Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 52-74 are pending in this office action.
Applicant’s arguments filed March 12, 2026, with respect to the 101 rejection have been considered and are persuasive. However, a new ground of rejection is made.
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 52-74 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Suriano et al. (Attestation of Trusted and Reliable Service Function Chains in the ETSI-NFV Framework, conference from June 29, 2020 – July 3, 2020).
Regarding claims 52 and 71, Suriano et al. teaches an orchestrator comprising (page 481, section III, Orchestrator): processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the orchestrator is configured to (fig. 5): receive signaling that requests the orchestrator to orchestrate a service and that indicates a trusted computing policy with which a resource must prove compliance in order for the service to be orchestrated with that resource (page 483, section III-C, paragraph 1-2, “This procedure is called each time…”, “The orchestrator maps the service request into a service chain, identifying the best set of VNFs, based on specific reliability levels”, “All the VNFs not verifying the hash check”… “are considered as untrusted and discarded from the list, because this means that the VNF bootcode has been altered from its original (trusted) version.”); and send a response that indicates whether or not the orchestrator has orchestrated the service according to the received signaling (page 484, fig. 4, step 8, Trustworthiness result and Algorithm 1).
Regarding claims 53, 61, and 69, Suriano et al. teaches wherein the trusted computing policy specifies a requirement that a resource with which the service is to be orchestrated must have a certain identity, configuration, behavior, or property, wherein the resource must prove compliance with the trusted computing policy by providing a remote attestation which proves the resource has the certain identity, configuration, behavior, or property (page 481, section III (“Trusted Platform Module).
Regarding claims 54, 62, and 70, Suriano et al. teaches wherein the trusted computing policy specifies a requirement that a resource with which the service is to be orchestrated must execute a certain software image or version, must execute software provided by a certain software provider, must execute software accredited by a certain software accreditor, must have certain hardware, must have hardware provided by a certain hardware manufacturer, must have hardware accredited by a certain hardware accreditor, or any combination thereof (page 481, section III (“Trusted Platform Module).
Regarding claim 55, Suriano et al. teaches further comprising: requesting a resource for a remote attestation that claims to prove compliance with the trusted computing policy; and receiving the requested remote attestation from the resource; enforcing the trusted computing policy by verifying whether the received remote attestation proves compliance with the trusted computing policy, wherein, based on the orchestrator verifying the received remote attestation, the response includes a remote attestation which proves the orchestrator itself complies with the trusted computing policy and which implicitly indicates a resource with which the service is orchestrated has proven compliance with the trusted computing policy (page 484, fig. 4, steps 1-7).
Regarding claim 56, Suriano et al. teaches wherein the response includes a remote attestation that proves a resource with which the service is or will be orchestrated complies with the trusted computing policy (page 485, V, “In this context, remote attestation is surely of great help in evaluating the trustworthiness and reliability of VNFs. In this paper, a procedure is explained in detail that performs the attestation of NFV-based service function chains, by properly taking into account the targeted security requirements and the measured reliability levels of the VNFs of the chain.”).
Regarding claim 57, Suriano et al. teaches further comprising: responsive to receiving the signaling, orchestrating, or attempting to orchestrate, the service with a resource that provides a remote attestation proving compliance with the trusted computing policy; and/or discovering a resource to orchestrate the service, on the basis of a resource claiming to be able to comply with the trusted computing policy (page 484, fig. 4, steps 2-7 and page 483, section III-C, “The orchestrator periodically receives the current state… compares it with the initial trusted state… All the VNFs not verifying the hash check… are discarded”).
Regarding claims 58 and 66, Suriano et al. teaches wherein the signaling indicates one or more conditions under which proving compliance with the trusted computing policy is required of a resource (page 483, section III-C, “based on specific reliability levels (i.e., bandwidth conditions, CPU and memory usage)”).
Regarding claims 59 and 67, Suriano et al. teaches wherein the service; provides a private communication mechanism between customer premises equipment and another endpoint, wherein the request is a request to orchestrator the service for the customer premises equipment; is a network slice or transport slice; or is a service in a wireless communication network (page 484, section IV, “practical use case… video transmission scenario… service chain is made up of five distinct functions: a firewall, an Intrusion Detection System (IDS), a parental control filter, a video optimizer, and a Network Address Translation (NAT)”).
Regarding claim 60, Suriano et al. teaches a method performed by customer premises equipment, the method comprising: transmitting, from the customer premises equipment to an orchestrator, signaling that requests the orchestrator to orchestrate a service for the customer premises equipment and that indicates a trusted computing policy with which a resource must prove compliance in order for the service to be orchestrated with that resource (page 483, section III-C, paragraph 1-2, “This procedure is called each time…”, “The orchestrator maps the service request into a service chain, identifying the best set of VNFs, based on specific reliability levels”, “All the VNFs not verifying the hash check”… “are considered as untrusted and discarded from the list, because this means that the VNF bootcode has been altered from its original (trusted) version.”); and receiving, from the orchestrator, a response that indicates whether or not the orchestrator has orchestrated the service for the customer premises equipment according to the signaling (page 484, fig. 4, step 8, Trustworthiness result and Algorithm 1).
Regarding claim 63, Suriano et al. teaches wherein the response indicates the orchestrator has enforced compliance with the trusted computing policy by a resource with which the service is orchestrated (page 484, fig. 4, step 8).
Regarding claim 64, Suriano et al. teaches wherein the response includes a remote attestation that explicitly proves the orchestrator itself complies with the trusted computing policy and that implicitly proves a resource with which the orchestrator has orchestrated the service complies with the trusted computing policy (page 485, IV, “The VNFs with the modified hash are no more considered as trusted, and the list of VNFs that compose the service changes accordingly”).
Regarding claim 65, Suriano et al. teaches further comprising: receiving, from the orchestrator, a remote attestation that proves a resource with which the service has been orchestrated complies with the trusted computing policy; and verifying the remote attestation received, as a condition for declaring the request for orchestration of the service satisfied (page 485, V, “In this context, remote attestation is surely of great help in evaluating the trustworthiness and reliability of VNFs.”).
Regarding claim 68, Suriano et al. teaches a method performed by resource equipment configured to be or host a resource for providing at least a part of a service, the method comprising: receiving, from an orchestrator, signaling that requests the resource to prove that the resource complies with a trusted computing policy indicated by the signaling in order for a service to be orchestrated with the resource (page 483, section III-C, paragraph 1-2, “This procedure is called each time…”, “The orchestrator maps the service request into a service chain, identifying the best set of VNFs, based on specific reliability levels”, “All the VNFs not verifying the hash check”… “are considered as untrusted and discarded from the list, because this means that the VNF bootcode has been altered from its original (trusted) version.”); and sending, to the orchestrator, a response which proves that the resource complies with a trusted computing policy indicated by the signaling (page 484, fig. 4, step 8, Trustworthiness result and Algorithm 1).
Regarding claims 72-74, Suriano et al. teaches wherein the trusted computing policy specifies one or more requirements that a resource must meet as a condition for the service to be orchestrated with that resource, wherein the resource meeting the one or more requirements indicates that the resource is secure enough for the service to be orchestrated with the resource (page 483, section III-C, “All the VNFs not verifying the hash check… are considered as untrusted and discarded… All the other VNFs passing the check are stored in a set Fi or trusted VNF”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON HOFFMAN whose telephone number is (571)272-3863. The examiner can normally be reached Monday-Friday 8:30AM-5: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, Jeffrey Pwu can be reached at (571)272-6798. 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.
/BRANDON HOFFMAN/Primary Examiner, Art Unit 2433
Prosecution Insights