AU2016277703A1 - System and Method for Arranging Transport Amongst Parties Through Use of Predominantly Mobile Devices - Google Patents

Abstract

A method and system directed towards arranging transport amongst parties located at different locations using mobile devices of the parties at the locations allowing a customer to produce and convey a request for transport in order to prompt one or more offers from one or more drivers and the customer can then accept one of the offers to form an engagement, with the terms of the engagement set during the negotiation of the engagement which takes place electronically. _L/J Customer Service 110 120 Respondent Respondent Pool 130 HS 132 HS 105 Request Transoort (Geo-Loc 122) (ID 124) Invite n 114 Accept rogress Comm. Fund Rating/FB Rating/FB Figure 1 (Prior Art) Customer Service Respondent Respondent Pool Request Transport Geo-Loc n Request Provide Offer Accept Progress Update Funds Rating Rating Figure 2

Description

ι 2016277703 22 Dec 2016

SYSTEM AND METHOD FOR ARRANGING TRANSPORT AMONGST PARTIES THROUGH USE OF PREDOMINANTLY MOBILE DEVICES

TECHNICAL FIELD

[0001] The present invention relates to generally to a system and method for arranging transport amongst parties through use of predominantly mobile devices that are carried by the respective parties.

BACKGROUND ART

[0002] Figure 1 shows a prior art system and method are described for enabling transportation to be arranged for individuals carrying mobile devices (e.g. handsets) in which a customer can transmit a request for transport from a given customer geographic location. A service handles the request by selecting a party to provide transport to the customer. The pairing of the party to the customer requesting the transport may be performed programmatically and/or automatically, based on parameters such as the location of the driver (or a vehicle of the transport party).

[0003] Individual drivers may be selected as respondents to a customer request, whom in turn have the option to accept the assignment. Once a driver (or alternatively, transport party) is selected and has accepted the assignment, information about the driver (e.g. the location of the driver when the fare was accepted, a picture of the driver, his rating etc.) may be communicated to a device of the customer (e.g. to the customer's handset). The driver may also be provided information about the customer (e.g. the picture of the customer, the customer's rating, the customer's precise location).

[0004] This system is good for the drivers but not necessarily good for the customer who may have less control than they would like over the price of the trip or the driver performing the service as it is the customer who makes the request and the driver that accepts the customer offer.

[0005] It will be clearly understood that, if a prior art publication is referred to herein, this reference does not constitute an admission that the publication forms part of the common general knowledge in the art in Australia or in any other country.

SUMMARY OF INVENTION

[0006] The present invention is directed to a system and method for arranging transport 2 2016277703 22 Dec 2016 amongst parties through use of predominantly mobile devices that are carried by the respective parties, which may at least partially overcome at least one of the abovementioned disadvantages or provide the consumer with a useful or commercial choice.

[0007] With the foregoing in view, the present invention in one form, resides broadly in a computer implemented method for arranging transport amongst parties located at different locations, the method being implemented by one or more processors and comprising the steps of: a) enabling a customer at a first geographic location to make a request for transport; b) communicating details of the request to a pool of candidate respondents; c) enabling one or more of the pool of candidate respondents to make respective offers in response to the customer request for transport; d) communicating the respective offers to the customer; e) communicating the customer acceptance of a driver offer to the driver at a second geographic location.

The method may further include the steps of: f) communicating the first geographic location to the driver; and g) communicating, to the customer, a location of the driver as the vehicle progresses to and/or arrives at the first geographic location.

[0008] In another aspect, the present invention resides in a computer-implemented method for operating one or more servers to provide a service for arranging transport, the method comprising: detecting a customer application executing on a mobile computing device of a customer, the customer application automatically communicating with the service over a network; determining a current location of the mobile computing device of the customer, based on data determined by the customer application executing to interface with a Global Positioning System (GPS) resource of the mobile computing device; receiving a request from the customer application executing on the mobile computing device of the customer, the request including geographic location information that specifies a pickup location; detecting a candidate respondent application executing on a mobile computing device of a candidate respondent, the candidate respondent application automatically communicating with 3 the service over a network; 2016277703 22 Dec 2016 communicating details of the request from the customer to a pool of candidate respondent vehicles using the candidate respondent application executing on a mobile computing device of a candidate respondent; enabling one or more of the pool of candidate respondents to make respective offers using the candidate respondent application executing on a mobile computing device of a candidate respondent in response to the customer request for transport; communicating the respective offers to the customer using the service over a network to communicate with the customer application executing on the mobile computing device of the customer; communicating customer acceptance of a candidate respondent offer to the candidate respondent at a second geographic location using the service over a network to communicate with the candidate respondent application executing on the mobile computing device of the candidate respondent.

[0009] The system of this embodiment may further include , prior to the transport being provided to the customer, (i) receiving location information determined by a corresponding driver application executing on a mobile computing device associated with the selected vehicle in order to access a GPS resource of that mobile computing device as the selected vehicle moves to the pickup location, and (ii) providing the location information of the selected vehicle to the customer application in order to provide progress information of the selected vehicle, the progress information including an indication showing a current geographic location of the selected vehicle in transit on the map provided on the corresponding display of the mobile computing device of the customer; upon the customer being picked up by the selected vehicle, tracking a route of the selected vehicle from the pickup location to a drop-off location, wherein tracking the route to the drop-off location includes using information determined by at least one of (i) execution of the customer application to obtain data from the GPS resource of the mobile computing device of the customer, or (ii) execution of the corresponding driver application in order to obtain data from the GPS resource of the mobile computing device associated with the selected vehicle; 4 2016277703 22 Dec 2016 determining a fare for providing transport to the customer, wherein the fare is based at least in part on the pickup location and the tracked route to the drop-off location; and obtaining funds for the fare using an account of the customer; and transferring funds corresponding to a portion of the funds received from the customer to an account associated with a driver.

[0010] In another aspect, the present invention resides in a system for arranging transport amongst parties located at different locations, the system comprising: a plurality of computing devices, the plurality of computing devices including a computing device operated by a customer and one or more computing devices operated by one or more transport providing parties; wherein the computing devices of the customer and the one or more transport providing parties each comprise: memory resources that store a set of instructions; network resources for enabling the computing device to wirelessly communicate on over a network; geo-aware resources that are operable to programmatically determine a location of the computing devices; and one or more processors; wherein on the customer computing device, the one or more processors are configured by the set of instructions to: enable the customer to operate the customer computing device in order to enter an input to request transport from a first geographic location; in response to the customer entering the input, automatically generate a request for transport; communicate the request for transport using the network resources of the customer computing device; and wherein on each of the one or more computing devices of the transport providing parties, the one or more processors are configured by the set of instructions to: 5 enable the driver that operates that computing device to enter an offer for transport; and 2016277703 22 Dec 2016 in response to the driver entering the offer, automatically generate an offer and communicate the offer for transport using the network resources of the transport providing party’s computing device, to the customer computing device; and enable the customer to operate the customer computing device in order to enter an acceptance input to accept an offer of transport from a first geographic location; in response to the customer entering the acceptance input, automatically generate an acceptance of the offer for transport by (i) using the geo-aware resources of the customer computing device to determine a geographic location of the customer; and (ii) automatically include data identifying the geographic location in the request for transport; and communicate the acceptance of the offer for transport using the network resources of the customer computing device to the transport providing parties computing device.

[0011] In still another aspect, the present invention resides in a system to arrange transport for a customer, the system comprising: one or more network interfaces to communicate with a mobile computing device of a customer and with a mobile computing device associated with each vehicle in a group of vehicles, wherein the customer application automatically communicates with a network service provided by the system; and one or more processors coupled to the one or more network interfaces, the one or more processors to: detect a customer application executing on a mobile computing device, the customer application automatically communicating with the network service of the system over a network; determine a current location of the mobile computing device of the customer, based on data determined by the customer application executing to interface with a Global Positioning System (GPS) resource of the mobile computing device; determine a current location of a set of available vehicles in the group of vehicles, the current location of each available vehicle in the set being based on data determined by a driver application executing on a corresponding mobile computing device associated 6 2016277703 22 Dec 2016 with that vehicle, wherein on each available vehicle in the set, the driver application executes to access a GPS resource of the corresponding mobile computing device in order to provide the data for determining the current location of that available vehicle in the set to the network service of the system; receive a request from the customer application executing on the mobile computing device of the customer, the request including geographic location information that specifies a pickup location; detect a driver application executing on a mobile computing device of a driver of a vehicle, the driver application automatically communicating with the service over a network; in response to receiving the request from the customer, communicating details of the request from the customer to a pool of drivers using the driver application executing on a mobile computing device of a driver; enabling one or more drivers to make respective offers using the driver application executing on a mobile computing device of a driver in response to the customer request for transport; communicating the respective offers to the customer using the service over a network to communicate with the customer application executing on the mobile computing device of the customer; communicating customer acceptance of a driver offer to a successful driver at a second geographic location using the service over a network to communicate with the driver application executing on the mobile computing device of the driver.

[0012] The system of this embodiment may further include, prior to the transport being provided to the customer, (i) receive location information determined by a corresponding driver application executing on a mobile computing device associated with the selected vehicle in order to access a GPS resource of that mobile computing device as the selected vehicle moves to the pickup location, and (ii) provide the location information of the selected vehicle to the customer application in order to provide progress information of the selected vehicle, the progress information including an indication showing a current geographic location of the selected vehicle in transit on the map provided on the display of the mobile computing device of the customer; upon the customer being picked up by the selected vehicle, track a route of the selected 7 2016277703 22 Dec 2016 vehicle from the pickup location to a drop-off location, wherein the one or more processors track the route to the drop off location using information determined by at least one of (i) execution of the customer application to obtain data from the GPS resource of the mobile computing device of the customer, or (ii) execution of the corresponding driver application in order to obtain data from the GPS resource of the mobile computing device associated with the selected vehicle; determine a fare for providing transport to the customer, wherein the fare is based at least in part on the pickup location and the tracked route to the drop-off location; obtain funds for the fare using an account of the customer; and transfer funds corresponding to a portion of the funds received from the customer to an account associated with a driver.

[0013] The method and system of the present invention is more particularly directed towards arranging transport amongst parties located at different locations using mobile devices of the parties at the locations allowing a customer to produce and convey a request for transport in order to prompt one or more offers from one or more drivers and the customer can then accept one of the offers to form an engagement, with the terms of the engagement set during the negotiation of the engagement which takes place electronically.

[0014] Normally, one or more notifications are sent between the customer and one or more candidate respondents/drivers. These notifications are normally sent through or via a service which will typically receive and forward the notifications as required. The service will typically operate at least one computer server or network in order to facilitate connection between the respondents/drivers and the customers.

[0015] The service will preferably use the acceptance notification from the customer of a respondent/driver offer and more particularly, details from the electronic offer/acceptance notification to accomplish the payment portion of the system and method of the present invention. This is preferably performed by the at least one computer server or network of the service using the information contained in the electronic offer/acceptance notification in order to populate information corresponding to the information contained in the notification, into the payment portion.

[0016] In this way, once negotiation of the engagement is completed and an offer has been accepted, the service (that receives the acceptance notification and the offer notification(s)) can electronically “read” the requisite fare information communicated between the customer and respond/driver the forms the basis of the engagement and uses that fare information for the 8 purposes of payment. 2016277703 22 Dec 2016 [0017] Preferably, the terms of the engagement including fare information are negotiated upfront, prior to pickup although additions such as tips and the like and potentially deductions for issues such as poor service or condition of the vehicle or the like may be provided for in the system and method of the present invention. Where there is variation of the negotiated fare, this may be provided as a part of the settlement process but it is preferred that the negotiation takes place prior to pickup and that negotiation, once agreed forms the basis for the payment such that payment can be automatic, based on the negotiated engagement once the drop-off at the destination has been completed.

[0018] The invite/request, offer(s) and acceptance are all preferably electronic notification is sent via the respective mobile computing devices of the customer/respondent/driver via the service. Information relating to the location of the parties is preferably included in the notifications and information is preferably populated automatically into the notifications from the global positioning service resources of the respective mobile computing devices.

[0019] The negotiation of the engagement upfront according to the system and method of the present invention provides certainty for both parties. The offer and acceptance is preferably via notification sent between the parties via their respective mobile computing devices. It is preferred that a single offer is made by any one party but more than one offer may be made by the same party subject to acceptance of any one offer made by another party.

[0020] In some embodiments, the customer may post a request with a starting offer and one or more counteroffers are then made by one or more respondents. In this way, these embodiments may function more like an auction. For example a customer who wants to obtain transport in a difficult time, such as for example, New Years Eve, can place a high starting offer or bid and then a candidate respondent/driver may accept or propose a counter offer.

[0021] In situations where there is more than one candidate respondent, the candidate respondents may be delivered the offers made by the other candidate respondents or alternatively, the method and system may operate as a multiple offer situation whereby a single, best offer is advanced by each of the candidate respondents.

[0022] The method and system of the present invention can be used for any type of transport or delivery service. The customer may require transport of themselves either individually or with others, require transport of a third-party or an object or item. 9 2016277703 22 Dec 2016 [0023] The drivers/respondents can be operators of private vehicles or alternatively, part of a fleet of vehicles operated by a delivery or transport party. In this way, any type of vehicle may be used including private cars or vehicles, taxis or limousines for example. It is preferred that taxi companies have access to the method and system of the present invention in order to allow increased competition and provide the taxis with the ability to compete with private vehicles for custom. In the embodiments where taxis are respondents/drivers, it is preferred that they have access to the system of the present invention using existing, in vehicle, mobile data terminals.

[0024] Any of the features described herein can be combined in any combination with any one or more of the other features described herein within the scope of the invention.

[0025] The reference to any prior art in this specification is not, and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

BRIEF DESCRIPTION OF DRAWINGS

[0026] Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way. The Detailed Description will make reference to a number of drawings as follows: [0027] Figure 1 illustrates a known prior art system for enabling transport to be arranged between parties that are at different geographic location.

[0028] Figure 2 illustrates a system for enabling transport to be arranged between parties that are at different geographic locations, according to a preferred embodiment of the present invention.

[0029] Figure 3 illustrates a mobile computing device that can be used by either customers or respondents, in implementing a system such as described with Figure 2.

[0030] Figure 4 illustrates components for implementing a service, such as described with other embodiments.

[0031] Figure 5 illustrates a process for programmatically transferring funds from a customer to a relevant transport party as a mechanism for compensating the transport party, according to an embodiment. ίο 2016277703 22 Dec 2016 [0032] Figure 6 illustrates a process for enabling fee splitting amongst multiple customers that share a transport, according to one or more embodiments.

[0033] Figure 7 illustrates a method for processing data determined from monitoring transport amongst parties located at different locations, according to one or more embodiments.

DESCRIPTION OF EMBODIMENTS

[0034] According to a preferred embodiment of the present invention, a system and method for arranging transport amongst parties through use of predominantly mobile devices that are carried by the respective parties is provided.

[0035] A system and method are described for enabling transportation to be arranged for individuals carrying mobile devices (e.g. handsets). In some embodiments, a customer can transmit a request for transport from a given customer geographic location. The service will then preferably transmit or communicate the customer request to at least one and normally a number of drivers of vehicles such that the drivers may provide an offer to the customer in relation to the transport required. These offers are then preferably communicated to the customer allowing the customer to select an offer to accept. The customer acceptance is then preferably communicated to the successful driver and the agreement formed.

[0036] Some embodiments provide that a location of the customer is communicated to a service and/or driver using programmatic resources of the customer's handset.

[0037] According to embodiments, the offer made by the driver will include basic information about the price and expected time of arrival of the driver at the customer location and/or at the destination.

[0038] According to embodiments, drivers may be selected as potential respondents to a customer request, based on their geographical proximity to the customer but in other embodiments, the potential respondent pool may not be limited in this way.

