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 .
This action is responsive to communication received on 10/08/2024. Claims 2-21 are pending responsive to preliminary amendments made to cancel claim 1. Claims 2-21 are labelled as new.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
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 conflicting claims 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) 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 www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 2-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No.12,039,057. Although the claims at issue are not identical, they are not patentably distinct from each other because claims of the instant application recite a broader set of claims than that of the claims in the allowed Patent US 12,039,057. Thus although claims are not exactly the same the claims of the Patent US 12,039,057 teach each limitation of the instant application, see table below.
18/750,839
US 12,039,057
2. A method, comprising: sealing, by a cryptography agent that resides in an unsecured portion of a client-side machine, information sent by a server,
wherein the information meets a specified sensitivity threshold;
storing, by the cryptography agent, the sealed information in a secure enclave of the client- side machine;
providing, by the cryptography agent and to a client application that resides in the unsecured portion of the client-side machine, an encrypted token that is generated within the secure enclave of the client-side machine;
receiving, by the cryptography agent and from the client application, the encrypted token as a part of an authentication request to authenticate the client application;
authenticating, by the cryptography agent based on a decryption of the received encrypted token, the client application;
and performing, by the cryptography agent on behalf of the client application after the client application has been successfully authenticated, one or more operations within the secure enclave, wherein the one or more operations are performed at least in part using the sealed information that is stored in the secure enclave.
1. A method, comprising:
sending, by a cryptography agent to a secure server, a first token that is received from a client application;
receiving, by the cryptography agent from the secure server, the confidential information, the confidential information being encrypted by the public key;
sealing, by the cryptography agent, the private key and the second token inside a secure enclave;
receiving, by the cryptography agent from the secure server, a second token that defines an application context associated with the client application;
generating, by the cryptography agent, a public key and a private key for the client application;
receiving, by the cryptography agent from the secure enclave, a third token that is generated within the secure enclave at least in part by encrypting information of the second token;
validating, by the cryptography agent, the client application based on the received third token;
and performing, in response to a successful validation of the client application, one or more operations according to the received one or more operational commands, the one or more
operations being performed by the cryptography agent within the secure enclave.
sealing, by the cryptography agent, the confidential information inside the secure enclave;
sending, by the cryptography agent to the client application, the third token; sending, by the cryptography agent to the secure server, a request to fetch confidential information, the request containing the public key and the second token;
receiving, by the cryptography agent from the secure server, the confidential information, the confidential information being encrypted by the public key;
receiving, by the cryptography agent from the client application, one or more operational commands along with the third token;
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, 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 2-21 are rejected under 35 U.S.C. 103 as being unpatentable over Fuhry US 2021/0266329.
Regarding claims 2, 15 and 19, Fuhry teaches a method, system and non-transitory CRM executed by a processor to perform sealing, by a cryptography agent that resides in an unsecured portion of a client-side machine(untrusted portion of the host, ¶23), information sent by a server, wherein the information meets a specified sensitivity threshold (enclave seals… i.e. encrypts to protect data such as keys token and data that is to be protected., ¶s 6,25,26)
[0006] In some variations, one or more of the features disclosed herein including the following features can optionally be included in any feasible combination. Establishing the trusted relationship may include: providing, by the enclave and to the certificate authority component, a server token request including a public key; receiving, by the enclave and from the certificate authority component, a server token signed with a certificate authority public key; and verifying, by the enclave, the received server token, where the verification is based upon the certificate authority public key. The certificate authority public key may be hard-coded into the enclave, and the server token may be persisted to memory of the enclave upon verification of the received server token. Establishing the trusted relationship may include: receiving, by the enclave and from the user application, an authentication token; and verifying, by the enclave, the authentication token based upon the certificate authority public key. The one or more parameters of access related to the file may include a level of permission for the individual users and/or the groups of users. An external, untrusted interface may establishes a secure connection including the secure interface between the user application and the enclave. The file may be encrypted with a file key, the file key unique to the file and derived from a root key generated by the enclave. The encryption of the file with the file key may occur within the enclave. The encrypted file may be decrypted in the enclave and sent to the user application over a channel including a secure interface. Providing, by the enclave, access to the file may be further in response to establishment of a second trusted relationship with a second user having individual access rights or being part of a group with access rights.
[0023] The trusted execution environment, according to aspects of the current subject matter, may guarantee confidentiality and integrity protection to code and data in it, even in an untrusted environment, such as the server 110. Consistent with implementations of the current subject matter, the trusted execution environment may dedicate at least a portion of the system's main memory (e.g., RAM) for processor reserved memory (PRM). All code and data in the processor reserved memory may be encrypted while residing outside of the central processing unit, and decrypted and integrity checked when the data is loaded into the central processing unit. All other software on the system, including privileged software such as the operating system, hypervisor, and firmware, cannot access the processor reserved memory. The operating system may swap out enclave pages, and the trusted execution environment ensures integrity, confidentiality, and freshness of swapped-out pages. According to aspects of the current subject matter, programs using the trusted execution environment may also include an untrusted part, and the host process may invoke the enclave only through a well-defined interface.
[0025] The trusted execution environment consistent with implementations of the current subject matter is stateless (e.g., all of its contents are lost when the trusted execution environment is destroyed). To preserve data for multiple enclave runs, the trusted execution environment offers data sealing. This process uses a sealing key to encrypt and integrity-protect data. Afterwards, the data may be stored outside of the trusted execution environment in untrusted memory, and only the trusted execution environment with the same sealing key may unseal the data.
[0026] Consistent with implementations of the current subject matter, a protected file system library may be part of the trusted execution environment and may provide a subset of a regular C file application program interface (API), (e.g., file creation, file writing, and file reading). On write, data may be separated into chunks, the data's integrity ensured with, for example, a Merkle hash tree variant, and each chunk encrypted before it is stored in untrusted memory. When file chunks are loaded back into the trusted execution environment, the confidentiality and integrity is verified. The encryption key may be provided manually, or it may be derived automatically from the sealing key. At any point, only one file handle may be open for writing, but many handles for reading.
storing, by the cryptography agent, the sealed information in a secure enclave of the client- side machine(sealing implies keys/token are stored in enclave ¶s 6,25,26)
providing, by the cryptography agent and to a client application that resides in the unsecured portion of the client-side machine, an encrypted token that is generated within the secure enclave of the client-side machine(in case the application is related for file sharing.. user mare share files and perform operations on such files to include changing permissions, request include client certificate as for authentication of the client , ¶s 65,66);
[0065] According to aspects of the current subject matter, establishing the trusted relationship between the enclave 220 and the user may further include the user application 202 sending an authentication token (e.g. a client certificate) to the enclave 220. The enclave 220 may check the validity of the authentication token with coded (e.g., hardcoded) CA trust information (e.g., the CA's public key).
[0066] With continued reference to FIG. 3, at 320, the enclave 220 associates one or more access control permissions to a file linked from the user application 202 to a remote file system at the untrusted provider (e.g., the cloud provider 110). The one or more access control permissions may define one or more parameters of access related to the file (e.g., as established by the user and as provided to the enclave 220). The one or more access control permissions may be defined by the user for individual users and/or groups of users. For example, as described herein, the combination of operations outlined in Algorithm 1 allow a user to share a file or directory with individual users (using their default groups) and groups, dynamically change permissions and group memberships, and set separate read and write permissions. According to aspects of the current subject matter and with reference to FIG. 2, the access control component 224 is responsible for relation updates (e.g., internal operation updateRel) and access control checks (e.g., internal operations auth_f and auth_g). For both tasks, the access control component 224 may use the file manager component 225 to read and write the required relations.
receiving, by the cryptography agent and from the client application, the encrypted token as a part of an authentication request to authenticate the client application(signer server token is return to and sent to enclave for validation and encryption, ¶s37,61, 62);
[0037] Consistent with implementations of the current subject matter, to establish user trust in the enclave 220, a certification service component 212 of a certificate authority (CA) 210 connects to the untrusted certification component 230 to perform remote attestation of the enclave 220. The CA's public key is hard-coded into the enclave 220. Thus, if the CA 210 receives the expected measurement, it is assured to communicate with an enclave that was built specifically for this CA. During remote attestation, the CA 210 establishes a secure channel that ends at the trusted certification component 222. This channel is used for the following message exchanges: (1) the certification service component 212 of the CA 210 requests a certificate signing request (CSR); (2) the trusted certification component 222 of the enclave 220 generates a temporary key pair 252 and provides the certification service component 212 with a CSR containing the public-key of the temporary key pair 252; and (3) the certification service component 212 generates and signs a server certificate 251 and provides it to the enclave's trusted certification component 222. The trusted certification component 222 checks the certificate's validity. On success, it persists the server certificate 251 in untrusted memory, seals the key pair 252, and triggers a trusted TLS interface 221 to update its server certificate. The CA 210 can request a new CSR and subsequently replace the server certificate at any time. Consistent with implementations of the current subject matter, a separation in an untrusted certification component 230 and the trusted certification component 222 may not be necessary if the enclave 220 support direct I/O.
[0061] According to aspects of the current subject matter, establishing the trusted relationship between the user and the enclave 220 may further include the trusted certification component 222 providing, to the CA's certificate service 212, a server token request (e.g., a server certificate request). The server token request may contain a public key.
[0062] According to aspects of the current subject matter, establishing the trusted relationship between the user and the enclave 220 may further include the CA's certificate service 212 providing, to the to the trusted certification component 222, a signed server token (e.g. a signed server certificate). The signed server token may be signed by the CA with the CA's public key.
authenticating, by the cryptography agent based on a decryption of the received encrypted token, the client application (enclave validates i.e. authenticates client certificate to authentication the client application, ¶65)
[0065] According to aspects of the current subject matter, establishing the trusted relationship between the enclave 220 and the user may further include the user application 202 sending an authentication token (e.g. a client certificate) to the enclave 220. The enclave 220 may check the validity of the authentication token with coded (e.g., hardcoded) CA trust information (e.g., the CA's public key).
and performing, by the cryptography agent on behalf of the client application after the client application has been successfully authenticated, one or more operations within the secure enclave, wherein the one or more operations are performed at least in part using the sealed information that is stored in the secure enclave enclave(after authentication user as allowed to perform operations on files such as setting permission , changing group access, ¶66 ).
[0066] With continued reference to FIG. 3, at 320, the enclave 220 associates one or more access control permissions to a file linked from the user application 202 to a remote file system at the untrusted provider (e.g., the cloud provider 110). The one or more access control permissions may define one or more parameters of access related to the file (e.g., as established by the user and as provided to the enclave 220). The one or more access control permissions may be defined by the user for individual users and/or groups of users. For example, as described herein, the combination of operations outlined in Algorithm 1 allow a user to share a file or directory with individual users (using their default groups) and groups, dynamically change permissions and group memberships, and set separate read and write permissions. According to aspects of the current subject matter and with reference to FIG. 2, the access control component 224 is responsible for relation updates (e.g., internal operation updateRel) and access control checks (e.g., internal operations auth_f and auth_g). For both tasks, the access control component 224 may use the file manager component 225 to read and write the required relations.
Regarding claim 3, Fuhry teaches wherein the information comprises one or more cryptographic keys.
[0024] The trusted execution environment may have a remote attestation feature, allowing for verification of code integrity and authenticity on a remote system. This is done by hashing (also referred to as measuring) the initial code and data loaded into the trusted execution environment. A signed version of the measurement may be provided to an external party to prove the correct creation of a trusted execution environment. Furthermore, the remote attestation feature allows to establish a secure channel between an external party and a trusted execution environment. This secure channel may be used to deploy sensitive data, e.g., cryptographic keys, directly into the trusted execution environment.
Regarding claim 4, Fuhry teaches wherein the sealing is performed by the cryptography
[0025] The trusted execution environment consistent with implementations of the current subject matter is stateless (e.g., all of its contents are lost when the trusted execution environment is destroyed). To preserve data for multiple enclave runs, the trusted execution environment offers data sealing. This process uses a sealing key to encrypt and integrity-protect data. Afterwards, the data may be stored outside of the trusted execution environment in untrusted memory, and only the trusted execution environment with the same sealing key may unseal the data.
Regarding claim 5, Fuhry teaches wherein the one or more seal keys are directly fused into one or more hardware resources of the client-side machine(hardware including enclave integrated in ASIC , ¶78).
[0078] One or more aspects or features of the subject matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs, field programmable gate arrays (FPGAs) computer hardware, firmware, software, and/or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Regarding claims 6 and 17, Fuhry teaches, wherein the one or more hardware resources comprise a motherboard or an integrated circuit (IC) chip(hard including enclave integrated in ASIC , ¶78).
[0078] One or more aspects or features of the subject matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs, field programmable gate arrays (FPGAs) computer hardware, firmware, software, and/or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Regarding claims 7 and 21, Fuhry teaches wherein the one or more operations comprise cryptographic operations(executes cryptographic operation to authenticate access, ¶17)
.
[0017] The architecture consistent with implementations of the current subject matter may support group file sharing in large and dynamic groups. The architecture may be trusted execution environment-based without using a cryptographic access control scheme. Via tokens, users authenticate themselves to the enclave (an isolated, trusted environment for application code and data in an untrusted environment) and establish a secure channel with it, which is used for all subsequent communication. On every user access, the enclave checks encrypted access control policies to enforce read and/or write access on files. Immediate permission or membership revocations may only require an inexpensive modification of an encrypted file. Users may upload (e.g., arbitrarily large) files through the secure channel directly into the enclave. If the upload is granted, the enclave encrypts the files with, for example, a random key using probabilistic authenticated encryption or other encryption schemes. The enclave then stores the files in the untrusted environment. On each granted file request, the file is decrypted inside the enclave and sent to the user over the secure channel. The architecture consistent with implementations of the current subject matter separates authentication and authorization using identity information in the tokens. As long as the identity information is preserved, no further change is necessary if a user's token is replaced or if a user has different tokens for multiple devices. According to aspects of the current subject matter, the disclosed architecture does not require complex cryptographic operations on permission or membership changes.
Regarding claims 8 and 16, Fuhry teaches wherein the one or more operations are based on one or more commands sent from the client application, and wherein the one or more commands are in plain text form(plaintext value in commands, ¶28).
[0028] Probabilistic authenticated encryption (PAE), according to aspects of the current subject matter, may provide confidentiality, integrity, and authenticity of encrypted data. For example, PAE_Enc takes a secret key SK, a random initialization vector IV and a plaintext value as input and returns a ciphertext c. PAE_Dec takes SK and c as input and returns v if v was encrypted with PAE_Enc under the initialization vector IV and the secret key SK.
and comprise encrypt, decrypt, sign, or verify(validating certificates, ¶s 63,64).
[0063] According to aspects of the current subject matter, establishing the trusted relationship between the user and the enclave 220 may further include the trusted certification component 222 verifying a received signed server token (e.g., a server certificate) with the CA's trust information (e.g., the CA's public key), which may be coded (e.g., hard-coded) into the enclave 220. Upon verification of the validity of the signed server token, the signed server token may be persisted to memory.
[0064] According to aspects of the current subject matter, establishing the trusted relationship between the user and the enclave 220 may further include the user application 202 receiving the signed server certificate upon connection with the enclave 220. The user application 202 may verify the certificate with the CA's trust information (e.g., public key) known to it.
Regarding claim 9, Fuhry teaches wherein the client application is prevented from communicating directly with the server and from having direct access to the secure enclave(application on client accesses files from server though the enclave, ¶23).
[0023] The trusted execution environment, according to aspects of the current subject matter, may guarantee confidentiality and integrity protection to code and data in it, even in an untrusted environment, such as the server 110. Consistent with implementations of the current subject matter, the trusted execution environment may dedicate at least a portion of the system's main memory (e.g., RAM) for processor reserved memory (PRM). All code and data in the processor reserved memory may be encrypted while residing outside of the central processing unit, and decrypted and integrity checked when the data is loaded into the central processing unit. All other software on the system, including privileged software such as the operating system, hypervisor, and firmware, cannot access the processor reserved memory. The operating system may swap out enclave pages, and the trusted execution environment ensures integrity, confidentiality, and freshness of swapped-out pages. According to aspects of the current subject matter, programs using the trusted execution environment may also include an untrusted part, and the host process may invoke the enclave only through a well-defined interface.
Regarding claim 10, Fuhry teaches receiving, by the cryptography agent from the server, an application context generated that specifies a set of operations the client application is authorized to perform(operational commands include read /write request to content in a file, ¶45,46).
[0045] The access control component 224 is responsible for relation updates (e.g., internal operation updateRel) and access control checks (e.g., internal operations auth_f and auth_g). For both tasks, the access control component 224 may use the file manager component 225 to read and write the required relations.
[0046] Trusted and untrusted file manager components handle all files stored in untrusted memory. The trusted file manager component 225 encrypts/decrypts the content of all files that should be written/read with, for example, PAE_Enc/PAE_Dec using a unique file key SK.sub.f per file. The file key may be derived from a root key SK.sub.r (e.g., root key 270), which the trusted file manager 225 generates and seals on the first enclave start and unseals on subsequent enclave starts. All encrypted data is passed/received to/from the untrusted file manager component 260, which handles the actual memory access (e.g., internal operations read and write).
Regarding claims 11 and 18, Fuhry teaches determining whether the one or more operations are included in the set of operations, and wherein the one or more operations are performed based on a determination that the one or more operations are included in the set of operations operational commands include read /write request to content in a file, ¶45,46).
[0045] The access control component 224 is responsible for relation updates (e.g., internal operation updateRel) and access control checks (e.g., internal operations auth_f and auth_g). For both tasks, the access control component 224 may use the file manager component 225 to read and write the required relations.
[0046] Trusted and untrusted file manager components handle all files stored in untrusted memory. The trusted file manager component 225 encrypts/decrypts the content of all files that should be written/read with, for example, PAE_Enc/PAE_Dec using a unique file key SK.sub.f per file. The file key may be derived from a root key SK.sub.r (e.g., root key 270), which the trusted file manager 225 generates and seals on the first enclave start and unseals on subsequent enclave starts. All encrypted data is passed/received to/from the untrusted file manager component 260, which handles the actual memory access (e.g., internal operations read and write).
Regarding claim 12, Fuhry teaches wherein the application context is in a form of a token that is generated specifically for the client application and is not share with any other client applications(token grant permissions to a particular file, ¶70).
[0070] For example, the enclave 220 may transfer and/or receive encrypted data through an untrusted file manager component 260 that is outside of the enclave 220 transferring data to a trusted file manager component 225. A separation of trusted and untrusted file manager may not necessary if the trusted execution environment supports enclaves performing direct I/O. Consistent with implementations of the current subject matter, the data may be encrypted with a file key. The file key may be, for example, the file key unique to a particular file and derived from a root key generated by the enclave 220. According to aspects of the current subject matter, the encryption occurs within the enclave 220. The encrypted data may be decrypted in the enclave 220 and sent to the user over the channel including the secure interface.
Regarding claim 13, Fuhry teaches facilitating, by the cryptography agent via the encrypted token, an indirect communication between the client application and the server where the cryptography agent serves as an intermediary between the client application and the server(application on client accesses files from server though the enclave , ¶23).
[0023] The trusted execution environment, according to aspects of the current subject matter, may guarantee confidentiality and integrity protection to code and data in it, even in an untrusted environment, such as the server 110. Consistent with implementations of the current subject matter, the trusted execution environment may dedicate at least a portion of the system's main memory (e.g., RAM) for processor reserved memory (PRM). All code and data in the processor reserved memory may be encrypted while residing outside of the central processing unit, and decrypted and integrity checked when the data is loaded into the central processing unit. All other software on the system, including privileged software such as the operating system, hypervisor, and firmware, cannot access the processor reserved memory. The operating system may swap out enclave pages, and the trusted execution environment ensures integrity, confidentiality, and freshness of swapped-out pages. According to aspects of the current subject matter, programs using the trusted execution environment may also include an untrusted part, and the host process may invoke the enclave only through a well-defined interface.
Regarding claim 14, Fuhry teaches wherein a decryption of the received encrypted token is performed within the secure enclave(validation of token performed in enclave, ¶65).
[0065] According to aspects of the current subject matter, establishing the trusted relationship between the enclave 220 and the user may further include the user application 202 sending an authentication token (e.g. a client certificate) to the enclave 220. The enclave 220 may check the validity of the authentication token with coded (e.g., hardcoded) CA trust information (e.g., the CA's public key).
Regarding claim 20, Fuhry teach wherein one or more of the sealing, the storing, the generating, the providing, the receiving, the determining, the authenticating, and the executing are performed by a cryptography agent that resides in the unsecured portion of the electronic memory(system include untrusted file manager component outside the enclave, ¶46).
[0046] Trusted and untrusted file manager components handle all files stored in untrusted memory. The trusted file manager component 225 encrypts/decrypts the content of all files that should be written/read with, for example, PAE_Enc/PAE_Dec using a unique file key SK.sub.f per file. The file key may be derived from a root key SK.sub.r (e.g., root key 270), which the trusted file manager 225 generates and seals on the first enclave start and unseals on subsequent enclave starts. All encrypted data is passed/received to/from the untrusted file manager component 260, which handles the actual memory access (e.g., internal operations read and write).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights