WO2015159276A1

WO2015159276A1 - Data routing and processing systems and methods

Info

Publication number: WO2015159276A1
Application number: PCT/IB2015/052878
Authority: WO
Inventors: Peter Jeffrey Young; Michael William Young
Original assignee: Auxilium Ltd
Priority date: 2014-04-18
Filing date: 2015-04-20
Publication date: 2015-10-22

Abstract

Systems and methods for a data routing and processing system are described, whereby a request message is received from a requestor device, the request message identifying a request and one or more binding parameters associated with the request, at least one candidate responder device is determined based on predefined selection criteria, the request is routed to the or each candidate responder device, a response message is received from at least one candidate responder device associated with the request, and in response, a binding action associated with the requestor device and the or each candidate responder device that responds to the request is generated, based on the one or more binding parameters.

Description

Data Routing and Processing Systems and Methods

Field of the Invention

[0001] This invention relates to a data communications system, and more particularly to a data routing and processing system.

Background

[0002] Mobile communication devices, such as cellular phones, and other hand-held communication devices, such as tablets, are widely used. These devices have a variety of features such as, but not limited to: multimedia messaging, audio-video capturing, web browsing, data manipulation, and location mapping. Mobile devices and terminals have been equipped with precise location awareness and tracking technologies, such as global positioning systems (GPS), triangulation or other location technologies. In addition, a sub group of cellular phones, known as 'smart phones' can communicate with each other wirelessly over networks such as 3G, 4G, Bluetooth or the internet.

[0003] It is worth noting that in the communications industry, mobile device communications, data transfer and location awareness can also occur via cellular towers and base stations (transceiver stations) which can interact with individual mobile devices as well as cellular towers and base stations in adjacent or other geographical areas. These mobile communication devices, cellular towers and base stations can exchange data via entire mobile device communication networks (MDCNs), which can utilise different types of technology, such as GSM, PCS, CDMA, UMTS etc.

[0004] Whilst users of these mobile communication devices are in their home or community carrying out their daily duties, they may encounter problems, inconveniences or at worst emergency situations. Such problems, inconveniences or emergency situations may include, but are not limited to, the following: the breakdown of a vehicle whilst on the way to work, encountering someone requiring medical attention whilst shopping, being involved in a traffic accident and requiring medical attention, being attacked by a gang of hostile people late at night after socialising with friends, being lost in the countryside and requiring directions, forgetting to take money to a petrol station and realising once the petrol tank is full and also running out of money whilst out socialising with friends or a long distance away from home.

[0005] To address the problem of a user not being able to operate a mobile communication device during some emergency situations such as a debilitating accident or attack, mobile devices have been described in the art which incorporate technologies such as temperature gauges to detect fire, accelerometers to detect sudden impact, and voice activation along with set key sequences or operations (such as constant pressure on volume controls or the detachment of speaker leads) to send an alert via MDCNs to the emergency services. Emergency services are then able to locate the emergency activated mobile device via the MDCNs or technologies such as GPS. Examples of such systems are discussed in US 2008/0284587 and US 2005/0037730 disclose such systems.

[0006] In addition, mobile communication devices have been described in the art as having special functions, for example rapid photo or video capture over a prolonged period, which become active when stimulated in personal safety emergency situations like attack in order to collect and transfer evidence data to secure data collection means. Such functions and data collection described in the art is limited to the mobile communication device of the person in the actual emergency situation.

[0007] Under unfortunate circumstances such as those already described, having a mobile communication device can be of great value for the user. If the user is capable of using their mobile communication device they will, for instance, be able to call friends, family or the emergency services for help. However, situations may occur where no friends or family will be in the vicinity of the user, and the emergency services may be some time or distance away from being able to help.

Summary of the Invention

[0008] Aspects of the present invention are set out in the accompanying claims.

[0009] According to one aspect of the present invention, a data routing and processing system is provided comprising: a receiver operable to receive a request message from a requestor device, the data message identifying a request associated with a location, and including one or more binding parameters associated with the request; a request handler operable to determine at least one candidate responder device based on the location associated with the request; a request router operable to transmit the request to the or each candidate responder device; and a request tracker operable to receive a response message from at least one candidate responder device associated with the request, and in response, generate a binding action associated with the requestor device and the or each candidate responder device that responds to the request, based on the one or more binding parameters.

[0010] The request handler may determine at least one candidate responder device having a location within a predefined distance of the location associated with the request. The system may be further configured to process the binding action in response to receiving indication that the request is completed. The request handler may be further configured to determine that a request is complete based on the relative distance between the requestor device and a responder device.

[0011] The system may be further configured to collect location data from requestor and/or responder devices. The system may be further configured to collect location data at predefined intervals. The system may be further configured to dynamically vary the frequency that location data is collected from requestor and/or responder devices. Location data may be collected from the requestor and/or candidate responder devices at shorter time intervals after a request message is received from the requestor device. The predefined intervals may be varied based on information received from the responder and/or requestor device.

[0012] The location associated with the request may be determined from collected location data. Alternatively, data identifying the location associated with the request may be included in the request message. The location data may include movement data identifying direction and/or velocity of the associated device.

[0013] The request handler may be further operable to determine at least one candidate responder device based on the movement data. The request handler may be further operable to calculate an estimated location of a device based on the movement data and elapsed time since the location data was collected. The request handler may be further operable to determine at least one candidate responder device based on calculated time of arrival to the location associated with the request. [0014] The data routing and processing system may be further configured to close a request after a predefined number of candidate responder devices have responded to said request.

[0015] The system may be further configured to adjust criteria to determine candidate responder devices in the absence of a predefined number of candidate responder devices that may have responded to said request.

[0016] The system wherein the data message may further include data identifying a request type, and wherein the request handler may be further operable to determine at least one candidate responder device based on the request type. Furthermore, the request type may be compared to profile data associated with a candidate responder device. The request handler may be further operable to determine a further candidate responder device in response to receiving a response message indicating rejection of the request. The request handler may be operable to determine at least one candidate responder device from stored data identifying a plurality of registered devices.

[0017] The system may be further configured to transmit updated location data associated with the request. The data routing and processing system wherein the request handler may be configured to determine that further candidate responder devices are available based on updated location data.

[0018] The system wherein the request router may be operable to generate a data message for the or each candidate responder device identifying said request.

[0019] In another aspect, the present invention provides a system comprising a receiver operable to receive a data message from a requestor device, the data message identifying a request and one or more binding parameters associated with the request; a request handler operable to determine at least one candidate responder device based on predefined selection criteria; a request router operable to transmit the request to the or each candidate responder device; and a request tracker operable to receive a response message from at least one candidate responder device associated with the request, and in response, generate a binding action associated with the requestor device and the or each candidate responder device that responds to the request, based on the one or more binding parameters. [0020] The system may further comprisie a database storing data identifying a plurality of responder devices and respective associated profile data; wherein the received request further includes data identifying a request type, and wherein the request handler is operable to determine a predefined number of candidate responder devices having associated profile data that match the request type. The system wherein the received request further includes data identifying a location of the request, and wherein the request handler is further operable to determine a predefined number of candidate responder devices based on proximity to the request location.

[0021] In another aspect, the present invention provides request handling system operable to receive and store location data associated with a plurality of devices; receive a request for assistance from one of said devices; identify at least one candidate device in proximity of the requesting device, based on the stored location data; and notify the at least one candidate device of said request

[0022] In another aspect, the present invention provides a mobile device operable in a first mode to generate and transmit a request for assistance at a location of the mobile device, and in a second mode to receive and respond to a request for assistance from a requestor device at a proximal location, wherein a request includes an associated location and one or more binding parameters, and wherein a response initiates a binding action associated with the requestor device based on the one or more binding parameters.

[0023] The mobile device may further comprise a peripheral device communicatively coupled therewith, the peripheral device having means for initiating the request.

[0024] The mobile device may be further operable to periodically transmit data identifying a current location of the device. The mobile device further configured to dynamically vary the frequency that location data may be transmitted at shorter time intervals after a request for assistance is generated. The mobile device may be further operable to output directions to the request location. The mobile device may be further operable to initiate a communication channel with a requestor device. The mobile device may be further configured to automatically generate a request based on sensor data and predefined criteria. The mobile device wherein the sensor data may be received from one or more of: accelerometer, heart rate detector, blood pressure detector, oxygen saturation detector, body temperature detector, respiration rate detector, adrenaline level detector, and perspiration detector. The mobile device may be further configured to respond to user input to generate a request for assistance in said first mode. The mobile device may be further configured to capture audio and/or video data in the first mode of operation, and to include the captured data in the generated request for assistance. The mobile device may be further configured to receive profile data associated with a responder device and to prompt the user for acceptance of said responder device.

[0025] In further aspects, the present invention provides a data routing and processing method for receiving a request message from a requestor device, the request message identifying a request and one or more binding parameters associated with the request; determining at least one candidate responder device based on predefined selection criteria; routing the request to the or each candidate responder device; and receiving a response message from at least one candidate responder device associated with the request, and in response, generating a binding action associated with the requestor device and the or each candidate responder device that responds to the request, based on the one or more binding parameters..

[0026] In yet other aspects, there is provided a request handling method for receiving and storing location data associated with a plurality of devices at predefined intervals; receiving a request for assistance from one of said devices; identifying at least one candidate device in proximity of the requesting device, based on the stored location data; and notifying the at least one candidate device of said request.

[0027] In yet other aspects, there is provided a computer readable medium, which when executed by a suitable computer, causes the computer to carry out the above methods.

[0028] In yet other aspects, there is provided a computer readable medium comprising instructions which, when executed by a suitable computer, causes the computer to become configured as the system.

Brief Description of the Drawings

[0029] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below. [0030] Figure 1 is a block diagram showing the main components of a data communications system according to an embodiment of the invention.

[0031] Figure 2, which comprises Figures 2a to 2c, is a flow diagram illustrating the main processing steps performed by the system of Figure 1 according to an embodiment.

[0032] Figure 3 is a diagram of an example of a computer system on which one or more of the functions of the embodiment may be implemented.

Description of Embodiments Overview

[0033] Referring to Figure 1, a block diagram showing the main components of a data communications system 100 according to an embodiment is illustrated. The data communications system 100 comprises a data routing and processing server 110, that is communicatively coupled to the requestor device 170 and a plurality of responder devices 190 via data network 150. A request handler 112 of server 110 receives a request message from a requestor device 170, for example via a communications interface 118. The request message includes data identifying a request, for example, for a form of assistance by a responder associated with a responder device. In this embodiment, a candidate determiner 116 of the request handler 112 determines at least one candidate responder device 190 based on predefined selection criteria, such as proximity of the candidate responder devices 190 to a location associated with the received request, for example a geo-location of the requestor device 170 at the time the request message is generated. A request router 114 forwards the request to the or each candidate responder device 190, for example via the communications interface 118. .

[0034] The requestor device 170 and responder devices 170 may be mobile computing devices, such as a laptop, a smart phone, a tablet computer, or the like, in electronic communication with the data routing and processing server 110 via data network 150. The data network 150 may be any suitable data communication network such as a wireless network, a local- or wide-area network including a corporate intranet or the Internet, using for example the TCP/IP protocol, or a cellular communication network such as Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), CDMA2000, Enhanced Data Rates for GSM Evolution (EDGE), Evolved High-Speed Packet Access (HSPTA+), Long Term Evolution (LTE), etc., or combination thereof.

[0035] The server 110 may include a registration module 121 for generating and storing data identifying registered requestor device 170 and responder devices 190 in a database 122 of the server 110. As shown in Figure 1, the registered devices database 122 stores a data record 124 for each registered device, each data record 124 can include a device identifier 126 uniquely identifying the respectively device, location data 128 identifying a last known location of the device, and profile data 130 relating to the device and/or a user associated with the device. For example, the profile data 130 may define parameters, characteristics, traits, preferences, or the like.

