DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Action is FINAL and is in response to the claims and remarks filed October 14, 2025 via RCE. Claims 1-20 are currently pending, of which claims 1 and 11 are currently amended.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on October 14, 2025 has been entered.
Response to Arguments
Prior Art Rejections
Applicant’s remarks regarding the previously cited art have been fully considered. Examiner notes that numerous arguments have been repeated from the previous Action. This includes the separate and independent ecosystems as still being taught by Plache and Narayanan. See Final Rejection 2-–4 (mailed 14 July 2025); see also Remarks 6–7 (filed 26 June 2025). Those arguments and responses are incorporated fully herein. Nevertheless, Examiner will be responding to each of Applicant’s arguments below. Specifically, Applicant has now amended the claim language to further clarify specific limitations. These amendments do not overcome the previously cited prior art, as will be discussed in the ensuing responses.
Applicant first argues that Plache’s teachings are directed to “various components and services within a single coherent system – not distinct, independent ecosystems each associated with separate physical assets and independent runtime environments”. See Remarks 6. Moreover, Applicant argues that Plache does not disclose the reception of a dedicated file that externally defines an interface description language with associated topics. See Id. at 7. Examiner respectfully disagrees. While Narayana is mentioned in passing in the Remarks, Applicant has not focused on the teachings of Narayana. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Furthermore, Narayana has been cited and combined with Plache to disclose the separate environments as claimed. Plache is explicit in its teaching that the services and their definitions and specifications can be used across multiple locations, platforms, and hosts. Moreover, Plache discloses that “at least one service provider platform other than the service provider platform” and also “providing a standardized programming structure between various components or hosts 102 (e.g., from different manufacturers) within the industrial automation system 100” See Plache Fig. 2 and paras. [0038] and [0045]. However, to further drive this point home and express the independence of these different services and hosts, Narayana has been introduced. Narayana teaches that the platform interfaces of Plache can be deployed using a different set of APIs and/or computing application and programming environments. These environments are separate and unique and belong to different third party vendors. See Narayanan paras. [0011-12], [0026-27], and [0060].
Additionally, Applicant has amended the claim language to recite that the interface file is not “defined by a user” and argues that this language is not taught by Plache either. See Remarks 7. Examiner again respectfully disagrees. The system of Plache includes multiple hosts 204 that a user/operator can interact with. More specifically, a host “is configured to interface with a user and/or entities (e.g., the Internet, another system, a computer, and so forth), hereinafter referred to as user 104. The interface between host 102 and user 104 can be through various interface mechanisms, including a human-machine interface (HMI) or a graphical user interface (GUI).” The user, via the host, can thus utilize the definitions and specifications. See Plache Figs. 1 and 2 and paras. [0034] and [0061].
Applicant further argues that Plache “does not disclose the reception of a dedicated file that externally defines an interface description language with associated topics.” See Remarks 7. Examiner again respectfully disagrees. Libraries and specifications, as discussed in Plache, are most certainly “files” under the broadest reasonable interpretation. Moreover, Plache explicitly states that “a configuration unit can be embodied in a data module, a file or file system, a set of registers, or the like.”. See Plache para. [0084]. Moreover, “service generator 928 can associate information (e.g., data, metadata, data type(s), code instructions, service profile(s), service procedure(s) . . . ) related to the at least one interface component and disclosed in the at least one specification with a set of computer-executable instructions.” See Id. at para. [0087]. Instructions are files as well.
It is for at least these reasons, and the reasons cited below, that the claims remain rejected in this Action.
Examiner’s Note
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references 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 their 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.
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.
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, 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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Plache et al. (U.S. Publication No. 2011/0022192; hereinafter, “Plache”) and further in view of Narayanan et al. (U.S. Publication No. 2009/0222842; hereinafter, “Narayanan”).
As per claim 1, Plache teaches a method performed in an industrial system that comprises a plurality of ecosystems that define respective physical assets and automation equipment configured to control the physical assets (See Plache paras. [0009] and [0037]), the method comprising:
receiving an interface file that defines an interface description language defining an interface definition and topic, the interface definition and the topic of the interface file defined by a user (See Plache paras. [0079-80], [0084], and [0087]: “To generate an interface service, service generator 928 acquires (retrieve, receive, etc.) the at least one specification that that defines the at least one interface component…” Additionally, the service generator can link to libraries and other information like metadata, data types, service profiles, etc. These are “topics”; Fig. 2 and paras. [0034], [0045], and [0061]: “includes a host 102 that is configured to interface with a user and/or entities (e.g., the Internet, another system, a computer, and so forth), hereinafter referred to as user 104. The interface between host 102 and user 104 can be through various interface mechanisms, including a human-machine interface (HMI) or a graphical user interface (GUI).” The user, via the host, can utilize the definitions and specifications);
based on the interface definition and topic, generating a first integration connector that is specific to a first ecosystem of the plurality of ecosystems, the first ecosystem developed by a first vendor (See Plache para. [0087]: generating executable code to implements the interface specification, where the code is “specific to a programming language employed to execute the service generated to implement the interface component and functionality thereof”); and
using the first integration connector to trigger an action, from the first ecosystem, performed at a second ecosystem of the plurality of ecosystems (See Plache paras. [0087-88]: “an interface service exposes functionality associated with an interface component in response to execution of the interface service.” When executed, the functionality of the interface component is generated).
Plache teaches the first ecosystem via the service provider, as well as “at least one service provider platform other than the service provider platform” and also “providing a standardized programming structure between various components or hosts 102 (e.g., from different manufacturers) within the industrial automation system 100” (See Plache paras. [0011], [0045], and [0038]). Plache further teaches that functional elements of the system “can include one or more functional elements associated with disparate operational environments (e.g., control environments in a control layer) and thus disparate portions of a single logical unit can operate under disparate requirement(s) or specification(s)” (See Plachepara. [0074]). Nevertheless, Plache does not explicitly teach that a different vendor develops the second independent ecosystem.
Narayanan teaches the second system of the plurality of ecosystems that is independent from the first ecosystem, the second ecosystem developed by a different vendor as compared to the first vendor that developed the first ecosystem (See Narayanan paras. [0026-27]: “The SAC 100 also includes a Platform Interface 130, which enables the SAC 100 to interact with many different device platform environments 132.” Additionally, “allows the SAC 100 to interact with many different services and service infrastructure systems 142… Different platforms use different API's or sets of API's and different parameters for this function, and different application programming languages use different instructions for this function.”; paras. [0011-12] and [0060]: different computing application and programming environments for the APIs, including Windows, Symbian, Linux, etc.).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine, with a reasonable expectation of success, the environments of Plache with the different services and APIs of Narayanan. One would have been motivated to combine these references because both references disclose data management in device platform environments with interfaces interacting within different platforms. Narayanan helps prevent “inefficient use and duplication of resources for application developers, device suppliers, and service providers” so as to reduce “the cost for specialized training and tools” and increase “flexibility for providers and users” (See Narayanan para. [0007]).
As per claim 2, Plache/Narayanan further teaches the method of claim 1, wherein the action comprises retrieving information from the second ecosystem by the first ecosystem, the information defining semantics associated with the first ecosystem (See Plache para. [0041]: “the interface can define external behaviors supplied to at least one client application engaging the service 106. Through the interface, the service 106 can expose data, expose operations that can be performed, expose dependencies on other services, and so forth”).
As per claim 3, Plache/Narayanan further teaches the method of claim 1, wherein the action comprises one or more physical assets of the second ecosystem performing a task defined by the first ecosystem (See Plache paras. [0041] and [0053]: operations that can be performed on a client, where a single interface can support a plurality of clients. Furthermore, there can be common reusable definitions, common specifications, and common services across the multiple platform configurations. Therefore, the first ecosystem can share these reusable common features with other ecosystems).
As per claim 4, Plache/Narayanan further teaches the method of claim 1, the method further comprising: based on the interface file, generating a second integration connector that is specific to the second ecosystem (See Plache para. [0041]: “an industrial process can be defined with a plurality of services, wherein a first service is a control service that controls a second service (e.g., equipment service) and a third service (e.g., material service), wherein the third service is subordinate to the second service. It is to be appreciated that the service 106 can support more than one interface, e.g., to engage with more than one client application, or to logically partition the functionality of the service”; Fig. 4 and paras. [0052-55] and [0087]: generating executable code to implements the interface specification, where the code is “specific to a programming language employed to execute the service generated to implement the interface component and functionality thereof”. Therefore, the second connector can be created just like the first, using the shared services, definitions, specifications, etc.).
As per claim 5, Plache/Narayanan further teaches the method of claim 4, the method further comprising: plugging the first integration connector to the second integration connector, so as to also use the second integration connector to trigger the action performed by the second ecosystem (See Plache Figs. 4, 5, and paras. [0041] and [0052-54]: interface connects service to other services, among a plurality of services. The services can have reusable definitions that can be executed, or triggered).
As per claim 6, Plache/Narayanan further teaches the method of claim 5, the method further comprising: running the first integration connector on a first machine and also running the second integration connector on the first machine, so as to plug the first integration connector directly to the second integration connector (See Plache Figs. 4, 5, and paras. [0041] and [0052-54]: interface connects service to other services, among a plurality of services. The services can have reusable definitions that can be executed, or triggered. Furthermore, “Each component (e.g., service, reusable definition, specification) of the platform can be located anywhere within an industrial control system 400 and does not need to be co-located with other components of the platform and/or the host(s) 406.” Therefore, the components can be directly associated with the different connections and connected with one another through the different platform configurations).
As per claim 7, Plache/Narayanan further teaches the method of claim 5, the method further comprising: at runtime, inserting a first communication connector between the first integration connecter and the second integration connector, such that communication between the first integration connector and the second integration connector traverses a machine that hosts the first communication connector (See Plache Fig. 4 and paras. [0052-55]: interface components of device 402 that can interact with a number of hosts 406 and multiple platform configurations. This further includes the ability to interact with the platform configurations as well as the components of the platform within the industrial control system. “Hopping” is merely the notion that the devices can be in communication with the host(s)).
As per claim 8, Plache/Narayanan further teaches the method of claim 7, the method further comprising: at runtime, inserting a second communication connector between the first communication connecter and the second integration connector, such that communication between the first and second integration connectors traverses multiple machines and ecosystems (See Plache Fig. 4 and paras. [0052-55]: interface components of device 402 that can interact with a number of hosts 406 and multiple platform configurations. This further includes the ability to interact with the platform configurations as well as the components of the platform within the industrial control system. A plurality of hosts and platform configurations and their services can be controlled. “Hopping” is merely the notion that the devices can be in communication with the host(s)).
As per claim 9, Plache/Narayanan further teaches the method of claim 1, the method further comprising: using the first integration connector to trigger another action, from the first ecosystem, performed at a third ecosystem of the plurality of ecosystems, the action triggered using a third integration connector that is specific to the third ecosystem (See Plache para. [0087]: generating executable code to implements the interface specification, where the code is “specific to a programming language employed to execute the service generated to implement the interface component and functionality thereof”; Figs. 4, 5, and paras. [0041] and [0052-54]: interface connects service to other services, among a plurality of services. The services can have reusable definitions that can be executed, or triggered. This would be applied to additional actions, whether it is the second, third, or Nth action).
As per claim 10, Plache/Narayanan further teaches the method of claim 2, the method further comprising: displaying the information and the semantics on a human machine interface of the first ecosystem (See Plache paras. [0034] and [0074-75]: “The interface between host 102 and user 104 can be through various interface mechanisms, including a human-machine interface (HMI) or a graphical user interface (GUI)”).
As per claims 11-20, the claims are directed to a computing system that implements the same features as the method of claims 1-10, respectively, and are therefore rejected for at least the same reasons therein. Furthermore, Plache/Narayanan teaches an industrial computing system, the computing system comprising: a processor; and a memory storing instructions that, when executed by the processor, configure the system to implement said method(s) (See Plache Fig. 12 and paras. [0111-114]).
Conclusion
All claims are identical to or patentably indistinct from, or have unity of invention with claims in the application prior to the entry of the submission under 37 CFR 1.114 (that is, restriction (including a lack of unity of invention) would not be proper) and all claims could have been finally rejected on the grounds and art of record in the next Office action if they had been entered in the application prior to entry under 37 CFR 1.114. Accordingly, THIS ACTION IS MADE FINAL even though it is a first action after the filing of a request for continued examination and the submission under 37 CFR 1.114. See MPEP § 706.07(b). 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 Nicholas Klicos whose telephone number is (571)270-5889. The examiner can normally be reached Mon-Fri 9:00 AM-5:00 PM.
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, Scott Baderman can be reached at (571) 272-3644. 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.
/NICHOLAS KLICOS/Primary Examiner, Art Unit 2118