Systems, devices and methods for digital payments

Abstract

The payment server for user transaction approval is configured to: receive two or more rule sets for user transaction approval from the two or more trusted entities; receive a transaction approval request, a token, payment terminal data, and additional data obtained by the payment terminal from a payment terminal; receive a balance limit decision from at least one payment account; and generate a transaction approval decision by cross-referencing the two or more rule sets with the mobile device data, the payment terminal data, the additional data, and the balance limit decision.

Description

[Technical field]

[0001] Some embodiments described herein relate generally to payment systems and methods, and more specifically to digital payments over a digital network. [Background technology]

[0002] Digital payment systems can enable purchases in virtual stores over the Internet. These systems can use a user's credit card or other payment methods, e.g., Pay Pal, crypto coins, etc., for commercial transactions.

[0003] However, a payment card for an institution, such as a loyalty club, may allow loyalty club members to purchase goods and services only with loyalty club points and / or coupons and only at stores available to loyalty club members (e.g., stores where loyalty club is accepted). The loyalty card may issue a global set of rules for all members. The global set of rules allows loyalty club members to purchase goods and services according to the loyalty club rules.

[0004] Thus, for example, there is a need to provide loyalty club members with flexible capabilities to purchase goods and services. Summary of the Invention

[0005] Embodiments of a payment server and a method for purchasing goods and services are described below by way of example only.

[0006] An embodiment may include a payment server for user transaction approval in communication with two or more trusted entities, at least one payment account associated with a trusted entity among the two or more trusted entities, a payment terminal, and a mobile device, wherein the payment server is configured to: receive two or more rule sets for user transaction approval from the two or more trusted entities; receive a transaction approval request from the payment terminal, the token, the payment terminal data, and additional data obtained by the payment terminal; receive an available balance from the at least one payment account and generate a balance limit decision selected from approving, partially approving, and rejecting the transaction approval request based on the available balance; send a request for mobile device data from the mobile device and receive the mobile device data; and generate the transaction approval decision by cross-referencing the two or more rule sets with the mobile device data, the payment terminal data, the additional data, and the balance limit decision.

[0007] For example, the mobile device data includes a history log configured to store past event data recorded by the mobile device.

[0008] For example, the mobile device data may further include data obtained in real time from at least one of a plurality of input elements operably coupled to the mobile device, including a camera, a microphone, a touch screen, an internal motion sensor, an odor sensor, a fingerprint reader, and a Global Positioning System (GPS) receiver.

[0009] For example, additional data obtained by the payment terminal may include the product identification (ID) for which the transaction is being made.

[0010] The payment server of claim 1 is configured such that a trusted entity of the two or more trusted entities receives an indication of an activation of a rule of the two or more rules.

[0011] For example, the payment server may be configured to report to the mobile device that a payment request has been denied based on activation of a rule in one or more rule sets.

[0012] For example, the activation of a rule in a rule set causes another rule to be activated.

[0013] For example, the token is not related to a physical payment card.

[0014] For example, the token contains user data arranged according to the Europay, Visa, Mastercard (EVM) standard.

[0015] For example, the tokens may be one-time use tokens and may be uploaded with a zero profit amount.

[0016] For example, the token may be incorporated into a digital wallet application software development kit (SDK), and the payment terminal may be configured to receive the digital payment token data from a mobile device that includes the SDK.

[0017] For example, the SDK includes a digital wallet application.

[0018] For example, a trusted entity may be verified by a payment server according to a set of rules and marked as trusted.

[0019] For example, the two or more rule sets include a first rule set provided by a payment server, a second rule set provided by a business group, a third rule set provided by a payment token issuer, and a fourth rule set provided by a client of the business group.

[0020] Another embodiment is In step 1, checking whether a transaction authorization request is in a state to be approved or partially approved for payment from a selected one of the one or more payment accounts according to two or more rules of a trusted entity of two or more trusted entities associated with the selected payment account and a balance limit determination for the selected payment account; if the transaction authorization request is approved, the method proceeds to step 2; if the transaction authorization request is rejected, the method proceeds to step 3; if the transaction authorization request is partially approved, setting an amount available for payment by the selected payment account as pending approval subject to approval of the remaining amount for payment by another payment account or payment account selected from the two or more payment accounts, and proceeding to step 3 for the remaining amount; The method for approval of a user transaction by a payment server includes, in step 2, conducting a transaction in the amount of the transaction authorization request using a selected payment account or multiple selected payment accounts of the one or more payment accounts via the payment terminal; in step 3, checking whether an alternative payment account is available and if so, proceeding to step 4, and if not, proceeding to step 5; in step 4, setting the alternative payment account as the selected payment account for paying the full amount or remaining amount of the transaction authorization request and proceeding to step 1 for approval of the full amount or remaining amount of the transaction authorization request; and in step 5, rejecting the transaction via the payment terminal if the payment request in step 3 is rejected by all of the at least two other payment accounts.

[0021] Yet another embodiment may include a method for approval of a user transaction by a payment server including checking whether a transaction authorization request is in a state to be approved or partially approved for payment by a selected one of the one or more payment accounts based on two or more rules of a trusted entity of two or more trusted entities associated with the selected payment account and a balance limit determination for the selected payment account, making a transaction of the requested payment amount via a payment terminal to the selected one of the one or more payment accounts, setting an alternative payment account as the selected payment account for paying the requested payment amount or partial payment amount of a remaining payment amount of the requested payment amount, repeating the check, and repeating the check, performing, and setting regarding approval of the requested payment amount or remaining payment amount of the two or more trusted entities.

[0022] For example, when a check as to whether a transaction authorization request for payment from a selected one of one or more payment accounts is in an approved or partially approved state fails and the payment request is rejected, an alternative payment account is set as the selected payment account.

[0023] For example, when a payment request is partially approved, the method may: The payment account is configured to set the amount payable by the selected payment account as pending authorization, subject to authorization of the remaining amount for the payment by another account selected from the two or more payment accounts, and to set the alternative payment account as the selected payment account for paying the remaining amount of the payment.

[0024] For example, when an alternate payment account is available for payment, the alternate payment account is set as the selected payment account for payment of the requested amount or a portion of the remaining amount of the payment request.

[0025] For example, declining a transaction via a payment terminal when an alternative payment account is not available for payment.

[0026] For example, the method includes denying the transaction via the payment terminal when the payment request is denied by the at least one other payment account.

[0027] It will be appreciated from the present disclosure that solutions to shortcomings in the art are described. More specifically, the embodiments described herein enable payments to be made by members of a loyalty club through the use of disposable payment elements. [Brief description of the drawings]

[0028] [Figure 1] FIG. 1 is a block diagram of a system for making payments over a network, according to some demonstrative embodiments. [Diagram 2] 1 is a flowchart of a method for purchasing goods and services using a digital payment token, according to some example embodiments. [Diagram 3] 1 is a block diagram of a dynamic rule set system according to some example embodiments. [Figure 4] FIG. 1 is a block diagram of a dynamic rule set system according to some other example embodiments. [Diagram 5] 1 is an article of manufacture, according to some illustrative embodiments. [Figure 6] 1 is another embodiment of a payment system, according to some other exemplary embodiments. [Figure 7] A payment system comprising a rule generator and a sensor controlled by the rules and configured to interact with a user. [Figure 8] 1 is a flowchart of a payment system and method according to some other example embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of some embodiments. However, it will be understood by those skilled in the art that some embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, units, and / or circuits have not been described in detail so as not to obscure the description.

[0030] For example, descriptions provided herein utilizing terms such as "processing," "computing," "calculating," "determining," "establishing," "analyzing," "checking," and the like, may refer to operations and / or processes of a computer, computing platform, computing system, or other electronic computing device that manipulates and / or converts data represented as physical (e.g., electronic) quantities in the computer's registers and / or memory into other data that is similarly represented as physical quantities in the computer's registers and / or memory, or other information storage medium capable of storing operating and / or processing instructions.

[0031] The term "plurality" as used herein includes, for example, "a plurality" or "two or more." For example, "a plurality of items" includes two or more items.

[0032] References to "one embodiment," "an embodiment," "exemplary embodiment," "various embodiments," and the like indicate that the described embodiment includes a particular feature, structure, or characteristic, but not all embodiments necessarily include the particular feature, structure, or characteristic. Moreover, repeated use of the phrase "in one embodiment" does not necessarily refer to the same embodiment, but may.

[0033] As used herein, unless otherwise specified, the use of ordinal adjectives such as "first," "second," "third," etc. to describe a common object merely indicates that different instances of a similar object are being referred to, and does not imply that the objects so described must be in a particular order, temporally, spatially, sequentially, or in any other manner.

[0034] As used herein, the term "circuitry" may refer to or include portions of an application specific integrated circuit (ASIC), integrated circuit, electronic circuit, processor (shared, dedicated, or group), and / or memory (shared, dedicated, or group) that executes one or more software or firmware programs, combinatorial logic circuits, and / or other suitable hardware components that provide the described functionality. In some exemplary embodiments, a circuit may be implemented, or functionality associated with a circuit may be implemented, by one or more software or firmware modules. In some exemplary embodiments, a circuit may include logic operable at least in part in hardware.

[0035] The term "logic" may refer to, for example, computational logic embedded in a circuit of a computing device and / or computational logic stored in a memory of a computing device. For example, the logic may be accessible by a processor of the computing device, which may execute the computational logic to perform computing functions and operations. In an example, the logic may be embedded in various types of memory and / or firmware, such as various chips and / or silicon blocks of a processor. The logic may be included and / or implemented as part of various circuits, such as radio circuits, receiving circuits, control circuits, transmitting circuits, transceiver circuits, processor circuits, etc. In an example, the logic may be embedded in volatile and / or non-volatile memory, including random access memory, read-only memory, programmable memory, magnetic memory, flash memory, persistent memory, etc. The logic may be executed by one or more processors, for example, using memory, such as, for example, registers, stacks, and / or buffers, coupled to the one or more processors necessary to execute the logic.

[0036] As used hereinafter, the term "module" is an object file that contains code that extends the running kernel environment.

[0037] The term "EMV" as used below is a payment method based on a technology standard for smart payment cards, payment terminals and automated teller machines. EMV originally represented the three companies that created the global payment standard: Europay, Mastercard and Visa.

[0038] The term "EMV terminal" as used hereinafter is a payment terminal also known as a Point of Sale (POS) terminal, credit card terminal, etc. An EMV terminal is a device that interfaces with payment cards, e.g., Europay, Mastercard, and Visa, to effect electronic funds transfers. The terminal consists, among other things, of a secure keypad for entering a PIN, a screen, a means for capturing information from the payment card, and a network connection for accessing the payment network for authentication.

[0039] In some exemplary embodiments, the payment terminal may allow a merchant to capture requested credit and / or debit card information, transmit this data to a merchant service provider and / or bank for authorization, and send funds to the merchant. The terminal may allow a merchant and / or its client to swipe, insert, and / or hold a card near the device to capture the information.

[0040] As used hereinafter, the term "issuer module" includes software, e.g., Mastercard, Visa, Europay, American Express, etc., configured to issue payment tokens that are configured to act as payment cards, e.g., credit cards, debit cards, charge cards, etc.

[0041] The term "card" as used hereinafter may include, for example, a prepaid card, a credit card, or a debit card created and issued by an issuer.

[0042] As used hereinafter, a "mobile application" may include at least one application installed on a mobile device, such as a loyalty club application or an e-Wallet application. The mobile application may include a digital wallet SDK and may interact with a digital wallet platform and a customer platform. The customer mobile application may be configured to run on a mobile device operating system, such as iOS and Android, or React.

[0043] The term "payment token" as used hereinafter may include a unique placeholder called a payment token that is configured to contain encrypted information of a user's payment capabilities, such as, for example, a credit card, a debit card, a prepaid card, a reloadable prepaid card, or bank transfer information. In some exemplary embodiments, the payment token may be configured to access, obtain, and hold, for example, a customer's credit card information, which may establish a higher level of security for both the customer and the business. The payment token may be stored on the customer platform and / or on the customer's mobile application.

[0044] Reference is first made to FIG. 1, which illustrates a block diagram of a system 100 for effecting payments, according to some exemplary embodiments.

[0045] In some demonstrative embodiments, the system 100 may include a payment server 110, a computing device 120, a payment terminal 130, and a payment server 140. For example, the payment server 110 may include a processing circuit 111, a group token database 112, an issuer module 113, a payment approval module 115, and a rules module 116.

[0046] In some example embodiments, the processing circuitry 111 may include circuitry, logic, memory, an operating system, one or more core computers, graphic processors, digital signal processors, or the like.

[0047] In some demonstrative embodiments, the payment server 110 may include one or more group token databases 112. The one or more group token databases 112 may also include and / or store one or more tokens for one or more business groups, e.g., a group database in the one or more group token databases 112 may each include one or more payment tokens for one or more clients, e.g., payment tokens 135. For example, a business group may include a loyalty club, a company, an organization, etc.

[0048] In some exemplary embodiments, the digital payment token 135 may include user data arranged according to the Europay, Visa, Mastercard (EVM) standard. The digital payment token 135 may also be referred to as a digital EVM token.

[0049] In some exemplary embodiments, the digital payment token 135 may be uploaded with zero return.

[0050] In some exemplary embodiments, the digital payment token 135 may be a one-time use token. For example, a digital payment token may be used for one merchant.

[0051] In some other exemplary embodiments, the lifespan of a digital payment token 135 may be limited to a predetermined amount of time, for example, the digital payment token may only be used for one month, and / or for a predetermined number of purchases, etc.

[0052] In some demonstrative embodiments, the issuer module 113 may be configured to issue to each client a digital payment token 135. For example, the issuer module 113 may issue the digital payment token 135 with data according to the EMV standard.

[0053] In some exemplary embodiments, the payment module 114 can be configured to transfer the requested profit amount to the merchant account and update the business group account and the client account.

[0054] In some exemplary embodiments, benefits may include loyalty club points, loyalty club coupons, any amount of money and / or credits, cryptocurrencies, and other available payment currencies.

[0055] In some example embodiments, the rules module 116 may be configured to store one or more dynamic rules sets. For example, the dynamic rules sets may include a first rule set provided by a payment server, a second rule set provided by a client of the payment server, a third rule set provided by a payment card server, and a fourth rule set provided by a user.

[0056] In some example embodiments, the rules of the dynamic rule set may include Boolean scripts configured to be executed by the payment server 110 .

[0057] In some demonstrative embodiments, the rules module 116 may be configured to store scripts of Boolean rules for one or more different entities, such as, for example, payment server rules, loyalty club rules, personal rules, bank rules, general rules, etc.

[0058] In some demonstrative embodiments, the payment authorization module 115 can be configured to receive a payment authorization request, for example, from a payment terminal 130. The payment authorization module 115 can process the request based on one or more rule sets and the payment token holder's account balance. The payment authorization module 115 can send an approval or denial to the payment terminal based on the processing.

[0059] However, it should be understood that in some other embodiments, each of the payment issuer module 113, the payment module 114, the payment approval module 115, and the rules module 116 may be implemented by software and / or hardware and / or a combination of software and hardware.

[0060] In some demonstrative embodiments, the processing circuit 111 may be configured to issue digital payment tokens, e.g., using the issuer module 113, to clients and / or members of a loyalty club, and store the digital payment tokens, e.g., tokens 135 in the group token database 112.

[0061] In some exemplary embodiments, the payment server 110 can be configured to effectuate payments. For example, the communication unit 117 can be configured to receive requests for payments by digital payment tokens, where the digital payment tokens are not associated with physical payment cards. The processing circuitry 111 is configured to process the payment requests according to a dynamic set of rules, where at least some of the rules are generated by a client of the digital payment token.

[0062] In some exemplary embodiments, the processing circuit 111 is configured to send, via the communication unit 117, an approval or rejection response to the payment request based on the processing.

[0063] In some exemplary embodiments, the processing circuit 111 can be configured to receive an authorization request message from the payment terminal 130.

[0064] In some demonstrative embodiments, the computing device 120 may include an application 124. For example, the application may include a software development kit (SDK) 126 that includes a digital payment token, such as, for example, the token 135, and a communication unit 122.

[0065] In some exemplary embodiments, the computing device may be a mobile phone, a tablet, a digital wallet device, a smart watch, a laptop computer, and / or any type of computerized personal and / or mobile device.

[0066] In some exemplary embodiments, the application 124 may be a digital wallet application programmed with an SDK 126. For example, the SDK 126 is specifically designed to communicate with payment tokens issued by the issuer module 113 of the payment server 110. In one implementation, the SDK 126 is configured to delete payment tokens after they have been used and request that new payment tokens be issued and uploaded to the digital wallet application 124.

[0067] In some other embodiments, the SDK 126 may be incorporated into the digital wallet application 124.

[0068] In some demonstrative embodiments, the communications unit 122 may include, for example, a near field communication (NFC) radio that may enable the payment terminal 130 to securely transact digital payment tokens.

[0069] It should be appreciated that the communication unit 122 can include one or more different types of radios, such as a phone radio, a WiFi radio, a 60 GHz radio, RF ID, Bluetooth, etc.

[0070] In some exemplary embodiments, the payment terminal 130 may be configured to effect a payment. The payment terminal 130 may include a communication unit 132, a token reader 134, a processing circuit 136, and an output unit 138.

[0071] In some other embodiments, payment terminal 130 may be referred to as an EMV terminal.

[0072] In some demonstrative embodiments, the communications unit 132 may include a near field communication (NFC) radio, for example, to enable the payment terminal 120 to securely transact digital payment tokens.

[0073] In some demonstrative embodiments, the payment terminal 130 may be configured to effect a payment. For example, the payment terminal 130 may be configured to include a processing circuit 136. The processing circuit 136 may be configured to enable the token reader 134 to receive a request for payment with a digital payment token 135 transmitted by the payment application 124 of the mobile device 120.

[0074] In some exemplary embodiments, the processing circuit 136 can enable the communication unit 132 to forward the payer identification data and the payer account data to the payment server 110 for processing the payment request according to the dynamic rule set. For example, a rule set of the dynamic rule set can be generated by a trusted entity. For example, the rule set can include multiple Boolean rules that are verified and provided as a script to the payment server 110. Furthermore, the dynamic rule set can be continually modified by a rule set provider, e.g., a trusted entity. For example, the trusted entity can be an entity that is verified by the payment server 110 according to the rule set and is marked as, e.g., trusted.

[0075] In some demonstrative embodiments, the payment terminal 130 may receive approval and / or denial of the payment request from the payment server 110 based on processing by the payment server 110 based on a dynamic rule set.

[0076] In some exemplary embodiments, the payment terminal 130 may provide authorization for the transaction at the dialogue unit 130, if desired.

[0077] It should be understood that the communication unit 132 may include one or more different types of radios, such as, for example, a cellular radio, a WiFi radio, a 60 GHz radio, RF ID, Bluetooth, etc.

[0078] In some demonstrative embodiments, the communications unit 132 can be configured to forward the digital payment token data to the payment server 110 for processing the payment request according to a dynamic set of rules, at least some of which are generated by a user of the digital payment token, such as token 135.

[0079] For example, the digital payment token data may include payer identification data and payer account data.

[0080] In some demonstrative embodiments, the communication unit 132 can receive approval or denial of a payment request from the payment server 110, such as the payment approval module 115, based on processing of a dynamic rule set.

[0081] In some demonstrative embodiments, the token reader 134 may be configured to receive requests for payment with a digital payment token, such as token 135, where the digital payment is not associated with a physical payment card.

[0082] In some exemplary embodiments, the token reader 134 may be implemented in software, hardware, and / or a combination of software and hardware.

[0083] In some demonstrative embodiments, the digital payment token may be incorporated into the digital wallet's SDK 126, and the payment terminal 130 may be configured to receive the digital payment token 135 from the mobile device 120 that includes the SDK 126 by contacting the mobile device 120 with the payment terminal 130.

[0084] In some demonstrative embodiments, the processing circuitry 136 can be configured to execute software instructions that can control and / or process data received from the communication unit 132, the token reader 134, and the interaction unit 138.

[0085] In some exemplary embodiments, processing circuitry 136 may include circuitry, logic, memory, an operating system, one or more core computers, graphic processors, digital signal processors, and the like.

[0086] In some exemplary embodiments, the interaction unit 138 can be configured to interact with the digital token holder. For example, the interaction unit 138 can be configured to display an approval transaction, issue a receipt, prompt to enter a code, and / or share merchant data, such as with an email account.

[0087] In some exemplary embodiments, the token reader 134 may be implemented in software, hardware, and / or a combination of software and hardware.

[0088] In some exemplary embodiments, the payment server 110 is configured to forward payments to merchants upon a payment event. The payment server 110 is configured to receive payments from business groups for purchases by one or more clients, for example, monthly, quarterly, when a predefined amount of credit is reached, etc.

[0089] In some demonstrative embodiments, the payment server 110 may be configured to receive payments from a payment network 140 at predetermined time intervals for purchases by one or more clients, where the payment network 140 may include, for example, a bank, a financial institution, a loyalty club, a merchant network, a store, etc.

[0090] In some exemplary embodiments, the payment module 114 can be configured to transfer the requested profit amount to the payment network 140 and update the business group account and the client account.

[0091] Advantageously, the present disclosure can provide a system that supports digital purchases of goods or services without the use of a physical payment card, with benefits granted to the purchaser and controlled by a dynamic rule set. The dynamic rule set can award benefits to the purchaser, convert the benefits into money, provide price limits, set specific dates for purchases, etc. Thus, the dynamic rule set can provide a "smart" purchasing experience and better use of the benefits and / or money.

[0092] Moreover, dynamic rule sets can enable execution of transactions optimized to the financial policies of a business group. For example, a municipality can add a rule that allows it to send a tax return when a transaction is completed. In addition, dynamic rule sets can enable business partners of a trusted entity to add rules that prevent security breaches. For example, rules that prevent alcohol sales in areas observed to have high alcohol fraud and / or rules that limit alcohol sales to certain hours of the day.

[0093] Reference is now made to FIG. 2, which is a schematic diagram of a flow chart of a method 200 for purchasing goods and services using digital payment tokens, according to some exemplary embodiments.

[0094] In some demonstrative embodiments, method 200 may operate on a payment server, e.g., payment server 110 (FIG. 1). Method 200 may begin with receiving (text box 210) a request for a payment from a payment terminal, e.g., payment terminal 130 of FIG. 1, initiated by a digital payment token, e.g., token 135 (FIG. 1). For example, the digital payment, e.g., token 135 (FIG. 1), may not be associated with a physical payment card.

[0095] The method 200 may proceed with the payment request according to a dynamic rule set (text box 220). For example, the dynamic rule set may include at least one of a first rule set provided by a payment server, a second rule set provided by a business group, a third rule set provided by a payment card server, a fourth rule set provided by a client of the business group, and / or at least some rules generated by a user of the digital payment token.

[0096] In some exemplary embodiments, method 200 may proceed to send an approval or denial response to the payment request to the payment terminal (text box 230). For example, approval or denial may be based on transaction. If the request is approved (diamond 240), the payment server may transfer the requested profit amount to the merchant account (text box 250) and update the business group account and the client account (text box 260). If the request is not approved (text box 240), the digital payment token is rejected and the purchase transaction is aborted (text box 270).

[0097] Reference is now made to FIG. 3, which is a block diagram illustration of a dynamic rule set system 300, according to some other example embodiments.

[0098] In some exemplary embodiments, the system 300 may be operatively coupled to a payment server, such as payment server 110 (FIG. 1).

[0099] In some example embodiments, the system 300 may include the rule module 116 of Figure 1. The rule module 116 may be configured to receive multiple rule scripts that may be dynamically generated at different resources.

[0100] For example, the rules module 116 can be configured to receive a payment server rule script 320. The payment server rule script 320 can be dynamically generated by a payment server rule generator 310. For example, the payment server rule generator 310 can be located on the payment server 110. The payment server rule generator 310 can be implemented by hardware or software or as any combination of hardware and software.

[0101] For example, the rules module 116 can be configured to receive a client rule script 360. The client rule script 360 can be dynamically generated by a client rule generator 350. For example, the client rule generator 350 can be located at the payment server 110. The client rule generator 350 can be implemented by hardware or software or any combination of hardware and software.

[0102] For example, the rules module 116 can be configured to receive a payment card rules script 370. The payment card rules script 370 can be dynamically generated by a payment card rules generator 380. For example, the payment card rules generator 380 can be located on the payment server 110. The payment card rules generator 380 can be implemented by hardware or software or any combination of hardware and software.

[0103] Reference is now made to FIG. 4, which illustrates a dynamic rule set system 400, according to some other example embodiments.

[0104] In some other exemplary embodiments, system 400 may include a rules server 410. For example, rules server 410 may receive rules sets from different entities, such as trusted entities. For example, rules sets may be received from a customer rules server 412, a loyalty club rules server 414, a service provider rules server 416, a credit card issuer rules server 418, a payment entity rules server 420, a municipal rules server 422, a client rules server 430, etc.

[0105] In operation, the token 460 can be downloaded to an application 440 (e.g., a digital wallet application). A client 430 can make a purchase using the application 440 by transmitting the token 462 data and client data to a payment terminal at a Point of Sale (POS) 450. The payment terminal 450 can transmit an authorization request 470 to the rules server 410. For example, the payment request may include the token 462 data, store data, payment terminal data, the type of purchase, the type of goods and / or services, the amount of money to be paid, etc.

[0106] In some exemplary embodiments, the rules server 410 can process the request according to a dynamic set of rules. For example, the rules server can perform a cross-check to ensure that the token is only used in this particular purchase and not simultaneously used in another POS. Based on the cross-check and other rules, the rules server 410 can approve and / or deny the purchase. The rules server 410 can send a replay 480 to the payment terminal 450.

[0107] In some exemplary embodiments, the payment terminal may be a payment application embedded in a web page, such as a POS.

[0108] It should be understood that the above are merely examples and that other rules may apply.

[0109] In some example embodiments, a trusted entity can be configured to receive instructions regarding the activation of rules in a dynamic rule set. For example, a client 430 can create a rule that allows the purchase of only one type of product. The client 430 can be informed that an attempt to purchase a different type of product was prevented by the rule.

[0110] In some example embodiments, the rules may report to the buyer that the purchase request was denied based on the activation of the rules in the dynamic rule set. For example, the report may include the reason for the denial, e.g., a daily purchase limit was met. The rules server 410 may send an email and / or a digital message, e.g., a text message, SMS, to the buyer.

[0111] In some exemplary embodiments, activation of a rule in a dynamic rule set by rules server 410 may cause activation of another rule. For example, if a payment by digital payment token or the like is rejected (e.g., exceeding a credit limit (bank rule)), rules server 410 may activate another rule (e.g., a rule for a credit card company that offers a loan to the buyer). Another example is when a payment by digital payment token or the like is rejected. For example, if a payment by digital payment token or the like is rejected, for example, when a buyer attempts to buy outside of his / her realm, e.g., a loyalty club rule, rules server 410 may activate another rule, for example, a store rule that offers the buyer to purchase a similar product at another branch of the store.

[0112] In some exemplary embodiments, for example, a rule for purchasing a product (eg, a dress, etc.) may enable a promotion for buying an accessory (eg, a belt, etc.).

[0113] Reference is now made to Figure 5, which is a schematic diagram of a product 500, according to some exemplary embodiments. The product 500 may include one or more tangible, computer-readable, non-transitory storage media 510, which may include computer-executable instructions 530 implemented by a processing device 520 operable, when executed by at least one computer processor, to enable at least one processing circuit 111 (Figure 1) to implement one or more program instructions for purchasing goods and / or services using a digital payment token based on a dynamic rule set and / or to perform, cause, and / or implement one or more operations, communications, and / or functions described above with reference to Figures 1-3. The phrase "non-transitory, machine-readable medium" is intended to include all computer-readable media, with the sole exception of transitory, propagating signals.

[0114] In some exemplary embodiments, the article 500 and / or the machine-readable storage medium 510 may include one or more types of computer-readable storage media capable of storing data and including volatile memory, non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. For example, the machine-readable storage medium 510 may include any type of memory, such as, for example, RAM, DRAM, ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, hard disk drive (HDD), solid state disk drive (SDD), fusion drive, etc. The computer-readable storage medium may include any suitable medium for downloading or transferring a computer program from a remote computer to a requesting computer, for example, conveyed by a data signal embodied in a carrier wave or other propagated signal over a communications link, such as a modem, wireless or network connection.

[0115] In some demonstrative embodiments, processing device 420 may include logic. Logic may include instructions, data, and / or code that, when executed by a machine, may cause the machine to perform the methods, processes, and / or operations described herein. The machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware, software, firmware, etc.

[0116] In some demonstrative embodiments, the processing device 520 may include or be implemented with software, firmware, software modules, applications, programs, subroutines, instructions, instruction sets, computing code, words, values, symbols, and the like. The instructions 440 may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The instructions may be implemented according to a predefined computer language, means, or syntax to instruct a processor to perform a particular function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language, such as C, C++, C#, Java, Python, BASIC, Mat lab, assembly language, machine code, and the like.

[0117] It should be understood that the system and / or method for making purchases over a network using a disposable payment element has been described above by way of example only, and that other embodiments may be implemented based on the detailed description and claims.