[0039] Once a driver (or alternatively, transport party) makes an offer to fulfil the assignment, information about the driver (e.g. the location of the driver, a picture of the driver, his rating etc.) may be communicated to a device of the customer (e.g. to the customer's handset). The driver may also be provided information about the customer (e.g. the picture of the customer, the customer's rating, the customer's precise location).

[0040] Additionally, some embodiments provide that the customer is provided updates as to 11 2016277703 22 Dec 2016 the location of the vehicle of the driver en route to the customer. The updates may be provided in real-time or near-real time, to reflect the progression of the driver towards the customer.

[0041] Among other benefits, embodiments recognize that transport services often have vehicles that have down-time because they are between fares. In particular, limousine (or black cabs) spend much of their operational time being idle, as conventional dispatching services for such drivers often significantly underutilize the individual drivers. In contrast to conventional approaches, embodiments provided herein enable the operators of the vehicles to field transport requests from, for example, their handsets. The handsets (or other mobile devices) may correspond to, for example, (i) cellular telephony or data devices (e.g. APPLE IPHONE) that run a program that is part of a transport platform, and/or (ii) roaming devices that can connect to access points (e.g. hot spot) or operate under other wireless networks (e.g. WiMax). When the drivers/respondents are free (e.g. between fares), they can operate the program on their devices to field transport requests. Customers may run a program of the same platform on similar handsets or devices, in order to make requests for transport from their respective location. A service (such as provided online, through use of a server) may allow connection of a respondent/driver (or transport), and perform some intermediary functions (such as make payment). Various parts of the transport transaction, in which a customer is picked up and transported to a desired location, are handled programmatically, through computing resources of the platform. As explained in more detail, embodiments employ such programmatic components in order to facilitate the ability of customers to request transport, receive and communicate offers from drivers (or alternatively, transport party) to the customer, receive and communicate acceptance from customer as well as to facilitate transport providing parties and customers to meet at the pickup site and to conduct their business.

[0042] Among other features, at least some embodiments provide that the geographic location of the respective parties is determined programmatically using geo-aware resources.

This information is communicated to the other party without need for manual involvement by the party operating the handset. Thus, for example, when the customer makes the request for transport, his location at the time of making the request can automatically be included in the request. Further, when the respondent/driver makes an offer his location and other relevant information (such as continuously updated estimated time of arrival) can be automatically communicated to the customer. Further, when the successful driver starts to travel to the customer, his location and other relevant information (such as continuously updated estimated time of arrival) can be automatically communicated to the customer. 12 2016277703 22 Dec 2016 [0043] According to some embodiments, the fare for the transport is determined by the driver, and communicated as a part of the offer using a program platform that is shared by the devices of both customer and driver. Moreover, once the agreement is reached (offer made by the driver and accepted by the customer) the customer's funds may be automatically accessed and transferred to the driver/respondent. Thus, the driver is provided an incentive in participating in the platform, by being assured that funds for services will be received. The driver may in this case make an offer distinguishing that driver from others based on the fare and the estimated time of arrival at the customer and/or the destination.

[0044] Still further, embodiments enable a system such as described to be implemented using commercially available handsets and devices.

[0045] Examples of devices that may be operated by customers or respondents (e.g. drivers) include multifunctional cellular telephony devices (e.g. APPLE IPHONE, devices that operate the Android operating system), and wireless network enabled devices such as laptops, netbooks or tablets (e.g. iPAD). As such, specialized devices or components are not needed. Customers who wish to use a transport service such as described need to only download or otherwise run a program on a suitable handset. Likewise, drivers who wish to participate need only to run a corresponding program on a similar handset.

[0046] One or more embodiments described herein provide that methods, techniques and actions performed by a computing device are performed programmatically, or as a computer-implemented method.

[0047] Programmatically means through the use of code, or computer-executable instructions. A programmatically performed step may or may not be automatic.

[0048] One or more embodiments described herein may be implemented using programmatic modules or components. A programmatic module or component may include a program, a subroutine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines.

[0049] Furthermore, one or more embodiments described herein 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. Machines shown or described with figures 13 2016277703 22 Dec 2016 below provide examples of processing resources and computer-readable mediums on which instructions for implementing embodiments of the invention can be carried and/or executed. In particular, the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on many cell phones and personal digital assistants (PDAs)), and magnetic memory. Computers, terminals, network enabled devices (e.g. mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, embodiments may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.

[0050] Figure 2 illustrates a system for enabling transport to be arranged between parties that are at different geographic locations, according to some embodiments of the present invention. In an embodiment, a customer 110 (also referred as to a customer) is able to make a request to receive automobile transport services, which may be metered, using a computing device. A transport service 120 includes a respondent pool 132 from which the customer will select a successful respondent 130 (also referred to as 'respondent' or 'driver') from a pool of possible respondents, in order to drive the customer 110 to a desired destination.

[0051] According to some embodiments, the customer 110 operates a handset 105 to generate a request for transport 112. As described in Figure 3, the handset 105 may include roaming network capabilities (e.g. network interface for cellular network, Wireless Fidelity 802.11 (a), (g) (n), or WiMax etc.), along with geo-aware resources (e.g. GPS). The network functionality enables the handset 105 to transmit request 112 and communicate further with service 120 or respondents 130. The geo-aware resources enable the handset to automatically include geographic identification information 124 that identifies the geographic location of the customer 110 when making the request 112. The handset 105 may also be configured to include identification information that identifies the customer 110 to the service 120 and/or to the respondent pool 132. The identification information 124 includes, for example, a name, account number, a rating, and/or picture of the customer making the request 112. A destination address may also be included or provided with the identification information 124. Normally, the geographic identification information 124 that identifies the geographic location of the customer 110 when making the request 112 will be sent to the respondent pool 132 in order to allow the respondents 130 to make offers based on estimated arrival time of the respondents 130 at the 14 customer location. 2016277703 22 Dec 2016 [0052] According to an embodiment, the service 120 processes the request 112 and sends the request 112 to candidate respondents that can provide the requested transport. The service 120 is able to use identification information 124 to identify an account or profile of the user. The account or profile of the user may include or identify (i) funds for payment for transport services, (ii) rating information that identifies a reputation or class of user of the customer 110. Other information that may optionally be associated or maintained with the user account/profile includes, for example, an image of the customer, preferences of the user (e.g. type of vehicle the user prefers), the rating of the user (which may be provided by drivers that have previously interacted with), and historical information such as previous drivers that have provided transport to the user. Such preferences, rating information, historical information and other profile information can be used to select candidate respondents from the respondent pool 132 for delivery of the request 112. For example, for a given fare request, the service may first attempt to locate a driver that the user has previously used (and perhaps provided a good rating for) to send the request to.

[0053] As an alternative or addition, some or all of the account/profile information may be stored with the user, and communicated as part of the user's request.

[0054] Service 120 uses information contained in the customer request 112 to select candidate respondents 132 based on one or more criteria. The criteria may include (i) proximity of the individual candidate respondents to the customer 110, (ii) a class or rating of the candidate respondent 132, based on reputation and/or level/quality of service (such as provided by rating/feedback of past instances), (iii) availability of the candidate respondents 132. As mentioned, the criteria may also include user-specified preferences, including specific identification by the user of a particular driver, or previous drivers that have serviced the user and whom have received good feedback from the user. In order to arrange transport to the customer, an embodiment provides that the service 120 implements a pairing process upon receipt of the request 112.

[0055] The service 120 performs the pairing process by (i) using the one or more criteria to select a first candidate respondent; (ii) sending an invitation 114 to the first candidate, and giving the first candidate a short duration to make an offer; (iii) if the first candidate respondent declines or fails to make an offer, selecting a second candidate respondent using the one or more criteria; (iv) sending the invitation 114 to the second candidate, and giving the second candidate a short duration to make an offer. The pairing process may be repeated (n times) until a 15 2016277703 22 Dec 2016 respondent 130 from the candidate pool 132 communicates back an offer 115a to the invitation 114.

[0056] As an alternative to the single pairing process and more preferred, another embodiment provides for selecting drivers by contacting a set of two or more drivers at once, based on criteria such as described above. The particular driver that ultimately is selected depends upon the offer 115a made to the customer and the customer acceptance of an offer 115a made by a driver.

[0057] Either as part of the invitation 114 made to one or more candidate respondents, or in a follow on communication to the successful respondent 130 (following offer 115a by the driver and acceptance by the customer), the service 120 may specify, information about the customer 110 that includes: (i) the reputation of the customer (e.g. the user's feedback as provided by other drivers), (ii) the expected fare of the transport for that customer (which may include determining and communicating the customer's destination), and/or (iii) the geographic location of the customer. The customer's picture or other identification information may also be communicated to the accepting respondent. Thus, for example, the one or more candidate respondents may choose to make an offer 115a or not or take customer information into account when making an offer 115a and the successful respondent 130 is able to identify the customer 110 from sight when he arrives to pickup the customer.

[0058] According to embodiments, each of the pool of respondents 132 are equipped with devices that can communicate with geo-aware mobile devices (e.g. handsets) of the customers.

In particular, the pool of respondents 132 may include portable/mobile and personal handsets 135, such as cellular voice/data devices with geo-aware resources that the respondents can carry with them into and out of their vehicles. In one embodiment, the handsets 135 of the candidate respondents share a platform (e.g. application level) with the handsets 105 used by the customers. The shared platform enables each party to exchange communications across a shared functionality and user-interface.

[0059] Once the respondent 130 starts traveling to the customer 110, a series of progress communication 126 are communicated to the customer 110. The progress communications 126 may be generated automatically, using program instructions that cause the handset to utilize its geo-aware resources to automatically generate location information of the respondent 130 as it progresses en route to the location of customer 110. The progress communications 126 are communicated to the customer 110 using network communications. The progress communications 126 may be communicated directly from the respondent 130 to the customer 16 2016277703 22 Dec 2016 110, or via the service 120. On pickup, the customer 110 and the respondent 130 are each facilitated in that identification information for each party has been communicated to the other. This identification information may include the picture of the other party.

[0060] According to an embodiment, once the respondent 130 picks up the customer 110, one or both devices can be used to perform trip monitoring functions. Preferably, the fee is determined as a part of the offer 115a and acceptance 115b and is then set prior to pickup.

[0061] In an embodiment, payment is automatic. The customer 110 may store or associate an online fund account with his device 105. Likewise, the driver (or alternatively the transport party) has an associated account for receiving funds. Once the customer 110 is driven to his desired destination, service 120 (or the devices as configured) can trigger transfer of out of the customer's account. In one embodiment, the funds are transferred from the customer's account to an account of the service, which then transfers funds to compensate the respondent party that provided transport. The distribution of the funds from the customer may be distributed to the service 120, as well as a transport party transport that can correspond to either the driver, or a business entity that provides the driver (e.g. fleet operator). The fee transferred from the service to the transport is based on the fee charged to the customer, but may include reductions for use of the service. Various payment schemes may be used to compensate the transport party, such as paying the transport party a percentage of the fare, or compensating the transport party based on various parameters that include quality of service, desirability of fare, or even hourly. As a variation or alternative, the service can trigger at least a portion of the funds to be transferred from the customer's account directly to the transport party (e.g. fleet operator or driver). Thus, the fund transfer can be accomplished by moving funds from the customer's online financial account to that of the service and/or respondent 130 (e.g. a commercial account for the fleet manager or company). In an embodiment, fund transfer communication 142 is directed to the respondent 130 to confirm that payment has been made. The fund transfer communication 142 may be made in response to the respondent/driver (and/or the customer 110) signalling via the respective handset that the fare is over. As mentioned with other embodiments, some or all of the actual funds may be distributed to an account associated with either the driver or the transport party (e.g. the entity that employs the driver).

[0062] After the customer 110 is driven to the desired destination, an embodiment enables one or both parties to provide feedback about the other. The customer 110 may provide a rating or feedback 144 to service 120, to rate, for example, the customer's experience with the particular driver. Likewise, the driver can provide a rating or feedback 146 for the customer 110. 17 2016277703 22 Dec 2016

The service 120 may associate profiles or accounts with each of the customer 110 and respondent 130 (or respondent party), and the rating/feedbacks 144, 146 may affect the overall rating of the customer/respondent. Thus, the reputation of the customer 110 or the driver 130 may be influenced by the feedback provided by the other party.

[0063] According to some embodiments, a service such as described in Figure 2 can be implemented using handsets or other portable computing devices, in a manner that overlays or compliments existing dispatching/metering equipment used by conventional services for limousines and taxicabs. For example, limousine drivers can carry commercially available handsets (e.g. APPLE IPHONE) that are configured to implement a system such as shown in Figure 2 in order to field pickup requests from customers using handsets (also configured as described above and elsewhere in the application), while at the same time using conventional fleet/taxi dispatch and metering equipment for carrying out fares that are made through conventional channels. Thus, an embodiment such as described with Figure 2 and elsewhere can provide an alternative but complimentary mechanism by which fleet drivers can be assigned fares. In some embodiments, the drivers may utilize conventional meters to determine fares that are initiated through conventional channels, and use the suitably configured mobile device or service to determine the fares when providing transport via the service such as described Figure 2. It is possible for different fare calculation formulas and rules to be used to determine fares with conventional meters as opposed to those determined through the use of handsets or devices (as described above).

[0064] Moreover, embodiments such as described by Figure 2 may be implemented to utilize drivers regardless of the specific hardware or equipment implemented by fleet companies. Thus, embodiments such as described need not be limited by disparities in the dispatch system or equipment used amongst different fleets or transport companies that service a common geographic region. Rather, drivers from different fleet networks can be made part of the same service through use of a suitably configured commercially available handset.

[0065] Figure 3 illustrates a mobile computing device that can be used by either customers or respondents, in implementing a system such as described with Figure 2. Accordingly, mobile computing device 210 may be illustrative of the customer handset 105 (see Figure 2) or the respondent handset 135 (Figure 2). Accordingly, the mobile device 210 may correspond to any one of the following : multi-functional cellular telephony/data device, wireless tablet device, netbook, laptop, or GPS computing device.

[0066] Computing device 210 includes GPS component 204, network resources 206, 18 2016277703 22 Dec 2016 processor 212, and memory resources 214. Other components that may be included with the computing device 210 include, for example, sensors such as accelerometer 230. In one implementation, the network resources 206 includes one or more modules for enabling wireless connectivity. The wireless modules may include radios or modems, as well as software or logic for enabling network ports and interfaces through use of the radios. The network resources can include, for example, a cellular data/voice interface to enable the device to receive and send network communications over a cellular transport, including communications to service 120 (see Figure 2) and/or to the other party. In implementing one or more embodiments, the device may transmit, for example, device identification (e.g. cellular number) and geo-aware communications (as described below). As an alternative or variation, the network resources 206 includes a wireless network interface for connecting to access points (e.g. Wireless Fidelity 802.11(g) or 802.1 l(n)) or for using other types of wireless mediums (e.g. WiMax).

[0067] In an embodiment, device 210 uses the geo-aware resources, shown in form of Global Positioning System (GPS) component 204, as well as network resources 206 to communicate with the service 120 or the respondents 130 (Figure 2) over cellular or other roaming networks. The device 210 can use the processor(s) 212 and memory resources 214 execute a program (or corresponding) functionality for either a customer or driver/respondent. In some embodiments, the same type of mobile computing device 210 may be used for handsets 105 of customers and respondents 130, but the programming functionality on the handsets may vary for the respective parties.

[0068] In one embodiment, the processors 212 execute programming instructions 211 in order to auto-locate and transmit geo-location information to the service 120 or to the device of the other party in the transaction. This functionality (as provided by programming instructions 211) enables geo-aware communications 209 to be transmitted from the device. The geo-aware communications 209 may correspond to the customer's request for transport 112 (Figure 2), in which geographic information 122 is automatically included with the request 112. This functionality also allows for geo-aware communications 209 from the driver respondent 130, which automatically communicate its geographic information of the driver in progress communications 126 (Figure 2) to the customer 110. In some embodiments, the programming instructions 211 exist in the form of an application that communicates with a transport service such as described with an embodiment of Figure 4. The application may execute to utilize various resources of the device, such as the geo-aware resources or accelerometer (as described below), to generate requests that automatically include information for transport requests, such as customer identification and geographic location. 19 2016277703 22 Dec 2016 [0069] The device 210 also includes geo-presentation resources 213, to enable mapping or similar presentations using geographic identification information. For example, maps can be stored and/or retrieved on the device to present the position of either party at a given moment. The on-device GPS unit 204 may provide GPS coordinates 205 to the processor, which then uses the geo-presentation resources 213 to present ‘real-time’ maps of the user's position. The processor 212 may also receive GPS coordinates 215 from over a network (via the network interface 206) and use geo-presentation resources 213 and the received GPS coordinates 215 to present the location of the other party at a given instance.

[0070] According to an embodiment, device 210 includes an accelerometer 230 that provides accelerometer information 232 to the processor 212. The accelerometer information 232 can be used by the processor 212 to determine actual travel information, particularly with regard to stop or waiting time. More specifically, an embodiment provides that the processor 212 uses the GPS data 205 and the accelerometer information 232 to determine (i) position information, such as pickup and drop-off locations and route information or distance travelled, and (ii) stop/wait time.

[0071] Figure 4 illustrates components for implementing a service, such as described with other embodiments. In an embodiment, a transport service (e.g. service 120 of (Figure 2) is implemented on server (or servers) 300 to arrange transport for customers by pairing drivers to customers. Server 300 may include customer interface 310, dispatcher 320, account interface 340, and respondent interface 330. The customer interface 310 may be used to handle customer communications 302, while respondent interface 330 is used to handle respondent communications 332. The overall service provided on the server 300 includes a dispatcher (sub) component 320 which manages the engagement between a driver (or transport party) with a customer in response to a customer request, driver offer 115a and customer acceptance 115b.

The server 300 also includes tracking components 360, 370 which track (or monitor position and status) of the customer and the driver when the fare request is initiated (e.g. when the driver is en route to the customer) and when the fare is ongoing (driver is delivering customer to destination). A presentation component 352, 354 may be provided to generate a graphic user interface for each of the customer and the driver prior to and after pickup. Payment component 380 may be included to handle automatic payment for the fare by the customer. These components are described in greater detail below.

[0072] DISPATCH, ENGAGEMENT AND PICKUP

[0073] According to embodiments, dispatch component 320 implements an engagement 20 2016277703 22 Dec 2016 process that results in a driver making an offer to a customer based on the request for transport and the customer accepting a driver offer to seal the engagement. In an embodiment such as shown, the customer request is generated programmatically, such as by way of the customer operating a user interface of a handset to make the request.

[0074] On the server 300, customer interface 310 receives the transport request 312 from a given customer, and uses the dispatcher 320 to manage the engagement of a respondent for invitation 314. The transport request 312 may communicate a pickup location of the customer. The pickup location can be included in the transport request 312 manually (e.g. the user specifies an address for the pickup operating a handset), or automatically (e.g. based on the users known position via the GPS information communicated from his handset). As discussed below, position data 311 can be procured programmatically and automatically from the customer when the service is in use, based on the GPS information of the user's device. Similar position data 313 may be maintained for the driver when he is available for customer pickup, as well as when he is engaged to pick up and deliver a customer to a destination location. Once the transport is initiated, the position data 311,313 may be used to determine a route taken, or intermediate positions between the pickup and drop-off locations.

[0075] The dispatch component 320 responds to the transport request 312 from the customer. In responding, the dispatch component 320 may identify relevant parameters, such as the pickup location (or the location of the customer), as well as profile information about the customer (e.g. customer rating, customer preferences etc.). In response to receiving the request 312, the dispatch component 320 may also identify the customer, and obtain profile information 353 from the profile database 350. More specifically, as mentioned in some embodiments, server 300 (as part of service 120 FIG. 1) maintains profile information about each of the participants of the service. The profile information may be maintained in a profile store 350. Examples of information that may be maintained in the profile store 350 include overall rating/feedback of either party, commentary feedback (such as complaints), name or identity information, credit card information, logs of transactions (showing, for example, the average fare requested by a customer).

[0076] Thus, the profile information 353 may be stored in a database or similar data structure, and dispatch component 320 may query 351 the database for information about the customer, based on the identity identified from the request 312 or other customer communication 302.

[0077] In selecting the driver or drivers to whom the request is communicated in order to 21 2016277703 22 Dec 2016 prompt offers for engagement, dispatch 320 includes information to identify the pickup location in the invitation 314 that is communicated to the one or more drivers. As discussed previously, multiple invitations 314 may be used to progressively select a driver respondent for the customer, using criteria that includes (i) proximity of the customer to the candidate respondent, and/or (ii) rating or class association of the driver and/or the customer, and/or (iii) user preference for a particular driver, driver or vehicle class, or other characteristic of the driver or transport; but preferably (iv) alternative business logic (e.g. driver offer process for the fare).

[0078] In order to handle transport requests and invitations, the server 300 may require use of geographic information resource (GIR) 326 that identifies, for example, proximity by distance or time of individual drivers to the requesting customer. The geographic information may also be used to identify the geographic location of individual parties based on their communicated GPS information. The geographic information resource may include maps or codes that enable locating parties from their GPS coordinates, as well as information needed for calculating time/distance separating the two parties. The dispatch component 320 may also identify profile information 353 about the individual drivers by, for example, querying 351 the database 350.

[0079] In one embodiment, dispatch component 320 sends out multiple invites 314 to multiple drivers, in response to transport request 312 communicated via customer device interface 310 (which may receive the customer communication 302). The invitations 314 are preferably sent in parallel (e.g. concurrently). Each of the initially selected drivers is a candidate, selected based on parameters such as proximity, rating, preference etc. The candidate driver receiving the invite 314 may communicate an offer 316, via the driver device interface 330 (which receives the driver communication 332). Dispatch 320 may then communicate (i) a notification 331 that informs the customer of the driver offer (including optionally, information about the driver, such as his picture, vehicle identification, rating, and current position); and (ii) updates 333 that convey information about the position of the driver en route to the pickup location and/or estimated time of arrival once the customer has accepted an offer.

[0080] In one embodiment, dispatch component 320 will also manage the receipt of the offer 316, via the driver device interface 330 (which receives the driver communication 332). Dispatch 320 communicates a notification 331 that informs the customer of each driver offer (including optionally, information about the driver, such as his picture, vehicle identification, rating, and current position) to the customer via the Customer device interface 310.

[0081] The customer can then preferably review the information conveyed to them as a part of the offer, including particularly the offer of price and other parameters upon which the 22 2016277703 22 Dec 2016 customer can base their selection. In situations where there is more than one driver offer received, the customer will normally be delivered all of the driver offers and the customer can choose to rank the offers according to any of the parameters including offer price, estimated arrival time at pickup point, estimated arrival time at drop off point and the like.

[0082] The customer will normally accept an offer by selection on the customer device interface 310 and acceptance will normally lock in the conditions of the offer at that time as a part of the engagement. The customer uses the Customer device interface 310 to accept an offer and the dispatch component 320 communicates an acceptance notification 335 to the driver device interface 330 (which receives the acceptance notification 335).

[0083] Acceptance by the customer of the offer made by the driver (or transport party) is normally communicated to the successful driver (or transport party) via the dispatch 320 tissuing a success notification 336 to the successful driver (or transport party) via the transport device interface 330. Similarly, all unsuccessful drivers (or transport parties) are advised of their unsuccessful offer communicated to the unsuccessful driver (or transport party) via the dispatch 320 a failure notification 337 to the unsuccessful driver (or transport party) via the transport device interface 330.

[0084] CUSTOMER PICKUP

[0085] According to embodiments, once the customer is picked up, position data 311, 313 is obtained from the handsets of each of the customer and driver (via the respective device interfaces 310, 330). A customer tracking component 360 uses the position data 311 to track the customer by position and time. Similarly, the driver tracking could component 370 uses the position data 313 to track the driver by position and time. The GIR 326 can be used to place the user's position data 311 and the driver’s position data 313 in context to mapping information and other geographic resources. The server 300 implements presentation component 352, 354 for the customer and the driver. The respective customer and driver tracking components 360, 370 communicate the position information of customer and driver to the presentation component 352, 354 for output to the user. The output of the respective presentation components 352, 354 may be a geographic output, such as one that would combine the position data 311, 313 of each of the customer and driver with mapping information. In one implementation, the geographic output 317, 319 is communicated to the customer and driver devices via the device interface 310 and 330, respectively. Thus, under one implementation, both customer and driver are able to view the progress of the fare after pickup. 23

[0086] PAYMENT 2016277703 22 Dec 2016 [0087] The server 300 includes logic for facilitating payment between customer(s) and the relevant transport party for a particular fare. According to some embodiments, payment of the customer’s transport is performed automatically, or substantially automatically (i.e. with minimal user input, such as confirmation by the user that the fare is to be paid), in response to completion of the transport. Still further, some embodiments provide that the completion of the transport can be detected automatically, based on, for example, the position data 311 of the customer relative to the position data 313 of the driver. For example, if the customer leaves the transport vehicle and does not return to the vehicle after a set duration, a determination may be made that the transport has been completed. This determination may be made by, for example, customer and/or driver tracking component 360, 370.

[0088] As an alternative or addition, some embodiments provide that one or both parties to the transport can signify that the transport has been completed with some action, such as providing input via the handset. As another example, the customer can enter rating information for the driver, which then can be interpreted as signifying the completion of the transport.

[0089] The payment component 380 may receive payment parameters 381 from one or both of the customer/driver tracking components 360, 370. The payment parameters 381 include details of the offer and acceptance between the driver and the customer in relation to the transport. Other location payment parameters may also be used by the payment component 380, such as whether toll fees were incurred (which can be determined from position data 311, 313 cross-referenced with information provided by GIR 326), and the type of the vehicle used (e.g. can be determined by the profile information 350 of the driver). Other parameters may also be used, including parameters on predicted or actual market demand, vehicle availability, time of day, rating of driver, type of vehicle, and quality of service (see description provided by Figure 5).

[0090] Additional descriptions of how payment algorithms can be implemented are described with Figure 5 and Figure 6.

[0091] Once the fare for the transport is settled as a part of the engagement and the transport is completed, the payment component 380 may communicate an instruct 383 to account interface 340. The instruct 383 identifies the amount of the transport, the customer (or customers) that are to provide the amount, and the transport party that is to be credited for the fare.

[0092] In one implementation, the account interface 340 may be used to process and transfer 24 2016277703 22 Dec 2016 funds from an online account of the customer to an online account of the transport service (provided by the server 300). In turn, the transport service may utilize one or more methodologies to compensate the relevant transport party. The relevant transport party can correspond to a business entity (e.g. company) that operates the vehicle, or which employs the driver. Alternatively, the relevant transport party may correspond to the driver, who can, in some variations of embodiments described, receive funds from the service. The transport service, may for example, compensate the transport party by (i) distributing a portion (e.g. 50%) of the compensation to the transport party; (ii) pooling funds from multiple transports of the transport party, then transferring the funds (which can represent a portion of the total funds received) to the transport party; (ii) compensating the transport party based on an alternative metric such as flat fee or hourly rate. Embodiments further recognize that many situations, the transport party corresponds to an entity that operates one or more vehicles (e.g. fleet), and is separate entity from the driver. In such embodiments, implementations provide that the transport party is compensated with one payment (for driver or operating entity) or multiple payments (separate payments for driver and operating entity). In still another variation, the transport service may delineate a tip portion of the payment of the customer, and compensate the driver separately for the tip portion. .

[0093] Accordingly, account interface 340 is capable of interfacing with online transactional accounts on behalf of either the customer 310 or the transport party/respondent. As an alternative, the server 300 may maintain credit card information for customers and use that information to pay the transport party/driver.

[0094] According to some embodiments, when the fare is complete, server 300 automatically, without approval from the customer, pays the respondent. In this way, the respondents are encouraged to make competitive offers in relation to the transport requests, in that payment for services is assured. The customer may have the option to tip. Whether the customer tips or not may reflect back on the customer by the respondent's rating/feedback.

[0095] FEEDBACK

[0096] Some embodiments enable the participants of the transport service to provide feedback about one another based on their respective experiences. As mentioned elsewhere, one embodiment provides that each participant (customer and driver) can provide feedback that includes a rating or other quantitative metric. Additionally, a user can provide qualitative statements, such as sentences or paragraph-formed commentary about his experience with the driver. 25 2016277703 22 Dec 2016 [0097] With reference to Figure 4, a rating interface 384, 388 may be provided for each of the customer and the driver. The rating interface 384 of the customer enables the customer to record feedback 385 about a driver, or more generally, about the transport party (e.g. driver or the taxi or limousine company that provided the transport). Likewise, the rating interface 388 enables the driver to record feedback about the customer 389. The rating information of each participant may be recorded as part of that user's profile information, and thus stored in the profile store 350. Thus, each feedback results in a respective driver rating update 387 (provided by the customer) or customer rating update 391 (provided from the driver).

[0098] In some embodiments, the rating interface 384, 388 is provided in part as a webpage or webform that the user can interact with to record information about the other participant in the transaction. Still further, the rating interface may be presented to the user upon completion of the transport, such as pushed (or accessible) to the user's handset (via web browser or app). Numerous alternatives and variations are possible in regard to enabling the participant (customer or driver) to enter rating and other feedback.

[0099] Other forms of feedback may also be collected in addition to, for example, overall ratings. For example, the transport service may prompt the customer to answer a series of yes or no questions as a means of evaluating the performance of a particular driver. The questions may ask, for example, whether the driver was courteous, whether the driver opened the door or assisted the customer in entering the vehicle, the manner in which the driver drove the vehicle, and the driver's response time. The user's questionnaire feedback may be recorded for the particular driver and/or the company or operator that provided the driver.

[0100] Once entered, the rating information can have a variety of uses. Rating information can influence, for example, the ability of a customer to pick up a driver when the pool of drivers is limited. A customer's rating may be based on factors such as whether the customer provided a decent tip, and was courteous. A "good tipper" can be identified from the rating information, and when the good tipper needs transport, available drivers are more likely to accept his fare. On the driver side, the rating information associated with a driver may reflect the driver's courtesy, driving manner etc. The transport service 300 may prioritize (or emphasize) selection of drivers with good ratings. For example, the invite 314 may first be sent to proximate drivers with highest ratings, then proximate drivers with middle tier ratings. Still further, some embodiments provide the user with the ability to reject the driver based on, for example, the driver's rating information.

[0101] As still another variation, the rating information may be used as a parameter in selecting one driver to be paired to a customer. In such an embodiment, customers may first be 26 paired with drivers with similar ratings. 2016277703 22 Dec 2016

[0102] LOG AND DATA USAGE

[0103] Still further, embodiments enable collection and dissemination of data that can promote or facilitate transport services for both customers and drivers. A transport service such as described with Figure 2 Figure 4 may collect and utilize information determined from customers and drivers for a variety of purposes. Among the types of information that can be collected, the location of potential customers may be determined based on location information transmitted from suitably configured customer handsets. For example, service 120 (Figure 2) may identify a location (e.g. city block, street address) of a conglomeration of customer handsets during a given time interval. Numerous inferences may then be made about the conglomeration. For example, the conglomeration may be identified as a social event or hot-spot in the city at the given time interval. This information can then be shared with other customers, or with a portion of the population that may want to know where, for example, the 'night life' in the city is in a given evening. Drivers and fleet operators (including conventional transport providers who may not use handsets) may be informed of the location where customer pickups may readily be available.

[0104] With reference to Figure 4, information pertaining to the various transports that are transacted through the transport service are recorded for a given duration of time. The recorded information may identify customer pickup locations, customer drop-off locations, time of transport, duration of transport, and/or routes taken. In the example shown, the recorded information is stored in a log 394. The information may be recorded from, for example, dispatch 320 (identify customer pickup locations), the customer tracker 360 and driver tracker 370 (record pickup and drop-off locations, routes taken, duration), and/or the payment component 380 (record fares paid, tips paid etc.).

[0105] From the recorded information, various kinds of analysis can be performed. An analysis component 390 may analyze information from the log 394 to identify information for users (customers and drivers) of the transport service, as well as to direct users who may research based on information recorded by the transport service. The analysis component 390 may provide output to users on, for example, a website.

[0106] According to some embodiments such as described with Figure 7, the information from the log includes historical and/or real-time information that is published to third-parties and/or a population. For example, the publication may be in the form of communications sent 27 2016277703 22 Dec 2016 directly to third-parties, such as vehicle transport providers. Alternatively, the information may be published on, for example, a website or made available to users that operate a mobile application. For parties such as customers, the information may identify the location of transport vehicles, as well as popular spots in a given geographic region. For vehicle transport services and providers, the information may predict likely areas where there are likely to be fares, thus facilitating the vehicle transport services and providers in positioning vehicles and drivers to reduce response times to customer transport requests.

[0107] As another example, web users can utilize the site to identify traffic spots or best routes by identifying routes taken by drivers of the transport service, as well as their actual transport time (versus expected or average).

[0108] Numerous other applications for such data exist. For example, common pickup locations may be analyzed by time, date or event to facilitate taxi services in knowing where to locate themselves in their off time. Similar information can identify information relevant to other business or social settings of a city. For example, hotel occupancy can be estimated by identifying the number of drop-offs at hotels.

[0109] Historical information may also be utilized to predict likely transport request times and locations. For example, the most common pickup times in a given region of a city at a particular time of year can be determined.

[0110] PAYMENT METHODOLOGY

[0111] Figure 5 illustrates a process for programmatically transferring funds from a customer to a relevant transport party as a mechanism for compensating the transport party, according to an embodiment. A method such as described by Figure 5 may be implemented using components such as described with Figure 4. Accordingly, reference is made to components of Figure 4 for purpose of illustrating suitable components for performing a step or sub step being described.

[0112] Customers may subscribe to participate in a transport service such as described with Figure 4. For customers, their participation may include (i) establishing an account with funds, and (ii) registering and/or enabling a device to utilize the service of server 300. For drivers, their participation may involve (i) establishing an account to receive funds, and (ii) registering and or enabling a device to utilize the service of server 300. In one embodiment, the devices used by the participants correspond to handsets that run applications ("app") for participating in the transport service described. Other types of devices may also be used, such as laptops, tablets, computers, 28 2016277703 22 Dec 2016 or other GPS enabled devices that have network connectivity. It should also be noted that embodiments contemplate use of more primitive devices, such as those that only enable cellular telephony communications and/or SMS.

[0113] In this environment, participants (customers and transport providing parties) are associated with accounts (410). In the case of the customers, the accounts include funds that can be used for transfer to a driver. For example, the customer may make payments through a specific transport service account that is managed by the transport service entity. The payments may be made, for example, in advance, periodically, or when prompted (such as by the transport service in response to the customer receiving the transport). The transport service (such as implemented on the server(s) 300) may have authority to automate transfer of funds from an account of the customer that is not under the control of the transport service (e.g. checking account, credit card account, PAYPAL account). As provided with other embodiments, the relevant transport party that is to receive compensation from the fare (directly from the service) can, depending on the implementation and the payment methodology, correspond to (i) the fleet or vehicle operator (e.g. limousine company or entity), and/or (ii) the driver. The transport party may establish or associate an account to receive funds from the transport service and/or account of the customer. Each account may also be associated with profile information of the respective participant, including the identity of the participant.

[0114] The transport service determines when the customer is being provided transport by driver (420). This determination may be made based on factors that include the customer requesting pickup, and an engagement being established between a customer and a particular driver. However, embodiments further recognize that not all transport requests may end up as fares. Thus, embodiments include the ability to auto detect when the customer and driver have actually initiated the transport (422). Such detection can be implemented in one of many possible ways. For example, the position of the transport providing vehicle and customer can be compared over duration of time while the two are moving, and if they are at the same position, the significance is that they are determined to be in the same vehicle. As an alternative or addition, accelerometers incorporated into the handsets of the customer and/or driver may detect linear motion, such as provided by motion of a vehicle. This information can also be used to detect a fare pickup, or to confirm as such. As an alternative or addition, customer input (424) or driver input (426) may be used to determine when the fare has started.

[0115] In addition to detecting the pickup, one or more embodiments detect the completion of the transport (430). Similar to pick up, this determination may be made automatically (432), 29 2016277703 22 Dec 2016 or by way of input from either the customer (434) or the driver (436). Automatic detection of the transport completion can be made by comparing relative position data 311,313 (e.g. as determined from GPS of devices) of the customer and transport vehicle, respectively. For example, if the position data 311,313 indicates that the customer and transport vehicle have separated in position, and a designated duration of time has passed by which the customer does not return to proximity of the transport vehicle, then a determination may be made that the fare is complete.

[0116] As still another variation, once the fare pickup is detected as being present, a wireless signal (e.g. Bluetooth detection and/or pairing) may be used to determine that the two devices are in very close proximity to each other (e.g. front seat and backseat of vehicle). The completion of the transport may correspond to such wireless signal indicating the two devices have separated.

[0117] As mentioned with pickup, manual input may also be used, such as by the customer (434) or the transport party (436). For example, one party may have lost battery life, in which case manual input from the other party is needed to signify end of transport.

[0118] Once the transport is complete, the payment parameters for the fare are determined (440). The payment parameters are typically established during engagement and are stored until completion.

[0119] As a variation, some embodiments may base the fare value on transport evaluation parameters. The transport service may evaluate the quality and kind of the transport that the customer received from the driver. The evaluation may be based on criteria such as (i) the response time of the driver to arrive at the pickup location, (ii) the transport time, (iii) whether the driver elected the fastest or best route to the drop-off location. Other considerations include whether amenities were provided to the customer (or whether the customer actual used the amenities), as well as feedback by the customer as to specifics of the transport (e.g. the driver was courteous, opened the door, the car was clean, the driver obeyed driving laws etc.). The transport evaluation parameters may be used to amend or adjust the fare negotiated during the engagement.

[0120] From the payment parameters, the fare for the transport is calculated and transferred from customer to driver (460). In one embodiment, the fare is calculated and accessed from the customer account, in response to a determination that the transport is complete. Alternatively, the transfer of the fare may be performed substantially automatically, such as by way of prompting the customer and/or driver to perform some action or otherwise provide confirmation upon 30 determining that the transport has been completed. 2016277703 22 Dec 2016 [0121] As mentioned with other embodiments, various methodologies may be used to distribute funds from the customer to the various entities that are involved in providing the transport to the customer. In one embodiment, the transport service collects the funds and distributes funds to the pertinent transport parties periodically, or responsively, after one or more fares are collected. The sum total of the fares that are distributed to the transport party may represent a portion of the total received. As an alternative, the funds (or portion thereof) collected from the customer can be transferred directly to the transport party. In the context provided, the transport party may correspond to the operator or company that provides the drivers. Thus, the drivers may be compensated by separate arrangements with the operator or company that provides the transport (e.g. their employers). Still as another variation, some funds may be distributed from the transport service to the drivers separate from the companies that employ the drivers (e.g. the tip portion). Numerous variations are possible for distributing funds collected from customers, depending on considerations for distributing collected funds from the customer.

[0122] In another embodiment, the general geographic locality where the transport service operates (e.g. a city) may be 'fenced' geographically into multiple predefined regions. The fare value from one fenced region to another may be pre-determined. Thus, only the pickup and dropoff locations may be used to determine the fare value.

[0123] Figure 6 illustrates a process for enabling fee splitting amongst multiple customers that share a transport, according to one or more embodiments. Conventionally, fee splitting in transport situations (e.g. limos, taxis) is informal and dictated by agreement amongst the customers. The time it takes for customers to work out a fee arrangement is inefficient. Furthermore, conventional approaches have an underlining assumption that parties sharing rides know one another, and thus are comfortable discussing fee arrangement. In contrast to such approaches, an embodiment of Figure 6 enables transport to be arranged for multiple parties in a manner previously described by other embodiments. Additionally, the transport service can be used to determine the fee portion of each party sharing the transport, and further prompt or automate the transfer of funds from each party without requiring the individuals to agree or discuss the arrangement. Among other benefits, the fee payment arrangement can be implemented with minimal involvement from the parties. It is also easier for a transport party to provide a vehicle to pickup more than one party for transport, even if the parties are not acquaintances, as the fee splitting is not an issue that needs to be resolved by the individuals. 31 2016277703 22 Dec 2016 [0124] With reference to an embodiment of Figure 6, the transport service determines that a particular transport is shared by more than one customer (510). The determination can be made in various ways. First, the transport service can be configured to detect when individuals that are participants of the service enter a vehicle that is also operating under the service. For example, such individuals may have handsets that each runs an application which communicates with the server 300. The presence of each individual in the same vehicle may be determined in a manner described with, for example, Figure 5 (e.g. see 410). When multiple individuals are in one of the transport vehicles, the transport service may assume the fee splitting arrangement is to take place. The multiple individuals may have negotiated their engagements with a driver separately or in communication with one another. Preferably, where multiple individuals negotiate a shared transport, all parties to the engagement are aware of this.

[0125] Alternatively, the assumption may be a parameter that is weighted against other parameters, such as whether the individuals entered the vehicle at the same time, whether they have shared rides in the past or whether they are dropped off at the same location. As another variation or alternative, the fee splitting may be implemented after individuals in the transport perform a designated action. This designated action can correspond to the individuals responding to a prompt delivered to their respective handsets. As an alternative, the users may "bump" devices. Bumping can trigger an accelerometer to register the event, and the event can signify some action like fee splitting. Numerous actions can be performed to enable the transport service to infer fee splitting is in place.

[0126] Once the transport is partially complete (some but not all of the customers are dropped off) or fully complete (all of the customers are dropped off), the payment parameters for the fare of each customer can be determined (520). The payment parameters may be customer-specific (524) and/or collective (528) for the fare, depending on the algorithm that is implemented. Customer-specific payment parameters include (i) pickup-location of each customer (if different), (ii) drop-off location of each customer (if different), and/or (iii) ride duration of each customer between their respective pickup and drop-off locations. Collective ride parameters include the starting point (first pickup) of the transport and the finishing point (the last drop-off), as well as the total distance and/or time of the transport from start to finish.

[0127] The portion of the fee is calculated for each customer based on the determined payment parameters (530) or may be negotiated as a part of the engagement. The particular payment parameters, weighting and/or other factors used in determining the proportioning amongst the customers can be a matter of implementation. 32 2016277703 22 Dec 2016 [0128] According to some embodiments, the fare portion attributable to each customer is then withdrawn from each user's associated online account and transferred to an account of the transport service, or the transport party (depending on the implementation). The payment transfer may be performed automatically, substantially automatically (e.g. prompt user to confirm payment) or manually. For example, in some cases, the user may have to pay cash or by credit.

[0129] Figure 7 illustrates a method for processing data determined from monitoring transport amongst parties located at different locations, according to one or more embodiments. A method such as described by Figure 7 may be implemented using components such as described with Figure 4. Accordingly, reference is made to components of Figure 4 for purpose of illustrating suitable components for performing a step or sub step being described.

[0130] Embodiments recognize that utilizing mobile devices with geo-aware resources and communicative capabilities to arrange transports enable significant data collection and usages. A transport service such as described with Figure 4 may administer transport for multiple vehicle transport services, such as different limousine operates in a designated city. In doing so, instances of customer pickups and drop-offs may be recorded, including recording the pickup locations (610) and drop-offs (620). The information may be recorded in the log 394. In some embodiments, the information may be recorded in real-time, although the information may stored for use as historical data.

[0131] Other information may also be recorded from, for example, by monitoring vehicles available for transport, and/or transports in progress (630). For example, the location of available vehicles may be determined, as well as the duration of transport between locations.

[0132] The recorded information is processed (640). In real-time applications, the information current information at a given instance is extracted from the log and processed in accordance with a particular application. One application includes presenting geographic information about popular customer pickup and/or drop-off locations. For example, a map may be generated that identifies the location of or popular recent customer pickups, recent or popular customer drop-offs, current location of available transport vehicles, predicted response times, and predicted areas of traffic congestion.

[0133] As another application, historical information from the log 394 may be used to predict demands for transport during given time spans (e.g. weeknights, weekends, between 2-4pm on Thursdays etc.). The historical information may include customer pickup locations, pickup times, customer drop-off locations and/or drop-off times. This information may be 2016277703 22 Dec 2016 33 processed to determine predicted demands for transport at given locations and times.

[0134] The processed information is then communicated or published to third-parties (650). For example, the transport service may publish the processed information on, for example, a website that is available to customers and transport provides. Alternatively, the information may be published through applications that execute on user devices. As still another example, the information may be generated in the form of reports that are emailed or otherwise communicated to parties (e.g. transport providing parties) directly. Numerous other variations are possible.

[0135] In the present specification and claims (if any), the word ‘comprising’ and its derivatives including ‘comprises’ and ‘comprise’ include each of the stated integers but does not exclude the inclusion of one or more further integers.

[0136] Reference throughout this specification to ‘one embodiment’ or ‘an embodiment’ means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases ‘in one embodiment’ or ‘in an embodiment’ in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

[0137] In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect. The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims (if any) appropriately interpreted by those skilled in the art.

Claims (20)

1. A computer implemented method for arranging transport amongst parties located at different locations, the method being implemented by one or more processors and comprising the steps of: a) enabling a customer at a first geographic location to make a request for transport; b) communicating details of the request to a pool of candidate respondents; c) enabling one or more of the pool of candidate respondents to make respective offers in response to the customer request for transport; d) communicating the respective offers to the customer; e) communicating the customer acceptance of a driver offer to the driver at a second geographic location.

2. A computer implemented method as claimed in claim 1 further including the steps of: f) communicating the first geographic location to the driver; and g) communicating, to the customer, a location of the driver as the vehicle progresses to and/or arrives at the first geographic location.

3. A computer-implemented method for operating one or more servers to provide a service for arranging transport, the method comprising: detecting a customer application executing on a mobile computing device of a customer, the customer application automatically communicating with the service over a network; determining a current location of the mobile computing device of the customer, based on data determined by the customer application executing to interface with a Global Positioning System (GPS) resource of the mobile computing device; receiving a request from the customer application executing on the mobile computing device of the customer, the request including geographic location information that specifies a pickup location; detecting a candidate respondent application executing on a mobile computing device of a candidate respondent, the candidate respondent application automatically communicating with the service over a network; communicating details of the request from the customer to a pool of candidate respondent vehicles using the candidate respondent application executing on a mobile computing device of a candidate respondent; enabling one or more of the pool of candidate respondents to make respective offers using the candidate respondent application executing on a mobile computing device of a candidate respondent in response to the customer request for transport; communicating the respective offers to the customer using the service over a network to communicate with the customer application executing on the mobile computing device of the customer; communicating customer acceptance of a candidate respondent offer to the candidate respondent at a second geographic location using the service over a network to communicate with the candidate respondent application executing on the mobile computing device of the candidate respondent.

