CTFR 18/406,702 CTFR 92504 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 1.The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Response to Arguments 2. Applicant’s arguments filed on 01/29/2026 with respect to independent claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claim Rejections - 35 USC § 103 07-20-aia AIA 3.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. 07-21-aia AIA 4. Claim s 1,4,6,7,9, 11 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Yadav (US Pub.No.11,755,425) . 5. Regarding claims 1,9 Cannon teaches a system and a method comprising: a computing cluster in a first network, the computing cluster comprising computing nodes, the computing nodes comprising worker nodes and a manager node, the worker nodes running pods deployed by the manager node, the manager node running a data store [element.14 in fig.1], the data store comprising plaintext secrets that are used by the pods; and a local backup server [element.16 in fig.1] in the first network, the local backup server being separate from the manager node, the local backup server being separate from the worker nodes, the local backup server configured to: obtain the plaintext secrets from the data store of the manager node (Para:0032 teaches a computing environment having a client 2 and server 4 for backing up data in the client 2. The client maintains data objects 8, such as files or objects, and maintains client object information 10 having metadata for each data object, including an ordered list of chunks of data assigned to each data object. The client 2 includes an operating system 12 to generate and maintain data objects 8 at the client 2, which data objects 8 may be stored in local storage at the client 2. To back-up data objects 8 at the client 2, a client backup manager 14 transfers chunks in the data objects 8 to a server backup manager 16 in the server 4. Para:0034 teaches the client 2 and server 4 components communicate over a connection 24. In one embodiment, the client 2 and server 4 may comprise separate computer systems and the link 24 may comprise a network, such as a local area network (LAN), storage area network (SAN), etc); generate a plaintext data key and an encrypted data key, the encrypted data key being an encrypted copy of the plaintext data key; encrypt the plaintext secrets using the plaintext data key to obtain encrypted secrets; and store the encrypted secrets and the encrypted data key in the data store of the manager node (Para:0035 teaches the server 4 may share a shared key (S.sub.s) 30 with the client 2 to use to encrypt chunks of the data objects sent between the client 2 and server 4 as part of backup and restore operations. The server may share the shared key 30 with multiple clients to use to encrypt chunks. In an alternative embodiment, the server 4 may store the chunks of data objects from clients 2 unencrypted and encrypt with the shared key (S.sub.S) when sending to the client 2); Cannon taches all the above claimed limitations but fails to teach the local backup server configured to: receive a backup request. Yadav teaches the local backup server configured to: receive a backup request (Col.6, lines.5-23 teaches generating backup data and backup metadata. In Fig.3, Step 300, the local backup manager of the local storage server receives a command (and/or request) to begin a backup process of a virtual data pool. The command may be received from a user of the local storage server, the command may be generated and sent automatically (e.g., scheduled by another program), and/or the local backup manager may initiate the process automatically (e.g., on a schedule). Although the command may only specify the virtual data pool (a collection of pointers, links, and paths), the local backup manager initiates a backup of the underlying data referenced by the virtual data pool. In Step 302, the local backup manager identifies the physical locations of the data referenced in the virtual data pool. The virtual data pool includes pointers, paths, and/or links to individual data components (e.g., files) of the underlying data. Each individual data component may be stored on the local storage server). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon to include the local backup server configured to: receive a backup request as taught by Yadav, such a setup create and store a copy of data, files or system information so it can be recovered later if something goes wrong. 6. Regarding claim 4 Cannon teaches the system, further comprising: an encryption server in the first network, the encryption server configured to generate the plaintext data key and the encrypted data key for the local backup server (Para:0046-0047 teaches operations performed by the client backup manager 14 and server backup manager 16 to back-up data objects at the client 2 to the server, and encrypting the data objects). 7. Regarding claim 6 Cannon teaches the system, wherein the computing cluster comprises an API server, and the local backup server obtains the plaintext secrets from the data store of the computing cluster via the API server (Para:0053 teaches the local backup server obtains the plaintext secrets from the data store). 8. Regarding claim 7 Cannon teaches the system, wherein the plaintext data key is a symmetric data key (Para:0032-0036). 9. Regarding claim 11 Cannon teaches the method wherein the plaintext data key is a symmetric data key, and encrypting the plaintext secrets comprises encrypting the plaintext secrets with a symmetric-key algorithm (Para:0032-0036). 10. Regarding claim 21 Cannon teaches the system, wherein the computing cluster does not run a backup agent (Cannon. Fig.1) 07-22-aia AIA 11. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Yadav (US Pub.No.11,755,425) as applied to claim 1 above and further in view of Donaghy (US Pub.No.2018/0225179) 12. Regarding claim 2 Cannon in view of Yadav teaches all the above claimed limitations, but fails to teach the system, further comprising: a backup data store in a second network, the second network separate from the first network; and a remote backup server in the second network, the remote backup server configured to: send the backup request to the local backup server; and store the encrypted secrets and the encrypted data key in the backup data store . Donaghy teaches a backup data store in a second network, the second network separate from the first network; and a remote backup server in the second network, the remote backup server configured to: send the backup request to the local backup server; and store the encrypted secrets and the encrypted data key in the backup data store (Abstract teaches the data encryption instructions to divide a data element into a plurality of data chunks, encrypt the plurality of data chunks, store the encrypted plurality of data chunks in a local storage, and provide the data element to a remote backup storage . Para:0014-0015 teaches Divide data element instructions 132 may divide a data element into a plurality of data chunks. For example, device 100 may comprise a client backing up a data element 140 such as log(s)s, video(s), image(s), application(s), and/or other data to a remote backup storage device 150 . Data element 140 may be broken into a plurality of data chunks 145(A)-(B). The remote backup storage device 150 may comprise an application and/or service executing on another computing device. Para:0017 teaches store encrypted data chunk instructions 136 may store the encrypted plurality of data chunks in a local storage. For example, device 100 may write encrypted data chunks 145(A)-(C) to machine-readable storage medium 120 and/or some other storage location accessible to device 100 other than remote backup storage device 150). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Yadav to include a backup data store in a second network, the second network separate from the first network; and a remote backup server in the second network, the remote backup server configured to: send the backup request to the local backup server as taught by Donaghy, such a setup helps in data recovery and protect the system failure .. 07-22-aia AIA 13. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Yadav (US Pub.No.11,755,425) as applied to claim 1 above and further in view of Harwood (US Pat.No.8,588,425) 14. Regarding claim 3 Cannon in view of Yadav teaches all the above claimed limitations but fails to teach the system, wherein the local backup server stores the encrypted secrets and the encrypted data key in a backup namespace of the computing cluster, and the remote backup server retrieves the encrypted secrets and the encrypted data key in response to detecting creation and population of the backup namespace with the encrypted secrets and the encrypted data key. Harwood teaches the local backup server stores the encrypted secrets and the encrypted data key in a backup namespace of the computing cluster, and the remote backup server retrieves the encrypted secrets and the encrypted data key in response to detecting creation and population of the backup namespace with the encrypted secrets and the encrypted data key (Figs.1-5 and Col.7, lines.19-66; Col.8, lines.1-24 teaches the data processing system has a key management server 53 separate from the storage systems 24, 25. The key management server 53 provides a secure backup for the data encryption keys and key encryption keys used by the storage systems 24, 25. The data processing system stores encrypted data. Object identifiers are assigned to storage objects, and data encryption keys are assigned to the storage objects. When performing an operation upon a storage object, a copy of the data encryption key is fetched from a key server. An absolute key identifier that is unique across the key server namespace also is stored in association with the object identifier in the storage system and in the key store of the key server, and the absolute key identifier is used as a failsafe for recovery of encrypted data. The storage systems 24, 25 and the key management server 53 also maintain a backup index to the data encryption keys in the key server context. The backup index associates the object identifiers and their data encryption keys with the absolute key reference. If a storage system has a data encryption failure when using a data encryption key that passes the key correctness check, then the storage system can use the absolute key reference to request a new copy of the data encryption key from the key management server 53. Fig.7,16 and Col.11, lines.10-37 teaches the system administrator may specify that all data encryption keys for the domain namespace are to be wrapped with an associated object ID and encrypted with a key encryption key using a specified block encryption algorithm, mode, key length, and key lifetime). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Yadav to include the local backup server stores the encrypted secrets and the encrypted data key in a backup namespace of the computing cluster, and the remote backup server retrieves the encrypted secrets and the encrypted data key in response to detecting creation and population of the backup namespace with the encrypted secrets and the encrypted data key as taught by Harwood, an absolute key identifier that is unique across the key server namespace is stored in association with the object identifier in the storage system and in the key store of the key server, and the absolute key identifier is used as a failsafe for recovery of encrypted data (abstract). 15. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable Cannon (US Pub.No.2013/0103945) in view of Yadav (US Pub.No.11,755,425) as applied to claim 1 above and further in view of in view of Menezes (US Pub.No.2023/0142346) . 16. Regarding claim 8 Cannon in view of Yadav teaches the local backup server stores the encrypted secrets in the data store by storing key-value objects in the data store, names of the key-value objects (Cannon: Para:0043); but fails to teach the backup request further comprises a target namespace of the computing cluster. Menezes teaches the backup request further comprises a target namespace of the computing cluster (Fig.4 abstract, Para:0006 and Para:0080-0084 teaches the backup request comprises a target namespace of the computing cluster). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Yadav to include the backup request further comprises a target namespace of the computing cluster, as taught by Menezes, such a setup would provide data backup in container management frameworks, to protect data clusters in container environments . 07-22-aia AIA 17. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Yadav (US Pub.No.11,755,425) as applied to claim 9 above and further in view of Ko (US Pub.No.2008/0307020) . 18. Regarding claim 10 Cannon in view of Yadav teaches all the above claimed limitations but fails to teach the method further comprising: deleting, by the backup server, the plaintext data key and the plaintext secrets from a memory of the backup server. Ko teaches deleting, by the backup server, the plaintext data key and the plaintext secrets from a memory of the backup server (Para:0045 teaches deleting backup data). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Yadav to include t deleting, by the backup server, the plaintext data key and the plaintext secrets from a memory of the backup server as taught by Ko, such a setup would save storage space by deleting backups . 07-22-aia AIA 19. Claim s 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Yadav (US Pub.No.11,755,425) as applied to claim 9 above and further in view of Menezes (US Pub.No.2023/0142346) . 20. Regarding claim 12 Cannon in view of Yadav teaches all the above claimed limitations but fails to teach the method, wherein the backup request further comprises a target namespace of the computing cluster, the worker nodes run the pods in the target namespace, and the plaintext secrets are obtained from the target namespace. Menezes teaches the method, wherein the backup request further comprises a target namespace of the computing cluster, the worker nodes run the pods in the target namespace, and the plaintext secrets are obtained from the target namespace (Menezes: Figs.4-5 abstract, Para:0005-0006 and Para:0080-0084 teaches the backup request comprises a target namespace of the computing cluster). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Yadav to include the backup request comprising a target namespace of the computing cluster as taught by Menezes, such a setup would provide data backup in container management frameworks, to protect data clusters in container environments. 21. Regarding claim 15 Cannon in view of Yadav teaches all the above claimed limitations but fails to teach the method, wherein generating the plaintext data key and the encrypted data key based on the description of the computing cluster comprises: looking up a cluster identifier that is unique to the computing cluster using the description of the computing cluster; and sending a key request to an encryption server, the key request comprising the cluster identifier Menezes the method, wherein generating the plaintext data key and the encrypted data key based on the description of the computing cluster comprises: looking up a cluster identifier that is unique to the computing cluster using the description of the computing cluster; and sending a key request to an encryption server, the key request comprising the cluster identifier (Menezes: Figs.4-5 abstract, Para:0006 and Para:0080-0084 teaches receiving a restore request for the target cluster or the object and, based on the received restore request, restoring the target cluster or the object using the first snapshot and the second snapshot). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Yadav to include looking up a cluster identifier that is unique to the computing cluster using the description of the computing cluster; and sending a key request to an encryption server, the key request comprising the cluster identifier as taught by Menezes, such a setup would provide data backup in container management frameworks, to protect data clusters in container environments. 22.Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Yadav (US Pub.No.11,755,425) as applied to claim 9 above and further in view of Harwood (US Pat.No.8,588,425) 23. Regarding claim 13 Cannon in view of Yadav teaches all the above claimed limitations but fails to teach the method further comprising: creating, by the backup server, a backup namespace of the computing cluster, wherein the encrypted secrets and the encrypted data key are stored in the backup namespace. Harwood teaches creating, by the backup server, a backup namespace of the computing cluster, wherein the encrypted secrets and the encrypted data key are stored in the backup namespace (Figs.1-5 and Col.7, lines.19-66; Col.8, lines.1-24 teaches the data processing system has a key management server 53 separate from the storage systems 24, 25. The key management server 53 provides a secure backup for the data encryption keys and key encryption keys used by the storage systems 24, 25. The data processing system stores encrypted data. Object identifiers are assigned to storage objects, and data encryption keys are assigned to the storage objects. When performing an operation upon a storage object, a copy of the data encryption key is fetched from a key server. An absolute key identifier that is unique across the key server namespace also is stored in association with the object identifier in the storage system and in the key store of the key server, and the absolute key identifier is used as a failsafe for recovery of encrypted data. The storage systems 24, 25 and the key management server 53 also maintain a backup index to the data encryption keys in the key server context. The backup index associates the object identifiers and their data encryption keys with the absolute key reference. If a storage system has a data encryption failure when using a data encryption key that passes the key correctness check, then the storage system can use the absolute key reference to request a new copy of the data encryption key from the key management server 53. Fig.7,16 and Col.11, lines.10-37 teaches the system administrator may specify that all data encryption keys for the domain namespace are to be wrapped with an associated object ID and encrypted with a key encryption key using a specified block encryption algorithm, mode, key length, and key lifetime). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Yadav to include the encrypted secrets and the encrypted data key are stored in the backup namespace, as taught by Harwood, an absolute key identifier that is unique across the key server namespace is stored in association with the object identifier in the storage system and in the key store of the key server, and the absolute key identifier is used as a failsafe for recovery of encrypted data (abstract). 24. Regarding claim 14 Cannon in view of Yadav teaches all the above claimed limitations, but fails to teach the method, wherein the backup request comprises the backup namespace. Menezes teach the method, wherein the backup request comprises the backup namespace. (Figs.4-5 abstract, Para:0005-0006 and Para:0080-0084) . 07-21-aia AIA 25. Claim s 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Menezes (US Pub.No.2023/0142346) . 26. Regarding claim 16 Cannon teaches a method comprising: the computing cluster comprising computing nodes, the computing nodes comprising worker nodes and a manager node, the worker nodes running pods deployed by the manager node, the manager node running a data store [element.14 in fig.1], the backup server [element.16 in fig.1] being separate from the manager node, the backup server being separate from the worker nodes, obtaining, by the backup server, encrypted secrets and an encrypted data key from the data store of the manager node (Para:0032 teaches a computing environment having a client 2 and server 4 for backing up data in the client 2. The client maintains data objects 8, such as files or objects, and maintains client object information 10 having metadata for each data object, including an ordered list of chunks of data assigned to each data object. The client 2 includes an operating system 12 to generate and maintain data objects 8 at the client 2, which data objects 8 may be stored in local storage at the client 2. To back-up data objects 8 at the client 2, a client backup manager 14 transfers chunks in the data objects 8 to a server backup manager 16 in the server 4. Para:0034 teaches the client 2 and server 4 components communicate over a connection 24. In one embodiment, the client 2 and server 4 may comprise separate computer systems and the link 24 may comprise a network, such as a local area network (LAN), storage area network (SAN), etc. Para:0035 teaches the server 4 may share a shared key (S.sub.s) 30 with the client 2 to use to encrypt chunks of the data objects sent between the client 2 and server 4 as part of backup and restore operations. The server may share the shared key 30 with multiple clients to use to encrypt chunks. In an alternative embodiment, the server 4 may store the chunks of data objects from clients 2 unencrypted and encrypt with the shared key (S.sub.S) when sending to the client 2); generating, by the backup server, a plaintext data key based on the encrypted data key and the plaintext data key being a decrypted copy of the encrypted data key; decrypting, by the backup server, the encrypted secrets using the plaintext data key to obtain plaintext secrets; and storing, by the backup server, the plaintext secrets in the data store of the computing cluster, the plaintext secrets being used by the pods (Para:0036 teaches The client 28 and server 30 keys may comprise cryptographic keys known in the art, such as symmetric keys produced by a symmetric key algorithm. The shared key 30 used by the client’s 2 and server 4 may comprise the same symmetric key. Alternatively, the keys 28 and 30 may be produced according to public key cryptography using an asymmetric key technology. For instance, the server 4 may maintain a private key and share the public key with clients 2 that the client’s 2 may use to encrypt chunks sent to the server 4 that may be decrypted with the server private key. The server may send chunks to the client’s 2 encrypted with the server private key that can only be decrypted by the server public key held by the client’s 2. Other key encryption techniques known in the art may be used for the client private key 28 and the shared key 30). Cannon taches all the above claimed limitations but fails to teach receiving, by a backup server, a restore request comprising a description of a computing cluster. Menezes teaches receiving, by a backup server, a restore request comprising a description of a computing cluster (Fig.4 abstract, Para:0006 and Para:0080-0084 teaches receiving a restore request for the target cluster or the object and, based on the received restore request, restoring the target cluster or the object ). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon to include receiving, by a backup server, a restore request comprising a description of a computing cluster, as taught by Menezes, such a setup would provide data backup in container management frameworks, to protect data clusters in container environments. 27. Regarding claim 18 Cannon teaches the method wherein the plaintext data key is a symmetric data key, and decrypting the encrypted secrets comprises decrypting the encrypted secrets with a symmetric-key algorithm (Para:0032-0036) . 07-22-aia AIA 28. Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Menezes (US Pub.No.2023/0142346) as applied to claim 16 above and further in view of Ko (US Pub.No.2008/0307020) . 28. Regarding claim 17 Cannon in view of in view of Menezes teaches all the above claimed limitations but fails to teach the method further comprising: deleting, by the backup server, the plaintext data key and the plaintext secrets from a memory of the backup server. Ko teaches deleting, by the backup server, the plaintext data key and the plaintext secrets from a memory of the backup server (Para:0045 teaches deleting backup data). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Canon in view of Menezes to include deleting, by the backup server, the plaintext data key and the plaintext secrets from a memory of the backup server as taught by Ko, such a setup would save storage space by deleting backups . 07-22-aia AIA 29. Claim s 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Cannon (US Pub.No.2013/0103945) in view of Menezes (US Pub.No.2023/0142346) as applied to claim 16 above and further in view of Harwood (US Pat.No.8,588,425) 30. Regarding claim 19 Cannon in view of Menezes teaches the method, wherein the restore request comprises a backup namespace of the computing cluster (Menezes: Fig.2 and Para: 0080-0084 teaches the restore request comprises the backup namespace of the computing cluster); but fails to teach the encrypted secrets and the encrypted data key are obtained from the backup namespace. Harwood teaches the encrypted secrets and the encrypted data key are obtained from the backup namespace (Figs.1-5 and Col.7, lines.19-66; Col.8, lines.1-24 teaches the data processing system has a key management server 53 separate from the storage systems 24, 25. The key management server 53 provides a secure backup for the data encryption keys and key encryption keys used by the storage systems 24, 25. The data processing system stores encrypted data. Object identifiers are assigned to storage objects, and data encryption keys are assigned to the storage objects. When performing an operation upon a storage object, a copy of the data encryption key is fetched from a key server. An absolute key identifier that is unique across the key server namespace also is stored in association with the object identifier in the storage system and in the key store of the key server, and the absolute key identifier is used as a failsafe for recovery of encrypted data. The storage systems 24, 25 and the key management server 53 also maintain a backup index to the data encryption keys in the key server context. The backup index associates the object identifiers and their data encryption keys with the absolute key reference. If a storage system has a data encryption failure when using a data encryption key that passes the key correctness check, then the storage system can use the absolute key reference to request a new copy of the data encryption key from the key management server 53. Fig.7,16 and Col.11, lines.10-37 teaches the system administrator may specify that all data encryption keys for the domain namespace are to be wrapped with an associated object ID and encrypted with a key encryption key using a specified block encryption algorithm, mode, key length, and key lifetime). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Menezes to include the encrypted secrets and the encrypted data key are obtained from the backup namespace as taught by Harwood, in such a setup an absolute key identifier that is unique across the key server namespace is stored in association with the object identifier in the storage system and in the key store of the key server, which is used as a failsafe for recovery of encrypted data (abstract). 31. Regarding claim 20 Cannon in view of Menezes teaches the method, wherein generating the plaintext data key based on the encrypted data key and the description of the computing cluster comprises: looking up a cluster identifier that is unique to the computing cluster using the description of the computing cluster (Menezes: Figs.4-5 abstract, Para:0006 and Para:0080-0084); But fails to teach sending a key request to an encryption server, the key request comprising the encrypted data key and the description of the computing cluster. Harwood teaches sending a key request to an encryption server, the key request comprising the encrypted data key and the description of the computing cluster (Figs.1-5 and Col.7, lines.19-66; Col.8, lines.1-24 teaches the data processing system has a key management server 53 separate from the storage systems 24, 25. The key management server 53 provides a secure backup for the data encryption keys and key encryption keys used by the storage systems 24, 25. The data processing system stores encrypted data. Object identifiers are assigned to storage objects, and data encryption keys are assigned to the storage objects. When performing an operation upon a storage object, a copy of the data encryption key is fetched from a key server. An absolute key identifier that is unique across the key server namespace also is stored in association with the object identifier in the storage system and in the key store of the key server, and the absolute key identifier is used as a failsafe for recovery of encrypted data. The storage systems 24, 25 and the key management server 53 also maintain a backup index to the data encryption keys in the key server context. The backup index associates the object identifiers and their data encryption keys with the absolute key reference. If a storage system has a data encryption failure when using a data encryption key that passes the key correctness check, then the storage system can use the absolute key reference to request a new copy of the data encryption key from the key management server 53. Fig.7,16 and Col.11, lines.10-37 teaches the system administrator may specify that all data encryption keys for the domain namespace are to be wrapped with an associated object ID and encrypted with a key encryption key using a specified block encryption algorithm, mode, key length, and key lifetime). Therefore, to would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify Cannon in view of Menezes to include sending a key request to an encryption server, the key request comprising the encrypted data key and the description of the computing cluster, as taught by Harwood, an absolute key identifier that is unique across the key server namespace is stored in association with the object identifier in the storage system and in the key store of the key server, and the absolute key identifier is used as a failsafe for recovery of encrypted data (abstract). Conclusion 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). 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 DEREENA T CATTUNGAL whose telephone number is (571)270-0506. The examiner can normally be reached Mon-Fri : 7:30 AM-5 PM EST. 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. /DEREENA T CATTUNGAL/Primary Examiner, Art Unit 2431 Application/Control Number: 18/406,702 Page 2 Art Unit: 2431 Application/Control Number: 18/406,702 Page 3 Art Unit: 2431 Application/Control Number: 18/406,702 Page 4 Art Unit: 2431 Application/Control Number: 18/406,702 Page 5 Art Unit: 2431 Application/Control Number: 18/406,702 Page 6 Art Unit: 2431 Application/Control Number: 18/406,702 Page 7 Art Unit: 2431 Application/Control Number: 18/406,702 Page 8 Art Unit: 2431 Application/Control Number: 18/406,702 Page 9 Art Unit: 2431 Application/Control Number: 18/406,702 Page 10 Art Unit: 2431 Application/Control Number: 18/406,702 Page 11 Art Unit: 2431 Application/Control Number: 18/406,702 Page 12 Art Unit: 2431 Application/Control Number: 18/406,702 Page 13 Art Unit: 2431 Application/Control Number: 18/406,702 Page 14 Art Unit: 2431 Application/Control Number: 18/406,702 Page 15 Art Unit: 2431 Application/Control Number: 18/406,702 Page 16 Art Unit: 2431 Application/Control Number: 18/406,702 Page 17 Art Unit: 2431 Application/Control Number: 18/406,702 Page 18 Art Unit: 2431 Application/Control Number: 18/406,702 Page 19 Art Unit: 2431
Prosecution Insights