SAFETY INTEGRATED SHARED VEHICLE SYSTEM AND METHODS

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings that form a part of this document: Copyright ©2019-2020 Wheels Inc. All Rights Reserved.

Personal Mobility Vehicle” filed on Oct. 3, 2019 (Attorney Docket No. 5148.013PRV), which is hereby incorporated by reference herein in its entirety.

BACKGROUND

The shared vehicle ecosystem has moved from a nascent set of startup companies to a vibrant industry with a number of companies in a large number of markets, each company specializing in short distance rentals of bicycles and powered scooters. The industry has also experienced growing pains in the areas of safety. There have been a number of highly publicized accidents, injuries and deaths of subscribers to these services. Several safety measures have been fielded including rental of safety devices (e.g. traditional bicycle helmets rented or various disposable helmet types). In each case, these half measures have left much to be desired in the areas of helmet sanitation, item loss/theft and validation that the safety device is being used and were ultimately unsuccessful commercially. Additionally, there has been no methodology attached to the shared ride systems deployed that will actively create a safer ride for the rider. In all previous cases, the safety device is not in communication with the shared vehicle, not integrated to the deployment or recovery of the safety device before and after the shared vehicle rental. Additionally, each shared vehicle is not in active communication with the shared ride provisioning system to monitor rides and riders for safety related behaviors. Additionally, all of the previous safety devices also rely heavily on a direct human involvement (helmet rental/recovery by a human) (sanitation and restocking by a human) and there was virtually no ability to prevent a rider from ignoring the use of a safety device.

SUMMARY

The present inventors have recognized, among other things, that a problem to be solved can include minimizing the labor involved in deploying safety devices with a shared ride system. Another aspect of the problem solved is the integration of safety system, sensors and user safety devices into the actual design of the personal mobility vehicle. Another aspect of the problem solved is the ongoing upkeep and maintenance of personal mobility vehicles (shared vehicles) by web enabled servicing of the invention. A third aspect of the problem solved is the integration of service items with the integral safety sensors and interconnects in the described solution. A fourth aspect of the problem solved is the closed loop monitoring of safety protocols from sensors in the personal mobility vehicle components, the safety equipment worn by the user, mobile devices of the user, and the vehicle management/servicing protocols.

The present subject matter provides a solution to these problems, such as by using integrally designed safety devices associated or integrated with a personal mobility vehicle that a) are deployed within the shared vehicle, b) are communicatively coupled to the vehicle, c) coupled to the system as a whole, which is in constant communication between the vehicle, the shared vehicle management system, and the various safety devices, thereby integrating safety and serviceability in the design of the shared vehicle. that interacts with the user who is using the various safety checks during a ride, d) the retrieval of any deployed user safety devices, and e) the verified sanitation of any deployed user safety devices, and f) the reset of any user safety device to be ready for the next user. By accomplishing these integrations, the present solution comprises a number of aspects where the solution can jointly validate a user to use the personal mobility vehicle, deploy the personal mobility vehicle, manage the deployment of a wearable user safety devices at the time of rental, validate the use of the helmet, monitor the use of a helmet by a shared vehicle renter during the rental, monitor the personal mobility vehicle during the rental, and the retrieval and sanitization of the helmet without the intervention of a servicing personnel allowing the immediate redeployment of the shared vehicle with the same wearable safety device, as well as detecting whether a user is safely using the shared vehicle. The present solution can additionally monitor the safety state of a user during a ride by use of additional sensors on the personal mobility vehicle.

Each of these non-limiting examples can stand on its own or can be combined in various permutations or combinations with one or more of the other examples.

This overview is intended to provide an overview of subject matter of the present patent application. It is not intended to provide an exclusive or exhaustive explanation of the invention. The detailed description is included to provide further information about the present patent application.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

FIG. 1 is a diagrammatic representation of a networked environment in which the present disclosure may be deployed, in accordance with some example embodiments.

FIG. 2 is a diagrammatic representation of a processing environment, in accordance with some example embodiments.

FIG. 3 is block diagram showing a software architecture within which the present disclosure may be implemented, according to an example embodiment,

FIG. 4 is a diagrammatic representation of a machine in the form of a computer system within which a set of instructions may be executed for causing the machine to perform any one or more of the methodologies discussed herein, in accordance with some example embodiments.

FIG. 5 illustrates a SIPV system and its functional architecture in accordance with one embodiment.

FIG. 6 illustrates a Meshed SIPV Network in accordance with one embodiment.

FIG. 7 is an example of a safety integrated electric vehicle disclosed herein;

FIG. 8 is a cutaway of the safety integrated electric vehicle disclosed herein, showing the user control interfaces;

FIG. 9 is a cutaway of the safety integrated electric vehicle disclosed herein, showing mechanical and system components;

FIG. 10 is a cutaway of the safety integrated electric vehicle disclosed herein, showing helmet and system interactions as well as other vehicle components;

FIG. 11 is a cutaway of the safety integrated electric vehicle disclosed herein, showing electronic and sensor safety features;

FIG. 12 illustrates a Deployable Safety Device Assembly in accordance with one embodiment;

FIG. 13 illustrates an Initiation of SIPV ride in accordance with one embodiment; and

FIG. 14 illustrates a safety process during SIPV rental in accordance with one embodiment.

DETAILED DESCRIPTION
System Level Description:

The example used in this description is intended as a median example of the solution proposed, rather than an exhaustive example of every permutation of this proposed solution. It can be appreciated that the recombination of the various aspects of this solution may result in many permutations.

FIG. 1 is a diagrammatic representation of a SIPV networked computing environment 100 in which some example variations of the present solution may be implemented or deployed.

One or more SIPV system application servers 104 provide server-side functionality via a network 102 to a networked user device, in the form of a user client device 106 that is accessed by a SIPV user 128. A web client 110 (e.g., a browser) and a programmatic client 108 (e.g., an “app”) are hosted and execute on the web client 110 to allow the SIPV user 128 to purchase a SIPV 700 ride.

An Application Program Interface (API) server 118 and a web server 120 provide respective programmatic and web interfaces to SIPV system application servers 104. A specific application server 116 hosts a SIPV System Code 122, which includes components, modules and/or applications as discussed earlier.

The web client 110 communicates with the SIPV System Code 122 via the web interface supported by the web server 120. Similarly, the programmatic client 108 communicates with the SIPV System Code 122 via the programmatic interface provided by the Application Program Interface (API) server 118. The third-party application 114 may, for example, be a Google Maps, Paypal or other commonly used apps to assist the SIPV user 128 in their purchase.

The application server 116 is shown to be communicatively coupled to database servers 124 that facilitates access to an information storage repository or databases 126. In an example embodiment, the databases 126 includes storage devices that store information to be published and/or processed by the SIPV System Code 122. (e.g. Rider data, prior use history and other data that assists the execution of the SIPV 700 experience.

Additionally, a third-party application 114 executing on a third-party server 112, is shown as having programmatic access to the application server 116 via the programmatic interface provided by the Application Program Interface (API) server 118. For example, the third-party application 114, using information retrieved from the application server 116, may support one or more features or functions on a website hosted by the third party. (e.g., SIPV user 128 present location, credit check, credit card transactions)

Turning now to FIG. 2, a diagrammatic representation of a the SIPV processing environment 200 is shown, which includes the onboard computer 808 further comprising Communication Processor 206, the Power Management Power Processor 208, and a Main Processor 202 (e.g., a GPU, CPU or combination thereof).

The Main Processor 202 is shown to be coupled to a power source 204, and to include (either permanently configured or temporarily instantiated) modules, namely a Safety component 210, a Monitoring component 212, and an Operations component 214. The Safety component 210 operationally generates all safety related interconnections between the SIPV 700 and its SIPV sensors 508, the Monitoring component 212 operationally generates all other monitoring tasks including monitoring commands or requests from the SIPV system 500 or requests from the present user devices, and the Operations component 214 operationally generates all basic functions and operations of the SIPV not related to maintaining safety or monitoring tasks, this comprises additional tasks like maintenance, system or sensor availability as well as alerting to the other processors as the Operations component 214 detects a new or projected servicing condition. As illustrated, the Main Processor 202 is communicatively coupled to both the Communication Processor 206 and Power Processor 208, and receives all external SIPV 700 communications/requests from the Communication Processor 206, as well as power status, power source status and charge condition from the Power Processor 208.

FIG. 3 is a general SIPV 700 block diagram 300 illustrating a software architecture 304, which can be installed on any one or more of the devices described herein. The software architecture 304 is supported by hardware such as a machine 302 that includes processors 320, memory 326, and I/O components 338. In this example, the software architecture 304 can be conceptualized as a stack of layers, where each layer provides a particular functionality. The software architecture 304 includes layers such as an operating system 312, libraries 310, frameworks 308, and SIPV applications 306. Operationally, the SIPV applications 306 invoke API calls 350 through the software stack and receive messages 352 in response to the API calls 350.

The operating system 312 manages hardware resources and provides common services. The operating system 312 includes, for example, a kernel 314, services 316, and drivers 322. The kernel 314 acts as an abstraction layer between the hardware and the other software layers. For example, the kernel 314 provides memory management, Processor management (e.g., task scheduling), component management, networking, and security settings, among other functionality. The services 316 can provide other common services for the other software layers. The drivers 322 are responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 322 can include display drivers, camera drivers, BLUETOOTH® or BLUETOOTH® Low Energy drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), WI-FI® drivers, audio drivers, power management drivers, and so forth.

The libraries 310 provide a low-level common infrastructure used by the SIPV applications 306. The libraries 310 can include system libraries 318 (e.g., C standard library) that provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries 310 can include API libraries 324 such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), graphics libraries (e.g., an OpenGL framework used to render in two dimensions (2D) and three dimensions (3D) in a graphic content on a display), database libraries (e.g., SQLite to provide various relational database functions), web libraries (e.g., WebKit to provide web browsing functionality), and the like. The libraries 310 can also include a wide variety of other libraries 328 to provide many other APIs to the SIPV applications 306.

The frameworks 308 provide a high-level common infrastructure that is used by the SIPV applications 306. For example, the frameworks 308 provide various graphical user interface (GUI) functions to the display, high-level resource management, and high-level location services. The frameworks 308 can provide a broad spectrum of other APIs that can be used by the SIPV applications 306, some of which may be specific to a particular operating system or platform.

