ALERT DEVICE SYSTEM AND METHOD

Abstract

A mobile device is provided with software monitoring a programmatically controlled process of the mobile device. The software communicates a status of the process to an alert device that, in turn, communicates process status information to the monitor. The monitor is equipped to take appropriate action, such as by providing notifications if operation of the process has failed, rebooting a program on the mobile device to restart the failed process, rebooting an operating system of the mobile deice to restart the failed process, or providing programmatic instructions to alter operation of the process according to a preterminated schedule or sequence of events.

Claims

1. A system comprising: an alert device that is constructed and arranged for monitoring and communicating with a mobile device; the alert device being configured to operate independently and in proximity to the mobile device to maintain the portability of the mobile device; a software application running on the alert device for programmatic monitoring and communicating with the mobile device the mobile device includes programmatic wireless transmission for communicating signals expected by the alert device wherein the software application periodically determines the operational status of the mobile device based on the information provided by the mobile device wireless transmissions, and the alert device being programmed with logic for delivery of user notification commensurate with the operational status of the mobile device.

2. The system of claim 1, wherein the mobile device includes a software application that has been downloaded to the resident memory of the mobile device.

3. The system of claim 2, further comprising a patient monitor that collects parameters related to a patient under medical care and wirelessly transmits the parameters to the software application that resides on the mobile device.

4. The system of claim 2, wherein the patient monitor collects parameters related a person, animal or other entity that requires monitoring and wirelessly transmits the parameters to a software application resident on a mobile device.

5. The system of claim 2, further comprising a process monitor that collects parameters related to a process involving machinery and/or materials and wirelessly transmits the parameters to the software application that resides on the mobile device.

6. The system of claim 1, wherein the alert device is a second mobile device and communication between the mobile device and alert device is performed wirelessly by at least one protocol selected from the group consisting of Bluetooth, Near Field Communication or another wireless communication protocol.

7. The system of claim 1 wherein the software application communicates to a remote observer the parameters that are transmitted by the patient monitor and received by mobile device.

8. The system of claim 1, wherein communication between the mobile device and alert device is performed through a wired connection.

9. The system of claim 1, wherein software application starts automatically when the mobile device is turned on.

10. The system of claim 1, wherein the software application permits starting by an owner/operator of the mobile device.

11. The system of claim 1, wherein the alert device is mechanically coupled to mobile device.

12. The system of claim 1, wherein the alert device is mechanically mounted within a fixed distance from the mobile device.

13. The system of claim 1, wherein the software application communicates its operational status to the alert device but the alert device does not transmit data to the mobile device or software.

14. The system of claim 1, wherein the alert device communicates its status to a software application.

15. The system of claim 1, wherein the software application contains the communication means for the alert device.

16. The system of claim 1, wherein the alert device is provided as a wearable article.

17. The system of claim 1, wherein the wearable article is configured as a pair of glasses, or other independent electromechanical device.

18. The system of claim 1, wherein the alert device is mechanically coupled with the mobile device.

19. The system of claim 1, wherein the software application running on the alert device is implemented in solid state circuitry.

20. A system comprising: an alert device that is constructed and arranged for monitoring and communicating with a mobile device; the alert device being configured to operate independently and in proximity to the mobile device to maintain the portability of the mobile device; a software application running on the alert device for programmatically initiating periodic communication queries with the mobile device; wherein the communication queries require a response from the mobile device; wherein the alert device evaluates the response to determine the operational status of the mobile device, and; the alert device being programmed with logic for delivery of user notification commensurate with the operational status of the mobile device.

21. The system of claim 20, wherein the mobile device includes a software application that has been downloaded to the resident memory of the mobile device.

22. The system of claim 21, further comprising a patient monitor that collects parameters related to a patient under medical care and wirelessly transmits the parameters to the software application that resides on the mobile device.

23. The system of claim 21, wherein the patient monitor collects parameters related a person, animal or other entity that requires monitoring and wirelessly transmits the parameters to a software application resident on a mobile device.

24. The system of claim 21, further comprising a process monitor that collects parameters related to a process involving machinery and/or materials and wirelessly transmits the parameters to the software application that resides on the mobile device.

25. The system of claim 20 wherein the software application communicates to a remote observer the parameters that are transmitted by the patient monitor and received by mobile device.

26. The system of claim 20, wherein the alert device is a second mobile device and communication between the mobile device and alert device is performed wirelessly by at least one protocol selected from the group consisting of Bluetooth, Near Field Communication or another wireless communication protocol.

