EP1733580A1 - Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card. - Google Patents

Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card.

Info

Publication number
EP1733580A1
EP1733580A1 EP05702218A EP05702218A EP1733580A1 EP 1733580 A1 EP1733580 A1 EP 1733580A1 EP 05702218 A EP05702218 A EP 05702218A EP 05702218 A EP05702218 A EP 05702218A EP 1733580 A1 EP1733580 A1 EP 1733580A1
Authority
EP
European Patent Office
Prior art keywords
file
efprl
efmr
updated
data information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05702218A
Other languages
German (de)
French (fr)
Inventor
Kenneth Cheng
Tony Lam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Axalto SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Axalto SA filed Critical Axalto SA
Priority to EP05702218A priority Critical patent/EP1733580A1/en
Publication of EP1733580A1 publication Critical patent/EP1733580A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Definitions

  • the invention deals with updating of data stored in a file included in a data processing system.
  • the present invention relates generally to handling roaming lists in a wireless communication system, and more specifically to updating a preferred roaming list PRL (Preferred Roaming List).
  • PRL Preferred Roaming List
  • this list is stored in a SIM (Subscriber Identity Module) card or a RUIM (Removable User Identity Module)
  • SIM Subscriber Identity Module
  • RUIM Removable User Identity Module
  • a PRL is a list defined in the specifications [S0023] and [S0016] for CDMA (Code-Division Multiple Access). These two documents are incorporated by reference to the description. It allows the Operator to use the OTAPA/SP commands to update the over the air using a defined protocol [S0016]. The relevant files are described in the [S0023] specification.
  • the PRL list is a list of information that resides in the memory of a smart card coupled to a mobile phone. This list is set by the network operator and stored in the SIM/RUIM card. It lists the frequency bands the phone can use in various parts of a country. This list can be updated by the home network operator by means of data download over the air (OTA).
  • OTASP Over-the-Air Service Provisioning
  • Over-the-Air Parameter Administration is a network initiated OTASP process of provisioning mobile phone operational parameters over the air interface.
  • Over-the-Air Service Provisioning (OTA SP) is a process of provisioning mobile station operational parameters over the air interface. The mobile station can receive Preferred Roaming List parameters in one or more SSPR commands from the network. As the APDU buffer on a RUIM is today restricted to 255 bytes, a complete PRL update will be sent over many commands.
  • a list PRL is stored in a temporary storage until reception of a "commit" command received from the server requesting the PRL list update.
  • the server sends a 'Commit APDU'
  • all the data stored in said temporary storage is copied into the file EF pr ⁇ file itself in a permanent memory.
  • the process is very long due to limited resources in the smart card.
  • the problem becomes worse as the size of the PRL increases.
  • the size of a PRL update is about 500 bytes.
  • the processor of the card is engaged in an update process for a long period of time. This is unacceptable in a GSM context as it is stated that each command should take no longer than 2 seconds in order to allow 'authentication' during a session.
  • said data processing system comprises a second file Efmr stored in permanent memory, this file Efmr having the same structure as the first file Efprl, said second file storing data information updates received from the network, and in that when the first file Efprl has to be updated by said second file Efmr, the second file Efmr is renamed by the name of the first file (Efprl).
  • a file EFmr as temporary storage provides a way to get consistent timing for PRL update operations regardless of the size of the PRL list.
  • FIG. 1 is a block diagram view of the architecture of a computer system on which the solution can be applied.
  • Figure 2 is an example of an OTAPA/SP sequence for PRL Update. Card and ME actions.
  • Figure 1 illustrates a system SYS including a mobile phone ME coupled to a RUIM card CARD.
  • the card CARD stores a list PRL.
  • This example is not restrictive; the PRL list could be for example stored in the mobile phone ME.
  • System SYS also comprises a server SERV. In our example, this server is the home network operator. PRL lists are loaded into the SIM card from this server.
  • FIG. 2 is an example of a communication between said couple Mobile- Card and the server SERV.
  • Reference COM means that PRL Update blocks are stored in EFmr file. This is updated as many times as required until the 'COMMIT' command.
  • This PRL comprises a list of preferred telecom operators.
  • This list is stored in a file EF pr ⁇ which can be updated.
  • the structure of EF pri includes parameters blocks.
  • parameters blocks are: -
  • a file ID block defines the file name.
  • a file ID is used to address or identify each specific file.
  • this file ID includes two bytes.
  • - Access conditions block defining access rights on Read command, Update command, Invalidate command, Rehabilitate command. The Access conditions are set for administrator use only.
  • Such file Efprl includes other blocks, but for a better understanding of the invention, we have simplified in reducing the number of blocks and in using a vocabulary other than used in the above standards.
  • this file is inaccessible by the user of the card.
  • the only person allowed to use this file is the administrator ADM. This way, the file Efmr can't be modified. Obviously, this way to manage access conditions is not restrictive; any other way to manage access might be used.
  • each parameter block is the following: - the file name is 6F30 - the access conditions are the following: ⁇ Read command can be used with a password CHV1 ⁇ And Update, Invalidate, Rehabilitate commands can be used by the administrator ADM. - The preferred operators are "TeleCom 1", “TeleCom2". In our example, we see that the user is allowed to use Read command and not the other commands. This example is not restrictive, any other access rights can be implemented function of the context. Let's suppose the operator wants to update the file EF pr ⁇ by a new one corresponding to the second file Efmr.
  • the card also stores a second file Efmr.
  • the operator downloads this file into the card CARD.
  • the structure of this second file Efmr is the same as file EF pr ⁇ .
  • This file includes the same parameter blocks as the file EF pr ⁇ but is located at a different place in memory and its content can be different from file EF pr
  • the first and second files are stored in the same permanent memory.
  • the content of each parameter block is the following: - the file name is FF30 - the access conditions are the following: ⁇ Read, Update, Invalidate, Rehabilitate commands can be used by the administrator ADM; - The preferred operators are: "Complus” and "operaT”.
  • Step l In a first step, referring to figure 2 and more particularly to reference COM, the operator sends a message (or a plurality of commands as shown on figure 2) including a new list of partners. Step 2 The mobile receives this message and stores the new list in said second file Efmr. Step 3 After reception and storage of the list of partners in Efmr, referring to figure 2, the operator server sends an update command. In our example, this command corresponds to the "commit" command. Step 4 When receiving this "commit" command, a program is therefore activated. The program renames the files as follows: - Rename the file Efmr by EFpri.
  • the second file EFmr becomes the current file EFpri by internally modifying the file header ID to EFpri.
  • Old EFpri Becoming the new file dedicated for the updates.
  • the file previously known as EFpri is for example renamed to a temporary File ID and used for storing future updates.
  • the Access conditions are also swapped between the 2 files.
  • the new file EF pr ⁇ is used as preferred operator list PRL for communicating with the network.
  • this procedure will be encapsulated in a transaction, allowing backup of previous data in case of unsuccessful completion of update.
  • file identifiers FF30, 6F30
  • the file ID can be of any value that does not affect normal functioning of the RUIM or Card.
  • data information stored in the second file Efmr is not deleted.
  • the server could reuse this data information if updates are those stored in this file.
  • the operator would only have to send a command including a "commit" command without data information updates. This avoids the server to download a new time data information updates over the air.
  • Each file could be used in target regions where the operator has agreement with a respective partners list.
  • Storing large PRL doesn't affect performance for RUIM as the update just consists in renaming a file.

