I’m a member of piug (Patent Information Users Group) and one day someone asked about cpcs. Not the new classification system (Cooperative Patent Classification) but the obsolete one (Canadian Patent Classification) phased out in 1989. Someone from the Canadian Patent Office replied with a pdf of the classifications! It was pointed out that it is quite similar to the uspto’s USPC (United States Patent Classification. It is just me, or have others noticed that the acronym’s meanings don’t seem very creative). I had already created a searchable page for USPCs so it wasn’t all that difficult to create one for Canadian CPCs. The really funny part was that the guy from the Canadian Patent Office replied saying that he shared the link to my CPC search with his colleges!
To quote the original poster, “Using the Canadian CPC is the only way to search hundreds of thousands of expired Canadian Patents that are not classified by IPC and are definitely not text searchable.”
The full piug thread is here http://wiki.piug.org/display/PIUG/Canadian+Patent+Classifications and my Canadian CPC pages are listed here https://historicip.com/patent-classification-systems/#CA And yes, I know that saying Canadian CPC is redundant (the first C of CPC = Canadian) but I needed a way to distinguish it from the other CPC and didn’t want to spell out the acronyms each time.
Russ Allen, developer and patent enthusiast, created a Swagger UI json object and explains its usefulness.
Pretend for a moment that you are a developer working on something cool that needs to call a web service. If you are lucky, the web service provider will have made a Swagger UI web page available for you. It’s an opensource project that generates a web page that lets users make calls to the web service by filling in form fields. It’s similar to Postman with a lot of setup work done for you. At the heart of Swagger UI is a json object that specifies all the api does or will do if you play by its rules (properly use its verbs and endpoints by passing what it expects in the formats it accepts). All an api provider needs to do is to create the json object and plug it into the Swagger UI package they’ve downloaded from swagger.io. That’s nothing more than copying the json object and dist folder to their web site. Then they just need to update the index.html file with the url of the file containing their json object and boom, their web site has a Swagger UI web page for the whole world to use!
Russ noticed that the patentsview api did not have a Swagger UI web page so he created the necessary json object. Below is an example that shows both the power of the patentsview api and of Swagger UI. We start by filling in the Swagger UI web page’s form fields that will issue a get to the patentsview’s /patents/query endpoint but we intentionally made a mistake, perhaps you’ll be able to spot it.
When we press the Execute button in the Swagger UI web page, the response is added to the UI page.
It seems we’ve made the api mad by requesting a field in the f parameter that it doesn’t yet support. Fortunately for us, the patentsview api developers thoughtfully return an x-status-reason response header explaining exactly why it returned a 400 or Bad Request response code. How cool is that? (Note that not all api providers go to this extent to be helpful.) If we correct our request and press the Execute button again, we are rewarded with the api’s data returned nicely formatted.
The Swagger UI web page and this api’s x-status-reason become a powerful tool for developers and interacting with the api is a great way to quickly learn the ins and outs of the api before writing any code. Try this very demo here!
The json object can also open doors in the opensource community. Several opensource projects use the json object as input and convert it to other formats or generate tests etc. Like many things in life, there are two standards. There’s the Swagger 2.0 specification and the newer Swagger 3.0, also known as the OpenAPI specification. Russ used one of these opensource projects to convert the Swagger 2.0 json object into its corresponding Swagger 3.0/OpenAPI object. Having both versions maximizes usefulness. Some opensource projects accept either version but there are ones looking for a specific version. There’s a nicely formatted list of these projects and which version(s) they accept at http://openapi.tools. Oh, and if Russ hasn’t sold you on the power of the json object, he suggests that you try importing it into Postman to see what happens: Boom, nicely loaded Postman page just itching to hit the patentsview api endpoints for you! In Postman:
File -> Import -> Import From Link [Swagger (v1/v2)] http://patentsview.historicip.com/patentsview.json
Russ would like to contribute the two json objects to the patentsview api project if its developers would care to host a Swagger UI page at patentsview.org. Otherwise, the patentsview Swagger 2.0 UI page is available at http://patentsview.historicip.com/swagger/ and the Swagger 3.0/OpenAPI version is at http://patentsview.historicip.com/swagger3/. The UI pages look the same, but the underlying json objects are distinct and correspond to their respective Swagger versions.
Note: Currently the X-Status-Reason header is not being displayed in either version of the UI (in chrome at least). I’ve opened an issue to address this.
Not to condone violence, but there’s what I came across at a flea market today. I’m guessing the seller did not know of the patent or associated trademark but I did.
issued February 15, 1966
registered December 14, 1965