In an example embodiment, the SIPV applications 306 used or integrated by the SIPV system 500 may include a rental application 336, a related services application 330 (accessing other services related to the SIPV 700 rental, a browser application 332, a user proximity application 334 an alerting function to suggest nearby points of interest, road hazards, or other alters proximate to the user's location, a GPS application 342, a media application 344, a SIPV messaging application 346, a camera application 348, and a broad assortment of other applications such as a third-party application 340 that would also service a related aspect of the present solution. The SIPV applications 306 are programs that execute functions defined in the programs and as listed throughout this description. Various programming languages can be employed to create one or more of the SIPV applications 306, structured in a variety of manners, such as object-oriented programming languages (e.g., Objective-C, Java, or C++) or procedural programming languages (e.g., C or assembly language). In a specific example, the third-party application 340 (e.g., an application developed using the ANDROID™ or IOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as IOS™, ANDROID™, WINDOWS® Phone, or another mobile operating system. In this example, the third-party application 340 can invoke the API calls 350 provided by the operating system 312 to facilitate functionality described herein.

FIG. 4 is a diagrammatic representation of the SIPV computing machine 400 within which instructions 410 (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the SIPV computing machine 400 to perform any one or more of the methodologies discussed herein may be executed. For example, the instructions 410 may cause the SIPV computing machine 400 to execute any one or more of the methods described herein. The instructions 410 transform the general, non-programmed SIPV computing machine 400 into a particular SIPV computing machine 400 programmed to carry out the described and illustrated functions and operations in the manner described. The SIPV computing machine 400 may operate as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the SIPV computing machine 400 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The SIPV computing machine 400 may comprise, but not be limited to, a server computer, a client computer, an onboard computer 808, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions 410, sequentially or otherwise, that specify actions to be taken by the SIPV computing machine 400. Further, while only a single SIPV computing machine 400 is illustrated, the term “machine” shall also be taken to include a collection of machines that individually or jointly execute the instructions 410 to perform any one or more of the methodologies discussed herein.

The SIPV computing machine 400 may include Processor 408, memory 406, and SIPV I/O components 402, which may be configured to communicate with each other via a bus 440. In an example embodiment, the Processor 408 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) Processor, a Complex Instruction Set Computing (CISC) Processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an ASIC, a Radio-Frequency Integrated Circuit (RFIC), another Processor, or any suitable combination thereof) may include, for example, a Processor 412 and a Processor 408) that execute the instructions 410. The term “Processor” is intended to include multi-core processors that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. Although FIG. 4 shows multiple Processor 408, the SIPV computing machine 400 may include a single Processor with a single core, a single Processor with multiple cores (e.g., a multi-core Processor), multiple processors with a single core, multiple processors with multiples cores, or any combination thereof.

The memory 406 includes a main memory 414, a static memory 416, and a storage unit 418, all accessible to the Processor 408 via the bus 440. The main memory 414, the static memory 416, and storage unit 418 store the instructions 410 embodying any one or more of the methodologies or functions described herein. The instructions 410 may also reside, completely or partially, within the main memory 414, within the static memory 416, within machine-readable medium 420 within the storage unit 418, within at least one of the processors 404 (e.g., within the Processor's cache memory), or any suitable combination thereof, during execution thereof by the SIPV computing machine 400.

The SIPV I/O components 402 may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific SIPV I/O components 402 that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones may include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the SIPV I/O components 402 may include many other components that are not shown in FIG. 4. In various example embodiments, the SIPV I/O components 402 may include output components 426 and input components 428. The output components 426 may include visual components (e.g., a display such as a display, a light emitting diode (LED) display light 728), acoustic components (e.g., speakers, alerts like horns or other SIPV sounds), haptic components (e.g., a vibratory motor, resistance mechanisms like brake 730 actions), other signal generators, and so forth. The input components 428 may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and/or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.

In further example embodiments, the SIPV I/O components 402 may include user biometric components 430, 3D motion components 432, sensed environmental components 434, or navigation position components 436, among a wide array of other components. For example, the biometric components 430 include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye-tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram-based identification), and the like. The 3D motion components 432 include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope). The sensed environmental components 434 include, for example, one or cameras, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermo-sensors that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detection concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The navigation position components 436 include location sensor components (e.g., a GPS receiver Component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.

Communication may be implemented using a wide variety of technologies. The SIPV I/O components 402 further include communication components 438 operable to couple the SIPV computing machine 400 to a network 422 or devices 424 via respective coupling or connections. For example, the communication components 438 may include a network interface Component or another suitable device to interface with the network 1422. In further examples, the communication components 438 may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), WiFi® components, and other communication components to provide communication via other modalities. The devices 424 may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

Moreover, the communication components 438 may detect identifiers or include components operable to detect identifiers. For example, the communication components 438 may include Radio Frequency Identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar code, multi-dimensional bar codes such as Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D bar code, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals). In addition, a variety of information may be derived via the communication components 438, such as location via Internet Protocol (IP) geolocation, location via Wi-Fi® signal triangulation, location via detecting an NFC beacon signal that may indicate a particular location, and so forth.

