CN105447424B - Method for reading contact information in intelligent card - Google Patents

Abstract

The present invention discloses a method for reading contact information in a smart card. In the startup process of a user device, the main part of the main basic file of the contact in the smart card memory is read, and the main part of the type 1 basic file, the type 2 basic file or the type 3 basic file is selectively read according to the validity or connectivity of each data in the main basic file of the contact, so as to avoid unnecessary reading of the main part of the unused data in other types of basic files in the contact, thereby improving the startup efficiency.

Description

Method for reading contact person information in smart card

technical field

The invention relates to a method for reading contact person information in a smart card, in particular to a method for reading basic files of relevant contact person information in a smart card.

Background technique

A Subscriber Identity Module (SIM) card is a smart card used to store subscriber identification data for mobile phone services, and can also be used to store SMS data and phone numbers. In terms of external hardware, the SIM card consists of a central processing unit (CPU), a read-only memory (ROM), a random access memory (RAM), an electronic erasable program It is composed of components such as electrically erasable programmable read-only memory (EEPROM) and input/output (I/O) circuits. In terms of internal data, the SIM card adopts a hierarchical (hierarchical) logical data structure, which includes elementary files (elementary file, EF), dedicated files (dedicated file, DF) and main files (master file, MF) etc. types of data.

The basic file includes a header (header) and a body part (body part), and its data structure is divided into three types: transparent (transparent), linear fixed (linear fixed) and cyclic (cyclic). data. The transparent basic file is a continuous data file with the unit of byte (byte), and data access is handled by specifying the offset (offset) position and the access data length. The linear fixed basic file and the circular basic file are continuous and fixed-length data files with the unit of record (record), and the data access is based on the unit of record. In addition, the header of the basic file indicates the total length of the data and the number of data items.

According to the specification TS 31.102 formulated by the 3rd Generation Partnership Project (3GPP), the SIM card can use different basic files to store various types of contact characteristics, such as the name of the contact, the main phone number, Information such as a secondary phone number, email or group. In the prior art, the user equipment will first read the basic file EF _PBR of the phone book reference file (phone book referencefile) in the memory of the SIM card in the boot process to know all the contact characteristics supported by the SIM card, and then Read the header and body sections of all relevant elementary files. However, not every contact uses all types of contact characteristics. Assuming that the SIM card can support four contact characteristics of name, main phone number, secondary phone number and email, but the user only stores the main phone number of a specific contact, the existing technology will still read the relevant name at this time. , primary phone number, secondary phone number, and the header and body of the 4 basic files. Therefore, the prior art may spend a lot of time reading headers and body parts of unused elementary files, thereby affecting boot efficiency.

Contents of the invention

In view of the above-mentioned problems in the prior art, the purpose of the present invention is to provide a method for reading contact information in a smart card, so as to improve booting efficiency.

In order to achieve the above purpose, the present invention discloses a method for reading contact information in a smart card, which includes installing the smart card into a user equipment; A body part of a main elemental file; read a header of a type-elementary file in the memory of the smart card, and only when a specific data in the body part of the main elemental file corresponds to a valid content Read corresponding first data in a body portion of an elementary file of the type.

Description of drawings

FIG. 1A and FIG. 1B are flowcharts of a method for reading contact information in a smart card in the present invention.

FIG. 2 is a schematic diagram of a phonebook reference file elementary file EF _PBR defined according to the 3rd Generation Partnership Project specification.

FIG. 3 is a schematic diagram of an abbreviated dialed number elementary file EF _ADN defined according to the 3rd Generation Partnership Project specification.

FIG. 4 is a schematic diagram of an index management phonebook elementary file EF _IAP defined according to the 3rd Generation Partnership Project specification.

Fig. 5 is a schematic diagram of reading different types of basic file body parts according to a comparison table in an embodiment of the present invention.

Wherein, the reference signs are explained as follows:

110～220 steps

11~16 fields

Detailed ways

The invention provides a method for reading contact information in a smart card, which can be applied to different types of user equipment, including mobile phones, personal digital assistants (personal digital assistants, PDAs), palm-sized (handheld) computers, tablet (tablet) Computer, mini desktop (nettop) computer, notebook (laptop) computer, or other devices with communication functions. However, the type of user equipment does not limit the scope of the present invention.

In the user equipment to which the method of the present invention is applied, different types of smart cards can be installed therein, such as the subscriber identity module card of the global system for mobile communications (GSM) system, the universal mobile telecommunications system (universal mobile telecommunications system , UMTS) universal subscriber identity module (USIM) card, code division multiple access (code division multiple access, CDMA) system removable user identity module (removable user identity module, R-UIM) card and code division multiple access user Identification Module (CSIM) card, etc. Although the description of the present invention uses the subscriber identity module card to illustrate the embodiment, the type of smart card installed in the user equipment does not limit the scope of the present invention.

In the user equipment to which the method of the present invention is applied, smart cards of different sizes can be installed therein, such as standard subscriber identity module card (Mini SIM), micro subscriber identity module card (Micro SIM) or nanometer subscriber identity module card (NanoSIM) Wait. However, the size of the smart card installed in the user equipment does not limit the scope of the present invention.

Fig. 1A and Fig. 1B are a kind of flow chart of the method for reading contact information in the smart card among the present invention, and it comprises the following steps:

Step 110: In the boot process, read the phonebook reference file EF _PBR installed in the smart card installed in the user equipment to obtain all the contact characteristics supported by the smart card; execute step 120.

Step 120: Read the header of the basic file related to the supported contact characteristics in the smart card memory; execute step 130.

Step 130: Read each piece of data in the main part of the basic file EF _ADN in the memory of the smart card for abbreviated dialing numbers (abbreviated dialing numbers); execute step 140.

Step 140: Record the i-th piece of data corresponding to the valid content in the main part of the abbreviated dialing number basic file EF _ADN in a first comparison table; execute step 150.

Step 150: Selectively read the main body part of all Type 1 basic files related to the characteristics of the supported contacts according to the first comparison table; execute step 160.

Step 160: Determine whether the read type-basic file includes an index management phone book (indexadministration phone book) basic file EF _IAP ; if so, execute step 170; if not, execute step 190.

Step 170: Record the i-th data corresponding to the effective pointer in the main part of the index management phonebook basic file EF _IAP selectively read according to the first comparison table in a second comparison table; execute step 180.

Step 180: Read the main body of a related Type 2 (Type 2) basic file according to the second comparison table; execute step 190.

Step 190: After selectively reading the main body of a specific type of basic file according to the first comparison table, determine whether the specific type of basic file needs to be linked to a related type three (Type 3) basic file: if yes, perform the steps 200 ; if not, go to step 220 .

Step 200: Record the i-th data corresponding to the effective content in the specific type-1 basic file and linked to the relevant type-3 basic file in a third comparison table; execute step 210.

Step 210: read the main part of the relevant type three basic file according to the third comparison table; perform step 220.

Step 220: end.

FIG. 2 is a schematic diagram of an elementary file EF _PBR of a phonebook reference file defined according to the 3rd Generation Partnership Project specification TS 31.102. As shown in field 11, bytes 1 to X (X is an integer greater than 1) are used to store tag length value (TLV) objects representing basic files included in the phonebook structure. The definition of other fields in the basic file EF _PBR of the phonebook reference file is detailed in the 3rd Generation Partnership Project specification TS 31.102, and will not be repeated here.

In step 110, the present invention can read the basic phonebook reference file EF _PBR in the smart card memory during the boot process of the user equipment, and judge all the contacts supported by the smart card according to the tag length value objects represented by bytes 1 to X. human characteristics. In the embodiment of the present invention, the abbreviations and types of the basic files related to the contact characteristics supported by the smart card are shown in the following table:

name type one type two type three EF _AAS x EF _ADN x EF _ANR x x EF _EMAIL x x EF _EXT1 x EF _GAS x EF _GRP x EF _IAP x EF _PBC x EF _SNE x x EF _UID x EF _CCP1 x

