DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
The instant application is a 371 national stage application of PCT/CN2022/116772 and further claims foreign priority to Chinese application number CN202210333295.9. The priority claims comply with all applicable rules and regulations. Therefore, the effective filing date of the claims will be 14 November 2023.
Response to Arguments
Applicant's arguments that state “Wilson fails to disclose any address comparison between any two parties among one custodian, at least one broker-dealer, at least one investor and their respective addresses” and “Wilson fails to involve determining whether the file record being not 0, and a data section k in the file record being not 0”, stated on page 6 and filed 07 January 2026, have been fully considered but they are not persuasive.
Initially, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., address comparison between any two parties) are not recited in the rejected claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In particular, the claims do not indicate any specific type or step of address comparison. The claims only indicate that the addresses are to be different. In Wilson’s case, each entity may have an address and, therefore, they are different addresses.
Wilson discloses different entities in a blockchain system, e.g., a custodian, broker dealer, and an investor. Each entity may have an address, e.g., an Ethereum address, that is owned by the particular entity—data owner and sender have different addresses-- (Para. 76). In this system, the broker dealer purchases or sells tokens and the custodian holds custody or ownership of tokens—the file record is not 0 and a data section in the file record is not 0--.
Nadeau discloses multiple users each with a different public key, e.g., an address (Para. 99)—data owner and sender have different addresses--.
Nadeau further discloses using the symmetric key to encrypt the document, and storing the symmetric key in the payload of block 704 (Para. 99)—the file record is not 0 and a data section in the file record is not 0--.
Examiner note: The “sender” may be interpreted to be any entity that sends provides anything to anywhere. The examiner suggests clarifying the “sender” language of the independent claims.
Examiner note: the Broadest Reasonable Interpretation (BRI) of “the file record being not 0” and “a data section k in the file record being not 0” includes the file merely comprising data, as in, the file including data indicates that it is not 0. The examiner suggests clarifying the file record not being “0” and the data section not being “0” language.
Therefore, the aforementioned limitations are taught by the combination of the cited prior art.
Applicant’s arguments, see page 6, filed 07 January 2026, with respect to the rejections of claims 1 and 5 under 35 U.S.C. 103 have been fully considered and are persuasive in view of the new claim amendments. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Aschauer et al. (US 2020/0127860 A1), Wilson et al. (US 2020/0051069 A1), Nadeau et al. (US 2022/0129443 A1), and Metzler et al. (US 2023/0259640 A1).
See the 35 U.S.C. 103 rejection below for a detailed analysis.
Examiner note: the Broadest Reasonable Interpretation (BRI) of a “one-time” key is a key that may be used a single time or be utilized for a single session, single file, single block, etc. The examiner suggests clarifying the “one-time” aspect of the key in the independent claims.
Claim Objections
Claim 1 and 5 are objected to because of the following informalities:
Regarding claim 1, lines 12-13—“the data structure”, lacks sufficient antecedent basis for the claim. In order to overcome this objection, lines 12-13 may be amended to state --a data structure--, for example.
Claim 5 includes similar language and is similarly analyzed.
Regarding claim 1, line 13—“the block”, lacks sufficient antecedent basis for the claim. In order to overcome this objection, line 13 may be amended to state --a block--, for example.
Claim 5 includes similar language and is similarly analyzed.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 5, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Aschauer et al. (US 2020/0127860 A1) in view of Wilson et al. (US 2020/0051069 A1) in view of Nadeau et al. (US 2022/0129443 A1) and further in view of Metzler et al. (US 2023/0259640 A1).
Regarding claim 1, Aschauer teaches a method for generating a timestamp, comprising:
obtaining a file record, e.g., a digital document 2 is made available to the time stamp apparatus 1 (Fig. 2, el. 1, 2; Para. 73);
calculating a hash value of the file record, e.g., in step S1, the first unit 11 of the time stamp apparatus 1 generates a nonce value 20 by means of a pseudorandom number generator, concatenates the nonce value 20 with the document 2 and determines a first hash value 30, by applying a hash function h(x) to the result of the concatenation (Fig. 1, el. S1; Fig. 2, el. 11, 20, 30; Para. 74); in step S1 (cf. FIG. 1), the first unit 111 of the time stamp apparatus 10 generates the nonce value 20, obtains a local time (90 in FIG. 6) from the local timer 114, concatenates the nonce value 20 with the local time (90 in FIG. 6) and the document 2 and determines the first hash value 30 according to formula VII by applying an SHA256 hash function h(x) to the result of the concatenation (Fig. 5, el. 10, 111; Para. 106);
sending the hash value to a random signer, e.g., time servers 80-88 (Figs. 2, and 5), wherein one of the plurality of time servers is selected in the respective steps b1) according to a predefined order or randomly (Para. 48); the allocation of a respective time server to one of the groups and the order of the time servers 80-88 within the groups are randomly determined by the time stamp apparatus 1 (Para. 104); in step S2, the second unit 12 of the time stamp apparatus 1 selects the first time server 80 and transmits the first hash value 30, as the current hash value, to the first time server 80 (Fig. 1, el. 12; Fig. 2, el. 80; Para. 76); in step S2, the second unit 112 of the time stamp apparatus 10 selects the plurality of first time servers 80, 81, 82 and transmits the first hash value 30 to each of the first time servers 80, 81, 82 (Fig. 5, el. 80, 81, 82, 112; Para. 108), and
receiving a signature result returned by the random signer, wherein the signature result is generated in a case that the random signer signs the hash value and a receiving time instant, and the receiving time instant is a time instant when the random signer receives the hash value, e.g., the second unit 12 of the time stamp apparatus receives the response 40 from the first time server 80 (Fig. 2, el. 40; Para. 78), wherein in response to the transmission of the hash value 30, the time server 80 generates a time specification 50 denoting a current system time t0 of the time server 80, concatenates the value 30 with the time specification 50 and signs the data sequence concatenated in such a manner in order to generate a digital signature 60, and the time server transmits the response 40 comprising the time specification 50 and the digital signature 60 as a concatenated data sequence (Fig. 2, el. 50, 60; Para. 77); the unit 112 receives a respective response 40, 41, 42 from each of the first time servers 80, 81, 82, wherein each of the responses 40, 41, 42 comprises a digital signature 60, 61, 62 (cf. FIG. 6) of the hash value 30, wherein a respective digital signature 60-68 respectively comprises a time specification 50-58 as part of the respective digital signature 60-68 (Fig. 5, el. 40, 41, 42; Para. 108);
storing, in response to…the file record being not 0, and a data section k in the file record being not 0…into a blockchain, e.g., a digital document 2 is made available to the time stamp apparatus 1 (Fig. 2, el. 1, 2; Para. 73); if one of the time specifications included in the cryptographic time stamp does not satisfy the consistency criterion, the cryptographic time stamp can be used as proof of the unreliability of the associated time server which created the time specification which does not comply with the consistency criterion, and the proof can be published in a blockchain (Para. 40); a hash chain in is formed by the recursion in formula VI (Para. 87); a hash chain which is protected from manipulation is produced by the illustrated back-references of the respective digital signatures in the respective responses to the hash values of the respectively previous responses (Para. 89, 114);
storing the signature result in a blockchain as a timestamp of the file record, e.g., if one of the time specifications included in the cryptographic time stamp does not satisfy the consistency criterion, the cryptographic time stamp can be used as proof of the unreliability of the associated time server which created the time specification which does not comply with the consistency criterion, and the proof can be published in a blockchain (Para. 40); a plurality of time servers are queried in a parallel manner and the cryptographic time key is accordingly formed as a hash chain from blocks of responses from a plurality of time servers in each case (Para. 51); a hash chain in is formed by the recursion in formula VI (Para. 87); a hash chain which is protected from manipulation is produced by the illustrated back-references of the respective digital signatures in the respective responses to the hash values of the respectively previous responses (Para. 89, 114); and
….
Aschauer does not clearly teach storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain; and
wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block.
Wilson teaches storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0…into a blockchain, e.g., any smart contracts implementing the global registry 108 may be executed by a virtual machine (e.g., the Ethereum Virtual Machine) running on a network node 140 (Fig. 1, el. 108; Para. 86); Smart contracts may be executed by a processor on a network node implementing a distributed ledger, e.g., a network node running a virtual machine, such as the Ethereum Virtual Machine (EVM) (Para. 19); the distributed ledger 122 may implement one or more blockchains to validate the data stored within the distributed ledger 122, wherein a blockchain is a verifiable permanent ledger (Para. 47); one or more data structures 110 may be stored in the data storage smart contract 128, wherein each data structure 110 may include one or more elements 223A-M, where each element 223 corresponds to (i.e., includes information about) a particular custodian 116, broker dealer 118, or investor 120 (Fig. 1, el. 110, 116, 118, 120; Fig. 2A, el. 223A-M; Para. 73); each storage slot 215 may include a key 219A-N and a value 221A-N, i.e., a key/value pair, wherein each key 219 may be a nested structure with a first level indicating the type of entity the element 223 corresponds to (e.g., custodian 116, broker dealer 118, investor 120, etc.) and a second level that indicates an address (e.g., Ethereum address) owned by the particular entity (Fig. 2A, el. 215, 219A-N, 221A-N, 223; Para. 76); the broker dealer 118—sender-- in the system 100 may be a person or entity that purchases or sells tokens for its own account and/or on behalf of its customers (Para. 39); the custodian 116—owner-- may be a person or entity that holds custody, possession, and/or ownership of tokens on behalf of many broker dealers 118 (Para. 41).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer to include storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, data into a blockchain, using the known method of generating a data storage smart contract that indicates at least one custodian, at least one broker dealer, and at least one investor and an address for each and storing the smart contract on the blockchain, as taught by Wilson, in combination with the timestamp blockchain system of Aschauer, for the purpose of clearly indicating each of the participating parties in data sharing using a smart contract, thereby increasing the efficiency and accuracy of the of sharing process.
Aschauer in view of Wilson does not clearly teach storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain; and
wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block.
Nadeau teaches storing, in response to…a data owner being different from a sender…, the file record, e.g., document 514 (Fig. 4, el. 514), being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain, e.g., as shown in block 704, an encrypted version of the document is stored in the payload data, wherein the encrypted version is generated by encrypting the document with a symmetric encryption key KS1, wherein an encrypted version of the symmetric encryption key E(KS1) may be generated by encrypting the symmetric encryption key KS1 with a public key of a public-private key pair, wherein the encrypted symmetric encryption key E(KS1) is stored in the payload data for this block 704, and block 710 has an encrypted second version of the document stored in its payload data, where the encrypted version is generated by encrypting the second version of the document with a second symmetric encryption key KS2 (Fig. 7B, el. 704, 710; Para. 99); and
wherein the symmetric key is a one-time symmetric key, e.g., the symmetric encryption key may vary with time and/or with each additional block added to a given blockchain, wherein the symmetric encryption key may be generated each time a document or new version of a document is to be stored in a block, and the symmetric encryption key may be generated each time a new block is to be added, and is used in the encryption of the payload data of each block (Para. 99), and
is written into the data structure…in the block, e.g., as shown in block 704, an encrypted version of the document is stored in the payload data, wherein the encrypted version is generated by encrypting the document with a symmetric encryption key KS1, wherein an encrypted version of the symmetric encryption key E(KS1) may be generated by encrypting the symmetric encryption key KS1 with a public key of a public-private key pair, wherein the encrypted symmetric encryption key E(KS1) is stored in the payload data for this block 704 (Fig. 7B, el. 704; Para. 99).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer in view of Wilson to include storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain; and wherein the symmetric key is a one-time symmetric key and is written into the data structure in the block, using the known method of encrypting a document with a symmetric key and storing the key and the document in the block, wherein the key may be generated each time a new document or new version of a document is to be stored in the block, as taught by Nadeau, in combination with the timestamp blockchain system of Aschauer in view of Wilson, for the purpose of increasing the security of the stored data while providing for a faster decryption of the data.
Aschauer in view of Wilson in view of Nadeau does not clearly teach wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block.
Metzler teaches wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record…, e.g., the encryption module 922 embeds each encrypted data encryption key with the encrypted file at block 1068, wherein embedding the encrypted data encryption keys with the file may include storing the encrypted data encryption keys with the encrypted file in a single file (Fig. 10B, el. 1068; Para. 466);
this data encryption key can include any type of symmetric key, and the data encryption key is unique for a file—one-time-- (Para. 460).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer in view of Wilson in view of Nadeau to include wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block, using the known method of encrypting a document with a symmetric key, embedding the key in the document, and storing the document, wherein the key may be unique for a file, as taught by Metzler, in combination with the timestamp blockchain system of Aschauer in view of Wilson in view of Nadeau, for the purpose of providing for a more accurate correlation between the encrypted document and the key used to encrypt it.
Regarding claim 5, Aschauer teaches an apparatus, e.g., time stamp apparatus 1/10 (Fig. 2, el. 1; Fig. 5, el. 10), wherein a computer program product (non-transitory computer readable storage medium having instructions, which when executed by a processor, perform actions) which causes the method explained above to be carried out on a program-controlled device (Para. 54), for generating a timestamp, comprising:
a processor and a memory, wherein the memory is configured to store program codes and transmit the program codes to the processor, e.g., a computer program product (non-transitory computer readable storage medium having instructions, which when executed by a processor, perform actions) (Para. 54); and
the processor is configured to perform:
obtaining a file record, e.g., a digital document 2 is made available to the time stamp apparatus 1 (Fig. 2, el. 1, 2; Para. 73);
calculating a hash value of the file record, e.g., in step S1, the first unit 11 of the time stamp apparatus 1 generates a nonce value 20 by means of a pseudorandom number generator, concatenates the nonce value 20 with the document 2 and determines a first hash value 30, by applying a hash function h(x) to the result of the concatenation (Fig. 1, el. S1; Fig. 2, el. 11, 20, 30; Para. 74); in step S1 (cf. FIG. 1), the first unit 111 of the time stamp apparatus 10 generates the nonce value 20, obtains a local time (90 in FIG. 6) from the local timer 114, concatenates the nonce value 20 with the local time (90 in FIG. 6) and the document 2 and determines the first hash value 30 according to formula VII by applying an SHA256 hash function h(x) to the result of the concatenation (Fig. 5, el. 10, 111; Para. 106;
sending the hash value to a random signer, e.g., time servers 80-88 (Figs. 2, and 5), wherein one of the plurality of time servers is selected in the respective steps b1) according to a predefined order or randomly (Para. 48); the allocation of a respective time server to one of the groups and the order of the time servers 80-88 within the groups are randomly determined by the time stamp apparatus 1 (Para. 104); in step S2, the second unit 12 of the time stamp apparatus 1 selects the first time server 80 and transmits the first hash value 30, as the current hash value, to the first time server 80 (Fig. 1, el. 12; Fig. 2, el. 80; Para. 76); in step S2, the second unit 112 of the time stamp apparatus 10 selects the plurality of first time servers 80, 81, 82 and transmits the first hash value 30 to each of the first time servers 80, 81, 82 (Fig. 5, el. 80, 81, 82, 112; Para. 108), and
receiving a signature result returned by the random signer, wherein the signature result is generated in a case that the random signer signs the hash value and a receiving time instant, and the receiving time instant is a time instant when the random signer receives the hash value, e.g., the second unit 12 of the time stamp apparatus receives the response 40 from the first time server 80 (Fig. 2, el. 40; Para. 78), wherein in response to the transmission of the hash value 30, the time server 80 generates a time specification 50 denoting a current system time t0 of the time server 80, concatenates the value 30 with the time specification 50 and signs the data sequence concatenated in such a manner in order to generate a digital signature 60, and the time server transmits the response 40 comprising the time specification 50 and the digital signature 60 as a concatenated data sequence (Fig. 2, el. 50, 60; Para. 77); the unit 112 receives a respective response 40, 41, 42 from each of the first time servers 80, 81, 82, wherein each of the responses 40, 41, 42 comprises a digital signature 60, 61, 62 (cf. FIG. 6) of the hash value 30, wherein a respective digital signature 60-68 respectively comprises a time specification 50-58 as part of the respective digital signature 60-68 (Fig. 5, el. 40, 41, 42; Para. 108); and
storing, in response to…the file record being not 0, and a data section k in the file record being not 0…into a blockchain, e.g., a digital document 2 is made available to the time stamp apparatus 1 (Fig. 2, el. 1, 2; Para. 73); if one of the time specifications included in the cryptographic time stamp does not satisfy the consistency criterion, the cryptographic time stamp can be used as proof of the unreliability of the associated time server which created the time specification which does not comply with the consistency criterion, and the proof can be published in a blockchain (Para. 40); a hash chain in is formed by the recursion in formula VI (Para. 87); a hash chain which is protected from manipulation is produced by the illustrated back-references of the respective digital signatures in the respective responses to the hash values of the respectively previous responses (Para. 89, 114);
storing the signature result in the blockchain as a timestamp of the file record, e.g., if one of the time specifications included in the cryptographic time stamp does not satisfy the consistency criterion, the cryptographic time stamp can be used as proof of the unreliability of the associated time server which created the time specification which does not comply with the consistency criterion, and the proof can be published in a blockchain (Para. 40); a plurality of time servers are queried in a parallel manner and the cryptographic time key is accordingly formed as a hash chain from blocks of responses from a plurality of time servers in each case (Para. 51); a hash chain in is formed by the recursion in formula VI (Para. 87); a hash chain which is protected from manipulation is produced by the illustrated back-references of the respective digital signatures in the respective responses to the hash values of the respectively previous responses (Para. 89, 114); and
….
Aschauer does not clearly teach storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain; and
wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block.
Wilson teaches storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0…into a blockchain, e.g., any smart contracts implementing the global registry 108 may be executed by a virtual machine (e.g., the Ethereum Virtual Machine) running on a network node 140 (Fig. 1, el. 108; Para. 86); Smart contracts may be executed by a processor on a network node implementing a distributed ledger, e.g., a network node running a virtual machine, such as the Ethereum Virtual Machine (EVM) (Para. 19); the distributed ledger 122 may implement one or more blockchains to validate the data stored within the distributed ledger 122, wherein a blockchain is a verifiable permanent ledger (Para. 47); one or more data structures 110 may be stored in the data storage smart contract 128, wherein each data structure 110 may include one or more elements 223A-M, where each element 223 corresponds to (i.e., includes information about) a particular custodian 116, broker dealer 118, or investor 120 (Fig. 1, el. 110, 116, 118, 120; Fig. 2A, el. 223A-M; Para. 73); each storage slot 215 may include a key 219A-N and a value 221A-N, i.e., a key/value pair, wherein each key 219 may be a nested structure with a first level indicating the type of entity the element 223 corresponds to (e.g., custodian 116, broker dealer 118, investor 120, etc.) and a second level that indicates an address (e.g., Ethereum address) owned by the particular entity (Fig. 2A, el. 215, 219A-N, 221A-N, 223; Para. 76); the broker dealer 118—sender-- in the system 100 may be a person or entity that purchases or sells tokens for its own account and/or on behalf of its customers (Para. 39); the custodian 116—owner-- may be a person or entity that holds custody, possession, and/or ownership of tokens on behalf of many broker dealers 118 (Para. 41).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer to include storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, data into a blockchain, using the known method of generating a data storage smart contract that indicates at least one custodian, at least one broker dealer, and at least one investor and an address for each and storing the smart contract on the blockchain, as taught by Wilson, in combination with the timestamp blockchain system of Aschauer, for the purpose of clearly indicating each of the participating parties in data sharing using a smart contract, thereby increasing the efficiency and accuracy of the of sharing process.
Aschauer in view of Wilson does not clearly teach storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain; and
wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block.
Nadeau teaches storing, in response to…a data owner being different from a sender…, the file record, e.g., document 514 (Fig. 4, el. 514), being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain, e.g., as shown in block 704, an encrypted version of the document is stored in the payload data, wherein the encrypted version is generated by encrypting the document with a symmetric encryption key KS1, wherein an encrypted version of the symmetric encryption key E(KS1) may be generated by encrypting the symmetric encryption key KS1 with a public key of a public-private key pair, wherein the encrypted symmetric encryption key E(KS1) is stored in the payload data for this block 704, and block 710 has an encrypted second version of the document stored in its payload data, where the encrypted version is generated by encrypting the second version of the document with a second symmetric encryption key KS2 (Fig. 7B, el. 704, 710; Para. 99); and
wherein the symmetric key is a one-time symmetric key, e.g., the symmetric encryption key may vary with time and/or with each additional block added to a given blockchain, wherein the symmetric encryption key may be generated each time a document or new version of a document is to be stored in a block, and the symmetric encryption key may be generated each time a new block is to be added, and is used in the encryption of the payload data of each block (Para. 99), and
is written into the data structure…in the block, e.g., as shown in block 704, an encrypted version of the document is stored in the payload data, wherein the encrypted version is generated by encrypting the document with a symmetric encryption key KS1, wherein an encrypted version of the symmetric encryption key E(KS1) may be generated by encrypting the symmetric encryption key KS1 with a public key of a public-private key pair, wherein the encrypted symmetric encryption key E(KS1) is stored in the payload data for this block 704 (Fig. 7B, el. 704; Para. 99).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer in view of Wilson to include storing, in response to an address of a data owner being different from a sender address, the file record being not 0, and a data section k in the file record being not 0, a symmetric key for performing an encryption operation on the file record into a blockchain; and wherein the symmetric key is a one-time symmetric key and is written into the data structure in the block, using the known method of encrypting a document with a symmetric key and storing the key and the document in the block, wherein the key may be generated each time a new document or new version of a document is to be stored in the block, as taught by Nadeau, in combination with the timestamp blockchain system of Aschauer in view of Wilson, for the purpose of increasing the security of the stored data while providing for a faster decryption of the data.
Aschauer in view of Wilson in view of Nadeau does not clearly teach wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block.
Metzler teaches wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record…, e.g., the encryption module 922 embeds each encrypted data encryption key with the encrypted file at block 1068, wherein embedding the encrypted data encryption keys with the file may include storing the encrypted data encryption keys with the encrypted file in a single file (Fig. 10B, el. 1068; Para. 466);
this data encryption key can include any type of symmetric key, and the data encryption key is unique for a file—one-time-- (Para. 460).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer in view of Wilson in view of Nadeau to include wherein the symmetric key is a one-time symmetric key and is written into the data structure of the file record in the block, using the known method of encrypting a document with a symmetric key, embedding the key in the document, and storing the document, wherein the key may be unique for a file, as taught by Metzler, in combination with the timestamp blockchain system of Aschauer in view of Wilson in view of Nadeau, for the purpose of providing for a more accurate correlation between the encrypted document and the key used to encrypt it.
Regarding claim 10, Aschauer in view of Wilson in view of Nadeau in view of Metzler teaches a non-transitory computer-readable storage medium, storing program codes, wherein the program codes are used to perform the method for generating a timestamp according to claim 1, e.g., time stamp apparatus 1/10 (Aschauer-Fig. 2, el. 1; Fig. 5, el. 10), wherein a computer program product (non-transitory computer readable storage medium having instructions, which when executed by a processor, perform actions) which causes the method explained above to be carried out on a program-controlled device (Aschauer-Para. 54).
Claims 2-4 and 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over Aschauer in view of Wilson in view of Nadeau in view of Metzler and further in view of Kass (US 2020/0076625 A1).
Regarding claim 2, Aschauer in view of Wilson in view of Nadeau in view of Metzler teaches the method according to claim 1.
Aschauer further teaches wherein the storing the signature result in a blockchain as a timestamp of the file record, e.g., if one of the time specifications included in the cryptographic time stamp does not satisfy the consistency criterion, the cryptographic time stamp can be used as proof of the unreliability of the associated time server which created the time specification which does not comply with the consistency criterion, and the proof can be published in a blockchain (Aschauer-Para. 40); a plurality of time servers are queried in a parallel manner and the cryptographic time key is accordingly formed as a hash chain from blocks of responses from a plurality of time servers in each case (Aschauer-Para. 51); a hash chain in is formed by the recursion in formula VI (Aschauer-Para. 87); a hash chain which is protected from manipulation is produced by the illustrated back-references of the respective digital signatures in the respective responses to the hash values of the respectively previous responses (Aschauer-Para. 89, 114), comprises:
…, and
storing…the timestamp in the blockchain…, e.g., if one of the time specifications included in the cryptographic time stamp does not satisfy the consistency criterion, the cryptographic time stamp can be used as proof of the unreliability of the associated time server which created the time specification which does not comply with the consistency criterion, and the proof can be published in a blockchain (Aschauer-Para. 40); a plurality of time servers are queried in a parallel manner and the cryptographic time key is accordingly formed as a hash chain from blocks of responses from a plurality of time servers in each case (Aschauer-Para. 51); a hash chain in is formed by the recursion in formula VI (Aschauer-Para. 87); a hash chain which is protected from manipulation is produced by the illustrated back-references of the respective digital signatures in the respective responses to the hash values of the respectively previous responses (Aschauer-Para. 89, 114).
Aschauer in view of Wilson does not clearly teach wherein the storing the signature result in a blockchain as a timestamp of the file record comprises:
obtaining the symmetric key;
encrypting the file record by using the symmetric key to obtain ciphertext of the file record; and
storing the ciphertext and the timestamp in the blockchain through a preset smart contract.
Nadeau teaches wherein the storing the signature result in a blockchain as a timestamp of the file record, e.g., the new block may be generated by obtaining the hash signature of the last block of the blockchain 512 prior to the addition of this new block, storing the current version of the document in the payload data of this new block, generating a current hash signature of the payload data of this new block, and storing the current hash signature and the previous hash signature in the metadata of this new block, and other information may be stored in the metadata and/or payload data of the new block, wherein the metadata of the new block may further comprise a timestamp of the date and time that the new block was generated (Fig. 7B, el. 512; Para. 142), comprises:
obtaining the symmetric key, e.g., step 1022, comprises generating an encrypted version of the current version of the document 514 based on encrypting the current version of the document 514 with a symmetric encryption key (e.g., the symmetric encryption key KS2) (Fig. 10C, el. 1022; Para. 143);
encrypting the file record by using the symmetric key to obtain ciphertext of the file record, e.g., step 1022, comprises generating an encrypted version of the current version of the document 514 based on encrypting the current version of the document 514 with a symmetric encryption key (e.g., the symmetric encryption key KS2) (Fig. 10C, el. 1022; Para. 143); and
storing the ciphertext and the timestamp in the blockchain…, e.g., storing in the new block the encrypted version of the new current of the document 514 and the encrypted version of symmetric key (Para. 143), wherein the metadata of the new block may further comprise a timestamp of the date and time that the new block was generated (Para. 142).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer in view of Wilson to include wherein the storing the signature result in a blockchain as a timestamp of the file record comprises: storing the ciphertext and the timestamp in the blockchain, using the known method of encrypting the document with a symmetric key and storing the encrypted document, the encrypted symmetric key, and a timestamp in the new block, as taught by Nadeau, in combination with the timestamp blockchain system of Aschauer in view of Wilson, using the same motivation as in claim 1.
Aschauer in view of Wilson in view of Nadeau in view of Metzler does not clearly teach wherein the storing the signature result in a blockchain as a timestamp of the file record comprises:
storing the ciphertext and the timestamp in the blockchain through a preset smart contract.
Kass teaches wherein the storing the signature result in a blockchain as a timestamp of the file record, e.g., The processor 104 may fetch, decode, and execute the machine-readable instructions 124 to forward the time/hash signed by the TSA 103 to the blockchain 106 to be recorded for validation (Fig. 1, el. 103, 104, 106, 124; Para. 42), comprises:
…; and
storing…ciphertext and the timestamp in the blockchain through a preset smart contract, e.g., the smart contract may write data to the blockchain in the format of key-value pairs, wherein data written to the blockchain can be public and/or can be encrypted and maintained as private (Para. 48).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer in view of Wilson in view of Nadeau in view of Metzler to include storing the ciphertext and the timestamp in the blockchain through a preset smart contract, using the known method of utilizing a smart contract to write the data to the blockchain, wherein the data written to the blockchain can be public and/or can be encrypted, as taught by Kass, in combination with the timestamp blockchain system of Aschauer in view of Wilson in view of Nadeau in view of Metzler, for the purpose of enabling the process of writing data to the blockchain to use the automated features of the smart contract while also providing better consistency for what data is allowed to be written and how the data is written to the blockchain by using the specific rules of the smart contract.
Regarding claim 3, Aschauer in view of Wilson in view of Nadeau in view of Metzler in view of Kass teaches the method according to claim 2, further comprising: obtaining, on receipt of a verification request for the timestamp from a verifier, record information corresponding to the timestamp, e.g., a time-stamped digital document 4 is formed from the digital document 2 and the cryptographic time stamp 3 and is submitted, at any desired later time, to an apparatus 5 for checking time stamps, which apparatus 5 checks the time stamp 3 of the time-stamped digital document 4 (Aschauer-Para. 95); and
obtaining a public key of the file record, and verifying the record information by using the file record and the public key, e.g., the apparatus 5 then checks the first response 40 by checking whether the first digital signature 60 from the response 40 from the first time server 80 is a valid digital signature of a concatenation of the current hash value with the time specification 50, wherein this check is carried out on the basis of the public key associated with the private key 70 of the first time server 80 (Aschauer-Para. 98); if the check has revealed that all digital signatures 60, 61, 62, for which the apparatus 5 knows and trusts the associated public keys 70, 71, 72, are valid, the apparatus 5 checks the time specifications 50, 51, 52 for consistency, and if the time specifications 50, 51, 52 are consistent, the apparatus 5 determines that the time stamp is valid and, on the basis of the time specifications 50, 51, 52, determines a time at which the time-stamped document 4 was originally submitted for time stamping (Aschauer-Para. 101);
Also note Nadeau discloses the document access request or an audit request is transmitted by the document authoring application 102 to the document management system 104. The document management system 104 identifies the data structure 510 corresponding to the data structure reference 508 (e.g., the blockchain 512 corresponding to the blockchain reference 508), and then obtains the document 514. The document management system 104 then transmits a temporary file 516 corresponding to the document 514 to the document authoring application 102. The temporary file 516 comprises data 518 comprising the contents 520 of the document 514, and metadata 522 comprising the reference 508. A first panel 528 of the graphical user interface window 526 is configured to display the contents 520 of the document 514 obtained from the temporary file 516 and a second panel 530 of the graphical user interface window 526 is configured to display document information and/or an audit trail for the document 514 (Para. 78).
Regarding claim 4, Aschauer in view of Wilson in view of Nadeau in view of Metzler in view of Kass teaches the method according to claim 3.
Aschauer further teaches wherein the record information comprises an error code, the signature result…, e.g., a time-stamped digital document 4 is formed from the digital document 2 and the cryptographic time stamp 3 (Aschauer-Para. 95), wherein the cryptographic time stamp 3 comprises the nonce value 20 (N in formulae I and IV) and the plurality of responses 40, 41, 42, wherein each of the responses 40, 41, 42 respectively comprises a time specification 50, 51, 52 and a digital signature 60, 61, 62 (Aschauer-Para. 89).
Aschauer in view of Wilson does not clearly teach wherein the record information comprises an error code, the signature result, the ciphertext, block time in the blockchain and the symmetric key.
Nadeau further teaches wherein the record information comprises an error code, the signature result, the ciphertext, block time in the blockchain and the symmetric key, e.g., storing in the new block the encrypted version of the new current of the document 514 and the encrypted version of symmetric key (Para. 143), wherein the new block includes the current hash signature—error code/digital signature-- and the previous hash signature—error code/digital signature-- in the metadata of this new block, a timestamp of the date and time that the new block was generated (Para. 142).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Aschauer in view of Wilson to include wherein the record information comprises an error code, the signature result, the ciphertext, block time in the blockchain and the symmetric key, using the known method of storing the encrypted document, the encrypted symmetric key, a previous hash signature, a current hash signature, and a timestamp in the new block, as taught by Nadeau, in combination with the timestamp blockchain system of Aschauer in view of Wilson, using the same motivation as in claim 1.
Regarding claim 6, the claim is analyzed with respect to claim 2.
Regarding claim 7, Aschauer in view of Wilson in view of Nadeau in view of Metzler in view of Kass teaches the apparatus according to claim 6, the processor is further configured to perform: obtaining, on receipt of a verification request for the timestamp from a verifier, record information corresponding to the timestamp, e.g., a time-stamped digital document 4 is formed from the digital document 2 and the cryptographic time stamp 3 and is submitted, at any desired later time, to an apparatus 5 for checking time stamps, which apparatus 5 checks the time stamp 3 of the time-stamped digital document 4 (Aschauer-Para. 95); and
obtaining a public key of the file record, and verifying the record information by using the file record and the public key, e.g., the apparatus 5 then checks the first response 40 by checking whether the first digital signature 60 from the response 40 from the first time server 80 is a valid digital signature of a concatenation of the current hash value with the time specification 50, wherein this check is carried out on the basis of the public key associated with the private key 70 of the first time server 80 (Aschauer-Para. 98); if the check has revealed that all digital signatures 60, 61, 62, for which the apparatus 5 knows and trusts the associated public keys 70, 71, 72, are valid, the apparatus 5 checks the time specifications 50, 51, 52 for consistency, and if the time specifications 50, 51, 52 are consistent, the apparatus 5 determines that the time stamp is valid and, on the basis of the time specifications 50, 51, 52, determines a time at which the time-stamped document 4 was originally submitted for time stamping (Aschauer-Para. 101);
Nadeau further discloses when the user requests to open the virtual file 504 (e.g., double clicks on the virtual file 504 or makes a request to open the virtual file 504 with the document authoring application 102), a request is made for the document 514 corresponding to the virtual file 504 (referred herein as the “document access request”), wherein the document access request or an audit request is transmitted by the document authoring application 102 to the document management system 104 (Para. 78); wherein the metadata of the new block may further comprise a timestamp of the date and time that the new block was generated (Para. 142). A first panel 528 of the graphical user interface window 526 is configured to display the contents 520 of the document 514 obtained from the temporary file 516 and a second panel 530 of the graphical user interface window 526 is configured to display document information and/or an audit trail for the document 514 (Para. 78).
Regarding claim 8, the claim is analyzed with respect to claim 4.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zhang et al. “Chronos: Secure and Accurate Time-stamping Scheme for Digital Files via Blockchain” discloses in Chronos, when a file is created, the file and a sufficient number of successive blocks that are latest confirmed on blockchain are integrated into a transaction. The time when the last block was chained to the blockchain serves as the earliest creation time of the file. The time when the block including the transaction was chained indicates the latest creation time of the file. Therefore, Chronos makes the file's creation time corresponding to this time interval (Abstract).
Ha et al. (US 2023/0261886 A1)—Ha discloses the processor 113 may generate a proposal block based on the second transaction and the second contract through the blockchain platform 323, by executing the data sharing APP 321, and may examine validity of the proposal block, wherein the blockchain platform 323 may synchronize the proposal block (Fig. 1, el. 113; Fig. 9, el. 321, 323; Para. 117). The application 324 may provide data to share, wherein the application 324 may provide a photo, a video, and/or document data (Fig. 9, el. 324; Para. 110). The second transaction may generate a second contract (for example, a second smart contract) containing detailed information regarding data sharing, wherein the second contract may include at least one of a unique ID of data sharing, a data sharing blockchain network ID, a symmetric key used for encryption of data, an address of a person sending data (second transaction generator), an address of a person receiving data, data in which a data download address is encrypted with a symmetric key, a data name, data authority, a data sharing time, a data access expiration date and/or a state of shared data (Para. 114).
Spangenberg et al. (US 2020/0334773 A1)—Spangenberg discloses creating transparency in (i) patent ownership, (ii) patent identification and (iii) patent coverage and value. In addition, by providing the network, a guaranteed buy program can be initiated that provides specific guaranteed value to intellectual property assets listed by verified brokers (Abstract).
Jing (US 2021/0272108 A1)—Jing discloses receiving a data deposit transaction request initiated by a deposit requester based on deposit data, a credible timestamp of the deposit data obtained in advance and a digital signature of a timestamp provider that provides the credible timestamp, wherein the credible timestamp is obtained by the timestamp provider from a timestamp server of the deposit requester; and determining that the credible timestamp of the deposit data is valid when the digital signature matches the deposit data, executing the data deposit transaction request, and storing the deposit data and the credible timestamp of the deposit data in a block-chain network (Abstract).
Hofstee et al. (US 2020/0169425 A1)—Hofstee discloses author 214 provides a hash value of digital file 231 to timestamping system 216. For the current interval, timestamping system 216 signs digital file 231, or in some cases the hash value of digital file 231, with the interval private key 232 of the current interval 221. Timestamping system 216 sends the signed digital file 233 to author 214. Either timestamping system 216 or blockchain network 218 sends or include in the signed digital file 231 an interval or block number, used by for locating the public key in key blockchain 136 (Para. 48).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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.
27 January 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498