System and method for offline vending

Abstract

There is provided a system and method for offline order placement. The method including encrypting a purchase log using a second encryption key pair, the second encryption key pair shared with a management server; communicating the encrypted purchase log to a consumer device, the consumer device communicates the encrypted purchase log to the management server; receiving and decrypting an encrypted purchase order from the consumer device using a first encryption key pair, the first encryption key pair shared with a consumer device; and performing fulfillment of the purchase order.

Description

SYSTEM AND METHOD FOR OFFLINE VENDINGTECHNICAL FIELD

[0001] The following generally relates to self-serve machines, and in particular, to a system and method for offline order placement.BACKGROUND

[0002] Self-serve machines, for example, vending machines, laundry machines, ticket kiosks, or coffee kiosks, provide services or products without human assistance. These machines can integrate with mobile applications to allow remote interactions. However, these typically depend on being online, which is not always feasible or reliable in certain situations.SUMMARY

[0003] In an aspect, there is provided a method for offline order placement. In an embodiment, a self-serve machine generates a combination of an encrypted list of product offerings and an encrypted purchase log, the encrypted list of product offerings encrypted using a productoffering encryption key of a product-offering key pair, and the encrypted purchase log encrypted using a log-transfer encryption key of a log-transfer key pair. The combination of the encrypted list of product offerings and the encrypted purchase log is transmitted to a consumer device, the encrypted purchase log stored in a storage of the consumer device for later transfer to a management server. The consumer device decrypts the encrypted list of product offerings, receives a purchase order from a user based on the decrypted list, encrypts the purchase order using an order-placement encryption key of an order-placement key pair, and transmits the encrypted purchase order to the self-serve machine. The self-serve machine decrypts the encrypted purchase order and performs fulfillment of the purchase order.

[0004] In another case of the method for offline order placement, the self-serve machine validates the decrypted purchase order against a predefined message-format rule before fulfillment.

[0005] In yet another case of the method for offline order placement, the transmitting and receiving between the self-serve machine and the consumer device are performed using at least one of Bluetooth™, Bluetooth™ Low Energy, Near-Field Communication, RFID, Wi-Fi, WiFi Direct, or a Quick-Response (QR) code.

[0006] In yet another case of the method for offline order placement, the encrypted purchase log comprises a timestamp, a machine identifier, and a transaction identifier.

[0007] In yet another case of the method for offline order placement, the consumer device transmits the stored encrypted purchase log to the management server after communication is established between the consumer device and the management server.

[0008] In yet another case of the method for offline order placement, the management server decrypts the transmitted purchase log using a log-transfer decryption key of a log-transfer key pair and records or reconciles the transmitted purchase log with a previously recorded purchase log.

[0009] In yet another case of the method for offline order placement, the management server determines expiration of each key pair and, upon expiration, generates and securely transmits replacement key pairs to the corresponding devices.

[0010] In another aspect, there is provided a method for offline payment for a purchase transaction. In an embodiment, the self-serve machine receives an encrypted balance token and one or more encrypted transaction tokens from the consumer device. The encrypted balance token is encrypted using a balance-token encryption key of a balance-token key pair, and the encrypted transaction tokens are encrypted using a transaction-token encryption key of a transaction-token key pair. The self-serve machine decrypts the encrypted tokens, validates each transaction token by verifying that it references a preceding transaction token or the balance token, determines a remaining balance based on the validated tokens, authorizes the purchase transaction when the remaining balance is sufficient, and generates a new encrypted transaction token referencing the latest transaction for transmission to the consumer device.

[0011] In another case of the method for offline payment, the self-serve machine declines the purchase transaction when validation of the balance token or transaction tokens fails, or when the remaining balance is insufficient to complete the purchase transaction.

[0012] In yet another case of the method for offline payment, the self-serve machine verifies one or more of a timestamp, an account identifier, and a digital signature associated with each balance token.

[0013] In yet another case of the method for offline payment, the consumer device stores the encrypted balance token and encrypted transaction tokens in a secure hardware storage.

[0014] In yet another case of the method for offline payment, the management server reconciles tokens received from the consumer device by decrypting the tokens using corresponding decryption keys and generating a new balance token reflecting an updated account balance.

[0015] In yet another case of the method for offline payment, each balance token and transaction token includes a validity timestamp defining a validity period used for validation of the respective token.

[0016] In yet another case of the method for offline payment, reaching a predefined maximum number of transaction tokens stored on the consumer device triggers reconciliation with the management server.

[0017] In another aspect, there is provided a method for offline data transfer between a sender device, a receiver device, and at least one intermediary device. In an embodiment, the sender device divides a dataset into a plurality of data chunks, encrypts each data chunk using a data-transfer encryption key corresponding to a data-transfer decryption key stored by the receiver device, and transmits the encrypted data chunks to a first intermediary device. The intermediary device stores the encrypted data chunks for subsequent transfer to the receiver device or to a second intermediary device. The receiver device decrypts each encrypted data chunk using the corresponding decryption key and reassembles the decrypted data chunks in an order determined from information associated with each data chunk to reconstruct the dataset sent by the sender device.

[0018] In another case of the method for offline data transfer, each data chunk includes a checksum embedded within or alongside the data chunk before transmission, and the receiver device verifies the integrity of each decrypted data chunk using the embedded checksum before reassembly.

[0019] In yet another case of the method for offline data transfer, subsets of the encrypted data chunks are distributed from the sender device across multiple intermediary devices.

[0020] In yet another case of the method for offline data transfer, the receiver device detects missing or duplicate data chunks and requests retransmission from the sender device.

[0021] In yet another case of the method for offline data transfer, transmission is performed using at least one of Bluetooth™, Bluetooth™ Low Energy, Near-Field Communication, Wi-Fi, Wi-Fi Direct, or a Quick-Response (QR) code.

[0022] In yet another case of the method for offline data transfer, the receiver device generates and stores a synchronization log identifying any missing, duplicate, or inconsistent data chunks detected during or after reassembly.BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The features of the invention will become more apparent in the following detailed description in which reference is made to the appended drawings wherein:

[0024] FIG. 1 illustrates a schematic diagram of a system for offline order placement in accordance with an embodiment;

[0025] FIG. 2 illustrates a schematic diagram of a consumer device of the system of FIG. 1 ;

[0026] FIG. 3 illustrates a schematic diagram of a self-serve machine of the system of FIG. 1;

[0027] FIG. 4 illustrates a schematic diagram of a management server of the system of FIG. 1 ;

[0028] FIG. 5 is a flowchart of a method for offline order placement, in accordance with an embodiment;

[0029] FIG. 6 is a flowchart of a method for offline order placement, in accordance with another embodiment;

[0030] FIG. 7 is a flowchart of a method for offline order placement, in accordance with yet another embodiment; and

[0031] FIG. 8 is a flowchart of a method for bidirectional offline data transfer, in accordance with an embodiment.DETAILED DESCRIPTION

[0032] Embodiments will now be described with reference to the figures. For simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Also, the description is not to be considered as limiting the scope of the embodiments described herein. It is appreciated that atleast some of the order and necessity of the steps, limitations, elements, functions, and technical features of the systems and / or methods can be varied or changed as appropriate, while retaining the technical contributions.

[0033] For simplicity and clarity of illustration, reference numerals may be repeated among the Figures to indicate corresponding or analogous elements. Specific details are set forth to provide a thorough understanding of the technical aspects and innovative features of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details, provided that the core innovative concepts are retained. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the novel aspects of the embodiments described herein. The description is not to be considered as limiting the scope of the embodiments described herein to the specific details provided but should be understood to cover all technical innovations and improvements.

[0034] Various terms used throughout the present description may be read and understood as follows, unless the context indicates otherwise: “or” as used throughout is inclusive, as though written “and / or”; singular articles and pronouns as used throughout include their plural forms, and vice versa; similarly, gendered pronouns include their counterpart pronouns so that pronouns should not be understood as limiting anything described herein to use, implementation, performance, etc. by a single gender; “exemplary” should be understood as “illustrative” or “exemplifying” and not necessarily as “preferred” over other embodiments.Further definitions for terms may be set out herein to ensure clarity and consistency in understanding the technical features and innovations described; these definitions may apply to prior and subsequent instances of those terms, as will be understood from a reading of the present description, to support consistent understanding of the novel and inventive aspects of the technical features and innovations described.

[0035] Any module, unit, component, server, computer, terminal, engine, or device that executes instructions described herein may include or access computer-readable media, such as storage media or data storage devices (removable and non-removable). Computer storage media include volatile and non-volatile, removable and non-removable media for storing information, such as computer-readable instructions, data structures, program modules, or other data. Examples include RAM, ROM, EEPROM, flash memory, CD-ROM, DVDs, magnetic cassettes, magnetic tapes, magnetic disk storage, or any other non-transitory medium that stores desired information and can be accessed by an application or module. Any such non-transitory media may be part of the device or accessible thereto or be integral to the functionality of the system, enabling efficient data storage and retrieval. Processors or controllers set out herein may be implemented as a single processor or a plurality of processors, which may be arrayed or distributed, carrying out processing functions individually or collectively. Any method, application, or module described herein may be implemented using computer-readable instructions stored or held by such non-transitory media and executed by the processors, thereby realizing the inventive concepts and technical improvements described herein.

[0036] The following generally relates to self-serve machines, and in particular, to a system and method for offline vending and order placement.

[0037] Self-serve machines are automated machines that provide services or products to customers without the need for human assistance. They're designed to increase efficiency, shorten waiting times, and provide products and services outside of typical business hours or traditional business locations. Examples of these machines include Automated Teller Machines (ATMs), self-checkout systems, vending machines, ticket kiosks, laundromat machines, coffee kiosks, entertainment stations, and self-serve carwash stations, amongst many others. These machines typically involve some form of user interface, a mechanism for accepting payment, and a mechanism for dispensing a product or rendering a service.

[0038] Self-serve machines can be equipped with a variety of mechanisms for presenting their products and services, accepting orders, and in some cases, even customizing an order. For example, self-serve machines for food items, such as coffee kiosks, may allow customers to choose the type and amount of ingredients; such as, selections for milk, cream, and sweeteners for a purchased coffee. In another example, a self-serve laundromat machine may allow customers to select the type, length, and other aspects of a washing or drying cycle. A self-serve carwash station may allow customers to select the type of detergent, the type of wash (regular, touchless, etc.), or the intensity of different aspects of service. Other self-serve machines may allow for similar custom izations of products and services they can render. As used herein, the term “product” or “service” includes any goods and services and “product offerings” or “service offering” includes any goods or services offered or rendered.

[0039] Customers can typically interact with self-serve machines using an interactive display screen and / or a panel of buttons. In many cases, a single digital touch screen is used for both display of information and for receiving input from the users and customers. In other cases, self-serve machines can receive commands and orders from applications on mobile devices, orother computing devices, accessed by the customers. In other cases, commands and orders can be received via web interfaces accessed by customers. Remote applications and web interfaces allow customers to place orders and make selections without needing to physically interact with the machine. For instance, a customer can use a mobile app to order and customize a coffee, pay for it, and receive a notification when the coffee is ready for pickup at a particular kiosk. Similarly, a customer might use a web interface to reserve and pay for a carwash, specifying all desired services and options in advance.

[0040] In most cases, using mobile applications or web interfaces requires that the customer be online, which might not be feasible or consistent at all times. For example, in rural areas where mobile coverage can be spotty or unreliable, customers might struggle to connect to the internet to place their orders. Similarly, in urban environments, self-serve machines located in basements or other areas with poor signal reception, such as laundry rooms or underground car washes, may face connectivity issues. In these scenarios, customers are often unable to use mobile applications or web interfaces effectively, resulting in frustration and inefficiency when interacting with the self-serve machine.

[0041] In order to overcome the substantial challenges of self-serve machines in offline environments, the present embodiments advantageously permit customers to place orders even when there is no immediate internet connectivity. The present embodiments can store order data on a mobile device belonging to a customer and synchronize such order data with a management server when a connection becomes available. This ensures that customer purchase logs and order data are accurately maintained. Similarly, self-serve machines can store order data and purchase logs locally and synchronize with the management server when they regain connectivity, ensuring all order data is up-to-date. In some cases, communication of orders placed directly between the consumer device and the self-serve machine can be encrypted, without the need for being online or in communication with the management server at the time of order placement. This direct communication ensures that customers can complete transactions seamlessly, even in areas with poor or no internet connectivity.

[0042] In embodiments of the present disclosure, secure communication can be implemented using pairs of encryption and decryption key pairs. Each of the encryption and decryption key pairs can be loaded into the self-serve machine, the consumer device, and / or the management server. In an example, one key pair can be used for communicating the products or services offered by the self-serve machine, and the other key pair can be used for communicating the placement of the order by the consumer device. The encryption key for communicating theoffered products and services can be loaded by the self-serve machine, while the corresponding decryption key can be loaded by the consumer device. Similarly, the encryption key for communicating the placement of the order can be loaded only in the consumer device, and the corresponding decryption key can be loaded only in the self-serve machine. Use of encryption and decryption key pairs ensures that sensitive information is securely transmitted between the devices through direct communication, without the risk of interception or unauthorized access.

[0043] In some cases, an offline payment mechanism may be implemented to facilitate transactions when the consumer device or the self-serve machine cannot connect to the management server. This offline payment mechanism may be particularly advantageous when communication costs are high; for example, where it may be preferable to schedule data transfers between the self-serve machines and the management server. In such cases, the offline payment may rely on various types of encrypted tokens, including balance tokens and transaction tokens. Each device involved in the transaction may carry an encrypted balance token, representing the consumer's available balance, as well as potentially a number of encrypted transaction tokens that record previous transactions.

[0044] The balance token may be created and encrypted by the management server, for example, using a balance token encryption key of a balance-token key pair. The balance token stores or otherwise indicates the current balance based on the most recent records maintained by the server. The corresponding decryption key of the balance-token keypair may be shared with the self-serve machines, enabling them to read and process the token during a transaction. In some cases, the transaction tokens may be generated by the self-serve machines during offline payment transactions. These tokens may include information such as the transaction value and may reference the previous transaction through identifiers such as serial numbers or dates. The transaction tokens are encrypted and decrypted using a transaction token key pair. The transaction token encryption key of the transaction token key pair may be unique to each self-serve machine, while its corresponding decryption key may be shared with the management server to allow for reconciliation of records once communication is restored. The consumer device will hold these tokens in a wallet repository which will be shared with each self-serve machine during a transaction. When the wallet repository holds encrypted transaction tokens, or by following other rules or intervals, once possible, the wallet repository will be shared with the management server to verify and reconciliate the transaction tokens into a new balance token, which will be sent back to the consumer’s device to replace the existing token.

[0045] In some cases where offline payment is used, the consumer device can be restricted to read the value of the balance token and transaction tokens but not modify them. This may be achieved by storing an unencrypted duplicate of each token's value alongside the encrypted version, allowing the consumer device to access the information without altering the underlying token. Alternatively, additional sets of encryption and decryption keys may be used to create readable copies of the tokens for the consumer device. When a consumer device interacts with a self-serve machine, all tokens, including the balance token and any transaction tokens, may be transferred to the machine. The self-serve machine can then calculate the remaining balance by deducting the value of all transaction tokens from the balance token. If a new transaction is initiated, the self-serve machine may generate a new encrypted transaction token that references the previous transaction, ensuring that the transaction history remains intact. This offline payment system may enhance the functionality of the self-serve machines, allowing secure transactions to be processed even in offline environments while maintaining the integrity of the transaction records for future reconciliation with the management server.

[0046] In some cases, a log-transfer key pair can be used in addition to a product-offering key pair (used for securely communicating the products and services offered) and an orderplacement key pair (used for securely communicating the placement of the order). The encryption key for the log-transfer key pair can be stored by the self-serve machine while the decryption key can be stored in the management server. In cases where the product offerings are communicated to the consumer device, typically, the consumer device would not have access to the log-transfer key pair. In such cases, the self-serve machine can encrypt a predetermined quantity of the latest purchase logs and place the encrypted purchase logs into the message that communicates the products and services offered to the consumer device. The consumer device receives and stores the encrypted purchase log, without any further processing, until a connection can be established with the management server. When the communication is established with the management server, the encrypted purchase log is transferred to the management server. In some cases, after transfer, the encrypted purchase log can be removed from the consumer device. Once the management server receives the encrypted purchase log, it decrypts the purchase log using the decryption key from the logtransfer key pair. In some cases, the management server can consolidate each one of the received purchase logs with purchase logs received from other consumer devices. In some cases, the management server identifies any discrepancies between received purchase logs and flags such discrepancies for further investigation.

