DETAILED ACTION
Status of Claims
The following is a non-final, first office action in response to the communication filed 5/9/2023.
Claims 1-20 are currently pending and have been examined.
Priority
The applicant’s claim for benefit of Provisional Patent Application Serial No. 62/782179, filed 12/19/2018, and 62/930,772, filed 11/5/2019, have been received and acknowledged.
Information Disclosure Statement
Information Disclosure Statements received 4/8/2026 and 6/8/2023 have been reviewed and considered.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 of the Subject Matter Eligibility Test entails considering whether the claimed subject matter falls within the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: Process, machine, manufacture, or composition of matter.
Claims 1-20 are directed to a method (process), and a system (machine or manufacture), respectively. As such, the claims are directed to statutory categories of invention.
If the claim recites a statutory category of invention, the claim requires further analysis in Step 2A. Step 2A of the Subject Matter Eligibility Test is a two-prong inquiry. In Prong One, examiners evaluate whether the claim recites a judicial exception.
Claim 1 recites abstract limitations, including those identified in bold below:
1. A computer-implemented method for monitoring a vehicle location using device sensor data, the method comprising: receiving sensor data from a plurality of sensors integrated into a wireless device located at a fixed position in the vehicle; fusing the received sensor data by: combining the sensor data from the plurality of sensors in a common reference frame; and applying one or more motion constraints to the combined sensor data; and calculating a current location of the vehicle using the fused sensor data by performing dead reckoning between successive global positioning system (GPS) points transmitted by a provider client device associated with the vehicle.
These limitations, as drafted, are a process that, under its broadest reasonable interpretation, cover performance of the limitations in the mind, or by a human using pen and paper, and therefore recite mental processes. More specifically, other than reciting that the method is “computer-implemented” nothing in the claim element precludes the aforementioned steps from practically being performed in the human mind, or by a human using pen and paper. The mere recitation of a generic computer does not take the claim out of the mental process grouping. Thus, the claim recites an abstract idea.
These limitations, as drafted, also recite limitations that, under its broadest reasonable interpretation, represent mathematical relationships and are therefore mathematical concepts (limitations recite calculating and the specification identifies the fusion process including mathematical equations). The mere recitation of a generic computer does not take the claim out of the mathematical concepts grouping. Thus, the claim recites an abstract idea.
Claim 11 recites analogous abstract limitations.
If the claim recites a judicial exception in step 2A Prong One, the claim requires further analysis in step 2A Prong Two. In step 2A Prong Two, examiners evaluate whether the claim recites additional elements that integrate the exception into a practical application of that exception.
Claim 1 recites additional elements, including those underlined below:
1. A computer-implemented method for monitoring a vehicle location using device sensor data, the method comprising: receiving sensor data from a plurality of sensors integrated into a wireless device located at a fixed position in the vehicle; fusing the received sensor data by: combining the sensor data from the plurality of sensors in a common reference frame; and applying one or more motion constraints to the combined sensor data; and calculating a current location of the vehicle using the fused sensor data by performing dead reckoning between successive global positioning system (GPS) points transmitted by a provider client device associated with the vehicle.
Claim 11 recites further additional elements, including those underlined below:
11. A system comprising: a processor for executing computer program instructions; and a non-transitory computer-readable storage medium storing computer program instructions executable by the processor to perform operations [identified in claim 1].
The functions of the computer (and associated computing elements) are recited at a high level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component.
The receiving step and transmitting steps are recited at a high level of generality (i.e. as a general means of gathering data for use in the fusing and calculating steps), and amounts to mere data gathering, which is a form of insignificant extra-solution activity.
The characterization of the sensor as being integrated into a wireless device located at a fixed position in the vehicle, and the characterization of the device as a provider client device, also amount to indicating a field of use or technological environment in which to apply a judicial exception and cannot integrate the judicial exception into a practical application (see MPEP 2106.05(h)).
Accordingly, in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
If the additional elements do not integrate the exception into a practical application in step 2A Prong Two, then the claim is directed to the recited judicial exception, and requires further analysis under Step 2B to determine whether they provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself).
As discussed above, the computer (and associated components) for implementing the method amounts to mere instructions to apply the exception Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. 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 does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
As discussed above, the characterization of the sensor as being integrated into a wireless device located at a fixed position in the vehicle, and the characterization of the device as a provider client device, amounts to merely indicating a field of use or technological environment in which to apply a judicial exception, which does not amount to significantly more than the exception itself. (see MPEP 2106.05(h)).
As discussed above, the receiving and transmitting step amounts to extra-solution data gathering. The Symantec, TLI, OIP Techs. and buySAFE court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection or receipt of data over a network is a well‐understood, routine, conventional function when it is claimed in a merely generic manner (as it is here). In addition, the specification demonstrates the well-understood, routine, conventional nature of additional elements as it describes the additional elements as well-understood or routine or conventional (or an equivalent term), as a commercially available product, or in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy 35 U.S.C. §112(a).
Thus, even when viewed as an ordered combination, nothing in the claims add significantly more (i.e. an inventive concept) to the abstract idea.
Regarding the limitations of claim 2, 7-8, 12 and 17-18 the further characterization of sensor types, signal types, and electronic features (e.g., map) amounts to merely indicating a field of use or technological environment in which to apply a judicial exception, which does not amount to significantly more than the exception itself. (see MPEP 2106.05(h)).
Regarding the limitations of claim 3, 5, 10, 13, 15 and 20 further characterizing of the fusing process (using tightly or loosely coupled architecture, and particular data types), merely acts to further characterize the previously identified abstract concepts (mental processes), and per the specification may comprise mathematical concepts. For the reasons described above with respect to claim 1, this judicial exception is not meaningfully integrated into a practical application, or significantly more than the abstract idea.
Regarding the limitations of claim 4, 6, 14 and 16 the generation of recommendation, updating a time of arrival and updating a map can be performed in the human mind or by a human using pen and paper and is therefore an abstract concept, merely acts to further characterize the previously identified abstract concepts. For the reasons described above with respect to claim 1, this judicial exception is not meaningfully integrated into a practical application, or significantly more than the abstract idea.
Regarding the limitations of 9, and 19 further characterizing of the fusing process as utilizing a Kalman filter algorithm represent mathematical concepts. For the reasons described above with respect to claim 1, this judicial exception is not meaningfully integrated into a practical application, or significantly more than the abstract idea.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 7, 9, 11, 17 and 19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ricci 20160086391 A1
Regarding claim 1, Ricci is directed to the management or fleetwide vehicle data. Rici discloses:
A computer-implemented method for monitoring a vehicle location using device sensor data (see Fig. 2, [0163], [0174]) , the method comprising:
receiving sensor data from a plurality of sensors integrated into a wireless device located at a fixed position in the vehicle;
Ricci [0163] An embodiment of a vehicle system 200 is shown in FIG. 2; vehicle sensors 242A-N; Ricci [0174] The vehicle control system 204 may also communicate with one or more sensors 236, 242, which are either associated with the vehicle 104 or communicate with the vehicle 104. …Embodiments of these sensors may be as described in conjunction with FIGS. 6A-7B.; Ricci [0234] A set of sensors or vehicle components 600 associated with the vehicle 104 may be as shown in FIG. 6A. … ; Ricci [0235] The vehicle 104 can include a number of sensors in wireless or wired communication with the vehicle control system 204 and/or display device 212, 248 to collect sensed information regarding the vehicle state, configuration, and/or operation. Exemplary sensors may include one or more of, but are not limited to, …vehicle control system sensors, wireless network sensor (e.g., Wi-Fi and/or Bluetooth® sensor), cellular data sensor, and other sensors either future-developed or known to those of skill in the vehicle art.
See also: Ricci [0662] The fleetwide vehicle telematics system 6500 comprises modules of: data acquisition 6510, data storage 6520 comprising data structures 6800, data cleansing and normalization 6730, third-party data 6535, geolocation mapping 6540, data fusion 6550, data distribution warehouse 6560, and customer telematics analysis services 6580 comprising correlations 6582, trends 6584 and business intelligence 6586.; Ricci [0663] Data acquisition 6510 receives data regarding a plurality of vehicles from one or more sources. The data received comprises vehicle state data comprising latitude/longitude location, speed, acceleration, deceleration, jerk, turn radius, engine parameters such as fluid levels (oil, hydraulic, brake, etc), airbag deployment state (deployed or stowed), video from a vehicle interior camera and video from a vehicle exterior camera, and driver and passenger device use (e.g. smartphone use such as texting). The data may be generated from sources to include vehicle on-board sensors, overhead (eg satellite) monitoring/surveillance, commercial tracking services, and customer enterprise systems (e.g. driver profile data, vehicle features and configuration).
fusing the received sensor data by: combining the sensor data from the plurality of sensors in a common reference frame; and applying one or more motion constraints to the combined sensor data; and
Ricci [0236] The vehicle control system 204 may also provide signal processing of one or more sensors, sensor fusion of similar and/or dissimilar sensors, signal smoothing in the case of erroneous “wild point” signals, and/or sensor fault detection. For example, ranging measurements provided by one or more RF sensors may be combined with ranging measurements from one or more IR sensors to determine one fused estimate of vehicle range to an obstacle target. (see also [0665] use of thresholds to identify erroneous data; [0666] disclosing data fusion algorithms known in the art)
See also: Ricci [0662], [0667]-[0668] Data Fusion 6550 module may employ any fusion algorithms know to those skilled in the art to combine the data. For example, regarding a speed value of a particular vehicle. Data source one (e.g. from a vehicle-mounted speedometer) providing a first measurement of speed may be combined with data source two (e.g. as measured from data derived from cell phone transmissions) by a state estimation algorithm to yield one combined or fused estimate of the speed (a particular “state” value of the vehicle). State estimation algorithms may comprise Kalman filtering
calculating a current location of the vehicle using the fused sensor data by performing dead reckoning between successive global positioning system (GPS) points transmitted by a provider client device associated with the vehicle.
Ricci [0165] The vehicle control system 204 may communicate with a device or a user interface 212, 248.. Further, the symbol 212, 248 can represent a device that is located or associated with the vehicle 104. The device 212, 248 can be a mobile device, including, but not limited to, a mobile telephone, a mobile computer, or other type of computing system or device that is either permanently located in or temporarily associated with, but not necessarily connected to, the vehicle 104. Thus, the vehicle control system 204 can interface with the device 212, 248 and leverage the device's computing capability to provide one or more of the features or functions as described herein.; Ricci [0166]-[0167], [0269] Further, the device 212, 248 may include or have access to device data 220 and/or profile data 252 - (e.g.,geographic location information (e.g., provided by a satellite positioning system (e.g., GPS, Wi-Fi hotspot, cell tower data, etc.)),
Ricci [0304] The location module 896 can be the controller of the satellite navigation system designed for use in automobiles. The location module 896 can acquire position data, as from the GPS Antenna/receiver 892, to locate the user or vehicle 104 on a road in the unit's map database 8100. Using the road database 8100, the location module 896 can give directions to other locations along roads also in the database 8100. When a GPS signal is not available, the location module 896 may apply dead reckoning to estimate distance data from sensors 242 including one or more of, but not limited to, a speed sensor attached to the drive train of the vehicle 104, a gyroscope, an accelerometer, etc. GPS signal loss and/or multipath can occur due to urban canyons, tunnels, and other obstructions. Additionally or alternatively, the location module 896 may use known locations of Wi-Fi hotspots, cell tower data, etc. to determine the position of the vehicle 104, such as by using time difference of arrival (TDOA) and/or frequency difference of arrival (FDOA) techniques.
See also Ricci [0035] The term “automotive navigation system” can refer to a satellite navigation system designed for use in vehicles. It typically uses a GPS navigation device to acquire position data to locate the user on a road in the unit's map database. Using the road database, the unit can give directions to other locations along roads also in its database. Dead reckoning using distance data from sensors attached to the drivetrain, a gyroscope and an accelerometer can be used for greater reliability, as GPS signal loss and/or multipath can occur due to urban canyons or tunnels.; Ricci [0250]
Regarding claim 7, Ricci discloses the limitations of claim 1 and further discloses wherein the wireless device receives beacon signals via Bluetooth or Bluetooth Low Energy (BLE) technologies or protocols.
Ricci [0313] FIG. 9 illustrates an optional communications architecture where, the host device 908 may include one more routing profiles, permission modules, and rules that control how communications within the vehicle 104 are to occur. … The host device 908 can act as a mobile hot spot for any one or more of the other devices 912, which may not need to communicate over the network/communications buses 224/404, but could instead connect directly to the host device 908 via, for example, NFC, Bluetooth®, WiFi, or the like. When the device 908 is acting as the host device, the device 908 can include one or more routing profiles, permissions, rules modules, and can also act as a firewall for the various inter and intra vehicle communications.; Ricci [0421] In one embodiment, vehicle 2004 may intercept emitted signals from one or more devices 212 in or about the vehicle to pair a device 212 with vehicle 2004. The emitted signals may be detected, for example, via one or more sensors, antennas, receivers, transmitters, and/or combinations thereof. … In one embodiment, pairing may be initiated by vehicle 2004 (upon a first registration) to a user's device (e.g., device 212). In one embodiment, subsequent pairings may be initiated by user's device 212 to the vehicle 2004. In one embodiment, one or more of Bluetooth®, Near Field Communications (NFC), and/or other protocols may be used to pair device 212 with vehicle 2004.
Regarding claim 9, Ricci discloses the limitations of claim 1 and further discloses further comprising fusing the received sensor data by applying a Kalman filter algorithm.
Ricci [0236] The vehicle control system 204 may also provide signal processing of one or more sensors, sensor fusion of similar and/or dissimilar sensors, signal smoothing in the case of erroneous “wild point” signals, and/or sensor fault detection. For example, ranging measurements provided by one or more RF sensors may be combined with ranging measurements from one or more IR sensors to determine one fused estimate of vehicle range to an obstacle target. (see also [0665] use of thresholds to identify erroneous data; [0666] disclosing data fusion algorithms known in the art); Ricci [0667] Data Fusion 6550 module sends and receives data, such as data of data structure 6800, with modules comprising: geolocation mapping 6540, data distribution warehouse 6560 and customer telematics analysis services 6580. Data Fusion 6550 module may employ any fusion algorithms know to those skilled in the art to combine the data. For example, regarding a speed value of a particular vehicle. Data source one (e.g. from a vehicle-mounted speedometer) providing a first measurement of speed may be combined with data source two (e.g. as measured from data derived from cell phone transmissions) by a state estimation algorithm to yield one combined or fused estimate of the speed (a particular “state” value of the vehicle). State estimation algorithms may comprise Kalman filtering. Data Fusion 6550 module may be a commercial off the shelf system and/or be performed by an outside third party.
Regarding claim 11, see the above rejection of claim 1. Ricci further discloses:
A system comprising: a processor for executing computer program instructions; and a non-transitory computer-readable storage medium storing computer program instructions executable by the processor to perform operations comprising: [see claim 1]
Ricci [0009]-[0014]
Regarding claim 17, Ricci discloses the limitations of claim 11. See also the above rejection of claim 7.
Regarding claim 19, Ricci discloses the limitations of claim 11. See also the above rejection of claim 9.
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 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.
Claim(s) 2-3, 5, 10, 12-13, 15 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ricci (20160086391) further in view of Ohev Zion (US 20200158888).
Regarding claim 2, Ricci discloses the limitations of claim 1 and further discloses a plurality of sensors (see rejection of claim 1), but does not explicitly disclose the sensor types as claimed, which are more explicitly disclosed by Ohev Zion, which is directed to synchronization between global navigation system measurements and inertial measurements.
Ohev Zion discloses wherein the plurality of sensors includes an inertial measurement unit (IMU), a global navigation satellite system (GNSS) receiver, and a barometer.
Ohev Zion [0062] In some demonstrative embodiments, device 102 may include a measurement processor 115 configured to process one or more measurements, e.g., navigation and/or positioning measurements, for example, to estimate a location of device 102, e.g., as described below.; Ohev Zion [0097] In some demonstrative embodiments, IMU 160 may include any other additional or alternative sensor, e.g., configured to detect movement and/or a change in a position of device 102, for example, a barometer, a compass, a Micro Electro-Mechanical Systems (MEMS) sensor, a speedometer, a motion sensor, a 6 Degree of Freedom (DoF) sensor, a 9-axis MEMS sensor, and/or a location determination mechanism and/or algorithm.; Ohev Zion [0107] In some demonstrative embodiments, a combination (“fusion”) of inertial measurements 143 and GNSS measurements 133, e.g., in a GNSS-IMU navigation system, may be implemented according to one or more methods and/or techniques, e.g., as described below.; Ohev Zion [0108] In some demonstrative embodiments, the combination inertial measurements 143 and GNSS measurements 133 may be implemented according to a loosely-coupled integration. For example, positions and velocities derived from GNSS measurements 133 may be merged as updates to position estimation information of IMU 160, for example, derived from inertial measurements 143, e.g., through a navigation Kalman filter.; Ohev Zion [0109] In some demonstrative embodiments, the combination of inertial measurements 143 and GNSS measurements 133 may be implemented according to a tightly-coupled integration. For example, one or more Kalman filters, for example, including a centralized Kalman filter, may be implemented to integrate GNSS measurements 133, e.g., estimated pseudo-ranges, delta-range and/or Doppler shifts, from GNSS receiver 120, with inertial measurements 143, e.g., one or more of linear acceleration, angular velocity, position, velocity, and/or altitude information, from mechanization equations of IMU 160.
One of ordinary skill in the art at the time of filing would have recognized that applying the known sensor integrations of Ohev Zion to the location estimation of Ricci would have yielded predictable results and resulted in an improved system for determining correct vehicle location.
Regarding claim 3, Ricci discloses the limitations of claim 1 and further discloses further comprising fusing the received sensor data using a … sensor fusion architecture.
Ricci [0236] The vehicle control system 204 may also provide signal processing of one or more sensors, sensor fusion of similar and/or dissimilar sensors, signal smoothing in the case of erroneous “wild point” signals, and/or sensor fault detection. For example, ranging measurements provided by one or more RF sensors may be combined with ranging measurements from one or more IR sensors to determine one fused estimate of vehicle range to an obstacle target. (see also [0665] use of thresholds to identify erroneous data; [0666] disclosing data fusion algorithms known in the art); Ricci [0662] – [0663], [0666] - [0668] Data Fusion 6550 module may employ any fusion algorithms know to those skilled in the art to combine the data. For example, regarding a speed value of a particular vehicle. Data source one (e.g. from a vehicle-mounted speedometer) providing a first measurement of speed may be combined with data source two (e.g. as measured from data derived from cell phone transmissions) by a state estimation algorithm to yield one combined or fused estimate of the speed (a particular “state” value of the vehicle). State estimation algorithms may comprise Kalman filtering.
Ricci discloses the fusion function, does not explicitly disclose the fusion architecture type as claimed. Ohev Zion discloses application of a tightly coupled sensor fusion architecture.
Ohev Zion [0097]; Ohev Zion [0107] In some demonstrative embodiments, a combination (“fusion”) of inertial measurements 143 and GNSS measurements 133, e.g., in a GNSS-IMU navigation system, may be implemented according to one or more methods and/or techniques, e.g., as described below.; Ohev Zion [0109] In some demonstrative embodiments, the combination of inertial measurements 143 and GNSS measurements 133 may be implemented according to a tightly-coupled integration. For example, one or more Kalman filters, for example, including a centralized Kalman filter, may be implemented to integrate GNSS measurements 133, e.g., estimated pseudo-ranges, delta-range and/or Doppler shifts, from GNSS receiver 120, with inertial measurements 143, e.g., one or more of linear acceleration, angular velocity, position, velocity, and/or altitude information, from mechanization equations of IMU 160.
One of ordinary skill in the art at the time of filing would have recognized that applying the known data processing structure of Ohev Zion to the location estimation of Ricci would have yielded predictable results and resulted in an improved system for determining correct vehicle location.
Regarding claim 5, Ricci discloses the limitations of claim 1 and further discloses fusing the received sensor data with signals from a …receiver in the provider client device.
Ricci [0165] The vehicle control system 204 may communicate with a device or a user interface 212, 248.. Further, the symbol 212, 248 can represent a device that is located or associated with the vehicle 104. The device 212, 248 can be a mobile device, including, but not limited to, a mobile telephone, a mobile computer, or other type of computing system or device that is either permanently located in or temporarily associated with, but not necessarily connected to, the vehicle 104. Thus, the vehicle control system 204 can interface with the device 212, 248 and leverage the device's computing capability to provide one or more of the features or functions as described herein; Ricci [0166] The user 216 may thus interact with the vehicle control system 204 through the interface or device 212, 248. Further, the device 212, 248 may include or have access to device data 220 and/or profile data 252. ; Ricci [0167] As an example, the profile data 252 may include one or more user profiles. User profiles may be generated based on data gathered from one or more of vehicle preferences (e.g., seat settings, HVAC settings, dash configurations, and the like), recorded settings, geographic location information (e.g., provided by a satellite positioning system (e.g., GPS), Wi-Fi hotspot, cell tower data, etc.), mobile device information (such as mobile device electronic addresses, Internet browsing history and content, application store selections, user settings and enabled and disabled features, and the like), ….; See also Ricci [0236], [0250], [0662] – [0663], [0069]
Ricci discloses fusing the received sensor data with signals from the provider client device, but does not explicitly disclose signals from a global navigation satellite system (GNSS) receiver, which is disclosed by Ohev Zion.
Ohev Zion [0097] In some demonstrative embodiments, IMU 160 may include any other additional or alternative sensor, e.g., configured to detect movement and/or a change in a position of device 102, for example, a barometer, a compass, a Micro Electro-Mechanical Systems (MEMS) sensor, a speedometer, a motion sensor, a 6 Degree of Freedom (DoF) sensor, a 9-axis MEMS sensor, and/or a location determination mechanism and/or algorithm.
Ohev Zion [0107] In some demonstrative embodiments, a combination (“fusion”) of inertial measurements 143 and GNSS measurements 133, e.g., in a GNSS-IMU navigation system, may be implemented according to one or more methods and/or techniques, e.g., as described below.; See also Ohev Zion [0108] - [0109] In some demonstrative embodiments, the combination of inertial measurements 143 and GNSS measurements 133 may be implemented according to a tightly-coupled integration. For example, one or more Kalman filters, for example, including a centralized Kalman filter, may be implemented to integrate GNSS measurements 133, e.g., estimated pseudo-ranges, delta-range and/or Doppler shifts, from GNSS receiver 120, with inertial measurements 143, e.g., one or more of linear acceleration, angular velocity, position, velocity, and/or altitude information, from mechanization equations of IMU 160.
One of ordinary skill in the art at the time of filing would have recognized that applying the known sensor integrations of Ohev Zion to the location estimation of Ricci would have yielded predictable results and resulted in an improved system for determining correct vehicle location.
Regarding claim 10, Ricci discloses the limitations of claim 1 and further discloses fusing the received sensor data using a … sensor fusion architecture.
Ricci [0236] The vehicle control system 204 may also provide signal processing of one or more sensors, sensor fusion of similar and/or dissimilar sensors, signal smoothing in the case of erroneous “wild point” signals, and/or sensor fault detection. For example, ranging measurements provided by one or more RF sensors may be combined with ranging measurements from one or more IR sensors to determine one fused estimate of vehicle range to an obstacle target. (see also [0665] use of thresholds to identify erroneous data; [0666] disclosing data fusion algorithms known in the art); Ricci [0662] – [0663], [0666] - [0668] Data Fusion 6550 module may employ any fusion algorithms know to those skilled in the art to combine the data. For example, regarding a speed value of a particular vehicle. Data source one (e.g. from a vehicle-mounted speedometer) providing a first measurement of speed may be combined with data source two (e.g. as measured from data derived from cell phone transmissions) by a state estimation algorithm to yield one combined or fused estimate of the speed (a particular “state” value of the vehicle). State estimation algorithms may comprise Kalman filtering.
Ricci discloses the fusion function, but does not explicitly disclose the fusion architecture type as claimed. Ohev Zion discloses a loosely coupled sensor fusion architecture
Ohev Zion [0097] ; Ohev Zion [0107] In some demonstrative embodiments, a combination (“fusion”) of inertial measurements 143 and GNSS measurements 133, e.g., in a GNSS-IMU navigation system, may be implemented according to one or more methods and/or techniques, e.g., as described below.; Ohev Zion [0108] In some demonstrative embodiments, the combination inertial measurements 143 and GNSS measurements 133 may be implemented according to a loosely-coupled integration. For example, positions and velocities derived from GNSS measurements 133 may be merged as updates to position estimation information of IMU 160, for example, derived from inertial measurements 143, e.g., through a navigation Kalman filter.
One of ordinary skill in the art at the time of filing would have recognized that applying the known data processing of Ohev Zion to the location estimation of Ricci would have yielded predictable results and resulted in an improved system for determining correct vehicle location.
Regarding claim 12, Ricci discloses the limitations of claim 11. See also the above rejection of claim 2.
Regarding claim 13, Ricci discloses the limitations of claim 11. See also the above rejection of claim 3.
Regarding claim 15, Ricci discloses the limitations of claim 11. See also the above rejection of claim 5.
Regarding claim 20, Ricci discloses the limitations of claim 11. See also the above rejection of claim 10.
Claim(s) 4, 6, 8, 14, 16 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ricci (US 20160086391) further in view of Farmer (US 10126138).
Regarding claim 4, Ricci discloses the limitations of claim 1 and further discloses generating a … location for a transportation service provided by the vehicle based on the current location.
Ricci [0666] Data cleansing & normalization 6730 module outputs and/or receives data from geolocation mapping module 6540, which provides geolocation data for one or more of the plurality of vehicles. Geolocation mapping module 6540 may provide, among other things, geocoding, rendering (e.g. rendering an image or representation of the location of one or more vehicles relative to a meaningful location such as an address), and routing. Geolocation mapping module 6540 sends and receives data with Data Fusion 6550 module. Geolocation mapping module 6540 may be a commercial off the shelf system and/or be performed by an outside third party.; Ricci [0689] In one embodiment, customer telematics analysis services comprise geofencing, tracking/retrieving, maintenance, administration (check-in/check-out), operations (fuel, usage, damage), fees (parking, toll, tickets), asset management, asset monitoring, analytics, and GPS and other location data to monitor location, performance, and service needs of a fleet's assets. In one embodiment, the customer comprises any fleet operator, fleet leasing operators, organizations with vehicle fleets, rental fleets providers, taxi and on-demand driving services such as uber and lyft, leasing fleet providers, rental truck companies, government fleets, and corporate fleets.
Ricci discloses the use of location for a transportation service, but does not explicitly recite generating a recommended pickup location for a transportation service, which is disclosed more explicitly by Farmer discloses generating a recommended pickup location for a transportation service.
Farmer: (50) (col. 14, ll. 10-30) FIGS. 4A-4B illustrate example interface approaches to display data related to optimizing pickup locations, in accordance with an embodiment of the present techniques. In the example 400 of FIG. 4, an application interface 410 is illustrated, as may be displayed on a computing device associated with a provider and/or requestor….
Farmer: (51) (col. 14, ll. 25-45) In the example 420 of FIG. 4B, an alternate request location 424 has been identified with regard to the request location 402. For example, as described earlier, a threshold distance around the request location 402 may be determined, and a set of alternate request locations evaluated until one (or more, in some embodiments) is found to reduce one of an ETA or ETD, or both, by a particular amount over the original route (as illustrated in FIG. 4A). In this example, the alternate request location 424 is displayed along with a travel path 422 to the alternate request location 424. With this particular alternate request location 424, it can be seen that the provider's route 426 to the alternate request location 424 is more efficient (i.e., shorter, with no turns), and allows for the journey to the destination to proceed immediately down the street 428 after the pickup, without a need for any turns around the block, etc.
Farmer: (52) (col. 14, ll. 40-60) Once the alternate request location 424 is selected, in the example of FIG. 4B, the interface 410 presents the requestor on their device with a dialog box or similar element 428 indicating that a new pickup location (i.e., request location) is available and indicating that traveling 2 minutes to the alternate request location 424 will save 5 minutes in the overall journey, although in various embodiments, the ETA to the requestor may be illustrated, the ETD to the destination, or both. The requestor is then able to confirm 432 or decline 430 the alternate request location 424, which decision will then be sent by the dynamic transportation matching system to the provider (e.g., through modified first transport request information) along with the alternate request location 424.
Farmer (9) (col. 2, ll. 15-25) FIG. 8 illustrates an exemplary flow diagram of a method for using a pickup location score of a request location and alternate request locations to determine a modified pickup location for a request, in accordance with embodiments of the present techniques;
One of ordinary skill in the art at the time of filing would have recognized that applying the known technique of recommendations for a service provider of Farmer to the on-demand driving service of Ricci would have yielded predictable results and resulted in an improved system for facilitating driver-passenger interaction in a on-demand driving service, as “there is a need to improve the identification of interaction locations and improve interactions between providers and requestors for overall travel time determinations, efficient use of system and processor resources, and overall improved experiences between providers and requestors” (Farmer, col. 1, ll. 50-55).
Regarding claim 6, Ricci discloses the limitations of claim 1 and further discloses further comprising generating or updating … of the vehicle location associated with a transportation service based on the current location.
Ricci [0689] In one embodiment, customer telematics analysis services comprise geofencing, tracking/retrieving, maintenance, administration (check-in/check-out), operations (fuel, usage, damage), fees (parking, toll, tickets), asset management, asset monitoring, analytics, and GPS and other location data to monitor location, performance, and service needs of a fleet's assets. In one embodiment, the customer comprises any fleet operator, fleet leasing operators, organizations with vehicle fleets, rental fleets providers, taxi and on-demand driving services such as uber and lyft, leasing fleet providers, rental truck companies, government fleets, and corporate fleets.
Ricci disclose the use of location for a transportation service, but does not explicitly recite generating or updating an estimated time of arrival (ETA) of the vehicle at a pickup transportation service, which is disclosed more explicitly by Farmer.
Farmer (18) col. 3, ll. 20-50, disclosing continues updating of estimated ETA
Farmer Ricci (21) (col. 4, ll. 30-40) In an embodiment, an estimated time of travel (ETT) is determined that indicates an estimated time it would take for the requestor to travel to one or more of the alternate request locations within a threshold distance (e.g., within the particular geographical area) of the original request location, and a determination is made whether the ETA to one of the alternate request locations, taking into account the ETT to the alternate request locations, would be less than the ETA to the original request location.
Farmer: (51) (col. 14, ll. 25-45) In the example 420 of FIG. 4B, an alternate request location 424 has been identified with regard to the request location 402. For example, as described earlier, a threshold distance around the request location 402 may be determined, and a set of alternate request locations evaluated until one (or more, in some embodiments) is found to reduce one of an ETA or ETD, or both, by a particular amount over the original route (as illustrated in FIG. 4A). In this example, the alternate request location 424 is displayed along with a travel path 422 to the alternate request location 424. With this particular alternate request location 424, it can be seen that the provider's route 426 to the alternate request location 424 is more efficient (i.e., shorter, with no turns), and allows for the journey to the destination to proceed immediately down the street 428 after the pickup, without a need for any turns around the block, etc.
Farmer: (52) (col. 14, ll. 40-60) Once the alternate request location 424 is selected, in the example of FIG. 4B, the interface 410 presents the requestor on their device with a dialog box or similar element 428 indicating that a new pickup location (i.e., request location) is available and indicating that traveling 2 minutes to the alternate request location 424 will save 5 minutes in the overall journey, although in various embodiments, the ETA to the requestor may be illustrated, the ETD to the destination, or both. The requestor is then able to confirm 432 or decline 430 the alternate request location 424, which decision will then be sent by the dynamic transportation matching system to the provider (e.g., through modified first transport request information) along with the alternate request location 424.
Farmer (9) (col. 2, ll. 15-25) FIG. 8 illustrates an exemplary flow diagram of a method for using a pickup location score of a request location and alternate request locations to determine a modified pickup location for a request, in accordance with embodiments of the present techniques;
One of ordinary skill in the art at the time of filing would have recognized that applying the known technique of updating ETAs based on current location of a service vehicle, of Farmer, to the on-demand driving service, of Ricci, would have yielded predictable results and resulted in an improved system for facilitating driver-passenger interaction in an on-demand driving service, as “there is a need to improve the identification of interaction locations and improve interactions between providers and requestors for overall travel time determinations, efficient use of system and processor resources, and overall improved experiences between providers and requestors (Farmer, col. 1, ll. 50-55)”
Regarding claim 8, Ricci discloses the limitations of claim 1 and further discloses updating … the current location of the vehicle.
Ricci [0304] The location module 896 can be the controller of the satellite navigation system designed for use in automobiles. The location module 896 can acquire position data, as from the GPS Antenna/receiver 892, to locate the user or vehicle 104 on a road in the unit's map database 8100. Using the road database 8100, the location module 896 can give directions to other locations along roads also in the database 8100. When a GPS signal is not available, the location module 896 may apply dead reckoning to estimate distance data from sensors 242 including one or more of, but not limited to, a speed sensor attached to the drive train of the vehicle 104, a gyroscope, an accelerometer, etc. GPS signal loss and/or multipath can occur due to urban canyons, tunnels, and other obstructions. Additionally or alternatively, the location module 896 may use known locations of Wi-Fi hotspots, cell tower data, etc. to determine the position of the vehicle 104, such as by using time difference of arrival (TDOA) and/or frequency difference of arrival (FDOA) techniques.
Ricci disclose a map and the tracking and updating of vehicle location, but does not explicitly recite updating an electronic map based on vehicle location, which is disclosed more explicitly by Farmer.
Farmer (34) (col. 8, l. 50 – col. 9, l. 5 ) FIGS. 2A-2B illustrate an example of a ride matching system environment where pickup paths to pickup locations are determined, in accordance with an embodiment of the present techniques…;
Farmer (35) (col. 9, ll. 1-15) In the example of FIG. 2B, an alternate request location 226 has been provided to the requestor once the request has been matched to the provider 206, along with a route 224 along which the requestor may walk to get to the alternate request location 226. As illustrated in FIG. 2B, by traveling to the alternate request location 226, the navigation route 222 taken by the provider to the alternate request location is shorter (i.e., no extra turn around the block to the original request location 202 is required) because the requestor has moved to a different curb segment. Similarly, after the provider 206 picks the requestor up at the alternate request location 226, the navigation route 228 to the destination is shorter (i.e., the provider 206 does not have to circle the block).
Farmer (50) (col. 14, ll. 10-30) FIGS. 4A-4B illustrate example interface approaches to display data related to optimizing pickup locations, in accordance with an embodiment of the present techniques. In the example 400 of FIG. 4, an application interface 410 is illustrated, as may be displayed on a computing device associated with a provider and/or requestor. In the example interface 410, a request location 402 is displayed at a particular location within the layout of roads. A representation of a provider 404 (e.g., that has accepted a transport request associated with the request location) is displayed at a location corresponding to the provider's current location, and a route 406 of the provider 404 to the request location is illustrated, along with a route 408 to the request destination (not pictured) that will be taken after the requestor is picked up at the request location 402. As can be seen in FIG. 4A, the provider cannot take a direct route to the destination; instead, the current request location 402 requires the provider 404 to make several turns.
Regarding claim 14, Ricci discloses the limitations of claim 11. See also the above rejection of claim 4.
Regarding claim 16, Ricci discloses the limitations of claim 11. See also the above rejection of claim 6.
Regarding claim 18, Ricci discloses the limitations of claim 11. See also the above rejection of claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Fan et al. (US 9734714), disclosing fine grained location-based services
Lu (US 20180189918), disclosing systems and methods for recommending service locations.
Zhang et al. (US 20180188381), disclosing positioning fusion
Zelenskiy et al. (US 20210181331), disclosing techniques for determining the location of a mobile object
Gordon et al. (US 20200143237), disclosing forms of sensor fusion
Dean et al. (US 20190052637), disclosing integrated mobile vehicle systems.
Haque et al. (US 20190051174 A1), disclosing travel path and location predictions
Bai et al. (US 20180302743), disclosing systems and methods for performing location-based actions
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABBY J FLYNN whose telephone number is (571)272-9855. The examiner can normally be reached Monday - Friday 8:30-5:00.
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, James Trammell can be reached at 571-272-6712. 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.
/ABBY J FLYNN/Examiner, Art Unit 3663