[0036] In this embodiment, the request handler 112 creates and stores a request data record 134 in a database 132 for each received request from the requestor device 170. Each request data record 134 can include the device identifier 136 of the associated requestor device 170 and data identifying a location 138 associated with the request. The request location data may be included in a received request message from the requestor device 170, or may be retrieved from previously stored location data 128 in the respective data record 124 of the requestor device 170. A location updater module 123 may be provided to prompt, collect and update the stored location data 123 of registered devices, for example at predefined time intervals or frequencies.

[0037] The data record 134 may also include request type data 140 identifying the type of request and/or details or parameters associated with the request. The request type data 140 may include, for example, data identifying that the request is an emergency request with a higher level of urgency, a request for a particular type or nature of assistance, such as a lift or ride to work, a request for money, goods or services, etc.

[0038] In this embodiment, each request is associated with one or more binding actions, defined by an associated one or more binding parameters included in the request message. The received binding parameters are also stored in the data record 134 associated with the request. As will be described below, the binding action is performed by a binding action processor 119 of the request handler 112 when the associated request is completed, for example in response to receiving data indicating that a requested or predefined minimum number of responder devices 190 have arrived at the location of the request. Binding parameter data may relate to rating/ranking increase or decrease data, reward data, acknowledgement data, competition data, accreditation/recognition data, prize data, sponsorship data or loyalty reward data. Furthermore, reward data may relate to a monetary reward, for example digital currency such as bitcoins, credit transfers etc. In one example, on successful completion of the request, the requestor device 170 may submit binding data in the form of a star rating, based on the performance of the responder device associated with the completion of the request. Furthermore, the responder device associated with the successful request may also provide a star rating, based on aspects of the request such as whether the request was accurate, whether it was a hoax, etc. The binding action processor 119 may be configured to generate a processing instruction to carry out the corresponding binding action based on the one or more binding parameters, such as to transmit a request for rating data from the requestor device 170 and the responder devices 190, or to instruct a payment transaction between financial accounts associated with the requestor device 170 and the responder devices 190, via a payment platform (not shown).

[0039] As mentioned above, the candidate determiner 116 may determine one or more candidate responder devices based on the location data 128 stored in respective data records 124. For example, the candidate determiner 116 may determine one or more candidate responder devices 190 having a calculated distance within a predefined radius of the location associated with the request. The candidate determiner 116 may use a linear distance calculation to select one or more candidate responder devices within the predefined radius. Alternatively, an estimated travel time to the request location may be calculated for each registered responder device 190 in order to determine the subset of candidate responder devices 190.

[0040] Alternatively or additionally, the candidate determiner 116 may select one or more candidate devices based on available profile data 130 stored in the data records 124. Candidate determiner 116 may be configured to determine candidate responder devices 190 that have profile data 130 matching the request type 140 of a received pending request. As an example, a request type 140 may define a medical request type and the candidate determiner 116 may retrieve and filter data records 124 having profile data 130 identifying a user type 130 relating to a medical field. As another example, the candidate determiner 116 may take into account other forms of profile data 130, such as age, sex, profession, etc of the users associated with the respective candidate responder devices 190.

[0041] The candidate determiner 116 is also configured to store device identifiers 126 of the selected candidate responder devices as responder identifier data 144 in the request data record 134 associated with the processed request. The request data record 134 may also include status data 146 associated with a request, for example indicating that the request is a new received request with an open or pending status, or that the request has been completed. Additionally, the status data 146 can include data identifying respective status of a forwarded request to each candidate responder device 190, for example indicating that the request was transmitted to the responder device 190, that a positive or negative response has been received, that a responder device 190 is on route to the request location, or that a responder device 190 is at the request location. A request tracker module 117 of the request handler 146 updates the status data 146 in response to receiving data identifying a change to the status of a received request, for example from the requestor device 170 or responder devices 190, or from determination by the request handler 112 that the request for assistance has been completed.

[0042] The requestor device 170 includes a requestor application module 176a having a request generator 178 for generating the request message, for example in response to user input via user interface 180a. As discussed above, the generated request message can includes user input binding parameters and data identifying a request type. Alternatively, the request may include predefined or default binding parameters without user intervention. The user interface may include a keyboard, a mouse, and/or a touch screen device (a touchpad).

[0043] Optionally, the requestor application module 176a may determine data identifying the current location of the requestor device 170 from a location module 174a of the requestor device 170. The location module 174a may determine the location of requestor device 170 based on, for example, global positioning data, (GPS), access point data and/or mobile cellular base station data.

[0044] The application module 176a is configured to transmit the generated request message to the server 110 via a communications interface 172a.

[0045] The requestor device 170 may also be communicatively coupled to an optional peripheral device 172 via respective peripheral interfaces 182a,b, which may be for example based on Bluetooth, Wi-Fi or any form of Near Field Communications (NFC) protocol.

[0046] Optionally, the peripheral device 172 may carry out processing on behalf of the user interface 180a, for example to provide the requestor application module 176a with input details of the request. For example, the peripheral device 172 may allow the user to manually input their request via the peripheral device 172, which may take the form of a panic button for example.

[0047] The requestor device 170 may further include one or more sensors or monitoring modules (not shown), including for example, an accelerometer, heart rate detector, blood pressure detector, oxygen saturation detector, body temperature detector, respiration rate detector, adrenaline level detector, and perspiration detector. Alternatively or addtionally, the peripheral device 172 may include such a sensor or monitoring module, configured to automatically generate and transmit instructions to the requestor application module 176a to initiate a new request, without user intervention. For example, the sensor could be a heart rate sensor, which is programmed to transmit an automatic request to the requestor application module 176a if the heart- rate sensor detects an abnormal signal.

[0048] As shown in Figure 1, a plurality of responder devices 190 are provided, each having an responder application module 176b configured to receive requests from the server 110 via it's a communications interface 172b. The responder application module 176b may output data identifying a received request and receive input from an associated user relating to the request via user interface 180b, for example to select an open request and indicate acceptance of the associated binding parameters. A response generator module 192 of the responder application module 176b generates a response message that is transmitted back to the server 110 for processing. [0049] In Figure 1, the requestor device 170 and responder devices 190 are illustrated as separate devices in Figure 1, with respective application modules 176a,b. It will be appreciated that a single device may include an application module 176 having both a request generator module 178 and a response generator 192, thereby operable in first and second modes to generate and transmit a request message, and respond to a request message, respectively.

[0050] Optionally, the requestor device 170 and each responder device 190 may be configured to transmit data identifying a current location to the server 110, for example in response to periodic requests for location data from the location updater module 123.

Request handling process

[0051] A brief description has been given above of the components forming part of the data communications system 100 of this embodiment. A more detailed description of the operation of these components in an embodiment will now be given with reference to the flow diagrams of Figure 2.

[0052] As shown in Figure 2A, the process begins at step S2-1 where the requestor application module 176a determines the current location of the requestor device 170 from the location module 174a. The location module 174a determines the current location of the requestor device 170 from available global positioning system (GPS) data, available mobile base-station data, available wireless access point data, or a combination of these types of data.

[0053] At step S2-3, the requestor application module 176a transmits the current location of the requestor device 170 as a data message to the server 110, via communications interface 172a. The data message also comprises the device identifier of requestor device 170.

[0054] At step S2-5, the server 110 receives the data message from the requestor device 170 via its communications interface 118. Subsequently, location updater 123 updates location data, within location 128, for the data record 124 associated with the device identifier of the data message received from the requestor device 170.

[0055] At step S2-7, one or more responder devices, for example responder device 190, will also determine their current location. Responder application module 176b will determine the current location of responder device 190 in a similar way as described for the responder device 170. Furthermore, at step S2-9, the responder application module 176b will transmit the location of the responder device 190 as a data message to the server 110, via communications interface 172b. The data message will also comprise the device identifier of the responder device 190.

[0056] In this embodiment, the aforementioned steps S2-1 to S2-9 are performed as background steps. Therefore, steps S2-1 to S2-9 are performed periodically and a number of times before step S2-11, which is defined in this embodiment as the start of the foreground steps. Therefore, the server 110, as described in the overview section, has pre- stored location information and device identifier information for a number of responder devices and requestor devices within its registered device database 122.

[0057] At step S2-11, the application module 176a receives, via the user interface 180a, a user input to initiate a request. This could be in the form of the user depressing one, or a number of buttons on the user interface 180a. Furthermore, the user interface 180a may emulate one or a number of buttons, for example if the user interface is a touch screen.

[0058] At step S2-13, the application module 176a receives a user input via user interface 180a defining one or more binding parameters. The one or more binding parameters allow a binding action to be associated with the requestor device 170 and candidate responder devices 190, wherein the binding action will be performed when the request has been completed. For example, a binding parameter may relate to a star rating/ranking, publicity data, acknowledgement data, award data, loyalty data, digital currency data, charitable donations or competition entries.

[0059] In this embodiment, a binding parameter has been chosen to represent star rating data. The binding action associated with the requestor device 170 and candidate responder devices 190 is that star rating data will be provided for candidate responder devices 190 that successfully complete the request.

[0060] At step S2-15, which is optional, the application module 176a may instruct the requestor device 170 to enable audio, image and/or video capturing technology within the requestor device, wherein the requestor application module 176a collects the associated data. This has an advantage of allowing the requestor device 170 to capture data relating to the request, which could be used as evidence in the example of an emergency request. The captured data may be transmitted to the server 110, during the request in order to prevent data loss if the requestor device is stolen/damaged for example.

[0061] At step S2-17, the requestor application module 176a instructs the request generator 178 to generate a request based on the received input. Therefore, the request generator 178 generates a request including data relating to the device identifier of requestor device 170 and the one or more binding parameters.

[0062] Optionally, the request may include data relating to the request type 140 and data relating to the current location of the requestor device 170. For example, the request type 140 may include data about whether the request is an emergency, or a general request, for example a request for assistance.

[0063] Further, and optionally, the requestor application module 176a may instruct the request generator 178 to generate a request without step S2-13. This may be, for example, if the requestor application module 176a determines that the user input at step S2-11 is an emergency. Therefore, the application module 176a may provide a default one or more binding parameter(s). The requestor application module 176a may be able to determine if the request is an emergency based on one or more 'flags' provided to the requestor application module 176a with the response.

[0064] At step S2-19, the application module 176a transmits the request to the server 110 via communications interface 172a.

[0065] At step S2-21, the request handler 112 receives the request from the requestor device 170 via data network 150 and its communications interface 118. Subsequently, at step S2-23, the request handler 112 generates and stores a request data record 134 based on the received request data. The request handler 112 will store the requestor identifier of the requestor device 170 in data record 134 as requestor identifier 136. The request handler 112 will also store, or determine from a data record 124 associated with the requestor's 170 device identifier stored in registered devices database 122, last known location data of the requestor device 170 in requestor location 138. The request handler 112 will also store the one or more binding parameters associated with the request in binding parameters 142 of the associated data record 134. If the request includes data on the request type, the request handler 112 will store this in request type 140 of the associated data record 134. Furthermore, the request handler 112 will store an open status within status 146, to inform the server 110 that this request has not been completed.

[0066] At step S2-25, the candidate determiner 116 determines one or more candidate responder devices at least based on associated stored location data. For example, the candidate determiner 116 will retrieve the requestor location data 138 and compare against a threshold to location data 128 within data records 124 for registered devices stored in registered devices database 122.

[0067] Optionally, the candidate determiner 116 may select a candidate responder device 190 that is closest to the requestor device 170, by determining the linear distance between both devices.

[0068] Optionally, the candidate determiner 116 may determine a perimeter around the requestor device, and select all candidate responder devices 190 within this perimeter.

[0069] Optionally, the candidate determiner 116 may review location data 128 and/or user type data 130 to determine at least one candidate responder device 190.

