Secure QR code-based data transmission

Abstract

The invention relates to data transmission based on secure QR codes. In accordance with an aspect of an embodiment of the present disclosure, a method may include receiving a quick response (QR) code from a computing device, the QR code including a first entity identifier; and analyzing the QR code to determine a request for initiating a data transmission between the first entity and the second entity associated with the first entity identifier, and to determine one or more features associated with the data transmission. The method may also include identifying a first QR code processing flow to follow from the plurality of QR code processing flows based on the one or more features to process the data transmission, and verifying a first entity in the transaction based on a first entity identifier of the QR code and based on the first QR code processing flow. The method may also include processing data transmission between the second entity and the first entity based on the first QR code processing flow.

Description

[0001] Divisional Application Instructions

[0002] This application is a divisional application of the invention patent application with the application date of December 27, 2018, application number 201880090522.1, and name “Data transmission based on secure QR code”.

[0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This application claims priority to and the benefit of U.S. Utility Patent No. 15 / 859,045, filed on December 29, 2017, entitled “Secure QR Code-Based Data Transmission,” the entire contents of which are incorporated herein. Technical Field

[0005] Embodiments of the present disclosure relate to Quick Response (QR) codes and their use in various secure data transmissions. Background Art

[0006] Mobile devices have become common devices that individuals carry with them. Many mobile devices have cameras or other optical scanning devices. Due to the popularity of such mobile devices, some entities have begun using QR codes to transmit information. A QR code may include a matrix barcode as a machine-readable optical label that carries information in the label. The information may be encrypted or otherwise protected. Summary of the invention

[0007] According to one aspect of the present disclosure, a method is provided, comprising: receiving a quick response (QR) code from a computing device, wherein the QR code includes a first entity identifier that identifies a first entity, and wherein the QR code corresponds to a request for initiating an electronic transaction between the first entity and a second entity; determining a first set of characteristics associated with the electronic transaction and a second set of characteristics corresponding to the computing device, wherein the second set of characteristics includes a geographic location of the computing device; identifying a first QR code processing flow for the electronic transaction from a plurality of QR code processing flows based on the first set of characteristics and the second set of characteristics; verifying the QR code; and in response to verifying the QR code, processing the electronic transaction between the first entity and the second entity based on the first QR code processing flow.

[0008] According to one aspect of the present disclosure, a non-transitory computer-readable medium storing instructions is provided, wherein the instructions, in response to being executed, cause a machine to perform one or more operations or control the execution of one or more operations, the operations comprising: receiving a quick response (QR) code from a computing device, wherein the QR code includes a request for initiating an electronic transaction between a first entity and a second entity, and wherein the QR code includes a first entity identifier corresponding to the first entity; determining a first set of characteristics associated with the electronic transaction; determining a second set of characteristics corresponding to the computing device, wherein the second set of characteristics includes a geographic location of the computing device; based on the first set of characteristics and the second set of characteristics, identifying a first QR code processing flow for the electronic transaction from a plurality of QR code processing flows; verifying whether the QR code is valid; and in response to verifying that the QR code is valid, processing the electronic transaction between the first entity and the second entity according to the first QR code processing flow.

[0009] According to one aspect of the present disclosure, a system is provided, comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions, wherein the instructions, in response to being executed by the one or more processors, cause the system to perform one or more operations or control the execution of one or more operations, the operations comprising: receiving a quick response (QR) code from a user computing device, wherein the QR code comprises a first entity identifier of a first entity, and wherein the QR code received from the user computing device is generated by the user computing device; analyzing the QR code to determine that the QR code corresponds to a request for initiating an electronic transaction between the first entity and a second entity; determining a first set of features associated with the electronic transaction; determining a second set of features corresponding to the user computing device, wherein the second set of features comprises a geographic location of the user computing device; identifying a first QR code processing flow for the electronic transaction from a plurality of QR code processing flows based on the first set of features and the second set of features; and processing the electronic transaction between the first entity and the second entity according to the first QR code processing flow in response to verifying that the QR code is valid. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Example embodiments are described and illustrated with additional specificity and detail through the use of the accompanying drawings, in which:

[0011] Figure 1 is a diagram illustrating an example system that can implement QR code-based data transmission;

[0012] Figure 2 is a flow chart illustrating an example method of QR code based data transmission;

[0013] Figure 3 is a flow chart illustrating another example method of QR code-based data transmission;

[0014] Figure 4 is a flow chart illustrating another example method of QR code-based data transmission;

[0015] Figure 5 is a flow chart illustrating another example method of QR code-based data transmission;

[0016] Figure 6 is a flow chart illustrating another example method of QR code-based data transmission;

[0017] Figure 7 is a flow chart illustrating another example method of QR code-based data transmission;

[0018] Figure 8 An example computing system is shown that may be used in a system configured to implement QR code-based data transfer. DETAILED DESCRIPTION

[0019] There are multiple potential ways to handle data transmission using QR codes. However, in some cases, different processes for handling such data transmission may be undesirable, and in other cases may not even work at all. In addition, the infrastructure that can be used to handle such data transmission is usually only capable of handling a single process of data transmission using QR codes. In addition, entities that expect to participate in QR code-based data transmission may not know which processes are advantageous in which situations, and may ultimately utilize multiple different infrastructure sets to handle different processes. A system with multiple potential processes that facilitate QR code-based data transmission may cause the following problem, that is, one party may not know which process to use, and even if a process is selected, the system needs to distinguish the processes and correctly handle the transmission. In addition, the security of such data transmission may be an important consideration (for example, if the data transmission is associated with a financial transaction).

[0020] The present disclosure can provide a system that solves these problems by assisting a first entity (e.g., a merchant) in determining which of a plurality of QR code-based data transmission processes is advantageous or appropriate for the first entity (e.g., a merchant). In addition, after selecting a process through which the first entity (e.g., a merchant) processes the QR code-based data transmission, the present disclosure solves the problem of distinguishing which process is for which entity, so that a single system can be configured to handle a plurality of different QR code-based processes from a plurality of different entities.

[0021] One or more embodiments of the present disclosure relate to an infrastructure that can be used to provide multiple potential options for using QR codes in data transmission. For example, a system can be provided through which merchants can register with the system and select one of multiple potential options during registration for processing data transmission (e.g., transactions) using QR codes. Before presenting potential options to merchants, the system can limit which options are presented to merchants. For example, based on information provided by a first entity in a registration process, the system can omit certain processes based on whether the first entity is a mobile merchant (e.g., a food truck) or whether the first entity operates in a physical store. As another example, the system can omit certain processes based on the geographic area or market where the first entity operates. In some embodiments, the system can present a set of queries to a first party (e.g., a merchant) to facilitate determining which processes are to be presented to the first party as options, such as the address of the first party, the market where the first party operates (e.g., a clothing retailer vs. a jewelry retailer), the actual location of the first party, multiple branches of the first party, the risk tolerance of the first party, etc. In some embodiments, the system can provide recommendations for specific processes to the first party for selection.

[0022] In some embodiments, various other factors may also be considered when providing a recommendation (or when selecting a process by the first entity), such as whether the QR code is unique for each data transfer (dynamic QR code) or is specific to an entity but used for multiple data transfers (static QR code), which may affect the amount of network traffic utilized for each data transfer. Another factor may include whether the QR code is generated by a first entity (e.g., a merchant) and scanned by a second entity (e.g., a consumer), or generated by a second entity and scanned by a first entity, which may affect the security of the transaction and whether certain device capabilities are required by certain parties. Another factor (e.g., when the data transfer involves a transaction) may include whether the QR code includes an amount associated with the transaction or whether one of the two parties to the transaction provides a payment amount for the transaction during the transaction, which may affect the security of the transaction and / or the amount of network traffic utilized. Other factors related to the entity (e.g., a merchant) or the region of the world in which the entity operates may affect which process is selected. For example, one or more options may be removed before presenting potential QR code processes to the first entity, and the first entity selects from the potential QR code processes based on the amount of network usage utilized during the data transfer, the security of the data transfer, the mobility of the merchant, etc. Another factor may include whether the first entity (e.g., merchant) has access to specialized hardware and / or software for generating, scanning, and / or displaying certain types or security features of the QR code. The present disclosure may additionally relate to using such a process to process transactions using QR codes.

[0023] Various embodiments of the present disclosure can improve the operation of a computer, and can improve the related technologies of computer security and network communication. For example, the present disclosure improves the operation of a computer by providing a single system that can facilitate multiple processes of data transmission based on QR codes, rather than using multiple different computing devices. As another example, because the specific process of data transmission processing using QR codes can be customized to a specific risk profile suitable for a region or market, computer security and network communication are improved. In addition, the process can be selected to adapt to the network bandwidth infrastructure in which the system can run. For example, the system can intelligently limit which processes the first entity can select based on the network bandwidth infrastructure of the area in which the first entity (e.g., a merchant) operates. In this way, instead of forcing the infrastructure to bear the load of increased network traffic, a process with appropriate traffic can be selected for the area. In addition, the type or style of the QR code can be dynamically generated based on the network infrastructure and / or performance. In these embodiments, the present disclosure can avoid the first entity from applying a wide or heavy load on an already overloaded network system. On the contrary, the present disclosure can intelligently and securely provide more customized network load amounts to promote secure and fast data transmission.

[0024] Various embodiments of the present disclosure may additionally operate in a manner that causes those components to operate in a non-traditional manner even if implemented using typical components. For example, various processes may utilize the generation of QR codes and responses to QR code scans to operate in a manner different from that observed in traditional QR code use.

[0025] One or more example embodiments are described with reference to the accompanying drawings.

[0026] Figure 1 1 is a diagram showing an example system 100 that can implement QR code-based data transmission according to one or more embodiments of the present disclosure. As described below, the system 100 may include a second entity device 110, a support server 120, an example first entity device 130 and another example first entity device 140, and a network 150. The first entity and the second entity may participate in a QR code-based data transmission supported by the support server 120 using the second entity device 110 and the first entity device 130 / 140. One of the second entity device 110 or the first entity device 130 / 140 may generate a QR code, and the other may scan the QR code to facilitate data transmission.

[0027] In some embodiments, data transmission may include a transaction between a consumer and a merchant. For example, the consumer and / or merchant may transmit data associated with the transaction to verify the transaction party, transaction amount, etc. by using a QR code.

[0028] In some embodiments, before participating in a QR-based data transfer, a first entity (such as a merchant using one or both of the first entity devices 130 or 140) may interact with the support server 120 to register to perform a QR code-based data transfer. In the registration, the support server 120 may identify information about the first entity and present one or more potential processes for processing the QR code-based data transfer to the first entity through the first entity device 130 or 140. For example, in some embodiments, when registering to obtain information, the support server 120 (or an application running on the first entity device 130 / 140) may ask the first entity a series of questions. Such information may include the name of the first entity, the address of the first entity (including the addresses of multiple branches / locations of the first entity), the size of the first entity (e.g., the number of employees, the amount of revenue, etc.), the market in which the first entity operates, the computing infrastructure of the first entity, the network connection of the first entity, the risk tolerance of the first entity, the preferences of the first entity, etc. In response to this information, the support server 120 may provide a recommendation or may provide a plurality of potential data transfer processes from which the first entity may select for use when processing a QR code-based transmission. Figures 2 to 7 An example of this process is depicted in .

[0029] In some embodiments, to determine the network infrastructure of the first entity, the support server 120 can determine properties of communications with the first entity (e.g., by pinging or other network test communications). In these and other embodiments, the network infrastructure can be determined in real time when the first entity registers with the support server.

[0030] In some embodiments, the support server 120 can determine the properties of the network infrastructure when data is transmitted (e.g., a transaction). Based on low network performance or low network availability, the support server 120 can promote the use of uncomplicated QR codes that can utilize a smaller amount of network resources during data transmission. In some embodiments, uncomplicated QR codes can be different from QR codes that are commonly used in data transmission in typical (e.g., high network availability) situations. Additionally or alternatively, one or more security features (e.g., pairing operations or handshakes between electronic devices) can be omitted to preserve network bandwidth.

[0031] In some embodiments, various processes may be differentiated by various factors, such as whether the first entity or the second entity generated the QR code, whether the QR code is static or dynamic, and / or whether the amount was entered by the second entity or the first entity. Additionally, processes may be differentiated by the risk profile of the industry in which the first entity operates (e.g., a grocer versus a jewelry store), the risk profile of the geographic location in which the first entity operates (e.g., a low crime country or region versus a high crime country or region), the network infrastructure of the geographic location in which the first entity operates (e.g., whether Internet speeds above a threshold amount are typically available, or whether low-speed Internet is typically available). In some embodiments, these factors may contribute to the recommendations or lists of potential processes presented to the first entity for selection. For example, if the first entity operates in a country or region with limited network infrastructure, the support server 120 may present a limited set of processes to the first entity that excludes processes that utilize large amounts of network data.

[0032] In some embodiments, some processes may be more suitable for one type of first entity or region type than another process. Figure 3 and Figure 5 The process shown may be particularly advantageous for small merchants, as such small merchants may not have the appropriate computing infrastructure to accommodate other processes. However, such a process may still allow smaller merchants to participate in QR code-based transactions. As another example, Figure 6 and Figure 7 The illustrated process may be particularly advantageous for a large first entity that can utilize a more robust computing infrastructure and provide more secure data transmission.Based on these factors, the support server 120 may select certain processes to present to the first entity for selection.

[0033] After selecting the process to be used, the support server 120 can complete any other tasks so that the first entity is ready to participate in the QR code-based data transmission. For example, if the QR code is a static QR code (e.g., the same in multiple data transmissions), the support server 120 can generate the QR code and provide the QR code to the first entity. As another example, information about the first entity, the location (one or more) of the first entity, and / or information about the QR code (e.g., the standard and standard version used to generate the QR code, the hash version used to encode the QR, the use of security measures, etc.) can be stored by the support server 120 for reference, such as for verifying the first entity or for processing the QR code-based data transmission. After completing any other initialization tasks, the support server 120 can be prepared to facilitate the QR code-based data transmission for the first entity.

[0034] In these and other embodiments, in the initial registration, the first entity and / or the support server 120 may generate various information about the first entity and / or the processing flow selected by the first entity. In some embodiments, a first entity identifier (e.g., a merchant identifier) ​​unique to the first entity may be generated. The location of the first entity may also be generated and / or stored. In some embodiments, such a location may be determined based on the location of the first entity device 130 / 140 used in the registration for the QR code-based data transfer determined by the location service module 126. In these and other embodiments, a location identifier associated with the first entity may be generated. In some embodiments, in addition to and / or in lieu of the location identifier of the first entity, the latitude and longitude of the first entity may be stored. Other identification information of the first entity, such as a telephone number, may also be stored. In some embodiments, features of the first entity may also be stored, such as whether the selected processing flow utilizes pairing, which parties to the data transfer are selected to scan the QR code or generate the QR code, which parties to the data transfer will enter the amount of the data transfer, which parties to the data transfer will approve the data transfer, etc. Additionally or alternatively, features such as notification details from a user interface or device perspective may be stored. For example, the first entity may configure the processing flow to integrate with a pre-existing data transfer process for the first entity. The location of a computing device (such as an API endpoint) where URLs or URIs of resources for facilitating pre-existing data transfer processes and / or for implementing pre-existing data transfer processes may be stored. This registration process may be performed regardless of the process ultimately selected by the first entity. Some selected processes may include other registration tasks (e.g., generation of a static QR code).

[0035] In some embodiments, a QR code identifier can be generated for a static QR code and stored in association with the QR code of the first entity. The QR code identifier can be based on the first entity identifier, the location identifier, and / or other features stored relative to the first entity. In some embodiments, the QR code may include a hash, append, or other combination of the first entity identifier and the location identifier. In these and other embodiments, the QR code identifier can be used to verify the first entity and / or detect which processes to follow. For example, the support server 120 can receive the QR code identifier and can obtain the first entity identifier from the QR code identifier. The support server can look up the first entity based on the first entity identifier, determine which process the first entity selected in the initial registration, and based on detecting which process was selected, continue to process the data transmission based on the detected process.

[0036] In some embodiments, such a QR code identifier may be generated for a dynamic QR code of a first entity. In these and other embodiments, the QR code identifier on each dynamic QR code may be the same. Additionally or alternatively, the QR code identifier may include a version or digital identifier of a specific QR code in a plurality of dynamically generated QR codes, and the plurality of dynamically generated QR codes may be included so that the first entity identifier and / or the location identifier portion of the QR code identifier may remain consistent, but the digital identifier may change, so that the QR code identifier may change. In these and other embodiments, the QR code identifier may still be used to identify which processes the first entity has selected based on obtaining a merchant identifier from the QR code identifier.

[0037] In some embodiments, after selecting a given process for handling QR code-based data transmission and performing any other initialization tasks associated with the process, upon receiving a QR code (or deriving data therefrom) in support of QR code-based data transmission, the system 100 can distinguish which process will be used for a given data transmission. For example, one of the first entity or the second entity can scan the QR code (depending on the process) and can also verify the QR code at the second entity device 110 or the first entity device 130 / 140, or can send the QR code to the support server 120 for verification. After receiving the QR code or the message that the QR code is verified, the support server 120 can analyze the information embedded in the QR code or the information provided in the verification message to determine which process of the multiple processes the given data transmission follows. For example, the QR code may or may not have the amount of the data transmission, the location where the QR code was generated, the identifier of the entity (e.g., the second entity or the first entity) that generated the QR code, etc. Such information can be extracted from the QR code by the support server 120, or can be sent to the support server 120 from the QR code scanning device. Based on this information, the support server 120 can identify which of the multiple flows the data transfer will follow and can process the data transfer accordingly. In some embodiments, the support server 120 can verify that the information identifying the flow used for the data transfer is consistent with the flow selected by the first entity during registration. In some embodiments, the merchant point of sale (POS) terminal can be configured to scan and decrypt / extract information from the QR code to identify the selected flow and process the data transfer.

[0038] The various features of the QR code generated and / or used in the data transmission based on the QR code of the present disclosure can be used to identify the process of data transmission and / or maintain the security of data transmission. In some embodiments, the QR code of the present disclosure can be provided with an effective date. For example, the first entity (and / or support server 120) can add an effective date to the QR code so that the QR code is invalid after a certain period of time. For static QR codes, the effective date can be days, weeks, months or years. For dynamic QR codes, the effective date can be minutes or hours. In some embodiments, based on the security of the region or market, some regions or markets can have a shorter or longer effective duration. For example, in a region or country with a high crime rate, the effective date may be shorter than in a region or country with a low crime rate. As another example, for merchants working in a market with a high incidence of fraud, the effective date may be shorter.

[0039] In some embodiments, the QR code may be restricted to a geographic location to enhance the security of data transmission. For example, the QR code may include information about the location of the first entity, and if scanned away from the location of the first entity, the QR code may be triggered to be invalid. As another example, a pattern of geographic locations may be measured for a given mobile first entity, and use of the QR code outside of the measured pattern may be triggered to be invalid.

[0040] In some embodiments, the QR code identifier can be logically coupled with the location identifier to enhance the security of the data transmission. For example, for a static QR code, the location can be based on the known location of the first entity and the identifier of the static QR code. As another example, for a dynamic QR code, the location can be based on the location of the device requesting the QR code and / or the expected location of the first entity. If the location identifier does not match the QR code identifier, the QR code may not be verified.

[0041] In some embodiments, the QR code may include one or more information fields embedded or encrypted into the QR code. Example fields and values ​​may relate to the first entity being the merchant. Examples of these fields and information may include those shown in Table 1, where "Field" identifies an example information field in the QR code, "Key" identifies a short identifier for the field, "Notes" provides details about the field, and "Value / Example" provides an example of the format of the information in the field:

[0042]

[0043]

[0044] Table 1

[0045] In some embodiments, the QR code may include one or more security features to generate a secure QR code. For example, the QR code may include a digital signature (e.g., the signature in Table 1), a hash implementation of the data (e.g., and / or a hashed version of an algorithm for hashing the data of the QR code), etc. In these and other embodiments, the QR code may utilize a hash-based message authentication code (HMAC), which may utilize any cryptographic function, such as a message digest 5 (MD5) algorithm or a secure hash algorithm 1 (SHA-1), etc.

[0046] The second entity device 110 may include any device used by the second entity to facilitate participation in a QR code-based data transfer. The second entity device 110 may include a mobile device, a cellular device, a tablet computer, a wearable electronic device, etc. In some embodiments, the second entity device 110 may include a communication device 112, an optical scanner 114, and / or a display 116. The communication device 112 may be used to communicate with the first entity electronic device 130 / 140 and / or the support server 120. The optical scanner 114 may be configured to scan a QR code presented by the first entity, and the display 116 may be configured to display the QR code to be scanned by the first entity electronic device 130 / 140.

[0047] The support server 120 may include one or more computing devices configured to register and otherwise prepare the first entity to participate in the QR code-based data transfer and facilitate the QR code-based data transfer between the second entity and the first entity. In some embodiments, the support server 120 may be configured to facilitate the selection of a process to be used by the first entity. For example, the support server 120 may remove certain processes from a list of processes to be presented to the first entity, or may provide recommendations of processes to the first entity during the first entity's registration.

[0048] In some embodiments, the support server 120 may communicate with the second entity device 110 and / or the first entity device 130 / 140 during the QR code-based data transmission. In these and other embodiments, the support server 120 may determine which process to follow to support the QR code-based data transmission using information embedded in the scanned QR code or information embedded in information extracted from the QR code and transmitted to the support server 120. As described in the various figures below, the support server 120 may facilitate the QR code-based data transmission according to an appropriate process based on the identified process.

[0049] In some embodiments, the support server 120 may include a QR code processing module 122, a payment processing module 124, and a location service module 126. In some embodiments, one or more components of the support server 120 may communicate and coordinate with each other during QR code-based data transmission. Figures 2 to 7 Let's look at one or more examples of the operation of support server 120 .

[0050] The QR code processing module 122 may include codes and routines configured to enable a computing device to process a QR code. Additionally or alternatively, the QR code processing module 122 may be implemented using hardware including a processor, a microprocessor (e.g., for performing one or more operations or controlling the execution of one or more operations), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). In some other instances, the QR code processing module 122 may be implemented using a combination of hardware and software. In the present disclosure, the operations described as being performed by the QR code processing module 122 may include operations that the QR code processing module 122 may instruct the corresponding system (e.g., the support server 120) to perform.

