Notice of Pre-AIA or AIA Status
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 is in response to the original filing of 04/29/2025 and preliminary amendments filed on 02/11/2026.Claims 1, 3-4, 9, 11 and 13-14 have been amended. Claims 19 and 20 have been added. Claims 1-20 are pending and have been considered below.
Priority
19193398 filed 04/29/2025 is a Continuation of PCT/CN2022/128749, filed 10/31/2022.
Drawings
The drawings filed on 04/29/2025 are accepted.
Specification
The amendments to the specification filed on 02/11/2026 is accepted.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/30/2025 and 12/29/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1 recites the limitation "the second module" in line 7. There is insufficient antecedent basis for this limitation in the claim.
Claim 9 recites the limitation "the second module" in lines 6-7. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation "the second module" in 8. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Stafford et al U.S. 2018/0287780 A1 herein after Ford in view of Fu et al U.S. 2019/0123903 A1 herein after Fu.
Claims 1, 11: Ford teaches a communication method, a communication apparatus (Ford teaches at ¶[0005]” means for exchanging, at a network security server, information with a client device; means fort providing a network security service for the client device; and means for recording security information about the client device via a blockchain verification process”, further teaches at ¶[0035]-[0036], method 600, ¶[0037], “the network security server may provide a network security service for the client device. For example, the network security service might be an integrity attestation service providing software verification for the client device” ), comprising:
at least one processor coupled to at least one memory storing a computer program including instructions that, when executed by the processor ( ¶[0049]-[0050] The processor 1510 may further record security information about the client device via a blockchain verification process (e.g., by registering a validation result within a distributed ledger), cause the communication apparatus to perform
executing, by a first module, a first security service based on a first request message received from a requester (Ford teaches at ¶[0042] ”attestation service 1010 "communicates with host agents via an attestation protocol". Ford further teaches at ¶[0043] "A security operator may use remote devices 1070 to execute a query trust state with the attestation service 1010… the attestation service 1010 might include a trust state process, a privacy CA process, a query API process, and an appraiser process" (i.e., the service is executed in response to a received request),
wherein the first request message requests one or more trusted services (Ford teaches at ¶[0043] a security operator may use remote devices 1070 to execute a query trust state with the attestation service 1010. Ford teaches at ¶[0031] “system 500 includes a network security server 510 with a communication port to exchange information with a client device 520” ),
the requestor comprises a first node or a second node (Ford teaches at ¶[0031] ”the system 500 includes a network security server 510 with a communication port to exchange information with a client device 520.” ¶[0036] “remote client device” might refer to, for example, a PC a tablet computer, a server computer, a smartphone, a microcontroller, an embedded access point, an embedded telecommunication base station, an embedded Internet of Things (“IoT”) gateway”. Ford further teaches at ¶ [0043] “remote devices 1070 to execute a query trust state with the attestation service 1010),
the first module is a module serving the first node (Ford teaches at ¶[0004] a network security server coupled to the communication port may include a computer processor adapted to provide a network security service for the client device, ¶ [0031], the network security server 510 provides a network security service for the client device 520. Ford teaches at ¶[0048] “For example, FIG. 14 is a system 1400 implementing an attestation architecture incorporating multiple attestation servers….. an additional blockchain 1422 and attestation server 1432 may provide protection for an additional client 1442 and associated with TPM 1452…….. each attestation server 1430, 1432 may be associated with multiple blockchains”), and the second module is a module is a module serving the second node(Ford teaches at ¶[0048] “For example, FIG. 14 is a system 1400 implementing an attestation architecture incorporating multiple attestation servers….. an additional blockchain 1422 and attestation server 1432 may provide protection for an additional client 1442 and associated with TPM 1452…….. each attestation server 1430, 1432 may be associated with multiple blockchains),
and sending, by the first module, a first feedback message to the requester, wherein the first feedback message feeds back an execution result of the first security service to the requester (Ford ¶[0036]” a network security server may exchange information with a client device. According to some embodiments, the network security server may be an attestation server adapted to generate an attestation report for a plurality of remote client devices. The attestation report might include, for example, a client identifier, a recorded date and time, and an attestation status a status indicating one of a secure status, a warning status, and/or a compromised status”, ¶[0028], The display indicates a version number 110 of the attestation server along with details about one or more client devices being monitored).
Ford fails to teach, however Fu in the same field of endeavor teaches
the first security service performing at least one of the following operations: calling a security algorithm (Fu ¶[0023], obtaining a component metric algorithm according to the serial number of the first service trusted server; matching the component metric algorithm with a component value result in a preset policy library table ), obtaining a security parameter (Fu ¶[0016] obtaining the to-be-verified information of the first service trusted server in the challenge request comprises: verifying that the certificate of the first service trusted server , ¶[0020] “to obtain the respective component of the second service trusted server, the metric policy identifier corresponding to the respective component, and a component metric algorithm)”, or requesting a second security service from a second module (Fu ¶[0014] “ sending a verification request to a trusted remote proving server, wherein the verification request includes the to-be-verified information of the first service trusted server;”, ¶[0020],” sending a platform metric policy request to a trusted policy management server; wherein the platform metric policy request includes: a certificate and a serial number of a second service trusted server, and respective component of the second service trusted server and corresponding metric policy identifier encrypted through a public key of the trusted policy management server”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Ford with the additional features of Fu in order to provide trusted remote proving methods and apparatuses as suggested by Fu [0002].
Claim 9: Ford teaches a communication method, comprising:
sending, by a requester, a first request message, the first request message requests a first module to execute a first security service (Ford teaches at ¶[0042] ”attestation service 1010 "communicates with host agents via an attestation protocol". Ford further teaches at ¶[0043] "A security operator may use remote devices 1070 to execute a query trust state with the attestation service 1010… the attestation service 1010 might include a trust state process, a privacy CA process, a query API process, and an appraiser process" (i.e., the service is executed in response to a received request) , , wherein the requester comprises a first node or a second node(Ford teaches at ¶[0042] ”attestation service 1010 "communicates with host agents via an attestation protocol". Ford further teaches at ¶[0043] "A security operator may use remote devices 1070 to execute a query trust state with the attestation service 1010… the attestation service 1010 might include a trust state process, a privacy CA process, a query API process, and an appraiser process" (i.e., the service is executed in response to a received request), the first module is a module serving the first node, and the second module is a module serving the second node(Ford teaches at ¶[0048] “For example, FIG. 14 is a system 1400 implementing an attestation architecture incorporating multiple attestation servers….. an additional blockchain 1422 and attestation server 1432 may provide protection for an additional client 1442 and associated with TPM 1452…….. each attestation server 1430, 1432 may be associated with multiple blockchains); and
receiving, by the requester, a first feedback message from the first module, wherein the first feedback message feeds back an execution result of the first security service (Ford ¶[0036]” a network security server may exchange information with a client device. According to some embodiments, the network security server may be an attestation server adapted to generate an attestation report for a plurality of remote client devices. The attestation report might include, for example, a client identifier, a recorded date and time, and an attestation status a status indicating one of a secure status, a warning status, and/or a compromised status”, ¶[0028], The display indicates a version number 110 of the attestation server along with details about one or more client devices being monitored)
Ford fails to teach, however Fu in the same field of endeavor teaches
the first security service is used to perform at least one of the following operations: calling a security algorithm (Fu ¶[0023], obtaining a component metric algorithm according to the serial number of the first service trusted server; matching the component metric algorithm with a component value result in a preset policy library table ), obtaining a security parameter (Fu ¶[0016] obtaining the to-be-verified information of the first service trusted server in the challenge request comprises: verifying that the certificate of the first service trusted server , ¶[0020] “to obtain the respective component of the second service trusted server, the metric policy identifier corresponding to the respective component, and a component metric algorithm)”, or requesting a second security service from a second module (Fu ¶[0014] “ sending a verification request to a trusted remote proving server, wherein the verification request includes the to-be-verified information of the first service trusted server;”, ¶[0020],” sending a platform metric policy request to a trusted policy management server; wherein the platform metric policy request includes: a certificate and a serial number of a second service trusted server, and respective component of the second service trusted server and corresponding metric policy identifier encrypted through a public key of the trusted policy management server”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Ford with the additional features of Fu in order to provide trusted remote proving methods and apparatuses as suggested by Fu [0002].
Claims 2, 10 and 12: the combination teaches
wherein the requester is the first node, and the first request message comprises an identifier of the second node (Fu ¶[0015] ("the challenge request comprises: a certificate of the first service trusted server, a serial number and a first random number of the first service trusted server encrypted through a public key of a second service trusted server…"); Fu ¶[0017] (verification request generated "according to a certificate of the second service trusted server, a sequence number of the second service trusted server… the sequence number of the first service trusted server"); Ford ¶[0038] (smart contract transaction "records a device attestation status, a validation hash, a device identifier, and an attestation server identifier"); Ford ¶[0040] (database fields include "a client identifier, a server identifier").
The same motivation to modify Ford in view of Fu applied to claim 1, 9 and 11 above applies here.
Claims 3 and 13: the combination teaches
wherein the first security service is an authentication service; and the executing, by the first module, the first security service comprises:
executing, by the first module, the authentication service based on the first request message, to obtain a first parameter set (Fu ¶[0016] ("verifying that the certificate of the first service trusted server is legitimate; in the case where the result of the verification is legitimate, decrypting a ciphertext in the challenge request through a private key of the second service trusted server to obtain the to-be-verified information, wherein the to-be-verified information includes a serial number and a random number of the first service trusted server; in the case where the result of the verification is illegitimate, terminating operation");
sending, by the first module, a second request message to the second module through the first node and the second node, wherein the second request message comprises a second parameter set, and the second parameter set is part of the first parameter set (Fu ¶[0017] ("generating the verification request according to a certificate of the second service trusted server, a sequence number of the second service trusted server, a second random number, the sequence number of the first service trusted server, and respective component of the first service trusted server and corresponding metric policy identifier encrypted through the public key of the trusted remote proving server; sending the verification request to the trusted remote proving server") the second Fu ¶[0017] ("generating the verification request according to a certificate of the second service trusted server, a sequence number of the second service trusted server, a second random number, the sequence number of the first service trusted server, and respective component of the first service trusted server and corresponding metric policy identifier encrypted through the public key of the trusted remote proving server; sending the verification request to the trusted remote proving server") the second parameter set is expressly assembled from the first. See also Fu ¶[0018]. R1 ¶[0042] ("the attestation service 1010 (e.g., a verifier) communicates with host agents via an attestation protocol to verify the integrity of software executing at the host agents. Each host agent may include hardware/TPM 1020, a hypervisor 1022, an OS 1024, and one or more applications 1026") the module-level exchange is carried by an agent resident on the host node. Routing module-to-module messages over the hosts' existing transport is a predictable design choice;);
receiving, by the first module, a second feedback message from the second module through the first node and the second node, wherein the second feedback message comprises an authentication response, and the authentication response feeds back an authentication service result of the second module to the first module (Fu ¶[0024] ("generating the verification response according to the certificate of the trusted remote proving server, and a verification response ciphertext encrypted through a public key of the second service trusted server, wherein the verification response ciphertext includes: a random number and information of determining that the first service trusted server and a platform in which the first service trusted server is located are legitimate"); Fu ¶[0025]); and
executing, by the first module, the authentication service based on the authentication response, and sending the first feedback message to the first node, wherein the first feedback message feeds back an authentication result of the second node to the first node (Fu ¶[0019] ("verifying whether a certificate of the trusted remote proving server in the verification response is legitimate; in the case where the result of the verification is legitimate, decrypting the ciphertext through a private key of the second service trusted server to obtain an identity of the first service trusted server and legitimacy of a platform in which the first service trusted server is located"); Ford ¶[0028]/¶[0036] (result reported out as an attestation status).
The same motivation to modify Ford in view of Fu applied to claim 1 and 11 above applies here.
Claims 4 and 14: the combination teaches
wherein the first security service is a trusted attestation service (Fu ¶[0015] (challenge request carries "a serial number and a first random number of the first service trusted server encrypted through a public key of a second service trusted server"); and the executing, by the first module, the first security service comprises:
executing, by the first module, the trusted attestation service based on the first request message to obtain a challenge value(Fu ¶[0004]–[0008] (background: "TPM-Based Remote Proving (TRA)… the challenger makes a decision on whether the target's status is integrated based on the integrity evidence provided by the target"; TRAP is "an agreement involving three parties: challenger, target, and trusted platform module"). The random number is the nonce/challenge value);
sending, by the first module, a second request message to the second module, wherein the second request message comprises the challenge value (Fu ¶[0022] ("the verification request includes a certificate of the second service trusted server, and a serial number of the second service trusted server, a serial number of the first service trusted server, a random number, and a ciphertext encrypted through a public key of the trusted remote proving server"). Fu ¶[0022]-[0023] ("the ciphertext includes: respective component of the first service trusted server and a corresponding metric policy identifier; determining legitimacy of the first service trusted server");
receiving, by the first module, a second feedback message from the second module, wherein the second feedback message comprises attestation evidence, and the attestation evidence is used by the first module to verify whether the second module is trusted(Fu ¶[0022]-[0023] ("the ciphertext includes: respective component of the first service trusted server and a corresponding metric policy identifier; determining legitimacy of the first service trusted server"; "decrypting the respective component… and corresponding metric result ciphertext according to a public key of the first service trusted server… matching the component metric algorithm with a component value result in a preset policy library table to determine whether they are equal"); Ford ¶[0038] ("the TPM may sign Platform Configuration Register ('PCR') values as proof of integrity"); Ford ¶[0047] (same); Ford ¶[0029] ("an actual integrity value 220 and a reported integrity value that may be compared to determine if the controller was compromised); and
executing, by the first module, the trusted attestation service based on the attestation evidence, and sending the first feedback message to the first node, wherein the first feedback message feeds back a trusted attestation result of the second node to the first node (Fu ¶[0022]-[0023] ("the ciphertext includes: respective component of the first service trusted server and a corresponding metric policy identifier; determining legitimacy of the first service trusted server"; "decrypting the respective component… and corresponding metric result ciphertext according to a public key of the first service trusted server… matching the component metric algorithm with a component value result in a preset policy library table to determine whether they are equal"); Ford ¶[0038] ("the TPM may sign Platform Configuration Register ('PCR') values as proof of integrity"); Ford ¶[0047] (same); Ford ¶[0029] ("an actual integrity value 220 and a reported integrity value that may be compared to determine if the controller was compromised).
The same motivation to modify Ford in view of Fu applied to claim 1 and 11 above applies here.
Claims 5 and 15: the combination teaches
wherein the first security service is a data upload service of a blockchain (Ford ¶[0004] ("The computer processor may further be adapted to record security information about the client device via a blockchain verification process (e.g., by registering a validation result within a distributed ledger”); Ford ¶[0038] ("At S630, the network security server may record security information about the client device via a blockchain verification process… registering a validation result within a distributed ledger… associated with a smart contract transaction that records a device attestation status, a validation hash, a device identifier, and an attestation server identifier"); Ford ¶[0031] (records via HYPERLEDGER), the first request message comprises data to be uploaded to the blockchain (Ford ¶[0040] ("Some or all of the data in the table 700 may then be recorded via a blockchain. For example, the client identifier, server identifier, record hash value, and status might be recorded via the blockchain") the client-sourced measurement data is what gets written; Ford ¶[0041] ("the display 800 further includes a blockchain indication 820 reflecting if the attestation server itself is valid"; FIG. 9 "blockchain indication 920 of 'invalid').
Claims 6 and 16: the combination teaches
wherein the first security service is a data download service of a blockchain (Ford ¶[0048] ("A cloud-based integrity monitor 1310 may provide information via a web browser and exchange information with a blockchain 1320 and an attestation server 1330 via Representational State Transfer ('REST') web services… allowing requesting systems to access and manipulate textual representations of web resources using a uniform, predefined set of stateless operations"); Ford ¶[0034] ("The network security server 510 may store information into and/or retrieve information from data stores"), the first request message comprises indication information of data to be downloaded from the blockchain (Ford ¶[0040] (record identifier / IMA database key, client identifier, server identifier, record date, "a message identifier… a Universally Unique Identifier ('UUID') for a blockchain's transaction") the UUID is the retrieval key; Ford ¶[0043] ("query API process"), and the first feedback message comprises downloaded data or indicates that the data fails to be downloaded or is successfully downloaded (Ford ¶[0041] (blockchain validation result returned and displayed as "valid"/"invalid" alongside the client status).
Claims 7 and 17:the combination teaches
wherein the first security service is an encryption service, the first request message comprises a plaintext message, and the first feedback message is a ciphertext message (Fu ¶[0015] ("a serial number and a first random number of the first service trusted server encrypted through a public key of a second service trusted server, and respective component of the first service trusted server and corresponding metric policy identifier encrypted through a public key of the trusted remote proving server"); Fu ¶[0024] ("generating the verification response according to the certificate of the trusted remote proving server, and a verification response ciphertext encrypted through a public key of the second service trusted server"); Ford ¶[0047] ("public key signing and decryption (e.g., public key 1250 exchange for secure communication)"); Ford ¶[0045] ("encryption keys used for secure local storage and for device authentication").
The same motivation to modify Ford in view of Fu applied to claim 1 and 11 above applies here.
Claims 8 and 18: the combination teaches
wherein the first security service is a decryption service, the first request message comprises a ciphertext message, and the first feedback message is a plaintext message (Fu ¶[0016] ("decrypting a ciphertext in the challenge request through a private key of the second service trusted server to obtain the to-be-verified information, wherein the to-be-verified information includes a serial number and a random number"); Fu ¶[0019] ("decrypting the ciphertext through a private key of the second service trusted server to obtain an identity of the first service trusted server and legitimacy of a platform"); Fu ¶[0022] ("decrypting by using a private key of the trusted remote proving server to obtain the serial number… the random number, and the decrypted ciphertext"); Ford ¶[0047]).
The same motivation to modify Ford in view of Fu applied to claim 1 and 11 above applies here.
Claim 19: the combination teaches
wherein the method further comprises obtaining, based on the identifier of the second node, a trusted policy(Fu ¶[0020] ("…the method further comprises: sending a platform metric policy request to a trusted policy management server; wherein the platform metric policy request includes: a certificate and a serial number of a second service trusted server, and respective component of the second service trusted server and corresponding metric policy identifier encrypted through a public key of the trusted policy management server; receiving a platform metric policy response returned by the trusted policy management server… decrypting the ciphertext… to obtain the respective component of the second service trusted server, the metric policy identifier corresponding to the respective component, and a component metric algorithm"); Fu ¶[0023] ("obtaining a component metric algorithm according to the serial number of the first service trusted server; matching the component metric algorithm with a component value result in a preset policy library table").
The same motivation to modify Ford in view of Fu applied to claim 2 above applies here.
Claim 20: the combination teaches wherein the method further comprises
obtaining, based on the trusted policy, the security algorithm and the security parameter (Fu ¶[0020] ("decrypting the ciphertext through a private key of the second service trusted server to obtain the respective component of the second service trusted server, the metric policy identifier corresponding to the respective component, and a component metric algorithm; deploying the metric policy identifier and the component metric algorithm in the respective component") — the policy response yields both the algorithm (security algorithm) and the metric policy identifier / component values (security parameters), which are then deployed and used; Fu ¶[0023] (algorithm retrieved and matched against the policy library table).
The same motivation to modify Ford in view of Fu applied to claim 19 above applies here.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. 2020/0169557 A1 Data Processing Method and Device, Blockchain Client, and Blockchain Node.
US 9,246,942 B2 Platform authentication strategy management method and device for trusted connection architecture .
US 8,146,150 B2 Security management in multi-node, multi-processor platforms.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FATOUMATA TRAORE whose telephone number is (571)270-1685. The examiner can normally be reached 6:30-3:00.
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, SHEWAYE GELAGAY can be reached at 5712724219. 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.
Saturday, August 15, 2026
/FATOUMATA TRAORE/Primary Examiner, Art Unit 2436
Prosecution Insights