WO2012031218A2

WO2012031218A2 - Point of service non-reversible secure identification and encryption

Info

Publication number: WO2012031218A2
Application number: PCT/US2011/050355
Authority: WO
Inventors: Jeffrey P. Emerson; Michael E. Simanek; Marc Sean Massar
Original assignee: Accenture Global Services Limited; Verifone, Inc.
Priority date: 2010-09-03
Filing date: 2011-09-02
Publication date: 2012-03-08
Also published as: WO2012031218A3

Abstract

A point of service (POS) non-reversible secure identification and encryption system receives a card data for a desired transaction from a user, and immediately generates a non-reversible global unique identifier (GUID) based on the card data in connection with the transaction. The system may also encrypt the card data to be transmitted to an external system. After transmitting the encrypted card data, the system may delete the encrypted card data to be in compliance with the PCI DSS. As a result, the system may provide an efficient and secure way conducting a desired transaction.

Description

Point of Service Non-Reversible Secure Identification and Encryption

CROSS REFERENCE TO RELATED APPLICATION

[001 ] This application claims priority to, and incorporates by reference, U.S. Provisional Application Number 61 /380,056, titled Point of Service Non- Reversible Secure Identification And Encryption, attorney docket number 10022- 1812.

BACKGROUND

Technical Field.

[002] This disclosure relates to generating and securely storing a Globally Unique Identifier ("GUID") at a point-of-sale ("POS"). The GUID preferably may not be easily reversed to reveal the original information from which it was generated.

Related Art.

[003] In mass transit systems, the mass transit operators may provide riders with proprietary passes for quick fare payments when the riders get on the busses or trains. When a rider boards a bus, the rider scans their proprietary pass on a bus card reader and receives a confirmation indicating whether the bus pass is valid or invalid. If the proprietary pass is confirmed to be valid, the rider is allowed to board the bus. When the rider scans the pass across the reader, the reader reads the unique pass ID from the pass and compares the ID against a "negative" list which stores a list of IDs previously determined to be invalid. If there is a match, the ID is determined to be invalid and the rider is denied boarding. This process may take 300 to 400 milliseconds (ms).

[004] Many customers perform financial transactions using transaction cards such as credit cards or debit cards at retail stores. When making a purchase, customers present their bank card to a card reader. The bank card readers read the Primary Account Number (PAN) listed on the bank card. Other associated information such as the name of the card holder, expiration date, and security numbers may be read by the card reader as well. Such information may be encrypted and transmitted to a remote server, usually hosted by a bank card processing company for authorization of the purchase. The remote server decrypts the information received from the card reader and determines whether or not the purchase is authorized. In some situations, the remote server may contact the issuing bank for availability of funds before authorizing the purchase. The remote server responds to the card reader that the purchase is authorized, and the customer may successfully complete the purchase. This process may take from 1 to 3 seconds.

[005] As more people rely on bank cards to meet their daily financial transaction needs, riders and mass transit operators alike feel the need to provide an easy and efficient way to use bank cards for making quick payments when boarding the busses, trains or other mode of transportation. However, conventional bank card transactions may take more than twice as long as compared to the proprietary passes for authorization. Further, conventional card readers raise security concerns when used with bank cards and may not comply with government regulations.

[006] Therefore, a need exists to address the problems noted above and others previously experienced.

SUMMARY

[007] A point of service non-reversible secure identification and encryption system ("system") allows a user to conduct a quick and secure transaction using a card data identifier at a point of service ("POS"). The system may include at a POS a device which receives card data from the user to be used for a transaction. The device may immediately determine a card data identifier (e.g., a globally unique identifier ("GUID")) based on the card data received from the user. The card data identifier may be non-reversible (e.g., the card data identifier may be difficult or impossible to reverse or decipher to obtain the original card data upon which it is based).

[008] In one implementation, the device may have access to a "negative" (or deny or reject) list of card data identifiers, and compare the card data identifier with the negative list. If a matching card data identifier is found in the negative list, the user may be denied transaction or other service that the user is seeking. If no matching card data identifier is found the user may be granted service or the transaction may complete.

[009] The system may further encrypt the card data at the POS, and transmit the encrypted card data and the card data identifier to a fare management system. After transmitting the encrypted card data and the card data identifier to the fare management system, the encrypted card data may be deleted from the POS. The fare management system may determine based on the card data identifier whether an account corresponding to the card data identifier already exists, and what fare should be applied to that transaction for that account. If an account already exists, the encrypted card data and card data identifier may be transmitted to a decryption system, where the encrypted card data is decrypted to obtain the original card data. After transmitting the encrypted card data to an external system such as the decryption system, the encrypted card data may be deleted from the fare management system. The card data may then be sent to an issuing bank for the financial transaction. If the financial transaction is successful, the issuing bank may transmit an authorization response, and the fare management system may update the account accordingly. If the financial transaction is not successful, the fare management system may update the negative list to include the card data identifier of the account for which the financial transaction was not successful.

[010] The card data identifier may also serve as an account identifier, upon which any application at the point of sale may chose to take appropriate action. [011 ] Other systems, methods, features and advantages will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[012] The system may be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like referenced numerals designate corresponding parts throughout the different views.

[013] Figure 1 shows a point of service non-reversible secure identification and encryption system.

[014] Figure 2 shows a flow diagram of a transaction card registration operation of the system of Figure 1 .

[015] Figure 3 shows a flow diagram of an operation of the system of Figure 1 in a "positive" case where a known and registered transaction card is used.

[016] Figure 4 shows a flow diagram of an operation of the system of Figure 1 in a "negative" case.

[017] Figure 5 shows a flow diagram of an operation of the system of Figure 1 in a "positive" case where a new and unknown transaction card is used.

[018] Figure 6 shows a flow diagram of an operation of the system of Figure 1 in a "positive" case where a known and unregistered transaction card is used.

[019] Figure 7 shows a detailed diagram of on embodiment the point of service device in communication with the fare management system.

DETAILED DESCRIPTION

[020] Figure 1 shows point of service non-reversible secure identification and encryption system ("system") 100. The system 100 includes a POS device 1 04 which may read a transaction card 102 for card data in support of or in connection with a transaction desired by a user. The POS device 104 may be located at a point of service that supports transactions desired by a user. The point of service may be a location where users are prompted for fare payments, such as, but not limited to, entrance to buses, entrances to train stations, or inside a taxi. However, the POS device 104 may be used in connection with any other commercial transaction system at any point of service to support commercial transactions (e.g., merchandise sales or returns) for any merchandise. Transaction card 102 may be a bank card, such as credit cards, debit cards, ATM cards, mobile devices with financial transaction capabilities, or any items which may be used for any types of transactions. The transaction card 102 is not limited to a card issued from or sponsored by a bank, but may be any type of card with any type of data used for transaction processing, such as unique identifiers for a person or an account, name, address, age, occupation, or other data.

[021] The POS device 104 may read card data stored in the transaction card 102 and obtain or determine a card data identifier based on the card data. The card data identifier may be a globally unique identifier ("GUID") 106 (e.g., unique among all such GUIDs that the system generates) and may be non-reversible. The GUID 106 is used as an example in the discussion below. A non-reversible identifier may be one that is difficult or impossible to reverse or decipher to obtain the original card data from which the card data identifier is determined. In one implementation, the SHA-1 or other hash algorithm may generate the card data identifier from the card data.

[022] The card data may include the primary account number ("PAN") associated with the transaction card 102. The card data may also include other identifiers such as, but not limited to, the account holder's name, expiration date and security digits. The card data may be embossed on the surface of the transaction card 1 02, and/or otherwise stored in transaction card, such as, but not limited to, in a magnetic strip in compliance with the ISO 781 1 part 1 -6 standard, RFID or other non-volatile digital memory. The system 100 may also encrypt the card data to obtain an encrypted card data 08. The system 00 may further obtain or assign a transaction ID 1 10 identifying the particular transaction desired by the user. The system 100 may assign or associate the same transaction ID 1 10 with both the GUID 106 and the encrypted card data 1 08.

[023] The system 100 may also include a negative list 1 12 accessible by the POS device 104 at the point of service. The negative list 1 1 2 may be implemented as a list of card data identifiers (e.g., GUIDs). The negative list 1 12 may be updated in real-time, or at any other interval. The system 100 may compare the GUID obtained from the card data of the transaction card 102 with the GUIDs of the negative list 1 12. The system 100 may, using the POS device 104, obtain the GUID based on the card data, access the negative list 1 12 and compare the GUID with the negative list.

[024] The POS device 104 will be described in more detail with reference to Figure 7. The POS device 1 04 may comprise a card reader 720 for reading card data from a transaction card 102 in communication with a POS processor 702 and a POS memory 704 including a POS program 706. The POS program 706 may include card data identifier (e.g., GUID) creation logic 708 for determining or generating the GUID 106. The POS program 706 may also include encryption logic 710 for obtaining the encrypted card data 108. The POS program 706 may also include logic for obtaining or assigning the transaction ID 1 10, accessing the negative list 1 12, and comparing the transaction GU ID 71 2 with the GUIDs stored in the negative list 1 12, such as negative list GUID1 718a and negative list GUID2 71 8b. The POS processor and the POS memory may be located inside the card reader 720 or in a separate enclosure.

[025] Upon receiving card data, the POS device 104 may execute the card data identifier creation logic 708, thereby responding immediately to the card data to determine the card data identifier, then use the card data identifier to process a desired transaction. In other words, the card data identifier is determined locally in the POS device 104 so that the card data identifier is immediately available for use in connection with a transaction. One advantage of immediately obtaining the card data identifier in the POS device 1 04 and processing the desired transaction using the card data identifier is that the transactions may complete more quickly. Transactions complete more quickly in part because it is not necessary to transmit reversible data, such as the encrypted card data 108, outside the POS Device 1 04, and await a response that may indicate whether the transaction is permitted or denied. Instead, a card data identifier, such as the GUID 106, is immediately available to be used as a surrogate for confidential card data in connection with any desired transaction through the POS device 1 04. Thus, the POS device 104 may proceed (e.g., to check against the negative list 1 1 2) without relying on or waiting for an external system to provide information needed to complete the transaction.

[026] Referring back to Figure 1 , if the system 100 finds a match in the negative list 1 1 2, the user may be denied access to the service provided by the POS. For example, where the point of service may be a boarding or access control in a bus in a mass transit system. In that case, the holder of a particular transaction card may be denied boarding when the card data identifier for that particular transaction card exists in the negative list 1 12 stored at the POS in the bus.

[027] The creation logic 708 may generate the card data identifier through a one-way hash of one or any combination of the PAN, account holder's name, security digits, expiration dates and any other information which may be associated with the transaction card 102. The card data identifier values can take many forms, such as 256-bits of data, or such data dithered down using mathematical calculations. Smaller card data identifier spaces may cause collisions (having identical card data identifier values for two different original values) with each other, and larger card data identifier spaces may reduce such collision risks. To that end, other plain text values may be added to the card data identifier values obtained by the one-way hash described above to mitigate the collision risk and provide a GUID. As opposed to encrypted data which may be decrypted to obtain the original data, the card data identifier is preferably implemented in a manner that makes it difficult or impossible to reverse or decipher to reveal the original data from which the card data identifier was generated.

[028] The system 100 may also encrypt the card data read from the transaction card 102. The encryption may be performed by the POS device 104. The encrypted card data 108 and the GUID 106 may also have a shared transaction ID 1 10, identifying the transaction. The system 100 may transmit the encrypted card data 1 08 and the GUID 106 to a fare management system ("FMS") 1 14. The transaction ID 1 10 may also be sent to the FMS 1 14. The FMS 1 14 may manage accounts associated with the GUID 106. The FMS 1 14 may determine whether the GUID 1 06 is known and/or registered within the FMS, and create/update an account based on the determination. The FMS 1 14 may be implemented with, for example, Accenture (TM) Fare Management Solution.

[029] In one implementation, the FMS 1 14 does not store the "clear" card data. In other words, card data will not leave the POS device 1 04 unless encrypted or is in the form of a GUID 106. Also, the encrypted card data 108 may not be decrypted within the fare management system 1 14. Therefore, the system 1 00 may transmit an authorization request 1 16 to a decryption system 1 18 for decryption of the encrypted card data 108. Along with the encrypted card data 108, the authorization request 1 16 may also include the GUID 106, amount to be charged to the transaction card 102, and the transaction ID 1 10. In situations where the user has a prepaid, or a postpaid aggregation account, the amount to be charged may be omitted from the authorization request 1 1 6, or may be zero ("0"). After the authorization request 1 1 6 is transmitted to the decryption system 1 18, the system may delete the encrypted card data 108 from the FMS 1 14, in compliance with the Payment Card Industry Data Security Standards ("PCI DSS").