[0118] It should be understood that like numerals in the drawings represent like elements throughout the several views, and that not all components and / or steps described with reference to and illustrated in the figures are required for all embodiments and / or configurations.

[0119] It should also be understood that embodiments, implementations, and / or arrangements of the systems and methods disclosed herein may be embodied as software algorithms, applications, programs, modules, or code present on hardware, firmware, and / or computer usable media (including software modules and browser plug-ins) that may be executed on a processor of a computer system or computing device to configure the processor and / or other elements to perform the functions and / or operations described herein.

[0120] It will be appreciated that, in accordance with at least one embodiment, one or more computer programs, modules and / or applications that, when executed, perform the methods of the present invention need not reside on a single computer or processor, but can be distributed in a modular manner among a number of different computers or processors to implement various aspects of the systems and methods disclosed herein.

[0121] Thus, illustrative embodiments and arrangements of the present systems and methods provide computer-implemented methods, computer systems, and computer program products for processing code. The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments and arrangements. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions for implementing a specialized logical function.

[0122] Reference is now made to FIG. 6, which illustrates another embodiment of a payment system 600, according to some exemplary embodiments.

[0123] In an example embodiment, the system 600 may include a payment server for user transaction authorization 620. The server 620 may communicate with two or more trusted entities (e.g., trusted entities 602, 603, 604 and / or 605), at least one payment account (616) associated with the trusted entity (e.g., trusted entity 605 of the two or more trusted entities 602, 603, 604 and / or 605), a payment terminal (606), and a mobile device (613).

[0124] In some example embodiments, the payment server 620 can be configured to receive two or more rule sets for user transaction authorization 607 from two or more trusted entities 602, 603, 604 and / or 605. The payment server 620 can receive a transaction authorization request 628 from the payment terminal 606 along with the token 609, payment terminal data, and additional data 611 obtained by the payment terminal 606. For example, the additional data 611 can include product price, product ID, discounts, store data, promotions, coupons, sales, etc.

[0125] In some exemplary embodiments, the additional data (611) may be obtained by the payment terminal (606) and may include a product identification (ID) (610) for which the transaction is being made.

[0126] In some demonstrative embodiments, the payment server 620 can further receive from the at least one payment account 616 an available balance 625 of said at least one payment account 616 and generate a balance limit decision selected from approval, partial approval, and denial of the transaction authorization request 628 based on the received balance. The payment server 620 can send a request for mobile device data (line 612) to the mobile device 613 and can receive mobile device data 630. For example, the mobile device data 630 can include location data, digital wallet related data, mobile device number, user email address, etc.

[0127] In some example embodiments, the payment server 620 can generate a transaction authorization decision (line 608) by cross-referencing two or more rule sets 607 with the mobile device data 630, the payment terminal data, the additional data 611, and the balance limit decision.

[0128] In some example embodiments, the trusted entity may include a loyalty club 602 that may manage payment accounts 616 for members of the loyalty club. For example, the payment accounts may include loyalty club points, currency, loyalty club currency, etc. For example, the loyalty club 601 may generate a rule set 607 for the member's account and provide the rule set 607 to a payment server.

[0129] In some example embodiments, the trusted entity may include multiple credit card companies 603 that may manage payment accounts for multiple credit card companies 603. For example, the payment accounts may include currency, cryptocurrency, points, etc. For example, the multiple credit card companies 603 may generate rule sets 607 for client accounts and provide the rule sets 607 to the payment server 620.

[0130] In some example embodiments, the trusted entity may include multiple banks 604 that may manage payment accounts 616 for multiple clients. For example, the payment accounts may include currency, cryptocurrency, etc. For example, the multiple banks 604 may generate rule sets 607 for the client accounts and provide the rule sets 607 to the payment server 620.

[0131] In some example embodiments, the trusted entity may include multiple credit card companies 603 that may manage payment accounts 616 for multiple credit card companies 603. For example, the payment accounts may include currency, cryptocurrency, points, etc. For example, the multiple credit card companies 603 may generate rule sets 607 for client accounts and provide the rule sets 607 to the payment server 620.

[0132] In some example embodiments, the trusted entity may include multiple other entities 605 that may manage multiple user payment accounts 616. For example, the payment accounts may include currency, cryptocurrency, points, etc. For example, the multiple other entities 616 may generate rule sets 607 for user accounts and provide the rule sets 607 to the payment server 620. For example, the other entities may include insurance companies, loan banks, mortgage banks, investment companies, financial companies, and any other companies.

[0133] In some demonstrative embodiments, the payment account 616 may be configured to provide the account balance 625 to the payment server 620 .

[0134] In some exemplary embodiments, the mobile device 613 may include a mobile phone, a smartphone, a laptop computer, a tablet, a digital smart watch such as an Apple Watch, or the like.

[0135] In some exemplary embodiments, the payment server 620 may be configured to issue payment cards, such as, for example, EMV credit cards, debit cards, loyalty club cards, etc. The payment server 620 may hold user accounts, such as, for example, bank accounts, which may be connected to personal accounts of users of the payment server 620. Additionally, the payment server 620 may be configured to make payments from multiple user personal accounts. For example, the payment server 620 may provide direct payment for goods and services purchased at a point of sale (POS) and bill users' personal accounts according to a predetermined schedule, such as, for example, once a month.

[0136] In some demonstrative embodiments, payment cards and / or payment tokens issued by the payment server 620 may be used to make payments to all user personal accounts connected to the payment server in accordance with the rule set 607.

[0137] In some demonstrative embodiments, the mobile device data 630 may include a history log 614 that may be configured to store past event data recorded by the mobile device 613 .

[0138] For example, the mobile device data 630 may include data obtained in real time from at least one of a number of input elements 615 operatively connected to the mobile device, which may include, for example, a camera, a microphone, a touch screen, an internal motion sensor, an odor sensor, a fingerprint reader, and a Global Positioning System (GPS) receiver.

[0139] Reference is now made to FIG. 7, which illustrates a payment system 600 configured to be controlled by rules for interacting with a user and a number of input elements, according to some example embodiments.

[0140] In some demonstrative embodiments, the payment system 600 may include a payment terminal 506, a mobile device 613, such as, for example, a smartphone, a rules server 607, and an input element controller 615. For example, the input element controller 615 may be operatively coupled to a number of sensors, such as, for example, a camera 701, a microphone 702, a touch screen 703, an internal motion sensor 704, an odor sensor 705, a fingerprint sensor 706, a global positioning system (GPS) receiver 707, and / or any other sensors.

[0141] In some example implementations, the mobile device data (FIG. 1, 630) may include data obtained in real time from at least one of a number of input elements that may be operatively coupled to the mobile device 613. For example, the number of input elements may include, but is not limited to, a camera 701, a microphone 702, a touch screen 703, a motion sensor 704, an odor sensor 705, a fingerprint reader 706, and a GPS receiver 707.

[0142] In some exemplary embodiments, the system 700 can be configured to approve or deny a payment based on rules that require the payer to authenticate a request for payment made with a payment token (FIG. 6, 609) at the payment terminal 606 by providing required inputs, as described below with the following examples.

[0143] In some demonstrative embodiments, a mobile device 613, such as, for example, a smartphone, can send a request to pay for products and / or services by providing a payment token (line 708) to the payment terminal 606. The payment terminal 606 can request approval of the payment from the rules server 607.

