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 Arguments
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/22/2026 has been entered.
The 35 USC 101 rejection has been withdrawn in view of the applicant’s arguments and the claims as amended.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 4, 5, 7 and 11-12 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jordan II, et al. (US Pat. No. 10,282,788, herein after “Jordan”).
As per claims 1, 11 and 12, Jordan discloses a system and method for connecting a plurality of smart devices in a home. The smart devices are being monitored for a malfunction of one or more appliances for insurance purposes and when a repair or replacement of the appliances is needed. Applicant is directed to the abstract of Jordan. Accordingly, Jordan teaches or discloses all the claimed limitations. Particularly, Jordan teaches or discloses:
A system, comprising: a processor (see figures 1 and 2 of Jordan) configured to:
receive from a user device a request to execute a conditional interaction with respect to an operable device in response to a determination that the operable device is at least partially inoperable (as Jordan teaches an operative device previously services is needed to be additionally serviced or repaired. See column 5 lines 9-29 of Jordan);
determine, based at least in part on the determination that the operable device is at least partially inoperable, whether the operable device is at least partially inoperable due to a malfunction having a likelihood of occurrence, wherein the likelihood of occurrence of the malfunction is calculated based at least in part on one or more of a type of the operable device, a usage rate of the operable device, an operational environment of the operable device, a maintenance status of the operable device, or a failure rate of the operable device (see column 5, lines 9-29 of Jordan; and
in response to determining that the operable device is at least partially inoperable due to the malfunction having the likelihood of occurrence:
compare the likelihood of occurrence of the malfunction to a predetermined threshold likelihood of occurrence of the malfunction (see column 5, lines 9-29 of Jordan);
determine, based at least in part on the comparison, whether the likelihood of occurrence of the malfunction is less than or equal to the predetermined threshold likelihood of occurrence of the malfunction, in response to determining that the likelihood of occurrence of the malfunction is less than or equal to the predetermined threshold likelihood of occurrence of the malfunction, approve the execution of the conditional interaction with respect to the operable device (see column 11, line 25 to column 12, line 25 of Jordan); and
execute, based at least in part on the approval, the conditional interaction with respect to the operable device to satisfy the request (see column 13, lines 18-34 and column 23, lines 14-63 of Jordan.
As per claim 4, Jordan discloses wherein the processor is further configured to:
in response to determining that the likelihood of occurrence of the malfunction is greater than the predetermined threshold likelihood of occurrence of the malfunction, reject the execution of the conditional interaction with respect to the operable device. See column 5, lines 9-29 of Jordan.
As per claim 5, Jordan discloses wherein the processor is further configured to determine that the operable device is at least partially inoperable due to the malfunction having the likelihood of occurrence based at least in part on a record of maintenance work performed on the operable device. See column 5, lines 9-29 and column 19, lines 56-67 of Jordan.
As per claim 7, Jordan discloses wherein the processor is further configured to calculate an accuracy of the likelihood of occurrence of the malfunction. See column 10, lines 38-63 and column 11, lines 25-42 of Jordan.
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.
Claim(s) 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jordan et al. (US Pat. No. 10,282,788, herein after “Jordan)”.
As per claim 9, the teachings of Jordan are discussed above.
Jordan does not explicitly state:
“the malfunction comprises a power transmission line, and the likelihood of occurrence of the malfunction incident is based on a prediction of a timing at which a tree comes into contact with the power transmission line”. Jordan discloses monitoring all aspects including appliances and power data in a home. See the abstract of Jordan. Power plants usually supply power to distant customers of a house using cable lines or transmission line on many poles. Trees usually fall on transmission lines due to bad weather and dangerous wind speed.
The malfunction comprises a power failure and the likelihood of occurrence of the malfunction being based on a prediction of a power demand would have been obvious to one of ordinary skill in the art to note in the system of Jordan at the effective filing date of the invention in order to determine the likelihood of potential accidents related to bad weather so as to properly assess a damage and refer repair.
As per claim 10, the teachings of Jordan are discussed above. Jordan does not explicitly teach or disclose the claimed feature. However, it should be noted that at times, most houses may experience a power failure for at least due to bad weather, and thus a power demand would be in effect.
As such, it would have been obvious to one of ordinary skill in the art to note that an incident may be a power failure, and the predicted probability of occurrence of the incident would be based on a prediction of a power demand”. The motivation to take account of this notion and to attribute this notion in the system and method of Jordan would have been obvious to one of ordinary skill in the art at the effective filing date of the invention in order to be informed and determined on when/how to react and/or prevent certain issues or catastrophic issues related to a power failure.
Claim(s) 3 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jordan et al. (US Pat. No. 10,282,788, herein after “Jordan”) in view of Oehler et al (US 20220138700 A1)
As per claim 3, the teachings of Jordan are discussed above. Jordan teaches storing and retrieving repairs information on a storage device. See column 21, lines 15-64 of Jordan. Jordan does not explicitly state “the processor is further configured to retrieve the calculated likelihood of occurrence of the malfunction from one or more blockchain distributed ledgers on which the calculated likelihood of occurrence of the malfunction is recorded”.
As per this limitation, storing or recording data on a blockchain distributed ledger is old and well-practiced in the art at the effective filing date of the invention.
Oehler et al disclose a system and method for determining a performance level of a transport based on the obtained data, dynamically revising, by the transport, the performance level based on a current use of the transport, and determining, by the transport, a next use of the transport, based on the dynamically revised performance level. Accordingly, Ohler et al further teach storing vehicle data and maintenance data related to a transport vehicle ono a distributed ledger as Ohler et al state:
“[0055] Example embodiments provide a service to a particular vehicle and/or a user profile that is applied to the vehicle. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. The vehicle may require service at certain intervals and the service needs may require authorization prior to permitting the services to be received. Also, service centers may offer services to vehicles in a nearby area based on the vehicle's current route plan and a relative level of service requirements (e.g., immediate, severe, intermediate, minor, etc.). The vehicle needs may be monitored via one or more vehicle and/or road sensors or cameras, which report sensed data to a central controller computer device in and/or apart from the vehicle. This data is forwarded to a management server for review and action. A sensor may be located on one or more of the interior of the transport, the exterior of the transport, on a fixed object apart from the transport, and on another transport proximate the transport. The sensor may also be associated with the transport's speed, the transport's braking, the transport's acceleration, fuel levels, service needs, the gear-shifting of the transport, the transport's steering, and the like. A sensor, as described herein, may also be a device, such as a wireless device in and/or proximate to the transport. Also, sensor information may be used to identify whether the vehicle is operating safely and whether an occupant has engaged in any unexpected vehicle conditions, such as during a vehicle access and/or utilization period. Vehicle information collected before, during and/or after a vehicle's operation may be identified and stored in a transaction on a shared/distributed ledger, which may be generated and committed to the immutable ledger as determined by a permission granting consortium, and thus in a “decentralized” manner, such as via a blockchain membership group.”.
“[0183] FIG. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to example embodiments. Referring to FIG. 6C, the example configuration 660 provides for the vehicle 662, the user device 664 and a server 666 sharing information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity inquiring with a vehicle service provider to share user profile rating information in the event that a known and established user profile is attempting to rent a vehicle with an established rated profile. The server 666 may be receiving and processing data related to a vehicle's service requirements. As the service events occur, such as the vehicle sensor data indicates a need for fuel/charge, a maintenance service, etc., a smart contract may be used to invoke rules, thresholds, sensor information gathering, etc., which may be used to invoke the vehicle service event. The blockchain transaction data 670 is saved for each transaction, such as the access event, the subsequent updates to a vehicle's service status, event updates, etc. The transactions may include the parties, the requirements (e.g., 18 years of age, service eligible candidate, valid driver's license, etc.), compensation levels, the distance traveled during the event, the registered recipients permitted to access the event and host a vehicle service, rights/permissions, sensor data retrieved during the vehicle event operation to log details of the next service event and identify a vehicle's condition status, and thresholds used to make determinations about whether the service event was completed and whether the vehicle's condition status has changed”.
It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to incorporate a distributed ledger to store the status and repair data in the system of Jordan as taught by Oehler et al in order to obtain a more secure database.
As per claim 6, the teachings of Jordan are discussed above. Jordan teaches storing and retrieving repairs information on a storage device. See column 21, lines 15-64 of Jordan. Jordan does not explicitly state “the record of maintenance work is maintained on one or more blockchain distributed ledgers”. As per this limitation, storing or recording data on a blockchain distributed ledger is old and well-practiced in the art at the effective filing date of the invention.
Oehler et al disclose a system and method for determining a performance level of the transport based on the obtained data, dynamically revising, by the transport, the performance level based on a current use of the transport, and determining, by the transport, a next use of the transport, based on the dynamically revised performance level. Accordingly, Ohler et al further teach storing vehicle data and maintenance data related to a transport vehicle ono a distributed ledger as Ohler et al state:
“[0055] Example embodiments provide a service to a particular vehicle and/or a user profile that is applied to the vehicle. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. The vehicle may require service at certain intervals and the service needs may require authorization prior to permitting the services to be received. Also, service centers may offer services to vehicles in a nearby area based on the vehicle's current route plan and a relative level of service requirements (e.g., immediate, severe, intermediate, minor, etc.). The vehicle needs may be monitored via one or more vehicle and/or road sensors or cameras, which report sensed data to a central controller computer device in and/or apart from the vehicle. This data is forwarded to a management server for review and action. A sensor may be located on one or more of the interior of the transport, the exterior of the transport, on a fixed object apart from the transport, and on another transport proximate the transport. The sensor may also be associated with the transport's speed, the transport's braking, the transport's acceleration, fuel levels, service needs, the gear-shifting of the transport, the transport's steering, and the like. A sensor, as described herein, may also be a device, such as a wireless device in and/or proximate to the transport. Also, sensor information may be used to identify whether the vehicle is operating safely and whether an occupant has engaged in any unexpected vehicle conditions, such as during a vehicle access and/or utilization period. Vehicle information collected before, during and/or after a vehicle's operation may be identified and stored in a transaction on a shared/distributed ledger, which may be generated and committed to the immutable ledger as determined by a permission granting consortium, and thus in a “decentralized” manner, such as via a blockchain membership group.”.
“[0183] FIG. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to example embodiments. Referring to FIG. 6C, the example configuration 660 provides for the vehicle 662, the user device 664 and a server 666 sharing information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity inquiring with a vehicle service provider to share user profile rating information in the event that a known and established user profile is attempting to rent a vehicle with an established rated profile. The server 666 may be receiving and processing data related to a vehicle's service requirements. As the service events occur, such as the vehicle sensor data indicates a need for fuel/charge, a maintenance service, etc., a smart contract may be used to invoke rules, thresholds, sensor information gathering, etc., which may be used to invoke the vehicle service event. The blockchain transaction data 670 is saved for each transaction, such as the access event, the subsequent updates to a vehicle's service status, event updates, etc. The transactions may include the parties, the requirements (e.g., 18 years of age, service eligible candidate, valid driver's license, etc.), compensation levels, the distance traveled during the event, the registered recipients permitted to access the event and host a vehicle service, rights/permissions, sensor data retrieved during the vehicle event operation to log details of the next service event and identify a vehicle's condition status, and thresholds used to make determinations about whether the service event was completed and whether the vehicle's condition status has changed”.
It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to incorporate one or more blockchain distributed ledgers to store the status and repair data in the system of Jordan as taught by Oehler et al in order to obtain a more secure database.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to FRANTZY POINVIL whose telephone number is (571)272-6797. The examiner can normally be reached M-Th 7:00AM to 5:30PM.
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, Michael Anderson can be reached at 571-270-0508. 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.
/fp/
/FRANTZY POINVIL/Primary Examiner, Art Unit 3693
Prosecution Insights