FI20030359A - Menetelmä ja järjestelmä työmatkaliikenteen kehittämiseksi - Google Patents

Description

Method and system for improving commuting traffic Menetelmä ja järjestelmä työmatkaliikenteen kehittämiseksi Metod och arrangemang för att utveckla trafiken pä arbetsresor

The present invention relates to a method and system for improving commuting traffic and particularly, for improving easiness and safety of the ride sharing when using mobile communication system.

Background of the invention

Traffic congestion costs as wasted time and in wasted gasoline $100 billion per year in USA alone. Carpooling is one of the possibilities to ease the flow of the traffic. Currently carpooling systems are more or less based on agreements between participants well ahead the trip. A lot has been done in metropolitan areas in USA to attract users for carpooling, but carpooling has not reached widespread acceptance among the commuters and its popularity has actually decreased in recent years.

According to the bureau of transport statistics 87.7% of 118 million workers in USA use private car as a principal mean of transportation to work (78.2% only driver in a car, 9.4% at least one passenger in a car). The percentage of carpoolers has decreased from 14.1% in year 1985 to 9.4% in year 1999.

According to a survey of San Francisco Bay Area Commute Patterns in 2001, 17% percent of the commuters in the area are using carpools already now, roughly 10% use public transportation, and 69% use single occupancy vehicle (SOV). The most common reasons for using the SOV mode for commuting are "no other way to get to work" (18% of SOV users), "work hours/work schedule" 16%, "travel time to work" 12%, while "privacy, not being dependent on the others, Come and go as I please, like to drive" consisted only 9% of SOV users as main reason for the commute mode choice. The average time saved using a carpool is 23 minutes (per direction). From all carpoolers 80% indicated that carpooling is saving time. The average travel distance and time of the commute are 17 miles and 34 minutes. Average travel distance for carpool users is 22 miles.

In US patent 4360875 a flexible-route transportation system, primarily utilizing privately owned vehicles to provide ridesharing transportation for the public, is described. Interactive communications terminals are provided through which drivers of the vehicles may rapidly transmit ride offers via a telecommunications network to a central operations coordinating station, equipped with a general-purpose programmable computer. Rider interactive communications terminals, located at public and private facilities, are also connected by the telecommunications network with the central coordinating station, permitting eligible members of the public to quickly request rides from one location to another. The central coordinating station matches the ride requests with the ride offers, on a trip-by-trip basis, comparing the driver's indicated origin, destination, seating requirements and time with the rider's requested origin, destination, seat availability and time. If .a ride offer and ride request can be matched within reasonable limits of space and time, the central coordinating station transmits to the driver the rider's identity and location and transmits to the rider the description and identity of the vehicle, so that the driver can pick up and drop off the rider en route to his or her destination. The system includes security features for preventing unauthorized access to the system by either drivers or riders, accounting features for properly billing riders and reimbursing vehicle owners for transportation services, and special terminals for entering trip information quickly and accurately.

Somewhat similar systems have been described in the US Patent Application Publication No: 2001/0037174 (Filed Apr. 4., 2001) that generally relates to an automated transit system, and more particularly to an urban transit system that minimizes the social costs of urban transportation, the transit system being based on digital cellular communication, GPS locating technology and digital computers to provide real-time command and control of passengers and vehicles.

In casual/real-time creation of carpools the participants are sharing a car with stranger. This creates a possible security risk for the carpool participants.

Summary of the invention

The present invention describes how a casual carpool can be set up and how the security of the participants can be increased without any complicated actions from the users. The invented method relies on the use of mobile communications devices in the setting up the carpool and solves two important issues: how the carried mobile devices can be used to increase the safety and how the system can confirm the identity of a person using the mobile communications device. Equally important for the system is that it introduces minimal amount of work for the carpool participants.

In the present invention it is described in details how the matching of the needs is done in real-time using mobile communications as well as how the easiness of use (needed messaging to set up the ride-sharing) is improved and the setting up the carpool is integrated to the features increasing the safety of carpoolers.

According to a first aspect of the invention a method is provided for arranging transportation for at least two persons by a same vehicle driven by one of said persons. Each of said persons has a communication device capable of establishing a communication connection to a server connected to a communication network. The communication devices can send and receive messages to and from said server. The method comprises at the server: - receiving registration information from a person, which registration information comprises at least an origination and a destination of at least one route to be transported, an identification identifying said person and registration to at least one of the following category: a driver of a vehicle and a passenger of a vehicle; - receiving a message from at least one registered driver, said message indicating a route of transportation, - receiving a message from at least one registered passenger, said message indicating a route of transportation, - matching one registered driver and at least one registered passenger having substantially similar route, - sending a message to said registered driver comprising at least identification and the route of said passenger, - sending a message to said at least one registered passenger comprising identification of said driver.

The method is characterized in that it comprises: - receiving a start message indicating successful start of transportation from said at least one registered passenger in response to successful identification of said driver, and - receiving an ending message indicating successful end of transportation from said at least one registered passenger.

According to a second aspect of the invention an electronic device is provided for arranging transportation for at least two persons by a same vehicle driven by one of said persons. The electronic device is essentially a server for implementing the method described above, so it is characteristic to the electronic device according to the invention that it comprises means for executing the steps of the method.

According to a third aspect of the invention a system is provided for arranging transportation for at least two persons by a same vehicle driven by one of said persons. The system is built essentially around a server for implementing the method described above, so it is characteristic to the system according to the invention that it comprises means for executing the steps of the method.

According to a fourth aspect of the invention a computer program product is provided for an electronic device for arranging transportation for at least two persons by a same vehicle driven by one of said persons. The computer program product is essentially a computer program to be stored into a program memory of a server according to the invention, so the characteristic features of the computer program product comprise means for causing the server to execute the steps of the method.

In the following, the invention will be described in greater detail with reference to the accompanying drawings, in which

Figure 1 a illustrates a system according to an embodiment of the invention;

Figure 1b illustrates a system according to another embodiment of the invention;

Figure 2 illustrates a flow diagram of registration to the system according to an embodiment of the invention;

Figure 3a illustrates a flow diagram of a method according to an embodiment of the invention;

Figure 3b illustrates a flow diagram of a method according to another embodiment of the invention;

Figure 4a illustrates a signaling diagram of a method according to an embodiment of the invention;

Figure 4b illustrates a signaling diagram of a method according to another embodiment of the invention;

Figure 5 illustrates a block diagram of a device according to an embodiment of the invention.

Detailed description of the invention

Figure 1a illustrates a system according to an embodiment of the invention. In the following the term SMS (Short Message Service) is used as an example of data transfer means. However, other techniques, such as multimedia messages (MMS; Multimedia Messaging Service), WAP (Wireless Application Protocol) or more advanced mobile Internet approaches can be used. Similarly the Mobile Station (MS) is used as an example of the mobile communications device.

The system comprises a centralized server 101 (a Carpool server) that is capable of communication with the other network elements, for example to mobile communication devices 102 and 103. In this exemplary illustration the communication devices 102 and 103 are operating in a GSM network. However a communication device disclosed hereinafter can also be other than a one operating in a GSM network. Other communication devices operating in different networks can be used as well when implementing the present invention. In the example set-up in figure 1a the server 101 is connected to a Short Message Service Center 104 (SMSC) allowing it to exchange short messages between it and MSs 102 and 103. Connection to the Internet 106 allows service profiles to be generated by users of MSs 102 and 103.

The operation of the system of figure 1a will be ..disclosed later in detail with . reference to figures 2 and 3a.

Figure 1b illustrates a system according to an alternative embodiment of the invention. The system comprises a centralized server 101 (a Carpool server) that is capable of communication with the other network elements, for example to MSs 102 and 103. In the example set-up in figure 1b the server 101 is connected to a Short Message Service Center 104 (SMSC) allowing it to exchange short messages between it and MSs 102 and 103. Connection to the Internet 106 allows service profiles to be generated by users of MSs 102 and 103.

The system can further comprise e.g. the Gateway Mobile Location Center 105 (GMLC) that can provide location information on Mobile Stations 102 and 103 to the Carpool server 101 it is connected to. In the case of detected emergency situation connections to Public Safety Answering Points 107 (PSAP), such as the police, etc. are provided. GMLC is used as a generic name for a network element or feature in the passenger's or driver's MS capable for providing a location estimate of the said Ms to a server connected to a communications network.

The capabilities to calculate the location of mobile communication devices (MS) are opening the possibility to collect a large amount of data about the movements of individuals. Most likely a majority of people would find the location tracking of their MS as a violation of their privacy and therefore they are likely to disable the o tracking of their phones if possible. For the persons using intelligent ride-sharing systems the tracking of the person's MS location can be used to increase the security of the tracked person and it is very likely that the persons using these systems will not only allow, but will insist that the location of their MS is traced when they are using intelligent ride-sharing system. Location information can be used also to enhance the easiness of the service. For example, the passenger can be located so that the starting point of the route is not needed to be indicated, or the arrival time of the driver can be estimated etc.

By utilizing mobile phones and the capability to locate them it is possible to create a system that enables fully dynamical, on demand creation of carpool. In instant/dynamic carpool one would not have to make any commitment well before the proposed trip, instead user can indicate the system his/hers willingness to participate immediately or short time before the trip should take place.

The proposed system of figure 1b utilizes the capability to locate a mobile communications device (from this on referred as MS). According to the proposed system the users MS locations can be traced from the user indicated starting point to a user indicated stop point. The safety of a carpooler is increased as both partners are aware that their location can be continuously traced and an alarm might be triggered if they are diverting from the route to the destination more than allowed, or if either one's MS will be switched off.

The operation of the system of figure 1b will be disclosed later in detail with reference to figures 2 and 3b.

Figure 2a illustrates a flow diagram of registration to the system according to an embodiment of the invention. A reference has been made to the system disclosed in the figures 1a and 1b. The steps of the method can be preferably implemented as a computer program code stored into the memory of an electronic device 101, which can be e.g. a server in a communication network.

The system has two types of users: passengers and drivers. A driver is providing a lift for a trip to a passenger. Reference numeral 102 in figures 1 and 2 is referring to a passenger and reference numeral 103 is referring to a driver. Both driver 103 and passenger 102 have to register to the system in order to be able to use it. The task of the system is to dynamically in real-time match the needs of the passengers to the offerings of the drivers. A single person can register to both a driver and a passenger.

Drivers and passengers register to the system using for example their mobile identity e.g. a mobile subscriber identifier. The registration can be done e.g. via Internet by using a desktop or laptop computer that is connected to the Internet. A connection to the server 101 is established e.g. by using either mobile or fixed line Internet access (step 201). Before registration is completed both passenger and driver have to fill in the profile questionnaire. The user profiles should contain at least identity, gender and age of the user as well as at least one approximate route for which the user would need or offer a carpool. The last-mentioned means typically giving a starting point and an end point, or identifying a starting area and an end area from ä list of default areas. For the driver also his/her car type, model, color, license plate number, available number of seats and model year have to be entered. The driver has to also report the status of his/her driving license and possible points in the insurance. Depending on local legislation also permission to do certain checks on criminal record or traffic violations might be asked. The system generates an account for the user who is registering to the system. The meaning of the account is to credit or debit the user depending on whether he/she is registered as a driver or a passenger. Alternatively the user can give his/hers bank account number for this purpose. Optionally credit cards or accounts in the known person to person, person to business or business to person payment systems such as paypal can be used.

If the system and the method disclosed in figures 1 b and 3b is in question, the driver and the passenger'have also to sign a waiver in order to authorize the system to track his/her mobile phone while he/she is active participant or is actively querying for participation in carpool in a carpool.

To validate the registration (step 203) the user has to send a message to the system using the mobile communications device. This message can be sent to the system before registration in order to gain access to the registration system (in this case he/she receives password to the system as return message). Other possibility is that the user selects the password in the registration and sends that password using mobile communications device to the system. In both cases the system gets a confirmation that the user registered to the system has the mobile communications device he/she registered in his/her possession (step 204).

In addition to the initial confirmation of the identity of the user, the system needs to be able to confirm the identity of the person each time he/she uses the system later on. This confirmation can be done for example using one or several from the following: a picture (of person registering), a fingerprint (of person registering), any digital identity (digital identity card etc.), code sentences (question and answer pair), a pass code, a personal identity code (actually a special case of question and answer pair, not connected to the PIN code of passenger's mobile device). In setting-up the carpool these are used to confirm the identities of the persons.

At step 205 the system provides a pass code to the user (optionally the system can ask the user to form a pass code), which is needed to confirm the identity of the user when the transportation begins. The pass code is not sent to a communication device by which the user makes a transportation request and/or offer. That is because if the communication device is stolen, it cannot be used for making successful transportations for a person who stole the device. At step 206 the registration has ended and the communication connection is terminated.

In the following an example of confirmation of an identity of a user is illustrated. The system provides a pass code "asdf to a passenger when he/she has registered to the system. Further the system also sends a pass code "zxcv" to a driver when he/she has registered to the system. Pass codes can also be allocated dynamically per transaction, i.e. code "zxcv" is sent to the driver, when he/she offers to share a ride. Likewise the passenger is given the code "asdf when he/she is requesting a ride. The passenger and driver may be requested to renew his/ her pass codes either periodically or upon usage. Now, if the driver and the passenger are matched by the system (i.e. they have similar starting point and ending point), the pass code ("zxcv") of the driver is sent to the passenger (for example to a communication device of the passenger) and the pass code ("asdf) of the passenger is sent for example to the communication device of the driver. When the passenger and the driver meets, the passenger utters the pass code "asdf to the driver. If the pass code the driver has received is identical with the uttered code of the passenger, the driver can be sure that the passenger is the right person. Also the driver utters the pass code "zxcv" to the passenger and if the pass code the passenger has received is identical with the uttered code of the driver, the passenger can be sure that the driver is the right person.

Figure 3a illustrates a flow diagram of a method according to an embodiment of the invention. The steps of the method can be implemented for example in a computer program code stored in a memory of an electronic device such as the server 101 in figures 1a and 1b. In the real time operation the following identifies the actions needed for the driver and for a passenger to set up a carpbol. At step 310 the system receives a message from the driver 102 or the passenger 103.

If the message is from the driver indicating offering (step 311), the flow proceeds to step 313, wherein the information received in the message is stored in the memory of the server 101. This message includes information, which the system uses to identify the route the driver is driving.

If the message received at step 311 is from passenger (step 312) indicating need for ride, the flow proceeds to step 314, wherein the information received in the message is stored in the memory of the server 101. This message includes information, which the system uses to identify the route for which the passenger is requesting ride.

At step 315 the server 101 finds matches of drivers and passengers having substantially similar route and time information and ask confirmation from driver (step 316). The message the system sends to driver includes the pick-up address of the passenger and either: a picture (of passenger), a fingerprint (of passenger), any digital identity (needed information about passenger's digital identity), code sentences (question and answer pair of passenger has registered), a previously mentioned pass code, personal identity code (of the passenger). Using the above information the driver can confirm the personality of the passenger as he/she sees the passenger. In the simplest method requiring least technology, the driver is delivered the passenger's personal identity code.

Next the flow proceeds to step 325, wherein a message from the driver is received. The message indicates (e.g. "accepted" or "not accepted") whether he/she accepts the passenger or not. If the driver accepts the passenger, the flow proceeds to step 317. If the driver does not accept the passenger, the flow proceeds to step 324, wherein the process ends. Alternatively the flow can continue to step 315, wherein a new match is searched to the passenger. Step 325 is optional, as well it can be always assumed that the driver accepts the passenger if he/she does not answer to the message.

Next (at step 317) the server 101 sends a message to the passenger in order to inform the passenger about the ride. The message the system sends to passenger includes the identification information about the driver's car and either: a picture of driver, a fingerprint (of driver), any digital identity (needed information about driver's digital identity), code sentences (question and answer pair of driver has registered), a previously mentioned pass code, personal identity code (of the driver). Using the above information the passenger can confirm the personality of the driver as he/she sees the driver. In the simplest method requiring least technology, the passenger is delivered the driver's personal identity code.

In the meeting place driver and passenger confirm identify of each other based on descriptions sent. If pictures are sent they compare what they see. If personal identity codes are used driver ask from passenger passenger's personal identity code and compares the answer from passenger to the one he/she received from the system (and vice versa). This procedure is used to confirm the identity of the participants and therefore a person cannot use a stolen mobile device (mobile identity) in the system.

Passenger then sends a message to the server 101 informing the system that he/she has been picked-up by the driver (step 318). This message's meaning is to indicate that the passenger and the driver have met and that they have agreed to share a ride. At step 319 the passenger's account is debited with a predetermined amount of e.g. money or credits. At step 320 it is checked whether the end message from the passenger is received or not within a predetermined time. If the end message from the passenger is received at step 320, the system knows that the transportation was successful and the flow proceeds to step 321 wherein the driver's account is credited with a predetermined amount of money or credits. From the step 321 the flow proceeds to step 324 wherein the process ends. If the end message from the passenger was not received at step 320, the system knows that the transportation was not successful and the flow proceeds to step 322 wherein an enquiry is sent to the passenger. At step 323 a response to the enquiry from the passenger is waited. If one is received, the flow proceeds to step 321 as if the response was the usual end message. If the end response is still not received, the system assumes that something went wrong and skips step 321 before ending. This course of action follows a "minimal security" assumption; not receiving an appropriate end message could also be interpreted as an alarming condition, which is described in more detail later in association of figure 3b.

As is seen from the above a driver in carpool has to send maximum of two simple messages, a passenger three. It should be emphasized that the end-users are using the service multiple times a week so remembering the message structure is not difficult. Furthermore personalized credit card sized instructions for the users can be made. The mobile device can also support the process, e.g. in the form of JAVA application or similar acting as a user interface.

Figure 3b illustrates a flow diagram of a method according to another embodiment of the invention. The steps of the method can be implemented for example in a computer program code stored in a memory of an electronic device such as the server 101 in figures 1a and 1b.

At step 330 the server of the system receives a message from the driver 102 or the passenger 103. If the message is an offering message from the driver indicating offering (step 331), the flow proceeds to step 333, wherein the information received in the message is stored in the memory of the server 101. This message includes information, which the system uses to identify the route the driver is driving.

If the message received at step 331 is a request message from passenger (step 332) indicating need for ride, the flow proceeds to step 334, wherein the information received in the message is stored in the memory of the server 101. This message includes information, which the system uses to identify the route for which the passenger is requesting ride. The request message and the offering message authorizes the system to locate the passenger's and the driver's mobile phone for a time period that could be, for example, equal to estimated drive time to work + N minutes, where N is a sum of maximum wait time, maximum drive time increase and tolerance time.

At step 335 the server 101 finds matches of drivers and passengers having substantially similar route and time information and ask confirmation from driver (step 336). The message the system sends to driver includes the pick-up address of the passenger and either: a picture (of passenger), a fingerprint (of passenger), any digital identity (needed information about passenger's digital identity), code sentences (question and answer pair of passenger has registered), a previously mentioned pass code, personal identity code (of the passenger). Using the above information the driver can confirm the personality of the passenger as he/she sees the passenger. In the simplest method requiring least technology, the driver is delivered the passenger's personal identity code.

The driver either accepts or rejects the passenger by sending a message e.g. "accept" or "reject" to the server (step 337). Optionally it can be always assumed that the driver accepts the passenger if he/she does not answer to the message e.g. within a predetermined time, like 5 minutes for example.

Next (at step 338) the server 101 sends a message to the passenger in order to inform the passenger about the ride. The message the system sends to passenger includes the identification information about the driver's car and either: a picture of driver, a fingerprint (of driver), any digital identity (needed information about \ driver's digital identity), code sentences (question and answer pair of driver has registered), a previously mentioned pass code, personal identity code (of the driver). Using the above information the passenger can confirm the personality of the driver as he/she sees the driver. In the simplest method requiring least technology, the passenger is delivered the driver's personal identity code.

In the meeting place driver and passenger confirm identify of each other based on descriptions sent. If pictures are sent they compare what they see. If personal identity codes are used driver ask from passenger passenger's personal identity code and compares the answer from passenger to the one he/she received from the system (and vice versa). This procedure is used to confirm the identity of the participants and therefore a person cannot use a stolen mobile device (mobile identity) in the system.

Passenger then sends a message to the server 101 informing the system that he/she has been picked-up by the driver (step 339). Also the driver can send a message to the server 101 informing the system that a passenger is now picked-up. These messages meaning is to indicate that the passenger and the driver have met and that they have agreed to share a ride. This message optionally authorizes (if not already done at steps 331 or 332) the system to locate passenger's and driver's mobile phone for a time period that could be, for example, equal to estimated drive time to work + N minutes, where N is a sum of maximum wait time, maximum drive time increase and tolerance time. Alternatively the system could be allowed to locate both the driver and the passenger after offering (step 333) and request messages (step 334), respectively. The system can then track the positions of the driver and the passenger at the approximate time of the pick-up. If the locations match, and the passenger does not send in the step 339 a negative confirmation about the pickup, i.e. that the pick-up is unsuccessful, the system assumes that the pick-up has happened, and the process continues.

As the meeting place is communicated through the system the system knows the · exact location of passenger and driver at the moment this message was sent. The system can perform location update (step 340) for passenger's and driver's mobile devices to confirm the location. The system continuously tracks the location of the passenger and the driver (step 341). If the MS location is too much diverted from the route a check request is sent or directly an alarm would be triggered (step 342) and sent to the police or other emergency system together with the latest known location of the MS.

Finally the passenger indicates the system that he/she is approaching drop-off location (step 343). This message's meaning is to indicate that shared part of trip is made. As the drop-off location is communicated through the system the system knows the exact location of passenger and driver at the moment this message was sent. The system can perform location update for passenger's and driver's mobile devices to confirm the location. After the server 101 receives the message indicating that the trip is made (at step 343) the system considers the carpool as done. Optionally the system communicates to driver that the arriving message was received from the passenger. Location tracking is disabled (step 344) for driver's and passenger's mobile communications devices and the process ends. Location tracking can be disabled either immediately or short time after the last messages are sent. Optionally the system can perform one more location update for passenger's and driver's mobile devices to make sure that they are not driving together anymore.

At step 345 the passenger's account is debited with a predetermined amount of e.g. money or credits and the flow proceeds to step 346 wherein the driver's account is credited with a predetermined amount of money or credits. From the step 346 the flow proceeds to step 347 wherein the process ends.

Figure 4a illustrates a signaling diagram of a method according to an embodiment of the invention. In order to simplify this illustration, the system serves only one passenger and one driver. In real situation the amount of drivers and passengers is usually more than one. A passenger registers him/herself to the system by making a communication connection (401, 402) to the server. Also a driver registers him/herself to the system by making a communication connection (403, 404) to the server. The registration can be done e.g. via Internet. A service profile is generated in this stage. It can comprise parameters such as usual routes, location checking periodicity, allowed deviation from the route, actions when some anomaly is detected (check SMS or call, alarm, etc.).

After registration the passenger and the driver may want to benefit from the services the system provides. The passenger sends a message (405) to the server, via SMSC, to inform the server that he/she would now use the route being v stored in the server. A little later also the driver (406) sends a message to the server via SMSC in order to inform the server that he/she would now drive the route being stored in the server.

When the server receives messages (405 and 406) from passengers and drivers it starts to match them by comparing the route of the messages to each other. A starting point and an ending point of a passenger is compared to corresponding starting point and ending point of a driver. If the starting points are located sufficiently close each other and/or the ending points are sufficiently close each other, the server matches a driver and a passenger. The server sends a message 407 to the driver, wherein the message comprises the identification information of the passenger (e.g. name, picture, and/or pass code of the passenger, etc) and a location (street address) he/she is waiting lift. The message may further comprise time of arrival when the driver should meet the passenger. The server sends a message 408 to the passenger, wherein the message comprises the identification information of the driver (e.g. name, picture, and/or pass code of the driver, etc) and a car he/she is driving (e.g. mark model and color) is coming to pick-up. The message may further comprise estimated time of arrival.

Next the passenger and the driver meets and identify each other and the passenger sends a message 409 to the server indicating that the trip has started successfully. When the trip ends the passenger sends another message 410 indicating that the trip has ended successfully. Now the server 101 informs the passenger with a message 411 that the passenger's account at the server 101 has been debited with an amount of money or credits. Next the server 101 sends a message 412 to the driver informing him/her that the account of his/hers has been credited with an amount of money or credits.

Figure 4b illustrates a signaling diagram of a method according to another embodiment of the invention. A passenger registers him/herself to the system by making a communication connection (420, 421) to the server. Also a driver registers him/herself to the system by making a communication connection (422, 423) to the server. The registration can be done e.g. via Internet. When a user (driver or passenger) wants that his/hers location should be traced he/she informs the system about it when registering to the system. The message should also contain the information about the route, which he/she has agreed with the other partner. The route information might be delivered by the initiation of tracing or it might be stored in the server, in which case the user has to only indicate which route he/she is using. The information should (if the route is not stored in the server) include at least the start and the stop points.

The passenger sends a message 424 to the server, via SMSC, to inform the server that he/she would now use the route being stored in the server. A little later also the driver 425 sends a message to the server via SMSC in order to inform the server that he/she would now drive the route being stored in the server.

When the server receives messages (424 and 425) from passengers and drivers it starts to match them by comparing the route of the messages to each other. A starting point and an ending point of a passenger is compared to corresponding starting point and ending point of a driver. If the starting points are located sufficiently close each other and/or the ending points are sufficiently close each other, the server matches a driver and a passenger. The server sends a message 426 to the driver, wherein the message comprises the identification information of the passenger (e.g. name, picture, and/or pass code of the passenger, etc) and a location (street address) he/she is waiting lift. The message may further comprise time of arrival when the driver should meet the passenger. The server sends a message 427 to the passenger, wherein the message comprises the identification information of the driver (e.g. name, picture, and/or pass code of the driver, etc) and a car he/she is driving (e.g. mark model and color) is coming to pick-up. The message may further comprise estimated time of arrival.

Next the passenger and the driver meets and identify each other and the passenger sends a message 428 to the server indicating that the trip has started successfully. Alternatively the system can track the positions of the driver and the passenger at the approximate time of the pick-up. If the locations match, and- the passenger does not send in the step 428 a negative confirmation about the pickup, i.e. that the pick-up is unsuccessful, the system assumes that the pick-up has happened, and the process continues. The location of the MS would then be traced (429) and if the MS location is too much diverted from the route (Step 430) a check request is sent (431) to the passenger's communication device. If no response (432) is received an alarm would be triggered (433) and sent to the police or other emergency system together with the latest known location of the MS. A user who's phone is set to be traced has to keep his/her phone on for the whole trip. After the ridesharing route is performed the user sends a message indicating that the tracing should be disabled and the server would disable the tracing provided that the MS is in the target area (sufficiently close to stop point). A user might also be able to configure the tracing of his/hers phone in such a way that the server is automatically disabling the tracking as soon as the traced MS arrives to the target area. Naturally some password or pin codes should be used for disabling the tracking and also for the safety check some pin code or .password can be used. If the users are participating in the ride-sharing organized by a server which creates matching of the drivers and passengers in real-time, the triggering of the safety features on and off can be included in the messaging used to set up the ride-sharing trip, therefore enabling the safety features would not require any further actions from the users.

In connection to carpool service the needed messages to authorize the system to perform location updates for the mobile devices can be fully integrated to the messages used to set up a carpool. Importantly the system knows the drive time estimate from the pick-up location to the drop-off location and thus the system can expect the arrival confirmation message. If arrival confirmation message is not received in time the safety procedure can be initialized.

If a problematic situation is detected code sentences the user has selected in the registration can be used to further improve the safety. As the safety procedure is initialized the system asks for certain (user selected) question from the user and depending on the validity of the answer the safety procedure is stopped or continued without indicating it to the user. This question and answer pair have to be different from the one delivered to a carpool partner in setting up the carpool.

Figure 5 illustrates a block diagram of a device according to an embodiment of the invention. The device 500 comprises a processor 501 and a memory 502 for processing the tasks to be performed in the device. The memory 502 can comprise for example random access memory (RAM) and read only memory (ROM). The device further comprises a storage medium 503, for example like a hard disk of a desktop computer or a RAM memory, which further comprises an application 504 that may be for example a computer program product according to the invention. The storage medium may further comprise a register 505 for storing information of the drivers and the passengers that are using the services of the system. The device 500 is for example a server located in a communication network. The device further has input and output means for establishing a connection to other elements of the network, such as SMSC 104, GMLC 105, Internet 106 and PSAP 107 as illustrated in figure 1b.

The server 500 is capable of receiving registration information of passengers and drivers via Internet. All the registration information is stored to the register 505. The server 500 receives request and offer messages from drivers and passengers via SMSC 104. The messages are stored in the register 505 and the application 504 performs matching of requests and offers in the register: When matched driver passenger pair is found, the server requests location information from GMLC 105 for the communication devices of the matched driver and passenger. If a problem situation is detected, the server 400 sends a message to the PSAP 107 in order to inform of the problem situation. The message can comprise for example the name of the owner a communication device having a problem and the location information of the communication device.

The above disclosure illustrates the implementation of the invention and its embodiments by means of examples. A person skilled in the art will find it apparent that the invention is not restricted to the details of the above-described embodiments and that there are also other ways of implementing the invention without deviating from the characteristics of the invention. The above embodiments should thus be considered as illustrative and not restrictive. Hence the possibilities of implementing and using the invention are only restricted by the accompanying claims and therefore the different alternative implementations of the invention, including equivalent implementations, defined in the claims also belong to the scope of the invention.