Abstract

Method for updating a file in a data processing system comprising a first file (Efprl) storing data information able to be updated through a network, characterized in that said system comprises at least one second file (Efmr) having the same structure as the first file (Efprl), said second file (EFmr) storing data information updates received from the network, and in that when the first file (Efprl) have to be updated, said method comprises the step of renaming the second file (Efmr) by the name of the first file (Efprl). In particular, the data processing system is a SIM card of a mobile phone and said files comprise preferred roaming lists (PRL).

Description

UPDATING OF THE PREFERRED ROAMING LIST ( PRL) IN A SIM (SUBSCRIBER IDENTITY MODULE) / RUIM (REMOVABLE USER IDENTITY MODULE) CARD
Field of the Invention The invention deals with updating of data stored in a file included in a data processing system. The present invention relates generally to handling roaming lists in a wireless communication system, and more specifically to updating a preferred roaming list PRL (Preferred Roaming List). Generally, this list is stored in a SIM (Subscriber Identity Module) card or a RUIM (Removable User Identity Module) A PRL is a list defined in the specifications [S0023] and [S0016] for CDMA (Code-Division Multiple Access). These two documents are incorporated by reference to the description. It allows the Operator to use the OTAPA/SP commands to update the over the air using a defined protocol [S0016]. The relevant files are described in the [S0023] specification. Prior Art Generally, the PRL list is a list of information that resides in the memory of a smart card coupled to a mobile phone. This list is set by the network operator and stored in the SIM/RUIM card. It lists the frequency bands the phone can use in various parts of a country. This list can be updated by the home network operator by means of data download over the air (OTA). A process used and defined in the above-identified standard is: Over-the-Air Service Provisioning (OTASP). This is a process of provisioning mobile station operational parameters over the air interface. Products existing today which support the [S0016-0] or [S0016-A] (OTAPA/SP) functionality will have the possibility to update the files for Preferred Roaming List using the commands - SSPR (System Selection for Preferred Roaming) Download Request - and SSPR Configuration Request. Over-the-Air Parameter Administration (OTA/PA) is a network initiated OTASP process of provisioning mobile phone operational parameters over the air interface. Over-the-Air Service Provisioning (OTA SP) is a process of provisioning mobile station operational parameters over the air interface. The mobile station can receive Preferred Roaming List parameters in one or more SSPR commands from the network. As the APDU buffer on a RUIM is today restricted to 255 bytes, a complete PRL update will be sent over many commands. So, a list PRL is stored in a temporary storage until reception of a "commit" command received from the server requesting the PRL list update. When the server sends a 'Commit APDU', all the data stored in said temporary storage is copied into the file EFprι file itself in a permanent memory. The process is very long due to limited resources in the smart card. The problem becomes worse as the size of the PRL increases. Today, the size of a PRL update is about 500 bytes. When the PRL is of a greater size, the processor of the card is engaged in an update process for a long period of time. This is unacceptable in a GSM context as it is stated that each command should take no longer than 2 seconds in order to allow 'authentication' during a session. Although it is not a restriction in CDMA (Code-Division Multiple Access), from a user point of view, an overly long wait is not desirable. The Invention The aim of the invention is to reduce the time that is required to update a PRL list in a smart card. According to the invention, said data processing system comprises a second file Efmr stored in permanent memory, this file Efmr having the same structure as the first file Efprl, said second file storing data information updates received from the network, and in that when the first file Efprl has to be updated by said second file Efmr, the second file Efmr is renamed by the name of the first file (Efprl). In this way, using a file EFmr as temporary storage provides a way to get consistent timing for PRL update operations regardless of the size of the PRL list.
This file EFmr is used to store each of the PRL update blocks. So, the step of updating the PRL list is largely reduced in time. In our example, this time is reduced to the time of modifying the file header. It will be easier to understand the invention on reading the description below, given as an example and referring to the attached drawings. In the drawings Figure 1 is a block diagram view of the architecture of a computer system on which the solution can be applied. Figure 2 is an example of an OTAPA/SP sequence for PRL Update. Card and ME actions. Figure 3 is a view of a part of a file storing a list of partners PRL; - Figure 4 is a view of a part of a file storing a list of partners PRL, this file being updates and being stored in said permanent memory according to the invention. Detailed description of examples illustrating the invention To simplify the description, the same elements illustrated in the drawings have the same references. Figure 1 illustrates a system SYS including a mobile phone ME coupled to a RUIM card CARD. In our example, the card CARD stores a list PRL. This example is not restrictive; the PRL list could be for example stored in the mobile phone ME. System SYS also comprises a server SERV. In our example, this server is the home network operator. PRL lists are loaded into the SIM card from this server. Downloading can be performed for example by means of over the air (OTA) technics. Figure 2 is an example of a communication between said couple Mobile- Card and the server SERV. On this figure, we see a plurality of SSPR commands. Reference COM means that PRL Update blocks are stored in EFmr file. This is updated as many times as required until the 'COMMIT' command. This PRL comprises a list of preferred telecom operators. This list is stored in a file EFprι which can be updated. The structure of EFpri includes parameters blocks. In our example, parameters blocks are: - A file ID block defines the file name. A file ID is used to address or identify each specific file. In our example this file ID includes two bytes. - Access conditions block defining access rights on Read command, Update command, Invalidate command, Rehabilitate command. The Access conditions are set for administrator use only. - a list block for defining the preferred operators
Such file Efprl includes other blocks, but for a better understanding of the invention, we have simplified in reducing the number of blocks and in using a vocabulary other than used in the above standards. For the correct vocabulary, and the correct structure, we will refer to the above-identified standards, which will define exactly the additional blocks.
In our example, we see that this file is inaccessible by the user of the card. The only person allowed to use this file is the administrator ADM. This way, the file Efmr can't be modified. Obviously, this way to manage access conditions is not restrictive; any other way to manage access might be used.
In our illustrated example, referring to Figure 3, the content of each parameter block is the following: - the file name is 6F30 - the access conditions are the following: ■ Read command can be used with a password CHV1 ■ And Update, Invalidate, Rehabilitate commands can be used by the administrator ADM. - The preferred operators are "TeleCom 1", "TeleCom2". In our example, we see that the user is allowed to use Read command and not the other commands. This example is not restrictive, any other access rights can be implemented function of the context. Let's suppose the operator wants to update the file EFprι by a new one corresponding to the second file Efmr. The operator has a new list of operators "Complus" and "operaT" and wants to replace the current operators TeleCom 1", "TeleCom2" by "Complus" and "operaT". According to the invention, the card also stores a second file Efmr. In our example, the operator downloads this file into the card CARD. Preferably, the structure of this second file Efmr is the same as file EFprι.
This file includes the same parameter blocks as the file EFprι but is located at a different place in memory and its content can be different from file EFpr|. Preferably, the first and second files are stored in the same permanent memory. In our illustrated example, referring to figure 4, the content of each parameter block is the following: - the file name is FF30 - the access conditions are the following: ■ Read, Update, Invalidate, Rehabilitate commands can be used by the administrator ADM; - The preferred operators are: "Complus" and "operaT". The following steps will help to understand how the file EFprι will be updated: Step l In a first step, referring to figure 2 and more particularly to reference COM, the operator sends a message (or a plurality of commands as shown on figure 2) including a new list of partners. Step 2 The mobile receives this message and stores the new list in said second file Efmr. Step 3 After reception and storage of the list of partners in Efmr, referring to figure 2, the operator server sends an update command. In our example, this command corresponds to the "commit" command. Step 4 When receiving this "commit" command, a program is therefore activated. The program renames the files as follows: - Rename the file Efmr by EFpri. EFmr becoming the new file defining the operators to be used by the mobile phone. So that, According to this embodiment, the second file EFmr becomes the current file EFpri by internally modifying the file header ID to EFpri. - And, in our example, Rename the file EFpri by Efmr. Old EFpri Becoming the new file dedicated for the updates. In this step, the file previously known as EFpri is for example renamed to a temporary File ID and used for storing future updates. In our example, the Access conditions are also swapped between the 2 files. Step 5 At this time, the new file EFprι is used as preferred operator list PRL for communicating with the network. Advantageously, this procedure will be encapsulated in a transaction, allowing backup of previous data in case of unsuccessful completion of update. For example, it is possible to create an inaccessible duplicate of the first file EFpri which will be used to store the blocks of PRL during the OTAPA/SP session. In our illustrated example, file identifiers (FF30, 6F30) are just suggested.
However, the file ID can be of any value that does not affect normal functioning of the RUIM or Card. According to another embodiment, after step 5, data information stored in the second file Efmr is not deleted. The server could reuse this data information if updates are those stored in this file. In this embodiment, the operator would only have to send a command including a "commit" command without data information updates. This avoids the server to download a new time data information updates over the air. We could also imagine to store a plurality of temporary files EFmrn (n= 1 , ..., k). Each file could be used in target regions where the operator has agreement with a respective partners list. In this embodiment, the operator would only have to send a command including a "commit" command and an indication of the file to be used among the plurality of files EFmrn (n= 1 , ..., k). These files could be loaded during personalization step or later. This solution could permit the operator to download data information updates one time. We see now that with the invention, Storing large PRL doesn't affect performance for RUIM as the update just consists in renaming a file.

