WO2009070114A1

WO2009070114A1 - A server of a check issuer and a merchant system in a proximity payment system

Info

Publication number: WO2009070114A1
Application number: PCT/SE2008/051368
Authority: WO
Inventors: Frans Lundberg
Original assignee: Skycash Sp.Z O.O.
Priority date: 2007-11-30
Filing date: 2008-11-27
Publication date: 2009-06-04

Abstract

Electronic checks for proximity payments are issued by one or more check issuers. The electronic checks can be used with ordinary mobile phones without installing custom software. An electronic check is generated by a check issuer when a customer visits a certain web page with his mobile phone. A secure check reference, linked to the electronic check, is displayed on the mobile phone in the form of a bar code. The bar code is scanned by a merchant using a bar code reader. The merchant sends the information acquired from the bar code to the check issuer to enable a payment from the customer to the merchant. The secure check reference contains verification data to avoid forgery. To achieve high security, the electronic check can only be used once. Also, it can only be used for a limited payment amount and only within a short period of time after it was created.

Description

A SERVER OF A CHECK ISSUER AND A MERCHANT SYSTEM IN A PROXIMITY PAYMENT SYSTEM

FIELD OF THE INVENTION

The present invention relates to proximity payments, and more particularly to proximity payments using mobile phones.

BACKGROUND OF THE INVENTION

Discussion of Prior Art

Several technologies exist that can be used to perform proximity payments with mobile phones. One such technology is Near Field Communication (NFC). Visa and MasterCard both have solutions based on NFC, but in contrast to the present invention, the information sent using NFC is data roughly equivalent to the data stored on a credit card. The systems are called PayPass [1] and pay Wave [2], for MasterCard and Visa, respectively. According to a report [3] from Juniper Research [4], 52 million mobile phones will support contactless chip connections (such as NFC) in 2011. This is a small fraction of the total number of mobile phones in use. There are over three billion mobile phones in the world, according to The Mobile World [5].

Bluetooth communication is another technology that can be used for proximity payments with mobile phones. One company that offers a Bluetooth-based proximity payment system [6] is Swedish Internet Payments Ltd [7]. Bluetooth have two major drawbacks, the first is that only a fraction of the mobile phones in use today supports Bluetooth. The other drawback is that it can take a long time to establish a connection between two Bluetooth devices previously unknown to each other. This fact increases the payment time significantly.

Infrared communication is yet another technology possible to use. However, this technology is becoming obsolete on mobile phones as Bluetooth gains popularity.

Some payment solutions use the camera of a mobile phone to take a picture of a bar code. This allows the payer to receive information needed to conduct a payment, such as identification of the receiver and the amount to be paid. These solutions cannot be used on all mobile phones, since not all mobile phones have a camera. Another limitation is that advanced custom mobile phone software is required to extract the bar code data from the pictures taken with the camera of the mobile phone.

Even though technologies such as Bluetooth, NFC and mobile phone cameras have been around for a few years, the majority of mobile phones does not support all or even any of these technologies. Another problem with payment systems that employ these technologies is that they require custom software that has to be installed on the mobile phone. This reduces the usability of the system significantly, since the installation process is complicated to many mobile phone users. Due to differences between mobile phone models, different pieces of software may be required for different mobile phone models. This makes it difficult and expensive to develop and maintain the software. It also complicates the installation process, since the user must choose the correct version of the software for his mobile phone.

Below, three patents or patent application are discussed. These proposed systems use fixed bar codes that contain personal data, credit card data, or data to identify a person. The first system, found in patent WO02086785 [8], uses customer-specific bar codes to identify a customer, prior to making payments. After identification using a bar code, the customer makes a payment by supplying a password, through for example a terminal connected to the merchant system. US patent 6,854,651 [9] describes a method for non-persistently displaying one of a plurality of stored personal data items through the use of bar codes. The third system is the one described in WO2003023674 [10]. This is a system for credit card payments using bar codes. In this solution the information required for a credit card payment is stored on a mobile phone, and then transferred to the merchant using bar codes. The problem with these three proposed systems is that they use bar codes that do not change over time, and therefore pose a security risk as the data can be captured and re-used by an attacker.

Using bar codes on mobile phone screens is nothing new. For example, there are several systems that use bar codes to display previously purchased tickets stored on the mobile phone. Some of the existing systems and methods can be found in US 6,916,244 [11], US 7,004,388 [12], US 7,028,906 [13], and US 6,736,322 [14].

US patent applications 20070244811 [15] and 20070255653 [16], use bar codes to identify the payer or the receiver of a payment. The bar codes are also used to enable merchants to accept payments from previously approved customers, by scanning the bar codes. The use of bar codes mentioned in these patent applications fails to achieve a high level of security offered by the present invention.

Another patent application from the US 20070130085 [17], relates to authenticating a customer for payments or similar services by connecting the phone to an "access server" that generates a random ID verification code. This code is sent back to the mobile phone, for instance using an SMS, and subsequently communicated from the mobile phone to the merchant, using a bar code or any other method for short range data transfer. The merchant then connects to the access server that verifies that the code received from the merchant and the one previously sent to the mobile phone match. If the codes match, the user is authenticated. In the solution proposed in US 20070130085 [17], the customer is required to supply personal information to a "transaction terminal" described in the application.

The method suggested in patent application US 20070130085 [17] relies on randomly generated IDs that are compared with each other. This means that a payment conducted using the method in US 20070130085 [17] has to be done in at least two steps, first the identification and then the payment. Several round trips means increased delays and increased user interaction.

In conclusion, many prior art systems for proximity payments using mobile phones depend on technology not available on the majority of the mobile phones used today. Also, these solutions often require the user to install custom software in order to start using the system to perform proximity payments. There are solutions for proximity payments with mobile phones that use bar codes as means of communication between the payer and receiver, but these solutions do not achieve the required degree of ease of use, security, and/or support for the vast majority of existing mobile phones.

SUMMARY OF INVENTION

One object of the present invention is a proximity payment system for mobile phones that works on nearly all mobile phones in use today.

Another object of the invention is a proximity payment system for mobile phones that works without installing any custom software on participating mobile phones.

Another object of the invention is a proximity payment system that is easy to use for the average customer.

Another object of the invention is a proximity payment system that is fast.

Another object of the invention is a proximity payment system for mobile phones that is secure even though the mobile phone is stolen.

Another object of the invention is a proximity payment system for mobile phones that is secure even though the receiver of the payment is malicious.

Another object of the invention is a proximity payment system that allows the customer to choose between a number of different payment service providers and still have a system that works at all participating merchants independent of which payment service provider the customer chooses to use.

The invention relates to a server of a check issuer for use in a proximity payment system, said check issuing server being arranged to: upon receiving a check request from a customer, create an electronic check and a secure check reference, wherein the secure check reference comprises data to identify the electronic check and data to verify the authenticity of the secure check reference; provide said customer with said secure check reference encoded in a bar code; receive a request of a payment from a merchant system to which said secure check reference encoded in a bar code has been provided by said customer; and if said request of a payment is at least partly based on said secure check reference, validate a payment with said electronic check using said part of said secure check reference in said request of a payment.

The invention also relates to a method for use in a server of a check issuer in a proximity payment system, comprising the steps of: upon receiving a check request from a customer, creating an electronic check and a secure check reference, wherein the secure check reference comprises data to identify the electronic check and data to verify the authenticity of the secure check reference; providing said customer with said secure check reference encoded in a bar code; receiving a request of a payment from a merchant system to which said secure check reference encoded in a bar code has been provided by said customer; and if said request of a payment is at least partly based on said secure check reference, validating a payment with said electronic check by using said part of said secure check reference in said request of a payment.

The invention further relates to a merchant system for use in selling merchandise to a customer, comprising a bar code reader and an internet connection, being arranged to: receive a secure check reference, said secure check reference comprises data to identify an electronic check and data to verify the authenticity of said secure check reference, encoded in a bar code from said customer using said bar code reader; send a request of a payment which is at least partly based on said secure check reference to an server over said internet connection.

The invention further also relates to a method for use in a merchant system comprising the steps of: receiving a secure check reference, said secure check reference comprises data to identify an electronic check and data to verify the authenticity of said secure check reference, encoded in a bar code from said bar code reader; sending a request of a payment which is at least partly based on said secure check reference to a server over said internet connection.

Using the present invention, the vast majority of today's mobile phones can be used to perform fast and secure proximity payments without the need for any special payment software. A customer visits a certain web page using the browser of his mobile phone. After the web server has authenticated the customer, an electronic check is created and stored on the server. The check is valid for payments from the customer during a limited time and for a maximum payment amount. A secure reference to the electronic check is created and a dynamically generated bar code containing the secure check reference is shown on the web page visited by the customer. The secure check reference contains information to identify the electronic check and the issuer of the check. Further, the secure check reference contains verification data to avoid forgery.

The bar code displayed on the screen of the mobile phone is shown to the merchant, who uses a bar code reader to scan the bar code to acquire the secure check reference. The merchant then connects over the Internet to the issuer of the check. If the secure check reference is valid, the corresponding electronic check has not expired, and the amount is less than or equal to the maximum amount of the check, the request by the merchant results in an electronic payment from the customer to the merchant. The payment system presented in this document is fast and easy to use. The actions required by the customer to make a payment is to visit a web page using his mobile phone and to show the generated bar code to the merchant.

A proximity payment system according to the present invention relies only on the built-in web browser of mobile phones, and therefore has a significant advantage in terms of ease of use, as no custom software installation is required. Most mobile phones have a built-in web browser.

The invention use dynamically generated bar codes that contain no personal data and that are only valid for a limited period of time.

An important feature of the invented system is that secure check references do not contain any personal information, and the electronic checks are valid only for a short period of time and for a maximum payment amount. Each check can only be used once. These security features give the user protection against frauds such as replay-attacks, where the same payment information is used several times to attempt several payments.

Previous solutions do not provide the high security offered by the present invention. This is because the bar codes are not dynamically generated, making them vulnerable to replay- attacks. Furthermore, the amount that can be withdrawn using the bar codes is not limited, so the customer has to trust every merchant not to charge more than the customer intended.

The invention further also relates to a computer program product for use in a server of a check issuer which comprises computer readable code means, which when run in a processing unit in the server of a check issuer causes said server of a check issuer to perform the steps of: upon receiving a check request from a customer, creating an electronic check and a secure check reference, wherein said secure check reference comprises data to identify an electronic check and data to verify the authenticity of said secure check reference; providing said customer with said secure check reference encoded in a bar code; receiving a request of a payment from a merchant system to which said secure check reference encoded in a bar code has been provided by said customer; and if said request of a payment is at least partly based on said secure check reference, validating a payment with said electronic check by using said at least part of said secure check reference in said request of a payment. The invention further also relates to a computer program product for use in a merchant system which comprises computer readable code means, which when run in the a processing unit in the merchant system causes said merchant system to perform the steps of: receiving a secure check reference, said secure check reference comprises data to identify an electronic check and data to verify the authenticity of said secure check reference, encoded in a bar code from said bar code reader; and sending a request of a payment which is at least partly based on said secure check reference to a server of a check issuer over said internet connection.

Further advantageous embodiments of the server, the merchant system, the methods and the computer program products are set forth in the dependent claims, which correspondently describe further advantageous embodiments of the present invention.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows the major components of the payment system and an example of a secure check reference that is: created by a check issuer, downloaded to the mobile phone of a customer, displayed on the mobile phone, scanned with a bar code reader, and then sent to the check issuer to enable a payment.

FIG. 2 shows an example of a web page where the customer enters information required for authentication and information required to generate an electronic check.

FIG. 3 shows an example of a web page with a bar code containing the secure check reference. The web page is displayed on a mobile phone.

FIG. 4 shows an example of a bar code that contains three different parts: digits to identify the check issuer, digits to identify the electronic check, and verification digits used to prove the authenticity of the secure check reference.

FIG. 5 shows an example of an electronic check and a corresponding secure check reference.

FIG. 6 shows a proximity payment system comprising a check issuing server, a customer database, a check database and a merchant system according to an embodiment of the invention.

FIG. 7 is a signaling diagram according to an embodiment of the invention. FIG. 8 is a signaling diagram according to further embodiment of the invention.

FIG. 9 is a flowchart of a method according to an exemplary embodiment for use in a check issuing server and/or a check database according to the invention.

FIG. 10 shows a check issuing server according to an embodiment of the invention.

FIG. 11 is a signaling diagram according to a yet further embodiment of the invention, and shows how an external monetary transfer system interacts with a check issuing server and a merchant system.

TERMINOLOGY

The terms defined below are useful for describing the present invention and prior art. Some of the terms are generally used, while some are defined particularly for this document.

