WO2017205961A1

WO2017205961A1 - Management and control of driverless vehicles

Info

Publication number: WO2017205961A1
Application number: PCT/CA2017/000137
Authority: WO
Inventors: Matthew J. MARQUARDT
Original assignee: Marquardt Matthew J
Priority date: 2016-06-04
Filing date: 2017-05-31
Publication date: 2017-12-07

Abstract

Systems (100), methods, controllers, and associated devices and components for the management, control, operation, maintenance, and administration of autonomously- operable (self-navigating) vehicles (100), and particularly fleets of land vehicles. Disclosed improvements include devices (200, 300) configured to allow users (250) to control the operation of such vehicles; improved autonomously-guided (self- navigating) vehicles (100) and controllers (299) therefor; and improved processes for using each of the foregoing, as well as machine-readable and/or executable codes and instruction sets suitable for implementing any and all the above.

Description

MANAGEMENT AND CONTROL OF DRIVERLESS VEHICLES

FIELD OF THE INVENTION

[0001] The present disclosure relates to the management, control, maintenance, and administration of vehicles, and particularly to systems, devices, and methods for the management, control, and administration of driverless (i.e., autonomously operable) land vehicles such as cars, buses, and delivery trucks.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims all benefit, including priority, of United States Provisional Patent Application Ser. No. 62/345,778, filed 4 June 2016 and entitled MANAGEMENT AND CONTROL OF DRIVERLESS VEHICLES, the entire contents of which are hereby incorporated herein by reference.

BACKGROUND OF THE INVENTION

[0003] It is well known that systems, devices, and methods of use for the operation and management of vehicles used to transport people and all types of cargo are in need of improvement. In particular, improvements in the economic and environmental efficiency of operation of such vehicles are needed.

SUMMARY OF THE INVENTION

[0004] In various aspects and embodiments, the invention provides improved systems for the management, control, operation, maintenance, and administration of autonomously-operable (self-navigating) land vehicles, and particularly fleets of such vehicles; improved devices configured to allow users to control the operation of such vehicles; improved autonomously-guided (self-navigating) vehicles, and particularly land vehicles, and controllers therefore; and improved processes for using each of the foregoing, as well as machine-readable and/or executable codes and instruction sets suitable for implementing any and all the above.

[0005] Systems in accordance with the invention apply with particular advantage to shared-ride or shared-vehicle applications, such as driverless taxis, cargo delivery, etc. In such applications they provide significant improvements in the efficient use of such vehicles, with benefits for the environment, particularly where, as in preferred embodiments, electric, hybrid, fuel-efficient, propane-fueled, and other zero-emissions vehicles are used.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Various aspects and embodiments of the invention are illustrated in the accompanying drawings, which are meant to be exemplary and not limiting, and in which like references are intended to refer to like or corresponding parts.

[0007] Figure 1 is a schematic block diagram of an embodiment of a system for the management, control, operation, maintenance, and administration of a plurality of vehicles in accordance with various aspects the invention.

[0008] Figure 2A is a schematic diagram of an embodiment of an autonomous or self-navigating vehicle in accordance with an aspect of the invention. Figure 2B is a logical block diagram showing various modules and components configured for the management, control, operation, maintenance, and administration of the vehicle of Figure 2A.

[0009] Figures 3A and 3B are schematic diagrams of embodiments of user call and control devices suitable for use implementing various aspects of the invention. Figure 3C is a logical block diagram showing various modules and components configured for the management, control, operation, maintenance, and administration of the call and control of a vehicle using the devices of Figures 3A and 3B.

[0010] Figure 4 is a logical block diagram showing various modules and components of a controller configured for the management, control, operation, maintenance, and administration of a fleet of vehicles in accordance with the disclosure.

[0011] Figure 5 is a schematic signal-flow or signal-exchange diagram showing embodiments of signal exchanges between components of systems for the management, control, operation, maintenance, and administration of fleets of vehicle in accordance with the disclosure.

[0012] Figures 6A - 6B are schematic diagrams of vehicle control devices and displayed graphical user interfaces configured for controlling vehicles in accordance with the disclosure. [0013] Figure 7 is a schematic signal-flow or signal-exchange diagram showing embodiments of signal exchanges between components of systems for the management, control, operation, maintenance, and administration of fleets of vehicle in accordance with the disclosure.

DESCRIPTION OF EMBODIMENTS

[0013] In various aspects and embodiments, the disclosure provides systems, devices, and computer program products for the secure and efficient management, control, operation, maintenance, and administration of vehicles, which may be used with particular advantage in controlling driverless or otherwise autonomously- operated or operable land vehicles. The invention is particularly well suited to use with fleets of passenger cars, delivery vans and trucks, and other shared pools of vehicles. However, as will be apparent to those skilled in the relevant arts, once they have been made familiar with this disclosure, aspects of the invention may also be applied with significant advantage to the management, control, operation, maintenance, and administration of privately-owned and other dedicated or nonshared vehicles, and/or with drones and other types of aircraft.

[0014] An example of a system 1000 for the management, control, operation, maintenance, and administration of a plurality of vehicles 100 is shown in Figure 1. In the embodiment shown, system 1000 comprises a plurality (or 'fleet') of autonomously-operable (i.e., driverless, self-navigating, or autonomously-guided) vehicles 100, one or more of user vehicle call and control devices 200, at least one fleet or pool management and control system 300, and optionally one or more of each of independent call service systems 301 , maintenance or repair facility system(s) 400, emergency rescue and/or response system(s) 500, and financial service provider (FSP) system(s) 600. As will be apparent to those skilled in the relevant arts, once they have been made familiar with this disclosure, in various embodiments systems 1000 according to the invention may comprise any numbers and/or varieties of components 100, 200, 300, 400, 500, 600 consistent with the purposes disclosed or suggested herein; and in such embodiments some or all of components 400, 500, 600 may be optional. Depending upon the purpose(s) to which a particular system 1000 is to be put, for example, any or all of maintenance and or repair facility system(s) 400, emergency rescue or response system(s) 500 may not be necessary or desirable.

[0015] Vehicles 100 may include any type(s) of driverless or otherwise self- navigating or autonomously-operable vehicles suitable for the particular purpose(s) to which a particular system 1000 is to be put. For example, an embodiment of a system 1000 adapted for the provision of shared or pooled-use driverless passenger cars (i.e., passenger cars intended to be used by multiple, unrelated individuals, such as a car-share, limousine, or taxi system), may employ any number of self- navigating passenger cars, buses, or vans 102, 108, 110, which may be of various types and/or sizes in order to accommodate, for example, varying types and numbers of passengers, luggage or other belongings, etc. An embodiment of a system 1000 adapted for rapid and efficient transportation or delivery of cargo can comprise any desired numbers of driverless or otherwise self-navigating vans, panel trucks, or larger cargo trucks 104, and/or drone aircraft 111 , comprising any desired or required cargo space, environmental control system(s) such as refrigerators, etc. An embodiment adapted to include or accommodate repair, cleaning, maintenance, and/or other service of vehicles 1000 may comprise one or more tow, repair, provisioning, or service trucks 106, such as driverless fuel or food delivery vehicles, etc. An embodiment adapted for scheduled or charter passenger service, such as a transit system, may comprise one or more multi-passenger vehicles of various types or sizes, such as buses 110. Functions performed by vehicle(s) 100 can comprise responding to calls generated by user control devices 200, in accordance with authorization signals generated by or otherwise routed through control system(s) 300; navigating appropriately across city streets and/or other approved or otherwise suitable thoroughfares to respond to such calls; upon authorization from local, vehicle-mounted security devices, admit passenger(s) 250 and/or cargo to be placed in the vehicle; and to navigate to one or more user-designated destinations in accordance with authorizations and/or routings received from control system(s) 300.

[0016] Each of the components 100, 200, 300, 400, 500, 600 of a system 1000 may be communicatively linked to one another through a wide variety of communications means, including one or more data (i.e. signal) communication networks 800 comprising land line, wireless, and/or other forms of communication. As will be understood by those skilled in the relevant arts, communications means 800 may comprise any mobile, wireless and/or wire-line signal exchange systems, such as the internet and/or other public or private data communications network(s), telephone system(s) such as the public-switched telephone system (PSTN), etc. Such communications can be direct or routed by or via any one or other(s) of systems 100, 200, 300, 400, 500, 600 or other proxy systems. In such cases routed communications may be subjected to any of a wide variety of requirements or authorizations generated by any one or more of the systems 100, 200, 300, 400, 500, 600.

[0017] In various embodiments, various components of controller systems 300, including for example some or ail of data processor(s) 402; data communication system(s) 404, 410; and persistent memory storage device(s) can be implemented as components of one or more autonomously operable vehicles 100.

[0018] Many different types of mobile and/or stationary network communication devices, including for example any or all of specially-designed electronic 'keys' or fobs 201 , 202; smart or other mobile phones or personal digital assistants (PDAs) 203, 204; tablet and/or laptop computers 205; and/or stationary personal or server-class computers 206 may be adapted for use as various components of system(s) 1000, including various embodiments of vehicle request control devices, sometimes also and more simply referred to as "user control devices," 200 as described herein. As explained further below, user call and/or control devices 200 enable individual passengers, merchants, etc., to hail, summon, or otherwise call; access; and/or otherwise control vehicle(s) 100 for personal and/or cargo transport, by means, for example, of electronic signal exchanges with any or all of fleet or pool management and control system(s) 300, vehicle(s) 100, FSP(s) 600, etc. Such devices 200 can be adapted for a wide variety of further uses, including for example payment for vehicle services such as taxi rides and other peruse or periodic payments involving bilateral or multilateral signal exchanges with any or all of systems 300, 100, 600. They may also be employed by administrative, maintenance, repair, and/or emergency personnel as desired or as otherwise appropriate.

[0019] A fleet or pool management and control system 300 can comprise any one or more computers or other signal processors configured for control of vehicle(s) 100 through secure and controlled signal exchanges. As described in further detail below, functions provided by system(s) 300 can include assigning vehicle(s) 100 to calls or other requests for service generated by users 250 and routed by devices 200; routing assigned vehicles appropriately over city or other streets or thoroughfares; facilitation and processing of payments received for use of vehicles 100 via FSP(s) 600; monitoring and controlling of the performance and repair or maintenance needs of vehicles 100 as appropriate; monitoring the safety and security of passengers 250 and/or cargo carried by vehicles 100; and communicating with emergency and other services 500 in case of need, etc.

[0020] As will be appreciated by those skilled in the relevant arts, once they have been made familiar with this disclosure, individual servers acting as management and control systems 300 can be used to control any numbers of vehicles 100, or distinct fleets of vehicles 100. For example, a server acting as a system 300 can be used solely for the control of individual fleets, e.g., a fleet of buses belonging to a single municipal transit authority, or they can be assigned to control multiple fleets - for example, a fleet of rental vehicles, a fleet of taxis, and a fleet of cargo transport vehicles.

[0021] As will further be apparent to those skilled in the relevant arts, systems 300 can physically reside at any convenient or otherwise suitable location or locations. For example, they can be located in stationary facilities (e.g., buildings or communications towers) remote from or in close proximity to the vehicles 100 they control; and/or they can be located in or on general fleet or special purpose vehicles 100; and/or they can be located on mobile devices 200. They may also be implemented as land- and/or vehicle-based distributed systems using, for example, network cloud techniques.

[0022] Repair, maintenance, and/or other vehicle service system(s) 400 can comprise any one or more computers or other signal processors configured for controlling and implementing any periodic, contingent, or other repair, maintenance, or service of vehicle(s) 100 through secure and controlled signal exchanges. As described further below, functions provided by system(s) 400 can include calling self- navigating vehicle(s) 100 to designated repair or maintenance facilities for scheduled or occasional service or repair, in response to signals received from control system(s) 300, vehicle(s) 100, user(s) 250, and/or in accordance with maintenance schedules monitored and implemented by the system(s) 400 themselves. Routing of called vehicles appropriately over city or other streets or thoroughfares to maintenance or repair facilities, and returning serviced vehicles to holding stations to await further assignment(s), can be accomplished by any or all of systems 100, 200, 300, 400.

[0023] In various embodiments of the invention, routing of vehicle(s) 100 to locations designated by user(s) 250 by control system(s) 300 can be conditioned upon receipt of signals representing deposits made or otherwise administered by, or other payments or authorizations received from, one or more FSPs 600. For example, for an autonomous taxi service implementation, a user 250 may use her or his device 200 to request a control system 300 to send a driverless taxi to a specified location, and, in response to a request generated by the control system 300, to arrange payment through an electronic funds account administered or otherwise controlled by an FSP 600. Confirmation of payment or other authorization may be provided directly from the FSP system 500 to the control system 300 and/or to an assigned vehicle 100, and/or via an authorized confirmation signal routed to the control system or vehicle via the user device 200.

[0024] A further advantageous component of various embodiments of systems 1000 is the ability any or all of the components to communicate with one or more emergency service systems or controllers 500. For example, an emergency response system 500 may be informed of an accident, injury, or other incident involving a vehicle 100 and/or passenger 250, by any or all of user devices 200, vehicles 100, and/or control stations 300, 400. Thereafter emergency system 500 can communicate with any or all of devices 200, 100, 300, 400 to coordinate a suitable response, including for example, routing of a vehicle 100 to a safe or otherwise designated location, release of doors or other devices of the vehicle 100, stopping of the vehicle 100, and/or routing of one or more emergency vehicles to a location designated by any or all of systems 100, 200, 300, 400, 500.

[0025] General schematic diagrams of aspects of an autonomously-operable (e.g., driverless) vehicle 100 in accordance with the invention are provided in Figures 2A and 2B. Figure 2A is a schematic block diagram of an embodiment of an autonomous or self-navigating vehicle 100, and Figure 2B is a logical block diagram of a vehicle on-board controller 299, showing various modules and components that may be provided for the management, control, operation, maintenance, and administration of the vehicle of Figure 2A. In the embodiment shown, vehicle 100 is a passenger vehicle 102, 108 such as a pool, shared-ride, or taxi vehicle which may comprise cargo space 280, etc. As previously noted, further embodiments include passenger and/or cargo vans, trucks, and busses. The schematic diagrams of Figures 2A and 2B are intended to suggest only function features of various aspects of the invention, and not to limit the disclosure to specific embodiments. For example, the passenger and cargo spaces, and the locations of components 299, 254 can be provided in a very wide variety of locations on the vehicle, and in a very wide variety of configurations. Those shown in the figures should not be taken as limiting in any way; they are merely meant to be exemplary.

[0026] In general, as will be understood by those skilled in the relevant arts, an autonomously navigated vehicle 100 comprises any and all components required or otherwise desirable for accomplishing it intended purposes, as disclosed or otherwise suggested herein. In addition to engines, motors, and/or other source(s) of motive power; wings, wheels, or other means for movement over surfaces or through media; steering and suspension mechanism and associated power trains, passenger and cargo accommodations; interior and exterior headlights, including headlights, anti-collision lights, parking lights, etc., components of autonomous vehicles 200 in accordance with the invention include controller(s) 299 comprising any or all of the following.

[0027] It will be understood by those skilled in the relevant arts that each of the functional blocks shown in Figure 2B can comprise any components needed or desired in order to enable the corresponding functions to be performed. For example, each of the blocks can consist of, or comprise, any suitable dedicated or general-purpose software, firmware, and/or input/output device(s), including for example one or more separate and/or integrated software packages, processors, sensors, displays, etc. required for other otherwise useful in accomplishing the corresponding purpose. With particular respect to logical devices, individual functions can be performed by standalone special- and/or general-purpose computers; software programs, applications or routines; or by combined programming structures that accomplish multiple purposes. For example, vehicles built for the purposes described herein may comprise one or more central processing unit(s) CPUs communicatively linked to all desired sensors, displays, and other input/output devices, in a single, integrated package, while retrofitted vehicles may be fitted with one or more systems adapted to accomplish more discrete functions or sets of functions.

[0028] For example, in various embodiments one or more data/signal processors 257 handle required or otherwise desired data and signal processes suitable for implementing the many actions and responses required of the vehicle 100. Many of these are described above and below. Any suitable general- and/or special purpose data processors, including specially-designed integrated circuits, may be adapted for required and/or desired purposes. Optionally, processor(s) 257 comprise or otherwise work in conjunction with one or more clock(s) 287 to provide both internal synchronization and process requirements, and to schedule and otherwise facilitate time stamping of data sets representing requests and other command signals.

[0029] Network communications system(s) 251 , 252, etc. comprise any digital and/or analog wireless signal processors desired to enable the transmission and receipt of representing command and/or control data between any or all of systems 200, 300, 400, 500, 600 and 262, 266, 268, 270, 272, etc. as described herein. As explained further below, these can include transmission and receipt of signals representing passenger calls and instructions from system(s) 200 and/or 300; signals representing financial transactions with systems 200, 300, 600; signals representing routing instructions from system(s) 300, 200; emergency signals from or to emergency services system(s) 500; signals representing maintenance, repair, and service requests or instructions from system(s) 400, etc. Such signals can be formatted in accordance with known or specially-formatted protocols, including for example public or private radio and/or telecommunications protocols, using public and/or private wireless communications systems, including any or all of public and/or private wireless telephone, satellite, radio cellular, and other systems. A wide variety of suitable systems and devices are now known, and doubtless others will hereafter be developed. These employ any suitable known or specially-developed signal formats and protocols, including for example TDMA, CDMA, GSM, SSM, FIX, etc., and/or network protocols such as those used in communicating via packet-switched data communications networks such as the internet. [0030] Local (or "proximity") wireless communications system(s) 254 can comprise any one or more near-field wireless communications (NFC) devices; radio- frequency identification (RFID) devices; low-power and/or other short-range radio devices; magnetic-strip and/or embedded chip card-readers, etc., suitable for use by users 250 located in close proximity to the vehicle 100. These can for example handle exchange of signals suitable for the provision to the vehicle 100 by a user 250 of navigation, scheduling, vehicle access, and/or authorization or payment instructions, etc. A wide variety of suitable systems and devices are now known, and doubtless others will hereafter be developed. These employ any suitable known or specially-developed signal formats and protocols, including for example Bluetooth™ protocols, etc.

[0031] Input/output devices 258, 256, 260 such as keyboards, keypads, touchscreens, displays, and printers can be provided to facilitate entry and communication of instructions and other information by or to user(s) 250 and/or other persons, such as administrative, maintenance, and/or emergency response personnel located within, next to, and/or otherwise in close proximity to the vehicle 100 to any or all of the various vehicle functional systems or devices 262, 266, 272, 268, 270, etc., described below. For example, suitable keypads, display screens, and/or touchscreens can be provided on a dash board or other interior structure within the passenger compartment, within one or more compartments accessible from outside the vehicle, and/or on kiosks or other structures in suitable proximity to the vehicle.

[0032] Navigation system(s) 262 can comprise any sensors, actuators, controllers, and/or other devices suitable for enabling autonomous navigation and operation of the vehicle 100. These can, for example, include radar, sonar, optical, infra-red, and other sensors 264 adapted to enable processor(s) 257 to interpret and apply information representing the immediate, intermediate, and long-range surroundings and planned or otherwise desired routings of the vehicle, and thereby calculate immediate, intermediate, and long-term responses to be implemented through the use of engine accelerators and decelerators, brakes, steering controls, etc. 268. This can be accomplished, for example, by through use of system 262 to cause processor(s) 257 to generate and route to any of the controls 268 suitably- configured command signal sets. A wide variety of such devices suitable for use in implanting such systems are now available, and others are becoming available rapidly.

[0033] Navigation system(s) 262 can further comprise global positioning system(s) (GPS(s)) and/or other satellite or wireless position-monitoring systems 267, to enable the processor(s) 257 to determine the geographic position of the vehicle 100, as well as its direction, rates of travel, and rates of acceleration, etc.

[0034] Autonomously-operable land and airborne vehicles are currently undergoing development at a rapid rate. As the invention(s) disclosed herein are not primarily concerned with the immediate details of autonomous vehicle operation - e.g. , steering to avoid objects or to navigate corners, accelerating and/or braking to maintain appropriate vehicle spacings on crowded streets, etc. - it will be appreciated by those skilled in the relevant arts that enabling vehicles 200 to perform such functions, whether currently known or hereafter developed, in accordance with other aspects of the invention will not trouble those skilled in the relevant arts.

[0035] Inputs to navigation system(s) 262 can, for example, comprise instruction signal sets received from control system(s) 300 and/or user(s) 250 via input device(s) 200, 258, etc.; positioning, traffic, and route revision data from satellite system(s) 267; and/or local traffic data signals from sensor(s) 264, etc. Outputs can include informational data presented on displays 200 via communications systems 251 , 254, etc.; and command signals routed to any vehicle operational systems 268 such as steering, braking, and acceleration systems.

[0036] Call response module 266 can comprise any logical instruction sets, data, and/or hardware required or otherwise useful for enabling processor(s) 257 to interact with any or all of control system(s) 300, user device(s) 200, and/or onboard user input devices 258, etc., in order to enable the vehicle 100 to respond to calls for service or other passenger requests. Inputs can for example comprise information query signal sets adapted for presentation of input requests on display devices 258, etc. and call response data sets received from system(s) 300, 264, 267 in response to call request data sets generated by user(s) 250, for processing by processor(s) 257. Outputs can include navigational instruction sets configured for use by navigation system(s) 262 and devices 268, etc. in causing the vehicle 100 to respond to a call for transportation. Further details are described in conjunction with illustrative examples provided below.

[0037] Authorization module 222, which can comprise one or more payment and/or user identity confirmation modules, can comprise any instruction sets, data, and/or hardware required or otherwise useful for enabling processor(s) 257 to interact with any or all of user device(s) 200, local (e.g., vehicle-mounted) input/output systems 254, 256, 258, 259, control system(s) 300, and/or FSPs 600 to facilitate, confirm, or conduct all or any portions of any required payment, user identification, and/or other vehicle access authorization processes, and corresponding signal exchanges, including any or all of the examples disclosed herein. For example, a payment/confirmation module 268 can request or control sequestration of deposits or other funds required to cover a deposit or advance payment, and/or final payment on completion of transport/delivery services. Module 268 can be configured to accept any single or multiple payments; for example in a multi-passenger transport system 1000 (for example, a transit bus 110), payments can be accepted from any desired number of passengers 250 and/or accounts administered by FSP(s) 600. Payment / confirmation / authorization modules 268 can also comprise and/or otherwise interact with one or more point-of-transaction (POT, or point-of-sale POS) or other devices 259 for accepting real or virtual tokens, cards, coins, currency, or other forms of payment aboard a vehicle 100.

[0038] Alternatively, or in addition to the support of payment signal exchanges, authorization module(s) 222 can perform identification verification services, using for example secure data sets such as passwords and user names, biometric data or input, and other processes. For example, prospective passenger(s) may be required to present suitable credentials prior to being authorized to access vehicle passenger or cargo compartments 27, 280, cause the vehicle to start, etc.

[0039] NFC/RFID/Card/Cash acceptance and/or other POT-type devices or components 259 can be configured for direct and/or indirect communication with any or all of user device(s) 200, processor(s) 257, FSP(s) 600, control system(s) 300, etc., in order to accept payment or signals useful in completing payment transactions. One or more such systems can be provided on a vehicle 100, in such fashion that it may, for example, be accessed by a user 250 from the outside of vehicle 100 prior to access to the vehicle 100; and/or on the inside of the vehicle, depending on the type of component 254 and/or the purpose(s) for which it and an associated vehicle are intended.

[0040] Passenger, cargo, and or other payload compartment(s) 275, 280 can be provided in any desired numbers and configured to accept any desired number(s) and types of passengers 250, packages, luggage, and or other cargo or payload(s), including for example groceries, equipment, and other business products. Such compartments can comprise air conditioning, refrigeration, heating, lighting, audio, and other environmental control system(s) ECS(s) 294 deemed suitable for the purpose(s) to which the compartments will be put. As will be appreciated by those skilled in the relevant arts, the number, size and configuration of compartments 275, 280, and the nature and capacities of ECS and other equipment 294 provided therewith, can be determined by factors such as the type of vehicle 100 provided, the environment(s) in which it is to operate, the purpose(s) to which it is to be put, etc.

[0041] Passenger and vehicle security module(s) and/or system(s) 270 can comprise any logical instruction sets, data, and/or components or devices, suitable for controlling access to a vehicle 100, and/or otherwise aiding in the protection of the vehicle 100, passenger(s) 250, and/or cargo in payload compartments 275, 280, etc. For example, exterior door locks 293 controlled by security and NFC and/or RFID components 270, 254, 288 adapted to interact with user devices 200 - 204, 314; cameras, passenger seat or cargo floor weight sensors; microphones, speakers, smoke, infrared, motion, or shock detectors; and other vehicle security monitoring devices, and/or other input devices 258, 271 installed within or in suitable proximity to a passenger and/or cargo compartment 280, 275, etc., can be configured to exchange signals with processor(s) 250 and/or NFC/RFID/card sensors 254; and/or fingerprint, retina scan, voice and/or facial recognition and/or other biometric sensors 288 to accept and process data confirming the identity(ies) of users 250 prior to unlocking doors 290; to confirm that passenger(s) 250 and/or cargo are located appropriately in compartments 275, 280; to monitor the passenger and/or cargo compartments for sounds of alarm or emergency; to accept voice instructions or requests from users 250, etc.

[0042] For example, infrared, heat detectors, smoke detectors, seat weight sensors, microphones, cameras, motion and other detectors 271 can be used to monitor the condition of the passenger and/or cargo compartments 275, 280 of a vehicle 100 prior to unlocking any of doors 290 to admit new passengers 250.

[0043] Security system(s) 270 can further be configured to accept navigation override commands from microphones (e.g., through the use of voice recognition software), keypads or other onboard input devices 258, control system(s) 300, 500, 400, etc., and/or under appropriately secure conditions (such as when operating secure vehicle control applications) user control devices 200, to alter or correct vehicle navigation routes in response to emergencies or vehicle needs, or other previously-unscheduled activities, including for example refueling requirements, restroom breaks, food breaks, etc. For example, a security system 270 can be configured such that, upon generation by any of sensors 271 , 258, etc., of signals associated with passenger or cargo distress, it generates signals suitable for alerting a control system 300 and/or emergency response system 500 of dangerous condition(s) within the vehicle 100; and receive from such systems 300, 500, etc., and/or from onboard memory(ies) 286 receive or otherwise access signals or data representing the location of a police station, fire station, hospital, ambulance, or rendezvous point, and use such signals to generate and route to vehicle navigation control(s) 262 signals suitable for causing the vehicle to proceed thereto.

[0044] Emergency alarm/call buttons 258, 271 can be provided in compartments 275, 280, and/or on the exterior of a vehicle 100 for activation by users 250 or other individuals inside or outside the vehicle 100 to generate alarm signals configured to alert any or all of systems 300, 500, 400 to emergency or other priority situations concerning passengers 250, etc.

[0045] Voice recognition systems 271 can also be provided, along with passenger and/or cargo compartment microphones, whereby, for example, recognition of a cry for help can be used to generate exception reporting data sets.

[0046] In addition, security system(s) and/or modules 270 can be configured to scan compartments 275, 280 for forgotten or otherwise left property or forgotten people or animals (e.g., pets) prior to authorizing an autonomous vehicle 100 to leave the delivery point at which passengers and/or cargo are to be left, and to issue any suitable reminders using, for example, any output device(s) 256, 260, 200, 273, automobile horns, headlights, etc. to notify a user 250. [0047] Any or all of processor(s) 257, navigation system(s) 262, and/or security system(s) 270 can interact with each other, and/or with controller(s) 300, 500, etc., to monitor, correct, and in appropriate circumstances alter planned vehicle navigation routes in response to emergencies, traffic revisions due to accidents or construction, etc.

[0048] Security system(s) 270 can override previous routing or transit commands in order to stop the vehicle 100 and/or release passengers 250, etc., or to re-route the vehicle 100 to a hospital, police station, or other point of assistance, and/or to facilitate routine or exceptional vehicle maintenance requirements, for example to enable petroleum refueling or electrical recharging, repairs, maintenance, etc.

[0049] Vehicle operational performance monitoring module(s) 272 can be provided to monitor engine, brake, steering, navigation, fuel/energy consumption, environmental, and other systems' performance and in appropriate circumstances to interact with any or all of systems and modules 270, 257, 300, 400, 500, etc., to implement remedial action as appropriate. Using such systems, safe and efficient operation of vehicle(s) 100 can be maximized. Such modules can include and/or interact with any suitable forms of gauges, sensors, or feedback devices, including for example pressure, fluid, and/or temperature sensors, position sensors, etc.

[0050] Vehicles 100 can further be provided with food, drinks, audio, video, game, network browsing, and other entertainment and/or refreshment systems, wash/toilet facilities, etc., and other passenger refreshment systems or components as desired. As will be readily understood by those skilled in the relevant arts, passenger compartments and other portions of vehicles 100 adapted for occupation by humans or animals can be configured in a very wide variety of suitable ways in order to ensure their comfort and safety, many now known and others likely to be developed hereafter.

[0051] Among the important aspects of system(s) 1000 in accordance with the invention are user call / control devices 200 (in various embodiments also referred to as vehicle request control devices 200) and the possibilities they offer. Such devices may be advantageously used with both privately-controlled (single-user) vehicles 100 and with pooled or shared (multi-user) vehicles 100. As previously noted, devices 200 can be provided in a wide variety of useful forms, including either general-purpose or specially-configured smart phones or cell phones 200, 203, 204; specially-configured vehicle ignition keys or fobs 200, 201 , 202; laptop, tablet, desktop, and other types of computers 200, 205, 206, as well as smart jewelry, watches, and other PDAs and data processing / communication devices. Devices such as general-purpose smart phones 203, 204 can be specially configured by, for example, installing suitable application programs configured to cause the devices to accept user input and to generate user-interpretable output signals, so as to enable user(s) 250 to interact with system(s) 300, 00, etc., and thereby control one or more vehicles 100. Alternatively, devices 200 which are not specially configured can also be used advantageously, for example through the use of web browsers and suitably adapted web sites, social media platforms, and other general-purpose communications applications, suitably employed to communicate with fleet or vehicle servers 300, etc.

[0052] Figures 3A and 3B are schematic block diagrams of embodiments of user call and control devices 200 suitable for use implementing various aspects and embodiments of the invention. Figure 3C is a logical block diagram showing various modules and components configured for the management, control, operation, maintenance, and administration of the call and control of a vehicle 100 using the devices of Figures 3A and 3B.

[0053] Figure 3A shows a key 200, 201 for a single vehicle 100, or for a group of vehicles 100 configured for acceptance of a commonly-cut key barrel 201 a; and a wireless fob 200, 202 adapted to wirelessly exchange signals with an ignition or access-control system of a vehicle 200 in order to authorize and initiate starting of and optionally access to the vehicle. Figure 3B shows a specially-configured general-purpose smart phone or PDA 200, 203 configured in accordance with the disclosure. As shown in Figure 3C, in both cases, the devices 200 can comprise any or all of a number of advantageous logical modules and/or hardware/firmware components, including for example one or more processors 302; clock(s) 303; memory(ies) 304; keypads 317, 318, 320, touchscreens 316, 319, and/or other user input devices 306; NFC, RFID, card-reading and other magnetic or wireless proximity and/or short-range data communications systems 314; network communications devices 312; and GPS or other positioning system(s) 310. [0054] Each of the modules or components 302, 303, 304, 317, 318, 320, 316,

319, 306 can interact with NFC, RFID, card-reading and other magnetic or wireless proximity and/or short range communications devices 314; network communications devices 312; and GPS or other positioning system(s) 310system(s) 100, 300, 600, etc., to implement the various processes described herein.

[0055] For example, a user 250 wishing to use a vehicle 100 to travel to another location, and/or to ship goods to another location, can use any or all of input devices 306, 310 to generate a call instruction set, which can alternatively be referred to as a vehicle request or vehicle service request data set, for routing to a fleet management system 300 via network communication system 312 and/or proximity communication system 314. For example, by using suitably-configured user interfaces, including special-purpose graphical user interfaces, the user 250 can specify any or all of a very wide variety of request or other control parameters, including an arrival time and location for the vehicle 100, as well as one or more vehicle condition parameters, including for example whether the vehicle is to idle or shut down upon arrival at the specified location, and pending entry of the passenger(s) 250 and/or cargo; environmental control parameters such as a desired air temperature inside either or both of compartments 275, 280, window status, seat warmer status, etc.

[0056] A particularly advantageous aspect of the invention is that a general purpose PDA or computer 203, 204, 205, 206, if suitably equipped with any desired positioning and communication modules 310, 312, 314, etc., can specially configured to act as a vehicle control system 100 through downloading by a user 250 and installation of an appropriately configured application module 395, to enable the device 200 to summon, pay, control, and/or otherwise interact with system(s) 100, 300, etc., and components thereof, in required modes to accomplish the purposes described herein.

[0057] A further advantageous aspect of the invention is the use of a PDA or computer 203, 204, 205, 206, etc., or any device 200, to control maintenance, administration, and other operational aspects of one or more vehicles 100 in addition to specific travel and/or transport requests. For example, a suitably-configured device 200 can be used to schedule and implement regular vehicle maintenance appointments, refueling, etc., without further specific action on the part of the user 200. This enables, for example, the user 250 to schedule a vehicle 100 to drive itself to a maintenance, charging, or other facility for regular or required maintenance at a time when the user 250 is otherwise occupied - for example, during off-peak traffic hours while the user is sleeping, etc.

[0058] Suitably-configured user control device(s) 200 can further be used by a user 250 to make inquiries regarding locations and/or availability of vehicle(s) 100, currently, at any desired point in the future, and or in the past, so as to facilitate travel or trip planning, performance, and/or record keeping.

[0059] Such devices, it should be noted, can be used to cause the arrival of a vehicle at the user's current location through use of GPS or other positioning module(s) 310, and/or to send the vehicle 100 to another location, for example, to collect a child, friend, or colleague.

[0060] Device(s) 200 can further be used to negotiate or accept suggested or assigned arrival times generated by control system(s) 300, to access and conveniently generate vehicle call requests by accessing pre-defined or frequently visited locations or other preferences, etc.; or to specify any of a very large variety of vehicle requirements, including for example seating and/or cargo capacity, en-route environmental, refreshment, or entertainment requests, etc.

[0061] Device(s) 200 can further be used to review vehicle routing suggestions made by a control system 300 or vehicle 100, and to assist in refining such suggestions, or even to override and replace them.

[0062] Figure 4 is a logical block diagram showing various modules and components of a system 300 configured for the management, control, operation, maintenance, and administration of a fleet of vehicles in accordance with the disclosure. System(s) 300 can be embodied as physically distinct, stand-alone servers, and/or they can be implemented as mobile devices on one or more specially-adapted vehicles 100, etc. System(s) 300 can be implemented in redundant and/or distributed form through the use of complementary and/or redundant devices located in multiple places and/or on multiple vehicles 100. Alternatively, or in addition, system(s) 300 can be implemented as component(s) of request control device(s) 200. [0063] Central control stations can be configured to monitor, control, and implement all aspects of the operation of autonomous vehicles 100, except to the extent that such control is overridden by users or passengers 250 inside or outside the vehicle(s) 100, security modules 270 of the autonomous vehicles 100 (e.g., in case of low fuel, system failure, accident, fire, etc.), maintenance and/or repair systems 400, and/or emergency systems 500, etc. Such control can be exerted through the generation by system(s) 300 and routing to individual vehicles 100 of appropriate autonomous vehicle control instruction data sets, which may be adapted to control any and/or all aspects of the operation of such vehicles or their various components 262, 270, 272, 286, etc.

[0064] Accordingly, as shown in Figure 4, control system(s) 300 in accordance with the disclosure can advantageously comprise a number of logical modules and/or hardware/firmware components, including for example any one or more of processors 402; clock(s) 403; databases and/or other memory(ies) 420; network and/or wireless communications systems 404, 410; vehicle system monitoring module(s) 408; fleet and/or vehicle maintenance module(s) 414; location monitoring module(s) 412; traffic/route monitoring module(s) 416; and/or user or customer management module(s) 422, which can for example include customer preference management components.

[0065] Using such systems and components, central control system(s) 300 can exchange signals with and otherwise cooperate with any or all of vehicle(s) 100, user controllers 200, maintenance repair system(s) 400, FSP system(s) 600, and emergency system(s) 500 to implement the many processes disclosed or suggested herein.

[0066] For example, central control station(s) 300 can monitor incoming user vehicle call requests from devices 200, monitor locations and conditions of vehicle(s) 00 that may be available to fulfill such requests; assign available vehicles to vehicle requests in accordance with user-specified vehicle parameters and cause them to respond autonomously thereto; monitor the locations and performance of vehicles autonomously executing transport instructions, including the conditions of compartments 275, 280, etc., as well as engine performance, fuel/energy levels to generate maintenance, repair, refuel/re-charge vehicles as appropriate; monitor traffic and route conditions to confirm or revise assigned vehicle routes, etc. [0067] User/customer management modules 420, 422 can control storage and analysis of data related to all aspects of the use of vehicles 100 by individual users 250, or groups of users, in order to maximize user satisfaction and minimize risk to vehicles 100 and third parties such as operators of other vehicles, pedestrians, etc. Such modules 420 can for example track customer travel and payment behavior to maintain or generate user preference profiles, which can be stored on either or both of server(s) 300 and user call/request device(s) 200, and to make suggestions adapted to assist the user(s) in creating an enjoyable or otherwise improved travel or transport experience. Central vehicle control systems 300 can also implement a variety of processes for improving business, including for example implementation of loyalty, advertising, and rewards programs; monitoring and completing credit, debit, and other transactions; customer credit worthiness, etc.

[0068] In circumstances where vehicle modules 270, 258, 272, or other data sources indicate exceptional operating conditions and/or other problems associated with one or more vehicles 100, central control system(s) 300 can alert emergency / rescue / repair / maintenance services 300, 400, 500, etc., and take other action as appropriate.

[0069] Call response modules 406 can provide a wide range of functions, including for example the generation of secure passwords or identification codes (or tokens) to be routed to user device(s) 200 for presentation to systems 254, etc. of vehicles 100 in order to ensure that only authorized users are able to access or control vehicles 100. The generation and routing of such codes can be conditioned upon any desired requisites, including for example receipt from FSP(s) 600, user device(s) 200, etc., of deposits or full payments for single-use fares; regular monthly or other period pool membership payments, etc.

[0070] Call response modules 406 can further provide functions such as the suggestion of advantageous vehicle arrival times, based on availability of desired vehicle types, etc.; assist in defining destination(s) / waypoints to be visited by the vehicle during autonomous navigation; suggest dinner, restaurant, entertainment, and/or other destinations or diversions; suggest, confirm or otherwise specify user vehicle needs, such as required or desired numbers of passenger seats, passenger/cargo space; food / refreshment needs; cargo needs (refrigeration, etc.); or desired vehicle condition at pickup points - e.g., windows up down, air- conditioning / heating status, etc.

[0071] An important optional feature of a system 300 is efficiency module 450. By continually or continuously monitoring the locations, performance, and usage of one or more vehicles 100, module 450 can cause processor(s) 402 to generate and route to vehicles 100 vehicle control instruction signals adapted to minimize energy and/or fuel consumption, minimize distances travelled or time required to travel, minimize risk of collisions or other accidents, or etc. Through the proper implementation and use of such processes, environmental damage can be minimized or eliminated.

[0072] Vehicle and/or fleet maintenance module(s) 414 can be used to automatically or semi-automatically implement or control refueling, recharging, maintenance, repair, and other service processes for individual vehicles 100 or groups thereof. For example, module(s) 414 can be used to schedule and implement regular vehicle maintenance appointments, refueling, etc., without further specific action on the part of the system 300 or its administrators. This enables, for example, the system to schedule the vehicle(s) 100 to drive themselves to a maintenance, charging, or other facility for regular, required, or otherwise advantageous maintenance at advantageous times - for example, during off-peak traffic hours, when sufficient numbers of vehicles are idle or unwanted, etc.

[0073] In various aspects and embodiments systems 1000 in accordance with the invention can comprise call service management system(s) 301 , which can be implemented in various embodiments as a part of, or in addition to, fleet management system(s) 300. Generally, call service management system(s) 301 can be thought of an additional layer or functionality of one or more vehicle controllers 300; in that system(s) 301 can operate without direct control of any vehicles 100, but instead by referring calls to controllers 300 which do control autonomous vehicles 100. It will be appreciated by those skilled in the relevant arts that such functions can be considered equivalent to a function performed by a fleet controller 300 of referring vehicle service requests to other controllers, such when none of the vehicles controlled by a controller 300 is suitable for or otherwise available to respond to a service request. [0074] For example, in some embodiments call service system(s) 300, 301 operate solely as independent service providers, taking requests from user devices 200 and referring them to other controllers 300.

[0075] Maintenance, repair, service, and recovery systems 400 can comprise processors, memories, and modules suitable for cooperating with central control system(s) 300, vehicle(s) 100, and emergency service system(s) 500 as described herein. Such systems 400 can be operated by, e.g. as a component of, or otherwise in cooperation with, central control system(s) 300 (e.g., by common ownership, systems integration, etc.), or independently by third parties using separate communications and data processing systems.

[0076] Emergency services system(s) 500 can be operated by governmental or other agencies or authorities responsible for public safety, health, road maintenance, etc., and comprise processors, memories, and modules suitable for cooperating with central control system(s) 300, user control system(s) 200, vehicle(s) 100, and maintenance system(s) 400 to respond to emergencies and other operational exceptions as described herein.

[0077] FSP system(s) 600 can be operated by banks, payment and other transaction processors, and other financial institutions who manage or administer payment accounts, or otherwise cooperate with any or all of systems 100, 200 300, etc., to authorize payment transactions suitable for use in implementing the purposes disclosed and suggested herein, and comprise processors, memories, and modules suitable for cooperating with central control system(s) 300, user control system(s) 200, vehicle(s) 100, etc. as described herein.

[0078] As will be appreciated by those skilled in the relevant arts, network(s) 800 can comprise any electronic signal communication systems, components, and devices, and/or combinations thereof, suitable for use in implementing the processes disclosed and otherwise suggested herein. For example, any or all of public and/or private wire-line and wireless telephone networks, satellite communications systems, etc., will serve. In many embodiments, it is preferred that all data and signal communications related to vehicle request and control functions be encrypted and/or otherwise secure. For example, it is important that unauthorized interference with the appropriate control of vehicles 100 transporting individuals and/or valuable cargos be prevented, and that personal and financial information and other data relating to payment and other transactions be protected from unauthorized access. As will be understood by those skilled in the relevant arts, once they have been made familiar with this disclosure, a wide variety of suitable methods for secure communications are now available; doubtless they will continue to be developed hereafter. The selection of suitable combinations of methods and devices will not trouble those skilled in the relevant arts.

[0079] As noted previously, among the significant improvements offered by the invention is the operation of individual and fleets of autonomous vehicles in ways that reduce or eliminate harmful environment effects, by reducing the numbers of vehicles required to serve pluralities of users (e.g., by ride or vehicle sharing); by reducing or eliminating vehicle idling times, gas or electricity consumption; routing of vehicles by the most efficient routes and in such ways as to avoid accidents or delays; the use of vehicles located close to or otherwise accessible to passenger or cargo transport needs, etc. Such improvements can be enhanced by the use of fuel- efficient, hybrid, electric, and/or other environmentally-friendly vehicles, such as propane-fueled and other low- and zero-emissions vehicles, in implementing various aspects of the invention.

[0080] Advantageous applications of the invention include a wide range of shared ride, fleet, and taxi programs, personal vehicle maintenance and operation, efficient establishment of delivery routes, etc.

[0081] Examples of the use of system(s) 1000 and the various components

100, 200, 300, 400, 500, 600 thereof are provided by reference to signal exchange diagrams such as those shown in Figures 5 and 7.

[0082] An example embodiment of a process for provisioning a general- purpose key, fob, smart phone, PDA, or other user device 200 with a vehicle management and control module or app 395 is shown as starting at 501 in Figure 5, with generation and routing by a user device 200 of a vehicle management module provisioning request data set, which is routed by the device 200 over network 800 to a central control system 300. Such a data set can, for example, include data representing: <delivery addressxvehicle user ID>

<request details><authorization information where:

<delivery address> = telephone number, uniform resource locator (URL), or other network identifier useable by controller 300 for routing a vehicle management data set comprising data representing machine-executable instructions for use by one or more user devices 200 associated with the requesting user in executing processes such as those disclosed herein

<vehicle user ID> = optional identification data or other credentials such as name, birth date, address, and/or any other information acceptable to an operator of a system 300 or fleet of vehicles 100 pertaining to a user or users authorized or to be authorized to make use of requested vehicle(s) 100

<request details> = optional details of any particulars of the vehicle management and control module 395 to be provided, which can for example include the characteristics of vehicle(s) the user typically expects to request; nature or range of service(s) to be performed by requested vehicle(s); default user preferences, etc. In some embodiments, no request details are required, because a standardized vehicle management and control module or application is provided, rather than a range of options tailored for different classes of users (e.g., business, pleasure, passenger, cargo, etc.)

authorization information> optional or required information or credentials sufficient to cause or enable an operator of a controller 300 or vehicle(s) 100 to authorize access by the requesting user(s) 250 to vehicles 100 under any desired circumstances, such as for example, one or more verified payment account or other sources of payment funds, such as a debit, credit, or non-monetary value account; voucher, negotiable payment token, etc., to be used as defaults in paying for vehicle services. Optionally such authorization information can be used to ensure any required payments for downloading or other access to a vehicle management and control module or application 395, where for example such modules or applications are not provided free of charge.

[0083] Conditioned upon presentation of data representing satisfactory credentials and IP addresses, etc., at 502 the system 300 can return, or authorize return directly or through a third-party trusted service provider, a vehicle management module data set that can be used by one or more processors 302 of the device 200 to install the module and thereby enable the device 200 to communicate with the system to request dispatch of an autonomous vehicle, membership in a ride share program, establishment of a user profile, etc.

[0084] It should be noted that special-purpose keys, fobs, etc. 200, 201 , can be prepared in advance, and delivered to a user 250 without need for performing the process 501-502, for example in batches by a company or other entity controlling a control system 300 and/or fleet of vehicles 100.