Claims

Claims
1. Method for updating a file in a data processing system comprising a first file (Efprl) storing data information able to be updated through a network, characterized in that said system comprises at least one second file (Efmr) having the same structure as the first file (Efprl), said second file (EFmr) storing data information updates received from the network, and in that when the first file (Efprl) have to be updated, said method comprises the step of renaming the second file (Efmr) by the name of the first file (Efprl).
2. Method according to claim 1 , characterized in that said program also performs, after the second file (Efmr) has been updated by the name of the first file (Efprl), a further step of renaming said first file (Efprl) by the name of the second file (Efmr).
3. Method according to claim 1 or 2, characterized in that, after the second file (Efmr) has been updated by the name of the first file (Efprl), a step of reusing this data information if updates are those stored in said file (Efmr).
4. Method according to claim 1 , characterized in that, beforehand, each of said second file (Efmr) is prealably loaded in said system, and in that when the first file (Efprl) have to be updated by one of said second file (Efmr), the operator sends an update command including an indication of the file to be used among the plurality of files EFmrn (n= 1 k) for updating said first file (Efprl).
5. Data processing system including a first file (Efprl) storing data information able to be updated through a network, characterized in that it stores a second file (Efmr) having the same structure as the first file (Efprl), said second file storing data information updates received from the network, and in that said system stores a program able to perform the step of renaming the second file (Efmr) by the name of the first file (Efprl) when the first file (Efprl) have to be updated by said second file (Efmr).
6. System according to claim 5, characterized in that said system is a mobile phone (ME) and in that said files (Efprl, EFmr) comprise a list of preferred operators to be used by the mobile.
7. Smartcard (CARD) including a first file (Efprl) storing data information able to be updated through a network, characterized in that it stores a second file (Efmr) having the same structure as the first file (Efprl), said second file storing data information updates received from the network, and in that said smart card (CARD) stores a program able to perform the step of renaming the second file (Efmr) by the name of the first file (Efprl) when the first file (Efprl) have to be updated by said second file (Efmr).
8. Computer program for a data processing system comprising a first file (Efprl) storing data information able to be updated through a network, characterized in that said system comprises a second file (Efmr) having the same structure as the first file (Efprl), said second file storing data information updates received from the network, said program including instruction code for, when the first file (Efprl) have to be updated by said second file (Efmr), renaming the second file (Efmr) by the name of the first file (Efprl).
EP05702218A 2004-01-14 2005-01-12 Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card. Withdrawn EP1733580A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05702218A EP1733580A1 (en) 2004-01-14 2005-01-12 Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card.

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP04290101A EP1583381A1 (en) 2004-01-14 2004-01-14 Updating of the preferred roaming list (PRL) in a Subscriber Identity Module (SIM) or Removable User identity Module (RUIM)
EP05702218A EP1733580A1 (en) 2004-01-14 2005-01-12 Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card.
PCT/IB2005/000048 WO2005069660A1 (en) 2004-01-14 2005-01-12 Updating of preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card.

