Intelligent patent retrieval system and method supporting multi-dimensional features

Abstract

The invention discloses an intelligent patent retrieval system and method supporting multi-dimensional features, relates to the technical field of patent information retrieval analysis, and is used for solving the problem of inaccurate complex retrieval. Comprising an access module, a slicing module, an establishment module, a planning module, a fusion and arrangement module and an evidence module, the access module unifies names, abstracts, claims, specifications and classifications, subjects, time, families, citations and legal states and generates literature keys and relation keys, and the slicing module unfolds a reference chain to analyze a limiting structure, extracts components, relations, actions and constraint fragments and records positions. The establishment module constructs an inverted table, a vector table, a field table and a relation table, the planning module generates an execution sequence, an expansion rule and a rollback rule, the fusion module recall multiple tables and performs fusion sorting with a coverage matrix, and the evidence module aligns fragments to generate evidence fingerprints, so that the system can continuously correct synonymous expressions, slice boundaries and execution strategies, noise hit is reduced, and the system performance is improved. And the continuous adaptation capability of the retrieval result is improved.

Description

Technical Field

[0001] This invention relates to the field of patent information retrieval and analysis technology, and more specifically, to a patent intelligent retrieval system and method that supports multi-dimensional features. Background Technology

[0002] In patent intelligence analysis and R&D project retrieval scenarios, enterprises and agencies typically need to quickly locate documents highly relevant to the target technical solution from massive amounts of patent texts, while simultaneously satisfying multi-dimensional constraints such as classification, applicant entity, time window, legal status, family, and citation chain. Existing retrieval systems mostly rely on keyword and field filtering. Although some systems have introduced semantic retrieval, they often treat the title, abstract, and claims as a whole text, making it difficult to break down the limiting structure, citation chain, and key technical fragments in the claims into fine-grained units that can be searched, located, and verified. In terms of retrieval results presentation, they often remain at the relevance score list, making it difficult to clearly indicate the specific claims and text locations hit. Search personnel still need to read and check each article one by one, reducing retrieval efficiency and increasing verification costs.

[0003] However, in the collaborative processing of multi-dimensional constraints and multi-source recall, existing technologies often employ sequential filtering or single-path recall when the search simultaneously includes classification, subject, time, legal status, and family extensions and citation extensions. When conflicts arise between constraints, there is a lack of consistency verification and controllable rollback mechanisms. This leads to either excessive narrowing that misses key family or key citation documents, or excessive broadening that introduces a large number of noisy documents. Furthermore, the fusion of semantic and keyword recall results lacks interpretable matching criteria, failing to form traceable records of coverage relationships and hit paths. This makes it difficult to reproduce and audit search results. The relevance annotations and exclusion reasons generated by users during the search process are usually not effectively written back into synonym rules, slicing rules, and query strategy templates. This results in a lag in the system's adaptation to industry terminology migration, changes in expression habits, and emerging technological concepts. After long-term operation, search quality is prone to fluctuations, making it difficult to continuously meet the comprehensive requirements of accuracy, interpretability, and stability in real-world business scenarios. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the following solution is proposed to solve the problem of inaccurate complex retrieval in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A patent intelligent retrieval system supporting multi-dimensional features includes an access module, a slicing module, a search module, a planning module, a fusion and sorting module, and an evidence module, with each module connected by a signal. The access module is used to access patent titles, abstracts, claims, specification texts, classification fields, subject fields, time fields, family relationships, citation relationships and legal status data, perform subject unification and family merging, and generate document keys and relationship keys. The slicing module is used to expand the claim reference chain and parse the limiting structure, extract component fragments, relationship fragments, action fragments, and constraint fragments, generate fragment keys, and record fragment position identifiers and claim position identifiers; The indexing module is used to build inverted indexes and vector tables based on fragment keys, field tables based on fields, and relation tables based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers. The planning module is used to receive query input and parse it into query fragments and constraint items, perform constraint consistency checks, and generate execution sequences, extended rules, and rollback rules. The fusion and ranking module is used to perform recall and record path identifiers in the inverted index, vector table, field table and relation table according to the execution sequence to obtain a candidate document set. It constructs a coverage matrix based on the query fragment and candidate document fragments, and generates a fusion and ranking list based on the constraint satisfaction items, coverage matrix matching items and path identifiers. The evidence module is used to align query fragments and candidate document fragments based on location identifiers, generate an evidence table and an evidence fingerprint, receive user annotations, and update the synonym table, slicing rule table and plan template table accordingly.

[0006] Furthermore, the access module performs entity normalization and family merging to generate document keys and relation keys, including: Read the main fields and perform character normalization, alias merging and field decomposition to generate the main key and establish a mapping table between the main key and the main fields; Read the time field and perform time expression normalization, generate time keys and establish a mapping table between time keys and time fields; Priority information and family association information are extracted based on clan relationships. Clan merging is performed to generate clan keys and a relationship table between clan keys and document keys is established. Citation pairs are extracted based on citation relations and citation keys are generated. Relation keys are generated based on family keys and citation keys and written into the relation mapping library. The classification field, subject key, time key, legal status data, and document key are associated and written into the document identifier database.

[0007] Furthermore, the slicing module expands the claim reference chain and parses the limiting structure to generate fragment keys and records the fragment position identifier and the claim position identifier, including: Based on the text of the claims, the claim item number and the reference pointer are extracted, a reference list is constructed, and the referenced content is expanded according to the reference list to generate the expanded text of the claim item. The text of the weights is expanded to perform phrase boundary segmentation and dependency parsing to obtain a sequence of bounded units and construct a bounded dependency chain. Extract component fragments, relation fragments, action fragments, and constraint fragments from the constrained unit sequence, generate fragment keys based on the normalized word sequence, and write them into the fragment mapping table; Record the fragment position identifier and the weight position identifier for the fragment key. The fragment position identifier includes the start offset and the end offset, and the weight position identifier includes the weight number and the segment number.

[0008] Furthermore, the planning module performs constraint consistency checks on the query input and generates execution sequences, expansion rules, and rollback rules, including: It receives query input and parses it into query fragments and a set of constraints. The set of constraints includes category constraints, subject constraints, time constraints, and legal status constraints. Conflict detection is performed based on the set of constraints. Conflict detection includes field missing conflict, range inclusion conflict and mutual exclusion conflict, and a conflict identification table is generated. Based on the conflict identifier table, rollback rules are generated. The rollback rules include the order and extent of constraint relaxation, and an executable constraint set is generated. An execution sequence is generated based on the set of executable constraints. The execution sequence includes the sequence identifiers of the field filtering stage, the relation expansion stage, and the fragment recall stage. Generate extension rules and bind them to the relationship table. The extension rules include extension direction identifier, extension level identifier, and termination condition identifier.

[0009] Furthermore, the indexing module constructs inverted indexes and vector tables based on fragment keys, field tables based on fields, and relationship tables based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers, including: The fragment text corresponding to the fragment key is segmented and normalized, a term sequence is generated, and an inverted entry from term to fragment key is established. The inverted entry is written with the document key, weight position identifier and fragment position identifier. Fragment vectors are generated based on fragment text, fragment type and limited dependency chain and written into a vector table. The vector table entries are written with document key, weight position identifier and fragment position identifier. Write the classification field, subject key, time key, and legal status into the field table, and associate the field table entries with the document key; Write the family key and citation key into the relation table, associate the relation table entries with the document key and write the relation direction identifier.

[0010] Furthermore, the fusion sorting module performs recall operations in the inverted index, vector table, field table, and relation table according to the execution sequence, records path identifiers, and generates a fusion sorting list, including: The field-based filtering stage performs filtering on the document keys based on the field table to obtain an initial candidate document set and generate field path identifiers; In the relation expansion phase, the initial candidate document set is expanded based on the relation table to obtain an expanded candidate document set and generate relation path identifiers. In the fragment recall phase, fragment matching is performed on the expanded candidate document set based on the inverted index and vector table to obtain the candidate document fragment set and generate fragment path identifiers; The system merges field path identifiers, relationship path identifiers, and fragment path identifiers to generate path identifiers, and then generates a merged sorted list based on these path identifiers.

[0011] Furthermore, the fusion and ranking module constructs a coverage matrix based on the query fragment and candidate document fragments, and generates a fused and ranked list according to constraint satisfaction terms, coverage matrix matching terms, and path identifiers, including: The query fragments are matched with candidate document fragments according to fragment type and fragment vector similarity threshold conditions to obtain a set of matching pairs; A coverage matrix is ​​constructed based on the set of matching pairs. The rows of the coverage matrix correspond to the query fragment keys, the columns correspond to the candidate document fragment keys, and the matrix cells are written with matching identifiers, position consistency identifiers, and weight consistency identifiers. Constraint satisfaction items are generated based on field constraints and relational constraints, and these constraint satisfaction items are bound to candidate document keys. A fusion ranking list is generated based on constraint satisfaction terms, coverage matrix matching terms, and path identifiers, and a candidate document set is output.

[0012] Furthermore, the evidence module aligns the query fragment and candidate document fragments based on location identifiers and generates an evidence table, including: Read the candidate document fragment set and aggregate the fragment keys and fragment position identifiers according to the document key to form a candidate document fragment mapping table; Read the query fragments and form a query fragment mapping table. Write the query fragment key and the query fragment position identifier into the query fragment mapping table. Fragment alignment is performed based on the query fragment mapping table and the candidate document fragment mapping table. Fragment alignment includes fragment type consistency verification, position consistency verification and weight consistency verification, generating a set of alignment matching pairs. Write the set of aligned matching pairs into the evidence table. Write the document key, weight position identifier, fragment position identifier, query fragment key, and candidate document fragment key into the evidence table entries.

[0013] Furthermore, the evidence module generates evidence fingerprints based on the evidence table and establishes the association between the evidence fingerprints and the document keys, including: The evidence list entries are sorted according to the document key and the weight position identifier, and an evidence sequence is generated. Perform normalized encoding on the query fragment key and candidate fragment key in the evidence sequence and generate an encoded sequence; The encoded sequence is input into the fingerprint calculation function to generate evidence fingerprints and written into the fingerprint table. The fingerprint table entries are written into the evidence fingerprint and document key. The evidence fingerprint is associated with the path identifier and written into the traceability table. The traceability table entries are written with the evidence fingerprint and the path identifier.

[0014] A patent intelligent retrieval method supporting multi-dimensional features, used to implement the aforementioned patent intelligent retrieval system supporting multi-dimensional features, includes: It can access patent title, abstract, claims, and specification text; classification field, subject field, time field; family relationship, citation relationship and legal status data; implement subject unification and family merging; and generate document key and relationship key. Expand the claim reference chain and parse the limiting structure, extract component fragments, relationship fragments, action fragments, and constraint fragments, generate fragment keys, and record fragment position identifiers and claim position identifiers; Inverted indexes and vector tables are constructed based on fragment keys, field tables are constructed based on fields, and relation tables are constructed based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers. Receive query input and parse it into query fragments and constraint terms, perform constraint consistency checks and generate execution sequences, expansion rules and rollback rules; The recall is performed in the inverted index, vector table, field table and relation table according to the execution sequence and the path identifier is recorded to obtain the candidate document set. A coverage matrix is ​​constructed based on the query fragment and the candidate document fragment. A fused sorted list is generated according to the constraint satisfaction item, the coverage matrix matching item and the path identifier. Based on the location identifier, the query fragments and candidate document fragments are aligned, an evidence table and evidence fingerprints are generated, user annotations are received, and the synonym table, slicing rule table and plan template table are updated accordingly.

[0015] The technical effects and advantages of the patent intelligent retrieval system and method supporting multi-dimensional features of this invention are as follows: This invention upgrades patent retrieval from text matching to structured multi-dimensional feature retrieval by constructing an integrated retrieval link that includes access unification, claim structure slicing, multi-table joint retrieval, constraint consistency plan, multi-source recall fusion sorting, and evidence closed-loop update. In the access stage, it unifies the expression of subject fields, time fields, family relationships, citation relationships, and legal status data and generates document keys and relationship keys, so that cross-data source retrieval has a consistent standard and traceability basis. In the slicing stage, the claim reference chain is expanded and the limiting structure is parsed. Component fragments, relation fragments, action fragments, and constraint fragments are extracted, and location identifiers and weight location identifiers are recorded, enabling the technical points to be located and verified. In the search and recall stage, inverted indexes, vector tables, field tables, and relation tables are used to perform multi-path recall and record path identifiers. Combined with the coverage matrix and constraint satisfaction items, a fused sorted list is generated, improving the balance between recall completeness and relevance of complex queries. Finally, in the evidence stage, query fragments and candidate fragments are aligned based on location identifiers, and an evidence table and evidence fingerprint are generated. Incremental updates to the synonym table, slicing rule table, and plan template table are performed in conjunction with user annotations, enabling the system to continuously correct synonym expressions, slicing boundaries, and execution strategies, reducing noise hits and uninterpretable results, and improving the interpretability, stability, and continuous adaptability of search results. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the structure of a patent intelligent retrieval system that supports multi-dimensional features according to the present invention.

[0017] Figure 2 This is a flowchart of a patent intelligent retrieval method that supports multi-dimensional features according to the present invention. Detailed Implementation

[0018] 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.

[0019] In order to achieve the above objectives, Figure 1 A schematic diagram of the structure of a patent intelligent retrieval system supporting multi-dimensional features is given, which specifically includes an access module, a slicing module, a search module, a planning module, a fusion and ranking module, and an evidence module. The modules are connected by signals. The access module is used to access patent titles, abstracts, claims, specification texts, classification fields, subject fields, time fields, family relationships, citation relationships and legal status data, perform subject unification and family merging, and generate document keys and relationship keys. The slicing module is used to expand the claim reference chain and parse the limiting structure, extract component fragments, relationship fragments, action fragments, and constraint fragments, generate fragment keys, and record fragment position identifiers and claim position identifiers; The indexing module is used to build inverted indexes and vector tables based on fragment keys, field tables based on fields, and relation tables based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers. The planning module is used to receive query input and parse it into query fragments and constraint items, perform constraint consistency checks, and generate execution sequences, extended rules, and rollback rules. The fusion and ranking module is used to perform recall and record path identifiers in the inverted index, vector table, field table and relation table according to the execution sequence to obtain a candidate document set. It constructs a coverage matrix based on the query fragment and candidate document fragments, and generates a fusion and ranking list based on the constraint satisfaction items, coverage matrix matching items and path identifiers. The evidence module is used to align query fragments and candidate document fragments based on location identifiers, generate an evidence table and an evidence fingerprint, receive user annotations, and update the synonym table, slicing rule table and plan template table accordingly.

[0020] The access module is used to access patent titles, abstracts, claims, and specification texts; to access classification fields, subject fields, time fields, family relationships, citation relationships, and legal status data; to perform subject unification and family merging; and to generate document keys and relationship keys. Specifically, the implementation is as follows: The access module receives and integrates two types of input data: one is patent text data, including patent title, abstract, claims, and specification text; the other is structured and relational data, including classification fields, subject fields, time fields, family relationships, citation relationships, and legal status data. The access module outputs a document key as a unique identifier for each patent document and simultaneously generates relation keys for unified relational expression. To ensure consistency in subsequent processing, the access module internally predefines and maintains the following data objects and their meanings: The subject key represents the applicant's identifier after subject normalization; the time key represents the time identifier after time expression normalization; the family key represents the family identifier after merging family members; the citation key represents the citation pair identifier; and the relation key represents the relation mapping identifier generated by combining the family key and the citation key. Simultaneously, the system maintains a subject key mapping table, a time key mapping table, a family key association table, a relation mapping library, and a document identifier library. The subject key mapping table stores the correspondence between subject keys and subject fields; the time key mapping table stores the correspondence between time keys and time fields; the family key association table stores the correspondence between family keys and document keys; the relation mapping library stores the correspondence between relation keys and family keys and citation keys; and the document identifier library stores the association records between document keys and classification fields, subject keys, time keys, and legal status data.

