WO2007076236A2

WO2007076236A2 - Method for correcting a mobile subscriber identification

Info

Publication number: WO2007076236A2
Application number: PCT/US2006/061841
Authority: WO
Inventors: Yong Chen; Jing Chen; Chong-Sheng Wei
Original assignee: Motorola Inc.
Priority date: 2005-12-20
Filing date: 2006-12-11
Publication date: 2007-07-05
Also published as: CN1988723A; WO2007076236A3

Abstract

A method for correcting a mobile subscriber identification is useful for improving Quality of Service (QoS). The method comprises receiving from a mobile device at a Device Management (DM) server a device management message including a first subscriber identification that identifies the mobile device (step 510). The first subscriber identification is then compared with a second subscriber identification, which second subscriber identification is stored in a memory associated with the DM server (step 515). The DM server then transmits to the mobile device a status code indicating a mismatch between the first and second subscriber identifications (step 520).

Description

METHOD FOR CORRECTING A MOBILE SUBSCRIBER IDENTIFICATION

FIELD OF THE INVENTION

The present invention relates generally to registering mobile devices with service providers. In particular, the invention relates to correcting a mobile subscriber identification at a Device Management (DM) server.

BACKGROUND OF THE INVENTION

Subscribers of mobile telephone services generally demand a high level of convenience from mobile service providers. Advanced mobile phone features such as international roaming, Over-The-Air (OTA) provisioning, and interoperability between different types of handsets are therefore increasingly common.

In the early 1990's GSM networks began using Subscriber Identity Module (SIM) cards to provide a convenient authentication process for subscribers. More recently, Removable User Identity Modules (RUIMs) have become available that enable international roaming across CDMA and GSM networks, and enable users to upgrade their handsets without needing to reprogram features such as their personal identification information and their phone/address book. RUIM smart cards are generally small plastic cards that include an embedded computer chip for storing information such as security data, subscription data, phone/address book data, network settings and other information related to specific service features. RUIMs are generally removably connected to a phone using a slot similar to that used by a SIM card.

International travelers can thus now perform "plastic roaming" across networks. For example a subscriber may roam from a CDMA network to a GSM network by simply removing the RUIM from a CDMA phone and placing the RUIM in a GSM phone. The subscriber's network data and personal data are then immediately recognizable by the new network.

Mobile subscribers also transfer identity modules between handsets for other reasons. For example, a subscriber may own multiple mobile phones that each have unique features, such as different camera or Bluetooth options. The subscriber can then choose to carry a particular phone that is best suited for particular circumstances. Also, subscribers often switch their identity module from a first phone to a second phone when a low battery condition occurs in the first phone.

Data related to mobile phones, such as application data, can be updated using Over-the-Air (OTA) provisioning. OTA provisioning is generally more convenient for subscribers than provisioning that requires physical access to a phone. OTA provisioning further enables both push and pull provisioning. Push provisioning is where data is automatically uploaded to a phone with our without the knowledge of the phone user. Pull provisioning enables phone subscribers to update selected phone features at their convenience. For example subscribers may navigate to a selected web site using an internet browser feature on their phone and then wirelessly download phone provisioning data from the site to their phone. Firmware Over-The-Air (FOTA) provisioning is a relatively new technology that enables device manufacturers and/or service providers to update a mobile device's firmware using wireless communications. Wireless provisioning of firmware using FOTA techniques has many advantages including improved time to market, faster deployment of security patches and anti-virus updates, reduced recall and service costs, faster adoption of new applications, and improved customer satisfaction.

The increased use of multiple wireless handsets by individual users, often through removal and substitution of SIM or RUIM cards, and the increased use of OTA provisioning, requires service providers maintain an updated and accurate match between a particular subscriber and a particular mobile device.

SUMMARY OF THE INVENTION

According to one aspect, the invention is a method for correcting a mobile subscriber identification at a Device Management (DM) server. The method comprises receiving from a mobile device at the DM server a device management message including a first subscriber identification that identifies the mobile device. The first subscriber identification is compared with a second subscriber identification, which second subscriber identification is stored in a memory associated with the DM server. The DM server then transmits to the mobile device a status code indicating a mismatch between the first and second subscriber identifications. Thus DM servers that maintain incorrect subscriber identifications, such as incorrect Mobile Station International Subscriber Directory Number (MSISDN)/International Mobile Equipment Identifier (IMEI) pairs, are able to readily correct the identifications so as not to disrupt service to network subscribers. Subscribers therefore receive a higher network Quality of Service (QoS), particularly when transferring an identity module between multiple wireless devices.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the invention may be readily understood and put into practical effect, reference now will be made to exemplary embodiments as illustrated with reference to the accompanying figures, wherein like reference numbers refer to identical or functionally similar elements throughout the separate views. The figures together with a detailed description below, are incorporated in and form, part of the specification, and serve to further illustrate the embodiments and explain various principles and advantages, in accordance with the present invention, where:

FIG. 1 is a schematic diagram illustrating a mobile device in the form of a radio telephone that performs a method of the present invention;

FIG. 2 is a message sequence chart illustrating a problem that arises under the prior art when a single identity module is used in multiple wireless devices;

FIG. 3 is a schematic diagram illustrating a format of a conventional general notification trigger message specified for a SyncML Device Management Notification Initiation package; FIG. 4 is a message sequence chart illustrating a process for identifying and correcting a mismatch between subscriber identifications, according to an embodiment of the present invention; and

FIG. 5 is a general flow diagram illustrating a method for correcting a mobile subscriber identification, according to an embodiment of the present invention.

Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

DETAILED DESCRIPTION

Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to methods for correcting a mobile subscriber identification. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention, so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

In this document, relational terms such as left and right, first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "comprises a . . ." does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

Referring to FIG. 1, a schematic diagram illustrates a mobile device in the form of a radio telephone 100 that performs a method of the present invention. The telephone 100 comprises a radio frequency communications unit 102 coupled to be in communication with a processor 103. The telephone 100 also has a keypad 106 and a display screen 105 coupled to be in communication with the processor 103. As will be apparent to a person skilled in the art, screen 105 may be a touch screen thereby making the keypad 106 optional.

The processor 103 includes an encoder/decoder 111 with an associated code Read Only Memory (ROM) 112 storing data for encoding and decoding voice or other signals that may be transmitted or received by the radio telephone 100. The processor 103 also includes a micro-processor 113 coupled, by a common data and address bus 117, to the encoder/decoder 111, a character Read Only Memory (ROM) 114, a Random Access Memory (RAM) 104, static programmable memory 116 and a SIM interface 118. The static programmable memory 116 and a SIM operatively coupled to the STM interface 1 18 each can store, amongst other things, selected incoming text messages and a Telephone Number Database TND (phonebook) comprising a number field for telephone numbers and a name field for identifiers associated with one of the numbers in the name field. For instance, one entry in the Telephone Number Database TND may be 91999111111 (entered in the number field) with an associated identifier "Steven C! at work" in the name field.

The micro-processor 113 has ports for coupling to the keypad 106 and screen 105 and an alert 115 that typically contains an alert speaker, vibrator motor and associated drivers. Also, micro-processor 113 has ports for coupling to a microphone 135 and communications speaker 140. The character Read only memory 114 stores code for decoding or encoding text messages that may be received by the communications unit 102. In this embodiment the character Read Only Memory 114 also stores operating code (OC) for the micro-processor 113 and code for performing functions associated with the radio telephone 100.

The radio frequency communications unit 102 is a combined receiver and transmitter having a common antenna 107. The communications unit 102 has a transceiver 108 coupled to antenna 107 via a radio frequency amplifier 109. The transceiver 108 is also coupled to a combined modulator/demodulator 110 that couples the communications unit 102 to the processor 103.

Referring to FIG. 2, a message sequence chart 200 illustrates a problem that arises under the prior art when a single identity module is used in multiple wireless devices. First, at step 1 a Subscriber Identity Module (SIM) card 205 is inserted into a phone "A" 210 that is identical to the radio telephone 100 described above. At step 2 the phone "A" 210 transmits a registration message to a Device Management (DM) server 215, which at step 3 creates a record of a Mobile Station International Subscriber Directory Number (MSISDN) and International Mobile Equipment Identifier (IMEI) pair. The MSISDN/IMEI pair then uniquely identifies a particular subscriber associated with the SIM card 205 and the physical phone "A" 210 in which the SIM card 205 resides. At step 4 the server 215 then transmits an acknowledgement to the phone "A" 210, and at step 5 the phone "A" 210 records an International Mobile Subscriber Identity (IMSI) associated with the SIM card 205.

Next, assume that the subscriber of the SIM card 205 chooses to switch handsets, for example to obtain access to a headset Bluetooth feature, and decides to change from phone "A" 210 to a phone "B" 220. At step 6 the SIM card 205 is thus removed from phone "A" 210, and at step 7 the SIM card 205 is inserted into phone "B" 220. Similar to steps 2 and 3, at steps 8 and 9 the phone "B" 220 transmits a registration message to the DM server 215, which then creates a new record of the MSISDN/IMEI pair that now associates the SIM card 205 with phone "B" 220, instead of phone "A" 210.

