JP2022176714A - In/out management system - Google Patents

Abstract

To provide an in/out management system that is constructed with simple constitution although media having high security standards, for example, credit cards etc., are utilized for in/out management of facilities.SOLUTION: An in/out management system 100 comprises a token conversion server 10 which converts a security ID into a token, a reader RD which reads and reports the security ID to the token conversion server 10 and also receives notice of a corresponding token, and an information management server 50 which manages in/out information associatively with the token reported by the reader RD.SELECTED DRAWING: Figure 2

Description

The present invention relates to an entrance/exit management system that manages entrance/exit to various facilities using payment media such as credit cards.

As a technology related to card information processing, when a card is used to purchase goods or services, information processing is performed while determining whether the card information is confidential or not, thereby suppressing cost increases and enhancing the security of card information. A device (see Patent Document 1) is known that enables this.

However, although the above Patent Document 1 discloses a method for enhancing the security of card information when using a card, it does not disclose how the card is used to provide services other than purchases using the card information. .

JP 2019-101744 A

The present invention has been made in view of the above points. The purpose is to provide a system.

The entry/exit management system for achieving the above purpose comprises a token conversion server that tokenizes a security ID, a reader that reads the security ID and notifies the token conversion server and receives notification of the corresponding token, and An information management server is provided for managing entry/exit information in association with the received token.

In the entrance/exit management system, the reader receives notification of the token corresponding to the security ID, and various management is performed by linking the token received by the reader to the notification. To construct a system with a simple configuration and a high security standard because it is not necessary to conform the entire system to a high security standard even if a medium with a high security standard such as a credit card is used when managing information on entry and exit in a building. can be done.

In a specific aspect of the present invention, the reader is provided in a parking lot or bicycle parking lot, and the information management server manages the entry/exit information of vehicles using the parking lot or bicycle parking lot based on the token notified by the reader. . In this case, the token corresponding to the security ID can be used for entrance/exit management in the parking lot or bicycle parking lot.

According to another aspect of the present invention, a fare adjustment machine is provided that is communicatively connected to an information management server and performs fare adjustment based on vehicle entry/exit information. In this case, the vehicle associated with the token can be managed (particularly, payment management) at the payment machine.

According to still another aspect of the present invention, the payment machine includes a pre-payment machine that accepts pre-payment processing of charges. In this case, pre-payment using tokens is possible at the pre-payment machine.

In still another aspect of the present invention, the reader further includes a facility-side reader installed in a facility other than a parking lot or a bicycle parking lot. Upon receiving the notification from the token conversion server, the information management server performs processing for applying discounts to the parking lot or bicycle parking lot based on the token notified by the facility-side reader. In this case, it is possible to apply a fee discount using the token.

In still another aspect of the present invention, the reader has a storage unit that stores the token notification history together with the corresponding security ID, and the information management server stores the token notification history when the reader becomes unable to communicate with the token conversion server. , manages incoming/outgoing information based on the history stored in the storage unit. In this case, even if communication with the token conversion server becomes impossible, entry/exit management using tokens can be maintained.

In still another aspect of the present invention, the reader is composed of an entrance-side reader installed at the entrance and an exit-side reader installed at the exit. Transmit to side reader. In this case, entry/exit management using tokens is performed by cooperation between the entry side reader and the exit side reader.

In still another aspect of the present invention, an entrance determination unit receives notification of a token from an entrance reader, is communicably connected to an information management server, and receives notification of a token from an exit reader and an entrance determination unit that determines whether or not to permit entry. and an exit determination unit that is communicatively connected to the information management server and determines whether or not to permit entry. Based on the notification, the decision on whether to participate will be made. In this case, even if communication with the information management server becomes impossible, it is possible to determine whether or not to participate using the token.

In still another aspect of the present invention, the reader includes a ticket gate reader provided at the ticket gate of the station, and the information management server obtains entry/exit information of passers-by at the ticket gate based on the token notified by the ticket gate reader. to manage. In this case, tokens can be used to control the entry and exit of passers-by at ticket gates at stations.

In still another aspect of the present invention, the information management server sets the expiration date and blacklist target for the token notified by the reader. In this case, the token can be used to perform various management incidental to entry/exit management.

BRIEF DESCRIPTION OF THE DRAWINGS It is a block diagram for demonstrating the outline|summary of the parking lot which installed the entrance/exit management system which concerns on 1st Embodiment. FIG. 4 is a block diagram for explaining token acquisition in the entrance/exit management system; 1 is a conceptual diagram for explaining an overview of entry/exit management using a token in a parking lot where an entry/exit management system is introduced; FIG. (A) to (C) are diagrams for explaining an example of data handled by an information management server of an entrance/exit management system; (A) is a flowchart for explaining an example of the operation of the entrance/exit management system when a vehicle enters, and (B) is a flowchart for explaining an example of the operation of the entrance/exit management system when a vehicle leaves. be. It is a block diagram for demonstrating the outline|summary of the parking lot which installed the entrance-and-exit management system which concerns on 2nd Embodiment. FIG. 4 is a diagram for explaining an example of data stored in an entrance-side reader of the entrance/exit management system; 4 is a flowchart for explaining an example of the operation of the entry/exit management system when a vehicle exits. 4 is a flowchart for explaining an example of the operation of the entry/exit management system when a vehicle enters. FIG. 11 is a conceptual diagram for explaining an outline of a parking lot in which an entrance/exit management system according to a third embodiment is installed; 1 is a block diagram for explaining an overview of a parking lot in which an entry/exit management system is installed; FIG. FIG. 2 is a diagram for explaining an example of data handled by an information management server of an entrance/exit management system; FIG. 12 is a conceptual diagram for explaining an outline of a ticket gate at a station where the entry/exit management system according to the fourth embodiment is installed; FIG. 11 is a conceptual diagram for explaining an outline of a modification of the entry/exit management system;

[First embodiment]
An example of the entrance/exit management system according to the first embodiment will be described below with reference to FIG. 1 and the like. As shown in FIG. 1 and the like, an entrance/exit management system 100 according to the present embodiment is provided in a parking lot PA, and performs entrance/exit management for vehicles VE (see FIG. 3) entering and exiting the parking lot PA. In other words, the entrance/exit management system 100 functions as a parking management system.

