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 .
Claims 1-20 are currently pending.
The official correspondence below is a first action non-final.
Priority
Applicant’s claim for the benefit of a prior-filed application, 16/985,656, is acknowledged.
No foreign priority has been claimed.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06-14-2024, 10-25-2024, 02-20-2025, and 07-10-2025 have been considered by the examiner.
Drawings
The drawings submitted on 06-11-2024 have been considered by the examiner.
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.
CLAIM 1 (CLAIMS 9 AND 15 PARALLEL IN SCOPE AND SPIRIT TO METHOD CLAIM 1) IS REJECTED under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis – Step 1
Claim 1 is directed to a method (i.e., a process) for organizing ride-sharing/driver designation. Therefore, claim 1 is within at least one of the four statutory categories.
101 Analysis – Step 2A, Prong I
Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claim 1 includes limitations that recite an abstract idea (emphasized below in bold text) and will be used as a representative claim for the remainder of the 101 rejection.
Claim 1 Recites:
(Currently Amended) A computer-implemented method comprising:
determining a number of slots for a prioritized transportation dispatch mode based on historical transportation dispatch data for a geographical area;
transmitting, based on the number of slots, digital notifications to a first set of provider devices from a pool of provider devices for joining the prioritized transportation dispatch mode;
based on user interactions with the digital notifications, identifying a prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode;
in response to receiving a transportation request from a requestor device, selecting, utilizing a provider device dispatch algorithm, a provider device from the pool of provider devices for the transportation request by applying, via the provider device dispatch algorithm, one or more prioritization metrics to the prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode relative to other provider devices in the pool of provider devices; and
transmitting the transportation request to the provider device with navigation instructions for navigating the provider device to a pickup location corresponding to the transportation request.
The examiner submits that the foregoing bolded limitation(s) constitute a “mental process” because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. For example, the first recited mental step, “determining a number of slots for a prioritized transportation dispatch mode based on historical transportation dispatch data for a geographical area” in the context of this claim encompasses a person (driver or dispatcher) observing historical data of local events (e.g., sporting, concert, festival, and the like) and anticipating a surge in ride-share demand for current or future events based upon historical demand for same/similar events, and further determining a required expansion of service providers/drivers. Accordingly, the claim recites at least one abstract idea. Further, the second recited mental step, “based on user interactions with the digital notifications, identifying …”. In the context of the claim, a cpu is curating a list of providers to respond to the event based on programmed criteria (online activity/availability, proximity, etc.). Which, the examiner respectfully submits, is within the limitations of the human mind.
101 Analysis – Step 2A, Prong II
Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
Claim 1 Recites:
(Currently Amended) A computer-implemented method comprising:
determining a number of slots for a prioritized transportation dispatch mode based on historical transportation dispatch data for a geographical area;
transmitting, based on the number of slots, digital notifications to a first set of provider devices from a pool of provider devices for joining the prioritized transportation dispatch mode;
based on user interactions with the digital notifications, identifying a prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode;
in response to receiving a transportation request from a requestor device, selecting, utilizing a provider device dispatch algorithm, a provider device from the pool of provider devices for the transportation request by applying, via the provider device dispatch algorithm, one or more prioritization metrics to the prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode relative to other provider devices in the pool of provider devices; and
transmitting the transportation request to the provider device with navigation instructions for navigating the provider device to a pickup location corresponding to the transportation request.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitations of “transmitting” and “transmitting” the examiner submits that these limitations are insignificant extra-solution activities that use a computer (see preamble) to perform the process. Further, “in response to receiving a transportation request from a requestor device, selecting …” is an expansion of the determining step, wherein after the determination has been made, a transition to the automated transmission step is made. In particular, relaying user requests (user input digital notification) to providers, is a form of insignificant extra-solution activity. The displaying step on display/console/interface is also recited at a high level of generality, and amounts to post solution displaying, which is a form of insignificant extra-solution activity. Lastly, a computer or algorithm describes how to generally “apply” the otherwise mental judgements/evaluations in a generic or general purpose computing environment. Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application that is significantly more the claimed mental process based on historical data.
Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use 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 not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
101 Analysis – Step 2B
Regarding Step 2B of the 2019 PEG, representative independent claim 1 does 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 claim does 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 element of using a backend computer to perform the evaluating amounts to applying the exception using a generic computer. Generally applying an exception using a generic computer cannot provide an inventive concept. And as discussed above, the additional limitations are insignificant extra-solution activities. Further, a conclusion that an additional element is insignificant extra-solution (pre/post) activity in Step 2A should be re-evaluated in Step 2B to determine if they are more than what is wellunderstood, routine, conventional activity in the field. The additional limitations are well-understood, routine, and conventional activities because the background recites that the first transmission is from a user device (i.e., phone), the second transmission is from a dispatching computer, and the specification does not provide any indication that the computer is anything other than a conventional computer associated with a cloud computing model. MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures I, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner. The additional limitation of “displaying” is a well-understood, routine, and conventional activity because the Federal Circuit in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying of data is a well understood, routine, and conventional function. Hence, claim 1 is not patent eligible.
Dependent claim(s) 2-8 do not recite any further limitations that cause the claim(s) to be patent eligible. Rather, the limitations of dependent claims are directed toward additional aspects of the judicial exception, an expansion on how the mental process is applied via a cloud computer, and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application. Therefore, dependent claims 2-8 are not patent eligible under the same rationale as provided for in the rejection of claim 1.
Therefore, claim(s) 1-9 is/are ineligible under 35 USC §101. Further, independent claims 9 and 15 are parallel to claim 1 and are rejected under the same rationale. Further still, dependent claim 10-14 and 16-20 do not recite any further limitations that cause the claim(s) to be patent eligible. Rather, the limitations of dependent claims are directed toward additional aspects of the judicial exception, an expansion on how the mental process is applied via a cloud computer, and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application. Therefore, dependent claims 10-14 and 16-20 are not patent eligible under the same rationale as provided for in the rejection of claims 1, 9, and 15.
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.
Claim(s) 1-7 and 9-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Marco (US 20180322420 A1) in view of Neubecker (US 20160018230 A1) in further view of Sweeney (US 20150161564 A1).
REGARDING CLAIM 1, Marco discloses, determining a number of slots for a prioritized transportation dispatch mode (Marco: [0113] if the level of service provided is a low priority, then the number of minimum fare offers and/or minimum fare amounts may be determined in order to maximize the revenue delta ... if the level of service provided is a high priority, then the number of minimum fare offers and/or minimum fare amounts may be determined to maximize the level of service, meet a threshold service level, or otherwise improve the level of service relative to the service expected to be provided by the baseline driver supply) based on historical transportation dispatch data for a geographical area (Marco: [0039] include concerts, sporting events (e.g., baseball, football, soccer, basketball, hockey, boxing, or other sports), parades, airplane arrivals, community gatherings, or other suitable gatherings. A record for an event stored by the social network system may include; [0064-0065] a predicted timeline of how many requests ... more accurately predict the same for upcoming or ongoing events; [0092-0094] the estimated passenger demand for a zone may be based on one or more events in the zone or a nearby zone ...); transmitting, based on the number of slots, digital notifications to a first set of provider devices from a pool of provider devices for joining the prioritized transportation dispatch mode (Marco: [0092-0094] (examiner: expanding-contract providers based upon demand, efficiency metrics); [0108] the average minimum fare offered may also rise to entice drivers to accept minimum fare offers ... various threshold levels of a supply and demand metric may correspond to various numbers of minimum fare offers or the magnitude of a metric indicating ...; [0111] the magnitude of an upward adjustment may be based on the extent to which passenger demand is greater than driver supply (e.g., the minimum fare amounts may be increased in times of heavy demand in order to entice drivers to accept the minimum fare offers); [0113-0114] determine which drivers will be the recipients of the minimum fare offers ... drivers may be selected for minimum fare offers based on historical records; [0116] In a particular embodiment, backend server 302 may determine a target number of drivers to add to the baseline driver supply and may then determine the number of minimum fare offers sent based on the target number of drivers and an expected acceptance rate (e.g., based on historical minimum fare offer data)); based on user interactions with the digital notifications, identifying a prioritized subset of the first set of provider devices (Marco: [0014] a passenger application runs on passenger computing devices 104. The application may allow a user to enter various account information ... car preference information (e.g., what models or color of car the user prefers) ... [0015] The user may also specify whether the request is for immediate pick-up or for a specified time in the future. In various embodiments, the user may specify pick-up by a vehicle that has particular merchandise available for use by the user, such as a specified type of battery charger, bottle of water or other food or beverage, umbrella, or other suitable merchandise. The user may also specify criteria for the driver, such as a minimum performance rating, such that drivers having performance ratings below the minimum performance rating will not be considered during selection of the driver ... [0016] The user may use the application to order a ride based on the specified information. The request for the ride is generated based on the information and transmitted to backend system 116. Backend system 116 will facilitate the selection of a driver) in the prioritized transportation dispatch mode (Marco: [0011] Various embodiments of the present disclosure may enhance the experience of passengers and drivers associated with a transportation service by offering drivers incentives to service transportation requests from the transportation service during a particular time period (e.g., during rush hour or other busy period)); in response to receiving a transportation request from a requestor device (Marco: [0113-0114]), selecting, utilizing a provider device dispatch algorithm, a provider device from the pool of provider devices for the transportation request (Marco: [0113-0114]) by applying, via the provider device dispatch algorithm, one or more prioritization metrics to the prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode (Marco: [ABS] based on one or more metrics indicative of passenger demand and driver supply associated with a transportation service; [0014] a passenger application runs on passenger computing devices 104. The application may allow a user to enter various account information ... car preference information (e.g., what models or color of car the user prefers) ... [0015] The user may also specify whether the request is for immediate pick-up or for a specified time in the future. In various embodiments, the user may specify pick-up by a vehicle that has particular merchandise available for use by the user, such as a specified type of battery charger, bottle of water or other food or beverage, umbrella, or other suitable merchandise. The user may also specify criteria for the driver, such as a minimum performance rating, such that drivers having performance ratings below the minimum performance rating will not be considered during selection of the driver ... [0016] The user may use the application to order a ride based on the specified information. The request for the ride is generated based on the information and transmitted to backend system 116. Backend system 116 will facilitate the selection of a driver ... backend system 116 may select a driver based on any suitable factors, such as the information contained in the request from the passenger, the proximity of the driver to the passenger, or other suitable factors) relative to other provider devices in the pool of provider devices (Marco: [0015] The user may also specify criteria for the driver, such as a minimum performance rating, such that drivers having performance ratings below the minimum performance rating will not be considered during selection of the driver); and transmitting the transportation request to the provider device (Marco: [0113-0114] backend server 302 may determine which drivers will be the recipients of the minimum fare offers. In particular embodiments, when determining which drivers will be the recipients of the minimum fare offers for a particular zone, the backend server 302 may limit the sending of offers to drivers located in the zone, drivers within a particular range of the zone, and/or drivers that are predicted to be located in the zone or within a particular range of the zone at the time the offer is to be sent (e.g., based on an analysis of a ride the driver is currently servicing) or the offer is to begin (e.g., an offer could be sent before the offer begins such as when a particular driver is nearing the end of a transportation request). In particular embodiments, drivers may be selected for minimum fare offers based on historical records) with navigation instructions for navigating the provider device (Marco: [0061] navigational data 324 may comprise map data that may be sent to passenger computing devices 104 and driver computing devices 108 to allow the devices to display maps and associated indicators (e.g., location of passenger(s), location of driver(s), desired routes, etc.)) to a pickup location corresponding to the transportation request (Marco: [0080] The backend server 302 may provide navigation information (e.g., the passenger's current location or other pickup location and directions to the current location or other pickup location) to the driver computing device 108 to direct the driver to the passenger's pickup location and subsequently to direct the driver to the passenger's destination location).
Marco does not explicitly recite the terminology filling a “number of slots”. However, Marco does disclose transmitting messages regarding expanding and contracting the number of providers based upon historical data, current events, and efficiency metrics. Which, the examiner respectfully submits, discloses awareness of current numbers and numbers needed to satisfy efficiency metrics or an anticipated surge in requests.
Marco does not explicitly recite the terminology “algorithm”. However, as discussed in the interview dated 03-09-2026, Marco (US 20180322420 A1) discloses using a set of rules and operations, implemented via a computing device (0032, 0036, 0125-0126) for problem solving or determining a solution. As stated previously, an algorithm is a process/series of operation performed by a CPU processor to solve a problem. Which, the examiner respectfully submits, is disclosed by the prior art.
However, in the alternative, and in the same field of endeavor, Neubecker discloses, via the provider device dispatch algorithm (Neubecker: [ABS] The processing device associates each desired destination with a priority, determines a destination order based on the associated priority and at least one predetermined factor; [0011] The navigation system 105 may be further configured to give preference to certain priority passengers. A passenger may purchase a priority pass. The destination information may indicate whether the user has purchased a priority pass. Moreover, the destination information may indicate the type of priority pass, including a one-time purchase or a subscription where every destination is a priority destination for a given amount of time (e.g., a week, a month, a year, etc.) or number of uses (e.g., 10 destinations, 20 destinations, etc.). The navigation system 105 may place destinations designated with a priority pass above destinations that have no such designation. In other words, the navigation system 105 may generate routes that generally direct the vehicle 100 to priority destinations ahead of non-priority destinations), for the benefit of generating a route to each desired destination in an order determined by best route and priority.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Marco to include algorithms taught by Neubecker. One of ordinary skill in the art would have been motivated to make this modification, with a reasonable expectation of success, in order to generating a route to each desired destination in an order determined by best route and priority.
Th examiner respectfully submits, Marco, as modified, discloses an “algorithm”.
However, alternatively, and in the same field of endeavor, Sweeney discloses, (Sweeney: [0068] As discussed above, once the pickup determination component 114 determines; [0128] FIG. 6A through FIG. 6C illustrate examples for implementation of a driver selection algorithm(s) in which driver/rider pairings are made with an optimization objective of minimizing time to pick up, according to one or more examples. While examples of FIG. 6A through FIG. 6C illustrate a relatively small number of riders and drivers, the examples provided are intended to illustrate application of the concepts described, and as such, the examples described with FIG. 6A through FIG. 6C can be extended in application to larger rider and driver pools), for the benefit of the computer system implements an optimization process to minimize an estimated time to pick up for at least one of the multiple transport requests.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by a modified Marco to include algorithms taught by Sweeney. One of ordinary skill in the art would have been motivated to make this modification, with a reasonable expectation of success, in order to generating a route to each desired destination in an order to the computer system implements an optimization process to minimize an estimated time to pick up for at least one of the multiple transport requests.
REGARDING CLAIM 2, Marco, as modified, remains as applied above to claim 1. Further, Marco also discloses, generating, utilizing a slot selection model, one or more efficiency improvement metrics (Marco: [ABS]; [0069]; [0118]) corresponding to one or more numbers of slots based on the historical transportation dispatch data (Marco: [0039]; [0064-0065]); and selecting the number of slots based on the one or more efficiency improvement metrics (Marco: [ABS]; [0069]; [0085]; [0092-0094] (examiner: discloses efficiency metrics and supply demand); [0118]).
REGARDING CLAIM 3, Marco, as modified, remains as applied above to claim 2. Further, Marco also discloses, determining a prioritized transportation mode compensation rate corresponding to the prioritized transportation dispatch mode (Marco: [ABS]; [0075]), wherein the prioritized transportation mode compensation rate is different than a transportation mode compensation rate corresponding to an additional transportation mode (Marco: [0086]); and generating a predicted provider device utilization metric corresponding to the prioritized transportation dispatch mode (Marco: [0114]).
REGARDING CLAIM 4, Marco, as modified, remains as applied above to claim 3. Further, Marco also discloses, generating the one or more efficiency improvement metrics (Marco: [0113]) from the predicted provider device utilization metric (Marco: [0065]; [0114]), the prioritized transportation mode compensation rate (Marco: see at least [0108-0114] enticing drivers to join by raising minimum fares for a predicted or real-time surge), and the transportation mode compensation rate (Marco: see at least [0108-0114] enticing drivers to join by raising minimum fares for a predicted or real-time surge).
REGARDING CLAIM 5, Marco, as modified, remains as applied above to claim 1. Further, Marco also discloses, generating, for a plurality of prioritized transportation dispatch mode algorithms, a plurality of transportation-mode value improvement metrics (Marco: [ABS]) corresponding to a plurality of numbers of slots (Marco: [0108]; [0111]).
REGARDING CLAIM 6, Marco, as modified, remains as applied above to claim 5. Further, Marco also discloses, selecting the number of slots (Marco: [ABS]; [0108]; [0111]; [0116]) and a corresponding prioritized dispatch mode algorithm, from the plurality of prioritized transportation dispatch mode algorithms (Marco: [ABS]; [0108]; [0111]), by comparing the plurality of transportation-mode value improvement metrics (Marco: [0072]; [0107-0110, 0113]).
REGARDING CLAIM 7, Marco, as modified, remains as applied above to claim 1. Further, Marco also discloses, determining performance metrics for the pool of provider devices (Marco: [0058]; [0106]; [0015-0116]); and selecting the first set of provider devices from the pool of provider devices by comparing the performance metrics (Marco: [0058]; [0106]; [0015-0116]).
REGARDING CLAIM 8, Marco, as modified, remains as applied above to claim 1. Further, Marco also discloses, applying a prioritization metric (Marco: [0058]; [0106]; [0015-0116]; see at least [0085-0086]).
Marco discloses applying a priority metric based on zone and service demand. However, Marco does not explicitly disclose priority based on a destination location prioritization metric or a provider device idle time prioritization metric to modify priority selection scores of the first set of provider devices relative to other provider devices.
However, in the same field of endeavor, Neubecker discloses, comprising at least one of a destination location prioritization metric or a provider device idle time prioritization metric to modify priority selection scores of the prioritized subset of the first set of provider devices relative to other provider devices in the pool of provider devices (Neubecker: [ABS]; [0011]), for the benefit of generating a route to each desired destination in an order determined by best route and priority.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Marco to include priority destinations taught by Neubecker. One of ordinary skill in the art would have been motivated to make this modification, with a reasonable expectation of success, in order to generate a route to each desired destination in an order determined by best route and priority.
REGARDING CLAIM 9, Marco discloses, A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause a computer device to (Marco: [0032-0036]): determining a number of slots for a prioritized transportation dispatch mode (Marco: [0113]) based on historical transportation dispatch data for a geographical area (Marco: [0039]; [0064-0065]; [0092-0094]); transmitting, based on the number of slots, digital notifications to a first set of provider devices from a pool of provider devices for joining the prioritized transportation dispatch mode (Marco: [0092-0094] (examiner: expanding-contract providers based upon demand, efficiency metrics); [0108]; [0111]; [0113-0114]; [0116]); based on user interactions with the digital notifications, identifying a prioritized subset of the first set of provider devices (Marco: [0039]; [0075]) in the prioritized transportation dispatch mode (Marco: [0011]); in response to receiving a transportation request from a requestor device (Marco: [0113-0114]), selecting, utilizing a provider device dispatch algorithm, a provider device from the pool of provider devices for the transportation request (Marco: [0113-0114]) by applying, via the provider device dispatch algorithm, one or more prioritization metrics to the prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode (Marco: [ABS]) relative to other provider devices in the pool of provider devices (Marco: [0015]); and transmitting the transportation request to the provider device (Marco: [0113-0114]) with navigation instructions for navigating the provider device (Marco: [0061]) to a pickup location corresponding to the transportation request (Marco: [0080]).
Marco does not explicitly recite the terminology filling a “number of slots”. However, Marco does disclose transmitting messages regarding expanding and contracting the number of providers based upon historical data, current events, and efficiency metrics. Which, the examiner respectfully submits, discloses awareness of current numbers and numbers needed to satisfy efficiency metrics or an anticipated surge in requests.
Marco does not explicitly recite the terminology “algorithm”. However, as discussed in the interview dated 03-09-2026, Marco (US 20180322420 A1) discloses using a set of rules and operations, implemented via a computing device (0032, 0036, 0125-0126) for problem solving or determining a solution. As stated previously, an algorithm is a process/series of operation performed by a CPU processor to solve a problem. Which, the examiner respectfully submits, is disclosed by the prior art.
However, in the alternative, and in the same field of endeavor, Neubecker discloses, via the provider device dispatch algorithm (Neubecker: [ABS]; [0011]), for the benefit of generating a route to each desired destination in an order determined by best route and priority.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Marco to include algorithms taught by Neubecker. One of ordinary skill in the art would have been motivated to make this modification, with a reasonable expectation of success, in order to generating a route to each desired destination in an order determined by best route and priority.
Th examiner respectfully submits, Marco, as modified, discloses an “algorithm”.
However, alternatively, and in the same field of endeavor, Sweeney discloses, (Sweeney: [0068]; [0128]), for the benefit of the computer system implements an optimization process to minimize an estimated time to pick up for at least one of the multiple transport requests.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by a modified Marco to include algorithms taught by Sweeney. One of ordinary skill in the art would have been motivated to make this modification, with a reasonable expectation of success, in order to generating a route to each desired destination in an order to the computer system implements an optimization process to minimize an estimated time to pick up for at least one of the multiple transport requests.
REGARDING CLAIM 10, Marco, as modified, remains as applied above to claim 9. Further, Marco also discloses, generating, utilizing a slot selection model, one or more efficiency improvement metrics (Marco: [ABS]; [0069]; [0118]) corresponding to one or more numbers of slots based on the historical transportation dispatch data (Marco: [0039]; [0064-0065]); and selecting the number of slots based on the one or more efficiency improvement metrics (Marco: [ABS]; [0069]; [0085]; [0092-0094]; [0118]).
REGARDING CLAIM 11, Marco, as modified, remains as applied above to claim 10. Further, Marco also discloses, determining a prioritized transportation mode compensation rate corresponding to the prioritized transportation dispatch mode (Marco: [ABS]; [0075]), wherein the prioritized transportation mode compensation rate is different than a transportation mode compensation rate corresponding to an additional transportation mode (Marco: [0086]); and generating a predicted provider device utilization metric corresponding to the prioritized transportation dispatch mode (Marco: [0114]).
REGARDING CLAIM 12, Marco, as modified, remains as applied above to claim 11. Further, Marco also discloses, generate the one or more efficiency improvement metrics (Marco: [0113]) from the predicted provider device utilization metric (Marco: [0065]; [0114]), the prioritized transportation mode compensation rate (Marco: see at least [0108-0114] enticing drivers to join by raising minimum fares for a predicted or real-time surge), and the transportation mode compensation rate (Marco: see at least [0108-0114] enticing drivers to join by raising minimum fares for a predicted or real-time surge).
REGARDING CLAIM 13, Marco, as modified, remains as applied above to claim 9. Further, Marco also discloses, generating, for a plurality of prioritized transportation dispatch mode algorithms, a plurality of transportation-mode value improvement metrics (Marco: [ABS]) corresponding to a plurality of numbers of slots (Marco: [0108]; [0111]).
REGARDING CLAIM 14, Marco, as modified, remains as applied above to claim 13. Further, Marco also discloses, selecting the number of slots (Marco: [ABS]; [0108]; [0111]; [0116]) and a corresponding prioritized dispatch mode algorithm, from the plurality of prioritized transportation dispatch mode algorithms (Marco: [ABS]; [0108]; [0111]), by comparing the plurality of transportation-mode value improvement metrics (Marco: [0072]; [0107-0110, 0113]).
REGARDING CLAIM 15, Marco discloses, at least one processor; and at least one non-transitory computer readable storage medium storing instructions that, when executed by the at least one processor, cause the system to (Marco: [0032-0036]): determining a number of slots for a prioritized transportation dispatch mode (Marco: [0113]) based on historical transportation dispatch data for a geographical area (Marco: [0039]; [0064-0065]; [0092-0094]); transmitting, based on the number of slots, digital notifications to a first set of provider devices from a pool of provider devices for joining the prioritized transportation dispatch mode (Marco: [0092-0094] (examiner: expanding-contract providers based upon demand, efficiency metrics); [0108]; [0111]; [0113-0114]; [0116]); based on user interactions with the digital notifications, identifying a prioritized subset of the first set of provider devices (Marco: [0039]; [0075]) in the prioritized transportation dispatch mode (Marco: [0011]); in response to receiving a transportation request from a requestor device (Marco: [0113-0114]), selecting, utilizing a provider device dispatch algorithm, a provider device from the pool of provider devices for the transportation request (Marco: [0113-0114]) by applying, via the provider device dispatch algorithm, one or more prioritization metrics to the prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode (Marco: [ABS]) relative to other provider devices in the pool of provider devices (Marco: [0015]); and transmitting the transportation request to the provider device (Marco: [0113-0114]) with navigation instructions for navigating the provider device (Marco: [0061]) to a pickup location corresponding to the transportation request (Marco: [0080]).
Marco does not explicitly recite the terminology filling a “number of slots”. However, Marco does disclose transmitting messages regarding expanding and contracting the number of providers based upon historical data, current events, and efficiency metrics. Which, the examiner respectfully submits, discloses awareness of current numbers and numbers needed to satisfy efficiency metrics or an anticipated surge in requests.
Marco does not explicitly recite the terminology “algorithm”. However, as discussed in the interview dated 03-09-2026, Marco (US 20180322420 A1) discloses using a set of rules and operations, implemented via a computing device (0032, 0036, 0125-0126) for problem solving or determining a solution. As stated previously, an algorithm is a process/series of operation performed by a CPU processor to solve a problem. Which, the examiner respectfully submits, is disclosed by the prior art.
However, in the alternative, and in the same field of endeavor, Neubecker discloses, via the provider device dispatch algorithm (Neubecker: [ABS]; [0011]), for the benefit of generating a route to each desired destination in an order determined by best route and priority.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Marco to include algorithms taught by Neubecker. One of ordinary skill in the art would have been motivated to make this modification, with a reasonable expectation of success, in order to generating a route to each desired destination in an order determined by best route and priority.
Th examiner respectfully submits, Marco, as modified, discloses an “algorithm”.
However, alternatively, and in the same field of endeavor, Sweeney discloses, (Sweeney: [0068]; [0128]), for the benefit of the computer system implements an optimization process to minimize an estimated time to pick up for at least one of the multiple transport requests.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by a modified Marco to include algorithms taught by Sweeney. One of ordinary skill in the art would have been motivated to make this modification, with a reasonable expectation of success, in order to generating a route to each desired destination in an order to the computer system implements an optimization process to minimize an estimated time to pick up for at least one of the multiple transport requests.
REGARDING CLAIM 16, Marco, as modified, remains as applied above to claim 15. Further, Marco also discloses, generating, utilizing a slot selection model, one or more efficiency improvement metrics (Marco: [ABS]; [0069]; [0118]) corresponding to one or more numbers of slots based on the historical transportation dispatch data (Marco: [0039]; [0064-0065]); and selecting the number of slots based on the one or more efficiency improvement metrics (Marco: [ABS]; [0069]; [0085]; [0092-0094]; [0118]).
REGARDING CLAIM 17, Marco, as modified, remains as applied above to claim 16. Further, Marco also discloses, determining a prioritized transportation mode compensation rate corresponding to the prioritized transportation dispatch mode (Marco: [ABS]; [0075]), wherein the prioritized transportation mode compensation rate is different than a transportation mode compensation rate corresponding to an additional transportation mode (Marco: [0086]); and generating a predicted provider device utilization metric corresponding to the prioritized transportation dispatch mode (Marco: [0114]).
REGARDING CLAIM 18, Marco, as modified, remains as applied above to claim 17. Further, Marco also discloses, generate the one or more efficiency improvement metrics (Marco: [0113]) from the predicted provider device utilization metric (Marco: [0065]; [0114]), the prioritized transportation mode compensation rate (Marco: see at least [0108-0114] enticing drivers to join by raising minimum fares for a predicted or real-time surge), and the transportation mode compensation rate (Marco: see at least [0108-0114] enticing drivers to join by raising minimum fares for a predicted or real-time surge).
REGARDING CLAIM 19, Marco, as modified, remains as applied above to claim 15. Further, Marco also discloses, generating, for a plurality of prioritized transportation dispatch mode algorithms, a plurality of transportation-mode value improvement metrics (Marco: [ABS]) corresponding to a plurality of numbers of slots (Marco: [0108]; [0111]).
REGARDING CLAIM 20, Marco, as modified, remains as applied above to claim 19. Further, Marco also discloses, selecting the number of slots (Marco: [ABS]; [0108]; [0111]; [0116]) and a corresponding prioritized dispatch mode algorithm, from the plurality of prioritized transportation dispatch mode algorithms (Marco: [ABS]; [0108]; [0111]), by comparing the plurality of transportation-mode value improvement metrics (Marco: [0072]; [0107-0110, 0113]).
Response to Arguments
Applicant's arguments filed 02-26-2026, beginning on page 11, have been fully considered but they are not persuasive.
To the examiner’s best understanding, the applicant has contended that the independent claims are significantly more than a drafting effort designed to monopolize the judicial exception. The examiner respectfully disagrees.
As stated above, to the examiner’s best understanding, claim 1 contains two mental steps that are well within the limitations of the human mind. First, determining or predicting a need based upon historical data is well within the limitations of the human mind. Second, making a second determination based upon more historical data in well within the limitations of the human mind. Lastly, transmitting, selecting who to transmit to after the determination step, and transmitting are all insignificant applications of tangential step that are pre and post solution, all automated with generic hardware, software, firmware. Therefore the examiner respectfully maintains the rejection of the independent claims under 35 USC §101, abstract idea, ineligible subject matter.
Applicant's arguments filed 02-26-2026, beginning on page 14, in regards to the rejection of the independent claims under 35 USC §103, obviousness, have been fully considered but they are not persuasive.
To the examiner’s best understanding, the applicant has contended that the prior art of record, specifically Marco (US 20180322420 A1), fails to disclose “determining a number of slots for a prioritized transportation dispatch mode based on historical transportation dispatch data for a geographical area; transmitting, based on the number of slots, digital notifications to a first set of provider devices from a pool of provider devices for joining the prioritized transportation dispatch mode; based on user interactions with the digital notifications, identifying a prioritized subset of the first set of provider devices in the prioritized transportation dispatch mode; in response to receiving a transportation request from a requestor device, selecting, utilizing a provider device dispatch algorithm, a provider device from the pool of provider devices for the transportation request relative to other provider devices in the pool of provider devices; and transmitting the transportation request to the provider device with navigation instructions for navigating the provider device to a pickup location corresponding to the transportation request”. The examiner respectfully disagrees.
As stated above, Marco discloses, determining a number of slots for a prioritized transportation dispatch mode (Marco: see [0113] high priority service levels) based on historical transportation dispatch data for a geographical area (Marco: see [0039], [0064-0065], [0092-0094] for historical data regarding rush hours zones, zones with events, airports, etc.); transmitting, based on the number of slots, digital notifications to a first set of provider devices from a pool of provider devices for joining the prioritized transportation dispatch mode (Marco: see at least [0092-0094] for expanding or contracting providers based upon demand and efficiency metrics); based on user interactions with the digital notifications, identifying a prioritized subset of the first set of provider devices (Marco: see at least [0014-0016] for selecting drivers based upon proximity and then by user preferences) in the prioritized transportation dispatch mode (Marco: to the examiner’s best understanding, the process is performed in all modes, but see at least [0011] for rush hour); in response to receiving a transportation request from a requestor device (Marco: see [0113-0114] for selecting and relaying request), selecting, utilizing a provider device dispatch algorithm, a provider device from the pool of provider devices for the transportation request (Marco: see [0113-0114] for selecting and relaying request), relative to other provider devices in the pool of provider devices (Marco: [0014-0016] for matching criteria); and transmitting the transportation request to the provider device (Marco: see [0113-0114] for selecting and relaying request) with navigation instructions for navigating the provider device (Marco: [0061] for driver map) to a pickup location corresponding to the transportation request (Marco: [0080] for driver going to passenger location).
While Marco (US 20180322420 A1) does not explicitly recite the terminology “determining a number of slots”, Marco dies disclose recognition for expanding or contracting number of providers based upon efficiency metrics. For example if two drivers are added and metrics determines that’s not enough, the system adds more until metrics determine that no more are needed. Which is determining a sufficient number of providers. Because the prior art of record discloses that which is claimed, the examiner respectfully maintains the rejection of the independent claims under 35 USC §103, obviousness.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hiyama (US 20160034845 A1)
O'Meara (US 20020077876 A1)
Demiralp (US 20230120345 A1)
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 AARRON SANTOS whose telephone number is (571)272-5288. The examiner can normally be reached Monday - Friday: 8:00am - 4: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, ANGELA ORTIZ can be reached at (571) 272-1206. 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.
/A.S./Examiner, Art Unit 3663
/ANGELA Y ORTIZ/Supervisory Patent Examiner, Art Unit 3663
Prosecution Insights