[0047] Offline vending on the self-serve machine, in embodiments of the present disclosure, can include transferring data between the mobile device and the self-serve machine; ensuring integrity and security of the transaction. Any suitable form of direct communication can be employed to achieve communication between the self-serve machine and the consumer device, for example, Bluetooth™, Wi-Fi, or Near Field Communication (NFC). In other cases, a quickresponse code (QR code) can be used where the self-serve machine generates a QR code that the consumer device scans to initiate the order placement process; which is particularly useful in scenarios where wireless communication might be unreliable and when avoiding wireless configurations is desired. Various suitable communication approaches can be used as appropriate to ensure a versatile approach to secure, direct communication between the consumer device and the self-serve machine; accommodating various environmental constraints and enhancing the reliability of offline vending.

[0048] In an example implementation of the embodiments of the present disclosure, a customer can install a mobile application onto their mobile device. The application can include an account for the customer that includes, at least, identifying information and payment information. Upon arriving at the self-serve machine, the customer receives communications with respect to products offered directly from the self-serve machine on their mobile device using the application or web interface. The communications can be received through one of the direct communication approaches, such as using a scanned QR code, using NFC, or using a Bluetooth™ protocol such as Bluetooth Low Energy (BLE). Using the communications approach, the consumer device can transmit order details to the self-serve machine. In most cases, the same communication approach can be used for communicating product offerings and for communicating the consumer’s order. The self-serve machine receives the order and provides the service or product as specified.

[0049] Referring now to FIG. 1, a system for offline vending 100 is shown, in accordance with an embodiment. In this embodiment, the system 100 includes one or more consumer devices 200, one or more self-serve machines 300, and a management server 400. The consumer device(s) 200 and the self-serve machine(s) 300 can communicate with each other, as described herein. In some cases, the consumer device(s) 200 and the self-serve machine(s) 300 can be in communication with the management server 400 over a network 110 (for example, a wireless data network or the Internet). The functions of the consumer device 200, the self-serve machine 300, and the management server 400 can be executed on any suitable device; for example, a desktop computer, a laptop computer, a smartphone, a tablet computer,a mobile device, a smartwatch, dedicated processing hardware, or the like. In further embodiments, aspects or functions of the system 100 can be run on further computing devices, such as a separate server. In some embodiments, the components of consumer device 200, the self-serve machine 300, and the management server 400 are each stored by and executed on a single computing device. In other embodiments, the components of the consumer device 200, the self-serve machine 300, and the management server 400 can be each distributed among two or more computing devices that may be locally or remotely distributed. In further cases, the functions of the management server 400 can be performed by the self-serve machine 300, or vice versa.

[0050] FIG. 2 shows an example embodiment of the consumer device 200 including various physical and logical components. As shown, the consumer device 200 has a number of physical and logical components, including a consumer device central processing unit (“CPU”) 204 (comprising one or more processors), consumer device random access memory (“RAM”) 206, a consumer device input interface 208, a consumer device output interface 210, a consumer device non-volatile storage 214, a consumer device network interface 216, and a local bus 202 enabling the consumer device CPU 204 to communicate with the other components. The consumer device CPU 204 executes an operating system, and various modules. The consumer device RAM 206 provides relatively responsive volatile storage to CPU 204. The consumer device input interface 208 enables a consumer device operator to provide input via an input device, for example, a programming module, a keyboard and mouse, a camera, a barcode scanner, a QR code scanner, an RFID interface, an NFC interface, a Bluetooth™ interface, or the like. The consumer device output interface 210 outputs information to output devices, such as a speaker and / or a display. The consumer device network interface 216 permits communication with other systems, such as the self-serve machine 300, or the management server 400, over the network 110; or with other computing devices and servers such as for a typical cloud-based access model. Non-volatile storage 214 stores the operating system and programs, including computer-executable instructions for implementing the operating system and modules, as well as any data used by the operating system and modules. Additional stored data can be stored in consumer device databases 220. During operation of the consumer device 200, the operating system, the functional operations, various modules, and the related data may be retrieved from the consumer device non-volatile storage 214 and placed in the consumer device RAM 206 to facilitate execution.

[0051] FIG. 3 shows an example embodiment of the self-serve machine 300 including various physical and logical components. As shown, the self-serve machine 300 has a number of physical and logical components, including a self-serve machine CPU 304 (comprising one or more processors), self-serve machine RAM 306, a self-serve machine input interface 308, a self-serve machine output interface 310, a self-serve machine non-volatile storage 314, a self-serve machine network interface 316, and a local bus 302 enabling the self-serve machine CPU 304 to communicate with the other components. The self-serve machine CPU 304 executes an operating system, and various modules. The self-serve machine RAM 306 provides relatively responsive volatile storage to CPU 304. The self-serve machine input interface 308 enables a users to provide input via an input device, for example, a programming module, a keyboard and mouse, camera, a barcode scanner, a QR code scanner, an RFID interface, an NFC interface, a Bluetooth™ interface, or the like. The self-serve machine output interface 310 outputs information to output devices, such as a speaker and / or a display. The self-serve machine 300 communicates with other systems, such as the consumer device 200, or the management server 400, over the network 110; or with other computing devices and servers, such as for a typical cloud-based access model. Non-volatile storage 314 stores the operating system and programs, including computer-executable instructions for implementing the operating system and modules, as well as any data used by the operating system and modules. Additional stored data can be stored in self-serve machine databases 320. During operation of the self-serve machine 300, the operating system, the functions and operations, and the related data may be retrieved from the self-serve machine non-volatile storage 314 and placed in the self-serve machine RAM 306 to facilitate execution.

[0052] FIG. 4 shows an example embodiment of the management server 400 including various physical and logical components. As shown, the management server 400 has a number of physical and logical components, including a server CPU 404 (comprising one or more processors), a server RAM 406, a server input interface 408, a server output interface 410, a server non-volatile storage 414, a server network interface 416, and a local bus 402 enabling the server CPU 404 to communicate with the other components. The server CPU 404 executes an operating system, and various modules. The server RAM 406 provides relatively responsive volatile storage to the server CPU 204. The server input interface 408 enables a user to provide input via an input device, for example a programming module or a keyboard and mouse. The server output interface 410 outputs information to output devices, such as a speaker and / or a display. The server network interface 416 permits communication with other systems, such as the consumer device 200, or the self-serve machine 300, over the network 110; or with othercomputing devices and servers such as for a typical cloud-based access model. Non-volatile storage 414 stores the operating system and programs, including computer-executable instructions for implementing the operating system and modules, as well as any data used by the operating system and modules. Additional stored data can be stored in server databases 420. During operation of the management server 400, the operating system, the functions and operations, and the related data may be retrieved from the server non-volatile storage 414 and placed in the server RAM 406 to facilitate execution.

[0053] Now referring to FIG. 5, a flowchart of an embodiment of a method 500 for operating the system 100 is shown in accordance with an embodiment. In some embodiments, at block 502, the server encryption-decryption module 418 creates encryption / decryption key pairs used in the system 100. Each key pair can be stored, for example, in the databases 420. These key pairs are used for secure communication between the self-serve machine 300, the consumer device 200, and / or the management server 400.

[0054] In a particular case, at least two types of key pairs are used for (a) product and service offerings, and (b) order placement. The encryption key of the product-offering key pair is only shared with and used by the self-serve machine 300 to send a list of product and service offerings to the consumer device 200. The consumer device 200 can decrypt the product and service offerings of the self-serve machine 300 using the decryption key of the product-offering key pair. Conversely, the encryption key of the order-placement key pair is only shared with and used by the consumer device 200 to send an order to the self-serve machine 300. The self-serve machine 300 can decrypt the order of the consumer device 200 using the decryption key of the order-placement key pair.

[0055] In some cases, a log-transfer key pair is used by the self-serve machine 300 and the management server 400. The encryption key of the log-transfer key pair is only shared with and used by the self-serve machine 300 to embed an encrypted log of recent purchase transactions within the product and service offerings that is later generated by the self-serve machine 300 and read by the consumer device 200. The encrypted purchase log is held by the consumer device 200 to be transferred, in its encrypted form, to the management server 400. Once received, the management server 400 can decrypt the encrypted purchase log of the self-serve machine 300 using the decryption key of the log-transfer key pair and consolidate the received purchase logs with existing purchase logs which were previously known to the management server 400.