Publications (1)

Publication Number Publication Date
EP1733580A1 true EP1733580A1 (en) 2006-12-20

Family

ID=34778229

Family Applications (2)

Application Number Title Priority Date Filing Date
EP04290101A Withdrawn EP1583381A1 (en) 2004-01-14 2004-01-14 Updating of the preferred roaming list (PRL) in a Subscriber Identity Module (SIM) or Removable User identity Module (RUIM)
EP05702218A Withdrawn EP1733580A1 (en) 2004-01-14 2005-01-12 Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP04290101A Withdrawn EP1583381A1 (en) 2004-01-14 2004-01-14 Updating of the preferred roaming list (PRL) in a Subscriber Identity Module (SIM) or Removable User identity Module (RUIM)

Country Status (4)

Country Link
EP (2) EP1583381A1 (en)
CN (1) CN1918932B (en)
BR (1) BRPI0506813B1 (en)
WO (1) WO2005069660A1 (en)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4548307B2 (en) 2005-10-31 2010-09-22 ソニー株式会社 Separation type processing apparatus and software version updating method
CN1984127B (en) * 2005-12-16 2010-05-12 华为技术有限公司 Method for realizing batch refresh in subscribing mechanism
CN101635071B (en) * 2008-07-21 2012-04-25 中国移动通信集团公司 Method, system and device for installing/updating e-wallet
US9008653B2 (en) 2008-08-15 2015-04-14 Tekelec, Inc. Systems, methods, and computer readable media for providing dynamic steering of roaming in a telecommunications network
CN102196400A (en) * 2010-03-02 2011-09-21 高通股份有限公司 Method and device for updating information of mobile communication terminal
CN104363576A (en) * 2010-03-02 2015-02-18 高通股份有限公司 Systems and methods for incremental update of a preferred roaming list
US9054883B2 (en) 2010-10-05 2015-06-09 Tekelec, Inc. Methods, systems, and computer readable media for user activated policy enhancement
US8825045B2 (en) * 2012-10-05 2014-09-02 Smith Micro Software, Inc. Policy-based roaming updates for mobile devices
DE102012020690A1 (en) * 2012-10-22 2014-04-24 Giesecke & Devrient Gmbh Method for introducing subscriber identity data into a subscriber identity module
EP2955947B1 (en) 2014-06-12 2019-07-31 Uros Technology S.à r.l. Processing of preferred roaming lists
EP2955948A1 (en) 2014-06-12 2015-12-16 Uros Technology S.à r.l. Management of subscriber identity modules
CN107484150B (en) * 2017-07-05 2020-12-22 宇龙计算机通信科技(深圳)有限公司 EV-DO network connection method, device and terminal
IT201700106423A1 (en) * 2017-09-22 2019-03-22 St Microelectronics Srl PROCEDURE FOR MANAGING INTEGRATED CIRCUIT CARDS, CARD AND CORRESPONDING EQUIPMENT

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19543843C2 (en) * 1995-11-24 2001-02-08 Acer Peripherals Inc Procedure for updating the software in a microcomputer-based telephone
US5903832A (en) * 1995-12-21 1999-05-11 Nokia Mobile Phones Llimited Mobile terminal having enhanced system selection capability
US5999811A (en) * 1996-02-16 1999-12-07 Ericsson, Inc. Mobile telephone for roaming using dual mode/band equipment including SIM cards
JP2001075785A (en) * 1999-09-09 2001-03-23 Nec Corp Data updating system
FR2808645B1 (en) * 2000-05-05 2002-06-21 France Telecom METHOD FOR RE-SELECTING THE NOMINAL NETWORK OF A MOBILE TELEPHONE
GB2369265B (en) * 2000-09-11 2004-03-17 Cable & Wireless Hkt Csl Ltd Method of automatically establishing roaming services in a mobile telecommunications system.

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005069660A1 *

