DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the America Invents Act (AIA ).
Response and Claim Status
The instant Office action is responsive to the response received August 12, 2026 (the “Response”).
Claims 1–4 and 10–12 are currently pending.
Claim Rejections – 35 U.S.C. § 112
The following is a quotation of 35 U.S.C. § 112(b): “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 MPEP recites “[d]uring examination, after applying the broadest reasonable interpretation consistent with the specification to the claim, if the metes and bounds of the claimed invention are not clear, the claim is indefinite and should be rejected.” MPEP § 2173.02(I) (citing In re Packard, 751 F.3d 1307, 1311 (Fed. Cir. 2014)). “For example, if the language of a claim, given its broadest reasonable interpretation, is such that a person of ordinary skill in the relevant art would read it with more than one reasonable interpretation, then a rejection under 35 U.S.C. 112(b) . . . is appropriate.” Id. See also id. § 2173.05(e)(discussing indefiniteness arising for terms lacking proper antecedent basis).
Claims 1–4 and 10–12 are rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
(I) claim 1, lines 6–12,
for each of the one or more runtime services, the configuration item is provided with an identifier that is unique within the distributed control system, and that is associated with a physical host address corresponding to an endpoint of a corresponding runtime service of the one or more runtime services and that is stored as an attribute of the configuration item of the corresponding runtime service
adds ambiguity to the claim because the Examiner is uncertain as to whether the limitation refers to
(A) for each of the one or more runtime services, the configuration item (i) is provided with an identifier that is unique within the distributed control system, and (ii) that is associated with a physical host address corresponding to an endpoint of a corresponding runtime service of the one or more runtime services and (iii) that is stored as an attribute of the configuration item of the corresponding runtime service
(B) for each of the one or more runtime services, the configuration item is provided with an identifier (i) that is unique within the distributed control system, and (ii) that is associated with a physical host address corresponding to an endpoint of a corresponding runtime service of the one or more runtime services and (iii) that is stored as an attribute of the configuration item of the corresponding runtime service
(C) for each of the one or more runtime services, the configuration item (i) is provided with an identifier that is unique within the distributed control system, and (ii) that is associated with a physical host address (a) corresponding to an endpoint of a corresponding runtime service of the one or more runtime services and (b) that is stored as an attribute of the configuration item of the corresponding runtime service
(D) for each of the one or more runtime services, the configuration item (i) is provided with an identifier that is unique within the distributed control system, and (ii) that is associated with a physical host address corresponding to an endpoint (a) of a corresponding runtime service of the one or more runtime services and (b) that is stored as an attribute of the configuration item of the corresponding runtime service
It is assumed for examination purposes that the limitation refers (B). See MPEP § 2173.06 (reciting “When making a rejection over prior art in these circumstances, it is important that the examiner state on the record how the claim term or phrase is being interpreted with respect to the prior art applied in the rejection.”; emphasis omitted).
(II) while antecedent basis exists for a unique identifier of a configuration item at claim 1, lines 6–9, “the unique identifier of the corresponding runtime service” at claim 1, lines 15–16 lacks clear antecedent basis.
Claim Rejections – 35 U.S.C. § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1–4, 10, and 12 are rejected under 35 U.S.C. § 102 as being anticipated by Tuomi, Aggregating OPC UA Server for Flexible Manufacturing Systems, Aalto University, pp. 1–53 (July 2015).
Response to Arguments
Applicants assert
Tuomi, discloses an aggregating OPC UA server that preserves separate OPC UA server/address-space context. The Action relies on Tuomi’s disclosure that “Nodes are identified in the database by their NodeId and the ServerURI of the server containing them,” and that each encountered unique combination of namespace URI and server URI is assigned a unique identifying value in a UnifiedNameSpace table.
Response 7. Applicants argue
this disclosure fails to teach configuration items managed by the respective runtime services being assigned to a common namespace extending across the runtime services by means of a system-wide unique identifier associated with the configuration item. Instead, Tuomi identifies nodes using NodeId together with server-specific information, thereby retaining the separate server/address-space context. This distinction is further reinforced by Tuomi’s discussion of NodeID conflicts. Tuomi recognizes that NodeID conflicts may occur and that the aggregating OPC UA server must be able to distinguish nodes having the same NodeID but different address spaces, and fails to disclose, “a common namespace that extends to the one or more runtime services spanning over the server and control layer by means of the unique identifier,” as recited in amended claim 1.
Id.
The Examiner is unpersuaded of error. At the outset, the Examiner notes Applicants’ argument is not commensurate with the scope of claim 1, which does not recite “a system-wide unique identifier” associated with a configuration item. See In re Self, 671 F.2d 1344, 1348 (CCPA 1982) (limitations not appearing in the claims cannot be relied upon for patentability). Claim 1 recites “a common namespace that extends to the one or more runtime services spanning over the server and control layer” that a configuration item of a corresponding runtime service is assigned to by means of a unique identifier of the corresponding runtime service.
Tuomi discloses “[t]he address space of an OPC UA server is the totality of the data it exposes. It is a graph consisting of nodes and edges.” Tuomi 11. According to Tuomi, each node (the claimed “configuration item”) is identified with a unique NodeId. See id. (reciting “Each Node is identified with a unique NodeId.” and “Nodes are identified by their NodeId”). “These identifiers can be of three types, Numeric, String or GUID. They are unique numbers, unique strings, and unique 64-bit numbers, respectively. Identifying numbers and strings need to be chosen in a way that does not cause a conflict.” Id.
Moreover, Tuomi’s Figure 4.1 (the claimed “distributed control system”) comprises one or more runtime services spanning over an OPC UA server (the claimed “server”). See Tuomi 21 (reciting “OPC UA services”), 22 (reciting “OPC UA service Write”). Such runtime services are performed by the nodes (the claimed “configuration item”) of the OPC UA server.
Tuomi, then, discloses for each of the runtime services, the node (the claimed “configuration item”) of the corresponding runtime service is assigned to an address space (the claimed “common namespace”) that extends to the one or more runtime services spanning over an OPC UA server (the claimed “server”) and control layer by means of a unique identifier (“Nodes are identified in the database by their NodeId and the Serveruri of the server containing them . . . The NodeId consists of an identifier, an identifier type, and a namespace. . . . Each encountered unique combination of namespace uri and server uri are assigned a unique identifying value in the UnifiedNameSpace table (Figure 5.4).” at p. 32) of corresponding runtime service.
Although Applicants’ arguments do not specify where in Tuomi discloses NodeID conflicts (see Response 7), the Examiner finds Applicants’ argument is directed to “nodes from several OPC UA address spaces in one aggregating address space.” Tuomi 22. According to Tuomi, “[w]hen representing nodes from several OPC UA address spaces in one aggregating address space, the possibility of a NodeId conflict arises. The aggregating OPC UA server needs to be able to distinguish nodes with the same NodeId, but different address spaces.” Id.
But the mapping the Examiner provides above does not rely on nodes from several OPC UA address spaces in one aggregating address space. Rather, the mapping the Examiner provides above relies on nodes from a single OPC UA address space of a single OPC UA server (as illustrated in Figure 3.1).
The Rejection
Regarding claim 1, Tuomi discloses a distributed control system (fig. 4.1 including the OPC UA server depicted in fig. 3.1) for industrial processes (intended use in italics; MPEP § 2111.02), the distributed control system comprising one or more runtime services (the services provided by “OPC UA Server” at fig. 3.1; “OPC UA services” at p. 21; “OPC UA service Write” at p. 22) spanning over a server (fig. 3.1 illustrates a server-layer because the OPC UA server accepts requests and messages from clients, processes them, and returns data) and control layer (fig. 3.1 illustrates a control layer that comprises operations to respond to request and publish messages “From OPC UA client”), wherein:
each of the one or more runtime services is arranged to manage its own configuration item (“OPC UA AddressSpace” at fig. 3.1 comprising nodes);
for each of the one or more runtime services, the configuration item is provided with an identifier (“Id,” “UnifiedNameSpaceId,” “NodeIdType,” and “NodeIdvalue” at fig. 5.4; “Nodes are identified in the database by their NodeId and the Serveruri of the server containing them . . . The NodeId consists of an identifier, an identifier type, and a namespace. . . . Each encountered unique combination of namespace uri and server uri are assigned a unique identifying value in the UnifiedNameSpace table (Figure 5.4).” at p. 32) that is unique within the distributed control system, and that is associated with a physical host address (“Each encountered unique combination of namespace uri and server uri are assigned a unique identifying value in the UnifiedNameSpace table (Figure 5.4).” at p. 32; “ServerEndPointURI” at fig. 5.4; “serveruri” at p. 32) corresponding to an endpoint (“the server containing them” at p. 32 of “ServerEndPointURI” at fig. 5.4) of a corresponding runtime service of the one or more runtime services and that is stored as an attribute (“the configuration specifies database procedures used for mappings. Upon reading the configuration, proxy nodes are created in the Database folder and a mapping is created to a function connecting to a database, ultimately retrieving the value.” at p. 33) of the configuration item of the corresponding runtime service; and
for each of the one or more runtime services, the configuration item of the corresponding runtime service is assigned to a common namespace (“Each Node is identified with a unique NodeId.” and “Identifying numbers and strings need to be chosen in a way that does not cause a conflict.” at p. 11) that extends to the one or more runtime services spanning over the server and control layer by means of the unique identifier of the corresponding runtime service.
Regarding claim 2, Tuomi discloses wherein the unique identifier with which each of the one or more runtime services is provided comprises a concatenation of two or more of: a Global Unique Identifier, GUID, for an object (“Each Node is identified with a unique NodeId. These identifiers can be of three types, Numeric, String or guid.” at p. 11); a GUID for the model; and Open Platform Communications Unified Architecture, OPC UA, node path for the configuration item (“OPC UA” at fig. 3.1).
Regarding claim 3, Tuomi discloses comprising runtime clients (“OPC UA client” at fig. 3.1; “Alarm and Conditions” section at pages 14–15) for human supervision of industrial processes (intended use in italics).
Regarding claim 4, Tuomi discloses wherein the runtime clients for human supervision of industrial processes (intended use in italics) comprises one or more of: process graphics, trend charts and alarm management (“Alarm and Conditions” section at pages 14–15).
Regarding claim 10, Tuomi discloses further comprising a Service Dispatcher component (the OPC UA server illustrated in fig. 3.1 at least suggests including software) configured to:
- receive, from a runtime service (the services provided by “OPC UA Server” at fig. 3.1) of the one or more runtime services, the unique identifier (“Tables implementing hda, illustrated in figure 5.4, contain the information required to identify nodes on opc ua servers, as well as to store and retrieve values. Nodes are identified in the database by their NodeId and the Serveruri of the server containing them – the same values used to identify nodes in configuration.” at p. 32) of the configuration item (“OPC UA AddressSpace” at fig. 3.1 comprising nodes) of the runtime service;
- obtain, based on the unique identifier, the host address (“Id,” “NameSpaceURI,” and “ServerEndPointURI” of “UnifiedNameSpace” at fig. 5.4) associated with the unique identifier from a mapping table (fig. 5.4), by accessing the mapping table, and
- provide (p. 32 of s. 5.2.4; p. 35 of s. 5.3.2), to the runtime service, the host address associated with the unique identifier.
Regarding claim 12, Tuomi discloses wherein the Service Dispatcher component is an in-process component in a runtime client (the OPC UA server illustrated in fig. 3.1 at least suggests including software), providing an in- process data look-up (p. 32 of s. 5.2.4; p. 35 of s. 5.3.2) to the runtime service.
Allowable Subject Matter
Claim 11 would be allowable if rewritten to (1) overcome the rejection under 35 U.S.C. § 112(b) set forth in this Office action; and (2) include all of the limitations of the base claim and any intervening claims.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicants are reminded of the extension of time policy as set forth in 37 C.F.R. § 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 extension fee pursuant to § 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 DAVID P. ZARKA whose telephone number is (703) 756-5746. The Examiner can normally be reached Monday–Friday from 9:30AM–6PM ET.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Vivek Srivastava, can be reached at (571) 272-7304. 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://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, Applicants are encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
/DAVID P ZARKA/PATENT EXAMINER, Art Unit 2449
Prosecution Insights