USPTO to add surcharge on non-DOCX patent applications in 2023
federalregister.gov
federalregister.gov
This also likely means I will need to rework our systems to spit out docx instead of/in addition to PDFs, which will be a nightmare to do. So that's fun.
I made an xlsx exporter in actionscript3 (lol) years ago and it worked like this. What I ultimately did was made a "template" document, and my code just injected strings into key spots, zipped it up in memory and gave it to you as a file.xlsx. Probably took me 3 days?
I didn't have the benefit of libraries so I imagine this is significantly easier in less hobbled environments, nodejs or whatever probably has a kitchen sink package to do it.
If anything, generating a pdf from various input files/structured text has been a much harder task. We generated docx files to allow for easy modification by non-technical staff, but to generate a pdf we had to use a headless instance of libreoffice since pandoc was struggling with the rendering.
ODT (OpenDocument) is also XML-in-a-ZIP and is also an ISO standard (older than Microsoft's, in fact).
I don't think the older variants (.doc, .xls etc.) are standardized, but iirc Microsoft did eventually release some documentation on them.
Apparently. Then a captcha and a button to request access, which if you complete, returns a 500 Internal Server Error.
… my tax dollars are hard at work, I see.
The Wayback Machine hasn't got a snapshot, either, it seems.
The correct one is: https://www.federalregister.gov/documents/2022/04/28/2022-09...
If you go to USPTO Operating Levels FY 2021-FY 2023 note that the Estimated Fee Revenue and Total Estimated Spending are approximately the same.
There are no tax dollars hard at work here.
But it doesn't really say why they chose to build on docx.
Having worked directly with their teams in the past (although not on this), a lot of their systems seemed to evolve naturally over time based on the needs present. In that industry, a large majority of the documents being passed back and forth are DOCX. So my semi-educated guess is someone built a system to handle some simple intake tasks for DOCX applications because a large majority already were, it evolved over a few years, and when they finally decided to fully automate the process, they decided to build upon what they have which only supported DOCX and it was cheaper/easier to mandate everyone submit in that format than to build a new system or add support for others.
Regulatory processes, business systems, and international integration are plagued by PDF OCR complexities. OCR creates systemic issues and an anatomy of complex system architectures. Im sure XML is a typical downstream for parsing anyways. Use DOCX to enhance quality of the overall scope of integrations.
I don't necessarily disagree with your point (since it makes complete sense), just wanting to point out that they already have a system in place for this using other means (although even there they are moving toward XML instead, likely because of what a pain it is to deal with text that exceeds the area of the input in PDFs)
It seems more like rationalization than reason.
Interestingly, a section in the wiki article linked mentioned the standard proposal was controversial because ODF already existed (and ODF was considered less complicated as a specification).
Nevertheless, good point. It depends on what you mean by "open".
[1] https://github.com/jsvine/pdfplumber/blob/stable/pdfplumber/...
[2] https://trepo.tuni.fi/bitstream/handle/123456789/21520/Nurmi...
A 6000-page spec and attributes that specify if the data is tabular data based on various properties (be it columns and rows or just plain text with start and stop pointers) and then may or may not render it visually as a table is error prone, even on first-party implementations (first-party desktop versions within Windows vary, as wel as on macOS, Android, iOS and their web offering).
If there was one simple data structure describing the table and all other aspects being optional, then yes, a XML based format is easier than OCR. But that's not the case I was pointing at.
Not really, or at least not all that specialized. You need:
a: a pdf-to-raster-image converter (ie any working PDF viewer, plus maybe the X server it talks to)
b: a reasonably decent OCR system capable of scanning tables (definitely nontrivial, but hardly "highly specialized" since things other than PDFs display data in tables).
I wrote DDEX parsers in the past and I wish it never existed...
https://support.microsoft.com/en-us/office/differences-betwe...
The list was only a few lines the last time I looked years ago, so maybe they're actually trying to make a complete list.
[edit: but I will grant that almost anything is better than attempting to parse useful content from PDF.]
In fairness though this a really good point.
I expect that whatever tooling the USPTO uses can probably just ignore those things. They're extracting metadata, not actually rendering it.
edit: ninja'd.
Is requiring the DOCX format just adding another step in the process for applicants?
Actually, it's the opposite. The USPTO conducted a study and found that over 80% of applicants are authoring their applications in DOCX format (through writing tools such as Microsoft Word). Because the files are originally in a DOCX format, uploading the original file eliminates the step for the applicant to convert the document to PDF prior to submission. Instead, the applicant is able to save the step of converting because our system will do that automatically.I used to be able to eke out accurate page layout in MS Word, but it was always fraught and more difficult. But if you’re not perfectionist about layout precision, MS Word provides the same meta-data encoding function through the application of style (‘this is a heading’, ‘this is a definition’, etc).
The fee is $100, $200, or $400 depending on the size of the document.
> Privacy: provides automatic metadata detection (e.g. author and comments) and removal features to support the submission of only substantive information in the DOCX file.
And, then further down in the FAQ it says:
> What happens to the metadata in DOCX files?
> Metadata is generally removed by applicants prior to submission. However, if metadata is found during the validation process, it is automatically removed prior to submission. Examples of metadata include author, company, last modified by, etc. The only information that is preserved is the size, page count, and word count.
> Outgoing DOCX documents (i.e. Office actions) from the USPTO to applicants will also have metadata removed.
[1] https://osswatch.jiscinvolve.org/wp/2007/01/05/criticism-of-...
[2] http://www.robweir.com/blog/2007/01/how-to-hire-guillaume-po...
[3] https://en.m.wikipedia.org/wiki/Standardization_of_Office_Op...
It would be a monumental effort to create another implementation and completely impossible without referring to MS Office as a reference implementation.
If the PTO has provided an MS Word Style Template and a document schema (document template), it is dead easy to extract a useful XML encoding for further analysis. There is a lot you can ignore in an MS Word file. Dead easy to write XPaths and XQueries that provide an API for the original DOCX document collection.
I encourage anyone who believes being a patent examiner is an easy job to read this subreddit: https://www.reddit.com/r/patentexaminer/
You can find patent examiners who say that being a patent examiner is relatively easy. These folks typically changed from a notoriously difficult job in law or academia. So it's only relatively easier. Beyond these cases, there do seem to be some examiners who have an easy time, but that's quite rare in my experience, and I'd question the quality of their work.
As for why I took the job: I came from academia, so the job is easier in some respects. The quota isn't entirely bad: It's hard to meet, yes, but it's also mostly objective. If an examiner's numbers are good, the USPTO is happy with them. That contrasts with my experience in academia, where one's job performance is often subjective. If a researcher's boss decides they don't like the researcher for whatever reason (office politics, the researcher is socially awkward, etc.), there might be nothing the researcher could do to recover from that. The job also does give me a lot of freedom in other ways: I can live mostly anywhere I want to, I'm not expected to work all the time (production numbers beat looking busy by working all the time), there are few IP restrictions (aside from that I can't get a US patent), etc. The main problems for me are that the quota is too high and that I don't care for the technology I'm assigned (though the technology could be a lot worse).
(It should go without saying that this comment is my own opinion and not that of the USPTO, US govt., my previous employers, etc.)
I gather IPCCAT https://ipcpub.wipo.int/?notion=search&version=20220101&symb..., uses ML - and other offices have similar tools.
UKIPO use AI for trademark searches and to streamline applications, eg https://ipo.blog.gov.uk/2020/10/29/introducing-the-trade-mar....
Patent examining seems pretty complex analytically, perhaps some aspects of patent drafting, making a common description from a bunch of 3D renders (like scene description) might be the next low-hanging fruit after classification?
Note: I am a current USPTO patent examiner, and this is my opinion, not that of the USPTO or US govt.
The USPTO apparently has two contractors to classify patent documents. I've heard that some sort of AI system is used for classification, in combination with a lot of poorly paid contractors. In my experience, the classification is so frequently wrong that this is clearly not working. It might seem okay to upper management, who never has to actually deal with the classification being inaccurate. But examiners aren't happy with it.
Many people are calling for AI search. The new head of the USPTO mentioned it during a recent all-hands meeting. Unfortunately, the people who propose AI search don't seem to realize that 1. the USPTO has at least 5 AI search tools at their disposal (PLUS, More Like This, Dialog's similarity search, IP.com's similarity search, and Google Patents similar documents) and 2. none of these AI search tools work that well. In my experience, most of the time these tools don't return useful documents. (I still try them for every application as there's little downside.) The documents are usually close but it's rare that I'll actually use one of these documents in a prior art rejection. AI search sounds good to people who have never searched for patents and particularly have never used the existing AI search tools. AI search technology probably won't be good for a decade or more.
In contrast, tools to analyze patent claims for various problems (basically, linters) have been available for around 30 years and can be quite useful in my opinion. But the USPTO has no such tool available to examiners, and analysis under 112(b), etc., is almost always done manually. I wrote my own tool, which I run on my USPTO computer on a regular basis.
There are a huge number of opportunities to streamline USPTO operations with automation. Why are IDS forms not computer-readable? Why is so much information not auto-filled? Why do I have to fill out "bib data sheets" for every application? Why do I have to manually upload my search history when the system could easily automatically grab it for me? Etc.
And automation isn't enough. There should be more data validation in the process, as a lot of problems can be automatically caught at the time of filing or when I post an office action. That's when fixing these problems would be easiest.
Could you elaborate on this? I'm still on the fence about even having independent dotfiles in a separate repo.
Perhaps it is different because it's governmental work, therefore for the public good?
If I may ask yet another question: if your tools make you more efficient, does that impact perception of other examiners' "KPI metrics?"
Automation is a sensitive topic at the best of times, so just trying to learn some context from different fields. Thank-you.
I'm not quite sure what specifically you want me to elaborate on, but I'll write about how similar my work and personal computers are.
My USPTO computer is almost entirely independent of my personal computer. I run Linux on my personal computer, and the USPTO computer is Windows. The repository for my tool, plint, is on both my USPTO and personal computers. With that being said, I make all the commits to the GitHub repository on my personal computer.
> If I may ask yet another question: if your tools make you more efficient, does that impact perception of other examiners' "KPI metrics?"
plint doesn't seem to have any effect on how I am perceived or how other examiners are perceived. I've told some examiners about plint. Some don't seem to be interested, others like the idea. I don't know of anyone else using plint on a regular basis.
Also, using a tool like this doesn't necessarily make an examiner more efficient in the KPIs that upper management cares about. The most "efficient" approach would be to ignore 112(b) problems unless they are particularly obvious. In fact, I think that's what the incentives encourage: doing the bare minimum and moving on to the next application. However, a tool like this makes quality examination more efficient. I'd like to do as high quality a job as I can given the absurd time restrictions on my work. USPTO upper management gives a lot of lip service to quality, but quality isn't rewarded like "production" is. (Again, all this is my opinion and I don't speak for anyone else.)
Our fair advantage is in the authoring of computing instructions, and that's as good a chance as we may get.
I hope we will both have stories to share a decade hence.
I see https://unblock.federalregister.gov/ which doesn't take me anywhere useful.
In case that the overagressive HN filer ate it again, it's https www-federalregister-gov documents/2022/04/28/2022-09027/filing-patent-applications-in-docx-format
Also dang, recently HN's filters are too aggressive - from sentence-casing USPTO (to Uspto which isn't even a pronounceable acronym) to removing Twitter's search queries.