WO2003050773A2

WO2003050773A2 - Method of managing lists of purchased goods

Info

Publication number: WO2003050773A2
Application number: PCT/DK2002/000834
Authority: WO
Inventors: Robert Elgaard
Original assignee: Beamtrust A/S
Priority date: 2001-12-10
Filing date: 2002-12-10
Publication date: 2003-06-19
Also published as: WO2003050773A3; AU2002358457A1; AU2002358457A8

Abstract

A method of managing lists of purchased goods, comprising the steps of: in connection with a payment for goods in a list of purchased goods, receiving Payment Medium Identification data (PMI data) identifying a payment medium of an identified registered user; characterized in that the method further comprises the steps of: linking the PMI data and the list of purchased goods together to a linked data entity; and transmitting the linked data entity to a list of goods computer server to subsequently make the list of purchased goods available to the identified user over a computer network, where the list of purchased goods is made available to the identified user in a collection of lists of goods, where each of the lists in the collection fulfils the criterion of being linked to the PMI data, and where the PMI data functions as a key for accessing the lists of purchased goods.

Description

Method of managing lists of purchased goods

Background

This invention relates to a method of managing lists of purchased goods, comprising the steps of: in connection with a payment for goods in a list of purchased goods, receiving Payment Medium Identification data (PMI data) identifying a payment medium of an identified registered user. The invention further relates to, in a payment computer system, a method of managing lists of purchased goods, comprising the steps of: in connection with a payment for goods in a list of purchased goods, receiving Payment Medium Identification data (PMI data) identifying a payment medium of an identified user; conducting an examination of the Payment Medium Identification data to determine whether the payment medium is valid.

Prior art Within trade and commerce it is customary to provide a customer, who has carried out a purchase, with a list of purchased goods, a so-called sales slip, in paper. The list of purchased goods defines the trade, typically by stating e.g. the name and address of the merchant, the date of the purchase, the purchased item(s) and their prize (s) . These sales slips often also function as a certificate of guarantee, which a customer, if he/she wishes to make a complaint about a purchased item, can use to verify that he/she is indeed the rightful owner of the item and to verify which date it was purchased. Typically, complaints for consumer goods can be made within a time period of one or two years, or even up to five or more years in case of special items, such as cars, washing machines, and so on. Thus, the individual customers have to save the sales slips for his/her purchases for a protracted period to be able to make such complaints as may arise.

The patent application WO 01/86 538 describes the principle of storing an electronic proof of a purchase on a user's mobile telephone in connection with a purchase made via e-commerce. This electronic proof is used to enable a vendor's server to fetch a detailed contract, which contains information about the purchase and a proof that the user has paid for the purchase; the transrαittal of the electronic proof precedes the delivery of the purchased item(s) to the user. However, WO 01/86 538 does not provide a solution to the problem that individual customers have to save the sales slips for their purchases for up to many years. Additionally, it is a security problem that sales slips for purchases without guarantee periods, e.g. everyday purchases of food, beverages, daily products, typically contains information about the payment media used. This information might be used fraudulently, for instance to order items over the Internet, if the sales slips are not brought along by the customer.

Summary of the invention

The above and other problems are solved when the method mentioned in the opening paragraph is characterised in that the method further comprises the steps of: linking the PMI data and the list of purchased goods together to a linked data entity; and transmitting the linked data entity to a list of goods computer server to subsequently make the list of purchased goods available to the identified user over a computer network, where the list of purchased goods is made available to the identified user in a collection of lists of goods, where each of the lists in the collection fulfils the criterion of being linked to the PMI data, and where the PMI data functions as a key for accessing the lists of purchased goods.

Hereby, an identified registered user can access the lists of goods for items he/she has purchased by means of a network connection to the list of goods computer server, e.g. over the Internet. In this way the identified registered user can entrust the keeping of the lists of goods to the list of goods server and he/she therefore no longer needs to have a paper sales slip. The collection of lists of goods can contain a listing of purchases made with the payment medium identified by the PMI data, where each list of purchased goods can comprise information about items covered by the payment, such as the name and address of the merchant, the date of the purchase, the purchased item(s) and their prize(s). The lists of goods should preferably be stored at the list of goods computer server for a protracted period of years.

It should be noted, that the linked data entity made up of the list of purchased goods and the PMI data can be constituted by the list of purchased goods and the PMI data related by any known linking, e.g. a pointer, sending the data to a specific address on a server, etc.

In a preferred embodiment of the method, the list of purchased goods exists in a markup language. Thereby, a range of vendors or merchants can store information on the list of goods computer server in a consistent way. Preferably, the used markup language is the Extensible Markup Language (XML) .

When the list of purchased goods is presented by the list of goods computer server by means of a style sheet language, the visual presentation of the list of purchased goods can be regulated, for instance so that the visual presentation of lists of goods on a computer monitor has the same visual appearance as the conventional list of goods in paper, the so-called sales slips. Preferably, the used style sheet language is the Extensible Stylesheet Language.

In the following, the term 'list of purchased goods" is denoted "list of goods" (LoG) for short, where the terms are meant to be synonymous. The term * sales slip" is meant to cover a conventional list of purchased goods in paper and the term 'list of goods" is meant to cover both the data, e.g. the XML data, representing the purchased goods and the presentation of the data in the list of goods, e.g. on a computer monitor.

In a preferred embodiment the payment medium is a mobile station. Mobile stations, typically known as mobile cellular telephones, are widespread and often used in everyday life; moreover, they typically have complex processing power and are light in weight and are therefore handy as payment media. "Mobile stations" are meant to cover the terms mobile cellular telephone, mobile telephone, mobile phone, mobile terminal, mobile radio communications unit, mobile communications unit, cellular phone or mobile. Finally, it should be stressed that the invention is not limited to a mobile telephone, inasmuch as it could as well be used in any wireless device or mobile equipment containing a SIM card and cellular communications means, e.g. a PDA with cellular communications means .

In another preferred embodiment the payment medium is a credit card, which is a widespread payment medium.

In a payment computer system, the method of managing lists of purchased goods, cited in the opening paragraph, further comprises the steps of: if the payment medium is determined to be valid, performing the following steps: transmitting the PMI data and the list of purchased goods to a list of goods computer server to subsequently make the list of purchased goods available to the identified user over a computer network; and transmitting an acknowledgement of the payment to the payment computer system. Consequently, the transmittal of a list of goods is bound to a determination of the payment medium as being valid. Thereby the list of goods is only transmitted if the payment is actually carried out.

The examination of the Payment Medium Identification data to determine whether the payment medium is valid can be performed in the payment computer system or by means of an intermediate computer server or by means of a network connection between the payment computer system and a bank server. The payment computer system typically is placed at a point of sale, e.g. a shop, a store, etc., where purchases of goods are typically performed by a customer collecting or choosing the goods he/she wishes to purchase, bringing them to the payment computer system and paying for them.

When the payment computer system is situated at a point of sale and the PMI data are transmitted locally from the payment medium to the payment computer system, a fast and safe transmittal of the PMI data can be performed. The term "local" transmittal of data is meant to be opposed to a data transfer performed over a radio communications network by means of satellites and by use of radio connections or a data transfer performed over a computer network. In local data transfer, the units typically communicate directly with each other without intermediate equipment. Typically the units performing the local data transfer are at a distance from each other of between about 40 cm to about 1 m; in some cases, though, the units performing the local data transfer are up to about 10 m from each other. However, the term "local" transmittal of data is not meant to limit the distance between the units communicating, whereas it is conceivable that the units could be at other distances from each other. The local data transfer could for instance be performed by means of Infrared signals (IR signals) , Bluetooth© signals or any other short-range communication mechanism.

In a preferred embodiment, the payment medium is a mobile station, and in a further preferred embodiment the transmission of the PMI data is performed by means of an application on a Subscriber Identification Module

(SIM) in the mobile station. This provides a fast and safe transmission of the PMI data, which transmission will typically be performed locally. When the payment medium is a credit card, another way of performing a fast and safe transmission is provided.

In yet another preferred embodiment, the PMI data are transmitted to an intermediate server that is arranged to conduct the examination of the PMI data against an intermediate database if the PMI data fulfils a criterion. This provides a fast examination of the PMI data, which is of great importance at e.g. points of sale, where the customers expect a rapid conduction of a payment. In a preferred embodiment, the criterion is whether an identified registered user of the payment medium is a trusted user, and in a further preferred embodiment the criterion is whether the payment medium is registered as being valid.

When the examination of the PMI data is forwarded to a payment authority server if the PMI data does not fulfil the criterion and the PMI data and information on the payment are examined at the payment authority server, the possibility of conducting a payment is provided, even if the criterions above are not fulfilled.

When the list of purchased goods data is transmitted upon detection of an acknowledgement of the payment, which acknowledgement is sent from the intermediate server or the payment authority server, it is ensured that the list of goods is transmitted only if the payment is actually carried out. In further preferred embodiments, the list of purchased goods exists in a markup language and wherein the list of purchased goods is presented by the list of goods computer server by means of a style sheet language. For instance, the markup language could be XML and the stylesheet language could be XSL.

Brief description of the drawings

The invention will be explained more fully below in connection with a preferred embodiment and with reference to the drawing, in which: fig. 1 shows a block diagram of a system for managing electronic transaction lists of goods; fig, 2 shows a flowchart of managing electronic transaction lists of goods; fig. 3 shows an example of a collection of lists of goods ; and fig. 4 shows an example of the structure of the representation of the collections of lists of goods.

Fig. 1 shows a block diagram of a system for managing electronic lists of purchased goods. In recent electronic payment systems it is possible to use a mobile telephone 107 with e.g. infrared or Bluetooth© communication capability as a payment medium in conjunction with a cash register CR 103 also known as a payment terminal.

The cash register 103 is able to output data identifying a payment, and to forward data identifying the payment medium and a registered user of the payment medium. The data identifying the payment medium and a registered user of the payment medium is provided by communication with or reading from the payment medium. Moreover, the cash register 103 is able to output lists of purchased goods data comprising information about the items covered by the payment.

This information is forwarded to a front-end server FE 104 located e.g. at a shop SD or at a service provider SP. At the front-end server FE 104 processing of the payment transaction is conducted. The Front end server can either serve a single or a plurality of cash registers; in the latter case, for instance a large super market could have 20 cash registers and just one front end server FE, or a single Front end server could serve the cash registers for different shops in a shopping centre.

Data relating to the purchased items are transmitted to the list of goods server LoGS 105 arranged to receive list of goods data and rendering the list of goods data accessible to a registered identified user, which server can be a web server or computer server suitable for housing a database and providing safe access thereto, and the payment transaction data are transmitted to a bank server BS 102.

Before the data relating to the purchased items are available for display or analyses, a user must activate a service. This activation can involve receiving a One- Time-Password (OTP) via an SMS to the mobile telephone 107. The OTP is then entered to a home-banking web service provided to the consumer via a personal computer. In a preferred embodiment, the cash register or payment terminal mentioned in the above will be comprised of two components: an ordinary cash register with a serial port; and a so-called pay-box also with a serial port for connection with the cash register, a network connection for the communication with the front-end/bank server, and means for communication with a mobile telephone (IrDa, Bluetooth etc.) or means (a pay-card slot) for reading a credit card. However, the pay-box could be incorporated as an integrated part of the cash register. Communication may be carried out via the Internet designated with reference numeral 101.

Fig. 2 shows a flowchart of managing electronic lists of purchased goods. The flowchart is divided into the following structural elements: a payment medium PM; a cash register or payment terminal CR; a front-end or intermediate server FE; a bank server BS, and a list of goods server LoGS. Punctuated lines separate the elements .

The cash register CR starts the processing in step 201 when items to be purchased are registered in the cash register. Step 202 designates Payment Transaction Data PTD information that identifies a payment of the items, e.g. the amount due for payment. This PTD information and Payment Medium Identification data are transmitted to the front-end or intermediate server FE where the information is subject to a preliminary check in step 204. Step 204 checks for e.g. whether the payment medium is registered as being stolen. If the preliminary check is not in order, a refusal of the payment is sent to the cash register in step 209. Alternatively, in step 205 it is verified whether the customer is a trusted customer. If the customer is not trusted (N) , a request for validation of the transaction data is sent to the bank server, where in step 207, the transaction is validated directly against the customer's account(s). If this validation indicates that the transaction can be carried out (tested in step 208), the payment transaction data are stored (in step 211) temporarily in a database at the front-end server. Alternatively, a refusal of the payment is send to the cash register in step 209. The payment is then refused at the cash register in step 210.

If the customer is found to be trusted (referring to step 205) , the Payment Transaction Data are also stored in step 211. Subsequently, in step 212, an acceptance of the payment transaction is sent to the cash register that accepts the payment in step 213. Additionally, a list of purchased goods is generated in the cash register and transmitted to the front-end server where it is stored temporarily in step 215.

At specified intervals or points in time, the List of purchased goods data (LoG data) and the Payment Transaction Data are transmitted to be stored at the list of goods server LoGS and to be registered in a bank server in step 217, respectively.

Further, in step 216 the List of goods data are made available to the user/customer or another authorised person via the Internet.

Thus, since the payment is validated either at the bank server or at the intermediate server FE, it is ensured that lists of goods are issued properly.

It should be noted, that even though the examples of the method have been related to points of sale, it is also conceivable, that the purchase of goods and the reception of the PMI data are performed over a computer network, e.g. the Internet. Fig. 3 shows a rough outline of an example of a collection 300 of lists of goods. The first column 301 indicates the ordering of the individual lists of goods, of which one is indicated by the reference number 305. The second column 302 specifies an example of PMI data identifying the used payment medium. Next, the column 303 indicates some of the data contained in a sales slip, e.g. the purchased items, and their prizes. As explained more detailed below, a preferred way of identifying the items purchased in the database in the list of goods server is by means of the EAN numbers of the items, EAN numbers relating to the EAN system described below. In fig. 3 the column 303 is meant to indicate only that the list of goods comprises the data on which goods have been purchased and at which prizes. The last column 304 contains the dates on which the purchases have been performed. It should be stressed that the collection 300 of lists of goods represented in fig. 3 is an example only of the contents thereof. Typically, the name and address of the retailers would also be included, whereas the PMI data would typically not be included once for every list of goods 305, but - on the contrary - it would rather be linked to the lists of goods by means of addresses on servers.

Fig. 4 shows an example of the structure of the representation of the collections of lists of goods. In fig. 4 the lists of goods are shown in relation to an identified registered user with the user name 400. The example is meant to illustrate that a user is typically in possession of more than one payment medium and to illustrate how the data can be structured for display to a user.

The reference numeral 401 indicates payments conducted with a first payment medium; the reference numeral 402 indicates payments conducted with a second payment medium, and 403 indicates payments conducted with a third payment medium. The reference numerals 404, 405, 406, 407 indicate payments performed with the first payment medium at a first, second, third and fourth retailer, respectively.

It should be stressed, that the structure of the representation of the collections of lists of goods shown in fig. 4 is exemplary only and that a plurality of variations are conceivable. The payment media used are for example one or more mobile telephones and/or one or more credit cards. However, it is also conceivable that purchases conducted by means of cash payment could also be included in the collections of lists of goods, as long as the purchase is made in connection with reception of PMI data. Of course, E-commerce purchases could also be included in the collections of lists of goods, in that they inherently contain transmission of PMI data.

Now follows a more detailed description of an example of the overall operation of a system performing the methods according to the invention as well as examples of data structures and formats used therein .

