WO2011053741A1

WO2011053741A1 - Systems, methods and apparatus that enable a party to monitor the use, location or speed of travel of a telecommunications device

Info

Publication number: WO2011053741A1
Application number: PCT/US2010/054589
Authority: WO
Inventors: Sharon Hamilton
Original assignee: P.A.L.S. Inc.
Priority date: 2009-10-28
Filing date: 2010-10-28
Publication date: 2011-05-05

Abstract

A system for monitoring telecommunications activity includes a cloud server having an installed web service, and a plurality of device applications. Each device application is installed on a respective telecommunications device and configures a processor of the respective telecommunications device to i) monitor storage of new messages in a message inbox and a message outbox of the respective telecommunications device, and ii) transmit data pertaining to new messages to the cloud server. A device application and the cloud server may also operate to block particular calϊs or messages. A device application may also collect and report a device's location and speed of travel information to the cloud server.

Description

SYSTEMS, METHODS AND APPARATUS THAT ENABLE A PARTY TO MONITOR THE USE, LOCATION OR SPEED OF TRAVEL OF A

TELECOMMUNICATIONS DEVICE

Background

[0001] Children today have access to an ever-expanding array of telecommunications devices and telecommunications services. The telecommunications devices include, for example, smartphones, smartbooks and tablet computers. The telecommunications services include, for example, phone calls, text messages, multimedia messages, instant messages, emails and twits. Typically, much of the information

communicated via these services is hidden from a parent. At best, a parent may be able to view call or message logs provided by their child's

telecommunications carrier, which logs are difficult to access and shed little light on the nature of their child's communications.

[0002] Because of bullies, predators, and the simple desire to be a good parent, a parent needs systems, methods and apparatus that provide them with greater insight into, and control over, their chikf s communications. Brief Description of the Drawings

[0003] Illustrative embodiments of the invention are illustrated in the drawings, in which:

[0004] FIG. 1 provides an example of a system topology that enables a party having an ownership or control interest in a telecommunications device to monitor the use, location or speed of travel of the telecommunications device;

[0005] FIG. 2 provides an example of how the device application shown in FIG. 1 might be integrated with its telecommunications device for the purpose of monitoring (and possibly blocking) inbound and outbound message activity;

[0006] FIG. 3 provides an example of a Java MobileEdition (Java ME) class diagram for implementing the message monitoring component of the device application shown in FIG. 1;

[0007] FIG. 4 illustrates various modules that may be incorporated into the device application;

[0008] FIGS. 5-8 illustrate an exemplary user interface for managing call and text blocking;

[0009] FIGS. 9 & 10 illustrate exemplary communication flows between the cloud server and one particular device application;

[0010] FIG. 11 illustrates a plurality of modules that may be implemented by the web service hosted on the cloud server;

[0011] FIG. 12 illustrates a Message/Call Decision process that may, for example, be executed by the message processing or call processing modules of the web service;

[0012] FIG. 13 illustrates a Location Monitoring process that may, for example, be executed by the location processing module of the web service shown in FIG. 11;

[0013] FIGS. 14-18 illustrate various screens of a user interface provided to an account owner for the purpose of viewing and managing information related to their account or a monitored device; and

[0014] FIG. 19 provides a block diagram of an exemplary computer system 1900, which computer system 1900 may provide the hardware, software and functionality for implementing a cloud server and its modules.

[0015] It is noted that, in the following description, like reference numbers appearing in different drawing figures refer to like elements/features. Often, therefore, like elements features that appear in different drawing figures will not be described in detail with respect to each of the drawing figures.

Detailed Description

[0016] Disclosed is a system that enables a party having an ownership or control interest in a telecommunications device to monitor the use, location or speed of travel of the telecommunications device. By way of example, the telecommunications device may take the form of a smartphone, smartbook or tablet computer. In some cases, the system may also provide some degree of control over use of the telecommunications device. For example, the system may block calls or messages that a user of the device attempts to place or send to, or receive from, a set of blocked phone numbers.

[0017] The disclosed system can be used in a variety of contexts, and for a variety of purposes. However, in one particularly important context, the system enables a parent to monitor or control the use of their child's smartphone or other form of telecommunications device. In this manner, a parent can protect their child from the dangers that become far more immediate when their child has unmonitored access to a variety of

telecommunication services (e.g., phone calls, text messages, and

multimedia messages). The system makes visible what would otherwise be hidden from a parent, such as the content of messages, the sources and destinations of calls and messages, and information about the location and speed of movement of a child's smartphone. Once this information is visible to the parent, the parent can take the actions that are necessary to protect their child.

[0018] FIG. 1 illustrates an example of a topology of the system. Here, a smartphone (a device 102) communicates with a telephony gateway 104, a message gateway 106, a data gateway 108, and Global Positioning System (GPS) resources 110. The device 102 communicates with the telephony gateway 104 via a telecommunications interface that is operable in accord with a telephony protocol. The device 102 communicates with the message gateway via a telecommunications interface that is operable in accord with a message protocol, such as a Short Message Service (SMS) protocol. The device 102 communicates with the data gateway 108 via a telecommunications interface that is operable in accord with a data protocol, such as Hypertext Transfer Protocol (HTTP).

[0019] The telephony gateway 104 couples the device 102 to a telephony network 112 over which a user of the device 102 can place and receive phone calls. The message gateway 106 couples the device 102 to message senders and receivers 114, 116. In one embodiment, the message gateway 106 may be an SMS gateway. The data gateway 108 couples the device 102 to various message and data sources and receivers, via a public or private network such as the Internet 118. The GPS resources 110 provide GPS signals or information to the device 102.

[0020] In one use case for the system 100 disclosed in FIG. 1 , a third party SMS sender 114 may send an SMS message into the operator's message gateway 106 (e.g., an SMS gateway), which SMS message is then routed to the device 102. An application 120 installed on the device 102 listens or checks for receipt of inbound SMS messages, and upon

discovering that the SMS message has been received at the device 102, causes data pertaining to the inbound SMS message to be transmitted from the device 102, through the data gateway 108, and over the Internet 118 to a cloud server 122 hosting a web service. At the cloud server 122, the data pertaining to the inbound SMS message is logged or processed, and an acknowledgement of the inbound SMS message data is returned from the cloud server 122 to the device application 120. The acknowledgement indicates whether or not the inbound SMS message data was received in good form at the cloud server 122.

[0021] The application 120 installed on the device 102 also listens or checks for the sending of SMS messages, and upon discovering an outbound SMS message sends data pertaining to the outbound SMS message from the device 102 to the cloud server 122. At the cloud server 122, the data pertaining to the outbound SMS message is logged or processed, and an acknowledgement of the outbound SMS message data is returned from the cloud server 122 to the device application 120. The acknowledgement indicates whether or not the outbound SMS message data was received in good form at the cloud server 122. Before, after or in parallel with the device application 120 sending data pertaining to the outbound SMS message to the cloud server 122, the outbound SMS message may be posted through the message gateway 106 to a third party SMS recipient 116.

[0022] The application 120 on the device 102 can also listen or check for other types of inbound or outbound messages received through the message gateway 106, such as Multimedia Messaging Service (MMS) messages. MMS messages may be received and sent in different ways, depending on the capabilities of the device and its service provider (e.g., its carrier). In some cases, an MMS message may be sent from the device 102, through the data gateway 108, to a Multimedia Messaging Service Center (MMSC) 124. The MMSC 124 then determines how to deliver the MMS message to a particular recipient. An MMS message may be received at the device 102, in some cases, in the form of 1) a control message received from the message gateway 106, which control message specifies a Uniform Resource Locator from which the message content can be downloaded, and 2) a download of the message content via the data gateway 108. Despite the channels through which an MMS message is sent or received, the application 120 on the device 102 listens or checks for the receipt and sending of MMS messages based on activity at the device 102, and upon discovering that an inbound or outbound MMS message has been received or is being sent, sends data pertaining to the MMS message from the device 102 to the cloud server 122.

[0023] The application 120 on the device 102 also listens or checks for inbound and outbound phone calls, and sends data pertaining to the phone calls to the cloud server 122. Of note, the application 120 listens or checks for activity on the device, and thus listens or checks for inbound and outbound phone calls based on activity occurring at the device 102.

