Status of Claims
This action is in reply to the communications filed on 07/29/2026.
Claims 1, 7, and 14 have been amended.
Claims 1, 5, 7, 11, 14, and 18 are currently pending and have been examined.
Response to Applicant’s Remarks
Applicant’s arguments and remarks filed on 07/29/2026 have been fully considered and each argument will be respectfully addressed in the following final office action.
Response to 35 U.S.C. § 101 Remarks
Applicant’s remarks filed on pages 9-17 of the Response concerning the 35 U.S.C. § 101 rejection of the claims have been fully considered but are found not persuasive and are moot in view of the amended rejection that may be found starting on page 8 of this final office action.
On pages 10-17 of the Response, the Applicant argues that the amended independent claims recite additional elements that provide significantly more than the abstract idea. Furthermore, on page 14 of the Response, the Applicant argues “First, the feature of “the on-board computer communicating with the data collecting device, screening objective driving data associated with a preset potential dangerous event from the initial driving data and transmitting the objective driving data to the server to reduce an amount of data uploaded from the vehicle to the server” is not mere data gathering. It is an objective driving data filtering mechanism that addresses the technical problem of communication bandwidth limitations and server processing burdens in a vehicle-to-cloud environment”. The Examiner respectfully disagrees that the amended claim features integrate the abstract idea into a practical application or provide significantly more than the abstract idea. As currently drafted, these claim features merely describe the utilization of generic computing tools (i.e., a server, data collecting device, and on-board computer) in their ordinary capacity to collect and transmit information. Examiner notes “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more […]” (MPEP 2106.05 (f)).
On page 14 of the Response, the Applicant argues “The features of “inputting the images of the roads into a preset image semantic recognition model to obtain a dynamic scene attribute of the vehicle […] is not a mental step. It is a computer vision and deep learning operation that extracts complex dynamic environmental information […] from image data”. Examiner respectfully disagrees that these claim features do not recite concepts of mental processes. As noted by the Applicant, these claim elements involve the analysis of image data to extract particular dynamic environmental information. A human using mental steps is capable of observing and analyzing collected information (i.e., an image) to extract further information. The recited use of the claimed “preset image semantic recognition model” is recited at a high level of generality such that it merely serves as a generic computer tool to perform the abstract idea (i.e., the mental process of observing and analyzing image data). Merely inputting images into a “preset image semantic recognition model to obtain a dynamic scene attribute of the vehicle”, as currently recited, does not reflect any type of improvement to computer visioning systems or deep learning operations because the claims merely describe obtaining an output from the model, based on an input, without any further technical details regarding how the “present image semantic recognition model” generates the output. Thus, these claim features merely describe the utilization of generic computer tools at a high level of generality to perform a mental process.
On page 14 of the Response, the Applicant argues “The feature of “obtaining a high-precision map […] is not a generic map function. It is a specific use of high-precision map data to determine static road attributes such as road type, intersection indication, speed limit, and lane driving direction”. These claim limitations merely describe concepts of collecting information (i.e., obtaining a high-precision map) and analyzing the collected information (i.e., determining a static scene attribute) – which is the abstract idea of mental processes. Examiner notes “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more […]” (MPEP 2106.05 (f)).
On page 14 of the Response, the Applicant argues “The feature of “detecting whether the dangerous driving behavior exists […] is a multi-source information fusion technique that improves the accuracy of dangerous driving behavior detection”. These claim limitations merely describe concepts of collecting information, analyzing information, and exercising judgement to determine whether a dangerous driving behavior exists – which is the abstract idea of mental processes.
On page 15 of the Response, the Applicant argues “Second, the claimed method does not merely describe an abstract concept and then state “apply it on a computer” […] The detection result is used to determine a management strategy for the vehicle […] includes a recommendation priority for each vehicle in the fleet, determined based on a safety score derived from the types of dangerous driving behaviors […] The priority is then used to select an objective vehicle from candidate vehicles to respond to a dispatching request […] This is a technical solution to the problem of efficiently and safely managing a fleet of vehicles in a network-connected environment”.
The Examiner respectfully disagrees that these claim features provide an improvement to a technical environment and implement that abstract idea into a practical application. These claim features are directed towards analyzing driving behaviors of a human driver (as evidenced in ¶ [0019] of the specification) and rewarding/punishing drivers based on an analysis of their driving behaviors in a commercial service environment (see ¶ [0063] of specification). In particular, a recommendation priority of a driver is determined based on their derived safety score, such that a higher recommendation priority indicates a greater probability that the driver/vehicle is selected to respond to a dispatching request. These claim limitations, as a whole, recite concepts of managing personal behavior and managing business relations. See MPEP 2106.04(a)(2)(II). The Examiner notes that “it is important to keep in mind that an improvement in the abstract idea itself […] is not an improvement in technology” (See MPEP 2106.05(a)(II)).
On page 15 of the Response, the Applicant argues “the step of screening data at the on-board computer to reduce upload amount is a network optimization technique. It reduces the amount of data uploaded from the vehicle to the server, thereby conserving bandwidth and reducing server-side storage and processing demands. These are technical benefits to the communication system itself, not merely commercial improvements”.
Examiner respectfully disagrees that these claim features, as currently drafted, reflect an improvement to technology. First, the claims merely recite generic computer instructions for organizing information (i.e., “screening objective driving data”) and transmitting information between generic computing devices. As noted further above “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more […]” (MPEP 2106.05 (f)).
Second, although the Applicant argues that these claim features conserve bandwidth and reduce server-side storage/processing demands, these claim features merely shift the computational burden away from the server to a different generic computer device. Instead of the server performing the steps of screening the objective driving data, these functions are delegated to the on-board computer. Overall, the processing demands and computational loads incurred by the system are not reduced. Instead, the processing demands of the overall system are simply divided between a plurality of system computer components. As such, these claim features are not considered to reflect a improvement to the functioning of a computer or technical environment.
On page 16 of the Response, the Applicant argues “the additional elements in amended claim 1 go far beyond conventional computer operations […] The above elements are not merely employed to “apply the abstract idea”. Rather they form a complete technical solution for real-time detection of dangerous driving behavior and dynamic adjustment of fleet dispatch strategies […] amended claim 1 includes significantly more than the alleged abstract idea and improves the technology of vehicle allocation […]”.
The Examiner respectfully disagrees that the amended independent claims recite additional elements that provide significantly more than the abstract idea. As discussed further above in greater detail, the additional elements that include a “present image semantic recognition model”, “on-board computer”, “data collecting device”, “server”, and steps for transmitting information between computing devices merely serve as generic computer tools and instructions to apply the abstract idea. Because merely “applying” the exception using generic computer components/instructions cannot provide an inventive concept, the additional elements, when viewed as a whole/ordered combination, do not recite significantly more than the judicial exception. See MPEP 2106.05(I)(A).
Furthermore, as discussed further above, the claim features which are considered to be part of the abstract idea itself include obtaining dynamic scene attributes of the vehicle, obtaining a high precision map, determining static scene attributes, and detecting whether dangerous driving behaviors exist based on a combination of dynamic scene attributes, static scene attributes, and operation information of the vehicle. Thus, these claim features cannot be considered to be additional elements that provide significantly more than the abstract idea because they are considered to be part of the abstract idea itself.
Response to 35 U.S.C. § 103 Remarks
Applicant’s remarks filed on pages 17-24 of the Response concerning the 35 U.S.C. § 103 rejection of the claims have been fully considered but are moot in view of the amended §103 rejection that may be found starting on page 19 of this final office action.
On pages 17-24 of the Response, the Applicant argues that the prior art of record- namely Kim, Shoshan, and Marueli – do not teach or suggest the amended features of the independent claims. On page 23 of the Response, the Applicant argues “a combination of Kim, Shoshan, and Marueli fails to teach or suggest all features, comprising the above-mentioned features as recited in amended claim 1”. In view of the amendments to the independent claims, and upon further search and consideration, the Examiner has set forth an amended §103 rejection of the claims that may be found starting on page 19 herein.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 5, 7, 11, 14, 18 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
First of all, claims must be directed to one or more of the following statutory categories: a process, a machine, a manufacture, or a composition of matter. Claims 1 and 5 are directed to a process (“a method”), claims 7 and 11 are directed to a machine (“a system”), and claims 14 and 18 are directed to a machine (“a server”). Thus, claims 1-5, 7-11, and 13-18 satisfy Step One because they are all within one of the four statutory categories of eligible subject matter. Claims 1, 5, 7, 11, 14, and 18, however, are directed to an abstract idea without significantly more.
Regarding independent claim 1, the specific limitations that recite an abstract idea are:
[…] screening objective driving data associated with a preset potential dangerous event from the initial driving data of the vehicle […];
Receiving the objective driving data […];
Detecting whether a dangerous driving behavior exists corresponding to the vehicle in accordance with the objective driving data to generate a detection result; and
Determining a management strategy of the vehicle in accordance with the detection result.
Wherein management strategies of the fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet is determined in accordance with a safety score determined by types of dangerous driving behaviors of each vehicle of the fleet;
The method further comprises: determining a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; and
Selecting an objective vehicle from the first number of candidate vehicles to respond the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles; wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the objective vehicle;
Wherein the objective driving data comprises operation information of the vehicle, images of roads during the vehicle driving, and position information of the vehicle;
detecting whether the dangerous driving behavior exists corresponding to the vehicle in accordance with the objective driving data to generate the detection result further comprises:
[…] obtain a dynamic scene attribute of the vehicle, wherein the dynamic scene attribute comprises at least on of traffic light signals, positions of obstacles surrounding the vehicle, and distances between the vehicle and surrounding obstacles;
Obtaining a high-precision map comprises the position information of the vehicle, and determining a static scene attribute of the vehicle in accordance with the position information of the vehicle and the high-precision map, wherein the high-precision map comprises road elements and traffic-related dynamic elements, and the static scene attribute comprises at least one of a road type, an intersection indication, a speed limit, and a lane driving direction; and
Detecting whether the dangerous driving behavior exists corresponding to the vehicle in combination with the dynamic scene attribute, the static scene attribute, and the operation information of the vehicle, to generate the detection result.
Therefore, claims 1 and 5, by virtue of dependence, recite certain methods of organizing human activity. In particular, the limitations of claim 1 identified above, as a whole, are directed towards determining/detecting dangerous driving behavior of a human driver based on collected objective driving data and determining a management strategy of the vehicle in accordance with the detection, wherein the management strategies involve determining a recommendation priority of each vehicle in a fleet in accordance with a safety score and selecting a vehicle to respond to a dispatch request in accordance with the recommendation priority. This is further evidenced by the Applicant specification at ¶ [0033], ¶ [0045], and ¶ [0066]. Thus, claim 1, as a whole, recites concepts of managing personal behavior and commercial interactions. See MPEP 2106.04(a)(2)(II). Furthermore, the limitations of claim 1 identified above recite concepts of mental processes. In particular, the limitations identified above recite the performance of observation, judgement, collecting information, comparing information, organizing information, and analyzing information in a manner that is analogous to human mental work. See MPEP 2106.04(a)(2)(III).
The judicial exception recited above is not integrated into a practical application. The additional elements of the claim include a “server”, “on-board computer configured in a vehicle of a fleet”, “the vehicle further comprising a data collecting device for collecting initial driving data”, “the on-board computer communicating with the data collecting device”, steps for “transmitting the objective driving data to the server to reduce an amount of data uploaded from the vehicle to the server”, and steps for “inputting the images of the roads into a preset image semantic recognition model to” perform the abstract idea. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer tools and instructions by which the abstract idea is implemented. See MPEP 2106.05(f).
Furthermore, the claim recites additional elements involving steps for transmitting information over a network (“the server communicating with an on-board computer”, “transmitting the objective driving data to the server”). These additional elements fail to integrate the claim into a practical application because the steps for transmitting information over a network amount to no more than mere data gathering/outputting, which is insignificant extra-solution activity. See MPEP 2106.05(g).
Finally, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, the additional elements, in combination, are recited at a high level of generality such that they amount to no more than mere instructions to apply the abstract idea using generic computer components. Because merely “applying” the exception using generic computer components/instructions cannot provide an inventive concept, the additional elements, when viewed as a whole/ordered combination, do not recite significantly more than the judicial exception. See MPEP 2106.05(I)(A). Furthermore, the additional elements involving steps for transmitting information over a network fail to amount to significantly more than the judicial exception because the courts have found transmitting information over a network to be well-understood, routine, and conventional activities. See MPEP 2106.05(d)(II). Because the invention is merely reciting well-understood, routine, and conventional activity, the additional elements of this claim which involve transmitting information over a network, when viewed as a whole/ordered combination, do not recite significantly more than the judicial exception. Thus, claim 1 is not patent eligible.
Regarding independent claim 7, the specific limitations that recite an abstract idea are:
[…] screening objective driving data associated with a preset potential dangerous event from the initial driving data of a corresponding vehicle […];
Receive the objective driving data […];
Detect whether a dangerous driving behavior exists corresponding to a first vehicle of the fleet […] in accordance with the objective driving data to generate a detection result; and
Determine a management strategy of the vehicle in accordance with the detection result;
Wherein management strategies of the fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet is determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet;
[…] determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; and
Select a second vehicle from the first number of candidate vehicles to respond the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles; wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle.
Wherein the objective driving data comprises operation information of the vehicle, images of roads during the vehicle driving, and position information of the vehicle;
[…] obtain a dynamic scene attribute of the first vehicle, wherein the dynamic scene attribute comprises at least one traffic light signals, positions of obstacles surrounding the vehicle, and distances between the vehicle and surrounding obstacles;
Obtain a high-precision map comprises the position information of the vehicle, and determining a static scene attribute of the vehicle in accordance with the position information of the vehicle and the high-precision map, wherein the high-precision map comprises road elements and traffic-related dynamic elements, and the static scene attribute comprises at least one of a road type, an intersection indication, a speed limit, and a lane driving direction; and
Detect whether the dangerous driving behavior exists corresponding to the vehicle in combination with the dynamic scene attribute, the static scene attribute, and the operation information of the vehicle, to generate the detection result.
Therefore, claims 7 and 11, by virtue of dependence, recite certain methods of organizing human activity. In particular, the limitations of claim 7 identified above, as a whole, are directed towards determining/detecting dangerous driving behavior of a human driver based on collected objective driving data and determining a management strategy of the vehicle in accordance with the detection, wherein the management strategies involve determining a recommendation priority of each vehicle in a fleet in accordance with a safety score and selecting a vehicle to respond to a dispatch request in accordance with the recommendation priority. This is further evidenced by the Applicant specification at ¶ [0033], ¶ [0045], and ¶ [0066]. Thus, claim 1, as a whole, recites concepts of managing personal behavior and commercial interactions. See MPEP 2106.04(a)(2)(II). Furthermore, the limitations of claim 1 identified above recite concepts of mental processes. In particular, the limitations identified above recite the performance of observation, judgement, collecting information, comparing information, organizing information, and analyzing information in a manner that is analogous to human mental work. See MPEP 2106.04(a)(2)(III).
The judicial exception recited above is not integrated into a practical application. The additional elements of the claim include “one or more on-board computers and a server, the one or more on-board computers communicating with the server, each of the one or more computers being configured in a vehicle of a fleet”, “the vehicle further comprising a data collecting device for collecting initial driving data”, “each one of the one or more on-board computers communicating with a corresponding data collecting device”, “transmitting the objective driving data to the server to reduce an amount of data uploaded from the corresponding vehicle to the server”, “an objective on-board computer”, and steps involving “when the server detects whether the dangerous driving behavior exists corresponding to the first vehicle of the fleet configured with the objective on-board computer is accordance with the objective driving data to generate the detection result, the server is further configured to: input the images of the roads into a preset image semantic recognition model to” perform the abstract idea. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer tools and instructions by which the abstract idea is implemented. See MPEP 2106.05(f).
Furthermore, the claim recites additional elements involving steps for transmitting information over a network (“the one or more on-board computers communicating with the server”, “transmitting the objective driving data to the server”). These additional elements fail to integrate the claim into a practical application because the steps for transmitting information over a network amount to no more than mere data gathering/outputting, which is insignificant extra-solution activity. See MPEP 2106.05(g).
Finally, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, the additional elements, in combination, are recited at a high level of generality such that they amount to no more than mere instructions to apply the abstract idea using generic computer components. Because merely “applying” the exception using generic computer components/instructions cannot provide an inventive concept, the additional elements, when viewed as a whole/ordered combination, do not recite significantly more than the judicial exception. See MPEP 2106.05(I)(A). Furthermore, the additional elements involving steps for transmitting information over a network fail to amount to significantly more than the judicial exception because the courts have found transmitting information over a network to be well-understood, routine, and conventional activities. See MPEP 2106.05(d)(II). Because the invention is merely reciting well-understood, routine, and conventional activity, the additional elements of this claim which involve transmitting information over a network, when viewed as a whole/ordered combination, do not recite significantly more than the judicial exception. Thus, claim 7 is not patent eligible.
Regarding independent claim 14, the specific limitations that recite an abstract idea are:
[…] screening objective driving data associated with a preset potential dangerous event from the initial driving data of a corresponding vehicle […];
Receive the objective driving data […];
Detect whether a dangerous driving behavior exists corresponding to a first vehicle of the fleet […] in accordance with the objective driving data to generate a detection result; and
Determine a management strategy of the vehicle in accordance with the detection result;
Wherein management strategies of the fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet is determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet;
[…] determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; and
Select a second vehicle from the first number of candidate vehicles to respond the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles; wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle.
Wherein the objective driving data comprises operation information of the vehicle, images of roads during the vehicle driving, and position information of the vehicle;
[…] obtain a dynamic scene attribute of the first vehicle, wherein the dynamic scene attribute comprises at least one of traffic light signals, positions of obstacles surrounding the vehicle, and distances between the vehicle and surrounding obstacles;
Obtain a high-precision map comprising the position information of the vehicle, and determine a static scene attribute of the vehicle in accordance with the position information of the vehicle and the high-precision map, wherein the high-precision map comprises road elements and traffic-related dynamic elements and the static scene attribute comprises at least one of a road type, an intersection indication, a speed limit, and a lane driving direction; and
Detect whether the dangerous driving behavior exists corresponding to the vehicle in combination with the dynamic scene attribute, the static scene attribute, and the operation information of the vehicle, to generate the detection result.
Therefore, claims 14 and 18, by virtue of dependence, recite certain methods of organizing human activity. In particular, the limitations of claim 14 identified above, as a whole, are directed towards determining/detecting dangerous driving behavior of a human driver based on collected objective driving data and determining a management strategy of the vehicle in accordance with the detection, wherein the management strategies involve determining a recommendation priority of each vehicle in a fleet in accordance with a safety score and selecting a vehicle to respond to a dispatch request in accordance with the recommendation priority. This is further evidenced by the Applicant specification at ¶ [0033], ¶ [0045], and ¶ [0066]. Thus, claim 1, as a whole, recites concepts of managing personal behavior and commercial interactions. See MPEP 2106.04(a)(2)(II). Furthermore, the limitations of claim 1 identified above recite concepts of mental processes. In particular, the limitations identified above recite the performance of observation, judgement, collecting information, comparing information, organizing information, and analyzing information in a manner that is analogous to human mental work. See MPEP 2106.04(a)(2)(III).
The judicial exception recited above is not integrated into a practical application. The additional elements of the claim include “a server configured for communicating with one or more on-board computers”, “one or more on-board computers being configured in a vehicle of a fleet”, “the vehicle further comprising a data collecting device for collecting initial driving data”, “each of the one or more on-board computers communicating with a corresponding data collecting device”, “at least one processor”, “a data storage storing one or more programs which when executed by the at least one processor, cause the processor to…”, “objective on-board computer”, “transmitting the objective driving data to the server to reduce an amount of data uploaded from the corresponding vehicle to the server”, and steps involving “when the at least one processor detects whether the dangerous driving behavior exists corresponding to the first vehicle of the fleet configured with the objective on-board computer in accordance with the objective driving data to generate the detection result, the at least one processor is further configured to: input the images of the roads into a preset image semantic recognition model to obtain a dynamic scene attribute of the first vehicle” . The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer tools and instructions by which the abstract idea is implemented. See MPEP 2106.05(f).
Furthermore, the claim recites additional elements involving steps for transmitting information over a network (“transmitting the objective driving data to the server”). These additional elements fail to integrate the claim into a practical application because the steps for transmitting information over a network amount to no more than mere data gathering/outputting, which is insignificant extra-solution activity. See MPEP 2106.05(g).
Finally, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, the additional elements, in combination, are recited at a high level of generality such that they amount to no more than mere instructions to apply the abstract idea using generic computer components. Because merely “applying” the exception using generic computer components/instructions cannot provide an inventive concept, the additional elements, when viewed as a whole/ordered combination, do not recite significantly more than the judicial exception. See MPEP 2106.05(I)(A). Furthermore, the additional elements involving steps for transmitting information over a network fail to amount to significantly more than the judicial exception because the courts have found transmitting information over a network to be well-understood, routine, and conventional activities. See MPEP 2106.05(d)(II). Because the invention is merely reciting well-understood, routine, and conventional activity, the additional elements of this claim which involve transmitting information over a network, when viewed as a whole/ordered combination, do not recite significantly more than the judicial exception. Thus, claim 14 is not patent eligible.
Claim 5 further describes that determining the management strategy of the vehicle further comprises determining dangerous driving behaviors of the vehicle within a preset time in accordance with the detection result within the preset time, giving a safety score for the vehicle in accordance with the dangerous driving behaviors and types of dangerous driving behaviors, and determining the management strategy in accordance with the safety score. Thus, claim 5 further describes the abstract idea. The claim does not recite any further additional elements beyond the additional elements previously addressed with regard to claim 1 from which the claim depends.
Claim 11 further describes that determining the management strategy of the vehicle further comprises determining dangerous driving behaviors of the vehicle within a preset time in accordance with the detection result within the preset time, giving a safety score for the vehicle in accordance with the dangerous driving behaviors and types of dangerous driving behaviors, and determining the management strategy in accordance with the safety score. Thus, claim 11 further describes the abstract idea. The claim does not recite any further additional elements beyond the additional elements previously addressed with regard to claim 7 from which the claim depends.
Claim 18 further describes that determining the management strategy of the vehicle further comprises determining dangerous driving behaviors of the vehicle within a preset time in accordance with the detection result within the preset time, giving a safety score for the vehicle in accordance with the dangerous driving behaviors and types of dangerous driving behaviors, and determining the management strategy in accordance with the safety score. Thus, claim 18 further describes the abstract idea. The claim does not recite any further additional elements beyond the additional elements previously addressed with regard to claim 14 from which the claim depends.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 5, 7, 11, 14, and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over Kim et al. U.S. Publication No. 2018/0134215, hereafter known as Kim, in view of Shoshan U.S. Patent No. 9,576,480, hereafter known as Shoshan, in further view of Marueli et al. U.S. Publication No. 2020/0404074, hereafter known as Marueli.
Claim 1: Kim teaches the following:
A […] method applied to a server, the server communicating with an on-board computer configured in a vehicle […] method comprising: (¶ [0035]: the device may be a micro server); (¶ [0036]: the device may communicate with a server in order to utilize information generated during running of various vehicles); (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like).
Receiving the objective driving data from the on-board computer; (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like).
Detecting whether a dangerous driving behavior exists corresponding to the vehicle in accordance with the objective driving data to generate a detection result; and (¶ [0049]: see above); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver).
Determining a management strategy of the vehicle in accordance with the detection result. (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver); (¶ [0047]: the notification signal may be generated when the risk level is great than or equal to a threshold); (¶ [0071]: the device may generate the notification signal with sound and/or vibration and output the notification signal. For example, the device may provide a driver with a guidance sound to induce safe driving. The guidance sound may be a voice to encourage stretching, a voice to explain a method of resolving drowsiness, and a voice to guide the driver to a resting place or a parking spot).
Wherein the objective driving data comprises operation information of the vehicle, images of roads during the vehicle driving, and position information of the vehicle; (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0049]: the information obtained from the vehicle may include image information generated from a camera included in the vehicle); (¶ [0029]: the device may use information generated during running of a vehicle to determine a status of a driver. The device may determine whether the vehicle is running on a predetermined road. If the vehicle is running on the road, the device may determine a risk level of the driver); (¶ [0053]: the device may determine whether the vehicle is running on the highway, based on information about a current state of the vehicle which is sensed while the vehicle is running); (¶ [0054]: the information about a current state of the vehicle which is sensed may include latitude and longitude information of a GPS sensor); (¶ [0057]: an input value of a data recognition model for determining whether the vehicle is running on the highway may be an input image generated by imaging signals of latitude and longitude information).
detecting whether the dangerous driving behavior exists corresponding to the vehicle in accordance with the objective driving data to generate the detection result further comprises: Inputting the images of the roads into a preset image semantic recognition model to obtain a dynamic scene attribute of the vehicle, wherein the dynamic scene attribute comprises at least one of […] positions of obstacles surrounding the vehicle […]; (¶ [0049]: see above); (¶ [0029]: see above); (¶ [0030]: information generated during running of the vehicle may include peripheral environment information); (¶ [0034]: peripheral environment information of the device may refer, for example, and without limitation, to environment information within a predetermined radius from the device); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0049]: the information obtained from the vehicle may include image information generated from a camera included in the vehicle); (¶ [0120] -¶ [0124]: A data acquisition unit may obtain sensing data. A preprocessing unit may pre-process the obtained data to use for learning to determine whether the vehicle is running on the highway and learn the risk level. A learning data selection unit may select data required for learning from the preprocessed data and provide the selected data to a model learning unit); (¶ [0125]: the model learning unit may learn a data recognition model used for determining whether the vehicle is running on the highway and a risk level of the driver using the learning data); (¶ [0126]: the data recognition model may be a model based on a neural network such as a deep neural network and recurrent neural network).
As disclosed by the Applicant in the Specification at ¶ [0025], “The dynamic scene attribute may include: red/green light signal of the road during the vehicle 30 driving, positions of pedestrians around the vehicle 30, distances between the vehicle 30 and another vehicle in front, etc.”. As noted above, Kim teaches a system configured to generate peripheral environmental information corresponding to environment information within a predetermined radius– equivalent to obtaining a dynamic scene attribute comprising at least positions of obstacles surrounding the vehicle.
Obtaining a high-precision map comprising the position information of the vehicle, and determining a static scene attribute of the vehicle in accordance with the position information of the vehicle and the high-precision map, […] and the static scene attribute comprises at least one of a road type […] a speed limit […]; (¶ [0053]: see above); (¶ [0054]: the information about a current state of the vehicle which is sensed may include latitude and longitude information of a GPS sensor); (¶ [0057]: an input value of a data recognition model for determining whether the vehicle is running on the highway may be an input image generated by imaging signals of latitude and longitude information); (¶ [0059]: the device may determine whether the vehicle is running on the highway through a mapping function); (¶ [0069]: if the device determines that the driver is driving over a speed limit, the device may display an image that includes a speed gauge and warns the driver that the driver is driving over the speed limit).
As disclosed by the Applicant at ¶ [0022] of the Specification, “the static scene attribute may include whether the vehicle 30 is driving on a one-way road, whether the vehicle 30 is driving at an intersection, whether the road is configured with a speed limit, and a driving direction of a lane which the vehicle 30 need to follow”. Thus, the step for “determining a static scene attribute of the vehicle” is interpreted as a determining whether the vehicle is driving on a type of road. As noted above, Kim teaches a system configured to determine whether a vehicle is running on a highway (i.e, a road type) based on a mapping function and GPS sensor information. Furthermore, the system is configured to determine and warn a driver when they are driving over a speed limit.
Detecting whether the dangerous driving behavior exists corresponding to the vehicle in combination with the dynamic scene attribute, the static scene attribute, and the operation information of the vehicle, to generate the detection result. (¶ [0043]: the device may recognize the running pattern of the vehicle based on the information sensed by the device. The running pattern of the vehicle may include dangerous driving, which includes erratic driving, violent driving, speeding driving, lane violation, sudden stopping, sudden lane changing, etc.); (¶ [0044]: the device may determine a current status of the driver of the vehicle based on the running pattern of the vehicle); (¶ [0120] -¶ [0124]: A data acquisition unit may obtain sensing data. A preprocessing unit may pre-process the obtained data to use for learning to determine whether the vehicle is running on the highway and learn the risk level. A learning data selection unit may select data required for learning from the preprocessed data and provide the selected data to a model learning unit); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver); (¶ [0047]: the notification signal may be generated when the risk level is great than or equal to a threshold).
Although Kim teaches a system configured to monitor driving behavior corresponding to a vehicle via a device/micro-server, Kim does not explicitly teach that the vehicle belongs to a fleet and that the server manages a fleet of vehicles. Furthermore, Kim does not explicitly teach an on-board computer screening objective driving data associated with a preset potential dangerous event from initial driving data of the vehicle and transmitting the objective driving data to the server. Furthermore, Kim does not explicitly teach wherein the high-precision map comprises road elements and traffic-related dynamic elements.
However, Shoshan teaches the following:
A fleet managing method applied to a server, the server communicating with an on-board computer configured in a vehicle of a fleet, the vehicle further comprising a data collecting device for collecting initial driving data, the on-board computer communicating with the data collecting device, screening objective driving data associated with a preset potential dangerous event from the initial driving data and transmitting the objective driving data to the server to reduce an amount of data uploaded from the vehicle to the server, the fleet management method comprising: (col. 2, lines 5-6: Fig. 2 is a flowchart of an example method of managing a fleet of vehicles); (col. 1, lines 28-38: the system for managing vehicle sensor data comprises a central server configured to aggregate vehicle condition sensor data by vehicle identifier and vehicle position, and determine a safety condition for the aggregated vehicle condition sensor data); (col. 2, lines 62-67: the vehicles have the ability to connect and share information through a centrally-managed cloud computing system. The cloud aggregates vehicle information to determine safety conditions); (col. 7, lines 44-55: data can be categorized as routine or abnormal. The vehicle on-board system can analyze vehicle condition sensor data and determine that the data is routine and not send it to the cloud in order to reduce load. A vehicle can report only abnormal sensor data (e.g., slipping on a road, emergency stop, and the like). When a vehicle is in the perimeter of a determined safety condition, the cloud can request vehicles within the perimeter of the determined safety condition to also send routine sensor data); (col. 3, lines 25-41: the vehicles are equipped with sensors. Sensors provide specialized vehicle operation information and include standard on-board diagnostic (OBD) sensors, and cameras that capture road imagery. Vehicle condition sensor data can be sent from the vehicle to the cloud); (col. 4, lines 41-50: safety conditions can be vehicle related or location related. For example, dangerous driving behavior can be determined from sensors acquiring data from driver input controls, determining unsafe following distances, and excessive speed. Thus, vehicle related safety conditions pertain to a particular vehicle).
Thus, Shoshan discloses a vehicle equipped with sensors to capture sensor data; equivalent to the vehicle comprising a data collecting device for collecting initial driving data. Furthermore, the vehicles on-board system can analyze sensor data and determine whether data is routine or abnormal (i.e., indicating unsafe driving behaviors). Accordingly, the on-board system only sends abnormal sensor data to a cloud server in order to reduce load; equivalent to the on-board computer communicating with the data collecting device, screening objective driving data associated with a preset potential dangerous event from the initial driving data and transmitting the objective driving data to the server to reduce an amount of data uploaded from the vehicle to the server.
[…] wherein the high-precision map comprises road elements and traffic-related dynamic elements; (col. 8, lines 59-60: the aggregated safety conditions can be used to populate a live map); (col. 2, line 66 – col. 3, line 1: The cloud can aggregate the vehicle information to determine safety conditions that vehicles and drivers have encountered or will encounter); (col. 5, lines 1-3: Safety conditions can be classified as one or more of: road hazard, traffic condition, or emergency vehicle).
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 the system of Kim with the teachings of Shoshan by incorporating the centrally-managed cloud server configured to manage driving sensor data from a plurality of vehicles within a fleet, an on-board computer that screens objective driving data received from a plurality of vehicle sensors and associated with preset potential dangerous events from initial driving data of the vehicle collected by the sensors, transmit the objective driving data to the server, and determine driving behaviors for each particular vehicle, as taught by Shoshan, into the system of Kim comprising a device/micro-server that is configured to collect sensor data from a vehicle to determine driving behaviors. Furthermore, it would have been obvious to one of ordinary skill in the art to have modified the system of Kim with the teachings of Shoshan by incorporating the high-precision map comprising road elements and traffic-related dynamic elements, as taught by Shoshan, into the system of Kim that is configured to utilize a mapping function to gather relevant information associated with a vehicle. One of ordinary skill in the art would have been motivated to make these modifications “in order to build an accurate image of the ongoing safety condition” (col. 7, lines 55-57) and when one considers “[a]nother advantage of the described technologies is that vehicle management system can use the aggregated vehicle information to guide traffic and ensure efficient use of available resources, such as road capacity” (col. 15, lines 35-39), as suggested by Shoshan. Furthermore, one of ordinary skill in the art would have recognized that the teachings of Shoshan are compatible with the system of Kim as they share capabilities and characteristics. In particular, they are both systems comprising servers configured to monitor vehicle driving data via on-board sensors and detect dangerous driving behaviors.
Kim/Shoshan does not explicitly teach wherein the management strategies of a fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet. Furthermore, Kim/Shoshan does not explicitly teach a method further comprising determining a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request, and selecting an objective vehicle from the first number of candidate vehicles to respond the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles, wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the objective vehicle.
However, Marueli teaches the following:
Wherein the management strategies of the fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet is determined in accordance with a safety score determined by types of dangerous driving behaviors of each vehicle of the fleet; (¶ [0012]: a queue of drivers for a particular area is maintained, wherein the queue specifies an order in which drivers are selected for transportation requests for a particular area); (¶ [0067]: the server may determine driver placement within a queue based on characteristics of transportation requests and performance metrics/scores associated with the drivers); (¶ [0078]: performance metrics may include a safety record, e.g., a measure of traffic accidents experienced or traffic tickets received).
The method further comprises: determining a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; (¶ [0012]: see above); (¶ [0067]: the server may determine driver placement within a queue based on characteristics of transportation requests and performance metrics/scores associated with the drivers); (¶ [0019]: backend system may select a driver based on any suitable factors, including information contained in the transportation request, the proximity of the driver to the passenger, whether the pickup location is located within an area serviced by one or more queues, or any other suitable factors);
Selecting an objective vehicle from the first number of candidate vehicles to respond to the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles; wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the objective vehicle. (¶ [0019]: see above); (¶ [0078]: see above); (¶ [0067]: if a driver has a relatively high performance score indicating that the driver is performing well relative to other drivers, the driver may be placed at a spot in the queue that is higher than the bottom of the queue); (¶ [0012]: a queue of drivers for a particular area is maintained, wherein the queue specifies an order in which drivers are selected for transportation requests for a particular area).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the system of Kim/Shoshan the ability to determine a recommendation priority of each vehicle of a fleet, the recommendation priority of each vehicle of the fleet determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet; determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; and select an objective vehicle from the first number of candidate vehicles to respond to the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the objective vehicle, as taught by Marueli, since the claimed invention is merely a combination of old elements. In combination, each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination are predictable. Furthermore, one of ordinary skill in the art would have been motivated to make this modification when one considers a “driver could be given a preferred position in the queue […] if the driver has performed well relative to other drivers” (¶ [0014]), as suggested by Marueli, and thus incentivizing drivers to drive safely.
Claim 5: Kim/Shoshan/Marueli teaches the limitations of claim 1. Furthermore, Kim teaches the following:
Wherein determining the management strategy of the vehicle in accordance with the detection result further comprises: determining dangerous driving behaviors of the vehicle within a preset time in accordance with the detection result within the preset time; (¶ [0056]: the information that the current state of the vehicle is sensed while the vehicle is running may be a time series signal. Further, the information about the current state of the vehicle may be processed in a form suitable for learning. The device may perform an operation of dividing the time series signal into an appropriate length of time. The appropriate length of time may be a length including a specific running pattern. The appropriate length of time may be set to a predetermined length).
Giving a safety score for the vehicle in accordance with the dangerous driving behaviors of the vehicle within the preset time and types of the dangerous driving behaviors; (¶ [0054]: see above); (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver); (¶ [0062]: Fig. 5 illustrates an example of determining a risk level of a driver); (¶ [0064]: As illustrated in Fig. 5, for example, if the determines that the driver is currently in a completely alert normal state, the device may use a table to determine that the drowsiness degree of the driver is 1. If the device determines that the driver is currently in a very drowsy state, the device may determine that the drowsiness degree is 4. When the drowsiness degree is above a threshold, the device may output a notification signal).
Determining the management strategy of the vehicle in accordance with the safety score of the vehicle. (¶ [0064]: see above); (¶ [0071]: the device may generate the notification signal with sound and/or vibration and output the notification signal. For example, the device may provide a driver with a guidance sound to induce safe driving. The guidance sound may be a voice to encourage stretching, a voice to explain a method of resolving drowsiness, and a voice to guide the driver to a resting place or a parking spot).
Claim 7: Kim teaches the following:
A […] system, comprising one or more on-board computers and a server, the one or more on-board computers communicating with the server, each of the one or more on-board computers being configured in a vehicle […] wherein the server is configured to: (¶ [0035]: the device may be a micro server); (¶ [0036]: the device may communicate with a server in order to utilize information generated during running of various vehicles); (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like).
Receive the objective driving data from an objective on-board computer of the on-board computers; (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like).
Detect whether a dangerous driving behavior exists corresponding to a first vehicle of the fleet configured with the objective on-board computer in accordance with the objective driving data to generate a detection result; and (¶ [0049]: see above); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver).
Determine a management strategy of the vehicle in accordance with the detection result. (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver); (¶ [0047]: the notification signal may be generated when the risk level is great than or equal to a threshold); (¶ [0071]: the device may generate the notification signal with sound and/or vibration and output the notification signal. For example, the device may provide a driver with a guidance sound to induce safe driving. The guidance sound may be a voice to encourage stretching, a voice to explain a method of resolving drowsiness, and a voice to guide the driver to a resting place or a parking spot).
Wherein the objective driving data comprises operation information of the vehicle, images of roads during the vehicle driving, and position information of the vehicle; (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0049]: the information obtained from the vehicle may include image information generated from a camera included in the vehicle); (¶ [0029]: the device may use information generated during running of a vehicle to determine a status of a driver. The device may determine whether the vehicle is running on a predetermined road. If the vehicle is running on the road, the device may determine a risk level of the driver); (¶ [0053]: the device may determine whether the vehicle is running on the highway, based on information about a current state of the vehicle which is sensed while the vehicle is running); (¶ [0054]: the information about a current state of the vehicle which is sensed may include latitude and longitude information of a GPS sensor); (¶ [0057]: an input value of a data recognition model for determining whether the vehicle is running on the highway may be an input image generated by imaging signals of latitude and longitude information).
When the server detects whether the dangerous driving behavior exists corresponding to the first vehicle of the fleet configured with the objective on-board computer in accordance with the objective driving data to generate the detection result, the server is further configured to: input the images of the roads into a preset image semantic recognition model to obtain a dynamic scene attribute of the first vehicle, wherein the dynamic scene attribute comprises at least one of […] positions of obstacles surrounding the vehicle […]; (¶ [0043]: the device may recognize the running pattern of the vehicle based on the information sensed by the device. The running pattern of the vehicle may include dangerous driving, which includes erratic driving, violent driving, speeding driving, lane violation, sudden stopping, sudden lane changing, etc.); (¶ [0044]: the device may determine a current status of the driver of the vehicle based on the running pattern of the vehicle); (¶ [0030]: information generated during running of the vehicle may include peripheral environment information); (¶ [0034]: peripheral environment information of the device may refer, for example, and without limitation, to environment information within a predetermined radius from the device); (¶ [0049]: see above); (¶ [0029]: see above); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0049]: the information obtained from the vehicle may include image information generated from a camera included in the vehicle); (¶ [0120] -¶ [0124]: A data acquisition unit may obtain sensing data. A preprocessing unit may pre-process the obtained data to use for learning to determine whether the vehicle is running on the highway and learn the risk level. A learning data selection unit may select data required for learning from the preprocessed data and provide the selected data to a model learning unit); (¶ [0125]: the model learning unit may learn a data recognition model used for determining whether the vehicle is running on the highway and a risk level of the driver using the learning data); (¶ [0126]: the data recognition model may be a model based on a neural network such as a deep neural network and recurrent neural network).
As disclosed by the Applicant in the Specification at ¶ [0025], “The dynamic scene attribute may include: red/green light signal of the road during the vehicle 30 driving, positions of pedestrians around the vehicle 30, distances between the vehicle 30 and another vehicle in front, etc.”. As such, the specification suggests that the “dynamic scene attribute” corresponds to any dynamic information corresponding to the position of the vehicle and its surroundings. As noted above, Kim teaches a system configured to generate peripheral environmental information corresponding to environment information within a predetermined radius– equivalent to obtaining a dynamic scene attribute comprising at least positions of obstacles surrounding the vehicle.
Obtain a high-precision map comprising the position information of the vehicle, and determining a static scene attribute of the vehicle in accordance with the position information of the vehicle and the high-precision map, […] and the static scene attribute comprises at least one of a road type […] a speed limit […]; (¶ [0053]: see above); (¶ [0054]: the information about a current state of the vehicle which is sensed may include latitude and longitude information of a GPS sensor); (¶ [0057]: an input value of a data recognition model for determining whether the vehicle is running on the highway may be an input image generated by imaging signals of latitude and longitude information); (¶ [0059]: the device may determine whether the vehicle is running on the highway through a mapping function); (¶ [0069]: if the device determines that the driver is driving over a speed limit, the device may display an image that includes a speed gauge and warns the driver that the driver is driving over the speed limit).
As disclosed by the Applicant at ¶ [0022] of the Specification, “the static scene attribute may include whether the vehicle 30 is driving on a one-way road, whether the vehicle 30 is driving at an intersection, whether the road is configured with a speed limit, and a driving direction of a lane which the vehicle 30 need to follow”. Thus, the step for “determining a static scene attribute of the vehicle” is interpreted as a determining whether the vehicle is driving on a type of road. As noted above, Kim teaches a system configured to determine whether a vehicle is running on a highway (i.e., a road type) based on a mapping function and GPS sensor information. Furthermore, the system is configured to determine and warn a driver when they are driving over a speed limit.
Detect whether the dangerous driving behavior exists corresponding to the vehicle in combination with the dynamic scene attribute, the static scene attribute, and the operation information of the vehicle, to generate the detection result. (¶ [0043]-[0045]: see above); (¶ [0120] -¶ [0124]: A data acquisition unit may obtain sensing data. A preprocessing unit may pre-process the obtained data to use for learning to determine whether the vehicle is running on the highway and learn the risk level. A learning data selection unit may select data required for learning from the preprocessed data and provide the selected data to a model learning unit); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver); (¶ [0047]: the notification signal may be generated when the risk level is great than or equal to a threshold).
Although Kim teaches a system configured to monitor driving behavior corresponding to a vehicle via a device/micro-server, Kim does not explicitly teach that the vehicle belongs to a fleet and that the server manages a fleet of vehicles. Furthermore, Kim does not explicitly teach an on-board computer screening objective driving data associated with a preset potential dangerous event from initial driving data of the vehicle and transmitting the objective driving data to the server. Furthermore, Kim does not explicitly teach wherein the high-precision map comprises road elements and traffic-related dynamic elements.
However, Shoshan teaches the following:
A fleet management system, comprising one or more on-board computers and a server, the one or more on-board computers communicating with the server, each of the one or more on-board computers being configured in a vehicle of a fleet, the vehicle further comprising a data collecting device for collecting initial driving data, each of the one or more on-board computers communicating with a corresponding data collecting device, screening objective driving data associated with a preset potential dangerous event from the initial driving data of a corresponding vehicle and transmitting the objective driving data to the server to reduce an amount of data uploaded from the corresponding vehicle to the server, wherein the server is configured to: (col. 2, lines 5-6: Fig. 2 is a flowchart of an example method of managing a fleet of vehicles); (col. 1, lines 28-38: the system for managing vehicle sensor data comprises a central server configured to aggregate vehicle condition sensor data by vehicle identifier and vehicle position, and determine a safety condition for the aggregated vehicle condition sensor data); (col. 2, lines 62-67: the vehicles have the ability to connect and share information through a centrally-managed cloud computing system. The cloud aggregates vehicle information to determine safety conditions); (col. 7, lines 44-55: data can be categorized as routine or abnormal. The vehicle on-board system can analyze vehicle condition sensor data and determine that the data is routine and not send it to the cloud in order to reduce load. A vehicle can report only abnormal sensor data (e.g., slipping on a road, emergency stop, and the like). When a vehicle is in the perimeter of a determined safety condition, the cloud can request vehicles within the perimeter of the determined safety condition to also send routine sensor data); (col. 3, lines 25-41: the vehicles are equipped with sensors. Sensors provide specialized vehicle operation information and include standard on-board diagnostic (OBD) sensors, and cameras that capture road imagery. Vehicle condition sensor data can be sent from the vehicle to the cloud); (col. 4, lines 41-50: safety conditions can be vehicle related or location related. For example, dangerous driving behavior can be determined from sensors acquiring data from driver input controls, determining unsafe following distances, and excessive speed. Thus, vehicle related safety conditions pertain to a particular vehicle).
Thus, Shoshan discloses a vehicle equipped with sensors to capture sensor data; equivalent to the vehicle comprising a data collecting device for collecting initial driving data. Furthermore, the vehicles on-board system can analyze sensor data and determine whether data is routine or abnormal (i.e., indicating unsafe driving behaviors). Accordingly, the on-board system only sends abnormal sensor data to a cloud server in order to reduce load; equivalent to the on-board computers communicating with a corresponding data collecting device, screening objective driving data associated with a preset potential dangerous event from the initial driving data of a corresponding vehicle and transmitting the objective driving data to the server to reduce an amount of data uploaded from the corresponding vehicle to the server.
[…] wherein the high-precision map comprises road elements and traffic-related dynamic elements; (col. 8, lines 59-60: the aggregated safety conditions can be used to populate a live map); (col. 2, line 66 – col. 3, line 1: The cloud can aggregate the vehicle information to determine safety conditions that vehicles and drivers have encountered or will encounter); (col. 5, lines 1-3: Safety conditions can be classified as one or more of: road hazard, traffic condition, or emergency vehicle).
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 the system of Kim with the teachings of Shoshan by incorporating the centrally-managed cloud server configured to manage driving sensor data from a plurality of vehicles within a fleet, an on-board computer that screens objective driving data received from a plurality of vehicle sensors and associated with preset potential dangerous events from initial driving data of the vehicle collected by the sensors, transmit the objective driving data to the server, and determine driving behaviors for each particular vehicle, as taught by Shoshan, into the system of Kim comprising a device/micro-server that is configured to collect sensor data from a vehicle to determine driving behaviors. Furthermore, it would have been obvious to one of ordinary skill in the art to have modified the system of Kim with the teachings of Shoshan by incorporating the high-precision map comprising road elements and traffic-related dynamic elements, as taught by Shoshan, into the system of Kim that is configured to utilize a mapping function to gather relevant information associated with a vehicle. One of ordinary skill in the art would have been motivated to make these modifications “in order to build an accurate image of the ongoing safety condition” (col. 7, lines 55-57) and when one considers “[a]nother advantage of the described technologies is that vehicle management system can use the aggregated vehicle information to guide traffic and ensure efficient use of available resources, such as road capacity” (col. 15, lines 35-39), as suggested by Shoshan. Furthermore, one of ordinary skill in the art would have recognized that the teachings of Shoshan are compatible with the system of Kim as they share capabilities and characteristics. In particular, they are both systems comprising servers configured to monitor vehicle driving data via on-board sensors and detect dangerous driving behaviors.
Kim/Shoshan does not explicitly teach wherein the management strategies of a fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet. Furthermore, Kim/Shoshan does not explicitly teach a server further configured to determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request, and select a second vehicle from the first number of candidate vehicles to respond the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles, wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle.
However, Marueli teaches the following:
Wherein the management strategies of the fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet is determined in accordance with a safety score determined by types of dangerous driving behaviors of each vehicle of the fleet; (¶ [0012]: a queue of drivers for a particular area is maintained, wherein the queue specifies an order in which drivers are selected for transportation requests for a particular area); (¶ [0067]: the server may determine driver placement within a queue based on characteristics of transportation requests and performance metrics/scores associated with the drivers); (¶ [0078]: performance metrics may include a safety record, e.g., a measure of traffic accidents experienced or traffic tickets received).
The server is further configured to: determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; (¶ [0012]: see above); (¶ [0067]: the server may determine driver placement within a queue based on characteristics of transportation requests and performance metrics/scores associated with the drivers); (¶ [0019]: backend system may select a driver based on any suitable factors, including information contained in the transportation request, the proximity of the driver to the passenger, whether the pickup location is located within an area serviced by one or more queues, or any other suitable factors);
Select a second vehicle from the first number of candidate vehicles to respond to the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles; wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle. (¶ [0019]: see above); (¶ [0078]: see above); (¶ [0067]: if a driver has a relatively high performance score indicating that the driver is performing well relative to other drivers, the driver may be placed at a spot in the queue that is higher than the bottom of the queue); (¶ [0012]: a queue of drivers for a particular area is maintained, wherein the queue specifies an order in which drivers are selected for transportation requests for a particular area).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the system of Kim/Shoshan the ability to determine a recommendation priority of each vehicle of a fleet, the recommendation priority of each vehicle of the fleet determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet; determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; and select a second vehicle from the first number of candidate vehicles to respond to the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle, as taught by Marueli, since the claimed invention is merely a combination of old elements. In combination, each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination are predictable. Furthermore, one of ordinary skill in the art would have been motivated to make this modification when one considers a “driver could be given a preferred position in the queue […] if the driver has performed well relative to other drivers” (¶ [0014]), as suggested by Marueli, and thus incentivizing drivers to drive safely.
Claim 11: Kim/Shoshan/Marueli teaches the limitations of claim 7. Furthermore, the limitations of claim 11 are substantially analogous to the limitations of claim 5. Accordingly, claim 11 is rejected for substantially the same reasons and rationale as set forth above with regard to claim 5.
Claim 14: Kim teaches the following:
A server configured for communicating with one or more on-board computers, each of the one or more on-board computers being configured in a vehicle […] the server comprising: at least one processor; and a data storage storing one or more programs which when executed by the at least one processor, cause the at least one processor to be configured to: (¶ [0035]: the device may be a micro server); (¶ [0036]: the device may communicate with a server in order to utilize information generated during running of various vehicles); (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like); (¶ [0089]: a controller of the the device comprises one or more processors and executed programing stored in the memory).
Receive the objective driving data from an objective on-board computer of the on-board computers; (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like).
Detect whether a dangerous driving behavior exists corresponding to a first vehicle of the fleet configured with the objective on-board computer in accordance with the objective driving data to generate a detection result; and (¶ [0049]: see above); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver).
Determine a management strategy of the vehicle in accordance with the detection result. (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver); (¶ [0047]: the notification signal may be generated when the risk level is great than or equal to a threshold); (¶ [0071]: the device may generate the notification signal with sound and/or vibration and output the notification signal. For example, the device may provide a driver with a guidance sound to induce safe driving. The guidance sound may be a voice to encourage stretching, a voice to explain a method of resolving drowsiness, and a voice to guide the driver to a resting place or a parking spot).
Wherein the objective driving data comprises operation information of the vehicle, images of roads during the vehicle driving, and position information of the vehicle; (¶ [0049]: the device may determine the risk level of the driver in consideration of at least information obtained from the vehicle. The information may include image information generated from a camera included in the vehicle, on-board diagnostics (OBD) (e.g., angle information of the steering wheel, RPM information, etc.), and the like); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0049]: the information obtained from the vehicle may include image information generated from a camera included in the vehicle); (¶ [0029]: the device may use information generated during running of a vehicle to determine a status of a driver. The device may determine whether the vehicle is running on a predetermined road. If the vehicle is running on the road, the device may determine a risk level of the driver); (¶ [0053]: the device may determine whether the vehicle is running on the highway, based on information about a current state of the vehicle which is sensed while the vehicle is running); (¶ [0054]: the information about a current state of the vehicle which is sensed may include latitude and longitude information of a GPS sensor); (¶ [0057]: an input value of a data recognition model for determining whether the vehicle is running on the highway may be an input image generated by imaging signals of latitude and longitude information).
When the at least one processor detects whether the dangerous driving behavior exists corresponding to the first vehicle of the fleet configured with the objective on-board computer in accordance with the objective driving data to generate the detection result, the server is further configured to: input the images of the roads into a preset image semantic recognition model to obtain a dynamic scene attribute of the first vehicle, wherein the dynamic scene attribute comprises at least one of […] positions of obstacles surrounding the vehicle […]; (¶ [0043]: the device may recognize the running pattern of the vehicle based on the information sensed by the device. The running pattern of the vehicle may include dangerous driving, which includes erratic driving, violent driving, speeding driving, lane violation, sudden stopping, sudden lane changing, etc.); (¶ [0044]: the device may determine a current status of the driver of the vehicle based on the running pattern of the vehicle); (¶ [0030]: information generated during running of the vehicle may include peripheral environment information); (¶ [0034]: peripheral environment information of the device may refer, for example, and without limitation, to environment information within a predetermined radius from the device); (¶ [0049]: see above); (¶ [0029]: see above); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0049]: the information obtained from the vehicle may include image information generated from a camera included in the vehicle); (¶ [0120] -¶ [0124]: A data acquisition unit may obtain sensing data. A preprocessing unit may pre-process the obtained data to use for learning to determine whether the vehicle is running on the highway and learn the risk level. A learning data selection unit may select data required for learning from the preprocessed data and provide the selected data to a model learning unit); (¶ [0125]: the model learning unit may learn a data recognition model used for determining whether the vehicle is running on the highway and a risk level of the driver using the learning data); (¶ [0126]: the data recognition model may be a model based on a neural network such as a deep neural network and recurrent neural network).
As disclosed by the Applicant in the Specification at ¶ [0025], “The dynamic scene attribute may include: red/green light signal of the road during the vehicle 30 driving, positions of pedestrians around the vehicle 30, distances between the vehicle 30 and another vehicle in front, etc.”. As such, the specification suggests that the “dynamic scene attribute” corresponds to any dynamic information corresponding to the position of the vehicle and its surroundings. As noted above, Kim teaches a system configured to generate peripheral environmental information corresponding to environment information within a predetermined radius– equivalent to obtaining a dynamic scene attribute comprising at least positions of obstacles surrounding the vehicle.
Obtain a high-precision map comprising the position information of the vehicle, and determining a static scene attribute of the vehicle in accordance with the position information of the vehicle and the high-precision map, […] and the static scene attribute comprises at least one of a road type […] a speed limit […]; (¶ [0053]: see above); (¶ [0054]: the information about a current state of the vehicle which is sensed may include latitude and longitude information of a GPS sensor); (¶ [0057]: an input value of a data recognition model for determining whether the vehicle is running on the highway may be an input image generated by imaging signals of latitude and longitude information); (¶ [0059]: the device may determine whether the vehicle is running on the highway through a mapping function); (¶ [0069]: if the device determines that the driver is driving over a speed limit, the device may display an image that includes a speed gauge and warns the driver that the driver is driving over the speed limit).
As disclosed by the Applicant at ¶ [0022] of the Specification, “the static scene attribute may include whether the vehicle 30 is driving on a one-way road, whether the vehicle 30 is driving at an intersection, whether the road is configured with a speed limit, and a driving direction of a lane which the vehicle 30 need to follow”. Thus, the step for “determining a static scene attribute of the vehicle” is interpreted as a determining whether the vehicle is driving on a type of road. As noted above, Kim teaches a system configured to determine whether a vehicle is running on a highway (i.e., a road type) based on a mapping function and GPS sensor information. Furthermore, the system is configured to determine and warn a driver when they are driving over a speed limit.
Detect whether the dangerous driving behavior exists corresponding to the vehicle in combination with the dynamic scene attribute, the static scene attribute, and the operation information of the vehicle, to generate the detection result. (¶ [0043]-[0045]: see above); (¶ [0120] -¶ [0124]: A data acquisition unit may obtain sensing data. A preprocessing unit may pre-process the obtained data to use for learning to determine whether the vehicle is running on the highway and learn the risk level. A learning data selection unit may select data required for learning from the preprocessed data and provide the selected data to a model learning unit); (¶ [0045]: The device may determine a current status of a driver. For example, the device may determine that the driver is in a dangerous state if the vehicle has been driven dangerously. As an example, if the device recognizes that the vehicle shows a running pattern that crosses a lane in which the vehicle is running, the device may determine that the vehicle has been driven dangerously. At this time, the device determines that the driver is in a careless state); (¶ [0046]: the device may generate a notification signal based on the risk level of the driver determined based on the current status of the driver); (¶ [0047]: the notification signal may be generated when the risk level is great than or equal to a threshold).
Although Kim teaches a system configured to monitor driving behavior corresponding to a vehicle via a device/micro-server, Kim does not explicitly teach that the vehicle belongs to a fleet and that the server manages a fleet of vehicles. Furthermore, Kim does not explicitly teach an on-board computer screening objective driving data associated with a preset potential dangerous event from initial driving data of the vehicle and transmitting the objective driving data to the server. Furthermore, Kim does not explicitly teach wherein the high-precision map comprises road elements and traffic-related dynamic elements.
However, Shoshan teaches the following:
A server configured for communicating with one or more on-board computers, each of the one or more on-board computers being configured in a vehicle of a fleet, the vehicle further comprising a data collecting device for collecting initial driving data, each of the one or more on-board computers communicating with a corresponding data collecting device, screening objective driving data associated with a preset potential dangerous event from the initial driving data of a corresponding vehicle and transmitting the objective driving data to the server to reduce an amount of data uploaded from the corresponding vehicle to the server, the server comprising: at least one processor; and a data storage storing one or more programs which when executed by the at least one processor, cause the at least one processor to: (col. 2, lines 5-6: Fig. 2 is a flowchart of an example method of managing a fleet of vehicles); (col. 1, lines 28-38: the system for managing vehicle sensor data comprises a central server configured to aggregate vehicle condition sensor data by vehicle identifier and vehicle position, and determine a safety condition for the aggregated vehicle condition sensor data); (col. 2, lines 62-67: the vehicles have the ability to connect and share information through a centrally-managed cloud computing system. The cloud aggregates vehicle information to determine safety conditions); (col. 7, lines 44-55: data can be categorized as routine or abnormal. The vehicle on-board system can analyze vehicle condition sensor data and determine that the data is routine and not send it to the cloud in order to reduce load. A vehicle can report only abnormal sensor data (e.g., slipping on a road, emergency stop, and the like). When a vehicle is in the perimeter of a determined safety condition, the cloud can request vehicles within the perimeter of the determined safety condition to also send routine sensor data); (col. 3, lines 25-41: the vehicles are equipped with sensors. Sensors provide specialized vehicle operation information and include standard on-board diagnostic (OBD) sensors, and cameras that capture road imagery. Vehicle condition sensor data can be sent from the vehicle to the cloud); (col. 4, lines 41-50: safety conditions can be vehicle related or location related. For example, dangerous driving behavior can be determined from sensors acquiring data from driver input controls, determining unsafe following distances, and excessive speed. Thus, vehicle related safety conditions pertain to a particular vehicle).
Thus, Shoshan discloses a vehicle equipped with sensors to capture sensor data; equivalent to the vehicle comprising a data collecting device for collecting initial driving data. Furthermore, the vehicles on-board system can analyze sensor data and determine whether data is routine or abnormal (i.e., indicating unsafe driving behaviors). Accordingly, the on-board system only sends abnormal sensor data to a cloud server in order to reduce load; equivalent to the on-board computer communicating with the data collecting device, screening objective driving data associated with a preset potential dangerous event from the initial driving data and transmitting the objective driving data to the server to reduce an amount of data uploaded from the vehicle to the server.
[…] wherein the high-precision map comprises road elements and traffic-related dynamic elements; (col. 8, lines 59-60: the aggregated safety conditions can be used to populate a live map); (col. 2, line 66 – col. 3, line 1: The cloud can aggregate the vehicle information to determine safety conditions that vehicles and drivers have encountered or will encounter); (col. 5, lines 1-3: Safety conditions can be classified as one or more of: road hazard, traffic condition, or emergency vehicle).
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 the system of Kim with the teachings of Shoshan by incorporating the centrally-managed cloud server configured to manage driving sensor data from a plurality of vehicles within a fleet, an on-board computer that screens objective driving data received from a plurality of vehicle sensors and associated with preset potential dangerous events from initial driving data of the vehicle collected by the sensors, transmit the objective driving data to the server, and determine driving behaviors for each particular vehicle, as taught by Shoshan, into the system of Kim comprising a device/micro-server that is configured to collect sensor data from a vehicle to determine driving behaviors. Furthermore, it would have been obvious to one of ordinary skill in the art to have modified the system of Kim with the teachings of Shoshan by incorporating the high-precision map comprising road elements and traffic-related dynamic elements, as taught by Shoshan, into the system of Kim that is configured to utilize a mapping function to gather relevant information associated with a vehicle. One of ordinary skill in the art would have been motivated to make these modifications “in order to build an accurate image of the ongoing safety condition” (col. 7, lines 55-57) and when one considers “[a]nother advantage of the described technologies is that vehicle management system can use the aggregated vehicle information to guide traffic and ensure efficient use of available resources, such as road capacity” (col. 15, lines 35-39), as suggested by Shoshan. Furthermore, one of ordinary skill in the art would have recognized that the teachings of Shoshan are compatible with the system of Kim as they share capabilities and characteristics. In particular, they are both systems comprising servers configured to monitor vehicle driving data via on-board sensors and detect dangerous driving behaviors.
Kim/Shoshan does not explicitly teach wherein the management strategies of a fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet. Furthermore, Kim/Shoshan does not explicitly teach a processor further caused to determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request, and select a second vehicle from the first number of candidate vehicles to respond the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles, wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle.
However, Marueli teaches the following:
Wherein the management strategies of the fleet comprise a recommendation priority of each vehicle of the fleet, the recommendation priority of each vehicle of the fleet is determined in accordance with a safety score determined by types of dangerous driving behaviors of each vehicle of the fleet; (¶ [0012]: a queue of drivers for a particular area is maintained, wherein the queue specifies an order in which drivers are selected for transportation requests for a particular area); (¶ [0067]: the server may determine driver placement within a queue based on characteristics of transportation requests and performance metrics/scores associated with the drivers); (¶ [0078]: performance metrics may include a safety record, e.g., a measure of traffic accidents experienced or traffic tickets received).
The at least one processor is further caused to: determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; (¶ [0012]: see above); (¶ [0067]: the server may determine driver placement within a queue based on characteristics of transportation requests and performance metrics/scores associated with the drivers); (¶ [0019]: backend system may select a driver based on any suitable factors, including information contained in the transportation request, the proximity of the driver to the passenger, whether the pickup location is located within an area serviced by one or more queues, or any other suitable factors);
Select a second vehicle from the first number of candidate vehicles to respond to the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles; wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle. (¶ [0019]: see above); (¶ [0078]: see above); (¶ [0067]: if a driver has a relatively high performance score indicating that the driver is performing well relative to other drivers, the driver may be placed at a spot in the queue that is higher than the bottom of the queue); (¶ [0012]: a queue of drivers for a particular area is maintained, wherein the queue specifies an order in which drivers are selected for transportation requests for a particular area).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the system of Kim/Shoshan the ability to determine a recommendation priority of each vehicle of a fleet, the recommendation priority of each vehicle of the fleet determined in accordance with a safety score determined by dangerous driving behaviors of each vehicle of the fleet; determine a first number of candidate vehicles from a second number of vehicles of the fleet in accordance with a pick-up location indicated by a received vehicle dispatching request; and select a second vehicle from the first number of candidate vehicles to respond to the received vehicle dispatching request in accordance with the recommendation priority of each of the first number of candidate vehicles wherein the higher the recommendation priority of the candidate vehicle is, the greater the probability that the candidate vehicle is selected as the second vehicle, as taught by Marueli, since the claimed invention is merely a combination of old elements. In combination, each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination are predictable. Furthermore, one of ordinary skill in the art would have been motivated to make this modification when one considers a “driver could be given a preferred position in the queue […] if the driver has performed well relative to other drivers” (¶ [0014]), as suggested by Marueli, as thus incentivizing drivers to drive safely.
Claim 18: Kim/Shoshan/Marueli teaches the limitations of claim 14. Furthermore, the limitations of claim 18 are substantially analogous to the limitations of claim 5. Accordingly, claim 18 is rejected for substantially the same reasons and rationale as set forth above with regard to claim 5.
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 JORGE G DEL TORO-ORTEGA whose telephone number is (571)272-5319. The examiner can normally be reached Monday-Friday 9:00AM-6:00PM.
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, Jeffrey Zimmerman can be reached at (571) 272-4602. 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.
/JORGE G DEL TORO-ORTEGA/Examiner, Art Unit 3628
/JEFF ZIMMERMAN/Supervisory Patent Examiner, Art Unit 3628
