A knowledge graph-based enterprise intellectual property service matching and risk early warning method

Abstract

The application relates to the technical field of computer data processing, and discloses a kind of enterprise intellectual property service matching and risk early warning method based on knowledge graph, the present application obtains the asset event set corresponding to same patent asset, generates uniform asset identification, encapsulates asset event as event fragment associated with event source, arrival time sequence, effective time sequence, event source level and pre-event association, and is written into asset state knowledge graph;Asynchronous event checking processing is performed on the asset state knowledge graph, the current asset undertaking state is generated, and the transaction annual fee conflict mark is written when there is time overlap between the transaction performance state and the annual fee period state and the official state event is not completed undertaking;Generate transaction operation permission field based on the current asset undertaking state, control display interface, order interface and performance confirmation interface;And generate the renewal warning message routing record and then write back to the asset state knowledge graph.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method for matching and risk warning of enterprise intellectual property services based on knowledge graphs. Background Technology

[0002] As enterprise intellectual property data service platforms gradually undertake continuous services such as patent transactions, annual fee monitoring, ownership verification, and message alerts, the same patent asset often participates in multiple processing stages simultaneously within the platform. Taking an invention patent to be transferred as an example, after the service provider completes the listing of the patent resource on the platform, the purchaser may initiate an inquiry and enter the order process based on technical field and application needs. The transaction service then records the payment progress, contract generation status, and performance confirmation results. At the same time, the patent may still be bound to the original enterprise account in the annual fee monitoring ledger. The annual fee monitoring service will monitor the annual fee according to the official annual fee period and grace period. When generating reminder tasks, the update times of order events, official ownership status, and annual fee status within the platform are not entirely consistent. When a transaction has entered the performance stage but the official ownership has not yet been updated, the annual fee warning may still be generated along with the original binding relationship. When the annual fee deadline is approaching, the transaction page may still display the patent according to the conventional matching results. Such situations are more likely to occur in platforms that operate in parallel with high-frequency transactions, batch annual fee monitoring, and asynchronous message push. Especially when there is a time difference in official data updates, the processing basis for the same patent asset on the transaction page, monitoring ledger, and message notification may be temporarily inconsistent.

[0003] Existing intellectual property service systems typically handle patent listing, supply and demand matching, order tracking, annual fee calculation, and tiered reminders within their respective business chains. This improves the efficiency of patent operation and asset management. However, in an integrated platform scenario, when the same patent asset is simultaneously in the transaction fulfillment process and the annual fee warning period, relying solely on the order status in the transaction module to determine whether to continue the transaction operation, or solely on the asset binding relationship in the annual fee monitoring module to determine the reminder recipient, may not accurately reflect the patent's current comprehensive status. This is especially true when the buyer has already paid, the contract has been generated, the fulfillment has not yet been confirmed, the official ownership has not yet taken effect, and the annual fee deadline is approaching. The system needs to first determine whether the platform business event and the official status event can be inherited, then determine whether the transaction should enter a confirmed, restricted, or blocked state, and further determine the main recipient and confirmation recipient of the renewal reminder. Therefore, when existing platforms process the same patent asset across modules, they need to establish an event inheritance mechanism based on a unified asset identifier, so that the transaction fulfillment status, official status, annual fee period, and warning records can be consistently verified under the same data path, thereby reducing inconsistencies between transaction license outputs and renewal warning recipients. Summary of the Invention

[0004] This application proposes a knowledge graph-based method for matching and risk warning of enterprise intellectual property services to address the problems mentioned in the background art.

[0005] To achieve the above objectives, this application adopts the following technical solution: a knowledge graph-based method for matching and risk warning of enterprise intellectual property services, comprising the following steps: The system obtains the set of asset events corresponding to the same patent asset in the enterprise intellectual property service platform, generates a unified asset identifier using the asset normalization method, and then uses the event encapsulation method to convert the asset events into event fragments that carry the event source, arrival time, effective time, event source level and associated preceding events. The event fragments are then written into the asset status knowledge graph according to the unified asset identifier. Asynchronous event verification processing is performed on the asset status knowledge graph to generate the current asset acceptance status. The asynchronous event verification processing isolates out-of-order events according to the association of preceding events and the effective time sequence. Then, it verifies the acceptance relationship between platform business events and official status events according to the event source level. When there is a time overlap between the transaction fulfillment status and the annual fee period status and the official status event has not been completed, a conflict flag is written. Perform transaction license mapping processing on the current asset acquisition status, generate a transaction operation license field, write the transaction operation license field into the patent transaction service, and the patent transaction service performs the opening processing of the display interface, order placement interface and performance confirmation interface according to the transaction operation license field; Perform early warning routing processing on the current asset takeover status, generate renewal early warning message routing records, and encapsulate the renewal early warning message routing records into event fragments before writing them back to the asset status knowledge graph.

[0006] The beneficial effects of this invention are as follows: This invention forms an asynchronous acceptance verification chain through pre-event association, effective sequence, and event source level. When the transaction fulfillment period and annual fee period overlap and the official status event has not yet been completed, the system writes a transaction annual fee conflict flag. This ensures that transaction operations no longer depend solely on order status, and renewal warnings no longer depend solely on the original annual fee binding relationship. Based on this conflict flag, the system generates transaction operation permission fields for restricted display, closed order placement, and closed fulfillment confirmation. On the other hand, it routes the renewal warning to the renewal processing node and transaction processing node corresponding to the same unified asset identifier. This reduces the misalignment between transaction permission and annual fee warning objects when official ownership synchronization lags, transaction fulfillment progresses, and the annual fee period approaches simultaneously, thereby improving the consistency of cross-module intellectual property service processing and the accuracy of risk handling. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort: Figure 1 A schematic diagram illustrating the encapsulation of asset events and the construction of an asset status knowledge graph; Figure 2 This diagram illustrates the asynchronous event verification and conflict flag formation. Detailed Implementation

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

[0009] like Figure 1 and Figure 2 As shown, this invention discloses a method for matching and risk warning of enterprise intellectual property services based on knowledge graphs, including the following steps: Before performing asynchronous event verification processing, the enterprise intellectual property service platform obtains the set of asset events corresponding to the same patent asset, generates a unified asset identifier using the asset normalization method, and then uses the event encapsulation method to convert the asset event into an event fragment carrying the event source, arrival time, effective time, event source level and associated preceding events. The event fragment is then written into the asset status knowledge graph according to the unified asset identifier.

[0010] The asset event set includes platform transaction records, annual fee monitoring records, early warning message records, and official status synchronization records. Platform transaction records are generated by the patent transaction service and record the platform transaction process formed by patent listing, order placement, payment, contract generation, performance confirmation, and transaction cancellation. Annual fee monitoring records are generated by the annual fee monitoring service and record term monitoring tasks and renewal reminder tasks. Early warning message records are generated by the message early warning service and record early warning sending results and response results. Official status synchronization records are generated by the official status synchronization service and record the rights status, payment status, term status, and ownership change status. The asset events in the asset event set carry number information used to identify patent assets, platform reception time, and business effective time. The platform reception time is used to form the arrival sequence, and the business effective time is used to form the effective sequence. This step only processes asset events that have been received by the enterprise intellectual property service platform. Asset events that enter the platform late form new event fragments after being received and are read by subsequent asynchronous event verification processing in the new round of processing.

[0011] Taking a proposed invention patent on the platform as the subject of implementation, this patent has an example platform asset number KCIP-XXX-001 and an example patent application number of 2024XXXXXXXX.X within the enterprise intellectual property service platform. It has also generated an example publication number CNXXXXXXXXXA and an example authorization announcement number CNXXXXXXXXXB. After the service provider lists the patent in the patent transaction service, the purchaser initiates an order. The same patent asset is still bound to the annual fee monitoring ledger by the original enterprise account. The annual fee monitoring service generates renewal reminder tasks according to the term status. The official status synchronization service then synchronizes the payment status and ownership status of the patent. Since the time when the platform receives the asset event is not necessarily consistent with the business effective time of the asset event, the system saves the arrival time sequence and the effective time sequence respectively.

[0012] In the asset unification method, the system first performs unified numbering format processing on the asset events in the asset event set. The unified numbering format processing includes deleting invalid spaces at the beginning and end of the number, converting full-width characters to half-width characters, converting connectors and separators to the platform's preset format, and saving the correspondence between the original number and the unified numbering information. The unified numbering format processing does not change the character sequence of the official number itself. For platform asset numbers, the system retains its attribute as an internal index of the platform; for patent application numbers, publication numbers, and authorization announcement numbers, the system retains their attribute as the basis for official number verification.

[0013] Existing asset indexes can be implemented through the asset master table and the asset index table. The asset master table records the unified asset identifier, platform asset number, and asset master status. The asset index table records the unified asset identifier, patent application number, publication number, authorization announcement number, and their effective period. When the system searches for existing asset indexes, it first searches for the platform asset number in the asset master table, and then searches for the official number in the asset index table.

[0014] The system uses standardized numbering information to retrieve existing asset indexes. For asset events carrying platform asset numbers, the system reads the existing asset index corresponding to that platform asset number. When an asset event also carries an official number, the system performs a consistency check between the official number in the asset event and the official number registered in the existing asset index. If the official numbers match, the system assigns the asset event to the corresponding unified asset identifier. If the official numbers do not match, the system writes the asset event to a pending verification state and writes it to an isolated path in the asset status knowledge graph. When an asset event does not carry an official number and its source is patent transaction service or annual fee monitoring service, the system assigns the asset event to the corresponding unified asset identifier according to the platform asset number and writes a default official number marker in the event fragment. When an asset event does not carry an official number and its source is official status synchronization service, the system writes the asset event to a pending verification state and writes it to an isolated path.

[0015] For asset events without a platform asset number, the system uses the official number to retrieve existing asset indexes. The system uses the patent application number as the main index for official numbers and the publication number and authorization announcement number as stage status verification fields. The patent application number is used to associate the same patent asset across the publication stage, authorization stage, and official status synchronization stage. The publication number and authorization announcement number are used to verify whether the publication status and authorization status corresponding to the asset event are consistent with the existing asset index. After the official number retrieval hits an existing asset index, the system compares the business effectiveness time of the asset event with the effectiveness sequence of the event fragments already included in the diagram. If the business effectiveness time does not form a mutually exclusive relationship with the official status events that have already taken effect under the same unified asset identifier, the system classifies the asset event into the corresponding unified asset identifier. If the business effectiveness time forms a mutually exclusive relationship, the system writes the asset event to the pending verification status and writes it to the isolation path.

[0016] Mutual exclusion relationships are identified based on the official number, effective time sequence, and status field under the same unified asset identifier. Same effective time periods include two categories: identical date-level status dates and overlapping time intervals. For statuses without an end time, the period from the previous status's effective time to the next status's effective time is used as the status interval. If the same patent application number is simultaneously registered as a valid asset master record by two different platform asset numbers within the same effective time period, and there is no duplicate listing association between the two platform asset numbers, the system identifies it as mutually exclusive asset identity. If the same platform asset number corresponds to two different patent application numbers within the same effective time period, the system identifies it as mutually exclusive official number. When conflicting payment statuses appear in the same official synchronous batch, the system identifies it as mutually exclusive official status. Duplicate listing associations originate from the platform asset number affiliation relationship under the same unified asset identifier recorded in the asset index. If this affiliation relationship does not exist, the two platform asset numbers are not considered to have formed a duplicate listing association. The identification result of mutual exclusion relationships is only used for path access of asset events and does not generate transaction operation permission fields or renewal warning message routing records.

[0017] For asset events that are not matched in the search, the system generates a temporary unified asset identifier and writes the corresponding asset event into the pending verification state. The temporary unified asset identifier is preferably formed by the platform date, the source service tag, and the incrementing sequence number. In a multi-node deployment scenario, the incrementing sequence number is formed by the node identifier and the incrementing sequence number of the current node. The platform date comes from the date the asset event enters the candidate normalization queue, the source service tag comes from the event source, and the incrementing sequence number is generated by the platform asset normalization service. Asset events in the pending verification state are written into the isolation path. The isolation path is separated from the valid event path used for subsequent processing. Asset events in the isolation path retain the event tracing entry and candidate attribution information and are not used as direct input for transaction permission mapping processing and early warning routing processing.

[0018] In this implementation, the admission criteria for an asset event to enter a valid event path are as follows: the asset event has been assigned to a unified asset identifier, the number information in the asset event is consistent with the corresponding asset index, the effective sequence of the asset event does not form a mutually exclusive relationship with the official status event under the same unified asset identifier, and the source of the event can be identified as patent transaction service, annual fee monitoring service, message alert service, or official status synchronization service. If any admission criterion is not met, the system writes the asset event to the pending verification status and writes it to the isolation path. This step does not perform valid acceptance confirmation on the asset events in the isolation path. The asset events in the isolation path are read by subsequent asynchronous event verification processing.

[0019] After completing the asset normalization process, the system uses event encapsulation to process normalized asset events. The system reads normalized asset events according to the unified asset identifier, converts the normalized asset events into event fragments, and during the conversion, the system writes the source service field into the event source, the platform receiving time and the incremental sequence number within the same service into the arrival time sequence, the business effective time into the effective time sequence, and the ordered code corresponding to the source service field into the event source level. After retrieving candidate preceding event fragments according to the business chain identifier, the system writes them into the preceding event association. If the event source cannot be identified, the system does not assign a valid event source level and writes the corresponding asset event into the pending verification status and isolation path.

[0020] Arrival sequence is preferably formed by combining the platform message reception time and the incremental sequence number within the same service. The recording accuracy of the platform message reception time is determined by the platform log system configuration, preferably at the second to millisecond level. When the platform log system only supports second-level recording, the incremental sequence number within the same service is used as the sorting basis for events within the same second. The effective sequence is formed by the effective time of the business status of the service to which the asset event belongs. Specifically, the effective sequence of the patent transaction service is the order status change time, the effective sequence of the annual fee monitoring service is the monitoring task generation time, the effective sequence of the message alert service is the message sending completion time, and the effective sequence of the official status synchronization service is the status effective time in the official status record. When the status time provided by the official status synchronization service only reaches the date level, the system forms the effective sequence based on the official status date and uses the official synchronization batch order to distinguish multiple official status events within the same date. When there are mutually exclusive official status events within the same official status date and the same official synchronization batch, the system writes the corresponding event fragment into the pending verification status.

[0021] The event source level is used to indicate the credible order of updates to the current asset status from different sources. The event source level preferably uses an ordered code of 2 to 4, with the code value serving as a source sorting marker. The preferred event source level for the official status synchronization service is 4, for the patent transaction service and annual fee monitoring service it is 3, and for the message alert service it is 2. This value is based on the different services' ability to prove the asset status field: the official status synchronization service provides rights status, payment status, and term status; the patent transaction service and annual fee monitoring service provide in-platform transaction progress and term monitoring progress; and the message alert service provides notification and response actions. The event source level is not used to indicate whether an event fragment is in a pending verification state; the pending verification state is expressed through an isolation path and a pending verification marker.

[0022] In this implementation, the event field mapping table records at least the source service identifier, event type, original event field, platform unified status field, business chain identifier field, effective time sequence field, pending acceptance status field, target status value, same-day sequence number, mapping version number, and whether an official acceptance mark is required. The event field mapping table is formed by the service interface definition and business status configuration of the enterprise intellectual property service platform, and the mapping version number is saved synchronously with the service interface version. When the service version to which an event fragment belongs is inconsistent with the mapping version number, the corresponding event fragment is written into the acceptance confirmation event set, and the acceptance confirmation reason is recorded as "field mapping version pending confirmation."

[0023] For contract generation events in patent transaction services, the event field mapping table maps the event type to a contract generation event, the original contract status field to a transaction process status field, the status value to "contract generated," the business chain identifier field to an order number, and the effective time sequence field to the contract generation time. It also considers order placement or listing events under the same order number as candidate preceding event fragments. For payment completion events, the event field mapping table maps the original payment status field to a transaction process status field, the status value to "payment completed," the business chain identifier field to an order number, and the effective time sequence field to the payment completion time. It also considers contract generation events under the same order number as candidate preceding event fragments. For performance confirmation events, the event field mapping table maps the original performance status field to a transaction performance status field, and the status value to "performance pending confirmation" or "performance confirmed." When a performance confirmation event requires waiting for official ownership status acceptance, the event field mapping table records the pending acceptance status field as the ownership status and the target status value as "ownership change completed."

[0024] For ownership status events in the official status synchronization service, the event field mapping table maps official ownership change records to ownership status fields, and maps official status values ​​indicating that the transferee's ownership has taken effect to ownership change completion. For term status events in the official status synchronization service, the event field mapping table maps official annual fee term records to term status fields, official term dates to term dates, and official grace period expiration information to grace period end dates. For term monitoring tasks in the annual fee monitoring service, the event field mapping table maps task asset numbers to unified asset identifier verification fields, task term dates to term dates, and task numbers to term monitoring task identifiers. When an annual fee monitoring task and an official term status event both correspond to the same unified asset identifier and their term dates are consistent, the system confirms that they both point to the same term endpoint; when an official term status event records a grace period end date, the grace period end date is used as the term endpoint.

[0025] When multiple platform transaction events occur on the same day or within the same effective time sequence, the system first determines the order based on the incremental sequence number within the same service. If the incremental sequence number within the same service is missing, the system reads the platform's business status flow configuration table to determine the order. The contract generation event precedes the payment completion event, the payment completion event precedes the performance confirmation event, and the transaction cancellation event and performance termination event are used to end the transaction performance period. If the order cannot be determined based on the incremental sequence number within the same service and the platform's business status flow configuration table, the system writes the corresponding event fragment into the acceptance confirmation event set and records the acceptance confirmation reason as a pending confirmation event.

[0026] Preceding event associations are used to record candidate preceding event fragments for the current event fragment. When the system generates preceding event associations, it reads the business chain identifier in the asset event. When the asset event carries an order number, the system searches for candidate preceding event fragments along the same order number; when the asset event carries an early warning task number, the system searches for candidate preceding event fragments along the same early warning task number; when the asset event carries an official synchronization batch number, the system searches for candidate preceding event fragments along the same official synchronization batch number. Taking the patent corresponding to the platform asset number KCIP-XXX-001 as an example, when the order event carries an order number, the system prioritizes consulting event fragments already written under the same order number as candidate preceding event fragments; if no consulting event fragments under the same order number exist, the system will... The system uses the listing event fragment under the corresponding unified asset identifier as a candidate preceding event fragment. When the payment event carries the same order number, the system uses the order placement event fragment as a candidate preceding event fragment. When the warning response event carries the warning task number, the system uses the warning sending event fragment as a candidate preceding event fragment. When a candidate preceding event fragment is found, the system writes the identifier of the candidate preceding event fragment into the preceding event association of the current event fragment. When no candidate preceding event fragment is found, the system writes the current event fragment into the acceptance confirmation status and writes the acceptance confirmation flag. The acceptance confirmation status indicates that the current event fragment lacks a referenceable candidate preceding event fragment. After the subsequent asynchronous event verification process reads the acceptance confirmation flag, it will not use the event fragment as an acceptance completion event.

[0027] In this implementation, the acceptance confirmation event set, out-of-order event set, ownership conflict pending confirmation status, and source conflict pending confirmation status are all persistently written into the asset status knowledge graph in the form of event fragments, and simultaneously written into the pending confirmation index. The pending confirmation index records at least the unified asset identifier, event fragment identifier, pending confirmation type, pending confirmation reason, business chain identifier of missing preceding events, pending acceptance status field, target status value, initial write threshold, most recent verification threshold, number of reviews, and pending confirmation valid status. Pending confirmation valid status includes pending review, accepted, expired, and replaced. The pending confirmation index does not cover the original event fragments, but only records the acceptance results of the event fragments under different verification batches.

[0028] When subsequent verification batches begin, in addition to reading new event fragments received by the platform that are later than the previous verification threshold but not later than the current verification threshold, the system also reads pending confirmation index records under the same unified asset identifier whose pending confirmation status is "pending review." For event fragments whose acceptance confirmation reason is missing prerequisites, the system re-searches for candidate prerequisite event fragments according to the business chain identifier, order number, early warning task number, or official synchronization batch number. When a candidate prerequisite event fragment that entered the platform late is found, and the candidate prerequisite event fragment passes the unified asset identifier verification and the effective sequence verification, the system writes the event fragment identifier of the candidate prerequisite event fragment into the prerequisite event association of the current event fragment, and updates the pending confirmation status of the corresponding pending confirmation index to "accepted." The current event fragment then exits the acceptance confirmation event set and enters the effective sequence verification process.

[0029] For event fragments in the out-of-order event set, after subsequent verification batches read new candidate preceding event fragments or new official status events, the system re-compares the effective sequence of the current event fragment with that of the candidate preceding event fragments. If the re-comparison satisfies the order in the platform's business status flow configuration table, the system removes the event fragment from the out-of-order event set and updates the pending-confirmation status to "accepted." For event fragments in the pending-confirmation status of source conflict, when subsequent verification batches read official status events with higher event source levels and the same status field value, the system uses the official status event as the basis for status confirmation, updates the original pending-confirmation status of source conflict to "replaced," and records the replacement acceptance result in the current asset acceptance status. If the official status event still records mutually exclusive status values, the pending-confirmation status of source conflict remains "pending review."

