The Five Questions US IP Law Firm and Corporate IP Leaders Should Ask a Technology Consultant Before Funding Custom Docketing Software

This article is part of our series on Custom Patent And IP Docketing Software Development for US IP Practices: Building a Deadline, Annuity And Foreign Filing Instruction System

Introduction: Ask Who Maintains the Rules

One of the docketing software consultant questions below settles most of this decision, and it takes about two minutes.

Ask a prospective partner who maintains the rule sets after launch. Not who builds them. Who knows, in eighteen months, that a particular office changed a period or adjusted a fee window, and who encodes and tests that change.

A partner who has worked in this domain answers immediately that it requires legal expertise alongside development, that it never stops, and that it is the strongest argument for adopting an established platform rather than building.

A partner who treats rule configuration as a one-time data load has not understood what they would be handing you.

Four more docketing software consultant questions follow, covering provenance, criticality, migration and closure. Before any of them, one exercise is worth doing because it frames everything.

Pre-build questioning is the decision layer of the full custom software development guide to custom IP docketing platform development, whose surfaces are web application development for docketing specialists and attorneys.

The Exercise: Audit Twenty Dates

Pick twenty live dates across jurisdictions and action types and ask, for each, what rule produced it.

Can the system tell you the triggering event, the rule applied and the version in force. Can it tell you who verified it and when. If a supervisor doubted the date, how long would checking it take.

Most practices find the system stores a date and little else, which means checking means reconstructing: finding the correspondence, recalling the rule, and recomputing by hand.

Then pick five dates where the deadline is non-extendable and check whether the system says so, or whether that knowledge lives entirely with the practitioner.

Those two findings together describe your current exposure more precisely than any feature comparison, and they are the specification for whatever follows.

Both use your existing system and both are worth knowing whether or not anything gets built.

Questions Two and Three: Provenance and Criticality

Ask what a date record contains. The answer should include the triggering event, the rule applied, the rule version in force at the time, any adjustment and the identity of the verifier.

A partner who describes a date and a description has proposed a system that cannot explain itself, which is the system most practices already have.

The follow-up: what happens to a date computed three years ago when the rule changes? The right answer is nothing, because the date knows which version produced it. Anyone proposing recomputation against current rules has misunderstood what a historical docket is.

Then ask how the system conveys that a deadline cannot be extended. A good answer treats extension availability and consequence as properties of the deadline rather than as convention or colour.

Anyone describing priority levels or a red flag has described decoration rather than information.

The follow-up there: what does a practitioner see the day after a date passed? The answer should include whether anything can still be done and by when, since revival windows are themselves deadlines. The obligations these questions surface are set out in USPTO Duty of Disclosure and IDS Timing, Malpractice-Critical Docket Date Rules, Foreign Filing License Requirements and Maintenance Fee Windows.

Questions Four and Five: Migration and Closure

Ask how migration works. The only acceptable answer involves verifying migrated dates rather than transferring them, because a date that arrives wrong in a new system is a right at risk and the old system’s errors travel with the data otherwise.

A partner who has done this will describe verification at volume by competent people, parallel running because a gap is unacceptable, and a plan for the dates that cannot be reconciled. One who describes a data mapping exercise has not understood what is being moved.

Then ask what closes a deadline. The answer should be a recorded action by a person, with nothing auto-closing, nothing dismissing on age and a passed date remaining visible as passed.

The follow-up is the one that reveals most: what does the system do about complaints that there are too many reminders? A good partner answers that volume is addressed through criticality, routing and proportionate escalation rather than suppression, and explains why filtering removes the entry that mattered.

Anyone offering intelligent filtering or noise reduction as a feature should end the conversation. The estimate a consultant should defend is detailed in Custom Patent and IP Docketing Software Development Cost.

Reading the Pattern

The five answers together show whether a partner understands that this system’s failure mode is a lost client right rather than a defect.

The pattern to look for: rule maintenance named as permanent and requiring legal expertise, dates carrying full provenance, criticality as a property conveying consequence, migration as verification, and closure as a human act.

The pattern to walk away from: rules as a one-time load, dates as values, criticality as colour, migration as mapping, and filtering offered as a benefit.

On the decision itself: for the overwhelming majority of practices an established platform is right, and the rule maintenance answer is why. The question worth asking a vendor is the same one you asked the consultant.

Where a build genuinely applies: very large corporate departments with deep enterprise integration, IP service providers for whom docketing is the product, and practices whose structure the products express badly.

And whichever path, the twenty-date audit findings are your current exposure and worth addressing now, since a system that cannot explain its dates is a system nobody can effectively supervise.

What the Exercise Produces Regardless

Three findings from the exercises above are worth acting on whatever the software decision.

Date provenance: if your system cannot explain how a date was derived, supervision is harder than it should be and a second pair of eyes cannot work efficiently. Adding the derivation to the record manually for critical dates is possible in most systems and improves checkability immediately.

Extension availability: if that distinction lives only in practitioners’ heads, a written reference by jurisdiction and action type costs an afternoon and addresses the characteristic failure of this practice.

Passed dates without recorded action: run the report. In most practices it is not empty, and some of those entries have revival windows still open, which makes this the most urgent of the three.

A consultant who identifies all three and tells you to fix them before buying anything has given you more value than the project would.

And a docketing review by somebody external, which several practices commission periodically, is a cheaper way to find these than a build.

Red Flags

A fixed price before the jurisdiction list exists. Rule maintenance absent from running costs. Migration priced as data transfer. No product comparison in a category where established platforms maintain the rules. No docketing staff involvement. Rule authoring treated as development work.

And the ones that should end the conversation: automated docketing presented as removing verification, dates stored without provenance, intelligent filtering or noise reduction offered as a feature, auto-closure on age, materiality determination for disclosure, and recomputation of historical dates against current rules.

The strongest positive signal is a partner who tells you to buy a platform and asks what else you need.

Conclusion

Ask who maintains the rules first, since the answer settles most of this decision and most practices should adopt an established platform because of it.

Audit twenty dates for provenance and five for extension availability, because both describe your exposure better than any feature list.

Run the passed-without-action report this week, since some of those windows are still open. And treat migration as verification rather than transfer. Put those docketing software consultant questions to every partner, including the software companies in the United States who would like to build it.

If you are weighing custom docketing software, asking each prospective partner who maintains the rule sets in eighteen months is the two minutes that will sort your shortlist.

FAQ