IC card with hierarchical file structure
1 claim: 1 independent, 0 dependent
- 1An integrated circuit card comprising:- a processing controller (2);- non-volatile memory means (4) having a plurality of key files (20) and data files (32) in a hierarchical structure, each key file having one or more key boxes with key box numbers for storing key data and each data file having an access conditions controller (80) for a key check in each level of said hierarchical structure, the data stored in the access conditions controller (80) of a certain data file determining certain levels of the hierarchical structure, such that keys valid at these levels may be used for controlling access to said data file;- volatile memory means (3) including a key verification indication table (71) for storing data indicative of the verification of keys at the various levels in a plurality of data fields corresponding to the various levels, each data field having one or more areas corresponding to said one or more key boxes;wherein the access conditions controller (80) comprises an access key box designation table (81) for designating key box numbers at which data indicative of the verification of keys must be checked, and a matching condition settings table (84) for designating one or more data fields of said key verification indication table (71) from which the data indicative of the verification of keys are collected and used for checking, said processing controller (2) being adapted for controlling access to a certain data file based on a result of a check of the data indicative of the verification of keys stored in areas of said key verification indication table (71) designated by said access key box designation table (81) and said matching conditions settings table (84) comprised in the access conditions controller (80) of said certain data file.
61 paragraphs, as filed
0001The present invention relates to an integrated circuit card for controlling, using key referencing data, access to plural files contained therein.
0002Conventional integrated circuit cards ("IC cards") typically have a two level logical structure as shown in Fig. 12. The internal memory 200 of the IC card contains a single parent file 201 located in the first level, and a plurality of child files 202, 203 located in the second level. The child files 202, 203 may be used by different applications. The parent file 201 is used by a plurality of applications, and stores common data 204 such as the cardholder's name, address and telephone number, and a global key 205 that is not dependent upon the application. The child files 202, 203 store application-specific data 206, 208 and a local key 207, 209. The global key 205 and local keys 207, 209 (collectively the "keys" below) are used to control access to the parent 201 and child files 202, 203, and access to the common data 204 and application-specific data 206, 208 is only permitted after the required key has been correctly verified.
0003The conventional IC card file structure has only two levels, and access control is therefore also limited to these two levels. More specifically, if the global key 205 is correctly verified, the common data 204 as well as the application-specific data 206, 208 can be accessed, and if only a local key 207, 209 is verified, the specific data of the file protected by the verified local key can be accessed.
0004This file structure presents two problems. First, a file structure having three or more levels cannot be used because the access control method is limited to a two-level file structure. For example, if a grandchild file (not shown in the figures) belonging to one child file 202 is created, the local key 207 may be required to function as a global key for the dependent grandchild files, but this is not possible.
0005Second, anyone knowing the global key 205 (typically the card issuer) can access the application-specific data 206, 208 without knowing the local keys 207, 209. It is therefore not possible to create application-specific files that cannot be accessed by the card issuer, and file security cannot be assured.
0006From FR-A-2 635 891 (corresponding to US-A-4 985 615) an IC card is known having a first type of key data used for an access able/disable judgement for a common data file and all of the application data files, and a second type of key data used for an access able/disable judgement for a specific application data file and the common data file. A storage section for storing key data registered for the common data file and a storage section for storing a collation result of key data registered for the application data files are separately arranged. Upon selection of an application data file, when an application data file different from the currently selected application data file is selected, the letter collation result is set in a non-collation status. Thus key data is effective only when a corresponding application is selected.
0007It is an object of the present invention to resolve the above discussed problems by providing an IC card compatible with a hierarchical file structure and capable of maintaining the confidentiality of files from the card user.
0008To achieve this object, an IC card according to the present invention comprises a processing controller, non-volatile memory means and volatile memory means as specified in claim 1.
0009By providing an access conditions controller for each file, and setting in the access conditions controller of the associated file the level number of the key information to be referenced when determining to permit or deny file access, access control compatible with a hierarchical file structure can be achieved. By setting the access conditions controller so that only the key information of that file can be referenced, files independent of the card issuer can be created.
0010The present invention will become more fully understood from the detailed description given below and the accompanying diagrams wherein: <ul id="ul0001" list-style="none" compact="compact"><li>Fig. 1 is a block diagram of an IC card according to an embodiment of the invention,</li><li>Fig. 2 is a block diagram of the non-volatile memory in an IC card according to the invention,</li><li>Fig. 3 is a block diagram of the key file structure in an IC card according to the invention,</li><li>Fig. 4 is a diagram of the RAM in an IC card according to the invention,</li><li>Fig. 5 is a block diagram of the data file structure in an IC card according to the invention,</li><li>Fig. 6 is a block diagram of the directory in an IC card according to the invention,</li><li>Fig. 7 is a flow chart of part of the access conditions control process in an IC card according to the invention,</li><li>Fig. 8 is a diagram of the RAM in an IC card according to the invention,</li><li>Fig. 9 is a flow chart of part of the access conditions control process in an IC card according to the invention,</li><li>Fig. 10 is a diagram of the RAM in an IC card according to the invention,</li><li>Fig. 11 is a diagram of the RAM in an IC card according to the invention, and</li><li>Fig. 12 is a block diagram of the memory in a conventional art IC card.</li></ul>
0011The embodiment of an IC card with a hierarchical file structure according to the invention is described below with reference to the accompanying figures.
0012Fig. 1 is a block diagram of the embodiment of this IC card 1 comprising a processing controller 2, RAM 3, and non-volatile memory 4. The processing controller 2 has an input/output control 5 and a command processor 6. The command processor 6 has an access control 7 which has a first comparator 8 for comparing the input key data and registered key data, and a second comparator 9 for comparing 8-bit data formed in RAM 3 and 8-bit data stored in memory 4, as will be described in detail later. The processing controller 2 may be formed in hardware using a CPU, ROM, input/output control, or other device, but is represented in Fig. 1 as a processing block achieved by means of a software program stored in a ROM device. A detail of this processing control 2 is described below.
0013The non-volatile memory 4 stores a plurality of files as shown in Fig. 2 in a logical file structure with five levels. Level 1 has a master directory, one key file 10 and one data file 11. Each of levels 2-5 has one or more directories, key files and data files. For example, level 2 has two directories, two key files and two data files 21 and 22.
0014As shown in Fig. 3, key file 20 for the level 2 has eight key boxes, and each key box has a key flag area 20a in which a key flag indicating whether or not key data is stored, and a key data area 20b in which key data are stored. Thus, the key file can store, at the maximum, eight different keys. Such keys may be registered by the holder (user) of the IC card, and/or by the distributor (bank, telephone company, etc.) of the IC card. The other key files have the same structure as the key file 20.
0015Each data file and key file are managed by the directory 61, which has as shown in Fig.6, a current level indicator 91 for indicating the current directory level and a parent pointer 92 for indicating the parent directory.
0016As shown in Fig. 5, each data file, such as data file 32 at the third hierarchical level 3, comprises a data area for storing data. Each data file further has an access condition controller (ACC) 80 which comprises an access key box designation table 81 and a logic conditions area 82. The logic conditions area 82 further comprises a horizontal matching condition settings area 83 and a vertical matching condition settings table 84. The values set in the access conditions controller 80 differ for each data file.
0017The access key box designation table 81 is usually set by the card distributor and designates the key box numbers at which stored key data requires verification. In the example, it is indicated that the key data from key boxes 1 and/or 2 is (are) required to be verified. When both key data from key boxes 1 and 2 should be verified before allowing an access to the file, the horizontal matching condition settings area 83 is set to "1", but when at least one of the key data from key boxes 1 and 2 is sufficient, the horizontal matching condition settings area 83 is set to "0". In other words, horizontal matching condition settings area 83 sets logical AND condition or logical OR condition for the designated key box numbers.
0018The vertical matching condition settings table 84 is also usually set by the card distributor and sets the levels from which the key files are collected and can be used for checking. The data stored in vertical matching condition settings table 84 is used for controlling switches SW1-SW5 inserted in the lines connected to OR gate 70 in Fig. 4, as will be explained later. In the example, it is indicated that the key files from levels 1, 2 and 3 can be used for checking.
0019The RAM 3 contains a key verification indication table 71, which is divided into five fields corresponding to the five levels of the hierarchical structure shown in Fig. 2, and each field comprises eight bits corresponding to eight key box numbers (where bit 1 is equivalent to key box number 1). For example, if the key data in key box 1 in level 1 is verified, indicator at right top corner in the key verification indication table 71 is set to "1", as shown in Fig. 4. Also, if the key data in key box 2 in level 3 is verified, the indicator at corresponding area in the key verification indication table 71 is set to "1". The indicator "1" in table 71 means that the corresponding key has been verified.
0020The RAM 3 further has a logical OR table 72 which takes logical OR along each column in table 71 by an OR gate 70 provided in association with RAM 3. According to the above example, the right two bits are set "1" and the remaining bits are set "0". Switches SW1-SW5 are connected to five input lines connected to OR gate 70, respectively. Switches SW1-SW5 turn ON when corresponding bit in vertical matching condition settings table 84 is "1". Thus, according to the example shown in Fig. 5, switches SW1-SW3 are ON and switches SW4 and SW5 are OFF. Instead of OR gate, it is possible to use AND gate at 70.
0021In operation, it is assumed that data file 32, such as for bank cashing, has been selected for having an access.
0022First, the user inserts the IC card in a cash dispenser (not shown). Upon insertion of the IC card, the cash dispenser automatically sends an identification key data, together with data indicating key file 10 in level 1 and data indicating key box 1, through input/output 5 to command processor 6. Then the access control 7 reads, in accordance with the received data of level 1 and key box 1, the key data stored in the key box 1 of the key file 10 in level 1, and compares in the first comparator 8 the received identification key data with the key data stored in the key box 1 of the key file 10 in level 1. If these two keys match, the first comparator 8 generates "1" and is stored RAM 3, particularly in table 71 at area corresponding to key box 1 in level 1.
0023Thereafter, the user selects a "cashing" button on the cash dispenser, and inputs his own secret key data through a keyboard. By the depression of "cashing", the access control 7 is informed that the key data for matching is stored in key box 2 of key file 30 in level 3. Then, in the first comparator 8, the secret key data inputted by the user is compared with the key data stored in key box 2 of key file 30 in level 3. If these two keys match, the first comparator 8 again generates "1" which is stored in RAM 3, particularly in table 71 at area corresponding to key box 2 in level 3.
0024In the meantime, OR gate 70 takes logic OR in each column in table 71, i.e., among the same number key boxes, and stores the result in table 72. The 8-bit data stored in table 72 is applied to second comparator 9, which is an 8-bit comparator, for comparing 8-bit data stored in access key box designation table 81. When these two data meet the condition depending on the horizontal matching condition setting area 83, an access is granted to data file 32.
0025The process for accessing the data file 32 in level 3 will be further described in detail. As before, the file selection command is input to the input/output 5 and interpreted by the command processor 6. The command processor 6 searches for the file name specified by the external device (e.g, cash dispenser), and when successful transfers control to the access controller 7.
0026While the description so far has related to reading the data area, an access conditions controller is also provided for controlling write access. An access rights controller is also provided for each function, including key registration and updating.
0027Depending on the settings to the horizontal matching condition settings area 83 and the vertical matching condition settings table 84, access can be controlled in various ways. A typical example is described below. In this example there is a card issuer key (key number 1) and a cardholder personal identification number (PIN) key (key number 2) both stored at key file 10 (level 1), and a terminal key (key number 1) stored at key file 30 used by the application using the data file 32 on the terminal.
0028If verification of both the PIN and the terminal key is required to read the data area of file 32 in this application, the horizontal access condition is set to the logical product (set in the horizontal settings area) of the key number 1 key and the key number 2 key (set in access key box designation table 81) for the read function of the data area. To enable processing when the card is issued using the card issuer key in place of the terminal key, those parts of the vertical matching condition settings table 84 corresponding to levels 1 and 3 are set to "1." Conversely, to protect the data area against access even by the card issuer, only level 3 is set to "1" in the vertical matching condition settings table 84. Private files that cannot be accessed by the card issuer can thus be created in the IC card.
0029To enable the cardholder to update the PIN without assistance from the issuer, and to enable the issuer to provide assistance in the case the cardholder forgets the PIN, the horizontal access condition by horizontal matching condition settings area 83 is set to "0" for taking the logical OR of key numbers 1 and 2 for the PIN update function.
0030It is therefore possible to provide files that are independent of the issuer, and to control access in various ways. In addition, the number of file levels is not limited by this access control method.
0031It is to be noted that the structure of the vertical matching condition settings table 84 in this embodiment has been described as specifying the level number used in the logical OR calculations, but shall not be so limited, any method enabling identification of the method of calculating the logical OR can be used.
0032The method of retaining or destroying the information of the key verification indication table 71 (herein after referred to as key information) when a different file is selected is described below. It is preferable that keys on the higher levels can also function as global keys for lower level files. A typical example of this is the PIN. Users may often want to use the same PIN for plural applications. In this case, the one PIN is registered at the highest level of the file structure branch in which the plural files are stored rather than storing the PIN with each file. The single PIN can thus be used to access all files lower in the hierarchy. This global key concept is not limited to PIN applications, however, and can be applied to any desired key. Rather than enabling only the key registered in the highest level of the file structure to function as a global key, greater utility can be achieved by enabling any key registered at level n to function as a global key for files stored at all levels below level n in the hierarchy.
0033To enable this, the key information for files on a common branch in the file structure must be retained when two or more files are selected. Referring to Fig. 2, if the previously selected file is file 32 and a newly selected file is file 41, the key information up to level 2 is retained because the branches on which file 32 and file 41 are located start from the same level 2. Because the key file 30 for data file 32 (level 3) has no relationship to file 41, however, access to file 41 using the key file 30 must be prohibited for security. The key information for level 3 is therefore destroyed.
0034So that this process can be applied to various cases, the key verification indication table 71 shown in Fig. 4 comprises fields for each level as described above, and each file directory contains the information shown in Fig. 6 (in addition to file address and other information). Only that information required for this description is shown in Fig. 6.
0035Note that each directory retains the same information shown in Fig. 6. The current directory 91 is the number of the current level on which the file is located; for file 32 this is "3." The parent pointer 92 indicates (e.g., the position of the directory of the parent file) the parent file of this file. Thus, the directory of file 32 stores "the directory of file 22" as a parent pointer 92. Because there is no parent file for file 11, such information is written to the file 11 parent file pointer.
0036The process executed using this information is described below with reference to Fig. 7. Fig. 7 is a flow chart for part of the access controller 7 shown in Fig. 1, specifically for processing the key information in the file selection command process. Note that in the following description the previously selected file is file A (data file 32), and the newly selected file is file B (data file 41).
(1) Steps 301 - 304
0037The level numbers of data files A (32) and B (42) are compared. If they are the same, X is registered with the file number of file A and Y with the file number of file B, and the process advances to (2) below.
0038If they are different, X is registered with the file number of a file with a higher level number (in this case, X-32). For the file with a lower level number, the file tree structure is searched upward until the level equal to the level number of X is reached, and the reached file number is registered in Y (in this case, Y-31). Then, the process advances to (2) below.
(2) Steps 305 - 208
0039The common level number of the files registered in X and Y is detected and registered in L (in this case, L-3). At step 306, it is detected whether or not X=Y. In this case, since X=32 and Y=31, the process advances to Step 308 at which X and Y are registered with the parent file number of the current indicated file. Thus, at step 308, X=22 and Y=22 are set. Then, again at step 305, the common level number between the files registers in X and Y is detected and registered in L (in this case, L-2). In this manner, if the files registered in X and Y are not the same file, X and Y are reassigned to their parent files, and the loop is repeated until X=Y is obtained. At step 306, when X and Y are registered with the same file, i.e., X=Y, the process advances to step 307. In step 307, the key information from level 1 to level L is retained, and the key information for levels below L is destroyed to terminate the loop.
0040Loop (2) is thus repeated until X and Y are the same. Because there is only one root file in an IC card as shown in Fig. 2, the loop will always end with L ≥ 1. The level numbers of each file shown in Fig. 6 are used to determine the level numbers of X and Y, and the parent pointer is used to determine the parent file of each file.
0041The adaptability of this procedure to various cases is described specifically below with reference to the file structure shown in Fig. 2.
0042If the previously selected file (file A) is file 32 (level 3) and the newly selected file (file B) is file 51 (level 5), X = file 32 because file 32 is on a higher level. By tracing back to level 3 to find the parent file of file 51, Y is set to file 32. Level L is thus 3. Because X = Y = file 32, the key information for levels 1 - 3 is retained, and the key information for levels 4 and 5 is abandoned. In this case, however, there is actually no change because the previously selected file (file 32) was at level 3.
0043However, if the previously selected file (file A) was file 51 (level 5) and the newly selected file (file B) was file 32 (level 3), the key information for levels 1 - 3 is retained and the key information fetched for levels 4 and 5 is destroyed.
0044In a different case in which the previously selected file (file A) is file 41 (level 4) and the newly selected file (file B) is file 51 (level 5), X = file 41, Y = file 42, and L = 4. Because X and Y are different files, the parent files of each are located to redefine X and Y to file 31 and file 32, respectively. The level L is 3. Because X and Y still reference different files, the parent files are again searched, resulting in X = parent file 22 and Y = parent file 22. X and Y now match and the level L = 2. The key information for level numbers 1 and 2 is therefore retained, and all key information for levels 3 - 5 is destroyed.
0045If the previously selected file and the newly selected file are the same file, file access can still be correctly processed by this procedure.
0046The description of this file structure has so far been limited to a file system in which only one file can be opened and in use at one time. When the file system has a limit of one open file at a time and it becomes necessary to access another file while working with the first file, the first file must be closed, the file to be accessed selected, and the required key verified before processing continues. Repeating this sequence of operations becomes increasingly inefficient when two files must be alternately accessed. Being able to simultaneously open and access more than one file at a time would therefore be extremely convenient and helpful.
0047To simplify the following description, the process whereby two files are simultaneously opened and accessed using two channel numbers (A, B) is described below. Which of the two open files is accessed is specified by the channel number in the command. To enable simultaneous opening of two files, separate key verification indication tables 71, 73 are provided for each channel in the RAM 3 as shown in Fig. 8. The key verification indication table 73 for channel B does not have a field for level 1 because level 1 is always common to both channels.
0048Whether the key information is held or destroyed depends on the level structure of the file and not on the channel. In other words, if the previously selected files on channels A and B are files P and Q, and the newly selected file on channel A is file R, the sum set of the key information common to the common branch of files P and R and the key information common to the common branch of files Q and R is retained.
0049More specifically, let us assume that file 41 in Fig. 2 is file P, file 51 is file Q, and file 43 is file R. Following the procedure described above, the key information to level 2 is retained based on the relationship between files 41 and 43. In addition, the key information to level 3 is also retained based on the relationship between files 51 and 43. Because the former key information is also contained within the latter key information set, the key information for channel A contains the key information for the latter, specifically for level 3 common to files 51 and 43.
0050The method whereby this process is executed for all cases is described below with reference to Fig. 9. Fig. 9 is a flow chart for part of the access controller 7 shown in Fig. 1, specifically for processing the channel A key information.
(1) Step 311
0051The key information for channel A is held or destroyed based on the relationship between files P and R. (The specific method conforms to the process described above for a file system enabling only one open file at a time.)
(2) Step 312
0052The level numbers 1 - L for which the key information is to be retained are obtained from the relationship between files Q and R. (The specific method conforms to the process described above for a file system enabling only one open file at a time.)
(3) Step 313
0053The channel B key information for levels 2 - L is copied to the channel A key information. (The channel B key information does not change because there is no change in the selected files.)
0054This process is described specifically below referring to Fig. 2 and assuming that file 41 is file P, file 51 is Q, and file 43 is R. If the initialized state is as shown in Fig. 8, the channel A key information holds the data for levels 1 and 2 as shown in Fig. 10 as a result of step 311 above. Step 312 yields level L = 3, and the channel B key information for levels 2 and 3 is copied to the channel A key information area in step 313, resulting in the values shown in Fig- 11.
0055Copying the key information for level 2 is redundant in step 313 above because level 2 is common to all three files 41, 51, and 43. The present method is still extremely effective, however, considering that there are any number of ways different files can be selected, and is applicable to all possible cases while remaining extremely simple. It is difficult to determine the branches common to plural files for each of the many different possible file selections in order to eliminate this redundancy, and the present method is thus more effective.
0056Another benefit of this method is expandability. For example, when the number of simultaneously usable files is increased to three or more (A, B, C, ,·····), it is sufficient t'o simply continue looping through step 313. The present method is therefore superior in terms of program size, processing speed, and expandability.
11 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US10187904B2 | Cited by | United States of America | Applicant |
| EP0479655A | Cites | European Patent Office (EPO) | – |
| WO9213322A | Cites | World Intellectual Property Organization (WIPO) | – |
| FR2635891A | Cites | France | – |
| F. Guez et al., Les cartes à microcircuit, Techniques et applications, Paris 1988, IBN 2-225-81346-9, pages 153 to 156. | Non-patent | – | – |
| A working draft of standard ISO/IEC 7816-4 | Non-patent | – | – |
| Standard CEN/TC 224 N 16, dated 07.05.1990: Requirements for intelligent cards and terminals for telecommunication use - Part 2 Application independent card requirements (Draft 3). Source: STC TE9 Project Team 14. | Non-patent | – | – |
| Interim European Telecommunication Standard, 2nd Final Draft pr I-ETS 300 045, February 1992, Reference:GSM 11.11 - version 3.10.0, pages 1 to 99, in particular chapter 3.4.2 "Semantics of the data field" (pages 11/12) and page 40 "SIM Implementation Model". Standard TE9, superseded by standard BS EN 726-3. | Non-patent | – | – |
| F. Guez et al., Les cartes à microcircuit, Techniques et applications, Paris 1988, IBN 2-225-81346-9, pages 153 to 156. | Non-patent | – | Opposition |
| A working draft of standard ISO/IEC 7816-4 | Non-patent | – | Opposition |
| Standard CEN/TC 224 N 16, dated 07.05.1990: Requirements for intelligent cards and terminals for telecommunication use - Part 2 Application independent card requirements (Draft 3). Source: STC TE9 Project Team 14. | Non-patent | – | Opposition |
| Interim European Telecommunication Standard, 2nd Final Draft pr I-ETS 300 045, February 1992, Reference:GSM 11.11 - version 3.10.0, pages 1 to 99, in particular chapter 3.4.2 "Semantics of the data field" (pages 11/12) and page 40 "SIM Implementation Model". Standard TE9, superseded by standard BS EN 726-3. | Non-patent | – | Opposition |
13 members in 5 offices; this record represents the family
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 21581792 | Japan | – | |
| 21581792 | Japan | A | |
| 27988492 | Japan | – | |
| 27988492 | Japan | A |
Members13
| Document | Office | Kind | |
|---|---|---|---|
| EP0583006A2 | European Patent Office (EPO) | A2 | |
| JPH0660235A | Japan | A | |
| KR940004469A | Republic of Korea | A | |
| JPH06131517A | Japan | A | |
| EP0583006A3 | European Patent Office (EPO) | A3 | |
| US5408082A | United States of America | A | |
| JP2502894B2 | Japan | B2 | |
| KR970006648B1 | Republic of Korea | B1 | |
| EP0583006B1 | European Patent Office (EPO) | B1 | |
| DE69320900D1 | Germany | D1 | |
| DE69320900T2 | Germany | T2 | |
| EP0583006B2This record | European Patent Office (EPO) | B2 | |
| DE69320900T3 | Germany | T3 |
41 legal events, as 3 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Patent expired after termination of 20 yearsExpiredPE20 | PE20 | GB | |
| Expiry of rightR071 | R071 | DE | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Fr: translation filed ** decision concerning oppositionOppositionET3 | ET3 | EP | |
| Patent maintained in amended form27A | 27A | EP | |
| Designated contracting statesAK | AK | EP | |
| Patent maintained in amended formORIGINAL CODE: 0009272PUAH | PUAH | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: PATENT MAINTAINED AS AMENDEDSTAA | STAA | EP | |
| Appeal procedure closedAppealORIGINAL CODE: EPIDOSNNOA9OAPBU | APBU | EP | |
| Opposition filed (corrected)OppositionR26 | R26 | EP | |
| Opposition data, opponent's data or that of the opponent's representative modifiedOppositionORIGINAL CODE: 0009299OPPOPLAB | PLAB | EP | |
| Appeal reference modifiedAppealORIGINAL CODE: EPIDOSCREFNOAPAH | APAH | EP | |
| Receipt of observations in appeal recordedAppealORIGINAL CODE: EPIDOSNOBA4OAPCA | APCA | EP | |
| Communication from the board of appeal sentAppealORIGINAL CODE: EPIDOS OBAPOAPCC | APCC | EP | |
| European patent in force as of 2002-01-01IF02 | IF02 | GB | |
| Appeal dossier modifiedAppealORIGINAL CODE: EPIDOS NOAPOAPAC | APAC | EP | |
| Appeal reference modifiedAppealORIGINAL CODE: EPIDOS REFNOAPAE | APAE | EP | |
| Appeal dossier modifiedAppealORIGINAL CODE: EPIDOS NOAPOAPAC | APAC | EP | |
| Patent revokedRevokedORIGINAL CODE: EPIDOS REVORDAH | RDAH | EP | |
| Reply of patent proprietor to notice(s) of oppositionOppositionORIGINAL CODE: EPIDOS OBSOPLBF | PLBF | EP | |
| Reply of patent proprietor to notice(s) of oppositionOppositionORIGINAL CODE: EPIDOS OBSOPLBF | PLBF | EP | |
| Opposition filedOpposition26 | 26 | EP | |
| Opposition filedOppositionORIGINAL CODE: 0009260PLBI | PLBI | EP | |
| Fr: translation filedET | ET | EP | |
| Corresponds to:REF | REF | EP | |
| Designated contracting statesAK | AK | EP | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOS IGRAGRAH | GRAH | EP | |
| Despatch of communication of intention to grantORIGINAL CODE: EPIDOS AGRAGRAG | GRAG | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOS IGRAGRAH | GRAH | EP | |
| Despatch of communication of intention to grantORIGINAL CODE: EPIDOS AGRAGRAG | GRAG | EP | |
| First examination report despatched17Q | 17Q | EP | |
| Designated contracting statesAK | AK | EP | |
| Search report despatchedORIGINAL CODE: 0009013PUAL | PUAL | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 0583006
- Application
- 931128367
Titles3
- German
- IC-Karte mit hierarchischer Dateienstruktur
- English
- IC card with hierarchical file structure
- French
- Carte IC avec structure de fichier hiérarchique
Classification
- CPC, 4
- G07F7/1008
- G06K19/073
- G06Q20/341
- G06Q20/35765
- IPC, 3
- G06K19 07
- G06K19 073
- G07F7 10
Designated states3
- Contracting states, 3
- Germany
- France
- United Kingdom
