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 .
Information Disclosure Statement
The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 (i.e., changing from AIA to pre-AIA ) 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, 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.
Claim(s) 1, 2, 15, 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Villapakkam et al. (US 2022/0271929 A1) (hereinafter Villapakkam) in view of Seyfried et al. (Pub. No. US 2020/0204357 A1) (hereinafter Seyfried) and further in view of Lee et al. (US 11,611,558 B2).
Regarding claim 1, Villapakkam teaches, One or more non-transitory computer readable media comprising instructions that, when executed by one or more hardware processors, cause performance of operations comprising: (Villapakkam Figure 6 [0073] “FIG. 1 comprise program code that is loaded into the system memory 610, and executed by the processors 602 to perform respective functions as described herein.”), cause performance of operations comprising:
receiving, at a key management service (KMS) operating in a cloud computing environment, a first vault creation request to create an internal key vault for accessing internal cryptographic keys; ([0007] “FIG. 2 is a high-level schematic illustration of a cloud computing system which implements a cryptographic key management system...”); ([0062] “In response to receiving the cryptographic request, the key management system 120 proceeds to determine a key vault which contains the target cryptographic key that is associated with the key proxy... More specifically, in some embodiments, assuming the key management system 120 is currently managing a plurality of key vaults including the primary (default) key vault 140 and one or more additional key vaults… to determine which key vault hosts the cryptographic key”, where the cryptographic request correspond to the first vault creation request, where the target cryptographic key within a specific vault in 140 is associated with one of the internal keys 150 illustrated in Figure 1, where the request is received from 114, as disclosed in [0020] “…the cryptography management system 114 is configured to establish a secure communications channel with the key management system 120 and pass cryptographic requests (e.g., data encryption requests or data decryption requests) received from the applications 112, along with key proxy information and plaintext data or encrypted data, to the key management system 120.”, where 114 is inside the 210 and is interpreted as the first request, where 114 in 240 perform the same function as 114 in the client device 210 as disclosed in [0047]);
creating, by the KMS, the internal key vault, wherein creating the internal key vault comprises:
associating, by the KMS, an internal hardware device in the cloud environment with the
internal key vault, ([0047] and Figure 2 illustrates application server 240, i.e. internal hardware device, which is in the cloud computing platform 230 and comprising cryptography management system 114, which through the KMS 120, is associated with key vault 140 in the key storage server 260 to perform data encryption/decryption for connected users and entities as disclosed in:
([0046] “The application server 240 is configured to host and manage one or more applications, which are used by multiple, simultaneously connected users and/or entities in one or more application domains.”),
([0047] “…the cryptography management system 114 which executes on the application server 240 is configured to securely communicate with the key management system 120 (hosted by the key management server 250) to access data encryption and data decryption services provided by the key management system 120 on behalf of the applications that are hosted by the application server 240 and other compute nodes of the cloud computing platform 230.”),
([0023] “The cryptographic keys for the client applications 112 are securely maintained in the secure key vault 140, and retrieved and utilized by the key management system 120 to provide data encryption and decryption services to the client applications 112.”, where the cryptography management system 114 inside the application 240 perform the same functions as for the client 210 as disclosed in [0047] therefore, 240, i.e. internal device, is associated with a key vault 140 through the KMS 120.)
adding, by the KMS to a set of endpoint records, a first endpoint record associated with
the internal key vault; (Villapakkam [0013] “…a cryptographic key management system will manage a plurality of different key vaults with different technologies and application programming interfaces (APIs), and maintain a global mapping which maps cryptographic keys to the different key vaults, wherein such mapping is utilized by the cryptographic key management system to determine which key vault hosts a given cryptographic key.”, [0034] “…the key proxy-to-cryptographic key mapping module 125 can be utilized by the key management system 120 to determine which key vault, among a plurality of key vaults (including the primary key vault 140 and one or more additional key vaults), hosts a cryptographic key associated with the a given key proxy.”, where the KMS keeps a mapping record associating each key vault with its corresponding key, where a generated key proxy and its associated mapping to a key vault and generated key (122 and 123 in the KMS 120 in Figure 2) associated with users/entities managed by 240 is interpreted as a first record);
receiving, at the KMS, a second vault creation request to create a proxy key vault for accessing
external cryptographic keys; ([0007] “FIG. 2 is a high-level schematic illustration of a cloud computing system which implements a cryptographic key management system...”); ([0062] “In response to receiving the cryptographic request, the key management system 120 proceeds to determine a key vault which contains the target cryptographic key that is associated with the key proxy... More specifically, in some embodiments, assuming the key management system 120 is currently managing a plurality of key vaults including the primary (default) key vault 140 and one or more additional key vaults…to determine which key vault hosts the cryptographic key”, where the cryptographic request correspond to the second vault creation request, where the target cryptographic key within a specific vault in 140 is associated with one of the internal keys 150 illustrated in Figure 1, where the request is received from 114, as disclosed in [0020] “…the cryptography management system 114 is configured to establish a secure communications channel with the key management system 120 and pass cryptographic requests (e.g., data encryption requests or data decryption requests) received from the applications 112, along with key proxy information and plaintext data or encrypted data, to the key management system 120.”, where 114 is interpreted as the second request, where 114 in 240 perform the same function as 114 in the client device 210 as disclosed in [0047]); and
creating, by the KMS, the proxy key vault, wherein creating the proxy key vault comprises:
creating, by the KMS, an authenticated communication path between the proxy key vault
and an external hardware device ([0017] and Figure 2 illustrates client 210, i.e. external hardware device, comprising cryptography management system 114, which through the KMS 120, is associated with additional key vaults, as disclosed in [0034, 0062] to perform data encryption/decryption, where the client device is authenticated with KMS as disclosed in [0050] “More specifically, in some embodiments, an authentication process comprises the client cryptography management system 114 sending credentials to the key management system 120 for verification… Following authentication, a secure channel is established between the client cryptography management system 114 and the key management system 120”, and based on the authentication the client is allowed access to the specific additional key vault as illustrated in Figure 5 501 and 502),
adding, by the KMS to the set of endpoint records, a second endpoint record associated with the proxy key vault; ([0013] “…a cryptographic key management system will manage a plurality of different key vaults with different technologies and application programming interfaces (APIs), and maintain a global mapping which maps cryptographic keys to the different key vaults, wherein such mapping is utilized by the cryptographic key management system to determine which key vault hosts a given cryptographic key.”, [0034] “…the key proxy-to-cryptographic key mapping module 125 can be utilized by the key management system 120 to determine which key vault, among a plurality of key vaults (including the primary key vault 140 and one or more additional key vaults), hosts a cryptographic key associated with the a given key proxy.”, where the KMS keeps a mapping record associating each key vault with its corresponding key, where a generated key proxy and its associated mapping to a key vault and generated key (122 and 123 in the KMS 120 in Figure 2) associated with users/entities managed by client 210 is interpreted as a second record);
wherein data stored in the cloud environment is encrypted/decrypted using a set of cryptographic keys comprising the internal cryptographic keys and the external cryptographic keys (Figure 5 505 data encrypted/decrypted using cryptographic keys in vault 140, interpreted as internal keys, and data encrypted/decrypted using cryptographic keys in additional/different/external vaults interpret as external keys);
wherein the set of endpoint records is a directory for a set of key vaults comprising the internal key vault and the proxy key vault. ([0013] “…a cryptographic key management system will manage a plurality of different key vaults with different technologies and application programming interfaces (APIs), and maintain a global mapping which maps cryptographic keys to the different key vaults, wherein such mapping is utilized by the cryptographic key management system to determine which key vault hosts a given cryptographic key.” and further disclosed in [0034] the mapping is interpreted as records or directory the map the plurality of vaults, i.e. internal and external, to their respective keys).
Villapakkam fails to teach wherein the internal hardware device is configured to store the
internal cryptographic keys;
However, Seyfried teaches wherein the internal hardware device is configured to store the
internal cryptographic keys; (Seyfried [0062] As shown in FIG. 7, the network server 700 may include a processing device 710… the processing device 710 may include one or more internal cryptographic keys 711 that may be used to encrypt and decrypt data stored in a portion of a memory that is assigned to a secure enclave of the key management system 730… the key management system 730 may be protected by the use of one of the internal cryptographic keys 711 that are internal to the processing device 710 ”)
Villapakkam and Seyfried are analogues in that they are both in the same field of cryptography. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam to incorporate the teachings of Seyfried wherein the internal hardware device is configured to store the internal cryptographic keys. Doing so would aid
in improving the security of cryptographic items stored by a key management system. [0024] Seyfried
The combination of Villapakkam and Seyfried fails to teach wherein the external hardware device is configured to store the external cryptographic keys.
However, Lee teaches wherein the external hardware device is configured to store the external cryptographic (Lee, Col. 5, Ln. 52-55 “The KEK 154 is only stored external or independent to the remote system 112 and the cloud key system 110 never has access to the KEK 154.”)
Villapakkam, Seyfried and Lee are analogues in that they are all in the same field of cryptography. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam and Seyfried to incorporate the teachings of Lee wherein the external hardware device is configured to store the external cryptographic. Doing so allows clients to achieve separation between keys and data which allows for the support of high security and/or compliance objectives. Col. 4, Ln. 63-65 Lee
Regarding claim 15, the Method of claim 15 is directed to claim 1 that recites similar limitation as claim 1 and is being rejected based on the same rational and motivation as claim 1 above.
Regarding claim 20, a system of claim 1 and further recites similar limitation as claim 1 and is being rejected based on the same rational and motivation as claim 1 above.
Regarding claim 2, Villapakkam in view of Seyfried and Lee teaches The non-transitory media of Claim 1, outlined above.
The combination of Villapakkam in view of Seyfried fails to teach wherein no component of the cloud computing environment stores the external cryptographic keys.
However, Lee teaches wherein no component of the cloud computing environment stores the external cryptographic keys. (Lee, Col. 5, Ln. 52-55 “The KEK 154 is only stored external or independent to the remote system 112 and the cloud key system 110 never has access to the KEK 154.”)
Villapakkam in view of Seyfried, and further in view of Lee, are analogues in that they are all in the same field of cryptography. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam in view of Seyfried to incorporate the teachings of Lee wherein no component of the cloud computing environment stores the external cryptographic keys. Doing so would aid the client to have control over usage of keys, maintain key provenance, and manage keys from a central key management service or system. Col. 4, Ln. 65-67 Lee
Regarding claim 16, claim 16 is directed to the Method of claim 15 and further recites similar limitation as claim 2 and is being rejected based on the same rational as claim 2 above.
Claim(s) 3 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Villapakkam et al. (US 2022/0271929 A1) (hereinafter Villapakkam) in view of Seyfried et al. (Pub. No. US 2020/0204357 A1) (hereinafter Seyfried) and further in view of Lee et al. (US 11,611,558 B2) (hereinafter Lee) and further in view of Hoy et al. (US 10,834,100 B2)(hereinafter Hoy).
Regarding claim 3, Villapakkam in view of Seyfried and Lee teaches, The non-transitory media of Claim 1, outlined above.
The combination of Villapakkam in view of Seyfried and Lee fails to teach, wherein the first vault creation request and the second vault creation request are initiated by a same cloud environment entity of the cloud environment.
However, Hoy teaches wherein the first vault creation request and the second vault creation request are initiated by a same cloud environment entity of the cloud environment. (Hoy Col 1 Ln. 64 and Col. 2 Ln. 1-11 “In a first virtual private network (VPN) manager a request is received from a first cloud application resident in the first cloud. The request includes a first set of requirements for a first VPN tunnel in the plurality of VPN tunnels. The VPN manager sends a first VPN manager request to a first system in a first cloud, wherein the first system creates the first VPN tunnel according to the first set of requirements. The VPN manager receives a request from a second cloud application resident in the first cloud. The request includes a second set of requirements for a VPN tunnel in the plurality of VPN tunnels. The VPN manager sends a second VPN manager request to the system in a first cloud, wherein the second VPN manager request contains the second set of requirements.”)
Villapakkam in view of Seyfried, and further in view of Lee and further in view of Hoy, are analogues in that they are all in the same field of cloud computer environment security. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam in view of Seyfried and in view of Lee to incorporate the teachings of Hoy wherein the first vault creation request and the second vault creation request are initiated by a same cloud environment entity of the cloud environment.
Doing so would aid in the need for secure communication between applications between different cloud hosting environments. Col. 2, Ln. 63-65 Hoy
Regarding claim 17, claim 17 is directed to the Method of claim 15 and further recites similar limitation as claim 3 and is being rejected based on the same rational as claim 3 above.
Claim(s) 4, 5, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Villapakkam et al. (US 2022/0271929 A1) (hereinafter Villapakkam) in view of Seyfried et al. (Pub. No. US 2020/0204357 A1)(hereinafter Seyfried) and further in view of Lee et al. (US 11,611,558 B2) (hereinafter Lee)and further in view of Oxman et al. (Pub. No. US 2023/0123734 A1) (hereinafter Oxman).
Regarding claim 4, Villapakkam in view of Seyfried and Lee teaches, The non-transitory media of Claim 1, outlined above.
The combination of Villapakkam in view of Seyfried and further in view of Lee fails to teach wherein the set of endpoint records is a set of Domain Name System (DNS) records.
However, Oxman teaches wherein the set of endpoint records is a set of Domain Name System (DNS) records. (Oxman [0043] “Network 301 can also contain a Domain Name System (DNS) module 312 which is coupled with service endpoint 311. DNS module 312 can contain an index of various domain names or other pointers and IP or other addresses associated with those domain names and pointers.”)
Villapakkam in view of Seyfried, Lee and further in view of Oxman, are analogues in that they are all in the same field of cloud computing security. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam in view of Seyfried and further in view of Lee to incorporate the teachings of Oxman wherein the set of endpoint records is a set of Domain Name System (DNS) records. Doing so, the owner, user, administrator or controller of network can create a service connection in order to connect to a service attachment which can be exposed within network. [0044] Oxman
Regarding claim 5, Villapakkam in view of Seyfried, and Lee teaches, The non-transitory media of Claim 4, outlined above.
The combination of Villapakkam in view of Seyfried and further in view of Lee fails to teach wherein the set of endpoint records is a set of private DNS records.
However, Oxman teaches wherein the set of endpoint records is a set of private DNS records.
(Oxman [0043] “The service endpoint can contain “private” entries within DNS module 312 which can be used to establish the private service connection.”)
Villapakkam in view of Seyfried, Lee and further in view of Oxman, are analogues in that they are all in the same field of cloud computing security. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam in view of Seyfried and further in view of Lee to incorporate the teachings of Oxman wherein the set of endpoint records is a set of private DNS records. Doing so, the service endpoint can contain “private” entries within DNS module which can be used to establish the private service connection. [0043] Oxman
Regarding claim 13, Villapakkam in view of Seyfried and Lee teaches, The non-transitory media of Claim 1, outlined above.
The combination of Villapakkam in view of Seyfried and further in view of Lee fails to teach authenticated communication path comprises a reverse-connection private endpoint (RCE) configured to communicatively couple the proxy key vault to the external hardware device.
However, Oxman teaches authenticated communication path comprises a reverse-connection private endpoint (RCE) configured to communicatively couple the proxy key vault to the external hardware device. (Oxman [0018] “The primary reference discloses using "communicatively couple the proxy key vault to the external hardware device", however, the primary reference does not disclose using "reverse connection". Oxman (US 20230123734) discloses [0018] “FIG. 6 illustrates an example of a “reverse connection” through the use of a service to initiate a private connection to remote endpoints." and further in [0060].”)
Villapakkam in view of Seyfried, Lee and further in view of Oxman, are analogues in that they are all in the same field of cloud computing security. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam in view of Seyfried and further in view of Lee to incorporate the teachings of Oxman authenticated communication path comprises a reverse-connection private endpoint (RCE) configured to communicatively couple the proxy key vault to the external hardware device. Doing so would aid in the needs to connect to a service in another network, a “reverse connection” can be the case where the service initiates the connection to arbitrary endpoints in the “consumer” network. [0060] Oxman
Claim(s) 14 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Villapakkam et al. (US 2022/0271929 A1) (hereinafter Villapakkam) in view of Seyfried et al. (Pub. No. US 2020/0204357 A1)(hereinafter Seyfried) and further in view of Lee et al. (US 11,611,558 B2) (hereinafter Lee) and further in view of Ray et al. (US 2015/0312268 A1) (hereinafter Ray).
Regarding claim 14, Villapakkam in view of Seyfried and Lee teaches, The non-transitory media of Claim 1, outlined above.
The combination of Villapakkam in view of Seyfried and further in view of Lee the operations further comprising: transmitting, by the proxy key vault, a first heartbeat signal to the external hardware device to
determine a status associated with at least one of the external hardware device or one or
more of the external cryptographic keys; and
responsive to receiving an indication that the external hardware device is unavailable and/or that
one or more of the external cryptographic keys are unavailable or invalid, raising an alert
corresponding to the indication.
However, Ray teaches transmitting, by the proxy key vault, a first heartbeat signal to the external hardware device to determine a status associated with at least one of the external hardware device or one or more of the external cryptographic keys; and (Ray [0077] “The heartbeat may include a periodic signal from the endpoint to the gateway to indicate a status of the endpoint…The heartbeat may, for example be encrypted and/or signed by the endpoint, or it may use its own internal key value, or it may be hardened by specific hardware or any other mechanisms to improve its robustness against adversarial code on the endpoint, and may include at least one item unique to the endpoint to facilitate authentication. The heartbeat may transmit signed packets to provide validation of the authenticity of the heartbeat packets.”)
responsive to receiving an indication that the external hardware device is unavailable and/or that
one or more of the external cryptographic keys are unavailable or invalid, raising an alert
corresponding to the indication. (Ray [0078] …“the interruption may include an authentication failure in the periodic signal such as from an authentication attempt using a public key for the originating endpoint.”); ([0086] “As shown in step 508, the method 500 may include receiving a notification from a gateway between the endpoint and a data network that network traffic from the endpoint includes a violation of a network policy for the endpoint.”)
Villapakkam in view of Seyfried, Lee and further in view of Ray, are analogues in that they are all in the same field of cloud computing security. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam in view of Seyfried and further in view of Lee to incorporate the teachings of Ray transmitting, by the proxy key vault, a first heartbeat signal to the external hardware device to determine a status associated with at least one of the external hardware device or one or more of the external cryptographic keys; and responsive to receiving an indication that the external hardware device is unavailable and/or that one or more of the external cryptographic keys are unavailable or invalid, raising an alert corresponding to the indication.
Doing so would aid in a secure heartbeat such as a cryptographically secured heartbeat using any of a variety of cryptographic techniques to secure contents of the heartbeat against tampering and to provide for authentication of the heartbeat or the source thereof. [0078] Ray
Regarding claim 19, claim 19 is directed to the Method of claim 15 and further recites similar limitation as claim 14 and is being rejected based on the same rational as claim 14 above.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Villapakkam et al. (US 2022/0271929 A1) (hereinafter Villapakkam) in view of Seyfried et al. (Pub. No. US 2020/0204357 A1)(hereinafter Seyfried) and further in view of Lee et al. (US 11,611,558 B2)(hereinafter Lee), Oxman et al. (Pub. No. US 2023/0123734 A1) (hereinafter Oxman) and further in view of LATOUR et al. (US 11,350,276 B2) (hereinafter LATOUR).
Regarding claim 6, Villapakkam in view of Seyfried and Lee teaches, The non-transitory media of Claim 1, outlined above.
While Oxman discloses DNS entries in contrast with private DNS entries in [0043], which indicate that DNS entries are public entries, however the combination of Villapakkam in view of Seyfried and in further view of Lee and further in view of Oxman fails to explicitly teach wherein the set of endpoint records is a set of public DNS records.
However, Latour teaches wherein the set of endpoint records is a set of public DNS records. (LATOUR [0017] “The registry system provides a new root of trust, simplify the validation of cloud service providers certificates and individual IoT device keys by using the cryptographically enabled public domain name system (DNS) infrastructure. [0022] The database can also provide an authoritative DNS for storing and providing DNSSEC signed CERT records.”)
Villapakkam in view of Seyfried, Lee and further in view of LATOUR, are analogues in that they all are in the same field of cloud computing security. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Villapakkam in view of Seyfried and further in view of Lee to incorporate the teachings of LATOUR wherein the set of endpoint records is a set of public DNS records. Doing so would aid in authentication and data integrity utilizing Domain Name System (DNS) public infrastructure. [0018] LATOUR
Allowable Subject Matter
Claim 7-12 and 18 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
With respect to claim 7, the prior arts of record do not disclose “a first request for a first cryptographic operation, the first request comprising a first identifier of the internal key vault associated with an internal cryptographic key to be used in the first cryptographic operation; performing the first cryptographic operation within the internal key vault; receiving, by the KMS from the internal key vault, a first set of results of the first cryptographic operation; receiving, a second request for a second cryptographic operation, the second request comprising a second identifier of the proxy key vault associated with an external cryptographic key to be used in the second cryptographic operation; forwarding the second request from the proxy key vault to the external hardware device via the authenticated communication path; and receiving, by the proxy key vault from the external hardware device, a second set of results of the second cryptographic operation.” ;” in conjunction with the remaining limitations in claim 7 and the base claim 1.
With respect to claim 18, the prior arts of record, Seyfried, Lee and Oxman, do not disclose “a first request for a first cryptographic operation, the first request comprising a first identifier of the internal key vault associated with an internal cryptographic key to be used in the first cryptographic operation; performing the first cryptographic operation within the internal key vault; receiving, by the KMS from the internal key vault, a first set of results of the first cryptographic operation; receiving, at the KMS from the cloud environment entity, a second request for a second cryptographic operation, the second request comprising a second identifier of the proxy key vault associated with an external cryptographic key to be used in the second cryptographic operation; forwarding the second request from the proxy key vault to the external hardware device via the authenticated communication path; and receiving, by the proxy key vault from the external hardware device, a second set of results of the second cryptographic operation.”, in conjunction with the remaining limitations of claim 18.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Tucker et al. (US 10,972,445 B2) teaches dynamic crypto key management for mobility tin a cloud environment.
McCallum (US 2017/0149564 A1) teaches network bound decryption with offline encryption
VATS et al. (Pub. No.: US 2020/0127823 A1) teaches rewiring cryptographic key management system service instances.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mala Boyd whose telephone number is (571) 272-6450. The examiner can normally be reached on M-F 7:30-4:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached at (571) 272-3867. 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.
/Mala Boyd/Patent ExaminerArt Unit 2497
/ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497