DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 12/22/2025
Claims 1, 14, and 27 are currently amended
Claims 1-8, 10-21, 23-34, and 36-42 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 statements (IDS) submitted on 08/20/2025, 10/13/2025, and 12/24/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Specification and Claims in the arguments filed on 12/22/2025. Claims 1-8, 10-21, 23-34, and 36-42 remain pending in the application. Examiner has withdrawn the outstanding objections to the claims in view of the amendments. However, additional claim objections arise.
Response to Arguments
Applicant’s arguments filed 12/22/2025, with respect to the rejections of independent claims 1, 14, and 27 and their corresponding dependent claims under 35 USC 103 have been fully considered, but they are not persuasive. Examiner respectfully submits that the previously applied combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi is sufficient to teach the amended limitations. Padmanabhan teaches the amended limitations “responsive to receiving the request, receiving a confirmation indicator …” and “wherein the first user identifier and the second user identifier are authorized to interact with the collaborative document”. Specifically, Padmanabhan teaches at least a system and method for implementing document interface and collaboration using a blockchain-based distributed ledger. Users associated with identifiers request to make contributions to shared documents and/or portions thereof, and responsive to receiving such requests, additional collaborating users confirm or deny the requests based on the requesting user’s input info (including identifier) and signature. The input info for transactions to the distributed ledger also includes information indicating an intended set of collaborators/contributors to a document (Padmanabhan – at least Figure 5 and Paragraph [0147]-[0159]). Further, Bleikertz teaches “a request authorization … that qualifies the candidate transaction as an authorized candidate transaction for the distributed ledger.” As highlighted below, Bleikertz teaches a method for committing transactions to a distributed ledger for a multiple-participant process. Each transaction is submitted as a request for confirmation which is responded to with at least one confirmation response which must occur before a confirmation deadline. Timestamps indicating these events and requirements are referenced in order to determine the validity of a given transaction (Bleikertz – at least Figure 9 and Paragraph [0184]; [0495]-[0510]; [0571]).
Claim Objections
Claims 1, 14, and 27 are objected to because of the following informalities:
Each of independent claims 1, 14, and 27 includes the amended limitation “wherein the first user identifier and the second user identifier are authorized to interact with the collaborative document”. It is unclear how the identifiers are to be interpreted as interacting with the collaborative document. Therefore, the claim could be re-written as “wherein a first user associated with the first user identifier and a second user associated with the second user identifier are authorized to interact with the collaborative document” or the like, in order to clarify the capabilities and purpose of the identifiers.
Appropriate correction is required.
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.
Claim(s) 1, 8, 13, 14, 21, 26, 27, 34, 39, and 40-42 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan (US 20190236598 A1), hereinafter Padmanabhan, in view of Diriye et al. (US 20200118131 A1), hereinafter Diriye, Bleikertz et al. (US 20200128022 A1), hereinafter Bleikertz, and Chalakudi et al. (US 20190114182 A1), hereinafter Chalakudi.
Regarding Claim 1:
Padmanabhan teaches an apparatus comprising one or more processors (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions) and one or more storage devices (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions) storing instructions that are operable, when executed by the one or more processors, to cause the one or more processors to (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions) receive a request associated with a first user identifier to commit a candidate transaction associated with at least a portion of a collaborative document (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator (e.g., an email address or a user login identifier); identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; … or a transaction regarding the document or the portion thereof (e.g., the first collaborator requests creating, modifying, or deleting the document, or creating, modifying, or deleting a portion thereof in the document); and Paragraph [0150]: the host creates a blockchain transaction that includes the blockchain asset and a blockchain asset identifier. In one embodiment, the blockchain asset identifier is associated with a user—a collaborator—that actually signed the collaborative document. In one embodiment, the host associates the blockchain asset identifier with information about the user obtained from the collaborative document system or cloud computing environment with which the user interacts. For example, the user may have a login, or particular cryptographic key or security information that identifies the user in the cloud computing environment and/or the collaborative document processing system) to a distributed ledger (Padmanabhan – Paragraph [0148]: a document collaboration system that makes use of a blockchain-based distributed ledger to provide for decentralized, replicated storage of shared documents or content, thereby improving the auditability and immutability of the documents; and Paragraph [0146]: and adding the new block to the blockchain, responsive to the validation of the request to add the new block to the blockchain) responsive to receiving the request, receive a confirmation indicator associated with a second user identifier to commit the candidate transaction associated with at least the portion of the collaborative document to the distributed ledger (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: … identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; and Paragraph [0151]: the receipt of validation of the blockchain transaction, in response to broadcasting the blockchain transaction into circulation on the blockchain involves receiving validation of the blockchain transaction from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document, as further described below. Thereafter, at logic block 530, the DLT host commits the validated blockchain transaction in a block to the blockchain; and Paragraph [0157]: receiving validation regarding the collaborative document from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document includes receiving validation regarding the collaborative document from the second collaborator via a user interface for the collaborative document processing application), wherein the first user identifier and the second user identifier are authorized to interact with the collaborative document (Padmanabhan – Paragraph [0149]: In one embodiment, the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator (e.g., an email address or a user login identifier); identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; a message to be exchanged between the first collaborator and the additional collaborator(s) (e.g., a comment or question about, or collaboration notes present alongside of, or version information for, a document); and Paragraph [0153]: According to another embodiment of method 500, the receiving of input regarding the collaborative document from the first collaborator includes receiving input regarding one or more of an identifier of the first collaborator, identification of one or more additional collaborators, a message to be exchanged between the first collaborator and the additional collaborator(s), all or a portion of the collaborative document, the first collaborator's signature of the collaborative document, and a transaction regarding all or the portion of the collaborative document {e.g., insert, modify, delete}; and Paragraph [0154]: According to another embodiment of method 500, receiving validation of the blockchain transaction, responsive to broadcasting the blockchain transaction into circulation on the blockchain includes receiving validation of the blockchain transaction from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document); generate a candidate transaction data structure for the candidate transaction in accordance with one or more candidate transaction attributes of the candidate transaction (Padmanabhan – Paragraph [0044]: according to a particular embodiment, distributed ledger technology contemplates a distributed ledger technology host, or a blockchain platform host, in a peer-to-peer network, the host having at least a processor and a memory therein, receiving a request to add a new block to a blockchain, the new block comprising a plurality of transactions, the request specifying one of a plurality of transaction types. The host selects one of a plurality of consensus protocols for validating the request to add the new block to the blockchain, responsive to the specified transaction type. The host then validates the request to add the new block to the blockchain when consensus is reached according to the selected consensus protocol. Finally, the host adds the new block of the blockchain, responsive to the validation of the request to add the new block to the blockchain); [and cause execution of a smart contract of the distributed ledger] to add the candidate transaction data structure to the distributed ledger in accordance with a distributed ledger consensus protocol (Padmanabhan – Paragraph [0123]: At logic block 215, the host validates, or receives validation of, the request to add the new block or transaction therein to the blockchain when the nodes in the consortium reach consensus according to the selected consensus protocol to add the block or transaction therein to the blockchain and communicate such to the host).
Padmanabhan does not expressly teach and cause execution of a smart contract of the distributed ledger to add the candidate transaction data structure to the distributed ledger; based on a comparison between the one or more candidate transaction attributes and smart contract rules for the smart contract, wherein adding the candidate transaction data structure to the distributed ledger renders at least the portion of the collaborative document associated with the candidate transaction immutable.
However, Diriye teaches and cause execution of a smart contract of the distributed ledger to add the candidate transaction data structure to the distributed ledger (Diriye – Paragraph [0064]: The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chaincode with conditions or other code elements subject to its execution; and Paragraph [0065]: The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger; and Paragraph [0082]: In the event of an endorsed transaction 437, the asset provider nodes/peers 440 execute the transaction 445, and approves the asset transfer to the requestor 450. The results of the executed transaction 445 are included in a new block 458 that is committed to the blockchain) in accordance with a distributed ledger consensus protocol (Diriye – Paragraph [0027]: After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks) based on a comparison between the one or more candidate transaction attributes and smart contract rules for the smart contract (Diriye – Paragraph [0078]: The risk assessment node or peer 430 then verifies validity of the transaction against the selected smart contract 435. The parameters in the blockchain transaction 416 are compared to rules contained within the identified smart contract, and a risk score is calculated; and Paragraph [0082]: In the event of an endorsed transaction 437, the asset provider nodes/peers 440 execute the transaction 445, and approves the asset transfer to the requestor 450. The results of the executed transaction 445 are included in a new block 458 that is committed to the blockchain) wherein adding the candidate transaction data structure to the distributed ledger renders at least the portion of the collaborative document associated with the candidate transaction immutable (Diriye – Paragraph [0104]: The distributed ledger 730 includes a blockchain 732 which stores immutable, sequenced records in blocks, and a state database 734 (current world state) maintaining a current state of the blockchain 732).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, further incorporating Diriye to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Diriye’s teachings to commit transactions to a blockchain only when smart contract rules have been satisfied into Padmanabhan’s system for receiving and validating requests to commit transactions to a distributed ledger. This combined functionality would further enhance transaction verification techniques within the system.
The combination of Padmanabhan and Diriye does not expressly teach initiate a request authorization comparison with respect to (i) [a first timestamp associated with] the request and (ii) [a second timestamp associated with] the confirmation indicator to determine whether the request and the confirmation indicator to enable committing the candidate transaction to the distributed ledger, wherein the second timestamp is determined in response to receiving the confirmation indicator; and responsive to a determination, based on the request authorization comparison, that (i) [the first timestamp associated with] the request and (ii) [the second timestamp associated with] the confirmation indicator are within a defined time interval.
However, Bleikertz teaches initiate a request authorization comparison with respect to (i) [a first timestamp associated with] the request and (ii) [a second timestamp associated with] the confirmation indicator to determine whether the request and the confirmation indicator to enable committing the candidate transaction to the distributed ledger (Bleikertz – Figure 9: illustration of various deadlines associated with processing a transaction; and Paragraph [0497]: 2. The confirmation deadline 845, 846, which determines the time when participants 811, 819 must have sent their confirmation responses 851, 852 to the local message broker 817, 813; and Paragraph [0506]: Confirmation deadline 845, 846 =decision time 848, 847-confirmation deadline offset 915, 917; and Paragraph [0509]: The submitter (submitting node) 815 should pick the confirmation deadline offset 915, 917 such that every relay has enough time to forward 853, 854 the confirmation responses in the time between the confirmation deadline 845, 846 of the source domain and the decision time 847, 848 of the target domain of the forwarding (for all combinations of source and target domain). However, the offset 915, 917 must be small enough such that every participant on every domain has enough time to check 951 for conflicts between when it observes the logical timestamp from the domain and when it must send out the confirmation response such that it arrives before the confirmation deadline 845, 846 at the broker 813, 817; and Paragraph [0571]: In some examples, the confirmation responses 851, 852 must be sent by the local confirmation deadline 845, 846. Responses from other domains need only arrive by the decision time 847, 848. These two time-stamps represent the end of the two phases in a two-phase-commit protocol: All participants must send prepare to commit to the submitter by the confirmation deadline and they can expect the commit or abort by the decision time 847, 848); and responsive to a determination, based on the request authorization comparison, that (i) [the first timestamp associated with] the request and (ii) [the second timestamp associated with] the confirmation indicator are within a defined time interval that qualifies the candidate transaction as an authorized candidate transaction for the distributed ledger (Bleikertz – Figure 9: illustration of various deadlines associated with processing a transaction; and Paragraph [0184]: Allowing the submitting node 210 to provide the logical time offset may, to some extent, allow the submitting node 210 to control a confirmation response deadline by which the recipient nodes 220, 222 must send a confirmation for a proposed transaction 240, and/or somewhat control the ordering of the proposed transaction 240 relative to other transactions. For instance, in an example, the system of the disclosure can provide a confirmation response deadline by which a relevant recipient node 220, 222 must send a confirmation of a proposed transaction 240 for it to be confirmed and entered into the ledger. The confirmation response deadline can be calculated with reference to the logical timestamp. For instance, the confirmation response deadline may be calculated by adding some preset time period to the proposed transaction 240′s logical timestamp); … add the candidate transaction data structure to the distributed ledger in accordance with a distributed ledger consensus protocol (Bleikertz – Paragraphs [0404]-[0406]: The confirmers send their responses 1061, 1062, 1063, 1064 to a mediator 1020, another special entity that aggregates the responses into a single decision for the entire confirmation request … From this, the mediator 1020 derives which (positive) confirmation responses 1061, 1062, 1063, 1064 are necessary in order to decide the confirmation request as approved … Under the confirmation policy's trust assumptions, the protocol ensures that the local decisions of honest participants match for all views that they jointly see. The protocol thus provides a virtual shared ledger between the participants, whose transactions consist of such valid views. Once approved, the accepted views are final, i.e., they will never be removed from the participants' records or the virtual ledger).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan and Diriye, further incorporating Bleikertz to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bleikertz’s implementation of request-confirmation time limits for each individual proposed blockchain transaction into Padmanabhan and Diriye’s combined system for receiving and validating requests to commit transactions to a distributed ledger. This addition would bolster the security of the system by ensuring that every transaction was processed within an acceptable amount of time, and incorporating that time evaluation into the conditions for committing each transaction to the ledger.
The combination of Padmanabhan, Diriye, and Bleikertz does not expressly teach a/the first timestamp associated with the request; a/the second timestamp associated with the confirmation indicator; wherein the second timestamp is determined in response to receiving the confirmation indicator.
However, Chalakudi teaches a/the first timestamp associated with the request; a/the second timestamp associated with the confirmation indicator (Chalakudi – Paragraph [0006]: In various embodiments, the request confirmation may comprise a first timestamp, the request acknowledgement comprises a second timestamp, the response confirmation comprises a third timestamp, and the response acknowledgement comprises a fourth timestamp; and Paragraph [0032]: Blockchain 108 may make the comparisons using smart contract 110 … The result of the comparisons may be written to blockchain 108 in response to execution of smart contract 110 that executes the comparisons. Monitoring device 112 may read blockchain 108 to determine whether the API request and/or API response was completed with an error. For example, an error may be detected in response to not receiving a request acknowledgement from service provider system 104 within a predetermined duration window from the request confirmation being transmitted by service consumer system 106. The predetermined duration may be measured from the timestamp included in the request confirmation, request acknowledgement, response confirmation, and/or response acknowledgment. The timestamp may be retrieved, for example, using a web API); wherein the second timestamp is determined in response to receiving the confirmation indicator (Chalakudi – Paragraph [0006]: In various embodiments, the request confirmation may comprise a first timestamp, the request acknowledgement comprises a second timestamp, the response confirmation comprises a third timestamp, and the response acknowledgement comprises a fourth timestamp).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, and Bleikertz, further incorporating Chalakudi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chalakudi’s explicit teaching of associating timestamps with transaction requests and confirmations into Padmanabhan, Diriye, and Bleikertz’s combined system for receiving and validating requests to commit transactions to a distributed ledger. This function, particularly in combination with the teachings of Bleikertz, provides transaction request and confirmation timestamps useful in determining the validity of the transactions.
Regarding Claim 8:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the one or more storage devices store instructions that are operable, when executed by the one or more processors, to further cause the one or more processors to (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions).
Diriye further teaches modify one or more smart contract rules of the smart contract rules (Diriye – Paragraph [0090]: the shared ledger and/or smart contract is updated to reflect an approved transaction, a declined transaction, a modified transaction, or modified rules in the smart contract) based on a first authorization associated with the first user identifier and a second authorization associated with the second user identifier (Diriye – Paragraph [0099]: Content of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 which are parties to the smart contract transaction).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, further incorporating Diriye to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Diriye’s teachings to enable authorized users to modify smart contract rules into Padmanabhan’s system for receiving and processing requests to make blockchain transactions. This combination would provide the system with additional flexibility and security by allowing only authorized users to modify the smart contracts between them.
Regarding Claim 13:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the one or more storage devices store instructions that are operable, when executed by the one or more processors, to further cause the one or more processors to (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions): receive the request from the first user identifier (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator … or a transaction regarding the document or the portion thereof (e.g., the first collaborator requests creating, modifying, or deleting the document, or creating, modifying, or deleting a portion thereof in the document)) via a user interface of a first client device associated with the first user identifier (Padmanabhan – Paragraph [0058]: Further depicted is the host organization 110 receiving input and other requests 115 from customer organizations 105A-C via network 155 (such as a public Internet). For example, incoming search queries, database queries, API requests, interactions with displayed graphical user interfaces and displays at the user client devices 106A-C, or other inputs may be received from the customer organizations 105A-C to be processed against the database system 130, or such queries may be constructed from the inputs and other requests 115 for execution against the databases 155 or the query interface 180, pursuant to which results 116 are then returned to an originator or requestor, such as a user of one of a user client device 106A-C at a customer organization 105A-C).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 14:
Padmanabhan teaches a computer-implemented method, comprising (Padmanabhan – Paragraph [0043]: Described herein are systems, methods, and apparatuses for implementing distributed ledger technology): receiving a request associated with a first user identifier to commit a candidate transaction associated with at least a portion of a collaborative document (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator (e.g., an email address or a user login identifier); identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; … or a transaction regarding the document or the portion thereof (e.g., the first collaborator requests creating, modifying, or deleting the document, or creating, modifying, or deleting a portion thereof in the document); and Paragraph [0150]: the host creates a blockchain transaction that includes the blockchain asset and a blockchain asset identifier. In one embodiment, the blockchain asset identifier is associated with a user—a collaborator—that actually signed the collaborative document. In one embodiment, the host associates the blockchain asset identifier with information about the user obtained from the collaborative document system or cloud computing environment with which the user interacts. For example, the user may have a login, or particular cryptographic key or security information that identifies the user in the cloud computing environment and/or the collaborative document processing system) to a distributed ledger (Padmanabhan – Paragraph [0148]: a document collaboration system that makes use of a blockchain-based distributed ledger to provide for decentralized, replicated storage of shared documents or content, thereby improving the auditability and immutability of the documents; and Paragraph [0146]: and adding the new block to the blockchain, responsive to the validation of the request to add the new block to the blockchain), responsive to receiving the request, receiving a confirmation indicator associated with a second user identifier to commit the candidate transaction associated with at least the portion of the collaborative document to the distributed ledger (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: … identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; and Paragraph [0151]: the receipt of validation of the blockchain transaction, in response to broadcasting the blockchain transaction into circulation on the blockchain involves receiving validation of the blockchain transaction from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document, as further described below. Thereafter, at logic block 530, the DLT host commits the validated blockchain transaction in a block to the blockchain; and Paragraph [0157]: receiving validation regarding the collaborative document from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document includes receiving validation regarding the collaborative document from the second collaborator via a user interface for the collaborative document processing application), wherein the first user identifier and the second user identifier are authorized to interact with the collaborative document (Padmanabhan – Paragraph [0149]: In one embodiment, the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator (e.g., an email address or a user login identifier); identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; a message to be exchanged between the first collaborator and the additional collaborator(s) (e.g., a comment or question about, or collaboration notes present alongside of, or version information for, a document); and Paragraph [0153]: According to another embodiment of method 500, the receiving of input regarding the collaborative document from the first collaborator includes receiving input regarding one or more of an identifier of the first collaborator, identification of one or more additional collaborators, a message to be exchanged between the first collaborator and the additional collaborator(s), all or a portion of the collaborative document, the first collaborator's signature of the collaborative document, and a transaction regarding all or the portion of the collaborative document {e.g., insert, modify, delete}; and Paragraph [0154]: According to another embodiment of method 500, receiving validation of the blockchain transaction, responsive to broadcasting the blockchain transaction into circulation on the blockchain includes receiving validation of the blockchain transaction from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document); generating a candidate transaction data structure for the candidate transaction in accordance with one or more candidate transaction attributes of the candidate transaction (Padmanabhan – Paragraph [0044]: according to a particular embodiment, distributed ledger technology contemplates a distributed ledger technology host, or a blockchain platform host, in a peer-to-peer network, the host having at least a processor and a memory therein, receiving a request to add a new block to a blockchain, the new block comprising a plurality of transactions, the request specifying one of a plurality of transaction types. The host selects one of a plurality of consensus protocols for validating the request to add the new block to the blockchain, responsive to the specified transaction type. The host then validates the request to add the new block to the blockchain when consensus is reached according to the selected consensus protocol. Finally, the host adds the new block of the blockchain, responsive to the validation of the request to add the new block to the blockchain); [and causing execution of a smart contract of the distributed ledger] to add the candidate transaction data structure to the distributed ledger in accordance with a distributed ledger consensus protocol (Padmanabhan – Paragraph [0123]: At logic block 215, the host validates, or receives validation of, the request to add the new block or transaction therein to the blockchain when the nodes in the consortium reach consensus according to the selected consensus protocol to add the block or transaction therein to the blockchain and communicate such to the host).
Padmanabhan does not expressly teach and causing execution of a smart contract of the distributed ledger to add the candidate transaction data structure to the distributed ledger; based on a comparison between the one or more candidate transaction attributes and smart contract rules for the smart contract, wherein adding the candidate transaction data structure to the distributed ledger renders at least the portion of the collaborative document associated with the candidate transaction immutable.
However, Diriye teaches and causing execution of a smart contract of the distributed ledger to add the candidate transaction data structure to the distributed ledger (Diriye – Paragraph [0064]: The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chaincode with conditions or other code elements subject to its execution; and Paragraph [0065]: The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger; and Paragraph [0082]: In the event of an endorsed transaction 437, the asset provider nodes/peers 440 execute the transaction 445, and approves the asset transfer to the requestor 450. The results of the executed transaction 445 are included in a new block 458 that is committed to the blockchain) in accordance with a distributed ledger consensus protocol (Diriye – Paragraph [0027]: After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks) based on a comparison between the one or more candidate transaction attributes and smart contract rules for the smart contract (Diriye – Paragraph [0078]: The risk assessment node or peer 430 then verifies validity of the transaction against the selected smart contract 435. The parameters in the blockchain transaction 416 are compared to rules contained within the identified smart contract, and a risk score is calculated; and Paragraph [0082]: In the event of an endorsed transaction 437, the asset provider nodes/peers 440 execute the transaction 445, and approves the asset transfer to the requestor 450. The results of the executed transaction 445 are included in a new block 458 that is committed to the blockchain) wherein adding the candidate transaction data structure to the distributed ledger renders at least the portion of the collaborative document associated with the candidate transaction immutable (Diriye – Paragraph [0104]: The distributed ledger 730 includes a blockchain 732 which stores immutable, sequenced records in blocks, and a state database 734 (current world state) maintaining a current state of the blockchain 732).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, further incorporating Diriye to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Diriye’s teachings to commit transactions to a blockchain only when smart contract rules have been satisfied into Padmanabhan’s system for receiving and validating requests to commit transactions to a distributed ledger. This combined functionality would further enhance transaction verification techniques within the system.
The combination of Padmanabhan and Diriye does not expressly teach initiating a request authorization comparison with respect to (i) [a first timestamp associated with] the request and (ii) [a second timestamp associated with] the confirmation indicator to determine whether the request and the confirmation indicator enable committing the candidate transaction to the distributed ledger, wherein the second timestamp is determined in response to receiving the confirmation indicator; and responsive to a determination, based on the request authorization comparison, that (i) [the first timestamp associated with] the request and (ii) [the second timestamp associated with] the confirmation indicator are within a defined time interval that qualifies the candidate transaction as an authorized candidate transaction for the distributed ledger.
However, Bleikertz teaches initiating a request authorization comparison with respect to (i) [a first timestamp associated with] the request and (ii) [a second timestamp associated with] the confirmation indicator to determine whether the request and the confirmation indicator enable committing the candidate transaction to the distributed ledger (Bleikertz – Figure 9: illustration of various deadlines associated with processing a transaction; and Paragraph [0497]: 2. The confirmation deadline 845, 846, which determines the time when participants 811, 819 must have sent their confirmation responses 851, 852 to the local message broker 817, 813; and Paragraph [0506]: Confirmation deadline 845, 846 =decision time 848, 847-confirmation deadline offset 915, 917; and Paragraph [0509]: The submitter (submitting node) 815 should pick the confirmation deadline offset 915, 917 such that every relay has enough time to forward 853, 854 the confirmation responses in the time between the confirmation deadline 845, 846 of the source domain and the decision time 847, 848 of the target domain of the forwarding (for all combinations of source and target domain). However, the offset 915, 917 must be small enough such that every participant on every domain has enough time to check 951 for conflicts between when it observes the logical timestamp from the domain and when it must send out the confirmation response such that it arrives before the confirmation deadline 845, 846 at the broker 813, 817; and Paragraph [0571]: In some examples, the confirmation responses 851, 852 must be sent by the local confirmation deadline 845, 846. Responses from other domains need only arrive by the decision time 847, 848. These two time-stamps represent the end of the two phases in a two-phase-commit protocol: All participants must send prepare to commit to the submitter by the confirmation deadline and they can expect the commit or abort by the decision time 847, 848); and responsive to a determination, based on the request authorization comparison, that (i) [the first timestamp associated with] the request and (ii) [the second timestamp associated with] the confirmation indicator are within a defined time interval that qualifies the candidate transaction as an authorized candidate transaction for the distributed ledger (Bleikertz – Figure 9: illustration of various deadlines associated with processing a transaction; and Paragraph [0184]: Allowing the submitting node 210 to provide the logical time offset may, to some extent, allow the submitting node 210 to control a confirmation response deadline by which the recipient nodes 220, 222 must send a confirmation for a proposed transaction 240, and/or somewhat control the ordering of the proposed transaction 240 relative to other transactions. For instance, in an example, the system of the disclosure can provide a confirmation response deadline by which a relevant recipient node 220, 222 must send a confirmation of a proposed transaction 240 for it to be confirmed and entered into the ledger. The confirmation response deadline can be calculated with reference to the logical timestamp. For instance, the confirmation response deadline may be calculated by adding some preset time period to the proposed transaction 240′s logical timestamp); … add the candidate transaction data structure to the distributed ledger in accordance with a distributed ledger consensus protocol (Bleikertz – Paragraphs [0404]-[0406]: The confirmers send their responses 1061, 1062, 1063, 1064 to a mediator 1020, another special entity that aggregates the responses into a single decision for the entire confirmation request … From this, the mediator 1020 derives which (positive) confirmation responses 1061, 1062, 1063, 1064 are necessary in order to decide the confirmation request as approved … Under the confirmation policy's trust assumptions, the protocol ensures that the local decisions of honest participants match for all views that they jointly see. The protocol thus provides a virtual shared ledger between the participants, whose transactions consist of such valid views. Once approved, the accepted views are final, i.e., they will never be removed from the participants' records or the virtual ledger).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan and Diriye, further incorporating Bleikertz to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bleikertz’s implementation of request-confirmation time limits for each individual proposed blockchain transaction into Padmanabhan and Diriye’s combined system for receiving and validating requests to commit transactions to a distributed ledger. This addition would bolster the security of the system by ensuring that every transaction was processed within an acceptable amount of time, and incorporating that time evaluation into the conditions for committing each transaction to the ledger.
The combination of Padmanabhan, Diriye, and Bleikertz does not expressly teach a/the first timestamp associated with the request; a/the second timestamp associated with the confirmation indicator; wherein the second timestamp is determined in response to receiving the confirmation indicator.
However, Chalakudi teaches a/the first timestamp associated with the request; a/the second timestamp associated with the confirmation indicator (Chalakudi – Paragraph [0006]: In various embodiments, the request confirmation may comprise a first timestamp, the request acknowledgement comprises a second timestamp, the response confirmation comprises a third timestamp, and the response acknowledgement comprises a fourth timestamp; and Paragraph [0032]: Blockchain 108 may make the comparisons using smart contract 110 … The result of the comparisons may be written to blockchain 108 in response to execution of smart contract 110 that executes the comparisons. Monitoring device 112 may read blockchain 108 to determine whether the API request and/or API response was completed with an error. For example, an error may be detected in response to not receiving a request acknowledgement from service provider system 104 within a predetermined duration window from the request confirmation being transmitted by service consumer system 106. The predetermined duration may be measured from the timestamp included in the request confirmation, request acknowledgement, response confirmation, and/or response acknowledgment. The timestamp may be retrieved, for example, using a web API); wherein the second timestamp is determined in response to receiving the confirmation indicator (Chalakudi – Paragraph [0006]: In various embodiments, the request confirmation may comprise a first timestamp, the request acknowledgement comprises a second timestamp, the response confirmation comprises a third timestamp, and the response acknowledgement comprises a fourth timestamp).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, and Bleikertz, further incorporating Chalakudi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chalakudi’s explicit teaching of associating timestamps with transaction requests and confirmations into Padmanabhan, Diriye, and Bleikertz’s combined system for receiving and validating requests to commit transactions to a distributed ledger. This function, particularly in combination with the teachings of Bleikertz, provide transaction request and confirmation timestamps useful in determining the validity of the transactions.
Regarding Claim 21:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 21 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 8. Therefore, claim 21 is rejected with the same rationale and motivation as applied against claim 8 above.
Regarding Claim 26:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 26 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 13. Therefore, claim 26 is rejected with the same rationale and motivation as applied against claim 13 above.
Regarding Claim 27:
Padmanabhan teaches a computer program product, stored on a non-transitory computer readable medium, comprising instructions that when executed by one or more computers cause the one or more computers to: (Padmanabhan – Paragraph [0059]: Embodiments may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the disclosed embodiments) receive a request associated with a first user identifier to commit a candidate transaction associated with at least a portion of a collaborative document (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator (e.g., an email address or a user login identifier); identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; … or a transaction regarding the document or the portion thereof (e.g., the first collaborator requests creating, modifying, or deleting the document, or creating, modifying, or deleting a portion thereof in the document); and Paragraph [0150]: the host creates a blockchain transaction that includes the blockchain asset and a blockchain asset identifier. In one embodiment, the blockchain asset identifier is associated with a user—a collaborator—that actually signed the collaborative document. In one embodiment, the host associates the blockchain asset identifier with information about the user obtained from the collaborative document system or cloud computing environment with which the user interacts. For example, the user may have a login, or particular cryptographic key or security information that identifies the user in the cloud computing environment and/or the collaborative document processing system) to a distributed ledger (Padmanabhan – Paragraph [0148]: a document collaboration system that makes use of a blockchain-based distributed ledger to provide for decentralized, replicated storage of shared documents or content, thereby improving the auditability and immutability of the documents; and Paragraph [0146]: and adding the new block to the blockchain, responsive to the validation of the request to add the new block to the blockchain), responsive to receiving the request, receive a confirmation indicator associated with a second user identifier to commit the candidate transaction associated with at least the portion of the collaborative document to the distributed ledger (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: … identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; and Paragraph [0151]: the receipt of validation of the blockchain transaction, in response to broadcasting the blockchain transaction into circulation on the blockchain involves receiving validation of the blockchain transaction from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document, as further described below. Thereafter, at logic block 530, the DLT host commits the validated blockchain transaction in a block to the blockchain; and Paragraph [0157]: receiving validation regarding the collaborative document from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document includes receiving validation regarding the collaborative document from the second collaborator via a user interface for the collaborative document processing application), wherein the first user identifier and the second user identifier are authorized to interact with the collaborative document (Padmanabhan – Paragraph [0149]: In one embodiment, the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator (e.g., an email address or a user login identifier); identification of one or more additional collaborators with which the first collaborator is or intends to collaborate with; a message to be exchanged between the first collaborator and the additional collaborator(s) (e.g., a comment or question about, or collaboration notes present alongside of, or version information for, a document); and Paragraph [0153]: According to another embodiment of method 500, the receiving of input regarding the collaborative document from the first collaborator includes receiving input regarding one or more of an identifier of the first collaborator, identification of one or more additional collaborators, a message to be exchanged between the first collaborator and the additional collaborator(s), all or a portion of the collaborative document, the first collaborator's signature of the collaborative document, and a transaction regarding all or the portion of the collaborative document {e.g., insert, modify, delete}; and Paragraph [0154]: According to another embodiment of method 500, receiving validation of the blockchain transaction, responsive to broadcasting the blockchain transaction into circulation on the blockchain includes receiving validation of the blockchain transaction from a second collaborator on the collaborative document that verified the first collaborator's signature of the collaborative document); generate a candidate transaction data structure for the candidate transaction in accordance with one or more candidate transaction attributes of the candidate transaction (Padmanabhan – Paragraph [0044]: according to a particular embodiment, distributed ledger technology contemplates a distributed ledger technology host, or a blockchain platform host, in a peer-to-peer network, the host having at least a processor and a memory therein, receiving a request to add a new block to a blockchain, the new block comprising a plurality of transactions, the request specifying one of a plurality of transaction types. The host selects one of a plurality of consensus protocols for validating the request to add the new block to the blockchain, responsive to the specified transaction type. The host then validates the request to add the new block to the blockchain when consensus is reached according to the selected consensus protocol. Finally, the host adds the new block of the blockchain, responsive to the validation of the request to add the new block to the blockchain); [and cause execution of a smart contract of the distributed ledger] to add the candidate transaction data structure to the distributed ledger in accordance with a distributed ledger consensus protocol (Padmanabhan – Paragraph [0123]: At logic block 215, the host validates, or receives validation of, the request to add the new block or transaction therein to the blockchain when the nodes in the consortium reach consensus according to the selected consensus protocol to add the block or transaction therein to the blockchain and communicate such to the host).
Padmanabhan does not expressly teach and cause execution of a smart contract of the distributed ledger to add the candidate transaction data structure to the distributed ledger; based on a comparison between the one or more candidate transaction attributes and smart contract rules for the smart contract, wherein adding the candidate transaction data structure to the distributed ledger renders at least the portion of the collaborative document associated with the candidate transaction immutable.
However, Diriye teaches and cause execution of a smart contract of the distributed ledger to add the candidate transaction data structure to the distributed ledger (Diriye – Paragraph [0064]: The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chaincode with conditions or other code elements subject to its execution; and Paragraph [0065]: The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger; and Paragraph [0082]: In the event of an endorsed transaction 437, the asset provider nodes/peers 440 execute the transaction 445, and approves the asset transfer to the requestor 450. The results of the executed transaction 445 are included in a new block 458 that is committed to the blockchain) in accordance with a distributed ledger consensus protocol (Diriye – Paragraph [0027]: After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks) based on a comparison between the one or more candidate transaction attributes and smart contract rules for the smart contract (Diriye – Paragraph [0078]: The risk assessment node or peer 430 then verifies validity of the transaction against the selected smart contract 435. The parameters in the blockchain transaction 416 are compared to rules contained within the identified smart contract, and a risk score is calculated; and Paragraph [0082]: In the event of an endorsed transaction 437, the asset provider nodes/peers 440 execute the transaction 445, and approves the asset transfer to the requestor 450. The results of the executed transaction 445 are included in a new block 458 that is committed to the blockchain) wherein adding the candidate transaction data structure to the distributed ledger renders at least the portion of the collaborative document associated with the candidate transaction immutable (Diriye – Paragraph [0104]: The distributed ledger 730 includes a blockchain 732 which stores immutable, sequenced records in blocks, and a state database 734 (current world state) maintaining a current state of the blockchain 732).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, further incorporating Diriye to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Diriye’s teachings to commit transactions to a blockchain only when smart contract rules have been satisfied into Padmanabhan’s system for receiving and validating requests to commit transactions to a distributed ledger. This combined functionality would further enhance transaction verification techniques within the system.
The combination of Padmanabhan and Diriye does not expressly teach initiate a request authorization comparison with respect to (i) [a first timestamp associated with] the request and (ii) [a second timestamp associated with] the confirmation indicator to determine whether the request and the confirmation indicator enable committing the candidate transaction to the distributed ledger, wherein the second timestamp is determined in response to receiving the confirmation indicator; and responsive to a determination, based on the request authorization comparison, that (i) [the first timestamp associated with] the request and (ii) [the second timestamp associated with] the confirmation indicator are within a defined time interval that qualifies the candidate transaction as an authorized candidate transaction for the distributed ledger.
However, Bleikertz teaches initiate a request authorization comparison with respect to (i) [a first timestamp associated with] the request and (ii) [a second timestamp associated with] the confirmation indicator to determine whether the request and the confirmation indicator enable committing the candidate transaction to the distributed ledger (Bleikertz – Figure 9: illustration of various deadlines associated with processing a transaction; and Paragraph [0497]: 2. The confirmation deadline 845, 846, which determines the time when participants 811, 819 must have sent their confirmation responses 851, 852 to the local message broker 817, 813; and Paragraph [0506]: Confirmation deadline 845, 846 =decision time 848, 847-confirmation deadline offset 915, 917; and Paragraph [0509]: The submitter (submitting node) 815 should pick the confirmation deadline offset 915, 917 such that every relay has enough time to forward 853, 854 the confirmation responses in the time between the confirmation deadline 845, 846 of the source domain and the decision time 847, 848 of the target domain of the forwarding (for all combinations of source and target domain). However, the offset 915, 917 must be small enough such that every participant on every domain has enough time to check 951 for conflicts between when it observes the logical timestamp from the domain and when it must send out the confirmation response such that it arrives before the confirmation deadline 845, 846 at the broker 813, 817; and Paragraph [0571]: In some examples, the confirmation responses 851, 852 must be sent by the local confirmation deadline 845, 846. Responses from other domains need only arrive by the decision time 847, 848. These two time-stamps represent the end of the two phases in a two-phase-commit protocol: All participants must send prepare to commit to the submitter by the confirmation deadline and they can expect the commit or abort by the decision time 847, 848); and responsive to a determination, based on the request authorization comparison, that (i) [the first timestamp associated with] the request and (ii) [the second timestamp associated with] the confirmation indicator are within a defined time interval that qualifies the candidate transaction as an authorized candidate transaction for the distributed ledger (Bleikertz – Figure 9: illustration of various deadlines associated with processing a transaction; and Paragraph [0184]: Allowing the submitting node 210 to provide the logical time offset may, to some extent, allow the submitting node 210 to control a confirmation response deadline by which the recipient nodes 220, 222 must send a confirmation for a proposed transaction 240, and/or somewhat control the ordering of the proposed transaction 240 relative to other transactions. For instance, in an example, the system of the disclosure can provide a confirmation response deadline by which a relevant recipient node 220, 222 must send a confirmation of a proposed transaction 240 for it to be confirmed and entered into the ledger. The confirmation response deadline can be calculated with reference to the logical timestamp. For instance, the confirmation response deadline may be calculated by adding some preset time period to the proposed transaction 240′s logical timestamp); … add the candidate transaction data structure to the distributed ledger in accordance with a distributed ledger consensus protocol (Bleikertz – Paragraphs [0404]-[0406]: The confirmers send their responses 1061, 1062, 1063, 1064 to a mediator 1020, another special entity that aggregates the responses into a single decision for the entire confirmation request … From this, the mediator 1020 derives which (positive) confirmation responses 1061, 1062, 1063, 1064 are necessary in order to decide the confirmation request as approved … Under the confirmation policy's trust assumptions, the protocol ensures that the local decisions of honest participants match for all views that they jointly see. The protocol thus provides a virtual shared ledger between the participants, whose transactions consist of such valid views. Once approved, the accepted views are final, i.e., they will never be removed from the participants' records or the virtual ledger).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan and Diriye, further incorporating Bleikertz to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bleikertz’s implementation of request-confirmation time limits for each individual proposed blockchain transaction into Padmanabhan and Diriye’s combined system for receiving and validating requests to commit transactions to a distributed ledger. This addition would bolster the security of the system by ensuring that every transaction was processed within an acceptable amount of time, and incorporating that time evaluation into the conditions for committing each transaction to the ledger.
The combination of Padmanabhan, Diriye, and Bleikertz does not expressly teach a/the first timestamp associated with the request; a/the second timestamp associated with the confirmation indicator; wherein the second timestamp is determined in response to receiving the confirmation indicator.
However, Chalakudi teaches a/the first timestamp associated with the request; a/the second timestamp associated with the confirmation indicator (Chalakudi – Paragraph [0006]: In various embodiments, the request confirmation may comprise a first timestamp, the request acknowledgement comprises a second timestamp, the response confirmation comprises a third timestamp, and the response acknowledgement comprises a fourth timestamp; and Paragraph [0032]: Blockchain 108 may make the comparisons using smart contract 110 … The result of the comparisons may be written to blockchain 108 in response to execution of smart contract 110 that executes the comparisons. Monitoring device 112 may read blockchain 108 to determine whether the API request and/or API response was completed with an error. For example, an error may be detected in response to not receiving a request acknowledgement from service provider system 104 within a predetermined duration window from the request confirmation being transmitted by service consumer system 106. The predetermined duration may be measured from the timestamp included in the request confirmation, request acknowledgement, response confirmation, and/or response acknowledgment. The timestamp may be retrieved, for example, using a web API); wherein the second timestamp is determined in response to receiving the confirmation indicator (Chalakudi – Paragraph [0006]: In various embodiments, the request confirmation may comprise a first timestamp, the request acknowledgement comprises a second timestamp, the response confirmation comprises a third timestamp, and the response acknowledgement comprises a fourth timestamp).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, and Bleikertz, further incorporating Chalakudi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chalakudi’s explicit teaching of associating timestamps with transaction requests and confirmations into Padmanabhan, Diriye, and Bleikertz’s combined system for receiving and validating requests to commit transactions to a distributed ledger. This function, particularly in combination with the teachings of Bleikertz, provide transaction request and confirmation timestamps useful in determining the validity of the transactions.
Regarding Claim 34:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 34 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 8 and the method claim 21. Therefore, claim 34 is rejected with the same rationale and motivation as applied against claims 8 and 21 above.
Regarding Claim 39:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 39 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 13 and the method claim 26. Therefore, claim 39 is rejected with the same rationale and motivation as applied against claims 13 and 26 above.
Regarding Claim 40:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the smart contract rules comprise one or more rules for one or more predefined events (Padmanabhan – Paragraph [0254]: The GUI manager 1110 presents a flow designer GUI 1111 interface to a user device via which users may interact with the host organization. The smartflow contract engine 1105 in coordination with the GUI manager interprets the various rules, conditions, and operations provided by the user, to generate a smartflow contract which is then translated or written into the target blockchain protocol; and Paragraph [0255]: Through the flow designer GUI 1111, a user can completely define utilizing visual flow elements how a particular process, event, agreement, contract, purchase, or some other transaction needs to occur, including dependencies, checks, required process inputs and outputs, triggers, etc), with respect to components of an application framework (Padmanabhan – Paragraph [0254]: The smartflow contract engine 1105 in coordination with the GUI manager interprets the various rules, conditions, and operations provided by the user, to generate a smartflow contract which is then translated or written into the target blockchain protocol; Examiner’s Comment: the smart contract engine in coordination with the GUI manager is interpreted as the application framework), that qualify as an authorized data block for the distributed ledger (Padmanabhan – Paragraph [0254]: The smartflow contract engine 1105 in coordination with the GUI manager interprets the various rules, conditions, and operations provided by the user, to generate a smartflow contract which is then translated or written into the target blockchain protocol; Examiner’s Comment: the blockchain protocol is the set of rules/conditions which determine a data block to be authorized).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 41:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of claim 14.
In addition, Claim 41 is a method claim that recites limitations corresponding those of the apparatus Claim 40. Therefore, claim 41 is rejected with the same rationale and motivation as applied against claim 40 above.
Regarding Claim 42:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 42 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 40 and the method claim 41. Therefore, claim 42 is rejected with the same rationale and motivation as applied against claims 40 and 41 above.
Claim(s) 2, 3, 12, 15, 16, 25, 28, 29, and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan, in view of Diriye, Bleikertz, Chalakudi, and Gu et al. (US 20200409940 A1), hereinafter Gu.
Regarding Claim 2:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach wherein the portion of the collaborative document corresponds to text data, image data, video data, audio data, or a combination thereof.
However, Gu teaches wherein the portion of the collaborative document corresponds to text data, image data, video data, audio data, or a combination thereof (Gu – Paragraph [0020]: the workflow can be a joint or collaborative workflow among multiple participants, where each participant can be associated with a client device (e.g., a client device executing the client service logic) or a network node (e.g., a consensus or a non-consensus node that is capable of executing the smart contract) of a blockchain network; and Paragraph [0034]: While transactions are used herein by way of non-limiting example, it is contemplated that any appropriate data can be stored in a blockchain (e.g., documents, images, videos, audio)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Gu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Gu’s teachings of various types of documents that can be transacted upon in a blockchain into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make those transactions. This combination would enable system users to collaborate on many different types of documents.
Regarding Claim 3:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the portion of the collaborative document (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator … or a transaction regarding the document or the portion thereof (e.g., the first collaborator requests creating, modifying, or deleting the document, or creating, modifying, or deleting a portion thereof in the document); and via the collaborative document (Padmanabhan – Paragraph [0149]: the input regarding the collaborative document received from the first collaborator includes but is not limited to: information regarding one or more of an identifier of the first collaborator … or a transaction regarding the document or the portion thereof (e.g., the first collaborator requests creating, modifying, or deleting the document, or creating, modifying, or deleting a portion thereof in the document).
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach [wherein the portion of the collaborative document] corresponds to a set of executable instructions associated with a macro tool configured for execution [via the collaborative document].
However, Gu teaches [wherein the portion of the collaborative document] corresponds to a set of executable instructions associated with a macro tool configured for execution [via the collaborative document] (Gu – Paragraph [0059]: In some embodiments, the one or more client service logics can be configurable by the respective client devices ... In some embodiments, the one or more client service logics can include defined application interfaces between or among the client service logics, or between the client service logics and the blockchain network (e.g., via the smart contract), which can provide a uniform and consistent framework to facilitate interactions among all the participants of the workflow and the blockchain network as well as improving the compatibility, scalability, flexibility, and efficiency of the workflow system; and Paragraph [0064]: the workflow logics of the client devices 370 and 375 includes one or more application interfaces with the cloud server 304, for example, for requesting transactions to be executed on the blockchain network 302 or 352; and Paragraph [0119]: In some embodiments, participants of the multi-party collaborative workflow can define a respective portion of the workflow specification according to individual needs, individually implement the client service methods of the client service logic, and complete the framework of the workflow).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Gu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Gu’s teachings of a user-configurable, multi-user application for committing transactions to a blockchain into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make those transactions. This combination would further enable system users to make modifications to shared documents on a distributed ledger and to make modifications to the user-configurable application for committing those transactions, based on the transactions.
Regarding Claim 12:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the one or more storage devices store instructions that are operable, when executed by the one or more processors, to further cause the one or more processors to (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions).
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach receive the request from the first user identifier in response to a predefined event associated with a workflow for the collaborative document.
However, Gu teaches receive the request from the first user identifier in response to a predefined event associated with a workflow (Gu – Paragraph [0088]: The workflow specification can also specify a series of client service methods (e.g., client service methods 362a-c and 364a-c) to be performed by the client devices (e.g., the client device 370 or 375) participating the workflow; and Paragraph [0091]: the workflow specification specifies one or more states and events (e.g., a triggering state and a triggering event for a specified client service method) that are commonly defined between the state transition methods of the smart contract and the client service methods of the configurable client service logic. In some embodiments, at least one client service method of the one or more client service methods changes the one or more states in the smart contract. For example, as described with respect to FIG. 3, after execution of a client service method that leads to an updated state (e.g., a target state of a client service method), the configurable client service logic can include interfaces and logics to send a transaction request to upload or otherwise record the updated state on the blockchain and/or to trigger subsequent methods (e.g., either to be performed by the client service or other client services) specified in the workflow) for the collaborative document (Gu – Paragraph [0020]: the workflow can be a joint or collaborative workflow among multiple participants, where each participant can be associated with a client device (e.g., a client device executing the client service logic) or a network node (e.g., a consensus or a non-consensus node that is capable of executing the smart contract) of a blockchain network; and Paragraph [0034]: While transactions are used herein by way of non-limiting example, it is contemplated that any appropriate data can be stored in a blockchain (e.g., documents, images, videos, audio)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Gu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Gu’s teachings to establish triggering events of a workflow that cause transaction requests into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make blockchain transactions. This combination would provide the system with some automation based on contributions made to collaborative documents in the workflow.
Regarding Claim 15:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 15 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 2. Therefore, claim 15 is rejected with the same rationale and motivation as applied against claim 2 above.
Regarding Claim 16:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 16 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 3. Therefore, claim 16 is rejected with the same rationale and motivation as applied against claim 3 above.
Regarding Claim 25:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 25 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 12. Therefore, claim 25 is rejected with the same rationale and motivation as applied against claim 12 above.
Regarding Claim 28:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 28 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 2 and the method claim 15. Therefore, claim 28 is rejected with the same rationale and motivation as applied against claims 2 and 15 above.
Regarding Claim 29:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 29 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 3 and the method claim 16. Therefore, claim 29 is rejected with the same rationale and motivation as applied against claims 3 and 16 above.
Regarding Claim 38:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 38 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 12 and the method claim 25. Therefore, claim 38 is rejected with the same rationale and motivation as applied against claims 12 and 25 above.
Claim(s) 4, 17, and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan, Diriye, Bleikertz, Chalakudi, and Fisher et al. (US 20190356493 A1), hereinafter Fisher.
Regarding Claim 4:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the one or more storage devices store instructions that are operable, when executed by the one or more processors, to further cause the one or more processors to (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions): generate the candidate transaction data structure for the candidate transaction (Padmanabhan – Paragraph [0044]: according to a particular embodiment, distributed ledger technology contemplates a distributed ledger technology host, or a blockchain platform host, in a peer-to-peer network, the host having at least a processor and a memory therein, receiving a request to add a new block to a blockchain, the new block comprising a plurality of transactions, the request specifying one of a plurality of transaction types. The host selects one of a plurality of consensus protocols for validating the request to add the new block to the blockchain, responsive to the specified transaction type. The host then validates the request to add the new block to the blockchain when consensus is reached according to the selected consensus protocol. Finally, the host adds the new block of the blockchain, responsive to the validation of the request to add the new block to the blockchain).
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach based on collaborative document metadata associated with at least the portion of the collaborative document.
However, Fisher teaches based on collaborative document metadata associated with at least the portion of the collaborative document (Fisher – Paragraph [0066]: Each block 455 includes a plurality of identifiers 458 paired with respective exposed metadata 456. The identifiers 458 may be hash values generated from a respective smart document as discussed above. The exposed metadata 456 can include user specified schema including access control lists, rules, signatures, and various access levels for decrypting predetermined portions of a respective associated smart document based on user defined rules stored within the exposed metadata 456).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Fisher to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Fisher’s teachings of associating document metadata with newly generated data blocks into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make blockchain transactions. This combination would help the system to ensure the legitimacy of its collaborative documents and contributions thereto.
Regarding Claim 17:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 17 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 4. Therefore, claim 17 is rejected with the same rationale and motivation as applied against claim 4 above.
Regarding Claim 30:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 30 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 4 and the method claim 17. Therefore, claim 30 is rejected with the same rationale and motivation as applied against claims 4 and 17 above.
Claim(s) 5, 6, 18, 19, 31, and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan, in view of Diriye, Bleikertz, Chalakudi, and Saito (US 20210263908 A1), hereinafter Saito.
Regarding Claim 5:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach wherein the smart contract rules for the smart contract are configured by the first user identifier or the second user identifier.
However, Saito teaches wherein the smart contract rules for the smart contract are configured based on data associated with the first user identifier or the second user identifier (Saito – Paragraph [0095]: FIG. 6C illustrates an example system configured to utilize a smart contract configuration among contracting parties and a mediating server configured to enforce the smart contract terms on the blockchain according to example embodiments. Referring to FIG. 6C, the configuration 650 may represent a communication session, an asset transfer session or a process or procedure that is driven by a smart contract 630 which explicitly identifies one or more user devices 652 and/or 656. The execution, operations and results of the smart contract execution may be managed by a server 654. Content of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 which are parties to the smart contract transaction).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Saito to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Saito’s teachings of smart contract rules configured by one or both parties of the contract into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make blockchain transactions. This combination would enhance security during user collaboration by having at least one collaborating party attest to the smart contract rules.
Regarding Claim 6:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach wherein the smart contract rules for the smart contract are configured based on data associated with the first user identifier and the second user identifier.
However, Saito teaches wherein the smart contract rules for the smart contract are configured based on data associated with the first user identifier and the second user identifier (Saito – Paragraph [0095]: FIG. 6C illustrates an example system configured to utilize a smart contract configuration among contracting parties and a mediating server configured to enforce the smart contract terms on the blockchain according to example embodiments. Referring to FIG. 6C, the configuration 650 may represent a communication session, an asset transfer session or a process or procedure that is driven by a smart contract 630 which explicitly identifies one or more user devices 652 and/or 656. The execution, operations and results of the smart contract execution may be managed by a server 654. Content of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 which are parties to the smart contract transaction).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Saito to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Saito’s teachings of smart contract rules configured by both parties of the contract into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make blockchain transactions. This combination would enhance security during user collaboration by having both collaborating parties attest to the smart contract rules.
Regarding Claim 18:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 18 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 5. Therefore, claim 18 is rejected with the same rationale and motivation as applied against claim 5 above.
Regarding Claim 19:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 19 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 6. Therefore, claim 19 is rejected with the same rationale and motivation as applied against claim 6 above.
Regarding Claim 31:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 31 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 5 and the method claim 18. Therefore, claim 31 is rejected with the same rationale and motivation as applied against claims 5 and 18 above.
Regarding Claim 32:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 32 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 6 and the method claim 19. Therefore, claim 32 is rejected with the same rationale and motivation as applied against claims 6 and 19 above.
Claim(s) 7, 20, and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan, in view of Diriye, Bleikertz, Chalakudi, and Pennington et al. (US 20200327546 A1), hereinafter Pennington.
Regarding Claim 7:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach wherein the smart contract rules for the smart contract are predetermined smart contract rules associated with an application framework system that manages the collaborative document.
However, Pennington teaches wherein the smart contract rules for the smart contract are predetermined smart contract rules associated with an application framework system that manages the collaborative document (Pennington – Paragraph [0066]: In some embodiments, the data management platform may allow for one or more nodes to execute one or more “smart contracts,” which can refer to predefined computer code or computer programs that can be executed by nodes in the data management network, for example automatically and/or dynamically upon one or more predetermined conditions being met. Smart contracts may comprise one or more predetermined sets of instructions, logic, and/or electronic actions that can be deployed and integrated into the data management platform).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Pennington to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Pennington’s teachings of smart contract rules configured by an application that manages blockchain data into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make blockchain transactions. This combination would provide the system with the capability to establish and implement predetermined smart contract rules via an application that manages collaborative documents.
Regarding Claim 20:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 20 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 7. Therefore, claim 20 is rejected with the same rationale and motivation as applied against claim 7 above.
Regarding Claim 33:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 33 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 7 and the method claim 20. Therefore, claim 33 is rejected with the same rationale and motivation as applied against claims 7 and 20 above.
Claim(s) 10, 11, 23, 24, 36, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan, in view of Diriye, Bleikertz, Chalakudi, and Blackshear et al. (US 20200394648 A1), hereinafter Blackshear.
Regarding Claim 10:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the one or more storage devices store instructions that are operable, when executed by the one or more processors, to further cause the one or more processors to (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions); defined authorization criteria to generate the candidate transaction data structure (Padmanabhan – Paragraph [0123]: At logic block 215, the host validates, or receives validation of, the request to add the new block or transaction therein to the blockchain when the nodes in the consortium reach consensus according to the selected consensus protocol to add the block or transaction therein to the blockchain and communicate such to the host; Examiner’s Comment: the consensus protocol is the authorization criteria for validating a blockchain transaction request and/or adding a new block to the blockchain).
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach compare first device data for a first client device associated with the first user identifier and second device data for a second client device associated with the second user identifier to determine whether the request associated with the first user identifier and the confirmation indicator associated with the second user identifier satisfies defined authorization criteria.
However, Blackshear teaches compare first device data for a first client device associated with the first user identifier (Blackshear – Paragraph [0160]: In one or more embodiments, the client device 202 further utilizes the client application 204 to add a sequence number to the transaction request. Indeed, in one or more embodiments, a validator node device rejects transaction requests having an incorrect sequence number. In some embodiments, computer nodes of the distributed digital ledger transaction network can store the current sequence number associated with a user account) and second device data for a second client device (Blackshear – Paragraph [0162]: as shown in FIG. 2, the validator node device 206 includes admission control(s) 210; and Paragraph [0166]: The admission control(s) 210 can then access the virtual machine 222 to perform a series of additional checks in order to determine whether the transaction request is properly formed. For example, admission control(s) 210 can ... verify that the sequence number for the signed transaction is correct) associated with the second user identifier (Blackshear – Paragraph [0423]: validator nodes (e.g., authorized devices with cryptographic keys)) to determine whether the request associated with the first user identifier and the confirmation indictor associated with the second user identifier satisfies the defined authorization criteria (Blackshear – Paragraph [0166]: The admission control(s) 210 can then access the virtual machine 222 to perform a series of additional checks in order to determine whether the transaction request is properly formed. For example, admission control(s) 210 can ... verify that the sequence number for the signed transaction is correct).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Blackshear to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Blackshear’s teachings to use data associated with collaborating user devices for transaction verification into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make blockchain transactions. This combination would provide the system with another mechanism to ensure that all transactions made to the distributed ledger are secure.
Regarding Claim 11:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the apparatus of Claim 1.
Padmanabhan further teaches wherein the one or more storage devices store instructions that are operable, when executed by the one or more processors, to further cause the one or more processors to (Padmanabhan – Paragraph [0369]: According to another embodiment, there is a system to execute at a host organization, in which the system includes: a memory to store instructions; a processor to execute instructions); defined authorization criteria to generate the candidate transaction data structure (Padmanabhan – Paragraph [0123]: At logic block 215, the host validates, or receives validation of, the request to add the new block or transaction therein to the blockchain when the nodes in the consortium reach consensus according to the selected consensus protocol to add the block or transaction therein to the blockchain and communicate such to the host; Examiner’s Comment: the consensus protocol is the authorization criteria for validating a blockchain transaction request and/or adding a new block to the blockchain).
The combination of Padmanabhan, Diriye, Bleikertz, and Chalakudi does not expressly teach combine a first security key provided by a first client device associated with the first user identifier and a second security key provided by a second client device associated with the second user identifier to determine whether the request associated with the first user identifier and the confirmation indicator associated with the second user identifier satisfies defined authorization criteria.
However, Blackshear teaches combine a first security key provided by a first client device associated with the first user identifier (Blackshear – Paragraph [0161]: Additionally, the client device 202 can utilize the client application 204 to sign the transaction request. For example, the client application can utilize a private key associated with the user of the client device 202 (i.e., associated with the sending user account) to apply a signature to the transaction request (e.g., by encrypting the transaction request). The client device 202 can then transmit the signed transaction request to the validator node device 206) and a second security key provided by a second client device (Blackshear – Paragraph [0162]: In one or more embodiments, the client device 202 submits the transaction to a particular address associated with the validator node device 206. For example, the client device 202 can submit the transaction to an address associated with an admission control component (e.g., the admission control(s) 210) of the validator node device 206 … In one or more embodiments, upon receiving the transaction request, the validator node device 206 signs the transaction request (e.g., using a private key stored in the privacy signature manager 216) and returns the signed transaction request back to the client device 202) associated with the second user identifier (Blackshear – Paragraph [0423]: validator nodes (e.g., authorized devices with cryptographic keys)) to determine whether the request associated with the first user identifier and the confirmation indicator associated with the second user identifier satisfies the defined authorization criteria (Blackshear – Paragraph [0166]: The admission control(s) 210 can then access the virtual machine 222 to perform a series of additional checks in order to determine whether the transaction request is properly formed. For example, admission control(s) 210 can check the input signature(s) on the transaction request to determine whether the transaction request is properly signed).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Padmanabhan, Diriye, Bleikertz, and Chalakudi, further incorporating Blackshear to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Blackshear’s teachings to use security keys associated with collaborating user devices for transaction verification into Padmanabhan, Diriye, Bleikertz, and Chalakudi’s system for receiving and processing requests to make blockchain transactions. This combination would provide the system with another mechanism to ensure that all transactions made to the distributed ledger are secure.
Regarding Claim 23:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 23 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 10. Therefore, claim 23 is rejected with the same rationale and motivation as applied against claim 10 above.
Regarding Claim 24:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer-implemented method of Claim 14.
In addition, Claim 24 is a method claim that recites limitations corresponding to the ones of the apparatus Claim 11. Therefore, claim 24 is rejected with the same rationale and motivation as applied against claim 11 above.
Regarding Claim 36:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 36 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 10 and the method claim 23. Therefore, claim 36 is rejected with the same rationale and motivation as applied against claims 10 and 23 above.
Regarding Claim 37:
Padmanabhan, Diriye, Bleikertz, and Chalakudi combine to teach the computer program product of Claim 27.
In addition, Claim 37 is a computer program product claim that recites limitations corresponding those of the apparatus Claim 11 and the method claim 24. Therefore, claim 37 is rejected with the same rationale and motivation as applied against claims 11 and 24 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wylie et al. (US 20220261380 A1) teaches methods for managing edits to a multi-user collaborative document via distributed ledger
Gonzales Jr. (US 20190205558 A1) teaches a system for managing a data file stored on a blockchain, wherein a file author approves/rejects edits to the file based on criteria
Nadeau et al. (US 20220129443 A1) teaches systems and methods for accessing and modifying a virtual file via blockchain
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 NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights