Prosecution Insights
Last updated: July 17, 2026
Application No. 18/474,899

AUTOMATED INDUSTRIAL AUTOMATION COMPONENT DISCOVERY AND EDGE INTEGRATION INTO A CONTAINER ORCHESTRATION SYSTEM

Non-Final OA §103§112
Filed
Sep 26, 2023
Examiner
SAAVEDRA, EMILIO J
Art Unit
2117
Tech Center
2100 — Computer Architecture & Software
Assignee
Rockwell Automation Technologies Inc.
OA Round
1 (Non-Final)
69%
Grant Probability
Favorable
1-2
OA Rounds
4m
Est. Remaining
96%
With Interview

Examiner Intelligence

Grants 69% — above average
69%
Career Allowance Rate
352 granted / 508 resolved
+14.3% vs TC avg
Strong +26% interview lift
Without
With
+26.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
29 currently pending
Career history
548
Total Applications
across all art units

Statute-Specific Performance

§101
1.4%
-38.6% vs TC avg
§103
86.2%
+46.2% vs TC avg
§102
6.2%
-33.8% vs TC avg
§112
4.9%
-35.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 508 resolved cases

Office Action

§103 §112
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is a response to an application filed 09/262023, in which claims 1-20 are pending and ready for examination. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 14 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Regarding claim 14, the claim contains the trademark/trade name Kubernetes. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a container orchestration system and, accordingly, the identification/description is indefinite. An internet search of appears to indicate that “KUBERNETES ® is a registered trademark of the Linux Foundation in the United States and other countries.” Examiner Notes Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1, 2-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Publication No. 2019/0041830 to Yarvis et al. (hereinafter Yarvis), in view of US Patent Publication No. 2024/0095002 to Waterman (hereinafter Waterman) Regarding claim 1, Yarvis teaches a computer-implemented method, comprising: detecting attachment of a first industrial automation component of a plurality of industrial automation components to an industrial automation network (An Industrial component resources, such as a node for control in a networked industrial environment, where a resource’s availability is detected in a map, thus attachment, see p79-80, p99-100, p10, Title, Fig. Fig. 1, Fig. 8, Fig. 11, p36, Yarvis), wherein the plurality of industrial automation components are attached to the industrial automation network and collectively perform an industrial automation process (An industrial component components are seen to be attached in a network, and perform an industrial process, see p3, p39, p89-90, 97 Fig. 9, 99-100, Fig. 7, Title, Fig. 1, Fig. 8, Fig. 11, 32, Yarvis); in response to detecting the attachment of the first industrial automation component, creating a representing the first industrial automation component in a container orchestration system hosted at least in part on a computing system communicably coupled with the industrial automation network (Container orchestration may be used in the system to create functional blocks representative of control components, see Fig. 8, p75-77, p82, p88, p41, p78-79, p128, p61,94, Yarvis), wherein creating the pod comprises: determining a type of the first industrial automation component, identifying functionality specific to the first industrial automation component based on the type, provisioning software that implements the functionality (Orchestration generates specified functional blocks required of control resources and best fit to the available resource capabilities used in function deployment, p61, p78-80, p88, Yarvis), generating a container comprising the software (Container can be orchestrated that comprises application functional blocks, see p84, p80, Fig. 8, see p80, Yarvis), and coupling interfaces in the software to interfaces of the first industrial automation component (Communications paths established between components, see p80, 94, p105, Yarvis); in response to creating the representation, exposing the representation in the container orchestration system (Deployment of components through orchestration system that includes a container is interpreted as exposing, see p80, 94, Yarvis). Yarvis does not explicitly teach a pod; a container in a pod; in response to creating a pod, exposing a pod in an container orchestration system However, Waterman from the same or similar field of orchestration, teaches a pod (Pod, see p6, Fig. 2, Waterman); a container in a pod (Container in a pod, see p6, Fig. 2, Waterman); in response to creating a pod, exposing a pod in a container orchestration system (A new container in a pod is deployed through orchestration, see p62, p6, 61, Waterman). It would have been obvious to a person of ordinary skill in the art before the filing date of the claimed invention to modify the control and orchestration as described by Yarvis and incorporating pods with containers and exposing pods in an orchestration system, as taught by Waterman. One of ordinary skill in the art would have been motivated to do this modification in order to properly use a mechanism of an orchestration system that employs containers within pods, and to deploy a new created container which are in pods in a specified orchestration platform, so as to actually permit a system to use the containers in a pod (see p62, p6, 61, Waterman). Regarding claim 2, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the first industrial automation component is an industrial automation hardware device (Resources in orchestration system can be hardware, see p36, p80, 94, Yarvis). Regarding claim 4, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the functionality comprises modifying an operational or physical behavior of the industrial automation hardware device (Control application implement functional changes (modifications) of resource such as physical actuator hardware, see p106, p36, p80, 94, Yarvis). Regarding claim 5, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the first industrial automation component is an industrial automation software component (Resources in orchestration system can be software, see p36, p80, 94, Yarvis). Regarding claim 6, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the computing system is an edge computing device coupled to the industrial automation network (Edge nodes, see Fig, 1A, p10, Fig, 2B, 32, Yarvis). Regarding claim 7, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the edge computing device is initially deployed with a thin layer of compute comprising minimum software components for hosting an on-premises portion of the container orchestration system (Orchestration can leverage lower commodity hardware and software, which is being interpreted as a thin layer, see 86, Yarvis). Regarding claim 8, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the functionality comprises at least one of: configuring the industrial automation component, monitoring behavior of the industrial automation component, and data access of the industrial automation component (Monitoring implemented with data information output, and configuration of resources in an automation system, see 79, p36, p55, 155 Yarvis). Regarding claim 9, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the functionality comprises enforcing security policies associated with the industrial automation component (Security implemented including hardware root of trust and software security in an automation system, thus comprising a security enforcement mechanism, see p37, 59, Yarvis). Regarding claim 10, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the computing system is a cloud-based system (Cloud system, see p29, p47, Yarvis). Regarding claim 11, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Waterman further teaches wherein a container orchestration system comprises a plurality of computing systems hosting portions of the container orchestration system that share a common control plane to comprise a single virtual system (An orchestration platform system with computing nodes each comprising worker nodes with at least containers virtualizing and sharing a system is being interpreted as a plane with at least worker portions with containers of the orchestration in the same plane, Fig. 2, p3, p5-6, p4, 63,61, Waterman). It would have been obvious to a person of ordinary skill in the art before the filing date of the claimed invention to modify the control and orchestration as described by the combination that includes Yarvis and incorporating an orchestration system with at least a portion of computing systems hosting portions of the container orchestration system sharing a common plane, as taught by Waterman. One of ordinary skill in the art would have been motivated to do this modification in order to better provide a flexible less complex system by sharing resources such as operating and network resources (see p3, p64, p62, p6, 61, Waterman). Regarding claim 12, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches the first industrial automation component (An Industrial component resources, such as a node for control in a networked industrial environment, where a resource’s availability is detected in a map, thus attachment, see p79-80, p99-100, p10, Title, Fig. Fig. 1, Fig. 8, Fig. 11, p36, Yarvis) Waterman further teaches wherein detecting an attachment of a component is performed by a second pod of a container orchestration system (A container, which in a specified orchestration platform are in a pods, is second pod separate a peripheral device container pod (i.e. a first pod), and is responsible for accessing connected devices, thus detecting attached devices, see p6, p65, Fig. 1, 2, Waterman). It would have been obvious to a person of ordinary skill in the art before the filing date of the claimed invention to modify the control and orchestration as described by the combination that includes Yarvis and incorporating a second pod detecting attached of a component, as taught by Waterman. One of ordinary skill in the art would have been motivated to do this modification in order to be able to access connected devices in order to exposing said devices (see p65, p4-p6, p71, p4, p6, 22, Waterman). Regarding claim 13, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches the first industrial automation component (An Industrial component resources, such as a node for control in a networked industrial environment, where a resource’s availability is detected in a map, thus attachment, see p79-80, p99-100, p10, Title, Fig. Fig. 1, Fig. 8, Fig. 11, p36, Yarvis) Waterman further teaches wherein creating a pod representing a component is performed by a second pod of a container orchestration system (A second pod registers and stores and provides image files that involve creatin of a container representing a component of a system such as a software component, where containers are in pods, see p71, p4, p6, 22, Waterman). It would have been obvious to a person of ordinary skill in the art before the filing date of the claimed invention to modify the control and orchestration as described by the combination that includes Yarvis and incorporating a second pod for creating a pod, as taught by Waterman. One of ordinary skill in the art would have been motivated to do this modification in order to provide a component responsible for and providing the registering, storing, and accessing required for creating a new container with corresponding pod as performed by a specific known container orchestration platform (see p4-p6, p71, p4, p6, 22, Waterman). Regarding claim 14, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Waterman further teaches wherein a container orchestration system is KUBERNETES (Kubernetes, see p6, Waterman). It would have been obvious to a person of ordinary skill in the art before the filing date of the claimed invention to modify the control and orchestration as described by the combination that includes Yarvis and incorporating kubernetes, as taught by Waterman. One of ordinary skill in the art would have been motivated to do this modification in order to a use a known accessible container orchestration platform to implement container orchestration in a system (see p4-p6, Waterman). Regarding claim 15, Yarvis teaches a system, comprising: a cloud-based (Cloud system, see p29, p47, Yarvis); an industrial automation network (An Industrial component resources, such as a node for control in a networked industrial environment, see p79-80, p99-100, p10, Title, Fig. Fig. 1, Fig. 8, Fig. 11, p36, Yarvis), detects attachment of industrial automation components to the industrial automation network (An Industrial component resources, where a resource’s availability is detected in a map, thus attachment, see p79-80, p99-100, p10, Title, Fig. Fig. 1, Fig. 8, Fig. 11, p36, Yarvis), wherein the industrial automation components collectively perform an industrial automation process (An industrial component components are seen to be attached in a network, and perform an industrial process, see p3, p39, p89-90, 97 Fig. 9, 99-100, Fig. 7, Title, Fig. 1, Fig. 8, Fig. 11, 32, Yarvis); library of selectable software functionality (Library of apps, where software app functions can be selected, see Fig. 2A, p132, 128, 127, 105, Yarvis) ; receives notification that an industrial automation component is attached to the industrial automation network (An Industrial component resources, where a resource’s availability is notified in a map, see p79-80, p99-100, p10, Title, Fig. Fig. 1, Fig. 8, Fig. 11, p36, Yarvis); in response to the notification, creates a representation the new industrial automation component in the container orchestration system (Container orchestration may be used in the system to create functional blocks representative of control components, see Fig. 8, p75-77, p82, p88, p41, p78-79, p128, p61,94, Yarvis), wherein creating comprises: determining a type of the industrial automation component, identifying functionality specific to the new industrial automation component based on the type, provisioning selected software that implements the functionality (Orchestration generates specified functional blocks required of control resources and best fit to the available resource capabilities used in function deployment, p61, p78-80, p88, Yarvis); generating a container comprising the selected software (Container can be orchestrated that comprises application functional blocks, see p84, p80, Fig. 8, see p80, Yarvis), and coupling interfaces in the selected software to interfaces of the new industrial automation component (Communications paths established between components, see p80, 94, p105, Yarvis); in response to creating the representation, exposing the representation in the container orchestration system (Deployment of components through orchestration system that includes a container is interpreted as exposing, see p80, 94, Yarvis). Yarvis does not explicitly teach a cloud-based portion comprising a first pod of a plurality of pods of the container orchestration system, the first pod providing access to a library; an on-premises portion of the container orchestration system implementation, wherein the on-premises portion is communicably coupled to the cloud-based portion via a common control plane and is communicably coupled; wherein the on-premises portion comprises: a second pod of the plurality of pods; third pod of the plurality of pods that: receives notification from the second pod that a new; using the first pod to access the library; a pod; a container in a pod; in response to creating a pod, exposing a pod in an container orchestration system. However, Waterman from the same or similar field of orchestration, teaches a cloud-based portion comprising a first pod of a plurality of pods of the container orchestration system (Cloud server portion with containers that are in pods, see Fig. 1, p6, p61, p3, 65, Waterman) , the first pod providing access to a library (Library of peripheral devices, see p65, p6, p61, p3, 65, Waterman); an on-premises portion of the container orchestration system implementation (SST comprise on-premise portions, see Fig. 1, Fig. 2, Waterman), wherein the on-premises portion is communicably coupled to the cloud-based portion via a common control plane and is communicably coupled (An orchestration platform system with computing nodes each comprising worker nodes with at least containers virtualizing and sharing a system is being interpreted as a plane with at least worker portions with containers of the orchestration in the same plane, Fig. 1, Fig. 2, p3, p5-6, p4, 63,61, Waterman); wherein the on-premises portion comprises: a second pod of the plurality of pods (A container, which in a specified orchestration platform are in a pods, is second pod separate a peripheral device container pod (i.e. a first pod), and is responsible for accessing connected devices, thus detecting attached devices, see p6, p65, Fig. 1, 2, Waterman); third pod of the plurality of pods that: receives notification from the second pod that a new is attached (New software or hardware, where another “third” pod receives request, and registers and stores and provides image files that involve creatin of a container representing a component of a system such as a software component, where containers are in pods, see p71, p65,, p4, p6, 22, Waterman), see p3, Waterman); using a first pod to access the library (library with obtaining selected components dependencies, see p65, p71, p65,, p4, p6, 22, Waterman); a pod (Pod, see p6, Fig. 2, Waterman); a container in a pod (Container in a pod, see p6, Fig. 2, Waterman); in response to creating a pod, exposing a pod in a container orchestration system (A new container in a pod is deployed through orchestration, see p62, p6, 61, Waterman). It would have been obvious to a person of ordinary skill in the art before the filing date of the claimed invention to modify the control and orchestration as described by Yarvis and incorporating pods, library, common plane, pods with containers and exposing pods in an orchestration system, as taught by Waterman. One of ordinary skill in the art would have been motivated to do this modification in order to better provide a flexible less complex system by sharing resources such as operating and network resources, in order to properly use a mechanism of an orchestration system that employs containers within pods, in order to access connected devices in order to exposing said devices, in order to provide a component responsible for and providing the registering, storing, and accessing required for creating a new container with corresponding pod as performed by a specific known container orchestration platform, and in order to deploy a new created container which are in pods in a specified orchestration platform, so as to actually permit a system to use the containers in a pod (see p62, p6, 61, p3, p64, p65, p4-p6, p71, 22, Waterman). Claim 16 is rejected on the same grounds as claim 7. Claim 18 is rejected on the same grounds as claims 4, 8, and/or 9. Claim 19 is rejected on the same grounds as claims 3 and/or 5. Regarding claim 20, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yardis further teaches a library of selectable software functionality (Library of apps, where software app functions can be selected, see Fig. 2A, p132, 128, 127, 105, Yarvis). Claims 3 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yarvis, in view of Waterman, and in further view of US Patent Publication No. 2016/0274552 to Strohmenger et al., (hereinafter Strohmenger). Regarding claim 3, the combination of Yarvis and Waterman teaches all the limitations of the base claim as outlined above, and are analyzed as previously discussed with regard to that claim. Yarvis further teaches wherein the industrial automation hardware device communicates over an industrial automation network using a protocol (Network and communications protocol used in automation network, see p140, 107, Yarvis) Yarvis does not explicitly teach Common Industrial Protocol (CIP). However, Strohmenger from the same or similar field of industrial automation systems with communications, teaches Common Industrial Protocol (CIP) (Common Industrial Protocol (CIP), see p142, Strohmenger); It would have been obvious to a person of ordinary skill in the art before the filing date of the claimed invention to modify the control and orchestration as described by the combination that includes Yarvis and incorporating Common Industrial Protocol, as taught by Strohmenger. One of ordinary skill in the art would have been motivated to do this modification in order to use a protocol hat is suitable for network communications among components of a system (see p142, Strohmenger). Claim 17 is rejected on the same grounds as claim 3. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Malladi et al., US. Patent Publication No. 2018/0300124 teaches an edge computing platform with orchestration and customized application based on available resources. Biernat et al., US. Patent Publication No. 2022/0091583 teaches a container orchestration system that includes updating of operational technology devices. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to EMILIO J SAAVEDRA whose telephone number is (571)270-5617. The examiner can normally be reached M-F: 9:30am-5:30pm (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, Robert E Fennema can be reached at (571) 272-2748. 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. /EMILIO J SAAVEDRA/Primary Patent Examiner, Art Unit 2117
Read full office action

Prosecution Timeline

Sep 26, 2023
Application Filed
May 14, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12681447
OPTIMIZED PROCESSING ENGINE OF AN INTERNET OF THINGS (IOT) DEVICE AND A METHOD OF GENERATING THE SAME
3y 7m to grant Granted Jul 14, 2026
Patent 12683142
ELECTRODE THICKNESS CONTROL METHOD AND CONTROL SYSTEM
2y 10m to grant Granted Jul 14, 2026
Patent 12680719
QUICK HEAT ALGORITHM FOR MODULATING HEATING EQUIPMENT
2y 2m to grant Granted Jul 14, 2026
Patent 12669853
Systems And Methods For Controlling Leaks In Liquid Cooling Systems For Computer Devices
2y 8m to grant Granted Jun 30, 2026
Patent 12645191
Electrical Equipment Fault Diagnosis And Control
3y 2m to grant Granted Jun 02, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
69%
Grant Probability
96%
With Interview (+26.2%)
3y 1m (~4m remaining)
Median Time to Grant
Low
PTA Risk
Based on 508 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month