DETAILED ACTION
This action is responsive to the Applicant’s response filed 12/12/25.
As indicated in Applicant’s response, claims 1, 3, 6, 16 have been amended, claims 2, 7, 11 cancelled, and claims 18-19 added. Claims 1, 3-6, 8-10, 12-19 are 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 (see network 104 - Fig. 1a) via components connected (sensor nodes ... interconnected by wireless communication links - para 0018) 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 (see 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)
A) 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 effect of taking input per a GUI or interactive mode, including scenario where 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
manipulate 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 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.
B) 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 a 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 includes (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 (Chandhoke: convert, compile, transfer to FPGA - Fig. 34), and wherein a generation of source code 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 does not explicitly disclose a method for configuring a control unit, the control 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 0040; code generator - para 0011) so that executable code is generated (para 0037; generator 152 - Fig. le; generator 152 - Fig. 2);
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 by the computing unit of the control unit (para 0020; code suitable for execution on a sensor node - claim 19, pg. 6).
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, 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 of A(i) claim 1); and
removing at least one additional component if the first component was removed and the additional component was connected solely to an input (refer to rationale A(ii) of claim 1) of the first component on the output side,
C) 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 at the time 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 a 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.
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 is recognized
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 required.
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.
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 that seek all components that are no longer required as shown in Goodman's hypergraph update; 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 would necessarily avert pointer indirection setback of the runtime software that actually attempt to render the latest state of an 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.
Response to Arguments
Applicant's arguments filed 12/12/25 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) Applicants have submitted that none of the applied references teaches or suggests “removing … one additional component if the first component was removed and the additional component was connected solely to input of the first component … wherein the block diagram is …executed in a … environment that provides … sensor data with time stamps and forwards the sensor data in a time-synchronized manner” as now recited in claim 1. (Applicants Remarks pg. 9). The ground of rejection has now been adjusted to address the limitations of claim 1; hence raise of patentability merits on basis of the newly added feature thereto would be deemed largely MOOT.
(B) Applicants have submitted that for claim 2 and position taken by the Examiner for motivation to render this claim obvious, notably in regard to mention of “prohibitive and devastating effect” of unconnected component in code generation or compilation, the claim language makes no mention of compilation; but instead relates to “runtime” provisioning of sensor data passed with time stamps and forwarded in time-synchronized manner (Applicants Remarks, pg. 10). The argument is not directed to a explicit limitation in claim 2 now cancelled, whereas the alleged motivation provided to prosecute claim 2 as set forth above is nowhere found in the current Office action which has been adjusted to meet the new feature about “block diagram” execution in environment that “provides … sensor data with time stamps and forwards the sensor data in a time-synchronized manner” ; hence, the Applicant allegation to the merits of this “time-synchronized forwarding of sensor data” is construed as largely non-commensurate with the actual state of the prosecution presented with the Office Action from above.
In all, the claims submitted with the added features as mentioned above stand rejected as indicated with this current and latest state of prosecution.
Conclusion
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.
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://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Tuan A Vu/
Primary Examiner, Art Unit 2193
January 30, 2026