[0021] The process of the access module performing subject normalization and generating subject keys is consistent with the steps in the claims, specifically including character normalization, alias merging, and field decomposition.

[0022] Character normalization takes the main field string as input and performs whitespace normalization, full-width and half-width character unification, uppercase and lowercase character unification, common symbol unification, and invalid character removal according to a preset character normalization rule set, outputting a normalized main string. Alias ​​normalization takes the normalized main string as input and calls the alias dictionary to map abbreviations, former names, and common spelling variations to the same main standard name. Each record in the alias dictionary contains the main standard name and its alias set. The alias dictionary is constructed from historical main field statistics and manual verification results and is incrementally updated in subsequent annotation loops. Field decomposition takes the main standard name as input and extracts the main name unit and region unit according to preset decomposition rules, generating a main key. The main key is obtained by concatenating the main name unit and region unit in a fixed order and encoding them. The encoding method uses either reversible character encoding or hash encoding and is fixed in the system configuration, thus ensuring that the same main key is generated in different batches of access for the same main input.

[0023] To ensure the stable availability of the alias dictionary across different batches of integration, a traceable mechanism is employed for its construction and updates: During each access, the access module collects the original string of the subject field, the normalized subject string, and candidate mappings of the subject standard name, forming a candidate mapping record set. When multiple candidate subject standard names point to the same normalized subject string, the access module triggers a conflict resolution process. This process determines the unique subject standard name and generates a conflict resolution record based on the consistency of historical mapping stability, co-occurrence relationships in the same key association table, and subject-related annotations in the user-annotated sample table. The conflict resolution record is written to the update log of the alias dictionary and bound to the subject key in the subject key mapping table, thus ensuring that the same subject maintains a consistent normalization result in subsequent accesses. The alias dictionary is managed by version identifiers, which are stored in association with the access task identifier, allowing the subject normalization result of any document key to be traced back to the corresponding alias dictionary version and conflict resolution record.

[0024] The access module writes the subject key, the original subject field, the normalized subject string, and the subject standard name into the subject key mapping table for subsequent retrieval constraints and audit traceability.

[0025] The access module performs time expression normalization and generates time keys. The time field can come from one or more of the following: publication date, application date, and priority date. After reading the time field, the access module converts date strings of different formats into a unified date expression according to the preset time normalization rules and sets null value indicators for missing items. The time key is generated by concatenating and encoding the normalized date representation with the time field type identifier. The time field type identifier is used to distinguish the time keys corresponding to the publication date, application date, and priority date. The access module writes the time key, the original time field, and the normalized date expression into the time key mapping table. Then, the access module generates the document key. The document key is generated by combining the publication number main identifier with the country / region identifier and the data source identifier in a fixed order. The country / region identifier is obtained from the publication number or data source metadata. The data source identifier is determined by the access interface configuration and written into the document key generation rule table to ensure consistency. The access module associates the category field, subject key, time key, legal status data, and document key with the document key and writes them into the document identifier library. The legal status data expresses the current legal status with a status code and is bound to the acquisition timestamp. The acquisition timestamp is generated at the time of access and is used for version comparison of status updates.

[0026] It should be noted that, to avoid inconsistencies in key values ​​due to different data sources and character formats, the access module maintains a key generation rule table. This table records the set of constituent fields, field order, delimiter rules, and escaping rules for document keys, subject keys, time keys, family keys, citation keys, and relation keys. During key generation, each constituent field involved in the concatenation process undergoes unified character encoding and escaping to ensure that delimiters are not confused with field content. Then, the fields are concatenated in a fixed order to form a key source string, which is then encoded to obtain the target key value. The encoding method is fixed in the system configuration and recorded in the key generation rule table along with the encoding method identifier and version identifier. After generating the key value, the access module performs collision checks: when the same target key value corresponds to multiple different key source strings, the access module marks the key value as a collision anomaly and writes it to the key anomaly table, while simultaneously writing the difference field of the key source strings to the anomaly details. After a collision anomaly is triggered, the access module re-encodes the key using an extended key source string that includes the data source identifier and writes the extended rules to the revision record of the key generation rule table, thus ensuring that the key value is globally unique and traceable.

[0027] The access module performs family merging, citation pair extraction and generation of relation keys. That is, based on family relations, the access module extracts priority information and family association information. Priority information includes priority number and priority date, and family association information includes the set of document keys under the same priority cluster. The access module aggregates priority clusters according to a preset family merging rule to generate family keys. The family key is generated by concatenating the priority number and the country / region identifier in a fixed order. The family key and the document key set are written into the family key association table. Based on the citation relationship, the access module extracts citation pairs and generates citation keys. The citation pair includes the citing document key and the cited document key. The citation key is generated by concatenating the citing document key and the cited document key in a fixed order and is written into the citation key mapping table.

[0028] The access module generates relationship keys based on family keys and citation keys. The relationship key is generated by concatenating and encoding the family key, citation key, and relationship direction identifier in a fixed order. The relationship direction identifier is used to distinguish the direction from which the citing document points to the cited document. The access module writes the relationship key into the relationship mapping library and establishes association records from the relationship key to the family key, citation key, and relationship direction identifier in the relationship mapping library. This ensures that the subsequent relationship table construction and relationship expansion rule execution have a consistent data foundation. The above access process is executed according to the same rules in each access task. During incremental access, the main key mapping table, time key mapping table, family key association table, relationship mapping library, and document identifier library are updated by insertion or overwrite. Overwrite updates use the document key as the primary key and obtain the timestamp to control version consistency, ensuring that the access results are traceable and unambiguous.

[0029] Legal status data is stored in a versioned manner to support incremental updates and historical tracing, specifically: In addition to the status code, each legal status record in the document identifier database is also bound to an acquisition timestamp and a status source identifier. The acquisition timestamp is used to characterize the time point of status collection, and the status source identifier is used to characterize the interpretation of the status. During incremental access, the access module retrieves existing status records using the document key as the primary key. When the newly acquired status code is inconsistent with the existing status code, the access module writes the new status as a new version and establishes a relationship between the previous and current versions in the status version index. When the newly acquired status code is consistent with the existing status code, the access module only refreshes the acquisition timestamp and retains the original version number, thereby avoiding duplicate version expansion. When generating legal status constraints, the planning module uses the status code and version validity period for joint judgment to ensure that the same query can be reproduced under the same time caliber.

[0030] The slicing module is used to expand the claim reference chain and parse the limiting structure, extract component fragments, relationship fragments, action fragments, and constraint fragments, generate fragment keys, and record fragment position identifiers and claim position identifiers. Specifically, it is implemented as follows: The input to the slicing module is the claim text and document key provided by the access module, and the output is the fragment key, fragment position identifier, claim position identifier, and fragment mapping table. The slicing module internally defines and maintains the following data objects and their meanings: Reference lists are used to record the reference relationships between weight numbers; The expanded text of the claims is used to represent the content text of the claims after being expanded by the chain of references; The constrained unit sequence is used to represent the smallest semantic unit sequence obtained by structural parsing of the expanded text of weights; Qualified dependency chains are used to represent the modification, conditional, and co-dependencies between qualified units in a sequence of qualified units. The fragment type is used to distinguish between component fragments, relationship fragments, action fragments, and constraint fragments; the fragment position identifier is used to locate the start and end offsets of the fragment in the expanded text of the weight item; The weight position identifier is used to locate the weight number and sentence number to which the segment belongs; Fragment keys are used to uniquely identify a feature fragment; The fragment mapping table is used to record the association records between fragment keys and document keys, fragment types, fragment position identifiers, and weight position identifiers. The names of these objects are fixed in this system, and subsequent modules call them with the same names.