If the subscriber later decides to switch back to using phone "A" 210, at steps 10 and 11 the SIM card 205 is removed from phone "B" 220 and inserted back into phone "A" 210. However, the phone "A" 210 now recognizes the SIM card 205 as having the same IMSI as that saved at step 5. Therefore the phone "A" 210 assumes that the MSISDN/IMEI pair associated with the SIM card 205 and the phone "A" 210 has not changed, and so the phone "A" 210 does not transmit a new registration message to the DM server 215. At step 12, if the DM server 215 then sends a session notification message to the subscriber, for example for DM notification or Firmware Over-The-Air (FOTA) provisioning purposes, any responses transmitted by the phone "A" 210 will cause the DM notification or FOTA process to fail. That is because a mismatch will occur between the MSISDN/IMEI pair maintained at the DM server 215 and the MSISDN/IMEI pair maintained at the phone "A" 210.

Referring to FIG. 3, a schematic diagram illustrates a format of a conventional general notification trigger message 300 specified for a SyncML Device Management Notification Initiation package, or a "package 0". The notification trigger message 300 is divided into three primary fields: a digest field 305 that specifies an MD5 Digest authentication, a trigger-hdr field 310 that specifies a header of the trigger message 300, and a trigger-body field 315 that specifies a body of the trigger message 300. Various sub-fields 320 are included within the primary fields, but none of the sub-fields 320 identify a particular physical device, such as by providing an IMEI, currently associated at the DM server 215 with a particular subscriber.

In the example shown in FIG. 2, generally the phone "A" 210 is not able to recognize the MSISDN/IMEI mismatch problem at step 12, because conventional session notification messages, such as notification trigger messages, sent from the DM server 215 do not identify the current MSISDN/IMEI pair that is stored at the DM server 215. As described below, the present invention provides a method for communicating such a mismatch to the phone "A" 210.

Referring to FIG. 4, a message sequence chart 400 illustrates a process for identifying and correcting a mismatch between subscriber identifications, according to an embodiment of the present invention. As described above concerning step 12 of the message sequence chart 200, assume here that the DM server 215 maintains an MSISDN/IMEI pair that incorrectly associates the current SlM card 205 of phone "A" 210 with the phone "B" 220. At step 1 of the message sequence chart 400, a notification trigger message 300 included in a package 0 is transmitted from the DM server 215 to the phone "A" 210. The package 0 can be intended, for example, to initiate a SyncML server alerted management session. At step 2, the phone "A" 210 responds to the package 0 by transmitting a "package 1" back to the DM server 215. The package 1 is a device management message that includes a field or sub-field that identifies the IMEI of phone "A" 210. At step 3, the DM server 215 then checks to see whether the IMEI received in package 1 matches with the MSISDN/IMEI pair stored in a database associated with the DM server 215. If not, at step 4 the DM server 215 transmits a status code indicating a mismatch between the subscriber identifications. At step 5 the phone "A" 210 interprets the status code and recognizes the subscriber identification mismatch. Then, at step 6, the phone "A" 210 begins a process of correcting the mismatch by transmitting a new registration message to the DM server 215.

Step 1 in FIG. 4 is illustrated using a dashed line to indicate that a package 0 is not always transmitted from the DM server 215 to initiate a device management session. As known to those skilled in the art, the package 1 device management message transmitted from the phone "A" 210 is generally the second transmitted package in a device management session that is initiated by the DM server 215 using a package 0. However, client-initiated device management sessions are also common and begin with a transmission from the phone "A" 210 to the DM server 215. Such client-initiated device management sessions begin with a package 1 , such as a FOTA pull command, and no package 0 is transmitted from the DM server 215. The format of a package 1 device management message can include for example extensible Markup Language (XML) code or wireless binary XML (WBXML) code. Below is a specific example of a SyncML package 1 device management message that is used to initiate a device management session.

<Targei><LocURI>http://www.syncrnl.org/rngmt-server</LocURI></Target>

<Cred>

<Meta><Type xmlns='syncml:metinf>syncml:auth-basic</Type></Meta> <Data>QnJlY2UyOk9oQmVoYXZl</Data> <!— base64 formatting of "userid:password" — > </Cred> </SyncHdr> <SyncBody>

</SyncBody> </SyncML>

The package 1 above includes the specific IMEI of "493005100592800" that uniquely identifies a sending device such the phone "A" 210. Because the package 1 is received from a specific MSISDN, when the DM server 215 receives the package 1 it can associate an MSISDN/IMEI pair with the package 1. Thus at step 3 of the message sequence chart 400, the DM server 215 compares the subscriber identification IMEI included in package 1 with the subscriber identification IMEI that is associated, in a database of the DM server 215, with the MSISDN that transmitted the package 1. If the DM server 215 determines that there is a mismatch between the two subscriber identification IMEIs, then at step 4 the DM server 215 transmits a status code indicating a mismatch between the subscriber identifications. The status code can be transmitted to the phone "A" 210 using various formats, including for example a SyncML acknowledgment message such as the following:

<Target><LocURI>IMEI:493005100592800</LocURIx/Target> <Source><LocURI>http ://www. syncml.org/mgmt-server</LocURI></Source> </SyncHdr> <SyncBody> <Status>

<MsgRef>l</MsgRef><CmdRef>O</CmdRef><Cmd>SyncHdr</Cmd> <TargetRef>http://www.syncml.org/mgmt-server</TargetRef> <SourceRef>IMEI:493005100592800</SourceRef>

</SyncBody> </SyncML>

Here the <Data> "xxx" of <Status> identifies the status code, which can be any code that indicates the mismatch between the IMEI received in the package 1 and the IMEI stored in a memory associated with the DM server that is paired with the MSISDN associated with the package 1.

At step 5 of the message sequence chart 400, the phone "A" 210 interprets the status code and identifies the subscriber identification mismatch. Then, at step 6, the phone "A" 210 begins a process of correcting the mismatch by transmitting a new registration message to the DM server 215.

Referring to FIG. 5, a general flow diagram illustrates a method 500 for correcting a mobile subscriber identification, from the perspective of a DM server 215, according to an embodiment of the present invention. First, at step 505, the DM server 215 transmits to a mobile device a session notification message. Step 505 is shown using dashed lines to indicate that it is an optional step that is performed only when a device management session is initiated by the DM server 215. Thus step 505 is not performed during a client-initiated Over-The-Air (OTA) provisioning session, such as a DM session or FOTA session initiated by the mobile device.

At step 510, the DM server 215 receives from the mobile device a device management message including a first subscriber identification, such as an IMEI, that identifies the mobile device. As described above, the device management message can be in response to the session notification message received from the DM server 215, or the device management message can itself initiate a device management session.

At step 515, the DM server 215 compares the first subscriber identification with a second subscriber identification, where the second subscriber identification is stored in a memory associated with the DM server 215. For example, the memory can include any hard disk, database, flash or other memory operatively connected to the DM server 215 that stores an MSISDN/IMEI pair, the IMEI of which is compared with the IMEI included in the device management message. If the first subscriber identification, such as the IMEI included in the device management message, does not match the second subscriber identification, such as the IMEI stored in the memory operatively connected to the DM server 215, then at step 520 the DM server 215 transmits to the mobile device a status code indicating the mismatch between the first and second subscriber identifications. Finally, at step 525, the DM server 215 receives from the mobile device, in response to the transmitted status code, a registration message. The registration message instructs the server to update its files to associate the correct MSISDN with the IMEI that identifies the mobile device.

Advantages of the present invention therefore include improved error-free operation of mobile networks. DM servers 215 that maintain incorrect subscriber identifications are able to readily correct the identifications so as not to disrupt service to subscribers. Subscribers therefore receive a higher Quality of Service (QoS), particularly when transferring an identity module between multiple wireless devices.

The above detailed description provides an exemplary embodiment only, and is not intended to limit the scope, applicability, or configuration of the present invention. Rather, the detailed description of the exemplary embodiment provides those skilled in the art with an enabling description for implementing the exemplary embodiment of the invention. It should be understood that various changes can be made in the function and arrangement of elements and steps without departing from the spirit and scope of the invention as set forth in the appended claims. It will be appreciated that embodiments of the invention described herein may be comprised of one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non- processor circuits, some, most, or all of the functions of correcting a mobile subscriber identification as described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method for correcting a mobile subscriber identification. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Thus, methods and means for these functions have been described herein. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. The benefits, advantages, solutions to problems, and any elements that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all of the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims.

Claims

ClaimsWc Claim:

1. A method for correcting a mobile subscriber identification, comprising: receiving from a mobile device at a Device Management (DM) server a device management message including a first subscriber identification that identifies the mobile device; comparing the first subscriber identification with a second subscriber identification, wherein the second subscriber identification is stored in a memory associated with the DM server; and transmitting from the DM server to the mobile device a status code indicating a mismatch between the first and second subscriber identifications.

2. The method of claim 1 , wherein the first subscriber identification comprises an International Mobile Equipment Identifier (IMEI).

3. The method of claim 1, wherein the second subscriber identification comprises a Mobile Station International Subscriber Directory Number (MSISDN)/ IMEI pair.

4. The method of claim 1 , further comprising transmitting from the DM server to the mobile device a session notification message, wherein the device management message is transmitted in response to the session notification message. 2006/061841

5. The method of claim 4, wherein the session notification message comprises a SyncML Device Management Notification Initiated Session Trigger Message.

6. The method of claim 1 , wherein the device management message is a first message of an Over-The-Air (OTA) provisioning session initiated by the mobile device.

7. The method of claiml, further comprising receiving from the mobile device at the DM server, in response to the transmitted status code, a registration message.

8. The method of claim 1 , wherein the device management message received from the mobile device comprises an XML or WBXML message.