EP1388134A1 - Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable - Google Patents
Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmableInfo
- Publication number
- EP1388134A1 EP1388134A1 EP02761929A EP02761929A EP1388134A1 EP 1388134 A1 EP1388134 A1 EP 1388134A1 EP 02761929 A EP02761929 A EP 02761929A EP 02761929 A EP02761929 A EP 02761929A EP 1388134 A1 EP1388134 A1 EP 1388134A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- data
- identification
- code
- memory
- intended
- 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
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/357—Cards having a plurality of specified features
- G06Q20/3576—Multiple memory zones on card
- G06Q20/35765—Access rights to memory zones
Definitions
- the invention relates to the management of data to be loaded into memory for optimizing storage possibilities.
- the data in question may in particular be of the code constituting a program of the "application” type, intended to be loaded into a memory of a communicating device, such as a programmable smart card or the like.
- an open card has rewritable memory spaces for storing one or more service applications in a progressive manner.
- the manufacturer can not provide for a different management of parts of the code of an application depending whether they are customizing, whose utility is only temporary, or other parts that can be used 'at any time .
- the personalization of an application is a series of operations carried out at an initial stage which makes it possible to individualize it in relation to the card holder.
- the personalization code contains different commands, called “administrative”, for example to load registers with identification codes, authorization, and other personal data, and to configure the application according to choices or limits established according to the holder, etc.
- the application is activated, possibly in cooperation with an internal card management program, to execute all of the administrative commands necessary for personalization.
- the administrative commands no longer have any use, but remain in memory with the rest of the application, as they cannot be managed separately.
- these administrative commands can represent a few tens of percent of the total space occupied in memory by the application concerned, which limits the ability of the smart card to accept new applications.
- the object of the invention is to provide an identification of the parts of a set of data to be stored in memory which can therefore be managed separately in order to be able to optimize the storage capacity.
- the parts corresponding to the administrative personalization commands will be identified (ie indicated) as such in , the code, according to. convention established, so that they can be recognized and managed separately within the card, in particular to free up the space they occupy in memory once the personalization has been carried out.
- the invention relates to a data managing method to be stored in a memory, 'the data are intended to be managed according to at least two modes, characterized in that it comprises the steps of:
- the data intended for a first management mode can be data whose utility is only provisional relative to the data intended for the other management modes.
- the invention will more particularly relate to a method for managing data intended to be stored in a memory, characterized in that it comprises the steps of: - provide an identification, during a data preparation phase, of that of data whose usefulness is only temporary in relation to the other data, and - manage the storage of data on the basis of the identification provided.
- the identification is integrated into the data.
- the data includes code relating to an executable program, part of which, identified as being intended for a first management mode, relates to the code intended to be used only during an initial phase of the program.
- the memory can be located in a communicating device, such as a smart card, the data comprising code relating to an application, part of which, identified as intended for a first management mode, relates to the code for personalizing the application during an initial phase.
- the step of managing the data storage comprises the sub-steps of:
- This step may further comprise a step of erasing the data identified after the end of utility detection step.
- identification can be provided by a naming technique, where we assign to or each module of the program associated with the data to be identified, an identifiable name according to an established convention. .
- the identification can be provided by a typing technique, where one or each type of said program associated with the data to be identified is given a subtyping link to a specified type identifiable according to a convention established.
- typing takes place by conferring on one or each class of the program associated with the data to be identified, an inheritance link to a specified class, identifiable according to the established convention. .
- identification can be provided by designating the file (s) associated with the data to be identified, according to an established convention.
- identification can be provided by labeling instructions relating to the data to be identified, according to an established convention, the labeling being affixed to each instruction concerned or limiting groups of instructions concerned.
- the method can also provide a step of checking the correct identification of the data of provisional utility relative to the other data which they are called to persist in memory, the verification consisting in ensuring that the data identified as not being that of provisional utility are not called by said other data.
- the analysis can consist in verifying that no instruction of the code of the rest of the program calls upon instructions of the code used only during an initial phase of the program.
- the invention can be applied to other types of management than those relating to data of temporary utility with respect to others.
- the management permitted by identification can also be used in particular for:
- routing can . run to one of several processors, selected according to said identification;
- the invention relates to a data management system intended to be stored in a memory, the data being intended to be managed according to at least two modes, characterized in that it comprises:
- identification means for supplying an identification, during a data preparation phase, making it possible to identify respectively the data intended to be managed according to the different modes, and storage management means and / or exploitation of data operating on the basis of said identification provided.
- the invention relates to a programmable smart card, comprising a first programmable memory intended for the storage of code constituting an application, and a second memory containing instructions making it possible to recognize an identification, according to an established convention, of the administrative code of a loaded application, this code being intended to personalize the application during an initial phase.
- the second memory further comprises. instructions for authorizing the erasure of the administrative code of the first active memory after the end of the ' customization of the application.
- FIG. 1 is a simplified block diagram of the main elements of a smart card
- r 2 is a flowchart of a protocol for identifying parts of the administrative code for an application for the card • chip of FIG 1, in accordance with the invention
- FIG. 3 is a flow diagram of a procedure for loading the application into a card and for managing the programmable memory used in the protocol of FIG. 2
- FIG. 4 is a flow diagram of a variant of that of FIG. 3, which incorporates verification measures for the identification of the data.
- a programmable smart card 1 The basic functional elements of a programmable smart card 1 are shown so synoptic in the block diagram of FIG. 1.
- a microprocessor CPU 2 which provides all the functions of internal management of the card, as well as the execution of the applications which are programmed there.
- the microprocessor is connected, by an internal bus system 4, to three types of memory:
- ROM read only type
- EEPROM electrically programmable
- a memory of the mask ROM type 8 containing all of the code and values of an internal card management software. These data are entered during the fabrication of the chip, at the level of the layer deposition masks.
- the content of the mask ROM 8 being very strongly linked to the hardware means of the smart card, the code is normally established by the manufacturer of the card;
- the internal bus 4 is also connected to a communication interface 12 which constitutes a data input and output port vis-à-vis the outside world, and which provides the electrical supply to the card 1.
- This interface can be in the form of connection pads intended to engage with respective contacts of a reader, and / or of an antenna in the case of a so-called contactless card.
- the communication interface 12 is used inter alia for bidirectional data exchange with a terminal provided for loading an application ' into the EEPROM memory 6.
- the invention provides an agreement between on the one hand the designer of the service application and on the other hand the manufacturer of cards, aiming to strictly identify the personalization code. ie. "administrative" (the one used only for personalization) compared to the rest of the code, ie the "functional" code used by the client application.
- This identification is entered in the service application by the designer and is recognized at the level of the management software stored in the mask memory 8.
- the management of the EEPROM memory 6 can then be established as a function of this recognition, in particular by providing for erasure, or compacting of the data located at the addresses assigned to the storage of the administrative code once the personalization . completed.
- step E2 The general concept of such an exploitation of the identification of the administrative code is illustrated by the flowcharts of FIGS. 2 and 3.
- the designer C of the service application and the manufacturer F of programmable smart cards s '' agree on an agreement to identify the administrative code (step E2). This convention ensures interoperability between the card and the service application.
- step E4 the designer provides an identification of the administrative code in his application (by marking, naming, labeling, etc.) (step E4).
- the constituent information of this identification is integrated with all the data that constitute the application code.
- step E6 the manufacturer writes in the ROM memory 8 the commands necessary for the recognition of the code thus identified and for the management in EEPROM memory 6 of this code, in accordance with a procedure Pi for loading into card and memory management described below. -after (step E6).
- the designer here assimilated to the owner operating the application, distributes the application with a view to integrating it into the smart card (step E8). To this end, it transmits it to the manufacturer for loading onto blank cards from a factory terminal (loading in pre-transmission) and, where appropriate, onto B2 "user" terminals for loading by the holders of smart cards ( loading in post-transmission). For example, a holder can load, via a B2 terminal, an application for a new commercial service that he wishes to use.
- terminal Bl or B2 comprises a program which manages the loading of an application by having identified on one side the personalization code ' and on the other the application code (functional). This program will load from terminal Bl or B2 all the code
- step E10 the application and, in the event of an immediate personalization request, initiate the personalization phase with transmission of the necessary orders.
- the procedure begins with the detection of a load in the EEPROM memory 6 of an application in the smart card 1 (step E10).
- step E12 the data flow which constitutes the code is analyzed to identify therein the data relating to the administrative code (step E12). This identification is carried out by means of the recognition commands established during step E6, on the basis of the identification convention.
- the addresses are then established in EEPROM 6 to which the data of the administrative code are assigned (step -E14).
- This step can be carried out in two ways: - passive, that is to say by listing in a register (in EEPROM 6 or RAM 10) the series of addresses occupied by the data of the administrative code, without intervening in the choice of these addresses, or - dynamic, by directing the data of the administrative code onto specific EEPROM 6 address areas, away from the other data forming the rest of the code.
- Personalization typically involves a dialogue between the card and the terminal, the latter allowing the service provider to enter personal data (identification codes, password, chosen options, etc.) via administrative commands. Personalization will then configure the application within the card taking into account this personal data (for example to check the personal code for each use, manage exchanges according to chosen options, etc.). Note that personalization takes place at the initial stage of the application, once and for all; the configuration of the application based on personal data is then frozen. Thus, the administrative code is no longer useful once the customization is complete.
- the procedure authorizes the reuse of the addresses of the administrative code located in step E14 (step E24).
- This authorization allows several possibilities for managing the EEPROM 6 memory space: registration of new data at the addresses previously occupied by the. administrative code; for example when loading another application. In this case, the administrative code may remain present until these addresses in EEPROM 6 memory are requisitioned for other data,
- This step E24 can be implemented by the internal management program of the card 1 according to conventional techniques for identifying free addresses in EEPROM memory 6. Whatever the option chosen, the management makes it possible to recover the space in EEPROM memory 6 unnecessarily occupied by the personalization code after its execution.
- the identification of the personalization code can be carried out in many different ways, some examples of which will be given below.
- a first approach consists in declaring that everything that comes under the administrative code is put in a specific module. To this end, o can proceed in two ways: by "naming” or by “typing”.
- Naming consists in naming this module (s) with an expression allowing a third party to recognize it as containing the personalization code, for example by assigning the prefix "personal" to the module, or any other established prefix. according to a naming convention between the card manufacturer and the designer of client applications in step E2 above. Of course, the other modules containing the rest of the code should not. use this prefix.
- the management software stored in the ROM memory mask 8 of the card can, by reading the module names, know where the parts of code intended for personalization are located and act accordingly, for example by putting them to cell addresses which will be subject to an erasure phase after personalization ( see Figure 3, steps E12, E14).
- the typing-based approach is aimed at object-oriented languages. These languages call on "classes”, comparable to modules, each defining a "type" of data and associated processing. These types are organized according to a hierarchy of types, going from the most general to the most specific, ie there is generally a basic type from which the classes and their instances are attached according to established dependency links, called “inheritance", a class “inheriting” from all the classes on which it depends in the hierarchy. It can thus be specified that the personalization classes "inherit” from a specific class dedicated to personalization, designated according to the convention set in step E2, for example "personal". The code of the other classes does not inherit from this "personal” class. The "personal” class can be empty, being a shell used only to create the inheritance links. During programming, we make sure that the codes linked to personalization are grouped into classes that inherit from this "personal” class.
- the mask ROM management software 8 performs a type analysis when the code is received (see FIG. 3, step E12), with the aim of determining the types of modules contained in the program.
- the type of the module specifies its ascending hierarchical links. We can thus determine by the type of a module if this the latter inherits, at any hierarchical level, from the "personal" module. If this is the case, it is considered that the module in question includes personalization code, to be managed as such in step E14.
- labeling where a file containing all of the application code (administrative code and other codes) is sent. This file is in the form of a series of instructions (for example from 0 to n). The instructions in this suite relating to personalization are then indicated by labeling (also known by the Anglo-Saxon expression "tag") according to a convention established during the abovementioned step E2.
- labeling also known by the Anglo-Saxon expression "tag”
- a series of personalization instructions will start with a “start of personalization code” label and will end with a “end of personalization code” label.
- FIG. 4 differs from this essentially in that it includes a verification step aimed at determining whether there is no error in identification.
- the steps E10-E24 of Figure 4 are identical to those corresponding to Figure 3 and will not be described again for the sake of brevity.
- the variant also provides a verification step prior to the erasure authorization step at the personalization code addresses.
- This verification may take place at different times during the aforementioned PI procedure, or even at a stage prior to its execution, depending on the technique used.
- the result of the verification is saved in an accessible way during the loading of the program that has been verified. In the example, this result is used just after the end of personalization (step E22) in a step - of conditional referral E26 to determine whether or not to go to step E24 of authorization to reuse the addresses of the personalization code. If there is no identification error detected, the procedure goes through authorization step E24 (branch b1), as in the case of FIG. 3. If there is at least one identification error detected, the procedure bypasses the authorization step E24. In this case, the data relating to the administrative code are kept in the memory 6 in the same way as the other data of the application.
- verification consists in ensuring that the functional code does not use administrative code, for example by means of the "go to" instruction.
- the verification can be done at the level of card 1, after loading the application.
- the card is managed in step E14 to store the personalization code between two bounded addresses (API - APn), and we check during the execution of the functional code that there is no jump to addresses between API and APn.
- Verification can also be done outside of the card, by performing a code analysis to determine if the functional code uses administrative code, which would indicate an error in administrative code designation.
- the teachings of the invention can take many equivalent forms and apply to other fields.
- the identification is attached to the administrative code; however, an equivalent technical effect can be obtained by attaching, conversely, an identification to the application code. In this case, the procedure will be adapted to recognize the administrative code by the absence of attached identification.
- the invention it is possible to manage the data stored in the memory 6 intelligently, by allowing the elimination of the memory of the data relating to the administrative code when these are no longer useful, after the personalization.
- the memory space thus freed can then be used for the storage of other data, corresponding for example to an additional application on the card.
- the invention is in no way limited to the embodiments which have just been described.
- the invention allows management of many different parameters related to data, as mentioned in the introductory part, where the identification of the data can be used inter alia to: establish a storage location in memory, establish a routing of the data corresponding, for example to a specific processor among several processors associated with the memory, to determine whether the data should be encrypted or not, to - determine if the data should undergo an integrity check and / or the conditions of this check, etc. .
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Storage Device Security (AREA)
- Stored Programmes (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0104889A FR2823330B1 (fr) | 2001-04-10 | 2001-04-10 | Procede et systeme de gestion de donnees destinees a etre stockees dans une memoire, par exemple du code d'une application charge dans une carte a puce programmable |
FR0104889 | 2001-04-10 | ||
PCT/FR2002/001235 WO2002084610A1 (fr) | 2001-04-10 | 2002-04-09 | Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1388134A1 true EP1388134A1 (fr) | 2004-02-11 |
Family
ID=8862175
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP02761929A Withdrawn EP1388134A1 (fr) | 2001-04-10 | 2002-04-09 | Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable |
Country Status (5)
Country | Link |
---|---|
US (1) | US7025261B2 (fr) |
EP (1) | EP1388134A1 (fr) |
CN (1) | CN1273943C (fr) |
FR (1) | FR2823330B1 (fr) |
WO (1) | WO2002084610A1 (fr) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007074119A1 (fr) * | 2005-12-29 | 2007-07-05 | Gemplus | Systeme et procede pour le deploiement d'applications web personnalisees |
CN101401132B (zh) * | 2006-03-14 | 2011-05-25 | Nxp股份有限公司 | 自动配置的智能卡及自动配置智能卡的方法 |
US7753281B2 (en) * | 2006-06-01 | 2010-07-13 | Hewlett-Packard Development Company, L.P. | System and method of updating a first version of a data file in a contactless flash memory device |
US7895245B2 (en) * | 2006-10-31 | 2011-02-22 | Hewlett Packard Development Company, L.P. | Methods and systems for managing data stored on a contactless flash memory device |
US20080265020A1 (en) * | 2007-02-09 | 2008-10-30 | Business Intelligent Processing Systems Plc | System and method for performing payment transactions, verifying age, verifying identity, and managing taxes |
US8917165B2 (en) * | 2007-03-08 | 2014-12-23 | The Mitre Corporation | RFID tag detection and re-personalization |
US8010271B2 (en) * | 2007-05-30 | 2011-08-30 | Mitsubishi Electric Corporation | Brake control device for electric vehicle |
CN103577465A (zh) * | 2012-08-02 | 2014-02-12 | 亿赞普(北京)科技有限公司 | ***数据处理***及方法 |
KR102377634B1 (ko) * | 2012-09-10 | 2022-03-22 | 에이매스, 아이엔씨. | 복수의 기기를 이용한 다차원의 환경 데이터 캡쳐 |
CN103473093B (zh) * | 2013-09-05 | 2016-08-24 | 飞天诚信科技股份有限公司 | 一种管理卡片上应用的方法 |
CN103617401B (zh) * | 2013-11-25 | 2017-02-08 | 北京深思数盾科技股份有限公司 | 一种数据文件保护方法及装置 |
CN107729260A (zh) * | 2017-09-30 | 2018-02-23 | 捷德(中国)信息科技有限公司 | 用于智能卡的存储空间回收方法 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4825054A (en) * | 1988-02-16 | 1989-04-25 | Datacard Corporation | Method and apparatus for parallel integrated circuit card initialization and embossing |
US5434919A (en) * | 1994-01-11 | 1995-07-18 | Chaum; David | Compact endorsement signature systems |
US5889941A (en) * | 1996-04-15 | 1999-03-30 | Ubiq Inc. | System and apparatus for smart card personalization |
KR100213555B1 (ko) * | 1997-01-22 | 1999-08-02 | 윤종용 | 이동무선 단말기의 전용화 확인 방법 |
US6233683B1 (en) * | 1997-03-24 | 2001-05-15 | Visa International Service Association | System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card |
CA2315656C (fr) * | 1997-12-19 | 2008-04-29 | Visa International Service Association | Activation d'une carte au niveau d'un point de distribution |
AUPP274098A0 (en) * | 1998-04-01 | 1998-04-30 | Chip Application Technologies Limited | Data carrying device and systems for use therewith |
US6402028B1 (en) * | 1999-04-06 | 2002-06-11 | Visa International Service Association | Integrated production of smart cards |
US6588673B1 (en) * | 2000-02-08 | 2003-07-08 | Mist Inc. | Method and system providing in-line pre-production data preparation and personalization solutions for smart cards |
US20040144472A1 (en) * | 2003-01-24 | 2004-07-29 | G & D Cardtech, Inc. | Process for manufacturing laminated plastic products |
-
2001
- 2001-04-10 FR FR0104889A patent/FR2823330B1/fr not_active Expired - Fee Related
-
2002
- 2002-04-09 EP EP02761929A patent/EP1388134A1/fr not_active Withdrawn
- 2002-04-09 CN CNB028114825A patent/CN1273943C/zh not_active Expired - Fee Related
- 2002-04-09 US US10/474,742 patent/US7025261B2/en not_active Expired - Lifetime
- 2002-04-09 WO PCT/FR2002/001235 patent/WO2002084610A1/fr not_active Application Discontinuation
Non-Patent Citations (2)
Title |
---|
None * |
See also references of WO02084610A1 * |
Also Published As
Publication number | Publication date |
---|---|
US7025261B2 (en) | 2006-04-11 |
WO2002084610A1 (fr) | 2002-10-24 |
FR2823330A1 (fr) | 2002-10-11 |
CN1514987A (zh) | 2004-07-21 |
FR2823330B1 (fr) | 2004-08-20 |
CN1273943C (zh) | 2006-09-06 |
US20040144838A1 (en) | 2004-07-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2082359B1 (fr) | Procede et dispositif de personnalisation d'une entite electronique portable | |
FR2673476A1 (fr) | Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur. | |
FR2612316A1 (fr) | Carte a circuits integres ayant une capacite de verification d'erreur interne | |
FR2681165A1 (fr) | Procede de transmission d'information confidentielle entre deux cartes a puces. | |
EP0089876A1 (fr) | Procédé et dispositif de protection d'un logiciel livré par un fournisseur à un utilisateur | |
EP1388134A1 (fr) | Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable | |
FR2923047A1 (fr) | Procede de gestion des droits d'acces dans une carte a puce | |
WO1999053401A2 (fr) | Carte a puce comprenant des moyens pour gerer une memoire virtuelle, procede et protocole de communication associes | |
FR2663142A1 (fr) | Dispositif electronique portable a memoire. | |
FR2642544A1 (fr) | Systeme de traitement de donnees a programme de securite | |
FR2908209A1 (fr) | Entite electronique portable et procede de personnalisation d'une telle entite electronique | |
FR2784479A1 (fr) | Protocole d'echange interne de donnees entre applications d'un objet portatif multi-applications et objet portatif multi-applications correspondant | |
EP0838053B1 (fr) | Procede et dispositif permettant a un programme fige de pouvoir evoluer | |
FR2902551A1 (fr) | Dispositif de memorisation amovible et appareil electronique aptes a etre connectes l'un a l'autre et procede de sauvegarde de donnees d'environnement | |
WO2014063940A1 (fr) | Procede de gestion d'identifiants dans une carte a circuit integre et carte a circuit integre correspondante | |
EP1433065A1 (fr) | Procede et dispositif de verificateur de code optimise | |
EP1402487A1 (fr) | Procede et dispositif de traitement de donnees pour la personnalisation d'une application sur un dispositif communicant portatif, par exemple une carte a puce | |
EP0974131B1 (fr) | Procede d'interpretation dynamique de donnees pour une carte a puce | |
FR2765362A1 (fr) | Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires | |
FR3090959A1 (fr) | Traitement d’un service de tickets électroniques | |
FR2747813A1 (fr) | Systeme securise de controle d'acces permettant l'invalidation automatique de cles electroniques volees ou perdues et/ou le transfert d'habilitation a produire des cles | |
FR2812116A1 (fr) | Procede et dispositif d'inscription securisee de donnees dans une memoire reinscriptible | |
FR3083341A1 (fr) | Configuration d'un dispositif electronique | |
EP1233383A1 (fr) | Procédé et dispositif de gestion d'applications de cartes à puce | |
FR2864294A1 (fr) | Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant |
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: 20031110 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO SI |
|
17Q | First examination report despatched |
Effective date: 20090515 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: GEMALTO SA |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
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: GRANT OF PATENT IS INTENDED |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06Q 20/34 20120101AFI20191002BHEP |
|
INTG | Intention to grant announced |
Effective date: 20191030 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
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: 20200310 |