KR20050034058A - Compression saving method and search method of card black-list data - Google Patents

Abstract

In the BL data-based card payment system or WL (White List) data-based card payment system that collects the purchase price or transportation fee, the compression method of the card number list data used to store or transmit the card number list data received from each card company In;

Sector number of the upper two bytes among the values converted from the 1st to 6th digits (decimal value or binary value) of the 16 digits of the card number into BIN, and the 7th through 15th numbers into 4 byte binary code. When the lower 2 bytes are designated as BL value,

A BL storage area composed of BL blocks in which BL values having the same BIN and sector number are collected;

And a structure of a data page consisting of an index table area indicating a storage location of BL blocks corresponding to a specific BIN and sector number.

Description

Compression and Storage Method of Card Blacklist Data and Search Method thereof {COMPRESSION SAVING METHOD AND SEARCH METHOD OF CARD BLACK-LIST DATA}

The present invention relates to a black list (BL: bad credit card and lost card list) data-based card payment system for quickly and accurately collecting transportation charges or purchase price of goods or services, and particularly, a BL data storage space of a card terminal. The present invention relates to a storage method that can significantly reduce the search speed and can easily update the BL.

Recently, smart card-type electronic money has been widely used around transportation cards. Among these, prepaid electronic money can reduce the inconvenience of having to refill the amount in advance unlike the prepaid method. In particular, it is widely used as an add-on to credit cards.

The postpay method collects the usage history of the transportation card in the settlement server and pays the postpay in a similar manner to the credit card payment.

However, almost all recently issued credit cards include the function of postpaid transit cards, and BL is a list of unpaid credit cards or lost postpaid transit cards that cannot be traded because they are also issued per person. Data can only grow in size.

Application No. 10-2001-0040873 has been proposed to solve the above problem. The application sequentially sorts a series of BL data stored in a BL DB, encodes a bank identification number (BIN) up to the first sixth digit of the BL card number of the edge sorted into one byte, and sets 7 of the card number. Binary encoding the 9-digit card identification number from the 15th to the 15th digit into 4 bytes to compress and generate one card number into 5-byte size, and when the compressed data for one BL card number is generated, The technical gist of the BL card number consists of a step of compressing by expressing only the difference value (offset value) from the previous BL card number.

The above application is a method of reducing the size of BL data, but there is a problem in the practical application for the presence of side effects. Compression side effects include: First, the card terminal should check the existence of the corresponding card from the stored BL data for the card number read, but the search process is complicated and time consuming because it is stored as an offset.

Second, every update of BL data that fluctuates every moment should be repeated to generate the entire BL data again by repeating the process steps of the application. When the BL data update cycle is short, it is necessary to repeat unnecessary and wasteful processes. In order to prevent the long BL data update cycle, there was a problem that the risk of using a bad card falls into a dilemma.

Third, the 6-digit BINs are currently represented as 1 byte because they are all less than 256. In this case, a separate 1-byte value corresponding to each BIN must be given. Is complicated, and in the case of applying a card issued by an overseas issuer in the global era, there is a limit that cannot guarantee that the total number of bins is less than 256.

The present invention has been made to solve the above problems, the BL data compression method that can be easily retrieved card number in the card terminal while reducing the size of the BL data for the storage space and transmission efficiency in the card terminal The purpose is to provide.

Another object of the present invention is to provide a method of compressing BL data, which can easily apply a function of transmitting and retrieving only BL data periodically changed.

BL compression storage method of the present invention for achieving the above object

The application sequentially sorts a series of BL data,

Each of the sorted BL card numbers are divided into bank identification numbers (BINs) up to the first six digits, and 9-digit card identification numbers from seven to fifteenth digits of the card number are binary-coded into four bytes, and again two bytes are used. Dividing by sector number and BL value,

Forming BL data formed of BL blocks of BL values having the same BIN and sector number;

And forming a BL block index table indicating a storage location of the BL block for each BIN and sector number.

Hereinafter, each embodiment will be described in detail with reference to the accompanying drawings.

(Example 1)

The storage structure of the BL data page of this embodiment can search for a BL (data) storage area formed of BL blocks having BL values having the same BIN and sector number, and a storage location of a BL block having a specific BIN and sector number. Index table That is, the BL index table of the present invention has a structure in which the position of the BL data can be found as the BIN and sector number values. For the convenience of management, it is preferable to include a header including bibliographic information such as the version and size of the BL data.

The detailed process of generating BL data in the management server is as follows.

First, the collected BL data is sorted by the card number. At this time, if one byte is allocated to each digit for convenience, 16 bytes are allocated to one BL data. The 7th to 15th numbers of each BL card number are regarded as a decimal number and converted into a 4-byte binary code. The 16th digit is discarded, and each BL card number is converted into a 10-byte value. The first to sixth numbers are designated as BINs, the upper two bytes of the four-byte binary code are designated as sector numbers, and the lower two bytes are designated as BL values. In the above, the first through sixth numbers can be viewed as a decimal number and converted into a three-byte binary code.

The sorted BL data is divided into data having the same BIN. The BL values of the cards having the same BIN and sector number in the sorted order are collected in parallel to form one BL block and stored sequentially in a space in which the compressed BL data to be written is stored. A BL block index table composed of position values (pointers) on the compressed BL data of each BL block is configured, and an index table is separately configured for each BL blocks having the same BIN. Each BL block index table is stored in a space in which compressed BL data is stored, and a sector number index table composed of a position value (pointer) in the stored space is constructed. The sector number index table is stored in a space in which compressed BL data is stored, and constitutes a BIN index table composed of position values (pointers) in the stored space. A header in which bibliographic information such as a version, a creation date, and a size of all BL data is recorded is constructed and stored after the completed BL data body.

The BL data created in the management server as described above is transmitted to each card terminal through a predetermined wired / wireless communication path and stored in the internal memory of the card terminal in the same structure.

The process of searching for the card number for the card read by the card terminal in the BL data configured as described above is as follows. First, the highest 2 of the values converted from the 1st to 6th digits (decimal value or binary value) of the 16-digit read card number into BIN, and the 7th to 15th numbers into 4 byte binary code. Bytes are designated as sector numbers and lower 2 bytes by BL values (S110). The BIN and sector number are searched in the index table stored in the internal memory (S120), and the storage location of the corresponding BL block recorded in the searched record is read (S140).

In the detailed method of the BL block storage location search, first, the BIN value of the card read is searched in the BIN index table (S122). In the searched record, the sector number index table storage position for the card number data having the corresponding BIN is recorded and read (S124). The sector number of the card read from the sector number index table is searched again (S126). In the retrieved record, the storage location of the BL block for the corresponding BIN and sector number is recorded. This value tells the location of the BL block.

The BL value of the read card number is retrieved from the BL block (S150). If the search result is present in the BL block, it is determined as a non-tradeable card, and if not present, the electronic money transaction procedure is performed (S160).

The storage structure for each part of the entire BL data stored on the memory in the card terminal or the management server can be the following two cases. The first method collects and stores all the BL blocks in one set, then stores the sector number index tables in one set, and then stores the BIN index table. The BL data header including the bibliographic information necessary for the BL data body configured as described above is subsequently stored to form the entire BL data.

In the second method, BL blocks having the same BIN are collected and collected into one set, and then the sector number index table of the corresponding BIN is stored after the BL block set of each BIN to configure data for each BIN. The data of each BIN is collected to form a BL data body, and then the BIN index table and the BL data header are stored to form the entire BL data.

(Example 2)

This embodiment is characterized by adding an exception BL page to the structure of the first embodiment. The BL data of this embodiment has a structure consisting of a BIN index table, a sector number index table for each BIN, BIN-specific data consisting of BL blocks and an exception BL page.

If there are extremely small numbers of BL numbers having a certain BIN and sector number, it is a waste of storage space to construct the BL blocks separately and add them to the index table as in the first embodiment. Therefore, in this embodiment, if the BL numbers sharing a certain BIN and sector number are less than a predetermined number (specified among 5 to 10), the binary card number value (sector number + Record the BL value). The exceptional BL page is included as a structure added to BL data for each BIN.

The generation method of BL data of this embodiment is as follows.

First, the collected BL data is sorted by the card number. At this time, 1 byte is allocated to each digit for convenience of work. The 7th to 15th numbers of each BL card number are regarded as a decimal number and converted into a 4-byte binary code. The 16th digit is discarded, and each BL card number is converted into a 10-byte value. The first to sixth numbers are designated as BINs, the upper two bytes of the four-byte binary code are designated as sector numbers, and the lower two bytes are designated as BL values. In the above, the first through sixth numbers can be viewed as a decimal number and converted into a three-byte binary code.

The sorted BL data is divided into data having the same BIN. Collect BL values of cards with the same BIN and sector number in sorted order in parallel. At this time, if the number of BL values of the cards having the same BIN and sector number is less than the predetermined number (to be designated as 10), the BL values are the binary card number value (sector number except BIN) in the separately allocated exception BL storage area. And BL values) only. On the contrary, if the number of BL values of cards having the same BIN and sector number is 10 or more, one BL block is constructed and stored in the space in which the compressed BL data to be written is stored.

A BL block index table composed of position values (pointers) on the compressed BL data of each BL block is configured, and an index table is separately configured for each BL blocks having the same BIN. Store each BL block index table in a space where compressed BL data is stored, construct and store a sector number index table composed of position values (pointers) in the stored space, and construct and store an exception BL page for the corresponding BIN. . The sector number index table is stored in a space in which compressed BL data is stored, and constitutes a BIN index table composed of position values (pointers) in the stored space. A header in which bibliographic information such as a version, a creation date, and a size of all BL data is recorded is constructed and stored after the completed BL data body.

The BL data retrieval method of the card terminal of this embodiment is as follows.

First, convert the 1st to 6th digits (decimal value or binary value) of the 16-digit card number (decimal value or binary value) into BIN, and convert the 7th to 15th numbers into 4 byte binary code. As the sector number, the lower two bytes are designated as BL values (S110). The BIN is retrieved from the BIN index table (S122). In the searched field, since the storage position of the sector number index table for the BIN is recorded, the searched field goes to the sector number index table for the BIN (S124). The sector number of the read card numbers is retrieved from the sector number index table (S126). In the searched field, since the storage location of the BL block for the corresponding sector number is recorded, the controller searches for the BL block for the corresponding sector number with reference to this (S140). The BL value of the read card number is retrieved from the BL block (S150). If the search result is present in the BL block, it is determined as a non-tradeable card, and if not present, the electronic money transaction procedure is performed (S160). If the sector number of the card read in step S126 is not retrieved from the sector number index table, the binary card number value is retrieved from the exception BL page included in the corresponding BL data storage area for each BIN (S202). If the card number read in above is searched, it is determined as an unusable card, and if not, the electronic money transaction procedure is performed (S204).

(Example 3)

This embodiment is characterized in that an exception BL page is added to the structure of the first embodiment as in the second embodiment. That is, the BL data of this embodiment is composed of all BL pages and exception BL pages having the same structure as all BL data of the first embodiment. In the present embodiment, unlike the case of the second embodiment, the general BL page and the exception BL page are not divided and combined for each BIN, and the entire BL data is composed of the general BL page and the exception BL page.

In the present embodiment, as in the second embodiment, if the BL numbers sharing a certain BIN and sector number are less than a predetermined number (specified among 5 to 10), the card number value is not collected in a separate BL block and is stored in the exception BL page. Record (sector number + BL value). The exception BL page is composed of an exception BL page body in which all of the exceptional BL number values are collected and stored in parallel, and an exception BL page header including bibliographic information such as creation date and version.

The generation method of BL data of this embodiment is as follows.

First, the collected BL data is sorted by the card number. At this time, 1 byte is allocated to each digit for convenience of work. The 7th to 15th numbers of each BL card number are regarded as a decimal number and converted into a 4-byte binary code. The 16th digit is discarded, and each BL card number is converted into a 10-byte value. The first to sixth numbers are designated as BINs, the upper two bytes of the four-byte binary code are designated as sector numbers, and the lower two bytes are designated as BL values. In the above, the first through sixth numbers can be viewed as a decimal number and converted into a three-byte binary code.

The sorted BL data is divided into data having the same BIN. Collect BL values of cards with the same BIN and sector number in sorted order in parallel. At this time, if the number of BL values of the cards having the same BIN and sector number is less than the predetermined number (to be designated as 10), the BL values are stored in the exception BL which separately assigns the binary card number value (sector number + BL value). Area (exception BL page storage area). On the contrary, if the number of BL values of cards having the same BIN and sector number is 10 or more, one BL block is formed and stored in the space (general BL page storage area) in which the compressed BL data to be written is stored.

In the case of the general BL page, a BL block index table including a position value (pointer) on the compressed BL data of each BL block is configured, and an index table is separately configured for each BL block having the same BIN. Each BL block index table is stored in a space in which compressed BL data is stored, and a sector number index table composed of a position value (pointer) in the stored space is constructed. The sector number index table is stored in a space in which compressed BL data is stored, and constitutes a BIN index table composed of position values (pointers) in the stored space. A header in which bibliographic information such as a version, a creation date, and a size of all BL data is recorded is constructed and stored after the completed BL data body.

Even in the exceptional BL body for which recording is completed, a header in which necessary bibliographic information is recorded is combined to form an entire exception BL page. The exception BL page also has a structure for allocating a data storage location by dividing each BIN and storing only a binary card number value (sector number and BL value) in the storage location. For this purpose, a BIN index table for the exception BL is provided. It is preferable. Since the structure of the BIN index table for the exception BL is similar to that of the BIN index table, description thereof is omitted.

The BL data retrieval method of the card terminal of this embodiment is as follows.

First, convert the 1st to 6th digits (decimal value or binary value) of the 16-digit card number (decimal value or binary value) into BIN, and convert the 7th to 15th numbers into 4 byte binary code. As the sector number, the lower two bytes are designated as BL values (S110). The BIN is retrieved from the BIN index table (S122). In the searched field, since the storage position of the sector number index table for the BIN is recorded, the searched field goes to the sector number index table for the BIN (S124). The sector number of the read card numbers is retrieved from the sector number index table (S126). In the searched field, since the storage location of the BL block for the corresponding sector number is recorded, the controller searches for the BL block for the corresponding sector number with reference to this (S140). The BL value of the read card number is retrieved from the BL block (S150). If the search result is present in the BL block, it is determined as a non-tradeable card, and if not present, the electronic money transaction procedure is performed (S160). However, if the sector number of the card read in step S126 is not found in the sector number index table, the BIN of the card read in the BIN index table for the exception BL is searched to find the storage location of the exception BL including the corresponding BIN. The binary card number value (sector number and BL value) of the card read out from the storage location of the exception BL is retrieved (S202). If the card number read in above is searched, it is determined as an unusable card, and if not, the electronic money transaction procedure is performed (S204).

(Example 4)

The present embodiment is characterized in that temp BL data is added to the main BL file having the structure of the first embodiment, the second embodiment, or the third embodiment. It is easy to apply with the improvement of the third embodiment where the similarity between the temp file and the exception BL page is strong. The temp BL file is a BL data which records only the contents changed during a specific period after the mail BL file is created.

Since the temp BL data records only the fluctuating BL of a short period, the interval between the data is large to compress the main BL data. Therefore, it is desirable to implement by dividing into a set of card numbers that simply share the BIN number. The BL change is not only to add a new card number to the BL, but also to delete a card number existing in the BL from the list. Therefore, it is necessary to indicate whether to delete / add each card number recorded in the temp BL. The display method is to provide a flag bit for each separate card number record (preferably using the remaining digits as a flag when converting a 9-digit decimal number to a 4-byte binary number) or display the list to be deleted and the list to be added. Areas are displayed separately.

The method of generating main BL data among the entire BL data of this embodiment is the same as that of one of the first to third embodiments.

4 illustrates main BL data and temp BL data according to the fourth embodiment of the present invention. In this case, the BL transmission is performed once a day.

First, there is main BL data, which is past BL data, and this main BL data is stored in the memory of the payment terminal. The central terminal collects the added BL and the released BL during the first day after the last update date of the main BL data, makes a temp BL0 (S20), and transmits it to the payment terminal, and stores the main BL and temp BL0 in the memory of the payment terminal. The central terminal collects the added BL and released BL during the second day, and updates the temp BL0 (adds the newly added BL and records the existing value with the new setting if the same number as the added BL number exists). (S30) The payment terminal transmits the payment terminal and replaces the temp BL0 stored in the memory with the newly updated temp BL0. In the same way, the added / released BLs are collected and updated until the seventh day, thereby completing the final temp BL0 of one week (S40). The above process completes temp BL1 for the next week. The memory of the payment terminal now stores the main BL, the temp BL0, and the temp BL1. When 10 temp BLs are collected from temp BL0 to temp BL9, the central terminal merges 10 temp BLs into the existing main BL to form a new version of the main BL (S50). This process merges and updates the temp BL0 first to the existing main BL, and updates the temp BL9 by merging the temp BL1 again. When merging Temp BL to Main BL, BL numbers set to 'register' in Temp BL are added to Main BL (unchanged if it already exists), and BL numbers set to 'Off' in Temp BL are Remove it (unless the number exists in the main BL, of course).

Each binary card number value in the BL data storage area in the temp BL data area is displayed by converting 9-digit decimal number into 31-bit binary number and registering / unregistering BL recording '0' and BL '1'. All of them are stored as four bytes, preceded by a bit (1 bit).

The BL data retrieval method of the card terminal of this embodiment is as follows.

It is assumed that one main BL data and two temp BL data are stored in the memory of the terminal. If the main BL is searched first, it is troublesome to search for the temp BL again. Therefore, the temp BL is searched from the most recent temp BL.

The terminal searches the BIN index table of the first to sixth digits of all the card numbers read, and finds the BL data storage area of the BIN as a result. The binary card number value obtained by converting the seventh to fifteenth numbers of all the card numbers read out into a four-byte binary code is retrieved from the most recent temp BL data for the corresponding BIN (S102). If the corresponding binary card number value is found, a record of whether to delete / add it is read, and if it is deleted, the card completes the determination as an available card, and if it is added, the determination is completed as an unavailable card (S104). If the corresponding binary card number value is not retrieved in the above step, the same process as the above step of searching in the latest temp BL data is performed. If the corresponding binary card number value is not found in all the temp BL data, the corresponding binary card number value is searched in the main BL data. This search procedure is the same as any one of the first to third embodiments, and thus description thereof is omitted. do.

In all embodiments of the present invention, it is preferable to record all the BINs of cards that can be postpaid in the BIN index table in order to distinguish card types (ie, BINs) which are not serviced due to contractual relationship. In this case, if there is no BL at all, there is no corresponding BL data storage area, so a value indicating NULL is recorded in the index area, and a reserved area of a predetermined size is set in the BIN index table to add a BIN added with temp BL data. Should have In the case of such an implementation, the terminal first checks whether the BIN of the card read first at the BL check is present in the BIN index table, and performs the post-paid processing procedure only if it exists.

The value stored in each index table of the present invention may be an address value or an index value for a storage location of data to be found. In the case of implementing a double address, the size of the value is large, which wastes storage space. However, since the value can be directly moved to the corresponding location, the search speed is faster and the search implementation is simpler. On the contrary, when the index is implemented, each previous data structure needs to be searched one by one as the number of indexes, and thus the search speed is slow and the search implementation is complicated. On the other hand, the short index number is used to save storage space.

When the BL data compression method according to the present invention is implemented, the BL data can be searched for whether the BL exists in the card number read by the terminal, while reducing the storage space of the BL data in the card terminal.

If the implementation using the compression method and the temp file of the BL data according to the present invention, since the amount of data to be transmitted daily is a small temp file, there is an effect that can reduce the transmission time and cost, as well as in the terminal Since there is no separate process of merging BL data, it is possible to reduce the operating time of the card terminal and waste of time by performing the BL data update.

1 shows one BL data structure in the first embodiment of the present invention.

2 shows another one of the BL data structures in the first embodiment of the present invention.

3 shows one of the BL data structures in the second embodiment of the present invention.

4 shows one BL data structure in the fourth embodiment of the present invention.

Figure 5 illustrates a postpaid card system in which the present invention is used.

Claims (8)

In the BL data-based card payment system or WL (White List) data-based card payment system that collects the purchase price or transportation fee, the compression method of the card number list data used to store or transmit the card number list data received from each card company In; Sector number of the upper two bytes among the values converted from the 1st to 6th digits (decimal value or binary value) of the 16 digits of the card number into BIN, and the 7th through 15th numbers into 4 byte binary code. When the lower 2 bytes are designated as BL value, A BL storage area composed of BL blocks in which BL values having the same BIN and sector number are collected; A method of compressing card number list data, comprising a structure of a data page comprising an index table area indicating a storage location of BL blocks corresponding to a specific BIN and sector number. In the BL data-based card payment system or WL (White List) data-based card payment system that collects the purchase price or transportation fee, the compression method of the card number list data used to store or transmit the card number list data received from each card company In; The first 2 bytes of the 16th digit of the card number (decimal value or binary value) are converted into BIN, and the top 2 bytes of the card number value obtained by converting the 7th to 15th numbers into 4 byte binary codes. Sector number, when the lower 2 bytes are designated as BL value, For BL values having a predetermined number or more of BL values having the same BIN and sector number, a BL storage area including BL blocks in which BL values of the same BIN and sector number are collected; Construct a structure of a general data page consisting of an index table area indicating a storage location of BL blocks corresponding to a specific BIN and sector number; Regarding the BL values in which the number of BL values having the same BIN and sector number is less than a predetermined number, an exception page structure consisting of exception BL block areas for each BIN in which card number values of the same BIN are collected is characterized in that it is configured. Compression method of card number list data. The data structure of claim 1 or 2, wherein the data page structure is formed by collecting BL blocks having the same BIN and collecting them into one set, and storing the sector number index table of the corresponding BIN following the BL block set of each BIN. A method of compressing card number list data, comprising: a BL storage area formed by collecting data for each BIN, and a BIN index table for indicating a data storage location for each BIN for each BIN value. Generating the main BL file by any one of claims 1 to 3 (S10), Generating a new temp file by collecting variation of BL data of one day (S20), A step of updating the temp file by collecting the amount of variation in the card number list data for each card company for each card company in the existing temp file data (S30); Confirming the temp file updated by the step S30 for 6 days (S40) and, Repeating steps (S20) to (S40) nine times, collecting ten determined temp files, merging them into an existing main file and updating the main file (S50). Compression method. The first 2 to 6 digits of the read 16-digit card number are converted to BIN, the upper 2 bytes of the 7th to 15th numbers are converted into 4-byte binary code, and the lower 2 bytes are BL. Assigning a value (S110); Retrieving the BIN and sector numbers from an index table stored in an internal memory (S120); Reading storage positions of the corresponding BL blocks recorded in the retrieved record (S140); Retrieving the BL value from the BL block (S150); If it is present in the BL block is determined as a non-tradeable card, and if not present, the step of performing an electronic money trading procedure (S160), the BL query method of the card terminal. The method of claim 5, wherein the step S120, Retrieving the BIN value from a BIN index table stored in an internal memory (S122); Reading the storage position of the sector number index table of the corresponding BIN recorded in the retrieved record (S124); And retrieving the sector number from the sector number index table (S126). The card number read according to claim 5 or 6, wherein if the read card number is not retrieved as a result of performing steps S102 to S160 of retrieving the read card number from the general BL page, Searching the card number read from the exception BL page, if present in the exception BL page is determined as a non-tradeable card, if not present, further comprising the step of performing an electronic money trading procedure (S202) of the card terminal BL query method. According to claim 7, Before the step S110 of retrieving the read card number in the main file, Retrieving a card number read from the latest temp file stored in the internal memory (S102); When the search is made in step S102, the delete / add flag of the corresponding record is read to determine that the card can be deleted, and that it is not available. If the card number read in step S120 is not retrieved, then the steps S102 and S104 are performed on the latest temp file.