Patent Description:
Mobile devices (e.g. smart phones) allow users to access data content and services from anywhere in the world. This mobility allows users to perform operations such as streaming media or making purchases from home, work, or anywhere else without being tied to any particular location. This mobility poses several technical challenges because the operations performed on a mobile device are not inherently linked with where the mobile device is located. In other words, there is not a correlation between operations being performed on a mobile device and the location of the mobile device. Another example of a technical challenge posed by the mobility of mobile devices is that they are typically not configured to communicate with other devices or systems where the mobile device is located. In existing systems, mobile devices operate independently from other devices. Allowing mobile devices to freely communicate with other devices poses a security risk for both the mobile device and other devices. For example, a bad actor may try to access one of the devices to perform malicious activities such as data exfiltration. In addition, allowing mobile devices and other devices to freely communicate reduces network bandwidth and performance of both the mobile device and other devices due to all the data traffic that is being generated between devices. The reduction in network bandwidth creates a bottle neck that limits the performance of a device and its ability to communicate with other devices.

<CIT> relates to the facilitation of transactions between customers, retailers and suppliers using smart devices using an application residing on a smart device to provide secure, encrypted communications with a proprietary server. <CIT> relates to a transaction processing system that use mobile phones as a means for making payments and money transfers. <CIT> relates to a server of a check issuer for use in a proximity payment system involving mobile phones.

It is desirable to provide a solution that allows mobile devices to be used cooperative with other devices where the mobile device is located.

Mobile devices (e.g. smart phones) allow users to access data content and services from anywhere in the world. This mobility allows users to perform operations such as streaming media or making purchases from home, work, or anywhere else without being tied to any particular location. This mobility poses several technical challenges because the operations performed on a mobile device are not linked with where the mobile device is located. In other words, there is not a correlation between operations being performed on a mobile device and the location of the mobile device. Another example of a technical challenge posed by the mobility of mobile devices is that they are typically not configured to communicate with other devices or systems where the mobile device is located. In existing systems, mobile devices operate independently from other devices. Allowing mobile devices to freely communicate with other devices poses a security risk for both the mobile device and other devices. For example, a bad actor may try to access one of the devices to perform malicious activities such as data exfiltration. In addition, allowing mobile devices and other devices to freely communicate reduces network bandwidth and processing performance of both the mobile device and other devices due to all the data traffic that is being generated and processed between devices. The reduction in network bandwidth creates a bottle neck that limits the performance of a device and its ability to communicate with other devices.

The system described in the present application provides a technical solution to the technical problems discussed above by enabling mobile devices to work. cooperatively with other devices to link operations performed on a mobile device with the location of the mobile device. The disclosed system provides several advantages which include <NUM>) enabling mobile devices to associate operations performed on the mobile device with the location of the mobile device, <NUM>) enabling mobile devices to work cooperatively with other devices where the mobile device is located to facilitate various operations, and <NUM>) providing the ability to validate operations performed on a mobile device at a particular location.

In one embodiment, the validation system enables a mobile device to associate and validate operations performed by the mobile device with the location of the mobile device. For example, the validation system is configured to determine whether the mobile device is currently located at a known registered location. This feature allows the validation system to enable services and communications between the mobile device and other devices at the registered location. This feature also improves the performance of the system by providing secure and controlled communications between the mobile device and other devices rather than allowing these devices to freely communicate.

Once an operation is performed on the mobile device, the validation system is configured to provide an encrypted barcode that can be used by other devices at the registered location to validate operations performed by the mobile device. The encrypted barcode is encrypted using a private key that is uniquely linked with a public key that is stored in a device at the registered location. When the encrypted barcode is presented to a validation device at the registered location, the validation device will validate the operation performed by the mobile device by decrypting the encrypted barcode using its public key. This feature allows operations performed by a mobile device to be validated by other devices using the public key stored at that location.

Certain embodiments of the present disclosure may include some, all, or none of these advantages. These advantages and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

The system described in the present application provides a technical solution to the technical problems discussed above by enabling mobile devices to work cooperatively with other devices to link operations performed on a mobile device with the location of the mobile device. The disclosed system provides several advantages which include <NUM>) enabling mobile devices to associate operations performed on the mobile device with the location of the mobile device, <NUM>) enabling mobile devices to work cooperatively with other devices where the mobile device is located to facilitate various operations, and <NUM>) providing the ability to validate operations performed on a mobile device at a particular location.

<FIG> and <FIG> are examples of a validation system and process, respectively, for facilitating and validating a mobile device process. <FIG> is an example of a screenshot from a mobile application on a mobile device performing an operation. <FIG> and <FIG> are examples of a network device and a validation terminal, respectively, configured to implement the validation process for a mobile device operation.

<FIG> is a schematic diagram of an embodiment of a validation system <NUM> for a mobile device process. Examples of mobile devices <NUM> include, but are not limited to, smart phones, tablets, or any other suitable type of network enabled device. Examples of mobile device processes include, but are not limited to, accessing data, streaming media, playing games, making a transaction, or any other type operation that can be performed on a mobile device <NUM>. For instance, a mobile device self-checkout process is an operation that allows a customer to purchase products using their mobile device <NUM> within a registered location <NUM> (e.g. a store). During this process the customer scans products they would like purchase using the camera on their mobile device <NUM> to add the products <NUM> to a digital cart <NUM>. Once the customer has finished scanning products <NUM>, the customer uses their mobile device <NUM> to complete the transaction without using a traditional point-of-sale terminal (e.g. a cash register).

The validation system <NUM> disclosed herein is configured to use interprocess communication between a cloud server <NUM> and a validation terminal <NUM> to facilitate and validate such a mobile device operation. The validation system <NUM> comprises a cloud server <NUM> in signal communication with one or more validation terminals <NUM> and one or more mobile devices <NUM>. The cloud server <NUM>, the validation terminal <NUM>, and the mobile device <NUM> may be in signal communication with each other using any suitable type of network or network connection. For example, the network may be any suitable type of wireless and/or wired network including, but not limited to, all or a portion of the Internet, an Intranet, a private network, a public network, a peer-to-peer network, the public switched telephone network, a cellular network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), and a satellite network. The network may be configured to support any suitable type of communication protocol as would be appreciated by one of ordinary skill in the art upon viewing this disclosure.

The cloud server <NUM> may be any suitable type of server or other network device as would be appreciated by one of ordinary skill in the art. The cloud server <NUM> may be formed by one or more physical devices configured to provide services and resources (e.g. data and/or hardware resources) for mobile devices <NUM> and validation terminals <NUM>. The cloud server <NUM> is generally configured to communicate with the mobile device <NUM> facilitate a mobile device operation. For example, the cloud server <NUM> may be configured to communicate with a mobile application <NUM> running on the mobile device <NUM> to add products <NUM> to a digital cart <NUM> and to process a transaction for the products in the digital cart <NUM>. Once the transaction is completed, the cloud server <NUM> is configured to send an encrypted barcode <NUM> to the mobile device <NUM> that can be used to validate the transaction. An example of the cloud server <NUM> in operation is described in <FIG>.

The validation terminal <NUM> is generally configured to process encrypted barcodes <NUM> provided by a mobile device <NUM> and to validate a transaction made by the mobile device <NUM> using the self-checkout process. The validation terminal <NUM> is configured to determine whether the customer has successfully completed their purchase before leaving registered location <NUM>. For example, the verification terminal <NUM> may visually and/or audibly indicate that a customer transaction has been validated. An example of the validation terminal <NUM> in operation is described in <FIG>.

The validation terminal <NUM> is located at or within a registered location <NUM>. For example, the verification terminal <NUM> may be located on a counter near a cashier or may be in a standalone kiosk near the door of a store. The registered location <NUM> is a location or business that sells one or more products <NUM>. Examples of a registered location <NUM> include, but are not limited to, stores, buildings, shopping centers, malls, or any other suitable type of location. In addition, each registered location <NUM> is also uniquely linked with a store identifier <NUM>. A registered location <NUM> may be linked with any suitable type of identifier as would be appreciated by one of ordinary skill in the art. For example, a store identifier <NUM> may comprise an alphanumeric string. Registered locations <NUM> are identifiable using geofences <NUM>. A geofence <NUM> is a virtual geographical boundary that is defined using Global Positioning System (GPS) or Radio Frequency Identification (RFID) technology. Using geofences <NUM>, a validation terminal <NUM> and the registered location <NUM> where it resides can be uniquely linked with a physical address or GPS coordinates. In some embodiments, the cloud server <NUM> uses geofences <NUM> to determine whether a mobile device <NUM> has entered or exited a registered location <NUM> based on the location information of the mobile device <NUM>. In this example, the cloud server <NUM> may be configured to use this process to enable or disable the mobile device's <NUM> ability to perform a mobile device self-checkout process.

<FIG> is a protocol diagram of an embodiment of a validation method <NUM> for a mobile device process. Method <NUM> uses interprocess communications between the cloud server <NUM> and the validation terminal <NUM> to facilitate and validate a mobile device operation. <FIG> illustrates a non-limiting example of the validation method <NUM> for facilitating and validating a transaction that is t made using a mobile device <NUM>.

At step <NUM>, the mobile device <NUM> sends an access request <NUM> comprising location information for the mobile device <NUM> to the cloud server <NUM>. For example, a customer may use a mobile application <NUM> running on the mobile device <NUM> to communicate with the cloud server <NUM>. In this example, the mobile device <NUM> sends the access request <NUM> to request permission to purchase products <NUM> using a mobile device self-checkout process. The location information may comprise GPS coordinates, a physical address, or any other suitable type of information that identifies the location of the mobile device <NUM>. For example, the mobile device <NUM> may comprise a GPS sensor that is configured to provide GPS coordinates which may be used as the location information for the mobile device <NUM>. In some embodiments, the access request <NUM> may comprise additional information such as customer information (e.g. a loyalty identifier) or credentials (e.g. a Personal Identification Number (PIN)). The access request <NUM> may be sent using any suitable type of messaging protocol as would be appreciated by one of ordinary skill in the art.

At step <NUM>, the cloud server <NUM> determines whether the mobile device <NUM> is at a registered location <NUM> based on the received location information for mobile device <NUM>. For example, the cloud server <NUM> determines whether the received location information (e.g. GPS coordinates) for the mobile device <NUM> matches any stored location information <NUM> linked with a registered location <NUM>. In this example, the cloud server <NUM> determines that the mobile device <NUM> is at a registered location <NUM> when the location information for the mobile device <NUM> matches stored location information <NUM> linked with a registered location <NUM>. In other words, the cloud server <NUM> determines that the mobile device <NUM> is within a store when their location information matches each other. The cloud server <NUM> proceeds to step <NUM> in response to determining that the mobile device <NUM> is at a registered location <NUM>.

The cloud server <NUM> determines that the mobile device <NUM> is not at a registered location <NUM> when the location information for the mobile device <NUM> does not match any stored location information <NUM> linked with registered locations <NUM>. In this case, the cloud server <NUM> determines that mobile device <NUM> is not at a store when the location of the mobile device <NUM> does not correspond with the location of any stores. This process allows the cloud server <NUM> distinguish between when the customer is physically at a store and when they are somewhere else, for example at home. The cloud server <NUM> continues to wait for an access request that comprises location information that indicates the mobile device <NUM> is at a registered location <NUM>.

In one embodiment, the cloud server <NUM> is configured to send location information <NUM> that identifies one or more registered locations <NUM> near the mobile device <NUM>. For example, the cloud server <NUM> may send addresses or GPS coordinates for other registered locations <NUM> that are near the mobile device <NUM>. This feature can be used to inform the customer about other locations where they can perform a mobile device self-checkout. For example, the mobile application <NUM> may use the received location information <NUM> about nearby registered locations <NUM> to annotate a graphical map to identify locations where mobile device self-checkout services are available.

At step <NUM>, the cloud server <NUM> sends instructions to the mobile device <NUM> for enabling a scan feature on the mobile device <NUM>. The cloud server <NUM> may send instructions or commands to the mobile device <NUM> that activates or enables a scan or camera feature on the mobile application <NUM> that is running on the mobile device <NUM>. For example, the mobile application <NUM> running on the mobile device <NUM> may be configured by default to disable a scan or camera feature on the mobile device <NUM> until the mobile device <NUM> receives instructions for activating this feature. Activating this scanning feature allows the mobile device <NUM> to scan products <NUM> to be added to a digital cart <NUM>. In some embodiments, step <NUM> may be optional and omitted. For example, the mobile application and mobile device <NUM> may be preconfigured with the scan feature already enabled.