[0024] Still further, the application 120 communicates with GPS resources 126 on the device 102, which GPS resources 126 in turn communicate with GPS resources 110 external to the device (such as GPS satellites). The application 120 may request GPS information such as longitude, latitude and altitude from the GPS resources 126, 110, and may then transmit this information to the cloud server 122.

[0025] It is noted that the device application 120 will typically be implemented as a software program. References herein to actions taken or performed by the device application 120 are therefore understood to be actions taken by a processor that has been configured by the device application 120.

[0026] One advantage of the system 100 shown in FIG. 1 is that it monitors telecommunications activity based on activity occurring at the device 102, and not by intercepting communications at some point external to the device 102 (e.g., at a gateway). In particular, the device application 120 may interface with the telephony or messaging services of the device 102, or with the data storage (e.g., inboxes, outboxes, call togs) of the device 102. Assuming that the device application 120 is installed by a person having a rightful ownership or control interest in the device 102, the monitoring arrangement illustrated in FIG. 1 typically makes it easier to comply with applicable privacy, wiretapping and other laws that pertain to monitoring the telecommunications activity of a device's user.

[0027] The device application 120 communicates bi-directionally with the cloud server 122 that provides the web service. Communications sent from the device application 120 (the client) to the cloud server 122 can take the form of standard HyperText Transport Protocol (HTTP) messages using the POST format. Such communications enable the sending of larger documents and paytoads.

[0028] Depending on the needs of the cloud server 122, and by way of example, either HTTP 1.0 or 1.1 protocol can be used to send

communications from the device application 120 to the web service. The difference is that HTTP 1.1 communications divide data into two kilobyte segments (or chunks), and some servers are known to have difficulties reassembling these segments into a single fluid data stream.

[0029] An HTTP request is posted to a Post Receiver page hosted by the cloud server 122, and is posted using a POST request method.

[0030] Communications from the device application 120 to the cloud server 122 can take the form of messages comprised of key/value pairs, using standard x-www-form-urlencoded syntax and delimiters of ampersands '&'. That is, each key value pair is separated by an '&' character, and each key is separated from its value by an character. Keys and values are both escaped by replacing spaces with the v character and then using URL encoding on all other characters. A communication from the device application 120 to the cloud server 122 may therefore assume the following format:

[0031] Key/value pairs may be posted in any order and are preferably in the ASCII character set. Because a back-end server will likely be written in a non-Java language, the use of ASCII characters can ease integration of data. However, the back-end server may be constructed to also read and translate binary values in the correct Endean format The use of binary values can reduce the sizes of transmissions, and can provide a level of data

obfuscation if the data were to be seen.

[0032] An example set of key/value pairs, deemed useful for monitoring a device's inbound and outbound messages, inbound and outbound phone calls, location, and speed, is provided in the following table:

[0033] Use of the above set of key/value pairs to communicate various types of data to the cloud server 122 will be described in more detail later in this description. However, a sample message sent from the device application to the cloud server at 2:32:04 pm on October 8, 2010 can take the following form: http:/ www. kidphoneadvocate. com/A=8005551212&E=8177734728&V =3.0.1 &T=0&D=100810143204&P=1 &S=93&F=0&Z=-6&M=Hi Shawn, how is it going. Wanted to give you this link. HTTP://www. noonle.com to look at.

[0034] In some embodiments, the value of the message type key (T=) may be a "0" for text and a " for binary. In other embodiments, the message type key may take one of the following values: 0 - represents a SMS Message

1 - represents a MMS Message

2 - represents a GPS Message

3 - represents a Call Message

5 - represents an Installation Configuration Message

In still other embodiments, other sets of values for distinguishing message types could be used.

[0035] In response to receiving a communication from the device application 120, the cloud server 122 may respond to the device application 120 with an acknowledgement (ACK) indicating successful processing, or with a non-acknowledgement (NAK) indicating unsuccessful processing of a posted message. A NAK response can include an error or reason code. For example, in some embodiments, a positive acknowledgement response from the server 108 can return the text 'ACK^* with a content-length field of three; and a negative acknowledge response can return the text 'ΝΑΚ-' with a 3 digit code, and with the content-length field set to 7.

[0036] Communications from the cloud server 122 to the device application 120 can be sent using the SMS protocol, and may be formatted, for example, with key words and data using the Subject Line and Body Text to communicate phone application functionality.

10037] An example set of NAK codes, and indications of whether the codes cause the device application 120 to resend a message, are provided in Table 2.

[0038] The device application 120 may also resend a message if it does not receive an ACK or a NAK, by initiating a new POST Request. This ability can be multi-threaded, so as not to interfere with normal device usage.

Retries upon failure to receive a post response of either an ACK or a NAK may occur, for example, every 30 seconds for a limit of 5 retry attempts.

[0039] FIG. 2 provides an example of how the device application 120 (FIG. 1 ) might be integrated with its device 102 for the purpose of monitoring (and possibly blocking) inbound and outbound message activity. As shown, the device 102 has an SMS/MMS port 200 (e.g., a telecommunications interface operable in accord with a message protocol). Inbound messages from a sending device 202 are received at the SMS MMS port 200 and stored in a message inbox 204 of a physical data store 206. The inbound messages can then be read or viewed from the message inbox 204 by a device user (at block 208). This flow is typical of the inbound message flow of most telecommunications devices. Vvbat is new is that the device application 120 configures a processor to listen or check for changes to the physical data store 206, and particularly, configures the processor to monitor the physical data store 206 to determine when new messages are stored in the message inbox 204. Upon determining that a new inbound message has hit the inbox 204, the device application 120, via the processor, transmits data pertaining to the new inbound message (including the content of the new message) to the cloud server 122. The device application 120 does this by assembling data pertaining to the message into a string of key/value pairs, and then transmitting a message containing the key/value pairs via a

telecommunications interface of the device 102. Preferably, the

telecommunications interface via which the message is transmitted implements a data protocol, such as HTTP. In some embodiments, the messages containing the key/value pairs may be posted to an HTML Post Receiver 210 of the cloud server 122. An example of such a POST request is: lTtto:/ www.kidphoneaclvc»te.com/A=8583348108&E=8586768901&V =1 &F=1 &T=0&D=101026131824&Z=1 &P=1 &S=[Size of the message body] &M=[Message Body]

[0040] The cloud server 122 then saves the string of key/value pairs as "stored data" 212 on a database server 214 or other storage device. Upon the string of key/value pairs being stored at the database server 214, a web service 216 of the cloud server 122 determines whether the string of key/value pairs is parseable and returns an ACK or NAK message to the device application 120.

[0041] In the case of outbound messages, a message is constructed by a user of the device (at block 218), and upon the user selecting to "send^* the message, the message is released to the message out box 220 of the physical data store 206. The outbound message is then transmitted to a receiving device 222 via the SMS/MMS port 200. This flow is typical of the outbound message flow of most telecommunications devices. What is new is that the device application 120 configures a processor to listen or check for changes to the physical data stored 206, and particularly, configures the processor to monitor the physical data store 206 to determine when new messages are stored in the message outbox 220. Upon determining that a new outbound message has hit the outbox 220, the device application 120, via the processor, copies data pertaining to the new outbound message (including the content of the new message) to the cloud server 122. The device application 120 does this by assembling data pertaining to the message into a string of key/value pairs, and then posting the message containing the key/value pairs to the HTML Post Receiver 210 of the cloud server 122. An example of such a POST request is: http:/ www.kidphoneadvc<ate.com/A=8583348108&E=8586768901 &V =1 &F=0&T=0&D=101026131824&Z=1 &P=1 &S=[Size of the message body] &M=[Message Body]

{0042] The cloud server 122 then saves the string of key/value pairs as "stored data^* 212 on the database server 214 or other storage device. Upon the string of key/value pairs being stored at the database server 214, a web service 216 of the cloud server 122 determines whether the string of key/value pairs is parseable and returns an ACK or NAK message to the device application 120.

[0043] As already noted, the message Inbox 204 and message outbox 220 may be provided as data structures maintained in the physical data store 206. By way of example, the physical data store 206 may be a random access or flash memory. The physical data store 206 may also provide data structures for maintaining call logs and call data, and other data structures.