[030] The decryption system 1 18 may decrypt the encrypted card data 1 10 to obtain the "clear" card data of the transaction card 1 02, and transmit an authorization request 1 1 6a to a card processing system 120, with the encrypted card data 108 replaced with the clear card data. The card processing system 120 may include a card processor, a card network, and/or a financial institution which processes the financial transaction made with the transaction card 102. In the case where the transaction card 102 is a bank card, the card processing system 1 20 may be a bank card company. The bank card company may authorize or decline the transaction. If the transaction is authorized, the card processing system 1 20 may transmit an authorization response 122. The authorization response may include the transaction ID 1 10. The decryption system 1 18 may transmit an authorization response 1 22a to the FMS 1 14. The authorization response 122a may include the transaction ID 1 10 and the GUID 106. The FMS 1 14, may update the account associated with the GUID based on the authorization response 122a.

[031] In one implementation, the FMS 1 14 does not transmit the authorization request 1 16 to the decryption system each time a transaction is made, if an account exists which is associated with the GUID 1 06 and if the account is a prepaid account, post-pay account, or any type of accounts for which payments are made for multiple transactions before hand, or for multiple transactions at a later time. In the case of a post-pay account, the authorization request 1 1 6 is not transmitted to the decryption system 1 1 8, until a certain time period has passed or certain conditions for fare payment have been met. The time period may be set to whatever time threshold a merchant is willing to accept. The longer and more transactions that are aggregated, the more risk that the merchant absorbs that the aggregate transaction may be rejected.

[032] The system may also include a web application 124 for registering a transaction card 102 in the FMS 1 14. The web application 124 may be accessed from or stored in a personal computer, mobile devices, or other terminals having access to the Internet or other computer networks. Registration of the transaction card 102 using the web application 124 will be described in more detail below.

[033] Figure 2 shows a flow diagram 200 of a transaction card registration operation of the system of Figure 1 .

[034] When a new transaction card 102 is issued to a user, the user may register in the FMS 1 14 through the web application 124. The web application 124 may be accessible by a proprietary computer network, or by public networks such as the Internet. The web application 124 may also be implemented by a web site accessible through any computer terminals having access to the Internet. The web application may be hosted by the FMS 1 14, or have access to the FMS. In an embodiment, the web application 124 may be implemented to include a hosted payment page.

[035] To register the transaction card 102, the user may enter through the web application 124 some or all of the card data of the transaction card 1 02 (202). Such card data may include, for example, one or any combination of: PAN, the name of the card holder, 3- or 4-digit card security code, the card holder billing address, and the expiration date. The card data may be manually entered by the user, or may be swiped at a magnetic card reader able to read card data stored on magnetic stripe cards in compliance with the ISO 781 1 part 1 -6 standard. With this information, the system 100, through web application 124, may generate a GUID 106 for the transaction card 102 (204). The system 100 may also encrypt the card data to obtain the encrypted card data 108 (206). The system 100 then sends the generated GUID 106 and the encrypted card data 108 to the FMS 1 14 (208). GUID 106 and the encrypted card data 108 may be sent, for example, using Secure Sockets Layer/Transport Layer Security ("SSL/TLS").

[036] The FMS 1 14 may include a known list which maintains a list of known (previously existing within the system 1 00) GUIDs, and compare the GUID 1 06 against the known list to obtain a known list response (210). The known list response may indicate that the GUID 106 is "unknown", "known", or "registered". A known GUID may indicate that the card has been used in the system previously. A registered GUID may indicate that an individual card holder has self-associated with that card, and in doing so, may have elected to associate a prepaid fare product or agreed to terms for a post-pay account. If the transaction card 102 is a card which has never been registered with the FMS 1 14, an "unknown" known list response would be generated (212). If an "unknown" response is generated, the FMS 1 14 may create a new account for the GUID 106 (214), and transmit an authorization request 1 16 to the decryption system 1 1 8 (216).

[037] The decryption system 1 18 may decrypt the encrypted card data 108 to obtain a "clear" (non-encrypted) card data (218). The system 100 may register and store the GUID and the clear card data in the decryption system 1 1 8 for future GUID correlation back to the clear card data (220). The stored GUID may also be used for future identification by the decryption system 1 18. The decryption system 1 18 may store the clear card data in an encrypted form or may instead only store the encrypted form of the clear card data. The decryption system may also transmit an authorization request 1 16a to the card processing system 1 20 (222). In the case of registering the transaction card 102 through the web application 124, the authorization request 1 1 6a may or may not include information regarding amount to be charged, depending on the type of account being created. The card processing system 120 may authorize or deny the transaction made with the transaction card 102. If the card processing system authorizes the transaction, then it may transmit an authorization response 1 22, indicating the authorization of the transaction, to the decryption system 1 1 8 (224). In turn the decryption system 1 18 may transmit an authorization response 122a, indicating the authorization of the transaction, to the FMS 1 14 (226). The FMS 1 14 may then update the account corresponding to the GUID 106, indicating that the transaction card 102 associated with the GUID 106 is ready to use for payments and access to services (228).

[038] Figure 3 shows a flow diagram 300 of an operation of the system of Figure 1 in a "positive" case where a known and registered transaction card is used.

[039] When a transaction card is presented to a POS device 104 at a mass transit POS for a transit fare transaction, the POS device may read the transaction card 102 to obtain the card data (302). Such card data may include, for example, some or all of PAN, the name of the card holder, 3- or 4-digit card security code, and the expiration date. The card data may be swiped at a magnetic card reader able to read card data stored on magnetic stripe cards in compliance with the ISO 781 1 part 1 -6 standard or tapped at a ISO 14443 contactless card reader to read the information stored on the Radio Frequency Identification (RFID) chip on the card. With this information, the system 100, through the POS device 104, may generate a GUID 1 06 for the transaction card 102 (304).

[040] The system 100 may also encrypt the card data to obtain the encrypted card data 108 (306). The system 100 then compares the GUID 106 with the GUIDs in the negative list 1 12 for a match (308). The negative list 1 12 may store a list of GUIDs, the transaction cards of which is to be denied access to the services provided at the POS. A GUID 106 may be added to the negative list 1 12 if the corresponding transaction card has been previously denied authorization by the card processing system 120, or otherwise identified as unsuitable for granting service. Depending on the configuration of the POS device 104, the negative list 1 1 2 may be updated in real time, may be updated periodically in predetermined intervals, or may be updated upon a predetermined triggering event. If no match is found in the negative list, the POS device 1 04 generates an "unknown" negative list response, indicating that no match is found in the negative list 1 12 (310). If an unknown response is generated, the user presenting the transaction card 102 is granted access to the service provided by the POS (312). In the case of a subway station in a mass transit system, a gate may be activated so that the user is granted entry into the subway station.

[041] The system 100 may also transmit the GUID 106 and encrypted card data 108 to the FMS 1 14 (314). For an on-line POS device 104 which has a substantially continuous access to the FMS 1 14, the GUID 106 and the encrypted data 108 is immediately sent to the FMS 1 14. For an off-line POS device 1 04 which has access to the FMS 1 14 during a certain period of time, the GUID 106 and the encrypted data 108 is stored in the POS device and transmitted to the FMS 1 14, when the POS device has access to the FMS 1 14 and/or meets a predetermined condition.

[042] After receiving the GUID 106 and the encrypted card data 1 08, the FMS 1 14 may check the known list to determine if the GUID is known (316). The FMS 1 14 may generate a known list response, indicating that the GUID is unknown, known, or registered. A "registered" known list indicates that an account is already created for the GUID 106. If a "registered" known list response is generated (318), the account corresponding to the GUID 106 is updated, to reflect the transit fare transaction (320). This update may include updating the number of times the transit fare transaction has occurred and deducting the fare amount corresponding to the transit fare transaction from an existing balance. The system 100 may wait for an aggregation period before transmitting an authorization request 1 1 6 (322). Subsequent transactions may occur during the aggregation period and the system 100 may keep track of the transactions occurring during this period. The aggregation period may vary depending on the type of account corresponding to the GUID 106. The aggregation period may be one month in the case of a one month post-pay account. The aggregation period may also correspond to the period required for a user to use up all or more than a certain amount of the initial account balance in the case of a pre-paid account with automated refill. If the aggregation period is up, the system 100 may transmit an authorization request 1 16 to the decryption system 1 18 (324). The authorization request 1 1 6 may include the GUID 106, the encrypted card data 108, amount to be charged to the transaction card 102, and the transaction ID 1 1 0. The authorization request 1 1 6 may reflect all the transactions accumulated during the aggregation period.

[043] The decryption system 1 18 may decrypt the encrypted card data 108 (326), register and store the GUID 106 and the decrypted "clear" card data in the decryption system (328), and transmit the authorization request 1 16a to the card processing system 1 20 (330). The authorization request 1 16a may include some or all of the information of the authorization request 1 16, but the encrypted card data 108 may be replaced with the "clear" card data.

[044] The card processing system 120 may authorize or deny the transactions and transmit an authorization response 122, indicating whether or not the transactions are authorized, to the decryption system 1 18 (332). The decryption system 1 18 may then transmit the authorization response 122a, indicating whether or not the transactions are authorized and also including the transaction ID 1 10, to the FMS 1 14. The FMS 1 14 may update the account corresponding to the GUID 106 based on the authorization response 122a. This update may include reducing the available balance by the amount charged for the authorized transactions. If any of the transactions are denied, the account may be updated to reflect the denial, and the system 100 may also update the negative list 1 12 to include the GUID 106.

[045] Figure 4 shows a flow diagram 400 of an operation of the system of Figure 1 in a "negative" case.

[046] When a transaction card 1 02 is presented to a POS device 104 at a mass transit POS for a transit fare transaction, the POS device may read the transaction card 102 to obtain the card data (402). The system 100, through the POS device 104, may generate a GUID 106 for the transaction card 02 (404) and also encrypt the card data to obtain the encrypted card data 108 (406). The system 100 then compares the GUID 106 with the GUIDs in the negative list 1 12 for a match (408). If a match is found in the negative list 1 12, the POS device 104 may generate a "deny" negative list response, indicating that a match is found in the negative list (410). If a deny response is generated, the user presenting the transaction card 102 is denied access to the service provided by the POS. In the case of a subway station, the user may be denied entry to the subway station. Further, an account update message may be transmitted to the FMS 1 14 (412). The account update message may include the GUID 106 and may indicate that the transaction card 102 corresponding to the GUID has been denied access to the service provided by the POS. In response, the FMS 1 14 may update the account corresponding to the GUID 106 based on the account update message.

[047] Figure 5 shows a flow diagram of an operation of the system of Figure 1 in a "positive" case where a new and unknown transaction card is used.

[048] A user may board the bus, enter the subway station, or ride a taxi and may wish to perform a transaction using a transaction card 102 which has not been registered or previously used within the mass-transit system. For example, the user may travel to a new city intending to use the transit system only for a couple of times and do not wish to create a long-term account (i.e. bulk pre-paid account or a recurring post-pay account). In such situation, the user may wish to conduct a one-time transaction with his/her credit card or a debit card each time the user rides on the mass-transit system.

[049] In this case, steps 502-514 may be identical to the steps 302-314 described with reference to Figure 3, and its discussion will be omitted.

[050] After the encrypted card data 108 and the GUID 106 is transmitted to the FMS 1 14 (514), the FMS may check the known list to determine whether the GUID 106 has previously existed in the system 100 (516). Since in this case the transaction card 1 02 has not been previously used in the system, the system 100 may generate an "unknown" known list response, indicating that the GUID 106 has not existed in the system before (518). After the "unknown" known list response is generated, the system 100 may create an account corresponding to the GUID 106 (520). Since no pre-paid or post-pay account has been created, the system 100 may not wait for an aggregation period and transmit to the decryption system 1 18 an authorization request 1 16 for the current transaction only (522). The authorization request 1 16 may include, for example, the GUID 106, the encrypted card data 108, amount to be charged to the transaction card 102, and the transaction ID 1 1 0.

[051] The decryption system 1 18 may decrypt the encrypted card data 108 (524), and transmit the authorization request 1 1 6a to the card processing system 120 (526). The authorization request 1 16a may include some or all of the information of the authorization request 1 16, but the encrypted card data 108 may be replaced with the "clear" card data.

