An Elasticsearch-based patent retrieval statistical engine

Abstract

The application discloses a kind of patent retrieval statistical engine based on Elasticsearch, comprising: standard request parameter acquisition module, for obtaining standard request parameter;Elasticsearch query statement conversion module, for converting standard request parameter into Elasticsearch query statement;Patent retrieval module, for carrying out patent retrieval in Elasticsearch using Elasticsearch query statement;Standard response result obtains module, for converting Elasticsearch retrieval result into standard response result output;The application defines an interface specification of patent retrieval statistics, implements patent retrieval statistical engine based on Elasticsearch, can handle a variety of patent retrieval statistical needs including complex condition retrieval, multidimensional data statistical analysis, patent deduplication document merging and asynchronous patent retrieval.

Description

Technical Field

[0001] This invention belongs to the field of search engines and statistical analysis, specifically relating to a patent search and statistical engine based on Elasticsearch. Background Technology

[0002] With the rapid development of technology in all fields of human society, countless intellectual achievements have emerged. At the same time, people's awareness of protecting the intellectual property rights of this knowledge is also increasing. As a form of intellectual property, there are currently hundreds of millions of patents worldwide, and these massive patents contain high value. Therefore, how to better extract and search information from these patents is fundamental to realizing the value of patents. With the improvement of the level of informatization in the field of intellectual property, patent data management is no longer the main issue. Currently, multi-dimensional retrieval of patent data has become a key technology and core capability for solving patent information retrieval.

[0003] In the field of patent search, users often need to perform complex combinations of conditions to search for various attributes of a patent. Simultaneously, since a single patent application document may correspond to one or more patent publication documents, it is sometimes necessary to deduplicate multiple documents of the same patent application. Furthermore, there may be a need to meet non-real-time data statistical analysis requirements that consume significant resources and time. Existing patent search engines, such as Elasticsearch, cannot support complex conditional searches, patent deduplication and document merging, multidimensional data statistical analysis, and asynchronous patent searches. Summary of the Invention

[0004] To address the aforementioned problems in existing technologies, this invention provides a patent retrieval and statistics engine based on Elasticsearch. The technical problem to be solved by this invention is achieved through the following technical solution:

[0005] An Elasticsearch-based patent search and statistics engine, comprising:

[0006] A standard request parameter acquisition module is used to acquire standard request parameters; wherein, the standard request parameters represent the attribute information of the patent search statistical requirements to be processed; the patent search statistical requirements include complex condition search, multidimensional data statistical analysis, patent deduplication document merging, and asynchronous patent search; the structure of the standard request parameters is a predefined standard data structure for the search input;

[0007] The Elasticsearch query conversion module is used to convert the standard request parameters into Elasticsearch query statements by utilizing the logical correspondence between standard request parameters and Elasticsearch query statements.

[0008] The patent search module is used to perform patent searches in Elasticsearch using the Elasticsearch query statements and obtain Elasticsearch search results.

[0009] The standard response result acquisition module is used to convert the Elasticsearch search results into standard response result output; wherein, the structure of the standard response result is a predefined standard data structure for the search output.

[0010] The beneficial effects of this invention are:

[0011] This invention, based on Elasticsearch, defines an interface specification for patent retrieval and statistics, implementing an Elasticsearch-based patent retrieval and statistics engine. The engine includes a standard request parameter acquisition module, an Elasticsearch query statement conversion module, a patent retrieval module, and a standard response result acquisition module. Specifically, the standard request parameter acquisition module obtains standard request parameters; the Elasticsearch query statement conversion module converts the standard request parameters into Elasticsearch query statements using the logical correspondence between the standard request parameters and Elasticsearch query statements; the patent retrieval module performs patent searches in Elasticsearch using the Elasticsearch query statements to obtain Elasticsearch search results; and the standard response result acquisition module converts the Elasticsearch search results into standard response results for output. The standard request parameters represent the attribute information of the patent retrieval and statistics requirements to be processed. These requirements include complex condition retrieval, multidimensional data statistical analysis, patent deduplication and document merging, and asynchronous patent retrieval. The structure of the standard request parameters is a predefined standard data structure for the retrieval input; and the structure of the standard response results is a predefined standard data structure for the retrieval output. As can be seen, the patent retrieval and statistics engine based on Elasticsearch in this embodiment of the invention establishes standards for patent retrieval and statistics by defining standard request parameters and standard response results. It can realize various functions such as complex condition retrieval, multidimensional data statistical analysis, patent deduplication and document merging, and asynchronous patent retrieval based on Elasticsearch, which can meet various needs in the existing patent retrieval and statistical analysis field. At the same time, it has corresponding standards and supports extension and optimization, providing good technical support for patent retrieval and statistical analysis. Attached Figure Description

[0012] Figure 1This is a schematic diagram of the structure of a patent retrieval and statistics engine based on Elasticsearch, provided in an embodiment of the present invention.

[0013] Figure 2 This is a schematic diagram of the processing flow of the patent retrieval and statistics engine based on Elasticsearch provided in an embodiment of the present invention;

[0014] Figure 3 This is a schematic diagram illustrating the logical correspondence between standard request parameters and Elasticsearch query statements in an embodiment of the present invention.

[0015] Figure 4 This is a schematic diagram illustrating the process of the patent retrieval module using Elasticsearch query statements to perform patent retrieval in Elasticsearch in an embodiment of the present invention.

[0016] Figure 5 This is a schematic diagram illustrating the logical correspondence between the actual patent search results and the standard response results in an embodiment of the present invention.

[0017] Figure 6 This is a flowchart illustrating the pre-defined patent search expression statement conversion method in an embodiment of the present invention.

[0018] Figure 7 This is a schematic diagram of the algorithm flow of the next function provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] To meet the diverse needs in the field of patent retrieval and statistical analysis, such as complex conditional retrieval, patent deduplication and document merging, multidimensional data statistical analysis, and asynchronous patent retrieval, this invention provides a patent retrieval and statistical engine based on Elasticsearch.

[0021] Please see Figure 1 The diagram shows the structure of a patent retrieval and statistics engine based on Elasticsearch. Figure 2The diagram shows the processing flow of the patent retrieval and statistics engine based on Elasticsearch. The patent retrieval and statistics engine based on Elasticsearch in this embodiment of the invention may include a standard request parameter acquisition module, an Elasticsearch query statement conversion module, a patent retrieval module, and a standard response result acquisition module.

[0022] The function of each module is explained below.

[0023] (I) Standard Request Parameter Acquisition Module

[0024] The standard request parameter acquisition module is used to obtain standard request parameters.

[0025] Among them, the standard request parameters represent the attribute information of the patent search statistical requirements to be processed; the patent search statistical requirements include complex condition search, multidimensional data statistical analysis, patent deduplication document merging and asynchronous patent search; of course, the patent search statistical requirements in the embodiments of the present invention are not limited to the above.

[0026] The standard request parameters are structured using a predefined standard data structure for the retrieval input.

[0027] Specifically, in order to encapsulate the complex Elasticsearch retrieval function into a concise and standard patent retrieval function, this embodiment of the invention predefines a standard data structure for the retrieval input, which serves as the structure of the standard request parameters for the patent retrieval statistics engine.

[0028] In one optional implementation, the structure of the standard request parameters includes:

[0029] The index name is indexName, the patent search expression is searchExpr, the sorting attribute is sortField, the data offset is offset, the data limit is limit, the statistics field list is statisticsFieldList, the deduplication field is collapseField, the asynchronous search ID is asyncSearchId, and the asynchronous search requirement is async; among them, the sorting attribute sortField includes the sorting field name fieldName and the sorting direction reverseOrder; the value of the asynchronous search requirement async indicates whether to perform asynchronous search.

[0030] Please refer to Table 1 for the structure of the standard request parameters.

[0031] Table 1 Structure of Standard Request Parameters

[0032]

[0033] As can be seen, the standard request parameters contain several attributes. `indexName` represents the index name. Since Elasticsearch contains multiple indexes, `indexName` specifies one or more Elasticsearch indexes used for retrieval. `searchExpr` represents the patent search expression used to retrieve patents in Elasticsearch. For example, a `searchExpr` could be `title = neural network AND face recognition`. `fieldName` represents the sorting field name. For example, if `fieldName` is `application date`, the patents will be sorted by application date. `reverseOrder` represents the sorting direction. For example, if `fieldName` is `application date`, the sorting direction is sequential (from first to last) and reverse (from last to first). `Offset` is a natural number specifying how many patents to skip when returning results. `Limit` is also a natural number specifying the maximum number of patents returned, i.e., how many patents are displayed per page when paginated. `statisticsFieldList` represents a list of statistical fields containing multiple `statisticsField` fields. Each field represents an independent statistic, which can be a single-level dimension or a multi-level dimension composed of multiple single-level dimensions. For example, a `statisticsFieldList` could be: `["Application Year, Patent Category", "Country"]`, where `Application Year`, `Patent Category`, and `Country` are all statistical fields. `Application Year` and `Patent Category` are independent statistics, and `Country` is also an independent statistic. `Application Year` and `Patent Category` are multi-level dimensions, meaning that the number of patents is first counted by application year, and then by patent category within each application year. `Country`, on the other hand, is a single-level dimension, meaning that the number of patents is counted by country. The `collapseField` represents a deduplication field that allows retrieved patents to be deduplicated, retaining only one patent text. For example, `collapseField` could be the application number. The `asyncSearchId` represents the asynchronous search ID, used as search input. The value of `collapseField` can also be empty, indicating that no asynchronous search results are retrieved. If the value of `collapseField` is not empty, the asynchronous search ID is used as a result extraction credential to retrieve the response result of a specific asynchronous search. When the value of Async is true, it indicates that asynchronous retrieval is required, which means that there is no need to wait for the return result. The return result will be obtained when needed later. When you expect to get the asynchronous retrieval result later, you need to provide the asynchronous retrieval number collapsedField to obtain it.

[0034] Understandably, the attributes such as searchExpr, sortField, statisticsFieldList, offset, limit, collapseField, asyncSearchId, and async in the standard request parameters reflect patent search and statistical needs such as complex conditional retrieval, multidimensional data statistical analysis, patent deduplication and document merging, and asynchronous patent retrieval.

[0035] The embodiments of this invention define standard request parameters in the form of standard data structures. The purpose is to encapsulate the specific retrieval and statistics logic based on Elasticsearch into a black box, so that the patent retrieval and statistics engine can provide a simple and unified application programming interface. In the future, functional expansion and customization can be carried out without refactoring the Elasticsearch engine.

[0036] (II) Elasticsearch Query Transformation Module

[0037] The Elasticsearch query conversion module is used to convert standard request parameters into Elasticsearch query statements by utilizing the logical correspondence between standard request parameters and Elasticsearch query statements.

[0038] To implement patent search and statistics based on Elasticsearch, standard request parameters need to be converted into Elasticsearch query statements that the search engine Elasticsearch can recognize and execute. The Elasticsearch query statements use the domain-specific language Query DSL in JSON format.

[0039] For the logical correspondence between standard request parameters and Elasticsearch query statements, please refer to [link / reference]. Figure 3 As shown. Figure 3 The left-hand box contains, from top to bottom, the attributes searchExpr, sortField, offset, limit, statisticsFieldList, and collapseField from the standard request parameters. Figure 3 The box on the right shows an example of an Elasticsearch query. From... Figure 3As can be seen, the `searchExpr` attribute in the standard request parameters corresponds to the `query` attribute in the Query DSL; the `sortField` attribute in the standard request parameters corresponds to the `sort` attribute in the Query DSL; the `offset` attribute in the standard request parameters corresponds to the `from` attribute in the Query DSL; the `limit` attribute in the standard request parameters corresponds to the `size` attribute in the Query DSL; the `statisticsFieldList` attribute in the standard request parameters corresponds to the `aggs` attribute in the Query DSL; and the `collapseField` attribute in the standard request parameters corresponds to both the `aggs` and `collapse` attributes in the Query DSL. Therefore, one attribute in the standard request parameters may affect multiple attributes in the Query DSL, such as the `collapseField` attribute; similarly, one attribute in the Query DSL may be affected by multiple attributes in the standard request parameters, such as the `aggs` attribute. Furthermore, since the Query DSL also has `source` and `track_total_hits` attributes in addition to the `query`, `sort`, `from`, `size`, `aggs`, and `collapse` attributes, these two attributes have no logical relationship with the attributes in the standard request parameters and need to be predefined. Specifically, in this embodiment of the invention, the value of source in Query DSL is defined as true, indicating that the original patent data needs to be obtained; the value of track_total_hits in Query DSL is defined as true, indicating that the total number of hit patents needs to be obtained.

[0040] In one optional implementation, the Elasticsearch query conversion module utilizes the logical correspondence between standard request parameters and Elasticsearch query statements to convert standard request parameters into Elasticsearch query statements. This process includes:

[0041] (1) Convert the value of searchExpr in the standard request parameters into an Elasticsearch query statement using the preset patented search expression statement conversion method, and assign it to the query property in the Query DSL;

[0042] For clarity, the process by which the Elasticsearch query statement conversion module converts the value of searchExpr in the standard request parameters into an Elasticsearch query statement using a pre-defined patented search expression statement conversion method will be explained in detail later.

[0043] (2) Convert the value of sortField in the standard request parameters to the format of sorting statement in Elasticsearch query statement and assign it to the sort property of Query DSL;

[0044] Specifically, you can directly extract the two attributes fieldName and reverseOrder from sortField and construct a statement in the following format:

[0045]

[0046] Here, fieldName is an attribute under sortField; order indicates sorting; desc indicates descending sorting; asc indicates ascending sorting, all of which have fixed parameter formats and will not be explained in detail here.

[0047] (3) Assign the value of offset in the standard request parameters to the from property in the Query DSL;

[0048] This step essentially assigns the source attribute value directly to the target attribute; the specific statements are not detailed here. The source attribute corresponds to the `offset` attribute in the standard request parameters, and the target attribute corresponds to the `from` attribute in the Query DSL.

[0049] (4) Assign the value of limit in the standard request parameters to the size property in the Query DSL;

[0050] This step essentially assigns the source attribute value directly to the target attribute; the specific statements are not detailed here. The source attribute corresponds to the `limit` attribute in the standard request parameters, and the target attribute corresponds to the `size` attribute in the Query DSL.

[0051] (5) For each statistic in the statisticsFieldList in the standard request parameters, based on the terms grouping aggregation function in Elasticsearch, convert the value corresponding to the statistic into the format of the aggregation query statement in the Elasticsearch query statement, construct the corresponding JSON object, and assign it to the aggs property of the Query DSL.

[0052] Step (5) may include:

[0053] For each statistic in the statisticsFieldList of the standard request parameters, if the statistic is a single-level dimension, the field value corresponding to the single-level dimension statistic is converted into the format of an Elasticsearch query statement using the terms grouping aggregation function in Elasticsearch, thus obtaining the Elasticsearch aggregation query statement corresponding to the single-level dimension statistic. Each item in statisticsFieldList is a statistics field, which represents an independent statistic.

[0054] For each statistic in the statisticsFieldList of the standard request parameters, if the statistic is a multi-level dimension, nest the Elasticsearch aggregation query statements obtained by using the terms grouping aggregation function in Elasticsearch for different single-level dimensions under the multi-level dimension statistic in sequence, and merge them to obtain the Elasticsearch aggregation query statement corresponding to the multi-level dimension statistic.

[0055] For each statistic, a JSON object is constructed using the statistic's field as the key and the corresponding Elasticsearch aggregation query statement as the value, and then assigned to the aggs property of the Query DSL.

[0056] To elaborate on the above, the statistical field name is the value of the `statisticsField`. When counting the number of patents based on the statistical field name, this embodiment of the invention uses the `terms` grouping aggregation function in Elasticsearch. For a single statistical field name, i.e., a single-level dimension, the resulting Elasticsearch aggregation query statement is:

[0057] {"terms":{"field":<statistical field name>}}

[0058] In this context, Terms and field are fixed parameter formats for the statement. Terms indicates that statistics are performed based on the word segmentation results of the field, and Field indicates the field itself.

[0059] When dealing with multi-level dimensional statistics, Elasticsearch aggregation queries at different levels can be nested sequentially and merged into a single Elasticsearch aggregation query to achieve multi-level dimensional statistics. For example, first grouping and aggregating by statistical field name 'a', then grouping and aggregating by statistical field name 'b', and then grouping and aggregating by statistical field name 'c', the final Elasticsearch aggregation query would look like this:

[0060] {"terms":{"field":"a"},"aggs":{"_subordinate aggregate":{"terms":{"field":"b"},"aggs":{"_subordinate aggregate":{"terms":{"field":"c"}}}}}}

[0061] In one optional implementation, if the standard request parameters contain a value of collapseField, for each statistic in statisticsFieldList in the standard request parameters, based on the terms grouping aggregation function in Elasticsearch, the value corresponding to the statistic is converted into the format of the aggregation query statement in the Elasticsearch query statement, the corresponding JSON object is constructed, and the value is assigned to the aggs property of the Query DSL. In the process, the cardinality aggregation function is also added to the Elasticsearch aggregation query statement corresponding to each single-level dimension to implement deduplication counting.

[0062] Specifically, if the standard request parameters specify a `collapseField` for deduplication, special logic needs to be added during aggregation to obtain the deduplicated count. This is achieved by adding a `cardinality` aggregation function to count deduplication, and this function needs to be added to each dimension. Therefore, assuming the deduplication field is `d`, the final Elasticsearch aggregation query becomes:

[0063] {"terms":{"field":"a"},"aggs":{"_deduplication count":{"cardinality":{"field":"d"}},"_lower-level aggregation":{"terms":{"field":"b"},"aggs":{"_deduplication count":{"cardinality":{"field":"d"}},"_lower-level aggregation":{"terms":{"field":"c"},"aggs":{"_deduplication count":{"cardinality":{"field":"d"}}}}}}}}}}

