DETAILED ACTION
This action is responsive to the Applicant’s response filed 4/29/26.
As indicated in Applicant’s response, claim 12 has been amended, claims 2, 7, 11 cancelled and claims 20-21 added. Claims 1, 3-6, 8-10, 12-21 are herein pending a next office action.
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 1, 3-6, 8-10, 13-19 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Suenbuel et al, USPubN: 2006/0142978 (herein Suenbuel) in view of Ketireddy et al, USPN: 10/860,295(herein KtReddy), Chandhoke et al, USPubN: 2002/0186245 (herein Chandhoke), and
Manglik et al, USPN: 12,499,599 (herein Manglik) further in view of Ning et al, USPubN:
2022/0043476 (herein Ning) and Sheng et al, USPubN: 2023/0012240 (herein Sheng)
As per claim 1, Suenbuel discloses a computer-implemented method for modifying a signal processing chain (see claims 5-6, pg. 5; claim 15, pg. 5) that is implemented in a block diagram via components (see network 104 - Fig. 1a) connected by signal lines (sensor nodes interconnected by wireless communication links - para 0018),
the block diagram including at least one signal source and at least two components that are
connected directly or by interposed components (network 104, sensor nodes - para 0018; Fig la) to at least one of the signal sources, the method comprising:
reading the block diagram into a development environment (Fig. la; environment 204 – para 0031; sensor network physical environment model provides graphical sensor constraint model - para 0033-0034; para 0036);
selecting a mode (user 114 selects one or more sensor network factors, cost, maximum control - para 0036) from at least two existing modes (automated process - para 0011; automatic
code generator - para 0037; pre-deployment, post-deployment - para 0030; provides a graphical user
interface through which the user selects one or more factors tool takes as input the requirement,
sensor constraint and domain specific model - para 0036 - Note1: a) GUI by which requirement
factors are inputted by user interaction/selection to build a sensor model reads on interactive mode;
b) code automation in which code is automatically generated reads on automated mode without user intervention; and c) post-deployment context to make use of distributed executable to client devices - para 0030 - reads on a distributed provision to common users in exercising of a ready-code deployment mode),
wherein
the signal processing takes place on a first hardware platform (enterprise server 106
- para 0018; para 0022-0023) or a host PC (para 0025), in a first mode (see Note1 for a) mode or user interactive mode having user-specified factors, inputs within a modeling tool – Fig. 2; para 0031) and
the signal processing takes place on a second hardware platform (see physical space – para 0033) in a second mode (post deployment mode - para 0030; physical space in which the sensor
network is to be deployed - para 0033), wherein the first hardware platform and the second hardware platform are designed differently (see enterprise server - para 0022-0023; physical environment of
storage facility, building construction, climate control system - para 0033)
Suenbuel does not explicitly disclose
(i) second mode is when the signal processing takes place on a Rapid Control Prototyping
system, comprising
(ii) removing or replacing at least a first component from the block diagram if the second mode was chosen; and removing at least one additional component if the first component was removed and the additional component was connected solely to an input of the first component on the output side.
As for (i)
Suenbuel discloses construction of sensor control software using a analytic platform that
receives requirements or specifications on physical environment constraints (model 204 - Fig. 2),
domain data (para 0026) and sensor constraints (para 0031) as pre-build information as well as
user-specified factors (para 0008) constitute a user-based assembling of software that achieves
code from taking input according to a GUI or interactive mode, including scenario wherein the
generated code is being dispatched to a domain specific location (claim 8, pg. 5) or environments
(para 0033) in which the generated code is to be deployed.
Hence, improving a sensor functionality from activities in a framework as in Suenbuel that
manipulates internal state of a visual diagram or sensor node via requirement check (para 0031-0032) as part of a prompt delivery of domain specific code is recognized
Chandhoke discloses a graphical programming environment for creating user-modified
version of program (para 0018) for use of a prototyping environment (Fig. 8-10; para 0091) which
support image acquisition of a image sensing system of a smart camera (Fig. 3A; para 0115), the
program being configurable via the graphical environment as programmable prototype (Fig. 2) such
that as deployed, the user modified version or prototype version thereof can be transferred to a real-
time operating system or memory of a hardware device that operates under that operating system
(para 0089, 0109) as part of prototype replacement (without requiring user programming - see para
0013) to improve image acquisition devices in computer vision or image vision acquisition
methodology (para 0110); hence effect of using prototype to simulate user modified program on a
Rapid Control Prototyping system in order to replace a sensor software per a UI framework geared
for simulating and replacing a SW component of a modeled sensor entity in order to affirm whether
a deployment prototype can be deemed ready as a replacement version for delivery to its real-world
environment or image acquisition device entails replacing at least a first component from the block
diagram to be processed using a RCP system if a second mode was chosen, the second mode being a deployment achieved via prototyping.
As for (ii)
Manglik discloses a ML-based updater of a animation graph in terms of adding more nodes
to increase the number of transactional input/output (Fig. 4F) and removing non-transactional nodes
or edges deemed unconnected, idle or least frequently used as part a management process of
pruning/replacing by the ML sub-system (col. 15 li. 14-52); i.e. removing one or more nodes
identified as unrelated to flow of the animation, least frequently used, or unconnected to the graph
story(col. 21 li. 47-59); hence removing an edges and respective node deemed unconnected or
unrelated to the sequence flow of a graph scenario is recognized.
KtReddy discloses evaluation of design diagrams with rule engines (Fig. 2) and policy-based
autocorrections (col. 3 li. 32-62; Fig. 5-8) without user acceptance input to address/resolve
connectivity (or ambiguity thereof) of edge endpoints, with automatic removal of an unconnected
endpoint (col. 3 li. 19-28) if no component in the vicinity is found as connected therewith (col. 7 li.
6-12). Hence, automatic removal of endpoint when the endpoint is not found as connected to any
component in the vicinity entails improvement to the quality of a graph design with autocorrection
that removes an endpoint observed as not being connected to component in the next vicinity.
Therefore, based on Manglik and KtReddy, diagram design performing connectivity analysis
in a context subsequent to a first component being removed, for identifying additional components
in the immediate vicinity of the removed component, so to find that a component whose endpoint is
no longer connected to the first component thereby effectuating a auto removal of the unconnected
component is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to manipulate component of a design in Suenbuel diagram framework so
that
1) quick replacement of specific code component is provided with action processing using a
replacement approach/mode like that of a Rapid Control Prototyping system, as shown in
Chandhoke;
2) with addition or replacement of a given first component from the block diagram enabled
with prototyping approach set forth above Rapid Control prototyping (RCP) mode being chosen;
3) including prompt and automated removal of at least one additional component - as in
KtReddy design auto-correction approach - if the first component was removed when said additional component - as in KtReddy analysis - in the immediate vicinity was initially connected solely to an input of the first component, with an endpoint on the output side of this additional component; i.e. the removal based on identifying that the additional component output endpoint has no connection - as per KtReddy - to any of the components in the vicinity; because
capability by a design and testing tool so that prototyping is afforded with verification of
components under the design per a designer option and that would enable prompt replacement of
candidate code or components in the endeavor of finding the best alternate candidates associated
with the design testing would reduce time and effort otherwise required for the designers or
developers to generate each time one or more new components from scratch prior to be able to
configure them for testing and verifying conformance of their results with the design;
and capability to add and remove components under this prompt prototype or component
replacement approach would enhance expansion of the software functionality in accordance with the designer intents in the course of the graphical design and modeling, and
autocorrection of the graphical design in adding or removing as set forth above using this
rapid control/replacement framework, would also optimize payload and storage resources associated
with the functional design in that component analyzed as not connected via a output endpoints to any other component in the immediate vicinity would be pruned out or removed from the graphical
diagram - as set forth above; so that resources spared from the efficient use of this automatic removal can be directed to the rest of the design, in that only components deemed of significance
with respect to the flow and purpose of the design can be identified and sought out in order to have
them connected and tested according to that flow and purpose.
Nor does Suenbuel explicitly disclose
wherein the block diagram is read and executed in a runtime environment of the development environment that provides the sensor data with time stamps and forwards the sensor data in a time-synchronized manner.
Ning discloses signal processing of a sensor data acquisition system based on displayed
timeline (para 0020, 0039) associated with transmission of data passing through hubs and processing
of results from the monitoring to provide alert and analytical observation (para 0035-0040), using
time synchronization (Fig. 1-2) synthetizing/conversion of the heterogenous sensor data with clock
synchronization circuit (para 0028) to realize synchronous data acquisition (para 0008-0009) or time
synchronous hybrid signal processing and control for analog and digital sensor data from multiple
hubs into the acquisition system (para 0015-0018), whereby strict dependence on the network is
reduced, and large amount of sensor data can be continuously acquired SO to yield effect of
reliability, stability and universality to their transmission (para 0022).
Sheng discloses sensors data arranged per a data acquisition device with added timestamps
in real-time for the data acquisition device to perform time synchronization to the obtained data and
data ranging (para 0048) using a measurement unit connected to a camera unit, a micro control unit
to provide power management to components of the data acquisition unit for acceleration and
velocity computation (Fig. 3-4) for use in 3-D scene modeling (para 0050, 0060, 0067) Hence,
sensors data acquisition arranged in time synchronization stream attached with timestamps into a
control unit of the data acquisition stage by which to calculate velocity and acceleration of uploaded image cloud points for use in modeling a 3D scene is recognized.
Based on information provided as sensors data to implement various applications, different
domains of industrial processes, business network with integration by way of modeling tool or
sensor constraint models in Suenbuel (para 0026-0031), the processing of real-time and disparate
sensor data into a more synchronized form is recognized.
Thus, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement block graphical design and modeling in Suenbuel so that
acquisition of sensor data captured in real-time from different sources would be using a data
acquisition stage equipped with time-synchronization capability by which sensor data captured in
real-time with timestamps can be processed/forwarded for conversion to a time-synchronized
propagation as part of acquisition stage as in Ning, to enhance reliability, stability and universality of the acquired data in association with their transmission; or as shown in Sheng timestamp-added
time-synchronization of this data in supporting a scene modeling; because
data or image information stream received and read, processed in a runtime environment of
the development environment when arriving from sensors situated from disparate sources can
encompass large discrepancies in time line, analog versus digital format distinction and
asynchronous type differentials, and by providing a acquisition layer equipped with timestamp
extraction, analog/digital format standardization enabling transfer of the sensor data in a time
synchronized manner, the complexity inherent to sensor data caused by disparaging time of arrival,
diversity in sources and format of the data type can be minimized with a retransformation step by an acquisition circuitry as set forth above that facilitates information processing of this sensor data in accordance to more time synchronized manner, which in turn would facilitate signal, data or image extraction and processing thereof into one or more stages of development environments such as in graphical model UI as in Sheng, in that the retransformation and time synchronization of raw sensor data would be it more easily interpretable without intervention of a user, and accordingly extracted for selection into a desired configuration of a model, and ultimately compiled as model executable software or deployed workflow application.
As per claim 3, Suenbuel discloses method according to claim 1, wherein the selection of a mode takes place automatically (model to be generated via an automated process automatic code
generator sensor node is reprogrammable on-the-fly due to internal factors associated with sensor node outages or physical environment (e.g. climate control failure - para 0011) on the basis of a hardware platform that executes the runtime environment of the development environment (Note2: automated process of generating code on-the-fly in light of dire events or disruption of service reads on selecting automatically a sensor code generating mode in response to, or on basis of real-world platform runtime incurring a situation or condition).
As per claim 4, Suenbuel discloses method according to claim 1, wherein
a third mode is selected through the development environment, wherein the third mode (refer to a prototyping mode per rationale A(i) using Chandhoke; e.g. para 0013) includes an execution on a third hardware platform (see prototyping environment in Chandhoke), in particular a production control unit, and wherein a generation of source code (see Chandhoke: convert, compile, transfer to FPGA - Fig. 34) from the block diagram additionally takes place in the third mode.
As per claim 5, Suenbuel discloses method according to claim 1, further comprising reading a configuration file that includes at least one mapping of a component of the block diagram onto another component (see mapping per Note3 from below; domain-specific model 208 can be prebuilt in a single file - para 0031; document 202, objectives are to be satisfied by deploying sensor network, sensor network shall ensure that company personnel are alerted when a dangerous situation is detected - para 0032) or a mapping onto an empty component or includes a removal of the component, and wherein the at least one mapping is specific for one mode (Note3: configuration file that establishes relationship/requisites between a domain-specific functionality - company security alert, storage facility - and a sensor network being a source signal to be matched with a specific function that monitors storage facility or dangerous company situation reads on file establishing mapping between a first signal source and a control software that operates with real-world sensor to monitor alerting situations - outages - para 0038 - or 1/0 of a storage facility - see para 0035 - in accordance to a domain-specific matching mode).
As per claim 6, Suenbuel does not explicitly disclose method according to claim 1, wherein the development environment includes the runtime environment that is equipped to provide signal data received through a signal source with at least one time stamp, and
wherein the components and/or the runtime environment are equipped to process signal
data in a synchronized manner.
But processing of sensor data to make this disparate stream to be time synchronized using a
acquisition circuitry that process the sensor data based on their corresponding timestamps to
reconvert the data into a data bearing time synchronization state is shown in Sheng and Ning, per the rationale B executed in claim 1.
Hence providing a development environment with a runtime configuration equipped to
provide signal data received through a signal source with at least one time stamp, wherein the
components and/or the runtime environment are equipped to process signal data in a synchronized
manner would be deemed equally obvious for the same reason set forth with use of Sheng in the
rationale B of claim 1.
As per claim 8, Suenbuel discloses a method for configuring a control unit, the control unit comprising at least one computing unit (see para 0009; para 0020; para 0040; processor - claim 18 pg. 6; execution with the sensor node - claim 19, pg. 6) and at least one sensor (para 0003-0008; para 0018; para 0026) and/or at least one actuator in order to sense data of a physical process (manufacturing company - para 0026-0027) and/or to influence the process, the method comprising:
generating source code (refer to claim 4) according to the method of claim 4;
compiling the source code for the computing unit (para 0037; generator 152 Fig. le; generator 152 - Fig. 2) so that executable code is generated;
transmitting the executable code to the control unit (loaded into memory prior to deployment
para 0020; para 0037); and
storing the executable code on a non-volatile memory (para 0020; para 0011) of the control unit and/or executing the executable code(para 0020; code suitable for execution on a sensor node - claim 19, pg. 6) by the computing unit of the control unit.
As per claim 9, Suenbuel discloses a computer program product with a non-transitory, computer-readable storage medium (para 0042) on which instructions are embedded that, when they are executed by a processor, cause the processor (para 0040; processor - claim 18 pg. 6) to carry out the method according to claim 1.
As per claim 10, Suenbuel discloses a computer system comprising a human-machine interface (claim 17, pg. 6; para 0008; user interface - para 0018), a non- volatile memory, and a
processor (para 0041-0042),wherein the processor is equipped to carry out the method according to
claim 1.
As per claim 13, Suenbuel discloses method according to claim 1, wherein the host PC is configured to be operated directly (network model to be generated via a automated process, by an
automatic code generator, loaded into the memory of a corresponding sensor node sensor node is
reprogrammable on-the-fly thus allowing changes to be made - para 0011) and manually by a user (a user 114 may interact with the sensor network issuing commands or reprogram individual sensor nodes - para 0018).
As per claim 14, Suenbuel discloses method according to claim 1, wherein the block diagram specifies interconnection (sensor readings are then passed from sensor node to sensor node on a multi-hop route to convey information within the sensor network 104 - para 0021) of the at least two components with existing sensors (network 104 interconnected by wireless links
represented by double dash lines - para 0018).
As per claim 15, Suenbuel discloses method according to claim 1, wherein a signal processing chain (application domains monitoring, maintenance, chain management, asset tracking targets a single application domain and is tailored to the domain's needs - para 0026) is independent of an implementation of individual components (deployed in the storage facility, server code generator 152 that translate into items of executable code each item associated with a particular sensor node 102 in the network - para 0037 - Note4: specific domain needs application for monitoring, maintenance, chain management, asset tracking reads on domain application being independent from server-based automatic generation of executable for individual sensor nodes made available in storage utility).
As per claims 16-17, Suenbuel discloses method according to claim 1, wherein the block diagram is executed in the runtime environment configured to provide sensor data with time stamps; wherein the sensor data is forwarded in a time-synchronized manner
(Refer to rationale B of claim 1)
As per claim 18, Suenbuel discloses a computer-implemented method for modifying a signal
processing chain (refer to claim 1) that is implemented in a block diagram(refer to claim 1) via components connected by signal lines, the block diagram including (refer to claim 1)at least one signal source and at least two components that are connected directly or by interposed components to at least one of the signal sources,
the method comprising:
reading the block diagram into a development environment (refer to claim 1);
selecting a mode from at least two existing modes, wherein the signal processing takes
place on a first hardware platform or a host PC, in a first mode(refer to claim 1) and the signal processing takes place on a second hardware platform(refer to claim 1) or a Rapid Control Prototyping (RCP) system (refer to rationale A(i) of claim 1), in a second mode, wherein the first hardware platform and the second hardware platform are designed differently(refer to claim 1);
removing or replacing at least a first component from the block diagram if the second mode
was chosen (refer to rationale A(i) of claim 1); and
removing at least one additional component if the first component was removed and the
additional component was connected solely to (refer to rationale A(ii) of claim 1) an input of the first component on the output side.
Suenbuel does not explicitly disclose
wherein the selection of a mode takes place automatically on the basis of a hardware
platform that executes a runtime environment of the development environment.
However, adapting of processing mode in Suenbuel system can be seen via first, using GUI
by which requirement factors are inputted by user interaction/selection to build a sensor model in
that the adaptive aspect of the build is driven by user interactive input; second, via an automation
mode in which code is automatically generated (para 0037) without user intervention; and third, per
a post-deployment mode that adapts the readily made software for a given context of client devices
or common users ( para 0030) in terms of a processing mode that is not driven by manual intervention.
As for a automatic mode of manipulating diagrams, the machine learning platform in Manglik operates with a ML-based updater associated with an animation graph in terms of adding more nodes to increase the number of transactional input/output (Fig. 4F) and removing non-transactional nodes or edges deemed unconnected, idle or least frequently used as part a management process of pruning/replacing by the ML sub-system (col. 15 li. 14-52); i.e. removing one or more nodes identified as unrelated to flow of the animation, least frequently used, or unconnected to the graph story(col. 21 li. 47-59); where use of a management platform to support a particular diagram editing mode with intelligent adding or removing nodes of a animation model driven by automated analytics from a ML adapter entails selection of a mode automatically set on basis of on the hardware platform that executes a runtime environment, e.g. for animation nodes development, editing.
Therefore, based on possible adaptation of processing mode in Suenbuel, it would have been obvious before the effective filing date of the invention for one skill in the art to implement the signal processing and UI support in Suenbuel SO that selection of a mode takes place automatically on the basis of a hardware platform that executes a runtime environment of the development environment - as in the ML platform of Manglik - where the selected mode implement intelligent editing (automatic add/remove) of nodes set with the development runtime using this intelligent adapter mode; because
prompt and adaptive UI mode selection based on a platform integrated with capability for
automating manipulation and editing of components of a graphical design (under UI development)
as set forth above, would obviate implication of user input in the course of implementing node manipulation or editing underlying the UI stage of a graphical modeling or build, notably when a
machine learning engine - as set forth above - is integrated with the platform in which graphical
nodes configuring and manipulation is taking place, thus benefitting from the automated internal
intelligence of the platform so that proper formation of the graphical design is assured by the
platform (via a integrated ML engine) while obviating interactive type delay caused by constant
reliance to (seeking of) user approval/consent at each granular step of the graphical modeling or
design/animation build paradigm
As per claim 19, Suenbuel discloses computer-implemented method for modifying a signal processing chain that is implemented in a block diagram via components connected by signal lines, the block diagram including at least one signal source and at least two components that are
connected directly or by interposed components to at least one of the signal sources, the method
comprising:
reading the block diagram into a development environment;
selecting a mode from at least two existing modes, wherein the signal processing takes place on a first hardware platform or a host PC, in a first mode and the signal processing takes place on a second hardware platform or a Rapid Control Prototyping (RCP) system, in a second mode, wherein the first hardware platform and the second hardware platform are designed differently; and removing or replacing at least a first component from the block diagram if the second mode was chosen,
wherein the block diagram is read and executed in a runtime environment of the development environment that provides the sensor data with time stamps and forwards the sensor data in a time-synchronized manner.
(all of which having been addressed in claim 1)
Claims 12 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Suenbuel et al, USPubN: 2006/0142978 (herein Suenbuel) in view of Chandhoke et al, USPubN: 2002/0186245 (herein Chandhoke), Ketireddy et al, USPN: 10/860,295(herein KtReddy), and Manglik et al, USPN: 12,499,599 (herein Manglik) further in view of Ning et al, USPubN: 2022/0043476 (herein Ning) and Sheng et al, USPubN: 2023/0012240 (herein Sheng) and further of Shear USPN: 7,630,326 (herein Shear) and Goodman et al, USPubN: 2012/0054707 (herein Goodman)
As per claim 12, Suenbuel does not explicitly disclose method according to claim 1, further comprising:
an iterative removal of components that are no longer required, by checking whether any further component in the block diagram has all of its outputs unconnected as a result of each successive component removal; and repeating the checking until no further component with all outputs unconnected remains in the block diagram.
Manglik discloses a ML-based updater of a animation graph in terms of adding more nodes
to increase the number of transactional input/output (Fig. 4F) and removing non-transactional nodes or edges deemed unconnected, idle or least frequently used as part a management process of
pruning/replacing by the ML sub-system (col. 15 li. 14-52); i.e. removing one or more nodes
identified as unrelated to flow of the animation, least frequently used, or unconnected to the graph
story (col. 21 li. 47-59); hence removing an edge and respective node deemed unconnected, least
used or unrelated to the sequence flow of a graph scenario entails tracking flow of node-to-node relationship and removing of unconnected nodes per a forward checking.
Shear discloses Agile network configuration expressed as sensor mesh network via a
processor interface (interface 506 - Fig. 3-5) in conjunction with operations and messages TX/RX
with a gateway, where setup operations on the mesh network include messaging, and time
synchronization operation; e.g. to maximize lifetime of nodes and throughput from nodes (Fig. 8),
using a process of synchronization maintenance that includes, assessing latest change to a mesh
network, rebuilding lost links and removing links that do not work any longer, and establishing
alternate links as necessary (col. 7 li. 16-29); hence removal of links that are no longer in use entails
removing a link attached node that is no longer necessary or whose output is no longer belong to any flow.
Goodman discloses optimizing of nodes placement - for service processors operating
thermal sensors - see para 0031 - of a cells connectivity hypergraph configured for managing cell
regions (Fig. 2-3) and resolving conflicts among the attached cells, nodes or edges, including
removal of a node that overlaps with a next node (para 0048), or nodes that cause a conflict in
updating the hypergraph by removing a node of greatest conflict and all connected nodes thereto to increase utilization rate by the hypergraph (para 0051); hence removing a node and repetitively remove each node attached to the removed node entails iterative removal of additional components or nodes that are no longer required, via effect of iteratively checking state of unconnected component outputs as result of a removal or slated for removal; and repeating the checking until no further component with all outputs unconnected is found in the block diagram.
Therefore, based on the update made to a design of sensor network graph via a modeling tool (see Suenbuel; Fig. 2; updates from the sensor network- para 0038), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement configurability of a sensor network representation in Suenbuel so that processing of block diagrams in Suenbuel would include assessing state of connectivity among the nodes of the network and continuous upgrade of the topology thereof so to include operations such as removal at least one additional component if an output of the additional component is not reused - as in Shear removal of node that is no longer in use, - or one that is least used as in Manglik; per an iterative mode of removal by checking whether any further component in the block diagram has all of its outputs unconnected as a result of each successive component removal; and repeating – as in Goodman - the checking until no further component with all outputs unconnected remains in the block diagram or should then be removed; because
programming issue caused by runtime pointer referencing as result from dangling effect or
deleted component(s), cell(s) or node(s) during the course of adding, grouping, deleting a node or
element of a graph representation require timely update made programmatically to the underlying
software that supports runtime of graphical editing and interactive design of a structure or diagram
as in the sensor node network by Suenbuel; and capability to follow through each removal of an
element of a topology with identification of dependency elements and removal of the attached
elements in accordance to a iterative process would necessarily avert pointer indirection setback of the runtime software that actually attempt to render the latest state of a graph or node diagrams onto a developer context such as that intended by the sensor node network modeling tool in Suenbuel, as well as recovering unallocated memory space resulting from the in-depth removal cycles which can be redirected for use in expanding the graphical model with additional nodes.
Claims 20-21 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Suenbuel et al, USPubN: 2006/0142978 (herein Suenbuel) in view of Ketireddy et al, USPN: 10/860,295 (herein KtReddy), Chandhoke et al, USPubN: 2002/0186245 (herein Chandhoke), and Manglik et al, USPN: 12,499,599 (herein Manglik) further in view of Ning et al, USPubN: 2022/0043476 (herein Ning), Sheng et al, USPubN: 2023/0012240 (herein Sheng), and further of Bermudez et al, USPubN: 2014/0257699 (herein Bermudez) and Wu et al, CN 109673045, (translation) 01-05-2021, 13 pgs (herein Wu)
As per claims 20-21, Suenbuel does not explicitly disclose method of claim 1,
(i) wherein the runtime environment provides a fixed range of functions for synchronization of signals, and wherein the fixed range of functions is constant across the first hardware platform and the second hardware platform;
(ii) wherein at least one signal source in the block diagram is executed as a playback component, in the first mode, that supplies stored sensor data in place of data from a real sensor, and wherein the block diagram is adapted from the first mode to the second mode by replacing the playback component with a component for controlling a real sensor.
As for (ii)
Raw sensor data from different environmental conditions in Suenbuel are detected, preprocessed, analyzed and filtered then passed on a multi-hop route to enterprise server, in that communicating of the filtered sensor readings rather than transmitting a continuous stream of raw data reduces power to convey such information (para 0021). Hence, effect of playing back of readings at a subsequent server, based on readings transmitted from a first hop or location at which the raw data is preprocessed, analyzed and filtered is recognized, where replacing raw sensor data at an initial hop device effecting a first (filter) mode to supply the filtered data via hops to a second (server) mode is recognized in that raw sensor data after being filtered at hop level (first mode) is conveyed as preprocessed readings to a server platform (second mode) per a hop-to-hop transfer (para 0018).
Hence, sensor network designed as block diagrams block being adapted from the first mode (hop filter mode) to the second mode (server mode) by replacing the playback component with a component (filtering node)– referred herein as (*) - for controlling a real sensor as part of the design is recognized
As for (i)
Bermudez discloses a sensor network where signals are transmitted through different wireless motes, at which the signals are recorded then communicated (each with times tamp) from the motes to central server (step 508 – Fig. 5), where the NW multi-hop communication uses a time synchronization protocol (para 0028) based on which the central server may be able to generate a map illustrating the relative location of the motes as well as time of flight or strength indicator ( para 0028); hence transmitting raw data recorded at a first mode to a second mode using an established hop-to-hop synchronization is recognized.
Wu also discloses a multi-hop distribution intended for a wireless sensor network transmission and monitoring of sensed data according to a cooperative broadcast framework (see Abstract) to monitor and collect according to a preset rule, where each communicated frame is imparted with time clock or time slot or data sub-time slot (pg. 3-4), the sensor network time slot distribution per a multi-hop synchronous transmission presented as a multi-hop transmission mechanism diagram (bottom pg. 4), where broadcast time slot in the synchronization instruction comprises main clock synchronization information, a current multi-hop identification information, the latter including network awake period by the node and transmission from a sub-time slot hop, and the number of maximum hop respective to a current control time slot at a i-th hop node (pg. 6).
Hence, design consideration with diagram depicting hop to hop passing of NW sensor data to be communicated to a broadcast framework having synchronization instruction at each hop node to manage the synchronized hop transfer entails runtime environment provides a fixed range of functions for synchronization of signals, and wherein the fixed range of functions is constant across the first hardware platform (hop device) and the second hardware platform (broadcast framework) is recognized.
Therefore, based on the modeling tool and interactive effect of developer associated with configuring sensing tasks, monitoring, setup alerts, correcting outages and regulation of changes made in deploying sensor data in the network by Suenbuel approach (para 0031-0039), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the modeling tool with capabilities to
(1) develop a runtime environment with a fixed range of functions for synchronization of signals, and wherein the fixed range of functions is constant across the first hardware platform and the second hardware platform, using hop-to-hop synchronization as in Wu and Bermudez;
wherein
(2) a block diagram of hop-to-hop modeling instance is adapted from the first mode (filtering node) to the second mode (server replay mode) by replacing the playback component with a component – a preprocessing hop as per (*) - for controlling a real sensor; where at least one signal source in the block diagram is executed as a playback component - a filtering hop- in the first mode that supplies stored sensor data (filtered readings) in place of data from a raw/real sensor to a second component operating in a second mode; because
configuring sensor data communication in a wireless network where data by design arrives in hop by hop time slot sequence per a synchronous or asynchronous protocol entails judicious pre-arrangement by the designers in establishing delay and untimeliness of packet passing across so many hops so that their arrival at a given destination, the sequence of packets can be somehow recorded and reproduced/remapped according to originating locations, the time slot or sub time slot within a determined sequence from a respective hop source, so that developing runtime for such sensor network in terms of customizing a steady range of synchronization functions available across the hop to hop communication path where sensor data is transmitted to a central destination as set forth above, would enable specific timing information to be relayed and passed from each hop to the next hop, each hop effecting a stage in which data is being reprocessed in converted with proper information for the next transmission, enabling thereby conversion of raw data into filtered reading that in turn can be re-assembled at a destination; the communication and synchronization thereby benefitting from the preprocessing/filtering at each hop with effect of alleviating energy cost by the NW transmission capability, where using a aggregating service mode adapted to operating with one or more playback versions of the sensor data rather than the raw/unfiltered sensor data would also benefit from the preprocessing at hop level which basically reduces the bandwidth required otherwise to transport a corresponding raw data.
Response to Arguments
Applicant's arguments filed 4/29/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) Applicants have submitted that (Applicants Remarks pg. 8) Chandhoke as cited to remedy to deficiencies of Suenbuel as indicated in the rationale A of claim 1, discloses diagrams for a image acquisition system where the prototype replacement thereof does not teach a second mode being RCP and removing a component from the block diagram if the RCP mode is selected. Actually, using prototype to simulate user modified program on a Rapid Control Prototyping system as shown in Chandhoke is provided to enable possibility to replace a sensor software per a UI framework geared for simulating and replacing a SW component of a modeled sensor entity in order to affirm whether a deployment prototype can be deemed ready as a replacement version for delivery to its real-world environment and this entails replacing at least a first component from the block diagram to be processed using a RCP system if a second mode was chosen, the second mode being a
deployment achieved via prototyping.
Applicants have submitted that (Applicants Remarks pg. 8-9) Manglik’s ML-based update of animation graph for adding and/or removing node on basis of the least frequently used, does not teach removing when a RCP mode is selected wherein the to-be-removed node is solely connected on the input side of a removed node. The removal of nodes in Manglik is driven by determination that a node is not connected to the forward sequence flow, whereas environment to perform node removal when the node are not connected forward is already shown in the diagram editing by Chandhoke. Hence, the removal of nodes not connected at the output in editing graph by Manglik is sufficient to meet the removal of a component “solely connected at the input” (of a already removed component) in a development interface as claimed.
Applicants have submitted (Applicants Remarks pg. 9) that KtReddy auto-correction with removal of component with dangling output or with endpoints not connected to neighbor nodes is not a cascading type of downstream removal that performs removal based on a component that is solely connected at its input. In fact, automatic removal of endpoint as shown in KtReddy is triggered when the endpoint is not found as connected to any component in the vicinity of a flow and this can indicate improvement to the quality of a graph design that removes an endpoint observed as not being connected to component in the next vicinity, which can include a component I/O without a output connected to neighbor node down a flow logic or one with only one input endpoint attached.
Applicants have submitted (pg. 10, top) that neither Manglik, KtReddy can correct to the deficiency by Suenbuel since Suenbuel sensor deployment planer has no iterative designer workflow. User interface (para 0018) in Suenbuel shows that a user can select or deselect sensor modules or nodes (para 0036,0043) construed within a topology made interactable via the interface; and editing connectivity between the sensor activities via this UI is evident, not to mention that diagrams for this sensor network is provided with interconnection lines (network 104 – Fig. 1a)
Applicants have submitted that Ning sensor data acquisition system is not a development environment with runtime layer that executes block diagrams in real-time (Applicants Remarks pg. 10, top pg 11). Ning is particularly shown to demonstrate that runtime of a sensor-traffic system can provide real-time synchronization using a DSP or server environment enabled with visual display of timeline (para 0018-0021, 0037-0039). The use of diagram and connection for a design environment has been already provided in part from a sensor NW topology made interactable via the interface in Suenbuel enabling user editing the connectivity between the sensor activities via this UI, and so, in light of diagrams (Suenbuel: network 104 – Fig. 1a) for this sensor network being provided with interconnection lines; not to mention that execution of diagrams has been shown in part in the 3-D scene modeling by Sheng (para 0050, 0060, 0067), where sensor entities are modeled with timestamps.
Applicants have submitted that (Applicants Remarks pg. 11) Sheng’s 3D scene modeling with configuration of timestamps forwarded in a time-synchronized manner clearly does not disclose block diagrams being read and executed in a runtime of a development environment. It is deemed that configuring a model via a UI (para 0050) and placement of synchronization effects to implement accelerated logical interactions of components associated with a given flowchart or block diagrams is the crux of Sheng image acquisition system (see 0094), where configured components of such diagram-based flow entails execution runtime to observe via those diagrams. Applicant remarks is deemed non-convincing.
(B) Applicants have submitted that there is no teaching that Suenbuel about a runtime execution that actively executes block diagrams in real-time; and importing the teaching by Ning, or Sheng into Suenbueal as alleged by the Office Action would enforce fundamental redesign to Suenbuel system (Applicants Remarks pg. 12) in that the proposed combination of Chandhoke, Ketireddy ,Manglik, Ning and Sheng references by the obviousness rationale should be withdrawn. The above allegation has been addressed as insufficient on basis of the teachings by each reference as presented above; i.e. in light of the modeling environment by the references (e.g. Sheng, Manglik, Suenbuel) which include interconnected diagram or blocks modeling with UI-based configurations that provide arrangement and synchronization of sensor activities across a network topology.
( C) Applicants have submitted that in claim 18, the removing and replacing of component from the block diagram (per a second mode selection) in terms of removing an additional component to a removed first component (when the additional component is solely connected to the input of the latter on the output side) pertains to a cascade removal performed based on a mode selection triggered with a environment runtime of a development environment, according to which, the Manglik ML-based editing clearly fails to disclose, notably when the Office action treats the component removal and the second mode selection as two disjoint features. For one, the claim language does not describe runtime of a development environment effecting cascade removal based on selection of a hardware platform.
When the claim recites method comprising “removing or replacing … first component from the diagram if a second mode was chosen” it does follow that this removal pertains to a cascade removal flow that the second mode particularly supports; and recitation of “removing one additional component if the first component was removed and the additional component was connected solely to an input of the first component” (on the output side) most definitely entails removing a component whose endpoint output is no longer connected to any part of a removed component; and this definitely cannot be equivalent to a second mode hardware selection which is functionally intended to perform a cascade removal of any sort.
Therefore, allegation on patentability of claim 18 or 19 is deemed largely inconclusive, and so, particularly when the allegation by the Applicants emphasizes on runtime environment related to a development context in which components of block diagrams are being removed, and this makes it hard for one to construe what exactly is the selection of hardware platform(mode) has to do with automating removal of diagram elements. Even more obscure is the connectivity (or lack of linkage) between a diagram development environment which enable cascade removal, and the automated effect of a mode selection by which runtime of block diagrams include timestamp-based synchronization or additional component removal. The features mentioned by the applicants appear to be a huge mish-mash that includes diagram editing context within a development framework and actual simulation of model code that is configured with timestamps propagation, when no part of the platform or mode selection (second mode as claimed) depicts a strict static block editing or strict simulation of SW, notably when Applicant mention of executing diagrams in a runtime environment (as repeated in the arguments) clearly cannot represent a mere diagram editing context per a design phase, nor a simulation of code underlying a created model simply because selection of a HW mode/platform as claimed cannot equally performs cascade removal/adding as alleged together with runtime of executables underling the developed flow diagrams in a stage where static blocks removal would be no longer possible.
In all, the allegations about patentability of the feature expressed as executing block diagrams per a runtime in a diagram development environment are deemed largely inconclusive.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
June 16, 2026
Prosecution Insights