Introduction to IPscreener
IPscreener is a decision support tool based on semantic technology used for automatic prior art retrieval. When feeding a raw text to the IPscreener API, the AutoMatch search engine converts this text to a fingerprint representation. This representation is used to fetch the most similar documents reflecting the context of the query text. This is done from a specially tailored global reference database of patent documents. Thus, relevant prior art is identified and presented to a user in a client platform without any manual interaction needed. Therefore, each review of an idea along the innovation process is given a support for faster decisions, better priority of resources and at a higher quality.
The IPscreener API is implemented as a standalone-module that is easily integrated with any existing commercial or internal patent administration system. The API service is built using REST principles which ensures predictable URLs that supports easy connectivity and communication. For a descriptive overview of the data flow see Fig. 1. The IPscreener REST API follows standard HTTP rules, enabling a wide range of HTTP clients to be able to interact with the service.
The IPscreener API system architecture
Fig. 1 The IPscreener API data flow architecture showing data traffic over Internet for a query and response.
System Security Frame Work
The API is hosted in a protected and secure environment including the protection of the user information and data.
- We have our own dedicated self-hosted servers for hosting the API, located in a 24/7 guarded vault in Stockholm, Sweden.
- A security surveillance system protects and prevents unauthorized traffic from accessing the network. It also ensures the implementation and compliance of the organization's regulatory policy.
- A hardware based firewall is implemented to secure the network traffic.
- When the clients access the API, no client information is stored/cached in the system except for the session ticket and case reference number. This data is used to track the number of performed searches.
- The API server has an EV SSL certificate implemented which provides an assured encryption level.
API Authentication Procedure
The API authentication is implemented as token authentication over the secure HTTPS protocol. By default there is no restriction on the IP-address from which the requests can be sent or from witch domain the request must come from (CORS). If the client requires additional security they can contact the support team to have a IP-address restriction and CORS enabled for their API authorization key. The client will then have to provide a list of IP numbers or an IP range that will be white listed, i.e. requests to API service is only possible form the specified IP addresses. Likewise, the same principle applies for registering whitelisted domains. You may retrieve API credentials and register associated IP restrictions by contacting the IPscreener support team, email@example.com.
There are two levels of user identification employed by the IPscreener API service. If the user is an end customer, e.g. direct end user, only the authorization key is needed when accessing the service, where said key also includes the client identification. When the client is a platform provider which in turn have their respective clients being the platform provider's end users, also the respective end user client-id has to be submitted in the header in the API request. In order for a platform provider to register and obtain a client-id for a new platform client, contact the IPscreener support team, firstname.lastname@example.org. A description of the hierarchy is revealed in Fig. 2.
Fig. 2 The access level hierarchy used to identify search requests for platform providers and end users.
API Pricing Model
The IPscreener API uses normally a transaction-fee based pricing model. Hence, you will need to purchase credits (the number of searches to be performed) in advance to use the API service. For more information contact the IPscreener team at email@example.com. A notification e-mail will be sent when there are few credits remaining or when the contract period is about to expire.
The IPscreener Search Procedure
The procedure for performing a search request via the API services is done according to the following steps. A general overview and introduction to this procedure of these steps is presented in Fig. 3 below.
- An API authorization key is needed for performing any access request.
- The request is initiated by the user specifying the search query text and how many records to be fetched in the result set. Optionally the user may also manually select what indexes to search with the query text. A maximum of three indexes may be searched in parallel. Index values is received by using the Index API.
- As a response to a query a session ticket is received. This ticket is used to fetch result data when ready for delivery. Thus, note that polling from the requesting part needed.
- The response is a result list with a number of hits representing the top most relevant documents corresponding to the content of the search query text. The hits are sorted in order of relevance. The result list includes for each hit the patent number, the associated relevance score and the additional requested document information.
- To fetch a PDF document for hit provided in the search response, insert each patent number a URL parameter request in the PDF API. The PDF document is encoded in base64 format.
- The maximum number of requests allowed are limited to 10 fetches per minute.
Fig. 3 IPscreener search procedure and identification steps.
IPscreener optimization and index selection structure
The AutoMatch search engine comprises advanced logic to optimize the search query according to the input text. In the default setup it automatically select the most appropriate settings for best recall and precision. This includes the possibility to also retrieve the paragraph considered by the algorithm to be most relevant for a specific retrieved document. The user may also manually select specific technically optimized domain indexes to be used during the query process. This includes the selection of customer specific indexes such as e.g. the archive of internal invention disclosures or adapted customizations. A summary overview of the index setup is shown in Fig. 4. For more information on special indexes and how to order and create them, contact the IPscreener support team, firstname.lastname@example.org.
Fig 4. Showing the layout structure for technical optimizations versus the IPscreener master collection.
The IPscreener search API
This API receives a text query input and then uses the AutoMatch semantic search engine to retrieve similar results from the worldwide patent database collection. The search procedure includes a first response to a query by returning a session ticket, which then is used to retrieve the results when ready for retrieval. Processing an IPscreeener query typically takes 15-30 seconds, and the patent data is delivered in a JSON format. The number of records delivered depends on the figure specified by the requested-hits parameter and are presented in order of ranked relevance. If the requested-hits parameter is null or absent, 25 records are returned by default. The request procedure is optimized for returning up to 100 records.
If no switches are provided IPscreener will select the most appropriate general settings for carrying out the semantic matching procedure, and returns a single result list. If the query specifies several indexes to be queried in the request, the number of results set by the requested-hits parameter applies to all. Thus, this is the number retrieved for each and one of the queried indexes, where the results for each index are presented sequentially according to the request order in the query string.
To note; we have a pilot running on a new feature where IPscreener performs an extra layer of analysis. For trying this new feature out use the switch "boost" as the optional index parameter. This feature is still in beta mode until further notice.
The next generation of IPscreener has an improved algorithm and extra layers of semantic analysis. This means that the engine identifies the technical domain that is optimized for the search query as such and tunes the settings accordingly. Currently the pilot running with the new analytic features is in a separate option named Boost. For trying out this new feature, use the switch "boost" with the optional index parameter.