4. A computer-implemented method as claimed in claim 3 further including, prior to the transport being provided to the customer, a. receiving location information determined by a corresponding driver application executing on a mobile computing device associated with the selected vehicle in order to access a GPS resource of that mobile computing device as the selected vehicle moves to the pickup location, and b. providing the location information of the selected vehicle to the customer application in order to provide progress information of the selected vehicle, the progress information including an indication showing a current geographic location of the selected vehicle in transit on the map provided on the corresponding display of the mobile computing device of the customer; upon the customer being picked up by the selected vehicle, tracking a route of the selected vehicle from the pickup location to a drop-off location, wherein tracking the route to the drop-off location includes using information determined by at least one of (i) execution of the customer application to obtain data from the GPS resource of the mobile computing device of the customer, or (ii) execution of the corresponding driver application in order to obtain data from the GPS resource of the mobile computing device associated with the selected vehicle; determining a fare for providing transport to the customer, wherein the fare is based at least in part on the pickup location and the tracked route to the drop-off location; and obtaining funds for the fare using an account of the customer; and transferring funds corresponding to a portion of the funds received from the customer to an account associated with a driver.

5. A system for arranging transport amongst parties located at different locations, the system comprising: a plurality of computing devices, the plurality of computing devices including a computing device operated by a customer and one or more computing devices operated by one or more transport providing parties; wherein the computing devices of the customer and the one or more transport providing parties each comprise: memory resources that store a set of instructions; network resources for enabling the computing device to wirelessly communicate on over a network; geo-aware resources that are operable to programmatically determine a location of the computing devices; and one or more processors; wherein on the customer computing device, the one or more processors are configured by the set of instructions to: enable the customer to operate the customer computing device in order to enter an input to request transport from a first geographic location; in response to the customer entering the input, automatically generate a request for transport; communicate the request for transport using the network resources of the customer computing device; and wherein on each of the one or more computing devices of the transport providing parties, the one or more processors are configured by the set of instructions to: enable the driver that operates that computing device to enter an offer for transport; and in response to the driver entering the offer, automatically generate an offer and communicate the offer for transport using the network resources of the transport providing party’s computing device, to the customer computing device; and enable the customer to operate the customer computing device in order to enter an acceptance input to accept an offer of transport from a first geographic location; in response to the customer entering the acceptance input, automatically generate an acceptance of the offer for transport by (i) using the geo-aware resources of the customer computing device to determine a geographic location of the customer; and (ii) automatically include data identifying the geographic location in the request for transport; and communicate the acceptance of the offer for transport using the network resources of the customer computing device to the transport providing parties computing device.

6. A method as claimed in any one of the preceding claims directed towards arranging transport amongst parties located at different locations using mobile devices of the parties at the locations, allowing a customer to produce and convey a request for transport in order to prompt one or more offers from one or more drivers and the customer can then accept one of the offers to form an engagement, with the terms of the engagement set during the negotiation of the engagement which takes place electronically.

7. A method as claimed in any one of the preceding claims wherein one or more notifications are sent between the customer and one or more candidate respondents/drivers.

8. A method as claimed in claim 7 wherein the notifications are sent through or via an electronic relay service which receives and forwards the notifications as required.

9. A method as claimed in claim 8 wherein the service uses an acceptance notification from the customer of a respondent/driver offer to accomplish the payment portion.

10. A method as claimed in claim 8 or 9 wherein the service uses details from the electronic offer/acceptance notification to accomplish the payment portion.

11. A method as claimed in claim 10 wherein the payment portion is performed by the at least one computer server or network of the service using the information contained in the electronic offer/acceptance notification in order to populate information corresponding to the information contained in the notification, into the payment portion.

12. A method as claimed in any one of the preceding claims wherein once negotiation of the engagement is completed and an offer has been accepted, the service receives the acceptance notification and the offer notification(s) can electronically read the requisite fare information communicated between the customer and respond/driver that forms the basis of the engagement and uses that fare information for the purposes of payment.