At step <NUM>, the mobile device <NUM> scans a product <NUM> to determine product information for the product <NUM>. The mobile device <NUM> may scan barcodes (e.g. stock keeping unit (SKU) barcodes, universal product code (UPC) barcodes, and Quick Response (QR) codes), labels, or any portion of a product <NUM>. In one embodiment, the mobile device <NUM> uses a camera to scan or take a picture of a barcode on the product <NUM> to obtain product information for the product <NUM>. In another embodiment, the mobile device <NUM> may capture an image of the product <NUM> using a camera and may perform object recognition to identify the object and product information for the product <NUM>. In other embodiments, the mobile device <NUM> may use any other suitable technique as would be appreciated by one of ordinary skill in the art to identify a product <NUM> and its related product information.

At step <NUM>, the mobile device <NUM> sends the product information <NUM> for the scanned product <NUM> to the cloud server <NUM>. The product information <NUM> may comprise an image, a barcode, a product name, a product description, price information, or any other type of information for identifying a product <NUM>. The mobile device <NUM> may send to product information <NUM> to the cloud server <NUM> using any suitable type of messaging format or protocol.

At step <NUM>, the cloud server <NUM> determines whether the scanned product <NUM> is available at the registered location <NUM> where the mobile device <NUM> is located. The cloud server <NUM> identifies the scanned product <NUM> based on the received product information <NUM> and determines whether the product <NUM> is available at the registered location <NUM> based on inventory information <NUM> for the registered location <NUM>. The inventory information <NUM> comprises information about products <NUM> that are currently available or in stock at the registered location <NUM>. The cloud server <NUM> proceeds to step <NUM> in response to determining that the scanned product is available or in stock at the registered location <NUM>. Otherwise, the cloud server <NUM> continues to wait for additional product information <NUM> from the mobile device <NUM> in response to determining that the scanned product <NUM> is not available or in stock at the registered location <NUM>. In one embodiment, the cloud server <NUM> is configured to send location information <NUM> that identifies one or more registered locations <NUM> near the mobile device <NUM> where the scanned product is available.

At step <NUM>, the cloud server <NUM> adds the scanned product <NUM> to a digital cart <NUM>. The digital cart <NUM> is a virtual shopping cart that is associated with a particular user. The digital cart <NUM> displays information about products <NUM> in the virtual shopping cart. For example, the cloud server <NUM> may generate an entry in the digital cart <NUM> that identifies the scanned product, a quantity for the scanned product, a price for the scanned product, and/or any other suitable type of information for the scanned product. The digital cart <NUM> is accessible (i.e. viewable) from the mobile application <NUM> running on the mobile device <NUM>. The digital cart <NUM> may be updated in about real time as the mobile device <NUM> scans products <NUM>. In one embodiment, the cloud server <NUM> may also send information about the digital cart <NUM> to a cashier's mobile device to allow a cashier to monitor the activity of a mobile device <NUM> and the products <NUM> that are in a mobile device's <NUM> digital cart <NUM>. For example, the cloud server <NUM> may send product information about the products <NUM> in the digital cart <NUM> as they are added to the digital cart <NUM>.

In one embodiment, the cloud server <NUM> determines whether the scanned product <NUM> qualifies for any promotions or rewards. Examples of promotions and rewards include, but are not limited to, discounts, coupons, reward points, rebates, or any other type of special offer. The cloud server <NUM> may be configured to automatically apply any promotions or reward to the digital cart <NUM> in response to identifying the qualifying scanned product <NUM>.

Steps <NUM>-<NUM> may be repeated for any number of products <NUM> that the mobile device <NUM> scans to place into the digital cart <NUM>.

At step <NUM>, the mobile device <NUM> sends a transaction request <NUM> for the products <NUM> in the digital cart <NUM>. For example, the mobile device <NUM> may send payment information for facilitating a transaction for the products <NUM> in the digital cart <NUM>. The mobile device <NUM> may send credit card information, account information, online payment service information, or any other suitable type of financial information for making an electronic transaction.

At step <NUM>, the cloud server <NUM> processes the requested transaction based on the payment information provided in the transaction request <NUM>. For example, the cloud server <NUM> may use the received payment information to facilitate an electronic purchase of the products <NUM> in the digital cart <NUM>. In one embodiment, the cloud server <NUM> is configured to send transaction information to a cashier upon processing the transaction request <NUM>. For example, the cloud server <NUM> may send transaction information to a cashier's mobile device to allow a cashier to monitor the transactions being made in the registered location <NUM> using the mobile self-checkout process.

At step <NUM>, the cloud server <NUM> generates an encrypted barcode <NUM> using a private key <NUM>. The cloud server <NUM> may generate a barcode based on customer information <NUM> (e.g. a loyalty identifier), a store identifier <NUM> for the registered location <NUM>, transaction information <NUM> (e.g. product information or purchase amount), a timestamp (e.g. a date and time) for when the transaction was made, or any other suitable type of information. The generated barcode is configured to embed or encode the information that is used to generate the barcode. This information may be recovered later by other devices (e.g. a validation terminal <NUM>). Examples of barcodes include, but are not limited to, one-dimensional barcodes (e.g. SKU barcodes and UPC barcodes) and two-dimensional barcodes (e.g. matrix barcodes and QR codes). The cloud server <NUM> may employ any suitable technique for generating a barcode. The cloud server <NUM> then identifies the private key <NUM> linked with the registered location <NUM> where the mobile device <NUM> is located and encrypts the generated barcode using the identified private key <NUM> to generate an encrypted barcode <NUM>. The cloud server <NUM> may employ any suitable technique to encrypt the barcode using the private key <NUM>. The barcode is encrypted such that the encrypted barcode <NUM> can only be decrypted using a corresponding public key <NUM> that is stored in a validation terminal <NUM> at the registered location <NUM>.

At step <NUM>, the cloud server <NUM> sends the encrypted barcode <NUM> to the mobile device <NUM>. Once the mobile device <NUM> receives the encrypted barcode <NUM>, the mobile device <NUM> may present the encrypted barcode <NUM> and any other information to the customer. In one embodiment, the cloud server <NUM> may also send dynamic content <NUM> with the encrypted barcode <NUM> to the mobile device <NUM>. For example, the cloud server <NUM> may send content (e.g. an image) that is animated or moves when presented on the display of the mobile device <NUM>. For instance, the dynamic content <NUM> may be animation, video, or special effect that plays on the mobile device <NUM>. Examples of dynamic content <NUM> include, but are not limited to, GIF animations, Adobe Flash objects, JavaScript objects, HTML objects, or any other suitable type of animated content. In this example, the dynamic content <NUM> may be used by the validation terminal <NUM> to distinguish between current information and a screenshot of previous information. This security feature prevents someone from making a valid transaction to obtain an encrypted barcode <NUM> and then trying to reuse the same encrypted barcode <NUM> again. Screenshots of previous information will only capture an instance in time and will not illustrate any active animations or movements being performed by the dynamic content <NUM>. The validation terminal <NUM> may be configured to detect whether any dynamic content <NUM> is present and animated to determine whether an encrypted barcode <NUM> is current and valid.

Referring to <FIG> as an example, a screenshot <NUM> from a mobile application <NUM> operating on the mobile device <NUM> is shown. In <FIG>, the mobile application <NUM> presents an encrypted barcode <NUM>, a timestamp <NUM>, a store identifier <NUM>, and transaction information <NUM>. In this example, the encrypted barcode <NUM> is a two-dimensional barcode (e.g. a QR code). The timestamp <NUM> may comprise the date and time when a transaction was processed or completed. The store identifier <NUM> identifies the registered location <NUM> where the transaction was made. The transaction information <NUM> comprises the total number of products <NUM> that were purchased and the total cost for the products <NUM>. In other examples, the transaction information <NUM> may comprise any other suitable information. For example, the transaction information <NUM> may comprise an itemized list of products <NUM>, product information <NUM>, tax information, or any other suitable type of information.

Returning to <FIG>, at step <NUM>, the mobile device <NUM> presents the encrypted barcode <NUM> to the validation terminal <NUM>. For example, the customer may place the display of the mobile device <NUM><NUM> adjacent to a barcode reader of the validation terminal <NUM> to present the encrypted barcode <NUM> to the validation terminal <NUM>.

