DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The claims 1-14 are currently pending and have been examined. Applicant amended claims 1 and 8.
Response to Arguments/Amendments
The amendment filed June 22, 2026 has been entered. Claims 1-14 are currently pending in the Application. Applicant’s amendments to the claims have overcome the drawing objections and specification objections previously set forth in the Non-Final Rejection.
Applicant's arguments regarding the 35 U.S.C. 101 mental process rejection have been fully considered but they are not persuasive.
The Examiner has carefully considered applicant’s arguments and respectfully disagrees. Applicant argues that the amended claim is not a mental process because it requires large-scale historical-data retrieval, filtering, multiple route computations, and multi-constraint optimization that allegedly cannot practically be performed in the human mind with pen and paper. Applicant additionally argues the claim is integrated into a practical application because filtering candidate pick up points before route computation allegedly reduces unnecessary route calculations, lowers computational overhead, improves resource utilization, and therefore improves computer technology and system performance, comparing the claimed limitations to Enfish and Example 42. Applicant lastly argues the particular ordered combination is unconventional under BASCOM through the steps of the claims and therefore amounts to significantly more (See pages 9-16 of Applicant’s remarks).
The Examiner has considered such arguments; however, when given their broadest reasonable interpretation in light of the specification, the claims remain directed to a judicial exception—specifically, to methods of organizing human activity and mental processes. The claimed steps of receiving a request for a ride, accessing a reference database to retrieve historical data, determining one or more pick up points, filtering the candidate pick up points, determining one or more routes, and adaptively identifying an optimal route reflect data collection, evaluation, analysis, and reporting of results—activities that can be performed mentally or with pen and paper. Applicant’s characterization of the claim requiring large-scale historical-data processing and a particular reduction in computational overhead is not reflected in the language of the claims. Performing these steps using a computer merely automates what a person could do mentally or manually and does not transform the nature of the claim into a technological process. Any alleged technical improvement is not shown in the steps of the claims, which merely describe generic data collection, analysis, and reporting operations performed by a conventional computer system, processor, and memory. While Applicant argues the claims improve ride-hailing systems by reducing unnecessary route computations, any such benefit is directed to the collection and evaluation of ride information and the generation of route results rather than to an improvement in the functioning of the computer system, processor, memory, or other computer technology itself. The claims do not recite any particular improvement to processor operation, memory architecture, database structure, or other computer functionality. Applicant’s reliance on Enfish and Example 42 is not persuasive, as the claims do not recite a specific improvement to the functioning of the computer itself, but instead use the computer as a tool to perform the claimed ride-related data processing and route determination. Applicant’s reliance on BASCOM is not persuasive because the claimed arrangement does not recite a non-generic arrangement of computer components, but rather uses the recited processor and reference database to perform their ordinary functions in carrying out the claimed data processing. Applicant’s assertion that the claimed steps are unconventional does not, by itself, establish that the claims amount to significantly more than the judicial exception. Accordingly, the Examiner finds that the amended claims do not include additional elements that meaningfully integrate the judicial exception into a practical application or that amount to significantly more than the exception itself. The rejection under 35 U.S.C. 101 is therefore maintained for claims 1-14.
Applicant’s arguments with respect to claim(s) 1-6 and 8-13 under 35 U.S.C. 102 and claims 7 and 14 under 35 U.S.C. 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s arguments with respect to claims 3, 10, 5, and 12 have been fully considered but they are not persuasive.
Applicant argues that Chachra fails to disclose calculating a first set of estimated time and distance for walking from the starting location to each of the one or more alternate request locations, and a second set of estimated time and distance for a ride from each of the one or more alternate request locations to the destination location (See Applicant’s Remarks, page 19). The Examiner respectfully disagrees. Applicant argues that Chachra merely describes evaluating the pickup location score (PLoS) for each alternate request location and selecting a modified request location based on the evaluated PLoS and only describes the fitness of a pickup location for providers and does not involve any computation of walking time or distance from the requestor’s location to the alternate request locations. As set forth in the rejection, Chachra states that an estimated walking time to an alternate request location is determined, including an example in which the requestor has a “2 min ETA” to walk to the alternate request location (See paragraph [0051].) Chachra further discloses calculating a distance from the requested pickup location to the actual pickup location (See paragraph [0072].). Accordingly, Chachra discloses calculating an estimated walking time and distance between the requestor’s starting/request location and alternate pickup locations. Applicant further argues that Chachra fails to disclose any computation of ride time or ride distance from each alternate request location to the destination location, stating that the selection is independent of any route-based time or distance estimation and is based solely on suitability of the pickup location for providers. Applicant further states that Chachra fails to distinguish between different segments of travel, such as walking and riding, and does not compute separate estimated times or distances for such segments. As set forth in the rejection, Chachra states that navigation routes are mapped and determined with estimated travel times (See paragraph [0079].). The system determining routes for travel in connection with the alternate pickup locations, along with the associated estimated travel times, reasonably corresponds to calculating a second set of estimated time and distance for a ride from each of the one or more pickup points to the destination location.
Applicant argues that Chachra fails to disclose identifying an optimal route from among the one or more routes based on the shortest time or distance using the first and/or second sets of estimated times and distances (See Applicant’s Remarks, page 20). The Examiner respectfully disagrees. Applicant argues that Chachra merely discloses ranking alternate request locations based on a pickup location score, reflecting provider-centric suitability and failing to involve identifying an optimal route based on calculated time or distance. As set forth in the rejection, Chachra states the system maps a plurality of possible routes and selection of the fastest route reasonably corresponds to identifying an optimal route from the plurality of routes based on the shortest time using the estimated travel times. Applicant further argues that Chachra fails to disclose generating multiple routes or comparing such routes based on travel time or distance metrics, that the selection mechanism is independent of route optimization criteria such as shortest time or distance and depends on PLoS, and that the pickup location score used in Chachra cannot be equated to route optimization based on time or distance, as it does not involve evaluating route characteristics or travel segments. Again, as set forth in the rejection, Chachra states that the system maps a plurality of possible routes and selects the fastest route (See paragraph [0079].), which reasonably corresponds to the claimed identification of an optimal route based on shortest time. Further, the Examiner is not equating the pickup location score itself to route optimization; rather, Chachra separately discloses mapping multiple routes, generating estimated travel times, and selecting the fastest route. Accordingly, the rejections of claims 3, 5, 10, and 12 are maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In January, 2019 (updated October 2019), the USPTO released new examination guidelines setting forth a two-step inquiry for determining whether a claim is directed to non-statutory subject matter. According to the guidelines, a claim is directed to non-statutory subject matter if:
STEP 1: the claim does not fall within one of the four statutory categories of invention (process, machine, manufacture or composition of matter), or
STEP 2: the claim recites a judicial exception, e.g. an abstract idea, without reciting additional elements that amount to significantly more than the judicial exception, as determined using the following analysis:
STEP 2A (PRONG 1): Does the claim recite an abstract idea, law of nature, or natural phenomenon?
STEP 2A (PRONG 2): Does the claim recite additional elements that integrate the judicial exception into a practical application?
STEP 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
Using the two-step inquiry, it is clear that claims 1 and 8 are directed toward non-statutory subject matter, as shown below:
STEP 1: Do claims 1 and 8 fall within one of the statutory categories? Yes. The claims are directed toward a method including at least one step and an apparatus.
STEP 2A (PRONG 1): Is the claim directed to a law of nature, a natural phenomenon or an abstract idea? Yes, the claims are directed to an abstract idea.
With regard to STEP 2A (PRONG 1), the guidelines provide three groupings of subject matter that are considered abstract ideas:
Mathematical concepts – mathematical relationships, mathematical formulas or equations, mathematical calculations;
Certain methods of organizing human activity – fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions); and
Mental processes – concepts that are practicably performed in the human mind (including an observation, evaluation, judgment, opinion).
Claim 1. A method for adaptively identifying an optimal route, comprising:
receiving, by a processor, a request for a ride including a starting location and a destination location;
accessing, by the processor, a reference database to retrieve historical data associated with the starting location based on the received request;
determining, by the processor, one or more pick up points based on historical data, wherein the one or more pick up points represent candidate pick up points associated with the starting location;
filtering, by the processor, the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points;
determining, by the processor, one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request;
and adaptively identifying, by the processor, an optimal route from the one or more routes based on at least one of a cheapest route, fastest route, shortest route and shortest walking distance.
The method in claim 1, specifically the limitations emphasized above, is a mental process that can be practicably performed in the human mind and, therefore, an abstract idea. It merely consists of determining one or more pick up points, filtering the candidate pick up points, determining one or more routes, and adaptively identifying an optimal route. This is equivalent to a person mentally deciding pick up points, filtering pick up points, deciding routes, and determining the optimal route.
Claim 8. A system for adaptively identifying an optimal route, the system comprising: at least one processor;
and at least one memory including computer program code;
the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to:
receive a request for a ride including a starting location and a destination location;
access a reference database to retrieve historical data associated with the starting location based on the received request;
determine one or more pick up points based on the historical data, wherein the one or more pick up points represent candidate pick up points associated with the starting location;
filter the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points;
determine one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request;
and adaptively identify an optimal route from the one or more routes based on at least one of a cheapest route, fastest route, shortest route and shortest walking distance.
The method in claim 8, specifically the limitations emphasized above, is a mental process that can be practicably performed in the human mind and, therefore, an abstract idea. It merely consists of determining one or more pick up points, filtering the candidate pick up points, determining one or more routes, and adaptively identifying an optimal route. This is equivalent to a person mentally deciding pick up points, filtering pick up points, deciding routes, and determining the optimal route.
STEP 2A (PRONG 2): Does the claim recite additional elements that integrate the judicial exception into a practical application? No, the claims do not recite additional elements that integrate the judicial exception into a practical application.
With regard to STEP 2A (prong 2), whether the claim recites additional elements that integrate the judicial exception into a practical application, the guidelines provide the following exemplary considerations that are indicative that an additional element (or combination of elements) may have integrated the judicial exception into a practical application:
an additional element reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field;
an additional element that applies or uses a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition;
an additional element implements a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim;
an additional element effects a transformation or reduction of a particular article to a different state or thing; and
an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception.
While the guidelines further state that the exemplary considerations are not an exhaustive list and that there may be other examples of integrating the exception into a practical application, the guidelines also list examples in which a judicial exception has not been integrated into a practical application:
an additional element merely recites the words “apply it” (or an equivalent) with the judicial exception, or merely includes instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea;
an additional element adds insignificant extra-solution activity to the judicial exception; and
an additional element does no more than generally link the use of a judicial exception to a particular technological environment or field of use.
In the present case, the additional limitations beyond the above-noted abstract ideas are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the abstract “idea”).
Claim 1. A method for adaptively identifying an optimal route, comprising:
receiving, by a processor, a request for a ride including a starting location and a destination location;
accessing, by the processor, a reference database to retrieve historical data associated with the starting location based on the received request;
determining, by the processor, one or more pick up points based on historical data, wherein the one or more pick up points represent candidate pick up points associated with the starting location;
filtering, by the processor, the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points;
determining, by the processor, one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request;
and adaptively identifying, by the processor, an optimal route from the one or more routes based on at least one of a cheapest route, fastest route, shortest route and shortest walking distance.
Claim 1 does not recite any of the exemplary considerations that are indicative of an abstract idea having been integrated into a practical application. The steps of “receiving…a request for a ride…” and “accessing…a reference database…” are recited at a high level of generality and amount to mere data gathering, which is a form of extra solution activity. The limitations “by the processor” are claimed generically and are operating in their ordinary capacity such that they do not use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The processor merely describes how to generally “apply” the otherwise mental judgments in a generic or general purpose computing environment. The processor recited at a high level of generality and merely automates the determining and adaptively identifying steps. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. It should be noted that because the courts have made it clear that mere physicality or tangibility of an additional element or elements is not a relevant consideration in the eligibility analysis, the physical nature of these computer components does not affect this analysis. See MPEP 2106.05(I). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 8. A system for adaptively identifying an optimal route, the system comprising: at least one processor;
and at least one memory including computer program code;
the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to:
receive a request for a ride including a starting location and a destination location;
access a reference database to retrieve historical data associated with the starting location based on the received request;
determine one or more pick up points based on the historical data, wherein the one or more pick up points represent candidate pick up points associated with the starting location;
filter the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points;
determine one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request;
and adaptively identify an optimal route from the one or more routes based on at least one of a cheapest route, fastest route, shortest route and shortest walking distance.
Claim 8 does not recite any of the exemplary considerations that are indicative of an abstract idea having been integrated into a practical application. The steps of “receive a request for a ride…” and “access a reference database…” are recited at a high level of generality and amount to mere data gathering, which is a form of extra solution activity. The limitations “A system for adaptively identifying an optimal route, the system comprising: at least one processor”, “and at least one memory including computer program code”, and “the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to” are claimed generically and are operating in their ordinary capacity such that they do not use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The system comprising at least one processor and memory including computer program code merely describe how to generally “apply” the otherwise mental judgments in a generic or general purpose computing environment. The system comprising at least one processor and memory including computer program code are recited at a high level of generality and merely automate the determining and adaptively identifying steps. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. It should be noted that because the courts have made it clear that mere physicality or tangibility of an additional element or elements is not a relevant consideration in the eligibility analysis, the physical nature of these computer components does not affect this analysis. See MPEP 2106.05(I). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
STEP 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception? No, the claims do not recite additional elements that amount to significantly more than the judicial exception.
With regard to STEP 2B, whether the claims recite additional elements that provide significantly more than the recited judicial exception, the guidelines specify that the pre-guideline procedure is still in effect. Specifically, that examiners should continue to consider whether an additional element or combination of elements:
adds a specific limitation or combination of limitations that are not well-understood, routine, conventional activity in the field, which is indicative that an inventive concept may be present; or
simply appends well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, which is indicative that an inventive concept may not be present.
Regarding Step 2B of the 2019 PEG, independent claims 1 and 8 do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claims do not integrate the abstract idea into a practical application.
As discussed above with respect to integration of the abstract idea into a practical application, the additional limitation(s) of “by the processor”, “A system for adaptively identifying an optimal route, the system comprising: at least one processor”, “and at least one memory including computer program code”, and “the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to” is/are merely means to apply the exception and do not amount to “significantly more”, as adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 573 U.S. at 225-26, 110 USPQ2d at 1984, are not sufficient to amount to significantly more than the judicial exception.
Further, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B to determine if they are more than what is well-understood, routine, conventional activity in the field. The additional limitations of “receiving…a request for a ride…”, “accessing…a reference database…”, “receive a request for a ride…”, and “access a reference database…” are well-understood, routine, and conventional activities because the specification does not provide any indication that the acquiring and determining steps are performed using anything other than a conventional computer. See also MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures |, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TL! Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and O/P Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere performance of an action is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Hence, the claim is not patent eligible.
Thus, since claims 1 and 8 are: (a) directed toward an abstract idea, (b) do not recite additional elements that integrate the judicial exception into a practical application, and (c) do not recite additional elements that amount to significantly more than the judicial exception, it is clear that claims 1 and 8 are directed towards non-statutory subject matter.
Dependent claims 2-7 and 9-14 further limit the abstract idea without integrating the abstract idea into practical application or adding significantly more.
As such, claims 1-14 are rejected under 35 USC 101 as being drawn to an abstract idea without significantly more, and thus are ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
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.
Claim(s) 1-6, 8-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chachra (US 20240337497 A1) in view of Racah (US 20170314948 A1).
Regarding Claim 1, Chachra teaches A method for adaptively identifying an optimal route, comprising: receiving, by a processor, a request for a ride including a starting location and a destination location (See at least paragraph [0036], “The ride matching system (also referred to as a “dynamic transportation matching system”) 130 may identify available providers that are registered with the ride matching system 130 through an application on their provider communication device 150A. The ride matching system 130 may send the ride request to a provider communication device 150A and the provider 140A may accept the ride request through the provider communication device 150A”, paragraph [0065], “A requestor computing device 120 may include any device that is configured to communicate with a ride matching system 130 and/or provider computing device 150 over one or more communication networks 170. The requestor computing device 120 may comprise a processor, a computer-readable memory, and communication hardware and/or software to allow the requestor computing device 120 to communicate over one or more communication networks 170. For example, a requestor computing device 120 may include a mobile phone, a tablet, a smart watch, a laptop computer, a desktop computer, and/or any other suitable device having a processor, memory, and communication hardware. In some embodiments, the requestor computing device 120 may include a requestor application 121 that is configured to manage communications with the ride matching system 130 and interface with the user (i.e., requestor) of the requestor computing device 120. The requestor application 121 may allow a user to request a ride, monitor the status of a matched ride, pay for a ride, monitor past rides, perform any other requestor-oriented services related to the ride matching system 130, and/or obtain any other requestor-oriented information from the ride matching system 130”, and paragraph [0092], “FIG. 7 illustrates an exemplary flow diagram of a method for using curb segment data to provide an optimized pickup location, in accordance with embodiments of the present techniques. At step 702, the dynamic transportation matching system receives a ride request from a requestor computing device. The ride request may include data (e.g., transport request information) including a request location (i.e., pick-up location) for the ride request, a request destination (i.e., a drop-off location), a request time, a requestor identifier, a requestor computing device location, and/or any other relevant information associated with the ride request and/or requestor.”); accessing, by the processor, a reference database to retrieve historical data associated with the starting location based on the received request (See at least paragraph [0061], “FIG. 6 illustrates an example block diagram 600 of a ride matching system 130, in accordance with an embodiment of the present techniques. As described above, the ride matching system 130 may identify and facilitate request matching from requestors 110 associated with requestor computing devices 120 with available providers 140 associated with provider computing devices 150. The ride matching system 130 may include a requestor interface 131, a provider interface 132, and a ride matching module 133 including a travel tie estimation module 134B, and a provider selection module 135. The ride matching system 130 may also include a requestor information data store 136A, a provider information data store 136B, a historical ride data store 136C, and a navigation data store 136D which may be used by any of the modules of the ride matching system 130 to obtain information in order to perform the functionality of the corresponding module”, paragraph [0089], “A location scoring system 610 may be provided as a separate system or as part of the ride matching system 130, and vice versa. A location scoring module 612 may utilize various data stores that may be part of the location scoring system 610 and/or communicatively coupled with the location scoring system 610, such as historical ride data 136C. For example, historical ride data 136C may comprise a data set of requests and matched rides that have been serviced by the ride matching system 130 and/or any other third party ride data source. For instance, the historical ride data 136C may include any information received from a transport request (e.g., user identifiers for requestors, request location, destination location, a location of the requestor and provider when the request was made, etc.) and any information associated with the transport request (e.g., a current location of the provider and/or requestor as the ride matching process progresses, a result of the transport request (e.g., canceled, completed, etc.), feedback after the request is completed, the day, date, and time of the request, weather at the time of the request, and any other information that can be captured, stored, and tracked associated with the transport request). The location scoring module 612 may utilize the data as discussed earlier; for example, to determine pickup location scores for a request location as well as alternate request locations within a geographic area”, and paragraph [0091], “Further, the location scoring system 610 may maintain and process the pickup location scores for the available curb segment data periodically, upon a trigger, and/or using any other processing scheme such that the pickup location scores are ready to be provided for a request location upon a request being received for a request location. Alternatively and/or additionally, the pickup location scores may be generated upon a request being received using the historical ride data 136C.”); determining, by the processor, one or more pick up points based on the historical data, wherein the one or more pick up points represent candidate pick up points associated with the starting location (See at least paragraph [0040], “Similar to FIGS. 2A-2B, in the example 230 of FIG. 2C, there are a number of buildings 214 with roads 216 running between them and the person has requested a ride (e.g., transport) at a location 202 outside one of the buildings, with a similar destination (not shown) indicated in the request...The pickup location score threshold value may be determined based on historical data of previous pickup locations, time to pickup, time from pickup to start of ride, or other factors such as ease of navigation to the location, legality and safety of the location for the provider to pick up the requestor, historical reduced cancelations, historical numbers of successful pickups, etc. Thus a location having a score that meets the pickup location score threshold may indicate that the location is suitable for a pickup and likely to be successful”, paragraph [0041], “Curb segments associated with locations having moderate pickup location scores 240A-240F are shown in a second pattern (e.g., a dotted pattern). The locations or curb segments with moderate pickup location scores may meet a pickup location score threshold but may not be excellent locations for interactions between providers and requestors. The moderate pickup location scores may indicate that some delay and/or contacts between providers and requestors is probably for the matched request but that the delay is minimal or reasonable”, paragraph [0044], “As can be seen in FIG. 2C, the locations associated with the curb segments 240A-204F and 242A are better locations for the request. As such, the system may determine alternate request locations surrounding the request location and may determine pickup location scores associated with those curb segments and/or the specific alternate request locations. The pickup location scores associated with the surrounding curb segments may be identified and ranked to determine the best possible alternate request locations for the request”, and paragraph [0047], “As shown in FIG. 2C, the dynamic transportation matching system may identify a set of alternate request locations associated with one or more of the curb segments 238A-238M, 240A-240F, and 242A and may identify that a location associated with the curb sub-segment 242A is the best alternate request location for the request. As such, the dynamic transportation matching system may modify the request location 202 to the modified request location 226 and navigate the requestor to the modified request location 226. In this example, the request may travel around the block further than the example shown in FIG. 2B to meet the provider. Once the provider 206 picks up the requestor at the location 226, the provider 206 may continue with the route 222 to the destination (not shown).”); and adaptively identifying, by the processor, an optimal route from the one or more routes based on at least one of a cheapest route, fastest route, shortest route and shortest walking distance (See at least paragraph [0079], “The travel time estimation module 134B may map a plurality of possible routes from the provider location to the request location as well as the alternate request locations and generate an estimated arrival time for each of the potential mapped routes. The travel time estimation module 134B may select the fastest route and/or the most probable route for each of the providers and the corresponding estimated travel time for that route as the estimated travel time for the provider... Accordingly, the travel time estimation module 134B may determine a navigation route associated with the request location and an estimated travel time for each of the providers. Further, the estimated time may be determined through any suitable method including taking an average of multiple routes, selecting the fastest route, adding additional cushion time when certainty is low for the estimate of the time, etc.” The system selects the fastest route from multiple routes, thereby identifying an optimal route based on at least one of the fastest route.).
Chachra does not explicitly disclose, however, Racah, in the same field of endeavor, teaches filtering, by the processor, the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points (See at least Fig. 5, paragraph [0005], “In some embodiments, the selecting of each candidate virtual pickup bus stop into the subset of candidate virtual pickup bus stops is based, at least in part, on at least one of: i) a first walking distance, being a distance from the passenger-requested origin point to each candidate virtual pickup bus stop, ii) a second walking distance, being a distance from each candidate virtual dropoff bus stop to the passenger-requested destination point, iii) at least one first walking comfort condition associated with the first walking distance, the second walking distance, or both, iv) at least one first walking safety condition associated with a first walking route, being a route from the passenger-requested origin point to each candidate virtual pickup bus stop, v) at least one passenger well-being related factor, vi) at least one passenger personal preference related to at least one of: a walking distance, an expected time of arrival, a ride duration, a price, and any combination thereof, vii) at least one environment related factor, viii) a first cost assigned to each pair of a particular candidate virtual pickup bus stop and a particular candidate virtual dropoff bus stop, and ix) any combination thereof; and where the selecting of each candidate virtual dropoff bus stop into the subset of candidate virtual dropoff bus stops is based, at least in part, on at least one of: i) the first walking distance, the second walking distance, or both, ii) the sum of the first walking distance and the second walking distance, iii) the at least one walking comfort condition, iv) at least one second walking safety condition associated with a second walking route, being a route from each candidate virtual dropoff bus stop to the passenger-requested destination point, v) the at least one passenger well-being, related factor, vi) the at least one passenger personal preference, vii) the at least one environment related factor, viii) the first cost assigned to each pair of the particular candidate virtual pickup bus stop and the particular candidate virtual dropoff bus stop, and ix) any combination thereof”, paragraph [0060], “In some embodiments, the computer transportation systems of present invention are configured that the absolute walk has a length of 50-500 meters (m). In some embodiments, the computer transportation systems of present invention are configured such that the absolute walk has a length of 300-400 m. In some embodiments, the computer transportation systems of present invention are configured such that the absolute walk has a maximum length of 360 m”, and paragraph [0068], “For example, in an embodiment of the exemplary computer transportation system of the present invention, since 10th Avenue goes uptown, there's a virtual bus stop near the origin (0-40 m, depending on exact point of origin). 11th Avenue is 270 m away from 10th, and can also be used for uptown pickups. However, the “additional walk” to 11th is calculated relative to the walk to the nearest virtual bus stop (on 10th), and is above 180 m, so 11th Avenue would not be considered in this example. A 1-2 block walk is allowed along 10th if the car's route requires it (at 80 m per block, it's less than 180 m of additional walk).”); determining, by the processor, one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request (See at least paragraph [0048], “In some embodiments, the present invention includes computer transportation systems configured to identify a passenger-requested ride, where the exemplary computer transportation systems are configured to assign the ride to an available vehicle. In some embodiments, assigning a ride to an available vehicle includes at least one of the following activities: (1) determining a virtual bus stop for the new passenger's pickup, within reasonable walking range of the passenger-requested point of origin, (2) determining a virtual bus stop for the new passenger's drop off, within reasonable walking range of the passenger-requested destination, (3) adjusting the drop off points for passengers assigned to a vehicle, where the drop off points may only be adjusted and where pickup points are unchangeable once the exemplary computer transportation system delivers the pickup point to the passenger), (4) determining an order of pickups and drop offs, (5) determining a route between pickup and drop off points, or any combination thereof” and paragraph [0123]-[0126], “In some embodiments, the exemplary computer transportation system of the present invention can be configured to dynamically determine, in real-time, the fastest route that serves multiple passengers while observing spatial detour limits by utilizing, but not limited to, at least one of the following four steps: 1. Identify reasonable pickup and or drop-off virtual bus stops for at least a subset of passengers on the vehicle and or assigned to be picked up by vehicle; 2. Pre-filtering: for each task (pickup or dropoff), remove all stops that would cause an excessive detour (at this point, a virtual bus-stop is only removed from consideration if it necessarily causes a detour (no matter which bus-stops are selected for other tasks)); 3. Use at least one routing algorithm of the present invention described herein to calculate a route using virtual bus-stops that survived steps 1 and 2.”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the invention of Chachra with the teachings of Racah such that the system for determining alternate request locations for a ride request of Chachra is further configured to filter, by the processor, the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points and determine, by the processor, one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request, as taught by Racah (See paragraph [0005], [0048], [0060], [0068], [0123]-[0126].), with a reasonable expectation of success. The motivation for doing so would be minimizing the additional walking distance of the passenger, as taught by Racah (See paragraph [0015].).
Regarding Claim 2, Chachra and Racah teach The method of claim 1, as set forth in the obviousness rejection above. Chachra teaches wherein the historical data indicates a plurality of pick up points and location information for each of the plurality of pick up points, and determining the one or more pick up points further comprises selecting, from the plurality of pick up points, one or more pick up points that are in proximity to the starting location based on the location information (See at least paragraph [0049], “According to an embodiment, a number of alternate request locations 306, such as corresponding to curb segments within a particular area (e.g., within a threshold distance 304 of the request location 302) may be determined. According to an embodiment, a threshold distance 304 from the request location 302 may be determined along with a number of alternate request locations 306 within the threshold distance 304.” The system determines alternate request locations within a threshold distance of a request location, thereby selecting pickup points based on proximity to the starting location.).
With respect to claim 9, please see the rejection above with respect to claim 2, which is commensurate in scope to claim 9, with claim 2 being drawn to a method for adaptively identifying an optimal route and claim 9 being drawn to a corresponding system.
Regarding Claim 3, Chachra and Racah teach The method of claim 1, as set forth in the obviousness rejection above. Chachra teaches wherein determining the one or more routes further comprises calculating a first set of estimated time and distance for walking from the starting location to each of the one or more pick up points, and a second set of estimated time and distance for a ride from each of the one or more pick up points to the destination location (See at least paragraph [0051], “In an embodiment, a number of alternate request locations may be sampled within a range of the requested location and a best or most optimal alternate request location may be determined. For example, there may be a 5 minute ETA for the requestor's current requested location but 2 min ETA for the requestor to walk to an alternate request location around the block”, paragraph [0072], “The pickup evaluation module 134A may calculate a distance from the requested pickup location to the actual pickup location”, and paragraph [0079], “The travel time estimation module 134B may map a plurality of possible routes from the provider location to the request location as well as the alternate request locations and generate an estimated arrival time for each of the potential mapped routes…Accordingly, the travel time estimation module 134B may determine a navigation route associated with the request location and an estimated travel time for each of the providers.” The system estimates walking times from a request location to alternate pickup locations and calculates distances between the request location and the pickup locations, thereby providing a first set of estimated time and distance. The system further determines routes for travel from pickup locations, thereby providing a second set of estimated time and distance.).
With respect to claim 10, please see the rejection above with respect to claim 3, which is commensurate in scope to claim 10, with claim 3 being drawn to a method for adaptively identifying an optimal route and claim 10 being drawn to a corresponding system.
Regarding Claim 4, Chachra and Racah teach The method of claim 3, as set forth in the obviousness rejection above. Chachra teaches wherein the historical data indicates a plurality of drop off points and location information for each of the plurality of drop off points, and determining the one or more routes further comprises: determining one or more drop off points that are in proximity to the destination location based on the location information, determining the one or more routes comprising one or more routes between each of the determined one or more pick up points and each of the one or more determined drop off points (See at least paragraph [0040], “Similar to FIGS. 2A-2B, in the example 230 of FIG. 2C, there are a number of buildings 214 with roads 216 running between them and the person has requested a ride (e.g., transport) at a location 202 outside one of the buildings, with a similar destination (not shown) indicated in the request...The pickup location score threshold value may be determined based on historical data of previous pickup locations, time to pickup, time from pickup to start of ride, or other factors such as ease of navigation to the location, legality and safety of the location for the provider to pick up the requestor, historical reduced cancelations, historical numbers of successful pickups, etc. Thus a location having a score that meets the pickup location score threshold may indicate that the location is suitable for a pickup and likely to be successful”, paragraph [0079], “The travel time estimation module 134B may map a plurality of possible routes from the provider location to the request location as well as the alternate request locations and generate an estimated arrival time for each of the potential mapped routes…Accordingly, the travel time estimation module 134B may determine a navigation route associated with the request location and an estimated travel time for each of the providers”, and paragraph [0100], “In an embodiment, the other requestor may include a destination with their request different from the original requestor's destination. The provider's ETD to the new requestor's destination is determined, along with one or more alternate destination locations to the original requestor's destination. An ETD of the provider to the other requestor's destination from one of the alternate destination locations is determined, and if that ETD is less than the original ETD to the new requestor's original destination, then modified transport information including the alternate destination location is sent to the matched provider. For example, the original requestor is going to location A and the ETD is 5 minutes. The other requestor is going to location B and the ETD, including the travel to location B from location A (because the original requestor is being dropped off first) is 10 minutes. It is determined that location C is within a threshold distance of location A, and that the ETD for the other requestor with location C instead of location A is 7 minutes. If that three minute improvement is within the threshold amount, then location C is used as the dropoff point for the original requestor. In an embodiment, the original requestor's computing device will display mapping data including a navigation route from location C to location A (e.g., a walking route) along with an ETT for the original requestor to travel from location C to location A, and an indication is received of the original requestor's acceptance or denial of the change.” The system discloses one or more alternate destination locations, thereby providing a plurality of drop-off pints with associated location information, and further discloses that a selected drop-off point is within a threshold distance of a destination location, thereby determining one or more drop-off points in proximity to the destination location based on the location information. The system further maps routes and determines a navigation route, thereby determining one or more routes between each of the determined pickup points and drop-off points. As previously discussed, the system utilizes historical data in evaluating locations associated with a ride request.); and calculating the second set of estimated time and distance based on a ride from each of the one or more pick up points to each of the one or more determined drop off points (See at least paragraph [0072], “The pickup evaluation module 134A may calculate a distance from the requested pickup location to the actual pickup location” and paragraph [0079], “The travel time estimation module 134B may map a plurality of possible routes from the provider location to the request location as well as the alternate request locations and generate an estimated arrival time for each of the potential mapped routes…Accordingly, the travel time estimation module 134B may determine a navigation route associated with the request location and an estimated travel time for each of the providers.” The system further determines routes for travel from pickup locations to drop-off points, thereby providing a second set of estimated time and distance.).
With respect to claim 11, please see the rejection above with respect to claim 4, which is commensurate in scope to claim 11, with claim 4 being drawn to a method for adaptively identifying an optimal route and claim 11 being drawn to a corresponding system.
Regarding Claim 5, Chachra and Racah teach The method of claim 3, as set forth in the obviousness rejection above. Chachra teaches wherein identifying an optimal route further comprises identifying a route from the one or more routes with a shortest time or distance as the optimal route based on the first and/or second sets of estimated times and distances (See at least paragraph [0079], “The travel time estimation module 134B may map a plurality of possible routes from the provider location to the request location as well as the alternate request locations and generate an estimated arrival time for each of the potential mapped routes. The travel time estimation module 134B may select the fastest route and/or the most probable route for each of the providers and the corresponding estimated travel time for that route as the estimated travel time for the provider... Accordingly, the travel time estimation module 134B may determine a navigation route associated with the request location and an estimated travel time for each of the providers. Further, the estimated time may be determined through any suitable method including taking an average of multiple routes, selecting the fastest route, adding additional cushion time when certainty is low for the estimate of the time, etc.” The system maps a plurality of possible routes and selects the fastest route, thereby identifying a route from the one or more routes with a shortest time as the optimal route based on estimated travel times.).
With respect to claim 12, please see the rejection above with respect to claim 5, which is commensurate in scope to claim 12, with claim 5 being drawn to a method for adaptively identifying an optimal route and claim 12 being drawn to a corresponding system.
Regarding Claim 6, Chachra and Racah teach The method of claim 4, as set forth in the obviousness rejection above. Chachra teaches wherein determining the one or more routes further comprises calculating a third set of estimated time and distance for walking from each of the one or more drop off points to the destination location, and identifying an optimal route further comprises identifying a route from the one or more routes with a shortest time or distance as the optimal route based on the first, second and/or third sets of estimated times and distances (See at least paragraph [0079], “The travel time estimation module 134B may map a plurality of possible routes from the provider location to the request location as well as the alternate request locations and generate an estimated arrival time for each of the potential mapped routes. The travel time estimation module 134B may select the fastest route and/or the most probable route for each of the providers and the corresponding estimated travel time for that route as the estimated travel time for the provider... Accordingly, the travel time estimation module 134B may determine a navigation route associated with the request location and an estimated travel time for each of the providers. Further, the estimated time may be determined through any suitable method including taking an average of multiple routes, selecting the fastest route, adding additional cushion time when certainty is low for the estimate of the time, etc.” and paragraph [0100], “In an embodiment, the other requestor may include a destination with their request different from the original requestor's destination. The provider's ETD to the new requestor's destination is determined, along with one or more alternate destination locations to the original requestor's destination. An ETD of the provider to the other requestor's destination from one of the alternate destination locations is determined, and if that ETD is less than the original ETD to the new requestor's original destination, then modified transport information including the alternate destination location is sent to the matched provider. For example, the original requestor is going to location A and the ETD is 5 minutes. The other requestor is going to location B and the ETD, including the travel to location B from location A (because the original requestor is being dropped off first) is 10 minutes. It is determined that location C is within a threshold distance of location A, and that the ETD for the other requestor with location C instead of location A is 7 minutes. If that three minute improvement is within the threshold amount, then location C is used as the dropoff point for the original requestor. In an embodiment, the original requestor's computing device will display mapping data including a navigation route from location C to location A (e.g., a walking route) along with an ETT for the original requestor to travel from location C to location A, and an indication is received of the original requestor's acceptance or denial of the change.” The system further provides a walking route from a drop-off point to a destination location along with an estimated travel time, thereby teaching calculating a third set of estimated time and distance for walking from the drop-off point to the destination location. The system also selects the fastest route from a plurality of possible routes, thereby identifying an optimal route based on estimated travel times.).
With respect to claim 13, please see the rejection above with respect to claim 6, which is commensurate in scope to claim 13, with claim 6 being drawn to a method for adaptively identifying an optimal route and claim 13 being drawn to a corresponding system.
Regarding Claim 8, Chachra teaches A system for adaptively identifying an optimal route, the system comprising: at least one processor (See at least paragraph [0137], “FIG. 14 shows an example computer system 1400, in accordance with various embodiments. In various embodiments, computer system 1400 may be used to implement any of the systems, devices, or methods described herein. In some embodiments, computer system 1400 may correspond to any of the various devices described herein, including, but not limited, to mobile devices, tablet computing devices, wearable devices, personal or laptop computers, vehicle-based computing devices, or other devices or systems described herein. As shown in FIG. 14, computer system 1400 can include various subsystems connected by a bus 1402. The subsystems may include an I/O device subsystem 1404, a display device subsystem 1406, and a storage subsystem 1410 including one or more computer readable storage media 1408. The subsystems may also include a memory subsystem 1412, a communication subsystem 1420, and a processing subsystem 1422.”); and at least one memory including computer program code (See at least paragraph [0137], “FIG. 14 shows an example computer system 1400, in accordance with various embodiments. In various embodiments, computer system 1400 may be used to implement any of the systems, devices, or methods described herein. In some embodiments, computer system 1400 may correspond to any of the various devices described herein, including, but not limited, to mobile devices, tablet computing devices, wearable devices, personal or laptop computers, vehicle-based computing devices, or other devices or systems described herein. As shown in FIG. 14, computer system 1400 can include various subsystems connected by a bus 1402. The subsystems may include an I/O device subsystem 1404, a display device subsystem 1406, and a storage subsystem 1410 including one or more computer readable storage media 1408. The subsystems may also include a memory subsystem 1412, a communication subsystem 1420, and a processing subsystem 1422.”), the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to: receive a request for a ride including a starting location and a destination location (See at least paragraph [0036], “The ride matching system (also referred to as a “dynamic transportation matching system”) 130 may identify available providers that are registered with the ride matching system 130 through an application on their provider communication device 150A. The ride matching system 130 may send the ride request to a provider communication device 150A and the provider 140A may accept the ride request through the provider communication device 150A”, paragraph [0065], “A requestor computing device 120 may include any device that is configured to communicate with a ride matching system 130 and/or provider computing device 150 over one or more communication networks 170. The requestor computing device 120 may comprise a processor, a computer-readable memory, and communication hardware and/or software to allow the requestor computing device 120 to communicate over one or more communication networks 170. For example, a requestor computing device 120 may include a mobile phone, a tablet, a smart watch, a laptop computer, a desktop computer, and/or any other suitable device having a processor, memory, and communication hardware. In some embodiments, the requestor computing device 120 may include a requestor application 121 that is configured to manage communications with the ride matching system 130 and interface with the user (i.e., requestor) of the requestor computing device 120. The requestor application 121 may allow a user to request a ride, monitor the status of a matched ride, pay for a ride, monitor past rides, perform any other requestor-oriented services related to the ride matching system 130, and/or obtain any other requestor-oriented information from the ride matching system 130”, and paragraph [0092], “FIG. 7 illustrates an exemplary flow diagram of a method for using curb segment data to provide an optimized pickup location, in accordance with embodiments of the present techniques. At step 702, the dynamic transportation matching system receives a ride request from a requestor computing device. The ride request may include data (e.g., transport request information) including a request location (i.e., pick-up location) for the ride request, a request destination (i.e., a drop-off location), a request time, a requestor identifier, a requestor computing device location, and/or any other relevant information associated with the ride request and/or requestor”, and paragraph [0137], “FIG. 14 shows an example computer system 1400, in accordance with various embodiments. In various embodiments, computer system 1400 may be used to implement any of the systems, devices, or methods described herein. In some embodiments, computer system 1400 may correspond to any of the various devices described herein, including, but not limited, to mobile devices, tablet computing devices, wearable devices, personal or laptop computers, vehicle-based computing devices, or other devices or systems described herein. As shown in FIG. 14, computer system 1400 can include various subsystems connected by a bus 1402. The subsystems may include an I/O device subsystem 1404, a display device subsystem 1406, and a storage subsystem 1410 including one or more computer readable storage media 1408. The subsystems may also include a memory subsystem 1412, a communication subsystem 1420, and a processing subsystem 1422.”); access a reference database to retrieve historical data associated with the starting location based on the received request (See at least paragraph [0061], “FIG. 6 illustrates an example block diagram 600 of a ride matching system 130, in accordance with an embodiment of the present techniques. As described above, the ride matching system 130 may identify and facilitate request matching from requestors 110 associated with requestor computing devices 120 with available providers 140 associated with provider computing devices 150. The ride matching system 130 may include a requestor interface 131, a provider interface 132, and a ride matching module 133 including a travel tie estimation module 134B, and a provider selection module 135. The ride matching system 130 may also include a requestor information data store 136A, a provider information data store 136B, a historical ride data store 136C, and a navigation data store 136D which may be used by any of the modules of the ride matching system 130 to obtain information in order to perform the functionality of the corresponding module”, paragraph [0089], “A location scoring system 610 may be provided as a separate system or as part of the ride matching system 130, and vice versa. A location scoring module 612 may utilize various data stores that may be part of the location scoring system 610 and/or communicatively coupled with the location scoring system 610, such as historical ride data 136C. For example, historical ride data 136C may comprise a data set of requests and matched rides that have been serviced by the ride matching system 130 and/or any other third party ride data source. For instance, the historical ride data 136C may include any information received from a transport request (e.g., user identifiers for requestors, request location, destination location, a location of the requestor and provider when the request was made, etc.) and any information associated with the transport request (e.g., a current location of the provider and/or requestor as the ride matching process progresses, a result of the transport request (e.g., canceled, completed, etc.), feedback after the request is completed, the day, date, and time of the request, weather at the time of the request, and any other information that can be captured, stored, and tracked associated with the transport request). The location scoring module 612 may utilize the data as discussed earlier; for example, to determine pickup location scores for a request location as well as alternate request locations within a geographic area”, and paragraph [0091], “Further, the location scoring system 610 may maintain and process the pickup location scores for the available curb segment data periodically, upon a trigger, and/or using any other processing scheme such that the pickup location scores are ready to be provided for a request location upon a request being received for a request location. Alternatively and/or additionally, the pickup location scores may be generated upon a request being received using the historical ride data 136C.”); determine one or more pick up points based on the historical data, wherein the one or more pick up points represent candidate pick up points associated with the starting location (See at least paragraph [0040], “Similar to FIGS. 2A-2B, in the example 230 of FIG. 2C, there are a number of buildings 214 with roads 216 running between them and the person has requested a ride (e.g., transport) at a location 202 outside one of the buildings, with a similar destination (not shown) indicated in the request...The pickup location score threshold value may be determined based on historical data of previous pickup locations, time to pickup, time from pickup to start of ride, or other factors such as ease of navigation to the location, legality and safety of the location for the provider to pick up the requestor, historical reduced cancelations, historical numbers of successful pickups, etc. Thus a location having a score that meets the pickup location score threshold may indicate that the location is suitable for a pickup and likely to be successful”, paragraph [0041], “Curb segments associated with locations having moderate pickup location scores 240A-240F are shown in a second pattern (e.g., a dotted pattern). The locations or curb segments with moderate pickup location scores may meet a pickup location score threshold but may not be excellent locations for interactions between providers and requestors. The moderate pickup location scores may indicate that some delay and/or contacts between providers and requestors is probably for the matched request but that the delay is minimal or reasonable”, paragraph [0044], “As can be seen in FIG. 2C, the locations associated with the curb segments 240A-204F and 242A are better locations for the request. As such, the system may determine alternate request locations surrounding the request location and may determine pickup location scores associated with those curb segments and/or the specific alternate request locations. The pickup location scores associated with the surrounding curb segments may be identified and ranked to determine the best possible alternate request locations for the request”, and paragraph [0047], “As shown in FIG. 2C, the dynamic transportation matching system may identify a set of alternate request locations associated with one or more of the curb segments 238A-238M, 240A-240F, and 242A and may identify that a location associated with the curb sub-segment 242A is the best alternate request location for the request. As such, the dynamic transportation matching system may modify the request location 202 to the modified request location 226 and navigate the requestor to the modified request location 226. In this example, the request may travel around the block further than the example shown in FIG. 2B to meet the provider. Once the provider 206 picks up the requestor at the location 226, the provider 206 may continue with the route 222 to the destination (not shown).”); and adaptively identify an optimal route from the one or more routes based on at least one of a cheapest route, fastest route, shortest route and shortest walking distance (See at least paragraph [0079], “The travel time estimation module 134B may map a plurality of possible routes from the provider location to the request location as well as the alternate request locations and generate an estimated arrival time for each of the potential mapped routes. The travel time estimation module 134B may select the fastest route and/or the most probable route for each of the providers and the corresponding estimated travel time for that route as the estimated travel time for the provider... Accordingly, the travel time estimation module 134B may determine a navigation route associated with the request location and an estimated travel time for each of the providers. Further, the estimated time may be determined through any suitable method including taking an average of multiple routes, selecting the fastest route, adding additional cushion time when certainty is low for the estimate of the time, etc.” The system selects the fastest route from multiple routes, thereby identifying an optimal route based on at least one of the fastest route.).
Chachra does not explicitly disclose, however, Racah, in the same field of endeavor, teaches filter the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points (See at least Fig. 5, paragraph [0005], “In some embodiments, the selecting of each candidate virtual pickup bus stop into the subset of candidate virtual pickup bus stops is based, at least in part, on at least one of: i) a first walking distance, being a distance from the passenger-requested origin point to each candidate virtual pickup bus stop, ii) a second walking distance, being a distance from each candidate virtual dropoff bus stop to the passenger-requested destination point, iii) at least one first walking comfort condition associated with the first walking distance, the second walking distance, or both, iv) at least one first walking safety condition associated with a first walking route, being a route from the passenger-requested origin point to each candidate virtual pickup bus stop, v) at least one passenger well-being related factor, vi) at least one passenger personal preference related to at least one of: a walking distance, an expected time of arrival, a ride duration, a price, and any combination thereof, vii) at least one environment related factor, viii) a first cost assigned to each pair of a particular candidate virtual pickup bus stop and a particular candidate virtual dropoff bus stop, and ix) any combination thereof; and where the selecting of each candidate virtual dropoff bus stop into the subset of candidate virtual dropoff bus stops is based, at least in part, on at least one of: i) the first walking distance, the second walking distance, or both, ii) the sum of the first walking distance and the second walking distance, iii) the at least one walking comfort condition, iv) at least one second walking safety condition associated with a second walking route, being a route from each candidate virtual dropoff bus stop to the passenger-requested destination point, v) the at least one passenger well-being, related factor, vi) the at least one passenger personal preference, vii) the at least one environment related factor, viii) the first cost assigned to each pair of the particular candidate virtual pickup bus stop and the particular candidate virtual dropoff bus stop, and ix) any combination thereof”, paragraph [0060], “In some embodiments, the computer transportation systems of present invention are configured that the absolute walk has a length of 50-500 meters (m). In some embodiments, the computer transportation systems of present invention are configured such that the absolute walk has a length of 300-400 m. In some embodiments, the computer transportation systems of present invention are configured such that the absolute walk has a maximum length of 360 m”, and paragraph [0068], “For example, in an embodiment of the exemplary computer transportation system of the present invention, since 10th Avenue goes uptown, there's a virtual bus stop near the origin (0-40 m, depending on exact point of origin). 11th Avenue is 270 m away from 10th, and can also be used for uptown pickups. However, the “additional walk” to 11th is calculated relative to the walk to the nearest virtual bus stop (on 10th), and is above 180 m, so 11th Avenue would not be considered in this example. A 1-2 block walk is allowed along 10th if the car's route requires it (at 80 m per block, it's less than 180 m of additional walk).”); determine one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request (See at least paragraph [0048], “In some embodiments, the present invention includes computer transportation systems configured to identify a passenger-requested ride, where the exemplary computer transportation systems are configured to assign the ride to an available vehicle. In some embodiments, assigning a ride to an available vehicle includes at least one of the following activities: (1) determining a virtual bus stop for the new passenger's pickup, within reasonable walking range of the passenger-requested point of origin, (2) determining a virtual bus stop for the new passenger's drop off, within reasonable walking range of the passenger-requested destination, (3) adjusting the drop off points for passengers assigned to a vehicle, where the drop off points may only be adjusted and where pickup points are unchangeable once the exemplary computer transportation system delivers the pickup point to the passenger), (4) determining an order of pickups and drop offs, (5) determining a route between pickup and drop off points, or any combination thereof” and paragraph [0123]-[0126], “In some embodiments, the exemplary computer transportation system of the present invention can be configured to dynamically determine, in real-time, the fastest route that serves multiple passengers while observing spatial detour limits by utilizing, but not limited to, at least one of the following four steps: 1. Identify reasonable pickup and or drop-off virtual bus stops for at least a subset of passengers on the vehicle and or assigned to be picked up by vehicle; 2. Pre-filtering: for each task (pickup or dropoff), remove all stops that would cause an excessive detour (at this point, a virtual bus-stop is only removed from consideration if it necessarily causes a detour (no matter which bus-stops are selected for other tasks)); 3. Use at least one routing algorithm of the present invention described herein to calculate a route using virtual bus-stops that survived steps 1 and 2.”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the invention of Chachra with the teachings of Racah such that the system for determining alternate request locations for a ride request of Chachra is further configured to filter the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points and determine one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request, as taught by Racah (See paragraph [0005], [0048], [0060], [0068], [0123]-[0126].), with a reasonable expectation of success. The motivation for doing so would be minimizing the additional walking distance of the passenger, as taught by Racah (See paragraph [0015].).
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chachra (US 20240337497 A1) in view of Racah (US 20170314948 A1) and Tolkin (US 20170169535 A1).
Regarding Claim 7, Chachra and Racah teach The method of claim 1, as set forth in the obviousness rejection above. Chachra and Racah do not explicitly disclose, however, Tolkin, in the same field of endeavor, teaches wherein determining the one or more routes further comprises calculating an estimated price for a ride from each of the one or more pick up points to the destination location, and identifying an optimal route further comprises identifying a route from the one or more routes with a cheapest price as the optimal route based on the estimated prices (See at least paragraph [0043], “To identify a suggested pickup location for the trip, the eligible pickup locations for are scored 335 for each provider. To score 335 the eligible pickup locations, the pickup location module 145 determines the total cost of travel for each pickup location. The cost of travel for a pickup location is evaluated based on the estimated time to reach the pickup location from the provider's current location (ETA), and the estimated time to reach the destination from the pickup location (ETD). The cost of travel may be determined by the routing module 155. These travel costs may account for the direction of travel of the provider at the time of the request, traffic conditions, and other routing conditions.” The system determines a cost of travel for each pickup location and selects a lowest-cost option, and price represents a cost metric for route selection.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the invention of Chachra with the teachings of Racah and Tolkin such that the system for determining alternate request locations for a ride request of Chachra is further configured to filter, by the processor, the candidate pick up points based on at least one threshold associated with walking distance or walking time to obtain one or more filtered pickup points and determine, by the processor, one or more routes between each of the one or more filtered pick up points and the destination location indicated in the ride request, as taught by Racah (See paragraph [0005], [0048], [0060], [0068], [0123]-[0126].), and wherein determining the one or more routes further comprises calculating an estimated price for a ride from each of the one or more pick up points to the destination location, and identifying an optimal route further comprises identifying a route from the one or more routes with a cheapest price as the optimal route based on the estimated prices, as taught by Tolkin (See paragraph [0043].), with a reasonable expectation of success. The motivation for doing so would be minimizing the additional walking distance of the passenger, as taught by Racah (See paragraph [0015].), and reducing distance and time spent traveling by the provider, reducing the time the client has to wait, and improve the effiency of the network service, as taught by Tolkin (See paragraph [0003].).
With respect to claim 14, please see the rejection above with respect to claim 7, which is commensurate in scope to claim 14, with claim 7 being drawn to a method for adaptively identifying an optimal route and claim 14 being drawn to a corresponding system.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEWEL ASHLEY KUNTZ whose telephone number is (571)270-5542. The examiner can normally be reached M-F 8:30am-5:30pm.
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, Anne Antonucci can be reached at (313) 446-6519. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JEWEL A KUNTZ/Examiner, Art Unit 3666
/ANNE MARIE ANTONUCCI/Supervisory Patent Examiner, Art Unit 3666
Prosecution Insights