MANAGING DATA TRANSACTIONS

Techniques for managing data transactions are described and are implementable to enable data transactions (e.g., payment transactions) to be automatically generated in response to different conditions. In implementations, user interactions to generate payment transactions are tracked at different locations over different time durations. Accordingly, when payment transactions at a particular location reach a threshold, a data transaction record can be generated. The data transaction record can be used to automatically generate subsequent data transactions. Further, application presence across different devices can be used to generate data transactions.

BACKGROUND

The use of network-based payment systems has become commonplace across the world. For instance, users can pay for a large variety of goods and services using a network-based payment application, such as using a portable device, e.g., a smartphone. While the availability of payment applications can provide a great deal of convenience, it is not without challenges. For instance, a typical payment transaction may involve multiple user interactions and system processes to generate a payment transaction, expose the payment transaction to a user, receive user input to accept or modify the payment transaction, and then attempt to process the payment transaction. Thus, significant system and user resources may be utilized to initiate and resolve a typical payment transaction.

DETAILED DESCRIPTION

Techniques for managing data transactions are described and are implementable to enable data transactions (e.g., payment transactions) to be automatically generated in a variety of different scenarios. For example, various data transaction conditions can be tracked and utilized to automatically generate data transactions.

For instance, consider a scenario where a person regularly visits a particular vendor (e.g., a restaurant) and purchases a particular item and/or similar items. The user, for instance, interacts with a digital payment application on a device (e.g., a smartphone) to specify a transaction amount, a vendor identifier, an item to be purchased, etc. Alternatively or additionally, the user can unlock their device and scan a code (e.g., a QR code) to obtain various transaction parameters for performing a payment transaction. Thus, multiple user and system steps are involved to surface and process the payment transaction.

Accordingly, implementations described herein can track such user and system behaviors to enable payment transactions to be automatically generated and presented to a user, such as with little or no user interaction to generate a payment transaction. For instance, considering the scenario mentioned above, a system can track user behaviors over multiple payment transactions at the vendor and generate a data transaction record that describes attributes of the payment transactions, such as user location, time duration(s) that the user is positioned at the location, payment method(s) utilized for payment transactions, items purchased, etc.

Accordingly, when the user subsequently visits the vendor and remains for a period of time, the system can automatically generate a recommended payment transaction and present the recommended payment transaction to the user via the user's device. The recommended payment transaction, for example, may include a recommended payment amount, recommended purchase item(s), a recommended payment method, etc. Further, the recommended payment transaction may identify a user purchase history at the vendor. Accordingly, the user may interact with the recommended payment transaction to accept the recommendation to automatically initiate a payment transaction, e.g., a transfer of value (e.g., digitally) from the user account to the vendor account.

As another implementation and considering the scenario describe above, consider a first set of instances where the user visits the restaurant for a brief period of time (e.g., less than 10 minutes) to purchase an item on the go, such as to take to eat at work. In a second set of instances, however, the user may visit the restaurant for a sit down meal for an extended period of time, e.g., more than 20 minutes. Further, the first set of instances may be associated with a first transaction amount and the second set of instances may be associated with a second, higher transaction amount.

As yet another example, consider scenarios where a user visits a salon at different instances to receive different services. For instance, in a first set of instances the user may visit the salon to obtain a haircut which typically takes a first amount of time (e.g., around 20 minutes) and has a first transaction amount. In a second set of instances the user may visit the salon to obtain a massage which typically takes a second, longer time duration (e.g., an hour or more) and has a second, higher transaction amount. In these different instances the time spent at the salon can be correlated to different service types and different corresponding recommended transaction amounts.

Thus, implementations described herein can track different time durations of user presence at a location and correlate the different time durations with different transaction amounts. Thus, when the user is present at the location for a time duration, the system can automatically generate and surface a transaction recommendation that includes a transaction amount that is correlated to the time duration. The user can interact with the transaction recommendation to enable a payment transaction to be automatically performed.

Implementations also enable data transactions to be generated and performed based on presence of common applications across different devices. For instance, and in an extension and/or variation on the scenario introduced above, consider that the user visits the vendor carrying their device. Further, the user's device has a payment application installed, and a vendor device (e.g., a point of sale (POS) device) at the vendor also has the payment application installed. Accordingly, the presence of the common application between the user device and the vendor device is detected and thus various transaction recommendations pertaining to the vendor can be automatically presented via the user device. The vendor device, for instance, may transmit a transaction recommendation to the user device, such as a recommended transaction amount, item(s) for purchase, item promotions, item discounts, etc. Thus, the user may interact with the transaction recommendation to accept or decline the transaction recommendation.

Accordingly, techniques described herein enable automated generation and processing of data transactions. In implementations, a payment transaction represents a data transaction. For instance, digital payment transactions involve generating, transmitting, and processing various types of data and across a variety of different systems and networks. Thus, such digital payment transactions can be characterized as sets of computational operations much like other operations of a computing device and/or set of computing devices. Accordingly, by enabling automated generation of data transactions, the described techniques can conserve system resources (e.g., memory, processor bandwidth, network bandwidth, etc.) that may otherwise be used to manually generate data transactions, and thus the described techniques can improve the operation of computing devices and data networks. Further, user burden can be reduced by performing generating data transactions automatically while reducing user interaction to initiate and manage data transactions.

While features and concepts of managing data transactions can be implemented in any number of environments and/or configurations, aspects of the described techniques are described in the context of the following example systems, devices, and methods. Further, the systems, devices, and methods described herein are interchangeable in various ways to provide for a wide variety of implementations and operational scenarios.

FIG.1illustrates an example environment100in which aspects of managing data transactions can be implemented. The environment100includes a client device102, a payment service104, and a transaction service106that are connectable to a network108. The client device102can be implemented in various ways and according to various form factors such as a smartphone, tablet device, a laptop computer, a wearable computing device, and so forth. The network108can be implemented in various ways and according to a variety of different architectures, including wireless networks, wired networks, and combinations thereof.

The client device102includes various functionalities and data that enable the client device102to perform different aspects of managing data transactions discussed herein, including a connectivity module110, a display device112, sensors114, a position module116, a payment application118, and a transaction manager module120. The connectivity module110represents functionality (e.g., logic and hardware) for enabling the client device102to interconnect with other devices and/or networks, such as the network108. The connectivity module110, for instance, enables wireless and/or wired connectivity of the client device102. In a wireless scenario the connectivity module110enables connectivity and data communication via a variety of different wireless protocols, such as wireless broadband, wireless cellular, Wireless Local Area Network (WLAN) (e.g., Wi-Fi), Wi-Fi Direct, wireless short distance communication (e.g., Bluetooth™ (including Bluetooth™ Low Energy (BLE)), Near Field Communication (NFC)), and so forth.

The display device112represents functionality for visual output of content by the client device102. In implementations the display device112includes touch input functionality (e.g., a digitizer) to enable a user of the client device102to provide touch input to the client device102.

The sensors114represent functionality for detecting various physical and/or logic conditions pertaining to the client device102. In this particular example the sensors114include cameras124, position sensors126, and wireless sensors128. The cameras124represent functionality for detecting visual objects in an environment surrounding the client device102and can generate visual data that describes the visual objects. The position sensors126represent functionality for determining a position and orientation of the client device102and for detecting changes in position and orientation of the client device102. Examples of the position sensors126include an accelerometer, a gyroscope, a magnetometer, a GPS and/or other geographic system sensor, and so forth.

The position sensors126can be implemented to detect a position of the client device102, such as a geographic position, a physical location, a relative position within a physical location, and so forth. Further, the position sensors126can enable a spatial orientation of the client device102to be detected and can be implemented in various ways to provide different types of orientation detection, such as 3 degrees of freedom (3-DOF), 6 degrees of freedom (6-DOF), 9 degrees of freedom (9-DOF), and so forth. The wireless sensors128represent functionality to detect direct types of wireless signal, such as wireless signal transmitted in different frequencies. The wireless sensors128, for instance, include an antenna and/or set of antennas tuned to detect wireless signal received via different wireless frequencies. The wireless sensors128, for instance, include an ultra-wideband (UWB) sensor129which is operable to receive and detect wireless signal in UWB frequencies.

These examples of sensors114are not to be construed as limiting and the sensors114are implementable to include a variety of different sensor types and sensor instances for sensing physical and logic phenomena.

The position module116represents functionality for determining a location of the client device102. The position module116, for instance, can receive sensor data130from the sensors114to determine a location of the client device102, such as a physical location including a geographic location, a street address, a known location, a physical facility, a micro-location (e.g., a precise location such as within a larger location), and so forth. The position module116can utilize various types of sensor data130for determining a location of the client device102, such as image data generated by the cameras124, position data generated by the position sensors126, wireless data generated by the wireless sensors128, combinations thereof, and so forth. In implementations the position module116can track locations where the client device102is detected such as to determine locations frequently visited by the person122.

The payment application118represents functionality to perform payments via the client device102, such as to cause value to be exchanged for services, e.g., exchanges of goods and/or services. For instance, when a vendor provides a service to the person122, the person122can interact with the payment application118to cause a value amount (e.g., a monetary amount) to be transferred (e.g., digitally) from a user account to the vendor's account.

The transaction manager module120represents functionality to track different payment transactions, such as payment transactions performed via the client device102and/or payments performed by the person122via a user account. Based on tracking different payment transactions, the transaction manager module120can generate transaction history data132that describes different attributes of payment transactions, such as payment transactions performed via the payment application118. The transaction history data132can include various information for payment transactions, such as transaction positions (e.g., geographic locations, addresses, micro-locations within larger locations, etc.), duration of device presence at positions in conjunction with payment transactions, transaction amounts, vendor IDs, payment methods used, etc. As further detailed herein, the transaction manager module120can utilize the transaction history data132to provide transaction recommendations such as for payment transactions at different positions of the client device102.

The environment100further includes a vendor device134which represents a device associated with a vendor that can provide items (e.g., goods and/or services), such as to the person122. In at least one implementation the vendor device134represents at least a part of a point of sale (POS) system. The vendor device134includes various functionality including a connectivity module136, a payment application138, sensors140, and a position module142. The connectivity module136represents functionality (e.g., logic and hardware) for enabling the vendor device134to interconnect with other devices and/or networks, such as the network108. The connectivity module136, for instance, enables wireless and/or wired connectivity of the vendor device134. In a wireless scenario the connectivity module136enables connectivity and data communication via a variety of different wireless protocols, such as wireless broadband, wireless cellular, Wireless Local Area Network (WLAN) (e.g., Wi-Fi), Wi-Fi Direct, wireless short distance communication (e.g., Bluetooth™ (including Bluetooth™ Low Energy (BLE)), Near Field Communication (NFC)), and so forth.

The payment application138represents functionality for enabling the vendor device134to receive value, such as based on services provided by a vendor associated with the vendor device134. For instance, the payment application118can initiate a payment transaction for a service provided to the person122by a vendor, and the payment application138can receive a transfer of credit from a user account to a vendor account. In at least some implementations the payment applications118,138represent different instances of a common payment application, such as a payment application deployed and/or managed by the payment service104and/or the transaction service106.

The sensors140represent functionality for detecting various physical and/or logic conditions pertaining to the vendor device134. In implementations the sensors140may include various sensor types such as described with reference to the sensors114of the client device102. The position module142represents functionality for determining a location of other devices relative to the vendor device134. The position module142, for instance, can receive sensor data from the sensors140to determine a location of the client device102relative to the vendor device134, such as to estimate a distance between the vendor device134and the client device102.

According to implementations, the payment service104and the transaction service106can participate in various aspects of managing data transactions described herein. For instance, the payment service104can serve as a broker functionality between the payment applications118,138to enable payment transactions to be performed. The transaction service106can perform aspects of managing data transactions described herein. For instance, implementations described herein can be performed by the transaction manager module120, the transaction service106, and/or cooperatively between the transaction manager module120and the transaction service106.

Having discussed an example environment in which the disclosed techniques can be performed, consider now some example scenarios and implementation details for implementing the disclosed techniques.

FIG.2depicts an example scenario200for training a system for managing data transactions in accordance with one or more implementations. The scenario200can be implemented in the environment100and incorporates attributes of the environment100introduced above. The scenario200, for instance, represents aspects of a training phase for training a system to provide data transaction recommendations.

In the scenario200the person122is located at a location202, which in this example represents a restaurant. Further, the person122is carrying the client device102. The person122engages in a data transaction204at the location202, such as via the payment application118. The data transaction204, for instance, represents an exchange of value for a purchase of food items at the location202. Based on the data transaction204the payment application118generates transaction data206that describes attributes of the data transaction204. The transaction data206, for instance, includes a vendor identifier for a vendor associated with the data transaction204(e.g., a restaurant identifier), a description of items purchased (e.g., goods and/or services), a transaction amount (e.g., a price paid for the items), a payment method, and so forth.

Further to the scenario200the position module116receives sensor data130from the sensors114. The position module116utilizes the sensor data130to generate position data208that describes a position of the client device102. The position data208can represent the position of the client device102in various ways, such as in terms of city, state, geographic coordinates, street address, etc. Further, the position data208can include a business identifier, such as for a business (e.g., restaurant) located at the location202. The position module116also generates duration data210that indicates a time duration that the client device102is located at the location202described by the position data208. Accordingly, the transaction manager module120generates a data transaction record212that includes attributes of the transaction data206, the position data208, and the duration data210. The data transaction record212, for instance, describes attributes of the transaction data206such as a transaction amount, items purchased, vendor identifier, etc. Further, the data transaction record212describes a position of the client device102at a particular date and time, a time duration that the client device102is located at the position during the data transaction204, and so forth.

According to implementations the transaction manager module120generates the data transaction record212to indicate a number of data transactions that match attributes of the data transaction204. For instance, when the person122visits the location202multiple times and multiple different data transactions occur, the transaction manager module120updates the data transaction record212to identify attributes of each data transaction, e.g., with different instances of the transaction data206, the position data208, and the duration data210.

In implementations the transaction manager module120can generate multiple instances of data transaction records212, such as based on different data transactions at a same location (e.g., the location202), different data transactions at different locations, different transaction amounts, different time durations, different items purchased, etc.

FIG.3depicts an example scenario300for generating data transactions in accordance with one or more implementations. The scenario300can be implemented in the environment100and incorporates attributes of the environment100introduced above. The scenario300, for instance, represents a continuation of the scenario200. The scenario200, for example, represents an implementation phase for providing data transaction recommendations, such as after system training described in the scenario200.

In the scenario300the person122is located at the location202, such as at a subsequent date and time than represented in the scenario200. Further, the transaction manager module120receives (e.g., from the position module116) position data302and duration data304respectively describing a position of the client device102and a time duration that the client device102is positioned at the location202. The transaction manager module120correlates the position data302and the duration data304to the data transaction record212and determines that a transaction trigger306occurs. The transaction trigger306, for instance, occurs in response to a set of data transaction conditions occurring, such as a position of the client device102for a particular time duration. For example, the data transaction record212indicates different minimum time durations for presence of the client device102at the location202after which the transaction trigger306can occur. Further, the data transaction record212can indicate a minimum number of data transactions to be performed at the location202before the transaction trigger306occurs.

Further to the scenario300and in response to the transaction trigger306, the transaction manager module120generates a transaction recommendation308that includes an executable data transaction310. The transaction recommendation308, for instance, includes transaction parameters for a data transaction, such as a transaction amount, a transaction method (e.g., a payment method), a transaction history (e.g., at the location202), etc. The executable data transaction310represents a set of data transaction parameters that are executable to perform a data transaction.

The transaction manager module120then generates and outputs a recommendation GUI312via the client device102that includes aspects of the transaction recommendation308. The recommendation GUI312, for instance, describes attributes of the transaction recommendation308, such as a vendor identifier associated with the location202, a recommended transaction amount, a recommended transaction method (e.g., payment method), a transaction history at the location202, etc. In at least one implementation the recommendation GUI312is output via the client device102in response to the person122unlocking the client device102from a locked state. For instance, after the person122is present at the location202for a time duration, the person122unlocks the client device102and the recommendation GUI312is displayed and/or output in some other way. Alternatively or additionally, the recommendation GUI312can be output while the client device102is in a locked state, such as part of a lock screen of the client device102.

