Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
A SYSTEM AND A METHOD FOR LOCATING ONE OR MORE PEERS
Document Type and Number:
WIPO Patent Application WO/2013/036199
Kind Code:
A1
Abstract:
A system and a method for locating one or more peers may be provided whereby the method comprises determining location information (e.g. geographical location) of a requesting peer; determining location information of at least one available peer for engagement based on the location information of the requesting peer; and transmitting the location information of the at least one available peer to the requesting peer.

Inventors:
KOH BENG KIOK ANTHONY (SG)
KIM MOON SOO (SG)
Application Number:
PCT/SG2012/000244
Publication Date:
March 14, 2013
Filing Date:
July 11, 2012
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
MOBILE CREDIT PAYMENT PTE LTD (SG)
KOH BENG KIOK ANTHONY (SG)
KIM MOON SOO (SG)
International Classes:
G08G1/123; G06F15/16; G06Q50/30; H04W4/02
Domestic Patent References:
WO2011014076A12011-02-03
Attorney, Agent or Firm:
DONALDSON & BURKINSHAW (P. O. Box 3667, Singapore 7, SG)
Download PDF:
Claims:
CLAIMS

1. A method for locating one or more peers, the method comprising,

determining location information of a requesting peer;

determining location information of at least one available peer for engagement based on the location information of the requesting peer; and

transmitting the location information of the at least one available peer to the requesting peer. 2. The method as claimed in claim 1 , further comprising presenting the location information of the at least one available peer to the requesting peer.

3. The method as claimed in claims 1 or 2, further comprising displaying in a graphical display said location information of the requesting peer, said location information of said at least one available peer for engagement or both.

4. The method as claimed in any one of claims 1 to 3, further comprising allowing selection of a chosen available peer by the requesting peer. 5. The method as claimed in any one of claims 1 to 4, wherein the at least one available peer is a peer that has actively indicated an availability status for locating by the requesting peer.

6. The method as claimed in any one of claims 1 to 5, wherein said determining location Information of the requesting peer comprises a user entry of an engagement location information.

7. The method as claimed in claim 6, wherein the user entry of the engagement location information comprises entering an address information using a web browser connected to a network.

8. The method as claimed in any one of claims 1 to 7, wherein said determining location information of the requesting peer further comprises utilising a location-based service at the requesting peer.

9. The method as claimed in any one of claims 1 to 8, wherein said determining location information of said at least one available peer for engagement further comprises utilising a location-based service at the at least one available peer. 10. The method as claimed in any one of claims 1 to 9, wherein said determining location information of said at least one available peer for engagement based on the location information of the requesting peer comprises using a range information transmitted from the requesting peer. 1 1. The method as claimed in any one of claims 1 to 10, wherein said transmitting the location information of the at least one available peer to the requesting peer comprises transmitting profile and/or history details of the at least one available peer.

12. The method as claimed in any one of claims 1 to 11 , further comprising allowing an engagement between the requesting peer and said at least one available peer. 3. The method as claimed in claim 12, further comprising confirming the engagement via the said at least one available peer generating a service payment message for sending to the requesting peer.

14. The method as claimed in claim 12, further comprising confirming the engagement via the requesting peer generating a service payment message for sending to the said at least one available peer. 15. The method as claimed in any one of claims 1 to 14, wherein the requesting peer is an entity requesting for transport services and the at least one available peer is an entity offering transport services.

16. The method as claimed in any one of claims 1 to 14, wherein the requesting peer is an entity offering transport services and the at least one available peer is an entity requesting for transport services. 7. The method as claimed in any one of claims 1 to 16, wherein the step of determining location information of at least one available peer for engagement comprises dynamically determining the location information.

18. A communication device for a requesting peer for locating one or more peers, the device comprising,

a module for determining location information of the requesting peer;

a receiving module for receiving location information of at least one available peer for engagement, said location information of at least one available peer determined based on the location information of the requesting peer.

19. The device as claimed in claim 18, further comprising a graphical display for displaying said location information of the requesting peer, said location information of said at least one available peer for engagement or both.

20. The device as claimed in claims 18 or 19, further comprising an input module for selection of a chosen available peer by the requesting peer. 21. The device as claimed in any one of claims 18 to 20, further comprising an input interface for actively switching on an availability status for locating by a peer.

22. The device as claimed in any one of claims 18 to 21 , wherein the module for determining location information of a requesting peer comprises a user entry field of an engagement location information.

23. The device as claimed in claim 22, wherein the user entry of the engagement location information comprises entering an address information using a web browser connected to a network.

24. The device as claimed in any one of claims 18 to 23, further comprising a location- based service module.

25. The device as claimed in claim 24, wherein the location-based service module is integrated with the module for determining location information of the requesting peer.

26. The device as claimed in any one of claims 18 to 25, wherein said location information of at least one available peer is determined utilising a location-based service at the at least one available peer.

27. The device as claimed in any one of claims 18 to 26, wherein said location information of at least one available peer is further determined based on a range information transmitted from the requesting peer. 28. The device as claimed in any one of claims 18 to 27, wherein said receiving module is capable of receiving profile and/or history details of the at least one available peer.

29. The device as claimed in any one of claims 18 to 28, further comprising a messaging module for confirming engagement of the requesting peer and the at least one available peer, wherein the at least one available peer generates a service payment message for sending to the requesting peer via the messaging module.

30. The device as claimed in any one of claims 8 to 28, further comprising a messaging module for confirming engagement of the requesting peer and the at least one available peer, wherein the requesting peer generates a service payment message for sending to the at least one available peer via the messaging module.

31. The device as claimed in any one of claims 18 to 30, wherein the requesting peer is an entity requesting for transport services and the at least one available peer is an entity offering transport services.

32. The device as claimed in any one of claims 18 to 30, wherein the requesting peer is an entity offering transport services and the at least one available peer is an entity requesting for transport services.

33. The device as claimed in any one of claims 18 to 32, wherein said location information of at least one available peer is dynamically determined.

34. A system for peer to peer engagement, the system comprising,

a requesting peer communication device;

one or more available engagement peers communication devices;

an application server;

wherein the requesting peer communication device comprises,

a module for determining location information of the requesting peer;

a receiving module for receiving location information of at least one available peer for engagement from the application server; and wherein for the one or more available engagement peers communication devices, each available engagement peer communication device comprises

a module for determining location information of the available engagement peer;

a transmitting module for transmitting location information of the available engagement peer to the application server; and

further wherein the application server is configured to receive location information of the requesting peer and determine said location information of at least one available peer based on the location information of the requesting peer.

35. The system as claimed in claim 34, wherein the each available engagement peer communication device further comprises an input interface for actively switching on an availability status for locating by the requesting peer. 36. The system as claimed in claims 34 or 35, wherein the requesting peer communication device further comprises an input interface for actively switching on an availability status for locating by a peer.

37. The system as claimed in any one of claims 34 to 36, wherein the module for determining location information of a requesting peer comprises a user entry field of an engagement location information.

38. The system as claimed in claim 37, wherein the user entry of the engagement location information comprises entering an address information using a web browser "connected to a network coupled to the application server.

39. The system as claimed in any one of claims 34 to 38, wherein said location information of at least one available peer is determined utilising a location-based service at the at least one available peer.

40. The system as claimed in any one of claims 34 to 39, wherein said location information of at least one available peer is further determined based on a range information transmitted from the requesting peer to the application server.

41. The system as claimed in any one of claims 34 to 40, wherein the application server is configured to transmit profile and/or history details of the at least one available peer to the receiving module. 42. The system as claimed in any one of claims 34 to 41 , wherein the application server is configured to send a service payment message to the requesting peer for confirming engagement of the requesting peer and the at least one available peer.

43. The system as claimed in any one of claims 34 to 42, wherein the application server is configured to send a service payment message to the at least one available peer for confirming engagement of the requesting peer and the at least one available peer.

44. The system as claimed in any one of claims 34 to 43, further comprising a payment server configured to handle payment from the requesting peer or the at least one available peer.

45. The system as claimed in any one of claims 34 to 44, wherein the requesting peer is an entity requesting for transport services and the at least one available peer is an entity offering transport services.

46. The system as claimed in any one of claims 34 to 45, wherein the requesting peer is an entity offering transport services and the at least one available peer is an entity requesting for transport services. "47. The system as claimed in any one of claims 34 to 46, wherein the application server is further configured to dynamically determine said location information of at least one available peer.

48. A computer readable data storage medium having stored thereon computer code means for instructing a processing module of a communication device to execute a method for locating one or more peers, the method comprising,

determining location information of a requesting peer;

receiving location information of at least one available peer for engagement, said location information of at least one available peer determined based on the location information of the requesting peer.

49. The computer readable data storage medium as claimed in claim 48, wherein the method further comprises displaying in a graphical display of the communication device said location information of the requesting peer, said location information of said at least one available peer for engagement or both.

50. The computer readable data storage medium as claimed in claims 48 or 49, wherein the method further comprises allowing selection of a chosen available peer by the requesting peer. 51. The computer readable data storage medium as claimed in any one of claims 48 to 50, wherein the at least one available peer is a peer that has actively indicated an availability status for locating by the requesting peer.

52. The computer readable data storage medium as claimed in any one of claims 48 to 51 , wherein said location information of at least one available peer is dynamically determined.

Description:
A SYSTEM AND A METHOD FOR LOCATING ONE OR MORE PEERS

TECHNICAL FIELD

The present invention relates broadly to a system and to a method for locating one or more peers.

BACKGROUND

In peer-to-peer engagements, there is typically a need for the communicating peers to have some information regarding each other in order to facilitate engagement. Such engagement may be, for example, a taxi passenger seeking to hail or book a taxi.

In an example scenario, typically, a taxi passenger (one peer) has to wait at the taxi stand or along the roadside to wait for the arrival of a taxi (another peer). The taxi passenger is unsure of the duration of the wait before the arrival of the taxi. Similarly, a taxi driver typically drives around to locate a potential taxi passenger. This can result in a waste of time and resources in trying to locate a taxi passenger.

In an effort to alleviate the above, one method is to set up a call center for administering calls for taxi booking. A taxi passenger may call a taxi booking hotline to book for a taxi. As technology advances, different platforms such as short messaging system (SMS) messages, emails and internet web booking are supported by the call centers. That is, a taxi passenger may book for a taxi through these available platforms provided by the call centers. In general, booking of a taxi is done through calling a designated taxi hotline number which routes to the taxi call center managed by the taxi company.

Typically, a call center is usually manned by a taxi company. As there are many taxi companies in the market and each taxi company has a different taxi fleet size in the market, there may arise a situation whereby there are a plurality of call centers with different hotline numbers available in the market. Hence, passengers would need to take note of the various taxi booking hotline numbers available in the market. In addition, taxi companies with a bigger fleet tend to dominate the market and their respective call center hotlines are typically more popular than the other taxi companies. During peak hours, these more popular call centers are then typically jammed with calls for bookings. Therefore, the call center can become a bottleneck for processing calls for taxi booking while other taxi drivers with less popular call centers are on the road roaming around looking for potential passengers. Furthermore, at the call center, bookings are allocated by call operators to the taxi drivers and bottlenecks frequently occur when one call operator has to serve a plurality of taxi drivers. Further, as a call center is typically costly to maintain, a taxi company with a small taxi fleet size may face financial problems operating a call center. Hence, in order to cover the cost of operating call centers, the cost is typically passed to the passengers via taxi booking fees, which typically is a source of income to the taxi companies and the taxi drivers. That is, the booking fee is an additional amount levied on the taxi passenger for using the booking service as compared to hailing a taxi by the street.

A location-based service that utilises a smart mobile device or smartphone, such as Apple iOS-enable iPhones, Android-enabled phones etc., has been proposed to assist taxi passengers to book for taxis. However, it has been recognised that such a service is merely an extension of the booking service provided by the call center in that the location-based service, in the form of e.g. a mobile application, is integrated to the call center system or is programmed to conduct an autodial to the call center booking system. This system still inherits the problem of the call center being the bottleneck where its efficiency depends significantly on the processing capability of the system. Furthermore, the processing capability is reliant on a computer host that communicates with mobile application. Bookings from the mobile application are sent to the host which in turn, broadcasts job requests to the taxis. Taxi drivers are allowed to respond and the booking is typically provided on a first- come-first-serve basis, i.e. to the first taxi driver who responds to a job request. Thus, ther may arise a problem that the taxi driver that is awarded the booking may not be in the close vicinity of the passenger.

Furthermore, for the above booking services, the passenger typically communicates with the staff or system of the call center, and the staff or system of the call center communicates with the taxi driver. There is typically no direct contact between the passenger and the driver. Typically, only upon confirmation of booking is e.g. the taxi vehicle number and estimated time of arrival (ETA) sent to the passenger. Other details of the taxi are not made known to the passenger and further, the passenger does not have a choice or selection of the taxi.

In addition, typically, booking depends on the taxi that responds to the call center for a passenger job request. Therefore, the taxi may not be the nearest available taxi to the passenger at the time of booking thus increasing the time of arrival.

Hence, there exists a need for a system and a method for locating one or more peers that seek to address at least one of the above problems.

SUMMARY

In accordance with a first aspect of the invention, there is provided a method for locating one or more peers, the method comprising determining location information of a requesting peer; determining location information of at least one available peer for engagement based on the location information of the requesting peer; and transmitting the location information of the at least one available peer to the requesting peer.

The method may further comprise presenting the location information of the at least one available peer to the requesting peer.

The method may further comprise displaying in a graphical display said location information of the requesting peer, said location information of said at least one available peer for engagement or both.

The method may further comprise allowing selection of a chosen available peer by the requesting peer.

The at least one available peer may be a peer that has actively indicated an availability status for locating by the requesting peer.

The said determining location information of the requesting peer may comprise a user entry of an engagement location information. The user entry of the engagement location information may comprise entering an address information using a web browser connected to a network.

The said determining location information of the requesting peer may further comprise utilising a location-based service at the requesting peer.

The said determining location information of said at least one available peer for engagement may further comprise utilising a location-based service at the at least one available peer.

The said determining location information of said at least one available peer for engagement based on the location information of the requesting peer may comprise using a range information transmitted from the requesting peer. The said transmitting the location information of the at least one available peer to the requesting peer may comprise transmitting profile and/or history details of the at least one available peer.

The method may further comprise allowing an engagement between the requesting peer and said at least one available peer.

The method may further comprise confirming the engagement via the said at least one available peer generating a service payment message for sending to the requesting peer.

The method may further comprise confirming the engagement via the requesting peer generating a service payment message for sending to the said at least one available peer. The requesting peer may be an entity requesting for transport services and the at least one available peer is an entity offering transport services.

The requesting peer may be an entity offering transport services and the at least one available peer may be an entity requesting for transport services. The step of determining location information of at least one available peer for engagement may comprise dynamically determining the location information.

In accordance with a second aspect of the invention, there is provided a communication device for a requesting peer for locating one or more peers, the device comprising a module for determining location information of the requesting peer; a receiving module for receiving location information of at least one available peer for engagement, said location information of at least one available peer determined based on the location information of the requesting peer.

The device may further comprise a graphical display for displaying said location information of the requesting peer, said location information of said at least one available peer for engagement or both. The device may further comprise an input module for selection of a chosen available peer by the requesting peer.

The device may further comprise an input interface for actively switching on an availability status for locating by a peer.

The module for determining location information of a requesting peer may comprise a user entry field of an engagement location information.

The user entry of the engagement location information may comprise entering an address information using a web browser connected to a network.

The device may further comprise a location-based service module.

The location-based service module may be integrated with the module for determining location information of the requesting peer.

The said location information of at least one available peer may be determined utilising a location-based service at the at least one available peer. The said location information of at least one available peer may be further determined based on a range information transmitted from the requesting peer. The said receiving module may be capable of receiving profile and/or history details of the at least one available peer. The device may further comprise a messaging module for confirming engagement of the requesting peer and the at least one available peer, wherein the at least one available peer can generate a service payment message for sending to the requesting peer via the messaging module. The device may further comprise a messaging module for confirming engagement of the requesting peer and the at least one available peer, wherein the requesting peer can generate a service payment message for sending to the at least one available peer via the messaging module. The requesting peer may be an entity requesting for transport services and the at least one available peer may be an entity offering transport services.

The requesting peer may be an entity offering transport services and the at least one available peer may be an entity requesting for transport services.

The said location information of at least one available peer may be dynamically determined.

In accordance with a third aspect of the invention, there is provided a system for peer to peer engagement, the system comprising a requesting peer communication device; one or more available engagement peers communication devices; an application server; wherein the requesting peer communication device comprises, a module for determining location information of the requesting peer; a receiving module for receiving location information of at least one available peer for engagement from the application server; and wherein for the one or more available engagement peers communication devices, each available engagement peer communication device comprises a module for determining location information of the available engagement peer; a transmitting module for transmitting location information of the available engagement peer to the application server; and further wherein the application server is configured to receive location information of the requesting peer and determine said location information of at least one available peer based on the location information ot the requesting peer. The each available engagement peer communication device may further comprise an input interface for actively switching on an availability status for locating by the requesting peer.

The requesting peer communication device may further comprise an input interface for actively switching on an availability status for locating by a peer.

The module for determining location information of a requesting peer may comprise a user entry field of an engagement location information.

The user entry of the engagement location information may comprise entering an address information using a web browser connected to a network coupled to the application server.

The said location information of at least one available peer may be determined utilising a location-based service at the at least one available peer.

The said location information of at least one available peer may be further determined based on a range information transmitted from the requesting peer to the application server.

The application server may be configured to transmit profile and/or history details of the at least one available peer to the receiving module.

The application server may be configured to send a service payment message to the requesting peer for confirming engagement of the requesting peer and the at least one available peer. The application server may be configured to send a service payment message to the at least one available peer for confirming engagement of the requesting peer and the at least one available peer.

The system may further comprise a payment server configured to handle payment from the requesting peer or the at least one available peer. The requesting peer may be an entity requesting for transport services and the at least one available peer may be an entity offering transport services.

The requesting peer may be an entity offering transport services and the at least one available peer is an entity requesting for transport services.

The application server may be further configured to dynamically determine said location information of at least one available peer. In accordance with a fourth aspect of the invention, there is provided a computer readable data storage medium having stored thereon computer code means for instructing a processing module of a communication device to execute a method for locating one or more peers, the method comprising determining location information of a requesting peer; receiving location information of at least one available peer for engagement, said location information of at least one available peer determined based on the location information of the requesting peer.

The method may further comprise displaying in a graphical display of the communication device said location information of the requesting peer, said location information of said at least one available peer for engagement or both.

The method may further comprise allowing selection of a chosen available peer by the requesting peer. The at least one available peer may be a peer that has actively indicated an availability status for locating by the requesting peer.

The said location information of at least one available peer may be dynamically determined.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which: FIG. 1 is a schematic illustration of a peer-to-peer location-based system in an example embodiment. FIG. 2 is a schematic diagram of a network architecture for illustrating the system in the example embodiment.

FIG.3 is a schematic flowchart for illustrating a peer-to-peer engagement in an example embodiment.

FIG.4 is a schematic peer-to-peer transaction flow diagram in an example embodiment.

FIG. 5 illustrates an exemplary scenario for using a 'Hail-A-Cab' location-based service (LBS) mobile application graphical user interface (GUI) in an example embodiment.

FIG. 6 is a schematic logic flowchart of an engagement process in an example embodiment.

FIG. 7 is a schematic block module architecture diagram of an application server in an example embodiment.

FIG. 8 is a schematic block module architecture of a client application in an example embodiment.

FIG. 9 is a schematic flowchart for illustrating a method for locating one or more peers in an example embodiment. FIG. 10 is a schematic drawing of a communication device suitable for implementing an example embodiment.

DETAILED DESCRIPTION In example embodiments described below, a real-time, location-based peer-to- peer interactive method and system may be provided. Peers can use the method and system for engagement. The peers can include entities seeking engagement or offering engagement and can generally include vehicles or vessels for hire. Engagement may mean two users or peers agreeing to transact on or carry out a service such as a passenger hiring a taxi. In the description below, a taxi or cab is used for ease of description for the engagement method and system.

In one example embodiment, one peer (a taxi passenger) and another peer (a taxi driver) can use a geographical location-based system and method to hail for a taxi on the one hand and for the taxi driver to locate the taxi passenger on the other hand. The system and method can provide mobility and convenience to different peers such as taxi passengers and taxi drivers. Furthermore, it can be provided that one peer can view the location(s) of one or more peers for deciding on engagement.

Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide an understanding of example embodiments of the present invention. It will be apparent, however, to one skilled in the art that some embodiments of the present invention may be practiced without some of these specific details.

The terms "coupled" or "connected" as used in this description are intended to cover both directly connected or connected through one or more intermediate means, unless otherwise stated.

The description herein may be, in certain portions, explicitly or implicitly described as algorithms and/or functional operations that operate on data within a computer memory or an electronic circuit. These algorithmic descriptions and/or functional operations are usually used by those skilled in the information/data processing arts for efficient description. An algorithm is generally relating to a self-consistent sequence of steps leading to a desired result. The algorithmic steps can include physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transmitted, transferred, combined, compared, and otherwise manipulated. Further, unless specifically stated otherwise, and would ordinarily be apparent from the following, a person skilled in the art will appreciate that throughout the present specification, discussions utilizing terms such as "scanning", "calculating", "determining", "replacing", "generating", "initializing", "outputting", and the like, refer to action and processes of an instructing processor/computer system, or similar electronic circuit/device/component, that manipulates/processes and transforms data represented as physical quantities within the described system into other data similarly represented as physical quantities within the system or other information storage, transmission or display devices etc.

The description also discloses relevant device/apparatus for performing the steps of the described methods. Such apparatus may be specifically constructed for the purposes of the methods, or may comprise a general purpose computer/processor or other device selectively activated or reconfigured by a computer program stored in a storage member. The algorithms and displays described herein are not inherently related to any particular computer or other apparatus. It is understood that general purpose devices/machines may be used in accordance with the teachings herein. Alternatively, the construction of a specialized device/apparatus to perform the method steps may be desired.

In addition, it is submitted that the description also implicitly covers a computer program, in that it would be clear that the steps of the methods described herein may be put into effect by computer code. It will be appreciated that a large variety of programming languages and coding can be used to implement the teachings of the description herein. Moreover, the computer program if applicable is not limited to any particular control flow and can use different control flows without departing from the scope of the invention.

Furthermore, one or more of the steps of the computer program if applicable may be performed in parallel and/or sequentially. Such a computer program if applicable may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a suitable reader/general purpose computer. In such instances, the computer readable storage medium is non-transitory. Such storage medium also covers all computer-readable media e.g. medium that stores data only for short periods of time and/or only in the presence of power, such as register memory, processor cache and Random Access Memory (RAM) and the like. The computer readable medium may even include a wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in bluetooth technology. The computer program when loaded and executed on a suitable reader effectively results in an apparatus that can implement the steps of the described methods. The example embodiments may also be implemented as hardware modules. A module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using digital or discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC). A person skilled in the art will understand that the example embodiments can also be implemented as a combination of hardware and software modules.

Further, in the description herein, the word "substantially" whenever used is understood to include, but not restricted to, "entirely" or "completely" and the like. In addition, terms such as "comprising", "comprise", and the like whenever used, are intended to be non- restricting descriptive language in that they broadly include elements/components recited after such terms, in addition to other components not explicitly recited. Further, terms such as "about", "approximately" and the like whenever used, typically means a reasonable variation, for example a variation of +/- 5% of the disclosed value, or a variance of 4% of the disclosed value, or a variance of 3% of the disclosed value, a variance of 2% of the disclosed value or a variance of 1 % of the disclosed value.

Furthermore, in the description herein, certain values may be disclosed in a range. The values showing the end points of a range are intended to illustrate a preferred range. Whenever a range has been described, it is intended that the range covers and teaches all possible sub-ranges as well as individual numerical values within that range. That is, the end points of a range should not be interpreted as inflexible limitations. For example, a description of a range of 1% to 5% is intended to have specifically disclosed sub-ranges 1% to 2%, 1% to 3%, 1% to 4%, 2% to 3% etc., as well as individually, values within that range such as 1%, 2%, 3%, 4% and 5%. The intention of the above specific disclosure is applicable to any depth/breadth of a range.

A Location-Based Service (LBS), for example a mobile computing application, can provide services to users based on geographical locations. In an example embodiment, there can be provided a peer-to-peer (for example, passenger-to-taxi driver or taxi driver-to- passenger) locating system e.g. in the taxi transportation sector and that uses a LBS e.g. for real-time, interactive 'taxi-hailing' and/or 'Passenger-Location'. The LBS may use functionality such as 'find nearby taxis' and 'tell me if the taxi is hired or booked within my vicinity.' etc. The LBS may then assist in solving issues such as assisting passengers to 'hail-a-cab', assisting taxi drivers searching for potential passengers to 'locate-a-passenger' and potentially alleviating the inefficiency of the call centers system operated by taxi companies.

In an example embodiment, a taxi passenger can 'hail-a-taxi' real-time using a communication device, such as a smartphone, to access or begin a Location-Based Service (LBS) that allows locating the taxis in the vicinity. Using the LBS, the taxi passenger is able to locate visually via a graphical display, e.g. on a map, a number of taxis available in the vicinity. The passenger is further able to access an application server via wireless access or the internet to e.g. obtain information on trips taken, to retrieve and check past travelling records, payment records and receipts of the passenger.

In an example embodiment, a taxi driver can 'locate-a-taxi passenger' real-time using a communication device, such as a processor unit installed in the taxi or a smartphone, to access or begin a Location-Based Service (LBS) that allows locating potential passengers in the vicinity. Using the LBS, the taxi driver is able to locate visually via a graphical display, e.g. on a map, the passengers awaiting taxis in the vicinity. The taxi driver is further able to access an application server via wireless access or the internet e.g. to obtain information on trips taken, to retrieve and check past travelling records, payment records on taxi fares and receipts of the taxi driver.

In an example embodiment, a LBS mobile application in a passenger communication device can communicate with a corresponding LBS mobile application of a taxi driver via an application server for the passenger to hail a taxi in real-time. Using the LBS mobile application, taxi passengers are able to 'hail-a-taxi' of their choice by locating visually via a graphical display, e.g. on a map, the number of taxis available in the vicinity, send a job request to a taxi of choice, track the movement of the taxi and preferably, transacting payments.

In an example embodiment, a LBS mobile application in a taxi driver's communication device can communicate with a corresponding LBS mobile application in a passenger's communication device via an application server for the taxi driver to locate a potential passenger in real-time. Using the LBS mobile application, taxi drivers are able to 'locate-a-passenger' of their choice by locating visually via a graphical display, e.g. on a map, the number of potential passengers available in the vicinity, send potential passengers a service request, allow tracking of the engaged passenger movement and preferably, transacting payments. FIG 1 is a schematic illustration of a peer-to-peer location-based system 100 in an example embodiment. In the example embodiment, one peer is exemplarily indicated as a potential passenger utilising a passenger communication device such as a mobile device 110. Another peer is exemplarily indicated as a taxi driver utilising a taxi driver communication device such as a mobile device 150. In the example embodiment, each peer (passenger or taxi driver) has full control over his/her location information. For example, the taxi driver is able to disable location tracking by turning his/her location status off. Each of the communication devices 110, 150 comprise a client application 180 that can communicate with an application server 130. The applicant server 130 is located remote or in a different location from the users using communication devices 110, 150. Preferably, the application server 130 is coupled to and communicates with a payment solutions server 120.

In the example embodiment, the application server 130 seeks to provide administrative functions such as administering transaction logs etc. that can assist in recording and/or accounting purposes.

FIG. 2 is a schematic diagram of a network architecture 200 for illustrating the system 100 in the example embodiment. The network architecture 200 comprises a service for determining location such as a GPS satellite service 230, a medium for allowing communication between the communication devices 110, 150 and the application server 130 such as a mobile carrier 210 in wireless (or wired/fixed) communication with the communication devices 110, 150 and in a network (or internet) 220 communication with the application server 130. The mobile carrier 210 may be a telephone company (telco). The application server 130 may be in a network (or internet) 240 communication with the payment solutions server 120. It will be appreciated that the network (or internet) communications 220,240 can be wireless or wired/fixed.

FIG.3 is a schematic flowchart 302 for illustrating a peer-to-peer engagement in an example embodiment. At step 300, a user (a peer such as a passenger or a taxi driver) downloads and/or installs a client application into a communication device. The client application (e.g. client application 80 of Figures 1 and 2) enables peer-to-peer engagement. The downloading and/or installing may be dependent on the type of communication device being used. For example, communication devices can include Apple iOS iphones, Google's android-based phones, Blackberry's smartphones and Windows-based devices etc. At steps 310 and 350, the user registers via his/her communication device as a peer, e.g. a passenger at step 310 or a taxi driver at step 350. For example, for a taxi driver, some registration details can comprise contact number, company name, taxi number, bank account details etc. For a passenger, some registration details can comprise contact number, credit card details, common/favourite pickup locations or "bookmarks" etc. Compare also with description of numeral 603. The credit card details can be stored in e.g. both phone local database and/or the application server, depending on implementation parameters. It may be provided that an OTP (one-time password), or a SMS code or the like can be generated and sent to the user for verification purposes such that the user is verified as a bona fide user.

The following description is separated into first describing the passenger peer portion before proceeding to describing the taxi driver peer portion. The passenger peer portion is shown on the left hand side of Fig. 3 and the taxi driver peer portion is shown on the right hand side of Fig. 3.

Thereafter, at step 311, upon starting/running the client application, the location status of the passenger is set to ON'. Starting or running the client application may be activated e.g. by activating an on/run button/slidebar for the client application on a graphical display of the communication device (compare 110 in Figures 1 and 2). This may comprise a touch signal sensed on a capacitive touch-screen or the like of the communication device.

Starting/running the client application comprises sending an activation signal to an application server (compare 30 in Figures 1 and 2) indicating a desire to begin engagement. The activation signal can comprise location information of the activating peer (the passenger). In certain example embodiments, the location information may be provided at a later stage, e.g. at the search stage. The location information can be provided by a LBS of the communication device (compare 110 in Figures 1 and 2). In alternative example embodiments, the location information can be supplemented or wholly provided by peer provided information. For example, in alternative example embodiments, the location information for pickup may be provided, or amended/supplemented, by the passenger, i.e. a desired pickup point, for example extrapolated from current position. Providing the location information may comprise entering a pickup address via a browser connected to the internet, or dragging an icon on a touchscreen graphical display to a desired location. In certain example embodiments, starting/running the client application can indicate that a peer is available for engagement with another peer, e.g. indicating to taxis that the passenger is available for a pickup by a taxi or indicating to a passenger that there are available taxis for engagement.

At step 312, the registered passenger may use the client application to search and display visually on a graphical display on the communication device all available engagement peers, such as taxis, within a radar range specified. These are peers that indicated availability on their communication devices (compare 150 in Figures 1 and 2, and described later at step 351). The client application can be activated for the search with a search button button/slidebar for the client application on a graphical display of the communication device to search for available taxis. This may comprise a touch signal sensed on a capacitive touch-screen or the like of the communication device. The radar range or vicinity can be pre-determined or selectable from a list depending on user requirement e.g. a radius of 10 to 100 meters, 100 to 500 meters and 500 meters to 1 kilometer etc.

Activating the search comprises sending a request signal to the application server (compare 130 in Figures 1 and 2) to transmit available peers information within the specified vicinity. The request signal can comprise the pre-determined or selected range, as range information. At the application server (compare 130 in Figures 1 and 2), a search is conducted through a database to determine peers suitable for engagement (e.g. taxis) based on the location information of the requesting peer (the passenger) and the received range information. The application server (compare 130 in Figures 1 and 2) then sends the results of the peers suitable for engagement to the requesting peer communication device (compare 110 in Figures 1 and 2). The results can be displayed in a graphical display on the communication device.

At step 313, the passenger may retrieve and view details relating to located taxi drivers' comprising information such as taxi company details, vehicle details and other details such as ratings, comments etc. provided by former passengers. The retrieval may be based on the passenger selecting each displayed peer on the graphical display. That is, the graphical representation of the taxis or vehicles are displayed on the passenger's communication device for selection. The details can be transmitted from the application server upon selection. Alternatively, the details may be transmitted together with the results information in step 312. At step 314, upon reviewing the details, the passenger is free to select a preferred taxi and to send a job request to the selected taxi driver. That is, a job request signal is sent from the requesting peer communication device (compare 110 in Figures 1 and 2) to the communication device (compare 150 in Figures 1 and 2) of the peer for engagement via the application server (compare 130 in Figures 1 and 2). As an alternative, the job request signal can be sent directly from the requesting peer communication device (compare 10 in Figures 1 and 2) to the communication device (compare 150 in Figures 1 and 2) of the peer for engagement, bypassing the application server (compare 130 in Figures 1 and 2).

In the example embodiment, the job request signal comprises the passenger location information that may be current location or a desired pickup location. Preferably, the job request can comprise a desired destination. At the communication device (compare 150 in Figures 1 and 2) of the peer for engagement (e.g. a selected taxi), the job request is indicated on a graphical display for acceptance or rejection.

In the example embodiment, the taxi driver may choose to reject or accept the job request received. If the taxi driver rejects the job request, the passenger is notified by a rejection signal and the passenger can proceed to choose a next choice. That is, the process loops to step 312. Such communication can be via the application server or directly between the requesting peer communication device (compare 110 in Figures 1 and 2) to the communication device (compare 150 in Figures 1 and 2) of the peer for engagement, bypassing the application server (compare 130 in Figures 1 and 2). For direct communication, for example, a communication link between the devices can be established with the assistance of the application server transmitting link details (such as device identification number or internet protocol (IP) address etc) to the communication devices. Direct communication may also be implemented with other forms of direct peer-to-peer communication technologies.

At step 315, if the taxi driver accepts the job request, an acceptance message is sent to the passenger communication device (compare 110 in Figures 1 and 2) e.g. via the application server. It will be appreciated that such technology may also be implemented by telcos. At step 316, the client application switches the passenger's location status to "OFF". At step 317, the passenger receives the acceptance/confirmation message through SMS or "in-application" using the client application. Preferably, the passenger and the taxi driver are removed (or status switched to "OFF") from a list of available peers/users at the application server (compare 130 in Figures 1 and 2) such that they appear "invisible" to other users. In such instances, although the passenger and the taxi driver appear "invisible", they are still able to view other users whose statuses are "ON".

In the example embodiment, at step 318, the passenger is able to track the movement of the engaged peer, i.e. the 'hailed' taxi, in real-time on the graphical display on the communication device (compare 110 in Figures 1 and 2). That is, the passenger can visually follow the movement of the engaged taxi via e.g. maps and routing modules of a LBS application on the passenger communication device (compare 110 in Figures 1 and 2). At step 319, when the taxi arrives at the pickup location, the passenger boards the taxi. At step 320, the passenger receives a service fee payment acknowledgement request message. The taxi driver can initiate the service fee payment request acknowledgement message to the passenger. This can be via the taxi driver sending a 'picked up' message from the communication device (compare 50 in Figures 1 and 2) to the application server (compare 130 in Figures 1 and 2). The passenger then receives the service fee payment request acknowledgement message from the application server (compare 130 in Figures 1 and 2).

At step 321, when the passenger acknowledges the service fee payment acknowledgement request message, the engagement/services process is complete. Following this, the payment process occurs.

In the example embodiment, since the registered passengers had entered credit card details during registration with the application server, after the driver initiates the payment process during "pick up" (compare step 320) and upon the passenger's acknowledgement e.g. by pressing a button in the mobile application (compare step 321), the passenger's credit card details are sent to a payment module or payment solution host for processing. For example, the payment solution host is connected to a credit card host of an acquiring bank to complete the transaction. Both the driver and the passenger can be notified of the status of the transaction. In the example embodiment, both passengers and taxi drivers are able to view transaction records from the application server. As an alternative to credit card payment, the passenger and/or the driver are allowed to select cash payment over credit cards for the service fee payment. For the taxi driver peer portion shown on the right hand side of Fig. 3, a peer, e.g. a taxi driver, may play an active role in searching for potential engagement peers, e.g. passengers, in the vicinity using a communication device (compare 150 in Figures 1 and 2) and using a LBS application of the communication device. As a user, the taxi driver registers the role of a peer at step 350.

At step 351 , the taxi driver may play an active role in searching for potential passengers and need not wait for potential passengers to send job requests. Upon starting/running the client application on the communication device (compare 50 in Figures 1 and 2), the location status of the taxi driver is set to ON'. Starting or running the client application may be activated e.g. by activating an on/run button/slidebar for the client application on a graphical display of the communication device (compare 150 in Figures 1 and 2). This may comprise a touch signal sensed on a capacitive touch-screen or the like of the communication device.

Starting/running the client application comprises sending an activation signal to an application server (compare 130 in Figures 1 and 2) indicating a desire to begin engagement. The activation signal can comprise location information of the activating peer (the taxi driver). In certain example embodiments, the location information may be provided at a later stage, " e.g. at the search stage. The location information can be provided by a LBS of the communication device (compare 150 in Figures 1 and 2). In alternative example embodiments, the location information can be supplemented or wholly provided by peer provided information. For example, in alternative example embodiments, the location information for pickup may be provided, or amended/supplemented, by the taxi driver, i.e. a desired pickup point or a taxi stand. This may comprise the driver entering location details using a web browser, or dragging an icon on a touchscreen graphical display to a desired location.

In certain example embodiments, starting/running the client application can indicate that a peer is available for engagement with another peer, e.g. indicating to taxis that the passenger is available for a pickup by a taxi or indicating to a passenger that there are available taxis for engagement.

At step 352, the registered taxi driver may use the client application to search and display visually on a graphical display on the communication device (compare 150 in Figures 1 and 2) all available engagement peers, such as potential passengers, within a radar range specified. These are peers that indicated availability on their communication devices (compare 110 in Figures 1 and 2, and described at step 311). The client application can be activated for the search with a search button button/slidebar for the client application on a graphical display of the communication device to search for available engagement peers. This may comprise a touch signal sensed on a capacitive touch-screen or the like of the communication device. The radar range or vicinity can be pre-determined or selectable from a list depending on user requirement e.g. a radius of 10 to 100 meters, 100 to 500 meters and 500 meters to 1 kilometer etc.

Activating the search comprises sending a request signal to the application server (compare 130 in Figures 1 and 2) to transmit available peers information within the specified vicinity. The request signal can comprise the pre-determined or selected range, as range information. At the application server (compare 130 in Figures 1 and 2), a search is conducted through a database to determine peers suitable for engagement (e.g. passengers) based on the location information of the requesting peer (the taxi driver) and the received range information. The application server (compare 130 in Figures 1 and 2) then sends the results of the peers suitable for engagement to the requesting peer communication device (compare 150 in Figures 1 and 2). The results can be displayed in a graphical display on the " communication device.

At step 353, the taxi driver may retrieve and view details relating to located passengers comprising information such as past engagement success rates, comments etc. provided by previous taxi drivers. The retrieval may be based on the taxi driver selecting each displayed peer (passenger) on the graphical display. That is, the graphical representation of the potential passengers are displayed on the taxi driver's communication device for selection. The details can be transmitted from the application server upon selection. Alternatively, the details may be transmitted together with the results information in step 352. At step 354, upon reviewing the details, the taxi driver is free to select a preferred passenger and to send a service request to the selected passenger. That is, a service request signal is sent from the requesting peer communication device (compare 150 in Figures 1 and 2) to the communication device (compare 110 in Figures 1 and 2) of the peer for engagement via the application server (compare 130 in Figures 1 and 2). As an alternative, the service request signal can be sent directly from the requesting peer communication device (compare 150 in Figures 1 and 2) to the communication device (compare 1 10 in Figures 1 and 2) of the peer for engagement, bypassing the application server (compare 130 in Figures 1 and 2).

In the example embodiment, the service request signal comprises the taxi location information that may be current location or desired pickup location.

At the communication device (compare 110 in Figures 1 and 2) of the peer for engagement (e.g. a selected passenger), the job request is indicated on a graphical display for acceptance or rejection.

In the example embodiment, the passenger may choose to reject or accept the service request received. If the passenger rejects the service request, the taxi driver is notified by a rejection signal and the taxi driver can proceed to choose a next choice. The rejection signal can be sent via the application server. That is, the process loops to step 352.

At step 355, if the passenger accepts the service request, an acceptance message is sent to the taxi driver communication device (compare 150 in Figures 1 and 2). The acceptance signal can be sent via the application server.

At step 356, the client application switches the taxi driver's location status to "OFF".

At step 357, the taxi driver receives the acceptance/confirmation message through SMS or the client application. Preferably, the passenger and the taxi driver are removed (or status switched to "OFF") from a list of available peers/users at the application server (compare 130 in Figures 1 and 2). In such instances, although the passenger and the taxi driver appear "invisible", they are still able to view other users whose statuses are "ON". In the example embodiment, at step 358, the taxi driver is able to track the location of the engaged peer, i.e. the engaged passenger, in real-time on the graphical display on the communication device (compare 150 in Figures 1 and 2), until the taxi driver reaches the location to pick the passenger up, unless a cancellation request from the passenger is received. The passenger can also be allowed to track the location of the taxi driver (compare step 318).

At step 359, when the taxi arrives at the pickup location, the passenger boards the taxi.

At step 360, the taxi driver can initiate the service fee payment request acknowledgement message to the passenger. This can be via the taxi driver sending a 'picked up' message from the communication device (compare 150 in Figures 1 and 2) to the application server (compare 130 in Figures 1 and 2). The passenger then receives the service fee payment request acknowledgement message from the application server (compare 130 in Figures 1 and 2).

At step 361 , when the passenger acknowledges the service fee payment acknowledgement request message, the engagement/services process is complete. Following this, the payment process occurs. In the example embodiment, since the registered passengers had entered credit card details during registration with the application server, after the driver initiates the payment process during "pick up" (compare step 320) and upon the passenger's acknowledgement e.g. by pressing a button in the mobile application (compare step 321), the passenger's credit card details are sent to a payment module or payment solution host for processing. For example, the payment solution host is connected to a credit card host of an acquiring bank to complete the transaction. Both the driver and the passenger can be notified of the status of the transaction. In the example embodiment, both passengers and taxi drivers are able to view transaction records from the application server. As an alternative to credit card payment, the passenger and/or the driver are allowed to select cash payment over credit cards for the service fee payment.

FIG.4 is a schematic peer-to-peer transaction flow diagram 400 in an example embodiment. This example on transaction flow is shown from the perspective of a peer e.g. a passenger engaging another peer e.g. hailing a cab or taxi using a communication device (compare 1 10 in Figures 1 and 2). Certain steps are not included for ease of illustration. At numeral 401 , the passenger requests a display of all available peers for engagement e.g. available taxis in a nearby vicinity, e.g. within a radius of about 100 meters. The request is sent from a client application having a LBS application in the passenger's communication device 110 to an application server 130.

At numeral 402, the application server 130 requests location information from a client application having a LBS application of taxi drivers' communication devices 150, those communication devices 150 indicating to the application server 130 of their availability and within the specified vicinity.

At numeral 403, the location information of the available taxis are then returned to the application server 130. At numeral 404, the application server 130 obtains the location information and sends the information for display on the passenger's communication device 110.

At numeral 405, the passenger requests the service of a taxi of choice from the passenger's communication device 110 and sends the selected taxi driver a job request. This may be directly between the passenger and the taxi driver or via the application server.

At numeral 406, the taxi driver's acceptance of the job request is returned as a confirmation message to the passenger communication device 110 and the location status of the passenger is turned 'OFF'. At numeral 407, upon a pick-up of the passenger, the driver initiates a service fee request message to the passenger through the application server 130.

At numeral 408, the passenger receives the service fee acknowledgement request message on the communication device 110. At numeral 409, upon boarding the taxi, the passenger acknowledges that the taxi has arrived and the engagement service is completed. At numeral 410, the application server 130 initiates a payment request to the payment solution server 120 to charge a service fee to the passenger e.g. via the passenger's credit cards. At numeral 411 , the service fee is paid to the driver to complete the transaction process. FIG. 5 illustrates an exemplary scenario for using a 'Hail-A-Cab' LBS mobile application graphical' user interface (GUI) in an example embodiment. The flow process is indicated at numeral 510. The LBS mobile application can function substantially similar to the client application 180 and/or as described with reference to Fig.3. Certain steps are not included for ease of illustration. In the example embodiment, the user is registered as a passenger.

For example, the passenger may begin the process of engaging a peer, e.g. hailing a cab, by activating the mobile application in a communication device e.g. a smart mobile device. An assumption is made that the user is a registered passenger and wanting to hail a taxi to a desired destination.

At the starting page 511, the passenger starts the LBS mobile Application, exemplarily called 'Hail-A-Cab', and the passenger's status is set to "online" or "on". That is, the status makes the passenger "visible" to taxi drivers searching for passengers. The passenger is allowed to enter trip information and search for available taxis in the vicinity. Available taxis can be represented by symbols, graphical icons or any other suitable representations, on their current locations in a graphical manner on a map provided by the mobile application. The passenger is able to view details of the taxis represented by the graphical icons. The graphical icons can have properties and attributes such as colors, numbers etc to represent different types of taxis, the number of taxis etc. at the different locations.

At a details page 512, taxi details can be viewed. These details may include, but are not limited to, showing registered taxi drivers' details, the type of taxis available, taxi company details, registered vehicle numbers, starting taxi fares, payment types available, languages spoken and other information such as user ratings and comments provided by previous passengers etc.

At a booking page 513, prior to sending a job request, the passenger is able to enter e.g. trip information, types of payment and other preferences. A confirmation screen 514 can be displayed before sending the job request to a selected taxi driver for acceptance. Subsequently, the passenger sends the job request to the taxi driver and once the taxi driver accepts the job request, a confirmation message 515 is received. The confirmation message displays a message indicating that the booking is confirmed by the taxi driver and may provide e.g. an estimated time of arrival (ETA). At a tracking screen 516, the passenger may proceed to track the location of the taxi visually on a graphical display on a map via the mobile application.

FIG. 6 is a schematic logic flowchart of an engagement process in an example embodiment. The flowchart illustrates both an exemplary 'hail-a-cab' and an exemplary 'locate-a-passenger' logic process flow. Certain steps are not included for ease of illustration.

At step 601 , a user downloads a client application to a communication device such as a mobile device and registers, at step 602, as either a passenger (at step 604) or a taxi driver (at step 603). The client application can function substantially similar to the client application 180 and/or as described with reference to Fig.3.

At step 604, the passenger enters profile information, preferred payment methods that can include credit card(s) information for payment of service fees or taxi fares, emergency contacts etc. At step 603, the taxi driver enters the taxi driver details, bank account information e.g. for receipt of service fees and taxi fares, and emergency contacts in event of emergencies etc. Preferably, during emergencies, the client application can dial to an emergency number specified. At step 605, the user accepts the terms and conditions that can include privacy settings to allow tracking of the location of the user.

Subsequent to the user accepting the privacy setting at step 605, at step 607, the client application can be started. At step 608, the location status is turned 'ON' when the application runs/starts on the communication device. At step 609, the location status being 'ON' or "online" allows the passenger to 'hail-a-cab' or the taxi driver to 'locate-a-passenger'. Compare steps 31 1 and 351 of Fig.3. At step 610, the passenger or the taxi driver are then able to send a job or a service request message respectively. Compare steps 314 and 354 of Fig.3.

If an acknowledgement to the job or service request message is received, the location status can be turned 'OFF' or "offline" at step 612. Compare steps 316 and 356 of Fig.3. Otherwise, the user loops to re-send or repeat the step 610. At step 613, each user/peer can view and/or track the location of the other engaging user/peer. For example, the passenger is able to track the location and/or movement of the taxi until the taxi arrives to pick up the passenger. Compare steps 318 and 358 of Fig.3. At step 614, if a user activates a cancel request after an acknowledgement of a job or service request message is received, a notification message is sent, at step 615, to the other engaging user. For example, if a passenger activates the cancel request after acknowledgement is received before the taxi turns up, a notification message is sent to the taxi driver. At step 615, the application server is also informed of the cancellation and the number of cancelled trips per user can be logged e.g. for rating purposes.

At step 617, if a user defaults, i.e. does not complete the engagement without sending a cancellation request, at step 615, the application server can be informed of the default and the number of defaults per user can be logged e.g. for rating purposes. For example, in the event a taxi driver defaults in picking up a passenger or a passenger defaults a taxi driver, this information can be sent by the defaulted user to the application server and the information is logged for rating the user that defaulted accordingly. For example, the default can be triggered by the defaulted user activating/clicking a no-show button on the communication device. In such an instance, the passenger or the taxi driver may repeat respectively, at step 616, the 'hail-a-cab' or 'locate-a-passenger' process from step 607.

At step 618, the engagement proceeds as intended. For example, the driver arrives to pick up the passenger as promised. Compare steps 319 and 359 of Fig.3. At step 619, the taxi driver can then initiate a service fee payment request message for the passenger to acknowledge. Compare steps 320 and 360 of Fig.3. At step 620, the passenger proceeds to acknowledge the service fee payment request message. Compare steps 321 and 361 of Fig.3. At step 621 , both users are notified of the successful transactions by the payment solutions server (compare 120 in Figure 1). The payment solution server is understood to be a payment gateway which facilitates the transfer of information between a payment portal (such as a website, mobile phone or interactive voice response IVR service) and a Front End Processor or acquiring bank. Thus, when a passenger orders a service from a payment gateway-enabled merchant, in this case, the taxi driver, the payment gateway performs a variety of tasks to process the transaction between the passenger and the driver. FIG. 7 is a schematic block module architecture diagram of an application server in an example embodiment. The application server 700 can function substantially similarly to the application server 130 in Figures 1 and 2. In the example embodiment, the application server 700 comprises a plurality of modules that communicate with a user/peer client application (e.g. a passenger or taxi driver mobile application). Compare 180 in Figures 1 and 2. The functionalities of each module are described as follows. A mobile-server integration module 31 is provided and can handle client-server communications between the passenger mobile application 180 and an application logic module 32 that is coupled to the mobile-server integration module 31. The mobile-server integration module 31 processes one or more functions provided by the application logic module 32 in a secure manner during transmissions to the mobile application.

The application logic module 32 contains business logic for e.g. graphical user interfaces of the mobile application such as, but not limited to, logic for hailing a cab/taxi, searching or displaying available taxis within a specific range/vicinity, viewing real-time running information on taxis, and updating a user' s location when boarding the taxi etc.

A database module 33 is provided coupled to the application logic module 32. The database module 33 is for storing application specific information such as, but not limited to, number of user trips and estimated arrival/departure times etc. A notification service module 34 is provided for sending notifications to passengers when a booking is confirmed or when the taxis are approaching their destination etc. The notifications can be triggered on a regular basis (e.g., once a minute), or via an update notification on tracked users (passengers or taxis) from a location service. A SMS service module 35 provided coupled to the notification service module 34 and is capable of sending SMS notifications e.g. to passengers when a booking is confirmed or when payment is made via a payment solutions server 120.

A real-time running processor module 36 is provided for requesting real-time updates on e.g. taxi locations and estimated arrival/departure times if available, and for updating relevant data points accordingly. The updates can be triggered to run on a regular basis (e.g., once a minute). Updates may be pushed or transmitted to the real-time running processor module 36 from the user mobile applications, e.g. from taxi drivers.

A user management module 37 is provided for allowing the users (e.g. passengers, taxi drivers) to e.g. register user information, view transactions records, update details and settings etc. In an example embodiment, the profile of the passengers and the taxi details of the taxis are recorded in the application server 700. The user management module 37 can be made accessible by users via the internet e.g. using an internet browser. The user management module 37 can provide a backend administration page that administers users' profiles, settings, properties and attributes settings etc.

A transaction management module 38 is provided for keeping transaction records such as number of trips, the payment amounts, trips details, methods of payments etc. The transaction management module 38 can be made accessible by users via the internet e.g. using an internet browser. A user may retrieve, view and print past transactions history, trips history, receipts and statement of accounts etc.

A payment module 39 is provided for allowing users e.g. passengers to select different methods of payments. The payment module 39 can integrate to various payment platforms available such as mobile payment, credit card or debit card payment gateways.

