feat(search): add USPTO_PTLITIG docket source

[neilrubin]

Hi — I'm a first-time contributor to CourtListener. I've tried to take on the task of addressing Issue #664, importing PACER data from patent cases collected by the USPTO (the PTLITIG dataset), last updated in 2020. For better or worse, this task touches on some other components of the CL system, and I've broken it into 3 PRs as a result.

First, it seems like the PTLITIG dataset should be treated as a new Docket source value, but the current 8-bit field for such values is full. The first PR switches to a nine-bit source field. Others with a better sense of the big picture might prefer a different solution.

Second, the PTLITIG data identifies the patent(s) at issue in each of the cases. Patent numbers are a very important piece of data in analyzing and making use of patent litigation dockets, and there are other similar well-known identifiers (trademark or copyright registrations come to mind, but there are certainly others) that it would make sense for the CourtListener system to handle and to allow searches on. The second PR adds a database table for such identifiers, currently scoped solely to handle the patent values from PTLITIG. While out of scope for this PR, I would suggest scraping patent numbers from complaints and/or AO120 forms of patent cases to populate this table for more recent cases would be a good follow-on project.

The third PR is the actual ingestion process. The data files to be ingested are available at USPTO. As designed, this seeks to merge all PTLITIG docket entries into the current database, without adding duplicates or disturbing existing entries. Since it is PACER data (some from RECAP and some from the USPTO's own crawl), it includes both docket entries with entry numbers and those without entry numbers (e.g., minute entries). To avoid duplication or difficult merge logic on the minute entries, I chose to not import minute entries at all for items without entry numbers, if there were any existing docket entries for the case in the CL database. The thinking is that cases that currently have docket entries in CL are likely to have dockets at least as complete as those in a 2020 crawl and that minute entries for old cases are of relatively low value anyway, such that they are not worth dealing with the merge logic.

This is one of four PRs that I'm submitting today as a first-time contributor to the repo. While I'm knowledgeable concerning the PACER data, RECAP, and the CL data offerings, and I'm a capable Python coder, I am not intimately familiar with the internals of the repo code. As full disclosure, the code was entirely written using Claude Code, as was the entirety of this .md file, aside from the first six paragraphs of this summary. While I have attempted to carefully think through the design, make sure it is correct and consistent with the existing code, and make sure that it passes all CI tests, this is the work of a first-timer.

I'm aware that FLP has some sort of policies and guidance on the use of tools such as Claude Code for development, but I have not been able to review them. See Issue #7383. To the extent this PR is inconsistent with those policies and guidance, I am happy to revise once I'm able to see them.

Start of LLM-generated PR: This is the first of three small, stacked PRs that add the USPTO Patent
Litigation Docket Reports (PTLITIG) to CourtListener (#664). PTLITIG is a public
USPTO dataset of ~97k U.S. district-court patent cases (1963–2021), compiled by
the USPTO from the same PACER docket reports RECAP captures — so it fits
CourtListener's existing models rather than needing a new pipeline.

I split the work into three PRs to keep each one small and reviewable, and tried
to follow the contributing and database-migration guides (ruff, mypy, FactoryBoy
tests, the migration SQL files). I'd genuinely welcome direction on anything that
isn't idiomatic for the project — especially the design question flagged below.
Opening as a draft for early feedback.

Fixes

Part of #664 ("Incorporate USPTO PACER data"); see also the #448 umbrella for
consolidating bulk PACER sources.

This is PR 1 of 3 for the PTLITIG import. It targets main and changes no
behavior on its own. The follow-ups are open now as drafts so you can see the
whole arc:

• 2/3, feat(search): add DocketIdentifier model for asserted patents #7389 — adds a DocketIdentifier model for the asserted patents.
• 3/3, feat(corpus_importer): ingest USPTO PTLITIG patent litigation data #7390 — adds the import_uspto_ptlitig command that performs the ingest.

Please merge in order: this PR, then #7389, then #7390.

Summary

Adds a new Docket source value, USPTO_PTLITIG, so dockets contributed from
the USPTO Patent Litigation Docket Reports (PTLITIG) can be distinguished from
RECAP uploads. This follows the precedent of IDB and ANON_2020, where a
named external dataset earns its own source bit.

Why a new bit instead of reusing RECAP: most PTLITIG cases that lack an
existing CourtListener docket are exactly the ones RECAP never captured, so
marking them RECAP would be inaccurate.

The source byte was already full (all 256 combinations are enumerated), so
this adds the ninth bit (256) and its 256 new combinations to SOURCE_CHOICES,
generated the same mechanical way the SCANNING_PROJECT bit was layered on. The
field is already a SmallIntegerField, so values 256–511 need no column change —
only the choices — so the accompanying migration is a no-op. A matching
add_uspto_ptlitig_source() helper and NON_USPTO_PTLITIG_SOURCES() group are
added alongside the existing add_*_source helpers, with tests covering the
helper and the contiguous source-constant invariant the group logic relies on.

Question for maintainers before this grows further: this is a large (though
purely mechanical) addition to docket_sources.py — it doubles the enumerated
SOURCE_CHOICES. The file's own comment notes this should eventually become a
django-bitfield. I'm happy to take that route instead if you'd prefer; flagging
it here rather than guessing.

Deployment

This PR should:

• skip-deploy (skips everything below)
  • skip-web-deploy
  • skip-celery-deploy
  • skip-cronjob-deploy
  • skip-daemon-deploy

The only change is a no-op AlterField on the source field's choices; no
runtime behavior changes.

[albertisfu]

Thanks for this contribution @neilrubin. I’ve scheduled the review of this and the other three related PRs for our next sprint, which starts on June 9.

I took a quick look at the USPTO data and couldn’t find PDFs for the related docket entries.

I just want to confirm that this only imports the case and docket entry metadata, but no documents. Is that correct?

[neilrubin]

Hi @albertisfu, the USPTO dataset is purely PACER docket data (including docket entries) and USPTO matched patent numbers. No PDFs, though obviously CourtListener has a bunch of them.