[0056] At block 504, depending on the type of key pair, each one of the encryption and decryption keys of each key pair is assigned by the management server 400 to a group of one or more consumer devices 200 or a group of one or more self-serve machines 300, which, for example, can belong to a specific consumer or a specific self-serve machine operator or location. In some cases, each one of these key pairs can have a general or distinct expiration date or valid use time value assigned to them.

[0057] At block 506, the management server 400 communicates each one of the assigned encryption and / or decryption keys to the assigned self-serve machine 300. The assigned self-serve machine 300 stores the assigned keys, such as in the non-volatile storage 314 and / or databases 320. In some cases, at block 508, the management server 400 communicates each one of the assigned encryption and / or decryption keys to the assigned consumer device 200. The assigned consumer device 200 stores the assigned keys, for example, in the non-volatile storage 214 and / or the databases 220. In some cases, the management server determines if any of the assigned key pairs have expired. If expired, the management server regenerates and securely transmits replacement key pairs to the respective devices.

[0058] At block 510, the self-serve machine 300 generates a combination of an encrypted list of the product offering and an encrypted purchase log. The list of the product offering is encrypted by the self-serve machine 300 using the product-offering encryption key of the assigned product-offering key pair. The purchase logs are encrypted using a log-transfer encryption key associated with a log-transfer key pair. The self-serve machine 300 makes the combined list of the product offering communicable to the consumer device 200. In some cases, the purchase logs may include, for each transaction, a timestamp, a self-serve machine identifier, a unique transaction identifier, and a checksum. In some other cases, the combine list may include the product offering only.

[0059] At block 512, the self-serve machine 300 transmits the combined list of the encrypted product offerings and the encrypted purchase logs to the consumer-device 200. The consumer device 200 receives and stores the encrypted product offerings and the encrypted purchase log in, for example, the non-volatile storage 214 and / or databases 220. The encrypted purchase log is stored in the consumer device 200 to be transferred to the management server 400 when a connection can be established between the consumer device 200 and the management server 400.

[0060] At block 514, the product offerings are decrypted by the consumer device 200 using the product-offering decryption key of the product-offering key pair. The product offerings are thenvalidated against pre-defined rules and expected messaging format. In cases where the encrypted combined product offering list includes encrypted purchase logs, the encrypted purchase log remains encrypted as the log-transfer decryption key of the log-transfer key pair is never shared with the consumer device 200. The consumer device 200 generates a list of products from the decrypted list of product offerings and displays them to the user of the consumer device 200, for example, through the output interface 210 (such as a digital screen).

[0061] At block 515, the user selects and / or customizes a purchase order using the input interface 208. The user continues by placing the order, the details of which are stored in the non-volatile storage 214 and / or databases 220.

[0062] At block 516, the consumer device 200 generates an encrypted purchase order using an order-placement encryption key of the assigned order-placement key pair. The consumer device 200 makes the encrypted purchase order available to be received by the self-serve machine 300. In some cases, where offline orders are permissible, the consumer device 200 makes its encrypted balance token and transaction tokens, if any, available to be received by the self-serve machine 300. These tokens are used by the self-serve machine 300 to verify and reconcile the consumer's remaining balance before proceeding with the transaction.

[0063] The transmission and receipt of the product offerings and the transmission and receipt of the purchase order may be done by any suitable technique, for example, using Bluetooth™, Bluetooth Low Energy (BLE), NFC, RFID, Wi-Fi, Wi-Fi Direct, or a QR code. In an example, the transmission and receipt may involve displaying a QR code on a digital screen of the self-serve machine 300 and capturing the QR code by a QR-code scanner or camera of the consumer device 200; or conversely, displaying a QR code on a digital screen of the consumer device 200, and capturing the QR code by a QR-code scanner or camera of the self-serve machine 300. In other cases, the transmission and receipt may involve attaching an NFC enabled consumer device 200, such as an NFC enabled mobile device or digital watch, on an NFC enabled self-serve machine 300. In further cases, the transfer and receipt of the product offerings and purchase orders may involve using Bluetooth™ enabled devices or BLE. In some cases, the transmission and receipt of the product offerings can be performed using a technique different from the transmission and receipt of the purchase order. For example, the transmission and receipt of the product offering can be performed using QR-code, while order placement is performed using Bluetooth™.

[0064] At block 518, the consumer device 200 transmits the encrypted purchase order to the self-serve machine 300. The self-serve machine 300 stores the details of the purchase order in, for example, the non-volatile storage 314 and / or databases 320.

[0065] In circumstances that require offline payment, the self-serve machine 300 only reads the encrypted purchase order from the consumer device 200 and stores the details of the purchase for verification of the transaction. The self-serve machine 300 verifies and reconciles the balance token and transaction tokens. Verification includes checking the references within each transaction token to ensure they link correctly to their previous transaction or the balance token. If the balance token and all associated transactions are valid, the self-serve machine 300 calculates the remaining balance by deducting the value of all transaction tokens from the balance token. If any transaction tokens are missing or the references do not match, the self-serve machine 300 can take a specific action, for example, it can halt the process, display an error message to the consumer, and / or flag the transaction for further review in addition to reconcile the discrepancy. After successful verification of the tokens and calculating the remaining balance, the self-serve machine 300 determines if the remaining balance is sufficient for the current transaction. If the balance is sufficient, the self-serve machine 300 proceeds with the transaction. If the balance is insufficient, the transaction is declined, and the consumer device 200 is notified.

[0066] At block 520, the encrypted purchase order is decrypted by the self-serve machine 300 using the order-placement decryption key of the order-placement key pair. The self-serve machine 300 renders the purchase order, after the order is validated, against pre-defined rules and expected messaging format.

[0067] In cases with offline payment, for a validated transaction, the self-serve machine 300 can additionally generate a new encrypted transaction token. This new transaction token can include the transaction value and references the most recent transaction or balance token, as applicable. The new transaction token is then sent back to the consumer device 200 for storage in its wallet repository.

[0068] At block 522, the self-serve machine 300 sends a purchase log to the management server 400. The transmission of the purchase log can be performed independently of the other operations, such as whenever the self-serve machine 300 is able communicate with management server 400. In some cases, the transfer is performed by a technician, for example, using a portable data storage device such as a USB flash memory or the like.

[0069] At block 524, the consumer device 200 sends its copy of the encrypted purchase logs to the management server 400 once a connection can be established between the consumer device 200 and the management server 400; and subject to other limitations such as readiness of the management server 400 to receive the encrypted purchase logs. The transmission of the purchase log can be performed independently of the other operations; such as whenever the self-serve machine 300 is able to communicate with management server 400, for example, when a network connection is available. In some cases, the consumer device 200 transfers the encrypted purchase log of one or several self-serve machines 300, to the management server 400.

[0070] Where offline payment is required, in some cases, the number of transaction tokens that can be stored in the wallet of the consumer device 200 may be hard limited to a predefined cap. In some cases, there may be a hard limit on the purchase log records. Similarly, a number of soft limits on the total number of transaction tokens or a series of soft limits on a specific type of token or log can be defined. When these soft limits are reached, the consumer device 200 can communicate with the management server 400 to transfer and reconcile all records. During this reconciliation, the management server 400 replaces the existing balance token and all transaction tokens with a new balance token, reflecting the updated balance. After this communication, the consumer device 200 can continue to perform new transactions. In some cases, regardless of whether the soft limits or hard limits are reached or not, the consumer device 200 can communicate with the management server 400 to transfer and reconcile all records.

[0071] At block 526, the management server 400 decrypts purchase logs using the decryption key of the log-transfer key pair and consolidates any new purchase logs with existing details of the purchase transactions of all self-serve machines 300. The management server 400 may identify any discrepancies and can inform operators to take corrective actions as necessary.

[0072] In some cases, after consolidation of the purchase logs, the management server 400 gradually shares the serial number of the latest consolidated transaction with the consumer devices 200. The shared serial number may be embedded in the next purchase order of the respective consumer device 200 to indicate an acknowledgment to the self-serve machine 300 that is offline. Once enough acknowledgments are received by the self-serve machine 300, the next encrypted purchase log of the self-serve machine 300 can not include the acknowledged purchase logs.

[0073] In some cases, several key pairs can be randomly generated and used for each type of key pairs; for example, instead of a single product-offering key pair for a self-serve machine 300, several product-offering key pairs can be generated at block 502. In some cases, one of the product-offering encryption keys can be selected randomly to be used for generating the encrypted products and services offering list. In some cases, the consumer device 200 can use a matching product-offering decryption key. Several approaches may be used by consumer device 200 to identify the matching product-offering decryption key; for example, an identification serial number along with the encrypted products and services offering message may be used, or alternatively, the consumer device 200 may try each one of its known decryption keys to find the matching one.

[0074] In some cases, offline payments can be handled as described above, without necessarily requiring offline order placement. In such cases, handling offline payment mechanisms can allow consumers to complete transactions without an active internet connection, using locally stored tokens that are securely exchanged between the consumer device 200 and the self-serve machine 300. Such an approach is particularly beneficial in certain scenarios, such as rural areas with limited network coverage, underground facilities like parking lots or basement laundromats, and locations where wireless networks are unreliable or restricted.

[0075] FIG. 6 illustrates a flowchart of a method 600 for offline vending in accordance with another embodiment. This embodiment is primarily used for offline payment only, and thus, without necessarily requiring order placement.

[0076] At block 602, the management server 400 generates a balance token key pair and a transaction key pair. These key pairs are securely stored on the management server 400 or one or more of the databases 420. The balance token decryption key of the balance token key pair, and the transaction encryption-decryption key pair are then transferred to the one or more self-serve machines 300 for later use. In some embodiments, the balance-token decryption key or the transaction-token decryption key, or both, may also be transferred to the one or more consumer devices 200 to enable decryption of balance tokens and / or transaction tokens on the one or more consumer devices 200.

[0077] At block 604, a balance token is generated by the management server 400. The generated balance token is encrypted using a balance token encryption key and stored on the management server 400 or one of the databases 420. The balance token is initialized based on a preloaded account balance, which can be set up when the consumer is connected to amanagement server 400. For example, if a consumer’s account has a balance of $50, the consumer device 200 will generate a balance token representing this amount, which can include embedded details such as an account identifier, a timestamp, and an encrypted checksum to ensure the integrity of the data.

[0078] At block 606, the management server 400 transmits the balance token to the consumer device 200 to be stored within a secure storage area, such as a Trusted Execution Environment (TEE) or a secure storage within the device’s hardware. This secure storage area prevents tampering and ensures that the balance token cannot be altered or duplicated.

[0079] At block 608, the consumer device 200 transmits the encrypted balance token to the self-serve machine 300 using a direct communication method; such as RFID, NFC, Bluetooth™, BLE, Wi-Fi, Wi-Fi Direct, a dynamically created QR barcode, or another suitable local communication protocol. For example, the consumer may tap their smartphone on an NFC-enabled self-serve machine 300 to initiate the transmission, or the consumer device 200 may use BLE to automatically detect and connect to the self-serve machine 300 within a defined proximity. The balance token can be transmitted securely, ensuring that only the intended recipient (the self-serve machine 300) can decrypt and use it. This secure transmission enables the transaction to be initiated even when there is no connection to a management server 400, making the system 100 robust against network outages or restricted access points.

[0080] At block 610, the self-serve machine 300 receives the balance token as well as any additional transaction tokens stored on the consumer device 200. Receiving the balance token can include decrypting the balance token and transaction tokens using a previously stored decryption key that was stored securely within the self-serve machine 300.

[0081] At block 612, the self-serve machine 300 validates the received balance token. During validation of the balance token, the self-serve machine 300 checks various attributes of the balance token, such as the account identifier, the timestamp, and a digital signature to verify the authenticity of the balance token. It also ensures that the balance token is not expired, previously used, or otherwise marked as invalid. For example, if the balance token was generated more than 48 hours ago, the machine may flag it as expired, requiring the consumer to provide a new balance token. If the balance token is not validated for any reason, for example if the balance token is expired, the consumer device 200 has to become online again, as described at block 624, to communicate with the management server 400 to receive a new balance token, or if required by the management server 400, initiate reconciliation of the transaction tokens stored on the consumer device 200.

[0082] At block 614, the self-serve machine 300 validates the received transaction tokens, should there be any. Similar to the balance tokens, the validation of the transaction tokens involves decryption of the transaction tokens using decryption keys of the transaction tokens, which were previously stored on the self-serve machine 300. Once decrypted, the self-serve machine 300 checks various attributes of the transaction token, to verify the authenticity of the token. The attributes of the transaction token can include all attributes of the balance token, and additionally, a reference to its previous balance token or transaction token. Such references ensure that the entire set of balance tokens and transaction tokens are transferred to the self-serve machine 300 and a final balance can be calculated for the respective consumer or the consumer device 200. Similar to the balance token, additional attributes can be used to ensure that the received tokens are not expired, or otherwise marked as invalid. For example, if any of the transaction tokens were generated more than 48 hours ago, the machine may flag it as expired, requiring the consumer device 200 to communicate with the management server 400, as described at block 624, to reconcile the existing balance token and transaction tokens with the management server 400 or otherwise provide a new balance token. If the balance token is successfully validated, the machine accepts it as proof of the consumer’s available balance for the offline transactions.

[0083] At block 616 the self-serve machine 300 calculates the available balance of the consumer device 200. If the balance token is successfully validated in previous steps, and there is no transaction tokens, the machine accepts it as proof of the consumer’s available balance for the offline transactions. If there are validated balance tokens, the combination of balance tokens with their balance or transaction amount, and their lineage to their previous tokens are verified by the self-serve machine 300 to calculate the available balance for the consumer device 200. If any verification fails, the consumer device 200 has to be able to communicate with the management server 400 to receive a new balance token, as described at block 624.

[0084] At block 617, the self-serve machine 300, compares the available balance of the consumer device 200 with the required balance to complete the purchase transaction. When the remaining balance is sufficient to complete the purchase transaction, the self-service machine 300 authorizes the transaction and proceeds to create a transaction token representing the authorized purchase.

[0085] At block 618, the self-serve machine 300 creates a transaction token based on the amount required for the selected service or product. For instance, if the consumer wishes to purchase a coffee priced at $3.50, the transaction token will include details of the transaction,such as the purchase amount, a reference to the validated balance token, the latest transaction token, a unique transaction identifier , and / or a timestamp indicating when the transaction was initiated. The self-serve machine 300 can then encrypt the transaction token using its transaction-token encryption key and transmit it to the consumer device 200, which can be via the same communication method employed in the initial transmission (e.g., NFC or BLE). This transaction token serves as proof that the balance has been allocated for the specific transaction, preventing the consumer from reusing the same balance token for multiple purchases.

[0086] At block 620, the consumer device 200 receives the transaction token and updates the balance token stored locally. This amount is primarily used for displaying the balance on the consumer device 200. Specifically, the consumer device 200 deducts the transaction amount from its locally stored balance token, ensuring that the updated balance accurately reflects the remaining amount after the current transaction. For example, if the consumer’s initial balance was $50 and $3.50 was used for the coffee purchase, the updated balance will now show $46.50. This step is performed using secure local storage mechanisms, ensuring that the balance cannot be altered without authorization. The consumer device 200 also stores a record of the transaction token, linking it to the updated balance token for future reference and reconciliation.

[0087] At block 622, the consumer device 200 securely stores the transaction token and maintains it as proof of payment. For example, if the self-serve machine 300 is a laundromat machine, the consumer device 200 can use the stored transaction token to activate the machine, triggering the start of a washing cycle. The transaction token is maintained in the secure storage area of the consumer device 200 at least until a connection to the management server 400 can be established. The self-serve machine 300, having received confirmation of the transaction, proceeds to provide the requested service or dispense the selected product. This ensures that the provided product or service is rendered based on a valid transaction, even without real-time communication with the management server 400.

[0088] At block 624, the consumer device 200 synchronizes all, or a subset of, the stored transaction tokens with the management server 400 upon establishing an internet connection, for example, at a later time. For instance, the consumer may connect their device to Wi-Fi at home or use mobile data to send the transaction tokens to the management server 400. The management server 400 receives the encrypted transaction tokens, along with a reference to the associated balance tokens, to facilitate accurate reconciliation. This synchronization ensuresthat the management server 400 has a complete and up-to-date record of all transactions, even those completed offline.

[0089] At block 626, the management server 400 decrypts the transaction token and performs reconciliation by consolidating the new transaction with existing records. The management server 400 verifies the authenticity of the transaction token, checks the associated balance token for consistency, and updates the consumer’s account balance accordingly. After updating the account balance, the management server 400 generates a new balance token, as described in block 604, and blocks 606 to 624 can be repeated for future transactions. In some cases, the management server 400 can detect anomalies, such as discrepancies between the local balance and the server-side records, in which case the management server 400 can initiate corrective actions, such as alerting the system administrator or suspending the consumer’s account for further investigation. This can ensure the integrity of the overall payment system and prevent misuse of offline tokens.