[0064] Since the statisticsFieldList attribute contains multiple independent statistics, for each statistic, a corresponding Elasticsearch aggregation query statement needs to be constructed. Finally, a JSON object is constructed with each statistical field as the key and the corresponding Elasticsearch aggregation query statement as the value, and it is assigned to the aggs attribute of the Query DSL. It can be understood that each statistic can be a single-level dimension or a multi-level dimension, and each statistic has a JSON object.

[0065] (6) Convert the value of collapseField in the standard request parameters into the format of the deduplication query statement in the Elasticsearch query statement, and assign it to the collapse attribute of the Query DSL.

[0066] To deduplicate the patent retrieval results, only the following statement needs to be constructed and assigned to the collapse attribute of the Query DSL:

[0067] {"field": <value of collapseField>}

[0068] In an optional implementation, after converting the value of collapseField in the standard request parameters into the format of the deduplication query statement in the Elasticsearch query statement and assigning it to the collapse attribute of the Query DSL, the Elasticsearch query statement conversion module is further used for:

[0069] Add a cardinality aggregation function to the obtained Elasticsearch deduplication query statement to perform deduplication counting on the patents that meet the retrieval conditions corresponding to the Elasticsearch deduplication query statement, so as to obtain the total number of deduplicated patents.

[0070] Specifically, to obtain the total number of deduplicated patents, the cardinality aggregation function also needs to be used to perform deduplication counting on the patents that meet the retrieval conditions. That is, based on the obtained Elasticsearch query statement above, a key-value pair (key-value) is added to the aggs attribute of the Query DSL, where the key is "_deduplication count" and the value is:

[0071] {"cardinality": {"field": <value of collapseField>}

[0072] Through the conversion processes described in (1) to (6) above, standard request parameters can be converted into Elasticsearch query statements. For details on the format of the Query DSL language, please refer to the relevant technical explanations. The format of each Elasticsearch query statement and the meaning of each parameter will not be explained in detail here.

[0073] (III) Patent Search Module

[0074] The patent search module is used to perform patent searches in Elasticsearch using Elasticsearch queries and obtain the Elasticsearch search results.

[0075] The search behavior of the patent search module is determined by three attributes in the standard request parameters: indexName, asyncSearchId, and async. Among them, indexName determines which index in Elasticsearch to search in, while asyncSearchId and async determine the asynchronous search behavior.

[0076] Please see Figure 4 In one optional implementation, the process by which the patent search module performs a patent search in Elasticsearch using Elasticsearch queries and obtains the Elasticsearch search results includes:

[0077] Step a1: Determine if the async parameter in the standard request is true; if yes, proceed to step a2; if no, proceed to step a6.

[0078] Here, `async` being true indicates asynchronous retrieval; otherwise, asynchronous retrieval is not performed.

[0079] Step a2: Determine if the asyncSearchId parameter in the standard request is empty; if not, proceed to step a3; if yes, proceed to step a4.

[0080] Step a2 indicates that an asynchronous search is required. If `asyncSearchId` is not empty at this point, it means it carries a previous asynchronous search ID. Since an asynchronous search is now being performed, the previous asynchronous search ID is invalid. Therefore, step a3 is executed to delete the search results corresponding to `asyncSearchId` in Elasticsearch, and then step a4 is executed to call the Elasticsearch asynchronous search interface. If `asyncSearchId` is empty at step a2, then step a4 is executed directly.

[0081] Step a3: Delete the search results corresponding to asyncSearchId in Elasticsearch; and then execute step a4.

[0082] Step a4: Call the Elasticsearch asynchronous retrieval interface;

[0083] Calling Elasticsearch's asynchronous search interface indicates that an asynchronous search has been initiated.

[0084] Step a5: Obtain the new asyncSearchId;

[0085] Specifically, step a5 assigns a new asynchronous search ID (asyncSearchId) to the asynchronous search in step a4 as a result retrieval credential. Since asynchronous search does not require waiting for the return result, but only retrieves the return result when needed later, this asyncSearchId is used to retrieve the corresponding asynchronous search result when the asynchronous search result is needed later.

[0086] Step a6: Determine if the asyncSearchId parameter in the standard request is empty; if yes, proceed to step a7; otherwise, proceed to step a9.

[0087] Step a6 indicates that asynchronous retrieval is not required. If asyncSearchId is empty at this point, step a7 is executed directly to call the Elasticsearch retrieval interface. If asyncSearchId is not empty, it indicates that it carries the result retrieval credentials for obtaining asynchronous retrieval results, and step a9 is executed according to the asyncSearchId.

[0088] Step a7: Call the Elasticsearch search interface;

[0089] Understandably, since asynchronous retrieval is not performed at this time, calling the Elasticsearch retrieval interface initiates a real-time retrieval.

[0090] Step a8: Obtain the actual patent search results;

[0091] In step a7, after calling the Elasticsearch search interface, the actual patent search results can be obtained, i.e., real-time search results.

[0092] Step a9: Obtain the search results corresponding to asyncSearchId in Elasticsearch; then proceed to step a10.

[0093] It is understandable that retrieving the search results corresponding to asyncSearchId in Elasticsearch is actually performing an asynchronous search.

[0094] Step a10: Determine whether the asynchronous retrieval has been completed; if yes, obtain the asynchronous retrieval status and execute step a8; if no, execute step a11.

[0095] If step a10 determines that the asynchronous search has been completed, the asynchronous search status is "successful," and then step a8 is executed. Executing step a8 to obtain the actual patent search result is essentially obtaining the result of the asynchronous search. If step a10 determines that the asynchronous search has not been completed, then step a11 is executed.

[0096] Step a11: Obtain the asynchronous retrieval status.

[0097] If the process proceeds from step a10 to step a11, the asynchronous retrieval status includes either failure or running.

[0098] See Figure 4 The dashed box portion in the diagram indicates that the final Elasticsearch search results in this embodiment of the invention may include three types: a first result, a second result, and a third result. Specifically, the asynchronous search state obtained in step a11 is considered the first result; the actual patent search result obtained after step a7 proceeds to step a8, which is the real-time search result, is considered the second result; and the actual patent search result obtained after step a10 proceeds to step a8, which is the asynchronous search result, is also considered the second result. Both of these search results return specific search content for the corresponding patent search expression, and therefore both belong to the actual patent search results; the new asyncSearchId obtained in step a5 is considered the third result.

[0099] The above steps involve four interactions with the Elasticsearch cluster, corresponding to four Elasticsearch interfaces: the retrieval interface mentioned in step a7 (POST / _search), the asynchronous retrieval interface mentioned in step a4 (POST / _async_search), the retrieval of asynchronous search results mentioned in step a9 (GET / _async_search / id), and the deletion of asynchronous search results mentioned in step a3 (DELETE / _async_search / id). The retrieval and asynchronous retrieval interfaces require the Query DSL from the converted Elasticsearch query statement as parameters, while the retrieval and deletion of asynchronous search results interfaces require the asyncSearchId attribute from the standard request parameters as parameters.

[0100] (iv) Standard Response Result Acquisition Module

[0101] The Standard Response Result Acquisition module is used to convert Elasticsearch search results into standard response result output.

[0102] The standard response result has a predefined standard data structure for the retrieval output.

[0103] Similarly, in order to encapsulate the complex Elasticsearch retrieval function into a concise and standard patent retrieval function, this embodiment of the invention also predefines a standard data structure for the retrieval output as the structure of the standard response result of the patent retrieval statistics engine.

[0104] In one optional implementation, the structure of the standard response result includes:

[0105] The database includes the patent document list (docList), hit count, duplicate hit count after Collapse, statistics (statisticsData), asynchronous search ID (asyncSearchId), and asynchronous search status (asyncSearchStatus).

[0106] Please refer to Table 2 for the structure of the standard response result. This can be understood in conjunction with the structure of the standard request parameters.

[0107] Table 2 Structure of Standard Response Results

[0108]

[0109]

[0110] Substructure 1 mentioned in Table 1 is a Map structure consisting of multiple key-value pairs, where:

[0111] a) The key is a string representing the name of the statistical field.

[0112] b) The value is a list of objects, representing the grouped statistical data corresponding to the statistical field name. Each object represents the statistical result corresponding to a single field value in the statistical field name. Its specific structure is shown in substructure 2 in Table 3.

[0113] Table 3 Detailed Structure of Substructure 2

[0114]

[0115] For example, regarding the `statisticFieldList` mentioned earlier: `["Application Year, Patent Category", "Country"]`, in the statistics for "Application Year, Patent Category", the application year is the higher-level dimension, and the individual field value corresponding to this statistical field name can be 2022, 2021, etc.; the patent category is the lower-level dimension, and the individual field value corresponding to this statistical field name can be invention, utility model, or design. Regarding the other statistical field, "Country", the individual field value corresponding to this statistical field name can be the United States, China, etc.

[0116] Similar to standard request parameters, this embodiment of the invention defines standard response results in the form of standard data structures. The purpose is to encapsulate the specific retrieval and statistical logic based on Elasticsearch into a black box, enabling the patent retrieval and statistical engine to provide a simple and unified application programming interface. Subsequent functional expansion and customization can be carried out without refactoring the Elasticsearch engine.

[0117] In one optional implementation, the process by which the standard response result acquisition module converts Elasticsearch search results into standard response result output includes:

[0118] ① If the Elasticsearch search result is in an asynchronous search state, assign the asynchronous search status to the asyncSearchStatus property in the standard response result and output the assigned standard response result;

[0119] If the Elasticsearch search result is the first result, then the asynchronous search status is directly assigned to the asyncSearchStatus property in the standard response result, and that result is returned.

[0120] ② If the Elasticsearch search results are actual patent search results, convert the actual patent search results into standard response results and output the obtained standard response results;

[0121] If the Elasticsearch search result is the second result, the actual patent search result is extracted and converted into a standard response result by utilizing the logical correspondence between the actual patent search result and the standard response result, and then the obtained standard response result is output.

[0122] For the logical correspondence between the actual patent search results and the standard response results, please refer to [link / reference needed]. Figure 5 As shown. Figure 5 The left box shows an example of actual patent search results. The right boxes, from top to bottom, represent the attributes docList, count, countAfterCollapse, and statisticsData from the standard response results. Figure 5 As can be seen, the docList attribute in the standard response result corresponds to the hits.hits attribute in the actual patent search result; the count attribute in the standard response result corresponds to the value attribute in the actual patent search result; and the countAfterCollapse and statisticsData attributes in the standard response result correspond to the aggregations attribute in the actual patent search result.

[0123] In one optional implementation, if the Elasticsearch search result is the actual patent search result, the actual patent search result is converted into a standard response result, and the obtained standard response result is output, including:

[0124] 1) Extract each item from the array corresponding to the hits.hits property of the actual patent search results, convert the source property of each extracted item into a Map object, and add it to the docList list in the standard response results in order;

[0125] Specifically, the `hits.hits` property of the Elasticsearch search results is an array, where each item represents a hit patent document. This step requires extracting each item, converting its `_source` property into a Map object, and adding it sequentially to the `docList` list.

[0126] 2) Assign the value of the value attribute of the actual patent search result to the count attribute in the standard response result;

[0127] This step essentially assigns the source attribute value directly to the target attribute. The source attribute corresponds to the `value` attribute of the actual patent search result, and the target attribute corresponds to the `count` attribute in the standard response result.

[0128] 3) Among the multiple key-value pairs contained in the aggregations attribute of the actual patent search results, determine the key corresponding to the deduplication count, and assign the value corresponding to the key to the countAfterCollapse attribute in the standard response result.

[0129] Specifically, the deduplication hit count (countAfterCollapse) needs to be extracted from the aggregations attribute within the actual patent search results. Aggregations consists of multiple key-value pairs. The key corresponding to the deduplication hit count corresponds to the key set in the previous introduction to the Elasticsearch query statement conversion module, "(6), convert the value of the collapseField in the standard request parameters into the format of the deduplication query statement in the Elasticsearch query statement and assign it to the collapse attribute of the Query DSL," namely, "_Deduplication Count". The value under the value corresponding to this key is the total number of patents after deduplication. This value is then assigned to the countAfterCollapse attribute of the standard response result.

[0130] 4) Extract the statistical results of each statisticsField from the statistical results contained in the aggregations attribute of the actual patent search results using the preset statistical result extraction and transformation method, and assign the values ​​to the statisticsData attribute in the standard response results.

[0131] Specifically, the `aggregations` property of the Elasticsearch search results contains the required statistical results in key-value pair format. The keys are the names of each statistical field in the `statisticsFieldList` property of the standard request parameters, i.e., each `statisticsField` in `statisticsFieldList`. The `buckets` property of the `statisticsField` value contains the statistical results corresponding to that `statisticsField`, which may include statistics across multiple dimensions.

[0132] The steps of the preset statistical result extraction and transformation method include:

[0133] Step b1: For each statisticsField, retrieve its corresponding buckets attribute, recursively execute step b2, match the converted object list with the statisticsField, construct a Map with the statisticsField as the key and the object list as the value, assign it to the statisticsData attribute of the standard response result, and end the process.

[0134] Step b2: Iterate through the buckets property, extract each value, define it as a bucket, and construct a corresponding empty object, define it as obj;

[0135] The structure of obj is referenced from substructure 2 mentioned earlier.

[0136] Step b3: Assign the value of key in bucket to the value attribute of obj, and assign the value of doc_count in bucket to the count attribute of obj;

[0137] Step b4: Assign the value of the "_deduplication count" property in the bucket to the countAfterCollapse property of obj;

[0138] In step b5, if the "_lower-level aggregate" attribute in the bucket is not empty, then retrieve the buckets attribute from the "_lower-level aggregate" attribute, recursively execute step b2, and finally assign the converted object list to the subLevel attribute of obj.

[0139] ③ If the Elasticsearch retrieval result has a new asyncSearchId, assign the new asyncSearchId to the asyncSearchId attribute in the standard response result and output the assigned standard response result.

[0140] If the Elasticsearch search result is a third result, simply assign the new asyncSearchId to the asyncSearchId attribute in the standard response result and return that result.

[0141] This completes the entire processing flow of the patent search and statistics engine based on Elasticsearch.

[0142] The following explains how the Elasticsearch query transformation module converts the value of `searchExpr` in a standard request parameter into an Elasticsearch query statement using a pre-defined proprietary search expression transformation method. Please refer to [link to documentation]. Figure 6 In one optional implementation, the value of searchExpr in the standard request parameters is converted into an Elasticsearch query statement using a preset patented search expression statement conversion method, including the following steps:

[0143] S61, using a pre-built word segmenter to parse the string corresponding to the patent search expression in searchExpr, and obtain multiple parsed words; wherein, the patent search expression and word segmenter in searchExpr are constructed based on a predefined extensible patent search expression syntax structure.

[0144] S62, based on the patent retrieval expression syntax structure, processes multiple word segments into a list of standard syntax nodes;

[0145] S63, Generate a standard syntax tree based on the list of standard syntax nodes;

[0146] S64 uses a pre-built syntax transformer to convert standard syntax trees into Elasticsearch query statements.

[0147] The following provides a detailed explanation of S61 to S64.

[0148] Regarding S61, this embodiment of the invention predefines an extensible patent search expression syntax structure. In one optional implementation, any patent search expression constructed based on the predefined extensible patent search expression syntax structure includes:

[0149] Field names, operators, and field values.

[0150] The field name represents the name of the search field for the patent. This means the field name refers to the bibliographical items, text content, or other content items appearing in the patent information. For example, the field name may include the application number, title, inventors, etc., and further examples will not be provided here. The field name format can include Chinese, English, and any characters such as symbols; however, the field name should not contain characters involved in operators. For example, the field name could be the patent title, AP, IPC-MAIN, etc.

[0151] Field values ​​include the search content for the field name; for example, if the goal is to retrieve patents whose titles contain the word "engine," then the field name would be "title," and the field value would be "engine." Field values ​​can be numbers, dates, single strings, and strings with wildcards, etc. For example, field values ​​could be "car," "comput*," or "20190101." Here, "car" is a single string; "20190101" is a date; and "comput*" is a string with wildcards, where "*" represents a wildcard character that can represent zero or more characters.

[0152] Operators represent operations performed on field names and field values, as well as operations performed on subexpressions within patent search expressions.

[0153] In this embodiment of the invention, the operators include at least the following eight types:

[0154] (1) Logical operators. For example, AND, OR, NOT, etc. Specifically, AND means that both search terms on both sides exist at the same time; OR means that at least one of the search terms on both sides appears; NOT means that the search terms following it are excluded.

[0155] (2) Truncation symbols. Examples include “*”, “?”, and “$”. The symbols within double quotes are example truncation symbols. Truncation symbols are used for fuzzy file searches. “*” is an infinite truncation symbol, used to replace zero, one, or more characters at the end of a word; “?” is often used in the middle of a word to replace a single character; “$” is used to replace zero or one character.

[0156] (3) Positional operators. For example, (w), (n), etc. Specifically, (W) means that the search terms on both sides must appear in the correct order, and no other words are allowed between the two search terms; only spaces or punctuation marks are allowed. (N) means that the positions of the search terms on both sides can be interchanged, and no other words are allowed between the two search terms, but spaces or punctuation marks are allowed.

[0157] (4) Same-sentence operator. For example, (s). Specifically, (s) means that the search terms being joined must appear in the same sentence, but does not restrict the relative order of the search terms being joined or the number of intervening terms.

[0158] (5) Same paragraph operator. For example, (p). Specifically, (p) means that the search terms being connected must appear in the same paragraph at the same time, but does not restrict the relative order of the search terms being connected or the number of intervening terms.

[0159] (6) Range search operators. For example, to, >, >=, <, <=, =, ==, etc. Specifically, == indicates a complete match of the content, and the meanings of the other range search operators are not explained.