[0030] The conditions for clearing the acceptance confirmation mark are: a candidate preceding event fragment has been retrieved under the same unified asset identifier, the effective timing verification has passed, the field mapping version is consistent, and the status field requiring official acceptance has been confirmed by the official status event. If any of the aforementioned conditions are not met, the acceptance confirmation mark will not be cleared. The longest backtracking period for the pending confirmation index is determined according to the greater of the order fulfillment cycle and the official status synchronization cycle, preferably 30 to 120 days; if the clearing conditions are not met even after the longest backtracking period, the system will update the pending confirmation valid status to expired, and retain the event fragment in the isolation path or the pending confirmation path, and it will not be used as the basis for generating the transaction fulfillment interval, annual fee period interval, and early warning routing object.

[0031] After an event fragment is generated, the system writes it into the asset status knowledge graph according to the unified asset identifier. The asset status knowledge graph is centered on the patent asset node, which carries the unified asset identifier. The event fragment acts as an event node connected to the patent asset node. The event path represents the writing relationship between events from different sources and the patent asset node. Official status events are written into the official status event path, platform events are written into the platform event path, and message alert events are written into the alert write-back path. The official status event path is used to record the right status, payment status, and term status obtained by the official status synchronization service. The platform event path is used to record the platform business status generated by the patent transaction service and the annual fee monitoring service. The alert write-back path is used to record the renewal alert message routing record, message sending result, and response result generated by the message alert service. The event fragments in the platform event path and the alert write-back path do not cover the status fields in the official status event path. The right status, payment status, and term status in the official status event path are only updated by the event fragments generated by the official status synchronization service.

[0032] During the example operation, the service provider listed the invention patent corresponding to KCIP-XXX-001 on [Date] 202X. The patent transaction service generated a listing event, which carried the platform asset number and patent application number. The system categorized it into the corresponding unified asset identifier and wrote it into the platform event path. The purchaser initiated an order on [Date] 202X. The patent transaction service generated an order event. This event prioritized obtaining the consultation event as a candidate preceding event fragment along the order number. If no consultation event existed, the listing event under the same unified asset identifier was obtained as a candidate preceding event fragment and written into the platform. The event path is as follows: The annual fee monitoring service generates a renewal reminder task on XX / XX / 202X. This task uses the same unified asset identifier and is written into the platform event path. The official status synchronization service synchronizes the annual fee term status of the patent on XX / XX / 202X. This event carries the patent application number and the effective time of the official status. The system writes it into the official status event path. The message alert service sends a renewal reminder and forms an alert sending event on XX / XX / 202X. This event is written into the alert write-back path. Neither the annual fee monitoring event nor the alert write-back event covers the term status in the official status event path.

[0033] In this embodiment, when the asset status knowledge graph is implemented using a graph database, patent asset nodes, event fragment nodes, and event paths are stored in the form of nodes and edges; when implemented using a relational database, the unified asset identifier is stored in the asset master table, the event fragment is stored in the event details table, and the event path is expressed by the event source field and the preceding event association field. Different storage implementations maintain the correspondence between the unified asset identifier, event fragment, event source, arrival time, effective time, event source level, preceding event association, isolated path, valid event path, official status event path, platform event path, and early warning write-back path.

[0034] Specifically, patent asset nodes should at least store the unified asset identifier, platform asset number, patent application number, publication number, authorization announcement number, asset master status, and current effective water level. Event fragment nodes should at least store the event fragment identifier, original asset event index, event source, event type, arrival sequence, effective sequence, event source level, business chain identifier, preceding event association, status field name, status field value, path status, acceptance status, acceptance confirmation reason, and event water level. Event paths should at least store the path type, starting event fragment identifier, target event fragment identifier, preceding relationship type, and path write time.

[0035] Path type is used to define the role of event fragments in subsequent processing. Path status in isolated paths is recorded as pending verification, ownership conflict, or field mapping pending confirmation; event fragments in isolated paths do not serve as endpoint sources for transaction fulfillment intervals and annual fee term intervals. Path status in valid event paths is recorded as valid; only event fragments located in valid event paths can enter asynchronous event verification processing. Official status event paths are used to store ownership status, payment status, and term status written by the official status synchronization service. Platform event paths are used to store platform process status written by the patent transaction service and annual fee monitoring service. Warning write-back paths are used to store renewal warning message routing records, message sending results, and response results. Status fields in platform event paths and warning write-back paths do not overwrite status fields in official status event paths.

[0036] When subsequent batches of data are read from the asset status knowledge graph, the patent asset node is first locked according to the unified asset identifier, and then event fragments are filtered according to path type and path status. Isolated paths serve to exclude and await review, platform event paths serve to establish transaction fulfillment status, official status event paths serve to confirm official acceptance and deadlines, and warning write-back paths serve to exclude duplicate routes and trace warning actions. Thus, event paths, status fields, isolated paths, and valid paths form a fixed correspondence in the data model.

[0037] Upon completion of this step, the system outputs an asset status knowledge graph. This knowledge graph provides subsequent steps with a unified asset identifier, event fragment, event source, arrival sequence, effective sequence, event source level, and associated preceding events. Subsequent asynchronous event verification processing identifies out-of-order arrivals, late updates, source conflicts, and interrupted acceptance based on event fragments within the same patent asset scope, and generates the current asset acceptance status.

[0038] After step S1 is completed, the enterprise intellectual property service platform has formed an asset status knowledge graph around the same patent asset corresponding to the example platform asset number KCIP-XXX-001. In this asset status knowledge graph, the listing event, contract generation event, and payment completion event generated by the patent transaction service are written into the platform event path; the term monitoring task generated by the annual fee monitoring service is written into the platform event path; the term status event generated by the official status synchronization service is written into the official status event path; and the warning sending event generated by the message warning service is written into the warning write-back path. Step S2 performs asynchronous event verification processing based on this asset status knowledge graph to generate the current asset acceptance status. The current asset acceptance status is used to record the acceptance classification results of event fragments in this batch, including acceptance completed, acceptance confirmed, out of order, attribution conflict, source conflict, interval pending confirmation, and transaction annual fee conflict.

[0039] This step processes event fragments under the same unified asset identifier. The event fragment retains its original asset event index. The system reads the event type, business chain identifier, status field, and term field through the original asset event index. The event type is used to distinguish between patent transaction events, annual fee monitoring events, official status events, and message warning events. The business chain identifier is used to retrieve candidate preceding event fragments under the same order number, the same warning task number, and the same official synchronization batch number. The status field is used to verify the succession relationship between platform business events and official status events. The term field is used to form the annual fee term status. The event type, business chain identifier, status field, and term field all come from the asset events that have been written into the asset status knowledge graph in step S1. This step does not regenerate the unified asset identifier, does not change the event source, and does not cover the rights status, payment status, and term status in the official status event path.

[0040] The system reads the event type, business chain identifier, status field, deadline field, pending acceptance status field, and target status value through the event field mapping table. The event field mapping table is formed by the service interface definition and business status configuration of the enterprise intellectual property service platform. It records at least the source service, event type, original field name, platform unified field name, and field value enumeration. When the field names in the patent transaction service, annual fee monitoring service, and official status synchronization service are inconsistent, the system converts the original field name to the platform unified field name according to the event field mapping table before performing field matching. If any of the following situations occur: the event field mapping table is missing, the field mapping version is inconsistent with the service version to which the event fragment belongs, or the original field cannot be mapped to the platform unified field name, the system writes the corresponding event fragment into the acceptance confirmation event set and records the acceptance confirmation reason as field mapping pending confirmation.

[0041] Asynchronous event verification processing is performed in batches, with the batch period determined by the platform's configuration parameters, ideally limited to 5 to 60 minutes. The data sources include the message queue retry cycle of the enterprise intellectual property service platform, the official status synchronization cycle, and the platform's transaction status update frequency. After platform deployment, the system reviews the batch period based on event arrival logs from the past 7 to 30 days. The review targets include the number of event segments within a single batch, the official status synchronization arrival interval, and the number of consecutive batches of platform transaction events. The past 7 days' event arrival logs cover event fluctuations on both weekdays and non-weekdays, while the past 30 days' logs cover recent changes in the official status synchronization strategy and transaction status update frequency. The event arrival logs are only used to review the batch period and do not participate in the determination of transaction fulfillment intervals, annual fee period intervals, or transaction annual fee conflict markers.

[0042] When the same unified asset identifier has at least one of the following events in two consecutive verification batches: platform transaction events and warning message events, the verification batch period is preferably 5 to 15 minutes. When there are no new patent transaction service events in two consecutive verification batches, and the official status synchronization service is synchronized daily, the verification batch period is preferably 30 to 60 minutes. When the candidate verification batch period is less than 5 minutes, the system executes it in 5-minute batches. When the candidate verification batch period is greater than 60 minutes, the system executes it in 60-minute batches, and unprocessed event fragments enter subsequent verification batches. When the platform is in the initial deployment stage and the event arrival logs of the past 7 days are insufficient to cover any situation of consecutive working days and non-working days, the system uses 15 minutes as the initial verification batch period. When the official status synchronization service has been configured to synchronize daily and no platform transaction events have occurred in two consecutive verification batches, the system uses 30 minutes as the initial verification batch period.

[0043] At the start of each verification batch, the system establishes the current verification water level. The system reads the previous verification water level saved at the end of the previous verification batch, the start time of the current verification batch, and the maximum platform reception time for completed entry into the platform message queue. The current verification water level is the earlier of the start time of the current verification batch and the maximum platform reception time for completed entry into the platform. If the current verification water level is earlier than the previous verification water level, the system keeps the previous verification water level unchanged and marks the current batch as having no new verifiable events. If the current verification water level is later than the previous verification water level, the system reads event fragments whose platform reception time is later than the previous verification water level but not later than the current verification water level. If there are any of the following situations at the start of the verification batch: incomplete entry event fragments, event fragments pending submission in the entry buffer, or unconfirmed messages in the message queue, the system processes them as message queue backlog. Only event fragments that have been written into the asset status knowledge graph and are within the range of the verification water level are used to generate the current asset acceptance status. Event fragments whose platform reception time is later than the current verification water level enter subsequent verification batches without changing the current asset acceptance status of the current batch.

[0044] The system reads the event fragment corresponding to KCIP-XXX-001 according to the unified asset identifier. Event fragments in the valid event path enter the acceptance verification process; event fragments in the isolated path are retained as objects to be verified, do not enter the acceptance completion event set, and are not used as the endpoint source for the transaction performance period and annual fee period.

[0045] The system first performs pre-event verification. For the contract generation event corresponding to KCIP-XXX-001, the system searches for candidate pre-event fragments under the same unified asset identifier according to the pre-event association of the contract generation event. When the pre-event association points to any event among the listing event and consultation event under the same unified asset identifier, the system sends the contract generation event to the effective timing verification. For the payment completion event, the system searches for contract generation events along the same order number. After the contract generation event is found, it is used as a candidate pre-event fragment for the payment completion event.

[0046] When the preceding event association of the current event fragment is empty, the system determines whether the current event fragment is located at the beginning of the corresponding event path after being sorted according to the effective time sequence. If the current event fragment is located at the beginning of the corresponding event path, the system allows the event fragment to enter the effective time sequence verification. If the current event fragment is not located at the beginning of the corresponding event path, the system writes the current event fragment into the acceptance and confirmation event set and records the acceptance and confirmation reason as preceding event missing. If the preceding event association of the current event fragment points to an event fragment under another unified asset identifier, the system writes the current event fragment into the status of ownership conflict pending confirmation. If the preceding event association of the current event fragment is not empty, but no candidate preceding event fragment is found under the same unified asset identifier, the system writes the current event fragment into the acceptance and confirmation event set and records the acceptance and confirmation reason as preceding event missing.

[0047] After completing the pre-event verification, the system performs an effectiveness sequence verification. If the effectiveness sequence of the current event fragment is later than that of the candidate pre-event fragments, the system confirms that the current event fragment passes the effectiveness sequence verification. If the effectiveness sequences of the two are the same, the system reads the event type order from the platform's business status flow configuration table. The platform's business status flow configuration table is formed by configuring the transaction process and annual fee monitoring process of the enterprise intellectual property service platform. The patent transaction service is configured according to the business flow order of listing events, contract generation events, payment completion events, performance confirmation events, transaction cancellation events, and performance termination events; the annual fee monitoring service is configured according to the time limit monitoring tasks, renewal reminder tasks, and period... When the business flow sequence configuration of the completed event is limited, and the event type of the current event fragment is after the candidate preceding event fragment, the system confirms that the current event fragment has passed the effective timing verification. If any of the following situations occur, such as the platform business status flow configuration table being missing, the configuration version being inconsistent with the service version to which the current event fragment belongs, the current event type not being included in the platform business status flow configuration table, or the order being uncertain, the system will write the current event fragment into the acceptance and confirmation event set and record the acceptance and confirmation reason as configuration pending confirmation. If the effective timing of the current event fragment is earlier than the effective timing of the candidate preceding event fragment, the system will write the current event fragment into the out-of-order event set.

[0048] During the effective time sequence verification, the system checks the mutual exclusion relationship of status fields. Within the same effective time period, there are two types of situations: the same date for the date-level status and overlapping statuses within the time interval. The system retrieves event fragments with the same name for the same status field that are already within the current verification water level under the same unified asset identifier. When the current event fragment and any event fragment with the same name for the same status field record mutually exclusive status values ​​within the same effective time period, the system writes the current event fragment into the source conflict pending confirmation status. Mutually exclusive status values ​​include the same payment status field recording both paid and unpaid, the same ownership status field recording both changed and unchanged ownership, and the same term status field recording both valid and expired terms. Event fragments in the out-of-order event set and the source conflict pending confirmation status do not participate in the generation of transaction performance status and annual fee term status.

[0049] The system then performs source acceptance verification. Platform business events refer to event segments in the platform event path whose source is patent transaction service and annual fee monitoring service. Official status events refer to event segments in the official status event path whose source is official status synchronization service. Ownership status, payment status, and term status are confirmed by official status events. Contract generation, payment completion, performance confirmation, message sending, and task generation belong to platform process status and are only used as business statuses in the platform event path. The event source level does not determine whether the event segment is accepted or not on its own. It is only used to determine the official status event as the priority for status confirmation when the same unified asset identifier and the same name status field have already matched.

[0050] When a platform business event carries a pending status field and a target status value, the system reads official status events under the same unified asset identifier, within the current verification water level, and that have passed the effective timing verification. It matches the pending status field with the same-named status field in the official status event and compares the status value of the official status event with the target status value. The pending status field and target status value originate from the business status configuration in the patent transaction service and annual fee monitoring service. When a transaction performance-related event needs to wait for official ownership confirmation, its pending status field is the ownership status, and the target status value is ownership change completed. When a platform business event does not carry a pending status field and target status value, the system only treats the platform business event as a platform process status and does not write it into the acceptance completion event set.

[0051] When an official status event and a platform business event belong to the same unified asset identifier, the official status event passes the effective timing verification, the official status event contains a pending status field, and the status value of the official status event is consistent with the target status value, the system writes the platform business event into the acceptance completion event set. When a platform business event carries a pending status field and a target status value, but no official status event containing the pending status field under the same unified asset identifier has been read at the time of this verification, the system writes the platform business event into the acceptance confirmation event set and records the acceptance confirmation reason as official acceptance missing. When an official status event and a platform business event belong to the same unified asset identifier, and the official status event contains a pending status field, but the status value of the official status event is inconsistent with the target status value, the system writes the platform business event into the source conflict pending confirmation status.

[0052] For KCIP-XXX-001, if the contract generation event and payment completion event have been read at the time of this verification, but the official status event that confirms the completion of the ownership change and includes the ownership status field has not yet been read, then the corresponding transaction performance-related event is written into the acceptance confirmation event set, and the reason for acceptance confirmation is recorded as official acceptance missing. If the official status event confirming the completion of the ownership change under the same unified asset identifier is read in the subsequent verification batch, then the transaction performance-related event can be written into the acceptance completion event set in the subsequent verification batch.

[0053] The system then generates a transaction fulfillment status. This status originates from event fragments in the patent transaction service event that lack isolated paths, out-of-order event sets, or pending source conflict confirmation. Event fragments where the reason for acceptance confirmation is a missing prerequisite or pending configuration confirmation are not considered endpoints of the transaction fulfillment interval. However, transaction fulfillment-related events where the reason for acceptance confirmation is an official acceptance deficiency are allowed as endpoints of the transaction fulfillment interval, and a pending transaction fulfillment confirmation field is written into the transaction fulfillment status. For KCIP-XXX-001, the system reads the contract generation event, payment completion event, and fulfillment confirmation event that meet the aforementioned conditions. The system reads transaction cancellation events, performance termination events, and ownership change status events that have been completed in the official status event path, and uses the earliest effective time among them as the starting point of the transaction fulfillment interval. If no transaction cancellation events, performance termination events, or ownership change status events that have been completed are read, the system uses the time corresponding to the current verification watermark as the current end point of the transaction fulfillment interval. The transaction fulfillment interval is only used for time overlap judgment in this asynchronous event verification. The order placement interface and fulfillment confirmation interface are not open in this step.

[0054] The system then generates the annual fee period status, which originates from the annual fee monitoring service events and the period status events in the official status events. For KCIP-XXX-001, the system reads the period monitoring tasks that have not been written to the isolation path, out-of-order event set, or source conflict pending confirmation status, and uses the effective time sequence of the period monitoring task as the starting point of the annual fee period interval. If there is a period status event in the official status event path that has passed the effective time sequence verification, the system selects the period status event with the latest effective time sequence and uses the period date in the period status event as the end point of the annual fee period interval. If the period status event records a grace period end date, the system uses the grace period end date as the end point of the annual fee period interval. If multiple period status events are in the same effective period and the period fields are inconsistent, the system writes the corresponding period status events to the source conflict pending confirmation status, and does not form an annual fee period interval for conflict confirmation. If the official status event has not yet been completed and there is a period monitoring task in the platform event path, the system uses the period date recorded by the period monitoring task as the temporary end point of the annual fee period interval and writes the period pending official acceptance field into the annual fee period status.

[0055] When the end point of the annual fee period is missing, the system writes the annual fee period pending confirmation field and does not form an annual fee period for conflict confirmation. When the end point of the annual fee period is earlier than the start point of the annual fee period, the system writes the corresponding event fragment into the source conflict pending confirmation status. When the grace period end date recorded in the period status event is earlier than the period date, the system writes the corresponding period status event into the source conflict pending confirmation status. The period pending official acceptance field and the annual fee period pending confirmation field do not cover the period status field in the official status event path.

[0056] After the transaction fulfillment period and annual fee period are formed, the system performs a conflict flag judgment. The system uses closed intervals to determine whether there is a time overlap between the transaction fulfillment period and the annual fee period. If the start point of the transaction fulfillment period is no later than the end point of the annual fee period, and the start point of the annual fee period is no later than the end point of the transaction fulfillment period, the system determines that the two intervals have a time overlap. If the endpoints of the intervals are equal, the system determines that there is a time overlap. If there are intervals with missing start points or missing end points in the transaction fulfillment period or the annual fee period, the system writes an interval pending confirmation flag, but does not write a transaction annual fee conflict flag.

[0057] When there is a time overlap between the transaction performance period and the annual fee period, and the official status event corresponding to the transaction performance status has not been completed, the system writes a conflict marker in the current asset acceptance status. The conflict marker is the transaction annual fee conflict marker. The official status event corresponding to the transaction performance status has not been completed means that at the time of verification, no official status event under the same unified asset identifier used to confirm the transaction performance status and containing the pending status field has been read; the official status event that has been read has not passed the effective time sequence verification; or an official status event containing the pending status field has been read but its status value is inconsistent with the target status value. The transaction annual fee conflict marker records at least the unified asset identifier, the patent transaction service event that triggered the conflict, the annual fee period event fragment that triggered the conflict, the transaction performance period, the annual fee period period, the official acceptance status, and the time of conflict writing. The annual fee period event fragment includes the period monitoring task and the period status event. The transaction annual fee conflict marker is written to the current asset acceptance status, but not to the status field in the official status event path, and does not change the event source, event source level, and effective time sequence of the event fragment.

[0058] In this implementation, when the transaction annual fee conflict flag is written to the current asset acceptance status, the conflict flag version number, conflict validity status, and conflict source watermark are also written. The conflict validity status includes effective, resolved, and updated. In each subsequent verification batch, the system reads the transaction annual fee conflict flags with an effective conflict status under the same unified asset identifier, and performs conflict review in conjunction with newly arrived official status events, annual fee term status events, transaction cancellation events, and performance termination events.

[0059] When subsequent verification batches read an official status event that confirms the transaction fulfillment status and includes a pending acceptance status field, and this official status event passes the validity time verification, the status field matches the pending acceptance status field, and the status value matches the target status value, the system updates the conflict validity status of the corresponding transaction annual fee conflict marker to "resolved," records the reason for resolution as "official acceptance completed," and records the resolution watermark as the current verification watermark. The resolved transaction annual fee conflict marker is retained in the asset status knowledge graph for traceability and is not read as an effective conflict marker in subsequent transaction license mapping processing and early warning routing processing.

