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 .
Response to Arguments
Applicant’s arguments, see pages 9-11, filed on December 31, 2025, with respect to the rejection(s) of claim(s) 1-5 under BACK et al. (20160330034) in view of Sheng et al. (US 20170228731 A --hereinafter-- Sheng) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Horne et al. (US 20080104407 A1 –hereinafter – “Horne”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claims 1-5 are rejected under 35 U.S.C. 103 as being unpatentable over BACK et al. (Hereinafter referred to as BACK, Us. Pub. No.: 20160330034) in view of Sheng et al. (US 20170228731 A --hereinafter-- Sheng) in further view Horne et al. (US 20080104407 A1 –hereinafter – “Horne”).
As per claim 1:
BACK discloses a method of recording a data transaction comprising, at a device associated with a first entity (0005-0006: sidechain validator server):
determining first seed data, the first seed data being associated with a previous data transaction involving the first entity (0030-0031: pegged sidechains; transfer of assets; 0033: Assets are transferred to the pegged sidechains by providing proofs of possession in the transferring transactions themselves, avoiding the need for nodes to track the sending chain. On a high level, when moving assets from one blockchain to another, a transaction is created on the first blockchain locking the assets. A transaction is also created on the second blockchain whose inputs include a cryptographic proof that the lock transaction on the first blockchain was done correctly. These inputs are tagged with an asset type, e.g. the genesis hash of the asset's originating blockchain; 0033: Assets are transferred to the pegged sidechains by providing proofs of possession in the transferring transactions themselves, avoiding the need for nodes to track the sending chain; These inputs are tagged with an asset type, e.g. the genesis hash of the asset's originating blockchain);
determining, as a first data transaction occurs between the first entity and a second entity, second seed data by combining at least the first seed data and an indication of the first data transaction to generate a record of the first data transaction (0016: provides a well-defined ordering for transactions (i.e., each subset of the blockchain has a least element in the ordering) collection of blocks, on which all users must (eventually) come to consensus which determines the history of asset control and provides a computationally unforgeable time ordering for transactions; 0069-0071; 0088: include root hash in each block; obtain a commitment to every element in the tree, since hash commitments are transitive, with Merkel Tree; H(H(data1)∥H(data2)=commitment);
generating a first hash of the first data transaction and associated with the record by hashing the second seed data, the first hash of the first data transaction comprising a history of data transactions involving the first entity (0016: blockheader commitments a hash: given data x, one can publish H(x) where H is a hash function, and only later reveals x (e.g., by using a hash table or Merkel Tree] to previous headers form a blockchain (or “chain), which provides a well-defined ordering for transactions (i.e., each subset of the blockchain has a least element in the ordering) collection of blocks, on which all users must (eventually) come to consensus which determines the history of asset control and provides a computationally unforgeable time ordering for transactions; 0069-0071: proof of work, hashpower; 0077);
Contemporaneously storing the record of the first data transaction and the first hash in a memory (0077: record output, 0084; 0096: memory RAM to provide to implement pegged sidechains and store hash transactions).
BACK does not explicitly disclose the generating of the first hash of the first data transaction and associated with the record by hashing the second seed data, wherein the generating of the first hash of the first data transaction and associated with the record occurs at a same time as a completion of the first data transaction and Wherein the record proves the completion of the first data transaction by the first entity and the second entity. Sheng, in analogous art however, discloses the generated first hash of the first data transaction by hashing the second seed data, wherein the generating of the first hash of the first data transaction occurs at a same time as a completion of the first data transaction ([0196] The chain of ownership is created by using a timestamp server that creates and widely publishes a hash of a block of items to be time-stamped, with each timestamp including previous timestamps in its hash value. To prevent double-spending, i.e., ensuring that the BTC payer didn't sign an earlier transaction for same BTC or already spent the BTC, a timestamp server is used to maintain a single chronological history in which each transaction was received. This process ensures that at the time of the transaction, the payee knows that majority of nodes agree to having received the current transaction as the first received. Subsequent transactions for the same BTC don't need to be recorded as they are rejected in the verification process. [0197] FIG. 25 shows a schematic representation of the creation of a blockchain from individual blocks as may be performed by the CETPA. As the only way to confirm absence of a transaction is to maintain a record of all transactions, as seen in FIG. 25, each timestamp includes the previous timestamp in its hash starting from first transaction. [0230] Next, the CETPA determines whether U1 entries exist in the column and row entries of a transaction matrix that is used to monitor all transactions occurring via the CETPA (step 2816). If no prior transactions have involved U1 then there will be no existing row, column entry in the transaction matrix, and in such case the CETPA will add a Row/Column Entry based on U1's wallet address (step 2818). [0231] If, on the other hand, U1 entries already exist in the matrix, the process 2800 next determines whether U2 row/column entries exist in the transaction matrix (step 2820). If U2 entries do not exist, the CETPA adds a U2 row/column entry to the transaction distance matrix based on U2's wallet address (step 2822). From step 2820 or 2822 above, the process 2800 then continues to step 2824. [0232] Next, at step 2824, the CETPA determines whether a previous transaction involving both U1 and U2 exist. If no such prior transaction exists, the CETPA will simply add the transaction amount to the U1, U2 row/column in the transaction matrix (step 2828). On the other hand, if prior entries exist in the (row, column) entry corresponding to (U1, U2) in the transaction matrix, the CETPA system will instead update the total transaction amount to include the new transaction amount (step 2826). In various embodiments, the total transaction amount will be the amount of all recorded transactions between U1 and U2. IN additional embodiments, the amount of each individual transaction between U1 and U2, along with the timestamp of each transaction is stored within the value stored in the transaction matrix. [0233] The distance matrix is used to record the transactions that happen between every pair of users that have ever involved in any transactions. However, especially with a huge base of users, there will be a high percentage of the row/column entries in the distance matrix where the value zero, because there exist no transactions between such user pairs. When most of the elements are zero, the matrix is mathematically considered a “sparse matrix.”); and wherein the record proves the completion of the first data transaction by the first entity and the second entity ([0196] The chain of ownership is created by using a timestamp server that creates and widely publishes a hash of a block of items to be time-stamped, with each timestamp including previous timestamps in its hash value. To prevent double-spending, i.e., ensuring that the BTC payer didn't sign an earlier transaction for same BTC or already spent the BTC, a timestamp server is used to maintain a single chronological history in which each transaction was received. [0197] As the only way to confirm absence of a transaction is to maintain a record of all transactions, as seen in FIG. 25, each timestamp includes the previous timestamp in its hash starting from first transaction. [0198] The block chain makes double spending very difficult as each block is preceded by prior block in chronological order as well as is based upon its hash value. To prevent double-spending, i.e., spending of the same BTC twice, public keys and signatures are published as part of publicly available and auditable block chain. To make it infeasible to falsify the blockchain, proof of work (PoW) is used to make addition of each block very costly. [0212] Upon completion of a transaction, the CETPA system sends a transaction confirmation (step 2710) via the data communications network, which is received by the client 106a (step 2712) and displayed to the user (step 2714).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the first hash and the first data transaction disclosed by BACK to include the generated first hash of the first data transaction by hashing the second seed data, wherein the generating of the first hash of the first data transaction occurs at a same time as a completion of the first data transaction and wherein the record proves the completion of the first data transaction by the first entity and the second entity. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide guided Target Transactions and Encrypted Transaction Processing and Verification, for Computationally Efficient Transfer Processing and Auditing Apparatuses as suggested by Sheng (0002).
BACK in view of Sheng do not explicitly disclose the second seed data being associated with an intermediate hash to be added to the record, wherein the record is an audit record. Horne, in analogous art however, discloses the second seed data being associated with an intermediate hash to be added to the record, wherein the record is an audit record ([0029] Random tree 300 may comprise greater or lesser number of intermediate nodes between seed value 206 and the leaf nodes of the random tree. In some embodiments, random tree 300 may be a set of randomly generated values. [0030] FIG. 7 depicts operation of an embodiment for parsing unparsed audit records in an audit record set into a set of fields. In order to support more efficient querying of audit records stored in audit log 108, unparsed audit records may be parsed into a set of fields. Integrity system 104 receives and signs a received audit record set 106 using a seed value 206 and hash tree 302 to generate summary hash value 214.sub.1 which is certified, as described above. Certifying process may comprise, for example, a time-stamping process which generates an integrity certificate 304 based on summary hash value 214.sub.1. [0031] Integrity system 104 stores the generated verifiable audit record set 114 comprising seed value 206, audit record set 106, and integrity certificate 304 to audit log 108. After generation of verifiable audit record set 114, computer system 100 executes a process to parse the audit records into a set of fields, e.g., a transformation 702 with a transform ID 703 is applied to audit record set 106. As described above, after transformation 702 is performed, integrity system 104 accesses a CIS to generate an integrity certificate 708 verifying the integrity of the audit record set 706 after performing transformation 702 on audit record set 106. Integrity system 104 generates a second verifiable audit record set 704 comprising a parsed version 706 of audit record set 106, seed value 206, an integrity certificate 708, and a representation of transformation 702, i.e., transform ID 703. Verification system 101 uses integrity certificate 708 to verify the integrity of the parsed version of audit record set 106). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the seed data disclosed by BACK in view of Sheng in view of Sheng to include the second seed data being associated with an intermediate hash to be added to the record, wherein the record is an audit record. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to establish the integrity of an audit record set by receiving a set of audit records and generating a first set of random values wherein each audit record in the set corresponds to at least one value of the first set) as suggested by Horne ([0005-0006]).
As per claim 2:
BACK discloses wherein the first seed data comprises a starting hash (0088: include root hash in each block; obtain a commitment to every element in the tree, since hash commitments are transitive, with Merkel Tree).
As per claim 3:
BACK discloses wherein the starting hash result from hashing a record of the previous data transaction involving the first entity (0088: include root hash in each block; obtain a commitment to every element in the tree, since hash commitments are transitive, with Merkel Tree; H(H(data1)∥H(data2)=commitment).
As per claim 4:
BACK discloses wherein the starting hash comprises a random hash (0092: Random seed; seed to initialize a cryptographic deterministic random number generator, such as, for example, NIST HMAC_DRBG).
As per claim 5:
BACK discloses wherein the random hash comprises at least one of a signature from the device associated with the first entity, a date that the random hash was generated, or a time that the random hash was generated (0017-0018: multi-party signature or DMM –secure ledge in blockchain header; 0080; 0084-0085).
Allowable Subject Matter
Claims 6-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The following is a statement of reasons for the indication of allowable subject matter:
The applicant’s invention is directed to a Tereon module architecture to provide ACID (atomicity, consistency, isolation, and durability) consistency model for databases that state that each database transaction must succeed if the entire transaction is required to be rolled back (atomicity), cannot leave the database in an inconsistent state (consistency), cannot interfere with each other (isolation); and must persist, even when the servers restart (durability). ACID (atomicity, consistency, isolation, and durability) consistency model is needed over large-scale systems that in known systems can only benefit from BASE (basic availability, soft-state, and eventual consistency) consistency, particularly by applying to ACID to blockchain database transactions as having allowable subject matters:
In Claim 6: wherein providing second seed data further comprises combining a first zero-knowledge proof and a second zero-knowledge proof with the first seed data and the record of the first data transaction, wherein: the first zero-knowledge proof comprises proof that a starting hash comprises a true hash of the previous data transaction involving the first entity; and the second zero-knowledge proof comprises proof that a second hash comprises the true hash of a previous data transaction involving the second entity.
In claim 20: sending the first hash to a device associated with the second entity; receiving a second hash from the device associated with the second entity, wherein the second hash comprises a hash of a previous data transaction involving the second entity; and generating a record of a second data transaction; determining third seed data by combining the record of the second data transaction with the first hash and the second hash; generating a third hash by hashing the third seed data, the third hash comprising a history of data transactions involving the first entity and a history of data transactions involving the second entity; and storing the third hash against the record of the second data transaction in the memory.
BRI (Broadest Reasonable Interpretation)
The above claims under examination have been given their BRI consistent with the applicant’s disclosure as they would be interpreted by one of ordinary skill in the art at the time of filing the invention and the following claim words or terms or phrases or languages have been given to them, as follows, reasonable BRI considerations and context in view of the applicant’s disclosure in order to construe and appraise boundary and scope of the claimed limitations. For example, for the following claim words or terms or phrases or languages, the examiner recites BRI considerations from the applicant’s disclosure as follows:
Seed or Seed Data: [0020] The first seed data may comprise a starting hash. The starting hash may be the result of hashing a record of a previous data transaction involving the first entity. The starting hash may comprise a random hash. The random hash may comprise at least one of a signature from the device, the date and/or the time that the random hash was generated.
[0021] Providing second seed data may further comprise combining a first zero-knowledge proof and a second zero-knowledge proof with the first seed data and the record of the first data transaction, wherein the first zero-knowledge proof may comprise proof that the starting hash may comprise the true hash of the previous data transaction involving the first entity, and the second zero-knowledge proof may comprise proof that a second hash may comprise the true hash of a previous data transaction involving the second entity.
[0294] A system hash can also be added to each record. This will be a hash of the record where the seed will be the hash of the previous action on the system, irrespective of whether or not that action relates to the account to which the record being hashed belongs. If the system hash is added then a hash chain within each account, and a hash chain of the system as a whole, is provided.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior art.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached on 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached on (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TECHANE GERGISO/Primary Examiner, Art Unit 2494