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
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statements (IDS) submitted are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Election/Restrictions
Claims 8-13 and 21-26 are withdrawn from further consideration pursuant to 37 CFR 1.142(b), as being drawn to a nonelected invention, there being no allowable generic or linking claim. Applicant timely traversed the restriction (election) requirement in the reply filed on November 5, 2025.
Applicant's election with traverse of claims 1-7 and 14-20 in the reply filed on November 5, 2025 is acknowledged. The traversal is on the grounds that Invention I and Invention II are not independent, and are related to related concepts. This is not found persuasive because:
With respect to the Applicant’s arguments pertaining to Invention I: “the attestation information is used to remotely attest whether the first node is trusted,” and Invention II: attestation information … is used to obtain an attestation result indicating whether the first node is trusted”.
The Examiner agrees with the Applicant’s statement that they related concepts, however the claims recite additional elements not addressed by the Applicant, namely subcombination I is directed towards registering or determining by a first node attestation information to be used for remotely attesting whether the first node is trusted and subcombination II is directed towards a second node obtaining attestation information about a first node, then verifying by the second node the attestation information that indicates if the first node is trusted.
Inventions I and II are related as subcombinations disclosed as usable together in a single combination. The subcombinations are distinct if they do not overlap in scope and are not obvious variants, and if it is shown that at least one subcombination is separately usable. Invention I recites of a first node determining attestation information used to remotely attest whether the first node is trusted and Invention II recites of a second node verifying attestation information indicating whether a first node is trusted. Although similar, separate searching of different CPC groups and subgroups and different search strategies and different search queries would be required for subcombination I and II.
The subcombinations are distinct from one another and are not inherently linked as argued by the Applicant, the restriction is proper and is hereby maintained by the Examiner.
The requirement is still deemed proper and is therefore made FINAL.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3, 5, 14, and 16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Qiu, U.S. Patent 11,093,651.
As per claim 1, it is taught of a method for trusted attestation, comprising:
obtaining, by a first node, information about a first blockchain (a client device deployed in an application system is designated to implement a blockchain protocol (i.e., sending and obtaining blockchain information as is taught in col. 2, lines 30-31) and can authenticate data in the blockchain system, col. 3, lines 52-57, wherein it is further disclosed of Intel® SGX is selected as core logic in a TEE to implement a client device of a blockchain system, the TEE program or TEE application itself can authenticate data on a blockchain with the client device publishing the data, col. 5, lines 1-5. The Examiner is interpreting the client device with the TEE application program as the first node); and
determining, by the first node, attestation information based on the information about the first blockchain (the client device (Examiner is interpreting the client device with the TEE application program as the first node) can publish (via determination) a code measurement value (i.e., attestation information) of the TEE program used to attest to the external that the TEE will honestly authenticate data on blockchains, col. 5, lines 5-9 and col. 12, lines 49-53, and (the client device can publish (via determination) parameters for initialization of the TEE program (i.e., attestation information), information about a blockchain that the client device is connected to is, col. 5, lines 5-6 & 17-19 and col. 12, lines 49-53), wherein the attestation information is used to remotely attest whether the first node is trusted (the client device (Examiner is interpreting the client device with the TEE application program as the first node) can publish (via determination) remote attestation information of the TEE, where an attester can request a corresponding remote attester to verify whether the types of information are from the client device of the TEE, col. 5, lines 5-9, 17-25 and col. 12, lines 49-53).
As per claim 3, it is taught or further comprising: sending, by the first node, the attestation information to the first blockchain (the client device (Examiner is interpreting the client device with the TEE application program as the first node) interacts (i.e., sending/receiving) with the a blockchain, col. 3, lines 53-57, wherein the client device can publish (i.e., sending) a code measurement value (i.e., attestation information) of the TEE program used to attest to the external that the TEE will honestly authenticate data on blockchains, col. 5, lines 5-9, and the client device can publish (i.e., sending) parameters for initialization of the TEE program (i.e., attestation information), information about a blockchain that the client device is connected to is, col. 5, lines 5-6 & 17-19).
As per claim 5, it is taught wherein the first blockchain comprises a second block, and wherein:
the second block stores the attestation information (a second blockchain (i.e., second block) via an attestation module returns a signed attestation request result to the first blockchain, col. 2, lines 15-25);
or the second block stores digest information about the attestation information, wherein the digest information is used to verify integrity of the attestation information, and the attestation information is stored in an off-chain storage node (a second blockchain (i.e., second block) via an attestation module returns a signed (i.e., digest information) attestation request result to the first blockchain verifying the integrity of the attestation data stored as cross-chain data (i.e., off-chain storage node), col. 2, lines 15-25).
As per claim 14, it is disclosed of a communication apparatus, comprising:
at least one processor (col. 2, lines 26-29); and
one or more memories coupled to the at least one processor and storing programming instructions for execution by the at least one processor (client device includes a processor and memory storing processor-executable instructions, col. 2, lines 26-29) to:
obtain information about a first blockchain (a client device deployed in an application system is designated to implement a blockchain protocol (i.e., sending and obtaining blockchain information as is taught in col. 2, lines 30-31) and can authenticate data in the blockchain system, col. 3, lines 52-57, wherein it is further disclosed of Intel® SGX is selected as core logic in a TEE to implement a client device of a blockchain system, the TEE program or TEE application itself can authenticate data on a blockchain with the client device publishing the data, col. 5, lines 1-5); and
determine attestation information based on the information about the first blockchain (the client device can publish (via determination) a code measurement value of the TEE program (i.e., attestation information) used to attest to the external that the TEE will honestly authenticate data on blockchains, col. 5, lines 5-9 and col. 12, lines 49-53, and (the client device can publish (via determination) parameters for initialization of the TEE program (i.e., attestation information), information about a blockchain that the client device is connected to is, col. 5, lines 5-6 & 17-19 and col. 12, lines 49-53& 17-19), wherein the attestation information is used to remotely attest whether the communication apparatus is trusted (the client device can publish (via determination) remote attestation information of the TEE, where an attester can request a corresponding remote attester to verify whether the types of information are from the client device of the TEE, col. 5, lines 5-9, 17-25 and col. 12, lines 49-53).
As per claim 16, it is disclosed wherein the one or more memories store programming instructions for execution by the at least one processor to: send, the attestation information to the first blockchain (the client interacts (i.e., sending/receiving) with the a blockchain, col. 3, lines 53-57, wherein the client device can publish (i.e., sending) a code measurement value (i.e., attestation information) of the TEE program used to attest to the external that the TEE will honestly authenticate data on blockchains, col. 5, lines 5-9, and the client device can publish (i.e., sending) parameters for initialization of the TEE program (i.e., attestation information), information about a blockchain that the client device is connected to is, col. 5, lines 5-6 & 17-19).
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.
Claims 2 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Qiu, U.S. Patent 11,093,651 in view of Hunt et al, U.S. Patent 10,523,421.
As per claims 2 and 15, it is disclosed by Qiu wherein the information about the first blockchain comprises any one or more types, such as the client device can publish (via determination) remote attestation information of the TEE, where an attester can request a corresponding remote attester to verify whether the types of information are from the client device of the TEE, col. 5, lines 5-9, 17-25 and col. 12, lines 49-53. The teachings of Qiu further disclose of signing data to a first blockchain with a signature based upon a private key corresponding to a TEE policy, col. 2, lines 21-25.
The teachings of Qiu fail to disclose of information about the blockchain comprising any one or more types of the following information:
a timestamp of a first block,
a hash value of the first block,
a hash value of a previous block of the first block,
a hash string of a plurality of blocks comprising the first block,
a merkle tree root of the plurality of blocks comprising the first block,
a random number in the first block,
a timestamp of a first transaction,
a hash value of the first transaction, or
a hash string of a plurality of transactions comprising the first transaction,
wherein the first block is a block on the first blockchain, and the first transaction is a transaction on the first blockchain.
Hunt et al discloses of a blockchain comprising any one or more types of the following information:
a timestamp of a first block (block number includes date and time, col. 4, lines 1-2),
a hash value of the first block (hashes of all blocks in a chain, col. 3, lines 28-29),
a hash value of a previous block of the first block (each block points back to a previous block, wherein a pointer is a hash of the previous block, col. 5, lines 7-9),
a timestamp of a first transaction (block number of checkpoint (i.e., transaction) includes date and time, col. 4, lines 1-2),
a hash value of the first transaction (each block points back to a previous block, wherein a pointer is a hash of the previous block, col. 5, lines 7-9, which is interpreted as the first block (i.e., first transaction) is a genesis block that is hashed, col. 5, lines 12-15), or
wherein the first block is a block on the first blockchain, and the first transaction is a transaction on the first blockchain (a genesis block is a first block on a blockchain, wherein transactions are added and with the world state progressively filling as additional transactions are added, col. 5, lines 7-21).
It would have been obvious to a person of ordinary skill in the art at the effective filing date of the claimed invention to have been motivated to understand the nature of how blockchains operate and are governed to determine if validity is maintained throughout the process as new blocks are added to the blockchain. Hunt et al discloses that blockchains are linked blocks of transaction which secure hashes representing transactions that were successful or unsuccessful. A certified checkpoint begins by reaching an agreement on a block number that is certified, with the checkpoint being performed between two blocks which is then validated by peers using a hash value, which is then entered when a consensus is reached by the peers certifying the correctness reached at that particular checkpoint of the transaction in the ledger, col. 5, lines 22-47. Although the teachings of Qiu disclose of the use of blockchain transactions, they are absent of the details of how blockchain transactions are certified via consensus, wherein the teachings of Hunt et al provide the support to show the missing features that the teachings of Qiu would be implementing when validating block transactions on the blockchains.
Claims 4, 6, 7, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Qiu, U.S. Patent 11,093,651 in view of Sohail et al, U.S. Patent 11,507,698.
As per claim 4, Qiu fail to disclose of a first node sending the attestation information to a smart contract, wherein the smart contract is deployed on a blockchain node for the first blockchain.
In a related teaching, it is taught by Sohail et al a first node sending the attestation information to a smart contract, wherein the smart contract is deployed on a blockchain node for the first blockchain (an IoT device (i.e., first node) store/send ledger of a blockchain (i.e., first blockchain) based attestation system and executes chain code that is part of smart contracts in the ledger, col. 3, lines 40-44).
It would have been obvious to a person of ordinary skill in the art at the effective filing date of the claimed invention to have been motivated to use smart contracts for attestation blockchains. Sohail et al discloses of the smart contracts containing rules that the defined in the contracts when used in blockchain attestation systems, col. 3, lines 47-49. The smart contracts contain rules for determining whether an IoT device should be permitted to join a network, rules for generating trust score, and rules for determining whether data associated with an IoT device is valid, col. 4 line 67 through col. 5, line 9. Although the teachings of Qiu disclose of providing remote attestation information via blockchains, the teachings of Sohail add an additional layer of security by use of smart contracts to dictate conditions that attested device have to comply with to further strengthen the security policy of a system by allowing authorized devices to participate in communications with one another.
As per claim 6, it is disclosed by Sohail et al wherein the method further comprises:
registering, by the first node, identity information with the smart contract, wherein the identity information comprises an identity used to record the attestation information (a participant registry includes identifiers and other information about the users of the IoT device network, which includes a profile of registered IoT devices (i.e., nodes or first node) that is stored within a transaction registry in a blockchain based attestation system, col. 5, lines 15-37, wherein the registry is part of a smart contract, col. 6, line 60 through col. 7, line 14). Please refer above for the motivational reasons of applying the teachings of Sohail et al use of smart contracts for attestation blockchains with Qiu.
As per claim 7, it is taught by Sohail et al of further comprising:
periodically sending, by the first node, the attestation information to the smart contract (a request granted for allowing a given IoT device to join the IoT network includes updating (i.e., periodically sending) various tables that the IoT device is now part of the IoT network, col. 6, lines 22-29, wherein the blockchain attestation system associates the smart contract with the joining IoT device, col. 9, lines 6-18), wherein the smart contract sends the attestation information to the first blockchain (an IoT device (i.e., first node) store/send ledger of a blockchain (i.e., first blockchain) based attestation system and executes chain code that is part of smart contracts in the ledger, col. 3, lines 40-44); or
As per claim 17, Qiu fails to disclose of sending the attestation information to a smart contract, wherein the smart contract is deployed on a blockchain node on the first blockchain.
Sohail et al discloses of sending the attestation information to a smart contract, wherein the smart contract is deployed on a blockchain node on the first blockchain (an IoT device (i.e., first node) store/send ledger of a blockchain (i.e., first blockchain) based attestation system and executes chain code that is part of smart contracts in the ledger, col. 3, lines 40-44).
It would have been obvious to a person of ordinary skill in the art at the effective filing date of the claimed invention to have been motivated to use smart contracts for attestation blockchains. Sohail et al discloses of the smart contracts containing rules that the defined in the contracts when used in blockchain attestation systems, col. 3, lines 47-49. The smart contracts contain rules for determining whether an IoT device should be permitted to join a network, rules for generating trust score, and rules for determining whether data associated with an IoT device is valid, col. 4 line 67 through col. 5, line 9. Although the teachings of Qiu disclose of providing remote attestation information via blockchains, the teachings of Sohail add an additional layer of security by use of smart contracts to dictate conditions that attested device have to comply with to further strengthen the security policy of a system by allowing authorized devices to participate in communications with one another.
As per claim 18, it is disclosed by Qiu wherein the first blockchain comprises a second block, and wherein:
the second block stores the attestation information (a second blockchain (i.e., second block) via an attestation module returns a signed attestation request result to the first blockchain, col. 2, lines 15-25);
or the second block stores digest information about the attestation information, wherein the digest information is used to verify integrity of the attestation information, and the attestation information is stored in an off-chain storage node (a second blockchain (i.e., second block) via an attestation module returns a signed (i.e., digest information) attestation request result to the first blockchain verifying the integrity of the attestation data stored as cross-chain data (i.e., off-chain storage node), col. 2, lines 15-25).
As per claim 19, it is taught Sohail et al wherein the one or more memories store programming instructions for execution by the at least one processor to: register identity information with the smart contract, wherein the identity information comprises an identity used to record the attestation information (a participant registry includes identifiers and other information about the users of the IoT device network, which includes a profile of registered IoT devices (i.e., nodes or first node) that is stored within a transaction registry in a blockchain based attestation system, col. 5, lines 15-37, wherein the registry is part of a smart contract, col. 6, line 60 through col. 7, line 14). Please refer above for the motivational reasons of applying the teachings of Sohail et al use of smart contracts for attestation blockchains with Qiu.
As per claim 20, it is disclosed by Sohail et al wherein the one or more memories store programming instructions for execution by the at least one processor to:
periodically send the attestation information to the smart contract (a request granted for allowing a given IoT device to join the IoT network includes updating (i.e., periodically sending) various tables that the IoT device is now part of the IoT network, col. 6, lines 22-29, wherein the blockchain attestation system associates the smart contract with the joining IoT device, col. 9, lines 6-18), wherein the smart contract sends the attestation information to the first blockchain (an IoT device (i.e., first node) store/send ledger of a blockchain (i.e., first blockchain) based attestation system and executes chain code that is part of smart contracts in the ledger, col. 3, lines 40-44); or
.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yagawa, “Delegating Verification for Remote Attestation using TEE” is relied upon for disclosing of remote attestation checking the status of IoT devices from remote locations, see abstract.
Wu, CN 111090875 A is relied upon for disclosing of a client end obtaining the remote authentication report for off-blockchain privacy computing node; remote attestation report generated after calculating node generates the self recommend information to verify to off-blockchain privacy by authentication server, from recommendation information privacy with off-blockchain calculation chain creating on the node of the trusted execution environment related, the client in determining under the condition of off-blockchain privacy calculation node trusted according to remote attestation report, the encrypted byte transmitted to off-blockchain privacy chain under contract computing node trusted under chain privacy by off-blockchain computing node execution environment from decryption to obtain the byte and deployment, wherein initiating the condition of call chain under contract by prophesying machine mechanism at blockchain node, a bytecode can for deployment in the chain in the trusted execution environment, and the result can be performed by prophesying machine mechanism back to the blockchain node, see the machine translation.
Matetic et al, WO 2019/185710 A is relied upon for disclosing of prior to sending a request to the TEE, such as an SGX enclave, the lightweight blockchain client performs an attestation with the TEE, possibly accompanied by the execution of an authentication mechanism. Attestation is the process of verifying that a certain enclave code has been properly initialized. In local attestation, a prover enclave can request a statement that contains measurements of its initialization sequence, enclave code and the issuer key. Another enclave on the same platform can verify this statement using a shared key created by the processor. In remote attestation, the verifier may reside on another platform. In either case enclave attestation guarantees honest enclave execution, see page 8, lines 21-30.
Wang, US 2024/0015028 is relied upon for disclosing of trusted execution environment platform is remotely verified through the smart contracts based on the characteristics of openness, transparency, and tamper resistance of the blockchain, so that the verification process is traceable, the credibility of verification on the trusted execution environment platform is improved, and the accuracy of verification on the trusted execution environment platform is improved accordingly. Meanwhile, communication between a blockchain network and the verification service node to which the verification smart contract belongs is directly opened through the oracle smart contract and the oracle node to implement real-time verification, thereby improving the efficiency of verifying the trusted execution environment platform and reducing operation and maintenance costs, see paragraph 0018.
Yu et al, US 2020/0311312 is relied upon for disclosing of querying external data sources (e.g., Internet-based data sources) using a relay system and TEE. More particularly, and as described in further detail herein, embodiments of this specification provide for use of a smart contract to perform the TEE remote verification (remote attestation, described herein), thereby avoiding direct access by the user, or client to the relay node. In this manner, and among other advantages, the attack surface is reduced, which inhibits potential attack vectors, and the coupling between the user logic and the relay system is reduced, which enhances the scalability, and improves the data uplink service capability, see paragraph 0047.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER REVAK whose telephone number is (571)272-3794. The examiner can normally be reached 5:30am - 3:00pm.
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, Catherine Thiaw can be reached at 571-270-1138. 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.
/CHRISTOPHER A REVAK/Primary Examiner, Art Unit 2407