13. A method as claimed in claim 12 wherein payment is automatically deducted from a customer account at completion of the engagement.

14. A method as claimed in claim 12 or 13 wherein the terms of the engagement including fare information are negotiated upfront, prior to pickup.

15. A method as claimed in any one of the preceding claims wherein the invite/request, offer(s) and acceptance are electronic notifications sent via the respective mobile computing devices of the customer/respondent/driver via the service.

16. A method as claimed in claim 15 wherein information relating to the respective locations of the parties is preferably included in the electronic notifications and information is populated automatically into the electronic notifications from the global positioning service resources of the respective mobile computing devices.

17. A method as claimed in any one of the preceding claims wherein the customer may post an electronic notification request with a starting offer and one or more counteroffers are then made by one or more respondents.

18. A method as claimed in claim 17 wherein there is more than one candidate respondent, the method operates as a multiple offer situation whereby a single, best offer is advanced by each of the candidate respondents.

19. A system to arrange transport for a customer, the system comprising: one or more network interfaces to communicate with a mobile computing device of a customer and with a mobile computing device associated with each vehicle in a group of vehicles, wherein the customer application automatically communicates with a network service provided by the system; and one or more processors coupled to the one or more network interfaces, the one or more processors to: detect a customer application executing on a mobile computing device, the customer application automatically communicating with the network service of the system over a network; determine a current location of the mobile computing device of the customer, based on data determined by the customer application executing to interface with a Global Positioning System (GPS) resource of the mobile computing device; determine a current location of a set of available vehicles in the group of vehicles, the current location of each available vehicle in the set being based on data determined by a driver application executing on a corresponding mobile computing device associated with that vehicle, wherein on each available vehicle in the set, the driver application executes to access a GPS resource of the corresponding mobile computing device in order to provide the data for determining the current location of that available vehicle in the set to the network service of the system; receive a request from the customer application executing on the mobile computing device of the customer, the request including geographic location information that specifies a pickup location; detect a driver application executing on a mobile computing device of a driver of a vehicle, the driver application automatically communicating with the service over a network; in response to receiving the request from the customer, communicating details of the request from the customer to a pool of drivers using the driver application executing on a mobile computing device of a driver; enabling one or more drivers to make respective offers using the driver application executing on a mobile computing device of a driver in response to the customer request for transport; communicating the respective offers to the customer using the service over a network to communicate with the customer application executing on the mobile computing device of the customer; communicating customer acceptance of a driver offer to a successful driver at a second geographic location using the service over a network to communicate with the driver application executing on the mobile computing device of the driver.

20. The system as claimed in claim 6 further including, prior to the transport being provided to the customer, (i) receive location information determined by a corresponding driver application executing on a mobile computing device associated with the selected vehicle in order to access a GPS resource of that mobile computing device as the selected vehicle moves to the pickup location, and (ii) provide the location information of the selected vehicle to the customer application in order to provide progress information of the selected vehicle, the progress information including an indication showing a current geographic location of the selected vehicle in transit on the map provided on the display of the mobile computing device of the customer; upon the customer being picked up by the selected vehicle, track a route of the selected vehicle from the pickup location to a drop-off location, wherein the one or more processors track the route to the drop off location using information determined by at least one of (i) execution of the customer application to obtain data from the GPS resource of the mobile computing device of the customer, or (ii) execution of the corresponding driver application in order to obtain data from the GPS resource of the mobile computing device associated with the selected vehicle; determine a fare for providing transport to the customer, wherein the fare is based at least in part on the pickup location and the tracked route to the drop-off location; obtain funds for the fare using an account of the customer; and transfer funds corresponding to a portion of the funds received from the customer to an account associated with a driver.