[0044] FIG. 3 provides an example of a Java MobiteEdition (Java ME) class diagram 300 for implementing the message monitoring component of the device application 120. Mobile phone makers realize privacy is a major concern to users, and within the Java ME there are strict requirements that privacy and security of user data be protected. As such, MIOIets, a JavaME application, do not have the ability to hook into the telephony services in the current and widespread MIDP2.0 standard. There is a Java Specification Request ( JSR) that has been finalized for a few years now (jsr-253 Mobile Telephony API) which speaks to those feature sets. However, no JavaME Java Virtual Machines (JV s) have been deployed that support it. The RIM Blackberry devices do, however, support this concept in Java. This is because nearly their entire OS is written in Java, with the use of extension APIs that can be used in JavaME IDIets on RIM devices. For the rest of the market (e.g., Symbian, Brew, iPhone, Android, WindowsMobile), the needed features can be achieved through hooks to a device's telephony services. It is currently known that Symbian and WindowsMobile both have the necessary APIs.

[0045] Returning now to the class diagram 300 shown in FIG. 3, it is noted that the class diagram 300 shows the primary classes of the

implementation. Other classes may also be implemented. The SysEventMgr class 302 handles system events, and provides a mechanism for processing SMS notifications received from the cloud server 122. The MessageProc class 304 is the central processing logic for standard SMS messages (both inbound and outbound) and has access to the HttpUtils library code 306 to make calls (e.g., POST requests) to the cloud server 122. The MyPALS class 308 is not only the base MIOIet code, but is also the listener for SMS messages and directs them to their proper processor (e.g., SysEventMgr 302 or MessageProc 304). MyPALS 308 uses a helper class StartUpProc 310 to encapsulate the initialization code so that it can be de-referenced and unloaded from device memory, thus reducing the in-memory footprint of the device application. Similarly, the PalUI 312 is a class which contains ail user interface (Ul) building and command setup when and if it is needed.

However, unless the device application 120 has been configured to provide a Ul for debugging or user control of the device application 120, the Ul is never initialized when a user boots their device 102 or otherwise starts the device application 120. This leaves a headless application. If the Ul is activated through a Java Application Descriptor (JAD) property setting, this Ul class is initialized and provides debug feedback when a user starts the device application 120, else it is not loaded so as not to impact device memory usage. The DataMgr class 314 manages data that the device application 120 has copied from a device's physical data store 206.

[0046] The above design has been constructed with a view of delegating responsibilities of processing to meaningful classes, and in a way that is easily interpreted into other device phone operating system languages, such as Symbian and Brew. The classes 302-314 should be able to provide each platform and language the best results and control over footprint size, and provide classes which will have operating system specific logic, while allowing similar class structures across languages for better communication between developers.

[0047] In the class diagram 300, particular method names are provided. However, these method names may change over time and revisions, and may need to be altered for each development language.

[0048] There are four references listed on the class diagram 300 that are JavaME specific. These are: MessageListener 316, CommandListener 318, Command 320, and Form 322. These references have been provided for completeness, and to assist in describing the responsibilities of the parent or implementation classes to which they are tied, in the case of Command 320 and CommandListener 318, these references provide support for issuing user command events (like exit), and the processor to handle their execution, respectfully. Form 322 is the JavaME screen object which holds components to be displayed and takes other forms for other languages. MessageListener 316 is the interface type used to provide the JavaME system with system notifications of SMS messages.

[0049] FIG. 4 illustrates various modules 400, 402, 404, 406, 408 that may be incorporated into the device application 120. In some deployments of a device application, only some of these modules 400-408 may be activated or enabled. For example, a person may log into an enrollment website and select which of the modules 402-408 they would like to activate - possibly in response to different needs and acceptable price points. The modules 400- 408 include a message module 400, a call module 402, an image module 404, a location module 406, and a call and message blocking module 408. [0050] The message module 400 may be implemented as shown in FIQS. 2 & 3. The image module 402 may be implemented in a similar fashion, with the exception that the device application 120 may need to retrieve images from a different data structure within the physical data store 206. The device application 120 may also need to send images to the cloud server 122 as multipart messages. The differences between regular SMS messages and multipart messages are described below.

[0051] The SMS messages commonly used by mobile phones have a text only format that includes between 120 and 160 characters. The SMS messages can have web links and phone numbers within them, however the interpretation and parsing of this information is device specific. There are no special tags encoded into the message that trigger support for selecting a URL or phone number and using it in the expected manner. However, outside the message there are specific attributes that are sent with the message. These attributes (or fields) include the sender's address (phone number or shortcode), a timestamp, and the type of message (text binary). In some cases, messages can extend beyond the 160 character format, and these messages become multipart messages. This was the first method used to send images from phone to phone. However, this caused SMS charges to be incurred for each message part. Later the MMS message, with its larger payload support, and special SMS messages with URLs that trigger standard HTTP communications, were developed to remedy these excessive multiple charges. To support the transmission of multipart messages to the server, the standard multipart form MIME type can be used to assemble messages, when needed.

[0052] An example of a POST request for sending an image to the cloud server 122 is: http:/ www.kidphoneadvocate_^

=1 &F=1 &T=1 &D=101026131824&Z=354&P= 1 &S=[length of the message which is basically the size of the binary message]&M=[binary message converted into UTF-8 ASCII format] [0053] The call module 404 may also be implemented similarly to the message module 400, but with the exception that the device application 120 may need to configure the processor of the device 102 to 1) monitor the storage of new call data in, and 2) retrieve call data from, a different data structure (e.g., a call log) within the physical data store 206. In addition, only the details of a call (e.g., inbound outbound external party phone number, and call duration), and not a recording of the call, are sent to the cloud server 122. An example of a POST request for sending call data to the cloud server 122 is: http://www.kidp ioneadvc<ate.(X>rn/A=8583348108&E=2245678901 &T =3&D=101026131824&F=0&V=0&C=1920

[0054] The location module 406 is implemented somewhat differently than the message, image and call modules 400, 402, 404. That is, instead of monitoring telecommunications activity, the location module 406 monitors or derives information such as latitude, longitude, horizontal accuracy, and speed. In some cases, the location module may retrieve or request this information from GPS resources 126 on-board the device 102 (see FIG. 1). For example, the location module 406 may request this information from a GPS application installed on the device 102, or from the device's operating system; or, the location module 406 may retrieve this information from a register or more permanent data store within the device 102. In still other cases, the location module 406 may compute "speed" itself, based on other GPS data. However, a speed computation function will sometimes be provided by a device's GPS application or resources 126, or by external GPS resources 110 with which the on-device GPS resources 126 communicate. 10055] Upon GPS data being communicated from the device 102 to the cloud server 122 via the device application 120, the web service 216 of the cloud server 122 can use the GPS data to provide an owner of the device 102 with location tracking and speed tracking services. For example, the web service 216 may provide the device owner with a web page that plots a device's current or historical GPS coordinates on a map. Alternately, the web service 216 may simply convey to a device owner the current location of the device 102. In some cases, the GPS coordinates may be translated to a particular street address, or to a common name of a particular location. With respect to speed, the web service 216 may chart or map particular device movement speeds in the context of particular locations. Alternately, the web service 216 may simply convey to a device owner the current speed of the tracked device, or provide an alert when the speed of the device crosses a defined threshold (e.g., movement over 10 miles per hour).

[0056] In some cases, a device application 120 may be programmed to report device location and speed information when such information is requested by the web service 216. In other cases, a device application 120 may be programmed to report device location and speed information at predetermined intervals, or in accord with a more complex reporting algorithm. Certainly, more frequent reporting of device location and speed information enables more accurate tracking of a device's location and speed. However, more frequent reporting also places a larger draw on a device's battery. In some cases, an owner of a telecommunications device 102 may indicate to the web service 216 how often location and speed information should be reported, and the web service 216 may then communicate changes in settings to the device application 120. In other cases, the frequency of reporting may be set through an on-devtce Ul of the device application 120. Reporting may also be conditioned on the nature of the data to be reported. For example, if a device owner (e.g., a parent or employer) is only concerned about speed tracking, and not location tracking, the device application 120 can determine if a current device speed exceeds a threshold, and then only report the device's current speed when the threshold is exceeded.

[0057] An example of a somewhat more sophisticated algorithm for reporting location and speed information is disclosed below: 1. Initially set GPS data collection and reporting frequency to 2 minutes (i.e., collect and report at 2 minute intervals).

2. If the most recent speed of movement is < 10 mph, increase the GPS data collection and reporting frequency by 15 seconds, unless the GPS data collection and reporting frequency has reached a GPS data collection and reporting frequency of 5 minutes, which is the maximum GPS data collection and reporting frequency.

3. If the most recent speed of movement is greater than or equal to (>=) 10 miles per hour, reset the GPS data collection and reporting frequency to 2 minutes.

[0058] It is noted that the numerical values used in the above algorithm are examples only and can be set to other values. It is also noted that the above algorithm is only an example, and other algorithms for collecting, reporting, or collecting and reporting GPS data can be used.

{0059] All reporting variables, such as maximum and minimum selection limits, should be configurable through a back-office administrative website interface of the cloud server 122.

[0060] Similarly to the message, image and call modules 400, 02, 404, the location module 406 can communicate location and speed information to the cloud server 122 using relevant ones of the key/value pairs disclosed in Table 2. Using these key value pairs, an example of a POST request for sending location and speed information to the cloud server 122 is: http://www.kidphoneadvocate.com/A=8583348108&T=2aD=10102613 1824&Z=3&V=0&Lat=33.023162&Lon=117.1133 1 &Y=1 &U=0&Spd=1 2

{0061] In some embodiments, the device application 120 may comprise a call and message blocking module 408 that, alone or in combination with the cloud server 122, blocks certain calls or messages from being sent, placed or received from/to the device 102. This may be done by providing a Ul at either or both of the device application 120 and the cloud server 122. If the Ul is provided at the device application 120, a device user or owner may enter blocked phone numbers, email addresses, URLs and other external party identifiers into the device 102. The blocked phone numbers or other external party identifiers may then be used to block calls or messages from being sent, placed or received from/to the device 102. If the Ul is provided at the cloud server 122, a list of blocked phone numbers or other external party identifiers may be downloaded to the device application 120, or may be maintained solely at the cioud server 122. In the context of call and message blocking, the remainder of this description only refers to blocked phone numbers. However, it is understood that the disclosed systems, methods and apparatus for blocking calls and messages are largely applicable to the blocking of calls and messages tied to any type of external party identifier.

[0062] Preferably, a list of the blocked phone numbers is maintained by both the cloud server 122 and the device application 120. When a call or message is to be sent or placed, or is received, the phone number of the external party, along with other details of the call or message, are

communicated to the cloud server 122. Also, a determination as to whether the call or message is "allowed^* or "blocked" is made by the device

application 120 or web service 216. In the case of calls, it may be preferable to have the device application 120 determine whether the call should be "allowed" or "blocked", so that a determination can be made fast enough to terminate an incoming or outgoing call before it is answered or placed. The device application may make this determination by configuring the processor of the device 102 to compare a phone number of an external party involved in a call to blocked phone numbers. If a particular call is determined to be blocked, the device application 120 may then terminate the call by interfacing with the telephony services of the device 102.

[0063] in the case of messages, it may be preferable to have the web service 216 determine whether the message should be "allowed" or

"blocked". In this manner, a message may also be parsed to determine whether it should be blocked based on the existence of Watchwords or Lingo Phrases. If this parsing is done by the web service 216, the processing logic of the device application 120 can be kept lighter, thereby decreasing the device application's consumption of a device's more limited processing and power resources. The parsing of a message for Watchwords and Lingo Phrases wili be described in more detail later in this disclosure. To prevent a message from being transmitted or viewed before the web service 216 is able to determine whether it should be "blocked" or 'allowed", the device application 120 may copy the message from the device's message inbox 204 or message outbox 220, temporarily store the message in a data cache outside of the inbox 204 or outbox 220, and delete the message from the inbox 204 or outbox 220. After receiving a decision or determination that the message is "allowed" (or making such a decision or determination itself), the device application 120 may then copy the message back into the inbox 204 or outbox 220 from which it was deleted. If a message is "blocked", the message is deleted from the cache and not written back into the inbox 204 or outbox 220.

[0064] In some embodiments, the Ul for entering blocked phone numbers may only be provided by the web service 216, and the device application 120 need not have any knowledge of which phone numbers are on a blocked list. Alternately, blocked phone numbers entered through a Ul of the web service 216 may be provided to the device application 120, and a list of the blocked phone numbers may or may not be viewable via a Ul of the device

application 120.

[0065] In some embodiments, only incoming calls or messages may be analyzed to determine whether the calls or messages are being received from a blocked phone number. This sort of blocking can be especially useful if a device user wants to avoid being harassed by a bully or other type of undesirable caller. In some cases, different lists of blocked phone numbers may be maintained for incoming calls or messages, for outgoing calls or messages, for calls only, or for messages only.

[0066] Regardless of where a Ul for entering blocked phone numbers is provided, the Ul may also enable a device user or device owner to remove blocked phone numbers from a list of blocked phone numbers.

[0067] The functionality of call and message blocking necessitates making an icon for the device application 120 visible on the device 102 - that is, the icon must be made visible if a Ul for entering blocked phone numbers is to be provided at the device 102 However, the ability to uninsta!! or otherwise alter the call and message blocking provided by the device application 120 can be prevented. If the device application 120 provides a Ul for entering blocked phone numbers at the device 102, the device application 120 is preferably configured to forward all requests for call and message blocking changes to the cloud server 122, for approval and implementation by the web service 216 (or by someone logged into the web service 216).

[0068] FIGS. 5-8 illustrate an exemplary Ul 500 for managing call and text blocking. As discussed above, the Ul 500 may be provided via a Ul of the device application 120, or via a Ul of the web service 216. Access to the Ul 500 on the device 102 may be accomplished by selecting an icon displayed on the device's display.

[0089] The Ul screen 502 shown in FIG. 5 provides a menu with selections titled "Add a number^* 504, "Remove a number" 506 and

"Properties" 508. Selecting the "Add a number" selection 504 causes a display of the screen 600 shown in FIG. 6. The screen 600 shown in FIG. 6 includes a text box 602 and three radio buttons 604, 606, 608. The text box 602 enables a user to enter a blocked phone number. The device application 120 may comprise logic that prevents a user from entering anything other than the appropriate number of digits. In some cases, the device application 120 may provide a template phone number entry per international standards. The radio buttons 604, 606, 608 enable a user to select from options titled 1) "Flick Now", which causes an SMS message to be proactively sent to the device associated with the blocked number, advising an external party using the device that their number has been blocked; 2) "Flick Future", which causes an SMS message to be reactivety sent to the device associated with the blocked number, thereby advising an external party of the block only if the external party attempts to communicate with the device 102 for which the number was blocked; and 3) "Never Flick", which causes the device application 120 to block communications from a device associated with the blocked phone number, without ever advising the external party that the block is in place. In some embodiments, the "Flick Now^* radio button may be identified as a default option.

[0070] Upon exit from the screen 600 shown in FIG. 6, a user may be prompted with the screen 700 shown in FIG. 7, which screen provides the user with options to "Save" 702, "Cancer 704 or "Block Unknowns" 706. The Block Unknowns option further provides options to block "Unknown Numbers^* 708, "Private Numbers" 710 and "Phone numbers <> xx digits" 712, where xx is determined per international standards and is "10" for domestic calls originated and terminated within the United States. The latter test is applied after stripping off any leading " of a party's phone number. In some cases, the "Block Unknowns" options 706 may be further augmented with, for example, options to block foreign numbers, numbers by country code, or numbers by area code (including, for example, numbers from area codes commonly used by adult entertainment venues). An option to reach the screen 700 shown in FIG. 7 may also be provided by the menu screen 502 shown in FIG. 5.

[0071] FIG. 8 illustrates a screen 800 of the Ul 500 for removing a phone number from a blocked phone number list. The screen 800 provides a scrollable window 802 from which a user can click on a blocked phone number to remove it from the list of blocked phone numbers.

[0072] The "Properties" selection 508 of the menu shown in FIG. 5 can lead to a screen that displays miscellaneous information such as "Name of product", "Company name", "Phone number* and "Website Address" for the device application 120 and its provider.

[007?] The device application 120 and cloud server 122 may

communicate with each other when a phone number is added or removed to or from a list of blocked phone numbers. Such communications may comprise a message in which a blocked phone number is associated with a key/value pair of "ΒΤ= and an unblocked phone number is associated with a key/value pair of ^*BT=0\ See, Table 1 , supra. A message indicating whether a phone number has been blocked or unblocked may also comprise an indication of the date/time, as well as an indication of the Flick Type (e.g., FT « 0*Never Flick; 1*Flick Now; 2=Flick Future). Messages indicating whether a phone number is blocked or unblocked should be sent

independently of any POST request to determine whether a particular call or message is "blocked" or "allowed^*.

[0074] A POST request for requesting whether a call or message is blocked can use the key/value pairs disclosed in Table 1 , and can be formatted the same as a POST request for copying data pertaining to a call or message to the server, as shown below: http:/ www.kidphoneadvocate_^

=3.0.1&T=0&D=090801143204&Z=6&BT=1&FT=1

[0075] Having described the device application 120 in detail, the cloud server 122 will now be described in greater detail. The primary design considerations for the cloud server 122 center around the dynamics of communication between multiple telecommunications devices 102 and a web service 216 (e.g., a web service 216 that provides services to the

telecommunications devices 102 over a public or private network, such as the Internet). The devices 102 will communicate frequently with the cloud server 122, and the round-trip time for message receipt, analysis, and response is a key performance barometer. Secondary design considerations include simplicity of use for parents or others that need to view data or change settings via a web page of the web service 216; storage considerations due to the large quantity and frequency of data points to be stored; and security for the data once stored.

[007m In some embodiments, the cloud server 122 and web service 216 may be based on Microsoft standard software products and practices using 64-bit architectures. These products may include Microsoft Windows Server 2008 R2, and Microsoft SQL Server 2008 R2 [0077] Exemplary communication flows 900, 1000 between the cloud server 122 and one particular device application 120 are shown in FIGS. 9 & 10. These application flows 900, 1000 were previously described from the viewpoint of the device application 120, but are described here from the viewpoint of the cloud server 122.

[0078] In FIG. 9, the device application 120 gathers data pertaining to a call or message 902 from the device 102, and then sends this data 904 to the cloud server 122 in an HTTP message. The cloud server 122 stores the data in a database 212, makes decisions about actions based on the call or message data, and then sends a control response to the device application 120. The device application 120 then either allows or blocks the attempted action (at block 906)

[0079] In FIG. 10, the device application 120 obtains (e.g., polls) GPS resources on a device 102 to obtain GPS Data 1002. The device application 120 then transmits location and speed information 1004 to the cloud server 122 in an HTTP message. The cloud server 122 stores the information in the database 212.

[0080] Although FIGS. 1 , 2, 9 & 10 each illustrate a cloud server's interaction with a single telecommunications device 102, it is noted that the cloud server would typically be in communication with a plurality of such telecommunications devices 102.

[0081] FIG. 11 illustrates a plurality of modules that may be implemented by the web service 216 installed on the cloud server 122. More particularly, the modules may be implemented by a processor of the cloud server 122 that has been configured by the web service 216. The modules include a message processing module 1100, a call processing module 1102, a location processing module 1104, an alert module 1106, a control flow module 1108, and an account interface and management module 1110.

[0082] FIG. 12 illustrates a Message/Call Decision process 1200 that may, for example, be executed by the message processing or call processing modules 1100, 1102 of the web service 216. The process 1200 is an integral part of a number of the information flows and use cases for the systems shown in FIGS. 1, 2 & 9. The decision process 1200 begins with an SMS port wait wakeup 1202 and the receipt (at block 1204) of a message that triggers a determination of whether a call or message is "allowed" or

"blocked". The process 1200 first pulls data (at block 1206) about the account for which a request is being made. The data may be pulled from an account database 1208. The data may include a list of active device application modules or services for the account, as well as lists of blocked (blacklisted) and whitelisted phone numbers. Then, based on the settings of the account, together with an analysis of the message itself, the web service 216 makes a determination regarding whether to block or allow the attempt to send, place or receive a call or message (at "Message OK?" block 1210). The web service 216 may make this determination by 1 ) parsing the data pertaining to a call or message, 2) comparing a phone number of an external party involved in the call to blocked phone numbers in a blacklist and/or whitelist, 3) determining whether content of the message contains particular words or characters (e.g., Watchwords), and/or 4) determining whether content of the message contains particular phrases (e.g., Lingo Phrases). Calls or messages involving blacklisted phone numbers are blocked, whereas calls or messages involving whitelisted phone numbers are allowed. Calls and messages involving either blacklisted or whitelisted phone numbers may also be flagged and used as triggers for the alert module 1106. Calls containing Watchwords or Lingo Phrases may be blocked, allowed or flagged for the alert module 1106, depending on rules associated with particular words, characters or phrases, or depending on rules associated with a Watchwords list or Lingo Phrases list "as a whole".

[0083] The decision to block or allow a call or message is communicated to the device application that generated the corresponding call or message request. The decision may an allowance or approval of the call or message (at block 1214) or a block or disapproval of the call or message (at block 1218). Regardless of the decision, received data pertaining to the call or message is logged to the database server 212 at block 1212 or 1216. it is noted that the timing of the call or message data logging is not critical and can be performed in parallel, before or after various of the process steps shown in FIG. 12.

[0084] In some embodiments, the Message Call Decision process 1200 shown in FIG. 12 may be implemented as a number of parallel sub- processes, where an initial decision is made as to whether a received request relates to an inbound or outbound call or message, and one of a number of similar sub-processes is executed by the web service, depending on whether the received request relates to a call or a message, or whether the received request relates to an inbound or outbound call or message. Also, it is noted that it may be necessary to move the decision making process for call blocking to the device application 120, so that a decision on whether to block or allow the call can be made fast enough that the call can be terminated (if necessary). In this case, the call processing module 1102 may only attend to call data logging.

[0085] In cases where a device owner has not subscribed for call or message blocking, the process shown in FIG. 12 determines this from the account data that it pulls and may then default to the "allow* (i.e., "Send Approval" 1214) flow. However, if a device owner has not subscribed for call or message blocking, a device application may in some cases be configured to allow calls and messages prior to the receipt of any decision from the web service 216 that implements the FIG. 12 process 1200.

[0088] In some cases, the Message/Call Decision process 1200 may retrieve one or more lists of Watchwords or Lingo Phrases for a device.

These lists may be retrieved from the account database 1208. Watchwords are words or characters that the web service 216 watches for in the subject or body of a message. Lingo Phrases are phrases that the web service 216 watches for in the subject or body of a message. Default lists of Watch Words and Lingo Phrases will sometimes be maintained by the web service 216. A device owner may sometimes supplement these default lists with additional Watchwords or Lingo Phrases, or may provide their own lists of Watchwords and Lingo Phrases. In either case, the Message/Call Decision process 1200 can parse a message to determine the presence of any Watchwords or Lingo Phrases (at block 1210), and can then block the message based on the presence of any Watch Words or Lingo Phrases in the message, or based on the presence of particular ones of the Watchwords or Lingo Phrases in the message.

[0087] FIG. 13 illustrates a Location Monitoring process 1300 that may, for example, be executed by the location processing module 1104 of the web service 216. As the location and speed of movement of a

telecommunications device 102 change throughout the day, the device application 120 installed on the device 102 sends location and speed information to the web service 216. The location and speed information is received by the web service 216 in the form of HTTP POST request messages (at block 1304) following a locality port wait wakeup (at block 1302). Account data is then pulled (at block 1306) from the account database 1308. The account data may indicate, for example, when alerts should be generated based on the location and speed information. The information is then stored (or recorded) at block 1310. The information may first be stored in a real-time location/speed information cache 1312, and may then be moved to a location/speed information archive 1314. In this manner, real-time maps and alerts can be updated based on the information stored in the real-time location speed information cache 1312, and requests for historical information can be pulled from a less real-time system (and not impact the speed with which new information can be written to the real-time location speed cache). Alternately, the real-time location speed information cache 1312 can be used solely for the purpose of receiving location and speed information from devices, and any alerts and maps can be generated based on information stored in the location speed information archive 1314. A background process may be executed to move the location and speed information from the real-time information cache 1312 to the information archive 1314 at regular intervals.

[0088] The web service 216 may provide a Ul via which a user may request a map (at block 1316). Need information is then pulled from the archive 1314 and used to draw a map at block 1318. Requests for historical location and speed information can be filtered based on information such as time/date, location and speed.

[0089] The web service 216 may also comprise an Alerting process that may, for example, be executed by the alert module 1106 (FIG. 11). The Alerting process can provide alerts based on a number of triggering events, such as: 1 ) removal or non-responsiveness of a device application 120, 2) the absence of requests from a device application 120 for a particular period of time, 3) the identification of Watchwords or Lingo Phrases in a message processed by the message processing module 1100, 4) a message or call being sent, placed or received to from a blacklisted or whitelisted phone number, or 5) a device's speed of movement exceeding a threshold. By way of example, the alert module 1106 may send alerts in the form of emails (via SMTP) or SMS messages. Alerts may also be saved in, or compiled from, the database server 212, and then displayed in one or more lists via a web page. Alerts are typically sent to or saved for a device owner in accord with alerting preferences that have been specified by the device owner. However, in some cases, alerts may be compiled for review by an administrator of the web service 216 or its alert module 1106.

[0090] In addition to sending a device application messages regarding the blocking or allowance of certain calls and messages, the web service 216 may also send control requests and messages to a device application 120. These control requests and messages may be provided by the control flow module 1108 of the web service 216. The control requests may include, for example, requests to update or upgrade a device application 120 with a new version, requests to uninstall a device application 120, or requests to update settings in the on-device configuration file for a device application 120

(including requests to activate or deactivate a module or service thereof). To implement these and other control requests, a device 102 may be sent a port directed SMS message which will cause the device 102 to make a request back to the cloud server 122 for a control message. The server request can be an HTTP request to a specific endpoint, in which the response will be a set of URL form encoded key/value pairs.

[0091] The request inbound to the cloud server 122 needs to identify the account requesting the update. In some cases, the account identifier can be the phone number of the device, and can be sent in a GET or POST format using ones of the key/value pairs disclosed in Table 1. When received at the cloud server 122, the account identifier can be used to determine the type or model of telecommunications device 102 at issue, as well as the most current version of device application 120 that is available for the device 102. in addition, the GET or POST request can provide the version of the currently installed device application 120. The current version information can then be used to insure that any configuration updates are valid for the installed version of the device application 120, or that a version of device application 120 to be downloaded is newer than the currently installed version. The following is an example of the inbound to server URL as a GET-type request: htto:/ kidphoneadvocate.com/posLupd.aspx?A~2145552121 &V=1.0.1

[0092] The response should contain the information needing to be updated, and may use the following keys for the desired information. Only those keys needing to be updated should be returned.

[0093] Expected information returned from the web service 216, to an update request, might look as follows. When the base URL is changed, and the phone activity is being deactivated, but the device application is not being completely disabled: active^&urt=http:/ kpa.com

[0094] Or when the device application is being completely disabled: active=f&listen=false

[0095] In some cases, the information returned from the web service 216 can be a URL from which the device application 120 can download a newer version of, or updates to, the device application 120. The newer version or updates are then downloaded, and are launched or installed by the device application 120. This can be done in a stealth mode, where a device user is unaware of the install, or in a prompt mode, where the device user is prompted to proceed with the download or install.

[009β] The account interface and management module 1110 provides a Ul via which account owners can login and 1 ) view information related to monitored telecommunications devices 102, and 2) subscribe, unsubscribe, or change settings or information for their account.

[0097] In one embodiment of the Ul provided by the module 1110, a user is shown a dashboard 1402 upon logging in to view and manage their account. See, FIG. 14. The intent of the dashboard 1402 is to give a view of the main areas of information that can be accessed via the Ul 1400. Each main area may have a box or section to display the most recent events relative to that area. The main areas shown in FIG. 14 are labeled: TextPal 1404 (showing most recently logged and blocked message activity), CallPal 1406 (showing most recently logged and blocked call activity), ImagePal 1408 (showing most recently logged and blocked images, such as images sent and received as MS messages), AlertPaJ 1410 (highlighting most recently flagged alerts), and LocatePal 1412 (showing a recent location or locations, and in some cases speed(s) of movement of a monitored device, preferably on a map). Blocked calls, messages or images may be flagged by a red "X" 1414, 1416 near the data displayed for a call, message or image.

[0098] Each element heading in the dashboard is preferably clickable, and takes a user to the appropriate search/view page for that element For example, clicking on TextPal within the dashboard 1402 takes the user to the TextPal page of the Ul 1400. If an account owner has subscribed to monitor activity for more than one phone, the Ul 1400 can provide a mechanism 1418 (e.g., a pull-down menu) for toggling between information for different monitored devices. The Ul 1400 also provides text fields 1420, 1422 for selecting or inputting "from" and "to" dates. These dates can be used to filter or focus the dashboard contents on a particular date range.

[0099] The Ul screen shown in FIG. 14 also provides a mem tree 1424 from which a user can select the elements represented by the main areas of the dashboard 1402, or other elements, such as account management functions (ManagePai) or Support.

[00100] Selecting either of the TextPal headings displayed in the FIG. 14 Ul screen navigates the Ul 1400 to the TextPal screen 1500 shown in FIG. 15. The screen 1500 provides a more extensive listing of logged and blocked message activity, and removes other main areas included in the dashboard 1402 shown in FIG. 14. The screen 1500 also adds buttons 1502, 1504 for filtering displayed message activity to "Inbound" or "Outbound" activity.

Optionally (not shown), the Ul screen 1500 may display or provide access to a dictionary of words, characters, phrases and/or abbreviations that are commonly used in messages. Alternately, the account interface and management module 1110 may map words, characters, phrases and or abbreviations in a message to their definitions, and then 1) replace words, characters, phrases and or abbreviations in a message with their definitions, or 2) display the definitions when a user graphically hovers over or clicks on the words, characters, phrases and/or abbreviations. For example, the dictionary might indicate that ROTFL means "rolling on the floor laughing".

[00101] Selecting either of the CallPal headings displayed in the FIG. 14 Ul screen navigates the Ul 1400 to the CallPal screen 1600 shown in FIG. 16. The screen 1600 provides a more extensive listing of logged and blocked call activity, and removes other main areas included in the dashboard 1402 shown in FIG. 14. The screen 1600 also adds buttons for filtering displayed call activity to "Inbound'' or "Outbound" activity.

[00102] Selecting either of the ImagePaJ headings displayed in the FIG. 14 Ul screen navigates the Ul 1400 to the ImagePal screen 1700 shown in FIG. 17. The screen 1700 provides a more extensive listing of logged and blocked image activity, and removes other main areas included in the dashboard 1402 shown in FIG. 14.

[00103] Selecting either of the LocatePal headings displayed in the FIG. 14 Ul screen navigates the Ul 1400 to the LocatePal screen 1800 shown in FIG. 18. The screen 1800 provides a larger and more interactive map 1802 on which device locations and speeds of device movement may be plotted. Upon hovering over a mapped device location using a graphical pointer, additional details concerning the location and speed information associated with the mapped device location may be displayed. The map 1802 may also comprise a mechanism to navigate within the map, which mechanism may take the form of graphically-selectable pan and zoom elements 1804, 1806.

[00104] Selecting one of the options under ManagePai enables a user to 1 ) add, update or remove monitored telecommunications devices to or from an account, 2) edit a Watchwords list, 3) edit a Lingo Phrases list, or 4) manage other account features (e.g., via the My Account option).

[00105] FIG. 19 provides a block diagram of an exemplary computer system 1900, which computer system 1900 may provide the hardware, software and functionality for implementing the cloud server and its modules. The computer system 1900 generally represents any single or multiprocessor computing device that is capable of executing single-threaded or multi-threaded applications. The computer system 1900 may include a communication infrastructure 1902 that interconnects the major subsystems of the computer system 1900. The communication infrastructure 1902 generally represents any form or structure that is capable of facilitating communication between one or more electronic components; including, for example, a communication bus (e.g., ISA, PCI, PCI-E, AGP, etc.) or a network.

[00108] As illustrated in FIG. 19, the exemplary computer system 1900 may comprise a processor 1904, a system memory 1906, an Input Output (I O) controller 1908, a communication interface 1910, and a memory interface 1912. The processor 1904 generally represents any type or form of CPU or other computing device that is capable of executing instructions and processing data. The instructions provided to the processor 1904 may cause the processor 1904 to implement the modules illustrated in FIG. 11. The instructions provided to the processor 1904 may be instructions from a software application or module, and the methods and systems disclosed herein may be implemented as instructions in one or more of the software applications or modules. The processor 1904 may execute, or assist in executing, various of the methods described herein. For example, the processor 1904 may execute, and/or be a means for executing, either alone or in combination with other elements, one or more of the actions, functions or methods performed by the modules illustrated in FIG. 11. The processor 1904 may also perform and or be a means for performing various other steps or processes described and/or illustrated herein, as well as other steps or processes.

[00107] The system memory 1906 generally represents any type or form of storage device or non-transitory computer-readable medium capable of storing data and/or other computer-readable instructions. Examples of system memory 1906 include, without limitation, a random access memory (RAM) unit, a read only memory (ROM) unit, a flash RAM unit, or any other suitable memory device. In certain embodiments, the system memory 1906 may be used, for example, to store data.

[00108] The I O controller 1908 generally represents any type or form of computer board or module that is capable of coordinating and or controlling the input and output functions of a computing device. The I O controller 1906 may be used, for example, to perform and/or be a means for performing, either alone or in combination with other elements, one or more of the actions or functions performed by the modules illustrated in FIG. 1. The I O controller 1908 may also be used to perform and/or be a means for performing other steps and processes set forth herein, as well as other steps or processes.

[00109] The communication interface 1910 generally represents a communication device capable of facilitating communication between the exemplary computer system 1900 and an additional device or devices. For example, in certain embodiments, the communication interface 1910 may interconnect the computer system 1900 with the Internet, an SMS gateway, an MMSC, or other private or public networks comprising additional computer systems or devices. Examples of the communication interface 1910 include, without limitation, a network interface (such as a network interface card), a wireless card, a modem, a communications port (such as a USB or Firewire port), and any other suitable interface. In at least one embodiment, the communication interface 1910 may provide a network connection through, for example, an Internet connection, an Ethernet connection, a modem, a digital cellular telephone connection, a BLUETOOTH network, an IEEE 802.11x wireless network, a digital satellite data connection, or any other suitable connection.

[00110] The communication interface 1910 may allow the computer system 1900 to engage in distributed or remote computing. For example, the communication interface 1910 may send or receive instructions to from a remote computer, database server, or back-end server. Accordingly, the communication interface 1910 may perform and/or be a means for

performing, either alone or in combination with other elements, one or more of the actions or functions of the methods or modules described herein. The communication interface 1910 may also be used to perform and/or be a means for performing other steps and processes set forth herein, as well as other steps or processes.

[00111] The memory interface 1912 generally represents any type or form of device that is capable of allowing software and data to be transferred between a storage device and other components of the computer system 1900. For example, memory interface 1912 may comprise a cartridge interface, a memory socket, or a disk drive. Memory interface 1912 may also be a floppy drive, an optical disk drive, a flash interface, or any other type of memory interface. In certain embodiments, the memory interface may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the actions or functions performed by the methods or modules described herein. The memory interface 1912 may also be used to perform and/or be a means for performing other steps and processes described and/or illustrated herein, as well as other steps or processes.

[00112] As illustrated in FIG. 19, the computer system 1900 may also comprise a display device 1914 that is coupled to the communication infrastructure 1902 via a display adapter 1916. The display device 1914 generally represents any type or form of device that is capable of visually displaying information forwarded by the display adapter 1916. Similarly, the display adapter 1916 generally represents any type or form of device that is configured to forward graphics, text, and other data from communication infrastructure 1902 (or from a frame buffer, as known in the art) for display on the display device 1914. Examples of the display device 1914 include, without limitation, CRT monitors, LCD screens, plasma screens, video projectors, and the like.

[00113] As illustrated in FIG. 19, exemplary computer system 1900 may also comprise at least one input device 1918 coupled to communication infrastructure 1902 via an input interface 1920. Input device 1918 generally represents any type or form of user input device capable of providing input, either computer or human generated, to exemplary computer system 1900. Examples of input device 1918 include, without limitation, a keyboard, a pointing device, a speech recognition device, or any other input device.

[001141 As illustrated in FIG. 19, the exemplary computer system 1900 may also comprise a storage device 1922 that is coupled to the

communication infrastructure 1902 via a storage interface 1924. The storage device 1922 generally represents any type or form of storage device or medium that is capable of storing data and/or other computer-readable instructions. For example, the storage device 1922 may be a magnetic disk drive (e.g., a hard drive), a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash drive, or the like. In certain embodiments, the storage device 1922 may be configured to read from and/or write to a removable storage unit that is configured to store computer software, data, or other computer-readable information. Examples of suitable removable storage units include, without limitation, a floppy disk, a magnetic tape, an optical disk, a flash memory device, or the like. The storage device 1922 may also comprise other similar structures or devices for allowing computer software, data, or other computer-readable instructions to be loaded into the computer system 1900. For example, the storage device 1922 may be configured to read and write software, data, or other computer-readable information. The storage device 1922 may also be a part of the computer system 1900 or may be a separate device, such as a database server, that is accessed through other interface systems.

[00115] In certain embodiments, the computer system 1900 may be any kind of computing device, including a server, a blade farm or a network appliance. The computer system 1900 may also be any type of device that is configured to execute the functions and modules described and/or illustrated herein. The operating system provided on computer system 1900 may be WINDOWS, UNIX, Linux, or any other operating system or platform. The computer system 1900 may also support a number of Internet access tools; including, for example, an HTTP-compliant web browser having a JavaScript interpreter, such as Netscape Navigator, Microsoft Internet Explorer, or other similar navigators.

[0011$] Many other devices or subsystems may be connected to the computer system 1900. Conversely, all of the devices shown in FIG. 19 need not be present to practice the embodiments of the invention described and/or illustrated herein. The devices and subsystems referenced above may also be interconnected in different ways from that shown in FIG. 19. Indeed, the computer system 1900 may assume any number of software, firmware, and/or hardware configurations. For example, one or more of the functions or subcomponents disclosed herein may be encoded as a computer program (also referred to as computer software, software applications, computer- readable instructions, or computer control logic) and stored in a computer- readable medium. The computer-readable medium containing the computer program may then be loaded into the computer system 1900 using a removable storage drive, or downloaded to the computer system 1900 via the communication interface 1910 over a communication path, such as the Internet or other network. Ail or a portion of the computer program stored on the computer-readable medium may then be stored in system memory 1906 and/or various portions of the storage device 1922. According to certain embodiments, a computer readable medium may be an optical storage device, a magnetic storage device, or any other physical storage device capable of storing computer readable instructions. When executed by the processor 1904, a computer program loaded into the computer system 1900 may cause the processor 1904 to perform and/or be a means for performing the actions or functions of the methods or modules described herein.

Additionally or alternatively, one or more of the exemplary embodiments described and/or illustrated herein may be implemented in firmware and/or hardware.

[00117] The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary systems, methods and apparatus described herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. It is desired that the embodiments described herein be considered in all respects illustrative, and not restrictive, and that reference be made to the appended claims and their equivalents for determining the scope of the instant disclosure.

[00118] While the foregoing disclosure sets forth various embodiments using specific block diagrams, flowcharts, and examples, each block diagram component, flowchart step, operation and/or component described and/or illustrated herein may be implemented, individually and/or collectively, using a wide range of hardware, software, or firmware (or any combination thereof) implementations.

[00119] The foregoing disclosure also describes embodiments including components contained within other components. Such architectures are merely examples, and many other architectures can be implemented to achieve the same functionality. For example, one or more of the components or modules described and/or illustrated herein may be combined into a single component or module and/or separated into a plurality of components or modules. Similarly, the process parameters and sequences of steps described and or illustrated herein are given by way of example only and can be varied as desired. For example, while the steps illustrated and/or discussed herein may be shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed, unless otherwise indicated. In addition, the various exemplary methods described and or illustrated herein may omit one or more of the steps described or illustrated herein or include additional steps in addition to those described or illustrated.

[00120] In addition, one or more of the embodiments described and/or illustrated herein may be implemented using software modules and scripts that perform certain tasks. The software modules and scripts discussed herein may include script, batch, or other executable files. In addition, these software modules and scripts may be stored on a machine-readable or computer-readable storage medium, such as a disk drive. In some embodiments, the modules and scripts can be stored within a computer system memory to configure the computer system to perform the functions of the modules, and to assume particular physical states that lead to the functions being performed.

[00121] Unless otherwise noted, the terms "a" or "an," as used in the specification and claims, are to be construed as meaning "at least one of." In addition, for ease of use, the words "including" and "having," as used in the specification and claims, are interchangeable with and have the same meaning as the word "comprising."

Claims

WHAT IS CLAIMED IS: 1. A telecommunications device, comprising:

a first telecommunications interface operable in accord with a message protocol;

a second telecommunications interface operable in accord with a data protocol;

a physical data store, in message sending and receiving

communication with the first telecommunications interface, the physical data store providing a message inbox and a message outbox; and

a processor in communication with the message inbox, the message outbox and the second telecommunications interface, the processor configured by a device application to monitor storage of new messages in the message inbox and the message outbox and transmit data pertaining to the new messages via the second telecommunications interface, the data including message content.

2. The telecommunications device of claim 1 , further comprising a data cache, wherein the processor is configured by the device application to i) copy the new messages stored in the message inbox and the message outbox to the data cache, ii) delete the new messages from the message inbox and the message outbox, preventing the new messages from being viewed on the telecommunications device or transmitted from the

telecommunications device, iii) determine whether each of the new messages is allowed or blocked, and iv) copy each new message that is allowed from the data cache to one of the message inbox and the message outbox.

3. The telecommunications device of claim 2, wherein the processor determines whether a particular new message is allowed or blocked by receiving an allow or block decision in response to its transmission of data pertaining to the particular new message via the second telecommunications interface.

4. The telecommunications device of claim 1 , further comprising a third telecommunications interface operable in accord with a telephony protocol, wherein:

the physical data store is in call logging communication with the third telecommunications interface; and

the processor is further configured by the device application to monitor storage of new call data in the physical data store and transmit the new call data via the second telecommunications interface.

5. The telecommunications device of claim 4, wherein the processor is configured by the device application to i) determine whether each new call is allowed or blocked, and ii) terminate each new call that is determined to be blocked.

6. The telecommunications device of claim 5, wherein the processor determines whether a particular new call is blocked by comparing a phone number of an external party involved in the call to blocked phone numbers in a list of blocked phone numbers.

7. The telecommunications device of claim 1 , wherein the processor transmits data pertaining to the new messages in POST requests comprising key/value pairs.

8. The telecommunications device of claim 1 , wherein the processor is configured by the device application to analyze the new messages stored in the message inbox for control messages, and to configure the device application in response to the control messages.

9. The telecommunications device of claim 1 , further comprising GPS resources, wherein the processor is further configured by the device application to collect and report device location and speed of movement information via the second telecommunications interface.

10. A system for monitoring telecommunications activity, the system comprising:

a cloud server having an installed web service;

a plurality of device applications, each installed on a respective telecommunications device and configuring a processor of the respective telecommunications device to i) monitor storage of new messages in a message inbox and a message outbox of the respective telecommunications device, and ii) transmit data pertaining to new messages to the cloud server.

11. The system of claim 10, wherein the cloud server comprises an HTML POST receiver that receives the transmitted data pertaining to the new messages, and wherein the web service transmits control messages to the device applications using a message protocol.

12. The system of claim 10, wherein the cloud server comprises a processor, configured by the web service, to i) parse the data pertaining to the new messages, ii) determine whether each new message is allowed or blocked, and iii) communicate each determination to a particular one of the device applications.

13. The system of claim 12, wherein the processor determines whether a particular new message is blocked by comparing a phone number of an external party involved in the call to blocked phone numbers in a list of blocked phone numbers.

14. The system of claim 12, wherein the processor determines whether a particular new message is blocked by parsing message content of the particular new message to determine whether particular words or characters are present in the message content.

15. The system of claim 12, wherein the processor determines whether a particular new message is blocked by parsing message content of the particular new message to determine whether particular phrases are present in the message content.

16. The system of claim 10, wherein:

the processor of at least one of the telecommunications devices is configured by a respective one of the device applications to collect and report device location and speed of movement information via the second

telecommunications interface of the telecommunications device; and

the cloud server comprises a processor, configured by the web service, to display the received device location and speed of movement information on a map.

17. A method of operating a telecommunications device, comprising:

operating a first telecommunications interface of the

telecommunications device in accord with a message protocol;

operating a second telecommunications interface of the

telecommunications device in accord with a data protocol;

physically saving inbound messages received at the first

telecommunications interface in a message inbox of the telecommunications device, and physically saving outbound messages to be sent via the first telecommunications interface in a message outbox of the

telecommunications device; and

using a processor of the telecommunications device, the processor configured by a device application and being in communication with the message inbox, the message outbox and the second telecommunications interface, i) monitoring storage of new messages in the message inbox and the message outbox, and ii) transmitting data pertaining to the new

messages via the second telecommunications interface, the data including message content.

18. The method of claim 17, further comprising:

using the processor to i) copy the new messages stored in the message inbox and the message outbox to a data cache, ii) delete the new messages from the message inbox and the message outbox, preventing the new messages from being viewed on the telecommunications device or transmitted from the telecommunications device, iii) determine whether each of the new messages is allowed or blocked, and iv) copy each new message that is allowed from the data cache to one of the message inbox and the message outbox.

19. The method of claim 18, wherein the processor determines whether a particular new message is allowed or blocked by receiving an allow or block decision in response to its transmission of data pertaining to the particular new message via the second telecommunications interface.

20. The method of claim 17, further comprising:

operating a third telecommunications interface in accord with a telephony protocol;

logging call data for calls that are placed or received via the third telecommunications interface; and

using the processor to monitor logging of new call data in the physical data store and transmit the new call data via the second telecommunications interface.

21. The method of claim 20, further comprising:

using the processor to i) determine whether each new call is allowed or blocked, and ii) terminate each new call that is determined to be blocked.

22. The method of claim 21 , wherein the processor determines whether a particular new call is blocked by comparing a phone number of an external party involved in the call to blocked phone numbers in a list of blocked phone numbers.

23. The method of claim 17, wherein the processor transmits data pertaining to the new messages in POST requests comprising key/value pairs.

24. The method of claim 17, further comprising:

using the processor to analyze the new messages stored in the message inbox for control messages, and to configure the device application in response to the control messages.

25. A method for monitoring telecommunications activity, the method comprising:

operating a web service installed on a cloud server;

operating a plurality of device applications, each installed on a respective telecommunications device and configuring a processor of the respective telecommunications device to i) monitor storage of new messages in a message inbox and a message outbox of the respective

telecommunications device, and ii) transmit data pertaining to new messages to the cloud server.

26. The method of claim 25, wherein the cloud server receives the transmitted data pertaining to the new messages via an HTML POST receiver, and wherein the web service transmits control messages to the device applications using a message protocol.

27. The method of claim 25, further comprising: using the web service to configure a processor of the cloud server to i) parse the data pertaining to the new messages, ii) determine whether each new message is allowed or blocked, and iii) communicate each determination to a particular one of the device applications.

28. The method of claim 27, wherein the processor determines whether a particular new message is blocked by comparing a phone number of an external party involved in the call to blocked phone numbers in a list of blocked phone numbers.

29. The method of claim 27, wherein the processor determines whether a particular new message is blocked by parsing message content of the particular new message to determine whether particular words or characters are present in the message content

30. The method of claim 27, wherein the processor determines whether a particular new message is blocked by parsing message content of the particular new message to determine whether particular phrases are present in the message content.