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.
Examiner Interview Summary
Applicant-Initiated telephonic interview conducted on May 5, 2026. The Applicant was represented by Attorney Caroline Swindell. The amendment to claim 1, argument(s) over the 103 rejection and references cited in claim 1 of the previous non-final action were discussed. No agreement was made.
Response to Arguments
Applicant's arguments filed May 20th, 2026, have been fully considered but they are not persuasive.
The Applicant states, on page 10, In rejecting claim 1, the Action alleges that Villapakkam teaches creating a proxy key vault. However, none of the references teaches creating a proxy key vault in the cloud computing environment where the proxy key vault stores a reference to the external cryptographic key.
Respectively, the Examiner disagrees with the above remarks. Villapakkam describes claim 1 limitations creating, by the KMS, the proxy key vault in the cloud computing environment, where the proxy key vault stores a reference to the external cryptographic key as recited in the currently amended claim 1. Villapakkam para. [0007] FIG. 2 discloses a high-level schematic illustration of a cloud computing system which implements a cryptographic key management system. The proxy key vault in the cloud computing environment is disclosed in Villapakkam para. [0047] where the applications 112 can store data in the cloud in the data storage system 280 of the cloud computing platform. Villapakkam discloses in para. [0019] various types of applications 112 are disclosed as a reference to the external cryptographic key.
The Applicant states, on page 10, Villapakkam does not create or disclose a vault in the cloud computing environment that stores references to external keys.
Respectively, the Examiner disagrees with the above remarks. Villapakkam discloses a vault in the cloud computing environment that stores references to external keys in Villapakkam [0017] a key management service system 120 (alternately referred to herein as key management system) and a secure key vault 140 in Cloud Computing Platform 230. Villapakkam discloses stores references to external keys in para. [0025] the key proxies for the client applications 112 are passed between the client cryptography management system 114 and the key management system 120. A key proxy essentially serves as a proxy in place of a cryptographic key such that the actual cryptographic keys associated with the key proxy remain stored in the secure key vault 140 and never passed to the client applications 112.
The Applicant further states, on page 10, Lee does not store a reference to an external key and does not disclose a proxy key vault in the cloud computing system as claimed.
Respectively, Lee discloses the claim limitation of the external hardware device is configured to store the external cryptographic in Lee [Col. 5, Ln. 52-55].
Examiner recommends further clarification to the claimed invention such that the claimed invention teaches away from the currently cited prior arts.
Applicant submits, on page 11, Claims 7-12 and 18 are 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. Applicant thanks the Examiner for the indication of allowable subject matter but defers rewriting the claims at this time in view of the remarks above.
Claims 1, 3, 11, 15, and 20 are amended. Support for these amendments can be found in at least paragraphs 115 and 130 of the specification.
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(Currently Amended), 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([0007] “FIG. 2 is a high-level schematic illustration of a cloud computing system which implements a cryptographic key management system...”), a first vault creation request to create an internal key vault for accessing internal cryptographic keys; ([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 in the cloud computing environment([0017] “FIG. 1 is a high-level schematic illustration of a system 100 which implements a cryptographic key management system according to an exemplary embodiment of the disclosure. The system 100 comprises a client computing system 110, a key management service system 120 (alternately referred to herein as key management system), a data storage system 130, and a secure key vault 140.” where the key management service system 120 is in the cloud computing platform 230 para. [0043])([0021] “The key management system 120 implements methods that are configured to administer the full lifecycle of cryptographic keys that are used for encrypting and decrypting data of the client applications 112, and to protect the cryptographic keys from loss or unauthorized or malicious use. The key management system 120 securely maintains cryptographic keys in the secure key vault 140,”where the key management system 120 securely maintains cryptographic keys in a secure key vault 140 corresponds to creating the internal key by the KMS)([0023] “The key management system 120 implements various methods to support encryption/decryption services and for generating and managing cryptographic keys as follows. …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.”),
wherein creating the internal key vault comprises:
associating, by the KMS, an internal hardware device in the cloud computing 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.)
and 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 in the cloud computing environment, the proxy key vault storing a reference to an external cryptographic key of the external cryptographic keys([0019] “The applications 112(where the applications 112 can store data in the cloud in the data storage system 280 of the cloud computing platform [0047]) which execute on the client computing system 110 include one or more of various types of applications including, but not limited to, end-user applications, data storage applications, operating systems, storage servers, file systems, database applications, etc., or other types of applications which store and access data (e.g., encrypted data) to and from the data storage system 130.”)([0024] “The key proxy generation and assignment module 122 implements methods that are configured to generate key proxies and assign key proxies to the client applications 112. In some embodiments, a key proxy is an algorithmically generated tag or identifier which is assigned to a given client application or client device, and which serves to uniquely identify a set of one or more cryptographic keys which are associated with the given client application or client device. In some embodiments, a key proxy is created in such a manner that it does not look like a standard cryptographic key. A key proxy is decorated differently than a typical cryptographic key (e.g., different headers, different mathematical characteristics, etc.) so that a hacker searching, e.g., the client computing system 110 or the data storage system 130 for cryptographic keys will be unlikely to find or identify a key proxy.”)([0025] “The key proxies for the client applications 112 are passed between the client cryptography management system 114 and the key management system 120, and are used by the key management system 120 to identify the cryptographic keys to be used for
encrypting/decrypting data provided by the client applications 112. A key proxy essentially serves as a proxy in place of a cryptographic key such that the actual cryptographic keys associated with the key proxy remain stored in the secure key vault 140 and never passed to the client applications 112. In this regard, a key proxy is not used to encrypt or decrypt data, but rather a key proxy is utilized as a means for the key management system 120 to uniquely identify a set of one or more cryptographic keys which are associated with a given client application. As such, the use of key proxies abstracts the client applications 112 from knowledge of the actual cryptographic keys that are generated and utilized by the key management system 120 for providing cryptographic services to the client applications 112.) ([0026] “The key generation module 123 implements methods that are configured to generate cryptographic keys, as well as perform other functions such as deleting, archiving, and revoking cryptographic keys, etc.”)([0027] “In some embodiments, the key generation module 123 utilizes an API for a given key technology to create cryptographic keys, wherein a cryptographic key comprises a key value which is generated using techniques as discussed above, as well as a set of attributes which are specified by the given API and which describe the cryptographic key. In some embodiments, the set of key attributes for a given cryptographic key are stored in an attributes object, which contain all of the attributes associated with the cryptographic key. The attributes object is used to query key attributes of the cryptographic key. The key attributes include, for example, key value type and size attributes, a key identifier (alias) attribute (which an application uses to refer to the key), time stamp attributes such as a key creation time attribute and a key activation time attribute, a lifetime attribute which determines when the key expires, a policy which determines how the key can be utilized, and other relevant attributes which may be mandated by the key API. In addition, the given key API provides a provision to generate custom attributes which are used to tag additional information to the cryptographic key, as may be desired for a given application. As explained in further detail below, the cryptographic keys and associated attributes (e.g., name, activation date, size, etc.) are stored in the secure key vault 140 in association with key proxies.”)([0028] “In some embodiments, the key generation module 123 implements methods that are configured to generate key cryptographic keys that are used for encrypting and decrypting the cryptographic keys that are stored in the secure key vault 140. In such embodiments, the cryptographic keys can be stored in the secure key vault 140 in encrypted form so that the secure key vault 140 is protected even if a rogue actor is able to access the secure key vault 140 (e.g., by stealing a persistent storage device which comprises the secure key vault 140)”)([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, wherein the credentials include one or more of (i) credentials of the client computing system, (ii) credentials of the requesting user/application, and/or (iii) credentials of the particular instance of the client cryptography management system 114 running on the client computing system. In addition, the key management system 120 can send its credentials to the client cryptography management system 114 for verification. In some embodiments, sending credentials includes generating a digital signature by signing a known message with a private key that is preassigned to, e.g., the client cryptography management system 114 or the client computing system 110, wherein the key management system 120 can then verify the digital signature using a paired public key that is published for client cryptography management system 114 or the client computing system 110. The authentication process is performed to provide security against spoof attacks that can be perpetrated by a hacker. The authentication process can be performed using any suitable PKI (public key infrastructure) authentication process such as verification of certificates using a CA (certificate authority). Following authentication, a secure channel is established between the client cryptography management system 114 and the key management system 120 using a protocol such as, Transport Layer Security (TLS), Secure Shell (SSH), or similar protocols or known key exchange or key agreement protocols.”),
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”),
and 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 computing 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)([0024] A key proxy is decorated differently than a typical cryptographic key (e.g., different headers, different mathematical characteristics, etc.) so that a hacker searching, e.g., the client computing system 110 or the data storage system 130 for cryptographic keys will be unlikely to find or identify a key proxy.);
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(Currently Amended), 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(Currently Amended), 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(Original), 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(Original), 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(Currently Amended), 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 computing 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 computing 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.”)(Hoy Col. 8, Ln 51-53 “Referring now to FIG. 3, by way of additional background, a set of functional abstraction layers provided by a cloud computing environment is shown” )
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 computing 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(Original), 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(Original), 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(Original), 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(Original), 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(Original), 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(Original), 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(Original), 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
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MALA BOYD whose telephone number is (571)272-6450. The examiner can normally be reached M-F 7:30-4:00.
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, Eleni A. 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/Examiner, Art Unit 2497 /BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
Prosecution Insights