[0085] With further reference to Figure 5, an example of a process suitable for enabling a user 250 to call a vehicle 00 using a device 200 is described. At 503, a user 250 of a vehicle request call device 200 desiring dispatch of one or more autonomous vehicles 100 for transportation of individuals and or cargo can use her/her his device 200, and various components thereof, to generate a vehicle call request data set and route it to a corresponding vehicle or fleet management control system 300. Such generation and routing can, for example, be accomplished through use of one or more input devices 306 and appropriately-configured graphical user interfaces (GUIs) generated by the vehicle management module 395, or by a website application made available by a fleet management control system 300. Using such devices and GUIs, the user can specify a time and location for arrival of requested vehicle(s) 100, of any desired type(s); one or more desired destinations and/or arrival times, etc.; and any other desired vehicle request information, such as for example any additional desired vehicle operating conditions, such as heating/cooling conditions, idle/no idle specifications, music to be playing in the vehicle, etc.

[0086] For example, as shown in Figure 6, a user 250 of a device 200 such as a smart phone 203 provided with a vehicle management application or module 395 can generate a vehicle call or request data set through use of a touch screen 306, 390, and/or command buttons (including physical 392 and/or virtual 398 keyboards 306) of the device 200, 203 in response to one or more data solicitations displayed on one or more graphical user interfaces (GUIs) 601 generated by processor(s) 302 in accordance with instructions provided by the vehicle management application or module 395.

[0087] For example, as shown in Figure 6A, a user 250 of a device 200 such as a smart phone 203 can access a vehicle management module 395 by using one or more input devices 306, 390, 392, etc., including for example a touch screen, virtual keyboard(s) 390 and/or physical keyboard(s) 398, etc., to select a vehicle management GUI icon 602 and thereby invoke a vehicle management application such as that provided at 501-502 of Figure 5, resulting in generation and display of vehicle management application log-in interface GUI 604 such as that shown in Figure 6B.

[0088] As an alternative example, such a user can use one or more input devices 306, 390, 392, etc. to invoke a general web or other network browser by means of a suitable GUI icon 603 and use the browser to navigate to a web site or other network resources associated with a vehicle management application hosted by a controller 300 in order to access a vehicle management application interface GUI 604 such as the application log-in user interface shown in Figure 6B, and initiate a vehicle call communication process which may be similar to that initiated by a vehicle management application 395. In further embodiments, a user can simply navigate to a website or other resource operated by a fleet management system 300, and request a car by presentation of suitable information and credentials without logging in.

[0089] In cases where log-in is required, in response to prompts 606, 608 in

Figure 6B the user 250 can use a touch screen 390, and/or virtual or physical keyboard(s) 398, etc., to enter user identification and authentication information such as the user's name or other unique identifier, and password, and thereby access one or more vehicle request data GUI(s) 610 such as GUI 610, 609 shown in Figure 6C. Vehicle request data GUI(s) 610 can be configured to solicit input of any and all desired information, including for example one or more vehicle types 612, pickup locations 614, pickup time/date 616, desired vehicle features, including for example size and type of vehicle, passenger compartment temperature and passenger comfort system settings, entertainment preferences such as music and/or video sources, types and quantities of refreshment, etc. Together with other, optionally previously entered and/or previously stored information such as preset preferences, such input can be used to generate suitably-configured vehicle request data sets as described herein.

[0090] In the embodiment shown in Figure 6C, GUI 610, 61 1 is configured to solicit data representing one or more desired vehicle types or classes, and a date, time, and location for pickup. GUI 610, 61 1 further includes a command item 632 "Next" configured to allow the user 250 to access further GUIs in order to continue entering desired request data.

[0091] At 612 in the embodiment shown in Figure 6C, the user can be provided a listing of available passenger and/or cargo vehicles or vehicle classes. Listing 612 can, for example, list classes of vehicles generally available within a fleet of vehicles 100. In various embodiments, for example, a listing 612 can comprise identifiers corresponding to all vehicles comprised by a fleet, without regard to current status or availability. In further embodiments, a listing 612 can comprise identifiers corresponding to individual vehicles, or classes of vehicles, that are currently identified by a server 300 as available. For example, a server 300 can maintain a data a database of all vehicles 100, controlled by the server, along with status indicators, which may include for example operational status (i.e., ready, in service, etc.) and/or location. For example, a server 300 can compare a current location of one or move vehicles 100 to an indicated pickup location, and provide a listing based wholly or partially on proximity of the vehicles to the pickup location, which list can be ordered according to geographic distance from the pickup location and/or estimated response time, convenience in user access to the vehicle (i.e., proximity or accessibility of parking lots, driveways, etc.) given available routings and/or traffic conditions, etc. In cases where, for example all generally-available vehicles, or classes of vehicles are listed, without regard to current availability or proximity, and a user selects a vehicle or vehicle type that is currently unavailable, or further away than a predetermined geographic or temporal threshold (i.e., too long an estimate response time), the server 300 can be configured to provide alternative vehicle or vehicle class suggestions. [0092] In any such embodiments, use by a user 250 of one or more of input device(s) 306 such as a touch screen 316 and/or physical or virtual keypad 398, etc., to select one or more vehicles or vehicle classes 612 can cause processor(s) 302 to generate a requested vehicle type or ID data set, for use in generating a vehicle request data set to be routed to the control system 300.

[0093] Alternatively, or in addition, an item 612 (not shown) representing one or more requested services or service types can be presented. Such an item can, for example, provide a listing of available services, such as passenger transport (taxi), cargo transport (delivery), etc. In such cases selection of one or more such items can cause processor(s) 302 to generate a requested vehicle service type data record for use in generating a vehicle request data set.

[0094] In some embodiments, a requested service type can be implicit in the type of vehicle requested at 612. For example, as shown in Figure 6C, a user 250 wanting a vehicle suitable for transporting one or two passengers can use a radio- button to select an item "Car (2)"; a user wishing to transport up to four passengers can select an item "Car (4)"; and a user wishing to transport up to seven passengers can select an item "Van (7)", where in each such case the parenthetical number represents a maximum number of passengers that the vehicle of vehicle class can accommodate, optionally along with a predetermined default amount of baggage, such as one or two suitcases per person. Selection of suitably-presented items for trucks, limos, etc. , can be enable users to designate amounts of cargo or class of service desired, etc.

[0095] By selecting an item 614 "Location", a user 250 can invoke processes suitable for providing information relating to one or more desired pickup locations. For example, selection of such an item can invoke processes whereby the user can access one or more input devices 306 to input a desired pickup location. Alternatively, or in addition, a user 250 can be presented with an interactive item 617 configured to access a GPS of other positioning system 610 of the user device 200 and determine a current location of the user device. In either such cases selection of one or more such items and entry of corresponding data can cause processor(s) 302 to generate a requested pickup location data record for use in generating a vehicle request data set. A pickup location can be either a present location of a user 250 at which a vehicle 100 can meet the user, for example without the user having to more; or a present location of a user 250 which can be used by the controller 300 to determine a spot where the user 250 can meet the vehicle 100, for example a location within a parking lot, parking garage, driveway or other site at which the user can find a vehicle 100 for use..

[0096] Alternatively, or in addition, a user interface 610 can provide one or more interactive command items 615, selection of which causes generation of a vehicle request data set comprising data representing any previously-stored or otherwise pre-set user preferences, such as one or more pickup locations (such as home, office, favorite restaurant, etc.); pickup times; vehicle types; vehicle operating or ECS conditions, etc. , as described herein. Such command items 615 can thereby enable a user to request one or more vehicles by entry of a single input command, e.g. , a tap of a finger on a touchscreen 316.

[0097] At 616, the user 250 is enabled to initiate a process such as those described above, whereby the user may designate a desired pickup date and/or time, using input any desired input device(s) 306.

[0098] If or when the user 250 is satisfied with the content of his or her vehicle request selections, he/she can select a command item 613 to initiate a process whereby processor(s) 302 access data records associated with selections of items 612, 614, 616, etc., to generate a vehicle request data set and route it to a vehicle management system 300 associated with the management module 395, vehicle management website, or otherwise designated by the user. At any point user can select item 613 to cause generation and routing of vehicle request data set.

[0099] Alternatively, the user 250 can be presented with GUI options to enable the user to input any further-desired request features. For example, as shown in Figure 6C, an item 632 can be provided to cause presentation of GUI features adapted to elicit any further desired information to be included as a part of the request data set. Selection of an item 632 "NEXT", can for example, cause generation of any one or more of GUI displays 610 shown in Figures 6D - 6G.

[00100] In Figure 6D, a GUI 619 configured to enable a user 250 to specify information relating to vehicle service type request is shown. GUI 619 can, for example, include one or more items 619a, 619b, 619c, adapted to elicit input representing commands related to a number of passengers to be transported, a number of passenger bags to be transported, and/or a size (e.g., maximum dimensions or cubic volume) and/or weight of cargo to be transported.

[00101] In Figure 6E, a GUI 610, 618 configured to enable a user 250 to specify any desired vehicle condition request(s) is shown. GUI 618 can, for example, include one or more items 620 to enable a user use one or more input device(s) 306 to designate a desired temperature and/or humidity, etc., to be established by vehicle ECS system(s) 294 by the time of arrival of vehicle 200 responding to a request; seat-warmer, window, and other passenger comfort system settings; one or more items 622, 624, 626 to generate music, video, and/or other entertainment requests to be submitted, so that desired music, video, or other entertainment items can be provided and ready for use by the time of arrival; one or more items 628 to specify desired temperature, humidity, and/or other ECS conditions to be established in one or more cargo compartments 280 of a responding vehicle; one or more items 630 for any further vehicle condition requests, such as food and/or beverage requests, reading material, etc.

[00102] In Figure 6F, a GUI 610, 61 1 configured to enable a user 250 to specify any desired or required payment source(s) to be used to make or guarantee any required payments associated with a vehicle request is shown. For example, a system 300 configured to support an autonomous taxi service can require payment or guarantee of a fare, etc. In the embodiment shown in Figure 6F, a GUI 61 1 enables a user to select a wallet icon 634 in order to access a virtual wallet application 341 operated by his/her request device 200, a vehicle management system 300, and/or or one or more FSP systems 600, and thereby provide any required input by means of such wallet application 341. Alternatively, or in addition, any one or more of credit functions 636, payment functions 638, and/or account information icons 640, can be accessed in order to provide any desired information pertaining to cash, credit, debit, or alternative payment value such as loyalty or rewards points to be input and used to generate suitable request data items. In any or all such cases, invocation of command items 634, 636, 638, 640 can enable the user to input data representing desired payment information using one or more input device(s) 306, and/or to access information previously stored within a vehicle management application 395, in a virtual wallet or other application 341 stored on the user's device 200, on a fleet management system 300, and/or one or more FSP systems 600 associated with the user 250 and/or fleet operator of the management operator system 300.

[00103] In Figure 6G, a GUI 610, 621 configured to enable a user 250 to specify any preferences the user desires to store for future use, for example as defaults, in generating vehicle request data sets. Such information can, for example include account information to be used as a default, such information enterable or otherwise accessible by use of command item 644; favorite or other vehicle preference information, by means of item(s) 646, which can enable designate of a specific favorite vehicle(s) or vehicle class(es), or other preferred characteristics of preferred vehicles (e.g., color, convertible, hardtop, number of doors, windows, entertainment systems, etc.), etc.; one or more preferred or usual pickup and/or destination locations by means of item(s) 648; any preferred routes or routing information (e.g., preferred roads, or types of roads, toll or no-toll roads, etc.) by means it item 650; and food, entertainment, or other ECS preferences by means of item(s) 652.

[00104] As previously noted, navigation between request data collection GUIs 610 such as those shown in Figure 6 can be by means of "NEXT" and "PREVIOUS" command items 632, 633.

[00105] At any point at which the user 250 is satisfied with the content of his or her vehicle request selections, he/she can select a command execution item 613 to initiate a process whereby processor(s) 302 access data records associated with selections of items 612, 614, 616, etc., and/or further input generated through the use of processes such as those described in connection with Figures 6D-6G, and generate a vehicle request data set for routing to a vehicle management system 300 associated with the management module 395, a vehicle management website, or otherwise designated by the user. Such a vehicle request data set can include data representing any or all of the items described above, including for example any or all of the following items or classes of items:

<pickup timexrequested service type><destination(s)><vehicle type or ID> outhorized user IDxECS preferencesxpayment/authentication info>;

where: <vehicle management service> = identifier associated with operator(s) of one or more vehicle management systems 300. For example, a request for taxi service might be routed to one or more of a plurality of taxi service providers, specified by a requesting user 250 or assigned by a vehicle management system 300

<requesting user> = identifier associated with a requesting user 250, as for example personal identifiers associated with an individual user, and/or with a business or other entity associated with the user

<pickup location> = identifier(s) associated with one or more street addresses or other geographical locations at which a requesting user 250 would like to pick up a car, or have a vehicle to arrive, to pick up the same or another user or users 250, cargo to be transported, etc. In some embodiments pickup location can be a current location of the requesting user, which can be used by the controller 300 to identify a meeting or pickup spot closest or otherwise most convenient to the user.

<pickup time> = identifier(s) associated with date(s) and/or time(s) at which vehicle(s) 200 are requested to arrive at specified pickup locations. Such times can be absolute or relative, and can for example be periodic (i.e. , daily, weekly, etc.). Such times can be any specified time(s) in the future, or now. For example, a pickup time data set can comprise an identifier representing a request for immediate service, service in 20 minutes, or service at 3 PM.

<requested service type> = identifier(s) associated with type(s) of requested service(s), e.g. , taxi; passenger transport; limousine; cargo; refrigerated cargo; etc.

<destination(s)> = identifier(s) identifier(s) associated with one or more street addresses or other geographical locations to which a requesting user 250 would like a vehicle to go, to deliver the same or another user or users 250, cargo to be transported, etc. <vehicle type or ID> = identifier(s) associated specific type(s) or class(es) of vehicles of , and/or individual vehicles requested, e.g. , taxi, limousine, van, bus, truck, pickup truck, SUV, sports care, etc. ; can also include identifier(s) associated with preferences for fuel-efficient, hybrid, electric, or otherwise environmentally- friendly vehicles

authorized user ID> = identifier(s) associated with one or more authorized

users of requested vehicle(s) 100, who may be the same as or different from the user(s) who requested the vehicle. For example, a first user 250 of a first request control device 200 can use his/her device 200 to generate a vehicle request data set and route it to the vehicle management controller 300, and designate as a part of the request one or more different users and/or different user request control device(s) 200 to receive a vehicle use authorization data set comprising a code, token, or other information adapted to enable the second user(s) 250 to access and use the responding vehicle(s). Such tokens can be based on random, pseudo-random, user- or system designated passwords, user biometrics, etc.

<ECS preferences> = identifiers associated with desired vehicle internal

operating conditions, e.g., air conditioner and/or heating system conditions; music, video, or other entertainment requests; food requests, etc.

<payment / authentication info> = identifiers associated with payments, payment sources, and/or other information required or otherwise desired for use in conjunction with authorizing and/or paying for requested vehicle service(s)

[00106] At 503, as previously noted, a vehicle request data set generated as described above can be routed to one or more vehicle management control system(s) 300 using for example URLs and/or other address information associated with vehicle management service data included in the request data set. [00107] In some embodiments, invocation of a command item 613 can cause generation and display of a request confirmation screen such as that shown in Figure 6H, which echoes some or all features of current input for a vehicle request data set, prior to routing of the data set to a controller 300 at 503. In the example shown, for example, the user has requested a 4-seat vehicle, with pickup at 123 Main Street, at 8:25AM on the 1^st day of January, 2021 ; with a requested passenger compartment temperature of 72 degrees Fahrenheit, with music playing and a requested destination of 632 Commerce Street; a total service price of $27.31 to be charged to a designated user account. Selection of "EDIT" item 974 can cause the management application 395 to return to any of the prior display states 609, 610, 611 , 618, 621 , etc., so that request input may be modified. Selection of "CONF" item 976 can cause the processor(s) 302 to display an order confirmation GUI such as that shown in Figure 6I, and route the request data set to the identified vehicle controller(s) 300.

