WO2014032170A1

WO2014032170A1 - System, devices and methods for securely exchanging data

Info

Publication number: WO2014032170A1
Application number: PCT/CA2013/000750
Authority: WO
Inventors: Vernon REDWOOD
Original assignee: Redwood Vernon
Priority date: 2012-08-31
Filing date: 2013-08-30
Publication date: 2014-03-06
Also published as: TW201415389A; AR092397A1

Abstract

A communications system is provided, including a point of sale (POS) device, an intermediate server, and a customer device. The POS device can receive item identifier(s) corresponding to goods selected by a customer and generate transaction data including price(s) for the selected goods. The POS device transmits the transaction data to the intermediate server. The intermediate server uses the transaction data and tax rules to generate a total price for the transaction, generates a web page containing some of the transaction data and the total price, and transmits an address of the web page to the POS device. The POS device is used to convey the address to the customer device, which then accesses the web page. The customer device can then send payment instructions to the intermediate server, and the intermediate server can interact with financial servers to effect a transfer of funds to pay for the selected goods.

Description

SYSTEM, DEVICES AND METHODS FOR SECURELY EXCHANGING DATA

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority from U.S. Provisional Patent Application No. 61/695584, filed August 31 , 2012, the contents of which is incorporated herein by reference.

FIELD

[0002] The specification relates generally to data exchanges between various computing devices, and specifically to a communications system, computing devices and methods for securely exchanging data, such as data relating to financial transactions.

BACKGROUND

[0003] Electronic payments have become common at physical retail locations. Although a variety of electronic payment systems exist, many are characterized by the following factors: the need for the paying customer to provide sensitive payment data at the point of sale; and the need for a computing device operated by the retailer to calculate final pricing and interact with financial infrastructure (such as servers operated by financial institutions).

[0004] The above factors can result in reduced security during a transaction, as sensitive payment data may be intercepted or maliciously stored by the retailer. In addition, locational variations in taxes, and changes to tax laws can result in outdated retailer calculations, and various financial infrastructure may not be reachable from certain locations or certain computing devices.

SUMMARY

[0005] According to an aspect of the specification, a communications system for securely exchanging data is provided, including a point of sale computing device, an intermediate server, and a customer computing device. The point of sale device can receive an item identifier (corresponding to goods selected by a customer) and generate transaction data including a price corresponding to the item identifier. The point of sale device can then transmit the transaction data to the intermediate server. The intermediate server, in turn, can use the transaction data and tax rules to generate a total price for the transaction. The intermediate server can also generate a web page containing a portion of the transaction data and the total price, and transmit an address of the web page to the point of sale device. The point of sale device can be used to convey the address to the customer device, which then accesses the web page using the address. The customer device can then send payment instructions to the intermediate server, and the intermediate server can interact with financial servers to effect a transfer of funds to pay for the selected goods.

BRIEF DESCRIPTIONS OF THE DRAWINGS

[0006] Embodiments are described with reference to the following figures, in which:

[0007] Figure 1 depicts a communications system for securely exchanging data, according to a non-limiting embodiment;

[0008] Figure 2 depicts certain internal components of computing devices in the system of Figure 1 , according to a non-limiting embodiment;

[0009] Figure 3 depicts a method of registering and authenticating certain computing devices in Figure 1 , according to a non-limiting embodiment;

[0010] Figure 4 depicts a customer database stored by the intermediate server of Figure 1 , according to a non-limiting embodiment; [0011] Figure 5 depicts a merchant database stored by the intermediate server of Figure 1 , according to a non-limiting embodiment;

[0012] Figure 6 depicts a method for securely exchanging data, according to a non-limiting embodiment; [0013] Figure 7 depicts a tax rules database stored by the intermediate server of Figure 1 , according to a non-limiting embodiment;

[0014] Figure 8 depicts a web page generated at block 620 of method of Figure 6, according to a non-limiting embodiment; and [0015] Figure 9 depicts a web page generated at block 645 of method of Figure 6, according to a non-limiting embodiment.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0016] Figure 1 depicts a communications system 100 for securely exchanging data, particularly data relating to financial transactions. System 100 includes one or more point of sale (POS) computing devices, referred to collectively as POS devices 104 and generically as a POS device 104. Four POS devices 104-1 , 104-2, 104-3 and 104-4 are shown in the present example. Each POS device 104 is associated with a merchant, which is a "bricks and mortar" retail location stocking goods for purchase. In the present example, POS devices 104-1 and 104-2 are associated with Merchant A, while POS devices 104-3 and 104-4 are associated with Merchant B. POS devices 104 are connected to a network 108 via links 1 12-1 , 1 12-2, 1 12-3 and 1 12-4 respectively, which can be wired (shown in solid lines) or wireless (shown in broken lines) links, or a combination thereof.

[0017] System 100 also includes a customer computing device 1 16 carried by a customer, who can visit Merchant A or Merchant B, select goods to purchase, and present the selected goods to an operator of a POS device 104 (generally, but not necessarily, an employee of the merchant). Customer device 1 16 is connected to network 108 via a wired or wireless link 120 (the present example shows a wireless link). In addition, customer device 1 16 can communicate with POS devices 104 locally, for example via link 124.

[0018] In addition, system 100 includes an intermediate server 128 connected to network 108 via a link 132, and one or more financial servers 136-1 , 136-2 (collectively, financial servers 136, and generically, a financial server 136) connected to network 108 via links 140-1 and 140-2.

[0019] Briefly, in operation, system 100 facilitates the purchase of goods from the merchants by the customer. For example, the customer, carrying customer device 1 16, can enter Merchant A and select various goods to purchase. A POS device 104, for example POS device 104-1 , collects data describing the selected goods and transmits that data to intermediate server 128 via network 108. Intermediate server 128 returns additional data to POS device 104-1 , which transfers the additional data to customer device 1 16. Customer device 1 16 then communicates directly with intermediate server 128 (and not with POS device 104-1 ) to arrange for payment of the selected goods. More specifically, customer device 1 16 instructs intermediate server 128 to arrange a transfer of funds at financial servers 136 from an account associated with the customer to an account associated with Merchant A. Following successful completion of the transfer of funds, intermediate server 128 informs customer device 1 16 and POS device 104-1 of the successful transfer, and the customer is permitted to leave Merchant A with the selected goods.

[0020] Before a more detailed discussion of the operation of system 100 is provided, the internal components of POS device 104-1 , intermediate server 108, and customer device 1 16 will be described.

[0021] Referring now to Figure 2, internal diagrams of POS device 104-1 , intermediate server 108, and customer device 1 16 are shown. POS devices 104- 2, 104-3 and 104-4 need not be identical to POS device 104-1 as shown in Figure 2, but POS device 104-1 is provided as a representative example of the other POS devices.

[0022] POS device 104-1 can be a desktop computer, a laptop computer, a hand-held communication device such as a tablet computer, a cellular telephone, a smart phone, and the like. POS device 104-1 includes a processor 200 interconnected with a non-transitory computer readable storage medium such as a memory 204. Memory 204 can be any suitable combination of volatile (e.g. Random Access Memory ("RAM")) and non-volatile (e.g. read only memory ("ROM"), Electrically Erasable Programmable Read Only Memory ("EEPROM"), flash memory, magnetic computer storage device, or optical disc) memory.

[0023] Memory 204 stores a plurality of computer readable instructions executable by processor 200, including an operating system and a variety of applications. One such application is point of sale application 208. When processor 200 executes the instructions of application 208, processor 200 is configured to perform various functions to facilitate the purchase of goods by the customer mentioned earlier. Those functions will be described in greater detail below.

[0024] POS device 104-1 also includes an input device 212 interconnected with processor 200. Input device 212 is configured to receive input and provide data representative of such input to processor 200. Input device 212 can include any one of, or any suitable combination of, a keypad, a touch screen, a light sensors, a microphone, a camera or barcode scanner, a GPS receiver, and the like (not shown).

[0025] POS device 104-1 also includes one or more output devices interconnected with processor 200, such as a display 216. Display 216 is controllable by processor 200 to generate interfaces representing data and/or applications maintained in memory 204. Display 216 includes any one of, or any suitable combination of, Cathode Ray Tube (CRT) displays, and flat panel displays (e.g. Liquid Crystal Display (LCD), plasma display, Organic Light Emitting Diode (OLED) display). When input device 212 includes a touch screen, the touch screen (not shown) can be integrated with display 216. POS device 04-1 can also include other output devices (not shown), such as a light-emitting indicator (not shown) in the form of an LED, and a motor or other mechanical output device (not shown) for causing communication device 104 to vibrate, a speaker, and the like.

[0026] POS device 104-1 also includes a network interface 220 interconnected with processor 200. Network interface 220 allows POS device 104-1 to communicate with other computing devices via link 1 12-1 and network 108, or via local peer-to-peer links similar to link 124. Link 1 12-1 can be any suitable combination of wired (for example, based on the Ethernet standard) or wireless (for example, based on mobile telecommunications standards, IEEE 802.1 1 standards, Bluetooth™, Near Field Communication (NFC) standards, and the like). Network interface 220 thus includes the necessary hardware, such as radios, network interface controllers and the like, to communicate over link 1 12-1 and any local links.

[0027] The various components of POS device 104-1 are contained within a housing (not shown) comprising any suitable combination of materials (e.g. aluminum or other metals, plastics, and the like). The components of POS device

104-1 are interconnected via one or more communication buses (not shown), and receive electrical power from a power source, such as a battery (not shown).

In some examples, certain components need not be contained within the same housing. For example, display 216 can be contained in a separate housing and connected to processor 200 via a local connection (e.g. a Digital Video Interface

(DVI) connection).

[0028] As mentioned above, POS device 104-1 as illustrated is representative of other POS devices 104, but POS devices 104 can all have different configurations conforming to the general description set out above.

[0029] Customer device 1 16 is also illustrated in Figure 2. Customer device 1 16 can be any mobile computing device, such as a laptop computer or a handheld communication device such as a tablet computer, a cellular telephone, a smart phone, and the like. Similarly to POS device 104-1 , customer device 1 16 thus includes a processor 230 interconnected with a non-transitory memory 234, which can be any suitable combination of volatile (e.g. RAM) and non-volatile (e.g. ROM, EEPROM), flash memory, magnetic computer storage device, or optical disc) memory. Memory 234 stores a plurality of computer readable instructions executable by processor 230, including an operating system and a variety of applications, among which is a purchasing application 238. When processor 230 executes the instructions of application 238, processor 230 is configured to perform various functions to facilitate the previously mentioned purchase of goods by the customer.

[0030] Customer device 1 16 also includes an input device 242 interconnected with processor 230, which can include any one of, or any suitable combination of, a keypad, a touch screen, a light sensors, a microphone, a camera or barcode scanner, a GPS receiver, and the like (not shown).

[0031] Customer device 1 16 also includes one or more output devices interconnected with processor 230, such as a display 246 controllable by processor 230 to generate interfaces representing data and/or applications maintained in memory 234. Display 246 includes any suitable flat panel display (e.g. Liquid Crystal Display (LCD), plasma display, Organic Light Emitting Diode (OLED) display). When input device 242 includes a touch screen, the touch screen (not shown) can be integrated with display 246. Customer device 1 16 can also include other output devices (not shown), such as a light-emitting indicator (not shown) in the form of an LED, and a motor or other mechanical output device (not shown) for causing communication device 104 to vibrate, a speaker, and the like.

[0032] Customer device 1 16 also includes a network interface 250 interconnected with processor 230, allowing customer device 1 16 to communicate with other computing devices via link 120 and network 108, or via local peer-to-peer links similar to link 124. Link 120 can be any suitable combination of wired (for example, based on the Ethernet standard) or wireless (for example, based on mobile telecommunications standards, IEEE 802.1 1 standards, Bluetooth™, Near Field Communication (NFC) standards, and the like). Network interface 250 thus includes the necessary hardware, such as radios, network interface controllers and the like, to communicate over link 120 and any local links.

[0033] The various components of customer device 1 16 are contained within a housing (not shown) comprising any suitable combination of materials (e.g. aluminum or other metals, plastics, and the like). The components of POS device 104-1 are interconnected via one or more communication buses (not shown), and receive electrical power from a power source, such as a battery (not shown).

[0034] Finally, Figure 2 also illustrates certain internal components of intermediate server 128. Intermediate server 128 includes a processor 260 interconnected with a non-transitory memory 264, which can be any suitable combination of volatile (e.g. RAM) and non-volatile (e.g. ROM, EEPROM), flash memory, magnetic computer storage device, or optical disc) memory.

[0035] Memory 264 stores a plurality of computer readable instructions executable by processor 260, including an operating system and a variety of applications, among which is a purchase intermediation application 268. When processor 260 executes the instructions of application 268, processor 260 is configured to perform various functions to facilitate the previously mentioned purchase of goods by the customer, interacting with POS devices 104, customer device 1 16 and financial servers 136 as necessary.

[0036] Memory 264 also stores a merchant database 270, a customer database 272, and a tax rule database 274, each of which will be discussed in greater detail below.

[0037] Intermediate server 128 also includes a network interface 280, which allows intermediate server 128 to communicate with other computing devices via link 132 and network 108. In the present example, link 132 is a wired link, and communications interface 280 therefore includes a network interface controller (NIC) which enables communications based on the Ethernet standard. It is contemplated, however, that link 132 can be any suitable combination of wired and wireless links, and that the nature of communications interface 280 can be varied according to the nature of link 132.

[0038] Processor 260 can receive input data from one or more input devices (not shown), such as a keyboard and a mouse. Additionally, processor 260 can transmit output data to control one or more output devices, such as a display, speaker and the like (not shown). Such input and output devices can be co- located with intermediate server 128 and connected to processor 260 via local connections (e.g. Universal Serial Bus (USB)). In other examples, such input and output devices can be located at a further computing device (not shown) connected to intermediate server 128 via network 108 and link 132. [0039] The components of intermediate server 28 are interconnected via one or more communication buses (not shown), and are housed within one or more enclosures (not shown). Intermediate server 128 can receive electrical power from a power source (not shown).

[0040] Returning briefly to Figure 1 , it is contemplated that additional POS devices beyond those shown, as well as additional customer devices (not shown) are substantially as described above in connection with POS device 104-1 and customer device 1 16. In addition, financial servers 136-1 and 136-2, as well as any other financial servers, can include substantially the same hardware components as described above in connection with intermediate server 128. However, rather than databases 270, 272 and 274, financial servers 136 include databases defining balances and other details of various financial accounts associated with the customer and the merchant. Such accounts can include credit card accounts, lines of credit, chequing accounts, and the like. The specific details relating to the operation of financial servers 136 are not set out in detail herein, as they are well known to those skilled in the art.

[0041] Registration and Authentication of Devices with Intermediate Server

[0042] Before the operation of system 100 summarized above can take place, POS device 104-1 and customer device 1 16 must be registered with intermediate server 128. In addition, in order to participate in the purchasing process summarized above, POS devices 104 and customer device 1 16 must be authenticated by server 128 (that is, the devices must prove that they correspond to devices previously registered with intermediate server 128). Referring now to Figure 3, a method 300 of registering and authenticating computing devices at intermediate server 128 is shown. The blocks of method 300 are performed by intermediate server 128, and particularly by processor 260, in conjunction with the remaining components of intermediate server 128, via the execution of application 268.

[0043] A first example performance of method 300 will be described in connection with the registration of customer device 1 16. Beginning at block 305, intermediate server 128 receives a request via network 108. The request is assumed to originate at customer device 1 16, although in other examples the request can originate at any other computing device associated with the customer (such as a desktop computer operated by the customer). The request is therefore transmitted from customer device 1 16, via link 120, network 108 and link 132, to arrive at network interface 280. The request can be generated at customer device 1 16 via the execution of application 208, or via the execution of a web browser application, which can be used to access a login and registration web page hosted by intermediate server 128.

