AU2021100297A4 - A commodity trade value transaction system, and a commodity trade value transaction method - Google Patents

Abstract

The present invention discloses a commodity trade value transaction system and a commodity trade value transaction method that provides alternative payments means to customer purchasing goods. 3/11 133987HT Completed Registration in Proces Yes Read Customer Tokens and POS and Pavment due Sossible Pavment options Ask customerto insert car' Start Rule and Priority Base Configure Rule and Priority in PT or connect mobile Payment 'Pouine from Business rule- set Read customer identification from PTor mobile Add Total Retrieve Customer e information from store DB Add Tym tal Ii Process DB Customer rYes information, set Rules anc 0 Prorty.'1 Add Total PT: Payment Terminal or •aAddTota other Identification Device -o POS: Point of Sale SW DB: Store CRM/Database Payment Addtotal Noo Sale Completion / Cancel Cancel Pur chase as denied fPayment completed Fig. 4

Description

3/11 133987HT

Completed Registration in Proces Yes Read Customer Tokens and POS and Pavment due Sossible Pavment options

Ask customerto insert car' Start Rule and Priority Base Configure Rule and Priority in PT or connect mobile Payment 'Pouine from Business rule- set

Read customer identification from PTor mobile Add Total

Retrieve Customer e information from store DB Add Tymtal Ii

Process DB Customer rYes information, set Rules anc 0 Prorty.'1 Add Total

PT: Payment Terminal or •aAddTota

other Identification Device -o POS: Point of Sale SW DB: Store CRM/Database Payment Addtotal

Noo Sale Completion / Cancel Cancel Pur chase as denied fPayment completed

Fig. 4

1/29 133987HT

A commodity trade value transaction system, and a commodity trade value transaction method Technical field

[00011 The present invention relates to a commodity trade value transaction system, and a commodity trade value transaction method.

Background

[00021 In retail stores, customers pay for articles at a manual or automated cash register in the store cash, credit card, debit cards or mobile phone payment systems. Traditionally, when the customers paid using cash, the cashier at the cash register would count the cash, enter the amount into the cash register, calculate the change and dispense change to the customer. The store manager would have to keep track of cash put into the cash register in the morning and repeat the process again in the evening when the cash was returned to a safe for storage. The store manager would also have to transport the cash to a bank for deposit, typically carrying the cash to a night safe. The manual cash handling involved risk of loss, theft, as well as personal injury in case of robbery. To alleviate some of these risks a large business of closed cash handlings systems and armoured cash collection services has emerged. After the cash has reached the bank or cash handling provider, the cash undergoes cash processing where coins are sorted and stacked in coin rolls. The bank or cash-handling provider sell the coin rolls back to the merchant with a surcharge, sometimes even surpassing the value of the coin roll. Cash, and in particular coin, management is a substantial cost for the stores.

[00031 Currently any merchant or retailer are expected to return physical change back to any shopper or customer buying services and products from the merchant, and paying with cash. The amount of coins and notes in circulation poses a major environmental problem from the use of metals, cotton, linen and the transportation etc. to support the cash payment to be supported in the society. There is about 6 trillion coins in circulation. This amount of coin can be visualized as 31 stacks of coin reaching to the

2/29 133987HT

moon. TheCO 2 emissions from the armoured cars transportation of cash worldwide exceeds by far the total CO 2 emissions from all airline traffic in the world.

[00041 The customers are changing their preferences for the means of payment and many customers simply want to avoid cash, as electronic means of payment are more convenient and secure. Still, as there is lots of cash in circulation most people receive cash on a regular basis. This cash is a hassle and most people prefer to get rid of the cash at the first possible occasion. In addition, the merchants pay a substantial cost from handling the cash and they are seeking a cash-less payment scenario.

[00051 The patent application herein addresses these problems by allowing a major reduction of cash in the society by breaking the cash cycle (pay/receive many times) incurred from any cash that becomes available. Additionally the patent application describes a smart way to control the flow of cash and allows for alternative uses of the change that becomes available from cash purchases.

[00061 Today's POS and payment solutions in commodity trade and service industries, including payment "over disk" where bank cards, mobile payments, ID-based payments or other forms of payment are used, have little flexibility, as only one source of funds is associated with the form of payment. Typically, this includes a bank account with or without credit.

[00071 This means that customers as payers may end up without coverage for purchases because the funds on affiliated account are limited. Summary of the Invention

[0008] According to a first aspect, the invention provides a commodity trade value transaction system, at least comprising: a) one or more POS-systems (in store), b) one or more payment terminals, at least configured to communicate with the one or more POS-systems, c) means of payment, d) reading means embedded in the one or more payment terminals configured to read means of payment data and optionally means of payment holder data,

3/29 133987HT

e) at least one customer data base, f) a first processor with processing means and memories (included in the POS) for process of payment data associated with payment data holder and customer data, where the customer data is mapped with payment data holders, g) a first set rules algorithm run by the first processor, h) a first decision machine configured to receive first set rules output of first set rules algorithm and further configured to, based on received data, decide further transaction sequences, i) at least one token/ID-matching server, configured to hold customer data, j) at least one second processor included in the token/ID-matching server configured to execute a second set rules algorithm, k) a configurator of the token/ID-matching server is configured to receive output from the second set rules algorithm and based on the received output from the second set rules algorithm to configure further transaction steps, I) an execution machine configured to interface with the configurator and execute further transaction steps based on the output from the configurator, m) the execution machine includes at least one second decision machine configured to receive further execution steps from the configurator and configured to receive input data from the customer and further configured to, based on input, to make a choice for means of payment for concluding a commodity value transaction.

[0009] According to another aspect of the invention it is disclosed a commodity trade value transaction method at least comprising the steps of: a) initialising the commodity trade value transaction method at completed registration of commodities to be purchased by a first customer, the initialisation is initiated by: i. the first customer communicates a payment process request to a point of sale, POS, or

4/29 133987HT

ii. a cashier communicates a payment process request to the POS, and b) the POS initialises an ID step for identification of the first customer, c) the POS initialises a profile acquisition step, acquiring profile data of the first customer, d) the POS initialises a payment process where acquired profile data of the first customer together with the final amount due for the commodities to be purchased by the first customer is used as input parameters for the payment process, and e) the POS initiates a complete sale step.

[00101 The ID step for identification of the first customer may further comprise the sub steps of: bi) POS forwards a Request ID Input message to a payment terminal, bii) POS simultaneously or substantially simultaneously forwards a message to the customer with a message which invites the customer to show his identity and a message is forwarded to the cashier with a message that invites the customer to show his identity, biii) the cashier invites the customer to show his identity, biv) the customer shows his identity to the ID Input of the payment terminal, bv) the ID Input of the payment terminal sends an ID value to the POS, hence the customer Identity becomes known to the POS.

[00111 The POS may simultaneously or substantially simultaneously forward a push message to a display screen visible to the customer with a message that invites the customer to show his identity and a push message is forwarded to a display screen visible to the cashier with a message that invites the customer to show his identity.

[00121 The step biv above may at least include one of the following sub steps: * the customer initiates a data exchange between data holding circuitry on a customer bank card and the ID Input of the payment terminal; • the customer initiates a data exchange between customers' mobile phone and the ID Input of the payment terminal;

5/29 133987HT

* the customer initiates a data exchange between data holding circuitry on a customer identity card and the ID Input of the payment terminal, and * the customer identifies himself manually to the cashier enters the customer personalia into the POS

[00131 The profile acquisition step acquiring profile data of the first customer may further comprise the sub steps of: ci) at the POS generate a request for customer profiles message; cii) from the POS forward the request for customer profiles message to a store database holding customer profile registries; ciii) from the store database generate a customer profile message; civ) from the store database forward the generated customer profile message to POS; cv) from the POS generate and send a request for customer profile to a token server; cvi) at the token server generate a customer profile / payment configuration message; cvii) at the token server forward the customer profile / payment configuration message to the POS, thereby acquiring profile data of the first customer to the POS. The step ciii) may further include a foregoing step of: at the store database look up match between payload of received customer profile message and registry entries, if match = true, then generate a customer profile message based on content of matched registry entry. The step cvi) may further include the foregoing step of: at the token server look up match between payload of received customer profile message received from POS and registry entries in a token server database, if match = true, then generate a customer profile message based on content of matched registry entry in the token server database and from the token server database return the generated customer profile to the token server and continue with sub step cvii) of claim 14.

[00141 In one aspect of the invention the payment process of step d) above may further comprise the sub steps of:

6/29 133987HT

di) at the POS generate a payment request message, the payment request message at least including: - invitation to the customer for use of highest priority payment means, - a counter value n=O - the amount due to be paid = Ssi - N,+1 = indicator of payment means and its priority number, where N, is highest priority payment means, - the number of payment means available to the customer: NA; dii) from the POS forward the payment request message to the ID Input of the payment terminal; diii) from the ID Input of the payment terminal forward the payment request as a payment call to a payment device of the payment terminal; div) at the payment device of the payment terminal request the customer to accept payment means No,,, if request is not accepted continue at step dviii); dv) at the payment device of the payment terminal generate a payment result status message based on at least one of the tests T1 and T2: T1: is A,.1 > S,1; T2: is n+1 = NA; P'+= A,+ 1 if T1= false P+1= S'+1 if T1= true where: A,+1 = available amount on payment means N,,i; Pn+1 is amount to be reserved on payment means N,. 1 generate a payment result status message with a payload, where the payload at least include: the logical value of T1 and T2; the amount reserved, P,,i, for later debiting of the payment means;

7/29 133987HT

values of A,1, S' 1 and NA, and priority number of payment means N,,i; dvi) from the payment device of the payment terminal forward the generated payment result status message including the payload to the POS; dvii) at the POS analysing the payment result status: if T1= "true" AND T2 = "X" then continue with sub step dx if T1 = "false" and T2 is "true" then continue with sub step dix); dviii) at the POS generate a payment request message with updated payload where the updated payload of the payment request message at least includes: - an updated new counter value: n=n+1 - invitation to the customer for use of a lower priority than previously ranked payment means, N-i, - an updated amount due to be paid: calculate remaining amount due to be paid: S,,,= S, - P, and include the remaining amount due to be paid in the payment request message, then continue with sub step dii); dix) cashier invites the customer to use cash to settle the remaining amount due to be paid or the POS cancels the commodity trade value transaction and finishes the payment process; dx) at the POS finishing the payment process.

[00151 The step div) may further include a foregoing step of: at the payment device receiving the payment request and forwarding to a display means associated with the payment device an input request to the customer where the input request includes the payment means priority number N,1 and a request to choose or not choose the payment means with the priority number N,1.

[00161 Other advantageous features of the present invention will be apparent from the accompanying claims.

8/29 133987HT

Brief Description of Drawings

[00171 Embodiments of the invention will now be described with reference to the following drawings, where:

[00181 Fig. 1 shows a flow chart of a transaction method;

[00191 Fig. 2 shows a detail A of the flow chart in fig. 1;

[00201 Fig. 3 shows a detail B of the flow chart of fig. 1

[00211 Fig. 4 shows a flow chart of a transaction method taking place after a completed registration in a POS has taken place;

[00221 Fig. 5 shows elements in a transaction system;

[00231 Fig. 6 shows a sequential diagram of a transaction method in a transaction system;

[00241 Fig. 7 shows an example of a declined transaction in a transaction system;

[00251 Fig. 8 shows an example of a display device indicating an alternative transaction process;

[00261 Fig. 9 shows an example of a display device indicating an alternative transaction process;

[00271 Fig. 10 shows an example of a display device indicating an alternative transaction process;

[00281 Fig. 11 shows an example of a display device indicating an alternative transaction process;

[00291 Fig. 12 shows an example of a display device with text in a transaction system;

[00301 Fig. 13 shows an example of a display device with text that invites a user to confirm personal information or to deliver personal information to a transaction system;

[00311 Fig. 14 shows an example of a display device with text that invites a user to confirm personal information to a transaction system;

[00321 Fig. 15 shows an example of a display device indicating a finalised alternative transaction additionally a printer confirming the alternative transaction is shown;

[00331 Fig. 16 shows an example of a display device with text in a transaction system; and

9/29 133987HT

[00341 Fig. 17 shows an example of a display device indicating an alternative transaction process.

Detailed description

[00351 The present invention will be described with reference to the figures.

[00361 The present invention provides transaction solutions that allows a reduction of cash in the society by introducing new and alternative payment means/options.

[00371 In retail stores, customers pay for articles at a manual or automated cash register in the store cash, credit card, debit cards or mobile phone payment systems. According to the invention transactions finds place between a customer at a retail store and a point of sale system in the same retail store. The POS on its side has communication means for communicating electronically with servers external to the POS and with the customer.

[00381 In the present invention a Central Database Customer Repository is used to describe a shared and centralized customer controlled service, where the customer may define if they want to receive cash change and if they in detail prefer to receive only notes or coins at certain denominations (only $1 for example) when receiving change. For security reasons a preference to never receive more than an upper limit is one of many possible preferences a customer may have. Alternative uses of cash into savings accounts, loyalty programs, lotteries, family member accounts and other receiver accounts or services applicable are also a part of this service.

[00391 In addition, the merchants may process the change pay-out as configured in their database information by customer, time of day, payment amount, change amount and by other preferences to optimize their cash management. The store and customer preferences are processed by the POS system to provide a balance of merchant interests and customers interests/preferences.

[00401 Today it is not possible to establish a credit or loan in a payment terminal if a customer lacks payment from his primary bank, it is an object of the

10/29 133987HT

invention to provide alternative payment solutions to a customer including establishing on site loans or credit.

[00411 A Central Database Customer Repository concept presented by the present invention provides solutions where a payment terminal and a POS is designed with new functionality to support payment from sources not available today.

[00421 There may be several parameters that indicate that alternative means of payment can be proposed and used: 1. Lack of coverage on account linked to payment means 2. Low balance on account associated with payment means 3. Market requests or other related affiliates 4. Season and promotional sales, for example, may be linked to cash back purchases or given products or services 5. Withdrawals from loyalty programs and adjust balance for these 6. Information related to the customer's relationship with the outlet, including "CRM" target management 7. The principle is that the customer's preferences/profile or outlets preferences/goals determine the payment method(s) that can be used rather than the payment means associated method determines this 8. The way identification of a customer is done or the payment method 9. Amount of purchase amount.

[00431 The list of parameters that may trigger use of alternative payment means is not exhaustive.

[00441 If one or more of the parameters 1 - 9 above matches then the payment terminal, mobile payment app, or other interactive payment systems/entities may suggest alternative forms of payment or solutions. These can be for example: 1. Transfer from another account belonging to the customer's account group 2. Payment using "loyalty points", gift cards or the like 3. Creation of micro loan / credit on exact payment amount from outlet or other sources

11/29 133987HT

4. Withdraw existing credit funds 5. Loan/credit on a "bulk amount", which increases the customer's available funds beyond current payment

[00451 Other available means or agents that may be made available.

[00461 Some of the elements in a commodity transaction system and method according to the present invention will be described below.

[00471 Point of Sale (System):

[00481 The point of sale system (POS) is normally a software application running in a personal computer or other hardware with a processing unit, random access memory and network access. The point of sale software may also include devices for item registration, such as scales, barcode readers, imaging devices and so on. Further, a payment terminal or other device communicating with external equipment such as mobile phones, using wireless signalling and similar may be considered a part of the POS system.

[00491 When a mobile device or external device or technology is used to identify a customer, such devices may also be considered as a part of the POS system in the context of the present invention, as they take part in the payment processing, which is a part of the POS system and checkout process.

[00501 In the following, a Sales Registration as shown in figure 1 is described using the reference numbers from said figure.

[00511 During this step, the items to be purchased are registered by the cashier and/or customer into the point of sale system. Subtotals, VAT amount and totals are being calculated and summarized.

[00521 Close Registration 101:

[00531 Whenever all items to be purchased have been registered, the cashier or possibly the customer will decide that no more items to purchased are to be registered and the POS system changes it mode to receive the means of payment.

[00541 Register Payments in POS system 102:

[00551 Different means of payments may be registered into the POS system, and they will be aggregated into a payment total to equal or exceed the

12/29 133987HT

purchase total. If a cash amount is being registered directly by the cashier as it is received manually, or the cash amount is being put into a cash recycler or cash validator, the POS may calculate that a specific amount of cash to be returned is due. If not, the POS system will complete the sale without any actions to return cash (change).

[00561 If the customer makes a partial payment with payment card, the POS may read the customer ID from the payment terminal (other device) / card and temporarily store this to be used if a customer also pays with cash requiring a change to be returned.

[00571 Read Store Configuration from database 103:

[00581 During the POS processing the POS will read the overall POS configuration in order to control its different operating modes. Settings in this configuration may have impact on how the POS process cash received and cash change that is to be returned.

[00591 Such setting may be used to control the selections of coins/notes to be returned, if the cashless electronic change mode of operation is allowed and more. If electronic change is set to "off" the POS will control a normal cash return 204.

[00601 Offer/show customer Electronic change option by asking for electronic change ID fig. 3:

[00611 Typically the POS will provide the customer a choice to use electronic change by showing a message like "Please register electronic change ID?" to inform the customer of the choice to make. This message can be shown on a fluorescent display or other display means facing the customer. The cashier may also give the same information by verbal or other means of signalling.

[00621 The customer may then use any of the implemented methods of 202 identification to identify themselves. Typically, this will include presenting a payment card, a device, a fingerprint or other identifiable measures to the payment terminal or a reader devices connected to the POS system. The registration may also be manual, by for example means of entering the customer phone number into the POS systems using a keypad or

13/29 133987HT

keyboard. Other means such as touch screen input etc. are obvious options to this process.

[00631 The ID read will then need to be validated/checked 203.

[00641 Customer ID Registration:

[00651 The customer may from the preferences decline to use Electronic change and then the normal cash based change pay-out routine is being executed by the POS and the cashier.

[00661 Send Customer ID Request for data and read Response 205:

[00671 If the customer registers a valid ID, the POS system will use the means of registration ID received and send a request to a central Database Customer Repository 206 ID/Token based central process service.

[00681 The ID (and type of ID) together with the merchant ID and the change amount is sent as a request to the central Database Customer Repository service for processing. This service will read the customer preferences (see: Background) 207 and return the cash-out option that the customer prefers together with applicable control information to control the pay-out process, back to the POS system.

[00691 The purchased items may be listed and sent to the central Database Customer Repository service as a part of the request mentioned. This information may be used to determine the customer preferences, and may be used to transfer a paperless receipt, aka e-Receipt, to be stored in the Central Database Customer Repository service databases.

[00701 Based on the customer's settings, the POS may be directed to not perform an Electronic change pay-out (unlikely) and then the POS continues by executing a normal change pay-out 204.

[00711 Process Store + Customer Electronic change settings:

[00721 By combining the store/merchant and the customer preferences the POS software program will be able to build a list of pay-out methods and amounts. The methods may be operations to be completed locally by control of the POS system and/or operations to be performed by the central Database Customer Repository service. The process to build the list and give the methods priority are done by normal business logic implemented by programming and best practices learning.

14/29 133987HT

[00731 Issue Coins 210:

[00741 If the methods of change pay-out (previous paragraph) includes the return of one or more coins, the cashier or a cash recycler typically will give or provide the coins to the customer.

[00751 Issue Notes 211:

[00761 If the methods of change pay-out (previous paragraph) includes the return of one or more notes, the cashier or a cash recycler typically will give or provide the notes to the customer.

[00771 Process Electronic change transfer using APP, Central Database Customer Repository and/or Payment terminal (Figure 2, 212):

[00781 To ensure pay-out to the customer by electronic means the POS system will further process the list of pay-out methods and use a payment terminal, a connected device, wireless devices or other local means to transfer the change amount in full or partial from the merchant holdings to the customer holdings, or other holdings that the customer has listed in its list of preferred pay-out targets.

[00791 When any locally (POS based) transfers have been processed the POS will send the status of the operations performed and request the central Database Customer Repository service to process any pay-outs and operations that are to be performed centrally.

[00801 When the central processing has been completed, the central service return the processing status to the POS system, optionally together with a printable text documenting the operations and confirmations needed on the customer receipt.

[00811 Complete Sale + Print 213:

[00821 The POS system will when getting the returned status back typically be able to commit or rollback the sale and any transactions involved. When committed the sale is closed and a receipt may be produced. This completes the POS sale + payment process.

[00831 When a purchase is due to be paid, the point of sale (POS) system will transfer the amount due to the payment terminal or the cashier (receiver of payment) will enter the amount due into the payment terminal (other devices may apply) manually.

15/29 133987HT

[00841 The customer will then insert or activate the payment method (card, mobile etc.) and allow the payment terminal to read the customer identification through the payment method identification. Then, the customer will typically enter a pin code or provide other means to confirm his or her personal identity.

[00851 The payment terminal (app, device, etc.) will then check the identity from the information provided. This step may involve contacting central servers/resources for the confirmation. If the identity is confirmed a payment request is sent from the payment terminal to the payment gateway/processor, that will ensure that the payment can be completed by checking with the holdings linked to the customer via a bank or other sources.

[00861 The above payment process as described is simplified and the actual process can be different.

[00871 An approved payment results in the payment terminal sending an "OK" message back to the POS system, or the payment terminal shows the result on its display and possible an attached printer. The POS system will either read the payment status from the payment terminal, or the cashier will input the payment ok status manually, whereby the sale is completed.

[00881 If the payment is declined for some reason this result is returned to the payment terminal, app, other devices, etc. and will be shown on the payment terminal display (i.e.), possibly an attached printer and also it's sent back to the POS system. The POS system may then not complete the sale as-is and the customer may get this information verbally from the cashier.

[00891 In effect, the payment request in current systems only has two possible outcomes; Accepted or Denied. Still the reason for Denied may also be due to other reasons than limited funds, such as technical problems, communication problems etc.

[0090] According to the present invention a situation where a purchase is due to be paid, the customer will be asked to pay by cash or insert a card or activate another payment method by other means (NFC, card, ID number, fingerprint, mobile app etc.) to allow the payment system to read the

16/29 133987HT

customer identification through the payment method identification. At some stage during the card insert / registration, the customer will typically enter a pin code, leave a fingerprint verification etc. or provide other means to confirm his or her personal identity. This identification can be for example a one-phase or a two phase identification method.

[00911 The payment terminal or other device/system/app will then check the identity and correctness of a (ie.) pin code from the information provided, like for example with the card issuer. This step may involve contacting central issuer/PSP servers/resources for the confirmation.

[00921 When the identity is read from the payment method / card issuer (typically by using a token = an anonymized ID value) the payment terminal will send the customer token/id to the POS system or other store systems to confirm the known customer identity, where the systems may perform pre-payment operations like checking the store internal databases and customer information system for relevant customer data. This in order to determine the type of payment preferred, supported alternative payment options and services relevant to the payment process. During this process the customer identity will also be sent to a Central Database Customer Repository Token/ID matching central to retrieve a list of available payment options and other profile/preference information valid for the specific customer.

[00931 The Central Database Customer Repository Token/ID matching central holds Token/IDs linked to a specific customer that has registered one or more Token/IDs with the central. The registration of a Token/ID may take place using the payment terminal, app or other devices or by using the POS system or by having the customer making a registration to be active with stores and payment system providers. Each Token/ID stored typically represent one or more customer to payment or store relationship(s).

[00941 The Central Database Customer Repository Token/ID matching process may also be run with selected stores and/or payment service providers independent from any centralized Central Database Customer Repository Token/ID matching central. As a result, the Token/ID matching may fully

17/29 133987HT

or in partial be separate from a Central Database Customer Repository Token/ID central. Either or both as mentioned is possible.

[00951 The communication with any off-premises (external) information systems and any internal back-office or database systems may take place directly from the payment terminal and/or from the POS / store system and/or by using other means/devices connected to the payment terminal and/or POS system, in order to complete the information retrieve process.

[00961 From the identification and Central Database Customer Repository Token/ID matching process, the data returned from this the POS / other store system (or the payment terminal if this is controlling the process) will learn which payment options are available to the customer and in which order these may or must to be applied. Such payment options may offered based on payment availability or business related preferences.

[00971 Such a list may be for example Ref figure 4: 1. Bank debit card available 2. Visa credit card available 3. Existing Credit balance may be used 4. Other linked accounts 5. A new Credit may be offered as an credit / small loan 6. Loyalty points available 7. Loyalty balance available

[00981 All, or some of the above list of available payment options may be collected after an initial debit/credit using a primary card has been attempted and then been declined or other controlled situations dictate the inclusion of different payment methods and sources.

[0099] Based on this information the POS / store system (or the payment terminal, app, device directly if it is controlling the process) will attempt the operations in sequence to ensure that a complete payment may be completed. Most often, this will include one single charge to a debit/credit card and no other operations may be required. Still a mix of payment methods can be applied based on the rules set in the different profiles and information systems.

18/29 133987HT

[001001 Using the example, if a bank debit and Visa credit charge both fails (may be same account in fact) a request is sent to a Credit system (without giving customer notification), with the customer Token/ID and the purpose of the purchase and the amount involved. This is then processed by the Credit system in real-time and the response may for example be positive, negative or conditional.

[001011 These are three examples of credit system responses: 1. Declined i. No amount may be paid on behalf of the customer. 2. Accept i. The amount can be accepted to be paid by credit system, by using the customer existing credit limit/balance. ii. Conditions like an interest rate, change to monthly payments etc. may be added together with documents like a loan/credit contract 3. Conditional i. The amount exceeds to available balance/limit, but an alternative lower amount as specified may be approved ii. Conditions like the interest rate, change to monthly payments etc. may be added together with documents like a loan/credit contract

[001021 The POS/store system and payment terminal will then notify the customer that the primary account balance is low, but that the payment may still be completed using the customer existing credit system. The customer may then choose to accept the credit charge, or decline the offer.

[001031 If the offer is accepted a new identity verification (manual or using pin code) may be required by the customer and if needed a paper based contract/information may be printed and if needed signed by the customer.

[00104] If the offer is declined by the customer the POS system and payment terminal may either cancel the full sale as-is, or allow a next (if any) payment options to be tried and if successful offered to the customer.

19/29 133987HT

[001051 The POS / store (=merchant) system may also provide the list of payment options to the customer, and allow the customer to choose (or attempt) the preferred alternative payment method.

[001061 Below is a sample sequence of operations where a credit card/account campaign is preferred for some customers. The reference numbers correspond with those in figure 5. The process is an example and some of the steps involved may be more complex in a real-world system and scenario.

[00107] A customer 9 wants to purchase of a new watch in a jeweller store 2. The cashier operating the POS/store/merchant system 6 will register the item in the POS system (app++) 6 and prepare the POS system 6 for the payment part. When the customer is ready to pay he/she is asked by the cashier operating the POS system 6 if he/she would like to pay with cash or a card 8 or use other payment methods 8.

[001081 The customer 9 responds by inserting a debit card 8 into the payment terminal 7. The payment terminal 7 then sends a request to check the card 8 validity to the bank (card issuer) 1, where the bank 1 typically will confirm that the card 8 is valid.

[001091 The payment terminal 7 will then request the customer 9 to verify his/her identity by entering a pin code on the payment terminal 7. The pin code is entered into the payment terminal 7 by the customer 9 and then the payment terminal 7 checks the pin code using its secure hardware against the card 8 information. If the verification succeeds the payment terminal 7 will send a message to the POS system 6 with the customer ID (i.e. Token) to inform that a valid payment card 8 and a verified customer 9 is present and ready to be charged/processed.

[001101 The POS system 6 will then request the store 2 system database and backend system for customer specific information (i.e. CRM system) and how the POS system 6 is to perform the payment process. For this example the POS system 6 is told to process the customer 9 in speak as follows:

20/29 133987HT

1. Offer this customer 9 an interest free, 30 day credit of $1000 offered by a credit provider 4 to complete the purchase, where $299 is charged directly to pay for the watch 2. If the customer 9 declines the offer, use the present debit/credit card 8 to charge the account 3. If the card 8 charge operation fails, allow the customer to pay using store specific loyalty points available. 4. If all of the above fails and/or are declined cancel the sale and payment in full

[001111 If the customer 9 accepts the 30 day interest free credit offer from the credit provider 4, a verification process is initiated as follows:

[001121 The POS system 6 (or payment terminal 7) sends a credit request on behalf of the customer 9 to the credit provider 4. The credit provider 4 checks the customer 9 financials and metrics in real-time and approves or declines the credit request by sending a response to the POS system 6 (or payment terminal 7). In the case of an approval the POS system 6

/ payment terminal will give the customer 9 the option to accept the credit offer. Assuming the customer 9 accepts the offer an agreement/account is created by the credit provider 4 and then the payment amount due is transferred from the credit provider 4 to the store 2 banking partner 1. The transfer of the payment funds from the credit provider 4 to the store 2 may also be settled using invoicing or other means typically used to settle the balance between different business partners.

[001131 Optionally additional steps may be performed to ensure the credit agreement is entered using the needed signatures and documentation.

[00114] A detailed sequence diagram is disclosed in figure 6. The sequence diagram shows interactions between elements in a transaction system for transactions. At the top of the figure the involved elements are shown whilst the sequences between elements is shown as lines/arrows between elements.

[001151 The ID Input can be an element in a payment terminal; however, it can also be a stand-alone unit, which is associated with the POS. In the

21/29 133987HT

event that it is a stand-alone unit it can exchange data through a protocol with the POS, however it may also exchange data through a protocol directly with a token server. A stand-alone ID Input can be an RFID reader, a scanner, an NFC reader, a Bluetooth receiver or a WiFi transceiver. An RFID reader can be used to read an RFID tag held by a customer that identifies the customer. A scanner can be used to read ID card of a customer or to read other credentials particular to the customer, which identifies the customer. An NFC transceiver can be used for data exchange between an NFC communication device associated with a customer, which identifies the customer, and the stand-alone ID Input unit. An NFC communication device can be included in a cell phone belonging to the customer, but it can also be included in wearables of the customer. Similarly, a Bluetooth communication device or a WiFi transceiver can be included in a cell phone belonging to the customer, but it can also be included in wearables of the customer.

[001161 It shall be noted that a two-phase identification as well as two-factor identification of customers can be effectuated in an embodiment of the present transaction system. By two phase identification it is meant that a customer in addition to showing his ID with one of the means indicated above he or she shall also authenticate ownership of the ID means by for example typing a PIN code, a Password or the like on a Payment terminal or a stand-alone ID Input unit. Signatures and biometrics can also be used in a two-phase system for verification of shown identity.

[00117] It can be instances when additional security is necessary in the event of a transaction, for example if a loan is negotiated and granted. In such instances, a two-factor system for identification and authentication of the customer may be used. A two-factor system is a system where the customer has two independent devices, which is associated with the customer. In one example, a first device can be an identity card and the second device can be a cell phone. A scenario can be as follows, a customer identifies himself on a payment terminal or on a stand-alone ID Input reader with a bankcard. If the data exchange between the card reader and a receiver such as a token server or a POS is OK, a second

22/29 133987HT

step is initiated where a text message is pushed to the customers cell phone, the text message invites the customer to verify his identity or the transaction between the first factor and the reader of the payment terminal or the stand alone ID Input unit. The two-factor method indicated is an example and other two factor means can be employed in a transaction system according to the present invention.

[001181 It shall be noted that devices belonging to a customer such as cell phones carries unique identifiers such as IMEI codes, MAC addresses, SEID etc. that in a secure manner identifies one factor in an ID-process, however in a one-phase system the association between the first factor and a customer is not verified. Two-phase systems verifies this association whilst two factor systems further increases transaction security.

[001191 In the context of this patent application it shall be appreciated that the notion "Payment terminal ID Input" shall include "ID Input stand-alone units" such as those mentioned above.

[001201 Reference numerals 1 Bank 2 Store 3 Token/ID matching 4 Credit 5 Payment processor 6 Point of sale system, POS 7 ID and payment terminal 8 ID and payment methods 9 Customer POS A point of sale is the time and place where a retail transaction is completed. At the point of sale, the merchant calculates the amount owed by the customer, indicates that amount, may prepare an invoice for the customer, and indicates the options for the customer to make payment. It is also the point at which a customer makes a payment to the merchant in exchange for goods or after provision of a service. After receiving payment,

23/29 133987HT

the merchant may issue a receipt for the transaction, which is usually printed but is increasingly being dispensed with or sent electronically. CRM Cash Recycler Machine RFID Radio Frequency Identity NFC Near Field Communication WiFi Wireless local area networking of devices based on one or more of the IEEE 802.11 standards. SEID Secure Element Identifier for secure transactions a SEID is commonly found in NFC enabled devices. ID Identification, i.e. identification information for one or more customers, interning to purchase goods in a retail store.

Claims (10)

1. 24/29 133987HT

   Claims 1. Commodity trade value transaction system, at least comprising: a) one or more POS-systems in a retail store, b) one or more payment terminals in the retail store, at least configured to communicate with the one or more POS-systems, c) means of payment held by a customer, d) reading means embedded in the one or more payment terminals in the retail store configured to read means of payment data and optionally means of payment holder data, e) at least one customer data base, f) a first processor with processing means and memories, included in the POS, for process of payment data associated with payment data holder and customer data, where the customer data is mapped with payment data holders, g) a first set rules algorithm run by the first processor, h) a first decision machine configured to receive first set rules output of first set rules algorithm and further configured to, based on received data, decide further transaction sequences, i) at least one token/ID-matching server, configured to hold customer data, j) at least one second processor included in the token/ID-matching server configured to execute a second set rules algorithm, k) a configurator of the token/ID-matching server is configured to receive output from the second set rules algorithm and based on the received output from the second set rules algorithm to configure further transaction steps, I) an execution machine configured to interface with the configurator and execute further transaction steps based on the output from the configurator, m) the execution machine includes at least one second decision machine configured to receive further execution steps from the configurator and configured to receive input data from the customer

   25/29 133987HT

   and further configured to, based on input, to make a choice for means of payment for concluding a commodity value transaction.
2. 2. A commodity trade value transaction method at least comprising the steps of: a) initialising the commodity trade value transaction method at completed registration of commodities to be purchased by a first customer, the initialisation is initiated by: i. the first customer communicates a payment process request to a point of sale, POS, or ii. a cashier communicates a payment process request to the POS, and b) the POS initialises an ID step for identification of the first customer, c) the POS initialises a profile acquisition step, acquiring profile data of the first customer, d) the POS initialises a payment process where acquired profile data of the first customer together with the final amount due for the commodities to be purchased by the first customer is used as input parameters for the payment process, and e) the POS initiates a complete sale step.
3. 3. A method according to claim 2, where the ID step for identification of the first customer further at least comprises the sub steps bi and bv of the sub steps bi to bv: bi) POS forwards a Request ID Input message to a payment terminal ID Input; bii) POS simultaneously or substantially simultaneously forwards a message to the customer with a message which invites the customer to show his identity and a message is forwarded to the cashier with a message that invites the customer to show his identity; biii) the cashier invites the customer to show his identity; biv) the customer shows his identity to the payment terminal ID Input; bv) the payment terminal ID Input sends an ID value to the POS, hence the customer identity becomes known to the POS.
4. 4. A method according to claim 2, where the ID step for identification of the first customer further at least comprises the sub steps

   26/29 133987HT

   *from the POS simultaneously or substantially simultaneously forward a push message to a display screen visible to the first customer with a message that invites the customer to show his identity and a push message is forwarded to a display screen visible to the cashier with a message that invites the customer to show his identity.
5. 5. A method according to claim 3 where step biv at least includes one of the following steps: * the customer initiates a data exchange between data holding circuitry on a customer bank card and the payment terminal ID Input; • the customer initiates a data exchange between customers' mobile phone and the payment terminal ID Input; * the customer initiates a data exchange between data holding circuitry on a customer identity card and the payment terminal ID Input, * and * the customer identifies himself manually to the cashier; the cashier enters the customer personalia into the POS.
6. 6. A method according to claim 5, where the payment terminal ID Input is a stand-alone ID Input device.
7. 7. A method according to any combination of the claims 2 - 6, where the profile acquisition step acquiring profile data of the first customer further comprises the sub steps of: ci) at the POS generate a request for customer profiles message; cii) from the POS forward the request for customer profiles message to a store database holding customer profile registries; ciii) from the store database generate a customer profile message; civ) from the store database forward the generated customer profile message to POS; cv) from the POS generate and send a request for customer profile to a token server; cvi) at the token server generate a customer profile / payment configuration message;

   27/29 133987HT

   cvii) at the token server forward the customer profile/payment configuration message to the POS, thereby acquiring profile data of the first customer to the POS.
8. 8. A method according to claim 7 where the step ciii) further includes the foregoing step of: at the store database look up match between payload of received customer profile message and registry entries, if match = true, then generate a customer profile message based on content of matched registry entry.
9. 9. A method according to claim 7 where the step cvi) further includes the foregoing step of: at the token server look up match between payload of received customer profile message received from POS and registry entries in a token server database, if match = true, then generate a customer profile message based on content of matched registry entry in the token server database and from the token server database return the generated customer profile to the token server and continue with sub step cvii) of claim 14.
10. 10.A method according to any combination of the claims 2 - 9, where the payment process of step d) further comprises the sub steps of: di) at the POS generate a payment request message, the payment request message at least including: - invitation to the customer for use of highest priority payment means, - a counter value n=O - the amount due to be paid =S, 1 - N,+ = indicator of payment means and its priority number, where N, is highest priority payment means, - the number of payment means available to the customer: NA; dii) from the POS forward the payment request message to the payment terminal ID Input; diii) from the payment terminal ID Input the payment request is forwarded as a payment call to a payment device of the payment terminal;