Method and apparatus for carpooling using spatial awareness

Abstract

The present disclosure provides "methods and apparatus for ride sharing using spatial awareness". A system includes a processor configured to receive a vehicle request, the vehicle request including a physical parameter of a requesting rider. The processor is further configured to send a request including the physical parameter to a ride service. The processor is further configured to receive, in response to the request, an identification of a vehicle based on the physical parameter, the vehicle having sufficient space to accommodate the requesting rider. Further, the processor is configured to receive a confirmation of the vehicle from the requesting rider, and request use of the vehicle in response to the confirmation.

Description

Technical Field

[0001] The illustrative embodiments generally relate to methods and apparatus for carpooling planning using spatial awareness. Background Technology

[0002] People come in all shapes and sizes, which can sometimes cause difficulties in situations where seating is shared, such as on buses, trains, and airplanes. With the increasing use of ride-sharing concepts (such as car-sharing and ride-hailing), this can create potential new problems in even more confined spaces, as most vehicle interiors are far less spacious than public transport options. Moreover, seats are not always clearly described, for example, as they are on airplanes, so two or three people attempting to ride together, who may both require ample space, might find themselves in an uncomfortable or even impossible situation. This can lead to embarrassment and lost fares for the driver, and often may even deter some from using any service other than a ride-hailing service. Even in those cases, if a six-foot-ten-inch person calls for a vehicle and the driver is driving a two-door compact car, it could result in discomfort and / or impossibility.

[0003] Most vehicle seats can be adjusted in some way, and in the future, driverless vehicles may include even more dynamically reconfigurable seats. But even if seats can be adjusted, there are currently few, if any, adaptations to address the potential inadequacy of trying to share a seat with tall or other large occupants who are already partially occupied. Summary of the Invention

[0004] In a first illustrative embodiment, a system includes a processor configured to receive a vehicle request, the vehicle request including physical parameters of a requesting occupant. The processor is also configured to send a request including the physical parameters to a ride-hailing service. The processor is further configured to, in response to the request, receive an identifier of a vehicle based on the physical parameters, the vehicle having sufficient space to accommodate the requesting occupant. Furthermore, the processor is configured to receive confirmation of the vehicle from the requesting occupant; and to use the vehicle in response to the confirmation request.

[0005] In a second illustrative embodiment, a system includes a processor configured to receive a vehicle request, the vehicle request including physical parameters of a requested occupant. The processor is further configured to determine, based on the physical parameters, a vehicle with sufficient available occupancy to accommodate the requested occupant; and to respond to the request by identifying the determined vehicle as an available vehicle.

[0006] In a third illustrative embodiment, a system includes a processor configured to determine that a vehicle is preparing to receive a passenger requesting the vehicle as a ride. The processor is also configured to determine a seat pre-assigned to be occupied by the occupant and provide visual guidance within the vehicle interior to identify the determined seat. Attached Figure Description

[0007] Figure 1 An illustrative vehicle computing system is shown;

[0008] Figure 2 An illustrative process for ride-hailing with spatial awareness is shown;

[0009] Figure 3 The process of selecting illustrative ride options with spatial awareness is shown;

[0010] Figure 4 An illustrative seating assistance process is shown;

[0011] Figure 5 Another illustrative ride selection process is shown;

[0012] Figure 6 This illustrates the ride request queue processing procedure; and

[0013] Figure 7 An illustrative driver / vehicle assignment process is shown. Detailed Implementation

[0014] Detailed embodiments are disclosed herein as needed; however, it is to be understood that the disclosed embodiments are merely illustrative and may be incorporated in various forms and alternatives. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show detail of specific components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art to employ the claimed subject matter in different ways.

[0015] Figure 1 An example block topology of a vehicle-based computing system 1 (VCS) for vehicle 31 is shown. This example of a vehicle-based computing system 1 is the SYNC system manufactured by The Ford Motor Company. Vehicles with a vehicle-based computing system enabled may include a visual front-end interface 4 located within the vehicle. If the interface is equipped with, for example, a touchscreen display, a user can also interact with the interface. In another illustrative embodiment, interaction is achieved via button presses, a spoken dialogue system with automatic speech recognition, and speech synthesis.

[0016] exist Figure 1In the illustrated embodiment 1, processor 3 controls at least some parts of the operation of the vehicle-based computing system. The processor, located within the vehicle, allows for on-vehicle processing of commands and programs. Furthermore, the processor is connected to non-persistent storage device 5 and persistent storage device 7. In this illustrative embodiment, the non-persistent storage device is random access memory (RAM), and the persistent storage device is a hard disk drive (HDD) or flash memory. Generally, persistent (non-transitory) memory can include all forms of memory that maintain data when the computer or other device is powered off. These memories include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any other suitable form of persistent memory.

[0017] The processor also features a number of different inputs that allow the user to interact with it. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which may be a touchscreen display), and a Bluetooth input 15 are provided. An input selector 51 is also provided to allow the user to switch between the various inputs. The microphone and auxiliary connector inputs are converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, many vehicle components and auxiliary components communicating with the VCS may use vehicle networks (such as, but not limited to, CAN bus) to exchange data with the VCS (or its components).

[0018] The system output may include, but is not limited to, the visual display 4 and the speaker 13 or stereo system output. The speaker is connected to the amplifier 11 and receives the signal from the amplifier 11 from the processor 3 via the digital-to-analog converter 9. The output may also be transmitted to a remote Bluetooth device such as the PND 54 or a USB device such as the vehicle navigation device 60 along bidirectional data streams shown at 19 and 21 respectively.

[0019] In one illustrative embodiment, system 1 uses a Bluetooth transceiver 15 to communicate 17 with a user's roaming device 53 (e.g., a cellular phone, smartphone, PDA, or any other device with wireless remote network connectivity). The roaming device (hereinafter referred to as ND) 53 can then be used to communicate 59 with a network 61 outside vehicle 31 via, for example, communication with a cellular tower 57. In some embodiments, the tower 57 may be a Wi-Fi access point.

[0020] Exemplary communication between ND 53 and Bluetooth transceiver 15 is represented by signal 14.

[0021] Pairing ND 53 and Bluetooth transceiver 15 can be indicated via button 52 or similar input. This instructs the CPU to pair the vehicle-mounted Bluetooth transceiver with the Bluetooth transceiver in the roaming device.

[0022] Data can be transmitted between CPU 3 and network 61 using, for example, data plans, audio data, or DTMF tones associated with ND 53. Alternatively, it may be desirable to include an onboard modem 63 with antenna 18 to transmit 16 data between CPU 3 and network 61 via voice bands. ND 53 can then be used to communicate 59 with network 61 outside vehicle 31 via, for example, communication 55 with cellular tower 57. In some embodiments, modem 63 may establish communication 20 with tower 57 to communicate with network 61. As a non-limiting example, modem 63 may be a USB cellular modem and communication 20 may be cellular communication.

[0023] In one illustrative embodiment, the processor is equipped with an operating system that includes APIs for communicating with modem application software. The modem application software can access embedded modules or firmware on the Bluetooth transceiver to enable wireless communication with remote Bluetooth transceivers, such as those present in roaming devices. Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. The IEEE 802 LAN (Local Area Network) protocol includes Wi-Fi and has considerable overlap with IEEE 802 PAN. Both are suitable for wireless communication within vehicles. Another communication method that can be used in this field is free-space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0024] In another embodiment, ND 53 includes a modem for voiceband or broadband data communication. In the voiceband data embodiment, a technique called frequency division multiplexing is implemented when the owner of the roaming device is able to talk through the device while data is being transmitted. At other times, when the owner is not using the device, data transmission can use the entire bandwidth (300 Hz to 3.4 kHz in one example). While frequency division multiplexing may be common for and still in use for analog cellular communication between a vehicle and the Internet, it has been largely replaced by a hybrid of code domain multiple access (CDMA), time domain multiple access (TDMA), and spatial domain multiple access (SDMA) for digital cellular communication. If the user has a data plan associated with the roaming device, the data plan may allow for broadband transmission, and the system can use a wider bandwidth (accelerating data transmission). In yet another embodiment, ND 53 is replaced by a cellular communication device (not shown) installed in vehicle 31. In yet another embodiment, ND 53 may be a wireless local area network (LAN) device capable of communicating over, for example (but not limited to), an 802.11g network (i.e., Wi-Fi) or a Wi-Max network.

