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
Currently pending claims are 21 – 40.
Response to Arguments
Applicant's arguments with respect to the subject matter of the instant claims have been fully considered but are not persuasive.
As per claim 1, Applicant asserts prior-art(s) does not teach “receive, from the trusted platform module, information indicating the current configuration for the compute instance” because the only thing Brickell's module reports to the platform's attestation software is a "success or failure" bit indicating whether the received candidate configuration matched the module's internally stored configuration and makes this point explicit in stating that "the response does not include which configuration was used (Remarks: Page 11 / 2nd Para). Examiner respectfully disagrees with the following rationale.
(a) Examiner notes according to MPEP 2111 of the broadest and reasonable claim interpretations, applicant’s argument has no merit since the alleged limitation such as “what is the exact information entity indicating the current configuration for the compute instance” has not been specifically recited into the claim. 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).
(b) accordingly, Examiner notes any status information entity regarding the current configuration constitutes a part of the information indicating the current configuration. In light of that, Brickell teaches providing a success / failure status bit (i.e. a status information entity) indicating whether the received current configuration information matched the module's internally stored configuration (Brickell: FIG. 1 / E-115 & E-120 and Col. 3 Line 17 – 25 / 31 – 34), as alleged by the Applicant, indeed constitutes a part of the information indicating the current configuration to meet the claim language. As such Applicant's arguments are respectfully traversed.
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.
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 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 21, 23 – 25, 27 – 29, 31, 32, 34 – 37 & 39 are rejected under 35 U.S.C.103 as being unpatentable over Brickell (U.S. Patent 7,587,607), in view of Trammel et al. (U.S. Patent 9,038,138).
As per claim 21, 28 & 35, Brickell teaches a system, comprising:
one or more processor and memory configured to implement a compute instance configured to (Brickell: FIG. 2 & 3):
send, to a trusted platform module, a request for information indicating a current configuration for the compute instance (Brickell: FIG. 1 / E-145 & E-160 and Col. 3 Line 9 – 22: an attestation software entity sends a request to a trusted platform module (TPM) to request for attestation information indicating whether the current configuration is satisfied in meeting an acceptable configuration by comparing with an internal stored configuration);
receive, from the trusted platform module, information indicating the current configuration for the compute instance (Brickell: FIG. 1 / E-115 & E-120 and Col. 3 Line 17 – 25 / 31 – 34:
(a) Examiner notes any status information entity regarding the current configuration constitutes a part of the information indicating the current configuration; and
(b) In light of that, Brickell teaches the trusted platform module (TPM) reporting / responding the result back via the attestation software entity and providing a success / failure status bit (i.e. a status information entity) indicating whether the received current configuration information matched the module's internally stored configuration);
send a request to a network endpoint of an attestation service, the request including the information indicating the current configuration for the compute instance (Brickell: see above, FIG. 1 / E-115 & E-120 and Col. 3 Line 31 – 34: sending, from the attestation software entity, a request to an attestation requestor entity for validating whether the current configuration matches the acceptable configuration).
However, Bickell does not disclose expressly receiving, from the attestation service, an attestation token for the compute instance.
Trammel (& Brickell) teaches receiving, from the attestation service, an attestation token for the compute instance, the attestation token indicting the compute instance is authorized to access a secured resource upon providing the attestation token to the secured resource (Brickell: see above) || (Trammel: Col. 4 Line 57 – 63, Col. 3 Line 27 – 30, Col. 7 Line 59 – 63 / Line 52 – 55 / Line 12 – 15 & Col. 8 Line 10 – 12:
(a) Trammel teaches managing multiple applications (i.e. compute instances) authentication ( as a part of attestation) by providing a distributed mechanism to manage the security tokens for access secure remote resource as needed (Trammel: Col. 4 Line 57 – 63) so as to avoid exposing authentication credentials to potential security vulnerabilities (security compromised) because the authentication credentials stored locally on the device are at risk of tampering and/or unauthorized use or access (Trammel: FIG. 2 & Col. 3 Line 27 – 30); thereby,
(b) after an authorization entity (i.e. an attestation service) has been successfully validated (see (c)), a security token is generated and received by the user / client device(s) (i.e. computer instance(s)) such that the user / client device(s) can be authenticated based on the presented security token (Trammel: see above & Col. 7 Line 59 – 63 / Line 52 – 55), wherein
(c) the validation is based on a security policy that matches the registration (configuration) information of the client device including configured unique serial number or hardware identifier (as a baseline health measurement values) indicating current system / hardware / software (versions) implementing the compute instance (Trammel: Col. 8 Line 10 – 12 and Col. 7 Line 12 – 15).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of wherein the current health measurement values of the compute instance are monitored based on a trusted platform module for the compute instance because Trammel teaches to alternatively, effectively and securely enable the user / client device(s) (i.e. computer instance(s)) to utilize a security token for authentication, after a successful validation by an attestation service, based on a presented security token to avoid exposing authentication credentials to potential security vulnerabilities (security compromised), wherein the validation is based on a security policy that matches the registration (configuration) information of the client device including configured unique serial number or hardware identifier (as a baseline health measurement values) indicating current system / hardware / software (versions) implementing the compute instance (see above) within the Brickell’s system that an attestation software entity sends a request to a trusted platform module (TPM) to request for attestation information indicating whether the current configuration is satisfied in meeting an acceptable configuration by comparing with an internal stored configuration so as to access remote secure data (see above).
send, to the secured resource, an access request for data stored at the secured resource, the request based at least in part on at least a portion of the attestation token (Brickell: see above) || (Trammel: see above & Col. 5 Line 35 – 44 & Col. 7 Line 52 – 63: the client device(s) (computer instance(S)) can use device attestation token to request the access to remote resources); and
receive, from the secured resource, the requested data (Brickell || Trammel: see above).
As per claim 23, 29 & 39, Sabri (& Brickell as modified) teaches wherein the current configuration indicates one or more of: a platform of the compute instance, current software of the compute instance, current hardware implementing the compute instance, or currently running applications of the compute instance (Trammel: see above & Col. 8 Line 10 – 12 and Col. 7 Line 12 – 15: a client access request is sent from a user / client device in accordance with a security policy to match the registration information of the client device associated with, for example, configured unique serial number or hardware identifier that at least indicates current system / hardware / software (versions) implementing the compute instance that at least indicates current system / hardware / software (versions) implementing the compute instance that includes more than one baseline health measurement values).
As per claim 24, 31 & 36, the claim limitations are met as the same reasons as that set forth in the paragraph above regarding to claim 21 with the exception of the feature(s) of receiving, from the attestation service, a notification indicating that the configuration for the other instance does not satisfy a baseline configuration, the baseline configuration specified in an attestation policy indicating the baseline configuration for validating the other compute instance (Brickell: see above) || (Trammel: see above & Col. 7 Line 12 – 15 / Line 59 – 63 / Line 52 – 55 and Col. 8 Line 10 – 12: an authorization entity (i.e. an attestation service) validates a request based on a security policy that matches the registration (configuration) information of the client device and, as a result, generates a security token for a successful validation and, otherwise, implicitly sends a notification (as a negative response) indicating that the configuration for the other instance does not satisfy a baseline configuration).
As per claim 25, 27, 32, 34 & 37, the instant claim is directed to a claimed content having functionality corresponding to the Claims 21, and are rejected by a similar rationale
Claims 22, 26, 30, 33 & 38 are rejected under 35 U.S.C.103 as being unpatentable over Brickell (U.S. Patent 7,587,607), in view of Trammel et al. (U.S. Patent 9,038,138), and in view of Sabri et al. (U.S. Patent 11,379,775).
As per claim 22, 26, 30, 33 & 38, Sabri (& Brickell as modified) teaches generating, in accordance with an API for the network endpoint of the attestation service, the access request for data stored at the secured resource (Brickell: see above) || (Sabri: Col. 13. Line 50 – 52: providing an effective mechanism for data access services such that a data access request can employ an API interface function for generating requests to a query service so as to access secure data stored at a database).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of generating, in accordance with an API for the network endpoint of the attestation service, an access request for data stored at the secured resource because Sabri teaches to alternatively, effectively and securely provide an effective mechanism for data access services such that a data access request can employ an API for generating requests to a query service so as to access secure data stored at a database (see above) within the Brickell’s system that an attestation software entity sends a request to a trusted platform module (TPM) to request for attestation information indicating whether the current configuration is satisfied in meeting an acceptable configuration by comparing with an internal stored configuration so as to access remote secure data (see above).
Claim 40 is rejected under 35 U.S.C.103 as being unpatentable over Brickell (U.S. Patent 7,587,607), in view of Trammel et al. (U.S. Patent 9,038,138), and in view of Upadbyay (U.S. Patent 8,011,002).
……… Note: U.S. Patent Su et al. (U.S. Patent 8,793,782) is also provided as an additional evidence enclosed in the record of 892 to further support the rationale of rejection for the clarity purpose (Pls. also see below).
As per claim 40, Upadbyay (& Brickell as modified) teaches based on receipt, from the attestation service, of an indication of the network endpoint to which requests, comprising the request, are to be sent and use the indication of the network endpoint to perform said send the request to the network endpoint (Brickell: see above) || (Upadbyay: Figure 3 / E-330 & Col. 6 Line 55 – 57: in response to a client request, an authorization server (i.e. attestation service) indicates to which an authorized proxy device (i.e. as a network endpoint) of the authorization server that the client device should send the request such that the confidential information would not be compromised by an unauthorized proxy device).
In addition, U.S. Patent Su et al. (U.S. Patent 8,793,782) can be used / considered as an additional evidence as a supplemental reference to (enclosed in the record of PTO-892) to further support the rationale of rejection for the clarity purpose (Su: Col. 8 Line 35 – 46 and FIG. 3 / E-352 & 354: (a) As per a well-known authentication server used in Microsoft's Internet Authentication Service (IAS), a proxy device of the server, alternatively as a separate device, can also be either physically resides in the same physical hardware of the authentication server ((or)) can be a plug-in to the authentication server and (b) managing a health condition of the supplicant by using a security token).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of providing an indication of the network endpoint to which requests, comprising the request, are to be sent and use the indication of the network endpoint to perform said send the request to the network endpoint because Upadbyay teaches to alternatively, effectively and securely, in response to a client request, indicate, by an authorization server (i.e. attestation service), to which an authorized proxy device (i.e. as a network endpoint) of the authorization server that the client device should send the request such that the confidential information would not be compromised by an unauthorized proxy device (see above) within the Brickell’s system that an attestation software entity sends a request to a trusted platform module (TPM) to request for attestation information indicating whether the current configuration is satisfied in meeting an acceptable configuration by comparing with an internal stored configuration so as to access
remote secure data (see above).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LONGBIT CHAI whose telephone number is (571)272-3788. The examiner can normally be reached Monday - Friday 9:00am-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, Lynn D. Feild can be reached at 571-272-2092. 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.
---------------------------------------------------
/Longbit Chai/
Longbit Chai E.E. Ph.D.
Primary Examiner, Art Unit 2431
No. #2591 – 2026 ---------------------------------------------------
Prosecution Insights