KR100987816B1 - System and Server for Managing Card and Apparatus for Providing Approval Card - Google Patents

Abstract

The present invention relates to a card management system, a server, and a card approval terminal device.

In the present invention, since the payment method is changed according to the use of the user who uses the card and various personal information changes, it is necessary to properly reflect the card management system. It is designed to overcome the limitations of change information storage.

The present invention can easily manage various kinds of card information by presenting a new type of data structure with only discount information except 'general' among unusable general card information and user discount information.

The present invention can be expected to reduce the memory requirements due to an efficient data structure, and to be able to flexibly cope with an increase in flag information.

Card, Alias, Offset, Card Endorsement, Flag Information, Unique Identification Number

Description

System and Server for Managing Card and Apparatus for Providing Approval Card}

The present invention relates to a card management system, a server and a card approval terminal device, and in particular, a card management system for efficiently storing card information by storing information such as whether a card is used or a discount in a card unique number corresponding to a card number; A server and a card approval terminal device.

The card approval terminal system is a system for collecting a corresponding fare by approving a transportation card. The card approval terminal system differentiates a payment fare according to various attribute information (for example, general, youth, etc.) to collect or control the fare.

The card approval terminal system needs to continuously manage the change of the attribute information corresponding to the card number or the corresponding identification number in order to differentially collect charges or control the approval according to various attribute information.

The card stores an identification number corresponding to the card number, that is, an Alias number, in the card to determine attribute information of the card.

The conventional card approval terminal system converts an alias number of a card into a memory address and retrieves card attribute information matching the memory address converted in the physical memory area from the card attribute information table to determine whether the card is used and the user's personal information. Search for. Here, the card attribute information table sequentially stores card attribute information in a memory address.

A conventional card approval system using a memory address sequentially stores flag information indicating whether a card is used in a memory address corresponding to a card number to facilitate authentication when using a card.

The structure for storing flag information indicating whether a card is used occupies a large amount of memory because it is necessary to sequentially store all flag information corresponding to the expected total number of available cards regardless of whether a card is actually used or not.

The above-described structure for storing flag information has a memory address corresponding to a separate card number even for a card which is not actually issued, instead of adding flag information sequentially when the memory area of flag information indicating whether a card is used up is exhausted. Unnecessary capacity consumption occurs because it is necessary to allocate area to store flag information.

Currently, the Seoul traffic terminal uses about 23M of memory space to store and manage 120 million cards of flag information, but it is expected that the memory address area will be exhausted in the future. This is a situation where the memory area for storing information is expanding.

The flag information indicating whether the card is used is managed for the use of 'unusable general card', 'usable general card', 'usable student card', 'usable child card' and discount information.

In the conventional method of storing flag information in a memory address, due to structural constraints, each additional storage of one kind of information increases the storage space as much as the total stored memory address, which has a fatal effect on memory capacity and processing speed. In other words, the current Seoul traffic terminal stores the flag information of 120 million cards, but the memory capacity of about 15M must be increased to add one kind of information.

In order to manage change information on the flag information, the conventional card approval terminal system needs to receive a memory information corresponding to a card number to be changed from time to time and a change information file in which flag information thereof is stored and update according to a separate processing method.

A conventional card approval terminal system performs a terminal update to update a received variation information file. If the change information is not updated correctly due to an error such as version information, a card approval problem may occur.

In addition, the card approval terminal system needs to secure additional capacity in order to receive the change information file in order to update the change information, and the card processing time is delayed during the terminal update.

In order to solve the above problems, the present invention provides a card management system and server and a card approval terminal device for efficient card authentication by storing information such as whether a card is used or a discount in a card unique number corresponding to the card number. It is to provide.

Card management server according to a feature of the present invention for achieving the technical problem is a card unique number storage unit for receiving and storing a card unique number list of all cards from the card issuer system; Compute the difference value between the Nth card unique number and the N + 1th card unique number from the card unique number list to generate one or more offset values, and divide the data into specific bytes per record to record the first record of each record. A data generation unit for storing compressed data by storing each reference card unique number at a position, and sequentially storing the generated one or more offset values after each stored reference card unique number; And a data transmission unit configured to transmit the generated compressed data to the card approval terminal device at regular intervals.

According to an aspect of the present invention, the card approval terminal apparatus stores fixed attribute data of card attribute information from an operating institution center. The fixed data is divided into specific bytes per record, and the reference card unique number is stored in the first record position of each record. And sequentially storing offset values that are difference values between the card identification numbers in addition to the reference card identification number. Alternatively, when the card property information stored in the fixed data is changed, the change data in which the changed card property information is stored is received at regular intervals. Card data receiving unit for storing; A card searching unit which compares and searches whether a unique target number of a card in the card belongs to the change data or the fixed data and transmits the searched result information; If there is a request for permission to use by the card, the search target card unique number in the card is read, and whether the search target card unique number exists in the change data is searched through the card search unit to determine whether to use the card, and the change A card processing unit for searching the fixed data through the card search unit to determine whether the card is used if not present in the data; And an approval processing unit configured to calculate a transaction fee, perform a transaction processing of deducting the balance in the card, and perform an approval procedure for storing the transaction details when the card is usable using the searched result information.

According to an aspect of the present invention, a card management system generates variable data in which card attribute information is stored, or variable data in which the changed card attribute information is stored when the card attribute information stored in the fixed data is changed from a card issuer system. A card management server which transmits data or the change data at regular intervals; And receiving and storing the fixed data or the variation data, and if there is a request for use approval by a card, receives a search target card unique number in the card, and whether the received search target card unique number exists in the variation data. Determining whether to use the card by searching, if not present in the change data, search the fixed data to determine whether to use the card, and the card terminal approval device for performing a card transaction approval process according to the use of the card It includes.

According to the above-described configuration, the present invention can apply the change data as it is without performing the task of separately updating the change data in the card approval terminal device, so that various error situations generated by the update can be reduced and change management is easy. Thus, stable system operation can be expected.

The present invention can be expected to prevent the phenomenon that the capacity increases due to the increase in the number of cards and change information by the conventional fixed memory area allocation.

The present invention can be expected to have the effect of preventing the delay of the physical processing speed and abnormal update error occurring in the update process of the change information in the card approval terminal device.

The present invention can be expected to reduce the memory requirements due to an efficient data structure, and to be able to flexibly cope with an increase in flag information.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. In the drawings, parts irrelevant to the description are omitted for simplicity of explanation, and like reference numerals designate like parts throughout the specification.

Throughout the specification, when a part is said to "include" a certain component, it means that it can further include other components, without excluding other components unless specifically stated otherwise. In addition, the terms “… unit”, “… unit”, “module”, “block”, etc. described in the specification mean a unit that processes at least one function or operation, which is hardware or software or a combination of hardware and software. It can be implemented as.

1 is a diagram schematically showing the overall configuration of a card management system according to an embodiment of the present invention.

The card management system of the present invention includes a card issuer system 100, an operating authority center 200, an aggregation system 300, and a card approval terminal device 400.

The card issuer system 100 issues a card in which card attribute information is described and stores the card attribute information in its own database (not shown). Here, the card attribute information includes any one or more of card serial number, expiration date, card type, issuer identification number, usage information, discount information, and card unique number.

When the card issuer system 100 changes the card attribute information according to a user's request or a card issuer's policy, the card issuer system 100 periodically stores the change information in its own database and periodically transmits the change information to the operation authority center 200.

The operator center 200 receives the card attribute information from the card issuer system 100 and generates fixed data for processing whether a prepaid card or a postpaid card is used, a discount, or an authentication. In addition, the operator center 200 periodically receives the change information from the card issuer system 100, integrates the change information, and generates change data having the same data structure as the fixed data.

The operator center 200 transmits the fixed data and the variation data to the card approval terminal device 400 through the aggregation system 300 when requested in a predetermined cycle or sub-system.

The aggregation system 300 receives and stores the fixed data and the variation data from the operator center 200. In addition, although the aggregation system 300 according to an embodiment of the present invention serves as a bypass for transmitting the fixed data and the variation data to the card approval terminal device 400, as another embodiment, the operating institution center 200 The fixed data and the variation data may be generated by receiving the data list and the card attribute information from the.

The operating institution center 200 or the aggregation system 300 according to the embodiment of the present invention may generate and transmit fixed data and change data.

In the embodiment of the present invention, any device or module may be used collectively as a card management server as long as the device generates and transmits fixed data and variation data.

When the card approval terminal device 400 generates a request for use approval by the card, the card approval terminal receives the card unique number stored in the card, determines whether the card is used by searching whether the card unique number exists in the prestored variation data, and changes the data. If it does not exist, the fixed data is retrieved to determine whether the card is used and the card transaction approval process is performed.

Next, the function of the operator center 200 will be described in detail with reference to FIG. 2.

2 is a block diagram schematically showing the internal configuration of the operation center 200 according to an embodiment of the present invention.

The operating center 200 according to the embodiment of the present invention includes a card unique number storage unit 210, a data generation unit 220, a data storage unit 230 and a data transmission unit 240.

Card unique number storage unit 210 is a card unique number (that is, Alias number) corresponding to the 'unusable general card' in order to process the use, discount, authentication of the post-paid card of the entire card from the card issuer system 100 Receives and stores a list of postpaid cards containing them.

Card unique number storage unit 210 is a 'normal card not available', 'usable child card' and 'usable student to process the use of prepaid cards, discounts, and authentication of the entire card from the card issuer system 100 Receives and stores a list of prepaid cards including card's unique number (ie, alias number) corresponding to the card.

The data generator 220 divides 35 bytes per record into 4 bytes by selecting the first card Alias number as a reference Alias number from a postpaid card list or a prepaid card list and storing the result as 4 bytes, and then offsets the difference between the Alias numbers. Calculated data is stored in 31 bytes sequentially to generate compressed data.

In the embodiment of the present invention, the reference alias number and the offset values are composed of 35 bytes including 4 bytes and 31 bytes, respectively, and the optimized number of records is determined in consideration of memory capacity and processing speed.

Therefore, the number of records is not limited to 35 bytes, but can be increased or decreased in consideration of the memory capacity and processing speed.

The data generation unit 220 sequentially stores the card data including the fixed data including 32 card information including the reference alias number and the offset values and the card property information corresponding to the fixed data (32 card information) as option values. Generates the fluctuation data stored with. Here, the option values are 32-bit, 8-byte, card attribute information composed of two bits, that is, an unusable general card (00), an available general card (01), an available student card (10), and an available child card ( 11) Field used to distinguish. In other words, data change information may be stored in the card attribute information.

The data generator 220 sequentially stores card attribute information corresponding to the postpaid fixed data as option values, in addition to the postpaid fixed data and the postpaid fixed data, which store reference alias numbers and offset values using the postpaid card list. Generate postpay variation data (consisting of reference alias numbers, offset values, and option values). Here, the postpaid change data configures card attribute information as option values to know whether the corresponding Alias number is changed (use / disable).

In addition, the data generator 220 generates prepaid fixed data having the same data structure as the prepaid fixed data and the prepaid fixed data storing reference alias numbers, offset values, and option values using the prepaid card list.

Thus, the prepaid variation data, the prepaid fixed data and the postpaid variation data are composed of reference alias numbers, offset values and option values.

When the card attribute information is changed and the change information is received from the card issuer system 100, the data generation unit 220 generates the postpaid change data and the prepaid change data by integrating the change information.

The data storage unit 230 updates and stores the prepaid fixed data, the prepaid variable data, the postpaid fixed data, and the postpaid variable data generated by the data generator 220.

The data transmission unit 240 transmits the generated prepaid fixed data and postpaid fixed data to the aggregation system 300 at regular intervals (for example, 30 days). If the storage capacity of more than a certain range of fixed data (for example, when more than 80% of the fixed data) is sent to the aggregation system 300.

Next, the data generation method of the fixed data or the variation data performed in the operator center 200 will be described in detail with reference to FIG. 3.

3 is a diagram illustrating a data generation method of fixed data or variation data according to an embodiment of the present invention, and FIG. 4 is a diagram illustrating an offset range described with reference to FIG. 3.

The data generation unit 220 extracts an alias number from the card unique number list, and determines whether the current offset position is an offset position (Alias == 0) of the reference alias number (S100 and S102).

If the current offset position is the offset position of the reference Alias number, the data generator 220 stores the extracted Alias number by dividing the data into 35 bytes per record as the reference Alias number of the first record, and moves the offset position to the right by one. (S104).

If the current offset position is not the offset position of the reference Alias number, the data generation unit 220 calculates a difference between the Alias number and the Alias number stored immediately before, and determines whether the difference is 253 or less (S106, S108).

If the offset value calculated from the difference between the corresponding Alias number and the previously stored Alias number is 253 or less, the data generator 220 stores the offset value, which is the difference value, and moves the offset position to the right by 1 ( S110).

If the offset value calculated from the difference between the corresponding Alias number and the previously stored Alias number is between 253 and 507, the data generator 220 moves the current offset position to the right by 2 (offset value greater than 254). Offset Position to Store) It is determined whether the offset position to be stored exceeds the last byte (S112 and S114).

If the offset position to store the offset value larger than 254 does not exceed the last byte, the data generator 220 stores the remaining value after subtracting '0x00' value from 1st offset byte and 253 from offset value which is a difference value from 2nd offset byte. The offset position is shifted to the right by two (S114, S116).

If the offset position to store the offset value larger than 254 exceeds the last byte, the data generator 220 stores only the value '0x00' in the 1st offset byte and moves the offset position to the right by 2 (S114 and S118).

If the offset value calculated from the difference between the corresponding Alias number and the Alias number stored immediately before is a value between 506 and 65536, the data generator 220 determines whether the offset position to store the offset value larger than 507 exceeds the last byte. (S120, S122).

If the offset position to store an offset value of 507 or more does not exceed the last byte, the data generator 220 stores a '0xFE' value in a 1st offset byte, an offset value corresponding to a difference value corresponding to the remaining 2 bytes, and an offset position. Move to the right by 3 (S122, S124).

If the offset position to store the offset value larger than 507 exceeds the last byte, the data generator 220 stores only the value '0xFE' in the 1st offset byte and moves the offset position to the right by 3 (S122 and S126).

If the offset value calculated from the difference between the corresponding Alias number and the previously stored Alias number is equal to or greater than 65536, the data generator 220 determines whether the offset position to store the offset value greater than or equal to 65536 exceeds the last byte (S128). .

When the offset position to store an offset value of 65536 or more does not exceed the last byte, the data generator 220 stores a '0xFF' value in the 1st offset byte, an offset value corresponding to the remaining 4 bytes, and an offset position. Move to the right by 5 (S130).

If the offset position to store the offset value 65536 or more exceeds the last byte, the data generator 220 stores only the value '0xFF' in the 1st offset byte and moves the offset position to the right by 5 (S132).

The data generator 220 stores only '0x00', '0xFE', and '0xFF' values in the 1st byte when the offset position to store the offset value larger than 254 exceeds the last byte, and regardless of the 1st byte in the 2nd byte ' Store the value 0x00 '.

In addition, the data generator 220 fills the offset storage space remaining after storing the last corresponding offset in the last record with a value of '0xFF'.

Here, '0x00', '0xFE' and '0xFF' are special codes, '0x00' stores the difference value corresponding to the remaining 1 byte after '0x00', and '0xFE' is the remaining 2 after '0xFE'. The difference value corresponding to the byte is stored, and '0xFF' means to store the difference value corresponding to the remaining 4 bytes after '0xFF'.

After performing each step of S110, S116, S118, S124, S126, S130, and S132, the data generating unit 220 determines whether the card unique number list is a postpaid card list or a prepaid card list, and in the case of a prepaid card list. The option value corresponding to the attribute information of the offset position to store the offset value is stored in the option field of the same position (S134 and S136).

After the data generating unit 220 performs each step of S110, S116, S118, S124, S126, S130, and S132, it is determined whether the card unique number list is a postpaid card list or a prepaid card list, and a postpaid card list or S136. In operation S138, it is determined whether the shifted offset position exceeds the last byte (S138).

If the shifted offset position exceeds the last byte, the data generator 220 adds a record, stores the offset value to be stored last in the previous record at the offset position of the reference alias number, and sets the offset position to 0 (S138). , S140).

The data generation unit 220 determines whether the offset value is the last data of the card identification number list after performing the step S140 or the moved offset position does not exceed the last byte, and if the last data, the last corresponding offset in the last record After storing, the remaining offset storage space is filled with '0xFF' values (S142 and S144).

After generating the moved offset position does not exceed the last byte or performs step S140, the data generating unit 220 determines whether the corresponding offset value is the last data of the card unique number list, and if it is not the last data, proceeds to step S102. Repeat the data generation process.

FIG. 5 is a diagram for describing a data format of postpaid fixed data generated by the data generator 220 according to an embodiment of the present invention, and FIG. 6 is a diagram of the data generator 220 according to an embodiment of the present invention. It is a figure which shows an example of the generated postpaid fixed data.

As shown in FIG. 5, the data generator 220 extracts the first Alias number corresponding to the postpaid card list, divides the data into 35 bytes per record, and stores the reference Alias number 1 500 as 4 bytes. After that, offset values, which are the difference between alias numbers, are sequentially stored.

The actual Alias number corresponding to the offset 1 means a value equal to the reference Alias 1 500 plus the offset 1 value 510.

The reference Alias 2 520 means as much as the reference Alias 1 500 plus all the values from the offset 1 510 to the offset 31 530. Therefore, up to 32 card aliases are stored per record.

As shown in FIG. 6, it refers to Alias numbers corresponding to 'unusable general cards' extracted from the postpaid card list, and the first card Alias number is set as the reference Alias number (A) 540 of the first record. After the reference Alias number (A) 540, an offset value that is a difference between Alias numbers is sequentially stored.

The last two bits of the postpaid card list refer to card attribute information, and in the case of postpaid fixed data, it is set to '00' unusable general card.

As mentioned in FIG. 4, when the offset value to be stored in the last byte of the first record exceeds 253 with 254, only '0x00' value 550 is stored in 1st byte, and '30000775 corresponding to G in the second record. Is stored as the reference alias number 560.

The structure of postpaid fixed data according to an embodiment of the present invention is a structure in which 32 card information is matched in one record by using a reference alias number and an offset value using a 'unusable general card' list. It has a decreasing effect.

FIG. 7 is a diagram illustrating a data format of prepaid fixed data generated by the data generator 220 according to an embodiment of the present invention, and FIG. 8 is a diagram of the data generator 220 according to an embodiment of the present invention. It is a figure which shows an example of the generated prepaid fixed data.

As shown in FIG. 7, the data generation unit 220 may include a prepaid card list ('unusable general card' 00, 'usable student card' 01, and 'usable child card' 10). The Alias number is extracted, divided into 35 bytes per record, and the reference Alias number is stored as 4 bytes. Then, the offset value, which is the difference between the Alias numbers, is sequentially stored. Subsequently, the data generator 220 stores an option value of 8 bytes corresponding to the card attribute information, which sequentially stores the card attribute information corresponding to the 32 card alias information by 2 bits.

According to the embodiment of the present invention, since the change information is stored more efficiently than the conventional method, various types of card information can be easily managed, thereby maximizing the quality of the card approval service.

The structure of prepaid fixed data and prepaid change data according to an embodiment of the present invention is based on a reference alias number, an offset value, and an option value using a list of 'unusable general card', 'usable student card', and 'usable child card'. It is a structure for storing 32 card information and card attribute information corresponding to the card information in one record.

The structure of the prepaid fixed data and the prepaid change data according to the embodiment of the present invention can be flexibly dealt with when the memory requirement is reduced and the flag information is increased.

The above-described data structure is designed to overcome the limitations of the card storage information limitation and the change information storage scheme of storing the flag information in the existing memory address.

Next, the function of the card approval terminal device 400 will be described in detail with reference to FIG. 9.

9 is a block diagram schematically showing the internal configuration of the card approval terminal device 400 according to an embodiment of the present invention.

Card approval terminal device 400 according to an embodiment of the present invention is the environment setting unit 410, card recognition unit 420, card data receiving unit 430, card processing unit 440, card search unit 450 and An approval processing unit 460 is included.

The environment setting unit 410 generates an environment setting request message and transmits it to the card, and sets a card processing environment by receiving an environment setting response message in response thereto. Here, the configuration response message includes information related to whether the card is one or two cards, an ISO chip card type or a memory card type.

The card recognition unit 420 receives card information including card attribute information and card transaction information (transfer, balance, transit, etc.) from the card in accordance with the card processing environment, and determines whether or not a real card when the card information is normally received. If the card is not a real card, the card recognition error terminates. Here, the card information includes postpaid, prepaid, valid period, and card issuer ID, in addition to card attribute information and card transaction information.

The card recognizing unit 420 determines whether the debit card is a deferred card or a prepaid card when determining whether the debit card is a debit card. If the card has passed, card recognition is terminated due to a card processing error. Subsequently, when determining that the card is within the validity period, the card recognizing unit 420 searches for the card issuer ID to determine whether the card is a usable card.

The card recognizing unit 420 is a card within the validity period, and when the card issuer ID is normally retrieved, the card recognizing unit 420 requests the card processing unit to retrieve and process card attribute information.

The card data receiving unit 430 receives the fixed data or the change data from the operator center 200 at regular intervals, and analyzes the header information of the received data to determine whether it is fixed data (postpaid fixed data or prepaid fixed data). Determine whether it is post-paid change data or prepaid change data) and replace the data.

The card processing unit 440 reads a search target Alias number in a corresponding card when a request for use authorization by a card is read, and determines whether the card is used by searching through the card search unit 450 whether the search target Alias number exists in the change data. If not, the fixed data is searched through the card search unit 450 to determine whether the card is used.

The card search unit 450 compares and searches whether the card is included in the variation data or the fixed data based on the search target Alias number, transmits the searched result to the card processing unit 440, and, in the case of a postpaid card, performs postpaid search logic. In the case of a prepaid card, the prepaid search logic is performed. Here, the postpaid search logic determines whether the search target Alias number exists in the postpaid change data and postpaid fixed data generated using the postpaid card list, and the prepaid search logic is prepaid fixed data and prepaid fixed by using the prepaid card list. A search process that determines whether a search target alias number exists in the data.

The card search unit 450 determines the search range by determining the start position and the end position of the record by opening the variation data and the fixed data, and selecting the intermediate position of the determined search range as the position of the record to search to search the search target Alias number. Do this. Also, the card search unit 450 searches for data higher than the current search position when the search target Alias number is smaller than the reference Alias number of the intermediate position record of the search range. .

In this way, the card search unit 450 selects an intermediate position of the determined search range to perform a search target Alias number search, and if the reference Alias number of the record to be searched is larger than the search target Alias number, the card search unit 450 selects lower data than the current search position. If the reference Alias number is small, the search target Alias number search is performed while narrowing the search range by repeating the process of searching for data higher than the current search position.

The authorization processing unit 460 calculates a transaction fee when the card is usable using the acquired card attribute information, performs a transaction processing of deducting the balance in the actual card, and performs an authorization procedure for storing the transaction details. Subsequently, the approval processing unit 460 transmits the transaction details to the operator center 200 to verify that the actual transaction was possible.

Next, a method of processing data in the card approval terminal device 400 will be described in detail with reference to FIG. 10.

10 is a view for explaining a data processing method in the card approval terminal device 400 according to an embodiment of the present invention.

The card processing unit 440 reads a search target Alias number in the corresponding card when a request for use approval by the card is received (S200).

The card processing unit 440 determines whether there is variation data in the card approval terminal device 400, and if there is variation data, the card processing unit 440 transmits the search target Alias number to the card search unit 450 and changes the change data through the card search unit 450. Search is performed (S202, S204).

When the card processing unit 440 receives a signal indicating that the search target alias number has been searched for the variation data from the card search unit 450, the card processing unit 440 terminates the search process without performing a fixed data search.

The card processing unit 440 determines whether there is variation data in the card approval terminal device 400, and if the variation data does not exist or the search target alias number is not found within the variation data, the card processing unit 440 may fix the fixed data through the card search unit 450. The search determines whether the search target alias number is the same as the corresponding alias number in the fixed data (S206, S208).

Next, the data retrieval method will be described in detail with reference to FIG.

11A and 11B are diagrams for describing a data retrieval method according to an embodiment of the present invention.

The card search unit 450 determines the search range by determining the start position and the end position of the record to be searched by opening the fixed data or the variation data (S300 and S302). Here, the search start position is 1, and the search end position is the number of records.

The card search unit 450 determines whether the search start position is smaller than or equal to the search end position, and if the search start position is larger than the search end position, generates and outputs failure information for the alias number search (S304 and S306).

If the search start position is less than or equal to the search end position, the card search unit 450 adds the search end position to the search start position, sets the value divided by 2 as the search position (that is, if the search range is determined). The middle position of the search range is moved to the search position), and the Alias number search is performed by moving to the position of the record to be searched at the set search position (S304, S308, S310).

When the position of the record to be searched is determined, the card search unit 450 reads the record to determine whether the search target Alias number and the reference Alias number are the same (S312 and 314).

If the search target Alias number and the reference Alias number are the same, the card search unit 450 generates and outputs success information for searching the Alias number (S316).

If the search target Alias number and the reference Alias number are not the same, the card search unit 450 determines whether the search target Alias number is smaller than the reference Alias number (S318). In order to reset the search end position to the position of the record to be searched for -1 (S320), the flow advances to step S304.

Subsequently, the card search unit 450 determines whether the search target Alias number is smaller than the reference Alias number, and if the search target Alias number is larger than the reference Alias number and the search position is the end position of the search range, the card search unit 450 performs an offset search process of the corresponding record. It performs (S318, S322, S324).