EF _AAS stands for type 3 additional number Alpha string (additional number Alpha string) basic file, which is used to store name tags related to user-defined additional numbers. EF _ADN stands for Type 1 Abbreviated Dialing Number Elementary File, and its structure will be described in detail later in the manual. EF _ANR stands for type 1 or type 2 additional number (additional number) elementary file, which is used to store multiple groups of abbreviated dial numbers or supplementary service control (supplementary service control, SSC) strings. EF _EMAIL represents a type 1 or type 2 email element file, which is used to store a contact's email. EF _EXT1 represents type 3 extension 1 (extension1) basic file, which is used to store data beyond 20 digits in abbreviated dial numbers or supplementary service control strings. EF _GAS represents a grouping information Alpha string (grouping information Alpha string) basic file of type 3, which is used to store the grouping name of the contact. EF _GRP represents a type 1 grouping file basic file, which is used to store the grouping information of related pen data in the basic file EF _ADN of the abbreviated dialing number. EF _IAP stands for Type 1 Index Management Phonebook Elementary File, which is used to store pointers linked to Type 2 Elementary File. EF _PBC represents a phone book control (phone book control) basic file of type 1, and is used to store control information related to pen data in the basic file EF _ADN of abbreviated dialing numbers. EF _SNE stands for type 1 or type 2 second name entry (second name entry) elementary file. EF _UID represents a type-one unique identifier (uniqueidentifier) elementary file. EF _CCP1 represents the basic file of type three function configuration parameters (capability configuration parameters 1).

In the phonebook reference file elementary file EF _PBR , the first data name marked with the label "A8" corresponds to a main basic file (master EF), and the subsequent data names marked with the label "A8" correspond to type one The data name marked with the label "A9" corresponds to the basic file of type two, and the data name marked with the label "AA" corresponds to the basic file of type three. According to the 3rd Generation Partnership Project specification TS 31.102, the Abbreviated Dial Number Elementary File EF _ADN is the main elementary file. The type-one basic file and the main basic file include the same number of data items, and each data in the type-one basic file is mapped to a corresponding data in the main basic file in a one-to-one manner. The number of data items included in the type 2 basic file is less than the number of data items included in the main basic file, and each data in the type 2 basic file is linked to the main basic file through the type 1 index management phone book basic file EF _IAP The corresponding pen data in the file. Each piece of data in the type three basic file is linked to the corresponding data in the main basic file through the data identifier (record identifier) of the data included in other basic files in the type one phonebook reference file basic file EF _PBR .

In step 120, the present invention can read the header of the basic file related to the characteristics of the supported contacts in the memory of the smart card, and then know how many pieces of data and data length each basic file can write.

In step 130, the present invention can read each piece of data in the main part of the basic file EF _ADN of the abbreviated dialing number stored in the smart card. FIG. 3 is a schematic diagram of an elementary file EF _ADN for abbreviated dialed numbers defined according to the 3rd Generation Partnership Project specification TS 31.102. As shown in field 12, bytes 1 to X are alpha identifiers for the first to Xth phone numbers respectively. As shown in field 13, bytes X+3 to X+12 are used to store dialed numbers and supplementary service control strings. As shown in field 14, byte X+13 represents a capability/configuration 1 record identifier (capability/configuration 1 record identifier) string. As shown in field 15, byte X+14 represents an extension 1 record identifier (extension 1 record identifier) string. The definition of other fields in the basic file EF _ADN of the abbreviated dialed number is detailed in the 3rd Generation Partnership Project specification TS 31.102, and will not be repeated here.

As mentioned above, the basic file EF _ADN of the abbreviated dialing number is the main basic file, and will be mapped to other basic files of type 1 in a one-to-one manner. That is, when the i-th data of the main body in the abbreviated dialing number basic file EF _ADN corresponds to the valid content (not empty), the relevant i-th data in the main body of the basic file of other types will also correspond to the valid content . Therefore, the present invention can record each piece of data corresponding to valid content in the main part of the basic file EF _ADN of the abbreviated dialing number in the first comparison table in step 140 .