[0025] In one embodiment, incoming data may be transmitted via audio data or data schedule through a roaming device, via an in-vehicle Bluetooth transceiver, and into the vehicle's internal processor 3. For example, for some temporary data, the data may be stored on an HDD or other storage medium 7 until the data is no longer needed.

[0026] Additional sources that can interact with the vehicle include a personal navigation device 54 with, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 with a USB 62 or other connection, an in-vehicle GPS device 24, or a remote navigation system (not shown) with a connection to a network 61. USB is one of the serial networking protocols. IEEE 1394 (FireWire) TM (Apple), iLINK TM (Sony) and Lynx TM The Texas Instruments (TI) serial protocol, EIA (Electronic Industries Association) serial protocol, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of inter-device serial standards. Most protocols can be implemented for electrical or optical communications.

[0027] In addition, the CPU can communicate with various other auxiliary devices 65. These devices can be connected wirelessly 67 or via wired connection 69. Auxiliary devices 65 may include, but are not limited to, personal media players, wireless health devices, portable computers, etc.

[0028] Alternatively, the CPU can connect to the vehicle-based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) transceiver 71. This allows the CPU to connect to a remote network within the range of the local router 73.

[0029] In addition to the exemplary process being performed by a vehicle computing system located within the vehicle, in some embodiments, the exemplary process may also be performed by a computing system communicating with the vehicle computing system. Such systems may include, but are not limited to, wireless devices (e.g., but not limited to, mobile phones) or remote computing systems (e.g., but not limited to, servers) connected via wireless devices. Such systems may be collectively referred to as Vehicle-Associated Computing Systems (VACS). In some embodiments, specific components of the VACS may perform specific portions of the process depending on the specific implementation of the system. As an example and not a limitation, if a process has steps involving sending or receiving information with a paired wireless device, it is likely that the wireless device is not performing said portion of the process because the wireless device does not "send and receive" information with itself. Those skilled in the art will understand when it is inappropriate to apply a particular computing system to a given solution.

[0030] In each of the illustrative embodiments discussed herein, exemplary, non-limiting examples of processes that can be executed by a computing system are shown. For each process, the computing system executing the process may be configured as a dedicated processor for the limited purpose of executing the process. Not all processes need to be executed, and are understood as examples of process types executable to implement elements of the invention. Additional steps may be added or removed from the exemplary processes as needed.

[0031] Regarding the illustrative embodiments shown in the accompanying drawings illustrating illustrative process flows, it should be noted that a general-purpose processor may be temporarily enabled as a dedicated processor in order to perform some or all of the exemplary methods shown in these drawings. When code providing instructions to perform some or all of the steps in the method is executed, the processor may be temporarily reused as a dedicated processor until the method completes. In another example, to an appropriate extent, firmware pre-configured to function as a processor may cause the processor to act as a dedicated processor for performing the method or some reasonable variations thereof.

[0032] Autonomous vehicles that do not necessarily require driver control or even forward-facing seats may include significantly reconfigurable vehicle seating, which in some configurations may resemble a small living room. Regardless of whether the seats face forward, inward, or otherwise, the seats may be modular, foldable, movable, and / or reconfigurable to some extent within the cabin's interior space.