[0070] Furthermore, and optionally, the candidate determiner 116 may review registered devices outside of its determined perimeter and select one or more of the candidate responder devices outside of the determined perimeter if it is determined that they can reach the requestor device 170 at a similar time. For example, a user of a responder device within the perimeter but on foot may reach the requestor device 170 at a similar time to a user of a responder device outside of the perimeter but who is traveling by car, for example.

[0071] It is also envisaged that the candidate determiner 116 may calculate a time of arrival for the candidate responder devices. This calculation may be based on available mapping and building specification data. The candidate determiner 116 may also determine the current direction and/or speed of the candidate responder devices before determining one or more candidate devices.

[0072] Subsequently, at step S2-27, the request handler transmits the request to the one or more selected candidate devices. Request router 114 may route the request to the one or more candidate devices without the request router 114 modifying the request. Therefore, the request will include at least the requestor identifier 136, and one or more binding parameters 142.

[0073] Optionally, the request router 114 may incorporate more data within the request, for example relating to updated location data from requestor location 138.

[0074] At step S2-29, the application module 176b receives a data message including the request from the server via communications interface 118 and data network 150.

[0075] At step S2-31, the application module 176b instructs the user interface 180b to output data identifying the request from the received data message. For example, the application module 176b may instruct the user interface 180b to output data relating to the location of the responder device 170, and details of the one or more binding parameter(s) associated with the request.

[0076] Optionally, the received data message may allow the responder device 190 to communicate directly with the requestor device 170. This may allow data to be transferred between responder device 190 and requestor device 170 relating to the request, their locations and/or the one or more binding parameter prior to the responder device accepting the request. Examples of data that could be transferred could be voice data, video data or instant messaging data.

[0077] At step S2-33, the application module 176b may receive via user interface 180b a user selection of the request for intended response. For example, the user selection may relate to an acceptance of the request, or a rejection of the request.

[0078] At step S2-35, the application module 176b instructs the responder device 190 to transmit a response message associated with the selected request via communications interface 172b and data network 150.

[0079] At step S2-37, the request tracker 117 receives the response message associated with the request. In this embodiment, it is assumed that the data message from the responder device includes an acceptance of the request.

[0080] Alternatively, the data message from the responder may indicate a rejection of the request. In response, the request handler 112 will update the data record 134 associated with the request. In particular, the request handler 112 will update the responder identifiers 144 within the data record for the candidate responder devices that reject the request. In some cases, the candidate responders that rejected the request are tracked by the request tracker 117 to ensure that they no longer receive updates relating to the request.

[0081] Subsequently, at step S2-38, the binding action processor 119 generates a binding action associated with the requestor device 190 and the responder device 170, based on the one or more binding parameter(s), as discussed previously.

[0082] At step S2-39, the request handler 112 updates the status data 146 of data record 134 associated with the request. For example, the status data 146 may be updated to store data relating to the number of candidate responder devices attending the request.

[0083] At step S2-40, the server 110 may optionally initiate a communication channel between the requestor device 170 and the, or each, candidate responder devices 190. This may have an advantage of allowing real-time updates to the request and/or location of the requestor device 170 and/or the, or each, candidate responder devices 190.

[0084] At step S2-41, the request tracker 117 receives data indicating that request is complete. The request tracker 117 may receive this data from the server 110, the requestor device 170 and/or the, or each, responder devices 190.

[0085] For example, the request tracker 117 may have tracked the progress of the request, and informed the request handler 112 when the request is completed. In some examples, the data received by the server 110 may comprise device identifier(s) of the, or each, responder device 190 that may have successfully carried out the request.

[0086] It is envisaged that there are many alternatives for the request tracker 117 receiving data indicating that the request has been completed. For example, the location updater 123 may determine that the location data for the requestor device 170 and at least one responder device 190 is within a threshold. Therefore, the location updater 123 may determine that the requestor device and the responder device 190 are at the same location. Thus the location tracker 117 may be informed that the request has been completed based on the location data of the requestor device 170 and the responder device 190.

[0087] Optionally, the requestor device 170 and/or the responder device 190 may transmit a data signal to the request tracker 117, informing the request tracker 117 that the request has been completed. The transmission of the data signal may be automatic, for example based on proximity of the requestor device 170 and responder device 190, or manually implemented by a user of the requestor device 170 and/or responder device 190.

[0088] At step S2-42, the status 146 of data record 134 is updated to indicate that the request is complete for each responder device associated with the request.

[0089] At step S2-43, the request handler 112 may instruct the request router 114 to generate a request complete message(s) for the, or each, responder device, and instruct the server 110 to transmit the request complete message(s) to the, or each, responder device 190 via communications interface 118 and data network 150.

[0090] In an alternative embodiment, it is envisaged that the request router 114 may generate notifications, as well as route them to the one or more candidate devices.

[0091] Subsequently, at step S2-45, the request handler 112 processes the binding action of the complete request. For example, the binding action processor 119 may request that feedback information is provided for the requestor device 170 and the, or each, responder device 190 associated with the request.

[0092] In some other cases, the binding action processor 119 may transmit a data message to a payment account of the requestor device 170, indicating that funds need to be transferred to a corresponding account for the, or each ,responder device 190 associated with the completed request.

[0093] Optionally, the request tracker 117 may determine that several candidate responder devices may have been associated with the completion of the request. Therefore, the request tracker 117 may provide responder identifiers to the binding action processor 119 so that the binding action can be applied, or split, between responder devices associated with completion of the request.

[0094] Optionally, the request tracker 117 may determine, from for example location updater 123, that a pre-defined number of responder devices 190 have reached the location of the requestor device. In this case, the request router 114 may generate a cancellation request message to be transmitted to responder devices that are not at the location of the requestor device 170. The request handler 112 will then update the responder identifiers 144 associated with data record 134 within the requests records database 132. [0095] The server 110 may optionally dynamically vary the frequency that location data is provided to the location updater 123. In some cases, the server 110 may instruct that the frequency of location data be varied. In some other cases, it may be the application module within the requestor/responder device that determines the frequency of location information should be varied. Further, and optionally, location data may be collected by the server at shorter time intervals after a request message bas been received from the requestor device 170. For example, the server 110 may determine that the time between providing location data should be shortened or lengthened depending on, for example, the location of the devices. Furthermore, the server 110 may instruct that a predefined number of location data transmissions should be received within a set time period, for example five data transmissions per thirty minutes.

[0096] Optionally, the location data provided to the server 110 may include movement data identifying the direction and/or velocity of the associated responder/requestor device. In some cases, the candidate determiner 116 may determine candidate devices based on the movement data. Furthermore, the location determiner 123 may calculate an estimated location of a device based on the movement data and elapsed time since the location data was collected.

Alternatives and modifications

[0097] It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.

[0098] For example, in the embodiments described above, it has been described that the application module 176a may receive a user input to initiate a request, via user interface 180a. It will be understood that from the aforementioned disclosure, it is equally possible for the application module 176a to receive an input to initiate a request from peripheral device 172. For example, peripheral device 172 may be a device that forwards a user input to initiate a request to the application module 176a. It is envisaged that the peripheral device 172 could be a panic button, a pull tag, voice activated device, key ring, broach, watch, lanyard, heart rate monitor, or other wearable technology that can forward a user input to initiate a request. [0099] It is also within the scope of this invention that the peripheral device 172 may comprise a sensor capable of automatically initiating a request on a user's behalf. Therefore, the application module 176a may receive a signal from the peripheral device 172 in place of a user input from the user. Such sensors may comprise an accelerometer, heart rate monitor or blood pressure monitor, etc.

[00100] Similarly, it is also envisaged that the user interface 180a may emulate a panic button.

[00101] It is also envisaged that the user input to initiate a request might include a 'flag' to notify the application module 176a that a particular type of request has been initiated, for example an emergency request. In such a request, the application module 176a may generate a request without requiring user input data defining one or more binding parameter(s). This may have an advantage of reducing the time and complexity of the request for a user in an emergency situation.

[00102] In embodiments described above, it has been assumed that data messages have been transmitted via a data network. It is also within the scope of this invention that data messages may be transmitted and received in the form of short message service (SMS) messages. This may be advantageous if the requestor device is in an area of poor reception, and is unable to connect to a data network.

[00103] In embodiments described above, it has been assumed that the requestor device 170 and responder device 190 are pre-registered with the server. However, in some examples, the server may create a new data record for new devices (requestor or responder devices) that it determines are in the vicinity of one or more registered devices. This may be achieved by the server determining devices registered with the data network 150, via for example a home subscriber network database, or information stored within one or more base stations.

[00104] In the embodiments described above, it has been assumed that the server determines one or more candidate responder devices based on associated stored location data. However, it is also envisaged that the server may transmit data regarding the determined one or more candidate responder devices to the requestor device. It is then envisaged that the server may receive a user input from the requestor device selecting one or more preferred candidate responder devices from the number initially transited to the requestor device. The server may then be arranged to only transmit the request to the one or more candidate devices detailed in the user input.

[00105] In the embodiments described above, it has been assumed that the server maintains records for registered devices. It is envisaged that the server may also determine that it needs to update information that has already been provided to the candidate responder devices or requestor device. In one example, the notification generator/request router may transmit update data messages to the devices associated with an open request. In another example, the request router may inform the devices associated with an open request that their data relating to the open request is out of date. In this case, the devices associated with the open request will determine when and how to request the updated data relating to the open request.

[00106] In another example, the request handler may determine that it should delay transmitting updated data relating to an open request to devices associated with the open request. This may be if the request handler has not received a response to a previous message sent to one or more devices associated with the open request. The request handler may determine that the one or more devices associated with the open request may be disabled or be in a location with no connectivity to the data network.

[00107] In embodiments described above, it has been assumed that a responder device that has accepted the request will not subsequently reject the request. However, it is envisaged that a responder device 190 associated with an open request may subsequently reject the request, even if the responder device previously accepted the request. In this case, the application module may receive a user input to decline the request, and transmit this to the server 110.

[00108] As those skilled in the art will appreciate, the user type data 130 associated with a registered device's data record 134, may relate to the profession of the user associated with the registered device. Therefore, it is within the scope of this application that the candidate determiner 116 can select candidate responder devices solely on the user type, without requiring location data.

[00109] As those skilled in the art will appreciate, step S2-15 may be implemented by a user input, or be automatically implemented by server 110. [00110] As those skilled in the art will appreciate, step S2-27 may include the location of the requestor device on a mapping application, for example Google Maps. The location of the responder may also be illustrated on the mapping application, allowing the responder to ascertain their location to the requestor. Furthermore, at this time, the requestor and responder may be able to communicate with each other, prior to the responder accepting the request. Providing mapping data may allow the responder to make an informed decision about the request prior to accepting it. This may have an advantage of reducing responders later canceling their involvement.

[00111] It is envisaged that devices may provide their location periodically, for example, every twenty-five minutes, so that the server 110 can approximate the locations of registered devices.

[00112] It is also envisaged that the server 110 may ping devices for their location data if the server 110 determines that it requires more up to date location data.

[00113] It is also envisaged that the server /application module may require less frequent transmissions of location data to be transmitted if it is determined that the device has low battery. Further, it is also envisaged that the server/application module may require more frequent transmissions of location data if it is determined that the device is moving above a threshold speed. For example, the server/application module may require more frequent location data transmissions if the device is on public transport.

[00114] It is also envisaged that the server 110 can deduce 3D locations of requestors and responders, for example if the requestor and/or responders are in a building. The server/application module may be able to use RFID, Bluetooth and cellular triangulation etc to determine the 3D location.

[00115] It is also envisaged that one or more responders can chat to the associated requestor device instantaneously. Therefore, the requestor device is able to ascertain data relating to all responders via a single instant messaging application, for example. Further, the instant messaging functionality may be supplemented by mapping data.

[00116] As those skilled in the art will appreciate, the requestor device 170 may be implemented as a reduced functionality device. Therefore, the requestor device may only include core functionality to allow a request to be generated and transmitted to the server 110. For example, the requestor device 170 may comprise a panic button, key ring, broach, watch, lanyard, heart rate monitor, or other wearable technology, with the ability to generate and transmit a request to the server 110. The request may be manually generated by a user, or automatically generated by the requestor device 170 without user involvement.

[00117] Furthermore, the requestor device may comprise wearable technology in the form of smart glasses, wherein detecting unusual, or lack of, eye movements may cause a request to be transmitted to the server 110.

[00118] It is also envisaged that examples relating to reduced functionality devices may also apply to peripheral devices, which require a requestor device 170 to relay data to the server 110.

[00119] It is also envisaged that location data may not be utilized when determining candidate responder devices. Other criteria, such as profile data etc, may be utilized to determine one or more candidate responder devices.

[00120] It is also envisaged that the server 110 may determine that it needs to update data associated with a current request for the requestor device 170 and/or responder devices 190. The server 110 may transmit a data message including updated information to the requestor device 170 and/or responder devices 190, or the server 110 may send a message to inform the requestor device 170 and/or responder devices 190 that updated data is available for collection.

[00121] In the embodiment described above, the mobile device stores a plurality of application modules (also referred to as computer programs or software) in memory, which when executed, enable the mobile device to implement embodiments of the present invention as discussed herein. As those skilled in the art will appreciate, the software may be stored in a computer program product and loaded into the mobile device using any known instrument, such as removable storage disk or drive, hard disk drive, or communication interface, to provide some examples.

[00122] Alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims. Computer Systems

