Detailed Action
Status of Claims
This action is a non-final, first office action in response to the claims filed on 10/04/2024.
Claims 1 – 20 are currently pending and have been examined.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted 10/11/2024 was filed before the mailing date of the final office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Novel/Nonobvious Subject Matter
Claim 18 is allowed over the prior art. In particular, Abbas et al. discloses resolving conflicting ride requests using various rules as outlined below, but fails to disclose the claimed functionality of “monitoring a performance of a multi-leg itinerary associated with the first allocation; storing log data descriptive of the performance in association with a platform identifier of a transportation platform that received the first allocation; and generating a quality measurement for the transportation platform based on the log data; wherein the request arbitration model is configured to generate the score for the corresponding request based on the quality measurement.” The remained of the cited references also fail to teach or render obvious the subject matter of dependent claim 18.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 1 – 18 are directed to a method (i.e., a process). Claim 19 is directed to a product. Claim 20 is directed to a machine (i.e., system). Therefore, claims 1 – 20 all fall within the one of the four statutory categories of invention.
Step 2A, Prong One
Independent claims 1, 19, & 20 substantially recite: accessing a first request for providing transportation along a first multi-leg transportation journey and a second request for providing transportation along a second multi-leg transportation journey, wherein the first request comprises first request data and the second request comprises second request data; querying, using the first request data and the second request data, a vehicle slot register to access data descriptive of unallocated vehicle slots for providing transportation services; computing, using a request arbitration model and based on the first request data, the second request data, and the data descriptive of unallocated vehicle slots, a first allocation for servicing the first request and a second allocation for servicing the second request, wherein the first request is prioritized over the second request; updating the vehicle slot register based on the first allocation and the second allocation; outputting a first response for the first request indicating the first allocation; and outputting a second response for the second request indicating the second allocation.
The limitations stated above are processes that, under the broadest reasonable interpretation, covers performance of the limitation in a business relation or commercial interaction. That is, the functions in the context of the claims encompass resolving conflicting transport requests. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in a commercial interaction, or while managing personal behavior or relationships or interactions between people, then it falls within the "Certain Methods of Organizing Human Activity" grouping of abstract ideas e.g., commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); and managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions). Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two
The judicial exception is not integrated into a practical application. Claims 1, 19, & 20, as a whole, amounts to merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent). Claim 1 does not recite any additional elements. Claim 19 recites the additional computer-related elements of: “one or more non-transitory computer-readable media storing instructions that are executable by one or more processors to cause a computing system to perform operations.” Claim 20 recites the additional computer-related elements of: “computing system,” “one or more processors,” and “one or more non-transitory computer-readable media storing instructions that are executable by the one or more processors to cause the computing system to perform operations.”
The additional elements of “one or more non-transitory computer-readable media storing instructions that are executable by one or more processors to cause a computing system to perform operations,” “computing system,” “one or more processors,” and “one or more non-transitory computer-readable media storing instructions that are executable by the one or more processors to cause the computing system to perform operations” are recited at a high-level of generality, such that, when viewed as whole/ordered combination, amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)).
Accordingly, these additional elements, when viewed as a whole/ordered combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to an abstract idea.
Step 2B
As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent). The same analysis applies here in Step 2B, i.e., merely invoking the generic components as a tool to perform the abstract idea or “apply it” (See MPEP 2106.05(f)) does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B.
Therefore, the additional elements of “one or more non-transitory computer-readable media storing instructions that are executable by one or more processors to cause a computing system to perform operations,” “computing system,” “one or more processors,” and “one or more non-transitory computer-readable media storing instructions that are executable by the one or more processors to cause the computing system to perform operations” fail to integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination, nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. There is no indication that the combination of elements, taken both individually and as an ordered combination, improves the functioning of a computer or improves any other technology. Thus, the claims are not patent eligible.
Furthermore, dependent claims 2 – 18 are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The additional element of “using a machine-learned model” in claim 5 is recited at a high-level of generality, such that, when viewed as whole/ordered combination, it amounts to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)). The additional elements of “first transportation platform computing system” and “second transportation platform computing system” in claim 13 are recited at a high-level of generality, such that, when viewed as whole/ordered combination, amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)). The additional element of “storing log data descriptive of the performance in association with a platform identifier of a transportation platform that received the first allocation” in claim 18 is recited at a high-level of generality, and when viewed as whole/ordered combination, amounts to insignificant extra-solution activity (See MPEP 2106.05(g)), and furthermore, is similar to functionality found by the courts to be well-understood, routine, and conventional activities (See MPEP § 2106.05(d)(II), noting “Electronic recordkeeping” and “Storing and retrieving information in memory”), and thus does not amount to significantly more.
The limitations of the claims, when considered both individually and as an ordered combination, do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea with generic computer components that conduct generic computer functions within a certain field of use, 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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1 – 4, 7 – 10, 15 – 16, & 19 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Abbas et al. (US 20180060827 A1) in view of Akselrod et al. (US 20180293521 A1).
As per Claim 1, Abbas discloses a method ([0018], [0085], & claim 1) for computing responses to transportation requests to efficiently deploy vehicle slots, the method comprising:
• accessing a first request for providing transportation along a first… transportation journey and a second request for providing transportation along a second… transportation journey, wherein the first request comprises first request data and the second request comprises second request data ([0053] – [0054] & [0098] – [0099], receiving requests (i.e., “calendar events”) from a first and second mobile device for transport to scheduled user events, comprising request data such as vehicle request data, time data, and location data. Also see [0024] & [0039], noting that the transport requests comprise request data such as “a position on a map where the first user would like to be picked up by the vehicle 102 at the starting location of the first user and/or at the location of the calendar event 202.”).
Abbas, as outlined above, discloses receiving transport requests for two users for a transportation journey to scheduled events. To the extent to which Abbas does not appear to explicitly disclose wherein requests can be for “multi-leg” transportation journeys, Akselrod, in at least [0020] – [0021], teaches receiving requests for rides for which “more than one segment is required” to complete the journey.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Akselrod in the invention of Abbas with the motivation to provide a system and method for “enabling passengers to travel longer distances by dynamically chaining shorter segments into one seamless trip,” as evidenced by Akselrod ([0009]).
Abbas further discloses:
• querying, using the first request data and the second request data, a vehicle slot register to access data descriptive of unallocated vehicle slots for providing transportation services (See [0055] – [0056] & [0099], noting querying “vehicle calendar 603” for information descriptive of unallocated vehicle slots “and compares the calendar data for the new vehicle request with previously stored calendar data.”);
• computing, using a request arbitration model and based on the first request data, the second request data, and the data descriptive of unallocated vehicle slots, a first allocation for servicing the first request and a second allocation for servicing the second request, wherein the first request is prioritized over the second request (See [0057] & [0059], noting that “conflict analyzer 604 determines if there are any direct conflicts between the new vehicle request and previously scheduled vehicle requests,” and uses “the rules created via the rules creator 128 of the user application 120, including default rules and/or calendar-event specific rules” to prioritize one transportation journey request over another, and the “vehicle arrival time field 212 is updated for each request to accommodate both requests based on data received from the scheduler 134” based on one transportation journey being “a high priority event.” Also see [0068] – [0070], & [0100] – [0103], noting that “the calendar event associated with the new vehicle request can be assigned a high event priority,” and that “the request confirmer 606 sends the user an adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134 in view of the vehicle schedule stored in the vehicle calendar 603 and the analysis performed by the conflict analyzer 604, the trip planner 608, and the vehicle locator 610. In such examples, the user application 120 populates the vehicle arrival time field 212 of the first example screen 200 with a proposed or alternative time” for one of the two requesting users (i.e., each request is allocated a slot with one given priority based on rules.);
• updating the vehicle slot register based on the first allocation and the second allocation ([0059], [0076], [0092], & [0107] – [0108], updating “the vehicle calendar 603” to add a new, conflicting request slot to the vehicle schedule while existing conflicting “vehicle requests have been rescheduled” in the “vehicle calendar 603.”);
• outputting a first response for the first request indicating the first allocation; and outputting a second response for the second request indicating the second allocation (See [0059], noting that “the new vehicle request created by the first user via the first mobile device 106 may be associated with a high priority event. In such examples, the request confirmer 606 transmits an alert to the second mobile device 108 to inform the second user that there is now a conflict with the second user's previously scheduled vehicle request. For example, the user application 120 of the second mobile device 108 can update the vehicle arrival time field 212 for the previously scheduled vehicle request (e.g., based on a vehicle arrival time received from the scheduler 134) and generate a notification for viewing by the second user. In other examples, the request confirmer 606 sends alerts to the first mobile device 106 and the second mobile device 108 if the vehicle arrival time field 212 is updated for each request to accommodate both requests based on data received from the scheduler 134)” (i.e., both user devices output respective vehicle slot allocations). Also see [0105] – [0106], noting that the “user application associated with the user devices used to generate the vehicle request displays the conflict settlement prompt(s) to alert the user(s) of conflicts between vehicles requests, changes in the arrival times of the vehicle.”).
As per claim 2, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses:
• wherein the first request and the second request present conflicting constraints for service, and wherein the first allocation and the second allocation resolve the conflict (See [0057] & [0059], noting that “conflict analyzer 604 determines if there are any direct conflicts between the new vehicle request and previously scheduled vehicle requests,” and uses “the rules created via the rules creator 128 of the user application 120, including default rules and/or calendar-event specific rules” to prioritize one transportation journey request over another, and the “vehicle arrival time field 212 is updated for each request to accommodate both requests based on data received from the scheduler 134” based on one transportation journey being “a high priority event.” Also see [0068] – [0070], & [0100] – [0103], noting that “the calendar event associated with the new vehicle request can be assigned a high event priority,” and that “the request confirmer 606 sends the user an adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134 in view of the vehicle schedule stored in the vehicle calendar 603 and the analysis performed by the conflict analyzer 604, the trip planner 608, and the vehicle locator 610. In such examples, the user application 120 populates the vehicle arrival time field 212 of the first example screen 200 with a proposed or alternative time” for one of the two requesting users (i.e., each request is allocated a slot with one given priority based on rules.).
As per claim 3, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses wherein computing the first allocation for servicing the first request and the second allocation for servicing the second request comprises:
• accessing real-time data associated with a first user for the first request, real-time data associated with a second user of the second request ([0046], accessing a current location of the users via GPS to be used as respective pickup locations and “estimated travel time for the vehicle 102 to reach the location” as per [0067].),
• and real-time performance data associated with the transportation services ([0062] – [0063], & [0090], accessing “a current location of the vehicle 102”),
• and computing the first allocation for servicing the first request and the second allocation for servicing the second request is based also on the real-time data associated with the first user, the real-time data associated with the second user, and the real-time performance data associated with the transportation services ([0062] – [0070], determining an “adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134” to “the vehicle arrival time field 212 of the first example screen 200 with a proposed or alternative time” for one of the requestors based on the travel time and the current location of the vehicle and starting points of each requestor (based on current GPS data).).
As per claim 4, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses:
• wherein the second allocation comprises a null allocation ([0058], “if the new vehicle request created by the first user via the first mobile device 106 is in direct conflict with a previously schedule vehicle request created by the second user via the second mobile device 108, the request confirmer 606 sends an alert to the user application 120 of the first mobile device 106 that the vehicle request is denied.”; [0069], an allocation for a conflicting request comprises “an indicator that the vehicle 102 is not available”; [0109], “If one or more of the vehicle requests in conflict are not rescheduled or grouped as a rideshare event, the example method 800 includes denying the one or more of the vehicle requests”).
As per claim 7, Abbas / Akselrod discloses the limitations of claim 2. Abbas further discloses:
• wherein the first allocation satisfies the constraints of the first request (See [0057] & [0059], noting that a first request is prioritized based on the rules: “conflict analyzer 604 determines if there are any direct conflicts between the new vehicle request and previously scheduled vehicle requests,” and uses “the rules created via the rules creator 128 of the user application 120, including default rules and/or calendar-event specific rules” to prioritize one transportation journey request over another, and the “vehicle arrival time field 212 is updated for each request to accommodate both requests based on data received from the scheduler 134” based on one transportation journey being “a high priority event.” Also see [0068] – [0070], & [0100] – [0103], noting that “the calendar event associated with the new vehicle request can be assigned a high event priority,” and that “the request confirmer 606 sends the user an adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134 in view of the vehicle schedule stored in the vehicle calendar 603 and the analysis performed by the conflict analyzer 604, the trip planner 608, and the vehicle locator 610. In such examples, the user application 120 populates the vehicle arrival time field 212 of the first example screen 200 with a proposed or alternative time” for one of the two requesting users (i.e., each request is allocated a slot with one given priority based on rules.),
• and wherein the second allocation comprises one or more candidate alternatives to one or more constraints in the second request ([0034], [0069] – [0070] & [0103], “the request confirmer 606 sends the user an adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134 in view of the vehicle schedule stored in the vehicle calendar 603 and the analysis performed by the conflict analyzer 604, the trip planner 608, and the vehicle locator 610. In such examples, the user application 120 populates the vehicle arrival time field 212 of the first example screen 200 with a proposed or alternative time.”).
As per claim 8, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses:
• wherein the first allocation comprises an allocated vehicle slot for servicing the first request according to one or more constraints in the first request (See [0057] & [0059], noting that “conflict analyzer 604 determines if there are any direct conflicts between the new vehicle request and previously scheduled vehicle requests,” and uses “the rules created via the rules creator 128 of the user application 120, including default rules and/or calendar-event specific rules” to prioritize one transportation journey request over another, and the “vehicle arrival time field 212 is updated for each request to accommodate both requests based on data received from the scheduler 134” based on one transportation journey being “a high priority event” as indicated in the request. Also see [0068] – [0070], & [0100] – [0103], noting that “the calendar event associated with the new vehicle request can be assigned a high event priority,” and that “the request confirmer 606 sends the user an adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134 in view of the vehicle schedule stored in the vehicle calendar 603 and the analysis performed by the conflict analyzer 604, the trip planner 608, and the vehicle locator 610. In such examples, the user application 120 populates the vehicle arrival time field 212 of the first example screen 200 with a proposed or alternative time” for one of the two requesting users (i.e., one request is allocated a slot based on priority based on the request.).
As per claim 9, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses:
• wherein the second allocation comprises an allocated vehicle slot for servicing the second request according to one or more relaxed constraints ([0034], [0069] – [0070], [0075] – [0076], & [0103], “the request confirmer 606 sends the user an adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134 in view of the vehicle schedule stored in the vehicle calendar 603 and the analysis performed by the conflict analyzer 604, the trip planner 608, and the vehicle locator 610.” Also [0105] – [0108], “adjustment of arrival times”).
As per claim 10, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses:
• wherein the one or more relaxed constraints comprise a time shift, a departure location shift, an arrival location shift, or a trip type shift ([0034], [0069] – [0070], [0075] – [0076], & [0103], relaxed constraints comprise a time shift: “the request confirmer 606 sends the user an adjusted arrival time for the vehicle 102 based on a next time that the vehicle 102 is available as determined by the scheduler 134 in view of the vehicle schedule stored in the vehicle calendar 603 and the analysis performed by the conflict analyzer 604, the trip planner 608, and the vehicle locator 610.” Also [0105] – [0108], “adjustment of arrival times”).
As per claim 15, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses:
• wherein the request arbitration model is configured to receive request data and generate a score for a corresponding request, and wherein the method comprises: computing, based on a score for the first request and a score for the second request, the first allocation for servicing the first request ([0043], [0102], & claim 17, a level (i.e., score) of priority is determined for each request. As per [0057] & [0059],
[0068] – [0070], & [0100] – [0103], each request is allocated a slot based on the priority score.).
As per claim 16, Abbas / Akselrod discloses the limitations of claim 1. Abbas further discloses:
• wherein the request arbitration model is configured to generate the score for the corresponding request based on at least one of: a platform identifier associated with the corresponding request, user data associated with the corresponding request ([0057], [0059] & [0068], the priority level is based on “calendar-event specific rules” i.e., user data associated with the corresponding request), forecasted utilization of available vehicle slots, departure location data associated with the corresponding request, arrival location data associated with the corresponding request, or scheduling data associated with the corresponding request.
As per claim 19, see the above relevant rejection of claim 1. In addition, Abbas discloses one or more non-transitory computer-readable media storing instructions that are executable by one or more processors to cause a computing system to perform operations ([0110] – [0112]).
As per claim 20, see the above relevant rejection of claim 1. In addition, Abbas discloses a computing system, comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that are executable by the one or more processors to cause the computing system to perform operations ([0110] – [0113]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Abbas et al. (US 20180060827 A1), in view of Akselrod et al. (US 20180293521 A1), in view of Liu (US 20180232840 A1), in view of Chachra et al. (US 20200410625 A1).
As per claim 5, Abbas / Akselrod discloses the limitations of claim 1. To the extent to which Abbas / Akselrod does not appear to explicitly disclose the following limitation, Liu teaches:
• computing, …a first value indicative of a likelihood of a subsequent request for providing transportation from a destination associated with the first request; computing, … a second value indicative of a likelihood of a subsequent request for providing transportation from a destination associated with the second request; and determining to prioritize the first request based on comparing the first value and the second value (See [0049] – [0050] & [0053] – [0055], which describes a process for calculating a probability of a subsequent user requesting a pickup at a starting point “associated with destination” information of a first ride, and giving “weight” (i.e., priority) to servicing a transport request which is part of a cluster of requests in a zone that has a higher probability of matching a destination of a first ride with the pickup point of the matched transport request.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Liu in the invention of Abbas / Akselrod with the motivation to provide a system and method which “advantageously allows a single provider to provide both rides,” as evidenced by Liu ([0049]).
To the extent to which Abbas / Akselrod / Liu does not appear to explicitly disclose wherein the probability determination is performed “using a machine-learned model,” Chachra, in [0021], teaches this functionality.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Chachra in the invention of Abbas / Akselrod / Liu with the motivation to provide a system and method “that efficiently and effectively provides on-demand transportation services for a geographic area,” as evidenced by Chachra ([0005]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Abbas et al. (US 20180060827 A1), in view of Akselrod et al. (US 20180293521 A1), in view of Brownell et al. (US 20190080275 A1).
As per claim 6, Abbas / Akselrod discloses the limitations of claim 1. To the extent to which Abbas / Akselrod does not appear to explicitly disclose the following limitation, Brownell teaches:
• determining that allocating a vehicle slot for servicing the first request would use capacity on a vehicle already assigned to travel to a destination associated with the first request; determining that allocating a vehicle slot for servicing the second request would use capacity on a previously unassigned vehicle, causing the previously unassigned vehicle to be assigned to travel to a destination associated with the second request; and determining to prioritize the first request based on the use of capacity on the vehicle already assigned to travel to the destination associated with the first request (See [0027] & [0029], noting a process for prioritizing the acceptance of a transport request over others when the request comprises a “pick-up location and drop-off destination” which matches “the traveling path or starting location and destination of the trip of the driver.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Brownell in the invention of Abbas / Akselrod with the motivation “to provide a platform and a method that offer additional revenue for drivers to greatly offset their fuel cost and turn their commute into a net gain,” as evidenced by Brownell ([0007]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Abbas et al. (US 20180060827 A1), in view of Akselrod et al. (US 20180293521 A1), in view of Scarborough et al. (US 20150066546 A1).
As per claim 11, Abbas / Akselrod discloses the limitations of claim 1. To the extent to which Abbas / Akselrod does not appear to explicitly disclose the following limitation, Scarborough teaches wherein updating the vehicle slot register based on the first allocation and the second allocation comprises:
• respectively updating an availability for the allocated vehicle slots to indicate that the first allocation comprises a pending allocation of one or more vehicle slots ([0006], [0061] – [0062], [0074] – [0075], & [0136], updating a status of a reservation allocations (i.e., ticket) that indicates a pending “hold” status.);
• and initiating an expiration interval for the pending allocation, the expiration interval configured to trigger expiry of the pending allocation, reverting availability of the allocated vehicle slots ([0075] – [0076] & [0136], releasing the held pending reservation allocations to be available to other customer.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Scarborough in the invention of Abbas / Akselrod with the motivation to “provide actors with more flexible and satisfactory experiences regarding obtaining” reservation allocations, as evidenced by Scarborough ([0004]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Abbas et al. (US 20180060827 A1), in view of Akselrod et al. (US 20180293521 A1), in view of Demczuk et al. (US 20090106055 A1).
As per claim 12, Abbas / Akselrod discloses the limitations of claim 1. To the extent to which Abbas / Akselrod does not appear to explicitly disclose the following limitation, Demczuk teaches:
• wherein a transportation platform associated with the first request is different than a transportation platform associated with the second request ([0022], [0053], and claims 1 & 19, “a universal reservation processing center” receiving “reservation requests received from the one or more marketplace systems”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Demczuk in the invention of Abbas / Akselrod with the motivation to “connect marketplaces to service providers through the universal scheduling agent,” as evidenced by Demczuk ([0010]).
Claims 13 – 14 are rejected under 35 U.S.C. 103 as being unpatentable over Abbas et al. (US 20180060827 A1), in view of Akselrod et al. (US 20180293521 A1), in view of Dovenor et al. (US 20240144127 A1).
As per claim 13, Abbas / Akselrod discloses the limitations of claim 1. To the extent to which Abbas / Akselrod does not appear to explicitly disclose the following limitations, Dovenor teaches wherein:
• the first request is from a first transportation platform computing system associated with a first platform identifier and the second request is from a second transportation platform computing system associated with a second platform identifier ([0035] & [0040], each “service request” received from the plurality of partners is associated with “certain identified conditions of service” such as each partner’s “proper authorization credential” to validate each request.);
• a quantity of vehicle slots are pre-allocated for servicing requests associated with the first platform identifier ([0034] & [0038] – [0039], a number of vehicles is assigned to each partner's primary fleet associated with the request credentials as per [0040]);
• and the first allocation is allocated from the pre-allocated quantity of vehicle slots ([0040] – [0044], allocating a vehicle from “the first partner's primary fleet” to a service request.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Dovenor in the invention of Abbas / Akselrod with the motivation to solve the problem of “inefficient vehicle use, as some vehicles may remain idle during times that the tenant has a low usage requirement, and a dedicated fleet may not include enough vehicles to handle a tenant's requirements during periods of high demand,” as evidenced by Dovenor ([0016] & [0018]).
As per claim 14, Abbas / Akselrod / Dovenor discloses the limitations of claim 13. To the extent to which Abbas / Akselrod does not appear to explicitly disclose the following limitations, Dovenor teaches:
• determining a conflict between the second request and the pre-allocation of the quantity of vehicle slots for servicing requests associated with the first platform identifier ([0042], determining that “the first partner's primary fleet cannot fulfill the trip request,” which, as per [0035] & [0040], is associated with “certain identified conditions of service” such as each partner’s “proper authorization credential” to validate each request.);
• computing a value indicating a probability that a pre-allocated vehicle slot of the pre-allocated quantity of vehicle slots will be underutilized ([0044], determining that “one or more other partner fleets has more vehicles allocated to it than that partner's SLA requires” i.e., determining a one hundred percent probability that a partner fleet is not fully used.);
• and releasing the pre-allocated vehicle slot for allocation for servicing the second request ([0042] – [0044], “assign a vehicle from the other partner's fleet to the first partner's primary fleet, and it may assign the trip to the vehicle by transmitting information to that vehicle that will cause the vehicle to fulfill the first trip request.”). Rationale to combine the teachings of Dovenor persists.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Abbas et al. (US 20180060827 A1), in view of Akselrod et al. (US 20180293521 A1), in view of Chen et al. (US 20200151640 A1).
As per claim 17, Abbas / Akselrod discloses the limitations of claim 16. To the extent to which Abbas / Akselrod does not appear to explicitly disclose the following limitation, Chen teaches wherein the request arbitration model is configured to:
• generate the score for the corresponding request based on historical platform performance data associated with the platform identifier associated with the corresponding request ([0004], [0006] – [0007], & [0095], generating “an order allocation weight” (i.e., score) for each “service request” “based on the historical online time length of the candidate service provider and the expected income at unit time and determine the order allocation weight of the first service request with respect the candidate service provider based on the expected income, the total values of historical orders, and the estimated value of the first service request.” As per [0048], [0052], & [0059], the requests are associated with “information or data” of a “service provider.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the aforementioned teachings of Chen in the invention of Abbas / Akselrod with the motivation to prioritize trustworthy partner platforms.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN J KIRK whose telephone number is (571)272-6447. The examiner can normally be reached Monday -Friday 9:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shannon Campbell can be reached at (571)272-5587. 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.
/BRYAN J KIRK/Examiner, Art Unit 3628