In step 150, the present invention selectively reads the main body of all types of basic files related to the supported contact features according to the first lookup table. More specifically, the present invention will determine whether to read the main body of all types of basic files related to the characteristics of the supported contacts according to whether each item of data in the first comparison table exists. For example, assuming that the i-th piece of data in the main body of the abbreviated dialing number basic file EF _ADN corresponds to valid content, but when the (i+1)-th piece of data corresponds to invalid content, the first comparison recorded in step 140 The i-th data will exist in the table, but the (i+1)-th data will not exist. Therefore, in step 150, the present invention can read the i-th item of data in the body part of the basic file of all types of supported contact characteristics, but will not read the (i+1)-th item of data.

FIG. 4 is a schematic diagram of an index management phonebook elementary file EF _IAP defined according to the 3rd Generation Partnership Project specification TS 31.102. As shown in field 16, bytes 1 to X are used to respectively store the record numbers of the first to Xth objects appearing after the tag A9. The definitions of other fields in the basic file EF _IAP for index management phonebook are detailed in the 3rd Generation Partnership Project specification TS 31.102, and will not be repeated here.

According to the content of the basic file EF _PBR of the phonebook reference file read in step 110, if it is known that the basic file related to the characteristics of the supported contacts includes the basic file EF _IAP of the index management phonebook, the present invention will be in step 150 according to the first The comparison table selectively reads the main part of the primary file EF _IAP for index management phonebook, and in step 160 it is known that the type-one basic file read includes the basic file EF _IAP for index management phonebook. According to the 3rd Generation Partnership Project specification TS 31.102, when the i-th data in the main part of the index management phonebook basic file EF _IAP is not "FF", it is a valid indicator, which means that the basic data of the related type 2 needs to be linked to The i-th data in the basic file EF _ADN of the abbreviated dialing number; when the i-th data in the main part of the index management phonebook basic file EF _IAP is "FF", it is an invalid indicator, which means that there is no need to link any type II basic data The path to the i-th data in the basic file EF _ADN of the abbreviated dialing number. Therefore, in step 170, the present invention can record the data corresponding to each valid pointer in the index management phonebook basic file EF _IAP in the second comparison table, and then selectively read according to the second comparison table in step 180. Get the main part of the relevant Type 2 basic file.

After selectively reading the main part of a specific type-elementary file according to the first comparison table, the present invention can determine in step 190 whether the specific type-elementary file needs to be linked to a related type-three elementary file.

In one embodiment, the specific type-elementary file may be a type-abbreviated dialed number elementary file EF _ADN . When the i-th piece of data in the main body of the abbreviated dialing number basic file EF _ADN corresponds to the valid content, it can be judged whether to link to the i-th piece of data of the specific type three basic file according to the specific byte in the valid data. Specifically, in the i-th piece of valid data in the basic file EF _ADN of the abbreviated dialing number, when the function/configuration 1 data identifier represented by byte X+13 corresponds to the valid content, it means that it needs to be linked to the Type 3 function The specific data of the configuration parameter type basic file EF _CCP1 ; when the extension 1 data identifier represented by byte X+14 corresponds to the valid content, it represents the specific data that needs to be linked to the type 3 extended basic file EF _EXT1 . Therefore, in step 200, the present invention can record the specific data that needs to be linked to the type three basic file in the third comparison table, and then in step 210, the extended basic file EF _EXT1 and/or can be read according to the third comparison table Or the main part of the function configuration parameter type basic file EF _CCP1 .

In other embodiments, a specific type one elementary file may be a type one extra number elementary file EF _ANR , which may need to be linked to a type three extra number alpha string elementary file EF _AAS . Therefore, in step 200, the present invention can record the specific data in the type one extra number basic file EF _ANR corresponding to the valid content and need to be linked to the type three extra number alpha character string basic file EF _AAS in the third comparison table, Then in step 210, the main part of the type 3 extra number alpha character string elementary file EF _AAS can be read according to the third comparison table.