[0044] At block 310, intermediate server 128 is configured to determine whether the request is a registration request or a login request. The type of the request may be determined by examining the request for a username and password (indicative of a login request), for example. Other ways of distinguishing between login and registration requests will also occur to those skilled in the art. [0045] When the request received at block 305 is a registration request, the performance of method 300 proceeds to block 315, at which intermediate server 128 is configured to request registration data from customer device 1 16, and to receive the requested registration data. The performance of block 315 can include transmitting a further web page to customer device 1 16, or transmitting instructions to application 208 to display a registration interface already stored within application 208. Customer device 1 16 thus displays various fields for receiving input data, and receives data within those fields, for transmission to intermediate server 128.

[0046] The registration data received at block 315 is not particularly limited, but generally serves to identify the customer operating customer device 1 16, and can also identify customer device 116 itself. In other words, the registration data defines what is generally referred to as an account for the customer on intermediate server 128. In the present example, registration data includes a usemame and password, a security code (which will be discussed below), the name of the customer and a physical mailing address (showing the residency of the customer), an email address, a telephone number. The registration data also includes data identifying one or more financial accounts associated with the customer, such as a credit card number, a bank account number, and the like. Further, the registration data can include an identifier of customer device 1 16, such as a serial number or MSISDN (i.e. a mobile telephone number assigned to customer device 1 6).

[0047] Proceeding to block 320, intermediate server 128 is configured to perform a verification process on at least some of the registration data received at block 315. The nature of the verification is not particularly limited, and is generally configured to confirm the identity of the customer. For example, the verification can include sending a query to a directory service (not shown) to confirm that the customer name received at block 315 matches the mailing received at block 315. Block 320 can also include sending a query to a financial server 136 to confirm that an account number received at block 315 not only exists, but is also truly associated with the customer name received at block 3 5. If the verification process is not successful (for example, if the response from the directory service shows that the name and mailing address provided do not match), intermediate server 128 can be configured to return to block 315 and request further registration data. In other examples, intermediate server 128 can be configured to simply terminate method 300 if verification is not successful at block 320.

[0048] When the verification at block 320 is successful, intermediate server 128 performs block 325, at which intermediate server 128 updates customer database 272 to include the registration data received at block 315. An example of customer database 272 is shown in Figure 4. Specifically, Figure 4 shows one record 400 of database 272 corresponding to the customer operating customer device 1 16. Database 272 can also include any number of other records (not shown) for other customers.

[0049] Following the creation of record 400 in database 272, intermediate server 128 can receive a login request from customer device 1 16 at block 305. The login request includes login credentials, such as a username and password. Intermediate server 128 is configured, at block 330, to compare the received credentials to those stored in record 400. If the credentials do match, login is successful, and intermediate server 128 can inform customer device 1 16 of the successful login at block 335. Otherwise, intermediate server 128 can send an error message to customer device 1 16 at block 340.

[0050] In some examples, intermediate server 128 can be configured to detect whether the login is the first login from customer device 1 16. If the device has not previously logged in, intermediate server 128 can be configured to send an email to the address in record 400 with a unique code, which must be returned to intermediate server 128 via customer device 1 16 in order to authorize customer device 1 16. The same methodology can be used to authorize other computing devices the customer uses to login, and any successfully authorized devices (that is, devices that have successfully been associated with the account defined by record 400) can be added to record 400. [0051] Following a successful login, customer device 1 16 can transmit updated or additional registration data to change the account defined by record 400. Customer device 1 6 can also interact with intermediate server 128 to conduct the purchasing process summarized above. In some examples, additional verifications may be required, such as the provision of the security code shown in Figure 4 by customer device 116 in order to complete a purchase, or such as the provision of the password shown in Figure 4 to carry out any edits to record 400 (even after customer device 1 16 has logged in).

[0052] The registration and authentication of POS devices 104 is similar to the process described above. An example performance of method 300 will now be described in connection with the registration of Merchant A and POS devices 104-1 and 104-2 at intermediation server 128. The registration of Merchant B and POS devices 104-3 and 104-4 would proceed in substantially the same way.

[0053] Beginning again at block 305, intermediate server 128 receives a request, for example from one of POS devices 104-1 and 104-2, or from a separate computing device associated with Merchant A. Upon determining that the request is a registration request, intermediate server 128 requests and receives registration data at block 310.

[0054] The registration data received at block 310 for Merchant A is not particularly limited. In the present example, the registration data includes a username and password, a name and physical mailing address, a telephone number, and data identifying one or more financial accounts associated with Merchant A (for example, an account into which proceeds from the sale of goods by Merchant A are directed).

[0055] The registration data also includes the identifiers of any POS devices authorized to interact with intermediate server 128 on behalf of Merchant A (in the present example, POS devices 104-1 and 104-2), as well as usernames and passwords for individual operators of POS devices 104-1 and 104-2, generally employees at Merchant A. The registration data can also include a variety of restrictions or permissions associated with each operator, such as the hours during which the operator is permitted to be logged in, the POS devices that the operator is permitted to log in at, and the like. The registration data can also include the location of a database (not shown in Figure 1 ) of inventory and prices for the goods stocked by Merchant A. The database can be located at Merchant A, such as on a local computing device (including one of POS devices 104), or can be located remotely, for example in a server storing inventory and price listings for a plurality of merchants. An example of such a database is described in United States Patent application no. 13/586092, the contents of which are incorporated herein by reference. In general, the database includes a unique identifier (such as a Universal Product Code (UPC)) for each good, and a corresponding price for each good. The database can also include other data, such as a type for each good (food, electronics, and the like).

[0056] Intermediate server 128 performs a verification process at block 320 substantially as described above (for example, verifying with a directory listing that the name and mailing address provided at block 310 for Merchant A are correct). Following a successful verification, at block 325 intermediate server updates merchant database 270 to include the registration data received at block 315.

[0057] Turning to Figure 5, an example of database 270 is shown after the above performance of block 325. As seen in Figure 5, database 270 includes a record 500 (it is contemplated that additional records can also exist for other merchants) defining an account at intermediate server 128 for Merchant A, and defining the individual POS devices 104 and operators associated with Merchant A. In the present example, each operator field specifies an identifier of the operator, hours during which the operator is permitted to be logged in, and which ones of POS devices 104-1 and 104-2 the operator is permitted to log in from.

[0058] Following the registration of Merchant A and POS devices 104-1 and 104-2, intermediate server 128 can receive, at block 305, a further request from one of POS devices 104-1 and 104-2 to log in (it is contemplated that any number of POS devices 104 associated with a given merchant can be logged in at a time; alternatively, the maximum number of simultaneous logins can be specified in record 500). If the login credentials provided by the POS device 104 are determined to match those in record 500 at block 330, intermediate server 128 can send a login confirmation message to the POS device 104, and the logged in POS device 104 can proceed to update record 500 or participate in the purchasing process summarized above. As mentioned in connection with customer device 1 16, if a login request from a given POS device 104 is detected by intermediate server 128 to be the first attempted login from that device, intermediate serve 128 can be configured to send an authentication code to an email address stored in record 500 (not shown in Figure 5). In order to complete the first login, the particular POS device 104 is required to provide the code to intermediate server 128.

[0059] It is contemplated that various login stages can be implemented in system 100. For example, the operator "Jane" may log in at intermediate server 128 using POS device 104-1 by providing only the username and password shown in Figure 5. In another example, the operator may also be required to provide an operator identifier. In still another example, the operator may be required to provide a separate username and password specific to that operator, in addition to or instead of the username and password for Merchant A. [0060] Once POS devices 104 and customer device 1 16 are registered with intermediate server 128, the above-mentioned secure exchange of data for purchasing goods can be effected, as will be described in connection with Figure 6.

[0061] Secure Exchange of Data for Purchasing Goods [0062] Referring now to Figure 6, the purchase process summarized earlier will be set out in greater detail. Figure 6 depicts a method 600 of securely exchanging data, which in the present example is performed within system 100. The steps of method 600 are divided amongst POS device 104-1 , intermediate server 128 and customer device 1 16. When a block is indicated as being performed by a given computing device, it will be understood that the block is performed via the execution of the respective application stored by that device by the processor of that device. For example, block 605 is performed by POS device 104-1 , and is thus performed by processor 200 via the execution of application 208. [0063] It is assumed for the present performance of method 600 that the registration and authentication processes described above are complete, and that POS device 104-1 and customer device 1 16 are logged in with intermediate server 128. [0064] Prior to the performance of block 605, the customer operating customer device 1 16 arrives at Merchant A and selects various goods for purchase. In the present example, it will be assumed that the customer selects a laptop computer and a can of cola for purchase. The customer presents the selected goods to the operator of POS device 04-1.

[0065] At block 605, POS device 104-1 is configured to receive item identifiers for the selected goods. The item identifiers can be received in a variety of ways. For example, POS device 104-1 can decode item identifiers from bar codes affixed to the selected goods by scanning the barcodes or capturing images of the barcodes using input device 212. In other examples, the item identifiers can be received at processor 200 from a keypad, having been manually entered by the operator of POS device 104-1. The item identifiers received at block 605 can also include identifiers of goods not explicitly selected by the customer but rather automatically selected by POS device 104-1 , such as discounts or additional fees associated with the selected goods. For example, an electronics recycling fee may be payable with the purchase of any electronics, and POS device 104-1 may therefore automatically select an item identifier corresponding to that recycling fee when the identifier for the laptop computer is received.

[0066] Proceeding to block 610, POS device 104-1 is configured to retrieve prices from the above-mentioned inventory database for the selected goods. The performance of block 610 can include sending one or more queries including the item identifiers received at block 605. In some embodiments, POS device 104-1 can be configured to retrieve the inventory database's location from record 500 at intermediate server 128 before sending such queries. Having retrieved the prices of the selected goods, POS device 104-1 can be configured to generate transaction data and transmit the transaction data to intermediate server 128.

[0067] The nature of the transaction data is not particularly limited. In general, the transaction data identifies POS device 104-1 , and also identifies the selected goods. In the present example, the transaction data includes the item identifiers, a quantity of each selected good, prices for the selected goods, and a subtotal (being the sum of the individual prices of the selected goods) calculated by POS device 104-1. The transaction data can also include a current location of POS device 104-1 , such as geographical coordinates generated by a GPS receiver.