The various memories (e.g., main memory 414, static memory 416, and/or memory of the Processor 408) and/or storage unit 418 may store one or more sets of instructions and data structures (e.g., software) embodying or used by any one or more of the methodologies or functions described herein. These instructions (e.g., the instructions 410, when executed by processors 404, cause various operations to implement the disclosed embodiments.

The instructions 410 may be transmitted or received over the network 422, using a transmission medium, via a network interface device (e.g., a network interface Component included in the communication components 438) and using any one of several well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the instructions 410 may be transmitted or received using a transmission medium via a coupling (e.g., a peer-to-peer coupling) to the devices 424.

SIPV System Network Overview:

SIPV system 500 as functionally presented can also be characterized as apart of a network of SIPVs 100s interconnected via several network types comprising cloud, cellular, wireless, mesh or CAN bus network either using Virtual Machines or other Processor hardware to create a system grouping. Several network types of controllers maybe used in this solution comprising individual or hybridized networks as described earlier One variant of the present solution further comprises a Meshed SIPV Network 600 bus as shown in FIG. 6, and another is the CAN bus protocol discussed here. The Can bus is one of these central networking protocols used in vehicle systems without a host computer. The CAN Bus in this solution is an International Standardization Organization (ISO) defined serial communications bus originally developed for the automotive industry to replace the complex wiring harness with a two-wire bus. The specification calls for high immunity to electrical interference and the ability to self-diagnose and repair data errors. These features have led to CAN's popularity in a variety of industries including building automation, medical, and manufacturing. The CAN communications protocol, ISO-11898: 2003, describes how information is passed between devices on a network and conforms to the Open Systems Interconnection (OSI) model that is defined in terms of layers. Actual communication between devices connected by the physical medium is defined by the physical layer of the model. The ISO 11898 architecture defines the lowest two layers of the seven layer OSI/ISO model as the data-link layer and physical layer. By connecting all the modules in a vehicle to one central line, the control system is simplified and more easily regulated. This design allows any connected Module to alert the main controller to an event that as it occurs which will cause the rest of the system to respond accordingly. The shared data line allows multiple modules to be attached with less invasive efforts, making the potential for error much lower. If one Module on the CAN bus fails, it does not necessarily cause the failure of other modules. Unless the two systems are directly related, and one cannot run without the other, the healthy modules will continue to function perfectly despite the loss of one bad Module. This makes the entire system safer. Additionally, diagnostics of the SIPV 700 are simpler and more specific due to the specialized and self-contained nature of the modules. Diagnostics can now pinpoint the exact cause of the Module failure with accuracy and speed. When one Module needs maintenance, that Module can simply be targeted and replaced rather than tearing apart the entire vehicle. CAN bus offer a simple interface for attaching an additional nodes in the present solution. Each of the nodes can be used for diagnostics, reprogramming, monitoring, and more. The utility of these Module nodes can be seen in the SIPV system 500. SIPV 700 comprising at least an integrated safety control apparatus 504 wherein the integrated safety control apparatus 504 polls a sensor suite 506 further comprising plurality of sensors measured data parameters of the present SIPV that are selected from a group of tire pressure, seat occupancy, helmet worn, helmet missing, speedometer, accelerometer, GPS location, image capture, video streamed, user input commands, bump detection, SIPV pitch/roll/yaw orientation, battery status, motor status, rental status)from the currently active SIPV 700. This plurality of data is converted by the integrated safety control apparatus 504 into parameters related to safe use by a rider, a communication link to a SIPV safety controller 510 to transmit the parameters related to safe use by a rider on a SIPV, and at least an instruction received from the SIPV safety controller 510 via the communication link to direct a plurality of control units controlled in the SIPV physical controls suite 512 to modify current operation parameters (e.g. Applying a brake, reducing acceleration, cutting power, actuating signals and tones in the SIPV 700 (e.g. commanding compliance via the display) in a manner to bring the SIPV back to a safe use. The SIPV system 500 may also take over and slave the SIPV controller 502 if the data received from the present SIPV warrants the use of a redundant control of the SIPV. For clarity, the SIPV controller 502 may also reside externally to the SIPV 700 in this solution as well. As further demonstrated in FIG. 7 the SIPV system 500 further comprises a Vending Module 514, which handles authentication of a user, the validation of the payment method provided, provision of authorization for the user rental of a SIPV 700; an Operation Module 516 which handles the operational monitoring and control of the SIPVs managed by the SIPV system 500 and manages the activation or disabling commands of SIPV 700 that are under its control. The Maintenance Module 518 also manages maintenance requests by/to specific SIPV 700 that allow a maintenance team to be dispatched for servicing or power source replacement. The Analytics Module 520 collects, aggregates and presents data from the SIPVs to help those managing the SIPV system 500 optimize their Operation Module 516 with SIPV 700 placement and usage.

Mesh Network:

A mesh network (or simply mesh-net) as shown in FIG. 6 is a local network topology in which the infrastructure nodes (i.e. bridges, switches and other infrastructure devices) connect directly, dynamically and non-hierarchically to as many other nodes as possible and cooperate with one another to efficiently route data from/to clients. This lack of dependency on one node allows for every node to participate in the relay of information. Mesh networks dynamically self-organize and self-configure, which can reduce installation overhead. The ability to self-configure enables dynamic distribution of workloads, particularly in the event that a few nodes should fail. This in turn contributes to fault-tolerance and reduced maintenance costs. Mesh topology may be contrasted with conventional star/tree local network topologies in which the bridges/switches are directly linked to only a small subset of other bridges/switches, and the links between these infrastructure neighbors are hierarchical. The Meshed SIPV Network 600 comprises a meshed SIPV system 802, that is operably connected with a wireless network 604 as disclosed above, the Meshed SIPV Network 600 in operable communication with at least one device(a user cell phone 606, or a User computing device 608) the meshed SIPV system 602 delegating operations, monitoring or other computing tasks to at least a meshed SIPV controller 610. The meshed SIPV controller 610 then in operable communication with at least a meshed SIPV 612. The meshed SIPV 612 is also in operable communications with other meshed SIPV 612 as well other meshed SIPV controller 610 if the working area of a meshed SIPV system 602 is larger than the practical range of a single mesh meshed SIPV controller 610. A useful configuration of a meshed SIPV 612 interaction would be to use idle meshed SIPV 612 for computing power as they are out of service. Additionally, active in-use meshed SIPV 612 should be aware of and monitoring other meshed SIPV 612 around their communication area to help co-locate the meshed SIPV 612 of interest. Additionally, integration with the user cell phone 606 and the wireless network 604 to continue to assist in triangulation problems where a particular meshed SIPV 612 was last connected. For the sake of clarity, the use of wireless network 604 and user cell phone 606 would work in the other network types used in the present solution, it is not intended that this functionalilty only exist in the Meshed SIPV Network 600 example.

The safety enabled personal mobility vehicle or safety integrated electrically powered vehicle SIPV 700 shown in FIG. 7 comprises a substantially rigid frame with at least two wheels 704 mounted to the frame supporting a seat 708 for at least a single user of the SIPV 700 and an articulated steering column mounted to at least one of the wheels. The wheel 704 further comprising a wheel hub 716 spokes 718, a wheel rim 720 and tire 706, the wheel in front being rotatably articulated for steering with the articulated steering column further comprising a set extending at a substantially perpendicular orientation from the articulated steering column with each handle set at a height for a user to steer the SIPV 700 while riding the SIPV 700. The SIPV may have several configurations for a user, sitting or standing on the SIPV 700, FIG. 7 depicts a seated version. The set of handles 710 includes an acceleration control 714 and a braking control 712 operably connected to the wheel hub 716 that houses a brake 730 in at least one or more of the wheels. The frame further comprises foot rests 722, light 728, a drive apparatus 732 operably connected to the acceleration control that propels the wheels (e.g., via a gear set or direct drive), a power source interface, and a mobile computing Processor hardware Although not illustrated in FIG. 7, the SIPV 700 can also include other components that are integrated into the SIPV 700. (e.g. Camera, a Accelerometer, a power source among other sensors)

The frame can vary depending on the implementation, and can be fabricated using a number of materials. In this variant of the solution in FIG. 7, the frame has a open design to ensure that the SIPV 700 is compatible with all types of clothing. The frame allows for a comfortable upright riding position allowing the rider to sit on seat 708, resting on foot rests 722 and allowing the SIPV 700 to be parked on a kickstand 724 The drive apparatus 732 is located in this version of the solution in the back wheel hub 716. A safety linkage 736 is wirelessly connected to the Safety device 738 to link it to the SIPV 700 to allow the SIPV 700 to enforce the use of a Safety device 738. For the sake of clarity, this variant of the solution focuses on use of a helmet as a Safety device 738 however the solution contemplates dispensation or deployment of other safety device types as well(e.g. Debris protection, other joint protection as well as rash protection devices)

The tire on wheel 704 can be made from a solid or puncture resistant material. The wheels are secured to the frame using standard components (e.g., nuts). In general, the SIPV 700 can be made from unique parts (e.g., nuts and screws) having sizes to help deter theft. For instance, the nuts and screws that are part of the SIPV 700 can be designed such that they can only be opened with proprietary interfaces further comprising electronic locks (e.g. BlueTooth® interfaces as described later in this description).

The wheel hub 716 house the brake 730 and/or drive apparatus 732. The internal wheel hub 716 can keep the wiring for brakes and gears enclosed and hidden. The brake 730 can include front and rear drum brakes operably connected to the set of handles 712 and the acceleration control operably attached for the drive apparatus 732 Other types of brakes such as disk, cantilever, and V-brakes may also be used.

The light 728 can further comprise at least a multiple LED lights powered by the power source mounted internally in the seat post 726. The power source 902 will be introduced later in FIG. 9. The light 728 can be replicated anywhere on the SIPV 700 to help provide visibility at night. In addition, lighted or reflective surfaces can also be applied to Logo zones on wheels, pedals, and on other visible areas of the SIPV 700 to enhance the solution branding and safety. An example of this feature is the power indicator 734 in FIG. 7 where a logo doubles as a power indicator 734

The seat post 726 can also be an adjustable height that allows the height of the seat 708 to be adjusted. The quick release feature of the seat post 726 is designed to allow easy height adjustments without making it possible to completely remove the post. A numbering system on the seat post 726 can help frequent users adjust the height of the seat 708 quickly to the pre-set height that the rider desires.

A significant aspect of this solution is that many of the safety features are built in and integrated at the SIPV 700 level, the SIPV system 500 level and extended to the user of the SIPV before, during and after the ride.

In FIG. 8, the handle further comprising a mounting for an acceleration control, a braking control, a display of SIPV 700's (BLE, cell, WiFi) network connections, status, location, other informatics, displaying data received from an onboard computer 808 (functionality further described in FIG. 9 and FIG. 7 mounted beneath the display, or down in the frame (the second option is shown in FIG. 9), turn signal control 804 and an antenna 806 for communication to the SIPV system 500 as introduced in FIG. 5. Turn signal control 804 is also linked to light 728 to indicate SIPV 700 turning by the user. Another aspect of the solution shown is rider authentication apparatus rider authentication apparatus 810 which is shown on as a QR code symbol in the written description, but could be accomplished with RFID technology, Bluetooth, Near Field Communications, or other device pairing technologies to allow a user to quickly authenticate and purchase a ride on the SIPV 700

In FIG. 7. shows an exploded view of the SIPV 700 is shown the substantially rigid frame further comprising: a power source powering a drive apparatus further comprising: at least a drive apparatus driving at least one of the wheels; a rider authentication apparatus 810; an acceleration control linkage to the drive apparatus for starting, maintaining, and decreasing movement of the SIPV 700 responsive to commands from a user input from the handle mounted controls(712 or 714) or from a SIPV system 500 or the onboard computer 808 to correct a detected unsafe condition. The drive apparatus is further comprising a motor, a power linkage to the power source and mechanical linkage to the wheel that the drive apparatus is driving. For the sake of clarity, the motor may directly drive the wheel 704 or indirectly drive the wheel 704 via chain/sprocket/drive shaft/transmission/or other indirect drive methods.

In FIG. 8, a close up of the control surfaces of the SIPV system 500 is also operably linked to a brake 730, the drive apparatus or the energy power source; a control linked to light 728 for signaling vehicle turns or braking (light 728 includes locations on the back and sides of the SIPV 700 for the sake of clarity). This SIPV system 500 linkage is in addition to inputs from the a user input from the handle brake control or a turn signal control 804 is fully coupled to the brake or turn indicator, respectively. The SIPV 700 wirelessly coupling to a Safety device 738 (e.g. a helmet) connected to the SIPV 700 to monitor for user safety further connected to the SIPV system 500 for transmission of other safety related data. The safety data that is interwoven into the safety solution comprises: Tire pressure used to detect safe driving conditions as well as safe loads (i.e. more riders than SIPV 700 is able to handle. A Seat sensor 1002 interlinked with the power source 808 to establish that a user is in place on the seat 708. A Bump sensor 1004 (both introduced in FIG. 10) allowing the SIPV 700 to identify unsafe driving (e.g., riding on sidewalks and other unsafe terrain. Other combinations of tire pressure data, bump sensor working in conjunction with the speedometer can identify unsafe speed and loads on the rigid frame. The SIPV 700 roll, yaw and pitch as well as SIPV 700 angle and upright gyroscope data to estimate SIPV status, detect accidents or other impacts on the SIPV, detection of uphill travel to increase power to drive apparatus, detection of downhill travel to establish system braking or power recovery protocols to keep SIPV from exceeding safe decent speeds. Integration with accelerometer/speedometer data also provides significant data for the SIPV 700 and SIPV system to detect, intervene if necessary, and transmit instructions to drive motor and braking performance. Servicing protocols are extracted from motor, brake and power sources. (e.g., the power source reports its charge status and usage. Although not explicitly a sensor, speakers/horns, displays and head lights/signal/telltale lights all are used to cue the rider of safety issues, warning the rider visually, aurally, or haptic notice of a safety issue. Finally, in the variants of this solution where at least a camera/video device is mounted in the SIPV 700, such that the visual detection of surroundings or items is also integrated into a safety scenario and forensic event recording. The camera can be uses to collect ride surroundings on a continuous basis to create the equivalence of a flight recorder and stream ride data to the SIPV system 500 during a ride for diagnostic purposes.

For the sake of clarity, the SIPV 700 comprises electric bicycles, electric mopeds, electric scooters and can further comprise any/all electric mobility vehicles having up to three wheels that are powered by an electric motor and primarily get their energy from the power grid—in other words: an EV that can be recharged or powered externally. This includes purely electric vehicles, vehicles that assist human power with electrical power assistance (e.g. pedaled), vehicles with a combination of electric motor and a small combustion engine (range extended electric vehicles—REEV), and hybrid vehicles that can be recharge via the power grid (plug-in hybrid electric vehicles—PHEV).

In FIG. 9, a cross-sectional view of the SIPV 700 further comprises a power source 902 that allows a rapid replacement by service personnel further comprising with safety and security interlocks that keep the SIPV 700 safer from vandalism and other threats. The power source 902 uses the Seat sensor 1002 that interacts with the SIPV 700 to determine if a rider is present on the seat 708 prior to the ride on the SIPV 700 allowing the drive apparatus to be engaged. Power source as defined in this solution includes electrical storage devices like batteries or active electrical generation devices like fuel cells that provide an electrochemical cell that converts the chemical energy of a fuel (often hydrogen) and an oxidizing agent (often oxygen) into electricity through a pair of redox reactions.

As shown in FIG. 10, the exploded view of the SIPV 700 showing the Seat Sensor 1002 and the Bump Sensor 1004 locations on the SIPV 700 as previously introduced.

As shown in FIG. 11, a power source 902 having compatible dimensions for seating inside a SIPV seat post 726 is inserted into of the SIPV 700 with the power source connector end 1102 of the power source 902 inserted first. A solenoid latch 1104 is pressed out of the way as the power source 902 is inserted into the seat post 726 and then the solenoid latch 1104 then re-extends once the power source 902 is fully inserted, locking the power source 902 into the seat post 726 When the power source 902 is fully inserted into the seat post 726, the power source connector end 1102 engages with the power source connector receptacle 1106 located at the bottom of the seat post 726. Once the power source connector receptacle 1106 connected with the power source connector end 1102, the power source powers the SIPV 700 and its respective vehicle control and authentication systems control (712,714,810,) thereby allowing Bluetooth Low Energy or the equivalent communications with the (SIPV 700 or the SIPV system 500) and the onboard computer 808 enabling control of the solenoid latch 1104. Servicing of the power source 902 is then enabled allowing the solenoid latch 1104 to be triggered by a mobile device application via Bluetooth Low Energy (BLE) link with solenoid latch 1104. Once unlatched, the power source 902 is removable. The SIPV system 500 can also trigger the solenoid latch 1104. Using the mobile device application, a maintenance command to unlock and remove the power source 902 is sent via BLE to the onboard computer 808 that issues a command to the solenoid latch 1104 via a digital bus. This digital bus can be a CAN bus or UART or other digital bus formats. As mentioned above, the power source 902 further comprises a Seat sensor 1002 comprising an integrated force-sensitive resistor drive circuit or its equivalent, which allows detecting the presence of a seated rider. Additionally, the power source 902 can also receive a deactivate command via BLE from a service technician, the SIPV system 500 or the onboard computer 808 if a disable requirement exists. (e.g., SIPV is stolen or damaged)

The present solution power source 902 provides for mass servicing, where the maintenance mobile device can simultaneously unlock multiple solenoid latch 1104 on multiple SIPV 700 via BLE. In the event of a power source 902 being drained and the solenoid latch 1104 is in an unpowered state, the power source 902 further comprises a power access port that enables a technician to power the solenoid latch 1104 and allow the removal of the power source 902. Additional safety considerations in the present invention's power configurations further comprise keeping the SIPV drive apparatus unpowered until a power-up procedure dictated by the onboard computer 808 is followed including use of the Safety device 738. The power source 902 further comprises a digital displayed of remaining capacity that is displayed either at the power indicator 734 or on the display. The power source 902 can be populated with a variable number of power cells/fuel cells to save weight and cost, or to comply with local regulations.

FIG. 12 displays a variant of the Safety device 738 and a SIPV mounting apparatus as it would be mounted on a SIPV 700. There are many places the safety device can be mounted on a SIPV 700 and the various variants of this solution are largely due to aesthetics. This variant of the solution's Safety device 738 deployment features a Mounting Clip 1202 where the Safety device 738 has a number of clip indents where the Safety device 738 has a Safety Device Retention Slot 1210 that fit with a Safety device retainer 1204 as the Safety device 738 is placed into the base of Mounting Clip 1202 and placed up into positions such that the Safety device retainer 1204 can be moved into position where the Latching Module 1206 will actuate to lock the device into place. The latching Module further comprises a local wireless connection to the onboard computer 808 and reports out that the latch is closed as well as confirming a near distance link between a Safety device sensor 1208 mounted in the Safety device 738 and a Mounting latch sensor 1212 located in the Latching Module 1206. One variant of this solution would carry permanent magnets to create a magnetic field that hall sensors emplaced in the Safety device 738 can use to detect a helmet presence. There are a number of variations of this configuration, but the basic aspect of the deployable Safety device 738 is that it is contained in the SIPV 700 and is deployed when the ride is purchased and recovered to the SIPV 700 and verified retrieved to the SIPV system 500. The deployment of this Safety device 738 typically is deployed once a user orders a SIPV 700 ride using a user mobile device. Upon validation of payment, the Latching Module 1206 receiving an unlocking command from onboard computer 808 or from the user mobile device if an app is used to generate an unlocking command. The solution contemplates either unlocking/retrieval methodology.

A typical SIPV rental process is outlined in FIG. 13, The SIPV rental process comprises a Start SIPV Rental 1302 step, where a particular SIPV 700 is identified for a rental. The user wanting to ride that SIPV 700 makes a Ride request step via mobile device/computing device of user step 904. where a potential user would use their mobile device to rent a particular SIPV 700(e.g, by using a QR code or an app that accomplishes the same usage), Selection of Destination 1308 is made after the user makes a Review ride destinations 1306 step. In the alternative, the user can simply rent the SIPV without selecting a destination and the SIPV will simply limit the ride to general service area). Once a Selection of Destination 1308 step has been made, the user will finalize the step of Book the SIPV 1312, which further comprises aa Payment Authorization 1314, and then to ultimately an Exit Transaction 1316 step. This booking step will in turn cause the Deploy Safety Device 1318 step releasing a Safety device 738 to the renting user, the SIPV 700 will validate that the Safety device 738 is working and in place completing a Safety Device Working and Used 1320 step. If the user does not use the Safety device 738 and it is permitted by law, a Wavier of Liability 1322 step is initiated, requiring the user to return the Safety device 738 to the Latching Module 1206. Once the Safety device 738 is restowed and latched into place, the waiver can be signed by the user and finalized to bring the SIPV ride ready at the Finish SIPV rental 1324 step.

The Safe Ride Flowchart 1400 is shown in FIG. 14 comprises a Continue Ride 1402 step where a user begins a ride on the SIPV 700 and the various safety systems support the ride with ongoing monitoring, a Monitor SIPV progress 1404 step simply monitors the ride and compares any known parameters for the ride. If the SIPV is on an On Correct Route 1406 step and no other safety alerts are generate, the SIPV takes no actions, gives no alerts until the SIPV 700 arrives at an At Destination 1408 step, and a final position of the SIPV 700 is established and also where recovery of the Safety device 738 begins. During a Recover Safety Device 1410 step, the user is prompted to remove a liner inside the Safety device 738 and to return it to the Safety device retainer 1204 and to lock the Safety device 738 into the mounting clip and to lock it. The SIPV broadcasts a recovery signal to the SIPV system 500 and the SIPV validates that a Safety Device Recovered 1412 step has been completed. After that step, a Finalize Transaction 1414 step is completed, the final Payment Authorization 1314 is completed, and the ride is over. However, if a user is using the SIPV unsafely, another process loop initiates which causes a Route Correction 1416 step to be generated once the SIPV 700 moves off a target area serviced by the SIPV system 500. In addition to this step, a number of other warnings can be offered (e.g. an overweight ride, illegal sidewalk riding, driving down one-way streets backwards, and other SIPV 700 riding behaviors that the SIPV system 500 wishes to prohibit.) The SIPV 700 then pushes out, an Offer Advisory Warning 1418 step that gives that user a warning to return to an approved route or local or suffer a disabled SIPV 700. Once a warning has been ignored, a Disable Vehicle 1420 step is engaged. Once the Vehicle has been disengaged, a Notify SIPV servicing 1422, step is made telling the servicing team to go retrieve a SIPV 700 and return the onboard computer 808 to a Rental 1124 state.

Bluetooth Usage

The present solution uses Bluetooth to interact and pair a user to a particular shared ride rental and the user's mobile device. Bluetooth is a popular standard for close-range wireless communication. It provides the ability to pair two devices together and thereby exchange information with each other. An example of the authentication mechanism utilized by Bluetooth devices is described below. The pairing process, also known as the standard pairing, requires the two devices (user mobile device and the SIPV 700) establish an initial symmetric key in order to communicate securely. In this case there are two devices, a user mobile device and SIPV 700 being rented. The two devices at first handle two keys, share a PIN and know each other's 48-bit Bluetooth device address (BD_Addr). The first key is the symmetric initialization key (Kinit) to mutually authenticate each other and the second is a link key. The link key is generated during the pairing session with the help of the initialization key. The ‘Unit key’ is generated when the device is first operated with the help of the key generation algorithm. The ‘Initialization key’ is needed when two devices need to communicate with each other. It is used for exchanging link keys and for encryption as well as decryption of information during the link key generation protocol. The ‘Link key’ can be used in two different methods. The devices' unit key can be sent with encryption of the initialization key and this would constitute a link key or the device can generate a random number and then send it under the encryption of the initialization key and thereby generate a link key. The ‘Combination key’ is generated during the Initialization process at the same time and is only valid for the session only. This key is exchanged when the two devices compute their link keys. It comprises of a 128 bit random number and the Bluetooth device address. The ‘Encryption key’ is generated from the current link key during the authentication process. It is based on the COF (96 bit Ciphering Offset Number). The ‘Master key’ is generally used as the link key if the master needs to transmit to multiple slaves. It is generated using the key generation algorithm by virtue of the 128 bit random number. The resultant link key is then sent to the slave, bitwise xored with overlay. With this, slave can compute master key.

Bluetooth Pairing Mechanism

At the onset, both the devices share a low-entropy human-readable secret PIN. Typically the PIN comprises of a 4-digit code, which can be up to 128 bits When device 1 initiates the connection it is referred to as the initiating device and it does so by generating a random nonce (number used once) n1, and then sending it to device 2. Both devices then compute a shared initialization key Kinit using the E22 algorithm. The key Kinit is a function of n1, BD_Addr1, and PIN.

Device Authentication

After the shared key generation, the two devices authenticate each other before generating the encryption key. It is based on the challenge response scheme. The verifier (device 2) sends a plain-text random value AV_RAND2, the receiver (device 1) then computes a response SRES=E1 (Kinit, BD_Addr1, AV_RAND2) where E1 is the algorithm. The verifier performs the same calculation and compares the response to the verifier. After the verification, a match is required for the mutual authentication process to be successful.

Bluetooth Encryption

The Bluetooth mechanism involves the use of block cipher algorithm for encryption and Link Key generation. Further, the encryption of packets is performed using a stream cipher and 4 linear feedback shift registers. After authentication, a cipher key K3 is generated. The key length is 128 bits to ensure high level of security. After the key is generated, the data payload is encrypted using the cipher stream engine E0 and takes as inputs the encryption key, BD_Addr, 128 bit random number and the 26 LSB of the master's clock. The input values are shifted into four linear feedback shift registers and then combined in the summation combiner FSM to produce the cipher. This generates a new cipher every time.

The above description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the invention can be practiced. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

In the event of inconsistent usages between this document and any documents so incorporated by reference, the usage in this document controls.

In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In this document, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

Geometric terms, such as “parallel”, “perpendicular”, “round”, or “square”, are not intended to require absolute mathematical precision, unless the context indicates otherwise. Instead, such geometric terms allow for variations due to manufacturing or equivalent functions. For example, if an element is described as “round” or “generally round,” a component that is not precisely circular (e.g., one that is slightly oblong or is a many-sided polygon) is still encompassed by this description.

Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a Computer-Readable Medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level language code, or the like. Such code can include computer readable instructions for performing various methods. The code may form portions of computer program products. Further, in an example, the code can be tangibly stored on one or more volatile, non-transitory, or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable media can include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memories (RAMs), read only memories (ROMs), and the like.

The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description as examples or embodiments, with each claim standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Number	Date	Country
62820005	Mar 2019	US
62820013	Mar 2019	US
62820039	Mar 2019	US
62875187	Jul 2019	US
62909653	Oct 2019	US

SAFETY INTEGRATED SHARED VEHICLE SYSTEM AND METHODS

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

International Classifications

Abstract

Description

Claims

CLAIM OF PRIORITY

Provisional Applications (5)