GB2483094A

GB2483094A - Taxi location and availability reporting system

Info

Publication number: GB2483094A
Application number: GB1014256.0A
Authority: GB
Inventors: Sivapathalingham Sivavakeesar; Sivapathalingham Ravishankar
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-08-26
Filing date: 2010-08-26
Publication date: 2012-02-29
Also published as: GB201014256D0

Abstract

An owner or driver of a public transport vehicle, such as taxi or cab, employs wireless transmitting device 100 to advertise the availability of their taxicab for hire on a centralised server 222, whereby current geographic location information and an availability status is transmitted wirelessly to server 22 upon a click of a button/key (170, figure 1). A context-capturing/reporting client within the wireless transmitting device 100 is physically and logically associated with a given vehicle being used to provide one mode of public transport facility where the said context-capturing client device captures and report context information. The invention allows any prospective commuter who is in search of a taxi to easily find a taxi in a particular location by interrogating the server 222 (and an associated repository 260) using a mobile handset 204 running client software 206. The wireless transmitting device 100 may also report speed/velocity information in addition to exact geographic location data, e.g. GPS data, to the traffic database 292.

Description

A Context Capturing Apparatus, System and Methods thereof

Technical Field

The present invention relates to an apparatus, methods and systemlframework for capturing the instantaneous context information pertaining to mobile users.

Background

With the technological advances in nanotechnology, hardware becomes increasingly cheaper -which in turn results in faster, smaller, more accessible, more affordable, and easier to use portable electronic devices enjoying state of the art computing and communication capabilities. The availability of full, capacitive touch screen, LED display (i.e., organic electro luminescent device (OELD)), a flip out QWERTY keyboard and/or an on-screenlsofl keyboard in lieu of a physical keyboard, a track ball for easy navigation, high resolution cameras/camcorders, and the like are becoming increasingly common in small portable electronic devices. It is therefore possible to add various functionalities to a small electronic device or for fusion of various electronic elements to produce one unified multi-functional device that turns out to be cheaper and convenient for the end-user.

Despite the technological advancement, inexpensive way of gathering online traffic information without using sophisticated satellite technology is quite challenging. Most of the traffic information gathering mechanism requires manual involvement whereby one or more human personnel is expected to interpret the online video footages taken by either CCTVsystems installed on major highways and roads or satellites in order. to make coarse judgement regarding the local instantaneous traffic conditions. This process is quite expensive as it requires installation of CCTV in every road and its video footages should be made available to the personnel that are required to judge TO the local traffic situations. More over, in such a scenario there is no way to quantify the local traffic condition in terms of the speed at which (i.e., how speedily) the traffic is moving on a given highway without using sophisticated satellite or similar technologies. Hence, one of the objectives of the present invention is to propose apparatus, system/framework and methodologies for iS one or more representative elements to periodically calculate the instantaneous local traffic condition of every road in a given region in terms of the velocity/speed at which the traffic on a given road, Street or a highway is moving on average, and to populate the results in a central server in order to determine the mean traffic speed on a given road, Street or highway and the like.

Another frustrating aspect of today's modern life despite the technological developments in multiple fronts is that catching a taxi/cab/taxicab in the middle of a city in a strange environment is not straightforward to a new visitor such as a tourist, business traveller or the like unless it is a place of public interest namely a railway station, bus stand, airport and the like. In such an environment, the only possible way is to look for a taxi/cab/taxicab arbitrarily on the road. Another possible solution is to get the telephone number of any local taxi/cab/taxicab operator perhaps from the local tourist information centre or the local resident, and to call for a taxi/cab/taxicab.

Sometimes due to language barrier or unfamiliarity of the place being visited, it is difficult to explain exactly from where the taxi/cab/taxicab is needed.

Hence, one of the objectives of the present invention is to address this issue by proposing appropriate apparatus, systemlfrarnework and methodologies that can make this task easier to an unexpected visitor to a strange city/country.

Navigation becomes one of the main ingredients of modern life-style.

Although navigation devices were used to be stand-alone, with an introduction of smartphones, navigation applications have found a place in the mobile markets. In the light of this phenomenon, the search Engine Giant, Google, is going to unveil its own free navigation application, called Google Maps Navigation, which offers spoken, turn-by-turn directions and is likely going to be seen as a challenge to the incumbents in the location-based services market, like TeleNav and TomTom. With this free navigation application, almost all future smartphone users will tend to use navigation application. Although it has a great potential in the mobile arena, the present invention feels that its potential has not been fully realised, and hence this patent endeavours to fill this gap.

After catching a taxi/cab/taxicab, there is no means for the commuter to find out exactly the locations of the interesting places, tourist attractions, local amenities such as restaurants, hotels, museum. cinemas and the like in the local neighbourhood without talking to the driver of the taxi/cab/taxicab, manually collecting some tourist brochures from the local tourist information centres, or browsing on a personal mobile phone all these operations are inconvenient and turn out to be expensive from the perspectives of a given commuter. Hence, another objective is to capture the commuters' current context by augmenting the apparatus, systemlframework and methodologies proposed by the present invention in order to enable the commuter to make l5 -some online booking!reservation and purchasing of required goods and * services. These can be possible using new mobile payment techniques such as a mobile-wallet or credit-cards or m-paythent. The apparatus, systemlframework and methodologies being proposed by the present invention provide the necessary keypad (either physical or soft), the necessary user interfaces and other functionalities for the commuter to complete an online purchasing/booking/reservation. The same mechanism can be used by the commuter to make the payment for the taxi/cab/taxicab fare together with -a facility to print the receipt.

Accordingly, the objective of the present invention is to propose solutions in the form of apparatus, systemlframework and methodologies in order to capture instantaneous context information pertaining to users on the move, and the same solutions can be augmented to enable the users on the move to make some online purchases and reservations/bookings. Hence, this invention mainly targets the commuters of a taxi/cab/taxicab and hence, each taxi/cab/taxicab is equipped with the solutions proposed by the present invention. The same solutions are still applicable to other modes of public transport facilities such as buses, coaches, trains, ferries, cruises, and the like.

In order to enable the commuters of a taxi/cab/taxicab or other public transport facilities to make online purchases and bookings/reservations, the commuters have to be provided with the information regarding the local goods and services. Hence, according to one embodiment of the present invention, the solutions being proposed by the present invention provides a marketing medium similar to mobile media. This is possible by letting the apparatus/device/equipment being used by the proposed solution of the present invention to have multimedia playback capabilities, maintain constant connectivity with one or plurality of mobile cellular or wireless communication networks and to periodically have location-specific information injected. In this respect, apparatus/device/equipment being used by the proposed solutions of the present invention shall possess namely one or plurality of wireless transceivers together with the Subscriber Identity Module (S1M), Universal Subscriber identity Module (USIM) or similar smartcard, an electronic visual display unit, a speaker and associated hardware/software functionalities (e.g., video card, sound card, codec) to process and playback multimedia contents.

In order to provide information regarding location-specific goods and services of a given region that are of particular interest to any commuter, it is important to capture the current context of the given commuter. This context information is non-exhaustive and includes namely the instantaneous geographical position information, intention, gender and the like of one or plurality of commuters. On getting to know the current context of a given commuter or a group of commuters, the solutions proposed by the present * invention will subsequently provide information regarding the goods and S services that are specific to the current context.

According to one embodiment, the context includes only the instantaneous geographical position information of a given commuter. The location information pertaining to one or plurality of commuters can be obtained either by using the mobile/wireless communication network or by using the Global Positioning System (GPS). For this purpose the apparatus/device/equipment being used by the proposed solution is equipped with GPS receiver circuitry and/or a separate transceiver to maintain constant connectivity with any mobilelwireless communication network.

In addition, if the apparatus/device/equipment being used by the proposed solution is equipped with voice recognition facility (e.g., lingo), it is possible to get other context information pertaining to one or plurality of commuters such as the user intention and even the gender. For instance, if a commuter happens to mention anything related to dining at any local restaurant/pub (e.g., hungry, thirsty, pint of beer and the like), the voice recognition facility of the apparatus/device/equipment being used by the proposed solution can pick them up and coordinate with any centralised context-aware advertisement/marketing mechanism to be injected relevant advertisements to be played back on the electronic visual display of the apparatus/device/ equipment being used by the proposed solution.

A typical example of context-aware advertisement is location-based advertisement (LBA). Although the present invention does not deal with exactly how this LBA works, the apparatus/device/equipment being used by the proposed solutions of the present invention is made capable enough to support context-aware or location-based advertising/marketing. In this respect, for the purpose of completeness, a small description of LBA is provided.

As mentioned before, the apparatus/device/equipment being used by the proposed solution of the present invention provides a marketing media similar to that of personal mobile phones (i.e., mobile media). Given that mobile is an interactive mass media similar to the Internet, advertisers are very keen to make much out of its viral effect. Despite this, revenues are still a small fraction of the advertising industry as a whole mainly because blind mobile advertisement does not bring in the intended benefit; instead it annoys customers. This applies to LBA which is a subset of mobile advertising.

The location-based advertising has the potential to enable advertising agencies or marketers to send advertisements related to products and services to consumers based on their proximity to places where the marketers products are available. There are three main key benefits of context-based advertisement (CBA) or location-based advertisement (LI3A) techniques which are immediate reach, very relevant, and quick result.

Despite the potential powers of mobile advertising and LBAJCBA in particular, not everybody is interested to receive annoying advertisements or to subscribe to any marketers' LBA/CBA program, because of privacy, security and spam concerns. As a result, majority of consumers are still mainly concerned about their privacy and risk of being monitored without being aware of it. Because of this, mobile advertising using mobile handsets has not realised/attained its full potential.

Considering the deficiency of the current mobile advertisement mechanisms, according to one embodiment of the present invention, the apparatus/device! equipment being used by the proposed solution of the present invention is augmented to provide a different type of mobile media that does not have the / I same seriousness of spam, privacy and security concerns. This is because the apparatus/device/equipment being used by the proposed solution of the present invention is not specific to any user; instead, it is specific to one mode of public transport facility such as a taxi/cab/taxicab, bus, coach, train, ferry, cruise, and the like. As a result, with an advent or the introduction of the apparatus/device/equipment being used by the proposed solution, the consumer privacy and spam issues can be completely or significantly alleviated and new paradigm of CBAILBA is brought in.

The circumstances and the context in which the apparatus/device/equipment being used by the proposed solution of the present invention will be used in reality are different from the ways in which the existing user handheld devices are used for LBA/CBA purposes. The multi-billion pounds worth advertising industry is really in need of this type of apparatus/device/equipment being used by the proposed solution of the present invention as who is walking around the town staring at their phone or willing to receive unwanted advertisements at his/her own expense. Even if consumers do, the establishment of well engineered consumer privacy and preference management policy is critical to the long-term success of LBA/CBA.

For easy identification, the apparatus/device/equipment being used by the proposed solution of the present invention is called iCab. In its basic configuration, iCab is equipped with a geographical position capturing mechanism and possesses a communication interface to maintain intermittent connectivity with a centralised server (and the associated repository) possibly via the Internet and one or plurality of electronic/soft buttons/keys. According to one embodiment of the present invention, this basic functionality of iCab device will allow any taxi/cab/taxjcaboer to advertise the availability of his/her taxi/cab/taxicab for a hirelrjde on a centraljsed server (and the associated repository) with the current location information with a click of a buttonfkey. This allows any prospective commuter who is in search of a taxi/cab/taxicab to easily find a taxi/cab/taxicab in a particular location automatically without having any hassle by interrogating with the same server (and the associated repository) perhaps using a mobile handset. Further, if the mobile handset has navigation capabilities, the person who is after a taxi/cab/taxicab will be automatically provided with the location information pertaining to one or plurality of the desired taxis/cabs/taxicabs, getting directed to the nearest place where he/she can find the desired taxi/cab/taxicab satisfying the prospective commuter's search criterialrequirements (such as having leather seat, entertainlnenhlwiFi/Intefl1et/ajrcoflditjofliflg facilities and the like).

* According to another embodiment of the present invention, iCab is equipped with a geographical position capturing mechanism whereby the client * application that runs on such a device periodically calculates its speed/velocity and notifies the current speed/velocity information along with the current geographical coordinates to a centralised server (and the associated repository). The server application that runs in the centralised server will receive such speed/velocity updates from every iCab device and determines the mean average velocity information of a given road, street, highway and the like at any moment. This arrangement would allow any prospective user of a road, street, high-way and the like to determine the traffic/congestion information of a given road by interrogating with the same centralised server (and the associated repository).

According to another embodiment of the present invention, if the iCab device is equipped with multimedia processing/rendering capability, it can provide marketing media targeting commuters/passengers of taxies, buses, coaches, trains, and other ground and sea/river/water transport facilities such as ferries, ships and cruises to spend their travel time enjoyably and informatively while maximising the advertisement revenue in mobile media. The present invention, however, is not concerned with mobile marketing or mobile advertisement. Instead, it only mentions that the iCab device can provide a potentially attractive mobile marketing/advertising medium.

According to another embodiment, if the iCab device maintains connectivity to any PLMN and/or to the Internet and has the necessary hardware/software capabilities, an iCab device can be used by a commuter to make PLMNIVoIP calls, get access to one or plurality of social networking sites (SNSs) such as Facebook, MySpace, Linkedln and the like, play online games, interact with friends via instantaneous messaging applications and the like. Subsequently, the commuter can be charged depending on the services being used, time of the day, service-duration and the like. The same iCab device can be used to display the instantaneous taxi/cab/taxicab-fare and rint receipts.

Disclosure of the Invention

According to the first aspect of the present invention there is provided an electronic device of first type to capture context information pertaining to one mode of public transport facility and/or the commuters that travel therein, and the said electronic device of first type comprising: i) a wireless transceiver providing a communication interface of first type; ii) a mechanism to determine the absolute geographical location information of the said electronic device of first type; wherein the said electronic device is part of a context-capturing framework *. that comprises: a) a server that has a profile-repository and other online databases and a server application running continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being -registered successfully; b) acommunjcatjon network which allows the said electronic device of first type to maintain intermittent connectivity with the said server via a communication interface of first type; wherein the said electronic device of first type provides a user interface of first type allowing the user to advertise the current geographical location of the said one mode of public transport facility with the centralised server automatically with a click of a button.

It is preferred that the said electronic device of first type being part of a context-capturing framework, wherein each of the said electronic devices of first type needs to be always physically and logically associated/tied with a given vehicle being used to provide one mode of public transport facility where the said electronic device of first type is going to capture context information.

Preferably the said electronic device of first type being part of a context-capturing framework, wherein the physical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by physically mounting the said electronic device of first type at the appropriate place in the given vehicle.

It is preferred that the said electronic device of first type being part of a context-capturing framework, wherein the logical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by creating and activating a unique profile in the said profile-repository of the said centralised server and the said unique profile is specific to a given vehicle and the electronic device of first type.

Preferably the said electronic device of first type being part of a context-capturing framework comprises a device-specific unique identifier (i.e., device-ID) that is globally unique being assigned at the time of manufacturing, wherein the said device-specific unique identifier is written on the exterior side of the said electronic device of first type for the user to use it at the time of logical association, It is preferred that the said electronic device of first type being part of a 10* context-capturing framework, wherein the ownerldriver of the public transport facility is expected to create, maintain and activate an on-line profile per vehicle being used for public transport in the said profile-repository of the said server of the said context-capturing framework, wherein the profile can be created using any personal computer that can connect to the said server via the Intemet on typing the correct URL of the said server and the user is expected to give unique information pertaining to a given vehicle and the electronic device of first type pair.

* Preferably the said electronic device of first type being part of a context-capturing framework, wherein every profile being maintained in the said centralised profile-repository will keep public transport vehicle specific çletails such as the vehicle registration number, country of registration, current absolute geographical location. current timestamp, colour of the vehicle, usual fare per distance, availability status for a hire/ride, contact number, device-specific unique identifier pertaining to the said electronic device of first type being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like, and this profile creation process requires the owner of the public transport to create login credentials namely the preferred user name/password that are specific to one vehicle and hence to one electronic device of first type.

It is preferred that the said electronic device of first type being part of a context-capturing framework, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creationlmaintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.

Preferably the said electronic device of first type being part of a context-capturing framework runs a client application and the electronic device of first type possesses green LED and red LED on the exterior side, wherein the said client application will automatically contact the said centralised server when the said electronic device of first type is powered on, and the LED indicators on the device will indicate the registration status of the given electronic device of first type depending on whether a corresponding profile already exists or not in the said profile-repository being maintained in the said centralised server such that: a) an automatic powering on of the said green LED indicating that the said client application has already found a corresponding entry in the said profile-repository and the given electronic device of first type is ready to operate; or, b) an automatic powering on of the said red LED indicating that no corresponding entry exist centrally; wherein the device-specific unique identifier of the said electronic device of first type is passed on to the server application by the said client application for the said server appliàation to search the profile-repository using the said device-specific unique identifier as the index. l0

It is preferred that the said electronic device of first type being part of a context-capturing framework runs a client application, wherein on seeing that a corresponding entry exists in the said profile-repository of the said centralised server, the said client application will maintain connectivity with the server application running on the centralised server via the communication interface of first type for the purpose of periodically advertising the avai1ability1unavajJajjv status of a given niode of public transport facility along with the instantaneous location information when prompted by the user.

Preferably the said electronic device of first type being part of a context-capturing framework, wherein the mechanism to determine the absolute geographical location information of the electronic device of first type is any of the prevailing state of the art technologies such as Global Positioning System (GPS) and other mobile/wireless network assisted positioning, wherein the said electronic device of first type comprising a GPS receiver or any wireless transceiver.

It is preferred that the said electronic device of first type being part of a context-capturing framework, wherein the said communication network that allows the said electronic device of first type to maintain intermittent connectivity with the said server can be WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like, and the associated communication interface of first type is the main air interface of the WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like respectively.

It is preferred that the said electronic device of first type being part of a context-capturing framework, wherein the user interface of first type has only two electronic/soft buttons/keys having the following features: i) one green button/key known as the "availability" button; and, ii) one red buttonlkey known as the "unavailability" button.

Preferably the said electronic device of first type being part of a context-capturing framework, wherein the said one mode of public transport facility is taxi/cab/taxicab service, wherein the taxi/cab/taxicab owner/driver can advertise the availability status of the taxi/cab/taxicab for a hire/ride in a given region by performing the advertising procedure comprising the steps of: i) mounting the said electronic device of a first type in the appropriate place of the taxi/cab/taxicab vehicle (i.e., the physical association); ii) creating and maintaining a corresponding profile pertaining to the given taxi/cab/taxicab vehicle and the said electronic device of first type being mounted therein by specifying the taxi/cab/taxicab details as well as the device-specific unique identifier of the electronic device of first type (i.e., the logicalassociation); iii) turning on the electronic device of first type and waiting till the green on the electronic device of first type to be automatically turned on; if not, a corresponding profile needs to be created online and activated; iv) on noticing a green LED being lit on the electronic device of first type, the taxi/cab/taxicab driverlowner pressing the said "availability" button to advertise the availability status of a given taxi/cab/taxicab for a hire/ride; and, v) on recognising that the "availability" button is pressed by the taxi/cab/taxicab owner/driver, the said client application determining the current absolute geographical location of the electronic device of first type by 1iaiing with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said centralised server; wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" for a hire/ride and update the absolute geographical location and the corresponding time stamp.

It is preferred that the said electronic device of first type being part of a context-capturing framework, wherein the said one mode of public transport facility is taxi/cab/taxicab service, wherein the taxi/cab/taxicab owner/driver can advertise the unavailability status of the taxi/cab/taxicab for a hire/ride in a given region by pressing the said "unavailability" buttonlkey of the said electronic device of first type on noticing that the device is ready to be used, wherein on recognising that the "unavailability" button is pressed by the taxi/cab/taxicab owner/driver, the said client application passing the device-specific unique identifier of the said electronic device of first type on to the said centralised server, wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being unavailable" for a hire/ride and update the corresponding time stamp.

Preferably the said electronic device of first type being part of a context-capturing framework enables taxi/cab/taxicab drivers to automatically advertise their availability for a hire/ride along with their geographical positions through the said centralised server, wherein if the said client application can determine that a given taxi/cab/taxicab has been parked in a particular location for more than a given time-limit, then this taxi/cab/taxicab's availability for a hire/ride will be automatically advertised without having to click any button unless the taxi/cab/taxicab owner/driver has already pressed the "unavailability button", wherein the said client application determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said centralised server, wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" for a hire/ride and update the corresponding time stamp.

Preferably the said electronic device of first type being part of a context-capturing framework, wherein the electronic device of first type can also function as a fare meter for a commuter and/or as a toll box for road pricing and/or has a printer functionality to print the receipt out.

It is preferred that the said electronic device of first type being part of a context-capturing framework where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said client application running on the electronic device of first type takes an extra functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said client application to constantly run a timer of first type; ii) when a timeout occurs, getting the client application to calculate the current speed/velocity of the vehicle to which the given electronic device of first type is physically and logically associated with, to determine the current absolute geographical location of the given vehicle by liaising with the said mechanism that determines the absolute geographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of electronic devices of first type, getting the said server application ruiming on the said centralised server to: a) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further traffic/congestion calculation only when the reported speed/velocity pertains to a road, street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d) to calculate the moving average velocity using the received updates from other electronic devices of first type pertaining to the same segment of a given road/street/highway/motorway or the like that are still non-stale and are currently cached in the traffic database; e) to liaise with the traffic database and temporarily cache the calculated moving average velocity in the said traffic database against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced with a new entry or times-out; and, I) getting the said server application to accompany the time stamp with each cached moving average velocity information being stored in the * traffic database; wherein by getting the said client application running on each of said electronic device of first type to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestionltraffic database of a given road, street, highway, motorway and the like.

Preferably the said electronic device of first type being part of a context-capturing framework where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said server application will take an extra functionality to liaise with the said profile-repository and said navigation map with an objective to inject traffic tips to every electronic device of first type that periodically notifies its instantaneous absolute geographical position information in case the calculated moving average velocity is much lower than the speed limit being set to a given segment of a road/street/highway/motorway or the like where a given vehicle carrying a given electronic device of first type is travelling on, wherein on receiving the traffic tips the electronic device of first type will render it depending on its capabilities so that the user/commuter will be informed in advance of a traffic/congestion situation in a given location.

It is preferred that said electronic device of first type being part of a context-capturing framework, wherein the said electronic device of first type takes extra functionalities by possessing a speaker configured to playback any received audio signal, an electronic visual display unit configured to playback any received video signal in an appropriate format, and a set of on-screen or physical keys/buttons to get user inputs in connection with volume control, picture quality control and the like and said server maintains connectivity with a.content database containing variety of multimedia contents; wherein the said extra functionalities comprising i) each electronic device of first type periodically updating the said centralised server with an absolute geographical location along with the device-specific unique identifier unless it actively gets involved in the traffic judging procedure periodically updating the said server with the said three-tuple information; ii) the said server application liaising with the said content database to regularly push one or plurality of multimedia contents to each electronic device of first type depending on its instantaneous geographical location; and, iii) once received, each electronic device of first type rendering or playing back the multimedia content.

Preferably the said electronic device of first type being part of a context-capturing framework, wherein the said electronic device of first type takes extra functionalities by possessing a credit-card or mobile-wallet or m-payment reader in order to support online purchases/reservations of goods and services by one or plurality of commuters of the said public transport facility.

According to the Second aspect of the present invention there is provided a context capturing electronic system on a chip potentially forminglrealising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, where an electronic device of first type is mounted on the said one mode of public transport facility, and the system on a chip comprising: i) a bus, ii) a peripheral controller being coupled to said bus for connecting one or plurality of I/O peripheral devices depending on the requirements; iii) one or plurality of microprocessors being coupled to said bus to provide control functions to the said electronic device of first type; iv) a communication controller being coupled to said bus for connecting to one or plurality of communication interfaces; v) a memory that is coupled to said bus into which a plurality of instructions are loaded; and, vi) a mechanism to determine the absolute geographical location information of the said electronic device of first type; wherein the said electronic device is part of a context-capturing framework that comprises: a) a server that has a profile-repository and other online databases and a server application running continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being registered successfully; b) a communication network which allows the said electronic device of first type to maintain intermittent connectivity with the said server via a communication interface of first type; wherein using a user interface of first type being provided by the said electronic device of first type the said system on chip allowing the user to advertise his/her current geographical location with the centralised server automatically with a click of a button.

It is preferred that the said context capturing electronic system on a chip potentially formirig/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein each of the said electronic devices of first type needs to be always physically and logically associated/tied with a given vehicle being used to provide one mode of public transport facility where the said electronic device of first type is going to capture context information.

Preferably the said context capturing electronic system on a chip potentially forminglrealising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode ofpublic transport facility and/or the commuters that travel therein, wherein the physical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by physically mounting the said electronic device of first type at the appropriate place in the given vehicle.

It is preferred that the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the logical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by creating and activating a unique profile in the said profile-repository of the said centralised server and the said unique profile is specific to a given vehicle and the electronic device of first type.

Preferably the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the said electronic device of first type comprises a device-specific unique identifier (i.e., device-ID) that is globally unique being assigned at the time of manufacturing for the user to use it at the time of logical association.

It is preferred that the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the owner/driver of the public transport facility is expected to create, maintain and activate an on-line profile per vehicle being used for public transport in the said profilç-repo.sitory of the said server of the said context-capturing framework, wherein the profile can be created using any personal computer that can connect to the said server via the Internet on typing the correct URL of the said server and the user is expected to give, unique information pertaining to a given vehicle and the electronic device of first type pair.

Preferably the said context capturing electronic system on a chip potentially forminglrealising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein every profile being maintained in the said centralised profile-repository will keep public transport vehicle specific details such as the vehicle registration number, country of registration, current absolute geographical location, current timestamp, colour of the vehicle, usual fare per distance, availability status for a hire/ride, contact number, device-specific unique identifier pertaining to the said electronic device of first type being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like, and this profile creation process requires the owner of. the public transport to create login credentials namely the preferred user name/password that are specific to one vehicle and hence to one electronic device of first type.

Tt is preferred that the said, context capturing electronic system,on a chip * pQtentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility andlor the commuters that travel therein, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creation! maintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.

Preferably the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor containing the software stack, wherein the said software stack comprising functionalities for: i) connection management enabling the establishment of connection with the said server application; ii) traffic condition calculation and reporting; iii) public transport facility availability reporting/advertisement; iv) other miscellaneous functionalities pertaining to displaying fare information, session management, multimedia rendering and the like; v) application layer and a variety of multimedia applications; It is preferred that the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor containing the software stack and the electronic device of first type possesses green LED and red LED on the exterior side being connected to, the, said peripheral controller, wherein the said connection management 5. functionality of the said software stack will automatically contact the said centralised server when the said electronic device of first type is powered on, an LED indicator on the device will indicate the registration status depending on whether a corresponding profile already exists or not in the said profile-repository being maintained in the said centralised server such that: a) an, automatic powering on of the said green LED indicating that one or - more functionalities of the said software stack have already found a corresponding entry in the said profile-repository and the given electronic device of first type is ready to operate; or, b) an automatic powering on of the said red LED indicating that no corresponding entry exist centrally; wherein the device-specific unique identifier of the said electronic device of first type is passed on to the server application for the said server application tosearch theprofile-repository using the said device-specific unique identifier -a's the index. 20.

It is preferred that the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for'the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor containing the software stack, wherein on seeing that a corresponding entry exists in the said repository of the said centralised server, one or more functionalities of the said software stack will maintain connectivity with the server application running on the centralised server via the communication interface of first type for the purpose of periodically advertising the availability/unavailability status of a given mode of public transport facility along with the instantaneous location information when prompted by the user.

Preferably the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the mechanism to determine the absolute geographical location information of the electronic device of first type is any prevailing state of the art technologies such as Global Positioning System (GPS) and/or other mobile/wireless network assisted positioning, wherein the said electronic device of first type comprising a GPS receiver or any wireless transceiver being connected via the said communication controller.

It is preferred that the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the user interface of first type has only two electronic buttons/keys being connected via the said peripheral controller having the following features: i) one green buttonlkey known as the "availability" button; and, ii) one red button/key known as the "unavailability" button.

Preferably the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the said one mode of public transport facility is taxi/cab/taxicab service, wherein the said software stack of the said electronic system on a chip runs a public transport availability advertisement procedure allowing the taxi/cab/taxicab owner/driver to advertise the availability status of the taxi/cab/taxicab for a hire/ride in a given region and the said advertising procedure comprising the steps of: i) automatically connecting to the said centralised server and checking whether a corresponding entry exists in the said profile-repository using the * device-specific unique identifier as the index; * ii) on having found a corresponding entry in the said profile-repository, turning on the green LED of the said electronic device of first type; otherwise turning on the red LED to indicate to the taxi/cab/taxicab owner/driver that a corresponding profile needs to be created in the said profile-repository; iii) beginning to listen to user inputs; iv) on recognising that the "availability" or "unavailability" button is pressed by the taxi/cab/taxicab owner/driver, determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said centralised server; wherein on being notified, the said server application of the said centralised server will look for a corresponding entry in the said repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" or "being unavailable" for a hire/ride respectively depending on the type of button pressed by the taxi/cab/taxicab owner/driver and update the absolute geographical location and the corresponding time stamp.

It is preferred that the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said software stack of the said electronic system on a chip takes an extra traffic condition reporting frmnctionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said traffic condition reporting fttnctionality of the said software stack to constantly run a timer of first type; ii) when a timeout occurs, getting the said traffic condition reporting functionality of the said software stack to calculaie the current speed/velocity of the vehicle to which the given electronic device of first type is physically and logically associated with, to determine the current absolute location of the given vehicle by liaising with the said mechanism that determines the absolute geographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographica' location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of electronic devices of first type, getting the said server application running on the saidcentralised server to: a) first check whether the reported speed/velocity pertains to a road, Street, ,highway or the like, and to consider it for further traffic/congestion, calculation only when the reported speed/velocity pertains to a road. street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d) to calculate the moving average velocity using the received updates from other electronic devices of first type pertaining to the same segment of a given road/street/highway/motorway or the like that are still non-stale and are currently cached in the traffic database; e) to liaise with the traffic database and temporarily cache the calculated moving average velocity in the said traffic database against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced with a new entry or times-out; and, getting the said server application to accompany the time stamp with each cached moving average velocity information being stored in the traffic database; wherein the said software stack of the said electronic system on a chip running the said traffic condition reporting procedure to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestionltraffic database of a given road, street, highway, motorway and the like.

It is preferred that the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the said electronic system on a chip takes extra functionalities by possessing a number of peripheral devices being connected via the said peripheral controller to the. said bus, and the said peripheral devices comprise a speaker configured to playback any received audio signal, an electronic visual display unit configured to playback any received video signal in an appropriate format, and a set of on-screen or physical keys/buttons to get user inputs in connection with volume control, picture quality control and the like and said server maintains connectivity a content database containing variety of multimedia contents; wherein the said extra functionalities comprising: i) each electronic device of first type periodically updating the said centralised serier with context information pertaining to one mode of public transport facility and/or the commuters that travel therein; ii) the said server application liaising with the said content database to regularly push one or plurality of multimedia contents to. each electronic device Of first type depending on its instantaneous context information; and, iii) once received, each electronic device of first type rendering or playing back the multimedia content.

Preferably the said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, wherein the said electronic system on a chip takes extra functionalities by possessing a number of peripheral devices being connected via the said peripheral controller to the said bus, and the said peripheral devices comprise a credit-card or mobile-wallet or rn-payment reader in order to support online purchases/reservations of goods and services.

According to the third aspect of the present invention there is provided a method for transforming an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities namely: i) a wireless transceiver providing a communication interface of first type; ii) an electronic visual display unit that can provide the required graphical user interface; iii) a mechanism to determine the absolute geographical location information of the said existing mobile phone, srnartphone or similar electronic device; through a purpose-built software running on the said mobile phone, smart-phone or similar electronic device in order to enable them to be part of a context-capturing framework in the capacity of context-reporting mobile clients and the said context-capturing framework comprising: a) a server that has a profile-repository and other online databases and a server application rurming continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being registered successfully; b) a communication network which allows the said existing mobile phone, smartphone or similar electronic device to maintain intermittent connectivity with the said server via a communication interface of first type; wherein forming a context-capturing framework in order to capture the required context information pertaining to one mode of public transport facility and/or the commuters that travel therein has a preset setup procedure/methodology comprising the steps of 1) the driver(owner of a given vehicle being used to provide one mode of public transport facility physically associating the said existing mobile phone, smartphone or similar electronic device with the said vehicle by mounting at the appropriate place of the said vehicle; ii) the driver/owner creating and maintaining a corresponding profile pertaining to the given taxi vehicle by specifying the taxi details with the * centralised server using a personal computer and the world wide web; iii) on the driver/owner successfully activating a vehicle-specific profile in the * 20 cntra1ised server, the said server creating login credentials and assigning a unique alphanumeric identifier to the registered vehicle; * * iv the driver/owner turning the physically associated existing mobile phone, smartphone or similar electronic device on and logically associating it with the given taxi vehicle by signing on with the said centralised server using the login credentials and the said server assigned unique alphanumeric identifier by getting the said purpose built software running on the said existing mobile phone, smartphone or similar electronic device to provide the necessary graphical user interface; v) on signing on, the purpose-built software running on the said existing mobile phone, smartphone or similar electronic device contacting the centralised server and locating the maintained profile using the said server generated unique alphanumeric identifier; vi) on successfully locating a corresponding profile with the centralised server, the said purpose-built software displaying that the said existing mobile phone, smartphone or similar electronic device is ready for it to be used as part of the said context-capturing framework on the graphical user interface, while activating two keys -one for advertising the availability of a given vehicle for a hire/ride and the other for advertising the unavailability of the given vehicle for a hire/ride; vii) on recognising that the "availability"/"unavailability" button is pressed by the taxi owner/driver, the said purpose-built software determining the current absolute geographical location of the said existing mobile phone, smartphone or similar electronic device by liaising with the said mechanism that determines the location and passing the determined location information on to the said centralised server along with the said server assigned unique alphanumeric identifier; wherein on being notified, the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the said server assigned unique alphanumeric identifier* as the index and on being found, the server application will change the taxi availability status to "being available" or "being unavailable" for a hire/ride depending on the type of key being pressed and update the absolute geographical location and the corresponding time stamp.

It is preferred that the said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework, vherein every profile being maintained in the said centralised profile-repository will keep public transport vehicle specific details such as the vehicle registration nuniber, country of registration, current absolute geographical location, current timestamp, colour of the vehicle, availability status for a hire/ride, usual fare per distance, contact number, server assigned unique alphanumeric identifier pertaining to the said existing mobile phone, smartphone or similar electronic device being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like.

Preferably the said method enabling an existing mobile phone, smartphone or similar electronic *device having the necessary hardware/software -functionalities to be part of a context-capturing framework, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creationlmaintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.

It is preferred that the said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework, wherein the said existing mobile phone, smartphone or similar electronic device uses GPS to determine the absolute geographical location.

Preferably the said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework, wherein the said communication network that allows the said existing mobile phone, smartphone or similar electronic device to maintain intermittent connectivity with the said server can be WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like, and the associated communication interface of first type is the main air interface of the WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like respectively.

It is preferred that the said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said purpose-built software running on the said existing mobile phone, smartphone or similar electronic device takes an extra functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said purpose-built software rumñng on the said existing mobile phone, smartphone or similar electronic device to constantly run a timer of first type; ii) when a timeout occurs, getting the said purpose-built software to calculate the current speed/velocity of the vehicle to which the said existing mobile phone, smartphone or similar electronic device is physically and logically associated with, to determine the current absolute geographical location of the given vehicle by liaising with the said mechanism that determines the absolute geographical location and to update the said centralised server with a three- * tuple information consisting of speedlvelocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of said existing mobile phones, smartphones or similar electronic devices, getting the said server application running on the said centralised server to: a) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further traffic/congestion calculation only when thereported speed/velocity pertains to a road, street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d) to calculate the moving average velocity using the received updates from one or plurality of said existing mobile phones, smartphones or similar electronic devices pertaining to the same segment of a given road/street/highway/motorway or the like that are still non-stale and are currently cached in the traffic database; e) to liaise with the traffic database and temporarily cache the calculated moving average velocity in the said traffic database against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced with a new entry or times-out; and, f) getting the said server application to accompany the time stamp with each cached moving average velocity information being stored in the traffic database; wherein by getting the said purpose-built software to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestionltraffic database of a given road, street, highway, motorway and the like.

Description of the Drawings

Non-limited and non-exhaustive embodiments are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

For a better understanding of the preseni invention, reference will be made to 5 the following detailed description of the invention, which is to be read in association with the accompanying drawings, wherein: Figure 1 is an illustrative front view of the electronic device of first type in its basic configuration that may be used for the purpose of capturing context information pertaining to one mode of public transport facility andtor the commuters that travel therein according to various embodiments of the present invention.

Figure 2 is an illustrative communication and computing network environment forming the basic context-capturing framework where various embodiments of the present invention are said to work. is

Figure 3 is an illustration of the various functionalities of the Server Application running on the centralised server of basic context-capturing framework according to an embodiment of the present invention.

Figure 4 illustrates one exemplary online form to be used by the owner/driver of one mode of public transport vehicle for the purpose of creating a centralised vehicle-specific profile according to an embodiment of the present invention.

Figure 5 exemplarily shows the contents of profile-repository being maintained by the said centralised server that keeps vehicle-specific profiles according to an embodiment of the present invention Figure 6 is an exemplary schematic block diagram illustrating the internal components of an electronic device of first type having multi-functional features and operating on a Reduced Instruction Set Computer (RISC) microprocessor for it to be used for the purpose of capturing context pertaining to users on the move, providing information related to goods and services based on the captured context and providing the users on the move with communication, entertainment and point-of-sale capabilities according to various embodiments of the present invention.

Figure 7 is an exemplary illustration of the various components of the software stack of a RISC microprocessor according to one another embodiment of the present invention.

Figure 8 illustrates one exemplified view of the graphical user interface provided by the purpose-built client software running on the context-seeking mobile device that is used to run a search looking for an availability of one or more public transport vehicle in the neighbourhood of the prospective commuter according to one another embodiment of the present invention, Figure 9A illustrates setup methodology/procedure for transforming an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities in order to capture the required context information pertaining to one mode of public transport facility andlor the commuters that travel therein according to one another embodiment of the present invention, Figure 9B illustrates one exemplary login window used for the purpose of letting a owner!driver of a vehicle being used to provide one mode of public transport facility to logically associate an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software capabilities with the given vehicle by signing on with the said centralised server using the login credentials and the said server assigned unique alphanumeric identifier according to an embodiment of the present invention.

Figure 10 illustrates the operations when the methodology/procedure that enables an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software capabilities or even an electronic device first type to be part of a context-capturing framework extends the capabilities of these devices for the purpose of judging the traffic/congestion situation of a given location.

Figure 11 illustrates as to how the regular velocity or speed updates by every context-reporting mobile client device will allow the traffic/congestion judgement functionality of the server application to maintain a traffic conditionlsituation database that allows anybody to get the traffic information of a given location.

Figure 12A exemplarily depicts the exterior view of the enhanced version of an electronic device of first type in terms of the extra functionalities it is expected to handle in addition to capturing context information pertaining to one mode of public transport facility and the commuters travel therein according to an embodiment of the present invention.

Fig. 12B depicts the special keypad being used to operate the enhanced version of the electronic device of first type in the intended way according to an embodiment of the present invention.

Figure 13 illustrates the various operations the enhanced version of the electronic device of first type is capable of performing according to an embodiment of the present invention.

Description of Specific Embodiments

The present invention will now be described in a more elaborative manner hereinafter with reference to the accompanying figures, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practised. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

This invention introduces a new context capturing device called iCab, systemlframework and methodology that captures the context pertaining to one mode of public transport facility and/or commuters travelling therein.

According to one embodiment of the present invention, the new context capturing device called iCab, system/framework and methodology allows any owner/driver of one mode of public transport facility such as a taxi/cab/taxicab, bus, coach, ferry and the like to advertise their availability/unavailability for a hire/ride through a centralised system/framework so that any prospective commuter can automatically identil' and get directed to the nearest available taxi/cab/taxicab, bus, coach, ferry and similar public transport facility. This is possible by getting the prospective commuter to send his/her absolute location using SMS/MMS/tweets to the driver/owner of a taxilcabltaxicab or similar public transport facility and getting the latter to navigate to the former's location without any difficulty.

Fig. 1 depicts an exemplary external view of the new electronic device of first type 100 (which is known as iCab device throughout this document) that * enables the owner/driver of a taxi/cab/taxicab or similar public transport taclilty to advertise the availability/unavailability status of a given mode of public transport (i.e., taxi/cab/taxicab or the like) for a hire/ride via a centralised systemlframework. This electronic device of first type 100 needs to be first mounted in the appropriate place of the vehicle being used for providing the public transport facility. Once mounted, the electronic device of first type 100 needs to be registered with the centralised server before being used as it will be described later. The physical mounting and the online registration binds/ties a given electronic device of first type 100 withlto a given vehicle being used to provide one mode of public transport facility.

Although the electronic device of first type is described in the context of taxi/cab/taxicab service, its usage is equally applicable to other modes of public transport facilities. Further, a term vehicle is used here onwards for the purpose of commonly referring to any vehicle being used to provide any mode of public transport facility.

As said before, each of the said electronic devices of first type 100 needs to be always physically and logically associated/tied with a given vehicle being used to provide one mode of public transport facility where the said electronic device of first type 100 is going to capture context information. The physical association between one of the said electronic devices of first type 100 and a given vehicle takes place by physically mounting the said electronic device of first type 100 at the appropriate place in the given vehicle. On the other hand, the logical association between one of the said electronic devices of first type and a given vehicle takes place by creating and activating a unique profile in the said profile-repository 260 of the said centralised server 222 and the said unique profile is specific to a given vehicle and the electronic device of first type 100, The electronic device of first type 100 has a power-on switch 120. Preferably this power-on switch 120 can be electronic, soft or embedded on to a touch-screen, although the possibility for it to be mechanical is not ruled out. In its normal usage, the electronic device of first type 100 will get the absolute physical geographical location of the vehicle where it is mounted on and pass it on to the centralised server when prompted by the is user, Given that the electronic device of first type 100 is expected to get the absolute geographical location of itself, it uses state-of-the art positioning services like a Global Positioning Service (GPS), mobile network assisted positioning service or similar services. If it is GPS equipped, the electronic device of first type 100 should have a GPS receiver 130. On the other hand, in case the electronic device of first type 100 uses mobile/wireless network assisted positioning, it should possess a corresponding transceiver 160.

Given that the electronic device of first type 100 is expected to maintain iitermittent connectivity with an external centralised server 222 (as it will be described later) for the purpose of passing the captured geographical positioning iflformation on to the said server 222, it needs to have a wireless/mobile transceiver 160. Depending on the type of wireless/mobile communication network used, the transceiver should support GPRS, WIFi *1, (IEEE 802.11), WiMAX (IEEE 802.16/IEEE 802.20), 3G/UMTS, 4G or the like. The electronic device of first type 100 possesses a red LED 140 and a green LED 150 on the exterior side. The green LED 150 is will be lit up only when the electronic device of first type 100 is ready to be used for capturing the context. On the other hand, the automatic lighting up of the red LED 140 will indicate that the given electronic device of first type 100 is not ready to be used. With the short pressing of the "unavailability" buttonlkey 110 and "availability" buttoii 170, the owner/driver of any taxi/cab/taxicab can advertise the unavailability and availability status of his/her taxi for a hire/ride respectively through a centralised systemlframework.

Fig. 2 is an illustrative communication and computing network environment forming the context-capturing framework 200 where various preferred embodiments of the present invention are said to work. As it can be seen clearly, the electronic device of first type 100 is part of the context-capturing framework. In this context-capturing framework 200, the electronic device of first type 100 operates in the capacity of context-reporting mobile client or a context-information seeking mobile client seeking potential context information. In addition, according to one embodiment of the present invention an existing mobile phone, smartphone, PDA or similar device 208 becomes part of the context-capturing framework 200 by transforming these devices to function as context-reporting mobile client device through running purpose-built software. Accordingly, the context-capturing framework 200 comprises one or plurality of context-reporting mobile clients/devices that include the said electronic device of first type 100 and existing mobile phones, PDAs, smartphones that got transformed to function this way through software solutions. In other words, the term context-reporting mobile client/device refers to either a purpose-built electronic device of first type 100 or an existing mobile phone, PDA, smartphone or similar device 208 that takes the context-reporting functionality through appropriate software solutions.

Throughout this document, the mobile client device that is used in the capacity to collect local context information and report it to the centralised server 222 is referred to as context-reporting mobile client/device and it includes both the electronic device of first type 100 and an existing mobile phone, PDA, smartphone or similar device 208 that takes the context-reporting functionality through appropriate software solutions. On the other hand, a mobile client device that is purely used to seek/get context- information from the centralised server 222 is referred to as context-information seeking mobile client device and this is shown by 204 in Fig. 2.

The context-information seeking mobile client device 204 runs purpose-built client software 206 in order to seamlessly contact the server application 224 and get the required context information.

The context-capturing framework 200 further includes at least one mobile andlor wireless base-station (or access-point) 218 which is connected to the converged conventional PLMTh4 and data network 220 and provides ubiquitous connection for an electronic device of first type 100 to intermittently interact with the centralised server 222.

The mobile and/or wireless base-station 218 can belong to one of various wireless communication networks such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA) and CDMA2000. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. CDMA2000 covers IS-2000, IS-95 and IS-856 standards.

A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM) and General Packet Radio Service (GPRS). An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.1 1 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM.

A nomadic or fixed personal computer 212 such as a laptop, netbook, notebook and/or the like interacts with the same centralised server 222 via an Internet cloud 220 for the purpose of allowing anybody to create/edit, activate, and maintain any vehicle-specific profile in a centralised way for various embodiments to work as it will be explained later. As said before, creation and activation of a vehicle-specific profile will logically bind a given vehicle to a given electronic device of first type 100. The mobile/wireless base-station/access-point 218 enables the electronic device of first type 100 to maintain intermittent connectivity with the centralised server 222 via the Internet cloud 220.

In its basic configuration of the context-capturing framework 200 according to one embodiment of the present invention, the centralised server 222 has a profile-repository 260 and a server application 224 running continuously, and the, said profile-repository 260 maintains profile information pertaining to every public transport vehicle (e.g., taxi, cab, taxicab or the like) being registered successfully. As part of the profile creation, the owner/driver of the vehicle needs to get an electronic device of first type 100 and associate it with a given vehicle as it will be explained later. This basic arrangement will allow the ownerldriver of a taxi/cab/taxicab or any other mode of public transport to advertise the availability/unavailability of the vehicle for a hire/ride with the short-pressing of "availability" key 170 or "unavailability" button 110 respectively. As it will be explained later, when the "availability" key 170 or "unavailability" button 110 is pressed, the electronic device of first type 100 will automatically contact the server application 224 running on the centralised server 222 to make the necessary alteration to the vehicle-specific profile being maintained in the profile-repository 260 to reflect the availability/unavailability status of the vehicle for a hire/ride. This set of information/details that allows any electronic device of first type 100 to automatically contact the centralised server 222 is hardwired or statically altered at the time of manufacture or at the discretion of the distributer of the electronic device of first type 100 respectively.

The server 222 runs its own server application 224 having multiple functionalities as shown in Fig. 3 and communicates with a number of online databases depending on its functionalities. In its basic functionality, the server application 224 is responsible for maintaining vehicle-specific profile being stored in the profile-repository 260. If extra functionalities are expected as it will be described as part of various other embodiments of the present invention, the server 222 and hence the server application 224 will also maintain connectivity with "Authentication, Authorization and Accounting" (AAA) related database 240, content database 250 consisting of advertisement, entertaining multimedia, e-newpapers, e-magazines contents, weather reports, news and local information and/or URLs to locate these contents from elsewhere, and navigation map/database 290. in case the context-capturing framework 200 is involved in judging the traffic/congestion situation of a given region, the server 222 will have a traffic database 292.

The server 222 is generally a combination of hardware and software, the software including an operating system which is of different flavours of Windows, Linux, Android and the like. Also, the server application 224 can be written according to a number of different known programming languages, technologies, and/or a combination thereof The server application 224 comprises a multitude of functionalities as shown in Fig. 3. However, according to one embodiment of the present invention, its main functionafjtjes include maintaining a context server (collecting, processing and making context information ready for use referred to as context server functionality 310) and taking care of online profile maintenance related services 320 to a vehicle being used to provide one mode of public transport facility. The functionality that is required for maintaining a context server is referred to as context-server functionality 310. For authentication, authorization and accounting (AAA) purposes as part of the profile creation, the server application may maintain constant connectivity with an AAA database 240. Hence, the server application includes AAA functionaljtjes as well 330. An enhanced version of AAA functionalitjes will be used when the server application 224 allows any user to use the credit-card, rn-payment, mobile-wallet reader of an enhanced version of the 15. electronic device of first type 100 as it will be described later.

The context-server functionality 310 of the server application 224 can offer to the end user benefits such as greater responsiveness, flexibility, adaptability and customisability. A user's context can be quite rich consisting of attributes such as physical location, user-intent, physiological state (e.g. body temperature and. heart-rate), emotional state (e.g. angry, distraught, or calm), personal history,. daily behavioural patterns and the like. In other words, context-awareness can be defined as the knowledge about the user's and device's state, including surroundings, situation, and locations. Hence, ideally the context-capturing framework 200 has to capture any user's full context.

However, given that the present invention deals with an issue of capturing context information pertaining to users on the move by empowering the electronic devices of first type 100, the context-capturing framework 200 gathers location, traffic/congestion information, user-intent of those particular class of users. For this purpose, the context-server functionality 310 of the server application 224 according to one embodiment of the present invention consists of Public transport Availability Prediction functionality 312 which allows capturing the relevant information regarding the availability/ unavailability status of one mode of public transport facility for a ride/hire at a particular instance using the electronic device of first type 100. According to another embodiment of the present invention, the context-server functionality 310 of the server application 224 consists of traffic/congestion judgement algorithm 314 that runs continuously. According to one another embodiment of the present invention, the context-server functionality 310 preferably includes the task of gathering the intention of users that are on the move through automatic voice recognition functionality 318.

According to one another embodiment of the present invention, the electronic device of first type 100 is preferably made multi-functional such that it can receive multimedia content and render the received content in itself. For this purpose, the electronic device of first type 100 would preferably include an electronic visual display unit, speaker and the associated circuitries, and support a multitude of video/audio codec as it will be described later.

The server application may include Pull Service functionality 370 in case it needs to accept various queries pertaining to traffic/congestion information, availability status of different modes of public transport facility (e.g., taxi/cab/taxicab) for a hire/ride in a given location, multimedia entertaining content and the like from any context-information seeking mobile client device 204 such as a mobile handset, smartphone, PDA or similar device as it will be described later, Proxy Server functionality 390 is employed by the server application 222 in order to make sure that when delivering multimedia or entertainment contents, either appropriate formats and codecs or virtual home environment (VHE) type of services are used depending on the hardware and software capabilities of any context-information seeking mobile client device 204 or context-reporting mobile device (i.e., electronic device of first type 100 and/or 208). The server application 224 can also support context-based advertisements being pushed to the multi-functional electronic device of first type 100 as it will be explained later. For this purpose the server application 224 would preferably run context-based advertisement push algorithm 360.

As said before, in order for any owner/driver of any taxi/cab/taxicab or any * mode of public transport facility to advertise the availability/unavailability status of a given vehicle for a hire/ride through a centralised server 222, the latter has to identify the given vehicle. This is where the electronic device of first type 100 is come in to being. The said electronic device of first type 100 is associated/tied with/to a given public transport vehicle after being mounted for the centralised context-capturing framework to know the availability status (for a hire/ride) of a given mode of public transport facility (e.g., taxi,cab, taxicab) constantly. This is possible through both the physical and logical association as explained before.

As part of the logical association, a vehicle-specific profile is created, activated and maintained on the centralised profile-repository 260. This profile includes vehicle-specific information and the details of the electronic device of first type 100 that is physically associated with the vehicle being used to provide one mode of public transport facility. The information of the electronic device of first type 100 that needs to be entered as part of the profile creation of a public transport vehicle is its device-specific unique identifier (i.e., device-ID). The device-specific unique identifier (i.e., device-ID) can preferably be assigned at the time of manufacturing and is an identifier that can be globally unique. The said device-specific unique identifier can be preferably written on the exterior side of the said electronic device of first type 100 for the user to use it at the time of logically associating a given device 100 to a given vehicle.

Fig. 4 illustrates one exemplary online form to be used by the owner/driver of one mode of public transport vehicle for the purpose of creating and activating a centralised vehicle-specific profile in the profile-repository 260 according to an embodiment of the present invention. In addition to the physical association between the electronic device of first type 100 and the vehicle being used for a public transport that is possible by physically attaching, the logical association is possible through the profile creation for the given electronic device of first type 100 and the vehicle pair. Accordingly, the. owner/driver of the public transport facility (e.g., taxi, cab, taxicab) is expected to create, maintain and activate an on-line profile per vehicle being used for public transport in the said profile-repository 260 of the said server 222 of the said context-capturing framework 200, where the profile can be created using any personal computer 212 that can connect to the said server 222 via the Internet 220 on typing the correct URL of the said server 222 and the user is expected to enter the device-specific unique identifier of the said electronic device of first type 100 that is physically and logically associated with a given vehicle when prompted. This registration process will bind/tie the device-specific unique identifier and, hence a given electronic device of first type 100 being mounted on a given public transport vehicle to that vehicle.

Every vehicle-specific profile being maintained in the said centralised profile-repository 260 will keep essential details pertaining to a given public transport vehicle as exemplarily shown by 410. The type of information shown by 410 is non-exhaustive and is subject to change depending on the cuffent trend being applicable. The main idea is to ensure the authenticity of the owner/driver of a vehicle which is used to provide one mode of public transport facility. Hence, profile creation needs such essential details as vehicle registration number, country of registration, date of registration, any credit/debit card details to make sure the authenticity of the owner/driver, best number to contact, device-specific unique identifier pertaining to the said electronic device of first type 100 being mounted on the given vehicle and the like as shown in 410. Profile creation may expect some optional information related to the extra features a given vehicle possesses as shown by 420. These extra features are given to indicate the colour, usual fare per distance, and the number of seats of a given vehicle and whether the given vehicle has air-conditioning, WiFi/Internet, leather-seat, in-car-entertainment facilities and the like as shown in 420. Once created, each vehicle-specific profile needs to be activated by pressing the "yes" key in 430 and this will ensure that a corresponding active profile will be maintained in the profile-repository 260.

Further, this profile creation process requires the owner of the public transport to create login credentials namely the preferred user name/password that are specific to one vehicle and hence one electronic device of first type 100.

Using such credentials, the owner/driver of the vehicle being used to provide one mode of public transport facility can login on with the centralised server 222 and edit/deactivate/delete the vehicle-specific profile being maintained in the profile-repository 260.

Some vehicle-specific details being maintained by each entry of the profile-repository 260 are exemplarily shown iii 500 of Fig. 5. The more enricheY each entry is with vehicle-specific information, the more convenient for any prospective commuter to specify and identify the nearest public transport facility being available for a hire/ride -this will be explained later. It contains details such as the mode of public transport (such as taxi/cab/taxicab, bus, coach, ferry, shuttle and the like), vehicle registration, date of registration, country. of registration, oer/driver's name, best mobile number to contact the driver, address, credit card details and the like. More importantly, each entry is indexed by the device-specific unique identifier if it is the electronic device of first type 100 that is going to be mounted or server assigned unique alphanumeric identifier if it is the existing capable mobile phone, smartphone or similar electronic device that is going to be used iii the capacity of a context-reporting mobile device through purpose-built software solutions.

Each entry may also include the extra featuies of the vehicle that are shown by 420 -which are usual fare per distance, number of seats, co1our pet policy, food policy, availability of leather seats, Internet, air-conditioning, in-car-entertainment, disability assistance and the like.

Each electronic device of first type 100 runs a client application and possesses a green LED 150 and red LED 140 on the exterior side. The client application will automatically contact the said centralised server 222 when the said electronic device of first type 100 is powered on. The client application has a hard-wired configuration details that allow it to contact the centralised server 222 when the electronic device of first type 100 is powered on while passing the device-specific unique identifier on to the server 222. Subsequently an LED indicator on the device will indicate the registration status depending on whether a corresponding profile already exists or not in the said profile-repository 260 being maintained in the said centralised server 222. The forwarded device-specific unique identifier belonging to the electronic device of first type 100 is used as an index to look for a given vehicle-specific entry in the profile-repository 260. With this arrangement, automatic lighting up of LEDs 140 and 150 has the following interpretation: a) an automatic powering on of the said green LED 150 indicates that the said client application has already found a corresponding entry in the said profile-repository 260 and the given electronic device of first type 100 is ready to operate; or b) an automatic powering on of the said red LED 140 indicates that no corresponding entry exist centrally; As said before, as part of this process the device-specific unique identifier of the said electronic device of first type 100 is passed on to the server application 224 for the said server application 224 to search the profile-repository 260 using the said device-specific unique identifier as the index.

On seeing that a corresponding entry exists in the said profile-repository 260 of the said centralised server 224, the said client application running on a given electronic device of first type 100 will maintain connectivity with the hard-wired configuration details that allow it to contact the centralised server 222 when the electronic device of first type 100 is powered on while passing the device-specific unique identifier on to the server 222. Subsequently an LED indicator on the device will indicate the registration status depending on whether a corresponding profile already exists or not in the said profile-repository 260 being maintained in the said,centralised server 222. The forwarded device-specific unique identifier belonging to the electronic device of first type 100 is used as an index to look for a given vehicle-specific entry in the profile-repository 260. With this arrangement, automatic lighting up of LEDs 140 and 150 has the following interpretation: a) an automatic powering on of the said green LED 150 indicates that the said client application has already found a corresponding entry in the said profile-repository 260 and the given electronic device of first type 100 is ready to operate; or b) an automatic powering on of the said red LED 140 indicates that no corresponding entry exist centrally; As said before, as part of this process the device-specific unique identifier of the said electronic device of first type 100 is passed on to the server application 224 for the said server application 224 to search the profile-repository 260 using the said device-specific unique identifier as the index.

On seeing that a corresponding entry exists in the said profile-repository 260 of the said centralised server 224, the said client application running on a given electronic device of first type 100 will maintain connectivity with the device-specific unique identifier of the electronic device of first type 100 (i.e., the logical association) as shown in 400; iii) turning on the electronic device of first type 100 and waiting till the green LED 150 on the electronic device of first type 100 turns green; if not, a corresponding profile needs to be created online and activated; iv) on noticing a green LED 150 being lit up on the electronic device of first type 100, the taxi/cab/taxicab driver/owner pressing the said "availability" button 170 to advertise the availability status of a given taxi/cab/taxicab; and, v) on recognising that the "availability" button 170 is pressed by the taxi/cab/taxicab owner/driver, the said client application determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type 100 along with the determined location information on to the said centralised server 222.

On being notified, the said server application 224 of the said centralised server 222 will look for a corresponding entry in the said profile-repository 260 using the device-specific unique identifier as the index and on being found, the server application 224 will change the taxi/cab/taxicab availability status to "being available" and update the absolute geographical location and the corresponding time stamp. * 66

At the same time, the taxi/cab/taxicab owner/driver can advertise the unavailability status of the taxi/cabltaxicab for ahirelride in a given region by pressing the said "unavailability" button/key 110 of the said electronic device of first type 100. On recognising that the "unavailability" button 110 is pressed by the taxi/cab/taxicab owner/driver, the said client application' running on the electronic device of first type 100 will pass the device-specific unique identifier of the said electronic device of first type 100 on to the said centralised server 222. On being notified the said server application 224 of the said centralised server 222 will look for a corresponding entry in the said profile-repository 260 using the device-specific unique identifier as the index and on being found, the server application 224 w1l change the taxi/cab/taxicab availability status to "being unavailable" and update the corresponding time stamp.

According to one embodiment of, the present invention, the said electronic device of first type 100 being part of a context-capturing framework 200 enables taxi/cab/taxicab drivers to automatically advertise their availability along with their geographical positions through the said centralised server 222 without pressing any button 170. According to this arrangement, if the said client application running on the electronic device of first tyj,e 100 can determine that a given taxi/cab/taxicab has been parked in a particular location for more than a given time-limit, men this taxi/cabftaxicabs availability for a hire/ride will be automatically advertised without having to click any button 170 unless the taxi/cab/taxicab owner/driver has already pressed the "unavailability button" 110. As part of this automatic updating process, the said client application running on the electronic device of first type 100 will determine the current absolute geographical location of the electronic device of first type 100 by liaising with the said mechanism that determines the geographical location and passing the device-specific unique identifier of the said electronic device of first type 100 along with the determined location information on to the said centralised server 222. On being notified the said server application 224 of the said centralised server 222 will look for a corresponding entry in the said profile-repository 260 using the device-specific unique identifier as the index and on being found, the server application 224 will change the taxi/cab/taxicab availability status to "being available" and update the corresponding time stamp.

According to one preferred embodiment of the present invention, the electronic device of first type 100 or similar context-reporting client device 208 can also function as a fare meter for continuously calculating and displaying the fare the travelling commuter owes. The electronic device of first type 100 can further has the printer functionality to print the receipt out and/or functions as a toll box for road pricing.

According to another preferred embodiment of the present invention, the said centralised server 222 contains a navigation map 290 of a serving region and a traffic database 292. In this particular arrangement, every road, street, highway, motorway or the like is segmented based on the speed limit as set by the highway-agency, road authority, local-government, central government or similar body. Each segment is represented by a rectangle and each of such rectangles is designated by absolute geographical location information pertaining to all four corners. The traffic database 292 for a given region is primarily indexed using such a rectangle representing each segment of every road. street, highway, motorway and the like. In other words, the traffic database contains each segment of every road, street, highway, motorway and the like of a given serving region. If the reported location of a context-reporting mobile device 100/208 falls within the coordinates making up a given rectangle road/street/highway segment, the corresponding server application that maintains the traffic database 292 will associate the reported speed to the right segment in the traffic database 292. Under these circumstances, the said client application running on the electronic device of first type 100 takes an extra functionality for the purpose ofjudging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said client application to constantly run a timer of first type called speed/velocity-update timer; ii) when a timeout occurs, getting the client application to calculate the current speedlvelocity of the vehicle to which the given electronic device of first type 100 is physically and logically associated with, to determine the current absolute geographical location of the given vehicle by liaising wi th the said mechanism that determines the absolute geographical location and to update the said centralised server 222 with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of electronic devices of first type 100, getting the traffic/congestion judgement functionality 314 of the said server application 224 running on the said centralised server 222 to: a) first check whether the reported speed/velocity pertains to a segment of a road, street, highway or the like by liaising with the navigation map 290 and/or a traffic database 292. In case the reported speed/velocity does not pertain to any road or the like, the profile-repository 260 will be updated with the reported location and the device-specific unique identifier along with the current time-stamp, and the traffic/congestion judgement functionality 314 of the said server application 224 will ignore the update for further traffic/congestion judgement calculation. If, on the other hand, the reported speedlvelocity pertains to a segment of a road, street, highway or the like, it will be further checked whether the reported speed is zero. If not, the reported speed will be considered for further traffic/congestion evaluation. If, on the other hand, the reported speed is zero mainly because the concerned vehicle moves at a zero velocity due to traffic jam, the reported speed will be considered for further traffic/congestion evaluation; otherwise, it will be ignored; b) to deduce the velocity from the speed with the use of reported location and the navigation map 290 and/or traffic database 292; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location in terms of the segment of the road, street, highway, motorway or the like to which it pertains, the device-specific unique identifier and the time-stamp in the traffic-database 292; d) to calculate the moving average velocity using the received non-stale updates from other electronic devices of first type 100 pertaining to the same segment of a given road/street/highway/motorway or the like that are stored in the traffic database 292; e) to liaise with the traffic database 292 and temporarily cache the calculated moving average velocity in the said traffic database 292 against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity times-out; and, t) getting the traffic/congestion judgement functionality 314 to accompany the time stamp with each cached moving average velocity information being stored in the traffic database 292.

This way by getting the said client application running on each of said electronic device of first type 100 to update the said centralised server 222 with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestionltraffic database of a given road, street, highway, motorway and the like.

Each velocity update (4-tuple information) and the calculated moving average velocity that are stored in the traffic database 292 against the segment of a road, street, highway, motorway or the like will be subject to a time-out mechanism. With this, each entry will become stale and hence is non usable after times out.

In case the reported speed by a first vehicle happens to be zero, the question of whether the first vehicle is parked in the middle of a road due to severe traffic jamlcongestion or traffic signal light can be answered by getting the traffic/congestion judgement functionality 314 of the said server application 224 to check the updates from other vehicles that happen to be on the same segment of the road, street, highway, motorway or the like as the first vehicle.

In order to compare with other speed updates, all updates need to be received within a given time-window oft-seconds. Time stamping each entry will help the traffic/congestion judgement functionality 314 of the said server application 224 to consider the appropriate updates based on their time coherence/correlation. If only one vehicle reports zero speed whereas all the other vehicles within the same segment reports non-zero speed within a given time interval (shortest as possible) then the zero speed update won't be taken into consideration, and hence will be ignored for further traffic/congestion judgement calculation by 314.

As said before, creation of an online congestion/traffic database 292 is possible because the server application 224 continuously run a traffic! congestion judgernent functionality/algorithm 314. This traffic/congestion judgement functionalitylalgorithm 314 which is constantly active runs a timer of fourth type (called mean velocity timer). Accordingly, whenever the respective timeout occurs it calculates the mean velocity (preferably a moving average) for a given region and temporarily caches the calculated moving average velocity in the traffic database 292 against the segment of a road, street, highway. motorway or the like to which it is applicable until the calculated moving average velocity is replaced with a new entry or times-out.

The mean velocity calculation can be based on time-window averaging or simple arithmetic mean averaging. As it can be perceived, the server application 224 constantly receives traffic/congestion information of a given geographical location (road/street/highway and the like) from every electronic device of first type 100 regularly in terms of velocity at which the traffic is moving.

According to one preferred embodiment of the present invention, the server application 224 will take an extra functionality to liaise with the said profile-repository 260 and said traffic database 292 in order to inject traffic tips to every electronic device of first type 100 in case the calculated mean velocity is much lower than the speed limit being set to a given road/street/highway and the like where a given vehicle carrying a given electronic device of first type 100 is travelling on. In such an arrangement, on receiving the traffic tips the electronic device of first type 100 will render it depending on its capabilities so that the user/commuter will be informed in advance of a traffic/congestion situation in a given location.

According to this arrangement, the centralised server 222 will hold information pertaining to the congestion or traffic situation of almost every road/street/highway of a given region. This will allow any prospective user of a given road/street/highway to get some tips by contacting the server 222.

This is possible if the prospective user of a given road/street/highway carries a context-information seeking mobile client device 204 (i.e., a handheld device) like a mobile phone, smartphone, PDA or similar device that runs the said purpose-built client software 206 allowing the prospective commuter to connect to the centralised server 222 seamlessly for the purpose of getting the required context information. By providing an appropriate user interface allowing the prospective user of a given road/street/highway to enter the location/name of a preferred road/street/highway, the said purpose-built client software 206 running on the context-information seeking mobile client device 204 (i.e., a handheld device) like a mobile phone, smartphone, PDA or similar device of a prospective user of a given road/street/highway gets the traffic/congestion details on demand from the traffic database. This will allow the given user to avoid certain roads/streets/highways in order not to get stuck due to heavy traffic. Please note that traffic tips would be available only when çntries pertaining to a given segment of a road or the like are non-stale.

The electronic device of first type 100 and its associated functionalities needed for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein can be realised in multiple different ways. According to the second preferred embodiment of the present invention, the essential functionalities of the electronic device of first type 100 can be realised potentially by the system on a chip and the associated software functionalities.

Fig. 6 depicts the basic components of context capturing electronic system on a chip (SoC) 610 using one or plurality of microprocessors according to one embodiment of the present invention that can be configured in any form as those having ordinary skill in the art will appreciate. According to the second preferred embodiment of the present invention, the essential functionalities of the electronic device of first type 100 can be realised potentially by the system on a chip (SoC) 610 with its microprocessor containing the software stack as shown in Fig. 7. In other words, any electronic device of first type 100 or similar contextreporting mobile client device 208 that forms part of the contextcapturing framework 200 for the purpose of capturing and reporting context information pertaining to one or plurality of public transport facilities *and the commuters travelling therein preferably includes the context capturing SoC 610. The said context capturing electronic system on a chip (SoC) 610 potentially forms/realise or makes up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein.

Various described embodiments propose the SoC 610 to capture context information pertaining to users on the move that is performed as software executed on a general purpose microprocessor 612, such as a Reduced Instruction Set Computer (RISC) microprocessor. The context capturing electronic system SoC 610 includes one or plurality of microprocessors 612, system memory such as ROM 614 and RAM 616, system peripheral controller 620 and a communication controller 630 in its basic configuration.

It can further include a system memory controller 624, audio/video codec 622 in case additional functionalities are expected as it will be described later -all of which are communicatively coupled over bus 618. It should be appreciated that context capturing SoC 610 may include additional components, as understood by those of skill in the art. These additional components are not described herein in order not to obscure the embodiments described herein.

In one embodiment the context capturing electronic system SoC 610 with its microprocessor containing the software stack as shown in Fig. 7 is operable to be part of a context-capturing framework 200 that comprises: a) a server 222 that has a profile-repository 260 and server application 224 running continuously, and the said profile-repository 260 maintains profile information pertaining to every public transport vehicle being registered successfully; b) a communication network 218/220 which allows the said electronic device of first type 100 to maintain intermittent connectivity with the said server via a communication interface of first type.

In such an environment, a user interface of first type that is coupled to the bus 618 via a peripheral controller 620 allows the user to advertise the availability/unavailability status of a given vehicle being used to provide one mode of public transport facility along with its current geographical location through the centralised server automatically with a click of a button/key.

Every electronic device of first type 100 being made up of essentially the context capturing SoC 610 with its microprocessor running the software stack as shown in Fig. 7 comprises a device-specific unique identifier (i.e., device-ID). This device-ID can preferably be assigned at the time of manufacturing and can be preferably written on the exterior side of the said electronic device of first type 100. The driver/owner of a given public transport vehicle has to use the device-ID at the time of logically associating a given device 100 with a given vehicle as explained before. According to the second preferred embodiment of the present invention, every electronic device of first type 100 being made up of essentially the context capturing SoC 610 with its microprocessor running the software stack as shown in Fig. 7 needs to be registerea by tue user with the said profile-repository 260 of the said centralised server 222 and subsequently mounted on the vehicle providing one mode of public transport facility before being used. This process will physically and logically associate/tie a given electronic device of first type to a given vehicle being used to provide one mode of public transport facility.

The said context capturing electronic SoC 610 potentially fonning/realising an electronic device of first type 100 for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein gets one or plurality of its microprocessors 612 to have an appropriate software stack as shown by 700 of Fig. 7. The microprocessor can be multipurpose such as a CPU or in contrary it can be a RISC microprocessor. The software stack 700 demonstrates the operations and applications executed by one RISC microprocessor, e.g., 612 of Fig. 6. As it can be seen, according to one embodiment, the basic functionalities of the software stack 700 comprise user applications and user interface 712, application layer 736, a traffic condition reporting module 744, a public transport facility availability reporting/advertisement module 750, geographical positioning determination module 760, another module 770 to perform miscellaneous operations pertaining to displaying fare information, session management, multimedia rendering and the like, a connection manager 776, OS abstraction layer 784, MAC control layer 788, and the physical layer configurations 790.

I

The connection manager 776 is responsible for establishing the necessary connection with the said server application 224. In its enhanced version, the multimedia applications of 712 of the software stack 700 consists of VoIP 714. \T2IP 718, online gaming 722, multimedia streaming 730 and instantaneous messaging or IP messaging 736 functionalities. Although multimedia application specific functionalities are not shown explicitly, it needs to be appreciated that they are typically included in their standard versions and are well understood by those of skill in the art. In one embodiment, the RISC processor may have TCP/IP and transport protocols such as UDP/SCTP/TCP in addition to MAC and PRY layers.

The software stack 700 may also include voicelvideo processing applications and procedures can have another DSP processor that can be used in conjunction with a general purpose RISC microprocessor. These are not included in order not to obscure the described embodiments but the details of which are well understood by those of skill in the art.

Every electronic device of first type 100 being made up of essentially the context capturing SoC 610 with its microprocessor running the software stack as shown in Fig. 7 possesses a green LED 150 and a red LED 140 on the exterior side that are connected to the said peripheral controller 620. The said connection management functionality 776 of the said software stack 700 will automatically contact the said centralised server 222 when the said electronic device of first type 100 is powered on. Subsequently, the LED indicator on the device will indicate the registration status depending on whether a corresponding profile already exists or not in the said profile-repository 260 being maintained in the said centralised server 222 such that: a) an automatic powering on of the said green LED 150 will indicate that one or more functionalities of the said software stack 700 have already found a corresponding entry in the said profile-repository 260 being maintained in the said centralised server 222 and the said electronic device of first type 100 is ready to be used; or, b) an automatic powering on of the said red LED 140 will indicate that no corresponding entry exist centrally.

When the connection manager functionality 776 of the software stack 700 contacts the server application 224, it will pass the device-specific unique identifier of the said electronic device of first type 100 for the said server application 224 to search the profile-repository 260 using the said device-specific unique identifier as the index. According to this arrangement, on seeing that a corresponding entry exists in the said repository 260 of the said centralised server 222, one or more functionalities of the said software stack 700 will maintain connectivity with the server application 224 running on the centralised server 222 via the communication interface of first type for the purpose of periodically updating the availability/unavailability status and the location information when prompted by the user.

The geographical position determination module 760 of the software stack 700 captures the positioning information by making use of any prevailing state of the art technologies such as Global Positioning System (GPS) and/or other mobile/wireless network assisted positioning. In case the said electronic device of first type 100 comprises a GPS receiver 644 or any wireless transceiver 664 it needs to be coupled to the bus 618 via a communication controller 630. Further the wireless transceiver 664 provides the communication interface of first type for various functionalities of the software stack 700 to maintain connectivity with the centralised server 222.

The wireless transceiver 664 can support TDMA, CDMA, FDMA, OFDMA or SC-.FDMA and can be part of any PLMN such as GPRS, UMTS, CDMA2000. HSPA+, LTE, LTE-A, WiMAX, WiFi and their variants.

* Every electronic device of first type 100 being made up of essentially the * 15 context capturing SoC 610 with its microprocessor running the software stack as shown in Fig. 7 provides a user interface of first type. According to one embodiment of the present invention, in its basic configuration, the said user interface of first type has a keyboard 636 consisting of only two electronic buttons/keys being connected via the said peripheral controller 620 having the following features: i) one green button/key known as "availability" button; and, ii) one red button/key know as unavailability" button.

P

It is possible for the "availability"! "unavailability" buttons to be soft being embedded on a touch-screen.

Once the driver/owner of one mode of public transport facility (e.g., taxi/cab/taxicab) has mounted the said electronic device of first type 100 being made up of essentially the context capturing SoC 610 with its microprocessor running the software stack as shown in Fig. 7 in the appropriate place of the taxi/cab/taxicab after having created and activated a corresponding profile pertaining to the given taxi/cab/taxicab vehicle and the said electronic device of first type being mounted therein in the centralised profile-repository 260, turning on the said device will allow the said software stack 700 of the said electronic SoC 610 runs a public transport availability advertisement procedure 750 allowing the taxi/cab/taxicab owner/driver to advertise the availability status of the taxi/cab/taxicab for a hire/ride in a given region and the said advertising procedure 750 comprises the steps of: i) the connection manager 776 of the software stack 700 automatically connecting to the said centralised server 222 and checking whether a corresponding entry exists in the said profile-repository 260 using the device-specific unique identifier as the index; ii) on having found a corresponding entry in the said profile-repository 260, turning on the green LED 150 of the said electronic device of first type 100; otherwise turning on the red LED 140 to indicate to the taxi/cab/taxicab owner/driver that a corresponding profile needs to be created in the said profile-repository 260; iii) beginning to listen to user inputs; iv) on recognising that the "availability" or "unavailability" button is pressed by the taxi/cab/taxicab owner/driver, getting the geographical position determination module 760 to determine the current absolute geographical location of the electronic device of first type 100 by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type 100 along with the determined location information on to the said centralised server 222.

Accordingly, on being notified the said server application 224 of the said centralised server 222 will look for a corresponding entry in the said repository 260 using the device-specific unique identifier as the index and on being found, the server application 224 will change the taxi/cab/taxicab's availability status to "being available" or "being unavailable" for a hire/ride respectively depending on the type of button pressed by the taxi/cab/taxicab owner/driver and update the absolute geographical location and the corresponding time stamp.

According to one preferred embodiment of the present invention, the said centralised server 222 contains a navigation map 290 of a given serving region and maintains a traffic database 292 for the given serving region. As mentioned before, the traffic database 292 is made up of traffic-related entries pertaining to segments of every road, street, highway, motorway and the like of a particular serving region. In addition, the said software stack 700 of the said electronic SoC 610 takes an extra traffic condition reporting functionality 744 for the purpose ofjudging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said traffic condition reporting functionality 744 of the said software stack 700 to constantly run a timer of first type called speed/velocity-update timer; ii) when a timeout occurs, getting the said traffic condition reporting functionality 744 of the said software stack 700 to calculate the current speed/velocity of the vehicle to which the given electronic device of first type is physically and logically associated with, to determine the current absolute location of the given vehicle by liaising with geographical position determination module 760 and to update the said centralised server 222 with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving speed/velocity information at a given location from one or plurality of electronic devices of first type 100, getting the traffic/congestion judgement functionality 314 of the said server application 224 running on the said centralised server 222 to: a) first check whether the reported speed/velocity pertains to a segment of a road, street, highway or the like by liaising with the navigation map 290 and/or a traffic database 292. In case the reported speed/velocity does not pertain to any road or the like, the profile-.

repository 260 will be updated with the reported location and the device-specific unique identifier along with the current time-stamp, and the traffic/congestion judgement functionality 314 of the said server application 224 will ignore the update for further traffic/congestion judgement calculation. If, on the other hand, the reported speed/velocity pertains to a segment of a road, street, highway or the like, it will be further checked whether the reported speed is zero. If not, the reported speed will be considered for further traffic/congestion evaluation. If, on the other hand, the reported speed is zero mainly because the concerned vehicle moves at a zero velocity due to traffic jam, the reported speed will be considered for further traffic/congestion evaluation; otherwise, it will be ignored; b) to deduce the velocity from the speed with the use of reported location and the navigation map 290 and/or traffic database 292; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location in terms of the segment of the road, street, highway, motorway or the like to which it pertains, the device-specific unique identifier and the time-stamp in the traffic-database 292; d) to calculate the moving average velocity using the received non-stale updates from other electronic devices of first type 100 pertaining to the same segment of a given road/street/highway/motorway or the like that are stored in the traffic database 292; e) to liaise with the traffic database 292 and temporarily cache the calculated moving average velocity in the said traffic database 292 against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity times-out; and, f) getting the traffic/congestion j udgement functionality 314 to accompany the time stamp with each cached moving average velocity information being stored in the traffic database 292; Accordingly, the said software stack 700 of the said electronic SoC 610 runs the said traffic condition reporting 744 procedure in order to update the centralised server 222 with the said three-tuple information for the traffic/congestion judgement functionality 314 of the said server application 224 to create an online congestionltraffic database 292.

Fig. 8 depicts how the context-capturing framework 200 allows any user to get the required context information pertaining to his/her surrounding in terms of the public transport facilities being available, traffic/congestion situation and the like. More specifically, any prospective commuter can use the local transport availability service or application 800 to look for an availability of a given mode of transport in the neighbourhood. In one arrangement, the local transport availability application 800 can be installed on a handheld device carried by the prospective commuter. In another arrangement, the commuter can access a the centralised server 222 by typing a particular URL via an Internet using a PC 212 or mobile phone that has data service and get the required context information pertaining to his/her surrounding from the centralised server 222.

According to one embodiment of the present invention, the centralised server 222 vill hold information pertaining to the availability/unavailability of a given mode of public transport facility (e.g., taxilcabhaxicab) in a given region. This will allow any prospective commuter to identify/find the nearest and preferred mode of public transport facility that suits the commuter's search criteria. This is possible if the prospective commuter carries a context-information seeking mobile client (handheld) device 204 like a mobile phone, smartphone, PDA or similar device that has already installed and is capable of running the purpose-built client software 206 consisting of the local transport availability application 800. The local transport availability application 800 provides an appropriate user interface allowing the prospective commuter to enter his/her search criteria as shown in Fig. 8. Some search criteria are 20. important as shown by 810, 820 and 830. Actually 810 allows the prospective commuter to indicate the actual mode of the public transport facility such as * taxi/cab/taxicab, coach/bus/shuttle, ferry and the like preferred. Another search criterion pertains to the maximum fare preferred as shown by 820. The prospective commuter can indicate the distance metric (whether km or mile or the like) and the currency (whether dollars, pounds, euro) in 820. In 830, the prospective commuter can indicate the minimum number of seats needed. lt is important to be noted, in connection with Fig. 8, that the search criteria exemplarily shown in Fig. 8 is non-exhaustive and may vary depending on future trends and needs.

Optional search criteria can be indicated in 840. Once the user has entered/ticked the preferred search criteria, he/she can activate the search by pressing/selecting the "Start the search" on-screen key/option. When this happens, the local transport availability application 800 will first capture the current geographical position information using GPS or similar service, and then automatically contact the server application 224 while passing the search criteria along with the captured geographical location information of the prospective commuter on to the server application 224. The server application will then run the actual search on the profile-repository 260 looking for the availability of the desired public transport facility in the local neighbourhood of the given prospective commuter based on his/her current absolute geographical positioning information while satisfying the search criteria being submitted. Once found, the results are passed on the prospective commuter. In case the prospective commuter has used a PC 212 to run the local transport availability service 800 using the World Wide Web (i.e., in this case the local transport availability service 800 runs an HTTP client), the results will be immediately made available on the PC 212. On the other hand, in case the prospective commuter runs the local transport availability application 800 that is installed on his/her handheld device 204, the server will return the results to the handheld device 204. If more than one public transport facilities satisfy the search criteria, their details including the contact information and the current geographical position information will be returned to the prospective commuter the results can be sorted based on the distance between the prospective commuter and the given mode of public transport facility or the fare by the prospective* commuter, and local transport availability application/service 800 will facilitate such a sorting operation.

This way, this special piece of purpose-built software 800 of 206 running on the context-information seeking mobile client 204 (i.e., handheld device) of a prospective commuter finds the nearest taxi/cab/taxicab or similar public transport facility in the near vicinity. If the context-information seeking mobile client 204 (i.e., handheld device) carried by the prospective commuter has a GPS receiver or similar technology to determine the absolute geographical location of the prospective commuter, the said purpose-built software 800 of 206 will determine the location information and pass it onto the centralised server 222 along with other search criteria being specified by the prospective commuter. Such search criteria may include mode of public transport facility (whether taxi/cab/taxicab, shuttle bus, coach, ferry and the 1 colou vecle type, avaibi1ityof air-conditioning, leather seat, in-car entertainment and the like preferred. On being submitted, the server application 224 will search the profile-repository 260 to see whether there is any mode of public transport facility being available that satisfies the prospective commuter's search criteria. Once found, the server application will pass the results of the search to the said purpose-built software 800 of 206 running on the context-information seeking mobile client 204 (i.e., handheld device) carried by the prospective commuter.

On getting the details of the preferred mode of public transport facility satisfying the search criteria along with each vehicle's absolute geographical location information, the prospective commuter can choose the preferred one and get to it while being guided by navigation software if the local transport availability application 800 running on the context-information seeking mobile client 204 (i.e., handheld device) carried by the prospective commuter has such a facility. On the other hand, the prospective commuter can manually contact the driver/owner of the given mode of public transport facility perhaps via the phone. According to another preferred embodiment, the pull service functionality 370 of the server application 224 will get the search criteria when the purpose-built client software 800 contacts the server application 224, coordinates with public transport availability prediction functionality 312 and return the search results back to context-information seeking mobile client 204.

Similarly, any prospective road/streetlhighway user can get the traffic/congestion information pertaining to a given road/street/highway using pull/push approaches. Given that each electronic device of first type 100 or any other context-reporting mobile client device 208 that is on the move calculates and sends periodic velocity information to the server 222 along with the geographical positioning information, the traffic/congestion judgement functionality 314 of the server application 224 will use this to constantly determine the traffic pattern of each road/street. As said before the server application 224 constantly runs the traffic/congestion judgement functionality 314 and the traffic conditions per each road, street, motorway, highway and the like are stored in the traffic database 292 for other algorithms and applications (e.g., Pull Service Functionality 370 of the Server application 224) to download on submitting the location information. It is preferred that the said instantaneous traffic conditions/tips/information for a given region is available on-demand if a consumer submits a query to the server 222.

In order to provide the traffic/congestion tips pertaining to a given road/street/highway, the traffic/congestion judgement functionality 314 will calculate the average velocity at which the traffic is moving in every possible location of a given region. Then it will normalise the calculated average velocity with respect to the speed limit of a given road segment. If the normalised value is one, there is no congestion at all. On the other hand, if the normalised value is less than one, it indicates that there is congestion/traffic-jam. The intensity of the congestion/traffic-jam is again determined by the normalised value -the lower the value, the worse the traffic situation is.

According to the pull approach, a user can specify the preferred location/name of a given road/street/highway in terms of absolute geographical coordinates, postcode, zipcode and the like in order to get the traffic/congestion situation therein. This is again possible via the Internet by submitting a given geographical location information of a given road/street/highway to the server application 224 by running a HTTP client on the PC 212. On the other hand, a user can run a similar application like the local transport availability application 800 on the context-information seeking mobile client device 204 by enhancing the purpose-built client software 206. On the other hand, according the push approach, the traffic/congestion judgement functionality 314 will continuously monitor the instantaneous location of a given electronic device of first type 100 by liaising with the profile-repository 260 and the traffic database 290 and push the traffic/congestion tips quantifying the traffic/congestion situation pertaining to the surrounding environment of where the given electronic device of first type 100 is currently located.

The flow-chart 900 of Fig. 9 illustrates the methodology/procedure involved in transforming an existing mobile phone, smartphone or similar electronic device 208 (referred to as context-reporting mobile client device) having the necessary hardware/software functionalities namely, i) a wireless transceiver providing a communication interface of first type; ii) an electronic visual display unit that can provide the required graphical user interface; iii) a mechanism to determine the absolute geographical location information of the said existing mobile phone, smartphone or similar electronic device 208; through a purpose-built context-capturing software running on the said mobile phone, smart-phone or similar electronic device 208 in order to enable them to he part of a context-capturing framework 200 in the capacity of context-repoñing mobile client/device. The same methodology/procedure applies to an electronic device of first type 100 in order to make it part of the context-capturing framework 200 as well.

Forming a context-capturing framework 200 in order to capture the required context information pertaining to one mode of public transport facility and/or the commuters that travel therein has a preset setup procedure/methodology as illustrated by the flowchart 900 of Fig. 9A. The context-capturing framework setup procedure/method starts with 910. In the processing step 920, the driver/owner of a given vehicle being used to provide one mode of public transport facility physically associate the context-reporting mobile device (can be electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device) 208 with the said vehicle by mounting at the appropriate place of the said vehicle. In the mean time, the owner/driver given vehicle being used to provide one mode of public transport facility by specifying the vehicle details with the centralised server 222 using a personal 212 computer and the World Wide Web 220 as explained in connection with Fig. 4. This is shown by the processing step 930.

According to one embodiment of the present invention, in case the context-reporting mobile device happens to be an electronic device of first type 100, it has a device-specific unique identifier that is known to the client application running on the device itself automatically. The same device-specific unique identifier is written on the exterior side of the electronic device of first type for the owner/driver to include that information at the time of vehicle-specific profile creation as explained earlier in connection with Fig. 4. This will allow the driver/owner of a public transport vehicle to logically associate the context-reporting mobile device with the given vehicle. This is true even in case the electronic device of first type 100 along with the associated/intended functionalities is formed/realised using the SoC 610 with its microprocessor running the software stack 700 as shown in Fig. 7.

On the other hand, according to another embodiment of the present invention, in case the context-reporting mobile device happens to be an existing mobile phone, smartphone, PDA or similar device 208 being capable enough to be transformed into a context-reporting mobile device through purpose-built context-capturing software solutions, at the time of profile creation, the owner/driver of the vehicle has to provide preferred username/password. In * case the user does not provide the device-specific unique identifier in 410, the profile maintenance related functionality 320 of the server application 224 will assign a unique alphanumeric identifier to the registered vehicle known as Profile ID. This is very similar to the device-specific unique identifier (i.e., device-iD) in terms of the size and the type. In the absence of a device-specific unique identifier, this Profile ID will bind (logically associate) a given vehicle to the profile being maintained in the profile-repository 260.

Please note that as explained before in the case of electronic device of first type 100,. it is the device-specific unique identifier that binds a given vehicle to the profile being maintained in the profile-repository 260.

Accordingly, before any existing mobile phone, smartphone, PDA 208 or similar device is used as a context-reporting mobile device, its purpose-built context-capturing software should provide a login window as shown in Fig. 9B for the owner/driver to login on with the centralised server 222. Please note that in order to enable such an operation, any existing mobile phone, smartphone, PDA 208 or similar device that is going to be used as a context-reporting mobile device should have the necessary hardware/software capabilities such as the possession of an electronic visual display being big * enough to display the login window as shown by 980, wireless transceiver to provide communication interface of first type for it to communicate with the centralised server 222 via 218, GPS or similar functionalities.

Once the profile is created/activated, device being mounted on the vehicle, and a Profile ID being assigned, the owner/driver of the vehicle has to turn on the context-reporting client device 208 on and activate the purpose-built context-capturing software/application running on 208 by signing on using the login credentials in the login window as shown in Fig. 9B. This is illustrated using the processing step 940. The owner/driver has to use the preferred username/password and the Profile ID being assigned by the server application 224 in order to login on with the centralized server 222. Once signed on, the purpose-built context-capturing software/application running on 208 will automatically contact the server application 224 passing the Profile ID details to the server application 224. The profile maintenance related functionality 320 of the server application 224 will handle this operation, and which in turn will search the profile-repository 260 in order to check whether a valid vehicle-specific profile entry exists in 260 using the Profile ID as the index. Please note that the profile-repository is indexed using the device-specific unique identifier and hence Profile ID will be of the same length and type as the device-specific unique identifier. Once found, the server application 224 will contact the purpose-built context-capturing software/application running on 208 with a positive response; otherwise, with a negative response. On receiving a positive response, the purpose-built context-capturing software/application running on 208 will display a message in its electronic visual display indicating that the device 208 is now ready to capture the context information (i.e., the owner/driver of the vehicle can now advertise the availability status of the vehicle for a hire).

In the decision making stage 950, the owner/driver of the vehicle being used to provide one mode of public transport facility checks whether device-ready message appears. If it does, owner/driver of the vehicle can advertise to indicate whether the vehicle is now available/unavailable for a hire in the processing step 960. If, on the other hand, a "device-not-ready" appears, the owner/driver of the vehicle should consider doing the steps 930 and 940 all again.

As explained in the previous paragraphs, on successfully locating a corresponding profile in the centralised server 222, the said purpose-built context-capturing software running on 208 displays that the said existing mobile phone, smartphone or similar electronic device 208 is ready for it to be used as part of the said context-capturing framework 200 on the graphical user interface, while activating two keys -one for advertising the availability of a given vehicle for a hire/ride and the other for advertising the unavailability of the given vehicle for a hire/ride.

The owner is now free to use either the availability or unavailability buttons/keys being activated. At this stage the purpose-built context-capturing software running, on 208 will listen to user inputs, On recognising that the avaiiawiity T'unavailabiiity" button is pressed by the taxi owner/driver, the said puose-bui1t context-capturing software running on 208 determines the current absolute geographical location of the said existing mobile phone, smartphone or similar electronic device 208 by liaising with the said mechanism that determines the location and passes the determined location information on to the said public transport availability prediction functionality 312 of 224 along with the said server assigned unique alphanumeric identifier (i.e., Profile ID).

Accordingly, on being notified the said server application functionality 312 of the said centralised server 222 will look for a corresponding entry in the said profile-repository using the said server assigned unique alphanumeric identifier as the index and on being found, the corresponding server application functionality 312 will change the taxi availability status to "being available" or "being unavailable" for a hire/ride depending on the type of key being pressed and update the absolute geographical location and the corresponding time stamp.

Every profile being maintained in the said centralised profile-repository 260 will keep public transport vehicle specific details such as the vehicle registration number, country of registration, current absolute geographical location, current timestamp, colour of the vehicle, availability status for a hire/ride, usual fare per distance, contact number, server assigned unique alphanumeric identifier pertaining to the said existing mobile phone, smartphone or similar electronic device 208 being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like.

As said before, the said server application 224 running on the said centralised server 222 is responsible for a multitude of functionalities and one of which is the profile creationlmaintenance related task 320 that makes sure to maintain each vehicle specific entry of the said profile-repository 260 once registered.

Any existing mobile phone, smartphone or similar electronic device 208 will employ the communication interface of first type in order to intermittently interact with the centralised server 222 and the communication interface of first type supports the main air interface of W1Fi (i.e., IEEE 802.11), GPRS, UMTS, CDMA2000, WiMAX, LTE, LTE-A or any similar wireless/mobile cellular network.

The flowchart 1000 of Fig. 10 illustrates the operations when the methodology/procedure that enables an existing mobile phone. smartphone or similar electronic device 208 having the necessary hardware/software capabilities or even an electronic device first type 100 to be part of a context-capturing framework 200 extends the capabilities of these devices of 100/208 type for the purpose of judging the traffic/congestion situation of a given location. This is possible in the case of 208 through enhancing the functionalities of the purpose-built context-capturing software that is to be installed and run on an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/software capabilities. On the other hand, in the event of an electronic device of first type 100 being the context-reporting mobile device, its client software has the extended functionality as it will be explained in relation to Fig. 10, According to one embodiment of the present invention, in case the electronic device is formed or made up of the context-capturing SoC 610 with its microprocessor running the software stack 700, the extended functionality is implemented by having the traffic condition reporting functionality 744. Hence, the term purpose-built context-capturing client software of the context-reporting mobile device (i.e., either 100 or 208), commonly refers to the software stack 700 or client application running on devices such as 100 and 208 and the extended functionality is called the traffic condition reporting functionality.

Accordingly, the traffic condition reporting functionality running on the context-reporting mobile device 100/208 will start a timer of first type called speed/velocity-update timer. This is illustrated by the processing step 1020.

Some device can calculate the velocity (i.e., a vector) whereas some devices can determine only the speed (i.e., a scalar) at which it they are travelling.

However, if a device has a navigation map/database, it can determine the velocity from the speed and the moving direction information.

After starting/running the speed/velocity-update timer (of first type) in the processing step 1030 of Fig. 10, the corresponding module of the purpose-built context-capturing client software (e.g., in the case of software stack 700, it is the traffic condition reporting functionality 744) will continuously monitor whether the time-out has occurred. The decision-making stage J 040 will, check this condition. If it has, the corresponding module (i.e., traffic condition reporting functionality) of the purpose-built context-capturing client S software running on the context-reporting mobile device 208/100 will calculate the speed or velocity as indicated by the processing step 1050.

According to one embodiment of the present invention, the traffic condition reporting functionality of the moving context-reporting mobile device 208/100 can store only the latest two locations along with the time-stamps in an internal memory and calculate the speed as explained below. Supposes that at time instances t1 and t2 (> t1), the reported locations of a context-reporting mobile device 208/100 in Cartesian coordinates be (x,, yj, Zi) and (x2. Y2, z2).

Hence, the speed of the given context-reporting mobile device 208/100 is given by the following equation: ye1 = t2 -tI Once the current speed is calculated, the traffic condition reporting * functionality of the given context-reporting mobile device 208/100 will * capture the current absolute geographical location by liaising with the mechanism. (e.g., GPS) that determines the location as indicated by the processing step 1060. Subsequently, the traffic condition reporting functionality of the given update the said centralised server 222 with three-tuple information consisting of speedlvelocity, current absolute geographical location and server assigned unique alphanumeric identifier (i.e., Profile ID) as illustrated by the processing step 1070. Please note that in the case of electronic device of first type, the three-tuple information includes the device-specific unique identifier instead of the Profile ID. With this operation, the control loop of the traffic condition reporting functionality will return to 1020 of Fig. 10 again.

The flowchart 1100 of Fig. 11 illustrates as to how the regular velocity or speed updates by every context-capturing client device 208/100 will allow the traffic/congestion j udgement functionality 314 of the server application 224 to maintain a traffic conditionlsituation database 292 that allows anybody to get the traffic information of a given location. This process starts at 1110, and proceeds to the decision-making stage 1120 at which the traffic/congestion judgement functionality 314 will check whether it has received any speed or velocity update from any context-capturing client device 208/100. If it has, at another processing step 1130, the traffic/congestion judgement functionality 314 will check whether the reported speed/velocity pertains to a segment of a road, street, highway or the like by liaising with the navigation map 290 and/or a traffic database 292. Once the check is performed, at the decision making stage 1140, the traffic/congestion judgement functionality 314 will conclude whether the reported speedlvelocity pertains to a segment of a road, street, highway or the like. In case the reported speed/velocity does not pertain to any segment of a road, Street, highway or the like, the reported speed will be ignored by 314, although it will coordinate with 312 to update the location information of a given device 100/208 in the profile-repository 260. If, on the other hand, the reported speed/velocity pertains to a segment of a road, street, highway or the like, it will be further checked whether the reported speed is zero in the decision making stage 1180. If not, the reported * speed will be considered for further traffic/congestion evaluation. If, on the * Other hand, the reported speed is zero mainly because the concerned vehicle moves at a zero velocity due to traffic jam, the reported speed will be considered for further traffic/congestion evaluation; otherwise, it will be ignored.

In order to compare with other speed updates, all updates need to be received within a given time-window oft-seconds. Time stamps of each entry will help the' traffic/congestion judgement functionality 314 of the said server application 224 to consider the appropriate updates based on their time coherence/correlation. If only one vehicle reports zero speed whereas all the 0th eludes within the same segment reports non-zero speed with inagiven time interval (shortest as possible) then the zero speed update won't be taken into consideration, and hence will be ignored for further traffic/congestion judgement calculation by 314.

In the next processing step 1146, the traffic/congestion judgement functionality 314 will deduce the velocity from the speed with the use of reported location and the navigation map 290 and/or traffic database 292. this is followed subsequently by the caching of 4-tuple information consisting of deduced velocity, current absolute geographical location in terms of the segment of the road, street, highway, motorway or the like to which it pertains, the device-specific unique identifier and the time-stamp in the traffic-database 292. Once cached, the decision making step 1150 will check whether there exists non-stale entries pertaining to speed updates by other context-reporting mobile devices 100/208 for the same segment of a given road, street, highway or the like in the traffic database 292. If there are non-stale entries for the same segment, the traffic/congestion judgement functionality 314 will calculate the moving average velocity using the received non-stale updates from other context-reporting mobile devices 100/208 pertaining to the same segment of a given roadlstreet/highway/ motorway or the like that are stored in the traffic database 292 in the processing step 1160.

Once the moving average velocity is computed, the traffic/congestion judgement functionality 314 will liaise with the traffic database 292 and temporarily cache the calculated moving average velocity in the said traffic database 292 against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity times-out along with the time-stamp. As mentioned before, each velocity update (4-tuple information) and the calculated moving average velocity that are stored in the traffic database 292 against the segment of a road, street, highway, motorway or the like will be subject to a time-out mechanism. With this, each entry will become stale and hence is non usable after times out.

+++++++++++++++++++H.++++++++++++++++++++++f Fig. 1 2A exemplarily depicts the exterior view of the enhanced version of an electronic device of first type 100 in terms of the extra functionalities it is expected to handle in addition to capturing context information pertaining to one mode of public transport facility and the commuters travel therein.

According to one embodiment of the present invention, the said electronic device of first type 100 takes extra functionalities by possessing a speaker configured to playback any received audio signal, an electronic visual display unit configured to playback any received video signal in an appropriate format, and a set of on-screen or physical keyslbuttons to get user inputs in connection with volume control, picture quality control and the like. It can receive any: multimedia content via the communication interface of first type.

tdmtronic device of first type 100 even has a microphone, maintains connectivity to any PLMN by possessing the necessary Subscriber Identity Module (SIM), Universal Subscriber Identity Module (USIM) or similar smartcard and the required hardware/software functionalities and the associated user interface to make circuit/packet-switched voice/video calls, send/receive text/multimedia messages (using Short-Messaging Service (SMS) or Multimedia Messaging Service (MMS)), connect to one or plurality of social networking sites such as Facebook, twitter, Linkedln and the like. Accordingly, the electronic device of first type 100 now has communication and entertaining functionalities in addition to gathering context information pertaining to users on the move.

As shown by 1200 of Fig. 1 2A, the enhanced version of the electronic device of first type 100 may have one or more input structures such as push buttons, toggle switches or dials on the outside of its electronic housing. Each input structure may be configured to activate a different function. The enhanced version of the electronic device of first type 100 consists of an electronic visual display unit 1248 (i.e., video panel/screen) in order to playback/view multimedia signals being received via the communication interface of first type, a pair of speakers 1256, one or plurality of wireless transceiver antenna 1246, a main settings button 1220 and associated arrow keys 1208, 1212, 1216, and 1228 for setting the time/day/date/calendar, manipulating video/audio received locally and tuning the TV or FM radio -please note that some of the settings are needed only if the enhanced version of the electronic device of first type 100 has extra functionalities such as TV/radio tuning, calendar built-in and the like. The electronic visual display unit 1248 can also be used to display the current status of various settings, configuration of the device like whether the device is now ready to be used for capturing the Context pertaining to one mode of public transport facility and the commuters travel therein, and to display the ambient temperature, time/date/day/calendar and the like. The electronic visual display unit 1248 can also be used for the purpose of streaming and playing back entertainment movies, video-clips and audio albums, if the enhanced version of can maintain a connection (e.g., radio link) with the Internet.

The enhanced version of the electronic device of first type 100 has a microphone 1204 configured to capture an audio input and transform it into digitised signal using an appropriate audio codec, a video camera 1250 configured to capture video input and transform it into digitised frame using an appropriate video codec, a speaker 1256 configured to playback the received audio signal. These facilities such as 1204 and 1250 let commuters to make voice/video calls respectively. In one embodiment the electronic visual display unit 1248 can be based on Thin-Film Transistor (TFT) preferably employing Quarter Video Graphics Array configured to playback the received video signal in an appropriate format.

The enhanced version of the electronic device of first type 100 has a power-on switch 1238 to turn itself on and off, one set of on-off toggle switch 1242 to

I

turn on/off the video camera 1250, and another set of on-off toggle switch 1236 to turn the microphone 1204 on/off. The enhanced version of the electronic device of first type 100 has its own power supply.

Electronic buttons 1232 are used to zoom in and zoom out the instantaneous video footage being viewed on the electronic visual display unit 1248. When buttons 1232 are pressed, appropriate command is given to the video camera to enable optical zooming. Electronic toggle switch 1230 is used to activate/deactivate muting of the speaker 1256. The enhanced version of the electronic device of first type 100 contains two sets of soft/physical keypads.

In 1200, only the physical keypads 1258 and 1260 are shown although they can be soft or on-screen in case the electronic visual display unit 1248 is equipped with touch sensor or used to work with a stylus. The keypad 1258 can be similar to a typical keypad a laptop/notepadlsrnartphone possesses.

According to one embodiment of the present invention, the enhanced version of the electronic device of first type 100 takes extra functionality to work as a traditional telephone, and hence has the handset 1254. In this respect, enhanced version of the electronic device of first type 100 maintains a connection to the standard PLMN 220 via a mobile/wireless base station 218.

Connection to the standard PLMN is possible by equipping the electronic device of first type 100 with a Subscriber Identity Module (SIM), Universal Subscriber Identity Module (USIM) or similar smartcard.

Fig. I 2B depicts the special keypad 1260 being used to operate the enhanced version of the electronic device of first type 100 in the intended way. As mentioned before, it can be either a physical keypad or an on-screen touchpad. The slit 1264 is used to insert a CD/DVD/Blue-ray-djsc for playing back any multimedia content on 1248 as long as the enhanced version of the electronic device of first type has the necessary hardware/software features.

The slot 1266 can be used to provide an USB, firewire (i.e., IEEE 1394 interface) or similar interface to connect an external device to the enhanced version of the electronic device of first type 100. The keys/buttons (either electronic or touch) 1278, 1276, 1274, 1272 and 1270 are used to make packet-switched VoIP and/or Video over IP calls, circuit-switched voice calls, circuit-switched video calls, and to initiate instantaneous messaging and test/multimedia (i.e.. SMS/MMS) messaging service. In addition, keys( buttons (either electronic or touch) 1296 and 1294 are used to display the instantaneous fare on the electronic visual display unit 648/1248 that may vary with the time, distance or combination of both and to print the receipt for the commuter respectively.

As soon as VoIP!V2IP button/key 1278 is pressed the purpose-built software client running on the enhanced version of the electronic device of first type will liaise with the associated VoIP/V2IP application (e.g., 714 of Fig. 7).

This will make sure that the necessary VoIPJV2IP client will get activated that Will enable the commuter to 0gm wh th VoIP/V21P server us ing JuisIogin credentials. For instance, if the VoIP/V2IP client is skype, pressing of 1278 will allow a skype login window/client to appear on 1248 for the commuter to sign in and make packet-switched calls as long as he/she has enough calling credits in his/her skype account. Similarly, pressing either 1274 or 1276 will enable the purpose-built client software running on the enhanced version of the electronic device of first type 100 to display an appropriate user interface on 1248 for the commuter to enter the telephone number using the keypadl258.

Similarly pressing the keys/buttons (either electronic or touch) 1272 enables the purpose-built software client running on the enhanced version of the electronic device of first type 100 to liaise with the associated instantaneous messaging application (e.g., 736 of Fig. 7). This will subsequently makes sure that the preferred IM client (e.g., MSN) will get activated that will provide the necessary user interface for the commuter to login in with the necessary IM server and to initiate instantaneous messaging with his/her currently online friends. Also, keys/buttons (either electronic or touch) 1270 is used to provide the necessary user interface to draft and send text/multimedia (e.g., SMS/MMS) messages via cellular communication network 220. The button/key 1268 is used to abort/cancel! stop any operation.

The set of keys as shown by 1280 is used to connect a commuter to one or plurality of Social Networking Sites (SNS) such as Facebook, twitter, Linkedln, MySpace and the like. When the individual keys of 1280 are pressed, the login window corresponding to the SNS site will appear on 1248 for the commuter to sign in onto the preferred SNS.

The Get-VoD key 1282 is used to search and stream any online video clips being available in the content database 250. When the key 1282 is pressed an appropriate user interface will appear on 1248 enabling the commuter to search the content database 250 using some preferred search criteria. When this happens, the purpose-built client software running on 100 will connect to the server application 224 while passing the search criteria on to it. The pull service functionality 370 of the server application 224 handles this and searches the content database 250 using the search criteria specified by the user and return the results back to the purpose-built client software running on 100. Once the preferred video content is found, it will be streamed and played back on 1248. In a similar way, the Get-AoD key 1284 will allow the commuter to search the content database 250 and get the desired audio content streamed on to the device 100. Similarly, the keys 1286 and 1288 will allow the commuter to get a list of local papers and tourist information on-demand from the content database 250 if the current location information is passed on to the server application 224. Also, the enhanced version of the electronic device of first type 100 supports Mobile TV andlor IPTV as it has the necessary wireless interface to maintain constant connectivity with the external networks.

According to one embodiment of the present invention, in case the context capturing electronic system on a chip 610 potentially forms or makes up the enhanced version of the electronic device of first type 100, the electronic visual display 1248/648 will be coupled to the bus 618 via the peripheral controller 620. Similarly all the settings input keys 1206/656, a pair of speaker 1256/668, a microphone 1204/676, a video camera 1250/672 and keypads 1260/1258/636 are all again coupled to the SoC 610 via the peripheral controller 620. In addition, in case the enhanced version of the electronic device of first type 100 employs any automatic voice recognition, the associated hardware 680 is coupled to the bus 618 via the peripheral controller 620. Also, if the enhanced version of the electronic device of first type 100 is equipped with a credit-card reader, mobile-wallet reader, m-payment reader 690/1252, it is again interfaced via the peripheral controller 620. For this purpose, in one embodiment, the enhanced version of the electronic device of first type 100 possesses hardware/software features required to support Near Field Communication (NFC).

The flowchart 1300 of Fig. 13 illustrates the various operations the enhanced version of the electronic device of first type 100 is capable of performing according to an embodiment of the present invention. According to this embodiment of the present invention, the purpose-built context-capturing software running on the enhanced version of the context-reporting mobile device (an enhanced version of electronic device of first type 100 or an / existing mobile phone, sinartphone or similar electronic device 208 having the necessary hardware/software functionalities) will trigger a timer of second type (i.e., location-update timer) in order to perform periodic geographical location updates with the centralised server 222. This timer will be activated only when the timer of first type is not activated. This is shown in the processing step 1320. Whenever this particular timeout occurs (this condition is checked in the decision-making stage 1330), every context-reporting mobile device 100/208 will captures its current absolute geographical location by liaising with the corresponding built-in mechanism as explained before.

Once captured, the context-reporting mobile device 100/208 will update the profile-repository 260 with its location information along with its device-specific unique identifier or Profile ID via the server application 224 as shown by the processing step 1340. The context-based advertisement (CBA) or location-based advertisement (LBA) push algorithm 360 of the server application 224 will take care of every location update and note this down in the profile-repository 260.

The context-based advertisement (CBA) or location-based advertisement (LBA) push algorithm 360 of the server application 224 periodically runs another timer of third type called CBAILBA-push timer. Whenever a timeout occurs, it will push the right advertisement to the right context-reporting mobile device 100/208 depending on the current context/location of the deviceand its surroundings (1.c ext pertaining to the veh ide where the device is mounted and the commuters travelling therein). Each context-reporting mobile device 100/208 is identified by its device-specific unique identifier or the Profile JD. Once it has pushed the right advertisements to all context-reporting mobile devices of 100/208 type, context-based advertisement (CBA) or location-based advertisement (LBA) algorithm 360 will restart the CBA!LBA-push timer (i.e., the timer of third type) and continues injecting the advertisements.

In case enhanced version of the context-reporting mobile device 100/208 is equipped with an Automatic Speech Recognition (ASR) mechanism (both software, firmware and hardware), it can figure out the commuters' intention by capturing/recognising the commuters' casual conversation or voice commands. For instance, if one or plurality of commuters are looking for a restaurant and happens to mention Chinese, food, hungry, thirsty, and the like, the ASR can capture this and pass it onto the CBAILBA push algorithm 360 so that 360 will inject the right advertisement content based on the current context (intent of the commuters). In addition, commuters can request interesting advertisements and/or movie-clips and/or audio albums and/or local newspaper/magazines and/or local tourist information with voice commands. The voice input device 1204 of Fig. l2A may be used for this purpose along with associated software functionalities.

Accordingly, as shown in Fig. 13, the processing step 1350 checks to see whether the enhanced version of the context-reporting mobile device 100/208 / has any AVR feature. If it does, in the next decision-making stage 1360 the purpose-built context-capturing software running on the enhanced version of the context-reporting mobile device (an enhanced version of electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardwarelsoftware functionalifies) will check whether the AVR functionality has captured any voice-command or user-intention through voice recognition and if it has, it will encode the captured command in the appropriate format and pass it on to the server 222, The server application will log it in the profile-repository 260 so that the CBA/LBA push algorithm 360 will push the right advertisement when the time out for pushing advertisement occurs.

Accordingly, the purpose-built context-capturing software running on the enhanced version of the context-reporting mobile device (an enhanced version of electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/sofiye functionalities) will check to see whether it has received any context-basedllocatjonbased advertisement in the decision-making stage 1380. If it has, the purpose-built context-capturing software running on the enhanced version of the context-reporting mobile device (an enhanced version of electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/software using thc clctröiik visual display unit 1248 andlor the speaker 1256 as illustrated using the processing step 1382.

After a multimedia clip of an advertisement being played back, the commuter has the option to purchase/reserve online the associated product of the advertisement clip that was played back using the key 1262. This condition is checked in the decision-making stage 1390, and in case the commuter would like to make an online purchase/reservation, the credit-card/mobile-wallet/rn-payment reader 690/1252 will be activated in order to execute the transaction.

As part of this process, the purpose-built context-capturing software running on the enhanced version of the context-reporting mobile device (an enhanced version of electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/software functionalities) will contact the "Authentication, Authorization and Accounting" (AAA) functionality 330 of the server application 224. This will ensure that the owner of the credit/debit card or m-payment account or similar account will be debited after having been checked for accounting, authorisation and authentication purposes.

As shown in 1300, the purpose-built context-capturing software running on the enhanced version of the context-reporting mobile device (an enhanced version of electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/software functionalities) will check to see in the processing step 1394 whether the commuter/driver of a given public transport facility has pressed any key namely 1280, 1278, 1276, 1274, 1272, 1270, 1294, 1262, 1296, 1292, 1290, 1288, 1286, 1284, and 1282. If so, then the purpose-built context-capturing software running on the enhanced version of the context-S reporting mobile device (an enhanced version of electronic device of first type or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/software thnctionalities) will coordinate with the corresponding application to act upon the user command as shown by the processing step 1398. In the middle of running any application that resulted in due to any key pressing by the user, any operation can be aborted, cancelled or terminated with a short-press of terminate-key 1268. This will let the context-reporting device to return to its default operations i.e., (un)availability advertisement with a click of a button, periodic locationlvelocjty/context updates and receiving and rendering context-based/locatjonbased advertisements, In case any commuter makes use of communicatio11Jentertajent features of the enhanced version of the context-reporting mobile device (i.e., electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/software functionaiities), he/she will be charged based on usage separately or together with the fare using the built-in creditcardJmobilewaletJmpayment 690/1252 mechanism.

The usage-based charge depends on the volume of traffic generated/accessed, time-duration or the combination of both.

The context-based/location-based advertising using an iCab is an extremely accountable medium; as it can results in higher advertising impact and greater customer satisfaction because this device introduce little privacy or spam concerns. iCab will enable advertising agencies and mobile marketers to target consumers with real-time and geographic precision. In turn, commuters will have advertising move with them, as the iCab device unobtrusively presents advertisements, offers, coupons, or other promotions that are specific to the a given locationlcontext. The advertisements might feature audio, rich graphics, or calls to action such as routing to the closest advertiser storefront and can lead to online secure purchasing using the enhanced version of the context-reporting mobile device (i.e., electronic device of first type 100 or an existing mobile phone, smartphone or similar electronic device 208 having the necessary hardware/software functionalities).

Claims

Claims There is provided an electronic device of first type to capture context information pertaining to one mode of public transport facility and/or the commuters that travel therein, and the said electronic device of first type comprising: i) a wireless transceiver providing a communication interface of first type; ii) a mechanism to determine the absolute geographical location information of the said electronic device of first type; wherein the said electronic device is part of a context-capturing framework that comprises: a) a server that has a profile-repository and other online databases and a server application running continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being registered successfully; b) a communication network which allows the said electronic device of first type to maintain intermittent connectivity with the said server via a communication interface of first type; wherein the said electronic device of first type provides a user interface of first type allowing the user to advertise the current geographical location of the said one mode of public transport facility with the centralised server automatically with a click of a button.
2. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein each of the said electronic devices of first type needs to be always physically and logically associated/tied with a given vehicle being used to provide one mode of public transport facility where the said electronic device of first type is going to capture context information.
3. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 2, wherein the physical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by physically mounting the said electronic device of first type at the appropriate place in the given vehicle.
4. The said electronic device of first type being part of a context-capturing framework according to claim I or 2, wherein the logical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by creating and activating a unique profile in the said profile-repository of the said centralised server and the said unique profile is specific to a given vehicle and the electronic device of first type.
5. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 4, wherein the said electronic device of first type comprises a device-specific unique identifier (i.e., device-ID) that is globally unique for the user to use it at the time of logical association.
6. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 5, wherein the owner/driver of the public transport facility is expected to create, maintain and activate an on line profile per vehicle being used for public transport in the said profile-repository of the said server of the said context-capturing framework, wherein the profile can be created using any personal computer that can connect to the said server via the Internet on typing the correct URL of the. said server and the user is expected to give unique information pertaining to a given vehicle and the electronic device of first type pair.
7. The said electronic device of first type being part of a context-capturing framework according to claim I or 6, wherein every profile being maintained in the said centralised profile-repository will keep public transport vehicle specific details such as the vehicle registration number, country of registration, current absolute geographical location, current timestamp, colour of the vehicle, usual fare per distance, availability status for a hire/ride, contact number, device-specific unique identifier pertaining to the said electronic device of first type being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like, and this profile creation process requires the owner of 11⁄4 the public transport to create login credentials namely the preferred user name/password that are specific to one vehicle and hence to one electronic device of first type.
8. The said electronic device of first type being part of a context-capturing framework according to claim I or 7, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creation/maintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.
9. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 8, wherein the said electronic device of first runs a client application and the electronic device of first type possesses green LED and red LED on the exterior side, wherein the said client application will automatically contact the said centralised server when the said electronic device of first type is powered on, and the LED indicators on the device will indicate the registration status of the given electronic device of first type depending on whether a corresponding profile already exists or not in the said profile-repository being maintained in the said centralised server such that: a) an automatic powering on of the said green LED indicating that the said client application has already found a corresponding entry in the said profile-repository and the given electronic device of first type is ready to operate; or,Nb) an automatic powering on of the said red LED indicating that no corresponding entry exist centrally; wherein the device-specific unique identifier of the said electronic device of first type is passed on to the server application by the said client application for the said server application to search the profile-repository using the said device-specific unique identifier as the index.
10. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 9, wherein the said electronic device of first runs a client application and on seeing that a corresponding entry exists in the said profile-repository of the said centralised server, the said client application will maintain connectivity with the server application running on the centralised server via the communication interface of first type for the purpose of periodically advertising the availabilitylunavailability status of a given mode of public transport facility along with the instantaneous location information when prompted by the user.
11. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein the mechanism to determine the absolute geographical location information of the electronic device of first type is any of the prevailing state of the art technologies such as Global Positioning System (GPS) and other mobile/wireless network assisted positioning, wherein the said electronic device of first type comprising a GPS receiver or any wireless transceiver.
12. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein the said communication network that allows the said electronic device of first type to maintain intermittent connectivity with the said server can be WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like, and the associated communication interface of first type is the main air interface of the WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like respectively.
13. The said electronic device of first type being part of a context-capturing framework according to any preceding claim, wherein the user interface of first type has only two electronic/soft buttons/keys having the following features: i) one green buttonlkey known as the "availability" button; and, ii) one red button/key known as the "unavailability" button.
14. The said electronic device of first type being part of a context-capturing framework according to any preceding claim, wherein the said one mode of public transport facility is taxi/cab/taxicab service, wherein the taxi/cab/taxicab owner/driver can advertise the availability status of the taxi/cab/taxicab for a hire/ride in a given region by performing the advertising procedure comprising the steps of: i) mounting the said electronic device of a first type in the appropriate place of the taxi/cab/taxicab vehicle (i.e., the physical association); ii) creating and maintaining a corresponding profile pertaining to the given taxi/cab/taxicab vehicle and the said electronic device of first type being mourned therein by specifying the taxi/cab/taxicab details as well as the device-specific unique identifier of the electronic device of first type (i.e., the logical association); iii) turning on the electronic device of first type and waiting till the green LED on the electronic device of first type to be automatically turned on; if not, a corresponding profile needs to be created online and activated; iv) on noticing a green LED being lit on the electronic device of first type, the taxi/cab/taxicab driver/owner pressing the said "availability" button to advertise the availability status of a given taxi/cab/taxicab for a hire/ride; and, v) on recognising that the "availability" button is pressed by the taxi/cab/taxicab owner/driver, the said client application determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said ceritralised server; wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" for a hire/ride and update the absolute geographical location and the corresponding time stamp.
15. The said electronic device of first type being part of a context-capturing framework according to claim I or 14, wherein the said one mode of public transport facility is taxi/cab/taxicab service, wherein the taxi/cab/taxicab owner/driver can advertise the unavailability status of the taxi/cab/taxicab for a hire/ride in a given region by pressing the said "unavailability" button/key of the said electronic device of first type on noticing that the device is ready to be used, wherein on recognising that the "unavailability" button is pressed by the taxi/cab/taxicab owner/driver, the said client application passing the device-specific unique identifier of the said electronic device of first type on to the said centralised server, wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being unavailable" for a hire/ride and update the corresponding time stamp.
16. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 14, wherein the said electronic device of first type enables taxi/cab/taxicab drivers to automatically advertise their availability for a hire/ride along with their geographical positions through the said centralised server, wherein if the said client application can determine that a given taxileabltaxicab has been parked in a particular location for more than a given time-limit, then this taxi/cab/taxicab's availability for a hire/ride will be automatically advertised without having to click any button unless the taxi/cab/taxicab owner/driver has already pressed the "unavailability button", wherein the said client application determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said centralised server, wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" for a hire/ride and update the corresponding time stamp.
17. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein the electronic device of first type can also function as a fare meter for a commuter and/or as a toll box for road pricing and/or has a printer fttnctionality to print the receipt out.
18. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said client application running on the electronic device of first type takes an extra functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said client application to constantly run a timer of first type; ii) when a timeout occurs, getting the client application to calculate the current speed/velocity of the vehicle to which the given electronic device of first type is physically and logically associated with, to determine the current absolute geographical location of the given vehicle by liaising with the said mechanism that determines the absolute geographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of electronic devices of first type, getting the said server application running on the said centralised server to: a) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further traffic/congestion calculation only when the reported speed/velocity pertains to a road, street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; I, b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d). to calculate the moving average velocity using the received updates from other electronic devices of first type pertaining to the same segment of a given road/street/highway/motorway or the like that are 0 still non-stale and are currently cached in the traffic database; e) to liaise with the traffic database and temporarily cache the calculated moving average velocity in the said traffic database against the segment of a road, Street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced with i new entry or times-out; and, f) getting the said server application to accompany the time stamp with each cached moving average velocity information being stored in the traffic database; wherein by getting the said client application rulming on each of said electronic device of first type to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestionltraffic database of a given road, street, highway, motorway and the like.
19. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 18, wherein the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said server application will take an extra functionality to liaise with the said profile-repository and said navigation map with an objective to inject traffic tips to every electronic device of first type that periodically notifies its instantaneous absolute geographical position information in case the calculated moving average velocity is much lower than the speed limit being set to a given segment of a road/street/highway/motorway or the like where a given vehicle carrying a given electronic device of first type is travelling on, wherein on receiving the traffic tips the electronic device of first type will render it depending on its capabilities so that the user/commuter will be informed in advance of a traffic/congestion situation in a given location.
20. The said electronic device of first type being part of a context-capturing framework according to claim I or any preceding claim, wherein the said electronic device of first type takes extra functionalities by possessing a speaker configured to playback any received audio signal, an electronic visual display unit configured to playback any received video signal in an appropriate format, and a set of on-screen or physical keys/buttons to get user inputs in connection with volume control, picture quality control and the like and said server maintains connectivity with a content database containing variety of multimedia contents, wherein the said extra functionalities comprising: i) each electronic device of first type periodically updating the said centralised server with an absolute geographical location along with the device-specific unique identifier unless it actively gets involved in the traffic judging procedure periodically updating the said server with the said three-tuple information; ii) the said server application liaising with the said content database to regularly push one or plurality of multimedia contents to each electronic device of first type depending on its instantaneous geographical location; and, iii) once received, each electronic device of first type rendering or playing back the multimedia content.
21. The said electronic device of first type being part of a context-capturing framework according to claim I or 20, wherein the said electronic device of first type takes extra functionalities by possessing a credit-card or mobile-wallet or rn-payment reader in order to support online purchases/reservations of goods and services by one or plurality of commuters of the said public transport facility.
22. There is provided a context capturing electronic system on a chip potentially formingfrealising or making up an electronic device of first type S. for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, where an electronic device of first type is mounted on the said one mode of public transport facility, and the system on a chip comprising: i) abus, ii) a peripheral controller being coupled to said bus for coimecting one or plurality of 1/0 peripheral devices depending on the requirements; iii) one or plurality of microprocessors being coupled to said bus to provide control functions to the said electronic device of first type; iv) a communication controller being coupled to said bus for connecting to one or plurality of communication interfaces; v) a memory that is coupled to said bus into which a plurality of instructions are loaded; and, vi) a mechanism to determine the absolute geographical location information of the said electronic device of first type; wherein the said electronic device is part of a context-capturing framework that comprises: a) a server that has a profile-repository and other online databases and a server application running continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being registered successfully; b) a communication network which allows the said electronic device of first type to maintain intermittent connectivity with the said server via a communication interface of first type; wherein using a user interface of first type being provided by the said electronic device of first type the said system on chip allowing the user to advertise hislher current geographical location with the centralised server automatically with a click of a button.
23. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22, wherein each of the said electronic devices of first type needs to be always physically and logically associated/tied with a given vehicle being used to provide one mode of public transport facility where the said electronic device of first type is going to capture context information.
24. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 23, wherein the physical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by physically mounting the said electronic device of first type at the appropriate place in the given vehicle.
25. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 23, wherein the logical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by creating and activating a unique profile in the said profile-repository of the said centralised server and the said unique profile is specific to a given vehicle and the electronic device of first type.
26. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 25, wherein the said electronic device of first type comprises a device-specific unique identifier (i.e., device-ID) that is globally unique for the user to use it at the time of logical association.
27. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility andJor the commuters that travel therein according to claim 22 or 26, wherein the owner/driver of the public transport facility is expected to create, maintain and activate an on-line profile per vehicle being used for public transport in the said profile-repository of the said server of the said context-capturing framework, wherein the profile can be created using any personal computer that can connect to the said server via the Internet on typing the correct IJRL of the said server and the user is expected to give unique information pertaining to a given vehicle and the electronic device of first type pair.
28. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility andlor the commuters that travel therein according to claim 22 or 27, wherein every profile being maintained in the said centralised profile-repository will keep public transport vehicle specific details such as the vehicle registration number, country of registration, current absolute geographical location, current timestamp, colour of the vehicle, usual fare per distance, availability status for a hirelride, contact number, device-specific unique identifier pertaining to the said electronic device of first type being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like. and this profile creation process requires the oier of the publ ic transport ogin credentials namely the preferred user name/password that are specific to one vehicle and hence to one electronic device of first type.
29. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 27, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creation! maintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.
30. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 29, with its microprocessor containing the software stack, wherein the said software stack comprising functionalities for: i) connection management enabling the establishment of connection with the said server application; ii) traffic condition calculation and reporting; iii) public transport facility availability reporting/advertisement; iv) other miscellaneous functionalities pertaining to displaying fare infonnation, session management, multimedia rendering and the like; v) application layer and a variety of multimedia applications.
31. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 30. with its microprocessor running an appropriate software stack and the electronic device of first type possesses green LED and red LED on the exterior side being connected to the said peripheral controller, wherein the said connection management functionality of the said software stack will automatically contact the said ceniralised server when the said electronic device of first type is powered on, an LED indicator on the device will indicate the registration status depending on whether a corresponding profile already exists or not in the said profile-repository being maintained in the said centralised server such that: a) an automatic powering on of the said green LED indicating that one or more functionalities of the said software stack have already found a corresponding entry in the said profile-repository and the given electronic device of first type is ready to operate; or, b) an automatic powering on of the said red LED indicating that no corresponding entry exist centrally; wherein the device-specific unique identifier of the said electronic device of to search the profile-repository using the said device-specific unique identifier as the index.
32. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22 or 31, wherein on seeing that a corresponding entry exists in the said repository of the said centralised server, one or more functionalities of the said software stack will maintain connectivity with the server application running on the centralised server via the communication interface of first type for the purpose of periodically advertising the availability/unavailability status of a given mode of public transport facility along with the instantaneous location information when prompted by the user.
33. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22, wherein the mechanism to determine the absolute geographical location information of the electronic device of first type is any prevailing state of the art technologies such as Global Positioning System (GPS) and/or other mobile/wireless network assisted positioning, wherein the said electronic device of first type comprising a GPS receiver or any wireless transceiver being connected via the said communication controller.
34. The said context capturing electronic system on a chip potentially forming/reaiising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22, wherein the user interface of first type has only two electronic buttons/keys being connected via the said peripheral controller having the following features: i) one green buttonlkey known as the "availability" button; and, ii) one red button/key known as the "unavailability" button.
35. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22 or 34, wherein the said one mode of public transport facility is taxi/cab/taxicab service, wherein the said software stack of the said electronic system on a chip runs a public transport availability advertisement procedure allowing the taxi/cab/taxicab owner/driver to advertise the availability status of the taxi/cab/taxicab for a hire/ride in a given region and the said advertising procedure comprising the steps of: i) automatically cormecting to the said centralised server and checking whether a corresponding entry exists in the said profile-repository using the device-specific unique identifier as the index; ii) on having found a corresponding entry in the said profile-repository, turning on the green LED of the said electronic device of first type; otherwise turning on the red LED to indicate to the taxi/cab/taxicab owner/driver that a corresponding profile needs to be created in the said profile-repository; iii) beginning to listen to user inputs; iv) on recognising that the "availability" or "unavailability" button is pressed by the taxi/cab/taxicab owner/driver, determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said centralised server; wherein on being notified, the said server application of the said centralised server will look for a corresponding entry in the said repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" or "being unavailable" for a hire/ride respectively depending on the type of button pressed by the taxi/cab/taxicab owner/driver and update the absolute geographical location and the corresponding time stamp.
36. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its S microprocessor running an appropriate software stack according to claim 22 or 35, where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said software stack of the said electronic system on a chip takes an extra traffic condition reporting functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said traffic condition reporting functionality of the said software stack to constantly run a timer of first type; ii) when a timeout occurs, getting the said traffic condition reporting functionality of the said software stack to calculate the current speedlvelocity of the vehicle to which the given electronic device of first type is physically and logically associated with, to determine the current absolute location of the given vehicle by liaising with the said mechanism that determines the absolute geographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of electronic devices of first type, getting the said server application running on the said centralised server to: a) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further traffic/congestion calculation only when the reported speed/velocity pertains to a road, street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d) to calculate the moving average velocity using the received updates from other electronic devices of first type pertaining to the same segment of a given road/street/highway/motorway or the like that are still non-stale and are currently cached in the traffic database; e) to liaise with the traffic database and temporarily cache the calculated moving average velocity in the said traffic database against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced with a new entry or times-out; and, f) gethng the said server application to accompany the time stamp with each cached moving average velocity information being stored in the traffic database; wherein the said software stack of the said electronic system on a chip running the said traffic condition reporting procedure to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestion/traffic database of a given road, Street, highway, motorway and the like.
37. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22 or 35, wherein the said electronic system on a chip takes extra functionalities by possessing a number of peripheral devices being connected via the said peripheral controller to the said bus, and the said peripheral devices comprise a speaker configured to playback any received audio signal, an electronic visual display unit configured to playback any received video signal in an appropriate format, and a set of on-screen or physical keys/buttons to get user and said server maintains connectivity a content database containing variety of multimedia contents; wherein the said extra functionalities comprising: i) each electronic device of first type periodically updating the said centralised server with context information pertaining to one mode of public transport facility and/or the commuters that travel therein; ii) the said server application liaising with the said content database to regularly push one or plurality of multimedia contents to each electronic device of first type depending on its instantaneous context information; and, iii) once received, each electronic device of first type rendering or playing back the multimedia content.
38. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22, wherein the said electronic system on a chip takes extra functionalities by possessing a number of peripheral devices being connected via the said peripheral controller to the said bus, and the said peripheral devices comprise a credit-card or mobile-wallet or rn-payment reader in order to support online purchases/reservations of goods and services.
39. There is provided a method for transforming an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionafitjes namely: i) a wireless transceiver providing a communication interface of first type; ii) an electronic visual display unit that can provide the required graphical user interface; iii) a mechanism to determine the absolute geographical location information of the said existing mobile phone, smartphone or similar electronic device; through a purpose-built software running on the said mobile phone, smart-phone or similar electronic device in order to enable them to be part of a context-capturing framework in the capacity of context-reporting mobile clients and the said context-capturing framework comprising: a) a server that has a profilerepository and other online databases and a server application running continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being registered successfully; b) a communication network which allows the said existing mobile phone, smartphone or similar electronic device to maintain intermittent connectivity with the said server via a communication interface of first type; 20. wherein forming a context-capturing framework in order to capture the required context information pertaining to one mode of public transport facility and/or the commuters that travel therein has a preset setup the steps of i) the driver/owner of a given vehicle being used to provide one mode of public transport facility physically associating the said existing mobile phone, smartphone or similar electronic device with the said vehicle by mounting at the appropriate place of the said vehicle; ii) the driver/owner creating and maintaining a corresponding profile pertaining to the given taxi vehicle by specifying the taxi details with the centralised server using a personal computer and the world wide web; iii) on the driver/owner successfully activating a vehicle-specific profile in the centralised server, the said server creating login credentials and assigning a unique alphanumeric identifier to the registered vehicle; iv) the driver/owner turning the physically associated existing mobile phone, smartphone or similar electronic device on and logically associating it with the given taxi vehicle by signing on with the said centralised server using the login credentials and the said server assigned unique alphanumeric identifier by getting the said purpose built software running on the said existing mobile phone, smartphone or similar electronic device to provide the necessary graphical user interface; v) on signing on, the purpose-built software running on the said existing mobile phone. smartphone or similar electronic device contacting the centralised server and locating the maintained profile using the said server generated unique alphanumeric identifier; vi) on successfiully locating a corresponding profile with the centralised server, the said purpose-built software displaying that the said existing mobile

-phone, smartphone or similar electronic device is ready for it to be used as part of the said context-capturing framework on the graphical user interface, while activating two keys -one for advertising the availability of a given vehicle for a hire/ride and the other for advertising the unavailability of the given vehicle for a hire/ride; Vii) on recognising that the "availability"/"unavailabifity" button is pressed by the taxi owner/driver, the said purpose-built software determining the current absolute geographical location of the said existing mobile phone, smartphone or similar electronic device by liaising with the said mechanism that determines the location and passing the determined location information on to the said centralised server along with the said server assigned unique alphanumeric identifier;
40. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim 39, wherein every profile being maintained in the said centralised profile-repository will keep public transport vehicle specific details such as the vehicle registration number, country of registration, current absolute geographical location, current timestamp, colour of the vehicle, availability status for a hire/ride, usual fare per distance, contact number, server assigned unique alphanumeric identifier pertaining to the said existing mobile phone, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like.
41. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim 39, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creation/maintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.
42. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim 39, wherein the said existing mobile phone, smartphone or similar electronic device uses GPS to determine the absolute geographical location.
43. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim 39, wherein the said communication network that allows the said existing mobile phone, smartphone or similar electronic device to maintain intermittent connectivity with the said server can be WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like, and the associated communication interface 4a of first type is the main air interface of the WiFi, WiMAX, GPRS, UMTS, LTE, LIE-A or the like respectively.
44. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardwarelsoftware functional ities to be part of a context-capturing framework according to ci aim 39, where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said purpose-built software running on the said existing mobile phone, sniartphone or similar electronic device takes an extra functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said purpose-built software running on the said existing mobile phone, smartphone or similar electronic device to constantly run a timer of first type; ii) when a timeout occurs, getting the said purpose-built software to calculate the current speed/velocity of the vehicle to which the said existing mobile phone, smartphone or similar electronic device is physically and logically associated with, to determine the current absolute geographical location of the given vehicle by liaising with the said mechanism that determines the absolute geographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographical iii) on receiving the said three-tuple information from one or plurality of said existing mobile phones, smartphones or similar electronic devices, getting the said server application running on the said centralised server to: a) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further traffic/congestion calculation only when the reported speed/velocity pertains to a road, street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d) to calculate the moving average velocity using the received updates from one or plurality of said existing mobile phones, smartphones or similar electronic devices pertaining to the same segment of a given road/street/highway/motorway or the like that are still non-stale and are currently cached in the traffic database; e) to liaise with the traffic database and temporarily cache the calculated moving average velocity in the said traffic database against the segment of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced with a new entry or times-out; and, t) getting the said server application to accompany the time stamp with each cached moving average velocity information being stored in the traffic database; wherein by getting the said purpose-built software to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestionltraffic database of a given road, street, highway, motorway and the like, Amendments to the claims have been filed as follows Claims 1. There is provided an electronic device of first type to capture context information pertaining to one mode of public transport facility and/or the commuters that travel therein, and the said electronic device of first type comprising: i) a wireless transceiver providing a communication interface of first type; ii) a mechanism to determine the absolute geographical location information of the said electronic device of first type; wherein the said electronic device is part of a context-capturing framework that comprises: a) a server that has a profile-repository and other online databases and a server application running continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being registered successfully; b) a communication network which allows the said electronic device of first S. 0.type to maintain intermittent connectivity with the said server via a * communication interface of first type; S...:: : . wherein the said electronic device of first type provides a user interface of *..* : :* 20 first type allowing the owner/driver of a public transport facility such as taxi, cab, and the like to advertise the availability of his/her taxi/cab/taxicab for a **...0S Shire/ride on a centralised server (and the associated repository) with the current location information with a click of a button/key.2.. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein each of the said electronic devices of first type needs to be always physically and logically associated/tied with a given vehicle being used to provide one mode of public transport facility where the said electronic device of first type is going to capture context information.3. The said electronic device of first type being part of a context-capturing framework according to claim I or 2, wherein the physical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by physically mounting the said electronic device of first type at the appropriate place in the given vehicle.4. The said electronic device of first type being part of a context-capturing framework according to claim I or 2, wherein the logical *0� association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by creating and activating a unique profile in the said profile-repository of the: *-S Se..said centralised server and the said unique profile is specific to a given vehicle S. S and the electronic device of first type. :, *5SS** * S 5. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 4, wherein the said electronic device of first type comprises a device-specific unique identifier (i.e., device-ID) that is globally unique for the user to use it at the time of logical association.6. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 5, wherein the owner/driver of the public transport facility is expected to create, maintain and activate an on- line profile per vehicle being used for public transport in the said profile-repository of the said server of the said context-capturing framework, wherein the profile can be created using any personal computer that can connect to the said server via the Internet on typing the correct 1.JRL of the said server and the user is expected to give unique information pertaining to a given vehicle and the electronic device of first type pair.7. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 6, wherein every profile being * :: :: maintained in the said centralised profile-repository will keep public transport 0I**S. . . . * * vehicle specific details such as the vehicle registration number, country of * ::: : registration, current absolute geographical location, current timestamp, colour **..of the vehicle, usual fare per distance, availability status for a hire/ride, contact number, device-specific unique identifier pertaining to the said **.S.S * electronic device of first type being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like, and this profile creation process requires the owner of the public transport to create login credentials namely the preferred user namelpassword that are specific to one vehicle and hence to one electronic device of first type.8. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 7, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creationf maintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.9. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 8, wherein the said electronic -device of first runs a client application and the electronic device of first type possesses green LED and red LED on the exterior side, wherein the said client application will automatically contact the said centralised server when the S...said electronic device of first type is powered on, and the LED indicators on Se....the device will indicate the registration status of the given electronic device of *5** first type depending on whether a corresponding profile already exists or not: *5SC * S S...in the said profile-repository being maintained in the said centralised server *, e * . S such that;S* S*S** * * a) an automatic powering on of the said green LED indicating that the said client application has already found a corresponding entry in the said profile-repository and the given electronic device of first type is ready to operate; or, b) an automatic powering on of the said red LED indicating that no corresponding entry exist centrally; wherein the device-specific unique identifier of the said electronic device of first type is passed on to the server application by the said client application for the said server application to search the profile-repository using the said device-specific unique identifier as the index.10. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 9, wherein the said electronic device of first runs a client application and on seeing that a corresponding entry exists in the said profile-repository of the said centralised server, the said client application will maintain connectivity with the server application running on the centralised server via the communication interface of first type for the purpose of periodically advertising the availability/unavailability status of a given mode of public transport facility along with the instantaneous location information when prompted by the user. * * *S*.* * 11. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein the mechanism to ***.* 20 determine the absolute geographical location information of the electronic :.: : device of first type is any of the prevailing state of the art technologies such as * * Global Positioning System (GPS) and other mobile/wireless network assisted positioning, wherein the said electronic device of first type comprising a GPS receiver or any wireless transceiver.12. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein the said* communication network that allows the said electronic device of first type to maintain intermittent connectivity with the said server can be WiFi, W1MAX, GPRS, UMTS, LTE, LTE-A or the like, and the associated communication interface of first type is the main air interface of the WiFi, WIMAX,' GPRS, UMTS, LTE, LTE-A or the like respectively.13. The said electronic device of first type being part of a context-capturing framework according to any preceding claim, wherein the user interface of first type has only two electronic/soft buttons/keys having the following features: i) one green button/key known as the "availability" button; and, ii) one red button/key known as the "unavailability" button.14. The said electronic device of first type being part of a context-S...capturing framework according to any preceding claim, wherein the said one *5 mode of public transport facility is taxi/cab/taxicab service, wherein the 5..taxi/cab/taxicab owner/driver can advertise the availability status of the: * *5*S * e..taxi/cab/taxicab for a hire/ride in a given region by performing the advertisingSprocedure comprising the steps of: :.: i) mounting the said electronic device of a first type in the appropriate place of the taxi/cab/taxicab vehicle (i.e., the physical association); I.-157 ii) creating and maintaining a corresponding profile pertaining to the given taxilcab/taxicab vehicle and the said electronic device of first type being mounted therein by specifying the taxi/cab/taxicab details as well as the device-specific unique identifier of the electronic device of first type (i.e., the logical association); iii) turning on the electronic device of first type and waiting till the green LED on the electronic device of first type to be automatically turned on; if not, a corresponding profile needs to be created online and activated; iv) on noticing a green LED being lit on the electronic device of first type, the taxi/cab/taxicab driver/owner pressing the said "availability" button to advertise the availability status of a given taxi/cab/taxicab for a hire/ride; and, v) on recognising that the "availability" button is pressed by the taxi/cab/taxicab owner/driver, the said client application determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said centralised * S server; I...wherein on being notified the said server application of the said centralised S...* : 20 server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the ***S 55 * S server application will change the taxi/cab/taxicab availability status to "being available" for a hire/ride and update the absolute geographical location and the corresponding time stamp.15. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 14, wherein the said one mode of public transport facility is taxi/cabltaxicab service, wherein the taxilcab/taxicab ownertdriver can advertise the unavailability status of the taxiicabltaxicab for a hire/ride in a given region by pressing the said "unavailability" button/key of the said electronic device of first type on noticing that the device is ready to be used, wherein on recognising that the "unavailability" button is pressed by the taxi/cab/taxicab owner/driver, the said client application passing the device-specific unique identifier of the said electronic device of first type on to the said centralised server, wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the deviàe-.specific unique identifier as the index and on being found, the server S...application will change the taxi/cab/taxicab availability status to "being *5I*l unavailable" for a hire/ride and update the corresponding time stamp. * . . * *S * *5**16. The said electronic device of first type being part of a context-*S capturing framework according to claim 1 or 14, wherein the said electronic *.device of first type enables taxi/cab/taxicab drivers to automatically advertise their availability for a hire/ride along with their geographical positions through the said centralised server, wherein if the said client application can determine that a given taxilcab/taxicab has been parked in a particular location for more than a given time-limit, then this taxi/cab/taxicab's availability for a hire/ride will be automatically advertised without having to click any button unless the taxi/cab/taxicab owner/driver has already pressed the "unavailability button", wherein the said client application determining the current absolute geographical location of the electronic device of first type by liaising with the said mechanism that determines the location and passing the device-specific unique identifier of the said electronic device of first type along with the determined location information on to the said centralised server, wherein on being notified the said server application of the said centralised server will look for a corresponding entry in the said profile-repository using the device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" for a hire/ride and update the corresponding time stamp. I...17. The said electronic device of first type being part of a context- * capturing framework according to claim 1, wherein the electronic device of S...: first type can also function as a fare meter for a commuter and/or as a toll box *S.. * S *5**for road pricing and/or has a printer functionality to print the receipt out. * *1 * . . *.* .*..eS.* 18. The said electronic device of first type being part of a context-capturing framework according to claim 1, wherein the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said client application running on the electronic device of first type takes an extra functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said client application to constantly run a timer of first type; ii) when a timeout occurs, getting the client application to calculate the current speedlvelocity of the vehicle to which the given electronic device, of first type is physically and logically associated with, to determine the current absolute geographical location of the given vehicle by liaising with the said mechanism that determines the absolute geographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from. one or plurality of electronic devices of first type, getting the said server application running on the said centralised server to: S... *5*Sa) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further: : : traffic/congestion calculation only when the reported speed/velocity S...pertains to a* road, street, highway or the like and is non-zero or the * *SS reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d) to calculate the moving average velocity using the received updates from other electronic devices of first type pertaining to the same segment of a given road/street/highway/motorway or the like that are still non-stale and are currently cached in the traffic database; e) to liaise with the traffic database and temporarily cache the calculated moving average velocity in the said traffic database against the segment of a road, Street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced * 15 with a new entry or times-out; and, f) getting the said server application to accompany the time stamp with 0*0* 00 each cached moving average velocity information being stored in the * traffic database; 0*I* wherein by getting the said client application running on each of said I...electronic device of first type to update the said centralised server with the said three-tuple information, the corresponding functionality of the server * 0 application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestioni'traffic database of a given road, street, highway, motorway and the like.19. The said electronic device of first type being part of a context-capturing framework according to claim 1 or 18, wherein the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said server application will take an extra functionality to liaise with the said profile-repository and said navigation map with an objective to inject traffic tips to every electronic device of first type that periodically notifies its instantaneous absolute geographical position information in case the calculated moving average velocity is much lower than the speed limit being set to a given segment of a roadlstreet/highway/motorway or the like where a given vehicle carrying a given electronic device of first type is travelling on, wherein on receiving the traffic tips the electronic device of first type vill render it depending on its capabilities so that the user/commuter will be informed in 1.1. -* *S** advance of a traffic/congestion situation in a given location. * S *5S20. The said electronic device of first type being part of a context-* S...capturing framework according to claim 1 or any preceding claim, wherein the said electronic device of first type takes extra functionalities by possessing a speaker configured to playback any received audio signal, an electronic visual display unit configured to playback any received video signal in an appropriate format, and a set of on-screen or physical keys/buttons to get user inputs in connection with volume control, picture quality control and the like and said server maintains connectivity with a content database containing variety of multimedia contents, wherein the said extra functionalities comprising: i) each electronic device of first type periodically updating the said centralised server with an absolute geographical location along with the device-specific unique identifier unless it actively gets involved in the traffic judging procedure periodically updating the said server with the said three-tuple information; ii) the said server application liaising with the said content database to regularly push one or plurality of multimedia contents to each electronic device of first type depending on its instantaneous geographical location; and, iii) once received, each electronic device of first type rendering or playing back the multimedia content.21. The said electronic device of first type being part of a context-*S."I., capturing framework according to claim 1 or 20, wherein the said electronic device of first type takes extra functionalities by possessing a credit-card or S..... : mobile-wallet or rn-payment reader in order to support online S... S *purchases/reservations of goods and services by one or plurality of commuters a *, of the said public transport facility.S22. There is provided a context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein, where an electronic device of first type is mounted on the said one mode of public transport facility, and the system on a chip comprising: S i) abus, ii) a peripheral controller being coupled to said bus for connecting one or plurality of 110 peripheral devices depending on the iequirements; iii) one or plurality of microprocessors being coupled to said bus to provide control functions to the said electronic device of first type; iv) a communication controller being coupled to said bus for connecting to one or plurality of communication interfaces; v) a memory that is coupled to said bus into which a plurality of instructions are loaded; and, vi) a mechanism to determine the absolute geographical location information of the said electronic device of first type; wherein the said electronic device is part of a context-capturing framework * aP.that comprises:Ia) a server that has a profile-repository and other online databases and a server application running continuously, and the said profile-repository maintaining:1 a::, I...profile information pertaining to every public transport vehicle being * *.I registered successfully; b) a communication network which allows the said electronic device of first type to maintain intermittent connectivity with the said server via a communication interface of first type; wherein using a user interface of first type being provided by the said electronic device of first type the said system on chip allowing the owner/driver of a public transport facility such as taxi, cab, and the like to advertise the availability of his/her taxilcab/taxicab for a hire/ride on a centralised server (and the associated repository) with the current location information with a click of a button/key.23. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22, wherein each of the said electronic devices of first type needs to be always physically and logically associated/tied with a given vehicle being used to provide one mode of public transport facility where the said electronic device * ***.* of first type is going to capture context information. I... * * S S. S S...24. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the I ** i * 5 purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 23, wherein the physical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by physically mounting the said electronic device of first type at the appropriate place in the given vehicle.25. The said context capturing electronic system on a chip potentially forminglrealising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 23, wherein the logical association between one of the said electronic devices of first type and a given vehicle being used to provide one mode of public transport facility takes place by creating and activating a unique profile in the said profile-repository of the said centralised server and the said unique profile is specific to a given vehicle and the electronic device of first type.26. The said context capturing electronic system on a chip potentially forrning/realising. or making up an electronic device of first type for the * *) a.purpose of capturing context information pertaining to one mode of public a.....transport facility and/or the commuters that travel therein according to claim a...22 or 25, wherein the said electronic device of first type comprises a device: * *�SI * a specific unique identifier (i.e., device-ID) that is globally unique for the user a. a * . a to use it at the time of logical association. . aa a S27. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 26, wherein the owner/driver of the public transport facility is expected to create, maintain and activate an on-line profile per vehicle being used for public transport in the said profile-repository of the said server of the said context-capturing framework, wherein the profile can be created using any personal computer that can connect to the said server via the Internet on typing the correct URL of the said server and the user is expected to give unique information pertaining to a given vehicle and the electronic device of first type pair.28. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 27, wherein every profile being maintained in the said centralised **Q.* profile-repository will keep public transport vehicle specific details such as the vehicle registration number, country of registration, current absolute *. 0 * **. geographical location, current timestamp, colour of the vehicle, usual fare per * : 20 distance, availability status for a hire/ride, contact number, device-specific : unique identifier pertaining to the said electronic device of first type being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like, and this profile creation process requires the owner of the public transport to create login credentials namely the preferred user name/password that are specific to one vehicle and hence to one electronic device of first type.29. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility andlor the commuters that travel therein according to claim 22 or 27, wherein the said server application running on the said centralised server is responsible for a multitude of functionalities and one of which is the profile creation! maintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.30. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 29, with its microprocessor containing the software stack, wherein the Se a...said software stack comprising functionalities for: i) connection management enabling the establishment of connection with theSsaid server application; ii) traffic condition calculation and reporting; iii) public transport facility availability reporting/advertisement; iv) other miscellaneous functionalities pertaining to displaying fare information, session management, multimedia rendering and the like; v) application layer and a variety of multimedia applications.31. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein according to claim 22 or 30, with its microprocessor running an appropriate software stack and the electronic device of first type possesses green LED and red LED on the exterior side being connected to the said peripheral controller, wherein the said connection management functionality of the said software stack will automatically contact the said centralised server when the said electronic device of first type is powered on, an LED indicator on the device will indicate the registration status depending on whether a corresponding profile already exists or not in the said profile-repository being maintained in the said *..S centralised server such that: a) an automatic powering on of the said green LED indicating that one or S...more functionalities of the said software stack have already found a corresponding entry in the said profile-repository and the given electronic : device of first type is ready to operate; or, b) an automatic powering on of the said red LED indicating that no corresponding entry exist centrally; wherein the device-specific unique identifier of the said electronic device of first type is passed on to the server application for the said server application to search the profile-repository using the said device-specific unique identifier as the index.32. The said context capturing electronic system on a chip potentially fonning/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22 or 31, wherein on seeing that a corresponding entry exists in the said repository of the said centralised server, one or more functionalities of the said software stack will maintain connectivity with the server application running on the centralised server via the communication interface of first type for the purpose of periodically advertising the availability/unavailability status of a given mode of public transport facility along with the instantaneous *Slocation information when prompted by the user. S S... * S * *5 *5*S33. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22, wherein the mechanism to determine the absolute geographical location information of the electronic device of first type is any prevailing state of the art technologies such as Global Positioning System (GPS) and/or other mobile/wireless network assisted positioning, wherein the said electronic device of first type comprising a GPS receiver or any wireless transceiver being connected via the said communication controller.34. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22, wherein the user interface of first type has only two electronic buttons/keys being connected via the said peripheral controller having the following features: i) one green button/key known as the "availability" button; and, * ii) one red button/key known as the "unavailability" button. S...*S.... * S35. The said context capturing electronic system on a chip potentially S * * ** S fortuing/realising or making up an electronic device of first type for the : 20 purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22 or 34, wherein the said one mode of public transport facility is taxi/cab/taxicab service, wherein the said software stack of the said electronic system on a chip runs a public transport availability advertisement procedure allowing the taxi/cabltaxicab owner/driver to advertise the availability status of the taxi!cabftaxicab for a hire/ride in a given region and the said advertising procedure comprising the steps of: i) automatically connecting to the said centralised server and checking whether a corresponding entry exists in the said profile-repository using the device-specific unique identifier as the index; ii) on having found a corresponding entry in the said profile-repository, turning on the green LED of the said electronic device of first type; otherwise turning on the red LED to indicate to the taxi/cab/taxicab ownerldriver that a corresponding profile needs to be created in the said profile-repository; iii) beginning to listen to user inputs; iv) on recognising that the "availability" or "unavailability" button is pressed by the taxilcabltaxicab owner/driver, determining the current absolute geographical location of the electronic device of first type by liaising with the * ..* said mechanism that determines the location and passing the device-specific **.unique identifier of the said electronic device of first type along with the * 0 determined location information on to the said centralised server; **** wherein on being notified, the said server application of the said centralised 0S * * server will look for a corresponding entry in the said repository using the 0 * 0000 device-specific unique identifier as the index and on being found, the server application will change the taxi/cab/taxicab availability status to "being available" or "being unavailable" for a hire/ride respectively depending on the P 173 type of button pressed by the taxilcab/taxicab owner/driver and update the absolute geographical location and the corresponding time stamp.36. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22 or 35, where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said software stack of the said electronic system on a chip takes an extra traffic condition reporting functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said traffic condition reporting functionality of the said software stack to constantly run a timer of first type; *::::* ii) when a timeout occurs, getting the said traffic condition reporting functionality of the said software stack to calculate the current speed/velocity * : of the vehicle to which the given electronic device of first type is physically *SS.S... and logically associated with, to determine the current absolute location of the : :* 20 given vehicle by liaising with the said mechanism that determines the absoluteS *...Sgeographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of electronic devices of first type, getting the said server application running on the said centralised server to: a) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further traffic/congestion calculation only when the reported speed/velocity pertains to a road, street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; d) to calculate the moving average velocity using the received updates * ..* * from other electronic devices of first type pertaining to (lie same segment of a given road/street/highway/motorway or the like that are still non-stale arid are currently cached in the traffic database; : 0*0 e) to liaise with the traffic database and temporarily cache the calculated 0* moving average velocity in the said traffic database against the segment 0 * S of a road, street, highway, motorway or the like to which it is applicable until the calculated moving average velocity is replaced with a new entry or times-out; and, f) getting the said server application to accompany the time stamp with each cached moving average velocity information being stored in the traffic database; wherein the said software stack of the said electronic system on a chip running the said traffic condition reporting procedure to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestion/traffic database of a given road, street, highway, motorway and the like.37. The said context capturing electronic system on a chip potentially forming/realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility andIor the commuters that travel therein with its microprocessor running an appropriate software stack according to claim 22 **S.or 35, wherein the said electronic system on a chip takes extra functionalities by possessing a number of peripheral devices being connected via the said **S.*... peripheral controller to the said bus, and the said peripheral devices comprise *: 20 a speaker configured to playback any received audio signal, an electronicS*S*** . . . . . visual display unit configured to playback any received video signal in an appropriate format, and a set of on-screen or physical keys/buttons to get user inputs in connection with volume control, picture quality control and the like and said server maintains connectivity a content database containing variety of multimedia contents; wherein the said extra functionalities comprising: i) each electronic device of first type periodically updating the said centralised server with context information pertaining to one mode of public transport facility and/or the commuters that travel therein; ii) the said server application liaising with the said content database to regularly push one or plurality of multimedia contents to each electronic device of first type depending on its instantaneous context information; and, iii) once received, each electronic device of first type rendering or playing back the multimedia content.38. The said context capturing electronic system on a chip potentially forming)realising or making up an electronic device of first type for the purpose of capturing context information pertaining to one mode of public transport facility and/or the commuters that travel therein with its *.fl microprocessor running an appropriate software stack according to claim 22, *SISS wherein the said electronic system on a chip takes extra functionalities by S..possessing a number of peripheral devices being connected via the said periheral controller to the said bus, and the said peripheral devices comprise S's.a credit-card or mobile-wallet or rn-payment reader in order to support online, :. *5555purchases/reservatIons of goods and services. I 17739. There is provided a method for transforming an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities namely: i) a wireless transceiver providing a communication interface of first type; ii) an electronic visual display unit that can provide the required graphical user interface; iii) a mechanism to determine the absolute geographical location information of the said existing mobile phone, smartphone or similar electronic device; through a purpose-built software running on the said mobile phone, smart-phone or similar electronic device in order to enable them to be part of a context-capturing framework in the capacity of context-reporting mobile clients and the said context-capturing framework comprising: a) a server that has a profile-repository and other online databases and a server application running continuously, and the said profile-repository maintaining profile information pertaining to every public transport vehicle being registered successfully; * * b) a communication network which allows the said existing mobile phone, *.S.: smartphone or similar electronic device to maintain intermittent connectivity ***.* with the said server via a communication interface of first type; *: * 20 wherein forming a context-capturing framework in order to capture the S....required context information pertaining to one mode of public transport facility andlor the commuters that travel therein has a preset setup procedure/methodology comprising the steps of: i) the driver/owner of a given vehicle being used to provide one mode of public transport facility physically associating the said existing mobile phone, smartphone or similar electronic device with the said vehicle by mounting at the appropriate place of the said vehicle; ii) the driver/owner creating and maintaining a corresponding profile pertaining to the given taxi vehicle by specifying the taxi details with the centralised server using a personal computer and the world wide web; iii) on the driver/owner successfully activating a vehicle-specific profile in the centralised server, the said server creating login credentials and assigning a unique alphanumeric identifier to the registered vehicle; iv) the driver/owner turning the physically associated existing mobile phone, smartphone or similar electronic device on and logically associating it with the given taxi vehicle by signing on with the said centralised server using the login credentials and the said server assigned unique alphanumeric identifier by getting the said purpose built software running on the said existing mobile I... * Sphone, smartphone or similar electronic device to provide the necessary * *SSS.: * S graphical user interface; S...v) on signing on, the purpose-built software running on the said existingS-*5SS mobile phone, smariphone or similar electronic device contacting the S. centralised server and locating the maintained profile using the said server * :5 S....generated unique alphanumeric identifier; vi) on successfully locating a corresponding profile with the centralised server, the said purpose-built software displaying that the said existing mobile phone, smartphone or similar electronic device is ready for it to be used as part of the said context-capturing framework on the graphical user interface, while activating two keys -one for advertising the availability of a given vehicle for a hire/ride and the other for advertising the unavailability of the given vehicle for a hire/ride; vii) on recognising that the "availability"/"unavailability" button is pressed by the taxi owner/driver, the said purpose-built software determining the current absolute geographical location of the said existing mobile phone, smartphone or similar electronic device by liaising with the said mechanism that determines the location and passing the determined location information on to the said centralised server along with the said server assigned unique alphanumeric identifier; 40. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim *S.* 39, wherein every profile being maintained in the said centralised profile-repository will keep public transport vehicle specific details such as theS S...vehicle registration number, country of registration, current absolute : 20 geographical location, current timestamp, colour of the vehicle, availability * status for a hire/ride, usual fare per distance, contact number, server assigned unique alphanumeric identifier pertaining to the said existing mobile phone, smartphone or similar electronic device being mounted on the given vehicle, and extra features indicating whether the given vehicle has air-conditioning, WiFi facilities and the like.41. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim 39, wherein the said server application running on the* said centralised server is responsible for a multitude of functionalities and one of which is the profile creation/maintenance task wherein the server application maintains each vehicle specific entry of the said profile-repository.42. The said method enablin an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim 39, wherein the said existing mobile phone, smartphone or similar electronic device uses GPS to determine the absolute geographical location. * . *S* * * * 43. The said method enabling an existing mobile phone, smartphone or * . * . . similar electronic device having the necessary hardware(software * functionalities to be part of a context-capturing framework according to claim * ** 39, wherein the said communication network that allows the said existing mobile phone, smartphone or similar electronic device to maintain intermittent connectivity with the said server can be WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like, and the associated communication interface of first type is the main air interface of the WiFi, WiMAX, GPRS, UMTS, LTE, LTE-A or the like respectively.44. The said method enabling an existing mobile phone, smartphone or similar electronic device having the necessary hardware/software functionalities to be part of a context-capturing framework according to claim 39, where the said centralised server contains a navigation map of a given serving region and maintains a traffic database for the given serving region, wherein the said purpose-built software running on the said existing mobile phone, smartphone or similar electronic device takes an extra functionality for the purpose of judging the traffic situation of a given location, and this traffic judging procedure comprising the steps of: i) getting the said purpose-built software running on the said existing mobile phone, smartphone or similar electronic device to constantly run a timer of first type; *****. ii) when a timeout occurs, getting the said purpose-built software to calculateSS.....* the current speed/velocity of the vehicle to which the said existing mobile phone, smartphone or similar electronic device is physically and logically S...* associated with, to determine the current absolute geographical location of the : . 20 given vehicle by liaising with the said mechanism that determines the absolute Si...geographical location and to update the said centralised server with a three-tuple information consisting of speed/velocity, current absolute geographical location and the device-specific unique identifier; iii) on receiving the said three-tuple information from one or plurality of said existing mobile phones, smartphones or similar electronic devices, getting the said server application running on the said centralised server to: a) first check whether the reported speed/velocity pertains to a road, street, highway or the like, and to consider it for further traffic/congestion calculation only when the reported speed/velocity pertains to a road, Street, highway or the like and is non-zero or the reported speed/velocity pertains to a road, street, highway or the like and it is from a vehicle that moves at a zero speed; b) to deduce the velocity from the speed with the use of reported location and the navigation map; c) to cache 4-tuple information consisting of deduced velocity, current absolute geographical location, the device-specific unique identifier and the time-stamp in the traffic database along with a correct time-stamp; ci) to calculate the moving average velocity using the received updates from one or plurality of said existing mobile phones, smartphones or *sa e similar electronic devices pertaining to the same segment of a given roadlstreetfhighwayimotorway or the like that are still non-stale and are *0 * .. SS S...currently cached in the traffic database; I. e) to liaise with the traffic database and temporarily cache the calculated * I.., moving average velocity in the said traffic database against the segment of a road, street, highway, motorway or the like to which it is applicable I 183 until the calculated moving average velocity is replaced with a new entry or times-out; and, f) getting the said server application to accompany the time stamp with each cached moving average velocity information being stored in the traffic database; wherein by getting the said purpose-built software to update the said centralised server with the said three-tuple information, the corresponding functionality of the server application will deduce the velocity from the location information and this will lead to the creation of an online and centralised congestionltraffic database of a given road, street, highway, motorway and the like. a a * * a... * .S * S.. S... a S * I. a a