Touch payment terminal device, fare touch payment system, and fare touch payment method

Abstract

This invention provides a contactless payment terminal and fare payment method for contactless credit card payments on public transportation that enable smooth payment processing without delay for users, even in environments where communication to the cloud cannot be established. [Solution] In a fare contactless payment system, an in-vehicle system 11 in which a contactless payment terminal device 12 and its higher-level control device 13 are connected to each other via telecommunication, the contactless payment terminal device includes a microcomputer 120 that includes a card information reading means for reading card information from the user's credit card, a local token generation means for generating a local token based on the read card information, and a provisional credit authorization means for performing provisional credit authorization on the user's credit card based on the generated local token.

Description

[Technical Field]

[0001] The present invention relates to a fare touch payment system for performing touch payment of transportation fares with a credit card, and to a fare touch payment method in such a system. The present invention also relates to a touch payment terminal device provided in such a fare touch payment system. [Background Art]

[0002] Conventionally, for cashless payment of fares in transportation means such as railways and bus routes, the CBT (Card Based Ticketing) system using a non-contact IC card (a so-called transportation IC card) capable of recording usage information such as boarding / alighting history has been mainstream. On the other hand, in recent years, an increasing number of transportation operators have introduced the ABT (Account Based Ticketing) system that performs cloud payment using a credit card on which information cannot be written or a QR code (registered trademark) as a medium. Credit cards have higher versatility than transportation IC cards, and touch payment systems using credit cards are regarded as promising particularly as a payment method for MaaS (Mobility as a Service), which is being promoted as part of transportation DX and in which a plurality of transportation operators cooperate to provide various transportation means.

[0003] Fig. 6 shows a conceptual diagram of a conventional credit card touch payment system. For example, Patent Document 1 discloses a fare payment system in which a boarding terminal (901A) installed at a boarding station, an alighting terminal (901B) installed at an alighting station, a fare calculation device (903) that calculates a fare based on boarding station information and alighting station information, and a payment proxy device (906) that proxies credit card payment processing between the system and a payment device (910) are connected via a network (N). [Prior Art Documents] [Patent Documents]

[0004] [Patent Document 1] Patent No. 7545593 [Overview of the project] [Problems that the invention aims to solve]

[0005] In the system described in Patent Document 1, a payment processing device (906) located in the cloud works in conjunction with a payment device (910) operated by a credit card company to perform credit authorization and payment processing for credit cards. The payment processing device (906) also determines the validity of credit cards touched to the boarding terminal (901A) and the alighting terminal (901B), and transmits a pass control signal to the boarding terminal (901A) and the alighting terminal (901B) to open and close the ticket gates according to the result.

[0006] However, in conventional systems, data is exchanged between the station system (901A, 901B, 902A, 902B) and the cloud-based payment processing device (906) and / or fare calculation device (903) via the internet. Therefore, delays in data transmission and reception may occur depending on the network communication status. Furthermore, especially in cases where cloud payments require mobile data communication, such as on moving route buses, it is conceivable that payments may not be completed within the stopping time due to reasons such as inability to connect to the internet within the bus stop area or unstable communication.

[0007] Therefore, the present invention aims to provide a technology that enables smooth payment processing without making users wait in a fare contactless payment system for paying transportation fares with a credit card. [Means for solving the problem]

[0008] To solve the above-mentioned problems, the present invention provides a touch payment terminal device for settling transportation fares with a credit card, wherein the touch payment terminal device comprises: a card information reading means for reading card information from a transportation user's credit card; a local token generation means for generating a local token based on the read card information; and a temporary credit authorization means for performing a temporary credit authorization on the credit card based on the generated local token.

[0009] In a contactless payment terminal device, it is preferable that the local token includes a hash value obtained by hashing the card information.

[0010] Furthermore, it is preferable that the touch payment terminal device is communicatively connected to a higher-level control device that settles the usage fare and a card payment processing server that handles credit card payments, and comprises authentication request means that transmits the card information read by the card information reading means to the card payment processing server to request authentication of the credit card, and authentication notification means that transmits the payment token corresponding to the card information returned from the card payment processing server to the higher-level control device in association with the local token.

