CA2418638A1 - System and apparatus for small amount transaction by mobile - Google Patents
System and apparatus for small amount transaction by mobile Download PDFInfo
- Publication number
- CA2418638A1 CA2418638A1 CA 2418638 CA2418638A CA2418638A1 CA 2418638 A1 CA2418638 A1 CA 2418638A1 CA 2418638 CA2418638 CA 2418638 CA 2418638 A CA2418638 A CA 2418638A CA 2418638 A1 CA2418638 A1 CA 2418638A1
- Authority
- CA
- Canada
- Prior art keywords
- user
- machines
- messages
- billing
- connectivity
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/29—Payment schemes or models characterised by micropayments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/20—Technology dependant metering
- H04M2215/2026—Wireless network, e.g. GSM, PCS, TACS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/32—Involving wireless systems
Abstract
This invention addresses the problem of electronic payment to a point of purchase (e.g., a vending machine, parking meter, ...) referred to as VS 110, by means of a mobile user equipment 150, (i.e., mobile phone or connected PDA). In this invention, we do not assume direct connectivity of the VS 110. The connection between the VS 110 and the service center (SC) 170 is indirectly created with the user's equipment through the messages that are securely exchanged. Security is provided with the proper use of encryption and CRC methods. It is handled by either Order Synchronized Code encryption or Initialization Vector and the key distribution system. Multiple languages are supported. The billing would be provided by the wireless carrier or through an independent billing service provider 1220. When the user equipment 150 does not support Infrared 116 or short range wireless networking (WLAN 802.11 118, Bluetooth 117) user 140 will assist in conveying messages between VS 110 and SC 170.
Description
Description List of Abbreviations ADE Automatic Data Exchange BT 117 Bluetooth CDM 625, 670 Coding Decoding Module CID 126 Confirmation 117 CRC Cyclic Redundancy Check EDM 720,780 Encryption Decryption Module FCS Frame Check Sequence IR 116 Infrared IV Initialization Vector OMP 760 OSC maintenance peer OSC 500 Order Synchronized Code PDA Personal Digital Assistant SATM Srnall Amount Transaction by Mobile SC 170 Service Center SMS Short Message Service TID 125 Transaction ID
UADE User Assisted Data Exchange UE 150 User Equipment VS 110 Vendor System WLAN 118 Wireless Local Area Network Description Brief description of figures Fig. l) Block diagram of the user-assisted data exchange (U.ADE) system.
Fig. 2) Definition of the TID 125 and CID 126 messages.
Fig. 3) Success path use case.
Fig. 4) Simplified Failure path use case.
Fig. 5) The seven symbol long OSC 500.
Fig. 6) Block diagram of the encryption scheme.
Fig. 7) Block diagram of the security and error protection between SC 170 and VS 110.
Fig. 8) Snapshot of the display for choosing the product.
Fig. 9) Snapshot of the display for Displaying TID 125 and guiding the user.
Fig.10) Snapshot of the display fox Accepting CID 126 from the user.
Fig. ll) Snapshot of the display for Product release.
Fig. 12) Block diagram of the billing system interaction with the SC 170.
Description Overview This document discloses the design for the "Small Amount Transaction by Mobile" or SATM hereafter.
SATM is a system to facilitate paying small amount transaction with a mobile User Equipment (hereafter, UE 150). The meaning of "small amount" depends on the context of the transaction and may vary from application to application or from time to time. The mobile device in its simplest form is a voice only cell phone or it can be a state-of-the-art mobile communication device such as cell phones or P'DAs with data transmission capability.
The goal for this system is to ensure that any user with any type of available mobile device, at any enabled un-attended or attended Vending Station (VS 110 hereafter), be able to pay for a transaction amount up to a certain limit. At the same time in this design it is not required that the VS 110 have connectivity through any means of data communication or telecommunication service.
The only requirement for the system is that the carrier, to whom the user 140 is subscribed to, is providing SATM service and the user is allowed to use the service by the carrier (very much like call forwarding or caller Id features).
...,,\
Description State-of the-art There have been several instances of different designs and implementation of similar systems that enable users to pays for their purchase using their mobile device. The following is some of the cases that we have studied:
~ Japan: NTT DoCaMo and Coca Cola o Australia: Telstra Core Ltd and Coca Cola o United states - PocketChange from USA Technologies o Singapore - SingTel AlI of the solutions provided by the cases mentioned above have one common aspect that differentiates from this invention arid that is the requirement of the VS 110 to be connected to a data communication or a telecommunication network by some means of connectivity such as a phone line or Internet. The presented invention in this disclosure, is offering a novel possibility that without imposing permanent means of connectivity for the VS I10, it enables the user's mobile device (UE 150) to be used to convey the information from the VS 110 to the Service Center (SC 170) and vise versa.
Description The Solution The presented solution makes it possible that a SATM transaction be fulfilled without a need for explicit permanent connectivity for the VS 110. The data exchange required to do this, is conveyed through the UE 150 in two different scenarios:
o User-Assisted Data Exchange (UADE) In this scenario, user 140 reads and receives information from the VS 110 and delivers it (i.e., punch in) to UE 150 to be transmitted to the SC 170 and on the other direction, receives data from SC 170 through the UE 150 and delivers them to VS 110. In this case there is no need to modify the UE 150 to install new software to support SATM. In fact any regular cell phone (with only simple voice communication) can be used to fulfill a transaction with a SATM enabled VS
110.
o Automatic Data Exchange (ADE) If the UE 150 is enabled with any means of local wireless connectivity such as Bluetooth 116, Wireless LAN (802.11 and so on) 118 or Infrared 116 (IrDA for example), the data exchange can be conveyed through this local connectivity.
With this, VS 110 can exchange data that it needs with the SC 170 to fulfill as transaction and the user only plays supervisory role to confirm or decline the transaction when needed.
General Block Diagram Figure 1 depicts the block diagram and the main elements of the system in UADE
scenario.
Description Description of the main elements Messaging The main messages that are exchanged between VS 110 and the SC 170 to fulfill a SATM transaction are:
o Transaction Id (T1D 125) from VS 110 to SC 170 o Confirmation Id (CBS 126) from SC 170 to VS 110 TID 125 consists of the following fields:
1. Merchant Id 210 2. Vendor Station Id 210 3. Price 220 4. Language 230 5. Error Correction (e.g., CRC) 240 The elements of C>T7 126 (Confirmation 1D) are as follows:
1. Message (encrypted) 250 2. Error Correction (e.g., CRC) 260 For the "user assisted data exchange" model, we have limited the TID 125 to 7 digits and CID 126 to 4 digits, for user convenience.
Figure 2 illustrates the byte description of T1D 125 and CII? 126.
Figure 3 depicts the Success path use case. Following remarks are in order for Figure 3:
~ This is a simplified use case for the success path, and for the UADE mode.
Some changes would be necessary for the ADE mode (for example, the UE 150 itself can check for the CRC).
~ ,: The message from SC 170 to UE 150 in UADE mode is a voice or SMS message, as this configuration necessitates no change in the UB, and virtually every UE
can use the system without any modification. In case of voice, the message would read the CII? 126 digit by digit and then after a short silence (of about 10 seconds) it repeats itself several times. In ADE the CB7 126 will automatically be transmitted from SC 170 to VS 126 without much user interaction or even Description knowledge (in IR 116 mode, the user may be asked to keep the UE 150 in a reasonable distance and direction to the VS 110).
~ As we will see for the billing system later, the transaction waits for a predetermined time (about 10 minutes, for instance) before the user account is charged. This gives the user opportunity to cancel thc; requested service, in case of error or in the case user changes his/her mind.
Figure 4 depicts the Simplified Failure path use case.
It is obvious that there are several different reasons for a failure. Below we explain some of the main failure cases:
1. If SC 170 finds that CRC is not correct (this can be either because of a punching error of TID 125 by the user or any simple communication error), the user is asked to re-enter the TID 125.
2. One reason for a failure can be "out of sync." If the encryption in the VS
110 is not in sync with the one in SC 170, then this failure is detected. In such a case, the VS 110 would become obsolete. Emergency message should be sent to the responsible department to make them in sync again. A message might be sent to the SC 170 to temporarily put the VS 110 out of use.
3. If the billing system can not identify the user, or that the user has not enough cash/credit to perform the transaction, a failure should be generated that would be understood by the VS 110 and appropriate message would be screened.
4. If the VS 110 detects that the message is not right (either the CRC is not correct, or the message is not among the allowed messages), the user would be asked to repeat the process of entering TID 125 and CID 126. If this problem occurs more than a predetermined number of times, the transaction should be cancelled by giving a special canceling TID 125 to the user; when the user enters this code, the transaction would be cancelled and the user will not be billed for this transaction.
5. If the VS 110 receives the CID 126 but at this time learns that for some reason, it can not provide the service or release the product, the same cancellation TID
mechanism will be applied. Of course, to guarantee a good user experience, the probability of such an event should be kept minimum.
Description Language selection Accommodating several languages in the system, would allow it to be more appealing for places where more than one language are spoken (like many regions in Europe, Canada, and countries with a high immigration rate) and also places with a large number of visitors (who may speak different languages). A simple example in Canada is the two official languages: English and French.
To accommodate this requirement, all we need is a human interface (keys, for example) to choose the language. In later versions, this can also be done as a preset or provisioned parameter inside the cell phone (or the PDA) which is set by the user 140 once at subscription time and is always used as his/her language preference, till helshe proceeds to change it.
To accommodate two languages, we only need b=1 bit and this is what we can do for several situations, including the Canadian context, where two official languages exist. In general, to accommodate L languages, we need b =
ceil(log2(L)) bits, where ceid(.) denotes the ceiling function and loge is the logarithm in base 2. As an example, with just three bits, we can accommodate up to eight languages.
For instance, in a North American context, these eight languages constitute:
English, French, Chinese, Spanish, Arabic, Persian, Russian, and Korean. In a Western European context, it can be English, French, German, Spanish, Italian, Portuguese, and Greek and in a Middle-Eastern context, it can be:
Arabic, Turkish, Persian, Kurdish, Azeri, Hebrew, English and French, or any other combination of languages.
It is obvious that the choice of the languages is completely reconfigurable by the operator. The number of possible languages can also be eight, more than eight, or less than eight. The choice of eight here is based on a reasonable design, but does not Iimit us in any other choice in the future.
So the user 140 selects the language (or goes with the default language).
Based on this choice, necessary bits are generated in the VS 110 and transmitted to the SC 170. All the consequent messages, either voice or text, including the optional advertisement 115, will be delivered in the chosen language from both VS 110 and SC 170 sides.
Description Coding and security In order to ensure the integrity and security of each transaction, and the system in general, the transmitted messages have to be encrypted. Since there is no direct connectivity between the VS 110 and SC 170, user 140 or user's equipment 150 has to convey the messages between VS 110 and the SC 170. In the case that the user's equipment 150 is limited to voice functionality, the user 140 will punch in the TID 125 into the I1E 150 and then received CID 126 from the L1E 150 into VS 110 via keypad. To maintain a good user experience, TID 125 is limited to 7 digits and ClT7 I26 is limited to 4 digits. Normal approaches to encryption can not be applied to this scenario because they all tend to use a large key (between 40-128 bits) which will make TID 125 and CID
126 too large for a user 140 to punch on keypad 107. Hence, this design uses an Order Synchronized Code (OSC 500) to encrypt Tm 125 excluding the VSId 210 filed and the CID 126.
The following rules govern the encryption/decryption of the messages:
a In TID 125, merchant ID 210 is sent as plain text (without encryption).
o In TID 125, Price and CRC/Language is encrypted.
o An OSC 500 is used as the key for encryption.
o SC 170 maintains a synched OSC 500 per provisioned VS 110.
a For maintaining security, SC's OSC 500 peer 760 performs a look ahead for the next r~LA codes to find a match.
Transaction Security by Order Synchronized Code (OSC 500) The design is based on a seven digit OSC 500 that is generated every time a new transaction is to be fulfilled. This OSC 500 is generated both in the VS 110 and at the SC
I70 and they are kept synchronized on the order of the transactions, i.e., for the first transaction VS 110 and SC 170 generate the same OSC 500 and for the second and so on.
The system is based on two identical pseudo random number generators with seed at the VS 110 and SC 170. In the SC 170 for each VS 110 ax OSC 500 maintenance peer (OMP) 760 is created and maintained in synch upon provisioning of that VS 1I0.
To ensure that VS 110 and SC 170 are kept in synch and don't fall out of synch, the SC 170 attempts to look ahead (or depending on the implementation, can be look behind) nLA
(number of Look Ahead) codes to find a match.
Description Figure 5 illustrates the OSC 500 as a 7 symbol long code.
The last 3 digits of the OSC 500 are used as a key to encrypt the Price, CRC
and Language code part of the TID 125 at the VS 110 and the same code should be used to decrypt the TID 125 at the SC 170 and the first 4 digits are used to encrypt CID 126 at the SC 170 and again decrypt it at the VS 110. The probability of repeating a TID 125, CID 126 combination p is calculated as:
_ nLA
p nS mlenOSC
y With assuming ZenOSC = 7 and nLA = 32, there is about 1 in 10 million chance that the same TID 125, CID 126 combination is generated by the system for each VS 110.
(nSym is assumed to be 12 and is the number of symbols on the keypad 107 which includes "0"-"9" "*" and °°#"~.
A potential delinquent who wishes to use the system in a phony way, may want to enter a random number as CID 126. Below, we calculate the chance for this CID 126 to be the right one which will lead the VS 110 to release a product or to provide a service.
nSym =12 nChar = 4 pfraud = 1/nSym "C~'~r= 1/124 = 1/20736 = 0.000,048,225 with nSym equal to 10, the value becomes simply 0.0001.
Description Error detection Cyclic Redundancy Check (CRC) is used as a means of error detection in both the TID
125 and the CID 126. A Frame Check Sequence (FCS) is calculated on the information bits and transmitted as redundant bits along with the information bits.
For TID 125, one digit is reserved for FCS, which provides more than 4 bits.
For C1D 126, three digits constitute the message, and again one digit is reserved for FCS.
The whole four bytes are then encrypted.
Figure 6 and 7 and describe the overall encryption and error detection mechanism in the system.
Description User interface Figure 8, 9, 10 and 11 illustrate an exemplary arrangement of the user interface of the system. Although the user interface can be built in other ways and using other shapes and form factors of keypad 107 and display 106 as well as keys and buttons 930, 940.
Description Billing The Billing Proxy in the SC 170 is in direct secure contact with the billing system 1220 that is provided by the billing provider. The billing provider can be one or a combination of the followings:
o The Wireless Carrier In this case the wireless carrier provides the billing service. The charges for the products/services that the subscribers purchase will be applied to the existing wireless service account that they already have established for their wireless service. If this option is opted, subscribers don't need to register and sign up for SATM service since they axe already known to the billing system.
o A financial institution A financial institution can be designated as the billing service provider.
This is probably the most extensive option for billing since the possibility of deploying the service over a broad range of products and services is much higher. An example of this scenario can be thought linking the subscribers' credit card account to their SATM service which conveniently charges all the purchases made by their mobile UE 1S0 to their credit card account. Another example can be a financial institution that charges user's checking account.
o The Vending Station o~eratin entity The firm that is operating the chain of VS 110 can act as the billing service provider. One condition in this case is that all the wireless service users that Iike to use this service, need to register with the billing service provider.
a The ~roductlservice man~acturer~rovider In this scenario the provider of the product or service that is being offered by SATM enabled VS 110 is providing the billing service.
Description Figure 12 is a diagram that shows how the billing service provider 1220 interacts with SC
170.
The billing service provider 1220 can reply back to a "charge account" 1230 request with one of the following reply codes 1240:
OK Charge applied NSF Not Sufficient Fund UU User Unknown GF General Failure To handle cancelling a transaction properly, the billing system keeps the billing record for a specified amount of time (ballihgDelay) before it applies the charge to the user's account. This delay allows the user to cancel the transaction. An example value for billingDelay can be set to 10 minutes and the billing system periodically visits the unapplied charge record and applies them if they are older than the billingDelay.
Description Automatic data exchange mode In this mode, the UE 150 and VS 110 have a local wireless way of communication and the need for the user to punch in the T117 I25 and then the CID 126 would be eliminated. The communication between the UE 150 and VS 110 can be but not limited to any of the followings: infrared (IR) 1I6, Bluetooth (BT) 117 or wireless LAN (such as 802.11 series) 118.
The first consequence of the automatic messaging is that the number of bytes (or digits) that are used in messaging can be more since there is less limitation by the user experience constraints and user typing errors.
In such a case, the following information can also be transmitted from VS l I0 to the SC 170:
1. More bits for language selection.
2. More bits for CRC to further decrease the osk of error (or even Reed-Solomon error correction can be used instead of CRC).
3. More bits for Merchant ID 210 and Vendor ID 210 (so the possibility to give the service to a bigger area).
4. More bits for the price (so the possibility of having more dynamic range and/or having more precision).
5. Possibility of transmitting an Initialization Vector (IV) for the encryption.
UADE User Assisted Data Exchange UE 150 User Equipment VS 110 Vendor System WLAN 118 Wireless Local Area Network Description Brief description of figures Fig. l) Block diagram of the user-assisted data exchange (U.ADE) system.
Fig. 2) Definition of the TID 125 and CID 126 messages.
Fig. 3) Success path use case.
Fig. 4) Simplified Failure path use case.
Fig. 5) The seven symbol long OSC 500.
Fig. 6) Block diagram of the encryption scheme.
Fig. 7) Block diagram of the security and error protection between SC 170 and VS 110.
Fig. 8) Snapshot of the display for choosing the product.
Fig. 9) Snapshot of the display for Displaying TID 125 and guiding the user.
Fig.10) Snapshot of the display fox Accepting CID 126 from the user.
Fig. ll) Snapshot of the display for Product release.
Fig. 12) Block diagram of the billing system interaction with the SC 170.
Description Overview This document discloses the design for the "Small Amount Transaction by Mobile" or SATM hereafter.
SATM is a system to facilitate paying small amount transaction with a mobile User Equipment (hereafter, UE 150). The meaning of "small amount" depends on the context of the transaction and may vary from application to application or from time to time. The mobile device in its simplest form is a voice only cell phone or it can be a state-of-the-art mobile communication device such as cell phones or P'DAs with data transmission capability.
The goal for this system is to ensure that any user with any type of available mobile device, at any enabled un-attended or attended Vending Station (VS 110 hereafter), be able to pay for a transaction amount up to a certain limit. At the same time in this design it is not required that the VS 110 have connectivity through any means of data communication or telecommunication service.
The only requirement for the system is that the carrier, to whom the user 140 is subscribed to, is providing SATM service and the user is allowed to use the service by the carrier (very much like call forwarding or caller Id features).
...,,\
Description State-of the-art There have been several instances of different designs and implementation of similar systems that enable users to pays for their purchase using their mobile device. The following is some of the cases that we have studied:
~ Japan: NTT DoCaMo and Coca Cola o Australia: Telstra Core Ltd and Coca Cola o United states - PocketChange from USA Technologies o Singapore - SingTel AlI of the solutions provided by the cases mentioned above have one common aspect that differentiates from this invention arid that is the requirement of the VS 110 to be connected to a data communication or a telecommunication network by some means of connectivity such as a phone line or Internet. The presented invention in this disclosure, is offering a novel possibility that without imposing permanent means of connectivity for the VS I10, it enables the user's mobile device (UE 150) to be used to convey the information from the VS 110 to the Service Center (SC 170) and vise versa.
Description The Solution The presented solution makes it possible that a SATM transaction be fulfilled without a need for explicit permanent connectivity for the VS 110. The data exchange required to do this, is conveyed through the UE 150 in two different scenarios:
o User-Assisted Data Exchange (UADE) In this scenario, user 140 reads and receives information from the VS 110 and delivers it (i.e., punch in) to UE 150 to be transmitted to the SC 170 and on the other direction, receives data from SC 170 through the UE 150 and delivers them to VS 110. In this case there is no need to modify the UE 150 to install new software to support SATM. In fact any regular cell phone (with only simple voice communication) can be used to fulfill a transaction with a SATM enabled VS
110.
o Automatic Data Exchange (ADE) If the UE 150 is enabled with any means of local wireless connectivity such as Bluetooth 116, Wireless LAN (802.11 and so on) 118 or Infrared 116 (IrDA for example), the data exchange can be conveyed through this local connectivity.
With this, VS 110 can exchange data that it needs with the SC 170 to fulfill as transaction and the user only plays supervisory role to confirm or decline the transaction when needed.
General Block Diagram Figure 1 depicts the block diagram and the main elements of the system in UADE
scenario.
Description Description of the main elements Messaging The main messages that are exchanged between VS 110 and the SC 170 to fulfill a SATM transaction are:
o Transaction Id (T1D 125) from VS 110 to SC 170 o Confirmation Id (CBS 126) from SC 170 to VS 110 TID 125 consists of the following fields:
1. Merchant Id 210 2. Vendor Station Id 210 3. Price 220 4. Language 230 5. Error Correction (e.g., CRC) 240 The elements of C>T7 126 (Confirmation 1D) are as follows:
1. Message (encrypted) 250 2. Error Correction (e.g., CRC) 260 For the "user assisted data exchange" model, we have limited the TID 125 to 7 digits and CID 126 to 4 digits, for user convenience.
Figure 2 illustrates the byte description of T1D 125 and CII? 126.
Figure 3 depicts the Success path use case. Following remarks are in order for Figure 3:
~ This is a simplified use case for the success path, and for the UADE mode.
Some changes would be necessary for the ADE mode (for example, the UE 150 itself can check for the CRC).
~ ,: The message from SC 170 to UE 150 in UADE mode is a voice or SMS message, as this configuration necessitates no change in the UB, and virtually every UE
can use the system without any modification. In case of voice, the message would read the CII? 126 digit by digit and then after a short silence (of about 10 seconds) it repeats itself several times. In ADE the CB7 126 will automatically be transmitted from SC 170 to VS 126 without much user interaction or even Description knowledge (in IR 116 mode, the user may be asked to keep the UE 150 in a reasonable distance and direction to the VS 110).
~ As we will see for the billing system later, the transaction waits for a predetermined time (about 10 minutes, for instance) before the user account is charged. This gives the user opportunity to cancel thc; requested service, in case of error or in the case user changes his/her mind.
Figure 4 depicts the Simplified Failure path use case.
It is obvious that there are several different reasons for a failure. Below we explain some of the main failure cases:
1. If SC 170 finds that CRC is not correct (this can be either because of a punching error of TID 125 by the user or any simple communication error), the user is asked to re-enter the TID 125.
2. One reason for a failure can be "out of sync." If the encryption in the VS
110 is not in sync with the one in SC 170, then this failure is detected. In such a case, the VS 110 would become obsolete. Emergency message should be sent to the responsible department to make them in sync again. A message might be sent to the SC 170 to temporarily put the VS 110 out of use.
3. If the billing system can not identify the user, or that the user has not enough cash/credit to perform the transaction, a failure should be generated that would be understood by the VS 110 and appropriate message would be screened.
4. If the VS 110 detects that the message is not right (either the CRC is not correct, or the message is not among the allowed messages), the user would be asked to repeat the process of entering TID 125 and CID 126. If this problem occurs more than a predetermined number of times, the transaction should be cancelled by giving a special canceling TID 125 to the user; when the user enters this code, the transaction would be cancelled and the user will not be billed for this transaction.
5. If the VS 110 receives the CID 126 but at this time learns that for some reason, it can not provide the service or release the product, the same cancellation TID
mechanism will be applied. Of course, to guarantee a good user experience, the probability of such an event should be kept minimum.
Description Language selection Accommodating several languages in the system, would allow it to be more appealing for places where more than one language are spoken (like many regions in Europe, Canada, and countries with a high immigration rate) and also places with a large number of visitors (who may speak different languages). A simple example in Canada is the two official languages: English and French.
To accommodate this requirement, all we need is a human interface (keys, for example) to choose the language. In later versions, this can also be done as a preset or provisioned parameter inside the cell phone (or the PDA) which is set by the user 140 once at subscription time and is always used as his/her language preference, till helshe proceeds to change it.
To accommodate two languages, we only need b=1 bit and this is what we can do for several situations, including the Canadian context, where two official languages exist. In general, to accommodate L languages, we need b =
ceil(log2(L)) bits, where ceid(.) denotes the ceiling function and loge is the logarithm in base 2. As an example, with just three bits, we can accommodate up to eight languages.
For instance, in a North American context, these eight languages constitute:
English, French, Chinese, Spanish, Arabic, Persian, Russian, and Korean. In a Western European context, it can be English, French, German, Spanish, Italian, Portuguese, and Greek and in a Middle-Eastern context, it can be:
Arabic, Turkish, Persian, Kurdish, Azeri, Hebrew, English and French, or any other combination of languages.
It is obvious that the choice of the languages is completely reconfigurable by the operator. The number of possible languages can also be eight, more than eight, or less than eight. The choice of eight here is based on a reasonable design, but does not Iimit us in any other choice in the future.
So the user 140 selects the language (or goes with the default language).
Based on this choice, necessary bits are generated in the VS 110 and transmitted to the SC 170. All the consequent messages, either voice or text, including the optional advertisement 115, will be delivered in the chosen language from both VS 110 and SC 170 sides.
Description Coding and security In order to ensure the integrity and security of each transaction, and the system in general, the transmitted messages have to be encrypted. Since there is no direct connectivity between the VS 110 and SC 170, user 140 or user's equipment 150 has to convey the messages between VS 110 and the SC 170. In the case that the user's equipment 150 is limited to voice functionality, the user 140 will punch in the TID 125 into the I1E 150 and then received CID 126 from the L1E 150 into VS 110 via keypad. To maintain a good user experience, TID 125 is limited to 7 digits and ClT7 I26 is limited to 4 digits. Normal approaches to encryption can not be applied to this scenario because they all tend to use a large key (between 40-128 bits) which will make TID 125 and CID
126 too large for a user 140 to punch on keypad 107. Hence, this design uses an Order Synchronized Code (OSC 500) to encrypt Tm 125 excluding the VSId 210 filed and the CID 126.
The following rules govern the encryption/decryption of the messages:
a In TID 125, merchant ID 210 is sent as plain text (without encryption).
o In TID 125, Price and CRC/Language is encrypted.
o An OSC 500 is used as the key for encryption.
o SC 170 maintains a synched OSC 500 per provisioned VS 110.
a For maintaining security, SC's OSC 500 peer 760 performs a look ahead for the next r~LA codes to find a match.
Transaction Security by Order Synchronized Code (OSC 500) The design is based on a seven digit OSC 500 that is generated every time a new transaction is to be fulfilled. This OSC 500 is generated both in the VS 110 and at the SC
I70 and they are kept synchronized on the order of the transactions, i.e., for the first transaction VS 110 and SC 170 generate the same OSC 500 and for the second and so on.
The system is based on two identical pseudo random number generators with seed at the VS 110 and SC 170. In the SC 170 for each VS 110 ax OSC 500 maintenance peer (OMP) 760 is created and maintained in synch upon provisioning of that VS 1I0.
To ensure that VS 110 and SC 170 are kept in synch and don't fall out of synch, the SC 170 attempts to look ahead (or depending on the implementation, can be look behind) nLA
(number of Look Ahead) codes to find a match.
Description Figure 5 illustrates the OSC 500 as a 7 symbol long code.
The last 3 digits of the OSC 500 are used as a key to encrypt the Price, CRC
and Language code part of the TID 125 at the VS 110 and the same code should be used to decrypt the TID 125 at the SC 170 and the first 4 digits are used to encrypt CID 126 at the SC 170 and again decrypt it at the VS 110. The probability of repeating a TID 125, CID 126 combination p is calculated as:
_ nLA
p nS mlenOSC
y With assuming ZenOSC = 7 and nLA = 32, there is about 1 in 10 million chance that the same TID 125, CID 126 combination is generated by the system for each VS 110.
(nSym is assumed to be 12 and is the number of symbols on the keypad 107 which includes "0"-"9" "*" and °°#"~.
A potential delinquent who wishes to use the system in a phony way, may want to enter a random number as CID 126. Below, we calculate the chance for this CID 126 to be the right one which will lead the VS 110 to release a product or to provide a service.
nSym =12 nChar = 4 pfraud = 1/nSym "C~'~r= 1/124 = 1/20736 = 0.000,048,225 with nSym equal to 10, the value becomes simply 0.0001.
Description Error detection Cyclic Redundancy Check (CRC) is used as a means of error detection in both the TID
125 and the CID 126. A Frame Check Sequence (FCS) is calculated on the information bits and transmitted as redundant bits along with the information bits.
For TID 125, one digit is reserved for FCS, which provides more than 4 bits.
For C1D 126, three digits constitute the message, and again one digit is reserved for FCS.
The whole four bytes are then encrypted.
Figure 6 and 7 and describe the overall encryption and error detection mechanism in the system.
Description User interface Figure 8, 9, 10 and 11 illustrate an exemplary arrangement of the user interface of the system. Although the user interface can be built in other ways and using other shapes and form factors of keypad 107 and display 106 as well as keys and buttons 930, 940.
Description Billing The Billing Proxy in the SC 170 is in direct secure contact with the billing system 1220 that is provided by the billing provider. The billing provider can be one or a combination of the followings:
o The Wireless Carrier In this case the wireless carrier provides the billing service. The charges for the products/services that the subscribers purchase will be applied to the existing wireless service account that they already have established for their wireless service. If this option is opted, subscribers don't need to register and sign up for SATM service since they axe already known to the billing system.
o A financial institution A financial institution can be designated as the billing service provider.
This is probably the most extensive option for billing since the possibility of deploying the service over a broad range of products and services is much higher. An example of this scenario can be thought linking the subscribers' credit card account to their SATM service which conveniently charges all the purchases made by their mobile UE 1S0 to their credit card account. Another example can be a financial institution that charges user's checking account.
o The Vending Station o~eratin entity The firm that is operating the chain of VS 110 can act as the billing service provider. One condition in this case is that all the wireless service users that Iike to use this service, need to register with the billing service provider.
a The ~roductlservice man~acturer~rovider In this scenario the provider of the product or service that is being offered by SATM enabled VS 110 is providing the billing service.
Description Figure 12 is a diagram that shows how the billing service provider 1220 interacts with SC
170.
The billing service provider 1220 can reply back to a "charge account" 1230 request with one of the following reply codes 1240:
OK Charge applied NSF Not Sufficient Fund UU User Unknown GF General Failure To handle cancelling a transaction properly, the billing system keeps the billing record for a specified amount of time (ballihgDelay) before it applies the charge to the user's account. This delay allows the user to cancel the transaction. An example value for billingDelay can be set to 10 minutes and the billing system periodically visits the unapplied charge record and applies them if they are older than the billingDelay.
Description Automatic data exchange mode In this mode, the UE 150 and VS 110 have a local wireless way of communication and the need for the user to punch in the T117 I25 and then the CID 126 would be eliminated. The communication between the UE 150 and VS 110 can be but not limited to any of the followings: infrared (IR) 1I6, Bluetooth (BT) 117 or wireless LAN (such as 802.11 series) 118.
The first consequence of the automatic messaging is that the number of bytes (or digits) that are used in messaging can be more since there is less limitation by the user experience constraints and user typing errors.
In such a case, the following information can also be transmitted from VS l I0 to the SC 170:
1. More bits for language selection.
2. More bits for CRC to further decrease the osk of error (or even Reed-Solomon error correction can be used instead of CRC).
3. More bits for Merchant ID 210 and Vendor ID 210 (so the possibility to give the service to a bigger area).
4. More bits for the price (so the possibility of having more dynamic range and/or having more precision).
5. Possibility of transmitting an Initialization Vector (IV) for the encryption.
6. Possibility to transmit the inventory information (or any other information) directly from VS 110 to the SC 170.
7. Possibility to transmit the advertisement information, provisioning (or any other information) directly from SC 170 to the VS 110.
If we use the IV, then the encryption scheme would be simplified, and the need for synchronizing the encryption systems in VS 110 and SC 170 will be eliminated.
This is done by breaking the main encryption key into two parts: the constant key and IV.
The IV is sent in plain text to the SC 170 and then the two systems use the main key.
So each time a completely different key would be used and the encryption will be totally different.
In a similar manner, the CID 126 can also be expanded to include the following messages:
Description 1. More messages from SC to VS 110 (rather than limiting to a few such as "O.K.", "NSF", "W" and "GF"). This would be messages such as "lock", "give-a-prize" and other commands.
2. More bits for CRC to further decrease the risk of error (or even Reed-Solomon error correction can be used instead of CRC).
3. Advertisements or any other type of data or information, to be displayed for the used, either on his UE 150 or the VS 110.
In this configuration, the UE 150 should be equipped to run a special program when dealing with this application. SMS or other means of data connectivity between the UE 150 and the SC 170 can be used for messaging, instead of voice or in parallel to voice. ITE 150 can also make use of CRC check 145 to detect some errors earlier.
If we use the IV, then the encryption scheme would be simplified, and the need for synchronizing the encryption systems in VS 110 and SC 170 will be eliminated.
This is done by breaking the main encryption key into two parts: the constant key and IV.
The IV is sent in plain text to the SC 170 and then the two systems use the main key.
So each time a completely different key would be used and the encryption will be totally different.
In a similar manner, the CID 126 can also be expanded to include the following messages:
Description 1. More messages from SC to VS 110 (rather than limiting to a few such as "O.K.", "NSF", "W" and "GF"). This would be messages such as "lock", "give-a-prize" and other commands.
2. More bits for CRC to further decrease the risk of error (or even Reed-Solomon error correction can be used instead of CRC).
3. Advertisements or any other type of data or information, to be displayed for the used, either on his UE 150 or the VS 110.
In this configuration, the UE 150 should be equipped to run a special program when dealing with this application. SMS or other means of data connectivity between the UE 150 and the SC 170 can be used for messaging, instead of voice or in parallel to voice. ITE 150 can also make use of CRC check 145 to detect some errors earlier.
Claims (20)
1. Non connectivity of the VS 110: We provide a system where there is no need for the VS 110 to be directly connected to the SC 170. The connection takes place through the user's UE 150 connection, and necessary information is exchanged.
2. No need for extra user registration, but not restricted to.
3. Use of Order Synchronized Code for authentication and authorization.
4. Use of language selection on the VS 110.
5. Selecting the product or service before the payment is processed.
6. Claim on the possible applications: vending machines, video rentals, coffee machines, fast food, cinema, sport facilities, laundries, copy machines, fax machines, Internet nodes, automatic photo taking machines, gas stations, carwashes, toll highways, bus, tramway and metro ticket sellers, taxi payments, game consuls, public washrooms, change machines, relaxation, massage and oxygen machines, donations, and any other place with enough similarity to these applications.
7. Using the billing system of the wireless career.
8. Cancellation mechanism as described in the disclosure.
9. Use of PDA as the platform and the main user interface on the VS 110.
10. Use of any means of wireless connectivity such as a PDA with Wide Area Networking connectivity as an alternative method of payment, instead of the cell phone.
11. Use of SMS to exchange messages between UE 150 and the SC 170.
12. Use of error correction and error detection in the transmissions taking place in the system.
13. Inventory and maintenance information transmission over the UE 150.
14. Use of text to speech for the SC 170 or the VS 110 to interact with the user.
15. Use of voice commands (speech recognition).
16. Use of PIN number or speaker recognition authentication for larger amounts.
17. Use of user confirmation in the ADE scenario.
18. Length and pattern of the messages.
19. Possibility of sending commercial messages to the user on the VS 110 or UE
based on the location of the user and user's profile.
based on the location of the user and user's profile.
20. Possibility of downloading configuration, and other data to the VS 110 or to the mobile device.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2418638 CA2418638A1 (en) | 2003-02-11 | 2003-02-11 | System and apparatus for small amount transaction by mobile |
| CA 2457263 CA2457263A1 (en) | 2003-02-11 | 2004-02-11 | System facilitating a purchase transaction over a wireless network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2418638 CA2418638A1 (en) | 2003-02-11 | 2003-02-11 | System and apparatus for small amount transaction by mobile |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2418638A1 true CA2418638A1 (en) | 2004-08-11 |
Family
ID=32831590
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2418638 Abandoned CA2418638A1 (en) | 2003-02-11 | 2003-02-11 | System and apparatus for small amount transaction by mobile |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2418638A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8249920B2 (en) | 2000-04-07 | 2012-08-21 | Zyzeba Holding Limited | Interactive marketing system using short text messages |
| US8977559B2 (en) | 2000-04-07 | 2015-03-10 | Zyzeba Holding Limited | Interactive marketing system |
| US10127364B2 (en) | 2015-04-13 | 2018-11-13 | Carwashfinder Inc. | Managing authorization codes from multiple sources |
-
2003
- 2003-02-11 CA CA 2418638 patent/CA2418638A1/en not_active Abandoned
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8249920B2 (en) | 2000-04-07 | 2012-08-21 | Zyzeba Holding Limited | Interactive marketing system using short text messages |
| US8380566B2 (en) | 2000-04-07 | 2013-02-19 | Zyzeba Holdings Limited | Interactive voting or survey |
| US8977559B2 (en) | 2000-04-07 | 2015-03-10 | Zyzeba Holding Limited | Interactive marketing system |
| US10127364B2 (en) | 2015-04-13 | 2018-11-13 | Carwashfinder Inc. | Managing authorization codes from multiple sources |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1922681B1 (en) | Mobile account management | |
| AU780943B2 (en) | Method of payment by means of an electronic communication device | |
| Schwiderski-Grosche et al. | Secure mobile commerce | |
| EP0794651B1 (en) | Method of prepayment for usage of telephone communications | |
| US7072854B2 (en) | Payment system by means of a mobile device | |
| EP2139218A1 (en) | Method and system for managing a purchase decision taken by a purchaser using a mobile radiotelephone | |
| EP3195226B1 (en) | System, method and apparatus for updating a stored value card | |
| EP0972275A2 (en) | Use of banking services in a digital cellular radio system | |
| US20040158534A1 (en) | System facilitating a purchase transaction over a wireless network | |
| US20120116978A1 (en) | Method of and system for securely processing a transaction | |
| WO2002065414A1 (en) | Telepayment method and system | |
| JP2001527247A (en) | Portable one-way wireless financial messaging unit | |
| EP1178450A3 (en) | Real time tele-payment system | |
| AU2002365333B2 (en) | Method for registering and enabling PKI functionalities | |
| US20160026991A1 (en) | Mobile account management | |
| WO2004049621A1 (en) | Authentication and identification system and transactions using such an authentication and identification system | |
| US20110238513A1 (en) | Method and system for validating a transaction, corresponding transactional terminal and program | |
| EP1739629A1 (en) | Procedure for automatic payment of a franking service | |
| EP1242983B1 (en) | A system for recharging a prepaid value in respect of a telephone connection | |
| CA2418638A1 (en) | System and apparatus for small amount transaction by mobile | |
| CA2457263A1 (en) | System facilitating a purchase transaction over a wireless network | |
| WO2001006747A1 (en) | Method and system for identifying a juridical person | |
| CN114548980A (en) | Double-off-line transaction instant confirmation method and system based on digital certificate | |
| WO2001091410A2 (en) | Method for authentication of clients for proof of claim to a service, and system and computer product implementing the method | |
| ES2170647A1 (en) | Payments transaction processing system installed in point-of-sale terminal, selects specified telecommunication equipment based on information of mobile telephone verified using specified telephone number |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |