WO2007095372A2

WO2007095372A2 - System and method for collection and processing of transit fares

Info

Publication number: WO2007095372A2
Application number: PCT/US2007/004149
Authority: WO
Inventors: Robert Gerard Taylor; Mark James Messenger; Michael Charles Nash; Kurt Louis Elste; Michael Laezza
Original assignee: Erg R & D Pty Ltd.
Priority date: 2006-02-14
Filing date: 2007-02-14
Publication date: 2007-08-23
Also published as: EP2033134A2; EP2033134A4; WO2007095372A3

Abstract

The present invention is a system and method for collecting and processing patron data or tokens which concentrates the systems business intelligence in the processing of the patron data or tokens at a central computer and not at the location of the collection of the patron data or tokens.

Description

SYSTEM AND METHOD FOR

COLLECTION AND PROCESSING OF TRANSIT FARES

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims the benefit of priority of U.S. Provisional

Patent Application Serial No. 60/773,305 filed February 14, 2006 entitled "System and Method for the Collection and Processing of Transit Fares".

FIELD OF THE INVENTION

The invention relates generally to a system and method for a new system of electronic fare collection within a transit environment and a system and method which can be extended to other areas of electronic commerce.

BACKGROUND OF THE INVENTION

Transit systems have developed over many decades from manual systems into highly engineered electronic systems. Transit systems in the prior art contain a wide variety of components typically linked in such a manner that as a transit patron passes through an entry point, the patron touch point devices (PTPDs), the fare must be determined and collected. In prior art electronic systems, either via contact systems or contactless systems, the patron presented a token to the fare collection system. At the point of entry or exit, the prior art systems used a fare rules matrix that was distributed to them by a central system to determine whether the presented token was valid and sufficient to pay the necessary fare. The distributed implementation of the business rules (fare rules matrix) also meant that PTPDs would often need adaptations to meet the requirements of tokens of multiple manufacturers which may be presented.

In prior art electronic fare payment systems, the business intelligence of the fare engine was distributed to the PTPDs. Complex rule sets are loaded into the backend system's fare engine (central computer) and after a lengthy computational period the different fare permutations or fare rules matrix are created. The fare rules matrix is output for loading into specific PTPDs in the system. Problems were invariably encountered in condensing the rules to a sufficient extent which would allow the rules to be loaded into the memory of the PTPDs. The fare rales matrix comprises a considerable volume of data which must to be sent via the telecommunications links to the PTPDs. There was always a considerable time lag between the input of a new or varied rule set and the time that that rale set could be converted into operational fare rales matrix. When generating a new set of fare rales, typically a test distribution through a specific test facility would have to be performed to ensure that all devices function properly with the new fare rales matrix and that the fare rules matrix produced appropriate and valid results. The cycle period for implementing business rale updates was long and was not flexible enough to align with the business needs for fast changes and updates. In the prior art systems, there was a need to limit the complexity and the allowable set of business rales would often need to be constrained to a subset of what a business would really like to have implemented.

Transactions calculated at the PTPDs would be transmitted to the backend where they would need to be reprocessed against a matching set of business rules. Each transaction would thus be effectively calculated more than once and historical sets of rales would have to be maintained for occasions where the transaction date and that of the current rale set did not match. The prior art distributed implementation of the business rales also resulted in devices would often need adaptations to meet the requirements of a particular PTPD manufacturer or token provider.

SUMMARY OF THE INVENTION

The present invention is a system and method for collecting and processing patron credentials which concentrates the systems business intelligence in the processing of the data at a location other than the point of collection of the credentials. The patron touch points within the present invention are sensors that provide preliminary validation of credentials and convey data to the backend processor. A business rules/fare engine processor at the central processor will provide near real-time information on the validity of a presented credentials by providing in-transit visibility and validation of patrons' credentials to purchase the service or goods. Among the benefits of the new system would be significantly reduced operational and deployment costs and an improved experience for the patrons. The system will allow for simpler patron touch point devices which will reduce the capital costs of the system as well as associated maintenance costs. In some implementations of the present invention there will be a marked reduction in the operating costs of payment token issuance. Patron tokens include, but are not limited to, credit cards, debit cards, pre-paid card, Smart Cards, cell phones and employee cards. For example, tokens already in use in a prior art system may simply join the system and the technical barriers for entry of multiple card issuers is reduced.

The examples presented in this document mainly will refer to operations in a public transit system, however this system could be extended to the purchase of other fixed or variable cost items or services, at stationary or mobile points of sale and the system could have similar results without operating in near real-time.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is block diagram showing the major components of the system of the present invention. DETAILED DESCRIPTION

The main principle of the present invention's operation is that its business intelligence is concentrated in the backend processing. The business intelligence includes such actions as the validation of data, translation of currency, pricing methodologies, etc. The touch points for the system (essentially data collection devices) may be simply sensors that provide preliminary validation of payment tokens and convey transactional data to the backend intelligence. A business rules/fare engine located at the backend of the system provides near realtime information on the validity of a presented transaction by providing in-transit visibility and validation of patrons' credentials to purchase the service or goods. The examples presented in this document refer mainly to operations in a public transit system, however this system is applicable to the purchase of other fixed or variable cost items or services, at stationary or mobile points of sale. When 'fare engine' and 'fare rules' are discussed the same terms should also be taken to refer to any business rules engine or business rules that are employed to calculate the cost of goods or services.

In the preferred embodiment the system of centralised business intelligence processing allows the fare engine to be located at the backend where large processing power is available and all transactions will effectively be done in near real-time against the current rule set. In one embodiment of the present invention the front end to the business rules engine does not require programming expertise; business analysts can add new rules through a simplified graphical user interface. The system will allow for business rules of arbitrary complexity. Rules changes can be rapidly entered into the system and those changes will not impact on the PTPDs. No remote device testing will be needed in the deployment cycle. Analysis can be performed with historical data resident in the central processor in order to gauge the impact of changes on business operations and revenues. Changes in rules over time can be tracked and analysed. Historical data can be run through the current rules engine. In some embodiments the rules are implemented with a limited lifespan to enable such events as a fare sale. In some embodiments the business rules engine will exist as a component within a Service Oriented Architecture environment, as part of the middleware. As such it can either be applied in a standalone manner as part of the single focus business enterprise (e.g. transit fare system) with its own backend processing or as a plug-in component of a another system (e.g. as a transit fare engine component that focuses on that business alone whilst being incorporated into a larger overall business system - as could happen when partnering with a telecommunications company; its backend billing system being also used to handle transit transactions from payment tokens incorporated in mobile phones.)

The system may be deployed as a standalone entity or as a stand-beside feature to another operating entity (electronic payment system). A stand-beside deployment will add functionality to a pre-existing system, allowing for the easy adoption of new and more varied payment token methods with accompanying, flexible business rules processing.

In one implementation of the present invention, sensors, remote from the central processing system, either mobile or stationary, will be the point of contact for the payment tokens presented by patrons. In this implementation, the system allows multiple types of payment tokens such as IOS/IEC 14443 contactless smartcard and ISO 15693 RFID tags or other proprietary tokens.

Electronic tokens are presented to the touch points or payment devices. These devices will interpret the tokens. In some embodiments, the touch point or payment device will determine that the token is valid i.e. from an authorised issuer and then scan the local Hot List to determine whether the token that has been presented is not valid within the system. The Hot List may be created locally by accumulating a list of tokens which are rejected by the token or card issuer or may be downloaded from the card issuer. The Hot List is downloaded from the backend processing system. Invalid tokens will result in an alarm and, where gates enclose the system, the gates will remain closed. The credentials from a non-Hot Listed token will be transmitted to the backend system along with the time and location of their use. The backend system will check to see whether the token is already known to the system. If it is a new token, the backend system will check its validity with the issuer. Depending on the implementation, the backend may determine whether any financial limits will be exceeded by the transaction. Alarms relating to the attempted invalid use of a token will also be sent to the backend processor. Invalid tokens will be added to the Hot List.

The transaction details transmitted to the backend system are similar to Call Data Records (CDR) in a telecommunications system e.g. token identity, a timestamp and location of its use and the service or goods obtained and any transition to another service - the backend processing would accumulate CDRs related to an overall event usage (e.g. multiple rides entailing transport vehicle transfers) to construct the overall transaction and the apply appropriate business rules to apply to the CDR, for example, determining the cost. The data structures on the payment tokens (e.g. contactless smartcards or RFID tags) used in prior art systems that were dedicated to the transit operations (or for any other particular line of business) can be set to nil in the present invention. This results in reduced transaction processing time, better system utilization and patron throughput is significantly increased.

An important aspect of the present invention is that the token can be securely linked to an identifiable billing account e.g. an RFID tag in a mobile phone could be linked via the phone's SIM card to a patron's account with a partnering telecommunications company. In the event that the participants make minimal updates on tokens, the processing time for transactions will still be significantly reduced compared to prior art systems. In the preferred embodiment the initial validity checks and transaction processing associated with any payment token usage will be completed in the central computer (i.e. the back end system) while the patron is in transit. If the presented token is determined to be invalid, the backend system will notify the change to be added to a Hot List. In the preferred embodiment this will be done before the patron attempts to exit the system. If the transit journey was of a short duration then under some circumstances it may occur that the invalid payment token could only be added to the Hot List in time to block the next usage attempt thereby minimising the opportunities for fraud.

In some embodiments the PTPD will itself contain the data structures and a processing engine that will do the lookup of tokens acceptable for use within the system. In other embodiments, the PTPD will be little more than card reader and will be linked via a communications channel to the local processor.

The local processor in the PTPD in this embodiment has connections to its remote card readers. Those connections could be over a wireless or wired communications channel. In the preferred embodiment, a low latency network is an important consideration, so as to not unduly extend the processing period for the presented payment token. USB or USB over wireless (utilising Ultra Wide Band) are two possibilities for such communications links.

In embodiments at fixed locations such as a railway station, wired communications are the most likely type that would be employed. The difference in this case would be that the PTPD would conduct its own communications with the backend.

In some embodiments a small amount of data buffering will take place for transactions to be sent to the backend. This will allow the communications link usage to be optimised. In some embodiments, the Hot List updates could be accomplished via broadcasts over communications links that been had optimised for unidirectional transport (e.g. conforming to RFC 3926, the IETF's (Internet Engineer Task Force) FLUTE (File Delivery over Unidirectional Transport) protocol via the use of forward error correction techniques. Such a technique would obviate the need for a back channel to acknowledge the receipt of the broadcast.

In some embodiments of the present invention, the system will allow for tokens that can be both read from and written to, as well as those tokens that are read only. For embodiments where a token can be written to, a minimal amount of transaction context information (for example, for the current (tag on) and previous journey (tag off)) may be updated on the token. That information may include the transport or selling authority, the location and time of the tag on. That information could be used to aid in the inspection of tokens that have been tagged for the current service and also to re-enforce the terms of payment calculation (e.g. when there is a patron transition between different forms of conveyances).

In other embodiments of mobile devices, such as a driver's console on a bus, a record may be kept of all tokens that are currently in use on the bus. When an inspector boards the bus, token information can be downloaded from the driver's console into an inspection device held by the inspector. A crosscheck can be performed comparing the inspected tokens and those validated for use on the current ride. This means that both updateable and non-updateable tokens can be checked for validity. In embodiments with devices that accept non-updateable tokens (e.g. an RFID tag in a mobile phone) there are alternate means of registering and displaying the last time and location at which the token was tagged. In other embodiments, an application on a mobile phone can keep a record of the number of times the token has been read and display that information upon request.

In the preferred embodiment, the system will be constructed in a modular fashion such that only those components necessary for the operation of system need be purchased and deployed. In some cases the functionality may already exist in an established system or be able to be provided by a third party e.g. via a Web service. An additional feature of the preferred embodiment is that the data transmission system would be integral to a device management module, an adjunct to the business rules engine. Data transmissions will take place over a number of scales of distance within the preferred embodiment. Devices within the system will be online for most of the time and will communicate directly with the backend processing system through the data management module.

Secure communications will be a fundamental aspect of the preferred embodiment. Various encryption techniques may be employed to ensure the privacy and integrity of data transmissions. IPv6 may be used in some embodiments, including Mobile IP for mobile nodes. As the devices may be online in near realtime, they may be likewise be tracked. This will provide an enhanced layer of security and aid in asset management.

When a patron presents a payment token for use within the preferred embodiment, a 'proximity' PTPD device may be employed to read, and optionally update, that token. Contact will not be necessary between the token and the PTPD - reading/writing will be done at a distance over wireless technology including Near Field Communications (NFC - is a secure short-range wireless technology defined by the standards ISO/IEC 18092 and 21481, ECMA 340, 352 and 356 and ETSI TS 102 190) or ISO 14443 and ISO 5693.

In an alternate embodiment, a financial risk module is added to the business rules engine. As an example of this functionality, this module can analyze how the debt is carried and managed when a telecommunications company's payment token is used for the purchase of a ride on the transit system when a pattern of usage would dictate period pass discounting. The risk model can calculate acceptable risk limits for outstanding debt carried by the token owner and the debt for which the issuer might be liable on behalf of another business entity. In another embodiment of the present invention, the operator could accumulate transactions for settlement. In prior art implementations the operator of the system could be expected to pay a fee to credit card companies per transaction based on the number of transactions processed. The system operator incurs a fee whenever it submits a transaction for settlement with a card company. In some embodiments of the present invention, the backend business rules engine and its associated financials modules will be configured to accumulate transactions on credit/debit card issuer payment tokens and to submit those transactions in bulk. The period of accumulation would configurable such that the bulk set was submitted whenever a certain number transactions had been accumulated or a certain time limit had expired or a certain value has been reached. The time limit for submission can be kept short to maintain the near-realtime feature of the embodiment. The bulk submission will result in a reduction of fees paid compared to submissions on an individual transaction basis. The risk module will calculate the number of transactions to be accumulated to ensure the balance of payment is to the operator's advantage and to balance that against the risk of carrying a debt burden for a period before settlement.

The present invention will significantly reduce costs and promote increased patronage through simpler access. The resulting simpler fare payment devices will reduce the capital costs of those items as well as associated maintenance costs. There will be a reduction in the operating costs of payment token issuance (tokens already in use for other means simply join the system) and there is easy entry for multiple issuers. In a Post-bill Model (i.e. a system in which patrons receive bills for services after they are rendered) which uses payment tokens that weren't solely dedicated to a transit operation, the invention will help eliminate many of the capital and operating costs of a Reload Model (i.e. a system in which patrons pay in advance for services and add money to the token to allow it to be reused). If reloads are to continue in a system that allowed the use of pre-paid products then a patron could use their normal banking facilities to accomplish the task (e.g. via the Web).

Readily changeable business rules and associated incentive schemes allow revenue streams to be optimized.

Claims

CLAIMSI claim:

1. A system for collecting and processing fares in a transit system, the system comprising: a central computer; a rules data base on the central computer, a plurality of patron touch point devices; and the plurality of patron touch point devices coupled to the transit central computer, each patron touch point device of the plurality of mass transit devices comprising: a token reader for reading information from the token presented by a patron and transmitting said information from said token to the central computer, wherein the rules data base determines the status of said token information and transmits said status to the said patron touch point device.

2. The system of claim 1, wherein the patron touch point devices contain smartcard readers.

3. The system of claim 1, wherein the rules data base contains a system for accumulating token information from multiple transaction related to the patron's credit card the said accumulated token information being later submitted to the credit card issuing company for processing.

4. The system of claim 1, which includes a graphical user interface to the rules data base for the creation and maintenance of the rules in the rules data base.

5. The system of claim 4, wherein the rules data base is implemented with rules which are effective for a fixed period of time.

6. The system of claim 1, which includes an electronic payment system.

7. The system of claim 1, in which the patron touch point devices are capable of receiving patron data from IOS/IEC 14443 contactless smartcards.

8. The system of claim I, in which the patron touch point devices are capable of receiving patron data from IOS/IEC 14443 contactless smartcards and transmitting data to IOS/IEC 14443 contactless smartcards.

9. The system of claim 1, in which the patron touch point devices determines the token validity based upon a list of invalid tokens downloaded from the central computer.

10. The system of claim 9, in which the list of invalid tokens are transmitted from the central computer to the patron touch point device on an optimized unidirectional transport.

11. The system of claim 1 , in which the patron touch point devices contains a list of invalid tokens previously down loaded from the central computer, said patron touch point device transmits patron token information to the central computer, said central computer determines the token validity and if the token is invalid, said central computer transmits a new list of invalid tokens to the patron touch point devices prior to the patron exiting the transit system.

12. The system of claim 1, in which the patron touch point devices contains a list of invalid tokens previously down loaded from the central computer, said patron touch point device transmits patron token information to the central computer, said central computer determines the token validity and if the token is invalid, said central computer transmits a message to the patron touch point devices in the system to add the patron token information to the list of invalid tokens prior to the patron exiting the transit system.

13. The system of claim 1, in which the patron touch point devices are connected to the central computer by means of a wireless communications network.

14. The system of claim 1, in which the patron touch point devices are connected to the central computer by means of a wired communications network.

15. The system of claim 1, in which the patron touch point devices accumulate patron token data prior to transmitting said token data to the central computer.

16. The system of claim 1, in which the central computer contains a financial risk module.

17. The system of claim 1, in which the central computer accumulates transactions for group submission to the credit provider.