COMPUTING DEVICES FOR ACTION PRECONDITION FULFILLMENT

Disclosed in some examples are methods, systems, devices and machine readable mediums for behavior modification through the use of computing devices of the user to fulfill tasks that are designated by the user as preconditions to certain actions. These actions involve one or more computing devices for their achievement. Tasks are completed using one or more applications on the computing device of the user. Once the task is completed, the action is allowed

TECHNICAL FIELD

Embodiments pertain to computing devices for fulfilling action preconditions. Some embodiments relate to computing devices for fulfilling action preconditions for actions involving other computer systems.

BACKGROUND

Mobile devices are becoming more and more ubiquitous as the capabilities of these devices increase. Mobile devices are now capable of executing very advanced software applications and are capable of communicating with many other computing devices using wireless technologies such as cellular, Wireless Local Area Networks (WLAN), BLUETOOTH®, Near Field Communications (NFC), and the like. Indeed, many mobile devices may simultaneously communicate using several of these technologies.

DETAILED DESCRIPTION

The ubiquitous natures of computing devices and computer networks (such as the Internet) as well as easy access to credit cards have decreased barriers to spending. For example, consumers used to have to have physically drive to a store and use money in the form of cash to make a purchase. But now they can easily purchase goods or services from their homes with a click of a button using widely available credit. As a result, it becomes extremely easy for a user to purchase outside of their budget, make transactions over self-imposed limits, and difficult for them to control their own behavior.

Disclosed in some examples are methods, systems, devices and machine readable mediums for behavior modification through the use of computing devices of the user to fulfill tasks that are designated by the user as preconditions to certain actions. One example action is completing a purchase—prior to completing a purchase, a user must complete a task such as using an application on their mobile device for a predetermined period of time (e.g., playing a game for 5 minutes). The task may be otherwise unrelated to the action normally. For example, the action may not be related to a computer-based gaming task. Once the task is completed, the transaction is allowed. The use of a distracting task prior to completion of an action (such as a transaction) adds additional hurdles to what otherwise would be a painless (and even rewarding) action. It thus provides users with an opportunity (while working on satisfying the condition) to change their mind and provides a mental barrier to wanting to engage in certain actions in the first place.

While the specification herein uses a transaction such as a purchase as one example of an action with a precondition, one of ordinary skill will understand that the systems, methods, and machine readable mediums described herein can be used with other actions as well. For example, a user may wish to eat healthier. In these examples, the action may be the purchase of certain foods. In other examples, users may wish to reduce the amount of certain media they consume (e.g., online gaming). In these examples, the precondition task may be a certain amount of exercise.