[0031] The calculation of fragment position identifiers adopts a uniform standard to avoid inconsistencies in cross-module offsets, specifically: The slicing module treats the expanded text of the weights as a unified character sequence and calculates the start and end offsets using a unified character encoding standard. In addition, to facilitate alignment with the word segmentation results, the slicing module generates additional word position identifiers, which consist of the start and end word positions of the segment in the word segmentation sequence.

[0032] In the fragment mapping table, the same fragment key is written with both the fragment position identifier and the word position identifier. When the evidence module performs position consistency verification, it first performs text-level positioning based on the fragment position identifier, and then performs word-level alignment verification based on the word position identifier, thereby ensuring that the alignment result is reproducible and is not affected by changes in word segmentation details.

[0033] The process of the slicing module expanding the claim reference chain and generating expanded claim text includes: First, the claim text is processed by extracting the claim number, which is obtained by parsing the serial number of the claim clause. Then, the claim text is processed by extracting the reference pointer, which is the text segment in the claim text used to indicate the number of the referenced claim. The slicing module writes each claim number and its reference pointer into the reference list. Then, the referenced content is expanded according to the reference list. The expansion rule is to insert the limiting content of the referenced claim into the reference position of the referenced claim, and retain the original claim boundary marker and sentence boundary marker for location and traceability. When there are multi-level references, the text is recursively expanded in the direction of the references until there are no new references. The slicing module outputs the expanded text as the weight expanded text and records the boundary markers of the weight number and the sentence segment number in the weight expanded text. The sentence segment number is obtained by segmenting the weight expanded text according to the rules of punctuation and conjunctions, and is used to form the position identifier of the subsequent weight.

[0034] The process by which the slicing module parses the bounded structure and forms a sequence of bounded units and a bounded dependency chain is as follows: The slicing module performs phrase boundary segmentation on the expanded text of the weights. The phrase boundary segmentation is based on the word segmentation results and commonly used patent-defined connection structures, dividing continuous word units into several defined units. The defined units are the smallest semantic units extracted subsequently. After phrase boundary segmentation, the slicing module performs dependency parsing on the sequence of qualifying units. The dependency parsing takes the syntactic dependency analysis results as input and encodes the modification, coordination and conditional relations between qualifying units into qualifying dependency chains.

[0035] The bounded dependency chain is represented by a set of directed edges, where each directed edge contains a dependency start bounding unit identifier, a dependency end bounding unit identifier, and a dependency type identifier. The dependency type identifier is used to distinguish between modifier dependencies, parallel dependencies, and conditional dependencies. To ensure consistency, the bounding unit identifier is generated from the start and end offsets of the bounding unit in the expanded text of the weighted item, and the dependency type identifier is given by a preset type dictionary. The slicing module writes the bounding unit sequence and the bounded dependency chain into an intermediate structure table for use in fragment extraction and fragment key generation.

[0036] The process by which the slicing module extracts fragments and generates fragment keys and position identifiers includes: The slicing module extracts component fragments, relationship fragments, action fragments, and constraint fragments from the limited unit sequence according to fragment type determination rules. The fragment type determination rules are stored in the slicing rule table and called with a fixed version number. The slicing rule table is organized as a set of rule entries. Each rule entry includes at least a rule identifier, applicable fragment type, trigger condition description, boundary determination method description, and rule version identifier. The trigger condition description limits the matching conditions of the rule in the defined unit sequence and defined dependency chain. The boundary determination method description provides the extraction strategy for fragment boundaries, ensuring that component fragments, relationship fragments, action fragments, and constraint fragments can be stably extracted within the same parsing framework. The slicing rule table is version-managed. The slicing module records the rule version identifier used in each slicing task and writes this version identifier into the rule version field of the fragment mapping table, ensuring that the generation process of any fragment key is traceable. When the evidence module triggers a rule update based on user annotations, the update result is written to the slicing rule table with the new version, while the old version is retained to support rollback. Rollback conditions are triggered by the anomaly detection rules recorded in the plan template table. Component fragments correspond to the representation of object entities and functional components; relationship fragments correspond to the representation of relationships such as connection, mapping, inclusion, and dependency; action fragments correspond to the representation of processes such as acquisition, generation, construction, updating, and output; and constraint fragments correspond to the representation of limitations such as range, condition, order, threshold, and consistency requirements. For each extracted fragment, the slicing module records the fragment position identifier, which includes the start and end offsets of the fragment in the expanded text of the weighted item. Simultaneously, the position identifier of the weight item is recorded. The position identifier of the weight item includes the weight item number and the sentence segment number to which the segment belongs. Then, the slicing module generates the segment key. The segment key is generated in the following way: The text fragment is processed by generating a normalized lexical sequence, which is obtained through word segmentation, synonym unification, morphological normalization, and stop word removal. Then, a dependency summary is generated for the corresponding limited dependency chain of the fragment. The dependency summary is obtained by encoding the set of dependency edges associated with the fragment in a preset order. Finally, the normalized lexical sequence and the dependency summary are concatenated in a fixed order and encoded to generate a fragment key. The encoding method is either reversible character encoding or hash encoding and is fixed in the system configuration, thereby ensuring that the same fragment key is generated when the same fragment is processed in different batches.

[0037] The slicing module writes the fragment key into the fragment mapping table, and associates the fragment type, fragment position identifier, and weight position identifier in the fragment mapping table with the document key as a foreign key, thus completing the output of the slicing module and providing a locatable basic unit for the indexing module to build inverted indexes and vector tables.

[0038] The indexing module is used to construct inverted indexes and vector tables based on fragment keys, field tables based on fields, and relation tables based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers. The specific implementation is as follows: The input to the indexing module is the document identifier database and relation mapping database output by the access module, and the fragment mapping table, fragment key, fragment position identifier, and weight position identifier output by the slicing module. The output consists of four types of search tables: inverted index, vector table, field table, and relation table. It ensures that all four types of tables use the document key as the primary association identifier, the fragment key as the fragment-level association identifier, and the fragment position identifier and weight position identifier as the location-level association identifier. Internally, the indexing module uniformly defines and maintains the following data objects and their meanings: Terms are used to represent basic search term units obtained from fragment text segmentation; lexical normalization is used to unify terms to obtain normalized lexical units; inverted entries are used to represent index records from terms to fragment keys; fragment vectors are used to represent semantic representation vectors of fragment text; vector entries are used to represent index records from fragment vectors to fragment keys; field entries are used to represent index records from structured fields to document keys; relation entries are used to represent index records from relation mapping to document keys; relation direction identifiers are used to characterize citation direction or family association direction.

[0039] The process of constructing an inverted index includes: The search module reads the fragment text corresponding to each fragment key in the fragment mapping table, performs word segmentation on the fragment text to obtain a term sequence. Word segmentation can be based on dictionary and statistics or on sub-word unit segmentation, outputting an ordered term sequence. Subsequently, lexical normalization is performed on the term sequence. Lexical normalization includes synonym unification, morphological normalization, and symbol normalization. Synonym unification maps equivalent expressions to unified lexical units through a synonym table. Morphological normalization unifies different forms of the same root word into a standard form. Symbol normalization unifies different full-width and half-width characters and different connector expressions into standard symbols. Based on the normalized term sequence, the search module builds inverted entries from terms to fragment keys. Each inverted entry contains at least the term, fragment key, document key, weight position identifier, and fragment position identifier, and can additionally include the fragment type to accelerate subsequent filtering by fragment type. The inverted entries are organized with terms as the primary key to form an inverted table, enabling the quick location of the matching fragment key set and its corresponding document key and position identifier when given a term, thus ensuring that the matching results can be directly used for evidence location.