[0051] The QR code processing module 122 may be configured to interact with the first entity device 130 / 140, the second entity device 110, other components of the support server, or any combination thereof when generating, verifying, validating, storing, or otherwise processing a QR code associated with a party or data transmission. In some embodiments, the QR code processing module 122 may provide one or more application programming interface (API) calls so that interactions from the second entity device 110, the first entity device 130 / 140, and / or other electronic devices may be through API calls to the support server 120.

[0052] In some embodiments, the QR code processing module 122 can be used for a registration process to prepare the first entity to process a QR code-based data transfer. For example, for certain selected processes, the QR code processing module 122 can generate a static QR code to be provided to the first entity in response to a request. In these and other embodiments, the static QR code can include a QR code identifier to facilitate identification of which process the data transfer will follow.

[0053] In some embodiments, the QR code processing module 122 can be used to process data transmission based on the QR code. For example, the second entity device 110 can request the QR code processing module 122 to generate a QR code. In response, the QR code processing module 122 can generate a dynamic QR code specific to the data transmission, or for a static QR code, a previously generated QR code can be provided unless the QR code has expired.

[0054] In some embodiments, the QR code processing module 122 can facilitate identification of which process the data transfer attempts to utilize. For example, the QR code processing module 122 can decrypt or otherwise extract information (such as a QR code identifier) ​​from the QR code so that the support server 120 can distinguish which potential processes the first entity is configured to use. For example, the QR code processing module 122 can read the amount of the data transfer from the QR code, whether the QR code is dynamic or static, etc. In addition or alternatively, the QR code processing module 122 can extract the QR code identifier and the first entity identifier from the QR code identifier. The QR code processing module 122 can determine the process associated with the first entity, the first entity is associated with the first entity identifier, and can configure the support server 120 based on the identified process to facilitate the data transfer based on the QR code. In some embodiments, the QR code processing module 122 can provide the first entity identifier to the payment processing module 124 to determine the process and / or configure the support server 120 to operate according to the process to facilitate the data transfer.