The entry/exit management system 100 of the present embodiment enables entry/exit management using a security ID. More specifically, for example, as shown in FIG. Entry/exit management in the parking lot PA is performed using this. In the example below, in addition to the case of using a credit card CC, a conventional mode of issuing a parking ticket and managing parking is shown. It is also possible to set it as the aspect which carries out. In addition, it is conceivable to use various media other than the credit card CC (such as an IC card).

Also, here, the credit card CC as an example of the payment medium is EMV (Europay, MasterCard, VISA protocol) compliant and non-contact readable.

In order to enable the above aspect, the entrance/exit management system 100 includes a token conversion server 10, an entrance reception device 20, an exit reception device 30, and an information management server 50. FIG. In the drawing, arrows A1 and A2 indicate the direction of vehicle entry and exit, respectively.

The token conversion server 10 is a facility for tokenizing the security ID of the credit card CC. The token conversion server 10 is composed of a PCIDSS (Payment Card Industry Data Security Standard) certified server or an equivalent server capable of generating tokens in order to ensure the security of card information of a credit card CC as a payment medium. be done. The token conversion server 10 exchanges the security ID of the credit card CC, which is the payment medium in the above-described mode, that is, the credit card number (PAN: Primary Account Number) with a specific external device (an entrance-side reader RDa, etc., which will be described later). , tokenization (token generation) and notification of the generated token.

The admission reception device 20 includes, for example, a ticket issuing machine 21 and a gate device 22, and performs operations related to permission or denial of admission of a vehicle to the parking lot PA. The ticket issuing machine 21 is a parking ticket issuing machine that issues a parking ticket from a discharge port 21a. The gate device 22 is a device that raises and lowers a gate bar 22a to indicate whether or not the vehicle is allowed to enter. In addition to the above, particularly in the present embodiment, the entrance reception device 20 includes an entrance determination section 20a as a main body portion for determining permission or denial of entrance, and an entrance-side reader RDa.

The entry-side reader RDa is composed of an EMV-authenticated reader to enable communication regarding PAN and corresponding tokens with the token conversion server 10 as a PCIDSS-authenticated server. That is, the entry-side reader RDa reads the PAN as the security ID from the credit card CC, notifies the token conversion server 10 of it, and receives notification of the token corresponding to the PAN from the token conversion server 10 . In the illustrated example, the admission reception device 20 is provided with an interface section 23a for non-contact reading of the credit card CC. In other words, the entrance-side reader RDa performs contactless reading of the credit card CC via the interface section 23a.

The entrance determination unit 20a is composed of, for example, various circuits, and while receiving the token notified to the entrance-side reader RDa from the entrance-side reader RDa, determines whether the vehicle of the holder (passenger) of the credit card CC is in the parking lot PA. to determine whether or not to enter. The entrance determination unit 20a is capable of communicating with the information management server 50, and outputs to the information management server 50 information on the received token (token ID) and information at the time of entrance such as entrance time. . That is, the entrance determination unit 20a receives a token notification from the entrance-side reader RDa, is communicably connected to the information management server 50, and functions as a main body part of the entrance reception device 20 by determining whether or not to permit entrance. . When the entrance determination unit 20a determines that the entrance is permitted, the entrance determination unit 20a outputs a command to raise and lower the gate bar 22a to the gate device 22 in order to allow the vehicle to pass through.

The entrance reception device 30 has the same configuration as the entrance reception device 20, and performs an operation related to whether or not the vehicle is allowed to exit the parking lot PA. For this reason, the entry reception device 30 includes, for example, a payment device 31, a gate device 32, an exit determination section 30a, and an exit side leader RDb. The settlement device 31 inserts and ejects a parking ticket from the reception port 31a, and performs various processes necessary for settlement of the parking fee, such as an inquiry to the information management server 50. FIG. The gate device 32 is a device that raises and lowers a gate bar 32a to indicate permission or denial of entry of the vehicle.

The exit side reader RDb reads the security ID of the credit card CC through the interface section 33a and notifies the token conversion server 10 of it, and also receives notification of the corresponding token from the token conversion server 10. FIG. The exit determination unit 30a is composed of, for example, various circuits, and while receiving the token notified to the exit-side reader RDb from the exit-side reader RDb, the exit determination unit 30a moves the vehicle of the holder (passenger) of the credit card CC to the parking lot PA. It functions as a main body part of the entry acceptance device 30 by determining whether or not entry is permitted.

The information management server 50 is composed of various storage devices, electronic circuits, etc., stores various data related to parking management including token IDs, and performs necessary judgment processing. In the illustrated example, the information management server 50 includes a communication unit 51 and a parking data management unit 52, and transmits and receives various information to and from the entrance reception device 20 and the exit reception device 30 via the communication unit 51 for parking management. I do. The parking data management unit 52 includes a token data management unit 52a that manages various data related to the token ID, and a parking ticket data management unit 52b that manages various data related to the parking ticket issued by the admission reception device 20. . That is, the information management server 50 performs parking management based on the token ID and parking ticket information. As described above, the information management server 50 can manage entry/exit information associated with tokens notified by the entrance-side leader RDa of the entrance reception device 20 and the exit-side leader RDb of the exit reception device 30. there is

When extracting operations such as token acquisition and notification in the entrance/exit management system 100, the block diagram illustrated as FIG. 2 is obtained. First, when the security ID (PAN) of the credit card CC is read by the reader RD (reader RDa on the entrance side or reader RDb on the exit side), the reader RD sends the read security ID to the token conversion server 10. to notify you. Upon receiving the notification from the leader RD, the token conversion server 10 tokenizes the security ID (tokenization) and notifies the generated token to the leader RD. The leader RD that has received the notification from the token conversion server 10 transmits the token to the information management server 50 that manages various types of information. In the example shown in FIG. 1, tokens are output to the information management server 50 from the entrance side reader RDa and the exit side reader RDb as the leader RD via the entrance determination section 20a and the exit determination section 30a. In addition, at this time, the token and various information related to parking management are linked together and managed in the information management server 50 . That is, in the information management server 50, data management is performed using a token as an ID.

