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 .
Claims 1-32 have been presented for examination and are rejected.
Examiner noted that as per claims 17-24 discloses “machine-readable storage medium comprising instructions“ the specification discloses whether the memory of a computer is limited to a non-transitory medium or transitory propagating signals (e.g. see paragraphs [0121, 0126-0127, 0234] discloses “machine-readable storage medium” specifically may refer to a non-transitory data storage means, such as a hardware storage medium having stored thereon computer executable instructions. The computer readable data carrier or storage medium specifically may be or may comprise a storage medium such as a random-access memory (“RAM”) and/or a read-only memory (“ROM”)”.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
acquire, associate, output in claims 1, 6-11, 13-18 and 20 are similarly being interpreted to invoke 112(f). Moreover, the limitation specify in claims 3 and 4 invoke 112(f). Moreover, the limitation estimate in claims 5 and 6 invoke 112(f). Moreover, the limitation generate in claims 9 and 10 invoke 112(f).
OR . these format
Such claim limitation(s) is/are:
" means for decoding " and “means for issuing” in claim 9
“means for collecting”, in claims 9, 14
“means for evaluating”, in claims 9, 16
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-32 are rejected under 35 U.S.C. 103 as being unpatentable Roth et al. (US 20160248593 hereinafter Roth) in view of Sood et al. (US 20190220601 hereinafter Sood).
With respect to claims 1, 9, 17 and 25 Roth teaches a host, the MEC host comprising:
Memory; and processing circuitry coupled to the memory(Roth, see para. [0077, 0079] ), the processing circuitry to:
decode an attestation request received from a first service of a network, the attestation request associated with attestation of a second service of the network (Roth, see FIG. 1 and Abstract, paragraph [0019] decrypted, a first request submitted to the first system is received from the first system. A response to the authentication request is generated that includes information usable by a second system…The metadata may be electronically signed by the authentication service and usable by the first service to determine the identity and policy information associated with a second electronic signature provided with a request from the first service to the second service. Para [0042] further discloses the authentication response may include various information such as an attestation that the signature provided from the service 306 matches the customer 302);
collect attestation evidence from the second service in response to the attestation request (Roth, see paragraph [0020] an instance of service-specific (i.e., first service) information may be an encrypted collection of information. The information, when decrypted, may enable a request signed with a signing key of the service-wide information to be verified…a receiving service of an authentication response can forward a request signed using information from the service-wide information and service-specific(i.e., first service) information to another service (i.e., second service)),
the attestation evidence associated with a software component of the second MEC service (Roth, see paragraph [0042] the metadata may be electronically signed by the authentication service and usable by the first service to determine the identity and policy information associated with a second electronic signature provided with a request from the first service to the second service. The service-wide information includes an attestation to the identity of the customer 302, a timestamp, policy information, a signature of the attestation and/or timestamp and/or policy information ), and
Roth disclosed most of the subject matter as described above yet fails to explicitly disclose Multi-Access Edge Computing (MEC),
the attestation evidence signed by a security function of a hardware root-of-trust.
However, Sood discloses Multi-Access Edge Computing (MEC)(Sood, see paragraphs [0038, 0062] one or more edge computing devices, which may include one or more gateways, servers, multi-access edge computing (MEC) appliances),
the attestation evidence signed by a security function of a hardware root-of-trust (RoT) of the MEC host (Sood, see paragraph[0088] Attestation of the trustworthiness of the bridge, router, or switch includes attestation of its hardware identity and software/firmware identities through cryptographically secure evidence. Para [0099] further discloses block 714 to determine whether the secure execution environment is approved by the tenant…the CTEE configuration may be provided to the tenant for approval, which may include root-of-trust (RoT) signatures and attestations for the trustworthiness of each component in the CTEE);
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to combine the teaching Roth with the teaching Sood to provide the method for the hardware-signed attestation of evidence using a hardware root-of-trust, which is unforgeable proof of a system’s integrity. Because the signing key is locked inside tamper-resistant physical hardware and isolated from the operating system, malware cannot steal the key or fake a clean security state.
With respect to claims 2, 10, 18, and 26 Roth-Sood teaches the MEC host,
wherein the hardware RoT is bound to the second MEC service in a trusted execution environment (TEE) of the MEC host (Sood, see para. [0083] …root-of-trust (RoT) signatures and attestation from those components in order to build a complete CTEE attestation that can be submitted to the tenant for approval ).
With respect to claims 3, 11, 19 and 27, Roth-Sood teaches the MEC host,
wherein the attestation evidence comprises one or more measurements of the software component of the second service (Roth, see FIG. 1 step 106 and para. [0019] a second electronic signature provided with a request from the first service to the second service).
With respect to claims 4, 12, 20 and 28, Roth-Sood teaches the MEC host,
wherein the first MEC service is configured as an application programming interface (API) endpoint of the host, and wherein the API endpoint is to invoke an API based on the client credential (Roth, see para. [0022] through appropriate user input and/or the transition of one or more electronic commands (e.g., local or remote web service calls) to the system 104, application programming interface (API) calls to the system 104 to a web service interface of the system 104…the customer 102 is provided authority to access the services 106 and the authentication service 108 is configured to enable the customer 102 to prove authority to access the services 106, such as by providing appropriate credentials and/or other information generated using appropriate credentials).
With respect to claims 5, 13, 21 and 29, Roth-Sood teaches the MEC host,
wherein the first MEC service is configured as a first MEC application and the second MEC service is configured as a second application instantiated in a virtual machine (Roth, see FIG. 2 step 208 and para. [0019] a second electronic signature provided with a request from the first service to the second service… para. [0025-0026] The virtual computer system service 208 may be a collection of computing resources configured to instantiate virtual machine instances onto virtual computing systems on behalf of the customers 204 of the computing resource service provider 202), and
wherein the hardware RoT is bound to the virtual machine(Sood, see para. [0083] The orchestrator, security controller, and/or virtualized infrastructure manager (VIM) may then collectively provision the various components and interconnects on the underlying infrastructure to build a CTEE for the workload, as well as procure root-of-trust (RoT) signatures and attestation from those components in order to build a complete CTEE attestation that can be submitted to the tenant for approval).
With respect to claims 6, 14, 22 and 30, Roth-Sood teaches the MEC host, further comprising an attester circuitry within the TEE, the attester circuitry to collect the attestation evidence from the second MEC service(Sood, see paragraph [0099] block 714 to determine whether the secure execution environment is approved by the tenant…the CTEE configuration may be provided to the tenant for approval, which may include root-of-trust (RoT) signatures and attestations for the trustworthiness of each component in the CTEE).
With respect to claims 7, 15, 23 and 31, Roth-Sood teaches the MEC host,
wherein the attester circuitry includes an API client of the API (Roth, see FIG. 2 and para. [0026] Customers 204 of the computing resource service provider 202 may interact with the virtual computer systems' service (via appropriately configured and authenticated API calls) to provision and operate virtual computer systems that are instantiated on physical computing devices hosted and operated by the computing resource service provider 202).
With respect to claims 8, 16, 24 and 32, Roth-Sood teaches the MEC host, further comprising a verifier circuitry within the TEE, the verifier circuitry to evaluate the attestation evidence using the at least one reference value to generate the attestation results(Sood, see para. [0083, 0086] The orchestrator, security controller, and/or virtualized infrastructure manager (VIM) may then collectively provision the various components and interconnects on the underlying infrastructure to build a CTEE for the workload, as well as procure root-of-trust (RoT) signatures and attestation from those components in order to build a complete CTEE attestation that can be submitted to the tenant for approval…Moreover, the orchestrator generates a workload manifest for deploying the workload (reference numeral 607), which is provided to the VIM. Once the tenant verifies and approves the CTEE…).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
PG. Pub. US 20200084202 Edge computing device for use in an edge-computing system, includes processing circuitry, a memory device comprising stored instructions, and processing circuitry performs operations to obtain a provider instance of a token.
PG. Pub. US 20180198764 Method of establishing trust chain, involves establishing secure transport for encrypted communication traversing intermediate system by client application and remote service.
PG. Pub. US 20190102556 Runtime security system in internet of things (IoT) applications, has execution monitor to detect that shared core has received secure boot request and allow shared core to securely boot, when boot request is valid.
PG. Pub. US 20180287780 System for securing operation of e.g. power generation and transmission system, has network security server including processor adapted to record security information about client device through blockchain verification process.
PG. Pub. US 20190158300 Edge computing apparatus for mobile edge computing (MEC) utilization tracking for billing and charging, has processing circuitry that stores identification of edge device, processing device identification and data computational processes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH KASSA whose telephone number is (571)270-0567. The examiner can normally be reached on Monday -Friday 9 AM -6 PM.
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, Ario Etienne can be reached on 517-272-4001. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
08/14/2026
/ELIZABETH KASSA/Examiner, Art Unit 2457
/MOUSTAFA M MEKY/Primary Examiner, Art Unit 2457
Prosecution Insights