As noted above, the list of goods server can function as a repository for customers' sales slips, i.e. the paper slips customers receive that specify the purchase, e.g. name and address of the retailer, date, time of day, the purchased items and their prizes, total amount paid.

The system handling the list of goods server, the access to the services of the list of goods server for retailers and customers/users, the necessary relations between the following: the cash registers of the retailers, the intermediate servers, the PMI of the customer's payment media, the bank server, etc., is denoted the "list of goods system". When a retailer enrols to the lists of goods system to obtain access to use the services of the list of goods server and offers these services to his customers, the cash register of the retailer will obtain a relation to a front-end server, a so-called bank gateway. This bank gateway will have its own private key rendering it capable of digitally signing messages. The list of goods server will have the corresponding public keys for all bank gateways.

When a customer makes a purchase, an electronic copy of the sales slip, the list of goods, is sent to the serving bank gateway in XML (Extensible Markup Language) format. The bank gateway issues a digital signature on the sales slip (the XML document) and forwards the list of goods to the list of goods server. The list of goods server verifies the signature, passes the XML document and writes each node of document into a relational database in the list of goods server. The list of goods server can at any time reconstruct a sales slip and re-verify the digital signatures. Hereby, the sales slips can be stored in the list of goods server and they can be used for analyses, statistics, graphic representations, reports and certificates of guarantee (also denoted warrants) for the customers. Also data mining for analysts and other professionals is an option. Preferably, the XSL language is used to present the XML data in the list of goods server to the user. The XSL language is a language for creating a style sheet that describes how data sent over the Web using the XML are to be presented to the user. For example, in a set of XML data that describes the characteristics of one or more super markets, a set of open and close tags might contain the name of a supermarket. Using XSL, you could tell the Web browser that the supermarket name should be displayed, where to display it on a page, and that it should be displayed in a bold font. In the same way, the other data in the set of XML data could be presented so that it look's similar to a sales slip, in case the set of XML data related to a list of goods.

It is important to stress, that the system enables enrolment of a wide range of retailers to the system, even internationally, thereby providing a customer with the option to access data from a greater part of all his/her purchases, even those made abroad, and thereby to perform analyses, statistics, graphic representations, reports and/or to issue warrants for a greater part or even all his purchases.

Customers, who wish to use the lists of goods system, must enrol to use the list of goods server. One possible way to enrol is to type in the GSM (Global System for Mobile) number to a web page on the list of goods server. The list of goods server generates a password for the customer - this password could be sent by SMS to the GSM number entered by the customer. When the customer receives the SMS containing his password, he/she is free to change the password to his own preference. This will ensure that impersonation is difficult and increases the security of the list of goods server. The password could function as the customer identification CID data, which is linked to the every list of goods, thereby providing a key for the access to the data of the specific customer in the list of goods server.

A preferred way of identifying the items purchased in the database in the list of goods server is by means of the EAN numbers of the items, EAN numbers relating to the EAN system described below. This makes managing of lists of goods uniform between different retailers, even internationally.

The EAN system is short for the EAN.UCC System, which is a common global language of business and is a set of tools that provide a standard way of uniquely and unambiguously identifying, tracking and tracing products, services and locations. It is a key, facilitating national and international communication between various trading partners. The EAN.UCC system is managed by EAN International through a network of national numbering organisations that allocate and administer the EAN.UCC Numbering System.

When a range of retailers, manufacturers, merchants, and so on has enrolled to the lists of goods system, the customer enrolled to the system is provided with the possibility of accessing data from a greater part of all his/her purchases, and thereby of performing analyses and statistics in a variety of ways. For example, he/she can deduct the amounts of money spent on specific categories of goods, amounts of money spent on those categories at different retailers, amounts of money or goods sorted according to date, retailer name, and so on.

Preferably, the list of goods server is also configured to support a warrant facility, whereby a customer can achieve a warrant of a purchased item, e.g. stating date of purchase, the retailer and specifying the item. This warrant could be available either in electronic form or be printed on paper or both.

When a customer needs to exercise the warrant facility of the list of goods server, he/she must first login to the list of goods server and fetch the list of goods containing the item for which the warrant should be raised. The customer can then click the "complain" button in the web page; this will open a new page where the customer can type in his complaint. After this the customer presses "send" and the selected sales slip with the digital signature is sent as email to the retailer from whom the item was purchased.

The retailer receives a complaint from the customer as an HTML-mail and after the retailer has verified the digital signature he can process the complaint.

Alternatively, the list of goods server can provide the warrant in a printable form, so that the customer can take a print of it and bring it to the retailer, e.g. along with the item in question. 11

An example of the structure of the format of the XML document transmitted from the payment terminal to the list of goods server is given below:

Example :

<?xml version="1.0" encoding="IS0-8859-l"?> <WEBSERVERINFO> <RETAILID>9999999999</RETAILID> <RETAILNAME>Name of retailer</RETAILNAME> <DATETIME>DDMMYY HH: TT : SS</DATETIME> <SALESSLIP> <BANKID>9</BANKID> <ACC0UNTID>9</ACC0UNTID> <USERID>40503701</USERID> <TRXID>9999</TRXID> <TEXT>

<ListOfGoods> <Header> <Linel>Retailer name verbose</Linel> <Line2>Retailers address</Line2> <Line3>ZIP and CITY</Line3> </Header> <Article> <count>9</count> <EAN>999999999999999</EAN>

<Total> <Text>TOTAL</Text> <Sum>9, 999.99</Sum> </Total> <Cash>

<Text> beamtrust</Text> <Value>9, 999.99</Val e> </Cash> <Salesman> <Linel>Description</ inel> <Line2>Name/number of cashier</Line2> </Salesman> <Footer>

<Linel>Date:dd.mm. yyyy time:hh.mm. ss</Linel> <Line2>P0S:9 Slip: 99999 Opr :AAAAAAAA</L±ne2> <Line3>Description</Line3> </Footer> </ListOfGoods> </TEXT> </SALESSLIP> </WEBSERVERINFO>

In the above example, the information between the tags <RETAILID> and </RETAILID> identifies the identification (ID) of the retailer, and the information between the tags <RETAILNAME> and </RETAILNAME> provides the name of the retailer. Likewise, the information tagged "DATETIME" provides the date and time of the purchase and is provided from the cash register. Thereafter, the structure provides for banking information ("BANKID", " CCOUNTID" , "USERID"), which information is preferably provided from the payment medium. The information between the tags <TEXT> and </TEXT> provides the information listed on a sales slip. It should be noted, that it is well known to provide this kind of information, i.e. a list of purchased items with details regarding the item(s) and their prize (s), from a cash register to a computer server via a data port.

Moreover, it should be noted that the above is only an example of a possible structure of the XML document. In the following a specific example of the use of the above XML structure is outlined: Example :

<?xml version="1.0" encoding="ISO-8859-l"?> <WEBSERVERINFO> <RETAILID>0012345678</RETAI ID>

<RETAILNAME>Dreisler</RETAILNAME> <DATETIME>191102 14 : 46: 15</DATETIME> <SALESSLIP> <BFCID>K/BFCID> <ACCOUNTID>K/ACCOUNTID> <USERID>4050370K/USERID> <TRXID>296K/TRXID> <TEXT>

<Linel>Dreisler Quantum</ inel> <Line2>Otto Monstedsvej 1</Line2> <Line3>9200 Aalborg</Line3> </Header> <Article>

<count>1</count> <EAN>28</EAN> <Text> BUTTER</Text> <UnitPrice>9, 95</UnitPrice> <TotalPrice>9, 95</TotalPrice>

</Article> <Article> <count>1</count> <EAN>30</EAN> <Text> 1 L MILK</Text>

<Text> FRUIT MIXED</Text> <UnitPrice>25, 00</UnitPrice> <TotalPrice>25 , 00</TotalPrice> </Article> <Article> <count>l</count> <EAN>32</EAN>

<Text> GENTLEMENS ARTICL.</Text> <UnitPrice>185, 00</UnitPrice>

<Text>6 BEER TUBORG</Text> <UnitPrice>5,50</UnitPrice> <TotalPrice>33, 00</TotalPrice> </Article> <Total>

<Text>TOTAD</Text> <Sum>302, 45</Sum> </Total> <Cash> <Text> beamtrust</Text>

<Value>302, 5</Value> </Cash> <Salesman> < inel>You were served by:</__inel> < ine2>Amanda</ ine2>

</Salesman> <Footer> <Linel>Date:19.11.2002 Kl : 14.36.14</Linel> <Line2>Cash register:l salesslip: 2304 Opr :Amanda</Line2> <Line3>Thank you - call again</Line3> </Footer> </ListOfGoods> </TEXT> </SAl_ESS IP> </ EBSERVERINFO>

Claims

Patent Claims

1. A method of managing lists of purchased goods, comprising the steps of: in connection with a payment for goods in a list of purchased goods, receiving Payment Medium Identification data (PMI data) identifying a payment medium of an identified registered user; characterized in that the method further comprises the steps of: linking the PMI data and the list of purchased goods together to a linked data entity; and transmitting the linked data entity to a list of goods computer server to subsequently make the list of purchased goods available to the identified user over a computer network, where the list of purchased goods is made available to the identified user in a collection of lists of goods, where each of the lists in the collection fulfils the criterion of being linked to the PMI data, and where the PMI data functions as a key for accessing the lists of purchased goods.

2. A method according to claim 1, wherein the list of purchased goods exists in a markup language.

3. A method according to claim 1 or 2, wherein the list of purchased goods is presented by the list of goods computer server by means of a style sheet language.

4. A method according to any of claims 1 to 3, wherein the payment medium is a mobile station.

5. A method according to any of claims 1 to 3, wherein the payment medium is a credit card.

6. In a payment computer system, a method of managing lists of purchased goods, comprising the steps of: in connection with a payment for goods in a list of purchased goods, receiving Payment Medium Identification data (PMI data) identifying a payment medium of an identified user; conducting an examination of the Payment Medium

Identification data to determine whether the payment medium is valid; characterized in that the method further comprises the steps of: if the payment medium is determined to be valid, performing the following steps:

- transmitting the PMI data and the list of purchased goods to a list of goods computer server to subsequently make the list of purchased goods available to the identified user over a computer network; and

- transmitting an acknowledgement of the payment to the payment computer system.

7. A method according to claim 6, wherein the payment computer system is situated at a point of sale and the

PMI data are transmitted locally from the payment medium to the payment computer system.

8. A method according to claim 6 or 7, wherein the payment medium is a mobile station.

9. A Method according to claim 8, wherein the transmission of the PMI data is performed by means of an application on a Subscriber Identification Module (SIM) in the mobile station.

10. A method according to claim 6 or 7, wherein the payment medium is a credit card.

11. A method according to claim 6, wherein the PMI data transmitted to an intermediate server that is arranged to conduct the examination of the PMI data against an intermediate database if the PMI data fulfils a criterion.

12. A method according to claim 11, wherein the criterion is whether an identified registered user of the payment medium is a trusted user.

13. A method according to claim 10 or 11, wherein the criterion is whether the payment medium is registered as being valid.

14. A method according to any of claims 11 to 13, wherein the examination of the PMI data is forwarded to a payment authority server if the PMI data do not fulfil the criterion and wherein the PMI data and information on the payment are examined at the payment authority server.

15. A method according to any of claims 1 to 7, wherein the list of purchased goods data are transmitted upon detection of an acknowledgement of the payment, which acknowledgement is sent from the intermediate server or the payment authority server.

16. A method according to any of the claims 6 to 15, wherein the list of purchased goods exists in a markup language .

17. A method according to any of the claims 6 to 16, wherein the list of purchased goods is presented by the list of goods computer server by means of a style sheet language .