Abstract:
A message control system for a portable device that communicates through a link with a packet switched network. Integrated sensors in the portable device are configured to generate speed data. The system comprises a message manager that logs when and where messages are received, monitors the speed data, and uses the data to determine if an incoming message is authorized. If the message is authorized it is displayed on the portable device, and if it is not authorized the system sends an outgoing message over the network link indicating that the incoming message is not authorized.

Description:
[0001]    This application is a continuation of U.S. patent application Ser. No. 13/188,856, filed Jul. 22, 2011 entitled: FAILURE DETERMINATION SYSTEM, which is a continuation of U.S. patent application Ser. No. 12/851,488, filed Aug. 5, 2010 entitled: AN APPLICATION MANAGEMENT SYSTEM FOR MOBILE DEVICES, now U.S. Pat. No. 8,020,028, issued Sep. 13, 2011, which is a continuation of U.S. patent application Ser. No. 11/616,650, filed Dec. 27, 2006 entitled APPLICATION MANAGEMENT SYSTEM WITH CONFIGURABLE SOFTWARE APPLICATIONS, now U.S. Pat. No. 7,793,136, issued Sep. 7, 2010, which is a continuation of U.S. Pat. No. 7,178,049, filed Apr. 24, 2002 and issued Feb. 13, 2007 entitled: METHOD FOR MULTI-TASKING MULTIPLE JAVA VIRTUAL MACHINES IN A SECURE ENVIRONMENT, which are all incorporated by reference in their entirety. 
         [0002]    This application incorporates by reference U.S. patent application Ser. No. 09/841,753, filed Apr. 24, 2001 entitled: OPEN COMMUNICATION SYSTEM FOR REAL-TIME MULTIPROCESSOR APPLICATIONS, now U.S. Pat. No. 6,629,033, issued Sep. 30, 2003, and U.S. patent application Ser. No. 09/841,915, filed Apr. 24, 2001 entitled: METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM, now U.S. Pat. No. 7,146,260, issued Dec. 5, 2006. 
     
    
     BACKGROUND OF THE INVENTION 
       [0003]    Distracted driving is a dangerous epidemic. According to the official U.S. Government Website www.distraction.gov, ‘Text and Drive’ behavior was the cause of 16,141 highway deaths from 2001 to 2007 in the United States alone. Additionally, and citing the same source, in 2010, there were over 416,000 non-fatal accidents and over 3,092 people were killed in distracted driving crashes on American roadways. 
         [0004]    Effecting real change to this epidemic will need to include a comprehensive understanding of the mobile phone and texting culture. Mobile phones make information accessible anytime and anywhere, and put information at our fingertips. Citing again the official U.S. Government Website www.distraction.gov, in June 2011, more than 196 billion text messages were sent or received in the US, up nearly fifty percent in two years. Today more than sixty-three percent of teens text every day, with some teens texting up to 100 messages a day. More alarming, a 2012 report from the U.S. Center for Disease Control shows 60% of teen drivers are texting while driving. Currently, one in three US adults downloads applications to a cell phone or tablet computer, and application downloading is highest among young adults age 18-29. 
         [0005]    There is an opportunity to compliment consumers&#39; appetite for anytime-information to mobile and social networking technology while providing them with an asset that allows them to make safe and productive choices. Large entities like auto makers, smartphone providers and insurance companies are grasping for solutions to the Text and Drive epidemic. 
         [0006]    In a discussion of prior art U.S. Pat. No. 6,690,940, the patent describes a system for selectively disabling use of at least selected features of a stand-alone electronic device under a predetermined set of conditions. 
         [0007]    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 used advantageously 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. However, the prior art does not address these safety features without disabling important elements of the portable device. 
         [0008]    What is needed is a smart message control system and method that manages messages for a portable device without disabling features of the portable device. 
       SUMMARY OF THE INVENTION 
       [0009]    A message control system and method that does not disable any functionality of the electronic device by managing and controlling messages sent to and from the electronic device by using a message manager that logs when and where messages are received, monitors the speed of the electronic device with an integrated sensor and uses the data to determine if an incoming message is authorized. If the message is authorized it is displayed or otherwise processed on the portable device in the normal manner, and if it is not authorized the system sends an outgoing message over a network link indicating that the incoming message was not displayed or processed in the normal manner. 
         [0010]    The foregoing and other objects, features and advantages of the invention will become more readily apparent from the following detailed description of a preferred embodiment of the invention, which proceeds with reference to the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]      FIG. 1  is a diagram showing a Java stack with an additional Secure Real-time Executive (SRE) layer. 
           [0012]      FIG. 2  is a diagram of a multiprocessor system that runs multiple Java Virtual Machines that each include a SRE. 
           [0013]      FIG. 3  is a detailed diagram of the managers in the SRE. 
           [0014]      FIG. 4  is a block diagram of how the SRE manages a multiprocessor system. 
           [0015]      FIG. 5  is a bock diagram showing how a task manager in the SRE operates the multiprocessor system in a lock-step mode. 
       
    
    
     DETAILED DESCRIPTION 
       [0016]    A Java application stack includes a Java layer  5  for running any one of multiple different applications. In one example, the applications are related to different vehicle operations such as Infrared (IR) and radar sensor control and monitoring, vehicle brake control, vehicle audio and video control, environmental control, driver assistance control, etc. 
         [0017]    A Java Virtual Machine (JVM) layer  16  provides the hardware independent platform for running the Java applications  5 . A Jini layer  12  provides some limited security for the Java applications that run on different machines. However, the Jini layer  12  does not provide the necessary reconfiguration and security management necessary for a distributed real-time multiprocessor system. 
         [0018]    A Secure Real-time Executive (SRE)  14  provides an extension to the JVM  16  and allows Java to run on different processors for real-time applications. The SRE  20  manages messaging, security, critical data, file I/O multiprocessor task control and watchdog tasks in the Java environment as described below. The JVM  16 , Jini  12  and SRE  14  can all be implemented in the same JVM  10 , However, for explanation purposes, the JVM  10  and the SRE  14  will be shown as separate elements. 
         [0019]      FIG. 2  shows a system  15  that includes multiple processors  16 ,  18 ,  20 ,  22  and  24 . Each processor includes one or more JVMs  10  that run different Java applications. For example, processor  16  includes one Java application  28  that controls a vehicle security system and another Java application  26  that controls the vehicles antilock brakes. A processor  18  includes a Java application  30  that controls audio sources in the vehicle. Other processors  20  and  22  may run different threads  32 A and  32 B for the same sensor fusion Java application  32  that monitors different IR sensors. Another thread  32 C on processor  24  monitors a radar sensor for the sensor fusion Java application  32 . 
         [0020]    The SRE  14  runs below the JVMs  10  in each processor and control tasks, messaging, security, etc. For example, the Java application  26  controls vehicle braking according to the sensor data collected by the sensor fusion Java application  32 . The SRE  14  in one example prevents unauthorized data from being loaded into the processor  16  that runs brake control application  26 . The SRE  14  also prevents other Java applications that are allowed to be loaded into processor  16  from disrupting critical braking operations, or taking priority over the braking operations, performed by Java application  26 . 
         [0021]    For example, the SRE  14  may prevent noncritical vehicle applications, such as audio control, from being loaded onto processor  16 . In another example, noncritical operations, such as security control application  28 , are allowed to be loaded onto processor  16 . However, the SRE  14  assigns the security messages low priority values that will only be processed when there are no braking tasks in application  26  that require processing by processor  16 . 
         [0022]    The SRE  14  allows any variety of real-time, mission critical, nonreal-time and nonmission critical Java applications to be loaded onto the multiprocessor system  15 . The SRE  14  then automatically manages the different types of applications and messages to ensure that the critical vehicle applications are not corrupted and processed with the necessary priority. The SRE  14  is secure software that cannot be manipulated by other Java applications. 
         [0023]    The SRE  14  provides priority preemption on a message scale across the entire system  15  and priority preemption on a task scale across the entire system  15 . So the SRE  14  controls how the JVMs  10  talk to each other and controls how the JVMs  10  are started or initiated to perform tasks. The SRE  14  allows programmers to write applications using Java in a safe and secure real time environment. Thus, viruses can be prevented by SRE  14  from infiltrating the system  15 . 
         [0024]    While the explanation uses Java as one example of a programming environment where SRE  14  can be implemented, it should be understood that the SRE  14  can be integrated into any variety of different programming environments that may run in the same or different systems  15 . For example, SRE  14  can be integrated into an Application Programmers Interface (API) for use with any programming language such as C++. 
         [0025]      FIG. 3  shows the different functions that are performed by the SRE  20 . Any combination of the functions described below can be provided in the SRE  20 . A message manager  50  controls the order messages are received and transmitted by the different Java applications. A security manager  52  controls what data and messages are allowed to be received or transmitted by different Java applications. A critical data manager  54  controls what data is archived by the different Java applications. 
         [0026]    A data manager  56  controls what data is allowed to be transferred between different processors. A task manager  58  controls the order tasks are performed by the different JVMs. A reconfiguration manager  60  monitors the operation of the different processors in the system and reassigns or reconfigures Java applications and Java threads to different processors according to what processors have failed or what new processors and applications have been configured into system  15 . 
         [0027]    The message manager  50  partially corresponds to the priority manager 44 shown in  FIG. 2  of U.S. Pat. No. 6,629,033, issued Sept.30, 2003, the critical data manager  52  partially corresponds with the logging manager 44 shown in  FIG. 2  of the &#39;033 patent, and the security manger 54 a least partially corresponds with the security manager 40 shown in the &#39;033 patent. The data manager  56  at least partially corresponds with the data manager 42 shown in  FIG. 2  of U.S. Pat. No. 7,146,260, the task manager  58  partially corresponds to the device manger 46 shown in  FIG. 2  of the &#39;260 patent, and the configuration manager  60  at least partially corresponds to the configuration manager 44 shown in  FIG. 2  of the &#39;260 patent. The descriptions of how the different managers  50 - 60  operate similarly to the corresponding managers in the &#39;033 and &#39;260 patents are herein incorporated by reference and are therefore not described in further detail. 
         [0028]    However, some specific tasks performed by the managers  50 - 60  are described below in further detail. 
         [0029]      FIG. 4  shows in more detail how the SRE  14  operates. One of the operations performed by the task manager  58  is to control when different tasks are initiated on different processors. For example, a first Global Positioning System (GPS) thread  62  is running on a JVM in a processor  80 . Another sensor fusion thread  64  is running on a different processor  82 . Block  74  represents the Java Virtual Machine operating in each of processors  80  and  82 . A master JVM  74  may run on either processor  80 , processor  82  or on some other processor. 
         [0030]    The task manager  58  sends an initiation command  66  to the GPS thread  62  to obtain location data. The task manager  58  then directs the obtained GPS data  68  through a link to the sensor fusion thread  64  for subsequent processing of GPS data  68 . The link may be any bus, such as a PCI bus, serial link such as a Universal Serial Bus, a wireless link such as blue tooth or IEEE 802.11, or a network link such as Ethernet, etc. 
         [0031]    The configuration manager  60  acts as a watchdog to make sure that the GPS thread  62  and the sensor fusion thread  64  are each running correctly. In one example, separate configuration managers  60  in each processor  80  and  82  sends out periodic signals to the other configuration managers  60  in the other processors. Any one of the configuration managers  60  can detect a processor or application failure by not receiving the periodic “ok” signals from any one of the other processors for some period of time. If a failure is detected, then a particular master configuration manager  60  in one of the processors determines where the task in the failed processor is going to be reloaded. If the master configuration manager  60  dies, then some conventional priority scheme, such as round robin, is used to select another configuration master. 
         [0032]    If a failure is detected, say in the processor  82  that is currently performing the sensor fusion thread  64 , a message is sent from the configuration manager  60  notifying the task manager  58  which processor is reassigned the sensor fusion thread. In this example, another sensor fusion thread  76  in processor  84  is configured by the configuration manager  60 . 
         [0033]    The critical data manager  52  manages the retention of any critical data  72  that was previously generated by the sensor fusion thread  64 . For example, the critical data manager  54  automatically stores certain data and state information that was currently, being used in the sensor fusion thread  64 . The critical data may include GPS readings for the last 10 minutes, sensor data obtained from sensors in other processors in the vehicle over the last 10 minutes. The critical data may also include any processed data generated by the sensor fusion thread  64  that identifies any critical vehicle conditions. 
         [0034]    The critical data manager  52  also determines which data to archive generally for vehicle maintenance and accident reconstruction purposes. 
         [0035]    The configuration manager  60  directs the critical data  72  to the new sensor fusion thread  76 . The task manager  74  then redirects any new GPS data obtained by the GPS thread  78  to the new sensor fusion thread  76  and controls sensor fusion tasks from application  76 . Thus, the configuration manager  60  and the task manager  58  dynamically control how different Java threads are initialized, distributed and activated on different processors. 
         [0036]    The message manager  50  determines the priority of sent and received messages. If the data transmitted and received by the sensor fusion thread  76  is higher priority than other data transmitted and received on the processor  84 , then the sensor fusion data will be given priority over the other data. The task manager  58  controls the priority that the sensor fusion thread  76  is giving by processor  84 . If the sensor fusion thread  76  has higher priority than, for example, an audio application that is also being run by processor  84 , then the sensor fusion thread  76  will be performed before the audio application. 
         [0037]    The SRE  14  can be implemented in any system that needs to be operated in a secure environment. For example, network servers or multiprocessors operating in a home environment. The multiprocessors in home appliances, such as washer and dryers, home computers, home security systems, home heating systems, can be networked together and operate Java applications. The SRE  14  prevents these multiple processors and the software that controls these processors from being corrupted by unauthorized software and also allows the applications on these different processors to operate as one integrated system. 
         [0038]    The SRE  14  is a controlled trusted computing based that is not accessible by non-authorized application programmers and anyone in the general public. Therefore, the SRE  14  prevents hacking or unauthorized control and access to the processors in the vehicle. 
       Task Controlled Applications 
       [0039]    Debugging is a problem with multiprocessor systems. The task manager  58  allows the Java applications to be run in a lock-step mode to more effectively identify problems in the multiprocessor system  15 . 
         [0040]      FIG. 5  shows a path  90  taken by a vehicle  92 . In one application, the position of the vehicle  92  is sampled every second t.sub.1, t.sub.2, t.sub.3, t.sub.4, etc. The position of the vehicle  92  is sampled by a GPS receiver in vehicle  92  that reads a longitudinal and latitudinal position from a GPS satellite. The GPS receiver is controlled by the GPS thread  62  that receives the GPS data and then sends the GPS data to a sensor fusion thread  64  that may run on the same or a different processor in the vehicle  92 . The sensor fusion thread  64  can perform any one of many different tasks based on the GPS data. For example, the sensor fusion thread  64  may update a map that is currently being displayed to the driver of vehicle  92  or generate a warning signal to the vehicle driver. 
         [0041]    For each sample period t.sub.N, the task manager  58  sends a request  94  to the GPS thread  62  to obtain GPS data. The task manager  58  uses a clock  96  as a reference for identifying each one second sample period. Each time a second passes according to clock  96 , the task manager  58  sends out the request  94  that wakes up the GPS thread  62  to go read the GPS data from the GPS satellite. Once the GPS data has been received, the GPS thread  62  passes the UPS data  96  to the sensor fusion thread  64 . The GPS thread  62  then goes back into an idle mode until it receives another activation command from the task manager  58 . 
         [0042]    The task manager  58  can control when the GPS thread  62  is woken up. Instead of the GPS thread  62  being free running, the GPS thread  62  is operating according to a perceived time controlled by the task manager  58 . The task manager  58  may send the activation request  94  to the GPS thread  62  once every second during normal sensor fusion operation. When the system is in a debug mode, however, the task manager  58  may only send one activation command  94 . This allows the other operations performed by the system  89  to be monitored and determine how the single sampling of GPS data  96  propagates through system  89 . The task manager  58  may also delay or disable task initiation to other threads, so that the processing of the GPS data  96  can be isolated. 
         [0043]    The task manager  58  can isolate any state in the overall system  89 , such as the state of system  89  after a first GPS reading by GPS thread  62  or the state of system  89  after the thirty second GPS reading by GPS thread  62  by controlling when and how often activation commands  94  are sent to UPS thread  62 . In a similar manner, the task manager  58  can control when other tasks are performed by the system  89 , such as when the sensor fusion thread  64  is activated. 
         [0044]    Thus, the task manager  58  controls when Java applications are activated effectively running the overall system  89  in a lock-step mode. The task manager  58  can control the initiation of multiple tasks at the same time. This allows the task manager to control what parameters and operations are performed and used by the different Java threads so that different states in the multiprocessor system  89  can be detected and monitored more effectively. 
         [0045]    One application for the task controlled applications is for accident reconstruction. The critical data manager  52  ( FIG. 3 ) may save different vehicle parameters from a vehicle that has been in an accident. For example, sensor data, brake data, speed data, etc. The task manager  58  can feed the saved data into the different Java applications in a lock-step mode to determine how each Java thread processes the saved data. This can then be used to identify any failures that may have occurred in the system  89 . 
         [0046]    The system described above can use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the communication operations. Some of the operations described above may be implemented in software and other operations may be implemented in hardware. 
         [0047]    For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional blocks and software modules or described features can be implemented by themselves, or in combination with other operations in either hardware or software. 
         [0048]    Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. Claim is made to all modifications and variation coming within the spirit and scope of the following claims.