/
Technical Blogs

Technical Blogs

Introduction Every patent document in an on-site instance of CLAIMS Direct carries two identifiers: a UCID (Unique Document Identifier) and a publication_id. They are not interchangeable — they serve different purposes and operate at different levels of the system. This blog explains what each identifier is, why the schema needs both, and how they work together to make it efficient to store, retrieve, and deliver patent data across a multi-table schema.  What Is a UCID? The combination of countr
IFI CLAIMS offers three services that help you work with company names and patent ownership data: the Names API, Entities Pro, and the Entities Stream. On the surface, they may seem to overlap — all three can tell you who owns a patent and what subsidiaries a company has. But they're built for different workflows, different levels of depth, and different types of questions. Understanding which one fits your use case can save significant time and effort. Here's a practical guide to telling them a
What is the Unitary Patent (UP) and Unified Patent Court (UPC)?  A European patent with unitary effect or Unitary Patent (UP) is based on a European patent granted by the EPO under the rules and procedures of the European Patent Convention (EPC). The Unitary Patent is a single right that covers all participating UP Member States, which are a subset of the member states of the EPO. Only a single annual renewal fee is required to cover the included states.  The goal of the UP is to decrease the co
Introduction The Entities Stream offers detailed content related to IFI standardized names and corporate hierarchies including ultimate owners and subsidiaries. This stream allows users to build full corporate portfolios quickly, retrieve all subsidiaries for a specific company, and gain quick statistical insights into a portfolio more easily. The optional statistical analysis tables give insights for key metrics such as number of active patent families, number of granted patents, and more. Befo
CLAIMS Direct now supports recent PostgreSQL versions (i.e., 14-16). The Alexandria schema (alexandria-schema-tools) and IFI CLAIMS Direct yum repository have been updated. They provide tools for quality control (cd-count.sh), bulk extraction (cd-extract.sh) and bulk loading (cd-load.sh).  Please note: Updates should be stopped (or paused) before proceeding. See apgupd for instructions. PostgreSQL must be configured to allow inbound and outbound communication via the pg_hba.conf, security group,
IFI CLAIMS has been managing standardized company name variations for decades, allowing you to map patent publications to the correct original and current assignees. Our proprietary name management process cleans various types of entity names to address issues of misspelling, name changes, and other merger and acquisition activity. The result is the most reliable company name mapping available for IP analytics. Our Names Service takes this process even further, providing the Ultimate Owner for a
Backward citations are a primary component of proving inventiveness in new patent applications. These citations reference previous work or prior art that is considered relevant to a current patent application. However, when looking for these citations in patent data, it is important to know that they are not always published in the applications. Here, we will look at how backward citations are handled during the application process and how the process can affect where those citations appear in t
Introduction IFI recommends 10TB of disk space for an on-site PostgreSQL instance. Normally, this will accommodate approximately 3 years of database growth (depending on your subscription level). If you are running out of disk space more quickly than anticipated, the reason may be an increased number of deletes occurring during the update process. This is especially likely to occur when IFI replaces content at a more aggressive rate than usual, as we have been doing since October 2019 in order t
Introduction With the deployment of the cumulative patch alexandria-sql-patch-alpa-3636-20191101, on-site CLAIMS Direct installations now have the ability to utilize family and citation functionality in-house. What was previously only available using the remote CLAIMS Direct shared API is now possible internally with simple SQL functions. The following post will outline the steps required to prepare the data tables as well as presenting a brief walk-through of the functionality. Preparation Note
Processes The main executable script used for indexing is aidx delivered as part of Alexandria::Library. This script is responsible for pulling source data, converting it into Solr XML and submitting via HTTP POST to Solr for indexing. The conversion process from CLAIMS Direct XML to Solr XML is handled by the indexer class (default is Alexandria::DWH::Index::Document). Alexandria::Client::Tools also provides an indexing daemon, aidxd which monitors an index process queue. Insertion into this qu
Introduction There are a number of reasons one would need to re-index data from the data warehouse. These range from simply repeating a load-id to a complete re-index of the entire contents of the data warehouse. In this blog, I'm going to go over the mechanisms that move data from the data warehouse to the index and ways in which these mechanisms can be used to trigger partial or full re-indexing of data. Background In all installations of CLAIMS Direct, data synchronization between the CLAIMS
The CLAIMS Direct data warehouse is updated continuously. On average, 1-3% of the entire database is touched weekly. These 1-3 million updates fall into two categories: new documents (roughly 20%) and updated documents (roughly 80%).  New documents are, of course, new publications from issuing authorities, US, EP etc. Updates are generally, but not limited to, CPC changes, family changes (adding family ID), IFI integrated content (patent status, standard names and claims summaries), reassignment
Overview The CLAIMS Direct Web Services (CDWS) offer a variety of entry points into both the data warehouse and Solr index. These are mid-to-high-level entry points and can satisfy most requirements pertaining to searching and extracting data for a typical search/view application. There are, however, corner cases which may require more intricate extraction of particular information. On the other hand, there may also be situations where massive amounts of data need to be extracted for further, do
Paging results is cumbersome and inefficient. In this next segment I'd like to talk about simple and complex sorting. Sorting, used effectively with the rows parameter can push relevant documents into the first page of results. Generally, you can sort on any indexed field but you can also utilize query boosting and functions to influence sort order. Missing Value Behavior  CLAIMS Direct is configured to return empty fields at the top when asc is the direction and the bottom when desc is the dire
In this first of a series of blogs about Solr result sets I'd like to talk about returned fields, both static and dynamic. Stored Fields Any field that is stored in Solr can be returned in the result set. The following table shows all available stored fields: Name Description Type Indexed ab_* all abstracts mixed: alexandria_text, alexandria_asian_text true ad filing date tint true an application number (tokenized) alexandria_token true anorig original, patent office format application number al