[0090] Fig. 7 illustrates a flowchart of a method 700 for offline payment in accordance with another embodiment. This embodiment is particularly directed to enabling secure monetary transactions between the consumer device 200 and a payment processing machine, such as the self-serve machine 300, in the absence of an internet connection. This is achieved by generating, transmitting, and validating balance and transaction tokens that facilitate offline payment, then later synchronizing the transaction with the management server 400. The encryption and decryption keys of the balance token key pairs and the transaction token key pairs are generated and suitably distributed prior to, or during, execution of method 700.

[0091] At block 702, the management server 400 initializes a balance token. The balance token is created based on the consumer’s available account balance, which is preloaded when the consumer is connected to the management server 400. For example, if the consumer has a $50 balance in their account, the balance token will reflect this amount.

[0092] At block 704, the balance token is encrypted by the management server 400 using an encryption key of a balance token encryption key. In some cases, the balance token encryption key is unique to the consumer device 200. This encryption ensures that the token cannot be tampered with or duplicated by unauthorized parties.

[0093] At block 706, the encrypted balance token is securely transmitted to the consumer device 200. In some cases, the consumer device 200 can securely store the token within a secure hardware environment, such as a Trusted Execution Environment (TEE) or a secureenclave. This secure storage guarantees that the token’s integrity is maintained even if the device 200 is later used offline.

[0094] At block 708, the consumer device 200 establishes a communication channel with the self-serve machine 300; for example, via RFID, NFC, Bluetooth™, Bluetooth Low Energy (BLE), Wi-Fi, Wi-Fi Direct, a dynamically created QR barcode, or other local communication protocols.

[0095] At block 710, the consumer device 200 transmits the encrypted balance token and any existing transaction tokens to the self-serve machine 300 over the established communication channel. This allows the self-serve machine 300 to initiate the payment process.

[0096] At block 712, the self-serve machine 300 decrypts the balance token and all transaction tokens using existing decryption keys stored securely on the machine. These key are specifically assigned to the self-serve machine 300 and are used to verify the authenticity of the received balance token and the transaction tokens.

[0097] At block 714, the self-serve machine 300 validates the balance token and transaction tokens by checking their integrity, timestamp, and digital signature. For example, if a balance token has expired or has been previously used, the self-serve machine 300 will reject the transaction. If all tokens are valid, the self-serve machine 300 calculates the available balance using the balance token and all transaction tokens to identify the available balance associated with the consumer device 200 and / or account.

[0098] At block 716, the self-serve machine 300 verifies that the available balance is sufficient to cover the transaction amount. If the balance is insufficient, the self-serve machine 300 may request an alternative payment avenue.

[0099] At block 718, the self-serve machine 300 generates a new transaction token. This new transaction token can include various details, such as the transaction amount, reference to the validated balance token, and a unique transaction ID.

[0100] At block 720, the self-serve machine 300 encrypts the new transaction token using the encryption key associated with the self-serve machine 300. The encryption ensures that the new transaction token is securely transmitted back to the consumer device 200.

[0101] At block 722, the self-serve machine 300 transmits the encrypted transaction token to the consumer device 200, such as over the same communication channel used for the initial transmission.

[0102] At block 724, the consumer device 200 receives the encrypted transaction token. In some cases, the consumer device 200 decrypts the new transaction token using its corresponding decryption key and validates the transaction details by comparing it to the consumer device’s 200 records of the transaction.

[0103] In some cases, at block 726, the consumer device 200 locally updates the transaction amount to the locally stored balance. For example, if the locally stored balance is $50 and the transaction amount is $3.50, the locally stored balance would be updated to $46.50.

[0104] In some embodiments, at block 728, the consumer device 200 updates its local purchase log to record the completed transaction and the adjusted balance. This purchase log can be securely stored in the same secure hardware environment as the balance token. The local purchase log may be used to reconcile the payment with the management server 400 at a later stage.

[0105] At block 730, the self-serve machine 300, upon receiving confirmation from the consumer device 200, provides the requested service or product; for example, dispensing a beverage or starting a car wash cycle.

[0106] At block 732, the consumer device 200 establishes a secure communication channel with the management server 400, for example, at a later time. This connection may be established through Wi-Fi, mobile data, or any other available network connection.

[0107] At block 734, the consumer device 200 transmits all, or a subset of, stored transaction tokens to the management server 400 for reconciliation. Each token is transmitted securely, ensuring that no unauthorized third parties can intercept or alter the data.

[0108] At block 736, the management server 400 decrypts the transaction tokens using its decryption key. The management server 400 verifies the authenticity of each token and checks the corresponding balance tokens for accuracy.

[0109] At block 738, the management server 400 updates the consumer’s account balance by consolidating the offline transactions with any other transactions processed. In some cases, the management server 400 can then regenerate a new balance token and transfer it back to the consumer device 200 to replace with the existing balance token and all transaction tokens sent to the management server 400 for reconciliation. The generation, encryption, and transmission of the new balance token can be performed similar to blocks 702 to 706.

[0110] At block 740, the management server 400 checks for any discrepancies, such as duplicate tokens or incorrect amounts. If discrepancies are found, the management server 400 can flag them for further investigation. In some cases, the management server 400 completes the reconciliation by generating a report summarizing all offline and online transactions. This report can be used for accounting purposes and ensures that both the consumer and the self-serve machine 300 have accurately recorded transactions.

[0111] In further cases, the generation and validation of tokens may occur using a different approach, or in a modified order, based on specific system configurations or customer requirements.

[0112] Those skilled in the art would appreciate that the method 700 may be used for any other form of monetary transaction, such as payment, deposit of funds, withdrawal of funds, or transfer of funds using one or more offline devices. For example, using an offline service kiosk, an offline automatic teller machine, an offline mobile device, or an offline mobile application. It will be appreciated that the method 600 may be used in other machines which are not strictly designed for providing self-serve services, for example, in a point of sale (POS) terminal, or in any other configuration of devices that require monetary transaction processing.

[0113] In some cases, the transfer of purchase logs from the self-serve machine 300 to the management server 400 can be adapted for offline data transfer. For example, the purchase log transfer approach described in the method 500 at blocks 510 to 514 and at blocks 522 to 526 can be used for transferring various types of data. In example cases, data transfer can be bidirectional, allowing data to flow either from the self-serve machine 300 to the management server 400 or from the management server 400 to the self-serve machine 300. This bidirectional data transfer in an offline configuration can be referred to as “bidirectional offline data transfer” or “offline data transfer”.

[0114] The bidirectional offline data transfer described in method 500 enables the transmission of any type of data without requiring a real-time connection between the two devices. For example, without requiring a direct network connection between a sender and a receiver, which is typical in conventional data transfer schemes. Instead, the method 500 supports configurations where either the sender, the receiver, or both are offline or otherwise disconnected. Offline data transfer can utilize one or more intermediary devices (such as the consumer device 200) to relay chunks of data between the sender and receiver. These intermediary devices connect to the sender, or the receiver, at different points of time to receive and / or forward the data.

[0115] The data transferred may include but is not limited to configuration updates, new product information, software or firmware updates, and system instructions. The flexibility of the method 500 allows the system 100 to support various data types.

[0116] In some cases, the bidirectional offline data transfer can be used by the consumer device 200 to transfer purchase logs, operational logs, software updates, or configurations to the management server 400, the self-serve machines 300, or both. Additionally, the offline data transfer can be used for communication between the management server 400 and the self-serve machines 300 using the consumer devices 200.

[0117] In some cases, the bidirectional offline data transfer can be performed alongside, or performed independently, of offline order placement or offline payment. This flexibility allows certain types of data transfers, such as firmware updates, to occur without necessarily requiring customer interaction with the management server 400, the self-serve machine 300, or any form of intermediary devices. The data transfer can be performed asynchronously using several of the consumer devices 200 acting solely as transfer mediums. In either case, the offline data transfer ensures that data integrity and security are maintained during various stages of the offline data exchange.

