Live data from Hacker News

USPTO to add surcharge on non-DOCX patent applications in 2023

federalregister.gov

31–40 of 109 posts

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#31
post #29

Earlier quoted context omitted.

It actually seems like a sane choice to me. PDF is good for rendering, but horrible for parsing. DOCX is a ZIP file with XML data. Maybe ODT or whatever would've been a better choice, I don't know what the format is like. But if you disregard the usual knee-jerk "but it's Microsoft!" reaction, it doesn't seem like a bad choice.

The Office Open XML file format is extremely complex, and takes up around 6,500 pages (compared to ~1000 for ODF). One thing you notice when reading the DOCX spec is that they designed it with the sole constraint that DOC files could easily be converted to DOCX. For example, you'll frequently see compatibility tags like "autoSpaceLikeWord95", "footnoteLayoutLikeWW8", "useWord2002TableStyleRules", and "lineWrapLikeWor…

So true. "It's XML, so it must easy to parse and manipulate" is such a naive, even misleading attitude. If what you do is take a byzantine, legacy-encrusted implementation and just serialise its data strucures to an XML representation, very little has been gained.

[edit: but I will grant that almost anything is better than attempting to parse useful content from PDF.]

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#32

I was wondering why docx format would be chosen instead of PDF but they answer it pretty completely here if anyone else is interested: https://www.uspto.gov/patents/docx

They say that 80% of the submissions used to be converted to PDF from word. I'd be interested to know where the other 20% came from.

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#33

Earlier quoted context omitted.

It actually seems like a sane choice to me. PDF is good for rendering, but horrible for parsing. DOCX is a ZIP file with XML data. Maybe ODT or whatever would've been a better choice, I don't know what the format is like. But if you disregard the usual knee-jerk "but it's Microsoft!" reaction, it doesn't seem like a bad choice.

Was just about to post this. Unzipping DOCX and parsing XML is much easier than accurately processing PDF submissions.

OCR has come a long way, so much that visually interpreting a PDF is about as error-prom as parsing XML output from Microsoft in non-microsoft software.

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#34
post #32

I was wondering why docx format would be chosen instead of PDF but they answer it pretty completely here if anyone else is interested: https://www.uspto.gov/patents/docx

They say that 80% of the submissions used to be converted to PDF from word. I'd be interested to know where the other 20% came from.

I’m guessing google docs is the next most common, and then probably libre office.

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#36
post #8

I was wondering why docx format would be chosen instead of PDF but they answer it pretty completely here if anyone else is interested: https://www.uspto.gov/patents/docx

It looks like most of those translate to "We build our automated systems around DOCX so you get all our features if you use it". But it doesn't really say why they chose to build on docx.

>But it doesn't really say why they chose to build on docx.

  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.

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#37
post #32

I was wondering why docx format would be chosen instead of PDF but they answer it pretty completely here if anyone else is interested: https://www.uspto.gov/patents/docx

They say that 80% of the submissions used to be converted to PDF from word. I'd be interested to know where the other 20% came from.

My guess is that printed and scanned documents from word make up a large component of this.

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#38

Can’t wait to see what kinds of unredacted metadata people start uploading without a thought.

It sounds like they're going to try to catch and remove that - one of the bullet points under DOCX Benefits on https://www.uspto.gov/patents/docx reads:

> 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.

Re: USPTO to add surcharge on non-DOCX patent applications in 2023

#39
post #26

I've been working on some tools that integrate with USPTO (both from the application side and the validation side) for quite a few years now and they've been making a TON of formatting changes recently. A lot of their PDF forms have changed, they're requiring XML versions of all data we submit, they're handling classifications differently, etc. Their process always felt like it was stuck in the past and being handled…

The consolation is that, if I remember correctly, docx is just a zip file containing xml. 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 s…

That's exactly right. There are definitely nodejs docx templating packages (I've worked on codebases that used them in the past), but they're certainly not required provided your documents are reasonably simple.

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.

Post reply on HN