WO2007069906A1

WO2007069906A1 - Method and server for ordering products

Info

Publication number: WO2007069906A1
Application number: PCT/NO2006/000468
Authority: WO
Inventors: Annette Krannig-Schmidt
Original assignee: Annette Krannig-Schmidt
Priority date: 2005-12-06
Filing date: 2006-12-06
Publication date: 2007-06-21
Also published as: NO324141B1; EP1958137A1; NO20055770D0; NO20055770L

Abstract

The invention relates to a method and server for transferring digital data from a hand-held communication device to a central across at least one communications network. The method includes receiving an initiating message from the communication device at the central, the initiating message having been transferred from the communication device across a communications network. The method is characterized in that it comprises sending a second message from the central to the communication device, the second message including a program providing an interface on the communication device for entering said data on the communication device; and receiving the digital data at the central from the interface on the communication device, the data having been transferred through an SMS connection or a mobile Internet. A server for carrying out the method is also described.

Description

METHOD AND SERVER FOR ORDERING PRODUCTS

INTRODUCTION

The present invention relates to a system and method for ordering products using mobile communication devices, e.g. mobile telephones or other hand-held devices.

BACKGROUND

Today, it is possible to send an email or ordinary message (e.g. SMS message) through the telephone company's network from a telephone to order a product. In most cases, however, the order itself as well as the customer information are processed manually by the party that receives the order and delivers the ordered product. The customer must be identified by the home address, and it must be possible to provide the delivery address.

Mobile phone e-commerce is also carried out in conjunction with WAP technology. A customer is surfing on the Internet from a mobile phone, and may then download a form from an Internet server, fill in the customer information in the form, and then submit this form to the server from which the form was downloaded. This process may be time consuming and cumbersome using a mobile phone. In many cases, therefore, the customer would rather use a computer connected to the Internet to make the order.

RFID (radio frequency identification) is a technology that envisions electronic billboards having an embedded RFID chip. To order the product shown on the billboard, the customer has to transmit radio signals from his or her telephone to the RFID chip. Each telephone has its own radio frequency, enabling the identification of the customer.

Another possible approach to mobile phone e-commerce is that the buyer sends an SMS to a given number, and is then returned, via SMS, a link to a form stored on an Internet server. Then the buyer must connect to the Internet by the telephone and download the form to his or her mobile phone to fill in customer information, such as name and delivery address. This information is then returned to the Internet server through an Internet connection. As such, the communication over the Internet/WAP between the buyer and the supplier of the product requires that the product supplier has an Internet gateway including an Internet server that is continuously connected to the Internet.

It is today also possible to download Java games and other digital content to the mobile phone over the Internet by clicking on a desired game, which is then installed on the customers mobile phone via SMS. As the buyer has to provide his or her telephone number to receive the game via SMS, the user is identified, so that the supplier of the game is able to invoice the buyer. The payment occurs via mobile phone, for example. Textmessages may also be used for ordering cinema tickets, in which case the reservation number is sent to the customers mobile phone via SMS, for ordering books, airplane tickets, etc.

The use of the mobile phone as a wallet is also possible, e.g. in that an SMS message is sent to a soda machine containing a code word identifying the desired beverage, which is then delivered to the customer from the machine, the payment being effected via the phone bill. Another example is the reservation of parking time via the mobile phone, the amount being drawn from the customers phone bill.

Also, the SIM/Smart Card in the telephone may execute cryptographic algorithms in order to implement secure electronic money. Payment through SMS is described, for example, in the U.S. patent application US 2005/0171909.

Security in e-commerce transactions is ensured, inter alia, using encryption based on SSL (Secure Socket Layer). SSL is a protocol for the secure transfer of data on the net according to which all data transferred between a browser and an Internet server is encrypted using a public key (RSA) and a symmetric algorithm. If a client (Internet browser) contacts an SSL Internet server with a request, the SSL server will reply with a response, including a certificate of the public key of the Internet server. Any Internet browser by the installation has a list of the most common certificate issuers (Certification Authorities (CA)) and their superior certificates (such as Verisign, Thawte).

In the authentication from a mobile phone to a server via the Internet, the mobile phone may generate an RSA key pair, after having received an Internet page from an SSL-server, including the corresponding public key/ certificate of the server. This method is described, for example, in "MIDP Application Security 3: Authentication in MIDP", by Jonathan Knudsen, December 2002, http://developers.sun.com/techtopics/mobilitv/midp/articles/security3/. The corresponding public key of the mobile phone is not verified by a certificate authority, so that an SSL server will not be able to authenticate the customer in a strict cryptographic sense. However, this method allows a mobile phone to reply to a response from an SSL Internet server. The SSL protocol requires that the client authenticate for the SSL server by way of a signature. The client returns a public key to the SSL server together with a signature, which is generated using the corresponding private key of the mobile phone (https). In the described method, a certificate and a private key are sent to the mobile phone, while the mobile phone signs the message for authentication against a WAP/Internet server. However, such use of the private key should be avoided, and represents a security risk for the users of a mobile e-commerce system. Moreover, a mobile phone also may not just simply generate a key pair.

Achieving a "proper authentication" from a mobile phone user with an SSL server is more difficult. It is then necessary to generate the private key and the public key and then have the public key certified by a certificate authority (CA), so that the customer from the mobile phone may authenticate with the SSL server using its signature. This is only possible by generating an RSA key pair and then have the public key certified by a certificate authority.

The most comprehensive description of feasible cryptographic solutions for mobile phones or J2ME is "Data security in mobile Java applications - learn how to select and use third-party-security", by Michael Yuan, Research Associate, Center for Research in Electronic Commerce, University of Texas at Austin, June 18, 2002 http://journals2.iranscience.net:800/www.javaworld.com/www.javaworld.com/javaw orld/jw-12-2002/jw-i 220-wireless-p2.html.

This reference also contains comprehensive source code material, and describes how to generate an RSA key pair in J2ME using Bouncy Castle, that provides encryption, and also how to write each key parameter to a file for later use and how to read the key parameters from a file, when needed. The reference also describes how to use cryptography in J2ME by means of other crypto-libraries than Bouncy Castle, such as Phaos or jNeo, for example.