[00108] In addition to confirmation that the vehicle request data set has been / is being routed to identified controller(s) 300, a GUI 610, 677 such as that shown in Figure 6I can comprise a command item 977 "ACCESS". Selection of "ACCESS" item 976 can invoke processes between the user device 200 and either or both of a responding vehicle 100 and controller 300, to adjudicate an access authorization request, whereby a user 250 can be granted access to the responding vehicle, as described herein.

[00109] Upon receipt, an identified vehicle controller 300 can parse the request to determine whether any one or more vehicles are available that meet the specifications identified by the request. For example, the control system 300 can consult table or other data set 412 of vehicle locations, and/or data set(s) 408 of the conditions or status of a plurality of potentially available vehicles, and/or poll, via one or more communications system(s) 404, 410 one or more vehicles 100 suitable for satisfying the request, to determine whether they are located in closest to, most convenient reached by, or otherwise in suitable proximity to the requesting user, and in condition to complete the request transportation set; and route to the user a vehicle request confirmation and authorization data set comprising one or more suitable available vehicles, any related pricing, etc. Such authorization data set can be conditioned upon satisfaction of further requirements, such as tender of suitable payment, or down payment, or establishment of credit.

[00110] For example, if authorization of dispatch of vehicle(s) 100 is conditioned upon payment, etc., and information suitable for satisfying the condition was not included in the vehicle request data set routed at 503, the user may be informed by means of data comprised by the authorization data set, and at 505 the requesting user 250 can select from among any options offered by the request confirmation and authorization data set, and use the various components 306, 308, etc., and suitably-configured GUIs, to generate a payment request data set and route it to one or FSPs associated with suitable user payment accounts.

[00111] If suitable funds are available in credit, debit, loyalty, and/or other accounts associated with the requesting user 250, either by information included in the vehicle request data set or in response to a vehicle authorization request data set, etc. , then at 506a and/or 506b the FSP(s) can route to either or both of the user request control device 200 and/or central control system 300 payment or transaction confirmation data sets.

[00112] With any required payment or other conditions satisfied, at 507 the central control system 300 can generate and route to suitable vehicle(s) 100 call- response instruction data set(s), comprising signals representing, for example, pick- up points and any, all, or none of pick-up times, vehicle condition requests, routing information, etc., as described above, along with any desired user access codes. At 508, the system 300 can route the user access code(s) to the requesting user device 200.

[00113] In various preferred embodiments of such aspects of the invention, for example, at 507 the vehicle management system 300 can route to one or more designated vehicle(s) 100 a response instruction data set comprising, in addition to any desired pickup time(s) and/or location(s), a first human- and/or machine- interpretable access code or token; and at 508 can route to the same or another user 250 and/or user device 200 a second human and/or machine-interpretable code or token, which may be the same as or different from the first token; the first and second tokens being adapted to enable both the user 250 and vehicle 100 to recognize the user 250 to access and use the vehicle 100 on arrival. [00114] For example, at 508 an encrypted, machine-readable vehicle access token may be routed to both the vehicle 100 and the authorized user control system 200; and on arrival of the vehicle at the designated pickup point, the user control system 200 can be used to transfer the encrypted access token to a security system 270 and/or access authorization system 222 of the responding vehicle 100, e.g. by means of proximity communication system 314 of the user device 200 and a vehicle POS interface 259; and processor(s) 257 can be used to match the tokens and authorize the security system 270 to enable the user 250 to access the vehicle. As a further example, user device input devices 306 can be used to collect fingerprint, retinal, or other biometric identifiers, which may be encrypted and/or otherwise routed to a responding vehicle 100, and confirmed at the time of access request by means of on-board vehicle biometric readers 288, etc.

[00115] Upon receipt at 507 and processing of the call-response instruction data set(s), assigned vehicle(s) 100 can autonomously navigate to the specified pick-up points, and can condition themselves as requested through suitable activation of heating, air-conditioning, and other systems 294, etc.

[00116] In some embodiments, vehicle request data sets generated at 503 can be used to access pooled or other vehicles provided at designated parking spots or parking lots. For example, for shared-ride operations, vehicles can be parked at agreed or otherwise specified regular or otherwise known location(s), and users can be required to travel to the vehicle, rather than the vehicle going to the user. In such cases, the pickup location specified by the user at 503 can simply correspond to the regular vehicle parking spot, and the process used by management system 300 can consist of simply ensuring that specific, requested vehicles are not previously reserved for use by other users.

[00117] For example, in such cases a user 250 wishing to use a parked shared-ride vehicle can approach the vehicle, access a vehicle management module 395 and cause a local, POS-type exchange to occur between his/her device 200 and the vehicle 100, with corresponding authorization communications exchanges occurring between some or all of systems 100, 200, 300 as described above.

[00118] In any case, upon arrival of the vehicle(s) 100, the requesting users can approach the vehicles and at 509 use the network and / or proximity communication system(s) 312, 314 of their user control device(s) 200 to transfer the user access code(s) received at 508 to the network and/or proximity communication systems 251 , 254 of the responding vehicle(s) 100. Transfer of access codes at 509 can occur automatically, for example as soon as proximity communications devices 254, 314 of the vehicle(s) 100 and user device(s) 200 are close enough or otherwise positioned such that communications can be exchanged; or they can be initiated by user(s) 250, for example by using an "ACCESS" GUI command item 977 such as that shown in Figure 6I.

[00119] In either case, upon successful communication and verification of access codes at 509, vehicle(s) 100 can unlock their doors 290, etc., e.g., under the control of security and/or authorization components 222, 270 to permit user access to cargo and / or passenger compartments 208, 275. Optionally, user access can further be conditioned upon confirmation by vehicle security module 270 that the vehicle is otherwise unoccupied and safe to enter.

[00120] In some embodiments, when it is determined by either or both of controller 300 and a vehicle 100 that an authorized user is within reasonable proximity (for example, within 50 meters) of a vehicle 100, one or more systems 270, 268 of the vehicle can be activated in order to alert the user and help them locate or identify the responding vehicle. For example, headlights and/or parking lights can be illuminated, the vehicle's engine can be started; a horn or other audible signal may be sounded, etc.

[00121] When the vehicle is loaded and is ready for travel, at 510a, 510b, the user(s) 250 can use vehicle input devices 251 , 254, 258 to inform vehicle(s) 100 and/or central management system 300 that they are ready to proceed. Alternatively, or in addition, the user(s) 250 can use their control devices 200 and/or management modules or apps 395 to communicate with either or both of the vehicle(s) 100 and management system(s) 300.

[00122] Upon receipt of such confirmation, the vehicle(s) 100 can autonomously navigate to the desired destination(s). Optionally, at 51 1a, 51 1b user 250 can use any of input devices 306, 258, etc., and/or modules 395 to modify or revise the route taken by the vehicle through exchange of suitable route revision request signal sets with either or both of vehicle(s) 00 and/or central system 300. [00123] Upon arrival at the desired destination(s), at 512a, 512b vehicle(s) 100 and/or user 250 can confirm safe arrival for central system9s) 300, and return control of the vehicle(s) 100 to the central system(s) 300.

[00124] At 513a, 513b, central system 300 can exchange any further required signal sets with user device 200 and/or FSP system(s) 600 to confirm or complete final authorized payment. For example, where a user 250 has modified an initial request, by for example modifying a pre-designated vehicle route, or adding one or more waypoint stops, for example to collect or let out fellow passengers or cargo, then the central control system(s) 300 can perform any suitable calculations to update and collect payments due, using processes such as those described above.

[00125] When a vehicle 100 has been released from a service request, at 514 central control system 300 can poll the released vehicle 100 to assess its condition and availability for any further calls.

[00126] Depending upon any response received to the polling request at 515, at 516 central system 300 can route vehicle(s) 100 to new call requests, or to any designated waiting, maintenance, or fueling/charging facility(ies) 400, as required. Upon satisfactory disposition, the vehicle(s) 100 can secure themselves by returning to designated locations, shutting down, locking up, etc.

[00127] Upon determining that fueling, charging, or other maintenance is required, at 517a, 517b, either or both of vehicle 100 and/or central control system 300 can notify maintenance system 400, so that the system can schedule and/or otherwise prepare to provide the requested services.

[00128] Thus in various aspects and embodiments, the invention provides controllers 300 for fleets of autonomously-operable land vehicles 100, the controllers comprising at least one data processor 402; at least one data communication system 404, 410 communicatively linked to the data processor 402; and at least one persistent memory device 420, the at least one persistent memory device 420 comprising stored data representing machine-interpretable instructions adapted to cause the at least one data processor to adjudicate and control responses to vehicle service requests.

[00129] For example, using the at least one data communication system 404, 410, such a controller 300 can receive from a vehicle request control device 200 at least one vehicle request data set, the at least one vehicle request data set representing a vehicle request and comprising data representing at least a pickup location and a requested service type. The controller 300 can parse the request and, using one or more vehicle monitoring components 408 adapted to poll or otherwise monitor the current availability or status of a plurality of autonomously operable vehicles, and/or location monitoring components 412, identify one or more of a plurality of at least one autonomously operable vehicle 100 corresponding to and suitable for responding to the requested service type; and using the same or another data communication system 404, 410, route to the at least one identified autonomously operable vehicle 100 a response instruction data set, the response instruction data set configured to cause the at least one vehicle to initiate at least one action responsive to the vehicle request.

[00130] Identifying a vehicle corresponding to and suitable for responding to the requested service type can, for example, comprise identifying one or move vehicles controllable by the controller at least one vehicle having characteristics satisfying the vehicle request data set - for example, the closest vehicle, a vehicle which can respond in the shortest amount of time, or most closely conforms to the request. Such vehicle(s) can be identified by consulting tables generated or controlled by modules 408, 412 and stored in memory such as memory 420 associated with the controller, and/or can by polling a plurality of vehicles in real time. For example, vehicle status request data set can be routed to one or more vehicles, the vehicle status request data set comprising at least a vehicle identifier, such as a telephone number or other network address or identifier, and a code requesting an update on vehicle status. Such a request can cause one or more processors 257 of the vehicles to which they are sent to return one or more vehicle status data sets, the vehicle status data sets comprising, for example, data representing some or of the following data items:

<vehicle ID ><operational status><location><fuel state><service due > where:

<vehicle ID > = identifier(s) associated with the vehicle, which identifiers may be associable with data representing, for example, vehicle type (e.g. 2-door, 4-door, van, truck, etc.) operational status> = identifier(s) representing, for example, any or all of

navigable (i.e. , capable of safe transit or navigation), clean/dirty, ECS status, etc.

<location> = identifier(s) representing current or prospective vehicle location <fuel state> identifier(s) representing absolute or relative fuel or energy

availability, which information may for example be associable with a range of operations the vehicle is currently capable of

<service due> = flag or indicator indicating whether any engine, system, or other maintenance is due

<pickup location> = identifier(s) associated with one or more street addresses or other geographical locations at which a requesting user 250 would like a vehicle to arrive, to pick up the same or another user or users 250, cargo to be transported, etc.

[00131] The data configured to cause the at least one vehicle 100 to initiate at least one action responsive to the vehicle request can comprise data representing instructions, executable by the one or more processors 257 of the autonomously- operable vehicle, configured to cause the vehicle 100 to, for example, navigate to a pickup location specified in the vehicle request data set, and/or to authorize access to the vehicle, for example through use of access authorization tokens as described herein. Instructions for such navigation and/or access authorization can be generated by the one or more vehicle processors 257, and routed to vehicle call response system 266, navigation system 262, 268 etc., and/or operational controls 268, to cause the vehicle to navigate to any required or desired pickup, meeting, or other location(s), using for example, known autonomous navigation techniques. Thus, for example, the at least one action responsive to the vehicle request can comprise autonomously proceeding (or navigating) by the vehicle(s) 100 to the pickup location(s).

[00132] As noted above, in various embodiments routing of vehicles 100 to requested pickup locations, and/or authorizing access to vehicles 100 by users 250, can be conditioned upon various forms and types of signal exchanges between user devices 200, controllers 300, and in some embodiments either or both of vehicles 100 and/or FSP systems 600, resulting in satisfaction of payment or payment assurance requirements by requesting users 250 and/or FSP systems 600. For example, any or all of vehicle request data sets, vehicle access authorization data sets, and requests for modification of vehicle routing instructions, and/or requests for release of control of a vehicle by a user 250/user device 200 can comprise data representing payment instructions, and/or payment authorization requests. In such embodiments, controllers 300 can be configured, in response to such payment authorization requests and/or payment instructions, to one or more transaction payment process controller(s) or FSP system(s) 600, transaction payment request data sets. Such a transaction payment request data set can comprise, for example, data representing at least a transaction payment amount and at least one account identifier for a repository for funds paid count in association with the transaction. Such payment request data sets can be routed by controllers 300 directly, or via vehicles 100 associated with the payment request. Payments or authorizations can be satisfied using proceeds of credit, debit, loyalty, or other value-based accounts.

[00133] In such embodiments, routing by the controller(s) 300 of response instruction data sets to vehicles 100 assigned to satisfy user requests can be conditioned upon verification by the controller(s) 300 of satisfaction of one or more criteria associated with the at least one payment instruction. Such criteria can, for example, include completion of payment, or confirmation of the availability of funds sufficient to cover any required payments, including payments for requested services and in some embodiments deposits or reserves for damage caused to vehicle(s) 100 by users 250 or other passengers, or by cargo placed in the vehicle(s) 100, etc.

[00134] For example, verification by a controller 300 of satisfaction of at least one payment criterion can conditioned upon receipt by the controller 300, using the same or another data communication system 404, 410, of a transaction payment confirmation data set, or payment assurance data set, generated by a transaction payment process controller 600. Such a data set can, for example, comprise a simple yes/no flag responsive to a request by the controller 300 whether funds sufficient to cover the requested services, damage deposits, etc., are available for payment to one or more accounts specified by the controller 300. As another example, a flag 1 , 2, or 3 can be used for confirmation, where

1 = payment confirmed 2 = confirmed that funds are available, but not yet paid

3 = funds not available

As will be understood by those skilled in the relevant arts, once they've been made familiar with this disclosure, a very wide variety of schemes for formatting and content of transaction payment confirmation data sets are known, and suitable for use in implementing the invention.

[00135] As a further example, in some embodiments a response instruction data set routed to a vehicle 100 by a controller 300 can cause the vehicle 100 to proceed to a pickup location, whereupon subsequent initiation by the vehicle of further actions responsive to the vehicle request data set is subject to routing by the controller 300 to the vehicle 100 of a request completion authorization data set, and routing of the request completion authorization data set can be conditioned upon verification by the controller of satisfaction of at least one transaction payment criterion, including for example processing of transaction payment confirmation data set(s) as described above.

[00136] As explained above, in various embodiments vehicle request data sets in accordance with the invention comprise data representing one or more vehicle condition request. As noted above, for example, such vehicle condition request data can comprise representing one or more environmental control instruction requests, such as air-conditioning, heating (i.e., temperature and/or humidity) conditions, seat warmer and/or window settings, refrigeration for cargo, etc.. Vehicle condition request data sets can further comprise data representing interior entertainment system request, such as audio and/or video system settings, etc.; passenger food, drink, and other refreshment requests, etc.

[00137] As explained above, a wide variety of processes can be used to authorize access by a user 250 to a vehicle 100 which has arrived (or has been approached by a user 250) at a pickup location. User identification authorization and/or user access authorization data sets can, for example, be routed between fleet vehicle controllers 300, vehicles 100, and user control devices 200 in a wide variety of sequences and combinations, depending on the uses and manners in which vehicles 100 are employed by the users. Identification/authorization data can, as explained above, comprise human- and/or machine-interpretable codes, biometrics, passwords, etc. as explained above. Identification and/or authorization can also be based on proximity of vehicles 100 and users 250 at the time when use commences.

[00138] For example, a controller 300 which has received from a user device 200 as part of a vehicle request data set, or which otherwise has access to one or more identifiers associated with a user 250 and/or the same or another user device 200, which in such a context may be referred to as a local operator control device 200, can be configured to compare a location of the operator control device 200 with a location of the at least one autonomously operable vehicle; and, conditioned upon satisfaction of a proximity criterion, to route to the at least one autonomously operable vehicle a user identification authorization or access authorization data set.

[00139] In such embodiments, proximity criteria may consist of comparisons of geographic positions of the local operator control device 200 and the vehicle 100, for example through the use of vehicle positioning system(s) 267 and user device positioning system(s) 310. For example, at 512a in Figure 5 a vehicle 100 responding to a service request can report to a controller 300 associated with the request the position of the vehicle, based on signals provided by a GPS or other positioning system 267 of the vehicle. Contemporaneously (within for example 10, 15, 30, or 60 seconds before or after the vehicle report, or within any other suitable time relative to reporting by the vehicle, or vice-versa), at 512b a user control device 200 associated with identifiers received as part of a vehicle request data set can report to the controller 300 a position of the control device 200, based on signals received from GPS or other positioning system 310. Such device positioning information can, for example, be pushed by the control device 200 to the controller 300, or be pulled from the device 200 by the controller 300. When the controller 300 has suitably contemporaneous position reports from both the vehicle 100 and the user control device 200, the controller can compare the positions to determine whether they are in sufficiently close proximity to warrant generation and routing to either or both of the vehicle 100 and user control device 200 secure access authorization tokens or other access authorization instruction or data sets such as codes, biometric data, etc. For example, such access authorization data sets can be routed by the controller if the vehicle 100 and user device 200 are reported to be within 5, 10, 15, 20, 30, or 50 feet of each other, within a space of 10, 15, 30, 60 seconds, or other time period and distance deemed suitable by the vehicle controller 300. As will be appreciated by those skilled in the relevant arts, different time periods and different distances can be used for access authorization, depending upon the conditions under which the vehicles 100 are used. Such conditions can, for example, include demographic, socio-economic, or other risk conditions, including traffic patterns, local traffic conditions, etc.

[00140] In the same and other embodiments, proximity between user device(s) 200 and vehicle(s) 100 can be determined based on communications exchanges between proximity communications devices 314, 254 of the user device(s) 200 and vehicle(s) 100. For example, rather than, or in addition to, relying on comparisons of proximity by controllers 300, access authorizations can be conditioned upon successful communication of secure biometric, code, or other tokens from a user device 200, using an RFID, NFC, or other short-range communication system 314, to a corresponding RFID, NFC, or other short-range communication system 254 of a vehicle 100. For example, a user 250 wishing to access a vehicle 100 can select an "ACCESS" item 976 such as that shown in Figure 61, and thereby cause processor(s) 302 of his/her device 200 to route, via proximity communication system(s) 314, a secure access token such as those described above to a proximity communication system 254, 259 of the vehicle 100, for use in adjudication of an access authorization request as described herein.

[00141] Upon receipt of and successful comparison or other adjudication of access authorization tokens or other access authorization data sets, user device(s) 200 and vehicle security and authorization systems 270, 222 can exchange signals, such as those described above, in order to grant vehicle access by, for example, unlocking vehicle passenger and/or cargo compartment doors, etc.

[00142] Thus, for example, in various aspects and embodiments of the invention a controller 300 can be configured to route user access authorization data sets such as tokens to either or both of device(s) 200 and vehicle(s) 100 upon satisfaction of various conditions, including for example receipt from the at least one local operator control device 200 associated with the vehicle request data set of a suitable user access request data set.

[00143] In various embodiments, comparison of tokens passed from user device(s) 200 to vehicle(s) 100 can be made by processor(s) 257 of vehicle(s) 100 responding to service or call requests. Criteria to be used in adjudicating such comparisons, and determining whether to authorize access to users 240 can be of any suitable type, including many which are known to those skilled in the arts of secure electronic authorizations.

[00144] Thus, for example, in various aspects and embodiments the invention provides controllers 300 for fleets of autonomously-operable land vehicles 100, the controllers configured receive from vehicle request control devices 200 vehicle request data sets, each such vehicle request data set representing a vehicle service request and comprising data representing at least a pickup location and a requested service type; to identify, among a plurality of vehicles 100, at least one autonomously operable vehicle controllable by the controller 300 and corresponding to the requested service type; route to the at least one identified autonomously operable vehicle 100 a vehicle access authorization data set, the vehicle access authorization data set comprising a first access authorization token interpretable by one or more processors of the identified autonomously operable vehicle; and route to the same or another vehicle request control device 200 a user access authorization data set, the user access authorization data set comprising a second access authorization token interpretable by one or more processors of the identified autonomously operable vehicle; the first and second access authorization tokens useable by one or more processors 257, 222, 270 of the autonomously operable vehicle 100 to adjudicate a request for access to the vehicle communicated to the vehicle by the same or another vehicle request control device; and, conditioned upon successful adjudication of the request, to authorize access to the vehicle 100 by, for example, unlocking and/or opening doors of passenger and/or cargo compartments.

[00145] As previously noted, fleet or pool management and control systems 300 can be configured to monitor vehicles 100 in service transporting passengers 250, cargo, etc., and to interact with such vehicles which are in need of or subject to requests for rerouting or other changed instructions; which are experiencing vehicle, passenger, or road emergencies, etc.; in order to implement suitable corrective action(s). Such actions can include re-routing of assigned vehicles 00 appropriately over city or other streets or thoroughfares to avoid accidents, traffic jams, or construction; monitoring and controlling of the performance and repair or maintenance needs of vehicles 100 and commanding the vehicle(s) 100 to take corrective action as appropriate; monitoring the safety and security of passengers 250 and/or cargo carried by vehicles 100 and commanding the vehicle(s) 100 to take corrective action as appropriate in case of emergency; and communicating with emergency and other services 500 in case of need, etc., to request assistance, etc.

[00146] Thus, for example, in various aspects and embodiments the invention provides controllers 300 for fleets of autonomously-operable land vehicles 100, the controllers configured to receive from one or more autonomously operable vehicles 100 vehicle exception data set(s), and, responsive to the vehicle exception data set(s), generate vehicle corrective action command data set(s), the vehicle corrective action command data set(s) comprising data representing one or more instructions executable by processor(s) 257 of the autonomously operable vehicle(s) 100 and configured to cause the processor(s) 257 to initiate corrective action(s) in response to condition specified by or otherwise associated with the vehicle exception data set(s).

[00147] For example, at 518a in Figure 5, a passenger 250 in a vehicle 100 can use his or her user control device 200 to access an emergency reporting function generated by a vehicle management app or module 395, for example by selecting a "HELP" or other emergency icon 973 as shown in Figure 6J, selection of which can invoke a process controlled by processor(s) 302 of soliciting information or, in various embodiments of immediately (i.e., without further input) sending an unspecified emergency message to one or more of controllers 300, 400, 500, etc.. generate a vehicle exception data set reporting a passenger, vehicle, or other emergency or vehicle maintenance requirement, and can use the device 200 to route the exception data set to a controller 300, either directly, e.g., by means of one or more networks 800; or indirectly, e.g., by means of vehicle input and/or communications systems 258, 251 , 254.

[00148] Alternatively, at 518a in Figure 5, a passenger 250 in a vehicle 100 can use his or her user control device 200 to access a "NEW WAYPOI T" or other new stop or re-routing interface and generate a request for such request modifications. For example, by selecting a "NEW WAYPOINT" command item 978 such a user 250 can cause a vehicle management module 395 to generate a GUI configured to solicit information for a new or additional destination location, for use in generation of a corresponding vehicle exception data set. [00149] Alternatively, or in addition, at 518b in Figure 5 any or all of vehicle security system(s) 270 of a vehicle 100, including for example any passenger or cargo compartment monitors 271 such as microphones coupled to voice recognition systems, and/or vehicle input device(s) 258, such as a touchscreen and/or keyboard located on a control panel within the vehicle 100 and operated by a passenger or other user 250, can generate or be used to generate a vehicle exception data set reporting a passenger, vehicle, or other emergency or vehicle maintenance requirement, and can use any or all of communications systems 251 , 254, etc. , to route the route the exception data set to a controller 300. In some embodiments, an interior of a passenger compartment of a vehicle 100 can include an alarm or emergency system, activation of which causes an unspecified emergency to be routed to any or all of controllers 300, 400, 500 without further human input.

[00150] Vehicle exception data sets in accordance with such embodiments and aspects can, for example, include any or all of the following data records:

<vehicle operating status><exception type > where:

<vehicle ID > = identifier(s) associated with the vehicle, vehicle type, etc.

<passenger ID> = identifier(s) with any requesting users 250 and/or other

passengers in the vehicle

<location> = identifiers representing current and/or prospective vehicle

location(s) (e.g., assigned destination)

<vehicle operating condition> = vehicle speed, engine condition, fuel state, vehicle orientation (e.g., upright, overturned), etc.

<exception type> = flag representing type of exception reported, e.g., re-route or new stop request, passenger health concern, engine fire or overheat, low or exhausted fuel; collision; traffic delay;

unspecified danger to vehicle and/or passengers

[00151] Upon receipt of a vehicle exception data set, processor(s) 402 of the receiving controller(s) 300 can parse the data records comprised by the exception data set and determine an appropriate course of action, for example by reference, in accordance with known techniques, to an exception look-up table stored in persistent memory 420 associated with the controller 300. Look-up tables suitable for use in accordance with the invention can comprise any desired, required, and/or otherwise useful information, including for example vehicle corrective action type(s) corresponding to the received exception type data record(s); locations of exception response facilities such as hospitals, fuel facilities, repair facilities, tow trucks, fire stations, ambulance stations, and/or other emergency facilities comprising resources suitable for response to the reported exceptions. Controller(s) 300 in such circumstances can further compare reported vehicle location(s) and operating conditions to the locations of such exception response facilities and determine which response facilities may be best positioned or otherwise qualified to respond.

[00152] Using such processes and information, responsible controller(s) 300 can generate one or more vehicle corrective action command data set(s), such vehicle corrective action command data set(s) comprising data representing one or more instructions executable by processor(s) 257 of the autonomously operable vehicle(s) 100 and configured to cause the processor(s) 257 to initiate corrective action(s) in response to condition specified by or otherwise associated with the vehicle exception data set(s).

[00153] For example, in various embodiments vehicle corrective action data set can comprise data representing an emergency response location, and the at least one corrective action can comprise proceeding, by the autonomously operable vehicle 100, to the emergency response location. In the same and other embodiments the corrective action comprises identifying, by the same or another data processor of the at least one autonomously operable vehicle 100, by example by reference to a look-up table or navigation resource 262, of an emergency response location, and causing the autonomously operable vehicle to proceed to the emergency response location.

[00154] Vehicle corrective action data sets in accordance with such embodiments and aspects can, for example, include any or all of the following data records:

<system status commandsxpassenger message(s)> where:

<vehicle ID > = identifier(s) associated with the vehicle, vehicle type, etc.

<command type(s)> = flag(s) or other identifier(s) corresponding to a desired vehicle response(s), e.g. , stop at current or nearest safe location; drive to specified new or additional location; turn on interior lights; turn on exterior emergency lights or warning signals; unlock passenger doors; lock passenger doors; etc.

<location> = identifiers representing location(s), if any, to be referenced in

execution of specified command type(s); e.g., location of hospital, fuel station, police station, fire station, ambulance station, etc.

<system status commands> = signals representing commands pertaining to individual vehicle systems, e.g. , navigation system(s) 262 (drive at fastest safe speed, take alternative route, etc.); ECS system(s) 294 (shut down, etc.), interior exterior lights, etc.

<passenger message> = instructions and/or reassurances suitable to the

reported exception(s), for presentation go vehicle passengers and/or emergency responders, e.g. , by display on an output display 256, by voice message using speaker(s) 273, etc.

[00155] Upon generation, controller(s) 300 can route such vehicle corrective action data sets to corresponding vehicle(s) 100 for execution, via any or all of communications system(s) 404, 410, 251 , 254, etc. The same or other messages can also be routed to corresponding user control device(s) 200, including for example device(s) 200 used to generate vehicle service request data sets, device(s) associated with passenger(s) 250 in the vehicles, etc.

[00156] Moreover, at any applicable point(s) 518a, 518b, 518c of Figure 5, any or all of user device(s) 200, vehicle 100, central control system 300, and/or other party can directly notify an emergency system 500 of the need for assistance, by means of passenger or vehicle emergency notification data sets, and at 519 the emergency system 500 can respond appropriately. [00157] Thus, for example, in various aspects and embodiments the invention further provides controllers 300 configured to generate passenger emergency notification data sets comprising data identifying at least a nature of an existing emergency condition and an emergency response location at which an emergency responder can find the at least one autonomously operable vehicle and, using the same or another data communication system, route the passenger emergency notification data set to at least one emergency response controller 500.

[00158] In cases in which the reported exception type includes a malfunction associated with one or more systems 268, 262, etc., of the autonomously operable vehicle 100, the controller(s) 300 can be configured to generate vehicle service notification data set(s) comprising data identifying at least a nature of the vehicle malfunction and a service response location at which an emergency responder such as a tow truck or repair vehicle can find the at least one autonomously operable vehicle 100 and, using the same or another data communication system, route the suitably configured vehicle malfunction notification data set(s) to one or more vehicle service response controllers 400. In such embodiments a vehicle corrective action data set can comprise data representing one or more service response locations, designated by any or all of controllers 300, 257, 400 and the at least one corrective action can comprise proceeding by the autonomously operable vehicle to the service response location.

[00159] Thus, it will be seen that a further advantageous component of various embodiments of systems 1000 is the ability of any or all of the components to communicate with one or more emergency service systems or controllers 500. For example, an emergency response system 500 may be informed of an accident, injury, or other incident involving a vehicle 100 and/or passenger 250, by any or all of user devices 200, vehicles 100, and/or control stations 300, 400. Thereafter emergency system 500 can communicate with any or all of devices 200, 100, 300, 400 to coordinate a suitable response, including for example, routing of a vehicle 100 to a safe or otherwise designated location, release of doors or other devices of the vehicle 100, stopping of the vehicle 100, and/or routing of one or more emergency vehicles to a location designated by any or all of systems 100, 200, 300, 400, 500.

