Manual patent downloading versus batch tools: a time model you can audit

Manual patent downloading versus batch tools: a time model you can audit

**Query date: 2026-09-21.** This article is a planning model, not a promise that every patent search or download takes the same number of seconds. Replace the example values with a small sample from your own docket before using the result for staffing or pricing.

What is being compared

The unit here is one reference that a paralegal or patent specialist must take from an identifier to a saved, checked PDF. It is not a novelty search, a legal-status opinion, or an IDS filing decision. A number that is syntactically valid may still be an unpublished application, a record without a retrievable PDF, or a document that needs a human decision about the correct publication kind.

The manual path is deliberately explicit:

1. Open the relevant office or aggregator: J-PlatPat, Espacenet, or USPTO Patent Public Search. 2. Interpret the number: country, digits, publication or application number, and kind code. 3. Find the corresponding gazette or publication record. 4. Download the PDF and confirm that it is the intended document. 5. Name and archive it according to the firm's matter convention. 6. Check the number, title, document kind, and file before marking the item complete.

These are work steps even when a portal makes one of them look like a single click. The second and third steps are where an application number can become a publication number, or where a family member can be confused with the cited document. The fifth and sixth steps are also real labor: a file that was downloaded but cannot be traced back to the matter is not a finished docketing result.

A per-item manual estimate

The table is a replaceable baseline for a clean, known reference. It is not a stopwatch study. The only calibrated anchor available in the repository is the Floen time-saved playbook's initial estimate of about 15 seconds for “manual search + download” of one known patent number. That 15 seconds is used only for the core lookup/download magnitude. The other rows make the hidden human work visible and are planning assumptions.

The subtotal is therefore:

`S_manual = 30 + 30 + 45 + 30 + 45 + 40 = 220 seconds`

For a firm's own baseline, keep the rows separate for at least ten to twenty items. Record whether the number was already a publication number, whether the portal was already open, and whether the item needed a second search. A single average hides the exact cases that later dominate a batch.

The formula

Use seconds during the calculation and divide by 3,600 at the end:

`total hours = case count × (sum of per-case step times + failure retry rate × retry cost) / 3600`

In symbols:

`H_manual = N × (S_manual + r_manual × R_manual) / 3600`

where `N` is the number of references, `S_manual` is the six-step subtotal, `r_manual` is the share of references that need at least one retry, and `R_manual` is the average staff time for one retry. Do not use a portal's server error rate as `r_manual` unless it represents the whole human recovery path. A retry can include re-reading the identifier, choosing a different office search, checking a family record, downloading a second version, and updating the archive name.

### Worked example: 100 references

Assume:

• `N = 100`
• `S_manual = 220 seconds`
• `r_manual = 0.15` (15% need a retry)
• `R_manual = 90 seconds` (one and a half minutes of human recovery)

Then:

`H_manual = 100 × (220 + 0.15 × 90) / 3600`

`= 100 × 233.5 / 3600`

`= 6.49 staff-hours`

The 15% and 90 seconds are not universal facts. They are scenario inputs. If a firm's sample shows 25% retries at 150 seconds each, the same 100 references become `100 × (220 + 0.25 × 150) / 3600 = 7.15 hours`. That is why a formula is more useful than a single “average time saved” headline.

What counts as a failure or retry

The failure model should come from the work that actually happens, not only from HTTP status codes.

### 1. The number is not recognized

The DownloadPatent parser distinguishes `native`, `english`, and `bare` notation. It also scans US application-number mentions separately from the general cited-reference parser. A line that contains no supported identifier is retained as an unsupported input instead of silently becoming a guessed document. For a manual workflow, the equivalent cost is checking the country prefix, punctuation, digits, and kind code, then returning to the source document.

### 2. An application number needs a different resolver

Application numbers do not all go through one universal lookup. The implementation tags different rows for GPSS, USPTO ODP, EPO OPS, or WIPO resolution. GPSS-backed resolution is currently limited to KR, CN, JP, and TW rows in this path. A pending resolution is not the same thing as a ready PDF: the resolver must produce a publication candidate before the download step has a document to fetch. If resolution returns no candidate, the item is a retry or a manual research task, not a successful download.

### 3. The identifier is known but is not downloadable

The number path explicitly carries `registry-only` and `provisional` as non-downloadable reasons. A registry record can be useful evidence that an application exists while still having no public gazette PDF. Treating such a row as a normal download makes the denominator look better but does not produce a file. The correct manual action is to mark the item, check whether a later publication exists, and preserve the reason.

### 4. The source returns a record but no usable PDF

