DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice to Applicant
The following is a Final Office Action for Application Serial Number: 18/213,994, filed on June 26, 2023. In response to Examiner’s Non-Final Rejection dated April 20, 2026, Applicant filed Arguments and Remarks on July 28, 2026. Claims 1-20 and 23 are pending in this application and have been rejected below.
Response to Amendment
Applicant's amendments are acknowledged.
The 35 U.S.C. § 103 rejections are maintained in light of Applicant’s amendments.
Response to Arguments
Regarding the 35 U.S.C. 112 rejection, Applicant states the Specification expressly discloses identifying a vehicle that is not yet available, estimating when that vehicle will become available, and generating and sending a notification once that vehicle has been identified.
For example, paragraph [0076] explains: "if a vehicle will be finishing a trip, the server computing devices may be able to estimate when a vehicle will be coming available within a predetermined expected period of time." Paragraph [0076] further explains that: "such a vehicle, even though it is currently providing services for another user, may be identified as an available vehicle within the predetermined expected period of time into the near future," and that this determination is made by: "taking into consideration the amount of time the vehicle will need to complete its current services and allow the other user to exit safely."
Paragraph [0079] further explains that: "[a] notification may then be generated for the identified one or more users indicating that a vehicle is available for a trip." Paragraph [0081] likewise states: "[o]nce a user and vehicle are identified, the server computing devices can send a notification to the user's device for display to the user."
Read together, paragraphs [0076], [0079], and [0081] describe (1) estimating when a vehicle that is currently providing services "will be coming available," (2) identifying that vehicle, and (3) generating and sending a notification after the user and vehicle have been identified. Thus, the Specification reasonably conveys to a person of ordinary skill in the art that the inventors were in possession of the claimed subject matter. The written description inquiry considers the Specification as a whole, and the Specification need not describe the claimed invention in ipsis verbis.
The Office Action cites disclosures regarding the estimated arrival time of an available vehicle. However, paragraphs [0076], [0079], and [0081] more directly address the claimed timing of when the notification is sent. When the Specification is considered as a whole, it reasonably conveys possession of the claimed subject matter. Accordingly, withdrawal of the rejection under 35 U.S.C. § 112(a) is respectfully requested.
In response, Examiner respectfully disagrees for the following reaches. Examiner notes Applicant’s par. [0075]-[0083] Specification, discusses, in part:
[0075] By combining the locations of vehicles with the locations of users and the users' task metrics, the server computing devices 410 can determine whether there is a vehicle currently located within a predetermined distance (i.e. within 5 minutes or 1 mile) of a user who is likely to need or want to take a ride or rather is associated with a task metric which indicates that the user is likely to want to take a trip in the near future (i.e within the next hour or more or less). Thus, to identify a specific vehicle and user combination, the server computing device may first identify any currently available vehicles or vehicles that are going to become available in the near future. For example, returning to FIGURE 6, vehicle 100A may currently be occupied and traveling to a destination. However, vehicle 100 may be available, or that is not currently dispatched to pick up a user, taking a user to a destination, or otherwise engaged. In that regard, the server computing devices may identify vehicle 100 as currently available.
[0076] In addition, if a vehicle will be finishing a trip, the server computing devices may be able to estimate when a vehicle will be coming available within a predetermined expected period of time. Thus, such a vehicle, even though it is currently providing services for another user, may be identified as an available vehicle within the predetermined expected period of time into the near future, such as 5 minutes or more or less, taking into consideration the amount of time the vehicle will need to complete its current services and allow the other user to exit safely. In this regard, even when stopped to drop off a passenger, a vehicle may not necessarily be available for another minute or more or less. For instance, vehicle 100A may be currently transporting a passenger on a trip, but the server computing devices may identify vehicle 100A as available where the trip is going to end shortly, i.e. within the next 10 minutes or more or less.
[0077] Then, using the location information shared by users, server computing
devices may then identify a set of any users within a predetermined distance (in space or time) of vehicle 100. In that regard, one or both of users 422 and 432 may be within 0.5 miles of the current location of vehicle 100 or 5 minutes traveling time by vehicle 100.
[0078] Of the identified set of users, the server computing devices may then select one or more of those that are associated with task metrics that indicate that these users are likely to accept a trip in response to a notification. For instance, where the user 422 may be a with task metric that indicates that the user frequently visits "Restaurant A" on Friday evenings at 8 pm, the restaurant is less than 30 minutes away via a trip in vehicle 100 (or similar), and it is currently 7:30 pm on a Friday, user 422 may be selected as a user who is likely to accept a trip.
Examiner finds par. 0075-0078 disclose criteria identifying a specific vehicle and user combination, with at least one aspect being the estimating of a vehicles availability as disclosed in par. 0076 and the location and task metrics of the users disclosed in par. 0077-0078. The specification then states:
[0079] A notification may then be generated for the identified one or more users
indicating that a vehicle is available for a trip. For instance, based on the identification of vehicle 100 as available and user 422 selected as likely to accept a trip, a notification may be generated to indicate to user 422 that a vehicle is available.
[0080] However, prior to sending a notification, the server computing devices can first send an instruction to dispatch the identified available vehicle to the location of the user or to continue to wait at its current location, for instance, if the vehicle is parked at a location proximate (i.e. within a few hundred feet or more or less) of the user's current location. In this way, the notification is provided only when the vehicle is on its way to the location of the user or has already reached the location of the user. For instance, once the server computing devices has identified a user and a vehicle, without receiving a specific request for the vehicle, the vehicle may show up at or near a particular user's current location. In this way, the notification itself can inform the user that a vehicle is on the way or at the location of the user.
[0081] Once a user and vehicle are identified, the server computing devices can send a notification to the user's device for display to the user. As noted above, the server computing devices computing devices may generate a notification to be provided to the user to indicate that a vehicle is currently available for a trip. After dispatching the vehicle or instructing the vehicle to wait at its current location, the notification may be sent to the user. Once received by the user's client computing device, an audible tone or tactile indication may be provide to indicate that a notification has been received. The user may then select to view or hear the notification. In this regard, the notification may be visual notification which simply displays on the display of the user's client computing device as shown in FIGURES 7A-7D and/or an audible notification that speaks the information. For example, FIGURE 7A depicts a notification 710 indicating to user 422 that a vehicle is currently available. In addition, the notification may or may not include information about how far the vehicle currently is from the user or an estimate time of arrival as shown in notification 720 of FIGURE 7B or whether the vehicle is already parked nearby waiting for the user as in notification 730 of FIGURE 7C. As noted above, the server computing devices 410 can send the notification and any additional information to the identified user's client device via network 460.
[0082] In addition to indicating that the vehicle is available to pick up the user for a ride, the notification may also make a suggestion about a destination. This suggestion may be generated based on the user's pattern of ride behavior or any task metric or metrics used to identify the user. Returning to the example above, once the vehicle his on its way to the location of the user (or has reached the location of the user), the user may receive a notification that "suggests" a trip to a restaurant based on the user 422's history of going to that restaurant at Friday evenings at 8 pm as shown by notification 740 suggesting a trip to "Restaurant A" shown in of FIGURE 7D.
Next, Examiner finds the criteria when notifications are generated is as follows:
Based on the identification of vehicle as available and user selected as likely to accept a trip.
To indicate to user that a vehicle is available.
Only when the vehicle is on its way to the location of the user or has already reached the location of the user.
To inform the user that a vehicle is on the way or at the location of the user.
To indicate that a vehicle is currently available for a trip. After dispatching the vehicle or instructing the vehicle to wait at its current location, the notification may be sent to the user.
To indicate that the vehicle is available to pick up the user for a ride, and may also make a suggestion about a destination.
More importantly, par. 0083-0084 explicitly disclosed the timing of notifications as follows:
[0083] The timing of the notification may be based on the location of the user, how long it will take to reach the suggested location (for instance due to current or predicted traffic conditions), any date and/or time of any task metric used to identify the user, how long it will take an available identified vehicle to reach the user, etc. If the current location of the user is approximately 30 minutes from the restaurant (via being transported by the vehicle) and an available identified vehicle is only 2 minutes from picking up the user, the server computing devices may send the notification at least 32 minutes before 8 pm on a Friday evening suggesting that the user take a trip to the restaurant.
[0084] In addition, the server computing devices may even provide the user's client device with instructions to provide and/or display the notification at that or some other particular time. For instance, where the vehicle is more than 5 minutes from the location of the user, the server computing device may wait to send the notification to the user's client device until the vehicle is closer to the location of the user or send the notification with instructions to delay displaying or otherwise providing the notification to the user. In another example, where a task metric indicates that a user travels to his or her workplace at 8:30 am, but at 8:00 am the server computing devices estimates that it will take a vehicle 45 minutes to reach the work place at 8:30 due to traffic conditions, the server computing devices may send a notification that suggests a trip the user's workplace immediately, rather than waiting closer to 8:30 to prevent the user from being late to the user's workplace.
Examiner notes Applicant’s Specification explicitly states the timing of the notification may be based on:
How long it will take to reach the suggested location (for instance due to current or predicted traffic conditions).
Any date and/or time of any task metric used to identify the user.
How long it will take an available identified vehicle to reach the user.
As an example, if the current location of the user is approximately 30 minutes from the restaurant (via being transported by the vehicle) and an available identified vehicle is only 2 minutes from picking up the user, the server computing devices may send the notification at least 32 minutes before 8 pm on a Friday evening suggesting that the user take a trip to the restaurant.
User instructions to provide and/or display the notification at that or some other particular time.
As an example, where the vehicle is more than 5 minutes from the location of the user, the server computing device may wait to send the notification to the user's client device until the vehicle is closer to the location of the user or send the notification with instructions to delay displaying or otherwise providing the notification to the user. In another example, where a task metric indicates that a user travels to his or her workplace at 8:30 am, but at 8:00 am the server computing devices estimates that it will take a vehicle 45 minutes to reach the work place at 8:30 due to traffic conditions, the server computing devices may send a notification that suggests a trip the user's workplace immediately, rather than waiting closer to 8:30 to prevent the user from being late to the user's workplace.
Examiner finds Applicant’s arguments are not persuasive as they suggest using the timing criteria for determining vehicle availability to identify vehicle-user pairs should also be used in determining the timing of a notification. Examiner maintains there is no actual description given and the specification fails to provide support for the timing of sending a notification being based on when the identified vehicle will become available.
Regarding the 35 U.S.C. 103 rejection, Applicant states these rejections, insofar as they may pertain to the presently pending claims, are respectfully traversed based, at least in part, on the following remarks. Independent claim 1 recites:
sending, by the one or more processors, to each respective client computing device of the one or more potential passengers, a notification including an offer for the identified at least one vehicle to take the one or more users on a trip to a destination, wherein a time when the notification is sent is based at least partially on a time when the identified at least one vehicle will become available.
The Office Action relies on Marco for this limitation, citing paragraphs [0072]-[0073] and [0079]. (Office Action, pp. 6-7.) Applicant respectfully submits that the cited portions of Marco do not teach or suggest the claimed relationship. (see pg. 9-10, Applicant Remarks).
In response Examiner respectfully disagrees. Examiner finds Applicant's amendments lack written description support in order to show the Applicant was in possession of the invention at the time the invention was filed. Specifically, Examiner finds the specification states specific criteria of timing notifications (see par. 0028 and 0083), however the specification fails to sufficiently support the wherein a time when the notification is sent is based at least partially on a time when the identified at least one vehicle will become available limitation as presented in the pending claim. For at least these reasons, Examiner finds, given the broadest reasonable interpretation, the prior art of record is sufficient in teaching the current claim language as presented. For at least these reasons, claims 1-20 and 23 remains rejected under 35 U.S.C. § 103 as being unpatentable over the prior art of record.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 and 23 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 13 and 23 recites “wherein a time when the notification is sent is based at least partially on a time when the identified at least one vehicle will become available”. The specification discloses the timing of the notification may be based on various data, including how long it will take an available identified vehicle to reach the user, etc. See at least Paragraph [0028]), which states “The timing of the notification may be based on the location of the user, how long it will take to reach the suggested location, any date and/or time of any task metric used to identify the user, how long it will take an available identified vehicle to reach the user, etc. In addition, the server computing devices may even provide the user's client device with instructions to provide and/or display the notification at that or some other particular time” and Paragraph [0083], which states “The timing of the notification may be based on the location of the user, how long it will take to reach the suggested location (for instance due to current or predicted traffic conditions), any date and/or time of any task metric used to identify the user, how long it will take an available identified vehicle to reach the user, etc. If the current location of the user is approximately 30 minutes from the restaurant (via being transported by the vehicle) and an available identified vehicle is only 2 minutes from picking up the user, the server computing devices may send the notification at least 32 minutes before 8 pm on a Friday evening suggesting that the user take a trip to the restaurant”. However there is no actual description given and the specification fails to provide support for the timing of sending a notification being based on when the identified vehicle will become available. The specification does not provide disclosure in sufficient detail to demonstrate to one of ordinary skill in the art that the claimed invention achieves such a function. For the purpose of examination, Examiner interprets the limitation to be “wherein a time when the notification is sent is based at least partially on how long it will take an available identified vehicle to reach the user”.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1-6, 9-18 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Marco et al., U.S. Publication No. 2017/0186126 [hereinafter Marco] and further in view of Crady et al., U.S. Publication No. 2006/0217885 [hereinafter Crady].
Referring to Claim 1, Marco teaches:
A method of reducing downtime for vehicles of a fleet of vehicles between trips, the method comprising:
identifying, by the one or more processors, one or more potential passenger, each of the one or more potential passenger being associated with a respective client computing device (Marco, [0044]), “information obtained by the device assistant logic 230 may be used to predict whether the passenger will submit a transportation request to the transportation service”; (Marco, [0070]), “backend server 302 receives device activity information from various passenger computing devices 104 and determines whether to classify the corresponding passengers as prospective passengers for a duration of time…”; (Marco, [0045]; [0049]; [0058]; [0079]);
sending, by the one or more processors, to each respective client computing device of the one or more potential passengers, a notification including an offer for the identified at least one vehicle to take the one or more users on a trip to a destination, wherein a time when the notification is sent is based at least partially on a time when the identified at least one vehicle will become available (Marco, [0079]), “in response to determining that a passenger is a prospective passenger based on the passenger's activity, a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104…The message may include any suitable indication to encourage or assist the passenger to submit a transportation request. For example, the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger, a discounted fare offer, a query as to whether the passenger desires a ride, or other suitable information… the message may be sent immediately after a determination that the passenger is a prospective passenger, in response to a driver accepting a request to drive towards a location based on the passenger's location, after a driver has already begun driving towards the location based on the passenger's location, while a driver is waiting at the location based on the passenger's location, or at any other suitable time”; (Marco, [0072]-[0073]), “if the activity information indicates that the passenger has a flight scheduled in two hours from an airport 30 minutes away and the stored device activity information indicates the customer has a propensity to arrive at an airport one hour before departure time, the backend server 302 may calculate that the passenger is most likely to generate a transportation request in 30 minutes… the most likely time and/or the duration may be selected based on the estimated travel time to a probable destination location determined based on the device activity information. For example, in the scenario described above, it may be determined that a passenger likes to arrive at the airport one hour prior to takeoff. Accordingly, the most likely time might be calculated by subtracting the estimated travel time from the passenger's location to the airport… from the time at which the passenger is estimated to want to arrive. Additionally, in some embodiments, additional time may be subtracted to account for an expected delay between the generation of the transportation request and the arrival of the driver”; (Marco, [0022]; [0061]); and
receiving, by the one or more processors from at least one of the respective client computing devices, a response to the notification indicating that at least one of the one or more potential passengers accepted the offer (Marco, [0079]), “the message may include reply options that allow the passenger to submit a transportation request”; (Marco, [0083]), “it is determined whether a transportation request has been received from the subscriber… If a transportation request is received from the subscriber, then the driver is navigated to the subscriber's location”; and
sending, by the one or more processors, dispatching instructions to the identified at least one vehicle to cause the identified at least one vehicle, while operating in an autonomous driving mode, to maneuver to one or more pickup locations after becoming available to pick up the at least one of the one or more potential passengers who accepted the offer (Marco, [0079]), “… a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104… The message may include any suitable indication to encourage or assist the passenger to submit a transportation request… the message may include reply options that allow the passenger to submit a transportation request”; (Marco, [0083]), “it is determined whether a transportation request has been received from the subscriber… If a transportation request is received from the subscriber, then the driver is navigated to the subscriber's location”; (Marco, [0012]), “a driver computing device 108 may be integrated within and/or communicate with a self-driven vehicle (e.g., a vehicle that has the capability of driving without physical steering guidance from a human being) and may influence the movement of the vehicle by providing route information (e.g., passenger pick-up and destination locations driver destination locations, navigational directions, etc.) to the self-driven vehicle. Accordingly, as used herein “driver” may refer to a human being that may physically drive or otherwise control movement of a vehicle or to the vehicle itself (e.g., in the case of a self-driven vehicle) or component thereof (e.g., computing device application 108 or logic thereof)”.
Marco teaches a backend server may access driver availability data to determine one or more drivers that would be suitable to fulfill the request from the passenger (see par. 0066), the driver availability data may include an identification of a driver and any suitable associated information, such as… whether the driver is currently transporting a passenger, a destination location of a current trip of the driver, an estimate of how long it will be before the driver finishes his current trip, whether the driver has opted for automatic acceptance of transportation requests, or other suitable information (see par. 0061), but Marco does not explicitly teach:
identifying, by one or more processors of a server, at least one vehicle of the fleet of vehicles that is currently providing services and will become available within a predetermined period of time.
However Crady teaches:
identifying, by one or more processors of a server, at least one vehicle of the fleet of vehicles that is currently providing services and will become available within a predetermined period of time (Crady, [0016]), “A fleet management system 110 receives real time or otherwise current location information from a number of service vehicles 112 in one or more fleets of vehicles, for example a fleet of vehicles for hire (e.g., taxis 112c, limousines 112b, and the like), a fleet of delivery vehicles 112a, or a fleet of business service vehicles… The location information is usually augmented by information identifying the vehicle (e.g., a vehicle and/or fleet ID), the data source (e.g., a source ID identifying the fleet management system 110), and vehicle status (e.g., availability, job status, time to next availability, time to next delivery, etc.). Each fleet management system 110 can report the vehicle data for one or more vehicles at a time”; (Crady, [0010]; [0059]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the driver availability in Marco to include the vehicle limitation as taught by Crady. The motivation for doing this would have been to improve the method of pairing drivers and passengers in Marco (see par. 0020) to efficiently include the results of tracking and management of service vehicles (see Crady par. 0002).
Referring to Claim 2, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the dispatching instructions are sent in order to reduce the downtime for the identified at least one vehicle between trips (Marco, [0048]), “Driver application logic 220 may also provide navigational data to the driver to allow the driver to travel to the pickup location of the transportation request received from the passenger so that the driver can fulfill the transportation request”. Examiner notes “… in order to reduce the downtime for the identified at least one vehicle between trips” has not been given patentable weight because it merely recites intended use of the system. In Hoffer v. Microsoft Corp., 405 F.3d 1326, 1329, 74 USPQ2d 1481, 1483 (Fed. Cir. 2005), the court held that when a "‘whereby’ clause states a condition that is material to patentability, it cannot be ignored in order to change the substance of the invention." Id. However, the court noted that a "‘whereby clause in a method claim is not given weight when it simply expresses the intended result of a process step positively recited.’" Id. (quoting Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)). See MPEP 2111.04(I).
Referring to Claim 3, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein identifying the one or more potential passengers is based on whether the one or more potential passengers are located within a predetermined distance from the identified at least one vehicle (Marco, [0079]), “In response to determining that a passenger is a prospective passenger based on the passenger's activity, a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104… The message may include any suitable indication to encourage or assist the passenger to submit a transportation request. For example, the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger”; (Marco, [0074]-[0075]).
Referring to Claim 4, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein identifying the one or more potential passengers is based on whether any potential passengers are associated with a task metric corresponding to a potential passenger's ride history (Marco, [0063]), “historical request data 326 may include information indicating whether particular requests were received from passengers who had been identified as prospective passengers based on device activity of the passengers”; (Marco, [0058]), “Passenger device activity data 317 may comprise activity information received from passenger computing devices… such as… calendar appointments… and/or information derived therefrom. Such activity information may include… flight reservations, train reservations, or other transportation reservations made or used by the passenger; calendar appointments or other written communications (e.g., emails, text messages, instant messages) specifying travel or meetings requiring travel by the passenger… passenger device activity data 317 may include statistics indicating how likely one or more particular types of activity data are to result in the generation of a transportation request by the passenger. As another example, passenger device activity data 317 may include statistics indicating when the user is most likely to generate a transportation request in connection with one or more particular activities. In some embodiments, passenger device activity data 317 may include a series of likelihoods that the passenger will generate a request as a function of time (e.g., around a time specified by the activity data, such as a flight time or a commute start time)”; (Marco, [0071]).
Referring to Claim 5, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification indicates an estimated time of arrival of the identified at least one vehicle at a current location of a respective client computing device (Marco, [0016]), “the application may notify the user of the selected driver and provide real-time updates of the driver's location (e.g., with respect to the passenger's location) and estimated pick-up time…”; (Marco, [0079]), “the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger”.
Referring to Claim 6, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
further comprising:
receiving, by the one or more processors, location information identifying current locations of each of the respective client computing devices (Marco, [0074]-[0075]), “Backend server 302 may direct a driver to drive to a location based on the location of one or more prospective passengers… the location may be based on each of multiple prospective passengers' locations. For example, the location may be equidistant from the locations of the prospective passengers or the location may be weighted towards prospective passengers that have a higher likelihood of generating a transportation request. In various embodiments, backend server 302 may select a group of prospective passengers that are located near each other from a larger set of prospective passengers, and determine a location to which the driver should go based on the locations of the group of prospective passengers”.
Referring to Claim 9, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
further comprising:
prior to sending the notification to the respective client computing devices of the one or more potential passengers, determining, by the one or more processors, whether to dispatch the identified at least one vehicle or allow the identified at least one vehicle to wait (Marco, [0047]-[0049]), “driver application logic 220 may receive a request from the backend system 116 for the driver to drive towards one or more prospective passengers in anticipation of the backend system 116 receiving a transportation request from a passenger of the one or more prospective passengers (wherein the prospective passengers are selected based on activity information received from their respective computing devices)… Driver application logic 220 may also provide navigational data to the driver to allow the driver to travel towards the one or more prospective passengers to a location specified by the backend system 116…While the driver is en route to the location specified by the backend system 116 or after the driver has arrived and is waiting at the location, the backend system 116 may receive a transportation request from one of the prospective passengers or another passenger near the location of the driver and send the request to the driver application logic 220 which may present the request to the driver… Driver application logic 220 may also provide navigational data to the driver to allow the driver to travel to the pickup location of the transportation request received from the passenger so that the driver can fulfill the transportation request…”; (Marco, [0022]; [0066]; [0012]; [0083]).
Referring to Claim 10, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification indicates that the identified at least one vehicle is currently maneuvering to the one or more pickup locations, or when the identified at least one vehicle will arrive at the one or more pickup locations (Marco, [0067]), “the backend server 302 notifies the passenger that a driver has accepted his request and provides any suitable information associated with the driver (e.g., driver's current location, model and color of vehicle, estimated time of arrival, etc.) to the passenger”.
Referring to Claim 11, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification indicates that the identified at least one vehicle is waiting at one of the one or more pickup locations (Marco, [0079]), “… a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104… the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger… the message may be sent… while a driver is waiting at the location based on the passenger's location; (Marco, [0012]).
Referring to Claim 12, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification provides a first option to accept the offer and a second option to decline the offer (Marco, [0079]), “the message may include reply options that allow the passenger to submit a transportation request… or indicate that the passenger does not desire a transportation request”.
Referring to Claim 13, Marco teaches:
A server computing device for reducing downtime for vehicles of a fleet of vehicles between trips, the server computing device comprising:
a memory configured to store data and instructions (Marco, [0024]; [0031]);
one or more processors configured to: access the data and instructions stored in the memory (Marco, [0031]);
Claim 13 disclose substantially the same subject matter as Claim 1, and is rejected using the same rationale as previously set forth.
Claim 14 disclose substantially the same subject matter as Claim 2, and is rejected using the same rationale as previously set forth.
Claim 15 disclose substantially the same subject matter as Claim 3, and is rejected using the same rationale as previously set forth.
Claim 16 disclose substantially the same subject matter as Claim 4, and is rejected using the same rationale as previously set forth.
Claim 17 disclose substantially the same subject matter as Claim 5, and is rejected using the same rationale as previously set forth.
Claim 18 disclose substantially the same subject matter as Claim 6, and is rejected using the same rationale as previously set forth.
Referring to Claim 23, Marco teaches:
A non-transitory computer-readable medium storing instructions, which when executed by one or more processors, cause the one or more processors to (Marco, [0031]);
Claim 23 disclose substantially the same subject matter as Claim 1, and is rejected using the same rationale as previously set forth.
Claims 7, 8, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Marco et al., U.S. Publication No. 2017/0186126 [hereinafter Marco], in view of Crady et al., U.S. Publication No. 2006/0217885 [hereinafter Crady], and further in view of Boskovic, U.S. Publication No. 2012/0290652 [hereinafter Boskovic].
Referring to Claim 7, Marco in view of Crady teaches the method of claim 1. Marco teaches sending messages to prospective passengers that may include suitable indications to encourage or assist the passenger to submit a transportation request (see par. 0079), but Marco does not explicitly teach:
wherein the notification indicates how many seats in the identified at least one vehicle are available for use for the trip to the destination.
However Boskovic teaches:
wherein the notification indicates how many seats in the identified at least one vehicle are available for use for the trip to the destination (Boskovic, [0090]), “offer may remain therein preferably with indication of free passenger slots. In connection with each ride offer, the service may be indeed configured to indicate the available person and optionally pet slots provided that the ride provider has indicated such information in the first place or it could have been deduced based on the available data (e.g. with motorcycle, typically only one slot for passengers is available and with a small van, there could only be two passenger seats). Otherwise, it may be presumed by the service that at least one free slot is available per each ride offer input”; (Boskovic, [0092]-[0093]), “preferably at least of departure and/or destination locations, may be provided to the concerned users. Each user may preferably obtain useful information such as schedule and/or map data about his/her personal overall journey to his/her terminal device such as a portable computer, a smartphone or a in-vehicle navigation, computing and/or communications system… the service may be configured to determine feasible transport sharing scenarios for the journeys of the users and output indications thereof to the terminals 704, 706. Real-time monitoring may be applied and up-to-date information relevant to the journeys be transmitted even after the departure time of the journeys”; (Boskovic, [0024]), “inform the associated user(s) and/or update or at least suggest update to the ride scenario or ride plan. E-mail, text or multimedia messages may be applied for sending the information among other options. Monitoring may include data retrieval via the data input entity and optionally processing thereof for determining the status of the tracked conditions”; (Boskovic, [0088]), “ride planning by the service with both public transportation and transport sharing aspects in accordance with an embodiment of the present invention. A journey of a service user includes the location of departure 602 and destination 614”; (Boskovic, [0097]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified messages in Marco to include the sending limitation as taught by Boskovic. The motivation for doing this would have been to improve the method of pairing of passengers and drivers in Marco (see par. 0002) to efficiently include the results of managing transport sharing (see Boskovic par. 0009).
Referring to Claim 8, Marco in view of Crady teaches the method of claim 7. Marco teaches sending messages to prospective passengers that include reply options that allow the passenger to submit a transportation request or indicate that the passenger does not desire a transportation request (see par. 0079), but Marco does not explicitly teach:
wherein the response to the notification indicates for which seats the offer is accepted.
However Boskovic teaches:
wherein the response to the notification indicates for which seats the offer is accepted (Boskovic, [0120]), “the concerned user(s) may be provided with an opportunity, such as a confirmation request, to accept the scenario 1314 or reject it”.
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the reply options in Marco to include the receiving limitation as taught by Boskovic. The motivation for doing this would have been to improve the method of pairing of passengers and drivers in Marco (see par. 0002) to efficiently include the results of managing transport sharing (see Boskovic par. 0009).
Claim 19 disclose substantially the same subject matter as Claim 7, and is rejected using the same rationale as previously set forth.
Claim 20 disclose substantially the same subject matter as Claim 8, and is rejected using the same rationale as previously set forth.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sweeney et al. (US 20150161564 A1) – In response to selecting a driver, the dispatch can transmit an invitation message to a corresponding driver device of the selected driver (e.g., using the driver ID) via the driver device interface. The invitation message can include information about the requesting user, the pickup location of the user, and provide selectable features to enable the driver to accept the transport service or reject/decline the transport service. For example, while a driver is already driving another customer to a respective destination, the driver can receive an invitation message that the driver can accept even before dropping off the other customer. If the driver declines the transport service, the dispatch receives the rejection and the driver select selects another driver for the requesting user. In one example, the driver select can continue to select a driver each time a rejection is received until there are no more capable drivers available. When no drivers are available, the dispatch can notify the request manager of an error or that no drivers are available so that the request manager can provide a status message to the client device of the requesting user to notify that user of the failure to arrange a transport.
THIS ACTION IS MADE FINAL. 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 Crystol Stewart whose telephone number is (571)272-1691. The examiner can normally be reached 9:00am-5: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, Patty Munson can be reached on (571)270-5396. 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.
/CRYSTOL STEWART/Primary Examiner, Art Unit 3624
Prosecution Insights