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
Applicant’s Amendments, filed October 30, 2025 have been entered. Claims 1, 3, 14 and 18 have been amended, claims 2 and 19 are canceled and claims 1, 3-18, and 20-21 are currently pending.
Response to Arguments
Applicant's arguments filed October 20, 2025, regarding the 35 U.S.C. 103 rejections of claims 1, 3-18, and 20-21 have been fully considered but they are not persuasive. Applicant argues that cited prior art Weikel et al. (Patent No. US 11,818,409 B1, hereinafter “Weikel”) has a different technological context than claim 1 because the content preferences in Weikel do not control a smart device like settings do (Remarks pp. 14-15). In response, examiner respectfully submits that the broadest reasonable interpretation of the content preferences disclosed in Weikel includes settings for a device (see Weikel Col. 1 lines 6-21, where an Internet router may be configured with certain user preferences to block certain webpages or addresses).
Applicant further argues that the NFT in Weikel is minted only if no NFT has been previously minted for an associated user, while the Applicant mints an NFT any time there has been a request to a smart device, regardless of whether an NFT has been previously minted (Remarks pp. 14-15). In response, examiner respectfully submits that MPEP 2145X.D. provides that a prior art’s mere disclosure of more than one alternative does not constitute a teaching away from any particular alternative because such disclosure does not criticize, discredit, or otherwise discourage the solution claimed. Here, Weikel teaches minting an NFT and the mere disclosure of minting the NFT only if no NFT has been previously minted for an associated user does not teach away from the claimed invention.
Applicant’s arguments, see Remarks pp. 8-14, filed October 30, 2025 with respect to the 35 U.S.C. 101 rejections of claims 1, 3-18, and 20-21 have been fully considered and are persuasive. The 35 U.S.C. 101 rejections of claims 1, 3-18, and 20-21 have been withdrawn.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-18, 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Taivalsaari et al. (Pub. No. US 2021/0011710 A1, hereinafter “Taivalsaari”) in view of Guy.
Regarding claim 1, Taivalsaari teaches:
receiving, via one or more processors, and from a reference smart device, an indication of the data and/or settings of the reference smart device (Taivalsaari – in Fig. 2, a smart contract with information of a number of targeted devices to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices, such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051].)
(i) a unique identification of the smart device, and (ii) the received data and/or settings of the smart device (Taivalsaari – the smart contract may comprise parameters for controlling the update in the targeted devices. The update initiator may include in the smart contract one or more of: an address of the update package, in case of configuration update, the updated configuration information, information about a threshold number of devices that need to be ready to perform the update or that need to perform the update (i.e. received data and/or settings), such as a threshold number and/or identification information of the devices (i.e. identification), identifiers of the number of targeted devices that need to perform the update, and type of targeted device(s) and communication method supported by the targeted device(s), such as M2M, NB-IoT [0069-0074]. The update procedure may thus be controlled on the bases of and/or by the smart contract stored in the distributed ledger (i.e. data storage area).)
receiving, via the one or more processors, a request to restore a target smart device using the data and/or settings (Taivalsaari – an indication to the distributed ledger on performance of the update by the number of targeted devices is detected. An indication of being ready to perform the update may be received from each targeted device [0051].)
and in response to receiving the request: retrieving, via the one or more processors, the data and/or settings from the data storage area (Taivalsaari – after indications from all or appropriate number of targeted device are received to the distributed ledger, the indication of the number of targeted devices may be considered to be received and detected by the apparatus implementing the method [0052].)
and sending, via the one or more processors, the data and/or settings to the target smart device (Taivalsaari – an indication to the distributed ledger on performance of the update by the number of targeted devices is received. Thus, the distributed ledger may be updated to indicate completion of the performance of the update to the number of targeted devices [0052].)
Taivalsaari does not appear to teach:
minting, in response to receiving the data and/or settings of the reference smart device, via the one or more processors, a non-fungible token (NFT),
wherein the minted NFT references a location of a data storage area; storing, via the one or more processors, at the location of the storage area rather than at the NFT:
adding, via the one or more processors, the NFT to a digital wallet
associated with the NFT
referenced by the NFT
However, Weikel teaches:
minting, in response to receiving the data and/or settings of the reference smart device, via the one or more processors, a non-fungible token (NFT), (Weikel – the computing system may determine, upon receiving a request that includes content preferences from a user device (i.e. receiving data and/or settings), whether a non-fungible token associated with the user exists or is being stored on the blockchain. Upon a determination that one such non-fungible token for the user does not exist, the computing system may query an on-chain program on the blockchain to generate (i.e. mint) a non-fungible token for the user. In doing so, the computing system may transmit an indication of one or more on-chain addresses, keys, or other mechanisms for verification and access associated with the newly generated (i.e. minted) non-fungible token to the user device [Col. 9 lines 63-67, Col. 10 lines 1-12].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Taivalsaari and Weikel before them, to modify the system of Taivalsaari with the teachings of Weikel, as indicated above. One would have been motivated to make such a modification to preserve user preferences across different device (Weikel [Col. 1 lines 6-21, Col. 2 lines 53-58, Col. 6 lines 57-60]).
Taivalsaari modified by Weikel does not appear to teach:
wherein the minted NFT references a location of a data storage area; storing, via the one or more processors, at the location of the storage area rather than at the NFT:
adding, via the one or more processors, the NFT to a digital wallet
associated with the NFT
referenced by the NFT
However, Guy teaches:
wherein the minted NFT references a location of a data storage area; storing, via the one or more processors, at the location of the storage area rather than at the NFT: (Guy – an NFT is a unique, irreplaceable token that can exist within a smart contract. NFT’s are generated, or “minted” through creation of these smart contacts [0073-0074]. Referring to Fig. 6, NFT creator 602 may be any entity that mints NFTs for placement on a blockchain. This process may involve creation of a smart contract specifying NFT 606A therein, associating NFT 606A with NFT-related metadata 606B, and taking steps to place NFT 606A on blockchain 610 and place NFT-related metadata 606B in off-chain digital storage 604. NFT-related metadata may include the actual content and/or description of the content referred to by NFT 606A. Off-chain digital content 604 may be an external or remote database that stores NFT-related metadata 604B as well as other metadata. Blockchain 610 may be any type of blockchain network that supports NFTs, e.g., via smart contracts. As shown, NFT may be stored in blockchain 610 and may contain a reference 608 to NFT-related metadata 606B as stored in off-chain digital storage 604 [0121-0124].)
adding, via the one or more processors, the NFT to a digital wallet (Guy – an NFT can be minted and submitted to any blockchain with additional metadata explicitly defining, or linking to information about, the value of the NFT. This value would be held by the NFT creator, and on completing the rules defined I the contract (i.e., proof of burn or transfer the NFT to a specified digital wallet), the NFT’s holder is awarded the value defined previously [0242].)
associated with the NFT (Guy – an NFT is a unique, irreplaceable token that can exist within a smart contract. NFT’s are generated, or “minted” through creation of these smart contacts [0073-0074]. Referring to Fig. 6, NFT creator 602 may be any entity that mints NFTs for placement on a blockchain. This process may involve creation of a smart contract specifying NFT 606A therein, associating NFT 606A with NFT-related metadata 606B, and taking steps to place NFT 606A on blockchain 610 and place NFT-related metadata 606B in off-chain digital storage 604. NFT-related metadata may include the actual content and/or description of the content referred to by NFT 606A. Off-chain digital content 604 may be an external or remote database that stores NFT-related metadata 604B as well as other metadata. Blockchain 610 may be any type of blockchain network that supports NFTs, e.g., via smart contracts. As shown, NFT may be stored in blockchain 610 and may contain a reference 608 to NFT-related metadata 606B as stored in off-chain digital storage 604 [0121-0124].)
referenced by the NFT (Guy – an NFT is a unique, irreplaceable token that can exist within a smart contract. NFT’s are generated, or “minted” through creation of these smart contacts [0073-0074]. Referring to Fig. 6, NFT creator 602 may be any entity that mints NFTs for placement on a blockchain. This process may involve creation of a smart contract specifying NFT 606A therein, associating NFT 606A with NFT-related metadata 606B, and taking steps to place NFT 606A on blockchain 610 and place NFT-related metadata 606B in off-chain digital storage 604. NFT-related metadata may include the actual content and/or description of the content referred to by NFT 606A. Off-chain digital content 604 may be an external or remote database that stores NFT-related metadata 604B as well as other metadata. Blockchain 610 may be any type of blockchain network that supports NFTs, e.g., via smart contracts. As shown, NFT may be stored in blockchain 610 and may contain a reference 608 to NFT-related metadata 606B as stored in off-chain digital storage 604 [0121-0124].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Taivalsaari, Weikel and Guy before them, to modify the system of Taivalsaari and Weikel with the teachings of Guy, as indicated above. One would have been motivated to make such a modification to enable access to a feature that the feature is logically de-coupled from users and software applications, and thus can be transferred between users, and to enable software to be used more efficiently (Guy [0010]).
Claims 14 and 18 correspond to claim 1 and are rejected accordingly.
Regarding claim 3, Taivalsaari teaches:
wherein: the reference smart device is a first reference smart device included in a group of smart devices including a second reference smart device; and the computer-implemented method further comprises: receiving, via one or more processors, and from the second reference smart device, data and/or settings of the second reference smart device (Taivalsaari – in Fig. 2, a smart contract with information of a number of targeted devices (i.e. includes first and second reference smart devices) to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices , such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051].)
and the data storage area further stores: (i) a unique identification of the second reference smart device, and (ii) the received data and/or settings of the second reference smart device (Taivalsaari – the smart contract may comprise parameters for controlling the update in the targeted devices. The update initiator may include in the smart contract one or more of: an address of the update package, in case of configuration update, the updated configuration information, information about a threshold number of devices that need to be ready to perform the update or that need to perform the update (i.e. received data and/or settings), such as a threshold number and/or identification information of the devices (i.e. identification), identifiers of the number of targeted devices that need to perform the update, and type of targeted device(s) and communication method supported by the targeted device(s), such as M2M, NB-IoT [0069-0074].)
Regarding claim 4, Taivalsaari teaches:
wherein the first reference smart device comprises a smart washer, and the second reference smart device comprises a smart dryer (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update [0046]. In Fig. 2, a smart contract with information of a number of targeted devices (i.e. includes first and second reference smart devices) to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices , such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051]. Examiner interprets that the target devices teach a smart washer and smart dryer, see [0003] where the Internet of Things facilitates further spreading of computational devices.)
Regarding claim 5, Taivalsaari teaches:
wherein: (i) the reference smart device comprises a smart thermostat, (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update [0046]. In Fig. 2, a smart contract with information of a number of targeted devices (i.e. the reference smart device) to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices , such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051]. Examiner interprets that the target device teaches a smart thermostat, see [0003] where the Internet of Things facilitates further spreading of computational devices.)
and (ii) the data and/or settings include a schedule of temperatures (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update [0046]. The smart contract may comprise parameters for controlling the update in the targeted devices. The update initiator may include in the smart contract one or more of: an address of the update package, in case of configuration update, the updated configuration information, information about a threshold number of devices that need to be ready to perform the update or that need to perform the update (i.e. received data and/or settings), such as a threshold number and/or identification information of the devices, identifiers of the number of targeted devices that need to perform the update, and type of targeted device(s) and communication method supported by the targeted device(s), such as M2M, NB-IoT [0069-0074].)
Regarding claim 6, Taivalsaari teaches:
wherein: (i) the reference smart device comprises an appliance, (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update [0046]. In Fig. 2, a smart contract with information of a number of targeted devices (i.e. the reference smart device) to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices , such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051]. Examiner interprets that the target device teaches an appliance, see [0003] where the Internet of Things facilitates further spreading of computational devices.)
and (ii) the data and/or settings include a temperature setting of the appliance (Taivalsaari – the smart contract may comprise parameters for controlling the update in the targeted devices. The update initiator may include in the smart contract one or more of: an address of the update package, in case of configuration update, the updated configuration information, information about a threshold number of devices that need to be ready to perform the update or that need to perform the update (i.e. received data and/or settings), such as a threshold number and/or identification information of the devices, identifiers of the number of targeted devices that need to perform the update, and type of targeted device(s) and communication method supported by the targeted device(s), such as M2M, NB-IoT [0069-0074].)
Regarding claim 7, Taivalsaari teaches:
at the direction of a smart contract deployed to a distributed ledger (Taivalsaari – a smart contract with information of a number of targeted devices to perform an update is generate in Fig. 2, 200. The smart contract is provided for a distributed ledger for the number of targeted devices, such as for distributed ledger 40 and for nodes 20, 22, 24 [0050].)
Taivalsaari modified by Weikel does not appear to teach:
wherein minting the NFT comprises: minting, via the one or more processors, the NFT
However, Guy teaches:
wherein minting the NFT comprises: minting, via the one or more processors, the NFT (Guy – an NFT is a unique, irreplaceable token that can exist within a smart contract. NFT’s are generated, or “minted” through creation of these smart contacts [0073-0074]. Referring to Fig. 6, NFT creator 602 may be any entity that mints NFTs for placement on a blockchain. This process may involve creation of a smart contract specifying NFT 606A therein, associating NFT 606A with NFT-related metadata 606B, and taking steps to place NFT 606A on blockchain 610 and place NFT-related metadata 606B in off-chain digital storage 604. NFT-related metadata may include the actual content and/or description of the content referred to by NFT 606A. Off-chain digital content 604 may be an external or remote database that stores NFT-related metadata 604B as well as other metadata. Blockchain 610 may be any type of blockchain network that supports NFTs, e.g., via smart contracts. As shown, NFT may be stored in blockchain 610 and may contain a reference 608 to NFT-related metadata 606B as stored in off-chain digital storage 604 [0121-0124].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Taivalsaari, Weikel and Guy before them, to modify the system of Taivalsaari, Weiekl and Guy with the teachings of Guy, as indicated above. One would have been motivated to make such a modification to enable access to a feature that the feature is logically de-coupled from users and software applications, and thus can be transferred between users, and to enable software to be used more efficiently (Guy [0010]).
Regarding claim 8, Taivalsaari teaches:
wherein: the smart contract is configured to initiate a request to backup data and/or settings associated with the reference smart device in response to a temporal trigger event (Taivalsaari – the smart contract may comprise logic and execute or trigger transactions associated with the upgrade procedure [0085]. The smart contract may comprise timing information indicative of at least a time by or at which the update needs to be carried out [0020, 0077-0081]. The distributed ledger may comprise history (i.e. backup data and/or settings) of all changes, and in case of failure might also help determine which was the configuration that worked – and thus help returning to working configuration [0112].)
Regarding claim 9, Taivalsaari teaches:
wherein: the indication of the data and/or settings of the smart device is a first indication; and the method further comprises: detecting, via the one or more processor, temporal trigger event associated with the smart contract (Taivalsaari – in Fig. 2, a smart contract with information of a number of targeted devices to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices, such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051].)
and transmitting, via the one or more processors and to the reference smart device, a request to backup data and/or setting (Taivalsaari – the smart contract may comprise logic and execute or trigger transactions associated with the upgrade procedure [0085]. The smart contract may comprise timing information indicative of at least a time by or at which the update needs to be carried out [0020, 0077-0081]. The distributed ledger may comprise history (i.e. backup data and/or settings) of all changes, and in case of failure might also help determine which was the configuration that worked – and thus help returning to working configuration [0112].)
Regarding claim 10, Taivalsaari teaches:
wherein the method further comprises: receiving, via the one or more processors, new data and/or settings of the reference smart device (Taivalsaari – in Fig. 2, a smart contract with information of a number of targeted devices to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices, such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051]. Examiner interprets that the update discloses new data and/or settings.)
and overwriting, via the one or more processors, the data and/or settings of the reference smart device with the new data and/or settings of the reference smart device in the data storage area (Taivalsaari – an indication to the distributed ledger on performance of the update by the number of targeted devices is received. Thus, the distributed ledger may be updated to indicate completion of the performance of the update to the number of targeted devices [0052].)
Regarding claim 11, Taivalsaari teaches:
wherein the data and/or settings are stored in a first location within the data storage area, and wherein the method further comprises: receiving, via the one or more processors, new data and/or settings of the reference smart device, wherein the data storage area stores the new data and/or settings of the reference smart device in a second location within the data storage area (Taivalsaari – the smart contract may comprise logic and execute or trigger transactions associated with the upgrade procedure [0085]. The smart contract may comprise timing information indicative of at least a time by or at which the update needs to be carried out [0020, 0077-0081]. The distributed ledger may comprise history (i.e. backup data and/or settings) of all changes, and in case of failure might also help determine which was the configuration that worked – and thus help returning to working configuration [0112]. The distributed ledger is a blockchain ledger, and the smart contract is provided and updated by blockchain transactions [0028]. Examiner interprets that the first location is a particular block within the blockchain data storage area, and that the update (i.e. new data) is stored in another block (i.e. second location).)
Regarding claim 12, Taivalsaari teaches:
wherein the request is received from the target smart device (Taivalsaari – an indication to the distributed ledger on performance of the update by the number of targeted devices is detected. An indication of being ready to perform the update may be received from each targeted device [0051].)
Regarding claim 13, Taivalsaari teaches:
detecting, via the one or more processors, that the reference smart device is no longer functioning while powered on; in response to the detection, searching, via the one or more processors, for the target smart device, wherein the target smart device is: (i) of a same type as the reference smart device, and/or (ii) on a same property as the reference smart device; and upon finding the target smart device, prompt, via the one or more processors, a user to restore the data and/or settings to the target smart device (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update, such as devices 24, 26a-c (i.e. same type and same property) [0046]. The targeted devices are configured to initiate and carry out the update according to the parameters. The targeted device may modify its radio activation settings in accordance with the smart contract timing information, wherein the power consumption can be reduced further. If the targeted device is not a node of the distributed network, such as an IoT device, such targeted device 26a-c may be configured by a node 24 in accordance of the timing information. For example, such targeted device 26a-c may be instructed and configured by node 24 to activate its radio and connect to node 24 in accordance with the timing information [0083].)
Regarding claim 15, Taivalsaari teaches:
wherein the reference smart device comprises a kitchen appliance, or a smart thermostat (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update [0046]. In Fig. 2, a smart contract with information of a number of targeted devices (i.e. the reference smart device) to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices , such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051]. Examiner interprets that the target device teaches a smart thermostat, see [0003] where the Internet of Things facilitates further spreading of computational devices.)
Claim 20 corresponds to claim 15 and is rejected accordingly.
Regarding claim 16, Taivalsaari teaches:
wherein: (i) the reference smart device comprises a smart thermostat, and (ii) the data and/or settings include a schedule of temperatures (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update [0046]. The smart contract may comprise parameters for controlling the update in the targeted devices. The update initiator may include in the smart contract one or more of: an address of the update package, in case of configuration update, the updated configuration information, information about a threshold number of devices that need to be ready to perform the update or that need to perform the update (i.e. received data and/or settings), such as a threshold number and/or identification information of the devices, identifiers of the number of targeted devices that need to perform the update, and type of targeted device(s) and communication method supported by the targeted device(s), such as M2M, NB-IoT [0069-0074].)
Regarding claim 17, Taivalsaari teaches:
wherein: (i) the reference smart device comprises an appliance, and (ii) the data and/or settings include a temperature setting of the appliance (Taivalsaari – the system comprises one or more IoT devices configurable on the basis of at least a portion of the update [0046]. The smart contract may comprise parameters for controlling the update in the targeted devices. The update initiator may include in the smart contract one or more of: an address of the update package, in case of configuration update, the updated configuration information, information about a threshold number of devices that need to be ready to perform the update or that need to perform the update (i.e. received data and/or settings), such as a threshold number and/or identification information of the devices, identifiers of the number of targeted devices that need to perform the update, and type of targeted device(s) and communication method supported by the targeted device(s), such as M2M, NB-IoT [0069-0074].)
Regarding claim 21, Taivalsaari teaches:
wherein the reference smart device is a different smart device than the target smart device (Taivalsaari – in Fig. 2, a smart contract with information of a number of targeted devices to perform an update is generated. The smart contract is provided for a distributed ledger for the number of targeted devices, such as for distributed ledger 40 and for nodes 20, 22, 24. An indication to the distributed ledger on readiness to perform the update by the number of targeted devices is detected. An indication of being ready to perform the updated may be received from each targeted device [0050-0051]. Examiner interprets that information on node 20 in the generated smart contract discloses a reference smart device, and indication of being ready to perform the update may be received from a node 22, i.e. a target smart device.)
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 RANJIT P DORAISWAMY whose telephone number is (571)270-5759. The examiner can normally be reached Monday-Friday 9:00 AM - 5:00 PM.
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, Sanjiv Shah can be reached at (571) 272-4098. 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.
/RANJIT P DORAISWAMY/Examiner, Art Unit 2166
/SANJIV SHAH/Supervisory Patent Examiner, Art Unit 2166