When tokenizing the security ID as described above, from the viewpoint of maintaining high security, for example, the token conversion server 10 is composed of a server that has acquired PCIDSS certification, as described above. The reader RD (entrance-side reader RDa, exit-side reader RDb) that performs communication is also maintained in a manner conforming to this security. That is, in the configuration shown in FIG. 2, the hatched token conversion server 10 and reader RD comply with PCIDSS authentication. On the other hand, other components (for example, the information management server 50) are not directly involved in tokenization, and are solely responsible for managing various types of information based on the notified tokens. Therefore, the information management server 50, etc., which are not hatched, can be configured as non-compliant with PCIDSS authentication, and can have a simpler configuration than the token conversion server 10, etc.

In view of this point, in the present embodiment, by configuring the entrance/exit management system 100, a medium with a high security standard such as a credit card is used when managing information related to entrance/exit in the parking lot PA (see FIG. 1). However, the system as a whole does not need to conform to high security standards, thereby realizing a system construction with a simple configuration. It should be noted that the information management according to the mode illustrated in FIG. 2 is applicable not only to parking lots but also to bicycle parking lots and other various facilities.

An example of an overview of entry/exit management of a vehicle VE using a token in a parking lot PA where the entry/exit management system 100 is introduced will be described below with reference to a conceptual diagram shown as FIG. In FIG. 3, similarly to the case shown in FIG. 2, among the parts constituting the entrance/exit management system 100, the parts conforming to the PCIDSS certification are indicated by hatching, and the non-conforming parts are not hatched. is shown. More specifically, in the figure, the token conversion server 10, the entrance-side reader RDa, and the exit-side reader RDb shown hatched are the PCIDSS authentication conforming unit 100A, and the entrance determination unit 20a, the exit determination unit 30a, and the information The management server 50 is assumed to be the PCIDSS authentication non-compliant section 100B. In other words, processing related to tokenization of the security ID (PAN) of the credit card CC is performed exclusively within the PCIDSS authentication compliant section 100A, and in the PCIDSS noncompliant section 100B, various management is performed using the already generated token as an ID. It is supposed to be done.

An example of a series of processes from entry to exit of the vehicle VE when the credit card CC is used for parking management will be described below with reference to FIG.

First, when the security ID (PAN) of the credit card CC owned by the passenger of the vehicle VE who is going to enter the parking lot PA is read by the entrance reader RDa of the admission reception device 20 (step S1), the entrance reader RDa is read. requests the token conversion server 10 to tokenize the security ID (step S2). In the token conversion server 10, a token is generated in response to a request from the entry-side reader RDa. Upon receiving the response of the token corresponding to step S2 from the token conversion server 10 (step S3), the entrance side leader RDa transfers the received token to the entrance determination section 20a (step S4).

The entrance determination unit 20a associates the entry information of the vehicle VE corresponding to the credit card CC, that is, information such as entry time, with the token received from the entrance side reader RDa in step S4, and registers them in the information management server 50 (step S5). In addition to the registration in step S5, the entrance determination unit 20a also performs various necessary operations such as raising and lowering the gate bar 22a (see FIG. 1) in order to allow the vehicle VE whose registration has been accepted to enter the venue.

On the other hand, the security ID (PAN) of the credit card CC is first read by the exit side reader RDb of the exit reception device 30 (step S6) for the vehicle VE that is about to exit from the parking lot PA. RDb requests the token conversion server 10 to tokenize the security ID (step S7), and receives a corresponding token response from the token conversion server 10 (step S8). 30a (step S9).

In order to calculate the parking fee for the target vehicle VE, the exit determination unit 30a sends the information (in this case, entrance information) about the token received from the exit side leader RDb in step S9 to the information management server 50. (Step S10), and upon receiving a response of the corresponding admission information from the information management server 50 (Step S11), the parking fee is calculated based on the received admission information (Step S12).

After step S12, various necessary processes such as settlement processing and entry processing are performed by the entrance reception device 30 having the settlement device 31 and the gate device 32 (see FIG. 1).

In the above example, the parking fee is calculated in the entry reception device 30. However, the information management server 50 is responsible for calculating the parking fee. Alternatively, it is possible to request information on the calculation result of the parking fee instead of the above admission information. When applying the entry/exit management system 100 to a bicycle parking lot, the configuration is the same as that described above. That is, in the above description, the vehicle (automobile) VE is replaced by a bicycle, and each part such as a gate device is specified by a bicycle parking lot, so that a similar configuration is possible.

An example of the data handled by the information management server 50, that is, the data for controlling entry and exit of the vehicle VE will be described below with reference to FIG. Here, an example of the data of the vehicle VE using the token, that is, the data stored in the token data management section 52a of the parking data management section 52 is shown. In the information management server 50, for example, as shown in FIGS. 4A and 4B, a data table DT is created each time a token is generated, and a plurality of data tables as shown in FIG. A series of data groups corresponding to DT are stored in the token data management unit 52a, and are updated each time the vehicle VE enters or exits. As shown in FIG. 4A and the like, each data table DT contains data DD1 related to the generated token number (token ID), the date and time of issue of the token, and the expiration date of the token, as well as the contract details for the vehicle VE. Data DD2 related to entry and exit, and data DD3 related to time information such as times related to entry and exit are stored. In the illustrated example, in addition to these pieces of information, data DD4 indicating whether or not the item is to be blacklisted is also stored. Data DD4 is normally not subject to the blacklist, but for example, when using the parking lot PA in the past, the token corresponding to the vehicle VE that had a problem such as not being able to exit normally. is registered as a blacklist object, and it is possible to detect that fact when using the parking lot PA thereafter.

Various forms are conceivable for the contract contents shown in the data DD2, but as shown in FIG. Also, the usage history is recorded in the time information shown as data DD3. On the other hand, as exemplified in FIG. 4(B), it is recorded that the temporary use vehicle VE is for use only on the day. These data DD1 to DD4 are stored based on a registration command from the entrance determination unit 20a when entering (step S5 in FIG. 3) and an information request from the exit determination unit 30a when exiting (step S10 in FIG. 3). , is recorded and updated.

An example of a series of operations in the entry/exit management system 100 of the above aspect will be described below with reference to the flowchart of FIG. First, with reference to FIG. 5A, an example of the operation of the entry/exit management system 100 when the vehicle VE enters will be described.

In the entrance/exit management system 100, the entrance reception device 20 detects the existence of the vehicle VE about to enter (step S101) using, for example, various sensors (not shown). (Step S101: Yes), it is confirmed whether or not the vehicle VE uses the security ID of the credit card CC for the entrance/exit management (Step S102).

In step S102, when the use of the security ID is confirmed, that is, when the entrance-side reader RDa reads the security ID (step S102: Yes), the entrance-side reader RDa tokenizes the read security ID (token conversion request and its response) (step S103).

Here, confirmation of blacklist registration regarding the security ID is made (step S104). As an example of confirmation of registration in the blacklist, it is conceivable that the target credit card CC has become unusable at the time of tokenization in step S103. In other words, it is assumed that the credit card CC itself is blacklisted and the token cannot be acquired in the processing in the token conversion server 10 . As another example, when the ID of the token is registered in the information management server 50 even though it has been tokenized in step S103, the data managed by the information management server 50 (data DD4 in FIG. 4) is , it is assumed that it is blacklisted. In other words, it is assumed that there was a problem when using the parking lot PA in the past.

In step S104, if it is determined that the token is not registered in the blacklist (step S104: No), processing is performed to accept the token. parking management registration is performed (step S105). After step S105, the admission reception device 20 permits the entry of the vehicle VE and performs various operations such as raising and lowering the gate bar 22a by the gate device 22 to guide the vehicle VE into the hall (step S106).

On the other hand, if it is determined in step S104 that the entry is blacklisted (step S104: Yes), the entrance reception device 20 issues a warning notification to that effect (step S107). Various forms of warning notification can be assumed. It is also possible to contact the company to that effect. In addition, the form of the warning notification may vary depending on the content determined to be registered in the blacklist. When the warning notification in step S107 is issued, the entrance/exit management system 100 terminates the series of processes without allowing the entrance reception device 20 to permit entrance.

If it is not confirmed in step S102 that the security ID is used, the admission reception device 20 issues a parking ticket, that is, issues a parking ticket from the outlet 21a of the ticket issuing machine 21 (step S102). S108). Note that, as a typical example of a mode in which the security ID is not used, a ticket issuing button (not shown) for issuing a parking ticket is provided in the admission reception device 20, and the ticket issuing button is pressed. is assumed. When the parking ticket is issued by the admission reception device 20, various information such as the time of issue and the parking ticket number is transmitted to the information management server 50, and the parking ticket data management section 52b of the parking data management section 52 of the information management server 50 This information is recorded in After issuing the parking ticket in step S108, the admission reception device 20 permits the entry of the vehicle VE and performs various operations such as raising and lowering the gate bar 22a by the gate device 22 in order to guide the vehicle VE into the hall (step S106).

After completing the above series of operations, the entrance reception device 20 starts detecting the presence of a new vehicle VE that is about to enter again (step S101).

Next, an example of the operation of the entry/exit management system 100 when the vehicle VE exits will be described with reference to FIG. 5(B).

In the entrance/exit management system 100, the exit reception device 30 detects the presence of the vehicle VE about to exit using, for example, various sensors (not shown) (step S201). (Step S201: Yes), it is confirmed whether or not the vehicle VE uses the security ID of the credit card CC for entrance/exit control (step S202).

In step S202, when the use of the security ID is confirmed, that is, when the exit side reader RDb reads the security ID (step S202: Yes), the exit side reader RDb tokenizes the read security ID. (Step S203), and the entry reception device 30 checks the corresponding token (Step S204). That is, the entry reception device 30 refers to the data managed by the information management server 50 and the data corresponding to the token acquired in step S203, so that the exit judgment unit 30a can judge whether to permit entry.

Here, in correspondence with the processing in steps S203 and S204, confirmation of registration of the security ID in the blacklist (step S205) is performed. For example, after admission is permitted by the entrance reception device 20, the subject credit card CC itself is blacklisted, or the data managed by the information management server 50 is blacklisted. A case such as entering is assumed.

If it is determined in step S205 that the player is not registered in the blacklist (step S205: No), the exit determination unit 30a determines whether or not to permit participation (step S206). Specifically, in step S206, for example, various kinds of processing are performed, such as determining whether or not settlement processing is necessary based on the collation result performed in step S204, processing for completing settlement processing when settlement processing is required, and the like. As a result, if it is determined that entry permission is possible (step S207: Yes), the entry acceptance device 30 permits entry of the vehicle VE, and performs various operations such as raising and lowering the gate bar 32a by the gate device 32 ( step S208).

On the other hand, if it is determined in step S205 that it is blacklisted (step S205: Yes), or if it is determined in step S207 that it is not permitted to participate (step S207: No), entry acceptance will be accepted. The device 30 issues a warning notification to that effect (step S209). Various forms of warning notification can be assumed. It is also possible to contact the company to that effect. Further, in this case, new registration, continuous registration, or the like for blacklist registration is performed as necessary. When the warning notification in step S209 is issued, the entrance/exit management system 100 terminates the series of processes without permitting the entry reception device 30 to participate.

If it is not confirmed in step S202 that the security ID is used (step S210), that is, if the entry reception device 30 receives a parking ticket inserted from the reception opening 31a, the received parking ticket Based on the relevant data, a decision is made as to whether or not to permit participation (step S206), and participation processing is performed (steps S207-S209).

