US20090017790A1

US20090017790A1 - Systems and methods for restricting service in mobile devices

Info

Publication number: US20090017790A1
Application number: US12/029,793
Authority: US
Inventors: Guru Thalapaneni; Srinivas Naidu Doddapaneni
Original assignee: Remoba Inc
Current assignee: Remoba Inc
Priority date: 2007-02-12
Filing date: 2008-02-12
Publication date: 2009-01-15
Also published as: WO2008100543A1; WO2008100543A8; WO2008100542A1; US20090029676A1; US8369832B2

Abstract

Systems and methods are described that enable remote restriction of workforce mobile phones, media players, computers and other devices. In particular, systems, apparatus and methods are described that deny or allow connections involving the mobile device based on the content of a preauthorized contact list provided by a business administrator. The connection may be any combination of incoming connection, outgoing connection, voice connection, data connection. The list of preauthorized contacts maybe updated upon receipt of a synchronization command from a business administrator. Access to the list of contacts can be blocked upon receiving a lockdown command from the business administrator. The list of contacts can be destroyed upon receiving a poison pill command from the business administrator. A client is described for controlling use of the mobile device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This Application claims priority from U.S. Provisional Patent Application Ser. No. 60/901,830, Filed Feb. 12, 2007, titled “Mobile Phone Information System,” and from U.S. Provisional Patent Application Ser. No. 60/901,832, Filed Feb. 12, 2007, titled “Mobile Phone Voice and Data Restriction System,” which applications are hereby incorporated by reference herein for all purposes. This application is also related to the concurrently filed U.S. Non-Provisional Application titled “Systems and Methods For Managing Information In Mobile Devices,” which application is hereby incorporated by reference herein for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present invention relates generally to mobile devices and more generally to wireless management of content of mobile devices.
2. Description of Related Art
Businesses, Enterprises, Government agencies, or Organizations provide mobile phones to their employees for improving their internal communications and productivity. It is a real challenge to keep all the employee phones up-to-date with the most current and accurate information such as Contacts, Tasks, Appointments, Notes, Group Lists, Email Accounts, Setup Conditions & Privileges, Restrictions to Voice Calls & Data Usage, etc. Whenever, the information changes as it happens all the time, it does not get transmitted to all the employees unless they physically bring the phones to the office for uploading the information to the phone by IT Manager or authorized Administrator. Practically, it is impossible to keep every employee's phone up-to-date. It creates inefficiency, and chaos in communicating with each other due to erroneous information and the real purpose of productivity gain is lost.
Furthermore, businesses and government agencies often provide mobile phones to many employees to improve internal communications and productivity. However, it is difficult to prevent abuse of the phone privilege and employees frequently make very long non-business related calls and download large files of data such as pictures, audio, video. Consequently, businesses may be surprised by large telephone bills which had not been budgeted.

BRIEF SUMMARY OF THE INVENTION

Certain embodiments of the present invention comprise systems and methods for enabling remote restriction of workforce mobile phones, media players, computers and other devices. Certain embodiments of the invention provide systems, apparatus and methods for restricting a mobile device comprising receiving a request for connection of the mobile device, determining if the request is for connection with a preauthorized contact, establishing the connection if the request relates to a preauthorized contact, and denying the connection if the request does not relate to a preauthorized contact, wherein the determining is performed using a list of contacts provided by a business administrator. The request may be a request related to an incoming connection, an outgoing connection, a voice connection, data connection or any combination of connections. The list of contacts maybe updated upon receipt of a synchronization command from a business administrator. Access to the list of contacts can be blocked upon receiving a lockdown command from the business administrator. The list of contacts can be destroyed upon receiving a poison pill command from the business administrator.
In certain embodiments restriction of mobile device usage is facilitated using a client that can process commands received from a system controller. The commands may include a synchronization command, a lockdown command and a poison pill command.
Certain embodiments of the invention may be embodied in a medium that stores instructions executable by one or more processing devices to perform the described methods.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic showing certain features of one embodiment of the invention;

FIG. 2 is a block diagram of a client provided to mobile devices in certain embodiments of the invention;

FIG. 3 is a flowchart illustrating certain administrative operations in one embodiment of the invention; and

FIG. 4 is a flowchart illustrating certain aspects of mobile device operation.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention to a single embodiment, but other embodiments are possible by way of interchange of some or all of the described or illustrated elements. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to same or like parts. Where certain elements of these embodiments can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. In the present specification, an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present invention encompasses present and future known equivalents to the components referred to herein by way of illustration.
Certain embodiments of the invention provide systems, methods that enable businesses to better manage employee mobile phones and content of mobile communication devices. Many of these systems and methods can be embodied using combinations of computer hardware, firmware and software that operate using communications services, often provided by third party systems. In certain embodiments, systems and methods are provided that interact with, manage and control contact lists, calendar events, tasks, Email accounts notes and other information maintained on a plurality of mobile devices. The mobile communication devices can include cellular telephones, satellite telephones, smart phones, email-enabled telephones PDAs, laptop computers and so on.
With reference to the generalized and simplified embodiment illustrated in FIG. 1 a mobile device 16 and its content may be managed and controlled by one or more system servers 11. Mobile device 16, while depicted as telephonic in nature for the sake of simplicity, can be any wirelessly connectable communications device, including portable computers (e.g. laptops, notebooks, etc.), cellular telephones, satellite telephones, PDAs, Email clients, multimedia players and the like. Mobile device 16 may communicate using any combination of wired and wireless communications including cellular networks, Bluetooth, WiFi, Infrared, satellite, etc. and typically communicates with enterprise servers (e.g. system server 11) through a wireless access point 14 which may also provide network gateway, security, firewall and other services. Server 11 can be provided in any dedicated or shared network resource and can be embodied as a combination of hardware and software resident in a computer, custom device, network switching equipment or any other suitable host.
Typically, an administrator is authorized to manage, update and synchronize contacts, calendar, tasks, and account information associated with, provided by or generated on behalf of an enterprise such as a corporation, partnership, club, government or other association of individuals and organizations. The administrators may further have responsibility for managing one or more groups of users affiliated with the enterprise, a project of the enterprise and/or a product or service provided by the enterprise. The one or more groups of users can include subgroups that are managed independently or separately from other subgroups. The scope of responsibility of an administrator and the number of authorized administrators is typically determined by organizational structure and policies of an enterprise, association or other entity.
In certain embodiments, an account can be created and associated with a group of users in order to define and organize membership of the group and associated subgroups. The account may also identify privileges of individual members or associates of the enterprise and may track services and service levels provided to the group, billing information, contact information and the identity of administrators of the group. An administrator can typically create additional groups or sub-groups as required and can assign membership to members identified in an account. For example, in an account corresponding to a corporation, employees of the corporation can be identified in the corporate account and can be assigned to one or more sub-groups based on a variety of factors including business function, seniority, department corporate division, etc. The administrator may set different privileges and access rights to each member of groups and sub-groups. A history of activities associated with the group may be maintained for the account.
A network 11 connecting the systems servers 10 to workstations 18, 19 and other servers 12 and 14. The network 11 may be based on the internet or other public network, but may equally be based on a private or semi-private network using, for example, dedicated services provided by public carriers. The network 10 is effectively divided at 100 into enterprise 104 and external or user 102 portions. Division 100 is typically a virtual division created using secured communications channels, particularly on the enterprise side 104. Communications channels may be secured using any combination of devices and software including firewalls, encryption or any mechanisms, methods and systems suitable for securing the channels to the degree required for the application and enterprise. Administrative workstations 19 are typically found on the enterprise side 104 of the network 10 while user workstations 18 can be located anywhere in the network contingent on the functions to be performed and security policies of the enterprise.
In certain embodiments, an administrator with sufficient account privileges can create a custom webpage on the one or more system servers 11 for controlling and managing a plurality of mobile devices 16. It will be appreciated that such webpage or its equivalent may be created elsewhere (e.g. workstation 19) and subsequently copied to the system servers 11 as desired. System servers 11 may be maintained by an enterprise but in some embodiments, system servers 11 may be maintained externally or internally to the enterprise network by a third party provider such as Remoba Inc. of Santa Clara, Calif.
In certain embodiments, an account may be associated with a corresponding console, typically customized to the account, that interacts with a plurality of applications resident in a plurality of mobile devices 16. The console typically executes on the one or more central servers 11 to facilitate access to enterprise data and policies, but such collocation is not required and the console function can be spread over several host devices. The degree and manner of interaction between console and mobile device 16 can be configured by the administrator such that the console implements rules and policies associated with the account. Mobile software applications can be wirelessly downloaded to mobile device 16 using a catalogue service and/or from content delivery servers (not explicitly shown). In one example, commercially available applications such as Remoba Inc. products including RemoSync, iPhonebook, iDatebook, and RemoMail can be provided to mobile device 16 and managed by the system server 11.
In certain embodiments, access to enterprise data may be controlled based on group membership. For example, members of a group associated with an accounting department may be permitted access to supplier and customer contact information while a group of managers in a manufacturing division may be permitted access to supplier contact information only. Individuals and/or groups of users may be expressly restricted from accessing certain data and data types. For example it may be necessary to restrict access to personnel records to members of a human resources department or group. Thus shared information may be associated with a set of access rules. Access controlled information may include contact lists, calendar events, tasks, and account information for account members.
Plural administrators can be assigned to manage user groups and corresponding privileges to access shared data. Supervisory administrators or “super” administrators can be designated whereby a super administrator may delegate authorization and control to group administrators. Thus, a hierarchical management structure may be created that typically reflects the organizational structure of the enterprise.
In certain embodiments, changes made to account-related information may be disseminated to group members according to predefined rules and protocols. For example, the predefined rules may mandate immediate or earliest opportunity dissemination of certain high priority information and scheduling exchange of other less-critical information at regular and/or cumulative updates. Changes may be transmitted automatically, according to a predefined schedule and/or by command of an administrator.
In certain embodiments, updates to mobile device 16 are transparent to the user of the device 16. Similarly, information generated by the user or the user device 16 can be synchronized with central repositories of information including system server 11. Synchronization of information and updates of user devices 16 are typically performed between mobile user devices and a central database or repository and an administrator can selectively activate, deactivate and prioritize real-time wireless synchronization 124 of the data to any individual user device 16 or group of devices 16. Thus, the most up-to-date information can be efficiently provided to group members based on organizational priorities.
As discussed above, data synchronization between mobile device 16 and system server 11 may be bi-directional in nature. In certain embodiments, users may enter, modify or delete shared information. The changes made by users may then be replicated on a central server 11 and disseminated to other user devices 16. Typically, a user is permitted to modify, add or delete shared information only if the user has sufficient system privileges for the information to be changed. For example, users or groups of users may be owners of the information with full permission to modify or delete the information. Users or groups of users may be afforded edit privileges with regard to certain data that permits modification or addition of information but not deletion. Certain users may be permitted to read information only, without the ability to modify the information directly. A user having insufficient privilege to change data may submit request to change the data to an administrator or data owner; the request may be in the form of an edited copy of the data.
Various types and operation of access privilege are contemplated based on specific application of the systems and methods described. For example, other classes of access privilege may be provided including a local copy privilege which permits alteration and maintenance of copies of data disseminated by central server. Local copy privilege permits a user to modify data or portions of data for local use but prohibits the propagation of the changes to servers and other users. Furthermore, access privileges may include a time component that sets different access levels for users and groups of users based on time of day, day of week, week of month and so on. Such time-sensitive privilege may also be granted for a fixed period of time and may expire or revert after a predetermined date or time.
In certain embodiments, a user may make entries at a workstation 18 or on the mobile device 16. The user may also cause certain private contact and other information 12 to be synchronized 120 and 124 with the mobile device while synchronizing 110 of enterprise contacts and other data may be limited to one-way synchronization. In this manner, user-private information may be maintained independently of enterprise data and combined only under administrator control.
As mentioned above, where a business entity has multiple departments, each department can be managed by a designated departmental administrator. In certain embodiments, departmental administrators can be controlled by an administrator with additional privilege (e.g. a “Super Administrator” and, where necessary, an administration hierarchy can be implemented as required to properly manage a user base. Administrator privileges typically permit an administrator to perform a range of management and security-oriented functions. Administrators can selectively lock down mobile devices 16 such that the mobile device 16 is incapable of initiating and/or receiving certain voice calls and data transmissions. For example, lockdown may prevent access to a corporate contact list maintained on the wireless device and may further prevent calls to telephone numbers in the contact list. In certain embodiments, calls received at the mobile device 16 from numbers identified in the enterprise contact list may be blocked or redirected to another telephone number or network address during lockdown.
In certain embodiments, administrators can send a “Poison Pill” command to initiate destruction of all information on the mobile device 16. It is contemplated that such command may be sent subsequent to loss or theft of a mobile device 16, resignation or dismissal of an employee or detection or suspicion of misuse of the mobile device 16. In certain embodiments, the administrator may also cause a lockdown command to be sent to a mobile device. The lockdown command may change a user's privilege level thereby preventing the user from accessing shared data and may partially or completely inhibit use of the mobile device 16. In certain embodiments, a standing lockdown command may be in effect at one or more mobile devices 16 whereby access to protected data on the device 16 may be blocked unless a release command is received by the device 16. For example, a release command may be sent periodically to a mobile device 16 in the form of an updated delayed lockdown command. The delayed lockdown command may specify that access to portions of the data are permitted for a period of time, typically measured in minutes, hours, days or weeks as necessary. After the specified time period expires, lockdown and/or deletion of the data may occur. In certain embodiments, lockdown can be implemented as partial or total restriction to data on a mobile device 16 and may include a data erasure process that generates a poison pill command.
In certain embodiments, lockdown can be used to control and affect the operation of a mobile device 16 and may be used to restrict service of a cellular phone or mobile computing device, etc. Service restriction can include disabling or restricting call initiation and call reception in a variety of manners and may include the use of system components deployed in access points of wireless service providers. In one embodiment, a lockdown command may restrict access to a repository of telephone numbers provided by the enterprise controlling the device. The enterprise telephone numbers may be maintained in an encoded or encrypted manner on the mobile device such that a user electing to call the enterprise number may not see the actual number dialed. Thus, when access to the enterprise numbers is blocked by a lockdown command or for failure of user authentication, the desired number will not available for dialing. Furthermore, a different number could be substituted that causes the device to call a security system to report the attempted call and/or to receive further commands from the system.
In certain embodiments, service restriction can be implemented to limit the use of the mobile device 16 to a list of authorized numbers. The service may be limited to numbers provided to members of a group within the enterprise and can be limited based on the individual user of the mobile device 16. In one example, service may be restricted to local calling, in-state calling or group calling except for specific predefined numbers controlled by an administrator using a system of servers or control devices. Restricting service to local calls may be accomplished using a client application and/or a customized mobile device 16. The client can be used to intercept keyed entries by the user and can perform a variety of authorization and lookup functions. In one example, the client may permit the user to select from an authorized directory and may prevent entry of numbers requiring calls beyond a predefined calling zone.
In certain embodiments, restrictions on data transfers to and from mobile devices 16 may be configured. Data transfers may be initiated using SMS or other messaging systems, web browsers, video and multimedia streaming, Email and so on. Data transfer restrictions may be enforced in any of a number of ways. In one example, data transfer volumes can be monitored and restricted such that a user may not transfer data in excess of a cumulative limit and/or may not transmit or receive data objects larger than a predefined size. Address restrictions may also be imposed to limit the number and type of communication partners available to a user of the mobile device 16. These restrictions are typically managed by an administrator in a manner similar to that described for phone number management. In that regard, an administrator may impose limits on the volume of voice calls, the quantity of data or some combination of calls and data that can be sent or received from a mobile device 16.
In certain embodiments, client applications may be used to authenticate users and enforce policies set by the system and the system administrators. Client applications may be provided to the mobile device 16 using a registration process described in more detail below. Certain mobile devices 16 may be customized to provide client services without the need for installation of client applications. Thus, the client may be implemented as a combination of hardware and software components in a mobile device 16. For example, encryption may be provided as part of a storage system on the device 16 whereby access to stored data can be prevented by the storage device unless proper authentication is provided by other client functions. In certain embodiments, the client cooperates with an authentication server to identify a user seeking to use the device. The user may provide identification and passwords or may be identified by biometric means available to the mobile device including, for example, fingerprint reader, iris scanner, etc.
The mobile device 16 may maintain sufficient information to authenticate the user without system participation, such information having been previously provided by the authentication or other server. In some embodiments, the mobile device may relay identifying information to the authentication server for confirmation of the user credentials. Upon authentication, the client typically retrieves access rules associated with the user from local storage or from an administrating device. In some embodiments, the rues can be retrieved upon first authentication of the user and may be updated during subsequent usage of the device by the user.
FIG. 3 is a flowchart illustrating a simplified registration process followed by an administrator in creating a new account and user information. At step 300, an account is created. Account creation typically comprises establishing information identifying ownership of data and users of the data as well as establishing administrative privileges of the account administrator. The administrator may also create a web page on a server for controlling user devices and managing synchronization of data. At step 302, users may be assigned group memberships that are typically related to function and position within the enterprise. At step 304, access privileges are assigned to the group or groups created. Access privileges may be granted by assigning ownership of certain data to groups or subgroups and providing access to other groups as determined by enterprise policy or need. The administrator may then add users to the groups at step 306. Adding users may include creation and of new user profiles and modification of existing user profiles. User profiles can be created manually or added by importing one or more preexisting contact lists, typically provided in a commonly recognized format, such as comma separated variable or other file type. At step 308, the administrator can create new groups and populate groups of users that reflect the organization of the enterprise. At step 310, the administrator may assign additional privileges or limit group privileges of each user in the group. At step 312, additional users can be created or added to groups and certain users may be added to additional groups.
Turning now to FIGS. 2 and 4, a simplified description of a process for initializing a mobile device 16 is described. The mobile device 16 can be any device capable of communicating wirelessly including cellular telephone, satellite telephone, PDA, mobile computing platform, multimedia player, gaming device and son on. The mobile device can receive and execute a client application 20 at step 400, the client 20 facilitating operation of the device according to certain aspects of the inventions. In some embodiments, the client 20 or portions of the client 20 may be predisposed within the mobile device as a combination of hardware and software components. In some embodiments, the client 20 may be provided on removable storage such as a SIM chip, a smartcard, smart chip and/or on a preconfigured storage device. The client 20 typically provides components that support sharing of protected enterprise data. These components can include registration and authentication instructions and data 202, policies and policy enforcement 204, an executive 206 for receiving, decoding and executing commands received from a system server 11, a synchronizer 208 and interface components for augmenting and customizing wireless communications 200, typically used for enforcing policies according to certain aspects of the invention. The components, alone or in combination, can be used to implement certain high level functions, processes, operations, tools and applications. The components may handle a downloaded product that manages certain data types such as the RemoBiz, RemoMail, iPhonebook and iDatebook applications mentioned above. The components may permit execution of business applications such as decision support systems, Email, contact lists and directories and calendaring applications. It will be appreciated that various applications may be downloaded wirelessly although many downloads can be accomplished using a wired connection between wireless device and a host computer or through removable storage systems.
At step 402, the client 20 can be initialized during first use of the mobile device 16 by an authorized user. In one example, first use is determined when the user provides identification, often in the form of a PIN or other code. Verification of the PIN may be based on information previously stored in the mobile device 16 but may also require performing an authentication process with the system at step 404. The authentication process may include an exchange of keys, for example. Upon authentication and at step 406, the user may provide certain identifying and customizing data for use on the mobile device 16, particularly where the phone may maintain multiple user profiles.
At step 408, the mobile device is synchronized with one or more system servers 11. Synchronization typically causes the loading of new or additional contact information, calendaring events, Email, etc. and may also include the deletion of certain information. Additionally, synchronization can include the download and initiation of applications to the mobile device 16 as well as commands from the system servers 11. At this point, the mobile device performs according to certain aspects described above and a user may establish and receive calls as authorized by the enterprise system. In certain embodiments, an action of the user may initiate a system request at step 410. The system request may comprise a request to call a telephone number in a different area code or an attempt to access the Internet, for example. The system request may necessitate performance of a system service such as a synchronization of private or enterprise data, a change of authorization or an intervention of an administrator. Typically, the system request may be fulfilled by creating a connection between the mobile device 16 and a desired destination or between the mobile device 16 and a system component and where authorized at step 412, such connection is established at step 414. If the system request cannot be authorized at step 412 or requires no connection, then the mobile device may be resynchronized at step 408 before resuming normal operation. Upon completing one or more transactions at step 414, connections can be broken down at step 416 before resynchronization of the mobile device 16 at step 408 as necessary or desired.
As noted above, authorization to assign or modify the enterprise data or related information is reserved for an administrator and enterprise information typically cannot be modified by users for upload during synchronization. However, in certain embodiments, it may be desirable to notify an administrator of desired changes in order to facilitate update of enterprise data. Based on the privileges assigned to individual users, private information such as contacts, calendar, non-corporate email accounts can be maintained on the mobile device. Such private information can be updated using a two-way synchronization process involving systems servers 11 and the mobile device.
With regard to commands issued during synchronization and described as executed using the client command processor 206, these commands can include a wide variety of functions. An administrator can typically prioritize the commands and, at the highest priority level, can push certain commands to the mobile device 16 at the earliest opportunity. The earliest opportunity may be created during a periodic contact by the mobile device 16 but the system may also contact the device using network access point protocols or by establishing a “dialed” connection with the device in order to transmit the commands. Commands may be used to schedule or initiate updates related to contacts, events, tasks, account information. Commands may also include security related commands such as the poison pill command described above and that causes the mobile device 16 to erase stored information such as contacts, calendar events, archives, email accounts, images, audio/video files.
In certain embodiments, central control of mobile phone usage is provided. A server-based controller may cooperate with a client provided on the mobile device in a manner that allows and enterprise to control usage of mobile phone provided to employees. Typically, a business administrator can wirelessly restrict and employee phone for both voice calls and data usage. Restriction may be made to limit calls and contact with preauthorized business contacts. In some embodiments, broader controls may restrict usage by time, place, destination, originator and by any combination of these characteristics.
As described above, a client may be deployed to a mobile device, wherein the client comprises hardware and software components. The client responds to commands from an administrator in order to allow restriction of the mobile devices with regard to both voice and data transmissions and in relation to the authorized contact list. The contact list can be synchronized wirelessly to the phone application in real-time based on schedule or in response to a command of an administrator who controls the authorized contact database. Sending and receiving voice calls, text messages, email messages, audio/video/image files can be restricted to the authorized contact list which resides in the application.
Referring now to FIG. 4, the operation of a mobile device according to certain aspects of the invention will now be described. At step 400, an administrator typically configures the contact list authorized for a user. The list may comprise portions of the enterprise list based on group membership, portions of the enterprise list based on the authorization level assigned to the user and portions of private contact lists identified by the user.
At step 402, the user will typically initialize a mobile device. Initialization can include installing a client downloading authentication information. Download and installation may include receiving a plurality of transfers from central servers 11. The user can then be identified to the system at step 404 and, at step 406, the system may authenticate the user using, for example, a password or PIN.
At step 408, the mobile device 16 is loaded with an authorized contact list. The initial loading can be performed by a synchronization of the mobile device data with system data. During an initial synchronization, a majority of the contact information may be initialized on the mobile device, although in some embodiments the mobile device can be preconfigured with client and a default contact list. Subsequent synchronizations operate to update, remove and add contacts and other information.
At step 410, the client detects an attempt to establish a call or connection involving the mobile device. Call establishment may involve a voice, data or other connection and the call may be an incoming call or outgoing call where, for example, a user attempts to make a call using a restricted mobile device. At step 412, the client obtains details of the called/calling party, time of day and other relevant information such as geographical location, etc. Where the user is authorized to make the desired connection, the call can be established at step 414. However, the call is typically blocked at step 418 if the user is discovered at step 412 to have insufficient privilege to make or receive the call.
Determination of authorization to establish a call can be performed by validating the called (or calling) party using and authorized contact list that is typically maintained by the client in the mobile device. If the contact is not listed in the authorized contact list, call or data establishment is denied. In some instances, the voice call or data link may be terminated if already established.
It will be appreciated that the authorization procedure may be applied to subsequent and additional call requests when a first call to a first contact is established. Thus, a call request from or to a second contact will be permitted if the second contact is listed in the authorized list. Thereafter, the user of the device may toggle between first and second calls or may initiate a conference call. In certain embodiments, a conference call may not be permitted if the first and second contacts are using mobile devices controlled by the system and are not in each other's authorized contact list. However, in at least some embodiments, a conference call can be established between three or more users if the authorized contact list of at least one of the users lists the other parties. In some embodiments, a conference call can be established based on a pooling and/or sharing of authorized contact lists that results in a combined contact list.
In certain embodiments, changes made to the authorized contact list by an administrator can be propagated to users and groups of users using BREW-enabled SMS messages whereby the messages are configured to wake the client at step in order to perform a synchronization process 408. In one example, the incoming message will be handled at steps 410, 412 and 414 as an authorized incoming call. However, upon receiving the SMS message, the client may determine at step 416 that a wake up call was received and may then initiate synchronization of its databases and other information at step 408.
In certain embodiments, users can add personal contact and other information (e.g. calendaring information) to the enterprise provided mobile device. However, the addition of this contact information may not result in authorization to call or accept calls from contacts listed in the private information. However, it is contemplated that authorization to call or receive calls from certain of the private contacts may be granted by the administrator. In some embodiments, a budget may be provided for private calls that limit the usage of the mobile device based on enterprise policies.
In certain embodiments, an authorized contact list may be maintained by the client. The authorized contact list typically comprises phone numbers, email addresses, or any other addresses used for voice calls, SMS, IMS, and MMS technologies. The authorized contact list may be initiated and synchronized by wireless download to mobile devices from a hosted or enterprise-owned server on command or by schedule. Restriction can apply to both reception and initiation of voice calls, text messages, SMS, Email and multimedia information. Typically, carrier-specific contact numbers are always allowed. These carrier-specific numbers can include numbers such as support numbers (e.g. 611), emergency/rescue services (e.g. 911), information (e.g. 411) and so on. As discussed previously, restriction can apply to any mobile device including those latterly discussed mobile phones such as feature phones, smart phones, etc.
In one example, XYZ Inc. is a food distribution company with 200 truck drivers located at its Santa Clara, Calif. Office. XYZ management has decided to provide mobile phones to all the drivers to keep track of operations in real time. XYZ wish to control phone usage in order to prevent abuse by employees and limit the possibility of uncontrolled telephone bills. Otherwise, drivers might use the phones to make personal calls to any location and may download or send data files which can include very large multimedia files. Such abuse would prove overly expensive for a small food distribution company such as XYZ. Using the described software-based lockdown feature, an office manager can synchronize a restricted contact list for each driver's phone, permitting the establishment and reception of calls, messages, attachments only to or from authorized contacts. Updates to the contact lists may be made in real-time irrespective of the frequency of changes by using a business administrator web page. An administrator can also control phone usage using the lockdown feature and can wipeout all the business related information on any employee phone if the employee is separated from employment or if the phone is lost.

Additional Descriptions of Certain Aspects of the Invention

Certain embodiments of the invention provide systems, apparatus and methods for restricting a mobile device comprising receiving a request for connection of the mobile device, determining if the request is for connection with a preauthorized contact, establishing the connection if the request relates to a preauthorized contact, and denying the connection if the request does not relate to a preauthorized contact, wherein the determining is performed using a list of contacts provided by a business administrator. In some of these embodiments, the request is for an incoming connection. In some of these embodiments, the request for connection includes a request to initiate the connection. Some of these embodiments further comprise the step of updating the list of contacts upon receiving a synchronization command from the business administrator. Some of these embodiments further comprise the step of preventing access to the list of contacts upon receiving a lockdown command from the business administrator. In some of these embodiments, the preventing step includes denying all connection requests. Some of these embodiments further comprise the step of destroying the list of contacts upon receiving a poison pill command from the business administrator. In some of these embodiments, the destroying step includes denying all connection requests subsequent to receiving the poison pill command. In some of these embodiments, the request is received from a user of the mobile device and establishing the connection includes initiating a call to the preauthorized contact. In some of these embodiments, the request is received from the preauthorized contact and establishing the connection includes accepting a call from the preauthorized contact. In some of these embodiments, the mobile device comprises a mobile telephone. In some of these embodiments, the mobile device comprises a wireless computing device. In some of these embodiments, the connection is a voice connection. In some of these embodiments, the connection is a data connection.
Certain embodiments of the invention provide a restriction facility for a mobile device, comprising a client for processing commands received from a system controller wherein the commands include a lockdown command and, responsive to receiving the lockdown command, the client prevents access to a list of authorized contacts identifying a plurality of network nodes. In some of these embodiments, the client permits call initiation by the mobile device when the call is directed to a contact in the list of authorized contacts. In some of these embodiments, the client permits call reception by the mobile device when the call is directed to a contact in the list of authorized contacts.
Certain embodiments of the invention provide a medium that stores instructions executable by one or more processing devices to perform the methods described above. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident to one of ordinary skill in the art that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method for restricting a mobile device, comprising:

receiving a request for connection of the mobile device;

determining if the request is for connection with a preauthorized contact;

establishing the connection if the request relates to a preauthorized contact; and

denying the connection if the request does not relate to a preauthorized contact, wherein the determining is performed using a list of contacts provided by a business administrator.

2. The method of claim 1, wherein the request is for an incoming connection.

3. The method of claim 1, wherein the request for connection includes a request to initiate the connection.

4. The method of claim 1, and further comprising the step of updating the list of contacts upon receiving a synchronization command from the business administrator.

5. The method of claim 1, and further comprising the step of preventing access to the list of contacts upon receiving a lockdown command from the business administrator.

6. The method of claim 5, wherein the preventing step includes denying all connection requests.

7. The method of claim 1, and further comprising the step of destroying the list of contacts upon receiving a poison pill command from the business administrator.

8. The method of claim 7, the destroying step includes denying all connection requests subsequent to receiving the poison pill command.

9. The method of claim 1, wherein the request is received from a user of the mobile device and establishing the connection includes initiating a call to the preauthorized contact.

10. The method of claim 1, wherein the request is received from the preauthorized contact and establishing the connection includes accepting a call from the preauthorized contact.

11. The method of claim 1, wherein the mobile device comprises a mobile telephone.

12. The method of claim 1, wherein the mobile device comprises a wireless computing device.

13. The method of claim 1, wherein the connection is a voice connection.

14. The method of claim 1, wherein the connection is a data connection.

15. A restriction facility for a mobile device, comprising a client for processing commands received from a system controller wherein the commands include a lockdown command and, responsive to receiving the lockdown command, the client prevents access to a list of authorized contacts identifying a plurality of network nodes.

16. The restriction facility of claim 15, wherein the client permits call initiation by the mobile device when the call is directed to a contact in the list of authorized contacts.

17. The restriction facility of claim 15, wherein the client permits call reception by the mobile device when the call is directed to a contact in the list of authorized contacts.

18. A computer-readable medium that stores instructions executable by one or more processing devices to perform a method for restricting a mobile device, the method comprising:

receiving a request for connection of the mobile device;

determining if the request is for connection with a preauthorized contact;

19. The computer-readable medium of claim 18, and further comprising the step of preventing access to the list of contacts upon receiving a lockdown command from the business administrator.

20. The computer-readable medium of claim 19, wherein the preventing step includes denying all connection requests.

21. The computer-readable medium of claim 20, and further comprising the step of destroying the list of contacts upon receiving a poison pill command from the business administrator.

22. The computer-readable medium of claim 21, the destroying step includes denying all connection requests subsequent to receiving the poison pill command.