[0011] Furthermore, it is preferable that the contactless payment terminal device has a negative list containing information on local tokens corresponding to expired credit cards.

[0012] Furthermore, the present invention relates to a fare contactless payment system in which any of the aforementioned contactless payment terminal devices and a higher-level control device are electrically connected to each other, wherein the higher-level control device has a usage history table that records the local token in association with at least the date and time information on when the card information was read.

[0013] The fare contactless payment system preferably includes a usage history recording means in which the higher-level control device records a payment token corresponding to the card information returned from the card payment processing server in association with the local token and records it in the usage history table.

[0014] Furthermore, the present invention relates to a fare contactless payment system in which a contactless payment terminal device and a card payment processing server that handles credit card payments are communicated together, wherein the negative list of the contactless payment terminal device is updated to be identical to the negative list of the card payment processing server.

[0015] Furthermore, the present invention relates to a fare contact payment method in a fare contact payment system in which any of the aforementioned contact payment terminal devices, a higher-level control device thereof, and a card payment processing server that handles credit card payments are interconnected via telecommunication, comprising the steps of: when a user boards a public transport, the contact payment terminal device reads card information from the user's credit card, generates a local token based on the read card information, and transmits the generated local token to the higher-level control device; the higher-level control device associates the user's boarding information with the received local token and records it in a usage history table; the contact payment terminal device transmits the read card information to the card payment processing server; and the card payment processing server processes the received card information in accordance with The fare contact payment method includes the steps of: transmitting a payment token to the higher-level control device; the higher-level control device recording the received payment token in the usage history table associated with the local token; when the user alights from the transportation, the contact payment terminal device reading card information from the user's credit card, generating a local token based on the read card information, and transmitting the generated local token to the higher-level control device; the higher-level control device associating the user's alighting information with the boarding information corresponding to the received local token and recording it in the usage history table; and settling the fare for the section used by the user based on the boarding information and alighting information recorded in the usage history table. [Effects of the Invention]

[0016] According to the present invention, a touch payment terminal device can generate a local token based on the card information of a touched credit card, and use that local token to perform processing within the in-vehicle system (including the touch payment terminal device and a higher-level control device). Therefore, even in environments where communication cannot be established between the in-vehicle system and a cloud server (including a card payment processing server) when a credit card is touched, the payment processing using the local token can proceed. Consequently, when using public transportation, smooth payment processing can be performed without making users wait. [Brief explanation of the drawing]

[0017] [Figure 1] This is a conceptual diagram illustrating the configuration of a contactless fare payment system according to one embodiment. [Figure 2] This is a block diagram illustrating the general outline of each element / device that constitutes a fare contactless payment system according to one embodiment. [Figure 3] This is a flowchart showing the credit card contactless payment process when boarding a bus. [Figure 4] This diagram illustrates an example of a usage history table managed by a higher-level control unit. [Figure 5] This is a flowchart showing the process of using a credit card when alighting from a bus. [Figure 6] This is a conceptual diagram illustrating the configuration of a conventional fare settlement system. [Modes for carrying out the invention]

[0018] Hereinafter, specific embodiments of the present invention will be described by taking a fare touch payment system for touch payment of route bus (shared bus) fares by credit card using the ABT (Account Based Ticketing) method as an example. Here, the ABT method refers to a method in which, instead of recording transportation usage information on a medium such as an IC card or magnetic ticket, the usage information is associated with ID information that identifies a user (for example, a credit card or a two-dimensional code) and managed by a server on the cloud. It should be noted that the basic configuration of the present invention described below is not limited to route buses only, and can also be applied to transportation means other than buses that adopt the ABT method (for example, railways).

[0019] <Configuration of fare touch payment system 10> FIG. 1 is a conceptual diagram for explaining the configuration of the fare touch payment system 10 according to the present embodiment, which targets a route bus (hereinafter simply referred to as "bus B"). FIG. 2 is a block diagram illustrating an outline of each element / device constituting the fare touch payment system 10.

[0020] The fare touch payment system 10 according to the present embodiment includes an in-vehicle system 11 installed in each bus B owned by a bus operating company (transportation operator), and a card payment agency server 14 communicatively connected to each in-vehicle system 11 via a network N such as the Internet. The in-vehicle system 11 mounted on the bus B is a computer system that performs processing such as operation management of the bus B in cooperation with a navigation system and management of fares for boarding sections. The in-vehicle system 11 incorporates the touch payment terminal device 12 according to the present invention and a host control device 13 that performs processing such as settlement of used fares.

[0021] In addition, the fare touch payment system 10 according to the present embodiment is positioned as a system responsible for fare payment processing in the ABT system of a bus operating company. The ABT system referred to herein includes the touch payment terminal device 12 and the host control device 13 mounted on each bus B, and a fare management server 16 that manages sales data 601 such as used fares for each bus B on the cloud.

[0022] The above-mentioned elements / devices that constitute the fare contactless payment system 10 according to this embodiment will be described in more detail below.

[0023] <<Touch payment terminal device 12>> First, let's describe the touch payment terminal device 12. The touch payment terminal device 12 is installed, for example, near the entrance / exit of bus B. Alternatively, the touch payment terminal device 12 may be integrated together with the higher-level control device 13 in the fare box or other location on bus B. Or, the touch payment terminal device 12 may be connected to the higher-level control device 13 via a communication cable at a location separate from it. Furthermore, if there are two entrance / exit locations on bus B, one at the front and one in the middle, two (or more) touch payment terminal devices 12 may be installed at each entrance / exit, one for boarding and one for alighting. In that case, each touch payment terminal device 12 is connected to a single higher-level control device 13. The communication connection between such a touch payment terminal device 12 and the higher-level control device 13 can utilize a serial or parallel bus system or an in-vehicle network such as CAN (Controller Area Network).

[0024] The touch payment terminal 12 connects to the card payment processing server 14 via mobile data communication. For this purpose, the onboard system 11 of bus B is equipped with a wireless communication module 111 for connecting to a mobile network. The wireless communication module 111 may be incorporated into the touch payment terminal 12. Alternatively, the wireless communication module 111 may be incorporated into the higher-level control unit 13. If the touch payment terminal 12 and the higher-level control unit 13 share a single wireless communication module 111, that wireless communication module 111 may also have router functionality.

[0025] The touch payment terminal device 12 includes a microcomputer 120, a card reader 121 for reading credit card information (hereinafter simply referred to as "card information") from credit card C, a cache memory 122, a data storage 123, and an input / output interface 125 for controlling data input and output with other devices.

[0026] The card reader 122 has the function of reading card information from a contactless payment-compatible credit card C via near-field communication (NFC). In addition, the card reader 122 may be equipped with a function to read card information using a contact method (magnetic and / or IC chip) in order to enable payment even with credit cards that do not support contactless communication.

[0027] The touch payment terminal device 12 includes several arithmetic processing means, such as a card information reading means 201, a local token generation means 202, a provisional credit authorization means 203, a negative check means 204, a card information encryption means 205, an authentication request means 206, and an authentication notification means 207, each of which is realized by the processor of the microcomputer 120 performing arithmetic processing according to a program.

[0028] The card information reading means 201 is a processing means for reading card information from the credit card of a user using bus B. When credit card C is touched to the card reader 121, the card information is read via short-range wireless communication. The card information read by the card reader 121 may include the card number, expiration date, cardholder's name, and security code.

[0029] In this embodiment, one feature of the touch payment terminal device 12 is that it includes a local token generation means 202. The local token generation means 202 is an arithmetic processing means that generates a local token based on the card information read by the card reader 121. For example, the local token can be a hash value obtained by hashing a string that combines the credit number and the expiration date. Alternatively, for example, a local token may be generated by hashing a string in which part of the credit number is masked. Since the hash value cannot be converted back to the original value, the card information cannot be reconstructed from the generated local token. Therefore, by using a local token, it is possible to safely and quickly perform processing that requires the identification of personal information without storing card information.

[0030] The local token generated by the local token generation means 202 is temporarily stored in the cache memory 122. The provisional credit granting means 203 is a processing means that performs provisional credit granting for credit card C based on the local token generated by the local token generation means 202. The provisional credit granting means 203 performs a preliminary screening check on the generated local token and grants provisional credit only to those that meet predetermined conditions. For example, it can check whether the generated local token is one that has been stored in the cache memory 122 and grant provisional credit if there is no match, i.e., if it is not a duplicate use.

[0031] Thus, in this embodiment, the provisional credit authorization means 203 provisionally authorizes credit card C via a local token. This allows processing within the in-vehicle system 11 to be performed using this local token instead of the token issued by the card payment processing server 14 (referred to as the "payment token" in this specification). In other words, even if mobile communication is not established between the in-vehicle system 11 and the card payment processing server 14 when the credit card is read (touched), processing such as allowing the user to board the vehicle can proceed.

[0032] Furthermore, the touch payment terminal device 12 may also include a negative check means 204. The data storage 123 stores a negative list 124 that records information on local tokens corresponding to credit cards that have expired or become invalid for other reasons. The negative check means 204 checks whether the generated local token is listed in the negative list 124 or not. The provisional credit means 203 can determine that the generated local token is valid if it is not listed in the negative list 124 and can provisionally grant credit to that local token.

[0033] Furthermore, the negative list 124 held by the touch payment terminal device 12 is updated asynchronously, just like the negative list 411 held by the card payment processing server 14, as will be described later.

[0034] The card information encryption means 205 is a computational processing means that encrypts the credit card information read by the card information reading means 201 using a predetermined algorithm.

[0035] The authentication request means 206 is a computational processing means that requests authentication (credit authorization) of credit card C by transmitting encrypted credit card information to the card payment processing server 14 via the wireless communication module 111. The authentication request for credit card C includes, for example, identification of the credit card number and name, and verification of its validity such as the expiration date and credit limit.

[0036] Furthermore, as will be described later, the card payment processing server 14 cooperates with the credit card company's payment server 15 and performs a credit check to verify the validity of the credit card information sent along with the authentication request. If it determines that the credit card C is valid, it returns the credit information (authorization) to the touch payment terminal device 12. At this point, in order to enhance the security of personal information, the card payment processing server 14 issues a payment token in which the credit card number has been replaced with another string of characters. The credit card company's payment server 15 can identify card information such as the credit card number based on the converted payment token and perform authentication processing such as credit check.

[0037] The authentication notification means 207 is a calculation processing means that notifies the higher-level control unit 13 of the result when authentication information, such as credit authorization for credit card C, is returned from the card payment processing server 14. For example, if credit card C is authorized as valid, the authentication notification means 207 sends the payment token corresponding to credit card C to the higher-level control unit 13, associating it with the generated local token.

[0038] <<Higher-level control device 13>> Next, the configuration of the higher-level control device 13 will be described. The higher-level control device 13 comprises a microcomputer 130, a data storage device 131, and an input / output interface 132 for controlling data input and output with other devices. The data storage device 131 stores data tables such as the operation management table 135, the fare table 136, and the usage history table 137 in a readable and updatable manner.

[0039] The higher-level control device 13 includes several arithmetic processing means, such as the following duplicate check means 301, usage history recording means 302, fare settlement means 303, and usage information transmission means 304, each of which is realized by the processor of the microcomputer 130 performing arithmetic processing according to the program.

[0040] The duplicate check means 301 is a calculation processing means that refers to the usage history table 137 of the data storage 131 and checks whether the local token transmitted from the touch payment terminal device 12 is a duplicate.

[0041] The usage history recording means 302 is a calculation processing means that records boarding information and alighting information in the usage history table 137 in association with local tokens. Here, boarding information includes information about the location (which may be the name of the bus stop, latitude and longitude, etc.) where the user associated with the local token boarded bus B, and information about the date and time of boarding. Alighting information includes information about the location (which may be the name of the bus stop, latitude and longitude, etc.) where the same user alighted from bus B, and information about the date and time of alighting. Such boarding and alighting information can be obtained each time from the touch payment terminal device 12 and / or the bus B operation system.

[0042] The fare settlement means 303 is a calculation processing means that settles the fare for a user associated with a local token who used bus B, by referring to the usage history table 137. The usage fare can be settled by referring to the fare table 136 based on the boarding and alighting location information recorded in the usage history table 137.

[0043] The usage information transmission means 304 is a calculation processing means that transmits the usage information recorded in the usage history table 137, along with the payment token and local token, to the card payment processing server 14 via the wireless communication module 111 in order to process the fare payment. The "usage information" referred to here includes the "boarding information" and "alighting information" mentioned above, as well as the confirmed fare information.

[0044] <<Fare Management Server 16>> Next, the fare management server 16, which constitutes the ABT system together with the in-vehicle system 11, will be described. The fare management server 16 has a sales database 161 that manages sales data such as fares for each bus B. In the sales database 161, usage information transmitted from the higher-level control device 13 of each bus B is recorded in association with the payment token and local token of the credit card C. That is, the sales database 161 of the fare management server 16 manages, as table data, at least the payment token and local token that identify the user, the bus number of the bus route ridden, information on the date and time and location of boarding and alighting, and information such as the date and time and location of alighting and the confirmed fare.

[0045] Furthermore, the fare management server 16 may also perform processing to settle the fare based on the aforementioned boarding and alighting information transmitted from the higher-level control device 13 of bus B. In that case, the fare information may be returned to the higher-level control device 13 along with the settlement token.

[0046] Furthermore, the fare management server 16 has a processing function that sends the settled fare information along with the settlement token to the card payment processing server 14 and requests credit card advance payment of the confirmed fare.

[0047] <<Card Payment Processing Server 14>> Next, the card payment processing server 14 will be described. The card payment processing server 14 is a cloud server on the network and has processing functions that provide a service of paying fares using credit card C in cooperation with the credit card company's payment server 15. For this purpose, the card payment processing server 14 is equipped with a transaction database 141 that records transaction information including the usage history and fares of transportation services provided by the fare management server 16 or the onboard system 11 of bus B.

[0048] The card payment processing server 14 includes several computational processing means, such as a card information decryption means 401, a credit request means 402, a credit result notification means 403, a transaction history recording means 404, an advance payment request means 405, and a negative list update means 406, each of which is implemented through computational processing.

[0049] The card information decryption means 401 is a computational processing means that decrypts encrypted credit card information transmitted from the contactless payment terminal device 12.

[0050] The credit authorization request means 402 is a computational processing means that requests authentication and credit authorization from the credit card company's settlement server 15 based on the decrypted card information. The authentication request for credit card C includes, for example, identification of the credit card number and name (cardholder's name), and confirmation of validity such as the expiration date and credit limit. Here, the card payment processing server 14 issues a settlement token in which the credit card number has been rewritten with another string to enhance the security of personal information. The credit card company's settlement server 15 can identify card information such as the credit card number based on the converted settlement token. If the settlement server 15 determines that the credit card C is valid, it returns credit authorization information to the card payment processing server 14.

[0051] The credit approval result notification means 403 is a calculation processing means that notifies the touch payment terminal device 12 of the credit approval result returned from the payment server 15.

[0052] The transaction history recording means 404 is a calculation processing means that records information such as transaction history settled using credit card C in the transaction database 141. The transaction data 410 stored in the transaction database 141 includes information such as the usage history and fares of bus B. Such transaction information is associated with a settlement token and a local token generated from the bus B user's credit card C and provided by the fare management server 16 or the bus B's onboard system 11.

[0053] The advance payment request means 405 is a calculation processing means that requests the settlement server 15 to make an advance payment of the fare based on the settlement token.

[0054] The negative list update means 406 receives the credit check result from the credit card company's settlement server 15, and if the credit card C is invalid, it records the tokens (settlement token and local token) of the credit card C in the negative list 411. The negative list update means 406 also promptly mirrors and updates the tokens in the negative list 124 held by each bus B's touch payment terminal device 12.

[0055] <Operation of the fare contactless payment system 10> Next, we will explain the operation of the fare contactless payment system 10 described above, along with a specific example of a fare contactless payment method using it.

[0056] First, let's explain the system operation when a user boards bus B. Figure 3 is a flowchart showing the credit card contact process upon boarding.

[0057] When bus B stops at a bus stop to allow passengers to board, the onboard system 11 of bus B sends a signal to the contactless payment terminal 12 to start reading the credit card (step S101). When the contactless payment terminal 12 receives the signal to start reading, it activates accordingly and is ready to read the card (step S102).

[0058] With the touch payment terminal device 12 activated, when a user touches credit card C to the card reader 121, the card information reading means 201 reads the card information from the credit card C using NFC (step S103). Subsequently, the local token generation means 202 generates a local token from the read card information (step S103). The generated local token includes a hash value obtained by hashing the read card information. Alternatively, a local token may be generated by hashing a string with part of the credit number masked. The generated local token is temporarily stored in the cache memory 122.

[0059] Next, the negative check means 204 checks whether the generated local token is listed in the negative list 124 (step S105). If the generated local token is not listed in the negative list 124, the touched credit card C is deemed to be valid for the time being (step S106; YES). In that case, the provisional credit means 203 can provisionally grant credit to the local token. If the local token is listed in the negative list 124, the credit card C is deemed to be invalid (step S106; NO), and the system proceeds to error processing without accepting touch authentication (step S107).

[0060] Next, the local token generated by the touch payment terminal device 12 is sent to the higher-level control device 13 (step S108). When the higher-level control device 13 receives the local token (step S111), the duplicate usage check means 301 refers to the usage history table 137 and checks whether the transmitted local token is a duplicate (step S112).

[0061] If a local token identical to the one generated is already being used by another passenger on board (step S113; YES), the process switches to using a token issued by the card payment processing server 14 (hereinafter referred to as the "payment token").

[0062] The usage history recording means 302 records the ride information in the usage history table 137 in association with the transmitted local token (step S114). Figure 4(a) shows an example of the usage history table 137 in which the local token and ride information are recorded. Here, the ride information includes information about the location where the user associated with the local token boarded bus B (which may be the name of the bus stop, latitude and longitude, etc.), and information about the date and time of boarding. The higher-level control device 13 then transmits the ride information to the touch payment terminal device 12 in association with the local token (step S115).

[0063] Meanwhile, in the touch payment terminal device 12, the card information encryption means 205 encrypts the card information read by the card reader 121 using a predetermined algorithm (step S121). Then, when mobile communication to the network N is established, the authentication request means 206 sends an authentication request for credit card C to the card payment processing server 14 via the wireless communication module 111 (step S122). The authentication request from the touch payment terminal device 12 includes encrypted card information, a generated local token, and ride information. Furthermore, the card information is deleted immediately after being sent to the card payment processing server 14 (step S123). In this way, the touch payment terminal device 12 does not retain card information, thus preventing the leakage of personal information, including card information.

[0064] In the card payment processing server 14, the card information decryption means 401 decrypts the encrypted credit card information transmitted from the touch payment terminal device 12 (step S126). The card payment processing server 14 also issues a payment token in which the decrypted credit card number has been replaced with another string.

[0065] The credit authorization request means 402 requests authorization for credit card C by sending a payment token to the credit card company's payment server 15 (step S127). The authentication request for credit card C includes, for example, identification of the credit card number and name, and verification of its validity such as the expiration date and credit limit. If the payment server 15 determines that credit card C is valid, it returns authorization information to the card payment processing server 14. The credit authorization result notification means 403 then notifies the touch payment terminal device 12 of the credit authorization result returned from the payment server 15, associating it with the payment token (step S127).

[0066] Furthermore, the transaction history recording means 404 of the card payment processing server 14 associates the ride information transmitted in step S122 with the payment token and records it in the transaction data 410 (S129).

[0067] When the authentication notification means 207 of the touch payment terminal device 12 receives credit authorization information for credit card C from the card payment processing server 14, it notifies the higher-level control device 13 of the authorization result, associating it with the payment token and local token (step S130). This allows the higher-level control device 13 to recognize the payment token of the authorized credit card C. Then, the usage history recording means 302 of the higher-level control device 13 records the transmitted payment token in the ride history column associated with the local token in the usage history table 137 (step S131). Figure 4(b) shows an example of the usage history table 137 with the local token, payment token and ride information recorded at this point.

[0068] Next, we will explain the system operation when a passenger alights from bus B. Here, Figure 5 is a flowchart showing the credit card contact process upon alighting.

[0069] When bus B stops at a bus stop to allow passengers to disembark, the onboard system 11 of bus B, specifically the higher-level control unit 13, transmits a signal to the contactless payment terminal 12 to begin reading the credit card (step S201). Upon receiving the signal, the contactless payment terminal 12 activates accordingly and completes the preparation for reading the card (step S202).

[0070] When a user alights from bus B and touches credit card C to card reader 121, card information reading means 201 reads card information from credit card C (step S203). Subsequently, local token generation means 202 generates a local token from the read card information (step S203).

[0071] Next, the touch payment terminal device 12 checks the cache memory 122 to see if there is a ride record for the generated local token (step S205). If there is no ride record for the local token (step S206; NO), it proceeds to the ride processing (step S207). If there is a ride record for the generated local token (step S206; YES), it notifies the higher-level control device 13 of that local token (step S208).

[0072] When the higher-level control device 13 receives a local token, the usage history recording means 302 records the disembarkation information in the usage history table 137 in association with the transmitted local token (step S214). Figure 4(c) shows an example of the usage history table 137 in which the local token, payment token, boarding information, and boarding information are recorded. Here, the disembarkation information includes information about the location (which may be the name of the bus stop, latitude and longitude, etc.) where the user associated with the local token disembarked from bus B, and information about the date and time of disembarkation. Since the local token and boarding information at the time of boarding are already recorded in the usage history table 137, the boarding information and disembarkation information of the user are associated with the same local token.

[0073] Subsequently, the higher-level control device 13 associates the local token with the disembarkation information and sends it back to the touch payment terminal device 12 (step S215).

[0074] Next, the fare settlement means 303 settles the fare for the section used by the user based on the boarding and alighting information recorded in the usage history table 137 (step S216). In addition, it is also possible that the fare settlement and the processing of the credit advance payment request to the card payment processing server 14, which will be described later, are centrally performed by a fare management server 16 on the cloud operated by the transportation operator.

[0075] Meanwhile, in the touch payment terminal device 12, the read card information is immediately deleted (step S223). Then, in an environment where mobile communication to network N is established, the touch payment terminal device 12 transmits the disembarkation information, along with the payment token corresponding to the local token, to the card payment processing server 14 via the wireless communication module 111 (step S224).

[0076] In the card payment processing server 14, the transaction history recording means 404 associates the transmitted disembarkation information with the payment token and records it in the transaction data 410 (S229).

[0077] Furthermore, the higher-level control device 13 associates the fare information settled in step S216 with the settlement token and sends it to the card payment processing server 14 (step S231).

[0078] The transaction history recording means 404 of the card payment processing server 14 associates the fare information transmitted from the higher-level control device 13 (or the fare management server 16) with the payment token and records it in the transaction data 410 (S232). Then, the advance payment request means 405 of the card payment processing server 14 requests the payment server 15 to make a credit advance payment of the fare based on the payment token (step S233). This completes the credit card payment by the fare touch payment system 10 of this embodiment. [Explanation of symbols]

[0079] 10. Fare contactless payment system 11. In-vehicle systems 12. Touch payment terminal device 13. Higher-level control unit 14. Card payment processing servers 15 Payment Server 16 Fare Management Server 111 Wireless communication module 120 Microcomputers 121 Card Reader 122 cache memory 123 Data Storage 124 Negative List 125 Input / Output Interfaces 130 Microcomputers 131 Data Storage 132 Input / Output Interfaces 135 Operation Management Table 136 Fare Table 137 Usage History Table 141 Transaction Database 161 Sales Database 201 Card Information Reading Method 202 Local token generation method 203 Provisional credit assessment method 204 Negative Checking Methods 205 Card Information Encryption Methods 206 Authentication Request Method 207 Authentication notification method 301 Duplicate Use Check Method 302 Means for recording usage history 303 Fare Settlement Methods 304 Means for transmitting user information 401 Card Information Decryption Method 402 Credit Request Method 403 Credit result notification means 404 Transaction history recording means 405 Payment Request Method 406 Negative List Update Methods 410 Transaction Data 411 Negative List 601 Sales Data

Claims

1. A contactless payment terminal device for paying transportation fares with a credit card, The aforementioned contactless payment terminal device A card information reading method that reads card information from the credit cards of transportation users, A local token generation means that generates a local token based on the card information read, A temporary credit authorization means that performs temporary credit authorization of the credit card based on the generated local token, A contactless payment terminal device equipped with the following features.

2. The touch payment terminal device according to claim 1, wherein the local token includes a hash value obtained by hashing the card information.

3. The aforementioned touch payment terminal device is connected to a higher-level control unit that settles the fare and a card payment processing server that handles credit card payments, Authentication request means that transmits the card information read by the card information reading means to the card payment processing server and requests authentication of the credit card, Authentication notification means that transmits to the higher-level control device an authentication notification means that associates the payment token corresponding to the card information returned from the card payment processing server with the local token. A touch payment terminal device according to claim 1, comprising:

4. The contactless payment terminal according to claim 1, wherein the contactless payment terminal has a negative list containing information on local tokens corresponding to expired credit cards.

5. A fare contact payment system comprising a contact payment terminal device according to any one of claims 1 to 4 and a higher-level control device connected to each other via telecommunication, A fare contactless payment system in which the higher-level control device has a usage history table that records the local token in association with at least the date and time information on when the card information was read.

6. The fare touch payment system according to claim 5, wherein the higher-level control device includes a usage history recording means that records a payment token corresponding to the card information returned from the card payment processing server in association with the local token and records it in the usage history table.

7. A fare contactless payment system comprising a contactless payment terminal device as described in claim 4 and a card payment processing server that handles credit card payments, wherein the contactless payment terminal device is communicated with the contactless payment terminal device described in claim 4, and the contactless payment system is communicated with the contactless payment server that handles credit card payments, A fare contactless payment system in which the negative list of the contactless payment terminal device is updated to be the same as the negative list of the card payment processing server.

8. A fare contact payment method in a fare contact payment system in which a contact payment terminal device according to any one of claims 1 to 4, a higher-level control device thereof, and a card payment processing server that handles credit card payments are interconnected via telecommunication, When a user boards public transportation, The aforementioned contactless payment terminal device The card information is read from the user's credit card. A local token is generated based on the card information read, The steps include: transmitting the generated local token to the higher-level control device; The higher-level control device records the user's ride information in a usage history table, associating it with the received local token. The touch payment terminal device transmits the card information it has read to the card payment processing server. The card payment processing server transmits a payment token corresponding to the received card information to the higher-level control unit. The higher-level control device records the received payment token in the transaction history table associated with the local token, When a user disembarks from public transportation, The aforementioned contactless payment terminal device The card information is read from the user's credit card. A local token is generated based on the card information read, The steps include: transmitting the generated local token to the higher-level control device; The aforementioned higher-level control device The steps include: associating the user's disembarkation information with the boarding information corresponding to the received local token and recording it in the usage history table; A step of settling the fare for the section used by the user based on the boarding information and alighting information recorded in the usage history table, Includes contactless payment methods for fares.

Images