The PDF fetch path separates an unavailable document from a temporary source error. The UI has distinct handling for `not-found`, `no_pdf`, `unavailable`, and source failures. In other words, “the search result loaded” is not proof that the file can be downloaded. The retry cost should include the time to distinguish a real missing document from a transient failure; otherwise a batch report will understate follow-up work.

### 5. The English family counterpart is missing

English-family lookup is a second decision path, not a rename operation. The current implementation checks family data for JP, CN, KR, and TW items, builds candidates from family members and priority information, and only then probes whether a machine-translation link is available when no candidate is found. The lookup is metadata-only until a candidate is actually downloaded. A missing counterpart therefore does not prove that the original is unusable; it means the original and the English option must be recorded separately.

### 6. Coverage is office- and document-specific

The current coverage page lists China, Japan, Taiwan, Korea, Europe, and the United States, but it also states that availability varies by publication and source. Its examples are not promises that every format is accepted: some CN application formats are not supported, not every Korean registration or design label is supported, and EPO patent coverage does not imply EUIPO registered-design coverage. These limitations are exactly why a firm's failure rate should be stratified by office and document kind instead of averaged across the whole docket.

Applying the same discipline to a batch tool

A batch tool changes the location of the labor. It can remove repeated portal navigation and perform bounded parallel fetching, but it does not remove input review, exception handling, naming rules, or the final check. For a staff-hour comparison, count only the human touch time. Report machine wait separately unless the person must actively supervise it.

Use this worksheet:

`H_batch = (B × T_setup + N × (T_review + T_archive + r_batch × R_batch)) / 3600`

`B` is the number of batches, `T_setup` is one-time preparation per batch, `T_review` is human review per item, and `T_archive` is the remaining naming/archive work. The batch failure rate and retry cost should be measured independently because a tool may catch some format errors before making a request while exposing other source failures later.

Here is one deliberately conservative scenario, not a product performance claim:

• one batch of 100 items: `B = 1`
• batch preparation: `T_setup = 240 seconds`
• review: `T_review = 20 seconds/item`
• naming/archive: `T_archive = 20 seconds/item`
• batch retry rate: `r_batch = 0.10`
• retry cost: `R_batch = 90 seconds`

`H_batch = (1 × 240 + 100 × (20 + 20 + 0.10 × 90)) / 3600`

`= 5140 / 3600 = 1.43 staff-hours`

That scenario is useful only because every input is visible. Replace 240 seconds with the time to prepare a real list, replace 20 seconds with the time your reviewer spends on each row, and count the actual exceptions. Do not subtract machine duration twice: if the specialist can work on another matter while the batch runs, it is not the same as attended labor; if the person must watch and restart the run, record that supervision separately.

For one item, the same batch assumptions produce:

`(240 + 20 + 20 + 0.10 × 90) / 60 = 4.82 minutes`

The manual example with the 15% retry rate is:

`(220 + 0.15 × 90) / 60 = 3.89 minutes`

So the batch setup is not automatically cheaper for a single special case. The break-even point changes when the batch preparation cost is spread across more items, when the list is already clean, and when the tool can preserve a useful failure manifest instead of forcing a full restart.

When manual work is the rational choice

Manual downloading can be the lower-cost and lower-risk method when:

• there is one item, or a very small list, and the batch setup cost exceeds the repeated clicks;
• the number is unusual, partly illegible, or tied to a prosecution question that needs professional judgment;
• the jurisdiction is outside the firm's tested coverage and the specialist must choose the authoritative source;
• the result is an application, provisional, design, or registration record where publication status must be established before retrieval;
• the matter requires a specific family member or a legally meaningful document version rather than the first PDF that opens;
• confidentiality or client instructions make it inappropriate to place the list into another service; or
• an outage is affecting the batch path but the official portal remains usable for one urgent item.

The right comparison is therefore not “manual bad, batch good.” It is a threshold decision: estimate the repeated human work, price the exceptions, and keep the professional review that cannot be delegated safely. A batch tool is most defensible when it reduces repeated mechanical work while leaving the firm's exception list, source identity, and final verification visible.

Sources and scope note

The portal examples were checked on 2026-09-21: J-PlatPat Simple Search, EPO Espacenet, and USPTO Patent Public Search. The EPO page also warns that Espacenet is not intended for bulk data retrieval; office terms and fair-use limits should be checked before designing any automated workflow.

The implementation facts in this article are based on the DownloadPatent number parser, application-resolution path, English-counterpart lookup, coverage page, and PDF result taxonomy as they stood on the query date. The 220-second manual subtotal, 15%/90-second retry example, and batch assumptions are estimation inputs. Measure them against your own matters and keep the rows visible when you revise them.

DownloadPatent can help collect available patent PDFs in a batch, but the decision to accept a number, choose a document version, resolve an exception, and complete the matter record remains a human responsibility.