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
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-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Danne (US 2015/0301821 A1) in view of Ricci (US 2019/0222484 A1).
Regarding claim 1, Danne discloses an information processing device configured to control a display unit configured to display information on software update for an in-vehicle electronic device (Danne discloses an in-vehicle vehicle computing system (“VCS”) having a processor and persistent memory, and a display, wherein the system manages software/firmware/application updates and provides user prompts/status/feedback regarding downloading/updating via the application-level user interface (Danne [0017]–[0021], [0035], [0068]–[0069]).), the information processing device comprising a circuitry configured to:
display guidance information on the display unit under a condition that an update error in which the software update is not performable properly has occurred (Danne teaches detecting update problems such as corrupt application files, incomplete transfers, interrupted downloads, and managing update status via the manifest, including recognition that the update is not properly performable (Danne [0036]–[0041], [0045]–[0046], [0077]–[0079]). Danne also teaches that the application-level user interface provides the user with prompts, status, and/or feedback based on update management (Danne [0068]-[0069]). Thus, Danne teaches displaying user-facing guidance (prompts/status/feedback) on a display when an update error/abnormal update condition occurs (e.g., corrupt, incomplete, interrupted update).).
However, Danne does not expressly disclose select first guidance information or second guidance information to be displayed on the display unit as the guidance information based on a situation in which the update error has occurred, the first guidance information indicating a procedure for resolving the update error that is practicable by a user of a vehicle, the second guidance information indicating that the vehicle needs to be brought to a dealer. Specifically, Danne teaches that different update conditions exist and are tracked/handled differently, including file “installation type” (active/kill/reboot/system command/image), update destination criticality (e.g., special handling for safety-critical subsystems requiring key-on/key-off constraints), and error conditions (corruption, incomplete transfer, interrupted transfer) that result in different remedial actions (Danne [0038]–[0039], [0045]–[0046], [0055]-[0056], [0063]–[0065], [0074]–[0079]). Danne teaches remedial actions of retrying/continuing download, requesting missing portions, verifying integrity (checksum), downloading again, using backup/rollback, etc. Danne also teaches an application-level UI providing prompts/feedback for update management (Danne [0045]–[0046], [0055]-[0056], [0068]–[0069], [0074]–[0079]).
In an analogous art, Ricci teaches selecting a treatment for a warning/error signal based on preferences/rules/policies and providing interactive guidance to the occupant, including escalation to third parties (Ricci [0020]–[0021], [0036]–[0037], [0327]-[0341] and steps 1400–1420). Thus, Ricci supplies the explicit teaching of selecting between different displayed guidance outputs depending on the situation/error-treatment logic. Ricci teaches providing the occupant “conversational” warnings and guidance and recommending actions that may be taken without immediate service intervention (e.g., “do not be alarmed…”, recommended course of action; interactive advice) (Ricci [0333]–[0339]). Thus, the combined system of Danne and Ricci teach displaying guidance that instructs the user on steps to resolve/mitigate an issue when practicable. Ricci teaches escalation paths where the diagnostic module forwards warnings/errors to a manufacturer/servicing entity and/or interacts with a repair service provider, including scheduling service and dispatching assistance depending on severity (Ricci [0327]-[0341, and steps 1400–1420). This corresponds to guidance that the vehicle needs professional service (e.g., dealer/service facility).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Danne’s vehicle software update error handling and displayed user feedback such that the system selects among different guidance outputs based on the situation in which the update error occurs, as taught by Ricci’s selection of error-treatment paths and presentation/escalation logic. This modification is a predictable application of known vehicle diagnostic/error-handling techniques to the known problem of software update failures in vehicles, and it yields the expected benefit of providing appropriate guidance to the user depending on whether the update error is resolvable by user-performed steps (e.g., retrying a download/update procedure, following presented corrective steps) or requires professional service (e.g., directing the user to bring the vehicle to a dealer/service facility or otherwise escalating the issue to a servicing entity).
Regarding claim 2, Danne in view of Ricci teaches the information processing device according to claim 1, wherein the circuitry is configured to select the first guidance information as the guidance information under a condition that the update error has occurred due to an interruption of communication with the in-vehicle electronic device (Danne teaches that an update/error condition can occur due to an interruption/loss of communication with the in-vehicle electronic device (e.g., VCS), including detecting that the VCS is no longer in communication and handling interrupted transfers/missing portions (Danne [0045], [0049]–[0050], [0057], [0077]–[0078]). Danne also teaches that the application-level user interface provides the user with prompts, status, and/or feedback based on update management (Danne [0068]-[0069]). Ricci teaches providing user-facing diagnostic guidance that is selected/presented based on a likely cause of a warning/error and may be conversational/interactive (Ricci [0036], [0333]–[0339]). It would have been obvious to modify Danne to, upon determining the update error is due to the communication interruption, select and present user-practicable guidance (i.e., the “first guidance information”) directed to restoring communication/retrying the update, as taught by Ricci, to improve user comprehension and facilitate recovery without service intervention.).
Regarding claim 3, Danne in view of Ricci teaches the information processing device according to claim 1, wherein the circuitry is configured to select the first guidance information as the guidance information under a condition that the update error has occurred due to an interruption of communication with the in-vehicle electronic device and the in-vehicle electronic device is switchable ON and OFF in conjunction with an operation on a power switch of the vehicle (Danne teaches that an update error can occur due to an interruption/loss of communication with the in-vehicle electronic device (e.g., VCS), including detecting that the VCS is no longer in communication and managing interrupted transfers (Danne [0049]–[0050], [0057], [0077]–[0079]). Danne further teaches the in-vehicle system behavior tied to vehicle power cycling, including key-on and key-off events (i.e., power ON/OFF in conjunction with vehicle operation) and performing/staging update actions during boot or storing update files for the next key-on event (Danne [0070]–[0071], [0079]–[0080]). Danne also teaches that the application-level user interface provides the user with prompts, status, and/or feedback based on update management (Danne [0068]-[0069]). Ricci teaches selecting and presenting user-facing diagnostic guidance based on the likely cause of a warning/error and providing interactive/ conversational guidance to facilitate corrective action (Ricci [0036], [0333]–[0339]). It would have been obvious to modify Danne such that, when the update error is due to the communication interruption and the in-vehicle device is switchable ON/OFF with the vehicle power operation (as taught by Danne’s key-on/key-off behavior), the system selects and presents user-practicable guidance (i.e., the “first guidance information”), e.g., instructing a user to power-cycle/retry, as taught by Ricci, to improve recovery and user understanding without requiring service.).
Regarding claim 4, Danne in view of Ricci teaches the information processing device according to claim 1, wherein the circuitry is configured to select the first guidance information as the guidance information under a condition that the update error has occurred due to an interruption of communication between the vehicle and an external distribution center configured to distribute software update data (Danne teaches performing vehicle software updates using an external server that distributes update data (i.e., an external distribution center), including the server 61 maintaining/ transmitting a manifest and application files/packages to the vehicle/VCS and managing download/ transfer of the update data (Danne [0038]–[0041], [0051]–[0055], [0064]–[0066], [0071]–[0076]). Danne further teaches that an update/download error condition can occur due to an interruption of communication between the vehicle (via nomadic device/onboard modem) and the server, including inability to establish/re-establish connection and loss/disabling of communication (Danne [0050]–[0051], [0057], [0071]–[0073]). Danne also teaches that the application-level user interface provides the user with prompts, status, and/or feedback based on update management (Danne [0068]-[0069]). Ricci teaches determining a likely cause of a warning/error and presenting user-facing guidance accordingly (Ricci [0036], [0333]–[0339]). Thus, it would have been obvious to configure the guidance selection logic such that, when the update error is determined to be due to interruption between the vehicle and the external distribution center (server) as taught by Danne, the device selects the first guidance information (user-practicable recovery steps) as taught by Ricci, to improve recovery and user comprehension.).
Regarding claim 5, Danne in view of Ricci teaches the information processing device according to claim 1, wherein the circuitry is configured to select the second guidance information as the guidance information under a condition that the update error has occurred through determination that an electronic signature assigned to software update data is not a valid signature (Danne teaches over-the-air (OTA) update security by checking a plurality of security signatures in an OTA manifest (Danne [0004]). An invalid signature corresponds to a signature verification failure for the update data. Ricci teaches selecting treatment for warning/error conditions, including escalation to a servicing/diagnostic entity when the condition warrants (Ricci [0327]–[0331]). It would have been obvious to treat an invalid-signature verification failure as an update error requiring escalation and to select the bring to dealer/service guidance because authenticity/security failures are appropriately handled by authorized service/diagnostics rather than user-performed steps.)
Regarding claim 6, Danne in view of Ricci teaches the information processing device according to claim 1, wherein the circuitry is configured to select the second guidance information as the guidance information under a condition that the update error has occurred due to a hardware malfunction of the in-vehicle electronic device (Danne teaches vehicle software update management and displaying user prompts/status/feedback responsive to update failures (Danne [0068]–[0069], [0077]–[0079]). Ricci teaches diagnosing faults/malfunctions of vehicle components and providing repair recommendations to the operator, including engaging a service/repair facility as an appropriate course of action. (Ricci [0327]–[0331], [0334]–[0336]). It would have been obvious to modify Danne such that, when the update error is determined to be due to a hardware malfunction, the device selects and displays the bring to dealer/service guidance, as taught by Ricci, because hardware faults are not reliably user-resolvable and are appropriately escalated to service.).
Regarding claim 7, Danne in view of Ricci teaches the information processing device according to claim 1, wherein the circuitry is configured to select the second guidance information as the guidance information under a condition that the update error has recurred after display of the first guidance information (Danne teaches presenting user-facing prompts/status/feedback on the vehicle display responsive to update failures and corrective actions (i.e., displaying guidance when update errors occur) (Danne [0068]–[0069], [0077]–[0079]). Ricci teaches selecting treatment for a warning/error via predetermined rules, including providing occupant-facing guidance/advice and, when the condition persists/recurs or is not resolved, escalating the treatment to servicing entities (e.g., forwarding the error to a servicing entity and/or scheduling service/repair) (Ricci [0327], [0330], [0340]–[0341]). It would have been obvious to modify Danne such that, after first displaying user-practicable guidance and the update error recurs, the device selects the bring to dealer/service guidance per Ricci’s escalation logic, because repeated failure indicates the condition is not resolved by user steps and warrants service escalation.).
Regarding claim 8, Danne in view of Ricci teaches a vehicle comprising the information processing device according to claim 1 (Danne teaches the claimed subject matter in a vehicle context (e.g., vehicle 31) (Danne fig. 1, [0017]). Ricci discloses a vehicle including one or more processing modules coupled to vehicle buses and an input/output system (e.g., dashboard/display) for presenting information to an occupant, including diagnostics/warning/error handling (Ricci [0013]–[0020], [0122]–[0131], [0174]–[0178], [0326]–[0331]). It would have been obvious to include the information processing device of claim 1 in a vehicle as taught by the combination of Danne and Ricci because the device is expressly for in-vehicle operation and display/diagnostic presentation.).
Claim 9 is rejected under 35 U.S.C. § 103 as being unpatentable over Danne (US 2015/0301821 A1) in view of Ricci (US 2019/0222484 A1). Claim 9 is rejected for the same reasons as set forth with respect to claim 1 above. Claim 9 is directed to method for executing steps corresponding to the system functions/features of claim 1 above, and the scope and content of the recited limitations are substantially the same. Accordingly, the teachings of Danne in view of Ricci that render claim 1 obvious likewise apply to claim 9 for the same reasons set forth above.
Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over Danne (US 2015/0301821 A1) in view of Ricci (US 2019/0222484 A1). Claim 10 is rejected for the same reasons as set forth with respect to claim 1 above. Claim 10 is directed to a non-transitory storage medium storing instructions for executing steps corresponding to the system functions/features of claim 1 above, and the scope and content of the recited limitations are substantially the same. Accordingly, the teachings of Danne in view of Ricci that render claim 1 obvious likewise apply to claim 10 for the same reasons set forth above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAJSHEED O BLACK-CHILDRESS whose telephone number is (571)270-7838. The examiner can normally be reached M to F, 10am to 5pm.
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, Quan-Zhen Wang can be reached at (571) 272-3114. 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.
/RAJSHEED O BLACK-CHILDRESS/Examiner, Art Unit 2685