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 .
Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 8/15/25, 3/27/26 and 8/28/26 are 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.
Claims 1, 3, 4, 6-8, 10, 11, 13-15, 17, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ozarkar et al. U.S. 11,586,752 (hereinafter Ozarkar) in view of Harvey U.S. 2024/0111907 (hereinafter Harvey).
As per claim 1, 8 and 15, Ozarkar discloses a method/device cluster/CRM for managing container data in a cloud management platform (Ozarkar: Fig. 7; col. 30 lines 25-59: cloud container management platform such as Kubernetes) to perform the steps comprising:
encrypting first data based on a first key to generate first data ciphertext (Ozarkar: col. 30 lines 7-24: encrypt container data based on data encryption key for a container), wherein the cloud management platform is configured to
manage a plurality of container management clusters providing a container service (Ozarkar: col. 30 lines 25-42: container orchestration);
the first data is data to be deployed to a target container managed by one of the plurality of container management clusters (Ozarkar: col. 30 lines 42-54: deploy and manage containers to host devices); and
the cloud management platform comprises a key management component configured to manage a key (Ozarkar: col. 30 lines 7-24: key management service);
deploying the first data ciphertext and the first key to a host machine to which the target container belongs (Ozarkar: col. 29 lines 57 – col. 30 line 6).
Ozarkar does not explicitly disclose splitting the first key based on the key management component to generate a first key shard and providing key shard to host machine. However, Harvey discloses splitting container key into a plurality of separate parts and later combined in working memory when needed to access the container data (Harvey: [0118]). It would have been obvious to one having ordinary skill in the art to incorporate the teachings of Harvey within the system of Ozarkar because they are in the same field of endeavor involving encrypting container data based on container specific encryption keys. The motivation to combine would be to make it harder for the complete key to be extracted.
As per claim 3, 10 and 17, Ozarkar as modified discloses the limitations of claims 1, 8 and 15 respectively. Ozarkar as modified further discloses wherein the key management component is further configured to synthesize key shards (Harvey: [0118]: combine parts of key components), the method further comprising: obtaining a third key; obtaining the first data ciphertext and the first key shard; obtaining the first data based on the key management component, the first data ciphertext, and the first key shard (Ozarkar: col. 29 lines 57 – col. 30 line 6); and encrypting the first data based on the third key to generate third data ciphertext (Ozarkar: [0011]-[0013]: re-encrypt with the new key/third key; [0036]). Same rationale applies here as above in rejecting claim 1.
As per claim 4, 11 and 18, Ozarkar as modified discloses the limitations of claims 1, 8 and 15 respectively. Ozarkar as modified further discloses wherein splitting the first key based on the key management component to generate the first key shard comprises: generating a first root key; encrypting the first key based on the first root key to generate first key ciphertext; and splitting the first root key using the key management component to generate the first key shard; and deploying the first data ciphertext and the first key shard to the host machine to which the target container belongs comprises: deploying the first data ciphertext, the first key ciphertext, and the first key shard to the host machine to which the target container belongs (Harvey: [0083]: master key is used as root for other application keys; [0172]-[0173]: loading one or more master keys in the container by encrypting with communication key). It would have been obvious to one having ordinary skill in the art to sign encryption key based on root key to encrypt data associated with container applications because they are analogous art. The motivation to combine would be to establish root-of-trust (Harvey: [0086]).
As per claim 6, 13 and 20, Ozarkar as modified discloses the limitations of claims 1, 8 and 15 respectively. Ozarkar as modified further discloses generating the first key based on an encryption parameter specified by a user (Ozarkar: col. 32 lines 24-49).
As per claim 7 and 14, Ozarkar as modified discloses the method of claims 6 and 13 respectively. Ozarkar as modified further discloses wherein the encryption parameter comprises at least one of the following: an encryption mode; an encryption algorithm; or a key length (Ozarkar: col. 8 line 6 – col. 9 line 16).
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ozarkar in view of Harvey and further in view of El-Moussa et al. U.S. 2020/0387598 (hereinafter El-Moussa).
As per claim 2, 9 and 16, Ozarkar as modified discloses the limitations of claims 1, 8 and 15 respectively. Ozarkar as modified discloses executing multiple applications within a single container and encrypt container data based on encryption key that may be split. Ozarkar does not explicitly disclose the first data is data used by the first application, the method further comprising: encrypting second data based on a second key to generate second data ciphertext, wherein the second data is data used by the second application; splitting the second key based on the key management component to generate a second key shard; and deploying the second data ciphertext and the second key shard to the host machine to which the target container belongs. However, El-Moussa discloses application specific encryption and access control such that potentially multiple applications executing in a single deployed software can be secured differently using different keys (El-Moussa: [0021]). It would have been obvious to one having ordinary skill in the art to combine the teachings of El-Moussa within the system of Ozarkar as modified because they are analogous art involving protecting container data involving one or more applications. The motivation to combine would be to provide granular control of different applications within a single container instead of encrypting everything together (El-Moussa: [0006]).
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ozarkar in view of Harvey and further in view of Cannata, Jr. et al. U.S. 2023/0163967 (hereinafter Cannata).
As per claim 5, 12 and 19, Ozarkar as modified discloses the limitations of claims 1, 8 and 15 respectively. Ozarkar as modified does not explicitly disclose wherein deploying the first data ciphertext and the first key shard to the host machine to which the target container belongs comprises: coding the first data ciphertext and the first key shard in a coding scheme that represents binary data based on 64 printable characters; and deploying the coded first data ciphertext and the coded first key shard to the host machine to which the target container belongs. However, Cannata discloses transmitting access token containing segment encoded based on base64 encoding scheme to transmit data to Kubernetes containers (Cannata: [0058]-[0060]: base64 encoding standard). It would have been obvious to one having ordinary skill in the art to orchestrate containers using base64 encoding as well-known in the art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Quinlan et al. U.S. 2024/0193255 discloses method of protecting secrets in use with containerized applications.
Schindewolf et al. U.S. 2024/0146526 discloses management of tenant-specific encryption keys.
Antinori et al. U.S. 2024/0137218 discloses label filtering and encryption.
Martinez De La Cruz et al. U.S. 2023/0050944 discloses container with encrypted software packages.
Ozarkar et al. U.S. 11,343,247 discloses local delegation of remote key management service.
Stephens et al. U.S. 2022/0107999 discloses secure private portable vault container.
Murray U.S. 2021/0103392 discloses dedicated encrypted container storage.
Robinson et al. U.S. 9,703,965 discloses secure containers for flexible credential protection in devices.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIN HON (ERIC) CHEN whose telephone number is (571)272-3789. The examiner can normally be reached Monday to Thursday 9am- 7pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431
Prosecution Insights