The card search unit 450 determines whether the search target alias number is smaller than the reference alias number, and if the search target alias number is larger than the reference alias number and the search position is not the end position of the search range, the card search unit 450 increases the current search position by one. The record is retrieved (S318, S322, S326).

Subsequently, after performing step S326, the card search unit 450 determines whether the search target Alias number and the reference Alias number are the same, and generates and outputs success information for searching the Alias number (S328, S330).

After performing the step S326, the card search unit 450 determines whether the search target Alias number and the reference Alias number are the same, and if the search target Alias number is smaller than the reference Alias number or the search position is in the search range. It is determined whether it is the end position (S328, S332).

Subsequently, when the search target Alias number is smaller than the reference Alias number or the search position is the end position, the card search unit 450 performs an offset search process of the corresponding record (S332 and S334).

If the search target Alias number is larger than the reference Alias number, the card search unit 450 resets the search start position to the position of the record to be searched +1 to search for lower data than the current search position (searches the position of the lower record). The search range is reset to the start position of the range) (S332, S336), and the flow advances to step S304.

Next, the offset search process of the record will be described in detail with reference to FIG. 12.

12 is a diagram for describing an offset retrieval process according to an embodiment of the present invention.

The card search unit 450 sets offset position = 0, Alias number = reference Alias number, and determines whether the offset position exceeds the last byte, and generates and outputs failure information for the alias number search when the last byte is exceeded. (S400, S402, S404). That is, after searching for all offset values of 31 bytes, if the search target alias number cannot be searched, it is determined that there is no search target alias number in the fixed data or the change data, and the search ends without failure.

If the offset position does not exceed the last byte, the card search unit 450 reads the offset value from the first offset byte, and if the value is '0x00', shifts the offset position to the right by 1 and adds 253 to the reference alias number. Then, the value obtained by adding the next offset 1 byte becomes the corresponding Alias number (S406, S408, S410).

When the offset position does not exceed the last byte and the corresponding offset value is '0xFE', the card search unit 450 adds the value of the next offset 2 bytes to the corresponding Alias number to become the corresponding Alias number. Move to the right (S412, S414, S416).

If the offset position does not exceed the last byte and the offset value is '0xFF' value, the value of the next offset 4 bytes is added to the reference alias number to become the corresponding alias number. Move to the right as much (S418, S420, S422).

If the offset position does not exceed the last byte and the offset value does not belong to the values of '0x00', '0xFE', and '0xFF', the card search unit 450 adds the corresponding offset value to the reference Alias number. It becomes a number and moves the offset position to the right by 1 (S424).

The card search unit 450 determines whether the search target Alias number is the same as the corresponding Alias number, and generates and outputs success information for searching the Alias number (S426, S428).

The card search unit 450 determines whether the search target Alias number is the same as the corresponding Alias number, and determines whether the search target Alias number is smaller than the corresponding Alias number (S426 and S430). Subsequently, when the search target Alias number is larger than the corresponding Alias number, the card search unit 450 proceeds to step S402. When the search target Alias number is smaller than the corresponding Alias number, the card search unit 450 proceeds to searching the Alias number without further searching. Generate and output the failure information (S430, S432).

The embodiments of the present invention described above are not implemented only by the apparatus and / or method, but may be implemented through a program for realizing functions corresponding to the configuration of the embodiment of the present invention, a recording medium on which the program is recorded And such an embodiment can be easily implemented by those skilled in the art from the description of the embodiments described above.

Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

1 is a diagram schematically showing the overall configuration of a card management system according to an embodiment of the present invention.

2 is a block diagram schematically showing the internal configuration of the operating center according to an embodiment of the present invention.

3 is a view for explaining a data generation method of fixed data or variation data according to an embodiment of the present invention.

4 is a diagram illustrating an offset range described in FIG. 3.

5 is a diagram for describing a data format of postpaid fixed data generated by a data generator according to an exemplary embodiment of the present invention.

6 is a diagram illustrating an example of postpaid fixed data generated by a data generator according to an exemplary embodiment of the present invention.

FIG. 7 illustrates a data format of prepaid fixed data generated by a data generator according to an exemplary embodiment of the present invention.

8 is a diagram illustrating an example of prepaid fixed data generated by a data generator according to an exemplary embodiment of the present invention.

9 is a block diagram schematically illustrating an internal configuration of a card approval terminal device according to an embodiment of the present invention.

10 is a diagram for describing a data processing method in a card approval terminal device according to an embodiment of the present invention.

11A and 11B are diagrams for describing a data retrieval method according to an embodiment of the present invention.

12 is a diagram for describing an offset retrieval process according to an embodiment of the present invention.

Claims (11)

A card unique number storage unit for receiving and storing a list of card unique numbers among all cards from a card issuer system; Compute the difference value between the Nth card unique number and the N + 1th card unique number from the card unique number list to generate one or more offset values, and divide the data into specific bytes per record to record the first record of each record. Generating compressed data by storing each reference card unique number at a position, and sequentially storing the generated one or more offset values after each stored reference card unique number, and generating the first reference card unique number of the first record. Set the first card unique number in the received card unique number list, and the second reference card unique number for the records after the first record, the reference card unique number of the previous record, and the one or more offset values generated. A data generation unit for setting the values as much as they add up; And Data transmission unit for transmitting the generated compressed data to the card approval terminal device at regular intervals Card management server comprising a. According to claim 1, And the data generator sequentially stores card attribute information corresponding to each reference card unique number and the one or more offset values as option values in an option field. According to claim 1, The data generation unit stores the respective reference card unique number and the generated one or more offset values in order to process the use of the postpaid card and the reference card unique number in addition to the postpaid fixed data and the postpaid fixed data. And generating postpaid change data by storing card attribute information corresponding to the generated one or more offset values as option values. According to claim 1, The data generation unit stores the same reference card pre-fixed data and the prepaid fixed data storing the respective reference card unique numbers, the generated one or more offset values, and option values indicating card attribute information for processing whether the prepaid card is used or not. And, when the card attribute information is changed to the prepaid fixed data, generating the prepaid change data in which the changed card attribute information is stored. According to claim 1, The card identification number list may be a prepaid card list including Alias numbers corresponding to 'usable general cards', 'usable children' cards 'and' usable student cards ', or' alias corresponding to 'unusable general cards'. (Alias) Card management server, characterized in that the list of postpaid cards containing the numbers. Fixed data in which card attribute information is stored from an operating institution center. The fixed data is divided into specific bytes per record, and the reference card unique number is stored in the first record position of each record, and the card unique information is added to the reference card unique number. Storing offset values which are difference values between numbers sequentially; A card searching unit which compares and searches whether a unique target number of a card in the card belongs to the change data or the fixed data and transmits the searched result information; If there is a request for permission to use by the card, the search target card unique number in the card is read, and whether the search target card unique number exists in the change data is searched through the card search unit to determine whether to use the card, and the change A card processing unit for searching the fixed data through the card search unit to determine whether the card is used if not present in the data; And In the case of a card that can be used using the searched result information, an authorization processing unit that calculates a transaction fee, performs a transaction processing of deducting the balance in the card, and performs an approval procedure for storing the transaction details. Card approval terminal device comprising a. The method according to claim 6, The card search unit determines the search range by determining the start position and the end position by opening the change data or the fixed data, selecting an intermediate position of the determined search range, and a reference of a record to be searched rather than the unique number of the search target card. If the card unique number is large, the lower data is smaller than the current search position. If the card unique number is smaller, the process of searching the data higher than the current search position is repeated, thereby narrowing the search range and searching for the search target card unique number. Card approval terminal device, characterized in that. The method according to claim 6 or 7, And the fixed data or the change data sequentially store card attribute information corresponding to the reference card unique number and the offset values as option values in an option field. When the fixed data storing the card attribute information or the card attribute information stored in the fixed data is changed from the card issuer system, the changed card attribute information is generated and the variation data stored therein is transmitted, and the fixed data or the variation data is transmitted at regular intervals. A card management server; And Receive and store the fixed data or the change data, and if there is a request for use approval by a card, receive a search target card unique number in the card, and search whether the received search target card unique number exists in the change data. Determining whether the card is used, if not present in the change data, by searching the fixed data to determine whether to use the card, the card terminal authorization device for performing a card transaction approval process according to the use of the card Card management system comprising a. The method of claim 9, The card management server receives a list of card unique numbers from the card issuer system, calculates a difference value between the Nth card unique number and the N + 1th card unique number from the received card unique number list, and includes one or more cards. Generating offset values, storing each reference card identification number in the first record position of each record by dividing the data into specific bytes per record, and generating one or more offset values after each reference card identification number stored. And storing the fixed data or the fluctuation data sequentially. The method of claim 10, And the card management server sequentially stores card attribute information corresponding to each reference card unique number and the generated one or more offset values as option values in an option field.

Images