27. The system of claim 20, wherein communication between the mobile device and alert device is performed through a wired connection.

28. The system of claim 20, wherein software application starts automatically when the mobile device is turned on.

29. The system of claim 20, wherein the software application permits starting by an operator of the mobile device.

30. The system of claim 20, wherein the alert device is mechanically coupled to mobile device.

31. The system of claim 20, wherein the alert device is mechanically mounted within a fixed distance from the mobile device.

32. The system of claim 20, wherein the software application communicates its operational status to the alert device but the alert device does not transmit data to the mobile device or software.

33. The system of claim 20, wherein the alert device communicates its status to a software application.

34. The system of claim 20, wherein the software application contains the communication means for the alert device.

35. The system of claim 20, wherein the alert device is provided as a wearable article.

36. The system of claim 20, wherein the wearable article is configured as a pair of glasses, or other independent electromechanical device.

37. The system of claim 20, wherein the alert device is mechanically coupled with the mobile device.

38. The system of claim 20, wherein the software application running on the alert device is implemented in solid state circuitry.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] FIG. 1 is a system schematic diagram according to one embodiment of the presently disclosed instrumentalities;

[0023] FIG. 2 is a system schematic diagram of a communication subsystem according to one embodiment;

[0024] FIGS. 3a and 3b are process flow diagrams according to one embodiment of the presently disclosed instrumentalities;

[0025] FIG. 4 is a system level diagram of a communications subsystem;

[0026] FIG. 5 is a system level diagram of a communications subsystem; and

[0027] FIG. 6 is a system level diagram of a communications subsystem.

DETAILED DESCRIPTION

[0028] FIG. 1 provides an overview of the system-level application that the present disclosure addresses. This system-level application contains a central monitor 20 that performs a critical function for a monitored entity or process 10. The monitored entity or process 10 can be any situation that must be supervised, attended to or monitored to ensure that certain conditions are maintained or addressed. The monitored entity or process 10 may be, for example, a person in a medical facility, someone who is involved in a hazardous endeavor or activity whose condition must be known, an activity involving animals or any type process involving other machinery and materials. The central monitor 20 is equipped with a wireless communication transceiver25 having the ability to transmit and receive wireless communication signals 30 that are commonly used by wireless devices, as is well known in the art.

[0029] Also shown in FIG. 1 is mobile device 110 that is in possession of a remote observer 40, where the remote observer 40 has an interest or requirement to maintain knowledge of the monitored entity or process 10 through the use of central monitor 20. Remote observer 40 may also be required to exercise control over central monitor 20 by changing or altering operating parameters of the central monitor 20 through the input of information through mobile device 110. Central monitor 20 transmits wireless communication signals 30 that contain relevant information regarding the status of the monitored entity or process 10. Mobile device 110 receives the wireless communication signals 30 and the information contained in the signals is used by a resident software application on the mobile device 110 to communicate the information to the remote observer 40 about the monitored entity or process 10.

[0030] To improve the reliability and security of the overall system-level application, an alert device 150 is used to monitor the mobile device 110 and provides independent error reporting to the remote observer 40. Preferably, mobile device 110 and alert device 150 communicates via wireless channel 60 that can use a variety of transmission technologies where the communication includes a signal from the mobile device 110 that updates or resets a watchdog timer operating on alert device 150. In the same manner, the central monitor 20 communicates with another mobile device 110, which may include additional hardware or software that provides monitoring capability for the monitored entity or process 10, utilizing wireless communications signals 30 and alert device 150 to notify remote observer 40. This may be repeated for a second remote observer 40 using a second mobile device 110 monitored by a second alert device 150 using mobile communications 60. It will be appreciated that the alert devices 150, 150 may each communicate with transceiver 25 using signals 30. Also, in some embodiments, the alert devices 150, 150 may be replaced by a single alert device (not shown) that communicates with mobile devices 110, 110 using wireless signals 60, 60 respectively allocated to a corresponding one of mobile devices 110, 110.

[0031] FIG. 2 is a system level diagram of the components utilized by the remote observer 40 according to one embodiment. The mobile device 110 may be a commercially available device, for example, as any type of cell phone, smart phone, tablet computer or other wirelessly communicating computing device. Mobile device 110 utilizes an Operating System (OS), such as a conventional operating system known in the art, which manages the hardware and software resources, including resident memory and wireless communication capabilities, as well as Bluetooth, Wi-Fi, near field communication (NFC), Radio Frequency Identification (RFID) and a variety of protocols through direct electrical connection.

[0032] The mobile device 110 is partially configured by a custom mobile monitoring application 120 that is a software application developed according to the presently disclosed instrumentalities. In one aspect, the application 120 may be downloaded, stored in the resident memory of the mobile device 110 and presented for use by a remote observer 40. For example and as is well known in the art, software application programs may be started automatically by the mobile device OS or upon user demand, for example, by remote observer 40.

[0033] The presence of the mobile monitoring application 120 on the mobile device 110 signifies that mobile device 110 is used as part of a multi-component system that facilitates additional monitoring for safety and reliability concerns. In a preferred embodiment, use of the mobile monitoring application 120 is in conjunction with an additional mobile application 125 that resides on mobile device 110. The mobile device 110 utilizes mobile application 125 to communicate with the system level central monitor 20 given in FIG. 1 where the central monitor 20 is remote from mobile device 110. The resident mobile application 125 communicates with the remote observer 40 to create a user interface extension of the system level central monitor 20.

[0034] In one embodiment, the mobile monitoring application 120 optionally launches automatically when the mobile device is turned on so that the mobile monitoring application 120 runs when the mobile device 110 is in use. Alternatively, the mobile monitoring application 120 may be configured to launch in unison with the resident mobile application 125that puts the mobile device in an operating condition. The resident mobile application 125 may contain computer code operating on an assumption that the alert device 150 and mobile monitoring application120 are operable and fully functioning, with periodic checks being made among the system components to confirm this is so. By way of example, the resident mobile application 125 may cause mobile device 110 to poll alert device 150 and/or monitoring application 120 by prompting a handshake reply to confirm that all systems are active. Any one device on the system may initiate a handshake confirmation from any other device. Alternatively, any device on the system may transmit to one or more other devices within designated intervals to confirm operability.

[0035] Mobile monitoring application 120 also includes computer code that utilizes one or more of the mobile device 110 communication capabilities, including Bluetooth, Wi-Fi, near field communication and a variety of protocols through direct electrical connection, such as USB or the headphone/microphone connector. The communication path is shown in FIG. 2 as notification 140. Mobile Monitoring Application (MMA) Status 140 may utilize a wireless signal notification, for example, using Bluetooth, or communication may use a wired path.

[0036] Also shown in FIG. 2, alert device 150 is, broadly, circuitry under operational control of program instructions constituting alarm logic 160, which interfaces with the mobile monitoring application 120 to provide alarms, alerts or other such notifications as needed concerning the operational status of resident mobile application 125. This may be, for example, a plug-in software module either for central monitor 20 or else a mobile device 110 that operates using the operating system of the electronic system to which the plug-in software module is attached. Preferably, the alert device 150 is a standalone or independent device housing simple circuitry for communicating with mobile device 110, and other customary components useful for the functioning of an electromechanical device. This includes alert device alarm logic 160 that drives functionality to produce a variety of possible alert or alarm types or otherwise communicate with a remote observer 40 through output notification 170, preferably under the control of a separate operating system other than an operating system of the central monitor 20 or mobile device 110. The mechanical form of the alert device 150 is more preferably such that it integrates with mobile devices in an unobtrusive electrical and mechanical manner to maintain the portability of the mobile device 110 and has a power source independent of central monitor 20 and mobile device 110.

[0037] In one embodiment, a smartphone provides the mechanical form of the alert device to be similar to commercially available protective cases, such as the Tough Jacket manufactured by the Ballistic Case Company of Sunrise, Florida. As will be recognized by those skilled in the art, there are many mechanical forms that will satisfy the mechanical packaging intent as disclosed herein. Further, the alert device is not required to be in physical contact with the mobile device. For example, if an application were deployed to GLASS, a mobile device made by Google, mounted to a pair of glasses, the alert device 150 can be integrated into a retainer that maintains the position of the glasses on the user's head. As the mechanical form factor of the mobile device 110 varies, so may the mechanical form of the alert device to satisfy the positional requirements disclosed, as will be recognized by those skilled in the art.

[0038] In operation, the alert device 150 is attached, adjacent or is otherwise in proximity of mobile device 110 when mobile device 110 is powered on, which optionally launches the mobile monitoring application 120. If a specific, third-party resident mobile application 125 is configured to operate in unison with the mobile monitoring application 120, mobile monitoring application 120 starts when the third-party resident mobile application launches. In this instance, the resident mobile application 125 integrates the mobile monitoring application 120 communication command set in order to communicate directly to the mobile monitoring application 120. In its most basic configuration, mobile monitoring application 120 is a device driver that provides a software interface for the alert device 150 hardware. Alternately, the mobile monitoring application 120 can collect status information directly from the resident mobile application 125 by receiving existing operational artifacts output by the resident mobile application 125 or can monitor its status through the operating system. Monitoring through the operating system can be accomplished through a variety of well-known techniques practiced in the art.

