Patent Publication Number: US-2020298841-A1

Title: Safety integrated shared vehicle system and methods

Description:
CLAIM OF PRIORITY 
     This patent application claims the benefit of priority of Viner, et.al, U.S. Provisional Patent Application Ser. No. 62/820,005 filed on Mar. 18, 2019 (Attorney Docket No. 5148.001PRV), the benefit of priority of Viner, et.al, U.S. Provisional Patent Application Ser. No. 62/820,013 filed on Mar. 18, 2019 (Attorney Docket No. 5148.002PRV), the benefit of priority of Viner, et.al, U.S. Provisional Patent Application Ser. No. 62/820,039 filed on Mar. 18, 2019 (Attorney Docket No. 5148.003PRV), the benefit of priority of Viner, et.al, U.S. Provisional Patent Application Ser. No. 62/875,187 filed on Jul. 17, 2019 (Attorney Docket No. 5148.004PRV), and the benefit of priority of Viner, et.al, U.S. Provisional Patent Application Ser. No. 62/909,653 filed on Oct. 2, 2019 (Attorney Docket No. 5148.013PRV), all of which are hereby incorporated by reference herein in their entireties. 
    
    
     COPYRIGHT NOTICE 
     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&#39;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&#39;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  100   s  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&#39;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 &#39;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&#39;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&#39;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&#39;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&#39;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&#39; 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&#39;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.