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 .
DETAILED ACTION
This action is in response to the amendment filed May 19, 2026. Claims 1-20 are pending and examined. This action is Final.
Response to Arguments
The applicant’s amendments did fix the 101 problems so those rejections are withdrawn.
Having a hash of the previous entry and using digital signatures are one of the basic parts of the definition of blockchains which at this point is a very established version of an append only log. Therefore it would have been obvious to a person of ordinary skill in such logs to include such features.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Waugh et al. (USPG 2019/0007,393 A1) in view of Lin (USPG 2009/0228,701).
As per claim 1 Waugh teaches:
A method performed by a verifier comprising a processor and a memory storing instructions that, when executed by the processor, cause the processor to perform the method, the method comprising:
requesting, from a storage provider maintaining an append-only log storing a first log entry written by a first writer, verification of the first log entry, wherein the first log entry comprises first log data, a first signature and a first hash value; (see at least Waugh paragraphs 16 and 86 “The current document describes a system that provides a tamper-resistant logging service using a mechanism that allows clients to verify that the log entries maintained by the logging service have not been altered. When a client submits a sequence of log entries to the logging service, the logging service generates an interdependent series of hash values which may be provided to the client. When the logging service receives a sequence of log entries from the client, the logging service assigns a sequence ID to each log entry of the received log entries and determines an initial hash value. The logging service may determine an initial hash value by retrieving a previous hash value generated from previous log entries or by using a random initial hash value if no previous log entries have been received. A hash value for the first log entry in the received sequence is generated using the initial hash value and the content of the first log entry. The logging service generates hash values for each of the remaining log entries by generating a hash value based at least in part on the content of each log entry, combined with the hash of the previous log entry. The logging system returns the range of sequence IDs and the hash of the last log entry in the sequence to the client.” “In various embodiments, data objects such as log entries with associated hash values may be cryptographically verifiable. In one example, cryptographically verifiable data objects are created to be cryptographically verifiable by the system to which the data object is to be provided or another system that operates in conjunction with the system to which the data object is to be provided. For example, the data object may be encrypted so as to be decryptable by the system that will cryptographically verify the data object, where the ability to decrypt the data object serves as cryptographic verification of the data object. As another example, the data object may be digitally signed (thereby producing a digital signature of the data object) such that the digital signature is verifiable by the system that will cryptographically verify the data object. In other examples, both encryption and digital signatures are used for cryptographic verifiability and/or security.”)
obtaining, from the storage provider, the first log entry and at least a portion of a second log entry preceding the first log entry to enable verification of the first log entry, wherein the second log entry comprises second log data, a second signature and a second hash value; (see at least Waugh paragraph 19 “When determining the hash values for the log entries, the log entries are processed in accordance with the sequence numbers assigned to each log entry by the logging service. In general, the hash value of the current log entry is based at least in part on the hash value of at least one previous log entry. In some examples, the prior hash value is provided to a hash-value-generation function as a seed value. In other examples, the hash value of the previous log entry is combined with the data of the current log entry. For example, the prior hash value may be prepended or appended to the data of the current log entry, and the hash value determined for the entire combination. For example, the hash value of the first log entry is combined with the data of the second log entry, and the hash value of the combination is the hash value of the second log entry. The hash value of the second log entry is combined with the data of the third log entry and so on.”)
verifying, by the verifier, the first log entry. (see at least Waugh paragraph 17 “As a result of receiving the range of sequence ID's and the hash of the last log entry, the client may elect to save the information in an audit history database. The client may selectively verify the log entries maintained by the logging service using the information stored in the audit history database. By verifying the log entries against the information stored in the audit history database, the client may detect unauthorized modification or tampering. The client may retain some, all, or none of the audit-history information based at least in part on the amount of auditing desired and the amount of storage space available for the audit history information.”)
While Waugh does teach verifying a log Lin teaches a verifier to verify the integrity and correctness of the logs. (see at least Lin paragraph 10 “In view of the above problems of protecting the integrity and correctness of the logs, the present invention is directed to a logging system based on the one-way hash function. A verifying party (a verifier) checks the logs of a verified party (a user system) with the help of a verification server (a trusted third party), so as to ensure that the logs are not changed or altered. For easy comprehension, it is particularly explained that the following "log file" is an embodied form of the so-called "log.”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success. As for determining whether the first signature and the first hash value of the first log entry are consistent with at least a portion of the second log entry in the append-only log that is practically a definition of a blockchain. (Blockchain page 3 Blocks “Blocks hold batches of valid transactions that are hashed and encoded into a Merkle tree. [3] Each block includes the cryptographic hash of the prior block in the blockchain, linking the two. The linked blocks form a chain. [3] This iterative process confirms the integrity of the previous block, all the way back to the initial block, which is known as the genesis block (Block o).[26J[27J To assure the integrity of a block and the data contained in it, the block is usually digitally signed. [28]”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made that wanted to create unalterable list of entries to have each succeeding element in the list contain a hash of the proceeding element and be digitally signed so that the integrity of each element in the list can be verified by checking the hash values and digital signatures. Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claim 2 Waugh teaches:
The method of claim 1, wherein said verifying, by the verifier, the first log entry further comprises:
verifying the first signature based on the first log data, the first signature, a public key associated with the first writer, and the second hash value; (see at least Waugh paragraph 86 “In various embodiments, data objects such as log entries with associated hash values may be cryptographically verifiable. In one example, cryptographically verifiable data objects are created to be cryptographically verifiable by the system to which the data object is to be provided or another system that operates in conjunction with the system to which the data object is to be provided. For example, the data object may be encrypted so as to be decryptable by the system that will cryptographically verify the data object, where the ability to decrypt the data object serves as cryptographic verification of the data object. As another example, the data object may be digitally signed (thereby producing a digital signature of the data object) such that the digital signature is verifiable by the system that will cryptographically verify the data object. In other examples, both encryption and digital signatures are used for cryptographic verifiability and/or security. The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair. Using the public key to encrypt the data object may include generating a symmetric key, using the symmetric key to encrypt the data object, and encrypting the symmetric key using the public key, where the encrypted symmetric key is provided to a system with the encrypted data object to enable the system to use the corresponding private key to decrypt the symmetric key and use the decrypted symmetric key to decrypt the data object. Further, in some embodiments, the data object is digitally signed using a private key of a public/private key pair corresponding to the computer system that encrypts and/or digitally signs the data object (e.g., a user device). For example, an application may be provisioned with the private key and the data object may include a certificate for the private key for use by a system for verification of the digital signature of the data object. Other variations, including variations where a symmetric key shared between the user computer and the system that cryptographically verifies the data object can be used to encrypt and/or digitally sign the data object.”)
generating a hash result by hashing, using a predetermined hash function, a concatenation comprising the first log data and at least one of the first signature or the second signature; (see at least Waugh paragraph 47 “The client computer system 404 uses the log batch 409 returned by the logging service 402 to verify that the log entry records associated with the log batch 409 have not been modified or corrupted. The client computer system 404 queries an audit history database 434 to acquire an expected hash value for the log batch 409. The audit history database 434 retains log batch hashes 438 in association with log entry ranges 436. The client computer system 404 determines the range of identifiers represented in the log batch 409 and queries the audit history database 434 to retrieve the expected hash values for the log entry records in the log batch 409. The client computer system 404 recalculates the hash value of each log entry record in the log batch 409 using the log entry record data and prior hash value provided by the logging service 402. In some examples, the prior hash value for each batch of log entry records is retained in the audit history database 434, and the client computer system 404 determines the prior hash for each log entry record by determining the hash value of each log entry record in sequence. If the hash values determined by the client computer system 404 match the hash values provided by the logging service 402, then it is likely that the corresponding log entry records retained by the logging service 402 have not been altered or corrupted. If the hash values determined by the client computer system 404 do not match the hash values provided by the logging service 402, then the log entry records retained by the logging service 402 have been altered since they were submitted by the client computer system 404.”) and
verifying the first hash value by comparing the hash result to the first hash value. (see at least Waugh paragraph 47)
As per claim 3 Waugh teaches:
The method of claim 1, wherein said verifying, by the verifier, the first log entry further comprises:
determining a reference signature by signing, using a private key associated with the first writer, a concatenation of the first log data and the second hash value; (see at least Waugh paragraph 86)
comparing the reference signature to the first signature; (see at least Waugh paragraph 86)
generating a hash result by hashing, using a predetermined hash function, a concatenation comprising the first log data and at least one of the first signature or the second signature; (see at least Waugh paragraph 47) and
comparing the hash result to the first hash value. (see at least Waugh paragraph 47)
As per claim 4 Waugh teaches:
The method of claim 1, wherein said verifying, by the verifier, the first log entry further comprises:
providing, to the first writer, a request to generate a cryptographic proof based at least on a private key associated with the first writer, a predetermined hash function, and the portion of the second log entry; (see at least Waugh paragraph 86 Verifying a digital signature is cryptographic proof of being able to verify a signature.)
receiving, from the first writer, the cryptographic proof; and
verifying the cryptographic proof.
As per claim 5 Waugh teaches:
The method of claim 1, further comprising:
selecting, based on a proof-of-storage protocol, a portion of the append-only log that, when verified, indicates a predetermined probability that the storage provider is in actual possession of the entire append-only log; (see at least Waugh paragraph 42 “At block 322, the client receives the range of sequence identifiers and the hash value of the batch of log entry records from the logging service, and confirms that the hash value received from the logging service matches the hash value determined by the client. If the hash value received from the logging service does not match the hash value determined by the client, the client determines that the log entries submitted by the client may have been modified or corrupted by the logging service. In some examples, the client selectively or randomly confirms the hash value provided by the logging service against a hash value determined by the client to reduce the amount of processing performed by the client.”)
obtaining, from the storage provider, log entries in the portion of the append-only log; (see at least Waugh paragraph 42) and
determining that the likelihood that the storage provider is in actual possession of the entire append-only log satisfies the predetermined probability by verifying the log entries in the portion of the append-only log. (see at least Waugh paragraph 42)
As per claim 6 Waugh teaches:
The method of claim 1, further comprising:
obtaining, from the append-only log, at least a portion of a last log entry stored in the append-only log, the last entry comprising last log data, a last signature, and a last hash value; (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature)
determining a third log entry, the third log entry comprising third log data, a third signature, and a third hash value; (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature) and
appending the third log entry to the append-only log by writing, to the append-only log, a tuple comprising the third log data, the third signature, and the third hash value, wherein the third signature is determined by signing, using a private key associated with a third writer of the third log entry, a concatenation comprising the third log data and at least one of the third hash value or a hash value associated with the last log entry, and the third hash value is determined by hashing, using a predetermined hash function, a concatenation comprising the third log data and at least one of the third signature or a signature associated with the last log entry. (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature)
As per claim 7 while Waugh arguably teaches a writer of a log entry in the append-only log; (see at least Waugh paragraph 16 “The current document describes a system that provides a tamper-resistant logging service using a mechanism that allows clients to verify that the log entries maintained by the logging service have not been altered.” Therefore the clients which are the writers can verify that log entries have not been changed.) Lin teaches all three. (see at least Lin paragraph 10 “In view of the above problems of protecting the integrity and correctness of the logs, the present invention is directed to a logging system based on the one-way hash function. A verifying party (a verifier) checks the logs of a verified party (a user system) with the help of a verification server (a trusted third party), so as to ensure that the logs are not changed or altered. For easy comprehension, it is particularly explained that the following "log file" is an embodied form of the so-called "log."”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claim 8 Waugh teaches:
A system comprising:
a processor; (see at least Waugh paragraph 77 “Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium ( e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed (i.e., as a result of being executed) by a processor of the server, allow the server to perform its intended functions.”) and
a memory device (see at least Waugh paragraph 77) that stores program code structured to cause the processor to:
request, from a storage provider maintaining an append-only log storing a first log entry written by a first writer, verification of the first log entry, wherein the first log entry comprises first log data, a first signature and a first hash value; (see at least Waugh paragraphs 16 and 86)
obtain, from the storage provider, the first log entry and at least a portion of a second log entry preceding the first log entry to enable verification of the first log entry, wherein the second log entry comprises second log data, a second signature and a second hash value; (see at least Waugh paragraph 19 ) and
verify the first log entry. (see at least Waugh paragraph 17
While Waugh does teach verifying a log Lin teaches a verifier to verify the integrity and correctness of the logs. (see at least Lin paragraph 10 “In view of the above problems of protecting the integrity and correctness of the logs, the present invention is directed to a logging system based on the one-way hash function. A verifying party (a verifier) checks the logs of a verified party (a user system) with the help of a verification server (a trusted third party), so as to ensure that the logs are not changed or altered. For easy comprehension, it is particularly explained that the following "log file" is an embodied form of the so-called "log.”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success. As for determining whether the first signature and the first hash value of the first log entry are consistent with at least a portion of the second log entry in the append-only log that is practically a definition of a blockchain. (Blockchain page 3 Blocks “Blocks hold batches of valid transactions that are hashed and encoded into a Merkle tree. [3] Each block includes the cryptographic hash of the prior block in the blockchain, linking the two. The linked blocks form a chain. [3] This iterative process confirms the integrity of the previous block, all the way back to the initial block, which is known as the genesis block (Block o).[26J[27J To assure the integrity of a block and the data contained in it, the block is usually digitally signed. [28]”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made that wanted to create unalterable list of entries to have each succeeding element in the list contain a hash of the proceeding element and be digitally signed so that the integrity of each element in the list can be verified by checking the hash values and digital signatures. Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claim 9 Waugh teaches:
The system of claim 8, wherein, to verify the first log entry, the program code is structured to cause the processor to:
verify the first signature based on the first log data, the first signature, a public key associated with the first writer, and at least one of the first hash value or the second hash value; (see at least Waugh paragraph 86)
generate a hash result by hashing, using a predetermined hash function, a concatenation comprising the first log data and at least one of the first signature or the second signature; (see at least Waugh paragraph 47) and
verify the first hash value by comparing the hash result to the first hash value. (see at least Waugh paragraph 47 )
As per claim 10 Waugh teaches:
The system of claim 8, wherein, to verify the first log entry, the program code is structured to cause the processor to:
determine a reference signature by signing, using a private key associated with the first writer, a concatenation of the first log data and the first hash value; (see at least Waugh paragraph 86)
compare the reference signature to the first signature; (see at least Waugh paragraph 86)
generate a hash result by hashing, using a predetermined hash function, a concatenation comprising the first log data and at least one of the first signature or the second signature; (see at least Waugh paragraph 47) and
compare the hash result to the first hash value. (see at least Waugh paragraph 47)
As per claim 11 Waugh teaches:
The system of claim 8, wherein, to verify the first log entry, the program code is structured to cause the processor to:
provide, to the first writer, a request to generate a cryptographic proof based at least on a private key associated with the first writer, a predetermined hash function, and the portion of the second log entry; (see at least Waugh paragraph 86 Verifying a digital signature is cryptographic proof of being able to verify a signature.)
receive, from the first writer, the cryptographic proof; and
verify the cryptographic proof.
As per claim 12 Waugh teaches:
The system of claim 8, wherein the program code is structured to further cause the processor to:
select, based on a proof-of-storage protocol, a portion of the append-only log that, when verified, indicates a predetermined probability that the storage provider is in actual possession of the entire append-only log; (see at least Waugh paragraph 42)
obtain, from the storage provider, log entries in the portion of the append-only log; (see at least Waugh paragraph 42) and
determine that the likelihood that the storage provider is in actual possession of the entire append-only log satisfies the predetermined probability by verifying the log entries in the portion of the append-only log. (see at least Waugh paragraph 42)
As per claim 13 Waugh teaches:
The system of claim 8, wherein the program code is structured to further cause the processor to:
obtain, from the append-only log, at least a portion of a last log entry stored in the append-only log, the last entry comprising last log data, a last signature, and a last hash value; (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature)
determine a third log entry, the third log entry comprising third log data, a third signature, and a third hash value; (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature) and
append the third log entry to the append-only log by writing, to the append-only log, a tuple comprising the third log data, the third signature, and the third hash value, wherein the third signature is determined by signing, using a private key associated with a third writer of the third log entry, a concatenation comprising the third log data and at least one of the third hash value or a hash value associated with the last log entry, and the third hash value is determined by hashing, using a predetermined hash function, a concatenation comprising the third log data and at least one of the third signature or a signature associated with the last log entry. (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature)
As per claim 14 Waugh teaches:
The system of claim 8, wherein, to request, from a storage provider maintaining an append-only log storing a first log entry written by a first writer, verification of the first log entry, the program code is structured to cause the processor to perform at least one of:
request verification of the first log entry on-demand; (see at least Waugh paragraph 18 “The client may initiate an audit of the log entries maintained by the logging service by submitting, to the logging service, a request that identifies a range of sequence IDs. The logging service responds to the request by providing the log entries associated with the range of sequence IDs. The client retrieves, from the audit history database, the initial and final hash values for the specified range of log entries.”) request verification of the first log entry periodically; or request verification of the first log entry responsive to a trigger.
As per claim 15 Waugh teaches:
A tangible computer-readable storage medium comprising executable instructions that, when executed by a processor, cause the processor to:
request, from a storage provider maintaining an append-only log storing a first log entry written by a first writer, verification of the first log entry, wherein the first log entry comprises first log data, a first signature and a first hash value; (see at least Waugh paragraphs 16 and 86)
obtain, from the storage provider, the first log entry and at least a portion of a second log entry preceding the first log entry to enable verification of the first log entry, wherein the second log entry comprises second log data, a second signature and a second hash value; (see at least Waugh paragraph 19 ) and
verify the first log entry. (see at least Waugh paragraph 17
While Waugh does teach verifying a log Lin teaches a verifier to verify the integrity and correctness of the logs. (see at least Lin paragraph 10 “In view of the above problems of protecting the integrity and correctness of the logs, the present invention is directed to a logging system based on the one-way hash function. A verifying party (a verifier) checks the logs of a verified party (a user system) with the help of a verification server (a trusted third party), so as to ensure that the logs are not changed or altered. For easy comprehension, it is particularly explained that the following "log file" is an embodied form of the so-called "log.”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success. As for determining whether the first signature and the first hash value of the first log entry are consistent with at least a portion of the second log entry in the append-only log that is practically a definition of a blockchain. (Blockchain page 3 Blocks “Blocks hold batches of valid transactions that are hashed and encoded into a Merkle tree. [3] Each block includes the cryptographic hash of the prior block in the blockchain, linking the two. The linked blocks form a chain. [3] This iterative process confirms the integrity of the previous block, all the way back to the initial block, which is known as the genesis block (Block o).[26J[27J To assure the integrity of a block and the data contained in it, the block is usually digitally signed. [28]”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made that wanted to create unalterable list of entries to have each succeeding element in the list contain a hash of the proceeding element and be digitally signed so that the integrity of each element in the list can be verified by checking the hash values and digital signatures. Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claim 16 Waugh teaches:
The tangible computer-readable storage medium of claim 15, wherein, to verify the first log entry, the executable instructions, when executed by the processor, further cause the processor to:
verify the first signature based on the first log data, the first signature, a public key associated with the first writer, and at least one of the first hash value or the second hash value; (see at least Waugh paragraph 86)
generate a hash result by hashing, using a predetermined hash function, a concatenation comprising the first log data and at least one of the first signature or the second signature; (see at least Waugh paragraph 47) and
verify the first hash value by comparing the hash result to the first hash value. (see at least Waugh paragraph 47)
As per claim 17 Waugh teaches:
The tangible computer-readable storage medium of claim 15, wherein, to verify the first log entry, the executable instructions, when executed by the processor, further cause the processor to:
determine a reference signature by signing, using a private key associated with the first writer, a concatenation of the first log data and at least one of the first hash value or the second hash value; (see at least Waugh paragraph 86)
compare the reference signature to the first signature; (see at least Waugh paragraph 86)
generate a hash result by hashing, using a predetermined hash function, a concatenation comprising the first log data and at least one of the first signature or the second signature; (see at least Waugh paragraph 47) and
compare the hash result to the first hash value. (see at least Waugh paragraph 47)
As per claim 18 Waugh teaches:
The tangible computer-readable storage medium of claim 15, wherein, to verify the first log entry, the executable instructions, when executed by the processor, further cause the processor to:
provide, to the first writer, a request to generate a cryptographic proof based at least on a private key associated with the first writer, a predetermined hash function, and the portion of the second log entry; (see at least Waugh paragraph 86 Verifying a digital signature is cryptographic proof of being able to verify a signature.)
receive, from the first writer, the cryptographic proof; and
verify the cryptographic proof.
As per claim 19 Waugh teaches:
The tangible computer-readable storage medium of claim 15, wherein the executable instructions, when executed by the processor, further cause the processor to:
select, based on a proof-of-storage protocol, a portion of the append-only log that, when verified, indicates a predetermined probability that the storage provider is in actual possession of the entire append-only log; (see at least Waugh paragraph 42)
obtain, from the storage provider, log entries in the portion of the append-only log; (see at least Waugh paragraph 42) and
determine that the likelihood that the storage provider is in actual possession of the entire append-only log satisfies the predetermined probability by verifying the log entries in the portion of the append-only log. (see at least Waugh paragraph 42)
As per claim 20 Waugh teaches:
The tangible computer-readable storage medium of claim 15, wherein the executable instructions, when executed by the processor, further cause the processor to:
obtain, from the append-only log, at least a portion of a last log entry stored in the append-only log, the last entry comprising last log data, a last signature, and a last hash value; (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature)
determine a third log entry, the third log entry comprising third log data, a third signature, and a third hash value; (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature) and
append the third log entry to the append-only log by writing, to the append-only log, a tuple comprising the third log data, the third signature, and the third hash value, wherein the third signature is determined by signing, using a private key associated with a third writer of the third log entry, a concatenation comprising the third log data and at least one of the third hash value or a hash value associated with the last log entry, and the third hash value is determined by hashing, using a predetermined hash function, a concatenation comprising the third log data and at least one of the third signature or a signature associated with the last log entry. (see at least Waugh paragraphs 19 and 86. Paragraph 19 lays out that hash values normally include an entry before them so that they can’t be altered without showing the corruption. Paragraph 86 teaches using the signature)
Conclusion
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.
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
Sewell et al. U.S. Patent 12,423,682 B2
Paunoiu et al . USPG 2026/0163,867 A1 – paragraph 52 every block added to a blockchain is checked for meeting the terms of the blockchain
Any inquiry concerning this communication from the examiner should be directed to Scott S. Trotter, whose telephone number is 571-272-7366. The examiner can normally be reached on 8:30 AM – 5:00 PM, M-F.
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, Matthew Gart, can be reached on 571-272-3955.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
The fax phone number for the organization where this application or proceeding is assigned are as follows:
(571) 273-8300 (Official Communications; including After Final Communications labeled “BOX AF”)
(571) 273-7366 (Draft Communications)
/SCOTT S TROTTER/Primary Examiner, Art Unit 3696
Prosecution Insights