WO2005104059A2 - Vehicle pooling system through telephone - Google Patents

Vehicle pooling system through telephone Download PDF

Info

Publication number
WO2005104059A2
WO2005104059A2 PCT/IN2005/000126 IN2005000126W WO2005104059A2 WO 2005104059 A2 WO2005104059 A2 WO 2005104059A2 IN 2005000126 W IN2005000126 W IN 2005000126W WO 2005104059 A2 WO2005104059 A2 WO 2005104059A2
Authority
WO
WIPO (PCT)
Prior art keywords
pooling
user
users
phone
vehicle
Prior art date
Application number
PCT/IN2005/000126
Other languages
French (fr)
Other versions
WO2005104059A3 (en
Inventor
Bharat Bhushan
Original Assignee
Bharat Bhushan
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bharat Bhushan filed Critical Bharat Bhushan
Publication of WO2005104059A2 publication Critical patent/WO2005104059A2/en
Publication of WO2005104059A3 publication Critical patent/WO2005104059A3/en

Links

Classifications

    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/20Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
    • G08G1/202Dispatching vehicles on the basis of a location, e.g. taxi dispatching
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07BTICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Definitions

  • Vehicle pooling system through telephone is-a pooling system through use of Telephone esp. Mobile Phone(s) on a real time basis.
  • Pooling may be considered as common supply of funds, goods and / or services which are available to a group of people t ⁇ be used as ⁇ -and when-required. Thus it may be-considered as Putting (money, resources, etc.) into a common fund for common goal.
  • Vehicle Pooling may be considered as people sharing a vehicle for a common destination on cost sharing basis based on mutual understanding.
  • Vehicle Owner term includes all those who drive vehicles having spare capacity for passenger/s, good/s, which includes people who own & drive their own vehicle, drivers other than owner, actual user of vehicle including commercial vehicles etc
  • People willing to Travel includes all those who want to travel / etc. using pooling inoiher's- vehicle.
  • Telephone phone/handsets/mobile phone handset
  • Service Provider database / system
  • Base / system will be Telecommunication -Service provider who ⁇ arovi e telecommunication means to subscribers including wireless communication.
  • Commercial section includes those who make living through -meeting transportation needs of user(s).
  • Object of invention 'Vehicle Pooling system through telephone' is use of a real time System / data base to provide Vehicle Pooling which will
  • Heat Energy generated by burni ⁇ gfuel can be converted to "Work" in real conditions. With mostly single/double occupancy in city conditions esp. during peak traffic, hours, & average human weighing less than 10% of weight of vehicle. This results in about 2.5% of Heat Energy generated by petroleum product being utilized in moving Human being, (for privately owned 4 wheeled vehicle in city conditions having single occupancy) rest for moving vehicle etc., for ehicle(s) using
  • Mobile phone service provider fixes requisite support devices to enable pooling.
  • Service provider authorizes select users (telephone) to use system. Authorized users who want to pool key-in data on their customized mobile phone hand sets. 3. User(s) gets feedback from service provider about possible options for pooling on their mobile phone handsets. User(s) may further select relevant result(s) through their handsets. 4. Customised mobile phone handsets facilitate user(s) in identifying other user(s) to pool (to ensure better sec ⁇ rity). ⁇ .Customized mobile handsets facilitate in tracking and recording distance, route & time of pooling (for security & billing purpose).
  • 'A' & 'B 5 represent customized telephone handsets authorized to pool by service provider.
  • 'D' represents the service provider's support system which accepts request for-pooling, processes requests, generates & transmits relevant data f ⁇ rpooli ⁇ g to customized handsets (users).
  • Mobile phone service provider along with phone handset manufacturer suitably arranges Travel option in the main menu of the Mobile ph ⁇ ne(s). Under Travel option a user selects Pool option; he is asked to specify the status thro' Mobile Phone. Once status is-selected say as Vehicle Owner (V.O.), user(s) specifies the Vehicle type (system displays vehicle in use) along with number of seat(s) available. Further system shows r ⁇ ute(s) -often used along with a map (showing user's base station coverage area) from which user has to select destination and route of journey(s). User can zoom in & zoom out of map, shuffle through to pin point exact starting point, route & end point
  • User(s) can store route(s) often used, in the system.
  • Date & Time of journey system displays current date & time as default.
  • the system Upon specifying all parameters along with date & time- the system will highlight user's selection in terms of status, vehicle type, number of seats / capacity along with the selected route, fime etc & reconfirms from user efore the data is transmitted to service provider's Database management system.
  • the Database management system matches the pooling requirements of V.O.'s with those of PwT's on real time basis & displays result(s) suiting the user(s), based on the common route, time, Personal preferences of VO's, PwT's along with other things in consideration (list is not exhaustive).
  • V.O. in our case will get result(s) on mobile phones along with necessary financial transactions involved.
  • System will intimate both the V.O. & PwT of place of meeting, common route, and approx. distance to meet etc.
  • Both VO's & PwT's will have facility to alter, cancel travel plans by intimating the system.
  • the system displays details of PwT's along with photo(s) and alerts V.O. by suitably signaling thro' phone (ringing& or vibrating etc.). System will again alert V.O. by signaling thro' phone when distance between them reduces to say 50m or less.
  • PwT gets similar details of V.O., his vehicle & alerts (signals) etc. on phone when V.O. comes within specified distance.
  • Mobile phone(s) will continuously inform user(s) whether both the VO & PwT are coming closer to each other or not by suitable audio & or visual signals.
  • Handset(s) may suitably inform user(s) if they cross over each other. Further details to ease identification, etc. canbeworked out based on the local customs m that part of the world.
  • PwT can waive hand/ Phone pinpointing his/her location while V.O. can use side i ⁇ dicatort ⁇ alert PwT drive on lane designated for low speed). Users may reconfirm their destination verbally before pooling. Both V.O. & PwT have option to pool or not, break journey etc. with the concerned person(s) at any moment of time during pooling at their will.
  • the Database Management system will record whether pooling is successful or not, calculates the common journey & makes necessary payment(s). This will be based on the fact that phones will cross various locations simultaneously if pooled successfully. In sucti a case, the system will again ask V.O. about the number of available (vacant) seats suggesting other things as route etc. as default (un-till V.O. travel requirement is-fully satisfied), while PwT will stop getting further results (un-till his/her travel requirement is fully satisfied).
  • V.O. fails to pool with PwT, both will continue to get updated results.
  • System provider may charge both V.O. & PwT for using the service and on basis of results generated and time duration of pooling etc. Feed back option will be available to both V.O. & PwT to report any trouble etc. during pooling so that System provider can take suitable action(s).
  • Service provider can incorporate other services in commercial section, say passenger transpert, goods carriers), courier sep'i e provider, etc based on demand by user(s). These services can be used by various Taxi operators, Bus-service providers, Goods Transport operators, Railways, Shipping, and Airlines etc. to cater to transportation needs of user.
  • Various steps to enable pooling include: 1. To initiate pooling, mobile phone Service provider fixes requisite support devices to enable pooling. These include both hardware & software as a) Setting up Data Base Management System. This system will • Maintain user's authorization status, personal details, preferences etc. required for pooling & to be updated / verified regularly from security point of view. • Help user(s) select route(s) between starting point, destination and current location by maintaining relevant Maps of coverage area etc. • Receive -(keyed in) data ent by user(s) through customized handsets. • Match the relevant parameters of travel-requiremesta-askeyed i ⁇ by user(s), their respective locations, -personal preferences etc. e Send users relevant data to enable pooling.
  • map opens to show the base station coverage area & the user has to select his location in map & key-in travel plan.
  • Data base will track users on basis of base station signals. Installing extra sensors / tracking devices at major roads, cross-sections etc. will track user(s) location, confirm pooling, help users locate other party during pooling etc. more accurately.
  • These sensors/tracking devices will serve as sub-base station for mobile handset to lessen signal coverage area of each base station for tracking mobile phone more accurately. Locations of these sensors/tracking devices will depend upon population density, traffic density, & road network etc. Based on availability of Global Positioning System (G.P.S.) enabled mobile handsets, G.P.S. may be used in addition/ in lieu of extra sensors at major roads etc.
  • G.P.S. Global Positioning System
  • Help-lines or suitable means to assist users to use system, reconfirm & record pooling status when 'known persons' by user, mobile phone of user(s) fails, no signal, battery failure, pooling of etc. Also they may handle complaints, faking suitable actions against complaints etc. Help-lines may. inform concerned users &Z or authorities in cases of: usex(s> pool with wrong user(s) who have different destination, user(s) alter travel plan, a stolen/ unauthorised mobile handset is used for pooling, etc. 2. Maki ⁇ g both hardware & software changes in Phone Handsets. These include a) Developing relevant menu formattokey-i ⁇ relevantdata as "Travel" as option in main menu and its related submenu as described in the drawing enclosed.
  • Mobile phone handset will havefacility to display map on its screen with user current base station coverage area. Users should be able to scroll through the map, select starting point & destination along with the route. With the help of extra sensors/ G.P-S, system, user's location can be displayed more accurately in map.
  • Thedatabase management system can suggest relevant routes based on the user's starting point & destination. Users may select one or several route based on their starting point and destination. Phone handset should store routes often used by subscriber.
  • Phone handsets will support system to present relevant data to user according to user's time schedule. If user selects option submenu as "Oefaulf under "Pooling", Phone handsets sends relevant data (status as V.O., vehicle type, number of seats / capacity, starting point of journey, route, destination, preferences etc)to the data base system after checking the current location & time. e.g. If a user routinely leaves home for job as V.O. in a car with 3 vacant seats between 8.00 to 8.30 a.m. & leaves office for home between 5.30 to 6.30 p.m. (data stored as 'Default), then phone after checking user's current location & time reconfirms from user displaying 'Default' data before sending to servjce provider.
  • relevant data status as V.O., vehicle type, number of seats / capacity, starting point of journey, route, destination, preferences etc
  • Phone handset customization to enable users to locate & identify the vehicle/ persons to be pooled as per the result generated by service provider. This can be done by activating phone ha ⁇ dsejs to act as a transmitter & receiver on select frequencies in a frequency band which will be responded to by the designated handset(s). intended for pooling. The activation of handsets will be done by service provider along with the selection of frequencies. Service provider may assign a unique random key number(s) to both V.O.s & PwTs mobile handsets (once their travel requirements match). On the basis this key number(s) mobile handsets will transmit & receive signals on a select frequency & thus respond to each other when they come within a specified distance from each other. This distance will be decided by service provider suiting local conditions.
  • phone handsets may work independently of service provider network to locate other user(s) for popling.
  • Customised mobile phone handsets will alert user (by suitably ringings or vibrating etc.) once the other user (selected by service provider for pooling) comes within specified distance (say 500m).
  • Customized phone handsets wilt inforrrrdatabase of other users once they come within the specified distance. Database will disclose identity of- such- vehicle/ persons to-be pooled. Handset will-suitably alert userwhether-drstance betwee ⁇ -him-& other user is reducing or increasing within select distance.
  • Customised phone handsets will senctthe above data to service provider for re-verification, record keeping etc. over a period of time, as and when required by service provider.
  • PhoneJiandset will show pooling status, details of user & pooled user(s) during pooling. This will be useful for third party physical verification during traveling. E.g. During security/ police checks conducted during traveling etc.
  • Customised phone handsets detects end of pooling and signals the service provider to make necessary monetary transaction.
  • This facility will be available to users authorized by Service Provider.
  • Service provider may lay his own criteria for authorizing users based on local laws, user's credibility etc.
  • To be Authorized to use pooling system Users will have to fill form specifying their preferences along with various details which are used as default by the system (can be changed later by user by intimating system provider).
  • User(s) opting for VO will be eligible to select their status as PwT if required.
  • PwT(s) will have to re-file the form in case they want to opt for VO.
  • Form may include: a) Vehicle details - make, colour, photo of vehicle/s displaying registration number, seating / loading capacity etc. b) Personal details (name, age, height, -blood group, medical ecor ⁇ details, insurance, addresses, reference, check, other history, credit history etc.) in addition to latest photo of self. c) System, should have provision where Personal Preferences / specifrcs can be incorporated by users.
  • - Prefererrce may include (list is not-exhaustive): Age, Sex, language-- Smoking, habitwhether smoker- or non-smoker etc. Persons working in a particular office, area etc.
  • S ⁇ ecifics, L may include: (list is not exhaustive) Events- marriage, conference, meetings; tourei ⁇ r.e. time boun affeerwhich event/s will be removed from the system automatically. User/s may add or block any person/sfr ⁇ rrr their preference list if required. Also they can report any complaint to the system so that the suitable action can be taken against concerned person (ma e barred: from using system). d) Regular Route/s with no. of empty seats, space, (can be preset as Default which can be modified as and when required). e) Security deposit (optional, depending on service provider). User may Authorize Service provider make necessary financial transaction with Bank (as required for Mobile banking).
  • any of the user can send the relevant request to service provider who in turn will inform both of them that they no longer enjoy a 'personal preference' status the other user's list.
  • any of the users can send the relevant request to service provider to 'Block' any other user.
  • Specific events can be also selected such as marriage, examination centre, vocational, etc. through phone.
  • Service provider may assign suitable means of identification based on event and/or user's phone numbers to further facilitate data key-in: Specif icswill be valid for a particular duration after which they will automatically be deleted. All information(s) regarding personal details etc. should be cross-checked (physically) before authorizing user(s) access to the system & repeatedly over a period of time (say every six months after availing service) to ensure requisite Security by Service provider. It should be tried with selected group/s to fine tune the system. Based on the initial response, the service can be suitably modified and extended to wider net of Population. This clause-may be suitably modified for PwT & VO in case of vehicle type being Commercial as Taxi's, Buses, Goods Transport operators etc. who are governed by different rules & regulations.
  • Mobile phone service provider along with phone handset manufacturer suitably arranges Travel option in the main menu of the Mobile, ⁇ hone(s). Under Travel option a user selects. Pool option; he is asked to specify the status thro' Mobile Phone. Once status is selected say as Vehicle Owner (V.O.), user further specifies vehicle type, number of seats capacity Further upon user specifying the Vehicle type, system displays-current vehicle in use. User(s) who have more than one vehicle can select vehicle in use. Users can add delete vehicle(s) by seeking approval by service provider. After user(s) selects vehicle type, user has to specify number of seat(s) / capacity available.
  • V.O. Vehicle Owner
  • a map will open (showing user's current base station coverage area) from which user has to setectdestinati ⁇ n and route of journey(s).
  • the database management system can suggest relevant routes based on the user's starting point & destination. Users may select one or several route based on their starting pointand destination. Phone handset and / or service provider should store routes often used by subscriber.
  • User(s) can stor route(s) often used, in the system. System will highlight the selected route along with other possible routes. Users may take assistance from service provider's help-line for selection of starting point, destination, routes etc.
  • user(s) specify date & time of journey (system displays current date & time as default).
  • the data is transmitted to service provider's Database management system.
  • Mobile, and/ or Fixed Line phones etc. will include preferred Vehicle Type, Seat ⁇ equ ⁇ rement, Route (assisted by map highlighting current location & route selected), along with Date-&time o ⁇ Journey. They may select "earliest" optio in- vehicle type in case they want to avail the earliest possible option irrespective of vehicle type: The system will show approximate amount of financial transaction involved.
  • hand set may beep & or vibrate etc. to inform user and/or also in case -he/she forgets time schedule, or to log in the system when the mobile phone and or system detects-movement. Movement can also be detected by change in signals from -base station, vibrations generated in handset as a result of movement when phone not being used for talking or by any other suitable means.
  • a special phone handset holder may be installed in the vehicle where user(s) may keep their mobile handset during travel. This may be used to select time of start of journey (movement).
  • Special phone handset holder may be further integrated with the-car electronics (audio& video signals), navigational system to further assist user(s) to pool. Provision may be built in phone handset holder to hold more than one phone handset so that when PwT put their phone in handset holder, it further re-confirms pooling & phones suitably inform the service provider.
  • the-car electronics audio& video signals
  • Provision may be built in phone handset holder to hold more than one phone handset so that when PwT put their phone in handset holder, it further re-confirms pooling & phones suitably inform the service provider.
  • User(s) gets feedback from service provider about their handsets. User(s) can select relevant result(s) through their handsets.
  • the System provider's data base management system Based on the Locations, Destination, Route, Seating requirement, Time, Personal preferences,, etc. of VO's, PwT's., the System provider's data base management system generates result(s) if any.
  • results will continuously be made available to both V.O. & PwTs unless and until their travel requirement is fulfilled by pooling (as per result generated by system).
  • the results will be updated automatically by the system provider as and when required.
  • System may suggest users (esp. PwT) to change their current location / break journey to enable them to reach final destination in case no results/option available which completely fulfills their travel requirements.
  • Service provider will suitably intimate user(s) in case they change travel plan during pooling.
  • the system will intimate both the parties regarding distance of meeting, Common Route of journey,
  • V.O. & PwT can view various travel requirements of pooled result(s) generated by system. User(s) can thus further make their preferred selection. In such case other result(s) will be neglected unless & until pooling with the preferred selected user(s) is unsuccessful (such preferred user crosses the user's location without pooling).
  • System wiH highlight such userfs) in the result generated for the other said- user(s> involved in pooling. Even if user(s) do not scroll through the-result(s) -generated &y system, they can still pool based on the optlon ⁇ s). available at nearest distance. ⁇ Both VO's & PwT's will have facility to alter, cancel plans by intimating the system.
  • S.Customized phone handsets faciHtate ⁇ sers in locating ⁇ .ident.fying the vehicle/ persons to be pooled (to ensure better security).
  • Service provider network will keep updating the locations of both VO & PwT based onfhe existing techniques.
  • extra signaling devices may be installed at major cross- sections to fine tune the location parameters and/or through use of G.P.S.
  • Phone -Hand-sets will have to be specially designed to help users identify each other as VO & PwT.
  • Mobile Hand set will suitably alert user about other user(s) movement when their meeting distance is less than say 500m once & again when their meeting distance is less than say-50m (variable, can be altered to suit local conditions & other parameters).
  • lVlobile- ⁇ hone(s)- will continuously -inform user(s) whether both the VO & PwT are coming closer to each other or not by suitable audio & or visual signals.
  • Handset(s) may suitably inform user(s) if they cross over each other.
  • Service provider may assign a (unique, random, variable) key number(s) along with necessary details to /both V.O.S& PwTs mobile handsets (once their travel requirements match) to help locate each other. Key numbers may be assigned on priorit basis for closest available options that are present within a pre-determi ⁇ ed distance.
  • Intra Mobile Pho ⁇ e(s) Hand set signaling should preferably be independent of network.
  • Service provider can also provide user facility to track / update movement of the result(s) generated by the system periodically (using any suitable means as base station signals, GPS etc.).
  • VO & PwT may track other's movement (result(s) generated by the system) with approx. distance to meet till they meet or cross each other.
  • the system will disclose identity of the other party to User only when the matched result(s) are within specified distance with both getting alert(s) thro' Mobile phone.
  • Mobile phones will inform service provider when the other users intended for pooling come within the specified distance.
  • service provider Upon receiving request from user's mobile handset, service provider will forward identification details of other users.
  • Mobile Handset will display other user's "Name & Destination" etc. to help confirm other's identity. Additionally Mobile Handset may display Photos etc- (handset dependent) along with, relevant details of -the other party to both VO & PwT to enable them to identify each other when they are within specified distance, say 500m
  • service provider also records all such cases where identity is disclosed to other users. Also service provider monitors V-Q- &. PwT's location closely within the specified distance, (esp. when distance between them is say 50m or less, suiting local conditions) -either independently and /or along with mobile handset(s). Service provider checks respective locations of V.O. & PwT's (say once every second) within specified distance to ensure whether or not V.O. stopped ⁇ o meet PwT.
  • Phone handset will store record of the users with whom pooling is successful, and of those who agree to be a personal preference. Mo record of the 'results/options' generated for- pooling by service provider will be stored / recorded on user's phone-handsets.
  • both V.O. & PwT will have to agree upon the same-i.e. to grant Personal Preference status to each other. Pooling results will highlight (such cases as personal pref.) provided the route & timing match within certain parameters.
  • Customized mobile handsets facilitate in tracking and recording distance, route & time of pooling (for security & billing purpose).
  • Service provider will detect whether pooling is successful or not either independently or along with phone handset. If pooled (user's travel requirement met by pooling as per result generated by- system), user(s) will be temporarily omitted from the travel requirement result (by suitably updating), subject to reaching of destination.
  • pooling If pooling is successful, their respective positions should be within say 20m of each other at all times during journey.
  • the system will confirm from V.O. about the pooling status, seat(s), space etc. after his meeting with PwT (displaying result(s)on mobile phone as per-data of PwT, V.G. as default). Similarly service providerwill reconfirm from PwT about pooling.
  • System will • detect whether meeting of V.O. & PwT is successful or not by checking their respective positions. Starting from V.O.'s approach distance with PwT is say 50m or less till it exceeds say 100m. If distance between VO & PwT exceeds specified limit, service providerwill update the list of probable match. Q ⁇ sta ⁇ ce(s) mentioned may be adjusted by service provider to suit local condition ⁇ s).These parameters may be checked repeatedly over a period of time from start to end of journey.
  • Service provider will track & record the details-of the journey shared by V.O. & PwTs. Details of journey shared can be tracked by detecting their respective movements) by using suitable means (checking signals from both VO & PwT mobile to detect their respective movements), if both are moving simultaneously over a period of time)-. Also Mobile Phone(s) -Hand sets-should be designed to record-time, duration and /or distance of pooling to inform the system. This-ca ⁇ be basedo ⁇ the logic that-phon ⁇ (s) used for pooling will stay within- say 20m of eac other during pooling at any given time when vehicle (with user(s) & handset(s) in it) is moving.
  • Mobile Handsets have to be specially designed to record-presence of customized mobile handset(s) used for pooling (based on unique key number given by service provider) are within say 20m range, keep track of such cases & inform system as and when required.
  • Customized phone handsets will send the above data to service provider for re-verification, record keeping etc. over a period of time as and when required by service provider.
  • pooling phone handset will show pooling status, details of user & pooled user(s). This will be useful for third party physical verification during traveling e.g. in case of police checks etc.
  • Service provider may track signals of pooled mobile handset (independently of data recorded & transmitted by pooled handsets as explained above) in the network based on the means as base station signals, extra sensing devices at roads & crossings, GPS etc.
  • service provider may re-confirm pool status over a period of time by a checking presence of pooled mobile handsets, tracking route & distance pooled, etc. by matching results generated by phone handsets (about pooling data) & those from base station signals, GPS etc.
  • Service provider may block stolen, lost etc. phone handsets. I case a Passenger uses a stolen mobile to pool (within the time user reports missing phone & subsequent blocking), service provider can suitably inform concerned fellow passengers ⁇ by appropriatemeans) along with police & concerned authorities etc. Record(s) of pooling can be stored with service provider for a reasonable period of i ime say 180 days to ensure requisite security to User(s).
  • Mobile -Handsets may also keep record for pooling for last entries based on their memory.
  • Customised phone handsets detects end of pooling & signals service provider to make necessary monetary transaction.
  • VO account will be credited & PwT's account be debited from the deposit by the system.
  • Service provider may ask user(s) to either provide Security deposit or authorize service provider to make necessary financial transaction(s) with user's Bank etc.
  • user(s) may want to meet travel requirement of their known persons, (say family, relatives, friends etc) by pooling who may not have phone handset, then user(s) have to suitably rpquest service provider.
  • Such-user ⁇ s will have to initiate pooling, facilitate in identification and pay financial transactions involved.
  • Other users (esp.- .O.) involved in pooling will have to confirm pooling status & end of journey etc. of such 'known persons' to service provider.
  • Users who initiated pooling will have to re-confirm with-in say 24 hours whether or not their 'known persons' travel requirements were met. If there is no re-confirmation with-in stipulated time- frame, financial transactions will be started.
  • Such user(s) can track others users travel pooling with 'known persons' I till other user reach designated place.
  • - service provider may act as mediator and connect both users involved in pooling to reconfirm end of pooling.
  • Such users may talk to their 'known persons' via other user's phone handset to confirm end of journey (service provider recording & monitoring such calls).
  • pool status can be suitably modified as finding a fool proof system to track goods may be not be feasible as on date. It might become feasible based on the further development of R.F.I. D. (Radio Frequency Identification tags) and their integration with pooling system. Unlike passenger pooling where passenger carries a mobile phone during pooling, such case may not be possible with pooling of goods.
  • service provider has to make separate billing procedure based on data usage, successful meeting with pooling user(s), travel requirement(s) etc. Scope for Further Integration
  • System menu options will have further menu options as 'Cash' -whereby monetary status can be checked, loaded etc.;
  • 'Traffic Jam' can check status -o traffic jam either in association with-service provider real-time data-base having inputs from- sensors, public, mobile signals etc.;
  • the system will match the demand & supply of Space, -Goods carrying capacity, Seat/s etc. on real time basis and hence will improve overall efficiency and change logistics planning for ever. Illustration on Passenger Transport Companies including City Transport. The whole process can be extended to transport companies in following way(s): In case of city transport, it will help in: • selection of buses & deciding their routes, • location of buses, their schedule, • Capacity utilization (by suitable techniques as detecting weight in vehicle through sensors, etc) with respect to time, location etc. Current location of Buses, their capacity utilization etc. can be shown at all major stops thro' mobile phones. This can be done by installing one mobile set in all the buses, and at major bus stands. These bus stands will intimate users of estimated distance for Bus to Arrive, approx. availability of seat(s) etc. Installing mobile on bus will also help transport companies in better route management (by running buses on required routes & in time to match traffic demand), immediate action on break down, accidents, & other emergency services etc.
  • Service provider should a. Provide insurance cover for life & material for all user(s) etc. b. Keep record (back up for a reasonable period) for persons availing the service, journey shared details etc. (keeping in mind legal-consequences). c. Feed back option to block offenders if reported so. d.
  • Helpline service (24hpurs X365 days) to assist users availing service, block mobile reported stolen, inform police about details etc., if the stolen mobile is being used for pooling, rechargirrg cash on mobile (by integrating with ATM's, thro' Cash cards, along with charging facility by any other user(s) remotely) etc.
  • This service will redupe: pollution, fuel consumption, traffic jams etc. Still it should be tried with selected group/s to fine tune the system.
  • Initial Trial be limited to Vehicle Owners only, and to Persons with PAN. (India specific), Bank Account Holders etc. for peak traffic hours. Initially allow pooling twice a day per mobile connection etc. Based on the initial response, the service can be suitably modified and extended to wider net of Population.

Abstract

Vehicle Pooling system allows people to pool using Phones (esp. Mobile Phones) to meet their traveling needs. In conventional pooling, Vehicle Owner (VO) has to know People willing to gravel (PwT) personally due to security & ether concerns. Additionally, their Destination, Timing etc. should match, which severely retrains pooling. In this invention, travel requirements of VO & PwT are met on real time basis taking security & other concerns into account through use of Phone(s). Based an the input(s) by users in term of destination, timings etc throgh phone, the system informs both VO & PwT simultaneously about possible match(s). It helps users in locating each other(s), keeps record of journey shared etc. Users have option to further select the result/s generated by system, alter travel plan(s).

Description

VEHiCLE POOLi G SYSTEM THROUGH TELEPHONE
Vehicle pooling system through telephone is-a pooling system through use of Telephone esp. Mobile Phone(s) on a real time basis.
Transportation is one of the basic requirements of society which involves human & goods traffic across the- globe. With growing population, increase in number of vehicles (& associated traffic jams etc.), limited Petroleum reserves and increasing global warming, society needs a more effective & efficient transportation system. Due to resource constraints esp. in Developing countries, Geographic distribution of population, Traveling patterns, etc., it is not always possible (economically & othervvise) to meet demand of all the areas with the Public transport at all the times, particularly during peak demand hours, people tend to use their own Vehicles.
These problems can be overcome to a great extent by the present invention, which helps human and goods pooling through use of mobile phone. Pooling may be considered as common supply of funds, goods and / or services which are available to a group of people tσ be used as~-and when-required. Thus it may be-considered as Putting (money, resources, etc.) into a common fund for common goal.
Similarly Vehicle Pooling may be considered as people sharing a vehicle for a common destination on cost sharing basis based on mutual understanding. ConyentionaiNehiele Pooling:-
In conventional pooling, Vehicle Owner(s) (VO) prefer to pool with known People willing to Travel (PwT) due to security & other concerns. In addition to matching of Destination, Time etc., knowledge of other's travel requirement is required. Therefore people working in same Office and/or residing in same locality having matching travel requirement pool because of tu above constraints. V.O. & PwT share travel cost on mutual understanding. Proposed Vehicle Pooling System Through Telephone: We propose to set up a system which will meet travel requirements of VO & PwT on real time basis taking security & other considerations into account using phones esp. Mobile Phones. Users will key-in their travel requirements in the system through phones. The system will inform both VO & PwT simultaneously about possible matches on basis of their destination, route etc. through phones. Each of them will have option to select the result(s) generated by the system through phone. System will further assist user(s) through phones to identify each other which will enable them to pool vehicle(s). V.O. & PwT share travel costs. The system will thus benefit VO, PwT & society as explained below. ^lote:
Vehicle Owner (VO) term includes all those who drive vehicles having spare capacity for passenger/s, good/s, which includes people who own & drive their own vehicle, drivers other than owner, actual user of vehicle including commercial vehicles etc People willing to Travel (PwT) includes all those who want to travel /
Figure imgf000003_0001
etc. using pooling inoiher's- vehicle. Telephone (phone/handsets/mobile phone handset) will include customized/ speciall -designed phone (including- fixed & mobile telephone) having extra features to facilitate pooling. Service Provider (database / system) will be Telecommunication -Service provider who ^arovi e telecommunication means to subscribers including wireless communication. Commercial section includes those who make living through -meeting transportation needs of user(s).
It ensures VO monetary returns for utilizing the free space / seat(s) in his vehicle which may cover part of the-vehicle running expense. PwT reach their destination in time, with comfort, and at fraction of cost as compared to running own vehicle. It saves Society, Governments of Traffic Jams, Pollution, Fuel (depleting petroleum resources), Time, Reduction in Accidents. & other resources etc. Also wijth the growing affluence, each individual tries to use own Vehicle for convenience, safety, time savings etc. Most of such uses esp. for official ρurρose(s) (during peak traffic hours in Metro cities) have single/ double occupancy: This results in large numbers of vehicle(s) on road & thus put tremendous load on transport & its related infrastructure (roads etc.). The resultant traffic jams further encourage people to use own vehicles which further increases Traffic Jams. Also many goods carrier are loaded to their capacity towards their destination while these are relatively empt on the return journey: To get loaded to Optimum capacity in return journey they have to either wait to get their vehicle loaded or travel back empty due to lack of data whether anyone requires goods vehicle etc.
In such situations our proposed 'Vehicle Pooling system through Telephone' will come in handy to a great extent.
Object of invention 'Vehicle Pooling system through telephone' is use of a real time System / data base to provide Vehicle Pooling which will
1. Cut down Pollution & reduce Global Warming
2. Save Fuel 'especially Non renewable Petroleum Products'.
3. Improve Global Economy by following mqans - a) Save man hours spent in traffic jams. b) Reduce costs of transportation. c) Reduce number of accidents. d) Helps in better management of resources (road, services) by local government, Police & Public at large etc.. 4. Helps telecom service providerto increase income (otherthan voice), lead over others in terms of service, profits, increase in latest mobile handset sale etc. Also ii will help in more healthy competition with better infrastructure.
Each petroleum fuel driven vehicle contributes greatly to-Global warming. Less than 25% of the
"Heat Energy" generated by burniπgfuel can be converted to "Work" in real conditions. With mostly single/double occupancy in city conditions esp. during peak traffic, hours, & average human weighing less than 10% of weight of vehicle. This results in about 2.5% of Heat Energy generated by petroleum product being utilized in moving Human being, (for privately owned 4 wheeled vehicle in city conditions having single occupancy) rest for moving vehicle etc., for ehicle(s) using
Petroleum products.
Since more private cars means more Traffic Jams on the road esp. in cities during peak traffic conditions. This further reduces the less than 2.5 % effective efficiency calculated above (due to engine/s running idle, frequent braking etc. in addition to wastage of Time).
Since there is a limit to Vehicle (Engine) efficiency, the only. alternative left is to use Vehicle(s) to their optima! capacity to use resources judiciously.
'Vehicle Pooling system through telephone' aims at providing Value Added Service to esp. Mobile
Phones users (Includingto fixed landline users and other devices), which will enable users to Pool vehicle.
Steps to initiate vehicle pooling:
1. Mobile phone service provider fixes requisite support devices to enable pooling.
2:Service provider authorizes select users (telephone) to use system. Authorized users who want to pool key-in data on their customized mobile phone hand sets. 3. User(s) gets feedback from service provider about possible options for pooling on their mobile phone handsets. User(s) may further select relevant result(s) through their handsets. 4. Customised mobile phone handsets facilitate user(s) in identifying other user(s) to pool (to ensure better secμrity). δ.Customized mobile handsets facilitate in tracking and recording distance, route & time of pooling (for security & billing purpose).
Brief Description o accompanying drawing:
The accompanying drawings illustrate the overview of system-. 'A' & 'B5 represent customized telephone handsets authorized to pool by service provider. 'D' represents the service provider's support system which accepts request for-pooling, processes requests, generates & transmits relevant data fσrpooliπg to customized handsets (users).
'E' & 'F' represent intra handshaking between customized telephone handsets to detect the presence of each other. The accompanying drawings illustrate the-menu format which can appear on phone (say mobHe phone) screen wherein Users authorized by service provider who wants to pool key-in data as per their travel requirement(s). By suitably modifying the menu different format(s) can be-developed based around the core concept of pooling. For example in the case of passenger(s) pooling esp. in private passenger vehicle:
Mobile phone service provider along with phone handset manufacturer suitably arranges Travel option in the main menu of the Mobile phαne(s). Under Travel option a user selects Pool option; he is asked to specify the status thro' Mobile Phone. Once status is-selected say as Vehicle Owner (V.O.), user(s) specifies the Vehicle type (system displays vehicle in use) along with number of seat(s) available. Further system shows rσute(s) -often used along with a map (showing user's base station coverage area) from which user has to select destination and route of journey(s). User can zoom in & zoom out of map, shuffle through to pin point exact starting point, route & end point
User(s) can store route(s) often used, in the system. In the end user(s) specifies Date & Time of journey (system displays current date & time as default). Upon specifying all parameters along with date & time- the system will highlight user's selection in terms of status, vehicle type, number of seats / capacity along with the selected route, fime etc & reconfirms from user efore the data is transmitted to service provider's Database management system.
Similarly PwTs key-irrtheir travel requirement in system through their phones (system will also highlight financial transaction involved).
The Database management system matches the pooling requirements of V.O.'s with those of PwT's on real time basis & displays result(s) suiting the user(s), based on the common route, time, Personal preferences of VO's, PwT's along with other things in consideration (list is not exhaustive).
The user(s), V.O. in our case will get result(s) on mobile phones along with necessary financial transactions involved. System will intimate both the V.O. & PwT of place of meeting, common route, and approx. distance to meet etc. Both VO's & PwT's will have facility to alter, cancel travel plans by intimating the system.
Once the V.O. comes within specified distance (say 500m), the system displays details of PwT's along with photo(s) and alerts V.O. by suitably signaling thro' phone (ringing& or vibrating etc.). System will again alert V.O. by signaling thro' phone when distance between them reduces to say 50m or less. PwT gets similar details of V.O., his vehicle & alerts (signals) etc. on phone when V.O. comes within specified distance.
Mobile phone(s) will continuously inform user(s) whether both the VO & PwT are coming closer to each other or not by suitable audio & or visual signals. Handset(s) may suitably inform user(s) if they cross over each other. Further details to ease identification, etc. canbeworked out based on the local customs m that part of the world. E.g. On approach of V.O., PwT can waive hand/ Phone pinpointing his/her location while V.O. can use side iπdicatortσalert PwT drive on lane designated for low speed). Users may reconfirm their destination verbally before pooling. Both V.O. & PwT have option to pool or not, break journey etc. with the concerned person(s) at any moment of time during pooling at their will.
The Database Management system will record whether pooling is successful or not, calculates the common journey & makes necessary payment(s). This will be based on the fact that phones will cross various locations simultaneously if pooled successfully. In sucti a case, the system will again ask V.O. about the number of available (vacant) seats suggesting other things as route etc. as default (un-till V.O. travel requirement is-fully satisfied), while PwT will stop getting further results (un-till his/her travel requirement is fully satisfied).
Both V.O. & PwT will be informed about payment(s) before being pooled & in the end of the journey. System providerwitf Intimate PwT in case of phone cash limit falling short before being pooled & might allow pooling with such user based on contract / agreement signed during authorization.
If V.O. fails to pool with PwT, both will continue to get updated results. System provider may charge both V.O. & PwT for using the service and on basis of results generated and time duration of pooling etc. Feed back option will be available to both V.O. & PwT to report any trouble etc. during pooling so that System provider can take suitable action(s).
Similarly Service providercan incorporate other services in commercial section, say passenger transpert, goods carriers), courier sep'i e provider, etc based on demand by user(s). These services can be used by various Taxi operators, Bus-service providers, Goods Transport operators, Railways, Shipping, and Airlines etc. to cater to transportation needs of user.
Detailed Description 'Vehicle Pooling system through telephone' will match travel requirement(s) on real time basis of i) Vehicle Owners traveling with spare seat(s) or capacity in their vehicles (VO) ii) Persons willing to Travel througrr pooling (PwT)
Various steps to enable pooling include: 1. To initiate pooling, mobile phone Service provider fixes requisite support devices to enable pooling. These include both hardware & software as a) Setting up Data Base Management System. This system will • Maintain user's authorization status, personal details, preferences etc. required for pooling & to be updated / verified regularly from security point of view. • Help user(s) select route(s) between starting point, destination and current location by maintaining relevant Maps of coverage area etc. • Receive -(keyed in) data ent by user(s) through customized handsets. • Match the relevant parameters of travel-requiremesta-askeyed iπ by user(s), their respective locations, -personal preferences etc. e Send users relevant data to enable pooling. • Keep record of "Default' option, -displays-relevant data of user's travel need (routine) based on location & time to facilitate to key-in data, • Initializing designated mobile phone handsets -to track each other & suitably alert users when they come with ina specified distance from each other to ease identification during pooling. • Remind users suitably in case they fail to start movement within a certain range of the tentative time of start of journey by ringing and/or vibrating through phone handset. β Remind users suitably in case they fail to log in with the system when users start to travel or change their travel plan within a certain range of the tentative time of start of journey by ringing and/or vibrating through phone handset. • Remind users suitably in case user(s) change their travel plan (destination, route etc.) during pooling. • Keep track of relevant data of pooling asuser's (phone) location w.r.t. time. • Calculate & make necessary financial transactions. These can be done by service provider alone or with association of financial establishments as banks depending on the prevalence of mobile banking etc. This clause may be suitably modified for vehicle types "commercial" which are governed by different rules & regulations. • Maintaining Records of relevant data of pooling for specified time. Time frame for record keeping may be decided upon legal, commercial requirement(s), preferably for not less, than 6 months.
b) Based on base station signals, map opens to show the base station coverage area & the user has to select his location in map & key-in travel plan. Data base will track users on basis of base station signals. Installing extra sensors / tracking devices at major roads, cross-sections etc. will track user(s) location, confirm pooling, help users locate other party during pooling etc. more accurately. These sensors/tracking devices will serve as sub-base station for mobile handset to lessen signal coverage area of each base station for tracking mobile phone more accurately. Locations of these sensors/tracking devices will depend upon population density, traffic density, & road network etc. Based on availability of Global Positioning System (G.P.S.) enabled mobile handsets, G.P.S. may be used in addition/ in lieu of extra sensors at major roads etc. whereby user's current location is displayed in the centre of map (default) from which they can further select their route, destination etc. c) Setting up of Help-lines or suitable means to assist users to use system, reconfirm & record pooling status when 'known persons' by user, mobile phone of user(s) fails, no signal, battery failure, pooling of etc. Also they may handle complaints, faking suitable actions against complaints etc. Help-lines may. inform concerned users &Z or authorities in cases of: usex(s> pool with wrong user(s) who have different destination, user(s) alter travel plan, a stolen/ unauthorised mobile handset is used for pooling, etc. 2. Makiηg both hardware & software changes in Phone Handsets. These include a) Developing relevant menu formattokey-iαrelevantdata as "Travel" as option in main menu and its related submenu as described in the drawing enclosed.
b) Mobile phone handset will havefacility to display map on its screen with user current base station coverage area. Users should be able to scroll through the map, select starting point & destination along with the route. With the help of extra sensors/ G.P-S, system, user's location can be displayed more accurately in map. Thedatabase management system can suggest relevant routes based on the user's starting point & destination. Users may select one or several route based on their starting point and destination. Phone handset should store routes often used by subscriber.
c) Phone handsets will support system to present relevant data to user according to user's time schedule. If user selects option submenu as "Oefaulf under "Pooling", Phone handsets sends relevant data (status as V.O., vehicle type, number of seats / capacity, starting point of journey, route, destination, preferences etc)to the data base system after checking the current location & time. e.g. If a user routinely leaves home for job as V.O. in a car with 3 vacant seats between 8.00 to 8.30 a.m. & leaves office for home between 5.30 to 6.30 p.m. (data stored as 'Default), then phone after checking user's current location & time reconfirms from user displaying 'Default' data before sending to servjce provider.
d) Phone handset customization to enable users to locate & identify the vehicle/ persons to be pooled as per the result generated by service provider. This can be done by activating phone haπdsejs to act as a transmitter & receiver on select frequencies in a frequency band which will be responded to by the designated handset(s). intended for pooling. The activation of handsets will be done by service provider along with the selection of frequencies. Service provider may assign a unique random key number(s) to both V.O.s & PwTs mobile handsets (once their travel requirements match). On the basis this key number(s) mobile handsets will transmit & receive signals on a select frequency & thus respond to each other when they come within a specified distance from each other. This distance will be decided by service provider suiting local conditions. These random key numbers will be valid for a particular time period only (to be decided b, y service provider) and have to be re-selected for every case of pooling. Once activated, phone handsets may work independently of service provider network to locate other user(s) for popling.
Customised mobile phone handsets will alert user (by suitably ringings or vibrating etc.) once the other user (selected by service provider for pooling) comes within specified distance (say 500m). Customized phone handsets wilt inforrrrdatabase of other users once they come within the specified distance. Database will disclose identity of- such- vehicle/ persons to-be pooled. Handset will-suitably alert userwhether-drstance betweeπ-him-& other user is reducing or increasing within select distance. e) Mobile Phone handset customisation to enable confirmation of pooling by a checking whether mobile handset used for pooling is present within a select distance, tracking route, distance & time of pooling, keeping record-of pooling etc: Route tracking will be done by monitoring & recording base station signals. By installing extra sensors/ G.P.S., tracking can be done more accurately. Customised phone handsets will senctthe above data to service provider for re-verification, record keeping etc. over a period of time, as and when required by service provider.
f) PhoneJiandset will show pooling status, details of user & pooled user(s) during pooling. This will be useful for third party physical verification during traveling. E.g. During security/ police checks conducted during traveling etc.
g) Tracking signafsof pooled mobile handset(s) { independently ofxiatairansmitted by pooled handsets as explained above (e)} in the network (using base station signals) to. enable confirmation of pool status over a period of time by a checking presence of pooled mobile handsets, tracking route & distance pooled, keeping record of pooling etc. In case of any doubt etc., help line phones up concerned user(s). h) Customised mobile phone hand set may beep & or vibrate etc. as a reminder to inform user in case he/she forgets to log in the system when the mobile phone detects movement. Movement can be detected by phone alerting user when base station changes during travel, incorporating vibration sensors which detect continuous movement of user for more than a set period, or any other suitably means.
1} Customised phone handsets detects end of pooling and signals the service provider to make necessary monetary transaction.
3. Authorizing users to use Pooling System.
This facility will be available to users authorized by Service Provider. Service provider may lay his own criteria for authorizing users based on local laws, user's credibility etc. To be Authorized to use pooling system, Users will have to fill form specifying their preferences along with various details which are used as default by the system (can be changed later by user by intimating system provider). User(s) opting for VO will be eligible to select their status as PwT if required. PwT(s) will have to re-file the form in case they want to opt for VO.
For example in case of Vehicle Owners (VO), Form may include: a) Vehicle details - make, colour, photo of vehicle/s displaying registration number, seating / loading capacity etc. b) Personal details (name, age, height, -blood group, medical ecor ^ details, insurance, addresses, reference, check, other history, credit history etc.) in addition to latest photo of self. c) System, should have provision where Personal Preferences / specifrcs can be incorporated by users.- Prefererrce may include (list is not-exhaustive): Age, Sex, language-- Smoking, habitwhether smoker- or non-smoker etc. Persons working in a particular office, area etc. Sρecifics,Lmay include: (list is not exhaustive) Events- marriage, conference, meetings; toureiσr.e. time boun affeerwhich event/s will be removed from the system automatically. User/s may add or block any person/sfrσrrr their preference list if required. Also they can report any complaint to the system so that the suitable action can be taken against concerned person (ma e barred: from using system). d) Regular Route/s with no. of empty seats, space, (can be preset as Default which can be modified as and when required). e) Security deposit (optional, depending on service provider). User may Authorize Service provider make necessary financial transaction with Bank (as required for Mobile banking).
Similarly persons who want to avail the service as -PwT will have to fill Form(s) specifying their a) Personal details (name, age, height, blood groups medical-record & details, insurance, addresses; reference check, other history, credit history etc.), in addition to latest photo of self. b) System should-have provision where personal preferences / specifics can be incorporated by users. c) Regular Rσute/s (presetas Default which can be modified as and when required). d) Security deposit with credit limit. User may Authorize Service provider to make necessary financial transaction with Bank (as required for Mobile banking).
For a user to grant a Personal preference status to other user for pooling, he will forward request to service provider througlr phone. Service provider will ask the other user for his consent through suitable means as 'sms' etc. whether he wants to be in personal preference list of the said user. Only afterthe otherusers replies to service provider in affirmation, both of them will be granted 'preferred status' for each other for pooling.
For canceling 'personal preference' status, any of the user can send the relevant request to service provider who in turn will inform both of them that they no longer enjoy a 'personal preference' status the other user's list. Similarly any of the users can send the relevant request to service provider to 'Block' any other user.
Similarly Specific events can be also selected such as marriage, examination centre, pilgrimage, etc. through phone. Service provider may assign suitable means of identification based on event and/or user's phone numbers to further facilitate data key-in: Specif icswill be valid for a particular duration after which they will automatically be deleted. All information(s) regarding personal details etc. should be cross-checked (physically) before authorizing user(s) access to the system & repeatedly over a period of time (say every six months after availing service) to ensure requisite Security by Service provider. It should be tried with selected group/s to fine tune the system. Based on the initial response, the service can be suitably modified and extended to wider net of Population. This clause-may be suitably modified for PwT & VO in case of vehicle type being Commercial as Taxi's, Buses, Goods Transport operators etc. who are governed by different rules & regulations.
4. Authorized users who want to pool key-in data through their customized mobile phone hand sets.
The accompanying- drawings illustrate the menu format which can appear on phone (say mobile phone) screen wherein Users who want to pool key-in data to meetiheir travel, requirement(s). By suitably modifying the menu different format(s) can be developed based around the core concept of pooling. For example in the case of passenger(s) pooling:
Mobile phone service provider along with phone handset manufacturer suitably arranges Travel option in the main menu of the Mobile, ρhone(s). Under Travel option a user selects. Pool option; he is asked to specify the status thro' Mobile Phone. Once status is selected say as Vehicle Owner (V.O.), user further specifies vehicle type, number of seats capacity Further upon user specifying the Vehicle type, system displays-current vehicle in use. User(s) who have more than one vehicle can select vehicle in use. Users can add delete vehicle(s) by seeking approval by service provider. After user(s) selects vehicle type, user has to specify number of seat(s) / capacity available.
Further a map will open (showing user's current base station coverage area) from which user has to setectdestinatiσn and route of journey(s). Usercan scroll, zoom in & zoom out of map, to pin point exact starting point, route & end point. With, the help of extra sensors/ G.P.S. system- user's location can be displayed more accurately. The database management system can suggest relevant routes based on the user's starting point & destination. Users may select one or several route based on their starting pointand destination. Phone handset and / or service provider should store routes often used by subscriber.
User(s) can stor route(s) often used, in the system. System will highlight the selected route along with other possible routes. Users may take assistance from service provider's help-line for selection of starting point, destination, routes etc.
In the eπά, user(s) specify date & time of journey (system displays current date & time as default).
Upon specifying all the relevant parameters (along with Personal Preferences / specifics as default), the data is transmitted to service provider's Database management system.
Similarly Persons willing to Travel thro- Pool (PwT)-will put similar information on the system thro'
Mobile, and/ or Fixed Line phones etc. These will include preferred Vehicle Type, Seatτequιrement, Route (assisted by map highlighting current location & route selected), along with Date-&time oτ Journey. They may select "earliest" optio in- vehicle type in case they want to avail the earliest possible option irrespective of vehicle type: The system will show approximate amount of financial transaction involved.
User's entry in the database will be cancelled if he doesn't start movement within a certain range of the tentative time of start of journey, or user cbanges route (travel plan). As a reminder, hand set may beep & or vibrate etc. to inform user and/or also in case -he/she forgets time schedule, or to log in the system when the mobile phone and or system detects-movement. Movement can also be detected by change in signals from -base station, vibrations generated in handset as a result of movement when phone not being used for talking or by any other suitable means. A special phone handset holder may be installed in the vehicle where user(s) may keep their mobile handset during travel. This may be used to select time of start of journey (movement). Special phone handset holder may be further integrated with the-car electronics (audio& video signals), navigational system to further assist user(s) to pool. Provision may be built in phone handset holder to hold more than one phone handset so that when PwT put their phone in handset holder, it further re-confirms pooling & phones suitably inform the service provider.
5. User(s) gets feedback from service provider about
Figure imgf000012_0001
their handsets. User(s) can select relevant result(s) through their handsets.
Based on the Locations, Destination, Route, Seating requirement, Time, Personal preferences,, etc. of VO's, PwT's., the System provider's data base management system generates result(s) if any.
The results will continuously be made available to both V.O. & PwTs unless and until their travel requirement is fulfilled by pooling (as per result generated by system). The results will be updated automatically by the system provider as and when required.
System may suggest users (esp. PwT) to change their current location / break journey to enable them to reach final destination in case no results/option available which completely fulfills their travel requirements.
In case no satisfactory result/option is available, users have to ensure that they travel on the pre- decided route towards their destination as informed to service provider to avail pooling. They will continue to get updated result unless they reach their destination, change route or cancel their pooling option. Change in route can be detected by base station signals, extra sensors (acting as sub-base stations), G.P.S. or any other suitable means.
Service provider will suitably intimate user(s) in case they change travel plan during pooling.
The system will intimate both the parties regarding distance of meeting, Common Route of journey,
Financial Transactions involved and probable distance to meet etc. Both V.O. & PwT can view various travel requirements of pooled result(s) generated by system. User(s) can thus further make their preferred selection. In such case other result(s) will be neglected unless & until pooling with the preferred selected user(s) is unsuccessful (such preferred user crosses the user's location without pooling). System wiH highlight such userfs) in the result generated for the other said- user(s> involved in pooling. Even if user(s) do not scroll through the-result(s) -generated &y system, they can still pool based on the optlonζs). available at nearest distance.~Both VO's & PwT's will have facility to alter, cancel plans by intimating the system.
S.Customized phone handsets faciHtate^sers) in locating ^.ident.fying the vehicle/ persons to be pooled (to ensure better security). Service provider network will keep updating the locations of both VO & PwT based onfhe existing techniques. In addition, extra signaling devices may be installed at major cross- sections to fine tune the location parameters and/or through use of G.P.S.
Phone -Hand-sets will have to be specially designed to help users identify each other as VO & PwT. Mobile Hand set will suitably alert user about other user(s) movement when their meeting distance is less than say 500m once & again when their meeting distance is less than say-50m (variable, can be altered to suit local conditions & other parameters). lVlobile-ρhone(s)-will continuously -inform user(s) whether both the VO & PwT are coming closer to each other or not by suitable audio & or visual signals. Handset(s) may suitably inform user(s) if they cross over each other.
Service provider may assign a (unique, random, variable) key number(s) along with necessary details to /both V.O.S& PwTs mobile handsets (once their travel requirements match) to help locate each other. Key numbers may be assigned on priorit basis for closest available options that are present within a pre-determiπed distance.
On the basis this key numbεr(s) mobile handsets will transmit & receive signals on select frequencies in a frequency band & thusrespond to each other. These random key numbers will be valid for particular time period only and have to be re-selected for every new case of pooling.
Intra Mobile Phoπe(s) Hand set signaling should preferably be independent of network.
Service provider can also provide user facility to track / update movement of the result(s) generated by the system periodically (using any suitable means as base station signals, GPS etc.). Thus both VO & PwT may track other's movement (result(s) generated by the system) with approx. distance to meet till they meet or cross each other.
The system will disclose identity of the other party to User only when the matched result(s) are within specified distance with both getting alert(s) thro' Mobile phone. Mobile phones will inform service provider when the other users intended for pooling come within the specified distance. Upon receiving request from user's mobile handset, service provider will forward identification details of other users. Mobile Handset will display other user's "Name & Destination" etc. to help confirm other's identity. Additionally Mobile Handset may display Photos etc- (handset dependent) along with, relevant details of -the other party to both VO & PwT to enable them to identify each other when they are within specified distance, say 500m
To ensure greater security, service provider also records all such cases where identity is disclosed to other users. Also service provider monitors V-Q- &. PwT's location closely within the specified distance, (esp. when distance between them is say 50m or less, suiting local conditions) -either independently and /or along with mobile handset(s). Service provider checks respective locations of V.O. & PwT's (say once every second) within specified distance to ensure whether or not V.O. stopped ^o meet PwT.
Phone handset will store record of the users with whom pooling is successful, and of those who agree to be a personal preference. Mo record of the 'results/options' generated for- pooling by service provider will be stored / recorded on user's phone-handsets.
For granting special consideration to other user(s) as Personal Preference, both V.O. & PwT will have to agree upon the same-i.e. to grant Personal Preference status to each other. Pooling results will highlight (such cases as personal pref.) provided the route & timing match within certain parameters.
7. Customized mobile handsets facilitate in tracking and recording distance, route & time of pooling (for security & billing purpose).
Service providerwill detect whether pooling is successful or not either independently or along with phone handset. If pooled (user's travel requirement met by pooling as per result generated by- system), user(s) will be temporarily omitted from the travel requirement result (by suitably updating), subject to reaching of destination.
If pooling is successful, their respective positions should be within say 20m of each other at all times during journey. The system will confirm from V.O. about the pooling status, seat(s), space etc. after his meeting with PwT (displaying result(s)on mobile phone as per-data of PwT, V.G. as default). Similarly service providerwill reconfirm from PwT about pooling.
In case of V.O. , PwT etc. givingmis'tnformatron about pooling (result different as per the data keyed in), they may be asked to reconfirm the fact. If wrong data is keyed in again, or data of both V.O. & PwT doesn't match they may be barred from using the service further and concerned user(s) a|ong with fellow passengers be informed. Service provider's call - centers may contact users to further solve the problem.
In case they fail to meet, the system will intimate them along with next probable match. System will • detect whether meeting of V.O. & PwT is successful or not by checking their respective positions. Starting from V.O.'s approach distance with PwT is say 50m or less till it exceeds say 100m. If distance between VO & PwT exceeds specified limit, service providerwill update the list of probable match. Qιstaπce(s) mentioned may be adjusted by service provider to suit local condition{s).These parameters may be checked repeatedly over a period of time from start to end of journey.
Service providerwill track & record the details-of the journey shared by V.O. & PwTs. Details of journey shared can be tracked by detecting their respective movements) by using suitable means (checking signals from both VO & PwT mobile to detect their respective movements), if both are moving simultaneously over a period of time)-. Also Mobile Phone(s) -Hand sets-should be designed to record-time, duration and /or distance of pooling to inform the system. This-caπbe basedoπ the logic that-phonε(s) used for pooling will stay within- say 20m of eac other during pooling at any given time when vehicle (with user(s) & handset(s) in it) is moving.
To take care of break-journey, stoppages etc. where distance between users may exceed 20m during pooling, additional parameter of time ma -be considered. E.g. if V.O; & PwT stop up to say 24 hoursat a particular place & distance between them exceeds 20m during their stoppage but resume their journey together there after, then system will just ask them to reconfirm their pooling status along with travel requirements.
In case of mobile phone handset of user(s) is switched off /battery is discharged: a) Within specified distance before pooling, then service provider may cancel/ update pooling option from result generated & suitably intimate other users. b) During pooling, then other user(s) will be suitably intimated. In such case other user(s) will have to inform service provider aboutend of journey with the concerned user to service provider. IF all of the user's mobile phone are not responding / switched off during journey, service provider may take suitable action against them, charge them with some penalty in addition to charges involved for the whole journey.
Mobile Handsets have to be specially designed to record-presence of customized mobile handset(s) used for pooling (based on unique key number given by service provider) are within say 20m range, keep track of such cases & inform system as and when required.
Customized phone handsets will send the above data to service provider for re-verification, record keeping etc. over a period of time as and when required by service provider.
During pooling phone handset will show pooling status, details of user & pooled user(s). This will be useful for third party physical verification during traveling e.g. in case of police checks etc.
Service provider may track signals of pooled mobile handset (independently of data recorded & transmitted by pooled handsets as explained above) in the network based on the means as base station signals, extra sensing devices at roads & crossings, GPS etc.
Thus service provider may re-confirm pool status over a period of time by a checking presence of pooled mobile handsets, tracking route & distance pooled, etc. by matching results generated by phone handsets (about pooling data) & those from base station signals, GPS etc. Service provider may block stolen, lost etc. phone handsets. I case a Passenger uses a stolen mobile to pool (within the time user reports missing phone & subsequent blocking), service provider can suitably inform concerned fellow passengers {by appropriatemeans) along with Police & concerned authorities etc. Record(s) of pooling can be stored with service provider for a reasonable period of i ime say 180 days to ensure requisite security to User(s). Mobile -Handsets may also keep record for pooling for last entries based on their memory.
8. Customised phone handsets detects end of pooling & signals service provider to make necessary monetary transaction.
Financial transactions will be initiated only after end of journey -(Travel requirement of user(s) met). In case of V.O. & PwT break journey before end of their destination and do not meet again within next 12 hours, financial transaction will be initiated. As explained above, this can be based on the logic that phone(s) used for pooling will stay within say 20m of each other during pooling at any given time when vehicle (with user(s) & handset(s) in it) is moving.
Based on the payment terms, VO account will be credited & PwT's account be debited from the deposit by the system. Service provider may ask user(s) to either provide Security deposit or authorize service provider to make necessary financial transaction(s) with user's Bank etc.
For Passenger vehicles, user(s) may want to meet travel requirement of their known persons, (say family, relatives, friends etc) by pooling who may not have phone handset, then user(s) have to suitably rpquest service provider. Such-user{s) will have to initiate pooling, facilitate in identification and pay financial transactions involved. Other users (esp.- .O.) involved in pooling will have to confirm pooling status & end of journey etc. of such 'known persons' to service provider. Users who initiated pooling will have to re-confirm with-in say 24 hours whether or not their 'known persons' travel requirements were met. If there is no re-confirmation with-in stipulated time- frame, financial transactions will be started.
Such user(s) can track others users travel pooling with 'known persons' I till other user reach designated place. For further security in such cases,- service provider may act as mediator and connect both users involved in pooling to reconfirm end of pooling. Such users may talk to their 'known persons' via other user's phone handset to confirm end of journey (service provider recording & monitoring such calls).
For Commercial Vehicles carrying goods, pool status can be suitably modified as finding a fool proof system to track goods may be not be feasible as on date. It might become feasible based on the further development of R.F.I. D. (Radio Frequency Identification tags) and their integration with pooling system. Unlike passenger pooling where passenger carries a mobile phone during pooling, such case may not be possible with pooling of goods. For Commercial Vehicles carrying goods, service provider has to make separate billing procedure based on data usage, successful meeting with pooling user(s), travel requirement(s) etc. Scope for Further Integration
1. System menu options will have further menu options as 'Cash' -whereby monetary status can be checked, loaded etc.;
'Locator" - wherebyrtrser s.).can view approx- location of designated user(s) for pooling as per the result generated by system;
'Traffic Jam' -whereby user(s) can check status -o traffic jam either in association with-service provider real-time data-base having inputs from- sensors, public, mobile signals etc.;
'City Directory' - whereby users can find public utilitiesetc. in f he -city; & further scope to add/delete such services.
2. System should have provision to Add new sub sections esp: in 'Commercial' submenu under 'Pooling' menu. These sub sections vvill work on similar grounds as passenger vehicle pooling which may inpiude people in travel/ transport Business. Based on the Data interchange of phone service provider with those other business in Travel industry, phone user(s) can find timetables, make / cancel reservations, find current status etc. online through phone. These may include (list not exhaustive) • Commercial vehicles carrying Goods / Heavy transport vehicles (Goods Transport Companies) • Courier / Postal Departments , Travel Agencies, Cargo Agents • Passenger Transport Companies including City Transport. • Railways , Airlines, Shipping
3. Integration with existing & developing technologies: system should preferable be compatible with car navigational system & thus enhance / aid in pooling. For carrying of goods, RFID tags can be tried with whereby a separate decoder may be built within mobile handset to detect presence of goods or suitable interface with mobile phone.
The system will match the demand & supply of Space, -Goods carrying capacity, Seat/s etc. on real time basis and hence will improve overall efficiency and change logistics planning for ever. Illustration on Passenger Transport Companies including City Transport. The whole process can be extended to transport companies in following way(s): In case of city transport, it will help in: • selection of buses & deciding their routes, • location of buses, their schedule, • Capacity utilization (by suitable techniques as detecting weight in vehicle through sensors, etc) with respect to time, location etc. Current location of Buses, their capacity utilization etc. can be shown at all major stops thro' mobile phones. This can be done by installing one mobile set in all the buses, and at major bus stands. These bus stands will intimate users of estimated distance for Bus to Arrive, approx. availability of seat(s) etc. Installing mobile on bus will also help transport companies in better route management (by running buses on required routes & in time to match traffic demand), immediate action on break down, accidents, & other emergency services etc.
Similarly all cargo/ goods carrier can pool to load their vehicle(s) to optimum level. Passenger vehicle (esp. commercial), may be used for carrying goods on relatively free shift/ route & vice- versa for commercial goods vehicles. This will be handy for city areas where a goods carrying heavy transport vehicles entry is restricted.
Also reference can be made to Automobile industry to design vehicles to facilitate easy conversion of passenger space to goods space & vice versa. Goods vehicle which are loaded for one- way journey can be targeted to begin with E.g. Dumpers, containers etc. so that some space can be converted to handle Passengers etc.
Risk / Precaution
Note: All users have to be informed about risks involved / precautions to be taken as privacy, theft, etc. Service providerwill have limited liability for misinformation by user(s), changes in travel plans of user(s), accident(s) enuring pooling etc.(service contract to be duly signed by user(s)). Service provider (System) should a. Provide insurance cover for life & material for all user(s) etc. b. Keep record (back up for a reasonable period) for persons availing the service, journey shared details etc. (keeping in mind legal-consequences). c. Feed back option to block offenders if reported so. d. Helpline service (24hpurs X365 days) to assist users availing service, block mobile reported stolen, inform police about details etc., if the stolen mobile is being used for pooling, rechargirrg cash on mobile (by integrating with ATM's, thro' Cash cards, along with charging facility by any other user(s) remotely) etc. e. This service will redupe: pollution, fuel consumption, traffic jams etc. Still it should be tried with selected group/s to fine tune the system. E.g. Initial Trial be limited to Vehicle Owners only, and to Persons with PAN. (India specific), Bank Account Holders etc. for peak traffic hours. Initially allow pooling twice a day per mobile connection etc. Based on the initial response, the service can be suitably modified and extended to wider net of Population.

Claims

Claims:
I claim, 1. A 'Vehicle Pooling system through telephone' comprising: Service Provider Support System which will support travel requirements of Vehicle Owner(s)- People willing to Travel , Goods & related commercial activities oη real time basis taking security & other concerns into account customized phone handsets to work in tandem with service provider support system for pooling.
2. 'Vehicle Pooling system through telephone' of claim 1 wherein the service provider support system comprises: authorization system to select users to access to Pooling system. Data base for accepting, processing and forwarding relevant information regarding the travel requ'trement(s) of users. location tracking device to track users, help users locate other party during pooling, confirm pooling etc. and customer support centre to assist users for pooling, -handle complaints etc.
3. 'Vehicle Pooling system through telephone' of claim 2 wherein the authorization system comprises of select users granting limited access based on unique mobile phone handset number and/or SIM chip number, users fulfilling criteria(s) as laid by service provider, government. etc.
4. 'Vehicle Pooling system through telephone' of claim 2 wherein the database system comprises : a record to maintain user's personal details, monetary status, preferences etc. required for pooling & from security point of view. a data acceptance system to accept data of authorized users as keyed πn through their customized phone handsets. a data processing system to process data as keyed-in by users, their preferences etc. and generate relevant output. a data distributing system to send data relevant to user's travel requirement.
5. Vehicle Pooling system through telephone' of claim 4 wherein the record further comprises details of users, as : Personal details, Personal preferences, vehicles details (for V.O.), Specifics, Regular routes (can be preset as Default which can be modified as and when required), security deposit etc. Data stored during pooling as pooling status with respect to time & location.
6. Vehicle Pooling system through telephone' of claim 5 wherein the Personal preferences further comprises of both the users granting a preferred status / 'block' each other. This can be stored in record when one user responses positively to request sent by other user through service provider or complaining service provider.
7. Vehicle Pooling system through telephone' of claim 5 wherein the Specifics further comprises of user storing data for particular event as marriage, conference, meetings, tour, school etc which are time bound and will be removed from the system automatically. System grants time bound Personal preferences status to users in case of specifics.
8. Vehicle Pooling system through telephone' of claim 4 wherein the data acceptance system further comprises: data acceptance in relevant format devised by service provider and keyed-in by user on customized handset. assisting user in keying - in data for data acceptance system by displaying user's current location, time and travel requirement, suggesting alternative routes etc. accepting data transmitted from phone handset for predefined activities as start of pooling, pool status, termination of pooling etc.
9. Vehicle Pooling system through telephone' of claim 4 wherein the data processing system further comprises of: matching travel requirements of users as per the data keyed-in and generating relevant results available at nearest distance to users keeping in view personal preferences etc. suitably alerting user(s) in case they change travel plan during pooling suitably alerting user(s) in case they pool with user(s) having different destination, route etc. suitably alerting user(s) of financial transaction involved & restraining pooling in case of cash limit falling short. assigning a unique key number to all the relevant user's mobile handset performing predefined activities based on data from data acceptance system as sending concerned user's relevant personal details to facilitate identification after data acceptance system receiving request from mobile handsets. Decides when to update the result(s) generated for pooling.
10. Vehicle Pooling system through telephone' of claim 4 wherein the data distributing system further comprises: data distribution to concerned users and suitably alerting them to scroll through the output and further selecting particular output(s), if desired. data distribution system also indicates monetary transaction involved with each Qutput and alerts users if money is falling short before start of pooling.
11. Vehicle Pooling system through telephone' of claim 2 wherein the location tracking device further comprises of installing sensors/tracking devices will serve as sub-base station for mobile handset to lessen signal coverage area of each base station for ease of tracking mobile phone.
12. Vehicle Pooling system through telephone' of claim 2 wherein the customer support centre further comprises of help-line to assist users, aid in reconfirmation of pooling esp. for 'known persons', handle complaints etc. 24 hours a days, 365 days a year.
13. Vehicle Pooling system through telephone' of claim 1 wherein the customized phone handset comprises: Including 'Travel' as option in main menu of phone handset. User's assistance in data key-in Pool alert suitably alerts users to help locate & identify designated user (phone handset) within a select distance. Phone record will keep track of time, distance etc. pooled with designated user(s)
14. Vehicle Pooling system through telephone' of claim 13 wherein the 'Travel' option further comprises of incorporating 'Travel' option with relevant submenu to enable and support pooling in the phone handset.
15. Vehicle Pooling system through telephone' of claim 13 wherein the users assistance further comprises : a menu option which opens vehicle type selection, further opens map showing user's location (base station coverage area) or user's current location in centre of map (G.P.S. enabled handset) with scroll, zoom options to ease selection of starting point, route & destination. phone handsets stores often used routes and highlights selected routes.
16. Vehicle Pooling system through telephone' of claim 13 wherein the pool alert further comprises : Phone handsets suitably alerting users when the designated user (handset) comes within select distance. Phone handset suitably informs users whether distance with designated user is increasing or decreasing. Phone handset shows relevant details of the designated user for ease of identification within select distance.
7. Vehicle Pooling system through telephone' of claim 1 wherein the customized phone handset comprises: Phone handset assists users in their data key-in, route selection etc. Phone handset transmits and receives signals (on a select frequency band) for pooling based on unique key number(s) assigned by service provider. Phone handsets inform service provider and requests for further details of such designated users intended for pooling (based on interface as per unique key number) when they come within specified distance. Phone handset intercommunication within specified distance may be independent of service provider network. Phone handset informs users when designated users intended for pooling come within specified distance and whether distance with designated user(s) is increasing or decreasing along witfi relevant details to ease identification of such users. Phone handsets monitor .& inform service provider respective position of users intended for pooling with respect to lime within specified distance. Phone handsets confirm pooling to service provider through detecting the presence of designated mobile within a certain range. Phone handsets ask users to reconfirm data of pooling as selected by phone handset. Phone handsets signal service provider to update pooling results based on whether pooling is successful or not. phone handset display status of 'Pooling' along with details of self & the vehicle/ - persons -being- pooled during pooling, phone hand set suitably alerts user (may beep &ΌΓ vibrate etc.) as a reminder to inform user in case he/she forgets to log in the system when the mobile phone detects movement of user. phone handset(s) displays pooling status along with details of self & the vehicle/ persons being pooled during pooling. Phone handset to dejtect end of pooling and initiate service provider to update pooling result(s) and monetary transactions. Phone handset will suitably interface with car navigational system, radio frequency identification tags to assist pooling. Phone handset will suitably interface with phone handset holders, display boards etc.
PCT/IN2005/000126 2004-04-22 2005-04-21 Vehicle pooling system through telephone WO2005104059A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN764DE2004 2004-04-22
IN764/DEL/2004 2004-04-22

Publications (2)

Publication Number Publication Date
WO2005104059A2 true WO2005104059A2 (en) 2005-11-03
WO2005104059A3 WO2005104059A3 (en) 2006-01-12

Family

ID=34967339

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IN2005/000126 WO2005104059A2 (en) 2004-04-22 2005-04-21 Vehicle pooling system through telephone

Country Status (1)

Country Link
WO (1) WO2005104059A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2767963B1 (en) * 2013-02-18 2021-08-25 Harman Becker Automotive Systems GmbH A system and a method for automatic scheduling
CN117391399A (en) * 2023-12-06 2024-01-12 厦门蓝斯通信股份有限公司 Method, system and storage medium for spelling and outputting

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4360875A (en) * 1981-02-23 1982-11-23 Behnke Robert W Automated, door-to-door, demand-responsive public transportation system
US5542100A (en) * 1991-06-06 1996-07-30 Sony Corporation Mobile communication system
DE19839524A1 (en) * 1998-08-29 2000-03-02 Daimler Chrysler Ag Efficient use of private road vehicles uses a computer network to connect passenger with a vehicle driver having spare capacity
DE19839525C1 (en) * 1998-08-29 2000-04-13 Daimler Chrysler Ag Mobility service system
GB2358515A (en) * 1999-11-17 2001-07-25 Sagem Map display device with orientation means.
WO2001072078A1 (en) * 2000-03-22 2001-09-27 Oy Waptaxi Ltd Ordering of vehicle, such as taxi, or car pool
US20010037174A1 (en) * 2000-04-04 2001-11-01 Dickerson Stephen L. Communications and computing based urban transit system
DE10033341A1 (en) * 2000-07-08 2002-01-24 Daimler Chrysler Ag Transport system using shared pool of private vehicles especially for use in city areas, in which information concerning users requiring transportation and users offering transport is conveyed to central facility
FR2824657A1 (en) * 2001-05-10 2002-11-15 Marques Et De Droits Derives I METHOD AND SYSTEM FOR RESERVING TAXI THROUGH INDIVIDUAL BOXES ALLOWING LOCATION AND IDENTIFICATION OF CALLER

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003061154A (en) * 2001-08-20 2003-02-28 Pioneer Electronic Corp Information exchange system by mobile phone

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4360875A (en) * 1981-02-23 1982-11-23 Behnke Robert W Automated, door-to-door, demand-responsive public transportation system
US5542100A (en) * 1991-06-06 1996-07-30 Sony Corporation Mobile communication system
DE19839524A1 (en) * 1998-08-29 2000-03-02 Daimler Chrysler Ag Efficient use of private road vehicles uses a computer network to connect passenger with a vehicle driver having spare capacity
DE19839525C1 (en) * 1998-08-29 2000-04-13 Daimler Chrysler Ag Mobility service system
GB2358515A (en) * 1999-11-17 2001-07-25 Sagem Map display device with orientation means.
WO2001072078A1 (en) * 2000-03-22 2001-09-27 Oy Waptaxi Ltd Ordering of vehicle, such as taxi, or car pool
US20010037174A1 (en) * 2000-04-04 2001-11-01 Dickerson Stephen L. Communications and computing based urban transit system
DE10033341A1 (en) * 2000-07-08 2002-01-24 Daimler Chrysler Ag Transport system using shared pool of private vehicles especially for use in city areas, in which information concerning users requiring transportation and users offering transport is conveyed to central facility
FR2824657A1 (en) * 2001-05-10 2002-11-15 Marques Et De Droits Derives I METHOD AND SYSTEM FOR RESERVING TAXI THROUGH INDIVIDUAL BOXES ALLOWING LOCATION AND IDENTIFICATION OF CALLER

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN vol. 2003, no. 06, 3 June 2003 (2003-06-03) & JP 2003 061154 A (PIONEER ELECTRONIC CORP; INKURIMENTO P KK), 28 February 2003 (2003-02-28) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2767963B1 (en) * 2013-02-18 2021-08-25 Harman Becker Automotive Systems GmbH A system and a method for automatic scheduling
CN117391399A (en) * 2023-12-06 2024-01-12 厦门蓝斯通信股份有限公司 Method, system and storage medium for spelling and outputting

Also Published As

Publication number Publication date
WO2005104059A3 (en) 2006-01-12

Similar Documents

Publication Publication Date Title
US11545031B2 (en) System and method for providing distributed on-street valet parking with the aid of a digital computer
US6697730B2 (en) Communications and computing based urban transit system
US20060259353A1 (en) Shared vehicle transportation systems and methods for individuals and entities
CN101520950B (en) Immediate taxi calling assignment managing system and calling assignment managing method
US9019130B2 (en) Notification systems and methods that permit change of time information for delivery and/or pickup of goods and/or services
CN100397434C (en) Taxi service safety and dispatching monitor system
US20160321771A1 (en) Ride-sharing range contours
CN201181988Y (en) Taxi instant calling and allocation management system
US20030040944A1 (en) On-demand transportation system
US20160210675A1 (en) Ordering products / services
US20160320195A1 (en) Ride-sharing long-term ride-share groups
US20120041675A1 (en) Method and System for Coordinating Transportation Service
US20070198276A1 (en) System for procuring services
US20080014908A1 (en) System and method for coordinating customized mobility services through a network
WO2017205961A1 (en) Management and control of driverless vehicles
JP2001060293A (en) Vehicle sharing method and system for allocating vehicle in most or second charged state
KR101721184B1 (en) Call taxi service method and call taxi service server
CN110223529A (en) Reservation bus prevents down the method and system given another the right of way
KR101492176B1 (en) System and method of taxi fare negotiation and relief taxi operation
CN110751541A (en) Unmanned shared automobile management method and device
KR20110066127A (en) System for intermediating goods transportation
WO2005104059A2 (en) Vehicle pooling system through telephone
JP2002163335A (en) Taxi business operating system
JP2021018623A (en) Vehicle allocation support device and vehicle allocation support system
KR20010016414A (en) System and method for optimizing passenger/freight transportation by using network

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase