TWI894802B - Backend clearing and settlement system for electronic ticket card benefits and method thereof - Google Patents

Abstract

Provided is a backend clearing and settlement system for electronic ticket card benefits, including a clearing module and a settlement module. The clearing module receives transaction information from frontend card-reading apparatus and generates financial transaction files based on the transaction information. The settlement module receives financial transaction files from the clearing module and manages a ticketing fund pool according to the financial transaction files. The settlement module’s management of the ticketing fund pool includes: in response to a refund request from an intermediary apparatus, the settlement module transfers refund amounts from the ticketing fund pool to the electronic wallet of the electronic ticket card through the intermediary apparatus; and/or the settlement module transfers refund amounts from the ticketing fund pool to a specified account.

Description

Electronic ticket card discount backend clearing system and method

The present invention relates to a clearing and settlement mechanism for electronic ticket cards, and more particularly to a backend settlement system and method for electronic ticket card discounts.

An e-ticket is a chip, card, voucher, or other form of debt that stores monetary value electronically, magnetically, or optically and incorporates data storage or computing capabilities. It serves as a versatile payment tool. Due to its portability and ease of use, e-tickets have gained widespread acceptance and adoption, replacing traditional cash-based transactions. Today, e-ticket usage is no longer limited to specific modes of transportation. For example, e-tickets can be found on public transportation such as the MRT, high-speed rail, trains, buses, and coaches; in public spaces such as parking lots, hospitals, libraries, and gas stations; at tourist attractions such as zoos, amusement parks, and scenic spots; and even in convenience stores, supermarkets, and retail establishments.

In response to market demand, e-tickets are often combined with various discount packages, such as regular passes (e.g., weekly, monthly, and season passes), as well as packages that span regions, lifestyles, industries (e.g., train to bus), and even venues (e.g., transportation combined with access to tourist attractions or participating merchants). These packages typically offer more attractive price discounts than simply adding up the unit prices, catering to the diverse needs of different consumers. Furthermore, consumers only need to pay once for the e-ticket; subsequent use within the specified usage period (e.g., restrictions on time, region, or venue) is free of charge.

To support these preferential policies, the front-line card reader used by consumers to interact with the cardholders must be able to identify whether the electronic ticket card used by the consumer is one of the aforementioned preferential tickets, in order to determine whether to debit the electronic wallet stored on the electronic ticket card. More specifically, if the electronic ticket card is one of the aforementioned preferential tickets, the front-line card reader will not debit the electronic wallet stored on the electronic ticket card, as the consumer has already paid the relevant fees in advance. Conversely, if the electronic ticket card is not one of the aforementioned preferential tickets, the front-line card reader will debit the electronic wallet stored on the electronic ticket card according to the standard operating procedures for general ticket types. To implement these diverse preferential schemes, especially those encompassing multiple regions, industries, and even locations, a large number of diverse front-end card readers must be adapted to accurately identify the discounted tickets. However, this approach would be prohibitively expensive and pose a significant technical challenge.

In view of the above technical challenges, we provide a backend clearing system and method for electronic ticket card discounts.

One embodiment of the present disclosure provides a backend clearing system for electronic ticket discounts, comprising a clearing module and a settlement module. The clearing module receives multiple transaction records from a front-end card reader and generates a payment flow file based on this transaction information. Each transaction contains an electronic ticket identification code and the corresponding transaction amount. The payment flow file records the electronic ticket identification code and the corresponding refund amount. The settlement module receives the payment flow file from the clearing module and manages the ticket fund pool based on the payment flow file. The settlement module manages the ticketing fund pool, including: responding to a refund request from an intermediary device, transferring the refund amount from the ticketing fund pool to the electronic wallet of the e-ticket card through the intermediary device, where the refund request includes the e-ticket card's identification code; and/or transferring the refund amount from the ticketing fund pool to a designated account.

In one embodiment, each transaction information is generated by a front-end card reader in response to a transaction event, in which the front-end card reader deducts the transaction amount from the electronic wallet of the electronic ticket card.

In one embodiment, the clearing module further selectively sums the transaction amounts corresponding to the electronic ticket identification codes in the transaction information based on a set of specified rules to calculate the refund amount. In a further embodiment, the set of specified rules includes regional restrictions and time restrictions.

In one embodiment, the payment file further records the receivables of multiple operators. The settlement module further allocates funds from the ticketing fund pool to these operators based on the receivables recorded in the payment file.

In one embodiment, the intermediary device is an interactive kiosk or a mobile device running an electronic payment application.

In one embodiment, the clearing module further receives transaction information from various front-end card reading devices, including ticket gates, mobile ticket machines, station customer service ticket machines, and/or dongle readers.

One embodiment of the present disclosure further provides a method for clearing electronic ticket benefits, implemented by a backend computer system. The method includes: receiving multiple transaction information from a front-end card reader; generating a payment flow file based on the transaction information; and managing a ticket fund pool based on the payment flow file. Furthermore, managing the ticket fund pool based on the payment flow file includes: responding to a refund request from an intermediary device, transferring a refund amount from the ticket fund pool to the electronic wallet of the electronic ticket through the intermediary device; and/or transferring the refund amount from the ticket fund pool to a designated account.

10: Backend Clearing System

11: Clearing Module

12: Settlement Module

13: Front desk card reader

14: Intermediary equipment

101: Trading Information

102: Electronic Ticket Card

103: Identification code

104: Transaction Amount

105: Financial Files

106: Refund Amount

107: Ticket Fund Pool

108: Return Request

120: Electronic Wallet

130:Specify account

201: Ticket sales revenue

202: Subsidy

203: Accounts receivable

204: Total refund amount

205: Other costs

M30: Methods

S31-S33: Steps

O331, O332: Operation

The contents of this disclosure can be more clearly understood by reading the following description of exemplary embodiments in conjunction with the accompanying drawings. Furthermore, it should be understood that the execution order of the blocks in the flowcharts of this disclosure may be changed, and/or certain blocks may be changed, deleted, or combined.

Figure 1 is a system architecture diagram of a backend clearing system according to one embodiment of the present disclosure.

Figure 2 is a schematic diagram illustrating the income and expenditure of an exemplary ticket fund pool according to one embodiment of the present disclosure.

Figure 3 is a flow chart illustrating a method for clearing electronic ticket card benefits according to one embodiment of the present disclosure.

The following description lists various embodiments of the present invention and is not intended to limit the scope of the present invention. The actual scope of the invention is defined by the scope of the patent application.

In the various embodiments listed below, the same reference numerals will be used to represent the same or similar elements or components.

Serial numbers in this specification and the patent applications, such as "first," "second," etc., are for convenience only and do not have a sequential order.

The following descriptions of device or system embodiments also apply to method embodiments, and vice versa.

Figure 1 illustrates a system architecture diagram of a backend clearing system 10 according to one embodiment of the present disclosure. As shown in Figure 1, the backend clearing system 10 may include a clearing module 11 and a settlement module 12.

The backend clearing system 10 may include one or more computer devices with computing capabilities, such as personal computers (e.g., desktop computers or laptops), server computers, and/or mobile devices such as tablet computers and smart phones, but the present disclosure is not limited thereto. Each computer device includes a processing unit and a storage unit, although not shown in the figure. The processing unit may include any one or more general-purpose or special-purpose processors for executing instructions, such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a controller, a microcontroller, a state machine, and/or a combination thereof, but the present disclosure is not limited thereto. The processing unit may further include volatile memory, such as random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and/or combinations thereof, but the present disclosure is not limited thereto. The storage unit may be any device including non-volatile memory (such as read-only memory, electrically erasable programmable read-only memory (EEPROM), flash memory, or non-volatile random access memory (NVRAM)), such as a hard drive (HDD), a solid-state drive (SSD), or an optical disk, but the present disclosure is not limited thereto. The storage unit stores a program corresponding to a method for clearing electronic ticket discounts. When the processing unit loads the program from the storage unit, it executes the corresponding instructions of the clearing module 11 and the settlement module 12, thereby implementing the functions of the clearing module 11 and the settlement module 12. The clearing module 11 and the settlement module 12 can be implemented by the same computer device or by different but interconnected computer devices; this disclosure is not limited to this.

Generally speaking, the clearing module 11 receives multiple transaction information 101 from the front-end card reader 13 and generates a payment flow file 105 based on this transaction information 101. The settlement module 12 receives the payment flow file 105 from the clearing module 11 and manages the ticket fund pool 107 based on the payment flow file 105. The settlement module's management of the ticket fund pool may include one or both of the following methods. First, in response to a refund request 108 from the intermediary device 14, the settlement module 12 transfers the refund amount 106 from the ticket fund pool 107 to the electronic wallet 120 of the electronic ticket card 102 through the intermediary device 14. Second, the settlement module 12 transfers the refund amount 106 from the ticket fund pool 107 to a designated account 130.

Each transaction information 101 described above includes an identification code (ID) 103 of an electronic ticket card 102 and a corresponding transaction amount 104. This indicates that, in a transaction event corresponding to this transaction information 101, the consumer used the electronic ticket card 102 to make a purchase (e.g., take a subway ride) for an amount equal to the transaction amount 104 (e.g., NT$40). The electronic ticket card 102 is a chip, card, voucher, or other form of debt that stores monetary value electronically, magnetically, or optically and has data storage or computing capabilities. It serves as a multi-purpose payment tool. The electronic ticket card 102 can be considered a carrier for an electronic wallet 120. Its physical form can be, for example, a physical card, or a mobile device or wearable device running an electronic payment application (APP), but this disclosure is not limited to this.

The front-end card reader 13 is a device used to read, identify, and process electronic ticket information. Such devices, such as ticket gates, mobile ticket machines, station customer service ticket machines, or dongle readers, can be used in public transportation, commercial facilities, tourist attractions, and other venues to provide convenient payment and access control services. The front-end card reader 13 typically uses short-range wireless communication technologies, such as Near Field Communication (NFC) or Radio-Frequency Identification (RFID), to achieve contactless ticket reading. Consumers simply hold their electronic ticket 102 close to the front-end card reader 13 to complete the transaction.

The payment file 105 is used to record the amount payable to each participant in the e-ticket discount program. Participants may include consumers, businesses (such as transportation operators, partners, and authorized merchants), and/or e-ticket issuers, but this disclosure is not limited to this. The refund amount 106 refers to the amount payable/refunded to consumers. Therefore, the content recorded in the payment file 105 includes the identification code 103 of the e-ticket 102 and the corresponding refund amount 106. It should be understood that although Figure 1 only shows the identification code 103 and the refund amount 106 as an example, the content recorded in the payment file 105 may include the identification codes of multiple e-tickets and their corresponding refund amounts.

The aforementioned ticket pool 107 is a mechanism specifically designed to centrally manage funds related to electronic ticket card discounts. Please refer to Figure 2, which is a schematic diagram illustrating the income and expenditure of the ticket pool 107 according to an embodiment of the present disclosure. As shown in Figure 2, the income of the ticket pool 107 may include ticket sales revenue 201 and subsidies 202 from discount tickets (including commuter tickets and discount packages). The expenditures may include accounts receivable 203 from operators (such as transportation operators, cooperative units, or authorized merchants), the total refund amount to be returned to consumers 204, and other costs 205, such as transaction costs and management costs. Subsidies 202 contribute to the ticketing fund 107 because the amount accumulated from actual consumer spending often exceeds the cost of commuter passes and discount packages. For example, a consumer purchases a commuter pass for NT$1,200, generating NT$1,200 in ticket sales revenue 201. However, if actual travel during the commuter pass period equates to NT$1,800 in fares, the excess NT$600 must be covered by subsidies 202. In one embodiment, the clearing module 11 further generates a subsidy report based on the transaction information 101 and sends the subsidy report to the subsidizing unit providing the subsidy 202, such as, but not limited to, a central or local government agency, or a sponsor of a preferential activity, via a specific channel, such as, but not limited to, email, application program interface (API), file transfer protocol (FTP), or electronic data interchange (EDI).

The intermediary device 14 can be an interactive kiosk, such as FamilyMart's FamiPort, UP Corporation's ibon, or Hi-Life's Life-ET, but this disclosure is not limited thereto. Alternatively, the intermediary device 14 can be a mobile device running an electronic payment application (APP). When a consumer performs specific operations on the user interface of the intermediary device 14 and holds the electronic ticket card 102 close to the intermediary device 14, the intermediary device can read the identification code 103 of the electronic ticket card 102 through a short-range wireless communication technology, such as Near Field Communication (NFC), Radio Frequency Identification (RFID), Bluetooth, or Wi-Fi Direct, and trigger a return request 108. The refund request 108 includes the identification code 103 of the electronic ticket card 102, allowing the settlement module 12 to determine the corresponding refund amount 106 based on the identification code 103. The settlement module 12 can then transfer the refund amount 106 from the ticket fund pool 107 to the electronic wallet 120 of the electronic ticket card 102 through the intermediary device 14.

The designated account 130 may be a fund or financial account designated by the consumer (who is also the holder of the electronic ticket card 102) or linked to the electronic ticket card 102, such as but not limited to a savings account, electronic payment account, debit card account, or credit card account.

In one embodiment, each transaction information 101 is generated by a front-end card reader 13 in response to a transaction event. During this transaction event, the front-end card reader 13 deducts the transaction amount 104 from the electronic wallet 120 of the electronic ticket card 102. For example, when a consumer uses an electronic ticket card 102 to ride the metro, the exit gate (i.e., the front-end card reader 13) deducts the transaction amount 104 (e.g., NT$40) from the electronic wallet 120 of the electronic ticket card 102, regardless of whether the electronic ticket card 102 is a discounted ticket. In other words, the front-end card reader 13 does not need to identify whether the electronic ticket card 102 is a discounted ticket; it simply performs a normal deduction operation. This transaction amount 104 will be included in the clearing and settlement process of the backend clearing system 10 and will ultimately be returned to the consumer. Therefore, consumers do not need to worry about being charged twice.

In one embodiment, the clearing module 11 further calculates the refund amount by selectively summing the transaction amounts (including but not limited to the transaction amount 104) corresponding to the identification code 103 of the electronic ticket card 102 in the transaction information 101 based on a set of specified rules. The set of specified rules may include regional restrictions (e.g., limited to Taipei City and New Taipei City), time restrictions (e.g., a one-month period from activation), business restrictions (e.g., designated participating merchants), and/or any combination thereof, but this disclosure is not limited thereto. For example, a consumer purchases a commuter pass for NT$1,200 and accumulates a total of NT$1,800 in actual rides during the pass period. Of this NT$1,800, NT$1,400 meets the aforementioned criteria. This NT$1,400 will be used as a refund amount 106 and ultimately returned to the consumer's electronic wallet 120 or designated account 130.

In one embodiment, payment file 105 further records the receivables of multiple operators (e.g., transportation operators, partners, or franchised merchants), for example, Operator A is owed NT$1 million, Operator B is owed NT$1.2 million, and so on. Furthermore, settlement module 12 allocates funds from ticketing fund pool 107 to these operators based on the receivables recorded in payment file 105.

Figure 3 is a flow chart illustrating a method M30 for clearing electronic ticket card benefits according to one embodiment of the present disclosure. As shown in Figure 3, method M30 may include steps S31 and S32. Steps S31 and S32 are performed by the clearing module 11 of the backend clearing system 10, while step S33 is performed by the settlement module 12 of the backend clearing system 10.

In step S31, multiple transaction information items 101 are received from the front-end card reader 13. Each transaction information item 101 includes an electronic ticket identification code and a corresponding transaction amount, such as the identification code 103 of electronic ticket 102 and the corresponding transaction amount 104.

In step S32, a payment flow file 105 is generated based on the transaction information 101. The payment flow file records the identification codes of multiple electronic ticket cards and their corresponding refund amounts, for example, including the identification code 103 of the electronic ticket card 102 and the corresponding refund amount 106.

In step S33, the ticket fund pool 107 is managed based on the payment flow file 105. Furthermore, step S33 may further include operation O331 and/or operation O332. Operation O331 includes transferring the refund amount 106 from the ticket fund pool 107 to the electronic wallet 120 of the electronic ticket card 102 via the intermediary device 14 in response to the refund request 108 from the intermediary device 14. Operation O332 includes transferring the refund amount 106 from the ticket fund pool 107 to the designated account 130.

Because method M30 is executed in the background, it can be implemented without modifying the front-end card reader 13. In other words, method M30 can overcome the limitations of the front-end card reader 13. Therefore, in one embodiment, the clearing module can receive transaction information 101 from a variety of front-end card readers, including ticket gates, mobile ticket machines, station customer service ticket machines, and/or dongle readers.

The above paragraphs describe various aspects. Obviously, the teachings herein can be implemented in a variety of ways, and any specific architecture or functionality disclosed in the examples is merely representative. Based on the teachings herein, those skilled in the art will understand that each aspect disclosed herein can be implemented independently, or two or more aspects can be combined.

Although the present disclosure has been described above with reference to the embodiments, these are not intended to limit the present disclosure. Anyone skilled in the art may make modifications and improvements without departing from the spirit and scope of the present disclosure. Therefore, the scope of protection of the invention shall be determined by the scope of the attached patent application.

10: Backend Clearing System

11: Clearing Module

12: Settlement Module

13: Front desk card reader

14: Intermediary equipment

101: Trading Information

102: Electronic Ticket Card

103: Identification code

104: Transaction Amount

105: Financial Files

106: Refund Amount

107: Ticket Fund Pool

108: Return Request

120: Electronic Wallet

130:Specify account

Claims (12)

A back-end clearing system for electronic ticket card discounts includes: a clearing module that receives multiple transaction information from a front-end card reading device and generates a payment flow file based on the transaction information, wherein each transaction information includes an identification code of an electronic ticket card and a corresponding transaction amount, and the payment flow file records the identification code of the electronic ticket card and the corresponding refund amount; and a settlement module that is connected to the clearing module, receives the payment flow file from the clearing module, and manages a ticket fund pool based on the payment flow file; wherein the settlement module manages the ticket fund pool by: responding to a refund request from an intermediary device, the settlement module receives a refund request from the intermediary device through the intermediary device; The ticketing fund pool transfers the refund amount to an electronic wallet of the electronic ticket card, wherein the refund request includes the identification code of the electronic ticket card; and/or the settlement module transfers the refund amount from the ticketing fund pool to a designated account; wherein the clearing module further selectively sums up the transaction amounts corresponding to the identification code of the electronic ticket card in the transaction information based on a set of specified rules to calculate the refund amount; and wherein the clearing module further receives the transaction information from multiple front-end card reading devices, wherein the front-end card reading devices include a ticket gate, a mobile ticket validator, a station customer service ticket validator, and/or a dongle reader. The system as described in claim 1, wherein each transaction information is generated by the front-end card reading device in response to a transaction event, in which the front-end card reading device deducts the transaction amount from the electronic wallet of the electronic ticket card. The system of claim 1, wherein the set of specified rules includes a region restriction and a time restriction. The system as described in claim 1, wherein the cash flow file further records a receivable item for each of multiple operators; and wherein the settlement module further allocates funds from the ticket fund pool to the operators based on the receivable items recorded in the cash flow file. The system as described in claim 1, wherein the revenue of the ticket fund pool includes ticket sales revenue and subsidy funds. The system of claim 1, wherein the intermediary device is an interactive kiosk or a mobile device running an electronic payment application. A method for clearing electronic ticket benefits is implemented by a back-end computer system. The method includes: receiving a plurality of transaction information from a plurality of front-end card reading devices, wherein each transaction information includes an identification code of an electronic ticket and a corresponding transaction amount, wherein the front-end card reading devices include a ticket gate, a mobile ticket machine, a station customer service ticket machine, and/or a dongle reader. reader); generating a payment flow file based on the transaction information, wherein the payment flow file records the identification code of the electronic ticket card and a corresponding refund amount; and managing a ticket fund pool according to the payment flow file; wherein managing the ticket fund pool according to the payment flow file includes: responding to a refund request from an intermediary device, transferring the refund amount from the ticket fund pool to the intermediary device through the intermediary device An electronic wallet of the electronic ticket card, wherein the refund request includes the identification code of the electronic ticket card; and/or transfers the refund amount from the ticket fund pool to a designated account; wherein generating the payment flow file based on the transaction information further includes: based on a set of specified rules, selectively summing the transaction amounts corresponding to the identification code of the electronic ticket card in the transaction information to calculate the refund amount. The method as described in claim 7, wherein each transaction information is generated by the front-end card reading device in response to a transaction event, in which the front-end card reading device deducts the transaction amount from the electronic wallet of the electronic ticket card. The method of claim 7, wherein the set of specified rules includes a regional restriction and a time restriction. The method as described in claim 7, wherein the cash flow file further records a receivable item for each of multiple operators; and wherein managing the ticket fund pool based on the cash flow file further includes: allocating funds from the ticket fund pool to the operators based on the receivable items recorded in the cash flow file. The method of claim 7, wherein the revenue from the ticketing fund pool includes ticket sales revenue and subsidies. The method of claim 7, wherein the intermediary device is an interactive kiosk or a mobile device running an electronic payment application.