[0068] At block 615, intermediate server 128 is configured to receive the transaction data from POS device 104-1 and store the transaction data in memory 264. Intermediate server 28 is then configured to generate a total price, inclusive of any applicable taxes, for the selected goods. The generation of a total price includes retrieving rules from tax rule database 274. The nature of the rules stored in database 274 is not particularly limited. In general, database 274 contains a plurality of records, each record identifying a particular tax. Each record also identifies which locations (countries, states, provinces, and the like) apply the tax, the level (e.g. the percentage of the good's price) of the tax, and if applicable, which types of goods the tax applies to. An example of database 274 is shown in Figure 7. In particular, database 274 is shown with two records, each defining a particular tax, the location where it is applied, its level, and the types of goods included or excluded from the tax (for example, the HST tax is not charged for goods having the type "food" in Ontario, while HST is charged for all other types of goods). Prior to generating a total price, intermediate server 128 can also be configured to validate the transaction data received from POS device 104-1. For example, intermediate server 128 can communicate with the inventory database identified in record 500 to confirm the prices of the selected goods.

[0069] Therefore, at block 615, intermediate server 128 is configured to retrieve rules from database 274 that match the location of either or both of POS device 104-1 and the residency of the customer from record 400, and the type of the selected goods identified in the transaction data, if applicable. For the present example performance of method 600, it will be assumed that Merchant A is located in Ontario (ON), and that the type indicated for the selected laptop computer is "electronics", while the type indicated for the selected can of cola is "food". Thus, at block 615, intermediate server 128 selects the "HST" tax and generates a final price by adding 13% to the price of the laptop computer, and the summing the modified price of the laptop computer with the unmodified price of the can of cola. The performance of blck 615 can also include the generation of any required transaction fees, which can also be determined by intermediate server 128, for example, based on the location of Merchant A.

[0070] Having generated a final price for the selected goods, at block 620 intermediate server 128 is configured to generate a payment portal specific to the transaction. The payment portal can be a web page, hosted at the intermediate server and accessible via network 108. An example web page 800 is shown in Figure 8. Web page 800 includes a transaction identifier 804, which can either be generated by intermediate server 128 or by POS device 104-1 and provided to intermediate server 128 with the transaction data. Web page 800 can also include an identifier 808 of the merchant that initiated the transaction by sending transaction data (Merchant A, in the present example). Web page 800 also indicates the names, quantities and prices of the selected goods, as well as a subtotal, taxes, and total price. Finally, web page 800 includes selectable elements 812 and 816, which will be discussed in greater detail below.

[0071] Returning to Figure 6, to complete the performance of block 620 intermediate server is configured to transmit an address (such as a Uniform Resource Locator (URL)) of web page 800 to POS device 104-1. The address can be transmitted in an encoded format, such as in the form of a linear bar code or a two-dimensional bar code (e.g. a Quick Response (QR) code). In some examples, the address sent to POS device 104-1 can be encrypted such that only customer device 1 16 can decrypt the address (for example, the address can be encrypted using a public key assigned to customer device 1 16).

[0072] At block 625, POS device 104-1 is configured to receive the address sent by intermediate server 128, and to convey the address to customer device 1 16. The manner in which the address is conveyed to customer device 1 16 is not particularly limited. For example, POS device 104-1 can present the address on display 216, following which customer device 1 16 can capture an image of display 216 using a camera or (if the address is encoded in a machine-readable form such as a bar code) a bar code scanner. Customer device 1 16 can also receive the address as input to a keypad or touch screen (that is, the customer operating customer device 1 16 can read the address from display 216 and enter the address at input device 242).

[0073] In other examples, the transmission of the address from POS device 104-1 to customer device 1 16 can be carried out over a local communications link, such as via Bluetooth™ or NFC communications. In still other examples, POS device 104-1 can be equipped with or connected to a printer, and can print a physical copy of the address, which can then be scanned or photographed by customer device 1 16, or input manually at customer device 1 16 by the customer. [0074] At block 630, having received the address of web page 800 from POS device 104-1 (whether directly or indirectly, as discussed above), customer device 1 16 is configured to access web page 800 at intermediate server 128. The steps taken in accessing web page 800 are the same as those taken in accessing any web page (e.g. by sending HTTP requests and receiving responses theret), and are therefore not detailed herein. In some examples, however, prior to requesting web page 800 from intermediate server 128 customer device 1 6 can determine whether the address received at block 630 is authentic. Customer device 116 can store (in memory 234, for example as a setting within application 238) an identifier of the domain (e.g. server128.com) of intermediate server 128. Thus, customer device 1 16 can be configured to compare any addresses received at block 630 to the stored domain. If the domain of the received address does not match the stored domain, customer device 116 can be configured to discard the address as potentially malicious, and to notify intermediate server 128 that the link was discarded. Intermediate server 128 can then be configured to abort the transaction, ending the performance of method 600. When the domain of the address does match the stored domain, on the other hand, the performance of method 600 can continue.

[0075] Having accessed web page 800 (that is, retrieved a copy of web page 800 from intermediate server 128) at block 630, customer device 1 16 is configured to present web page, or at least a portion thereof, on display 246. Thus, display 246 can present an interface substantially resembling that shown in Figure 8.

[0076] At block 635, customer device 1 16 is configured to determine, based on input received from input device 242, whether to accept or decline the transaction. Specifically, referring to Figure 8, customer device 1 16 is configured to receive a selection of either the "checkout" element 812, or a selection of the "decline" element 816. If the "decline" element 816 is selected at input device 242, indicating that the transaction is declined, customer device 1 16 is configured to proceed to block 640 and abort the transaction. The transaction can be aborted, for example, by sending a message to intermediate server 128 instructing intermediate server 128 to end the transaction and inform POS device 104-1 that the transaction has been declined. The performance of method 600 then ends.

[0077] If, however, the "checkout" element 812 is selected, the determination at block 635 is affirmative and customer device 1 16 proceeds to block 645. At block 645, customer device 1 16 is configured to receive further input at input device 242 and send a payment instruction to intermediate server 128. For example, referring to Figure 9, display 246 can be controlled to present a web page or other interface 900, which contains transaction identifier 804 and merchant identifier 808 from web page 800, and which also contains selectable elements 904 and 908 corresponding to the accounts identified in record 400 of database 272. Customer device 6 is configured to receive a selection of element 904 or element 908, indicating which of the accounts associated with customer device 1 16 is to be debited to pay for the selected goods. Web page 900 can also include a field 912 into which a security code must be entered, and a selectable element 916 which, when selected by input device 242, causes customer device 1 16 to send the payment instruction.

[0078] The payment instruction includes transaction identifier 804, an identifier of the selected account (for example "Account 1 "), and the security code entered in field 912. Returning to Figure 6, at block 650 intermediate server 128 is configured to receive the payment instruction sent by customer device 1 16, and instruct financial servers 136. Prior to instructing financial servers 136, intermediate server 128 can be configured to validate the payment instruction, for example by comparing the security code received from customer device 1 16 to the "master" security code stored in record 400. If the two codes do not match, intermediate server 128 can be configured to abort the transaction. In some examples, the verification of the security code can be conducted entirely within customer device 1 16 (that is, customer device 1 16 stores the master code, and compares it with the security code received as input before sending the payment instruction).

[0079] If the security code provided by customer device 1 16 matches the security code stored in record 400, intermediate server 128 instructs financial servers 136 to transfer funds according to the payment instructions. In particular, an amount equal to the total shown in Figures 8 and 9 is to be debited from the account indicated by customer device 1 16 at block 645, and credited to the account identified in record 500 (that is, the account associated with Merchant A). The exact nature of the communications between intermediate server 128 and financial servers 36 are contemplated to follow conventional standards and protocols for conducting financial transactions, and are therefore not described in detail herein.

[0080] At block 655, intermediate server 128 is configured to determine whether the payment specified by customer device 1 6 was completed successfully. Intermediate server 128 can determine whether the payment was completed based on data received from financial servers 136. For example, if a message is received from financial server 136-1 at intermediate server 128 indicating that the account selected by customer device 1 16 does not contain sufficient funds to pay for the selected goods, then the determination at block 655 is negative. Intermediate server 128 thus records details of the failed transaction in memory 264 at block 660, and proceeds to block 670. On the other hand, if a message is received at intermediate server 128 from financial server 136-1 indicating that the transfer of funds is complete, the determination at block 655 is affirmative, and intermediate server 128 proceeds to block 665. At block 665, details of the successful transaction are recorded in memory 264, and intermediate server 128 proceeds to block 670.

[0081] The exact nature of the data logged at blocks 660 and 665 is not particularly limited. Recorded data can include identifiers of the merchant (e.g. Merchant A) and POS device (e.g. POS device 104-1 ) that initiated the transaction; an identifier of customer device 1 16; identifiers of the selected goods; the total price determined by intermediate server; the account selected for payment by customer device 1 16; the reason for failure of the transaction, and the like. Data logged at blocks 660 and 665 can be accessed at a later time by customer device 1 16 and POS devices 104. For example, POS devices 104 can request reports of transactions associated with their merchants. It is also contemplated that data can be logged by intermediate server 128 if the transaction is aborted earlier in method 600 (for example, if the determination at block 635 is negative).

[0082] At block 670, intermediate server 128 is configured to notify customer device 116 and POS device 04-1 of the successful or unsuccessful completion of the transaction. At block 675, POS device 104-1 receives the notification, and can also present the notification on display 216. Similarly, at block 680 customer device 1 16 can receive the notification and present the notification on display 246. The customer can then be permitted to depart from Merchant A with the selected goods.

[0083] Variations to the above systems and methods are contemplated. In some embodiments, intermediate server 128 can be configured to retrieve prices and item types directly from the inventory database identified in record 500. In such examples, POS device 104-1 need only transmit item identifiers for the selected goods, without retrieving prices or determining a subtotal. At block 615, intermediate server 128 is then configured to receive the item identifiers, and request item types, prices and the like from the database identified in record 500. [0084] In still other embodiments, intermediate server 128 can also automatically initiate related transactions. For example, intermediate server 128 can include in database 274 an indication of which account each tax is paid to (such as a local government authority). Intermediate server 128 can therefore not only determine a total price at block 615, but also, at block 650, initiate a transfer of funds from the account selected by customer device 1 16 to the account associated with Merchant A and initiate a transfer from the merchant's account to the tax collection account (or multiple tax collection accounts, if multiple taxes apply to the selected good). This implementation can be extended to apply to tips, franchisee fees, consignment fees, and the like. Taking the consignment example, a selected good can be identified as being on consignment in the inventory database. Intermediate server 128 can therefore be configured to consult the inventory database to determine that the selected good is on consignment, and to determine the portion of the good's price that is to be remitted to the consignor. Thus, at block 650, intermediate server 128 can transfer a portion of the final price to the merchant's account, and a portion to a consignor's account (which can also be identified in the inventory database). The above-mentioned automatic transfers can also occur directly from the customer's account to the tax collection, consignor, or other relevant account (that is, bypassing the merchant account).

[0085] In a further variation, at block 645 customer device 1 16 can also provide information relating to discounts, gift cards and the like. In other words, the accounts indicated in the payment instruction (and identified in record 400) can include a wide variety of financial instruments. Combinations of the above variations are also contemplated.

[0086] Certain advantages to the above systems, methods and computing devices will now be apparent to those skilled in the art. For example, customer device 1 16 is not required to provide potentially sensitive payment information at Merchant A (such as account numbers). Thus, the security of the transaction is enhanced. In addition, due to the centralized storage of tax rules, POS devices 104 need not be updated when tax rules change. [0087] A further advantage provided by the use of intermediate server 128 is that neither POS devices 104 nor customer device 1 16 are required to interact directly with financial servers 136. The variety of communication protocols supported by POS devices 104 and customer device 1 16 can therefore be reduced. Additionally, customer device 1 16 is not required to communicate with various financial servers in order to effect payment for goods at any merchant, and in some examples can even avoid communicating with POS devices 104. Other advantages will also occur to those skilled in the art.

[0088] Persons skilled in the art will appreciate that there are yet more alternative implementations and modifications possible for implementing the embodiments, and that the above implementations and examples are only illustrations of one or more embodiments. The scope, therefore, is only to be limited by the claims appended hereto.

Claims

We claim:

1. A communications system for securely exchanging data, comprising:

a point of sale computing device having an input device, a first network interface connected to a network, and a first processor configured to:

receive an item identifier from the input device;

generate transaction data including a price corresponding to the item identifier, and transmit the transaction data via the first network interface;

an intermediate server having a second memory, a second network interface connected to the network, and a second processor configured to:

receive the transaction data from the point of sale computing device at the second network interface;

generate data representing a total price, based on the transaction data and on a tax rule stored in the second memory;

generate a web page accessible via the network and containing a portion of the transaction data and the total price; and

transmit an address of the web page to the point of sale computing device;

a customer computing device having a third network interface connected to the network, and a third processor configured to:

receive the address sent from the intermediate server to the point of sale device;

access the web page at the intermediate server using the address; and,

send a payment instruction to the intermediate server, the payment instruction including a selected account identifier;

the intermediate server further configured to receive the payment instruction, and transmit a transfer instruction to a financial server via the network for transferring funds from the selected account to an account associated with the point of sale computing device.

2. The system of claim 1 , wherein the transaction data includes a goods type corresponding to the item identifier.

3. The system of claim 1 , wherein the address is encoded in a machine readable code; the point of sale device configured to send the machine readable code to the customer device via a local link.

4. The system of claim 1 , wherein the payment instruction includes a security code; the intermediate server configured to store a master security code in the second memory, and to compare the security code with the master security code.

5. The system of claim 1 , the intermediate server configured to store identifiers of a plurality of accounts maintained by the financial server and associated with the customer computing device; the web page including a selectable element representing each account identifier.

6. The system of claim 5, the customer computing device configured to receive a selection of one of the selectable elements, and to include the corresponding one of the account identifiers in the payment instruction.

7. The system of claim 1 , the intermediate server further configured to generate an additional transfer instruction for transferring funds from an account associated with the point of sale computing device to a further account.

8. An intermediate server, comprising:

a memory;

a network interface connected to a network; and

a processor interconnected with the memory and the network interface, the processor configured to: receive transaction data from a point of sale computing device via the network interface, the transaction data including a price corresponding to an item identifier;

generate data representing a total price, based on the transaction data and on a tax rule stored in the memory;

generate a web page accessible via the network and containing a portion of the transaction data and the total price;

transmit an address of the web page to the point of sale computing device via the network interface;

in response to a request from a customer computing device, transmit the web page to the customer computing device via the network interface;

receive a payment instruction from the customer computing device, the payment instruction including a selected account identifier; and

transmit a transfer instruction to a financial server via the network interface, for transferring funds from the selected account to an account associated with the point of sale computing device.

9. The intermediate server of claim 8, wherein the transaction data includes a goods type corresponding to the item identifier.

10. The intermediate server of claim 8, the processor configured to generate a machine readable code encoding the address; wherein transmitting the address comprises transmitting the machine readable code to the point of sale device.

1 1. The intermediate server of claim 8, wherein the payment instruction includes a security code; the intermediate server configured to store a master security code in the second memory, and to compare the security code with the master security code.

12. The intermediate server of claim 8, the memory storing identifiers of a plurality of accounts maintained by the financial server and associated with the customer computing device; and the web page including a selectable element representing each account identifier.

13. The intermediate server of claim 8, the processor further configured to generate an additional transfer instruction for transferring funds from an account associated with the point of sale computing device to a further account.

14. A method in an intermediate server having a memory, a network interface connected to a network, and a processor interconnected with the memory and the network interface, the method comprising:

receiving transaction data from a point of sale computing device at the processor via the network interface, the transaction data including a price corresponding to an item identifier;

generating, at the processor, data representing a total price, based on the transaction data and on a tax rule stored in the memory;

generating, at the processor, a web page accessible via the network and containing a portion of the transaction data and the total price;

transmitting an address of the web page to the point of sale computing device via the network interface;

in response to a request from a customer computing device, transmitting the web page to the customer computing device via the network interface;

receiving a payment instruction from the customer computing device, the payment instruction including a selected account identifier; and transmitting a transfer instruction to a financial server via the network interface, for transferring funds from the selected account to an account associated with the point of sale computing device

15. The method of claim 14, wherein the transaction data includes a goods type corresponding to the item identifier.

16. The method of claim 14, further comprising generating a machine readable code encoding the address; wherein transmitting the address comprises transmitting the machine readable code to the point of sale device.

17. The method of claim 14, wherein the payment instruction includes a security code; the method further comprising storing a master security code in the second memory, and comparing the security code with the master security code.

18. The method of claim 14, the memory storing identifiers of a plurality of accounts maintained by the financial server and associated with the customer computing device; and the web page including a selectable element representing each account identifier.

19. The method of claim 14, further comprising: generating an additional transfer instruction for transferring funds from an account associated with the point of sale computing device to a further account.