EP1176571A1 - Surveillance dans un système de partage d'utilisation de véhicule - Google Patents

Surveillance dans un système de partage d'utilisation de véhicule Download PDF

Info

Publication number
EP1176571A1
EP1176571A1 EP01305580A EP01305580A EP1176571A1 EP 1176571 A1 EP1176571 A1 EP 1176571A1 EP 01305580 A EP01305580 A EP 01305580A EP 01305580 A EP01305580 A EP 01305580A EP 1176571 A1 EP1176571 A1 EP 1176571A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
user
vehicles
trip
block
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
EP01305580A
Other languages
German (de)
English (en)
Other versions
EP1176571B1 (fr
Inventor
Hiroshi c/o Kabushiki Kaisha Honda Murakami
Kazuhiro Kabushiki Kaisha Honda Nakamura
Shunji c/o Kabushiki Kaisha Honda Yano
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honda Motor Co Ltd
University of California
Original Assignee
Honda Motor Co Ltd
University of California
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 Honda Motor Co Ltd, University of California filed Critical Honda Motor Co Ltd
Publication of EP1176571A1 publication Critical patent/EP1176571A1/fr
Application granted granted Critical
Publication of EP1176571B1 publication Critical patent/EP1176571B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
    • G08G1/205—Indicating the location of the monitored vehicles as destination, e.g. accidents, stolen, rental
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
    • G08G1/127—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams to a central station ; Indicators in a central station

Definitions

  • the present invention relates, generally, to systems and methods for sharing a fleet of vehicles among a plurality of Users and, in preferred embodiments, to such systems and methods for sharing a fleet of electric vehicles, including systems and methods relating to allocating, tracking, securing, managing and relocating shared electric vehicles.
  • Mass transit systems such as busses, commuter trains, subways, streetcars or the like can fulfill some of the transportation needs of those communities and municipalities that have such systems.
  • travel with such systems is confined to pre-set stop locations and times, set by the route and time schedule of the bus, train, subway or streetcar.
  • the prescribed routes and time schedules typically do not meet many travelers' needs or are too inconvenient for practical usage of the mass transportation system by some travelers.
  • the pre-set stop location is far enough from their origination or destination locations that they must find additional modes of transportation to or from the pre-set stop.
  • some Users drive private vehicles to and from pre-set stop locations and park the vehicles near the stop locations.
  • Some mass transportation systems even provide vehicle parking facilities near pre-set stop locations for such Users.
  • commuter train stops and bus stops in and near some cities are often provided with parking lots for train Users to park private vehicles.
  • vehicles in such parking lots typically remain parked throughout a large part of the day, and are driven only in the morning to bring the User to the train or bus stop and in the evening to take from the train or bus stop.
  • modern mass transportation systems can result in a reduced number of vehicles on the road at any given time, such mass transportation systems do not eliminate the need for private vehicles and can result in an inefficient use of private vehicles.
  • Shared vehicle systems can provide more flexibility than other means of public transportation.
  • a shared vehicle system a number of vehicles are normally maintained in several designated parking areas. Each User is allowed to pick up a vehicle at one parking area, and return the vehicle to the parking area nearest to the User's destination. The User may also drive a vehicle out of a designated parking area for an errand and return the vehicle to the same designated parking area.
  • Shared vehicle systems that are used by a relatively large number of subscribers should include sufficient security measures to protect the vehicles from theft and also to protect the User from crime.
  • Shared vehicle systems must be sufficiently convenient to motivate Users to employ the system. Accordingly, vehicle availability within a reasonable time of a User's request for a vehicle is very important to the success of such a system.
  • vehicle availability within a reasonable time of a User's request for a vehicle is very important to the success of such a system.
  • system cost is minimized and the efficiency of vehicle usage is maximized with smaller vehicle fleets. Accordingly, there is a need for a shared vehicle system that maximizes User convenience yet minimizes the number of vehicles required in the fleet.
  • Vehicles in a shared system may be of many types. They may be the conventional petroleum based gasoline or diesel fuel type vehicles. They may however employ cleaner forms of propulsion such as methanol or propane powered vehicles, or may be vehicles powered by hydrogen stored as a gas or metal hydride. Electric vehicles may draw energy from batteries, fuel cells, generators driven by internal combustion engines, or combinations of different energy sources. Electric vehicles powered by both lead acid and nickel metal hydride batteries have shown much promise and several manufacturers have produced viable electric vehicles employing these battery technologies. Electric propulsion is a good candidate for use as a shared vehicle. Sharing systems and methods are in no way dependent on the use of an electric vehicle, and may be employed with a number of non electrical or hybrid technologies, including common gasoline power.
  • Electric vehicles typically require charging more often than the conventional vehicles require refueling. Recharging stations are not nearly as available as conventional petroleum motor fuels. Moreover, recharging of an electric vehicle typically takes much more time than refueling a conventional vehicle. Thus, if a conventional vehicle is present at a designated parking area of a shared vehicle system, but does not have sufficient fuel to meet a User's travel needs, the vehicle can be quickly refueled and made available to the User. However, even when an electric vehicle is idle in a designated parking space, it is not available to a User unless it has a sufficient existing state of charge (SOC) to make the User's intended trip. Typically, an electric vehicle cannot be re-charged quickly enough to make the intended trip if its existing SOC is inadequate.
  • SOC state of charge
  • the vehicle may be capable of making the intended trip even though it is not fully charged. Accordingly, there is a further need for a system and method for managing shared electric vehicles in an optimum fashion and to meet the needs of a maximum number of Users with a minimum number of vehicles.
  • Preferred embodiments of the present invention relate to shared vehicle systems and methods that maximize User convenience and minimize the number of vehicles required in the shared fleet.
  • a shared vehicle system includes a central station, at least one port for vehicle distribution and a plurality or fleet of vehicles, each having a vehicle subsystem.
  • the central station, port and each of the vehicles are able to communicate so that the vehicles can be requested, allocated and used in an efficient and reliable manner.
  • a User enters information to request a vehicle at a port. That information is communicated to the central station, where the information is processed by a system control computer to select a vehicle from the fleet for allocation to the User at the port.
  • the system control computer communicates with a computer subsystem located in the port from which the User entered the request.
  • the system control computer also communicates directly with the assigned vehicle to provide secure access to the selected vehicle by the assigned User, to monitor vehicle location and operating status, to monitor the state of charge of electric vehicles and to provide other functions described below.
  • allocation of shared vehicles to Users is based in part on travel information received from Users. By allocating vehicles based on travel information, the usage of vehicles and User convenience can be optimized. While various embodiments related to this aspect of the invention may employ any form of shared vehicle, according to further embodiments of the present invention, vehicle sharing systems and methods employing electric vehicles in the shared fleet are disclosed. The allocation of electric vehicles to Users is managed to maximize vehicle availability and minimize vehicle downtime, taking into account the state of charge of a vehicle as well as the charging rate of a vehicle.
  • vehicle parameters such as stored energy are tracked and processed for purposes of efficient allocation of vehicles to Users as well as for selection of vehicles for charging.
  • This information is sent from vehicles to the system control computer, preferably by radio frequency transmission.
  • radio frequency transmission is bidirectional, allowing messages from the central station to be transmitted to individual vehicles as well.
  • the location of vehicles is also tracked and stored by computers located in the central station.
  • the vehicle subsystem includes a vehicle locator system such as global positioning system (GPS), dead reckoning system, radio beacon triangulation system, or a variety of other techniques.
  • vehicle location information is provided by a radio beacon triangulation system such as that operated by Teletrac® (Teletrac is a trademark of Teletrac, Carlsbad California).
  • a shared vehicle system or method provides controlled or secured access to the shared vehicles.
  • User identification information is provided to a vehicle that has been assigned to a User and such information must match information presented by the User in a User interface device installed on the vehicle, before the User is allowed access to the vehicle.
  • a User's personal identification number PIN
  • staff identification information is permanently stored in the vehicle subsystem. Accordingly, staff members may gain entry and operate any of the vehicles without the need to have the vehicle allocated by the system control computer.
  • User interface devices in vehicles not allocated remain in a power conservation mode until allocated.
  • a shared vehicle system and method involves allocating vehicles from a group of available vehicles and returning vehicles allocated to a User to the group of available vehicles upon detection of a parking state while the vehicle is located at a port.
  • the detection of a parking state is accomplished by, for example, the detection of the setting of the vehicle in a parking gear, the lack of motion of a vehicle for a period of time, the opening and/or closing of a vehicle door, or a combination of such events, each of which require no User interaction other than the typical actions taken to park a vehicle.
  • a shared vehicle system and method involves transporting or relocating vehicles from one area or port having a surplus of vehicles to another area or port having a shortage of vehicles. Vehicles may also be transported to effectively use storage space for the parking of the vehicles.
  • a shared vehicle system and method involves a vehicle transport system for transporting a first vehicle with a second vehicle, for example, for relocating the first and/or second vehicle.
  • the invention relates generally to systems and methods for sharing a fleet of vehicles among a plurality of Users, and various aspects of such systems and methods including optimizing vehicle allocation, vehicle tracking, security, and charging and managing a fleet of shared electric vehicles.
  • a number of vehicles are normally maintained in several designated parking areas referred to herein as ports.
  • the ports also include equipment for charging the batteries of the vehicles, as well as computer subsystems, for communicating with the central computer system.
  • computer subsystems are located within kiosks to provide security and to protect the equipment from weather.
  • a User may begin a trip at one port, and return the vehicle to another port more convenient to the User's destination, or to return the vehicle to the port facility at which the trip was begun.
  • the system To successfully attract people to subscribe and become Users of a shared vehicle system, the system must be sufficiently convenient and inexpensive. More particularly, Users should be able to pick up a vehicle at a convenient location and with minimal or no waiting time.
  • the system should be easy and inexpensive for the User and cost effective for the system administrator to operate.
  • the system should be capable of addressing the above needs and employing clean power sources, such as electric vehicles, as its primary shared vehicle.
  • Preferred embodiments of the present invention relate to shared vehicle systems and methods which address the above-described needs and provide additional advantages discussed below. As will become apparent from the discussion below, some embodiments pertain only to sharing systems containing at least some electrical vehicles. Those embodiments of the invention relate to charging or the state of charge of electric vehicles and may be implemented with or without various other aspects relating to, for example, vehicle allocation, tracking, and securing. Similarly, embodiments of the invention relating to vehicle allocation aspects may be implemented with or without various other aspects such as vehicle charging, tracking and securing, and embodiments relating to vehicle securing may be implemented with or without other aspects such as vehicle tracking, allocation or charging.
  • FIG. 1 A schematic representation of a shared vehicle system 10 according to a preferred embodiment of the present invention is shown in Fig. 1.
  • the system includes a central facility (110) comprising a system control computer for administering the vehicle sharing system, at least one port including a kiosk (120) with a computer subsystem including input and output equipment in communication with the system control computer, and a fleet of vehicles 130, one of which is shown in Fig. 1, each having a vehicle subsystem (140) in communication with a system control computer.
  • the system control computer communicates with the computer subsystem in kiosk (120) and the vehicle subsystem 140, according to various embodiments described below, to allocate vehicles in response to requests by Users, to notify a User of the vehicle allocated, to provide secure User access to the selected vehicle, to monitor the location and operating status of vehicles in the fleet, to monitor the state of charge of electric vehicles and to provide other functions described below.
  • system control computer and the computer subsystems are configured as sever and client respectively.
  • the server and client communicate using standard Internet based hypertext transfer protocol ("http").
  • http hypertext transfer protocol
  • the request preferably is made by transmitting active server web pages requesting the information to the client computer subsystem, and processing the User's response thereto.
  • the message requesting information from the User may be generated locally or. stored at the computer system and called by appropriate command from the server.
  • the computers may be linked directly be dedicated lines rather than by Internet.
  • systems and methods for sharing electric vehicles involve selecting and allocating vehicles to Users based on a combination of factors for maximizing both efficiency and convenience.
  • factors include the location of the vehicles relative to the port from which a request is submitted, the state of charge of the vehicles, the distance that the User expects to travel, the period of time that the User expects to use the vehicle, the User's expected arrival time, the User's expected destination, vehicle use patterns of particular Users, the number of individuals waiting for vehicles in the port, and the number of vehicles available at the port.
  • Vehicle selection and allocation occurs in real time by direct communication between the central station, the ports and the vehicles.
  • the machine readable token is a contactless security access card that is read by a passive RF antenna.
  • the card is encoded with 26 machine readable bits.
  • the first 8 bits are common to all Users and are referred to herein as a facility ID; the next 16 bits are uniquely assigned to each User, and are referred to herein as a personal ID; the last two bits are used to verify the integrity of the encoded information read by the card reader by checking parity.
  • the 26 bits are collectively a "User ID.”
  • Other machine readable tokens such as those readable by optical signals, are also within the scope of the invention.
  • the facility ID is read by a card reader attached to the outside of the kiosk. If the facility ID is correct, the kiosk unlocks, and the User is able to enter and access the computer subsystem located inside.
  • a screen saver preferably displayed when the computer subsystem is inactive, is removed at block 250, after the kiosk door unlocks (block 240).
  • the User swipes a smartcard at a second card reader located within the kiosk.
  • the User ID and the kiosk location is sent to a system control computer at the central facility (block 220). From the personal ID portion of User ID information, the system control computer makes a determination as to whether the ID is assigned to a User (27), Staff (28), or is invalid (29).
  • the computer subsystem from which the User initiated a request receives signal 2 from the system control computer, which causes a request for the User's destination to be displayed.
  • the User is requested to input his intended final destination which is sent to the system control computer and stored in a data base.
  • the User is asked whether the vehicle will be used for a Destination Trip or for an Errand Trip.
  • a Destination Trip is defined as a trip from one port to another, while an Errand Trip includes at least one stop at a point that is not the final destination entered at block 300.
  • the User may be asked to provide additional information, such as the number of additional miles (330) or the additional time (340) the errand trip is expected to require. Regardless whether an Errand Trip is to be included, all Users are asked for the number of passengers traveling with them at block 345.
  • the computer subsystem asks the user the number of passengers for the intended trip.
  • this question is used only for logging purpose, but may be advantageously utilized for relocating the vehicles from one port to another for efficient utilization of the vehicles.
  • the system needs to know the number of eligible drivers among the passengers, and the user is required to declare the number of eligible drivers.
  • the system may be provided with an arrangement for rewarding the users who are willing to provide an additional driver to relocate a second vehicle (or even a plurality of vehicles).
  • the system asks the user if the intended trip is a direct or indirect trip.
  • the distinction between a direct trip and an indirect trip allows a relatively accurate estimation of the time duration of the trip.
  • the vehicles were used for a direct trip in a majority of cases, if the user selected a port different from a departure port.
  • the time durations of trips to a same destination typically fall into a narrow time window, and cases of extended time durations or errand trips are relatively rare. Based on this recognition, it is possible to do away with the requirement to declare if the intended trip is a direct path or indirect path without causing any significant errors in estimating the time duration of a trip simply from the distance to the destination.
  • a User is simply asked for his destination. If the final destination is different than the port at which the trip begins, the trip is considered a Direct Trip. Experience shows that when the final destination is not the same as the place where a trip is begun, in the great majority of cases, the trip is a Direct Trip. It is believed that streamlining the vehicle allocation process by eliminating a step in which Users are asked whether a trip is a Direct Trip or an Errand Trip will make the system more user friendly.
  • the system determines whether vehicles are available for the trip requested (block 350). If available, a vehicle is allocated and the vehicle number is displayed by the computer subsystem (block 365). If a vehicle is not then available, the waiting time for a vehicle is displayed (block 370). At block 375, the User is asked to accept or decline the vehicle offered. If the offer is accepted, the number of the assigned vehicle is displayed by the computer subsystem (block 380). If the offer is declined, the program ends (block 385). As described in more detail below, in preferred embodiments, individual passengers traveling together may be assigned to different vehicles to assist in relocating vehicles when appropriate.
  • the system of the present invention distinguishes between a staff ID and a User ID. If the User ID is recognized as a staff ID, program flow branches to the Staff Subroutine shown in Figure 4. As shown in Fig. 4, in response to a signal from the system control computer the Staff Subroutine, staff members are asked at block 410 for their destination. At block 420 the computer subsystem displays the status of each vehicle in the vehicle fleet, together with a "check box" which provides staff members with an opportunity to select one or more vehicles. Staff members may be presented with information concerning all vehicles located at the particular port, as well as indications of which vehicles require relocation. Vehicle information displayed at block 420 preferably includes the state of charge of the vehicle, and any required maintenance. Based on this information, a staff member may select a particular vehicle for maintenance or relocation purposes.
  • Each vehicle 130 in the shared vehicle fleet is provided with an onboard computer system referred to herein as a "vehicle subsystem" 140 for communicating vehicle system and location data to the system control computer and for performing a variety of other functions described below.
  • vehicle subsystem 140 for communicating vehicle system and location data to the system control computer and for performing a variety of other functions described below.
  • the features and components of a vehicle subsystem are shown in Figures 5a and b in diagrammatic form.
  • the vehicle subsystem communicates with a monitoring process of the system control computer to provide updated information regarding the location and status of each vehicle in the fleet of shared vehicles.
  • the vehicle subsystem obtains information from instruments within the vehicle such as the odometer (510) and battery charge indicator (520), as well as engine and transmission monitoring devices (530).
  • the state of charge of the traction and auxiliary batteries is preferably determined according to methods disclosed in United States patent 5,614,804, the disclosure of which is incorporated herein by reference.
  • Vehicle status information together with vehicle-specific identification information is broadcast periodically, preferably every 30 seconds by a transponder (535) installed within the vehicle. Signals broadcast by the transponder also permit vehicle location to be determined by, for example, radio beacon triangulation. Other techniques known in the navigation field, previously mentioned, may also be used. In the presently preferred embodiment, vehicle status and location information is relayed to a system/vehicle interface by Teletrac® .
  • the vehicle subsystem includes a programmable processor (“microcontroller”) 540 that receives inputs from instruments, gauges and other devices for providing information regarding vehicle status.
  • the microcontroller is a Motorola model 68HC11.
  • the microcontroller In addition to monitoring vehicle status information, the microcontroller also provides secure access to the vehicles. User ID and PIN information is broadcast to each vehicle and stored in the microcontroller, at the time the vehicle is allocated by the system control computer, to insure that only authorized Users may operate the vehicle.
  • the microcontroller compares the User ID information provided by a card reader (575), accessible from the exterior of the vehicle and PIN information entered in a multi display terminal ("MDT") (565) with the values provided by the system control computer to verify the identity of a User attempting to access the vehicle.
  • MDT multi display terminal
  • the microcontroller also controls powered door locks (545) in response to commands from the system control computer.
  • the microcontroller also controls the vehicle ignition system (550), thereby enabling or disabling the electrical motor that powers the vehicle.
  • the microcontroller preferably includes random access memory (RAM) (555) and electrically programmable read only memory (ROM) (560).
  • RAM random access memory
  • ROM electrically programmable read only memory
  • staff ID information is stored in an electrically erasable programmable read only memory.
  • the staff ID information remains stored in the E2-PROM when the vehicle is turned off.
  • the microcontroller sends vehicle status information to a monitoring process running on the system control computer to provide constantly updated vehicle status and location information.
  • the microcontroller Upon arrival at a port at the conclusion of a trip, the microcontroller performs a shut down sequence and waits for another trip request from the system control computer.
  • each vehicle is tracked by the TeleTrac system, and this would not create any problem while the vehicle is in motion. Because, even if the vehicle moves into a blind spot for the system, the vehicle will eventually come out of the blind sport, and the system will be able to locate the vehicle. However, it is possible that the port in which the vehicle is located may not be covered by the TeleTrac system. It may be so due to the unfortunate selection of the location of the port or a temporary problem with the TeleTrac system. In either case, any failure to locate a vehicle by the system renders the vehicle unavailable for use even though the vehicle may be sitting idle in the port.
  • each port may be provided with a short-range radio communication system for locating the vehicles in the particular port. Because the vehicle is located by the TeleTrac system once outside the port, the proposed system may be considered as a hybrid system in the sense it combines the global locating system by TeleTrac and the local locating system at each port using the short-range radio communication, and can provide a high reliability at a low cost.
  • Such a hybrid communication system is valuable in other situations as well.
  • the user initially enters data on his trip needs and his ID from the touch panel and the card reader of the computer subsystem, respectively.
  • the system assigns a vehicle which suits his needs, and permits the door of this vehicle to be unlocked simply in response to a swiping of the correct ID card at the vehicle. It is accomplished by the central control computer directly communicating with the vehicle subsystem, typically via a public cellular phone service.
  • Such a public cellular phone service may not be entirely reliable. Should the system fail to operate properly due to a breakdown of communication, the authorized user would not be able to unlock the door or use the vehicle. Such an occurrence can seriously damage the users' trust of the system. Conversely, should the system fail to detect the completion of the use of a vehicle by the user due to a breakdown of communication, the charge to the user would continue to run even after he has released the vehicle, and this would lead to serious consequences.
  • a convenient arrangement would be to mount a radio transceiver in each vehicle to allow the vehicle to communicate directly with the computer subsystem of the port in which the vehicle is located.
  • the user can at least unlock the door and start the vehicle even if the system fails to operate properly once the vehicle is assigned to the user.
  • the vehicle When he parks the car outside the ports, it is essential that he can gain access to the vehicle, and start it even when the system is unable to operate properly.
  • the vehicle subsystem reverts to a low power state when the vehicle subsystem detects that the vehicle is idle, as when the transmission is set to "park" or the electric motor is off.
  • low power mode no power is supplied the vehicle electric motor, the card reader or MDT, and the transponder is in a low power or "listening" mode in which it can respond to signals from the system control computer, but does not broadcast signals for determining vehicle location or status.
  • User ID and PIN information are transmitted to the vehicle's microcontroller from the system control computer at block 610 by radio frequency transmission.
  • the information is transmitted using a commercial system operated by Teletrac.
  • a specialized RF link between the computer subsystem at the port and the vehicle is used to transmit User ID and PIN information to improve the reliability of data related to vehicle security. If the receipt of User ID and PIN information by the vehicle subsystem is not acknowledged (block 615) the system control computer reverts to an initial state (block 605).
  • User ID and PIN information are stored in random access memory in a vehicle's microcontroller at block 625.
  • Receipt of these signals restores the transponder to fully operational mode (block 630); power is also supplied to the MDT and card reader, causing those systems to also become operational. If a vehicle is assigned to a staff member, receipt of Staff ID information will also restore the vehicle subsystem to fully operational mode,
  • the card reader After power-up the card reader waits for input of User or staff ID information by card swipe (block 635) for a predetermined period; for example, the waiting period may be five minutes. If a card swipe is not detected in 5 minutes, the vehicle subsystem returns to a low power condition (block 640).
  • User ID or staff ID information input from the card reader is compared with User ID or staff ID information previously received and stored in random access memory in the microcontroller at block 645. Access to the vehicle is permitted, for example, by unlocking the vehicle's doors if User ID or staff ID information matches that received from the system control computer and stored in the memory of the microcontroller (block 650). If a User does not input User ID or staff ID information or if the User ID or staff ID information that is input is not correct, within a predetermined period, for example three minutes the vehicle doors do not unlock and both the card reader and MDT return to low power states. The User may be instructed to begin the registration process at the kiosk.
  • a User has provided correct User ID or staff ID information, and gained access to the interior of a vehicle, the User's assigned PIN number must be entered into the MDT by, for example, pressing appropriate keys on a key pad connected to the MDT at block 655.
  • a User is permitted to enter the correct sequence a predetermined number of times, for example, five times (block 660). If the correct PIN has not been entered after the specified number of attempts, or three minutes have elapsed since the User began entering a PIN number, the User will be instructed to repeat the registration process at the kiosk, and the doors to the vehicle will lock, after allowing the User a period of time to exit the vehicle (block 665).
  • the vehicle may be driven after the correct User ID and PIN information are provided, as the ignition is then enabled (block 670). At that time, vehicle status information is transmitted from the vehicle subsystem to the monitoring process of the system control computer as described in more detail below.
  • a first level of security is provided by requiring an ID card with the correct facility information to enter a kiosk.
  • a second level of security is provided by the requirement for proffer of valid User identification to be assigned a vehicle.
  • a third level of security is provided at the vehicle where the User must enter valid identification information (for example, by swiping a card key or token) to gain access to the vehicle.
  • a fourth level of security is provided by the requirement that, once the User enters the vehicle, the User must input a PIN that corresponds to the same User associated with the identification information.
  • each of these entries must be made within a preset period of time.
  • vehicle status data is transmitted from the vehicle to the vehicle data base.
  • a system operator can monitor the progress of each vehicle in use via a graphical User interface.
  • a User arrives at a station -- though not necessarily the destination specified -- parks and exits the vehicle, the User is automatically logged off the system.
  • the vehicle is locked and made available for use by others. If the car is parked elsewhere, as during an errand trip, the system still locks the vehicle, but the vehicle remains assigned to the same User.
  • the User can reenter and activate the vehicle by presenting his smart card and PIN number at the vehicle card reader and MDT as previously described.
  • Figure 7 illustrates how the system control computer communicates with Users while driving vehicles as necessary, and tracks vehicle use.
  • the vehicle subsystem receives a message from the system control computer. For example, a message "please charge your vehicle” may be sent if the system control computer determines that the state of charge is too low to reach the destination vehicle port. A User may reply "Yes", or "No.” Other messages exchanged between a vehicle and the central station could include emergency conditions, such as an accident, or a flat tire.
  • the message once received, is displayed on the MDT of the vehicle subsystem (block 715).
  • the microcontroller is programmed to acknowledge receipt of the messages from the central control computer (block 720). If a message is not acknowledged, the system attendant is alerted to the malfunction. (block 725) and the program halts. If a User reply is detected at block 730, the reply is broadcast to the system control computer at block 735.
  • the system control computer interrogates the vehicle at block 740 to determine if the vehicle is parked. If it is determined that the vehicle is not parked, the flow of Fig. 7 repeats.
  • a follow-up signal is sent from the microcontroller to set the ignition to an "off" condition at block 745.
  • the system control computer determines whether the vehicle is in a port at block 750. If the vehicle is determined to be at a port, at block 750 in Fig. 7, the system control computer sends a command to the vehicle to end the current User (block 755). The MDT jumps to its initial state, clearing random access memory. At the same time, the card reader and MDT are turned off and the transponder returns to listening mode.
  • the vehicle remains assigned to the same User, and the vehicle's doors lock.
  • the assigned User follows the same protocol to access the vehicle similar to Figure 6 except block 610 and 625. The user swipes his smart card to unlock the vehicle and enters his PIN in the MDT. If either the User ID or PIN does not correspond to the assigned User, the vehicle does not respond, but waits for the correct information to be provided.
  • vehicle status information is transmitted as a radio frequency signal from the vehicle subsystem to the system control computer.
  • This information may include the state of charge of the vehicle (in electrical vehicles) and other operational parameters such as odometer reading, speed, and actual usage or drive time, and whether the vehicle is charging.
  • Vehicle location may be determined from the relative strength of the signals broadcast, according to all known methods. In the presently preferred embodiment, a commercial system using triangulation algorithms is used.
  • Information is transmitted from the vehicle subsystem 18 to a vehicle monitoring process of the system control computer at periodic intervals. In the presently preferred embodiment, the interval is 30 seconds.
  • system control computer may readily track each vehicle in the fleet and allocate vehicles based on information that is current, as described above.
  • system control computer may monitor the state of charge of vehicles for purposes of alerting Users and port facility attendants of the need to recharge a vehicle.
  • a User interface including an MDT (565 in Fig. 5) display similar information to the User, for example, usage time, state of charge or other vehicle parameter such as notices or travel information sent from the system control computer.
  • the system control computer may send a warning to a vehicle, to inform the User that the state of charge of the vehicle is low or has experienced an unusual fluctuation. The User may be informed to return the vehicle to the nearest port or to simply connect the vehicle to a charger, upon the User's scheduled return.
  • the duration of trips may be predicted. This is especially true when the trips are direct trips, as the distance of the trip will be reasonably uniform. On the other hand, because the distance covered during errand trips will vary, data from such trips is less useful in predicting trip duration. Expected trip duration may be used to determine whether a User has encountered difficulty during a trip. For example, if the arrival of a user at a port is delayed, a system attendant may contact the user by way of the vehicle subsystem.
  • Staff members may be required to perform different tasks to ensure that vehicles are available for use. More specifically, staff members may have to relocate vehicles if there are not a sufficient number of vehicles at particular ports. Relocation may be accomplished by driving a vehicle or by towing it with another vehicle. Staff members may also have to charge electrically powered vehicles, or to recover a vehicle that is abandoned or is inoperable.
  • One of the primary purposes of the system is to provide sufficient vehicles at each station to meet the demand of system Users.
  • the distribution of vehicles at stations become imbalanced, the condition is detected, and vehicles are relocated to correct the imbalance in vehicle distribution.
  • staff members may have to relocate vehicles. Relocation may be accomplished by driving a vehicle or by towing it with another vehicle. Staff members may also have to charge electrically powered vehicles, or to recover a vehicle that is abandoned or is inoperable.
  • a staff member swipes his card key at a kiosk. The staff member's card is read by the card reader, and ID information read from the card is sent to the host computer.
  • the system control computer recognizes the ID information as that of a staff member, the staff member is presented with a menu of potential destinations to which relocation of vehicles is required. The staff member selects a location to which he will relocate a vehicle.
  • the system displays the status of each vehicle, including state of charge and maintenance required, if any.
  • the staff member selects the vehicle to be relocated, and sends his selection to the system control computer.
  • the system control computer sends the ID and PIN of the staff member to the vehicle to be relocated, which is stored in the vehicle microcontroller.
  • the staff member swipes his key card past the card reader attached to the vehicle.
  • the staff member moves the towing vehicle into position, arranges the towing gear, and drives the towing vehicle to the destination with the towed vehicle attached by towing gear.
  • the staff member disconnects the towing gear, and parks the vehicles.
  • a staff member may drive the vehicle requiring relocation. After relocation, the relocated vehicle is available for inclusion into a vehicle search group.
  • the staff member If the vehicle requires charging, after the staff member's ID and PIN are recognized, the staff member enters the vehicle and opens the charge hatch door. The staff member attaches the charging equipment to the receptacle on the vehicle. The vehicle is then charged, and returned to the fleet of available vehicles.
  • Computer subsystems (805 in Figure 8) correspond to the registration component. Computer subsystems are located at a vehicle port to allow Users to input vehicle requests, and staff members to assess the condition and location of vehicles, as required.
  • the management component is embodied as a system control computer (810) which assigns vehicles to Users in response to requests according to a method to be described below, monitors vehicle location and status, and provides an operator interface for intervention as may be required.
  • the vehicle component is embodied as a vehicle subsystem that allows monitoring of vehicle location and status as well as bidirectional communication between the central station and Users operating vehicles.
  • the system control computer (810) receives requests for vehicles from computer subsystems (805) which may be located in kiosks.
  • Vehicle request information including a kiosk identifier, User ID data received by the card reader, and data entered by Users is transmitted to the management component, preferably by way of the Internet using conventional TCP/IP protocol. Alternate embodiments based on dedicated networks are also within the scope of this invention.
  • the User interface of each computer subsystem preferably comprises a client computer, including a keyboard, and other input and output devices such as a card reader for reading smart cards or the like, and a touch screen that is capable of displaying color images.
  • the registration process of the system control computer is a web server that uses scripting language routines to communicate with the computer subsystems.
  • Each vehicle in the vehicle sharing system is equipped with a vehicle subsystem 815 installed in each vehicle of the vehicle sharing fleet which includes a microcontroller (540 in Figure 5) capable of monitoring vehicle functions as well as processing and storing data related thereto, a multidisplay terminal (MDT 565 in Figure 5) for displaying messages to the vehicle from the system control computer, as well as for sending messages to the system control computer, such as entry of PIN numbers, and a transponder that transmits signals for determining vehicle location, as well as vehicle status data.
  • a vehicle subsystem 815 installed in each vehicle of the vehicle sharing fleet which includes a microcontroller (540 in Figure 5) capable of monitoring vehicle functions as well as processing and storing data related thereto, a multidisplay terminal (MDT 565 in Figure 5) for displaying messages to the vehicle from the system control computer, as well as for sending messages to the system control computer, such as entry of PIN numbers, and a transponder that transmits signals for determining vehicle location, as well as vehicle status data.
  • the vehicle subsystem transmits data to and receives messages from the system control computer by, for example, radio frequency transmission, or other wireless link.
  • Received data is converted by the system control computer to machine readable code by an interface (820), which communicates with a monitoring process (825), further described below, in the system control computer.
  • the interface comprises two subsystems: a system interface for providing vehicle location data, and a communications interface for decoding vehicle status information and converting it to a format compatible with the shared system data base.
  • the system control computer and interfaces are located at the central station.
  • the system control computer is preferably located in a secure environment, such as a secure office building, where access to data relating to User identification codes and other sensitive or private information may be controlled.
  • the system control computer includes a registration process that communicates with computer subsystems (805).
  • the registration process allocates vehicles in response to requests by Users and staff through computer subsystems. Vehicles are made available to Users in response to requests in accordance with the method already described.
  • An advantage of the network implementation of the invention is its flexibility.
  • a port vehicle may be placed anywhere that access to the Internet is available.
  • the system is therefore accessible from any computer with access to the Internet.
  • Users of the system may access the system remotely, for example to make reservations for shared vehicles, to determine if vehicles are available at a port, to determine how long a wait there is for a vehicle, to apply for membership in the vehicle sharing system or for other reasons.
  • the steps carried out by the registration process are described in detail below.
  • the registration process employs information stored in data bases maintained by a monitoring process that runs concurrently on the system control computer in allocating vehicles. These data bases include user data (830), vehicle data (835) and request data (840).
  • the monitoring process updates the data bases with data received from the vehicle and computer subsystems. In preferred embodiments vehicles are polled at 30 second intervals, the interval calculated from the beginning of each trip, and the data bases are updated continuously, as data becomes available.
  • the operation of the system control computer is summarized in Figures 9-14, and is described below.
  • the registration process receives personal ID information together with the identity of the kiosk from which a request is sent.
  • the personal ID information is checked against User data (850) to determine if the request is from an authorized User, and if so, whether the personal ID information is assigned to Staff Member (950) to the more general class of Users (940). If the personal ID information is not recognized, a signal that the personal ID is invalid is sent to the kiosk (block 960). If the User ID is invalid, an appropriate message (Signal 1) is sent to the computer subsystem at block 970.
  • this signal, and others sent from the registration process to the computer subsystems is a web page.
  • a complete message may be stored at the at the client computer, and called by a signal from the central system computer.
  • the message may be called as a subroutine at the local computer.
  • signal 2 is sent to the computer subsystem to request the User to provide the destination to which he wishes to travel. From the destination input by the User (1015) the corresponding distance is determined from information stored in the request data portion of the shared system data base (840). Following receipt of the destination information, signal 2.5 is sent to request whether the trip is to be a Direct Trip or an errand trip, as previously defined (1020). If the response received at block 1025 is that the trip is to be an errand trip, then program flow continues to determine the additional distance and time that the trip is expected to require (1035-1050).
  • the result of the calculation is the minimum state of charge required for the trip requested, expressed as a percentage of the total charge the vehicle's battery can accommodate.
  • a vehicle allocation algorithm determines which vehicles match the User's request based on current information stored in the vehicle data portion of the shared system data base (Fig. 8, block 835).
  • a vehicle search group is defined for the port from which a User wishes to depart.
  • the vehicle search group includes vehicles located and parked at the port that are not presently allocated to other Users.
  • the vehicle search group may also include vehicles expected to arrive at the port facility within a pre-defined time period. Vehicles scheduled to leave the port for transfer to another port or otherwise are excluded from the vehicle search group.
  • the pre-defined time period is selected to minimize User-waiting time, yet maximize vehicle usage efficiency, by, for example, minimizing energy usage. If there is only one vehicle available with sufficient charge to make the requested trip, that vehicle will be offered at block 1090. If there are two or more vehicles available with sufficient charge, the vehicle with the second greatest state of charge will be offered to the User. In alternative embodiments, all vehicles with sufficient charge may be offered.
  • the system will offer the vehicle with the highest state of charge.
  • a warning is provided to the User requesting the vehicle informing the User that the state of charge may be insufficient for the trip requested (block 1080).
  • the vehicle fleet is made up of specially modified Honda minivans
  • different types of vehicles may be offered to Users.
  • the vehicle allocation will take into account the passenger capacity of each vehicle in the vehicle fleet.
  • signal 2 is sent to the computer subsystem from which the request was received, resulting in display of a message asking the staff member to input his intended destination.
  • the registration process receives the Staff Member's destination from a computer subsystem at a kiosk at block 1220.
  • the registration process determines the distance and time that the requested trip is expected to require based on information previously stored in the User portion of the shared system data (Fig. 8, block 840). The distance and time data is then stored to the request data base at block 1240.
  • the status of all vehicles is retrieved from the vehicle data base.
  • those vehicles in the vehicle search group corresponding to the port from which the request is made, together with their status, is sent to the computer subsystem at the port.
  • the Staff Member selects a vehicle at block 1270, and at block 1280 the User-ID and PIN of the staff member are sent to the selected vehicle.
  • the system determines that vehicle relocation is required, as for example in the algorithm disclosed above, Users may be asked to relocate vehicles. If during vehicle allocation, the monitoring process determines a need for vehicle relocation (block 1310), the User is presented with a short set of questions to determine whether a passenger might drive a vehicle that requires relocation to the passenger's intended destination.
  • the User is asked whether the trip requested is a destination or an errand trip. If the trip requested is an errand trip, the User is not asked to assist with relocation and the program flow returns to the vehicle assignment method of Figure 6. If at block 1330 the User responds that only one person will be making the requested trip, then there is no extra driver for vehicle relocation and program flow continues with vehicle assignment according to the method of Figure 6. If there is a least one passenger in the requested trip (block 1330), then at block 1340 a vehicle is offered for relocation by a passenger. At block 1350 the passenger accepts or declines the offer. If the offer is accepted, the passenger swipes his smart card past the card reader at the computer subsystem, and at block 1370 the appropriate data is sent to the vehicle for assignment to the passenger. At block 1380 the number of the vehicle assigned is sent to the computer subsystem. At block 1280, the passenger either accepts or declines the vehicle offered. The flow of Figure 11 repeats until there are no additional passengers available to relocate vehicles.
  • a real time data base is used as part of the monitoring component.
  • the data base is implemented as a set of shared tables accessible to both the monitoring and registration processes.
  • the tables contain data from the various subsystems, or from algorithms that use and refine the date.
  • Data management is handled by commercial data base engines, such as Microsoft Access.
  • the data bases are used for a variety of tasks, including vehicle allocation, calculation of the time and distance a trip requires, as well as tracking and monitoring vehicle status. Other tasks that may be implemented through the data bases include improving the prediction of vehicle arrival times, and determining when vehicle relocation will be necessary.
  • Fig. 8, 830 there are three shared system data base User Data (Fig. 8, 830) includes records of User information and statistics, such as the time required for travel to particular destinations, at different times of the day, as well as a record of the system by registered Users.
  • a request data base (840) contains a record of requests for vehicles and allocation information for each vehicle is maintained.
  • the vehicle data base 835 contains information about vehicle status, including requests that cannot be immediately filled, for lack of a vehicle or in the case that the vehicle is, for instance an electrical vehicle, lack of a vehicle with sufficient battery charge.
  • the vehicle use data base may be accessed by a User having rights to access the wait request data base from a remote computer, such as the computer subsystem located at a kiosk.
  • the monitoring process updates information in the shared system data base using information broadcast from vehicles concerning vehicle status and location.
  • the monitoring process controls and communicates with the vehicle fleet by way of computer and telecommunication equipment.
  • the monitoring process is implemented on three computers: 1) a data transmission computer that manages communication between the system control computer and the RF (radio frequency) messaging network; 2) a fleet management computer that initiates and monitors messaging and location of the vehicle fleet; and 3) a control computer that generates and records all messages sent to and from the fleet management computer and carries out protocols necessary for system operation.
  • the fleet management computer runs commercially available "fleet director" software. It is the integration of the control computer with the fleet management computer that creates a unified shared vehicle system.
  • Data from the vehicle fleet is constantly monitored.
  • the vehicle request data base is immediately updated.
  • the monitoring process also observes the use request portion of the data base.
  • the monitoring process prepares the allocated vehicle for use. This includes transmitting the appropriate User ID and PIN information to the vehicle, to insure that the allocated vehicle is made available to the User that submitted the corresponding request.
  • the monitoring process also keeps track of the distance driven so that the User may be charged for the use made of the vehicle, to warn the User if the distance driven may be in excess of the battery charge available, and to insure that the vehicle is not taken away from the area.
  • GUI graphical user interface
  • the GUI is configured to allow the system operator to observe the location of each vehicle in a map based environment.
  • the GU[ also allows operating data for a selected vehicle to be reviewed.
  • the GUI allows the system operator to send specific messages to individual vehicles.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)
EP01305580A 2000-06-28 2001-06-27 Surveillance dans un système de partage d'utilisation de véhicule Expired - Lifetime EP1176571B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US60752400A 2000-06-28 2000-06-28
US607524 2000-06-28

Publications (2)

Publication Number Publication Date
EP1176571A1 true EP1176571A1 (fr) 2002-01-30
EP1176571B1 EP1176571B1 (fr) 2005-10-19

Family

ID=24432638

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01305580A Expired - Lifetime EP1176571B1 (fr) 2000-06-28 2001-06-27 Surveillance dans un système de partage d'utilisation de véhicule

Country Status (4)

Country Link
EP (1) EP1176571B1 (fr)
JP (1) JP2002074574A (fr)
AT (1) ATE307369T1 (fr)
DE (1) DE60114100D1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1847969A1 (fr) * 2006-04-19 2007-10-24 Mobility Genossenschaft Systèmes et méthodes de contrôle d'accès au véhicule
EP2012264A1 (fr) * 2007-06-22 2009-01-07 Laurens Maria Schimmelpenninck Système de distribution de véhicule
ITMI20091438A1 (it) * 2009-08-07 2011-02-08 Twist S R L Procedimento e sistema di gestione e controllo di singoli veicoli, in particolare di singoli autoveicoli, autocarri ed autobus di flotte di autoveicoli, autocarri ed autobus rispettivamente.
FR2971876A1 (fr) * 2011-02-22 2012-08-24 Adm Concept Systeme et procede de gestion du fonctionnement d'un vehicule electrique destine a etre partage par plusieurs utilisateurs.
CN106846585A (zh) * 2017-02-13 2017-06-13 上海量明科技发展有限公司 安全型共享交通工具及实现方法、安全装置和系统

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003006787A (ja) * 2001-06-21 2003-01-10 Nissan Motor Co Ltd 車両共同利用システム
KR101271412B1 (ko) 2011-10-28 2013-06-05 주식회사 피엠그로우 주차장 전기차량 충전 시스템 및 방법
FR3033438B1 (fr) * 2015-03-06 2018-01-12 Pvp Technologies Canada Inc. Dispositif, systeme et procede pour le partage de vehicules

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0451482A1 (fr) * 1990-02-27 1991-10-16 Israel Hirshberg Système de location de voitures
FR2732144A1 (fr) * 1995-03-24 1996-09-27 Peugeot Systeme de gestion d'un parc de vehicules urbains notamment electriques
US5726885A (en) * 1994-08-23 1998-03-10 Daimler-Benz Ag Hire vehicle transportation system
EP0991031A2 (fr) * 1998-09-30 2000-04-05 Honda Giken Kogyo Kabushiki Kaisha Système de partage d'utilisation de véhicules
EP1011085A2 (fr) * 1998-12-07 2000-06-21 MANNESMANN Aktiengesellschaft Procédé d'allocation de véhicules

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0451482A1 (fr) * 1990-02-27 1991-10-16 Israel Hirshberg Système de location de voitures
US5726885A (en) * 1994-08-23 1998-03-10 Daimler-Benz Ag Hire vehicle transportation system
FR2732144A1 (fr) * 1995-03-24 1996-09-27 Peugeot Systeme de gestion d'un parc de vehicules urbains notamment electriques
EP0991031A2 (fr) * 1998-09-30 2000-04-05 Honda Giken Kogyo Kabushiki Kaisha Système de partage d'utilisation de véhicules
EP1011085A2 (fr) * 1998-12-07 2000-06-21 MANNESMANN Aktiengesellschaft Procédé d'allocation de véhicules

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1847969A1 (fr) * 2006-04-19 2007-10-24 Mobility Genossenschaft Systèmes et méthodes de contrôle d'accès au véhicule
EP2012264A1 (fr) * 2007-06-22 2009-01-07 Laurens Maria Schimmelpenninck Système de distribution de véhicule
ITMI20091438A1 (it) * 2009-08-07 2011-02-08 Twist S R L Procedimento e sistema di gestione e controllo di singoli veicoli, in particolare di singoli autoveicoli, autocarri ed autobus di flotte di autoveicoli, autocarri ed autobus rispettivamente.
FR2971876A1 (fr) * 2011-02-22 2012-08-24 Adm Concept Systeme et procede de gestion du fonctionnement d'un vehicule electrique destine a etre partage par plusieurs utilisateurs.
CN106846585A (zh) * 2017-02-13 2017-06-13 上海量明科技发展有限公司 安全型共享交通工具及实现方法、安全装置和系统

Also Published As

Publication number Publication date
ATE307369T1 (de) 2005-11-15
DE60114100D1 (de) 2005-11-24
JP2002074574A (ja) 2002-03-15
EP1176571B1 (fr) 2005-10-19

Similar Documents

Publication Publication Date Title
US6975997B1 (en) Method for efficient vehicle allocation in vehicle sharing system
EP1067498B1 (fr) Méthode et dispositif pour la réservation partagée des véhicules avec la charge électrique majeur
US6941197B1 (en) Vehicle sharing system and method with vehicle parameter tracking
US6636145B1 (en) Vehicle sharing system and method with parking state detection
US6253980B1 (en) Shared vehicle system and method with system for carrying a first vehicle with a second vehicle
US6850153B1 (en) Vehicle sharing system and method for controlling or securing vehicle access and/or enablement
US6947881B1 (en) Shared vehicle system and method with vehicle relocation
US6850898B1 (en) Vehicle sharing system and method for allocating vehicles based on state of charge
US11587370B2 (en) Distributed maintenance system and methods for connected fleet
EP1172768A2 (fr) Procédé d'affectation efficace de véhicules dans un système de partage d'utilisation de véhicules
EP1067480A2 (fr) Système de partage d'utilisation de véhicules et méthode avec affectation de véhicules basée sur données de parcours
US10360518B2 (en) Shared vehicle management device
US11847695B2 (en) Credit screening support system, vehicle-mounted device, vehicle, server, credit screening support method, credit screening support program, and storage medium
US11055638B1 (en) Method for shared vehicle utilization management
EP1176571B1 (fr) Surveillance dans un système de partage d'utilisation de véhicule
EP1170706A2 (fr) Entrée sans clef pour un système de partage d'utilisation de véhicules
EP3901857A2 (fr) Dispositif d'expansion d'e/s de véhicules partagés
US11210612B2 (en) Method for shared vehicle maintenance and recovery
EP3901844A1 (fr) Système de partage et de surveillance de véhicules
JP2001090405A (ja) 車両セキュリティシステム及びその方法
JP2002099985A (ja) 低電力消費モードを備えた車両共用システム
CN118816925A (zh) 一种电动车智能充电控制方法及相关设备

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: TODD, MICHAEL, DONOVAN

Inventor name: MURAKAMI, HIROSHI C/O KABUSHIKI KAISHA HONDA

Inventor name: NAKAMURA, KAZUHIRO KABUSHIKI KAISHA HONDA

Inventor name: YANO, SHUNJI C/O KABUSHIKI KAISHA HONDA

Inventor name: BARTH, MATTHEW, JAMES,

17P Request for examination filed

Effective date: 20020729

AKX Designation fees paid

Free format text: AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

17Q First examination report despatched

Effective date: 20030721

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT;WARNING: LAPSES OF ITALIAN PATENTS WITH EFFECTIVE DATE BEFORE 2007 MAY HAVE OCCURRED AT ANY TIME BEFORE 2007. THE CORRECT EFFECTIVE DATE MAY BE DIFFERENT FROM THE ONE RECORDED.

Effective date: 20051019

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20051019

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20051019

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20051019

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20051019

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 60114100

Country of ref document: DE

Date of ref document: 20051124

Kind code of ref document: P

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060119

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060119

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060119

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060120

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060130

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: DR. LUSUARDI AG

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060320

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
ET Fr: translation filed
PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060627

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060627

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060630

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060630

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060630

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20060720

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20060627

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20070228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20060627

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20051019

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20051019