[0060] When subsequent verification batches read new term status events, and the new term endpoints are inconsistent with the original annual fee term range, the system re-forms the annual fee term range using the new term status events. If the re-formed annual fee term range does not overlap with the transaction fulfillment period, the system updates the original transaction annual fee conflict marker to "resolved," with the reason recorded as "no overlap after the annual fee term update." If the re-formed annual fee term range still overlaps with the transaction fulfillment period, and the official status event has not yet been completed, the system generates a new version of the transaction annual fee conflict marker and updates the original transaction annual fee conflict marker to "updated."

[0061] When subsequent verification batches read transaction cancellation events or performance termination events, and these events pass the preceding event verification and effective sequence verification, the system uses the effective sequence of the transaction cancellation event or performance termination event as the end point of the transaction performance interval to re-determine the interval overlap relationship. If, after re-determination, there is no time overlap between the transaction performance interval and the annual fee period interval, the system updates the original transaction annual fee conflict mark to "resolved," recording the reason for resolution as the end of the transaction performance interval; if, after re-determination, there is still time overlap and the official status event has not been completed, the system generates a new version of the transaction annual fee conflict mark and updates the original transaction annual fee conflict mark to "updated."

[0062] The transaction license mapping and early warning routing processes only read the transaction annual fee conflict flags whose conflict validity status is effective and whose conflict source water level is no later than the current verification water level. The resolved and updated transaction annual fee conflict flags are only used for audit tracing and are not used to close the order placement interface, close the performance confirmation interface, or expand the renewal early warning routing object.

[0063] During the sample operation of KCIP-XXX-001, the patent transaction service generated a contract generation event on XX / XX / 202X and a payment completion event on XX / XX / 202X. The system retrieved candidate preceding event fragments along the same order number, associated the preceding event of the payment completion event with the contract generation event, and compared the effective sequence of the two. When the effective sequence of the payment completion event was not earlier than that of the contract generation event, the payment completion event passed the preceding event verification and effective sequence verification. Since the official status synchronization service had not yet synchronized the official status event used to confirm the completion of the ownership change and containing the ownership status field, the corresponding transaction performance-related event was written into the acceptance confirmation event set, and the reason for acceptance confirmation was recorded as official acceptance missing. At the same time, the transaction performance pending confirmation field was written into the transaction performance status.

[0064] During the same example operation, the annual fee monitoring service generates a term monitoring task on XX / XX / 202X, and the official status synchronization service synchronizes the term status event of the patent on XX / XX / 202X. The system reads the effective time of the term monitoring task as the starting point of the annual fee term interval and reads the term date in the term status event as the ending point of the annual fee term interval. If the transaction performance interval and the annual fee term interval overlap according to the closed interval judgment, and the official status event used to confirm the completion of the ownership change under the same unified asset identifier has not been read at the current verification time, the system writes a transaction annual fee conflict mark in the current asset acceptance status. After the subsequent transaction license mapping processing reads the transaction annual fee conflict mark, it generates the transaction operation license field; after the subsequent early warning routing processing reads the transaction annual fee conflict mark, it generates the renewal early warning message routing record.

[0065] The event fragments in the early warning write-back path are used to record the renewal early warning message routing record, early warning sending result and response result generated by the message early warning service. Step S2 reads the early warning write-back path to maintain the integrity of the event chain under the same unified asset identifier. However, the event fragments in the early warning write-back path do not participate in the formation of the endpoints of the transaction performance interval and the annual fee period interval. The event fragments in the early warning write-back path are read by the subsequent early warning routing process and used to generate the renewal early warning message routing record.

[0066] After step S2 is completed, the system outputs the current asset acceptance status, which includes the set of acceptance completion events, the set of acceptance confirmation events, the set of out-of-order events, the status of pending ownership conflict, the status of pending source conflict, the status of transaction fulfillment, the status of annual fee term, the interval pending confirmation flag, and the transaction annual fee conflict flag. This current asset acceptance status serves as the input for subsequent transaction license mapping processing and early warning routing processing.

[0067] The current asset acceptance status is a snapshot below the verification batch watermark. The system does not delete the original event fragments, nor does it rewrite the status fields in the official status event path. Subsequent verification batches read new event fragments, pending confirmation indexes, and transaction annual fee conflict markers that are still in effect, and then regenerate a new current asset acceptance status. The new current asset acceptance status is distinguished from the previous batch status by the event watermark, and the processing results of event fragments or conflict markers in subsequent batches are expressed by status values ​​such as acceptance completed, accepted, cancelled, updated, and expired. Transaction license mapping processing and early warning routing processing only read the latest current asset acceptance status corresponding to the current verification watermark, and do not read expired or cancelled old statuses as the basis for interface opening and message routing.

[0068] After generating the current asset acceptance status in step S2, the system executes step S3. Step S3 is used to convert the transaction performance status, annual fee term status and transaction annual fee conflict mark already formed in the current asset acceptance status into transaction operation license fields that can be executed by the patent transaction service. The patent transaction service then executes the opening processing of the display interface, order placement interface and performance confirmation interface according to the transaction operation license fields.

[0069] This step follows the processing result of the example platform asset number KCIP-XXX-001 in step S2. For KCIP-XXX-001, step S2 has already read the contract generation event and payment completion event generated by the patent transaction service, and completed the pre-event verification and effective timing verification along the same order number. When the official status synchronization service has not yet synchronized to the official status event used to confirm the completion of the ownership change, step S2 writes the corresponding transaction performance-related events into the acceptance confirmation event set. At the same time, step S2 has read the term monitoring task generated by the annual fee monitoring service and the term status event generated by the official status synchronization service to form the annual fee term status. When there is a time overlap between the transaction performance period and the annual fee term period and the official status event has not been completed, step S2 writes the transaction annual fee conflict mark in the current asset acceptance status. Step S3 takes the current asset acceptance status as input and uses the unified asset identifier, current verification water level, transaction performance status, annual fee term status and transaction annual fee conflict mark formed in step S2.

[0070] The system reads the patent transaction service events used to form the transaction performance status in the current asset acceptance status, and reads the annual fee monitoring service events and term status events used to form the annual fee term status in the current asset acceptance status. For KCIP-XXX-001, the patent transaction service events include contract generation events and payment completion events, the annual fee monitoring service events include term monitoring tasks, and the term status events include term status events written by the official status synchronization service. All of the aforementioned events come from the current asset acceptance status already formed in step S2. Step S3 does not regenerate business events, nor does it rewrite the rights status, payment status, and term status in the official status event path. Events received by the platform after the current verification waterline do not participate in the generation of the license field for this transaction operation.

[0071] The system first determines whether the current asset acceptance status can be used as the basis for opening a transaction. Only one set of transaction operation permission fields is generated for the same current asset acceptance status. When any of the following situations exist, the system generates transaction operation permission fields indicating restricted display, closed order placement, and closed performance confirmation.

[0072] First, if the unified asset identifier is inconsistent, the system reads the unified asset identifier carried by the contract generation event, payment completion event, deadline monitoring task, and deadline status event, and compares it with the unified asset identifier in the current asset acceptance status. If any event is inconsistent with the unified asset identifier in the current asset acceptance status, the transaction-side event and the deadline-side event will not be used as the basis for opening the transaction of the same patent asset. In this case, the limited display will only show the basic information of the patent asset corresponding to the unified asset identifier in the current asset acceptance status in the main asset table. The basic information of the patent asset includes the platform asset number, patent application number, publication number, authorization announcement number, and asset name. The transaction performance status and annual fee deadline status formed by the event with inconsistent unified asset identifier will not be displayed.

[0073] Second, if the event acceptance status fails verification, and any of the patent transaction service events, annual fee monitoring service events, and term status events has been written into any of the following sets or statuses: out-of-order event set, source conflict pending confirmation status, or acceptance confirmation event set, the current asset acceptance status will not be used as the basis for transaction opening. Specifically, writing into the out-of-order event set indicates that the effective sequence between the event and its predecessor events has not passed the verification in step S2; writing into the source conflict pending confirmation status indicates that there are mutually exclusive status values ​​in the same status field within the same effective period; and writing into the acceptance confirmation event set indicates that the event still has unconfirmed situations such as missing predecessors, configuration pending confirmation, or official acceptance missing.

[0074] Third, if the endpoints of the interval are incomplete and the current asset acceptance status has an interval pending confirmation mark, it means that at least one of the transaction performance intervals or annual fee period intervals has a missing start point or end point. The transaction performance status and the annual fee period status have not yet formed a complete time overlap judgment basis, and the system does not open the order placement interface and the performance confirmation interface.

[0075] Fourth, if the transaction annual fee conflict has not been resolved, and the current asset acceptance status has a transaction annual fee conflict mark, and the official status event corresponding to the transaction annual fee conflict mark has not been completed, it means that there is a time overlap between the transaction performance period and the annual fee period, and the transaction performance status has not been confirmed by the official status event. The system will not open the order placement interface and the performance confirmation interface.

[0076] If none of the aforementioned situations exist, and both the transaction fulfillment status and annual fee term status are taken over by official status events, the system generates a transaction operation permission field indicating full display, open order placement, and open fulfillment confirmation. The conditions for opening are: the patent transaction service event, annual fee monitoring service event, and term status event are not written into the out-of-order event set, the source conflict pending confirmation status, and the acceptance confirmation event set; the current asset acceptance status does not have the interval pending confirmation mark and the transaction annual fee conflict mark; and both the transaction fulfillment status and annual fee term status are taken over by official status events.

[0077] The transaction operation permission fields include the display interface permission value, order placement interface permission value, performance confirmation interface permission value, and permission source watermark. The display interface permission value uses two enumerated values: full display and restricted display. The order placement interface permission value uses two enumerated values: open order placement and closed order placement. The performance confirmation interface permission value uses two enumerated values: open performance confirmation and closed performance confirmation. The aforementioned enumerated values ​​belong to the interface open configuration, and their engineering source is the interface action attributes and transaction write permission configuration of the patent transaction service. The display interface belongs to the information reading action, and basic information is retained when the transaction annual fee conflict mark exists but the object ownership is clear. The order placement interface and performance confirmation interface belong to the transaction write action, and are closed when the official status event has not been completed, the interval pending confirmation mark exists, or the transaction annual fee conflict mark exists.

[0078] When the display interface license value is "Full Display," the patent transaction service displays basic patent asset information, transaction performance status information, and an order placement portal. When the display interface license value is "Restricted Display," the patent transaction service displays basic patent asset information and marks it as "Restricted Display," without displaying the direct order placement portal or the performance confirmation portal. When the order placement interface license value is "Open Order Placement," the patent transaction service creates an order record. When the order placement interface license value is "Closed Order Placement," the patent transaction service does not create an order record. When the performance confirmation interface license value is "Open Performance Confirmation," the patent transaction service writes a performance confirmation record. When the performance confirmation interface license value is "Closed Performance Confirmation," the patent transaction service does not write a performance confirmation record.

