A vanish Pande

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Application No. 62/297,185, filed on February 19, 2016, the contents of which are hereby incorporated by reference.

SUMMARY OF THE INVENTION

[0002] Embodiments disclosed herein provide for a secure and cost effective system and method of authentication. In one embodiment, to authenticate a remote terminal, an authentication server may use a short, unanswered call, to provide a verification code to the remote terminal. In one embodiment, the remote terminal may send an initial authentication request to the authentication server. The authentication server may respond to the initial authentication request with a short, unanswered telephony call to the remote terminal (or other device). The authentication server may embed one or more codes in a calling line identification (CLI) record associated with the short, unanswered call. The remote terminal may analyze the CLI associated with the short, unanswered call to determine whether the remote terminal received a verification code (sometimes also herein referred to as an authentication code) from the authentication server. If the remote terminal determines that the CLI contains the verification code, the remote terminal will transmit a second authentication request with the verification code to the authentication server. If the authentication server determines that second authentication request (including the verification code) matches with information contained in the initial authentication request, the authentication server will provide an authentication message to the remote terminal. The authentication message may unlock or activate certain features and/or functionality of the remote terminal.

[0003] In some embodiments, the authentication server may obtain certain unique identifying information from the remote terminal to increase security of the authentication process. For example, the remote terminal may transmit to the authentication server a mobile station international subscriber directory number (MS1SDN) associated with the remote terminal. The remote terminal may transmit an international mobile station equipment identity (1MEI) associated with the remote terminal. The remote terminal may transmit to the authentication server the geographic location information associated with the remote terminal (obtained from global positioning satellites (GPS) and/or WIFI and/or cellular triangulation, or other means). In one embodiment, the remote terminal transmits one or more of the above unique identifying information to the authentication server in the initial authentication request and the second authentication request When the authentication server receives the second authentication request, the authentication server may compare the unique identifying information from initial authentication request and the second authentication request along with the verification code. If the verification code and all of the unique identifying information matches, the authentication server can confirm that the remote terminal can be authenticated. In one embodiment, the authentication process can be used to activate or unlock certain features and/or functionality of other devices.

[0004] The aforementioned and other objects, features and merits of the present invention will become more apparent from the detailed description of the representative embodiments of the present invention illustrated in the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005J Fig. 1 is a diagrammatic view of one embodiment of a network system configured to perform authentication.

[0006] Fig. 2 is a diagrammatic view of another embodiment of a network system configured to perform authentication.

[0007] Fig. 3 is a diagrammatic view of a data/call flow for performing authentication.

[0008] Figs.4A and 4B illustrate a flowchart that depicts one embodiment of a network system performing authentication.

[0009] Fig. 5 is a flowchart that depicts one embodiment of a network system performing authentication.

[0010] Figs. 6A and 6B illustrate a flowchart that depicts one embodiment of an authentication server performing authentication.

[0011] FIG. 7 is a diagram of example components of a computing device of an authentication cloud. DETAILED DESCRIPTION OF THE INVENTION

[0012] Embodiments of the present invention will be discussed below with reference to FIGS. 1 to 7.

[0013] Fig. 1 is a diagrammatic view of one embodiment of a network system adapted to perform authentication using missed calls. Carrier network 100 may comprise one or more computing devices 105. The computing devices 105 may include, among other things, mobile devices or remote terminals. For purposes of illustration, computing devices 10S will be hereinafter referred to as mobile device 105. Mobile device 105 can access carrier network 100 through a radio access network 110. In one embodiment, the carrier network 100 may interface with other network elements 115 and 120. Network elements 115 and 120 may comprise gateways or switches depending on the type of network connectivity required. For example, network element 115 may comprise an internet protocol (IP) gateway router to communicate with authentication cloud 130. Network element 120 may comprise a telephony switch or a media switch capable of communicating with time division multiplexing (TDM) or IP networks such as telephony network 155. Mobile device 105 may also receive global positioning signals (GPS) from GPS satellites to determine the location of mobile device 105. Mobile device 105 may also use Wi-Fi positioning or cellular triangulation to determine the location of mobile device 105.