[0040] The process of constructing a vector table includes: The indexing module reads the fragment text, fragment type, and limited dependency chain information corresponding to each fragment key in the fragment mapping table, generates fragment vectors, and writes them into the vector table. The fragment vectors are obtained by inputting the fragment text into a pre-configured text encoder to obtain a fixed-dimensional vector representation. The text encoder can be an encoding network trained on patent corpus or a general text encoding network. The indexing module combines the fragment type with the fragment text encoding result in the form of type embedding to generate the final fragment vector, so that different fragment types have a distinguishable semantic space. The type embedding is obtained by looking up the fragment type mapping table, which is set during system initialization and remains stable in version iterations. The search module generates dependency summary vectors for the defined dependency chains and combines them with fragment text vectors, ensuring that the influence of the defined dependency chains is reflected in the semantic representation. The dependency summary vectors are obtained by encoding the dependency type identifier sequence in the defined dependency chains. The final generated fragment vectors are written into a vector table. Each vector entry must include at least the fragment vector, fragment key, document key, weight position identifier, and fragment position identifier, and may also include a fragment type identifier as a search constraint, enabling subsequent semantic retrieval to return locatable fragment results.

[0041] It should be noted that, to support rapid retrieval of the vector table, the search module maintains a vector retrieval index structure outside the vector table. This index structure uses fragment vectors as the retrieval object and fragment keys as the return object, maintaining consistent association with document keys, weight position identifiers, and fragment position identifiers. The construction of the vector retrieval index structure is performed under the same rule version, and records the text encoder version identifier, type embedding version identifier, and dependent abstract encoding version identifier. During incremental search, when a fragment key already exists and the fragment text remains unchanged, only existing fragment vectors and index entries are reused. When a fragment key exists but the fragment text or the defined dependency chain changes, the search module marks the old vector entry as a historical version and writes it into the version index, while simultaneously writing the new vector entry, ensuring that the semantic retrieval results are traceable and consistent with evidence localization.

[0042] The process of constructing field tables and relational tables includes: The construction of the field table is driven by the document identifier library output by the access module. The indexing module writes the classification field, subject key, time key and legal status data into the field table. The field table entries use the document key as the association key and write the field type identifier and field value identifier. The subject key and time key come from the subject key mapping table and the time key mapping table, respectively, to ensure that the values ​​used when filtering fields are consistent with those used during access. The construction of the relationship table is driven by the relationship mapping library output by the access module. The indexing module writes the family key and citation key into the relationship table. The relationship table entries are associated with the document key and write the relationship direction identifier. The relationship direction identifier is used to distinguish the direction from which the citing document key points to the cited document key, as well as the direction of intra-family association generated by merging family members. The relation table also retains the association between relation keys and family keys and citation keys, so that when the planning module generates extension rules, it can directly bind the relation table and execute the extension according to the extension direction and extension level. Through the above construction method, the inverted table, vector table, field table and relation table form a unified index structure under the same document key system and position identifier system, which provides a data foundation for the multi-table parallel retrieval, coverage matrix construction and evidence table location of the fusion sorting module.

[0043] The planning module receives query input, parses it into query fragments and constraint terms, performs constraint consistency checks, and generates execution sequences, expansion rules, and rollback rules. Specifically, it implements the following: The planning module takes user query input, query fragments, and constraints as input and outputs execution sequence, expansion rules, and rollback rules as output. The function of the planning module is to convert the query input into a query form that the system can execute, perform consistency checks on the constraints, and generate execution sequence, expansion rules, and rollback rules according to the needs of the retrieval process. The planning module can also maintain a planning template table. This table is used to reuse execution strategies for common query types. Each template in the planning template table contains at least a template key, constraint structure signature, query fragment structure signature, execution sequence template, extended rule template, and fallback rule template. The constraint structure signature is generated by combining the existence and value types of classification constraints, subject constraints, time constraints, and legal status constraints. The query fragment structure signature is generated by combining the fragment types of the query fragment. After parsing the query input, the planning module first generates the constraint structure signature and the query fragment structure signature, and then matches them with the template key in the planning template table. When a template key is matched, the corresponding execution sequence, extended rule, and fallback rule are directly assembled. When a template key is not matched, the planning module generates the execution sequence, extended rule, and fallback rule according to the rules of this embodiment, and writes the generated result along with the structure signature into the planning template table as a candidate template. Candidate templates must undergo user-annotated closed-loop verification by the evidence module before being upgraded to a reusable template version.

[0044] In this embodiment, the query input processed by the planning module includes query fragments and constraints. The query fragments are the specific query content entered by the user, which may be key terms, functional requirements, technical field descriptions, etc. in the patented technology. The constraints are additional restrictions that need to be followed when querying, including classification constraints, subject constraints, time constraints, and legal status constraints. The query input is usually expressed by the user in natural language. The planning module is responsible for performing structured parsing on it, converting the natural language query into a set of query fragments and constraints that can be executed by the search engine.

[0045] The planning module first preprocesses the query input. Its main tasks include word segmentation, terminology standardization, fragmentation, and field extraction. The word segmentation and terminology standardization steps use existing natural language processing technologies in the patent field to normalize patent terms and ensure that synonyms, abbreviations, etc., appearing in the query can be unified into standard terms. The fragmentation process splits the query text into fragments with independent meanings, such as technical feature fragments, functional fragments, and implementation method fragments. Each fragment represents a technical content or requirement in the query.

[0046] The field extraction process identifies fields related to patent document fields (such as technical field, applicant, patent type, etc.) from the query, generating classification constraints, subject constraints, etc. After these steps, the planning module converts the query input into a set of query fragments and constraint items, and performs subsequent consistency checks and rule generation. During the consistency check process, the planning module first identifies the constraints in the query and performs conflict detection on these constraints. Conflict detection includes field missing conflicts, scope inclusion conflicts, and mutual exclusion conflicts. Field missing conflicts occur when certain fields (such as patent applicant, patent type, etc.) are missing from the query, resulting in a lack of necessary limitations. Scope inclusion conflicts occur when the scope of certain constraints is too broad, potentially leading to too many query results and affecting the accuracy of subsequent results. Mutually exclusive conflicts occur when mutually exclusive constraints appear in the query; for example, a query may require a patent to belong to a specific technical field but also require that the patent not belong to a related subfield of that field. For these conflicts, the planning module generates a conflict identifier table, recording the conflict type and conflict item. Based on this, it generates fallback rules, which indicate how to avoid conflicts by relaxing constraints. These rules typically include the order and extent of constraint relaxation.

[0047] During the generation of the execution sequence, the planning module generates an executable sequence of query steps based on the parsed query fragments and constraints. The generation of the execution sequence follows a certain logical flow, mainly divided into a field filtering stage, a relation expansion stage, and a fragment recall stage. The field filtering stage mainly performs preliminary screening of the data in the literature database based on the field constraints in the constraints, removing patent documents that do not meet the conditions. The relation expansion stage expands the query scope based on family relationships and citation relationships, mining relevant patent documents to ensure that the search results have strong relevance and breadth. The fragment recall stage performs precise fragment-level recall based on inverted indexes and vector tables, selecting the documents that best match the query fragments from all candidate documents. The execution sequence includes the execution step identifier and execution priority of each stage, ensuring that the retrieval process is executed sequentially according to the predetermined steps and can be dynamically adjusted according to the actual situation.

[0048] The process of generating extended rules complements the execution sequence. Extended rules are used to further expand and deepen the query, ensuring that the search results are not limited to the initial query scope. The expansion rules include expansion direction identifiers, expansion level identifiers, and termination condition identifiers. The expansion direction identifier indicates whether the expansion proceeds along family relationships or citation relationships; the expansion level identifier specifies the depth of the expansion; and the termination condition identifier defines the conditions under which the expansion ends. For example, an expansion rule can be set to "expand along family relationships, with an expansion depth of 2 levels, until the similarity between the document and the query fragment reaches a preset threshold." These expansion rules are automatically generated by the planning module based on the type of query fragment, the relationships between constraints, and the requirements of the query target.

[0049] Rollback rules come into play when query conflicts or execution failures occur. By relaxing query constraints, rollback rules ensure that the retrieval process can still execute and return valid results even when constraints conflict. Rollback rules include the constraint relaxation order and the relaxation magnitude. The relaxation order indicates which constraints should be relaxed first, while the relaxation magnitude specifies the degree of relaxation at each step, usually expressed as a percentage or a specific numerical value. For example, when field constraints conflict, the planning module can choose to relax constraints on some non-core fields, allowing for some fuzzy matching; when range conflicts occur, the planning module can appropriately expand the query range to maximize retrieval results.

[0050] In summary, the planning module, through parsing the query input, verifying constraint consistency, generating execution sequences, and generating expansion and rollback rules, provides clear execution steps, expansion strategies, and flexible rollback mechanisms for the subsequent retrieval process. This ensures that the patent intelligent retrieval system can operate stably and efficiently under different query conditions and guarantees the accuracy and comprehensiveness of the retrieval results.

[0051] The fusion and ranking module is used to perform recall and record path identifiers in the inverted index, vector table, field table, and relation table according to the execution sequence to obtain a candidate document set. A coverage matrix is ​​constructed based on the query fragments and candidate document fragments. A fused and ranked list is generated based on constraint satisfaction items, coverage matrix matching items, and path identifiers. The specific implementation is as follows: The main function of the fusion ranking module is to perform recall in the inverted table, vector table, field table and relation table according to the execution sequence, and construct a coverage matrix based on the query fragment and candidate document fragment. Based on the constraint satisfying items, coverage matrix matching items and path identifiers, a fusion ranking list is generated, and finally the candidate document set is output. The fusion ranking module provides the optimal candidate document set for the subsequent display of search results through multi-table parallel query, recall and fusion ranking.

[0052] The fusion and ranking module first receives the execution sequence generated by the planning module. This execution sequence indicates the execution order of each step in the query process. The execution sequence includes the field filtering stage, the relation expansion stage, and the fragment recall stage. The execution order of each stage determines the priority and processing order of the retrieval. According to the execution sequence, the fusion and ranking module performs recall operations in the inverted table, vector table, field table, and relation table in sequence to obtain multiple candidate document sets and record the path identifiers.

[0053] The path identifier uses structured coding to support traceable ordering, and the specific process is as follows: The path identifier consists of a phase identifier sequence, a rule version identifier sequence, and a hit source identifier sequence. The phase identifier sequence records the execution order and actual hit status of the field filtering phase, relation expansion phase, and fragment recall phase. The rule version identifier sequence records the reference versions of the field table, relation table, inverted index, and vector table. The hit source identifier sequence records which one or more of the following sources—inverted index recall, vector recall, field filtering, or relation expansion—the candidate document set originates from. The fusion module generates path fragments within each phase and concatenates and encodes these fragments in a fixed order at the end of each phase to obtain the complete path identifier. The complete path identifier is written to the path tracing table along with the candidate document key.

[0054] Path identifiers are used to record the matching relationships between various steps and query segments in the retrieval process, helping to identify the source of the association between document entries and the query process, and facilitating verification and sorting.

[0055] In the inverted index recall phase, the fusion ranking module matches the keywords in the query fragment with the inverted index to quickly locate document fragments containing the query keywords. The index entries of the inverted index are organized according to the mapping between terms and fragment keys. When a query fragment matches a term, the document key and fragment key of the candidate document fragment will be retrieved, and the path identifier will be recorded. In the vector table recall phase, the fusion ranking module matches the query fragment with the fragment vector based on the similarity, recalls candidate document fragments that are semantically similar to the query fragment from the vector table, generates path identifiers, and records the corresponding similarity scores. In the field table recall phase, the fusion ranking module retrieves documents that meet the field constraints in the query fragment, such as technical field, applicant, time, etc., from the field table and records the path identifiers.

[0056] In the recall phase of the relation table, the fusion and ranking module expands the candidate document set based on family relationships and citation relationships, mines relevant documents, obtains an expanded candidate document set, and generates path identifiers. Each recall phase, through the recording of path identifiers, ensures subsequent multi-level ranking and verification operations.

[0057] Next, the fusion and sorting module constructs the coverage matrix, specifically as follows: A coverage matrix is ​​used to represent the matching relationship between query fragments and candidate document fragments. Rows in the matrix represent query fragments, and columns represent candidate document fragments. Each matrix cell represents the degree of matching between a query fragment and a candidate document fragment, including a matching identifier, a positional consistency identifier, and a weight consistency identifier. The matching identifier indicates the degree of matching between the query fragment and the candidate document fragment in terms of terms, semantics, or structure; the positional consistency identifier indicates the alignment of the query fragment and the candidate document fragment in the text; and the weight consistency identifier indicates the degree of matching between the query fragment and the candidate document fragment in the corresponding claims or patent text. Through these identifiers, the coverage matrix provides quantitative data support for matching judgments.

[0058] The generation of matching items in the coverage matrix follows the rule of type first, semantics second, and position third: the fusion module first groups and matches the query fragments and candidate document fragments according to the fragment type constraints to ensure that component fragments, relation fragments, action fragments and constraint fragments are compared in the same type space; Within the same type of group, the fusion ranking module generates matching identifiers based on the consistency of terms hit in the inverted index and the semantic similarity consistency of the vector table. The matching identifiers use discrete state markers to indicate whether the inverted index recall is hit, whether the vector recall is hit, and whether both are hit simultaneously. Subsequently, the fusion module generates position consistency identifiers and weight consistency identifiers based on the fragment position identifier and weight position identifier. The position consistency identifier is used to determine whether the location span of the query fragment and the candidate fragment in the candidate document is compatible with the limited structure of the query fragment. The weight consistency identifier is used to determine whether the candidate fragment falls within the same weight number and sentence number range.

[0059] In the process of generating the fused sorted list based on constraint satisfaction terms, coverage matrix matching terms, and path identifiers, the fusion sorting module performs sorting calculations based on multiple constraints and matching terms, specifically: First, the fusion and ranking module checks whether candidate document fragments meet field constraints, relational constraints, and other conditions based on the constraints in the query fragment, obtaining constraint satisfaction items. These constraint satisfaction items record whether the candidate document fragments meet various constraints of the query, such as time, subject, and technical field. Then, based on the matching items in the coverage matrix and the constraint satisfaction items, the fusion and ranking module constructs a fused ranking list, combining the matching degree between the query fragment and the candidate document fragments. The fused ranking list sorts the candidate documents by priority, displaying documents with high semantic matching degree to the query fragment and meeting the constraints first, ultimately outputting the best candidate document set.

[0060] During the sorting process, the fusion sorting module uses path identifiers to help track the source and steps of document retrieval, ensuring the traceability of sorting results and supporting subsequent evidence verification and result analysis. Through parallel queries and fusion sorting of multiple tables, the fusion sorting module can provide efficient and accurate candidate document sorting for the patent intelligent retrieval system, improving retrieval quality and response speed.

[0061] Finally, the fusion and ranking module generates a merged and ranked list based on the above steps, and outputs the final candidate document set to the system's user interface or subsequent modules for further processing. This ranking process not only ensures the accuracy of the search results but also optimizes search performance, enabling the search system to respond to user queries quickly and accurately.

[0062] The evidence module is used to align query fragments and candidate document fragments based on location identifiers, generate an evidence table and evidence fingerprints, receive user annotations, and update the synonym table, slicing rule table, and plan template table accordingly. Specifically, the implementation is as follows: The main function of the evidence module is to align query fragments and candidate document fragments based on location identifiers, generate an evidence table, and generate evidence fingerprints. The evidence module also receives user annotations and updates the synonym table, slicing rule table, and plan template table based on these annotations, thereby enhancing the system's retrieval accuracy and adaptability.