Further, the recommendation GUI312is configured to receive user input to perform various actions pertaining to the transaction recommendation308, such as to accept or decline the transaction recommendation308, to modify the transaction recommendation308, to obtain more information about the transaction recommendation308, and so forth.

FIG.4illustrates an example recommendation GUI312in accordance with one or more implementations. The recommendation GUI312includes a vendor identifier400, a transaction description402, an accept control404, a decline control406, an options control408, and a history region410. The vendor identifier400identifies a particular vendor (e.g., a merchant) associated with the transaction recommendation308, e.g., an identifier for a vendor from the transaction data206used to generate the data transaction record212. In at least one implementation the vendor identifier400can be received and/or extracted from vendor-specific information, such as information transmitted from the vendor device134.

The transaction description402identifies attributes of a recommended data transaction, such as a transaction amount (e.g., a recommended payment amount) and a transaction item, e.g., a recommended item for purchase as part of a data transaction. The accept control404is selectable to cause the executable data transaction310to be executed. For instance, a user selection of the accept control404causes a data transaction (e.g., a payment transaction) to be executed, such as via the payment application118and/or the payment application138. The accept control404, for example, identifies a recommended transaction method for executing the executable data transaction310, such as based on transaction history indicated by the data transaction record212.

The decline control406is selectable to decline execution of the data transaction310. For instance, user selection of the decline control406causes the recommendation GUI312to be removed from display and the transaction recommendation308to be ignored. The options control408is selectable to present other transaction options, such as to enable the person122to input different transaction amounts, different transaction methods (e.g., different payment methods), different transaction items (e.g., items for purchase), etc.

The history region410is populated with transaction history information, such as for past data transactions that occurred at the location202. The data transaction record212, for instance, tracks data transactions at the location202over time and thus the history region410can be populated with information about previous data transactions, such as transaction dates, transaction items, transaction amounts, etc. In implementations different transaction history entries in the history region410are selectable to cause additional transaction information about a selected entry to be presented and/or to perform actions pertaining to a selected history entry. For instance, a history entry412indicates different transaction information (e.g., items purchased, transaction amount, etc.) than identified in the transaction description402. Accordingly, the person122can select the history entry412to cause a data transaction to be executed based on transaction parameters of the history entry412, e.g., to override transaction parameters indicated by the transaction description402.

FIG.5depicts an example scenario500for using application data for data transactions in accordance with one or more implementations. The scenario500can be implemented in the environment100and incorporates attributes of the environment100introduced above. In implementations the scenario500can be combined in various ways with aspects of the scenarios described above.

In the scenario500the person122is carrying the client device102and is positioned at the location202. The person122, for example, is at the location202to purchase items such as food items from a vendor located at the location202. Further, the vendor device134is positioned within the location202. The payment application138on the vendor device134receives application data502indicating that the payment application118is available on the client device102. The vendor device134, for instance, receives data transmitted from the client device102indicating that the payment application118is present on the client device102. Alternatively or additionally the vendor device134maintains historical data from the client device102identifying that the payment application118is present on the client device102, and/or the vendor device134receives network data (e.g., from the payment service104) indicating that the payment application118is present on the client device102. As mentioned above, the payment applications118,138can represent different instances of a common payment application.

The payment application138also receives position data504and duration data506, such as from the position module142. The position module142, for example, receives sensor data from the sensors140and generates the position data504that describes a position (e.g., location) of the client device102relative to the vendor device134. The position module142can determine the position of the client device102in various ways, such as based on wireless signal transmitted by the client device102and received by the sensors140. In implementations the position data504indicates an estimated distance between the client device102and the vendor device134. Further, the duration data506can indicate a time duration and/or set of time durations that the client device102is located within a particular distance and/or set of distances from the vendor device134.

Further to the scenario500, the payment application138determines based at least in part on the application data502, the position data504, and the duration data506that a transaction trigger508occurs. The transaction trigger508, for instance, occurs based on occurrence of a set of one or more conditions, such as that the client device102includes the payment application138and is located within a threshold minimum distance from the vendor device134for a threshold minimum time duration.

In at least some implementations a data transaction record510can be used to determine whether the transaction trigger508occurs. The data transaction record510, for instance, can indicate various transaction-related information, such as historical and/or average time durations associated with transactions at the location202, average and/or historical transaction amounts, items historically purchased at the location202, and so forth. In implementations the data transaction record510can be associated with persons in general and/or specific to a user identity associated with the client device102, e.g., the person122. The data transaction record510, for example, can be generated based on a transaction history of the person122at the location202and/or at locations associated with an entity (e.g., an enterprise entity) with a presence at the location202and/or represented by the vendor device134.

Further to the scenario500and based at least in part on the transaction trigger508, the payment application138generates a transaction recommendation512that includes an executable data transaction514. The transaction recommendation512can include various transaction-related parameters, such as a recommended payment option (e.g., with a recommended transaction value and a recommended payment method (e.g., using a same payment application)), discounts available at the location202, coupons for items available for purchase, reward points (e.g., available to the person122), and so forth. Accordingly, the payment application138causes the transaction recommendation512to be transmitted to the client device102, such as wirelessly via the vendor device134.

The client device102receives the transaction recommendation512and the payment application118presents the transaction recommendation512within a recommendation GUI516. The recommendation GUI516can be presented in various ways, such as in response to an unlock action on the client device102, as part of a lock screen on the client device102, etc. The person122can interact with the recommendation GUI516, such as to cause a payment transaction to be implemented and/or to participate in an offer and/or promotion identified by the transaction recommendation512.

FIG.6illustrates an example recommendation GUI516in accordance

with one or more implementations. The recommendation GUI516includes a vendor identifier600, a promotions control602, and a discounts control604. The vendor identifier600identifies a particular vendor (e.g., a merchant) associated with the transaction recommendation512, e.g., an identifier for a vendor from the transaction recommendation512. In at least one implementation the vendor identifier600can be received and/or extracted from vendor-specific information, such as information transmitted from the vendor device134.

The promotions control602is selectable to cause different product promotions to be presented, such as for new items for sale. The discounts control604is selectable to cause representations of different discounted items to be presented, such as items that currently have a reduced cost.

The recommendation GUI516further includes an amount field606, an accept control608, a decline control610, and a history region612. The amount field606indicates an estimated transaction amount for the transaction recommendation512, e.g., for a payment transaction associated with the transaction recommendation512. The transaction amount presented in the amount field606can be determined in various ways, such as based on a user transaction history indicated by the data transaction record510, based on a transaction determined by the payment application138, etc. In implementations the amount field606is user customizable, such to enable the person122to enter a custom transaction amount.

The accept control608is selectable to cause the executable data transaction514(e.g., a payment transaction) to be executed, such as via the payment application118and/or the payment application138. The decline control610is selectable to decline execution of the executable data transaction514. For instance, user selection of the decline control610causes the recommendation GUI516to be removed from display and the transaction recommendation512to be ignored. Example attributes of the history region612are discussed above with reference to the history region410, such as information about past data transactions that occurred at the location202and/or associated with an entity (e.g., business entity) associated with the vendor device134.

According to implementations aspects of the scenarios described herein are combinable in various ways. For instance, at least some of the training aspects described with reference to the scenario200can be circumvented (e.g., skipped) using the application-to-application communication discussed in the scenario500.

FIG.7illustrates a flow chart depicting an example method700for training a system to generate data transactions in accordance with one or more implementations. The method700, for instance, represents portions of a training phase for training a system for implementation aspects of managing data transactions. At702data transactions at one or more locations are monitored. The transaction manager module120, for instance, monitors data transactions at different locations, such as payment transactions at different vendor locations. Various aspects of the data transactions can be monitored, such as position information, time duration, transaction amounts, items purchased as part of the data transactions, and so forth.

At704it is determined whether data transactions for a first location correspond to a data transaction threshold. The data transaction threshold, for instance, represents a minimum number of data transactions that occur at the first location, such as over a time period. In implementations the data transaction threshold may be associated with a particular transaction amount and/or transaction amount range.

If data transactions for the first location do not correspond to the data transaction threshold (“No”), the method returns to step702. If the data transactions for the first location correspond to the data transaction threshold (“Yes”), at706a data transaction record is generated based at least in part on the data transactions for the first location corresponding to the data transaction threshold. The data transaction record can include various information, such as data transaction parameters for the first location. Examples of the data transaction parameters include one or more time durations for data transactions for the first location, data transaction amounts, items purchased as part of data transactions, etc. Examples of different information that can be included as part of a data transaction record are described throughout this disclosure. The data transaction record can be used for various purposes, such as for generating data transaction recommendations as described throughout this disclosure.

FIG.8illustrates a flow chart depicting an example method800for generating data transactions in accordance with one or more implementations. The method800, for instance, may be implemented in conjunction with and/or subsequently to the method700. At802it is determined that a set of data transaction conditions occur based at least on a position of a device and a duration that the device is located at the position. The transaction manager module120, for instance, receives position data and time duration data (e.g., transaction conditions) indicating that the client device102is present at a location for a minimum threshold time duration.

At804a data transaction record is retrieved that corresponds to the set of transaction conditions. For instance, the transaction manager module120searches the transaction history data132to identify a data transaction record that corresponds to the set of transaction conditions, such as a position of the client device102and a time duration that the client device102is located at the position.

At806one or more executable data transactions are generated based at least in part on the data transaction record. The transaction manager module120, for example, generates transaction parameters that can be used to execute a data transaction, such as transaction amount(s), transaction items, transaction history information, etc.

At808an indication of the one or more executable data transactions is caused to be presented that is selectable to implement at least one executable data transaction of the one or more executable data transactions. For instance, the transaction manager module120generates a transaction recommendation and causes the transaction recommendation to be output via a recommendation GUI.

At810an indication is received of user interaction with the indication of the one or more executable data transactions. A user, for instance, interacts with a recommendation GUI to indicate an action to be performed, such as to select a data transaction and/or set of data transactions to be implemented, to decline implementation of the one or more executable transactions, to modify and implement one or more of the data transactions, etc.

At812the at least one executable data transaction is processed based at least in part on the indication of the user interaction. For instance, if a user provides input to select to accept the at least one executable data transaction, the transaction manager module120causes the at least one executable data transaction to be implemented. In an implementation where the executable data transaction represents a payment transaction, the transaction manager module120can cause a payment value amount to be transferred from a user account to a different account, such as vendor account.

Alternatively, if the user provides input to decline the at least one executable data transaction, the transaction manager module120can cancel performance of the at least one executable data transaction. For instance, the transaction manager module120can remove the recommendation GUI.

As yet another implementation, a user may interact with the recommendation GUI to modify various transaction parameters, such as a transaction amount, an item involved in the data transaction, a vendor, etc. Accordingly, the transaction manager module120may cause a modified executable data transaction to be performed based on the user modified parameter(s).

In implementations a data transaction record can be updated based on the user interaction, such as to indicate that the user accepted a data transaction recommendation, declined a data transaction recommendation, modified a data transaction recommendation, etc. For instance, user interaction with a data transaction recommendation can be used as feedback to further train and improve the recommendation algorithm(s) to enable more accurate recommendations to be provided.

FIG.9illustrates a flow chart depicting an example method900for using application data for data transactions in accordance with one or more implementations. At902occurrence of one or more conditions is detected indicating that a first device is present within a first threshold proximity to a position for a minimum time duration threshold and that the first device and the second device support a data transaction application. A payment application (e.g., one or more of the payment applications118,138) detects that the client device102is within a threshold proximity to the vendor device134for minimum amount of time, e.g., based on a predefined time duration threshold.

At904an executable data transaction indication is transmitted, to the first device and based at least in part on occurrence of the one or more conditions, the executable data transaction indication including one or more data transaction parameters for performing one or more executable data transactions with the second device. The payment application138on the vendor device134, for instance, causes a transaction recommendation associated with one or more executable data transactions to be transmitted to the client device102. The payment application118at the client device102may output a recommendation GUI that includes the transaction recommendation. Examples of different transaction-related parameters that may be included in the executable data transaction indication (e.g., in the recommendation GUI) are discussed above, and may include a recommendation to perform a payment transaction using a particular payment application, such as the common payment applications118,138between the client device102and the vendor device134.

At906a data transaction response to the executable data transaction indication is received from the first device. A user, for instance, interacts with the recommendation GUI to accept a recommended action pertaining to an executable data transaction, such as to perform a data transaction (e.g., a payment transaction), to accept an offer and/or a promotion relating to the vendor device134, to decline a recommended action pertaining to an executable data transaction, etc.

At908one or more executable data transactions are processed based at least in part on the data transaction response and the one or more data transaction parameters. For instance, where a user provides input to accept a data transaction recommendation, a data transaction can be executed. The payment application138and/or the payment application118, for instance, can cause a payment transaction to be executed, such as a transfer of value from a user account to a vendor account. Where a user provides input to decline a data transaction recommendation, the data transaction recommendation can be canceled and a recommendation GUI removed from display. Further, a user may modify one or more transaction parameters (e.g., transaction amount, transaction items, etc.) and thus a modified data transaction may be performed.

FIG.10illustrates a flow chart depicting an example method1000for using application data for data transactions in accordance with one or more implementations. At1002an executable data transaction indication is received at a first device, the executable data transaction indication including one or more data transaction parameters for performing one or more data transactions, via a data transaction application, with a second device located at a position. The client device102, for instance, receives a transaction recommendation from the vendor device134. Examples of different transaction parameters are described above, such as a transaction amount and/or other related transaction parameters.

At1004and based at least in part on the first device being located within a first threshold proximity to the position for a minimum threshold time duration, a transaction notification is presented including the one or more transaction parameters. The payment application118, for instance, causes the client device102to display a recommendation GUI that includes the transaction parameters. In at least one implementation the client device102can receive the executable data transaction indication and can prevent (e.g., delay) output of the transaction notification until the client device102is within the threshold proximity to the vendor device134, such as for the threshold time duration.

At1006an executable data transaction is processed, via the data transaction application, based at least in part on an indication of an input to the transaction notification. A user, for instance, provides input to the recommendation GUI to accept, decline, or modify the executable data transaction indication. For instance, where a user provides input to accept a data transaction recommendation, a data transaction can be executed. The payment application138and/or the payment application118, for instance, can cause a payment transaction to be executed, such as a transfer of value from a user account to a vendor account. Where a user provides input to decline a data transaction recommendation, the data transaction recommendation can be canceled and a recommendation GUI removed from display. Further, a user may modify one or more transaction parameters (e.g., transaction amount, transaction items, etc.) and thus a modified data transaction may be performed.

The example methods described above may be performed in various ways, such as for implementing different aspects of the systems and scenarios described herein. Further, while certain operations and/or actions are described with regard to specific entities (e.g., the client device102, the vendor device134, etc.), it is to be appreciated that the techniques described herein may be performed by any suitable entity and/or cooperatively between different entities.

Generally, any services, components, modules, methods, and/or operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Some operations of the example methods may be described in the general context of executable instructions stored on computer-readable storage memory that is local and/or remote to a computer processing system, and implementations can include software applications, programs, functions, and the like. Alternatively or in addition, any of the functionality described herein can be performed, at least in part, by one or more hardware logic components, such as, and without limitation, Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SoCs), Complex Programmable Logic Devices (CPLDs), and the like. The order in which the methods are described is not intended to be construed as a limitation, and any number or combination of the described method operations can be performed in any order to perform a method, or an alternate method.

FIG.11illustrates various components of an example device1100in which aspects of user state for user image in media content can be implemented. The example device1100can be implemented as any of the devices described with reference to the previousFIGS.1-10, such as any type of mobile device, mobile phone, mobile device, wearable device, tablet, computing, communication, entertainment, gaming, media playback, and/or other type of electronic device. For example, the client device102and/or the vendor device134as shown and described with reference toFIGS.1-10may be implemented as the example device1100.