[0079] The license source watermark is equal to the current verification watermark carried by the current asset acceptance status in step S2. It is used to identify the event time boundary on which the license field of this transaction operation is based. The time precision of the license source watermark is consistent with the current verification watermark in step S2. When the platform event reception time is recorded in seconds, the license source watermark is recorded in seconds. When both the platform message queue and the patent transaction service support millisecond-level reception time, the license source watermark is recorded in milliseconds. When the time precision of different services is inconsistent, the system compares the watermarks according to the lower time precision. The time precision from seconds to milliseconds is the preferred precision range. Its engineering source is the recording precision of the platform event reception time field, the message queue delivery time field, and the patent transaction service write time field.

[0080] When the platform is deployed, service versions are changed, or time field configurations are changed, the system calibrates the time precision of the license source watermark. During calibration, the system reads the time precision configurations of the platform event reception time field, message queue delivery time field, and patent transaction service write time field, and checks whether the current verification watermark formed by adjacent verification batches can be distinguished by order. If the adjacent verification batches can be distinguished by order, the system writes the license source watermark with the same time precision as the current verification watermark. If the adjacent verification batches cannot be distinguished by order, the license field of this transaction operation will not be used as the basis for opening order placement and opening performance confirmation, and the patent transaction service will be processed as restricted display, closed order placement, and closed performance confirmation.

[0081] After generating the transaction operation license field, the system first verifies whether the transaction operation license field contains the display interface license value, the order placement interface license value, the performance confirmation interface license value, and the license source water level. If the transaction operation license field lacks any of the aforementioned fields, the transaction operation license field will not be used as the basis for transaction opening, and the patent transaction service will process it as restricted display, closed order placement, and closed performance confirmation. If the transaction operation license field contains the aforementioned fields, the system will write the transaction operation license field into the patent transaction service according to the unified asset identifier.

[0082] Before writing, the system reads existing transaction operation license fields under the same unified asset identifier in the patent transaction service. If no existing transaction operation license field is read, the system writes the current transaction operation license field into the patent transaction service. If an existing transaction operation license field is read, the system compares the license source watermark of the current transaction operation license field with that of the existing transaction operation license field. If the license source watermark of the current transaction operation license field is later than that of the existing transaction operation license field, the system writes the current transaction operation license field into the patent transaction service and uses the current transaction operation license field as the basis for interface opening. If the license source watermark of the current transaction operation license field is not later than that of the existing transaction operation license field, the system retains the existing transaction operation license field and uses it as the basis for interface opening. Thus, the basis for interface opening in the patent transaction service corresponds to the current asset acceptance status with the newest time boundary under the same unified asset identifier, avoiding the overwriting of the current license field by transaction operation license fields generated by old verification batches.

[0083] When the patent transaction service fails to read the transaction operation license field under the same unified asset identifier, it will process the transaction as restricted display, closed order placement, and closed performance confirmation. If any of the following fields are missing from the read transaction operation license field: display interface license value, order placement interface license value, performance confirmation interface license value, and license source watermark, the patent transaction service will process the transaction as restricted display, closed order placement, and closed performance confirmation. This downgrade process does not change the current asset acceptance status or the transaction annual fee conflict flag. It is only used to ensure that the interface open processing does not output a tradable result when the license field is missing or the license field lacks necessary fields.

[0084] Taking KCIP-XXX-001 as an example, step S2 has already written a transaction annual fee conflict mark into the current asset acceptance status. The transaction performance period corresponding to this transaction annual fee conflict mark overlaps with the annual fee period period, and the official status event corresponding to the transaction performance status has not been completed. After reading the current asset acceptance status in step S3, it is confirmed that the contract generation event and payment completion event used to form the transaction performance status, as well as the term monitoring task and term status event used to form the annual fee period status, belong to the same unified asset identifier. Since the current asset acceptance status of KCIP-XXX-001 has a transaction annual fee conflict mark and the official status event has not been completed, the system generates a transaction operation license field indicating restricted display, closed order placement, and closed performance confirmation, and writes the license source water level line into the current verification water level line. The patent transaction service displays the basic information of KCIP-XXX-001 according to the transaction operation license field, and marks the display interface license value as restricted display, does not create a new order record, and does not write a performance confirmation record.

[0085] After this step is completed, the current asset acceptance status has been converted into a transaction operation license field that can be executed by the patent transaction service. This transaction operation license field makes the display interface, order placement interface, and performance confirmation interface subject to the same unified asset identifier, the same current verification water level, and the same transaction annual fee conflict mark. When subsequent steps perform early warning routing processing, the transaction annual fee conflict mark and annual fee term status in the current asset acceptance status will continue to be read, and the order placement interface license value and performance confirmation interface license value generated in this step will not replace the renewal early warning message routing record.

[0086] After completing the transaction license mapping process in step S3, the system executes step S4. The processing content of step S4 is as follows: perform early warning routing processing on the current asset acceptance status, generate a renewal early warning message routing record, and encapsulate the renewal early warning message routing record into an event fragment and write it back to the asset status knowledge graph. This step is used to ensure that renewal early warning messages are routed according to the same patent asset, the same term endpoint, and the corresponding transaction processing relationship when there is asynchronous acceptance of patent transaction service, annual fee monitoring service, official status synchronization service, and message early warning service.

[0087] This step continues to use the platform asset number KCIP-XXX-001 from the previous implementation. For KCIP-XXX-001, step S1 has already written the listing event, contract generation event, and payment completion event generated by the patent transaction service into the platform event path, the term monitoring task generated by the annual fee monitoring service into the platform event path, the term status event generated by the official status synchronization service into the official status event path, and the warning sending event generated by the message warning service into the warning write-back path. Step S2 has already performed asynchronous event verification processing on the asset status knowledge graph corresponding to KCIP-XXX-001, generated the current asset acceptance status, and in the transaction execution... When the contract period and the annual fee period overlap and the official status event has not been completed, a transaction annual fee conflict flag is written. Step S3 has already generated a transaction operation permission field based on the current asset acceptance status, and recorded the display interface permission value in the patent transaction service as restricted display, the order placement interface permission value as closed order placement, and the performance confirmation interface permission value as closed performance confirmation. Step S4 does not use the order placement interface permission value and performance confirmation interface permission value generated in step S3 as the conditions for generating the renewal warning message routing record, but continues to read the current asset acceptance status, annual fee period status, transaction annual fee conflict flag, current verification water level, and warning write-back path formed in step S2.

[0088] For KCIP-XXX-001, the system first reads the annual fee term status, transaction annual fee conflict flag, current verification water level, and early warning write-back path from the current asset acceptance status. The annual fee term status is used to provide the term monitoring task, term status event, term date, and grace period end date. The transaction annual fee conflict flag is used to provide the judgment result of asynchronous acceptance between the transaction performance status and the annual fee term status. The current verification water level is used to limit the event time boundary that can be used for this early warning routing process. The early warning write-back path is used to read the renewal early warning message routing record that has been written under the same unified asset identifier and to write the event fragment formed in this encapsulation. Event fragments received by the platform after the current verification water level do not participate in the generation of this renewal early warning message routing record. This event fragment enters the subsequent verification batch processing.

[0089] The system is configured with degradation rules. If any of the following conditions are met: inconsistent warning object, pending deadline status, pending warning water level, pending time zone configuration, missing warning lead time, pending official acceptance status, missing routing object, or missing conflict marker, the system will record the routing status of the current renewal warning message routing record as pending confirmation and write the corresponding reason into the pending confirmation reason. The routing record of the renewal warning message with a routing status of pending confirmation is only written into the warning write-back path for subsequent verification batch reading of pending confirmation reasons and execution of duplicate routing exclusion. It is not used as the basis for message sending, not used as the basis for deadline endpoint generation, and is not written into the official status event path.

[0090] In this implementation, when the system reads the warning write-back path, it first establishes a warning routing index based on the unified asset identifier, term endpoint, routing object, routing status, and event watermark. For multiple renewal warning message routing records corresponding to the same unified asset identifier, term endpoint, and routing object, the system first excludes records that have been marked as invalid or replaced by subsequent event watermarks, and then selects the record with the latest event watermark as the latest valid record. If the event watermarks are the same, the system determines the latest valid record according to the executableness of the routing status, with the sending status taking precedence over the not-send-yet status, and the not-send-yet status taking precedence over the pending-confirmation status; if it still cannot be determined, the system records the routing record of this renewal warning message as pending confirmation, and records the reason for pending confirmation as pending confirmation in the same order as the routing record.

[0091] Before generating the routing record for this renewal warning message, the system first constructs a deduplication key. This key is formed by the unified asset identifier, term endpoint, routing object, transaction annual fee conflict flag version number, and the warning window to which the current verification watermark belongs. If a record with the same deduplication key and a sent status already exists in the warning write-back path, the system will not generate a new renewal warning message routing record with a sent status. If a record with the same deduplication key exists in the warning write-back path but its status is pending confirmation or temporarily not sent, and the current verification batch has already supplemented the pending confirmation reason or the term endpoint has entered the warning window, the system generates a new renewal warning message routing record and marks the original record as replaced.

[0092] When any of the following conditions are met—change in annual fee period, change in transaction annual fee conflict flag version, or change in routing object—the system determines that the routing deduplication key has changed and can generate a new renewal warning message routing record. After the new renewal warning message routing record is written into the warning write-back path, the system uses its event watermark as the basis for judging the latest valid record in subsequent batches. Therefore, historical event fragments in the warning write-back path are continuously retained, but subsequent warning routing processing is only based on the latest valid record and the routing deduplication key, avoiding duplicate sending or repeated confirmation of already processed warning records.

[0093] The system performs boundary verification of the warning object. The system reads the term monitoring task and term status event corresponding to the annual fee term status of KCIP-XXX-001, and reads the unified asset identifier carried by each type of event. When both the term monitoring task and the term status event correspond to the unified asset identifier of KCIP-XXX-001, the system continues to perform term endpoint processing. When the term monitoring task and the term status event do not correspond to the same unified asset identifier, the annual fee term status is not used as the basis for the renewal warning of KCIP-XXX-001. The system records the routing status of this renewal warning message routing record as pending confirmation, and records the reason for pending confirmation as inconsistent warning object.