[0055] The payment processing module 124 may include code and routines configured to enable a computing device to process payments. Additionally or alternatively, the payment processing module 124 may be implemented using hardware including a processor, a microprocessor (e.g., for performing one or more operations or controlling the performance of one or more operations), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). In some other instances, the payment processing module 124 may be implemented using a combination of hardware and software. In the present disclosure, operations described as being performed by the payment processing module 124 may include operations that the payment processing module 124 may direct a corresponding system (e.g., support server 120) to perform.

[0056] The payment processing module 124 may be configured to interact with the first entity device 130 / 140, the second entity device 110, other components of the support server 120, a third party financial computing device, or any combination thereof in confirming, verifying, and / or communicating the amount of the data transfer. For example, the payment processing module 124 may be configured to verify the amount of the data transfer, verify the availability of funds, and transfer funds from one account to another or request a transfer of funds. In some embodiments, one or more accounts may be associated with In some embodiments, the payment processing module 124 may provide one or more application programming interface (API) calls so that interactions from the second physical device 110 , the first physical device 130 / 140 , and / or other electronic devices may be through API calls to the support server 120 .

[0057] In some embodiments, the payment processing module 124 may facilitate filtering or recommending certain processes for the first entity when selecting a process. For example, the payment processing module 124 may maintain risk profiles for various markets and / or fraud incidence rates for various merchants, so that the payment processing module 124 may remove certain processes from the processes presented to the first entity. In some embodiments, based on the high risk profile of the market in which the first entity operates, the payment processing module 124 may limit the first entity to selecting processes that include high security features, such as processes that use dynamic QR codes instead of static QR codes. Additionally or alternatively, one or more attributes of the process may be modified. For example, for high risk profile markets, the expiration date of the QR code may be shortened. As another example, a more secure version of the hash function performed on the QR code may be utilized, or a more secure signature of the QR code may be utilized.

[0058] In some embodiments, the payment processing module 124 may cause the support server 120 to facilitate one or more digital handshakes between the second entity device 110 and the first entity device 130 / 140. Such digital handshakes may utilize a secure socket layer (SSL) and may involve multiple information exchanges between the support server 120, the second entity device 110, and / or the first entity device 130 / 140.