In other embodiments, a specific type-elementary file may be a type-group archive elementary file EF _GRP , whose specific data may need to be linked to a type-three group information alpha string elementary file EF _GAS . Therefore, in step 200, the present invention can record the i-th data in the group archive basic file EF _GRP corresponding to the valid content and need to be linked to the type three group information alpha character string basic file EF _GAS in the third comparison table, and then In step 210, the main part of the basic file EF _GAS can be read according to the third look-up table.

According to the first comparison table, the present invention will only read the corresponding pen data in the main part of the type-basic file when a specific pen data in the main part of the abbreviated dialing number basic file EF _ADN corresponds to valid content; When a specific piece of data in the main body of the abbreviated dialing number basic file EF _ADN does not correspond to valid content, the corresponding pen data in the main body of the type-one basic file will not be read at this time.

According to the second comparison table, the present invention will only read the corresponding pen data in the type two basic file when a specific pen data in the main part of the index management telephone book basic file EF _IAP corresponds to an effective pointer; When the main part of a specific item of data in the basic file EF _IAP for managing the telephone book corresponds to an invalid index, the corresponding item of data in the main part of the Type II basic file will not be read at this time.

According to the third comparison table, the present invention only reads the relevant type three basic file body only when a specific piece of data in the specific type one basic file body part corresponds to valid content and includes a specific byte corresponding to a valid link The corresponding pen data in the section; when a specific pen data in the body part of a specific type-elementary file corresponds to the payload but does not include a specific byte corresponding to the valid link, the relevant type-three-base file will not be read at this time The corresponding pen data in the main part of the file.

Fig. 5 is a schematic diagram of reading different types of basic file body parts according to a comparison table in an embodiment of the present invention. For the convenience of explanation, it is assumed that in step 110, it is known that the smart card supports at least contact features such as contact number, contact email and contact grouping, that is, the relevant basic files include the main abbreviated dialing number basic file EF _ADN , and index management of type 1 Phonebook elementary file EF _IAP , type two electronic mail elementary file EF _EMAIL , and type three extension 1 elementary file EF _EXT1 . According to step 120, it is assumed that the main body part of each of the above-mentioned basic files includes 5 pieces of data. The upper part of FIG. 5 shows the method of reading the main body part of different types of basic files in steps 130 , 180 and 210 , while the lower part of FIG. 5 shows the comparison table recorded in steps 140 , 170 and 200 .

The first comparison table shown in FIG. 5 records that the 1st to 4th data in the main elementary file EF _ADN correspond to valid content (marked by an asterisk "*"), and the 5th data corresponds to invalid content. Therefore, the present invention only reads the 1st to 4th data (marked by a circle "○") of the main part of the type-one basic file EF _IAP , but does not read the 5th data.

The second comparison table shown in FIG. 5 records that the content of the first, third and fourth data items in the main part of the Type-1 basic file EF _IAP corresponds to valid indicators, and the content of the second data item corresponds to invalid indicators. Therefore, the present invention only reads the 1st, 3rd, and 4th data (marked by a circle "○") of the main part of the type 2 basic file EF _EMAIL , but does not read the 2nd and 5th data.

The third comparison table shown in FIG. 5 records that among the effective pen data in the main elementary file EF _ADN , only the second data (marked by an asterisk "*") that needs to be linked to the specific type three basic files. Therefore, the present invention only reads the second data (marked by a circle "O") in the main part of the type three basic file EF _EXT1 , but does not read the first, third to fifth data.

For the same situation, prior art can read all total 20 data in the main part of basic file EF _ADN , EF _IAP , EF _EMAIL and EF _EXT1 , and the present invention can only read basic file EF _ADN , EF _IAP , EF _EMAIL and 13 pieces of data are actually used in the main part of EF _EXT1 , so the boot time can be shortened.

