Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Office Action is in response to the Amendment filed on 12/05/2025.
Claims 1-20 are pending. This Action is made FINAL.
Response to Arguments
The rejections of claims 16-20 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph are withdrawn as the claims have been amended.
Applicants’ arguments in the instant Amendment, filed on 12/05/2025, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: Claim 1 recites "transmitting a first request, including the context identifier, for an encrypted key stored in a record associated with the context identifier to a key broker server; receiving the encrypted key from the key broker server; transmitting a second request, including the encrypted key, for a data encryption key to a key management server; ...." (Emphasis added.) Kennedy is not understood teach or suggest these limitations of claim 1."
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Kennedy discloses transmitting a first request, including the context identifier, for an encrypted key stored in a record associated with the context identifier to a key broker server; receiving the encrypted key from the key broker server; transmitting a second request, including the encrypted key, for a data encryption key to a key management server. As seen in paragraph 0073 of Kennedy. Kennedy teaches that receive an encryption request from a first server that includes an identifier for one or more users; select a key management server based on the identifier; transmit, using the network interface, a request for a data encryption key to the selected key management server. Further as seen in paragraphs Kennedy par. 0074 and 0075 of Kennedy. Kennedy teaches that receive, using the network interface, a plaintext key and an encrypted key from the key management server; in response to the encryption request, transmit the plaintext key and the encrypted key to the first server and transmit a request for a data encryption key to the selected key management server, the request including the encrypted key. Therefore, Kennedy discloses transmitting a first request, including the context identifier, for an encrypted key stored in a record associated with the context identifier to a key broker server; receiving the encrypted key from the key broker server; transmitting a second request, including the encrypted key, for a data encryption key to a key management server.
Applicant’s arguments: Shah is not understood to teach or suggest transmitting a first request, including the context identifier, for an encrypted key stored in a record associated with the context identifier to a key broker server; and receiving the encrypted key from the key broker server, as recited by claim 1."
The Examiner disagrees with the Applicants. The Examiner respectfully submits that the combination of Kennedy and Sha does disclose transmitting a first request, including the context identifier, for an encrypted key stored in a record associated with the context identifier to a key broker server; and receiving the encrypted key from the key broker server, as recited by claim 1. As seen in paragraphs 0073 and 0074 of Kennedy. Kennedy teaches that receive an encryption request from a first server that includes an identifier for one or more users; select a key management server based on the identifier; transmit, using the network interface, a request for a data encryption key to the selected key management server and store the encrypted key and data encrypted with the plaintext key in non-volatile memory at the destination address. Further as seen in paragraphs 0028 and 0085 of Sha. Sha teaches that decrypt request 502 can be submitted to a cryptography service instance or an endpoint routing service 512. In some examples, a Decrypt request 502 is obtained by a cryptography service instance, in which the cryptography service instance decrypts ciphertext indicated by Ciphertext Data 506 using one or more keys indicated by KeyID 504. An Encrypt(KeyID, Data, Encryption Configuration) request can be used to cause a cryptography service instance to encrypt specified data using a key identified by the KeyID, which can refer to an identifier that uniquely resolves to a particular managed key. Therefore, the combination of Kennedy and Sha does disclose transmitting a first request, including the context identifier, for an encrypted key stored in a record associated with the context identifier to a key broker server; and receiving the encrypted key from the key broker server, as recited by claim 1.
Independent claims 9 and 16 directed to a system and a method respectively that perform a method at least similar to that disclosed in claim1 and claims 2-8, 10-15 and 17-20 depend from claims 1, 9 and 16. Thus Applicants’ arguments with respect to claims 1-20, have been fully considered but they are not persuasive for at least the reasons explained above with respect to claim 1.
Thus, all the limitations are still obvious over the prior art of record. Please see the rejection below.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kennedy (US 2023/0078187) and in view of Sah (US 2022/0179972).
Regarding claim 1, Kennedy discloses a method comprising:
receiving a decryption request, including an identifier, from a client (Kennedy abstract and par. 0075; A key broker server is employed to map encryption and decryption requests from servers in the platform to key management servers of customers based on user identifiers);
transmitting a first request, including the context identifier, for an encrypted key stored in a record associated with the identifier to a key broker server (Kennedy par. 0073; Receive an encryption request from a first server that includes an identifier for one or more users; select a key management server based on the identifier; transmit, using the network interface, a request for a data encryption key to the selected key management server);
receiving the encrypted key from the key broker server (Kennedy par. 0073; Receive, using the network interface, a plaintext key and an encrypted key from the key management server; in response to the encryption request, transmit the plaintext key and the encrypted key to the first server; and delete the plaintext key);
transmitting a second request, including the encrypted key, for a data encryption key to a key management server (Kennedy par. 0075; Receive a decryption request from a first server that includes an identifier for one or more users and an encrypted key; select a key management server based on the identifier; transmit a request for a data encryption key to the selected key management server, the request including the encrypted key);
receiving a plaintext key from the key management server (Kennedy par. 0075; Receive a plaintext key from the key management server); and
transmitting the plaintext key to the client in response to the decryption request (Kennedy par. 0075; Receive a plaintext key from the key management server in response to the decryption request, transmit the plaintext key to the first server).
Kennedy discloses transmitting a request with an identifier and receiving a plaintext key from the key management server (Kennedy par. 0075). However, Kennedy does not explicitly disclose receiving a decryption request, including a context identifier.
However, in an analogous art, Sah discloses receiving a decryption request, including a context identifier (Sah par. 0028 and 0085; Decrypt request 502 can be submitted to a cryptography service instance or an endpoint routing service 512. In some examples, a Decrypt request 502 is obtained by a cryptography service instance, in which the cryptography service instance decrypts ciphertext indicated by Ciphertext Data 506 using one or more keys indicated by KeyID 504. An Encrypt(KeyID, Data, Encryption Configuration) request can be used to cause a cryptography service instance to encrypt specified data using a key identified by the KeyID, which can refer to an identifier that uniquely resolves to a particular managed key. Inputs to a KeyID parameter can include one or more data objects, such as strings, that indicate or otherwise identify one or more cryptographic keys. See also par. 0029).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the request of Kennedy using the request with identifier taught in Sah in order to provides the data structure and the data key in response to the request (Sah abstract).
Regarding claim 2, Kennedy and Sah disclose the method of claim 1,
Kennedy further discloses wherein the decryption request includes an authorization token that includes the context identifier and is digitally signed by a server storing encrypted data associated with the context identifier, and comprising: verifying the authorization token before transmitting the first request (Kennedy par. 0070 and 0071; When the one or more key management servers 422 verify user permissions for the requested encryption or decryption, a data encryption key is returned to the key broker server 410, which in turn relays the data encrypting or decrypting encryption key to the requesting server for use in encrypting or decrypting data. the system 400 is configured to prevent customers from encrypting and decrypting to a different customer's key by using an account ID unique to each customer. A customer may be enabled to log events in a fine-grained fashion. For example, a customer may be enabled to prevent encryption and decryption events based on asset type, time, and other variables, such as type of asset (e.g., Conference/Webinar recordings vs. Calendar Token), individual assets identified by some characteristics (e.g., prevent decryption of a certain conference recording), or timestamps (e.g., prevent decryption for assets that were created between time X and time Y).).
Regarding claim 3, Kennedy and Sah disclose the method of claim 1,
Kennedy further discloses comprising: caching the plaintext key on a local device (Kennedy par. 0074; Store the encrypted key and data encrypted with the plaintext key in non-volatile memory at the destination address).
Regarding claim 4, Kennedy and Sah disclose the method of claim 1,
Kennedy further discloses comprising: authenticating the decryption request using an identity provider server (Kennedy par. 0082; the encrypted key 552 is read from non-volatile memory (e.g., a disk) on the database server 516 by the media server 514 when it prepares to access the encrypted asset 562. At 640, the encrypted key 552 is passed from the media server 514 to the key broker server 512 in a request for decryption. At 642, a request for decryption of the encrypted key 552 is sent from the key broker server 512 to the key management server 522. At 644, the key management server 522 sends a message to the log server 526 to log the activity of the request at 64).
Regarding claim 5, Kennedy and Sah disclose the method of claim 1,
Kennedy further discloses wherein the client is a first client, and comprising: receiving a second decryption request, including the context identifier, from a second client; and in response to the second decryption request, transmitting the plaintext key to the second client (Kennedy par. 0075; The key broker server may also be configured to facilitate decryption. In some implementations, the memory stores instructions executable by the processor to receive a decryption request from a first server that includes an identifier for one or more users and an encrypted key; select a key management server based on the identifier; transmit a request for a data encryption key to the selected key management server, the request including the encrypted key; receive a plaintext key from the key management server; in response to the decryption request, transmit the plaintext key to the first server; and delete the plaintext key).
Regarding claim 6, Kennedy and Sah disclose the method of claim 1,
Kennedy further discloses wherein the client uses the plaintext key to decrypt an encrypted recording of a conference to obtain a decrypted recording (Kennedy par. 0076; The media server 402 is configured to decrypt an encrypted recording of a conference conducted by the first server using the plaintext key to obtain a decrypted recording).
Regarding claim 7, Kennedy and Sah disclose the method of claim 1,
Kennedy further discloses wherein the first request is transmitted via a wide area network (Kennedy par. 0045; The clients 104A through 104D communicate with the servers 108 through 112 of the datacenter 106 via the network 114. The network 114 can be or include, for example, the Internet, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), or another public or private means of electronic computer communication capable of transferring data between a client and one or more servers. In some implementations, a client can connect to the network 114 via a communal connection point, link, or path, or using a distinct connection point, link, or path. For example, a connection point, link, or path can be wired, wireless, use other communications technologies, or a combination thereof.).
Regarding claim 8, Kennedy and Sah disclose the method of claim 1,
Kennedy further discloses wherein the first request is transmitted through a firewall (Kennedy par. 0048; The load balancer 116 can operate as a firewall, allowing or preventing communications based on configuration settings. Although the load balancer 116 is depicted in FIG. 1 as being within the datacenter 106, in some implementations, the load balancer 116 can instead be located outside of the datacenter 106, for example, when providing global routing for multiple datacenters. In some implementations, load balancers can be included both within and outside of the datacenter 106. In some implementations, the load balancer 116 can be omitted).
Regarding claims 9-15; claims 9-15 are directed to a method associated with the system claimed in claims 1 and 3-8 respectively. Claims 9-15 are similar in scope to claims 1 and 3-8 respectively, and are therefore rejected under similar rationale.
Regarding claim 16, Kennedy discloses a method comprising:
receiving an encryption request from a client (Kennedy abstract and par. 0075; A key broker server is employed to map encryption and decryption requests from servers in the platform to key management servers of customers based on user identifiers);
transmitting a first request for a data encryption key to a key management server (Kennedy par. 0073; Receive an encryption request from a first server that includes an identifier for one or more users; select a key management server based on the identifier; transmit, using the network interface, a request for a data encryption key to the selected key management server);
receiving a plaintext key and an encrypted key, which has been determined based on the plaintext key from the key management server (Kennedy par. 0073; Receive, using the network interface, a plaintext key and an encrypted key from the key management server; in response to the encryption request, transmit the plaintext key and the encrypted key to the first server; and delete the plaintext key);
transmitting a second request, including the encrypted key, to a key broker server to have the encrypted key stored in a record associated with a identifier (Kennedy par. 0075; Receive a decryption request from a first server that includes an identifier for one or more users and an encrypted key; select a key management server based on the identifier; transmit a request for a data encryption key to the selected key management server, the request including the encrypted key);
receiving a plaintext key from the key management server (Kennedy par. 0075; Receive a plaintext key from the key management server ); and
transmitting the plaintext key to the client in response to the encryption request (Kennedy par. 0075; Receive a plaintext key from the key management server in response to the decryption request, transmit the plaintext key to the first server).
Kennedy discloses transmitting a request with an identifier and receiving a plaintext key from the key management server (Kennedy par. 0075). However, Kennedy does not explicitly disclose receiving a request, including a record associated with a context identifier.
However, in an analogous art, Sah discloses receiving a request, including a record associated with a context identifier (Sah par. 0028 and 0085; Decrypt request 502 can be submitted to a cryptography service instance or an endpoint routing service 512. In some examples, a Decrypt request 502 is obtained by a cryptography service instance, in which the cryptography service instance decrypts ciphertext indicated by Ciphertext Data 506 using one or more keys indicated by KeyID 504. An Encrypt(KeyID, Data, Encryption Configuration) request can be used to cause a cryptography service instance to encrypt specified data using a key identified by the KeyID, which can refer to an identifier that uniquely resolves to a particular managed key. Inputs to a KeyID parameter can include one or more data objects, such as strings, that indicate or otherwise identify one or more cryptographic keys. See also par. 0029).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the request of Kennedy using the request with identifier taught in Sah in order to provides the data structure and the data key in response to the request (Sah abstract).
Regarding claim 17, Kennedy and Sah disclose the method of claim 16,
Kennedy further discloses comprising: generating the context identifier, wherein the context identifier is included in the second request; and transmitting the context identifier to the client in response the encryption request (Kennedy par. 0075; Receive a decryption request from a first server that includes an identifier for one or more users and an encrypted key; select a key management server based on the identifier; transmit a request for a data encryption key to the selected key management server, the request including the encrypted key).
Regarding claim 18, Kennedy and Sah disclose the method of claim 16,
Kennedy further discloses wherein the context identifier is generated by the key broker server and returned in response to the second request (Kennedy par. 0075; The memory stores instructions executable by the processor to receive a decryption request from a first server that includes an identifier for one or more users and an encrypted key; select a key management server based on the identifier; transmit a request for a data encryption key to the selected key management server, the request including the encrypted key).
Sah further discloses receiving a request, including a record associated with a context identifier (Sah par. 0028 and 0085; Decrypt request 502 can be submitted to a cryptography service instance or an endpoint routing service 512. In some examples, a Decrypt request 502 is obtained by a cryptography service instance, in which the cryptography service instance decrypts ciphertext indicated by Ciphertext Data 506 using one or more keys indicated by KeyID 504. An Encrypt(KeyID, Data, Encryption Configuration) request can be used to cause a cryptography service instance to encrypt specified data using a key identified by the KeyID, which can refer to an identifier that uniquely resolves to a particular managed key. Inputs to a KeyID parameter can include one or more data objects, such as strings, that indicate or otherwise identify one or more cryptographic keys. See also par. 0029).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the request of Kennedy using the request with identifier taught in Sah in order to provides the data structure and the data key in response to the request (Sah abstract).
Regarding claim 19, Kennedy and Sah disclose the method of claim 16,
Kennedy further discloses wherein the context identifier is generated by the client, included in the encryption request, and included in the second request ((Kennedy par. 0075; The memory stores instructions executable by the processor to receive a decryption request from a first server that includes an identifier for one or more users and an encrypted key; select a key management server based on the identifier; transmit a request for a data encryption key to the selected key management server, the request including the encrypted key).
Sah further discloses receiving a request, including a record associated with a context identifier (Sah par. 0028 and 0085; Decrypt request 502 can be submitted to a cryptography service instance or an endpoint routing service 512. In some examples, a Decrypt request 502 is obtained by a cryptography service instance, in which the cryptography service instance decrypts ciphertext indicated by Ciphertext Data 506 using one or more keys indicated by KeyID 504. An Encrypt(KeyID, Data, Encryption Configuration) request can be used to cause a cryptography service instance to encrypt specified data using a key identified by the KeyID, which can refer to an identifier that uniquely resolves to a particular managed key. Inputs to a KeyID parameter can include one or more data objects, such as strings, that indicate or otherwise identify one or more cryptographic keys. See also par. 0029).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the request of Kennedy using the request with identifier taught in Sah in order to provides the data structure and the data key in response to the request (Sah abstract).
Regarding claim 20, Kennedy and Sah disclose the method of claim 16,
Kennedy further discloses wherein the client uses the plaintext key to encrypt a recording of a conference to obtain an encrypted recording (Kennedy par. 0076; The media server 402 is configured to decrypt an encrypted recording of a conference conducted by the first server using the plaintext key to obtain a decrypted recording).
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 SANCHIT K SARKER whose telephone number is (571)270-7907. The examiner can normally be reached M-F 8:30 AM-5:30 PM.
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, FARID HOMAYOUNMEHR can be reached at 571-272-3739. 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.
/SANCHIT K SARKER/Primary Examiner, Art Unit 2495
Prosecution Insights