Additional prior art solutions are described at the following Internet sites, for example:

MIDP Application Security 4: Encryption in MIDP, by Jonathan Knudsen, September 2005 http://developers.sun.com/techtopics/mobilitv/midp/articles/security4/

Secure Java MIDP Programming Using HTTPS with MIDP by Qusay H. Mahmoud, June 2002 http://developers.sun.com/techtopics/mobility/midp/articles/https/index.html

Securing your J2ME/MIDP apps: How to digitally sign and verify XML documents on wireless devices using the Bouncy Castle Crypto APIs, by Michael Yuan, Research Associate, Center for Research in Electronic Commerce, University of Texas that Austin, 18 Jun 2002;http://www-128.ibm.com/developerworks/librarv/i- midpds.html.

SUMMARY OF THE INVENTION

In a first aspect, the present invention provides a method for transferring digital data from a hand-held communication device to a central across at least one communication network, the method comprising receiving an initiating message from the communication device at the central, the initiating message being transferred from the communication device across a communications network, wherein the method further comprises sending a second message from the central to the communication device, the second message including a program providing an interface on the communication device for entering said data on the communication device; and receiving the digital data at the central from the interface on the communication device, the data being transferred via an SMS connection or mobile Internet.

The program may include a public key of the central for encrypting the digital data. In another embodiment, the program may include a certificate and/or a public key of a superior certificate authority. The method may further comprise signing/certifying the public key of the central with the private key of the central, or signing/certifying the public key of the central by a superior certificate authority (CA), and embedding the signature/certificate in the program, so that the program includes a fingerprint of the signature of the public key of the central. The method may further include sending an additional message to the communication device before sending the second message, the additional message including a fingerprint of the public key of the ordering central.

The program may be hashed or signed in the central before being sent. The hash code may then be verified by the program before the program is downloaded to the communication device.

In a further embodiment, the method may include sending an additional message to the communication device before sending the second message, the additional message including a fingerprint. The fingerprint/checksum may be calculated as a hash code from a secret in the program, the public key of the central, and a time stamp (current time and date). The program includes the time stamp representing the time at which the server calculated the fingerprint, and knows the secret of the server. Having this information, the program on the mobile phone is able to calculate the same fingerprint that is sent to the mobile phone/ customer in an additional SMS. The fingerprint is calculated each time a program is sent. The fingerprint is verified after the program has been downloaded to the communication device. The fingerprint cannot be calculated by other parties than the ordering central and the mobile phone.

The method may further include downloading the program to the communication device across the mobile Internet by way of a link to the program provided in the second message from the central. The digital data may be order data including customer data and payment information associated with a payment organization. The method may further include authenticating/verifying the customer data by querying a subscriber database of a network operator, as well as authenticating/verifying the payment information by querying the payment organization, before shipment/sending of at least one ordered product.

In a second aspect, the invention provides a server for processing digital data received from at least one communication device across at least one communications network, wherein the server comprises a database for the digital data, wherein the server further comprises a receiving device for receiving at least one message transferred via a communications network from the communication device, and a sending device for messages transferred to the communication device across the communications network, the message including a program providing an interface on the communication device for entering the digital data on the communication device, and for transferring the digital data to the server through an SMS connection or across the mobile Internet.

The program may include a public key of the server for encrypting the digital data, and the server may include a private key for decrypting the received digital data. To further increase the security, the program may be signed with the private key of the server, include a certificate, and/or a public key from a superior certificate authority.

Also, the public key of the central may be signed/certified with the private key of the central, or signed/certified at the central by a superior certificate authority (CA), after which the signature/certificate is integrated in the program. An additional message may be sent to the communication device before the message containing the program is sent, the additional message including a fingerprint of the public key of the server. The program may further be hashed or signed at the central before being sent, and the hash code may then be verified in the program before the program is downloaded to the communication device. The server may further include a means for sending an additional message to the communication device before sending the message containing the program, wherein the additional message includes a fingerprint. This fingerprint may be a hash code of a secret in the program, the public key of the central, and a timestamp.

The message sent may further include a link to the program for downloading the program to the communication device over the mobile Internet. The server may have access to a communication channel for transferring information between the server and product suppliers. The communication channel may be at least one of an email client, a telephone system, a fax gateway, and an SMS gateway.

The hand-held communication device may be a mobile phone or another handheld device, such as a PDA, and said messages may be SMS messages. Further, the communications network may include GSM, GPRS, 3G, UMTS, or EDGE, and the mobile Internet may include GPRS, 3G, UMTS, or EDGE.

The program may be a MIDIet (JAVA). In a further embodiment, the program may include means for receiving messages from the server through an SMS or http connection. In this manner, the program may be actualized/updated from the server after installation on the hand-held device (mobile phone, telephone, PDA, etc.), by clicking on "actualize" in a menu in the interface on the communication device, for example.

A method for ordering at least one product using a hand-held communication device over at least one communications network is also described, the method comprising receiving an initiating message from the communication device at an ordering central, the initiating message having been transferred from the communication device across a telecommunications network, wherein the method is characterized in the steps of sending a second message from the ordering central to the communication device, the second message including a program serving as an ordering form for automatically providing an interface for entering order data on the communication device; and receiving digital order data at the ordering central from the interface on the communication device, the ordering data having been transferred via SMS/the telecompany network or the mobile Internet using a corresponding communication protocol (such as WAP/http).

In one embodiment, the digital order data may include customer data, which in turn includes payment information associated with a payment organization. The customer data may be authenticated/verified by querying a subscriber database at a network operator, and the payment information may be authenticated/verified by querying the payment organization, before shipment/sending of the at least one product.

In a further embodiment, the communication device may be a mobile phone, and the initiating message and the second message may be SMS messages. The mobile Internet may be protocols like WAP or HTTP across communications networks like GPRS, UMTS, 3G, or EDGE.

A server for processing product orders comprising a database for order-related information is also described, wherein the server is further characterized in that it comprises a receiving device for receiving order messages transferred via a communications network from a communication device, and a sending device for sending messages to a communication device via the communications network, the message providing a program serving as an ordering interface for entering order data on the communication device.

