DETAILED ACTION
Notice to Applicant
The following is a NON-FINAL Office action upon examination of application number 18/989,706 filed on 12/20/2024. Claims 1-20 are pending in the application and have been examined on the merits discussed below.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The preliminary amendment filed on 06/05/2025 has been entered. In accordance with Applicant’s amendment, claim 1 is amended and claims 2-20 are newly presented. Claims 1-20 are currently pending.
Priority
Application 18/989,706 filed 12/20/2024 is a Continuation of Application 16/894,432, filed 06/05/2020.
Claim Rejections - 35 USC § 112
5. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
6. Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
7. Claim 1 recites “analyzing one or more current dispatch conditions affecting dispatch of one or more transportation provider devices to the computing device.” The term “the computing device,” lacks antecedent basis. While the claim recites “a requestor computing device”, no “computing device” is previously introduced in the claim. It is not clear whether “the computing device” refers to the “requestor computing device” or to a different computing device, therefore rendering the claim indefinite. Independent claims 15 and 20 recite similar limitations as those discussed above and are therefore found to be indefinite for the same reasons as claim 1. Appropriate correction is required.
8. Claim 6 recite “the separate set of ridesharing constraints,” which lacks antecedent basis. While the claim recites “a separate set of tighter ridesharing constraints,” the claim does not introduce “a separate set of ridesharing constraints”, therefore rendering the claim indefinite. Additionally, the claim “tighter” is indefinite because it is a relative term that lack objective boundaries. The specification and prior claims do not provide any specific criteria, quantitative limits, or objective measure for determining when a ridesharing constraint is considered “tighter” than another constraint. Therefore, claim 6 is rejected as being indefinite. Appropriate correction is required.
9. Claim 7 recites “wherein the ephemeral ride mode is offered only if the shared ride constraints are determined…” The term “the shared ride constraints” lacks antecedent basis because claim 1 recites “one or more ridesharing constraints.” It is unclear whether “the shared ride constraint” refer to all, some, or any of the constraints of claim 1, therefore rendering the claim indefinite. Appropriate correction is required.
10. Claims 10 and 18 recite the term “the computing device”, which lacks antecedent basis. While claims 1/15 recite “a requestor computing device”, no “computing device” is previously introduced, therefore rendering the claims indefinite. Appropriate correction is required.
11. Claim 11 recites “that the shared ride constraints no longer apply…” The term “the shared ride constraints” lacks antecedent basis because claim 1 recites “one or more ridesharing constraints.” It is unclear whether “the shared ride constraint” refer to all, some, or any of the constraints of claim 1, therefore rendering the claim indefinite. Appropriate correction is required.
All claims dependent from above rejected claims are also rejected due to dependency.
Claim Rejections - 35 USC § 101
12. 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.
13. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claims are directed to an abstract idea without significantly more.
14. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The eligibility analysis in support of these findings is provided below, in accordance with MPEP 2106.
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is first noted that the system (claims 1-14), method (claims 15-19), and non-transitory computer-readable medium (claim 20) are directed to at least one potentially eligible category of subject matter (i.e., machine, process, and article of manufacture, respectively). Thus, Step 1 of the Subject Matter Eligibility test for claims 1-20 is satisfied.
With respect to Step 2A Prong One, it is next noted that the claims recite an abstract idea that falls under the “Certain methods of organizing human activity” and “Mental Processes” abstract idea groupings set forth in MPEP 2106 since the claims set forth steps for managing commercial interactions (e.g., ride-sharing transactions) and managing personal behavior or relationships or interactions (e.g., social activities, following rules or instructions) and thus fall under “Certain Methods of Organizing Human Activity,” and steps that can be performed in the human mind (including observation, evaluation, judgment, opinion), including the analyzing, predicting, and determining steps, and therefore fall under the “Mental Processes” abstract idea grouping. With respect to independent claim 1, the limitations reciting the abstract idea are indicated in bold below: request a shared ride, the shared ride including one or more ridesharing constraints that are to be maintained throughout the shared ride; analyzing one or more current dispatch conditions affecting dispatch of one or more transportation provider devices to the computing device, wherein each transportation provider device includes a global positioning system (GPS) radio configured to provide dynamically updated, real time location information for each transportation provider device; according to the analysis, predicting a likelihood that the requestor will pay a higher price for less uncertainty in overall ride time based on the current dispatch conditions; determining, based on the predicted likelihood, that the current dispatch conditions allow for an ephemeral ride mode to be offered on the transportation application; and instructing the computing device to at least temporarily present the ephemeral ride mode within a user interface of the transportation application as a selectable option based on the determination.
Considered together, these steps set forth an abstract idea of managing ridesharing interactions involving a transportation provider and a transportation requestor [See Specification at paragraph 0024 describing “an example scenario 100 in which a transportation requestor 102 requests a traditional shared ride to a destination... In this example, a transportation management system may match transportation requestor 102 with a transportation provider 104 at time A.”], which falls under the under the “Certain methods of organizing human activity,” and also recite an abstract idea falling under the “Mental Processes” abstract idea grouping set forth in MPEP 2106. Independent claims 15 and 20 recite similar limitations as those discussed above and are therefore found to recite the same or substantially the same abstract idea as claim 1.
With respect to Step 2A Prong Two, the judicial exception is not integrated into a practical application. With respect to the independent claims, the additional elements are:
With respect to Step 2A Prong Two, the judicial exception is not integrated into a practical application. The additional elements recited are: a non-transitory memory, one or more hardware processors configured to execute instructions, a transportation application, a requestor computing device, one or more transportation provider devices, the computing device, each transportation provider device, a global positioning system (GPS) radio, and a user interface of the transportation application (claim 1), a transportation application, a requestor computing device, one or more transportation provider devices, the computing device, each transportation provider device, global positioning system (GPS) radio, and a user interface of the transportation application (claim 15), computer-readable instructions, at least one processor of a computer, a transportation application, a requestor computing device, one or more transportation provider devices, the computing device, each transportation provider device, a global positioning system (GPS) radio, and a user interface of the transportation application (claim 20). These additional elements have been evaluated, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or computer-executable instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment. See MPEP 2106.05(f) and 2106.05(h). Even if the steps for receiving an indication that a transportation application has been initialized on a requestor computing device to request a shared ride and presenting the ephemeral ride mode are not deemed part of the abstract idea, these steps are at most directed to insignificant extra-solution activity, which is not sufficient to amount to a practical application. See MPEP 2106.05(g). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional elements recited are: a non-transitory memory, one or more hardware processors configured to execute instructions, a transportation application, a requestor computing device, one or more transportation provider devices, the computing device, each transportation provider device, a global positioning system (GPS) radio, and a user interface of the transportation application (claim 1), a transportation application, a requestor computing device, one or more transportation provider devices, the computing device, each transportation provider device, global positioning system (GPS) radio, and a user interface of the transportation application (claim 15), computer-readable instructions, at least one processor of a computer, a transportation application, a requestor computing device, one or more transportation provider devices, the computing device, each transportation provider device, a global positioning system (GPS) radio, and a user interface of the transportation application (claim 20). These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment and does not amount to significantly more than the abstract idea itself. Notably, Applicant’s Specification suggests that virtually any type of computing device under the sun can be used to implement the claimed invention (Specification at paragraph [0090]). Accordingly, the generic computer involvement in performing the claim steps merely serves to generally link the use of the judicial exception to a particular technological environment, which does not add significantly more to the claim. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976.).
Even if the steps for transmitting and presenting are not deemed part of the abstract idea, this step is at most directed to insignificant extra-solution activity, which has been recognized as well-understood, routine, and conventional, and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d) - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrate the abstract idea into a practical application. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent claims 2-14 and 16-19 recite the same abstract idea as recited in the independent claims, and when evaluated under Step 2A Prong One are found to merely recite details that serve to narrow the same abstract idea recited in the independent claims accompanied by the same generic computing elements or software as those addressed above in the discussion of the independent claims, which is not sufficient to amount to a practical application or add significantly more, or other additional elements that fail to amount to a practical application or add significantly more, as noted above. In particular, dependent claims 2-14 and 16-19 recite “wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for fewer detours or shorter detours,” “wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for a shorter pickup time,” “wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for a shorter overall estimated time of arrival (ETA),” “provides dynamically updated, real time location information,” “wherein a separate set of tighter ridesharing constraints is implemented when determining whether to surface the ephemeral ride mode, the separate set of ridesharing constraints including additional restrictions that are only applied in the ephemeral ride mode,” “wherein the ephemeral ride mode is offered only if the shared ride constraints are determined to be enforceable throughout the duration of the shared ride and only if the separate set of ridesharing constraints with the additional restrictions has been met,” “wherein the ephemeral ride mode allows the requestor computing device to share a ride with at least one other requestor computing device based on one or more requestor device-specific constraints,” “wherein the device-specific constraints comprise at least one of: a maximum potential detour time; a maximum potential detour distance; a maximum allowable percentage increase in length of detour time; or a maximum allowable percentage increase in length of detour distance,” “wherein the ephemeral ride mode provides an indication of an estimated time to a selected destination that is customized based on the device-specific constraints,” “dynamically remove the ephemeral ride mode upon determining, based on the real time location of the requestor computing device or the real time location of the transportation provider device, that the shared ride constraints no longer apply, such that the ephemeral ride mode is automatically removed,” “wherein the ephemeral ride mode is presented according to a schedule that is specific to the requestor,” “wherein the schedule is determined automatically based on prior ride-history data associated with the requestor,” “wherein the ephemeral ride mode is presented according to the schedule even if the current dispatch conditions are unmet,” “wherein the current dispatch conditions comprise at least one of: an indication of available transportation provider; an indication of profitability of a shared ride provided through the ephemeral ride mode; a measure of efficiency; a measure of expected conversion rate; a determination that the requestor is currently located in a specified city; a determination that the requestor is currently located on a specified route; or identification of a transportation requestor associated with the requestor computing device,” “wherein the ephemeral ride mode is presented dynamically upon the occurrence of at least one of the current dispatch conditions,” “wherein the step of analyzing the one or more current dispatch conditions affecting the dispatch of the one or more transportation provider based on the requestor includes calculating a match efficiency rating that indicates a determined value of matching the computing device to at least one of the transportation provider,” “further comprising: determining that the calculated match efficiency rating meets a minimum threshold value; and matching the requestor to at least one of the transportation provider,” however these limitations cover organizing human activity since they flow directly from the transportation request management involving human interaction, which encompasses activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions), which is part of the same abstract idea as addressed in the independent claims that falls within the “Certain Methods of Organizing Human Activity” abstract idea grouping and which are details directly in support of the commercial ride-sharing transaction. Accordingly, these steps are part of the same abstract idea(s) set forth in the independent claims. The additional elements recited in the dependent claims include: wherein the requestor computing device includes a GPS radio (claim 5), other requestor computing device (claim 8), a transportation management system (claim 16). However, these elements are recited at a high level of generality and fail to yield any discernible improvement to the computer or to any technology, nor set forth any additional function or result that provided meaningful limitation beyond linking the abstract idea to a particular technological environment (i.e., automated/computing environment), and thus fail to integrate the abstract idea into a practical application. When evaluated under Step 2A Prong Two and Step 2B, these additional elements do not amount to a practical application or significantly more since they merely require generic computing devices (or computer-implemented instructions/code) which as noted in the discussion of the independent claims above is not enough to render the claims as eligible.
The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself.
For more information, see MPEP 2106.
Claim Rejections - 35 USC § 103
15. 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 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.
16. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
17. 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.
18. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
19. Claims 1, 3-5, 8-10, 12-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gururajan, Patent No.: US 10,248,913 B1, [hereinafter Gururajan], in view of Klein et al., Pub. No.: US 2017/0169366 A1, [hereinafter Klein].
As per claim 1, Gururajan teaches a system (col. 54, lines 23-30) comprising:
a non-transitory memory (col. 54, lines 23-30: “These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.”; col. 54, lines 42-57: “numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium.”); and
one or more hardware processors configured to execute instructions from the non-transitory memory to perform operations (col. 1, lines 45-55, discussing that the system includes a processor configured to receive a trip booking request for a passenger at a processor...The processor is configured to generate trip booking options from the ride sharing itineraries; col. 54, lines 23-30: “the embodiments of the devices, systems and methods described may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system, and at least one communication interface.”) comprising:
receiving an indication that a transportation application has been initialized on a requestor computing device to request a shared ride (col. 7, lines 52-53, discussing screenshots depicting an example passenger mobile application; col. 11, lines 50-63, discussing that a booking request may include one or more of the following elements: pick-up time, drop-off time, pick-up location, drop-off location, number of passengers, one-way or return trip, desired transit time, desired cost, the passenger's tolerance to delay caused by ride-sharing, and/or person's current location. For example, a passenger may utilize a smart phone application accessed at communication device 12 to send the booking request to allocation system [i.e., receiving an indication that a passenger accessed a smart phone application to send a booking request to the allocation system is considered to be receiving indication that a transportation application has been initialized on a requestor computing device] and then review and select from trip options returned by allocation system; col. 47, lines 10-14, discussing that a customer provides a trip booking request at interface application to be picked up at 60 Bronte St.; col. 15, lines 41-53), the shared ride including one or more ridesharing constraints that are to be maintained throughout the shared ride (col. 1, lines 45-55, discussing that the system includes a processor configured to receive a trip booking request for a passenger at a processor, the trip booking request defining passenger constraints. The processor is configured to generate trip booking options from the ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 3, lines 6-10, discussing that the passenger constraints include one or more ranges or metrics for a requested trip price, a requested pickup time, a requested drop off time, a requested pick up location, a requested drop off location, and a relative delay; col. 5, lines 47-50, discussing that the processor is configured to generate trip booking options from the subset of ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 30, lines 11-14, discussing that pre-travel optimizer module 212 may be configured to perform the optimization while respecting each passenger's constraints (or requirements); col. 53, lines 21-25, discussing that the vehicle's itinerary may also be modified to pick up another passenger in place of the missing passenger, so long as travel constraints of other passengers and travel constraints of the vehicle may be met), the shared ride including one or more ridesharing constraints that are to be maintained throughout the shared ride (col. 1, lines 45-55, discussing that the system includes a processor configured to receive a trip booking request for a passenger at a processor, the trip booking request defining passenger constraints. The processor is configured to generate trip booking options from the ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 3, lines 6-10, discussing that the passenger constraints include one or more ranges or metrics for a requested trip price, a requested pickup time, a requested drop off time, a requested pick up location, a requested drop off location, and a relative delay; col. 5, lines 47-50, discussing that the processor is configured to generate trip booking options from the subset of ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 30, lines 11-14, discussing that pre-travel optimizer module 212 may be configured to perform the optimization while respecting each passenger's constraints (or requirements); col. 53, lines 21-25, discussing that the vehicle's itinerary may also be modified to pick up another passenger in place of the missing passenger, so long as travel constraints of other passengers and travel constraints of the vehicle may be met);
analyzing one or more current dispatch conditions affecting dispatch of one or more transportation provider devices to the computing device (col. 13, lines 13-16, discussing that communication devices may be capable of collecting current vehicle supply and occupancy data and transmitting the occupancy information to allocation system [i.e., the current vehicle supply and occupancy data corresponds to one or more current dispatch conditions]; col. 14, lines 1-15, discussing that various data associated with the itineraries, including, for example, driver data, vehicle data, passenger data, capacity data, traffic data, current road conditions, current location of a vehicle implementing one of the itineraries, a current speed of a vehicle implementing one of the itineraries, an estimated travel time of a vehicle implementing one of the itineraries, etc., may be considered "status" data. Such status data may be used at allocation system for various purposes, such as generating estimates of itinerary times [i.e., generating estimates of itinerary times based on the status data including driver data, vehicle data, passenger data, capacity data, traffic data, current road conditions, current location of a vehicle implementing one of the itineraries, a current speed of a vehicle implementing one of the itineraries also suggests analyzing one or more current dispatch conditions affecting dispatch of one or more transportation provider devices to the computing device], etc. For example, a traffic congestion causing longer travel times may be detected, and a leg of one or more itineraries may be adjusted to adapt to the detected longer travel times; col. 17, lines 17-25, discussing that the capacity calculator module may be configured to generate a usable estimate of available capacity in the system (vehicles and/or drivers and their associated itineraries) for the desired trip, or variations of the desired trip. The available capacity relates to available vehicles and itineraries that can be used for trip booking options to satisfy the trip booking request…; col. 36, lines 40-49, discussing that real-time optimizer module may be configured to receive a given set of vehicle ride-sharing itineraries that are currently in-transit, a number of cycles to attempt, real-time status data (e.g. current vehicle location, newly cancelled trips etc.), and/or any currently unassigned trips that need to be assigned to itineraries; col. 44, lines 6-12), wherein each transportation provider device includes a global positioning system (GPS) radio configured to provide dynamically updated, real time location information for each transportation provider device; determine the current location of the passenger (col. 13, lines 7-12, discussing that the allocation system may be configured to retrieve data from a GPS or Wi-Fi based location tracker at a communication device to determine the current location of an associated vehicle, e.g., to detect travel delays, to verify that drivers are adhering to a prescribed route, etc.);
determining that the current dispatch conditions allow for a ride mode to be offered on the transportation application (col. 9, lines 55-67 & col. 10, lines 1-2, discussing that the allocation system is configured to receive a trip booking request for a passenger. The trip booking request defines passenger constraints including a desired pickup time, a desired arrive before time, a pick up location, and a drop off location. The allocation system generates trip booking options from the ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 50, lines 43-52, discussing that a trip options ranking sub-module receives as inputs the trip booking options from the capacity calculator module, and the prices associated with each trip option as calculated by the dynamic pricing module. From the various trip booking options, it determines a priority order in which the trip booking options are to be presented to the user via interface module. An interface application residing on an electronic device may display trip booking options to user for selection [i.e., the trip booking options correspond to the ride mode offered on the transportation application]; col. 16, lines 41-67, discussing that only plausible/possible trip options are presented to the passenger for selection. Interface module 216 has a trip options frequency and efficiency channeling sub-module that evaluates efficiency scores and desired departure frequency, for plausible trip options and retains specific trip options to show to the passenger. Interface module 216 has a trip options ranking sub-module that calculates scores for plausible trip options and orders them by priority to show to the passenger. A user selection for one of the trip options (corresponding to one of the potential ride-sharing itineraries) may be received, e.g., by way of interface module 216; col. 19, lines 29-37, discussing that trip insertion optimizer module 210 may conduct a determination of whether it would be possible and/or plausible to fit the trip booking request in view of existing ride-sharing itineraries); and
instructing the computing device to at least present the ride mode within a user interface of the transportation application as a selectable option based on the determination (col. 16, lines 41-67, discussing that only plausible/possible trip options are presented to the passenger for selection. Interface module 216 has a trip options frequency and efficiency channeling sub-module that evaluates efficiency scores and desired departure frequency, for plausible trip options and retains specific trip options to show to the passenger. Interface module 216 has a trip options ranking sub-module that calculates scores for plausible trip options and orders them by priority to show to the passenger. A user selection for one of the trip options (corresponding to one of the potential ride-sharing itineraries) may be received, e.g., by way of interface module 216 [i.e., presenting plausible trip options for user selection by way of interface module 216 corresponds to instructing the computing device to at least present the ride mode within the transportation application as a selectable option]; col. 25, lines 57-67 & col. 26, lines 1-3, discussing that the various modules of allocation system 100 may be configured to process various interactions with the passenger, such as information requests, decision support, trip booking requests, trip cancellations, trip modifications, etc. Allocation system 100 may be configured to provide information relating to available trips that match or may be similar in specifications to the ride request and the associated prices for each trip option; col. 50, lines 43-52, discussing that a trip options ranking sub-module receives as inputs the trip booking options from the capacity calculator module, and the prices associated with each trip option as calculated by the dynamic pricing module. From the various trip booking options, it determines a priority order in which the trip booking options are to be presented to the user via the interface module. An interface application residing on an electronic device may display trip booking options to user for selection).
While Gururajan teaches determining that the current dispatch conditions allow for a ride mode to be offered on the transportation application, it does not explicitly teach that the ride mode is an ephemeral ride mode and that the ephemeral ride mode is temporarily presented within the transportation application as a selectable option. Gururajan does not explicitly teach according to the analysis, predicting a likelihood that the requestor will pay a higher price for less uncertainty in overall ride time based on the current dispatch conditions; determining, based on the predicted likelihood, that the current dispatch conditions allow for an ephemeral ride mode to be offered on the transportation application; and instructing the computing device to at least temporarily present the ephemeral ride mode within a user interface of the transportation application as a selectable option based on the determination. However, Klein in the analogous art of transportation request management teaches these concepts. Klein teaches:
according to the analysis, predicting a likelihood that the requestor will pay a higher price for less uncertainty in overall ride time based on the current dispatch conditions (paragraph 0053, discussing that determining an adjustment cost can include identifying an additional fare amount willing to be paid by the potential additional passenger of the ride-sharing vehicle to obtain the adjustment request. The higher the fare amount willing to be paid by a potential additional passenger, the more likely it will be in some examples to grant the adjustment request; paragraph 0072, discussing that before initial passengers are made aware of the ride-sharing request received, an impact score based on combinations of one or more relevant factors can be determined. For instance, an impact score can be based at least in part on such factors as an amount of additional time needed to deviate from the ride-sharing route to pick up and drop off the one or more potential additional passengers, a rerouting distance needed to deviate from the ride-sharing route to pick up and drop off the one or more potential additional passengers, a number of initial passengers in the ride-sharing vehicle, user preferences of the one or more initial passengers and/or whether there is or will be additional passenger capacity in the ride-sharing vehicle at the time the ride-sharing request is received or at the time the potential additional passenger is requesting pickup; paragraph 0074, discussing that the method can include identifying whether the impact score determined is less than a predetermined threshold amount. In some examples, the predetermined threshold amount can depend on one or more factors such as the ride-sharing route and preferences or schedules associated with the initial passenger(s). For instance, the predetermined threshold amount can be set to require a lower impact score if an initial passenger is taking a ride-share to the airport on a tight schedule and cannot be late. In some examples, identifying whether the impact score is less than a predetermined threshold amount includes comparing the impact score with a price value associated with the one or more initial passengers, wherein the price value is related to an adjustment in fare amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers. When an impact score is identified to be less than the predetermined threshold amount, such identification is intended to indicate that the potential impact to initial passengers of a ride-sharing route might be less than a potential benefit in reduced fare discount available to the initial passenger(s) by accepting the potential additional passengers into the ride-sharing route; paragraph 0028, discussing that adjustment requests can include a variety of data features to assist with making subsequent evaluations regarding whether to grant a request. For example, an adjustment request can include an estimated arrival time of the potential additional passenger of the ride-sharing vehicle to a predetermined route location. In other examples, an adjustment request can include a requested amount of delay time (e.g., 20 seconds) beyond an expected stop time for a ride-sharing vehicle to wait at a particular route location. In other examples, an adjustment request can include an additional fare amount willing to be paid by the potential additional passenger of the ride-sharing vehicle to obtain the requested adjustment);
determining, based on the predicted likelihood, that the current dispatch conditions allow for an ephemeral ride mode to be offered on the transportation application (paragraph 0029, discussing that rules-based analytics can be used to automatically evaluate the adjustment request as well as additional information provided as part of the request or gathered in response to the request. Analytic evaluation can include determining an adjustment cost associated with the adjustment request. The adjustment cost can provide a quantifiable value of the impact of the adjustment request to initial passengers of the ride-sharing vehicle. The adjustment cost can be determined at least in part from selected factors including but not limited to: the estimated arrival time or delay time for a potential additional passenger requesting a schedule adjustment, an additional fare amount the potential additional passenger is willing to pay, a number of initial passengers on the ride-sharing vehicle, a number of times that the potential additional passenger of the ride-sharing vehicle has previously provided an adjustment request, whether the potential additional passenger of the ride-sharing vehicle is handicapped, approval response feedback from initial passengers of the ride-sharing vehicle indicating their preference for accepting or denying the adjustment request and/or a current state of the ride-sharing vehicle paragraph 0053, discussing that determining an adjustment cost can include identifying an additional fare amount willing to be paid by the potential additional passenger of the ride-sharing vehicle to obtain the adjustment request. The higher the fare amount willing to be paid by a potential additional passenger, the more likely it will be in some examples to grant the adjustment request; paragraph 0075, discussing that if the impact score is identified to be less than the predetermined threshold amount, then a notification output can be provided for display to the one or more initial passengers of the ride-sharing vehicle. An example of a notification output provided for display is the ride-sharing request notification…In some examples, a notification output provided can include information about the ride-sharing request received, including but not limited to information about the potential additional passenger(s)…; paragraph 0076, discussing that a notification output provided can include information about the pickup and drop-off locations of the potential additional passenger(s). In some examples, a notification output provided can include an indication of an expected amount of additional time needed to deviate from a ride-sharing route to pick up and drop off the one or more potential additional passengers. A notification output provided also can include a fare adjustment or discount amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers; paragraph 0032); and
instructing the computing device to at least temporarily present the ephemeral ride mode within a user interface of the transportation application as a selectable option based on the determination (paragraph 0030, discussing that the adjustment request response can be provided as a notification output to a mobile device associated with the potential additional passenger of the ride-sharing vehicle. In situations when an adjustment request is not granted or only granted in part, some embodiments can include automatic initiation of a dispatch request for alternative transportation arrangements; paragraph 0034, discussing that if the determined impact score is less than a predetermined threshold amount, then a notification output can be provided to the initial passenger(s) informing them of the ride-sharing request. In some examples, comparison of the impact score to a threshold amount involves comparing the impact score with a price value associated with the initial passenger(s). The price value can be related to an adjustment in fare amount available to the initial passenger(s) for accepting the ride-sharing request of the potential additional passenger(s). In some examples, the notification output provided to the initial passenger(s) includes an expected amount of additional time needed to deviate from the ride-sharing route to pick up and drop off the potential additional passenger(s) and a fare adjustment amount available to the initial passenger(s) for accepting the ride-sharing request of the potential additional passenger(s); paragraph 0046, discussing that selectable interface elements such as an “Accept” button and a “Decline” button can also be provided to respectively accept or decline the adjustment request response; paragraph 0061, discussing that in some examples, a commercial transportation provider can optionally send an electronic coupon, discount fare option, and/or advertisement to the user as part of an interface for the user to make a decision to initiate a dispatch request; paragraph 0067, discussing that a time impact identifier and distance impact identifier can indicate to Passenger 1 that accepting the ride-sharing request would add an additional time of four minutes and an additional distance of 0.6 miles to the ride-sharing route. A fare discount identifier can indicate to Passenger 1 that his fare for ride-sharing route would be discounted or reduced by $2.50 by accepting the ride-sharing request…; paragraph 0076, discussing that a notification output provided can include information about the pickup and drop-off locations of the potential additional passenger(s). In some examples, a notification output provided can include an indication of an expected amount of additional time needed to deviate from a ride-sharing route to pick up and drop off the one or more potential additional passengers. A notification output provided also can include a fare adjustment or discount amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers. In some examples, alternative benefits to fare discounts can be provided. For instance, passengers can earn points or coupons to use towards the cost of future rides, free rides, etc. Ride-sharing requests initiated by one or more potential additional passenger(s) may have an option to increase the amount of fare discount or other benefit offered to the initial passenger(s). Options to offer increased discount or benefit amounts can be advantageous to the initial passenger(s) receiving the benefits as well as to the potential additional passenger(s) when in a significant hurry; paragraph 0077, discussing that instructions can be received from the initial passenger(s) indicating their response to the notification output provided. The instructions received can include an indication of whether the initial passenger(s) accept or reject the ride-sharing request of the potential additional passenger(s). If instructions are received indicating that all or a majority of the initial passenger(s) have accepted the ride-sharing request, then the ride-sharing route can be modified to add one or more pickup locations and one or more drop-off locations associated with the potential additional passenger(s)…If one or more initial passengers are in a hurry, prefer not to share their ride-sharing route, or have other reasons for rejecting the ride-sharing request, there would be no negative impact. The initial passenger can simply opt-out by rejecting the ride-sharing request and the potential additional passenger(s) would be paired up with a different ride-sharing vehicle and route dispatch; paragraphs 0035, 0068).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s features for according to the analysis, predicting a likelihood that the requestor will pay a higher price for less uncertainty in overall ride time based on the current dispatch conditions; determining, based on the predicted likelihood, that the current dispatch conditions allow for an ephemeral ride mode to be offered on the transportation application; and instructing the computing device to at least temporarily present the ephemeral ride mode within a user interface of the transportation application as a selectable option based on the determination, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 3, the Gururajan-Klein combination teaches the system of claim 1. Although not explicitly taught by Gururajan, Klein in the analogous art of transportation request management teaches wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for a shorter pickup time (paragraph 0065, discussing that potential additional passengers can access the same ride-share scheduling system accessed by the initial passenger(s) to submit a ride-sharing request. Ride-sharing requests can cause an existing ride-sharing route and schedule to be adjusted to accommodate the potential additional passenger(s). This dynamic route adjustment can occur in real time at one or more time periods including before a ride-sharing vehicle is dispatched, while the ride-sharing vehicle is en route to one or more pickup locations of the initial passengers, and/or while the ride-sharing vehicle is en route to one or more drop-off locations of the initial passengers. If additional capacity exists in a given ride-sharing vehicle, and the potential additional passenger(s) requests travel within a predetermined geographic proximity to the ride-sharing route, then consideration of a ride-sharing request can be enabled according to disclosed techniques. A comparison between the requested pickup and drop-off times of initial passenger(s) and potential additional passenger(s) can also be implemented to ensure that adjustment of only appropriate ride-sharing routes and/or schedules is considered; paragraph 0072, discussing that before initial passengers are made aware of the ride-sharing request received, an impact score based on combinations of one or more relevant factors can be determined. For instance, an impact score can be based at least in part on such factors as an amount of additional time needed to deviate from the ride-sharing route to pick up and drop off the one or more potential additional passengers, a rerouting distance needed to deviate from the ride-sharing route to pick up and drop off the one or more potential additional passengers, a number of initial passengers in the ride-sharing vehicle, user preferences of the one or more initial passengers and/or whether there is or will be additional passenger capacity in the ride-sharing vehicle at the time the ride-sharing request is received or at the time the potential additional passenger is requesting pickup. When additional passenger capacity is considered, vehicle capacity determinations can be made dynamically to determine vehicle capacity for a time when additional passengers are seeking a ride. As such, even in situations when a ride-sharing vehicle is full, capacity determinations can account for whether passengers will be dropped off before an additional pickup is requested; paragraph 0074, discussing that the method can include identifying whether the impact score determined is less than a predetermined threshold amount. In some examples, the predetermined threshold amount can depend on one or more factors such as the ride-sharing route and preferences or schedules associated with the initial passenger(s). For instance, the predetermined threshold amount can be set to require a lower impact score if an initial passenger is taking a ride-share to the airport on a tight schedule and cannot be late. In some examples, identifying whether the impact score is less than a predetermined threshold amount includes comparing the impact score with a price value associated with the one or more initial passengers, wherein the price value is related to an adjustment in fare amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers. When an impact score is identified to be less than the predetermined threshold amount, such identification is intended to indicate that the potential impact to initial passengers of a ride-sharing route might be less than a potential benefit in reduced fare discount available to the initial passenger(s) by accepting the potential additional passengers into the ride-sharing route).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s feature for including
wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for a shorter pickup time, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 4, the Gururajan-Klein combination teaches the system of claim 1. Although not explicitly taught by Gururajan, Klein in the analogous art of transportation request management teaches wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for a shorter overall estimated time of arrival (ETA) (paragraph 0028, discussing that adjustment requests can include a variety of data features to assist with making subsequent evaluations regarding whether to grant a request. For example, an adjustment request can include an estimated arrival time of the potential additional passenger of the ride-sharing vehicle to a predetermined route location; paragraph 0029, discussing that rules-based analytics can be used to automatically evaluate the adjustment request as well as additional information provided as part of the request or gathered in response to the request. Analytic evaluation can include determining an adjustment cost associated with the adjustment request. The adjustment cost can provide a quantifiable value of the impact of the adjustment request to initial passengers of the ride-sharing vehicle. The adjustment cost can be determined at least in part from selected factors including but not limited to: the estimated arrival time or delay time for a potential additional passenger requesting a schedule adjustment, an additional fare amount the potential additional passenger is willing to pay,…, approval response feedback from initial passengers of the ride-sharing vehicle indicating their preference for accepting or denying the adjustment request and/or a current state of the ride-sharing vehicle; paragraph 0065, discussing that potential additional passengers can access the same ride-share scheduling system accessed by the initial passenger(s) to submit a ride-sharing request. Ride-sharing requests can cause an existing ride-sharing route and schedule to be adjusted to accommodate the potential additional passenger(s). This dynamic route adjustment can occur in real time at one or more time periods including before a ride-sharing vehicle is dispatched, while the ride-sharing vehicle is en route to one or more pickup locations of the initial passengers, and/or while the ride-sharing vehicle is en route to one or more drop-off locations of the initial passengers. If additional capacity exists in a given ride-sharing vehicle, and the potential additional passenger(s) requests travel within a predetermined geographic proximity to the ride-sharing route, then consideration of a ride-sharing request can be enabled according to disclosed techniques. A comparison between the requested pickup and drop-off times of initial passenger(s) and potential additional passenger(s) can also be implemented to ensure that adjustment of only appropriate ride-sharing routes and/or schedules is considered; paragraph 0072, discussing that before initial passengers are made aware of the ride-sharing request received, an impact score based on combinations of one or more relevant factors can be determined. For instance, an impact score can be based at least in part on such factors as an amount of additional time needed to deviate from the ride-sharing route to pick up and drop off the one or more potential additional passengers, a rerouting distance needed to deviate from the ride-sharing route to pick up and drop off the one or more potential additional passengers, a number of initial passengers in the ride-sharing vehicle, user preferences of the one or more initial passengers and/or whether there is or will be additional passenger capacity in the ride-sharing vehicle at the time the ride-sharing request is received or at the time the potential additional passenger is requesting pickup. When additional passenger capacity is considered, vehicle capacity determinations can be made dynamically to determine vehicle capacity for a time when additional passengers are seeking a ride. As such, even in situations when a ride-sharing vehicle is full, capacity determinations can account for whether passengers will be dropped off before an additional pickup is requested; paragraph 0074, discussing that the method can include identifying whether the impact score determined is less than a predetermined threshold amount. In some examples, the predetermined threshold amount can depend on one or more factors such as the ride-sharing route and preferences or schedules associated with the initial passenger(s). For instance, the predetermined threshold amount can be set to require a lower impact score if an initial passenger is taking a ride-share to the airport on a tight schedule and cannot be late. In some examples, identifying whether the impact score is less than a predetermined threshold amount includes comparing the impact score with a price value associated with the one or more initial passengers, wherein the price value is related to an adjustment in fare amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers. When an impact score is identified to be less than the predetermined threshold amount, such identification is intended to indicate that the potential impact to initial passengers of a ride-sharing route might be less than a potential benefit in reduced fare discount available to the initial passenger(s) by accepting the potential additional passengers into the ride-sharing route; paragraph 0076).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s feature for including
wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for a shorter overall estimated time of arrival, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 5, the Gururajan-Klein combination teaches the system of claim 1. Gururajan further teaches wherein the requestor computing device includes a GPS radio that provides dynamically updated, real time location information for the requestor computing device (col. 12, lines 19-22, discussing that the allocation system may be configured to retrieve data from a GPS or Wi-Fi based location tracker at a communication device to determine the current location of the passenger; col. 24, lines 50-54).
As per claim 8, the Gururajan-Klein combination teaches the system of claim 1. Gururajan further teaches wherein the ride mode allows the requestor computing device to share a ride with at least one other requestor computing device based on one or more requestor device-specific constraints (col. 3, lines 6-10: “the passenger constraints include one or more ranges or metrics for a requested trip price, a requested pickup time, a requested drop off time, a requested pick up location, a requested drop off location, and a relative delay”; col. 8, lines 32-67, discussing that allocation system 100 promotes transportation efficiency by satisfying passenger travel requirements using vehicles that concurrently service multiple passengers, thereby allowing costs to be shared amongst passengers; col. 9, lines 7-19, discussing that allocation system 100 is configured to take into account various additional factors such as, e.g., a travel delay for passengers caused by ride-sharing, which may be referred to herein as a "relative" delay. This relative delay may include a delay between an estimated transit time or distance for the passenger driving alone, and an estimated transit time or distance for the passenger according to a generated ride-sharing itinerary (which may include additional stops or route deviations to pick-up or drop-off passengers); col. 9, lines 55-67 & col. 10, lines 1-2, discussing that the allocation system is configured to receive a trip booking request for a passenger. The trip booking request defines passenger constraints. The allocation system 100 generates trip booking options from the ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 15, lines 42-43, discussing that a passenger may provide a trip booking request wherein the passenger sets out various parameters, such as the origin location, the destination location, a desired departure/arrival time, a tolerance for delay caused by ride-sharing, among others [i.e., the various parameters set out by the passenger including a tolerance for delay caused by sharing the ride with another passenger correspond to the one or more requestor device-specific constraints]; col. 15, lines 66-67 & col. 16, lines 1-3, discussing that variations that would exceed the passenger's tolerance are not presented. The passenger's relative delay tolerance for a booking request may be configured as a default system parameter or a user specified parameter; col. 20, lines 39-45, discussing that the allocation system may be configured to store a plurality of relative delay tolerance metrics, each reflective of tolerance for delay caused by ride-sharing of a particular passenger. The ride-sharing itineraries may be optimized such that the relative delay for each passenger is within an acceptable tolerance of that passenger; col. 26, lines 23-33).
While Gururajan teaches that the ride mode allows the requestor computing device to share a ride with at least one other requestor computing device based on one or more requestor device-specific constraints, it does not explicitly teach that the ride mode is an ephemeral ride mode. However, Klein in the analogous art of transportation request management teaches this concept (paragraph 0029, discussing that rules-based analytics can be used to automatically evaluate the adjustment request as well as additional information provided as part of the request or gathered in response to the request. Analytic evaluation can include determining an adjustment cost associated with the adjustment request. The adjustment cost can provide a quantifiable value of the impact of the adjustment request to initial passengers of the ride-sharing vehicle. The adjustment cost can be determined at least in part from selected factors including but not limited to: the estimated arrival time or delay time for a potential additional passenger requesting a schedule adjustment, an additional fare amount the potential additional passenger is willing to pay, a number of initial passengers on the ride-sharing vehicle, a number of times that the potential additional passenger of the ride-sharing vehicle has previously provided an adjustment request, whether the potential additional passenger of the ride-sharing vehicle is handicapped, approval response feedback from initial passengers of the ride-sharing vehicle indicating their preference for accepting or denying the adjustment request and/or a current state of the ride-sharing vehicle; paragraph 0075, discussing that if the impact score is identified to be less than the predetermined threshold amount, then a notification output can be provided for display to the one or more initial passengers of the ride-sharing vehicle. An example of a notification output provided for display is the ride-sharing request notification…In some examples, a notification output provided can include information about the ride-sharing request received, including but not limited to information about the potential additional passenger(s)…; paragraph 0076, discussing that a notification output provided can include information about the pickup and drop-off locations of the potential additional passenger(s). In some examples, a notification output provided can include an indication of an expected amount of additional time needed to deviate from a ride-sharing route to pick up and drop off the one or more potential additional passengers. A notification output provided also can include a fare adjustment or discount amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers. In some examples, alternative benefits to fare discounts can be provided. For instance, passengers can earn points or coupons to use towards the cost of future rides, free rides, etc. Ride-sharing requests initiated by one or more potential additional passenger(s) may have an option to increase the amount of fare discount or other benefit offered to the initial passenger(s). Options to offer increased discount or benefit amounts can be advantageous to the initial passenger(s) receiving the benefits as well as to the potential additional passenger(s) when in a significant hurry; paragraph 0077, discussing that instructions can be received from the initial passenger(s) indicating their response to the notification output provided. The instructions received can include an indication of whether the initial passenger(s) accept or reject the ride-sharing request of the potential additional passenger(s). If instructions are received indicating that all or a majority of the initial passenger(s) have accepted the ride-sharing request, then the ride-sharing route can be modified to add one or more pickup locations and one or more drop-off locations associated with the potential additional passenger(s)…If one or more initial passengers are in a hurry, prefer not to share their ride-sharing route, or have other reasons for rejecting the ride-sharing request, there would be no negative impact. The initial passenger can simply opt-out by rejecting the ride-sharing request and the potential additional passenger(s) would be paired up with a different ride-sharing vehicle and route dispatch; paragraphs 0061, 0068).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s feature for including wherein the ride mode allows the requestor computing device to share a ride with at least one other requestor computing device based on one or more requestor device-specific constraints, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 9, the Gururajan-Klein combination teaches the system of claim 8. Gururajan further teaches wherein the device-specific constraints comprise at least one of: a maximum potential detour time; a maximum potential detour distance; a maximum allowable percentage increase in length of detour time; or a maximum allowable percentage increase in length of detour distance (col. 9, lines 7-19, discussing that the allocation system is configured to take into account various additional factors such as, e.g., a travel delay for passengers caused by ride-sharing, which may be referred to herein as a "relative" delay. This relative delay may include an estimated transit time or distance for the passenger according to a generated ride-sharing itinerary (which may include additional stops or route deviations to pick-up or drop-off passengers); col. 9, lines 55-67 & col. 10, lines 1-2, discussing that the trip booking request defines passenger constraints. The allocation system generates trip booking options from the ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 11, lines 50-63, discussing that a booking request may, for example, include one or more of the following elements: pick-up time, drop-off time, pick-up location,…, number of passengers,…, the passenger's tolerance to delay caused by ride-sharing, and/or person's current location; col. 15, lines 42-43, discussing that a passenger may provide a trip booking request wherein the passenger sets out various parameters, such as the origin location, the destination location, a desired departure/arrival time, a tolerance for delay caused by ride-sharing (e.g., relative to the passenger driving alone directly from origin to destination), among others [i.e., the various parameters set out by the passenger including a tolerance for delay caused by sharing the ride with another passenger correspond to the device-specific constraints comprising a maximum potential detour time]; col. 15, lines 66-67 & col. 16, lines 1-3, discussing that variations that would exceed the passenger's tolerance are not presented; col. 20, lines 39-45, discussing that the allocation system may be configured to store a plurality of relative delay tolerance metrics, each reflective of tolerance for delay caused by ride-sharing of a particular passenger. The ride-sharing itineraries may be optimized such that the relative delay for each passenger is within an acceptable tolerance of that passenger).
As per claim 10, the Gururajan-Klein combination teaches the system of claim 9. Gururajan further teaches wherein the ride mode provides an indication of an estimated time to a selected destination that is customized for the computing device based on the device-specific constraints (col. 3, lines 41-42, discussing that each trip booking option has a corresponding trip length duration; col. 9, lines 55-67 & col. 10, lines 1-2, discussing that the trip booking request defines passenger constraints including a desired pickup time, a desired arrive before time, a pick up location, and a drop off location. The allocation system generates trip booking options from the ride sharing itineraries, each trip booking option including a leg that satisfies the passenger constraints of the trip booking request; col. 11, lines 50-63, discussing that a booking request may, for example, include one or more of the following elements: pick-up time, drop-off time, pick-up location, drop-off location, number of passengers,…, the passenger's tolerance to delay caused by ride-sharing, and/or person's current location. For example, a passenger may utilize a smart phone application accessed at communication device 12 to send the booking request to the allocation system and then review and select from trip options returned by the allocation system [i.e., as set forth above, each trip option has a corresponding trip length duration]; col. 15, lines 42-43, discussing that a passenger may provide a trip booking request wherein the passenger sets out various parameters, such as the origin location, the destination location, a desired departure/arrival time, a tolerance for delay caused by ride-sharing, among others [i.e., the various parameters set out by the passenger including the origin location, the destination location, among others correspond to the device-specific constraints]; col. 15, lines 54-64, discussing that the capacity calculator module may be configured to receive a trip booking request including at least one of a requested pick-up time and a requested drop-off time. The requested drop-off time reflects a latest time desired by the passenger for drop-off (i.e., an arrive-before time). In these embodiments, one of the pick-up and drop-off times may be used as a variable for determining variations of the trip; col. 24, lines 50-54, discussing that the allocation system may be configured to show the vehicle's current location on the passenger's smart-phone or other computing device along with an expected time of arrival (ETA) [i.e., providing an expected time of arrival to the drop-off location corresponds to providing an indication of an estimated time to a selected destination]; col. 4, lines 3-7; col. 4, lines 36-42).
While Gururajan teaches that the ride mode provides an indication of an estimated time to a selected destination that is customized for the computing device based on the device-specific constraints, it does not explicitly teach that the ride mode is an ephemeral ride mode. However, Klein in the analogous art of transportation request management teaches this concept (paragraph 0029, discussing that rules-based analytics can be used to automatically evaluate the adjustment request as well as additional information provided as part of the request or gathered in response to the request. Analytic evaluation can include determining an adjustment cost associated with the adjustment request. The adjustment cost can provide a quantifiable value of the impact of the adjustment request to initial passengers of the ride-sharing vehicle. The adjustment cost can be determined at least in part from selected factors including but not limited to: the estimated arrival time or delay time for a potential additional passenger requesting a schedule adjustment, an additional fare amount the potential additional passenger is willing to pay, a number of initial passengers on the ride-sharing vehicle,…, approval response feedback from initial passengers of the ride-sharing vehicle indicating their preference for accepting or denying the adjustment request and/or a current state of the ride-sharing vehicle; paragraph 0068, discussing that Passenger 1 can analyze the information provided within the ride-sharing request notification and make a decision to either accept the ride-sharing request by selecting “Accept” button or reject the ride-sharing request by selecting “Reject” button; paragraph 0075, discussing that if the impact score is identified to be less than the predetermined threshold amount, then a notification output can be provided for display to the one or more initial passengers of the ride-sharing vehicle. An example of a notification output provided for display is the ride-sharing request notification…In some examples, a notification output provided can include information about the ride-sharing request received, including but not limited to information about the potential additional passenger(s)…; paragraph 0076, discussing that a notification output provided can include information about the pickup and drop-off locations of the potential additional passenger(s). In some examples, a notification output provided can include an indication of an expected amount of additional time needed to deviate from a ride-sharing route to pick up and drop off the one or more potential additional passengers. A notification output provided also can include a fare adjustment or discount amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers. In some examples, alternative benefits to fare discounts can be provided. For instance, passengers can earn points or coupons to use towards the cost of future rides, free rides, etc. Ride-sharing requests initiated by one or more potential additional passenger(s) may have an option to increase the amount of fare discount or other benefit offered to the initial passenger(s). Options to offer increased discount or benefit amounts can be advantageous to the initial passenger(s) receiving the benefits as well as to the potential additional passenger(s) when in a significant hurry; paragraph 0077, discussing that instructions can be received from the initial passenger(s) indicating their response to the notification output provided. The instructions received can include an indication of whether the initial passenger(s) accept or reject the ride-sharing request of the potential additional passenger(s). If instructions are received indicating that all or a majority of the initial passenger(s) have accepted the ride-sharing request, then the ride-sharing route can be modified to add one or more pickup locations and one or more drop-off locations associated with the potential additional passenger(s)…If one or more initial passengers are in a hurry, prefer not to share their ride-sharing route, or have other reasons for rejecting the ride-sharing request, there would be no negative impact. The initial passenger can simply opt-out by rejecting the ride-sharing request and the potential additional passenger(s) would be paired up with a different ride-sharing vehicle and route dispatch; paragraphs 0032, 0035).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s feature for including wherein the ephemeral ride mode allows the requestor computing device to share a ride with at least one other requestor computing device based on one or more requestor device-specific constraints, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 12, the Gururajan-Klein combination teaches the system of claim 1. Gururajan further teaches wherein the ephemeral ride mode is presented according to a schedule that is specific to the requestor computing device (col. 8, lines 8-22, discussing that the allocation system may provide the passenger with a range of travel options that satisfy the passenger's travel requirements [i.e., presenting travel options that satisfy the passenger's travel requirements corresponds to presenting the ride mode according to a schedule that is specific to the requestor computing device]. For example, in response to a booking request, allocation system 100 may generate a plurality of different potential itineraries, each having at least one of (i) a plurality of different pick-up times for the passenger; (ii) a plurality of different drop-off times for the passenger (iii) a plurality of different pick-up locations for the passenger; and (iv) a plurality of different drop-off locations for the passenger. The passenger may select one of these potential itineraries for booking; col. 11, lines 50-63, discussing that a booking request may include one or more of the following elements: pick-up time, drop-off time, pick-up location, drop-off location, number of passengers,…, the passenger's tolerance to delay caused by ride-sharing, and/or person's current location. For example, a passenger may utilize a smart phone application accessed at communication device 12 to send the booking request to the allocation system and then review and select from trip options returned by the allocation system; col. 26, lines 23-33, discussing that the allocation system may be configured to allow a passenger to specify one of a "pick-up after" or a "drop-off before" time. For example, a passenger seeking transportation to his/her workplace may specify that the passenger should be dropped off prior to 9:00 AM. The latest "drop-off" time may not be flexible, but there may be flexibility in when the passenger could be "picked-up". In this example, potential ride-sharing itineraries that may fit this passenger's needs may include itineraries where the passenger is picked up at 8:30 AM and dropped off at 8:55 AM, picked up at 8:15 AM and dropped off at 8:57 AM, etc. [i.e., presenting ride-sharing options that fit the passenger’s needs (e.g., specified “drop-off before” time) also suggests that the ride mode is presented according to a schedule that is specific to the requestor computing device]; col. 26, lines 46-49, discussing that the passenger's desired ride request is displayed along with the associated price for a door-to-door trip. Other trip options may be shown that may be variants of the trip booking request; col. 16, lines 41-67).
While Gururajan teaches that the ride mode is presented according to a schedule that is specific to the requestor computing device, it does not explicitly teach that the ride mode is an ephemeral ride mode. However, Klein in the analogous art of transportation request management teaches this concept (paragraph 0029, discussing that rules-based analytics can be used to automatically evaluate the adjustment request as well as additional information provided as part of the request or gathered in response to the request. Analytic evaluation can include determining an adjustment cost associated with the adjustment request. The adjustment cost can provide a quantifiable value of the impact of the adjustment request to initial passengers of the ride-sharing vehicle. The adjustment cost can be determined at least in part from selected factors including but not limited to: the estimated arrival time or delay time for a potential additional passenger requesting a schedule adjustment, an additional fare amount the potential additional passenger is willing to pay, a number of initial passengers on the ride-sharing vehicle,…, approval response feedback from initial passengers of the ride-sharing vehicle indicating their preference for accepting or denying the adjustment request and/or a current state of the ride-sharing vehicle; paragraph 0068, discussing that Passenger 1 can analyze the information provided within the ride-sharing request notification and make a decision to either accept the ride-sharing request by selecting “Accept” button or reject the ride-sharing request by selecting “Reject” button; paragraph 0075, discussing that if the impact score is identified to be less than the predetermined threshold amount, then a notification output can be provided for display to the one or more initial passengers of the ride-sharing vehicle. An example of a notification output provided for display is the ride-sharing request notification…In some examples, a notification output provided can include information about the ride-sharing request received, including but not limited to information about the potential additional passenger(s)…; paragraph 0076, discussing that a notification output provided can include information about the pickup and drop-off locations of the potential additional passenger(s). In some examples, a notification output provided can include an indication of an expected amount of additional time needed to deviate from a ride-sharing route to pick up and drop off the one or more potential additional passengers. A notification output provided also can include a fare adjustment or discount amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers. In some examples, alternative benefits to fare discounts can be provided. For instance, passengers can earn points or coupons to use towards the cost of future rides, free rides, etc. Ride-sharing requests initiated by one or more potential additional passenger(s) may have an option to increase the amount of fare discount or other benefit offered to the initial passenger(s). Options to offer increased discount or benefit amounts can be advantageous to the initial passenger(s) receiving the benefits as well as to the potential additional passenger(s) when in a significant hurry; paragraph 0077, discussing that instructions can be received from the initial passenger(s) indicating their response to the notification output provided. The instructions received can include an indication of whether the initial passenger(s) accept or reject the ride-sharing request of the potential additional passenger(s). If instructions are received indicating that all or a majority of the initial passenger(s) have accepted the ride-sharing request, then the ride-sharing route can be modified to add one or more pickup locations and one or more drop-off locations associated with the potential additional passenger(s)…If one or more initial passengers are in a hurry, prefer not to share their ride-sharing route, or have other reasons for rejecting the ride-sharing request, there would be no negative impact. The initial passenger can simply opt-out by rejecting the ride-sharing request and the potential additional passenger(s) would be paired up with a different ride-sharing vehicle and route dispatch; paragraphs 0032, 0035).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s feature for including the ephemeral ride mode, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 13, the Gururajan-Klein combination teaches the system of claim 12. Gururajan teaches prior ride-history data associated with the requestor computing device (col. 24, lines 33-40, discussing that the database may be comprised of non-transitory computer-readable media storing various elements of information, such as passenger profiles, itinerary information, constraints, heuristic information, ride sharing requests, historical data, analytic data, event data, sensory data, etc.; col. 26, lines 39-42, discussing that the interface may be configured to associate a passenger with a passenger profile, which may store various elements of information related to that passenger's preferences and/or historical trips [i.e. the historical trips corresponds to the prior ride-history data]; col. 39, lines 38-48), but it does not explicitly teach wherein the schedule is determined automatically based on prior ride-history data associated with the requestor computing device. However, Klein in the analogous art of transportation request management teaches this concept (paragraph 0027, discussing that a determination that a potential additional passenger will be late for a predetermined stop time at a given route location can be made based in part from passenger commuting history; paragraph 0029, discussing that rules-based analytics can be used to automatically evaluate the adjustment request as well as additional information provided as part of the request or gathered in response to the request. Analytic evaluation can include determining an adjustment cost associated with the adjustment request. The adjustment cost can provide a quantifiable value of the impact of the adjustment request to initial passengers of the ride-sharing vehicle. The adjustment cost can be determined at least in part from selected factors including but not limited to: the estimated arrival time or delay time for a potential additional passenger requesting a schedule adjustment, an additional fare amount the potential additional passenger is willing to pay, a number of initial passengers on the ride-sharing vehicle, a number of times that the potential additional passenger of the ride-sharing vehicle has previously provided an adjustment request…; paragraph 0039, discussing that an intended user pickup or drop-off can be identified automatically from statistical models that identify a user's normal travel schedule based on geolocation and timestamp history (e.g., a user's normal commute schedule on weekday mornings and evenings).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s feature for including wherein the schedule is determined automatically based on prior ride-history data associated with the requestor computing device, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 15 and 20 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 1, as discussed above. Further, as per claim 15 the Gururajan-Klein combination teaches a computer-implemented method (Gururajan, abstract, discussing systems and methods for electronically booking ride share trips; col. 4, lines 65-67). As per claim 20, the Gururajan-Klein combination teaches a non-transitory computer-readable medium comprising computer readable instructions (Gururajan, col. 1, lines 45-55, discussing a system for electronically booking ride share trips. The system includes a processor configured to receive a trip booking request for a passenger at a processor, the trip booking request defining passenger constraints. The processor is configured to generate trip booking options from the ride sharing itineraries; col. 54, lines 23-30, discussing that the embodiments of the devices, systems and methods described may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface; col. 54, lines 42-57).
As per claim 16, the Gururajan-Klein combination teaches the computer-implemented method of claim 15. Gururajan further teaches wherein the current dispatch conditions comprise at least one of: an indication of available transportation provider devices; an indication of profitability of a shared ride provided through the ephemeral ride mode; a measure of efficiency within a transportation management system; a measure of expected conversion rate; a determination that the requestor computing device is currently located in a specified city; a determination that the requestor computing device is currently located on a specified route; or identification of a transportation requestor associated with the requestor computing device (col. 6, lines 20-44, discussing that a subset of said plurality of ride-sharing itineraries are presented to the user as ride options available for booking, wherein said subset of trip options is determined based on analyzing at least one measure of efficiency score and one measure of temporal proximity between trip options; col. 13, lines 13-16, discussing that communication devices may be capable of collecting current vehicle supply and occupancy data and transmitting the occupancy information to allocation system [i.e., the current vehicle supply and occupancy data suggests current dispatch conditions]; col. 14, lines 1-15, discussing that various data associated with the itineraries, including, for example, driver data, vehicle data, passenger data, capacity data, traffic data, current road conditions, current location of a vehicle implementing one of the itineraries, a current speed of a vehicle implementing one of the itineraries, an estimated travel time of a vehicle implementing one of the itineraries, etc., may be considered "status" data. Such status data may be used at allocation system for various purposes, such as generating estimates of itinerary times [i.e., status data including driver data, vehicle data, passenger data, capacity data, traffic data, current road conditions, current location of a vehicle implementing one of the itineraries, a current speed of a vehicle implementing one of the itineraries corresponds to the current dispatch condition comprising identification of a transportation requestor associated with the requestor computing device]; col. 17, lines 17-25, discussing that the capacity calculator module may be configured to generate a usable estimate of available capacity in the system (vehicles and/or drivers and their associated itineraries) for the desired trip, or variations of the desired trip. The available capacity relates to available vehicles (i.e., available transportation provider devices) and itineraries that can be used for trip booking options to satisfy the trip booking request [i.e., the available capacity referring to available vehicles corresponds to the current dispatch condition comprising an indication of available transportation provider devices]. The available capacity can be based on the trip price, pickup time, drop-off time, pickup location, drop-off location, and so on; col. 9, lines 45-49; col. 36, lines 40-49; col. 36, lines 63-67; col. 44, lines 6-12).
As per claim 17, the Gururajan-Klein combination teaches the computer-implemented method of claim 16. Although not explicitly taught by Gururajan, Klein in the analogous art of transportation request management teaches wherein the ephemeral ride mode is presented dynamically within the transportation application upon the occurrence of at least one of the current dispatch conditions (paragraph 0030, discussing that the adjustment request response can be provided as a notification output to a mobile device associated with the potential additional passenger of the ride-sharing vehicle; paragraph 0032, discussing that dynamic route adjustment can occur in real time at one or more time periods including while the ride-sharing vehicle is en route to the one or more pickup locations of the initial passengers…; paragraph 0034, discussing that if the determined impact score is less than a predetermined threshold amount, then a notification output can be provided to the initial passenger(s) informing them of the ride-sharing request. In some examples, comparison of the impact score to a threshold amount involves comparing the impact score with a price value associated with the initial passenger(s). The price value can be related to an adjustment in fare amount available to the initial passenger(s) for accepting the ride-sharing request of the potential additional passenger(s). In some examples, the notification output provided to the initial passenger(s) includes an expected amount of additional time needed to deviate from the ride-sharing route to pick up and drop off the potential additional passenger(s) and a fare adjustment amount available to the initial passenger(s) for accepting the ride-sharing request of the potential additional passenger(s); paragraph 0046, discussing that selectable interface elements such as an “Accept” button and a “Decline” button can also be provided to respectively accept or decline the adjustment request response; paragraph 0067, discussing that a time impact identifier and distance impact identifier can indicate to Passenger 1 that accepting the ride-sharing request would add an additional time of four minutes and an additional distance of 0.6 miles to the ride-sharing route. A fare discount identifier can indicate to Passenger 1 that his fare for ride-sharing route would be discounted or reduced by $2.50 by accepting the ride-sharing request…; paragraph 0076, discussing that a notification output provided can include information about the pickup and drop-off locations of the potential additional passenger(s). In some examples, a notification output provided can include an indication of an expected amount of additional time needed to deviate from a ride-sharing route to pick up and drop off the one or more potential additional passengers. A notification output provided also can include a fare adjustment or discount amount available to the initial passengers for accepting the ride-sharing request of the one or more potential additional passengers…Ride-sharing requests initiated by one or more potential additional passenger(s) may have an option to increase the amount of fare discount or other benefit offered to the initial passenger(s). Options to offer increased discount or benefit amounts can be advantageous to the initial passenger(s) receiving the benefits as well as to the potential additional passenger(s) when in a significant hurry; paragraph 0077, discussing that instructions can be received from the initial passenger(s) indicating their response to the notification output provided. The instructions received can include an indication of whether the initial passenger(s) accept or reject the ride-sharing request of the potential additional passenger(s). If instructions are received indicating that all or a majority of the initial passenger(s) have accepted the ride-sharing request, then the ride-sharing route can be modified to add one or more pickup locations and one or more drop-off locations associated with the potential additional passenger(s)…If one or more initial passengers are in a hurry, prefer not to share their ride-sharing route, or have other reasons for rejecting the ride-sharing request, there would be no negative impact. The initial passenger can simply opt-out by rejecting the ride-sharing request and the potential additional passenger(s) would be paired up with a different ride-sharing vehicle and route dispatch; paragraph 0035, 0068).
Gururajan is directed towards systems, methods, devices for facilitating vehicle ride-sharing amongst passengers. Klein is directed to systems and methods for adjusting ride-sharing schedules and routes. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gururajan with Klein because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying Gururajan to include Klein’s feature for including wherein the ephemeral ride mode is presented dynamically within the transportation application upon the occurrence of at least one of the current dispatch conditions, in the manner claimed, would serve the motivation of enhancing the availability and effectiveness of ride-sharing options (Klein at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 18, the Gururajan-Klein combination teaches the computer-implemented method of claim 15. Gururajan further teaches wherein the step of analyzing the one or more current dispatch conditions affecting the dispatch of the one or more transportation provider devices based on the requestor computing device includes calculating a match efficiency rating that indicates a determined value of matching the computing device to at least one of the transportation provider devices (col. 6, lines 20-44, discussing that a subset of said plurality of ride-sharing itineraries are presented to the user as ride options available for booking, wherein said subset of trip options is determined based on analyzing a measure of efficiency score; col. 17, lines 47-57, discussing that a trip options frequency and efficiency channeling sub-module 220 takes as inputs trip booking request, trip booking options from the capacity calculator module 206, that satisfy the trip booking request, and for each trip booking option, its efficiency score. From the various trip booking options, it analyzes the efficiency score. It removes specific trip booking options that are less efficient and sends the retained list of trip booking options to trip options ranking sub-module 218 and/or to interface module 216. The retained list of trip booking options are channeled in order to improve the efficiency of a ride-share itinerary, and presented in a certain time frequency that facilitates better planning for the end user. The retained list of trip booking options provide different pickup time options that span a time range; col. 25, lines 57-67 & col. 26, lines 1-3, discussing that allocation system 100 may be configured to provide information relating to available trips that match or may be similar in specifications to the ride request and the associated prices for each trip option; col. 5, lines 54-65).
As per claim 19, the Gururajan-Klein combination teaches the computer-implemented method of claim 18. Gururajan further teaches further comprising: determining that the calculated match efficiency rating meets a minimum threshold value (col. 6, lines 20-44, discussing that a subset of said plurality of ride-sharing itineraries are presented to the user as ride options available for booking, wherein said subset of trip options is determined based on analyzing at least one measure of efficiency score and one measure of temporal proximity between trip options; col. 16, lines 41-67, discussing that only plausible/possible trip options are presented to the passenger for selection. Interface module 216 has an efficiency channeling sub-module 220 that evaluates efficiency scores, for plausible trip options and retains specific trip options to show to the passenger. Interface module 216 has a trip options ranking sub-module 218 that calculates scores for plausible trip options and orders them by priority to show to the passenger. A user selection for one of the trip options may be received; col. 17, lines 48-67, discussing that an efficiency channeling sub-module 220 takes as inputs trip booking request, trip booking options from the capacity calculator module 206, that satisfy the trip booking request, and for each trip booking option, its efficiency score. From the various trip booking options, it analyzes the efficiency score. It removes specific trip booking options that are less efficient and sends the retained list of trip booking options to trip options ranking sub-module 218 and/or to interface module 216 [i.e., analyzing the efficiency score for each trip booking option and retaining trip booking options that are more efficient corresponds to determining that the calculated match efficiency rating meets a minimum threshold value]. The retained list of trip booking options are channeled in order to improve the efficiency of a ride-share itinerary…; col. 25, lines 57-67 & col. 26, lines 1-3, discussing that allocation system 100 may be configured to provide information relating to available trips that match or may be similar in specifications to the ride request and the associated prices for each trip option); and
matching the requestor computing device to at least one of the transportation provider devices (col. 16, lines 41-67 & col. 17, lines 1-16, discussing that once one of the trip options has been selected, allocation system 100 may provide a confirmation to the passenger of acceptance of the trip booking request. The allocation system may generate and transmit notification messages regarding the trip booking request to notify the driver linked to the vehicle assigned to the confirmed trip booking option… As trip booking options are confirmed, allocation system 100 is configured to automatically and dynamically update, in real-time, the dynamic route of the itinerary for the driver to add to the additional stop locations and stop times associated with the new accepted trip booking requests. The allocation system is configured to generate and transmit notifications of the updated itinerary to a device associate with the driver of the vehicle; col. 52, lines 25-53, discussing that allocation system 100 may be configured to provide itinerary and/or routing information to a driver. The information may be provided through a smart device which may be wireless connected to the Internet. For example, the information can include the specific passenger pick-ups/drop-offs, times and locations. The information can include real-time notifications indicating whether the driver is ahead of schedule or behind schedule).
20. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Gururajan in view of Klein, in further view of Asghari et al., Pub. No.: US 2019/0370922 A1, [hereinafter Asghari].
As per claim 2, the Gururajan-Klein combination teaches the system of claim 1. While Gururajan describes that a passenger may provide a trip booking request wherein the passenger sets out various parameters, such as a tolerance for delay caused by ride-sharing (col. 15, lines 42-43), the Gururajan-Klein combination does not explicitly teach wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for fewer detours or shorter detours. However, Asghari in the analogous art f ride-sharing systems teaches this concept. Asghari teaches:
wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for fewer detours or shorter detours (paragraph 0045, discussing that the rider [i.e. the requestor] may set time-based options further specifying expected discount. For example, the rider may expect more of a discount when the inconvenience of a detour is greater (e.g., heavy traffic, late at night). In an illustrative example, when the detour is between 12 AM-6 AM, the rider may expect a larger discount, as it is late at night and the rider may want to get home as soon as possible. In another illustrative example, when detour is between 3 PM-7 PM, the rider may also expect a larger discount, as there may be considerable traffic present, and a 2-mile detour may mean a 1 hour delay; paragraph 0047, discussing in the rider profile, the horizontal axis represents a distance detour and the vertical axis represents a discount ratio. The curve represents the values specified by the rider and is specific to the rider. For example, when the distance detour is 10 miles, the rider expects a discount ratio of 0.55. That is, if the rider is currently in a driver's vehicle, and the driver picks up another passenger resulting in a detour of 10 miles, the rider currently in the vehicle expects to pay 55% of the rider's original fare (i.e., a 45% discount); paragraph 0048, discussing that the rider may simply enter in a plurality of data points (e.g., 5 mile detour results in 80% of original fare; 20 mile detour results in 20% of original fare; and 30 mile detour results in 1% of original fare) and the rider mobile device may fit a curve to the entered-in data points; paragraph 0075, discussing that a rider's profile may be used as a tool for the rider to specify how much discount the rider expects to receive in return for a certain amount of detour on the rider's trip. A rider's profile can have different formats: linear decay or exponential decay, which represents that the rider is not willing to take a service after the decay point; paragraph 0073).
The Gururajan-Klein combination describes features related to ride-sharing and transportation request management. Asghari is directed to a price-aware real-time auction-based ride-sharing system. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Gururajan-Klein combination with Asghari because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying the Gururajan-Klein combination to include Asghari’s feature for including wherein predicting the likelihood that the requestor will pay a higher price for less uncertainty in overall ride time includes predicting whether the requestor will pay a higher price for fewer detours or shorter detours, in the manner claimed, would serve the motivation of efficiently assigning riders to the candidate drivers (Asghari at paragraph 0040); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
21. Claims 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Gururajan in view of Klein, in further view of Gopalakrishnan et al., Pub. No.: US 2018/0165731 A1, [hereinafter Gopalakrishnan].
As per claim 6, the Gururajan-Klein combination teaches the system of claim 1. Although not explicitly taught by the Gururajan-Klein combination, Gopalakrishnan in the analogous art of real time ridesharing management teaches wherein a separate set of tighter ridesharing constraints is implemented when determining whether to surface the ephemeral ride mode, the separate set of ridesharing constraints including additional restrictions that are only applied in the ephemeral ride mode (paragraph 0005, discussing that the method includes receiving, by one or more transceivers in the computing device, a first plurality of ridesharing requests of a first plurality of commuters from a first plurality of commuter-computing devices. A ridesharing request of the first plurality of ridesharing requests comprises at least a set of commuter constraints. The method further includes identifying, by one or more processors in the computing device, a ridesharing vehicle in real time, by matching one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests based on at least the corresponding set of commuter constraints, to maximize a key performance parameter, for the matched ridesharing requests in the first plurality of ridesharing requests, as specified by a service provider of the ridesharing vehicle; paragraph 0019, discussing that the ridesharing request may comprise the source location, the destination location, and a set of commuter constraints, such as a waiting time threshold, a detour distance threshold, and a detour time threshold, and/or the like; paragraph 0020, discussing that the ridesharing vehicle may be identified to serve a plurality of ridesharing requests of a plurality of commuters based on a set of commuter constraints and a set of vehicle constraints; paragraph 0022, discussing that a “set of commuter constraints” refers to constraints specified by a commuter in a ridesharing request; paragraph 0023, discussing that a “set of vehicle constraints” refers to constraints associated with a ridesharing vehicle. In an embodiment, the set of vehicle constraints may include a capacity constraint of the ridesharing vehicle. For example, the vehicle capacity of a ridesharing vehicle may be “four.” Thus, the ridesharing vehicle may serve a maximum of “four” requests simultaneously. Further, based on the vehicle capacity, the ridesharing vehicle may not be identified for more than “four” ridesharing requests at a given time instant. Thus, “four” ridesharing requests may correspond to the capacity constraint of the ridesharing vehicle; paragraph 0054, discussing that the ride matcher 208 may execute the matching of ridesharing requests based on the set of commuter constraints...In an embodiment, the ride matcher 208 may be configured to identify a ridesharing vehicle, such as the first ridesharing vehicle 110A or the second ridesharing vehicle 110B, for the matched ridesharing requests; paragraph 0065, discussing that the matching of one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests is based on the corresponding set of commuter constraints. In an embodiment, the processor may be configured to instruct the ride matcher 208 to identify a ridesharing vehicle in real time, by matching one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests to maximize the key performance parameter for the matched ridesharing requests. In an embodiment, the matching one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests may minimize the other key performance parameter (i.e., a number of driver-miles for serving the first plurality of commuters) specified by the service provider; paragraph 0073, discussing that after creating the first list, the ride matcher 208 may be configured to remove the first entry of the first list (i.e., the ridesharing request of commuter 104C assigned to the third ridesharing vehicle). Thereafter, the ride matcher 208 may be configured to match the removed entry with the remaining entries of the first list based on the set of commuter constraints of the ridesharing request in the removed entry and the remaining entries of the first list. In other words, the ride matcher 208 may be configured to match one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests based on the corresponding set of commuter constraints. For matching the removed entry with the remaining entries of the first list, the ride matcher 208 may be configured to traverse the first list from top to bottom. The ride matcher 208 may perform matching of the remaining entries of the first list with the removed entry based on the corresponding set of commuter constraints, a set of vehicle constraints, and an increment in value of a profitability parameter. The set of vehicle constraints may include the capacity constraint of the ridesharing vehicle in the removed entry of the first list; paragraph 0093, discussing that if the third ridesharing vehicle may be assigned to pick the commuter 104C along with the commuter 104A, the waiting time threshold, the detour distance threshold, and the detour time threshold, of both the commuters (i.e., the commuter 104C and the commuter 104A) are satisfied; paragraphs 0037, 0068).
The Gururajan-Klein combination describes features related to ride-sharing and transportation request management. Gopalakrishnan is directed to a method and system for real time ridesharing management. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Gururajan-Klein combination with Gopalakrishnan because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying the Gururajan-Klein combination to include Gopalakrishnan’s feature for including wherein a separate set of tighter ridesharing constraints is implemented when determining whether to surface the ephemeral ride mode, the separate set of ridesharing constraints including additional restrictions that are only applied in the ephemeral ride mode, in the manner claimed, would serve the motivation of facilitating real time management of ridesharing services (Gopalakrishnan at paragraph 0139); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 7, the Gururajan-Klein-Gopalakrishnan combination teaches the system of claim 6. Although not explicitly taught by the Gururajan-Klein combination, Gopalakrishnan in the analogous art of real time ridesharing management teaches wherein the ephemeral ride mode is offered only if the shared ride constraints are determined to be enforceable throughout the duration of the shared ride and only if the separate set of ridesharing constraints with the additional restrictions has been met (paragraph 0019, discussing that the ridesharing request may comprise the source location, the destination location, and a set of commuter constraints, such as a waiting time threshold, a detour distance threshold, and a detour time threshold, and/or the like; paragraph 0020, discussing that the ridesharing vehicle may be identified to serve a plurality of ridesharing requests of a plurality of commuters based on a set of commuter constraints and a set of vehicle constraints; paragraph 0022, discussing that a “set of commuter constraints” refers to constraints specified by a commuter in a ridesharing request; paragraph 0023, discussing that a “set of vehicle constraints” refers to constraints associated with a ridesharing vehicle. In an embodiment, the set of vehicle constraints may include a capacity constraint of the ridesharing vehicle. For example, the vehicle capacity of a ridesharing vehicle may be “four.” Thus, the ridesharing vehicle may serve a maximum of “four” requests simultaneously. Further, based on the vehicle capacity, the ridesharing vehicle may not be identified for more than “four” ridesharing requests at a given time instant. Thus, “four” ridesharing requests may correspond to the capacity constraint of the ridesharing vehicle; paragraph 0054, discussing that the ride matcher 208 may execute the matching of ridesharing requests based on the set of commuter constraints...In an embodiment, the ride matcher 208 may be configured to identify a ridesharing vehicle, such as the first ridesharing vehicle 110A or the second ridesharing vehicle 110B, for the matched ridesharing requests; paragraph 0065, discussing that the matching of one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests is based on the corresponding set of commuter constraints. In an embodiment, the processor may be configured to instruct the ride matcher 208 to identify a ridesharing vehicle in real time, by matching one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests to maximize the key performance parameter for the matched ridesharing requests. In an embodiment, the matching one of the first plurality of ridesharing requests with remaining of the first plurality of ridesharing requests may minimize the other key performance parameter (i.e., a number of driver-miles for serving the first plurality of commuters) specified by the service provider; paragraph 0093, discussing that if the third ridesharing vehicle may be assigned to pick the commuter 104C along with the commuter 104A, the waiting time threshold, the detour distance threshold, and the detour time threshold, of both the commuters (i.e., the commuter 104C and the commuter 104A) are satisfied; paragraph 0094, discussing that the ride matcher 208 may further determine that the set of vehicle constraints (i.e., the capacity constraint of the other ridesharing vehicle) is not violated on matching the removed entry with the second entry in the remaining entries of the first list. In other words, the third ridesharing vehicle may have a capacity to accommodate the commuter 104B along with the commuter 104C. Further, the ride matcher 208 may determine that the set of commuter constraints is not violated on matching the removed entry with the second entry in the remaining entries of the first list. In other words, if the third ridesharing vehicle may be assigned to pick the commuter 104C along with the commuter 104B, the waiting time threshold, the detour distance threshold, and the detour time threshold, of both the commuters (i.e., the commuter 104C and the commuter 104B) are satisfied; paragraph 0102, discussing that the ride matcher 208 may be configured to determine the increment in the value of the profitability parameter by use of equation (4) for all possible pairs of the assigned ridesharing vehicles that meet the set of vehicle constraints and the set of commuter constraints…; paragraph 0073).
The Gururajan-Klein combination describes features related to ride-sharing and transportation request management. Gopalakrishnan is directed to a method and system for real time ridesharing management. Therefore, they are deemed to be analogous as they both are directed towards systems for managing transportation service requests. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Gururajan-Klein combination with Gopalakrishnan because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying the Gururajan-Klein combination to include Gopalakrishnan’s feature for including wherein the ephemeral ride mode is offered only if the shared ride constraints are determined to be enforceable throughout the duration of the shared ride and only if the separate set of ridesharing constraints with the additional restrictions has been met, in the manner claimed, would serve the motivation of facilitating real time management of ridesharing services (Gopalakrishnan at paragraph 0139); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
22. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Gururajan in view of Klein, in further view of Matthiesen et al., Pub. No.: US 2018/0188731 A1, [hereinafter Matthiesen].
As per claim 11, the Gururajan-Klein combination teaches the system of claim 1. Although not explicitly taught by the Gururajan-Klein combination, Matthiesen in the analogous art of transportation request management teaches further comprising instructing the requestor computing device to dynamically remove the ephemeral ride mode from the user interface upon determining, based on the real time location of the requestor computing device or the real time location of the transportation provider device, that the shared ride constraints no longer apply, such that the ephemeral ride mode is automatically removed from the user interface of the transportation application on the requestor computing device (paragraph 0021, discussing that aa ride request graphical user interface (GUI) can show a map of an area where the requestor is located. The map may include icons, such as vehicles, representing available vehicles in the area. Each icon may be located on the map at a location corresponding to an approximate real time location of the corresponding vehicle; paragraph 0022, discussing that after setting the pickup location, a ride selection element can be displayed in the ride request GUI. The ride selection element can include available types of vehicles available to complete the ride. For example, a group carpool option, an autonomous option, and a large vehicle option may be provided, as shown. Additional, fewer, or alternative types of rides may similarly be presented. Each option can include a description of the ride and estimated time of arrival. In some embodiments, depending on the selected type, additional information may be required before the ride can be confirmed. For example, autonomous option 216 has been selected. In some embodiments, autonomous vehicles may be limited to particular routes or particular geographic areas, limiting the availability of this option if, e.g., the drop-off location is not within one of these regions. As such, drop-off element 220 can be displayed and a drop-off location can be received. The requestor can select element 222 to set the drop-off location based on the entered location identifier. The location identifier can be sent to the ride matching system to determine whether an autonomous vehicle is available for that drop-off location. In some embodiments, if an autonomous vehicle is not available for that drop-off location and/or between the requested pickup and drop-off locations, a message can be displayed indicating the lack of availability and autonomous option 216 can be removed from ride selection element 212. In some embodiments, if an autonomous vehicle is not available to service the request, the requestor may be automatically matched to a different type of ride; paragraph 0023, discussing that as shown in FIG. 2C, autonomous ride option 216 has been requested. The other ride options have been removed, leaving the selected autonomous option displayed at element 224. The current drop-off location is set at element 226, and the option to add one or more drop-off locations 228 is shown. In some embodiments, element 226 can be selected to change the current drop-off location).
The Gururajan-Klein combination describes features related to transportation service management. Matthiesen relates to systems and methods to manage rider pickup and drop-off. Therefore, they are deemed to be analogous as they both are directed towards transportation service management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Gururajan-Klein combination with Matthiesen because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying the Gururajan-Klein combination to include Matthiesen’s feature for instructing the requestor computing device to dynamically remove the ephemeral ride mode from the user interface upon determining, based on the real time location of the requestor computing device or the real time location of the transportation provider device, that the shared ride constraints no longer apply, such that the ephemeral ride mode is automatically removed from the user interface of the transportation application on the requestor computing device, in the manner claimed, would serve the motivation of facilitating request ride matching requestors received from requestor computing devices with available providers (Matthiesen at paragraph 0032); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
23. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Gururajan in view of Klein, in further view of Paul et al., Pub. No.: US 2015/0248689 A1, [hereinafter Paul].
As per claim 14, the Gururajan-Klein combination teaches the system of claim 13, but it does not explicitly teach wherein the ephemeral ride mode is presented within the transportation application according to the schedule even if the current dispatch conditions are unmet. However, Paul in the analogous art of transportation service management teaches this concept (paragraph 0120, discussing that the transportation server determines one or more areas that will have an increased need for drivers. For example, a business area of a city will have increased need for drivers around dinner time, as workers leave work and travel to dinner or home. In some example embodiments, the transportation server creates one or more incentives for riders to take a ride that ends in an area with increased driver need; paragraph 0122, discussing that the current user interface example shows two offers. The first is for discounted rides to downtown San Francisco. In some example embodiments, this offer is responding to increased demand for drivers in San Francisco after business hours end. The second offer is for a trip to Santa Clara before 4:00 PM [i.e., the presentation of the ride option is temporary]. In some example embodiments, there is an American Football game at the Levi's stadium that ends at 4:00 PM and the transportation server is attempting to increase the supply of drivers in that area; paragraph 0159, discussing that in some example embodiments, certain discounts are applied automatically (e.g., a discount for travelling on a specific holiday or to a specific location). In other example embodiments, certain discounts are only applied when the user consents; paragraphs 0166, 0168).
The Gururajan-Klein combination describes features related to transportation service management. Paul relates to transportation services. Therefore, they are deemed to be analogous as they both are directed towards transportation service management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Gururajan-Klein combination with Paul because the references are analogous art because they are both directed to solutions for transportation services, which falls within applicant’s field of endeavor (transportation management systems), and because modifying the Gururajan-Klein combination to include Paul’s feature for presenting the ephemeral ride mode within the transportation application according to the schedule even if the current dispatch conditions are unmet, in the manner claimed, would serve the motivation of increasing the ability of the transportation server to efficiently plan rides for users (Paul at paragraph 0158); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rong et al., Pub. No.: US 2019/0137291 A1 – describes a server that removes certain options by comparing the parameters with the criteria provided by the user. For example, assuming the passenger is only willing to walk for 50 meters (or less than 10 minutes), and wait a total of 15 minutes to be picked-up, the server may determine that option (1) should be removed because the total waiting time (e.g., 45 minutes) exceeds the 15 minutes threshold, and option (3) should also be removed because the walking distance (e.g., 60 meters) exceeds the 50 meters limit.
Munafo et al., Pub. No.: US 2019/0050787 A1 – describes rider matching in ridesharing.
Liu et al., Pub. No.: US 2016/0321771 A1 – describes a multi-modal transportation system allowing for trip planning, bidding, displaying, and trip reservation, including identification of range contours for use in ridesharing.
Cao, Pub. No.: US 2016/0364678 A1 – describes systems and methods for on-demand transportation.
Zhang et al., Pub. No.: US 2019/0057476 A1 – describes a system and method for reducing wait time in providing transportation service.
McGrath, Pub. No.: US 2006/0178949 A1 – describes buttons for saving or updating a ride offer or deleting the ride offer.
Cooksey et al., Pub. No.: US 2020/0160374 A1 – describes an offer-determination computer that determine customized offers for two potential leasees with respect to the same apartment but might determine that a second potential leasee is likely to accept an offer at a higher price. In this way, the offer-determination computer can help the offeror to maximize its profitability.
Agatz, Niels, et al. "Optimization for dynamic ride-sharing: A review." European Journal of Operational Research 223.2 (2012): 295-303 – outlines the optimization challenges that arise when developing technology to support ride-sharing and survey the related operations research models in the academic literature.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Darlene Garcia-Guerra whose telephone number is (571) 270-3339. The examiner can normally be reached on M-F 7:30a.m.-5:00p.m. EST.
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, Brian M. Epstein can be reached on 571- 270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Darlene Garcia-Guerra/
Primary Examiner, Art Unit 3625