Also Published As

Publication number Publication date
CN1918932B (en) 2010-09-29
CN1918932A (en) 2007-02-21
WO2005069660A1 (en) 2005-07-28
EP1583381A1 (en) 2005-10-05
BRPI0506813A (en) 2007-06-05
BRPI0506813B1 (en) 2018-07-10

Similar Documents

Publication Publication Date Title
EP1733580A1 (en) Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card.
US7577126B2 (en) System and method for over the air area code update
US10602348B2 (en) System and method for updating dataset versions resident on a wireless device
EP2578005B1 (en) Method and apparatus for the management of non volatile items and provisioning files for a communication device with multiple service accounts
EP2735180B1 (en) Application selection for multi-sim environment
EP1825702B1 (en) Backup system and method in a mobile telecommunication network
CN102308561B (en) ME network parameters configuration by UICC
EP1761088B1 (en) Customisation of mobile stations
EP2254359A2 (en) Method and apparatus for handling roaming lists in a wireless communication system
CN100391279C (en) Method for updating main programme executed by radio communication module
AU4664099A (en) Changing functionality of a module terminal in a wireless network
US11930558B2 (en) Method for providing subscription profiles, subscriber identity module and subscription server
US6810245B1 (en) Intelligent remote software loading method for wireless portable communication device
JP4571298B2 (en) Home and roaming provisioning methods for mobile terminals
EP1637003B1 (en) Databases synchronization
CN101877071A (en) Data updating method, device and system
KR100901871B1 (en) Method and Apparatus for Loading Program Using Smart Card
CN106792643A (en) A kind of international roaming realization method and system based on card number switching
EP1367487A1 (en) Remote application correction
CN112748937A (en) Method and device for updating eUICC operating system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060721

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080222

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GEMALTO SA

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04Q0007320000

Ipc: H04W0008180000

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 8/18 20090101AFI20110316BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20111011