[052] The card processing system 120 may authorize or deny the transaction and transmit an authorization response 122, indicating whether or not the transaction is authorized, to the decryption system 1 18 (528). The decryption system 1 18 may then transmit to the FMS 1 14 the authorization response 122a, indicating whether or not the transactions are authorized (530). The authorization response 122a may also include the transaction ID 1 10. The FMS 1 14 may update the account corresponding to the GUID 106 based on the authorization response 122a (532). If the transaction is denied, the account may be updated to reflect the denial, and the system 100 may also update the negative list 1 12 to include the GUID 106.

[053] The system 100 may also include a "positive" list. The positive list may include GUIDs for which a transaction has been previously authorized by the card processing system 120. The positive list may be stored in the FMS 1 14, in the POS device 104, or anywhere accessible by the FMS 1 14 and/or the POS device 104. If a positive list is available, and if the transaction is authorized at step 528, the system 100 may update the positive list to include the corresponding GUID 106.

[054] Figure 6 shows a flow diagram 600 of an operation of the system of Figure 1 in a "positive" case where a known and unregistered transaction card is used.

[055] A transaction card 102 may be known and unregistered when the user has already set up an account through the web application 124, but has not yet performed a transaction at a POS. When a user presents the transaction card 102 at a POS for the first time after setting up an account, the operation of the system 1 00 is similar to that described with reference to Figure 3. For example, steps 602-616 may be identical to steps 302-316, and discussion will be omitted regarding steps 602-616. At step 618, since an account has been already set up but the transaction card 102 has not been used after the set up, the system may generate a "known" known list response (618). In response, the system 100 may update the account corresponding to the GUID 106. The update may include indicating that the transaction card 102 has now been presented for the first time at the POS for transaction. The remaining steps may also be similar to the operation described with reference to Figure 3. For example, steps 622-636 may be identical to steps 322-336, and discussion with be omitted regarding steps 622-636.

[056] In an embodiment, a user may be prompted for the transaction card 102 upon entry of POS and once again upon exit of POS. Therefore, before exiting the POS, a user may be required to present the transaction card 1 02 to the POS device 104 once more, or may be required to present the transaction card to a second POS device (not shown) which may be located at another location. Even though the GUID 106 obtained based on the transaction card 1 02 may not be present in the negative list 1 12 upon entry into the POS, the system 100 may update the negative list between the user's entry and exit of the POS. If the negative list 1 12 is updated to include the GUID 106 during this time, the POS device 104 or the second POS device will find a match when the transaction card 102 is presented before the user exits the POS. In such situation, the system 100 may not allow the user to exit the POS. Alternatively, the system 100 may allow the user to exit, but update the negative list 1 12 to indicate that the user has been allowed to exit the POS and prompt and investigation.

[057] The embodiments discussed above are examples only. The point of service is not limited to the mass-transit system, and may be other types of locations where any types of transactions are conducted. The card processing system may include other systems, institutions, or entities which may authorize a financial transaction. [058] The system described above may be implemented in any combination of hardware and software. For example, programs provided in software libraries may provide the functionality that performs the operations discussed above, hashes the card data to determine or generate GUIDs, encrypts the card data, or other functions. Such software libraries may include dynamic link libraries (DLLs), or other application programming interfaces (APIs). The logic described above may be stored on a computer readable medium, such as a CDROM, hard drive, floppy disk, flash memory, or other computer readable medium.

[059] In addition, the system may be implemented as a particular machine. For example, the particular machine may include a CPU, and software library for carrying out the functionality that performs the operations discussed above, hashes the card data into GUIDs, encrypts the card data, or other functions noted above. Thus, the particular machine may include a CPU, and a memory that stores the logic for performing the operations described above.

[060] While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.

Claims

CLAIMS We claim:

1 . A method for initiating a secure transaction, the method comprising:

receiving, at a point of service device, transaction card data from a transaction card in connection with a card holder desired transaction;

immediately determining, in the point of service device, a card data identifier from the transaction card data, the card data identifier comprising a globally unique identifier (GUID) that provides a non-reversible representation of the transaction card data; and

once the card data identifier is determined, initiating the card holder desired transaction for the card holder using the card data identifier.

2. The method of claim 1 , further comprising:

checking the card data identifier against a card data identifier rejection list stored in the point of service device; and

rejecting the card holder desired transaction when the card data identifier is present in the card data identifier rejection list.

3. The method of claim 1 , further comprising:

permitting the card holder desired transaction when the card data identifier is absent from the card data identifier rejection list.

4. The method of claim 1 , further comprising:

checking the card data identifier against a card data identifier acceptance list stored in the point of service device; and

permitting the card holder desired transaction when the card data identifier is present on the card data acceptance list.

5. The method of claim 1 , where the card data identifier is obtained by applying a one-way hash to the transaction card data.

6. The method of claim 1 , further comprising:

encrypting the transaction card data to obtain encrypted card data;

transmitting the encrypted card data and the card data identifier to an external system in connection with conducting the desired transaction; and

deleting the encrypted card data after transmitting the encrypted card data and the card data identifier to the external system.

7. The method of claim 6, further comprising:

receiving a negative authorization response from the external system; and updating a card data identifier rejection list in the point of service device to include the card data identifier.

8. The method of claim 6, further comprising:

storing the desired transaction with other transactions prior to transmitting the encrypted card data and the card data identifier to the external system in connection with conducting the desired transaction.

9. A system for initiating a secure transaction, the system comprising:

a processor;

a reader operable to receive transaction card data from a transaction card in connection with a card holder desired transaction; and

a memory coupled to the processor, the memory comprising:

the transaction card data; and

processing logic that when executed causes the processor to immediately determine a card data identifier based on the transaction card data, the card data identifier comprising a globally unique identifier (GUID) that provides a non-reversible representation of the transaction card data, and initiate a card holder desired transaction for the card holder using the card data identifier.

10. The system of claim 9, where the processing logic, when executed, further causes the processor to:

check the card data identifier against a card data identifier rejection list stored in the point of service device; and

reject the card holder desired transaction when the card data identifier is present in the card data identifier rejection list.

1 1 . The system of claim 9, where the processing logic, when executed, further causes the processor to:

permit the card holder desired transaction when the card data identifier is absent from the card data identifier rejection list.

12. The system of claim 9, where the processing logic, when executed, further causes the processor to:

check the card data identifier against a card data identifier acceptance list stored in the point of service device; and

permit the card holder desired transaction when the card data identifier is present on the card data acceptance list.

13. The system of claim 9, wherein the processing logic comprises one-way hash logic for obtaining the card data identifier from the transaction card data.

14. The system of claim 9, wherein the processing logic, when executed, further causes the processor to:

encrypt the transaction card data to obtain an encrypted card data;

transmit the encrypted card data and the card data identifier to an external system in connection with conducting the transaction; and

15. The system of claim 14, where the processing logic, when executed, further causes the processor to:

receive a negative authorization response from the external system; and update a card data identifier rejection list in the point of service device to include the card data identifier.

16. The system of claim 14, where the processing logic, when executed, further causes the processor to:

store the desired transaction with other transactions prior to transmitting the encrypted card data and the card data identifier to the external system in connection with conducting the desired transaction.

17. A product comprising:

a machine readable medium; and

processing logic stored on the medium that, when executed by a processor in a point of service device, causes the processor to:

receive transaction card data from a transaction card in connection with a card holder desired transaction;

immediately determine a card data identifier based on the transaction card data, the card data identifier comprising a globally unique identifier (GUID) that provides a non-reversible representation of the transaction card data; and

initiate a card holder desired transaction for the card holder using the card data identifier.

18. The product of claim 17, where the processing logic, when executed, further causes the processor to:

reject the card holder desired transaction if the card data identifier is present in the card data identifier rejection list.

19. The product of claim 17, where the processing logic, when executed, further causes the processor to:

20. The product of claim 17, where the processing logic, when executed, further causes the processor to:

21 . The product of claim 17, wherein the processing logic comprises one-way hash logic for obtaining the card data identifier from the transaction card data.

22. The product of claim 17, wherein the processing logic, when executed, further causes the processor to:

encrypt the transaction card data to obtain an encrypted card data;

delete the encrypted card data after transmitting the encrypted card data and the card data identifier to the external system.

23. The product of claim 22, where the processing logic, when executed, further causes the processor to:

24. The product of claim 22, where the processing logic, when executed, further causes the processor to: