DETAILED ACTION
Remarks
This action is in response to the communication filed 14 April 2026 responsive to the 30 December 2025 non-final Office action (the “Previous Action”). Claims 1, 6 and 16 were amended via this communication.
Applicant also filed specification amendments and amendments to figure 2F on 30 March 2026. That response included non-compliant claim amendments as well but those amendments were deemed non-compliant and were not entered.
Claims 1-20 are pending. Claims 1, 6 and 16 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
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 .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
Applicant asserts that the objections to the specification have been addressed at p. 12 of its remarks but this does not appear to be the case. The objections are accordingly maintained.
Applicant’s remaining arguments are moot in view of the new ground(s) of rejection below, necessitated by Applicant’s amendments.
Specification
The specification is objected to for the following informalities:
It uses the trademarks BLUETOOTH and ZIGBEE without capitalization (every letter). See M.P.E.P. § 608.01(v).
Paragraph [0054] refers to “virtual organizations” 271a, which is inconsistent with figure 2D of the drawings, which shows 271a as referring to a “Dealer Code.”
Drawings
In view of Applicant’s amendments to the drawings and specification, the Previous Action’s drawing objections are withdrawn.
Claim Objections
Claim 16 is objected to for the following informalities:
Claim 16 refers executing a first stat machine workflow “to: causing…using…transmitting” starting at line 15 of the claim, which appears include typographical errors and should perhaps read -to: cause…use…transmit- instead.
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, 5-6, 11-14, 16-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rao et al. (US 2022/0365868) (art of record – hereinafter Rao) in further view of Aluru et al. (US 2012/0317555) (art of record – hereinafter Aluru) in further view of Moran et al. (US 2022/0334860) (art made of record – hereinafter Moran).
As to claim 1, Rao discloses: a computing system for testing of fleet management software, the computing system comprising at least one processor, at least one memory, and one or more non-transitory, computer-readable storage media storing instructions, which, when executed by the at least one processor, cause the computing system (e.g., Rao, par. [0032]: the terms program, application and the like are defined as a sequence of instructions designed for execution on a computer system; par. [0233]: the system may be embodied in the form of a computing device. The computing device can be a programmed microprocessor capably of implementing the steps that constitute the method of the invention [since the microprocessor is programmed, it executes programming instructions, which requires storing them in a non-transitory computer-readable storage media]. The computing device includes a memory, nonvolatile data storage) to:
generate a set of virtual assets, (e.g., Rao, par. [0060]: simulated device instances are created based on an existing device template)
wherein the virtual assets are simulations of machinery in a fleet; (e.g., Rao, par. [0171], IoT application 102 under test is monitoring a fleet of trucks; par. [0174]: considering the truck use case, one device template is for the engine of the truck, and another device template is for the radiator) and
wherein at least one asset in the set of virtual assets includes a set of simulated sensor values; (e.g., Rao, par. [0057]: device templates are created as a blueprint for the simulated device instances and are defined based on the sensor vendor specification document; par. [0040]: device templates include attributes; par. [0065]: attributes include device parameters include device parameters which do not change and which change “(such as, but not limited to, speed, engine run state, and fuel level”) [sensor values, simulated because the devices are simulated])
for the at least one asset in the set of virtual assets, (e.g., Rao, par. [0064]: device instances are defined based on a message structure) generate: (1) a first simulated application programming interface (API) message definition structured to capture a first subset of the set of simulated sensor values and (2) a second simulated API message definition structured to capture of a second subset of the set of simulated sensor values; (e.g., Rao, par. [0066]:UI module enables a user to define the message structure; par. [0067]: the user can select a KEY in the message structure and the method used to populate it, with, such as a current value of a device parameter or device attribute [which include simulated sensor values noted above]; par. [0071]: if a temperature parameter in Message A is greater than ‘X’, then the device should also emit a Message B [i.e., devices can send a plurality of messages]; par. [0053]: IoT application receives device messages [so the messages are application programming interface (API) messages because the instances use them to interface with the application])
bind the set of virtual assets to a simulation scenario record, (e.g., Rao, par. [0167]: a test scenario is populated with respective blocks; par. [0168]: each block is populated with the entities, which will participate in testing such as devices instances to be used in device block 804 [so devices are bound to the test scenarios in the sense that they are associated with it])
wherein the simulation scenario record is associated with a first scenario type and includes a first trigger condition (e.g., Fig. 8 and associated text, par. [0167]: scenario 802 is populated with blocks These blocks include device block 804; par. [0168]: each block is populated with the entities, which will participate in testing such as, device instances to be used in block 804; Rao, claim 3: a device instance comprises a plurality of rules, wherein the rules comprise message transmission rules; par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages [this scenario is associated with a type in the sense that it is a testing scenario]) and ordered references to the first simulated API message definition and the second simulated API message definition; (e.g., Rao, par. Fig. 8 and associated text, par. [0169]: test steps 810 [in an order, see figure] are created within a test scenario; par. [0170]: in each step, after setting the initial environment, multiple device messages may be sent) and
cause a scheduler to perform operations (see above, Rao is implemented in software, so the instructions of that software perform the following are a “scheduler”) comprising:
upon detecting that the first trigger condition is met, (e.g., Rao, par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages)
for each asset in the set of virtual assets, execute a first state machine workflow pertaining to first scenario type (see below, again the workflow pertains to a first scenario type in the sense that a test scenario is a type of scenario. The workflow can be seen as a state machine because it transmits based on whether or not preceding messages are sent (a state). Note too that a computer is a state machine)
generate a first simulated API message and a second simulated API message according to the ordered references; (e.g., Rao, par. [0033]: messages/data from IoT devices; par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages; par. [0067]: the value needs to be generated before the message is created and sent) and
transmit the first simulated API message and the second simulated API message (see immediately above).
Rao does not explicitly disclose to upon detecting that the trigger condition is met, fetch the simulation scenario record; to transmit to a target computing system; or upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, wherein the second scenario type pertains to data clean-up, and wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset.
However, in an analogous art, Aluru discloses:
upon detecting that the trigger condition is met, (e.g., Aluru, par. [0076]: when the time to provide the sensor simulation data to the application is determined, at block 406, sensor simulation data may be provided)
fetch the simulation scenario record; (e.g., Aluru, par. [0033] the sensor interface object may request data values at times that represent times at which a physical sensor would supply data values [retrieving data being fetching it]; par. [0084]: the data may be stored so that the sensor data engine may access the sensor simulation data and provide the data to the application upon request; par. [0040]: timing information, it may be used by the sensor data engine to determine an appropriate data value to simulate output of a sensor. This information may be used regardless of whether the engine is in a “push” or “pull” [fetch] mode) and
to transmit to a target computing system (e.g., Aluru, Fig. 3 and associated text, par. [0053]: sensor emulation environment 302 and application environment 304 may be executed on different computing device; par. [0058]: sensor emulation environment 302 may include sensor interface objects 312. Each of the interface objects 312 may provide sensor simulation data to the application [see figure, the application is in application environment 304]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the trigger conditions and scenario records taught by Rao by incorporating fetching scenario records upon detecting a trigger condition is met, as taught by Aluru, as Aluru would provide the advantage of a means of retrieving the appropriate scenario data in response to the trigger, as suggested by Rao. (See Aluru, par. [0084], Rao, par. [0170).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transmission of messages to an application upon taught by Rao by incorporating transmission to another computing system, as taught by Aluru, as Aluru would provide the advantage of a means of sending the data to an application running on a separate system. (See Aluru, par. [0053]).
Further, in an analogous art, Moran discloses:
upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, (e.g., Moran, par. [0044]: all VMs and processors are cleaned-up and/or deconstructed upon completion [second trigger condition]of the given workflow [first scenario type]; par. [0046]: clean-up and/or removal operations [second scenario type] may be contained and/or configured via a separate file. Referring to Fig. 4, example code snippet 400 illustrates steps [a workflow, state machine because it depends on a particular state (the VMs and controllers being deployed] for cleaning-up and/or removing the workers as well as test controller(s), which can include archiving results; par. [0052]: to run a performance test on a given environment [i.e., here, simulated operation of an actual running system])
wherein the second scenario type pertains to data clean-up, (see immediately above) and
wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset (see above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the simulation taught by Rao such that upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, wherein the second scenario type pertains to data clean-up, and wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset., as taught by Moran, as Moran would provide the advantage of a means of minimizing upkeep and maintenance on the system. (See Moran, par. [0056]).
As to claim 5, Rao/Aluru/Moran discloses the computing system of claim 1 (see rejection of claim 1 above), Rao further discloses further comprising instructions to:
generate a virtual organization; (e.g., Rao, Fig. 8 and associated text, par. [0168]: each block is populated with the entities, which will participate in the testing, such as, device instances to be used in device block 804 [the populated block being a virtual organization]) and
bind the simulation scenario record to the virtual organization (e.g., Rao, par. [0167]: test scenario 802 is populated with blocks. These blocks include device block 804 [i.e., the device block (virtual organization) is associated with (bound to) the simulation scenario])
wherein assets in the set of virtual assets are selectable for inclusion in a particular simulation scenario if the assets are associated with the virtual organization (e.g., Rao, par. [0203]: device instances that need to be utilized for simulation testing selected. A simulation run is then executed).
As to claim 6, Rao discloses one or more non-transitory, computer-readable storage media storing instructions, which, when executed by at least one data processor of a computing system (e.g., Rao, par. [0032]: the terms program, application and the like are defined as a sequence of instructions designed for execution on a computer system; par. [0233]: the system may be embodied in the form of a computing device. The computing device can be a programmed microprocessor capably of implementing the steps that constitute the method of the invention [since the microprocessor is programmed, it executes programming instructions, which requires storing them in a non-transitory computer-readable storage media]) for testing of fleet management software, (see below) cause the computing system to:
generate a set of virtual assets, (e.g., Rao, par. [0060]: simulated device instances are created based on an existing device template) wherein the virtual assets are simulations of machinery in a fleet (e.g., Rao, par. [0171], IoT application 102 under test is monitoring a fleet of trucks; par. [0174]: considering the truck use case, one device template is for the engine of the truck, and another device template is for the radiator) and wherein at least one asset in the set of virtual assets is associated with a set of simulated sensor values; (e.g., Rao, par. [0057]: device templates are created as a blueprint for the simulated device instances and are defined based on the sensor vendor specification document; par. [0040]: device templates include attributes; par. [0065]: attributes include device parameters include device parameters which do not change and which change “(such as, but not limited to, speed, engine run state, and fuel level”) [all simulated sensor values because the devices are simulated])
for the at least one asset in the set of virtual assets, (e.g., Rao, par. [0064]: device instances are defined based on a message structure) generate a simulated application programming interface (API) message definition structured to capture the set of simulated sensor values; (e.g., Rao, par. [0066]:UI module enables a user to define the message structure; par. [0067]: the user can select a KEY in the message structure and the method used to populate it, with, such as a current value of a device parameter or device attribute [which include simulated sensor values noted above]; par. [0071]: if a temperature parameter in Message A is greater than ‘X’, then the device should also emit a Message B [i.e., devices can send a plurality of messages]; par. [0053]: IoT application receives device messages [so the messages are application programming interface (API) messages because the instances use them to interface with the application])
bind the set of virtual assets to a simulation scenario record, (e.g., Rao, par. [0167]: a test scenario is populated with respective blocks; par. [0168]: each block is populated with the entities, which will participate in testing such as devices instances to be used in device block 804 [so devices are bound to the test scenarios in the sense that they are associated with it])
wherein the simulation scenario record is associated with a first scenario type and includes a first trigger condition; (e.g., Fig. 8 and associated text, par. [0167]: scenario 802 is populated with blocks These blocks include device block 804; par. [0168]: each block is populated with the entities, which will participate in testing such as, device instances to be used in block 804; Rao, claim 3: a device instance comprises a plurality of rules, wherein the rules comprise message transmission rules; par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages [this scenario is associated with a type in the sense that it is a testing scenario]) and
cause a scheduler to perform operations (see above, Rao is implemented in software, the software instructions performing the following being a “scheduler”) comprising:
upon detecting that the first trigger condition is met, execute a first state machine workflow, pertaining to the first scenario type (e.g., Rao, par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages [again the workflow pertains to a first scenario type in the sense that a test scenario is a type of scenario. The workflow can be seen as a state machine because it transmits based on whether or not preceding messages are sent (a state). Note too that a computer is a state machine]) to:
for each asset in the set of virtual assets, (See immediately below)
generate a simulated API message according to the definition; (e.g., Rao, par. [0033]: messages/data from IoT devices; par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages; par. [0067]: the value needs to be generated before the message is created and sent) and
transmit the simulated API message (see immediately above).
Rao does not explicitly disclose to: upon detecting that the trigger condition is met, fetch the simulation scenario record; to transmit a target computing system; and upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, wherein the second scenario type pertains to data clean-up, and wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset.
However, in an analogous art, Aluru discloses to:
upon detecting that the trigger condition is met, (e.g., Aluru, par. [0076]: when the time to provide the sensor simulation data to the application is determined, at block 406, sensor simulation data may be provided)
fetch the simulation scenario record; (e.g., Aluru, par. [0033] the sensor interface object may request data values at times that represent times at which a physical sensor would supply data values [retrieving data being fetching it]; par. [0084]: the data may be stored so that the sensor data engine may access the sensor simulation data and provide the data to the application upon request; par. [0040]: timing information, it may be used by the sensor data engine to determine an appropriate data value to simulate output of a sensor. This information may be used regardless of whether the engine is in a “push” or “pull” [fetch] mode) and
to transmit a target computing system (e.g., Aluru, Fig. 3 and associated text, par. [0053]: sensor emulation environment 302 and application environment 304 may be executed on different computing device; par. [0058]: sensor emulation environment 302 may include sensor interface objects 312. Each of the interface objects 312 may provide sensor simulation data to the application [see figure, the application is in application environment 304]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the trigger conditions and scenario records taught by Rao by incorporating fetching scenario records upon detecting a trigger condition is met, as taught by Aluru, as Aluru would provide the advantage of a means of retrieving the appropriate scenario data in response to the trigger, as suggested by Rao. (See Aluru, par. [0084], Rao, par. [0170).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transmission of messages to an application upon taught by Rao by incorporating transmission to another computing system, as taught by Aluru, as Aluru would provide the advantage of a means of sending the data to an application running on a separate system. (See Aluru, par. [0053]).
Further, in an analogous art, Moran discloses:
upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, (e.g., Moran, par. [0044]: all VMs and processors are cleaned-up and/or deconstructed upon completion [second trigger condition]of the given workflow [first scenario type]; par. [0046]: clean-up and/or removal operations [second scenario type] may be contained and/or configured via a separate file. Referring to Fig. 4, example code snippet 400 illustrates steps [a workflow, state machine because it depends on a particular state (the VMs and controllers being deployed] for cleaning-up and/or removing the workers as well as test controller(s), which can include archiving results; par. [0052]: to run a performance test on a given environment [i.e., here, simulated operation of an actual running system])
wherein the second scenario type pertains to data clean-up, (see immediately above) and
wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset (see above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the simulation taught by Rao such that upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, wherein the second scenario type pertains to data clean-up, and wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset., as taught by Moran, as Moran would provide the advantage of a means of minimizing upkeep and maintenance on the system. (See Moran, par. [0056]).
As to claim 11, it is media claim having limitations substantially the same as those of claim 5 and is rejected for substantially the same reasons.
As to claim 12, Rao/Aluru/Moran discloses the media of claim 6 (see rejection of claim 6 above) Rao further discloses:
using an identifier associated with the simulated API message definition, generating a related sequence of electronic messages, the related sequence comprising the simulated API message and a set of API messages related to the simulated API message (e.g., Rao, par. [0071]: messages [API message, see above] transmission rules can be defined to create an interlinking between two messages. For instance, if Message A [A being an identifier] with parameter “xyz” greater than 10 us sent, then a device should also send out Message B).
As to claim 13, Rao/Aluru/Moran discloses the media of claim 6 (see rejection of claim 6 above), Rao further discloses the instructions further comprising:
generating a data structure in a particular programming language according to a user-specified selection; (e.g., Rao, par. [0078]: UI module allows the user to define the JSON [particular programming language] structure with all its features which includes, defining an array [data structure] and an object [data structure]) and
including the data structure in the simulated API message definition (see immediately above).
As to claim 14, Rao/Aluru/Moran discloses the media of claim 6 (see rejection of claim 6 above), Rao further discloses:
wherein a particular simulated sensor value includes or approximates raw data received from a sensor associated with the machinery (e.g., Rao, par. [0065]: attributes include device parameters include device parameters which do not change and which change “(such as, but not limited to, speed, engine run state, and fuel level”) [all simulated sensor values, since the devices are simulated]; Fig. 11 and associated text [see figure, the engine temperature and speed values are numeric and have units of measurement of Degree Celsius and kmph, which would approximate the values of actual sensors in the sense that real sensors produce data having similar characteristics]; par. [0137]: a value generation unit simulating the data).
As to claim 16, Rao discloses a method for testing of fleet management software with automatic asset synchronization (this preamble is not treated as limiting, see M.P.E.P. § 2111.02), the method comprising:
generating a set of virtual assets, (e.g., Rao, par. [0060]: simulated device instances are created based on an existing device template) wherein the virtual assets are simulations of machinery in a fleet; (e.g., Rao, par. [0171], IoT application 102 under test is monitoring a fleet of trucks; par. [0174]: considering the truck use case, one device template is for the engine of the truck, and another device template is for the radiator)
for at least one asset in the set of virtual assets, (e.g., Rao, par. [0064]: device instances are defined based on a message structure) generating a simulated application programming interface (API) message definition structured to capture, according to a configuration setting, a set of simulated sensor values; (e.g., Rao, par. [0066]:UI module enables a user to define the message structure; par. [0067]: the user can select a KEY in the message structure and the method used to populate it, with, such as a current value of a device parameter or device attribute; par. [0065]: attributes include device parameters include device parameters which do not change and which change “(such as, but not limited to, speed, engine run state, and fuel level”) [sensor values, simulated because the devices are simulated]; par. [0053]: IoT application receives device messages [so the messages are application programming interface (API) messages because the instances use them to interface with the application])
binding the set of virtual assets to a simulation scenario record, (e.g., Rao, par. [0167]: a test scenario is populated with respective blocks; par. [0168]: each block is populated with the entities, which will participate in testing such as devices instances to be used in device block 804 [so devices are bound to the test scenarios in the sense that they are associated with it]) wherein the simulation scenario record is associated with a first scenario type and includes a first trigger condition; (e.g., Fig. 8 and associated text, par. [0167]: scenario 802 is populated with blocks These blocks include device block 804; par. [0168]: each block is populated with the entities, which will participate in testing such as, device instances to be used in block 804; Rao, claim 3: a device instance comprises a plurality of rules, wherein the rules comprise message transmission rules; par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages [this scenario is associated with a scenario type in the sense that it is a testing scenario]) and
causing a scheduler to perform operations (see above, Rao is implemented in software, so the instructions of that software perform the following are a “scheduler”) comprising:
upon detecting that the first trigger condition is met, (e.g., Rao, par. [0036]: the message transmission rules define the conditions for IoT messages. The rules create an interlinking which triggers a sequence of IoT messages based on the transmitting of one or more preceding IoT messages)
for each asset in the set of virtual assets execute a first state machine workflow, pertaining to the first scenario type (see below, again the workflow pertains to a first scenario type in the sense that a test scenario is a type of scenario. The workflow can be seen as a state machine because it transmits based on whether or not preceding messages are sent (a state). Note too that a computer is a state machine) to
causing the asset to automatically update a particular configuration setting for the asset, wherein the particular configuration setting specifies a particular set of simulated sensor values; (e.g., Rao, par. [0067]: the user can specify how the value needs to be generated before the message is created and sent. The user can select a KEY in the message structure and the method used to populate it, with, such as a current value of a device parameter or device attribute [simulated sensor value, see above])
using the particular set of simulated sensor values specified by the updated configuration setting, generating a simulated API message according to the definition; (e.g., Rao, par. [0066]: UI module 316 enables a user to define the message structure; par. [0067]: for each of the KEYS in the structure, the user can specify how the value needs to be generated before the message [API message, see above] is created and sent. The use can select a particular KEY in the message structure and specify the method used to populate it with) and
transmitting the simulated API message (see immediately above)
Rao does not explicitly disclose upon detecting that the trigger condition is met, fetching the simulation scenario record; and transmitting to a target computing system; and upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, wherein the second scenario type pertains to data clean-up, and wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset.
However, in an analogous art, Aluru dislcoses:
upon detecting that the trigger condition is met, (e.g., Aluru, par. [0076]: when the time to provide the sensor simulation data to the application is determined, at block 406, sensor simulation data may be provided)
fetching the simulation scenario record; (e.g., Aluru, par. [0033] the sensor interface object may request data values at times that represent times at which a physical sensor would supply data values [retrieving data being fetching it]; par. [0084]: the data may be stored so that the sensor data engine may access the sensor simulation data and provide the data to the application upon request; par. [0040]: timing information, it may be used by the sensor data engine to determine an appropriate data value to simulate output of a sensor. This information may be used regardless of whether the engine is in a “push” or “pull” [fetch] mode) and
transmitting to a target computing system (e.g., Aluru, Fig. 3 and associated text, par. [0053]: sensor emulation environment 302 and application environment 304 may be executed on different computing device; par. [0058]: sensor emulation environment 302 may include sensor interface objects 312. Each of the interface objects 312 may provide sensor simulation data to the application [see figure, the application is in application environment 304]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the trigger conditions and scenario records taught by Rao by incorporating fetching scenario records upon detecting a trigger condition is met, as taught by Aluru, as Aluru would provide the advantage of a means of retrieving the appropriate scenario data in response to the trigger, as suggested by Rao. (See Aluru, par. [0084], Rao, par. [0170).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transmission of messages to an application upon taught by Rao by incorporating transmission to another computing system, as taught by Aluru, as Aluru would provide the advantage of a means of sending the data to an application running on a separate system. (See Aluru, par. [0053]).
Further, in an analogous art, Moran discloses:
upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, (e.g., Moran, par. [0044]: all VMs and processors are cleaned-up and/or deconstructed upon completion [second trigger condition]of the given workflow [first scenario type]; par. [0046]: clean-up and/or removal operations [second scenario type] may be contained and/or configured via a separate file. Referring to Fig. 4, example code snippet 400 illustrates steps [a workflow, state machine because it depends on a particular state (the VMs and controllers being deployed] for cleaning-up and/or removing the workers as well as test controller(s), which can include archiving results; par. [0052]: to run a performance test on a given environment [i.e., here, simulated operation of an actual running system])
wherein the second scenario type pertains to data clean-up, (see immediately above) and
wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset. (see above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the simulation taught by Rao such that upon detecting that a second trigger condition is met, execute a second state machine workflow for the at least one asset, the second state machine workflow comprising operations to execute an additional simulation scenario record of a second scenario type different from the first scenario type, wherein the second scenario type pertains to data clean-up, and wherein executing the additional simulation scenario includes operations to clear persisted simulation data relating to the at least one asset., as taught by Moran, as Moran would provide the advantage of a means of minimizing upkeep and maintenance on the system. (See Moran, par. [0056]).
As to claim 17, Rao/Aluru/Moran discloses the method of claim 16 (see rejection of claim 16 above), Rao further discloses:
wherein the particular set of simulated sensor values relate to an asset state (e.g., Rao, par. [0065]: attributes [simulated sensor values, see above], include device parameters include device parameters which do not change and which change “(such as, but not limited to, speed, engine run state, and fuel level”).
As to claim 20, Rao/Aluru/Moran discloses the method of claim 16 (see rejection of claim 16 above), Rao further discloses:
wherein the particular set of simulated sensor values relate to an asset component, the asset component being one of an engine and a battery (e.g., Rao, par. [0065]: attributes [simulated sensor values, see above], include device parameters include device parameters which do not change and which change “(such as, but not limited to, speed, engine run state, and fuel level”).
Claims 2-3 and 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 2022/0365868) in view of Aluru (US 2012/0317555) in view of Moran (US 2022/0334860) in further view of Randolph et al. (US 2019/0068455) (art of record – hereinafter Randolph).
As to claim 2, Rao/Aluru/Moran discloses the computing system of claim 1 (see rejection of claim 1 above), but does not explicitly disclose wherein the scheduler comprises a state machine structured to detect that trigger conditions are met.
However, in an analogous art, Randolph discloses:
wherein the scheduler comprises a state machine structured to detect that trigger conditions are met (e.g., Randolph, par. [0066]: by ingesting data from the sensor reliable actor service module 205, the state machine service module 209 may trigger state transitions for each device or sensor so modeled. For example, during an “off state” of a sensor, the state machine service module 209 may ignore instructions to that sensor, refusing to pass the instructions to the sensor reliable actor service module 205).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the scheduler of Rao, such that it comprises a state machine structured to detect that trigger conditions are met, as taught by Randolph, as Randolph would provide the advantage of a means of ensuring the software of Rao is efficient, scalable and maintainable. (See “Introduction to State Machines and Use Cases” at p. 6 par. 2).
As to claim 3, Rao/Aluru/Moran/Randolph discloses the computing system of claim 2 (see rejection of claim 1 above), Rao further discloses:
wherein the software is structured to cause a temporal delay after generating the first simulated API message and prior to generating the second simulated API message, and wherein the temporal delay determined based on the simulation scenario record (e.g., Rao, par. [0169]: test steps 810 are created within a test scenario; par. [0170]: There can be a possibility that in each step, multiple device messages may be sending two subsequent messages.).
Rao does not explicitly disclose a state machine.
However, in an analogous art, Randolph discloses:
a state machine (e.g. Randolph, p. 6 par. 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the scheduler of Rao, such that it comprises a state machine structured to detect that trigger conditions are met, as taught by Randolph, as Randolph would provide the advantage of a means of ensuring the software of Rao is efficient, scalable and maintainable. (See “Introduction to State Machines and Use Cases” at p. 6 par. 2).
As to claim 7, it is media claim having limitations substantially the same as those of claim 2 and is rejected for substantially the same reasons.
As to claim 8, it is media claim having limitations substantially the same as those of claim 3 and is rejected for substantially the same reasons.
As to claim 9, Rao/Aluru/Moran/Randolph discloses the media of claim 7 (see rejection of claim 7 above), Rao further discloses:
wherein the software is structured to obtain an additional sensor value for a particular virtual asset in the set of virtual assets and generate additional simulated API messages using the additional sensor value (e.g., Rao, par. [0071]: if message A with parameter [which can be a sensor value, see above] “xyz” [additional sensor value] greater than 10 is sent, then a device should also send out Message B [API message] with parameter “mno” value as 20 [the first value is used to send the message because generation of the second message is conditioned on that value meeting a condition])
Rao does not explicitly disclose a state machine.
However, in an analogous art, Randolph discloses:
a state machine (e.g. Randolph, p. 6 par. 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the scheduler of Rao, such that it comprises a state machine structured to detect that trigger conditions are met, as taught by Randolph, as Randolph would provide the advantage of a means of ensuring the software of Rao is efficient, scalable and maintainable. (See “Introduction to State Machines and Use Cases” at p. 6 par. 2).
Claims 4 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 2022/0365868) in view of Aluru (US 2012/0317555) in view of Moran (US 2022/0334860) in further view of Casey et al. (US 2022/0343230) (art of record – hereinafter Casey).
As to claim 4, Rao/Aluru/Moran discloses the computing system of claim 1 (see rejection of claim 1 above) but does not explicitly disclose further comprising instructions to: generate an additional simulation scenario record by cloning the simulation scenario record.
However, in an analogous art, Casey discloses:
further comprising instructions to: generate an additional simulation scenario record by cloning the simulation scenario record (e.g., Casey, par. [0102]: characteristics of the electric grid simulated based on each of the scenarios; par. [0124]: duplicating a scenario. In this way, the system enables a user to generate new scenarios from pre-existing scenarios instead of creating each scenario anew).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Rao, to include generating an additional simulation scenario by cloning the simulation scenario record, as taught by Casey, as Casey would provide the advantage of a means of creating new scenarios without having to create each one anew. (See Casey, par [0124]).
As to claim 10, it is media claim having limitations substantially the same as those of claim 4 and is rejected for substantially the same reasons.
Claims 15, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 2022/0365868) in view of Aluru (US 2012/0317555) in view of Moran (US 2022/0334860) in further view of Saha et al. (US 2022/0075708) (art of record – hereinafter Saha).
As to claim 15, Rao/Aluru/Moran discloses the media of claim 6 (see rejection of claim 6 above), but Rao does not explicitly disclose wherein a particular simulated sensor value comprises a synthetic value generated based on a set of raw data received from one or more sensors associated with the machinery.
However, in an analogous art, Saha discloses:
wherein a particular simulated sensor value comprises a synthetic value generated based on a set of raw data received from one or more sensors associated with the machinery (e.g., Saha, par. [0006]: the Doppel models can be defined by specifying the characteristics of the devices or by deriving them from a recorded data stream [raw data] of a physical device; par. [0069]: FIG. 3 illustrates the constituents of a Doppel Model, comprising data points or sensors; par. [0072]: datapoints 303 describe the various sensors that are part of the device/thing or quantities being measured [sensed] and reported by the device thing; par. [0085]: some data point values can be “derived” from other data point values).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the sensor data Rao to include a synthetic value generated based on a set of raw data received from one or more sensors associated with the machinery, as taught by Saha, as Saha would avoid the need for to specify the data manually and ensure a data double of a physical device. (See Saha, par. [0006]).
As to claim 18, Rao/Aluru/Moran discloses the method of claim 17 (see rejection of claim 17 above), but does not explicitly disclose wherein the asset state indicates that the asset is disabled, derated or tampered with.
However, in an analogous art, Saha discloses:
wherein the asset state indicates that the asset is disabled, derated or tampered with (e.g., Saha, par. [0068-0067]: device/things 101 that can be modeled are a part of equipment, a vehicle or fork lift; par. [0072]: datapoints 303 describe various sensors that are part of the device/thing; par. [0088]: ignition status can be modelled as a Constant Value Datapoint. It has a value of Off/0 when the vehicle is off and On/1 when the vehicle on; par. [0079]: ignition value is 1 to indicate motion).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the asset state of Rao such that it indicates that the asset is disabled, derated, or tampered with, as taught by Saha, as Saha would provide the advantage of a means of simulating machinery in an on or off state. (See Saha, par. [0088]).
As to claim 19, Rao/Aluru/Moran discloses the method of claim 17 (see rejection of claim 17 above), but does not explicitly disclose wherein the asset state indicates that the asset is in active operation.
However, in an analogous art, Saha discloses:
wherein the asset state indicates that the asset is in active operation (e.g., Saha, par. [0068-0067]: device/things 101 that can be modeled are a part of equipment, a vehicle or fork lift; par. [0072]: datapoints 303 describe various sensors that are part of the device/thing; par. [0088]: ignition status can be modelled as a Constant Value Datapoint. It has a value of Off/0 when the vehicle is off and On/1 when the vehicle on; par. [0079]: ignition value is 1 to indicate motion).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the asset state of Rao such that wherein the asset state indicates that the asset is in active operation, as taught by Saha, as Saha would provide the advantage of a means of simulating machinery in a on or moving state. (See Saha, pars. [0088] and [0079]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM 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, Hyung S Sough can be reached at (571)272-6799. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192
Prosecution Insights