At step <NUM>, the validation terminal <NUM> reads and authenticates the encrypted barcode <NUM> using a public key <NUM>. The validation terminal <NUM> is preconfigured to store a public key <NUM> that is paired with the private key <NUM> stored in the cloud server <NUM>. The public key <NUM> and the private key <NUM> are uniquely linked with the registered location <NUM> where the validation terminal <NUM> is located. The validation terminal <NUM> decrypts the encrypted barcode <NUM> using the locally stored public key <NUM> to retrieve the generated barcode. The validation terminal <NUM> may employ any suitable technique for decrypting the encrypted barcode <NUM> using the public key <NUM>.

At step <NUM>, the validation terminal <NUM> determines whether the barcode is valid. In one embodiment, the validation terminal <NUM> processes the barcode to retrieve a timestamp <NUM> (e.g. a date and time) for when the transaction was made. The validation terminal <NUM> determines whether the timestamp <NUM> is within a predetermined time window from the current time. For example, the validation terminal <NUM> may determine whether the timestamp <NUM> is for a time that is within the past fifteen minutes. In other examples, the predetermined time window may be any other suitable amount of time. In this example, the validation terminal <NUM> determines that the barcode is valid when the timestamp <NUM> is within the predetermined time window. The validation terminal <NUM> determines that the barcode is invalid when the timestamp <NUM> is outside of the predetermined time window. This security feature prevents customers from reusing barcodes from previous transactions.

In one embodiment, the validation terminal <NUM> determines whether the barcode or information presented with the barcode contains dynamic content <NUM>. For example, the validation terminal <NUM> determines whether any dynamic content <NUM> on the display of the mobile device <NUM> is active (e.g. moving). In this example, the validation terminal <NUM> determines that the barcode is valid when the barcode is presented with dynamic content <NUM>. The validation terminal <NUM> determines that the barcode is invalid when the barcode is not presented with dynamic content <NUM>. This security feature prevents customers from reusing barcodes from previous transactions.

In other embodiments, the validation terminal <NUM> may use any other criteria or combination of criteria for determining whether the barcode is valid. The validation terminal <NUM> proceeds to step <NUM> in response to determining that the barcode is valid. Otherwise, the validation terminal <NUM> proceeds to step <NUM> in response to determining that the barcode is not valid.

At step <NUM>, the validation terminal <NUM> indicates that the transaction is invalid and terminates method <NUM>. For example, the validation terminal <NUM> may activate (i.e. turn on) one or more red light emitting diodes (LEDs) to indicate that the transaction is invalid. As another example, the validation terminal <NUM> may present a visual indicator on a liquid crystal display (LCD) that indicates the transaction is invalid. In other examples, the validation terminal <NUM> may employ any other suitable technique for visually indicating that the transaction is invalid. This process allows a cashier or worker to visually determine that a transaction is invalid and may require further attention. In one embodiment, the validation terminal <NUM> may send an alert <NUM> comprising information about the invalid transaction. The alert <NUM> may be an email, a text message (e.g. a short message service (SMS) message), an application pop-up alert, or any other suitable type of message notification.

Returning to step <NUM>, the validation engine <NUM> proceeds to step <NUM> in response to determining that the barcode is valid. At step <NUM>, the validation terminal <NUM> indicates that the transaction is valid. For example, the validation terminal <NUM> may activate (i.e. turn on) one or more green LEDs to indicate that the transaction is valid. As another example, the validation terminal <NUM> may present a visual indicator on a LCD that indicates the transaction is valid. In other examples, the validation terminal <NUM> may employ any other suitable technique for visually indicating that the transaction is valid. This process allows a cashier or worker to visually confirm that a transaction was valid and does not require any assistance.

At step <NUM>, the validation terminal <NUM> sends confirmation information <NUM> to the cloud server <NUM>. The confirmation information <NUM> may comprise information indicating that the transaction has been validated and is complete.

At step <NUM>, the cloud server <NUM> sends confirmation information <NUM> to the mobile device <NUM>. For example, the cloud server <NUM> may forward the confirmation information <NUM> to the mobile device <NUM> to be displayed on the mobile application <NUM> running on the mobile device <NUM>.

<FIG> is a schematic diagram of an embodiment of a network device <NUM> (e.g. cloud server <NUM>) configured to implement the validation method <NUM> for a mobile device process. The network node <NUM> comprises a processor <NUM>, a memory <NUM>, and a network interface <NUM>. The network device <NUM> may be configured as shown or in any other suitable configuration.

