Patentsview Suggestions

There doesn't seem to be a suggestion box, there's just an email address. Here is a list of what I'd like them to consider:
  1. Update:there is a forum now!

    There should be a forum to discuss issues and possible enhancements. Currently there is just an email address for a two way dialogue. How about an n-way discussion instead? There is built in redundancy in an email only system if multiple people are reporting the same bug or requesting the same new feature and there are presumably discussions going on that no one else is aware of. I'd imagine there are a lot of great ideas floating around with no way for service consumers to share them with each other.
  2. The locations endpoint should have a distance or radius attribute. ex: give me the patents from everywhere within 10 miles of Cleveland. I have a workaround that requires making multiple web service calls (one for each nearby city). It would be way more powerful if this functionality was added to the web service rather than making service consumers do it themselves.
  3. Or maybe a rectangle instead of a circle? I'd like to be able to query the location endpoint by latitude and longitude but it is not allowed. I received HTTP/1.1 400 Bad Request. X-Status-Reason: Not a valid field for querying: location_longitude. It would be nice to be able to specify a rectangular area bounded by two points (a,b) and (c,d). Logically where (latitude >= a) and (latitude <= c) and (longitude > b) and (longitude <= d). Or less readably {"_and":[{"_gte":{"location_latitude":a}},{"_lte":{"location_latitude":c}}, {"_gte":{"location_longitude":b}},{"_lte":{"location_longitude":d}}]}
  4. Query language suggestions
    • Add _isnull and _isnotnull. I'd like to be able to ask for patents that have a govint_org_name. I'm not sure what possible values exist in the database. I could find out by querying the endpoint if these operators were added to the language. I'd also be able to do things like ask for patents assigned to people not entities. The query would _isnotnull assignee_organization and _isnull assignee_first_name.
    • A _between would be a nice addition. Especially for a patent dates and patent numbers rather than having to do {"_and":[{"_gte":{"patent_date":"2007-01-01"}},{"_lte":{"patent_date":"2010-06-30"}}]} maybe {"_between":["2007-01-01","2010-06-30"]} where it's an error if there aren't exactly two values. Turn into a between in the sql: where patent_date between '2007-01-01' and '2010-06-30'
    • There is a _begins. How about an _ends?
    • On the _text_any how about a separator other than blank so I can try to match a whole word rather than a portion? Or a separate operator to do matching on word boundaries. I might want to search for " Ave " for instance. Or maybe better, have the second argument be an array: {"_text_any":{"patent_title":["COBOL","cotton"," gin "]}} The query language page says that {"_text_any":{"patent_title":"COBOL cotton gin"}} a title that contains "cotton" or "gin" or "COBOL". But what if I don't want matches like PP24,545 Heuchera plant named 'Ginger Snap'?
  5. Have an option to suppress null fields. On a web page or in a phone app I probably wouldn't display these to a user. Here's assignee data to illustrate this. As it is I'd have to add code to my clients to not display these fields.
  6. Add an /ipc endpoint. The FAQ mentions that there are four classifications being used but only three have endpoints.
  7. Use Swagger to interactively document the api for developers!
  8. For api friendliness there should be an optional way to specify a jquery callback function. The returned json data would be wrapped in the specified callback function.
  9. Also for api friendliness, the patentsview service should return a status code of 404 (not found) rather than a 200 (success) when there are no query results (nothing met the users search criteria). Currently it returns a 200 (success) with a count of 0.
  10. I'd like the count meeting my search criteria returned for an endpoint. Ex: I'd like to be able to query the locations endpoint for plant patents and sort the results by those counts from high to low. Here's my attempt to get the most prolific plant patent locations but it isn't quite right. For a location I can ask for the most prolific inventors or assignees as shown here. I'd also like to be able to get the most prolific locations meeting my search criteria.
  11. Update: there has been a partial fix for this. The cited_patent_number field is now filled in: Some patents cite ones not in the database. The xml and json have citedPatent blocks where only the sequence number is filled in. It might be nice to at least show the patent number, kind and date or whatever was scraped. Guessing a join is making the data null since those patents aren't in the database. It's generally accepted that even the uspto does not have titles for pre-1976 patents. ex: pn 3930271 references:
    2379430 July 1945 Frost
    2782422 February 1957 Bencriscutto
    resulting in this block of json and analogous xml:
          "cited_patents": [
            {
              "cited_patent_category": null,
              "cited_patent_date": null,
              "cited_patent_id": null,
              "cited_patent_kind": null,
              "cited_patent_number": null,
              "cited_patent_sequence": "0",
              "cited_patent_title": null
            },
            {
              "cited_patent_category": null,
              "cited_patent_date": null,
              "cited_patent_id": null,
              "cited_patent_kind": null,
              "cited_patent_number": null,
              "cited_patent_sequence": "1",
              "cited_patent_title": null
            }
          ]
        }
      ]
    
  12. The same patent has no application citations yet its application_citations would have a length of 1. possibly have "application_citations": null?
          "patent_num_us_application_citations": "0",
    
          "application_citations": [
            {
              "appcit_app_number": null,
              "appcit_category": null,
              "appcit_date": null,
              "appcit_kind": null,
              "appcit_name": null,
              "appcit_sequence": null
            }
    
  13. It would be nice if the api was HATEOAS, returning links to retrieve the next part of a result set etc. Here's an example where an endpoint of mine returns links to get inventors and assignees for a location so the caller does not have to build them themselves. My endpoint always returns the links but it could be coded so it would only return them if a new options parameter is specified (ex o={"addLinks":true}). My service accepts &f &s &o &format and adds them to the returned links. It also _and's in a &q parameter if specified.
  14. On the advanced search of the cool new query tool I couldn't build a query using a _not. I wanted to create a query where the patent_type is Plant but the patent number doesn't start with PP. Fortunately I figured it out: {"_and":[{"patent_type":"Plant"},{"_not":{"_begins":{"patent_number":"PP"}}}]} as shown on this page.
  15. I don't think the uspcs of "No longer published" is especially useful. I'd rather that the service not return the uspcs attributes when they aren't applicable (utility patents issued after May 2015) as shown here.
  16. I was surpised that the query builder does not offer to help with a location endpoint query. The api has 7 endpoints but the query tool only offers three of them (patents, inventors, and assignees). I would have liked a little help with a locations query I wanted to make where the city contains UTF-8 characters. The query tool is otherwise very cool and helpful. For inventors and assignees it lets you select an exact location, either location at issue or last known. _begins and _contains are not offered. A state can only be specified if the country is United States. For a country only search you have to enter a city before it will let you add the criteria to the search. You then can delete the city from the query.
  17. The government data could be served up by an endpoint
  18. It would be nice to be able to submit a generic query to the query tool. There are api features it doesn't support, like specifying multiple values for a field, using other operators than equals on locations or querying the locations endpoint directly (ex: city _begins with a digit). Or even using _or's rather than _and's. The tool's csv option and up to 100,000 rows returned make it very useful but there are queries it won't allow me to make.
  19. Publish the api's todo list(s). Several issues and posts mention that they've added something to a list. Here's an example where an ongoing issue was closed saying that it's been added to a list. Here's a post referencing another list.
  20. Perhaps there should be an R package specific forum in the patentsview community. There have been a few R package related posts but there isn't a specific forum for them. Invite Chris Baker, the package's author, to participate?
  21. How about using codegen and the swagger object I created to generate annotated Slim code? Maybe I'll try that locally and then create a PR. If the generated code can be merged into the existing code base Swagger would be baked into the api, as it should have been in the first place! I need to confirm this theory, it would work if the api was written in java (where the generated annotations will produce a swagger object at runtime. If the annotations are updated when code changes are made the swagger object will automatically be changed.) It looks like this would be required https://github.com/zircote/swagger-php#usage-from-php to dynamically generate the swagger page from the annotations. Might not need to use the codegen? Could just edit the existing source to add @OA annotations. It turns out that an endpoint can be added that returns the swagger yaml by crawling the annotations in the source code. auto-swagger-ui could be added as a dependency and be configured to call back to the endpoint just mentioned, and voila, dynamic swagger baked into to the api's source code. Note to self, the codegen idea could be used if @OA annotations were added to its mustache (honest, I'm not making this up) templates.
  22. The forum's url changed over time. Forum links in older posts should be edited so they will still work. Or redirects could be added (the current redirect goes to https://community.patentsview.org/).
    then: http://www.patentsview.org/community/forum/7/topic/107
     now: https://community.patentsview.org/forum/7/topic/107
  23. People in the forum mentioned wanting to track inventor location changes over time and again here. I was thinking inventors who appear to move a whole lot would be inventors to look at when trying to improve the disambiguation algorithm. That is, to use what looks like frequent moves as an indicator of disambiguation failures.