The USPTO databases have to be one of the most torturous services to their users in the whole of internet. The UI of both the patent and trademark search is archaic, but not in a HN way but in a really bad way.
In patent search, there is no "search" box. Instead, the "quick search" forces you to specify two (and exactly two) text queries on the database columns with obligatory boolean operation.[1] Even if you happen to find an interesting patent, good luck linking to it (which should be the number one service they provide - GET individual patent documents). The page showing the patent document has a dozen cryptic query parameters in the URL, some of which relate to the search query you used to find the patent! No "make shareable link" button to be seen, either.
And don't get me started on the trademark search, or Trademark Electronic Search System (TESS), as they like to call it.[2] When you navigate to the front page, you get a private session identifier - in your URL of course! And when you search for a trademark ("simple search" is intuitively known as "New User" here) and select a TM to view, you would be excused of thinking that the short URL in your browser address bar is the linkable URL of this entry. But no - it's just your session identifier along with the document's index in the results of your last search query.
When you leave the trademark site or just click "Logout" (since you're a kind person - they after all ask you "logout when you are done to release system resources allocated for you"), that URL is gone in the wind. If you shared a link to that trademark to your friend, they only get this very helpful page:
<H1>This search session has expired. Please start a search session again by clicking on the TRADEMARK icon, if you wish to continue</H1>
So no way to link to individual TM registrations here either.
FWIW, you're often better off not searching, or looking at, patents.
If you end up in a patent case, your liabilities will be much higher if they can sufficiently claim you knowingly infringed. Evidence that you searched for patents can weigh against you / your employer. Even if you weren't associated with the infringing product itself.
The bizarre practice of assigning session keys to visitors and somehow storing the page they're viewing in the server instead of in the URL is pretty common in Brazilian government, which is dominated by Java programmers.
Historically it was fairly common. I wouldn't say it was standard, but it happened often enough to notice. There's a bunch of reasons that come together to cause that.
During the explosion of the web, enterprises moved much of their development into web solutions using an existing workforce that had skills in different technologies - often client-server desktop-to-RDBMS tech. Java was a popular choice for these new projects. Those developers would range in their general aptitude - some were quite good, some weren't - but they all came onto these projects with existing skills and knowledge in patterns and architectures that weren't particularly well aligned with web development. They were expected to adapt and deliver at pace consistent with their previous projects. So they did what they could to get the job done, even though that meant that their solutions were not well suited to the web environment.
That doesn't have a lot to do with Java specifically, except that it was a common language for that situation. It was far more common for enterprises to take VB/PowerBuilder/Delphi/etc Devs and move them into Java than something like PHP.
But Java was more likely to produce this horrible implementation for a couple of reasons.
Firstly, as a general purpose language (that also happened to have decent web capabilities) it was easy to design an application using your traditional patterns and then just shoe-horn the web UI on top. You were far less likely to do that in a web-oriented platform like PHP or ColdFusion (!).
Secondly, the Java servlet spec makes sessions really easy (because it stores standard, stateful, Java objects) and didn't offer a lot for managing complex page state. You could spend several days trying to build something to page through database search results with query parameters, only to find that the back button broke your design. Or you could just throw it all into the session, and call it "done".
That probably peaked about 15 years ago, but inertia is a strong force, particularly in government and large enterprises. Some of those developers are probably still working like that. Some of them trained others. And many others know that it's a bad design, but there's no budget to fix it.
Also, the third likely reason is that there are still a lot of Java web codebases from the mid to late 90s around; the Java runtime can still run the code, so people keep it. Perl and TCL are less likely to be convenient to run today, and more of those codebases will have been dumped.
And Java was disproportionately used for very large complex systems which would be expensive to replace, in any case.
This practice has nothing to do with Java, at all. It is not an approach that was invented by Java, for Java, and it is not in any way unique to Java.
Most web technologies support rendering a view based on a set of values residing in a database, and use the values to populate a template. The template contains placeholders reserved for values expected to originate from a database.
The version of the page that appears in your web browser usually does not exist as a serialized HTML page on a disk connected to a server. It often only exists as a representation of two pieces of information bound to a session in memory on a server: 1. The Template or server-side script, 2. the values you are authorized to retrieve from the database, which may or may not be a SQL database.
What you see in the address bar does not need to correlate to the HTML rendered in the browser window. JavaScript (which is not Java) often employs this technique, termed as a "single page web application."
This is true for PHP, Mcrosoft, Ruby, Python, Perl, server-side JavaScript (such as node.js) and yes Java too.
What's being described above isn't simply template-based rendering (which, yes, essentially everything does), but the practice of building web-software like desktop software and keeping the state of the UI server-side. It ignores that browsers are capable of effectively forking the UI through (today) tabs and (historically) "Open in New Window". Interacting with such software is a profoundly unpleasant experience; thankfully it's not particularly common, especially outside of "enterprise" applications (including government services, public utilities, education management, property management, healthcare, etc.)
It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one).
The vast majority of frameworks (including most modern Java frameworks) do the sane thing and keep application state on the server side (often in a database, as you describe) and UI state on the browser side, which allows links and forms to work the way links are generally supposed to work.
> It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one).
ASP.NET WebForms has a feature where the Session ID, normally stored in a cookie, is stored in the request URL path instead. This was done back in 1999-2001 to support extremely rudimentary HTTP clients which did not support HTTP Cookies - imagine really prototypical mobile-phone web-browsers or hastily-written shell scripts using CURL.
Fortunately it was disabled by default and the documentation describes why it's a bad idea to use it - and I understand the business reasons for including it - however this design does not break things like multiple-tab browsing: that's just what happens when you have any stateful web-application, regardless of framework.
It's now gone in ASP.NET MVC (where you gave full control over rendered URLs), so that horrid chapter has ended.
Which is great, because everybody should downvote anything because of a mild distinction, rather than the wildly off the mark question that prompted a reasonable response. Good job!
Well, the post I responded to included a more or less textbook description of template based rendering. It's a response to a response to this:
> The bizarre practice of assigning session keys to visitors and somehow storing the page they're viewing in the server instead of in the URL is pretty common in Brazilian government, which is dominated by Java programmers.
Having dealt with such a service just today (King County Recorder's Office public records search) that behaves in this manner, I felt pretty familiar with what I was describing.
It is entirely possible I'd misapprehended the situation, but as it's an informal conversation on the internet about bad web development practices, I'm going going to dwell on it too much.
You got what I meant correctly. Thank you for understanding me.
I don't know how could anyone think I was talking about general template rendering (but maybe I expressed myself badly, English is not my first language).
...which is pretty much how hashtag-based single page webapps operate.
Many, if not most, isomorphic react/node.js apps have a single API url, with microservices behind the load-balanced URI, that accepts HTTP POST requests, and looks at a JSON object sent as the request body, in turn responding with a JSON object that informs the client-side app to re-render accordingly.
This isn't bizarre at all. It is very, very common; if not the norm.
Also, once you get your patent search results, clicking on one of the links takes an amount of time that seems to scale with the complexity of the search. So I suspect that they actually re-run the search every time you request a result.
Has anyone built an open index, legal or otherwise? Doesn't seem like it would be too hard to script the downloads and build a real search tool for it.
Question: if it's really this bad, this site is going to have incredibly poor ratelimiting or per-IP analytics/access controls, if it has these things at all.
So, it probably wouldn't be too impossible for someone to build a new site (maybe even an API) that talks to this and prettifies the results, lets you copy URLs (most likely via caching¹), and so forth. (The case in point about my previous paragraph is that the new site would generally hitting the old one, possibly several times a second, from one IP.)
You'd just need a strong mind to handle the inanities of talking to this system. :P
¹ But with the caching thing, you'd absolutely have to have a disclaimer stating that the services don't replace the USPTO website, yada yada (along with some wording buried in a policy document that carefully points out that the data is cached). I mean you'd need that anyway, but yeah.
Probably the only thing keeping this from being abused is that it's the government, it's a low-value target, and they're paying millions upon millions for someone to support this trainwreck with security patches.
In patent search, there is no "search" box. Instead, the "quick search" forces you to specify two (and exactly two) text queries on the database columns with obligatory boolean operation.[1] Even if you happen to find an interesting patent, good luck linking to it (which should be the number one service they provide - GET individual patent documents). The page showing the patent document has a dozen cryptic query parameters in the URL, some of which relate to the search query you used to find the patent! No "make shareable link" button to be seen, either.
And don't get me started on the trademark search, or Trademark Electronic Search System (TESS), as they like to call it.[2] When you navigate to the front page, you get a private session identifier - in your URL of course! And when you search for a trademark ("simple search" is intuitively known as "New User" here) and select a TM to view, you would be excused of thinking that the short URL in your browser address bar is the linkable URL of this entry. But no - it's just your session identifier along with the document's index in the results of your last search query.
When you leave the trademark site or just click "Logout" (since you're a kind person - they after all ask you "logout when you are done to release system resources allocated for you"), that URL is gone in the wind. If you shared a link to that trademark to your friend, they only get this very helpful page:
So no way to link to individual TM registrations here either.1: http://patft.uspto.gov/netahtml/PTO/search-bool.html
2: http://tmsearch.uspto.gov/