[0039] From a security perspective, the preferred embodiment is to employ the resident Near Field Communication (NFC) capability such that when mobile device 110 is powered, the mobile monitoring application 120 activates the NFC through MMA Status 140 and looks for a response from alert device 150, indicating its presence. NFC has the advantage that in order for any separate device to communicate with mobile device, the separate device must be in very close proximity to mobile device, and in most cases, the two devices must be in direct contact. From a practical perspective, Bluetooth is more commonly available and is an equally effective communication method but can be received at greater distances, making it susceptible to eavesdropping and hacking. With a greater range, Bluetooth will also introduce the possibility that the two devices become physically separated beyond the range of transmission without alerting the user that the communication has been lost. Both communication technologies include a handshaking protocol between devices that establish the connection and provide evidence that the alert device is present and operational. As will be understood by those skilled in the art, other forms of communication between the devices are possible including Wi-Fi, optical or a direct cable interconnect.

[0040] Once the communication link between mobile device 110 and alert device 150 is established, the system transitions into a run-time mode of operation, where the mobile monitoring application 120 includes the mobile monitoring application present 130 that sends a repeating, periodic message via MMA Status 140 path to alert device alarm logic 160 indicating the mobile monitoring application 120 is operating normally. If alert device alarm logic 160 fails to receive a message in the prescribed time period, or the message indicates abnormal operation, alert device alarm logic 160 activates the output notification 170 to alert the remote observer 40 to an error condition.

[0041] The foregoing operational description of the interaction between the alert device 150 and mobile device 110 is described in greater detail below and graphically in FIGS. 3a and 3b. FIG. 3a shows a representative process flow for the mobile device 110 that begins with Launch Resident Application 310. As previously disclosed, Launch Resident Application 310 can be initiated by applying power to the mobile device or it can be launched by an operator or Remote Observer 40. Launching Application 310 causes the mobile monitoring application 120 to start in Launch Mobile Monitoring Application 313. With both applications running on the mobile device 110, the mobile monitoring application 120 begins transmitting a message through the mobile device 110 wireless channel 60 to the alert device 150. The mobile monitoring application 120 monitors the wireless channel 60 for a response from the alert device 150 in process step Alert Device Response? 319 and if none is received, the mobile monitoring application 120 generates an error message indicating that no response was received from the alert device 110 in the Display Error Message 322. If it is determined that the alert device 110 provides a response 319, then the process moves forward to complete handshaking 325, which establishes an on-going communication wireless channel 60 between the mobile device 110 and alert device 150. With wireless channel 60 operational, the mobile monitoring application 120 transitions into Runtime Mode 328, where the mobile monitoring application 120 transmits periodic MMA Status 140 messages to the alert device 110. If the mobile monitoring application 120 continues to operate normally, MMA Status 140 is sent in Transmit Message 337 and the periodicity is defined by Wait Period 340. If any abnormal conditions occur, MMA Status 140 is not sent and the process ends with Transmission Absent 334. The process flow of FIG. 3a runs on the mobile device 110 while the complementary process flow runs on the alert device 150 as given in FIG. 3b and described below.

[0042] The alert device 150 may be powered by batteries or RF energy harvesting and when power is applied, the alert device 150 immediately looks for the presence of a signal through wireless channel 60 as shown in Detect Communication Channel 370 block of FIG. 3b. When a signal is detected, the alert device 150 verifies it was sent from the mobile monitoring application 120 in process step Receive Communication 373. The alert device 150 acknowledges the signal is correct by responding to the mobile monitoring application 120 in Send Response 376 that then results in Complete Handshaking 379 to secure a persistent wireless channel 60. As with the mobile device process flow in FIG. 3a, the alert device 120 transitions in Runtime Mode 382, where it goes into a process loop to look for messages from the mobile monitoring application 120 in decision block Receive Message? 385. If a message is received, Reset Counter 388 initializes the counter to its default value and it begins counting again. If no message is received, the alert device determines if the counter has depleted in Counter Timeout 391 and if it hasn't, continues to look for a message in Receive Message 385. If not message is received and the counter has timed out, Active Alarm 394 is triggered to notify the Remove Observer that an abnormal condition has occurred.

