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
[deleted]
USPTO to add surcharge on non-DOCX patent applications in 2023
21–30 of 109 posts
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#22I 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.
As a few others have mentioned, the parsing alone means DOCX is a huge win over PDF. I had to parse a bunch of PDF data related to COVID and it was always a PITA. Every time they changed their layout even a little bit I had to rewrite parts of my extractor. The worst part? The headers/metadata showed it was all made in Word so they could have exported to DOCX as well as PDF if they wanted to but they only provided PDF.
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#23Earlier quoted context omitted.
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. 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 applicati…
I get that you worked with them it seems, but would argue that your hunch is wrong here.
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.
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#24Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#25I don't think you submitted the link you wanted to. I see https://unblock.federalregister.gov/ which doesn't take me anywhere useful.
That explains why I get a 503 every time I pass the captcha.
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#26I'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 significantly easier in less hobbled environments, nodejs or whatever probably has a kitchen sink package to do it.
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#27Earlier quoted context omitted.
> 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 applicati…
I get that you worked with them it seems, but would argue that your hunch is wrong here. 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.
They could just use standardized application forms the way they do for research reports they require (the "ISA ###" forms). Those forms are easily parsable by things like pdftk and don't require any OCR.
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)
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#28Machine learning is coming for the examiners jobs. :P
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#29Earlier quoted context omitted.
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.
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 "lineWrapLikeWord6" that expose internal implementation details. Rather than creating a useful standard allowing all users to store their documents in a clean, portable way, Microsoft decided to make their standard faithfully reproduce all of the quirks and bugs of their legacy binary formats. It's so difficult to correctly implement the Office Open XML standard that even Microsoft took until Office 2013 to do so (the standard was approved in 2006).
Re: USPTO to add surcharge on non-DOCX patent applications in 2023
#30Earlier 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…
Interesting! How do they compare feature-wise? I feel like there must be things each of them support that the other one doesn't, but I don't know how consequential they are.