[0014] In one embodiment, carrier network 100 is in communication with authentication cloud 130 via network element 145. In this embodiment, network element 145 may comprise an IP gateway router to receive data transmissions from the carrier network 100. The authentication cloud 130 may include an authentication server 135 than handles authentication requests and determines whether authentication requests can be approved. The functions of authentication server 135 can be included in a single special purpose computer/server or in separate special purpose computers/servers. The features of authentication cloud 130 may also be divided in a distributed processing environment among different discrete processors or discrete servers. The authentication server 135 may be in communication with a storage database 140. Alternatively, storage database 140 may be included in authentication server 135. Authentication server 135 may be in communication with network element 145 and may receive authentication requests through network element 145. Authentication server 135 may also send authentication data through network element 145. Authentication server 135 may also be in communication with network element 150 to send data to the telephony network 155. For example, authentication server 135 may send data related to generating a telephone call to the telephony network 155 through network clement 150. In one embodiment, network element ISO may comprise a telephony switch or a media switch capable of communicating with TDM or IP networks such as telephony network 155. Alternatively, network element ISO may be an IP gateway for communicating with other IP based network elements.

[0015] In one embodiment, the authentication cloud 130 is in communication with the telephony network. In one such embodiment, authentication cloud 130 does not include telephony equipment to generate telephony calls to a telephony network such as carrier network 100. In such an embodiment, authentication cloud 130 may rely on an intermediary telephony network such as telephony network 155 to generate telephony calls. In one embodiment, network element 165 is an IP gateway. In another embodiment, network element 165 is a session border controller (SBC) capable of handling session initiation protocol (SIP) data traffic. Network element 165 may comprise a telephony switch or a media switch capable of communicating with TDM or IP networks. Telephone switch 160 may be in communication with the network element 165. Telephone switch 160 may comprise a telephony switch or a media switch capable of communicating with TDM or IP networks. Telephone switch 160 may communicate through network element 165 to network element 120 of the carrier network to generate telephony calls to mobile devices 105.

[0016J Fig. 2 is a diagrammatic view of one embodiment of a network system adapted to perform authentication using missed calls. Fig. 2 differs from Fig. 1 in that the authentication cloud 230 may include a capability to directly interact with telephony networks such as carrier network 220. That is, authentication cloud 230 may include a telephony switch 245 and a network element 255 that can generate calls on carrier network 200. Thus, in such an embodiment, authentication cloud 230 does not need to rely on an intermediary telephony network to generate telephony calls. In one embodiment, network element 255 and telephony switch 245 may comprise an IP gateway. In another embodiment, network element 255 and telephony switch 245 may comprise a session border controller (SBC) capable of handling session initiation protocol (SIP) data traffic. In one embodiment, network element 255 and telephony switch 245 may comprise a telephony switch or a media switch capable of communicating with TDM or IP networks.

[0017] Fig. 3 is a diagrammatic view of a data/call flow for performing authentication in accordance with one embodiment In the following example, mobile device 300 transmits an initial authentication request 325 to authentication server 310. It should be appreciated that the terms authentication and authorization, as used herein, are sometimes used interchangeably. As illustrated in Fig. 3, mobile device 300 may be required to transmit the initial authentication request 32S through carrier network 30S (e.g., when mobile device docs not have alternative communication options available). In one embodiment, mobile device 300 may bypass the carrier network 305 if an alternative communication path is available to authentication server 310 (e.g., through WiFi communications). In one embodiment, mobile device 300 can be required to transmit the initial authentication request 325 through carrier network 305 even if other communication paths are available. In an embodiment where carrier network 305 receives the request, carrier network 305 forwards the same initial authentication request to authentication server 310 as shown at 330. When authentication server 310 receives the initial authentication request 330 transmitted via the carrier network 305, the authentication server 310 stores information contained in the initial authentication request in authentication database 315 (as shown in transmission 335). Authentication server 310 also generates a SIP request that includes a uniquely generated CLI and an MS1SDN associated with the mobile device 300. It should be appreciated that in one embodiment, the uniquely generated CLI is different from a standard CLI. That is, the uniquely generated CLI may repurpose the CLI standard to communicate different information used for a different purpose, as is discussed in more detail below. The MSISDN tells the telephony switch what device to call. The generated CLI may include two separately identifiable sets of numbers. One set of identifiable numbers identifies the CLI as a missed call authentication message. The other set of identifiable numbers in the CLI is a time limited authentication code generated for the mobile device 300. Authentication server 310 transmits the SIP request 340 including the generated CLI and MSISDN associated with the mobile device 300 to telephony switch 320.

[0018] In one embodiment, the SIP request instructs the telephony switch 320 to generate a call to the mobile device 300 (based on the MSISDN information). The telephony switch 320 generates the call 345. The call 345 is routed to carrier network 305 so that the carrier network can terminate (place) the call 350 to mobile device 300. The SIP request 340 also instructed the telephony switch 320 to place the call 345 and 350 such that the CLI of the call 345 and 350 shows the generated CLI.

[0019] Within a predetermined amount of time (in one embodiment, 15 seconds or less), the authentication server 310 transmits a SIP hang-up message 355 to telephony switch 320. Telephony switch 320 sends the appropriate message to the carrier network 305 to terminate the call as shown in 360. Carrier network thereafter terminates the call to mobile device 305 as shown in 365. The time between the generated call 345 and 350 and the call termination 360 and 365 may be any suitable period of time. In one embodiment, the mobile device rings once or does not ring to produce the missed call. In alternative embodiments, the mobile device 300 may ring any number of times. In one embodiment, a user may also answer the call to mobile device 300 and still obtain the uniquely generated CLI.

[0020] The mobile device 300 is specially configured to analyze its missed call logs to determine if the CLI is one of the uniquely generated CLIs that include a missed call identifier and the authentication or verification code. Once the mobile device 300 determines that the uniquely generated CLI was received, the mobile device 300 extracts the authentication or verification code from the uniquely generated CLI based on the missed call . The mobile device 300 then transmits a second authentication request 370 to the authentication server 310. In one embodiment, the second authentication request 370 may include the authentication or verification code extracted from the uniquely generated CLI, the MSISDN associated with the mobile device 300, the 1MEI associated with the mobile device 300, and geographic location data of the mobile device 300. The second authentication request 370 may include any combination of the foregoing items as well as other items necessary for the authentication process. As noted in Fig. 3, if a cellular network is used, the second authentication request 370 may be transmitted via the carrier network 305 as shown in reference 375.

[0021] When authentication server 310 receives the second authentication request 375 from mobile device 300, authentication server 310 retrieves the initial authentication request from authentication database 315, as shown in references 380 and 385. The authentication server 310 compares the information contained in the second authentication request to the information contained in the initial authentication request Depending on whether the information matches between the initial authentication request and the second authentication request, the authentication server 310 transmits an authentication message approving authentication or denying authentication to the mobile device 300 as shown in references 390 and 395. The authentication message approving authentication may cause mobile device 300 to be reconfigured to unlock or activate certain features and/or functionality of the mobile device 300. It should be appreciated that, as used herein, an authentication request is often a request message that originates from a mobile device, such as mobile device 300. The request message may be passed around to different equipment in the authentication system to perform the authentication process. It should also be appreciated that, as used herein, an authentication message is often a message that originates from an authentication server, such as authentication server 310. The authentication message may be passed around to different equipment in the authentication system to perform the authentication process.

[0022] Using the above architecture to perform authentication results in technological improvements over existing authentication systems for an easier, faster, cheaper, more efficient, and more secure authentication system. For example, the above architecture is easier and faster because end users can be removed from the authentication process. When authentication or verification codes are received at a user's device, the user does not have to search for received messages that provide authentication or verification codes and the user does not have to determine what part of a message includes the authentication or verification codes (which can be confusing, result in user errors, and frustrate users by preventing access to certain features of a service or features of a mobile device). The architecture is also easier, faster, and more accurate because users are freed from having to create additional authentication requests and manually provide the received authentication or verification codes in the additional authentication requests (e.g., the second authentication request) to the authentication system. The specially configured processor on the mobile device eliminates errors transferring the received authentication or verification codes and can complete the process faster than preexisting systems.

[0023] The above architecture is also more cost efficient than preexisting systems. For example, if short message service (SMS) was used to send messages with authentication or verification codes, each SMS message sent and received (especially when the SMS messages are sent across different mobile networks) incurs one or more transaction costs. The message sender is charged for the SMS message. If the SMS message leaves the mobile network operator associated with the sender, the mobile network operator is charged by an interconnected mobile network operator to deliver the SMS message. Tn some instances, the recipient of the SMS message may also be charged for the message. On the other hand, using missed calls to deliver the authentication or verification codes generally avoids any costs. Typically, no party (e.g., the user, the mobile network operators, etc.) pays any costs for a call that is considered missed or not completed.

[0024J The authentication architecture described herein is more efficient and reduces reliance on scarce resources. For example, if short message service (SMS) was used to send messages with authentication or verification codes, the SMS messages would be sent over spare bandwidth on a voice network that is used for signaling traffic. SMS messaging uses a separate channel with limited bandwidth among available voice channels on a mobile device, which is also used for transferring data packets of signaling control messages. Whereas voice and data calls have a dedicated, larger share of available bandwidth to use. As a result, SMS messages uses a limited resource. Thus, the architecture to perform authentication as described herein reduces the burden on the limited SMS resources by relying telephony architecture with greater bandwidth to deliver the authentication or verification codes. When the architecture to perform authentication results as described herein is increased in scale (e.g., handling millions of authentication transactions a day), the reduction in bandwidth load used by SMS traffic become more apparent. The architecture to perform authentication results as described herein also reduces the load on equipment used to deliver SMS messages (mobile network operators that manage SMS transmission equipment generally maintain less available SMS equipment than equipment available for use to deliver voice and data calls).

[0025] Using the above architecture to perform authentication also results in a more secure authentication system because of the use of unique device verifications. For example, if short message service (SMS) was used to send messages with authentication or verification codes, these messages would be vulnerable to many known flaws of the SMS system (such as fraudulent spoofing and "man-in-the middle" attacks). As discussed herein, the architecture to perform authentication not only uses returned authentication or verification codes, but also may use other unique parameters of a mobile device to determine that an authentication request is non-fraudulent (e.g., determining a mobile device's 1MEI, 1MS1, UDID, or geographic location information in each authentication request). By incorporating checks against these additional items associated with a mobile device (or a device requesting the authentication), the authentication system discussed herein reduces the ability of attackers to improperly or illegally obtain authentication or verification codes to unlock costly features of a mobile device or a service.

[0026] Figs. 4A, 4B, and 5 are flowcharts that depict one embodiment of a network system performing authentication. At step 400, a mobile device generates an initial authentication request to access certain features and/or functionality of the mobile device. In one embodiment, a feature may include the ability to place free Voice over IP (VoIP) telephony calls to another mobile device in another country via specially configured network devices. The operators of the specially configured network devices want to ensure that only authorized devices access and use the specially configured network devices. The authentication system ensures that only authorized users have access to the specially configured network devices. It should be appreciated that the features and/or functionality of the mobile device are not limited to the above example.

[0027] The generated request may include the MSISDN, 1MEI, UDID, and location information associated with the mobile device. The generated request may also include domain identifiers associated with the mobile device or an application running on the mobile device. For example, the mobile device may include different functions, features, or applications that each require separate and different authentications. Thus, the domain identifier may be used to further differentiate more than one authentication request originating from the same mobile device.

[0028] The mobile device transmits the generated initial authentication request to an authentication server at step 405. The authentication server receives the initial authentication request from a mobile device at step 410. The request may include the MSISDN, IMEI, UDID, and Location Information. The request may include other unique identifiers, as necessary to increase security functionality, as noted above. The authentication server stores the received IMEI, UDID, and Location Information in an authentication database at step 420 that is in communication with the authentication server. The combination of received data from the initial authentication request may be referred to as information from an initial authentication request.

[0029] The authentication server also generates a CL1 based on information associated with the received authentication request at step 415. The CLI may include a generated missed call identifier and a generated verification code, which are not part of the standard CLI. The missed call identifier is a number that permits a mobile device to determine that a missed call was more than just a typical missed call. The missed call identifier is a predetermined number that tells the specially programed mobile device that the CLI for the missed call includes an authentication code or verification code that can be used to complete the authentication process. In one embodiment, the missed call identifier is known to the mobile device. In one embodiment, the missed call identifier number is periodically changed at the authentication server and provided to the mobile device, whereby the mobile device is reconfigured to recognize the new missed call identifier. A message updating the missed call identifier may be provided via cellular data, Wi-Fi data, or other suitable communication interface. The missed call identifier may be changed daily, hourly or during some other suitable period of time. In one embodiment, if the mobile device does not receive the updated missed call identifier, the mobile device may not be reconfigured to determine that a CLI for the missed call contains a verification code, in one embodiment, a different plurality of missed call identifiers may be supplied to the mobile device from the authentication server. Each of the different plurality of missed call identifiers may be associated with unlocking or accessing different features or functionalities of the mobile device. In one embodiment, the missed call identifier may be embedded in the CLI as the first 5 digits of the CLI. However, any suitable number of digits of the CLI may be used to store the missed call identifier. Any suitable location for the digits in the CLI may be used to store the missed call identifier. [0030] The generated verification code may be a randomly or pscudo- randomly generated number. The verification code may have a predefined period of usable life. That is, the verification code may only be usable for a fixed period of time. In one embodiment, the fixed period of time can be set at 5 minutes. In another embodiment, any suitable amount of time can be used for the fixed period of time. In an alternative embodiment, the period of time that the verification code is usable is not fixed. In one embodiment, the verification code may be embedded in the CLI as the last 4 digits of the CLl. However, any suitable number of digits of the CLl may be used to store the verification code. Any suitable location for the digits in the CLl may be used to store the verification code. The authentication server may store the verification code in association with the mobile device that sent the initial authentication request The verification code may be stored in the authentication database along with the information from the initial authentication request.

[0031] At step 425, the authentication server transmits a SI? request with a custom payload (e.g., including the generated CLI and the MSISDN associated with the requesting mobile device) to a telephony switch at step 425. Based on the SIP request and the MSISDN, the telephony switch generates a call including the generated CLI to the mobile device at step 430.

[0032] At step 435, the mobile device receives the call. Due to the received call, the call log of the mobile device includes the custom generated CLI at step 435.

[0033] The authentication server also transmits a SIP request to the telephony switch to terminate the call to the mobile device at step 440. Switching to Fig. 4B, as shown in step 445, the telephony switch terminates the call to the mobile device. In one embodiment, the time between the initial call to the mobile device and the call termination is less than a predetermined period of time at step 445. In one embodiment, the time period is 15 seconds or less. By keeping the time between the call setup and call termination short, the mobile device may only ring one time or not at all to ensure the call is a missed call. By avoiding the user picking up the call and maintaining the call as a missed call, the call will avoid incurring any minute charges or minute plan deductions to the callee. The missed call can also avoid charges being incurred by the telephony network placing the call. However, in alternative embodiments, the call may ring more than once and/or the user may pick up the call while still obtaining the generated CLI at the mobile device. In such an instance, the mobile device may be reconfigured to review other call logs or all call logs to search for the missed call identifier.

[0034] After receiving the missed call, the mobile device may review its stored call log records of received calls at step 450. The mobile device inspects the CLIs of the missed calls for the embedded missed call identifiers. For example, the mobile device determines if a predetermined quantity of initial numbers of the CLI of the available call records matches the stored missed call identifier at step 455. In one embodiment, the mobile device only checks the CLI of the last call that was received at the mobile device. In other embodiments, the mobile device may review any number of records in the call log of the mobile device. The process may stop at step 460 if the predetermined quantity of initial numbers of the CLI of each reviewed record does not match the stored missed call identifier.

[0035] At step 46S, if the mobile device determines that the predetermined quantity of initial numbers of the CLI for a received call (or alternatively, just for a missed call) matches the stored missed call identifier, the mobile device extracts a predetermined quantity of numbers from the end of the same CLI at step 465 to obtain the verification code. It should be appreciated that in one embodiment, by restricting the missed call identifier to only missed calls, the mobile device gains a power saving and processing efficiency advantage. That is, the mobile device would need to search less CLI records. This reduces the necessary processing power to execute the search, which also reduces the power drain on the mobile device.

[0036] The mobile device at step 470 generates a second authentication request that includes the verification/authentication code (e.g., the predetermined quantity of numbers from the end of the CLI). The second authentication request may include the MSISDN, IMEI, UD1D, and Location Information of the mobile device. The second authentication request may include other unique identifiers, as discussed above in connection with the initial authentication request. The mobile device transmits the second authentication request to the authentication server at step 475.

[0037] The process continues at off-page connector A (480) to Fig. 5 off-page connector A (500). At step 505, the authentication server receives the transmitted second authentication request. The authentication server retrieves, from the authentication database, the stored information from the initial authentication request associated with the mobile device (e.g., the IMEI, UD1D, and Location Information, etc.) at step 510. The authentication server compares the verification code received in the second authentication request to the previously generated verification code stored in association with the mobile device (when originally generated for the CLI). The authentication server also compares the other information received in the second authentication request (e.g., the MSISDN, IMEI, UDID, and/or Location Information, etc.) to the stored information received in the initial authentication request at step 515.

[0038] The authentication server determines whether the received verification code matches the stored generated authentication code and whether information from the initial authentication request matches with the information from the second authentication request at step 520.

[0039] The authentication server transmits a message to the mobile device denying authentication at step S2S if a match is not achieved.

[0040] The authentication server transmits an authentication message to the mobile device confirming authentication at step 530 if a match is determined. At step 535, the mobile device uses the authentication message to activate, unlock, or enable certain functions and features on the mobile device without requiring user intervention at step 535. In the system above, the user does not need to review call records to find the authentication or verification code. The mobile device can automatically obtain the authentication or verification codes and automatically can unlock or enable features of the mobile device.

[0041] Figs. 6A and 6B illustrate a flowchart that depicts one embodiment of an authentication server performing authentication. The authentication server receives an initial authentication (e.g., authorization) request from a mobile device. It should be appreciated that, as used herein, the terms authentication and authorization may sometimes be used interchangeably. The request may include the MSISDN, IMEI, UDID, and Location Information. The request may also include domain name information associated with a customer at step 600.

[0042] The authentication server causes information such as the IMEI, UDID, and Location Information contained in the request to be stored in an authentication database that is in communication with the authentication server at step 605.

[0043] The authentication server generates a CLI based on information associated with the received authentication request at step 610. The generated CLI may include a missed call identifier and an authentication or verification code as previously discussed. The authentication server transmits a SI? request (including the generated CLI and the MSISDN associated with the requesting mobile device) from the authentication server to telephony switch at step 615. The authentication server transmits a SIP request to a telephony switch to terminate the call at step 620. Switching to Fig. 6B, the authentication server receives a second authentication request from the same mobile device at step 625. The authentication server retrieves, from the authentication database, the stored information associated with the initial authentication request associated with the mobile device at step 630.

[0044] The authentication server compares the authentication code and other information (e.g., MSISDN, IMEI, UDID, and Location Information, etc.) received in the second authentication request to the stored authentication code and other information (e.g., MSISDN, IMEI, UDID, and Location Information, etc.) from the initial authentication request at step 635. [0045] The authentication server determines whether the received authentication code matches the stored authentication code and whether data or information from the initial authentication request matches with the data or information from the second authentication request at step 640.

[0046] Switching back to Pig. 6A, the authentication server transmits a message to the mobile device denying authentication at step 64S if a match is not made. The authentication server transmits an authentication message to the mobile device confirming authentication to unlock features and functions on the mobile device at step 6S0 if a match is made.

[0047] Fig. 7 is a diagram of components of a computing device 700 which may be used to implement various computer devices of the systems and methods described in this document, such as the devices of authentication cloud 130 and mobile device 10S, as either as client devices or as a server or a plurality of servers. Computing devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Other computing devices may include various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices. Computing devices can include Universal Serial Bus (USB) flash drives. T e USB flash drives may store operating systems and other applications. The USB flash drives can include input/output components, such as a wireless transmitter or USB connector that may be inserted into a USB port of another computing device. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit embodiments of the inventions described and/or claimed in this document.

[0048] In one embodiment, a computing device used herein may include a processor 710, memory 720, a storage component 730, a high and low speed interfaces and buses 740 connecting to the memory. Each of the components of the computing devices are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor can process instructions for execution within the computing device, including instructions stored in the memory or on the storage device to display graphical information for a graphic user interface on an external input/output device 7S0 such as a display. In other embodiments, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices may be interconnected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system). [0049] The processor may be implemented as a chipset of chips that include separate and multiple analog and digital processors. Additionally, the processor may be implemented using any of a number of architectures. For example, the processor may be an x86 processor, CISC (Complex Instruction Set Computers) processor, a RISC (Reduced Instruction Set Computer) processor, or a MISC (Minimal Instruction Set Computer) processor. The processor may provide, for example, for coordination of the other components of the device, such as control of user interfaces, applications run by device, and wireless communication.

[0050] The processor may communicate with a user through a control interface and display interface coupled to a display. The display may be, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface may comprise appropriate circuitry for driving the display to present graphical and other information to a user. The control interface may receive commands from a user and convert them for submission to the processor. In addition, an external interface may be provided in communication with processor to enable near field communication with other devices. External interface may provide, for example, for wired communication in some embodiments, or for wireless communication in other embodiments, and multiple interfaces may also be used.

[0051] The memory may store information within the computing device. In one embodiment, the memory is a volatile memory unit or units. In another embodiment, the memory is a nonvolatile memory unit or units. The memory may also be another form of computer-readable medium, such as a magnetic or optical disk.

[0052] T e storage device is capable of providing mass storage for the computing device. In one embodiment, the storage device may contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. The storage device may be anyone of the foregoing and be located remotely, such in a cloud infrastructure. A computer program product can be tangibly embodied in an information carrier. The computer program product may also contain instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory, the storage device, or memory on processor.

[0053] The computing device may be implemented in a number of different forms. For example, it may be implemented as a standard server, or multiple times in a group of such servers. It may also be implemented as part of a rack server system. In addition, it may be implemented in a desktop computer or a laptop computer. Alternatively, components from the computing device may be combined with other components in a mobile device. Each of such devices may contain one or more computing devices. An entire system may be made up of multiple computing devices that communicate with each other.

[0054] The computing devices may communicate wirelessly through communication interfaces 760, which may include digital signal processing circuitry. Communication interfaces may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication may occur, for example, through a radio- frequency transceiver. In addition, short-range communication may occur, such as using a Bluetooth, Wi-Fi, or other such transceiver. In addition, a GPS (Global Positioning System) receiver module may provide additional navigation- and location-related wireless data to the computing devices, which may be used as appropriate by applications running on the computing devices.

[0055] The computing devices may communicate audibly using an audio codec, which may receive spoken information from a user and convert it to usable digital information. The audio codec may likewise generate audible sound for a user, such as through a speaker. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on the computing devices.

[0056] Various embodiments of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, and/or combinations thereof. These various embodiments can include embodiments that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special purpose computers, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0057] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having any suitable display device for displaying information to the user and an input device 770 (e.g., a keyboard, a touchpad, touchscreen, a mouse, or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback). Input from the user can be received in any form, including acoustic, speech, or tactile input.

[0058] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an embodiment of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), peer-to-peer networks (having ad-hoc or static members), grid computing infrastructures, and the Internet.

[0059] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0060] The illustrative block diagrams and flowcharts depict process steps or blocks that may represent modules, segments, or portions of code that include one or more executable instructions for implementing specific logical functions or steps in the process. Although the particular examples illustrate specific process steps or procedures, many alternative implementations are possible. Some process steps may be executed in different order from the specific description herein based on, for example, considerations of function, purpose, conformance to standard, legacy structure, user interlace design, and the like.

[0061 ] A number of embodiments of the invention have been described. It should be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, various forms of the flows shown above may be used, with steps re-ordered, added, or removed. Also, although several embodiments of authorizing a remote terminal or mobile device have been described, it should be recognized that numerous other applications are contemplated. Accordingly, other embodiments are within the scope of the following claims.