DETAILED ACTION
Status of Claims
This final Office action is responsive to Applicant's amendment filed 2/20/26. Claims 1, 6, 10, and 15 have been amended. Claims 5 and 14 have been canceled. Claims 19 and 20 have been added. Claims 1-4, 6-13, and 15-20 have been considered as follows.
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 .
Response to Amendment
The previously pending objection to claims 1, 6, and 15 is withdrawn in response to Applicant's amendment to the claims.
The previously pending rejection under 35 U.S.C. § 101 is not withdrawn in response to Applicant's claim amendments. Examiner submits that while a system including a communications interface and a processor is provided, there is no positive recitation of how the system transforms or changes the nature of the claim into something patent-eligible.
Response to Arguments
Regarding Applicant’s arguments drawn to the rejection of the pending claims under 35 U.S.C. § 101, Examiner respectfully disagrees and reiterates that the claims, even as amended, are not drawn to patent eligible subject matter. Regarding Applicant’s arguments that instant claim including the newly added language is not directed to a mental process, Examiner submits the language as claimed still constitutes a user mentally receiving indications of the current locations, mentally determining a set of proposals, mentally determining/planning a ridesharing plan, and manually transmitting the proposals and an alert indicating new violations. No specific technology by which the claimed indications are collected or detected is described. Under broadest reasonable interpretation of the claim language, Examiner submits that the claims, even as amended, describe the elements of technology (i.e. receiving indications of the current locations of the ridesharing vehicles) at a very nominal level and therefore do not preclude performance in the mind. Additionally, Examiner submits that the instant claims are also drawn to the abstract idea grouping of certain methods of organizing human activity. Even as amended, the claims still invoke a rejection under 35 U.S.C. § 101 as described in the rejection below. As explained previously, the claim language and any related technological components are claimed at a very nominal level and do not describe the technological environment in which the computer elements are used to accomplish the overall invention drawn to manual operations in a ridesharing system. For at least these reasons and the reasons described in the rejection below, these claim limitations, either individually or as an ordered combination, do not amount to significantly more than the abstract idea itself and do not transform the nature of the claim from the judicial exception into a patent-eligible application. Although the invention teaches of a system including a communications interface and a processor, there is also no physical transformation or improvement to the technology that would be more than the idea of itself. Furthermore, in the current language, the claim is merely implemented or executed using a communications interface and a processor and therefore does not improve upon the technology or functionality of the computer beyond the abstract idea. In other words, Examiner submits that the inventive concept, i.e. an element or combination of elements that is “sufficient to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept (of an abstract idea itself)”, is unable to be determined within the limitations as claimed.
Applicant's arguments with respect to the rejection of the pending claims under 35 U.S.C. § 103 have been considered, however Examiner believes the previously applied prior art teaches of the new limitations as explained in the art rejection below. Regarding Applicant's argument that the cited references do not teach of the claims as amended, Ikeda et al. (US 2014/0365250 A1, herein Ikeda) in view of Stumpf et al. (US 2022/0164911 A1, herein Stumpf) has been further analyzed, as necessitated by amendment, to illustrate this aspect (see claim 1 rejection below). Regarding the rejection of newly added claims 19-20, ElShenawy (US 2020/0410555 A1, herein ElShenawy) has been brought in, necessitated by amendment, to illustrate this aspect (see claim 19 rejection below).
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-4, 6-13, and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a patent-ineligible abstract idea without significantly more and are merely requiring generic computer implementation, which fails to transform that abstract idea into a patent-eligible invention. In view of the two-step test regarding determining subject matter eligibility, Examiner submits that the independent claim(s) 1 and 10 recite(s) a system and method for manual operations in a ridesharing system. Therefore, the claims as a whole are considered as being in a statutory category under Step 1 of the test.
Regarding Step 2A, prong 1, Examiner submits that the claims as a whole are directed to a judicially recognized exception that is an abstract idea. The claimed invention is drawn to an abstract idea of manual operations in a ridesharing system, by specifically including “a communications interface configured to receive a plurality of requests for shared rides from a plurality of users”; “at least one processor configured to: receive, via the communications interface, the plurality of requests, each request including an origin, a time, and a destination for each rider associated with each request”; “receive…indications of the current locations of the ridesharing vehicles”; “determine a first set of proposals for scheduling the plurality of requests based on the received indications of current locations, wherein the first set of proposals includes scheduling violations”; “determine a ridesharing plan…”; transmit…the first set of proposals to a user; and “transmit…an alert indicating whether new violations are introduced”. First, the limitations of at least “…receive…the plurality of requests…”; “receive…indications of the current locations of the ridesharing vehicles”; “determine a first set of proposals for scheduling the plurality of requests…”; “determine a ridesharing plan…”; “transmit…the first set of proposals to a user”; and “transmit…an alert indicating whether new violations are introduced”, as drafted, are drawn to a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “by a processor”, or “via the communications interface” nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the “by a processor” language, “…receive…the plurality of requests…” and “receive…indications of the current locations of the ridesharing vehicles” in the context of this claim encompasses the user mentally receiving a ride request and/or indications of the current locations. Similarly, the limitation of “determine a first set of proposals for scheduling the plurality of requests…” and “determine a ridesharing plan…”, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. For example, but for the “by a processor” language, “determine a first set of proposals for scheduling the plurality of requests…” and/or “determine a ridesharing plan” in the context of this claim encompasses the user manually determining the set of proposals and/or a ridesharing plan, e.g. mentally and/or drafting the set of proposals and/or the ridesharing plan using pen and paper. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Furthermore, the limitations of at least “…receive, via the communications interface, the plurality of requests, each request including a origin, a time, and a destination for each rider associated with each request”; “receive…indications of the current locations of the ridesharing vehicles”; “determine a first set of proposals for scheduling the plurality of requests…wherein the first set of proposals includes scheduling violations”; “determine a ridesharing plan…”; “transmit…the first set of proposals to a user”; and “transmit…an alert indicating whether new violations are introduced”, as drafted are drawn to a process that, under its broadest reasonable interpretation, falls within the abstract idea grouping of Certain Methods of Organizing Human Activity (i.e. commercial or legal interactions including agreements in the form of contracts; legal obligations; advertising, marketing or sales activity or behaviors; business relations; or managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions). That is, the claims are directed to the concept of manual operations in a ridesharing system. If a claim limitation/invention, under its broadest reasonable interpretation, can be construed as describing advertising, marketing or sales activity or behaviors, business relations, or the managing of personal behavior or relationships or interactions between people, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. In particular, the steps together are accomplishing manual operations in a ridesharing system, which is related to the managing of personal behavior or relationships or interactions between people, including at least social activities, teaching, and following rules or instructions. Accordingly, the claims recite an abstract idea.
Regarding Step 2A, prong 2, Examiner submits that the claim as a whole does not integrate the recited judicial exception into a practical application of the exception. Examiner submits that the claims at hand in fact do not include any recitation of additional elements in the claim beyond the judicial exception that would integrate the judicial exception into a practical application. To be considered statutory, the claims require an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. In this regard, Examiner submits that there are no such additional elements that improve the functioning of a computer to any other technology or technical field, apply or use a judicial exception to effect a particular treatment, apply the judicial exception with or by use of a particular machine, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. In fact, the claims include language drawn to 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/or generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h). Accordingly, the claims recite an abstract idea.
Regarding Step 2B drawn to determining if the claim recites additional elements amounting to significantly more than the judicial exception, Examiner submits that the claims in fact do not include any recitation of additional elements that would constitute anything significantly more. In particular, the claim only recites the additional elements of a communications interface and a processor to perform the steps of the invention. The processor in the claimed steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of computing or processing) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea and amount(s) to no more than: (i) mere instructions to implement the idea on a computer, and/or (ii) recitation of generic computer structure that serves to perform generic computer functions that are well-understood, routine, and conventional activities previously known to the pertinent industry. Furthermore, the instant claims’ invocation of computers, and/or networks, and/or displays does not transform the claimed subject matter into patent-eligible applications. The claims at issue do not require any nonconventional computer, network, or display components, or even a “non-conventional and non-generic arrangement of known, conventional pieces,” but merely call for performance of the claimed information collection, analysis, and display functions “on a set of generic computer components” and display devices. Bascom, 2016 WL 3514158, at *6–7. Nothing in the claims, understood in light of the specification, requires anything other than off-the-shelf, conventional computer, network, and display technology for gathering, sending, and presenting the desired information. Such invocations of computers and networks that are not even arguably inventive are “insufficient to pass the test of an inventive concept in the application” of an abstract idea. buySAFE, 765 F.3d at 1353, 1355; see, e.g., Mortg. Grader, Inc. v. First Choice Loan Servs. Inc., 811 F.3d 1314, 1324–25 (Fed. Cir. 2016); Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370 (Fed. Cir. 2015); Internet Patents, 790 F.3d at 1348–49; Content Extraction, 776 F.3d at 1347–48. Therefore, these claim limitations, either individually or as an ordered combination, do not amount to significantly more than the abstract idea itself and do not transform the nature of the claim from the judicial exception into a patent-eligible application. The claims are not patent eligible.
Regarding claims 2-4, 6-9, 11-13, and 15-20, the dependent claims do not include any additional elements that constitute statutory matter. The dependent claims are directed to the same abstract idea as recited in the independent claims and have been found to either recite additional details that are part of the abstract idea itself (when analyzed under Step 2A Prong One), or include additional details that, when analyzed under Step 2A Prong Two and Step 2B, recite additional elements that fail to integrate the abstract idea into a practical application (Step 2A Prong Two) and fail to add significantly more to the abstract idea (Step 2B). Specifically, claims 2, 4, 11, and 13 describe details regarding receiving an additional request and determining a second set of proposals and transmitting the second set accordingly. Claims 3, 6-7, 12, and 15-16 describe additional details regarding the scheduling violations. The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claims) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea itself. The dependent claims also recite steps that together with the independent claims are accomplishing the overall process of manual operations in a ridesharing system, which falls within the abstract idea grouping of Mental Processes and/or Certain Methods of Organizing Human Activity (i.e. commercial or legal interactions including agreements in the form of contracts; legal obligations; advertising, marketing or sales activity or behaviors; business relations; or managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions), as described above. Accordingly, the dependent claims are drawn to an abstract idea.
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.
Claim(s) 1-4, 8-13, and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ikeda et al. (US 2014/0365250 A1, herein Ikeda) in view of Stumpf et al. (US 2022/0164911 A1, herein Stumpf).
As per claim 1, Ikeda teaches of a system for managing a fleet of ridesharing vehicles, the system comprising:
a communications interface configured to receive a plurality of requests for shared rides from a plurality of users (pg. 2, [0025] which describes the transportation service reservation apparatus as a computer that accepts a ride request for a transportation service and executes a process for generating a ride option according to the ride request);
at least one processor configured to (pg. 1, [0024] and Fig. 1, which describes the transportation service reservation system, including a transportation service reservation apparatus and at least one user terminal; and pg. 2, [0033] and Fig. 2, which describes a hardware configuration of a transportation service reservation apparatus, including ga drive unit, a secondary storage unit, a memory unit, a central processing unit, and an interface, all connected by bus B):
receive, via the communications interface, the plurality of requests, each request including a origin, a time, and a destination for each rider associated with each request (pg. 1, [0005] which describes the transportation service reservation method including receiving a ride request specifying an origin and a destination; and pg. 2, [0025] which describes the transportation service reservation apparatus as a computer that accepts a ride request for a transportation service; and pg. 3, [0040] which describes the request reception part that receives a ride request, where the ride request includes conditions specified with respect to a ride, such as a user ID, which is information identifying a user, a ride date, an origin, and a destination; pg. 3, [0054] which describes the input control part of the user terminal that receives a group of parameters relating to a ride request input from a user, including user ID, a ride date, an origin, and a destination, at least one of a preferred departure time and a preferred arrival time, and/or the number of passengers or the number of seats);
determine a first set of proposals for scheduling the plurality of requests;
determine a ridesharing plan in accordance with the determined first set of proposals and optimize scheduling of requests (pg. 1, [0005] which describes generating a feasible ride option pertaining to multiple forms of ride…and selecting a subset to be offered in response to the ride request from among the one or more subsets satisfying the predetermined condition; and pg. 2, [0025] which describes the transportation service reservation apparatus as a computer that executes a process for generating a ride option according to the ride request; and pg. 3, [0041] which describes the ride option generation part that generates feasible ride options with respect to each vehicle and each form of ride based on the ride request, referring to schedules stored in the schedule information storage part; and pg. 3, [0046] which describes how the ride option selection part selects a combination of ride options to be offered to a user from among the subsets that satisfy a predetermined condition that maximizes the representative utility of a user; and pg. 6, [0093-0095] which describes if the updated existing schedule satisfies predetermined constraint condition, such as the constraint of the capacity of the vehicle, if the difference between the pickup time in the updated schedule and the pickup time provided at the time of reservation and the difference between the drop-off time in the updated schedule and the drop-off time provided at the time of the reservation are within a threshold with respect to each user of the updated schedule, and/or whether or not the travel time is less than or equal to a maximum value with respect to a user pertaining to the ride request and other users of the updated schedule, where the maximum travel time may differ from user to user); and
transmitting, via the communications interface, the first set of proposals to a user (pg. 3, [0047] which describes the response transmission part that returns the information of each of the ride options of the combination of ride options determined by the ride option selection part as a response to the ride request).
Ikeda teaches of a transportation service reservation method, but fails to explicitly teach of receiving indications of the current locations of the ridesharing vehicles, determining a set of proposals that includes scheduling violations, and determining a ridesharing plan that minimizes scheduling violations. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically to:
receive, via the communications interface, the plurality of requests (abstract which describes receiving a ride request from a user having a user profile, the ride request including a requested drop-off location within a service area and the user profile specifying at least one drop-off location preference parameter; and pg. 7, [0084] which describes the destination information system for a ride share service for transporting a user in response to receipt of a ride request);
receive, via the communications interface, indications of the current locations of the ridesharing vehicles (pg. 3, [0026] which describes the autonomous vehicle that includes at least global positioning system (GPS); and pg. 7, [0084] which describes a destination information system for a ride share service for transporting a user including at least a database for storing data collected by a plurality of vehicles traversing the service area and equipped with at least one of at least one sensor and at least one imaging device for collecting the data; and a real time fleet information (RTFI) module);
determine a first set of proposals for scheduling the plurality of requests based on the received indications of current locations, wherein the first set of proposals includes scheduling violations (abstract and pg. 7, [0084] which describes a destination information system for a ride share service for transporting a user including at least a database for storing data collected by a plurality of vehicles traversing the service area and equipped with at least one of at least one sensor and at least one imaging device for collecting the data; and a real time fleet information (RTFI) module configured to obtain data regarding a condition of the requested drop-off location and determine whether the drop obtained data satisfies at least one drop-off location preference parameter specified in the user profile, and determine at least one alternative drop-off location within a first distance from the requested drop-off location if the obtained data does not satisfy the at least one drop-off location preference parameter);
determine a ridesharing plan in accordance with the determined first set of proposals and optimize scheduling of requests to minimize scheduling violations (pg. 3, [0027] which describes how the driving behavior includes any information relating to how an autonomous vehicle drives given a set of instructions (e.g. a route or plan), where elements that contribute to driving behavior include at least routing preferences and lighting preferences; and pg. 7, [0090] which describes the embodiments of the invention that may be configured to operate in a manner that achieves or optimizes one advantage or group of advantages without necessarily achieving other objects or advantages as may be taught or suggested);
transmit, via the communications interface, the first set of proposals to a user; and
transmit, via the communications interface, an alert indicating whether new violations are introduced (pg. 5, [0041-0043] and Fig. 3, which describes the method including a rideshare application used by the user to specify drop-off point condition preferences along, to further refine the parameter by specifying a threshold or other limiting factor determining compliance of the drop-off point condition with the parameter, and/or specify whether the user would like to be advised of conditions of the selected drop-off point that do not comply with the parameter as optionally refined and if the user would prefer to be provided with a list of options of alternative drop-off points from which to select; and pg. 5, [0044] which describes how the user may be provided with options relating to a limit on the maximum distance between the originally selected drop-off point and alternative drop-off points suggested or deployed; and pg. 6, [0059-0062] which describes determining if conditions at the drop-off location satisfy the user preferences as set forth in the user’s profile, where if not, the database is queried for alternative drop-off locations and a determination is made whether one of the alternative drop-off locations better satisfies the user’s preferences and the user is then provided with the message developed and the alternative drop-off location (or locations) is recommended and presented to the user).
Ikeda teaches of a transportation service reservation method. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically including the scheduling violations as claimed. Both references are drawn to managing rideshares. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda with the included scheduling violations as taught by Stumpf for the purpose of accessing real time information regarding their destination to enable users to better plan for their trip or modify their selected drop-off point (Stumpf, pg. 1, [0002]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of arranging rideshares to mutually benefit the passenger and the drive.
As per claim 10, it refers to a method for performing the above steps. It recites limitations already addressed by claim 1 above, and is therefore rejected under the same art and rationale. Furthermore, Ikeda et al. (US 2014/0365250 A1, herein Ikeda) discloses the steps are performed by a transportation service reservation method (pg. 1, [0005]).
As per claim 2, Ikeda in view of Stumpf discloses all the elements of claim 1, and Ikeda further teaches wherein the processor is further configured to:
receive, via the communications interface, an additional request for a shared ride (pg. 1, [0005] which describes the transportation service reservation method including receiving a ride request specifying an origin and a destination; and pg. 2, [0025] which describes the transportation service reservation apparatus as a computer that accepts a ride request for a transportation service; and pg. 3, [0040] which describes the request reception part that receives a ride request, where the ride request includes conditions specified with respect to a ride, such as a user ID, which is information identifying a user, a ride date, an origin, and a destination; pg. 3, [0054] which describes the input control part of the user terminal that receives a group of parameters relating to a ride request input from a user, including user ID, a ride date, an origin, and a destination, at least one of a preferred departure time and a preferred arrival time, and/or the number of passengers or the number of seats);
determine by the processor, a second set of proposals that includes the additional request for the shared ride (pg. 1, [0005] which describes generating a feasible ride option pertaining to multiple forms of ride…and selecting a subset to be offered in response to the ride request from among the one or more subsets satisfying the predetermined condition; and pg. 2, [0025] which describes the transportation service reservation apparatus as a computer that executes a process for generating a ride option according to the ride request; and pg. 3, [0041] which describes the ride option generation part that generates feasible ride options with respect to each vehicle and each form of ride based on the ride request, referring to schedules stored in the schedule information storage part; and pg. 3, [0046] which describes how the ride option selection part selects a combination of ride options to be offered to a user from among the subsets that satisfy a predetermined condition that maximizes the representative utility of a user; and pg. 6, [0093-0095] which describes if the updated existing schedule satisfies predetermined constraint condition, such as the constraint of the capacity of the vehicle, if the difference between the pickup time in the updated schedule and the pickup time provided at the time of reservation and the difference between the drop-off time in the updated schedule and the drop-off time provided at the time of the reservation are within a threshold with respect to each user of the updated schedule, and/or whether or not the travel time is less than or equal to a maximum value with respect to a user pertaining to the ride request and other users of the updated schedule, where the maximum travel time may differ from user to user); and
transmit, via the communications interface, the second set of proposals for scheduling the plurality of the requests to a user (pg. 3, [0047] which describes the response transmission part that returns the information of each of the ride options of the combination of ride options determined by the ride option selection part as a response to the ride request).
Ikeda teaches of a transportation service reservation method, but fails to explicitly teach of a set of proposals that includes scheduling violations. Stumpf further teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically to:
receive, via the communications interface, an additional request for a shared ride;
determine by the processor, a second set of proposals that includes the additional request for the shared ride, wherein the second set of proposals does not increase a number of scheduling violations compared to the first set of proposals, and wherein the additional request for a shared ride may include a scheduling violation; and
transmit, via the communications interface, the second set of proposals for scheduling the plurality of the requests to a user (abstract which describes receiving a ride request from a user having a user profile, the ride request including a requested drop-off location within a service area and the user profile specifying at least one drop-off location preference parameter, querying a database to obtain data regarding a condition of the requested drop-off location, determining whether the obtained data satisfies the at least one drop-off location preference parameter, and determining at least one alternative drop-off location within a first distance from the requested drop-off location if the obtained data does not satisfy the at least one drop-off location preference parameter; and pg. 5, [0041-0043] and Fig. 3, which describes the method including a rideshare application used by the user to specify drop-off point condition preferences along, to further refine the parameter by specifying a threshold or other limiting factor determining compliance of the drop-off point condition with the parameter, and/or specify whether the user would like to be advised of conditions of the selected drop-off point that do not comply with the parameter as optionally refined and if the user would prefer to be provided with a list of options of alternative drop-off points from which to select; and pg. 5, [0044] which describes how the user may be provided with options relating to a limit on the maximum distance between the originally selected drop-off point and alternative drop-off points suggested or deployed; and pg. 6, [0053] which describes how the method may preferably be executed continuously for each AV in the fleet while the AV is in service; and pg. 6, [0059-0062] which describes determining if conditions at the drop-off location satisfy the user preferences as set forth in the user’s profile, where if not, the database is queried for alternative drop-off locations and a determination is made whether one of the alternative drop-off locations better satisfies the user’s preferences and the user is then provided with the message developed and the alternative drop-off location (or locations) is recommended and presented to the user).
Ikeda teaches of a transportation service reservation method. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically including the scheduling violations as claimed. Both references are drawn to managing rideshares. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda with the included scheduling violations as taught by Stumpf for the purpose of accessing real time information regarding their destination to enable users to better plan for their trip or modify their selected drop-off point (Stumpf, pg. 1, [0002]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of arranging rideshares to mutually benefit the passenger and the drive.
As per claim 11, it refers to the method of claim 10 used for performing the above steps. It recites limitations already addressed by claim 2 above, and is therefore rejected under the same art and rationale.
As per claim 3, Ikeda in view of Stumpf discloses all the elements of claim 1, and Stumpf further teaches wherein the one or more scheduling violations are based on one or more walking distance outside of an allowable walking distance from pick-up/drop off location, pick-up/drop-off time outside of the pick-up/drop off time window, or any combination thereof (abstract which describes receiving a ride request from a user having a user profile, the ride request including a requested drop-off location within a service area and the user profile specifying at least one drop-off location preference parameter, querying a database to obtain data regarding a condition of the requested drop-off location, determining whether the obtained data satisfies the at least one drop-off location preference parameter, and determining at least one alternative drop-off location within a first distance from the requested drop-off location if the obtained data does not satisfy the at least one drop-off location preference parameter; and pg. 5, [0041-0043] and Fig. 3, which describes the method including a rideshare application used by the user to specify drop-off point condition preferences along, to further refine the parameter by specifying a threshold or other limiting factor determining compliance of the drop-off point condition with the parameter, and/or specify whether the user would like to be advised of conditions of the selected drop-off point that do not comply with the parameter as optionally refined and if the user would prefer to be provided with a list of options of alternative drop-off points from which to select; and pg. 5, [0045] which describes how parameters may be selectively conditionally activated and/or refined based on ride-specific factors, such as if the user is alone or with others, the time of day, week, or year, a geographic location of the service area in which the user is traveling, weather conditions, environmental conditions, or a combination of one or more of those; and pg. 6, [0059-0062] which describes determining if conditions at the drop-off location satisfy the user preferences as set forth in the user’s profile, where if not, the database is queried for alternative drop-off locations and a determination is made whether one of the alternative drop-off locations better satisfies the user’s preferences and the user is then provided with the message developed and the alternative drop-off location (or locations) is recommended and presented to the user).
Ikeda teaches of a transportation service reservation method. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically including the scheduling violations as claimed. Both references are drawn to managing rideshares. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda with the included scheduling violations as taught by Stumpf for the purpose of accessing real time information regarding their destination to enable users to better plan for their trip or modify their selected drop-off point (Stumpf, pg. 1, [0002]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of arranging rideshares to mutually benefit the passenger and the drive.
As per claim 12, it refers to the method of claim 10 used for performing the above steps. It recites limitations already addressed by claim 3 above, and is therefore rejected under the same art and rationale.
As per claim 4, Ikeda in view of Stumpf discloses all the elements of claim 1, and Ikeda further teaches wherein the processor is further configured to:
receive, via the communications interface, a scheduled ride having a set pick-up time, set pick-up location, a set drop-off time, a set drop-off location, or any combination thereof (pg. 1, [0005] which describes the transportation service reservation method including receiving a ride request specifying an origin and a destination; and pg. 2, [0025] which describes the transportation service reservation apparatus as a computer that accepts a ride request for a transportation service; and pg. 3, [0040] which describes the request reception part that receives a ride request, where the ride request includes conditions specified with respect to a ride, such as a user ID, which is information identifying a user, a ride date, an origin, and a destination; pg. 3, [0054] which describes the input control part of the user terminal that receives a group of parameters relating to a ride request input from a user, including user ID, a ride date, an origin, and a destination, at least one of a preferred departure time and a preferred arrival time, and/or the number of passengers or the number of seats; and pg. 4, [0067-0069] which describes how the user determines a ride option that the user wishes to use, then the user terminal receives one ride option selected from the ride options displayed, and the reservation request is received by the request reception part of the transportation service reservation apparatus and the reservation process part updates the schedule information and adds new schedule information to the reservation information storage part);
determine, via the processor, an updated set of proposals with the scheduled ride having the received set pick-up location, the set drop-off time, the set drop-off location, or any combination thereof (pg. 1, [0005] which describes generating a feasible ride option pertaining to multiple forms of ride…and selecting a subset to be offered in response to the ride request from among the one or more subsets satisfying the predetermined condition; and pg. 2, [0025] which describes the transportation service reservation apparatus as a computer that executes a process for generating a ride option according to the ride request; and pg. 3, [0041] which describes the ride option generation part that generates feasible ride options with respect to each vehicle and each form of ride based on the ride request, referring to schedules stored in the schedule information storage part; and pg. 3, [0046] which describes how the ride option selection part selects a combination of ride options to be offered to a user from among the subsets that satisfy a predetermined condition that maximizes the representative utility of a user; and pg. 6, [0093-0095] which describes if the updated existing schedule satisfies predetermined constraint condition, such as the constraint of the capacity of the vehicle, if the difference between the pickup time in the updated schedule and the pickup time provided at the time of reservation and the difference between the drop-off time in the updated schedule and the drop-off time provided at the time of the reservation are within a threshold with respect to each user of the updated schedule, and/or whether or not the travel time is less than or equal to a maximum value with respect to a user pertaining to the ride request and other users of the updated schedule, where the maximum travel time may differ from user to user); and
transmit, via the communications interface, the updated set of proposals to the user (pg. 3, [0047] which describes the response transmission part that returns the information of each of the ride options of the combination of ride options determined by the ride option selection part as a response to the ride request).
Ikeda teaches of a transportation service reservation method, but fails to explicitly teach of a set of proposals that includes scheduling violations. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically to:
receive, via the communications interface, a scheduled ride;
determine, via the processor, an updated set of proposals with the scheduled ride, while minimizing violations; and
transmit, via the communications interface, the updated set of proposals to the user (abstract which describes receiving a ride request from a user having a user profile, the ride request including a requested drop-off location within a service area and the user profile specifying at least one drop-off location preference parameter, querying a database to obtain data regarding a condition of the requested drop-off location, determining whether the obtained data satisfies the at least one drop-off location preference parameter, and determining at least one alternative drop-off location within a first distance from the requested drop-off location if the obtained data does not satisfy the at least one drop-off location preference parameter; and pg. 5, [0041-0043] and Fig. 3, which describes the method including a rideshare application used by the user to specify drop-off point condition preferences along, to further refine the parameter by specifying a threshold or other limiting factor determining compliance of the drop-off point condition with the parameter, and/or specify whether the user would like to be advised of conditions of the selected drop-off point that do not comply with the parameter as optionally refined and if the user would prefer to be provided with a list of options of alternative drop-off points from which to select; and pg. 5, [0044] which describes how the user may be provided with options relating to a limit on the maximum distance between the originally selected drop-off point and alternative drop-off points suggested or deployed; and pg. 6, [0053] which describes how the method may preferably be executed continuously for each AV in the fleet while the AV is in service; and pg. 6, [0059-0062] which describes determining if conditions at the drop-off location satisfy the user preferences as set forth in the user’s profile, where if not, the database is queried for alternative drop-off locations and a determination is made whether one of the alternative drop-off locations better satisfies the user’s preferences and the user is then provided with the message developed and the alternative drop-off location (or locations) is recommended and presented to the user).
Ikeda teaches of a transportation service reservation method. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically including the scheduling violations as claimed. Both references are drawn to managing rideshares. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda with the included scheduling violations as taught by Stumpf for the purpose of accessing real time information regarding their destination to enable users to better plan for their trip or modify their selected drop-off point (Stumpf, pg. 1, [0002]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of arranging rideshares to mutually benefit the passenger and the drive.
As per claim 13, it refers to the method of claim 10 used for performing the above steps. It recites limitations already addressed by claim 4 above, and is therefore rejected under the same art and rationale.
As per claim 8, Ikeda in view of Stumpf discloses all the elements of claim 1, and Ikeda further teaches wherein the first set of proposals is ordered based on diversity, costs, or both (pg. 3, [0045] which describes how the predetermine condition may be the condition that the elements of a subset are three ride options that are difference in service type from one another).
Stumpf also further teaches wherein the first set of proposals is ordered based on diversity, costs, or both (pg. 5, [0045] which describes how parameters may be selectively conditionally activated and/or refined based on ride-specific factors, such as if the user is alone or with others, the time of day, week, or year, a geographic location of the service area in which the user is traveling, weather conditions, environmental conditions, or a combination of one or more of those, where the user may also be permitted to indicate a relative importance of the activated parameters, where one may be more important than the other and the relative importance may have a direct impact on which of several drop off points would be more preferable to the user).
Ikeda teaches of a transportation service reservation method. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically including the scheduling violations as claimed. Both references are drawn to managing rideshares. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda with the included scheduling violations as taught by Stumpf for the purpose of accessing real time information regarding their destination to enable users to better plan for their trip or modify their selected drop-off point (Stumpf, pg. 1, [0002]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of arranging rideshares to mutually benefit the passenger and the drive.
As per claim 17, it refers to the method of claim 10 used for performing the above steps. It recites limitations already addressed by claim 8 above, and is therefore rejected under the same art and rationale.
As per claim 9, Ikeda in view of Stumpf discloses all the elements of claim 1, and Stumpf further teaches wherein each request further includes a driver break time, a request to be picked up with another rider, a gas station break, a maximum travel time, a drop off time, a number of shared riders, or any combination thereof (abstract which describes receiving a ride request from a user having a user profile, the ride request including a requested drop-off location within a service area and the user profile specifying at least one drop-off location preference parameter, querying a database to obtain data regarding a condition of the requested drop-off location, determining whether the obtained data satisfies the at least one drop-off location preference parameter, and determining at least one alternative drop-off location within a first distance from the requested drop-off location if the obtained data does not satisfy the at least one drop-off location preference parameter; and pg. 5, [0041-0043] and Fig. 3, which describes the method including a rideshare application used by the user to specify drop-off point condition preferences along, to further refine the parameter by specifying a threshold or other limiting factor determining compliance of the drop-off point condition with the parameter, and/or specify whether the user would like to be advised of conditions of the selected drop-off point that do not comply with the parameter as optionally refined and if the user would prefer to be provided with a list of options of alternative drop-off points from which to select; and pg. 6, [0070-0072] which describes the example of determining at least one alternative drop-off location within a first distance from the requested drop-off location if the obtained data does not satisfy the at least one drop-off location preference parameter, where the first distance is specified by the user in the user profile; and pg. 7, [0078] which describes how a preference expressed by the drop-off location preference parameter is dependent on at least one of time of day, time of week, and time of year; and pg. 7, [0080] which describes additional examples where the preference expressed by the drop-off location preference parameter is depending on a number of passengers; and pg. 7, [0089] which describes how if the obtained portion of data does not satisfy the at least one drop-off location preference parameter, at least one alternative drop-off location within a first distance from the requested drop-off location being determined and suggested to the user).
Ikeda teaches of a transportation service reservation method. Stumpf teaches of rideshare services, more specifically to devices and methods for enabling delivery of enhanced information about a selected destination to a rideshare service user, specifically including the scheduling violations as claimed. Both references are drawn to managing rideshares. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda with the included scheduling violations as taught by Stumpf for the purpose of accessing real time information regarding their destination to enable users to better plan for their trip or modify their selected drop-off point (Stumpf, pg. 1, [0002]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of arranging rideshares to mutually benefit the passenger and the drive.
As per claim 18, it refers to the method of claim 10 used for performing the above steps. It recites limitations already addressed by claim 9 above, and is therefore rejected under the same art and rationale.
Claim(s) 6-7 and 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ikeda et al. (US 2014/0365250 A1, herein Ikeda) in view of Stumpf et al. (US 2022/0164911 A1, herein Stumpf) in further view of Mahimkar et al. (US 2021/0250232 A1, herein Mahimkar).
As per claim 6, Ikeda in view of Stumpf discloses all the elements of claim 4, but fail to explicitly teach of setting the violations in the updated set of proposals as permissible. Mahimkar further teaches of conflict-free change deployment, including determining an optimized schedule for change deployment, specifically wherein if the updated set of proposals has more violations than the first set of proposals, setting the violations in the updated set of proposals as permissible for the shift going forward (pg. 2, [0020] which describes how policies for conflict avoidance may be obtained from the request or may already be predetermine, e.g. preloaded based on previous determinations or entries; and pg. 3, [0028] which describes the goal of minimizing the number of conflicts and tradeoff with the completion time, where there may be a conflict tolerance that is considered when determining a network change schedule, for allowing the operations teams to let the optimization engine provide a schedule that has minimum number of conflicts (tolerance) at the benefit of completion of the change activity within a tighter time-window, where conflicts may be allowed to persist with an understanding of an increased level of complete outages or intermittent interrupted service than preferred).
Ikeda in view of Stumpf teaches of a transportation service reservation method, including scheduling violations. Mahimkar teaches of conflict-free change deployment, including determining an optimized schedule for change deployment, specifically including the setting of permissible violations as claimed. All references are drawn to managing schedules. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda in view of Stumpf with the included setting of permissible violations as taught by Mahimkar for the purpose of determining an optimized schedule for change deployment (Mahimkar, abstract and pg. 1, [0016]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of coordinating schedule management in the most optimized manner.
As per claim 15, it refers to the method of claim 13 used for performing the above steps. It recites limitations already addressed by claim 6 above, and is therefore rejected under the same art and rationale.
As per claim 7, Ikeda in view of Stumpf discloses all the elements of claim 1, but fail to explicitly teach of a threshold of violations. Mahimkar further teaches of conflict-free change deployment, including determining an optimized schedule for change deployment, specifically wherein the first set of proposals includes a number of violations that is below a threshold (pg. 3, [0024-0026] which describes scheduling as a best available based on one or more factors, such as policies for conflict avoidance, including determining whether a threshold is reached, based on time, number of requests received or not received, type of requests received, bandwidth usage, processor usage, etc., where based on reaching the threshold, processing the batch of requests to determine a schedule that may have no or minimal conflicts).
Ikeda in view of Stumpf teaches of a transportation service reservation method, including scheduling violations. Mahimkar teaches of conflict-free change deployment, including determining an optimized schedule for change deployment, specifically including the setting of permissible violations as claimed. All references are drawn to managing schedules. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda in view of Stumpf with the included setting of permissible violations as taught by Mahimkar for the purpose of determining an optimized schedule for change deployment (Mahimkar, abstract and pg. 1, [0016]). By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of coordinating schedule management in the most optimized manner.
As per claim 16, it refers to the method of claim 10 used for performing the above steps. It recites limitations already addressed by claim 7 above, and is therefore rejected under the same art and rationale.
Claim(s) 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ikeda et al. (US 2014/0365250 A1, herein Ikeda) in view of Stumpf et al. (US 2022/0164911 A1, herein Stumpf) in further view of ElShenawy (US 2020/0410555 A1, herein ElShenawy).
As per claim 19, Ikeda in view of Stumpf discloses all the elements of claim 1 and Stumpf further teaches of identifying the scheduling violation (abstract; and pg. 5, [0041-0043] and Fig. 3), but fails to explicitly teach of generating a suggested override identifying the scheduling violations. ElShenawy teaches of technology pertaining to an improved user experience for user accounts taking group rideshare rides and dynamic rideshare service behavior based on past passenger experience data, specifically wherein the processor is configured to generate a suggested override identifying the scheduling violation (pg. 3, [0035] which describes the internal computing system that can include a user interface service that communicates with the cabin system in order to provide information or receive information to a human co-pilot or human passenger, such as requiring the human co-pilot or human passenger to evaluate and override a constraint from the constraint service and/or provide an instruction to the autonomous vehicle regarding destinations, requested routes, or other requested operations).
Ikeda in view of Stumpf teaches of a transportation service reservation method, including scheduling violations. ElShenawy teaches of dynamic rideshare service behavior based on past passenger experience data, specifically including the suggested override as claimed. All references are drawn to managing schedules and rideshare services. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ikeda in view of Stumpf with the included suggested override as taught by ElShenawy for the purpose of providing a better user experience with a rideshare service (ElShenawy, pg.1, [0017]). By doing so, one would reasonably expect the overall appeal of the invention to improve in functionality by providing a better overall experience for the user.
As per claim 20, it refers to the method of claim 10 used for performing the above steps. It recites limitations already addressed by claim 19 above, and is therefore rejected under the same art and rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Van Buskirk (US 2009/0248587 A1) teaches of a selectively negotiated ridershare system comprising riders, drivers, and vehicles.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHLEY Y YOUNG whose telephone number is (571)270-5294. The examiner can normally be reached Mondays, Tuesdays, and Thursdays, 9:00a-3:00p, EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Beth Boswell can be reached at (571) 272-6737. 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.
/ASHLEY Y YOUNG/Examiner, Art Unit 3625
/BETH V BOSWELL/Supervisory Patent Examiner, Art Unit 3625
Prosecution Insights