[00160] It may also be seen that in further aspects and embodiments the invention provides autonomously operable vehicles 100, and controllers 299 therefor, suitable for use in implementing any of the functions and processes disclose herein. Such vehicles 100 can, as explained above, comprise motive and operational navigation means 268, such as for example, wheels, motor(s) and/or engine(s), and drive trains, steering systems, brakes, 264 etc.; and one or more controllers 299 comprising one or more navigation controllers 262 which can for example include GPS and other positioning systems 267 position-monitoring systems 267; one or more vehicle access controllers 222, 270, 271 , 254, etc.; one or more data communications systems 251 , 254; and one or more data processors 257 directly or indirectly communicatively linked to each of the foregoing and to one or more persistent memory devices 286 comprising data representing stored, machine- interpretable instructions adapted to cause the processor(s) to receive, via the at least one data communication system 251 , 254 vehicle request data sets, each such data set comprising data representing at least a pickup location; using the at least one navigation controller(s) 262 and motive means 268 etc., cause the autonomously operable vehicle 100 to proceed to the pickup location; and subject to receipt and authentication of a user access request data set, cause the at least one vehicle access controller 222, 270, 271 , to unlock or otherwise place at least one vehicle access portal (e.g., passenger or cargo door) into an openable state.

[00161] In various embodiments, such vehicles 100 and controllers 299 are configured so that either or both of causing the vehicle to proceed to the pickup location and placing the at least one vehicle access portal into an openable state is conditioned by the at least one data processor 257 on receipt of a transaction payment confirmation data set. Such data sets are generally generated by controller(s) 300 associated with the vehicles 100, as described above, and can be communicated to the processor(s) 257 by the controller(s) 300 directly, by means of communications systems 251 , 254, and/or indirectly by user control devices 200, by means of communications systems 251 , 254, and/or POS system(s) 259 provided on the vehicles, for example for direct payment using chip cards, smart phones, etc.

[00162] In the same and/or further embodiments, vehicles 100 and controllers 299 can be configured so that, as described above, processor(s) 257 can cause one or more vehicle environment control systems 294 to initiate various vehicle environmental control actions, such as requested heating, cooling, entertainment, or refreshment functions, in response to instruction data sets generated by either or both of controller(s) 300 and/or user device(s) 200, in accordance with data received by the at least one data communication system representing one or more vehicle environmental condition requests. For example, as described above such vehicle environmental control actions can include vehicle interior environmental control actions, such as setting passenger and/or vehicle compartment temperatures, humidity, seat warmer functions, refrigeration, etc.; and/or vehicle interior entertainment system control action such a music or video settings.

[00163] In the same and other embodiments, vehicle(s) 100 and controllers 299 thereof can comprise vehicle security and or operational monitoring device(s) 270, such as passenger and/or cargo payload compartment cameras, passenger seat or cargo floor weight sensors; microphones, speakers; or smoke-, heat-, infrared-, motion-, or shock-detectors; 258, 271 communicatively linked to data processor(s) 257 and adapted to monitor conditions in passenger and/or cargo compartments 275, 280 and communicate to the data processor(s) 257 signals representing exceptional vehicle operating condition, such as passenger or vehicle emergences, such that, as shown for example at 515, 517b, 518c in Figure 5, the data processor(s) 257 can route to exceptional vehicle operation response controller(s) 300, 400, 500 vehicle operating exception data sets comprising data representing the exceptional vehicle operating condition(s). Vehicle operating exception data sets according to such embodiments can, for example, include any or all of the following:

<vehicle operating status><exception type > requested vehicle exceptional condition response location> where:

<vehicle ID > = identifier(s) associated with the vehicle, vehicle type, etc.

<passenger ID> = identifier(s) with any requesting users 250 and/or other

passengers in the vehicle

<location> = identifier(s) representing current and/or prospective vehicle

location(s) (e.g., assigned destination)

<vehicle operating condition> = vehicle speed, engine condition, fuel state,

vehicle orientation (e.g., upright, overturned), etc. <exception type> = flag representing type of exception reported, e.g., re-route or new stop request, passenger health concern, engine fire or overheat, low or exhausted fuel; collision; traffic delay;

unspecified danger to vehicle and/or passengers

requested vehicle exceptional condition response location> = identifier(s)

representing one or more requested or proposed locations for meeting response managers, acquiring emergency or maintenance services, etc.; can be specified by user(s) 250 using onboard input devices 258, and/or generated by vehicle on-board systems 257, 262, etc. ; may be current or any other location.

[00164] In response to the routing of such vehicle operating exception data sets, any or all of exceptional vehicle operation response controller(s) 300, 400, 500 can generate vehicle corrective action command data set(s), and as shown for example at 516, 519 in Figure 5, can route the vehicle corrective action command data set(s) to the vehicle(s) 100 for execution. For example, in response to receipt by one or more of data communication system(s) 251 , 254, processor(s) 257 can consult suitably-configured look-up tables stored in memory(ies) 286 and generate suitably configured vehicle system corrective action command data set(s) and route them to navigation controller(s) 262 and/or other system controllers 294, 270, etc., for execution. Vehicle system corrective action data sets according to such embodiments can, for example, include any or all of the following:

where:

<vehicle system ID > = identifier(s) associated with navigation, ECS, security, and/or other system(s) 262, 294, 270, etc. associated with required exception response(s)

<instruction> = signal(s) suitable for causing the identified vehicle system(s) to take corrective action in response to the operating exception(s) [00165] It is important to note that such embodiments of the invention enable exceptional vehicle operation response controller(s) 300, 400, 500 to override other vehicle operating commands, and take control of vehicle(s) 100 in emergency or other conditions, at least until the exceptional operating condition(s) have been resolved. For example, a vehicle corrective action command data set generated by an exceptional vehicle operation response controller 300 300, 400, 500 in accordance with such an embodiment of the invention can comprise data representing an emergency response location, and the at least one vehicle system corrective action data set can comprise signals representing instructions configured to cause the at least one navigation controller 263 to navigate the vehicle to the emergency response location. In various embodiments of such aspects of the invention, the vehicle system corrective action data set can further comprise signals representing instructions configured to cause one or more of security controllers 270, 271 to unlock passenger and/or cargo doors, and/or otherwise place one or more vehicle access portal into an openable state when the vehicle has come to a stop and is no longer in motion.

[00166] As further explained above, in various embodiments of the invention authorization of access to vehicle(s) 100 by user(s) 250 can be accomplished in whole or in part by means of processes involving any or all of user device(s) 200, controller(s) 300, and processor(s) 257 communicating by means of any of communications systems 251 , 254, 312, 314, 404, 410, etc. In some embodiments, for example, such processes can be implemented through the use of wireless proximity communication device(s) 254, 259 of a vehicle 100, configured to receive user access request data set from vehicle request control devices 200 vehicle users 250.

[00167] For example, as previously explained in conjunction with Figure 61, a user 250 of a device 200 can select an "ACCESS" command item 977 of a GUI 610, 677 and thereby cause one or more of processors 302 to access an access authorization token stored in memory(ies) 304 and/or 420, and use it in conjunction with an access request data set, and route the access request data set via proximity and/or network communications system(s) 314, 312 to one or more of vehicle communication(s) systems 254, 259, 251. In such cases, for example, a vehicle proximity communications system 254, 259 can receive the access request data set, compare the embedded token to a token provided to the vehicle 100 by one or more of controller(s) 300, and, based on successful comparison, authorize access to the vehicle by routing to security components 270, 271 signals adapted to cause the security components to unlock or open one or more passenger and/or cargo doors.

[00168] In some embodiments of such vehicles, access authorization codes provided to a user device 200 by a controller 300 may be communicated to vehicle 100(s) by a user 250 through the use of, for example, a local operator input device such as a keypad 258, 259 accessible from an exterior location on the vehicle 100.

[00169] It may further be seen that in various aspects and embodiments the invention provides vehicle request and/or control devices 200, such devices comprising one or more input devices 306, wireless data communication system(s) 312, 314, and data processors 302 communicatively linked thereto, and to one or more persistent memory devices, the persistent memory device(s) comprising stored data representing machine-interpretable instructions adapted to cause the at least one data processor 302 implement any or all of the processes described herein. For example, in accordance with one or more command signals received from the at least one input device 306, processor(s) 302 can be configured to generate vehicle request data sets, the vehicle request data sets comprising data representing at least a pickup location and a requested service type, as described above, and to route such vehicle request data sets to suitably-configured autonomously-operable vehicle controller(s) 300.

[00170] In the same and other aspects and embodiments, user control devices 200 can be configured to enable user(s) 250 to generate vehicle routing instructions and route them to autonomously operable vehicle controllers 300, 257 for execution. Such instructions can, for example, be routed directly to processor(s) 257 of a vehicle 100, and/or they can be routed indirectly, by way of controller(s) 300. For example, a user of a device 200 can invoke a vehicle management module 395 to access GUIs 610 such as those shown in Figures 6A - 6J. Through the use of command items 614, 650, 978, for example, a user can access a GUI 610, 935 such as that shown in Figure 6K, and by using input devices 258 such as command buttons 306, touchscreen 316, etc., generate data representing preferred routes, waypoints, revised destinations, etc. For example, by invoking a "WAY POINT" command item 936, or "DESTINATION" item 937, a user 250 can be presented with a virtual keyboard 306, 390, 398 useful for typing desired location information; alternatively, or in addition, an interactive map application or device 958 can be used to designate desired waypoints or alternative destinations.

[00171] For example, a user 250 being carried in or waiting for a vehicle 100 in response to a previously negotiated service request can that modified and/or overridden to include alternative or additional instructions. In such cases the vehicle request control device 200 can be configured, in accordance with one or more command signals received from the at least one input device, to generate one or more vehicle navigation control data sets, the vehicle navigation control data set(s) comprising data representing at least a vehicle routing instruction such as a destination, waypoint, or preferred routing, and using one or more of data communication systems 404, 410, route the vehicle navigation control data set to the same or another autonomously operable vehicle controller 300, either directly or via a vehicle 100.

[00172] It may also be seen from the foregoing that the invention provides vehicle request control devices 200 configured to, in accordance with one or more command signals received from the at least one input device, generate vehicle environmental control data sets, such vehicle request data sets comprising data representing vehicle environmental control command signals; and, using the at least one data communication system, route the vehicle environmental control data set to the same or another autonomously operable vehicle controller.

[00173] A further advantage offered by the invention is the ability of a user 250 of a device 200 to 'hail' autonomously-operable vehicles 100 which may happen to be close by and able to respond quickly, without regard to the identities or systems of particular fleet controllers 300 who may control the vehicles.

[00174] Two examples (a) and (b) of such 'hailing' functionality are described by particular reference to Figure 7.

[00175] As noted above, for example, in various aspects and embodiments systems 1000 in accordance with the invention can comprise call service management system(s) 301 , which can be implemented in various embodiments as a part of, or in addition to, fleet management system(s) 300. Generally, call service management system(s) 301 can be thought of an additional layer or functionality of one or more vehicle controllers 300; in that system(s) 301 can operate without direct control of any vehicles 100, but instead by referring calls to controllers 300 which do control autonomous vehicles 100. It will be appreciated by those skilled in the relevant arts that such functions can be considered equivalent to a function performed by a fleet controller 300 of referring vehicle service requests to other controllers, such when none of the vehicles controlled by a controller 300 is suitable for or otherwise available to respond to a service request.

[00176] For example, in some embodiments call service system(s) 300, 301 operate solely as independent service providers, taking requests from user devices 200 and referring them to other controllers 300.

[00177] As shown for example at (a) in Figure, a user of a user control device 200 can access a vehicle management application 395, which may for example be associated with a preferred call service manager 301 , and invoke a GUI "HAIL" command device 983 such as that shown in Figure 6C. Invocation of the "HAIL" command device 983 can cause the user's device 200 to generate a vehicle hail data set, the vehicle hail data set comprising any or all of the following:

<service request codexpayment information^ where:

<call service ID> = network identifier(s) associated call service manager(s) 301 to which the hailing request is to be routed; can be set by default by application 395

<hailing location> = identifier(s) associated with the current location of the device

200. Data representing this information may be generated automatically by processor(s) 257 of the device 200, for example by reference to device positioning system(s) 310 requesting user> = identifier(s) associated with a requesting user 250, as for example personal identifiers associated with an individual user, and/or with a business or other entity associated with the user; may be associated by call service system 301 with payment information destination(s)> = identifier(s) identifier(s) associated with one or more street addresses or other geographical locations to which a requesting user 250 would like a vehicle to go, to deliver the same or another user or users 250, cargo to be transported, etc. This information can also be provided by the requesting user to a responding vehicle 100, for example by means of proximity communications systems 314, 254, rather than to a call service system 300, 301 , particularly where for example privacy is desired

requested service type and preferences> = identifier(s) associated with type(s) of requested service(s), e.g., number of passenger(s), size, weight, or amount of cargo, etc.; preferred vehicle management system(s) 300 (e.g. preferred cab companies), etc.

[00178] In some preferred embodiments of the invention, the foregoing information is determined and stored in advance, in memory(ies) 304, as for example by establishment of hailing preferences through the use of device(s) 634, 636, 638, 640,642 shown in GUI 61 1 of Figure 6F. The use of data stored in advance enables, for example, the use of a hailing item 983 to be a single-input command process; that is, simply by selecting the hailing command (and optionally a confirmation GUI such as that shown in Figure 6H) a user 250 can cause a hailing command (i.e., vehicle hail data set) to be routed to a call service system 301.

[00179] Subject to any confirmations solicited by a GUI such as that shown in Figure 6F, at 702, 704, 706 the vehicle request device 200 can route the vehicle hail data set to one or more fleet control system(s) 300, such as a call service system 301 . The call service system determine whether any vehicles 100 are in the immediate vicinity of the requesting device 200, for example by consulting virtual tables of vehicle status as described above, and/or can forward the vehicle data set to any one or more fleet management controllers 300a, 300b, 300c, etc., that may have suitable vehicles 100 available to respond to the request.

[00180] At 703a, 703b, 703c; 705a, 705b, 705c; and 707a, 707b, 707c; respectively, fleet controllers 300a, 300b, 300c can determine whether any of their respective vehicles 100 are sufficiently close, sufficiently convenient, and/or otherwise available to respond to the hailing request. As described above, this can be accomplished by consulting updated status lookup tables in memory(ies) 420, by polling individual vehicles, or both.

[00181] At 708, 709, 710, controllers 300c, 300b, 300a respectively can respond to call service manager system 301 with vehicle availability data sets comprising, for example, data representing vehicle identification, location, and projected arrival time information.

[00182] At 71 1 , call service manager 301 can compare responses received at 708-710, and determine which if any is are preferred. For example, call service manager 301 can compare projected arrival times (which manager 301 may independently verify) of competing availability data sets, preferences associated with the requesting user 250, etc.

[00183] In some embodiments, the call service manager 301 may designate one of a plurality of available vehicles 100 to respond to the hail request. In such embodiments, at 71 1 the call service manager can inform the corresponding vehicle controller 300, and can instruct or authorize the controller to respond. At 712, 713, the designated controller 300b can route to the designated vehicle 100 instructions for responding to the call, and receive a confirmation, which at 714 may be forwarded to the call manager 301 , which at 715 can forward a confirmation and any associated instructions to the requesting device 200; and further useful instruction date sets may be forwarded at 716-7 8.

[00184] In other embodiments, the call service manager can forward a list of available vehicles 100 to the requesting device 200, optionally in an order of ranked preference, and allow a user of the device 200 to select a vehicle 100 for service. In such embodiments, the user's selection may be forwarded to the corresponding selected fleet controller 300 for response by the selected vehicle 100.

[00185] Another example process of using a user device 200 to "hail" a vehicle is described with reference to process (b) shown in Figure 7. As described above, a user 250 of such a device can access a vehicle management application 395, which need not be associated with any preferred call service manager 301 , and invoke a GUI "HAIL" command item 983 such as that shown in Figure 6C. Invocation of the "HAIL" command device 983 can cause the user's device 200 to generate a vehicle hail data set, the vehicle hail data set comprising any or all of the following:

<service request codexpayment information^ and can be populated automatically using previously-established preferences. In addition to, or rather than, routing the vehicle hail data set to one or more fleet or call service managers 300, 301 , the user vehicle management app 395 can route the vehicle hail data set directly to one or more vehicles 100 which may happen to be within communications range of a suitably-defined proximity communications system 254, such as a Bluetooth or other radio-based system, or within one or more of a defined set of radio telephone 'cells' or antenna towers that can be reached using a suitably-configured network communications system 251 ; or within a specified range as determined using satellite positioning techniques.

[00186] In such cases at 760, 762 any vehicles available for responding to such a request can respond to the requesting device 200, either directly or through any one or more vehicle controller systems 300, 301. The vehicle management module 395 of the requesting device 200 can assemble a list 961 of any such vehicles, and present it to the requesting user 250 by means of a suitably-configured GUI 939 such as that shown in Figure 6L. In the example shown in Figure 6L, GUI 939 provides a list of available vehicles with indications of the size/type 962 of the vehicles, the entities 963 responsible for operating the vehicles, the projected relative arrival times 964 of the vehicles, and firm or estimated costs 965of providing the requested service. The list also provides 'radio button' GUI devices 966 to enable the requesting user 250 to select one of the vehicles, and a 'SEND' command item 941 to cause the device 200 to route at 764 a confirmed vehicle request data set to the selected vehicle and/or a vehicle management system 300 associated with the selected vehicle.

[00187] In all of the above signal exchanges, any or all of database(s) 420 and memories 304, 286 can store all received and routed data for future reference and analysis, to improve system and vehicle performance, customer satisfaction, environmental and operating efficiency, etc. [00188] While the disclosure has been provided and illustrated in connection with specific, presently-preferred embodiments, many variations and modifications may be made without departing from the spirit and scope of the invention(s) disclosed herein. The disclosure and invention(s) are therefore not to be limited to the exact components or details of methodology or construction set forth above. Except to the extent necessary or inherent in the processes themselves, no particular order to steps or stages of methods or processes described in this disclosure, including the Figures, is intended or implied. In many cases the order of process steps may be varied without changing the purpose, effect, or import of the methods described. The scope of the invention is to be defined solely by the appended claims, giving due consideration to the doctrine of equivalents and related doctrines.

[00189] It should in particular be noted that any of the above improvements, processes, devices, systems and components can be used in differing combinations, subject only to logical necessity and the intended uses of the system 1000 as implemented. This disclosure is meant to be enabling within its complete scope, and not limiting.

Claims

CLAIMS What is claimed is:

1. A controller for a fleet of autonomously-operable land vehicles, the controller comprising:

at least one data processor;

at least one data communication system communicatively linked to the data processor; and

at least one persistent memory device, the at least one persistent memory device comprising stored data representing machine-interpretable instructions adapted to cause the at least one data processor to:

using the at least one data communication system, receive from a vehicle request control device at least one vehicle request data set, the at least one vehicle request data set representing a vehicle request and comprising data representing at least a pickup location and a requested service type;

identify among a plurality of vehicles at least one autonomously operable vehicle corresponding to the requested service type; and

using the same or another data communication system, route to the at least one identified autonomously operable vehicle a response instruction data set, the response instruction data set configured to cause the at least one vehicle to initiate at least one action responsive to the vehicle request.

2. The controller of claim 1 , wherein the at least one action responsive to the vehicle request comprises autonomously proceeding to the pickup location.

3. The controller of claim 1 , wherein the data representing a requested service type represents at least a number of passengers to be transported.

4. The controller of claim 1 , wherein the data representing a requested service type comprises represents at least a type of requested vehicle.

5. The controller of claim 1 , wherein the data representing a requested service type comprises represents at least a type of service requested.

6. The controller of claim 1 , wherein the data representing a requested service type comprises represents at least one destination location.

7. The controller of claim 1 , wherein the vehicle request data set comprises data representing at least one payment instruction.

8. The controller of claim 7, wherein, responsive to the at least one payment instruction, the at least one data processor causes the same or another data communication system to route to at least one transaction payment process controller a transaction payment request data set, the transaction payment request data set comprising data representing at least a transaction payment amount and at least one account identifier for a repository for funds paid count in association with the transaction.

9. The controller of claim 7, wherein the data representing the at least one payment instruction comprises data representing at least one credit authorization request.

10. The controller of claim 7, wherein the routing the response instruction data set to the at least one identified autonomously operable vehicle is conditioned upon verification by the controller of satisfaction of at least one criterion associated with the at least one payment instruction.

11. The controller of claim 10, wherein verification by the controller of satisfaction of the at least one payment criterion is conditioned upon receipt by the controller, using the same or another data communication system, of a transaction payment confirmation data set generated by a transaction payment process controller.

12. The controller of claim 1 , wherein:

the response instruction data set causes the at least one autonomously operable vehicle to proceed to the pickup location, and

initiation by the at least one autonomously operable vehicle of further actions responsive to the vehicle request data set is subject to routing by the controller to the at least one autonomously operable vehicle of a request completion authorization data set, and

routing of the request completion authorization data set is conditioned upon verification by the controller of satisfaction of at least one transaction payment criterion.

13. The controller of claim 1 , wherein the vehicle request data set comprises data representing at least one vehicle condition request.

14. The controller of claim 13, wherein the data representing at least one vehicle condition request comprises data representing at least one environmental control instruction request.

15. The controller of claim 14, wherein the data representing the at least one environmental control instruction request comprises data representing at least one vehicle interior environmental control system request.

16. The controller of claim 14, wherein the data representing the at least one environmental control instruction request comprises data representing at least one interior entertainment system request.

17. The controller of claim 14, wherein the data representing the at least one environmental control instruction request comprises data representing at least one passenger refreshment request.

18. The controller of claim 14, wherein the at least one data processor; the at least one data communication system communicatively linked to the data processor; and the at least one persistent memory device are components of the at least one autonomously operable vehicle.

19. The controller of claim 2, wherein the at least one vehicle request data set comprises data representing an identifier associated with at least one local operator control device, and the stored data representing machine-interpretable instructions are adapted to cause the at least one data processor to: compare a location of the at least one local operator control device with a location of the at least one autonomously operable vehicle, and

conditioned upon satisfaction of a proximity criterion, to route to the at least one autonomously operable vehicle a user identification authorization data set.

20. The controller of claim 2, wherein the at least one vehicle request data set comprises data representing an identifier associated with at least one local operator control device, and the stored data representing machine-interpretable instructions are adapted to cause the at least one data processor to:

conditioned upon receipt from the at least one local operator control device associated with the vehicle request data set of a user access request data set, route to the at least one autonomously operable vehicle a user access authorization data set.

21. A controller for a fleet of autonomously-operable land vehicles, the controller comprising:

at least one data processor;

using the at least one data communication system, receive from a vehicle request control device at least one vehicle request data set, the at least one vehicle request data set representing a vehicle service request and comprising data representing at least a pickup location and a requested service type;

identify among a plurality of vehicles at least one autonomously operable vehicle controllable by the at least one processor and corresponding to the requested service type;

using the same or another data communication system, route to the at least one identified autonomously operable vehicle a vehicle access authorization data set, the vehicle access authorization data set comprising a first access authorization token interpretable by one or more processors of the identified autonomously operable vehicle; and using the same or another data communication system, route to the same or another vehicle request control device a user access authorization data set, the user access authorization data set comprising a second access authorization token interpretable by one or more processors of the identified autonomously operable vehicle;

the first and second access authorization tokens useable by the one or more processors of the autonomously operable vehicle to adjudicate a request for access to the vehicle communicated to the vehicle by the same or another vehicle request control device.

22. A controller for a fleet of autonomously-operable land vehicles, the controller comprising:

at least one data processor;

at least one data communication system communicatively linked to the data processor, and

using the at least one data communication system, receive from at least one of a user control device and an autonomously operable vehicle a vehicle exception data set, and

responsive to the vehicle exception data set, generate a vehicle corrective action command data set, the vehicle corrective action command data set comprising data representing one or more instructions executable by at least one data processor of the at least one autonomously operable vehicle and configured to cause the at least one data processor of the at least one autonomously operable vehicle to initiate at least one corrective action in response to a condition associated with the vehicle exception data set.

23. The controller of claim 22, wherein the vehicle exception data set comprises data corresponding to the existence of an emergency condition within a passenger compartment of the at least one autonomously operable vehicle, and

the stored, machine-interpretable instructions are adapted to cause the at least one processor, in response to receipt of the vehicle exception data set, to generate a passenger emergency notification data set comprising data identifying at least a nature of the emergency condition and an emergency response location at which an emergency responder can find the at least one autonomously operable vehicle and, using the same or another data communication system, route the passenger emergency notification data set to at least one emergency response controller.

24. The controller of claim 22, wherein the vehicle corrective action data set comprises data representing an emergency response location and the at least one corrective action comprises proceeding by the autonomously operable vehicle to the emergency response location.

25. The controller of claim 22, wherein the at least one corrective action comprises identifying, by the same or another data processor of the at least one autonomously operable vehicle, of an emergency response location, and causing the autonomously operable vehicle to proceed to the emergency response location.

26. The controller of claim 25, wherein the at least one corrective action comprises unlocking a door communicating with a passenger compartment of the at least one autonomously operable vehicle.

27. The controller of claim 22, wherein the vehicle exception data set comprises data corresponding to the existence of a vehicle malfunction associated with the at least one autonomously operable vehicle, and

the stored, machine-interpretable instructions are adapted to cause the at least one processor, in response to receipt of the vehicle exception data set, to generate a vehicle service notification data set comprising data identifying at least a nature of the vehicle malfunction and a service response location at which an emergency responder can find the at least one autonomously operable vehicle and, using the same or another data communication system, route the vehicle service notification data set to at least one vehicle service response controller.

28. The controller of claim 22, wherein the vehicle corrective action data set comprises data representing service response location and the at least one corrective action comprises proceeding by the autonomously operable vehicle to the service response location.

29. The controller of claim 22, wherein the at least one corrective action comprises identifying, by the same or another data processor of the at least one autonomously operable vehicle, of a service response location, and causing the autonomously operable vehicle to proceed to the service response location.

30. An autonomously operable land vehicle, comprising:

motive means;

at least one navigation controller;

at least one vehicle access controller;

at least one data communication system;

at least one data processor communicatively linked to the at least one

navigation controller, the at least one vehicle access controller, the at least one data communication system, and to one or more persistent memory devices comprising data representing stored, machine-interpretable instructions adapted to cause the at least one data processor to:

receive, via the at least one data communication system a vehicle request data set comprising data representing at least a pickup location;

using the at least one navigation controller and the motive means, cause the autonomously operable vehicle to proceed to the pickup location; and

subject to receipt and authentication of a user access request data set, cause the at least one vehicle access controller, place at least one vehicle access portal into an openable state.

31. The vehicle of claim 30, wherein at least one of causing the vehicle to proceed to the pickup location and placing the at least one vehicle access portal into an openable state is conditioned by the at least one data processor on receipt of a transaction payment confirmation data set.

32. The vehicle of claim 30, comprising at least one vehicle environment control system, wherein the stored, machine-interpretable instructions are adapted to cause the at least one data processor to cause the at least one vehicle environment control system to initiate at least vehicle environmental control action, in accordance with data received by the at least one data communication system representing one or more vehicle environmental condition requests.

33. The vehicle of claim 32, wherein the at least one vehicle environmental control action comprises at least one vehicle interior environmental control action.

34. The vehicle of claim 33, wherein the at least one vehicle environmental control action comprises at least one vehicle interior entertainment system control action.

35. The vehicle of claim 30, comprising at least one vehicle security monitoring device communicatively linked to the at least one data processor and adapted to communicate to the at least one data processor at least one signal representing an exceptional vehicle operating condition, wherein the stored, machine-interpretable instructions are adapted to cause the at least one data processor to route to at least one exceptional vehicle operation response controller a vehicle operating exception data set comprising data representing the exceptional vehicle operating condition.

36. The vehicle of claim 35, wherein the vehicle operating exception data set further comprises a current vehicle location.

37. The vehicle of claim 35, wherein the vehicle operating exception data set further comprises a requested exceptional condition response location.

38. The vehicle of claim 35, wherein the at least one vehicle security monitoring device comprises at least one payload compartment camera.

39. The vehicle of claim 35, wherein the at least one vehicle security monitoring device comprises at least one payload weight sensor.

40. The vehicle of claim 35, wherein the at least one vehicle security monitoring device comprises at least one microphone.

41. The vehicle of claim 35, wherein the at least one vehicle security monitoring device comprises at least one smoke detector.

42. The vehicle of claim 35, wherein the at least one vehicle security monitoring device comprises at least one motion detector.

43. The vehicle of claim 35, wherein the at least one vehicle security monitoring device comprises at least one temperature sensor.

44. The vehicle of claim 35, wherein the stored, machine-interpretable instructions are adapted to cause the at least one data processor to route to at least one exceptional vehicle operation response controller an vehicle operating exception data set comprising data representing the exceptional vehicle operating condition.

45. The vehicle of claim 35, wherein the stored, machine-interpretable instructions are adapted to cause the at least one processor, in response to receipt by the at least one data communication system of at least one vehicle corrective action command data set, to generate a vehicle system corrective action command data set and route the at least one vehicle system corrective action command data set to the at least one navigation controller.

46. The vehicle of claim 45, wherein the vehicle corrective action command data set comprises data representing an emergency response location and the at least one vehicle system corrective action data set comprises data representing instructions configured to cause the at least one navigation controller to navigate the vehicle to the emergency response location.

47. The vehicle of claim 45, wherein the at least one data processor causes the vehicle access controller to place at least one vehicle access portal into an openable state when the vehicle is not in motion.

48. The vehicle of claim 30, comprising a wireless proximity communication device adapted to receive the user access request data set from a vehicle request control device of a vehicle user.

49. The vehicle of claim 30, comprising at least one local operator input device adapted for use by a user of the vehicle to generate the user access request data set.

50. A vehicle request control device, comprising:

at least one input device;

at least one wireless data communication system; and

at least one data processor communicatively linked to the at least one input device and the at least one data communication system;

at least one persistent memory device accessible by the at least one data processor, the at least one persistent memory device comprising stored data representing machine-interpretable instructions adapted to cause the at least one data processor to:

in accordance with one or more command signals received from the at least one input device, generate at least one vehicle request data set, the at least one vehicle request data set comprising data representing at least a pickup location and a requested service type;

using the at least one wireless data communication system, route the at least one vehicle request data set to an autonomously operable vehicle controller.

51. The vehicle request control device of claim 50, wherein the machine- interpretable instructions are adapted to cause the at least one data processor to: access a vehicle access authorization data set, and

using the at least one proximity communication system, route the vehicle access authorization data set to the same or another autonomously operable vehicle controller.

52. The vehicle request control device of claim 50, wherein the machine- interpretable instructions are adapted to cause the at least one data processor to: in accordance with one or more command signals received from the at least one input device, generate at least one vehicle navigation control data set, the at least one vehicle navigation control data set comprising data representing at least a vehicle routing instruction, and using the at least one data communication system, route the vehicle navigation control data set to the same or another autonomously operable vehicle controller.

53. The vehicle request control device of claim 50, wherein the machine- interpretable instructions are adapted to cause the at least one data processor to: in accordance with one or more command signals received from the at least one input device, generate at least one vehicle environmental control data set, the at least one vehicle request data set comprising data representing at least one vehicle environmental control command signal, and

using the at least one data communication system, route the vehicle environmental control data set to the same or another autonomously operable vehicle controller.