Synchronization of an emulated device over a local link

RELATED CO-PENDING APPLICATION

[0001] The present Application for Patent is related to co-pending U.S. Application for Patent entitled “EMULATING A WIRELESS COMMUNICATION DEVICE USING A LOCAL LINK,” by Pattabiraman et al., having Attorney Docket No. 020137, filed concurrently herewith and assigned to the assignee hereof.

BACKGROUND

[0002] 1. Field

[0003] The present invention relates generally to communications, and more specifically to a novel and improved method and apparatus for synchronizing an emulated wireless communication device over a local link.

[0004] 2. Background

[0005] Wireless communication systems are widely deployed to provide various types of communication such as voice and data. These systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), or some other modulation techniques. A CDMA system provides certain advantages over other types of systems, including increased system capacity.

[0006] A CDMA system may be designed to support one or more CDMA standards such as (1) the “TIA/EIA-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System” (the IS-95 standard), (2) the standard offered by a consortium named “3rd Generation Partnership Project” (3GPP) and embodied in a set of documents including Document Nos. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214 (the W-CDMA standard), (3) the standard offered by a consortium named “3rd Generation Partnership Project 2” (3GPP2) and embodied in a set of documents including “C.S0002-A Physical Layer Standard for cdma2000 Spread Spectrum Systems,” the “C.S0005-A Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems,” and the “C.S0024 cdma2000 High Rate Packet Data Air Interface Specification” (the cdma2000 standard), (4) the “TIA/EIA-IS-856 CDMA2000 High Rate Packet Data Air Interface Specification” (the IS-856 standard), and (5) some other standards. Non-CDMA systems include AMPS, GSM, and other TDMA systems. These and other wireless communication standards support data communication at various data rates.

[0007] Users of wireless communication devices conforming to one or more communication standards, such as those just described, often travel to areas covered by various alternate communication standards. The communication standard provided in any particular geographic region may or may not be supported by the user's device.

[0008] In addition, a user may have multiple wireless communication devices, such as a handheld mobile telephone, a mobile telephone in an automobile, or a notebook computer equipped with a mobile telephone for voice and/or data access, whether embedded in the computer or attached with a PC card.

[0009] A cellular network is an example of a wide area network. In addition, a cellular network likely connects to the Public Switched Telephone Network (PSTN), as well as other wide area networks, such as the Internet or corporate intranets.

[0010] Users may wish to access multiple wide area networks, perhaps using multiple devices, while maintaining a common identity for billing, record keeping, authentication, etc. Removable identity cards allow a user to access a wide area network with a variety of devices, while operating under an existing service contract associated with the identification information on the device. This process is referred to as emulation. For example, a user has a given service contract on device A. The user desires to access a network not available from device A directly, but available from device B. The user provides identification information from device A to device B. Device B then proceeds to access the network using the identification information from device A. In this case, device A is the “emulated device” and device B is the “emulating device.” Methods for providing information from one device to another include R-UIM cards, defined in TIA/EIA/IS-820, “Removable User Identity Module (R-UIM) for TIA/EIA Spread Spectrum Standards”, and SIM cards, defined in GSM 11.11, “Specification of the Subscriber Identity Module”. The user must swap the card between different devices to perform such emulation.

[0011] Local wireless communications standards, such as the BLUETOOTH Specification, allow multiple devices to communicate when in proximity to each other, in a peer-to-peer configuration (one of the devices is generally designated the server, and one or more proximate devices act as clients. BLUETOOTH is a trademark owned by BLUETOOTH SIG, Inc. having principle address c/o Sonnenschein Nath & Rosenthal, 1301 K St. NW, Suite 600, East Tower, Washington D.C. 20009. While one example of a wireless local link methodology is described by the BLUETOOTH Specification, other wireless and wired formats may be used to link together two wireless communication devices.

[0012] A first wireless communication device may be emulated on a wide area network using a local link. If a wireless local link is deployed, such as that specified by the BLUETOOTH Specification, no physical connection or swapping of a removable identity module is required. Techniques for such emulation are disclosed in co-pending U.S. patent application Ser. No. ______, entitled “EMULATING A WIRELESS COMMUNICATION DEVICE USING A LOCAL LINK” (referred to hereinafter as the ______ application), having Attorney Docket No. 020137, filed concurrently herewith, assigned to the assignee of the present invention and hereby expressly incorporated by reference herein.

[0013] During a wireless communication session, various parameters stored in a wireless communication device, such as a mobile station, may be updated over the air. For example, over-the-air updating is described in TIA/EIA/IS-683A, “Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Systems”. For transparent emulation, the emulated device should be synchronized with updated information during emulation. The first device, after being emulated by a second device, should be able to directly access a wide area network or communication system utilizing the updated information. There is therefore a need in the art for synchronizing an emulated device over a local link.

SUMMARY

[0014] Embodiments disclosed herein address the need for synchronizing an emulated wireless communication device over a local link. In one aspect, the emulating device monitors received signals for information directed to the emulated device. The information is delivered to the emulated device over the local link. In another aspect, the emulated device updates stored information with the information received over the local link. In yet another aspect, a previously emulated device accesses a wide area network directly, using synchronized information. Various other aspects are also presented. These aspects have benefits including keeping an emulated device synchronized with a wide area network such that post-emulation access attempts are made with updated information and parameters.

[0015] The invention provides methods and system elements that implement various aspects, embodiments, and features of the invention, as described in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The features, nature, and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout and wherein:

[0017]FIG. 1 is a general block diagram of a wireless communication system capable of supporting a number of users;

[0018]FIG. 2 depicts a portion of a mobile station equipped for emulation;

[0019]FIG. 3 depicts a flowchart of an embodiment of a method for emulating a first wireless communication device with a second device;

[0020]FIG. 4 depicts a flowchart of an embodiment of a method for communicating with a first device while emulating that device with a second device on a wide area network;

[0021]FIG. 5 depicts a flowchart of an embodiment of a method for communicating with a second device on a wide area network while emulating a first device;

[0022]FIG. 6 is a state diagram depicting an embodiment of a method for synchronizing an emulated device over a local link; and

[0023]FIG. 7 depicts a flowchart of an embodiment of a method for synchronizing an emulated device over a local link.

DETAILED DESCRIPTION

[0024]FIG. 1 is a diagram of a wireless communication system <b>100</b> that may be designed to support one or more wireless standards and/or designs (e.g., the W-CDMA standard, the IS-95 standard, the cdma2000 standard, the IS-856 standard, GSM, AMPS). Wireless communication system <b>100</b> is but one example of a wide area network that may be deployed within the scope of the present invention.

[0025] For simplicity, system <b>100</b> is shown to include one base station <b>104</b> in communication with two mobile stations <b>106</b>. It is common to find cellular systems including multiple base stations <b>104</b>. It also common for multiple cellular systems to interact with each other as well as the Public Switched Telephone Network (PSTN) for voice calls, and with one or more Packet Data Service Nodes (PDSNs) for data communications and connectivity with the Internet (details not shown).

[0026] The base station and its coverage area are often collectively referred to as a “cell”. In IS-95 systems, a cell may include one or more sectors. In the W-CDMA specification, each sector of a base station and the sector's coverage area is referred to as a cell. As used herein, the term base station may be used interchangeably with the terms access point or Node B. The term mobile station may be used interchangeably with the terms User Equipment (UE), subscriber unit, subscriber station, access terminal, remote terminal, or other corresponding terms known in the art. The term mobile station encompasses fixed wireless applications.

[0027] Depending on the system being implemented, each mobile station <b>106</b> may communicate with one (or possibly more) base stations <b>104</b> on the forward link at any given moment, and may communicate with one or more base stations on the reverse link depending on whether or not the mobile station is in soft handoff. The forward link (i.e., downlink) refers to transmission from the base station to the mobile station, and the reverse link (i.e., uplink) refers to transmission from the mobile station to the base station.

[0028] For clarity, the examples used in describing this invention may assume base stations as the originator of signals and mobile stations as receivers and acquirers of those signals, i.e. signals on the forward link. Those skilled in the art will understand that mobile stations as well as base stations may be equipped to transmit data as described herein and the aspects of the present invention apply in those situations as well. The word “exemplary” is used exclusively herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0029] Base station <b>104</b> comprises a Base Station Controller (BSC) <b>110</b> communicating with one or more Base-station Transceiver Subsystems (BTS) <b>112</b>. A mobile station <b>106</b> communicates with one or more BSCs <b>110</b> via a wireless connection with one or more BTSs <b>120</b>. In this example, BSC <b>110</b> is connected with BTS <b>120</b>A and <b>120</b>B. Mobile station <b>106</b>B is communicating with BSC <b>110</b> via a wireless connection with BTS <b>120</b>A. Mobile station <b>106</b>C communicates with BSC <b>110</b> through BTS <b>120</b>B.