The processor <NUM> comprises one or more processors operably coupled to the memory <NUM>. The processor <NUM> is any electronic circuitry including, but not limited to, state machines, one or more central processing unit (CPU) chips, logic units, cores (e.g. a multi-core processor), field-programmable gate array (FPGAs), application specific integrated circuits (ASICs), or digital signal processors (DSPs). The processor <NUM> may be a programmable logic device, a microcontroller, a microprocessor, or any suitable combination of the preceding. The processor <NUM> is communicatively coupled to and in signal communication with the memory <NUM>. The one or more processors are configured to process data and may be implemented in hardware or software. For example, the processor <NUM> may be <NUM>-bit, <NUM>-bit, <NUM>-bit, <NUM>-bit or of any other suitable architecture. The processor <NUM> may include an arithmetic logic unit (ALU) for performing arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that fetches instructions from memory and executes them by directing the coordinated operations of the ALU, registers and other components.

The one or more processors are configured to implement various instructions. For example, the one or more processors are configured to execute instructions to implement the authentication engine <NUM>. In this way, processor <NUM> may be a special purpose computer designed to implement function disclosed herein. In an embodiment, the authentication engine <NUM> is implemented using logic units, FPGAs, ASICs, DSPs, or any other suitable hardware. The authentication engine <NUM> is configured to execute the operation performed by the cloud server <NUM> described in <FIG> and <FIG>.

The memory <NUM> comprises one or more disks, tape drives, or solid-state drives, and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory <NUM> may be volatile or non-volatile and may comprise read-only memory (ROM), random-access memory (RAM), ternary content addressable memory (TCAM), dynamic random-access memory (DRAM), and static random-access memory (SRAM). The memory <NUM> is operable to store authentication instructions <NUM>, location information <NUM>, store identifiers <NUM>, private keys <NUM>, customer information <NUM>, inventory information <NUM>, transaction information <NUM>, and/or any other data or instructions. The authentication instructions <NUM> may comprise any suitable set of instructions, logic, rules, or code operable to execute the authentication engine <NUM>.

The memory <NUM> is configured to store location information <NUM> for a set of registered locations <NUM>. Examples of location information include, but are not limited to, GPS coordinates, physical addresses, or any other suitable type of descriptor that uniquely identifies the location of the registered location <NUM>.

Store identifiers <NUM> are used to uniquely identify a registered location <NUM> (e.g. a store). In one embodiment, a store identifier <NUM> may comprise an alphanumeric string. In other embodiments, a store identifier <NUM> may be any other suitable type of identifier as would be appreciated by one of ordinary skill in the art.

Private keys <NUM> are uniquely linked with registered locations <NUM>. Each private key <NUM> is paired with a public key <NUM> that is stored locally in a validation terminal <NUM> located at a registered location <NUM>.

Customer information <NUM> may comprise any suitable type of information linked with customers. Examples of customer information <NUM> include, but are not limited to, personal information, account information, loyalty identifiers, demographic information, financial information, transaction history information, or any other suitable type of information.

Inventory information <NUM> comprises information about products <NUM> that are currently available or in stock at the registered locations <NUM>. For example, the inventory information <NUM> may identify products <NUM> and the quantity of products <NUM> that are in stock at a particular registered location <NUM>. The inventory information <NUM> may be updated in about real time as transactions are made by customers. In some embodiments, the inventory information <NUM> may be obtained from one or more online databases.

The network interface <NUM> is configured to enable wired and/or wireless communications. The network interface <NUM> is configured to communicate data between the network device <NUM> and other network devices, systems, or domain. For example, the network interface <NUM> may comprise a WIFI interface, a LAN interface, a WAN interface, a modem, a switch, or a router. The processor <NUM> is configured to send and receive data using the network interface <NUM>. The network interface <NUM> may be configured to use any suitable type of communication protocol as would be appreciated by one of ordinary skill in the art.

<FIG> is an exploded view of an embodiment of a validation terminal <NUM> configured to implement the validation method <NUM> for a mobile device process. In one embodiment, the validation terminal <NUM> comprises a scanning window <NUM>, a housing <NUM>, a processor <NUM>, a memory <NUM> configured to store a public key <NUM>, a network interface <NUM>, a barcode reader <NUM>, lights <NUM>, and a base plate <NUM>. The validation terminal <NUM> may be configured as shown or in any other suitable configuration. In some embodiments, the validation terminal <NUM> omit one or more components and/or may include one or more additional components. For example, the validation terminal <NUM> may further comprise a liquid crystal display (LCD) for providing visual information to a user.

The scanning window <NUM> is configured to allow the barcode reader <NUM> to scan barcodes that are positioned adjacent to the validation terminal <NUM>. For example, a user may position a barcode in front of the scanning window <NUM> to be detected and read by the barcode reader <NUM>. The scanning window <NUM> may be formed of any suitable type of glass or plastic material.

The housing <NUM> is configured to at least partially enclose the processor <NUM>, the memory <NUM>, the network interface <NUM>, the barcode reader <NUM>, and the lights <NUM>. In one embodiment, the housing <NUM> is formed from a molded translucent plastic body. In this example, the lights <NUM> can be configured to emit light through the housing <NUM> which causes the housing to glow in the emitted light color. In other embodiments, the housing <NUM> may be formed of metals, wood, or any other suitable type of material.

The processor <NUM>, the memory <NUM>, and the network interface <NUM> may be configured similar to the processor <NUM>, the memory <NUM>, and the network interface <NUM> described in <FIG>, respectively. The processor <NUM> is configured to execute instructions to implement a validation engine <NUM>. In this way, processor <NUM> may be a special purpose computer designed to implement function disclosed herein. In an embodiment, the validation engine <NUM> is implemented using logic units, FPGAs, ASICs, DSPs, or any other suitable hardware. The validation engine <NUM> is configured to execute the operations performed by the validation terminal <NUM> described in <FIG> and <FIG>. The memory <NUM> is configured to store a public key <NUM> that is paired with a private key <NUM> that is stored in the cloud server <NUM>. The public key <NUM> and the private key <NUM> are uniquely linked with the registered location <NUM> where the validation terminal <NUM> is located.

The barcode reader <NUM> is in signal communication with the processor <NUM> and is configured to read barcodes (e.g. encrypted barcodes <NUM>). The barcode reader <NUM> may be any suitable type of barcode reader as would be appreciated by one of ordinary skill in the art.

The lights <NUM> may be any suitable type of lights as would be appreciated by one of ordinary skill in the art. In one embodiments, the lights <NUM> comprise LED lights.

The base plate <NUM> is generally configured to integrate the housing <NUM> with other structures. For example, the base plate <NUM> may be configured to integrate the housing <NUM> with a countertop. In other examples, the base plate <NUM> may be configured to integrate the housing <NUM> with a standalone kiosk or any other suitable type of structure. In one embodiment, the base plate <NUM> is formed from aluminum. In other embodiments, the base plate <NUM> may be formed of metals, wood, plastic, or any other suitable type of material.

While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

Claim 1:
A validation system, comprising;
a server comprising:
a first memory operable to store:
location information for a set of registered locations;
a set of store identifiers, wherein each store identifier is linked with a registered location from the set of registered locations; and
a set of private keys, wherein each private key is linked with a registered location from the set of registered locations; and
an authentication engine implemented by a first processor operably coupled to the first memory, wherein the authentication engine is configured to:
receive location information for a mobile device;
determine the received location information for the mobile device matches location information linked with a registered location from the set of registered locations;
identify a private key linked with the registered location;
receive a transaction request from the mobile device for products in a digital cart;
process a transaction for the products in the digital cart in response to receiving the transaction request;
generate a barcode based on the store identifier linked with the registered location and transaction information from processing the transaction for the products in the digital cart;
encrypt the barcode using the private key linked with the registered location; and
send the encrypted barcode to the mobile device;
a validation terminal located at the registered location and in signal communication with the server, comprising;
a barcode reader;
a second memory operable to store a public key, wherein the public key is paired with the private key; and
a validation engine implemented by a second processor operably coupled to the barcode reader and the second memory, wherein the validation engine is configured to:
detect the encrypted barcode was scanned by the barcode reader;
decrypt the encrypted barcode using the stored public key; and
indicate the transaction is valid in response to decrypting the encrypted barcode using the public key.