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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. CN202210705073.5, filed on 6/21/2022.
Response to Amendment
This action is in response to applicant’s arguments and amendments filed 2/10/2026, which are in response to USPTO Office Action mailed 11/12/2025. Applicant’s arguments have been considered with the results that follow: THIS ACTION IS MADE FINAL.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/04/2025 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is/are being considered by the examiner.
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, 7 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over August et al. (US PGPUB No. 2020/0098032; Pub. Date: Mar. 26, 2020) in view of Hu et al. (US PGPUB No. 2022/0089170; Pub. Date: Mar. 24, 2022).
Regarding independent claim 1,
August discloses a data processing method, applied to a detection component of an application, and comprising: detecting an interface element of a vehicle service of the application, See FIG. 3 & Paragraph [0046], (Disclosing a system for guided vehicle matching via an electronic vehicle listing service configured to provide vehicle recommendations to a user via graphical user interface displayed on a client device. FIG. 3 illustrates method 300 comprising step 308 wherein a server 140 may analyze user responses and interactions on a graphical user interface to determine vehicle recommendations for a user, i.e. a detection module (e.g. server 140), configured to detect an interface element of a vehicle service of the application (e.g. server 140 monitors user responses to displayed information).)
wherein the interface element is configured in a user interface of a terminal device on which the application runs; See FIG. 3 & Paragraph [0047], (FIG. 3 illustrates method 300 comprising step 310 comprises a step of presenting vehicle recommendations to a user by transmitting vehicle recommendations to client computing device 110 for presentation to the user on display 202, i.e. wherein the interface element is configured in a user interface of a terminal device on which the application runs;)
uploading a data updating request to a service platform of the vehicle service if it is detected that a data updating condition of the interface element is triggered; See Paragraph [0008], (The system may update displayed vehicle recommendations based on received user reaction data indicating response to the one or more vehicle recommendations. Note [0030] wherein controller 210 of the client computing device 110 may process data for presentation to the user in response to user interaction or requests, i.e. uploading a data updating request to a service platform of the vehicle service if it is detected that a data updating condition of the interface element is triggered;)
and performing, based on the vehicle use information, data updating on the interface element displayed in the user interface. See FIG. 3 & Paragraph [0042], (The method of FIG. 3 comprises step 312 of monitoring user response to recommendations. The monitoring may comprise tracking user navigation such as click-through rate or time on vehicle pages in order to determine additional vehicle recommendations to be presented to a user, i.e. performing, based on the vehicle use information, data updating on the interface element displayed in the user interface (e.g. the GUI of client device 110 is updated based on the monitoring).)
August does not disclose the step of receiving vehicle use information that is of a user vehicle associated with the vehicle service and that is delivered by the service platform, wherein the vehicle use information corresponds to a vehicle use state of the user vehicle and is obtained by the service platform by querying a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms;
Hu discloses the step of receiving vehicle use information that is of a user vehicle associated with the vehicle service and that is delivered by the service platform, See Paragraph [0070], (Disclosing a system for determining status information of one or more hardware components in a vehicle. Health monitoring system 460 may monitor the working condition of one or more hardware and/or software components of a vehicle. Note [0080] wherein health monitoring system 460 comprises monitor 461 that may determine a status of application software based on whether the data to be processed by the application software is received, i.e. receiving vehicle use information that is of a user vehicle associated with the vehicle service and that is delivered by the service platform.)
wherein the vehicle use information corresponds to a vehicle use state of the user vehicle and is obtained by the service platform by querying a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms; See Paragraph [0071], (Monitor 461 may monitor the status of an operating system 410, the status of braking system 420, the status of acceleration system 430, the status of signaling system 440, the status of vehicle navigation system 450, etc. to detect errors or failures that may affect the autonomous driving of a vehicle. Monitor 461 retrieves data corresponding to a working status of one or more electrical components and determines whether said components are working in a normal status, i.e. wherein the vehicle use information corresponds to a vehicle use state of the user vehicle and is obtained by the service platform by querying a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms;)
August and Hu are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August to include the method of determining vehicle component status information as disclosed by Hu. Paragraph [0072] of Hu discloses that the system may notify a user of the status of the hardware and software components. This represents an improvement in the user experience as users may be made aware of any abnormal conditions that may be present with regard to both sensors and components of a vehicle as well as application software such as the operating system or other elements of the vehicle navigation system.
Regarding dependent claim 7,
As discussed above with claim 1, August-Hu discloses all of the limitations.
August further discloses the step wherein that the data updating condition is triggered is detected in the following manner: detecting whether a configuration request for the interface element exists, and if the configuration request for the interface element exists, determining that the data updating condition is triggered; or detecting whether an updating request for the interface element exists, and if the updating request for the interface element exists, determining that the data updating condition is triggered; or detecting whether a data updating time of the interface element arrives, and if the data updating time of the interface element arrives, determining that the data updating condition is triggered. See Paragraph [0042], (Server 140 may monitor user responses to vehicle recommendations in order to determine and iteratively refine vehicle recommendations in response to user interactions and responses, i.e. detecting whether an updating request for the interface element exists (e.g. based on the monitored user responses), and if the updating request for the interface element exists, determining that the data updating condition is triggered (e.g. the system may respond to the monitored response by providing vehicle recommendations responsive to the user's preferences as indicated by the response(s)).)
Regarding independent claim 19,
August discloses a computing device comprising a memory and a processor, wherein the memory stores executable instructions that, in response to execution by the processor, cause the computing device to: detect an interface element of a vehicle service of an application, See FIG. 3 & Paragraph [0046], (Disclosing a system for guided vehicle matching via an electronic vehicle listing service configured to provide vehicle recommendations to a user via graphical user interface displayed on a client device. FIG. 3 illustrates method 300 comprising step 308 wherein a server 140 may analyze user responses and interactions on a graphical user interface to determine vehicle recommendations for a user, i.e. a detection module (e.g. server 140), configured to detect an interface element of a vehicle service of the application (e.g. server 140 monitors user responses to displayed information).)
wherein the interface element is configured in a user interface of a terminal device on which the application runs; See FIG. 3 & Paragraph [0047], (FIG. 3 illustrates method 300 comprising step 310 comprises a step of presenting vehicle recommendations to a user by transmitting vehicle recommendations to client computing device 110 for presentation to the user on display 202, i.e. wherein the interface element is configured in a user interface of a terminal device on which the application runs;)
upload a data updating request to a service platform of the vehicle service if it is detected that a data updating condition of the interface element is triggered; See Paragraph [0008], (The system may update displayed vehicle recommendations based on received user reaction data indicating response to the one or more vehicle recommendations. Note [0030] wherein controller 210 of the client computing device 110 may process data for presentation to the user in response to user interaction or requests, i.e. upload a data updating request to a service platform of the vehicle service if it is detected that a data updating condition of the interface element is triggered.)
wherein the request uploading module is configured to upload a data updating request to a service platform of the vehicle service; See Paragraph [0030], (Controller 210 may send and/or receive data from server 140 either directly or through network 130, i.e. wherein the request uploading module is configured to upload a data updating request to a service platform of the vehicle service (e.g. controller 210 may receive an indication of a user action or request and may respond by requesting data from server 140).)
and a data updating module, configured to perform, based on the vehicle use information, data updating on the interface element displayed in the user interface. See FIG. 3 & Paragraph [0042], (The method of FIG. 3 comprises step 312 of monitoring user response to recommendations. The monitoring may comprise tracking user navigation such as click-through rate or time on vehicle pages in order to determine additional vehicle recommendations to be presented to a user, i.e. a data updating module (e.g. the functionality is performed by elements of server 140), configured to perform, based on the vehicle use information, data updating on the interface element displayed in the user interface (e.g. the GUI of client device 110 is updated based on the monitoring).)
August does not disclose that the device may receive vehicle use information that is of a user vehicle associated with the vehicle service and that is delivered by the service platform, wherein the vehicle use information corresponds to a vehicle use state of the user vehicle and is obtained by the service platform by querying a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms;
Hu discloses a device that may receive vehicle use information that is of a user vehicle associated with the vehicle service and that is delivered by the service platform, See Paragraph [0070], (Disclosing a system for determining status information of one or more hardware components in a vehicle. Health monitoring system 460 may monitor the working condition of one or more hardware and/or software components of a vehicle. Note [0080] wherein health monitoring system 460 comprises monitor 461 that may determine a status of application software based on whether the data to be processed by the application software is received, i.e. receiving vehicle use information that is of a user vehicle associated with the vehicle service and that is delivered by the service platform.)
wherein the vehicle use information corresponds to a vehicle use state of the user vehicle and is obtained by the service platform by querying a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms; See Paragraph [0071], (Monitor 461 may monitor the status of an operating system 410, the status of braking system 420, the status of acceleration system 430, the status of signaling system 440, the status of vehicle navigation system 450, etc. to detect errors or failures that may affect the autonomous driving of a vehicle. Monitor 461 retrieves data corresponding to a working status of one or more electrical components and determines whether said components are working in a normal status, i.e. wherein the vehicle use information corresponds to a vehicle use state of the user vehicle and is obtained by the service platform by querying a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms;)
August and Hu are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August to include the method of determining vehicle component status information as disclosed by Hu. Paragraph [0072] of Hu discloses that the system may notify a user of the status of the hardware and software components. This represents an improvement in the user experience as users may be made aware of any abnormal conditions that may be present with regard to both sensors and components of a vehicle as well as application software such as the operating system or other elements of the vehicle navigation system.
Claim(s) 2-4, 8-9, 12-14, 16 and 23-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over August in view of Hu as applied to claim 1 above, and further in view of Dickow et al. (US PGPUB No. 2016/0209224; Pub. Date: Jul. 21, 2016).
Regarding dependent claim 2,
As discussed above with claim 1, August-Hu discloses all of the limitations.
August-Hu does not disclose the step wherein the vehicle service is activated in the following manner: verifying, based on vehicle identification information that is of the user vehicle and that is entered by a login user, whether the user vehicle satisfies a configuration condition for the interface element;
displaying an activation control of the interface element to the login user if the user vehicle satisfies the configuration condition for the interface element;
and activating the interface element for the login user if it is detected that the activation control is triggered.
Dickow discloses the step wherein the vehicle service is activated in the following manner: verifying, based on vehicle identification information that is of the user vehicle and that is entered by a login user, whether the user vehicle satisfies a configuration condition for the interface element; See Paragraph [0024] & [0032], (Disclosing a ride-swap server configured to receive swap requests from users indicating a swap between a first vehicle of a first user and a second vehicle of a second user. Swap management server 118 maintains account information 120 which may include information regarding a user such as a unique account or username identifier as well as information regarding a vehicle 120. Authentication information such as login names, passwords, encryption keys, etc. are also used to authenticate users with the system. Vehicle information may include vehicle configuration information, i.e. wherein the vehicle service is activated in the following manner: verifying, based on vehicle identification information that is of the user vehicle and that is entered by a login user, whether the user vehicle satisfies a configuration condition for the interface element (e.g. users may create accounts and associate said accounts with specific vehicles using vehicle information which may include vehicle configuration information)
displaying an activation control of the interface element to the login user if the user vehicle satisfies the configuration condition for the interface element; See Paragraph [0064], (Users may log into the swap management server 118 via ride swap application 126.) See Paragraph [0039], (An authenticated user may be presented with the graphical user interface as in FIG. 2 which comprises a listing of vehicle swap information the authenticated user, i.e. displaying an activation control of the interface element to the login user if the user vehicle satisfies the configuration condition for the interface element (e.g. a user may log in to the ride swap application. In the case of a successful authentication, the user may be presented with a list of swap information relevant to their registered vehicle(s));)
and activating the interface element for the login user if it is detected that the activation control is triggered. See Paragraph [0039], (User interface 200 as in FIG. 2 may be presented to a user responsive to a user logging into the swap management server 118, i.e. activating the interface element for the login user if it is detected that the activation control is triggered.)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 3,
As discussed above with claim 2, August-Hu-Dickow discloses all of the limitations.
Dickow further discloses the step wherein activating the interface element for the login user comprises: reading user information of the login user and the vehicle identification information based on an information read request that is sent by the target vehicle platform after the target vehicle platform detects an information authorization instruction submitted by a vehicle providing service for the login user; See Paragraph [0032], (Account information 120 includes user identifiers as well as vehicle information including a VIN number or other vehicle identifier.) See Paragraph [0039], (User interface 200 may be presented to a user in response to a successful authentication. User interface 200 comprises vehicle swap information including vehicle information, i.e. reading user information of the login user and the vehicle identification information (e.g. account information 120 comprises information about both users and vehicles) based on an information read request that is sent by the target vehicle platform after the target vehicle platform detects an information authorization instruction submitted by a vehicle providing service for the login user (e.g. the platform may display a particular interface in response to a request to authenticate. The interface of FIG. 2 displays retrieved vehicle data according to vehicle information such as a VIN).)
synchronizing the user information and the vehicle identification information to the target vehicle platform, See Paragraph [0035], (Swap management server 118 may determine which vehicles 102 are associated with account information 120 at what time and may query vehicle information server 116 to retrieve vehicle information 110 associated with vehicles 102 driven by the user, i.e. synchronizing the user information and the vehicle identification information to the target vehicle platform,).)
wherein the target vehicle platform performs user vehicle verification based on the user information and the vehicle identification information; See FIGs. 9-10 & Paragraphs [0064]-[0065], (User interfaces 900 and 1000 illustrate account information for a user as well as vehicle information associated with a user respectively, i.e. wherein the target vehicle platform performs user vehicle verification based on the user information and the vehicle identification information (e.g. swap management server 118 may determine which vehicles are associated with which users at any given time).)
and receiving an activation result that is of the interface element and that is returned by the target vehicle platform when verification succeeds, See FIG. 10 & Paragraph [0065], (The user interface 1000 for displaying vehicle information for a user is displayed in response to a user selection to configure the vehicles 102 associated with the user account or as part of an initial setup sequence, i.e. receiving an activation result that is of the interface element and that is returned by the target vehicle platform when verification succeeds (e.g. a user may configure a vehicle after a successful authentication).)
and displaying the activation result by using the vehicle service. See FIG. 10 & Paragraph [0065], (The user interface 1000 for displaying vehicle information for a user is displayed in response to a user selection to configure the vehicles 102 associated with the user account or as part of an initial setup sequence, i.e. displaying the activation result by using the vehicle service.)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 4,
As discussed above with claim 3, August-Hu-Dickow discloses all of the limitations.
Dickow further discloses the step wherein before the operation of reading user information of the login user and the vehicle identification information based on an information read request that is sent by the target vehicle platform after the target vehicle platform detects an information authorization instruction submitted by a vehicle providing service for the login user is performed, the method further comprises: loading a service page of the vehicle providing service, See FIG. 9 & Paragraph [0063], (User interface 900 of FIG. 9 may be presented to new users as part of an initial setup interface, i.e. wherein before the operation of reading user information of the login user and the vehicle identification information based on an information read request that is sent by the target vehicle platform after the target vehicle platform detects an information authorization instruction submitted by a vehicle providing service for the login user is performed, the method further comprises: loading a service page of the vehicle providing service (e.g. the system may provide a user interface for account creation, which necessarily occurs before any login or vehicle information is provided as the user has not yet registered within the swap management server 118).)
wherein if the target vehicle platform detects the information authorization instruction submitted by the service providing service, the target vehicle platform generates, based on the information authorization instruction, an information read request that carries a user identifier of the login user, and sends the information read request to the service platform; See FIG. 9 & Paragraph [0063], (FIG. 9 illustrates a user interface wherein a user may enter their desired credentials for a user account including a unique identifier, name, photo, password, phone number, etc., i.e. Modifications to the user's account information is provided by the ride swap application 126 to update account information 120 maintained in the swap management server, i.e. wherein if the target vehicle platform detects the information authorization instruction submitted by the service providing service, the target vehicle platform generates, based on the information authorization instruction, an information read request that carries a user identifier of the login user, and sends the information read request to the service platform;)
wherein the information authorization instruction is submitted by the vehicle providing service after the vehicle providing service detects that an information authorization control configured on the service page is triggered. See FIG. 9 & Paragraph [0063], (FIG. 9 illustrates a user interface wherein a user may enter their desired credentials for a user account including a unique identifier, name, photo, password, phone number, etc., i.e. Modifications to the user's account information is provided by the ride swap application 126 to update account information 120 maintained in the swap management server, i.e. wherein the information authorization instruction is submitted by the vehicle providing service after the vehicle providing service detects that an information authorization control configured on the service page is triggered (e.g. a user may create an account with the system via user interface 900 in order to access the features of the swap management server 118 via the application).)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 8,
As discussed above with claim 1, August-Hu discloses all of the limitations.
August-Hu does not disclose the step wherein the service platform obtains the vehicle use information in the following manner: querying, based on a user identifier that is of a login user of the application and that is carried in the data updating request, the user vehicle associated with the vehicle service;
determining the target vehicle platform corresponding to the user vehicle in the plurality of vehicle platforms, and generating an information query request based on a vehicle service identifier of the user vehicle, wherein the vehicle service identifier is generated after the target vehicle platform activates the interface element;
and querying the vehicle use information from the target vehicle platform based on the information query request.
Dickow discloses the step wherein the service platform obtains the vehicle use information in the following manner: querying, based on a user identifier that is of a login user of the application and that is carried in the data updating request, the user vehicle associated with the vehicle service; See Paragraph [0064], (Disclosing a ride-swap server configured to receive swap requests from users indicating a swap between a first vehicle of a first user and a second vehicle of a second user. The system comprises a user interface 900 comprising authentication controls 908 configured to allow a user to configure a password or other credentials to allow the user to identify with and log into the swap management sever 118 via ride swap application 126.) See FIG. 2 & Paragraph [0039], (FIG. 2 illustrates user interface 200 comprising a listing of vehicle swap information 122 for an authenticated user including information describing an owned vehicle, note indication 206 listing "My 2015 Mustang", i.e. querying, based on a user identifier that is of a login user of the application and that is carried in the data updating request, the user vehicle associated with the vehicle service;)
determining the target vehicle platform corresponding to the user vehicle in the plurality of vehicle platforms, See Paragraph [0073], (Vehicle information server 116 may collect vehicle information 119 via method 1200 of FIG. 12 via a plurality of data adapters 112 of the plurality of vehicles over network 114, i.e. determining the target vehicle platform corresponding to the user vehicle in the plurality of vehicle platforms (e.g. each vehicle 102 stores vehicle information 110 to be provided to the system via a network 114 using data adapters 112, i.e. each vehicle is a platform).)
and generating an information query request based on a vehicle service identifier of the user vehicle, wherein the vehicle service identifier is generated after the target vehicle platform activates the interface element; See FIGs. 2 & Paragraph [0039], (FIG. 2 illustrates a user interface 200 for viewing a listing of vehicle swap information that is presented following a successful authentication into the swap management server 118 using account information 120.) See FIG. 13 & Paragraph [0078], (FIG. 13 illustrates method 1300 comprising step 1302 wherein the swap management server 118 receives a swap request for a vehicle 102 from mobile device 124 of a first user of the system, i.e. generating an information query request based on a vehicle service identifier of the user vehicle (e.g. the swap request indicates a service associated with at least two vehicles, one belonging to the user), wherein the vehicle service identifier is generated after the target vehicle platform activates the interface element (e.g. users initiate swap requests via the ride swap application 126).)
and querying the vehicle use information from the target vehicle platform based on the information query request. See FIG. 13 & Paragraph [0079], (Method 1300 comprises step 1304 wherein swap management server 118 may send a vehicle swap request to a mobile device of a second user of the system associated with a requested vehicle 102, i.e. querying the vehicle use information from the target vehicle platform based on the information query request (e.g. the requested vehicle 102's information is retrieved from vehicle 102 as part of the swap request. Swap requests include information about both vehicles being swapped as illustrated in the interface of FIG. 2 wherein the swap list includes indication 206 listing the vehicles involved in the swap).)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 9,
As discussed above with claim 1, August-Hu discloses all of the limitations.
August-Hu does not disclose the step of uploading a data switching request to the service platform if a switching instruction of the login user for the vehicle use information that is of the user vehicle and that is displayed on the interface element is detected;
receiving second vehicle use information that is of a second user vehicle associated with the vehicle service and that is delivered by the service platform based on the data switching request, wherein the vehicle use information is obtained by the service platform by querying a second vehicle platform corresponding to the second user vehicle in the plurality of vehicle platforms;
and performing, based on the second vehicle use information, data switching on the interface element displayed in the user interface.
Dickow discloses the step of uploading a data switching request to the service platform if a switching instruction of the login user for the vehicle use information that is of the user vehicle and that is displayed on the interface element is detected; See FIG. 13 & Paragraph [0078], (Disclosing a ride-swap server configured to receive swap requests from users indicating a swap between a first vehicle of a first user and a second vehicle of a second user. FIG. 13 illustrates method 1300 comprising step 1302 of receiving a vehicle swap request for a vehicle from a first user. A user may utilize a swap application 126 of a mobile device 124 to request a vehicle 102 swap, i.e. uploading a data switching request to the service platform if a switching instruction of the login user for the vehicle use information that is of the user vehicle and that is displayed on the interface element is detected (e.g. a user provides a swap request to application 126).)
receiving second vehicle use information that is of a second user vehicle associated with the vehicle service and that is delivered by the service platform based on the data switching request, See FIG. 14 & Paragraph [0087], (FIG. 14 illustrates method 1400 comprising step 1404 wherein the system retrieves vehicle information for a specified user by querying vehicle swap information 122, i.e. receiving second vehicle use information that is of a second user vehicle associated with the vehicle service and that is delivered by the service platform based on the data switching request (e.g. two users may swap vehicles via the swap management server 118. A user may request information about vehicles associated with a swap and may therefore request information about a vehicle 110 of a second user).)
wherein the vehicle use information is obtained by the service platform by querying a second vehicle platform corresponding to the second user vehicle in the plurality of vehicle platforms; See FIG. 14 & Paragraph [0088], (FIG. 14 illustrates method 1400 comprising step 1406 of retrieving vehicle information 110 according to vehicle 102 identifiers specified by vehicle swap information 122. Note [0024] wherein vehicle information is stored in vehicle system 104 of a vehicle and provided to requesting entities, i.e. wherein the vehicle use information is obtained by the service platform by querying a second vehicle platform corresponding to the second user vehicle in the plurality of vehicle platforms (e.g. as in FIG. 1, each vehicle includes vehicle port 108 used to supply vehicle information 110 to requesting devices. During a swap operation, vehicle information is obtained corresponding to the vehicles to which the swap is directed. Therefore, vehicle information 110 would be retrieved for the vehicles from their respective vehicle buses 106).
and performing, based on the second vehicle use information, data switching on the interface element displayed in the user interface. See FIG. 13 & Paragraph [0083], (Method 1300 of FIG. 13 comprises step 1312 wherein swap management server 118 determines whether a vehicle swap is concluded and marks a swap as complete at step 1314.) See Paragraph [0062], (User interface 800 may display a list of completed swaps previously completed by the user which indicates information regarding the swap including information about the vehicles 102 that were swapped, i.e. performing, based on the second vehicle use information, data switching on the interface element displayed in the user interface.)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding independent claim 12,
August discloses a data processing method, applied to a service platform of a vehicle service, and comprising: obtaining a data updating request uploaded by a detection component of an application after the detection component detects that a data updating condition of an interface element of the vehicle service is triggered, See Paragraph [0008], (Disclosing a system for guided vehicle matching via an electronic vehicle listing service configured to provide vehicle recommendations to a user via graphical user interface displayed on a client device. The system may update displayed vehicle recommendations based on received user reaction data indicating response to the one or more vehicle recommendations. Note [0030] wherein controller 210 of the client computing device 110 may process data for presentation to the user in response to user interaction or requests, i.e. a data processing method, applied to a service platform of a vehicle service, and comprising: obtaining a data updating request uploaded by a detection component of an application after the detection component detects that a data updating condition of an interface element of the vehicle service is triggered,)
wherein the interface element is configured in a user interface of a terminal device on which the application runs; See FIG. 3 & Paragraph [0047], (FIG. 3 illustrates method 300 comprising step 310 comprises a step of presenting vehicle recommendations to a user by transmitting vehicle recommendations to client computing device 110 for presentation to the user on display 202, i.e. wherein the interface element is configured in a user interface of a terminal device on which the application runs;)
August does not disclose the step of receiving vehicle use information that corresponds to a vehicle use state of the user vehicle and that is returned by the target vehicle platform, and delivering the vehicle use information to the detection component, wherein the detection component performs, based on the vehicle use information, data updating on the interface element displayed in the user interface.
Hu discloses the step of receiving vehicle use information that corresponds to a vehicle use state of the user vehicle and that is returned by the target vehicle platform, See Paragraph [0070], (Disclosing a system for determining status information of one or more hardware components in a vehicle. Health monitoring system 460 may monitor the working condition of one or more hardware and/or software components of a vehicle. Note [0080] wherein health monitoring system 460 comprises monitor 461 that may determine a status of application software based on whether the data to be processed by the application software is received, i.e. receiving vehicle use information that is of a user vehicle associated with the vehicle service and that is delivered by the service platform.)
and delivering the vehicle use information to the detection component, wherein the detection component performs, based on the vehicle use information, data updating on the interface element displayed in the user interface. See Paragraphs [0071]-[0072], (Health monitoring system 462 may comprise monitor 461 and indicator 462. Monitor 461 may monitor the status of a plurality of system components and may retrieve data corresponding to a working status of one or more electrical components and determines whether said components are working in a normal status. Indicator 462 may be configured to notify the status of the one or more hardware and/or software components to passenger in a vehicle. Indicator 462 may generate a visual or audible cue to indicate a normal status or abnormal status that is conveyed toa passenger via an onboard display of the vehicle, i.e. delivering the vehicle use information to the detection component, wherein the detection component performs, based on the vehicle use information, data updating on the interface element displayed in the user interface.)
August and Hu are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August to include the method of determining vehicle component status information as disclosed by Hu. Paragraph [0072] of Hu discloses that the system may notify a user of the status of the hardware and software components. This represents an improvement in the user experience as users may be made aware of any abnormal conditions that may be present with regard to both sensors and components of a vehicle as well as application software such as the operating system or other elements of the vehicle navigation system.
August-Hu does not disclose the step of querying, based on a user identifier that is of a login user of the application and that is carried in the data updating request, a user vehicle associated with the vehicle service;
determining a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms, and sending an information query request of the user vehicle to the target vehicle platform;
Dickow discloses the step of querying, based on a user identifier that is of a login user of the application and that is carried in the data updating request, a user vehicle associated with the vehicle service; See Paragraph [0064], (Disclosing a ride-swap server configured to receive swap requests from users indicating a swap between a first vehicle of a first user and a second vehicle of a second user. The system comprises a user interface 900 comprising authentication controls 908 configured to allow a user to configure a password or other credentials to allow the user to identify with and log into the swap management sever 118 via ride swap application 126.) See FIG. 2 & Paragraph [0039], (FIG. 2 illustrates user interface 200 comprising a listing of vehicle swap information 122 for an authenticated user including information describing an owned vehicle, note indication 206 listing "My 2015 Mustang", i.e. querying, based on a user identifier that is of a login user of the application and that is carried in the data updating request, the user vehicle associated with the vehicle service;)
determining a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms, See Paragraph [0078], (FIG. 13 illustrates method 1300 comprising step 1302 of receiving a vehicle swap request for a vehicle from a mobile device of a user using the ride swap application 126. Swap management server 118 may receive the request and store vehicle swap information 122 including information describing vehicle 102 to be requested. Note [0024] wherein vehicle information 110 is provided over a network 114 to a vehicle information server 114 from a vehicle system 104 in communication over one or more vehicle buses 106, i.e. determining a target vehicle platform corresponding to the user vehicle in a plurality of vehicle platforms)
and sending an information query request of the user vehicle to the target vehicle platform; See FIG. 14 & Paragraph [0086], (FIG. 14 illustrates a method 1400 comprising step 1402 of receiving a request for vehicle information for a user, i.e. sending an information query request of the user vehicle to the target vehicle platform (e.g. by requesting vehicle information that is delivered from vehicle 102).)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 13,
As discussed above with claim 12, August-Hu-Dickow discloses all of the limitations.
Dickow further discloses the step wherein the information query request is generated in the following manner: generating the information query request of the user vehicle based on a vehicle service identifier that is comprised in an activation result of the interface element and that is returned by the target vehicle platform. See Paragraph [0024] & [0033], (Swap management server 118 maintains vehicle swap information 122 which comprises information regarding a user's planned and/or historical vehicle 102 swaps. The information included additionally comprises unique account identifiers of users swapping vehicles 102, vehicle 102 identifiers of users swapping vehicles 102, a time period during which the swap is scheduled to take place or did take place (e.g., a start time, an end time), a swap status (e.g., requested/unaccepted, changed, accepted, declined, canceled, started or in progress, ended or completed, etc.), etc.) See FIG. 13, (FIG. 13 illustrates method 1300 comprising step 1302 of receiving a vehicle swap request for a vehicle from a first user, i.e. generating the information query request of the user vehicle based on a vehicle service identifier that is comprised in an activation result of the interface element and that is returned by the target vehicle platform (e.g. a vehicle swap request includes information identified at least two vehicles).)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 14,
As discussed above with claim 12, August-Hu-Dickow discloses all of the limitations.
Dickow further discloses the step of reading user information and vehicle identification information of the login user based on an information read request sent by the target vehicle platform, wherein the target vehicle platform sends the information read request after detecting an information authorization instruction submitted by a vehicle providing service for the login user; See Paragraph [0032], (Account information 120 includes user identifiers as well as vehicle information including a VIN number or other vehicle identifier.) See Paragraph [0039], (User interface 200 may be presented to a user in response to a successful authentication. User interface 200 comprises vehicle swap information including vehicle information, i.e. reading user information of the login user and the vehicle identification information (e.g. account information 120 comprises information about both users and vehicles) based on an information read request that is sent by the target vehicle platform after the target vehicle platform detects an information authorization instruction submitted by a vehicle providing service for the login user (e.g. the platform may display a particular interface in response to a request to authenticate. The interface of FIG. 2 displays retrieved vehicle data according to vehicle information such as a VIN).)
synchronizing the user information and the vehicle identification information to the target vehicle platform, See Paragraph [0035], (Swap management server 118 may determine which vehicles 102 are associated with account information 120 at what time and may query vehicle information server 116 to retrieve vehicle information 110 associated with vehicles 102 driven by the user, i.e. synchronizing the user information and the vehicle identification information to the target vehicle platform,).)
wherein the target vehicle platform performs user vehicle verification based on the user information and the vehicle identification information; See FIGs. 9-10 & Paragraphs [0064]-[0065], (User interfaces 900 and 1000 illustrate account information for a user as well as vehicle information associated with a user respectively, i.e. wherein the target vehicle platform performs user vehicle verification based on the user information and the vehicle identification information (e.g. swap management server 118 may determine which vehicles are associated with which users at any given time).)
and receiving an activation result that is of the interface element and that is returned by the target vehicle platform when verification succeeds, See FIG. 10 & Paragraph [0065], (The user interface 1000 for displaying vehicle information for a user is displayed in response to a user selection to configure the vehicles 102 associated with the user account or as part of an initial setup sequence, i.e. receiving an activation result that is of the interface element and that is returned by the target vehicle platform when verification succeeds (e.g. a user may configure a vehicle after a successful authentication).)
and displaying the activation result by using the vehicle service. See FIG. 10 & Paragraph [0065], (The user interface 1000 for displaying vehicle information for a user is displayed in response to a user selection to configure the vehicles 102 associated with the user account or as part of an initial setup sequence, i.e. displaying the activation result by using the vehicle service.)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 16,
As discussed above with claim 12, August-Hu-Dickow discloses all of the limitations.
Dickow further discloses the step of querying, based on a data switching request that is displayed on the interface element for the vehicle use information of the user vehicle and that is uploaded by the detection component, See FIG. 13 & Paragraph [0078], (Disclosing a ride-swap server configured to receive swap requests from users indicating a swap between a first vehicle of a first user and a second vehicle of a second user. FIG. 13 illustrates method 1300 comprising step 1302 of receiving a vehicle swap request for a vehicle from a first user. A user may utilize a swap application 126 of a mobile device 124 to request a vehicle 102 swap. Note FIG. 2 illustrating a graphical user interface comprising a swap list 204 comprising indications 206-A describing a swap between a first user's vehicle and a second user's vehicle, i.e. querying, based on a data switching request that is displayed on the interface element for the vehicle use information of the user vehicle and that is uploaded by the detection component (e.g. the swap request requires user vehicle information retrieved from vehicle 102 via data adapters 112 of the plurality of vehicles as described in [0073].)
a second user vehicle that is associated with the vehicle service and for which the interface element is activated; See FIG. 14 & Paragraph [0087], (FIG. 14 illustrates method 1400 comprising step 1404 wherein the system retrieves vehicle information for a specified user by querying vehicle swap information 122, i.e. a second user vehicle that is associated with the vehicle service (e.g. two users may swap vehicles via the swap management server 118) and for which the interface element is activated (e.g. Note [0052] the system facilitates swap requests by providing a search list 404 allowing users to enter criteria to search for vehicles registered with the ride swap application, i.e. the interface element is activated).)
determining a second vehicle platform corresponding to the second user vehicle in the plurality of vehicle platforms, and querying second vehicle use information of the second user vehicle from the second vehicle platform; See FIG. 14 & Paragraph [0088], (FIG. 14 illustrates method 1400 comprising step 1406 of retrieving vehicle information 110 according to vehicle 102 identifiers specified by vehicle swap information 122. Note [0024] wherein vehicle information is stored in vehicle system 104 of a vehicle and provided to requesting entities, i.e. determining a second vehicle platform corresponding to the second user vehicle in the plurality of vehicle platforms (e.g. as in FIG. 1, each vehicle includes vehicle port 108 used to supply vehicle information 110 to requesting devices. During a swap operation, vehicle information is obtained corresponding to the vehicles to which the swap is directed. Therefore, vehicle information 110 would be retrieved for the vehicles from their respective vehicle buses 106). See FIG. 14 & Paragraph [0087], (FIG. 14 illustrates method 1400 comprising step 1404 wherein the system retrieves vehicle information for a specified user by querying vehicle swap information 122, i.e. and querying second vehicle use information of the second user vehicle from the second vehicle platform;)
and receiving the second vehicle use information returned by the second vehicle platform, See Paragraph [0035], (Swap management server 118 may access vehicle information 110 to retrieve logged vehicle information across vehicles 102 driven by a user, i.e. receiving the second vehicle use information returned by the second vehicle platform)
and delivering the second vehicle use information to the detection component, See FIG. 7A & Paragraph [0059], (The system may provide a user interface 700 for describing a swap request which includes information about a requested vehicle. In the example of FIG. 7A a Mustang GT, i.e. delivering the second vehicle use information to the detection component (e.g. swap management server 118 manages vehicle information for display at ride swap application 126).)
wherein the detection component performs data switching on the interface element based on the second vehicle use information. See FIG. 13 & Paragraph [0079], (FIG. 13 illustrates method 1300 comprising step 1302 of receiving a vehicle swap request for a vehicle from a first user. A user may utilize a swap application 126 of a mobile device 124 to request a vehicle 102 swap. At step 1304, the system provides the vehicle swap request to the second user associated with the requested vehicle, i.e. wherein the detection component performs data switching on the interface element based on the second vehicle use information.)
August, Hu and Dickow are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the functionality for swapping vehicles as disclosed by Dickow. Paragraph [0037] of Dickow discloses that the ride swap application allows users to search vehicles for swap, request to swap a user's vehicle, accept/reject vehicle swap requests, receive location information for a vehicle, and other functionalities that facilitate the process of swapping vehicles to users that might not be socially or physically proximate.
Regarding dependent claim 23,
The claim is analogous to the subject matter of dependent claim 2 directed to a computing device and is rejected under similar rationale.
Regarding dependent claim 24,
The claim is analogous to the subject matter of dependent claim 3 directed to a computing device and is rejected under similar rationale.
Regarding dependent claim 25,
The claim is analogous to the subject matter of dependent claim 4 directed to a computing device and is rejected under similar rationale.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over August in view of Hu and Dickow as applied to claim 3 above, and further in view of Fang et al. (US PGPUB No. 2021/0158460; Pub. Date: May 27, 2021).
Regarding dependent claim 5,
As discussed above with claim 3, August-Hu-Dickow discloses all of the limitations.
August-Hu-Dickow does not disclose the step wherein the manner of the user vehicle verification comprises: querying, based on the vehicle identification information, vehicle user information having an association relationship with the vehicle identification information;
verifying whether the vehicle user information matches the user information;
and if the vehicle user information matches the user information, determining that a verification result of the user vehicle verification is that verification succeeds.
Fang discloses the step wherein the manner of the user vehicle verification comprises: querying, based on the vehicle identification information, vehicle user information having an association relationship with the vehicle identification information; See Paragraph [0046], (Disclosing a system for processing charging information of a vehicle by transmitting vehicle information to a cloud server from a user terminal. The cloud server may allow a user to access the vehicle according ot an authentication process. The user terminal may transmit vehicle identity information and user information to the cloud server for authentication, i.e. querying, based on the vehicle identification information, vehicle user information having an association relationship with the vehicle identification information;)
verifying whether the vehicle user information matches the user information; See Paragraph [0046], (The cloud server authenticates the user terminal and allows the user to access the vehicle, such as by unlocking the vehicle for use, i.e. verifying whether the vehicle user information matches the user information;)
and if the vehicle user information matches the user information, determining that a verification result of the user vehicle verification is that verification succeeds. See Paragraph [0029], (A user can login to a client-end App at the user terminal wherein the system may display a list of vehicles that need ot be charged according to vehicle identify information received by the cloud server from the user terminal, i.e. if the vehicle user information matches the user information, determining that a verification result of the user vehicle verification is that verification succeeds (e.g. access to the user interface and listing of vehicles represents a successful authentication.)
August, Hu, Dickow and Fang are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu-Dickow to include the method of authenticating users according to vehicle information as disclosed by Fang. Paragraph [0004] of Fang discloses that the system is directed to incentivizing users to charge rental vehicles in order to reduce the workload of operation maintenance personnel. This is achieved by providing users with vehicle charging information for a vehicle currently in their use.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over August in view of Hu as applied to claim 1 above, and further in view of KANDASAMY et al. (US PGPUB No. 2022/0028187; Pub. Date: Jan. 27, 2022).
Regarding dependent claim 6,
As discussed above with claim 1, August-Hu discloses all of the limitations.
August-Hu does not disclose the step of receiving vehicle abnormality information delivered by the service platform, wherein the vehicle abnormality information is sent to the service platform after the target vehicle platform detects an abnormal state of the user vehicle;
and performing, based on the vehicle abnormality information, data reminding on the interface element displayed in the user interface.
KANDASAMY discloses the step of receiving vehicle abnormality information delivered by the service platform, See Paragraph [0035], (Disclosing a system for detecting vehicle abnormalities based on data from one or more servers and a diagnostic model. The system is directed to a process for detecting vehicle abnormalities while a vehicle of a vehicle fleet is being used by a user. Once an abnormality is detected, the vehicle transmits a notification regarding the abnormality to a fleet management system that manages the fleet device, i.e. receiving vehicle abnormality information that is sent by the target vehicle platform after the target vehicle platform detects an abnormal state of the user vehicle;)
wherein the vehicle abnormality information is sent to the service platform after the target vehicle platform detects an abnormal state of the user vehicle; See Paragraph [0040], (Vehicle controller 116 comprises notification module 134 configured to transmit a notification to the FM system 102 in response to an abnormality being detected. Note [0050] wherein the FM system 102 may be accessible by a computing device of a user, i.e. delivering the vehicle abnormality information to the interface element)
and performing, based on the vehicle abnormality information, data reminding on the interface element displayed in the user interface. See Paragraph [0040], (Vehicle controller 116 comprises notification module 134 configured to transmit a notification to the FM system 102 in response to an abnormality being detected.) See Paragraph [0049], (User interface 120 can notify a user of a detected vehicle anomaly such as via a message displayed by visual system 144 and/or an audio message broadcasted via an audio system, i.e. wherein the interface element performs, based on the vehicle abnormality information, data reminding on the interface element displayed in the user interface.)
August, Hu and KANDASAMY are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the method of delivering messages to a user describing potential issues with a vehicle as disclosed by KANDASAMY. Paragraph [0060] of KANDASAMY discloses that the system may diagnose a particular vehicle abnormality and automatically transmit an invoice to a particular user such that the vehicle abnormality may be remedied. This process allows for abnormalities to be detected without requiring human inspection of every component of a vehicle.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over August in view of Hu and Dickow as applied to claim 12 above, and further in view of KANDASAMY et al. (US PGPUB No. 2022/0028187; Pub. Date: Jan. 27, 2022).
Regarding dependent claim 15,
As discussed above with claim 12, August-Hu-Dickow discloses all of the limitations.
August-Hu-Dickow does not disclose the step of receiving vehicle abnormality information that is sent by the target vehicle platform after the target vehicle platform detects an abnormal state of the user vehicle;
and delivering the vehicle abnormality information to the interface element,
wherein the interface element performs, based on the vehicle abnormality information, data reminding on the interface element displayed in the user interface.
KANDASAMY discloses the step of receiving vehicle abnormality information that is sent by the target vehicle platform after the target vehicle platform detects an abnormal state of the user vehicle; See Paragraph [0035], (Disclosing a system for detecting vehicle abnormalities based on data from one or more servers and a diagnostic model. The system is directed to a process for detecting vehicle abnormalities while a vehicle of a vehicle fleet is being used by a user. Once an abnormality is detected, the vehicle transmits a notification regarding the abnormality to a fleet management system that manages the fleet device, i.e. receiving vehicle abnormality information that is sent by the target vehicle platform after the target vehicle platform detects an abnormal state of the user vehicle;)
and delivering the vehicle abnormality information to the interface element, See Paragraph [0040], (Vehicle controller 116 comprises notification module 134 configured to transmit a notification to the FM system 102 in response to an abnormality being detected. Note [0050] wherein the FM system 102 may be accessible by a computing device of a user, i.e. delivering the vehicle abnormality information to the interface element)
wherein the interface element performs, based on the vehicle abnormality information, data reminding on the interface element displayed in the user interface. See Paragraph [0040], (Vehicle controller 116 comprises notification module 134 configured to transmit a notification to the FM system 102 in response to an abnormality being detected.) See Paragraph [0049], (User interface 120 can notify a user of a detected vehicle anomaly such as via a message displayed by visual system 144 and/or an audio message broadcasted via an audio system, i.e. wherein the interface element performs, based on the vehicle abnormality information, data reminding on the interface element displayed in the user interface.)
August, Hu, Dickow and KANDASAMY are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu-Dickow to include the method of delivering messages to a user describing potential issues with a vehicle as disclosed by KANDASAMY. Paragraph [0060] of KANDASAMY discloses that the system may diagnose a particular vehicle abnormality and automatically transmit an invoice to a particular user such that the vehicle abnormality may be remedied. This process allows for abnormalities to be detected without requiring human inspection of every component of a vehicle.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over August in view of Hu as applied to claim 1 above, and further in view of KANDASAMY et al. (US PGPUB No. 2022/002818; Pub. Date: Jan. 27, 2022).
Regarding dependent claim 10,
As discussed above with claim 1, August-Hu discloses all of the limitations.
August-Hu does not disclose the step of uploading the data updating request to the service platform if it is detected that a data updating time of the interface element arrives, wherein the service platform queries, based on the data updating request, first vehicle use information and second vehicle use information of the user vehicle and the second user vehicle for which the interface element is activated;
receiving the first vehicle use information of the user vehicle and the second vehicle use information of the second user vehicle that are delivered by the service platform;
displaying the first vehicle use information on the interface element;
and displaying the second vehicle use information on the interface element if a switching instruction for the interface element is detected.
Monassebian discloses the step of uploading the data updating request to the service platform if it is detected that a data updating time of the interface element arrives, See Paragraphs [0022]-[0023] & [0039], (Disclosing a personal electronic parking system adapted to identify, track, predict, alert, manage and collect payment for parking spaces. The system allows users to create accounts and register a plurality of vehicles which may be managed via a mobile application on a mobile device. Geolocation coordinate data is checked periodically by the automatic parking payment process (PPP) and may be dynamically updated depending on external data. Geolocation coordinates of a parked vehicle are determined based on a geolocation database query, automatic geolocation, GPS, manual input, etc., i.e. uploading the data updating request to the service platform if it is detected that a data updating time of the interface element arrives (e.g. GPS data is updated periodically for user vehicles).)
wherein the service platform queries, based on the data updating request, first vehicle use information and second vehicle use information of the user vehicle and the second user vehicle for which the interface element is activated; See Paragraph [0039], (Geolocation coordinate data is checked periodically by the automatic parking payment process (PPP) and may be dynamically updated depending on external data. Geolocation coordinates of a parked vehicle are determined based on a geolocation database query, automatic geolocation, GPS, manual input, etc., i.e. wherein the service platform queries, based on the data updating request, first vehicle use information and second vehicle use information of the user vehicle and the second user vehicle for which the interface element is activated;)
receiving the first vehicle use information of the user vehicle and the second vehicle use information of the second user vehicle that are delivered by the service platform; See Paragraph [0022], (A user may register multiple vehicles on the same account, which allows users to access a "Homepage" interface which displays information such as a current parking session, parking payment activity and history, notification settings, language choices, payment methods, and/or vehicle options.) See Paragraph [0039], (Geolocation coordinate data is checked periodically by the automatic parking payment process (PPP) and may be dynamically updated depending on external data, i.e. receiving the first vehicle use information of the user vehicle and the second vehicle use information of the second user vehicle that are delivered by the service platform (e.g. the platform tracks vehicle geolocation data for a user's registered vehicles).)
displaying the first vehicle use information on the interface element; See Paragraphs [0022]-[0023], (A user may register multiple vehicles on the same account, which allows users to access a "Homepage" interface which displays information such as a current parking session, parking payment activity and history, notification settings, language choices, payment methods, and/or vehicle options. The user interface receives, processes and displays information available on-street and off-street parking information in real-time via a mobile app of a mobile device, i.e. displaying the first vehicle use information on the interface element (e.g. a mobile app interface displays vehicle information for any of a user's registered vehicles).)
and displaying the second vehicle use information on the interface element if a switching instruction for the interface element is detected. See Paragraph [0035], (The system allows users to select any of the vehicles associated with their account to complete a parking payment transaction. Once the transaction is complete, the user's interface will display parking information of an active parking session and its duration, i.e. displaying the second vehicle use information on the interface element if a switching instruction for the interface element is detected (e.g. the system may display the information for a selected vehicle upon completion of the transaction, which includes first, second, third, etc. vehicles registered to a user account).)
August, Hu and Monassebian are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include the method of managing vehicle information such as for parking as disclosed by Monassebian. Paragraph [0054] of Monassebian discloses that the system allows a user to share and update information on a map view that allows other users of the application to see and benefit from said information.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over August in view of Hu as applied to claim 1 above, and further in view of Cain, JR et al. (US PGPUB No. 2022/0108291; Pub. Date: Apr. 7, 2022).
Regarding dependent claim 11,
As discussed above with claim 1, August-Hu discloses all of the limitations.
August-Hu does not disclose the step of obtaining a vehicle service request submitted by a login user by using the interface element;
and uploading the vehicle service request to the service platform, to perform vehicle service processing of the user vehicle on the service platform.
Cain, JR discloses the step of obtaining a vehicle service request submitted by a login user by using the interface element; See Paragraph [0044], (Disclosing a system for processing requests for particular data provided by a transport. The system employs an instant solution implemented via driving systems comprising authorizing a vehicle for a service via an automated and quick authentication scheme. An example is provided wherein a vehicle may provide a communication signal that identifies a vehicle having an active profile linked to an account that is authorized to accept a service such as a charging station or fuel pump. Note [0060] wherein a mobile phone 220 may provide information to a processor 204 of a transport node which may initiate node 202 to take an action, i.e. obtaining a vehicle service request submitted by a login user by using the interface element (e.g. a user may submit a request using mobile phone 220 such as via an application running on the device).)
and uploading the vehicle service request to the service platform, to perform vehicle service processing of the user vehicle on the service platform. See Paragraph [0044], (The user may instruct the vehicle to provide a communication signal that provides an identification of the vehicle to the service and/or charging station in order to provide access to the request in response to the authentication, i.e. uploading the vehicle service request to the service platform, to perform vehicle service processing of the user vehicle on the service platform (e.g. the vehicle communicates the user's request to the charging station in order to authenticate the user's account and provide the applicable service).)
August, Hu and Cain, JR are analogous art because they are in the same field of endeavor, vehicle management systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of August-Hu to include functionality for communicating information about a user vehicle for requesting a service as disclosed by Cain, JR. Paragraph [0044] of Cain, JR discloses that the instant solution may allow a vehicle operator or autonomous transport to request and receive services without any delays due to the quick authentication scheme.
Response to Arguments
Applicant’s cancellation of claims 17-18 and 20-22 is acknowledged by the examiner. The corresponding rejections have been withdrawn.
Applicant’s arguments with respect to claim(s) 1, 12 and 19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s amendments have modified the scope of the claims and necessitated the new grounds of rejection presented in this Office Action.
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 Fernando M Mari whose telephone number is (571)272-2498. The examiner can normally be reached Monday-Friday 7am-4pm.
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, Ann J. Lo can be reached at (571) 272-9767. 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.
/FMMV/Examiner, Art Unit 2159
/AMRESH SINGH/Primary Examiner, Art Unit 2159