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 .
DETAILED ACTION
This office action is in response to applicant’s amendment and remarks received on January 21, 2026. Claims 1-20 are pending in the application. Claims 1, 4-6, 10, and 12-20 have been amended.
Claim Interpretation - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AlA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a driving data acquisition unit that acquires…”, “a first recommend function specifying unit that specifies…”, and “an information distribution unit that distributes…”, in claim 13; “an inquiry information acquisition unit that acquires…”, “a second recommend function specifying unit that specifies…”, and “an information distribution unit that distributes…”, in claim 14; “a comment information acquisition unit that acquires…”, “a third recommend function specifying unit that specifies…”, and “an information distribution unit that distributes…”, in claim 15; and “a recommend function presentation unit that presents…”, in claim 16.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AlA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation: for example, para. [0129]-[0132], i.e., the function management server and the in-vehicle system include at least one of (i) a circuit and (ii) a processor having a memory storing computer program code configured to perform the recited functions, for example, by reading and executing a program stored in a memory.
If applicant wishes to provide further explanation or dispute the examiner's interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AlA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AlA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AlIA 35 U.S.C. 112, sixth paragraph.
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 of this title, 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.
Claims 1-3, 6-9, 10, 12, 13, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (U.S. Publication No. 2019/0100216 A1; hereinafter as “Volos”) in view of Maeda et al. (U.S. Publication No. 2022/0111855 A1; hereinafter as “Maeda”), and further in view of Rao et al. (U.S. Publication No. 2015/0307106 A1; hereinafter as “Rao”).
As per claim 1, Volos discloses a data communication system (fig. 1: a driver risk assessment system 10) comprising:
a function management server (figs. 1 & 3: a driver risk assessment (DRA) server 12) that manages a function related to a vehicle (a target vehicle 20 and other vehicles 22) (see e.g., para. [0037]); and
an in-vehicle system mounted in the vehicle (see e.g., fig. 2; para. [0039]-[0050]: control modules in vehicles 20, 22), wherein:
the function management server (DRA server 12) and the in-vehicle system (control modules in vehicles 20, 22) perform data communication with each other (see e.g., para. [0051]);
the function management server acquires a driving data of a driver of the vehicle from the in-vehicle system (see e.g., fig. 3; para. [0052] & [0074]-[0075]), specifies a recommend function by analyzing a driving technique of the driver based on an acquired driving data, and distributes recommend function information related to a specified recommend function to the in-vehicle system (see e.g., para. [0037]: the risk assessment server sends feedback (e.g., risk scores, driver behavior information) to vehicles and other systems);
upon receiving the recommend function information distributed from the function management server, the in-vehicle system presents the recommend function specified by the received recommend function information to the driver (see e.g., para. [0037]: “The vehicles 20, 22 may perform various tasks based on the feedback including reporting the assessment scores to the drivers, altering autonomous vehicle operation, training the drivers how to operate the vehicles 20, 22 in certain locations, etc.”; and para. [0081]: the vehicle control modules may adjust vehicle components (engine, brakes, steering, etc.), generate audio/video outputs, and attempt to influence driver behavior based on average driver patterns or anomalies).
Volos does not explicitly disclose the recommended function (feedback) is executable by the in-vehicle system mounted on the vehicle.
However, in the same field of endeavor, Maeda discloses: the recommended function is executable by the in-vehicle system mounted on the vehicle (see e.g., para. [0085]-[0103]: “In step S201, the CPU 20A determines whether or not the received command is for the activation of the recommended function. In a case in which the CPU 20A determines that the received command is for the activation of the recommended function (i.e., if the result of the determination in step S201 is YES), then the routine proceeds to step S202”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “For example, in a case in which, based on the vehicle speed information, the vehicle 12 is caught in a traffic jam, and based on the image information, an intention of driver fatigue is acquired for the vehicle occupant P, in the central server 30, an automatic brake hold function is selected as the recommended function. In a case in which the vehicle 12 is traveling, then the suggestion of activating the automatic brake hold function is selected and a command pertaining to this suggestion is transmitted to the vehicle on-board unit 20. In a case in which the vehicle 12 is stopped, then the activation of the automatic brake hold function is selected, and a command pertaining to activation is transmitted to the vehicle on-board unit 20”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos to incorporate the teachings of Maeda to provide an executable recommended function to the in-vehicle system. Doing so allows to achieve a lightening of the burden on the vehicle occupant for performing the operation, as recognized by Maeda (para. [0103]).
Maeda discloses that each program stored in the vehicle on-board unit is downloaded from an external device (para. [0124]), however, Volos in view of Maeda does not explicitly disclose that software of the recommended function is downloadable from the function management server.
However, in the same field of endeavor, Rao discloses: software of the recommended function is downloadable from the function management server (see e.g., para. [0013], [0031]-[0034]: “A recommendation application 210 installed on the VCS 1 may be configured to provide recommendations to the user regarding mobile applications 204 to be downloaded to the nomadic device 53 (or to the VCS 1 via the nomadic device 53) for use by the driver”; “the mobile application 204 may be included on the nomadic device 53 as part of a default installation. In other cases, the mobile application 204 may be downloaded and installed by a user of the nomadic device 53, such as from an online application store 208”; para. [0054]: where the application store 208 may be a server; Also see para. [0045]: “If the application recommendation module 324 determines that certain mobile applications 204 are installed on other vehicles 31 having the same or similar identified driver characteristics 312, but not on the vehicle 31, then the application recommendation module 324 may generate an application recommendation 326 recommending those mobile applications 204 to the driver”; and para. [0048]: “the driver may receive the application recommendations 326, and may choose to install the recommended mobile applications 204. Accordingly, using the application recommendations 326 determined by the recommendation application 210, the driver may be able to download and utilize mobile applications 204 that may help the driver to improve his or her driving experience”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maeda to incorporate the teachings of Rao to provide downloading of software of the recommended function from the server. Doing so enables recommending the driver to download the application that would be beneficial for the particular driver in enhancing his or her driving experience, as recognized by Rao (para. [0013]).
Independent claim 13 (directed to a function management server) recites corresponding features of system claim 1. Therefore, claim 13 is rejected for the same reasons set forth in claim 1 above for having similar limitations and being similar in scope.
Independent claim 17 (directed to a non-transitory CRM claim) recites corresponding features of system claim 1. Therefore, claim 17 is rejected for the same reasons set forth in claim 1 above for having similar limitations and being similar in scope.
As per claim 2, claim 1 is incorporated and Volos further discloses: wherein:
the function management server (DRA server 12) specifies the recommend function by comparing the driving data of the driver acquired from the in-vehicle system with a driving data of another driver (see e.g., para. [0075]-[0076], [0096] & [0102]-[0103]).
As per claim 3, claim 2 is incorporated and Volos further discloses: wherein:
the function management server specifies the recommend function by comparing the driving data of the driver acquired from the in-vehicle system with the driving data of the another driver at a same place (see e.g., para. [0075]-[0076], [0096]-[0099] & [0102]-[0103]: others drivers driving in a same location and under similar driving conditions).
As per claim 6, claim 1 is incorporated and Rao further discloses: wherein: the function management server determines whether the recommend function is installed in a target vehicle, and distributes the software of the recommend function to the in-vehicle system when the function management server determines that the recommend function is not installed in the target vehicle; and the in-vehicle system downloads and pre-installs the software of the recommend function from the function management server before the driver determines to use the recommend function (see para. [0045]: “If the application recommendation module 324 determines that certain mobile applications 204 are installed on other vehicles 31 having the same or similar identified driver characteristics 312, but not on the vehicle 31, then the application recommendation module 324 may generate an application recommendation 326 recommending those mobile applications 204 to the driver.”; para. [0048]: “the driver may receive the application recommendations 326, and may choose to install the recommended mobile applications 204. Accordingly, using the application recommendations 326 determined by the recommendation application 210, the driver may be able to download and utilize mobile applications 204 that may help the driver to improve his or her driving experience”).
As per claim 7, claim 6 is incorporated and Rao further discloses: wherein: the in-vehicle system downloads and pre-installs the software of the recommend function from the function management server when presenting the recommend function to the driver (see, e.g., para. [0047]-[0048]).
As per claim 8, claim 7 is incorporated and Rao further discloses: wherein: the in-vehicle system presents the recommend function to the driver for a limited time (see e.g., para. [0047]: the application recommendation module 324 may be configured to provide the application recommendations 326 to the driver using the HMI 202 of the vehicle 31, such as via the display 4, for selection by the driver for installation; It would be obvious to provide the recommendation for a limited time on the vehicle’s display to ensure timely awareness without causing driver distraction).
As per claim 9, claim 1 is incorporated and Volos further discloses: wherein:
the in-vehicle system intervenes in a driving operation of the driver when it is necessary to intervene in the driving operation of the driver (e.g., para. [0037] & [0080]-[0082]: the vehicles 20, 22 may perform various tasks based on the feedback including altering autonomous vehicle operation).
As per claim 10, claim 9 is incorporated and Volos further discloses: wherein:
the in-vehicle system executes a driving support when the vehicle passes another vehicle as an intervention in the driving operation of the driver (see e.g., para. [0006], [0037] & [0081]-[0082]).
As per claim 12, claim 1 is incorporated and Volos further discloses: wherein:
the in-vehicle system acquires a usage history of a function and a behavior history (see e.g., para. [0074]-[0075]: for example, the DRA driver history DB 172 which stores features of behaviors of drivers for locations and conditions, and the DRA vehicle history DB 178 which stores vehicle history data, such as steering angles, throttle positions, brake percentages, acceleration rates, and/or other features for locations and conditions); and
the function management server specifies the recommend function based on the usage history of the function and the behavior history of the driver, and distributes recommend function information related to a specified recommend function to the in-vehicle system (e.g., para. [0076]; Also see Rao, para. [0044]-[0045]: “The application recommendation module 324 may be configured to access the driver character and application matching database 322 and, based on the current and/or historical driver characteristics 312, determine the application recommendations 326 for the driver”).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Volos in view of Maeda and Rao, and further in view of Washimi et al. (Japanese Publication No. JP2009036675A; machine translation provided by Applicant, hereinafter as “Washimi”).
As per claim 11, claim 1 is incorporated and Volos in view of Maeda and Rao does not explicitly disclose: wherein: the in-vehicle system inquires of the driver related to a satisfaction level of the driver with a presented recommend function after presenting the recommend function to the driver; and the function management server collects a response result related to the satisfaction level with the presented recommend function from driver.
However, in the same field of endeavor, Washimi discloses: wherein: the in-vehicle system (fig. 1: in-vehicle device 1) inquires (see the feature of distributing a "questionnaire" to the "driver", etc.) of the driver related to a satisfaction level of the driver with a presented recommend function after presenting the recommend function to the driver (“provided route”); and the function management server (fig. 1: server device 3) collects a response result related to the satisfaction level with the presented recommend function from driver (see the feature of "recovering the "questionnaire" from the "driver," etc.) (see Washimi, e.g., fig. 1; para. [0005]-[0006], [0012]-[0014] & [0020]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maeda and Rao to incorporate the teachings of Washimi to provide collecting a response result related to the satisfaction level with the presented recommend function from driver. Doing so enables the system to gather and analyze the user’s satisfaction with the current recommendation, allowing it to deliver a more refined recommendation next time, as recognized by Washimi (para. [0005]).
Claims 4, 14, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Volos in view of Maeda and Rao, and further in view of Neubauer (U.S. Publication No. 2020/0378783 A1).
As per claim 4, Volos discloses a data communication system (fig. 1: a driver risk assessment system 10) comprising:
a function management server (figs. 1 & 3: a driver risk assessment (DRA) server 12) that manages a function related to a vehicle (a target vehicle 20 and other vehicles 22) (see e.g., para. [0037]); and
an in-vehicle system mounted in the vehicle (see e.g., fig. 2; para. [0039]-[0050]: control modules in vehicles 20, 22), wherein:
the function management server (DRA server 12) and the in-vehicle system (control modules in vehicles 20, 22) perform data communication with each other (see e.g., para. [0051]);
the function management server acquires information of a driver of the vehicle (see e.g., fig. 3; para. [0052] & [0074]-[0075]), specifies a recommend function, and distributes recommend function information related to a specified recommend function to the in-vehicle system (see e.g., para. [0037]: the risk assessment server sends feedback (e.g., risk scores, driver behavior information) to vehicles and other systems);
upon receiving the recommend function information distributed from the function management server, the in-vehicle system presents the recommend function specified by received recommend function information to the driver (see e.g., para. [0037]: “The vehicles 20, 22 may perform various tasks based on the feedback including reporting the assessment scores to the drivers, altering autonomous vehicle operation, training the drivers how to operate the vehicles 20, 22 in certain locations, etc.”; and para. [0081]: the vehicle control modules may adjust vehicle components (engine, brakes, steering, etc.), generate audio/video outputs, and attempt to influence driver behavior based on average driver patterns or anomalies).
Volos does not explicitly disclose the recommended function (feedback) is executable by the in-vehicle system mounted on the vehicle.
However, in the same field of endeavor, Maeda discloses: the recommended function is executable by the in-vehicle system mounted on the vehicle (see e.g., para. [0085]-[0103]: “In step S201, the CPU 20A determines whether or not the received command is for the activation of the recommended function. In a case in which the CPU 20A determines that the received command is for the activation of the recommended function (i.e., if the result of the determination in step S201 is YES), then the routine proceeds to step S202”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “For example, in a case in which, based on the vehicle speed information, the vehicle 12 is caught in a traffic jam, and based on the image information, an intention of driver fatigue is acquired for the vehicle occupant P, in the central server 30, an automatic brake hold function is selected as the recommended function. In a case in which the vehicle 12 is traveling, then the suggestion of activating the automatic brake hold function is selected and a command pertaining to this suggestion is transmitted to the vehicle on-board unit 20. In a case in which the vehicle 12 is stopped, then the activation of the automatic brake hold function is selected, and a command pertaining to activation is transmitted to the vehicle on-board unit 20”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos to incorporate the teachings of Maeda to provide an executable recommended function to the in-vehicle system. Doing so allows to achieve a lightening of the burden on the vehicle occupant for performing the operation, as recognized by Maeda (para. [0103]).
Maeda discloses that each program stored in the vehicle on-board unit is downloaded from an external device (para. [0124]), however, Volos in view of Maeda does not explicitly disclose that software of the recommended function is downloadable from the function management server.
However, in the same field of endeavor, Rao discloses: software of the recommended function is downloadable from the function management server (see e.g., para. [0013], [0031]-[0034]: “A recommendation application 210 installed on the VCS 1 may be configured to provide recommendations to the user regarding mobile applications 204 to be downloaded to the nomadic device 53 (or to the VCS 1 via the nomadic device 53) for use by the driver”; “the mobile application 204 may be included on the nomadic device 53 as part of a default installation. In other cases, the mobile application 204 may be downloaded and installed by a user of the nomadic device 53, such as from an online application store 208”, and para, [0054]: where the application store 208 may be a server; also see para. [0045]: “If the application recommendation module 324 determines that certain mobile applications 204 are installed on other vehicles 31 having the same or similar identified driver characteristics 312, but not on the vehicle 31, then the application recommendation module 324 may generate an application recommendation 326 recommending those mobile applications 204 to the driver.”; para. [0048]: “the driver may receive the application recommendations 326, and may choose to install the recommended mobile applications 204. Accordingly, using the application recommendations 326 determined by the recommendation application 210, the driver may be able to download and utilize mobile applications 204 that may help the driver to improve his or her driving experience”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maeda to incorporate the teachings of Rao to provide downloading of software of the recommended function from the server. Doing so enables recommending the driver to download the application that would be beneficial for the particular driver in enhancing his or her driving experience, as recognized by Rao (para. [0013]).
Volos in view of Maeda and Rao does not explicitly disclose the function management server acquires inquiry information of a driver of the vehicle in an automatic conversation service.
However, in the same field of endeavor, Neubauer discloses: a function management server (fig. 1: routing platform 111) acquires inquiry information of a driver of the vehicle in an automatic conversation service, and provides a recommend function (see e.g., para. [0028], [0038]-[0041] & [0060]-[0067]: the navigation system provides a conversational voice-based user interface; the user issues a voice command; the mapping platform 111 can generate a series of justification messages based on different argumentative reason classes to present to a user).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maedato and Rao to incorporate the teachings of Neubauer to provide a recommend function based on inquiry information of a driver of the vehicle in an automatic conversation service. Doing so allows the system to specify recommended function(s) by taking the user inquiry or interaction into account, as recognized by Neubauer (para. [0025]).
Independent claim 14 (directed to a function management server) recites corresponding features of system claim 4. Therefore, claim 14 is rejected for the same reasons set forth in claim 4 above for having similar limitations and being similar in scope.
Independent claim 18 (directed to a non-transitory CRM claim) recites corresponding features of system claim 4. Therefore, claim 18 is rejected for the same reasons set forth in claim 4 above for having similar limitations and being similar in scope.
Claims 5, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Volos in view of Suzuki (U.S. Publication No. 2019/0080596 A1).
As per claim 5, Volos discloses a data communication system (fig. 1: a driver risk assessment system 10) comprising:
a function management server (figs. 1 & 3: a driver risk assessment (DRA) server 12) that manages a function related to a vehicle (a target vehicle 20 and other vehicles 22) (see e.g., para. [0037]); and
an in-vehicle system mounted in the vehicle (see e.g., fig. 2; para. [0039]-[0050]: control modules in vehicles 20, 22), wherein:
the function management server (DRA server 12) and the in-vehicle system (control modules in vehicles 20, 22) perform data communication with each other (e.g., para. [0051]);
the function management server acquires information of a driver of the vehicle (see e.g., fig. 3; para. [0052] & [0074]-[0075]), specifies a recommend function, and distributes recommend function information related to a specified recommend function to the in-vehicle system (see e.g., para. [0037]: the risk assessment server sends feedback (e.g., risk scores, driver behavior information) to vehicles and other systems);
upon receiving the recommend function information distributed from the function management server, the in-vehicle system presents the recommend function specified by received recommend function information to the driver (see e.g., para. [0037]: “The vehicles 20, 22 may perform various tasks based on the feedback including reporting the assessment scores to the drivers, altering autonomous vehicle operation, training the drivers how to operate the vehicles 20, 22 in certain locations, etc.”; and para. [0081]: the vehicle control modules may adjust vehicle components (engine, brakes, steering, etc.), generate audio/video outputs, and attempt to influence driver behavior based on average driver patterns or anomalies).
Volos does not explicitly disclose the recommended function (feedback) is executable by the in-vehicle system mounted on the vehicle.
However, in the same field of endeavor, Maeda discloses: the recommended function is executable by the in-vehicle system mounted on the vehicle (see e.g., para. [0085]-[0103]: “In step S201, the CPU 20A determines whether or not the received command is for the activation of the recommended function. In a case in which the CPU 20A determines that the received command is for the activation of the recommended function (i.e., if the result of the determination in step S201 is YES), then the routine proceeds to step S202”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “For example, in a case in which, based on the vehicle speed information, the vehicle 12 is caught in a traffic jam, and based on the image information, an intention of driver fatigue is acquired for the vehicle occupant P, in the central server 30, an automatic brake hold function is selected as the recommended function. In a case in which the vehicle 12 is traveling, then the suggestion of activating the automatic brake hold function is selected and a command pertaining to this suggestion is transmitted to the vehicle on-board unit 20. In a case in which the vehicle 12 is stopped, then the activation of the automatic brake hold function is selected, and a command pertaining to activation is transmitted to the vehicle on-board unit 20”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos to incorporate the teachings of Maeda to provide an executable recommended function to the in-vehicle system. Doing so allows to achieve a lightening of the burden on the vehicle occupant for performing the operation, as recognized by Maeda (para. [0103]).
Maeda discloses that each program stored in the vehicle on-board unit is downloaded from an external device (para. [0124]), however, Volos in view of Maeda does not explicitly disclose that software of the recommended function is downloadable from the function management server.
However, in the same field of endeavor, Rao discloses: software of the recommended function is downloadable from the function management server (see e.g., para. [0013], [0031]-[0034]: “A recommendation application 210 installed on the VCS 1 may be configured to provide recommendations to the user regarding mobile applications 204 to be downloaded to the nomadic device 53 (or to the VCS 1 via the nomadic device 53) for use by the driver”; “the mobile application 204 may be included on the nomadic device 53 as part of a default installation. In other cases, the mobile application 204 may be downloaded and installed by a user of the nomadic device 53, such as from an online application store 208”, and para, [0054]: where the application store 208 may be a server; also see para. [0045]: “If the application recommendation module 324 determines that certain mobile applications 204 are installed on other vehicles 31 having the same or similar identified driver characteristics 312, but not on the vehicle 31, then the application recommendation module 324 may generate an application recommendation 326 recommending those mobile applications 204 to the driver.”; para. [0048]: “the driver may receive the application recommendations 326, and may choose to install the recommended mobile applications 204. Accordingly, using the application recommendations 326 determined by the recommendation application 210, the driver may be able to download and utilize mobile applications 204 that may help the driver to improve his or her driving experience”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maeda to incorporate the teachings of Rao to provide downloading of software of the recommended function from the server. Doing so enables recommending the driver to download the application that would be beneficial for the particular driver in enhancing his or her driving experience, as recognized by Rao (para. [0013]).
Volos in view of Maeda and Rao does not explicitly disclose the function management server acquires comment information of a driver of the vehicle in an online communication service using a website.
However, in the same field of endeavor, Suzuki discloses: a function management server (fig. 1: center 10) acquires comment information of a driver of the vehicle (fig. 1: vehicle 30) in an online communication service using a website (e.g., para. [0043]: “the center 10 is further connected to a SNS server 40 via a network, such as the Internet. The SNS server 40 is one or more computers that provide social networking services. In the SNS server 40, various types of posted information by each user of the SNS, comments that other users leave on each posted information, and the like are uploaded and stored. Hereinafter, the posted information, the comments, and the like stored in the SNS server 40 are collectively referred to as “SNS information.” The SNS information is used to analyze the preferences and the like of the vehicle user.”; also see para. [0050] & [0055]), and provides a recommend function (see e.g., para. [0041] & [0092]: “the recommended information to be provided to the vehicle user is generated based on the preference information of the vehicle user based on the SNS information (i.e. posted information in social media), and the vehicle information transmitted from the in-vehicle device 20 of the vehicle in which the vehicle user is riding.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maedato and Rao to incorporate the teachings of Suzuki to provide a recommend function based on comment information of a driver in an online communication service using a website. Doing so allows the system to provide recommended information to the vehicle user based on the preference information of the vehicle user based on posted information in social media, as recognized by Suzuki (para. [0092]).
Independent claim 15 (directed to a function management server) recites corresponding features of system claim 5. Therefore, claim 15 is rejected for the same reasons set forth in claim 5 above for having similar limitations and being similar in scope.
Independent claim 19 (directed to a non-transitory CRM claim) recites corresponding features of system claim 5. Therefore, claim 19 is rejected for the same reasons set forth in claim 5 above for having similar limitations and being similar in scope.
Claims 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Volos in view of Maedato and Rao, and further in view of Neubauer and Suzuki.
As per claim 16, Volos discloses an in-vehicle system (see e.g., fig. 2; para. [0039]-[0050]: control modules in vehicles 20, 22 that performs data communication with a function management server (figs. 1 & 3: a driver risk assessment (DRA) server 12) which specifies a recommend function based on at least one of a driving technique of a driver of a vehicle analyzed based on a driving data of the driver of the vehicle (see e.g., fig. 3; para. [0052] & [0074]-[0075]), and distributes recommend function information related to a specified recommend function to the in-vehicle system (see e.g., para. [0037]: the risk assessment server sends feedback (e.g., risk scores, driver behavior information) to vehicles and other systems), the in-vehicle system comprising:
a recommend function presentation unit that presents the recommend function specified by received recommend function information to the driver upon receiving the recommend function information distributed from the function management server (see e.g., para. [0037]: “The vehicles 20, 22 may perform various tasks based on the feedback including reporting the assessment scores to the drivers, altering autonomous vehicle operation, training the drivers how to operate the vehicles 20, 22 in certain locations, etc.”; and para. [0081]: the vehicle control modules may adjust vehicle components (engine, brakes, steering, etc.), generate audio/video outputs, and attempt to influence driver behavior based on average driver patterns or anomalies).
Volos does not explicitly disclose wherein: the recommended function (feedback) is executable by the in-vehicle system mounted on the vehicle.
However, in the same field of endeavor, Maeda discloses: wherein: the recommended function is executable by the in-vehicle system mounted on the vehicle (see e.g., para. [0085]-[0103]: “In step S201, the CPU 20A determines whether or not the received command is for the activation of the recommended function. In a case in which the CPU 20A determines that the received command is for the activation of the recommended function (i.e., if the result of the determination in step S201 is YES), then the routine proceeds to step S202”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “In step S202, the CPU 20A executes activation processing for the recommended function. In other words, the CPU 20A causes the vehicle on-board device 23 that pertains to the recommended function to be activated through the ECU 22 that pertains to the recommended function”; “For example, in a case in which, based on the vehicle speed information, the vehicle 12 is caught in a traffic jam, and based on the image information, an intention of driver fatigue is acquired for the vehicle occupant P, in the central server 30, an automatic brake hold function is selected as the recommended function. In a case in which the vehicle 12 is traveling, then the suggestion of activating the automatic brake hold function is selected and a command pertaining to this suggestion is transmitted to the vehicle on-board unit 20. In a case in which the vehicle 12 is stopped, then the activation of the automatic brake hold function is selected, and a command pertaining to activation is transmitted to the vehicle on-board unit 20”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos to incorporate the teachings of Maeda to provide an executable recommended function to the in-vehicle system. Doing so allows to achieve a lightening of the burden on the vehicle occupant for performing the operation, as recognized by Maeda (para. [0103]).
Maeda discloses that each program stored in the vehicle on-board unit is downloaded from an external device (para. [0124]), however, Volos in view of Maeda does not explicitly disclose that software of the recommended function is downloadable from the function management server.
However, in the same field of endeavor, Rao discloses: software of the recommended function is downloadable from the function management server (see e.g., para. [0013], [0031]-[0034]: “A recommendation application 210 installed on the VCS 1 may be configured to provide recommendations to the user regarding mobile applications 204 to be downloaded to the nomadic device 53 (or to the VCS 1 via the nomadic device 53) for use by the driver”; “the mobile application 204 may be included on the nomadic device 53 as part of a default installation. In other cases, the mobile application 204 may be downloaded and installed by a user of the nomadic device 53, such as from an online application store 208”, and para, [0054]: where the application store 208 may be a server; also see para. [0045]: “If the application recommendation module 324 determines that certain mobile applications 204 are installed on other vehicles 31 having the same or similar identified driver characteristics 312, but not on the vehicle 31, then the application recommendation module 324 may generate an application recommendation 326 recommending those mobile applications 204 to the driver.”; para. [0048]: “the driver may receive the application recommendations 326, and may choose to install the recommended mobile applications 204. Accordingly, using the application recommendations 326 determined by the recommendation application 210, the driver may be able to download and utilize mobile applications 204 that may help the driver to improve his or her driving experience”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maeda to incorporate the teachings of Rao to provide downloading of software of the recommended function from the server. Doing so enables recommending the driver to download the application that would be beneficial for the particular driver in enhancing his or her driving experience, as recognized by Rao (para. [0013]).
Volos in view of Maeda and Rao does not explicitly disclose the function management server specifies a recommend function based on inquiry information of the driver in an automatic conversation service.
However, in the same field of endeavor, Neubauer discloses: a function management server (fig. 1: routing platform 111) which specifies a recommend function based on inquiry information of the driver in an automatic conversation service (see e.g., para. [0028], [0038]-[0041] & [0060]-[0067]: the navigation system provides a conversational voice-based user interface; the user issues a voice command; the mapping platform 111 can generate a series of justification messages based on different argumentative reason classes to present to a user).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maeda and Rao to incorporate the teachings of Neubauer to provide a recommend function based on inquiry information of a driver of the vehicle in an automatic conversation service. Doing so allows the system to specify recommended function(s) by taking the user inquiry or interaction into account, as recognized by Neubauer (para. [0025]).
Volos in view of Maeda, Rao, and Neubauer does not explicitly disclose the function management server specifies a recommend function based on comment information of the driver in an online communication service using a website.
However, in the same field of endeavor, Suzuki discloses: a function management server (see e.g., fig. 1; para. [0043]: “the center 10 is further connected to a SNS server 40 via a network, such as the Internet. The SNS server 40 is one or more computers that provide social networking services. In the SNS server 40, various types of posted information by each user of the SNS, comments that other users leave on each posted information, and the like are uploaded and stored. Hereinafter, the posted information, the comments, and the like stored in the SNS server 40 are collectively referred to as “SNS information.” The SNS information is used to analyze the preferences and the like of the vehicle user”) which specifies a recommend function based on comment information of the driver in an online communication service using a website (e.g., para. [0092]: “the recommended information to be provided to the vehicle user is generated based on the preference information of the vehicle user based on the SNS information (i.e. posted information in social media), and the vehicle information transmitted from the in-vehicle device 20 of the vehicle in which the vehicle user is riding.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Volos in view of Maeda, Rao, and Neubauer to incorporate the teachings of Suzuki to provide specifying a recommend function based on comment information of the driver in an online communication service using a website. Doing so allows the system to provide recommended information to the vehicle user based on the preference information of the vehicle user based on posted information in social media, as recognized by Suzuki (para. [0092]).
Independent claim 20 (directed to a non-transitory CRM claim) recites corresponding features of system claim 16. Therefore, claim 20 is rejected for the same reasons set forth in claim 16 above for having similar limitations and being similar in scope.
Response to Arguments
Applicant's arguments filed January 21, 2026 have been fully considered but are moot in view of the new ground(s) of rejection, as necessitated by amendment. Volos in view of Maeda and Rao is demonstrated to meet the amended claims.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADNAN AZIZ whose telephone number is (571) 270-7536, (Fax: 571-270-8536). The examiner can normally be reached Monday - Friday (9am - 6pm Eastern Time).
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.
/ADNAN AZIZ/Primary Examiner, Art Unit 2685 adnan.aziz@uspto.gov