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 .
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, 11, 12, and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smith (U.S. Patent Application Publication No. 2024/0362956) in view of Andreasen (U.S. Patent Application Publication No. 2025/0284582).
Regarding claim 1, Smith discloses a system for managing fault information about vehicles based on blockchain, the system comprising:
a data storage unit configured to store at least one of fault information or a repair history of the vehicles, with interlinked blockchain tokens of vehicle controllers (The vehicle data are collected in a data lake 106, [0015], using a blockchain 110 to store the vehicle data, the data is immutable, secure, and traceable, ensuring the integrity of the data, [0020], The system and method 100 include a data acquisition process 104 that automatically receives vehicle data through various ingestion methods, such as webhooks or SFTP (Secure File Transfer Protocol). The acquired data is pushed into a Data Lake (Raw Data Lake) 106 to handle the unstructured and un-normalized nature of the acquired data, [0037], Vehicle Health Record System 100, [0039], fig. 1, 3, 5); and
a first data transmission-reception unit configured to transmit and receive, to and from a main server, data pertaining to at least one of the fault information or the repair history of the vehicles, at preset periodic intervals, wherein the main server is configured to classify and manage the data by types of the vehicles (The VHR system 100 may employ cloud-based servers and data storage devices that provide users 500 with the ability to access value-added data, insights, and derivative products and services easily and efficiently. The VHR system 100 also takes advantage of the benefits of using cloud-based servers and data storage devices such as redundancy, scalability, flexibility, and reliability, [0039], The VHR system 100 ingests vehicle data from a number of data sources 102 that provide a variety of data related to the vehicles, including vehicle build information, ownership information, recall information, repair information, diagnostics information, repair estimates, connected-car information, DMV (Department of Motor Vehicle) history, accident information, insurance information, and other vehicle data, [0013], The received fault codes may be sorted or categorized based on the origin (e.g., location) of each fault code as well as the time when each fault code was triggered. With regard to origin, each fault code may be categorized as being either a network type fault code or a non-network type fault code, [0072], fig. 19, 20, 22, 23).
Smith does not expressly disclose wherein the vehicle controllers each includes:
a plurality of electronic control units (ECUs) configured to store the fault information in response to an occurrence of a fault, and
a communication module configured to wirelessly communicate with the main server.
Andreasen teaches that it was known in the art wherein the vehicle controllers each includes:
a plurality of electronic control units (ECUs) configured to store the fault information in response to an occurrence of a fault (The system connects to a vehicle's data link connector (DLC) and automatically retrieves diagnostic trouble codes (DTCs) from multiple electronic control units (ECUs), Abstract, The status response signal includes a plurality of ECUs on the vehicle that are responsive to the transmitted ECU status request signal. A state of health report is generated and includes a comprehensive listing of all ECUs associated with the vehicle. Each ECU in the state of health report responsive to the transmitted ECU status request signal is associated with an active status, while the remaining ECUs in the state of health report being associated with an inactive status. The method additionally includes receiving communication DTCs from the vehicle, with each communication DTC being associated with at least one ECU, [0020], a vehicle's Controller Area Network (CAN) bus. The device includes a processor, memory, a display-based user interface, and a communication interface configured to connect to the vehicle's diagnostic link connector (DLC) and communicate with multiple onboard control modules (ECUs). The apparatus retrieves diagnostic trouble codes (DTCs) over the CAN bus, [0029], The device performs a system-wide scan to identify all ECUs present on the vehicle. It sends broadcast messages and listens for responses from each ECU on all available networks. A detailed description of network discovery and ECU polling follows below with FIG. 17. Next, DTCs are retrieved at block 1616. The system requests and retrieves all available DTCs from each responding ECU. This includes both active (current) and historical (stored) fault codes, [0098]), and
a communication module configured to wirelessly communicate with the main server (Abstract, [0020, 0029, 0098], Wireless, [0095]).
Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to modify the system of Smith by including the fault storing, ECUs, and wireless communication as taught by Andreasen.
One of ordinary skill would have been motivated to make the combination, in order to provide a method for detecting, filtering, grouping, and prioritizing Controller Area Network (CAN) Bus-related diagnostic trouble codes (DTCs) across multiple electronic control units (ECUs), and for guiding technicians through an efficient, step-by-step repair process based on the ranked severity of communication faults (because) ([0003], Andreasen).
Regarding claim 2, Smith discloses a second data transmission-reception unit configured to transmit the data from the main server to user terminals of the vehicles to enable users of the vehicles to monitor the data pertaining to at least one of the fault information or the repair history (The VHR system 100 then packages (310) the augmented data 308 into elements usable and/or accessible via the API 122 and, in some cases, delivered directly to the customer and end users 312, [0037], provide users 500 with the ability to access value-added data, insights, and derivative products and services easily and efficiently, [0039], fig. 1, 5).
Regarding claim 3, Smith discloses wherein, in the data storage unit, the blockchain tokens of the vehicle controllers mutually assure data validity to ensure data security (Abstract, ensure data immutability and security using blockchain technology. [0010]).
Regarding claim 4, Smith discloses wherein the blockchain tokens of the vehicle controllers are issued via respective hash values that are generated based on unique numbers of the vehicles at a time of manufacture of the vehicles are manufactured ([0011]).
Regarding claim 5, Andreasen discloses wherein the ECUs are configured to: determine, according to preset criteria, whether data corresponds to the fault information; and manage the data that corresponds to the fault information as fault memory ([0168, 0173]).
Regarding claim 6, Smith discloses wherein the first data transmission/reception unit is further configured to transmit fault memory data, along with vehicle information, to the main server by using a wireless communication network ([0095]).
Regarding claim 11, Smith discloses an apparatus for managing fault information about vehicles based on blockchain, the apparatus comprising:
a data storage module configured to store at least one of fault information or a repair history of the vehicles, with interlinked blockchain tokens of vehicle controllers ([0020, 0037, 0039], fig. 1, 3, 5);
a first data transmission-reception module configured to transmit and receive, to and from a main server, data pertaining to at least one of the fault information or the repair history of the vehicles, at preset periodic intervals, wherein the main server is configured to classify and manage the data by types of the vehicles ([0013, 0039, 0072], fig. 19, 20, 22, 23); and
a second data transmission-reception module configured to transmit the data from the main server to terminals of users of the vehicles to enable the users of the vehicles to monitor the data pertaining to the at least one of the fault information or the repair history ([0037, 0039], fig. 1, 5).
Andreasen discloses wherein the vehicle controllers each includes:
a plurality of electronic control units (ECUs) configured to store the fault information in response to an occurrence of a fault, and a communication module configured to wireless communicate with the main server ([0020], 0029, 0098]), and
a communication module configured to wirelessly communicate with the main server (Abstract, [0020, 0029, 0095, 0098]).
Regarding claim 12, Smith discloses wherein, in the data storage module, the blockchain tokens of the vehicle controllers mutually assure data validity to ensure data security ([0037, 0039], fig. 1, 5).
Regarding claim 14, Smith discloses a method of managing fault information about vehicles based on blockchain, the method comprising:
a data storage operation of storing at least one of fault information or a repair history of the vehicles, in interlinked blockchain tokens of vehicle controllers ([0020, 0037, 0039], fig. 1, 3, 5);
a first data transmission-reception operation of transmitting and receiving data pertaining to at least one of the fault information or the repair history of the vehicles at preset periodic intervals [0013, 0039, 0072], fig. 19, 20, 22, 23); and
a data management operation of managing the data by classifying the data in a main server according to types of the vehicles and updating the data with new information ([0013, 0039, 0072], fig. 19, 20, 22, 23).
Andreasen discloses wherein the vehicle controllers each includes:
a plurality of electronic control units (ECUs) capable of storing the fault information in response to an occurrence of a fault, and a communication module configured to wirelessly communicate with the main server (Abstract, [0020, 0029, 0095, 0098]).
Regarding claim 15, Smith discloses a second data transmission-reception operation of transmitting the data from the main server to terminals of users of the vehicles to enable the users of the vehicles to monitor the data pertaining to the at least one of the fault information or the repair history ([0037, 0039], fig. 1, 5).
Regarding claim 16, Andreasen discloses wherein the data storage operation includes: a fault information determination operation of determining, by the ECUs, whether data corresponds to the fault information, according to preset criteria; and a fault memory management operation of managing data corresponding to the fault information as fault memory ([0168, 0173]).
Regarding claim 17, Andreasen discloses wherein the ECUs are configured to, while the vehicles are driving, determine whether data corresponds to the fault information, and store the data ([0106]).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smith in view of Andreasen, as applied to claim 11 above, and further in view of Wang (U.S. Patent Application Publication No. 2024/0053738).
Regarding claim 13, Smith as modified by Andreasen discloses the system as set forth above.
Smith does not expressly disclose wherein the first data transmission-reception module is further configured to collect the data pertaining to the at least one of the fault information or the repair history of the vehicles by utilizing a Unified Diagnostic Services (UDS) diagnostic protocol ().
Wang teaches that it was known in the art wherein the first data transmission-reception module is further configured to collect the data pertaining to the at least one of the fault information or the repair history of the vehicles by utilizing a Unified Diagnostic Services (UDS) diagnostic protocol ([0077]).
Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to modify the system of Smith as modified by Andreasen by including the UDS protocol as taught by Wang.
One of ordinary skill would have been motivated to make the combination, in order to accurately determine which function or functions are faulty and how to perform repair ([0004], Wang).
Allowable Subject Matter
Claims 7-10 and 17-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA P LOTTICH whose telephone number is (571)270-3738. The examiner can normally be reached Mon - Fri, 9:00am - 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, Bryce Bonzo can be reached at 5712723655. 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.
/JOSHUA P LOTTICH/ Primary Examiner, Art Unit 2113
Prosecution Insights