[0160] (7) Special characters. Examples include "." and " / ". The symbols within double quotes are special characters in this example. Special characters have no actual meaning during retrieval and will be ignored.

[0161] (8) C-CETS characters. For example, %n, / HIGH, / LOW, / SEN, / FREC, etc. Specifically, the %n operator can be used to retrieve the frequency of each classification number. n takes a number greater than 1 and retrieves documents in which the classification number appears n times; / HIGH indicates that the classification number itself and the higher-level classification number in the search query are extended; / LOW indicates that the classification number itself and the lower-level classification number in the search query are extended; / SEN indicates that the position of the classification number is retrieved, and the position range of the classification number can be set; / FREC indicates that the total number of times the entire C-CETS classification number appears is retrieved.

[0162] For the specific meanings and usage rules of the above eight operators, please refer to the relevant technical explanations; they will not be explained in detail here.

[0163] Any of the above operators can connect field names and field values, either alone or in combination according to certain rules, to obtain a patent search expression. For example, the patent search expression "TI = Computer AND Specification = Computing Device" consists of two sub-expressions: "TI = Computer" and "Specification = Computing Device". Each sub-expression includes a field name, an operator, and a field value; the two sub-expressions are connected by the AND logical operator, indicating that the patent title must include the word "computer" and the patent specification must include the word "computing device". It can be understood that in this example, the field names in the two sub-expressions are TI and Specification, respectively; the field values ​​are Computer and Computing Device, respectively; and the operator is the logical operator AND.

[0164] It should be noted that the field names and operators in this embodiment of the invention are extensible. That is, they can be freely extended according to actual needs and are not limited to the above examples, thus making the patent retrieval expression syntax structure defined in this embodiment of the invention extensible.

[0165] This invention, after defining the above-described syntax structure of patent search expressions, can specifically construct a word segmenter for parsing patent search expressions within its specifications. The word segmenter works by using a custom set of whitespace characters, symbols, and keywords, as defined in this invention, to decompose the content of the string corresponding to the patent search expression into multiple word segments. Each resulting word segment does not possess logical meaning; it merely represents the basic unit after segmenting the string corresponding to the patent search expression.

[0166] The whitespace character set consists of multiple whitespace characters used for separation. In this embodiment of the invention, whitespace characters include space, carriage return, newline, and tab. A space is a single space; carriage return, newline, and tab are represented as \r, \n, and \t, respectively.

[0167] The symbol set consists of multiple symbols, encompassing various commonly used symbols, such as =, ==, >, >=, <, <=, (,), etc. Compared to the symbols used in field names and operators, the symbol set contains a wider range of symbols.

[0168] The keyword set consists of multiple keywords, each of which is complete and semantic. These keywords can be Chinese, English, or other characters, such as student, car, bag, and, or, not, to, etc.

[0169] Specifically, in S61, a pre-built tokenizer is used to parse the string corresponding to the patent search expression in searchExpr, resulting in multiple parsed tokens. This process includes:

[0170] Based on a predefined set of whitespace characters, symbols, and keywords, and using a predefined next function, the system retrieves the next word from the current position pointed to by the pointer in the string corresponding to the patent search expression, updates the pointer position, and repeats the process of retrieving the next word from the patent search expression until no more words can be retrieved, thus obtaining multiple words parsed from the patent search expression.

[0171] In this embodiment of the invention, a `next` function is provided to retrieve the next word from the position pointed to by the current pointer. The `next` function ignores whitespace characters. Each word can be of the type of symbol, keyword, or string; a string is any character or combination of characters other than those in the whitespace set, symbol set, and keyword set.

[0172] The above process can be combined Figure 7 Understanding includes the following steps:

[0173] Step c1: Based on the current position pointed to by the pointer, determine whether there are any unprocessed matching results in the previous matching results before the current position; if yes, proceed to step c2; if no, proceed to step c5.

[0174] At any given moment, the pointer points to the current position, which is the position to be processed in the patent search expression. Based on the current position, the previous matching result can be retrieved; this can be one or multiple matching results. Each matching result represents a portion of the string corresponding to the patent search expression, whose content, after reading, is confirmed to belong to any of the following types: whitespace, symbol, or keyword. For a matching result, it may be immediately determined as word segmentation or not, in which case it is a processed matching result; alternatively, because it is uncertain whether there are any related matching results, its word segmentation cannot be immediately determined and needs to be determined later, in which case the matching result is an unprocessed matching result. In other words, an unprocessed matching result indicates that the corresponding content has been confirmed to belong to any of the following types: whitespace, symbol, or keyword, but a word segmentation judgment result has not yet been obtained; the word segmentation judgment result is: either word segmentation or not word segmentation. For example, the unprocessed match result in the previous matching result was the keyword "I". The reason it was unprocessed was because the keyword set also contained the keyword "we". Therefore, without knowing the matching results of subsequent characters, the keyword "I" could not be immediately identified as a word.

[0175] Step c2: Obtain the unprocessed matching results from the previous step;

[0176] If there were multiple unprocessed matching results in the previous step, the one closest to the current position is retrieved.

[0177] Step c3: Determine if the previously unprocessed matching result is a blank character; if yes, proceed to step c1; if no, proceed to step c4.

[0178] Specifically, since whitespace is only used as a separator and has no actual meaning, if the previously unprocessed match result is a whitespace character, it cannot be determined as a word segment. Instead, it is treated as a processed match result, and the process returns to step c1 to find the next word segment. Understandably, the pointer will move to after the whitespace character before returning to step c1.

[0179] Step c4: Determine the previously unprocessed matching results as word segments;

[0180] Specifically, if the previously unprocessed matching result is not a whitespace character, it can be determined that it is a word segmentation.

[0181] Step c5 involves moving the pointer character by character to attempt to obtain the next matching result;

[0182] Specifically, the pointer moves character by character from the current position, checking at each stopping position whether the moved content belongs to any of the following types: whitespace, symbol, or keyword. If it does, the matching content is identified as a match result; otherwise, the pointer moves forward to continue checking. When a match result is identified, the stopping position of the pointer is the end position corresponding to that match result.

[0183] Step c6: Determine if the next matching result can be obtained; if not, proceed to step c7; if yes, proceed to step c8.

[0184] Step c7: Before attempting to obtain the next matching result, all remaining text after the current position pointed to by the pointer is determined as the word segmentation;

[0185] Specifically, if moving the pointer character by character fails to obtain the next matching result, then all remaining text after the current position pointed to by the pointer before attempting to obtain the next matching result will be determined as the word segmentation.

[0186] Step c8: Determine if there is text between the end position corresponding to the next matching result and the current position pointed to by the pointer before attempting to obtain the next matching result; if yes, proceed to step c9; if no, proceed to step c10.

[0187] Specifically, if moving the pointer character by character can obtain the next matching result, then the content between the end position corresponding to the next matching result and the current position pointed to by the pointer before trying to obtain the next matching result can be obtained to confirm whether the content is text.

[0188] Step c9: Determine the part of the text corresponding to the word segmentation and temporarily store the next matching result obtained;

[0189] Specifically, if there is text between the end position of the next matching result and the current position pointed to by the pointer before attempting to obtain the next matching result, then the part corresponding to that text is directly identified as a word, completing the word segmentation parsing for this time. At the same time, the obtained next matching result is temporarily stored for later determination of whether it is a word. At this point, it can be understood that the pointer points to the end position of the next matching result.

[0190] Step c10: Determine if the next matching result is a whitespace character; if yes, proceed to step c1; if no, proceed to step c11.

[0191] Specifically, if there is no text between the end position of the next matching result and the current position pointed to by the pointer before attempting to obtain the next matching result, it is necessary to determine whether the obtained next matching result is a whitespace character. If it is, it cannot be determined as a word segmentation, and it is treated as a processed matching result. The process returns to step c1 to find the next word segmentation. It can be understood that before returning to step c1, the pointer will move to after the whitespace character. If not, step c11 is executed.

[0192] Step c11: The next matching result obtained is determined as the word segmentation.

[0193] For S62, since the word segments obtained by the word segmenter do not reflect the syntax of the patent search expression, it is necessary to judge and process the word segments to convert all word segments into standard syntax nodes that conform to the grammatical structure of the patent search expression. S62 may include the following steps:

[0194] S621, obtain the next segment from the word segmenter; obtain the standard syntax node based on the segment, and determine whether the node is empty; if yes, end the process; otherwise, execute S622;

[0195] In this process, the next segment corresponding to the first execution is the first segment; the standard syntax node indicates that the content type belongs to any of the following: field name, operator, or field value; an empty node indicates that no next segment can be obtained from the segmenter. The process of obtaining the standard syntax node based on this segment is explained later. If the node is empty, it means that all segmentations have been processed, and the list of standard syntax nodes has been built, so the process ends. If the node is not empty, it means that further processing is needed, so S622 is executed.

[0196] S622, determine whether the standard syntax node is not a left square bracket; if yes, execute S623; if no, execute S624;

[0197] S623, add the standard syntax node to the list of standard syntax nodes, and repeat S621;