A location service and location update service module 40 is provided coupled to the modules 32, 34, 36, 37, 38 and 39. The location service and location update service module 40 is capable of accessing and storing location trace information about users such as passengers and taxis. In an example embodiment, the location service and location update service module 40 is implemented using the OpenLS Tracking specification, to enable other modules in the application server 700 to easily make use of location update and notification functionalities. In an alternative example embodiment, a commercial product can be used to provide the functionality of these modules. These modules can also be reusable between different LBSs.

Furthermore, the location service and location update service module 40 can update e.g. the location of taxis, can calculate e.g. estimated time of arrival/departure at pickup/interchange points, and can determine e.g. taxis locations and estimated time of arrival etc. The location service and location update service module 40 can also clean up specific user information, such as mobile phone identifiers, once a user has completed a trip. In an example embodiment, to handle a data-intensive process, a production rules engine such as JBoss Drools or IBM iLog can be used for the implementation of the module. The location service and location update service module 40 can be triggered on a regular basis (e.g., once a minute) or e.g. via an update notification on vehicle movements from a location service.

FIG. 8 is a schematic block module architecture of a client application in an example embodiment. The client application 800 can function substantially similar to the application 180 described in Figures 1 and 2 and/or with reference to any one of Figures 3 to 7. In this example embodiment, the client application is a mobile LBS application for use by users (e.g. passengers and taxi drivers).

In this example embodiment, the passenger or taxi driver mobile application 800 is a mobile LBS application that runs on the user's communication device such as a smartphone. The mobile application comprises a graphical user interface and a plurality of modules such as one for searching for available taxis or passengers, for entering trip information, a module for managing location and movement information, a client-server communications module, and a push notification handler module etc. An application module 81 is provided and comprises a user interface. The application module 81 can facilitate communication between an application server 130 and one or more modules such as a messaging module 82, a maps and routing module 83, a location module 84, a privacy module 85, a content module 86 and a billing module 87 etc. The application module 81 can also communicate/operate various functionalities such as SMS, MMS, LBS and payment modules e.g. 89 provided e.g. by a mobile operator or telco 90 through one or more gateway connector 88 services.

A messaging module 82 is provided for an instant messaging service, and a location module 84 is a LBS-client component for location information provisioning. Location information requests are signaled via specially encoded instant messages between clients on participating mobile devices. A GPS positioning device e.g. at the communication device can be used for sending raw location coordinates (e.g. Longitude-Latitude-Altitude) to a requesting peer. Using the location information, a map or street address can be obtained from e.g. an external map server of the positioned peer (e.g. from Google Maps) via e.g. GPRS connectivity technology. The interface between a LBS client and an application service provider can use standardized HTTP or SIP based communication protocol.

In the example embodiment, a positioning request between two mobile peers (e.g. passenger and taxi drivers) is carried out as follows. A mobile peer (e.g. a passenger) registered with a location-based service can request the position of another fellow registered peer (e.g. a taxi driver) from a messaging menu.

Depending on the peer's (e.g. taxi driver's) privacy settings (e.g. handled by a privacy module 85), a message pop-up can be displayed on the taxi driver's communication device display showing the passenger's request. If the taxi driver's privacy setting is set to 'accept allowed' for a requesting peer/user, the message pop-up can be skipped. If the request of the passenger is granted by the taxi driver, GPS coordinates of the taxi driver can be converted to a special message format and transmitted to the passenger communication device. Once the required position coordinates are received by the passenger, a map showing the taxi driver's location (e.g. handled by a maps and routing module 83) can be received from an online map server.

Alternatively, the distance to the remote peer (e.g. the taxi driver) can be calculated at the passenger's communication device using location information from a GPS device or application installed in the passenger's communication device. Therefore, it is possible to locate nearby taxis, and preferably triggering an instant message if registered taxi drivers come into range of the passenger communication device. The above can be implemented by performing periodic location requests to registered peers.

In the example embodiment, a location request between peers (e.g. passengers and taxi drivers) can be carried out if the peers are "online". Hence, preferably, a polling of the presence status (online/offline) of peers can be carried out before sending any location requests.

In the example embodiment, a billing module 87 is provided for handling payment services such as service charges or taxi fares. The other modules, such as content module 86, connector 88, modules 89 and 90 can be generic modules not generally utilised in the example embodiments. Fig. 9 is a schematic flowchart 900 for illustrating a method for locating one or more peers in an example embodiment. At step 902, location information of a requesting peer is determined. At step 904, location information of at least one available peer for engagement is determined based on the location information of the requesting peer. At step 906, the location information of the at least one available peer is transmitted to the requesting peer.

Other Exemplary Example Embodiments

In alternative embodiment 1 , there is provided a system for a peer-to-peer (passenger-to-taxi driver or Taxi driver-to-passenger) locating system in the taxi transportation sector comprising: an application server that communicates with the Passenger Mobile LBS application and the Taxi Driver Mobile LBS application, integrates to the payment solution server and provide user access via internet for administration purposes such as registration, edit of user profiles and settings, view and retrieval of transactional records on number of trips, receipts and statement of accounts; A Passenger Mobile LBS application that runs in the Passenger mobile device, communicates with the application server, and enables the passenger to 'hail-a-taxi'; A taxi Mobile LBS application that runs in the taxi driver mobile device, communicates with the application server, and enables the taxi driver to 'locate-a-passenger'; A payment solution server integrated to the application server with various platforms of payment services.

In alternative embodiment 2, there is provided a system as mentioned in embodiment 1 wherein the application server comprises: A Mobile-server integration module that is responsible for handling client-server communications between the Passenger Mobile Application and the Application Logic Module. It processes functions provided by the Application logic module in a secure manner to the mobile application; and An Application Logic Module which contains the business logic for the user interface of the application, searching or displaying available taxis within specific range, viewing real-time running information on taxis, and updating a user' s location when boarding the taxi ; and A Database Module that is responsible for storing application specific information and data store such as such as user trips and estimated arrival/departure times; and A Notification Service module that is responsible for sending notifications to passengers when a booking is confirmed or when the taxis are approaching their destination. The notification is triggered on a regular basis or via an update notification on tracked passengers or taxis from the Location service; and A Real-time Running Processor module that is responsible for requesting realtime updates on the taxi locations and estimated arrival/departure times if available, and updates relevant data points accordingly, triggering on a regular basis. Updates are pushed to it from the taxi mobile application; and A SMS Service module that is responsible for sending notifications to passengers when a booking is confirmed or when payment is made via payment solutions server.

In alternative embodiment 3, there is provided a system as mentioned in embodiment 2 wherein the application server further comprises: A User Management Module accessible by the user via the internet that allows the users to register, view transactions records, update details and settings etc. It administers users profile, settings, properties and attributes settings; and The Transaction Management Module that administer transaction records such as number of trips, the amounts, trips details, methods of payments etc, and is accessible by the user via the internet. The user may retrieves, view and print past transaction history, trips history, receipts and statement of accounts; and A Payment M Module that is responsible for the passengers to select the methods of payments. This module integrates to various payment platforms available such as mobile payment, credit card or detail card payment gateways.

In alternative embodiment 4, there is provided a system as mentioned in embodiment 1 wherein the Payment Solution Server comprises: Payments of taxi fares or admin charges using online credit card or debit card facilities through the LBS application and authenticated via mobile SMS and billing through the banks; and Payments of taxi fares or admin charges using mobile payments and billing through the telephone companies; and Payments of taxi fares or admin charges using online credit card, debit card facilities or mobile payments and billing through third party payment service provider.

In alternative embodiment 5, there is provided a system as mentioned in embodiment 1 wherein the Mobile LBS application comprises: An application module that consists of a user interface and communicates between the Application Server and various modules such as Messaging module, Maps and routing module, location module, privacy module, content module and billing module.

In alternative embodiment 6, there is provided a system as mentioned in embodiment 4 wherein the Mobile LBS application further comprises: The application module also communicates with the various functionality features such as SMS, MMS, LBS and Payment provided by the Mobile Operator through Gateway connectors services. In alternative embodiment 7, there is provided a system as mentioned in embodiment 4 wherein the Mobile LBS application further comprises: A Messaging Module for the instant messaging service provisioning and purposes; and A Location Module for the location information provisioning and purposes; A Map and routing module for showing the user location and receiving map information from the online map server; and A privacy module responsible for handling user's privacy settings; and A content module responsible for processing and displaying application content; and A billing module responsible for handling user selected payment methods. In alternative embodiment 8, there is provided a method for passenger-to-taxi driver locating system comprising: A mobile LBS application in passenger mobile device communicating with the LBS application in the taxi driver mobile device via an application server; and Locating and searching for the taxis within the vicinity of the passenger and viewing the graphical representation of the taxis in the mobile device; and Viewing the taxi details in the mobile device; and Setting the privacy settings to Online' and enter trip information; and Sending a job request the taxi driver; and Receiving booking confirmation via messaging or SMS after Taxi driver accept the job request; and Contact the taxi driver via messaging, sms or mobile; and Track the location of the booked taxi real-time on the mobile device; and Taxi fare and /or administrative charges Payment through mobile device.

In alternative embodiment 9, there is provided a method for taxi driver-to-passenger locating system comprising: A mobile LBS application in driver mobile device communicating with the LBS application in the passenger mobile device via an application server. Locating and searching for the passengers within the vicinity of the taxis and viewing the graphical representation of the Passenger in the mobile device; and Viewing the Passenger profile in the mobile device; and Setting the privacy settings to 'online' and enter taxi vehicle details, taxi fare charges, vehicle registration number, contact details; and Sending a service request the passenger; and Receiving booking confirmation via messaging or SMS after Taxi driver accept the job request; and Contact the passenger's via messaging, sms or mobile; and View the location of the Passenger real-time on the mobile device; and Received Taxi fare and /or administrative charges Payment confirmation through mobile device.

In alternative embodiment 10, there is provided a method as mentioned in embodiment 8 for passenger-to-taxi driver locating system further comprises: Accessing the application server via the internet for user registration, administer user profile, access information on trips, retrieve ana cnecK past traveling recoras, payment records ana receipts. In alternative embodiment 11 , there is provided a method as mentioned in embodiment 9 for taxi driver-to-passenger locating system further comprises: Accessing the application server via the internet for user registration, administer user profile, accessing information on trips, retrieve and check past traveling records, payment records on taxi fares and receipts.

In alternative embodiment 12, there is provided a method for taxi drivers and passengers locating system, comprising of the steps of: The user, being the passenger or taxi driver, downloads the LBS client application to the user's mobile device; The user registers as either passenger or taxi driver, entering information such as profile, preferences, payment methods, bank accounts, emergency contact number and taxi vehicle details into the system; The user shall agree to the terms and conditions of using the software, including accepting the privacy settings of allowing their locations to be tracked and monitored; The user's location status is 'ON' when the application runs. The user is able to search and display the other users in the vicinity via the mobile device. For example, a passenger is able to search and display locations of the taxis while the taxi driver is able to search and display locations of the passengers; The user is able to send a job or service request to the other user; and the other user is free to choose to accept the acknowledgement or reject the request; and In the event of any cancellation, both the user and the application server are being notified and the user shall repeat the process again; Upon acknowledgement by the other user, the user's location status is 'OFF' and the user is able to track the location of the other user whom accepted his job request. If the user is a passenger, he will board the taxi (the other user) upon the arrival of the taxi; The taxi driver will send a service fee payment Tequest for the passenger to acknowledge; and upon receiving acknowledgement, the payment solution server will send both users a notification on successful transaction.

In another example embodiment, a requesting peer (e.g. a passenger) can enter location information in a browser connected e.g. to the internet and indicate via the interface that the requesting peer is available for engagement. The location information of at least one available peer for engagement (e.g. one or more taxi drivers) may be obtained and filtered according to the location information of the requesting peer. The obtained location information of the at least one available peer for engagement is then transmitted to the requesting peer and e.g. can be displayed as symbols on the browser for selection by the requesting peer. The selection and engagement steps are thereafter substantially similar to the steps as described with reference to Fig.3. Different example embodiments can be implemented in the context of data structure, program modules, program and computer instructions executed in a communication device. An exemplary communication device is briefly disclosed herein. One or more example embodiments may be embodied in one or more communication devices e.g. 1000, such as is schematically illustrated in Fig. 10.

One or more example embodiments may be implemented as software, such as a computer program being executed within a communication device 1000, and instructing the communication device 1000 to conduct a method of an example embodiment.

The communication device 1000 comprises a processor module 1002, an input module such as a touchscreen interface or a keypad 1004 and an output module such as a display 1006 on a touchscreen.

The processor module 1002 is coupled to a first communication unit 1008 for communication with a cellular network 1010. The first communication unit 1008 can include, but is not limited to, a subscriber identity module (SIM) card loading bay. The cellular network 1010 can, for example, be a 3G or 4G network.

The processor module 1002 is further coupled to a second communication unit 1012 for connection to a network 1014. For example, the second communication unit 1012 can enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN) or a personal network. The network 1014 can comprise a server, a router, a network personal computer, a peer device or other common network node, a wireless telephone or wireless personal digital assistant. Networking environments may be found in offices, enterprise-wide computer networks and home computer systems etc. The second communication unit 1012 can include, but is not limited to, a wireless network card or an eternet network cable port. The second communication unit 1012 can also be a modem/router unit and may be any type of modem/router such as a cable-type modem or a satellite-type modem.

It will be appreciated that network connections shown are exemplary and other ways of establishing a communications link between computers can be used. The existence of any of various protocols, such as TCP/IP, Frame Relay, Ethernet, FTP, HTTP and the like, is presumed, and the communication device 1000 can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Furthermore, any of various web browsers can be used to display and manipulate data on web pages.

The processor module 1002 in the example includes a processor 1016, a Random Access Memory (RAM) 1018 and a Read Only Memory (ROM) 1020. The ROM 1020 can be a system memory storing basic input/ output system (BIOS) information. The RAM 1018 can store one or more program modules such as operating systems, application programs and program data. The processor module 1002 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 1022 to the display 1006, and I/O interface 1024 to the keypad 1004.

The components of the processor module 1002 typically communicate and interface/couple connectedly via an interconnected bus 1026 and in a manner known to the person skilled in the relevant art. The bus 1026 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. It will be appreciated that other devices can also be connected to the system bus

1026. For example, a universal serial bus (USB) interface can be used for coupling an accessory of the communication device, such as a card reader, to the system bus 1026.

The application program is typically supplied to the user of the communication device 1000 encoded on a data storage medium such as a flash memory module or memory card/stick and read utilising a corresponding memory reader-writer of a data storage device 1028, The data storage medium is not limited to being portable and can include instances of being embedded in the communication device 1000. The application program is read and controlled in its execution by the processor 1016.

Intermediate storage of program data may be accomplished using RAM 1018. The method(s) of the example embodiments can be implemented as computer readable instructions, computer executable components, or software modules. One or more software modules may alternatively be used. These can include an executable program, a data link library, a configuration file, a database, a graphical image, a binary data file, a text data file, an object file, a source code file, or the like. When one or more processor modules execute one or more of the software modules, the software modules interact to cause one or more processor modules to perform according to the teachings herein.

The operation of the communication device 1000 can be controlled by a variety of different program modules. Examples of program modules are routines, programs, objects, components, data structures, libraries, etc. that perform particular tasks or implement particular abstract data types.

The example embodiments may also be practiced with other computer system configurations, including handheld devices, multiprocessor systems/servers, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, personal digital assistants, mobile telephones and the like. Furthermore, the example embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wireless or wired communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

The functions and advantages that have been discussed above in various example embodiments can be achieved independently or may be combined in yet other example embodiments.

In example embodiments, the communication devices are not limited to mobile or smartphones and can take the form of e.g. desktop personal computers (PCs), laptops, tablet PCs, mobile music players and the like.

In example embodiments, the location-based service can comprise a mechanism for determining geographical location information and can be, but not limited to, a Global Positioning Service (GPS), a GSM (Global System for Mobile Communications) triangular location service, wi-fi location service or the like. The service can even include a user entry of an engagement location information such as entering an address information using a web browser connected to a network (such as the Internet).

In example embodiments, the location-based service can be integrated with the client application or may be separate from and coupled to the client application (such as a native GPS installed on a smartphone). In example embodiments, the wireless communication with the telco may be via wi-fi, 3G, 4G networks or the like. The network between the telco and the application server, and/or between the application server and the payment server, may be a wired network or wi-fi, 3G, 4G, optic fiber networks or the like.

In example embodiments, the presenting of the location information is not limited to a visual display on a GUI and can include, but not limited to, audio prompts, presentation in a list format etc. In some example embodiments, the determining of the location information can be construed as a dynamically determining step to distinguish the method and system of such example embodiments from conventional location maps showing fixed entities such as buildings, landmarks etc. In some example embodiments, for a passenger, if there are no available taxis available for hire, a list of call-centre numbers may then be provided to the passenger for selecting call-centres to try for bookings.

In some example embodiments, once a passenger and a taxi driver has confirmed requests for engagement, an option may be made available for the passenger and taxi driver to communicate directly over a voice call. That is, a call button may be provided on a touchscreen graphical display.

In some example embodiments, if a user (passenger or taxi driver) were to exit an " application (app) for the engagement, it may be provided that the status of the user is then changed to "OFF" or offline.

In described example embodiments, as the application server is not primarily used for searching and handling pairing of users offering engagement and users requesting engagement, the processing load for the application server is significantly reduced as compared to current call-centre-type servers. Furthermore, in some example embodiments, it can be provided that the client application communicates with the application server on a periodic basis, e.g. every 30 seconds or 1 minute, to update the users offering engagement and users requesting engagement, so as to further reduce processing load, as compared to an always-on communication format. It will be appreciated by a person skilled in the art that other variations and/or modifications may be made to the specific embodiments without departing from the scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.