[0043] The embodiment given in FIG. 2 is a simple form of the present system that provides utility and an improvement to the art. The likely implementation is where reliability is critical, so the preferred embodiment incorporates additional functionality to provide fail-safe functionality. In the present context, fail-safe is applied to mean that if either the mobile device 110 or alert device 150 fails, the remote observer 40 will be notified so the use of the devices will be discontinued to minimize the risk to property and personnel.

[0044] The embodiment of FIG. 4 includes the mobile device 110, mobile monitoring application 120a and alert device 150, as given in FIG. 2. The embodiment of FIG. 4 establishes bi-directional monitoring of the mobile device 110 and alert device 150 so that if either device fails, the operator/owner is notified. The embodiment in FIG. 2 is present in FIG. 4, which adds a mirrored functionality for elements 130, 140 and 160. As in FIG. 2, elements 130, 140 and 160 communicate the operational status of mobile monitoring application 120a to the alert device 150.

[0045] To support the fail-safe context, the alert device 150 must be monitored and is diagramed in FIG. 4 to provide a robust two-way monitoring with notification and status reporting redundancy. Elements 260, 255, 230 and 235 combine to perform the same pathway function as elements 130, 140, 160 and 170, except in the reverse direction such that the mobile device 110 is monitoring the status of the alert device 150 and the mobile device 110 reports the absence and/or occurrence of any abnormal conditions. Algorithm Alert Device Present 260, a component of alert device 150, generates an Alert Device Status signal 255 that is transmitted to mobile device 110 via pathway 60 and is received by the functional block alert device present monitor 230. This bi-directional monitoring down to the level of individual resident mobile applications 125 provides the reliability necessary to support the trend of mobile devices being used as user interface extensions.

[0046] In one aspect, an important operational element of mobile device use may be the power source for the device, which is generally based on a form of battery technology. The preferred embodiment is to power the alert device 150 with rechargeable batteries developed for mobile devices, thereby providing a similar maintenance and charging requirement. Further, given the limited functionality provided by the alert device 150, the power consumption will be lower than the mobile device 110 that increases the likelihood the mobile device 110 will deplete its battery before the alert device 150, elevating the reliability of the alert device 150 reporting an error or malfunction. Other battery technologies are contemplated by the present disclosure, including disposable lithium-based material combinations, alkaline, and other materials that are packaged in commonly available cell formats including A, AA, AAA and coin cells.

[0047] Also contemplated as possible power source by the present disclosure is the use of Radio Frequency (RF) energy harvesting, where ambient RF energy is converted to DC voltage to provide power for electronic circuits. Widely used for RF identification tags, the RF energy harvesting technology continues to improve the efficiency of the conversion of RF energy into useable DC voltage, and when coupled with the reduction in required operating voltage of integrated circuits, harvested RF energy is a viable power source for the alert device 150. For the mobile device 110 to be operational, it must be in proximity of an RF signal of sufficient strength to communicate wirelessly. This signal is able to generate enough energy for the alert device 150 to convert to DC voltage for power. Other RF signals may be present, including those emitted from the mobile device 110. To ensure against sudden loss of RF energy that would render the alert device inoperable in this embodiment, an energy storage component, such as a super capacitor, is added to the alert device and charged while RF energy is present. If a sudden loss of RF energy occurs, the energy stored in the storage component is used to drive the output notification 170 or WW Action Block 275 to inform the user of an error condition or malfunction.

[0048] Another aspect may be that the alert device 150 does not drive, direct, initiate or otherwise control any functional aspect of the mobile device 110 or resident mobile application 125. This is noteworthy for two reasons, the first of which is that it allows the alert device 150 to maintain its independence from the mobile device 110 and resident mobile application so that failure modes do not become inter-dependent. A second aspect is that if the alert device 150 were to execute any control over the mobile device 110 or the resident mobile application 125 then the alert device would become subject to the requirements and regulatory issues bound to the mobile device 110 and resident mobile application. Further, the alert device 150 is essentially a hardware device running a software application that typically does not have a display for visual information but is capable of communicating with a mobile device 110 for interactive operation.

[0049] It is expected that once the alert device 150 becomes commercially available and the need for fail-safe mobile device operation is demonstrated, system designers and developer will incorporate the use of the alert device 150 into the development and operation of their resident mobile application 125. The software communication and command set for the alert device 150 will be publicly available, for example as an Application Program Interface (API), so that system designers can capitalize on the full functionality offered by the alert device 150 by integrating an interface directly in their resident mobile applications 125.

