This invention relates generally to a system, apparatus and method for transmitting event information from a remote terminal to subscribers over a network and, more particularly, to a system, apparatus and method for transmitting event information from a remote terminal over a network to, for example, a user logged into his or her remote terminal account, such transmission being made automatically without the need for the user to make an inquiry to the remote terminal.
Remote terminals, such as mobile phones, are becoming the mainstay of personal communication. In addition to asynchronous voice communication, mobile phones are used for sending messages, such as email, short messages or multimedia messages. Along the same lines, it is also common to use a computer, for example, a desktop, laptop, PDA etc., at work, home or remotely. Digital communication techniques have also fostered the ability to communicate between a remote terminal and a computer, for example, by the use of systems that can synchronize certain events between a host system (i.e. a data computing device) and a mobile phone.
However, such a usage does not take advantage of the asynchronous capabilities of remote terminals. For example, with a mobile phone, a subscriber, such as a user of services like short message service (“SMS”) or multimedia message service (“MMS”) offered by the mobile phone service provider, can receive a call or an SMS or MMS message anytime, asynchronously. Such a user does not have to push buttons to receive an incoming call or SMS. On the other hand, conventional web interfaces do not provide such asynchronous notifications. A user, for example, has to push a button (to “refresh” the screen) each time the user wants to get the latest state.
Some conventional web interfaces do allow automatic refreshing at certain intervals so that a user can get the latest state, however, such systems typically have at least two problems. First, if the refresh interval is small, the interface keeps refreshing itself, thereby flickering while a user is reading the contents. This is very distracting to the user. Second, if the refresh interval is large, the state is not truly asynchronous because a user could be notified of the happening of an event that took place some time back only after a pre-determined time interval. Being notified of a missed call which occurred several minutes ago is not asynchronous communication.
The Gmail™ notifier is a prior art asynchronous email notification application which alerts the user to new messages. The Gmail™ notifier application displays an icon in the user's system tray to inform the user of unread messages, and shows the user the subject, the sender and snippets of the message, all without the user having to open a web browser. However, the Gmail™ notifier is used only with email messages and only by subscribers of Gmail's™ search-based webmail service.
The following example further illustrates the problems and limitations of conventional systems such as the Gmail™ notifier: A remote terminal subscriber, such as a user of a mobile phone, is on her way to work when she notices that she has left her mobile phone at home. She has no immediate information about who is trying to contact her. In fact, the only way she can determine if attempts have been made to contact her is to: (a) wait to return home and check, on her mobile phone, the missed calls log, the voice messages, the SMS etc, or (b) call her voice message retrieval system through an alternate voice communication means such as an office phone, and determine if anyone has left a voice message. Unfortunately, there is no way for the user to access missed calls or text messages or even know if the battery is running low on her mobile phone if the phone is not with her.
Therefore, it would be advantageous if the user could more readily be informed about missed calls or text messages even when she does not have her mobile phone on her person. Accordingly, there may be interest in technologies applicable to notifying a user of such missed calls or text messages etc.
According to exemplary embodiments of the present invention, as described below, the problems noted above are overcome by providing a system, apparatus and method for transmitting remote terminal event information between a remote terminal, such as a mobile phone, and one or more subscribers, such as a user of a desktop computer, terminal or other network access device over a network. Such information is transmitted when the user is logged on to his or her remote terminal account over a network. The remote terminal is configured to transmit the information upon the occurrence of the event and without the need for a user to make an inquiry regarding the happening of an event. When information is generated for more than one remote terminal event, a listing of all event information transmitted to a subscriber is generated, and the list presented to a user on his or her network access device.
In one exemplary embodiment, a set of mobile phone events for which a user wishes to be notified is configured and stored on the mobile phone. Upon logging on to his or her mobile phone account through a network access device, such as a desktop computer, interaction between a user's mobile phone and computer begins. This interaction is controlled as a function of the mobile phone event notification configuration and parameters associating a mobile phone to a user. The mobile phone communicates with the desktop computer via a mobile communication system providing the possibility of communicating mobile phone event information to the user.
By way of example, a user may require notification of certain mobile events whether or not a user has access to his or her mobile phone. Based on event notification settings, mobile middleware running on the mobile phone, which, for example, could be specially designed software that allows an application to remotely configure events of interest and receive notifications about such events, automatically notifies a user on his or her desktop computer or other network access device of the happening of an event or a series of events on the user's mobile phone. In this manifestation of the invention the user does not have to make an inquiry to the middleware running on the mobile phone to initiate the transmission of event information.
As another example, based on event notification settings, a user is notified on his or her desktop computer of the happening of an event or a series of events on the user's mobile phone after the desktop computer or other network access device has initiated a request to the mobile middleware running on the mobile phone to transmit event information. In this manifestation of the invention a request to the mobile middleware initiates the transmission of event information to the desktop computer or other network access device.
It is to be understood that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims. It should be further understood that the drawings are not necessarily drawn to scale and that, unless otherwise indicated, they are merely intended to conceptually illustrate the structures and procedures described herein.
The following examples illustrate some of the benefits of the claimed invention in contradistinction to the problems associated with conventional systems as discussed above. As an example, a mobile phone user is on her way to work when she notices that she has left her remote terminal at home. When she reaches her office, she opens her mobile phone website on the computer and logs in. While she is working she receives notifications about arrived SMS's and missed phone calls. If someone important has called her, she can immediately return the call with the office phone.
As another example of the present invention, a mobile phone user is reading his email in an internet coffee shop. His mobile phone is inside his backpack and he does not notice that the battery of his mobile phone is running low. Luckily, he is logged into his mobile phone website and he receives a notification on the computer screen that the battery is running low. He takes the phone out from the backpack and plugs it into the charger.
Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings.
According to exemplary embodiments of the present invention the problems of conventional systems noted above are overcome by providing a system, apparatus and method of interaction for instantaneously transmitting remote terminal event information between a remote terminal, for example a mobile phone, and one or more subscribers, for example a user of a desktop computer or a terminal. The invention as described is not limited to a particular mobile communication system or network, and works with any mobile communication system or network providing the possibility of communicating remote terminal events. As used in this invention, remote terminal events include, but are not limited to, SMS messages, MMS messages, missed calls, and low battery etc.
In
By way of example, an exemplary general purpose data computing device, such as a desktop computer 106, includes a central processing unit (“CPU”), a system memory, and a system bus that couples various system components including the system memory to the processing unit. The desktop computer 106 further includes a hard disk drive for reading from and writing to a hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk, such as a CD ROM or other optical media. The drives and the associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the desktop computer 106. The desktop computer 106 may operate in a wired or wireless networked environment using logic connections to one or more remote computers. The remote computer may be another personal computer, a server, a router, a network PC, a peer device or other network node, and typically includes many or all of the elements described above relative to the desktop computer 106.
In the illustrative, non-limiting exemplary embodiment of the present invention, an SMS Message 112 in
In
Referring to
Various technologies may be used within the mobile middleware 120 and the notification program 202 to allow for transmitting notifications asynchronously from the mobile middleware 120 to the notification program 202. By way of example, the notification program 202 can be a webpage shown in a browser using JavaScript and Asynchronous JavaScript Technology and XML (“AJAX”) web technology. Once a subscriber is logged on to, e.g., a desktop computer 106 he or she logs onto his or her mobile phone account. Then the initial loading of the interface for the web application “/pcconsole” is completed, provided that, for example, the mobile middleware 120 on the mobile phone includes a web server that can respond to an HTTP request and that the web application related to the notification program 202 is prepared for execution and is accessible at URI “/pcconsole” for downloading to the web browser. Next, after necessary objects such as images, CSS, and JavaScript etc. are loaded the notification JavaScript in the notification program 202 (in this exemplary embodiment the webpage downloaded to the context of a web browser) is displayed and starts execution, polling the mobile phone 100 to fetch XML documents containing data to be parsed. Under the AJAX JavaScript programming paradigm, an XmlHTTPRequest object makes a new HTTP request to “poll” the status of the mobile phone 100 to Uniform Resource Identifier (“URI”) “/pcconsole/events?observer=username”. The URI “/pcconsole/events?observer=katja” is one example that the application “/pcconsole” will accept HTTP requests, provided the user is identifiable, in this example as “katja.” Once a user has been authenticated, the mobile middleware will return a response of the HTTP request in the form of XML documents. In this exemplary embodiment, AJAX (and XmlHTTPRequest object) is executing asynchronously, therefore, when the response is received, then the XML response body is parsed by the web application. The handler functions, which in this case are references to JavaScript functions that receive and deal with the event when it occurs, are initialized. Once initialized, these functions allow the webpage (“PcConsole”) to continue interaction with a user, and whenever an XML response is received it is handled by the appropriate function programmed in the web application.
In the exemplary embodiment shown in
The XML response is received by the web application on the desktop computer 106 and is parsed for display as a notification to the user. In this example, the HTTP request is pending all the time and therefore, may autonomously time out just like the browser which initiates the request, unless an event worth notification is received on the mobile phone 100 and dispatched by the mobile middleware 120 to the notification program 202 (in this example the AJAX web application) by means of an HTTP response to the HTTP request still pending.
As another example, the HTTP request may be answered by the mobile middleware 120 at one minute intervals even if no event has occurred and consequently there is nothing to send back. Once the HTTP response is received by the web application on the desktop computer 106, which in this example would be blank, a new request is made immediately. In this example, the implementation is such that an application level “push” is implemented at the lower level as a regular “pull,” a situation similar to the conventional page refresh mechanism on a web browser. However, in this example, the browser screen does not flicker, and the interaction is still smooth because the web page itself is not reloaded or re-rendered.
As yet another example, the HTTP request is answered immediately by the mobile middleware 120 using chunked encoded XML elements. An HTTP response can indicate that it is returning a chunked response, in which case it returns the data as a series of length-prefixed chunks, as “chunked transfer encoding” as defined in the HTTP 1.1 standard. In this example, most of the time the chunked response will be empty and therefore convey no notification. Whenever a remote terminal event occurs the chunked response from the mobile middleware 120 will contain data that is received by the program module on desktop computer 106 and is parsed for display as a notification to the user.
As another example of one exemplary embodiment of the present invention, the notification program 202 is an application specific Java Applet which acts as a temporary web server on the desktop computer 106 in the context of a Java enabled web browser—an embodiment that is atypical to the common use of Java Applets which, when involved in any form of communication, are normally used as web clients. Such a temporary web server, as described herein and as used in this example, creates a notification dialog when it receives from the mobile middleware 120 an HTTP request with details about a remote terminal event. In this example, the notification program 202 does not have to send an HTTP request. It is the mobile middleware 120 that acts as an HTTP client to the notification program 202 (in this example the Java Applet temporary web server) and is executed in the context of the web browser. The mobile middleware 120 transmits information to the user on the happening of a mobile phone event thereby achieving event notification in an asynchronous manner. In this example, the temporary web server on the desktop computer 106 can display a pop-up notification displaying “You have a message” when it receives XML data from the mobile middleware 120 telling it that a new mobile phone event has occurred. The XML data in this example would be:
The web browser determines the URL it has to download the Java Applet file from, which by way of example may be http://www.wswb.com/tempwebsrv/tmpwebsrvjar, and downloads it from the web server. After downloading, the Java Applet is initialized with configured parameters (as may be required) and is executed. This Java Applet (i.e. the temporary web server (308) applet), will make a connection (303) back to the web server to some specified port, and wait for HTTP requests to come. This connection is opened from the Java Applet (executing in the context of the web browser) to the web server, and not the other way around, as it would be customary if the web server was merely a pure (reverse) HTTP proxy. This special connection must be capable of conveying HTTP messages (requests and replies).
After the connection is initiated, the web server acts as a reverse HTTP proxy, e.g. by mapping the temporary web server onto its own URL space with a URL address, for example, http://www.wswb.com/˜katja. The mobile middleware acting as an HTTP client to the notification program transmits information to the user on the happening of a mobile phone event (304). The gateway (309) determines which connection should be used to dispatch the notification, as there may be a plurality of temporary web servers connected at any give point in time. The web server routes the notification information to the notification program (305), or more precisely, to the temporary web server (308) which, in turn, dispatches the information to the notification program (202), particularly, in this example, the user interface (i.e. notification window (307)) part of the notification program (202), which then receives the information and parses it for display as described above.
In the examples implementing a Java Applet which acts as a temporary web server on the desktop computer 106 in the context of a Java enabled web browser, the web browser on desktop computer 106 must be addressable. In a conventional system applying this example, the web browser on the desktop computer 106 is not addressable because the Java Applet, for security reasons, cannot create server sockets and cannot make connections to a web site other than the web server where it was downloaded. The addressability of the notification program 202 (in this example a Java Applet running in the context of a web browser) can be solved, for example, by introducing a custom internet gateway (309) that acts as a reverse HTTP proxy to all such temporary web-server-in-web-browser notification programs 202 by assigning them temporary URLs via which they can be accessed. In the present exemplary embodiment an example of the temporary URL would be http://www.wswb.com/˜katja. The connection between such reverse HTTP proxy i.e. gateway (309) and the Java Applet notification program 202 must be maintained so that all HTTP requests arriving at URL http://www.wswb.com/˜katja can immediately be dispatched through the said connection to be processed by the notification program 202. The connection between the reverse HTTP proxy and the Java Applet can be implemented in many ways. For example, the connection could be a proprietary TCP protocol, or it could be implemented in terms of an HTTP protocol with mechanisms to provide asynchronicity similar to an AJAX implementation i.e. a conceptual push can be implemented in terms of HTTP requests that are stalled until there is an event notification message to send, or HTTP requests stalled for only a certain short period (e.g. 1 minute) and answered whether there is something to report or not, or HTTP requests continuously answered by a stream of HTTP chunks that most of the time convey no payload notification. Having conceptually an invocable web server in the context of the web browser on the desktop computer 106 enables the mobile phone to send an HTTP message to the web browser telling it about a new event right after the event occurs, or at anytime thereafter.
The addressability of the notification program 202 is resolved because the Java Applets are allowed to open connections to any port and use any protocol (e.g. connection DB) to connect to their origin server, in this case the gateway (309). Gateway (309), in turn, presents the connected Java Applet as a web content provider mapped into its own temporary URL space (i.e. the originating web server acts as a reverse HTTP proxy). This will, in effect, mean that a special purpose temporary web server is implemented in the context of the Java enabled web browser on the network device.
It should be noted that the exemplary embodiments involving the AJAX solution (i.e. when the mobile middleware 120 includes a web server and notification program 202 is an AJAX page executed in the context of the web browser) and the solution with the reverse HTTP proxy (i.e. where the notification program 202 is a Java Applet maintaining a connection to the reverse HTTP proxy according to a proprietary protocol and a conceptual temporary web server) both maintain a constant connection. In the case of the AJAX solution the connection can be only HTTP based while in the reverse HTTP proxy case the connection can be a TCP protocol also. However, in the reverse HTTP proxy i.e. gateway (309) case the notification program 202 does not maintain the connection to the mobile web server included in the mobile middleware 120, but it maintains the connection to the reverse HTTP proxy i.e. gateway (309) on the Internet 104. This means reduced cost in terms of traffic and battery usage. Another advantage of reverse HTTP proxy is that it hides the technical details of connection maintenance from the application programmer and presents the application programmer writing the notification program 202 a clean and well understood paradigm to create the notification displayer notification program 202.
It is to be noted that these exemplary embodiments may be implemented in a cellular context i.e. such that the desktop computer 106 is a network device, which for example could be another remote terminal i.e. a second mobile phone or any mobile communicating device operable on any mobile communication system, and the notification program 202 is executed on the network device. In such an exemplary embodiment, the subscriber will log into his or her second mobile phone account via an interface on the second mobile phone, and as discussed in exemplary embodiments above, various technologies used within the mobile middleware 120 and the notification program 202 allow for transmitting notifications asynchronously from the mobile middleware 120 to the notification program 202 and to the subscriber on his or her second mobile phone.
It is to be noted that while the exemplary embodiment of the reverse HTTP proxy refers to the notification program 202 as being written as a Java Applet, it is by no means restricted to Java technology and can be implemented, for example, as a JavaScript, or any other technology that allows dynamically downloaded programs to execute in the context of a web browser and can create socket connections and/or HTTP requests to the originating server it was downloaded from, e.g. Macromedia Flash™.
In yet another example where the mobile phone is using Bluetooth or WLAN technology a small reverse HTTP proxy with stripped down functionality (not shown) can be installed on the mobile phone 100 or on Desktop Computer 106 which will then act as a gateway similar to the one in a cellular context utilizing a reverse HTTP proxy in the mobile communication network 102. This example is particularly important in implementing the present invention for the conventional Bluetooth system, where there is no gateway in the mobile communication network 102, because the task of keeping the connections with the mobile phone alive is entirely the task of the gateway connection protocol, which for example may use different keepalive, streaming, polling, pushing mechanisms or any combination thereof.
In one exemplary embodiment of the present invention, customized software is developed to be used as notification program 202, which allows the desktop computer 106 to receive asynchronous notifications from the mobile middleware 120 via Bluetooth/WLAN. A user executes the notification program 202 which, when executed receives one or more asynchronous notifications from the mobile middleware 120, parses those notifications and displays them to the user.
Mobile middleware 120 residing in memory 508 of remote terminal 100 could be specially designed software that allows a mobile phone application to configure events of interest and subsequently be notified of the occurrence of a configured event. Mobile middleware 120, or other program modules residing in memory 508, can also be used to associate a remote terminal with a particular user, to determine if the user is logged on, and to generate and send notifying messages on the happening of a configured mobile phone event.
It is noted that these examples are not intended to limit the breadth and scope of the invention, but rather to illustrate the variety of possibilities embodied in the transmission of remote terminal event information to subscribers over a network.
Hardware and Software
Various operations and/or the like described hereinabove may, in various exemplary embodiments, be executed by and/or with the help of computers. Further, for example, devices described hereinabove may be and/or may incorporate computers. The phrases “data computing device,” “general purpose computer,” “computer,” “remote terminal,” and the like, as used herein, refer but are not limited to a smart card, a media device, a personal computer, an engineering workstation, a PC, a Macintosh, a PDA, a portable computer, a computerized watch, a wired or wireless terminal, phone, communication device, node, and/or the like, a server, a network access point, a network multicast point, a network device, a set-top box, a personal video recorder (PVR), a game console, a portable game device, a portable audio device, a portable media device, a portable video device, a television, a digital camera, a digital camcorder, a Global Positioning System (GPS) receiver, a wireless personal server or the like, or any combination thereof, perhaps running an operating system such as OS X, Linux, Darwin, Windows CE, Windows XP, Windows Server 2003, Palm OS, Symbian OS, or the like, perhaps employing the Series 40 Platform, Series 60 Platform, Series 80 Platform, and/or Series 90 Platform, and perhaps having support for Java and/or .Net.
The phrases “data computing device,” “general purpose computer,” “computer,” “remote terminal,” and the like also refer, but are not limited to, one or more processors operatively connected to one or more memory or storage units, wherein the memory or storage may contain data, algorithms, and/or program code, and the processor or processors may execute the program code and/or manipulate the program code, data, and/or algorithms. Each of I/O interfaces may, for example, be an Ethernet, IEEE 1394, IEEE 1394b, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11i, IEEE 802.11e, IEEE 802.11n, IEEE 802.15a, IEEE 802.16a, IEEE 802.16d, IEEE 802.16e, IEEE 802.16x, IEEE 802.20, IEEE 802.15.3, ZigBee, Bluetooth, Ultra Wide Band (UWB), Wireless Universal Serial Bus (WUSB), wireless Firewire, terrestrial digital video broadcast (DVB-T), satellite digital video broadcast (DVB-S), Advanced Television Systems Committee (ATSC), Integrated Services Digital Broadcasting (ISDB), Digital Multimedia Broadcast-Terrestrial (DMB-T), MediaFLO (Forward Link Only), Terrestrial Digital Multimedia Broadcasting (T-DMB), Digital Audio Broadcast (DAB), Digital Radio Mondiale (DRM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications Service (UMTS), Global System for Mobile Communications (GSM), Code Division Multiple Access 2000 (CDMA2000), DVB-H (Digital Video Broadcasting: Handhelds), IrDA (Infrared Data Association), and/or other interface.
Mass storage may be a hard drive, optical drive, a memory chip, or the like. Processors may each be a commonly known processor such as an IBM or Freescale PowerPC, an AMD Athlon, an AMD Opteron, an Intel ARM, an Intel XScale, a Transmeta Crusoe, a Transmeta Efficeon, an Intel Xenon, an Intel Itanium, an Intel Pentium, or an IBM, Toshiba, or Sony Cell processor. Computer as shown in this example also includes a touch screen and a keyboard. In various exemplary embodiments, a mouse, keypad, and/or interface might alternately or additionally be employed. Computer may additionally include or be attached to card readers, DVD drives, floppy disk drives, hard drives, memory cards, ROM, and/or the like whereby media containing program code (e.g., for performing various operations and/or the like described herein) may be inserted for the purpose of loading the code onto the computer.
In accordance with various exemplary embodiments of the present invention, a computer may run one or more software modules designed to perform one or more of the above-described operations. Such modules might, for example, be programmed using languages such as Java, Objective C, C, C#, C++, Perl, Python, and/or Comega according to methods known in the art. Corresponding program code might be placed on media such as, for example, DVD, CD-ROM, memory card, and/or floppy disk. It is noted that any described division of operations among particular software modules is for purposes of illustration, and that alternate divisions of operation may be employed. Accordingly, any operations discussed as being performed by one software module might instead be performed by a plurality of software modules. Similarly, any operations discussed as being performed by a plurality of modules might instead be performed by a single module. It is noted that operations disclosed as being performed by a particular computer might instead be performed by a plurality of computers. It is further noted that, in various exemplary embodiments, peer-to-peer and/or grid computing techniques may be employed. It is additionally noted that, in various exemplary embodiments, remote communication among software modules may occur. Such remote communication might, for example, involve Simple Object Access Protocol (SOAP), Java Messaging Service (JMS), Remote Method Invocation (RMI), Remote Procedure Call (RPC), sockets, and/or pipes.
It is noted that various operations and/or the like described herein may, in various exemplary embodiments, be implemented in hardware (e.g., via one or more integrated circuits). For instance, in various exemplary embodiments various operations and/or the like described herein may be performed by specialized hardware, and/or otherwise not by one or more general purpose processors. One or more chips and/or chipsets might, in various exemplary embodiments, be employed. In various exemplary embodiments, one or more Application-Specific Integrated Circuits (ASICs) may be employed.
The present invention is described above by using the Global System for Mobile Communication (“GSM”) mobile communication system as an example of the information transmission network system. However, the invention is not limited to this mobile communication system. The invention can also be applied in other mobile communication systems which have the capability for transmitting addressed information. The mobile communication system can be simplex or duplex.
As is known, a GSM mobile communication network consists of mobile services switching centers (“MSC”) and of base station systems (“BSS”). A base station system consists of a base station and a base station controller. Each BSS is controlled by one MSC. MSC's communicate with each other, wherein calls and other signaling can be transmitted within the mobile communication network as well as between the mobile communication network and a landline telecommunication network or another mobile communication network. In the same geographical area, there can also be several mobile communication networks. The MSC has a home location register (“HLR”) and a visitor location register (“VLR”). The HLR is a database of the mobile communication network containing the basic data of the mobile phone subscribers registered in the network. The HLR contains, for example, the international mobile subscriber identity, the mobile subscriber international ISDN number, and data related to the services available to the subscriber. The VLR is a database of the mobile communication network containing the data required of the mobile subscribers within the area of the mobile communication network at each time for the transmission of calls. The visitor location register VLR is used, for example, for the control of the mobility of the mobile phone, wherein calls and messages can be directed to the correct mobile phone, also in a situation where the mobile phone is in the area of a different mobile communication network than in which the mobile phone is registered. This situation comes also for example when the mobile phone is used abroad.
With GSM mobile phones, each mobile subscriber must have at least one subscriber identity module (“SIM”) card. This SIM card contains the identification data of the mobile subscriber, such as the code and telephone number of the mobile subscriber. Thus by using these identification data, the messages and calls can be directed to the correct mobile station. The SIM card can also be moved to another mobile station, if necessary, wherein also the calls are transmitted to this other mobile phone. The use of a SIM card requires usually that a PIN code is entered at the stage when the mobile phone is turned on. This PIN code can be changed by the mobile subscriber, and the code is intended for preventing misuse of the SIM card for example if the SIM card is lost.
Ramifications and Scope
Although the description above contains many specifics, these are merely provided to illustrate the invention and should not be construed as limitations of the invention's scope. Thus it will be apparent to those skilled in the art that various modifications and variations can be made in the system and processes of the present invention without departing from the spirit or scope of the invention.
In addition, the exemplary embodiments, features, methods, systems, and details of the invention that are described above in the application may be combined separately or in any combination to create or describe new exemplary embodiments of the invention.
It is noted that the various examples of this exemplary embodiment are not intended to limit the breadth and scope of the invention, but rather to illustrate the variety of possibilities embodied in processing and displaying the notification of remote terminal events to a user.