[0118] In some cases, a data-transfer key pair is used for encrypting and decrypting datasets communicated during offline data transfer. The data-transfer key pair comprises a data-transfer encryption key and a data-transfer decryption key, which together enable end-to-end protection of the transmitted data chunks. The data-transfer encryption key is stored by the sender device, and the data-transfer decryption key is stored by the corresponding receiver device, allowing only the intended receiver to decrypt and reconstruct the dataset. The data-transfer key pair may be generated and distributed by the management server 400 in a manner similar to the product-offering, order-placement, and log-transfer key pairs described above, ensuring uniform key-management procedures for offline vending.

[0119] FIG. 8 illustrates a method 800 for bidirectional offline data transfer, in accordance with an embodiment. This method enables secure, bidirectional data transfer between the self-serve machine 300 and the management server 400 using the consumer devices 200 as intermediaries. The method 800 is particularly suited for environments where direct, real-time communication between the self-serve machine 300 and the management server 400 is not feasible due to limited or unreliable network connectivity.

[0120] For simplicity, the described method 800 refers to “sender” and “receiver”. Whereby the sender is device (either the management server 400 or the self-serve machine 300) that is desirous to send data to the receiver (either the management server 400 or the self-serve machine 300). For example, the management server 400 can act as the sender when sending configuration files to one of the self-serve machines 300, which is acting as a receiver. In other cases, such as the scenario of purchase log transfers from the self-serve machines 300 to the management server 400, the self-serve machine 300 would be referred to as the sender and the management server 400 would be referred to as the receiver.

[0121] In some cases, to ensure reliable data transmission, the data to be communicated can be divided into multiple smaller chunks, each of which can be transmitted using direct communication methods such as Bluetooth™, BLE, RFID, NFC, Wi-Fi, Wi-Fi Direct, or scanning QR codes.

[0122] In some cases, each data chunk includes a checksum embedded within or alongside the data prior to transmission, enabling the receiver to verify integrity upon decryption before reassembly.

[0123] At block 802, the sender (e.g. the management server 400 or the self-serve machine 300, as the case may be), initializes a dataset for transfer. In some cases, the dataset can be divided into smaller data chunks, the size of which can be determined based on the constraints of the communication approach used. For instance, BLE broadcast messages are typically limited to 20 bytes of payload data, whereas a single QR code can encode up to several kilobytes depending on the QR version and error correction level. Each chunk can be labeled with a unique data packet sequence ID, which specifies the position of the data chunk in the overall dataset, the total number of chunks in the sequence, and the originating source.

[0124] In some cases, several series of data chunks may be generated concurrently based on the constraints of several communication approaches.

[0125] At block 804, the sender (e.g. the management server 400 or the self-serve machine 300, as the case may be) encrypts each data chunk using the data-transfer encryption key of the data-transfer key pair, the corresponding data-transfer decryption key being stored by the receiver device. This encryption ensures that the data remains confidential and cannot be intercepted, read, or altered by unauthorized parties.

[0126] The consumer device 200, acting as an intermediary, is only able to receive, transmit, and store the encrypted chunks without knowing their contents or sequence. To furthersafeguard this obfuscation, the metadata of each chunk, including the sequence number and source identifiers, can be encrypted within the chunk itself, preventing the consumer device 200 from identifying which part of the dataset it is handling.

[0127] At block 806, the consumer device 200 establishes a direct communication channel with the sender (e.g. the management server 400 or the self-serve machine 300, as the case may be) using a suitable protocol, such as Wi-Fi, cellular data, or any other communication protocol.

[0128] In cases where the sender is the management server 400, the direct communication of block 806 can be established once an internet connection or other suitable form of communication is available. This communication may be established through Wi-Fi, mobile data, or any other suitable network connection.

[0129] In cases where the sender is one of the self-serve machines 300, the consumer device 200 may establish the direct communication channel with the sender using various suitable protocols, such as Bluetooth™, BLE, RFID, NFC, Wi-Fi, Wi-Fi Direct, or scanning a QR code displayed on the output interface 210.

[0130] At block 808, the sender device (e.g. the management server 400 or the self-serve machine 300, as the case may be) transmits the encrypted data chunks to the consumer device 200. The transmission may occur in a single pass if the entire dataset fits within the consumer device’s storage capacity, or within the limits of the communication protocols used. The transmission of the entire set of encrypted data chunks may require multiple communication passes if the dataset is too large to be transferred in a single session.

[0131] Depending on the protocol used, the size of each transmitted data chunk may be constrained to a specific limit. For example, if NFC is used, the data chunks may be transferred sequentially in real-time, whereas with QR codes, each chunk can be displayed as a unique QR pattern that the consumer device 200 scans and captures without interpreting the data.

[0132] In some cases, a connection can be established with several consumer devices 200 to distribute a complete set of data chunks over several consumer devices 200. In some cases, each chunk can be redundantly transferred to several consumer devices 200 over a period of time, for a minimum or maximum number of times, or until a confirmation message is received.

[0133] At block 810, the consumer device 200 receives and temporarily stores the data chunks in their encrypted form; in most cases, keeping track of the chunks as opaque units of data without access to unencrypted metadata. The encrypted storage ensures that the consumer device 200 has no ability to interpret, reorder, or alter the chunks. The stored chunks arehandled based on their encrypted identifiers, ensuring that the consumer device 200 can function purely as a passive intermediary. The consumer device 200 can only discern that it is storing a series of encrypted data chunks, but it does not have the capacity to distinguish between individual chunks or access their sequence information.

[0134] At block 812, the consumer device 200 establishes a secure communication channel with the receiver (e.g. the management server 400 or the self-serve machine 300, as the case may be). Similar to block 806, a suitable direct communication channel may be used depending on the type of the receiver, for example Wi-Fi or cellular data when the receiver is the management server 400, or Wi-Fi, BLE, NFC, or a QR codes when the receiver is the self-serve machine 300. Upon establishing the connection, the consumer device 200 initiates the transfer of the stored encrypted data chunks to the receiver, maintaining the integrity of the chunks without being able to understand or reveal their contents.

[0135] At block 814, the receiver (e.g. the management server 400 or the self-serve machine 300, as the case may be) receives the encrypted data chunks and decrypts them using the data-transfer decryption key of the data-transfer key pair corresponding to the data-transfer encryption key of the same data-tranfer key pair used by the sender device. The receiver verifies the sequence numbers within the decrypted chunks to confirm that all parts of the dataset have been received and checks for any discrepancies, such as missing or duplicate chunks. If a chunk is missing, the receiver can request retransmission from the original source (the self-serve machine 300 or the management server 400) or flag the data as incomplete.

[0136] At block 816, the receiver (e.g. the management server 400 or the self-serve machine 300, as the case may be) reassembles the data chunks into the original dataset using the decrypted sequence numbers and source identifiers.

[0137] At block 818, the receiver verifies the integrity of the received data, followed by storing the verified data in the appropriate database or file system. In some cases, the receiver (e.g. the management server 400 or the self-serve machine 300, as the case may be) may generate a synchronization report that summarizes the status of the offline data transfer. This report may include details such as the number of chunks received, any missing or duplicate chunks, and the overall integrity of the transferred dataset. If the report indicates any anomalies, such as unmatched sequence numbers or incomplete datasets, corrective actions may be initiated to alert system operators or resolve the issues.

[0138] In some cases, at block 820, if the dataset is a configuration update for the self-serve machine 300, the self-serve machine 300 can apply the configuration changes locally. Similarly, if the dataset is a purchase log, the management server 400 can perform reconciliation to ensure that the new data is consistent with previously stored records.

[0139] In some cases, reassembly of data may rely on data chunks collected from several data chunk series of the same data. Data chunks from a series with smaller data chunks may be reassembled to generate a data chunk from a series with larger data chunks. For example, 5 data chunks from a series of 20 bytes data chunks may be reassembled to generate a data chunk from a series of 100 bytes data chunk.

[0140] It should be appreciated that the dataset types for the method 800 may vary depending on the device that is the sender. For example, the self-serve machine 300 may only send datasets that include operational logs, purchase logs, sales records, or error reports.Configuration updates, new product information, system instructions, or software / firmware updates are always initiated by the management server 400 and cannot be triggered by the self-serve machine 300.

[0141] In cases where software updates, firmware updates, or configuration updates are sent (including but not limited to new product information, new technical or business rules and configurations, or price changes), the management server 400 can initiate the offline transfer of data. Additionally, once the self-serve machine 300 reassembles the chunks of data into the original form of data, the self-serve machine 300 can apply updates or configurations specified in the transmitted dataset. For example, if the received data is a firmware update, the self-serve machine 300 can install the update to its firmware at a specified time. Once the reassembly and update are complete, the self-serve machine 300 can generate a local synchronization log confirming that the data was received and applied successfully. In some cases, the update time or other types of update rules or instructions may be included in the transmitted update by the self-serve machine 300.

[0142] In some cases, devices of a site operator, a site manager, a support agent, a dedicated portable edge server, or a dedicated portable edge server on the premise may be used to act as the role of the intermediary device (i.e., the consumer device 200). In other cases, one of the self-serve machines 300 can act as an intermediary device in order to receive and forward data chunks between the sender and the receiver. In further cases, especially when a self-serve machine 300 acts as an intermediary device, one of the intermediary devices may forward data chunks to another intermediary device for further forwarding.

[0143] In some cases, data chunks may indicate metadata information within the data chunk itself. In other cases, metadata information is treated as a separate piece of data to be transferred along the original data or along the series of data chunks. In either case, the metadata may include various details, for example, type of artifact being transferred (e.g., update package, configuration, pricing, purchase logs, etc.), previous chunk ID, current chunk ID, next chunk ID, data / file version, data / file date and time, chunk checksum, original file / data checksum, or other indicators such as location ID, serial number, operation ID, or other metadata details.

[0144] In some cases, predictive intelligence can be used by the management server 400 to anticipate the most likely updates that can be transferred by a consumer device 200 based on the location history of the consumer device 200. Such predictions can be used to decide which pieces of update chunks should be transferred to each user, to increase the likelihood of faster data transfer to the target self-serve machine. For example, if a user frequently goes to a specific location, the management server 400 can select the relevant update data chunks to transfer to the necessary updates for that location.

[0145] Those skilled in the art would appreciate that the robustness of the embodiments described herein for offline operation, including any combination of offline order placement, offline payment, or bidirectional offline data transfer. In some cases, suitable data synchronization, data integrity, and securing data transfer can be used to provide a seamless user experience. Robust encryption, error-checking mechanisms, and other data management techniques may be used to handle data synchronization. It will be appreciated that the encryption approaches used herein can be implemented using any suitable encryption scheme known in the art.

[0146] The integration of offline vending capabilities, such as any combination of offline order placement, offline payment, or bidirectional offline data transfer into self-serve machines represents a significant advancement in the realm of automated services. By allowing customers to place and customize orders and pay for orders without the need for constant internet connectivity, the offline operation mode enhances convenience, accessibility, and overall user satisfaction. Additionally, capabilities such as bidirectional offline data transfer significantly enhance efficiency of large-scale operations to extents that are not achievable by expanding traditional approaches to operation of self-serve machines.

[0147] While the present disclosure generally refers to encryption and decryption, it is understood that any suitable encoding and any other alternative use of key pairs, including various dedicated key pairs, may be used.

[0148] Although the invention has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the claims appended hereto.

Claims

CLAIMS1. A method for offline order placement, the method comprising:generating, at a self-serve machine, an encrypted list of product offerings and an encrypted purchase log, the encrypted list of product offerings encrypted using a product-offering encryption key of a product-offering key pair, the encrypted purchase log encrypted using a log-transfer encryption key of a log-transfer key pair;transmitting, from the self-serve machine, the combination of the encrypted list of product offerings and the encrypted purchase log to a consumer device to be stored on the consumer device, the consumer device is able to decrypt the encrypted list of product offerings using a product-offering decryption key of the product-offering key pair;receiving, at the self-serve machine, an encrypted purchase order from the consumer device, the purchase order comprises a selection of one or more items from the encrypted list of product offerings after the encrypted list of product offerings is decrypted by the consumer device using a product-offering decryption key of the product-offering key pair, the purchase order is encrypted by the consumer device using an order-placement encryption key of an order-placement key pair; anddecrypting, at the self-serve machine, the encrypted purchase order, using the orderplacement decryption key of the order-placement key pair for fulfillment of the purchase order by the self-serve machine.

2. The method of claim 1, further comprising validating, at the self-serve machine, the decrypted purchase order against a predefined message-format rule before fulfillment.

3. The method of claim 1, wherein the transmitting and receiving between the self-serve machine and the consumer device uses at least one of Bluetooth™, Bluetooth Low Energy, NFC, RFID, Wi-Fi, Wi-Fi Direct, and a Quick-Response (QR) code.

4. The method of claim 1, wherein the encrypted purchase log comprises a timestamp, a machine identifier, and a transaction identifier.

5. The method of claim 1, further comprising transmitting, from the consumer device to a management server, the stored encrypted purchase log after establishment of acommunication between the consumer device and the management server.

6. The method of claim 1 , wherein a management server decrypts the transmitted purchase log using a log-transfer decryption key of a log-transfer key pair, and wherein the management server records or reconciles the transmitted purchase log with a previously recorded purchase log.

7. The method of claim 1, further comprising determining, at a management server, expiration of each key pair and, upon expiration, generating and securely transmitting replacement key pairs to the corresponding devices.

8. A method for offline payment for a purchase transaction at a self-serve machine from a consumer device, the method comprising:Receiving an encrypted balance token and one or more encrypted transaction tokens from the consumer device, the encrypted balance token encrypted using a balancetoken encryption key of a balance-token key pair, the one or more encrypted transaction tokens encrypted using a transaction-token encryption key of a transaction-token key pair;decrypting the encrypted balance token and the one or more encrypted transaction tokens, the encrypted balance token decrypted using a balance-token decryption key associated with the balance-token key pair, the one or more encrypted transaction tokens decrypted using a transaction-token decryption key associated with the transaction-token key pair;validating the transaction tokens by verifying that each transaction token accords with a preceding transaction token or the balance token;determining a remaining balance based on the balance token and the validated transaction tokens; andauthorizing the purchase transaction when the remaining balance is sufficient to complete the purchase transaction.

9. The method of claim 8, further comprising declining, at the self-serve machine, the purchase transaction, when validation of the balance token or transaction tokens fails, or when theremaining balance is insufficient to complete the purchase transaction.

10. The method of claim 8, further comprising verifying, at the self-serve machine, one or more of a timestamp, an account identifier, and a digital signature associated with each balance token.

11. The method of claim 8, further comprising generating, at the self-serve machine, a new encrypted transaction token referencing the latest transaction, the new encrypted transaction token encrypted using the transaction-token encryption key; and transmitting, from the self-serve machine, the new encrypted transaction token to the consumer device.

12. The method of claim 8, further comprising reconciling, at a management server, tokens received from the consumer device by decrypting the tokens using the corresponding decryption keys and generating a new balance token reflecting an updated account balance.

13. The method of claim 8, wherein each balance token and transaction token each includes a validity timestamp defining a validity period for each balance token and transaction token, the validity timestamps used for validation of each balance token and transaction token.

14. The method of claim 8, wherein reaching a predefined maximum number of transaction tokens stored on the consumer device triggers reconciliation with a management server.

15. A method for offline data transfer between a sender device, a receiver device, and at least one intermediary device, the method comprising:dividing, at the sender device, a dataset into one or more data chunks;encrypting, at the sender device, each data chunk using a data-transfer encryption key corresponding to a data-transfer decryption key stored by the receiver device;transmitting, from the sender device, the encrypted data chunks to a first intermediary device;storing, at the first intermediary device, the encrypted data chunks for subsequent transfer to the receiver device or to a second intermediary device;transmitting, from the first intermediary device or the second intermediary device, the stored encrypted data chunks to the receiver device;decrypting, at the receiver device, each encrypted data chunk using the data-transfer decryption key; andreassembling, at the receiver device, the decrypted data chunks into the dataset sent by the sender device using an order determined from information associated with each data chunk.

16. The method of claim 15, wherein each data chunk includes a checksum embedded within or alongside the data chunk before transmission, and further comprising verifying, at the receiver device, the integrity of each decrypted data chunk using the embedded checksum before reassembly.

17. The method of claim 15, further comprising distributing subsets of the encrypted data chunks from the sender device across multiple intermediary devices.

18. The method of claim 15, further comprising detecting, at the receiver device, missing or duplicate data chunks and requesting retransmission from the sender device.

19. The method of claim 15, wherein transmitting is performed using at least one of Bluetooth™, Bluetooth Low Energy, Near-Field Communication, Wi-Fi, Wi-Fi Direct, and a Quick- Response (QR) code.

20. The method of claim 15, wherein the receiver device generates and stores a synchronization log identifying any missing, duplicate, or inconsistent data chunks detected during or after reassembly.

Images