OCR or Optical Character Recognition is the translation of images of characters into machine- editable characters stored digitally.

A bar code is a machine-readable representation of information that can be read using optical methods. Originally, bar codes typically stored data in the widths and spacings of parallel lines, but today they also come in, for example, patterns of dots or concentric circles. Examples of bar code types include EAN- 13, Code 128, PDF417, and QR codes. In this document, the definition of a bar code extends to include a series of characters meant to be read by OCR methods.

A bar code reader is a device capable of scanning bar codes to acquire the data stored in them.

A proximity payment is a payment conducted at a short distance between the payer and the receiver of the payment. A common type of a proximity payment is a payment from a customer to a merchant in a grocery store.

A proximity payment system is a payment system that handles proximity payments.

In this document, a secure check reference is data used to identify an electronic check. This term is further explained in the detailed description of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention comprises the generation of an electronic check by a check issuer, a secure reference to that check sent to the customer as a bar code, the bar code being scanned by the merchant using a bar code reader, and the merchant using the secure check reference to make a payment from a customer to a merchant by connecting to the issuer of the customer.

Generating the Check

The invented payment system employ electronic checks to make payments. Each check is issued by a check issuer. The customer requests the creation of a check by connecting to his check issuer using the web browser and the Internet connection of an ordinary mobile phone. In this description, it is assumed that the customer has a previous business relationship with his check issuer that provides the check issuer with the ability to make an electronic payment from the customer to the merchant.

The process of making a payment from a customer to a merchant in a store is initiated by the customer by requesting the creation of an electronic check. This can be done in advance, up to ten minutes before the actual payment is to take place assuming checks are valid for ten minutes. The customer can create the check when he walks around in the store, when he arrives at the check out line, or when the cashier starts to sum the prices of the merchandise. The request to create a check is made through the web browser on the mobile phone of the customer. The customer visits a certain web page provided by the check issuer. The customer either enters the web address of the web page manually, or uses a stored bookmark to direct the web browser to the specific web page.

The preferred embodiment of the present invention uses the web browser of a mobile phone to request the creation of a check and to display a generated bar code. In an alternative embodiment, custom software is instead used to make the request and to display the bar code.

The next step in the process is to authenticate the customer to the web server of the check issuer. The check issuer or more specific the web server of the check issuer may also be referred to herein as a check issuing server. Authenticating a client visiting a web site can be done in a number of ways. Which way that is used is not of importance to the rest of the payment system and is not part if the invention. There are several prior art methods of authenticating a client to a web server and a web server to a connecting client. One way of authenticating a client visiting the web site is to use a client certificate. A more common way is to use identity information (typically user name, email address, or user identification number) plus a password or a pin code. FIG. 2 shows an example of that. The figure shows a web page that asks the customer to enter his secret pin code in order to authenticate himself to the web server.

In one embodiment of the present invention, the mobile phone number of the connecting customer is automatically detected by the mobile phone operator that provides the Internet connection to the mobile phone. The mobile phone number is made available to the check issuer to be used for identification and/or authentication of the customer. In another embodiment, a browser cookie is used to identify the customer to avoid the need to enter the mobile phone number each time a payment is to be made. Browser cookies can also be used as part of the authentication of the customer.

In one embodiment of the present invention, the security of the authentication of a customer is increased by adding identification using an identity card. The customer must show a valid identity card to the merchant to be able to proceed with the payment. The identity card must match the account holder of the account from which the payment is to be made.

In one embodiment of the present invention, the customer is able to use the web browser of his mobile phone to immediately register for the payment service with one of the check issuers if the customer is not already a registered customer.

An optional step that can be made before the check is created is to allow the customer to choose options for the check to be generated. For example, the maximum amount and the expiry time may be chosen by the customer before the check is generated. FIG. 2 shows a web page that combines user authentication and the customer option of choosing the maximum amount of the check to be generated. In FIG. 2 it is assumed that the identity of the customer is known to the server already (for example from a browser cookie or from a previous web form).

Once the customer has chosen check options and authenticated himself to the web server, an electronic check is generated and stored by the check issuer of the customer. FIG. 5 shows an example of an electronic check. The generated check contains at least: a check identification number (CheckID in FIG. 5), a customer identification number (CustomerID), a check state (State), a maximum amount (Max Amount), an expiry time (ExpiryTime), and randomly chosen verification data (VerData). The check identification number is a unique number used to identify an individual check among all checks stored in the database of the check issuer. The customer identification number is a unique number of each customer of the check issuer. The check state is either "used" or "unused" depending on whether the check has been used to make a payment or not. The maximum amount of the check is the maximum amount that can be paid using the check. Any payment amount less than or equal to the maximum check amount can be paid using the check. Once the check has been used, the check state will be "used" and the check can not be used again, independent of however small amount that was actually paid using the check. The expiry time of the check is used to limit the validity period of the check. After the expiry time has passed, the check can no longer be used to make a payment. The verification data is randomly chosen data stored in both the electronic check and in the corresponding secure check reference.

Used checks are marked with a check state of "used" instead of being removed from the database immediately. Each check is either available for use (unused and not expired), expired, or already used. Expired and used checks are removed from the system, but only after a period of time. Storing checks that are no longer valid allows the server to tell the difference between a check that has never existed (a forgery), a check that has recently expired, and one that has been used recently.

The Secure Check Reference

When the electronic check is created as described in the previous section, a corresponding secure check reference is also created at the same time. FIG. 5 shows an electronic check with a corresponding secure check reference. This reference contains at least the check identification number (CheckID in FIG. 5) and some verification data (VerData). If the payment system has more than one issuer, an issuer identification number (IssuerID) is typically also included in the reference to identify which issuer issued the corresponding check. The check identification number is the same as the identification number of the corresponding check. The verification data is the same as the verification data included in the corresponding check stored by the check issuer. The secure check reference always contains data to identify the corresponding check and to prove the authenticity of the secure check reference. The check identification number and the verification data could be joined as one piece of data, instead of being encoded in separate pieces of data. The secure check reference is only used to identify and access a previously generated check. No personal information is included in the reference, not even an identification number of the customer.

In one embodiment of the present invention, the payment system has more than one check issuer, and an issuer identification number (IssuerID in FIG. 5) is included in the secure check reference. The issuer identification number is a unique number used to identify the issuer of the check.

In another embodiment, the payment system has more than one check issuer, but the information on which issuer the customer is to use is not stored in the secure check reference. Instead this information is provided by other means, for example by letting the customer manually choose an issuer using a device connected to the merchant system.

The previous section describes how a customer requests the creation of a check through the web browser of his mobile phone. The check is created and a corresponding secure check reference is also created by the server. The reference is then encoded in a bar code and shown on a web page visited by the customer. FIG. 3 shows an example of such a web page displayed on a mobile phone. In the figure, an EAN- 13 type of bar code is used to encode the secure check reference, but other embodiments may of course use other types of bar codes. The web page in the figure also includes the expiry time and the maximum amount of the check corresponding to the reference.

In one embodiment of the present invention, the bar code is divided into a three separate blocks of digits as shown in FIG. 4. Block A (digits 731) in the figure is used to identify the check issuer, Block B (digits 0861) is used to identify the check, and Block C (digits 00179) is used to verify the authenticity of the secure check reference. The last digit (9) is the checksum digit mandatory for EAN- 13 bar codes.

In another embodiment, the bar code consists of a series of characters. The characters are then scanned by OCR methods instead of using conventional bar code methods. The check issuer generates the verification data of the secure check reference and stores this data along with the rest of the check information. For a secure check reference and the corresponding check to be valid, both the check identification and the verification data has to match an existing, unused, and not expired check stored by the check issuer. The use of the verification data makes it unfeasible for someone to guess the secure check reference corresponding to a valid check in order to perform an unauthorized payment.

Using the Check

Using an electronic check in the invented payment system is fast and easy to do, both for the customer and the merchant. The customer visits a web page to generate a bar code that is displayed on his mobile phone. The mobile phone is shown to the merchant who scans the bar code. The merchant system connects to the check issuer of the customer and the secure check reference scanned from the bar code is used to enable a payment from the customer to the merchant. The payment does not have to take longer than the time it takes to scan one additional item to be bought.

In one embodiment of the present invention, the first few digits of the bar code contains the identification number of the check issuer. Based on a list of known network addresses (IP numbers, domain names, or complete URLs) to all check issuers, the address of the check issuer of the customer can be found. The merchant system connects to the check issuer using, for example, an HTTPS Internet connection. Alongside the secure check reference received from the customer, the merchant system also sends the amount to be paid and information to identify the receiver of the payment. Several methods may be used to identify and authenticate the merchant to the check issuer and to authenticate the check issuer to the merchant. One example is to use a username with a corresponding password to authenticate the merchant, and a digital certificate to authenticate the check issuer.

When the check issuer receives the payment request from the merchant, several verifications are made before the payment can be processed. First, the check issuer makes sure the request is syntactically correct and includes all required information. Then the check issuer attempts to match the secure check reference received from the merchant with one of the electronic checks previously generated by the check issuer. If no matching check is found based on the check identification number, the merchant is notified with an error message explaining the situation. Similar error messages are sent to the merchant if the check is found, but either has expired or has been used already.

If the server has a matching check, that has not expired and has not been used, the amount provided by the merchant is matched against the maximum allowed amount specified by the check. If the amount supplied by the merchant is less than or equal to this maximum amount, and the customer has enough funds or credit, the issuer performs the requested payment from the customer to the merchant. Traditional electronic banking systems could be used. Possibly the Visa or MasterCard payment system could be used. Another alternative would be to use an Internet-based payment service such as PayPal.

When the payment has been executed, the check issuer will notify the merchant of this by responding the payment request. In one embodiment, the customer is notified by an SMS sent to his mobile phone. The payment process is now complete.

Payment Example

FIG. 1 depicts this payment example. A customer (C) makes a payment at the local supermarket to a merchant (M). While waiting in the check out line, the customer starts the web browser of his mobile phone and visits the start web page of his check issuer (S731 in FIG. 1). The page presented to the customer is shown in FIG. 2. The customer chooses 20 EUR as the maximum amount of this check, enters his pin code, and then proceeds by clicking on "Create Check".

The request arrives at the check issuer (S731 in FIG. 1), and if the customer is successfully authenticated, a new electronic check (H0861) and a corresponding secure check reference (D0861) are created. The check issuer generates random digits (00179) as verification data. This data is included in both the check and the corresponding secure check reference. The maximum amount chosen by the customer (20 EUR), is stored in the check (H0861) together with check identification number (0861), customer identification number (820503), check state (Unused), expiry time (13:40, 14 November 2007), and verification data (00179). See FIG. 5. The time when the check is created is 13:30 (14 November 2007), so the check is valid for ten minutes. A secure check reference (D0861) corresponding to the secure check is also created. It contains: an issuer identification number (731), a check identification number (0806), and verification data (00179). The web server of the issuer encodes the secure check reference as a bar code. The bar code is sent to the web browser of the customer as a response to a standard web page request. This transport of the bar code is marked with T in FIG. 1. The resulting web page is shown in FIG. 3. Note that the bar code is just a way of encoding the secure check reference. The data that can be read from the bar code is equivalent to the secure check reference.

When the customer reaches the front of the line at the check out register, and the merchandise has been registered by the merchant, the customer shows his mobile phone to the merchant, who scans the bar code displayed on the mobile phone using a bar code reader (R in FIG. 1). This results in a transport of the secure check reference from the mobile phone of the customer to the merchant ('2' in FIG. 1).

The system of the merchant (M in FIG. 1) receives the data from the bar code reader, and looks up the Internet address of Issuer 731 in a table. The merchant system connects to the check issuer and supplies the data received from the bar code scanner (the secure check reference) along with the amount to be paid and the identity of the receiver of the payment (the account number of the merchant). This transport of the secure check reference is marked with '3' in FIG. 1.

The check issuer locates check 0861 and confirms that the validation data stored in the check matches the verification data in the secure check reference received from the merchant. Given that the total price of the merchandise does not exceed 20 EUR, and the check has not expired, the payment is approved and processed by the check issuer. A notification is sent back to the merchant. The customer now has completed the payment process, and receives an SMS including information about the amount and the receiver of the payment.

Multiple Issuers

Like the Visa and MasterCard payment systems, multiple issuers of the payment service are allowed to participate in the invented payment system. The customer can choose among a number of participating check issuers. The issuers may be competitors and offer different services and prices to the customers. Still, the system works, for payments to every participating merchant, independently of which issuer the customer uses.

Security Discussion The present invention is designed to achieve a high degree of security. Secure check references, as described earlier, are critical to avoid forgery and unauthorized payments. With secure check references, once a check has been used, the data contained in the bar code cannot be used by a potential attacker in any way. This is because the secure check reference only refers to a previously generated check, and once this check has been used, the information is useless.

The onetime, time-limited data used in secure check references is more secure to use for payments than the static data on credit cards. An attacker that somehow acquires the data on a credit card (by visual inspection or by a skimming attack), can use the data for payments without restrictions, until the credit of the card reaches the limit, or until the card expires or is invalidated.

If secure check reference data is acquired by an attacker during the short interval between the check generation and the expiration time, the attack is still limited by the maximum amount of the check. Also an attack cannot be made without revealing the identity of the receiver of the unauthorized payment. A bar code must be used within a short time after it is created and the customer receives an SMS that includes the identity of the receiver of the payment.

Even if a mobile phone is stolen, there is little risk of attacks. The account of the customer is still protected by a secret required to authenticate the customer to the web server of the check issuer. This secret is typically a pin code.

The system is secure even though the merchant is malicious. A scanned bar code can only be used once and only for a maximum payment amount. An attempt by a merchant to charge a higher amount than expected by the customer will immediately be detected by the customer when he gets an SMS with the notification of the payment. The merchant may tell the customer that a valid bar code is not valid, in order to trick the customer to create a new bar code. This way, the merchant has two valid bar codes instead of one. Still this does not allow the merchant to charge the customer twice without being detected immediately. The bar codes must be used within a short amount of time. Since the customer gets a notification of all payments, the fraudulent behavior of the merchant will be detected within the short validity time of the generated bar codes.

Some further aspects of the invention are described below. These aspects serve to clarify the underlying payment processes of the invention described above.

7. Customer Database

As shown in FIG. 6 and according to an embodiment of the invention, the check issuing server (65; S731 in FIG. 1), that is, for example, the web server (S731) mentioned above and shown in FIG. 1 arranged to issue electronic checks (H0861) and secure check references (D0861), may comprise a processing unit (66) and memory (67). The processing unit (66) and memory (67) may be arranged to perform the tasks of the check issuing server (65; S731 in FIG. 1) described herein.

The check issuing server (65) may be arranged to be connected to a customer database (611) and a check database (68). The customer database (611) and the check database (68) may also be comprised in the check issuing server (65; S731 in FIG. 1). This section aims to describe the customer database (611) in some more detail. The description of the customer database (611) is an example of a realistic and typical embodiment of the database. It should however be noted that several variations are possible.

The purpose of the customer database (611) is to store information about every customer (C in FIG. 1) that belongs to the check issuer that runs the check issuing server (611) and provide this information to the check issuing server (65) when the check issuing server (65) requests it. For every customer, the following information may be included in the database (611): first name of customer, last name of customer, unique customer identification number, contact information to the customer. Furthermore, there may be credentials for the user required to authenticate the customer when the customer (C) connects his mobile phone (61) to the check issuing server (65). The credentials may, for example, simply consist of a password. In that case, the password may be stored directly in the customer database (611), or a secure hash of the password may be stored instead to increase security. Storing the secure hash (e.g. SHA-I or SHA-256) is considered more secure in general, than storing the passwords in clear text. The secure hash of the password is enough to verify that the user supplies the correct password in the authentication process.

Furthermore, the customer database (611) may store a monetary balance with electronic funds available to use for payments. If so, the check issuing server (65) itself provides the liquidity required to make an electronic payment. However, in another embodiment of this invention, the electronic funds are available in an external monetary transfer system (91, 92, 93, 101 in Figs. 10 and 11). This decoupling between the check issuing server (65) and the supporting monetary transfer system makes it possible to use existing transfer systems (91, 92, 93, 101) to facilitate the electronic money transfer process.

One suitable way of implementing the customer database (611) is using a conventional relational database with tables containing the customer information. This technology is well- known in previous art.

8. Check Database

According to an embodiment of the invention, a check database (68) may hold information on currently issued electronic checks (H0861). Figure 5 shows one example of the information stored in one of the issued electronic checks (H0861) and the corresponding secure check reference (D0861). Figure 7 shows how this part of the system may interact with the rest of the system. The whole payment process is started when the customer (C) visits the website of the check issuer (65; S731 in FIG. 1) using, for example, the mobile phone (61). After the customer (C) has been authenticated to the check issuing server (65; S731 in FIG. 1), the check issuing server (65; S731 in FIG. 1) handles the check issuing request from the customer (C) by creating an electronic check (H0861). This electronic check (H0861) is always created for the amount as requested by the customer and for a limited time period. In one embodiment of the invention, the balance of the customer (or the possibility of charging a certain amount) is checked before the electronic check (H0861) is issued. If so, the electronic check (H0861) will only be issued if there is enough funds on the electronic monetary account. In another embodiment of the invention, there is no balance check at this stage of the process. This is not required since the balance will be checked later when the merchant system (614) requests a payment using the issued electronic check (H0861). There is no need to block or reserve a specific amount for the electronic check (H0861) when it is created. Instead, the balance may always be checked when the merchant system (614; M, R in FIG. 1) to request a payment using the electronic check (614).

The electronic check (H0861) may be created and stored in the check database (68) until it expires and some predetermined duration after that. While or after the electronic check (H0861) is stored in the check database (68), the corresponding secure check reference (D0861) is sent to the mobile phone (61) in a web page, scanned by the bar code scanner (R) of the merchant system (614; M, R in FIG. 1), and then sent from the merchant system (614; M, R in FIG. 1) to the check issuing server (65; S731 in FIG. 1) that will use the secure check reference (D0861) to validate the payment request from the merchant system (614). Only if the secure check reference (D0861) validates successfully will the check issuing server (65; S731 in FIG. 1) request a monetary transfer based on the request from the merchant system (614). As can be seen in FIG. 6, the merchant system (614; M, R in FIG. 1) may comprise a processing unit (615) and a memory (616) arranged to perform the tasks of the merchant system (614; M, R in FIG. 1) described herein.

FIG. 7 shows an example of a successful payment is performed by the parts comprised in the proximity payment system, particularly the inventive check issuing server (65; S731 in FIG. 1) and merchant system (614; M, R in FIG. 1) according to the invention.

In FIG. 7, the check issuing server (65; S731 in FIG. 1) may arranged to provide a web site which a customer may enter in order to log onto the check issuing service of the check issuing server (65; S731 in FIG. 1) using a mobile connected device (61). Upon a detecting a customer logging on (71), the check issuing server may further be arranged to authenticate said customer by sending a request (72) to authenticate the customer to said customer database (611). The request (72) may comprise customer credentials which the customer has to enter in order to be logged in. The check issuing server (65; S731 in FIG. 1) may receive information (73) from said customer database (611) indicating if said authentication was performed successful or not by the customer database (611). Upon receiving information (73) that said authentication was successful, the check issuing server (65; S731 in FIG. 1) may provide a new web site wherein said authenticated customer may enter a check request (74). Upon receiving said check request from said authenticated customer, the check issuing server (65; S731 in FIG. 1) may create an electronic check (74) and store said electronic check in accordance with said check request in a check database (74). Upon receiving said check request from said authenticated customer, the check issuing server (65; S731 in FIG. 1) may create a secure check reference corresponding to said electronic check. The check issuing server (65; S731 in FIG. 1) may provide said customer with said secure check reference encoded in a bar code. This may be performed by a displaying said bar code on a new web site provided to the authenticated customer (75). The web site may be provided to the authenticated customer through a mobile connected device. The authenticated customer may show the bar code displayed on the mobile connected device to the merchant using the merchant system (614; M, R in FIG. 1), which may scan the bar code with a bar code scanner (76). The merchant system (614; M, R in FIG. 1) may then perform send request of a payment (77) which includes the secure check reference and the check amount encoded in the bar code data. The check issuing server (65; S731 in FIG. 1) may receive a request of a payment (77) from a merchant system (614; M, R in FIG. 1) to which said secure check reference encoded in a bar code has been provided by said customer. The check issuing server (65; S731 in FIG. 1) may then validate a payment with said electronic check using said secure check reference in said request of a payment (77). The validation may be performed in the check issuing server (65; S731 in FIG. 1) or by sending the secure check reference to said check database (78). The check issuing server (65; S731 in FIG. 1) may, upon for example receiving information (79) from said check database (68) indicating that the secure check reference is valid, perform said payment (710) if said secure check reference is valid. The payment may be performed by the check issuing server (65; S731 in FIG. 1) or by an external payment system. When said payment has been executed by the check issuing server (65; S731 in FIG. 1) or said external payment system, the check issuing server (65; S731 in FIG. 1) may notify said the merchant system (614; M, R in FIG. 1) that said payment has been executed (711). A notification (712) may also be sent to the customer, for example, to the mobile connected device (61). After a period of time, the electronic check may be permanently removed from the check database (68).

FIG. 8 shows an example of a payment that is unsuccessful due to an expired electronic check (H0861). If the secure check reference (D0861) displayed on the web page shown in the mobile phone (61) is not used within e.g. 10 minutes, the electronic check (H0861) will expire (81). The subsequent request for a payment (77) by the merchant system (614; M, R in FIG. 1) in FIG. 8 will be unsuccessful. The response from the check issuing server (65; S731 in FIG. 1) will then be "check expired" (82; 83).

In this manner, if information received from said check database (68) and/or in the check issuing server (65; S731 in FIG. 1) indicates that the secure check reference (D0861) is not valid, then the check issuing server (65; S731 in FIG. 1) may notify the merchant system (614; M, R in FIG. 1) that said payment has not been executed. This notification may also comprise information indicating the reason why said payment was not executed, such as, for example, "Check expired" (82; 83). Figs. 7 and 8 thus describe two common scenarios when the validation of the secure check reference (D0861) is successful and one where it is not. The next section describes the validation process in some more detail.

9. Validation Process

FIG. 9 shows a flow chart of how a secure check reference (D0861) is validated by the check issuing server (65; S731 in FIG. 1) and/or the check database (68) when it is sent to the check issuing server (65; S731 in FIG. 1) from the merchant system (614; M, R in FIG. 1) in step S91. In step S92, a syntactical analysis may be performed. If the syntax is not correct, a message with that information may be returned to the merchant system (614; M, R in FIG. 1) in step S93. This step may be performed without contacting the check database (68).

In step S94, the check database (68) may be queried by the check issuing server (65; S731 in FIG. 1) for the existence of an electronic check (H0861) corresponding to said secure check reference (D0861). If a corresponding electronic check (H0861) does not exist, the message "no such check" may be returned to the merchant system (614; M, R in FIG. 1) in step S95.

In step S96, the check issuing server (65; S731 in FIG. 1) may check the verification data in the secure check reference (D0861) and compares this with the verification data in the issued electronic check (H0861). If the verification data in the secure check reference (D0861) is not identical to what is stored in the issued electronic check (H0861) according to the check database (68) or the check issuing server (65; S731 in FIG. 1), the message "check invalid" is sent to the merchant system (614; M, R in FIG. 1) in step S97. The merchant using the merchant system (614; M, R in FIG. 1) will now be informed of the fact that the customer (C) may be trying to forge a check.

If the verification data in the secure check reference (D0861) matches that of the verification data in the issued electronic check (H0861), the validation process continues with checking the expiry time of the issued electronic check (H0861) in step S98. If the issued electronic check (H0861) has expired, the message "check expired" is send to the merchant system (614; M, R in FIG. 1) in step S99. This check may be performed by the check issuing server (65; S731 in FIG. 1) by, for example, a query to the check database (68). This information may then be communicated to the customer (C) by the merchant. The customer can at this time simply generate a new check to enable a payment. If the issued electronic check (H0861) has not expired, the check issuing server (65;S731 in FIG. 1) may continue with the validation process by checking the payment amount in step S910. An issued electronic check (H0861) always has a maximum payment amount. The payment request from the merchant system (614; M, R in FIG. 1) contains a payment amount. If this amount exceeds the maximum payment amount of the issued electronic check (H0861), the message "maximum check amount exceeded" will be sent to the merchant system (614; M, R in FIG. 1) in step S911. The merchant will now know that the customer (C) issued an electronic check (H0861) with a too small maximum amount. At this time, it is possible for the merchant to inform the customer (C) of this, and request a new check with a higher maximum payment amount. If this amount does not exceed the maximum payment amount of the issued electronic check (H0861), the secure check reference (D0861) is valid and the payment request may be processed in step S912.

10. Interface to Existing Monetary Transfer Systems

Figure 10 shows that the check issuing server (65; S731 in FIG. 1) may connect to an external monetary transfer system (91, 92, 93), instead of using an internal monetary balance of the customer. Possible systems to use for this purpose include the conventional inter-bank monetary transfers systems (91) that typically use SWIFT messages to process transfers. Another alternative is to use electronic wallet solutions, such as the PayPal service (92). The existing card payments systems (93), such as Visa or MasterCard, could also potentially be used to execute the actual transfer of funds. In one embodiment in the present invention, the check issuing server (65; S731 in FIG. 1) uses multiple external monetary transfer systems for different customers depending on their preferences.

Figure 11 shows how an external monetary transfer system (101) interacts with the check issuing server (65; S731 in FIG. 1) and the merchant system (614; M, R in FIG. 1). When the merchant system (614; M, R in FIG. 1) has sent a payment request (111) to the check issuing server (65; S731 in FIG. 1) and the payment request is validated successfully (112), the external monetary transfer system (101) is requested to perform the payment (113). If the transfer system does this successfully (114), the merchant system (614; M, R in FIG. 1) is notified by the check issuing server (65; S731 in FIG. 1) of this fact (115; 116) and the merchant can complete the purchasing procedure (117) and print the receipt for the customer (C). At this time, the check issuing server (65; S731 in FIG. 1) may also send an SMS directly to the mobile phone (61) of the customer (C) as a receipt for the successful payment (712 in FIG. 7).

Some further aspects of the invention are discussed below.

A check issuing server for use in a proximity payment system, wherein said check issuing server may be arranged to comprise or be connected to a check database and a customer database. The check issuing server may further be arranged to provide a web site which a customer may enter in order to log onto the check issuing service of the check issuing server. Upon detecting a customer logging on, the check issuing server may further be arranged to authenticate said customer by sending a request to authenticate the customer to said customer database. The request may comprise customer credentials which the customer has to enter in order to be logged in. The check issuing server may further be arranged to receive information from said customer database indicating if said authentication was successful or not. Upon receiving information that said authentication was successful, the check issuing server may further be arranged to provide a new web site wherein said authenticated customer may enter a check request. Upon receiving said check request from said authenticated customer, the check issuing server may further be arranged to create an electronic check and store said electronic check in accordance with said check request in a check database. Upon receiving said check request from said authenticated customer, the check issuing server may also be arranged to create a secure check reference corresponding to said electronic check. The check issuing server may further be arranged to provide said customer with said secure check reference encoded in a bar code. This may be performed by displaying said bar code on a new web site provided to the authenticated customer. The web site may be provided to the authenticated customer through a mobile connected device. The check issuing server may further be arranged to receive a request of a payment from a merchant system to which said secure check reference encoded in a bar code has been provided by said customer. The check issuing server may further be arranged to, if said request of a payment is at least partly based on said secure check reference, validate a payment with said electronic check using said part of said secure check reference in said request of a payment. The validation may be performed in the check issuing server or by sending the secure check reference to said check database. The check issuing server may further be arranged to, upon for example receiving information from said check database indicating that the secure check reference is valid, perform said payment if said secure check reference is valid. The payment may be performed by the check issuing server or by an external payment system. When said payment has been executed by the check issuing server or said external payment system, the check issuing server may further be arranged to notify said the merchant system that said payment has been executed. A notification may also be sent to the customer, for example, to the mobile connected device.

Alternatively, if information received from said check database and/or in the check issuing server indicates that the secure check reference is not valid, then the check issuing server may further be arranged to notify said merchant system that said payment has not been executed. This notification may also comprise information indicating the reason why said payment was not executed.

Some additional aspects of the invention are listed below.

According to a first additional aspect of the invention, the proximity payment system may comprise one or more check issuers; a mobile phone capable of connecting to the Internet; a bar code reader; a customer who uses said mobile phone and who is a registered user with at least one of said check issuers; a merchant; a monetary transfer system providing means to make a payment from said customer to said merchant; a check issuer that is one of said check issuers and that has said customer as one of its customers; an electronic check that: (a) is valid for payments from said customer, (b) is issued by said check issuer, (c) is stored by said check issuer, and (d) is valid only for a limited amount of time; a secure check reference comprising: (a) data to identify said electronic check, and (b) data to verify the authenticity of said secure check reference; a bar code that stores the data of said secure check reference; mobile phone software, running on said mobile phone, capable of:(a) connecting to said check issuer, (b) authenticating said customer and/or said mobile phone to said check issuer, (c) receiving said secure check reference from said check issuer, and (d) displaying said barcode on the display of said mobile phone; a merchant system used by said merchant capable of: (a) using said bar code reader to scan said barcode displayed on said mobile phone, (b) connecting to said check issuer, and (c) sending the acquired secure check reference and the amount to be paid, to said check issuer; a check issuing system run by said check issuer capable of: (a) creating said electronic check, (b) creating said secure check reference, and (c) validating said secure check reference received from said merchant and if said secure check reference is valid, and the corresponding electronic check is valid, a request of a payment from said customer to said merchant is made using said monetary transfer system; whereby fast and secure proximity payments can be made using an ordinary mobile phone.

According to a second additional aspect of the invention, said mobile phone software is a web browser connecting to said check issuer using the web standards HTTP and HTML or variants of those standards.

According to a third additional aspect of the invention, said bar code does not consist of a series of characters meant to be read by OCR methods.

According to a fourth additional aspect of the invention, said electronic check is valid only for payment amounts smaller than or equal to a maximum amount included in said electronic check.

According to a fifth additional aspect of the invention, the system may comprise more than one check issuer.

According to a sixth additional aspect of the invention, said secure check reference further comprises data to identify the issuer of said electronic check.

REFERENCES

[1] MasterCard's web site at http://www.mastercard.com/paypass/.

[2] Visa's web site at http://corporate.visa.com/md/fs/consumer/contactless.jsp.

[3] Report "Mobile Payments Strategies & Markets 2007-2011" from Juniper Research. Report is available at http://www.juniperresearch.com/shop/viewreport.php?id=88.

[4] http://www.juniperresearch.com/.

[5] Statistics available at The Mobile World's web site at http://www.themobileworld.com/tmwdev/Q4smartSite.dll/wrapper.

[6] Daniel Henriksson, "Proximity payments using Betala.se", from http://www.cs.umu.se/education/examina/Rapporter/DanielHenriksson.pdf.

[7] Swedish Internet Payments Ltd. VAT number SE556689226001. Web site: www.betala.se.

[8] Korean patent application 20020023098, "Electronic payment system and method using LCD barcode of mobile terminal, method for paying cash". Also published as US2004148253 and WO02086785.

[9] US patent 6854651, "Non-persistently displayed bar code based data input method and apparatus".

[10] WO2003023674 "System and method for credit card payment using barcode and mobile phone device".

[11] US patent 6916244, "Server- less cashless gaming systems and methods".

[12] US patent 7004388, "Electronic ticket issuing system and electronic ticket issuing method".

[13] US patent 7028906, "System, method, and apparatus for communicating information between a mobile communications device and a bar code scanner".

[14] US patent 6736322, "Method and apparatus for acquiring, maintaining, and using information to be communicated in bar code form with a mobile communications device".

[15] US patent application 20070244811 "Mobile Person-to-Person Payment System".

[16] US patent application 20070255653, "Mobile Client Application for Mobile Payments".

[17] US patent application 20070130085, "Method and apparatus of secure authentication and electronic payment through mobile communication tool".

Claims

1. A server of a check issuer (S731) for use in a proximity payment system, said server of a check issuer (S731) being arranged to

upon receiving a check request from a customer (C), create an electronic check (H0861) and a secure check reference (D0861), wherein said secure check reference (D0861) comprises data to identify said electronic check (H0861) and data to verify the authenticity of said secure check reference (D0861);

provide said customer (C) with said secure check reference (D0861) encoded in a bar code;

receive a request of a payment (3) from a merchant system (M; R) to which said secure check reference (D0861) encoded in a bar code has been provided by said customer (C); and

if said request of a payment (3) is at least partly based on said secure check reference (D0861), validate a payment with said electronic check (H0861) using said at least part of said secure check reference (D0861) in said request of a payment (3).

2. A server of a check issuer (S731) according to claim 1 , further being arranged to provide a web page through which said web server of a check issuer (S731) may receive said check request from said customer (C).

3. A server of a check issuer (S731) according to claim 1 or 2, said server of a check issuer (S731) being arranged to show said bar code on a web page which may be displayed on a mobile phone of said customer (C).

4. A server of a check issuer (S731) according to any one of the claims 1-3, wherein said electronic check (H0861) contains at least: a check identification data (CheckID), a customer identification data (CustomerID), a check state (State), a maximum amount (MaxAmount), an expiry time (ExpiryTime), and verification data (VerData).

5. A server of a check issuer (S731) according to any one of the claims 1-4, wherein said secure check reference (D0861) further includes an issuer identification data (IssuerID).

6. A method for use in a server of a check issuer (S731) in a proximity payment system comprising the steps of

upon receiving a check request from a customer (C), creating an electronic check (H0861) and a secure check reference (D0861), wherein said secure check reference (D0861) comprises data to identify said electronic check (H0861) and data to verify the authenticity of said secure check reference (D0861);

providing said customer (C) with said secure check reference (D0861) encoded in a bar code;

receiving a request of a payment (3) from a merchant system (M; R) to which said secure check reference (D0861) encoded in a bar code has been provided by said customer (C); and

if said request of a payment (3) is at least partly based on said secure check reference (D0861), validating a payment with said electronic check (H0861) by using said at least part of said secure check reference (D0861) in said request of a payment (3).

7. A method according to claim 6, wherein said step of validating a payment is performed by matching said at least part of said secure check reference (D0861) with said previously created electronic check (H0861).

8. A method according to claim 6 or 7, further comprising the step of notifying a merchant system (M; R) with an error message from said server of a check issuer (S731) if no matching check is found, and/or if a matching check has been found, but has either expired or already been used.

9. A method according to any one of the claims 6-8, further comprising the step of notifying a merchant system (M; R) via a response to said request of a payment (3) from said server of a check issuer (S731) if the payment has been executed.

10. A computer program product for use in a server of a check issuer (S731) which comprises computer readable code means, which when run in a processing unit in the server of a check issuer (S731) causes said server of a check issuer (S731) to perform the steps of

upon receiving a check request from a customer (C), creating an electronic check (H0861) and a secure check reference (D0861), wherein said secure check reference (D0861) comprises data to identify an electronic check (H0861) and data to verify the authenticity of said secure check reference (D0861);

11. A computer program product according claim 10, comprising computer readable code means, which when run in the processing unit in the check issuing server (S731) causes the server of a check issuer (S731) to further perform the steps according to any of the claims 8-10.

12. A computer program product according claim 10 or 11, wherein said code means is stored on a readable storage medium.

13. A merchant system (M; R) for use in selling products and services to a customer (C), comprising a bar code reader (R) and an internet connection, being arranged to

receive a secure check reference (D0861), said secure check reference (D0861) comprises data to identify an electronic check (H0861) and data to verify the authenticity of said secure check reference (D0861), encoded in a bar code from said customer (C) using said bar code reader (R);

send a request of a payment (3) which is at least partly based on said secure check reference (D0861) to an server of a check issuer (S731) over said internet connection.

14. A merchant system (M; R) according to claim 13, further being arranged to in said request of a payment (3) supply the secure check reference (D0861) along with information about the amount to be paid and the identity of the receiver of the payment.

15. A merchant system (M; R) according to claim 13 or 14, further comprising a list of network addresses to servers of check issuers.

16. A method for use in a merchant system (M; R) comprising the steps of

receiving a secure check reference (D0861), said secure check reference (D0861) comprises data to identify an electronic check (H0861) and data to verify the authenticity of said secure check reference (D0861), encoded in a bar code from said bar code reader (R);

sending a request of a payment (3) which is at least partly based on said secure check reference (D0861) to a server of a check issuer (S731) over said internet connection.

17. A method according to claim 16, further comprising the step of supplying, in said request of a payment (3), the secure check reference (D0861) along with information about the amount to be paid and the identity of the receiver of the payment.

18. A method according to claim 16 or 17, further comprising the step of finding the address to the server of a check issuer (S731) in said list of network addresses to servers of check issuers.

19. A computer program product for use in a merchant system (M; R) which comprises computer readable code means, which when run in the a processing unit (615) in the merchant system (M; R) causes said merchant system (M; R) to perform the steps of receiving a secure check reference (D0861), said secure check reference (D0861) comprises data to identify an electronic check (H0861) and data to verify the authenticity of said secure check reference (D0861), encoded in a bar code from said bar code reader (R);

20. A computer program product according claim 19, comprising computer readable code means, which when run in the processing unit (615) in the merchant system (M; R) causes the merchant system (M; R) to further perform the steps according to any one of the claims 17-18.

21. A computer program product according claim 19 or 20, wherein said code means is stored on a readable storage medium.

22. A proximity payment system comprising a server of a check issuer (S731) according to any one of the claims 1-5 and/or a merchant system (M; R) according to any one of the claims 13-15.