The server may further comprise access to a communication channel for transferring information between the server and product suppliers, which communication channel may be at least one of an email client, a telephone system, a fax gateway, and an SMS gateway.

The present invention provides a simple and secure method, and a system, for the digital transfer of sensitive digital data from a hand-held communication device to a central server. The digital data may represent order data in an electronic ordering/commerce scenario. A customer does not have to be concerned about the Internet, but may carry out the purchase by means of the mobile phone (or some other hand-held device that is able to send and receive SMS messages) and SMS (Short Message Service). The midlet (the program) is downloaded from a server via the mobile Internet (such as WAP) using a URL/link sent to the customer in an SMS message. The midlet may be automatically installed on the customers mobile phone when the customer clicks on the link in the received SMS message. The mobile phone may ask the user whether or not the user accepts the installation and where the program is to be stored. On some telephones, the program may open automatically after the installation, whereas on other telephones the customer has to open the program manually. Opening the program automatically provides an ordering interface for entering order data. The ordering interface provides digitized information on the name, address of the user and the delivery address, as well as order data. This means that the user can be authenticated by the mobile phone number and associated address registered in a subscriber database of the telephone company before delivery of the ordered products takes place. It also allows for another delivery address than the address of the subscriber, as well as the verification of the customer credit card information. Payment may be effected automatically by way of a credit card, or through an invoice accompanying the shipment. Hence, the system provides an automatic ordering and payment service based on SMS all the way to the shipment of the ordered products.

The ordering process is simplified in that only a mobile phone or another handheld device is necessary on the buyer side, and that on the vendor side the handling may be performed automatically with a reduced demand on the equipment. The solution also improves the security by implementing an encrypted and verified communication with the hand-held device and the ordering central. By including e.g. a public key and/or fingerprint from an ordering central (server) as discussed above, for example, in the program to be downloaded to the mobile phones, the digital order data, and thereby also any sensitive payment information, may be encrypted in a secure manner with no assistance from the user of the mobile phone. The invention is defined in the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described with reference to the following drawings, in which:

Figure 1 is a schematic view of the system according to the present invention,

Figure 2 shows a flow diagram for carrying out the method according an embodiment of the present invention,

Figure 3 is an exemplary ordering interface that is downloaded and run on a mobile phone according to an embodiment of the present invention,

Figure 4 shows an exemplary interface for product and credit card information in an exemplary donation transaction according to an embodiment of the present invention,

Figure 5 shows an exemplary display confirming that the sensitive data has been encrypted,

Figure 6 shows an exemplary interface for address information according to an embodiment of the present invention,

Figure 7 shows an exemplary shopping basket with "submit" function according to an embodiment of the present invention,

Figure 8 shows that the mobile phone will automatically ask if the user accepts sending two SMS messages according to an embodiment of the present invention;

Figure 9 shows the interface confirming that the encrypted order has been sent;

Figure 10 is an exemplary encrypted order that is received at an ordering central and forwarded to the payment solution according to an embodiment of the invention,

Figure 11 shows an example in which the payment solution verifies the credit card information, and, in the case of erroneous information, informs the user,

Figure 12 shows exemplary digital information that is needed for the automatic transfer of customer data and order data to a database at the provider of the mobile e-commerce system, according to an embodiment of the invention, and

Figure 13 shows an SMS warehouse system based on the mySQL database system. DETAILED DESCRIPTION

Figure 1 shows an overview of the various systems that enter the system according to an embodiment of the present invention. At reference number 2, a server, comprising a "midlet" (a JAVA program) for providing an interface on a mobile phone, communicates with the mobile phone via SMS or a mobile Internet, e.g. GPRS. The communication 1 between the mobile phone and the central is by way of textmessages (SMS, Short Message System) in the GSM network and/or a mobile Internet. The communication 3 between the central and the supplier/inventory is the most convenient: SMS, ordinary telephone, email or fax. The server including the program for providing an ordering interface may be physically located in association with the ordering central or remotely therefrom. The communication 4 between the ordering central and the payment solution may be an SSL connection over the Internet (sslSocket, https via the web, etc).

A first message that a customer sends from his or her mobile phone to a given telephone number containing a given codeword is an ordinary message via the network of the operator, e.g. an SMS message. In order for the customer to be able to download the program including the ordering interface to the mobile phone, the customers mobile phone needs to communicate with the server. The server returns an SMS to the customer containing a link to an ordering program (WAP push, for example). The ordering program is automatically downloaded when the customer selects the link to the WEB/ WAP server in the textmessage. A second message from the customer to the ordering central containing digital order data and customer data is transferred via SMS or a mobile Internet, e.g. GPRS. It is also possible to transfer the order data by way of an http connection (WAP) or any other communication protocol, such as a socket connection over a corresponding communications network, if the digital data cannot be transferred using SMS. The server storing the ordering program must run continuously awaiting requests. The server must also be modified to send the program in correct mime format over a mobile Internet. The communication between the customers telephone and the server for downloading the ordering program is primarily a Web/ Wap based communication. The customer may then download the program to his or her telephone regardless of the distance between the customer and the server. In principle, however, the program may be downloaded to the customers telephone using any existing technology: Bluetooth, infrared, cable, etc. The program for providing the ordering interface to mobile phones may be implemented as a Java program (midlet - Midp2.0), or in another programming language that is supported by telephones, or telephones based on the Symbian standard, etc.

In one embodiment, the ordering central is a server program that runs continuously waiting for incoming messages to be able to respond immediately by returning a correct SMS message containing a link to a midlet (program) to the customer. A GSM device or a modem/ ISDN adapter is connected to the server or comprised by the server to allow for the receipt and sending of SMS messages. Incoming and outgoing messages are transferred by way of AT modem commands between the modem and the ordering central. The receipt of product orders through SMS is then accomplished without the use of an external SMS gateway. For example, a software library jSMS from ObjectXP.com is used that transfers textmessages by way of AT modem commands to a Java program.

The program receives a message containing the codeword, identifies the mobile phone number of the sender, and returns to this phone number an SMS message containing the link to the ordering program. In the next step, a message containing order information is received by the server. This message starts with an identification word, such as "products", or an identification string for the vendor, such as XXL, PL ("Platekompaniet"), Komplett, etc. Then follows product-no1., numberl , ... product-no.10, numberi O, first name, family name, address, postal code, and post office. This is digital information that may be transferred to a database, as shown in figure 11. The database also receives credit card information: credit card number, expiry date, etc. An SMS warehouse system based on the mySQL database system is shown in figure 12. The product order sent via SMS from a mobile phone (or another handheld communication device) to the ordering central is a character string consisting of an identification string, desired products (identified by product name and number), any products from a catalog (product name and number), billing information, i.e. the customer name and delivery address, and any credit card information.

In the ordering central, the textmessage containing the product order is received by a program that adds the order to an order database. The order database basically consists of four tables: Customer table, product table, order table and stock table. These tables includes:

• Customer table: customer_id, mobile phone number, first name, family name, address, postal code, post office

• Product table: product_id, name, description, ordering number, price, weight

• Stock table: stock_id, product_id, number

• Order table: order_id, date, customer_id, product_id_1 , number_1 ,...₍ product_id_n, number_n, total_price, total_weight

For each customer order a separate row is created in the order table.

The order information is encrypted, as the communication goes via SMS/mobile Internet. Hence, the customer may be given the option to enter his or her credit card information if the product supplier desires so. Some mail order product suppliers only ships their products after payment by the credit card has taken place. Thus, in the case of corresponding ordering software at the product supplier, the products are paid before they are shipped to the customer by the mail. Further details regarding encryption are described below.

Most telephones manufactured today support electronic shopping such as described above. The telephones need to support the programming language used, Java (Midp2.0), and, for sending the order via SMS, Wireless Messaging API - WMA (JSR 120 or later), and have installed settings for WAP/ GPRS/ SMS. The mobile phone of the customer must support Java (if midlet) or the programming language in which the ordering interface is programmed.

While the above exemplary embodiment shows an ordering system, the present method and system may be used in the secure transfer of other digital data from a hand-held communication device to a server, the digital data being entered by the user of the hand-held communication device through the interface provided on the communication device.

Example: carrying out the trade

An exemplary flowchart for carrying out the trade is shown in figure 2. A trade occurs as follows: A customer sees an advertisement for a product in a newspaper, for example. First, the customer sends a message to an announced phone number containing the announced code word. The announced phone number is the phone number to the ordering central that is operated by the product supplier or system provider. As the customer is identified by the mobile phone number, the customer then receives an SMS message on his or her mobile phone containing a link. On selecting the link, the telephone connects to the mobile Internet, and a program (e.g. midlet in JAVA) will be downloaded to the customers mobile phone. The telephone may also ask if the customer desires to download and install the program and where the program is to be stored. Thereafter, the program/ordering interface must be opened: a telephone from Sony Ericsson, for example, after the installation is completed, would ask if the customer wants to open the program, and the customer must then select "yes". On a Nokia telephone, the customer must navigate back to the main menu and then open the program. As such, the process of selecting the link, download, install, and open the program are known, e.g. in connection with getting a Java game from the Internet, download the program, install, and run the game.

However, opening the program (midlet) results in that the customer is automatically shown an ordering interface on the display of the mobile phone. An example of such an ordering interface is shown in figs. 3 - 9. The ordering interface contains fields in which the customer enter first name, family name, living address, delivery address, desired products, credit card information, optionally the amount for a donation transaction, and is informed on terms of purchase. By clicking "order" or "send", for example, a message containing this "filled-in" ordering form is automatically sent to the server of the provider of the mobile e- commerce system via SMS, for example, which is the easiest to handle for the customer. If the mobile phone does not support sending SMS messages from the program, the order may alternatively be transferred via a mobile Internet, e.g. GPRS, UMTS, or EDGE, or another suitable communication protocol (e.g. http/WAP) across a suitable communications network.

For example, the mobile e-commerce system and the ordering central itself may be run by one or more product suppliers or a system provider. The provider of the mobile e-commerce system (e.g. a product supplier) first receives an SMS from a customer containing the code word via the mobile phone network. An ordering function at the server of the mobile e-commerce system then automatically sends a message to the received mobile phone number (the telephone number to the sender of the SMS) containing a link to a midlet (Java) providing the ordering interface. The provider of the mobile e-commerce system thereafter receives the second message from the customer containing the customer information as discussed above. This customer and ordering information is assigned to the already existing customer information in the database of the provider based on the mobile phone number, to which the provider has access via the textmessage. If the customer is using a mobile phone with a registered phone number, it is also possible for the provider of the mobile e-commerce system to automatically verify the customer information by checking the customer database against the available subscriber databases of the telephone companies. The subscriber databases contain verified personal information, as a buyer of a mobile phone must be registered and provide identification. The subscriber databases may be queried each time a message containing a new telephone number is received by the ordering central. On the receipt of the second message, the provider of the mobile e-commerce system may automatically return an SMS to the customer with an order confirmation and information on the time of delivery. Credit card information is transferred together with the name of the vendor and payable amount to the payment solution/ bank. The bank will respond with an ok if the credit card information could be verified, and with an error message if not. If the credit card information was correct, the amount is reserved on the customers' account and the order may be reported to the warehouse section. If the credit card information was incorrect, the customer will be returned an SMS informing "Sorry, your credit card information could not be verified." The communication between the ordering central and the payment solution goes via the Internet through a secure SSL connection (sockets, the web, ...).

If everything was correct, the product supplier informs the warehouse section on the new product order via telephone, fax, email, or SMS. This transfer of the product order may be accomplished digitally, as the ordering interface provides a digital transfer of customer and order information between the customer and the provider of the mobile e-commerce system.

The warehouse section of the product supplier is informed on the product order in the most convenient way; via email, a telephone call, fax, or SMS. The billing process is also fully digitized, and the invoice accompanying the product is written from the program. The digital handling of the purchase ends in the warehouse section of the product supplier, where the ordered products must be packed and sent to the customer, e.g. by mail.

The ordering form

Various methods may be used for developing an ordering form. The method selected primarily depends on the products offered by the supplier and the manner in which the product supplier advertises. Examples includes:

• Spontaneous purchase of a product;

• "Top 5" list;

• Ordering from a catalog using ordering number and the number desired. Spontaneous purchase - scenario at the tram or subway:

The product is advertised on a large poster in the city, a billboard, or the like. In the advertisement, the telephone number to the ordering central is provided, together with a code word for the textmessage that uniquely identifies the product for the product supplier. The customer sends a message to the given phone number containing the code word stated in the advertisement. On the receipt of the "order-SMS", the ordering central stores the code word together with the telephone number to the sender of the order-SMS. The ordering central then returns an SMS to the sender/customer containing a link to the ordering form. In this case, the ordering form only contains the address display (Figure 6), the credit card information display (Figure 4), and the shopping cart with a "send" function (Figure 7).

Flyer - advertising using a "top 5" list:

A product supplier may pick its five most popular articles and put them together in a flyer that is handed out on a shopping mall, laid out in canteens, etc. In this case, the code word is simply "order", or the company name of the product supplier, or whatever desired. Having sent the initial message, the customer is returned an ordering form listing the "top 5" products, so that the customer only have to select the number of the desired products. Of course, also in this case it must be possible to provide address or billing information.

A number of variations are conceivable: The price could be included in the "top 5" product list; also the weight could be included, as it is important for the freight charges. The ordering form, on selection of a desired product, could calculate (price x number) and (weight x number) and finally sum up, so that the customer knows the exact total cost of the order before pressing "send".

Ordering from catalog - scenario by the kitchen table:

It is also possible to make an order from a catalog. In this case, it must be possible to provide the product/ordering number as well as the desired number of the ordered product. The billing information and ordering form are the same as in the above example.

In any case, it is possible to integrate the relevant data from the previous communication in the ordering program itself. It could be that the address information from the customer can be extracted from a database and integrated in the form itself before it is downloaded to the customers mobile phone. If the program is later opened on the telephone, the address form is already filled with the customers registered living address. The customer only needs to change the address information if the goods are to be delivered elsewhere. If a customer orders a given product in a first SMS, he does not have to reenter the selected product next time the ordering program is opened on the telephone. In that case the previously requested product is already filled in and more products may be added, if desired.

When the ordering program of a vendor is installed on the customers mobile, it may be reused again and again for ordering and paying for products from the vendor. However, it may be necessary or desirable to inform the customer on a new top offer, price change, or the like. Especially with respect to an embodiment in which the public key of the ordering central is included in the program, a communication channel will be important, as the program may have to be renewed, or is no longer valid if the private key has been lost or compromised, or the like. Encryption will be discussed in more detail below.

At a menu item "actualize", the customer may receive current data from the ordering central to his or her ordering program. The communication in this process is preferably based on SMS, as an ordering program that is able to send SMS messages is also able to receive SMS messages. Anyhow, if the mobile phone doesn't support sending and receiving SMS messages by the program, the communication may also be accomplished via http/WAP or the like across suitable communications networks (mobile Internet, GPRS, 3G, UMTS, EDGE...).

Encryption Assuming the use of an underlying ssl or https protocol, a customer browses the Internet from a computer or a mobile phone (http/WAP) and receives as a response to a request to an ssl server a public key from the ssl server. The key is normally signed by a superior authority (CA - certification authority). The corresponding certificate has been sent to the browser in the response from the ssl server, and contains name of the superior authority that certified the key, the public key itself, the signature of the public key, generated by the superior authority the owner of the public key, etc.

The public key from, the ssl server is then used for encrypting a symmetric key, which is in turn used for encrypting the sensitive message.

In the present system, a customer only contacts the ssl server of the ordering central, which has sent the ordering program, and not any ssl server. Further, the communication in the present system is preferably made via SMS (Short Message

System, GSM).

Thus, we need to find another way of transferring the public key from the ordering central to the midlet/ordering form on the customers mobile phone. One possibility is to integrate the public key of the ordering central in the ordering program itself, before it is downloaded to the customers mobile phone.

The corresponding private key, on the other hand, resides in the ordering central, most preferably protected by a password. It must be made sure that no attacker is able to get to the private key of the ordering central.

Thus, data is encrypted at the telephone side and decrypted at the ordering central, so that the data transfer from the telephone to the ordering central via SMS (GSM) or http/WAP over mobile Internet/ GPRS/ etc., is secure. Preferably, the encryption algorithm used is RSA (invented by Rivest, Shamir, and Adleman), but any other Public Key Algorithm may alternatively be used (such as ellyptic curves), as long as it is supported by the underlying cryptosystem (e.g. Bouncy Castle, Phoas, jNeo,...). The purpose, hence, is to encrypt a short message using the public key on a mobile phone or another hand-held device, which message may only be decrypted using the corresponding private key, which is located in the SMS gateway/ ordering central.

In the present ordering system RSA is used as the public key algorithm. As mainly short messages are processed, it would be possible to encrypt the entire order using RSA. The public key of the ordering central or a bank may then be included in the ordering program itself, which is in the form of a midlet, for example, that is sent to the mobile phone in response to the first initiating message. This public key should be certified by a CA (Certification Authority), thereby allowing the signature of the public key of the ordering central to be verified on the mobile phone. As for the time being we may not assume that a mobile phone contains preinstalled certificates from known certificate authorities (CA's), we also have to attach the public key of the certificate authority that has certified (signed) the public key of the ordering central. It is also possible that the ordering central itself signs its own public key before it is sent.

The credit card information is encrypted with the public key before the order is sent from the mobile phone, so that only the ordering central is able to decrypt the content in the ordering message, which is preferably sent by SMS. The encrypted message is transferred via SMS in the form of binary data, so the server/SMS gateway in the ordering central must be able to receive binary data - which is not the case for all SMS gateways today. If the mobile phone does not support sending SMS messages from the ordering program, the order may be transferred by way another communication protocol across another communications network (such as WAP, http across mobile Internet/ GPRS, 3G, EDGE, UMTS, and so on).

In the case of longer messages, the ordering program on the mobile phone may also generate a symmetric key in order to be able to encrypt the message using a symmetric algorithm. The symmetric key is then encrypted with the public key from the ordering central directly on the mobile phone, so that the symmetric key may be decrypted with the private asymmetric key in the ordering central. Then the actual payload message, which has been encrypted using a symmetric algorithm (DES or IDEA, for example), may be decrypted.

Not only credit card information, such as credit card number and expiry date, but also the entire message including name, address information, and product orders, may be encrypted with the public key of the system provider. If the message becomes too long for a public key algorithm, a symmetric key is generated on the mobile phone, which is then encrypted with the public key of the system provider, and so on, as discussed above.

The entire ordering form may be signed with the private key of the ordering central, so that the mobile phone may automatically verify during the installation that the midlet has not been changed during the transfer. However, not all mobile telephones allows installation of such signed midlets.

Regardless whether the ordering program can be signed or not, the ordering central must ensure that no attacker is able to insert a forged/incorrect ordering program/key on the server of the ordering central. Thus, using appropriate firewall functions, the ordering central must make sure that no attacker is able to break into the system - also due to the private key, that any other party must be prevented access to. In addition, the ordering program itself may be hashed in the ordering central, and the hash code stored at a suitable location. If a customer "orders" the ordering program by clicking on the link sent in the second SMS, the server program generates the current hash code from the ordering program. Then the new hash code is compared to the previous, stored hash code. Only if both hash codes are equal, the ordering program has not been tampered with, and may be sent to the customers mobile phone as a response to the http request. If all mobile phones are able to install signed midlets, it will be sufficient to make available a signed ordering program on the central server. The mobile phone will automatically verify the signature at installation time. It must also be verified that the signature has in fact been generated by the ordering central, which ensures that the customer installs the correct ordering program on his or her mobile phone. The fingerprint of the key that is used for generating the signature may be sent in an earlier SMS to the customer, in which he is also informed that an SMS containing a. link to an ordering form will follow. We advise the customer to write down the fingerprint on a piece of paper for its verification after the program has been installed. Following the installation, the customer may be displayed a menu item in the ordering program: "Verify the fingerprint". In this connection, the fingerprint of the public key of the ordering central, which is used for encryption, is popped up on the display - and the customer should compare it with the fingerprint he received in the previous SMS. Only if they are equal, the ordering program is correct, that is, the customer has installed an ordering program having the correct public key of the ordering central. This will be discussed in more detail in the section "Man in the middle attack".

A customer may also verify the url from the WAP push itself before installing the ordering form. The initiating communication goes via SMS across the telephone company's network, so it is most likely not possible to forge the url to the ordering form. Even so, it is possible to send the correct url to the customer before the actual WAP push, in a message that also announces that he is about to receive an SMS containing a link that he may open to install the program on the mobile phone.

When using SMS, the ordering central receives the mobile phone number from the customer that wishes to order the products from a vendor, and, as explained earlier, the customer will therefore be authenticated by the mobile phone number. The mobile phone number is unambiguous, at least if a customer that takes out a new mobile telephone subscription has to show some identification - as is now a regulatory requirement in Norway, among other countries.

The system may comprise several product suppliers. These may each have their own midlet including a public key, or the system may have a common midlet including a public key. The advantage of having a common midlet and public key is that the communication may be directed to a common central, which, after receipt of the digital order data, may forward the order to the appropriate product supplier. "Man in the middle attack"

A very severe attack against any encryption system based on public keys is the so-called "man in the middle attack". In an ssl protocol, e.g. in an e-trade communication, this attach may take place as follows: A customer receives through an http response a certificate from an ssl server. Using this certificate, the customer web browser encrypts a symmetric key that is used for encrypting the sensitive content. If an attacker is able to send his public key to the browser of the customer, without the customer noticing, only the attacker will be able to decrypt the symmetric key and thereby the sensitive message. Such an attack may happen, for example, in that a customer receives from an attacker a page looking absolutely identical to the correct net bank, but having a completely different url/http address.

Carried over to the present system for mobile e-commerce, this means that a customer downloads a midlet/ ordering form containing the public key of the attacker instead of the public key of the ordering central. The ordering form may otherwise appear to be identical to the original. In this case, the ordering central is not able to decrypt the sensitive credit card information - assuming that the order appears at the ordering central at all, which would be very unlikely on such an attack. Only the attacker then, has access to and may decrypt the message. After the implementation of the security procedures as explained above, this attack is only possible if an attacker is able to replace the correct ordering form with the attacker's own ordering form on its way from the server before reaching the mobile phone.

At least two methods may be used for preventing the "man-in-the-middle-attack": Method 1 :

The first variant, as discussed above, is that the entire ordering form is signed with the private key of the ordering central. The signature is verified during the installation from the mobile phone, and the customer must verify that the signature has in fact been generated at the ordering central. Thus, after the installation and the automatic and purely technical approval of the signature of the key, the customer must open the certificate manually. The certificate is sent with the ordering program and used for verifying the signature. The customer must hence verify manually that the public key that is used for signing the public key of the ordering central is in fact the public key of the ordering central or certificate authority. The fingerprint of the public key must be located somewhere else than in the ordering program itself. Either in the advertisement, in an earlier SMS that informs the customer that he is about to receive an SMS containing a link to an ordering program, on the web pages of the ordering central, or elsewhere. This process is known from the download of open software - such as the download of tomcat, apache, tools for xml processing, and so on. The method is one hundred percent secure, but the certificate verification as such may be somewhat difficult to implement practically.

This "man in the middle attack" poses a threat to any e-commerce solution. In a strict cryptographic sense, it is also essential that a user of an e-commerce solution checks who has issued the signature of the certificate from the ssl server. However, in practice, this is only rarely or never actually done. In an ssl protocol there is only a technical check that the signature is verifiable, that is, if the issuing certification authority (CA) is known to the browser. If the browser accepts the signature, i.e. that the superior authority (CA) that issued the signature is known to the browser, the customer is not allowed to check who has issued the signature. Only if the superior authority is not known, the certificate itself pops up in the browser, and the user can see who has generated the signature and is asked is he wishes to accept the certificate. The only security in this case consist in that the user should check the url from the ssl server to verify that the user has actually ended up at the correct server. However, first of all, the URL can most probably be forged in a well-planned attack. In addition, the attacker will have time to get hold of the encryption code in the web page on its way from the SSL server to the customer, and then intercept the credit card information, which is now encrypted with the key of the attacker, on its way back from the browser of the customer to the SSL server. Neither the customer nor the SSL server will detect the attack. The problem with method 1 is not only that it is difficult to carry out in practice, but also that not all mobile phones currently support the installation of signed software.

Method 2:

Not all mobile phones are able to install signed programs, and it is difficult for a customer to check if the signature has been generated at the ordering central or not. However, we still have to be able to guarantee that an order has been encrypted with the public key of the ordering central. This problem may be solved as follows:

A fingerprint is a hash code such as an MD5 function, for example. A hash code is an irreversible function, so that it is not possible to calculate the original value from the function value/ fingerprint.

One possibility is that the fingerprint of the public key of the ordering central is calculated, and then, after the installation, the fingerprint is verified automatically by the program or manually by the customer on the mobile phone. However, if an attacker has got hold of the ordering program and slipped in his own public key, he will also be able to tamper with the fingerprint itself.

However, as we want to guarantee that the public key of the ordering central correctly has ended up in the ordering program installed on the mobile phone, it must be included in the fingerprint. In addition, we need to have a secret, which is to be included in the fingerprint. As the secret, we may use any value from the ordering program. This is the case as the ordering form itself has been compressed by means of an "obfuscator". This is primarily done in order to compress the code as much as possible, so that it can be installed on small or low-resource devices, but also to prevent an attacker or competitor from decompiling the code to copy the order form. Thus, an attacker will neither be able to de-compile the ordering form code nor be able to read which secret has been used for generating the fingerprint.

We must also be able to defend ourselves against the so-called "replay-attack." That is, thus far it is possible for an attacker to send the initiating SMS to the ordering central, to receive the fingerprint and the ordering form itself in return. The attacker then knows what the fingerprint looks like, and is able to forge the ordering form. Therefore, it is also necessary to integrate a time stamp in the fingerprint. That is, on receipt of the initiating SMS, the ordering central inserts the current time in the ordering form - i.e. before it is being sent out, and now calculates the fingerprint using the same time stamp, the secret, and the public key of the ordering central. In this manner, the fingerprint changes from second to second, or in other appropriate time intervals providing an adequate level of security.

The fingerprint is sent to the customers mobile phone in an earlier SMS, which also informs the customer that an SMS containing a link to the ordering form will follow. Hence, the fingerprint is sent to the customer as a secret in a separate message after the initiating message. As the second message is an SMS sent across the telephone company's network, this is definitely sufficiently secure - and feasible.

Following the installation of the ordering program, the customer must select a menu item "Check fingerprint!", and the program, having received the current time from the server before being sent and knowing the secret and the public key of the ordering central, now recalculates the fingerprint.

The customer has written the secret fingerprint from the previous SMS on a piece of paper, and may now verify that the fingerprints are identical.

Thus, an attacker is not able to calculate the fingerprint, to which the customer only has access through the previous SMS - as the fingerprint not only has been calculated from the public key of the ordering central, but also based on a secret and a time stamp.

In this manner we may counteract a "replay-attack", and at the same time guarantee that the correct key, i.e. the public key of the ordering central, has been used in the encryption. The fingerprint only has to be checked once after the installation, thereafter the menu item "Check the fingerprint!" may automatically be deleted from the program. The fingerprint itself does not have to comprise more than four digits, similar to a PIN code for the banking card (i.e. the first four digits, the last four digits, the next four digits after position x in the fingerprint...). The secret should be exchanged regularly - e.g. once a day, once a week, etc.

An attacker that has been able to replace the correct ordering form by his own form on its way from the server at the ordering central to the mobile phone, will not be able to calculate the fingerprint correctly - and hence the attack or any change of the program will be revealed.

Exemplary embodiment

The customer sends an SMS containing the codeword Securem SOS to 1933 and receives two SMS messages in return.

"You will now receive an SMS containing a link to a payment form, which you may download and install on your telephone". The message contains a fingerprint that should be checked after the installation: xxxx Please write down the fingerprint on a piece of paper, and verify, after the installation, that both numbers are equal by clicking on 'Check fingerprint!"¹.

The other SMS is a WAP Push containing a link to the program sos.jad on the server of the ordering central.

After the download and installation on the mobile phone, an ordering/payment form is opened, as shown in figs. 3 - 9, for example. The customer then enters name and address (not absolutely necessary for a donation transaction) as shown in figure 6. The credit card information form and the desired product are filled in (figure 4). The fields "product" and "sum" may be changed by the user and will be listed in the customers "my page" section and the vendors overview page. In the donation transaction in the exemplary embodiment, the preset values are as follows:

Product: SOS Barneby; Sum: 400.00 Nok. A credit card number field and an expiry date field. In the exemplary embodiment, the fields contain: Credit card number: 4444333322221111 ; Expiry date: 0707. In the embodiment shown, a window then appears that shows the order or credit card information in an encrypted form (figure 5). In most cases, this is performed automatically and is invisible for the customer.

Figure 7 shows a screen display with a shopping basket, so that the customer may check what he is about to order. The encrypted credit card information is sent to the central/SMS gateway, and the SMS message is decrypted at the ordering central. In the given example, the mobile phone is connected to the Paynet. The values for a "Test Merchant" is: agrnr = "101-NOK-TESTMERCHANT"; curry = "NOK", and is added. The information is then forwarded to the bank through an interface to a payment solution (Paynet, for example), in an encrypted form as shown in figure 10.

If the credit card information and "expiry date" from the customer are correct, the payment solution (in this case, Paynet) sends an "OK" in response to the ordering central. "The order", i.e. the money sum, mobile phone number, and name and address from the telephone book, is then transferred to the database at the vendor. The customer may then receive a "thank you" SMS as an acknowledgement of the "purchase", containing information on the clients "my page" section with a user name and password. The user name may be the customers mobile phone number, and in an international perspective, for example, the user name may be the last eight numbers of the mobile phone number (including the national code). The buyer/user of the mobile e-commerce system may have his own page in a database at the server of the ordering central, in which all purchases/transactions are tabulated. If the payment solution could not verify the credit card information, the customer receives a return SMS informing "Sorry, but your credit card information could not be verified", as shown in figure 11. Each vendor connected to the system has an overview page showing all orders with a user name and password in a database on a server at or associated with the ordering central. Having an overview of status of orders is very important for connection to a payment solution: The bank. must know when the products are sent - only after the products have been sent the amount may be drawn from the customers account. It may be that the customer returns the products within the 14 days free return period and demands a refund. The product may be returned later due to a defect - with a refund claim. Hence, a communication between the vendor and the bank through the payment solution interface is required, in the same manner as is practiced in any e-commerce solution.

In the preceding sections, embodiments of the invention have been described. However, further embodiments of the invention may also be devised by a man skilled in the art. The scope of the invention is defined by the accompanying claims.

Claims

1. A method for transferring digital data from a hand-held communication device to a central across at least one communications network, the method comprising receiving an initiating message from the communication device at the central, the initiating message having been transferred from the communication device across a communications network, characterized in that the method further comprises: sending a second message from the central to the communication device, the second message including a program providing an interface on the communication device for entering said data on the communication device; and receiving the digital data at the central from the interface on the communication device, the data being transferred via an SMS connection or mobile Internet.

2. The method of claim 1 , characterized in that the program includes a public key of the central for encrypting the digital data.

3. The method of claim 1 , characterized in that the program includes a certificate and/or public key of a superior certificate authority.

4. The method of claim 2, characterized in signing/certifying the public key of the central with the private key of the central, or signing/certifying the public key in the central by a superior certificate authority (CA), and integrating the signature/ certificate in the program, the program thus including a fingerprint of the signature of the public key of the central.

5. The method of claim 2, characterized in sending an additional message to the communication device before sending the second message, the additional message including a fingerprint of the public key of the ordering central.

6. The method of claim 2, characterized in that the program is hashed or signed in the central before being sent.

7. The method of claim 6, characterized in verifying the hash code of the program before the program is downloaded to the communication device.

8. The method of claim 2, characterized in sending an additional message to the communication device before sending the second message, the additional message including a fingerprint.

9. The method of claim 6 or 8, characterized in calculating the fingerprint as a hash code from a secret in the program, the public key of the central, and a time stamp.

10. The method of claim 9, characterized in verifying the fingerprint after download of the program to the communication device.

11. The method of claim 1 , characterized in that the second message includes a link to the program for downloading the program to the communication device over a mobile Internet.

12. The method of claim 1 , characterized in that the digital data is order data including customer data and payment information associated with a payment organization.

13. The method of claim 12, characterized in authenticating/verifying the customer data by querying a subscriber database at a network operator before sending/shipping at least one ordered product.

14. The method of claim 12, characterized in authenticating/verifying the payment information by querying the payment organization before sending/shipping the at least one ordered product.

15. The method of claim 1 , characterized in that the hand-held communication device is a mobile phone.

16. The method of claim 1 , characterized in that the initiating message and the second message are SMS messages.

17. The method of claim 1 , characterized in that the communications network includes GSM, GPRS, 3G, UMTS, or EDGE.

18. The method of claim 1 , characterized in that the mobile Internet includes GPRS, 3G, UMTS, or EDGE.

19. A server for processing digital data received from at least one communication device across at least one communications network the server comprising a database of the digital data, characterized in that the server further includes: a receiving device for receiving at least one message transferred by way of a communications network from the communication device, and a sending device for messages being transferred to the communication device by way of the communications network, the message including a program providing an interface on the communication device for entering the digital data on the communication device and for transferring the digital data to the server by way of an SMS connection or across a mobile Internet.

20. The server of claim 19, characterized in that the program includes a public key from the server for encrypting the digital data.

21. The server of claim 19, characterized in that the server comprises a private key for decrypting the received digital data.

22. The server of claim 21 , characterized in that the program is signed with the private key of the server.

23. The server of claim 19, characterized in that the program includes a certificate and/or a public key from a superior certificate authority.

24. The server of claim 20 or 23, characterized in that the public key of the central is signed/certified with the private key of the central at the central, or signed/certified by a superior certificate authority (CA), and the signature/ certificate is integrated in the program.

25. The server of claim 19, characterized in an additional message that is sent to the communication device before the message including the program is sent, the additional message including a fingerprint of the public key of the server.

26. The server of claim 19, characterized in that the program is hashed or signed in the central before being sent.

27. The server of claim 26, characterized in that the hash code is verified by the program before the program is downloaded to the communication device.

28. The server of claim 19, characterized in an additional message that is sent to the communication device before the message including the program is sent, the additional message including a fingerprint.

29. The server of claim 26, 27, or 28, characterized in that the fingerprint is a hash code from a secret in the program, the public key of the central, and a time stamp.

30. The server of claim 19, characterized in that the message includes a link to the program for downloading the program to the communication device through a mobile Internet.

31. The server of claim 19, characterized in that the server further comprises access to a communication channel for the transfer of information between the server and product suppliers.

32. The server of claim 19, characterized in that the communication channel is at least one of an email client, a telephone system, a fax gateway, and an SMS gateway.

33. The server of claim 19, characterized in that the communication device is a mobile phone.

34. The server of claim 19, characterized in that the messages are SMS messages.

35. The server of claim 19, characterized in that the at least one message is transferred via a communications network including GSM, GPRS, UMTS, or EDGE.

36. The server of claim 19, characterized in at the program is a midlet.

37. The server of claim 19, characterized in that the mobile Internet includes GPRS, 3G, UMTS, or EDGE.

38. The server of claim 19, characterized in that the program includes means for receiving messages from the server through an SMS or http connection.