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 .
Status of Claims
This Office action is in response to the amendments filed on January 02, 2025. Claims 1, 4-8 are currently pending, with Claims 1, and 4-5 being amended, Claims 2-3 being canceled, and Claims 6-8 being newly added.
Response to Amendments
In response to Applicant’s amendments, filed January 02, 2026, the Examiner withdraws the previous 35 U.S.C. 102 and 103 rejections.
Response to Arguments
Applicant’s arguments, filed January 02, 2026, with respect to the rejections of Claims 1-5 under Lu, in view of Ropel, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made of Claims 1 and 4-8, in view of Lu, in view of Kai and Ropel.
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 and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2021/0347276 A1, to Lu (hereinafter referred to as Lu; previously of record); and in view of U.S. Patent Publication No. 2022/0169144 A1, to Kai (hereinafter referred to as Kai; newly of record).
As per Claim 1, Lu discloses the features of an information management system (e.g. Paragraphs [0034]-[0035]; where the system comprises a data collection, monitoring, validation, and distribution system) comprising:
a data management device (e.g. Paragraph [0045]; where information is stored on a centralized database for managing and maintaining data; and where data is forwarded to a management server for review and action) configured to
record management information (e.g. Paragraphs [0035], [0042], [0150]; where a distributed ledger is capable of maintaining records; and where 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) including
identification information of a power storage device (e.g. Paragraphs [0070], [0082]; where the analytics may identify when a battery needs to be replaced, and the blockchain (154) can track energy consumed by the battery, and determine when to replace a battery or when to keep charging the battery; and where an identifier of the rechargeable battery can be added to a transmission) managed by an owner (e.g. Paragraphs [0043], [0107], [0125], [0142]; where the alerts, service events, triggered conditions, etc., prompt an alert to be sent to the managing party (e.g., vehicle owner, vehicle operator, server, etc.)),
identification information of one or more users of the power storage device (e.g. Paragraphs [0076], [0101]; where the authorization module may store passwords, usernames, PIN codes, etc., for different users; and where digital keys are associated with multiple users), and
usage history information on usage history of the power storage device of each of the one or more users (e.g. Paragraphs [0128], [0130], [0142], [0152]; where the system may estimate a value of power to be used to charge the rechargeable battery over a predetermined period of time, based on historical usage patterns of the transport, a user input, etc.; and where the blockchain transactions include performing a hash of the data contents of the transactions in a current block and referencing a previous hash of a previous block; and where the system can store a user profile based on the user’s history of purchases and preferences), ‘…’
ii) power storage amount data that indicates a transition of state of charge of the power storage device (e.g. Paragraphs [0089]-[0090]; where the charging station manages the amount of energy transferred from the transport, such that there is sufficient charge remaining in the transport to arrive at a destination, and may provide energy to the transport and/or system based on future needs and priorities), and
iii) temperature data that indicates a transition of temperature of the power storage device (e.g. Paragraphs [0053], [0060], [0068], [0089]-[0090]; where the analytics may identify if the temperature is very cold or hot at a future location to determine when to build up aggregate anergy storage for the node; and where the request for recharging power may be generated by the transport’s computer in response to a predefined condition occurring at a particular point in time, such as based on weather or a detection that the charge power has fallen below a threshold); and
a server configured to read the management information recorded in the data management device (e.g. Paragraphs [0045], [0077], [0096], [0099]; where data shared and received may be stored in a database server; and where the central node may be an intermediary system, such as a server, database, cloud platform that receives requests from the plurality of nodes),
an information terminal (e.g. Paragraphs [0045], [0077], [0096], [0099]; where data shared and received may be stored in a database server; and where the central node may be an intermediary system, such as a server, database, cloud platform that receives requests from the plurality of nodes) configured to
transmit either a first transmission request or a second transmission request to the server (e.g. Paragraph [0128]; where the system can assign a first portion of critical updates in one process in the transport, and then run a second portion of non-critical updates after a period of time),
the first transmission request indicating that a traffic accident of a vehicle on which the power storage device is mounted has occurred (e.g. Paragraphs [0096]-[0097], [0099], [0105]; where the system can record changes in the condition of a rented object, such as a vehicle, to determine damage to the transport, which indicates an accident has occurred; and where the system can send data to a server by devices associated with a transport, or devices proximate to the accident), and ‘…’, wherein the server is further configured to
acquire usage history information from the data management device (e.g. Paragraphs [0034], [0070], [0150]; where the vehicle status data may be received and processed to identify vehicle/ transport status conditions, including when a battery needs to be replaced),
in response to receiving the first transmission request, generate provision information based on the usage history information of a current user of the power storage device (e.g. Paragraphs [0043], [0124], [0142]; where the system can collect data relating to the device type, manufacturer, owner, vehicle operator; and can also collect data relating to average speed, acceleration rates, safety measures taken, etc.), ‘…’, and
transmit the generated provision information to the information terminal (e.g. Paragraphs [0056]-[0058], [0142]; Figure 1; where the central node receives a request for charging power at a transport node, where the transport node may be a vehicle; and where a computer of the transport node transmits a request to the central node, and the central node may transmit a command, message, etc. instructing the power source to generate enough power to satisfy the request made by the transport node; and where the blockchain transactions may identify if requesting entities are registered to receive vehicle services, what service features are entitled/ required to be receive based on profile status of each user, and when a service event is required, data monitoring is triggered, and an alert/ request is sent to the managing party).
Lu fails to disclose the features of the usage information including i) current data that indicates a transition of current of the power storage device; and the second transmission request indicating that the traffic accident has not occurred and the power storage device has been removed from the vehicle; and in response to receiving the second transmission request, generate the provision information based on the usage history information of the current user and one or more previous users who have used the power storage device before the current user, the one or more previous users being different from the owner.
However, Kai, in a similar field of endeavor, teaches the features of the usage information including i) current data that indicates a transition of current of the power storage device.
Kai teaches a method for generating information about a user who uses a battery module, where the battery management unit (BMU, 110) determines the voltage and current measured over a predetermined time by the detachable battery (e.g. Paragraphs [0051], [0053]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to modify the transport battery recharging method of Lu, with the feature of transmitting the state of the removed battery in the system of Kai, in order to determine a consumption amount of the electrically driven vehicle discharged from the electricity accumulation part (see at least Paragraph [0053] of Kai).
Kai further teaches the features of the second transmission request indicating that the traffic accident has not occurred and the power storage device has been removed from the vehicle.
Kai teaches a method for generating information about a user who uses a battery module, where an exhausted detachable battery (100) is removed from the electrically driven vehicle (10), and the storage (140) provided on the detachable battery (100) may store a use aspect (a use state, a use history) associated with the vehicle, such as traveling history information, electric power consumption amount, a battery SOC, battery state information (i.e. normal operation of the battery, or no accident has occurred), and when the detachable battery is returned to the battery accommodating part on the charging module, the battery ID is read and transmitted to the management server (300)) (e.g. Paragraphs [0056], [0062], [0070], [0113]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to modify the transport battery recharging method of Lu, with the feature of transmitting the state of the removed battery in the system of Kai, in order to identify the user of the detachable battery and assign the battery ID of the new battery to the user (see at least Paragraph [0062] of Kai).
Kai further teaches the features of in response to receiving the second transmission request, generate the provision information based on the usage history information of the current user and one or more previous users who have used the power storage device before the current user, the one or more previous users being different from the owner.
Kai teaches a method for generating information about a user who uses a battery module, where the battery management unit (BMU, 110) stores history information related to the electrically driven vehicle (10) to which the battery (100) currently used by a user is attached and information related to the electrically driven vehicle (10) to which the battery (100) was used by a user in the past is acquired as personal information, and the accumulated usage history of a plurality of users is acquired (e.g. Paragraphs [0052], [0119], [0165]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to modify the transport battery recharging method of Lu, with the feature of determining the record of users of the battery in the system of Kai, in order to measure the battery state information over time (see at least Paragraphs [0056], [0078] of Kai).
As per Claim 6, Lu, in view of Kai, teaches the features of Claim 1, and Lu further discloses the features of further comprising
a plurality of data storing devices respectively (e.g. Paragraphs [0039], [0165]; where the blockchain may be stored in a peer node file system (e.g. local, attached storage, cloud, etc.)) configured to
acquire the usage history information of the power storage device (e.g. Paragraphs [0128], [0130], [0142], [0152]; where the system may estimate a value of power to be used to charge the rechargeable battery over a predetermined period of time, based on historical usage patterns of the transport, a user input, etc.; and where the blockchain transactions include performing a hash of the data contents of the transactions in a current block and referencing a previous hash of a previous block; and where the system can store a user profile based on the user’s history of purchases and preferences),
generate a hash value of the usage history information using a hash function (e.g. Paragraphs [0128], [0130], [0142], [0152]; where the system may estimate a value of power to be used to charge the rechargeable battery over a predetermined period of time, based on historical usage patterns of the transport, a user input, etc.; and where the blockchain transactions include performing a hash of the data contents of the transactions in a current block and referencing a previous hash of a previous block; and where the system can store a user profile based on the user’s history of purchases and preferences), and
record the hash value (e.g. Paragraphs [0035], [0042], [0064], [0150]; where a distributed ledger is capable of maintaining records; and where 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; and where the storage includes the blockchain in the form of a hash-linked chain of blocks and a state database).
As per Claim 7, Lu, in view of Kai, teaches the features of Claim 6, and Lu further discloses the features of wherein the data storing devices are respectively configured to generate an electronic signature by encrypting the hash value of the usage history information with a private key (e.g. Paragraphs [0078], [0158]-[0159]; where the encryption module may provide a private key to be used by the transport to encrypt/ decrypt communications with other devices, which may be transmitted to a remote server using a local private/ public key pair, and the block data includes signature data).
Claims 4-5 and 8 is rejected under 35 U.S.C. 103 as being unpatentable over Lu, in view of Kai as applied to Claims 1 above, and further in view of U.S. Patent Publication No. 2024/0220939 A1, to Ropel, et al (hereinafter referred to as Ropel; previously of record).
As per Claim 4, Lu, in view of Kai, teaches the features of Claim 1, and Lu further discloses the features of wherein the provision information generated in response to receiving the first transmission request indicates a value loss of the power storage device due to the traffic accident (e.g. Paragraph [0096]; where the transport computer can send data to the server relating to an accident, and the sever stores the damage assessment into a blockchain).
Lu fails to disclose the features of the information terminal is configured to, in a case where the traffic accident has occurred, transmit the first transmission request to the server, and calculate an insurance benefit for compensating for the value loss of the power storage device due to the traffic accident by using the provision information received from the server.
However, Ropel teaches a method for tracking vehicle maintenance information using blockchain technology, where the vehicle information includes vehicle accident data, and the recording component can record the vehicle accident data in the blockchain; and where the vehicle information can facilitate the provisioning of and pricing of warranties, insurance, or valuation, and can send notifications to relevant entities, including a blockchain server device (e.g. Paragraphs [0090], [0123]-[0124], [0129], [0148]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to further modify the transport battery recharging method of Lu, in view of Kai, with the feature of calculating the insurance benefit in the system of Ropel, in order to provide seamless and up-to-date provisioning of information (see at least Paragraphs [0089], [0093] of Ropel).
As per Claim 5, Lu, in view of Kai, teaches the features of Claim 1, but Lu fails to disclose every feature of wherein the information terminal is configured to, in a case where the traffic accident has not occurred and the power storage device has been removed from the vehicle, transmit the second transmission request to the server; and estimate a value of the power storage device by using the provision information received from the server, and determine an application for reuse of the power storage device removed from the vehicle based on the estimated value.
Kai teaches the features of wherein the information terminal is configured to, in a case where the traffic accident has not occurred and the power storage device has been removed from the vehicle, transmit the second transmission request to the server. Kai teaches a method for generating information about a user who uses a battery module, where an exhausted detachable battery (100) is removed from the electrically driven vehicle (10), and the storage (140) provided on the detachable battery (100) may store a use aspect (a use state, a use history) associated with the vehicle, such as traveling history information, electric power consumption amount, a battery SOC, battery state information (i.e. normal operation of the battery, or no accident has occurred), and when the detachable battery is returned to the battery accommodating part on the charging module, the battery ID is read and transmitted to the management server (300)) (e.g. Paragraphs [0056], [0062], [0070], [0113]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to modify the transport battery recharging method of Lu, with the feature of transmitting the state of the removed battery in the system of Kai, in order to identify the user of the detachable battery and assign the battery ID of the new battery to the user (see at least Paragraph [0062] of Kai).
Ropel further teaches the features of estimate a value of the power storage device by using the provision information received from the server. Ropel teaches a method for tracking vehicle maintenance information using blockchain technology, where the battery is removed from the transport vehicle, and the battery health over the course of the removal and install can be monitored, and the removable components can comprise biometric and/or blockchain data associated with each user who loaned or operated the vehicle to facilitate the tracking use of the car over a period and by which driver, and monitor the health of the battery over the supply chain distribution (e.g. Paragraphs [0036], [0050], [0055], [0061], [0094]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to further modify the transport battery recharging method of Lu, in view of Kai, with the feature of estimating the value of the power storage in the system of Ropel, in order to provide real-time updates of battery health and condition (see at least Paragraph [0085] of Ropel).
Ropel further teaches the features of determine an application for reuse of the power storage device removed from the vehicle based on the estimated value.
Ropel teaches a method for tracking vehicle maintenance information using blockchain technology, where the health of the battery is tracked; and where the state of health (SOH) of the battery can be determined, and the system may determine charge retention, number of charge/discharge cycles, SOC, charge fading, charging profile, voltage, etc., to determine the SOH of the battery for installing in a vehicle to determine if the battery can be used or installed (e.g. Paragraphs [0039], [0052], [0083]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to further modify the transport battery recharging method of Lu, in view of Kai, with the feature of determining the estimated value of the battery in the system of Ropel, in order to provide real-time updates of battery health and condition (see at least Paragraph [0085] of Ropel).
As per Claim 8, Lu, in view of Kai, teaches the features of Claim 6, and Lu further discloses the features of wherein the server is configured to
acquire the hash value of the usage history information from the plurality of data storing devices (e.g. Paragraphs [0038]-[0039], [0142], [0152]; where the ledger records all state transitions of a blockchain by utilizing the hash of the entry that came before it (i.e. acquires usage history of other devices), including registered recipients, vehicle features, sensor thresholds, etc., and also identifies whether requesting entities are registered to receive vehicle services and provide the information to the owner, operator, etc.),
acquire the usage history information from the data management device (e.g. Paragraphs [0034], [0070], [0150]; where the vehicle status data may be received and processed to identify vehicle/ transport status conditions, including when a battery needs to be replaced)),
generate a hash value of the acquired usage history information using the hash function (e.g. Paragraphs [0149], [0152]; where the system receives a hash and retrieves the blockchain from a has associated with the data template created by the user of a previously stored extractor),
determine whether the hash value acquired from the plurality of data storing devices matches the hash value generated by the server (e.g. Paragraph [0149]; where if the hashes of the hash identifier match, the system sends an authorization key to the requested service) ‘…’.
Lu fails to disclose every feature of in a case where a determination is made that the hash value acquired from the plurality of data storing devices does not match the hash value generated by the server, request the data management device to transmit correct usage history information. However, Ropel teaches a method for tracking vehicle maintenance information using blockchain technology, where the node may generate hashed battery data based on applying a hash function to the battery data, and if the result of the comparison indicates a match, then the data integrity of the battery data entry may be established and validated; and where if the data does not match or conform to a set of rules for the blockchain, the system determines the missing content and records the missing data or if the data of the battery entry data has been modified (i.e. does not match), the system indicates the data entry is not successfully validated, and the system searches for blockchain data with the newest timestamp to create a new blockchain entry, and records the data when the blockchain value is verified (e.g. Paragraphs [0084], [0114]-[0115], [0120], [0126]-[0127]).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the Applicant’s invention, with a reasonable expectation for success, to further modify the transport battery recharging method of Lu, in view of Kai, with the feature of determining if the values match in the system of Ropel, in order to provide an accurate record of the operational health of the battery (see at least Paragraph [0039] of Ropel).
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 MERRITT LEVY whose telephone number is (571)270-5595. The examiner can normally be reached Mon-Fri 0630-1600.
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, Abby Flynn can be reached at (571) 272-9855. 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.
/MERRITT LEVY/Examiner, Art Unit 3663
/ABBY J FLYNN/Supervisory Patent Examiner, Art Unit 3663