DETAILED ACTION
This action is in response to communication filed on 3/13/2025
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/4/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 7, 16-17, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hunn (US 2024/0202663).
Regarding claim 1, Hunn discloses a system, comprising:
processing circuitry configured to generate a graph based on a plurality of messages, wherein to generate the graph (Hunn discloses a system that builds and maintains a cryptographic graph data structure; [0060] “The system and method uses a cryptographic graph data structure that represents and may stores the state of a contract. Objects are preferably immutably added to the graph in an append-only fashion when events, transactions, updates, and other operations occur under the contract and/or otherwise relate to the contract”), the processing circuitry is further configured to:
instantiate a first message node that represents a first message of the plurality of messages (Hunn discloses creating nodes in the graph for events and state updates. An “event object” node records post-formation events/inputs/outputs/transactions (first message). A “state update object” node stores the resulting state change; [0134] “A state update object is an object type used in after formation of the contract that stores the current post-formation state of the contract without amending the logic of the contract itself. The state update clause preferably reflects changes in variables or data integrated with the contract”, [0135] “An event object is an object type that can record post-formation events that occur in respect of the contract that may or may not update the state of the contract/COG. For example, event objects may be used to record outputs from the contract to external systems (e.g. update of a price to an invoice on an external system, via an API etc.); transactions that occur on BDLs; and/or inputs to the contract from external resources, the contracting parties, and/or third parties”);
generate a first data node based on processing of the first message (Hunn discloses processing a state update/event appends a new object/node representing the updated/current state (first data node). New data/changes cause new nodes to be added and linked; [0072-0073] “Accordingly, executing formation of the COG can include one or more instances of receiving a state update S210 and appending at least one update object component to the COG in accordance with the contract state update S220…New data, changes in logical state, interactions with external resources, amendments, and/or other changes are preferably appended or committed to the COG to preserve a secure and trusted historical record of the computable contract”, [0134] “the current/updated state of the ‘price’ object may be stored as a node in the graph, which may be linked to prior states of that object and/or the original formation object state”);
instantiate a second message node that represents a second message of the plurality of messages, wherein the second message is indicative of the generation of the first data node and comprises data and transactional information associated with the first data node (Hunn discloses the state update object (or commit object) itself serves as the second message node. It is “indicative of the generation” of the new state (first data node) because it records/reflects the change that produced the new state object. It comprises the data (updated variables/values) and transactional metadata (UUIDs, timestamps, previous update UUID, execution data, signatures, source of data, etc); [0208] “State updates may take the form of: a new, modified, state of object(s) that comprise a clause, an update object, an event object, and/or any other appropriate object or mechanism of updating the contract data structure”, [0210-0212] “The update object may store any appropriate data—which may vary according to the source, event, clause and/or contract in question. Exemplary metadata may include (but is not limited to and does not have to include):…State updates may include metadata being added to the update, which may include (but may not be limited to and does not have to include): the UUID/identifier for the clause (and/or atomic object(s)…applicable data relating to the source of any data that caused the state such as the API, transaction or other data from a BDL data etc”); and
create a first history node that links the first message node, the second message node, and the first data node (Hunn discloses commit object/state update object and versioning/Merkle links. The commit/state update object centrally records and links the causing events (first message), the resulting new state (first data node), and the change metadata (second message/transactional record). Versioning links connects prior state to the new state with the update/commit defining the link. The MDAG structure makes the entire history traversable; [0175] “A version link type may be used, which preferably represents a link to a prior version of an object within the graph. An example would be a prior version of an object within a contract, linking to a new version of the object. Other versioning relationships or approaches may be used alternatively or in combination. A versioning link therefore implies that the Merkle link between the two or more objects represents a change in version of that object. A versioning link may be used to create the edge on the graph representing an ‘update’ between the existing/previous state and the updated/new state of an object”), and
wherein the generated graph facilitates query response generation (Hunn; [0060] “The data structure provides a versioned history of contractual state that can be used, amongst other applications: (a) to query the data structure to display events and contract updates to users (e.g. event streams/feeds, audit trails, notifications); to provide analytics of the state of one or more contracts (e.g. metrics, graphs, dashboards); (b) by contract logic and/or ‘on-chain’/‘on-ledger’ scripts (e.g. by using graph object states in execution of logic); (c) to audit or replay the state of the contract; and (d) to push or otherwise store the state of the contract, or part thereof, to BDLs. Other applications may be used”).
Regarding claim 2, Hunn discloses the system of claim 1, wherein the first history node links the first message node, the second message node (Hunn [0127] “The graph data structure preferably consists of nodes of various object types and links/edges connecting those nodes. These objects components relate to the state of the contract—including (but not limited to): natural language content, executable code, metadata relating to contractual, and other events, transactions, and operations, and the current state of the contract”), and the first data node to indicate that (i) the first data node is an output associated with the processing of the first message represented by the first message node (Hunn [0190] “as the state of a contract changes, an updated record of the atomic object is stored as a node in the graph”) and (ii) the second message node, that represents the second message, stores a change associated with the first data node (Hunn [0178] “Commit objects preferably include metadata, which may include…details of the contracting party that performed the commit, including a timestamp and cryptographic signature of the submitting party”).
Regarding claim 3, Hunn discloses the system of claim 1, wherein the first message corresponds to a command, and the first data node is generated based on an execution of the command (Hunn [0208] “state updates are messages (‘transaction-like’ function calls; that may be signed or unsigned data packets) that call exposed functions with appropriate argument values. These occur either by way of input to the contract; internal operation of the contract (e.g. one object updating another object); output from the contract, or any other suitable form”).
Regarding claim 4, Hunn discloses the system of claim 1, wherein the first message corresponds to an event, and the first data node is generated based on a handling of the event (Hunn [0208] “State updates may take any suitable form. State updates may take the form of: a new, modified, state of object(s) that comprise a clause, an update object, an event object, and/or any other appropriate object or mechanism of updating the contract data structure”).
Regarding claim 7, Hunn discloses the system of claim 1, wherein the processing circuitry is further configured to create:
a first history-message edge between the first history node and the first message node, the first history-message edge indicating that the first message represented by the first message node is a cause for the generation of the first data node (Hunn [0174] “A dependency link type may be used, which preferably represents a dependency link, meaning that the linked objects serves as a logical input to the Merkle root object of the target/linked object or other relationship between objects in the graph (e.g. one object is an input to another, such as a ‘temperature’ object in one clause being an input to a ‘pricing’ or ‘warranty’ clause)”),
a first history-data edge between the first history node and the first data node, the first history-data edge indicating that the first data node is an output associated with the processing of the first message (Hunn [0176] “A relationship link type preferably represents a relationship between two or more objects. Relationship links may be used where an object is added to the graph that does not represent a link indicating a change in state of an object (and therefore is not suited to a versioning link) by an action, operation or event that occurs by operation of the contractual logic or otherwise, e.g. between an event object and a clause object representing a transaction or action that occurred on a BDL or API”), and
a second history-message edge between the first history node and the second message node, the second history-message edge indicating a change associated with the first data node (Hunn [0175] “A versioning link may be used to create the edge on the graph representing an ‘update’ between the existing/previous state and the updated/new state of an object. The versioning may occur in the formation (e.g. where the contract is negotiated) or post-formation state of the contract (e.g. if the logic of the contract is amended after execution or the state of the contract changes by reason of its execution”).
Regarding claim 16, Hunn discloses the system of claim 1, wherein the processing circuitry is further configured to identify, in the graph, a third data node that corresponds to a previous version of the first data node, and wherein the third data node is modified based on the processing of the first message to generate the first data node (Hunn [0175] “A version link type may be used, which preferably represents a link to a prior version of an object within the graph. An example would be a prior version of an object within a contract, linking to a new version of the object … A versioning link may exist between any objects in the graph (e.g. between atomic objects, between clause objects, between section objects) and may include a commit and/or state update object defining the link and the update”).
Regarding claim 17, Hunn discloses the system of claim 1, wherein the processing circuitry is further configured to:
receive a query that comprises a reference value (Hunn [0225] “The graph may be queried by an API so that data can be displayed via a graphical user interface, command line Interface, or any appropriate manner as shown in FIG. 29. The data from the graph may be used to display data to the end user in a number of different forms that may include, but are not limited to: displaying feeds of events (chronological, filterable by event type, event attributes etc.) that occur under a contract, changes in the state of contracts, ‘pop-over’ data of the history of objects (e.g. price) in clauses (see FIG. 10)”);
identify, in the graph, at least one history node having a data value that is associated with the reference value (Hunn [0216] “each state may be (but does not have to be) tied to the previous state: creating an append-only log of immutable state updates (see FIG. 25 for an example)—these state updates may be used to ‘rewind’ or ‘restore’/‘replay’ the state of a contract or contracts (where ‘linked’) in a manner similar to event sourcing systems as each state update reflects a ‘snapshot’ of the contract (see FIG. 26 for an example)”);
identify one or more edges associated with the identified history node (Hunn [0171] “The graph may also consist of links (graph edge) structures to other objects, which may include the following fields: the UUID of the link; the UUID of the linked object; and the type of link. In a preferred embodiment, at least three types of link may exist: a dependency link; a versioning link; a relationship link; and/or a metadata link relating to the link”); and
generate a response to the query based on at least one of the identified history node and the identified one or more edges (Hunn [0225] “displaying feeds of events (chronological, filterable by event type, event attributes etc.) that occur under a contract, changes in the state of contracts, ‘pop-over’ data of the history of objects (e.g. price) in clauses (see FIG. 10)”).
Regarding claim 20, is rejected under the same rationale as claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Hunn (US 2024/0202663) in view of Hunn (US 2024/0202663) in view of Beyer (US 2023/0014255).
Regarding claim 5, Hunn discloses the system of claim 1, wherein the second message corresponds to an event header.
Beyer in the field of the same endeavor discloses techniques for bundling line item based events in an event-driven architecture. In particular, Beyer teaches the following:
wherein the second message corresponds to an event header (Beyer [0034] “The improved bundled message 400 includes a single set of technical metadata 402, a single set of event metadata 404 (e.g., including an event type of ItemApprovedBundle 406, an event identifier 408, and other event metadata 410), and a single event header 412 in an event payload 414. The single event header 412 includes a purchase requisition identifier 416, a total net amount 418, and an overall status 420”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Beyer. One would have been motivated because Beyer teaches for efficiency in conveying aggregated/stateful information tied to event processing. This is a known technique in event-driven architectures for reducing overhead while preserving the data and metadata linked to data changes/generation.
Claims 6, 9, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hunn (US 2024/0202663) in view of Hunn (US 2024/0202663) in view of Lin et al. (US 2018/0075159).
Regarding claim 6, Hunn discloses the system of claim 1, wherein a response to a query is generated based on at least one of a group consisting of (i) the first message node, (ii) node properties of the first message node, (iii) the first history node, (iv) node properties of the first history node, (v) the first data node, (vi) node properties of the first data node, (vii) the second message node, or (viii) node properties of the second message node.
Lin in the field of the same endeavor discloses techniques for storing streaming graphs. In particular, Lin teaches the following:
wherein a response to a query is generated based on at least one of a group consisting of (i) the first message node, (ii) node properties of the first message node (Lin [0086] “The multi-version graph engine 801 accepts graph updates and returns graph queries 404. A versioning control module 802 provides version numbers (e.g., timestamps) and controls the number of versions 803 to maintain (e.g., sliding window size)”), (iii) the first history node, (iv) node properties of the first history node, (v) the first data node, (vi) node properties of the first data node, (vii) the second message node, or (viii) node properties of the second message node.
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Lin. One would have been motivated because Lin enables efficient, version-aware query processing over streaming updates while optimizing storage through multi-version history maintenance.
Regarding claim 9, Hunn discloses the system of claim 7, wherein a response to a query is generated based on at least one of a group consisting of (i) the first history-message edge (Lin [0071] “a history of updates to the graph database is maintained (e.g., stored on disk), which includes previous updates to a list of edges of a vertex and/or updating properties for vertices and edges. In this way, data is stored to a new copy of the graph database, while maintaining a link to a previous version”. Rationale to combine is similar to claim above), (ii) edge properties of the first history-message edge, (iii) the first history-data edge, (iv) edge properties of the first history-data edge, (v) the second history-message edge, or (vi) edge properties of the second history-message edge.
Regarding claim 10, Hunn discloses the system of claim 1, wherein the processing circuitry is further configured to delete the first data node from the graph (Lin [0083] “In a case where the computer system 400 removes a vertex or an edge, a counter in corresponding property files (e.g., prop1, 503) are decreased and entries are removed when the counter becomes zero” .Rationale to combine is similar to claim above).
Regarding claim 18, Hunn discloses the system of claim 1, wherein the processing circuitry is further configured to:
receive a query that comprises a reference value (Hunn [0078] “The method can include querying the COG and providing a versioned history of contract state. In some cases, this may be the history on the whole contract or different elements of the contract. For example, the COG may be used in generating a time series record of pricing values as driven and represented in a pricing clause. Querying the COG can additionally be used in replaying the COG to revisit how the state changed”);
identify, in the graph, at least one history node having a data value that is associated with the reference value (Hunn [0078] “Querying the COG can additionally be used in replaying the COG to revisit how the state changed”);
determine that a data node associated with the identified history node is absent in the graph (Lin [0083] “In a case where the computer system 400 removes a vertex or an edge, a counter in corresponding property files (e.g., prop1, 503) are decreased and entries are removed when the counter becomes zero”);
identify, in the graph, based on the identified history node, a message node that represents a message comprising data and transactional information associated with the data node (Hunn [0206] “state update objects are preferably used to update and/or transition the state of the contract in the post-formation stage as shown in FIGS. 6, 18, 23, 24A, and 24B. A state update object may itself be stored in the graph data structure so that a record exists as to what caused a given change in the state of an object/contract”);
recreate, based on the identified message node, the data node associated with the identified history node (Hunn [0144] “Through this design preferably no data communication layer between the clauses needs to be established as all communication happens through the storage medium and the atomic objects themselves. This, combined with the inherent versioning of all objects in the system, makes is also possible to ‘replay’ the entire history of all changes, not just of the contract and contract output, but also all input”); and
generate a response to the query based on the recreated data node (Hunn [0117] “the graph data structure may be queried or otherwise utilized to: (a) generate or display data visualizations, graphics, dashboards and other data metrics; (b) provide data feeds, chronological and filterable event feeds, notifications (as shown in exemplary FIGS. 9 and 28), transaction and event logs and other representations of state, potentially in real time or near real time; (c) display parameters and/or other data in a ‘prose view’ of a contract (as shown in exemplary FIG. 10)—in whole or in part—where appropriate (e.g. a ‘price’ object may be displayed in a contract that updates based upon the state of the graph)”. Rationale to combine is similar to claim above).
Allowable Subject Matter
Claims 8, 11-15 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chris Parry can be reached at 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights