Fare contactless payment system and fare contactless payment method

Abstract

We provide a contactless fare payment system for public transportation that allows users to apply discounted fares even when they transfer to a different route. [Solution] The fare contactless payment system comprises an in-vehicle system 11 in which a contactless payment terminal and its higher-level control unit are electrically connected to each other, and a card payment processing server. The contactless payment terminal generates a local token based on card information read from the user's credit card. The card payment processing server transmits transfer information (most recent disembarkation information) associated with the local token to the higher-level control unit. This allows the higher-level control unit to apply a discounted fare to the disembarkation fare based on the transfer information.

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 a fare touch payment method in such a system. [[Background Art]]

[0002] Conventionally, for cashless payment of fares in transportation means such as railways and bus routes, the CBT (Card Based Ticketing) method using a contactless IC card (so-called transportation IC card) that can record 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) method that performs cloud payment using a credit card to which information cannot be written or a QR code (registered trademark) as a medium. Credit cards have higher versatility compared to transportation IC cards, and credit card-based touch payment systems are regarded as promising especially as a payment method for MaaS (Mobility as a Service), which is promoted as part of transportation digital transformation 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 proxys credit card payment processing between the payment device (910) are connected via a network (N). [[Prior Art Documents]] [[Patent Documents]]

[0004] [[Patent Document 1]] Japanese Patent No. 7545593 [[Summary of the Invention]] [Problems that the invention aims to solve]

[0005] When using a transportation IC card for cashless payment of fares, the boarding history can be stored in the IC card's memory. Therefore, it is possible to refer to transfer information for other routes recorded on the IC card and convert it to a discounted fare. However, in fare contactless payment systems that use credit cards as the ticket medium, such as in Patent Document 1, the card itself cannot store information such as boarding history. As a result, when a user uses another route for a transfer, it is not possible to obtain information such as the station where they previously disembarked, and therefore fare discounts cannot be applied.

[0006] Therefore, the present invention aims to provide a fare contactless payment system and a fare contactless payment method that allow a discounted fare to be applied to the fare when alighting, even if the user uses a different route for transfers or other reasons. [Means for solving the problem]

[0007] To solve the above-mentioned problems, the present invention provides a fare touch payment system comprising a touch payment terminal device for settling transportation fares with a credit card, a higher-level control device for settling the said fares, and a card payment processing server for processing credit card payments, all of which are interconnected in a manner that allows for mutual communication, 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 an authentication request means for transmitting the card information, the generated local token, and the transportation usage information to the card payment processing server to request authentication of the credit card, and the card payment processing server comprises a database for recording the usage information in association with the local token, and a transfer information transmission means for transmitting transfer information based on the usage information recorded in the database to the higher-level control device in association with the local token, thereby providing a fare touch payment system.

[0008] The fare contactless payment system preferably includes a usage history table in which the higher-level control device records the transfer information transmitted from the card payment processing server in association with the local token.

[0009] Furthermore, it is preferable that the fare contactless payment system includes at least the most recent disembarkation information associated with the local token as part of the transfer information.

[0010] Furthermore, the present invention relates to a fare card payment method in a fare touch payment system in which a touch payment terminal device for settling transportation fares by credit card, a higher-level control device for settling the said fares, and a card payment processing server for acting as an agent for credit card payments are interconnected in a manner that enables communication between them, wherein when a user boards, the touch 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; and the touch payment terminal device transmits the read card information, the generated local token, and the boarding information to the card payment processing server. The fare contactless payment method includes the steps of: a card payment processing server transmitting transfer information based on the user's usage information recorded in the database to a higher-level control device in association with the local token; when the user alights, the contactless 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 recording the user's alighting information in the usage history table in association with the boarding information corresponding to the received local token; and calculating the fare for the section used by the user based on the boarding information and alighting information recorded in the usage history table, and converting it to a discounted fare based on the transfer information transmitted from the card payment processing server.

[0011] Furthermore, it is preferable that the fare contactless payment method includes at least the most recent disembarkation information associated with the local token as part of the transfer information. [Effects of the Invention]

[0012] According to the present invention, a touch payment terminal generates a local token based on the card information of the touched credit card, and a card payment processing server transmits transfer information (most recent disembarkation information) associated with that local token to a higher-level control device. As a result, the higher-level control device can apply a discounted fare based on the transfer information even if the user uses a different route for transfers or other reasons. [Brief explanation of the drawing]

[0013] [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 credit card contactless payment process 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]

[0014] The following describes a specific implementation of a fare payment system for route buses (public transport buses) using the Account Based Ticketing (ABT) method, using a contactless payment system with a credit card 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, usage information is linked to ID information that identifies the user (e.g., a credit card or a QR code) and managed on a server in the cloud. It should be noted that the basic configuration of the present invention described below is not limited to route buses, but can also be applied to other means of transportation that employ the ABT method (e.g., railways).

[0015] <Configuration of Fare Touch Payment System 10> FIG. 1 is a conceptual diagram for explaining the configuration of a fare touch payment system 10 according to the present embodiment, which targets route buses (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.

[0016] 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 communicably 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 usage fares.

[0017] Further, 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 usage fares for each bus B on a cloud.

[0018] Each of the aforementioned elements / devices constituting the fare touch payment system 10 according to the present embodiment will be described more specifically below.

[0019] <<Touch Payment Terminal Device 12>> First, the touch payment terminal device 12 will be described. The touch payment terminal device 12 is installed, for example, near the entrance / exit of a bus B. Further, the touch payment terminal device 12 may be provided by being integrally incorporated together with a host control device 13 in a fare box or the like of the bus B. Alternatively, the touch payment terminal device 12 may be connected to a position separated from the host control device 13 via a communication cable. Further, when there are two entrances / exits at the front part and the center part of the bus B, two (or more) touch payment terminal devices 12 for boarding and alighting may be installed at each entrance / exit. In that case, each touch payment terminal device 12 is connected to one host control device 13. For such a communication connection between the touch payment terminal device 12 and the host control device 13, a serial or parallel bus system, or an in-vehicle network such as CAN (Controller Area Network) can be used.

[0020] The touch payment terminal device 12 is connected to a card payment proxy server 14 via mobile data communication. For this purpose, an in-vehicle system 11 of the bus B includes a wireless communication module 111 for connecting to a mobile line. The wireless communication module 111 may be incorporated in the touch payment terminal device 12. Further, the wireless communication module 111 may be incorporated in the host control device 13. When the touch payment terminal device 12 and the host control device 13 share one wireless communication module 111, the wireless communication module 111 may have a router function.

[0021] 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 a credit card C, a cache memory 122, a data storage 123, and an input / output interface 125 for performing input / output control of data between the terminal and other devices.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] <<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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] <<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.

[0041] Furthermore, the fare management server 16 may also process the settlement of 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.

[0042] 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.

[0043] <<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.

[0044] 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, a negative list update means 406, and a transfer information transmission means 407, each of which is implemented through computational processing.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] The transfer information transmission means 407 is a processing means that transmits transfer information based on usage history information recorded in the transaction data 410 of the transaction database 141 to the higher-level control device 13 in association with a local token. The transfer information includes at least the most recent disembarkation information associated with the local token.

[0052] <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.

[0053] 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.

[0054] 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).

[0055] 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.

[0056] 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).

[0057] 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).

[0058] 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").

[0059] 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).

[0060] 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.

[0061] 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.

[0062] 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).

[0063] 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).

[0064] 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.

[0065] Meanwhile, in the card payment processing server 14, the transfer information transmission means 407 searches the transaction data 410 and transmits the user's transfer information, which is associated with the local token, to the higher-level control device 13 in association with the local token (step S141). In this embodiment, the transfer information includes previous disembarkation information, which includes the bus stop where the user most recently disembarked and the date and time of disembarkation.

[0066] Then, the usage history recording means 302 of the higher-level control device 13 records the transfer information associated with the local token as a discount condition in the usage history table 137 (step S142). Figure 4(c) shows an example of the usage history table 137 in which the local token, payment token, boarding information, and previous disembarking information as transfer information are recorded.

[0067] 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.

[0068] 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).

[0069] 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).

[0070] 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).

[0071] 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(d) shows an example of the usage history table 137 in which the local token, payment token, boarding information, boarding information, and previous disembarkation information as transfer 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.

[0072] 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).

[0073] Next, the fare settlement means 303 calculates 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). Furthermore, if a discount condition (transfer information, i.e., the most recent alighting information) is set in the usage history table 137 in step S142 when boarding, the fare settlement means 303 can also convert the calculated fare to a discounted fare based on that transfer information (most recent alighting information).

[0074] Alternatively, the fare settlement and the processing of credit card advance payments to the card payment processing server 14 described later may be handled centrally 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 Means 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 407 Transfer Information Transmission Method 410 Transaction Data 411 Negative List 601 Sales Data

Claims

1. A fare contactless payment system comprising a contactless payment terminal for paying transportation fares by credit card, a higher-level control unit for settling the said fares, and a card payment processing server for processing credit card payments, all of which are interconnected and can communicate with each other, 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, Authentication request means that transmits the card information, the generated local token, and the transportation usage information to the card payment processing server to request authentication of the credit card. Equipped with, The aforementioned card payment processing server, A database that records the aforementioned usage information in association with the aforementioned local token, A transfer information transmission means that transmits transfer information based on the usage information recorded in the database to the higher-level control device in association with the local token. A contactless payment system for fares.

2. The fare touch payment system according to claim 1, wherein the higher-level control device includes a usage history table that records the transfer information transmitted from the card payment processing server in association with the local token.

3. The fare contactless payment system according to claim 1 or 2, wherein the transfer information includes at least the most recent disembarkation information associated with the local token.

4. A fare card payment method in a fare contact payment system in which a contact payment terminal device for paying transportation fares by credit card, a higher-level control device for settling the said fares, and a card payment processing server for handling credit card payments are interconnected in a manner that enables communication between them, When a passenger boards, 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 read card information, the generated local token, and the ride information to the card payment processing server. The card payment processing server transmits transfer information based on the user's usage information recorded in the database to the higher-level control unit, associating it with the local token. When passengers disembark, 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; The steps include: calculating the fare for the section used by the user based on the boarding information and alighting information recorded in the usage history table, and converting it to a discounted fare based on the transfer information transmitted from the card payment processing server; Includes contactless payment methods for fares.

5. The fare payment method according to claim 4, wherein the transfer information includes at least the most recent disembarkation information associated with the local token.

Images