The device1100includes communication transceivers1102that enable wired and/or wireless communication of device data1104with other devices. The device data1104can include any of device identifying data, device location data, wireless connectivity data, and wireless protocol data. Additionally, the device data1104can include any type of audio, video, and/or image data. Example communication transceivers1102include wireless personal area network (WPAN) radios compliant with various IEEE 1102.15 (Bluetooth™) standards, wireless local area network (WLAN) radios compliant with any of the various IEEE 1102.11 (Wi-Fi™) standards, wireless wide area network (WWAN) radios for cellular phone communication, wireless metropolitan area network (WMAN) radios compliant with various IEEE 1102.16 (WiMAX™) standards, and wired local area network (LAN) Ethernet transceivers for network data communication.

The device1100may also include one or more data input ports1106via which any type of data, media content, and/or inputs can be received, such as user-selectable inputs to the device, messages, music, television content, recorded content, and any other type of audio, video, and/or image data received from any content and/or data source. The data input ports may include USB ports, coaxial cable ports, and other serial or parallel connectors (including internal connectors) for flash memory, DVDs, CDs, and the like. These data input ports may be used to couple the device to any type of components, peripherals, or accessories such as microphones and/or cameras.

The device1100includes a processing system1108of one or more processors (e.g., any of microprocessors, controllers, and the like) and/or a processor and memory system implemented as a system-on-chip (SoC) that processes computer-executable instructions. The processor system may be implemented at least partially in hardware, which can include components of an integrated circuit or on-chip system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations in silicon and/or other hardware. Alternatively or in addition, the device can be implemented with any one or combination of software, hardware, firmware, or fixed logic circuitry that is implemented in connection with processing and control circuits, which are generally identified at1110. The device1100may further include any type of a system bus or other data and command transfer system that couples the various components within the device. A system bus can include any one or combination of different bus structures and architectures, as well as control and data lines.

The device1100also includes computer-readable storage memory1112(e.g., memory devices) that enable data storage, such as data storage devices that can be accessed by a computing device, and that provide persistent storage of data and executable instructions (e.g., software applications, programs, functions, and the like). Examples of the computer-readable storage memory1112include volatile memory and non-volatile memory, fixed and removable media devices, and any suitable memory device or electronic data storage that maintains data for computing device access. The computer-readable storage memory can include various implementations of random access memory (RAM), read-only memory (ROM), flash memory, and other types of storage media in various memory device configurations. The device1100may also include a mass storage media device.

The computer-readable storage memory1112provides data storage mechanisms to store the device data1104, other types of information and/or data, and various device applications1114(e.g., software applications). For example, an operating system1116can be maintained as software instructions with a memory device and executed by the processing system1108. The device applications may also include a device manager, such as any form of a control application, software application, signal-processing and control module, code that is native to a particular device, a hardware abstraction layer for a particular device, and so on. Computer-readable storage memory1112represents media and/or devices that enable persistent and/or non-transitory storage of information in contrast to mere signal transmission, carrier waves, or signals per se. Computer-readable storage memory1112do not include signals per se or transitory signals.

In this example, the device1100includes a transaction manager module1118that implements aspects of managing data transactions and may be implemented with hardware components and/or in software as one of the device applications1114. In an example, the transaction manager module1118can be implemented as the transaction manager module120described in detail above. In implementations, the transaction manager module1118may include independent processing, memory, and logic components as a computing and/or electronic device integrated with the device1100. The device1100also includes a payment application1120which may represent an implementation of one or more of the payment applications118,138.

In this example, the example device1100also includes a camera1122and motion sensors1124, such as may be implemented in an inertial measurement unit (IMU). The motion sensors1124can be implemented with various sensors, such as a gyroscope, an accelerometer, and/or other types of motion sensors to sense motion of the device. The various motion sensors1124may also be implemented as components of an inertial measurement unit in the device.

The device1100also includes a wireless module1126, which is representative of functionality to perform various wireless communication tasks. For instance, for the client device102, the wireless module1126can be leveraged to scan for and detect wireless networks, as well as negotiate wireless connectivity to wireless networks for the client device102. The device1100can also include one or more power sources1128, such as when the device is implemented as a mobile device. The power sources1128may include a charging and/or power system, and can be implemented as a flexible strip battery, a rechargeable battery, a charged super-capacitor, and/or any other type of active or passive power source.

The device1100also includes an audio and/or video processing system1130that generates audio data for an audio system1132and/or generates display data for a display system1134. The audio system and/or the display system may include any devices that process, display, and/or otherwise render audio, video, display, and/or image data. Display data and audio signals can be communicated to an audio component and/or to a display component via an RF (radio frequency) link, S-video link, HDMI (high-definition multimedia interface), composite video link, component video link, DVI (digital video interface), analog audio connection, or other similar communication link, such as media data port1136. In implementations, the audio system and/or the display system are integrated components of the example device. Alternatively, the audio system and/or the display system are external, peripheral components to the example device.

Although implementations of user state for user image in media content have been described in language specific to features and/or methods, the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the features and methods are disclosed as example implementations of user state for user image in media content, and other equivalent features and methods are intended to be within the scope of the appended claims. Further, various different examples are described, and it is to be appreciated that each described example can be implemented independently or in connection with one or more other described examples.