[0094] The system determines the term endpoint based on the annual fee term status. The system reads the term date from the annual fee term status of KCIP-XXX-001. If the term status event records a grace period end date, the grace period end date is used as the term endpoint; if the term status event does not record a grace period end date, the term date is used as the term endpoint. Both the term date and the grace period end date are derived from the annual fee term status already formed in step S2. This step does not recalculate the official payment period or rewrite the term status field in the official status event path. If any of the following conditions are met: the term date is missing, the term status event has a source conflict and is pending confirmation, or the grace period end date is earlier than the term date, the system records the routing status of this renewal warning message routing record as pending confirmation and records the reason for pending confirmation as term status pending confirmation.

[0095] The system converts the current verification water level into a verification date. When the current verification water level is a timestamp field, the system converts it into a date-level verification date according to the unified time zone configured on the enterprise intellectual property service platform. When the current verification water level is already a date field, the system uses that date field as the verification date. If the current verification water level needs time zone conversion but cannot read the unified time zone configuration, the system records the routing status of this renewal warning message routing record as pending confirmation and records the reason for pending confirmation as time zone configuration pending confirmation. If the current verification water level is missing, or if there is an existing event fragment in the warning write-back path and the current verification water level cannot be compared with the event water level field in the existing event fragment in terms of time sequence, the system records the routing status of this renewal warning message routing record as pending confirmation and records the reason for pending confirmation as warning water level pending confirmation.

[0096] The system reads the renewal warning advance period, which is an operational configuration parameter of the message warning service. It is used to determine whether the deadline has entered the warning window and is not used as the legal calculation result of the official payment deadline. The renewal warning advance period uses positive integer natural days, and the preferred range for the renewal warning advance period is 30 to 90 days. The engineering source of this range is the customer reminder cycle configuration of the enterprise intellectual property service platform, the message template cycle configuration in the message warning service, and the deadline verification cycle configuration in the annual fee monitoring service. When the renewal warning advance period is less than 30 days, the processing cycle between the first reminder and the deadline will be shortened; when the renewal warning advance period is greater than 90 days, the warning window will be expanded and duplicate reminder records will be added.

[0097] If a customer reminder period configuration exists and can be converted to a positive integer number of days, the system prioritizes reading the customer reminder period configuration and limits the read configuration value to 30 to 90 days. If either the customer reminder period configuration is missing or cannot be converted to a positive integer number of days, the system reads the reminder template period enabled in the message alert service and the period verification period configured in the annual fee monitoring service. If a period that can be converted to a positive integer number of days is read, the system uses that period as a backup configuration value. If two periods that can be converted to positive integer numbers of days are read, the system uses the larger period as the backup configuration value. After the backup configuration value is formed, the system limits the period to 30 to 90 days. If no period that can be converted to a positive integer number of days is read, the system continues to use the backup configuration value. When configuring the backup value for the day, the system reads the default lead time from the deployment configuration file. If the default lead time in the deployment configuration file can be converted into a positive integer natural day, the system performs a limit processing based on 30 to 90 days. The preferred value for the default lead time is 60 days, which is the midpoint of the preferred limit range of 30 to 90 days and is not used as a historical sample statistical conclusion. If either the default lead time in the deployment configuration file is missing or cannot be converted into a positive integer natural day, the system records the routing status of this renewal warning message routing record as pending confirmation and records the reason for pending confirmation as missing warning lead time. When the platform deployment, message template changes, and annual fee monitoring rules change, the system rereads, limits, and verifies the renewal warning lead time according to the same rules.

[0098] The system determines whether the deadline endpoint meets the sending time conditions. When the deadline endpoint and the verification date are the same date, the date interval is recorded as 0 days. When the verification date is not later than the deadline endpoint and the date interval between the deadline endpoint and the verification date is not greater than the renewal warning advance period, the system confirms that the deadline endpoint enters the warning window. When the verification date is later than the deadline endpoint, the system records the warning type as a deadline overdue warning. When either the deadline endpoint enters the warning window or the warning type is recorded as a deadline overdue warning, the system continues to execute the routing object determination process. When the deadline endpoint is later than the verification date and the date interval between the two is greater than the renewal warning advance period, the system generates a renewal warning message routing record and records the routing status as "not sending for now". The renewal warning message routing record with the routing status of "not sending for now" is encapsulated as an event fragment and written into the warning write-back path. It does not trigger message sending and does not enter the routing object determination process.

[0099] After entering the routing object determination process, the system determines the routing branch based on the transaction annual fee conflict flag and the official acceptance status.

[0100] When there is no transaction annual fee conflict marker in the current asset acceptance status, and the annual fee term status is accepted by the official status event, the system enters the regular renewal warning branch. The system reads the task configuration record corresponding to the unified asset identifier and term monitoring task identifier from the annual fee monitoring service, and reads the renewal processing node from the task configuration record. If either the task configuration record does not correspond to the same unified asset identifier or no renewal processing node is read, the system records the routing status of the renewal warning message routing record as pending confirmation, and records the reason for pending confirmation as missing routing object. When a renewal processing node is read and the task configuration record corresponds to the same unified asset identifier, the system determines the routing object of the renewal warning message routing record as the renewal processing node, and continues to perform duplicate routing exclusion processing.

[0101] Both renewal processing nodes and transaction processing nodes are routing receiving objects that can be identified by the message alert service. They can be represented by processing account identifier, job queue identifier, or server processing address. When the system reads a processing node, it prioritizes reading the processing account identifier; if the processing account identifier is missing but the job queue identifier exists, it reads the job queue identifier; if both are missing but the server processing address exists, it reads the server processing address; if all three are missing, it is recorded as a missing routing object.

[0102] If there is no transaction annual fee conflict marker in the current asset acceptance status, and the annual fee period status has not been completed by the official status event, the system will record the routing status of the renewal warning message routing record as pending confirmation, and record the reason for pending confirmation as pending confirmation of the official acceptance status.

[0103] If the current asset acceptance status has a transaction annual fee conflict marker, and the official status event corresponding to the transaction annual fee conflict marker has not been completed, the system enters the conflict renewal warning branch. The system first verifies whether the transaction annual fee conflict marker can correspond to the event segment that triggered the conflict, the transaction performance period, the annual fee period, and the official acceptance status. If the transaction annual fee conflict marker cannot correspond to the aforementioned content, the system records the routing status of the renewal warning message routing record as pending confirmation, and records the reason for pending confirmation as a missing conflict marker. If the transaction annual fee conflict marker can correspond to the aforementioned content, the system reads the task configuration record corresponding to the unified asset identifier and the term monitoring task identifier from the annual fee monitoring service, and reads the renewal processing node from the task configuration record; the system also reads the order corresponding to the patent transaction service event that triggered the conflict from the patent transaction service. The system processes records and reads transaction processing nodes from order processing records. If any of the following conditions are met: the task configuration record does not correspond to the same unified asset identifier, the order processing record does not correspond to the same unified asset identifier, no renewal processing node is read, or no transaction processing node is read, the system records the routing status of the renewal warning message routing record as pending confirmation and records the reason for pending confirmation as missing routing object. If both the renewal processing node and the transaction processing node are read, and both the task configuration record and the order processing record correspond to the same unified asset identifier, the system determines the routing object of the renewal warning message routing record as the renewal processing node and the transaction processing node, and continues to perform duplicate routing exclusion processing. By using the renewal processing node and the transaction processing node as routing objects simultaneously, the annual fee term risk can be simultaneously entered into the term-side and transaction-side processing processes.

[0104] If the current asset transfer status has a transaction annual fee conflict marker, and the official status event corresponding to the transaction annual fee conflict marker has been completed, the system will not process it according to the conflict renewal warning branch, but will instead enter the regular renewal warning branch according to the official transfer result of the annual fee period status.

[0105] The system performs duplicate routing exclusion processing. The system reads the existing renewal warning message routing records in the warning write-back path. If there is already a renewal warning message routing record in the warning write-back path that has the same unified asset identifier, term endpoint, and routing object as the current renewal warning message routing record and the routing status is "sent", the system will not generate a new renewal warning message routing record with the routing status "sent". If there is no such consistent sending record in the warning write-back path, the system will record the routing status of the current renewal warning message routing record as "sent". If there is already a renewal warning message routing record in the warning write-back path with the routing status "pending confirmation", but the current warning object boundary, term endpoint, routing object, and transaction annual fee conflict flag already meet the sending conditions, the system will generate a new renewal warning message routing record and record the routing status of the new renewal warning message routing record as "sent".

[0106] The renewal warning message routing record must at least record the unified asset identifier, current verification water level, term endpoint, routing object, and routing status. The routing status includes sent, not sent, and pending confirmation. When the routing status is sent, the message warning service generates a message task record according to the renewal warning message routing record, writes the unified asset identifier, term endpoint, routing object, and warning content into the message task record, and delivers the message task record to at least one of the following sending channels through the message queue: in-site message, SMS interface, and email interface. The sending channel is determined by the message template configuration of the message warning service. When the routing status is not sent, the message warning service does not send a message and only retains the judgment result of this warning window. When the routing status is pending confirmation, the message warning service does not send a message and continues to read the current asset acceptance status for acceptance judgment in subsequent verification batches. These fields are all derived from the current asset acceptance status, annual fee term status, transaction annual fee conflict flag, message warning service operation configuration, and warning write-back path, and the unified asset identifier is not regenerated.

[0107] The system encapsulates renewal warning message routing records into event fragments. During encapsulation, the system writes the renewal warning message routing records into the event fragments according to the unified asset identifier, the current verification water level, and the routing status. The message warning service is also written into the event fragments as the event source. The encapsulated event fragments are written into the warning write-back path in the asset status knowledge graph. Event fragments written into the warning write-back path are not written into the official status event path, and do not modify the annual fee term status, transaction fulfillment status, or transaction annual fee conflict flag. Event fragments written back to the warning write-back path are used for subsequent verification batch reading of warning routing results and execution of duplicate routing exclusion. They are not used as the rights status, payment status, or term status in the official status event path.

[0108] Taking KCIP-XXX-001 as an example, during this step, the current asset acceptance status of KCIP-XXX-001 already contains an annual fee term status and a transaction annual fee conflict marker. Furthermore, the official status event corresponding to the transaction annual fee conflict marker has not been completed. After step S4 reads the annual fee term status of KCIP-XXX-001, it determines the term endpoint based on the term date and grace period end date, and converts the current verification watermark into a verification date. When the term endpoint enters the warning window, the system reads the event fragment that triggered the conflict, the transaction fulfillment period, the annual fee term period, and the official acceptance status corresponding to the transaction annual fee conflict marker. Since the transaction annual fee conflict marker has not yet been completed by the official status... Once the event is accepted, the system identifies the routing object of the renewal warning message routing record as the renewal processing node and transaction processing node corresponding to the same unified asset identifier. When the duplicate routing exclusion process fails to find an existing sent record, the system records the routing status as sent. Subsequently, the system encapsulates the renewal warning message routing record into an event fragment and writes it into the warning write-back path in the asset status knowledge graph. When the subsequent batch of verification processes KCIP-XXX-001 again, the system reads the event fragment in the warning write-back path, identifies that a renewal warning message routing record with the same unified asset identifier, the same term endpoint, the same routing object, and a routing status of sent already exists, and does not generate the same sent record again.

[0109] After this step is completed, the annual fee term status and transaction annual fee conflict marker in the current asset acceptance status are used to generate renewal warning message routing records, and are written back to the asset status knowledge graph in the form of event fragments. The write-back result provides a readable basis for sending warnings and deduplication for subsequent verification batches, while not changing the rights status, payment status and term status in the official status event path.

[0110] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for matching and risk warning of enterprise intellectual property services based on knowledge graphs, characterized in that, Includes the following steps: The system obtains the set of asset events corresponding to the same patent asset in the enterprise intellectual property service platform, generates a unified asset identifier using the asset normalization method, and then uses the event encapsulation method to convert the asset events into event fragments that carry the event source, arrival time, effective time, event source level and associated preceding events. The event fragments are then written into the asset status knowledge graph according to the unified asset identifier. Asynchronous event verification processing is performed on the asset status knowledge graph to generate the current asset acceptance status. The asynchronous event verification processing isolates out-of-order events according to the association of preceding events and the effective time sequence. Then, it verifies the acceptance relationship between platform business events and official status events according to the event source level. When there is a time overlap between the transaction fulfillment status and the annual fee period status and the official status event has not been completed, a conflict flag is written. Perform transaction license mapping processing on the current asset acquisition status, generate a transaction operation license field, write the transaction operation license field into the patent transaction service, and the patent transaction service performs the opening processing of the display interface, order placement interface and performance confirmation interface according to the transaction operation license field; Perform early warning routing processing on the current asset takeover status, generate renewal early warning message routing records, and encapsulate the renewal early warning message routing records into event fragments before writing them back to the asset status knowledge graph.

2. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 1, characterized in that, The specific operation of the asset normalization method is as follows: the numbering format of asset events in the asset event set is uniformly processed; the existing asset index is retrieved using the uniformly formatted numbering information, and the asset events that are found in the search are assigned to the corresponding unified asset identifier; temporary unified asset identifiers are generated for asset events that are not found in the search, and the corresponding asset events are written to the pending verification status; among them, asset events in the pending verification status are written to the isolated path of the asset status knowledge graph, and the isolated path is separated from the valid event path used for subsequent processing.

3. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 2, characterized in that, The specific operation of the event encapsulation method is as follows: Read the normalized asset events according to the unified asset identifier, convert the normalized asset events into event fragments, and write the event source, arrival time, effective time, event source level, and associated preceding events into the event fragments; write the event fragments into the corresponding event paths in the asset status knowledge graph according to the event source, and retain the event source level of the event fragments; among them, official status events are written into the official status event path, platform events are written into the platform event path, and message warning events are written into the warning write-back path. The event fragments in the platform event path and the warning write-back path do not cover the status fields in the official status event path.

4. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 1, characterized in that, The specific operation of isolating out-of-order events according to the association of preceding events and the effective time sequence is as follows: read the event fragments and their corresponding status fields in the asset status knowledge graph according to the unified asset identifier, and retrieve candidate preceding event fragments according to the preceding event association of the current event fragment; when the preceding event association of the current event fragment is empty, and the current event fragment is not an event fragment located at the beginning of the corresponding event path after being sorted according to the effective time sequence, write the current event fragment into the acceptance confirmation event set; If the preceding event association of the current event fragment is not empty and no candidate preceding event fragments under the same unified asset identifier are found, the current event fragment will be written into the acceptance confirmation event set. When the preceding event of the current event fragment points to an event fragment under another unified asset identifier, the current event fragment will be written to the status of ownership conflict pending confirmation. After retrieving candidate preceding event fragments, compare the effective timing of the current event fragment with that of the candidate preceding event fragments; If the current event fragment takes effect earlier than the candidate preceding event fragment, the current event fragment is written into the out-of-order event set. When the current event fragment and the candidate preceding event fragment record mutually exclusive state values ​​in the same state field within the same effective period, the current event fragment will be written to the source conflict pending confirmation state; among them, event fragments in the out-of-order event set do not participate in the generation of transaction fulfillment state and annual fee period state.

5. The knowledge graph-based enterprise intellectual property service matching and risk warning method according to claim 4, characterized in that, The specific steps for verifying the connection between platform business events and official status events according to the event source level and writing conflict markers are as follows: read event fragments from the platform event path whose event source is patent transaction service and annual fee monitoring service as platform business events, and read event fragments from the official status event path whose event source is official status synchronization service as official status events. When an official status event and a platform business event belong to the same unified asset identifier, the official status event passes the effective timing verification, and the official status event and the platform business event correspond to the same status field and the status field records the same status value, the platform business event is written into the acceptance completion event set. When the status field corresponding to a platform business event is confirmed by an official status event under the same unified asset identifier, and no official status event for accepting the platform business event has been read at the time of this verification, the platform business event is written into the accepting confirmation event set; the effective sequence of patent transaction service events that have not been written into the out-of-order event set and those with pending source conflict status are read to form the transaction performance interval; Read the effective sequence of annual fee monitoring service events that are not written out of order and have pending source conflict status, as well as the expiration status events in the official status events, to form the annual fee expiration period; When the start of the transaction fulfillment period is no later than the end of the annual fee period, and the start of the annual fee period is no later than the end of the transaction fulfillment period, and the official status event corresponding to the transaction fulfillment status has not been completed, a conflict marker is written in the current asset acceptance status. The conflict marker is the transaction annual fee conflict marker. When there are missing start points or missing end points in the transaction performance period and annual fee period, a pending confirmation mark is written to the period, but a transaction annual fee conflict mark is not written. The transaction annual fee conflict mark is written to the current asset acceptance status, but not to the status field in the official status event path.

6. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 5, characterized in that, The specific operation of the transaction license mapping process is as follows: read the patent transaction service event used to form the transaction performance status in the current asset acceptance status, and the annual fee monitoring service event and the term status event used to form the annual fee term status; when the patent transaction service event, the annual fee monitoring service event and the term status event do not belong to the same unified asset identifier, generate a transaction operation license field indicating restricted display, closed order placement and closed performance confirmation; When a patent transaction service event, an annual fee monitoring service event, or a term status event has been written into any of the following sets: out-of-order event set, source conflict pending confirmation status, or acceptance confirmation event set, a transaction operation permission field is generated indicating restricted display, closed order placement, and closed performance confirmation. When the current asset acceptance status has a pending confirmation mark, a transaction operation permission field is generated indicating restricted display, closed order placement, and closed performance confirmation. When the current asset acceptance status has a transaction annual fee conflict mark and the official status event has not been completed, a transaction operation permission field is generated indicating restricted display, closed order placement, and closed performance confirmation. When patent transaction service events, annual fee monitoring service events, and term status events are not written into the out-of-order event set, the source conflict pending confirmation status, and the acceptance confirmation event set, and the current asset acceptance status does not have a range pending confirmation mark or a transaction annual fee conflict mark, and the transaction performance status and annual fee term status are both completed by official status events, a transaction operation license field is generated indicating full display, open order placement, and open performance confirmation; among which, the transaction operation license field includes the display interface license value, the order placement interface license value, the performance confirmation interface license value, and the license source water level.

7. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 6, characterized in that, The specific steps for writing the transaction operation license field into the patent transaction service, and for the patent transaction service to perform the open processing of the display interface, order placement interface, and performance confirmation interface according to the transaction operation license field, are as follows: Read the existing transaction operation license field in the patent transaction service according to the unified asset identifier; if no existing transaction operation license field is read, write the current transaction operation license field into the patent transaction service; if an existing transaction operation license field is read, compare the license source water level of the current transaction operation license field with that of the existing transaction operation license field; if the license source water level of the current transaction operation license field is later than that of the existing transaction operation license field, write the current transaction operation license field into the patent transaction service; if the license source water level of the current transaction operation license field is not later than that of the existing transaction operation license field, retain the existing transaction operation license field. The patent transaction service controls the transaction display results according to the display interface license value, controls the establishment of order records according to the order placement interface license value, and controls the writing of performance confirmation records according to the performance confirmation interface license value.

8. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 7, characterized in that, The specific operations of the early warning routing process are as follows: read the annual fee term status, transaction annual fee conflict flag, current verification water level, and early warning write-back path in the current asset acceptance status; read the term date in the annual fee term status, and use the grace period end date as the term endpoint when there is a grace period end date, and use the term date as the term endpoint when there is no grace period end date, and convert the current verification water level into the verification date; If any of the following situations are met: the current fee period status does not correspond to the same unified asset identifier, the period endpoint is missing, the current verification water level is missing, or the renewal warning advance period is missing, the routing status of the renewal warning message routing record will be recorded as pending confirmation. If none of the above conditions apply, and the verification date is not later than the deadline, and the date interval between the deadline and the verification date is greater than the renewal warning lead time, the routing status of the renewal warning message routing record will be recorded as "not to be sent for the time being".

9. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 8, characterized in that, The specific operation for generating renewal warning message routing records is as follows: when the term endpoint enters the warning window, the annual fee term status is taken over by the official status event, and there is no transaction annual fee conflict mark in the current asset acceptance status, the routing object of the renewal warning message routing record is determined to the renewal processing node corresponding to the same unified asset identifier. When the term endpoint enters the warning window, the current asset acceptance status has a transaction annual fee conflict marker, and the official status event corresponding to the transaction annual fee conflict marker has not been completed, the routing object of the renewal warning message routing record will be determined as the renewal processing node and transaction processing node corresponding to the same unified asset identifier; when the transaction annual fee conflict marker cannot correspond to the event fragment that triggered the conflict, the transaction fulfillment interval, the annual fee term interval, and the official acceptance status, the routing status of the renewal warning message routing record will be recorded as pending confirmation; when there is already a renewal warning message routing record in the warning write-back path that is consistent with the unified asset identifier, term endpoint, and routing object corresponding to this renewal warning message routing record and whose routing status is sent, a renewal warning message routing record with a routing status of sent will not be generated again.

10. The method for matching and risk warning of enterprise intellectual property services based on knowledge graphs according to claim 9, characterized in that, The specific steps for encapsulating renewal warning message routing records into event fragments and writing them back to the asset status knowledge graph are as follows: encapsulate renewal warning message routing records into event fragments according to the unified asset identifier, current verification level, and routing status; write the event fragments into the warning write-back path in the asset status knowledge graph; Among them, the event fragments written to the warning write-back path are not written to the official status event path, and the annual fee period status, transaction fulfillment status, and transaction annual fee conflict flag are not rewritten.

Images