[0059] The location services module 126 may include code and routines configured to enable the computing device to identify a location, compare two locations, interact with a global positioning system (GPS) service, etc. Additionally or alternatively, the location services module 126 may be implemented using hardware including a processor, a microprocessor (e.g., for performing one or more operations or controlling the performance of one or more operations), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). In some other instances, the location services module 126 may be implemented using a combination of hardware and software. In the present disclosure, operations described as being performed by the location services module 126 may include operations that the location services module 126 may direct the corresponding system (e.g., the support server 120) to perform.

[0060] The location service module 126 may be configured to interact with the first entity device 130 / 140, the second entity device 110, or any combination thereof when verifying, checking, or otherwise determining the location attributes of the data transmission. For example, the location service module 126 may determine the location of the first entity device 130 / 140, the location associated with the QR code, the location of the second entity device 110, the location where the QR code was generated, the location where the QR code was scanned, etc. In some embodiments, the location service module 126 may provide one or more application programming interface (API) calls so that interactions from the second entity device 110, the first entity device 130 / 140, and / or other electronic devices may be through API calls to the support server 120.

[0061] In some embodiments, the location services module 126 can facilitate selecting or recommending a process for QR code-based data transfer during registration of the first entity. For example, the location services module 126 can determine the location of the first entity such that certain potential processes may not be presented as possible choices based on the location of the first entity (e.g., because the first entity is located in a high crime area).

[0062] In some embodiments, the support server 120 may store information about the first entity associated with the first entity device 130 / 140. For example, the support server 120 may store the information described above in association with the initial registration. As another example, the support server 120 may store information about: what process the first entity has selected for QR code-based data transmission, the identifier of one or more QR codes associated with the first entity, the physical location of the first entity (including each branch of the first entity) or the physical location of the data transmission with the first entity, whether the first entity is a mobile merchant (e.g., a food truck), etc.

[0063] In some embodiments, the first entity device 130 / 140 may be similar or comparable to the second entity device 110. The first entity device 130 / 140 may include any device used by a first entity (e.g., a merchant) to register to participate in QR code-based data transmission and / or otherwise facilitate participation in QR code-based data transmission. In some embodiments, the first entity device 130 / 140 may receive a set of recommendations or processes to select from, and may present the set of recommendations or processes to the first entity for selection during registration. In some embodiments, the first entity device 130 / 140 may communicate with or be part of other merchant systems, such as an inventory processing system configured to monitor, track, or otherwise account for the inventory of the first entity, a checkout system configured to aggregate items purchased at the first entity, a payment system configured to request or accept payment, etc. In some embodiments, the first entity device 130 / 140 may include a communication device 142, an optical scanner 144, and / or a display 146. The communication device 142 may be used to communicate with the second entity device 110 and / or the support server 120. The optical scanner 144 may be configured to scan a QR code presented by the second entity, and the display 146 may be configured to display the QR code to be scanned by the second entity device 110 .

[0064] In some embodiments, the first entity device 130 may be associated with a merchant at a fixed location (e.g., a physical store). In these and other embodiments, the location of the first entity device 130 may be assumed to be fixed for all data transmissions. In some embodiments, if a merchant has multiple locations, such as multiple branches, the location of each branch may be stored by the support server 120, and each branch may have a unique identifier. In some embodiments, the first entity device 140 may be associated with a mobile merchant such as a food truck, a plumber, etc.

[0065] Although the second entity device 110 and the first entity device 130 / 140 are both shown as displaying a QR code, it should be understood that for a given data transfer, one device may display a QR code and another device may scan the QR code. Additionally or alternatively, a static QR code may be generated and printed or otherwise rendered and scanned by another party.

[0066] In some embodiments, the support server 120 can provide a whole QR code-based data transmission system that the first entity can incorporate into the experience provided by the first entity. For example, the first entity can include a merchant, and the data transmission can include a financial transaction between a consumer and a merchant. The merchant can utilize various Web-based or other computer-based elements in the merchant's payment interface, and can incorporate the transaction elements based on the QR code into the merchant's payment interface. In these and other embodiments, when implementing the data transmission processing flow, the support server 120 can store other identification information of various components of the uniform resource locator (URL) or the merchant's payment interface. In addition or alternatively, the function of the support server 120 can be called by an application programming interface (API) call within the merchant's programming code. In these and other embodiments, various processing flows can be folded into the payment flow designed by the existing merchant and the interaction with their consumers. For example, the POS terminal and the startup screen used by the merchant can be configured to make an API call to the support server 120 to generate and return a QR code to be displayed in a specific field of the merchant's startup screen.

[0067] The network 150 may be any device, system, component, or combination thereof to facilitate communication between any other components of the system 100. In some embodiments, the network 150 may represent a logical set of protocols or instructions, for example, a set of protocols used as a second entity device 110 and a first entity device 130 / 140 to communicate directly with each other. In some embodiments, the network 150 may include one or more wide area networks (WANs) and / or local area networks (LANs) that enable the second entity device 110, the support server 120, and / or the first entity device 130 / 140 to communicate. In some embodiments, the network 150 may include the Internet, including a global Internet formed by logical and physical connections between multiple WANs and / or LANs. Alternatively or in addition, the network 150 may include one or more cellular RF networks and / or one or more wired and / or wireless networks (e.g., 802.xx networks), Bluetooth access points, wireless access points, IP-based networks, etc. The network 150 may also include a server that enables one type of network to interface with another type of network. Additionally or alternatively, the network 150 may include an intranet, or one or more computing devices that communicate within an organization or in other secure ways.

[0068] After reviewing this disclosure, those skilled in the art may recognize that modifications, additions, or omissions may be made to the system 100 without departing from the scope of this disclosure. For example, any number of merchants with any number of branch locations and / or mobile locations may be included within the scope of this disclosure. As another example, the support server 120 may be divided into multiple computing devices that communicate with each other.

[0069] Figures 2 to 7 Various flow diagrams of example methods of performing QR code based data transfer are shown. Figure 2 The method may represent a general method for performing QR code-based data transmission, while Figures 3 to 7 Specific iterations of the process of QR code-based data transmission are shown. For each method, one or more operations of the method can be performed by a system or device (e.g., Figure 1 The second entity device 110, the support server 120 and / or the first entity device 130 / 140 or any combination thereof) is executed. In these and other embodiments, operations can be performed based on the execution of instructions stored on one or more non-transitory computer-readable media. Although shown as discrete blocks, various blocks of various methods can be divided into additional blocks, combined into fewer blocks, or removed depending on the desired implementation.

[0070] After reviewing the present disclosure, those skilled in the art will recognize that the present invention may be modified without departing from the scope of the present disclosure. Figures 2 to 7 The various methods of the present invention may be modified, added, or omitted. For example, the operations of the various methods may be implemented in different orders. Additionally or alternatively, two or more operations may be performed simultaneously. Furthermore, the operations and actions outlined are provided as examples, and some operations and actions may be optional, may be combined into fewer operations and actions, or may be extended to additional operations and actions without departing from the essence of the disclosed embodiments.

[0071] refer to Figure 2 At block 205, the first entity may participate in a registration process to perform a QR code-based data transfer. For example, the first entity may register with a support server such as Figure 1In some embodiments, the registration process may include a support server 120 to register to participate in the QR code-based data transfer. In these and other embodiments, the registration process may include a series of questions and / or inputs sought from the first entity so that the QR code-based data transfer can be supported. In some embodiments, such a registration process may include removing one or more potential processing flows so that when selecting which flow to use for performing the QR code-based data transfer, a list of less than all potential processing flows is presented to the first entity. In these and other embodiments, the registration may include the support server storing and / or generating various information related to the first entity. Such information may include a first entity identifier, a location identifier (which may be different for different locations of the same first entity (e.g., different branches of the same merchant)), address details (e.g., a street address of the first entity, an IP address of the first entity, etc.), a geographic location of the first entity (e.g., the latitude and longitude of the location identified by the location service module), a telephone number of the first entity, and one or more features associated with the selected flow. For example, these characteristics may include which potential processes are selected by the first entity, whether the process selected by the first entity utilizes pairing, which party to the data transfer will scan the QR code and / or display the QR code, whether the QR code includes the amount of the data transfer, notification details associated with the process (e.g., which entities receive confirmation notifications, approval notifications, etc.), and / or any combination of the above.

[0072] In some embodiments, for example, when a process utilizing a static QR code is selected, block 205 may additionally include generation of a QR code. For example, a QR code processing module of the support server may generate a static QR code based on a merchant identifier and / or a location identifier.

