DETAILED ACTION
This communication is a Non-Final Rejection Office Action in response to the 12/31/2024 filling of Application 19/007,350. Claims 1-20 are now presented.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 non-statutory subject matter.
When considering subject matter eligibility under 35 U.S.C. 101, in step 1 it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, in step 2A prong 1 it must then be determined whether the claim is recite a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). If the claim recites a judicial exception, under step 2A prong 2 it must additionally be determined whether the recites additional elements that integrate the judicial exception into a practical application. If a claim does not integrate the Abstract idea into a practical application, under step 2B it must then be determined if the claim provides an inventive concept.
In the Instant case, Claims 1-13 are directed toward a computer program product for assigning and reassigning job order to providers. Claims 14-19 are directed toward a system for assigning and reassigning job order to providers. Claim 20 is directed toward a method for assigning and reassigning job order to providers. As such, each of the Claims is directed to one of the four statutory categories of invention.
MPEP 2106.04 II. A. explains that in step 2A prong 1 Examiners are to determine whether a claim recites a judicial exception. MPEP 2106.04(a) explains that:
To facilitate examination, the Office has set forth an approach to identifying abstract ideas that distills the relevant case law into enumerated groupings of abstract ideas. The enumerated groupings are firmly rooted in Supreme Court precedent as well as Federal Circuit decisions interpreting that precedent, as is explained in MPEP § 2106.04(a)(2). This approach represents a shift from the former case-comparison approach that required examiners to rely on individual judicial cases when determining whether a claim recites an abstract idea. By grouping the abstract ideas, the examiners’ focus has been shifted from relying on individual cases to generally applying the wide body of case law spanning all technologies and claim types.
The enumerated groupings of abstract ideas are defined as:
1) Mathematical concepts – mathematical relationships, mathematical formulas or equations, mathematical calculations (see MPEP § 2106.04(a)(2), subsection I);
2) Certain methods of organizing human activity – fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) (see MPEP § 2106.04(a)(2), subsection II); and
3) Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).
As per step 2A prong 1 of the eligibility analysis, claim 1 recites the abstract idea of assigning job orders to providers which falls into the abstract idea categories of certain methods of organizing human activity and mental processes. The elements of Claim 1 that represent the Abstract idea include:
Receiving a transport request from a computing device of a service requester;
Generating data corresponding to a job order for the transport request;
assigning the job order to a first service provider based at least in part on a current location of the first service provider, the current location being determined based on location information received from a computing device of the first service provider;
monitoring an activity of the first service provider during a time interval that follows when the first service provider is assigned to the job order;
computing a score indicative of an intent of the first service provider to fulfill the job order in accordance with a set of objectives, based at least in part on the monitored activity; and
based at least in part on the score, reassigning the job order to a second service provider.
MPEP 2106.04(a)(2) II. states:
The phrase "methods of organizing human activity" is used to describe concepts relating to:
fundamental economic principles or practices (including hedging, insurance, mitigating risk);
commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); and
managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions).
The Supreme Court has identified a number of concepts falling within the "certain methods of organizing human activity" grouping as abstract ideas. In particular, in Alice, the Court concluded that the use of a third party to mediate settlement risk is a ‘‘fundamental economic practice’’ and thus an abstract idea. 573 U.S. at 219–20, 110 USPQ2d at 1982. In addition, the Court in Alice described the concept of risk hedging identified as an abstract idea in Bilski as ‘‘a method of organizing human activity’’. Id. Previously, in Bilski, the Court concluded that hedging is a ‘‘fundamental economic practice’’ and therefore an abstract idea. 561 U.S. at 611–612, 95 USPQ2d at 1010.
In the instant case the steps of receiving a transport request from a computing device of a service requester; generating, data corresponding to a job order for the transport request; assigning the job order to a first service provider based at least in part on a current location of the first service provider, the current location being determined based on location information received from a computing device of the first service provider; monitoring an activity of the first service provider during a time interval that follows when the first service provider is assigned to the job order; computing a score indicative of an intent of the first service provider to fulfill the job order in accordance with a set of objectives, based at least in part on the monitored activity; and based at least in part on the score, reassigning the job order to a second service provider are directed to assigning job orders to providers which is a fundamental business practice.
MPEP 2106.04(a)(2) states:
The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’" 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 71, 101 USPQ2d 1961, 1965 (2012) ("‘[M]ental processes[] and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work’" (quoting Benson, 409 U.S. at 67, 175 USPQ at 675)); Parker v. Flook, 437 U.S. 584, 589, 198 USPQ 193, 197 (1978) (same).
Accordingly, the "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions
The instant claims recite mental processes including observation, evaluation, judgment, opinion. For example, the steps directed to generating, data corresponding to a job order for the transport request; assigning the job order to a first service provider based at least in part on a current location of the first service provider, the current location being determined based on location information received from a computing device of the first service provider; monitoring an activity of the first service provider during a time interval that follows when the first service provider is assigned to the job order; computing a score indicative of an intent of the first service provider to fulfill the job order in accordance with a set of objectives, based at least in part on the monitored activity; and based at least in part on the score, reassigning the job order to a second service provider are directed to mental processes. There is nothing is nothing the claims that preclude these steps from being performed mentally. As such, the claims recite abstract ideas.
Under step 2A prong 2 the examiner must then determine if the recited abstract idea is integrated into a practical application. MPEP 2106.04 states:
Limitations the courts have found indicative that an additional element (or combination of elements) may have integrated the exception into a practical application include:
• An improvement in the functioning of a computer, or an improvement to other technology or technical field, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a);
• Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, as discussed in MPEP § 2106.04(d)(2);
• Implementing a judicial exception with, or using a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, as discussed in MPEP § 2106.05(b);
• Effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP § 2106.05(c); and
• Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception, as discussed in MPEP § 2106.05(e)
The courts have also identified limitations that did not integrate a judicial exception into a practical application:
• Merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f);
• Adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g); and
• Generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h).
In the instant case, this judicial exception is not integrated into a practical application. In particular, Claim 1 recites the additional elements of:
A non-transitory computer-readable medium that stores instructions, which when executed by one or more processors of a computer system, cause the computer system to perform operations comprising:
Receiving a request over one or more networks,
storing information in a data store;
monitoring, by communicating with the computing device
However, the computer elements (processors to execute instruction; and the computing device to monitor) are recited at a high-level of generality (i.e., as a generic processor performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception using a generic computer component.
Further, the step of storing information does not add any meaningful limits on the claims and as such amounts to insignificant extra solution activity.
Further, the receiving a request over one or more networks amounts to a general link to a particular technological environment. For example, the abstract idea of assigning job orders is being conducted via the particular technological environment of networked devices that facilitate communication between requestor and providers.
Viewing the generic data storage and general link to a particular technological environment in combination with the generic computer does not add more than when viewing the elements individually. Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
In step 2B, the examiner must be determine whether the claim adds a specific limitation other than what is well-understood, routine, conventional activity in the field - see MPEP 2106.05(d). As discussed with respect to Step 2A Prong Two, the processing circuitry in the claim amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Similarly, including a general link to a particular technological environment in the claims cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Further, MPEP 2106.05(d) states that Storing and retrieving information in memory is well-known and conventional when claimed generically. As such, the storing information in a data store is not sufficient to provide an inventive concept.
Viewing the generic data storage and general link to a particular technological environment in combination with the generic computer does not add more than when viewing the elements individually. Accordingly, the additional elements do not provide an inventive concept.
Further Claims 2-13 further limit the mental processes and business practices recited in the parent claim, but fail to remedy the deficiencies of the parent claim as they do not impose any additional elements that amount to significantly more than the abstract idea itself.
Accordingly, the Examiner concludes that there are no meaningful limitations in claims 1-13 that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
The analysis above applies to all statutory categories of invention. The presentment of claim 1 otherwise styled as a method, or system, for example, would be subject to the same analysis. As such, claims 8-20 are also rejected.
Claim Rejections - 35 USC § 103
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, 2, 11, 12, 13, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gu US 2023/0057527 A1 in view of Ittiachen US 2022/0005086 A1.
As per Claim 1 Gu teaches A non-transitory computer-readable medium that stores instructions, which when executed by one or more processors of a computer system, cause the computer system to perform operations comprising: See Gu para. 136
receiving, over one or more networks, a transport request from a computing device of a service requester; Gu para. 56 teaches As illustrated in FIG. 2, the request distribution system 104 performs an act 202 to receive a transportation request. In particular, the request distribution system 104 receives a transportation request from the requester device 112 indicating a requested pick-up location and a requested drop-off location. For example, the request distribution system 104 receives a transportation request to surface to a provider device (e.g., one of the provider devices 108a-108n) to service the transportation request.
generating, and storing in a data store, data corresponding to a job order for the transport request; Gu para. 48 teaches as shown, the request distribution system 104 utilizes the network 116 to communicate with the provider devices 108a-108n and the requester device 112. The network 116 may comprise any network described in relation to FIGS. 11-12. For example, the request distribution system 104 communicates with the provider devices 108a-108n and the requester device 112 to match transportation requests received from the requester device 112 with one or more of the provider devices 108a-108n. Indeed, the transportation matching system 102 or the request distribution system 104 can receive a transportation request from the requester device 112 and can provide request information to the provider devices 108a-108n, such as a requested location (e.g., a requested pickup location and/or a requested drop-off location), a requester identification (for a requester corresponding to the requester device 112), and a requested pickup time. Further, para. 172 teaches in particular embodiments, transportation matching system 102 may be a network-addressable computing system that can host a transportation matching network. The transportation matching system 102 may generate, store, receive, and send data, such as, for example, user-profile data, concept-profile data, text data, transportation request data, GPS location data, provider data, requester data, vehicle data, or other suitable data related to the transportation matching network. This may include authenticating the identity of providers and/or vehicles who are authorized to provide transportation services through the transportation matching system 102. In addition, the transportation matching system 102 may manage identities of service requesters such as users/requesters. In particular, the transportation matching system 102 may maintain requester data such as driving/riding histories, personal data, or other user data in addition to navigation and/or traffic management services or other location services (e.g., GPS services).
assigning the job order to a first service provider based at least in part on a current location of the first service provider, Gu para. 26 teaches the request distribution system can select the provider device based on comparing the arrival times and/or based on the request reliability metric, the acceptance probability, and/or the cancelation probability associated with the transportation request.. The Examiner considers arrival time to be a determination that is based at least in part on a current location.
the current location being determined based on location information received, over the one or more networks, from a computing device of the first service provider; Gu para. 172 teaches in particular embodiments, transportation matching system 102 may be a network-addressable computing system that can host a transportation matching network. The transportation matching system 102 may generate, store, receive, and send data, such as, for example, user-profile data, concept-profile data, text data, transportation request data, GPS location data, provider data, requester data, vehicle data, or other suitable data related to the transportation matching network. This may include authenticating the identity of providers and/or vehicles who are authorized to provide transportation services through the transportation matching system 102. In addition, the transportation matching system 102 may manage identities of service requesters such as users/requesters. In particular, the transportation matching system 102 may maintain requester data such as driving/riding histories, personal data, or other user data in addition to navigation and/or traffic management services or other location services (e.g., GPS services).
monitoring, by communicating with the computing device of the first service provider over one or more network, a first service provider during a time interval that follows when the first service provider is assigned to the job order; Gu para. 81 teaches as further illustrated in FIG. 4, the request distribution system 104 determines a cancelation probability 412 for a transportation request. In particular, the request distribution system 104 determines the cancelation probability 412 from one or more cancelation probability factors 408, where the cancelation probability 412 indicates a likelihood of receiving a cancelation from the requester device 112 before pick-up. For example, the request distribution system 104 utilizes a cancelation probability model 410 to determine or predict the cancelation probability 412 based on the cancelation probability factors 408. The cancelation probability factors 408 can include a time since acceptance of the transportation request (e.g., a duration of time that has elapsed since the provider device accepted the transportation request), a distance of the provider device to the pick-up location, an arrival time for the provider device to arrive at the pick-up location, and/or a provider rating within the transportation matching system 102. In some cases, the cancelation probability factors 408 can also include a number of cancelations over a particular time period (e.g., a previous 3 days or a previous 5 days) and/or within a geographic region associated with the transportation request (e.g., a particular geofenced zone or geohash). Based on one or more of the aforementioned cancelation probability factors 408, the request distribution system 104 can determine a likelihood of receiving a cancelation of the transportation request from the requester device 112 (e.g., utilizing the cancelation probability model 410).
computing a score indicative of an intent of the first service provider to fulfill the job order in accordance with a set of objectives, based at least in part on the monitoring; and Gu para. 81 teaches as further illustrated in FIG. 4, the request distribution system 104 determines a cancelation probability 412 for a transportation request. In particular, the request distribution system 104 determines the cancelation probability 412 from one or more cancelation probability factors 408, where the cancelation probability 412 indicates a likelihood of receiving a cancelation from the requester device 112 before pick-up. For example, the request distribution system 104 utilizes a cancelation probability model 410 to determine or predict the cancelation probability 412 based on the cancelation probability factors 408. The cancelation probability factors 408 can include a time since acceptance of the transportation request (e.g., a duration of time that has elapsed since the provider device accepted the transportation request), a distance of the provider device to the pick-up location, an arrival time for the provider device to arrive at the pick-up location, and/or a provider rating within the transportation matching system 102. In some cases, the cancelation probability factors 408 can also include a number of cancelations over a particular time period (e.g., a previous 3 days or a previous 5 days) and/or within a geographic region associated with the transportation request (e.g., a particular geofenced zone or geohash). Based on one or more of the aforementioned cancelation probability factors 408, the request distribution system 104 can determine a likelihood of receiving a cancelation of the transportation request from the requester device 112 (e.g., utilizing the cancelation probability model 410). The Examiner considers a cancellation probability to be a score indicative of an intent.
based at least in part on the score, reassigning the job order to a second service provider. Gu para. 26 teaches based on the comparison of the arrival times, the different expected changes in network coverage time, and/or the other transportation request metrics, the request distribution system can determine or select a provider device to provide the transportation request. For example, the request distribution system can select a limited-eligibility provider device or another provider device as a recipient for the transportation request based on determining that providing the transportation request to the provider device will result in an overall increase in network coverage time (e.g., for the transportation matching system as a whole and/or for a particular geographic region). In addition, the request distribution system can select the provider device based on comparing the arrival times and/or based on the request reliability metric, the acceptance probability, and/or the cancelation probability associated with the transportation request. In some cases, the request distribution system can select an initial provider device for a transportation request and can reassign the transportation request to a different provider device (e.g., a limited-eligibility provider device) based on the expected change in network coverage time, comparing arrival times, and/or other transportation metrics. Para. 113 teaches in one or more embodiments, the request distribution system 104 performs a provider device swap (e.g., transfers a transportation request from a first provider device to a second provider device). To elaborate, the request distribution system 104 determines, after acceptance by a full-eligibility provider device, that a limited-eligibility provider device is a better candidate for servicing the transportation request. For instance, the request distribution system 104 determines that providing the transportation request to the limited-eligibility provider device would result in at least a threshold increase in transportation system provider hours. As another example, the request distribution system 104 determines that providing the transportation request to the limited-eligibility provider device would result in at least a threshold improvement to arrival time (or other transportation metric) as compared to the full-eligibility provider device. The request distribution system 104, therefore, reassigns the transportation request to the limited-eligibility provider device and provides the transportation request to the limited-eligibility provider device, removing the request from the full-eligibility provider device. In some cases, the request distribution system 104 further compensates the full-eligibility provider device for the swap (e.g., the unilateral cancelation from the system). In other cases, the request distribution system 104 replaces a swapped request with another request for the full-eligibility provider device.
Gu does not explicitly disclose monitoring, by communicating with the computing device of the first service provider over one or more network, an activity of the first service provider. However, Ittiachen para. 50 teaches The acceptance score may indicate an intent of the driver 112 for providing ride services to the customer 116 and may be measured in terms of a rate at which the booking request is accepted by the driver 112, a call is made to the customer 116 by the driver 112 based on the allocation, and the vehicle 108 is driven towards the pick-up location of the customer 116 by the driver 112. Both Gu and Ittiachen are directed to managing a rideshare platform. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Gu to include monitoring, by communicating with the computing device of the first service provider over one or more network, an activity of the first service provider as taught by Ittiachen to improve operations by tracking and analyzing vehicle's and driver's performance may be necessary since it can lead to optimization that increases productivity and mitigate risks, which in turn lowers costs of the transportation industry over the long-term (see para. 3).
As per Claim 2 Gu teaches the non-transitory computer readable medium of claim 1, wherein computing the score includes determining whether an estimated time-to-arrival for the first service provider to arrive at a start location is within a threshold time interval. Gu para. 98 teaches as further illustrated in FIG. 5A, the request distribution system 104 compares an arrival time (e.g., estimated time of arrival or “ETA”) for the limited-eligibility provider device 502 with an arrival time associated with another limited-eligibility provider device 504 (or a full-eligibility provider device). For example, the request distribution system 104 determines an arrival time for the limited-eligibility provider device 502 to arrive at the pick-up location to service the transportation request (if the limited-eligibility provider device 502 were selected to service the request) and further determines an arrival time for the limited-eligibility provider device 504 to arrive at the pick-up location as well. The request distribution system 104 compares the arrival times to select the limited-eligibility provider device 502 based on determining that its arrival time is sooner (or shorter) than that of the limited-eligibility provider device 504. In some cases, the request distribution system 104 filters limited-eligibility provider devices based on arrival time by removing from consideration, or excluding, limited-eligibility provider devices whose arrival time exceeds a threshold arrival time.
As per Claim 11 Gu teaches the non-transitory computer-readable medium of claim 1, wherein reassigning the job order includes determining that a likelihood of the service requester cancelling the transport request is less than a threshold. Gu para. 81 teaches As further illustrated in FIG. 4, the request distribution system 104 determines a cancelation probability 412 for a transportation request. In particular, the request distribution system 104 determines the cancelation probability 412 from one or more cancelation probability factors 408, where the cancelation probability 412 indicates a likelihood of receiving a cancelation from the requester device 112 before pick-up. For example, the request distribution system 104 utilizes a cancelation probability model 410 to determine or predict the cancelation probability 412 based on the cancelation probability factors 408. The cancelation probability factors 408 can include a time since acceptance of the transportation request (e.g., a duration of time that has elapsed since the provider device accepted the transportation request), a distance of the provider device to the pick-up location, an arrival time for the provider device to arrive at the pick-up location, and/or a provider rating within the transportation matching system 102. In some cases, the cancelation probability factors 408 can also include a number of cancelations over a particular time period (e.g., a previous 3 days or a previous 5 days) and/or within a geographic region associated with the transportation request (e.g., a particular geofenced zone or geohash). Based on one or more of the aforementioned cancelation probability factors 408, the request distribution system 104 can determine a likelihood of receiving a cancelation of the transportation request from the requester device 112 (e.g., utilizing the cancelation probability model 410).
As per Claim 12 Gu teaches the non-transitory computer-readable medium of claim 1, wherein reassigning the job order includes determining that the second service provider is closer to a start location of the job order. Gu para. 63 teaches in one or more embodiments, the request distribution system 104 selects a provider device based on other factors as well. For example, the request distribution system 104 determines and compares arrival times associated with different provider devices, including limited-eligibility provider devices and full-eligibility provider devices. Specifically, the request distribution system 104 determines and compares arrival times for provider devices to arrive at a pick-up location associated with the transportation request
As per Claim 13 Gu teaches the non-transitory computer-readable medium of claim 1, wherein monitoring the activity of the first service provider is based on sensor data from one or more movement sensors of the computing device of the provider. Gu para. 172 teaches In particular embodiments, transportation matching system 102 may be a network-addressable computing system that can host a transportation matching network. The transportation matching system 102 may generate, store, receive, and send data, such as, for example, user-profile data, concept-profile data, text data, transportation request data, GPS location data, provider data, requester data, vehicle data, or other suitable data related to the transportation matching network. This may include authenticating the identity of providers and/or vehicles who are authorized to provide transportation services through the transportation matching system 102. In addition, the transportation matching system 102 may manage identities of service requesters such as users/requesters. In particular, the transportation matching system 102 may maintain requester data such as driving/riding histories, personal data, or other user data in addition to navigation and/or traffic management services or other location services (e.g., GPS services).
Claims 14 and 15 recite similar limitations to those recited in claims 1, 2 and are rejected for similar reasons. Further, Gu teaches A network computer system comprising: one or more processors; a memory to store a set of instructions; wherein the one or more processors execute instructions to perform operations that include the recited steps (see para. 136)
Claim 20 recite similar limitations to those recited in claims 1 and are rejected for similar reasons. Further, Gu teaches A computer-implemented method comprising performing the recited steps (see para. 4)
Claim(s) 3, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gu US 2023/0057527 A1 in view of Ittiachen US 2022/0005086 A1 as applied to claim 1 and in further view of Martin US 2022/0044569 A1.
As per Claim 3 Gu does not teach the non-transitory computer-readable medium of claim 1, wherein monitoring an activity of the first service provider includes determining that the first service provider is idling for a duration that exceeds a designated threshold time interval. However, Martin para. 282 teaches for example, in one or more embodiments, the provider dispatch control system 106 utilizes a threshold idle time to determine whether to utilize a prioritization metric to increase or decrease a priority selection score. For example, in some embodiments, if the average idle time at a destination location is below a threshold idle time (e.g., the wait time is low), the provider dispatch control system 106 can utilize the prioritization metric to increase a priority selection score. Moreover, in one or more embodiments, if the average idle time meets or is above the threshold idle time, then the provider dispatch control system 106 can utilize the prioritization metric to decrease a priority selection score. Both Gu in view of Ittiachen and Martin are directed to managing a rideshare platform. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Gu in view of Ittiachen to include monitoring an activity of the first service provider includes determining that the first service provider is idling for a duration that exceeds a designated threshold time interval as taught by Martin to dispatch provider devices to more efficient destinations, reduce idle times for provider devices, reduce wait times for requestor devices, and reduce digital cancellation (see para. 40).
As per Claim 8 Martin does not teach the non-transitory computer-readable medium of claim 1, wherein monitoring the activity of the first service provider includes determining a progress of the first service provider towards a start location of the transport request. However, Martin para. 261 teaches in addition, in one or more embodiments, the provider dispatch control system 106 determines a selection score (e.g., a dispatch score) for a provider device by utilizing a probability of conversion and a value of a transportation request. For example, the provider dispatch control system 106 can determine a probability of conversion (e.g., a probability of whether a transportation request will be fulfilled or canceled). Additionally, the provider dispatch control system 106 can combine the probability of a conversion with a value of the transportation request (e.g., a value associated with the request after costs of fulfilling the transportation request) to generate the selection score. In one or more embodiments, the provider dispatch control system 106 utilizes a probability of conversion and/or value of a transportation request (e.g., as a result of travel to a pickup location, vehicle type, time of day, distance, ETA) that is specific to a provider device to determine the selection score for the provider device in relation to the transportation request. Both Gu in view of Ittiachen and Martin are directed to managing a rideshare platform. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Gu in view of Ittiachen to include monitoring the activity of the first service provider includes determining a progress of the first service provider towards a start location of the transport request as taught by Martin to dispatch provider devices to more efficient destinations, reduce idle times for provider devices, reduce wait times for requestor devices, and reduce digital cancellation (see para. 40).
Claims 16 recite similar limitations to those recited in claim 3 and are rejected for similar reasons. Further, Gu teaches A network computer system comprising: one or more processors; a memory to store a set of instructions; wherein the one or more processors execute instructions to perform operations that include the recited steps (see para. 136)
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gu US 2023/0057527 A1 in view of Ittiachen US 2022/0005086 A1 in view of Martin US 2022/0044569 A1 as applied to claim 8 and in further view of Shoval US 2022/0003561 A1.
As per Claim 9 Martin does not teach the non-transitory computer-readable medium of claim 8, wherein computing the score includes: determining that the progress of the first service provider is inadequate based on one or more of the set of objectives, and in response to making the determination, transmitting, over one or more networks, a notification to the computing device of the first service provider. Shoval para. 137 teaches event detection module 604 may detect an unanticipated ridesharing event after first ridesharing vehicle 701 picks up some of the users and before picking up the last users. An unanticipated ridesharing event refers to an event that was not anticipated or did not occur before assignment module 605 electronically assigned the users to first ridesharing vehicle 701. For example, after first ridesharing vehicle 701 picks up first user 711 and is on its way to the pick-up location of second user 712, second user 712 transmits a request to communication module 601 to modify the pick-up time because second user 712 will arrive at the pick-up location late. Event detection module 604 may consider (or detect) this event as an unanticipated ridesharing event. Event detection module 604 may also determine the inability of first ridesharing vehicle 701 to pick up a next user (i.e., third user 713) at a corresponding estimated pick-up time due to the unanticipated ridesharing event. Assignment module 605 may further reassign second user 712 to another ridesharing vehicle (e.g., second ridesharing vehicle 702). Assignment module 605 may determine a new route for first ridesharing vehicle 701 that does not include the determined pick-up location of second user 712 and a new route for second ridesharing vehicle 702 that includes the determined pick-up location of second user 712. For example, assignment module 605 may determine a new route 722 for first ridesharing vehicle 701 (solid line 722 shown in FIG. 7) and direct first ridesharing vehicle 701 to change its original route (dashed route 721) at point 741 to pick up third user 713, skipping second user 712. Assignment module 605 may also determine a new route for second ridesharing vehicle 702 (solid line 732 shown in FIG. 7) and direct second ridesharing vehicle 702 to change its original route (dashed route 731) at point 742 to pick up second user 712. Further, para. 157 teaches in some embodiments, assignment module 605 may determine the inability of the first ridesharing vehicle to pick up the next user at the estimated pick-up time by calculating a delay in the estimated time of arrival (ETA) to the next user caused by the unanticipated ridesharing event and compare the calculated delay with a predefined threshold prior to reassign the next user to another ridesharing vehicle. For example, assignment module 605 may determine that the first ridesharing vehicle may be late for two minutes (i.e., a two-minute delay in the ETA) arriving at the pick-up location of second user 712 due to an unanticipated event. Assignment module 605 may compare the delay with a threshold (e.g., five minutes). Assignment module 605 may determine that the delay, which is shorter than the threshold, is acceptable, and determine that the first ridesharing vehicle will be able to reach the second user on time. As another example, assignment module 605 may determine that the first ridesharing vehicle will be late for 10 minutes, which is longer than the threshold. Assignment module 605 may determine that the first ridesharing vehicle will not reach the second user on time. Both the combination of Gu, Ittiachen and Martin are directed to managing a rideshare platform. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Gu in view of Ittiachen to include wherein computing the score includes: determining that the progress of the first service provider is inadequate based on one or more of the set of objectives, and in response to making the determination, transmitting, over one or more networks, a notification to the computing device of the first service provide as taught Shoval to design an optimal path and pick-up/drop-off order for a particular assigned vehicle undertaking multiple requests, and assign additional pick-ups as the vehicle completes a part of or all of the ride requests.
Relevant Art Not Relied Upon in a Rejection
Dutta US 20190206008 A1 - Continuing with FIG. 2, the system manager 108 identifies one or more drivers available to fulfill a ride request (e.g., the closest driver 204, the second closest driver 206, and the third closest driver 208). In one or more embodiments, the system manager 108 identifies available drivers based on a proximity to the pick-up location 202. For example, the system manager 108 may identify all drivers currently within a predetermined distance threshold of the pick-up location 202 as available drivers. In other embodiments, the system manager 108 identifies potential drivers based on estimated times-to-arrival from a current location of each potential driver and the pick-up location, which account for traffic or other factors in addition to proximity.
Subsequently, the system manager 108 identifies a first driver from the available drivers. In particular, the first driver is a driver determined by the system manager 108 as a potential first assignee of the ride request (as opposed to a re-assigned driver to whom the ride request may be re-assigned upon rejection by the first driver). In one or more embodiments, the system manager 108 identifies the first driver based on one or more characteristics of the ride request. For example, the system manager 108 may identify the first driver based on the proximity of each available driver to the pick-up location 202. In such a case, the system manager 108 may identify the closest driver 204 to the pick-up location 202 as the first driver.
Anuar US 2024/0210200 A1 - As used herein, the term “matching probability” refers to a likelihood that a provider device accepts a transportation request. For instance, based on features associated with the transportation request, a provider device will be more or less likely to match with a transportation request. To illustrate, a matching probability may be high when a transportation request has a high transportation value, whereas the matching probability may be low when the transportation request has a low transportation value. To further illustrate, a matching probability might be higher if the transportation request pickup location is near the provider device, whereas the matching probability may be lower when the transportation request pickup location is far away from the provider device.
Gulatu US 20210082077 A1 - As shown in FIG. 5, dynamic transportation matching system 400 of FIG. 4 may calculate acceptance probabilities 404(1)-(3) for each of provider devices 106(1)-(3). In one embodiment, dynamic transportation matching system 400 may determine a likelihood of each of provider devices 106(1)-(3) accepting a match to transportation request 102 by comparing transportation request 102 with historical records 502(1)-(3) of previous transportation requests 504(1)-(6) sent to provider devices 106(1)-(3). In this embodiment, historical records 502(1)-(3) may include information on estimated times of arrival 506(1)-(6) from a provider device's location at the time of a previous transportation request to a starting location of a previous transportation request, routes 508(1)-(5) of previous transportation requests, requestor ratings 512(1)-(4), and/or modes of transportation 510(1)-(5) used by the requestor. In some embodiments, information about the route of a previous request may also include data about the starting location, the ending location, an amount of time taken, a general location of the entire route (e.g., a geographical region or predefined region of service), an actual time of arrival, an idle time of provider devices 106(1)-(3) prior to receiving previous transportation requests 504(1)-(6), or other relevant data. For example, the information may also include a distance traveled during a route, a comparison of predicted data (such as the estimated time of arrival) with actual data (such as the actual time of arrival), a time of day of a transportation request (such as a specific hour, a day of the week, and/or whether the previous transportation request was during a known busy period), a previous location of a provider device, whether the provider indicated a preference to travel toward a particular location, device or application information from the provider device (such as a version of the application or specific device information), a provider vehicle type (e.g., whether the provider vehicle is classified as a luxury vehicle, which may indicate a greater likelihood that the provider accepts the match), and/or other provider data (such as a type of provider or user attributes). In some examples, dynamic transportation matching system 400 may determine acceptance probabilities based on one or more of the attributes described herein using a universal evaluation function (e.g., that does not take the particular provider into account). In other examples, dynamic transportation matching system 400 may determine acceptance probabilities based on one or more of the attributes described herein using a provider-specific evaluation function (e.g., that uses provider-specific information to determine how an attribute affects a likelihood of acceptance by a specific provider). For example, dynamic transportation matching system 400 may determine acceptance probabilities based on the time of day, the day of week, provider location, requestor pick-up location, weather, etc., on a provider-specific basis.
Gu US 20220164910 A1 [0030] As suggested above, in certain implementations, the priority management system ghost matches a prioritized requestor with a specific provider associated with (i) a candidate provider device currently in transit to pick up another requestor instead of (ii) a candidate provider device idling and waiting to receive transportation requests. By selecting a provider device in an in-transit-to-pickup status with a faster ETA than a provider device in an idle status, the priority management system can assign (and display with a prioritized transportation option) a specific provider more certain to accept a prioritized transportation request from a prioritized requestor's device. Because a provider device in in-transit-to-pickup status previously accepted a transportation request from another requestor device—and a provider device in idle status is more likely to reject or allow a transportation request to lapse (e.g., expire)—the provider device in in-transit-to-pickup status provides a more certain and specific provider to display with a prioritized transportation option before receiving a request from a prioritized requestor's device. In some cases or geographic areas, a provider device in idle status accepts about 80% (or rejects about 20%) of transportation requests, making a provider associated with such an idle provider device a less certain provider to display for a prioritized transportation option. Therefore, by selecting a provider device in in-transit-to-pickup status rather than idle status for a prioritized transportation option—and reducing a number of underutilized provider devices idling and awaiting transportation requests to maintain target ETAs—the priority management system increases the certainty of selecting and showing a specific provider to prioritized requestor devices before receiving prioritized transportation requests, expedites ETAs at a prioritized requestors' pickup locations with closer providers, and more efficiently utilizes a pool of candidate provider devices for a geographic area.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEIRDRE D HATCHER whose telephone number is (571)270-5321. The examiner can normally be reached Monday-Friday 8-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached at 571-270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/DEIRDRE D HATCHER/Primary Examiner, Art Unit 3625