Prior-art retrieval is a crucial application of Patent Retrieval aimed to determine the novelty of a new invention. In this scenario patent authors require an exhaustive knowledge of all related patents and the search often involves multiple patent collections across the world, which do not share the same document structure or vocabulary. For this reason, despite of the numerous patent search applications already available, we propose in this paper PatentLight[1] a search tool that offers novel and flexible functionalities based on both fuzzy logic and IR to help users looking for relevant patents here represented as XML documents. We show some examples of the proposed search tool to inquiry the WIPO and USPTO collections in a flexible way.
Patent Information Retrieval (PIR) is a specialized branch of Information
Retrieval, which is aimed to support users, often professionals such as patent
attorneys or inventors, in retrieving patents that satisfy their information needs
[
In this scenario, a crucial application is prior-art retrieval [
Today patents are commonly available thanks to collections such as USPTO (United States Patent and Trade Office), EPO (European Patent Office) and WIPO (World Intellectual Property Organization).
Each collection contains several thousands of patents and continues to grow
up year by year; this situation poses a serious issue to patent professionals:
the cost of filing patents, defining claims and defending a claim of infringement
is increasing with time, making the process often too expensive, due to the
complexity in finding relevant patents. In 2010 the estimated cost to find relevant
patents was $1,500 per patent filing [
For the above reasons Patent Retrieval stimulates an increasing interest of the scientific community, and it is also considered a complex challenging task since the vocabulary used in patents is often obscure as it contains a lot of specialized or technical words. Often the obfuscation of content is intentional by writers who wish their patents difficult to retrieve; patents contain an intrinsic structure which often include description, claims or prior-art for instance and can be different in different collections. Finally typical queries in patent retrieval include a huge amount of words, often entire claims.
Most Patent Search tools available today are collection dependent. The most
known, Google Patents [
Most approaches presented in the literature, based on keyword extraction or query expansion techniques, proved to produce poor results (see Section 1.1).
Despite this fact, we believe that a traditional keyword-based analysis of XML patents joined with our flexible search approach can be promising with respect to both recall and precision.
The first experimental results produced by [
In this paper we present the development of our flexible tool PatentLight plus some examples obtained on more than one patent collection from different English language countries. Each document collection stores more or less the same information (i.e., abstract, author names, topic, description,etc.) but with different tree structures and tag vocabulary.
For this task our PatentLight tool [
The approach we propose in this paper relies on the recent outcomes of research in XML Retrieval, overcoming the weaknesses of traditional keywordbased approaches in the patents domain. 1.1
Patent IR evolved as a separate branch of IR showing characteristics that drastically reduce the effectiveness of traditional retrieval techniques.
In the last years, several approaches have been proposed, which can be broadly classified into three categories: – approaches based on query expansion techniques to reduce vocabulary mismatch; – approaches based on query extraction techniques to reduce verbose queries – approaches based on query translation techniques, which include approaches for querying multilingual patent collections, and approaches to query patents section by section instead as a whole document.
Because of the peculiarities of patent retrieval w.r.t traditional retrieval (as described in the Introduction), standard IR techniques such as query expansion proved not to work effectively with patent queries due to the presence of noisy terms in the typical queries.
In real practice however, most patent examiners formulate their queries for
invalidating claims by selecting high frequency terms from the query-patent claim
text, and hence the first approaches proposed in the literature [
Other approaches, [
Another important work is [
The last class of patent retrieval approaches tries to take advantage from the
multilinguality of most patent collections, which means that the same patent
can be stored in more than one language. Most works are based on natural
language processing (NLP) approaches [
Finally a nice survey on users issues and expectations associated to Patent
Retrieval is [
FleXy: a Flexible XML Query language
In [
A patent search application based on FleXy has been proposed in [
In PatentLight the structure-based constraints of Flexy named below and near, and the content-based flexible constraint around where employed. In this section we introduce the constraint similar which applies on tag names, and we show how the combination of content-based and structure-based evaluation of results can improve the effectiveness of PatentLight. Here below a short explanation of the above flexible constraints is given. 2.1
A short description of below, near and around The constraint below retrieves the fragments of an XML document (in this case a patent) that are closer to the path required by the user’s query. The syntax of the below constraint follows the standard XQuery axis syntax, and it is specified as: c/below::t, where c is the context node, and t is the target node. The best retrieved path is the one in which t is direct child of c. Others paths, those in which t is simply descendant of c, will be retrieved but ranked in a lower position w.r.t. the best one. To create the list of results we compute a path relevance 1 degree for each retrived fragment, wc,t, computed as wc,t = |desc arc(c,t)| where desc arc(c,t) is a function that returns the set of descending arcs from c to t if and only if t is a descendant node of c.
The flexible constraint near retrieves elements that are connected to the context node by any path (not only the descendant relationship), i.e., also ancestor and sibling elements are evaluated. For the near constraint, the scoring func1 tion is defined as: wc,t = |arcs(c,t)| where arcs(c,t) is the function that returns the set of arcs that connects the context node c to the target node t following the shortest path. The near constraint syntax is: c/near::t, where, as for the constraint below, c is the context node and t is the target node.
Around is a flexible constraint which applies to numerical data and its evaluation function is formally defined as the membership function of a fuzzy subset on the considered numerical domain; the membership function expresses the similarity between the retrieved values and the numerical value requested by the user. In the patent domain, the constraint around is defined to the aim of analyzing date contents.
tag-date is the attribute having the date value that has to be evaluated, x is the date value of the examined patent, and b is the date written by the user in his/her query.
The evaluation function of the around constraint produces a score in the
interval [
The similar constraint to assess tag similarity
Similar is a flexible constraint defined on tag names that allows to retrieve
fragments with a target node name similar to the name used in the user query.
Similar is defined as a function whose FleXy syntax is ’similar(x)’, where x
is the node name we are looking for. The evaluation of the function returns a
list of XML fragments with a target node name similar to x where the similarity
1
degree is number in the interval [
Fig. 1 shows how the similar constraint works on two document fragments, the left one from the USPTO collection, the right one from the WIPO collection.
Although the query Q1 is looking for a fragment containing the tag name last-name, the system is able to retrieve also the patent fragment containing the tag name orgname with a similarity degree of 0.16.
Note that traditional XML query languages would not retrieve the second fragment in the same situation.
Moreover, to avoid the retrieval of unuseful fragments we can set a threshold value for ws. At present we do not evaluate synonyms since this option would include the use of a dictionary or an ontology.
Q1: applicants//similar(Last-Name)[text() contain text «Smith»]
US-Patent-Grant
US-Bibliographic-Data-Grant
Parties
Applicants
Applicant
AddressBook ws=1
Last-Name Smith wo-patent-document parties applicants applicant sequence ws=0.16 addressbook orgname Smith
When a query involves more that one flexible constraint, for instance a flexible axis and the similar constraint for the target node name, the overall relevance degree woc,t is computed as a combination between the two scores, wc,t and ws. In principle we prefer a conservative evaluation and therefore we use woc,t = min(wc,t, ws) but different solutions could be tested. 3
How the flexible constraints works in patent search
This section explains how the flexible constraints introduced in the previous
section are used to exploit the patent search task. In particular, the proposed
approach has been defined and tested in [
In any case it was noted that also EPO and WIPO patent documents show more or less the same structure of USPTO, even if with different tags. In this paper we use the similar constraint to extend our tests to a cross collections composed by USPTO and WIPO.
The proposed approach allows users to search patents using the formulation of a keyword based query, in addition the user can choose the similar tag option to extend the search also to tag names similar to the standard ones.
Subsection 3.1 describes how search results are categorized according to
keyword-based queries, while subsection 3.2 shows how the similar constraint
evaluation changes the original approach in [
An important functionality of FlexSearch [
By analyzing the patents in the USPTO collection, four categories were
identified in [
The same categories are here adopted for the cross-collection due to the structural similarity between the WIPO and the USPTO collections.
Formally, let E be the set of XML elements defined in a patent collection, and Cat be the set of categories, then one or more elements ei ∈ E are mapped into each category c ∈ Cat, i.e {e1, ..., em} → c. In the application the four identified categories along with the corresponding XML elements are: People (the associated elements are Applicants, Agents, Assignee, Examiners), Title (title), Description (Description), Claims (claims).
A user specified keyword based query (here below ”query terms”) is automatically rewritten into four distinct FleXy queries, one for each of the four categories. The structure of each query is predefined in order to search the query terms in pre-established elements as follows:
The proposed query translation process uses the near constraint in the FleXy query related to the category People, and the context node is the tag applicants; this means that we assume that the applicant role (i.e., the inventor) has more importance in the search with respect to the other roles defined in the patent such as Agent, Examiner. This choice has been motivated to be coherent with respect to standard patent search applications (i.e., Google Patents, PatentSearcher, etc.).
In case of user queries formulated by the standard textual search area, where a user writes a name of a person it is supposed that he/she is interested in finding inventors of patents. However, it is important to notice that by the approach also patents containing the name with a different role will be retrieved. 3.2
The evaluation of similar in PatentLight In this work we improve the PatentLight engine by introducing the possibility to retrieve also fragments with different tag names w.r.t. those expressed by the query.
This feature is useful when we inquiry collections of which we roughly know the internal structure (tag names and node positions) or when we want to apply the same query to a composition of patent collections that contain more or less the same information stored in different tag nodes (for instance the node orgname instead of the node Last-Name).
In the engine, if the user chose to add the similar tag evaluation (in the prototype the user just flags the option in the interface), the set of FleXy queries would change accordingly as shown below:
applicants/near::similar(Last-Name)[ text() contains text "query terms"]
similar(claims)/below::claim-text[ text() contains text "query terms"] claims/below::similar(claim-text)[ text() contains text "query terms"]
Note that the similar constraint is applied to the relevant nodes of each query and therefore the categories People and Claims will contain two queries instead of one.
The retrieved fragments are ranked according to two values: the degree of
structural relevance based on the evaluation of FleXy constraints (woc,t), and the
degree of relevance obtained by the full-text scoring of the XQuery Full Text
language (the prototype in [
PatentLight development and preliminary evaluation Aim of this work was to evaluate the retrieval capabilities of the flexible language FleXy when applied to patent collections, with particular emphasis on the similar constraint able to execute the same queries on different tag vocabularies.
For this reason PatentLight has been developed on top of the BaseX system
[
INDEX INDEXING
XML PATENTS COLLECTION
DICTIONARY
BASEX QUERY ENGINE RANKING
USER
RESULTS
The main module is the BaseX Query engine, which is in charge of the collection indexing process and querying. During the querying process each class query is executed independently with the support of a dictionary for the similar constraint evaluation. One of the main characteristics of the approach is that each query produces a set of results, one for each class (People, Title, Descriptions, Claims), which are not merged. For each result two scores are computed, the overall relevance degree wo (see Section 2.2) and the degree of relevance obtained by the full-text scoring of the XQuery Full Text language as implemented by BaseX. The ranking module reorganizes each class of results by first considering wo and next the degree of content-based relevance as explained in Section 2.2.
To the aim of exploring the usefulness of FleXy on the patent collection we performed several different searches, the most interesting are shown in Figure 3. For each search we started with a very simple query, then we refined it with one more keyword or in one case two. In most cases three keywords were enough to achieve satisfactory results, i.e., a not so large number of retrieved results in each class without loosing any of the relevant documents found with the less specific query.
In this set of trials we wanted to compare PatentLight and Google Patents w.r.t the prior-art retrieval task. In this task users really need to find the highest number of relevant patents as possible; in our preliminary evaluations we have carefully checked the first 50 results for each search, and compared them with the results provided by Google Patents for the same query. Figure 3 shows the number of retrieved patents for each query, in parentheses the number of relevant patents found within the first 50 results. PatentLight presents each query results divided into four classes (i.e., People, Title, Claims, and Descriptions) depending
Q1: «Bell»
compressor»
Patent Light People Title 64(0) 8(1) 1(1) 6(0) 0 0 0 0 0 0 0 5(1) 1(1) 215(1) 2 (2) 0 0 279(1) 25(2) 2(2) 346(1) 0 Claims 98(2) 2(2) 453(4) 70(2) 0 0 1770(2) 207(2) 5(2) 2730(1) 12(4)
1110(2) 341(2) 46(1) 0 9487(2) 2159(2) 139(1) 8312(1) 910(2)
Google Patents 4(0) 0 113(2) 98(2) 40(0) 0 147(2) 114(0) 50(1) 199(1) 110(4) on the document section where the query keywords were found, while Google Patents has no classification system and results appear all together in a single list.
As shown in Figure 3, in most cases PatentLight retrieved the same number or a higher number of relevant patents w.r.t. Google Patents within the first 50 results. Moreover the results classification of PatentLight, with in average short lists, was really useful to easily find the relevant documents and discard the unuseful classes as a whole.
See for instance the first query. In this example we were looking for patents about kettle bells. Google Patents found only 4 patents, none relevant. PatentLight found 5 patents with the word ”bell” in the title, one was relevant, 64 with ”bell” as person name and hence it was not necessary to check this class of results, 98 with ”bell” in the claims sections and 964 in the descriptions. The mere addition of the word ”kettle” drastically reduced the number of retrieved results also in the sections ”claims” and ”description”, but the relevant documents were found anyway.
Conclusions and Future Work In this paper we have described the development and preliminary evaluation of PatentLight on a collection of English patents with dishomogeneous structures. The peculiarity of PatentLight is to allow users to specify flexible constraints in their queries. Future work will study the evaluation of synonyms for the tag names used in the queries of the four categories.