[00123] The entities described herein, such as the server 110, requestor device 170 and responder device 190 may be implemented by computer systems such as computer system 1000 as shown in Figure 3. Embodiments of the present invention may be implemented as programmable code for execution by such computer systems 1000. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[00124] Computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 may be any type of processor, including but not limited to a special purpose or a general-purpose digital signal processor. Processor 1004 is connected to a communication infrastructure 1006 (for example, a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[00125] Computer system 1000 also includes a user input interface 1003 connected to one or more input device(s) 1005 and a display interface 1007 connected to one or more display(s) 1009. Input devices 1005 may include, for example, a pointing device such as a mouse or touchpad, a keyboard, a touch screen such as a resistive or capacitive touch screen, etc. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures, for example using mobile electronic devices with integrated input and display components.

[00126] Computer system 1000 also includes a main memory 1008, preferably random access memory (RAM), and may also include a secondary memory 610. Secondary memory 1010 may include, for example, a hard disk drive 1012 and/or a removable storage drive 1014, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 1014 reads from and/or writes to a removable storage unit 1018 in a well-known manner. Removable storage unit 1018 represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by removable storage drive 1014. As will be appreciated, removable storage unit 1018 includes a computer usable storage medium having stored therein computer software and/or data.

[00127] In alternative implementations, secondary memory 1010 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000. Such means may include, for example, a removable storage unit 1022 and an interface 1020. Examples of such means may include a program cartridge and cartridge interface (such as that previously found in video game devices), a removable memory chip (such as an EPROM, or PROM, or flash memory) and associated socket, and other removable storage units 1022 and interfaces 1020 which allow software and data to be transferred from removable storage unit 1022 to computer system 1000. Alternatively, the program may be executed and/or the data accessed from the removable storage unit 1022, using the processor 1004 of the computer system 1000.

[00128] Computer system 1000 may also include a communication interface 1024. Communication interface 1024 allows software and data to be transferred between computer system 1000 and external devices. Examples of communication interface 1024 may include a modem, a network interface (such as an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communication interface 1024 are in the form of signals 1028, which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 1024. These signals 1028 are provided to communication interface 1024 via a communication path 1026. Communication path 1026 carries signals 1028 and may be implemented using wire or cable, fibre optics, a phone line, a wireless link, a cellular phone link, a radio frequency link, or any other suitable communication channel. For instance, communication path 1026 may be implemented using a combination of channels.

[00129] The terms "computer program medium" and "computer usable medium" are used generally to refer to media such as removable storage drive 1014, a hard disk installed in hard disk drive 1012, and signals 1028. These computer program products are means for providing software to computer system 1000. However, these terms may also include signals (such as electrical, optical or electromagnetic signals) that embody the computer program disclosed herein.

[00130] Computer programs (also called computer control logic) are stored in main memory 1008 and/or secondary memory 1010. Computer programs may also be received via communication interface 1024. Such computer programs, when executed, enable computer system 1000 to implement embodiments of the present invention as discussed herein. Accordingly, such computer programs represent controllers of computer system 1000. Where the embodiment is implemented using software, the software may be stored in a computer program product 1030 and loaded into computer system 1000 using removable storage drive 1014, hard disk drive 1012, or communication interface 1024, to provide some examples.

[00131] Alternative embodiments may be implemented as control logic in hardware, firmware, or software or any combination thereof.

Claims

1. A data routing and processing system comprising:

a receiver operable to receive a request message from a requestor device, the data message identifying a request associated with a location, and including one or more binding parameters associated with the request;

a request handler operable to determine at least one candidate responder device based on the location associated with the request;

a request router operable to transmit the request to the or each candidate responder device; and

a request tracker operable to receive a response message from at least one candidate responder device associated with the request, and in response, generate a binding action associated with the requestor device and the or each candidate responder device that responds to the request, based on the one or more binding parameters.

2. The system of claim 1, wherein the request handler is operable to determine at least one candidate responder device having a location within a predefined distance of the location associated with the request.

3. The system of claim 1 or 2, further configured to process the binding action in response to receiving indication that the request is completed.

4. The system of claim 3, wherein the request handler is further configured to determine that a request is complete based on the relative distance between the requestor device and a responder device.

5. The system of any preceding claim, further configured to collect location data from requestor and/or responder devices.

6. The system of claim 5, further configured to collect location data at predefined intervals.

7. The system of claim 6, further configured to dynamically vary the frequency that location data is collected from requestor and/or responder devices.

8. The system of claim 7, wherein location data is collected from the requestor and/or candidate responder devices at shorter time intervals after a request message is received from the requestor device.

9. The system of claim 7, wherein the predefined intervals are varied based on information received from the responder and/or requestor device.

10. The system of any one of claims 5 to 9, wherein the location associated with the request is determined from collected location data.

11. The system of any one of claims 1 to 4, wherein data identifying the location associated with the request is included in the request message.

12. The system of any preceding claim, wherein the location data includes movement data identifying direction and/or velocity of the associated device.

13. The system of claim 12, wherein the request handler is further operable to determine at least one candidate responder device based on the movement data.

14. The system of claim 13, wherein the request handler is further operable to calculate an estimated location of a device based on the movement data and elapsed time since the location data was collected.

15. The system of any preceding claim, wherein the request handler is further operable to determine at least one candidate responder device based on calculated time of arrival to the location associated with the request.

16. The system of any preceding claim, further configured to close a request after a predefined number of candidate responder devices have responded to said request.

17. The system of any preceding claim, wherein the request handler is further configured to adjust criteria to determine candidate responder devices in the absence of a predefined number of candidate responder devices that have responded to said request.

18. The system of any preceding claim, wherein the data message further includes data identifying a request type, and wherein the request handler is further operable to determine at least one candidate responder device based on the request type.

19. The system of claim 18, wherein the request type is compared to profile data associated with a candidate responder device.

20. The system of any preceding claim, wherein the request handler is further operable to determine a further candidate responder device in response to receiving a response message indicating rejection of the request.

21. The system of any preceding claim, wherein the request handler is operable to determine at least one candidate responder device from stored data identifying a plurality of registered devices.

22. The system of any preceding claim, further configured to transmit updated location data associated with the request.

23. The system of any preceding claim, wherein the request handler is configured to determine that further candidate responder devices are available based on updated location data.

24. The system of any preceding claim, wherein the request router is operable to generate a data message for the or each candidate responder device identifying said request.

25. A system comprising:

a receiver operable to receive a data message from a requestor device, the data message identifying a request and one or more binding parameters associated with the request;

a request handler operable to determine at least one candidate responder device based on predefined selection criteria;

26. The system of claim 25, further comprising:

a database storing data identifying a plurality of responder devices and respective associated profile data;

wherein the received request further includes data identifying a request type, and wherein the request handler is operable to determine a predefined number of candidate responder devices having associated profile data that match the request type.

27. The system of claim 25, wherein the received request further includes data identifying a location of the request, and wherein the request handler is further operable to determine a predefined number of candidate responder devices based on proximity to the request location.

28. A request handling system operable to:

receive and store location data associated with a plurality of devices; receive a request for assistance from one of said devices;

identify at least one candidate device in proximity of the requesting device, based on the stored location data; and

notify the at least one candidate device of said request.

29. A mobile device operable in a first mode to generate and transmit a request for assistance at a location of the mobile device, and in a second mode to receive and respond to a request for assistance from a requestor device at a proximal location, wherein a request includes an associated location and one or more binding parameters, and wherein a response initiates a binding action associated with the requestor device based on the one or more binding parameters.

30. The mobile device of claim 29, wherein the mobile device further comprises a peripheral device communicatively coupled therewith, the peripheral device having means for initiating the request.

31. The mobile device of claim 29 or 30, wherein the mobile device is further operable to periodically transmit data identifying a current location of the device.

32. The mobile device of claim 31, further configured to dynamically vary the frequency that location data is transmitted.

33. The mobile device of claim 32, wherein location data is transmitted at shorter time intervals after a request for assistance is generated.

34. The mobile device of any one of claims 29 to 33, wherein the mobile device is further operable to output directions to the request location.

35. The mobile device of any one of claims 29 to 34, wherein the mobile device is further operable to initiate a communication channel with a requestor device.

36. The mobile device of any one of claims 29 to 35, further configured to automatically generate a request based on sensor data and predefined criteria.

37. The mobile device of claim 36, wherein the sensor data is received from one or more of: accelerometer, heart rate detector, blood pressure detector, oxygen saturation detector, body temperature detector, respiration rate detector, adrenaline level detector, and perspiration detector.

38. The mobile device of any one of claims 29 to 37, further configured to respond to user input to generate a request for assistance in said first mode.

39. The mobile device of any one of claims 29 to 38, further configured to capture audio, image and/or video data in the first mode of operation, and to include the captured data in the generated request for assistance.

40. The mobile device of any one of claims 29 to 38, further configured to capture audio, image and/or video data in the second mode of operation, and to include the captured data in the generated request for assistance

41. The mobile device of any one of claims 29 to 39, wherein the mobile device is further configured to receive profile data associated with a responder device and to prompt the user for acceptance of said responder device.

42. A data routing and processing method comprising:

receiving a request message from a requestor device, the request message identifying a request and one or more binding parameters associated with the request; determining at least one candidate responder device based on predefined selection criteria;

routing the request to the or each candidate responder device; and

receiving a response message from at least one candidate responder device associated with the request, and in response, generating a binding action associated with the requestor device and the or each candidate responder device that responds to the request, based on the one or more binding parameters.

43. The method of claim 42, wherein the received request further includes data identifying a request type, and wherein the request handler is operable to determine a predefined number of candidate responder devices having associated profile data that match the request type.

44. The method of claim 42 or 43, wherein the received request further includes data identifying a location of the request, and wherein the request handler is further operable to determine a predefined number of candidate responder devices based on proximity to the request location.

45. A request handling method comprising:

receiving and storing location data associated with a plurality of devices at predefined intervals;

receiving a request for assistance from one of said devices;

identifying at least one candidate device in proximity of the requesting device, based on the stored location data; and

notifying the at least one candidate device of said request.

46. A computer readable medium comprising instructions which, when executed by a suitable computer, cause the computer to become configured as the system of any one of claims 1 to 28 or the mobile device of any one of claims 29 to 40.

47. A computer readable medium comprising instructions which, when executed by a suitable computer, cause the computer to perform the method of any one of claims 41 to 44.