[0198] Specifically, in patent search expressions, when searching for strings, they are usually limited by left and right square brackets. For example, when searching for a range of dates or quantities, such as searching for patents with application dates from 20220901 to 20220916, the patent search expression would be APD:[20220901TO 20220916], where APD is an abbreviation for the application date field name. Therefore, for each standard syntax node, it is necessary to first determine whether it is a left square bracket. If the standard syntax node is not a left square bracket, it means that it can be used as a separate standard syntax node, and therefore, it can be added to the list of standard syntax nodes. If the standard syntax node is a left square bracket, it means that it cannot be used as a separate standard syntax node, and the content between the left and right square brackets needs to be determined.

[0199] S624, obtain the next word from the word segmenter; obtain the standard syntax node based on the word segmentation; and determine whether the node is empty or the node content is not a string; if yes, throw an exception and terminate the process; if no, execute S625;

[0200] Specifically, if a node is empty, the process needs to end. If the node content is not a string, it does not conform to the normal definition of the left and right square brackets in the patent search expression, indicating an error. If either of these situations occurs, the process needs to be aborted. If the node is not empty and the node content is a string, the status is normal, and S625 needs to be executed.

[0201] S625, obtain the next segment from the word segmenter; obtain the standard syntax node based on the segment; and determine whether the node is empty or the node content is not the character "to"; if yes, throw an exception and terminate the process; if no, execute S626;

[0202] Specifically, when performing string searches using the left and right square brackets in the patent search expression, the string should contain the character "to" according to the regulations. If the node content is not the character "to", an error has occurred. If the node is not empty and its content is the character "to", the status is normal, and execution of S626 should continue. It should be noted that the character "to" in this embodiment is not case-sensitive.

[0203] S626, obtain the next word from the word segmenter; obtain the standard syntax node based on the word segmentation; and determine whether the node is empty or the node content is not a string; if yes, throw an exception and terminate the process; if no, execute S627;

[0204] Understandably, S624 is used to determine the content between the left square bracket and the character "to", while S626 is used to determine the content between the character "to" and the right square bracket, and the execution methods are similar.

[0205] S627, obtain the next word from the word segmenter; obtain the standard syntax node based on the word segmentation; and determine whether the node is empty or the node content is not a right square bracket; if yes, throw an exception and terminate the process; if no, execute S628;

[0206] Specifically, if a node is empty or its content is not a right square bracket, it indicates an error has occurred; if a node is not empty and its content is a right square bracket, it indicates a normal status and that all content between the left and right square brackets has been found.

[0207] S628, merge all the previously obtained standard syntax nodes into a single string syntax node in order, add it to the list of standard syntax nodes, and then repeat S621;

[0208] Specifically, all standard syntax nodes obtained in S621 to S627 are merged sequentially into a single string syntax node, where the string syntax node is a special type of standard syntax node. After adding the string syntax node to the list of standard syntax nodes, S621 is repeated until S621 obtains the next segment from the tokenizer. When obtaining a standard syntax node based on this segment, if the node is empty, the process ends, resulting in the final list of standard syntax nodes.

[0209] The process of obtaining standard grammar nodes based on this word segmentation includes the following steps:

[0210] Step d1: If the type of the word segment is not a symbol, then directly wrap the word segment into a regular standard syntax node; otherwise, proceed to step d2.

[0211] Step d2: If the word segment is not enclosed in English double quotes, then directly wrap the word segment into a regular standard syntax node; otherwise, proceed to step d3.

[0212] Step d3: Determine if the next matching double quote can be found; if not, throw an exception; if yes, proceed to step d4.

[0213] Step d4: Wrap the content between the two double quotes into a string syntax node.

[0214] In step d1, the symbols are the elements in the symbol set. In step d3, the next matching double quote is the one following a pair of double quotes in English form; ordinary standard syntax nodes are in contrast to special standard syntax nodes such as string syntax nodes.

[0215] For S63, the semantics and precedence of different operators need to be considered. The generated standard syntax tree has only one final root node, each node may have 0 to 2 child nodes, all leaf nodes are field names or field values, and all internal nodes are operators. S63 includes:

[0216] S631, define a stack valueStack for storing field name nodes, field value nodes, or subexpression root nodes, and define a stack symbolStack for storing operator nodes.

[0217] The initial states of valueStack and symbolStack are empty.

[0218] S632, define a pointer i that points to the position of the currently pending node in nodeList;

[0219] Here, nodeList represents a list of standard syntax nodes.

[0220] S633, if i is greater than or equal to the total number of nodes in nodeList, execute S634; otherwise, execute S635.

[0221] Specifically, if i is greater than or equal to the total number of nodes in nodeList, it means that all nodes have been processed.

[0222] S634, take an operator node a from the current symbolStack, and take two nodes b and c from the current valueStack. Use node a as the operator, node b as the left child node, and node c as the right child node to construct a binary operation node. Then push the binary operation node into the current valueStack. Repeat this step until the current symbolStack is empty, and execute S6312.

[0223] Here, a, b, and c only represent the node's identifier and are not used to limit the node's content.

[0224] S635, retrieve the node n at position i from nodeList and increment i by 1; if the tokenization type of node n is string, execute S636; otherwise, execute S637;

[0225] S636, If the tokenization type of the previous node of node n is also string, push node n and an AND operator into the current valueStack, and then repeat S633; If the tokenization type of the previous node of node n is not string, push node n into the current valueStack, and then repeat S633.

[0226] S637, If the current symbolStack is empty, push node n into the current symbolStack, and then repeat S633; otherwise, execute S638.

[0227] S638, if node n is a left parenthesis, push node n onto the current symbolStack, and then repeat S633; otherwise, execute S639.

[0228] S639, check the priority of the current symbolStack top node t. If the priority of node n is less than or equal to the priority of the top node t, execute S6310; otherwise, execute S6311. The priority of each operator is predefined.

[0229] S6310, remove the top node t from the stack, then remove two nodes e and f from the current valueStack. Using the top node t as the operator, node e as the left child node, and node f as the right child node, construct a binary operation node from these three nodes, then push the binary operation node into the current valueStack, and then repeat S639.

[0230] Similarly, t, e, and f are merely symbols and are not used to define the content of a node.

[0231] S6311, push node n into the current symbolStack, and then repeat S633;

[0232] S6312: Determine if there is only one node remaining in the current valueStack. If so, use the remaining node as the root node of the final generated standard syntax tree; otherwise, throw an exception and stop the process.

[0233] It is understandable that after obtaining the root node of the final generated standard syntax tree, the standard syntax tree can be obtained based on the known relationships between the nodes.

[0234] The standard syntax tree generated in S63 contains the logical semantics of the entire patent search expression. This semantics is universal and independent of specific data formats, data storage methods, and data query engines. Therefore, it can adapt to various data formats, data storage methods, data query engines, and heterogeneous searches.

[0235] For details on the specific processing procedures of each step in S63, please refer to the relevant technical explanations; they will not be described in detail here.

[0236] In this embodiment of the invention, the operator precedence is predefined, such as 0, 50, 70, etc., which will not be described in detail here.

[0237] For S64, one possible implementation may include the following steps:

[0238] S641, obtain the currently processed root node r, and execute S642;

[0239] During the initial execution, the root node r being processed is the root node of the standard syntax tree. It can be understood that after the initial execution, the root node r being processed can be a root node at a level below the root node of the standard syntax tree.

[0240] S642, if the root node r being processed is not a binary operation node, throw an exception and abort the process; otherwise, execute S643.

[0241] Understandably, the root node r currently being processed should be a binary operation node under normal circumstances.

[0242] S643, if the operator of the currently processed root node r is a logical operator, then execute S644; otherwise, execute S647.

[0243] S644, retrieve the root node r-left of the left subtree of the currently processed root node r, and recursively execute S642 to obtain the left clause left of the currently processed root node r;

[0244] It is understandable that when S642 is recursively executed, the root node r-left of the left subtree of the currently processed root node r is used as the currently processed root node r.

[0245] S645, retrieve the root node r-right of the right subtree of the currently processed root node r, and recursively execute S642 to obtain the right clause right of the currently processed root node r;

[0246] It is understandable that when S642 is recursively executed, the root node r-right of the right subtree of the currently processed root node r is used as the currently processed root node r.

[0247] Please refer to relevant technical explanations for the concepts of left and right subtrees; they will not be explained in detail here.

[0248] S646, based on the logical operator of the currently processed root node r, merge its left clause and right clause into a single Elasticsearch boolean query statement; and return S643;

[0249] Please refer to relevant technical explanations for the concepts of left clause and right clause; they will not be explained in detail here.

[0250] S647: The left subtree of the currently processed root node r is used as the field name k, and the right subtree is used as the field value v. Based on the operator op of the currently processed root node r, k and v are converted into a query statement in Elasticsearch according to the conversion algorithm corresponding to the operator op; and S643 is returned.

[0251] It is understandable that when execution reaches S647, there must exist a left subtree of the currently processed root node r as the field name k and the right subtree as the field value v.

[0252] The conversion algorithms for different operators (op) have different logic. For example, when the operator (op) of the currently processed root node r matches the symbol "=", k and v are converted into a query statement in Elasticsearch according to the corresponding conversion algorithm based on the operator (op) of the currently processed root node r, including the following steps:

[0253] Step g1: If the tokenization type of v is string, then execute step g2; otherwise, execute step g3.

[0254] Step g2: Based on the content of v, package k and v into a corresponding Elasticsearch query statement, and end the process;

[0255] Elasticsearch query statements include Elasticsearch term query statements, range query statements, or wildcard query statements. For specific concepts of these query statements, please refer to the relevant technical explanations, which will not be explained here.

[0256] In step g3, if the operator of v is not a logical operator, an exception is thrown and the process ends; otherwise, step g4 is executed.

[0257] Step g4: Extract the root node v-left of the left subtree of v, recursively execute step g1, and obtain the left clause left of v;

[0258] Step g5: Extract the root node v-right of the right subtree of v, recursively execute step g1, and obtain the right clause right of v.

[0259] Step g6: Based on the logical operators of v, merge the left clause (left) and right clause (right) of v into a single Elasticsearch boolean query statement, and end the process.

[0260] Using steps S61 to S64 above, the value of `searchExpr` in the standard request parameters can be converted into an Elasticsearch query statement. Specific examples will not be provided here for further explanation.

[0261] To facilitate understanding of the processing of the patent retrieval and statistics engine based on Elasticsearch in this embodiment of the invention, two specific embodiments are described below.

[0262] It should be emphasized that the statement parameters not explained in the following examples are all inherent parameters in the Query DSL and do not require detailed explanation.

[0263] Example 1:

[0264] This example demonstrates a process for synchronously searching patent documents. The following are its standard request parameters.

[0265]

[0266] The next step is to construct the Elasticsearch Query DSL based on the standard request parameters, i.e., convert it into an Elasticsearch query statement. For clarity and ease of identification, all statements in the following examples are presented in tabular form, with the table content representing the statement content.

[0267] First, construct a basic statement, then assign the offset and limit attributes from the standard request parameters to the from and size attributes of the Query DSL, respectively:

[0268]

[0269]

[0270] Then, the Elasticsearch query statement obtained by parsing and transforming the patent search expression is:

[0271]

[0272] Assign this statement to the query property of the Query DSL:

[0273]

[0274] The sortField field in the standard request parameters, when converted to an Elasticsearch query statement, is as follows:

[0275] [{"Open Day":{"order":"desc"}}]

[0276] Assign this statement to the sort property of the Query DSL:

[0277]

[0278] The `statisticsFieldList` parameter in the standard request contains two independent statistics. The first statistic is the number of applications submitted by publication year, and then the number of applications submitted by application year within each publication year. Therefore, a nested aggregate statistics statement needs to be constructed:

[0279] {"terms":{"field":"Year of Publication"},"aggs":{"_Subordinate Aggregates":{"terms":{"field":"Year of Application"}}}}

[0280] Since the standard request parameters specify the deduplication field "application number", a deduplication counting statement needs to be added to the aggregation statistics statement:

[0281]

[0282] Similarly, the statement for the second statistical item can be obtained:

[0283] {"terms":{"field":"country"},"aggs":{"_duplicate count":{"cardinality":{"field":"application number"}}}}

[0284] Combine the names of these two statistics and their corresponding statements into a single JSON object and assign it to the `aggs` property of the Query DSL:

[0285]

[0286]

[0287] The `collapseField` field in the standard request parameters, when converted to an Elasticsearch query, would be:

[0288] {"field":"Application Number"}

[0289] Assign this statement to the collapse property of the Query DSL:

[0290]

[0291] Additionally, to obtain the total number of patents after deduplication, a separate deduplication count needs to be added to the aggs attribute:

[0292]

[0293]

[0294] This completes the Elasticsearch query statement derived from the standard request parameters. Since the `async` attribute in the standard request parameters is false and the `asyncSearchId` attribute is empty, it's necessary to call the Elasticsearch `_search` interface to perform the search and wait for the actual patent search results. An example of the actual patent search results is shown below (irrelevant attributes have been omitted):

[0295]

[0296]

[0297] The next step is to convert the actual patent search results into standard response results. First, construct a standard response result and assign the `hits.total.value` property from the search results to the `count` property of the standard response result:

[0298] property value count 49629

[0299] Then, the _source attribute of all matched patent documents is extracted from the hits.hits property, converted into a Map object, and added to the docList list in the standard response results.

[0300] property value docList [Patent document 1, Patent document 2, Patent document 3...] count 49629

[0301] Then, the `aggregations._deduplication_count`.value property is assigned to the `countAfterCollapse` property of the standard response result:

[0302] property value docList [Patent document 1, Patent document 2, Patent document 3...] count 49629 countAfterCollapse 44903

[0303] Finally, extract all statistical data from the aggregations attribute. Taking the "Publication Year, Application Year" statistic as an example, the statistical results for the first-level dimension "Publication Year" are as follows:

[0304] property value value 2021 count 27438 countAfterCollapse 26684

[0305] The statistical results for the second-level dimension, "Application Year," are as follows:

[0306]

[0307]

[0308] Next, establish the hierarchical relationship between different levels and dimensions (using the subLevel attribute), merge the statistical results of all statistical items together, and then assign them to the statisticsData attribute of the standard response result (for ease of representation, the content of the statisticsData attribute is displayed in JSON format here). Finally, the complete standard response result can be obtained:

[0309]

[0310] (I) Example 2:

[0311] This embodiment demonstrates the process of asynchronous patent document retrieval. The process consists of two steps: first, initiating an asynchronous search; and second, retrieving the results of that asynchronous search. The following are the standard request parameters for initiating an asynchronous patent search.

[0312]

[0313]

[0314] The next step is to convert the standard request parameters into Elasticsearch's Query DSL. The attribute conversion table is as follows:

[0315]

[0316] Therefore, the complete Elasticsearch query statement converted from the standard request parameters is as follows:

[0317]

[0318] Because the `async` attribute in the standard request parameters is set to `true`, an asynchronous retrieval needs to be performed by calling the Elasticsearch `_async_search` interface. An example of the asynchronous retrieval results is shown below (irrelevant attributes have been omitted):

[0319]

[0320] At this point, you have obtained the asynchronous search ID. Then, construct a standard response and assign this asynchronous search ID to the `asyncSearchId` property.

[0321]

[0322] The second step is to use the asyncSearchId obtained earlier to retrieve the corresponding asynchronous search results. The standard request parameters for this request are as follows:

[0323]

[0324] Since the `async` attribute in the standard request parameters is false and the `asyncSearchId` attribute is not empty, we need to directly use this asynchronous search ID to call the Elasticsearch API to retrieve asynchronous search results.

[0325]

[0326] Here is an example of the search results (irrelevant attributes have been omitted):

[0327]

[0328]

[0329] The asynchronous search results have a similar structure to the synchronous search results, except that the asynchronous search results include an additional `id` attribute, representing the asynchronous search ID. The actual search results are placed in the `response` attribute, therefore, the search results in the `response` need to be converted into standard response results. The attribute conversion table is as follows:

[0330]

[0331] Finally, the complete standard response result can be obtained:

[0332]

[0333] In summary, this invention, based on Elasticsearch, implements an Elasticsearch-based patent retrieval and statistics engine by defining an interface specification for patent retrieval and statistics. This engine includes a standard request parameter acquisition module, an Elasticsearch query statement conversion module, a patent retrieval module, and a standard response result acquisition module. Specifically, the standard request parameter acquisition module obtains standard request parameters; the Elasticsearch query statement conversion module converts the standard request parameters into Elasticsearch query statements using the logical correspondence between the standard request parameters and Elasticsearch query statements; the patent retrieval module performs patent searches in Elasticsearch using the Elasticsearch query statements to obtain the Elasticsearch search results; and the standard response result acquisition module converts the Elasticsearch search results into standard response results for output. The standard request parameters represent the attribute information of the patent retrieval and statistics requirements to be processed. These requirements include complex condition retrieval, multidimensional data statistical analysis, patent deduplication and document merging, and asynchronous patent retrieval. The structure of the standard request parameters is a predefined standard data structure for the retrieval input; and the structure of the standard response results is a predefined standard data structure for the retrieval output. As can be seen, the patent retrieval and statistics engine based on Elasticsearch in this embodiment of the invention establishes standards for patent retrieval and statistics by defining standard request parameters and standard response results. It can realize various functions such as complex condition retrieval, multidimensional data statistical analysis, patent deduplication and document merging, and asynchronous patent retrieval based on Elasticsearch, which can meet various needs in the existing patent retrieval and statistical analysis field. At the same time, it has corresponding standards and supports extension and optimization, providing good technical support for patent retrieval and statistical analysis.

[0334] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A patent retrieval and statistics engine based on Elasticsearch, characterized in that, include: A standard request parameter acquisition module is used to acquire standard request parameters; wherein, the standard request parameters represent the attribute information of the patent search statistical requirements to be processed; the patent search statistical requirements include complex condition search, multidimensional data statistical analysis, patent deduplication document merging, and asynchronous patent search; the structure of the standard request parameters is a predefined standard data structure for the search input; The Elasticsearch query conversion module is used to convert the standard request parameters into Elasticsearch query statements by utilizing the logical correspondence between standard request parameters and Elasticsearch query statements. The patent search module is used to perform patent searches in Elasticsearch using the Elasticsearch query statements and obtain Elasticsearch search results. The standard response result acquisition module is used to convert the Elasticsearch search results into standard response result output; wherein, the structure of the standard response result is a predefined standard data structure for the search output; The process by which the patent retrieval module performs a patent retrieval in Elasticsearch using the Elasticsearch query statement and obtains the Elasticsearch retrieval results includes: Step a1: Determine whether the async parameter in the standard request is true; if yes, proceed to step a2; if no, proceed to step a6. Step a2: Determine whether the asyncSearchId in the standard request parameter is empty; if not, proceed to step a3; if yes, proceed to step a4. Step a3: Delete the search results corresponding to asyncSearchId in Elasticsearch; and then execute step a4. Step a4: Call the Elasticsearch asynchronous search interface to initiate asynchronous search; Step a5: Obtain a new asyncSearchId; assign a new asynchronous search ID, asyncSearchId, to the asynchronous search in step a4 as a result retrieval credential; this asyncSearchId is used to retrieve the corresponding asynchronous search results when needed in the future. Step a6: Determine whether the asyncSearchId in the standard request parameter is empty; if yes, proceed to step a7; if no, proceed to step a9. Step a7: Call the Elasticsearch search interface to start real-time retrieval; Step a8: Obtain the actual patent search results; wherein, after calling the Elasticsearch search interface in step a7, a search is performed to obtain real-time search results; Step a9: Obtain the search results corresponding to asyncSearchId in Elasticsearch; then proceed to step a10. Step a10: Determine whether the asynchronous search has been completed; if yes, obtain the asynchronous search status and execute step a8; if no, execute step a11; wherein, if step a10 determines that the asynchronous search has been completed, the asynchronous search status is obtained as successful, and then step a8 is executed. Executing step a8 to obtain the actual patent search result is actually obtaining the result of the asynchronous search. Step a11: Obtain the asynchronous retrieval status; wherein, if step a10 leads to step a11, the asynchronous retrieval status includes failure or running.

2. The patent retrieval and statistics engine based on Elasticsearch according to claim 1, characterized in that, The structure of the standard request parameters includes: The index name is indexName, the patent search expression is searchExpr, the sorting attribute is sortField, the data offset is offset, the data limit is limit, the statistics field list is statisticsFieldList, the deduplication field is collapseField, the asynchronous search ID is asyncSearchId, and the asynchronous search requirement is async; wherein, the sorting attribute sortField includes the sorting field name fieldName and the sorting direction reverseOrder; the value of the asynchronous search requirement async indicates whether asynchronous search is performed; The structure of the standard response result includes: The database includes the patent document list (docList), hit count, duplicate hit count after Collapse, statistics (statisticsData), asynchronous search ID (asyncSearchId), and asynchronous search status (asyncSearchStatus).

3. The patent retrieval and statistics engine based on Elasticsearch according to claim 2, characterized in that, The Elasticsearch query conversion module utilizes the logical correspondence between standard request parameters and Elasticsearch query statements to convert the standard request parameters into Elasticsearch query statements. This process includes: The value of searchExpr in the standard request parameter is converted into an Elasticsearch query statement using a preset patented search expression statement conversion method, and then assigned to the query property in the Query DSL. Convert the value of sortField in the standard request parameters to the format of the sorting statement in the Elasticsearch query statement, and assign it to the sort property of the Query DSL; Assign the value of offset from the standard request parameters to the from attribute in the Query DSL; Assign the value of limit from the standard request parameters to the size attribute in the Query DSL; For each statistic in the statisticsFieldList of the standard request parameters, based on the terms grouping aggregation function in Elasticsearch, the value corresponding to the statistic is converted into the format of the aggregation query statement in the Elasticsearch query statement, the corresponding JSON object is constructed, and the value is assigned to the aggs property of the Query DSL; The value of the collapseField in the standard request parameters is converted into the format of the deduplication query statement in the Elasticsearch query statement and assigned to the collapse property of the Query DSL.

4. The patent retrieval and statistics engine based on Elasticsearch according to claim 3, characterized in that, The step of converting the value of searchExpr in the standard request parameters into an Elasticsearch query statement using a preset patented search expression statement conversion method includes: The string corresponding to the patent search expression in searchExpr is parsed using a pre-built word segmenter to obtain multiple parsed words; wherein, the patent search expression in searchExpr and the word segmenter are constructed based on a predefined extensible patent search expression syntax structure; Based on the patent retrieval expression syntax structure, the multiple word segments are processed into a list of standard syntax nodes; Generate a standard syntax tree based on the list of standard syntax nodes; The standard syntax tree is converted into an Elasticsearch query statement using a pre-built syntax transformer.

5. The patent retrieval and statistics engine based on Elasticsearch according to claim 3, characterized in that, For each statistic in the `statisticsFieldList` of the standard request parameters, based on the `terms` grouping aggregation function in Elasticsearch, the value corresponding to that statistic is converted into the format of the aggregation query statement in the Elasticsearch query statement, a corresponding JSON object is constructed, and the value is assigned to the `aggs` property of the Query DSL, including: For each statistic in the statisticsFieldList of the standard request parameters, if the statistic is a single-level dimension, the field value corresponding to the single-level dimension statistic is converted into the format of an Elasticsearch query statement using the terms grouping aggregation function in Elasticsearch to obtain the Elasticsearch aggregation query statement corresponding to the single-level dimension statistic; where each item in statisticsFieldList is a statistics field statisticsField, representing an independent statistic; For each statistic in the statisticsFieldList of the standard request parameters, if the statistic is a multi-level dimension, the Elasticsearch aggregation query statements obtained by using the terms grouping aggregation function in Elasticsearch for different single-level dimensions under the multi-level dimension statistic are nested in order and merged to obtain the Elasticsearch aggregation query statement corresponding to the multi-level dimension statistic. For each statistic, a JSON object is constructed using the statistic's field as the key and the corresponding Elasticsearch aggregation query statement as the value, and then assigned to the aggs property of the Query DSL.

6. The patent retrieval and statistics engine based on Elasticsearch according to claim 5, characterized in that, If the standard request parameters contain a value of collapseField, then for each statistic in statisticsFieldList in the standard request parameters, based on the terms grouping aggregation function in Elasticsearch, the value corresponding to the statistic is converted into the format of the aggregation query statement in the Elasticsearch query statement, the corresponding JSON object is constructed, and the value is assigned to the aggs property of the Query DSL. In addition, the cardinality aggregation function needs to be added to the Elasticsearch aggregation query statement corresponding to each single-level dimension to implement deduplication counting.

7. The patent retrieval and statistics engine based on Elasticsearch according to claim 3, characterized in that, After converting the value of the `collapseField` in the standard request parameters into the format of a deduplication query statement in an Elasticsearch query statement and assigning it to the `collapse` property of the Query DSL, the Elasticsearch query statement conversion module is further used for: Add the cardinality aggregation function to the converted Elasticsearch deduplication query statement to count the number of patents that meet the search conditions corresponding to the Elasticsearch deduplication query statement, so as to obtain the total number of deduplicated patents.

8. The patent retrieval and statistics engine based on Elasticsearch according to any one of claims 1 to 7, characterized in that, The process by which the standard response result acquisition module converts the Elasticsearch search results into standard response results for output includes: If the Elasticsearch search result is in an asynchronous search state, the asynchronous search state is assigned to the asyncSearchStatus property in the standard response result, and the assigned standard response result is output. If the Elasticsearch search result is the actual patent search result, convert the actual patent search result into a standard response result and output the obtained standard response result; If a new asyncSearchId is found in the Elasticsearch search results, the new asyncSearchId is assigned to the asyncSearchId attribute in the standard response result, and the assigned standard response result is output.

9. The patent retrieval and statistics engine based on Elasticsearch according to claim 8, characterized in that, If the Elasticsearch search result is an actual patent search result, the actual patent search result is converted into a standard response result, and the obtained standard response result is output, including: Extract each item from the array corresponding to the hits.hits property of the actual patent search results, convert the source property of each extracted item into a Map object, and add it in order to the docList list in the standard response results; Assign the value of the value attribute of the actual patent search result to the count attribute in the standard response result; Among the multiple key-value pairs contained in the aggregations attribute of the actual patent search results, determine the key corresponding to the deduplication count, and assign the value corresponding to the key to the countAfterCollapse attribute in the standard response result; From the statistical results contained in the aggregations attribute of the actual patent search results, the statistical results of each statisticsField are extracted using a preset statistical result extraction and transformation method, and then assigned to the statisticsData attribute in the standard response results.

Images