[0050] By way of a non-limiting example of an architectural implementation of the present instrumentalities, alert device 150 is a system that includes a block of software code that runs external to the alert device 150 and is provided as an Application Programming Interface (API). The API is made a part of the resident mobile applications 125 by linking the API into the resident mobile application 125 by the developers, a technique that is well known in the art. In this case there is only one application as the mobile monitor application 120/120a is integrated into the resident mobile application 125 and it communicates with the alert device 150. The developer creates the application and must make appropriate calls to the API to enable, disable and send notifications to the alert device 150.

[0051] As shown in FIG. 5, alert device API 510 has been integrated into the resident mobile application 125a and become a component of the application. This alternate embodiment permits the resident mobile application 125a to communicate directly with the alert device 150 using the resident mobile application present 520 function that is part of the alert device API 510. Yet another alternate embodiment is shown in FIG. 6, where alert device API 510a includes MMA alarm logic 235 and alert device present monitor 230 as in FIG. 2. Since in this embodiment, the resident mobile application 125b is communicating directly to the alert device 150, the alert device API 510a outputs the RMA status 550 from the resident mobile application present 520. The advantage to the approach using an API is that all code associated with the resident mobile application and the mobile monitoring application are encapsulated into a single code base for a more tightly integrated implementation. The resident mobile application 125a/125b is responsible for interacting with the mobile device 110 and managing the necessary mobile device110 resources needed by the alert device API 510/510a. This is contrasted by the embodiment of FIG. 2 and FIG.4, where the mobile monitoring application 120/120a runs standalone on the mobile device 110 so it must manage the necessary mobile device 110 resources.

[0052] A manufacturer of a mobile device 110 or a developer of a resident mobile application 125 can require the use of the alert device 150 with their product(s) without the need to sell or manufacture an alert device. As demonstrated by other markets with products governed by standards, the alert device can be produced by multiple vendors based on the publicly available interface specification. The standard interface of the alert device 150 allows the developer of resident mobile applications 125 to specify that a compliant alert device 150 is required to use the resident mobile application 125. The aforementioned situation also addresses potential problem caused by variations among mobile devices. For example, there are instances where a mobile device 110 is operating nominally, but the resident mobile application 125 has locked up and is frozen. This condition is generally supposed to be handled by the OS, but the response produced by the OS for the user (e.g. a dialog that says application taking too long, do you want to continue to wait?) may not be appropriate, guaranteed to be the same across all mobile devices 110 or comply with a regulatory requirement for a particular market (e.g. FDA standards for medical device alarms). The present instrumentality addresses this problem by providing a standardized response to a locked up application and other error conditions that is independent and immune to the perturbations of performance found across all mobile devices.

[0053] There is another architectural configuration supported by the present disclosure, where an external hardware device is connected or interfaced directly to mobile device 110 to create a critical application without a central monitor. For example, a wearable respiratory sensor can communicate locally with a mobile device using Bluetooth to transmit respiration and heart rate. The mobile device can then wirelessly transmit this information to a cloud service that would allow other remote users 40 to monitor the patient vital signs remotely. In this configuration, the mobile device 110 coupled with an external hardware device is monitored by the alert device 150 for nominal operation.

[0054] In yet another contemplated embodiment, monitoring of the operational status of resident mobile application 125 can be performed and reported by mobile monitoring application 120 without the use of an independent alert device 150. In this situation, the mobile monitoring application 120 runs on the mobile device 110 and monitors the resident mobile application 125 for any anomalous conditions or anything that impedes it's operational status. For example, mobile device operating systems (OS) will automatically put applications to sleep after periods of inactivity with a user and this is a likely condition for a resident mobile application 125 that is part of a user interface extension. Further, mobile device OS will automatically shut down applications if resources (memory) becomes limited. Both these situations pose a danger when the mobile device is running a resident mobile application 125 used for remote monitoring. If a situation similar to those just outlined occurs, the mobile monitoring application 120 is able to activate an alert for the user since the mobile monitoring application 120 was designed to immune to sleep mode or automatic shutdown.

[0055] Those skilled in the art will understand that the disclosed embodiments, as hereinabove described, may be subjected to apparent modifications or insubstantial change without departing from the true scope and spirit of the invention. The inventors, accordingly, hereby state his intention to rely upon the Doctrine of Equivalents, in order to protect their full rights in the invention.