Patent Application
20210394766
The invention generally relates to a method and system for detecting, monitoring and/or controlling a mobile communication device.
Accordingly, the invention is directed to a method and system for controlling a mobile communication device in a vehicle that substantially obviates one or more of the problems due to limitations and disadvantages of the related art.
Disclosed herein is a method and system for detecting, monitoring and/or controlling one or more of mobile services for a mobile communication device (also referred to herein as a Controllable Mobile Device or CMD), and in particular, when the device is being used and the vehicle, operated by the user of the device, is moving. The present method and system (also referred to as a “mobile services control system” herein) determines whether the vehicle is being operated by a user that may also have access to a mobile communication device which, if used concurrently while the vehicle is in operation, may lead to unsafe operation of the vehicle. If the mobile services control system determines that a vehicle operator has potentially unsafe access to a mobile communication device, the mobile services control system may restrict operator access to one or more services that would otherwise be available to the operator via the mobile communication device.
In at least some embodiments of the mobile services control system, the position of a mobile communication device within the vehicle is determined, and in particular, whether the mobile communication device (also referred to as merely a “mobile device” herein) is within a restricted zone of the vehicle, which may include, but is not limited to, the driver's seat, areas near the driver's seat, other locations within the vehicle, or in some cases, the entire vehicle occupant enclosure. The present mobile services control system may be utilized to restrict mobile communication device access over any of a plurality of wireless communication standards, protocols or wireless interfaces (including CDMA, WCDMA, TDMA, UMTS, GSM, GPRS, OFDMA, WiMAX, FLO TV, Mobile DTV, WLAN, and Bluetooth technologies), and may be provided across multiple wireless network service providers. The present mobile services control system may be used to restrict access to mobile communication device services (e.g., texting, voice calls, games, videos, Internet access, online books, etc.) on a plurality of mobile communication devices available within a single vehicle occupant enclosure. The ability of embodiments of the mobile services control system to control access to services on one or more mobiles (e.g., within a vehicle occupant enclosure) may be substantially facilitated by centralizing or concentrating information related to subscribers to the mobile services control system, wherein “subscribers” as used herein, unless explicitly indicated otherwise, refers to persons or entities that contract for the user services provided by the mobile services control system (e.g., for restricting user access to certain mobile services). The information that may be centralized or concentrated by the mobile services control system include, e.g., subscriber related data for identifying: mobile(s) and/or mobile user(s) and/or vehicle(s) to which access to certain services on mobiles are to be restricted. In particular, in at least one embodiment, such centralization or concentration of subscriber information may be provided and maintained independently of most wireless service providers. For example, such centralization or concentration of subscriber information may be maintained and accessed via an Internet website, wherein such subscriber information may be accessed from a data management system which, in addition to identifying the subscribers, contains operational information about the mobile communication devices to be controlled by the mobile services control system, and the subscriber vehicles and also configurable service control parameters for allowing, e.g., subscribers to configure the mobile services control system to meet their individual needs and/or circumstances. In particular, the mobile services control system provides a mechanism for transmitting data detected during operation of vehicles to the centralized data management system for determining any restrictions on mobile services to be activated or deactivated. The present mobile services control system may also provide support for the correlation of data from the one or more detectors and/or sensors within the vehicle and the mobile communication device, with usage data from the service provider of the mobile communication device. The correlated data may be used for, but is not limited to, reporting on the use of mobile services while the vehicle is moving, sending notification messages and/or alerts, and/or real-time control (enable/disable) of mobile services on the mobile communication device. Accordingly, embodiments of the mobile services control system described herein provide one or more of the following features:
(a) The mobile services control system monitors and/or controls mobile communication device access to services while a corresponding registered vehicle is in operation.
(b) The mobile services control system provides an in-vehicle Vehicle Detection System (VDS) which includes a vehicle motion sensor to determine the operational state of the vehicle, and may include a detection engine (e.g., a hardware/software configuration of computational equipment) with one or more detectors and/or sensors to determine the presence and identity of one or more Controllable Mobile Devices (CMDs) within the vehicle and possibly to determine the position of one or more CMDs within the vehicle.
(c) The mobile services control system may provide a centralized data storage system (herein also referred to as a Safe Driving Database which contains, but is not limited to, (i) subscriber identity information, (ii) registration information identifying the Vehicle Detection System (VDS) for each subscriber's vehicle whose operation triggers activation of the mobile services control system for controlling a Controllable Mobile Device (CMD) within the vehicle, (iii) registration information identifying the one or more CMDs, (iv) customizable service control settings, and (v) “vehicle plus mobile detected information” which includes, but is not limited to, vehicle operational status information (e.g., moving/not moving, possibly GPS position, etc.), the identity of each of one or more CMDs detected within the vehicle, possible position information for each of the one or more CMDs (e.g., in/out of the restricted zone, position relative to the restricted zone, etc.), possible the boundary definition of the restricted zone within the vehicle, and other related vehicle or mobile state/position information.
(d) The mobile services control system may provide a centralized data management system (herein also referred to as a Safe Driving Registration System or SDRS) with user interfaces for customers, administrators, and communication (wireless) service providers to configure data monitoring and service control settings, along with generating usage reports and alert messages, and for the SDRS to provide electronic interfaces via which such service providers or other entities may gain access to data contained in the Safe Driving Database.
(e) The mobile services control system may provide for the transmission of vehicle operational status and mobile communication device position information to the Safe Driving Database, either in real-time or with a store-forward mechanism.
(f) The mobile services control system may provide, for each vehicle occupant enclosure being monitored, an in-vehicle VDS which can determine the position of each Controllable Mobile Device (CMD) within the vehicle occupant enclosure relative to a predetermined restricted zone, wherein the restricted zone may be any sub-area within the vehicle occupant enclosure, or the entire vehicle occupant enclosure, and then wirelessly transmit that restricted zone position information to the Safe Driving Database.
(g) The mobile services control system may provide and maintain data for each monitored Controllable Mobile Device (CMD), wherein the data may include one or more of:
(i) a Mobile Device Air Identifier to identify the CMD to the Vehicle Detection System (VDS), (ii) a wireless signal identifier generated by the CMDs wireless signal, (iii) identification of one or more mobile services or applications that may be controlled by the mobile services control system. The mobile services control system may also provide: (i) a vehicle wireless network interface which may connect the CMD wirelessly to the VDS ii) a service provider wireless network interface which may connect it to a communication (wireless) service provider for communicating with the vehicle, and (iii) control software which may control the services or applications.
(h) The mobile services control system may provide a Service Decision System in operation with the Safe Driving Registration System (SDRS) to receive the vehicle plus mobile detected information and to receive input service control parameters, where the Service Decision System may further be operational to send realtime service control directives to the wireless service provider for the mobile device or to the SDRS to enable or disable specific services for a specific CMD, or to enable/to disable the CMD itself, wherein the Service Decision System or SDRS may provide an option for the subscriber of the mobile services control system or the user of the CMD to temporarily override the control of enabling or disabling services.
In at least some embodiments, the system described herein may be used for purposes beyond that of controlling mobile electronic devices. For example, the system described can be easily integrated into various other commercial systems that involve a connection between a vehicle and the internet or a cloud, such as systems that provide a connection between a vehicle and a cloud to capture driving behaviors that are relevant to the insurance industry (such as Usage Based Insurance), or connections between commercial vehicles and the internet cloud where vehicle and driver information is captured for safety and other business purposes. With subject invention can be integrated into these systems, so as to provide control of potentially distracting devices in the vehicles, or elements of the invention can be integrated into these systems to be able to identify individuals within the vehicle, or identify the drivers of the vehicles, either by identifying that a CMD is within the vehicle through the techniques described herein, or by identifying the driver of the vehicle through the techniques described herein. This information can then be used for various other commercial purposes other than controlling potentially distracting electronic devices, such as improving insurance company performance by knowing the identity of drivers, or by associating particular safe or unsafe driving practices with specific drivers, or for commercial customers, identifying the drivers of a vehicle and or identifying safe or unsafe driving practices of a specific driver.
In at least some embodiments, registered or associated CMDs are utilized that are associated to a specific VDS and therefore represent the CMDs that are most likely to be used by a driver of the vehicle associated with the VDS. The use of registered CMDs (which is typically a number between 1 and 5, but in some instances can be greater) limits the number of CMDs that are required to be determined to be in or out of a vehicle, and therefore significantly enhancing the functionality of the system for controlling mobile devices in vehicles. However, it is noted that various aspects of the invention can be utilized with non-registered or non-associated CMDs, or alternately a much larger population of CMDs might be associated or registered with a CMD (such as the CMDs subscribing to a particular MSDP, or the CMDs in a particular geographic area may be registered to a specific CMD) to also enhance the system.
In one embodiment, the system can incorporate a reward for self-identifying the driver at the beginning of the trip through a handset, or through scheduling thereby eliminating ambiguity if the individual is driving, providing a more accurate score, creating the habit of self-identifying at the beginning of the trip, and providing additional accurate information for use by insurance companies and other parties that are interested in knowing the identify of an individual who is driving. In addition, the self-identifying feature of the application, can incorporate other information to the driver, such as driving information, route information, traffic information, motivational thought for the day, joke of the day, or similar type things that incentivize the driver to stop and identify themselves prior to starting the trip.
In an embodiment, an aspect of the invention seeks to control unsafe driving by changing the behavior of drivers to lessen the occurrence of unsafe driving events such as texting while driving, use of distracting features of a mobile device while driving, speeding, swerving, hard corners, e.g., greater than a predetermined threshold of acceleration, hard braking and acceleration, e.g., greater than a predetermined threshold of acceleration, lack of focus on driving, and lack of anticipation while driving. An embodiment provides immediate feedback or substantially immediate feedback on safe driving habits (as indicated by lack of unsafe behaviors) formatted as a game or score, thereby motivating the driver to change driving behaviors through a desire to win the game, meet personal goals, meet team goals, and through tangible and intangible rewards provided by doing well in the game, or by consequences for unsafe driving, provided by parents, law enforcement, insurance companies, schools, or other organizations or individuals that can provide material consequences or rewards to the driver.
It is understood that this Summary section is neither intended to be, nor should be, construed as being representative of the full extent and scope of the present disclosure. Additional benefits, features and embodiments of the present disclosure are set forth in the attached figures and in the description herein below, and as described by the claims. Accordingly, it should be understood that this Summary section may not contain all of the aspects and embodiments claimed herein.
Additionally, the disclosure herein is not meant to be limiting or restrictive in any manner. Moreover, the present disclosure is intended to provide an understanding to those of ordinary skill in the art of one or more representative embodiments supporting the claims. Thus, it is important that the claims be regarded as having a scope including constructions of various features of the present disclosure insofar as they do not depart from the scope of the methods and apparatuses consistent with the present disclosure (including the originally filed claims). Moreover, the present disclosure is intended to encompass and include obvious improvements and modifications of the present disclosure.
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention.
In the drawings:
For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the exemplary embodiments illustrated in the drawing(s), and specific language will be used to describe the same.
Appearances of the phrases an “embodiment,” an “example,” or similar language in this specification may, but do not necessarily, refer to the same embodiment, to different embodiments, or to one or more of the figures. The features, functions, and the like described herein are considered to be able to be combined in whole or in part with another as the claims and/or art may direct, either directly or indirectly, implicitly or explicitly.
Functional units described in this specification may be labeled as modules, in order to more particularly emphasize their structural features. A module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. Modules may also be implemented in software for execution by various types of processors. An identified module of programmable or executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Components of a module need not necessarily be physically located together, but may, e.g., comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
A module and/or a program of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, data or input for the execution of such modules may be identified and illustrated herein as being an encoding of the modules, or being within modules, and may be embodied in any suitable form and organized within any suitable type of data structure.
The various system components and/or modules discussed herein may include one or more of the following: a host server or other computing systems including a processor for processing digital data; a memory coupled to the processor for storing digital data; an input digitizer coupled to the processor for inputting digital data; an application program stored in one or more machine data memories and accessible by the processor for directing processing of digital data by the processor; a display device coupled to the processor and memory for displaying information derived from digital data processed by the processor; and a plurality of databases or data management systems.
The present disclosure may be described herein in terms of functional block components, screen shots, user interaction descriptions, optional selections, various processing steps, and the like. It should be appreciated that such descriptions may be realized by any number of hardware and/or software components configured to perform the functions described. Accordingly, to implement such descriptions, various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, and the like may be used, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. Similarly, the software elements of the present disclosure may be implemented with any programming or scripting language such as C, C++, Java, COBOL, assembler, PERL, Visual Basic, SQL Stored Procedures, AJAX, extensible markup language (XML), Flex, Flash, with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Further, it should be noted that embodiments in the present disclosure may employ any number of conventional techniques for data transmission, signaling, data processing, network control, and the like as one skilled in the art will understand. Embodiments of the present disclosure may also include detection or prevention of security issues using various techniques. Additionally, many of the functional units and/or modules herein may be described as being “in communication” with other functional units and/or modules. Being “in communication” refers to any manner and/or way in which functional units and/or modules, such as, but not limited to, computers, laptop computers, PDAs, modules, and other types of hardware and/or software, may be in communication with each other. Some non-limiting examples include communicating, sending, and/or receiving data and metadata via: a network, a wireless network, software, instructions, circuitry, phone lines, Internet lines, satellite signals, electric signals, electrical and magnetic fields and/or pulses, and/or so forth.
Communication among the parties in accordance with the present disclosure may be accomplished through any suitable communication channels, such as, for example, a telephone network, an extranet, an intranet, Internet, point of interaction device (point of sale device, personal digital assistant, cellular phone, kiosk, etc.), online communications, off-line communications, wireless communications, transponder communications, local area network (LAN), wide area network (WAN), networked or linked devices and/or the like. Moreover, although the invention may be implemented with TCP/IP communications protocols, embodiments of the disclosure may also be implemented using IPX, Appletalk, IP-6, NetBIOS, OSI or any number of existing or future protocols. Specific information related to the protocols, standards, and application software utilized in connection with the Internet is generally known to those skilled in the art and, as such, need not be detailed herein. See, for example, DILIP NAIK, INTERNET STANDARDS AND PROTOCOLS (1998); JAVA 2 COMPLETE, various authors, (Sybex 1999); DEBORAH RAY AND ERIC RAY, MASTERING HTML 4.0 (1997); and LOSHIN, TCP/IP CLEARLY EXPLAINED (1997), the contents of which are hereby incorporated by reference.
As used herein, “comprising,” “including,” “containing,” “is,” “are,” “characterized by,” and grammatical equivalents thereof are inclusive or open-ended terms that do not exclude additional unrecited elements or method steps unless explicitly stated otherwise.
In order to more fully appreciate the present disclosure and to provide additional related features, the following references are incorporated therein by reference in their entirety:
(1) U.S. Pat. No. 6,122,486 by Tanaka et al. which discloses, a transmission restricting system which has a transmission interruption controlling means for generating and radiating a magnetic field pattern including a command code to command the transmission interruption to a radio communication terminal equipment in a radio-wave transmission-prohibited area, the transmission interruption controlling means being disposed at the entrance or exit of the radio-wave transmission-prohibited area; a transmission interruption releasing means for generating and radiating a magnetic field pattern including a command code to command the releasing of transmission interruption to the radio communication terminal equipment in the radio-wave transmission-prohibited area, the transmission interruption releasing means being disposed at the entrance or exit of the radio-wave transmission-prohibited area; and a radio communication terminal equipment comprising means for detecting a magnetic field pattern including a command code to command the transmission interruption or the releasing of transmission interruption, and means for controlling the process of the transmission interruption or the releasing of transmission interruption according to the result of the detection of the detecting means.
(2) U.S. Pat. No. 6,353,778 by Brown which discloses, an automobile computer control system for limiting the usage of wireless telephones in moving automobiles comprising an implementation for sensing when the velocity of the automobile exceeds a predetermined velocity, a wireless implementation for sensing when the wireless telephone is in use by the driver of the automobile and a function responsive to both of the sensing implementations for limiting the use of the wireless telephone by the driver of the automobile when the velocity of the automobile exceeds the predetermined velocity. For the best safety, the predetermined velocity is any moving velocity. Also, the wireless device for sensing when the velocity of the automobile exceeds a predetermined velocity may be carried out by an infrared device.
(3) U.S. Pat. No. 6,556,810 by Suzuki which discloses, a communication inhibiting apparatus with: disturbing wave generating means for generating a disturbing wave signal which disturbs communications to and from a portable telephone or similar communication terminal equipment; and disturbing wave emitting means for emitting the signal generated by the disturbing wave generating means, as the disturbing wave, to the communication terminal equipment.
(4) U.S. Pat. No. 6,690,940 by Brown et al. which discloses, a system for selectively disabling use of at least selected features of a stand-alone electronic device under a predetermined set of conditions. The system establishes a state of the set of conditions as being satisfied or unsatisfied, communicates the state to the electronic device, and disables the selected features if the state is satisfied. In one embodiment, the system may be advantageously used to prevent vehicular accidents by at least partially disabling non-emergency use of a wireless telephone in a moving vehicle. In another embodiment, the system may be used to disable features of an electronic device within a predetermined area having a boundary that is independent of a communications network cell.
(5) U.S. Pat. No. 6,973,333 by O'Neil which discloses restrictions on use of a cellular telephone in a vehicle, such as an automobile, that are imposed using a global position system (GPS) device to determine the location of a vehicle in relation to geographic regions in which legal or customer restrictions on cellular telephone use are to be imposed. Network or local short-range wireless transmitters supply information to a cellular telephone describing potentially applicable restriction information retrieved from network databases. In response, a cellular telephone determines applicability of such restrictions and applies them to further use of the cellular telephone while such restrictions continue to apply. Alternative arrangements allow vehicle-based or network based processing of region and restrictions information to yield command messages to cellular telephones.
(6) U.S. Pat. No. 7,064,656 by Belcher et al. which discloses a controller to prevent access or utilization by a vehicle operator to communications devices installed on the vehicle when the vehicle is in motion thereby reducing distractions of the operator.
(7) U.S. Pat. No. 7,107,058 by Inoguchi et al. which discloses a printer that enables a determination whether a failure has occurred in a device during initialization or a radio wave condition is bad. Receive electric field strength during a time period from a time at which a turn-off message is outputted to a time at which turn-on message is outputted and receive electric field strength after the turn-on message is outputted are measured. The measurements are compared with each other and information indicating the condition of each of a plurality of channels is printed out according to the results of the comparison. A user can reference the printed information to determine whether a failure has occurred in a device or the radio wave condition is bad.
(8) U.S. Pat. No. 7,181,229 by Singh et al which discloses a system for disabling a cell phone in the presence of certain conditions, and for switching it off in the presence of some other conditions, while allowing its use in the normal fashion in the absence of these two sets of conditions. Thus, this system regulates cell phone use in accordance with specified restrictions in specific locations, and allows its normal functioning when these restrictions are not required. Specifically, a first condition is an attempt to operate a cell phone by the driver of a vehicle having its ignition on and/or moving above a certain speed. In such a condition the system would automatically disable the OK switch of a cell phone and may also perform the CALL END function. In the second condition the system automatically switches off any cell phone in the ON condition being carried on the person of an individual occupying a seat in an aircraft, or a committee room, or any other such location where such a restriction is envisaged. The system also makes a provision for automatic sequential dialing of a specified set of numbers like the police, medical services etc. during an emergency by allowing overriding any regulatory restriction. In addition, U.S. Pat. No. 7,181,229 also relates to control circuits provided in the system for preventing tampering with or bypassing the system by cell phone users.
(9) U.S. Pat. No. 7,206,615 by Ochi et al. which discloses a first transmitter that outputs a request signal requesting a response to a mobile device toward an area including a driver's seat and its neighborhood, and a second transmitter outputs a request signal toward an area covering the entire vehicle. The mobile device transmits a response signal to a receiver if receiving the request signal transmitted from the first or second transmitter. The controller detects the position of the mobile device based on a communication result between the mobile device and the receiver in response to the request signals transmitted from the first and second transmitters.
(10) U.S. Pat. No. 7,260,390 by Skinner et al. which discloses a panel provided to a wireless device that turns off all RF capability of the wireless device (including, but not limited to notifications, wireless web clipping, instant messaging, email sending/receiving, phone calls, etc.). The panel is brought up on a screen of the wireless device by pressing a programmed hard button for more than 1 second. Once the RF capability has been turned off, if the user attempts to access a program or other device that requires the RF capabilities, a notification is displayed that identifies the RF capabilities as being disabled and prompts the user whether to continue. If the user continues, the RF device is automatically enabled, otherwise the RF device remains disabled.
(11) U.S. Pat. No. 7,343,148 by O'Neil which discloses, restrictions on use of a cellular telephone in a vehicle, such as an automobile, that are imposed using a global position system (GPS) device to determine the location of a vehicle in relation to geographic regions in which legal or customer restrictions on cellular telephone use are to be imposed. Network or local short-range wireless transmitters supply information to a cellular telephone describing potentially applicable restriction information retrieved from network databases. In response, a cellular telephone determines applicability of such restrictions and applies them to further use of the cellular telephone while such restrictions continue to apply. Alternative arrangements allow vehicle-based or network based processing of region and restrictions information to yield command messages to cellular telephones to control their further use.
(12) U.S. Pat. No. 7,369,845 by Keohane et al. which discloses, a portable communication device that detects a current speed of travel of the portable communication device independent of any vehicle temporarily transporting the portable communication device. A speed based setting controller of the portable communication device compares the current speed to at least one threshold value set at the portable communication device. Responsive to the current speed exceeding the threshold value, the speed based setting controller automatically assigns a separate speed based setting to a current setting for each feature assigned to the threshold value, wherein each current setting for each feature designates the operability of that feature within the portable communication device, such that the current setting for each feature adjusts with a speed of travel as detected by the portable communication device.
(13) U.S. Pat. No. 7,395,046 by Hossain et al., which discloses a method and apparatus for enhancing the probability of a successful emergency call completion and emergency callback on a mobile station in a network, the method comprising the steps of: during an emergency call attempt, monitoring whether the mobile station has received a non-voice service request from the network and, if yes, ignoring the non-voice service request, Further, during a callback period, monitoring whether the mobile station has received a service request from the network and, if yes, ignoring the service request if the service request is a non-voice service request that is anything but a position location service request. Further, during a callback period, monitoring whether a user attempts to initiate a non-voice service request that is anything but a position location service request, and if yes ignoring the non-voice service request.
(14) U.S. Pat. No. 7,400,891 by Aaron which discloses wireless terminals that are remotely controlled by identifying a wireless terminal that is located at a premises and obtaining at least one operational authorization rule for the wireless terminal that was identified, and that applies to the premises at which the wireless terminal is located. Selected operations of the wireless terminal are disabled and/or enabled in response to the at least one operational authorization rule that was obtained for the wireless terminal that was identified and that applies to the premises at which the wireless terminal is located.
(15) U.S. Pat. No. 7,471,929 by Fujioka et al. which discloses a device and a method for telephone countermeasure in using a telephone during driving which can automatically suppress communication of only a driver in a vehicle. The device for telephone countermeasure includes a database (3), a driver judgment unit, and a mode switching unit. The database (3) contains driver face data (3-1) and a telephone number (3-2) of a mobile telephone (7) used by the driver for each of the drivers. The driver judgment unit identifies the current driver of the vehicle in the database (3) by the face authentication. The mode switching unit extracts the telephone number (3-2) of the mobile telephone (7) used by the identified driver from the database (3) and switches the mobile telephone (7) of the driver to a drive mode such as a message recording mode by using the telephone number.
(16) U.S. Pat. No. 7,734,315 by Rathus et al. which discloses a method and system that limits the use of a communication device present in an area controlled by an intelligent controller. The intelligent controller detects any present communication devices in the area and conducts an inventory providing information about each detected device. The intelligent controller compares that information to a standard of use data, which specifies the conditions needed to be present for allowing the usage of a communication device. If such conditions are not met, the intelligent controller sends commands to the communication device to restrict its functionality. Else if, the intelligent controller is incapable of restricting the communication device, it can notify authorities of unauthorized usage of a communication device in the restricted area.
(17) U.S. Pat. No. 7,640,101 by Pair et al. which discloses a system that uses a GPS receiver and a computer program product to disable a feature of an electronic device when movement of the receiver is detected. Speed data from a GPS data stream is monitored. When the speed of the GPS receiver exceeds a predetermined value, the desired feature of the electronic device is disabled. For example, when the speed of the GPS receiver exceeds 0.5 knots, a windows function call is executed to set a desired display element as a top window on a display screen. The system may allow for temporary enabling of disabled features and for rapid enabling of disabled features when motion stops. The system may also include navigational software. A manufacturer may also use a proprietary combination of one or more disabled data fields in a GPS data stream to identify GPS receivers approved for use with the system.
(18) U.S. Pat. No. 7,474,264 by Bolduc et al. which discloses a system and method for detecting use of RF transmit devices (e.g., cellular phones) in a vehicle. The system includes a first RF antenna for detecting signal strength of an RF signals transmit device at a first location in a vehicle and a power first detector for generating a first output signal indicative thereof. The system also includes a second antenna for detecting signal strength of the RF signals at a second location in the vehicle and a second power detector for generating a second output signal indicative thereof. The system further includes a signal processor for processing the first and second output signals to determine the presence of an RF transmit device in use in the vehicle and to further determine the location of the RF transmit device to determine if a driver is using the device.
(19) U.S. Pat. No. 7,477,135 by Belcher et al. which discloses an access (utilization) controller to restrict or block visual or aural interaction between a vehicle operator/driver and mobile communications and information devices such as computers, mobile telephones, pagers, personal digital assistants (PDAs), and the like mounted on or used in the vehicle is disclosed. The utilization controller comprises sensors to detect motion or “potential” motion of the vehicle, a processor receiving data from the sensors and inhibitor means responsive to the processor to “blank out” or otherwise inhibit any distracting visual or aural output from the communications or information devices while the vehicle is in motion or about to move. The sensor data such as speedometer, transmission gear position indicator, antilock brakes and others are extracted from a vehicle's internal monitoring and control systems.
(20) U.S. Pat. No. 7,619,507 by Santos et al. which discloses aspects that provide a system and method for receiving information in a vehicle. Information pertaining to the vehicle's driver may be stored. Information pertaining to the vehicle's driver may be made audile through the vehicle's radio system.
(21) U.S. Patent No. 2002/0198005 by Hilton et al. which discloses, a logic based control system to modify and improve operations of wireless communications devices and the operating systems of a plurality of portable wireless communications devices by continuously, selectively and automatically controlling, enabling and/or disabling access to the transmission and reception of portable wireless communication devices depending on the factors of velocity, location and/or time of the wireless communication device, while continually enabling access to emergency communications at any time, location and/or velocity.
(22) U.S. Patent No. 2005/0170850 by Edwards et al. which discloses, the methods and apparatuses for selectively disabling functionality of a device to detect a device; detecting a device type of the device; and transmitting a signal to the device for selectively disabling a function of the device based on the device type.
(23) U.S. Patent No. 2005/0184860 by Taruki, which discloses a portable information terminal controlling system comprising the detector-transmitter and the cellular phone. The detector-transmitter includes the automobile moving state detecting unit and the control information transmitting unit. The cellular phone includes the function controlling unit, the transmitter-receiver, the display and the control unit. When the detector-transmitter detects that an automobile is moving, the detector-transmitter sends control information to a function controlling unit. When the detector-transmitter detects that an automobile is moving, the function controlling unit limits a part of a display function and a communication function of a portable information terminal, or limits all functions of the portable information terminal, and makes the portable information terminal be in a difficult state to use by giving an instruction to the control unit. Judgment of the driver's use of the portable information terminal is performed based on a signal arriving time and signal strength between the detector-transmitter and the function controlling unit, or an image extract with a camera included in the detector-transmitter.
(24) U.S. Patent No. 2005/0255874 by Stewart-Baxter et al. which discloses a system and method for detecting motion of a cell phone and disabling the use of the cell phone while moving or driving. The inventive system includes: a cell phone; a sensor to detect motion of the cell phone; software in the cell phone to disable the use of the cell phone when motion is detected. In a preferred embodiment, the system also recognizes the near proximity of an automobile and disables the use of the cell phone in this near proximity.
(25) U.S. Patent No. 2006/0099940 by Pfleging et al. which discloses a method for changing the status of a mobile apparatus based upon the velocity of the mobile apparatus. The communication system determines the velocity of a mobile apparatus by calculating the difference between a first position of a mobile apparatus at a first time and a second position of the mobile apparatus at a second time. If the velocity of the mobile apparatus exceeds a predetermined threshold, the communication system changes the status of the mobile apparatus to a sleep state and ends a call that the mobile apparatus is involved in.
(26) U.S. Patent No. 2007/0072616 by Irani which discloses, a method for preventing cellular phone usage while driving. In one embodiment a GPS system incorporated into the workings of the cellular phone is used to detect that the phone is in motion, and that the rate of movement exceeds some preset value indicating that the phone is in a moving vehicle. Having detected motion the phone will deliver a number of options ranging from complete shutdown until motion stops, to use only for emergency purposes, to only limited use, or to complete use by interjecting a preset PIN or other such password which will allow the cellular phone user to override the phone shutdown mechanism. Other alternate means for detecting motion include triangulation between numerous towers, to signal strength variation from a single tower, to signals generated by miniature accelerometers and velocity meters imbedded in the phone specifically for detecting rate of movement.
(27) U.S. Patent No. 2008/0139183 by Keohane et al. which discloses, a portable communication device that detects a current speed of travel of the portable communication device independent of any vehicle temporarily transporting the portable communication device. A speed based setting controller of the portable communication device compares the current speed to at least one threshold value set at the portable communication device. Responsive to the current speed exceeding the threshold value, the speed based setting controller automatically assigns a separate speed based setting to a current setting for each feature assigned to the threshold value, wherein each current setting for each feature designates the operability of that feature within the portable communication device, such that the current setting for each feature adjusts with a speed of travel as detected by the portable communication device.
(28) U.S. Patent No. 2008/0214211 by Lipovski which discloses, a system for selectively restricting or enabling the use of a cellular telephone module in a zone is described, comprising: a control signal transmitter for generating a control signal at an entrance to the zone or alternatively generating control signals throughout the zone; the cellular telephone including a module; a receiver module within the cellular telephone responsive to the control signal for generating a module enable/restrict upon receipt of the control signal; and a switch within the cellular telephone responsive to the module enable/restrict for selectively enabling or inhibiting the operation of the module for a predetermined period of time after receipt of the control signal. Additionally, this system's cellular telephone can dial a telephone, send a message to it, receive a text message from it, and send digits to it, to handle emergencies or conduct business. Finally, the system can remind owners to recharge their cellular telephone batteries.
(29) U.S. Patent No. 2009/0004968 by Miyake which discloses an in-vehicle apparatus that determines in the vicinity the presence of a portable terminal designated with a device requiring restriction on radio transmission as a device name thereof. Radio transmission from a cellular phone is thereby restricted. In contrast, when determining in the vicinity the absence of the portable terminal designated with a device requiring restriction on radio transmission, the restriction on radio transmission from the cellular phone is removed. In the event of a person with a cardiac pacemaker getting on the vehicle, if the person carries a portable terminal designated with a device requiring restriction on radio transmission as a device name, the concern of the person about a possibility that the cellular phone has a bad influence on the cardiac pacemaker can be prevented.
(30) U.S. Patent No. 2009/0029675 by Steinmetz, et al. which discloses, a safety device for automotive vehicles (cars, buses and trucks) or rail locomotives. The device inhibits use of cellular telephones and other communication devices that run the risk of distracting a driver/operator while the vehicle is in motion. Several techniques for inhibiting use are described which can be used individually or in a complementary combination. In one technique, a rapidly varying signal level is created local to the communication device. The variations exceed the operational limits of the system, thereby inhibiting communications. In another technique, the safety device emits radiation that interferes with the reception of signals by the communication device only within the interior of the vehicle and will not interfere with cell phones or wireless devises outside the automotive vehicle or rail locomotive. As another alternative, masking signals also may be generated to prevent signals sent by the communication device within the vehicle from being intelligible at receiving stations outside the vehicle.
(31) U.S. Patent No. 2009/00895744 by Sellin et al. which discloses, a system for controlling access to a network includes a wireless switch configured for radio frequency communication with a mobile unit associated with a radio frequency identification tag. The wireless switch is adapted for determining if a radio frequency identification tag is located within a first area, and enabling the mobile unit to access the network according to a first scheme if the mobile unit is located within the first area.
(32) U.S. Patent No. 2009/0111422 by Bremer et al. which discloses, control systems and methods that are provided for controlling a personal communication device (PCD), such as a wireless telephone, personal data assistant (PDA), etc. The control systems and methods enable the controlled PCD (CPCD): (1) to determine (a) CPCD motion (speed, acceleration, or both) and/or (b) geographical location and (2) to (a) modify (enable, disable, and/or otherwise change) one or more CPCD functions based at least in part on the CPCD motion and/or geographical location and/or (b) communicate an alert (locally and/or to a remote communication device). The control of CPCD functions and alerts may also be dependent on other factors, such as the laws of the authoritative legal jurisdiction wherein the CPCD is located. The operation of the following CPCD functions can be modified, as nonlimiting examples: keypad, image display, microphone, speaker, camera, voice call out, voice call answer, text message creation, text message transmission, text message reception, email creation, email reception, image creation, image reception, Internet browsing, gaming, ring signal operation, communication signal transmission, and communication signal reception.
It is of great national importance to change the behavior of drivers so that distracted driving, such as using one or more services of a mobile device while driving is lessened, thereby promoting safe driving behavior. Legislation is failing to change behavior, and systems that only control texting are also not changing the behavior of the majority of the population also the current techniques are perceived as overly intrusive, and impinging on rights. Thereby, hindering the adoptions of the same.
Embodiments of the invention are directed towards a subject behavior modification method and system that provides a system that rewards the driver, both with intangible and tangible rewards the driver is both motivated to adopt the system and also then motivated to change their behavior. In one embodiment, intangible rewards may include a score or ongoing ranking on a social media site or communicated over some other network. Moreover, a tangible reward may include an economic incentive, e.g., a reduction in an insurance premium. By incorporating elements that reward other safe driving behaviors, such as staying within the speed limit, not swerving and not abruptly stopping, the system is also able to broaden the behavior modification to a larger suite of behaviors, so that the improvement goes beyond distracted driving, to actually creating safe drivers in multiple respects.
The system can incorporate both gamification and incentivization, which have proven to be effective in changing behaviors in multiple domains, for instance skiing behaviors through the Epic Mix program, used by Vail Associates, to provide reward for skiers for the amount, and type of skiing they do.
An embodiment, combines elements such as distracted driving control systems, distracted driving reporting systems, measurement of vehicle characteristics indicating safe or unsafe behavior, indication of whether any of these systems have been overridden, and the ability to provide real time feedback and incentives (at the end of a trip). Thereby, the motivation to change behavior is powerful.
In an embodiment, reward for behavior changes or to motivate behavior change can include a number of different type of awards, e.g., intangible awards, tangible awards, combinations of the same and the like. Intangible awards or elements include, e.g., earning of badges, personal scores, team scores, competitors scores, leader boards, recognition on social media such as Facebook, Twitter, public acknowledgement as a safe driver, other form of networked communication, combinations of the same and the like. In addition, competition can be used as a tangible award, for instance with individuals, corporations, family members, or other groups competing against one another to determine who has the safest driver population, such as cities competing against one another. In addition, the tangible rewards can be used in combination or separate from intangible rewards. The tangible rewards can also include economic incentives, e.g., cash incentives provided for safe driving, insurance discounts, discounts on purchases (such as gasoline, food or other goods), discounts on other products of value to the driver such as discounts on beverages, or phone service provider service, or insurance, or food items, or hard goods such as clothing, that are provided by corporate partners to the program that recognize corporate reward for supporting social issues, brand halo effects, and from incentivizing individuals to go to their store and purchase an item for a discount.
The ability to provide feedback at the end of a trip as to the particular trip score and ultimate score, as well as the ability to identify the location at the end of the trip, allows instant gratification tie-ins to further drive behavior modification, such as at the end of the trip, when the score is provided, a map is presented showing nearby locations that will provide discounts, at that moment for safe drivers, for instance a coffee shop that is within a close distance, e.g., quarter mile, that will discount the price of a beverage, e.g., by 50%, if they arrive in the next period of time, including the ability for the discount to be increased if the score of the driver is increased.
These incentives can also be chosen by the driver to be things of value to them, for instance, they might choose from a list of possible incentives, to create a shorter list of the things that highly incentivize them, such as choosing a discount at high profile brand store such as Nike or Abercrombie and Fitch, or choosing a gas discount. Thereby, further incentivizing the driver.
As a further incentive, the system can incorporate a multiplier feature, so that as the driver completes a certain number of safe drive sequences in a row, e.g., a greater award, the reward multiplies, creating an additional powerful incentive to continue to drive safely.
In a preferred embodiment, the system permits or enables both controlling a distracted driving and/or reporting on distracted driving. In an embodiment, the system is configured to monitor whether a mobile device is in use, or monitor if the system has been overridden or defeated, or if the system is not in use but the driver still used distracting features on the phone, and then penalizing the driver by limiting points gained, or taking points away, a powerful incentive is created to prevent distracted driving behavior. Further, by utilizing embodiments described herein the system can determine who is in the vehicle, as well as who is actually driving the vehicle, thereby the accuracy of the system is increased, reducing false positive and false negatives, so as to further incentivize the driver, as they are not being falsely penalized, or falsely rewarded.
In an embodiment, a record of a driver's performance, e.g., including a score, can provide the basis for additional tangible benefits, by providing a metric by which the individual can be rewarded directly by organizations, or by the parents, for instance the parents can provide a financial reward if a driver exceeds a certain score in a certain period, or a company can provide a reward in vacation, or pay, or other gifts if an employee exceeds a certain point score in a certain period. In addition, a third party, e.g., an insurance company can provide a reward or a discount on insurance rates, if drivers exceed a certain score, or they can provide discounted rates to new insureds, if a driver exceeds a certain score, providing an additional incentive for insurance companies to adopt such a system.
In an embodiment, drivers' programs can adopt such a system, schools can adopt the system, federal government, and/or states can legislate such a system as part of a Graduated License Program, so that it becomes mandatory for a new driver, with the rewards of the system supporting the adoption of the system.
In one embodiment, the system can incorporate a reward for self-identifying the driver at the beginning of the trip through a handset, or through scheduling thereby eliminating ambiguity if the individual is driving, providing a more accurate score, creating the habit of self-identifying at the beginning of the trip, and providing additional accurate information for use by insurance companies and other parties that are interested in knowing the identify of an individual who is driving. In addition, the self-identifying feature of the application, can incorporate other information to the driver, such as driving information, route information, traffic information, motivational thought for the day, joke of the day, or similar type of things that incentivize the driver to stop and identify themselves prior to starting the trip.
In an embodiment, an aspect of the invention seeks to control unsafe driving by changing the behavior of drivers to lessen the occurrence of unsafe driving events such as texting while driving, use of distracting features of a mobile device while driving, speeding, swerving, hard corners, e.g., greater than a predetermined threshold of gravity force, hard breaking and accelerating, e.g., greater than a predetermined threshold of gravity force, lack of focus on driving, and lack of anticipation while driving. An embodiment provides immediate feedback or substantially immediate feedback on safe driving habits (as indicated by lack of unsafe behaviors) formatted as a game or score, thereby motivating the driver to change driving behaviors through a desire to win the game, meet personal goals, meet team goals, and through tangible and intangible rewards provided by doing well in the game, or by consequences for unsafe driving, provided by parents, law enforcement, insurance companies, schools, or other organizations or individuals that can provide material consequences or rewards to the driver.
In one embodiment, a mobile services control system for generating a score based on driving events. The system is configured to prevent unsafe driving, distracted driving, and/or change unsafe driving behavior of a user of the controllable mobile device. The system optionally includes an in-vehicle detection system and computational equipment. The computation equipment may reside in the cloud, partially within the cloud, and/or network. The in-vehicle detection system is configured to determine one or more characteristics of a vehicle indicative of the vehicle being operated by a user, e.g., key on, movement of vehicle, acceleration, combinations of the same and the like. The computational equipment is configured to generate the score based on a first input indicative of whether a controllable mobile device is within the vehicle when the vehicle is in operation, a second input comprising the one or more characteristics indicative of the vehicle being operated by a user, and a third input indicative of one or more of a use of the controllable mobile device, a use of the system that prevents unsafe use of the controllable mobile device, overriding the system that prevents unsafe use of the controllable mobile device, and unsafe driving events. Alternatively and/or optionally, the system can be configured to restrict one or more services of the controllable mobile device, report and monitor on the same.
In one embodiment, the use of the controllable mobile device includes any use, e.g., including but not limited to moving the phone, whether the phone is on or off, reviewing text message, typing a text message, sending a text message, reviewing an email message, typing a text message, sending an email, playing a game, viewing a video, and information provided via the Internet. In one embodiment, the score may include rewards, discounts and/or be indicative of a driving behavior of the user, e.g., may include one or more of a number of hard corners, a number of hard brakes, a number of overrides, a number of perfect segments, a number of perfect miles, over maximum velocity, over speed limit, miles driven, segments driven and other non-game data.
The Controllable Mobile Device (CMD) 25 provides the user of the CMD with communication services (e.g., voice, text messaging, email, Internet access, gaming, video, and other services) via a wireless connection 50 through a wireless network 45 from a Mobile Device Service Provider (MDSP) 130 (e.g., a cellular or WiMAX wireless carrier). The MDSP 130 is operational to enable or disable services provided to each CMD 25 and records each instance a user uses a service in a mobile usage database 135.
In addition to the plurality of services available through a Controllable Mobile Device (CMD) 25, the CMD may also provide a unique identification capability which can be detected over-the-air from one or more position detectors and/or sensors 37, 38, 39 (three are shown in
In one embodiment of the mobile services control system 10, the Vehicle Detection System (VDS) 35 is operational to send data, via wireless signal 65, to a wireless network 60 (which may or may not be identical to the network 45), and subsequently to Vehicle Service Provider (VSP) 100 also included as part of the system 10 in at least some embodiments thereof. The VSP 100 may be provided by a network/service operator (wireless carrier) which (via the wireless network 60) provides a mobile (wireless) data connection to a plurality of VDSs 35 in a plurality of vehicles 15. Alternatively, the VSP 100 may not be operated by the wireless carrier operating the network 60, and instead is, e.g., operated by an entity that operates the mobile services control system 10. The VDS 30 may physically be located in various positions within the vehicle 15, including, but not limited to, entirely within the vehicle occupant enclosure 20 (e.g., under the dashboard), or entirely outside of the vehicle occupant enclosure 20 (e.g., in the engine or trunk compartments), or partially within and partially outside the vehicle occupant enclosure 20 (e.g., with the VDS base unit 35 under the dashboard and the one or more detectors/sensors 37, 38, and 39 located elsewhere in the vehicle 15).
The vehicle plus mobile detected information (as also described in (c) of the Summary section hereinabove) is transmitted over wireless connection 65 (i.e., to a wireless base station 70), and such information may include position information indicative of whether the Controllable Mobile Device (CMD) 25 is within a restricted zone for the vehicle 15, or outside of the restricted zone, wherein such a restricted zone may be a geospatial envelop (2-dimensional or 3-dimensional) within the vehicle occupant enclosure 20 that is particularly associated with where an occupant would be positioned for operating the vehicle. The vehicle plus mobile detected information may further include detailed information describing a more precise position of the CMD 25 within such a restricted zone. The position information may be defined in a 3-dimensional spatial grid of x, y, and z coordinate offsets from a reference point, which might be a point adjacent to or in the base unit 35 of the Vehicle Detection System (VDS) 30 with optional resolutions in inches or centimeters, etc., or the position information may be provided as a one dimensional distance from, e.g., the detector and/or sensor 37 located near the driver's seat (more generally, the operator's position). Further, the data transmitted via connection 65 may include vehicle state information as to whether the vehicle 15 is moving and the operational status of the VDS 30 itself. In one embodiment, all of the data may be transmitted over the wireless connection 65 to the Vehicle Service Provider (VSP) 100 in a real-time, near-continuous stream of information. Alternately and/or optibnonally, the CMD may also provide information via 50 to a wireless network 45, the information including but not limited to information about a user's use of one or more services, number of finger pushes, e.g., selection of one or more feature of the phone, number of services used during a segment of distance or time, number of times a password was entered, texting services being used including reading, responding, phone services usage, internet services usage, game services usage, application usage, internet being usage, location of CMD, velocity of CMD, acceleration of CMD, deceleration of CMD, movement of CMD, power of CMD, e.g., was CMD on/off, self-identification of user and combinations of the same.
Alternately and/or optionally, the Vehicle Detection System (VDS) 30 may store the vehicle status information related to each restricted zone, each CMD 25 position, and other data in local non-volatile memory within the VDS for later forwarding to the Safe Driving Registration System (SDRS) 105 via the Vehicle Service Provider (VSP) 100. The VSP 100 may provide multiple network access methods by which the VDS 30 may forward the stored data. In one embodiment, when the VDS 30 enters receive/transmit range of VSP's 100 network 60, the VDS may be operational to transmit the stored data to wireless network base station 70 via wireless signal 65. In another embodiment, the VSP 100 may provide access to the VDS 30 through a data network 90. For example a wireless connection and signaling between the VSP 100 and the VDS 30 may be tunneled through an Internet data connection (e.g., TCP/IP) wherein the data network 90 is used to communicate data to the Mobile Services Control System 10, e.g., when the vehicle 15 resides at the premises 85 as shown in
Alternately and/or optionally, the Vehicle Detection System (VDS) 30 may be configured and operable to transmit the vehicle plus mobile detected information and other data directly to the Controllable Mobile Device (CMD) 25 via an over-the-air connection 40.
In this configuration both the CMD 25 and the VDS 30 include vehicle wireless network interfaces, such as, for example a WLAN/Wi-Fi, femtocell or picocell wireless, Bluetooth, Wireless USB, or some similar connection. In this configuration, control software on the CMD 25 may determine what action to take on specific services or applications operating on the CMD, such actions may include, but is not limited to: disabling a specific service, a set of services, or all services on the CMD; enabling a specific service, a set of services, or all services on the CMD; or enabling a specific service, a set of services, or all services on the CMD but also delivering a warning to the user via a CMD user interface. In one embodiment, the vehicle operational status, restricted zone, position, and other data transmitted directly to the CMD 25 via an over-the-air connection 40, may operate directly with a specially constructed battery on the CMD, which in turn disables the entire CMD. The special battery (not shown) may be constructed in the same shape, size, and form of a standard battery for the CMD with the addition of internal digital logic which controls the flow of power from the battery to the CMD wherein the digital logic receives the vehicle operational status, restricted zone, position, and other data transmitted via over-the-air connection 40 and decides whether to enable or disable the flow of power to the CMD.
Alternately and/or optionally, the VDS may be connected to the vehicle, e.g., through the OBDII port of the vehicle, which can provide power to the VDS, as well as other information through the vehicle computer information network. Information provided to the VDS through the OBDII port for communication to the Safe Driving Database (SDD) 110 and SDS 125 by transmission wirelessly to the CMD 25 carrier network, or through other wirelessly connected means such as WiFi, either real time, or in a store and forward mode, may include vehicle speed, vehicle location over a segment of travel, vehicle acceleration, information indicative of a hard breaking event, swerving event, hard acceleration event, accident, vehicle power on/off, mileage, vehicle maintenance information, RPM, seat position information and other information available to the VDS through the OBDII port in support of limiting distracted driving, or for other business reasons.
The VDS may be connected to vehicle power, either through a direct connection to vehicle wiring, or through a power outlet in the vehicle. In this embodiment, the VDS is not directly connected to the OBDII port, but captures the vehicle location and speed information from GPS data collected by a GPS chip connected to the VDS, or by using an accelerometer connected to the VDS, or through changes in cell-tower connection data detected by the wireless cell connection within the VDS, or a combination of the above. Detection of motion via the accelerometer may include detection of vibration indicative of engine operation or vehicle movement, or by integration of acceleration data indicative of velocity. In another embodiment of the invention, the VDS is not connected to vehicle power, but is powered by solar cells on the VDS that is connected to a battery that would be charged by the solar cells and allow operation during periods of darkness.
Returning to
The Vehicle Service Provider (VSP) 100 may be operational to deliver the vehicle plus mobile detected information to the Safe Driving Registration System (SDRS) 105 for storage in the Safe Driving Database 110, also included in the mobile services control system 10. The SDRS 105 may be provided by the Vehicle Service Provider (VSP) 100, the Mobile Device Service Provider (MDSP) 130, or a third-party service provider as one skilled in the art will understand. The SDRS 105 may store the vehicle plus mobile detected information in a data management system 110, also denoted herein as the Safe Driving Database 110, which may be considered as a component of the system 10 in at least some embodiments. Note that the Safe Driving Database 110 may also contain, but is not limited to, information identifying each subscriber subscribing to the services provided by the mobile services control system 10, registration information identifying the Vehicle Detection System (VDS) 30 for a specific vehicle managed/owned by the subscriber, registration information identifying one or more mobile devices 25 for this subscriber, customizable service control settings (e.g., allowed or restricted services, time-of-day controls, report options, etc.), game parameters including rewards, discounts, locations of redemptions, pre-chosen user identified categories and awards, and information that describes subscribers to the SDRS 105 (e.g., name, address, etc.). Subscribers subscribing to the services provided by the mobile services control system 10 include, for example, parents who register a vehicle 15 for a teenage child and equip it with the VDS 30 to disable use of the teen's CMDs 25 within that vehicle. Note that other entities may access the subscriber data within the Safe Driving Database 110. These other entities may include, for example, one or more Mobile Device Service Providers (MDSP) 130 which provide mobile wireless services (e.g., voice, text messaging, email, Internet access, gaming, etc.) to, e.g., a teenager's CMD 25. Note that in at least some embodiment of the mobile services control system 10, such providers 130 are not part of the system 10, but instead, are necessary for the operation of the system 10.
In addition, the Safe Driving Registration System (SDRS) 105 may be operational to provide user interfaces, such as, for example, Internet web-based interfaces 115 for users (e.g., subscribers to the services provided by the mobile services control system 10) to configure data monitoring, rewards, discounts and service control settings for the one or more vehicles 15 and one or more CMDs 25 such users manage. The service control settings may define which mobile services (e.g., voice, text messaging, email, Internet access, gaming, etc.) to allow and which to disable under which conditions (e.g., when the vehicle is moving). Alternately and/or optionally service control settings may be provided as part of the Service Decision System 125 (
In one embodiment, the Safe Driving Database 110 (and/or the SDRS 105) is configured to generate a score, e.g., game score, based on one or more of the following; did the driver self-identify themselves during the trip as a driver, frequency of use of one more services of the CMD, location of vehicle, acceleration, deceleration, number of perfect distance segments (number of times a predetermined distance was driven without an event indicating distracted) that satisfy a predetermined criteria, e.g., without using one or more services on the CMD that could be distracting, that the driver did not override the distracted driving control system, that they handled the CMD a certain way, or a certain number of times, that they pressed button on the CMD a certain amount of times, number of times one or more services of the CMD is overridden, power of the CMD, e.g., off or one, use and/or movement of CMD, e.g., was a text looked at or answered or usage, was the phone answered or usage, fuel economy of travel and combinations of the same. The game score can also be based on the number of perfect distance segments driven in sequence (a streak), so that the longer the streak, the greater the score, or score multiplier. The Safe Driving Database may also be configured to allow team competitions to occur, where multiple drivers can combine their scores to compete against other groups of multiple drivers, the groups being chosen by the drivers or by a third party. The Safe Driving Database 110 (and/or the SDRS 105) is configured to communicate with the internet, e.g., social media including Twitter, Facebook, Advertiser, e-commerce, and the like, thereby allowing a subscriber, user or third-party to post the score, results, team results, notification of team rewards, provide discounts, provide awards, team competitions, leader boards and the like.
In one embodiment, the Safe Driving Database 110 (and/or the SDRS 105) may be hosted in a network, such as, any location or network site connected to the Internet and independently operated from the VSP 100 and/or MDSP 130. Alternatively, the Safe Driving Database 110 (and/or the SDRS 105) may be hosted at a location or network site administered by a network-based VSP 100, or by a network-based MDSP 130, wherein the Safe Driving Database 110 (and/or the SDRS 105) may be operated by the VSP 100, the MDSP 130, or by a third party. As such, the Safe Driving Database 110 may operate as a national database monitoring and managing all registered vehicles 15 with multiple mobile service providers 130 that are able to access the Safe Driving Database 110. Alternately, the Safe Driving Database 110 may be operated by an independent “third party” company (e.g., a software or insurance company) for a specific set of subscribers, and/or within a specified geographic region, or the Safe Driving Database may be managed and operated by the Vehicle Service Provider (VSP) 100 or the Mobile Device Service Provider (MDSP) 130.
In one embodiment, the Safe Driving Registration System (SDRS) 105 may be implemented as two or more modules, where one or more of those modules is hosted on a subscriber's computing platform, such as, for example, a home personal computer, a subscriber's mobile device, or some similar platform, and with one or more other modules hosted in a service provider 130 network. This arrangement allows distributed report and control management from a remote subscriber computer. In yet another embodiment, all modules of the SDRS 105 may be located on a subscriber computing platform.
In one embodiment, the registrations of one or more CMDs 25 are associated in the SDRS 105 with the registration of the VDS 30 for a specific vehicle 15. The mobile services control system 10 may simply be operable to control services (enable or disable) on the one or more registered CMDs 25 whenever motion is detected by the VDS 30 in the associated vehicle 15, or alternately stated, the system 10 does not detect the presence or position of a CMD 25 within the registered vehicle 15, and instead assumes that services on the one or more registered CMDs 25 should be disabled whenever the vehicle 15 is in motion. With this configuration of mobile services control system 10, there may be situations where the subscriber to the mobile control services system 10 knows that the user of CMD 25 (e.g., their teenaged child, or their employee) will not be using the associated vehicle 15 (registered through the vehicle's VDS 30) on a particular day, or during a particular time. In such situations, the vehicle 15 may be used by another person and may be moving while the subscriber knows the registered CMD 25 is not in the vehicle 15. A similar situation may arise when the subscriber and user are one in the same person and that person drops their vehicle 15 off at an auto repair shop for work during the day and takes their registered CMD 25 with them. Throughout that day the vehicle 15 may be driven by repair shop personnel, but the CMD 25 is with the subscriber/user where it is desirable to allow full use of the CMD 25 services.
Alternately and/or optionally, the mobile services control system 10 may be operational to provide an override function to the subscriber or user of the mobile services control system 10 which allows the subscriber or user to temporarily override the control of services on the CMD 25 by selecting an option via a user interface 115 (e.g., an Internet web interface, a mobile device interface, some other computer interface, etc.), or via an option displayed on the CMD 25. Alternately and/or optimally, the override may be initiated by the user of the CMD 25 by sending a simple text message or voice message to a specified number designated by the Service Decision System 125, or alternately, the Safe Driving Registration System 105 to receive override messages, such message initiating the override for a specific amount of time specified by the user of the CMD 25 via the message. In such a case, the Service Decision System 125 or alternately the Safe Driving Registration System 105 may send an email or voice or text alert to the subscriber of the mobile services control system 10 that may also include information of the times that the associated vehicle 15 was in motion in relation to the time of the override. These text alerts then provide a method for the subscriber to change the configuration of the mobile services control system 10 to disallow user of CMD 25 to self-generate override messages if this feature is being abused. Alternately and/or optionally, in one embodiment, when: (i) the VSP 100 and MDSP 130 are operated by the same business entity, and wireless networks 45 and 60 are one in the same network (or substantially so), or (ii) the VSP 100 and MDSP 130 are different business entities but are sharing information to support increased operability of the Mobile Services Control System 10, then in either case, information related to the location of the base stations in wireless communication with the CMD 25 and VDS 30 (e.g., base stations 70 and 55 in
In one embodiment of the mobile services control system 10, the Services Decision System 125 may be operational to receive the vehicle plus mobile detected information (e.g., vehicle operational status, CMD position information, CMD use information, override, self-identification, auto-identification, restricted zone data, etc.) and service control settings (e.g., subscriber service selections, awards, discounts, subscriber preferences, service provider options, etc.) to determine for each managed communication service whether to enable or disable the service. The vehicle plus mobile detected information may be received by the Service Decision System 125 periodically at set intervals or in a real-time near-continuous stream of data. A high level flowchart of the processing performed by the Service Decision System 125 is described herein below, and illustrated in
In one embodiment, the Service Decision System 125 may be operational to connect with the Mobile Device Service Provider (MDSP) 130 or third-party source to receive the vehicle plus mobile detected information from the MDSP via the Vehicle Service Provider (VSP) 100 from the Safe Driving Registration System (SDRS) 105 where the vehicle plus mobile detected information is stored in the Safe Driving Database 110. Data is transmitted to and from between the MDSP 130 and VSP 100 via a direct connection 145 when a compatible data format and signaling interfaces exist, or alternately/optionally via Service Provider Interworking function 140 when some type of data format or signaling conversion is necessary. The vehicle plus mobile detected information may be transmitted based on service provider access parameters by periodic polling and “pull” requests from the MDSP 130 to the Safe Driving Registration System (SDRS), or based on event-driven “push” transmissions from the SDRS 105 to the MDSP 130. In one embodiment, these vehicle plus mobile detected information is transmitted in a real-time data stream to allow real-time control of the plurality of services on each CMD 25 as it is moved in and out of the restricted zone in the vehicle occupant enclosure 20. In this later configuration, the Service Decision System 125 forwards the determinations it makes (e.g., to enable or disable a specific service) on to the MDSP 130 which, in turn, may enable or disable one or more of the services on the CMD 25. Further, in this configuration, the Service Decision System 125 may be physically hosted by the MDSP 130 in the MDSP's network, or hosted by a third-party service provider, which may, or may not, be the same service provider hosting the Safe Driving Registration System (SDRS) 105 and/or Safe Driving Database 110.
Alternately and/or optionally, the Service Decision System 125 may be operational to connect directly via communications path 120 and/or path to user interfaces 115 to the SDRS 105 to receive the vehicle plus mobile detected information from the SDRS 105 without transiting the VSP 100 and MDSP 130. In this configuration, data may still be transmitted between the SDRS 105 and Service Decision System 125 using a polling (“pull”), or event-driven (“push”) method, or real-time near continuous stream. In this configuration, the Service Decision System 125 forwards the determinations it makes to enable or disable a CMD 25 specific service to the SDRS 105 which sets an enable/disable flag for each such service in the SDRS, which the MDSP 130 is then operational to query that flag via a “pull” request or “push” notification. Further, in this configuration, the Service Decision System 125 may be physically hosted by the same service provider hosting the Safe Driving Registration System (SDRS) 105 and/or Safe Driving Database 110, or possibly by a third party service provider.
The Service Decision System 125 also provides a user interface 115 (e.g., a computer software interface, an Internet web interface, a mobile device interface, or some other user interface) for subscribers, users or third parties to view and manage their service control settings, for administrators of the Mobile Device Service Provider (MDSP) 130 to manage operational settings, scoring parameters, e.g., game parameters, awards, offered discounts, advertisements, and/or for administrators of the SDRS 105 to manage operational parameters.
Disclosed in
The implementation of the Controllable Mobile Device (CMD) 25 may include an operating system 210 and a plurality of services/applications 205, including, but not limited to, voice, text messaging, video, Internet access, games, and other types of service. The term “service” in the present context, includes interactive mobile communication services, display or output only services, and input only services. The CMD 25 may also include a vehicle wireless network interface 215 which supports a typical wireless local area network (WLAN), for example, Wi-Fi, or some other wireless local network capability, like, for example, femtocell or picocell wireless, Bluetooth, Wireless USB, etc. The vehicle wireless network 215 may be configured for wireless connection to the Vehicle Detection System (VDS) 30, or other wireless devices in proximity to the CMD 25. In addition, as a mobile device, the CMD 25 also provides a service provider wireless network interface 220 which connects the CMD 25 to the Mobile Device's Service Provider (MDSP) 130 (i.e., wireless network 45), shown in
The Vehicle Detection System 30 (VDS) may be operational to detect a Controllable Mobile Device 25 (CMD) through the Mobile Device Air Identifier 200 (
Alternately, the Vehicle Detection System (VDS) 30 and CMD 25 may be operational to use another over-the-air identification and position detection technology other than RFID, such as, using acoustic methods such as ultrasound, using optical technologies such as InfraRed (IR), or other similar technologies for determining the position of the CMD relative to the VDS.
The Controllable Mobile Device (CMD) 25 may further be operational to support control software 225 (
Disclosed in
As disclosed in
Disclosed in
Alternately and/or optionally, the vehicle motion sensor 305 may report the vehicle is in operation to the SDRS 105 based on a combination of current movement or recent movement (e.g., within the past 2-4 minutes, or some configurable amount of time). If the detect traffic option (as determined in step 440) is set in the vehicle motion sensor 305, then the logical combination would prevent intermittent use of CMD 25 services during traffic stoplights, or in stop-and-go congested traffic whereby the vehicle motion sensor 305 would continuously report the vehicle 15 is in operation until it is no longer moving. Recent motion is calculated (step 445) by continually updating a time variable each time the vehicle motion sensor 305 determines that the vehicle is in motion 415 as the difference between the current time and the vehicle last moved time. If the vehicle speed (as determined in step 405) is below the threshold (step 410) and the detect traffic option (as determined in step 440) is on, and the vehicle 15 has not moved recently, then the vehicle motion sensor 305 reports to the VDS detection engine 300 that the vehicle is not in operation in step 435. Otherwise, if the vehicle 15 has moved recently then the vehicle motion sensor 305 reports the vehicle is in operation in step 455.
The vehicle motion sensor 305 may report the raw data including vehicle speed, g-force data, engine power state, the vehicle last moved time, and the detect traffic option to the SDRS 105 via the VSP 100 where the SDRS 105 would be operational to provide the vehicle motion sensor logic to determine whether brief traffic stops or congested traffic constitute that the vehicle is in operation, or not. Alternately and/or optionally, the vehicle motion sensor 305 may only report state changes to the SDRS 105 (e.g., the vehicle 15 is in operation, or the vehicle is not in operation), or the vehicle motion sensor may regularly and periodically report (e.g., every minute, or every few seconds, a real-time stream, or some such appropriate interval) the current status to the SDRS 105. Alternately and/or optionally, the Service Decision System 125 may provide the vehicle motion sensor logic with the raw data transmitted from the VDS 30 to the Service Decision System via the SDRS 105.
Returning to
The Vehicle Detection System (VDS) 30 may also include a detection engine 300 (e.g., a hardware/software configuration of computational equipment) which determines whether a detected Controllable Mobile Device (CMD) 25 is within a restricted zone while the vehicle 15. In one embodiment the detection engine 300 is in communication with one or more of a plurality of position detectors and/or sensors 37, 38, 39 to receive real-time position information about one or more Controllable Mobile Devices 25. The detection engine 300 also receives motion sensing information from the vehicle motion sensor 305 and possibly engine powered on/off information from the vehicle 15. If the vehicle motion sensor 305 uses an accelerometer to provide motion sensing information, the detection engine 300 may be operational to discern vibrations associated with vehicle motion from other motions caused by other sources such as wind, or movement within the vehicle 15.
In one embodiment, the Vehicle Detection System (VDS) 30 may receive motion sensing information from the CMD 25, via the Mobile Device Service Provider (MDSP) 130, which may include, but is not limited to, a GPS capability built-in to the CMD, or motion determination by the MDSP wireless network, such as, for example, triangulation of signals between multiple cellular radio frequency towers, or other means available in the MDSP to determine motion of the CMD. In one variation of this embodiment, the motion sensing information is determined by the MDSP 130 and relayed via the Vehicle Service Provider (VSP) 100 over wireless connection 65 to the VDS 30, where the MDSP and VSP may be the same network service provider. In another variation, the motion sensing information may be relayed by the MDSP 130 back to the CMD 25 via wireless connection 50 and then transmitted by the vehicle wireless network 215 on the CMD to the vehicle wireless network 310 on the VDS.
The detection engine 300 further may be operational to provide the ability to define a “restricted zone” within the vehicle wherein CMDs 25 are detected and possibly services on the Controllable Mobile Device (CMD) are disabled. In one embodiment, such a restricted zone is configurable by the person who installs the Vehicle Detection System (VDS) 30 or possibly by the subscriber. The detection engine 300 of the VDS 30 may provide a wired configuration port 330, such as, for example a serial port, a USB port, or similar interface technology, to allow a computational device, such as, for example, a personal computer, a notebook computer, a PDA, or even a mobile phone, to connect to the detection engine and provide a user interface 340 of a communication 335 via a wireless network for configuring the restricted zone. The user interface (UI) may be graphical, or numerical, or some such appropriate UI. The connection between the detection engine 300 and the computational device may be wired or a wireless connection, and it may use the vehicle wireless network interface 310, for example a Wi-Fi connection. Alternately and/or optionally, the detection engine 300 may provide a default restricted zone.
The Vehicle Detection System (VDS) 30 may further be operational to provide a Detection System Air Identifier 325. The VDS can include data storage 320. In one embodiment the Detection System Air IDentifier 325 includes a Radio Frequency IDentifier (RFID) transponder or tag. The one or more position detectors and/or sensors 37, 38, 39 may be operational to read the Detection System Air IDentifier to verify that the Detection System Air IDentifier is readable, thereby deducing that the VDS base unit 35 (
Alternately and/or optionally, the VDS 30 may be operational to detect and identify a Controllable Mobile Device (CMD) 25 via one or more wireless signals from the CMD 25. This includes, but is not limited to, detection and identification via the local area vehicle wireless network capability 310 in the VDS 30 and corresponding local area wireless network capability 215 in the CMD 25 over wireless connection 40 wherein the presence of a specific CMD 25 may be detected and identified. Alternately and/or optionally, the VDS 30 may be operational to receive and connect with the wireless network signal 50 (e.g., the cellular or some such similar technology) from the CMD 25 intended for the MDSP 130 service provider through the MDSP's wireless network 45 wherein the VDS 30 may be operational to have the necessary encryption codes and wireless signaling technology to read the wireless network signal 50 and through that signal identify the specific CMD 25.
The VDS base unit 35 configuration of the Vehicle Detection System (VDS) 30 may include the detection engine, 300 vehicle motion sensor 305, Detection System Air IDentifier 325, vehicle wireless network 310, and service provider wireless network 315 components or functions. The VDS base unit 35 may also include one of the position detectors 37, 38, 39.
As described above, the Vehicle Detection System (VDS) 30 may yet be operational to provide one or more position detectors and/or sensors 37, 38, 39. In one embodiment, each position detector 37, 38, 39 includes a Radio Frequency IDentifier (RFID) reader. Each such RFID reader transmits a signal 380 wirelessly which any of the RFID tags in the area pick-up and in turn each tag transmits it's ID number, and possibly other data including driver ID, back to the reader. Passive tags use the signal from such a reader to generate enough power for the tag to transmit the response. The VDS 30 may provide one or more RFID readers as position detectors and/or sensors 37, 38, 39. A configuration of one reader could be placed in the dashboard area of a vehicle and provide approximately a circular detection area as the restricted zone. In this implementation the single position detector 37 (one RFID reader) may be implemented in the same component (a single “pod”) along with all of the other VDS functions described above. Alternately, or in addition to, the single position detector 37, could be implemented in a separate physical component from the other base unit VDS 35 functions.
Additional position detectors and/or sensors 38, 39, for example, a total of three detectors and/or sensors 37, 38, 39 placed at appropriate distances from one another, may allow the detection engine 300 of Vehicle Detection System (VDS) 30 to triangulate the exact position of a CMD 25, by comparing relative response signal strengths, and thereby determine whether it is within a restricted zone. The triangulation logic employs standard algorithms to calculate a more accurate position of the CMD 25. In one embodiment, the VDS 30 may use one or two detectors and/or sensors 37, 38, 39 to determine the approximate position of the CMD 25 by also detecting the relative strength of the RFID signals with respect to the known location of the detectors and/or sensors 37, 38, 39, and thereby approximate whether the CMD is within the restricted zone. The VDS 30 may support more than three position detectors and/or sensors 37, 38, 39 depending on the position accuracy needed and the size of the vehicle.
Each position detector 37, 38, 39 may be connected to the VDS base unit 35 by a wired connection 345, 350, 355 for transmitting detected information to the detection engine 300 along with providing power to each of the remote position detectors and/or sensors 37, 38, 39. Alternately, each position detector may provide its own vehicle wireless network interface, such as, for example, Wi-Fi, to transmit data wirelessly 345, 350, 355 to and from the VDS base unit 35. The connections 390, 380 and 385 may be wireless or wired as described herein to a transmitter/receiver 395. Wireless position detectors and/or sensors 37, 38, 39 may receive power from some other source, such as, for example, batteries, solar power, wireless power, wind power through vehicle movement, or other power sources.
Further, each position detector 37, 38, 39 may also be configured with a Position Detector Air Identifier 360, 370, 375, such as, for example, an integrated RFID tag, within the detector which is configured to respond to the queries of other detectors and/or sensors (e.g., RFID readers). At the same time, each position detector is configured to ignore it's own Position Detector Air Identifier.
The Vehicle Detection System (VDS) 30 may additionally be operational to detect wireless signal 380 from one or more Controllable Mobile Devices 25 in parallel within the restricted zone and to process that data through the detection engine 300 and to transmit that data to the VPS 100 via the service provider wireless network 315 interface in an interleaved, virtually simultaneous fashion.
In one embodiment, the Vehicle Detection System (VDS) 30 may use other technology methods to detect the position of one or more CMDs 25 within a restricted zone. These include, but are not limited to, detecting the strength of an electromagnetic signal from the CMD 25, such as, for example, a radio frequency signal, which may emanate from the Bluetooth or Wi-Fi capability on the mobile device, or from the cellular signal of the mobile device, or from a different electromagnetic signal source on the CMD 25.
In a further embodiment, the detection engine 300 of the Vehicle Detection System (VDS) 30 may compare the absolute position of the Controllable Mobile Device (CMD) 25 to the absolute position of the VDS base unit 35 to determine if the CMD is within the relative boundary of the restricted zone. In this configuration, the absolute position of the CMD 25 may be determined by multiple methods, including, but not limited to, the Mobile Device Service Provider (MDSP) 130 using the signal strength from its wireless network base stations 55 to triangulate the position of the CMD, or by a GPS location capability built-in to the CMD 25 in operation with a GPS network and the MDSP 130. Further, in this configuration, the absolute position of the VDS 30 may be determined by multiple methods, including, but not limited to, the Vehicle Service Provider (VSP) 100 using the signal strength from its wireless network base stations 70 to triangulate the position of the VDS 30, or by a GPS location capability built-in to the VDS 30 in operation with a GPS network and the VSP 100. Both the MDSP and the VSP, or the GPS network, are operational to transmit the determined absolute position, probably stated in geographical coordinates, to the VSP via wireless network connection 65 where the detection engine compares the absolute positions of the CMD 25 and VDS 30 with the relative boundary of the restricted zone.
In yet another embodiment, the Vehicle Detection System (VDS) 30 may detect a CMD 25 through conduction of an electrostatic charge by the user holding the mobile device and touching the steering wheel, or similar part of the vehicle in the driver's seat, thereby creating an electrostatic connection leading to the deduction that the driver user is holding the mobile device within the restricted zone.
Disclosed in
The safe driving engine 500 is also operational to transmit information from the Safe Driving Database 110 to the Mobile Device Service Provider (MDSP) 130 via the Vehicle Service Provider (VSP) 100 through various land based and wireless based communication networks and/or to receive information from the MDSP 130 which may include, for example, usage data for specific mobile services. With mobile usage data, the safe driving engine 500 may correlate that data with vehicle operational data and, possibly CMD 25 restricted zone position data, and/or perform other calculations on the data.
Disclosed in
Alternately and/or optionally, the Service Decision System 125 may be in direct communication 120 with the Safe Driving Registration System (SDRS) 105 to receive the vehicle plus mobile detected information.
The service decision engine 600 may also be operational to receive input service control settings 605 which may include, but are not limited to, parameters defined by state or local laws, parameters set by the Mobile Device Service Provider (MDSP) 130, parameters set by individual subscribers for all users of CMDs 25 for the subscriber, parameters of a game, or awards, or discounts and/or individual users within a group managed by the subscriber. The service control settings 605 may include, but are not limited to, parameters that define which service the service decision engine 600 controls for which users (e.g., voice calls, text messaging, video calls or messaging, Internet access, games, etc.); how those services are controlled (e.g., disable the service when the vehicle is operational, disable the service when the Controllable Mobile Device (CMD) 25 is within the restricted zone, enable the service when the CMD moves outside of the restricted zone, enable the service when the CMD is within the restricted zone but send a warning or reminder message to the CMD, as well as other possible control scenarios); what time frames some services may be enabled or disabled, as well as other control preferences.
Further, the service control settings 605 may be stored and managed in operations with the service decision engine of the Service Decision System 125, or in direct operation with the SDRS 105.
Disclosed in
In one embodiment, the service directive is transmitted in a real-time or near-continuous stream to the MDSP 130 or SDRS 105, or alternately could be stored and forwarded in some other timing arrangement.
Alternately, the Service Decision System 125 and service decision engine 600 may be provided in any other suitable component of the mobile service control system 10, including, but not limited to, the mobile device control software 225 of the CMD 25 (as illustrated in
Disclosed in
Referring again to
Disclosed herein is another embodiment of the mobile services control system 10 that is well suited for vehicles 15 that are primarily operated by a single driver-operator, or driven or operated by multiple driver-operators who are scheduled so that at any particular time, the driver-operator of a corresponding vehicle 15 is known with high confidence (e.g., commercial drivers of vehicles such as trucks and taxi cabs, operators of public transportation such as buses or trains, and drivers of government vehicles). Since such a driver-operator of a vehicle 15 is often the primary user of a unique CMD 25 or unique CMDs, knowledge of the motion of the vehicle 15 in conjunction with knowledge of the operator of that vehicle (perhaps at a specific time) in conjunction with knowledge of a unique identifier of the operator's CMD 25 (such as a cell phone number of the CMD(s), or Mobile Device Air Identifier of the CMD(s)), enables the Mobile Services Control System 10 to provide notifications to appropriate wireless carrier network equipment for activating and/or deactivating CMD services (e.g., texting, etc.). In particular, such activation and/or deactivation may be substantially solely dependent upon a determination of whether the vehicle 15 is moving. In this embodiment, the Safe Driving Registration System 105 (
Referencing
Referring to
In a preferred embodiment, only a single CMD is associated or registered to a VDS. Alternatively or optionally, more than one CMD may be associated or registered with a VDS or vehicles. Moreover, the association of a CMD may change over time according to a predetermined schedule. For example, on a Monday a first CMD may be associated with a VDS or vehicle, on Tuesday a second CMD (adding or deleting the association of the first CMD) may be associated with the same VDS or vehicle, and so on. In addition, more than one CMD may be associated with a VDS or vehicle for a business. Also, every CMD in a particular area may be associated with a VDS or vehicle as needed. Also, every CMD associated with a specific MDSP may be associated with a specific VDS, or multiple VDSs.
In one embodiment, SDS 125 is configured to use one or a combination of location, location error, velocity direction of travel, the location of cell towers connected to a particular CMD 25 or VDS 35 and time since start of trip to determine the probability of a CMD 25 being in a vehicle. This data may be obtained from the CMD 25, VDS 35, and/or Vehicle 15 by either an electronic query from the SDS 125 (pull) or by data provided to the SDS 125 without query as part of the operation (push), or by other techniques known in the art. Electronic query means communication between two components (hardware, software and/or combinations), e.g., including but not limited to any connection between devices such as over a wireless network, wired network, or other communication mechanism.
In one embodiment, the location of CMDs 25 that have been previously identified as possibly being used by a driver of a particular vehicle containing a VDS 35, e.g., a registered CMD associated to a specific driver, can be combined with the location of the VDS 35 in the Vehicle 15, and the estimated or calculated errors in each of the location measurements, and other data as such listed above to establish which of the CMDs are likely within the vehicle, and therefore could potentially distract the driver of the vehicle.
Moreover, in one embodiment the SDS 125 is operable to send a signal to MDSP 130, to the CMD 25 via the MDSP 130, or to third party providers that can control functionality of the CMD 25 The MDSP 130 is operable to send a disable signal to a predetermined CMD 25 or to disable or partially disable operation of a predetermined CMD 25. By way of definition, the term disable and partially disable shall be used interchangeable throughout the application, and shall mean to completely or partially limit the functionality of a CMD. The term disable signal shall mean a signal that provides notification that a CMD should be partially or fully disabled as used throughout the document. The disable signal can be emitted from any component or module of the system as described herein. Third-party providers are operable to provide a disable signal to the CMD 25 or to disable or partially disable operation of a predetermined CMD 25 on receiving a disable signal from the SDS. The CMD 25 may be operable to disable or partially disable potentially distracting functions on receiving a disable signal from the SDS 125, MDSP or third party provider.
In another embodiment, when the CMD may possibly not be operable to be disabled or for other reasons may be desired to not be disabled, the disable signal for a specific CMD shall be recorded in the SDD along with the time it was sent, the identity of the CMD and the identity of the associated VDS, and other related information to allow a comparison with usage records for that CMD, provided by the MDSP, or another third-party provider of services to the CMD, so as to provide a record of when the CMD was used while the vehicle was in a potentially unsafe state, and optionally to provide alerts of potentially unsafe CMD use. In embodiments of the invention, upon an enabling event or disabling event such as sending a disable signal or disabling a CMD, the following information is optionally simultaneously recorded in the SDD including at least the time of disable signal, identities of VDSs, CMDs and drivers, and other information related to the event.
In operation, various information, e.g., velocity, location, location error, direction of travel of the vehicle can be obtained directly from the VDS 35 using techniques such as vehicle GPS data, and velocity data from a GPS chip integral to the VDS 35. This information may also be obtained through sensing change in velocity from an accelerometer imbedded on the VDS 35, accelerometers in the vehicle, from vehicle information (such as speed) provided to the VDS through various means, or from velocity information provided by CMDs known to be within the vehicle, e.g., by GPS data or accelerometer data provided by the CMD 35 within the vehicle. Optionally, the VDS 35 may be connected to an OBDII port or other port in the vehicle to provide data from vehicle sensors.
Referring now to
MCBL information is a predetermined geographic location such as a home or place of business, where multiple drivers share a vehicle and therefore a given vehicle associated with a VDS, may have any one or more drivers with registered CMDs associated with the VDS be within the vehicle or driving the vehicle on trip start. In this case the SDS, is operable to discriminate which registered CMDs are in the vehicle from those not in the vehicle but potentially proximal to the MCBL. A VDS is associated or registered with one or more MCBLs, so that any given car at one of these locations may have one of a finite number of possible drivers.
SCBL information is a predetermined geographic location such as a home, place of business, school, or shopping center, or similar location where it is probable that only one driver associated with one or more CMDs is driving a vehicle associated with a VDS on trip start. The VDS is associated or registered with one or more SCBL, so that the driver of the vehicle can be quickly identified.
MCBL and/or SCBL information may be assigned via a User Interface 115 by a user or third party. The MCBL and/or SCBL information includes user information, VDS identities associated with the location, associated driver identities, associated CMD identities, physical addresses or GPS locations associated with a list of places, e.g., home, business, gym, shopping, schools, resorts, other locations of interest and optionally additional information may also be associated to the MCBL and/or SCBL information including but not limited to the probability that specific drivers may be driving the vehicle when starting from that location. In a preferred embodiment, MCBL and/or SCBL information is stored in the SDD 110.
Moreover, the SCBL or MCBL information may be acquired automatically by system 1100. The determination of SCBLs and MCBLs associated with a given VDS and CMDs can be inferred over time from previous trips, by establishing which CMDs are in the vehicle at a particular location on trip start by other means described herein. When the probability of a particular CMD being within a vehicle on trip start from a specific location, or is determined to be above a predetermined threshold, the associated location can be identified as an SCBL or MCBL for that VDS and CMD(s). In the instance when only a single CMD is likely to be within the vehicle from that trip start location it can be defined as a SCBL. Alternately, the location may be defined as an MCBL for a given VDS and a group of CMDs, when there is a likelihood that there are one of several drivers within the vehicle at trip start. The location information is added to the SDD 110 and associated with the particular MCBL and/or SCBL information.
Referring again to
After determining whether the VDS is associated with a SCBL, MCBL or neither, the geographic location of the VDS is acquired (Step 1104). The geographic location of the VDS may be determined by deriving information from the carrier network related to the VDS 35, such as the location of the cell tower 55, 70 that the VDS 35 is connected to, triangulation of cell tower signals that the VDS 35 is connected to, location information provided wirelessly from a GPS device within the VDS 35, time of flight methods of determining location from the VDS signal, various techniques used for e911 emergency location of a mobile device, information captured on the VDS 35 with respect to cell tower connection information and relative signal strength from various cell towers, and assisted GPS (aGPS) enabled on the VDS 35, other technique described herein throughout, or other techniques as known in the art. In a preferred embodiment, the geographic location of the VDS is determined by accessing the last location of the VDS stored in the SDD 110.
After the location of the VDS has been determined go to step 1106 if the desired VDS is associated with a SCBL. Step 1106 requires the system to disable the CMD associated or registered with SCBL information. The disabling of the CMD may be conducted as described herein. Optionally, a verification step 1108 may be performed.
The verification step 1108 includes determining the location of the disabled CMD, and optionally other CMDs associated with the VDS, and comparing it with the location of the VDS. This location of CMDs may be obtained from a pull query or push query of the CMD via the system 1100 or with other techniques described herein. Typically, this is a low cost method, such as using cell tower information, or information provided by a GPS-equipped CMD, either through push or pull techniques. Alternatively or optionally, the location of the CMD may be obtained with high cost location method, e.g., directly from a network, data provider, third party as a charged service.
The VDS location and CMD location are compared to establish if the distance between them is within the predetermined threshold error distance (PTED. The PTED is related to the accuracy of the location information, and is typically less than 200 meters for GPS data, is typically less than 3000 meters for cell tower location techniques in rural areas with large distances between cell towers, and may be less than 500 meters in urban areas with small distances between cell towers. Of course this PTED can change depending on the accuracy of the CMD location and/or VDS location. The more accurate the CMD location and/or VDS location the shorter the PTED can be set. That is, if the accuracy from both the CMD and VDS are within 5 meters or less, then a 10 meter PTED can be used. Alternately, as the accuracy of CMD location and/or VDS location lessens, the greater the PTED.
The verification step 1108 is a double check that is optionally performed to confirm that the disabled CMD is within a vehicle and other associated CMDs are not. If the locations of the CMD and the VDS when compared indicate a distance less than the PTED threshold step 1106 the CMD remains disabled and other CMDs identified to be within the vehicle are disabled, if the location of any associated CMDs and the VDS when compared are greater than the PTED then the CMD can be enabled (while other previously disabled CMDs remain disabled). Alternately a disable signal can be sent when the distance between the CMD and VDS are such that when accuracies in location measurement are considered and optionally combined with other information described herein, there is a high probability that the CMD is within the vehicle although the location information alone does not confirm the CMD is in the vehicle.
Optionally, after step 1102, previous trip information is provided by SDD 110 on a query from SDS 125, including the identity of CMDs within the vehicle at the end of the previous trip associated with the VDS, (as also described in step 1114 below). If this information indicates that a single registered CMD is different than that typically associated with the SCDL was in the vehicle, then it is probable that the CMD in the vehicle on the previous trip is within the vehicle at the start of trip, and therefore step 1106 is performed with the CMD identified from the previous trip, rather than with the CMD associated with the SCBL. Similarly if multiple associated CMDs are identified as having been in the vehicle on the previous trip, the trip is treated as starting from a MCBL (as described in step 1110 below) with the CMDs associated with the start of trip location as if the location was a MCBL, being those identified as being within the vehicle on trip end.
If the desired VDS is associated with MCBL information, go to step 1110. Step 1110 requires the system 1100 to obtain the location of each of the multiple CMDs associated with the MCBL and VDS. The location of each of these CMDs may be obtained from a pull or push query of the CMD as described herein. Typically, this is a high accuracy method. Alternatively or optionally a low accuracy location may be obtained from cell tower information or other low accuracy, low cost means, or other means can be used to determine if a registered CMD is in the vehicle or outside of the vehicle.
The location of each CMD is compared to the starting location of step 1104 and the VDS location. The location of the CMDs and VDS associated with that MCBL are determined by means described herein. If the error in the CMD and VDS location measurement allows discrimination of CMDs in the vehicle from those remaining at the MCBL, then the SDS proceeds to step 1112. Alternately the SDS can utilize a Predetermined Threshold Distance (PTD), which is a threshold distance between a VMD and a base station that given typical CMD and VMD location accuracies have a high probability of enabling discrimination of CMDs remaining at the base from those in a vehicle. The PTD is typically greater than 100 meters with GPS-based location measurements. Of course this PTD can change depending on the accuracy of the CMD location and/or VDS location. The more accurate the CMD location and/or VDS location the shorter the PTD can be set. That is, if the accuracy from both the CMD location and/or VDS location is 5 meters or less than a 10 meter predetermined threshold distance can be used. Alternately, as the accuracy of CMD location and/or VDS location worsens, the PT can be set to greater values to take in account the increased likely error of location. By way of example, the PTD may be greater than 500 m in urban areas with a high cell tower concentration when a non-GPS cell tower-based location is used, and greater than 3000 m in rural areas of low cell tower concentration when cell tower-based location is used.
If the CMD and VDS location error is so large as to not allow discrimination between CMDs located at the MCBL from CMDs in the vehicle, then the SDS waits a predetermined amount of time and step 1110 is repeated and the location of the CMDs and the VDS again compared. This step can be repeated until there is sufficient distance between the VDS and the MCBL to discriminate associated VMDs in the vehicle.
Alternately, the SDS may wait a predetermined time after trip start to determine location of the CMDs and VDS, so as to allow sufficient time for there to be adequate distance between the VDS and the MCBL to discriminate the location of CMDs in or out of the vehicle. The predetermined amount of time may be in a range from less than 15 seconds to five minutes or greater. This time may be set by the user interface 115 as a criteria in the MCBL information and stored in the SDD 110, or be a default amount. Once there is sufficient distance between the VDS and MCBL, the CMDs within the vehicle, as described herein, are disabled (Step 1112).
If the desired VDS is not associated with either a SCBL or MCBL go to step 1114. On trip start, the SDS queries the SDD for the most recent location of the CMDs registered to the VDS. The CMDs that were determined to be within the vehicle in the previous trip, are considered to be potentially within the vehicle for the current trip. CMDs that were not in the vehicle at the end of the previous trip are assumed to not be in the vehicle. Similarly, any registered CMDs that were in the vehicle during the previous trip, but whose last known location is such that they could not be in the vehicle at the beginning of the trip, are considered to not be in the vehicle (for instance, a registered CMD that had a location 30 miles from the VDS 15 minutes prior to the start of trip, would be considered to not be in the vehicle, as it would have to have travelled at 120 mph to be in the vehicle). Next, the CMD or CMDs that are considered to be in the vehicle are disabled. (Step 1116). Optionally, a verify step 1108 may be performed as previously described herein.
In one embodiment, the SDS is operable to receive information as to the identification and location of the cell tower that a given registered CMD is connected to, and thereby determine when the CMD switches its connection from one tower to another, thereby indicating that CMD is in motion providing additional information that allows the SDS to determine there is an increased probability the CMD is in a vehicle if the associated VDS has also been determined to be in motion, increasing the ability of the SDS to quickly discriminate CMDs within or separate from the vehicle. Alternately, as the SDS receives information that the CMD has not switched to a different cell tower although the associated VDS is in motion for a period of time, the SDS can determine that it is less probable that the CMD is in the vehicle, increasing the performance of the SDS in a similar way.
In addition, velocity information of the CMDs that is provided through various means such as GPS and network based velocity determination means can be used to aid in discriminating CMDs that could be in a moving vehicle from those that are stationary and therefore not in a vehicle. For example, if it is determined that the VDS is in motion, and a CMD associated or registered with a VDS is not moving, it can be inferred that the CMD is not in the moving vehicle and should not be disabled, and similarly the probability that the other CMDs associated with the vehicle is raised allowing potentially a more accurate or more timely determination of which CMD should be disabled.
Similarly, if the velocity of associated or registered CMDs differs from the velocity of the VDS it can be inferred it is not in the associated vehicle, or, if it matches the velocity of the VDS it is likely in the vehicle. Similarly, the direction of the velocity of either the VDS or the CMD can also be used to further clarify the velocity information and infer if a CMD is in a target vehicle or not depending if the direction of velocity of a CMD matches that of a VDS or not.
In one embodiment, location information from previous trips may be used to improve the ability of the SDS to identify if a CMD is in a vehicle as described previously. This information may be stored in a memory, e.g., the SDS 125, SDD 110 or both. The location of a MCBL or SCBL, may be provided by the subscriber via the SDRS 105 and stored in the SDD 110, or this location may be inferred by the SDS from data from previous trips. By way of example, if location information indicates that a high percentage of trips starting from a particular geographical location are determined to occur with a specific CMD in a vehicle associated with a VDS, then it can be inferred that location is a SCBL associated with that specific VDS and CMD, and similarly if previous trip information captured by the SDD and or SDS indicates that multiple CMDs are associated with a vehicle VDS are present in trips that start from that location, or that CMDs associated with the vehicle are frequently at that location, then it can be inferred that that location is a MCBL for that VDS and CMDs. As described elsewhere, this information can then be used by the SDS to calculate the probability that a specific CMD is in a vehicle at trip start independent of CMD location information, thereby improving the ability of the SDS to quickly determine which CMDs to disable.
In one embodiment, on trip start the SDS is operable to compare the trip start location for a vehicle associated with a VDS (determined either from the location captured at the end of the previous trip, or from location information provided by the VDS at trip start) with the location of a MCBL associated with the VDS, and in the case where the location of trip start is distant from the MCBL, the SDS is operable to determine that there is a high probability that the CMD in the vehicle during the previous trip is the CMD in the vehicle at current trip start, thereby allowing an immediate disable signal to be sent, or in other ways increase the effectiveness of the SDS by increasing the effectiveness of discrimination.
In one embodiment, on trip start the SDS is operable to compare the location of the VDS on trip start with the geographical location associated with a SCBL for that VDS, allowing the SDS to determine there is a high probability that the CMD associated with that SCBL and VDS is within the vehicle, thereby allowing an immediate disable signal to be sent, or in other ways increase the effectiveness of the SDS by increasing the effectiveness of discrimination.
In one embodiment, on trip start the SDS is operable to compare various CMDs last known locations with the time and geographic location of a trip start in order to establish on trip start whether a particular CMD has a low probability of being within a vehicle. In this embodiment, the SDS is operable to calculate the distance between the last known location of a CMD and compare that with a VDS start of trip location, as well as the time of last known location and the time of trip start to thereby calculate the velocity that the CMD would have to have been travelling to be in the vehicle at trip start, and compare that with a threshold velocity to establish the probability that the CMD is within the vehicle. By way of example, if fifteen minutes prior to the start of a new trip, an associated CMD was identified to be 30 miles away from the VDS there is a low probability that CMD can be in the vehicle as the CMD would have to have been travelling at 120 mph to be in the vehicle. Thereby, establishing the CMD does not require disabling, and increasing the probability that other associated CMDs may be in the vehicle, thereby increasing the effectiveness of the SDS by increasing the effectiveness of discrimination.
In one embodiment, the SDD may accumulate location information over time from VMD and the CMD associated with the VMD. With this information the SDS may autonomously determine home or base areas, or areas where there is a high probability a trip may start with one of several CMDs, such as a home where all CMDs may be frequently located (a MCBL), or alternately a location where there is a high probability only one CMD is located and therefore a high probability that at trip that starts there is associated with that CMD (a SCBL).
Information recorded in the SDD, e.g., location of VDS, location of CMD, velocity information, direction information, SCBL information, MCBL information, location of CMDs previous trips, e.g., trip ending information, CMDs identified in vehicle on previous trip, can be used to improve the performance of the system and lessen latency, by a) allowing immediate disabling with subsequent verification, b) immediate low-accuracy location information, or immediate high accuracy location information to increase the certainty that a CMD is in a vehicle, or c) lessen the time necessary to make the determination that a CMD is in a vehicle or, d) eliminate the need for location accuracy queries, e) allow the use of a low or high accuracy location information query performed significantly after trip start to provide a check to confirm that a particular CMD is in or out of the car after a more immediate disable signal has been sent to the CMD.
Referring to
The VDS 35 is operable to sense a unique wireless signal (UWS) 1205 from a CMD 25 or plurality of CMDs. In a preferred embodiment, the VDS 35 can be configured with an RF receiver or other type of receiver to receive and interpret the UWS 1205.
The UWS 1205 may be any type of communication signal, e.g., a Bluetooth signal, low energy Bluetooth signal, ZigBee, WIFI or other wireless signal. Sensing of UWS 1205 from the CMD may be closed-loop 1202, in which a handshake type connection is made between the VDS and the CMD (such as a Bluetooth handshake) or open-loop connection 1204, in which the VDS identifies a UWS transmitted from the CMD but does not create a handshake connection with the device.
In one embodiment, the UWS 1205 includes an identifier that is unique to a particular CMD. The identifier may be an encrypted or non-encrypted alpha numeric code that is compatible with an established protocol, e.g., Bluetooth protocol or other IEEE protocol. Moreover, more than one unique identifier may in the UWS 1205, e.g., an established protocol identifier and a priority protocol identifier. In a preferred embodiment, the UWS is the transmission signal from the CMD that is used to communicate with a cell tower and therefore requires no additional transmission capability on the CMD. In this embodiment, the VDS is operable to recognize the UWS as distinct and unique to the CMD. Optionally, the MSDS may provide information to the VDS by various means to enable it to decrypt and or recognize the UWS.
In this embodiment, the VDS 35 is operable to receive the UWS 1205 and interpret the signal so as to be able to identify whether the signal is being transmitted by a specific CMD 25 associated with the VDS 35, and to thereby send a signal to the SDS 125 that a particular CMD 25 is in or proximal to the vehicle. Moreover, the UWS 1205 may be user controlled therefore being able to be disabled by a user, either inadvertently or intentionally, so as to conserve power of the CMD, or to attempt to defeat the system.
Referring to
Next, sensing is performed with the VDS (Step 1222) to determine whether the VDS is in a safe or unsafe state. An unsafe state is a condition in which the user of CMD could potentially be distracted from driving for instance, they are in a vehicle that is or will be moving. Indications of an unsafe state can include information that establishes the vehicle is moving, that a vehicle is above a certain speed threshold, that a key has been turned on, that a battery voltage indicates that a vehicle is prepared to move, that a vehicle is in a location such as on a highway, engine RPM indicative that a vehicle may moving or is about to move, or vibration that indicates that a vehicle is moving or may be moving.
Moreover, an unsafe state may include a condition in which the vehicle is not moving, but that it is in an unsafe condition where distraction can be a problem. By way of definition, throughout this document the terms moving or in motion, shall mean any indication that the vehicle is about to begin a trip, is in mid-trip, and/or is in some other unsafe state where a CMD could potentially be distracting, independent of whether at that point in time the vehicle is actually moving.
If an unsafe state is sensed go to step 1224. In step 1224, the UWS 1205 is communicated to the SDS 1208 from the VDS 35 with communication techniques described herein.
Next, comparing the UWS 1205 with a CMD associated with the VDS is performed via SDS or other part of the system 10 (Step 1226). The comparing step 1226 may include referencing tables in the SDD 110 to determine whether a particular CMD is associated with the UWS 1205, or other information available electronically, including data collected for other means that correlates a unique UWS signature to a particular CMD and or optionally a VDS.
If an associated CMD is found for the compared UWS 1205, go to step 1228 in which the associated CMD is disabled (Step 1228) using techniques described herein. If no associated CMD is found for the UWS go to Step 1230. Optionally, after Step 1228, if only one of multiple CMDs associated with a VDS are identified and disabled, go to Step 1231 to establish if there are other CMDs within the vehicle that may have disabled UWS via a query. The query in Step 1231 in a preferred embodiment is a low cost query.
In Step 1230, the location of CMD associated with the VDS are queried as a means to determine if CMDs are within the vehicle. The location may be queried as described with reference to
The alert provides notice to a third-party or the owner that the owner of CMD 25 has inadvertently or purposefully disabled the UWS transmission communication means, e.g., Bluetooth, and the like. The alert can be transmitted by email, text message, through the internet to the user via a web interface, or by other means. The alert may include one or more of the following: identity of the CMD, identity of the VDS or vehicle, identity of the CMD owner, time of alert, number of previous alerts, and location of the VDS at the time of alert. The alert may also be sent directly to the CMD owner to alert them. This alert provides a means for ensuring that the UWS remains enabled thereby improving the effectiveness of the SDS.
After disabling a CMD in step 1228, optionally a check may be performed to determine if multiple CMDs are in a vehicle by querying location of registered or associated CMDs with the VDS (Step 1231 and Step 1232). As it is a check, rather than a primary means for determining if a CMD is in the vehicle, the query may be delayed to ensure adequate separation from the start of trip location, or may be a low cost query, so as to lessen the frequency and cost of location queries. If additional registered CMDs are found in the vehicle, disable the CMDs (Step 1228) and optionally send an alert (Step 1234).
Alternately step 1228 and step 1230 may determine whether a CMD is in a vehicle, or should be disabled by other means described herein that may or may not require a location query.
Referring to
The VNT 17 described herein can be utilized in any aspect of the invention. In one embodiment, the VNT 17 is a subset of the VDS 35 as a separate hardware and/or software feature. Alternatively, the VNT 17 may be a standalone hardware and/or software feature. In this embodiment, the VNT 17 is located within the vehicle 15, and provides a unique wireless signal over a short range whenever the vehicle 15 is moving. The unique wireless signal is of a form that is received by the CMD on a similar frequency to that used for communication between the CMD and the MDSP, or some other frequency able to be received by the CMD during normal operation. The signal may be similar to that provided by a cell carrier femtocell repeater, or it may be some other signal that the CMD is operable to receive without the need for CMD software or firmware beyond that needed for normal operation, or with minimal modifications or minimal software or firmware required to receive and interpret the VNT signal.
In one embodiment, the VNT is located within the vehicle and provides a unique wireless signal over a short range whenever the vehicle is in an unsafe state. The wireless signal is configured to be received by a CMD. In the preferred embodiment, the wireless signal is transmitted at a frequency similar to that of a cell tower, however, the wireless signal may be Bluetooth, Zigby, or any other signal that has a CMD transmission/receive frequency or other similar RF protocol to permit communication with a CMD. The wireless signal contains a unique identifier for the VDS.
In one embodiment, the unique wireless signal provided by the VNT 17 is transmitted at a frequency similar to that of a network cell tower, so that RF receivers on the CMD used for communicating to cell towers also receive the signal from the VNT, with the range of the VNT transmission such that it is only received by CMDs within the vehicle or near the vehicle.
Moreover, the unique wireless signal transmitted by the VNT 17 can be formatted so as to appear as an additional cell tower to the CMD, with a tower ID including a unique identifying characteristic that varies depending on the velocity or state of the vehicle and unique wireless signal can also include identifying characteristic that are unique to the VDS. For example, the unique wireless signal can be configured with any existing communication protocol to mimic a cell tower or to provide some other form of signal that will be forwarded to the MDSP 130.
In one embodiment, a CMD that has received a unique identifying characteristic from the VNT processes the signal as if it were a cell tower. Thereby, the CMD provides the VNT cell tower information to the MDSP 130 or a part of MDSP 130 communication protocols, with the presence of the unique identifier data providing data to the MDSP that indicates that a specific CMD is within a vehicle associated with a specific VDS, and the vehicle is in an unsafe state. For instance, the cell tower ID information may be formatted to be processed by the CMD as a functional cell tower ID, but contain unique information within the cell tower ID that indicates to the VNTP that the cell tower ID contains information associated with the System.
In a preferred embodiment, the unique wireless signal from the VNT is of a low signal strength, and/or sends other information that prevents the CMD from connecting to it as a functioning cell tower, e.g., the unique wireless signal may include a tower busy signal to prevent connection or other signal as known in the art in order to prevent connection. The MDSP 130 identifies this unique wireless signal through a VNT processor identifier (VNTP) 19.
In one embodiment, the unique wireless signal includes a VNTID as part of the signal generated from the VNT. The VNTID is configured to include a unique identifier of a VDS, information about the state of the VDS, e.g., unsafe state or safe state, and/or may include other information about the vehicle, e.g., velocity, direction, RPM, on, off, battery voltage, and the like. The VNT processor and/or software is operable to process the VNTID and identify it as information associated with any of the systems described herein, to process the VNTID so as to identify the unique identifying information associated with the VDS and to associate that information with a unique CMD identifier, such as the CMD phone number.
In one embodiment, access to the VNTID can be provided by the VNTID through the internet, or other means to the SDS 125 indicating the presence of a particular CMD within a particular moving vehicle. This information is then combined with other collected information relevant to distracted driving to determine if a particular CMD is being used by a driver of a moving vehicle, and if so, a notification is transmitted to the MDSP, third party network element provider, or wirelessly to the mobile device itself, enabling the MDSP, a third party network element provider, or software on the CMD itself to limit various distracting functions provided by the CMD using means described elsewhere in this description, or to disable the CMD using techniques described elsewhere.
In another embodiment, the VNTID can be interpreted by software or firmware within the CMD to indicate that the CMD is within a moving vehicle 15. The CMD upon receipt of an interpreted signal then provides notification wirelessly from the CMD to the SDS via the MDSP, that a particular CMD is within vehicle 15 and the vehicle is in an unsafe state, allowing the SDS to disable the CMD through techniques included herein.
In one embodiment, the VNT 17 is operable to connect to the MDSP, either directly through a wireless connection, or through the CMD to the MDSP, to receive provisioning information necessary for the VNT to provision itself as a cell tower, in an equivalent manner to how a femtocell repeater is provisioned to act as a cell tower.
Referring to
Initially, sensing of the VDS is performed to determine a safe or unsafe state of the vehicle. An unsafe state is a condition of the vehicle that indicates that a CMD may be potentially distracting as previously described herein. Again, an unsafe state or condition is not limited to when the vehicle is moving, but may include an unsafe condition where a distraction can occur.
In one embodiment, movement or other indication of a potentially unsafe state, such as sensing vehicle start or key on may be sensed directly by connection to the vehicle computer network either by the OBDII port or some other wireless or directly connected means, or the movement may be sensed by a GPS device connected to the VNT, or by accelerometers connected to the VNT.
If an unsafe state is sensed a unique wireless signal and VNTID is transmitted from the VNT 17 (Step 1304). Next, a CMD receives the unique wireless signal VNTID and retransmits VNTID via communication network and MDSP 130 (Step 1306).
In one embodiment, access to this data is then provided by the MDSP through the internet, or other means to the SDS indicating the presence of a CMD in a vehicle that is in an unsafe state. This information is then combined with other collected information relevant to distracted driving to determine if it is probable that a particular CMD is being used by a driver of a vehicle in an unsafe state, and if so, a notification is transmitted to the MDSP, third party network element provider, or wirelessly to the CMD itself via the MDSP, enabling the MDSP, a third party network element provider, or software on the CMD itself to limit various distracting functions provided by the CMD, such as texting, computer software applications requiring interaction with the mobile device owner, or talking on the cell phone, or through other techniques described herein.
Next, the VNTP processing is performed (Step 1308). The VNTP processing receives information from the network including the VNTID and the identity of the CMD associated with the VNTID. The VNTP then processes this information to extract the VDS identity, information as to the state of the vehicle, and the identity of the CMD associated with the VNTID. Next the processing includes sending the bundled information from the VNTP 19 to the SDS 125.
The SDS 125 is operable to determine the probability that the CMD is in use by a driver of a vehicle by combining the bundled information from the VNTP 19 with information related to the CMD, the vehicle and the driver that is available to the SDS via the SDD, using techniques described herein (Step 1310) and if the SDS determines it is likely the CMD is in use by a driver of the vehicle disable the CMD using techniques described herein (Step 1312).
In this embodiment, additional information is utilized in the determination of whether to disable a CMD or multiple CMDs. This additional information may be obtained in a variety of different ways and can include information specific to a particular driver including information collected during provisioning (Driver Profile Information, DPI), information related to the driving behavior of a driver or vehicle (Driving Behavior Pattern Information, DBPI), information related to previous and recent trips (Recent Trip Data, RTD), information related to the frequency and nature of CMD overrides (Driving Override Record, DOR), information collected during a trip including but not limited to information related to a vehicle, driver, CMD, VDS, or other information (Real Time Vehicle Data, RTVD). All of this information may be stored in the SDD 110 or other storage device, or may be processed by the SDS and not stored.
This information can be transmitted by the VDS to the SDS during previous trips, either via data collected from the vehicle via the OBDII port, through integral velocity, location and acceleration sensors on the VMD, other sensors integral to the VDS, or similar data collected and transmitted by a CMD within the vehicle, as well as data transmitted or captured during a previous trip from other sources associated with a vehicle, CMD, VDS or driver.
In one embodiment, this information is used to generate a unique DPBI for each of the drivers associated with CMDs.
In one embodiment, the DPBI and DPI includes driving patterns and information associated with specific portions of a trip (such as a specified period at the beginning or end of a trip), or for specific locations during a trip (such as behaviors at stop signs, or geographic locations with specific speed restrictions), or data collected throughout the trip. Moreover, the DPBI can include such information as acceleration rates, maximum speed, average speed, trip start locations, trip end locations, driving behaviors at stop signs, driving behaviors during cornering, vehicle route information during a portion of the trip, linear acceleration patterns, braking patterns, cornering acceleration patterns, rpm vs. location patterns, rpm vs. velocity patterns, rpm patterns, times of day a specific driver has been determined to be likely to be driving, probability a certain driver will be driving a vehicle, probability that a certain driver will be driving a vehicle when there are more than one registered CMDs in the vehicle, times of day a particular driver has been determined to be likely to be driving along a certain route, driver seat position, time to first motion of the vehicle after key-on, velocity while backing up, selection of radio channel, choice of audio or video entertainment, key identification data, and any other information able to be captured by the onboard vehicle electronics, other sensors, provisioning or through other techniques that could be unique to a particular driver.
In one embodiment, RTVD may include self-identification information (Self ID Information) that may be intentionally sent by the driver of the vehicle to identify them as the driver such as sending a text message or making a call that can be received by the SDS and associated with a specific driver, opening a self-ID application or website on their CMD that transmits the identity of the driver to the SDS, by performing actions unique to a particular driver of the vehicle that can be sensed by the VDS via the OBDII connection or other means of sensing vehicle information, and transmitted to the SDS, such as, but not limited to, blinking the high-beam lights a certain number of times, turning on lights a certain amount of times, tapping the brakes a certain number of times or any other means for communicating to the SDS that a specific individual is driving the vehicle.
In one embodiment, the SDS disables all CMDs associated or registered with a VDS on sensing an unsafe state until a driver of the associated vehicles self identifies using communication techniques described herein, providing a motivation for the driver to self-identify due to the inconvenience from an associated CMD of a non-driver being disabled.
In one embodiment, DOR can include data from previous trips, during which certain individuals in the vehicle transmitted a request to override a disable command from the SDS for a specific CMD, as described elsewhere in this description, indicating a possibility that the CMD was at that time not associated with the driver of a vehicle and or not within the vehicle, implying the SDS had made an incorrect determination that a particular CMD was in a vehicle, or associated with the driver of the vehicle. This information then being used to improve the SDS ability to discriminate by identifying possible errors in probability calculations that can be corrected, either as an autonomous capability of the SDS software (self learning), or by manual reprogramming of the SDS software.
DBPI can be associated with a specific driver by various means, such as positively identifying the driver later in a trip by other means such as collocation of a CMD within the vehicle, statistically by identifying a particular unique driver profile, and then later associating it with a specific driver when the collected data indicates a high probability that the unique driver profile is associated with a specific driver, by self-identifying as described herein or other techniques that associate a driver with a particular driving pattern.
DPI for specific drivers associated with a specific vehicle can also be captured directly via the SDRS user interfaces. For example, information on the probability that a specific driver will be driving a specific vehicle, probability that a driver will start a trip at a particular time of day, geographic locations that a particular driver often starts a trip from (for instance a home or place of business), a location the driver often ends a trip at, probability that if multiple registered drivers are in a specific vehicle, that a particular registered driver will be the driver of that vehicle (for instance, when the family is in the car, the mother is likely to be the driver), the probability that a specific driver will “self-police” and voluntarily not use a distracting device, and the probability that a specific driver will not use a distracting device when other passengers are in the vehicle.
Collected data can also include data collected by the SDS during recent trips (Recent Trip Data). This data can be associated with a) the specific VDS b) concurrent trips associated with a different VDS that has associated drivers that are also associated with the specific VDS, c) most recent location of CMDs associated with the specific VDS, d) location of the previous end of trip for the specific VDS, e) location of previous end-of-trips for associated VDS's, and other recent trip data specific to a particular VDS and the associated CMDs.
In one embodiment, the SDS incorporates a Real Time CMD Driving Probability (RTCDP) processor as a component of the SDS which is operable to compare RTVD information with DPI, DBPI, RTD, DOR, Self ID information and other information (collectively the ID Information) to calculate the probability that a particular CMD is either in a vehicle or associated with the driver of the vehicle, the CMD Driving Probability (CDP). The RTCDP is operable to compare information and patterns represented in the Real Time Vehicle Data with information and patterns in the ID Information to calculate the CDP. In one embodiment, the RTCDP processor identifies individual elements of similarity or dissimilarity between the RTVD information and the ID Information, and calculates the CDP by applying historical weighting factors to each areas of similarity that increase probability and then applying historical weighting factors to each area of dissimilarity that decreases probability and calculating the resulting CDP by calculating aggregate probability based on these individual probabilities. For example, if a comparison of RTVD and DPI information shows that a vehicle is being driven at a time of day where there is a low probability an individual with a given CMD would be driving, this would indicate a decreased probability for that CMD being distracting, while simultaneously, the behavior of the associated vehicle at a stop sign may be similar to that associated with DPBI information associated with that same CMD and individual indicating a higher probability that the CMD is associated with the vehicle driver, while simultaneously, the location of the vehicle matches route information within the DPBI that indicates an increased probability that the CMD is associated with the driver of the vehicle. The RTCDP then uses weighting factors for each of these probabilities (established historically from the data, or entered manually) to calculate a composite CDP, which may or may not indicate a high probability that the CMD is being used by a driver and potentially distracting. In similar ways the RTCDP can compare any RTVD with other ID information data or other data to identify elements of similarity or difference between the RTVD and ID information and thereby calculate aggregate CDP for comparison with threshold probability values for disabling.
In one embodiment, the time of day that a particular vehicle is being driven is compared with DPI indicating the probability that a driver is driving at that time of day.
In one embodiment, the route of a vehicle in the first portion of trip is compared with DBPI related to the routes taken by specific drivers to indicate the probability that a specific driver is driving the vehicle.
In one embodiment, at least one of the velocity, acceleration and de-acceleration information of a vehicle at or near a stop sign is compared with DBPI related to at least one of the velocity, acceleration and de-acceleration information of specific drivers at or near stop signs, indicating whether they typically do a rolling stop, or a full stop, or other behavior that determines the probability that a specific driver is driving the vehicle.
In another embodiment, the RTVD information related to accelerations during cornering is compared with DBPI related to specific driver cornering to indicate the probability that a specific driver is driving.
In another embodiment, the RTVD information related to velocity compared to speed limit, or velocity on a particular segment of a route, is compared with equivalent DBPI to determine the probability that a specific driver is driving.
In another embodiment, RTVD information related to the time between turning the key of the vehicle on and first motion, which can be associated with individual-specific time taken to prepare to drive after turning on the car, is compared with equivalent DBPI to determine the probability that a specific driver is driving.
In another embodiment, RTVD information on braking patterns during a particular segment of a trip, or at any point in the trip, such as average de-acceleration or maximum de-acceleration are compared with equivalent DBPI to determine the probability that a specific driver is driving.
In another embodiment, RTVD information on rpm vs. velocity, indicative of individual-specific shifting patterns in both automatic and manual transmissions is compared with equivalent DBPI to determine the probability that a specific driver is driving.
In another embodiment, probabilities from individual positive and negative correlations between RTVD and DPBI information are combined to provide a more accurate composite CDP.
Referring now to
The RTCDP component of the SDS is operable to compare RTVD information with SDD data including at least one, or a combination of Driver Profile Information, Self ID Information, Driving Behavior Pattern Information, Recent Trip Data, Driver Disable Record Information and other data related to identifying the driver of a vehicle. (Step 1404).
Next, to determine the probability that a specific driver associated with a particular CMD is driving a vehicle (CMD Driving Probability, CDP) is calculated (Step 1406) using techniques described herein. The SDS is operable to compare the CPD with a threshold probability (Threshold Probability for Disabling, TPD) that is a probability value that establishes if the SDS should enable or disable a CMD, and has been pre-established to provide optimum SDS performance, or is autonomously derived by the SDS by comparing the accuracy of disable discrimination from previous trips (determined by evaluating DOR information or other means, Step 1408).
When the TPD is exceeded, the SDS is operable to send a signal to disable, or partially disable the function of a specific CMD, or alternately to record the identity of the driver in the SDS for subsequent comparison with CMD use records to report distracting CMD use as described elsewhere in this description (Step 1410).
Optionally, when the TPD is not exceeded, the SDS is operable to query locations of CMD associated with the VMD and compare those locations with the VMD location using techniques described elsewhere in this description, or to utilize any other information or process described herein that improves the ability of the SDS to determine if the CMD should be disabled (Step 1412). Moreover, the SDS is operable to update the CDP in real-time as additional information is received by the VMD (Step 1414).
Optionally, a verify step 1416 is performed to confirm CMD within the vehicle via a location query of CMD associated with the VDS through means described elsewhere. The verify step is describe herein with reference to step 1108 of
In one embodiment, information associated with a SDS determination of when CMD may be used in a distracting manner is used to monitor instances of distracting CMD use rather than to disable the CMD. In this embodiment, information is recorded in the SDD or other means, or is provided real time to the SDS, related to the likelihood of the CMD being in a vehicle that is in an unsafe state and possibly being used in a distracting manner. This information can include the identification of CMD that would have been disabled by the SDS by means described herein, the time the CMD would have been disabled, the location of the VDS, the calculated probability the CMD is in the vehicle, the calculated probability the CMD is in use by a driver, the location of the CMD, the identity of the vehicle, the velocity of the vehicle during a trip, the time that the CMD would have been enabled, the location at which the CMD would have been enabled, and other data from the SDS or RTVD associated with the use of a CMD in a distracting manner. For instance, the SDS may record information related to when a CMD was in a vehicle that was in an unsafe state, when a CMD would have been disabled by the system, when a CMD would have been enabled, by the system and the identity of the VDS it was associated with during the trip. The SDS is operable to compare this information as to when a CMD was in a vehicle in an unsafe state, or the when a CMD was associated with the driver of a vehicle in an unsafe state, with CMD usage information provided by the MSDP or other parties indicating the time and nature of CMD function or operation (for instance, texting sending and receiving, call sending or receiving, or other use of the CMD) as well as any other information related to potential distracting use of a CMD. This usage information can be provided autonomously by the MDSP or a third party provider with access to that information, or can be provided by the subscriber by uploading usage information provided them by the MDSP, to the DSS via the SDRS or other means. The SDS is then operable to determine instances when the CMD was used in a potentially distracting manner, by comparing time of usage of the CMD with times that CMD use may have been distracting, record these instances and related data in the SDD, and provide reports and alerts to the CMD user, the vehicle owner, insurance companies, federal agencies, or other parties, so as to identify potentially distracting use of a CMD by a driver or passenger. These reports may be provided by email, by text, by web interface or be provided by other means. They optionally can include additional information beyond instance of distracting CMD use, including other relevant information, such as location of distracted use, velocity of the vehicle at the time, severity of the distracted use (such as use on high speed two lane roads), probability of occurrence, etc.
In another embodiment, any means described herein for determining if a CMD is in a vehicle that is in an unsafe state, and therefore should be disabled or enabled, and any information captured by the SDS and SDD by means described herein may be used to report instances of distracted CMD use as an alternative to disabling the CMD. Additionally, this information can be used in conjunction with disabling the CMD to confirm that the CMD was effectively disabled by comparing usage information with periods of time where the CMD should have been disabled by the SDS.
In embodiments described herein, the above techniques improve the performance of the SDS by one or more of a) lessening the time lag and improving the accuracy of determining if a CMD is in use by a driver of a vehicle, is in use by a passenger of a vehicle, or is not in the vehicle; b) lessening the need for time-consuming, costly, or ineffective discernment methods (such as location queries); and c) providing a more accurate record of CMDs that were in a vehicle or in use by the driver of a vehicle, that when compared with CMD usage records as described elsewhere in this description, provide a more accurate record of when a CMD was used in a potentially distracting manner.
Referring to
Determine CMDs associated or registered with the VMD are within the vehicle using techniques included elsewhere in the description (Step 1502). Determine if the CMD in the vehicle is associated with a low risk driver, e.g., a driver that is unlikely to use a CMD in a distracting manner when others are in the vehicle, and or, is likely to prevent others from using a CMD in a distracting manner in the vehicle they are within such as a parent, or in a commercial vehicle, a supervisor (Step 1503).
Determine number of other CMDs associated with the VMD in the vehicle (Step 1504). If it is determined only one CMD associated with the VMD is in the vehicle, send disable command (Step 1512), optionally, go to Step 1510 to verify if there are more than one CMDs in the vehicle. The verify step is described herein with reference to
If it is determined that there is more than one CMD associated with the VMD in the vehicle, the SDS is operable to determine if any of the CMDs in the vehicle is registered to a low risk driver (Step 1506).
If one or more CMDs are registered to low risk drivers, enable any previously disabled CMD associated with the VDS for the remainder of the trip and exit the process (Step 1514).
If none of the CMDs in the vehicle are registered to low risk drivers, disable all CMDs in the vehicle (Step 1508).
Optionally, continue to determine if CMDs associated with the vehicle are within the vehicle or not in the vehicle (Step 1510), and repeat step 1504 until all CMDs associated with the vehicle are determined to be in or out of the vehicle, or it is determined there is are more than one CMDs within the vehicle and one of the CMDs is registered to a low risk driver.
In one embodiment of the above cases, each CMD is able to send an override signal wirelessly to the SDS, either through a text message, or through some other simple function on the SDS described herein, requesting that the CMD owner is not driving, and requesting the SDS to re-enable potentially distracting functions (Step 1516). The SDS is operable to enable the CMD (Step 1522), or optionally to determine if there are at least two CMDs in the vehicle that have been disabled, so that on granting the override request, there will remain one CMD that is disabled, presumably the driver (Step 1518). If there are two CMDs disabled, go to Step 1522. If there is only one disabled CMD in the vehicle go to Step 1520. On re-enabling these functions, the SDS optionally can simultaneously send a notification to the owner of the vehicle, or to the subscriber that an override has been received and executed. If through these notifications, the owner of the vehicle determines that this override function is being abused, they have the optional ability to provide notification to the SDS that overrides shall not be allowed for that particular CMD without their authorization.
In one embodiment of the invention, it is desired to improve the ability of the VDS to provide data in real-time that the SDS that the vehicle is in an unsafe state or not, and reduce lags and inaccuracies in the ability of the SDS to disable and enable CMDs, as well as to provide data that indicates if a driver of the vehicle has attempted to disable the VDS.
In one embodiment, the VDS includes elements to improve VDS performance such as a) means to sense and transmit information helpful in determining if a vehicle is in a potentially unsafe state such as battery voltage, rpm, location and key-on or key-off signals; b) means to send and receive text (SMS) messages via the MSDS to the SDS; c) means to receive and respond via either SMS or other data transfer means to queries for specific vehicle information helpful in determining if a vehicle is in a potentially unsafe state such as rpm, battery voltage, location, velocity, key on, or key off; d) on-board timers that can connect or disconnect the wireless connection to the MDSP; e) means to send data intermittently to the MDSP to confirm that the vehicle continues to be in an unsafe state or not; and f) means to connect the VDS to the MDSP when the VDP senses motion of the vehicle, key on, or some other event that indicates that the vehicle may be about to enter into an unsafe state (Unsafe State Indicator Data, USID).
In one embodiment, the VDS is operable to be in a standby mode where it is not connected to the MDSP but is powered. On recognizing USID data, the VDS is operable to immediately connect to the MDSP, and on connection to the MDSP, sends an SMS message to the SDS indicating that the vehicle may be in an unsafe state, such SMS message being able to be transmitted with a considerably weaker data connection than that required for other data transfer, allowing the VDS to connect to the SDS quickly in cases in which the wireless connection between the VDS and the SDS is weak (such as in a parking garage, or in the mountains). The means for sending the SMS immediately may be accomplished by the SDS sending an SMS query to the VDS while it is in standby mode, that would be automatically responded to when the VDS first connects to the MDSP, or by the firmware on the VDS automatically sending the SMS when it first connects to the MDSP. Optionally the data sent to the SDS via SMS can be either a simple flag indicating a possible unsafe state, or be the transmission of data such as the USID data that when combined with other data, helps the SDS better determine if the vehicle is actually in an unsafe state.
In one embodiment, it is desired to enable the SDS to determine the end of a trip in the instance that the end of trip occurs in an area of weak wireless connectivity (such as a parking garage, or in mountainous areas). In this example, the VDS is operable to send an intermittent signal at a constant interval (for instance every 30 seconds) that transmits either a flag indicating the vehicle is in a safe, or unsafe state, or transmits USID data that enables the SDS to determine if the vehicle is in a safe or unsafe state. In this example, the SDS is operable to monitor signals from the VDS, and if it no longer receives signals at a regular interval for a pre-determined period, the SDS determines that the VDS either has ended a trip in an area of weak connectivity, or has entered an area of weak connectivity for an extended period in which a CMD would also lose connectivity and be less capable of distracting a driver. In either case, the SDS then is operable to send a re-enable command for the CMD until it again receives data indicating that the VDS senses a potentially unsafe vehicle state indicating both the unsafe state and that the vehicle is in a location with connectivity that allows potential distracting use of the CMD. Optionally, if the SDS does not receive signals from the VDS over a pre-determined period indicating weak wireless connectivity, the SDS is operable to query the VDS using SMS and the VDS is operable to respond to that query, providing USID data, or a flag, indicating that the vehicle is in a safe or unsafe state, such SMS transmission being able to occur in areas of weak connectivity, thereby increasing the effectiveness of the SDS in being able to determine if the vehicle is in an unsafe state. Alternately, the MDSP can provide data to the SDS indicating that a connection is present between the VDS and the MDSP, the SDS being operable to respond in a similar manner as that described above, when the MDSP data indicates that a connection between the VDS and the MDSP has been lost.
In one embodiment of the invention designed to discourage drivers from disabling the VDS, the VDS incorporates a rechargeable battery that provides sufficient power to maintain a wireless connection to the SDS and provide the SDS a signal that a VDS has been disconnected from the vehicle. The SDS is then operable to disable or partially disable the CMD or CMDs associated with that VDS until such time as the VDS is reconnected, or alternately to provide an alert to the vehicle owner that the VDS in that vehicle has been disconnected.
In one embodiment of the invention, it is desired to eliminate the lag time resulting from the establishment of the handshake connection between the VDS and the MDSP that occurs when the vehicle is turned on. In this embodiment, the wireless connection, is maintained between the VDS and the MDSP while the vehicle is turned off, so that it is not necessary to establish a handshake connection when the vehicle is turned on, thereby enabling the SDS to sense when a vehicle is in an unsafe state shortly after the vehicle is turned on. This connection may optionally be a limited functionality stand-by mode. Optionally, the VDS can include a timer that will disconnect the VDS to MDSP wireless connection after a certain number of hours, to prevent unnecessary battery drain when the vehicle is parked for multiple days (for instance when parked in an airport parking lot).
One embodiment, is directed towards a method for determining if a CMD is in a vehicle by utilizing one or more of velocity, direction of velocity, location in order to establish whether a CMD is in a vehicle, without needing location information from CMD and/or VDS. More specifically, this embodiment can be utilized with CMDs and VDSs having location and velocity capability. The velocity of a CMD is compared to the velocity of the VDS to see if it is substantially identical. Also, the direction of CMD is compared to the direction of the VDS to see if it is substantially identical. Monitor cell tower switching for CMDs indicating motion of CMD SDS utilizes the tower switching to indicate a CMD is moving or not when a VDS is moving. If CMD velocity or direction is substantially identical it indicates that a CMD is in that particular vehicle. Moreover, if CMD velocity or direction is not substantially identical it indicates that a CMD is not in a particular vehicle. In addition, if tower switching indicates CMD motion, while VDS is in motion, it increases the likelihood that CMD is in that vehicle. If no tower switching then it indicates CMD is not in that vehicle.
One embodiment is directed towards a method for determining if a CMD is in a vehicle by using one or more of previous trip and information and start of trip location and velocity. In this embodiment, locations are identified where multiple registered drivers may be in a vehicle at trip start (MCBL) and where a single registered driver may be in the vehicle (SCBL). In one embodiment, these locations may be identified by provisioning or be reviewing past trip history. If the vehicle starts from a location other than a MCBL, disable CMDs that were in the previous trip, then confirm CMDs in the vehicle through other verification procedures as described herein. If the vehicle starts from a location that is a MCBL, establish CMDs in the vehicle through various techniques described herein and disable CMDs in the vehicle. Evaluate the last known location of other registered CMDs to determine those that could not be in the vehicle at start of trip being located too far from the start of trip.
One embodiment is directed towards a method of determining if a CMD is in a vehicle by using one or more of the following, provisioned information associated with a driver or vehicle or location, driving pattern information established from previous trip information associated with a specific CMD, and real time information from a current trip. Real time information during a trip is compared with previous information associated with a particular CMD, Vehicle or Driver (profile information) and a comparison is made between real time information and profile information. When real time information is similar to profile information, the probability that CMD is in the vehicle is increased. When real time information is dissimilar to profile information, the probability that CMD is in the vehicle is decreased. In a preferred embodiment, SDS compares the information with other information to determine overall probability that the CMD is in the vehicle and or if the CMD should be disabled. SDS compares this probability with a threshold value to determine if the CMD should be disabled. Presence of CMDs in vehicle can optionally be confirmed from other techniques such as location of CMDs versus location of VDS. In one embodiment, information includes information described herein including but not limited to: information associated with specific portions of a trip (such as a specified period at the beginning or end of a trip), or for specific locations during a trip (such as behaviors at stop signs, or geographic locations with specific speed restrictions), data collected throughout the trip, acceleration rates, maximum speed, average speed, trip start locations, trip end locations, driving behaviors at stop signs, driving behaviors during cornering, vehicle route information during a portion of the trip, linear acceleration patterns, braking patterns, cornering acceleration patterns, rpm vs. location patterns, rpm vs. velocity patterns, rpm patterns, times of day a specific driver has been determined to be likely to be driving, times of day a particular driver has been determined to be likely to be driving along a certain route, probability that a driver will be driving a particular vehicle, driver seat position, time to first motion of the vehicle after key-on, velocity while in backing up, selection of radio channel, choice of audio entertainment, key identification data, and any other information able to be captured by the onboard vehicle electronics, other sensors, provisioning or through other techniques that could be unique to a particular driver and/or self ID from driver.
One embodiment is directed towards a method of reducing lags between the time that a vehicle is in a safe or unsafe state and the ability for system to respond and disable CMDs. In this embodiment, using a network service, e.g., texting messages (SMS) to connect the VDS to the SDS in areas of weak connectivity, thereby keeping VDS connected to the MDSP when the vehicle is off to eliminate lags from connection making. Monitor data from VDS on a regular time interval to determine if vehicle has ended trip in an area with weak connectivity. Query VDS if state of vehicle is unknown by SMS to receive vehicle information indicating state of vehicle, such as power on, velocity, rpm, battery voltage etc. Monitor VDS MDSP connectivity at MDSP to confirm vehicle state and connectivity.
One embodiment is directed towards a method of reporting use of a CMD in a distracting situation rather than to disable the CMD, therefore providing information that can be used monitor distracted use of the CMD without the need for control. In this embodiment, any event is record that indicates a CMD is in a vehicle that is in an unsafe state using techniques described herein. This recording can include additional information about the unsafe state, e.g., severity of event, etc. This information is compared with CMD usage records from the MDSP to identify uses of the CMD while in a vehicle. A report is created to incidences of CMD usage including associated elements such as location of use, velocity of vehicle etc.
One embodiment is directed towards a simple method of determining the CMD within the vehicle. In this embodiment, CMDs are registered or associated with a VDS. The CMD owner can to identify that they are driving, such as text message, phone call, opening an application on a CMD, or performing a function that can be sensed by the VDS and transmitted to the SDS such as tapping brakes a certain number of times, blinking lights a certain number of times. When an unsafe state is determined, and a driver has not been identified, disable all CMDs associated with that vehicle. When the driver self-identifies enable non-driver CMDs. Optionally, compare the location of the disabled CMD with the location of the vehicle to confirm the identity of the driver.
One embodiment is directed towards using self-policing to limit the number of CMDs disabled when multiple CMDs are in a vehicle, thereby lessening the need for override requests. In this embodiment, identify which CMDs are associated with low risk drivers (unlikely to use a distracting CMD with others in the vehicle) as well as CMDs associated with high risk drivers (likely to use a distracting CMD with others in the vehicle. When a single CMD is in the vehicle, disable all CMDs in the vehicle. When multiple CMDs are in the vehicle and one is a low risk driver, enable all CMDs. When multiple CMDs are in the vehicle and none are low risk drivers, disable all CMDs. Optionally, with multiple CMDs disabled in a vehicle, allow all but one CMD to request an override.
One embodiment is directed towards using unique wireless signals transmitted from the CMD that can be received by the VDS to determine if a CMD is in a vehicle. In this embodiment, registered CMDs may be used within the vehicle to transmit a Unique Wireless Signal such as Bluetooth or other RF signal with a unique identifier. In a preferred embodiment, the UWS is the transmission that the CMD utilizes to communicate with the MSDP and therefore does not require any additional RF transmission beyond that required for operation. Optionally the MSDP may provide information through various means to the VDS to enable it to decrypt the UWS. The registered CMDs are associated to a specific UWS by provisioning or by the VDS sensing the UWS with the known CMD in the vehicle. When a UWS is received while a vehicle is in an unsafe state, a notification is made that the CMD associated with the UWS should be disabled. Optionally, the presence of CMDs in the vehicle but with a UWS disabled can be verified by comparing the location of the CMDs with the location of the VDS or other means described herein. Optionally, an alert can be sent that a CMD has a disabled UWS, allowing it to be enabled.
One embodiment is directed towards using a unique wireless signal transmitted from the VNT to the CMD that can be received by the CMD and transmitted to the MSDP without the need for software on the CMD, or with minimal software on the CMD, so as to provide information via the MSDP as to the presence of a CMD in a vehicle in an unsafe state, allowing it to be disabled. Registered CMDs may be used within the vehicle. On detecting an unsafe state, the VNT transmits a unique wireless signal (UWS) including one or more of notice of the unsafe state, vehicle information associated with the unsafe state, the ID of the vehicle and the ID of the VDS and VNT. The UWS is able to be received by the CMD without any modifications or software, or alternately with minor modifications or software. In a preferred embodiment, the UWS is configured to be received by the CMD and retransmitted to the MSDP as part of normal CMD protocols. In a preferred embodiment frequency of UWS is same as frequency CMD uses to communicate with MSDP. In a preferred embodiment, UWS is configured to appear as a cell tower transmission, such as femtocell transmission, with identification information incorporated as an element of the UWS in the form of cell tower ID information, but in a manner that the CMD does not attempt to connect to the VNT as a cell tower. UWS information can then be transmitted to the MSDP via this cell tower ID information (or by other means). MDSP is operable to decode the UWS to determine vehicle ID, CMD ID, state of vehicle, and provide to the system described herein. The system is operable to combine with other information to determine if the CMD should be disabled.
In one preferred embodiment where it is desired to provide information for other purposes other than controlling a potentially distracting mobile device, a vehicle is equipped with a VDS that is operable to capture vehicle information for the purposes of establishing a more accurate insurance rate for the vehicle and at the same time improving the driving behavior of individuals by providing feedback as to their driving behavior. In this embodiment the VDS provides data related not only to the identification of CMDs within the vehicle as described herein, but optionally can provide one of more of vehicle, driver and CMD information related to evaluating the driving patterns of the vehicle and drivers so as to establish an accurate risk factor for the vehicle for insurance purposes (Insurance Rating Information, IRI), or for other commercial purposes. In this embodiment, the SDS is operable to capture IRI information provided by the VDS and store it on the SDD, or forward it directly to be used for insurance ratings purposes, while utilizing information provided by the VDS for disabling CMDs using techniques described herein. Alternately, VDS information can be captured by a third party (for example an insurance company) and information necessary for disabling CMDs using techniques described herein can be provided to the SDS or SDD. In an embodiment, techniques describe herein to determine if a CMD is in a vehicle, if an individual is in a vehicle, or a specific individual is driving, are used to determine one or more of the occupants of the vehicle during trips, the driver of the vehicle during trips, the driving behavior of individuals, the amount of driving by a particular individual, and other information of commercial value related to driving behavior and the identification of individuals that are passengers or drivers of the vehicles. This information can then be provided to insurance companies, or commercial vehicle owners, or such companies to provide driver and vehicle passenger information that can be used for purposes of establishing more accurate insurance rates for that vehicle or individual, or for providing driving behavior feedback, or for determining favorable or unfavorable individuals or vehicles to insure. In another embodiment, the system and techniques described herein are used exclusively to determine this information without the incorporation of the elements of the system that actually control the potentially disabling electronic device.
In one embodiment, the method for capturing events that indicate the mobile device is or may be being used in a distracting manner by the driver can include indications such as the system is engaged or not while driving, e.g., game engaged, whether a distracted driving system has been overridden (
Optionally or alternatively, the method for providing information and scoring on unsafe driving behavior to the driver, the subscriber to the system 10, or others electronically, including CMD 25 and User Interface 115, includes providing the score in “real time” at the end of the drive to the driver through the CMD. The method can include providing discounts, e.g., e-commerce incentives, to a user near a location of the user at the end of the trip, e.g., using the location of the vehicle provided by the system. The e-commerce incentives can be generated automatically by the system or in combination with partners, such as companies that are willing to provide discounts to safe drivers and include tangible rewards (such as a discount on a products), potentially in real time through the CMD, or through another user interface. The incentives can also be rewards that are provided to a third party, such as a charity. In one embodiment, the type of rewards can be selected from a list by the user so as to be highly motivating to improve driving behavior, or be previously selected to be highly motivating to a particular driving demographic and be incoporated into the game based on demographic information provided by the user during registration.
In one embodiment, the Service Decision System 125 may be operational to connect with the CMD 25, VDS 35, Mobile Device Service Provider (MDSP) 130, Vehicle Service Provider VSP 100, or third-party source with network 60, network 45, data network 90, user interfaces 115 or other means to receive the vehicle plus mobile detected information. The vehicle plus mobile detected information may be received by the Service Decision System 125 periodically at set intervals or in a real-time near-continuous stream of data. Referring now to
In this embodiment, the Safe Driving Registration System 105 (
Referencing
The service decision engine may receive vehicle plus mobile detected information from one or more of CMD 25, VDS 35, and external inputs outside the vehicle. The information may be provided in real time, at predetermined intervals or after use of the vehicle 15. If the vehicle 15 is not in operation (as determined in step 710) the service decision engine 600 sends an enable services directive to either the MDSP 130 or the SDRS 110, depending on how it is configured (disclosed in
In step 1605, the Service Decision System 125 (and optionally the Safe Driving Registration System 105) received vehicle is configured to output the incentive including one of a score, or rewards, or bonus, or discounts and combinations of the same to the CMD 25, VDS 35, user interface 115, social media, portal, internet, subscriber, operator, or third party. In this embodiment, the output is done with the system 10 over a network (e.g., wireless network 45, wireless network 65, data network 90, other network or combinations therein). The output to the CMD 25 may be substantially instantaneous after the trip or at any predetermined time after the trip, e.g., when instantaneous, at key off of the vehicle 15. Outputs may include multimedia, sound, video and combinations thereof. In one embodiment, upon key off an incentive is audibly generated by the SDS 125 in step 1605 and sent to a CMD 25 and/or vehicle 15 to provide relatively instant feedback to the user. Moreover, the output may be sent via an application on the CMD 25 or other device accessible via internet to a graphical user display (e.g., in one embodiment as described with reference to
Referencing
In one embodiment, the incentive, e.g., score, and method can include a method for capturing unsafe driving events that can include swerving, excessive speed, abrupt braking either wirelessly from the vehicle, or from a mobile device associated with the driver utilizing the Vehicle Detection System (VDS) 35.
In one embodiment, the service decision engine 125 is configured to determine when a vehicle is moving, who the passengers are in the vehicle are and who is the driver of the vehicle 15; receive inputs from the vehicle 15 or CMD 25; and determine the location and occurrence of unsafe events. The SDS 125 determines a score for the driver using the system 10, as well as calculates other data that will improve the efficacy of the system to modify driving behavior. Optionally or alternatively, the incentives, e.g., score, may be generated on a game engine external to the system, (e.g.,
Referring now in detail to
Optionally or alternatively, one or more of the items may include outputting to social media to allow broad dissemination as well as enable different forms of games, competitions and rewards for individuals or teams. The data may also include scoring the driving behavior of the driver based on the number of unsafe events during a drive and be presented to the driver as a game that optionally may allow other drivers' scores to be compared for the purposes of competition, such as scoring changing the behaviors of the drivers from the desire to improve the score.
Referring now in detail to
Referring now in detail to
In one embodiment, software on the CMD is utilized, e.g., an application with functionality of the system, e.g., i.) preventing one or more services on the CMD from being operated during some predetermined events, e.g., vehicle motion, ii.) vehicle operator identification, iii.) game functionality, iv.) communication from the CMD to report various information over a network the information may include vehicle plus mobile device information, VDS information and/or other information, v.) other functionality of the system operated via at least a portion of the CMD, and combinations of the same. Software and/or hardware running at least partially on the CMD can cause a problem with delivering functionality of the system if it enters into a killed state, suspended state, removed from the CMD, becomes corrupted and the like. A killed state herein means that a user closes the application on the CMD after it is opened or has not actively opened an application on the CMD. A suspended states means the software has not been used for a time sufficient to suspend the software making communication with the software difficult even from a push notification.
Embodiments of the invention are directed to assist with suspended or killed states of the CMD or VDS. In one embodiment, the CMD and/or VDS can be used with a geofencing mode. In a geofencing mode one or more geofences based on at least last known location can be established for each CMD and/or VDS. The geofence is a predetermined geographical area, location and the like. Upon the CMD and/or VDS being within the geofence or near the geofence it can trigger software to wake up or can trigger the software to wake up when leaving a geofence and a communication from the CMD and/or VDS including state information can be communicated. The communication including state information can optionally include vehicle plus mobile device information. The geofence can be utilized to sniff or trigger Bluetooth activation. That is, if the vehicle leaves the geofence, the vehicle receiver/transmitters can sense wireless signals, e.g., Bluetooth, RF transmissions or other signals of the CMD and/or send a signal to the CMD to turn on Bluetooth or other RF transmissions so as to allow the sensing of the CMD in the vehicle, or alternately the CMD can sniff for Bluetooth or other RF signals within the vehicle so as to allow the CMD to identify the vehicle it is in proximity to. In one embodiment, the communication from the VDS can include information shown in Appendix A. This information can be simplified to information shown in Appendix B. In one embodiment, the communication from the CMD can include information shown in Appendix C. Optionally and/or alternatively, the communication from either the VDS and/or CMD can be configured with other information indicative of motion, location, time, temperature, base station signal strengths, wireless interface information and the like.
Referring now in detail to
In step 2102, the system determines if the CMD is in motion or if a notification was received. The notification includes a communication from the CMD having information indicative of motion. In one embodiment, the information can include information as shown in Appendix A, B, C and/or combinations of the same. This communication may be pushed (the CMD provides a communication to the system) or pulled (the CMD is queried for information from the system, and in response provides the communication). The system programically deduces if the vehicle is in movement or about to move based on at least a portion of the information and if it is determined go to step 2104. In a preferred embodiment, the system determines if a CMD is in motion by receiving information indicative of motion or location including motion and location information over time that is timely and accurate to within 5 meters or less. If it is determined the vehicle is not in movement or not about to move go to step 2106 and the process is completed.
In step 2104 it is determined if there are one or more detectors/sensors associated with the CMD. In one embodiment, information from step 2102 can be used along with information in the SDRS to determine if there are associated detectors/sensors with the CMD. In a preferred embodiment, this is done by sensing or querying an in-vehicle communication or input using the CMD while at the same time comparing and matching the vehicle and CMD's locations. If it is determined there are sensors/detectors associated with the CMD go to step 2108. If it is determined there are no sensors/detectors associated with the CMD go to step 2106.
In step 2108 a wireless interface is activated on the CMD if it is inactive, either triggered remotely by a signal from the system to the CMD, or on the CMD itself. In one embodiment, a Bluetooth and or WiFi interface can be activated if inactive on the CMD remotely. If the wireless interface cannot be activated go to step 2106. If the wireless interface is active or can be activated go to step 2110.
In step 2110 the system determines if the sensors/detectors satisfy predetermined criteria. The predetermined criteria includes a predetermined distance of the sensors/detectors from a CMD and/or VDS for a predetermined threshold time. The predetermined distance can be about 0.1 meters to about 10 meters. In a preferred embodiment, the predetermined distance is about 2 meters to about 2.5 meters in a more preferred embodiment the predetermined distance is about 2.5 meters. The predetermined threshold time can be from about 0.1 seconds to about 2 minutes or more. In a preferred embodiment, the threshold time can be about 2 minutes. In a preferred embodiment, this done by comparing signal strength and change of a signal broadcast by an in-vehicle system detected by a sensor on the CMD.
If the criteria is satisfied go to step 2112. If the sensors/detectors are not within the predetermined range go to step 2106. In step 2112, the CMD sends a communication over the network with information indicative that the sensors/detectors are within a predetermined range and information indicative of at least one of the CMD and sensors/detectors. Optionally and/or alternatively, additional information may also be transmitted.
Next, in step 2114, the system determines if the detectors/sensors are still within a requested ranging for a predetermined threshold of time. This is done by starting a recheck timer upon receipt of the last sensor update. Upon expiration of this time detectors/sensors check their environment again. If this is satisfied go to step 2110. If not satisfied, go to step 2116. In step 2116, the wireless interface is deactivated if it was activated. The technique described with reference to
Referring to
In step 2204 it is determined with the system if there are detectors/sensors associated with the CMD. In one embodiment, information from step 2202 can be used along with information in the SDRS to determine if there are associated detectors/sensors with the CMD. In a preferred embodiment this is done by querying the CMD for information to determine which if any sensors are in place and active on the CMD. Optionally and/alternatively, the SDRS is queried for information to determine association of detectors/sensors identified in communication from CMD and/or VDS. If it is determined there are sensors/detectors associated with the CMD go to step 2208. If it is determined there are no sensors/detectors associated with the CMD go to step 2206.
In step 2208 ranging is performed with the CMD. The ranging of the CMD searches for sensors/detectors nearby. In a preferred embodiment, the range is done by scanning for detectors/sensors for about 3 seconds, waiting 2 seconds, and scanning again for sensors/detectors 3 seconds. The scanning can be done by searching for associated sensors/detectors, e.g., known IDs of sensors and detectors. The scanning frequency and duration can be adjusted to save battery resources. If associated sensors/detectors are identified go to step 2210. If associated sensors/detectors are not identified go step 2206.
In step 2210 the system or a component of the system, e.g., CMD and/or VDS, determines if the sensors/detectors satisfy predetermined criteria. The predetermined criteria include information indicative of if the sensors/devices are within a predetermined distance for a predetermined threshold time from a CMD and/or VDS. The predetermined distance can be about 0.1 meters to about 10 meters. In a preferred embodiment, the predetermined range is about 2 meters to about 2.5 meters, in a more preferred embodiment the predetermined range is about 2.5 meters. The predetermined threshold time can be from about 0.1 seconds to about 2 minutes or more. In a preferred embodiment, the threshold time can be about 2 minutes. If it is determined the predetermined criteria has been satisfied go to step 2212. If the predetermined criteria has not been satisfied go to step 2206.
In step 2212, the CMD transmits a communication over the network with information indicative that the sensors/detectors are within a predetermined range and information indicative of at least one of the CMD and sensors/detectors. In a preferred embodiment, the communication includes detailed and accurate location information paired with in-vehicle environmental signals detected. Optionally and/or alternatively, additional information may also be transmitted. Next, go to step 2206.
Referring now in detail to
In step 2302 it is determined if the CMD motion is stopped or not driving. In one embodiment, this is done by receiving information shown in Appendix C. The system is queried to determine if the CMD is stopped or not driving. If it is determined the vehicle is in movement go to step 2304. If it is determined the vehicle is not in movement go to step 2306.
In step 2304, the system is configured to determine if the CMD is an active trip. Active trips as used herein means, at sometime after SOT and before EOT the vehicle may or may not be in motion. In a preferred embodiment, the system determines if it is in an active trip by receiving information from the VDS indicative that the vehicle is moving or engaged to be moved. If it is determined the CMD is an active trip, go to step 2308. If it is determined the CMD is not in an active trip, go to step 2306.
In step 2308, the system is queried to determine if there are any detectors/sensors associated with the CMD. In one embodiment, the SDRS is queried to determine if there are associated detectors/sensors with the CMD. Optionally and/alternatively, the associated detectors/sensors information from a previous trip can be used by reviewing the data logged for the last trip in the SDRS identifying which sensors/detectors provided data. If it is determined there are sensors/detectors are associated with the CMD for the current trip go to step 2310. If it is determined there are no sensors/detectors associated with the CMD go to step 2308.
In step 2310 ranging is started with the CMD and/or VDS. The ranging of the CMD searches for sensors/detectors nearby. In a preferred embodiment, the ranging is done by scanning for sensors/detectors about 3 seconds, waiting 2 seconds, and scanning again for about 3 seconds. The scanning frequency and duration can be adjusted to save battery resources.
In step 2312, the system determines if the sensors/detectors associated with the CMD are found. In a preferred embodiment, this done by querying the CMD over the network to detect which sensors/detectors are available for use. If associated sensors/detectors are found go to step 2316. If the associated sensors/detectors are not found go to step 2314.
In step 2316 the system determines whether the detectors/sensors satisfy a predetermined condition. The predetermined condition includes if the detectors/sensors are within distance from either the CMD and/or VDS for a predetermined threshold time. The predetermined distance can be about 0.1 meters to about 10 meters. In a preferred embodiment, the predetermined distance is about 2 meters to about 2.5 meters in a more preferred embodiment the predetermined distance is about 2.5 meters. The predetermined threshold time can be from about 0.1 seconds to about 2 minutes or more. In a preferred embodiment, the predetermined threshold time can be greater than 2 minutes. In a preferred embodiment, this is done by comparing signal strength and change of a signal broadcast by an in-vehicle system detected by a sensor on the CMD. If the criteria are satisfied go to step 2318. If the criteria are not satisfied go to step 2310.
In step 2314, the system determines if the sensors/detectors are out of range from the CMD and/or VDS for predetermined time. The out of range predetermined time can be about 2 seconds or more. If it is determined the sensors/detectors are out of range over the predetermined time go to step 2318. If it is determined the sensors/detectors are in range within the predetermined time go to step 2310.
In step 2318, the CMD transmits a communication over the network with information indicative that the sensors/detectors condition has been satisfied indicating an EOT. In a preferred embodiment, the communication includes information showing that an ignition off signal has been sent by the VDS. In addition, ranging is stopped.
Referring now in detail to
In step 2402 it is determined if the VDS and/or CMD motion is stopped or not driving. In one embodiment, this is done by comparing location over time of both the VDS and CMD to themselves and each other to determine if there is significant movement that would indicate driving. In this embodiment, the system is queried to determine if the CMD and/or VDS is stopped or not driving. If it is determined the vehicle is in movement go to step 2404. If it is determined the vehicle is not in movement go to step 2406. In a preferred embodiment, this can be done with an application, e.g., API, on the CMD and/or VDS.
In step 2404 the system is configured to determine if the CMD is an active trip. In a preferred embodiment, the system compares the location of the CMD and VDS to collocate them while comparing in-vehicle environments to determine if in active trip. If it is determined the CMD is an active trip, go to step 2408. If it is determined the CMD is not in an active trip, go to step 2406.
In step 2408 the system is queried to determine if there are any detectors/sensors associated with the CMD. In a preferred embodiment, association is determined by querying the CMD over the network to determine which sensors/detectors are available. In one embodiment, the SDRS is queried to determine if there are associated detectors/sensors with the CMD. Optionally and/alternatively, the associated detectors/sensors information from a previous trip can be used. If it is determined there are sensors/detectors associated with the CMD and/or VDS go to step 2410. If it is determined there are no sensors/detectors associated with the CMD and/or VDS go to step 2406.
In step 2410 ranging is performed with the CMD to locate sensors/detectors that are associated. The ranging of the CMD searches for sensors/detectors nearby. In a preferred embodiment, the ranging is done by scanning for about 3 seconds, waiting 2 seconds, and scanning again for 3 seconds. The scanning can be done by searching for associated sensors/detectors with either the VDS and/or CMD. The scanning frequency and duration can be adjusted to save battery resources. In a preferred embodiment, the ranging is done by the CMD detecting an in-vehicle signal.
In step 2412 the CMD determines if the sensors/detectors are associated with the CMD are found and associated with the current trip. In a preferred embodiment, this is done by the CMD detecting an in vehicle signal known to be associated with a specific vehicle through the SDRS database. If associated sensors/detectors are found go to step 2416. If the associated sensors/detectors are not found go to step 2414.
In step 2416, the system determines whether a criteria of the detectors/sensors is satisfied. The criteria of the found detectors/sensors includes a predetermined distance of the sensors/detectors from a CMD and/or VDS for a predetermined threshold time. The predetermined distance can be about 0.1 meters to about 10 meters. In a preferred embodiment, the predetermine distance is about 2 meters to about 2.5 meters in a more preferred embodiment the predetermined range is about 2.5 meters. If the sensors/detectors condition is not satisfied go to step 2410. If the sensors/detectors condition is satisfied go to step 2418.
In step 2414, the system adds to a counter (N) one additional count (N+1) and compares the current count to predetermined maximum count. In a preferred embodiment, the predetermined maximum count is 5. If it is determined the predetermined maximum count has been satisfied go to step 2418. If it is determined the predetermined maximum count has not been satisfied go to step 2410.
In step 2418, the CMD transmits a communication over the network with information indicative that the sensors/detectors condition has been satisfied indicating an EOT. In a preferred embodiment, the communication includes an ignition off signal from the VDS. In addition, ranging is stopped.
Referring to
In step 2502 the system is configured to determine if a CMD and/or VDS is within a predetermined distance from of one or more devices/sensors associated with the CMD and/or VDS. This is done by comparing in-vehicle environments detected by both the VDS and the CMD to determine if a predetermined signal is found and if it is within a predetermined threshold. The predetermined distance can be about 0.1 meters to about 10 meters. In a preferred embodiment, the predetermined distance is about 2 meters to about 2.5 meters in a more preferred embodiment the predetermined distance is about 2.5 meters. If the associated sensors/detectors predetermined distance range condition is not satisfied go to step 2516. If the associated sensors/detectors are within the predetermined distance go to step 2518.
In step 2518 the identity of the operator is predicted based on information from step 2502. In a preferred embodiment this is done by using prepopulated values within the SDRS and signals detected by the VDS or CMD to associate an operator with a VDS and or CMD during an active trip. Optionally and/or alternatively, in order to increase the probability of operator identification one or more of steps 2504, 2506, 2508, 2510, 2512 and any combination of the same may be used.
In step 2504 the system determines if a CMD associated with the vehicle operator has communicated with the system. For example, whether the system has received information from the CMD, e.g., information as shown in Appendix C. The information received from the CMD can include other information as discussed previously herein. If it is determined the CMD has communicated go to step 2506. If it is determined the CMD has not communicated with the system go to step 2516. In step 2516 the identity of the vehicle operator is not predicted.
In step 2506 the system is configured to determine if CMD is within a predetermined distance from the detectors/sensors. The predetermined distance can be about 0.1 meters to about 10 meters. In a preferred embodiment, the predetermined distance is about 2 meters to about 2.5 meters in a more preferred embodiment the predetermined distance is about 2.5 meters. If the predetermined distance from the CMD to sensors/detectors condition is satisfied go to step 2508. If the predetermined distance from the CMD to sensors/detectors condition is not satisfied go to step 2516.
In step 2508 it is determined if the CMD and/or VDS has moved within a predetermined time range of two minutes or less. In a preferred embodiment, this is done by the VDS transmitting an ignition on signal to the SDRS within the time frame specified. If the CMD has not moved within the predetermined time range go to step 2516. If it is determined the CMD has moved within the predetermined time range go to step 2510. Optionally and/or alternatively, if it is determined the CMD has moved within the predetermined time range go to step 2518.
In step 2510 it is determined whether the CMD is on another trip by querying the SDRS database to determine if a CMD is associated with an active trip. If it is determined the CMD is on another trip go to step 2512. If it is determined the CMD has moved within the predetermined time range go to step 2516. Optionally and/or alternatively, if it is determined the CMD has moved within the predetermined time range go to step 2518. If it is determined the CMD has moved within the predetermined time range go to step 2510.
In step 2512 it is determined if the VDS and CMD are within a predetermined location to one another. In one embodiment, a location of the VDS and CMD are compared to determine if they are within a predetermined distance range of about 5 meters or less from each other. If it is determined the VDS and CMD are within the predetermined range go to step 2512. If it is determined the VDS and CMD are not within a predetermined range go to step 2516.
Optionally and/or alternatively, there are several additional inputs that can be used to programically increase the probability that a vehicle operator identity is accurate. In one embodiment, the operator from a previous trip is compared with the vehicle operator determined on the current trip in order to increase the accuracy of the determined vehicle operator. Also, it can be determined if the CMD transition into vehicle motion around the same time as the CMD.
Referring to
Referring to
In
Referring to
Referring to
Referring to
In this embodiment, an end user approval through on-phone prompts during initial install of software or application allows the user to override the blocking in emergencies. Optionally, the system can be configured on set-up to provide alerts to the system administrator, or other individuals when such an emergency override is used. This alert can optionally include context information at the time of alert, such as the time of day, the location, the speed at which the vehicle is moving, and the number of other individuals in vehicle, as well as other context information. In a preferred embodiment, emergency use such as 911 in the US, and 911 texting are never blocked. Optionally, this setup can allow whitelisting of applications or capabilities that are considered non-distracting. Granular application level filtering and remote triggering of filtering can be utilized. For example, a list of allowed and disallowed applications can be adjusted by the predetermine personnel, e.g., administrator of the service.
In one embodiment, the system includes an application or software that utilizes the CMD's preexisting Virtual Private Network (VPN) capabilities to disallow all or chosen applications on a phone from accessing the cellular network (block applications), allowing only specific applications on a phone access to the cellular network, disallow all other applications (white list of allowed applications), or to disallow a specific list of applications from accessing the cellular network while allowing all other applications (black list of disallowed applications).
The application or software can use the phone operating system's VPN capabilities without the establishment of an actual VPN connection. The data destined for the blocked apps or capabilities using the VPN connection is instead forwarded to an on-phone VPN end point which does not connect to the actual cellular network. This “dead end” connection works for both incoming and outgoing until such time as the local VPN endpoint service is stopped. Blocking of these services can occur through end user interaction or through an external trigger or other techniques within a CMD application, a CMD operating system, or elements of the network that provides service to the CMD.
In one embodiment, where the end user stops the VPN application to thwart the blocking to utilize blocked apps, said application will provide a flag to the SDRS or triggering system so that the SDRS or triggering system can use the flag to alert the authority requiring the blocking that the on-phone blocking system was stopped. This flag can contain context information about the phones physical location, time of event, speed of the vehicle and RF environment (WIFI, Bluetooth etc.).
Alternately, the VDS or other software on the CMD, or the CMD operating system, or in the CMD provider network, can direct data (or other channels of communication to the CMD, such as voice or texting) to a Distributed Network Server (DNS), which can be configured to only provide addresses for certain allowed applications while not providing addresses for applications or capabilities that are to be blocked, providing blocking of disallowed features or applications until the information is directed back to a DNS that provides addresses for all CMD features (unblocking the CMD).
Referring to
Optionally and/or alternatively, a user may override the restricted feature or application on the CMD (step 3516). In this event, step 3506 stops the blocking. The system, in step 3518, can be configured to obtain information indicative of one or more of user of CMD, CMD information, vehicle information and any other information indicative the user of the CMD. In step 3520, the CMD sends an override flag over the network to SDRS to be logged and reported on to the appointed administrator as described above. In step 3522, the system logs the override and context information and alerts a blocking authority, e.g., a parent or vehicle owner. In step 3524, the system sends an override flag and phone contact to the SDRS.
In one embodiment, an end user can interact with the CMD by triggering radio frequency (RF) environment inspection without requiring the end user to interact with their phone's touch screen. In this embodiment, the vehicle RF environment and CMD may both have their own unique identifier which are provided to external systems to associate the user and the location of the vehicle or location of the RF environment, which can be provided by RF sensors in the vehicle that detect a CMD RF signal, or alternately, RF sensors on the CMD that can detect an RF signal broadcast by receiver/transmitters in the vehicle.
In one embodiment, the CMD application can detect a phone tap (quick, low velocity deceleration) or patterns of taps configured to self ID a user. The application then can search the current RF environment for a predetermined unique identifier to further confirm the driver ID. The application then sends the unique RF identifier and the phone's unique identifier to a predetermined outside system. Sending this information to the cloud provides a flag that associates a phone and its user with a specific physical location based on the RF environment. The CMD application can use the CMD operating system's RF and motion detection capabilities to create the phone to physical location flag. The unique identifier on the phone can be set up through the on-phone application. The unique RF environment is established through receiver/transmitter hardware. One specific use case for this innovation is driver identification. The end user would tap their phone upon entering a vehicle to self-identify that they are beginning a trip as the driver.
In one embodiment, the identification of a driver can occur by interaction with the CMD by either using an existing RF environment, or by triggered radio frequency (RF) environment inspection without requiring the end user to interact with their phone's touch screen. In a preferred embodiment, the SDRS can trigger either the VDS or the CMD to begin transmitting or receiving RF signals such as Bluetooth. In a preferred embodiment, the RF environment and CMD both have their own unique identifier which are provided to external systems to associate the user and the location of the vehicle or location of the RF environment.
Referring to
Referring to
If vehicle is moving or about to move go to step 3706. If vehicle is not moving or not about to move repeat step 3702. The number of registered operators for the vehicle is determined in step 3706. In step 3708 passenger alerts can be provided. In a preferred embodiment, the registered operators of a specific vehicle has been pre-established within a data-base by a system administrator.
If one or more registered drivers are registered to the vehicle, go to step 3710 or optionally step 3720 if it is desired to block registered phones prior to confirming which registered CMD's are in the vehicle. Alternately, the CMD's can remain unblocked until the driver identity is established. In step 3710, the CMD's of registered vehicles are queried for the context of the CMD's (context being the environment, including speed, location, direction, time of motion, vibration, RF environment, etc. and the like) and compared with the context of the VDS to determine the number of registered CMD's within the vehicle. If there are no CMDs registered with the vehicle determined to be in the vehicle in step 3710 go to step 3730 and step 3716. If one or more CMDs is registered with the vehicle go to step 3712 to determine vehicle operator.
If only one registered CMD is determined to be in the vehicle, in step 3712, or if a single CMD is established as a vehicle operator CDM through other means described elsewhere, and if that CMD has been restricted in step 3720, then continue restricting the CMD until the end of trip. If that CMD has not been restricted, then restrict the phone is step 3720 until the completion of the trip. If more than one registered CMD's is determined to be in the vehicle in step 3712 and the vehicle operators CMD has not been identified by other means, then in step 3718 alerts or messages may be sent to the CMDs identified as in the vehicle requesting that the passengers or the driver identify the driver. Once the driver ID is established by driver or passenger input, then go to step 3720 to restrict the CMD of the driver, and to step 3716 to unrestrict the CMDs of the passengers. The identification of the vehicle operator CMDs or CMDs within the vehicle may be determined as described herein or with reference to one or more of U.S. Pat. Nos. 8,761,821, 8,787,936, 9,386,447, 9,451,447 and 9,615,213, each of which is hereby fully incorporated by reference. This is a double check to ensure identification is accurate or increase the accuracy of the determination. Go to step 3716 if no registered operators are associated with the vehicle, go to step 3720 if only one registered operator is identified with the vehicle, and go to step 3718 if more than one registered driver is identified as in the vehicle. In step 3716, the restrictions are removed. In step 3718, alerts and/or a communication is provided to all the registered CMDs to assist with driver identification as described above. After the CMD has been determined when the CMD is the vehicle go to step 3720 for all CMDs and step 3618.
In step 3718, a message is sent to all the registered CMDs determined to be in the vehicle from step 3710. The message allows each user of the CMDs within the vehicle to identify the driver. In one implementation send a listing of all the people associated with each of the identified registered CMDs in the vehicle to allow the users of those CMD to identify the operator of the vehicle. After the operator of the vehicle is identified go to steps 3716 for CMDs not identified as an operator, and restrict the identified operator's CMD in step 3720.
Referring now to step 3720 where application functionality of the CMDs is restricted. There are two possible options that may or may not be mutually exclusive.
In the first option, (step 3722) the CMD a VPN connection solution can be utilized by the application to establish a VPN connection that directs data and other capabilities to a custom DNS. In a preferred embodiment, the VPN points all data to the custom DNS. Optionally and/or alternatively, more than one custom DNS can be utilized. In addition, some applications can be whitelisted to not permit the use of the custom DNS, e.g., map applications, that is the application and data will have full functionality. Alternately, the customer DNS can be configured to provide only address to safe applications or whitelisted applications and no address or a custom DNS to other applications. Optionally and/or alternatively, the step 3722 skips the step of the VPN and points the data or application to a custom DNS via other means either utilizing the CMD operating system, or other elements in the provider or other network that can redirect data traffic to a custom DNS server. The result of the step 3724 is that unsafe application are blocked during the operation of the vehicle. In addition, other functionality of the CMD, e.g., SMS, phone, etc., can be blocked as previously described herein. Upon notice from the server that the drive has ended, this VPN is terminated and/or other techniques for routing data to a custom DNS server are terminated and all traffic is allowed
In the second option, (step 3726) a VPN to nowhere is established, e.g., as described herein and also in Appendix F. The VPN is with no underlying networks in order to halt the transmittal of data at the application layer to and from the CMD. The VPN solution in this step allows for a VPN to nowhere as described herein, e.g., Appendix F. In this implementation, the application establishes a VPN connection for all data applications, or for specific distracting applications, with no underlying networks in order to halt the transmittal of data at the application layer to and from the handset. Upon notice from the server that the drive has ended, this VPN is terminated and all traffic is allowed. In step 3728, the VPN can also have whitelisted applications as described herein. In step 3730, the process ends or returns to step 3702.
Optionally, and/or alternatively, the system is configured to restrict or disable features, functions, e.g., applications and texting of the CMD with a telematics connection to the vehicle and/or CMD. In a preferred embodiment, the system described herein and in
Referring to
In a preferred embodiment of this application, the vehicle has an transmitter, e.g., RF transmitter, with unique characteristics, provided by vehicle components, that have been placed or installed within the vehicle, such as Bluetooth, iBeacon, Low Energy Bluetooth, WiFi or NFC. In step 3801, the vehicle is queries for a signal as described herein. In step 3802, a CMD registered to the vehicle receives a unique signal or transmission, e.g., RF signal, indicating that it is in the vehicle and optionally indicating that the vehicle is about to move or moving (either from the reception of a short range RF signal that is constantly transmitting, but when received by a CMD in the vehicle indicates that a CMD is in a vehicle and about to move, or by short range RF signal that is initiated when the power to the vehicle is turned on). Alternately, a CMD associated/registered with the vehicle, may sense that the CMD has begun to move, via motion sensors on the CMD, or by a change in location of the CMD with a previous location of the CMD (geofencing). In step 3802, the CMD provides a signal to a (decision engine) that a CMD registered to a vehicle is moving. The decision engine can then determine if RF sensors such as BT are enabled (Step 3804), and if not, enable RF sensors on the CMD to sense a unique RF environment of a registered vehicle (Step 3806). If such an environment is sensed, then the decision engine can determine that at least one of the registered drivers are in a vehicle that is moving or about to move, and then query other CMD's of registered drivers of the vehicles as shown in step 3810 of
In one implementation, if one or more registered drivers are registered to the vehicle, go to step 3810 or optionally step 3820 if it is desired to block registered phones prior to confirming which registered CMD's are in the vehicle. Alternately, the CMD's can remain unblocked until the driver identity is established.
In step 3810, the CMD's of registered vehicles are queried for the context of the CMD's (context being the environment, including speed, location, direction, time of motion, vibration, RF environment, etc. and the like) and compared with the context of the VDS (context being the environment, including speed, location, direction, time of motion, vibration, RF environment, etc. and the like) to determine the number of registered CMD's within the vehicle. In one embodiment, when the context of the VDS and the context of the CMD are similar or substantially identical it is used to determine if CMD is in vehicle. If there are no CMDs registered with the vehicle determined to be in the vehicle in step 3810 go to step 3830 and step 3816. If one or more CMDs is registered with the vehicle go to step 3812 to determine vehicle operator.
If only one registered CMD is determined to be in the vehicle, in step 3812, or if a single CMD is established as a vehicle operator CDM through other means described elsewhere, and if that CMD has been restricted in step 3820, then continue restricting the CMD until the end of trip. If that CMD has not been restricted, then restrict the phone is step 3820 until the completion of the trip.
If more than one registered CMD's is determined to be in the vehicle in step 3812 and the vehicle operators CMD has not been identified by other means, then in step 3818 alerts or messages may be sent to the CMDs identified as in the vehicle requesting that the passengers or the driver identify the driver. Once the driver identification, e.g., Driver ID, is established by driver or passenger input, then go to step 3820 to restrict the CMD of the driver, and to step 3816 to unrestrict the CMDs of the passengers in the vehicle. The identification of the vehicle operator CMDs or CMDs within the vehicle may be determined as described herein or with reference to one or more of U.S. Pat. Nos. 8,761,821, 8,787,936, 9,386,447, 9,451,447 and 9,615,213, each of which is hereby fully incorporated by reference. This is an optionally “double check” to ensure identification is accurate or increase the accuracy of the determination. Go to step 3816 if no registered operators are associated with the vehicle, go to step 3820 if only one registered operator is identified with the vehicle, and go to step 3818 if more than one registered driver is identified as in the vehicle. In step 3816, the restrictions are removed. In step 3818, alerts and/or a communication is provided to all the registered CMDs to assist with driver identification as described above. After the CMD has been determined when the CMD is the vehicle go to step 3820 for all CMDs and step 3818.
In step 3818, a message is sent to all the registered CMDs determined to be in the vehicle from step 3810. The message allows each user of the CMDs within the vehicle to identify the driver. In one implementation send a listing of all the people associated with each of the identified registered CMDs in the vehicle to allow the users of those CMD to identify the operator of the vehicle. After the operator of the vehicle is identified go to steps 3816 for CMDs not identified as an operator, and restrict the identified operator's CMD in step 3820.
Referring now to step 3820 where application functionality of the CMDs is restricted. In this implementation, there are two possible options that may or may not be mutually exclusive to achieve this functionality.
In the first option, (step 3822) the CMD a VPN connection solution can be utilized by the application to establish a VPN connection that directs data and other capabilities to a custom DNS. In a preferred embodiment, the VPN points all data to the custom DNS. Optionally and/or alternatively, more than one custom DNS can be utilized. In addition, some applications can be whitelisted to not permit the use of the custom DNS, e.g., map applications, that is the application and data will have full functionality. Alternately, the customer DNS can be configured to provide only address to safe applications or whitelisted applications and no address or a custom DNS to other applications. Optionally and/or alternatively, the step 3822 skips the step of the VPN and points the data or application to a custom DNS via other means either utilizing the CMD operating system, or other elements in the provider or other network that can redirect data traffic to a custom DNS server. The result of the step 3824 is that unsafe application are blocked during the operation of the vehicle. In addition, other functionality of the CMD, e.g., SMS, phone, etc., can be blocked as previously described herein. Upon notice from the server that the drive has ended, this VPN is terminated and/or other techniques for routing data to a custom DNS server are terminated and all traffic is allowed
In the second option, (step 3826) a VPN to nowhere is established, e.g., as described herein and also in Appendix F. The VPN is with no underlying networks in order to halt the transmittal of data at the application layer to and from the CMD. The VPN solution in this step allows for a VPN to nowhere as described herein, e.g., Appendix F. In this implementation, the application establishes a VPN connection for all data applications, or for specific distracting applications, with no underlying networks in order to halt the transmittal of data at the application layer to and from the handset. Upon notice from the server that the drive has ended, this VPN is terminated and all traffic is allowed. In step 3828, the VPN can also have whitelisted applications as described herein. The whitelisted application may be specified by a user or master user. In step 3830, the process ends or returns to step 3802.
Standalone CMD application and/or software development kit (SDK) module can be used to implement this embodiment. The SDK module allows for implementation of the software on updates on existing software on the CMD. There is no user interface when the SDK is implemented, but allows for implementation of the functionality.
Referring to
In step 3908 the CMD is queried to determine if in the vehicle with any technique described herein. If CMD is in vehicle then the system restricts one or more applications as described herein (step 3920). If the CMD is not in the vehicle then the system ends (step 3930).
A method for generating an auto-response message according to an application on a cellphone is generally depicted with reference to 4000. In this embodiment, authoritative entities such as companies and legal guardians have the ability to have auto-response messages for certain phone on a cellular network.
In step 4002, they system identifies CMDs in a moving vehicle of interest as described herein. After the system has determined the CMD is moving the application on the CMD begins querying for any incoming short mmessage service (SMS) messages, e.g., text messages (step 4004).
In step 4006, the application sends SMS message to user of CMD and application identified as an operator of the vehicle.
In step 4008, the application inspects an origin of the SMS message.
In step 4010, the application notifies the server that a SMS message was received from the identified origin of step 4008.
In step 4012, the server sends an auto-generated response messaged, e.g., SMS, to sender. The auto-generated message is configured to notify the sender the recipient is currently operating a vehicle.
In step 4016, the server and/or application are configured to determine a current operation has ended, e.g., drive ended. This is done with any technique described herein.
In step 4014, the application stops listening for SMS messages (step 4004).
Referring to
In this embodiment, one or more sensors include a vehicle powered BLE beacon device is utilized, software on the CMD, and a system described herein. In step 4102 the vehicle and BLE beacon device are in a power off position.
In step 4104 when the vehicle ignition is in an on configuration the beacon is broadcasting a signal. In step 4106 the CMD senses the signal being emitted by the beacon. In step 4108 when the signal is sensed or recognized the application wakes up or becomes active. In step 4110 after the application is active its sends a unique CMD identification and unique beacon identification to system, e.g., SDS 125. The SDS 125 determines the CMD in the vehicle that is being operated or about to be operated. In step 4114, the SDS 125 signals MDSP 130 to restrict the identified CMDs from step 4112.
In step 4116, the CMD periodically queries and scans for signals from beacons, e.g., 30, 38 and 39, and other CMDs and sends any discovered unique beacons and CMD identifications to the SDS 125. In step 4118, the SDS 125 determines whether the CMD is being utilized by an operator of the vehicle as described herein. In one approach [add details]. In step 4120, the software continues to send CMD identification even when the beacon identifications are not discovered to SDS 125. In step 4122, the SDS 125 uses the CMD identification and lack of beacon identification to programically deduce the operation of the vehicle has ended. In step 4124, the SDS 125 notifies the MDSP 130 to unrestrict the CMD restricted in step 4112. In step 4126, when the vehicle ignition is an off or key off position the beacon or sensors 37, 38, 39 no longer transmit a beacon identification.
Referring to the process 4200 is related to a do not disturb trigger and bypass event. In step 4202, the SDS 125 identifies a CMD as moving in a vehicle. In step 4204, the software places the identified CMD from step 4202 in a do not disturb mode. In step 4206, a user of the CMD attempts to disable or override the do not disturb mode of the CMD. In step 4208, the software rejects the attempts to override or disable and notifies SDS 125 of attempted override. In step 4210, the SDS 125 receives the notification from step 4208 and notifies an administer of the account regarding CMD through one or more of text, email or other means. In step 4212, a user and vehicle operator of the CMD begins to utilize applications, e.g., audio, video, multimedia streaming and combinations of the same. In step 4214, the CMD application queries multimedia or applications that is not whitelisted. Whitelisted applications are user or system administration preconfigured. The application restricts non-whitelisted multimedia or applications. A whitelisted application could be a navigation applications, e.g., Waze, Google maps or the like. In step 4216, user ends whitelisted application. In step 4218, the SDS determines whether operation of the vehicle has ended. If ended the system goes to step 4220 where application and multimedia restrictions are removed.
In step 4302 the SDS 125 determines an identification of CMD in a moving vehicle with any technique described herein. In step 4304, the software on the identified CMD restricts or cancels all non-ongoing notifications or other predetermined notifications that can be configured by a user or administrator of the CMD.
In step 4306, the new notification is presented to be displayed on the identified CMD.
In step 4308, software on the CMD is configured to programically deduced if notification is emitted from a whitelisted source, e.g., application or a non-whitelisted source. If received from a whitelisted source then go to step 4310 and display notification. If received from a non-whitelisted source go to step 4312 and not display notification or cancel the notification before it can be displayed.
In step 4314, the SDS 125 determines if vehicle operation has end with one or more techniques described herein. Go to step 4316 if operation of vehicle has ended. In step 4316, restore all notifications and operation of identified CMD.
Referring to the process 4400 is related to a reporting mechanism for a user who attempts to or does override a restricted functionality of the CMD. In step 4202, an end user uses or activates an override features of an application of a restricted CMD. In step 4204, the application on the CMD removes all restrictions on the CMD. In step 4406, the application and/or CMD transmits a notice to an SDS 125 having information indicative of the override command. In step 4408, the SDS receives the notification and notifies an administrator of the CMD or application.
In step 4410, an end user of the restricted CMD denies a required permission and in step 4412 the application confirms the required permission was denied and transmit a notice to the SDS regarding infraction in step 4432.
In step 4414, an end user of the restricted CMD revokes a required permission (previously granted). In step 4416, the application confirms the required permission was revoked and transmits a notice to the SDS regarding infraction in step 4432.
In step 4418, an end user of the restricted CMD attempts to disable a VPN. In step 4420, the application confirms the attempted disabling of the VPN and transmits a notice to the SDS regarding infraction in step 4432.
In step 4422, an end user of the restricted CMD attempts to disable a do not disturb feature of the CMD or application. In step 4424, the application confirms the attempted disabling of the do not disturb feature and transmits a notice to the SDS regarding infraction in step 4432.
In step 4426, an end user of the restricted CMD attempts to send a SMS message on a restricted CMD. In step 4428, the application confirms the attempted transmission of the SMS message and transmits a notice to the SDS regarding infraction in step 4432. In step 4430, the SDS receives the notification and notifies an administrator of the restricted CMD or application.
Referring to
In step 4506, the SDS outputs a signal to configured to restrict one or more application on each of the identified CMDs. The signal can be sent directly to the CMDs and restrict on the CMDs or restricted as the service provider or combination of the same. In addition, the signal or additional signal transmit a message to be displayed on each of the identified CMDs asking the users to identify the operator of the vehicle.
In step 4508, the application of each of the CMDs updates and all CMDs are restricted, e.g., one or more application, as described herein. Moreover, a message is displayed on each of the CMDs. In step 4510, users of the restricted CMDs must selected or identify the vehicle operator's CMDs. Each of these identifications are sent to SDS in step 4510. In step 4512 the SDS determines the operator from the received identifications and unblocks each of those CMDs as described herein.
In another implementation, there are some power consumption techniques that can be utilized. For example, rather than querying any CMD for context or sensors when the vehicle is moving or about to move the system only queries ones that could possibly be in the vehicle. In implementation, if an operator CMD has been identified as in a different vehicle, or a CMD is known to be in a location that would make it impossible for them to be in a particular vehicle (such as in another state), they are not queried as they can't be in the vehicle. In one implementation, the CMD is queried a single time at the end of any drive to know where the location of the CMD is, and then it can be mathematically determined if it is possible that could be associated with a subsequent drive (could the CMD have travelled from the previous location at end of trip to the start of a subsequent trip given the time and distance involved). Moreover, as soon as a CMD has been identified in a deterministic manner (whether present in the car or definitively not in the car), querying of the CMD can be terminated to save power.
Also, the CMDs can be intelligently queried, e.g., if the CMDs have been determined to be in a vehicle, and the vehicle could be in a mode to drop-off a passenger, or to switch drivers (i.e. the car has stopped), rather than query throughout the drive CMD contexts, CMD context can be queried only during this mode to determine if drivers have changed. Optionally, CMDs can be queried mid-drive, e.g., as the car approaches the last known location of a CMD, that CMD can be queried for a brief period of time to determine if the CMD owner is being picked up. Optionally, CMDs previously determined to be associated with an occupant in the vehicle can be queried to send us a single updated location at the end of a drive, to be stored and used at the beginning of a subsequent drive to optimize battery use.
In yet another implementation, the system is configured with tattletale logic. The tattletale logic allows passengers to identify who is operating the vehicle when more than one CMD of a registered operator is identified in the vehicle. For example, when there are more than one CMDs registered with a vehicle and/or detected in vehicle, the system can be configured to provide alerts/messages that allow passengers to unblock their CMDs simply by identifying the operator of the vehicle. This may done in one or more of the following ways.
When multiple occupants are detected in the vehicle and no driver has yet been established, they system is configured to show a list of occupants on the CMD's in the vehicle (other than the phone's current user) and allows a user to select the driver. For example, if John, Mary, and Anita were identified as occupants, John's CMD would show the options of “Mary” and “Anita” as the vehicle operator. Mary's phone would show “John” and “Anita” as options as the vehicle operator. In this implementation, the current user of the CMD is not displayed in order to prevent self-id (and interacting with the phone) as the driver. The driver should not be identified himself/herself while driving. Alternately the system can provide a notice that allows the driver to self ID safely (such as when the vehicle is stopped, or by the operator handing their CMD to a passenger to identify themselves as the driver.
In addition, in this implementation, when multiple occupants are detected in the vehicle and a driver has been established, the system is configured to transmit a message to each of the CMDs in the vehicle showing a list of occupants other than the phone's current user and the current driver. This allows a user to change who is driving—in case a mistake was made with the selection, or in case the driver has actually changed during the trip. Using the same example names above, if John is driving, Mary's phone will only display “Anita” as a selection. Again, this is because we don't want Mary self-identifying as the driver if she is currently driving the vehicle.
Moreover, in one implementation the application or software is configured to programmatically display different options based on how the driver was established. For example, the system is configured to establish a driver (rather than the driver being manually established through tattletale logic), the application would display on the driver's phone the tattletale logic. This allows a mis-identified driver to quickly tattletale on the correct user who is driving. Alternatively, if the driver has been manually identified (through tattletale, or self-id prior to the drive starting), the application does not display tattletale options, but rather just an action for override. This is again to discourage a driver from interacting with his/her phone during the drive.
In another implementation, the system is configured to provide a distracted driving function as an SDK feature of an existing application, e.g., via a software update. In this implementation, a code portion was added to any existing application to provide a restriction of the CMD. The SDK is configured so all the key functions occur without any additional development of the application or user interface, e.g., using notifications to provide the following without needing any additional application development. In one implementation, the data based applications are blocked while whitelisting others. The SMS usage can also be blocked as described herein or reported. Additionally, the elimination of alerts when an SMS is received, providing messaging to the sender of a message that the driver is driving, the SDK being functional even if the app is killed.
In one implementation, the system is configured to restrict functionality of the CMDs from a network level. For example, telematics are configured to ID drivers as described herein. However, instead of providing a signal to the Telco to turn off content, a signal is sent to the phone to create a VPN. The VPN creates data channels routed to an external address, which allows two blocking approaches: Distracting content is sent to VPN to nowhere as described in Appendix F.
In one implementation, the non-distracting content is allowed by it not being included in the VPN e.g., whitelisted applications. In the instance where SMS (text messages) are not blocked, SMS alerts are turned off by the SDK while driving, so when text messages are received, the driver is not alerted. Optionally, if the driver sends a text message while driving, an alert can be sent to the system administrator that the driver was messaging while driving. Optionally, this alert can also provide context information such as speed and location for when the text message was sent.
In one implementation, a custom DNS Server is configured to only provide addresses for safe or whitelisted applications and other applications the DNS does not provide addresses. For example, a VPN can be activated to programmatically alter the CMD's DNS server to a real hosted DNS resolver. The DNS resolver will point the application to its own set of whitelisted/blacklisted rules and therefore the blocking is performed at this layer instead of on the handset itself.
Optionally and/or alternatively, the above systems can be implemented by downloading software, e.g., application, or an SDK can be utilized with existing applications via an update. In this implementation, a registered CMD connects via a signal in the vehicle, e.g., Bluetooth. The CMD sends a communication over the network after it recognizes it has been paired or recognizes the vehicle in absence of pairing. The system is configured to recognize a registered vehicle and/or CMD from the communication from the CMD. The system can then query to determine all registered CMDs with the vehicle. One or more of the methods described herein are utilized to determine the vehicle operator.
There are features in the system to override a user from turning off connectivity features on the CMD, e.g., Bluetooth features, WiFi features, radio, or the like. However, there are software code portions configured to sense motion of the CMD and if the connectivity features of the CMD are off it turns them on to determine if there is a corresponding Bluetooth signal present that corresponds to a registered vehicle. If none is found the system assumes the CMD is in some other vehicle (bus), and turns off the connectivity features.
In one implementation, the following is a method for determining if a vehicle, e.g., hybrid or electric car, stops at a red light (which can be construed as a trip ending) vs. actually the key is turned off event, in such an instance, the system does not want to disable and enable at each red light. In such a case, there is a stop/start methodology that is configured to receive an “IGN_TIMER” event when the car has stopped, e.g., at a red light, a stop sign, or has been turned off. As soon as the system receives this “IGN_TIMER” event it is configured to begin to query the CMDs which have identified as occupants in the vehicle to determine motion from one or more of speed, acceleration, location, BLE, and other technologies to determine deterministically if a drive has ended. If the system instead receives a “HEARTBEAT” from the OBDII module or vehicle system, the system immediately requests that the phones CMDs send data, and allow the drive to continue.
Moreover, there are methods for determining if a car is in a black spot, in a garage, or has stopped. The “IGN_TIMER” method above uses the same logic if the system receives a “STOPPED” message from the OBDII module, or if the module has not checked in with the server in 45 seconds (it's required to check-in every thirty (30) seconds, but we allow some latency). If the server hasn't heard from the module in five (5) minutes, and it hasn't stopped the trip due to the parameters above, the server unblocks the phones associated with the trip. This is to ensure we never leave a phone in a disabled state. If at any point the server hears from the module again, and the trip is still ongoing, it immediately blocks the same phones which had been unblocked.
Moreover, the system can be configured to read the strength of the connection signal from the VDS or the CMD and how quickly it degrades, or, using database information that shows where the black spots (areas of poor coverage) and parking garages are. thereby, when entering parking garage, and telematics and CMD signals are interrupted, it is desirable to either quickly enable the phone (in the event that the car has entered a parking garage, and therefore a trip will soon end), however, a loss of signal could result from driving through a weak area of coverage (black spot), in which case the system should not enable quickly, but rather wait until the vehicle emerges from the black spot (if they system enables too early, it would distract the driver with saved messages being forwarded). or to not enable the phone if the vehicle is in an area of poor coverage where enabling the CMD may provide distracting messages to be received.
Moreover, if the CMD or VDS strength quickly drops from a strong signal to a weak signal quickly, the system can be configured to assume it is in a parking garage and quickly re-enable, as the quick degradation of signal indicates the car has gone underground, and is likely parking. In addition, if the strength slowly drops from strong to weak, the system can determine that it is approaching a black spot of no or weak signal, and wait for the signal to re-strengthening without re-enabling. A database can be either created from data collected from that above, learning where the black spots and garages are, and respond accordingly based on location. A database can also be accessed that shows where parking garages are (from Google or others), or from the Telco's or other sources who have recorded the location of black spots or no or weak signal. The system can be integrated with locations, e.g., Google Places in the Android SDK. In the same scenarios as above, the server queries the phones identified as occupants for their current “place”. If this is deemed to be a parking garage/lot, or a place of business, and exceeds a certain confidence threshold, blocking or re-enabling decisions can be made using that information.
In one implementation, the system is configured with intelligent CMD querying. This was discussed above (as a battery-saving feature) and also can be configured with a specific time/distance algorithm in order to determine if the last location received from one or more CMDs the database is updated enough such that if a drive were to immediately begin for a module on that phone's account, would we be able to deterministically understand if that phone was a potential driver candidate. CMDs last known location is from the vehicle, the less we query that phone to update its location (up to a minimum query value of once per week). This is dynamically calculated every minute and any phone requiring an updated location is sent a location request from the server. This is a high-efficiency type of request which instructs that application to simply acquire the last known location from the operating system. This often does not require the phone to even turn on GPS.
Moreover, when a drive begins, the system can be configured to use a combination of algorithms to determine which of CMDs the server needs to query to determine the operator of the vehicle. These algorithms are based on the following inputs and information, Do Not Query [EXCLUDE]: i) is the CMD already an occupant on another ongoing trip?, ii) is the last known location from the CMD so far away from the vehicle that no standard form of travel could allow the phone to reach the car in time for it to be an occupant?, and Query [INCLUDE]: i) is the phone very close to the car?, ii)—Has this phone historically often been an occupant in this vehicle?, iii) has this phone historically often been identified as the driver for this vehicle?, iv) was this phone the driver of the previous trip? v) was this phone an occupant of the previous trip?, vi) has this phone historically been an occupant for trips that start in the same location this trip is starting from?, and vii) has this phone historically been an occupant for trips that start at this same time? (e.g. historically John is an occupant for most trips that start at 5 am).
In one implementation, the system is configured for automatic driver identification. In this implementaiton, driver identification is different from occupant identification. Driver identification only occurs after we've definitively determined which users are in the vehicle. Driver identification attempts to discern which of these occupants is the sole driver. The system uses information from previous drives in addition to the current drive in order to attempt to automatically assign a driver to a drive. Until a strong historical knowledge of drives is built up over time, we tend not to attempt to discern between an occupant and a driver (unless there is only a single occupant in the vehicle). We allow tattletale and self-ID for these circumstances to identify the driver.
One or more of the following information is used in order to programically determine the driver of the vehicle after the system has already determined the occupants: i) is this the only user that has been found to be in the car (and we've definitely located all other users)? (Assign this user as the driver), ii) does this trip have the exact same occupants as the previous trip, and the previous trip had a driver assigned to it? (Assign the same driver as the previous trip), iii) do the overwhelming majority of trips in this specific vehicle have the same driver? (assign this driver if he/she has been identified as an occupant on this trip), iii) do the overwhelming majority of trips with these exact occupants have the same driver? (assign this driver), iv) do the overwhelming majority of trips in this specific vehicle with these exact occupants have the same driver? (assign this driver), v) do the overwhelming majority of trips which start at this location have the same driver? (assign this driver if he/she has been identified as an occupant on this trip), vi) do the overwhelming majority of trips which start at this location with these exact same occupants have the same driver? (assign this driver), and vii) do the overwhelming majority of trips which start at this specific time have the same driver? (assign this driver if he/she has been identified as an occupant on this trip).
In one implementation, a CMD discovery process includes identify a CMD as being in a deterministic state (whether included in the vehicle, or definitely excluded from being in the vehicle), the server sends this phone a “Phone Discovery Request”. This CMD then begins advertising itself to the other phones on the account using a combination of Bluetooth, local Wi-Fi, and ultrasonic frequency. If it detects or is detected by another phone on the account, the server is notified and the other phone is assigned the same definitive state (included/excluded). This allows us to quickly chain together decisions our server has made from one CMD to another, simply by allowing the phones to discover nearby phones on the account. In one embodiment, the identification of the driver can be provided by a manual ID entry at the beginning of a drive, by entering the driver identification, i.e., driver ID, on a device in the vehicle such as an electronic logging device (ELD), via a communication, e.g., text message, phone call, Bluetooth or other Wifi beacon associated with the driver. In a preferred embodiment, the CMD of the driver has been registered as a potential driver of the vehicle.
In an additional implementation, the driver ID is established by a schedule or some other unambiguous association of a particular driver to a particular vehicle, such that when a particular vehicle is moving, the driver, as well as the CMD associated with the driver are determined from this association, and therefore other driver identification techniques are not required. This driver ID information (as with driver ID information determined through other techniques described elsewhere herein), can be used to trigger a notification to a third party service provider, such as that provided by a DNS, a Mobile Device Management service provider, or a Mobile device Virtual Network Operator (MVNO), such that distracting content is blocked during a drive at the MDM, DNS or MVNO level rather than at the Telco service provider level.
In a preferred embodiment, that is thwart-resistant or user override proof, the driver of a vehicle can be determined without a VDS in the vehicle via a wireless RF transmitter or other wireless transmitter in the vehicle, such as with a Bluetooth beacon, Wifi, or traditional Bluetooth or ultrasound that incorporates a unique identifier, and that may transmit when the vehicle power is engaged, or that is powered continuously. The signal is such that it can be sensed by receivers on the CMD. In a preferred embodiment, motion is detected on a CMD previously registered as associated with a potential driver of the vehicle, through any of the techniques described elsewhere including a change in the RF environment of the CMD, changes in location, sensors in the CMD that determine CMD motion, or the CMD crossing a previously established geofence, boundary. The CMD then provides a notification over the network it is in motion to the SDS or other aspect the mobile services control system 10. The notification then triggers a query of the CMD by the “system” with regard to what sensors are active that could sense the presence of a short range RF signal generated within the vehicle. If the sensors are active, and there are no unique recognized signals from the vehicle, then the “system” determines that the individual associated with a vehicle, is not driving that vehicle. If the sensors are not active, a signal is sent to the CMD that triggers the sensor to be turned on. If after the sensor is turned on, and there is no unique signal detected, then the “system” determines that the individual associated with a vehicle, is not driving that vehicle and disabling of the CMD occurs. In either the case of the sensors being already enabled, or being enabled on sensing of CMD motion, and the unique transmission is detected, the “system” is able to establish that the CMD is in the vehicle, and may be associated with the driver of the vehicle. At that point, CMD distractions can be blocked via various means elsewhere described. In a preferred embodiment, the “system” then similarly queries other CMD's associated with a particular vehicle to determine if they are also in the vehicle, and if the “system” determines that there are multiple potential drivers in the vehicle, then the driver can be identified via other techniques described elsewhere.
The following Appendix A is a portion of high level program code illustrating information that can received from VDS according to one or more embodiments described herein.
The following Appendix B is a portion of high level program code illustrating information that can received from VDS according to one or more embodiments described herein. This information includes at least speed of vehicle, location of vehicle, relative times of each of the foregoing and other information indicated in the Appendix B.
The following Appendix C is a portion of high level program code illustrating information that can received from CMD according to one or more embodiments described herein.
The following Appendix D is a portion of high level program code illustrating information and endpoints of a trip to determine what state of the CMD.
The following Appendix E is a portion of high level program code illustrating a CMD communication to request from the SDS whether or not it should be reporting the CMD contexts to the SDS if it missed a trigger (push notification) from the SDS. For example, this portion of the code tells the CMD how, how often and for how long it needs to send the CMD context to the SDS.
The following Appendix F is a portion of high level program code illustrating software to determine how to exclude a CMD from being restricted.
Without intending to limit the scope of the invention, the following examples illustrate how various embodiments of the invention may be made and/or used.
Example 1 illustrates an experiment in which probabilities are used to include a CMD in a vehicle at a SOT. In this Example 1, the SDRS system running on a hosted platform evaluates inputs from all CMDs and VDSs to determine probability that a CMD is in a vehicle at a SOT. Calculations were performed with one or more computation equipment described herein. The following Equations 1 and 2 were used in the calculations.
Total Inclusion/Exclusion of CMD in vehicle likelihood=(p(n−1)+(p(n)−(p(n−1)*p(n))) Equation 1
In Equation 1, n is a filter weight in range from 0 to 1.
TotalInclusionLikelihood=InclusionLikelihood−ExclusionLikelihood Equation 2.
In this Example 1, it was started inclusion and exclusion each at 0.0 as there were no preexisting factors that would make any driver a more likely candidate than another. Next it was determined which filters have returned LIKELY_INCLUDED through their use of various sensors and comparison techniques outlined throughout this document. Three filters returned LIKELY_INCLUDED: SINGLE DRIVER, PREVIOUS DRIVER, MOTION.
A retrieved filter weight of each filter from a configuration as follows was used: SINGLE DRIVER (weight=0.6), PREVIOUS DRIVER (weight=0.2), MOTION (weight=0.3).
Applied the following Equations in order to determine inclusion probability:
p(1)=weight1+(weight2−(weight1*weight2))
p(1)=0.6+(0.2−(0.6*0.2))
p(1)=0.68
p(2)=p(1)+(weight3−(p(1)*weight3))
p(2)=p(1)+(0.3−(p(1)*0.3))
p(2)=0.679 . . . +(0.3−(0.68*0.3))
p(2)=0.78
Determined inclusion likelihood was 0.78.
Example 2 illustrates an experiment in which probabilities are used to exclude a CMD in a vehicle at a SOT. In this Example 2, the system was utilized to determine probability that a CMD was not in a vehicle. Calculations were performed with computation equipment described herein. Inputs received included inputs from SDRS system running on a hosted platform evaluates inputs from all CMDs and VDSs. Equations 1 and 2 were used in this Example.
It was determined which filters have returned LIKELY_EXCLUDED through their use of various sensors and comparison techniques outline throughout this document. One filter returned LIKELY_EXCLUDED: ADJACENT_DISTANCE as the vehicle and CMD were a large distance away
The system retrieved the filter weight of each filter from a configuration as follows: ADJACENT_DISTANCE (weight=0.3). The following equations were applied in order to determine exclusion probability:
(1)=weight1
p(1)=0.3
Determined exclusion likelihood as 0.3
Next, the system calculated a combined total weight of all LIKELY_INCLUDED filters as follows:
totalInclusionWeight=weight1+weight2+weight3
totalInclusionWeight=0.6+0.2+0.3
totalInclusionWeight=1.1
A calculated combined total weight of all LIKELY_EXCLUDED filters was done as follows:
totalExclusionWeight=weight1
totalExclusionWeight=0.3
Calculated the total weight of all filters:
totalWeight=totalInclusionWeight+totalExclusionWeight
totalWeight=1.1+0.3
totalWeight=1.4
Calculated the weighted value of the inclusion result based on total weight:
weightedInclusion=inclusion*(totalInclusionWeight/totalWeight)
weightedInclusion=0.78*(1.1/1.4)
weightedInclusion=0.61
Calculated the weighted value of the exclusion result based on total weight:
weightedExclusion=exclusion*(totalExclusionWeight/totalWeight)
weightedExclusion=0.3*(0.3/1.4)
weightedExclusion=0.06
Calculated the total value of weightedInclusion and weightedExclusion in order to use as a baseline to calculate the final percentages:
totalWeightedValue=weightedInclusion+weightedExclusion
totalWeightedValue=0.61+0.06
totalWeightedValue=0.67
Calculated the final inclusion percentage based on the totalWeightedValue:
finalInclusion=weightedInclusion/totalWeightedValue
finalInclusion=0.61/0.67
finalInclusion=0.9
Calculated the final exclusion percentage based on the totalWeightedValue:
finalExclusion=weightedExclusion/totalWeightedValue
finalExclusion=0.06/0.67
finalExclusion=0.10
Calculated the overall final inclusion likelihood based on the final inclusion and exclusion percentages:
finalInclusionLikelihood=finalInclusion−finalExclusion
finalInclusionLikelihood=0.9−0.10
finalInclusionLikelihood=0.81
Compared the finalInclusionLikelihood with the inclusion cutoff specified in our configuration:
Inclusion Cutoff=0.8
0.81>0.8
Determined this phone to be INCLUDED in the vehicle at a SOT event.
In conclusion, the CMD's likelihood was great enough to be considered included in the trip.
Various embodiments of the present disclosure have been described in detail, it is apparent that modifications and alterations of those embodiments will occur to those skilled in the art. However, it is to be expressly understood that such modifications and alterations are within the scope and spirit of the present disclosure, as set forth in the following claims.
The foregoing discussion of the disclosure has been presented for purposes of illustration and description. The foregoing is not intended to limit the disclosure to the form or forms disclosed herein. In the foregoing Detailed Description for example, various features of the disclosure are grouped together in one or more embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed disclosure requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate preferred embodiment of the disclosure.
Moreover, though the present disclosure has included description of one or more embodiments and certain variations and modifications, other variations and modifications are within the scope of the disclosure, e.g., as may be within the skill and knowledge of those in the art, after understanding the present disclosure. It is intended to obtain rights which include alternative embodiments to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangeable and/or equivalent structures, functions, ranges or steps are disclosed herein, and without intending to publicly dedicate any patentable subject matter.
The present application claims the benefit of an claim priority from U.S. Provisional Patent Application No. 62/813,479 filed Mar. 4, 2019, which is incorporated herein by reference in its entirety. Provisional patent application Ser. No. 61/227,404 filed Jul. 21, 2009, entitled “Method and System for Controlling Mobile Devices in a Moving Vehicle”, provisional patent application Ser. No. 61/267,064 filed Dec. 6, 2009, entitled “Method and System for Controlling Mobile Devices in a Moving Vehicle”, PCT application Ser. No. PCT/US2010/042793 filed Jul. 21, 2010, entitled “Method and System for Controlling a Mobile Communication Device in a Moving Vehicle, provisional patent application Ser. No. 61/533,358 filed Sep. 12, 2011, entitled “Method and System for Controlling Mobile Devices in a Moving Vehicle, provisional patent application Ser. No. 61/745,349 filed Dec. 21, 2012, entitled “Method and System for Controlling a Mobile Communication Device, Pat. Reg. No. 8,761,821 registered Jun. 24, 2014, entitled “Method and System for Controlling a Mobile Communication Device in a Moving Vehicle, Pat. Reg. No. 8,787,936 registered Jul. 22, 2014, entitled “Method and System for Controlling a Mobile Communication Device in a Moving Vehicle, Pat. Reg. No. 9,451,447 registered Sep. 20, 2016, entitled “Method and System for Controlling a Mobile Communication Device in a Moving Vehicle”, Pat. Reg. No. 9,386,447 registered Jul. 5, 2016, entitled “Method and System for Controlling a Mobile Communication Device, Pat. Reg. No. 9,615,213 registered Apr. 4, 2017, entitled “Method and System for Controlling and Modifying Driving Behaviors, patent application Ser. No. 15/191,286 filed Jun. 23, 2016, entitled “Method and System for Controlling a Mobile Communication Device, Ser. No. 15/233,784 filed Aug. 10, 2016, entitled “Method and System for Controlling a Mobile Communication Device in a Moving Vehicle, patent application Ser. No. 15/477,536 filed Apr. 3, 2017, entitled “Method and System for Controlling and Modifying Driving Behaviors; each of the foregoing referenced applications and patents are hereby incorporated by reference as if fully set forth herein.
| Number | Date | Country | |
|---|---|---|---|
| 62813479 | Mar 2019 | US | |
| 61745349 | Dec 2012 | US | |
| 61533358 | Sep 2011 | US | |
| 61267064 | Dec 2009 | US | |
| 61227404 | Jul 2009 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/US2020/021017 | Mar 2020 | US |
| Child | 17464324 | US | |
| Parent | 15477536 | Apr 2017 | US |
| Child | 17334184 | US | |
| Parent | 14139698 | Dec 2013 | US |
| Child | 15477536 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17334184 | May 2021 | US |
| Child | PCT/US2020/021017 | US | |
| Parent | 13612748 | Sep 2012 | US |
| Child | 14139698 | US | |
| Parent | 12841077 | Jul 2010 | US |
| Child | 13612748 | US |