[0144] In some example embodiments, the rules server 607 may include a rule set for the user and may approve and / or deny a payment based on one or more rule sets. For example, a rule may include a request for a payer's voice signature. The rules server 607 may send a request to the mobile device 613 to ask the user to speak into the microphone 702 (line 612). The payer may provide a voice signature (all dotted lines) to the input element controller 615. The input device controller 615 may send the payer's voice signature to the rules server 604 via the mobile device 613.

[0145] In some exemplary embodiments, the rules server 607 can compare the payer's voice signature to a stored voice signature of the payment token holder and can approve or deny the payment based on the comparison. For example, if the payer's voice signature matches the stored voice signature, the rules server can approve the payment and send the payment to the payment terminal 606 (line 708).

[0146] In some exemplary embodiments, the above authentication methods may be implemented in a similar manner for facial recognition, for example by using the camera 701, odor authentication, for example by using the odor sensor 705, motion identification, for example by identifying gestures using the motion sensor 704, a request to press the bottom or a required number, for example using the touch screen 703, a request to read the payer's fingerprint, and / or any other interaction with the payer and / or the cardholder.

[0147] Reference is now made to FIG. 8, which illustrates a flow chart of a payment system and method of payment 800, according to some other exemplary embodiments.

[0148] Reference is now made to FIG. 8, which illustrates a flow chart of a payment system and method, according to some other exemplary embodiments.

[0149] In some exemplary embodiments, a method of payment is described in system 600 of FIG.

[0150] In some exemplary embodiments, the method of approval of a user transaction by the payment server 620 may include the following steps. For example, in stage 1, the payment server 620 may receive a transaction authorization request 821 and check whether the transaction authorization request may be in a state to be approved or partially approved for a payment (diamond 800) from a selected payment account of one or more payment accounts 616 according to two or more rules 607 of two or more trusted entities 602, 603, 604, 605 associated with the selected payment account and a balance limit determination for the selected payment account.

[0151] For example, if the transaction authorization request is approved ("Yes"), the method may proceed to stage 2. If the transaction authorization request is denied ("No"), the method may proceed to stage 3. If the transaction authorization request is partially approved, the payment server 620 may set the amount available for payment by the selected payment account as pending approval, conditional on approval of the remaining amount of the payment by another account selected from the two or more payment accounts, and the method may be configured to proceed to stage 3 with respect to the remaining amount.

[0152] In some exemplary embodiments, in step 2, the method may include transacting (806) the requested payment to the selected payment account via a payment terminal (807).

[0153] In some example embodiments, in stage 3, the payment server 620 may check (diamond 803) whether an alternative payment account is available, such as, for example, the payment account 616 at the bank 604. For example, if "Yes" (line 804), the method may proceed to stage 4, and if "No" (line 808), the method may proceed to stage 5.

[0154] In some demonstrative embodiments, in stage 4, the payment server 620 may set an alternative payment account, such as, for example, the payment account 616 of the bank 604, as the selected payment account for paying the requested amount and / or a partial amount of the remaining amount of the transaction authorization payment request. For example, the method may be configured to proceed to stage 1 upon authorization of the requested amount or partial remaining amount of two or more trusted entities (602, 603, 604, 605).

[0155] For example, in stage 5, if the stage 3 transaction approval request is rejected by all of the at least one other payment accounts (diamond 808), the payment server 620 may reject the transaction via the payment terminal (807) (line 809).

[0156] In another example embodiment, the payment server 620 can be configured to approve the user transaction. For example, the payment server 620 can check whether the transaction authorization request (diamond 800) is in a state to be approved or partially approved for payment from a selected payment account, e.g., payment account 616, of one or more payment accounts, e.g., credit card company 603, based on two or more rules 607 of a trusted entity, e.g., credit card company 603, of two or more trusted entities, e.g., trusted entities 602, 603, 604, 605, associated with the selected payment account, e.g., payment account 616, of the credit card company 603, and a balance limit determination for the selected payment account. The payment server 620 may execute the requested payment transaction (line 806) via the payment terminal 807 to one or more payment accounts, e.g. a selected payment account 616 of the credit card company 603, may set an alternate payment account as the selected payment account for paying the requested amount or partial amount of the remaining amount of the transaction authorization request, and may repeat the checking, executing and setting operations for authorization of the requested amount or partial remaining amount of two or more trusted entities.

[0157] In this embodiment, when the transaction authorization request fails to check whether the payment from one or more payment accounts, such as payment account 616, e.g., credit card company 603, is in a state where it can be approved or partially approved, and the transaction authorization request is rejected ('No' in diamond 800), the payment server 620 can set an alternative payment account as the selected payment account.

[0158] Moreover, when the transaction authorization request is partially approved, the payment server 620 may be configured to set the amount available for payment by the selected payment account as pending approval subject to approval of the remaining amount of the payment by another account selected from the two or more payment accounts, and may set an alternative payment account, such as, for example, account 616 at bank 604, as the selected payment account for paying the remaining amount of the payment.

[0159] In another scenario, when an alternate payment account is available for payment (diamond 803), the payment server can set the alternate payment account, e.g., payment account 616 of the credit card company 603, as the selected account for payment of the requested amount or partial amount of the remaining amount of the payment request. The payment server 620 can deny (line 809) the transaction via the payment terminal (807) when the alternate payment account is not available for payment (803), e.g., deny (809) the payment via the payment terminal (807) when the payment request is denied (808) by the at least one other payment account.

[0160] It should also be noted that in some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed concurrently, depending on the functionality involved, or the blocks may sometimes be executed in the reverse order. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a special-purpose hardware-based system that performs the specified functions or acts, or a combination of special-purpose hardware and computer instructions.

[0161] The terminology used herein describes particular embodiments only and is not intended to limit the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly supports otherwise. The terms "comprise" and / or "comprising" when used in this specification specify the presence of certain features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0162] Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. As used herein, the words "including," "having," "including," "with," and variations thereof are meant to include the items listed thereafter and equivalents thereof, as well as additional items.

[0163] The above content is provided by way of example only and should not be construed as limiting. Various modifications and changes may be made to the content described herein without departing from the spirit and scope of the present invention, as set forth in the following claims, without departing from the following embodiments and application examples shown and described.

[0164] The following examples relate to further embodiments.

[0165] Example 1 includes a payment server configured to execute payments, the payment server including a payment approval module configured to perform the steps of: receiving a request for payment from a payment terminal by means of a digital payment token, the digital payment token not associated with a physical payment card; processing the payment request according to a dynamic rule set, the rule set of the dynamic rule set being generated by a trusted entity and the set of tools including a plurality of Boolean rules validated and provided as a script, the dynamic rule set being continually modified by a rule set provider; and sending an approval or rejection of the payment request based on the processing of the payment request according to the dynamic rule set.

[0166] Example 2 includes the subject matter of Example 1, and optionally, the payment acceptance module is configured to receive a payment request from a payment application embedded in the web page.

[0167] Example 3 includes the subject matter of example 1, where the trusted entity is configured to receive an indication of activation of a rule in the dynamic rule set.

[0168] FIG. 4 includes the content of FIG. 1, where the payment approval module is configured to report to the buyer that the payment request has been denied based on activation of the rules of the dynamic rule set.

[0169] Example 5 includes the subject matter of example 4, wherein notifying the buyer includes sending at least one of an email or a digital message to the buyer.

[0170] FIG. 6 includes the content of FIG. 1, where the activation of a rule in a dynamic rule set causes the activation of another rule.

[0171] FIG. 7 includes the content of FIG. 1, where a trusted entity is an entity that is verified by the payment server according to a set of rules and marked as trusted.

[0172] Example 8 includes the content of example 1, wherein the digital payment token includes user data arranged according to the Europay, Visa, Mastercard (EVM) standard.

[0173] Example 9 includes the content of example 1, where the digital payment token is uploaded with a return of zero.

[0174] Example 10 includes the subject matter of example 1, wherein the digital payment token is a one-time use token.

[0175] Example 11 includes the content of example 1, where the lifetime of the digital payment token is limited to a predetermined time.

[0176] Example 12 includes the content of Example 1, and the dynamic rule sets include a first rule set provided by a payment server, a second rule set provided by a business group, a third rule set provided by a payment card server, and a fourth rule set provided by one or more clients of the business group.

[0177] Example 13 includes the content of Example 12, where the rules of the dynamic rule set include a Boolean script configured to be executed by the payment server.

[0178] Example 14 includes the subject matter of example 1, wherein the digital payment token is incorporated into a software development kit (SDK) of the digital wallet, and the payment terminal is configured to receive the digital payment token from a mobile device that includes the SDK.

[0179] Example 15 includes the content of example 14, and the SDK includes a digital wallet application.

[0180] Example 16 includes the subject matter of example 1, and the payment server includes one or more databases of one or more business groups and a database of the business groups including one or more clients, an issuer module configured to issue digital payment tokens to each user of the clients, and a payment module configured to transfer a requested amount of the benefit amount to a merchant account and update the user account and the client account.

[0181] Example 17 includes the subject matter of example 1, wherein the payment server is configured to forward the payment to a payment network.

[0182] Example 18 includes the subject matter of example 1, wherein the payment server is configured to receive payments from the business group at predetermined intervals for purchases made by one or more clients.

[0183] Example 19 includes the subject matter of example 1, wherein the payment server is configured to receive payments from the payment network at predetermined intervals for purchases made by the one or more clients.

[0184] Example 20 includes an article of manufacture including one or more tangible, computer readable, non-transitory storage media including program instructions for making a payment using a payment program, where execution of the program instructions of the payment program by a processing circuitry receives a request for payment from a payment terminal by a digital payment token, where the digital payment is not associated with a physical payment card, and processes the payment request according to a dynamic rule set, where the rule set of the dynamic rule set is generated by a trusted entity, where the set of rules includes a plurality of Boolean rules that are verified and provided as a script, where the dynamic rule set is continually modified by a rule set provider, and where based on the processing of the payment request, sends an approval or rejection of the payment request according to the dynamic rule set.

[0185] Example 21 includes the subject matter of example 20, and further includes receiving a request for payment from a payment application embedded in a web page by execution of program instructions of a payment program by a processing circuit.

[0186] Example 22 includes the subject matter of example 20, wherein the trusted entity is configured to receive an indication of activation of the dynamic rule set.

[0187] Example 23 includes the subject matter of example 20, where execution of the program instructions of the payment program by the processing circuit reports to the buyer that the payment request was denied based on activation of the rules of the dynamic rule set.

[0188] Example 24 includes the subject matter of example 20, wherein notifying the buyer includes executing program instructions of the payment program by the processing circuitry to send at least one of an email or a digital message to the buyer.

[0189] Example 25 includes the subject matter of example 20, where execution of program instructions of the payment program by the processing circuitry activates a rule of the dynamic rule set that causes another rule to be activated.

[0190] Example 26 includes the subject matter of example 20, where a trusted entity is an entity that has been verified by the payment server according to a rule set and marked as trusted.

[0191] Example 27 includes the subject matter of example 20, wherein the digital payment token includes user data arranged according to the Europay, Visa, Mastercard (EVM) standard.

[0192] Example 28 includes the subject matter of example 20, where the digital payment token is uploaded with a zero return.

[0193] Example 29 includes the content of Example 20, and the dynamic rule sets include a first rule set provided by a payment server, a second rule set provided by a business group, a third rule set provided by a payment card server, and a fourth rule set provided by a client of the business group.

[0194] Example 30 includes the subject matter of example 20, where the rules of the dynamic rule set include a Boolean script configured to be executed by the payment server.

[0195] Example 31 includes the subject matter of example 20, and includes executing a payment instruction of the payment program by the processing circuit to transfer a requested profit amount to a merchant account and update a business group account and a client account.

[0196] Example 32 includes the subject matter of example 20, where execution of the program instructions of the payment program by the processing circuit results in:

[0197] Receiving payments from clients at predetermined time intervals for purchases made by one or more users.

[0198] Example 32 includes the subject matter of example 20, and further includes receiving payments from a payment network at predetermined intervals for purchases made by one or more users of the client by executing program instructions of the payment program by the processing circuit.

[0199] Example 33 includes a payment terminal configured to perform a payment, the payment terminal including a processing circuitry configured to enable a token reader configured to receive a request for payment by a digital payment token sent by a payment application; and a communication unit configured to transmit payer identification data and payer account data to a payment server for processing the payment request according to a dynamic rule set, the rule set of which is generated by a trusted entity, the rule set including a plurality of Boolean rules that are verified and provided to the payment server as a script, the dynamic rule set being continually modified by the rule set provider; and receiving approval or rejection of the payment request from the payment server based on the processing of the request for payment by the payment server based on the dynamic rule set and presenting the approval processing by an interaction unit.

[0200] Example 34 includes the content of Example 33, where the payment application is embedded in a web page.

[0201] Example 35 includes the subject matter of example 33. The trusted entity is configured to receive an indication of activation of a rule in the dynamic rule set.

[0202] Example 36 includes the content of Example 33, where reporting the request for payment to the buyer is denied based on activation of a rule in the dynamic rule set.

[0203] Example 37 includes the subject matter of example 36, wherein notifying the buyer includes sending at least one of an email or a digital message to the buyer.

[0204] 10. The payment terminal of claim 1, wherein activation of a rule in the dynamic rule set causes another rule to be activated.

[0205] Example 38 includes the subject matter of example 33, wherein the digital payment token is not associated with a physical payment card.

[0206] Example 39 includes the content of Example 33, where the trusted entity is an entity that has been verified by the payment server according to the rule set and marked as trusted.

[0207] Example 40 includes the content of example 33, wherein the digital payment token includes user data arranged according to the Europay, Visa, Mastercard (EVM) standard.

[0208] Example 41 includes the subject matter of example 33, except that the digital payment token is updated with a benefit amount of zero.

[0209] Example 42 includes the subject matter of example 33, wherein the digital payment token is a one-time use token.

[0210] Example 43 includes the content of example 33, wherein the lifetime of the digital payment token is limited to a predetermined time.

[0211] Example 44 includes the content of Example 33, and the dynamic rule sets include a first rule set provided by a payment server, a second rule set provided by a business group, a third rule set provided by a payment token issuer, and a fourth rule set provided by a client of the business group.

[0212] Example 45 includes the content of example 33, wherein the rules of the dynamic rule set include a Boolean script configured to be executed by the payment server.

[0213] Example 46 includes the subject matter of example 33, wherein the digital payment token is incorporated into a digital wallet application software development kit (SDK), and the payment terminal is configured to receive digital payment token data from a mobile device that includes the SDK.

[0214] Example 47 includes the content of Example 46, and the SDK includes a digital wallet application.

[0215] Example 48 includes the subject matter of example 33, and the payment server includes a business group database including one or more databases of the one or more business groups and one or more clients, an issuer module configured to issue digital payment tokens to each of the one or more clients, and a payment module configured to transfer a requested profit amount to a merchant account to update the business group account and the client account.

[0216] Example 49 includes the subject matter of example 33, wherein the payment server includes a payment module configured to transfer the requested profit amount to a payment network and update the business group account and the client account.

[0217] Example 50 includes example 33, wherein the payment server is configured to receive payments from the business group at predetermined intervals for purchases made by the one or more clients.

[0218] Example 51 includes the subject matter of example 33, wherein the payment server is configured to receive payments from the payment network at predetermined intervals for purchases made by one or more clients.

[0219] Example 52 includes a payment server operably coupled to two or more trusted entities and a payment terminal, the payment server being configured to: receive a payment request from the payment terminal and a digital payment token including user data from the mobile device to authenticate the payment request; process the payment request by the two or more trusted entities according to a dynamic rule set, the dynamic rule set including a plurality of Boolean rules generated, verified by the two or more entities and provided as a script to the payment server; and provide to the payment server an approval or rejection of the payment request based on the dynamic rule set of a selected one of the two or more trusted entities, the selected trusted entity being operably coupled to a payment account; and, when the payment request is approved, provide payment from one or more payment accounts connected to the two or more trusted entities according to the dynamic rule set.

[0220] The above is provided for illustrative purposes only and should not be construed as limiting. Various modifications and variations can be made to the subject matter described herein without departing from the spirit and scope of the invention as set forth in the following claims.

Claims

1. A payment server (620) for user transaction authorization in communication with two or more trusted entities (601, 602, 603, 604, 605), at least one payment account (616) associated with a trusted entity of the two or more trusted entities, a payment terminal (606), and a mobile device (613), the payment server comprising: receiving two or more rule sets for said user transaction approval (607) from said two or more trusted entities; receiving from said payment terminal a transaction authorization request (628) together with a token (609), payment terminal data, and additional data (611) obtained by said payment terminal (606); receiving an available balance (625) from said at least one payment account (616) and generating a balance limit decision selected from approving, partially approving, and denying said transaction authorization request based on said available balance; Sending a request for mobile device data (612) from said mobile device (613) and receiving said mobile device data (612); generating a transaction authorization decision (608) by cross-referencing the two or more rule sets (607) with the mobile device data (630), the payment terminal data, the additional data (611), and the balance limit decision; A payment server configured to:

2. 2. The payment server of claim 1, wherein the mobile device data (630) includes a history log (614) configured to store past event data recorded by the mobile device.

3. 2. The payment server of claim 1, wherein the mobile device data (630) includes data obtained in real time from at least one of a plurality of input elements (615) operably coupled to the mobile device (613), the plurality of input elements including a camera (701), a microphone (702), a touch screen (703), an internal motion sensor (704), an odor sensor (705), a fingerprint reader (706), and a global positioning system (GPS) receiver (707).

4. The method for the approval of the user transaction by the payment server comprises: In step 1 (800), checking whether the transaction authorization request (628) is in a state to be approved or partially approved for payment from the selected one of the one or more payment accounts (616) according to two or more rules (607) of the trusted entities (602, 603, 604, 605) associated with the selected payment account and a balance limit determination for the selected payment account; if the transaction approval request is approved ("Yes"), proceeding to step 2 of the method; if the transaction approval request is denied ("No"), proceeding to step 3 of the method; if the transaction authorization request is partially approved, setting the amount available for payment by the selected payment account as pending authorization, subject to approval of the remaining amount for payment by another payment account or a payment account selected from the two or more payment accounts, and proceeding to step 2 with respect to the remaining amount; in step 2, effecting a transaction in the amount of the transaction authorization request (806) via the payment terminal (807) with the selected payment account or a plurality of selected payment accounts of the one or more payment accounts; In step 3, checking whether an alternative payment account is available; If it is available (804), proceed to step 4, if it is not available (808), proceed to step 5; in step 4, setting the alternate payment account as the selected payment account for payment of the full or remaining amount of the transaction authorization request, and proceeding to step 1 for approval of the full or remaining amount of the transaction authorization request; in step 5, rejecting said transaction via said payment terminal (807) if the payment request in step 3 is rejected by all of said at least one other payment account (808); The payment server of claim 1 , further comprising:

5. 2. The payment server of claim 1, wherein the additional data (611) obtained by the payment terminal (606) includes a product identification (ID) relating to the product for which the transaction is conducted.

6. The approval of the user transaction by the payment server comprises: checking whether the transaction authorization request (800) is in a state to be approved or partially approved for payment from a selected one of the one or more payment accounts (616) based on the two or more rules (607) of the trusted entities (602, 603, 604, 605) associated with the selected payment account and a balance limit determination for the selected payment account; effecting a transaction of a requested payment amount (806) via said payment terminal (807) into said selected one of said one or more payment accounts; performing a step of setting the alternative payment account as the selected payment account for paying the requested payment amount or the partial payment of the remaining amount of the requested payment amount, and repeating the steps of checking, enforcing and setting for approval of the requested payment amount or the partial remaining amount among the two or more trusted entities; The payment server of claim 1 , comprising:

7. 7. The payment server of claim 6, wherein when the transaction authorization request (800) fails to check whether the one or more payment accounts are in an approved or partially approved state for payment from the selected payment account and the payment request is rejected (802), the payment server sets the alternative payment account as the selected payment account.

8. 7. The payment server of claim 6, wherein when the payment request is partially approved, the method is configured to set the payable amount by the selected payment account as pending approval, conditional on approval of the remaining amount for payment by another account selected from the two or more payment accounts, and set the alternative payment account as the selected payment account for paying the remaining amount for payment.

9. 7. The payment server of claim 6, further comprising: when the alternate payment account is available for payment (803), setting the alternate payment account as the selected payment account for paying the requested amount or a partial amount of the remaining amount of the payment request.

10. 7. The payment server of claim 6, further comprising: a payment server configured to reject a transaction via said payment terminal when said alternate payment account is not available for payment (803).

11. 7. The payment server of claim 6, wherein the method includes rejecting the transaction (809) via the payment terminal (807) when the payment request is rejected by all of the at least one other payment account (808).

12. The payment server of claim 1 , wherein the trusted entity of the two or more trusted entities is configured to receive an indication of an enablement of a rule of the two or more rules.

13. 10. The payment server of claim 1, configured to report to the mobile device that the request for payment has been denied based on activation of a rule in the one or more rule sets.

14. The payment server of claim 1 , wherein the activation of a rule of the rule set causes the activation of another rule.

15. The payment server of claim 1 , wherein the token is not associated with a physical payment card.

16. 2. The payment terminal of claim 1, wherein the token comprises user data arranged according to the Europay, Visa, Mastercard (EVM) standard.

17. The payment terminal of claim 1 , wherein the token is a one-time use token and is uploaded with a benefit amount of zero.

18. 2. The payment server of claim 1, wherein the token is incorporated into a digital wallet application software development kit (SDK), and the payment terminal is configured to receive digital payment token data from a mobile device that includes the SDK.

19. 20. The payment terminal of claim 19, wherein the SDK includes the digital wallet application.

20. The payment server of claim 1 , wherein the trusted entity is an entity that has been verified by the payment server according to the rule set and marked as trusted.

21. 2. The payment server of claim 1, wherein the two or more rule sets include a first rule set provided by the payment server, a second rule set provided by a business group, a third rule set provided by a payment token issuer, and a fourth rule set provided by the client of the business group.

Images