[0073] At block 210, a QR code may be received from a computing device. For example, a second physical device (such as Figure 1 The second entity device 110) can scan the first entity (e.g., the merchant device (such as Figure 1 As another example, the first entity device may scan a QR code displayed on the second entity device. In these and other embodiments, the scanned QR code may be sent to a support server (e.g., Figure 1 support server 120) and received by it for processing.

[0074] At box 220, the QR code may be analyzed to determine a request for initiating a data transfer (e.g., a payment transaction) between the first entity and the second entity. Additionally or alternatively, the QR code may be scanned to determine the payment characteristics of the data transfer. In some embodiments, the QR code may have characteristics of the data transfer embedded in the QR code. These characteristics may include identifiers about the following items: which process among multiple potential processing flows is to be followed by the support server when processing the data transfer. For example, the characteristics may include information such as whether the QR code is a QR code generated by the first entity (e.g., a QR code generated by a merchant) or a QR code generated by the second entity (e.g., a QR code generated by a consumer), the amount of the data transfer, whether the QR code is a static QR code or a dynamic QR code, the first entity associated with the QR code, the location of the first entity, the location where the QR code is generated, etc., which may each be associated with different types of processes as indicated above. In some embodiments, the QR code may be analyzed by a scanning device, and the characteristics may be sent to the support server. In some embodiments, the QR code may include a field or other identifier that specifically identifies which process among the potential processes is to be followed by the QR code generation.

[0075] At block 230, it may be determined whether a QR code processing flow is identified from a plurality of potential QR code processing flows. In some embodiments, this determination may be based on features. For example, the support server may be configured to process QR code-based data transmission along any of a plurality of potential flows. The support server may identify which flow is associated with the first entity based on the features from block 220. Figures 3 to 7 Various examples of potential flows are identified in . For example, a flow ( Figure 3 ) can utilize a static QR code generated by the merchant that does not have the amount embedded in the QR code and is scanned by the consumer, where the consumer enters the amount of the transaction; another process ( Figure 4 ) may include a static QR code generated by the merchant without the amount embedded in the QR code and scanned by the consumer, where the merchant enters the amount of the transaction; additional process ( Figure 5 ) may include a dynamic QR code generated by a merchant, the dynamic QR code having an amount embedded in the QR code and scanned by a consumer, wherein the consumer approves the amount embedded in the QR code by the merchant; another process ( Figure 6 ) may include a dynamic QR code generated by the consumer without a dollar amount and scanned by the merchant, where the merchant enters the dollar amount and the consumer approves the dollar amount; and another process ( Figure 7 ) may include a dynamic QR code generated by the consumer having an amount embedded in the QR code and scanned by the merchant, where the merchant approves the amount.

[0076] In some embodiments, the support server can determine which party (e.g., the first entity or the second entity) is sending the initial message of the data transfer (e.g., the party scanning the QR code), whether the transmission includes an amount embedded in the QR code (extracted by the QR code itself or by a scanning device), whether the QR code is dynamic or static (e.g., by analyzing the expiration date of the QR code or features that directly identify whether the QR code is static or dynamic), etc. Using such features, the support server can identify a specific flow and can proceed to block 240. If no QR code processing flow is identified, the method 200 can proceed to block 235, and an error message can be sent back to the device sending the QR code and / or the first entity, and the method 200 can end.

[0077] At box 240, the first entity (e.g., merchant) for data transmission can be verified based on the QR code and the identified processing flow. For example, the support server can find information from the QR code in the database to verify that the information is consistent with the information associated with the first entity stored in the database. For example, the support server can verify that the feature is consistent with the process selected by the first entity for performing a QR code-based transaction for the first entity. As another example, the support server can verify that the QR code identifies the correct first entity and the correct location of the first entity. In these and other embodiments, verifying the first entity can help prevent fraud or other problems in the transaction. For example, when using a static QR code, there may be a risk that a third party may steal or copy the QR code and try to use the QR code to secretly perform a transaction. By verifying the first entity, such attempts can be avoided. In some embodiments, verification can include any of a variety of verifications, such as verifying that the location where the QR code is scanned or generated matches the location of the first entity stored by the support server. In some embodiments, verification of the first entity can be a prerequisite for the transfer of funds for the transaction. As an additional example, the support server can verify that the signature of the QR code is properly authenticated (e.g., the QR code includes the latest electronic signature from the support server).

[0078] At block 250, in response to the first entity being authenticated, the data transfer between the second entity and the first entity may be processed according to the identified process flow. For example, the support server may perform any additional tasks to authenticate the transaction, the amount of the transaction, the identities of the parties, etc. Additionally or alternatively, block 250 may include transferring funds or requesting a transfer of funds from an account associated with the second entity to an account associated with the first entity.

[0079] Figures 3 to 7An example of a QR code based data transfer is provided, where the first party may include a merchant and the second party may include a consumer, and the QR code based data transfer (e.g., a data transfer) may include a QR code based transaction. In these and other embodiments, features of the process may include a payment feature. Although provided as an example, the same type of process may also be applicable to other data transfers and other entities.

[0080] Figure 3 One potential flow of a QR code based transaction can be illustrated. Figure 3 The process may include a process in which the payment feature includes that the QR code is static, generated by the merchant and scanned by the consumer. The consumer can enter the transaction amount, and the merchant can verify that the transaction is complete. Such a process may be advantageous because such a process can eliminate pairing between the merchant device and the consumer device. In addition, such a process can utilize a small amount of network traffic, so that the process can be used in locations with limited network infrastructure. In addition, the process can support situations where the merchant is mobile and / or otherwise not in a specific physical place. Such a process may be particularly advantageous for small merchants or individual practitioners or other merchants with minimal or limited computer infrastructure. In addition, such a process may be advantageous for merchants in countries or regions of the world with limited network infrastructure or merchants with slow Internet connections.

[0081] At block 303, a request to generate a QR code may be received from a merchant. For example, when initially registering to process QR code-based transactions, the merchant may request a QR code from a support server (e.g., Figure 1 The QR code processing module 122 may be used to generate a QR code. The QR code processing module 122 may be used to process the QR code, and the QR code may be encrypted or otherwise generated using information received from the merchant. For example, the QR code processing module 122 may call the location service module 126 to determine the location of the merchant, and generate a QR code identifier based on the location, merchant identifier, and / or other information about the merchant when generating the QR code. Additionally or alternatively, the QR code may include a signature from the support server 120 indicating an approved QR code and / or an approved merchant. In these and other embodiments, a preselected hash algorithm may be used to hash the QR code. In some embodiments, a version of the hash used may be embedded, encrypted, or otherwise included in the QR code so that the scanning device can decrypt the QR code and verify the signature from the support server 120.

[0082] At block 305, a QR code may be received that is scanned by a consumer while at a merchant. For example, the merchant may generate the QR code (e.g., when initially registering to process QR code-based transactions) and may display the QR code in a physical format (e.g., printed) or in electronic form (e.g., displayed on a screen). The consumer may use a consumer device (such as a Figure 1 The consumer device 110) is used to scan the QR code.

[0083] At box 310, it can be determined whether the QR code is valid. In some embodiments, a program running on a consumer device can operate to verify information about the QR code. In addition or alternatively, the consumer device can send the QR code (and / or information obtained from scanning the QR code) to a support server. For example, the consumer device can send the QR code to a QR code processing device of a support server, or to a payment processing device that can query the QR code processing device in turn. The support server can decrypt or otherwise derive the information stored in the QR code, and can verify information about merchants, consumers, etc. In some embodiments, the support server can store information about the transaction, such as information about consumers, merchants, OR codes, etc. of the transaction. In some embodiments, the support server can generate a transaction identifier associated with the transaction. If the QR code is determined to be invalid, method 300 can proceed to box 315. If the QR code is determined to be valid, method 300 can proceed to box 320.

[0084] At box 315, a message that the QR code is invalid can be returned. For example, a message that the QR code is invalid can be provided to the consumer who scanned the QR code. In some embodiments, the reason why the QR code is invalid (e.g., invalid merchant, invalid merchant location, etc.) can be provided.

[0085] At block 320, a verification message may be sent to the consumer verifying the merchant associated with the QR. For example, the support server may send a message to the consumer electronic device that the merchant has been verified. In some embodiments, such a communication may include a transaction identifier.

[0086] In some embodiments, in response to the verification message, the consumer electronic device can prompt the consumer to enter the transaction amount. For example, the consumer electronic device can provide an interface to the consumer to enter the amount that the consumer intends to pay to the merchant.

[0087] At block 325, a payment amount may be received from the consumer. For example, in response to entering an amount, the consumer device may send the amount to a support server.

[0088] At block 330, the payment may be processed by the support server. For example, the support server may transfer the amount of funds from a consumer account associated with the support server to a merchant account associated with the support server. As another example, the support server may send a request to a financial institution with which the consumer has a relationship to transfer the payment amount to an account associated with the merchant at the same or a different financial institution. In these and other embodiments, the processing of the payment may be invoked via an API call from one of the merchant or consumer devices to the support server.

[0089] At block 335, a payment confirmation may be received from the merchant. For example, the merchant may send a message to the support server that a funds confirmation has been received for the transaction amount.

[0090] At block 340, a success message may be sent to the consumer. For example, the support server may send a message to the consumer device indicating that the transaction processing is complete.

[0091] Figure 4 One potential flow of a QR code based transaction can be illustrated. Figure 4 A process may include a process where the payment feature includes a QR code that is static, generated by the merchant, and scanned by the consumer. The merchant may enter the transaction amount, and the consumer may confirm the amount. Such a process may utilize pairing between the merchant device and the consumer device. Such a process may include a high level of trust in the transaction because the merchant enters the amount, and the consumer approves the amount, so that both parties are committed to the transaction. In addition, since a large number of messages can be passed between the parties and a secure connection can be formed, such a process may utilize a large amount of network traffic.

[0092] At block 403, a request to generate a QR code may be received from a merchant. Block 403 may be associated with Figure 3 The block 303 is similar or equivalent.

[0093] At block 405, a QR code may be received that is scanned by a consumer while at a merchant. Block 405 may be associated with Figure 3 305 is similar or equivalent.

[0094] At block 410, it may be determined whether the QR code is valid. Block 410 may be associated with Figure 3 If the QR code is determined to be invalid, the method 400 may proceed to block 415. If the QR code is determined to be valid, the method 400 may proceed to block 420.

[0095] At block 415, an invalidation message may be sent to the consumer. Block 415 may be associated with Figure 3 315 is similar or equivalent to that of FIG.

[0096] At block 420, a request for an amount message may be sent to the merchant. For example, upon determining that the QR code is valid, the consumer device may submit an API to the support server indicating that the consumer intends to pay the merchant. The API call may cause the support server to send a request for an amount message to the merchant.

[0097] At block 425, a payment amount may be received from the merchant. For example, in response to the request for the amount, the merchant may enter the payment amount into the merchant device. For example, the amount request message may cause the merchant device to load a user interface for the merchant to enter the transaction amount. The merchant device may send the amount to the support server.

[0098] The payment amount may be sent to the consumer at block 430. For example, the API call may be responded to with the amount entered by the merchant.

[0099] At block 435, it may be determined whether the consumer confirms the transaction amount. If the consumer does not confirm the amount, method 400 may proceed to block 440. If the consumer does confirm the amount, method 400 may proceed to block 445.

[0100] In these and other embodiments, blocks 425 to 435 may include one or more SSL handshake exchanges between the merchant device and / or the consumer device so that the amount entered and verified can be processed securely. In these and other embodiments, a pairing engine of a support server may facilitate such SSL handshakes.

[0101] At block 440, a transaction end message may be sent to the consumer and / or merchant. For example, if the merchant entered an incorrect amount, or if the consumer changes his mind, the consumer may refuse to confirm the transaction amount.

[0102] At block 445, payment may be processed in response to the consumer confirming the amount. Block 445 may be associated with Figure 3 330 is similar or equivalent.

[0103] At block 450, the support server may receive payment confirmation from the merchant. Block 450 may be associated with Figure 3 335 is similar or equivalent.

[0104] At block 455, a success message may be sent to the consumer. Block 455 may be associated with Figure 3 340 is similar or equivalent.

[0105] Figure 5 One potential flow for a QR code based transaction can be shown. Figure 5The process may include a process in which the payment feature includes that the QR code is dynamic (e.g., newly generated for each transaction), generated by the merchant and scanned by the consumer. The QR code may additionally include the transaction amount, and the consumer may confirm the amount. Such a process may include a high level of trust in the transaction because the merchant generates the amount and the consumer approves the amount, so that both parties are invested in the transaction. In addition, such a process may utilize a small amount of network traffic. Such a process may be particularly advantageous for small merchants or individual practitioners or other merchants with minimal or limited computer infrastructure. In addition, such a process may be advantageous for merchants in countries or regions of the world with limited network infrastructure or merchants with slow Internet connections.

[0106] At block 505, a QR code generation request may be received from a merchant. For example, a merchant may submit a request to generate a QR code to a support server. In some embodiments, the request may include a transaction amount. For example, the merchant may manually enter an amount, or a merchant device may automatically generate an amount (e.g., by subtotaling items scanned at a retailer), and an API call may be sent from the merchant device to a support server to generate a QR code including the transaction amount.

[0107] At block 510, a QR code may be generated based on the amount in the request of block 505 and based on the merchant. For example, a QR processing component of the support server may incorporate the received amount and other information from or about the merchant into the QR code. Such other information may include a merchant identifier, the location of the merchant or the location of a branch of the merchant, etc.

[0108] The QR code may be sent to the merchant at block 515. For example, the support server may send the QR code to the merchant device.

[0109] The merchant may display the QR code at block 520. For example, the merchant device may receive the QR code from the support server and may display the QR code on a display of the merchant device.

[0110] The consumer may scan the QR code at block 525. For example, the consumer may use an optical scanner of the consumer device to scan the QR code from the display of the merchant device.

[0111] At block 530, it may be determined whether the consumer device has verified the QR code. Block 530 may be associated with Figure 3The method 500 may be similar or equivalent to block 310 of . For example, an application or other software running on the consumer device may decrypt the QR code and verify one or more security features of the QR code to verify that the QR code is valid. Additionally or alternatively, the consumer device may verify whether the QR code was successfully scanned so that the consumer device can obtain information contained in the QR code. If the consumer device does not verify the QR code, the method 500 may proceed to block 535. If the consumer device does verify the QR code, the method 300 may proceed to block 540.

[0112] At block 535, an invalidation message may be sent regarding the transaction. Block 535 may be associated with Figure 3 315 is similar or equivalent to that of FIG.

[0113] At block 540, it may be determined whether the consumer confirms the transaction amount. For example, in response to the QR code being verified, the consumer device may present the transaction amount contained in the QR code to the consumer to verify the amount. If the consumer does not verify the amount, method 500 may return to block 535, where an invalidation message regarding the transaction may be sent. If the consumer verifies the amount, method 500 may proceed to block 550.

[0114] At block 545, a QR code verification message may be received. In some embodiments, the QR code verification message may include an indication that the QR code is verified and the transaction amount is verified. For example, the consumer device may send a QR code message to a support server in response to the QR code and the amount being verified.

[0115] At block 550, payment may be processed. Block 550 may be associated with Figure 3 335 is similar or equivalent.

[0116] At block 555, a success message may be sent to the consumer. Block 555 may be similar or comparable to block 345 of method 3.

[0117] Figure 6 One potential flow of a QR code based transaction can be illustrated. Figure 6A process may include one in which the payment feature includes that the QR code is dynamic (e.g., newly generated for each transaction), generated by the consumer, and scanned by the merchant. The QR code, while specific to the transaction, may exclude the transaction amount. The merchant may scan the QR code, and the amount may be entered (either in an automated fashion from a merchant device or manually from the merchant), and the consumer may verify the amount. Such a process may include a high level of trust in the transaction because the merchant provides the amount and the consumer approves the amount, such that both parties are committed to the transaction. Additionally, such a process may utilize pairing to provide improved security. Additionally, such a process may utilize large amounts of network traffic. Such a process may be particularly advantageous for larger merchants or merchants with robust computer infrastructure. Furthermore, such a process may be advantageous for merchants in countries or regions of the world with developed network infrastructure, or for merchants with high-speed Internet connections at their locations. Compared to previous processes, Figure 6 The process can provide a process with additional security features.

[0118] At block 605, a QR code generation request may be received from a consumer. For example, a consumer may submit a request to generate a QR code to a support server. In some embodiments, the request may exclude a transaction amount. In these and other embodiments, an API call may be sent from a consumer device to a support server to generate a QR code for a transaction. In these and other embodiments, the request may or may not identify a merchant with whom the consumer intends to engage in a QR code-based transaction.

[0119] At block 610, a QR code may be sent to the consumer. For example, a QR code processing component of a support server may generate a QR code in response to a request and send the QR code to a consumer device. The QR code may include information about the transaction, the merchant, the consumer device, etc.

[0120] At block 613, the merchant may scan the QR code. For example, the merchant may use an optical scanner of the merchant device to scan the QR code from the display of the merchant device. In these and other embodiments, the optical scanner may be part of the merchant's POS terminal, or other interface via which the consumer interacts with the merchant when making a purchase.

[0121] At block 615, the merchant may determine whether the scanned QR code is valid. For example, the merchant device may decrypt or otherwise obtain information from the QR code. If the QR code is not verified, the method 600 may proceed to block 620. If the QR code is verified by the merchant, the method 600 may proceed to block 625.

[0122] At block 620, an invalidation message may be sent. For example, the merchant device may send a message to the consumer device that the QR code was not verified. As another example, the merchant device may report to the support server that the QR code was not verified, and the support server may notify the consumer that the QR code was not verified.

[0123] At block 625, a payment amount may be received from the merchant device. For example, after verifying the QR code, the merchant device may present a user interface to the merchant through which the merchant may enter the transaction amount. As another example, the merchant device may automatically provide the amount (e.g., by subtotaling items scanned at a retailer) by sending the amount from the merchant device in response to verifying the QR code.

[0124] The payment amount may be sent to the consumer at block 630. For example, the support server may receive the payment amount from the merchant and send the amount to the consumer for approval.

[0125] At block 635, it may be determined whether the consumer confirms the transaction amount. Block 635 may be associated with Figure 4 If the consumer does not confirm the amount, method 600 may return to block 620, and an invalid message may be sent to one or both parties of the transaction. If the consumer does confirm the amount, method 600 may proceed to block 640.

[0126] In these and other embodiments, blocks 625 to 635 may include one or more SSL handshake exchanges between the merchant device and / or the consumer device so that the amount entered and verified can be processed securely. In these and other embodiments, a pairing engine of a support server may facilitate such SSL handshakes.

[0127] At block 640, an approval of the amount may be received from the consumer at the support server. For example, in response to receiving input from the consumer confirming the amount, the consumer device may send an approval to the support server indicating that the consumer approves the payment amount for the transaction. In some embodiments, the approval of the amount may be sent in the form of an API requesting payment in the amount confirmed by the consumer.

[0128] At block 645, payment may be processed. Block 645 may be associated with Figure 3 335 is similar or equivalent.

[0129] At block 650, a success message may be sent to the consumer. Block 650 may be associated with Figure 3 345 is similar or equivalent.

[0130] Figure 7 One potential flow of a QR code based transaction can be illustrated. Figure 7 A process may include a process in which the payment feature includes that the QR code is dynamic (e.g., newly generated for each transaction), generated by the consumer and scanned by the merchant. The QR code may include the transaction amount. The merchant may scan the QR code and may approve the amount. Such a process may include a high level of trust in the transaction because the consumer provides the amount and the merchant confirms the amount, so that both parties are committed to the transaction. Such a process may utilize a small amount of network traffic, so that the process may be utilized in locations with limited network infrastructure. Such a process may be particularly advantageous for large merchants or merchants with robust computer infrastructure.

[0131] At block 705, a QR code generation request may be received from a consumer. In these and other embodiments, the QR code generation request may include a payment amount for the transaction. For example, a consumer may submit a request to generate a QR code to a support server. In these and other embodiments, an API call may be sent from a consumer device to a support server to generate a QR code for the transaction. In these and other embodiments, the request may or may not identify a merchant with whom the consumer intends to participate in a QR code-based transaction. The API call may include a transaction amount.

[0132] At block 710, the requested QR code may be sent to the consumer. Block 710 may be associated with Figure 6 610. After receiving the QR code, the consumer device may display the QR code so that the merchant device may scan the QR code.

[0133] At block 713, the merchant may scan the QR code. For example, the merchant may use an optical scanner of the merchant device to scan the QR code from the display of the merchant device. In these and other embodiments, the optical scanner may be part of the merchant's POS terminal, or other interface via which the consumer interacts with the merchant when making a purchase.

[0134] At block 715, it may be determined whether the scanned QR code is verified by the merchant. Block 715 may be associated with Figure 6 If the QR code is not verified, the method 700 may proceed to block 720. If the QR code is verified by the merchant, the method 700 may proceed to block 725.

[0135] At block 720, an invalidation message may be sent. For example, the merchant device may send a message to the consumer device that the QR code was not verified. As another example, the merchant device may report to the support server that the QR code was not verified, and the support server may notify the consumer that the QR code was not verified.

[0136] At block 725, it may be determined whether the merchant has verified the amount identified in the QR code. For example, after scanning the QR code, the merchant device may decrypt or otherwise extract information from the scan, including the payment amount for the transaction. The amount may be presented to the merchant on a user interface at the merchant device so that the merchant can verify the payment amount for the transaction. If the merchant does not verify the amount, the method 700 may return to block 720 to send an invalid message (e.g., from the merchant device to the consumer device or from the merchant device to a support server to transmit the invalid message to the consumer device). If the merchant verifies the amount, the method 700 may proceed to block 730.

[0137] At block 730, a verification message may be sent from the merchant device to the support server. For example, the verification message may indicate that the QR code has been verified and the amount in the QR code has been verified by the merchant. After receiving the verification message from the merchant device, both the consumer and the merchant may have entered the amount to verify the transaction, and the payment may be ready to be processed.

[0138] In some embodiments, after receiving the verification message, details about the transaction can be stored by the support server. For example, the support server can store the QR code, the transaction party, the amount of the transaction, the location of the transaction, the transaction identifier, etc., or other information about the transaction and / or the QR code.

[0139] At block 735, payment may be processed. Block 735 may be associated with Figure 3 335 is similar or equivalent.

[0140] At block 740, a success message may be sent to the consumer. Block 740 may be associated with Figure 3 345 is similar or equivalent.

[0141] Figure 8 An example computing system 800 ("system 800") is shown that can be used in a system configured to implement QR code-based transactions according to one or more embodiments of the present disclosure. System 800 may include a processor 810, a memory 820, a data storage device 830, a communication unit 840, a display 850, and an optical scanner 860, which may all be communicatively coupled. In some embodiments, at least a portion of system 800 may be part of any system or device described in the present disclosure. For example, system 800 may be included in Figure 1 in or as part of devices 110, 120, 130 and / or 140.

[0142] In general, the processor 810 may include any suitable special or general purpose computer, computing entity, or processing device including various computer hardware or software modules, and may be configured to execute instructions stored on any applicable computer-readable storage medium. For example, the processor 810 may include a microprocessor, a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (SIC), a field programmable gate array (FPGA), or any other digital or analog circuit configured to interpret and / or execute program instructions and / or process data.

[0143] Despite Figure 8 820, data storage device 830, or both. In some embodiments, processor 810 may interpret and / or execute program instructions and / or process data stored in memory 820, data storage device 830, or both. In some embodiments, processor 810 may extract program instructions from data storage device 830 and load the program instructions into memory 820.

[0144] The processor 810 may execute the program instructions after they are loaded into the memory 820. In these and other embodiments, the QR code processing module 122, the payment processing module 124, and / or the location services module 126 may be stored in the memory 820 and / or the data storage device 830 and may be loaded and executed by the processor 810 to perform operations related to facilitating QR code-based transactions.

[0145] The memory 820 and the data storage device 830 may include a computer-readable storage medium or one or more computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. Such a computer-readable storage medium may include any available medium that can be accessed by a general-purpose or special-purpose computer such as a processor 810. By way of example, such a computer-readable storage medium may include a non-transitory computer-readable storage medium, including a random access memory (RAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a compact disk read-only memory (CD-ROM) or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory devices (such as solid-state memory devices) or any other storage medium that can be used to carry or store program codes in the form of computer-executable instructions or data structures and can be accessed by a general-purpose or special-purpose computer. The above combination may also be included within the scope of the computer-readable storage medium. Computer-executable instructions may include, for example, instructions and data configured to cause the processor 810 to perform a certain operation or a set of operations as described in the present disclosure or to control the execution of a certain operation or a set of operations as described in the present disclosure.

[0146] The communication device 840 may include any component, device, system, or combination thereof configured to send or receive information over a network. In some embodiments, the communication device 840 may communicate with other devices located at other locations, at the same location, or even at other components within the same system. For example, the communication device 840 may include a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device (e.g., an antenna) and / or a chipset (e.g., a Bluetooth device, a near field communication (NFC) device, an 802.6 device (e.g., a metropolitan area network (MAN), a WiFi device, a WiMax device, a cellular communication facility, etc.), etc. The communication device 840 may allow data to be exchanged with a network and / or any other suitable device or system (such as those described in the present disclosure). For example, when the system 800 is included in Figure 1 When the device 110, 120, 130 and / or 140 is in communication with the device 110, 120, 130 and / or 140, the communication device 840 may allow the device 110, 120, 130 and / or 140 to communicate with the device 110, 120, 130 and / or 140 through Figure 1 The network 150 and / or other communication pathways may communicate with one or more other devices.

[0147] Display 850 may be configured as one or more displays, such as an LCD, LED, or other type of display. Display 850 may be configured to present content such as video, text subtitles, a user interface, and other data as directed by processor 810. For example, when system 800 is included in Figure 1When the device 110, 120, 130 and / or 140 is in use, the display 850 can be configured to present the QR code.

[0148] The optical scanner 860 may include one or more devices configured to capture depictions such as digital images or QR codes, infrared scans, and / or other depictions. For example, the optical scanner 860 may include a camera (including a video, digital, or analog camera), an infrared scanner, a laser scanner, a charge coupled device (CCD) sensor, a complementary metal oxide semiconductor (CMOS) sensor, or any other photoelectric sensor. The optical scanner 860 may be configured to capture depictions of a QR code. In some embodiments, the optical scanner 860 may be configured to capture multiple depictions of a QR code (e.g., a video).

[0149] System 800 may include or be included in a mobile device (such as a cellular phone, e-reader, mobile gaming system, laptop computer, and / or other device), a desktop computer, a server computer, an Internet-connected device (e.g., a thermostat, a security system, a refrigerator, and / or other device), a wearable device (e.g., a smart watch, smart glasses, a fitness tracker, and / or other device), or any other device.

[0150] After reading this disclosure, those skilled in the art may recognize that modifications, additions, or omissions may be made to the system 800 without departing from the scope of the present disclosure. For example, the system 800 may include more or fewer components than those explicitly shown and described.

[0151] As used in this disclosure, the term "module" or "component" may refer to a specific hardware implementation configured to perform the actions of a module or component and / or a software object or software routine that may be stored on general hardware of a computing system (e.g., computer-readable media, processing devices, etc.) and / or executed by general hardware. In some embodiments, the different components, modules, engines, and services described in this disclosure may be implemented as objects or processes executed on a computing system (e.g., as separate threads). Although some of the systems and methods described in this disclosure are generally described as being implemented in software (stored on general hardware and / or executed by general hardware), specific hardware implementations or combinations of software and specific hardware implementations are also possible and contemplated. In this specification, a "computing entity" may be any computing system as previously defined in this disclosure, or any module or combination of modules running on a computing system.

[0152] The foregoing disclosure is not intended to limit the present disclosure to the precise form disclosed or to the specific field of use. Therefore, it is contemplated that various alternative embodiments and / or modifications to the present disclosure are possible in accordance with the present disclosure, whether or not explicitly described or implied herein. Having thus described the embodiments of the present disclosure, it will be appreciated that changes may be made in form and detail without departing from the scope of the present disclosure. Therefore, the present disclosure is limited only by the claims.

[0153] The terms used herein, and particularly in the appended claims (e.g., the bodies of the appended claims), are generally intended to be “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.).

[0154] In addition, if a specific number of introduced claim recitations is intended, such intent will be expressly recited in the claim, and in the absence of such recitation, such intent is not present. For example, to aid understanding, the following appended claims may contain the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be interpreted as implying that a claim recitation introduced by the indefinite article "a" or "an" limits any particular claim containing the introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"); the same is true for the use of definite articles used to introduce claim recitations.

[0155] Additionally, even if a specific number of an introduced claim recitation is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., a bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, where a convention similar to "at least one of A, B, and C, etc." or "one or more of A, B, and C, etc." is used, such a construction is generally intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc. The use of the term "and / or" is intended to be interpreted in this manner.

[0156] In addition, any ambiguous word or phrase presenting two or more alternative terms, whether in the specification, claims or drawings, should be understood to include the possibility of one, either or both of these terms. For example, the phrase "A or B" should be understood to include the possibility of "A" or "B" or "A and B".

[0157] However, the use of such phrases should not be interpreted as implying that a claim recitation introduced by the indefinite article "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"); the same is true for the use of the definite article used to introduce a claim recitation.

[0158] In addition, the use of the terms "first", "second", "third", etc. in this document is not necessarily used to indicate a specific order. Generally, the terms "first", "second", "third", etc. are used to distinguish different elements. In the absence of specific indications that the terms "first", "second", "third", etc. indicate a specific order, these terms should not be understood as indicating a specific order.

[0159] All examples and conditional language described herein are intended for teaching purposes to help readers understand the present invention and the concepts contributed by the inventors to further develop the art, and should be interpreted as not being limited to such specific examples and conditions. Although the embodiments of the present disclosure are described in detail, it should be understood that various changes, substitutions and modifications may be made thereto without departing from the spirit and scope of the present disclosure.

[0160] The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the embodiments shown herein, but should be consistent with the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method comprising: receiving a quick response (QR) code from a computing device, wherein the QR code includes a first entity identifier identifying a first entity, and wherein the QR code corresponds to a request to initiate an electronic transaction between the first entity and a second entity; determining a first set of characteristics associated with the electronic transaction and a second set of characteristics corresponding to the computing device, wherein the second set of characteristics includes a geographic location of the computing device; Based on the first set of features and the second set of features, identifying a first QR code processing flow for the electronic transaction from a plurality of QR code processing flows; Verifying the QR code; and In response to validating the QR code, the electronic transaction between the first entity and the second entity is processed based on the first QR code processing flow.

2. The method according to claim 1, further comprising: The first entity is authenticated based on the first entity identifier, wherein processing the electronic transaction is further performed based on authenticating the first entity.

3. The method according to claim 2, wherein: Authenticating the first entity is further based on verifying a location of the computing device.

4. The method according to claim 1, wherein: The first set of characteristics associated with the electronic transaction includes a transaction amount, an indication of a QR code processing flow selected for the electronic transaction utilizing pairing, and an indication of which of the first entity and the second entity will approve the electronic transaction, and wherein determining the first set of characteristics associated with the electronic transaction includes determining whether the QR code is a static QR code or a dynamic QR code.

5. The method according to claim 1, wherein: The first entity is a merchant and the second entity is a user electronically interacting with the merchant.

6. The method according to claim 1, wherein: Processing the electronic transaction between the first entity and the second entity comprises: sending the amount specified by the second entity to the first entity; receiving a confirmation from the first entity indicating that the first entity has received the amount; and In response to receiving the confirmation from the first entity, a success message is sent to the second entity indicating completion of the electronic transaction.

7. A non-transitory computer-readable medium storing instructions that, in response to being executed, cause a machine to perform or control the performance of one or more operations, the operations comprising: receiving a quick response (QR) code from a computing device, wherein the QR code includes a request to initiate an electronic transaction between a first entity and a second entity, and wherein the QR code includes a first entity identifier corresponding to the first entity; determining a first set of characteristics associated with the electronic transaction; determining a second set of characteristics corresponding to the computing device, wherein the second set of characteristics includes a geographic location of the computing device; Based on the first set of features and the second set of features, identifying a first QR code processing flow for the electronic transaction from a plurality of QR code processing flows; Verify that the QR code is valid; and In response to verifying that the QR code is valid, processing the electronic transaction between the first entity and the second entity according to the first QR code processing flow.

8. The non-transitory computer readable medium of claim 7, wherein: The first entity is a mobile merchant and the second entity is a consumer.

9. The non-transitory computer readable medium of claim 8, wherein: Processing the electronic transaction is further performed in response to authenticating the first entity based on the first entity identifier, and wherein the first set of characteristics associated with the electronic transaction includes a transaction amount.

10. The non-transitory computer readable medium of claim 9, wherein: Authenticating the first entity is further based on verifying a geographic location of the computing device included in the second set of characteristics.

11. The non-transitory computer readable medium of claim 7, wherein: Determining the first set of characteristics associated with the electronic transaction includes determining whether the QR code is a static QR code or a dynamic QR code.

12. The non-transitory computer readable medium of claim 7, wherein: Processing the electronic transaction between the first entity and the second entity comprises: sending the amount specified by the second entity to the first entity; and A confirmation is received from the first entity indicating that the first entity has received the amount.

13. The non-transitory computer readable medium of claim 12, wherein: Processing the electronic transaction between the first entity and the second entity comprises: In response to receiving the confirmation from the first entity, a success message is sent to the second entity indicating completion of the electronic transaction.

14. A system comprising: one or more processors; as well as One or more non-transitory computer-readable media storing instructions that, in response to being executed by the one or more processors, cause the system to perform or control the performance of one or more operations, including: receiving a quick response (QR) code from a user computing device, wherein the QR code includes a first entity identifier of a first entity, and wherein the QR code received from the user computing device was generated by the user computing device; analyzing the QR code to determine that the QR code corresponds to a request to initiate an electronic transaction between the first entity and a second entity; determining a first set of characteristics associated with the electronic transaction; determining a second set of characteristics corresponding to the user computing device, wherein the second set of characteristics includes a geographic location of the user computing device; Based on the first set of features and the second set of features, identifying a first QR code processing flow for the electronic transaction from a plurality of QR code processing flows; and In response to verifying that the QR code is valid, processing the electronic transaction between the first entity and the second entity according to the first QR code processing flow.

15. The system of claim 14, wherein: The first entity is a user, and the second entity is a merchant corresponding to a physical store.

16. The system of claim 15, wherein: The first set of characteristics associated with the electronic transaction includes a transaction amount.

17. The system of claim 15, wherein: Authenticating the first entity is further based on verifying a geographic location of the user computing device included in the second set of characteristics.

18. The system of claim 14, wherein: Processing the electronic transaction between the first entity and the second entity comprises: sending the amount specified by the second entity to the first entity; receiving a confirmation from the first entity indicating that the first entity has received the amount; and In response to receiving the confirmation from the first entity, a success message is sent to the second entity indicating completion of the electronic transaction.

19. The system of claim 14, wherein: Determining the first set of characteristics associated with the electronic transaction includes determining that the QR code is a dynamic QR code unique to the electronic transaction.

20. The system of claim 14, wherein: Processing the electronic transaction is further performed in response to authenticating the first principal based on the first entity identifier.

Images