DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment / Arguments
Regarding priority to provisional application No. 63/369,869:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that the provisional specification supports the claim limitations at issue and points to paragraphs [0001]-[0006]. For “transmitting, by the device, a first set of alerts associated with the event; receiving, by the device and from a second set of monitoring sensors, a set of tracking updates based on transmitting the set of alerts associated with the event,” Applicant points to [0003] and [0006] stating that some “implementations may enable remote patient monitoring sending out custom alerts to a mobile application” and provide for “remote patient monitoring… real-time execution of dynamic machine learning models.” However, the cited portions do not elaborate what is analogous to “the device” in sending out the custom alerts, nor do they specify an “event” analogue. Further, it is not clear which language in the cited portions relates to receiving tracking updates “based on transmitting the set of alerts associated with the event.” It is additionally not clear what elements are to be interpreted as support for “a second set of monitoring sensors” or even the “tracking updates.”
With respect to “registering, by the device, a set of attributes, associated with the entity and the set of tracking updates, in a distributed ledger based on receiving the set of tracking updates,” Applicant points to [0001] and [0003], bolding the following language for emphasis: “analyzing a supply chain for an optimization of resource allocations… Different computing systems may be deployed… and the different systems may be used to store data and output data… as processes become increasingly automated and computer integrated, deploying a processing platform… Some implementations include communication with… sensors to monitor production and development characteristics, blockchain for information transparency and accessibility during shipment.” While the cited portions do mention communicating with a blockchain, it is not clear which language is meant to be interpreted as support for “based on receiving the set of tracking updates” nor “a set of attributes.” It is likewise unclear how the cited portions support the full context of “registering, by the device, a set of attributes, associated with the entity and the set of tracking updates, in a distributed ledger based on receiving the set of tracking updates.”
With respect to “transmitting, by the device, a second set of alerts associated with the distributed ledger based on registering the set of attributes in the distributed ledger,” Applicant points to [0004] and [0006], bolding the following language for emphasis: “implementations include… payment switch capabilities… omnichannel… switch between third-party payment providers… Some implementations enable… real-time inclusion of other forms of payment… each entity can have a different set of modules… reused or re-instantiated across entities… Some implementations may use a decentralized block chain… provide automated insights… provide a cloud framework… integration to multiple devices… real-time execution… provide… real-time patient insight and/or public health updates… discovery of leading re-admission indicators.” It is not at all clear which of these is intended as support for “the device” and “a second set of alerts,” nor how the cited portions support “based on registering the set of attributes in the distributed ledger.”
Applicant relies on [0001]-[0006] of the provisional specification by pointing to what appears to be a discussion of multiple different embodiments and implementations. However, these do not appear to be linked in a way as to disclose the claim limitations at issue when taken as a respective whole. The cited portions of the provisional application do mention patient monitoring, health updates, and using a blockchain. But they do not link these elements in the same manner as they are structured together in the claim limitations at issue.
Regarding claims rejected under 35 USC 112(b):
Applicant’s amendment is considered to have overcome the applied rejections. Accordingly, the rejections have been withdrawn.
Regarding the claim rejected under 35 USC 112(d):
Applicant has canceled the rejected claim. Accordingly, the rejection has been withdrawn.
Regarding claims rejected under 35 USC 103:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that Cella does not teach “receiving… from a second set of monitoring sensors… tracking updates based on transmitting the first set of alerts associated with the event.” For instance, Applicant argues that “Cella fails to trigger a first alert based on the sensor measurements that are received. Cella at most talk about simultaneous sampling of other sensors on a device. Further, Cella in its entirety talks about route changes detected as the result of a single-point sensor. Therefore, Cella merely talks about triggering a rapid route change upon detecting operational mode changes… the sensors that are involved in providing the tracking updates (second set of monitoring sensors) is different from the configuration of sensors involved in enabling the device to transmit a first set of alerts.”
In response, it is noted that Cella discloses an example of “a system for data collection in an industrial environment may use ambient, local and vibration noise for prediction of outcomes, events, and states” as in [1794], where the data is based on sensor data such as in [1792] (e.g., “a microphone, ultrasound sensors, acoustic wave sensors, optical vibration sensors… Any sensor data may be used by the expert system to provide an ambient sensed condition for analysis along with the vibration fingerprint to predict an outcome, event, or state”). “Based on the prediction, the expert system may one or more of trigger an alert of a failure, imminent failure, or maintenance event,… generate/modify a maintenance schedule, or the like” as in [1795] of Cella. Additionally, [1123] and [6423] of Cella disclose having “smart route changes based on incoming data or alarms” with smart route changes being further defined in [1728] of Cella as “as changes enabling dynamic selection of data collection for analysis or correlation… [which] may enable the system to alter current routing of sensor data based on incoming data or alarms… but when the analysis (or an alarm) indicates a special need, the system may change the sensor routing to address that need… the system may change the routing to collect more focused data collection for analysis, such as… initiating collection using other sensors (such as temperature or heat flux sensors).”
As such, Cella discloses monitoring an entity with a first set of sensors until a prediction causes an alarm and a smart route change based on the alarm. The smart route change includes initiating data collection using other sensors. The sensor data from the other sensors is received and processed accordingly.
Further in response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., that the “claimed invention clearly specify that the sensors that are involved in providing the tracking updates (second set of monitoring sensors) is different from the configuration of sensors involved in enabling the device to transmit a first set of alerts”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claims merely specify a first set of sensors and a second set of sensors without any language concerning disjoint set elements. For example, a first set of sensors may contain a second set of sensors as a subset or vice-versa. For the purpose of applying prior art, the claim language has been interpreted such that the first and second sets are not the exact same set. However, the first set and the second set may be the same set in the trivial case. It is also noted that the claim language does not refer to a “configuration” of sensors.
Applicant further argues that Cella does not teach “registering, by the device, a set of attributes, associated with the entity and the set of tracking updates, in a distributed ledger based on receiving the set of tracking updates.” Specifically, Applicant argues that “[i]t is important to note that the registration of the set of attributes associated with the entity and the set of tracking updates are registered (or stored) only upon receiving the set of tracking updates. Whereas, Cella merely have a distributed ledger that facilitates the storage of sensor data and further receives or updates the ledger with sensor inputs at discrete intervals.” In response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “registered (or stored) only upon receiving the set of tracking updates”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this case, the independent claim does not limit registration taking place “only upon” receiving the set of tracking updates. Instead, registration takes place “based on receiving the set of tracking updates.”
As per at least [0514], [3051], and [3117] of Cella, it updates a distributed ledger with received sensor data. This can include sensor data as in [1728]-[1729] above (i.e., sensor data from other sensors).
Applicant additionally argues against the Cella-Singh combination, stating that in Singh, “the distributed ledger is configured to merely store data or provide the stored data for validation. Singh merely enables an adjustment module to consult the distributed ledger to validate the configuration, but fails to transmit a second set of alerts (that is evidently different from the first set of alerts) associated with the distributed ledger based on registering the set of attributes in the distributed ledger.” In response, it is noted that Singh concerns a validation platform that obtains performance information of a monitored ATM, generates a digital twin for the ATM, and further monitors the digital twin (e.g., the abstract of Singh). As per at least [0018], [0022], and [0056] of Singh, digital twin data may be stored to a distributed ledger, and the validation platform uses the distributed ledger data for sending updated configurations to the monitored ATM. Singh therefore discloses using a blockchain to store digital twin data and pushing updates to devices based on the stored data in the blockchain. Since Cella already uses a blockchain as described above, the combination of Cella-Singh modifies the teachings of Cella to further use the blockchain in pushing updates to devices involved in monitoring and remediation as discussed on page 7 of the 9/5/2025 Office action.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 1-6, 8-13, and 21-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cella (US 2021/0157312 A1) in view of Singh (US 2023/0316876 A1).
Regarding claim 1, Cella discloses: A method, comprising:
registering, by a device (e.g., backend system 28750 as part of the system in FIG. 287 of Cella), a first set of monitoring sensors associated with monitoring an entity;
Refer to at least 30202-30204 in FIG. 302 of Cella. As per [3114] of Cella, “the backend system 28750 registers the sensor kit 28700 to a respective industrial setting 28720… the backend system 28750 provides an interface for specifying a type of entity or industrial setting 28720 to be monitored.”
receiving, by the device and from the first set of monitoring sensors, and based on registering the first set of monitoring sensors, a first set of sensor measurements of the entity during a monitoring period;
Refer to at least 30204-30208 in FIG. 302 and [3114]-[3117] of Cella with respect to the backend system receiving instances of sensor data from the sensor kit sensors.
generating, by the device and based on the first set of sensor measurements, a prediction for an event associated with the entity;
Refer to at least 11042-11046 in FIG. 147 and [1885] of Cella with respect to determining a predicted outcome for a process associated with the industrial system (e.g., “determining a predicted off-nominal operation for the process associated with the industrial system; determining a prediction value for one of the plurality of components; determining a future state value for one of the plurality of components”).
transmitting, by the device, a first set of alerts associated with the event;
Refer to at least [1795] of Cella, where “[b]ased on the prediction, the expert system may one or more of trigger an alert.” In [3048], Cella discloses that “the user may define a set of conditions, which if predicted by the AI module and/or the edge device, trigger an alarm.”
Refer to at least [6423] of Cella stating that “provided herein is a system for data collection in an industrial environment having smart route changes based on incoming data or alarms to enable simultaneous dynamic data for analysis or correlation and having a backend system that includes an AI module that trains machine-learned models to make predictions or classifications related to sensor data captured by a sensor kit.”
receiving, by the device and from a second set of monitoring sensors, a set of tracking updates based on transmitting the first set of alerts associated with the event;
Refer to at least [1729] of Cella concerning the result of a route change being that “additional sensors may be engaged to watch for failures.” In [1732] of Cella, a route change may include “an increase in the number of sensors being sampled (e.g., simultaneous sampling of other sensors on a device, coordinated sampling of similar sensors on near-by devices), generating a burst of sampling (e.g., sampling at a high rate for a period of time), and the like.” Further see at least [1260] of Cella with respect to triggering data collection from additional sensors.
registering, by the device, a set of attributes, associated with the entity and the set of tracking updates, in a distributed ledger based on receiving the set of tracking updates;
Refer to at least [0514] of Cella with respect to “sensor data representing a condition of an industrial machine; determining a severity of the condition of the industrial machine by analyzing the sensor data; predicting a maintenance action to perform against the industrial machine based on the severity of the condition; and storing a transaction record of the predicted maintenance action within a ledger of service activity associated with the industrial machine.” In [0515] of Cella, the system “generates subsequent blocks of the ledger by combining data from at least one of… operational sensor data.”
Refer to at least [3051] and [3117] of Cella with respect to the backend system including a distributed ledger that it updates based on processed instances of sensor data.
Cella does not appear to disclose: transmitting, by the device, a second set of alerts associated with the distributed ledger based on registering the set of attributes in the distributed ledger. However, Cella in view of Singh discloses: transmitting, by the device, a second set of alerts associated with the distributed ledger based on registering the set of attributes in the distributed ledger.
Refer to at least the abstract, [0022], and [0056] of Singh with respect to directing configuration updates to devices based on information stored to a distributed ledger.
The teachings of Cella and Singh relate to monitoring the correct functioning of devices, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Cella to further use the distributed ledger for pushing updates to devices involved in monitoring and remediation for at least the purpose of increasing security and confidence by providing a cryptographically secured and immutable record (i.e., utilizing the properties of distributed ledgers to protect against malicious nodes, and for auditing).
Regarding claim 2, Cella-Singh discloses: The method of claim 1, wherein registering the first set of monitoring sensors comprises:
receiving information identifying a monitoring sensor, of the first set of monitoring sensors, initiating, based on receiving the information identifying the monitoring sensor, registration of the monitoring sensor in an Internet of Things (IoT) hub; associating device metadata with the monitoring sensor in the IoT hub based on initiating registration of the monitoring sensor in the IoT hub; and
Refer to at least [2168] and [2181] of Cella concerning “identifying one or more other accessible signal acquisition instruments (e.g., data collectors 12008) on an accessible network (e.g., 12010), nominating at least one of the one or more other accessible signal acquisition instruments as a logical communication hub.” Further refer to at least [3153] and [3443] of Cella.
Refer to at least [0013], [0017], and [1074] of Cella with respect to IoT, IoT sensors, and metadata.
instantiating a digital twin of the monitoring sensor based on associating the device metadata with the monitoring sensor in the IoT hub.
Refer to at least [5292] of Cella with respect to digital twins, including digital twins for associated sensors. Further refer to at least [5308], [5325], and [6432] of Cella with respect to creating digital twins (e.g., of IoT sensors).
Regarding claim 3, Cella-Singh discloses: The method of claim 1, wherein registering the first set of monitoring sensors comprises: registering a location digital twin entity of a location entity, the location digital twin entity having a set of unit digital twin entities and a set of row digital twin entities;
Refer to at least [0027] of Cella with respect to “a digital twin datastore including data collected by a set of proximity sensors disposed within an industrial environment, the data including location data indicating respective locations of a plurality of elements within the industrial environment… collect, in response to actuation of the at least one proximity sensor, updated location data for the real-world element using the at least one proximity sensor; and update the industrial-environment digital twin within the digital twin datastore to include the updated location data.” Further see at least [3125] of Cella, which discloses that, in embodiments, “the set of digital twins includes a single machine digital twin.”
and assigning a set of monitoring sensor digital twin entities to the location digital twin entity, each monitoring sensor digital twin entity, of the set of monitoring sensor digital twins, being associated with at least one of a unit digital twin entity, of the set of unit digital twin entities, or a row digital twin entity, of the set of row digital twin entities.
Refer to at least [5417] of Cella, which discloses that “the set of properties of a digital twin of an industrial device that may be updated by the digital twin dynamic model system 40008 using dynamic models 400100 may include the status of the device, a location of the device, the temperature(s) of a device, a trajectory of the device, identifiers of other digital twins that the digital twin of the device is embedded within, embeds, is linked to, includes, integrates with, takes input from, provides output to, and/or interacts with and the like.”
Regarding claim 4, Cella-Singh discloses: The method of claim 1, wherein receiving the first set of sensor measurements comprises: identifying a time-based trigger (e.g., [1309] and [2861] of Cella with respect to time based triggers; [0253] and [0270] of Cella concerning updating digital twins based on triggering conditions); requesting information identifying the set of monitoring sensors from an Internet of Things (IoT) hub with which a set of digital twins, of the set of monitoring sensors, is registered; generating, using a device simulator, telemetry data associated with the first set of monitoring sensors; and updating stored telemetry of the set of digital twins using the telemetry data and based on the information identifying the set of monitoring sensors.
Refer to at least [0429] of Cella concerning “monitoring an industrial setting using the Internet of Things (IoT) system having the plurality of sensors, the edge device including the processing system, and the data handling platform includes displaying, by a dashboard, the digital twin to a user of the IoT system; and updating, by the data handling platform, the digital twin based on sensor kit packets received subsequent to generation of the digital twin such that the displayed digital twin includes a substantially real-time digital replica of said at least one industrial component of said industrial setting.”
Regarding claim 5, Cella-Singh discloses: The method of claim 1, further comprising: receiving, by the device, based on transmitting the first set of alerts, information indicating completion of the event; storing, by the device, data associated with the completion of the event based on receiving the information indicating the completion of the event;
Refer to at least [0508]-[0509], [3051], [3117]of Cella with respect to the ledger having service activity and monitored information recorded.
and deleting, by the device, one or more digital twin entities associated with the event based on storing the data associated with the completion of the event.
Refer to at least [2285] of Cella with respect to deleting any aspect of the expert system “in response to updated information learned by the system, provided by a user or operator, provided by the machine learning algorithm 12248, information from external data 12246 and/or from offset systems.” Further see at least [6409] of Cella with respect to the digital twins as aspects of the expert system.
Regarding claim 6, Cella-Singh discloses: The method of claim 1, further comprising: receiving, by the device, based on transmitting the first set of alerts, information indicating a tracking update, of the set of tracking updates, wherein the tracking update identifies a new entity associated with the entity; and providing output identifying the tracking update based on receiving the information identifying the tracking update; and
Refer to at least [1728] and [1732] of Cella, where a route change may include “coordinated sampling of similar sensors on near-by devices).” Further see at least [6166]-[6169] of Cella with respect to changing sensor input to a similar sensor in a different location for a distinct component.
wherein registering the set of attributes in the distributed ledger comprises: registering the tracking update in the distributed ledger.
Refer to at least [0514]-[0515], [3051], and [3117] of Cella with respect to registering sensor information to the ledger.
Regarding independent claim 8, it is substantially similar to elements of independent claim 1 above, and is therefore likewise rejected. Where independent claim 8 further recites “registering… anonymized data” and transmitting a second set of alerts “based on registering the anonymized data,” refer to at least [2291] of Cella disclosing “instructions to encrypt data corresponding to at least a portion of the number of sensor values sent over the network… providing instructions to deliver data corresponding to at least a portion of the number of sensor values to a distributed ledger.” Further, [3029] of Cella states that “the distributed ledger module 29030 may encrypt the content within the block, so that the content may not be read by unauthorized devices.”
Regarding claim 9, Cella-Singh discloses: The method of claim 8, wherein generating the prediction for the event comprises: normalizing the set of sensor measurements to generate a set of normalized sensor measurements;
Refer to at least [0418], [1835], and [3023] of Cella with respect to normalizing the sensor data.
aggregating the set of normalized sensor measurements into a set of time increments;
Refer to at least [1835] of Cella with respect to aggregating the normalized sensor data; [3021] of Cella concerning aggregation over a period of time.
transforming one or more normalized sensor measurements, of the set of normalized sensor measurements and associated with a time increment of the set of time increments, into a transformed format; and
Refer to at least [3064] of Cella stating that “the edge device 28704 may normalize and/or transform the sensor data into a media-frame compliant format.”
generating the prediction using the one or more normalized sensor measurements in the transformed format.
Refer to at least [5143], [5145], and [5155] of Cella with respect to predictions using normalized data. Further refer to at least [2150] of Cella stating that “data from the current data collector(s) may not accurately predict the state or metric of operation of the system, thus, the self-organization functionality may begin to iterate to determine if a new data collector, type of sensed data, format of sensed data, etc. is better at predicting a state or metric.”
Regarding claim 10, Cella-Singh discloses: The method of claim 8, further comprising: receiving a request associated with the entity; accessing a first entity database to obtain data associated with the entity based on receiving the request; communicating with a second entity database to match the data associated with the entity to a record in the second entity database; and storing the data associated with the entity in the second entity database based on matching the data to the record; and
Refer to at least the abstract of Cella, which discloses “receiving a request for one or more digital twins; retrieving the one or more digital twins required to fulfill the request from a digital twin datastore; retrieving one or more dynamic models corresponding to one or more properties that are depicted in the one or more digital twins indicated by the request.”
wherein registering the first set of monitoring sensors comprises: associated the first set of monitoring sensors with the entity based on storing the data associated with the entity in the second entity database.
Refer to at least the abstract of Cella, which discloses “selecting data sources from a set of available data sources based on the one or more inputs of the one or more dynamic models; obtaining data from selected data sources.”
Regarding claim 11, it is rejected for substantially the same reasons as claim 8 above (i.e., the citations concerning the alert).
Regarding claim 12, Cella-Singh discloses: The method of claim 8, further comprising: generating, using a framework, a set of synthetic entities; and
Refer to at least [5292], [5308], [5325], and [6432] of Cella with respect to generating digital twins.
wherein generating the prediction comprises: generating the prediction based on data associated with the set of synthetic entities.
Refer to at least [0032] and [0048] of Cella with respect to generating predictions based on data associated with the digital twins.
Regarding claim 13, Cella-Singh discloses: The method of claim 8, wherein generating the prediction comprises: predicting one or more interventions for the entity based on the other events associated with the other entities; and automatically causing one or more response actions associated with the one or more interventions.
Refer to at least [0383] and [0459]-[0460] of Cella with respect to determining a mitigating action from a plurality of potential actions based on the results of a prediction.
Regarding claim 21, Cella-Singh discloses: The method of claim 2, wherein based on instantiating the digital twin of the monitoring sensor, the device is configured to simulate the monitoring sensor and generate data for the prediction of the event based on the simulated monitoring sensor.
Refer to at least [5292] of Cella digital twins of associated sensors; [5379], and [5383] of Cella with respect to alerts being based on the digital twin sensor data.
Regarding independent claim 22, it is substantially similar to independent claim 1 above, and is therefore likewise rejected.
Regarding claims 23-27, they are substantially similar to claims 2-6 and 21 above, and are therefore likewise rejected.
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 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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/V.S/Examiner, Art Unit 2432
/SYED A ZAIDI/Primary Examiner, Art Unit 2432
Prosecution Insights