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
Claims 1-20 are presented for examination.
This is a Final Action.
Response to Arguments
Applicant's arguments filed 11/21/2025 have been fully considered but they are not persuasive.
Applicant makes the following arguments in view of claim 1:
On page 9 applicant argues “The combination of Mallikarjuna, Severino, and Ezzati fails to render obvious all of Applicant's claim elements. For example, the combination of references does not suggest, "a secret management process to enable secrets to be added to an application pod of a virtual software environment without restarting the application pod..., including: monitor for creation of a first secret in the virtual software environment; [and] append a name of the first secret to a key file name from the first secret to produce an appended key file" as in independent claim 1. Similarly, the combination of references does not suggest, "operating a secret management system to enable secrets to be added to an application pod of a virtual software environment without restarting the application pod ... including: monitoring for creation of a first secret in the virtual software environment; [and] appending a name of the first secret to a key file name from the first secret to produce an appended key file" as in independent claim 11.”
1. On pages 10-11 applicant argues “First, the combination of references does not render obvious, "a secret management process to enable secrets to be added to an application pod of a virtual software environment without restarting the application pod", as in Applicant's independent claims. The OA acknowledges Mallikarjuna does not teach this element, but asserts Ezzati does (OA, pages 3-4). The OA cites to Ezzati's title and the first paragraph of page 2. Id. However, while the title of Ezzati is "Create and Update Kubernetes Secret without Restarting Pods", it only actually teaches updating secrets without restarting pods. It does not teach how to "enable secrets to be added to an application pod... without restarting the application pod, as in Applicant's claims.”
Examiner respectfully disagrees with the applicant, Ezzati explicitly teaches, (1) mounting Secrete as volume, (2) Updating Secrete remotely without restart. Under BRI, “added to an application pod” includes adding secret data into the mounted directory. Under BRI, “added to application pod” would include adding secret data accessible without mounted directory. The claim does not explicitly recite “mounting a new secrete object after pod startup”. Accordingly, examiner respectfully maintains his mapping because argument is not persuasive.
2. On page 11 applicant argues “Second, the combination of references does not render obvious, "monitor for creation of a first secret in the virtual software environment". The OA acknowledges Mallikarjuna does not teach this, but again asserts Ezzati does. OA, pages 3-4. The OA points to, "(pages 3 and 4 - teaches detecting/creating a secret before pod consumption, Ezzati)". Id. However, Ezzati only teaches creating and mounting a secret, and not anything that monitors for the creation of a secret and acts in response, as in Applicant's claims. As explained above, Ezzati teaches including a secret in a volume that is mounted to a pod at creation of the pod, and there is nothing about "monitoring for creation of a first secret in a virtual software environment" as in Applicant's claims. "All words in a claim must be considered in judging the patentability of that claim against the prior art." In re Wilson, 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970). MPEP 2143.03. As above, Severino does not discuss application pods and secrets in a virtual software environment, and therefore does not suggest anything about monitoring for creation of a secret in such an environment. Accordingly, the combination of references does not render obvious Applicant's element as claimed.
Examiner respectfully disagrees with the applicant, specifically, Mallikarjuna teaches operator controller monitoring creation/changes of global object. Monitoring creation includes detecting initial creation event. The claim does not require monitoring all secret objects – only monitoring for creation of secret. Mallikarjuna’s controller detecting creation events can satisfy this condition. Accordingly, examiner respectfully maintains his mapping because argument is not persuasive.
3. On page 11-12 applicant argues “Third, the combination of references does not render obvious, "append a name of the first secret to a key file name from the first secret to produce an appended key file", as in Applicant's independent claims. The OA acknowledges that Mallikarjuna does not teach this element, but suggests that Severino does. OA, pages 3-4. The OA relies on Severino's discussion of appending new blocks to a secure blockchain, and claims that this covers Applicant's claim under the Broadest Reasonable Interpretation (BRI) standard. During patent examination, the pending claims must be "given their broadest reasonable interpretation consistent with the specification." MPEP 2111 (emphasis added). Evidence for the meaning of a term may be derived from "the words of the claims themselves, the remainder of the specification, the prosecution history, and extrinsic evidence concerning relevant scientific principles, the meaning of technical terms, and the state of the art". Phillips v. A WH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005)). The broadest reasonable interpretation standard requires that claim language be consistent with the specification, and does not grant "an unfettered license to interpret the words in a claim without regard for the full claim language and the written description." In re Power Integrations, Inc., Appeal No. 17- 1304 (Fed. Cir. 2018). With this framework in mind, the specific language of Applicant's claims recite "append a name of the first secret to a key file name from the first secret to produce an appended key file". Appellant amended the claims to add to further clarify this point. Further, Applicant's specification and figures demonstrates taking a name of a secret and appending it to key file names from the secret to create unique key file names for adding to a super secret. See, e.g., FIG 3 through FIG. 7. Accordingly, it does not fall within the "BRI" to show any appending of data to other data, as was relied upon in Severino - the interpretation must be consistent with Applicant's specification and claim language. None of the references, alone or in combination, suggest the element as recited in Applicant's claims. ”
Examiner respectfully disagrees with the applicant, Severino teaches appending identifiers to stored data blocks. Appending an identifier to data to produce modified data is a known technique. Applying this known technique to secret key identifiers would have been obvious to improve uniqueness and traceability. The claim does not require specific string-concatenation semantics. Furthermore, While the applicant points to specific embodiments showing concatenation of secret names to file names, the claims do not require such specific implementation. Under BRI, appending a name to a key file encompasses associating identifier information with secret data. Severino teaches appending identifiers to store data structures. Accordingly, examiner respectfully maintains his mapping because argument is not persuasive.
In view of compact prosecution, Examiner respectfully suggests that the applicant review claims 5 and 8, and combine it with claim 1, the combination would allow for groups of multiple independent secrets into composite objects based on metadata value and namespace. Specifically if the focus would be on 1. From claim 5: Detect creation of second secrete (second namespace, selected metadata label, second value same as first value); (2) determine whether second namespace equals first namespace; (3) if different namespace: generate new super secrete in second namespace, store second appended key file to new super secret; (4) if same namespace: store second appended key file in existing super secret. From claim 8: (5) detect creation of second secret; (6) append second name to second key file to produce second appended key file; and (7) store second appended key file to super secret. Hence the most important limitations to consider would be 1. Detection of second secret. 2. Appending secret name to key file name (rename entry). 3. Storing multiple renamed entries in same super secret. 4. Namespace comparison. 5. Conditional creation of new super secret in different namespace.
Which would overcome the combination of the present references.
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 Mallikarjuna et al. (US 11,445,021) in view of Severino et al. (US 2025/0209055) further in view of Ezzati (“Create and update Kubernetes Secret without Restarting Pods”)
1. Mallikarjuna teaches, A secret management system (Col 3: lines 41-54 – a system for describing abstracted global view of objects including… a child resource may be secret, Mallikarjuna), comprising:
one or more processors (Col 11: lines 7-55 – teaches one or more processors in the system, Mallikarjuna); and
a memory having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to implement a secret management process (Col 12: lines 35-65 – teaches execution of instructions in memory for managing containerized objects, Mallikarjuna), a secret including a data object containing sensitive data, including (Col 3: lines 41-54- teaches objects include sensitive data such as credentials, Mallikarjuna):
store the appended key file to a super secret, the super secret including a specialized secret configured to contain key files from multiple secrets ( - teaches consolidating secrets into shared objects across namespace (this is analogous to super secret), Mallikarjuna).
Mallikarjuna does not explicitly teach,
…to enable secrets to be added to an application pod of a virtual software environment without restarting the application pod;
monitor for creation of a first secret in the virtual software environment; and
append a name of the first secret to a key file from the first secret to produce an appended key file;
Severino and Ezzati teach,
…to enable secrets to be added to an application pod of a virtual software environment without restarting the application pod (title and page 2, first paragraph - teaches secrets mounted to pods via volumes and doesn’t need any pod restarting , Ezzati);
monitor for creation of a first secret in the virtual software environment (pages 3 and 4 – teaches detecting/creating a secret before pod consumption, Ezzati); and
append a name of the first secret to a key file from the first secret to produce an appended key file (Abstract, Paragraph 31 & 36 – teaches a storage node generates appending requests, appends block identifiers, and associates them with receipt in ledger blocks (this includes blocks BLK0-BLKN) – in view of BRI - the block represent a first secrete unit containing secure data, the appending request body represents the key file from the first secret, and the block + appended receipt represents the appended key file, Severino);
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which said subject matter pertains to allow combining Mallikarjuna with Ezzati and Snider because all the prior arts are in the same field of endeavor of secret or secure data object management in distributed/virtualized environments because Mallikarjuna teaches aggregation (“super secret”) across namespaces, Ezzati teaches addition secrets into pods without restarting and Severino teaches appending identifiers and cryptographically certifying file objects, these teaches can be applied to Kubernetes-style secret management (Ezzati) to improve reliability and traceability with predictable results.
2. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 1, further comprising instructions that, upon execution, cause the one or more processors to:
determine whether the first secret includes a selected metadata label (Fig 3: 304E, Col 6: lines 22-34 - teaches using metadata labels, Mallikarjuna); and
in response to the first secret not including the selected metadata label, do not append the name of the first secret to the key file or store the appended key file to the super secret (Col 7: lines 30-39 - teaches that if the metadata label is missing, the replication/append does not occur, Mallikarjuna).
3. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 2, further comprising instructions that, upon execution, cause the one or more processors to: in response to determining the first secret includes the selected metadata label (Fig. 4 and 5 - teaches …upon detecting initial creation of a global object 112, the operator controller 108 may determine if the global object 112 complies with a corresponding custom resource definition 114. If the operator controller 108 determines that the global object compiles… the operator controller 108 replicates one or more parent resource 104, Mallikarjuna), determine a first value associated with the selected metadata label and a first namespace associated with the first secret (Fig 3-4 – teaches the global object 112… may include… a match labels field 304E that indicates labels associated with the set of tenant namespaces 102B… and a namespace field, which identifies the namespace 102 in which the global object 112 logically recites (metadata 402 and match labels field 304E) , Mallikarjuna); and
determine whether the first value corresponds to an existing super secret in the first namespace (Col 7: lines 63-Col 7: lines 1-20 - teaches upon detecting a change to the global object 112 (e.g. a change to the name field, or match labels field 406C)… the operator controller 108 may replicate one or more parent resources 104 indicated… to a set of tenant namespaces 102B… if a corresponding child resource 106 already exists, it may be deleted and replaced – therefore teaches operator checks whether same-valued object already exists before adding/replacing, Mallikarjuna).
4. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 3, further comprising instructions that, upon execution, cause the one or more processors to:
in response to determining the first value does correspond to an existing super secret in the first namespace (Col 10: lines 21-26 - teaches “when one or more of the tenant namespaces 102B already includes a child resource 106… the operator controller 108 may delete this resource 106 and replace it” thereby teaching - detecting duplicate and updates/replaces it, Mallikarjuna), store the appended key file to the super secret as the existing super secret ( Abstract - teaches “the system appends data blocks with identifiers into existing storage structures…” – thereby teaching new key info is appended into an existing aggregated structure (super secret), Severino).
5. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 4, further comprising instructions that, upon execution, cause the one or more processors to:
detect creation of a second secret having: a second namespace associated with the second secret; the selected metadata label; and a second value associated with the selected metadata label that is the same as the first value; (Fig 3-4, Col 6: lines 18-57 - teaches “…the global object 112 may identify… a set of tenant namespaces 102B… and a match labels field 304E… (e.g. Detects another object in a different namespace but same label/value), Mallikarjuna)
determine whether the second namespace is the same as the first namespace (Col 7: lines 7-15 - teaches “…namespace filed… identifies the namespace 102 in which the global object 112 logically resides… (e.g. namespace comparison supported), Mallikarjuna);
when the second namespace is different than the first namespace, generate a new super secret in the second namespace; and store a second appended key file from the second secret to the new super secret (Col 7: lines 40-47 & col 10: lines 14-26 - teaches “…replicates parent resource 104… into tenant namespaces 102B1-102B3… these replicated parent resources… can be represented… by child resources 106… (e.g. new namespace equals new replicated secret object), Mallikarjuna); and
when the second namespace is the same as the first namespace, store the second appended key file from the second secret to the super secret in the first namespace (Paragraphs 30 & 50 - teaches “…appending identifiers to the same existing object/file when values match…” (i.e. appends into same aggregated object if namespace matches), Severino).
6. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 3, further comprising instructions that, upon execution, cause the one or more processors to:
in response to determining the first value does not correspond to an existing super secret in the first namespace, generate the super secret, including setting a name for the super secret based on the first value (Fig 3-4, Col 6: lines 29-40 - teaches “…global object 112 includes… a name filed… indicates a name of the object… replicated into tenant namespaces” (i.e. if no match, system creates new “super secrete” with a name from metadata value, Mallikarjuna).
7. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 6, further comprising instructions that, upon execution, cause the one or more processors to:
mount the super secret to the application pod during initialization of the application pod (title & pages 1-5 – teaches injecting new secrets into a running pod (no start) (i.e. secret/data injected into pods at initialization and later without restart), Ezzati), including storing the appended key file to a directory accessible to the application pod (Col 3: lines 46-56 and Col 10: lines 17-21 - teaches “child resources 106… can be named… and made accessible in tenant namespaces for tenant services 110 (i.e. replicated secret/config becomes accessible as files inside pod), Mallikarjuna).
8. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 1, further comprising instructions that, upon execution, cause the one or more processors to:
detect creation of a second secret in the virtual software environment (Fig 5 & Col 9: lines 38-45 - teaches “operator controller 108 monitors… for creation or receipt of the global object 112” (i.e. detects new secret object), Mallikarjuna);
append a second name of the second secret to a second key file from the second secret to produce a second appended key file (Paragraph 29-31 - teaches system appends new identifiers/blocks into existing files, Severino); and
store the second appended key file to the super secret (Col 8: lines 17-20 - teaches “…replicates parent resource 104 into tenant namespaces… child resource 106” (i.e. stores new appended file into shared replicated structure), Mallikarjuna).
9. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 1, further comprising instructions that, upon execution, cause the one or more processors to:
receive a digital certificate at a certificate manager (Paragraphs 36-37 - teaches certificate receipts associated with appended records are managed and verified (i.e. certificate manager receives/handles certificates, Severino); and
generate, via the certificate manager, the first secret based on the digital certificate (Fig 8 & Col 9: lines 50-53 - teaches “…parent resource 104… may be used to store a secret used for authentication (i.e. certificate used to generate secret object), Mallikarjuna).
10. The combination of Mallikarjuna, Severino and Ezzati teach, The secret management system of claim 1, further comprising instructions that, upon execution, cause the one or more processors to:
initiate the virtual software environment as a Kubernetes cluster (Col 2: lines-41-43 – teaches running kubernetes, Mallikarjuna);
initiate the application pod after initiation of the Kubernetes cluster (Col 3: lines 21-22 – teaches “…pods (kpods in Kubernetes)… where a pod is the unit of replication (i.e. pod initialized after cluster), Mallikarjuna);
mount the super secret to the application pod during initiation of the application pod (title and page 2, - teaches hot reloading secret injection into pods (i.e. super secret mounted at pod startup), Ezzati);
add secret key files to the super secret without restarting the application pod (title and page 5, - teaches secret update without restart (hot-reload mechanism for adding secrets), Ezzati); and
remove the secret key files from the super secret without restarting the application pod (title - teaches secret update without restart (i.e. hot-reload mechanism for adding secrets), Ezzati).
Claim 11 is similar to claim 1 hence rejected similarly.
Claim 12 s similar to claim 2 hence rejected similarly.
Claim 13 is similar to claim 2 hence rejected similarly.
Claim 14 is similar to claim 3 hence rejected similarly.
Claim 15 is similar to claim 4 hence rejected similarly.
Claim 16 is similar to claim 5 hence rejected similarly.
Claim 17 is similar to combination of claims 6 and 7 hence rejected similarly.
Claim 18 is similar to claim 8 hence rejected similarly.
Claim 19 is similar to claim 9 hence rejected similarly.
Claim 20 is similar to claim 10 hence rejected similarly.
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.,0
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMRESH SINGH whose telephone number is (571)270-3560. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Ann J. Lo can be reached at (571) 272-9767. 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.
/AMRESH SINGH/Primary Examiner, Art Unit 2159