[0033] Additionally, advanced user profiles are already capable of measuring and storing physical individual preferences and parameters. The retrieval and use of these features, as well as feature collection, are discussed in co-owned and co-pending application U.S. Serial No. 15 / 015,559, which is incorporated herein by reference in its entirety.

[0034] As automated ride-hailing opportunities increase and become more popular, people may become more comfortable sharing rides with strangers. In some cases, this may be the only available option if service vehicles are limited. Furthermore, as vehicles become more generally autonomous (AV), vehicle usage can be based on booking, and certain lower-priced options may require ride-sharing. To fully utilize vehicles without losing an entire class of potential customers, it would be useful for these vehicles to be dispatched and / or reconfigured to accommodate users of various body sizes. Therefore, illustrative embodiments provide spatial awareness aspects of ride-hailing and AV utilization scenarios.

[0035] Figure 2This illustrates a spatially aware ride-hailing process. For example, the process runs on the user's mobile device, allowing them to observe and select possible seating configuration options from a variety of available vehicles. The user can also specify whether space or immediacy is a priority, as they may be willing to experience temporary discomfort for all or part of the journey in order to secure a ride more quickly.

[0036] In this illustrative example, the process uses a 201 user profile (which may be on the device or accessed from a remote account) to include the user's physical preferences, parameters, and constraints in the vehicle request. By passing these parameters to the planning process, the planning process can utilize the specified parameters to optimally manage individual user preferences and available vehicle space to maximize or optimize traveler services.

[0037] If the request returns an indication of a comfortable 205 or a possible 207 vehicle, the local process can display a wireframe, image, or even a 3D model of the vehicle's interior, showing the current occupancy and where the user will sit. For example, the model could even approximate the available space for the user inside the vehicle, in terms of possible legroom and elbow room. A "comfortable" vehicle could be perfectly adapted to any user's physical parameters and preferences, while a "possible" vehicle could be available but potentially uncomfortable.

[0038] If there is neither a comfortable nor even a possible current vehicle, the process can queue the request 209 for future fulfillment; for example, if only an uncomfortable option exists, the user is allowed to wait for a "better" option. If the user approves 213 a possible vehicle, the process can send a request to the specific vehicle approved by the user.

[0039] Many current ride-hailing systems rely on users' willingness to use certain types of vehicles, but do not specifically assign vehicles to certain users unless those are the only vehicles available in an area. These models can be adapted to spatial awareness models and / or user acceptance models, where the driver must agree to the fare and the user must accept the vehicle. In AV models without driver-agreement on the fare, one of the variables is removed, and some models may also present an "accept or leave" format, where a comfortable or available vehicle is "automatically" accepted based on minimum constraints that meet certain occupant parameters (e.g., if the occupant is four feet three inches tall, the person must accept a vehicle that can accommodate them, rather than waiting for a half-empty large SUV).

[0040] Figure 3An illustrative process for selecting ride options with spatial awareness is shown. In this example, the process runs on a dispatch server (or multiple servers) or other centralized system capable of receiving and evaluating passenger and vehicle parameters. In some examples, the central server may simply receive and broadcast the available parameters for each vehicle, allowing individual devices to determine whether a given vehicle is suitable.

[0041] In this process, the centralized system receives a request for a vehicle, which in this example also includes parameters for one or more expected occupants. If a vehicle is requested on behalf of multiple occupants, the request process may require the user to specify the number of occupants. The user can also specify an identifier for a profile, allowing the application to retrieve the profile from a server or through communication with individual devices storing profiles of expected passengers.

[0042] The central dispatching process can keep track of current and / or expected vehicle occupancy configurations (for dispatch vehicles that are not yet fully occupied). Therefore, the system can remain aware of available empty space and / or seat reconfiguration options, and upon receiving occupancy parameters, the system can model possible open vehicles in appropriate locations with sufficient space. If seat changes and / or reconfigurations are required to accommodate passengers, the system can also send requests to change seats (when it is safe to do so), and / or may send requests for seat reconfiguration (which may require emptying the vehicle, depending on the form of reconfiguration).

