DETAILED ACTION
Claims 1-20 are -resented for examination.
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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 8, and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, and 15 of U.S. Patent No. 12,081,678. Claims are directed to, providing, to a secure enclave, an attestation token based on a hash value of a public key and signed with a signing certificate; receiving an update request from a data storage based on the signing certificate of the attestation token in an application programming interface (API) call being unrecognized by the data storage, the data storage persisting confidential data in an encrypted state; update the signing certificate, resulting in an updated signing certificate; and provide the updated signing certificate to the data storage.
Although the conflicting claims are not identical, the claimed system and method in the instant application are not patentably from the claims of the patented application (U.S. Patent No. 12,081,678) because the differences between them are insubstantial and would have been obvious to one of ordinary skill in the art. Specifically, the subject matter of claim 1 of the instant application is anticipated by U.S. Patent No. 12,081,678. Please see the table below for the claim mapping.
Instant Application
U.S. Patent No. 12,081,678
A trusted token provider system comprising:
a processor; and
a program memory storing program code structured to cause the processor to: provide, to a secure enclave, an attestation token based on a hash value of a public key and signed with a signing certificate;
receive an update request from a data storage based on the signing certificate of the attestation token in an application programming interface (API) call being unrecognized by the data storage, the data storage persisting confidential data in an encrypted state; update the signing certificate, resulting in an updated signing certificate; and
provide the updated signing certificate to the data storage.
2. The trusted token provider system of claim 1, wherein the public key is from a key pair generated by the secure enclave.
3. The trusted token provider system of claim 1, wherein program code is further structured to cause the processor to: receive a signed digital certificate comprising the public key and a secure quote, the secure quote generated in encrypted memory of the secure enclave and comprising an identifier of the secure enclave and the hash value of the public key.
4. The trusted token provider system of claim 3, wherein the signed digital certificate is received from an API service and the program code is further structured to cause the processor to: validate the API service based on the secure quote; and subsequent to validating the API service, generate the attestation token.
5. The trusted token provider system of claim 1, wherein to update the signing certificate, the program code is further structured to cause the processor to: rotate an active signing certificate from the signing certificate to the updated signing certificate.
6. The trusted token provider system of claim 1, wherein program code is further structured to cause the processor to: generate the attestation token based on the hash value of the public key.
7. The trusted token provider system of claim 1, wherein program code is further structured to cause the processor to: locally store the signing certificate.
8. A method performed utilizing a trusted token provider system, the method comprising:
receiving, from a data storage, an update request based on a signing certificate of an attestation token in an application programming interface (API) call being unrecognized by the data storage, the data storage persisting confidential data in an encrypted state; updating the signing certificate, resulting in an updated signing certificate; and providing the updated signing certificate to the data storage.
9. The method of claim 8, wherein said updating the signing certificate comprises: rotating an active signing certificate from the signing certificate to the updated signing certificate.
10. The method of claim 8, further comprising: providing, to a secure enclave, the attestation token based on a hash value of a public key and signed with the signing certificate.
11. The method of claim 10, wherein the public key is from a key pair generated by the secure enclave.
12. The method of claim 10, further comprising: receiving a signed digital certificate comprising the public key and a secure quote, the secure quote generated in encrypted memory of the secure enclave and comprising an identifier of the secure enclave and the hash value of the public key.
13. The method of claim 12, wherein the signed digital certificate is received from an API service and the method further comprises: validating the API service based on the signed digital certificate; and subsequent to said validating the API service, generating the attestation token.
14. The method of claim 10, further comprising: generating the attestation token based on the hash value of the public key.
15. A computer readable storage medium having program code recorded thereon structured to cause a processing system to perform a method, the method comprising: receiving, from a data storage, an update request based on a signing certificate of an attestation token in an application programming interface (API) call being unrecognized by the data storage; updating the signing certificate, resulting in an updated signing certificate; and providing the updated signing certificate to the data storage.
16. The computer readable storage medium of claim 15, wherein said updating the signing certificate comprises: rotating an active signing certificate from the signing certificate to the updated signing certificate.
17. The computer readable storage medium of claim 15, wherein the method further comprises: providing, to a secure enclave, the attestation token based on a hash value of a public key and signed with the signing certificate.
18. The computer readable storage medium of claim 17, wherein the public key is from a key pair generated by the secure enclave.
19. The computer readable storage medium of claim 17, wherein the method further comprises: receiving a signed digital certificate comprising the public key and a secure quote, the secure quote generated in encrypted memory of the secure enclave and comprising an identifier of the secure enclave and the hash value of the public key.
20. The computer readable storage medium of claim 19, wherein the signed digital certificate is received from an API service and the method further comprises: validating the API service based on the signed digital certificate; and subsequent to said validating the API service, generating the attestation token.
A system comprising: a secure enclave that comprises an encrypted memory, a program memory storing program code, and a processing system comprising a processor circuit configured to receive the program code from the program memory and, in response to receiving the program code, to:
generate a signed digital certificate that comprises: a public key from a key pair generated by the secure enclave, and a secure quote generated in the encrypted memory and comprising an identifier of the secure enclave and a hash value of the public key; receive an attestation token from a trusted token provider, the attestation token based on the hash value of the public key and signed with a signing certificate;
receive, from a requestor, a request for confidential data; and place a first application programming interface (API) call to a data storage that persists the confidential data in a first encrypted state, the first API call comprising the signed digital certificate and the attestation token; and the trusted token provider configured to:
receive an update request from the data storage based on the signing certificate of the attestation token in the API call being unrecognized by the data storage;
update the signing certificate; and
provide the updated signing certificate to the data storage.
2. The system of claim 1, wherein the trusted token provider is further configured to: receive the secure quote and the signed digital certificate; generate the attestation token based on receiving the secure quote and the digital signed certificate; and provide the attestation token to the secure enclave.
3. The system of claim 1, wherein the trusted token provider is configured to: locally-store the signing certificate as part of stored signing certificates; receive a certificate request from the data storage for the signing certificate; and provide the signing certificate to the data storage.
4. The system of claim 1, wherein the processing system, in response to at least receiving the program code, is further configured to: place a second API call to the data storage, the second API call comprising the signed digital certificate and an updated attestation token, the updated attestation token signed by the updated signing certificate, the second API call establishing a secure session between the data storage and the secure enclave based on the updated signing certificate; and receive, from the data storage via the secure communication session and based on a trust determination for the secure enclave made by the data storage, an API response that comprises the confidential information to fulfill the request from the requestor.
5. The system of claim 4, wherein the trust determination is performed by the data storage and includes determining that the secure enclave is a trusted source for the API call based on: a validation of a signature of the updated attestation token against the updated signing certificate; and a validation of the signed digital certificate.
6. The system of claim 4, wherein: the processing system, in response to receiving the program code, is further configured to provide the confidential information in the first encrypted state to the encrypted memory that includes a private key of the key pair, receive the confidential information in a second encrypted state from the encrypted memory, and provide the confidential information in the second encrypted state to the requestor as fulfillment of the request; and the encrypted memory is configured to prevent access to both decrypting operations and encrypting operations that utilize the private key.
7. The system of claim 4, wherein; the secure enclave and the trusted token provider comprise a cloud-based platform; the data storage comprises an on-premise computing device outside of the cloud-based platform; and the secure communication session is a mutual transport layer security session via hyper-text transfer protocol (HTTP).
8. A method performed utilizing a secure enclave and a trusted token provider of a processing system, the method comprising: generating, by the secure enclave, a signed digital certificate comprising: a public key from a key pair generated by the secure enclave, and a secure quote generated in an encrypted memory of the secure enclave and comprising an identifier of the secure enclave and a hash value of the public key;
receiving an attestation token by the secure enclave and from the trusted token provider, the attestation token based on the hash value of the public key and signed with a signing certificate; receiving, by the secure enclave and from a requestor, a request for confidential data; placing, by the secure enclave, a first application programming interface (API) call to a data storage that persists the confidential data in a first encrypted state, the API call comprising the signed digital certificate and the attestation token;
receiving, by the trusted token provider and from the data storage, an update request based on the signing certificate of the attestation token in the API call being unrecognized by the data storage;
updating, by the trusted token provider, the signing certificate; and providing, by the trusted token provider, the updated signing certificate to the data storage.
9. The method of claim 8, further comprising: receiving, by the trusted token provider, the secure quote and the signed digital certificate; generating, by the trusted token provider, the attestation token based on said receiving the secure quote and the digital signed certificate; and providing, by the trusted token provider, the attestation token to the secure enclave.
10. The method of claim 8, further comprising: updating, by the trusted token provider, stored signing certificates by: locally-storing the signing certificate as part of the stored signing certificates; receiving a certificate request from the data storage for the signing certificate; and providing the signing certificate to the data storage.
11. The method of claim 8, further comprising: placing, by the secure enclave, a second API call to the data storage, the second API call comprising the signed digital certificate and an updated attestation token, the updated attestation token signed by the updated signing certificate, the second API call establishing a secure session between the data storage and the secure enclave based on the updated signing certificate; and receiving, by the secure enclave and from the data storage via the secure communication session and based on a trust determination for the secure enclave made by the data storage, an API response that comprises the confidential information to fulfill the request from the requestor.
12. The method of claim 11, wherein the data storage makes the trust determination by determining that the secure enclave is a trusted source for the API call based on: a validation of a signature of the updated attestation token against the updated signing certificate; and a validation of the signed digital certificate.
13. The method of claim 11, further comprising: providing, by the secure enclave, the confidential information in the first encrypted state to the encrypted memory that includes a private key of the key pair, receiving, by the secure enclave, the confidential information in a second encrypted state from the encrypted memory, and providing, by the secure enclave, the confidential information in the second encrypted state to the requestor as fulfillment of the request; and wherein the encrypted memory is configured to prevent access to both decrypting operations and encrypting operations that utilize the private key.
14. The method of claim 11, wherein the secure enclave and the trusted token provider comprise a cloud-based platform; wherein the data storage comprises an on-premise computing device outside of the cloud-based platform; and wherein the secure communication session is a mutual transport layer security session via hyper-text transfer protocol (HTTP).
15. A computer readable storage medium having program code recorded thereon that, when executed by a processing system, perform a method utilizing a secure enclave and a trusted token provider, the method comprising: generating, by the secure enclave, a signed digital certificate comprising: a public key from a key pair generated by the secure enclave, and a secure quote generated in an encrypted memory of the secure enclave and comprising an identifier of the secure enclave and a hash value of the public key; receiving an attestation token by the secure enclave and from the trusted token provider, the attestation token based on the hash value of the public key and signed with a signing certificate; receiving, by the secure enclave and from a requestor, a request for confidential data; placing, by the secure enclave, a first application programming interface (API) call to a data storage that persists the confidential data in a first encrypted state, the API call comprising the signed digital certificate and the attestation token; receiving, by the trusted token provider and from the data storage, an update request based on the signing certificate of the attestation token in the API call being unrecognized by the data storage; updating, by the trusted token provider, the signing certificate; and providing, by the trusted token provider, the updated signing certificate to the data storage.
16. The computer readable storage medium of claim 15, wherein the method further comprises: receiving, by the trusted token provider, the secure quote and the signed digital certificate; generate, by the trusted token provider, the attestation token based on said receiving the secure quote and the digital signed certificate; and providing, by the trusted token provider, the attestation token to the secure enclave.
17. The computer readable storage medium of claim 15, wherein the method further comprises: updating, by the trusted token provider, stored signing certificates by: locally-storing the signing certificate as part of the stored signing certificates; receiving a certificate request from the data storage for the signing certificate; and providing the signing certificate to the data storage.
18. The computer readable storage medium of claim 15, wherein the method further comprises: placing, by the secure enclave, a second API call to the data storage, the second API call comprising the signed digital certificate and an updated attestation token, the updated attestation token signed by the updated signing certificate, the second API call establishing a secure session between the data storage and the secure enclave based on the updated signing certificate; and receiving, by the secure enclave and from the data storage via the secure communication session and based on a trust determination for the secure enclave made by the data storage, an API response that comprises the confidential information to fulfill the request from the requestor.
19. The computer readable storage medium of claim 18, wherein the data storage makes the trust determination by determining that the secure enclave is a trusted source for the API call based on: a validation of a signature of the updated attestation token against the updated signing certificate; and a validation of the signing certificate.
20. The computer readable storage medium of claim 18, wherein: the method further comprises: providing, by the secure enclave, the confidential information in the first encrypted state to the encrypted memory that includes a private key of the key pair, receiving, by the secure enclave, the confidential information in a second encrypted state from the encrypted memory, and providing, by the secure enclave, the confidential information in the second encrypted state to the requestor as fulfillment of the request, wherein the encrypted memory is configured to prevent access to both decrypting operations and encrypting operations that utilize the private key; or the secure enclave and the trusted token provider comprise a cloud-based platform, wherein the data storage comprises an on-premise computing device outside of the cloud-based platform, and wherein the secure communication session is a mutual transport layer security session via hyper-text transfer protocol (HTTP).
This is a nonstatutory double patenting rejection.
Conclusion
Please see the attached PTO-892 for the prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD A SIDDIQI whose telephone number is (571)272-3976. The examiner can normally be reached Monday-Friday.
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, Carl G Colin can be reached at 571-272-3862. 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.
/MOHAMMAD A SIDDIQI/Primary Examiner, Art Unit 2493