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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/23/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 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.
Claims 1, 3-4, 8, 11, 13-14, 17-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Beadle et al. (US 12,218,817), hereinafter Beadle.
As for claim 1, Beadle teaches a backend server comprising (Fig. 2, SCADA Server 202; col. 5, lines 44-47 describe a central server of SCADA system):
a processing device (col. 8, lines 40-44 describe a processor); and
memory configured to store computing logic that includes instructions which, when executed (col. 8, lines 40-44 describe storage media that stored program instructions that are executed by one or more processors to perform operations), causes the processing device to perform steps of:
enabling publication-subscription (pub-sub) communication with multiple end point devices using the Message Queuing Telemetry Transport (MQTT) protocol (col. 3, lines 25-43 describe MQTT message protocol is used to define how data is sent and received. MQTT is bi-directional, publish/subscribe message protocol. Devices, sensors at the edge of a network can use Sparkplug to communicate with applications, these communication go through an MQTT broker server),
formatting MQTT messages directed to the multiple end point devices using the Sparkplug specification (col. 6, lines 11-16 describe in accordance with the Sparkplug protocol, SCADA server corresponds to a data collection and control host and remote terminal unit (RTU) corresponds to edge of network (EON) node. The SCADA server executes a host application responsible for supervision, monitoring, and control of the MQTT EON nodes and their respective devices, sensors, etc.; col. 6, lines 22-24 describe the SCADA server serves as a host node for receiving data from devices and sending control information to devices; col. 6, lines 65 and col. 7, lines 1-2 describe in response to receiving the initial payload from the RTU, the SCADA server generates a subsequent payload in the form of a CMD message compliant with the Sparkplug protocol for the RTU), and
allowing publication of a single broadcast message targeting a subset of the multiple end point devices, thereby extending the Sparkplug specification (col. 6, lines 22-24 describe the SCADA server sends control information to the devices; col. 7, lines 53-60 describe the disclosure provide functionality by extending properties of the Sparkplug payload to send metric configuration properties from the SCADA server to the RTUs (i.e. devices)).
As for claim 3, Beadle teaches wherein the pub-sub communication remains backward compatible with MQTT and Sparkplug policies (col. 5, lines 44-55 describe the central server SCADA communicates with the devices via an MQTT broker, or server. The devices provide data, process variables, and metrics. The MQTT broker is the central data distribution component of the system and establishes communication between the SCADA server and each RTU. In a Sparkplug MQTT network, communication between nodes is via the central MQTT broker such that there is no direct link between end nodes and the primary application).
As for claim 4, Beadle teaches wherein the single broadcast message is configured as either a command or data categorically targeting the subset (col. 6, lines 22-24 describe the SCADA server serves as a host node for receiving data from the devices and sending control information to the devices).
As for claim 8, Beadle fails to teach wherein the pub-sub communication with the multiple end point devices includes communication via a first layer of edge node devices and/or a second layer of enterprise group devices interposed between the backend server and the multiple end point devices (col. 6, lines 11-16 describe in accordance with the Sparkplug protocol, the SCADA server corresponds to a data collection and control host and the RTU corresponds to an edge of network node (EON); col. 6, lines 22-24 describe the SCADA server serves as a host node for receiving data from devices and sending control information to the devices (i.e. the RTUs)).
As for claim 11, Beadle teaches a method comprising steps of:
enabling publication-subscription (pub-sub) communication with multiple end point devices using the Message Queuing Telemetry Transport (MQTT) protocol (col. 3, lines 25-43 describe MQTT message protocol is used to define how data is sent and received. MQTT is bi-directional, publish/subscribe message protocol. Devices, sensors at the edge of a network can use Sparkplug to communicate with applications, these communication go through an MQTT broker server),
formatting MQTT messages directed to the multiple end point devices using the Sparkplug specification (col. 6, lines 11-16 describe in accordance with the Sparkplug protocol, SCADA server corresponds to a data collection and control host and remote terminal unit (RTU) corresponds to edge of network (EON) node. The SCADA server executes a host application responsible for supervision, monitoring, and control of the MQTT EON nodes and their respective devices, sensors, etc.; col. 6, lines 22-24 describe the SCADA server serves as a host node for receiving data from devices and sending control information to devices; col. 6, lines 65 and col. 7, lines 1-2 describe in response to receiving the initial payload from the RTU, the SCADA server generates a subsequent payload in the form of a CMD message compliant with the Sparkplug protocol for the RTU), and
allowing the backend server to publish a single broadcast message targeting a subset of the multiple end point devices, thereby extending the Sparkplug specification (col. 6, lines 22-24 describe the SCADA server sends control information to the devices; col. 7, lines 53-60 describe the disclosure provide functionality by extending properties of the Sparkplug payload to send metric configuration properties from the SCADA server to the RTUs (i.e. devices)).
As for claim 13, Beadle teaches wherein the distributed system remains backward compatible with MQTT and Sparkplug policies (col. 5, lines 44-55 describe the central server SCADA communicates with the devices via an MQTT broker, or server. The devices provide data, process variables, and metrics. The MQTT broker is the central data distribution component of the system and establishes communication between the SCADA server and each RTU. In a Sparkplug MQTT network, communication between nodes is via the central MQTT broker such that there is no direct link between end nodes and the primary application).
As for claim 14, Beadle teaches wherein the single broadcast message is configured as either a command or data categorically targeting the subset (col. 6, lines 22-24 describe the SCADA server serves as a host node for receiving data from the devices and sending control information to the devices).
As for claim 17, Beadle teaches wherein the pub-sub communication includes a step of transporting messages via a first layer of edge node devices and/or a second layer of enterprise group devices interposed within the distributed system between the backend server and the multiple end point devices (col. 6, lines 11-16 describe in accordance with the Sparkplug protocol, the SCADA server corresponds to a data collection and control host and the RTU corresponds to an edge of network node (EON); col. 6, lines 22-24 describe the SCADA server serves as a host node for receiving data from devices and sending control information to the devices (i.e. the RTUs)).
As for claim 18, the claim list all the same limitations of method claim 11 but in a non-transitory computer-readable medium including a device trust program having logic instructions that enable one or more processing devices to perform operations (Beadle: col. 8, lines 40-44 describes non-transitory storage media that store instructions executed by one or more processors). Therefore, the supporting rational of the rejection to claim 11 applies equally as well to claim 18.
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.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Beadle (US 12,218,817), in view of Hoque et al. (US 2026/0051246), hereinafter Hoque.
As for claim 2, Beadle teaches wherein the multiple end point devices include a) Internet of Things (loT) devices, b) Industrial loT (lloT) devices, and/or d) embedded devices having local agents with low-capacity processing functionality (col. 7, lines 36-41 describe the RTUs are smart devices includes any remote industrial or resource monitoring; col. 7, lines 45-52 describe the functionality of the RTU require remote configurability).
Beadle fails to teach wherein multiple endpoint devices include resource- constrained devices.
Hoque discloses
wherein multiple endpoint devices include resource- constrained devices (paragraphs [0040] and [0077] describe a system includes signal controllers, edge devices and others. The MQTT broker can be deployed on resource-constrained devices to perform data processing and distribution at the edge of the network).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Hoque for implementing resource-constrained in a system. The teachings of Hoque, when implemented in the Beadle system, will allow one of ordinary skill in the art to collect data from the resource-constrained devices. One of ordinary skill in the art would be motivated to utilize the teachings of Hoque in the Beadle system in order to perform processing of data received from resource-constrained devices.
As for claim 12, Beadle teaches wherein the multiple end point devices include a) Internet of Things (loT) devices, b) Industrial loT (lloT) devices, and/or d) embedded devices having local agents with low-capacity processing functionality (col. 7, lines 36-41 describe the RTUs are smart devices includes any remote industrial or resource monitoring; col. 7, lines 45-52 describe the functionality of the RTU require remote configurability).
Beadle fails to teach
wherein multiple endpoint devices include resource- constrained devices.
Hoque discloses
wherein multiple endpoint devices include resource- constrained devices (paragraphs [0040] and [0077] describe a system includes signal controllers, edge devices and others. The MQTT broker can be deployed on resource-constrained devices to perform data processing and distribution at the edge of the network).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Hoque for implementing resource-constrained in a system. The teachings of Hoque, when implemented in the Beadle system, will allow one of ordinary skill in the art to collect data from the resource-constrained devices. One of ordinary skill in the art would be motivated to utilize the teachings of Hoque in the Beadle system in order to perform processing of data received from resource-constrained devices.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Beadle (US 12,218,817), in view of Gochenaur et al. (US 11,811,884) hereinafter Gochenaur.
As for claim 6, Beadle fails to teach wherein each end point device of the subset includes a common identifier for essentially creating a subscription to a specific topic associated with the subset.
Gochenaur discloses
wherein each end point device of the subset includes a common identifier for essentially creating a subscription to a specific topic associated with the subset (col. 7, lines 43-49 describe an API call causes a set of subscriptions, authorized for at least one of the client nodes, to be communicated to the subscription provisioning database. The set of subscriptions is communicated in a data packet also containing one or more client IDs associated with at least one of the client nodes; col. 9, lines 8-16 describe client nodes can be authenticated for the same set of subscriptions using a single client ID. For example, an API call is made, where the principal parameter specifies a client ID that is common to a plurality of client nodes, can cause the plurality of client nodes to be authenticated for a common set of topic subscriptions).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Gochenaur for using a single client ID that represents multiple client nodes for a topic subscription. The teachings of Gochenaur, when implemented in the Beadle system, will allow one of ordinary skill in the art to receive topics that client devices subscribe to receive. One of ordinary skill in the art would be motivated to utilize the teachings of Gochenaur in the Beadle system in order to reduce network bandwidth usage and compute resources for processing many subscription request messages come from a plurality of client nodes.
As for claim 16 issuing a common identifier to each end point device of the subset for essentially creating a subscription to a specific topic associated with the subset.
Gochenaur discloses
wherein issuing a common identifier to each end point device of the subset for essentially creating a subscription to a specific topic associated with the subset (col. 7, lines 43-49 describe an API call causes a set of subscriptions, authorized for at least one of the client nodes, to be communicated to the subscription provisioning database. The set of subscriptions is communicated in a data packet also containing one or more client IDs associated with at least one of the client nodes; col. 9, lines 8-16 describe client nodes can be authenticated for the same set of subscriptions using a single client ID. For example, an API call is made, where the principal parameter specifies a client ID that is common to a plurality of client nodes, can cause the plurality of client nodes to be authenticated for a common set of topic subscriptions).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Gochenaur for using a single client ID that represents multiple client nodes for a topic subscription. The teachings of Gochenaur, when implemented in the Beadle system, will allow one of ordinary skill in the art to receive topics that client devices subscribe to receive. One of ordinary skill in the art would be motivated to utilize the teachings of Gochenaur in the Beadle system in order to reduce network bandwidth usage and compute resources for processing many subscription request messages come from a plurality of client nodes.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Beadle (US 12,218,817), in view of Blonskey et al. (US 2021/0288412), hereinafter Blonskey.
As for claim 7, Beadly fails to teach wherein publishing a single broadcast message promotes synchronization among a subset of multiple end point devices.
Blonskey discloses
wherein publishing a single broadcast message promotes synchronization among a subset of multiple end point devices (paragraphs [0006]-[0007] describe a master is configured to connect to multiples slave devices which are actuators, sensors and the like. The master downlink is a broadcast message (i.e., one message sent to all devices) while the multiple devices and components use a synchronous TDM method for uplink).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Blonskey for broadcasting one message to multiple devices. The teachings of Blonskey, when implemented in the Beadle system, will allow one of ordinary skill in the art to reduce computer resources in data transmission. One of ordinary skill in the art would be motivated to utilize the teachings of Blonskey in the Beadle system in order to enable the master device controlling of slave devices that have relationship with the master device.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Beadle (US 12,218,817), in view of Ansari et al. (US 2008/0189774), hereinafter Ansari.
As for claim 9, Beadle teaches wherein the single broadcast message is configured to a) notify the subset of a change in the backend server, b) provide new or updated policies for the subset (col. 7, lines 16-25 describe the subsequent payload communicated from the SCADA server to device include a plurality of metrics. The RTU parameters include alarm thresholds, alarm priorities, alarm delay settings, data logging frequencies, alarm priorities, alarm delay settings, data logging frequencies, data source communications settings and/or properties relating to the RTU itself such as communications and security parameters), c) update configuration settings for the subset (col. 6, lines 63 and col. 7, lines 1-15 describe the SCADA server sends a subsequent payload that contains specific metric names, data, and PropertySet items for RTU information. The Sparkplug B protocol payloads are exploited to add configuration properties for the RTU. In addition, custom metrics can be added to the set to allow other/all RTU properties to be set. The RTU presents custom metrics to publish configuration version information, allowing the SCADA server to detects changes made locally), and/or d) change, renew, revoke, and/or update digital certificates for the subset.
Beadle fails to teach wherein the single broadcast message is configured to notify the subset of a change in the backend server, and/or change, renew, revoke, and/or update digital certificates for the subset.
Ansari discloses
wherein a single broadcast message is configured to notify the subset of a change in the backend server (paragraph [0127] describes a service configuration manager notifies a publisher/subscriber (Pub/Sub) server of a configuration update. The Pub/Sub serve determines which gateway devices have the early version of the configuration information and sends a notification containing the new configuration version to the gateway devices’ service manager transiting the presence and networking infrastructure. If the gateway has a previous version of configuration information, the service manager of the gateway device updates the version of the configuration information on the gateway device), and/or change, renew, revoke, and/or update digital certificates for the subset .
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Ansari for providing configuration updates. The teachings of Ansari, when implemented in the Beadle system, will allow one of ordinary skill in the art to simplify the delivery of services and applications. One of ordinary skill in the art would be motivated to utilize the teachings of Ansari in the Beadle system in order to provide a system to simplify the delivery of services and applications, reduce the complexity of maintenance, upgrading, and operation of digital endpoint devices.
As for claim 19, the claim list all the same limitations of method claim 9 but in a non-transitory computer-readable medium including a device trust program having logic instructions that enable one or more processing devices to perform operations (Beadle: col. 8, lines 40-44 describes non-transitory storage media that store instructions executed by one or more processors). Therefore, the supporting rational of the rejection to claim 9 applies equally as well to claim 19.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Beadle (US 12,218,817), in view of Dixon et al. (US 2024/0019852), hereinafter Dixon.
As for claim 10, Beadle teaches wherein extending the Sparkplug specification is configured to achieve benefits (col. 7, lines 53-60 describe the properties of a Sparkplug payload is extended to send metric configuration properties from the SCADA server to a device using properties of Sparkplug. Extending properties permits recording and updating configuration versioning and other change-related information using specific metrics).
Beadle fails to teach wherein benefits include
a) reduce network traffic and latency in a distributed system including the backend server and multiple end point devices, b) simplify communication with the multiple end point devices by reducing redundant actions, and/or c) eliminate a need to specifically identify each of the multiple end point devices in the subset.
Dixon discloses
wherein benefits include
a) reduce network traffic and latency in a distributed system including the backend server and multiple end point devices (paragraphs [0022] and [0036] describe the placement of MEC within an access network permits data exchanges between the multi access edge computing system (MEC) and intermediary device as plant data acquisition and control device (PDAC). The devices within the MEC is sufficiently powerful enough to offload services that traditionally were implemented by a cloud computer resources (CCR), and thus execute the offloaded services with reduce latency. MEC also allows the reduction of traffic congestion with an access network), b) simplify communication with the multiple end point devices by reducing redundant actions (paragraph [0036] describes MEC allows a reduction in the amount of traffic in an access network), and/or c) eliminate a need to specifically identify each of the multiple end point devices in the subset.
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Dixon implementing a network infrastructure comprising edge devices. The teachings of Dixon, when implemented in the Beadle system, will allow one of ordinary skill in the art to reduce latency when exchange commands/data with intermediary devices. One of ordinary skill in the art would be motivated to utilize the teachings of Dixon in the Beadle system in order to distribute automation tasks across plant devices, edge devices, and cloud resources while keeping them synchronized.
As for claim 20, the claim list all the same limitations of method claim 10 but in a non-transitory computer-readable medium including a device trust program having logic instructions that enable one or more processing devices to perform operations (Beadle: col. 8, lines 40-44 describes non-transitory storage media that store instructions executed by one or more processors). Therefore, the supporting rational of the rejection to claim 10 applies equally as well to claim 20.
Allowable Subject Matter
Claims 5 and 15 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: prior art fails to teach all the limitations recited in claims 5 and 15.
As for claim 5, the claim recites the limitations “The backend server of claim 4, wherein the single broadcast message is formatted in the Sparkplug specification as "<namespace>/<groupid>/GCMD/<subset id>" for publishing a command or "<namespace>/<groupid>/GDATA/<subset id>" for publishing data, where: <namespace> is "spAv1.0" or "spBv1.0," <groupid> represents a customer group, a tenant group, an enterprise group, or an organization group, and<subsetid> represents the subset of the multiple end point devices within the customer group, tenant group, enterprise group, or organization group.”
As claim 15, the claim recites the limitations “The method of claim 14, wherein the single broadcast message is formatted in the Sparkplug specification as "//GCMD/" for publishing a command or "//GDATA/" for publishing data, where is "spAv1.0" or "spBv1.0," represents a customer group, a tenant group, an enterprise group, or an organization group, and represents the subset of the multiple end point devices.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Namburi et al. (US 2024/0111263) teach systems and methods for optimization and autoconfiguration of edge processing devices
Wellig et al. (US 2022/0021667) teach building management system architecture
Johnson et al. (US 11,121,930) teach sparkplug-aware MQTT server.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to L. T N. whose telephone number is (571)272-1013. The examiner can normally be reached M & Th 5:30 am - 2:30 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, TONIA DOLLINGER can be reached at 571-272-4170. 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.
/L. T. N/
Examiner, Art Unit 2459
/TONIA L DOLLINGER/Supervisory Patent Examiner, Art Unit 2459