[0043] If the process is able to locate a “comfortable” 305 and / or a “possible” 307 vehicle or group of vehicles, the process may return the identified vehicles at 311, along with any parameters required if the local device will perform visual modeling. If the process performs modeling or image rendering (so that the user can see the proposed configuration), the process may return the completed model and / or image. If one of the proposed vehicles at 313 is selected, the process may notify 315 of any movement or changes required to accommodate the new passenger. If no vehicle is selected or is available for selection, the process may queue the request at 309 for later processing.

[0044] Figure 4 An illustrative seating assistance process is shown. In this example, the process reconfigures and / or guides a specific user to a seat. In this example, the process uses lighting to guide the user to a given seat and may use multiple colors, for example, to guide multiple occupants to seats (e.g., different colors are presented on each occupant unit or next to the occupant's name on a single unit to indicate the intended seat). If reconfiguration is required, the process may request the vehicle to be emptied or passengers to be moved to accommodate the reconfiguration.

[0045] In this example, the process determines whether 401 is about to arrive at the new occupant's location. If it is, the process can also determine whether the seat 403, intended for the new occupant, is currently occupied. If the seat is occupied, the process can alert the person currently seated that their seat has been assigned to another person.

[0046] Since it may not be necessary to physically remove the user from their seat (if it is not possible), the illustrative embodiment utilizes a profile update process, which could, for example, lower a user's rating if they do not vacate their seat. Depending on the implementation, a lower rating could reduce vehicle availability or even prevent use for a period of time. Fines may also be applicable, so in this example, after the process alerts occupant 405, the process could update user 407's profile based on whether the occupant moved their seat as requested. In some cases, a user may be allowed to occupy any seat until requested to move, thus generating a negative profile only if the user fails to change their seat in a timely manner.

[0047] If the intended user seat is unoccupied or vacant, the process may illuminate seat 409 and / or the path to the seat. As mentioned above, various colored lights may be used for illumination to identify the appropriate seat for each occupant. One or more occupant devices may also display appropriate colors accordingly. Upon arrival at the destination, the process may also open door 411 corresponding to the intended seat or multiple doors.

[0048] Figure 5 Another illustrative ride selection process is shown. This process allows the system to choose between a reconfigurable vehicle and a standard vehicle. In this example, because the standard vehicle has a fixed configuration, it can be initially "reserved" to facilitate task assignment to the reconfigurable vehicle, since the fixed-configuration vehicle may necessarily only be suited to certain physical characteristics. Of course, the exact opposite reasoning can be applied, and the reverse process can also be used, depending on the chosen implementation.

[0049] Here, the process receives 501 a request including physical characteristics corresponding to "atypical" features (based on predefined criteria). For example, if most vehicles can accommodate passengers 6 feet or smaller, and the user is 6 feet 5 inches, this might be considered an "atypical" feature. In this example, if any reconfigurable vehicle is available 503, the process will select 507 the reconfigurable option and adjust the vehicle to accommodate the user. Otherwise, the process will find 505 a suitable or available standard fixed-configuration vehicle for use.

[0050] In another model, the implementer can decide that it is best to retain reconfigurable vehicles for the worst-case scenario and can use all available standard vehicles first before requesting reconfigurable vehicles, which is essentially the opposite model.

[0051] Figure 6 An illustrative ride request queuing process is illustrated. This process occurs when a centralized system and a local mobile device system queue a request because it cannot be processed (or for other reasons). Since the local user may have cancelled the request, the process receives the request 601 from the central queue and attempts to check 603 the local device to ensure the request is still pending 605. Because the local user may have found another ride or otherwise cancelled the request, but the device may not have notified the remote queue, the process checks whether the request is still pending on the mobile device before processing it. This helps avoid inappropriately dispatching a vehicle to a party that no longer needs it. If the request is still pending, the system processes 607 the request.

[0052] Figure 7 This illustrates an illustrative driver / vehicle assignment process. It is an example of how vehicle spatial awareness adaptation can be used to allocate vehicle resources across various geographic areas. People in certain locations may have different physical characteristics than the general public, and people attending certain events may also have different physical characteristics. Over time, or using other known demographic data, these characteristics can be better adapted by assigning vehicles based on anticipated passenger types. For example, if a wheelchair trade show is underway and a large number of attendees are expected, a larger fleet of vehicles capable of accommodating wheelchairs than the standard fleet could be deployed to patrol the area around the show.

[0053] Certain sports fans, music lovers, food enthusiasts, and other potential occupants may possess observable physical demographic characteristics, and because vehicles can be adapted to these characteristics, the system can not only dispatch a sufficient number of vehicles to serve the event or demand, but also actually dispatch vehicles with appropriate adaptability. This can be as simple as, as illustrated in the previous example, dispatching a large number of multi-passenger vehicles intended for group participation in an event to dedicated vehicles.

[0054] In this example, the process obtains utilization data (701) corresponding to a specific event, event type, geographic area, etc. The process, which tracks used and unused occupied space, determines (703) the available unused occupancy for a given time period. The process can also obtain metrics on unavailable space, which will be physical user demands that existing vehicle infrastructure cannot accommodate or cannot immediately adapt to. The collected data can then be used to reconfigure the model of the event or area, so that if the central system manages demand and supply by strategically dispatching vehicles to patrol certain areas, the model should better reflect the short-term or long-term needs of the population.

[0055] The illustrative embodiments allow for the provision of ride-hailing and AV (Audience Travel) services that are adaptable to the physical characteristics of requesting users. This can lead to increased carpooling and improved space utilization, as well as creating additional sharing opportunities for people who may not be served by existing solutions.

[0056] While exemplary embodiments have been described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the terminology used herein is descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the invention. Furthermore, features of various implementation embodiments may be logically combined to produce suitable variations of the embodiments described herein, depending on the circumstances.

[0057] According to the present invention, a system is provided having a processor configured to receive a vehicle request including physical parameters of a requesting passenger; in response to the request, send a request including the physical parameters to a ride-hailing service; receive an identifier of a vehicle based on the physical parameters, the vehicle having sufficient space to accommodate the requesting passenger; receive confirmation of the vehicle from the requesting passenger; and in response to the confirmation request, use the vehicle.

[0058] According to one embodiment, the physical parameters include occupant height.

[0059] According to one embodiment, the physical parameters include occupant weight.

[0060] According to one embodiment, the physical parameters include occupant limb length.

[0061] According to one embodiment, the processor is configured to display a view of the vehicle interior in response to receiving an identification of the vehicle.

[0062] According to one embodiment, the view includes other current occupants at locations identified by the received vehicle identification.

[0063] According to one embodiment, the processor is configured to display a view of the vehicle interior, including a model of the requesting occupant, in response to receiving an identification of the vehicle.

[0064] According to one embodiment, the view is a two-dimensional view.

[0065] According to one embodiment, the view is a three-dimensional view.

[0066] According to the present invention, a system is provided having a processor configured to receive a vehicle request, the vehicle request including physical parameters of a requested occupant; determine, based on the physical parameters, a vehicle with sufficient available occupancy to accommodate the requested occupant; and respond to the request by identifying the determined vehicle as an available vehicle.

[0067] According to one embodiment, the processor is configured to determine the vehicle based on reports indicating current occupancy received from a plurality of possible vehicles.

[0068] According to one embodiment, the processor is configured to determine the vehicle based on reports received from a plurality of possible vehicles indicating the current occupant seating positions.

[0069] According to one embodiment, the physical parameters include occupant height.

[0070] According to one embodiment, the physical parameters include occupant weight.

[0071] According to one embodiment, the physical parameters include occupant limb length.

[0072] According to one embodiment, the processor is configured to determine that a change in occupant seating would allow a possible vehicle to adapt to the physical characteristics of the requesting occupant and to send a request for the seating change to the possible vehicle.

[0073] According to one embodiment, the request includes a request to change the seat of an occupant.

[0074] According to one embodiment, the request includes a request to reconfigure the reconfigurable seats in the vehicle.

[0075] According to one embodiment, the processor is configured to determine a first vehicle adequately suited to the physical parameters based on predefined comfort parameters and a second vehicle adequately suited to the physical parameters based on predefined probability parameters, the probability parameters being more suited to a tighter occupant load than the comfort parameters.

[0076] According to the present invention, a system is provided having a processor configured to determine that a vehicle is ready to receive a passenger requesting the vehicle as a ride, determine a seat pre-designated for occupancy by the passenger, and provide a visual guide to the interior of the vehicle for identifying the determined seat.

Claims

1. A system for carpooling planning using spatial awareness, comprising: Processor, the processor being configured to: Receive a vehicle request, the vehicle request including the physical parameters of the requesting passenger, the vehicle request requesting the ride-hailing service to dispatch a vehicle to pick up the requesting passenger; In response to the vehicle request, a vehicle available to serve the vehicle request is identified from a plurality of vehicles. The identification is based on a comparison of the current occupancy of a given vehicle among the plurality of vehicles and a known vehicle space characteristic of the given vehicle compared with the physical parameters, such that the identified vehicle has sufficient space to accommodate the requesting occupant in at least one seat that would become available through occupant movement. Send information about the vehicle identified by the identifier to the requesting occupant; Receive confirmation of the identified vehicle from the requesting occupant; as well as In response to the confirmation, the identified vehicle is instructed to carry the requested occupant.

2. The system as claimed in claim 1, wherein, The physical parameters include occupant height.

3. The system as described in claim 1, wherein, The physical parameters include passenger weight.

4. The system as claimed in claim 1, wherein, The physical parameters include occupant limb length.

5. The system as claimed in claim 1, wherein, The processor is configured to send a view of the vehicle's interior in response to receiving the vehicle's identifier.

6. The system of claim 5, wherein, The view includes other current occupants at locations identified by the vehicle's identification received.

7. The system as claimed in claim 1, wherein, The processor is configured to send a view of the vehicle interior, including a model of the requesting occupant, in response to receiving an identifier of the vehicle.

8. The system of claim 7, wherein, The view is a two-dimensional view.

9. The system of claim 7, wherein, The view is a three-dimensional view.

10. A system for carpooling planning using spatial awareness, comprising: Processor, the processor being configured to: Receive a vehicle request, the vehicle request including the physical parameters of the requested occupants; Based on the physical parameters compared with the available seat options in each of the plurality of vehicles determined according to the current occupancy of each of the plurality of vehicles, a vehicle with sufficient available occupancy to accommodate the requesting occupant is determined from the plurality of vehicles. The determination is further based on vehicle space parameters for determining whether at least one of the occupied and unoccupied seats is adapted to the physical parameters, such that the identified vehicle has sufficient space to accommodate the requesting occupant in at least one seat that would become available by occupant movement. as well as The request is responded to by identifying the determined vehicle as an available vehicle.

11. The system of claim 10, wherein, The processor is configured to determine the current occupancy of each of the plurality of vehicles based on reports indicating current occupancy received from a plurality of possible vehicles.

12. The system of claim 10, wherein, The processor is also configured to determine the vehicle based on reports received from multiple possible vehicles indicating the current occupant seating positions.

13. The system of claim 10, wherein, The physical parameters include occupant height.

14. The system of claim 10, wherein, The physical parameters include the weight of the occupants.

15. The system of claim 10, wherein, The physical parameters include occupant limb length.

Images