In addition to the previously described methods, any one or more of the following:

In some aspects, the techniques described herein relate to a system including: one or more processors: and computer-readable storage media storing instructions that are executable by the one or more processors to: determine that a set of data transaction conditions occur based at least on a position of a device and a duration that the device is located at the position: retrieve a data transaction record that corresponds to the set of data transaction conditions: generate one or more executable data transactions based at least in part on the data transaction record; and cause an indication of the one or more executable data transactions to be presented that is selectable to implement at least one executable data transaction of the one or more executable data transactions.

In some aspects, the techniques described herein relate to a system, wherein the set of data transaction conditions include a minimum time threshold for location at the position.

In some aspects, the techniques described herein relate to a system, wherein the at least one executable data transaction includes a transaction amount determined based at least in part on the data transaction record.

In some aspects, the techniques described herein relate to a system, wherein the data transaction record includes multiple different transaction amounts for the position of the device, each transaction amount is based at least in part on a different respective duration of time for location at the position, wherein the transaction amount is based at least in part on respective duration of time that the device is located at the position.

In some aspects, the techniques described herein relate to a system, wherein the indication of at least one executable data transaction an indication of the transaction amount, and wherein the instructions are executable by the one or more processors to: receive input to the indication of the one or more executable data transactions to modify the transaction amount; and update the data transaction record to include the modified transaction amount.

In some aspects, the techniques described herein relate to a system, wherein the data transaction record indicates a payment method, and the indication of the one or more executable data transactions includes a recommendation to implement the at least one executable data transaction using the payment method.

In some aspects, the techniques described herein relate to a system, wherein the instructions are executable by the one or more processors to receive a wireless signal and determine the position of the device based at least in part on the wireless signal.

In some aspects, the techniques described herein relate to a system, wherein the instructions are executable by the one or more processors to: receive an indication of selection of the indication of the one or more executable data transactions: and cause the at least one executable data transaction to be implemented based at least in part on the indication of the selection.

In some aspects, the techniques described herein relate to a system, wherein the indication of the one or more executable data transactions includes a first selectable option to accept the at least one executable data transaction, a second selectable option to decline the at least one executable data transaction, and wherein the instructions are executable by the one or more processors to: receive an indication of selection of the second selectable option: and update the data transaction record to indicate that the at least one executable data transaction is declined.

In some aspects, the techniques described herein relate to a system, wherein the instructions are executable by the one or more processors to present the indication of the one or more executable data transactions in response to an unlock action occurring on the device.

In some aspects, the techniques described herein relate to a system, wherein the indication of the one or more executable data transactions includes one or more previous data transactions performed based at least in part on the device being located at the position.

In some aspects, the techniques described herein relate to a system, wherein the indication of the one or more executable data transactions includes a first indication of a first executable data transaction associated with a first transaction amount and a second indication of a second executable data transaction associated with a second transaction amount, and wherein the instructions are executable by the one or more processors to: receive an indication of selection of the second indication; and cause the second executable data transaction to be implemented and according to the second transaction amount.

In some aspects, the techniques described herein relate to a system including: one or more processors: and computer-readable storage media storing instructions that are executable by the one or more processors to: monitor data transactions at one or more locations: determine that data transactions for a first location correspond to a data transaction threshold, the data transaction threshold including a number of data transactions that occur at the first location: generate, based at least in part on the data transactions for the first location corresponding to the data transaction threshold, a data transaction record for the first location, the data transaction record including data transaction parameters for the first location, and the data transaction parameters for the first location including one or more time durations for the data transactions for the first location; and cause, based at least in part on the data transaction record, an indication of one or more executable data transactions to be presented that is selectable to implement at least one executable data transaction of the one or more executable data transactions.

In some aspects, the techniques described herein relate to a system, wherein to monitor data transactions at the one or more locations includes to monitor durations of time for the data transactions and transaction amounts for the data transactions.

In some aspects, the techniques described herein relate to a system, wherein the data transaction threshold further includes an indication of one or more transaction amounts for the data transactions for the first location.

In some aspects, the techniques described herein relate to a system, wherein the data transaction record includes an indication of multiple different data transactions that are each associated with a different time duration and a different transaction amount.

In some aspects, the techniques described herein relate to a system, wherein the instructions are executable by the one or more processors to: determine a time duration that a device is present at the first location: and cause the indication of the one or more executable data transactions to be presented to include the at least one executable data transaction based on the time duration that the device is present at the first location.

In some aspects, the techniques described herein relate to a system, wherein the indication of the one or more executable data transactions includes a first selectable option to accept the at least one executable data transaction, a second selectable option to decline the at least one executable data transaction, and wherein the instructions are executable by the one or more processors to update the data transaction record based on an indication of selection of the first selectable option or the second selectable option.

In some aspects, the techniques described herein relate to a method including: determining that a set of data transaction conditions occur based at least on a position of a device and a time duration that the device is located at the position: retrieving a data transaction record that corresponds to the set of data transaction conditions: generating one or more executable data transactions based at least in part on the data transaction record; and causing an indication of the one or more executable data transactions to be presented that is selectable to implement at least one executable data transaction of the one or more executable data transactions.

In some aspects, the techniques described herein relate to a method, wherein the data transaction record includes multiple time durations and a different transaction amount for each respective time duration, and wherein the indication of the one or more executable data transactions includes an indication of a particular data transaction associated with the time duration that the device is located at the position.