DETAILED ACTION
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 . Claims 1-20 are pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03.
Per Step 1, claims 1 and 2 are directed to a method (i.e., a process), and claim 12 is directed to a system (i.e., a machine). Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 U.S.C. 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea of claim 1 is:
recording, having one or more permissions to act on behalf of a first party, one or more events, wherein the one or more permissions include permission to sign a contract on behalf of the first party;
recording, granted one or more permissions to act on behalf of a second party, one or more events, wherein the one or more permissions include permission to sign the contract on behalf of the second party;
wherein the one or more events recorded and the one or more events recorded one of comprise and evidence the contract between the first party and the second party;
wherein the contract is human readable, and legally enforceable.
The abstract idea of claims 2 and 12 (claim 2 being representative) is:
in response to receiving input from a first party configuring, one or more revocable permissions to act on behalf of the first party, the one or more revocable permissions including signing a contract between the first party and a second party;
in response to receiving input from the second party, configuring one or more revocable permissions to act on behalf of the second party, the one or more revocable permissions including signing the contract; and
recording one or more events;
wherein the one or more events one of comprise and evidence the contract; and
wherein the contract is human readable, and legally enforceable.
The abstract idea steps italicized above involves contracting, permission delegation, and legal enforceability, which constitutes a process that, under its broadest reasonable interpretation (BRI), covers commercial activity. This is further supported by paragraph [0048] of applicant’s specification as filed. If a claim limitation, under its BRI, covers commercial interactions, including contracts, legal obligations, advertising, marketing, sales activities or behaviors, and/or business relations, then it falls within the Certain Methods of Organizing Human Activity – Commercial or Legal Interactions grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Additionally and alternatively, the abstract idea steps recited above are those which could be performed mentally, including with pen and paper. Applicant has broadly claimed recording events in a contracting process. Under its BRI, it is covered under Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas, given that they pertain to data gathering. This is further supported by paragraph [0050] of applicant’s specification as filed. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f).
Claim 1 recites the following additional elements: micro-ledgers; computer processors; using a first software agent; using a second software agent; machine readable.
Claim 2 recites the following additional elements: micro-ledgers; computer processors; through one or more computing devices; a first software agent; through the one or more computing devices; a second software agent; using the first software agent and the second software agent, each acting within its one or more revocable permissions, to one or more micro-ledgers; machine readable.
Claim 12 recites the following additional elements: micro-ledgers; one or more servers at least intermittently communicatively coupled with one or more computing devices and providing one or more software elements, the one or more software elements configured to be executed by one or more processors to; through one or more computing devices; a first software agent; through the one or more computing devices; a second software agent; using the first software agent and the second software agent, each acting within its one or more revocable permissions, to one or more micro-ledgers; machine readable.
These elements are merely instructions to apply the abstract idea to a computer, per MPEP §2106.05(f). Applicant has only described generic computing elements in their specification, as seen in paragraphs [0033] – [0035] of applicant’s specification as filed, for example.
Further, the combination of these elements is nothing more than a generic computing system. Because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f), they do not integrate the abstract idea into a practical application.
Accordingly, these additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP §2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two on the considerations discussed in MPEP §2106.05(f).
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that facilitates the tasks of the abstract idea, as described in MPEP §2106.05(f).
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
Further, the analysis takes into consideration all dependent claims as well:
Regarding claims 3 – 4, 6, 8, 11, 14 – 16, 19, and 20, applicant further narrows the abstract idea with additional step(s). There are no further additional elements to consider, beyond those highlighted above. This further narrowing of the abstract idea, similar to above, is also not patent eligible. See MPEP §2106.05(f).
Claim 5 includes further additional elements with additional description: configuring a third software agent with one or more revocable permissions to act on behalf of the first party. There are no further additional elements to consider beyond those highlighted above. This does not integrate the abstract idea into practical application and is not significantly more.
Claim 7 includes further additional elements with additional description: wherein the methods are implemented at least in part using a data-exchange control layer for decentralized applications (dApps). There are no further additional elements to consider beyond those highlighted above. This does not integrate the abstract idea into practical application and is not significantly more.
Claim 9 includes further additional elements with additional description: wherein the first software agent and the second software agent write to the one or more micro-ledgers using their own unique decentralized identifiers (DIDs), and wherein the DIDs are used to define ownership and access control over the one or more micro-ledgers. There are no further additional elements to consider beyond those highlighted above. This does not integrate the abstract idea into practical application and is not significantly more.
Claim 10 includes further additional elements with additional description: wherein one or more DID documents are further used to define ownership and access control over the one or more micro-ledgers. There are no further additional elements to consider beyond those highlighted above. This does not integrate the abstract idea into practical application and is not significantly more.
Claim 13 includes further additional elements with additional description: wherein the first software agent and the second software agent write to the one or more micro-ledgers using their own unique decentralized identifiers (DIDs). There are no further additional elements to consider beyond those highlighted above. This does not integrate the abstract idea into practical application and is not significantly more.
Claim 17 includes further additional elements with additional description: wherein one of the first software agent and the second software agent comprises software code running in a cloud computing environment. There are no further additional elements to consider beyond those highlighted above. This does not integrate the abstract idea into practical application and is not significantly more.
Claim 18 includes further additional elements with additional description: wherein one of the first software agent and the second software agent is online in a networked computing environment. There are no further additional elements to consider beyond those highlighted above. This does not integrate the abstract idea into practical application and is not significantly more.
Accordingly, claims 1-20 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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, 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 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.
Claims 1-8, 12, and 16-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Treat (US 20190253240) in view of Fournier (US 20210166246).
Claim 1
Regarding claim 1, Treat discloses:
Data contract methods using micro-ledgers, comprising: {The B4C platform is a computer-implemented contract management system that uses blockchain and distributed ledger technology to manage and record contracts (paragraphs 0016, 0035).}
using one or more computer processors: {The platform relies on computing devices, servers, and nodes, each with processors, to execute transactions (paragraph 0032).}
recording to one or more micro-ledgers, one or more events, wherein the one or more permissions of the first software agent include permission to sign a contract on behalf of the first party; {The B4C platform describes a sender (i.e., first party) using computing devices and GUIs to create, sign, and submit contracts, with digital signatures serving as permissions to act on behalf of that party. Event such as contract creation and signing are recorded to the blockchain ledger (paragraphs 0019, 0069).}
recording to the one or more micro-ledgers, one or more events, wherein the one or more permissions of the second software agent include permission to sign the contract on behalf of the second party; {The B4C platform describes a receiver (i.e., second party) who accesses, edits, approves, and sign the contract. The receiver’s digital signature or permission is added to the transaction object and recorded in the blockchain ledger (paragraphs 0071, 0073 – 0074).}
wherein the one or more events recorded using the first software agent and the one or more events recorded using the second software agent one of comprise and evidence the contract between the first party and the second party; {Both sender and receiver events (e.g., signing and approval) are recorded as transactions with corresponding hash codes. These events together comprise and evidence the contract, which becomes finalized once both parties and the notary sign (paragraphs 0067, 0073, 0076).}
wherein the contract is human readable, machine readable, and legally enforceable. {The contracts are described as electronic documents editable by the parties (i.e., human readable), stored as transaction objects with hash codes (i.e., machine readable), and legally enforceable (paragraphs 0019, 0039, 0065).}
Treat does not disclose:
using a first software agent having one or more permissions to act on behalf of a first party;
using a second software agent granted one or more permissions to act on behalf of a second party.
However, Fournier, in a similar field of endeavor directed to permissioned data exchange among parties over the internet, teaches:
using a first software agent having one or more permissions to act on behalf of a first party {The system configures the party’s software agent (i.e., JLINC Data Service) with revocable authorization via cryptographically signed Information Sharing Agreements (ISAs). The first party signs and the counterparty countersigns, enabling the agent to act on the party’s behalf, including signing the contract between the parties, and the authorizations can be changed or withdrawn at any time (paragraphs 0031, 0054 – 0056, 0090 – 0092, 0095 – 0098).}
using a second software agent granted one or more permissions to act on behalf of a second party {The JLINC Solutions Service (i.e., second part), in response to initializing customers or calling the API, is configured to act on that party’s behalf and sign or countersign the ISA. The permissions are revocable via key withdrawal and signed permission control under the ISA (paragraphs 0081 – 0087, 0092, 0097, 0116 – 0119, 0124 – 0125).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the digital records management features of Treat to include the automated electronic data transfer authorization features of Fournier, to provide for an automated way to control the use of data after it has been transmitted from one computing device to another computing device, or from one database to another database, using the Internet or other network. (see paragraph 0006 of Fournier).
Claims 2 and 12
Regarding claims 2 and 12 (claim 2 being representative), Treat discloses:
(claim 2) A data contract method using micro-ledgers, comprising: {The B4C platform is a computer-implemented contract management system that uses blockchain and distributed ledger technology to manage and record contracts (paragraphs 0016, 0035).}
(claim 2) using one or more computer processors: {The platform relies on computing devices, servers, and nodes, each with processors, to execute transactions (paragraph 0032).}
(claim 12) A data contract system using micro-ledgers, comprising: {The B4C platform is a computer-implemented contract management system that uses blockchain and distributed ledger technology to manage and record contracts (paragraphs 0016, 0035).}
(claim 12) one or more servers at least intermittently communicatively coupled with one or more computing devices and providing one or more software elements, the one or more software elements configured to be executed by one or more processors to; {The platform relies on computing devices, servers, and nodes, each with processors, to execute transactions (paragraph 0032). “Implementations of the present disclosure can be realized in digital electronic circuitry, integrated circuitry, specially designed application specific integrated circuits (ASICs), computer hardware, firmware, software, and/or combinations thereof.” (paragraph 0090).}
to one or more micro-ledgers; {Both sender (i.e., first party) and receiver (i.e., second party) perform actions such as signing a contract. These actions are recorded as transactions with corresponding hash codes on the blockchain ledger (paragraphs 0019, 0069, 0073 – 0074).}
wherein the one or more events one of comprise and evidence the contract; and {Both sender and receiver events (e.g., signing and approval) are recorded as transactions with corresponding hash codes. These events together comprise and evidence the contract, which becomes finalized once both parties and the notary sign (paragraphs 0067, 0073, 0076).}
wherein the contract is human readable, machine readable, and legally enforceable. {The contracts are described as electronic documents editable by the parties (i.e., human readable), stored as transaction objects with hash codes (i.e., machine readable), and legally enforceable (paragraphs 0019, 0039, 0065).}
Treat does not disclose:
in response to receiving input from a first party through one or more computing devices, configuring a first software agent with one or more revocable permissions to act on behalf of the first party, the one or more permissions including signing a contract between the first party and a second party;
in response to receiving input from the second party through the one or more computing devices, configuring a second software agent with one or more revocable permissions to act on behalf of the second party, the one or more revocable permissions including signing the contract; and
recording one or more events using the first software agent and the second software agent, each acting within its one or more revocable permissions.
However, Fournier, in a similar field of endeavor directed to permissioned data exchange among parties over the internet, teaches:
in response to receiving input from a first party through one or more computing devices, configuring a first software agent with one or more revocable permissions to act on behalf of the first party, the one or more permissions including signing a contract between the first party and a second party {Upon first-party input (e.g., clicking “Control Your Data”/login), the system configures the party’s software agent (i.e., JLINC Data Service) with revocable authorization via cryptographically signed Information Sharing Agreements (ISAs). The first party signs and the counterparty countersigns, enabling the agent to act on the party’s behalf, including signing the contract between the parties, and the authorizations can be changed or withdrawn at any time (paragraphs 0031, 0054 – 0056, 0090 – 0092, 0095 – 0098).}
in response to receiving input from the second party through the one or more computing devices, configuring a second software agent with one or more revocable permissions to act on behalf of the second party, the one or more revocable permissions including signing the contract {The JLINC Solutions Service (i.e., second part), in response to initializing customers or calling the API, is configured to act on that party’s behalf and sign or countersign the ISA. The permissions are revocable via key withdrawal and signed permission control under the ISA (paragraphs 0081 – 0087, 0092, 0097, 0116 – 0119, 0124 – 0125).}
recording one or more events using the first software agent and the second software agent, each acting within its one or more revocable permissions {Both parties’ agents (i.e., JLINC Data Service and JLINC Solution Service), operating under revocable permissions based on an ISA, record each event by generating and sending signed data events receipts to the JLINC Audit Service (paragraphs 0031, 0035, 0081 – 0087, 0098, 0122 – 0124).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the digital records management features of Treat to include the automated electronic data transfer authorization features of Fournier, to provide for an automated way to control the use of data after it has been transmitted from one computing device to another computing device, or from one database to another database, using the Internet or other network. (see paragraph 0006 of Fournier).
Claim 3
Regarding claim 3, the combination of Treat and Fournier teaches the limitations set forth above. Treat further discloses:
wherein the input from the first party comprises a cryptographically signed document, and wherein the input from the second party comprises a cryptographically signed document. {The sender and receiver sign contracts using digital signatures based on asymmetric cryptography (paragraphs 0028, 0069, 0073 – 0074).}
Claim 4
Regarding claim 4, the combination of Treat and Fournier teaches the limitations set forth above. Fournier further teaches:
in response to receiving input from the first party through the one or more computing devices, revoking one or more or all permissions of the first software agent to act on behalf of the first party. {When the first party acts via the JLINC app, she may change, update, or withdraw previously granted authorizations at any time. She may also instruct deletion and the protocol supports key withdrawal or supersession (i.e., together revoking some or all permissions of her agent, the JLINC Data Service) to act on her behalf) (paragraphs 0032, 0072, 0098, 0120, 0124).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the automated electronic data transfer authorization features of Fournier, to provide for an automated way to control the use of data after it has been transmitted from one computing device to another computing device, or from one database to another database, using the Internet or other network. (see paragraph 0006 of Fournier).
Claim 5
Regarding claim 5, the combination of Treat and Fournier teaches the limitations set forth above. Fournier further teaches:
further comprising configuring a third software agent with one or more revocable permissions to act on behalf of the first party. {A third software agent (e.g., FinCo’s JLINC Solution Service), upon input from the first party (e.g., Alice) asking FinCo to act “on her behalf”, is configured to operate under permissions based on a cryptographically signed ISA that Alice can change , update, or withdraw at any time (i.e. revocable), enabling that third agent to act for her within those permissions (paragraphs 0031, 0081 – 0087, 0098, 0106, 0124).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the automated electronic data transfer authorization features of Fournier, to provide for an automated way to control the use of data after it has been transmitted from one computing device to another computing device, or from one database to another database, using the Internet or other network. (see paragraph 0006 of Fournier).
Claim 6
Regarding claim 6, the combination of Treat and Fournier teaches the limitations set forth above. Fournier further teaches:
wherein the method does not require the use of blockchain consensus because formation of the contract, data exchange, and data control occur off-chain, and wherein the method further does not require a consensus fee, does not require the use of a data exchange fee, and does not require the use of a crypto wallet. {The system implements off-chain contract formation, data exchange, and data use control via cryptographically signed ISAs between parties and a fourth party Audit Service (i.e., no blockchain consensus). It does not require consensus mechanisms, therefore no consensus fee, crypto token or wallet, or data exchange fees. Interactions occur among databases using keypairs and OAuth2 (paragraphs 0031, 0035, 0074, 0100 – 0104, 0122 – 0124).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the automated electronic data transfer authorization features of Fournier, to provide for an automated way to control the use of data after it has been transmitted from one computing device to another computing device, or from one database to another database, using the Internet or other network. (see paragraph 0006 of Fournier).
Claim 7
Regarding claim 7, the combination of Treat and Fournier teaches the limitations set forth above. Treat further discloses:
wherein the methods are implemented at least in part using a data-exchange control layer for decentralized applications (dApps). {Each node runs a Corda distributed application and invokes flows via remote procedure calls under Corda’s orchestration framework, with timestamping services and a notary service mediating when data is exchanged (i.e. data exchange control layer) (paragraphs 0040 – 0041, 0045, 0047 – 0049).}
Claim 8
Regarding claim 8, the combination of Treat and Fournier teaches the limitations set forth above. Fournier further teaches:
wherein the methods are configured to operate outside of a Web3 computing environment. {Contracts are cryptographically signed ISAs exchanged between server-side services and databases or APIs (i.e., not smart contracts), communications use OAuth2, and an external Audit Service stores matched receipts. In other words, the methods are configured to operate a Web3 environment (i.e., no consensus layer, tokens, or wallet required) (paragraphs 0031, 0035, 0074, 0100, 0104, 0116, 0122 – 0123).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the automated electronic data transfer authorization features of Fournier, to provide for an automated way to control the use of data after it has been transmitted from one computing device to another computing device, or from one database to another database, using the Internet or other network. (see paragraph 0006 of Fournier).
Claim 16
Regarding claim 16, the combination of Treat and Fournier teaches the limitations set forth above. Treat further discloses:
wherein the contract facilitates an automated data exchange between data stores and governs use of the exchanged data. {each party’s node maintains its own database, and CorDapp flows with smart contract logic automatically update and synchronize data between them (paragraphs 0019, 0039 – 0041, 0046, 0067).}
Claim 17
Regarding claim 17, the combination of Treat and Fournier teaches the limitations set forth above. Treat further discloses:
wherein one of the first software agent and the second software agent comprises software code running in a cloud computing environment. {One enterprise’s node is “cloud-hosted (off-premise) while other nodes may be on-premises (paragraph 0031, 0042, 0045).}
Claim 18
Regarding claim 18, the combination of Treat and Fournier teaches the limitations set forth above. Fournier further teaches:
wherein one of the first software agent and the second software agent is online in a networked computing environment. {The second agent (e.g., JLINC Solution Service) is implemented as a cloud service exposing APIs that authenticate, exchange capabilities, and process receipts. These functions are executed under a persistently accessible network service (paragraphs 0012, 0081, 0091, 0100, 0116, 0122 – 0124).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the automated electronic data transfer authorization features of Fournier, to provide for an automated way to control the use of data after it has been transmitted from one computing device to another computing device, or from one database to another database, using the Internet or other network. (see paragraph 0006 of Fournier).
Claim 19
Regarding claim 19, the combination of Treat and Fournier teaches the limitations set forth above. Treat further discloses:
wherein the one or more events recorded by the first software agent and the one or more events recorded by the second software agent are immutable, non-repudiable, and auditable. {The platform records each party’s events as transactions on a blockchain, where entries are immutable, non-repudiable, and auditable (i.e., histories are maintained and viewable) (paragraphs 0019, 0028, 0041, 0047 – 0049, 0061).}
Claim 20
Regarding claim 20, the combination of Treat and Fournier teaches the limitations set forth above. Treat further discloses:
wherein the one or more software elements are further configured to write to one or more documents using the first software agent or the second software agent, and wherein the one or more documents one of comprise and evidence the contract. {The B4C platform has parties’ agents create, edit, approve, and sign contract document via GUIs. Those edits are written to the documents and recorded as transactions, with hashes and signatures, evidence the agreement (paragraphs 0017, 0054, 0062, 0069, 0073, 0076).}
Claims 9-11, and 13 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Treat and Fournier, in further view of Patel (US 20210192520).
Claims 9 and 13
Regarding claims 9 and 13 (claim 9 being representative), while the combination of Treat and Fournier teaches the limitations set forth above, it does not explicitly teach:
wherein the first software agent and the second software agent write to the one or more micro-ledgers using their own unique decentralized identifiers (DIDs), and wherein the DIDs are used to define ownership and access control over the one or more micro-ledgers.
However, Patel, in a similar field of endeavor directed to automated and distributed system utilizing a digital ledger, and a data marketplace in which users control access to their data, teaches:
wherein the first software agent and the second software agent write to the one or more micro-ledgers using their own unique decentralized identifiers (DIDs), and wherein the DIDs are used to define ownership and access control over the one or more micro-ledgers. {Users are identified by decentralized identifiers (DIDs), which can be pairwise-unique and reside in micro-ledgers between two or more parties for whom the DID is relevant. Each DID is linked to a DID Document listing public keys and authentication services, which are used to prove ownership of the keys and to provide authentication and access control (paragraphs 0104 – 0106).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the decentralization and data autonomy features of Patel, to improve the security of personal data of consumers and merchants during application processing/onboarding, transactional payment processing/settlements, and in data marketplaces. (see paragraphs 0001 – 0002 of Patel).
Claim 10
Regarding claim 10, the combination of Treat, Fournier, and Patel teaches the limitations set forth above. Patel further teaches:
wherein one or more DID documents are further used to define ownership and access control over the one or more micro-ledgers. {A DID can be linked to a DID Document, which lists associated public keys and links to authentication services. These public keys and services are used to prove ownership of the public keys. Also, private DIDs can reside in micro-ledgers between parties, therefore the DID Documents linked to those DIDs are further used to define ownership and access control over the micro-ledgers (paragraphs 0104, 0106).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the decentralization and data autonomy features of Patel, to improve the security of personal data of consumers and merchants during application processing/onboarding, transactional payment processing/settlements, and in data marketplaces. (see paragraphs 0001 – 0002 of Patel).
Claim 11
Regarding claim 11, while the combination of Treat and Fournier teaches the limitations set forth above, it does not explicitly teach:
wherein the one or more micro-ledgers do not require any token, do not require centralization, and do not require authority to be created or shared.
However, Patel, in a similar field of endeavor directed to automated and distributed system utilizing a digital ledger, and a data marketplace in which users control access to their data, teaches:
wherein the one or more micro-ledgers do not require any token, do not require centralization, and do not require authority to be created or shared. {Private DIDs can reside inside micro-ledgers between two or more parties without being recorded on a public ledger. Such DIDs support self-sovereign identity, giving users control over their own identity and data across the network without reliance on a central authority. Private, pairwise-unique DIDs operate directly between parties in micro-ledgers, independent of token-based consensus (paragraphs 0102, 0104 – 0105).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the decentralization and data autonomy features of Patel, to improve the security of personal data of consumers and merchants during application processing/onboarding, transactional payment processing/settlements, and in data marketplaces. (see paragraphs 0001 – 0002 of Patel).
Claims 14-15 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Treat and Fournier, in further view of Hunn (US 20180365201).
Claim 14
Regarding claim 14, while the combination of Treat and Fournier teaches the limitations set forth above, it does not explicitly teach:
wherein the one or more events are recorded using a directed acyclic graph (DAG) data structure.
However, Hunn, in a similar field of endeavor directed to creating and executing contracts with programmable components, teaches:
wherein the one or more events are recorded using a directed acyclic graph (DAG) data structure. {“[D]ata is stored using a graph data structure. Preferably as a contract object graph (COG) and more preferably in the form of a Merkle directed acyclic graph (DAG).” “The DAG can store the history of the events in a document (e.g., operations, computations and similar that occur as a result of committing a contract to execution).” (paragraphs 0093 – 0094).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the data structuring and storing features of Hunn, to enable contracts and other commercial documentation to interact with external resources and enable computational functionalities. (see paragraph 0004 of Hunn).
Claim 15
Regarding claim 15, while the combination of Treat, Fournier, and Hunn teaches the limitations set forth above. Hunn further teaches:
wherein the one or more software elements are configured to record the one or more events regardless of which specific DAG data structure is used. {Events can be recorded in a contract object graph (COG) but “more preferably in the form of a Merkle directed acyclic graph (DAG)”. “Alternative approaches to storing relationships and state history may be used (e.g., data stores, databases, message feeds, and file systems such as IPFS).” (paragraph 0093).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Treat and Fournier to include the data structuring and storing features of Hunn, to enable contracts and other commercial documentation to interact with external resources and enable computational functionalities. (see paragraph 0004 of Hunn).
Response to Arguments
Rejections under 35 U.S.C. §112(b)
Claim rejections under § 112(b) are withdrawn in view of Applicant’s amendments.
Rejections under 35 U.S.C. §101
Applicant's arguments filed on 12/15/2025 have been fully considered but they are not persuasive.
At Step 2A, the claims are directed to forming and evidencing legally enforceable contracts between parties. The recited elements fall within commercial or legal interactions. The use of processors, software agents, and ledgers does not change the focus of the claims, which remains contract formation and management. They do not require a particular data structure, a specific mechanism for eliminating consensus, a defined DAG implementation, or any improvement to computer functionality. The claims are developed at a functional level and do not reflect a concrete technological solution.
At Step 2B, the additional elements are generic computer components performing their ordinary functions. The claims do not recite an improvement to in how computers operate. Implementing contract execution and recordation using generic computing components does not amount to significantly more than the abstract idea itself.
Applicant’s mental process argument is also unpersuasive. While Applicant's arguments are well taken, examiner's position is that Applicant has conflated the abstract idea with the additional elements, when offering such comments as "A human mind cannot form two separate software agents, each representing a different party, and using those agents record events to mental micro-ledgers in order to form a legally- enforceable contract". As seen in the analysis above, examiner identified an abstract idea which contains the following steps (claim 1 being representative):
recording, having one or more permissions to act on behalf of a first party, one or more events, wherein the one or more permissions include permission to sign a contract on behalf of the first party;
recording, granted one or more permissions to act on behalf of a second party, one or more events, wherein the one or more permissions include permission to sign the contract on behalf of the second party;
wherein the one or more events recorded and the one or more events recorded one of comprise and evidence the contract between the first party and the second party;
wherein the contract is human readable, and legally enforceable.
Examiner maintains that the steps shown in the abstract idea are those that could be performed mentally and/or manually, i.e., with pen and paper. These are steps that an administrator could perform, in the context of determining whether a contract is enforceable.
Accordingly, the 35 U.S.C. §101 is therefore maintained.
Rejections under 35 U.S.C. §103
While Applicant’s specification as filed describes certain implementations where micro-ledgers can be “single-author” and can avoid blockchain consensus (paragraphs [0067] – [0068]), claims 1-2, and 12 do not recite a DAG requirement, a “single-author only” requirement, or a “no consensus” requirement. Under the BRI in light of the specification, “micro-ledger” reasonably covers a limited scope ledger that can be maintained and viewed participant by participant.
Treat discloses that ledger facts are not globally visible, that participants may only see a facts subset on the ledger, and that nodes may store only portions of the ledger (see paragraphs [0037], [0039], and [0046] of Treat). Treat also discloses recording actions regarding contracts as ledger events (see paragraphs [0068], [0082], and [0088]). Accordingly, Treat remains applicable to the “recording… events… to one or more micro-ledgers” limitation as claimed.
Applicant argues that Treat uses consensus (e.g., notary service) and therefore cannot disclose micro-ledgers. This is not persuasive because claims 1-2, and 12 do not exclude implementations based on consensus. Treat’s use of consensus does not take it outside the scope of the claims as written.
Treat discloses nodes operated by enterprise executing platform software and performing cryptographic signing using private keys (see paragraphs [0045], [0073] – [0074]), and it also discloses access control paradigms for granting or revoking access (see paragraphs [0043] – [0044]). Therefore, first and second software components acting on behalf of respective parties with authority to sign and record events is disclosed or, in the alternative, rendered obvious.
Accordingly, the rejections under 35 U.S.C. §103 are maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS F MONTALVO whose telephone number is (703)756-5863. The examiner can normally be reached Monday - Friday 8:00AM - 5:30PM; First Fridays OOO.
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, Sarah Monfeldt can be reached at 571-270-1833. 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.
/C.F.M./Examiner, Art Unit 3629 /SARAH M MONFELDT/Supervisory Patent Examiner, Art Unit 3629