Office Action Predictor
Last updated: April 15, 2026
Application No. 18/351,896

CONFIGURATION DATA MANAGEMENT

Non-Final OA §101§103
Filed
Jul 13, 2023
Examiner
HUARACHA, WILLY W
Art Unit
2197
Tech Center
2100 — Computer Architecture & Software
Assignee
Oracle International Corporation
OA Round
1 (Non-Final)
73%
Grant Probability
Favorable
1-2
OA Rounds
4y 1m
To Grant
99%
With Interview

Examiner Intelligence

Grants 73% — above average
73%
Career Allow Rate
300 granted / 410 resolved
+18.2% vs TC avg
Strong +35% interview lift
Without
With
+35.3%
Interview Lift
resolved cases with interview
Typical timeline
4y 1m
Avg Prosecution
28 currently pending
Career history
438
Total Applications
across all art units

Statute-Specific Performance

§101
12.6%
-27.4% vs TC avg
§103
45.4%
+5.4% vs TC avg
§102
9.6%
-30.4% vs TC avg
§112
26.4%
-13.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 410 resolved cases

Office Action

§101 §103
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 currently pending and have been examined. Information Disclosure Statement The information disclosure statement (IDS) submitted on 01/28/2025 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1 is rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below. Step 1: Claims 1 is directed to a system and falls within the statutory category of machines. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes. In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application. Step 2A Prong 1: The limitations of “monitor for creation of a first ConfigMap in the virtual software environment" and "append a name of the first ConfigMap to a data element name from the first ConfigMap to produce an appended data element”, as drafted, are a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think and observe and evaluate a ConfigMap and mentally associate a name with an element of data. Therefore, Yes, claim 1 recites judicial exceptions. The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception. Step 2A Prong 2: The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional elements – “one or more processors; 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 configuration data management process to enable ConfigMaps to be added to an application pod of a virtual software environment without restarting the application pod, a ConfigMap including a data object containing configuration data, the configuration data management process including” which are merely recitations of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional elements – “store the appended data element to a super ConfigMap, the super ConfigMap including a specialized ConfigMap configured to contain data elements from multiple ConfigMaps” which is merely a recitation of insignificant extra-solution data storage activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application. This insignificant extra-solution data storage activity will be further evaluated at Step 2B as to whether it is Well-Understood, Routine, and Conventional (WURC). Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that the claim 1 not only recites a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application. Step 2B: The claim does not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components and insignificant extra-solution data gathering activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra-solution data storage activity is WURC. See MPEP § 2106.05(d)(II) "iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)". Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception. Having concluded analysis within the provided framework, Claim 1 does not recite patent eligible subject matter under 35 U.S.C. § 101. With regard to claim 2, recites the additional elements “determine whether the first ConfigMap includes a selected metadata label; and in response to determining the first ConfigMap includes the selected metadata label, determine a first value associated with the selected metadata label and a first namespace associated with the first ConfigMap; and determine whether the first value corresponds to an existing super ConfigMap in the first namespace” which as drafted, are a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think and observe and evaluate a ConfigMap metadata and namespace against existing super Configmaps and mentally and determine whether a configmap corresponds to an esisting super configmap, and which does not integrate the judicial exception into practical application nor provide significantly more. With regard to claim 3, recites the additional elements “in response to determining the first value does correspond to an existing super ConfigMap in the first namespace, store the appended data element to the super ConfigMap as the existing super ConfigMap” which is merely a recitation of insignificant extra-solution data storage activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application nor provide significantly more. With regard to claim 4, recites the additional elements “detect creation of a second ConfigMap having: a second namespace associated with the second ConfigMap; the selected metadata label; and a second value associated with the selected metadata label that is the same as the first value; determine whether the second namespace is the same as the first namespace; when the second namespace is different than the first namespace, generate a new super ConfigMap in the second namespace; and store a second appended data element from the second ConfigMap to the new super ConfigMap; and when the second namespace is the same as the first namespace, store the second appended data element from the second ConfigMap to the super ConfigMap in the first namespace” which as drafted, are a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think and observe and evaluate a newly created ConfigMap namespace against the namespace of a first Configmap and mentally and determine whether to create a new super configmap or store into an existing super configmap, and which does not integrate the judicial exception into practical application nor provide significantly more. With regard to claim 7, recites the additional elements “in response to the first ConfigMap not including the selected metadata label, do not append the name of the first Configmap to the data element name or store the appended data element to the super ConfigMap” which merely further specifies that when configmap does not include selected metadata, not appending the name or storing the metadata, and which does not integrate the judicial exception into practical application nor provide significantly more. With regard to claim 9, recites the additional elements “detect creation of a second ConfigMap in the virtual software environment; append a second name of the second ConfigMap to a second data element from the second ConfigMap to produce a second appended data element” which as drafted, are a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think and observe and evaluate a second ConfigMap and mentally associate a name with an element of data. The additional elements “store the second appended data element to the super ConfigMap” merely recite insignificant extra-solution data storage activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application nor provide significantly more. With regards to claim 11, recites subject matter similar to that of claims 1 directed to a method and is rejected under the same rationale. With regards to claims 12-15, 17-18 recites subject matter similar to that of claims 2-4, 7-9 directed to a method and is rejected under the same rationale. Claim Rejections - 35 USC § 103 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, 8-11 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Burns et al. “Managing Kubernetes: Operating Kubernetes Clusters in the Real World” in view of Roy et al. (U.S. Pub. No. 20240143315 A1), and further in view of StackOverflow “How to merge two configmaps using volume mount in Kubernetes” (hereinafter Stackoverflow). Burns was cited in an IDS previously filed by applicant. As per claim 1, Burns teaches the invention substantially as claimed including a configuration data management system, comprising: a configuration data management process to enable ConfigMaps to be added to an application pod of a virtual software environment (page 115, fig. 10-1, CNI networking, describes virtual software environment) without restarting the application pod, a ConfigMap including a data object containing configuration data (page 13, lines 14-27 When you add a Volume to your Pod, you can choose to mount it to an arbitrary location in each running container. This enables your running container to have access to the storage within the Volume … In addition to basic files, there are several types of Kubernetes objects that can them‐selves be mounted into your Pod as a Volume. The first of these is the ConfigMap object. A ConfigMap represents a collection of configuration files. In Kubernetes, you want to have different configurations for the same container image. When you add a ConfigMap-based Volume to your Pod, the files in the ConfigMap show up in the specified directory in your running container … In the context of Volumes, a Secret works identically to a ConfigMap. It can be attached to a Pod via a Volume and mounted into a running container for use. Examiner notes, various types Kubernetes objects e.g. ConfigMaps, secrets, etc., can be added to a pod as volumes by attaching and mounting the configmap-based volumes to the pod into a running container. Once a ConfigMap-based Volume is added to the Pod, the files in the ConfigMap show up in a specified directory in the running container, the container may then use/access the ConfigMap without restarting because the files added may or may not be actively used), the configuration data management process including: Burns does not expressly disclose: one or more processors; and a memory having stored thereon instructions that, upon execution by the one or more processors cause the one or more processors to implement; monitor for creation of a first ConfigMap in the virtual software environment; store the appended data element to a super ConfigMap, the super ConfigMap including a specialized ConfigMap configured to contain data elements from multiple ConfigMaps. However, Roy teaches: one or more processors cause the one or more processors to implement (Fig. 4, Processor 410); and a memory having stored thereon instructions that, upon execution by the one or more processors (Fig. 4, Memory 412; par. 0118 The memory 412 … storing executable program code of one or more software programs); monitor for creation of a first ConfigMap in the virtual software environment (par. 0043 the configuration manager detects a new configuration map object has been loaded into the software configuration management system; par. 0014 When a change is detected in a configuration deployment file on GitHub, the changes to the configuration map representation are pulled from GitHub and used to create a configuration map object that is used by a microservice); store the … data element to a super ConfigMap, the super ConfigMap including a specialized ConfigMap configured to contain data elements from multiple ConfigMaps (par. 0043 detects a new configuration map object has been loaded into the software configuration management system, and adds the new configuration map object to the dictionary; par. 0041 a configuration manager merges a plurality of configuration map objects for a plurality of microservice applications into the dictionary [super configmap]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention combine/modify the teaching of Burns with the teaching of Roy because they are both directed to software configuration management and it would allow an applications/pod to work with a single dictionary [super configmap] as if the application had loaded a single configmap object. The ordinary skill would have been motivated inter to take advantage on various advantages provided including the ability to manage modification of configurations at scale, keep deployment files “DRY”, update a single deployment file, deploy the same configurations across multiple business units, and minimize updating of multiple files whenever a configuration value is changed [0101]. Burns and Roy do not expressly describe: append a name of the first ConfigMap to a data element name from the first ConfigMap to produce an appended data element. However, Stackoverflow teaches: append a name of the first ConfigMap to a data element name from the first ConfigMap to produce an appended data element (page 6, lines 1-18, describes two configmaps namely: a test-configmap and a common-configmap; page 6, lines 19-28 further describes a single third configmap [super configmap] having same data elements of the configmaps Instead of having different configmaps, wherein the third configmap describes appended data elements of the configmaps e.g., “data: common-1.conf: | property-1=value-1”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention combine/modify the teaching of Burns and Roy with the method of merging configmaps as disclosed by Stackoverflow because it would provide for appending the data elements of configuration maps in order to facilitate for merging into a single super configuration, and allow applications/pods access the data elements associated with multiple configuration maps from a single configuration map. Further, This approach is good if you have less amount of data in configmaps (page 5, NOTE, in last line). As per claim 8, Roy further teaches: mount the super ConfigMap to the application pod to provide a directory via which the application pod can access the appended data element (par. 0099 the microservice application mounts at least one configuration map object from the plurality of configuration map objects. In an example embodiment, the microservice application mounts the configuration map object (i.e., the configmap object), where the configmap object is obtained from the single dictionary). Burns further teaches: configure the super ConfigMap such that additional appended data elements from ConfigMaps can be added to or removed from the directory during operation of the application pod, without requiring a restart of the application pod (page 13, lines 20-23, In Kubernetes, you want to have different configurations for the same container image. When you add a ConfigMap-based Volume to your Pod, the files in the ConfigMap show up in the specified directory in your running container). As per claim 9, Roy further teaches: detect creation of a second ConfigMap in the virtual software environment; and store the second appended data element to the super ConfigMap (par. 0043 the configuration manager detects a new configuration map object has been loaded into the software configuration management system, and adds the new configuration map object to the dictionary). Stackoverflow further teaches: append a second name of the second ConfigMap to a second data element from the second ConfigMap to produce a second appended data element (page 6, lines 1-18, describes two configmaps namely: a test-configmap and a common-configmap; page 6, lines 19-28 further describes a single third configmap [super configmap] having same data elements of the configmaps Instead of having different configmaps, wherein the third configmap describes appended data elements of the configmaps e.g., “common-1.conf:” and “test-1.conf:”). As per claim 10, Roy further teaches: initiate the virtual software environment as a Kubernetes cluster; initiate the application pod after initiation of the Kubernetes cluster (par. 0040 The continuous deployment module deploys the microservice application in the software configuration management system, where the microservice application mounts at least one configuration map object from the plurality of configuration map objects; par. 0087 In an example embodiment, relevant microservice applications [pod], running in the Kubernetes cluster; par. 0082 restarts the microservices in the Kubernetes cluster. It is noted that microservices implicitly may start/restart after Kubernetes cluster is instantiated) and remove the data element key files from the super ConfigMap without restarting the application pod (par. 0082 configuration values in a configuration deployment file may be overwritten). Burns further teaches: mount the super ConfigMap to the application pod during initiation of the application pod; add data element key files to the super ConfigMap without restarting the application pod (page 13, lines 14-27 … In addition to basic files, there are several types of Kubernetes objects that can them‐selves be mounted into your Pod as a Volume. The first of these is the ConfigMap object. A ConfigMap represents a collection of configuration files. In Kubernetes, you want to have different configurations for the same container image. When you add a ConfigMap-based Volume to your Pod, the files [key files] in the ConfigMap show up in the specified directory in your running container … In the context of Volumes, a Secret works identically to a ConfigMap. It can be attached to a Pod via a Volume and mounted into a running container for use). As per claim 11, it is a method having similar limitations as claim 1. Thus, claim 11 is rejected for the same rationale as applied to claim 1. A per claim 18, Roy further teaches: detecting creation of a second ConfigMap in the virtual software environment (par. 0043 the configuration manager detects a new configuration map object has been loaded into the software configuration management system; par. 0014 When a change is detected in a configuration deployment file on GitHub, the changes to the configuration map representation are pulled from GitHub and used to create a configuration map object that is used by a microservice); store the second appended data element to the super ConfigMap (par. detects a new configuration map object has been loaded into the software configuration management system, and adds the new configuration map object to the dictionary; par. 0041 a configuration manager merges a plurality of configuration map objects for a plurality of microservice applications into the dictionary [super configmap]). Stackoverflow further teaches: appending a second selected value derived from the second ConfigMap to a second data element from the second ConfigMap to produce a second appended data element (page 6, lines 1-18, describes two configmaps namely: a test-configmap and a common-configmap; page 6, lines 19-28 further describes a single third configmap [super configmap] having same data elements of the configmaps Instead of having different configmaps, wherein the third configmap describes appended data elements of the configmaps e.g., “common-1.conf:” and “test-1.conf:”). As per claim 19, Roy further teaches: in response to detecting creation of the first ConfigMap, generating the super ConfigMap (par. 0035 configuration manager creates a dictionary [super configmap] comprising a plurality of configuration map objects); mounting the super ConfigMap to the application pod during initialization of the application pod, including storing the appended data element to a directory accessible to the application pod (par. 0099 he microservice application mounts at least one configuration map object from the plurality of configuration map objects. In an example embodiment, the microservice application mounts the configuration map object (i.e., the configmap object), where the configmap object is obtained from the single dictionary). Burns further teaches: configuring the super ConfigMap such that additional appended data elements from ConfigMaps can be added to or removed from the directory during operation of the application pod, without requiring a restart of the application pod (page 13, lines 20-23, In Kubernetes, you want to have different configurations for the same container image. When you add a ConfigMap-based Volume to your Pod, the files in the ConfigMap show up in the specified directory in your running container). As per claim 20, it is a method having similar limitations as claim 10. Thus, claim 20 is rejected for the same rationale as applied to claim 10. Claims 2-3, 12-13 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Burns in view of Roy and StackOverflow as applied to claim 1, and further in view of Rozenraukh et al. “cmmc/docs/example/aws-auth md at v0.1.2. cashapp/cmmc. GitHub” Rozenraukh was cited in an IDS previously filed by applicant. As per claim 2, Burns and Roy and Stackoverflow do not expressly disclose: determine whether the first ConfigMap includes a selected metadata label; and in response to determining the first ConfigMap includes the selected metadata label, determine a first value associated with the selected metadata label and a first namespace associated with the first ConfigMap; and determine whether the first value corresponds to an existing super ConfigMap in the first namespace. However, Rozenraukh teaches: determine whether the first ConfigMap includes a selected metadata label; and in response to determining the first ConfigMap includes the selected metadata label, determine a first value associated with the selected metadata label and a first namespace associated with the first ConfigMap; and determine whether the first value corresponds to an existing super ConfigMap in the first namespace (page 1, lines 19-20 This one specifically looks for ConfigMap resources with the label: cmmc:k8s.cash.app/merge: "aws-auth-map-roles" and the corresponding metadata labels on the source ConfigMaps of page 2, lines 8 and 12. This corresponds to determining whether to store the data element to the "super" ConfigMap based on a metadata label. Further, page 2, lines 13-25 and 26-38 describes two ConfigMaps of services/namespaces service-a and service-b, and lines 40-55 describe a target ConfigMap [super ConfigMap]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention combine/modify the teaching of Burns and Roy and Stackoverflow with method of merging configmaps as set forth by Rozenraukh because it would provide for merging/adding configmaps to an existing dictionary [super configmap] at least based on a value associated with metadata label matching a dictionary. As per claim 3, Rozenraukh further teaches: in response to determining the first value does correspond to an existing super ConfigMap in the first namespace, store the appended data element to the super ConfigMap as the existing super ConfigMap (page 1, lines 19-20 This one specifically looks for ConfigMap resources with the label: cmmc:k8s.cash.app/merge: "aws-auth-map-roles" and the corresponding metadata labels on the source ConfigMaps of page 2. This is equivalent to determining whether to store the data element to the "super" ConfigMap based on a metadata label, and wherein storing the configmap when the label is detected is implicit). As per claim 12, Rozenraukh further teaches: determining whether the first ConfigMap includes a selected metadata label; and determining whether to store the appended data element to the super ConfigMap based on whether the first ConfigMap includes the selected metadata label (page 2, describes creating sample configmap resources for two services/namespaces; page 1, lines 19-20 This one specifically looks for ConfigMap resources with the label: cmmc:k8s.cash.app/merge: "aws-auth-map-roles" and the corresponding metadata labels on the source ConfigMaps of page 2, lines 7 and 11. It is noted this corresponds to determining to store appended data element to the super ConfigMap). As per claim 13, it is a method having similar limitations as claim 2. Thus, claim 13 is rejected for the same rationale as applied to claim 2. As per claim 16, Stackoverflow further teaches: and generating the first ConfigMap to have a name of the first ConfigMap, the first namespace of the first ConfigMap, and the selected metadata label based on the definition file; and setting the selected value to the name of the first ConfigMap (page. 6, lines 1-19, describes creation of two configmaps [e.g. test-configmap and common-configmap], each including a name, namespace and metadata label, test-property-1=test-value-1, common-property-1=common-value-1). Roy further teaches: receiving a definition file that defines attributes of the first ConfigMap (par. 0014 the changes to the configuration map representation are pulled from GitHub and used to create a configuration map object that is used by a microservice; par. 0019 receives a file containing the value, where the file is named according to the configuration key. For example, a file may be created, such as a *.yml file … where the name of the file is the name of the configuration key and the content of the file is the value); As per claim 17, it is a method having similar limitations as claim 7. Thus, claim 17 is rejected for the same rationale as applied to claim 7. Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Burns in view of Roy, StackOverflow and Rozenraukh, further in view of Rui et al. (CN114398151A, English Translation), and further in view of Zheng et al. (U.S. Pub. No. 20230274167 A1). As per claim 4, Roy further teaches: detect creation of a second ConfigMap a second namespace associated with the second ConfigMap (par. 0043 the configuration manager detects a new configuration map object has been loaded into the software configuration management system;). Rozenraukh further teaches the second ConfigMap having: the selected metadata label; and a second value associated with the selected metadata label that is the same as the first value (cmmc:k8s.cash.app/merge: "aws-auth-map-roles"); determine whether the second namespace is the same as the first namespace (page 2, lines 29 and 47, describes a namespace “service-b” of second ConfigMap is the same as the namespace “service-b” in the target ConfigMap or super ConfigMap). Burns, Roy, Stackoverflow and Rozenraukh do note expressly describe: store a second appended data element from the second ConfigMap to the new super ConfigMap; and when the second namespace is the same as the first namespace, store the second appended data element from the second ConfigMap to the super ConfigMap in the first namespace. However, Rui teaches: store a second appended data element from the second ConfigMap to the new super ConfigMap; and when the second namespace is the same as the first namespace, store the second appended data element from the second ConfigMap to the super ConfigMap in the first namespace (par. 0085 Then, based on the tenant, the configuration group and configuration name are used to query the corresponding configuration content and configuration format, denoted as ConfigForm2 and ConfigValue2. The configuration content is parsed into a Map format and stored, denoted as ConfigMap2. The content of ConfigMap2 is merged into resultConfigMap, and configurations with the same name retain the configuration content in resultConfigMap). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify/combine the teaching of Burns, Roy, Stackoverflow and Rozenraukh by incorporating the teaching of Rui because they are directed to field of managing configmaps, and because it would provide for storing appended data elements of a ConfigMap to a resultConfigMap. The ordinary skill would have been motivated to combine because it would provide a configuration management method that merges the configuration information of namespaces level by level according to the parent-child relationship between namespaces to obtain the configuration information of child namespaces, thereby enabling configuration management at the tenant, project, resource group, and even higher levels (0042). Burns, Roy, Stackoverflow, Rozenraukh and Rui do not expressly disclose: when the second namespace is different than the first namespace, generate a new super ConfigMap in the second namespace. However, Zheng discloses: when the second namespace is different than the first namespace, generate a new super ConfigMap (par. 0107 when the unknown task cannot be classified into any task group [namespace] … a new task group may be created in the knowledge base module 210, and a task included in the new task group is the unknown task). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify/combine the teaching of Burns, Roy, Stackoverflow, Rozenraukh and Rui by incorporating the technique of creating a new task group as set forth by Zheng because the ordinary skill would have known how to combine (Rozenraukh) method of determining whether namespaces match and merging/storing a data element of a configmap into a super configmap with the technique of creating a new task group when a task cannot be classified to any task group to arrive by implementing the in the manner of creating a new target ConfigMap when a namespace of a ConfigMap does not match a first namespace. The ability to create a unique super ConfigMap for configmaps would have allowed teams to manage configurations independently and provided significant advantages primarily related to isolation, security. As per claim 15, it is a method having similar limitations as claim 4. Thus, claim 15 is rejected for the same rationale as applied to claim 4. Claims 5-6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Burns in view of Roy, StackOverflow, Rozenraukh, and further in view of Zheng et al. (U.S. Pub. No. 20230274167 A1). As per claim 5, Rozenraukh further teaches: determining the first value does not correspond to an existing super ConfigMap in the first namespace (page 1, lines 19-20 This one specifically looks for ConfigMap resources with the label: cmmc:k8s.cash.app/merge: "aws-auth-map-roles" and the corresponding metadata labels, values on the source ConfigMaps and target ConfigMap in page 2) Burns, Roy, Stackoverflow and Rozenraukh do not expressly disclose: in response to determining the first value does not correspond to an existing super ConfigMap in the first namespace, generate the super ConfigMap, including setting a name for the super ConfigMap based on the first value. However, Zheng teaches: in response to determining the first value does not correspond to an existing super ConfigMap in the first namespace, generate the super ConfigMap, including setting a name for the super ConfigMap based on the first value (par. 0107 when the unknown task cannot be classified into any task group [namespace] … a new task group may be created in the knowledge base module 210, and a task included in the new task group is the unknown task). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify/combine the teaching of Burns, Roy, Stackoverflow and Rozenraukh by incorporating the technique of creating a new task group as set forth by Zheng because the ordinary skill would have known how to combine (Rozenraukh) method of determining whether namespaces match and merging/storing a data element of a configmap into a super configmap with the technique of creating a new task group when a task cannot be classified to any task group to arrive by implementing the in the manner of creating a new target ConfigMap when a namespace of a ConfigMap does not match a first namespace. The ability to create a unique super ConfigMap for configmaps would have allowed teams to manage configurations independently and provided significant advantages primarily related to isolation, security. As per claim 6, Roy further teaches: mount the super ConfigMap to the application pod during initialization of the application pod, including storing the appended data element to a directory accessible to the application pod (par. 0099 he microservice application mounts at least one configuration map object from the plurality of configuration map objects. In an example embodiment, the microservice application mounts the configuration map object (i.e., the configmap object), where the configmap object is obtained from the single dictionary). As per claim 14, Rozenraukh further teaches: in response to determining the first value does correspond to an existing super ConfigMap in the first namespace, storing the appended data element to the super ConfigMap as the existing super ConfigMap (page 1, lines 19-20 This one specifically looks for ConfigMap resources with the label: cmmc:k8s.cash.app/merge: "aws-auth-map-roles" and the corresponding metadata labels on the source ConfigMaps of page 2. This is equivalent to determining whether to store the data element to the "super" ConfigMap based on a metadata label, and wherein storing the configmap when the label is detected is implicit). Zheng further teaches: in response to determining the first value does not correspond to an existing super ConfigMap in the first namespace, generating the super ConfigMap, including setting a name for the super ConfigMap based on the first value (par. 0107 when the unknown task cannot be classified into any task group [namespace] … a new task group may be created in the knowledge base module 210, and a task included in the new task group is the unknown task). Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Burns in view of Roy, StackOverflow and Rozenraukh, and further in view of Mallikarjuna et al. (U.S. Patent No. 11445021 B2). As per claim 7, Burns, Roy, StackOverflow and Rozenraukh do not expressly teach: in response to the first ConfigMap not including the selected metadata label, do not append the name of the first Configmap to the data element name or store the appended data element to the super ConfigMap. However, Mallikarjuna teaches: in response to the first ConfigMap not including the selected metadata label, do not append the name of the first Configmap to the data element name or store the appended data element to the super ConfigMap (col. 6, lines 46-50 describes using a match labels field 304E that indicates labels associated with the set of tenant namespaces 102B that the object will be replicated to; col. 7, lines 30-39 When the set of fields 406 of the global object 112 are not from the set of fields 304 from the custom resource definition 114 (e.g., the fields 406 of the global object 112 include one or more fields 406 not defined in the custom resource definition 114) or the set of fields 406 of the global object 112 does not include a required field 306, the operator controller 108 indicates that there is an error in the global object 112 and does not replicate the parent resource 104 according to the indications in the global object. It is noted these describes that if the metadata label is missing, the replication/append does not occur). 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 Burns, Roy, StackOverflow and Rozenraukh with Mallikarjuna because all the prior arts are in the same field of endeavor of configmap object management and because Burns teaches adding configmap objects to a pod without restarting, Roy teaches detecting new configmaps and adding configmaps object to a dictionary without restarting, Stackoverflow teaches appending a name of a configmap to a data element name from a configmap, Rozenraukh teaches determine whether the first ConfigMap includes a selected metadata label. Meanwhile, Mallikarjuna teaches aggregation (“ConfigMap”, “secret”) across namespaces, these teaching can be applied to Kubernetes-style ConfigMap management as it would improve reliability and traceability with predictable results. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Pub. No. 20240143318 A1 teaches efficient configuration management in continuous deployment. U.S. Pub. No. 20230079209 A1 teaches containerized routing protocol process for virtual private networks. U.S. Pub. No. 20220318001 A1 autonomous Kubernetes operator creation and management. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Willy W. Huaracha whose telephone number is (571)270-5510. The examiner can normally be reached on M-F 8:30-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached on (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /WH/ Examiner, Art Unit 2195 /BING ZHAO/Primary Examiner, Art Unit 2151
Read full office action

Prosecution Timeline

Jul 13, 2023
Application Filed
Dec 20, 2025
Non-Final Rejection — §101, §103
Mar 30, 2026
Response Filed

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12547427
DESERIALIZATION METHOD AND APPARATUS, AND COMPUTING DEVICE
2y 5m to grant Granted Feb 10, 2026
Patent 12541390
SYSTEM SUPPORT REPLICATOR
2y 5m to grant Granted Feb 03, 2026
Patent 12504993
HIGH-THROUGHPUT CONFIDENTIAL COMPUTING METHOD AND SYSTEM BASED ON RISC-V ARCHITECTURE
2y 5m to grant Granted Dec 23, 2025
Patent 12455753
CLOUD BASED AUDIO / VIDEO OPERATING SYSTEMS
2y 5m to grant Granted Oct 28, 2025
Patent 12443440
METHOD FOR EXECUTING DATA PROCESSING TASK IN CLUSTER MIXED DEPLOYMENT SCENARIO, ELECTRONIC DEVICE AND STORAGE MEDIUM
2y 5m to grant Granted Oct 14, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
73%
Grant Probability
99%
With Interview (+35.3%)
4y 1m
Median Time to Grant
Low
PTA Risk
Based on 410 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month