DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice to Applicant
The following is a Final Office action. In response to Examiner’s Non-Final Rejection of 3/18/26, Applicant, on 6/5/26, amended claims. Claims 1-6 and 10 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The 112a rejection are withdrawn.
The previous 112b rejections are withdrawn. New 112b antecedent basis rejections, necessitated by the amendments, are now presented.
Reasons for Subject Matter Eligibility under 35 USC 101
The claim 1 overcomes the 101 rejections because the claim is now : performing by the management server, a first matching suitability between the operating vehicle and the passenger based on the driving information and the passenger information, using at least one passenger matching condition set in the management server, then performing a final matching determination by the driver terminal based on the driving information and the passenger information using a passenger matching condition selected by a driver and a reference value set by the driver, for the selected at least one passenger matching condition, in the driver terminal independently from the management server. When viewing the claim as a whole, this when combined with the earlier limitations is viewed as a practical application under step 2a, prong 2, as the claim is improving another technology when viewing all the limitations listed above (See MPEP 2106.05a – e.g. Enfish; “improvements to computer functionality” – see vii. vii. Particular structure of a server that stores organized digital images, TLI Communications, 823 F.3d at 612; DDR Holdings; Applicant’s Remarks 8/13/25 pages 19-20 (showing Applicant’s FIG. 3, and explanation), pages 25-27) and/or is viewed as a using a judicial exception in a meaningful way under MPEP 2106.05(e), as it requires a particular arrangement for when processing is conducted on a local driver terminal in combination with when processing is conducted on a server. The same reasons also apply to independent claim 4, which has similar limitations.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-3 and 5-6 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation “The allocation management method of claim 1, wherein the (c) performing comprises (ci) determining, by the management server, a total estimated travel time obtained by: adding an estimated travel time from the current location of the operating vehicle to the departure point of the passenger, adding an estimated travel time from the departure point of the passenger to the destination of the passenger, and adding an estimated travel time from the destination of the passenger to the arrival point of the operating vehicle.” There is insufficient antecedent basis for this limitation in the claim as each of these limitations are now added to claim 1. Examiner notes – much of claim 2 is in claim 1 – it is possible claim 2 should just be cancelled.
Claim 5 recites similar limitations and is rejected for the same reasons.
Claims 3 and 6 depend from claim 2, 5 and are rejected for the same reasons.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-6 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Kuncl (US 2018/0330621) in view of Tang (US 2016/0182312), and further in view of Wang (US 2017/0220966).
Concerning claim 1, Kuncl discloses:
An allocation management method for a vehicle being driven to an arrival point (Kuncl – See par 31-32 - the network computer system 100 may also optimize the selection of service providers individually, so as to maximize the objective of individual service providers (e.g., increased amount of service provided, minimize downtime, etc.); “service providers” of service vehicles for service requests of transport-related services; See par 56 - system 200 includes a profile component 270 to continuously develop profile information about service providers. The profile information 275 may be specific to geolocation, to identify, for example, preferred locations where the service provider pauses or ends a shift.), the allocation management method comprising:
(a) receiving, by a management server (Kuncl – see par 21 - FIG. 1 illustrates a network computer system to manage the positioning of service vehicles in a geographic region. A network computer system 100 such as shown by FIG. 1 can be implemented in a variety of computing environments, including as part of a network service provided through one or more servers; see par 32 - a service arrangement system 200 (FIG. 2) may be implemented as a network service, using, for example, a network computer system 100 such as described with an example of FIG. 1.), driving information including current location information of an operating vehicle (Kuncl – see par 23 - The estimated quantity of service providers may be determined from the historical trip data 124 for the geographic region, and a current or recent location of individual service providers. see par 36 - provider device 202 may repeatedly or continuously communicate service information 203 to the system 200. The service information 203 may include the provider's identifier 205, and the provider's current location 207, which may be determined by the service application interfacing with a GPS component of the provider device 202.) and arrival point information of the operating vehicle, from a driver terminal (Applicant’s [0041] as published gives example – “the arrival point of the operating vehicle 10-1 may be a returning place of the driver who finished the day's operation or a garage where the driver has to return the operating vehicle 10-1, and in this case, the present disclosure may be the allocation management method for a returning vehicle.”
Kuncl discloses the limitations based on broadest reasonable interpretation in light of the specification – See par 56 - system 200 includes a profile component 270 to continuously develop profile information about service providers. The profile information 275 may be specific to geolocation, to identify, for example, preferred locations (describing an “arrival point”) where the service provider pauses or ends a shift. see par 71 - the system 200 may determine a preference or propensity for the service provider to stop service (e.g., go off duty) at a particular time. For example, the service provider may have a preference to stop service at a particular location (describing an “arrival point”) and time for a personal appointment. The system 200 can learn the propensity of the service provider, and then plan the location bias for the service provider so that the service provider is near the stopping location at the particular time);
(b) receiving, by the management server, passenger information including departure point information and first destination information of a passenger, from a passenger terminal (Kuncl – see par 34, FIG. 2 - system 200 to establish communication channels with individual devices of requesters; The requesters may also operate mobile devices (represented in FIG. 2 by the requester device 204) on which a corresponding service application 218 runs. The requesters may operate respective service applications 218 to request transport-related services, such as human transport between a start location (or pickup location) (describing a “departure point”) and a destination (or drop-off) (describing “destination information”).); and
(c) performing, by the management server, a first matching suitability determination of the operating vehicle and the passenger, based on the driving information and the passenger information, using at least one passenger matching condition set in a management server and at least one reference value set in the management server (Applicant’s [0068 as published] state : “even when the matching suitability determination performed by the determining unit 250 of the management server 200 has passed according to information about a passenger matching condition and reference values set by a manager, the driver may finally perform the matching suitability determination additionally according to the information about the passenger matching condition and reference values personally set according to his/her tendency and situation as described above.
Kuncl discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 40 - In one implementation, the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers, as provided by the service data store 230. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel).
See also Tang – see par 26 - the network node 315 selects which of the contractors 325 will provide the service to the user 310, defines the terms of the service agreement, and then confirms the service agreement with the selected contractor 325 and user 310. For example, the network node 315 may filter the contractors 325 based on their real-time locations (e.g., proximity to the user 310, etc.) or some other criteria, and then present the remaining subset of contractors with the opportunity to fulfill the service request under pre-defined terms).
(d) transmitting, by the management server, the passenger information to the driver terminal (Kuncl – see par 39 - The requester device interface 220 can parse individual service requests 201 to determine one or more service locations 209 of the service request, including the service start location and/or the service destination location. see par 40 - the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers, as provided by the service data store 230. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel). From the queried result set, the matching component 240 makes a selection of a service provider for the service request 201. The service provider may receive the matched service request as an invitation);
(e) performing, by the driver terminal, a final matching suitability determination of the operating vehicle and the passenger based on the driving information and the passenger information (Applicant’s [0063-0064] further state : “Information about the passenger matching condition and a reference value personally set by the driver.” Applicant’s [0054] as published states “shown in FIG. 4… an estimated travel time t3 from the destination 4 of the passenger to an arrival point 2 of the operating vehicle 10-1, determine whether a difference value between a total estimated travel time (t1+t2+t3) obtained by adding the same and an estimated travel time T1 from the current location 1 of the operating vehicle 10-1 to the arrival point 2 of the operating vehicle 10-1 is less than a predetermined first reference value α (for example, 10 minutes),”… then “the passenger is suitable” – see Equation 1; [0062] as published states “In addition, in implementing the present disclosure, the driver may personally set a passenger matching condition as described above, via the operating driver terminal 300-1. In detail, the driver may select one or at least two equations to be necessarily satisfied from among three equations above, such that matching with the passenger is determined to be suitable, according to his/er tendency and situation.”; see [0057-0058] as published – Equation 2 -a case where Equation 2 is satisfied is a case where the time t1 taken for the driver to deviate from an original moving path ((1).fwdarw.(2)) and arrive at the departure point 3 of the passenger so as to take the passenger is less than the predetermined second reference value β, for example, 3 minutes, and the determining unit 250 of the management server 200 determines that the matching between the operating vehicle 10-1 and the passenger is suitable; [0059] as published – Equation 3 - the determining unit 250 of the management server 200 may determine that the matching between the operating vehicle 10-1 and the passenger is suitable when a distance D from the destination 4 of the passenger to the arrival point 2 of the operating vehicle 10-1 is less than a predetermined third reference value γ, for example, 2 km (i.e., when Equation 3 is satisfied). In light of 112 rejections and the various paragraphs, for purposes of applying prior art only, Examiner interprets the limitations as including the scope of two of the three equations, where one condition could be “time” from Equation 1 or 2; or “distance” deviating from Equation 3.
PNG
media_image1.png
428
584
media_image1.png
Greyscale
Kuncl discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 13 - positioning operations can be selected to maximize an objective of the service provider (e.g., maximize service time), while facilitating the service provider in arriving at a stopping location identified by the provider's profile at an appropriate time. see par 40 - the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel); see par 44 - the system 200 may perform positioning operations for individual service provider considerations, in order to meet a preference of the service provider as to locality where the service provider performs services (e.g., service provider has affinity or need to be positioned in subregion near particular location, etc.), or to further an objective of the individual service provider with respect to the quantity or duration of service time the service provider will provide in a given shift.), using at least one passenger matching condition selected by a driver corresponding to the driver terminal from among a plurality of passenger matching conditions and at least one reference value set by the driver for the selected at least one passenger matching condition, the at least one passenger matching condition being selected and the at least one reference value being set … (Kuncl see par 56 – system has preferred locations where service provider ends a shift; see par 57 - The calendar data set may identify appointments or other events which are likely to signify stop or pause locations of the provider. The profile component 270 may update the profile information 275 of each active service provider, based on … retrieving calendar or other relative data set to determine the location preferences or likely service stops of the service provider. see par 59 - In some examples, as the time of the likely service stop nears, location bias 285 may be implemented as a band that is separated from the stopping location by a distance that is approximately the same as an expected trip distance for an expected service request that can be matched to the service provider prior to the stopping time; See par 61 - satisfy one or more preferences of the service provider (e.g., service provider prefers to be located at a particular subregion during a portion of their respective shift). see par 71 – service provider may have a preference to stop service at a particular location and time for a personal appointment (disclosing a condition, that considers driving information of a driver, and passenger information – distance/location and time).
Kuncl discloses that the driver terminal is used for gathering updated preferences/objectives of a provider, such as appointments or other events, to aid in matching (see par 44, 56-57, 59, 61, 71).
Tang discloses that the driver device itself can perform the matching.
(e) performing, “by the driver terminal,” a final matching suitability determination of the operating vehicle and the passenger based on the driving information and the passenger information, using at least one passenger matching condition selected by a driver corresponding to the driver terminal from among a plurality of passenger matching conditions and at least one reference value set by the driver for the selected at least one passenger matching condition, the at least one passenger matching condition being selected and the at least one reference value being “set in the driver terminal, independently from the management server” (Tang – see par 2 – ride-sharing agreements between passengers and drivers; Upon receiving the ride-request, the network server distributes a fare offer to candidate drivers based on their real-time locations, and brokers a ride-sharing agreement between the passenger and a selected one of the candidate drivers; see par 24, FIG. 2 - filtering may be autonomously performed by the candidate devices 210-213 upon receiving the referrals. In this example, the candidate device 213 may autonomously ignore the referral because the requesting mobile device 205 is located more than a threshold distance from the candidate device 213. There may be other reasons for autonomously ignoring the referral, e.g., the candidate device 213 is turned off, the candidate device 213 is configured to ignore referrals outside a pre-defined time-window, etc. see par 25 – responses may propose… time/day to provide the service, e.g. fair, rate)).
Kuncl and Tang disclose:
(f) transmitting, by the driver terminal, a request for allocation of the passenger to the operating vehicle (Kuncl – see par 33 - In some examples, the service providers operate mobile devices (represented in FIG. 2 by the mobile device 202) on which a corresponding service application 216 runs. Among other functionality, the service application 216 can automate operations which include indicating the availability of the service provider to provide service, … receive information from the system 200 for facilitating the service provider in receiving service requests and fulfilling a service request, and communicate information to the system 200 for various purposes, including provisioning determination; see par 38 - The service data store 230 may also associate a service state with each provider. Initially, when the service provider goes on duty, the service provider may be associated with an available state. See par 40 - From the queried result set, the matching component 240 makes a selection of a service provider for the service request 201. The service provider may receive the matched service request as an invitation, or the matched service request may be communicated as an automatic assignment. See par 41 - For example, the current trip for the service provider may complete, or the system 200 may detect when the service vehicle is nearing the destination, such that the service provider can be marked available for assignment to a new service request); see par 59 - The planning logic 280 may repeatedly determine and store the location bias 285 with the current location 207 of the provider in the service data store 230. The location bias 285 may influence the service requests which the particular service provider is matched with.
See also Tang – see par 29, FIG. 6 - As shown, the method 600 begins at step 610, where the candidate device receives a referral from a network node. The referral indicates that a service has been requested by a requesting device. Subsequently, the method 600 proceeds to step 620, where the candidate device determines whether to autonomously ignore the referral. In some embodiments, the candidate device may autonomously ignore the referral when a criteria is satisfied (e.g., proximity of candidate device to requesting device exceeds threshold, etc.). see par 30 - if the candidate device decides not to autonomously ignore the referral, then the method 600 proceeds to step 640, where the candidate device prompts the user to respond to the referral).
wherein the plurality of passenger matching conditions comprises:
a first passenger matching condition that evaluates matching suitability based on a difference between a total estimated travel time obtained by ((Appears to be referring to addition of t1+t2+t3 in specification page 10 and equation in [0054, 0069] as published, and FIG. 4; Kuncl – see par 59 - The location bias 285 may reflect an area or band about the assumed (or likely) stopping location of the provider, where the separation distance of the location bias 285 from the stopping location is based on travel time for the provider's vehicle to travel to the stopping point in a given time period set by the likely stopping time. In some examples, as the time of the likely service stop nears, the location bias 285 may be implemented as a band that is separated from the stopping location by a distance that is approximately the same as an expected trip distance for an expected service request that can be matched to the service provider prior to the stopping time. see par 62 - The service plan 282 may then define location bias 285 for the provider, based on inputs such as the current location of the provider, the preferences of the service provider, and the service provider's objective (e.g., eliminate downtime or maximize earnings)) adding an estimated travel time from a current location of the operating vehicle to a departure point of the passenger (in one example, this is departure point 3 in Applicant’s FIG. 4, page 10 of spec, and time “t1”) (Kuncl – see par 45 - provisioning level may reflect a comparative measure of service providers and requesters; the determination of the provisioning level can be represented by the wait time for a requester to be provided a service vehicle after making a request (“requester wait time)), an estimated travel time from the departure point of the passenger to a destination of the passenger (destination” is point 4 in Applicant’s FIG. 4, page 10 of spec, and this is time “t2”) (Kuncl – see par 61 - The location bias 285 for each target area may be associated with the service provider in the service data store 230 at selective time intervals that precede the target time interval by a duration predicted for matching the service provider to a suitable request and to have the service provider fulfill the service request (e.g., time for service provider to pickup and drop-off requester”)), and an estimated travel time from the destination of the passenger to an arrival point of the operating vehicle (arrival point” is point 2 in Applicant’s FIG. 4, page 10 of spec, and this is time “t3”) (Kuncl – see par 60 - planning logic 280 may predict (e.g., using historical trip data store) that a given service provider can, when positioned in a more distance subregion (target subregion) relative to the stopping location as compared to a current subregion, be matched to a single service request that can place the service provider adjacent to a likely stopping location prior to the expected stopping time. The planner 280 may then implement a service plan 282 to position the service provider after fulfillment of service requests along a path (pickup then dropoff; disclosing locations 3 and 4 in Applicant’s FIG. 4) that will position the service provider in the target subregion, with adequate time to match the service provider to a service request that that will position the service provider near the likely stopping location, before the expected stopping time).
Kuncl discloses that the provider should be separated from the “stopping location” (corresponding to Applicant’s Arrival Location 2) that is “approximately the same” as an expected trip distance for expected service request (See par 59), where a provider can have a “likely” stopping time, and a provider can also have an objective of “maximize earnings” (See par 62). Tang discloses having a response related to an offer including a time to provide the service (See par 25).
Wang discloses:
and an estimated travel time from the current location of the operating vehicle to the arrival point of the operating vehicle (current location is point 1; “arrival point” is point 4 in Applicant’s FIG. 4, page 10 of spec, and this is time “T1”; this is the same as “total estimated travel time” at beginning of this claim; the difference appears to be equation 1 on page 10 – comparing (t1+t2+t3) to T1 being less than “reference value alpha”) Wang discloses the limitations as best understood – see par 186 - In comparing the service provider's preset time limitations with the estimated travel time of the customer's service request, which includes the entire time the service provider will be underway from traveling to the pickup location to the drop off location to the preset return location; if applicable; if the estimated travel time will be beyond the service provider's time limitations (disclosing that the difference between time to go home and time to make this trip is too large, disclosing comparing different to a reference value) —making the service provider unable to get to where he or she needs to be by a certain time—the service provider will be deemed incompatible);
Kuncl, Tang, and Wang disclose:
a second passenger matching condition that evaluates matching suitability based on an estimated travel time from the current location of the operating vehicle to the departure point of the passenger (Kuncl – see par 40 - In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel). see par 45 - the determination of the provisioning level can be represented by … (ii) the wait time for a requester to be provided a service vehicle after making a request (“requester wait time”);
see also Wang – see par 68 - , a customer is able to search for a potential best matching service provider by using “search parameters” or a “search radius” to identify potential available service providers. The preference may be determined by a customer limiting a search to a desired number of service providers he or she wants to negotiate with, or to service providers who are within a certain distance from the pickup location or who can arrive to the pickup location within a certain amount of time.); and
a third passenger matching condition that evaluates matching suitability based on a distance from the destination of the passenger to the arrival point of the operating vehicle (Kuncl – see par 71 - the system 200 may determine a preference or propensity for the service provider to stop service (e.g., go off duty) at a particular time. For example, the service provider may have a preference to stop service at a particular location (describing an “arrival point”) and time for a personal appointment. The system 200 can learn the propensity of the service provider, and then plan the location bias for the service provider so that the service provider is near the stopping location at the particular time; par 72 - The system 200 can then selectively determine the location bias at various times through the day for the service provider, so that the service provider maintains a path or direction that places the service provider at a specified location and at a scheduled time. The system 200 may also position the service provider through location bias and matching, so that the service provider is optimizing a desired objective while being receiving consecutive matched assignments that drift the service provider towards a likely or preferred stopping location;
see also Wang par 186 as above).
Both Kuncl and Tang are analogous art as they are directed to forming agreements between two people - assigning drivers/providers for transport/vehicle requests (see Kuncl Abstract; Tang par 2, 18; Wang Abstract) and in addition both Kuncl and Wang are directed to assigning drivers/providers for transport/vehicle requests (see Kuncl Abstract; Wang par 59). 1) Kuncl discloses that the driver terminal is used for gathering updated preferences/objectives of a provider, such as appointments or other events, to aid in matching (see par 44, 56-57, 59, 61, 71) and that it checks for matches based on a threshold distance or time of travel (See par 40). Tang improves upon Kuncl by disclosing filtering contractors based on real-time locations or other criteria (See Tang par 26), and having the driver terminal itself perform matching with regards to “threshold” distance or “pre-defined” time windows for facilitating peer-to-peer service agreements (See Tang par 24-25) and also noting the conventional feature of having a network node filter contractors (e.g. drivers) based on real-time locations and proximity to user, where those “first to respond” chosen to fulfill a service request. One of ordinary skill in the art would be motivated to further include doing a first filter based on locations or criteria and having a driver device itself conduct some portion of matching, as well as just matching with whichever driver can pickup the passenger first, to efficiently improve upon computing devices performing various examples for ride matching in Kuncl (See par 16) and the preferred locations and times of a driver/provider being considered in Kuncl (See par 56-57, 59, 61, 71). 2) Kuncl discloses that the provider should be separated from the “stopping location” (corresponding to Applicant’s Arrival Location 2) that is “approximately the same” as an expected trip distance for expected service request (See par 59), where a provider can have a “likely” stopping time, and a provider can also have an objective of “maximize earnings” (See par 62). Klein discloses estimating arrival times generally (See par 28). Wang improves upon Kuncl and Tang by disclosing that it checks whether the provider is incompatible by seeing whether provider can get to where he or she needs to by a certain time by seeing the estimated travel time for the request, relative to the provider’s time limitations (See par 186). One of ordinary skill in the art would be motivated to further include estimated travel time for a request being compared to where provider needs to be by a certain time for determining whether the driver/provider is compatible for a request to improve upon the preferred locations of where a service provider ends a shift that also considers a stopping time (see Kuncl par 56, 59).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to supplement the consideration of stopping location and stopping time for which requests to be matched with in Kuncl to further include service a provider device itself performing matching determination based on location thresholds or pre-defined time windows as disclosed in Tang, to further include estimated travel time for a request being compared to where provider needs to be by a certain time for determining whether the driver/provider is compatible for a request as disclosed in Wang, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning independent claim 4, Kuncl discloses:
A management server (Kuncl – see par 21 - FIG. 1 illustrates a network computer system to manage the positioning of service vehicles in a geographic region. A network computer system 100 such as shown by FIG. 1 can be implemented in a variety of computing environments, including as part of a network service provided through one or more servers; see par 32 - a service arrangement system 200 (FIG. 2) may be implemented as a network service, using, for example, a network computer system 100 such as described with an example of FIG. 1) comprising:
a management server (Kuncl – see par 75-76 – computer system 400 (which can implement computing system 100), includes one or more processors);
a driver terminal (Kuncl – see par 33 - service providers operate mobile devices (represented in FIG. 2 by the mobile device 202) on which a corresponding service application 216 runs),
wherein the management server comprises:
a processor (Kuncl – see par 75-76 – computer system 400 (which can implement computing system 100), includes one or more processors));
a receiving unit, executed by the processor, configured to receive, from a driver terminal, driving information including current location information of an operating vehicle (Kuncl – see par 23 - The estimated quantity of service providers may be determined from the historical trip data 124 for the geographic region, and a current or recent location of individual service providers. see par 36 - provider device 202 may repeatedly or continuously communicate service information 203 to the system 200. The service information 203 may include the provider's identifier 205, and the provider's current location 207, which may be determined by the service application interfacing with a GPS component of the provider device 202.) and arrival point information of the operating vehicle Applicant’s [0041] as published gives example – “the arrival point of the operating vehicle 10-1 may be a returning place of the driver who finished the day's operation or a garage where the driver has to return the operating vehicle 10-1, and in this case, the present disclosure may be the allocation management method for a returning vehicle.”
Kuncl describes the limitations based on broadest reasonable interpretation in light of the specification – See par 56 - system 200 includes a profile component 270 to continuously develop profile information about service providers. The profile information 275 may be specific to geolocation, to identify, for example, preferred locations (describing an “arrival point”) where the service provider pauses or ends a shift. see par 71 - the system 200 may determine a preference or propensity for the service provider to stop service (e.g., go off duty) at a particular time. For example, the service provider may have a preference to stop service at a particular location (describing an “arrival point”) and time for a personal appointment. The system 200 can learn the propensity of the service provider, and then plan the location bias for the service provider so that the service provider is near the stopping location at the particular time), and receive, from a passenger terminal, passenger information including departure point information and destination information of a passenger (Kuncl – see par 34, FIG. 2 - system 200 to establish communication channels with individual devices of requesters; The requesters may also operate mobile devices (represented in FIG. 2 by the requester device 204) on which a corresponding service application 218 runs. The requesters may operate respective service applications 218 to request transport-related services, such as human transport between a start location (or pickup location) (describing a “departure point”) and a destination (or drop-off) (describing “destination information”).); and
a determining unit, executed by the processor, configured to perform a first matching suitability determination of the operating vehicle and the passenger based on the driving information and the passenger information, using at least one passenger matching condition selected by a manager and at least one reference value set by the manager (Kuncl – [same as claim 1] - see par 40 - In one implementation, the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers, as provided by the service data store 230. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel;
See also Tang – see par 26 - he network node 315 selects which of the contractors 325 will provide the service to the user 310, defines the terms of the service agreement, and then confirms the service agreement with the selected contractor 325 and user 310. For example, the network node 315 may filter the contractors 325 based on their real-time locations (e.g., proximity to the user 310, etc.) or some other criteria, and then present the remaining subset of contractors with the opportunity to fulfill the service request under pre-defined terms).
The remaining limitations are the same as claim 1 and are rejected for the same reasons.
It would be obvious to combine Kuncl and Tang for the same reasons as claim 1.
Concerning claims 2 and 5, Kuncl discloses:
The allocation management method of claim 1, wherein the (c) performing comprises (c1)
determining, by the management server, a total estimated travel time (Appears to be referring to addition of t1+t2+t3 in specification page 10 and equation) obtained by (Kuncl – see par 59 - The location bias 285 may reflect an area or band about the assumed (or likely) stopping location of the provider, where the separation distance of the location bias 285 from the stopping location is based on travel time for the provider's vehicle to travel to the stopping point in a given time period set by the likely stopping time. In some examples, as the time of the likely service stop nears, the location bias 285 may be implemented as a band that is separated from the stopping location by a distance that is approximately the same as an expected trip distance for an expected service request that can be matched to the service provider prior to the stopping time. see par 62 - The service plan 282 may then define location bias 285 for the provider, based on inputs such as the current location of the provider, the preferences of the service provider, and the service provider's objective (e.g., eliminate downtime or maximize earnings)).
adding an estimated travel time from the current location of the operating vehicle to the departure point of the passenger (in one example, this is departure point 3 in Applicant’s FIG. 4, page 10 of spec, and time “t1”) (Kuncl – see par 45 - provisioning level may reflect a comparative measure of service providers and requesters; the determination of the provisioning level can be represented by the wait time for a requester to be provided a service vehicle after making a request (“requester wait time”)),
adding an estimated travel time from the departure point of the passenger to the destination of the passenger (“destination” is point 4 in Applicant’s FIG. 4, page 10 of spec, and this is time “t2”) (Kuncl – see par 61 - The location bias 285 for each target area may be associated with the service provider in the service data store 230 at selective time intervals that precede the target time interval by a duration predicted for matching the service provider to a suitable request and to have the service provider fulfill the service request (e.g., time for service provider to pickup and drop-off requester)), and
adding an estimated travel time from the destination of the passenger to the arrival point of the operating vehicle (“arrival point” is point 2 in Applicant’s FIG. 4, page 10 of spec, and this is time “t3”) (Kuncl – see par 60 - planning logic 280 may predict (e.g., using historical trip data store) that a given service provider can, when positioned in a more distance subregion (target subregion) relative to the stopping location as compared to a current subregion, be matched to a single service request that can place the service provider adjacent to a likely stopping location prior to the expected stopping time. The planner 280 may then implement a service plan 282 to position the service provider after fulfillment of service requests along a path (pickup then dropoff; disclosing locations 3 and 4 in Applicant’s FIG. 4) that will position the service provider in the target subregion, with adequate time to match the service provider to a service request that that will position the service provider near the likely stopping location, before the expected stopping time)).
Kuncl discloses that the provider should be separated from the “stopping location” (corresponding to Applicant’s Arrival Location 2) that is “approximately the same” as an expected trip distance for expected service request (See par 59), where a provider can have a “likely” stopping time, and a provider can also have an objective of “maximize earnings” (See par 62). Tang discloses having a response related to an offer including a time to provide the service (See par 25).
Wang discloses:
determining whether a difference between the total estimated travel time and an estimated travel time from the current location of the operating vehicle to the arrival point of the operating vehicle is less than a predetermined reference value (current location is point 1; “arrival point” is point 4 in Applicant’s FIG. 4, page 10 of spec, and this is time “T1”; this is the same as “total estimated travel time” at beginning of this claim; the difference appears to be equation 1 on page 10 – comparing (t1+t2+t3) to T1 being less than “reference value alpha”) Wang discloses the limitations as best understood – see par 186 - In comparing the service provider's preset time limitations with the estimated travel time of the customer's service request, which includes the entire time the service provider will be underway from traveling to the pickup location to the drop off location to the preset return location; if applicable; if the estimated travel time will be beyond the service provider's time limitations (disclosing that the difference between time to go home and time to make this trip is too large, disclosing comparing different to a reference value) —making the service provider unable to get to where he or she needs to be by a certain time—the service provider will be deemed incompatible).
It would be obvious to combine Kuncl and Tang for the same reasons as claim 1. In addition, Kuncl, Tang, and Wang are analogous art as they are directed to ride request data processing (See Kuncl Abstract; Tang par 2, 18; Wang Abstract) and in addition both Kuncl and Wang are directed to assigning drivers/providers for transport/vehicle requests (see Kuncl Abstract; Wang par 59). Kuncl discloses that the provider should be separated from the “stopping location” (corresponding to Applicant’s Arrival Location 2) that is “approximately the same” as an expected trip distance for expected service request (See par 59), where a provider can have a “likely” stopping time, and a provider can also have an objective of “maximize earnings” (See par 62). Klein discloses estimating arrival times generally (See par 28). Wang improves upon Kuncl and Tang by disclosing that it checks whether the provider is incompatible by seeing whether provider can get to where he or she needs to by a certain time by seeing the estimated travel time for the request, relative to the provider’s time limitations (See par 186). One of ordinary skill in the art would be motivated to further include estimated travel time for a request being compared to where provider needs to be by a certain time for determining whether the driver/provider is compatible for a request to improve upon the preferred locations of where a service provider ends a shift that also considers a stopping time (see Kuncl par 56, 59).
Concerning claims 3 and 6, Kuncl and Wang disclose:
The allocation management method of claim 2, wherein the (c) performing further comprises (c2) determining, by the management server, whether the estimated travel time from the current location of the operating vehicle to the departure point of the passenger is less than a predetermined reference value (Kuncl – see par 40 - n one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel). see par 45 - the determination of the provisioning level can be represented by … (ii) the wait time for a requester to be provided a service vehicle after making a request (“requester wait time”)).
Concerning claim 10, Kuncl disclose:
A non-transitory recording medium having recorded thereon a program for executing the method according to claim 1. (Kuncl – see par 19 - one or more examples described may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium.)
Response to Arguments
Applicant's arguments filed 6/5/26 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
With regards to 103, Applicant argues that Tang does not disclose the driver terminal itself performing matching. Remarks, pages 13-15. In response, Examiner respectfully disagrees. It appears this is arguing “(e) performing, “by the driver terminal,” a final matching suitability determination of the operating vehicle and the passenger based on the driving information and the passenger information, using at least one passenger matching condition selected by a driver corresponding to the driver terminal from among a plurality of passenger matching conditions and at least one reference value set by the driver for the selected at least one passenger matching condition, the at least one passenger matching condition being selected and the at least one reference value being “set in the driver terminal, independently from the management server.” The rejection applies a combination of references – both Kuncl and Tang. Tang is applied for filtering referrals/matches by candidate devices 210-213 (i.e. driver devices), based on distance in an example or time in another example. Kuncl discloses the other portions of the limitations. The arguments are not persuasive. Applicant further makes an argument regarding “single quantity” or “threshold” but this is not required by the claim, and even if it was, it still is not persuasive over the disclosures in Kuncl and Tang. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant then makes an argument that Tang does not apply to the claim limitations because the current location is required within the “first passenger matching condition” and that other limitations are not in Tang. Remarks, page 15-16. In response, Examiner respectfully disagrees. First, Tang paragraph 24 was already cited referring to candidate device location. In addition, it appears Applicant is arguing limitations were mapped to Kuncl and Wang. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant then argues that Kuncl matches “server side.” Remarks, page 17. In response, Examiner respectfully disagrees. This aspect is what Tang was applied. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). As stated in the 103 rejection, Tang improves upon Kuncl by disclosing filtering contractors based on real-time locations or other criteria (See Tang par 26), and having the driver terminal itself perform matching with regards to “threshold” distance or “pre-defined” time windows for facilitating peer-to-peer service agreements (See Tang par 24-25) and also noting the conventional feature of having a network node filter contractors (e.g. drivers) based on real-time locations and proximity to user, where those “first to respond” chosen to fulfill a service request.
Applicant then argues that Wang performs compatibility for travel “server side.” Remarks, page 18. In response, Examiner respectfully disagrees. This aspect is what Tang was applied. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Edgington (US 2016/0283994) – directed to a peer-to-peer environment for providing taxi services such as with Uber (See par 16-17)
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 IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
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, Anita Coupe can be reached at 571-270-3614. 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.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619
Prosecution Insights