As described above, the entrance/exit management system 100 in this embodiment includes the token conversion server 10 that tokenizes a security ID, and the reader RD that reads the security ID, notifies the token conversion server 10, and receives notification of the corresponding token. and an information management server 50 that manages entry/exit information in association with the token notified by the reader RD. In this case, in the entrance/exit management system 100, the reader RD receives notification of a token corresponding to the security ID, and various management is performed in association with the token received by the reader RD. When managing information related to entering and exiting various facilities, such as information management of vehicles VE entering and leaving the facility and bicycles entering and exiting bicycle parking lots, even if a medium with a high security standard such as a credit card CC is used, Since there is no need to conform the entire system to high security standards, a system with high security standards can be constructed with a simple configuration.

[Second embodiment]
An example of the entry/exit management system 100 according to the second embodiment will be described below with reference to FIG. 6 and the like. In the present embodiment, in the entrance/exit management system 100 described as an example of the first embodiment, the reader further has a storage unit to store the token notification history together with the corresponding security ID. , in that the information stored in the storage unit is used. The overall configuration of the entrance/exit management system 100 is the same as that of the first embodiment, so detailed descriptions of the components denoted by the same reference numerals in the overall configuration will be omitted.

FIG. 6 is a block diagram for explaining an overview of the parking lot PA in which the entrance/exit management system 100 according to this embodiment is installed, and corresponds to FIG. In this embodiment, the entrance-side reader RDa is provided with the storage unit Rm, the entrance determination unit 20a is provided with the storage unit 20m, and the exit determination unit 30a is provided with the storage unit 30m.

Each storage unit Rm, 20m, 30m is composed of various storage devices, etc., and stores data handled during communication between the units.

As illustrated in the data table shown in FIG. 7, the storage unit Rm provided in the entry-side reader RDa stores the security ID of the credit card CC, the corresponding token ID, and the token ID as information related to the token notification history. It stores data that associates the generation time (token generation time) of the ID with the token conversion server 10 . That is, token notification histories are accumulated together with corresponding security IDs. The communication history information (accumulated data) accumulated as described above may be limited to, for example, a certain number of cases or period of time, and the oldest information may be sequentially deleted.

Here, communication is possible between those constituting the PCIDSS authentication conforming section 100A indicated by hatching. In particular, in the illustrated example, communication (wired communication in the illustrated example) is possible between an entrance-side reader RDa having a storage unit Rm and an exit-side reader RDb. When a trouble occurs in communication with the token conversion server 10, the information stored in the storage unit Rm can be obtained from the entrance side reader RDa.

The storage unit 20m provided in the entrance determination unit 20a stores, for example, the token ID transferred from the entrance-side reader RDa, the token generation time for the token ID, and the like. That is, among the data illustrated in FIG. 4A and the like, the data acquired at the time of entry is stored.

Further, here, communication is possible between those constituting the PCIDSS authentication non-conforming section 100B shown without hatching. In particular, in the illustrated example, communication (wired communication in the illustrated example) is possible between the entrance determination unit 20a including the storage unit 20m and the exit determination unit 30a. When a trouble occurs in communication with the information management server 50, the information stored in the storage unit 20m can be obtained from the entrance determination unit 20a. In addition, when the information stored in the storage unit 20m is acquired, the exit determination unit 30a stores information on a series of processing contents including the acquired information in the storage unit 30m, and then communicates with the information management server 50. returns, the series of information stored in the storage unit 30m is transmitted to the information management server 50. FIG.

An example of the operation of the entrance/exit management system 100 when the vehicle VE exits will be described below with reference to the flowchart of FIG. 8 . Here, it is possible to deal with a communication trouble between the exit side reader RDb and the token conversion server 10 and a communication trouble between the exit determination unit 30a and the information management server 50. FIG.

As in the case described with reference to FIG. 5(B), the entry reception device 30 first continues to detect the existence of the vehicle VE about to exit, and when the vehicle VE is detected, the security of the credit card CC is checked. When the use of the ID is confirmed and the security ID is read, tokenization processing is performed by the exit side reader RDb (steps S301 to S303).

Here, in the tokenization process, it is confirmed whether or not a communication trouble has occurred between the exit side reader RDb and the token conversion server 10 (step S304), and if a communication trouble has occurred (step S304: Yes). , the exit-side reader RDb inquires of the entrance-side reader RDa connected by wire, and refers to the accumulated data stored in the storage unit Rm (step S305). That is, the exit side leader RDb confirms whether or not information corresponding to the target security ID exists in the accumulated data temporarily stored at the time of entry. As a result of the reference in step S305, if the corresponding data (token ID) does not exist (step S306: No), the entry reception device 30 stops the process related to entry (step S307), and ends the series of processes. In this case, the exit reception device 30 notifies the passengers of the vehicle VE and the manager of the parking lot PA of the occurrence of the communication trouble by voice, display, or the like.

On the other hand, if the corresponding token ID exists in step S306 (step S306: Yes), the exit side leader RDb transfers it to the exit determination unit 30a, and after that, the entry reception device 30 performs processing based on the token ID. is done.

If no communication trouble occurs in step S304 (step S304: No) and a token is acquired, or if a token is acquired from the storage unit Rm through step S305 or the like, the entry reception device 30 stores the corresponding token is collated (step S308). That is, the entry reception device 30 collates the acquired token with the data managed by the information management server 50 .

Here, when collating the token, it is confirmed whether or not a communication trouble has occurred between the exit determination unit 30a and the information management server 50 (step S309). ), the exit determination unit 30a inquires of the entrance determination unit 20a connected by wire, and refers to the accumulated data stored in the storage unit 20m (step S310). In other words, the exit determination unit 30a checks whether or not information corresponding to the target token ID at the time of entry exists in the accumulated data temporarily stored at the time of entry. As a result of the reference in step S305, if the corresponding data (token ID) does not exist (step S311: No), the entry reception device 30 stops the processing related to entry (step S312), completes the series of processing, and performs communication. The occurrence of the trouble is notified to the passengers of the vehicle VE and the manager of the parking lot PA by means of voice, display, or the like.

On the other hand, if there is a corresponding token ID in step S311 (step S311: Yes), the exit determination unit 30a uses the token generation time for this token ID as equivalent to the entry time, for example, to determine the entry time. Perform permission/refusal determination processing. In addition, the exit determination unit 30a stores the acquired various data in the storage unit 30m together with the acquisition process.

If no communication trouble occurs in step S309 (step S309: No) and the token is verified, or if information about the token is acquired from the storage unit 20m through step S310 or the like, the entry reception device 30 List registration is confirmed (step S313). If it is determined in step S313 that the entry is not blacklisted (step S313: No), the exit determination unit 30a performs the same operation processing as in step S206 and subsequent steps in FIG. (Steps S314 to S317).

Further, in step S302, if it is not confirmed that the security ID is used (step S302: No), the entry reception device 30 receives the parking ticket inserted from the reception opening 31a (step S318). Based on the data regarding the parking ticket, subsequent processes for entry, such as determination of entry permission, are performed (steps S314 to S317).

As described above, in the entrance/exit management system 100 according to the present embodiment as well, various management is performed based on the token corresponding to the security ID, so that a system with a simple configuration and a high security standard can be constructed. In particular, in this embodiment, the entry-side reader RDa has a storage unit Rm that stores the token notification history together with the corresponding security ID. is disabled, the entry/exit information is managed based on the history stored in the storage unit Rm of the entry side reader RDa, and communication between the exit side reader RDb and the token conversion server 10 becomes disabled. Even if it is, it is possible to maintain access control using tokens.

Further, as another aspect of the present embodiment, referring to the flowchart of FIG. 9, one example of the operation of the entrance/exit management system 100 when the vehicle VE enters the vehicle VE among the series of operations in the entrance/exit management system 100 of the above aspect will be described. explain.

As in the case described with reference to FIG. 5A, first, the admission reception device 20 continues detecting the presence of the vehicle VE about to enter. When the use of the ID is confirmed and the security ID is read, tokenization processing is performed by the entrance side reader RDa (steps S401 to S403).

Here, in the tokenization process, it is confirmed whether or not a communication trouble has occurred between the entrance-side reader RDa and the token conversion server 10 (step S404), and if a communication trouble has occurred (step S404: Yes). , the entry-side reader RDa refers to the accumulated data stored in the built-in storage unit Rm (step S405). In other words, by tracing the history of accumulated data, it is confirmed whether or not there are security IDs that have been handled in the past that are the same as the current target security ID and token ID data corresponding thereto. . As a typical example, when a regular-use vehicle VE uses the parking lot PA multiple times within the validity period of the token ID, the relevant data (past entry data) exists in the storage unit Rm. It is assumed that

As a result of the reference in step S405, if the corresponding data (token ID) does not exist (step S406: No), the entrance reception device 20 stops the process related to entrance (step S407) and ends the series of processes. In this case, the entrance reception device 20 notifies the passengers of the vehicle VE and the manager of the parking lot PA of the occurrence of the communication trouble by voice, display, or the like.

On the other hand, if the corresponding token ID exists in step S406 (step S406: Yes), the entrance-side leader RDa transfers it to the entrance determination unit 20a, and after that, the entrance reception device 20 performs processing based on the token ID. is done.

If no communication trouble occurs in step S404 (step S404: No) and the tokenization process is performed, or if information about the token is acquired from the storage unit Rm through step S405 or the like, the entrance determination unit 20a Operation processing similar to that after step S104 in FIG. 5A, such as confirmation of blacklist registration, is performed (steps S408 to S411).

If it is not confirmed in step S402 that the security ID is used (step S402: No), the admission reception device 20 issues a parking ticket (step S412) and permits entry of the vehicle VE. , various operations such as raising and lowering of the gate bar 22a by the gate device 22 are performed in order to guide it into the hall (step S410).

[Third embodiment]
An example of the entrance/exit management system 100 according to the third embodiment will be described below with reference to FIG. 10 and the like. This embodiment differs from the first embodiment and the like in that the number of locations where readers are installed is increased compared to the entry/exit management system 100 described as an example in the first embodiment and the like. In addition, in the entrance/exit management system 100 according to the present embodiment, detailed description of each component denoted by the same reference numeral as in the case of the first embodiment, etc., will be omitted.

FIG. 10 is a conceptual diagram for explaining an overview of the parking lot PA in which the entrance/exit management system 100 according to this embodiment is installed, and corresponds to FIG. Also, the block diagram shown as FIG. 11 corresponds to FIG. 1 and the like. The entrance/exit management system 100 according to the present embodiment includes a pre-payment device 60 and a store terminal device 70 in addition to the components installed in the parking lot PA illustrated with reference to FIG. 3 and the like.

The pre-payment device 60 is a device for making it possible to perform pre-payment processing for the parking fee required for exiting the car. and a facility side leader RDc as a leader RD. As shown in the figure, of the advance payment device 60, the facility side leader RDc indicated by hatching belongs to the PCIDSS authentication compliant section 100A, while the main body portion 60a indicated by no hatching belongs to the PCIDSS authentication noncompliant section 100B. That is, the facility-side leader RDc communicates with the token conversion server 10 to perform tokenization processing, and the main body 60a receives the token from the facility-side leader RDc and communicates with the information management server 50 to acquire the token. It is possible to link information related to pre-settlement processing to the tokens.

The advance payment device 60 is installed in the facility where the parking lot PA is installed and at the entrance of a person from the parking lot PA to the facility. By using it, it is possible to quickly participate by omitting the settlement process at the time of participation.

Of the advance payment devices 60, the facility side leader RDc is composed of an EMV authentication reading device, reads PAN as a security ID from the credit card CC via the interface unit 63a, notifies the token conversion server 10, The notification of the token corresponding to the PAN is received from the token conversion server 10 .

The main body 60a of the pre-payment device 60 is configured with various control circuits, an input operation section, a display section, and the like so as to enable the above-described pre-payment processing. In other words, the main body 60a functions as a pre-payment machine that accepts pre-payment processing for the parking fee by accepting operation instructions from the user US through the above-described sections and performing various processing for pre-payment accordingly. . Here, in particular, the main body part 60a associates the processing result, that is, the result of the pre-settlement processing, with the token received from the facility-side leader RDc, and stores it in the parking data management unit 52 (token data management unit 52a) of the information management server 50. can be notified. If a parking ticket is to be used, it can be used by inserting the parking ticket through the reception opening 61a.

As described above, when the pre-payment using the pre-payment device 60 is completed, the pre-payment device 60 sends a notification to that effect to the information management server 50 responsible for parking management.

The store terminal device 70 is a device provided at a store X in a facility affiliated with the parking lot PA. A register device or the like for performing The store terminal device 70 includes a main body portion 70a for performing cash register operations according to the use of the store X, and a facility side leader RDd as a leader RD.

Among the store terminal devices 70, the facility-side reader RDd is composed of an EMV authentication reader, reads PAN as a security ID from the credit card CC via the interface section 73a, and notifies the token conversion server 10 of the PAN, The notification of the token corresponding to the PAN is received from the token conversion server 10 .

The main body part 70a of the store terminal device 70 is composed of various control circuits, an input operation unit, a display unit, etc., in order to enable the processing related to the use of the store (settlement processing for the use of the store by the cash register) as described above. ing. That is, the main body portion 70a functions as a register device by receiving operation instructions from the employee CL or the like and performing various processes in response to the operation instructions by the respective parts described above. In particular, here, the store terminal device 70 associates the processing result in the main body portion 70a that configures the PCIDSS authentication non-compliant section 100B with the token received from the facility side leader RDd that configures the PCIDSS authentication compliance section 100A. , the parking data management unit 52 (token data management unit 52a) of the information management server 50 can be notified.

With the configuration described above, the information management server 50 is capable of information management that accompanies the provision of various additional services linked to tokens in parking management. Specifically, as shown in the data table shown in FIG. 12, for example, in the data DD3 indicating the time information, in addition to the information on entering and exiting, the store X was used based on the notification from the store terminal device 70. The fact that a parking fee discount is applied corresponding to , that the advance payment using the advance payment device 60 has been completed, and the like are added, and managed together with these information-type information.

As described above, in the entrance/exit management system 100 according to the present embodiment as well, various management is performed based on the token corresponding to the security ID, so that a system with a simple configuration and a high security standard can be constructed. In particular, in this embodiment, the leader RD further includes facility side leaders RDc and RDd installed in facilities other than parking lots and bicycle parking lots. Of these, for example, the facility side leader RDd reads the security ID when using the facility (store X in the facility) and receives notification of the corresponding token from the token conversion server 10. The information management server 50 reads the facility side leader Based on the token notified by RDd, it is possible to apply processing for discounting the parking lot PA or the like. In other words, in the case of the above mode, it is possible to apply a charge discount using the token.

[Fourth embodiment]
An example of the entrance/exit management system 100 according to the fourth embodiment will be described below with reference to FIG. 13 and the like. In the first embodiment and the like, the entrance/exit management system 100 is introduced in a parking lot (or a bicycle parking lot) to manage the entrance/exit of vehicles. It differs from other embodiments in that it is a form of management, or in that it is a form of comprehensively managing entrances and exits to other facilities together with management of parking lots and the like.

As conceptually shown in FIG. 13, in the present embodiment, one aspect will be described when an entrance/exit control system 100 is introduced into the station ST. Here, a case of applying the entrance/exit management system 100 in entrance/exit management at the station ST using token notification when passing through an automatic ticket gate AG installed at the station ST will be described. In the illustrated example, an owner (not shown) holding a credit card CC passes through an automatic ticket gate AG installed at one station STα, enters the premises of the station STα, uses a train TR, and travels to another station. It conceptually represents the situation from passing through the automatic ticket gate AG installed at the station STβ to exiting the station STβ.

In this case, each automatic ticket gate AG corresponding to a station ticket gate is provided with a ticket gate reader RDe as a reader RD. The automatic ticket gate AG has an interface section AGa capable of non-contact reading of various media including credit cards CC.

The ticket gate reader RDe reads the security ID of the credit card CC through the interface unit AGa, notifies the token conversion server 10 of it, and receives notification of the corresponding token from the token conversion server 10 . In other words, the ticket gate reader RDe, which is an EMV authentication reading device, is attached inside the automatic ticket gate AG and communicates with the token conversion server 10 to perform tokenization processing, thereby configuring the PCIDSS authentication conforming unit 100A. there is

The automatic ticket gate AG receives the token notified to the ticket gate reader RDe from the ticket gate reader RDe, determines whether or not the credit card CC is allowed to pass through, and further opens and closes the gate GT as necessary. , functions as a gate device. The information of the token received from the ticket gate reader RDe in the automatic ticket gate AG and various information such as the passage time at the automatic ticket gate AG linked thereto are notified from the automatic ticket gate AG to the information management server 50. , is managed by the information management server 50 . In other words, the automatic ticket gate AG and the information management server 50 perform entry/exit management based on the token received from the ticket gate reader RDe, and can be configured as the PCIDSS authentication non-compliant section 100B.

As described above, in the entrance/exit management system 100 according to the present embodiment as well, various management is performed based on the token corresponding to the security ID, so that a system with a simple configuration and a high security standard can be constructed. In particular, in this embodiment, as the reader RD, there is provided a ticket gate reader RDe installed at the station ST as a facility other than a parking lot or a bicycle parking lot. That is, the reader RD includes a ticket gate reader RDe provided at the ticket gate of the station ST, and the information management server 50 manages information on the entry and exit of passers-by at the ticket gate based on the token notified by the ticket gate reader RDe. can be configured. That is, in the case of the above-described mode, the token is used in managing the entry and exit of passers-by at the ticket gate of the station ST.

Furthermore, as another aspect (one modified aspect) of this embodiment, as illustrated in FIG. It is good also as a structure performed intensively. In the example shown in FIG. 14, entry/exit management using a credit card CC is possible in a parking lot PA, a station ST, or the like. As an example of usage, as indicated by arrows R1 to R10 in FIG. be done. More specifically, first, the vehicle VE (on which the user US is boarding) enters the parking lot PA as indicated by an arrow R1 and is parked. Heads to station STα, passes through automatic ticket gate AG at station STα, gets on train TR from station STα, gets off at station STβ, and gets off at station STβ. , go to the destination (for example, store X) and use store X, as indicated by arrow R5. Thereafter, as indicated by arrows R6 to R9, the user US returns to the parking lot PA in the reverse order of R2 to R5. Finally, as indicated by an arrow R10, the vehicle VE leaves the parking lot PA. do.

Regarding the operation of the entrance/exit management system 100 in the series of operations described above, as indicated by the solid-line round-trip arrows in the figure, each time the credit card CC is used, the A token corresponding to the security ID is issued or notified. In addition, as indicated by the dashed round-trip arrows in the figure, the PCIDSS authentication non-conforming unit 100B, which is composed of the entrance determination unit 20a and the like, centrally manages information related to entry and exit based on issued tokens. . From a different point of view, the above aspect realizes multi-use based on the credit card CC as one physical object.

〔others〕
The present invention is not limited to the above embodiments, and can be implemented in various forms without departing from the scope of the invention.

First, in the above description, the case where the entrance/exit management system 100 is used for entrance/exit management in a parking lot, a bicycle parking lot, or a ticket gate at a station has been described, but the entrance/exit management system 100 is not limited to this, and can be used in various ways in providing various services. For example, the entrance/exit management system 100 can be applied to management of entrance/exit in event venues and membership facilities.

In addition, in the above description, as the entrance/exit management by the entrance/exit management system 100, for example, when the system is introduced into a parking lot or a bicycle parking lot, the management is performed by grasping the difference in time between entering and exiting. On the other hand, for example, when the system is installed in a ticket gate at a station, it is conceivable to manage the system by capturing the difference in distance (position) between the time of entry and the time of exit. However, the items to be managed in the entrance/exit management by the entrance/exit management system 100 are not limited to time and distance, and various things can be considered. It is conceivable that the difference in weight between them may be captured, and various control items can be provided according to the object to be managed.

In the above description, credit cards are used as the medium for issuing tokens to be managed. It is also conceivable to configure the entrance/exit management system 100 by using these together with a credit card.

In addition, in the above description, for example, payment of charges at a parking lot, that is, settlement processing, can be performed in various ways, and does not necessarily have to be limited to credit card settlement. On the other hand, from a different point of view on the above aspect, the user's convenience is improved by making it possible to deal with a single credit card (unified) by lumping together cases with and without payment (non-payment). It can also be understood that the mode is designed to

10 -- token conversion server, 20 -- admission reception device, 20 a -- entrance determination unit, 20 m -- storage unit, 21 -- ticket issuing machine, 21 a -- ejection port, 22 -- gate device, 22 a -- gate bar, 23 a -- interface unit, 30 -- entry Reception device 30a Exit determination unit 30m Storage unit 31 Payment device 31a Reception port 32 Gate device 32a Gate bar 33a Interface unit 50 Information management server 51 Communication unit 52 Parking data management unit 52a Token data management unit 52b Parking ticket data management unit 60 Advance payment device 60a Main unit 63a Interface unit 70 Store terminal 70a Main unit 73a Interface part 100... Entrance/exit management system 100A... PCIDSS authentication compliant part 100B... PCIDSS authentication non-compliant part A1, A2... Arrow AG... Automatic ticket gate AGa... Interface part CC... Credit card CL... Employee , DD1 to DD4... data, DT... data table, GT... gate, PA... parking lot, R1 to R10... arrow, RD... reader, RDa... entrance side reader, RDb... exit side reader, RDc, RDd... facility side reader , RDe... ticket gate reader, Rm... storage unit, ST, STα, STβ... station, TR... train, US... user, VE... vehicle, X... store

Claims (10)

a token conversion server that tokenizes a security ID;
a reader that reads a security ID and notifies the token conversion server and receives notification of the corresponding token;
An entry/exit management system comprising an information management server that manages entry/exit information in association with tokens notified by the reader. The reader is provided in a parking lot or a bicycle parking lot,
2. The entrance/exit management system according to claim 1, wherein said information management server manages entrance/exit information of vehicles using said parking lot or said bicycle parking lot based on the token notified by said reader. 3. The entrance/exit management system according to claim 2, further comprising a fare adjustment machine communicably connected to said information management server and performing fare settlement based on vehicle entrance/exit information. 4. The entrance/exit management system according to claim 3, wherein said fare adjustment machine includes a pre-payment fare adjustment machine that accepts pre-payment processing for charges. The leader further includes a facility-side leader installed in a facility other than the parking lot or the bicycle parking lot,
When the facility is used, the facility-side leader reads the security ID and receives notification of the corresponding token from the token conversion server,
5. The entrance/exit management according to any one of claims 2 to 4, wherein said information management server performs a process of applying a fee discount for said parking lot or said bicycle parking lot based on the token notified by said facility-side reader. system. the reader has a storage unit that stores a token notification history together with a corresponding security ID;
6. The information management server according to any one of claims 1 to 5, wherein when communication with the token conversion server becomes impossible in the reader, the information management server manages input/output information based on the history stored in the storage unit. Access control system as described in paragraph. The reader is composed of an entrance-side reader installed at the entrance and an exit-side reader installed at the exit,
7. The entrance/exit management system according to any one of claims 1 to 6, wherein said entry-side reader transmits a token notified upon entry to an exit-side reader. an entrance determination unit that receives notification of a token from the entrance-side reader, is communicatively connected to the information management server, and determines whether or not to permit entry;
an exit determination unit that receives notification of a token from the exit side leader, is communicatively connected to the information management server, and determines whether or not to permit entry;
8. The entrance/exit management system according to claim 7, wherein when communication with said information management server becomes impossible, said exit determination unit determines whether or not to permit entry based on a token notification from said entrance-side leader. The reader includes a ticket gate reader provided at the ticket gate of the station,
9. The entrance/exit management system according to any one of claims 1 to 8, wherein said information management server manages entrance/exit information of passers-by at the ticket gate based on the token notified by said ticket gate reader. 10. The entrance/exit management system according to any one of claims 1 to 9, wherein said information management server sets an expiration date and a blacklist target for the token notified by said reader.

Images