As used herein, actions are behaviors that utilize computer systems (e.g., action authorization computing devices) for their achievement. For example, a payment transaction using a credit card for payment may involve messaging between a merchant computer system, an acquirer computer system (e.g., the merchant's bank), a card network computer system, an issuer's computer system, and the like to approve and fund the transaction. Tasks that are preconditions to actions are tasks that must be satisfied for an action to be allowed by the computer systems. Tasks that are preconditions to actions are capable of being monitored by, or achieved with, a computing device of the user (which may, or may not be a computer system that participates in the action). Thus performing a task by a computing device of a user may be a condition precedent to the processing of an action on other, external, computer systems.

Prior to completion of the task, the action may be blocked by one of the computing devices participating in the action until an indication is received that the task was completed from the computing device of the user. In some examples, these computer devices may be acquirer computer systems, issuer computer systems, merchant computer systems, card network computer systems, and the like. In other examples, the action may be blocked by the computing device of the user—e.g., the user may be trying to complete a transaction via a mobile wallet application on the computing device of the user. In these examples, the mobile wallet application may be blocked from passing payment details to the merchant or other computing device until the task is complete.

Monitoring the completion of a task may be accomplished by use of a task monitoring module on a computing device (e.g., a mobile device) of the user. The task monitoring module communicates fulfillment or non-fulfillment of the task to one or more computing devices that are participating in the action (e.g., a credit card server, a mobile wallet on the computing device, or the like) to allow the action.

Tasks are interactions with a computerized device of the user, such as utilizing an application on the mobile device (e.g., playing a game), performing a physical action (e.g., raising the mobile device over the user's head a predetermined number of times), and the like. In some examples, when the task relates to utilizing an application on the mobile device, the task may involve reaching a predetermined objective or state of the application. Examples include using the application for a predetermined period of time, completing an objective in the application (such as reaching a particular level or goal), or the like. Task completion may be required to be within a predetermined temporal proximity to the desired action to constitute satisfaction of the task precondition for the action. For example, the task may be required to be completed 10 minutes before, or 10 minutes after (e.g., a 20 minute window) of initiation of the action.

Task preconditions, as used herein, do not include the normal activities necessary for engaging in the action. For example, in engaging in a transaction, normal actions necessary for engaging in the action include navigating to a merchant's website, clicking on icons/graphics within that site, entering payment information, messaging between various computer systems to approve the transaction and transfer payment, and the like. In the case of a physical merchant, normal actions necessary for engaging in the transaction including bringing products to the checkout counter, scanning the items, handing over or transmitting payment information, messaging between various computer systems to approve the transaction and transfer payment, and the like, signing a slip, and the like.

Turning now toFIG. 1, a schematic of a system1000for operation of computing devices for precondition task fulfillment is shown according to some examples of the present disclosure. InFIG. 1, the action is a purchase transaction. Users may initiate a transaction manually (e.g., provide a credit card), or utilize computing device1010(e.g., a mobile device) to initiate a transaction. For example, computing device1010may communicate with a merchant computing device1020, such as a point of sale device (POS), e-commerce server, or the like to provide payment information of the user for a transaction to a merchant computing system. Merchant computing device1020may communicate with action authorization computing device1030(such as a payment processing computer such as a credit card issuer or acquirer system) to authorize the transaction. For example, the merchant system1020may send the payment information received from the user or received from the user's computing device1010through network1040to action authorization computing device1030for authorization to proceed with the payment.

In some examples, action authorization computing device1030may include or be communicatively coupled to a database1045. Database1045may store one or more user profiles. These profiles may include information about one or more users. This profile information may include payment information, demographic information, financial information (e.g., balances, payments, spending habits) and the like. Additionally, this profile information may contain information about any user specified preconditions for actions. For example, a precondition task table1050which shows actions in one column and corresponding tasks required to perform the action in a second column. Thus, for example, a transaction that is over $15.00 but less than $30.00 requires that the user use or otherwise interact with an application with a particular identifier (e.g., task id 25).

Precondition tasks may be static—that is, each action of a particular type (e.g., a payment, a withdrawal, a transfer) may require the same task. Precondition tasks may vary depending on the type—that is, a payment may require a different task than a withdrawal. In other examples, within action types, various task levels may be defined which change based upon the details of the action. For example, as shown inFIG. 1, tasks may become more difficult as the dollar value of the transaction increases. Precondition tasks may thus depend on action information (e.g., payment amount). In additional, the precondition task may vary based on past action history or financial information. For example, a user may wish to increase a task difficulty based upon on a total amount spent, a budgeted amount remaining, or the like. For example, as a particular transaction category (e.g., food, utility bills, gas, entertainment) nears or exceeds a budgeted amount, a task may be added, or may become more difficult to meet. In some examples, multiple tasks may be required prior to an action. The budgeted amount as well as task difficulty thresholds may be specified by a user when establishing the precondition task table1050.

Upon receiving a request to approve an action, action authorization computing device1030checks to determine if the user has completed a task required for the approval of that action by consulting the precondition task table1050. If a precondition task is established for the action, the authorization server determines if the task has been completed. For example, the user's computing device1010may communicate completion of the task to the authorization server1030. This communication may be directly (e.g., through a computer network) or through the merchant computing device1020. If the task was satisfied within a predetermined temporal limit, the action authorization computing device1030may authorize the action (assuming other conditions necessary for the action are met—such as sufficient credit). For example, the action authorization computing device1030may request an indication of whether or not the task was completed from the computing device1010. In some examples, the request triggers the computing device1010to prompt the user to perform the task. For example, a GUI may be displayed which may prompt the user to “play 5 minutes of the game GalaxyZoomer to unlock this transaction.” In some examples, the user may have already completed the task prior to the initiating the transaction. Task completion may be bounded by a temporal window. For example, the task may be required to be completed within a temporal window of 15 minutes before to 15 minutes after the initiation of the transaction.

To setup which actions correspond to which preconditions, users may setup an account with the action authorization computing device1030or with another computing device that is communicatively coupled to the database1045. The action authorization computing device1030may provide one or more graphical user interfaces (GUI) to provide users the ability to sign up for, view, edit, delete, and otherwise modify the actions and associated precondition tasks. The GUIs may be provided by the action authorization computing device1030upon request to computing devices (such as computing device1010) of the user through one or more GUI descriptors. GUI descriptors may include one or more files which are renderable by a general rendering application, such as a browser application, or by a specialty application (e.g., such as an application designed to implement the functionality described herein) to provide a GUI. Example GUI descriptors include HyperText Markup Language (HTML) files, eXtensible Markup Language (XML) files, JavaScript files, scripting files, Content Style Sheets (CSS), and the like. In other examples, GUI descriptors may provide information which is used by a dedicated application on the computing device of the user1010to create one or more GUIs. In some examples, other computing devices other than the action authorization computing device1030may setup and manage user profiles and accounts. GUIs may allow users to sign up, set precondition tasks for various actions, delete preconditions, and the like.

While the example ofFIG. 1showed an action authorization computing device1030implementing the precondition task checking, in other examples, where the action utilizes the computing device1010, the computing device1010may implement the precondition task checking. For example, the user may wish to utilize a payment item in a mobile wallet application on the computing device1010to pay for the transaction. In these examples, the mobile device1010may store or have access to the precondition task table1050of the user (either the only copy or a copy). The mobile device1010may then verify if and when the task was completed and allow access to, or deny access to, the mobile wallet for use in paying. In some examples, both the action authorization computing device1030and the mobile device1010may have access to the precondition task table1050(or a portion of it). For example, the precondition task table1050accessed by the action authorization computing device1030may specify precondition tasks for actions relevant to purchases made with traditional payment devices (e.g., physical credit cards) and the precondition task table1050accessed by the mobile device1010may specify precondition tasks for actions relevant to purchases made with mobile wallet applications or other mobile payment forms.

Computing device1010(shown as a mobile device) may track user completion of tasks, provide functionality necessary to complete the tasks (e.g., execute one or more applications), prompt users to complete tasks, allow users to pay using one or more mobile wallet applications, and the like. In examples in which the mobile device includes the precondition task table1050and determines whether the tasks were completed, the mobile device1010may have a dedicated application which may perform the functions of creating the user profiles (including creating and populating the precondition task table1050), tracking task completions, and authorizing (or declining) access to a mobile wallet or other means for performing the action (e.g., blocking access to certain websites prior to completing a task).

In some examples, rather than controlling action completion through controlling access to applications and functionality on the mobile device1010itself, the dedicated application on the mobile device1010may ensure precondition task fulfillment by communicating with external computing devices. For example, the mobile device1010may communicate with the authorization server1030and may indicate that precondition tasks are enabled (authorization server1030may not know the preconditions). In these examples, the dedicated application will send a message at the time of a transaction to the authorization computing device1030indicating (e.g., yes or no) whether the precondition task (as stored in the mobile device1010) have been completed.

Turning now toFIG. 2, a flowchart of a method2000of determining whether an action precondition is satisfied according to some examples of the present disclosure. The method2000may be performed by either an action authorization computing device (such as a transaction authorization computing device) or a user's computing device depending on the particular embodiment. At operation2010, the computing device determines that the user desires to perform a particular action. For example, purchasing goods or services from a merchant. This determination may be made based upon a message or other communication received from a merchant computer system (in the case that the authorization server is executingFIG. 2) or based upon an input into the computing device of the user (e.g., an attempt to use a digital wallet to pay for a purchase or by clicking “checkout” or an equivalent control on a merchant website).

At operation2020, the computing device retrieves user information. For example, the computing device may retrieve a profile of the user. The user information may be retrieved from storage, either on the device, or by requesting it from another computing device over a network. The user information may include information on whether any precondition tasks are setup for any actions. For example, the information may contain (or contain a reference to) a precondition task table. The computing device may also retrieve financial information (e.g., past amounts spent) for the user if it is necessary to determine whether a precondition task is applicable to an action. The financial information may be retrieved from storage, either on the device, or by requesting it from another computing device over a network.

At operation2030the computing device may determine from the user information if the desired action of the user (as determined by operation2010) has a required task. If the action does not have a precondition task (as that term is used herein), the computer system processes the action normally at operation2040. Processing the action normally may include operations such as transmitting payment information, determining whether to approve the transaction based upon credit limits, fraud detection, allowing access to a mobile wallet, allowing access to one or more websites or web addresses, and the like.

If a precondition task is present, a determination is made whether the task was completed or not. In some examples, the determination may be made by a computing device of the user and (if necessary) communicated to the authorization server. The determination may be made by passively monitoring the computing device of the user, utilizing an Application Programming Interface (API) to query one or more other applications on the mobile device as to the user's status, providing and monitoring the precondition task and the like.

If the precondition is satisfied, then the action may be processed normally at operation2040. In some examples, the system may allow a user a predetermined amount of time to complete the task after the commencement of the method2000. At operation2050, if the task is not completed, the system may wait the predetermined amount of time. If the task is not completed within the predetermined period of time, the action may be refused.

Turning now toFIG. 3, a schematic3000of an action authorization computing device3010used to authorize or perform an action as well as a user computing device3020are shown according to some examples of the present disclosure.FIG. 3features one or more modules. Modules are circuits that are configured so as to provide certain functionality. These circuits may be created by instructions on a computer readable medium that configures general purpose circuitry to perform the provided functionality, or may be specifically created circuits. The functionality for the modules ofFIG. 3is exemplary and other divisions of functionality among the modules shown, or the addition of modules not shown, or the subtraction of modules shown, may be utilized. In some examples the modules as shown inFIG. 3may be distributed across more than a single computing device. Modules are discussed more with respect to the discussion ofFIG. 4.

Action authorization computing device3010may be an example implementation of action authorization computing device1030fromFIG. 1. Action authorization computing device3010may have an action processing module3030which may process the action. For example, the action processing module3030may determine whether a transaction is to be allowed based upon the user's credit limit, unpaid balance, likelihood of fraud, and the like. Action processing module3030may also access a database3060which may store user information (e.g., financial information, demographic information), and may also store precondition task tables. Action processing module3030may check to determine whether the action has a required precondition task and whether that task has been completed and if not may deny the action. If the task has been completed and the action would otherwise be allowed or completed, then the action processing module may allow or complete the action. Example actions include approving transactions (e.g., credit card transactions), allowing access to media (e.g., videos, online gaming, music, television shows), accessing one or more applications, allowing access to one or more communications programs (e.g., instant messaging, chats, Short Message Services (SMS)), and the like.

Profile management module3040may provide one or more GUIs to user computing devices (such as user computing device3020) to allow users to setup profiles, manage profiles, delete profiles, and otherwise manipulate their profiles. This includes entering, modifying, editing, deleting, creating, or otherwise changing precondition tasks and specifying actions for those precondition tasks. The GUIs may be provided via one or more GUI descriptors. The profile and the precondition tasks may be saved in the database3060. Database3060may be part of the action authorization computing device3010or may be separate, but communicatively coupled through one or more computer networks. Precondition manager3050may communicate with the user computing device3020to determine whether a precondition task has been completed. Precondition manager may inform action processing module3030upon completion of the precondition task.

User computing device3020includes one or more applications3070. Applications3070may be assigned application identifiers (IDs) which may be utilized to specify application related tasks in the precondition task tables. Applications include games, productivity applications, sensor applications (e.g., GPS sensors, motion sensors, and the like), communication applications, operating system applications, and the like. Applications may be off-the-shelf applications that are not created specifically to serve as a precondition to an action. In other examples, applications may be specially created to serve as a precondition to an action.

In some examples in the user computing device3020may have a task monitoring module3080which monitors applications3070for precondition task achievement. Applications3070may be monitored for task completion continuously or monitored temporally proximate an action. Applications may be monitored through indirect monitoring (e.g., querying an operating system of the user computing device3020about task execution (including execution time, input focus to ensure the user isn't running the task solely in the background, and the like)), or by directly communicating with the task through an Application Programming Interface (API). Additionally tasks may be monitored based upon the task's communication activities. For example, games with a social networking component may post messages to the social networking service about achievements in the game.

Task completion may be communicated by the task monitoring module3080with an action authorization computing device3010, or in some examples, with other components of the user computing device3020such as action processing module3090.

In examples in which the action is performed (or allowed to proceed) by user computing device (such as unlocking a mobile wallet, allowing website access, or the like once a precondition task has been completed), an action processing module3090in some examples may process at least part of the requested action. For example, the action processing module3090may receive a request to access to a mobile wallet application for engaging in a transaction. The action processing module3090may determine, by accessing database3120, if any task preconditions are present. If the task preconditions are not present, or are completed, then the action processing module3090may allow access to the payment item in the mobile wallet application to pay for the transaction. If task preconditions are present, and are not completed, then the action processing module3090may wait until the temporal time window has elapsed before denying the action. Additionally, once the temporal window has elapsed, the user may attempt again to perform the action. This will result in the resetting of the temporal window and allow a further opportunity for the user to perform the precondition task. In some examples, the action processing module3090will prompt the user to complete the precondition task and in some examples may automatically launch an application from applications3070to allow the user to complete the task.

Database3120may store user information (e.g., financial information, demographic information), and may also store precondition task tables. Database3120may be stored in memory of the user computing device3020or may be external to the user computing device3020but accessible via one or more computer networks.

As with profile management module3040, profile management module3110may provide one or more GUIs to allow users to setup profiles and to enter and manage precondition tasks. The profile and the precondition tasks may be saved in the database3120. Precondition manager3100may communicate with the action authorization computing device3010in some examples to inform the action authorization computing device3010that a precondition task has been completed.

Machine (e.g., computer system)4000may include a hardware processor4002(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory4004and a static memory4006, some or all of which may communicate with each other via an interlink (e.g., bus)4008. The machine4000may further include a display unit4010, an alphanumeric input device4012(e.g., a keyboard), and a user interface (UI) navigation device4014(e.g., a mouse). In an example, the display unit4010, input device4012and UI navigation device4014may be a touch screen display. The machine4000may additionally include a storage device (e.g., drive unit)4016, a signal generation device4018(e.g., a speaker), a network interface device4020, and one or more sensors4021, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine4000may include an output controller4028, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared(IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The storage device4016may include a machine readable medium4022on which is stored one or more sets of data structures or instructions4024(e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions4024may also reside, completely or at least partially, within the main memory4004, within static memory4006, or within the hardware processor4002during execution thereof by the machine4000. In an example, one or any combination of the hardware processor4002, the main memory4004, the static memory4006, or the storage device4016may constitute machine readable media.

While the machine readable medium4022is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions4024.