[0063] The evidence module internally defines and maintains the following data objects and their meanings: The fingerprint table is used to store the association records between evidence fingerprints and document keys and right item location identifiers; the traceability table is used to store the association records between evidence fingerprints and path identifiers and rule version identifiers. The annotation sample table stores the evidence fingerprints, document keys, annotation types, and annotation reason tags generated by user annotations. The calculation of evidence fingerprints uses a fixed abstract algorithm to generate abstract values ​​from the coded sequence. The coded sequence is formed by sorting the evidence table entries according to the document key and weight position identifier. The abstract algorithm and encoding rules are fixed in the system configuration and the version identifier is recorded to ensure that the same evidence table generates the same evidence fingerprint in different running batches. When user annotations trigger an update, the evidence module first writes the annotations to the annotation sample table, and then determines whether to update the synonym table, slicing rule table, and plan template table based on the update conditions: When the annotation shows that the same query fragment key and candidate fragment key are semantically equivalent but not matched multiple times, the synonym table is triggered to add a synonym mapping; when the annotation shows that the fragment boundary repeatedly shifts, causing evidence alignment to fail, the slicing rule table is triggered to update the boundary determination method; when the annotation shows that the backoff rule is repeatedly triggered under a certain type of constraint combination and causes the candidate document set to deviate, the plan template table is triggered to update the execution sequence template and backoff rule template.

[0064] The evidence module takes as input the candidate document fragments and their corresponding path identifiers generated by the ranking module, and relevance feedback from user annotations. The output of the evidence module is an evidence table and evidence fingerprints. The evidence table records alignment information between the query fragment and the candidate document fragments, including fragment type consistency checks, position consistency checks, and weight consistency checks. The evidence fingerprint generates a unique identifier for each matching pair, facilitating traceability and verification. Internally, the evidence module uniformly defines and maintains the following data objects and their meanings to ensure consistency across all data processing procedures, specifically including: The fragment mapping table records the mapping relationship between query fragments and candidate document fragments; fragment alignment describes the degree of matching between query fragments and candidate document fragments; evidence fingerprints generate unique identifiers for matching pairs; and the evidence table stores detailed information about aligned matching pairs.

[0065] The evidence module first aligns query fragments with candidate document fragments based on location identifiers by comparing the matching results of the query fragments and candidate document fragments. Each query fragment finds its matching fragment in the corresponding document, and the matching criteria include fragment type, location, and consistency of weights. The alignment of query fragments and candidate document fragments involves two main steps: The evidence module performs two checks: type consistency and position consistency. Type consistency checks primarily detect whether the query fragment and the candidate document fragment belong to the same type (such as functional fragments, action fragments, etc.), which is achieved by comparing the category labels of the fragments. Position consistency checks whether the query fragment and the candidate document fragment are in the same position in the text, ensuring that the semantic positions of the fragments are correctly aligned in the document. Through these two checks, the evidence module can accurately align the query fragment and the candidate document fragment and record the alignment results as a set of matching pairs.

[0066] Next, the evidence module generates an evidence table, which is the core storage structure for alignment and matching. The evidence table records all alignment information between the query fragment and the candidate document fragment. Each entry contains a document key, a weight position identifier, a fragment position identifier, a query fragment key, and a candidate document fragment key. The document key is used to identify candidate documents, the weight position identifier and the fragment position identifier are used to mark the precise position of the fragment in the document, and the query fragment key and the candidate document fragment key are used to identify the unique identifier of the query fragment and the candidate document fragment in the retrieval process. Each alignment matching pair will be associated with the corresponding document key, fragment position identifier, weight position identifier, query fragment key and candidate fragment key in the evidence table to ensure that the alignment results can be traced and verified.

[0067] The generation of evidence fingerprints is a key step in the evidence module. Evidence fingerprints are unique identifiers for aligned matching pairs, used to distinguish different matching pairs, ensuring that each matching pair is unique during the retrieval process and can be effectively traced in subsequent queries. The process of generating evidence fingerprints includes sorting each matching pair in the evidence table and generating a coding sequence by normalizing the query fragment key and candidate document fragment key of each matching pair.

[0068] Normalized coding employs a standardized algorithm to map query fragment keys and candidate document fragment keys into fixed-length coded sequences, which are then input into a fingerprint calculation function. The fingerprint calculation function maps these coded sequences into evidence fingerprints, which are written into a fingerprint table. Each entry in the fingerprint table contains a record linking the evidence fingerprint to the document key.

[0069] The generated evidence fingerprint can uniquely identify each matching pair and is used in subsequent evidence verification, query review and version update processes.

[0070] During the processing of user annotations, the evidence module receives relevance feedback from user annotations and updates the synonym table, slicing rule table, and plan template table based on these annotations. The relevance feedback from user annotations can include annotation results on the degree of matching between a certain document and the query segment. The annotations include a relevance score (e.g., 1 indicates relevance, 0 indicates irrelevance) and possible reasons for exclusion (e.g., low similarity, segment mismatch, etc.).

[0071] The evidence module writes the annotation results into an annotation sample table, which includes document keys, query fragment keys, relevance scores, and annotation types. Based on the annotation sample table, the evidence module performs incremental updates to the synonym table. These updates include adding synonym mappings, deleting invalid synonym mappings, and updating the confidence flags of synonym mappings, thereby improving the accuracy and flexibility of subsequent search results. The evidence module also performs incremental updates to the slicing rule table and the plan template table based on the annotation sample table. Updates to the slicing rule table include updating fragment boundary rules, dependency chain restriction rules, and fragment type determination rules. Updates to the plan template table include updating constraint consistency verification rules, execution sequence generation rules, and rollback rules, ensuring that the system can dynamically adapt to new input data and query requirements.

[0072] In summary, the evidence module provides a reliable guarantee of retrieval accuracy for the system through the alignment of query fragments and candidate document fragments, evidence generation, and closed-loop feedback updates of user annotations, ensuring the accuracy and consistency of each query result, while also providing strong data support for subsequent retrieval optimization and strategy adjustment.

[0073] Example 2: A patent intelligent retrieval method supporting multi-dimensional features, such as... Figure 2As shown, it specifically includes: It can access patent title, abstract, claims, and specification text; classification field, subject field, time field; family relationship, citation relationship and legal status data; implement subject unification and family merging; and generate document key and relationship key. Expand the claim reference chain and parse the limiting structure, extract component fragments, relationship fragments, action fragments, and constraint fragments, generate fragment keys, and record fragment position identifiers and claim position identifiers; Inverted indexes and vector tables are constructed based on fragment keys, field tables are constructed based on fields, and relation tables are constructed based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers. Receive query input and parse it into query fragments and constraint terms, perform constraint consistency checks and generate execution sequences, expansion rules and rollback rules; The recall is performed in the inverted index, vector table, field table and relation table according to the execution sequence and the path identifier is recorded to obtain the candidate document set. A coverage matrix is ​​constructed based on the query fragment and the candidate document fragment. A fused sorted list is generated according to the constraint satisfaction item, the coverage matrix matching item and the path identifier. Based on the location identifier, the query fragments and candidate document fragments are aligned, an evidence table and evidence fingerprints are generated, user annotations are received, and the synonym table, slicing rule table and plan template table are updated accordingly.

[0074] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0075] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0076] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0077] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0078] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A patent intelligent retrieval system supporting multi-dimensional features, characterized in that: It includes an access module, a slicing module, a search module, a planning module, a fusion and sorting module, and an evidence module, with each module connected by a signal. The access module is used to access patent titles, abstracts, claims, specification texts, classification fields, subject fields, time fields, family relationships, citation relationships and legal status data, perform subject unification and family merging, and generate document keys and relationship keys. The slicing module is used to expand the claim reference chain and parse the limiting structure, extract component fragments, relationship fragments, action fragments, and constraint fragments, generate fragment keys, and record fragment position identifiers and claim position identifiers; The indexing module is used to build inverted indexes and vector tables based on fragment keys, field tables based on fields, and relation tables based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers. The planning module is used to receive query input and parse it into query fragments and constraint items, perform constraint consistency checks, and generate execution sequences, extended rules, and rollback rules. The fusion and ranking module is used to perform recall and record path identifiers in the inverted index, vector table, field table and relation table according to the execution sequence to obtain a candidate document set. It constructs a coverage matrix based on the query fragment and candidate document fragments, and generates a fusion and ranking list based on the constraint satisfaction items, coverage matrix matching items and path identifiers. The evidence module is used to align query fragments and candidate document fragments based on location identifiers, generate an evidence table and an evidence fingerprint, receive user annotations, and update the synonym table, slicing rule table and plan template table accordingly.

2. The patent intelligent retrieval system supporting multi-dimensional features according to claim 1, characterized in that: The access module performs entity normalization and family merging, and generates document keys and relation keys, including: Read the main fields and perform character normalization, alias merging and field decomposition to generate the main key and establish a mapping table between the main key and the main fields; Read the time field and perform time expression normalization, generate time keys and establish a mapping table between time keys and time fields; Priority information and family association information are extracted based on clan relationships. Clan merging is performed to generate clan keys and a relationship table between clan keys and document keys is established. Citation pairs are extracted based on citation relations and citation keys are generated. Relation keys are generated based on family keys and citation keys and written into the relation mapping library. The classification field, subject key, time key, legal status data, and document key are associated and written into the document identifier database.

3. The patent intelligent retrieval system supporting multi-dimensional features according to claim 1, characterized in that: The slicing module expands the claim reference chain and parses the limiting structure to generate fragment keys and records the fragment position identifier and the claim position identifier, including: Based on the text of the claims, the claim item number and the reference pointer are extracted, a reference list is constructed, and the referenced content is expanded according to the reference list to generate the expanded text of the claim item. The text of the weights is expanded to perform phrase boundary segmentation and dependency parsing to obtain a sequence of bounded units and construct a bounded dependency chain. Extract component fragments, relation fragments, action fragments, and constraint fragments from the constrained unit sequence, generate fragment keys based on the normalized word sequence, and write them into the fragment mapping table; Record the fragment position identifier and the weight position identifier for the fragment key. The fragment position identifier includes the start offset and the end offset, and the weight position identifier includes the weight number and the segment number.

4. The patent intelligent retrieval system supporting multi-dimensional features according to claim 1, characterized in that: The planning module performs constraint consistency checks on the query input and generates execution sequences, expansion rules, and rollback rules, including: It receives query input and parses it into query fragments and a set of constraints. The set of constraints includes category constraints, subject constraints, time constraints, and legal status constraints. Conflict detection is performed based on the set of constraints. Conflict detection includes field missing conflict, range inclusion conflict and mutual exclusion conflict, and a conflict identification table is generated. Based on the conflict identifier table, rollback rules are generated. The rollback rules include the order and extent of constraint relaxation, and an executable constraint set is generated. An execution sequence is generated based on the set of executable constraints. The execution sequence includes the sequence identifiers of the field filtering stage, the relation expansion stage, and the fragment recall stage. Generate extension rules and bind them to the relationship table. The extension rules include extension direction identifier, extension level identifier, and termination condition identifier.

5. A patent intelligent retrieval system supporting multi-dimensional features according to claim 3, characterized in that: The indexing module constructs inverted and vector tables based on fragment keys, field tables based on fields, and relation tables based on family and citation relationships. Each table is associated with a document key, fragment key, and position identifier, including: The fragment text corresponding to the fragment key is segmented and normalized, a term sequence is generated, and an inverted entry from term to fragment key is established. The inverted entry is written with the document key, weight position identifier and fragment position identifier. Fragment vectors are generated based on fragment text, fragment type and limited dependency chain and written into a vector table. The vector table entries are written with document key, weight position identifier and fragment position identifier. Write the classification field, subject key, time key, and legal status into the field table, and associate the field table entries with the document key; Write the family key and citation key into the relation table, associate the relation table entries with the document key and write the relation direction identifier.

6. A patent intelligent retrieval system supporting multi-dimensional features according to claim 4, characterized in that: The fusion and sorting module performs recall operations on the inverted index, vector table, field table, and relation table according to the execution sequence, records path identifiers, and generates a fused and sorted list, including: The field-based filtering stage performs filtering on the document keys based on the field table to obtain an initial candidate document set and generate field path identifiers; In the relation expansion phase, the initial candidate document set is expanded based on the relation table to obtain an expanded candidate document set and generate relation path identifiers. In the fragment recall phase, fragment matching is performed on the expanded candidate document set based on the inverted index and vector table to obtain the candidate document fragment set and generate fragment path identifiers; The system merges field path identifiers, relationship path identifiers, and fragment path identifiers to generate path identifiers, and then generates a merged sorted list based on these path identifiers.

7. A patent intelligent retrieval system supporting multi-dimensional features according to claim 6, characterized in that: The fusion and ranking module constructs a coverage matrix based on the query fragment and candidate document fragments, and generates a fused and ranked list according to constraint satisfaction terms, coverage matrix matching terms, and path identifiers, including: The query fragments are matched with candidate document fragments according to fragment type and fragment vector similarity threshold conditions to obtain a set of matching pairs; A coverage matrix is ​​constructed based on the set of matching pairs. The rows of the coverage matrix correspond to the query fragment keys, the columns correspond to the candidate document fragment keys, and the matrix cells are written with matching identifiers, position consistency identifiers, and weight consistency identifiers. Constraint satisfaction items are generated based on field constraints and relational constraints, and these constraint satisfaction items are bound to candidate document keys. A fusion ranking list is generated based on constraint satisfaction terms, coverage matrix matching terms, and path identifiers, and a candidate document set is output.

8. A patent intelligent retrieval system supporting multi-dimensional features according to claim 7, characterized in that: The evidence module aligns query fragments and candidate document fragments based on location identifiers and generates an evidence table, including: Read the candidate document fragment set and aggregate the fragment keys and fragment position identifiers according to the document key to form a candidate document fragment mapping table; Read the query fragments and form a query fragment mapping table. Write the query fragment key and the query fragment position identifier into the query fragment mapping table. Fragment alignment is performed based on the query fragment mapping table and the candidate document fragment mapping table. Fragment alignment includes fragment type consistency verification, position consistency verification and weight consistency verification, generating a set of alignment matching pairs. Write the set of aligned matching pairs into the evidence table. Write the document key, weight position identifier, fragment position identifier, query fragment key, and candidate document fragment key into the evidence table entries.

9. A patent intelligent retrieval system supporting multi-dimensional features according to claim 8, characterized in that: The evidence module generates evidence fingerprints based on the evidence table and establishes the association between the evidence fingerprints and the document keys, including: The evidence list entries are sorted according to the document key and the weight position identifier, and an evidence sequence is generated. Perform normalized encoding on the query fragment key and candidate fragment key in the evidence sequence and generate an encoded sequence; The encoded sequence is input into the fingerprint calculation function to generate evidence fingerprints and written into the fingerprint table. The fingerprint table entries are written into the evidence fingerprint and document key. The evidence fingerprint is associated with the path identifier and written into the traceability table. The traceability table entries are written with the evidence fingerprint and the path identifier.

10. A patent intelligent retrieval method supporting multi-dimensional features, used to implement the patent intelligent retrieval system supporting multi-dimensional features as described in any one of claims 1-9, characterized in that, include: It can access patent title, abstract, claims, and specification text; classification field, subject field, time field; family relationship, citation relationship and legal status data; implement subject unification and family merging; and generate document key and relationship key. Expand the claim reference chain and parse the limiting structure, extract component fragments, relationship fragments, action fragments, and constraint fragments, generate fragment keys, and record fragment position identifiers and claim position identifiers; Inverted indexes and vector tables are constructed based on fragment keys, field tables are constructed based on fields, and relation tables are constructed based on family relationships and citation relationships. Each table is associated with document keys, fragment keys, and position identifiers. Receive query input and parse it into query fragments and constraint terms, perform constraint consistency checks and generate execution sequences, expansion rules and rollback rules; The recall is performed in the inverted index, vector table, field table and relation table according to the execution sequence and the path identifier is recorded to obtain the candidate document set. A coverage matrix is ​​constructed based on the query fragment and the candidate document fragment. A fused sorted list is generated according to the constraint satisfaction item, the coverage matrix matching item and the path identifier. Based on the location identifier, the query fragments and candidate document fragments are aligned, an evidence table and evidence fingerprints are generated, user annotations are received, and the synonym table, slicing rule table and plan template table are updated accordingly.

Images