[0030] Mobile station <b>106</b>A is connected to mobile station <b>106</b>B with a wired link. Any of the various wired standards known in the art for connecting devices may be deployed. Mobile station <b>106</b>A may communicate with base station <b>104</b> via its connection to mobile station <b>106</b>B and the wireless connection between <b>106</b>B and BTS <b>120</b>A. Alternatively, mobile station <b>106</b>B may be used for communication while emulating mobile station <b>106</b>A using data transferred on the wired link between mobile stations <b>106</b>A and <b>106</b>B. These procedures will be described further below.

[0031] Similarly, mobile station <b>106</b>D is connected with mobile station <b>106</b>C via a wireless link. In the exemplary embodiment, this wireless link is a link supporting the BLUETOOTH Specification, such as version 1.1, but other wireless links may be supported. Mobile station <b>106</b>D may communicate with base station <b>104</b> via its connection to mobile station <b>106</b>C and the wireless connection between <b>106</b>C and BTS <b>120</b>B. Alternatively, mobile station <b>106</b>C may be used for communication while emulating mobile station <b>106</b>D using data transferred on the wireless link between mobile stations <b>106</b>C and <b>106</b>D. Again, these procedures will be described further below.

[0032] The wired or wireless links between two mobile stations <b>106</b> are examples of local links which may be used by one mobile station to access a wide area network, such as a cellular system, through another mobile station, or for one mobile station to emulate another mobile station while accessing the wide area network. The mobile stations <b>106</b> used for accessing the wide area network will support at least the standard used by base station <b>104</b>, and may support a variety of other standards. In the example of FIG. 1, mobile stations <b>106</b>B and <b>106</b>C support the communication standard deployed by base station <b>104</b>. Mobile stations <b>106</b>A and <b>106</b>D may or may not support the communication standard deployed in base station <b>104</b>.

[0033] For example, mobile station <b>106</b>C may be a car phone owned by a user. The user may also own a handheld mobile phone <b>106</b>D. The user may want the handheld mobile phone <b>106</b>D to connect with the car phone <b>106</b>C, so that certain features of the car phone, such as handsfree operation or support for a desired data capability are available while driving, and yet the phone number and service contract of the handheld mobile phone <b>106</b>D allow others to reach the user and dictate the terms of service, respectively. In the exemplary embodiment, the local link between mobile stations <b>106</b>C and <b>106</b>D is a link supporting the BLUETOOTH Specification, such as version 1.1, so the two mobile stations must merely come in proximity to each other. The user needn't connect any wires or transfer any components, such as an R-UIM card. In this example, both mobile phones <b>106</b>C and <b>106</b>D may be capable of communicating with base station <b>104</b>, yet the user has reason to connect with the wide area network, that is, cellular system <b>100</b>, with mobile station <b>106</b>C.

[0034] As another example, mobile station <b>106</b>D may not support the communication standard deployed by base station <b>104</b>. The user of <b>106</b>D may have traveled to a region with an incompatible cellular network, for example. That user may rent a mobile phone <b>106</b>C that does operate on cellular network <b>100</b>. The user may then access system <b>100</b> with the rented phone <b>106</b>C while remaining accessible at the phone number assigned to mobile station <b>106</b>D and operating under the user's existing service contract. As before, the two mobile stations need only come within a certain distance to connect a link supporting the BLUETOOTH Specification or other wireless link.

[0035] Wireless connections between various base stations <b>104</b> and mobile stations <b>106</b> are established using an Authentication, Authorization, and Accounting (AAA) server <b>130</b>. AAA server <b>130</b> authorizes of a mobile station <b>106</b> by verifying that the mobile station identification corresponds to a valid subscriber. In addition, various parameters associated with an authorized subscriber may be returned to a network, such as terms of service, features supported, roaming capabilities, and the like. In a typical cellular system, a subscriber is authenticated using an authentication protocol with a shared secret, password, or key corresponding to the subscriber information stored in AAA server <b>130</b>. A variety of authentication protocols are known in the art, and any such scheme may be deployed within the scope of the present invention.

[0036] Although a single AAA server <b>130</b> is shown, those of skill in the art will recognize that AAA server <b>130</b> may represent a network of AAA servers and/or proxy AAA servers. An AAA server <b>130</b> in one network may receive a request for authentication of a mobile station that is not known by that AAA server. The AAA server may access one or more additional servers with the request, until the AAA server containing the information corresponding to the mobile station is found.

[0037] Those of skill in the art will recognize that an AAA server deployed for authorization of a mobile station is exemplary only. Some IS-2000 packet services use an AAA server, as does IS-856. Other systems, such as IS-95 and IS-2000 systems, use a Home Location Register/Authentication Center (HLR/AC) for authentication, authorization, and to support roaming information/service profile download. The term AM server, as used herein, may be used interchangeably with HLR/AC, as well as any other device for providing authentication, authorization, service profile, and similar services.

[0038]FIG. 2 depicts a portion of a mobile station <b>106</b>. Signals are received with antenna <b>210</b> and delivered to receiver <b>250</b>. Receiver <b>250</b> performs processing according to one or more wireless system standards, such as the cellular standards listed above. Receiver <b>250</b> performs various processing such as Radio Frequency (RF) to baseband conversion, amplification, analog to digital conversion, filtering, demodulation, deinterleaving, decoding, and the like. Various techniques for receiving are known in the art. Data received may be transmitted to processor <b>240</b> for use in voice or data communications. Additional components for supporting voice communications or data applications are not shown.

[0039] Received data is also delivered to message decoder <b>260</b>. Message decoder <b>260</b> decodes various messages used in setting up, maintaining and tearing down a call on a cellular network (or other wide area network). Various call setup procedures and their related messages are known in the art. Examples include paging messages from base station <b>104</b>, or messages responding to access requests messages from mobile station <b>106</b>. Authentication procedures, involving both base station <b>104</b> and AAA server <b>130</b> may produce messages for delivery to mobile station <b>106</b> and subsequent decoding in message decoder <b>260</b>. The various messages are delivered to processor <b>240</b>. Those of skill in the art will recognize that some or all of the procedures carried out in message decoder <b>260</b> and/or receiver <b>250</b> may be performed in processor <b>240</b>.

[0040] Processor <b>240</b> directs message generator <b>230</b> to generate various messages used in setting up, maintaining and tearing down a call on a cellular network (or other wide area network). Various call setup procedures and their related messages are known in the art. Examples include access requests to base station <b>104</b>, or messages responding to paging messages from base station <b>104</b>. Authentication procedures, involving both base station <b>104</b> and AAA server <b>130</b> may require response messages for delivery to base station <b>104</b>. In addition, a mobile station may send messages to register with a base station and remain in an idle state until a call is received or initiated.

[0041] The messages are delivered to transmitter <b>220</b> for formatting according to one or more communication standards supported by mobile station <b>106</b>. Procedures in transmitter <b>220</b> may include vocoding, encoding, interleaving, modulation, filtering, amplification, digital to analog conversion, modulation, and the like. In addition, data for use in voice communication or a data application may be delivered to transmitter <b>220</b> from processor <b>240</b>. Signals generated in transmitter <b>220</b> are delivered for transmission on antenna <b>210</b>. Those of skill in the art will recognize that some or all of the procedures carried out in message generator <b>230</b> and/or transmitter <b>220</b> may be performed in processor <b>240</b>.

[0042] Some mobile stations <b>106</b> may include a local wireless receiver/transmitter <b>280</b> for receiving and transmitting data on a local wireless link. In the exemplary embodiment, local wireless receiver/transmitter <b>280</b> transmits and receives formatted data consistent with the BLUETOOTH Specification. As shown in FIG. 2, local wireless receiver/transmitter <b>280</b> shares antenna <b>210</b>. Alternate embodiments may deploy a second antenna for use by local wireless receiver/transmitter <b>280</b>. Two mobile stations <b>106</b>, each equipped with a local wireless receiver/transmitter <b>280</b>, may establish a local wireless link such as that described between mobile stations <b>106</b>C and <b>106</b>D in FIG. 1. Note that the communication standards supported by transmitter <b>220</b>, receiver <b>250</b>, message generator <b>230</b>, and message decoder <b>260</b>, described above, need not be identical or overlapping between two mobile stations <b>106</b>. In some situations, described above, a first mobile station <b>106</b> may utilize the wireless link processed with local wireless receiver/transmitter <b>280</b> to access a cellular or other wide area network via a second mobile station <b>106</b>, wherein the network would not be accessible using standards supported by the first mobile station <b>106</b>. Local wireless receiver/transmitter <b>280</b> connects with processor <b>240</b> for processing the local wireless link.

[0043] In addition to or in lieu of local wireless receiver/transmitter <b>280</b>, a mobile station <b>106</b> may include a link interface <b>290</b> for wired connection with another wireless communication device, such as another mobile station <b>106</b>. The wired connection may be used in similar fashion as just described with respect to the local wireless communication link. Link interface <b>290</b> connects with processor <b>240</b> for processing the local wired link.

[0044] Processor <b>240</b> may be a general purpose microprocessor, a Digital Signal Processor (DSP), or a special purpose processor. Processor <b>240</b> may perform some or all of the functions of message generator <b>230</b>, transmitter <b>220</b>, message decoder <b>260</b>, receiver <b>250</b>, local wireless receiver/transmitter <b>280</b>, or link interface <b>290</b>, and may be connected with special purpose hardware to assist in these tasks (details not shown). Data or voice applications may be external to mobile station <b>106</b>, such as an externally connected laptop computer, may run on an additional processor within mobile station <b>106</b> (not shown), or may run on processor <b>240</b> itself. Processor <b>240</b> may have embedded memory, or be connected to a memory (not shown) for storing instructions to perform various procedures and methods, detailed further below.

[0045] A mobile station <b>106</b> may include an identity module <b>270</b> for storing identity and authentication information (such as passwords, shared secret information, and the like). The identity information may be accessed and incorporated in various messages generated or received for registration, authentication, call setup, and the like. The identity module <b>270</b> may be part of processor <b>240</b>, or incorporated in non-volatile memory attached thereto (not shown). In some cases both mobile stations <b>106</b> communicating over a local link, such as <b>106</b>C and <b>106</b>D, or <b>106</b>A and <b>106</b>B, shown in FIG. 1, will also support removable identity modules, such as an R-UIM interface. The local link, use of which is described in further detail below, may be used to alleviate the requirement of physically moving the R-UIM card from one mobile station to another. Note that the identity information stored in any of the mobile stations <b>106</b> need not be in a removable module.

[0046] During a communication session, a variety of parameters may be updated. Some of these parameters are stored in identity module <b>270</b>, and may be overwritten in response to messages directed to the mobile station. For example, a service programming code may be used to lock or unlock the contents of non-volatile memory, a portion of which may be in identity module <b>270</b> or embedded or connected with processor <b>240</b>. When the non-volatile memory is locked, information stored therein is not modified. When unlocked, the non-volatile memory may be updated. Another example includes authentication data. For example, shared secret data may be modified, which may be used in authentication and to generate encryption keys. During non-emulation communication with a mobile station <b>106</b>, these parameters and similar information may be updated directly in the course of the communication session. When a first mobile station <b>106</b> is emulated by a second mobile station, as described herein, these parameters may be synchronized over the local link so that the first mobile station may subsequently access a wide area network directly using the latest set of parameters.

[0047] Various mobile stations <b>106</b>, such as those shown in FIG. 1, need not be configured with identical sets of components. For example, some mobile stations may be equipped for local wireless links only, or local wired links only, or both. As stated above, the set of supported standards for communicating on a wide area network <b>100</b>, such as a cellular network, may be unique for each mobile station <b>106</b>. One useful configuration includes a first mobile station <b>106</b> connecting with a second mobile station <b>106</b> with a wired or wireless local link to access a wide area network using a communication standard not supported by the first mobile station <b>106</b>.

[0048] Techniques for emulating a first wireless communication device with a second wireless communication device on a wide are network using a local link, of which FIGS. <b>3</b>-<b>5</b>, described below, are examples. The synchronization procedures disclosed herein may be applied to these exemplary embodiments, as well as any other embodiments of a second device emulating a first device over a local link.

[0049]FIG. 3 depicts a flowchart of an embodiment of a method for emulating a first wireless communication device with a second. The wireless communication devices <b>106</b> shown in FIG. 1 and further detailed in FIG. 2 are examples. The process begins in step <b>310</b>, where the first device, referred to as device A, is connected with the second device, referred to as device B, using a local link such as those described above. As used herein, device A will be the “emulated device,” and device B will be the “emulating device.” In the exemplary embodiment, a wireless local link such as one supporting the BLUETOOTH Specification is deployed. Any of a variety of local links, wired or wireless, may be deployed in alternate embodiments. A local wireless receiver/transmitter <b>280</b>, described above, may be used in both device A and device B to communicate if a wireless local link is deployed. A link interface <b>290</b>, described above, may be used in both device A and device B to communicate if a wired local link is deployed.

[0050] In this example, when emulation is performed, device B will be used to access the wide area network. In the exemplary embodiment, the wide area network includes a wireless communication system such as the cellular systems described above. Proceed to step <b>320</b>.

[0051] In step <b>320</b>, identity information for device A, the device to be emulated, is exchanged between device A and device B on the local link. An identity module <b>270</b> may be deployed in device A for storing the identity information, to be accessed for transmission to device B during emulation, or for use in call setup by device A when emulation is not desired (this alternative is detailed further below). In the exemplary embodiment, identity module <b>270</b> is an R-UIM card. Proceed to step <b>330</b>.

[0052] In step <b>330</b>, device B accesses the wide area network using the identity information from device A, transferred on the local link in step <b>320</b>. Various procedures for call setup according to various communication standards are known in the art, as well as registration, authentication, and similar procedures used in accessing a cellular system and/or wide area network. Messages for performing these procedures may be generated and decoded in a message generator <b>230</b> and a message decoder <b>260</b>, respectively, deployed in device B. (Device A may be similarly equipped, but the wide area network is accessed through the components of device B when device A is being emulated.) Note that steps <b>320</b> and <b>330</b> may occur simultaneously. Note further that identity information may be accessed a number of times during authentication and call setup. The identity information exchange step may be performed once initially, with all required information stored on device B, for access as required. Alternatively, identity information may be retrieved in one or more accesses using the local link established in step <b>310</b>. Once the wide area network has been accessed and a communication link has been successfully set up, voice or data communications may proceed between device B and the wide area network, utilizing the identity and associated service contract features of device A, while using device B and its capabilities for communication with the wide area network. The emulation of device A in step <b>330</b> may stop once the voice or data application terminates, or it may remain in place while numerous calls are initiated or received, terminating at the user's request. Device B may emulate device A in an idle mode, waiting for the user to initiate a voice or data call, or for a call directed to device A to be received.

[0053] A user, equipped with both devices A and B, may make a determination to use either device as the access terminal. For example, a laptop computer equipped with a cellular PC card, device A, may establish a wireless local link with a mobile station in an automobile, device B. The impetus for such a connection may be that the automobile's mobile station supports the cellular system in the geographical area while the PC card in the notebook computer supports only other cellular systems. Or, the automobile's mobile station provides the benefits of a larger supply of power, or supports higher data rates. In situations such as these, device A is acting as the access terminal. For example, a data application may be running on the notebook computer, or device A, and so device A may direct device B, the mobile station in the automobile, to access the network, emulate device A, and transfer communication data across the local link to device A. Or, a user may prefer to talk using one handheld mobile telephone, device A, because it has certain features, such as programmed contact lists, that the user would like to use. A rented mobile telephone, device B, provides network access due to its support of the cellular system provided in the geographical area. Thus, device A is the access terminal and device B acts as a conduit in the connection between device A and the wide area network. An embodiment of a method for communicating with device A while emulating device A with device B on a wide area network is described below with respect to FIG. 4.

[0054] Alternatively, there may be situations where device B, the emulating device, is to be the access terminal. For example, if a user brings a handheld mobile telephone, device A, into an automobile equipped with a mobile station, device B, the user may wish to use the automobile's mobile station for communication. It may be that device B is equipped with a handsfree system that makes conversing on device B preferable while driving. Or, in contrast to the example of two handheld mobile telephones described above, the user may elect to talk using device B rather than device A. An embodiment of a method for communicating with device B on a wide area network while emulating device A is described below with respect to FIG. 5.

[0055]FIG. 4 depicts an embodiment of a method for communicating with device A while emulating it with device B on a wide area network. This method is applicable where device A is to act as the access terminal, as described above. The process starts in step <b>410</b>, where it is determined to communicate with device A, for any reason, including those examples given earlier. Proceed to decision block <b>420</b>.

[0056] In decision block <b>420</b>, if an emulating device, that is, device B, is to be used, proceed to step <b>430</b>. If not, then proceed to step <b>470</b>. In step <b>470</b>, device A performs call setup with the wide area network, and the process proceeds to step <b>480</b> where data or voice communication flows between device A and the wide area network.

[0057] In step <b>430</b>, device A signals device B over a local link, such as those described above, to access the wide area network. Proceed to step <b>440</b>. In step <b>440</b>, device B accesses a base station supporting the communication standard provided in the geographical region. The access may be for a voice or data connection, or simply to register with the wide area network. (Alternatively, the link may remain idle until device A initiates a call or a call directed to device A is received at device B.) A variety of call setup and registration procedures for various communication standards, examples of which are given above, are known in the art. Proceed to step <b>450</b>. In step <b>450</b>, device B receives authentication information, or any other information required for emulation, from the identity module of device A over the local link. Steps <b>440</b> and <b>450</b> may occur in parallel, and information from device A may be accessed in one step or in segments during call setup or registration. Proceed to step <b>460</b>. In step <b>460</b>, data or voice communication flows between device A and device B over the local link. If device B was the access terminal, then only the identity and/or authentication information would be transferred over the local link, and the voice or data communication would terminate at device B. In this case, the local link is used to transfer traffic data between device A and B as well. Proceed to step <b>480</b>, where data and voice communication flows between device A and the wide area network, using the link between device B and the wide area network and the local link between device A and device B. The process may terminate when the voice or data call terminates, or may repeat for numerous received or initiated calls or data sessions.

[0058]FIG. 5 depicts an embodiment of a method for communicating with device B on a wide area network while emulating device A. This method is applicable where device B is to act as the access terminal, as described above. The process starts in step <b>510</b>, where it is determined to communicate with device B, for any reason, including those examples given earlier. Proceed to decision block <b>520</b>.

[0059] In decision block <b>520</b>, if device B is to emulate device A, proceed to step <b>530</b>. In step <b>530</b>, receive identity information from device A on a local link. This may be accomplished in a variety of ways, including those examples given above. In decision block <b>520</b>, if device B is not to emulate device A, proceed to step <b>540</b>. In step <b>540</b>, use the device B identity information. This may be stored in an identity module <b>270</b> deployed in device B, as described above with respect to FIG. 2. From either step <b>530</b> or <b>540</b>, proceed to step <b>550</b>.

[0060] In step <b>550</b>, device B performs call setup or registration, using device B identity information or emulating device A using device A identity information. Either step <b>530</b> or step <b>540</b> may be performed in parallel with step <b>550</b>. Step <b>530</b> identity information may be exchanged at one time, or in segments during call setup or registration in step <b>550</b>. Proceed to step <b>560</b>. In step <b>560</b>, device B accesses the wide area network. As described earlier, this may entail accessing a cellular network solely, or the call set up in step <b>550</b> may be connected with the PSTN for a voice call or another wide area network, such as the Internet or a corporate intranet, via a PDSN. Steps <b>560</b> and <b>550</b> may be combined in a single step, depending on the voice or data application. Proceed to step <b>570</b>. In step <b>570</b>, data or voice communication flows between device B and the wide area network. The process may terminate when the voice or data call terminates, or may repeat for numerous received or initiated calls or data sessions.

[0061]FIG. 6 is a state diagram depicting an embodiment of a method for synchronizing an emulated device over a local link. Begin in the start state <b>610</b>. If two devices, device A and device B, are connected with a local link, transition to the devices connected state <b>620</b>. From state <b>620</b>, if emulation is requested, then device B may access the wide area network emulating device A, using a method such as those described above. On emulation request, device B transitions to state <b>630</b>, where device B monitors the wide area network for information directed to device A. If information is received, transition to state <b>640</b> to process the information. Some information directed to device A will be used for communication, such as an incoming call, or a response to a network access request. Information that does not need to be updated in device A for synchronization may be used by device B as necessary. In that case, transition back to state <b>630</b> to continue monitoring for device A information. If the device A information received in state <b>630</b> needs to be synchronized, examples of which are given above, transition from state <b>640</b> to state <b>650</b> to synchronize device A. In state <b>650</b>, device B may signal device A over the local link that an update to information stored in non-volatile memory, such as the identity module <b>270</b>, is required. The information may then be transmitted over the local link to device A for synchronization. Once the transmission and synchronization are complete, transition back to state <b>630</b> to continue monitoring for device A information. At any time, emulation may be terminated, thus returning to state <b>620</b>, the devices connected state. The devices may remain connected until a new emulation session is initiated, resulting in a transition to state <b>630</b>. Or, the local link may be terminated, the devices disconnected, and a return to state <b>610</b> would be in order.

[0062] From state <b>610</b>, in which device A and device B are disconnected, or from state <b>620</b>, where the local link is established, a transition to state <b>660</b> may be made when device A is to be used to access the wide area network directly. The access will use information stored in non-volatile memory, such as identity module <b>270</b>, to make the connection to the wide area network. Thus, the information used will be as updated during any prior emulation, since synchronization of such information took place in state <b>650</b>. When the wide area communication is terminated, a transition to state <b>610</b> or <b>620</b> is appropriate depending on whether device A and device B are disconnected or connected, respectively.

[0063]FIG. 7 depicts a flowchart of an embodiment of a method for synchronizing an emulated device over a local link. The process begins with decision block <b>705</b>, where it is determined whether a first device, device A, should be emulated using a second device, device B. If not, then proceed to decision block <b>755</b>, to determine whether to access a wide area network. Decision block <b>755</b> is detailed further below.

[0064] If emulation is desired in decision block <b>705</b>, proceed to step <b>710</b>. In step <b>710</b>, device A and device B are connected using a local link, as described above. Proceed to step <b>715</b>, where device B accesses the wide area network emulating device A, various techniques for which are described above. Proceed to step <b>720</b>. In addition to other emulation tasks, such as performing voice or data communication, or remaining in an idle mode awaiting an initiated or received call, device B in step <b>720</b> monitors the wide area network for transmissions directed to device A. Proceed to decision block <b>725</b>. If, in decision block <b>725</b>, device A information is received at device B, proceed to decision block <b>730</b>. If not, proceed to decision block <b>750</b>. In decision block <b>750</b>, if emulation is to continue, loop back to step <b>720</b> to continue monitoring for device A transmissions. While monitoring is desired, the process may remain in the loop formed by step <b>720</b> and decision blocks <b>725</b> and <b>750</b>.

[0065] If device A information is received in decision block <b>725</b>, proceed to decision block <b>730</b>, to determine whether the received information should be synchronized in device A. Some transmissions directed to device A, and received at device B, do not need to be synchronized. For example, messages or traffic used to carry out voice or data transmission when device B is the access terminal, as described above, only require processing in device B. If device A is the access terminal, procedures described above for transferring traffic over the local link may be sufficient when device A synchronization is not needed. When synchronization is not required, the process loops back to step <b>720</b> to continue monitoring, as described above. An alternative embodiment may proceed from decision block <b>730</b> to decision block <b>750</b> to determined whether to continue emulation before proceeding to step <b>720</b>. In either embodiment, the process may form a loop to continue monitoring for device A information for as long as is desired.

[0066] In decision block <b>730</b>, device A information requiring synchronization is received, proceed to step <b>735</b>. In step <b>735</b>, the synchronization information is directed to device A over the local link. Those of skill in the art will recognize various techniques for signaling and transfer between device A and device B, depending on the local link deployed. Proceed to step <b>740</b>. In step <b>740</b>, the synchronization information may be stored in device A. The synchronization information may be further processed by device A prior to storage. The resultant information may be stored in non-volatile memory, such as in identity module <b>270</b>, or other memory deployed in device A. Proceed to decision block <b>750</b>. As before, in decision block <b>750</b>, if emulation is to continue, the process loops back to <b>720</b>. Device A may continue to be synchronized as applicable. If emulation is not continued, in decision block <b>750</b>, proceed to decision block <b>755</b>.

[0067] In decision block <b>755</b>, device A may connect directly to the wide area network, if desired. Note that that this block may also be entered from decision block <b>705</b> when emulation was not desired. If it is not desired to connect directly with device A, the process terminates. The process may be repeated as necessary. Note that, at this point, device A has remained current, or synchronized, with updates to various parameters or settings exchanged with the wide area network, even if device B was used for communication using device A identity information. If a direct connection using device A is desired in decision block <b>755</b>, proceed to step <b>760</b> to access the wide area network with device A. The access will be made with the benefit of synchronized information, whether or not prior emulation took place. The process may terminate after device A terminates communication, and may be repeated as necessary for future direct or emulated accesses, as just described.

[0068] The techniques described above may also be deployed using multiple clients or multiple servers. For example, a mobile station <b>106</b> may be a client on more than one local link, such as that specified by the BLUETOOTH Specification. The methods described may be deployed to allow the client mobile station, acting as device A, to access one or more wide area networks with a number of servers, acting as device B, where each server connects with the wide area network for a portion of time. Similarly, multiple client mobile stations, each acting as a device A, may be connected to a server, or device B. The clients may essentially time-share access to the wide area network through the server, device B. The clients may coordinate with the server such that the server accesses the wide area network emulating one client at a time. The client information for each emulated client may be transmitted over the local link as appropriate during the time period that the server is emulating a particular client. Those of skill in the art will readily apply the techniques disclosed herein to these multi-client or multi-server applications.

[0069] Those of skill in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0070] Those of skill will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

[0071] The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0072] The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor may read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

[0073] The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.