To sum up, the present invention can selectively read the main part of other types of basic files according to the validity or linkability of each piece of data in the smart card memory abbreviated dialing number basic file EF _ADN . Therefore, the present invention can avoid unnecessarily reading unused data in the main body of other types of basic files, thereby improving booting efficiency.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims (10)

1. A method for reading contact person information in a smart card, characterized in that, comprising: installing the smart card into a user device; In a boot process of the user equipment, read a main part of a main basic file in the memory of the smart card; reading a header of a type-elementary file in the memory of the smart card, and only when a specific data in the body portion of the main elemental file corresponds to a valid content of the type-elementary file corresponding first data in a body part; and When the corresponding first data of the type-1 basic file corresponds to a valid pointer, read the corresponding second data in a body part of a type-2 basic file in the memory of the smart card. 2. The method according to claim 1, wherein the main basic file is an abbreviated dialing number basic file defined by a 3rd Generation Partnership Project specification. 3. The method according to claim 1, wherein said type-basic file is an additional number basic file defined by a 3rd Generation Partnership Project specification, a group file basic file, an index management phonebook Basic file, a phonebook control basic file, a second name input basic file, or a unique identification basic file. 4. The method of claim 1, wherein, an elementary file of said type is an indexed phonebook elementary file as defined by a 3rd Generation Partnership Project specification; and The Type 2 basic file is an additional number basic file, an email basic file, or a second name input basic file defined by the 3rd Generation Partnership Project specification. 5. The method of claim 1, further comprising: reading a phonebook reference file elementary file defined by the 3rd Generation Partnership Project specification to obtain one or more contact characteristics supported by the smart card, wherein the primary elementary file is associated with the type-elementary file on the one or more contact characteristics. 6. The method of claim 5, further comprising: Recording all data corresponding to valid content in the main part of the main basic file in a first comparison table; selectively read the body part of the type-elementary file according to the first comparison table; Recording all the data corresponding to valid pointers in the main part of the basic file of the type in a second comparison table; selectively read a main body part of a type 2 basic file according to the second comparison table; recording all the data corresponding to the specific bytes of the valid content and including the relevant valid links in the main body part of the main basic file in a third comparison table; and Selectively reading a body portion of a Type 3 elementary file according to the third lookup table, wherein the Type 2 elementary file and the Type 3 elementary file are related to the one or more contact characteristics. 7. A method for reading contact person information in a smart card, characterized in that, comprising: installing the smart card into a user device; In a boot process of the user equipment, read a main part of a main basic file in the memory of the smart card; reading a header of a type-elementary file in the memory of the smart card, and only when a specific data in the body portion of the main elemental file corresponds to a valid content of the type-elementary file corresponding first data in a body part; and When the specific data of the main elementary file corresponds to the valid content and includes a specific byte related to a valid link, read the corresponding first in a body part of a type three basic file in the memory of the smart card Three data. 8. The method according to claim 7, wherein the three basic files of the type are an additional number alpha character string basic file, an extension 1 basic file, a grouping An informational alpha string elementary file, or a functional configuration parameter elementary file. 9. A method for reading contact person information in a smart card, characterized in that, comprising: installing the smart card into a user device; In a boot process of the user equipment, read a main part of a main basic file in the memory of the smart card; reading a header of a type-elementary file in the memory of the smart card, and only when a specific data in the body portion of the main elemental file corresponds to a valid content of the type-elementary file corresponding first data in a body part; and When the corresponding first data of the type-elementary file includes a specific byte related to a valid link, read the corresponding third data in a body part of a type-3 elementary file in the memory of the smart card. 10. The method of claim 9, wherein: When the type-one basic file is an additional number basic file defined by a 3rd Generation Partnership Project specification, the type-three basic file is an additional number alpha character defined by the 3rd Generation Partnership Project specification string basic files; and When the Type 1 basic file is a grouping archive basic file defined in the 3rd Generation Partnership Project specification, the Type 3 basic file is a grouping information alpha defined in the 3rd Generation Partnership Project specification String base file.