Data Grid Platform

Abstract

In various example embodiments, systems and methods for data grid platforms are proposed. User-associated attribute data is accessed from multiple attribute sources. Analysis of the attribute data is performed. Based on this analysis, actions corresponding to the user are executed.

Description

[0001] This application is a divisional application of the PCT international application PCT / US2015 / 022318 filed on March 24, 2015, which entered the Chinese national phase with application number 201580027971.8 and entitled "Data Grid Platform".

[0002] Related applications

[0003] This international application claims priority to U.S. Provisional Application No. 61 / 970,263, filed March 25, 2014; U.S. Patent Application No. 14 / 459,115, filed August 13, 2014; U.S. Patent Application No. 14 / 449,113, filed July 31, 2014; U.S. Patent Application No. 14 / 449,126, filed July 31, 2014; and U.S. Patent Application No. 14 / 498,326, filed September 26, 2014, the entire contents of which are incorporated herein by reference. Technical Field

[0004] The embodiments disclosed herein generally relate to data grid platforms. Background Art

[0005] In recent years, mobile devices, wearable devices, and smart devices have permeated almost every aspect of modern life. These devices increasingly incorporate sensors to monitor everything from the humidity levels of indoor plants to basketball dribbling. Connected devices like these provide near real-time and continuous data feeds. These trends deliver a wealth of constantly updated data. Summary of the Invention

[0006] To better illustrate the apparatus and methods disclosed herein, a list of non-limiting examples is provided below:

[0007] Example 1: A system comprising: an attribute module for receiving attribute data associated with a user from multiple attribute sources; an item module for extracting demand indications from the attribute data, the demand indications indicating the user's expected demand for a specific item; an analysis module, implemented by a machine's hardware processor, for identifying relevant items based on the extracted demand indications according to the attribute data; a feature module for inferring user characteristics associated with the user based on the attribute data; and an order module for determining transaction parameters for a proposed transaction associated with the relevant items, at least in part based on the user characteristics, and facilitating the proposed transaction based on the determined transaction parameters.

[0008] Example 2 is based on the system of Example 1, wherein at least one order parameter includes at least one of quantity, delivery time, payment time, delivery method, delivery destination, merchant, or product.

[0009] Example 3: A method comprising: receiving attribute data associated with a user from multiple attribute sources; extracting a demand indication from the attribute data, the demand indication indicating the user's expected demand for a specific item; identifying a product based on the attribute data using a machine's hardware processor based on the extracted demand indication; inferring user characteristics associated with the user based on the attribute data; determining order parameters for a user purchase associated with the product based at least in part on the inferred user characteristics; and facilitating the user purchase based on the determined order parameters.

[0010] Example 4 follows the method of Example 3, wherein at least one order parameter includes at least one of quantity, delivery time, payment time, delivery method, delivery destination, merchant, or product.

[0011] Example 5, based on the method of Example 3, further includes: extracting the current inventory level of a product from attribute data; determining an inventory threshold for the product by modeling the use of the product based on the extracted current inventory level and inferred user characteristics; identifying a mismatch between the inventory threshold and the current inventory level; and automatically executing a user purchase on behalf of the user based on the mismatch.

[0012] Example 6, based on the method of Example 3, further includes: identifying the user's purchase motive for the product by analyzing the inferred user characteristics, the purchase motive corresponding to a motive time; determining a time order parameter included in the order parameters based on the motive time; and promoting the user's purchase based on the determined time order parameter.

[0013] Example 7, based on the method of Example 3, further includes: identifying similar users similar to the user from among the plurality of other users based on the inferred user characteristics and corresponding user characteristics of the plurality of other users; and determining the order parameters based on the user characteristics of the identified similar users.

[0014] Example 8, based on the method of Example 3, further includes: accessing purchase criteria corresponding to the user; and automatically purchasing the goods on behalf of the user based on the purchase criteria.

[0015] Example 9 follows the method of Example 8, wherein the purchasing criteria include at least one criterion corresponding to a budget; and wherein the automatic purchase of the goods on behalf of the user is at least partially based on the budget.

[0016] Example 10, according to the method of Example 8, further includes: determining the item category of the product, the purchase criteria including criteria corresponding to the item category; and promoting user purchase of the product based on the purchase criteria corresponding to the determined item category.

[0017] Example 11, according to the method of Example 3, further includes: generating a notification including an option to make a user purchase, the notification including determined order parameters; causing the notification to be presented to the user; receiving a user selection of the option to make a user purchase; and, in response to receiving the user selection, performing the user purchase according to the determined order parameters.

[0018] Example 12, according to the method of Example 11, further includes: identifying presentation parameters for presenting the notification to the user based on inferred user characteristics, the presentation parameters including presentation time and presentation device; and causing the notification to be presented according to the presentation parameters.

[0019] Example 13, according to the method of Example 11, further includes: adapting the presentation of notifications to the user based at least in part on the inferred user characteristics.

[0020] Example 14, based on the method of Example 11, further includes: detecting a user's triggering action based on real-time data included in the attribute data; and presenting a notification to the user based on the detected triggering action.

[0021] Example 15, according to the method of Example 3, further includes: calculating a demand metric for the product based on a demand indication corresponding to the product; and promoting user purchases associated with the product based at least in part on the demand metric.

[0022] Example 16, based on the method of Example 15, further includes: automatically performing a user purchase on behalf of the user based on the demand metric exceeding a threshold.

[0023] Example 17, according to the method of Example 15, further includes: generating a notification that provides the user with the option to purchase goods based on a demand metric exceeding a threshold, the notification including determined order parameters; and causing the notification to be presented to the user.

[0024] Example 18: A machine-readable medium storing instructions that, when executed by at least one processor of a machine, cause the machine to perform operations including: receiving attribute data associated with a user from a plurality of attribute sources; extracting a demand indication from the attribute data, the demand indication indicating the user's expected demand for a particular item; identifying the item based on the extracted demand indication and the attribute data; inferring user characteristics associated with the user based on the attribute data; determining order parameters for a user purchase associated with the item, at least in part based on the inferred user characteristics; and facilitating the user purchase based on the determined order parameters.

[0025] Example 19 is based on the machine-readable medium of Example 18, wherein at least one order parameter includes at least one of quantity, delivery time, payment time, delivery method, delivery destination, merchant, or product.

[0026] Example 20, based on the machine-readable medium of Example 18, further includes: extracting the current inventory level of a product from attribute data; determining an inventory threshold for the product by modeling the use of the product based on the extracted current inventory level and inferred user characteristics; identifying a mismatch between the inventory threshold and the current inventory level; and automatically performing a user purchase on behalf of the user based on the mismatch.

[0027] Example 21 A system includes: an attribute module for receiving attribute data associated with a user from a plurality of attribute sources, the attribute data including real-time data; an authentication module, implemented by a hardware processor of a machine, for identifying a portion of the real-time data that indicates a user identifier, and for authenticating the user identifier with respect to the real-time data based on analysis of the identified portion of the real-time data; and an activity module for authenticating the user identifier in response to analysis of the portion of the real-time data, identifying a user goal that the user is advancing based on the real-time data, and enhancing the user's environment based on user settings to facilitate advancement toward the user goal.

[0028] Example 22, based on the system of Example 21, wherein the authentication module is further configured to: calculate an identity probability metric based on real-time data, the identity probability metric indicating the probability of authentication of a user identifier with respect to the real-time data; and authenticate the user identifier based on the identity probability metric exceeding a threshold.

[0029] Example 23 is based on the system of Example 22, wherein the authentication module is further configured to identify a portable device corresponding to a user based on real-time data, wherein the identity probability metric is based on the identified portable device.

[0030] Example 24 is based on the system of Example 22, wherein the real-time data includes sensor data corresponding to the user, and the identity probability metric is based in part on the sensor data.

[0031] Example 25 is based on the system of Example 22, wherein the authentication module is further configured to: extract a past identification indication from past attribute data corresponding to the user, wherein the attribute data includes past attribute data; extract a real-time identification indication from real-time data corresponding to the user; and calculate an identity probability measure by correlating the real-time identification indication with the past identification indication.

[0032] Example 26 A method includes: receiving attribute data associated with a user from a plurality of attribute sources, the attribute data including real-time data; identifying a portion of the real-time data that indicates the user's identity; using a machine's hardware processor, authenticating the user's identity with respect to the real-time data by analyzing the identified portion of the real-time data; based on the authentication of the user's identity, identifying user activities being performed by the user based on the real-time data; and enhancing user activities according to user settings.

[0033] Example 27, according to the method of Example 26, further includes: calculating an identity probability metric based on an identified portion of real-time data, the identity probability metric indicating the likelihood of authentication of the user's identity with respect to the real-time data; and authenticating the user's identity based on the identity probability metric exceeding a threshold.

[0034] Example 28, according to the method of Example 27, further includes: identifying a portable device corresponding to a user based on real-time data, wherein the identity probability metric is based on the identified portable device.

[0035] Example 29 follows the method of Example 27, wherein the real-time data includes sensor data corresponding to the user, and the identity probability metric is based at least in part on the sensor data.

[0036] Example 30, according to the method of Example 27, further includes: extracting a past identification indicator from past attribute data corresponding to a user, wherein the attribute data includes past attribute data; extracting a real-time identification indicator from real-time data corresponding to a user; and calculating an identity probability measure by correlating the real-time identification indicator with the past identification indicator.

[0037] Example 31, according to the method of Example 27, further includes: adjusting the security level of the authorization task based on the identity probability metric, wherein the user activity includes the authorization task.

[0038] Example 32 follows the method of Example 31, wherein adjusting the security level of the authorization task includes: automatically performing the authorization task on behalf of the user.

[0039] Example 33, according to the method of Example 26, further includes: determining user settings based on attribute data and user activity; and enhancing the user activity based on the determined user settings.

[0040] Example 34, according to the method of Example 33, further includes: inferring user characteristics based on analysis of a portion of the attribute data; determining the user settings based on the inferred user characteristics and the user activities; and enhancing the user activities based on the determined user settings.

[0041] Example 35, according to the method of Example 34, further includes: identifying the similar user based on the inferred user characteristics and the corresponding user characteristics of similar users similar to the user; and determining user settings based on the user characteristics of the identified similar users.

[0042] Example 36, according to the method of Example 26, further includes: determining that the user activity includes presenting a user interface to the user; identifying a presentation device available to the user based on the attribute data, the presentation device being capable of presenting the user interface to the user; determining an alternative presentation device from the identified presentation devices based on the user settings; and causing the user interface to be presented to the user on the alternative presentation device.

[0043] Example 37, according to the method of Example 26, further includes: determining the user's current location based on real-time data; accessing device location data included in attribute data; identifying a user device within the user's operating distance based on the user's current location and the device location data; and enhancing the operation of the identified user device according to the user's settings.

[0044] Example 38, according to the method of Example 26, further includes: identifying user actions of the user based on real-time data, the user actions being in response to enhanced user activities; inferring an enhancement result using the user settings to enhance the user activities; and storing the enhancement result for later determining the user settings.

[0045] Example 39 A machine-readable medium that does not have transient signals and stores instructions, which, when executed by at least one processor of a machine, cause the machine to perform operations including: receiving attribute data associated with a user from a plurality of attribute sources, the attribute data including real-time data; identifying a portion of the real-time data that indicates the user's identity; authenticating the user's identity with respect to the real-time data by analyzing the identified portion of the real-time data; identifying user activities being performed by the user based on the real-time data based on the authentication of the user's identity; and enhancing user activities according to user settings.

[0046] Example 40, based on the machine-readable medium of Example 39, further includes: calculating an identity probability metric based on an identified portion of real-time data, the identity probability metric indicating the likelihood of authentication of the user's identity with respect to the real-time data; and authenticating the user's identity based on the identity probability metric exceeding a threshold.

[0047] Example 41 A system includes: an attribute module for receiving attribute data associated with a user from a plurality of attribute sources; a feature module for inferring user features based on analysis of at least a portion of the attribute data; a visualization module, implemented by a hardware processor of a machine, for generating a visualization at least in part based on the user features, the visualization representing the attribute data; and a presentation module for presenting the visualization to a user.

[0048] Example 42 is a system according to Example 41, wherein the presentation module is further configured to receive user input indicating a change to the visualization, the visualization module is further configured to update the visualization based on the change indicated by the user input, and the feature module is further configured to infer subsequent user features based at least in part on the user input.

[0049] Example 43 is based on the system of Example 42, wherein user input includes user interaction with visualization.

[0050] Example 44, based on the system of Example 41, further includes: an analysis module for identifying similar users similar to the user from among the plurality of other users based on the inferred user characteristics and corresponding user characteristics of the plurality of other users; and the visualization module for generating the visualization based on the user characteristics of the identified similar users.

[0051] Example 45, based on the system of Example 41, further includes an analysis module for determining reward criteria associated with the attribute data; and providing a reward to a user based on the determined reward criteria, wherein the reward includes visual features.

[0052] Example 46 is based on the system of Example 45, wherein the analysis module is further configured to: calculate an integrity metric based on the attribute data, and the reward criteria include a metric based on the integrity metric.

[0053] Example 47 is based on the system of Example 46, wherein the integrity metric indicates the amount of specified type of data included in the attribute data, and the specified type of data is provided by the user to meet the criteria based on the integrity metric.

[0054] Example 48 is based on the system of Example 45, wherein the analysis module is further configured to: calculate a quality metric based on the attribute data, and the reward criteria include criteria based on the quality metric.

[0055] Example 49 is a system based on Example 48, wherein the quality metric indicates the recentity of the attribute data and meets the criteria based on the quality metric by providing recent data by the user.

[0056] Example 50 A method comprising: receiving attribute data associated with a user from a plurality of attribute sources; inferring user characteristics related to the user based on the attribute data, the user characteristics including physical characteristics of the user; generating a virtual avatar representing the user based on the inferred user characteristics using a hardware processor of a machine, the virtual avatar including virtual avatar features corresponding to the user's physical characteristics; and causing a visualization to be presented to the user.

[0057] Example 51, according to the method of Example 50, further includes: receiving user input indicating a change to the virtual avatar; and updating the virtual avatar based on the change indicated by the user input, wherein subsequently inferred user characteristics are inferred at least in part based on the user input.

[0058] Example 52 follows the method of Example 51, wherein the user input includes user interaction with the virtual avatar.

[0059] Example 53, according to the method of Example 50, further includes: identifying similar users similar to the user from among the plurality of other users based on the inferred user characteristics and corresponding user characteristics of the plurality of other users; and determining the virtual avatar characteristics based on the user characteristics of the identified similar users.

[0060] Example 54, according to the method of Example 50, further includes: determining a reward criterion associated with the attribute data; and providing a reward to the user based on the determined reward criterion, wherein the reward includes virtual avatar features.

[0061] Example 55, according to the method of Example 54, further includes: calculating an integrity metric based on the attribute data, wherein the reward criterion includes a criterion based on the integrity metric.

[0062] Example 56 follows the method of Example 55, wherein the integrity metric indicates the amount of specified type of data included in the attribute data, and the specified type of data is provided by the user to meet the criteria based on the integrity metric.

[0063] Example 57, according to the method of Example 54, further includes: calculating a quality metric based on the attribute data, wherein the reward criterion includes a criterion based on the quality metric.

[0064] Example 58 follows the method of Example 57, wherein the quality metric indicates the recentity of the attribute data, and recent data is provided by the user to meet the criteria based on the quality metric.

[0065] Example 59, according to the method of Example 54, further includes: identifying similar users similar to the user from among the plurality of other users based on the inferred user characteristics and corresponding user characteristics of the plurality of other users; and determining whether the reward criteria are met based on attribute data associated with the identified similar users.

[0066] Example 60: A machine-readable medium storing instructions that, when executed by at least one processor of a machine, cause the machine to perform operations including: receiving attribute data associated with a user from a plurality of attribute sources; inferring user characteristics based on the attribute data, the user characteristics being associated with the user; generating a user interface based on the inferred user characteristics, including a virtual avatar representing the user, the user characteristics including physical characteristics of the user, the virtual avatar including virtual avatar features corresponding to the physical characteristics of the user; and causing the user interface to be presented on the user's device. Attached Figure Description

[0067] The accompanying drawings illustrate only exemplary embodiments of this disclosure and should not be considered as limiting the scope of the invention.

[0068] Figure 1 This is a block diagram illustrating a networking system according to some example embodiments.

[0069] Figure 2 This is a block diagram illustrating an example embodiment of a data grid system according to some example embodiments.

[0070] Figure 3 This is a block diagram illustrating an example embodiment of an assistive activity system according to some example embodiments.

[0071] Figure 4 Examples of generating assistive activities from a user device are shown, based on some example embodiments.

[0072] Figure 5 This is a flowchart illustrating an example method for generating assistive activities from a user device, according to some example embodiments.

[0073] Figure 6 This is a flowchart illustrating some of the operations for inferring user preferences based on attribute data, according to some example embodiments.

[0074] Figure 7 and Figure 8 This is a flowchart illustrating, according to some example embodiments, for facilitating the identification of other operations from a user device.

[0075] Figure 9 and Figure 10This is a flowchart illustrating further operations for generating assistive activities from a user device, according to some example embodiments.

[0076] Figure 11 An example scenario illustrating the presentation of assistive activities to a user is shown according to some example embodiments.

[0077] Figure 12 and Figure 13 An example user interface for presenting assistive activities is depicted according to some example embodiments.

[0078] Figure 14 This is a block diagram illustrating an example embodiment of a user analytics system according to some example embodiments.

[0079] Figure 15 This is a flowchart illustrating an example method for identifying items and facilitating purchases associated with the identified items, according to some example embodiments.

[0080] Figure 16 This is a flowchart illustrating some of the operations for facilitating purchases based at least in part on an assessment of inventory levels, according to some example embodiments.

[0081] Figure 17 This is a flowchart illustrating some of the operations, including the operation of determining the parameters of the purchase, for facilitating a purchase according to some example embodiments.

[0082] Figure 18 This is a flowchart illustrating some of the operations for determining order parameters, including the operation of determining time parameters associated with the purchase, according to some example embodiments.

[0083] Figure 19 This is a flowchart illustrating some other operations that facilitate purchases based at least in part on purchase criteria, according to some example embodiments.

[0084] Figure 20 This is a flowchart illustrating another example method for identifying items and facilitating purchases, based on some example embodiments.

[0085] Figure 21 This is a flowchart illustrating alternative example methods for identifying items and facilitating purchases, according to some example embodiments.

[0086] Figure 22 This is a flowchart illustrating some other operations that facilitate purchasing based at least in part on demand metrics, according to some example embodiments.

[0087] Figure 23 This is a flowchart illustrating some of the operations that use notifications to facilitate purchases, based on some example embodiments.

[0088] Figure 24 and Figure 25 This is a flowchart illustrating some other operations for presenting a notification, according to some example embodiments.

[0089] Figure 26 This is a flowchart illustrating communication between various devices related to presenting notifications to a user, according to some example embodiments.

[0090] Figure 27 An example user interface for facilitating purchases is depicted according to some example embodiments.

[0091] Figure 28 and Figure 29 Examples are shown of identifying items and facilitating purchases associated with the identified items, according to some example embodiments.

[0092] Figure 30 This is a block diagram illustrating an example embodiment of an enhanced system according to some example embodiments.

[0093] Figure 31 This is a flowchart illustrating example methods for authenticating users and enhancing user activities according to some example embodiments.

[0094] Figure 32 and Figure 33 This illustrates some example embodiments. Figure 31 Flowcharts for some other example operations of the method.

[0095] Figure 34 The communication between a user device and a data grid system according to some example embodiments is described.

[0096] Figures 35 to 38 This illustrates some example embodiments. Figure 31 The flowchart shows some other example operations of the method.

[0097] Figure 39 Enhancements to example user activities are shown according to some example embodiments.

[0098] Figure 40 An enhanced example user interface for facilitating user activity is depicted according to some example embodiments.

[0099] Figure 41 This illustrates methods for promoting, according to some example embodiments. Figure 31 The flowcharts for various communication methods.

[0100] Figure 42 This is a block diagram illustrating an example embodiment of a visualization system according to some example embodiments.

[0101] Figure 43 This is a flowchart illustrating an example method for generating visualizations according to some example embodiments.

[0102] Figure 44 This illustrates some example embodiments. Figure 43 The flowchart shows some other example operations of the method.

[0103] Figure 45 This is a flowchart illustrating an example method for determining whether a reward criterion is met, according to some example embodiments.

[0104] Figure 46 This illustrates some example embodiments. Figure 43 The flowchart shows some other example operations of the method.

[0105] Figure 47 This illustrates methods for promoting, according to some example embodiments. Figure 43 The flowcharts for various communication methods.

[0106] Figure 48 , Figure 49 , Figure 50A and Figure 50B An example user interface, including example visualizations, is depicted according to some example embodiments.

[0107] Figure 51A and Figure 51B Example configurations for communicatively coupling attribute sources are depicted according to some example embodiments.

[0108] Figure 52 Various example property sources are described according to some example embodiments.

[0109] Figure 53 Various components that provide attribute data according to some example embodiments are described.

[0110] Figure 54 It is a block diagram of an example data structure (e.g., attribute data associated with a user) based on some example embodiments.

[0111] Figure 55 It is a block diagram of an example data structure (e.g., attribute data associated with a device) based on some example embodiments.

[0112] Figure 56 This is a block diagram illustrating an example of a software architecture that can be installed on a machine according to some example embodiments.

[0113] Figure 57A schematic representation of a machine in the form of a computer system according to an example embodiment is shown, in which a set of instructions can be executed to cause the machine to perform any one or more of the methods discussed herein. Detailed Implementation

[0114] The following description includes systems, methods, techniques, instruction sequences, and computer program products embodying exemplary embodiments of the present disclosure. In the following description, numerous details are set forth for purposes of explanation to provide an understanding of various embodiments of the subject matter of the invention. However, it will be apparent to those skilled in the art that embodiments of the subject matter of the invention can be practiced without these specific details. Generally, well-known examples of instructions, protocols, structures, and techniques need not be shown in detail.

[0115] Users of modern technologies typically have a variety of devices for performing various tasks, such as laptops, smart TVs, smartphones, and wearable devices. Traditionally, users of such devices operate a single device to perform one task at a time. The following discussion describes systems and methods that, in some embodiments, utilize multiple devices to perform auxiliary, complementary, or supplementary activities associated with a specific activity or task in real time. In some embodiments, the systems and methods distribute a portion of a specific activity or task across multiple devices. Auxiliary or supplementary activities associated with a specific device activity can be determined based on various factors, including inferred user preferences, device capabilities, and device activity. Therefore, auxiliary activities are dynamically determined and performed in real time for the user to assist in the device activity.

[0116] In various example embodiments, device activity performed in real time by the user's device is detected. For example, a user might be browsing websites on a mobile device or laptop. Once device activity is detected, user-associated attribute data from multiple attribute sources is accessed. In various example embodiments, attribute data is received or accessed from a wide range of attribute sources, such as mobile devices, smart devices, smart home devices, social networking services, user profiles, browsing history, purchase history, etc.

[0117] Inferring user preferences indicates a user's preference or expectation to perform auxiliary, supplementary, complementary, or accompanying activities from the user's device that correspond to device activities. For example, analysis of attribute data can indicate that a user wants to view supplementary content corresponding to device activities. In this example, auxiliary activities include presenting supplementary content to the user from the user's device.

[0118] According to some example embodiments, a user device can be identified based on its device state, based on inferred user preferences. In various implementations, device state indicates the device's ability to perform assistive activities in real time. For example, if the assistive activity involves presenting content to the user, the user device may not be able to perform such a task if it is not near the user (e.g., within the user's presentation distance).

[0119] Once the slave user device is identified, assistive activities to be executed in real time on the slave user device are generated by analyzing device activity, device functions, and user preferences. For example, if device activity includes providing direction to the user, the assistive activity may include providing content associated with providing direction, such as the readout current orientation or distance to the destination. In various implementations, the assistive activity is either executed on the slave user device or transmitted to the slave user device with instructions to execute the assistive activity in real time.

[0120] According to other embodiments, the goal of zero-effort shopping is to reduce or eliminate the effort consumer users put into purchasing various products. To this end, among other functions, the systems and methods described herein can access a large amount of attribute data associated with a user, analyze the attribute data to identify items the user may need, and facilitate purchases associated with the identified items. For example, a user can be characterized based on the analysis of the attribute data, and the user characterization can be used as the basis for order parameters for identifying items and purchases associated with the identified items. The collective and aggregated attribute data can be referred to as a “data grid.”

[0121] In various example embodiments, attribute data is received or accessed from a wide range of attribute sources, such as mobile devices, smart devices, smart homes, social networking services, user profiles, browsing history, purchase history, etc. Demand indications, indicating a user's anticipated need for a specific item, are extracted from the attribute data. For example, purchase history may indicate previous purchases of coffee products, location data (e.g., determined by a mobile device's GPS component, beacon detection, or other location services) may indicate frequent visits to coffee shops, or social media data (e.g., a user's check-in or posting) may indicate a preference for coffee shops. After extracting the demand indications, goods can be identified based on the extracted demand indications according to the attribute data. Continuing with the above examples, the identified goods may include coffee beans, coffee filters, or other coffee-related items.

[0122] In other example embodiments, user characteristics related to a user are inferred based on analysis of a portion of attribute data. User characteristics include, for example, traits, qualities, actions, activities, attitudes, health conditions, habits, behaviors, etc. For example, user characteristics may include a specific medical condition associated with the user's dietary restrictions. The systems and methods described herein can facilitate purchases associated with goods based at least in part on user characteristics. In example embodiments, a notification including the option to make a purchase is presented to the user. In some instances, notifications are personalized to the user based on user characteristics (e.g., notifications may be presented on the user's preferred device at a time corresponding to the user's availability, such as after the user has finished work). In some example embodiments, purchases are made automatically on behalf of the user. For example, a demand metric is calculated based on a demand indication, and if the demand metric exceeds a threshold, the purchase can be executed automatically. Therefore, the systems and methods described herein can facilitate business activities on behalf of users to increase the convenience of users conducting business activities and reduce time and effort. In some cases, the systems and methods analyze attribute data to simulate user decisions regarding various shopping or purchase-related activities.

[0123] According to other embodiments, attribute data, including real-time data, can be received from multiple attribute sources; users can be authenticated based on the analysis of the attribute data; user activity can be identified based on the attribute data; and user activity can be enhanced based on user settings. Attribute data may include data received from a wide range of attribute sources, such as mobile devices, smart devices, smart homes, social networking services, user profiles, browsing history, purchase history, etc.

[0124] After receiving the attribute data, the portion of the real-time data that indicates the user's identity can be identified. For example, real-time data may include the location of the user's mobile device, sensor data from the user's device, etc. In example embodiments, the user's identity can be authenticated based on the analysis of the identified portion of the real-time data. For example, the location of the user's mobile device can indicate the user's location, and if the user's device is within a certain distance of a currently used internet device, it can be inferred that the user is currently using an internet device. Many other indicators of user identity can be used to authenticate the user's identity. In other example embodiments, an identity probability metric can be calculated based on the analysis of the attribute data. In some example embodiments, the user's identity can be authenticated when the identity probability metric exceeds a threshold.

[0125] In other example embodiments, user activities can be identified based on real-time data, based on user authentication. For example, a user might be using a website, jogging, or moving into a room (e.g., from the living room to the kitchen). User activities can be enhanced based on user settings. In a specific example, a user might be using a website to log in, and based on user authentication, the security of the website login could be reduced or the user could be automatically logged in. In another specific example, a user could stream media from the living room to an internet-connected device (e.g., a media entertainment system displayed on a monitor), and the streaming could continue in the kitchen (e.g., to a smart refrigerator including a monitor) as the user moves from the living room. Many other user activities can be enhanced in various ways.

[0126] According to other embodiments, visualizations can be generated at least in part based on attribute data associated with a user. In example embodiments, attribute data can be received from a wide range of attribute sources. For example, attribute data may include user-associated data received from mobile devices, smart devices, smart homes, social networking services, user profiles, browsing history, or purchase history. Collective and aggregated attribute data may be referred to as a “data grid.” After receiving the attribute data, user characteristics can be inferred based on the analysis of at least a portion of the attribute data. In various example embodiments, user characteristics may be traits, qualities, actions, activities, attitudes, health conditions, habits, behaviors, etc. For example, a user's physical characteristics, such as height, weight, fitness level, etc., can be inferred or measured directly from the attribute data. In example embodiments, visualizations can be generated at least in part based on user characteristics. The visualization can represent the attribute data. For example, the visualization can be a virtual image including physical characteristics similar to the user's physical characteristics. In this example, the visualization can represent the user. The visualization can be presented to the user.

[0127] In other example embodiments, the user can provide user input indicating changes to the visualization. The visualization can be updated based on the changes indicated by the user input. Subsequent inferences about user characteristics can be based at least in part on the user input. For example, if the visualization does not accurately reflect user or attribute data, the user can modify the visualization. This modification can then be used as the basis for generating a more accurate visualization or for more accurately inferring user characteristics.

[0128] In other example embodiments, rewards may be provided to users based on determined reward criteria. For example, reward criteria may include criteria for completing a physical activity, such as a certain number of steps determined by a pedometer (e.g., an application running on the user's mobile device that can determine walking). Based on exceeding a threshold number of steps, the user can meet the reward criteria. In example embodiments, rewards may include additional visual features (e.g., additional accessories or functions for visualization). In another instance, reward criteria may be associated with the completeness of a profile. In this instance, the more information the user provides or the more information they have access to, the closer the user is likely to meet the reward criteria.

[0129] refer to Figure 1 This illustrates an example embodiment of an advanced client-server based network architecture 100. Networking system 102 provides server-side functionality to client device 110 via network 104 (e.g., the Internet or a wide area network (WAN)). Users (e.g., user 106) can interact with networking system 102 using client device 110. Figure 1 The illustration shows, for example, a network client 112 (e.g., a browser, such as Internet Explorer developed by Microsoft Corporation of Redmond, Washington), a client application 114, and a programming client 116 running on client device 110. Client device 110 may include network client 112, client application 114, and programming client 116 individually, together, or in any suitable combination. Although Figure 1 A client device 110 is shown, but the network architecture 100 may include multiple client devices.

[0130] Client device 110 may include a computing device, which includes at least a display and communication capabilities to provide access to networked system 102 via communication network 104. Client device 110 includes, but is not limited to: remote devices, workstations, computers, general-purpose computers, internet devices, handheld devices, wireless devices, portable devices, wearable computers, cellular or mobile phones, personal digital assistants (PDAs), smartphones, tablets, ultrabooks, netbooks, laptops, desktops, multiprocessor systems, microprocessor-based or programmable consumer electronics devices, game consoles, set-top boxes, network PCs, minicomputers, etc. In other example embodiments, client device 110 includes one or more of the following: touchscreen, accelerometer, gyroscope, biometric sensor, camera, microphone, Global Positioning System (GPS) device, etc.

[0131] Client device 110 can communicate with network 104 via a wired or wireless connection. For example, one or more parts of network 104 can be an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), a part of the Internet, a part of the public switched telephone network (PSTN), a cellular telephone network, a wireless network, or Wi-Fi. A network, a global microwave access interoperability (WiMax) network, another type of network, or a combination of two or more such networks.

[0132] Client device 110 may include one or more applications (also referred to as “apps”), such as, but not limited to, web browsers, book reader applications (operable to read ebooks), media applications (operable to present various media formats including audio and video), fitness applications, biometric monitoring applications, messaging applications, email applications, e-commerce website applications (also referred to as “marketplace applications”), etc. Client application 114 may include various components operable to present information to a user and communicate with networked system 102. In some embodiments, if an e-commerce website application is included in client device 110, the application may be configured to natively provide a user interface and at least some of the functionality, wherein the application is configured to communicate with networked system 102 as needed to obtain data or processing capabilities not available locally (e.g., access to a database of items available for sale, user authentication, payment method verification, etc.). Conversely, if an e-commerce website application is not included in client device 110, client device 110 may use its web browser to access an e-commerce website (or a variant thereof) hosted on networked system 102.

[0133] In various example embodiments, the user (e.g., user 106) can be a person, a machine, or other device that interacts with client device 110. In some example embodiments, the user may not be part of network architecture 100, but may interact with network architecture 100 via client device 110 or another device. For example, the user may interact with client device 110, which is operable to receive input information from the user (e.g., using touchscreen input or alphanumeric input) and present information to the user (e.g., using graphics on a device display). In this example, the user may, for example, provide input information to client device 110 to be transmitted to networking system 102 via network 104. Networking system 102, in response to the received input information, transmits the information to client device 110 via network 104 to be presented to the user. In this way, the user can interact with networking system 102 using client device 110.

[0134] Application Programming Interface (API) server 120 and web server 122 may be coupled to one or more application servers 140, and provide programming and network interfaces to the application servers 140, respectively. In various implementations, application server 140 houses one or more publishing systems 142, payment systems 144, and data grid systems 150, each system comprising one or more modules or applications, and each system is implemented as hardware, software, firmware, or any combination thereof. Accordingly, application server 140 is shown coupled to one or more database servers 124, which facilitate access to one or more information repositories or databases 126. In example embodiments, database 126 is a storage device where information to be published (e.g., posts or listings) is stored in publishing system 142. According to some example embodiments, database 126 stores digital goods information.

[0135] Additionally, a third-party application 132 executing on third-party server 130 is shown to have programmable access to networked system 102 via a programming interface provided by API server 120. For example, third-party application 132 uses information retrieved from networked system 102 to support one or more features or functions on a website hosted by the third party. For example, the third-party website provides one or more promotional, marketing, or payment functions supported by related applications of networked system 102.

[0136] Publishing system 142 provides multiple publishing functions and services to users accessing networked system 102. Payment system 144 similarly provides multiple functions to execute or facilitate payments and transactions. Although publishing system 142 and payment system 144 are... Figure 1 Both are shown as part of network system 102; however, it should be understood that in alternative embodiments, each system 142 and 144 may form part of a separate and distinct payment service from network system 102. In some example embodiments, payment system 144 may form part of publishing system 142.

[0137] According to various embodiments, data grid system 150 provides the functionality to receive, retrieve, or store a wide range of data associated with a user. It will be noted that collective and aggregated attribute data is sometimes referred to as a “data grid.” Data grid system 150 stores, for example, the received data in a storage device such as database 126. In some example embodiments, data grid system 150 communicates with client device 110, third-party server 130, publishing system 142 (e.g., a search list), and payment system 144 (e.g., a purchase list). In alternative example embodiments, data grid system 150 may be part of publishing system 142.

[0138] In addition, although Figure 1 The client-server based network architecture 100 shown adopts a client-server architecture, but the subject matter of the present invention is certainly not limited to this architecture and can also be well applied to, for example, distributed or peer-to-peer architecture systems. Various systems of application server 140 (e.g., publishing system 142 and payment system 144) can also be implemented as stand-alone software programs that do not necessarily have networking capabilities.

[0139] Network client 112 can access various systems of network system 102 (e.g., publishing system 142) via the network interface supported by network server 122. Similarly, programming client 116 and client application 114 can access various services and functions provided by network system 102 via the programming interface provided by API server 120. For example, programming client 116 could be a seller application (e.g., developed by a company in San Jose, California). The company developed the TurboLister application, which enables sellers to create and manage listings on the networked system 102 offline and performs batch mode communication between the programming client 116 and the networked system 102.

[0140] Figure 2 This is a block diagram of a data grid system 150, which provides functions such as receiving, retrieving, or accessing attribute data from attribute sources, analyzing attribute data, and managing attribute data. In an example embodiment, the data grid system 150 may include a presentation module 210, a communication module 220, an attribute module 230, a feature module 240, a management module 250, an auxiliary activity system 260, a user analysis system 270, an enhancement system 280, and a visualization system 290. Figure 2 All or some of the modules 210-290 can communicate with each other, for example, via network coupling, shared memory, etc. It should be understood that each module in 210-290 can be implemented as a single module, combined into other modules, or further subdivided into multiple modules. Other modules not related to the example embodiment may also be included, but are not shown.

[0141] refer to Figure 2The presentation module 210 provides various presentation and user interface functions operable to interactively present and receive information from a user. For example, the presentation module 210 causes various notifications or user interfaces to be presented, which provide the user with options to make purchases associated with identified items. The presentation module 210 uses various means, including visually displaying information and using other device outputs (e.g., acoustic, haptic), to present or cause information to be presented. Interactive presentation is intended to include the exchange of information between the device and the user. The user can provide input in various ways to interact with the user interface, including alphanumeric input, cursor input, haptic input, or other inputs (e.g., one or more of a touchscreen, camera, haptic sensor, light sensor, infrared sensor, biometric sensor, microphone, gyroscope, accelerometer, or other sensors). It should be understood that the presentation module 210 provides many other user interfaces to facilitate the functions described herein. Furthermore, it should be understood that the term "presentation" as used herein is intended to include transmitting information to another device that is operable to perform presentation using the transmitted information.

[0142] Communication module 220 provides various communication functions and network services. For example, communication module 220 provides network communication, such as communication with networked system 102, client device 110, and third-party server 130. In various example embodiments, network communication operates via wired or wireless means. Network services are intended to include retrieving information from third-party server 130, database 126, and application server 140. The information retrieved by communication module 220 includes data associated with a user (e.g., user profile information from an online account, social networking service data associated with the user), data associated with one or more items listed on an e-commerce website (e.g., images of items, reviews of items, item prices), and other data used to facilitate the functions described herein.

[0143] The attribute module 230 can receive, access, or retrieve various attribute data from many different attribute sources. For example, the attribute module 230 can receive, retrieve, or access attribute data from user devices or machines (e.g., client device 110), social networking services, third-party servers 130, publishing systems 142, payment systems 144, other application servers, or other attribute sources. As used herein, attribute data is intended to include raw data such as sensor data, profile data, social network content, etc.

[0144] In some example embodiments, the attribute module 230 extracts attribute data from various sources. For example, a user's payment history log may include a large amount of external data. The attribute module 230 can extract purchase information from the user's payment history log, such as the purchased item, time, purchase price, seller, location, brand, etc.

[0145] In other example embodiments, attribute module 230 performs various functions to prepare or condition attribute data for analysis. For example, attribute module 230 standardizes attribute data to facilitate its analysis (e.g., determining a canonical form to allow for comparisons and other mathematical analyses). Attribute module 230 performs many other functions to prepare attribute data for analysis.

[0146] In various example embodiments, attribute module 230 stores attribute data in association with users for subsequent analysis. For example, attribute module 230 stores attribute data in database 126. Attribute data may be stored in conjunction with user identifiers, allowing attribute module 230 to later access attribute data corresponding to a specific user using the user identifier. Attribute module 230 uses other methods to access the stored attribute data. For example, attribute module 230 accesses portions of the attribute data associated with time, item, user, user type, specific attribute source, etc. In this way, attribute module 230 accesses a portion of the attribute data based on various parameters from a large amount of attribute data to access, identify, or find relevant and related data.

[0147] Feature module 240 infers one or more user features corresponding to a user based on the analysis of at least a portion of the attribute data. Many schemes and techniques can be employed to infer features from attribute data. For example, a specific user feature could be the user's work location. Attribute data can include multiple locations, including timestamps (e.g., determined by the GPS component of the user's device). The user's work location can be inferred based on the consistency and timing of the locations included in the attribute data (e.g., the user is typically in a specific office building during normal working hours). Many different portions of the attribute data and combinations of these portions can be analyzed to infer a wide variety of features.

[0148] In various example embodiments, features such as those used herein (e.g., user features) are intended to include characteristics, qualities, actions, activities, attitudes, habits, behaviors, etc., that are related to one or more people. Because attribute data may not necessarily be related to a person (e.g., raw data, such as coordinates of a specific location), features (e.g., a user's current location, dislike of spicy food, having young children, being a Star Trek fanatic) can be distinguished from attribute data.

[0149] Management module 250 provides management functions associated with attribute data. For example, management module 250 provides users with the ability to edit, modify, update, or otherwise control attribute data. For instance, users can use the functions provided by management module 250 to remove unwanted attribute data. In another instance, users use the functions provided by management module 250 to specify permissions for a portion of the attribute data. Permissions allow or prohibit certain access to or use of the attribute data (e.g., a permission prohibits third parties from accessing the attribute data). Various levels of access rights and capabilities can be granted. In some example embodiments, permissions last for a period of time and are revoked after the period expires.

[0150] In other example embodiments, management module 250 requests user consent to access a portion of the attribute data or requests permission for certain uses of the attribute data. For example, management module 250 requests user consent to allow a third party to access a portion of the attribute data. Management module 250 requests various other consents associated with various actions corresponding to the attribute data.

[0151] In other example embodiments, management module 250 provides functionality that allows third parties to access attribute data or user characteristics. For example, management module 250 provides a set of APIs that can be invoked by third parties to access attribute data or user characteristics. As described above, in some example embodiments, user permission or consent is determined before granting access to attribute data.

[0152] Figure 3 This is a block diagram of an assistive activity system 260, which can provide functionality to generate assistive activities based on various triggers and information. According to an example embodiment, the assistive activity system 260 includes an activity module 310, a preference module 320, and a device module 330.

[0153] The activity module 310 in the auxiliary activity system 260 provides functionality for generating auxiliary, supplementary, complementary, or accompanying activities corresponding to device activities. For example, a user may be browsing a website, and the activity module 310 generates auxiliary activities, including providing the user with interactive content, such as options to share the website, like the website, or announce (e.g., tweet) the website. The activity module 310 generates many other auxiliary activities corresponding to device activities based on various triggers and information.

[0154] Preference module 320 provides the functionality to infer user preferences based on attribute data, thereby indicating user preferences associated with auxiliary activities performed from the user's device corresponding to device activities. For example, preference module 320 infers that the user expects or prefers a specific type of content associated with a particular device activity. Preference module 320 also identifies other users similar to the user and infers user preferences based on the identified similar users. Preference module 320 employs various schemes and techniques that utilize extensive data to infer user preferences.

[0155] Device module 330 provides the ability to identify the functionality of a slave user equipment based on its device state. In various implementations, device state indicates the device's ability to perform auxiliary activities in real time. Device module 330 retrieves, derives, determines, or otherwise obtains various information associated with the user equipment and slave user equipment to facilitate the functionality described herein. For example, device module 330 determines the available functionality of the slave user equipment.

[0156] Figure 4 A schematic diagram 400 illustrates an example of generating assistive activities from a user device according to some example embodiments. User 410 may be using a wearable device such as Google... This refers to a wearable computing device, such as a wearable device 430 (e.g., a smartwatch). In this example, the wearable device 430 is communicatively coupled to the user equipment 450 via a wireless signal (e.g., signal 440). In various implementations, the user equipment 450 is communicatively coupled to a network 104 via coupling 460, and the network 104 is in turn communicatively coupled to a data grid system 150 (described above). Figure 2 (Discussion) and Assistive Activity System 260 (combined with the above) Figure 3 (Discussion) Networked system 102.

[0157] User 410 may be operating or using user device 450. As used herein, the terms “operating,” “using,” “serving,” or “in use” are intended to include physical interaction between a particular user and a particular device that enables the user to operate the device as a dormant or standby device for a short period of time (e.g., a particular user carrying a mobile device and not currently physically interacting with the device is included in the terms “operating,” “using,” or “in use”), or otherwise using the particular device (e.g., a smart refrigerator not near the user that is configured to track inventory levels and provide inventory data).

[0158] In example schematic 400, user 410 carries user equipment 450 communicatively coupled to assistive activity system 260. Activity module 310 detects device activity of user equipment 450. For example, user 410 may be using user equipment 450 to browse the web, receive directions to a specific location, or monitor fitness activities such as a certain number of steps.

[0159] Once the activity module 310 detects device activity, the preference module 320 infers user preferences based on attribute data accessed by the attribute module 230. User preferences indicate a user's preference or expectation for performing specific assistive activities corresponding to device activity on a specific user device. For example, the preference module 320 infers that user 410 wants to see options on a specific wearable device associated with saving, sharing, and posting announcements (e.g., tweeting) related to the web pages that user 410 is browsing on user device 450.

[0160] Based on inferred user preferences, device module 330 identifies the user device based on its device state. Device state indicates the device's ability to perform assistive activities. For example, device module 330 identifies wearable device 430 as the user device based on the device state corresponding to it. In this example, device module 330 determines that wearable device 430 is being used by user 410 (e.g., user 410 is wearing wearable device 430). Therefore, wearable device 430 is operable to perform assistive activities because it can provide options for user 410 to choose from when user 410 is within its operating range.

[0161] After device module 330 identifies the user device, activity module 310 generates an auxiliary activity to be executed in real time on the user device. Activity module 310 generates the auxiliary activity by analyzing device activity, device functions of the user device, user preferences, and other data. Device functions indicate the options available for input and output on the user device. For example, the identified user device is a wearable device 430 with a small screen area for displaying the user interface or with reduced output options (e.g., no speaker). In a specific instance, activity module 310 generates an auxiliary activity that includes reduced activity content based on device functions (e.g., small display size).

[0162] After the activity module 310 generates the auxiliary activity, the activity module 310 sends or otherwise transmits it to the user equipment to execute the auxiliary activity in real time.

[0163] Figure 5This is a flowchart illustrating an example method 500 for generating assistive activities from a user device, according to some example embodiments. In operation 510, activity module 310 detects device activities being performed in real time by the user's user device. The term "real-time data" as used herein is intended to include data associated with currently occurring events. For example, real-time executed device activities include: specific device activities detected at activity module 310 after a delay interval (e.g., due to transmission delays or other delays such as temporary storage at an intermediate device) between the moment a particular device activity occurs and after activity module 310 detects the particular device activity. Therefore, in some instances, real-time executed device activities are intended to include activities that have occurred within a short period in the past. Other uses of the term "real-time" are also applicable throughout the specification.

[0164] In various embodiments, device activities include a wide variety of activities, such as browsing the web, monitoring fitness activities (e.g., a user walking), heart rate monitoring, inventory level monitoring (e.g., a smart refrigerator monitoring inventory), and so on. In some implementations, the activity module 310 detects device activities being performed by the user's monitoring device. For example, the user's smart device provides continuous or periodic data streams indicating various device activities.

[0165] In operation 520, attribute module 230 accesses user-associated attribute data from multiple attribute sources. In various example embodiments, at least a portion of the attribute data includes real-time or near-real-time data. For example, real-time data includes user input data or sensor data that is transmitted to attribute module 230 after a delay interval between data capture and data reception by attribute module 230 (e.g., due to transmission delays or other delays, such as temporary storage at an intermediate device).

[0166] If combined Figure 52 and Figure 53 The discussion concerns receiving attribute data from a wide range of attribute sources (e.g., devices, sensors, servers, databases, and others). Furthermore, the attribute module 230 receives or accesses attribute data via numerous paths resulting from the classification of attribute sources by configuration, such as combining... Figure 51A and Figure 51BFurther discussion follows. In an example embodiment, attribute module 230 receives attribute data directly from an attribute source. In other example embodiments, attribute module 230 receives attribute data from a central device, wherein the central device receives attribute data from multiple user devices. In other example embodiments, various user devices are communicatively coupled in a decentralized device-to-device grid, and attribute module 230 receives attribute data corresponding to a specific device in the grid from any device in the grid. Attribute module 230 receives attribute data from the attribute source through many other configurations, including various suitable combinations of configurations.

[0167] In various example embodiments, attribute module 230 stores attribute data in association with users (e.g., indexed based on user identifiers) for subsequent analysis. Attribute module 230 stores attribute data in a storage device such as database 126. Attribute module 230 uses various search or lookup schemes to access the stored attribute data. For example, attribute data associated with a specific user is accessed using a user identifier corresponding to that specific user. It will be noted that collective and aggregated attribute data is sometimes referred to as a "data grid."

[0168] In operation 530, preference module 320 infers user preferences or desired user settings based on attribute data, which indicate the user's preference for performing assistive activities corresponding to device activities from the user's device. For example, attribute data includes user engagement data indicating the types of information the user is interested in (e.g., specific websites visited, clicks, taps, or other interactions with various notifications). In a particular example, preference module 320 infers user preferences for receiving notifications associated with a specific sporting event based on engagement data.

[0169] In this particular example, activity module 310 detects from a user device (e.g., a smart TV) that device activity includes watching sports events. Continuing with this example, preference module 320 infers user preferences based on past notifications of interest to the user included in attribute data, indicating that the user favors notifications associated with watching sports events on a particular slave device.

[0170] Now refer to Figure 6 The diagram illustrates flowcharts of further operations for inferring user preferences based on attribute data, according to some example embodiments. As described above, following operation 520, in operation 530, the preference module 320 infers user preferences based on the attribute data.

[0171] In operation 610, the feature module 240 infers or directly measures user characteristics related to the user based on attribute data. In some example embodiments, the feature module 240 stores the inferred user characteristics in a storage device such as database 126 for subsequent analysis. The feature module 240 infers a large number of broad user characteristics based on attribute data. Some specific examples of user characteristics include: demographic data (e.g., age, gender, marital status, number of children), user preferences (e.g., early riser, favorite location, preference for spicy food), traits (e.g., forgetfulness, such as running out of a mobile device's battery; or impatience, such as a route-breaker who will leave a store if the route is too long), qualities (e.g., robust physique, tall stature, large vocabulary), personality traits (e.g., adventurer), actions, activities (e.g., working for a nonprofit), attitudes, habits (e.g., coffee drinker), behaviors, beliefs, biases, mannerisms, and the user's physical characteristics (e.g., height, weight, clothing size, eye color, hair color). The specificity of the feature range ranges from very narrow (e.g., drinking a particular brand of soda) to very broad (e.g., generally philanthropic). In one example, to illustrate inferring user characteristics based on attribute data, the attribute data includes user location data indicating frequent visits to local schools, local soccer fields, etc. In this example, feature module 240 infers that the user has children based on the types of locations the user might frequently visit.

[0172] In some instances, feature module 240 performs varying degrees of inferential analysis on attribute data to derive user characteristics. For example, feature module 240 infers a user's wake-up time based on user device activity or other activities (e.g., connected alarm settings, account logins, and various other user activities indicating wake-up time). In this example, feature module 240 infers specific user characteristics that may have large inference jumps, such as the user being an early riser or a sleeper. The degree of inference jumps can be configurable. In some example embodiments, feature module 240 uses various techniques to minimize or otherwise control incorrect inferences (e.g., machine learning, other learning algorithms).

[0173] In other example embodiments, the feature module 240 learns, adapts, or evolves (e.g., via machine learning techniques or other learning algorithms) as more attribute data is received. For example, the attribute data includes the user's location data. The feature module 240 infers the user's preferred location based on patterns in the location data (e.g., frequently visited locations). However, the feature module 240 subsequently receives employment data indicating the user's current employer, which includes the employer's location. The feature module 240 learns, updates, or otherwise adapts to take the new attribute data into account. Thus, in this example, if the location is the user's work location, the feature module 240 may not infer the user's preferred location. In one instance, the user can directly provide input (e.g., via a user interface configured to receive inference guidance from the user) to facilitate the feature module 240 inferring features based on attribute data (e.g., user input indicating that a particular inferred feature is incorrect or providing input to be used as the basis for future inferences).

[0174] In other instances, the feature module 240 performs little or no analysis to derive user characteristics from attribute data. For example, the attribute data might include alarm time settings from a connected alarm clock (e.g., a smartphone with an alarm clock app). Alarm time settings directly indicate wake-up time. Because the attribute data is directly related to specific user characteristics, the feature module 240 does not need to perform analysis to derive user characteristics.

[0175] In some example embodiments, user characteristics include predefined characteristics or dynamically determined characteristics. For example, a specific set of characteristics may be predefined (e.g., work location, home location, marital status, socioeconomic status). In this example, the feature module 240 determines that a specific predefined characteristic is associated with the user based on analysis of attribute data. In other examples, the feature module 240 dynamically determines characteristics based on attribute data. For example, the attribute data indicates that the user owns a specific exotic pet. Although there may not be a predefined characteristic associated with a specific exotic pet, the feature module 240 determines the user characteristic of owning an exotic pet based on the attribute data.

[0176] In operation 620, preference module 320 identifies similar users to the user based on the inferred user characteristics and corresponding user characteristics of multiple other users. Preference module 320 identifies similar users to the user based on various factors. In some example embodiments, preference module 320 accesses attribute data or stored user characteristics corresponding to multiple other users. For example, preference module 320 identifies similar users among multiple other users based on the inferred user characteristics of the user and corresponding user characteristics of multiple other users. Preference module 320 correlates, matches, or otherwise compares the inferred user characteristics with the corresponding user characteristics of multiple other users to identify similar users. In various example embodiments, preference module 320 identifies similar users based on identical or similar demographic data (e.g., identical or similar age, marital status, gender, geographic location, etc.), identical or similar user characteristics (e.g., identical or similar brand purchases), identical or similar attribute data, and so on.

[0177] In operation 630, the preference module 320 infers user preferences or desired user settings based on identified similar users. For example, the preference module 320 analyzes the user characteristics of identified similar users to determine user preferences. In a specific example, if the user characteristics of identified similar users indicate a preference for watching specific content on a particular user device, then the preference module 320 infers that the user also has the same or similar preference for watching specific content on a particular user device. In this way, the preference module 320 infers user preferences based on identified similar users.

[0178] Return Reference Figure 5 In operation 540, device module 330 identifies the user equipment based on its device status. Device status indicates the device's ability to perform auxiliary activities in real time. Device capabilities include various metrics and characteristics associated with the user equipment. In various implementations, device module 330 identifies the user equipment based on device status based on various combinations of factors discussed below. For example, device status may be based on device capabilities including the distance from the user equipment to the user, as combined below. Figure 7 Further discussion is needed. For example, if the user device is near the user, the user device can present information or notifications to the user.

[0179] In another example, the device state is based on a specific function of the device. Device module 330 queries the user device to determine its functions. In other instances, device module 330 determines the user device's functions by looking up the functions of devices that are the same as or similar to the user device. For example, if the user device is a specific type of wearable device, device module 330 can look up the available functions of that specific type of wearable device from third-party server 130. For example, if the user device has audio output, device module 330 identifies the user device as capable of performing specific assistive activities that include audio output (e.g., voice guidance for hands-free navigation). Therefore, in some cases, device module 330 combines specific assistive activities to determine the device state.

[0180] In yet another example, the device state is based on whether the user device is active, as discussed below. Figure 8 Further discussion. For example, if the user equipment is currently not in use (e.g., determined by sensors on the equipment, such as an accelerometer indicating that the equipment is completely stationary), the device module 330 determines that the device is not active and does not recognize the inactive user equipment as capable of performing auxiliary activities.

[0181] Now refer to Figure 7 The flowchart illustrates, according to some example embodiments, further operations for identifying data from a user device. Specifically, Figure 7 The device module 330 identifies the user equipment by determining its device status, including whether it is within a certain distance of the user. Following operation 530, in operation 710, the device module 330 receives sensor data from the user equipment. The sensor data includes, for example, data from the following... Figure 53 The discussion concerns data received by any sensors. In a specific example, sensor data includes location data determined by the GPS component of the user equipment. The sensor data represents the real-time physical environment from the user equipment. As described below, device module 330 determines the device state from the user equipment based on the sensor data received from the user equipment.

[0182] In operation 720, the feature module 240 or the device module 330 infers the current user location based on location data received from the user equipment. For example, the attribute data includes real-time data from the user equipment corresponding to the user's location (e.g., location data corresponding to the user determined by the GPS component of the mobile device).

[0183] In operation 730, device module 330 extracts the current device location from sensor data received from the user equipment. For example, the user equipment may be equipped with a GPS component that provides location data. In other instances, device module 330 is based on... Triangulation, NFC beacon detection, or other location services can be used to extract the current device location.

[0184] In operation 740, device module 330 compares the current user location with the current device location to determine a distance (e.g., an operating distance) from the user device to the current user location. This distance can be a short distance, such as a reasonable distance from the user device that allows the user to physically operate the device (e.g., arm's length).

[0185] although Figure 7 This involves determining whether the user device is within a certain distance of the user's location based on the user and the inferred location of the user device. However, device module 330 employs other methods to determine whether the user is within the operating distance of the user device. For example, if the user device is equipped with a biometric identification sensor, and device module 330 receives biometric sensor data from the user device indicating the user's identity, then in this case, device module 330 can infer that the user is within the operating distance of the user device.

[0186] Now refer to Figure 8 The flowchart illustrates further operations for identification from a user device according to some example embodiments. Following operation 530, device module 330 receives sensor data from the user device in operation 810, similar to operation 710 described above. The sensor data represents the real-time physical environment from the user device. For example, the sensor data includes thermal data (e.g., data indicating the current temperature), motion data (e.g., data determined by an accelerometer component), location data (e.g., data determined by a GPS component), biometric data (e.g., heart rate data or fingerprint recognition), and communication data (e.g., NFC beacon detection or...). Equipment detection) and other sensor data (see below) Figure 53 (Additional sensors and data).

[0187] In operation 820, device module 330 calculates an activity metric based on sensor data. In various implementations, the activity metric indicates whether a user is using the user device. In some implementations, the activity metric includes the probability or likelihood of activity from the user device. In these implementations, a higher activity metric value is associated with a higher probability of activity from the user device. In a specific instance, if the user device is a wearable device such as a smartwatch, the sensor data is based on a heart rate sensor to indicate that a particular user is wearing the wearable device (when the user is not wearing the wearable device, the heart rate sensor indicates no heart rate).

[0188] Similarly, if the user device is a smartphone providing ambient temperature data, the device module 330 calculates an activity metric based on the temperature data. For example, if the temperature data is fluctuating or higher than the expected ambient temperature, this indicates that the user should put the smartphone in their pocket. Conversely, if the temperature is close to the expected ambient temperature and the temperature fluctuation is small, the device module 330 calculates a low probability corresponding to a lower activity metric, indicating that the particular device is inactive or that the user has not used the particular device.

[0189] In operation 830, device module 330 determines activity from the user equipment based on activity metrics. For example, if the calculated activity metric exceeds a threshold, device module 330 determines activity from the user equipment. The threshold can be predetermined or dynamically determined by device module 330. For example, device module 330 employs various statistical models based on historical values ​​of activity metrics to determine whether the current activity metric is abnormal. In a simple, non-limiting example, device module 330 sets the threshold as the average of historical values ​​of activity metrics, and if the activity metric exceeds the average of historical values ​​of activity metrics, device module 330 determines activity from the user equipment. Device module 330 employs many other schemes and techniques to determine device activity based on activity metrics.

[0190] In operation 840, device module 330 identifies a slave user device as capable of performing auxiliary activities in real time based on the slave user device's activity. In other words, device module 330 identifies a specific slave user device based on its specific activity. The reasoning is as follows: In some cases, if a slave user device is inactive, it cannot present information to the user or receive input from the user, and therefore cannot perform auxiliary activities.

[0191] Refer again Figure 5 In operation 550, the activity module 310 generates auxiliary activities to be executed in real time from the user device by analyzing device activity, device functions from the user device, user preferences, and other factors and data. Auxiliary activities can include a wide range of tasks, content, and functions. For example, auxiliary activities include notifications containing information associated with the device activity. For instance, if the device activity is watching a sports event on a smart TV, auxiliary activities include notifications containing information associated with the sports event (e.g., information related to athletes, current score, and event statistics).

[0192] In some implementations, ancillary activities include a portion of device activities. For example, if device activities include browsing a specific website, the activity module 310 generates ancillary activities that include content that is part of the website. Therefore, in these implementations, the activity module 310 assigns a portion of the device activities to the user device.

[0193] Figure 9This is a flowchart illustrating further operations for generating assistive activities from a user device, according to some example embodiments. Following operation 540, in operation 550, the activity module 310 generates the assistive activity. Operation 550 may also include operations 910, 920, and 930.

[0194] In operation 910, device module 330 determines the display size corresponding to the user device. For example, device module 330 directly queries the user device to retrieve data associated with the display size. In another example, device module 330 uses an identifier associated with the user device to query a specific third-party server (e.g., third-party server 130) to determine the display size of the user device. In a specific example, device module 330 determines a specific device model of the user device and performs a lookup for the display size of that specific device model.

[0195] In operation 920, device module 330 determines that the display size corresponding to the user device is below a threshold size. For example, the display size may be too small for specific content in an assistive activity. In this case, device module 330 determines that the display size is below the threshold size.

[0196] In operation 930, the activity module 310 generates an auxiliary activity, including a scaled-down activity context, based on the display size corresponding to the user device. For example, the device module 330 shortens or reduces the content or functionality of the auxiliary activity to fit the display size of the user device.

[0197] Figure 10 This is a flowchart illustrating further operations for generating assistive activities from a user device, according to some example embodiments. Following operation 540, in operation 550, the activity module 310 generates the assistive activity. Operation 550 also includes operations 1010 and 1020.

[0198] In operation 1010, device module 330 compares the device functions of the user device with those of the user device to identify non-mutual functions that are not available on the user device. For example, the user device may include a mobile computer on which the user is browsing a website. The user device could be a wearable device attached to the user. In this example, device module 330 would identify, for example, haptic output from the user device as a non-mutual function because the mobile computer may not have haptic output capabilities. In another example, a particular wearable device may not include a GPS component, while the user's smartphone may include a GPS component for determining the current location. In this example, device module 330 would identify the use of the GPS component as a non-mutual function.

[0199] In operation 1020, activity module 310 generates auxiliary activities that include activity components utilizing non-common functions from the user device. In the example discussed above, if device module 330 determines that the user device includes a GPS component, while the user device does not, activity module 310 utilizes location data from the user device when generating auxiliary activities. In a specific example, if the user is browsing a specific webpage associated with a particular merchant or location, activity module 310 uses the user device's GPS component, which accesses the user's current location, to generate auxiliary activities that include map directions to the specific location. Therefore, activity module 310 receives the specific location from the user device and transmits that location and instructions for map directions from the current location to that location to the user device.

[0200] Refer again Figure 5 In operation 560, the activity module 310 sends or otherwise transmits instructions to the secondary user equipment to perform complementary activities in real time. For example, the activity module 310 transmits instructions to the secondary user equipment to present a user interface that facilitates or implements the secondary activity (e.g., a user interface including functions for performing the secondary activity). In a specific example, if the secondary activity includes a notification containing notification content, the activity module 310 sends a notification containing the notification content to the secondary user equipment to be presented to the user. Therefore, in this example, the activity module 310 causes the notification to be presented on the secondary user equipment.

[0201] While operations 540-560 involve performing a single assistive activity on a single slave user device, other embodiments include identifying multiple slave devices and generating multiple assistive activities to be performed in real time on one or more of the identified slave user devices. For example, if a user is wearing a smartwatch and smart glasses, the generated assistive activity can be distributed among the identified assistive activities. For example, a haptic notification can be directed to the user's smartwatch, while a visual notification can be directed to the user's smart glasses. In this example, activity module 310 distributes multiple assistive activities among the multiple slave user devices based on the corresponding device capabilities of the multiple slave user devices. Activity module 310 uses other factors (e.g., user preferences) to distribute the multiple assistive activities.

[0202] To help explain the above concepts, Figure 11 Non-limiting examples of generating assistive activities from a user device are shown, based on some example embodiments. Figure 11 Scene 1100 depicts a living room attached to an open-plan kitchen. Scene 1100 includes a smart TV (TV) 1110, a media entertainment device 1120, a light 1130, a mobile computer 1140, a wearable device 1150, a user 1160, a mobile device 1170, a smart refrigerator 1180, and a kitchen display 1190. Figure 11Each device in the network can be a source of attributes coupled to the network (e.g., network 104) and operable to communicate with the data grid system 150. In various example embodiments, the user 1160 may carry or wear a smart device, such as a wearable device 1150 (e.g., a mobile device, wearable device, NFC-enabled smart ring) that provides real-time data corresponding to the user 1160. For example, the user 1160 may be carrying a mobile device that provides real-time location data (e.g., location data determined by a GPS component, beacon location detection, or other location services).

[0203] In an example embodiment, user 1160 may be browsing web pages using mobile computer 1140. Mobile computer 1140 may be coupled to network 104, and activity module 310 detects device activity while browsing a specific web page. Preference module 320 infers user preferences associated with the device activity while browsing a specific web page. For example, activity module 310 infers that the user has a preference for viewing supplementary content associated with the specific web page the user is browsing or supplementary functions associated with the specific web page (such as liking, saving, or sharing the specific web page).

[0204] Based on the inferred user preferences, device module 330 identifies a user device, such as wearable device 1150, capable of performing assistive activities. Device module 330 identifies wearable device 1150 based on its proximity to user 1160 (the reasoning being: if wearable device 1150 is within a short distance of user 1160, then wearable device 1150 can provide information or receive input from user 1160). For example, device module 330 may base its identification on various sensor data received from wearable device 1150 (e.g., biometric data indicating a specific user is wearing the device, accelerometer data indicating the device is in use, or data indicating that wearable device 1150 is within short-range communication range of another user device that device module 330 has inferred the user is using). (Device detection) confirmed that user 1160 is wearing wearable device 1150.

[0205] Once device module 330 identifies wearable device 1150, activity module 310 generates assistive activities based on the identified device functions, device activities, user preferences, and other data from the user device. For example, wearable device 1150 may not have audio output; in this case, content including audio components can be changed or modified to suit the functionality of wearable device 1150. Continuing the example above, activity module 310 generates assistive activities that include options for saving, liking, or sharing (e.g., tweeting) a specific webpage that user 1160 is browsing. In some instances, activity module 310 generates assistive activities based on device activities. For example, if the device activity for browsing a specific webpage already includes options for saving or sharing the webpage, activity module 310 generates assistive activities that include functionality not yet available on the user device (in this case, mobile computer 1140). After activity module 310 generates assistive activities, it sends or otherwise transmits them to wearable device 1150 to execute the assistive activities. In this example, the activity module 310 sends an instruction to the wearable device 1150 to present a user interface that includes options for saving, liking, or sharing specific web pages that the user 1160 is browsing on the mobile computer 1140.

[0206] Figure 12 and Figure 13 An example user interface for interactively presenting information to the user is depicted. Although Figure 12 and 13 Specific example user interfaces and user interface elements are depicted, but these are merely non-limiting examples, and many other alternative user interfaces and user interface elements can be generated and presented to the user by the rendering module 210. It will be noted that... Figure 12 and Figure 13 Alternative presentations may include additional information, graphics, options, etc.; other presentations may include less information or provide reduced information for user convenience.

[0207] Figure 12 An example device 1200 (e.g., a smartwatch) is depicted displaying an example user interface 1210 that includes auxiliary or supplementary functions. For example, the user interface 1210 includes user interface elements 1220, 1230, and 1240 that respectively provide the user with options to like (e.g., like a specific webpage or location), share (e.g., tweet a link to a specific location or webpage), or return to the homepage (e.g., navigate to a specific webpage on the user's device using the navigation function). For example, activating user interface element 1220 enables the user to "like" items (e.g., specific webpages) associated with device activity on a social networking service where the user is a member. The user interface 1210 includes a variety of other functions.

[0208] In some cases, the assistive activity includes a notification. In these cases, the activity module 310 causes the notification to be presented to the user. For example, the activity module 310 transmits an instruction to the device 1200 for presenting the notification. In some instances, the instruction includes notification content generated by the activity module 310, such as a message to be presented to the user (e.g., relevant information). In example embodiments, the notification includes a text message, such as a Short Message Service (SMS) message, a Multimedia Messaging Service (MMS) message, an Enhanced Messaging Service (EMS) message, etc. In other example embodiments, the notification includes a push notification or another similar type of notification. In still other example embodiments, the notification includes interactive user interface elements.

[0209] Figure 13 An example device 1300 is depicted displaying an example user interface 1310 that includes auxiliary or supplementary content. For example, the user interface 1310 includes supplementary content associated with directions to a specific location. For instance, if a user is attempting to physically locate a specific location using a smartphone, assistive activities include providing additional or supplementary content on a wearable device that the user may be wearing. Figure 13 In the example, the user interface 1310 includes orientation determined via sensors included in the wearable device or based on data received from a smartphone. Additional information may also include relevant data, such as distance to a specified location. In this way, the wearable device performs assistive activities associated with device activities being performed in real time by the user's device.

[0210] Now let's turn to another example embodiment. Figure 14 This is a block diagram of a user analytics system 270, which provides functions for identifying items needed by a user and facilitating purchases associated with those identified items. The user analytics system 270 may include an item module 1410, an analytics module 1420, and an order module 1430.

[0211] The item module 1410 in the user analysis system 270 can provide functionality to facilitate item identification based on attribute data. For example, the item module 1410 extracts demand indications from the attribute data that can indicate a user's anticipated need for a particular item. In specific examples, demand indications can indicate a user's use of a particular item, the user supply of a particular item, user activities indicating a particular item (e.g., frequent beach visits can indicate a need for sunscreen and other beach-related products), and other demand indications for various items. The item module 1410 uses various schemes and techniques to extract demand indications from many different parts of the attribute data and combinations of parts of the attribute data.

[0212] Analysis module 1420 provides functionality for identifying items based on attribute data. For example, analysis module 1420 identifies goods or related items based on demand indications, user characteristics, attribute data, or any suitable combination thereof. In other example embodiments, analysis module 1420 calculates demand metrics based on demand indications. In some implementations, user analysis system 270 performs various tasks and functions based on demand metrics, such as facilitating various aspects of purchasing related to goods.

[0213] Order module 1430 provides functionality to facilitate user purchases associated with goods. For example, order module 1430 determines order parameters or transaction parameters for a user purchase based on user characteristics, attribute data, demand indications, or other data. In some example embodiments, order module 1430 automatically (e.g., without user intervention or action) executes a user purchase on behalf of the user based on various triggers or analyses.

[0214] Figure 15 This is a flowchart illustrating an example method 1500 for identifying goods based on attribute data and facilitating user purchases associated with those goods. In operation 1510, attribute module 230 receives user-associated attribute data from multiple attribute sources. In various example embodiments, at least a portion of the attribute data includes real-time or near-real-time data. The term "real-time data" as used herein is intended to include data associated with currently occurring events. For example, real-time data may include user input data or sensor data that is transmitted to attribute module 230 after a delay interval (e.g., caused by transmission delays or other delays, such as temporary storage at an intermediate device) between data capture and data reception by attribute module 230.

[0215] If combined Figure 52 and Figure 53 The discussion focuses on receiving attribute data from a wide range of attribute sources, such as devices, sensors, servers, databases, and others. Furthermore, the attribute module 230 can receive attribute data via numerous paths resulting from the classification of attribute sources through configuration, such as combining... Figure 51A and Figure 51B Further discussion follows. In an example embodiment, attribute module 230 receives attribute data directly from an attribute source. In other example embodiments, attribute module 230 receives attribute data from a central device, where the central device receives attribute data from multiple user devices. In other example embodiments, various user devices are communicatively coupled in a distributed device-to-device grid, and attribute module 230 receives attribute data corresponding to a specific device in the grid from any device in the grid. In other examples, attribute module 230 receives attribute data from an attribute source through many other configurations including various suitable combinations of configurations.

[0216] In various example embodiments, attribute module 230 stores attribute data in association with users (e.g., indexed based on user identifiers) for subsequent analysis. For example, attribute module 230 may store attribute data in a storage device such as database 126. In some implementations, attribute module 230 uses various search or lookup schemes to access the stored attribute data. For example, it may use a user identifier corresponding to a specific user to access attribute data associated with that specific user. It will be noted that collective and aggregated attribute data may be referred to as a “data grid.”

[0217] In operation 1520, the item module 1410 extracts a demand indication from the attribute data. In some example embodiments, a demand indication indicates a user's anticipated demand for a particular item. For example, a specific demand indication may indicate that a user may want, expect, or favor a particular product or commodity. Note that the terms "item," "product," "commodity," etc., are intended to include a wide variety of products (e.g., items corresponding to a list of items published on an e-commerce website) and services (e.g., a specific activity of going to a restaurant). It should also be noted that the terms "anticipate" and "forecast" as used herein are intended to refer to future events or activities, including events in the near future (e.g., events within a short timeframe, such as minutes or seconds) and events in the more distant future (e.g., months or years from now).

[0218] Item module 1410 extracts demand indications from various data included in the attribute data, such as purchase history, location data (e.g., location data determined by a mobile device's GPS component, beacon detection, or other location services), social media data (e.g., user registrations or posts), and other data included in the attribute data as discussed herein. Demand indications include, for example, inventory level indications (e.g., a user's food supply indicated by a smart refrigerator), item usage indications (e.g., a user's purchase history can indicate specific item usage patterns), item activity indications, item-related activities (e.g., a user spending time at a ski resort can indicate a demand for ski equipment), user engagement data (e.g., a user clicking on specific links associated with various products or activities), and so on. For example, location data included in the attribute data can indicate frequent visits to coffee shops. In this example, item module 1410 extracts location data from the attribute data because it can indicate a user's demand for coffee or coffee-related products. In another example, social media data (e.g., gym registrations or posts about fitness activities) can indicate a demand for fitness-related items or activities.

[0219] In a specific example, the user currently has a sufficient supply of bottled water, but based on an indication of the user's consumption rate of bottled water, the user may have a future demand for bottled water. Therefore, in this example, the item module 1410 extracts either a supply indication of bottled water (e.g., the user's purchase history data) or a consumption indication of bottled water (e.g., inventory activity data retrieved or accessed from the smart refrigerator) from the attribute data. In other words, the demand indication extracted by the item module 1410 can include a supply indication of bottled water, an inventory level indication, or an inventory activity indication.

[0220] In operation 1530, analysis module 1420 identifies goods, products, or related items based on attribute data according to the extracted demand indication. For example, analysis module 1420 determines that a user is likely interested in or has a demand for a specific item. In other words, analysis module 1420 identifies one or more goods from multiple goods associated with the demand indication based on user demand for corresponding goods included in a plurality of goods.

[0221] Analysis module 1420 uses various schemes and techniques to identify goods based on demand indications. For example, analysis module 1420 may calculate a demand metric based on demand indications. A demand metric can indicate the likelihood that a user has a demand for a particular item. For example, a demand metric may be based on the occurrence count of demand indications corresponding to a particular item (e.g., a particular item with multiple corresponding demand indications may be associated with a higher demand metric than a particular item with a single corresponding demand indication). In some example embodiments, analysis module 1420 may identify goods based on the calculated demand metric exceeding a threshold (e.g., a predefined or dynamically determined value).

[0222] In another example embodiment, the analysis module 1420 ranks, sorts, or otherwise organizes at least a portion of a plurality of goods associated with a demand indication based on a demand metric. In this example embodiment, the analysis module 1420 identifies, individually or in any suitable combination, a predetermined number or dynamically determined number of the top-ranking goods among the plurality of goods associated with the demand indication. For example, the analysis module 1420 identifies goods from the plurality of goods based on statistical analysis, such as percentages (e.g., the top 10% of the ranked goods), analysis based on the standard deviation from the mean, or other statistical methods.

[0223] In other example embodiments, demand indications are weighted so that higher-weighted demand indications have more influence in the analysis module 1420, which identifies goods based on demand indications. The weights can be predefined or dynamically determined based on user feedback data (e.g., data indicating whether a user actually needs a good product identified by the analysis module 1420). In some implementations, feedback data is included in attribute data after the analysis module 1420 identifies a product. In this way, the analysis module 1420 can adapt, learn, or evolve as more attribute data is received. In some example embodiments, the analysis module 1420 employs various machine learning techniques to enhance product identification based on demand indications. The item module 1410 can apply similar techniques to extract demand indications from previous operations.

[0224] In operation 1540, feature module 240 infers or directly measures user characteristics related to the user based on attribute data. As discussed above in conjunction with operation 610, feature module 240 can use various data to infer various user characteristics based on attribute data. It will be understood that the discussion of operation 610 related to feature module 240 also applies to operation 1540.

[0225] In operation 1550, the order module 1430 promotes user purchases or suggested transactions related to goods, at least in part, based on user characteristics. Promoting a specific purchase is intended to include actions such as: automatically (e.g., without user intervention or action) performing the specific purchase on behalf of the user, causing the presentation of a notification including the option to make the specific purchase, or other actions associated with promoting the specific purchase (e.g., causing the presentation of advertisements, adjusting the user's item list search results to highlight items associated with the specific item). In other example embodiments, the order module 1430 determines various parameters (e.g., order parameters or transaction parameters) associated with the user purchase based on attribute data, user characteristics, demand indications, or other data. Additional aspects of promoting user purchases are described in the discussion below.

[0226] Figure 16This is a flowchart illustrating further operations for facilitating user purchases based at least in part on an assessment of inventory levels, according to some example embodiments. In operation 1610, the item module 1410 extracts the current inventory level of the item from attribute data. For example, the item module 1410 extracts the quantity of the item from attribute data that includes inventory data received from a smart refrigerator. In other examples, the attribute data includes inventory indications from sensors that directly monitor or measure the item. In a specific example, brake pads may be monitored via a sensor operable to indicate the condition of brake pads in a user's car (e.g., needing replacement). In another example, another user, possibly associated with that user, may purchase a specific item that the user needs. In this example, based on the purchases of other users, the user may no longer have a need for the featured item (e.g., a shared shopping list among family members).

[0227] In operation 1620, analysis module 1420 determines an inventory threshold for a product by modeling its usage based on the extracted current inventory level and inferred user characteristics. In an example embodiment, analysis module 1420 determines an inventory threshold such that if the current inventory level is likely to fall below the threshold, it may be necessary to reorder inventory to avoid depletion. For example, analysis module 1420 calculates a usage rate corresponding to a product based on attribute data, user characteristics, or other data, and applies this usage rate to determine the inventory threshold for the product to prevent its supply from running out. For example, analysis module 1420 determines the usage rate of a specific item based on historical purchase history data and infers the usage rate based on the purchase frequency of the specific item. In a specific example, the product could be coffee beans, and analysis module 1420 determines that a user may run out of coffee beans within fourteen days based on the user's current coffee bean supply and the corresponding user consumption rate (e.g., usage rate). In this specific example, analysis module 1420 determines the inventory threshold as a value, such as the quantity of coffee beans, which could be the current inventory level a few days before the coffee bean supply runs out.

[0228] In operation 1630, analysis module 1420 identifies a mismatch between the inventory threshold and the current inventory level. For example, if analysis module 1420 determines that the current inventory level is below the inventory threshold, analysis module 1420 identifies the mismatch based on this.

[0229] In operation 1640, depending on some implementation, the order module 1430 automatically (e.g., without user intervention or action) executes a user purchase based on the mismatch. In some example embodiments, the order module 1430 considers delivery delays and other delays to prevent the current inventory level of the goods from falling below an inventory threshold. For example, the analysis module 1420 considers delays in receiving orders for specific items and raises the inventory threshold.

[0230] Figure 17 This is a flowchart illustrating several other operations, including the determination of parameters for facilitating a purchase, according to some example embodiments. In operation 1710, order module 1430 determines at least one order parameter based at least in part on user characteristics. Order parameters may include at least one of quantity, delivery time, payment time, delivery method, delivery destination, merchant, brand, price, item color, item style, etc. For example, user characteristics may indicate that a user can wear a certain clothing size. In this example, order module 1430 specifies the order parameter for clothing or apparel based on clothing size. Similarly, order module 1430 may specify the brand a user purchases based on user characteristics (e.g., a user's historical brand purchases, or an analysis of the user's style and brands that match that style). In another example, user characteristics may indicate that a user can prioritize cost minimization over other considerations. In this example, order module 1430 identifies lower-cost options over faster options (e.g., waiting for a particular item to go on sale or using the cheapest shipping). In yet another example, user characteristics may indicate that delivery speed is important for certain items (e.g., a user may want a trendy new mobile device immediately). In this example, the order module 1430 determines the delivery method parameters based on how quickly the order can be delivered. In another example embodiment, the order module 1430 specifies the delivery location of the user's purchase based on user characteristics (e.g., if the user is purchasing an item related to the user's work, the delivery location could be the user's work location instead of their home address). The order module 1430 can determine many other order parameters based on user characteristics.

[0231] In operation 1720, order module 1430 facilitates a purchase based on determined order parameters. For example, order module 1430 may recommend a purchase to a user, where the recommendation includes the determined order parameters (e.g., providing the user with a notification that includes an option for the user to make a purchase). In another example, order module 1430 automatically makes a purchase on behalf of the user. For example, if order module 1430 determines that the user's purchase may be urgent (e.g., to avoid running out of supply of an item), routine (e.g., buying bottled water), or pre-specified by the user to allow automatic purchases, the purchase can be made automatically to avoid inconveniencing the user in making the purchase decision.

[0232] Figure 18This is a flowchart illustrating further operations, including the determination of time parameters associated with a purchase, for determining order parameters according to some example embodiments. In operation 1810, the analysis module 1420 identifies a user's purchase motive for goods by analyzing user characteristics. In various example embodiments, purchase motive corresponds to motive time. For example, a user might be planning a vacation that includes a beach destination. The vacation might indicate a user's purchase motive for items associated with the vacation (e.g., sunscreen for a beach vacation, snacks for a road trip, Broadway tickets for a trip to New York City). In this example, motive time corresponds to the start of the vacation (e.g., determined by user calendar information or purchase history data such as flight information included in attribute data).

[0233] In operation 1820, order module 1430 determines time order parameters based on the motivation time. In the example above, where the user may be planning a vacation, order module 1430 determines the time order parameters to ensure that the item corresponding to the user's purchase arrives before the vacation. In another example, if the purchase motivation is associated with an event such as a graduation party, order module 1430 may determine the time order parameters to ensure that the item associated with the user's purchase is delivered before the graduation party, because the user may no longer need the specific item after a certain time.

[0234] In operation 1830, the order module 1430 facilitates the purchase based on the determined time order parameters. For example, the order module 1430 schedules items corresponding to a user's purchase to arrive at a specific time.

[0235] Figure 19 This is a flowchart illustrating further operations that facilitate purchases based at least in part on purchase criteria, according to some example embodiments. In operation 1910, analysis module 1420 accesses purchase criteria corresponding to a user. Purchase criteria individually include, for example, predefined criteria, user-specified criteria, dynamically determined criteria, or any suitable combination thereof. For example, purchase criteria may in particular include time-based criteria (e.g., criteria specifying when a user will make purchases within a specific time period), budget criteria (e.g., spending limits associated with a specific item or category of items), and context-based criteria (e.g., adjusting budget criteria based on the user's current location). In a specific example, the user specifies a budget, total budget, or monthly budget for a specific category or item (e.g., transportation, food, utilities, housing, entertainment, travel, health). Furthermore, the user can specify rule-based criteria, such as a specific time for certain purchases (e.g., after salary is deposited).

[0236] In other example embodiments, the analysis module 1420 identifies and includes patterns in the user's purchasing habits, goals, purposes, or dynamically generated criteria in the purchasing criteria. In a specific example, the analysis module 1420 determines that the user may have a medical condition, such as a peanut allergy. In this scenario, the analysis module 1420 includes a criterion of avoiding items containing peanuts in the purchasing criteria. In another example, the analysis module 1420 determines that the user may be trying to maintain a vegetarian diet, and the analysis module 1420 may avoid food items that contradict the goal of maintaining a vegetarian diet.

[0237] In operation 1920, order module 1430 automatically purchases goods on behalf of the user based on purchase criteria. In the example embodiment, order module 1430 determines whether the purchase criteria are met before encouraging the user to make a purchase. For example, order module 1430 determines that a specific budget threshold included in the purchase criteria has been exceeded, and based on this, order module 1430 may not execute the purchase. In other words, order module 1430 encourages the user to make a purchase based on the determined fulfillment of purchase criteria.

[0238] Now go to Figure 20 The data grid system 150 can implement various suitable combinations of the operations discussed above for identifying goods and promoting user purchases. This also applies to the operations discussed above and below. Figure 20 The flowchart illustrates an example method 2000 of such a combination of operations, but many other suitable combinations can be employed. In operation 1510, the attribute module 230 receives attribute data associated with the user. In operation 1520, the item module 1410 extracts demand indications from the attribute data. In operation 1530, the analysis module 1420 identifies items based on the demand indications and attribute data. In operation 1540, the feature module 240 infers user characteristics based on the attribute data. Figure 20 As shown, various combinations of the above operations can be used to encourage users to make purchases at operation 1550.

[0239] In example method 2000, to encourage user purchases, in operation 1610, the item module 1410 retrieves the current inventory level of the goods. As described above, in operation 1620, the analysis module 1420 determines the inventory threshold for the goods. Subsequently, in operation 1630, the analysis module 1420 identifies a mismatch between the inventory threshold and the current inventory level. In operation 1640, if the analysis module 1420 identifies a mismatch, the user analysis system 270 can proceed to operation 1710. Alternatively, if the analysis module 1420 does not identify a mismatch, subsequent operations may not be performed.

[0240] In an example embodiment, after determining a mismatch, at operation 1710, the order module 1430 determines the order parameters for the user's purchase based on user characteristics. In some example embodiments, this may involve operations 1810, 1820, and 1830, respectively, for determining time order parameters that may be included in the order parameters. At operation 1720, the order module 1430 facilitates the user's purchase based on the order parameters.

[0241] Finally, in operation 1910, the analysis module 1420 accesses the purchase criteria, and in operation 1920, the order module 1430 promotes user purchase based on the purchase criteria. Therefore, Figure 20 Example embodiments are shown in which various operations described above can be combined with each other to promote user purchases.

[0242] Figure 21 This is a flowchart illustrating an alternative example method 2100 for identifying goods and facilitating user purchase according to some example embodiments. Example method 2100 may involve operations similar to those described above. In operation 2110, similar to operation 1510, attribute module 230 receives or accesses attribute data associated with a user. In operation 2120, similar to operation 1540, feature module 240 infers user characteristics related to the user based on the attribute data.

[0243] In operation 2130, analysis module 1420 identifies similar users to the user based on the inferred user characteristics and corresponding user characteristics of multiple other users. Analysis module 1420 identifies similar users to the user based on various factors. In some example embodiments, analysis module 1420 accesses attribute data or stored user characteristics corresponding to multiple other users. For example, analysis module 1420 identifies similar users among multiple other users based on the inferred user characteristics of the user and corresponding user characteristics of multiple other users. Analysis module 1420 may correlate, match, or otherwise compare the inferred user characteristics with the corresponding user characteristics of multiple other users to identify similar users. In various example embodiments, analysis module 1420 identifies similar users based on identical or similar demographic data (e.g., identical or similar age, marital status, gender, geographic location, etc.), identical or similar user characteristics (e.g., identical or similar brand purchases), identical or similar attribute data, and so on.

[0244] In operation 2140, analysis module 1420 identifies goods based on attribute data using user characteristics and demand indicators from similar users. For example, demand indicators might suggest a particular item that is not particularly important (e.g., the demand metric might be particularly low for a particular item). However, analysis module 1420 could identify a particular item based on user characteristics from similar users indicating that the item might be important. In other words, even if the demand indicator does not show a strong demand for a particular item, user characteristics from similar users might suggest that the user has a strong demand for the particular item.

[0245] In a specific example, the demand indicator can suggest that a user has a need for a pair of sunglasses. In this example, the demand indicator can further suggest that the user may be interested in brands X, Y, and Z, with particular emphasis on brand X. User characteristics of similar users (e.g., users with the same or similar age, location, gender, other demographic information, or similar purchasing preferences) can indicate that users similar to the user may have a high demand for brand Z. Based on this, the analysis module 1420 can identify the sunglasses of brand Z as a product.

[0246] In operation 2150, the order module 1430 determines order parameters or transaction parameters based on user characteristics of similar users. For example, the delivery method can be determined based on user characteristics of similar users. For example, if similar users frequently choose fast delivery methods for a specific item (e.g., a new electronic device), the order module 1430 can determine a fast delivery method corresponding to the user's purchase for goods that are the same as or similar to that specific item.

[0247] Similarly, purchasing criteria can include criteria dynamically determined based on user characteristics of similar users. That is, the analysis module 1420 can dynamically generate a portion of the purchasing criteria based on similar users. For example, a default budget for a particular category of items can be determined based on the analysis of user characteristics of similar users (e.g., other users with similar demographic information to the user, since the user is likely to spend a certain amount on average in each product category).

[0248] In operation 2160, order module 1430 facilitates user purchases associated with the product based on determined order parameters. As described above, order module 1430 facilitates user purchases in various ways, including: automatically executing a user purchase on behalf of the user based on the order parameters, or presenting the user with a notification including the option to make a user purchase.

[0249] Figure 22This is a flowchart illustrating some other operations that facilitate purchasing based at least in part on demand metrics, according to some example embodiments. In operation 2210, analysis module 1420 calculates a demand metric for the identified item based on a demand indication corresponding to the identified item.

[0250] In operation 2220, order module 1430 facilitates user purchases based on demand metrics. For example, if order module 1430 determines a high demand metric (e.g., exceeding a predefined or dynamically determined threshold), order module 1430 may facilitate user purchases more urgently compared to lower demand metrics. For example, order module 1430 may automatically execute a user purchase for the user based on a high demand metric, or more frequently present the user with notifications including the option to make a purchase (or more prominently, such as more obvious notifications, like a larger user interface presentation for the user). In some instances, order module 1430 determines order parameters based on demand metrics. For example, if order module 1430 determines a high demand metric, order module 1430 may subsequently determine a faster delivery option for that item.

[0251] Figure 23 This is a flowchart illustrating further operations using notifications to facilitate purchases according to some example embodiments. In operation 2310, presentation module 210 generates a notification including options for the user to make a purchase. This notification may include a user interface, text messages (Short Message Service (SMS), Multimedia Messaging Service (MMS), Enhanced Messaging Service (EMS), other messaging modes), etc. In some example embodiments, presentation module 210 may generate notification content based on products, user characteristics, similar user characteristics, attribute data, etc. In various example embodiments, the notification may include order parameters for the user to make a purchase.

[0252] In operation 2320, presentation module 210 causes the generated notification to be presented to the user. For example, presentation module 210 may transmit instructions for presenting a user interface including the notification to the user's device. In some example embodiments, presentation module 210 may determine the user device to which the notification is presented based on user characteristics. For example, if the user prefers a particular device (e.g., the user's mobile device), presentation module 210 may cause the notification to be presented to that device. In other example embodiments, the notification may provide the user with options for specifying or modifying order parameters purchased by the user.

[0253] In operation 2330, the presentation module 210 receives the user's selection of the option to make a purchase. For example, if the user selects to make a purchase, the presentation module 210 can receive the user's selection of the purchase option and transmit the selection to the order module 1430 to execute the purchase.

[0254] According to some example embodiments, in operation 2340, the order module 1430 executes a purchase. For example, the order module 1430 can make a purchase on behalf of the user based on order parameters.

[0255] Figure 24 This is a flowchart illustrating further operations for presenting notifications according to some example embodiments. In operation 2410, presentation module 210 identifies presentation parameters for presenting the notification. For example, presentation module 210 may identify presentation parameters based on user characteristics, similar user characteristics, attribute data, demand indications, or other data. Presentation parameters may include the user's preferred device for presenting notifications, preferred time for presenting notifications, content preferences (e.g., not presenting notifications related to a specific item category), etc. In a specific example, user characteristics may indicate the user's work hours. In this example, notifications may not be presented to the user during work hours because the user may not respond. In another example, analysis module 1420 may identify the device status of a particular user's device, and based on the device status, presentation module 210 may route the notification to another device. For example, if the device status indicates that the device is inactive (e.g., charging), presentation module 210 may cause the notification to be presented to another device (e.g., an active device determined by device sensors).

[0256] In operation 2420, presentation module 210 causes the notification to be presented based on presentation parameters. For example, presentation module 210 may, based on analysis of user characteristics, cause the notification to be presented on the user's preferred device at a certain time of day during which the user is likely to respond to the notification.

[0257] Figure 25 This is a flowchart illustrating some other operations for presenting a notification according to some example embodiments. In operation 2510, the analysis module 1420 detects a user's triggering action based on real-time data included in the attribute data. For example, the analysis module 1420 may determine that the user may be moving to the kitchen (e.g., by a mobile device that the user may be wearing and a smart device located in the user's kitchen). (As confirmed by the handshake), this may be a good time to notify users of food supplies.

[0258] In operation 2520, the presentation module 210 responds to the detection of a trigger action by presenting a notification to the user. In other words, based on the user's trigger action detected by the analysis module 1420, the presentation module 210 can cause the notification to be presented to the user.

[0259] Figure 26This is a flowchart illustrating an exemplary method 2600, which demonstrates communication between various devices related to presenting a notification to a user, according to some example embodiments. In operation 2610, attribute source 2602 transmits attribute data to data grid system 150. As described above, in operation 1510, attribute module 230 may receive attribute data associated with a user. In operation 1520, item module 1410 extracts demand indications from the attribute data. In operation 1530, analysis module 1420 may identify items based on the demand indications and attribute data. In operation 1540, feature module 240 infers user characteristics based on the attribute data.

[0260] In example method 2600, at operation 2620, order module 1430 facilitates a user purchase by generating a notification. Presentation module 210 transmits the notification from data grid system 150 to user device 2606. At operation 2630, user device 2606 can receive the notification and present it to the user. The user can then select an option to make a purchase. At operation 2640, user device 2606 can transmit an instruction to the user to make a purchase. At operation 2650, data grid system 150 can receive the user's selection to make a purchase. Finally, at operation 2660, order module 1430 can execute the purchase in response to receiving the user's selection to make a purchase.

[0261] Figure 27 An example user interface 2700 for facilitating purchases, according to some example embodiments, is depicted. It will be noted that... Figure 27 Alternative presentations may include additional information, graphics, options, etc.; other presentations may include less information or provide reduced information for user convenience. Notification 2710 may be a text message such as a Short Message Service (SMS) message, a Multimedia Messaging Service (MMS), an Enhanced Messaging Service (EMS), or other messaging modalities, which may be provided to notify the user of a purchase, including order parameters. In other example embodiments, notification 2710 may be a push notification or a similar type of notification. Some notifications may be interactive, allowing the user to make selections via an SMS system, mobile application, or other methods. For example, the user may interact with notification 2710 using user interface element 2720.

[0262] To help illustrate the above concept, Figure 28 and Figure 29 Non-limiting examples are shown, illustrating the identification of goods and the promotion of purchases by users associated with those goods, based on some example embodiments. Reference is now made to... Figure 28 Scene 2800 depicts a living room attached to an open-plan kitchen. Figure 28In the example, scenario 2800 includes a media entertainment device 2810, a smart TV (TV) 2820, a light 2830, a mobile computer 2840, a mobile device 2850, a user 2860, a smart refrigerator 2870, and a kitchen display 2880. Each of devices 2810-2850, 2870, and 2880 may be a source of attributes coupled to a network (e.g., network 104) and operable to communicate with a data grid system 150. In various example embodiments, user 2860 carries a smart device (e.g., a mobile device, wearable device, smart ring with near field communication (NFC) functionality) that can provide real-time data corresponding to user 2860. For example, user 2860 may be carrying a mobile device that can provide real-time location data (e.g., location data determined by GPS components, beacon location detection, or other location services). In this way, the analysis module 1420 tracks, monitors, or otherwise observes the location of the user 2860 via a specific device being worn by the user, or can do so based on various real-time data associated with the user's location included in the attribute data (e.g., the distance between the user's worn device and another device with a known or fixed location). (Handshake) to export the location of user 2860.

[0263] In an example embodiment, lamp 2830 is a smart lamp operable to transmit various operational data to data grid system 150, or connected to a smart socket operable to monitor the functionality of lamp 2830. In this example embodiment, item module 1410 extracts a demand indication from the portion of attribute data corresponding to lamp 2830. For example, the demand indication may indicate that lamp 2830 is being used in a particular manner (e.g., user 2860 may use a low brightness setting on lamp 2830) or that the bulb of lamp 2830 has burned out. Analysis module 1420 identifies an item as a bulb that needs replacement based on the demand indication (e.g., a demand indication detected by sensors on lamp 2830 or derived from data from the smart socket, such as an indication of reduced power consumption for a burned-out bulb). Subsequently, order module 1430 may notify the user of the burned-out bulb of the option to reorder the specific bulb based on user characteristics (e.g., the user's purchase history). In some instances, order module 1430 may automatically reorder the bulb without notifying the user. In various example embodiments, the order module 1430 automatically executes user purchases based on purchase criteria (e.g., for a specific category of goods, simply placing an order automatically).

[0264] In another example embodiment, the smart refrigerator 2870 transmits inventory data to the data grid system 150. For example, the smart refrigerator 2870 may transmit food supply data. In this example embodiment, the item module 1410 extracts demand indications from the food supply data. Subsequently, the analysis module 1420 identifies goods based on the demand indications. For example, the analysis module 1420 may identify milk as a good based on a low milk inventory level. The order module 1430 determines the quantity of milk to be ordered based on user characteristics (e.g., historical milk purchase data during the current season of the year). The order module 1430 may then generate a notification that includes the option to purchase milk. The order module 1430 causes the notification to be presented based on user characteristics. For example, real-time data included in the attribute data may indicate that user 2860 is currently in the kitchen, which could be a good time to offer user 2860 the option to order milk again (inference that user 2860 may be able to check the food supply first). In another instance, the order module 1430 can determine that the mobile device 2850 is inactive (e.g., turned off or not used based on inactivity detected by the device's accelerometer). In this scenario, the order module 1430 can enable a notification to be presented to the user on another device, such as a display 2880.

[0265] Figure 29 Examples of identifying items and facilitating purchases associated with the identified items are illustrated according to some example embodiments. Scenario 2900 depicts a city including a user 2910 who is driving. In this example, the item module 1410 extracts demand indications, such as the location of user 2910 or the route taken by user 2910 that could indicate destination 2950 and thus the goods. Continuing the example, the analysis module 1420 determines the destination 2950 of user 2910 based on the demand indications or based on, for example, user 2910's current route 2930, the time of day, and the day of the year. In other words, the analysis module 1420 can determine the destination 2950 of user 2910 based on demand indications and user characteristics or real-time context data included in attribute data (e.g., location determined by the GPS component of a mobile device). In some example embodiments, the analysis module 1420 or the feature module 240 bases the determination on a radius (e.g., radius 2920) within a certain radius. The analysis module 1420 determines the real-time location of user 2910 using other near-field communication detection. For example, if user 2910 is within a radius 2940 of destination 2950, ​​the analysis module 1420 determines that user 2910 may be at destination 2950. In this scenario, destination 2950 could be a coffee shop, and the item could be a cup of coffee. In some example embodiments, the order module 1430 automatically places an order for a cup of coffee while user 2910 may be en route, or presents a notification with the option to order coffee. In other example embodiments, the order module 1430 determines order parameters based on user characteristics (e.g., including past coffee orders in user 2910's purchase history). In other example embodiments, the presentation module 210 determines presentation parameters based on user 2910 being in a car (e.g., presenting audio prompts for the option to place an order, and receiving voice commands from user 2910 for placing an order).

[0266] Now let's turn to another example embodiment. Figure 30 This is a block diagram of the enhancement system 280, which provides functions for authenticating user identity, recognizing user activity, and enhancing user activity. The enhancement system 280 may include an authentication module 3010, an activity module 3020, and a settings module 3030.

[0267] The authentication module 3010 in the enhanced system 280 can provide functionality to facilitate the authentication of user identities. For example, the authentication module 3010 can identify portions of attribute data that indicate the user's identity. Subsequently, the authentication module 3010 can authenticate the user's identity by analyzing the identified portions of the attribute data. In other example embodiments, the authentication module 3010 can calculate an identity probability metric based on real-time data included in the attribute data. The identity probability metric can indicate the likelihood of authenticating the user's identity (e.g., a higher identity probability metric can indicate a strong probability that the user's identity can be authenticated). The authentication module 3010 can use many different schemes and techniques to analyze various portions of the attribute data to authenticate the user's identity.

[0268] Activity module 3020 can provide functionality associated with user activities. For example, activity module 3020 can identify user activities being performed by a user based on attribute data included in real-time data. In another example, activity module 3020 can enhance the identified user activities based on user settings or user preferences. For example, user settings can be associated with presenting information to the user (e.g., if available, the user might prefer a larger screen for presenting information). In this instance, activity module 3020 can enhance the presentation of information to the user based on user settings.

[0269] The settings module 3030 can provide functionality for accessing or determining one or more user settings. For example, the settings module 3030 can determine user settings based on attribute data and identified user activity. In some example embodiments, the settings module 3030 can access user settings from a storage device (e.g., database 126). In other example embodiments, the settings module 3030 can determine user settings based on analysis of user characteristics, similar users, enhancement results through enhancements to user activity, and so on.

[0270] Figure 31 This is a flowchart illustrating an example method 3100 for authenticating a user and enhancing user activity according to some example embodiments. The operation of method 3100 can be performed by components of data grid system 150 and enhancement system 280. In operation 3110, attribute module 230 may receive user-associated attribute data from multiple attribute sources. In various example embodiments, at least a portion of the attribute data may include real-time or near-real-time data. The term "real-time data" as used herein is intended to include data associated with currently occurring events. For example, real-time data may include user input data or sensor data that is transmitted to attribute module 230 after a delay interval between data capture and data reception by attribute module 230 (e.g., caused by transmission delays or other delays, such as temporary storage at an intermediate device).

[0271] If combined Figure 52 and Figure 53 The discussion focuses on the possibility of receiving attribute data from a wide range of attribute sources, such as devices, sensors, servers, databases, and others. Furthermore, the attribute module 230 can receive attribute data via numerous paths resulting from the classification of attribute sources through configuration, such as combining... Figure 51A and Figure 51B Further discussion follows. In the example embodiment, attribute module 230 can receive attribute data directly from an attribute source. In other example embodiments, attribute module 230 can receive attribute data from a central device, where the central device receives attribute data from multiple user devices. In other example embodiments, various user devices can be communicatively coupled in a distributed device-to-device grid, and attribute module 230 receives attribute data corresponding to a specific device in the grid from any device in the grid. Through many other configurations, including various suitable combinations of configurations, attribute module 230 can receive attribute data from an attribute source.

[0272] In various example embodiments, attribute module 230 may store attribute data in association with users (e.g., indexed based on user identifiers) for subsequent analysis. For example, attribute module 230 may store attribute data in a storage device such as database 126. Attribute module 230 may access the stored attribute data using various search or lookup schemes. For example, attribute data associated with a specific user may be accessed using a user identifier corresponding to that specific user. It will be noted that collective and aggregated attribute data may be referred to as a "data grid".

[0273] In operation 3120, authentication module 3010 can identify portions of real-time data that indicate the user's identity. Attribute data including real-time data can include a large amount of data associated with the user. All or various portions (e.g., fragments or blocks) of the real-time data can indicate the user's identity. Authentication module 3010 can identify, extract, parse, or otherwise obtain data from the real-time data that is relevant, related, or otherwise useful for performing user authentication.

[0274] In example embodiments, various devices providing real-time data to attribute module 230 may correspond to a user. For example, one or more user devices (e.g., mobile devices, wearable devices) may provide at least a portion of the real-time data. User devices and the real-time data they provide may be identified via device identifiers (e.g., Internet Protocol (IP) addresses, Media Access Control (MAC) addresses, other unique identifiers, International Mobile Equipment Identifiers (IMEI), Mobile Equipment Identifiers (MEID), etc.). In various example embodiments, authentication module 3010 may identify the portion of real-time data that indicates the user's identity by matching the device identifier corresponding to the user with a corresponding device identifier associated with the real-time data. In a specific example, if location data (e.g., determined by the GPS component of a mobile device) originates from a device with a device identifier corresponding to the user (e.g., the location data originates from the user's mobile device), authentication module 3010 may identify the location data as indicating the user's identity. It should be clear that data originating from a device corresponding to the user may only indicate the user's identity, rather than identifying the user as another user who may be operating the device. In subsequent operations discussed below, the user's identity may be authenticated with respect to real-time data.

[0275] In various example embodiments, attribute data and real-time data may include sensor data. In example embodiments, authentication module 3010 may identify portions of the sensor data that may indicate the user's identity. For example, sensor data may include biometric data such as fingerprint scans, voice samples, electroencephalograms, or retinal scans (see additional sensor data). Figure 53In this example, authentication module 3010 can identify biometric data as indicating the user's identity (e.g., matching a fingerprint included in sensor data with the user's fingerprint, or matching another sensor signature with the user's sensor signature). In these specific example embodiments and the following example embodiments, the real-time data does not necessarily have to originate from the device corresponding to the user.

[0276] In other example embodiments, authentication module 3010 may identify portions of attribute data that indicate a user's identity based on various analyses or patterns. For example, a particular device may provide location data (e.g., determined by the GPS component of a mobile device). Authentication module 3010 may determine that location data can indicate a user's identity based on the user's past location data. In a specific example, if a user has previously exhibited a particular travel pattern or frequently visited specific locations (e.g., a specific route home, or spent a specific amount of time in a specific location), authentication module 3010 may identify real-time data indicating the user's identity corresponding to the specific device providing the location data.

[0277] In other example embodiments, authentication module 3010 may employ numerous other analyses to identify attribute data indicative of a user's identity. For example, a user may be a member of various websites (e.g., e-commerce websites, social networking sites). If a user logs into a specific website using a specific device, authentication module 3010 may identify that specific device and the attribute data indicative of the user's identity received from that specific device.

[0278] In operation 3130, authentication module 3010 can authenticate the user's identity based on real-time data by analyzing the identified portions of real-time data and attribute data. In some example embodiments, authenticating the user's identity based on real-time data can be based on real-time data generated by the user's actions. For example, if authentication module 3010 authenticates the user's identity based on location data included in the real-time data, the location data can indicate the user's current location. Authentication module 3010 can use various analysis schemes and techniques to analyze many different portions of attribute data to authenticate the user's identity. The following discussion provides only a non-limiting example of authentication module 3010 authenticating the user's identity based on attribute data.

[0279] In an example embodiment, authentication module 3010 can identify portable devices (e.g., mobile devices, wearable devices) corresponding to a user based on real-time data, and use the identified portable devices as the basis for authenticating the user's identity based on the real-time data. For example, authentication module 3010 can calculate an identity probability metric based on the identified portable devices. The identity probability metric can indicate the likelihood that the identified portion of the attribute data identifies the user. In a specific example, the user may be operating a computer, carrying a mobile device, and wearing a smartwatch. In this example, attribute module 230 can receive real-time data from each device. If authentication module 3010 determines that the mobile device and smartwatch correspond to the user (e.g., by matching the corresponding device identifier with the device identifier corresponding to the user), then authentication module 3010 can authenticate the user's identity based on the real-time data received from these devices, reasoning that if it is determined that a person is carrying one or more devices belonging to the user, then that person is likely the user (e.g., the identified portable devices suggest or indicate that the person is likely the user). The more devices that person may be carrying belonging to the user, the stronger the basis for that person being the user.

[0280] Continuing the example above, authentication module 3010 can authenticate the user's identity based on authentication of mobile devices and wearable devices, and on real-time data corresponding to the computer. Authentication module 3010 can perform this authentication, for example, based on the location of the computer relative to the user's portable device. For instance, if the computer's location is the same as or within a short distance (e.g., arm's length) of the user's portable device, authentication module 3010 can infer that the user is using the computer. This authentication can also be based on sensor data (e.g., near-field, [missing information]) included in the real-time data. The location of the computer can be established through other interactions between the portable device and the computer (or other interactions between the portable device and the computer). In other words, the location of a particular portable device can be determined based on its GPS component, and the location of the device communicating with that particular portable device can be inferred based on short-range communication with short-range operation. Therefore, in this example, the authentication module 3010 can authenticate the user's identity based on real-time data received from the computer. The above is only a non-limiting example, and the authentication module 3010 can employ many other techniques to authenticate the user's identity based on real-time data from various devices.

[0281] In other example embodiments, the authentication module 3010 may use other indicators of the user's identity regarding real-time data to authenticate the user's identity. For example, the authentication module 3010 may use sensor data at least in part to authenticate the user's identity. For example, the sensor data may include biometric data, which the authentication module 3010 may use to authenticate the user's identity. In specific examples, the biometric data may include biometric identification data, such as fingerprint scans, voice samples, retinal scans, facial scans, or electroencephalogram (EEG) data (see additional biometric identification data). Figure 53 The authentication module 3010 can match, correlate, or otherwise determine that bioassay data corresponds to a user, thereby authenticating the user's identity based on real-time data.

[0282] In other example embodiments, authentication module 3010 may use location data to authenticate a user's identity with respect to real-time data. For example, location data (e.g., determined by the GPS component of a mobile device) may indicate a location pattern that authentication module 3010 can use to authenticate a user's identity. In this example, the location pattern may include being at a specific location at a specific time, or a specific route at a specific time. In a specific example, location data may indicate a location that may be the user's home. If the location may be the user's home, then it is possible that the real-time data provided by the mobile device may correspond to the user. Therefore, in some example embodiments, authentication module 3010 may authenticate a user's identity based on real-time data that may correspond to a location (e.g., typically a restricted location where the user has access, such as home or office) and referencing the real-time data.

[0283] Continuing the discussion on operation 3130, Figure 32 This illustrates some example embodiments. Figure 31 The flowchart shows some other example operations of method 3100. As described above, after operation 3120, in operation 3130, authentication module 3010 can authenticate the user's identity by analyzing the identified portion of real-time data. Furthermore, in operation 3210, authentication module 3010 can calculate an identity probability measure based on the identified portion of attribute data. The identity probability measure can indicate the likelihood that the identified portion of attribute data identifies the user (e.g., the probability that the identified portion of real-time data identifies the user).

[0284] The authentication module 3010 can use various schemes and techniques to calculate the identity probability metric. In an example embodiment, the authentication module 3010 can weight different portions of the real-time data that indicate the user's identity. For example, the authentication module 3010 can give greater weight to real-time data that strongly indicates the user's identity (e.g., a fingerprint scan that matches the user's fingerprint scan). Conversely, the authentication module 3010 can give less weight to real-time data that does not strongly indicate the user's identity (e.g., real-time data indicating a user's device being in a specific location at a specific time may indicate the user's identity, but may not be as strongly suggestive of the user's identity as biometric identification data). In some example embodiments, the authentication module 3010 can use a combination of real-time data to calculate the identity probability metric.

[0285] After calculating the identity probability metric, in decision 3220, authentication module 3010 can determine whether the identity probability metric exceeds an authentication threshold. In an example embodiment, when the identity probability metric exceeds the authentication threshold, authentication module 3010 can authenticate the user's identity. Conversely, if the identity probability metric does not exceed the threshold, authentication module 3010 may not be able to authenticate the user's identity, and no further operation is performed in method 3100.

[0286] In operation 3230, authentication module 3010 can authenticate the user's identity. As described above, authentication module 3010 can use an identity probability measure exceeding an authentication threshold as a factor for authenticating the user's identity based on real-time data. Authentication module 3010 can use the identity probability measure alone or in combination with other factors to authenticate the user's identity. Once the user's identity has been authenticated based on real-time data, the subsequent operations of method 3100 can be performed.

[0287] When further discussing operation 3130... Figure 33 This is a flowchart illustrating another embodiment for authenticating a user's identity according to some example embodiments. Following operation 3120, in operation 3130, the authentication module 3010 can authenticate the user's identity by analyzing the identified portions of the attribute data. Furthermore, in operation 3310, the authentication module 3010 can derive, extract, or otherwise obtain past identification indications from past attribute data. For example, if the past attribute data includes location data, the authentication module 3010 can extract locations corresponding to the user's preferences or frequently visited locations.

[0288] In operation 3320, authentication module 3010 can derive, extract, or otherwise obtain real-time identification indications from real-time data. For example, real-time data may include location data. In some example embodiments, real-time identification indications can be derived. For instance, authentication module 3010 may derive location information based on short-range communication with a device at a known or fixed location.

[0289] In operation 3330, authentication module 3010 can calculate an identity probability measure by relating, matching, or otherwise comparing real-time identification indications with past identification indications. For example, if real-time data indicates a specific location, authentication module 3010 can match that specific location with locations the user frequently visits to authenticate the user's identity. Although Figure 33 The discussion focuses primarily on location data, but the authentication module 3010 can use many other types of data included in the attribute data in a similar manner to calculate an identity probability metric.

[0290] Return Reference Figure 31 In operation 3140, activity module 3020 can identify or infer user activities being performed by the user based on real-time data. In other words, activity module 3020 can identify user goals that the user is pursuing (e.g., logging into a website) based on real-time data. User activities can include a wide variety of activities, such as operating a computer (e.g., logging into a website), jogging in a park, walking towards a refrigerator, and streaming video or other media content. In an example embodiment, activity module 3020 can identify user activities based on sensor data and status data received from one or more user devices. Status data can indicate activities associated with a specific device. For example, user devices can include mobile devices that provide location data and various other user devices that can provide status data (e.g., a smart TV that indicates the current operational status (e.g., streaming specific media)). In this example, activity module 3020 can infer user activities by combining status data with location data (e.g., based on location data, the user may be near a smart TV, and the smart TV may indicate that it is streaming video).

[0291] In another example, the activity module 3020 can infer, extract, or derive state data of a specific device based on the analysis of sensor data corresponding to that device. For example, a mobile device may be equipped with an accelerometer that measures motion and provides motion data. If the motion data indicates that the device is not moving, the activity module 3020 can infer that the person may not be carrying that specific device. In this scenario, the activity module 3020 may not be able to infer user activity based on a device that the user is not currently carrying. The above examples are merely non-limiting examples of how the activity module 3020 identifies or infers user activity based on real-time data. The activity module 3020 can use many other parts of real-time data in various ways to identify or infer user activity.

[0292] In operation 3150, activity module 3020 can enhance, adapt, or otherwise modify user activities based on user settings or preferences. In other words, activity module 3020 can enhance the user's environment based on user preferences to facilitate the user's progress toward user goals. The user's environment is intended to include, for example, user devices near the user. For example, if user activities include authorization tasks (e.g., logging into a website), activity module 3020 can enhance user activities by adjusting the security level of the authorization tasks. In some example embodiments, activity module 3020 can adjust the security level of authorization tasks based on an identity probability metric. For example, if the identity probability metric strongly indicates that the user's identity is authenticated, the security level can be lowered more than if the identity probability metric does not strongly indicate that the user's identity is authenticated. In some example embodiments, adjusting the security level of authorization tasks can include automatically performing authorization tasks on behalf of the user. For example, if authentication module 3010 has already authenticated the user's identity, and user activities include accessing a specific website, activity module 3020 can automatically log the user into the specific website.

[0293] In another specific example, the identified user activity could include making a payment (e.g., an electronic payment to an e-commerce website corresponding to a list of items listed on an e-commerce website, or an electronic payment to a merchant in a physical store). Activity module 3020 can enhance user activity associated with making a specific payment by facilitating payments between users and payees. For example, based on authentication of the user's identity, the user may not need to provide security credentials or may need to provide fewer security credentials to make a payment.

[0294] To help illustrate the above discussion, Figure 34 Communication between a user's device and a data grid system 150 is depicted according to some example embodiments. Figure 34In the illustration, user 3410 may wear one or more smart devices, such as smartwatch 3420. Smartwatch 3420 can be communicatively coupled to network 104 via various modalities. For example, smartwatch 3420 can be communicatively coupled to network interface 3440, which in turn is communicatively coupled to network 104. For example, smartwatch 3420 can transmit a signal 3430 received at network interface 3440. In another example, smartwatch 3420 can be communicatively coupled to network 104 without network interface 3440. Additionally, networking system 102, including data grid system 150 and enhancement system 280, can be communicatively coupled to network 104.

[0295] Therefore, the user's smartwatch 3420 can be communicatively coupled to the data grid system 150, which includes the enhancement system 280. The data grid system 150, including the enhancement system 280, can receive or access attribute data corresponding to the smartwatch 3420 via the network 104. Similarly, the data grid system 150, including the enhancement system 280, can communicate with or exchange data with the smartwatch 3420 to enhance user activities, such as transmitting instructions to present a user interface. Although Figure 34 The example depicts a sample smartwatch 3420, but it should be understood that a wide variety of other devices can be similarly configured to interact with the data grid system 150.

[0296] Figures 35 to 38 This illustrates some example embodiments. Figure 31 The flowchart shows some other example operations of method 3100. After operation 3140, in operation 3150, the activity module 3020 can enhance user activities according to user settings. Figures 35 to 38 Each flowchart illustrates an additional operation of operation 3150. The additional operations of operation 3150 include various example embodiments of enhancing user activity based on user settings. The following discussion describes only non-limiting examples, and the enhancement system 280 can employ many other schemes and techniques to enhance user activity using user settings.

[0297] exist Figure 35In the flowchart, after operation 3140, in operation 3510, the settings module 3030 can determine user settings based on attribute data and user activity. For example, the settings module 3030 can store multiple user settings in a storage device such as database 126. After determining user activity, the settings module 3030 can determine user settings associated with or related to user activity. For example, user activity may include a user streaming a movie to a specific user device. Based on the activity identified by the activity module 3020 for streaming the movie, the settings module 3030 can determine user settings associated with enhancing the user activity of streaming the movie, such as automatically pausing streaming when the user leaves the vicinity of the specific device that presented the movie to the user.

[0298] In operation 3520, activity module 3020 can enhance user activities based on determined user settings. Continuing the example above, user activities can include streaming movies. Activity module 3020 can enhance user activities based on determined user settings. For example, activity module 3020 can automatically pause or otherwise stop the movie based on a trigger (e.g., the user leaves the vicinity or answers a phone call), present the streaming movie to another display based on user settings and the user's location, and so on. While the above discussion pertains to streaming movies, activity module 3020 can enhance user activities, including many other activities, based on many different types or categories of user settings.

[0299] exist Figure 36 In the flowchart, following operation 3140, in operation 3610, feature module 240 can directly infer or measure user characteristics based on the analysis of at least a portion of the attribute data. As discussed above in conjunction with operation 610, feature module 240 can infer various user characteristics from attribute data using various data. It will be understood that the discussion of operation 610 related to feature module 240 also applies to operation 3610.

[0300] In operation 3620, the settings module 3030 can determine user settings based on inferred user characteristics and user activities. For example, the inferred user characteristics may indicate that the user prefers to view the user interface on the largest available screen. In this example, the settings module 3030 can determine that the user settings include presenting the user interface on the largest available screen.

[0301] In other example embodiments, the setting module 3030 may identify users similar to the user based on attribute data or user characteristics. For example, the setting module 3030 may identify users associated with demographic data that is the same as or similar to the user's demographic data. In example embodiments, the setting module 3030 may determine user settings based on attribute data or characteristics corresponding to similar users. For example, the setting module 3030 may access user characteristics corresponding to other users and correlate, match, or otherwise compare the user's user characteristics with those of other users to identify similar users.

[0302] In operation 3630, activity module 3020 can enhance user activity based on determined user settings. For example, if a user is viewing a specific user interface on a mobile device and is within a certain distance of a larger screen (such as a computer or smart TV), activity module 3020 can enhance user activity by presenting the specific user interface on the larger screen.

[0303] exist Figure 37 In the flowchart, following operation 3140, in operation 3710, activity module 3020 can determine that user activity includes presenting a user interface to the user. For example, presenting a user interface may include the user watching a movie, using a website, or reading an email. Activity module 3020 can determine that user activity includes the presentation of a user interface based on real-time data. For example, the status data of a user's specific device may indicate that a particular device is likely presenting a user interface to the user.

[0304] In operation 3720, the activity module 3020 can identify the presentation devices available to the user based on attribute data that enables the presentation of a user interface. For example, the user may be in a room containing several user devices, such as a smart TV, a laptop computer, and a mobile device. The activity module 3020 can identify these devices based on real-time data. For example, if the smart TV is active and connected to a network, the activity module 3020 can query the smart TV to determine whether it is capable of presenting a user interface.

[0305] In operation 3730, activity module 3020 can determine alternative presentation devices from the identified presentation devices based on user settings. Activity module 3020 can determine alternative presentation devices based on multiple factors. For example, user settings may indicate that the user prefers to view a larger screen when available. Based on this user setting, activity module 3020 can identify presentation devices with larger displays. In another example, activity module 3020 can determine that alternative presentation devices should be near the user. For example, a particular presentation device outside the user's field of vision may not be the best choice among alternative presentation devices. Activity module 3020 can make this determination based on location data included in real-time data. In yet another example, activity module 3020 can identify portable presentation devices. For example, activity module 3020 can determine that the user is watching a movie and the user is leaving the vicinity, and can determine that a portable device continuing to play the movie is a desirable choice as an alternative presentation device.

[0306] In operation 3740, activity module 3020 can present the user interface to the user using alternative presentation devices. In a specific example, the user may be watching a live sports event on a smart TV. When the user leaves the vicinity of the smart TV, activity module 3020 can cause the live sports event to be presented to alternative presentation devices, such as another smart TV that the user can watch, or a portable device that allows the user to continue watching the live sports event even when it is out of the line of sight of the initial presentation device.

[0307] exist Figure 38 In the flowchart, following operation 3140, in operation 3810, the activity module 3020 or the feature module 240 can determine the user's current location based on real-time data. For example, real-time data may include location data determined by the mobile device's GPS component, near-field beacon detection, and other location services.

[0308] In operation 3820, the activity module 3020 or the feature module 240 can access device location data included in attribute data containing real-time data. Similar to operation 3810, the activity module 3020 can access, receive, or otherwise obtain device location data based on GPS, near-field beacon detection, and other location services. Although Figure 38 The illustration shows that operation 3810 is performed before operation 3820; however, in alternative example embodiments, operation 3810 may be performed simultaneously with operation 3820 or after operation 3820. For example, activity module 3020 may simultaneously receive, access, retrieve, export, or otherwise obtain the user's current location and device location data in any order, and perform... Figure 38 The subsequent operations are shown in the diagram.

[0309] In operation 3830, activity module 3020 can identify user devices within the user's operating distance based on the user's current location and device location data. The operating distance can be configurable or dynamically determined. In some example embodiments, the operating distance can vary depending on the device. For example, the operating distance for a smart TV could be a reasonable distance that allows the user to watch the smart TV. In other examples, the operating distance for a mobile device could be a reasonable distance (e.g., arm's length) that allows the user to touch the mobile device.

[0310] In operation 3840, the activity module 3020 can enhance the operation of the identified user devices based on user settings. In some example embodiments, the activity module 3020 can enhance the operation of the identified user devices based on user settings and user activities. For example, if user activity includes the user moving to the smart kitchen, the user activity module 3020 can enhance the operation of each user device based on the user's settings upon moving to the smart kitchen. For example, relevant notifications (e.g., notifications about the status of smart kitchen appliances) can be pushed to the user's mobile device based on the user moving to the smart kitchen or being in the smart kitchen. In another example, the activity module 3020 can cause smart appliances in the smart kitchen to automatically perform tasks on behalf of the user based on the user moving to the smart kitchen (e.g., automatically brewing a cup of coffee).

[0311] To help illustrate the above concept, Figure 39 Non-limiting examples of enhanced user activity according to some example embodiments are shown. Scenario 3900 depicts a living room attached to an open-plan kitchen. Scenario 3900 may include a media entertainment device 3910, a smart TV 3920, a light 3930, a mobile computer 3940, a mobile device 3950, a user 3960, a smart refrigerator 3970, and a kitchen display 3980. Each of devices 3910-3950, 3970, and 3980 may be a source of attributes coupled to a network (e.g., network 104) and operable to communicate with a data grid system 150. In various example embodiments, real-time data may include location data corresponding to the user. For example, user 3960 may be carrying a mobile device or another smart device (e.g., a smartwatch, a smart ring with NFC functionality) that can provide real-time location data (e.g., determined by a GPS component, beacon location detection, or other location services). In this way, the location of user 3960 can be tracked, monitored, or observed via a specific device worn by user 3960, or the location of user 3960 can be derived from various real-time data associated with the user's location included in the attribute data (e.g., the distance between the device worn by user 3960 and another device with a known or fixed location). (Handshake). The Activity Module 3020 can infer user activity based on real-time data and enhance user activity based on user settings.

[0312] In an example embodiment, the activity module 3020 may determine that user 3960 may be streaming media content to smart TV 3920 and may be moving from smart TV 3920 to the kitchen. In this example, the activity module 3020 may identify mobile computer 3940 and display 3980 as alternative presentation devices. The activity module 3020 may further determine that kitchen display 3980 is likely a preferred alternative presentation device because it is likely within viewing distance of user 3960. The activity module 3020 can then enhance user 3960's activity by presenting streaming content on kitchen display 3980 and stopping presentation to smart TV 3920. In other example embodiments, the activity module 3020 may also determine that user 3960 has opened smart refrigerator 3970 and may pause media content streaming when user 3960 may be using smart refrigerator 3970.

[0313] In another example embodiment, authentication module 3010 can authenticate user 3960 by detecting a mobile device or wearable device that user 3960 may be carrying near kitchen display 3980 (e.g., detected based on attribute data, which may include data feeds from the mobile device, wearable device, and kitchen display 3980). Subsequently, activity module 3020 can detect that user 3960 is moving within the operating distance of a specific user device (e.g., kitchen display 3980) (e.g., a reasonable distance, such as a distance that would place user 3960 and the specific device in the same room). Activity module 3020 can detect movement via the GPS component of a mobile device that user 3960 may be carrying, or short-range communication detection (e.g., between user 3960's mobile device and kitchen display 3980). Or near-field communication handshake) or other methods to detect whether user 3960 is within the operating distance of kitchen monitor 3980.

[0314] Then, the activity module 3020 can present a personalized message to user 3960 on a kitchen display 3980 that may be related to or associated with user 3960, based on the context or environment of user 3960 determined by the settings module 3030 through analysis of attribute data (e.g., the attribute data may include calendar information corresponding to user 3960 or food inventory information provided by the smart refrigerator 3970). For example, the personalized message could be a reminder about an upcoming appointment or a reminder to purchase a specific product that user 3960 may be running out of. For specific users other than user 3960, the activity module 3020 can present different personalized messages or perform different user activity enhancements. Thus, in this example, the enhancement system 280 has received attribute data associated with a user (e.g., user 3960), authenticated the user's identity with real-time data (e.g., by detecting a portable device corresponding to user 3960), identified user activity (e.g., walking near the kitchen display 3980), and enhanced the user's activity according to user settings (e.g., presenting a personalized message to user 3960 on the kitchen display 3980).

[0315] In another example embodiment, the activity module 3020 may detect that the user 3960 may be near the lamp 3930 (e.g., the user 3960 and the lamp 3930 are in the same room) via location tracking of the user 3960 (e.g., a wearable device worn by the user). In response to the activity module 3020 detecting that the user 3960 is near the lamp 3930, the activity module 3020 may enhance the user 3960's environment by turning on the lamp 3930 or changing the brightness of the lamp 3930 (e.g., the lamp 3930 may be a smart lamp operable to perform various commands, or the lamp 3930 may be coupled to a smart socket operable to control various functions of the lamp 3930). The activity module 3020 may adjust the operation of the lamp 3930 according to user settings corresponding to the lamp 3930 determined by the setting module 3030 (e.g., adjusting the brightness of the lamp 3930 according to the historical brightness of the lamp 3930 corresponding to the user 3960).

[0316] Figure 40An enhanced example user interface for facilitating user activity is depicted according to another embodiment. In the example embodiment, activity module 3020 can recognize user activity, such as a user moving to a specific location (e.g., the kitchen). In some embodiments, activity module 3020 can enhance user activity by presenting a user interface to the user. An example mobile device 4000 displaying an example notification 4010 is shown. Activity module 3020 can present the user with relevant notifications within the context of the user activity, such as notification 4010. For example, if the user has just entered the kitchen, this might be a good time to provide the user with kitchen-related information (e.g., kitchenware). In the example embodiment, attribute data may include data indicating food availability received from a smart refrigerator (e.g., smart refrigerator 3970). Activity module 3020 can enhance user activity by presenting the user with notification 4010 regarding food availability. In this example embodiment, the user can interact with notification 4010 using user interface element 4020 (e.g., order the item or turn off the notification).

[0317] Figure 41 This illustrates a method for promoting, according to an example embodiment. Figure 31 The flowchart 4100 shows the various communication methods. In operation 4110, the attribute source 4102 can transmit attribute data to the data grid system 150. (See above reference...) Figure 31 The data grid system 150 can receive attribute data in operation 3110, authenticate the user's identity in operation 3130, identify user activities in operation 3140, and enhance user activities in operation 3150.

[0318] The data grid system 150 can enhance user activity by communicating with user equipment 4106. During operation 4120, user equipment 4106 can facilitate enhanced user activity. For example, the data grid system 150 can transmit instructions to user equipment 4106 to present a specific user interface (e.g., a notification), and in response, user equipment 4106 can present the user interface.

[0319] In operation 4130, user equipment 4106 can transmit data associated with user actions in response to user activity. Data associated with user actions enhancing user activity can indicate whether the user requires the enhancement. For example, if the enhancement includes presenting a notification to the user and the user ignores the notification, settings module 3030 can use this as a basis for determining user settings in subsequent analysis.

[0320] Similarly, in operation 4140, attribute source 4102 can transmit attribute data associated with user actions enhanced in response to user activity. For example, data grid system 150 can request, retrieve, or otherwise obtain attribute data associated with user actions enhanced in response to the user from attribute source 4102. Attribute source 4102 can transmit attribute data indicating whether the user requires enhancement.

[0321] In operation 4150, the settings module 3030 can infer enhancement results based on data received from user device 4106 and attribute source 4102. The settings module 3030 or the features module 240 can identify user actions based on real-time data, user actions responding to the enhancement, or the environment. For example, user actions may include ignoring notifications or interacting with the user interface. Enhancement results can indicate whether the user needs the enhancement. For example, attribute data may include engagement data indicating user participation in a specific activity (e.g., clicking a user interface element). The settings module 3030 can infer enhancement results based on engagement data or other data. In some other example embodiments, the activity module 3020 may store enhancement results in a storage device such as database 126 for later use in determining user settings. Thus, as more data associated with enhancements is received over time, the settings module 3030 can allow user settings to evolve to better suit the user.

[0322] Now let's turn to another example embodiment. Figure 42 This is a block diagram of visualization system 290, which provides functions for analyzing attribute data and generating visualizations based on the attribute data. Visualization system 290 may include analysis module 4210, business module 4220, and visualization module 4230.

[0323] The analysis module 4210 in the visualization system 290 can perform various analyses to facilitate the functions described herein. For example, the analysis module 4210 can determine whether reward criteria associated with attribute data are met. In this example, the reward criteria may include fitness goals, and the analysis module 4210 can determine whether a user has met their fitness goals based on the analysis of the attribute data. The analysis module 4210 can perform many other rewards and analyses.

[0324] The commerce module 4220 can identify items from an e-commerce platform (e.g., publishing system 142). Items (e.g., a list of items on an e-commerce website) are intended to include products, services, events, etc. The commerce module 4220 can also retrieve item data associated with the identified items, such as item price, seller, item location, seller location, item image, item description, etc. In some example embodiments, the commerce module 4220 can facilitate a user's purchase of the identified items.

[0325] The visualization module 4230 can generate visualizations at least partially based on attribute data. The visualizations can represent the attribute data. For example, the visualization module 4230 can generate virtual avatars representing attribute data. For instance, the attribute data can indicate demographic data corresponding to a user, such as gender, age, height, etc. The visualization module 4230 can generate virtual avatars based on demographic data, such as virtual avatars of the same gender and similar age, height, etc. Subsequently, the presentation module 210 can present the generated visualizations to the user.

[0326] Figure 43 This is a flowchart illustrating an example method 4300 for generating visualizations according to some example embodiments. The operation of method 4300 can be performed by components of the data grid system 150 and the visualization system 290. In operation 4310, the attribute module 230 can receive user-associated attribute data from multiple attribute sources. (As will be combined...) Figure 52 and Figure 53 The discussion focuses on the possibility of receiving attribute data from a wide range of attribute sources, such as devices, sensors, servers, databases, and others. Furthermore, the attribute module 230 can receive attribute data via numerous paths resulting from the classification of attribute sources through configuration, such as combining... Figure 51A and Figure 51B Further discussion follows. In the example embodiment, attribute module 230 can receive attribute data directly from an attribute source. In other example embodiments, attribute module 230 can receive attribute data from a central device, where the central device receives attribute data from multiple user devices. In other example embodiments, various user devices can be communicatively coupled in a distributed device-to-device grid, and attribute module 230 receives attribute data corresponding to a specific device in the grid from any device in the grid. Through many other configurations, including various suitable combinations of configurations, attribute module 230 can receive attribute data from an attribute source.

[0327] In various example embodiments, attribute module 230 may store attribute data in association with users (e.g., indexed based on user identifiers) for subsequent analysis. For example, attribute module 230 may store attribute data in a storage device such as database 126. Attribute module 230 may access the stored attribute data using various search or lookup schemes. For example, attribute data associated with a specific user may be accessed using a user identifier corresponding to that specific user. It will be noted that collective and aggregated attribute data may be referred to as a "data grid".

[0328] In various example embodiments, at least a portion of the attribute data may include real-time or near-real-time data. The term "real-time data" as used herein is intended to include data associated with currently occurring events. For example, real-time data may include user input data or sensor data that is transmitted to the attribute module 230 after a delay interval (e.g., caused by transmission delays or other delays, such as temporary storage at an intermediate device) between data capture and data reception by the attribute module 230.

[0329] In operation 4320, feature module 240 can infer or directly measure one or more user features based on the analysis of at least a portion of the attribute data. As discussed above in conjunction with operation 610, feature module 240 can infer various user features from attribute data using various data. It will be understood that the discussion of operation 610 in relation to feature module 240 also applies to operation 4320.

[0330] In specific examples, feature module 240 can infer a user's physical size based on attribute data that may include purchase history. For instance, feature module 240 can use demographic information such as age, gender, or location to filter clothing purchases included in the purchase history (e.g., filtering to identify clothing purchases for the user). Based on the filtered clothing purchase history, feature module 240 can identify the user's physical size based on the clothing sizes purchased. In another specific example, feature module 240 can infer a user's fitness level based on fitness tracking software included in the user's mobile device. Therefore, in these specific examples, feature module 240 can infer various physical characteristics or traits of the user based on attribute data.

[0331] In operation 4330, visualization module 4230 may generate visualizations at least in part based on user characteristics. In some cases, as used herein, the term "visualization" is intended to include both visual and non-visual components of a presentation (e.g., animation of audio to animated cues). The term "visualization" is also intended to include still images, animations, and other forms of visual presentation.

[0332] In an example embodiment, the visualization may include a chart or graph that can indicate a metric associated with the attribute data. For example, the metric associated with the attribute data may be a completeness metric that indicates the completeness of the attribute data associated with the user. That is, a completeness metric may indicate the amount of attribute data compared to a target amount of attribute data or the amount of attribute data available (e.g., a completeness metric may indicate that the amount of attribute data associated with the user is 60 percent of the target amount of attribute data).

[0333] In another example embodiment, the visualization may include a virtual avatar representing the user. For example, the virtual avatar may be an animated or image of a humanoid figure designed to represent the user. The virtual avatar does not necessarily need to resemble the user's physical attributes or personality traits. However, in some example embodiments, the virtual avatar may be designed to include attributes or traits similar to or identical to the user's attributes or traits. In other words, the virtual avatar may be visually similar to the user. The visualization module 4230 may determine the virtual avatar characteristics based at least in part on the inferred user characteristics and include the virtual avatar characteristics when generating the virtual avatar. In some example embodiments, user characteristics may include the user's physical characteristics, and the virtual avatar characteristics may include representations of physical characteristics. For example, the feature module 240 may infer various user characteristics, such as the user's physical dimensions, demographic information, personality traits, etc. In this example, physical dimensions may indicate a height of six feet, demographic information may indicate gender as female and age as 22, and personality traits may indicate eccentricities. Thus, the virtual avatar in this example may resemble a six-foot-tall woman and may include clothing consistent with having eccentricities. Therefore, the virtual avatar may visually represent various characteristics of the user.

[0334] In various example embodiments, the visualization module 4230 can employ various schemes and techniques to determine virtual avatar characteristics, at least in part, based on the inferred user characteristics. In example embodiments, the analysis module 4210 can identify similar users based on various factors. In some example embodiments, the analysis module 4210 can access attribute data and stored user characteristics corresponding to multiple other users. For example, the analysis module 4210 can identify similar users from multiple other users based on the inferred user characteristics of the user and the corresponding user characteristics of multiple other users. The analysis module 4210 can correlate, match, or otherwise compare the inferred user characteristics with the corresponding user characteristics of multiple other users to identify similar users. In various example embodiments, the analysis module 4210 can identify similar users based on identical or similar demographic data (e.g., identical or similar age, gender, location, etc.), identical or similar user characteristics (e.g., identical or similar brand purchases), identical or similar attribute data, etc. For example, the analysis module 4210 can correlate the inferred user characteristics with the corresponding user characteristics of other users to identify similar users.

[0335] After the analysis module 4210 identifies similar users, the visualization module 4230 can extract common features from the identified similar users. The visualization module 4230 can generate visualizations based on the extracted common features. In the example above, the analysis module 4210 can identify specific similar users associated with eccentric personalities. Continuing this example, the visualization module 4230 can extract common features (e.g., specific styles of clothing or brands) from multiple identified users. For example, common features could be wearing specific clothing colors, styles, brands, etc. The visualization module 4230 can generate or present virtual avatars that include specific virtual avatar characteristics corresponding to the common features (e.g., wearing a specific clothing brand).

[0336] In other example embodiments, the visualization module 4230 may apply weights to the inferred user features and extracted common features in various schemes to generate visualizations based on the inferred user features or extracted common features. For example, a specific user feature inferred from specific attribute data corresponding to a more distant past time may have a smaller weight than a specific user feature inferred from more recent specific attribute data, the reasoning being that the more recent data may be more relevant or related to the goal of generating the visualization in a way that accurately reflects the user or attribute data. The visualization module 4230 may use many other schemes to apply weights, and the above are merely non-limiting examples.

[0337] In other example embodiments, the visualization module 4230 may generate the visualization based at least in part on real-time data included in the attribute data. For example, the feature module 240 may infer user characteristics at least in part based on real-time data, and the visualization module 4230 may generate the visualization based on the user characteristics inferred from the real-time data. Thus, the visualization can reflect the user's current state. In a specific example, the feature module 240 may infer that the user is currently jogging energetically in a park. The visualization module 4230 may, for example, generate a visualization including sweating characteristics indicating that the user is currently engaged in an energetic physical activity, such as a virtual avatar. Thus, the visualization can represent the user's real-time state. In another example, the feature module 240 may infer the equipment the user is currently wearing (e.g., inferred from attribute data, where the attribute data may include detections from smart tags embedded in the user's clothing), and the visualization module 4230 may generate a virtual avatar including a representation of the inferred equipment.

[0338] In operation 4340, presentation module 210 can cause a visualization to be presented to a user. For example, the visualization may include a virtual avatar, and presentation may be displaying the virtual avatar on a screen. Presentation module 210 causing the visualization to be presented may include transmitting instructions to a user operable to present the visualization to the user. In other example embodiments, presentation module 210 can cause the visualization to be presented to other users. For example, a user may be associated with a profile, and viewers of the user profile may also see the visualization. In other example embodiments, a user may be associated with a contact user with whom the user has a connection (e.g., based on social media relationships). In this example embodiment, the visualization may be presented to the contact user.

[0339] Figure 44 This illustrates some example embodiments. Figure 43 The flowchart shows some other example operations 4400 of example method 4300. After operation 4340, in operation 4410, the presentation module 210 may receive user input indicating changes to the visualization. For example, the user input may indicate that the visualization is based on user characteristics or does not reflect the user's attribute data. In this example, the visualization may be a virtual avatar, and the physical characteristics of the virtual avatar may not reflect the user (e.g., the virtual avatar is too short compared to the user).

[0340] In operation 4420, the visualization module 4230 can update the visualization based on changes indicated by user input. In the example above, if the user input indicates that the virtual avatar is too short, the visualization module 4230 can generate or present a virtual avatar with a taller stature.

[0341] In other example embodiments, the attribute module 230 can update or modify attribute data based on user input. For example, if the user input indicates demographic data (e.g., age) in addition to the data currently associated with the user, the attribute module 230 can update the demographic information based on the user input.

[0342] In other example embodiments, the feature module 240 may infer user characteristics based on the analysis of attribute data and user input. For example, if the user input indicates a specific clothing style, color, brand, etc., the feature module 240 may use that user input as the basis for combining it with attribute data to infer user characteristics.

[0343] Figure 45This is a flowchart illustrating an example method 4500 for determining whether reward criteria are met and providing a reward to a user, according to some example embodiments. The operation of method 4500 can be performed by components of the data grid system 150 and the visualization system 290. In operation 4510, the analysis module 4210 can determine whether reward criteria associated with attribute data are met. Reward criteria can include various standards.

[0344] In an example embodiment, the reward criteria may include criteria based on an integrity metric. In an example embodiment, the analysis module 4210 may determine the integrity metric based on analysis of the attribute data. The integrity metric may indicate the amount of attribute data available to the data grid system 150. In some example embodiments, the integrity metric may indicate the amount of attribute data compared to a target amount or the amount of available attribute data (e.g., the integrity metric may indicate that the amount of attribute data associated with a user is 60 percent of the target amount). For example, a user may have been provided with attribute data, permission to access portions of the attribute data, or consent to access portions of the attribute data by the management module 250 (e.g., the user may have granted the management module 250 permission to allow the attribute module 230 to access mobile sensor data but not social network data). In this instance, the integrity metric may indicate that a portion of the attribute data may be unavailable to the attribute module 230. If the integrity metric exceeds a threshold, the analysis module 4210 may determine whether a criterion is met based on the integrity metric. The analysis module 4210 may predefine or dynamically determine the threshold based on various statistical analyses.

[0345] In another example embodiment, the integrity metric may be associated with a specified type of attribute data. In this further example embodiment, if a user provides attribute data of a specified type or grants permission to access attribute data of a specified type, the analysis module 4210 may determine the criteria based on the fulfillment of the integrity metric.

[0346] In another example embodiment, the reward criteria may include criteria based on quality metrics. In this example embodiment, the analysis module 4210 may determine the quality metrics based on the analysis of attribute data. Quality metrics may indicate the relevance or correlation of attribute data. For example, older attribute data may be less relevant than newer attribute data. In this example embodiment, newer attribute data may have higher quality metrics, and older attribute data may have lower quality metrics. Therefore, a specific user associated with continuously updated attribute data can be associated with a higher quality metric. The analysis module 4210 may determine reward criteria that include the criteria based on the quality metric exceeding a threshold. That is, for example, the analysis module 4210 may determine reward criteria that include specific criteria by providing recent data based on the quality metric. The analysis module 4210 may predefine or dynamically determine the threshold based on various statistical analyses.

[0347] In another example embodiment, the reward criteria may include criteria associated with completing a task. For example, the task may include a user recommending or communicating a product or app to other users (e.g., email, text message). The presentation module 210 may facilitate the user performing the task (e.g., automatically identifying available contacts and providing a pre-defined message that can be sent via the user interface provided by the presentation module 210). In other instances, the task may include a specified goal. In this instance, the goal may be, for example, a fitness goal, such as the number of steps taken in a day (e.g., determined by a pedometer app running on the user's mobile device). Continuing with this example, if the user exceeds a threshold number of steps, the analysis module 4210 may determine that a reward criterion, including one based on the number of steps taken, has been met.

[0348] In other example embodiments, the analysis module 4210 can determine reward criteria that include various standards (e.g., standards based on completeness or quality metrics) by comparing the metrics associated with the user with those of other users. As described above, the analysis module 4210 can identify similar users based on various factors. The analysis module 4210 can determine the fulfillment of reward criteria by comparing various metrics associated with the user with various metrics associated with similar users. In a specific example, similar users can include users who may have the same or similar demographic data (e.g., age, gender, location). Among these similar users, the analysis module 4210 can determine the average completeness metric or another statistically based value. The analysis module 4210 can compare the user's completeness metric with the average completion metric or another statistically based value to determine whether a specific criterion associated with the user's completeness metric is met (e.g., if the user's completeness is above average compared to similar users, then the user may meet the reward criteria). Similarly, the analysis module 4210 can compare the user's fitness goals with similar users who may have similar fitness levels. The analysis module 4210 can use many other comparisons with similar users or other users to determine the fulfillment of reward criteria. Therefore, in some example embodiments, the analysis module 4210 may determine whether the reward criteria are met based on attribute data associated with the identified similar users.

[0349] In operation 4520, the analysis module 4210 can provide rewards to the user based on the determined reward criteria. Rewards may include additional visual features or functionalities. For example, a reward may include the ability to provide the user with further customization of the visualization (e.g., modifying the virtual avatar's clothing). In another instance, a reward may provide the user with additional features, such as the ability to share the visualization with other users. Rewards may include many other features and functionalities related to the visualization.

[0350] In other example embodiments, rewards may include coupons, transactions, or other incentives. Rewards can incentivize users to provide consent, permission, or access to additional attribute data, to provide higher quality, more relevant attribute data, to complete various marketing tasks, to achieve various goals (e.g., fitness goals), and so on.

[0351] Figure 46This is a flowchart illustrating additional operations of method 4300 according to some example embodiments. Following operation 4320, in operation 4330, visualization module 4230 may generate a visualization based at least in part on user characteristics. Additionally, in operation 4610, commerce module 4220 may identify a list of items based on user characteristics. For example, user characteristics may indicate a user's preferences for clothing, electronic devices, etc. Furthermore, attribute data may include purchase history data that commerce module 4220 can use to determine the products a user already owns. By analyzing this information, commerce module 4220 can identify a list of items that the user is interested in (e.g., a list of items on an e-commerce website). Commerce module 4220 may employ various schemes and techniques for identifying item lists using user characteristics and attribute data.

[0352] In operation 4620, visualization module 4230 can generate visualizations that include the identified items associated with the identified item list. For example, the visualization generated by visualization module 4230 can include a virtual avatar that can represent the user. In this example, visualization module 4230 can generate a virtual avatar that includes a virtual avatar wearing or using suitable items associated with the identified item list. Business module 4220 can access item data associated with the identified items, wherein the identified items are associated with the identified item list. For example, business module 4220 can access item data that may include images of the items, physical dimensions of the items (e.g., clothing size), etc. Based on the item data, visualization module 4230 can generate visualizations that include representations of the identified items. This representation may be similar to the item in that it may include features similar to the identified item. For example, the identified item may be a specific garment. In this example, visualization module 4230 can present representations of garments with the same or similar sizes, colors, patterns, etc.

[0353] In other example embodiments, items associated with the identified list of items may be highlighted or otherwise emphasized during the rendering of the virtual avatar. In some example embodiments, a user can interact with the generated item presentation, which is associated with the identified list of items included in the virtual avatar (e.g., interacting with an item may prompt a recommendation for sale within the item list).

[0354] Figure 47This is a flowchart illustrating an example method 4700 for generating visualizations based on attribute data, according to some example embodiments. The operation of method 4700 can be performed by components of data grid system 150 and visualization system 290. In the example embodiment, at operation 4710, attribute source 4702 can transmit attribute data to attribute source 4704. At operation 4715, attribute source 4704 can receive attribute data from attribute source 4702. At operation 4720, attribute source 4704 can transmit attribute data to data grid system 150. As described above... Figure 43 As discussed, in operation 4310, the data grid system 150 can receive attribute data from attribute source 4704. In this example embodiment, attribute data can be exchanged between attribute source 4702 and attribute source 4704. In this way, the data grid system 150 can access various attribute data corresponding to a specific attribute source without directly communicating with that specific attribute source.

[0355] As described above Figure 43 As discussed, in operation 4320, feature module 240 can infer user features. In operation 4330, visualization module 4230 can generate a visualization at least partially based on user features. In operation 4340, presentation module 210 can cause the visualization to be presented to the user. Presentation module 210 can cause the visualization to be presented by transmitting the visualization to user device 4706. In operation 4725, user device 4706 can present the visualization to the user. For example, user device 4706 can be the user's mobile device, and presentation can be displaying the visualization on the screen of the mobile device. After presenting the visualization to the user, in operation 4730, user device 4706 can receive user input from the user. In some example embodiments, user input can originate from interaction with the presented visualization. In operation 4735, user device 4706 can transmit the user input to data grid system 150. For example, presentation module 210 of data grid system 150 can receive user input.

[0356] As described above Figure 44 As discussed, in operation 4410, the presentation module 210 can receive user input indicating changes to the visualization. In operation 4420, the visualization module 4230 can update the visualization based on the changes indicated by the user input. Therefore, Figure 47 Various communications or interactions between devices according to some example embodiments have been shown.

[0357] Figure 48 , Figure 49 , Figure 50A and Figure 50B An example user interface for presenting visualizations to the user is depicted. Although Figure 48 , Figure 49 , Figure 50A and Figure 50B Specific example visualizations and user interface elements are depicted, but these are merely non-limiting examples, and the presentation module 210 can generate many other alternative visualizations and user interface elements and present them to the user. It will be noted that... Figure 48 , Figure 49 , Figure 50A and Figure 50B Alternative presentations may include additional information, graphics, options, etc.; other presentations may include less information or provide reduced information that is easy for the user to use.

[0358] Figure 48 An example device 4800 is depicted displaying an example user interface 4810 for presenting visualizations to a user. In an example embodiment, the visualization may be a virtual avatar 4820 based on inferred user characteristics. In a specific example, an approximate physical size of a user can be derived from purchase history data such as clothing size, user input (e.g., user input to a fitness app requesting the user's measurements for various calculations). User characteristics may include style features extracted, derived, or inferred from attribute data (e.g., the type of clothing purchased, the type of activities the user participates in, etc.). In other example embodiments, the virtual avatar 4820 may be used as a virtual fitting measurement device to determine how specific clothing should be displayed on this person. Although Figure 48 The visualization depicts the virtual avatar 4820, but the visualization module 4230 can present many other various visualizations, which are presented to the user by the presentation module 210.

[0359] In some example embodiments, the user may have already provided interests and other information to the data grid system 150, as shown by user interface element 4830. In some example embodiments, the user can modify access permissions for user information, for example, by activating user interface element 4840. The user can also edit or modify attribute data, for example, by activating user interface element 4850. In other example embodiments, recommendations based on analysis of attribute data or user characteristics can be provided to the user. For example, activating user interface element 4860 can display various personalized recommendations.

[0360] Figure 49An example device 4900 is depicted displaying an example user interface 4910 that can present visualizations to a user. The example user interface 4910 may include recommended items or allow the user to provide user input to change the visualization. For example, user interface element 4930 may include multiple recommended items, such as user interface element 4940. A user can activate a specific recommended item (e.g., drag a user interface element onto an area occupied by a virtual avatar 4920) to indicate interest in that specific recommended item. In response to user activation of a specific recommended item, the visualization may be updated or otherwise modified. For example, the recommended item may be visually included in the visualization, such as displaying the virtual avatar 4920 wearing the recommended item when appropriate. In other example embodiments, the user can provide indications of interest and other information. For example, user interface element 4950 may include multiple user interests, such as interest 4960. In example embodiments, the user can select an interest from multiple interests. Based on the selected interest, visualization module 4230 can modify the visualization. In still other example embodiments, feature module 240 may incorporate the selected interest into analysis to determine user characteristics.

[0361] Figure 50A An example device 5010 for displaying a sample user interface 5010 for presenting visualizations to a user is depicted. Similarly, Figure 50B An example device is depicted displaying an example user interface 5050 for presenting visualizations to a user. In this example embodiment, as more attribute data is provided to the data grid system 150, the visualization module 4230 can present visualizations representing the attribute data in greater detail and accuracy. For example, the user could be a male college student of a certain age with a sporting background. In this example, Figure 50A The virtual avatar 5020 compared to Figure 50B The virtual avatar 5060 represents the user in a less detailed and less accurate manner. The virtual avatar 5020 can be an initial representation of the attribute data, and the virtual avatar 5060 can be a subsequent representation of the attribute data after the data grid system 150 receives more attribute data from the user, thereby allowing the visualization system 290 to represent the user more accurately.

[0362] Figure 51A and Figure 51BExample configurations for transmitting coupled attribute sources are depicted according to some example embodiments. The example embodiments described herein can access large and rich “Internet of Things” (IoT) datasets, which are primarily provided by connected, interconnected, or otherwise communicatively coupled machines and devices that may include a large number of sensors. In the example embodiments, the devices and machines providing attribute data (e.g., attribute sources) can be communicatively coupled in many different configurations. For example, each attribute source is independently and communicatively coupled to network system 102 to provide network system 102 with access to corresponding attribute data of each of the communicatively coupled attribute sources. Figure 51A and Figure 51B An alternative example property source configuration is described. It will be understood that... Figure 51A and Figure 51B This is merely a non-restrictive example of property source configuration, and many other configurations or appropriate combinations of configurations can be used.

[0363] Figure 51A An example embodiment is described, including an attribute source 5110 communicatively coupled in a distributed device-to-device grid. In this example embodiment, attribute data corresponding to a specific device in the grid can be received from any one or more devices in the grid. For example, in Figure 51A In this system, the network system 102 can access attribute data corresponding to attribute source E via attribute source H or via a combination of attribute sources H and I. In an example embodiment, attribute source H or I can aggregate and store attribute data corresponding to attribute source E. Figure 51A The attribute data of the attribute source AF in the system. In some example embodiments, the networking system 102 can communicate with... Figure 51A The attribute source H or I communicates to access the attribute data associated with the attribute source E.

[0364] Figure 51B It describes a scenario that may include communicative coupling to a centralized property source (e.g., Figure 51B Another example embodiment of attribute source 5120 (attribute source H) in the network system 102. Figure 51B A centralized attribute source is used to access attribute data associated with an attribute source AG. In some embodiments, the centralized attribute source can aggregate and store attribute data received or accessed from the attribute source AG, and target it for... Figure 51B The communication coupling attribute source AG provides a central access point for all or some of the associated attribute data.

[0365] Figure 52An example source 5200, including an attribute source 5210, is depicted according to some example embodiments. In various example embodiments, attribute data may include data received, retrieved, or accessed from attribute source 5210. For example, attribute source 5210 may provide all data, including everything from the humidity level of indoor plants to the dribbling rhythm of a basketball. In some embodiments, attribute data corresponding to attribute source 5210 may be received or accessed in real time or near real time. For example, attribute source 5210 may transmit or otherwise provide access to attribute data when it becomes available. In example embodiments, attribute source 5210 may include user device source 5220, user data source 5230, vehicle source 5240, material source 5250, third-party source 5260, home source 5270, and various other sources. Figure 53 As discussed, attribute source 5210 can be associated with a wide variety of sensors, instruments, measurement components and other components.

[0366] In an example embodiment, attribute data may include data corresponding to user equipment source 5220. User equipment source 5220 may include non-limiting examples such as personal computers (PCs), tablet computers, laptop computers, netbooks, set-top boxes (STBs), personal digital assistants (PDAs), entertainment media systems, cellular phones, smartphones, mobile devices, wearable devices (e.g., smartwatches), smart home devices (e.g., smart appliances), and other smart devices. Figure 53 Further discussion suggests that the attribute data corresponding to user equipment source 5220 may include data associated with sensors, instruments, or other measurement components, such as environmental sensor data (e.g., ambient temperature data related to the user's environment), biometric sensor data (e.g., the user's heart rate data), detection data (e.g., detection of near field communication (NFC) beacons), motion data (e.g., acceleration data), location data (e.g., location determined by the mobile device's GPS), and so on.

[0367] In other example embodiments, the attribute data corresponding to user device source 5220 includes data such as device type, device model, device name, unique device identifier, and other device parameters. In some example embodiments, device type data provides the basis for inferences associated with the attribute data. For example, if the device type data indicates that the device is a user's mobile device, then the location data corresponding to the mobile device can indicate the user's location. Similarly, if the device type is a media entertainment system, then the attribute data corresponding to the media entertainment system can be associated with the user's home.

[0368] User data source 5230 includes, for example, calendars (e.g., user calendar events such as birthdays, trips, exams), user profiles (e.g., demographic information such as age, gender, income level), purchase history, browsing history (e.g., search terms), social media content (e.g., registrations, posts, relationships), or other user data (e.g., bookmarked websites, preferences or settings for various applications, application usage data such as time spent using a specific application). For example, attribute data corresponding to user data source 5230 may be stored by user device source 5220 (e.g., mobile devices including mobile browsers with user browsing history), application server 140 (e.g., user payment history stored in payment system 144, user profiles stored by e-commerce websites), or third-party server 130 (e.g., social media data stored in social networking services). For example, attribute data corresponding to user device source 5220 may include device resource data. In some implementations, device resource data may include files (e.g., digital media or applications) stored on the device or metadata associated with files (e.g., the number of times a particular song has been played or the usage time corresponding to a particular application).

[0369] As automobiles and other forms of transportation are increasingly equipped with sensors and communication capabilities, vehicle source 5240 can provide a wealth of data. For example, attribute data corresponding to vehicle source 5240 may include acceleration data, speed data, and other sensor data (e.g., brake pad wear data, gear shift data, mileage). In this example, attribute data corresponding to vehicle source 5240 can provide indications of the user's driving mode and style (e.g., coming to a complete stop at a stop sign, speed, or careful use of the brakes).

[0370] Material sources 5250 (e.g., clothing and buildings) are increasingly acquiring the ability to capture data. In various example embodiments, attribute data may include data corresponding to material source 5250. For example, clothing may embed sensors to detect movement. Data from these sensors can provide an indication of whether a user is active or inactive. In another example, clothing may embed biometric sensors that can provide a continuous feed of biometric data corresponding to the user. Biometric data can provide indications of the user's health, mobility, and many other characteristics. Similarly, buildings may be equipped with sensors (e.g., street cameras, traffic cameras, and other sensors) that passively or actively monitor the surrounding environment.

[0371] In an example embodiment, attribute data may include data associated with a third-party source 5260. The third-party source 5260 may also provide rich data associated with the user. For example, attribute data may include data accessed from government websites or other public records that may provide criminal history, civil subpoena history, credit history, or other publicly available information.

[0372] In various embodiments, a smart home is a user's house, office, or other environment with one or more integrated smart devices. Almost every aspect of a smart home can provide data associated with the user (e.g., various data provided via smart devices acting as sensors). In some implementations, attribute data includes data corresponding to home source 5270. For example, home source 5270 may include smart appliances, consumables, utilities, and many other smart devices. In some specific instances, attribute data may include consumable inventory and consumption rates of various consumer goods (e.g., perishable foods such as milk or bread) tracked, monitored, or otherwise observed by a smart refrigerator. In another instance, attribute data may include utility usage data (e.g., electricity, water). Analysis of utility usage data can indicate user patterns or states, such as the user being on vacation, the user being sick (e.g., increasing the house thermostat setting to cope with cold), the user being an energy-conscious consumer, and so on.

[0373] Now refer to Figure 53 Example Figure 5300 depicts a non-limiting example I / O component 5310 that can provide attribute data according to some example embodiments. In the example embodiment, I / O component 5310 includes an input component 5320, an output component 5330, an environmental component 5340, a motion component 5350, a position component 5360, a biometric component 5370, a communication component 5380, a detection component 5390, and... Figure 53 A wide range of other sensors, instruments, and measurement components are not shown. I / O component 5310 or suitable combinations of I / O components 5310 may be included in any suitable device or machine (e.g., Figure 52 The attributes described herein (including the devices or machines in the source 5210) are used to facilitate the functions described herein.

[0374] I / O component 5310 can receive, detect, measure, capture, or otherwise acquire sensor data associated with physical properties, attributes, or characteristics. I / O component 5310 can provide, generate, transmit, or otherwise transfer sensor data or other indications associated with physical properties, attributes, or characteristics (e.g., sensors included in the device are operable to transmit sensor data to networking system 102). In some implementations, a combination of devices may be used to provide sensor data (e.g., a first device including a sensor and communicatively coupled to a second device, wherein the second device transmits sensor data received from the first device to networking system 102). Thus, the sensor data provided by I / O component 5310 can be accessed in real-time or near real-time by all or some of the modules described above. I / O component 5310 may be grouped according to function for the purpose of simplifying the following discussion only, and the grouping is not intended to be limiting in any way.

[0375] Input component 5320 includes alphanumeric input components (e.g., a keyboard, a touchscreen configured to receive alphanumeric input, an optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, touchpad, trackball, joystick, motion sensor, or other pointing instrument), haptic input components (e.g., a physical button, a touchscreen providing position and force for a touch or touch gesture, or other haptic input components), audio input components (e.g., a microphone), etc. In some implementations, input component 5320 receives input from a user to facilitate the functions described herein. For example, a user can use input component 5320 to interact with a user interface.

[0376] Output component 5330 includes visual components (e.g., displays such as plasma display panels (PDPs), light-emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tubes (CRTs)), acoustic components (e.g., speakers), haptic components (e.g., vibration motors), other signal generators, etc. Output component 5330 can present information to a user. For example, output component 5330 can present a user interface or a media file to a user.

[0377] Environmental component 5340 includes lighting sensors (e.g., a photometer), temperature sensors (e.g., one or more thermometers that detect ambient temperature), humidity sensors, pressure sensors (e.g., a barometer), acoustic sensors (e.g., one or more microphones that detect background noise), proximity sensors (e.g., an infrared sensor that detects nearby objects), gas sensors (e.g., a machine olfactory detection sensor, a gas detection sensor that detects the concentration of harmful gases for safety purposes, or measures pollutants in the atmosphere), and so on. Environmental component 5340 can measure various physical parameters to provide indications or signals corresponding to the physical environment surrounding environmental component 5340.

[0378] Motion component 5350 includes an accelerometer (e.g., an accelerometer), a gravity sensor, a rotation sensor (e.g., a gyroscope), etc. Motion component 5350 can provide motion data, such as velocity, acceleration, or other mechanical measurements along the x, y, and z axes. In some implementations, motion data is provided at a regular update rate or sampling rate (e.g., 10 updates per second), and the update rate and sampling rate can be configurable.

[0379] Location component 5360 includes a location sensor (e.g., a Global Positioning System (GPS) receiver component), an altitude sensor (e.g., an altimeter or a barometer that detects air pressure (from which altitude can be derived)), an orientation sensor (e.g., a magnetometer that provides the strength of a magnetic field along the x, y, and z axes), and so on. In an example embodiment, location component 5360 can provide location data such as latitude, longitude, altitude, and timestamps. Similar to motion component 5350, location component 5360 can provide motion data at a configurable rule update rate.

[0380] Biometric component 5370 includes components for functions such as detecting performance, measuring biosignals, or recognizing a person. For example, biometric component 5370 includes performance components for detecting, for example, gesture performance (also known as "kinesics") (e.g., optical components for detecting gestures or Doppler components for detecting hand movements), speech performance (e.g., a microphone for detecting pitch variations that can indicate tension), facial performance (e.g., a camera for detecting a person's performance or micro-expressions (such as smiling), body posture, and eye tracking (e.g., detecting the focus of a person's eyes or patterns of eye movement). Biometric component 5370 may also include, for example, biosignal components for measuring biosignals such as blood pressure, heart rate, body temperature, sweat, and brain waves (e.g., determined by electroencephalography). In other examples, the biometric component 5370 includes identification components for identifying a person, such as a retinal scanner (e.g., a camera component), a voice detector (e.g., a microphone that receives audio data for speech recognition), a face detector, a fingerprint detector, and an electroencephalogram (EEG) sensor (e.g., identifying a person by a unique brainwave pattern).

[0381] A wide variety of technologies can be used to implement communication. I / O component 5310 may include communication component 5380 operable to communicatively couple a machine or device. For example, communication component 5380 may include a network interface component or other suitable device that interfaces with a network (e.g., network 104). In other examples, communication component 5380 may include a wired communication component, a wireless communication component, a cellular communication component, a near field communication (NFC) component, etc. Components (e.g.) (low energy) The component, and other communication components that provide communication via other modalities. Furthermore, the communication component 5380 can be used to export various information, such as location via Internet Protocol (IP), and via... The location of signal triangulation, the location of NFC beacon signals that can be detected to indicate a specific location, and so on.

[0382] The detection component 5390 provides the functionality to detect various identifiers. For example, the detection component 5390 includes a radio frequency identification (RFID) tag reader component, a near field communication (NFC) smart tag detection component, an optical reader component (e.g., an optical sensor for detecting one-dimensional barcodes (such as Universal Product Code (UPC) barcodes), multi-dimensional barcodes (such as Quick Response (QR) codes), Aztec codes, Data Matrix, Dataglyph, MaxiCode, PDF417, SuperCode, Uniform Business Code Reduced Space Symbol (UCC RSS)-2D barcodes, and other optical codes), or an acoustic detection component (e.g., a microphone for recognizing tagged audio signals). Furthermore, various information can be derived via various communication components, such as location via Internet Protocol (IP) geolocation, etc. The location of signal triangulation, the location of NFC beacon signals that can be detected to indicate a specific location, and so on.

[0383] Figure 54 This is a block diagram 5400 of an example data structure for attribute data associated with a specific user according to an example embodiment. In the embodiment, the attribute data is associated with multiple users such as users 5402, 5404, 5406, 5408, 5410, 5412, and 5414. In the embodiment, the attribute data of a specific user is accessed by looking up a user identifier. The attribute data includes, for example, profile data 5420, device data 5422, calendar data 5424, list data 5426, list type data 5428, interest data 5430, accessory data 5432, clothing type data 5434, preference data 5436, measured size data 5438, fitness goal data 5440, reward data 5442, location data 5444, and... Figure 54 Other data not shown. In some embodiments, attribute data may be configured such that portions of the attribute data are associated with other portions of the attribute data through relationships. For example, calendar data 5424 may include calendar events associated with the event name, event data, and event location of a calendar event.

[0384] Figure 55This is a block diagram 5500 of an example data structure for data associated with a device, based on some example embodiments. In the example embodiments, Figure 54 Device data 5422 may include device identifiers, device names, device resource data (e.g., files stored on the device, such as browser logging programs (cookies), media files), I / O component data, etc. In an example embodiment, the device identifier includes, for example, an Internet Protocol (IP) address, a Media Access Control (MAC) address, other unique identifiers, an International Mobile Station Device Identifier (IMEI), or a mobile device identifier. In one embodiment, I / O component data particularly includes standard device parameters 5502, motion data 5508, environmental data 5510, and biometric data 5512. Figure 55 Only sample attribute data that can correspond to a specific device is described, and the device data may include... Figure 55 Various other data not shown. In various embodiments, standard device parameters 5502 include parameters that are standard across multiple devices included in the IoT. In some embodiments, standardized parameters and protocols facilitate access to and utilization of attribute data corresponding to such devices. For example, attribute data available on unknown devices can be accessed and utilized without needing to discover or otherwise determine which parameters are available and which units of measurement are associated with the parameters. Many other approaches can be employed to discover or otherwise determine available parameters accessible on a particular device.

[0385] Some embodiments are described herein as including logic or multiple components, modules, or mechanisms. A module can constitute a software module (e.g., code embodied on a machine-readable medium or in a transmitted signal) or a hardware module. A “hardware module” is a tangible unit capable of performing certain operations and can be physically configured or arranged. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware modules (e.g., a processor or a group of processors) of a computer system are configured by software (e.g., an application or an application portion) to operate to perform the specific operations described herein.

[0386] In some embodiments, a hardware module is implemented mechanically, electronically, or in any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic permanently configured to perform a specific operation. For example, a hardware module may be a dedicated processor, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). A hardware module may also include programmable logic or circuitry temporarily configured by software to perform a specific operation. For example, a hardware module may include software contained within a general-purpose processor or other programmable processor. It should be understood that the decision to implement a hardware module mechanically in a dedicated and permanently configured circuit or in a temporarily configured circuit (e.g., configured by software) may be based on cost and time considerations.

[0387] Therefore, the phrase "hardware module" should be understood to encompass tangible entities that are physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a particular manner or perform the specific operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Consider embodiments of temporarily configured (e.g., programmed) hardware modules, where it is not necessary to configure or instantiate each of the hardware modules at any given time. For example, if a hardware module includes a general-purpose processor configured by software as a dedicated processor, the general-purpose processor can be configured at different times as distinct dedicated processors (e.g., including different hardware modules). Thus, software can configure one or more particular processors, for example, to constitute a particular hardware module at one time and a different hardware module at another time.

[0388] Hardware modules can provide and receive information from other hardware modules. Therefore, the described hardware modules can be viewed as communication-coupled. If multiple hardware modules exist simultaneously, communication can be achieved through signal transmission between two or more hardware modules (e.g., via appropriate circuitry and buses). In embodiments where multiple hardware modules are configured or instantiated at different times, such communication between hardware modules can be achieved, for example, by storing and retrieving information in a memory structure accessible to the multiple hardware modules. For instance, one hardware module performs an operation and stores the output of that operation in a storage device communicatively coupled to it. Another hardware module can then later access the storage device to retrieve and process the stored output. Hardware modules can also initiate communication with input or output devices and are capable of operating on resources (e.g., collections of information).

[0389] The various operations of the example methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors constitute processor implementation modules that operate to perform one or more of the operations or functions described herein. As used herein, "processor implementation module" refers to a hardware module implemented using one or more processors.

[0390] Similarly, the methods described herein can be implemented at least in part by a processor, where a particular processor or processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors or modules implemented by processors. Furthermore, one or more processors can also be operable to support the execution of the operations in a “cloud computing” environment or as “Software as a Service” (SaaS). For example, at least some of the operations can be performed by a group of computers (as an example of a machine including a processor), and these operations can be accessed via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0391] The execution of certain operations can be distributed across processors, not just residing on a single machine, but rather across multiple machines. In some example embodiments, the processor or processor-implemented modules reside in a single geographic location (e.g., in a home environment, office environment, or server cluster). In other example embodiments, the processor or processor-implemented modules are distributed across multiple geographic locations.

[0392] Figure 56 This is a block diagram 5600 showing the architecture of software 5602, which can be installed on any one or more of the aforementioned devices. Figure 56 This is merely a non-limiting example of a software architecture, and it should be understood that many other architectures can be implemented to facilitate the functionality described herein. In various embodiments, software 5602 is composed of, for example... Figure 57 The hardware implementation of machine 5700 includes processor 5710, memory 5730, and I / O components 5750. In this example architecture, software 5602 can be conceptualized as a stack of layers, each providing specific functionality. For example, software 5602 includes layers such as operating system 5604, libraries 5606, frameworks 5608, and applications 5610. Operationally, according to some embodiments, application 5610 invokes application programming interface (API) calls 5612 through the software stack and receives messages 5614 in response to API calls 5612.

[0393] In various implementations, the operating system 5604 manages hardware resources and provides common services. The operating system 5604 includes, for example, a kernel 5620, services 5622, and drivers 5624. According to some embodiments, the kernel 5620 serves as an abstraction layer between hardware and other software layers. For example, the kernel 5620 specifically provides functions such as memory management, processor management (e.g., scheduling), component management, networking, and security settings. Services 5622 can provide other common services for other software layers. According to some embodiments, drivers 5624 are responsible for controlling the underlying hardware or interface with the underlying hardware. For example, drivers 5624 may include display drivers, camera drivers, etc. Drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Drivers, audio drivers, power management drivers, etc.

[0394] In some embodiments, library 5606 provides low-level public infrastructure used by application 5610. Library 5606 may include system libraries 5630 (e.g., the C standard library) that can provide functions such as memory allocation, string manipulation, and mathematical functions. Additionally, library 5606 may include API libraries 5632, such as media libraries (e.g., libraries supporting the rendering and manipulation of various media formats, such as Moving Picture Experts Group 4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer 3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codecs, Joint Picture Experts Group (JPEG or JPG) or Portable Web Graphics (PNG)), graphics libraries (e.g., the OpenGL framework for two-dimensional (2D) and three-dimensional (3D) rendering on a display in a graphics context), databases (e.g., SQLite providing various relational database functions), web libraries (e.g., WebKit providing web browsing functionality), etc. Library 5606 may also include a wide variety of other libraries 5634 to provide many other APIs to application 5610.

[0395] According to some embodiments, framework 5608 provides advanced public infrastructure that can be used by application 5610. For example, framework 5608 provides various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. Framework 5608 can provide a wide range of other APIs that can be used by application 5610, some of which may be specific to a particular operating system or platform.

[0396] In example embodiments, application 5610 includes a home application 5650, a contacts application 5652, a browser application 5654, a book reader application 5656, a location application 5658, a media application 5660, a messaging application 5662, a game application 5664, and a wide variety of other applications such as third-party application 5666. According to some embodiments, application 5610 is a program that performs functions defined in a program. Various programming languages ​​can be used to create one or more of the applications 5610 structured in various ways, such as object-oriented programming languages ​​(e.g., Objective-C, Java, or C++) or procedural programming languages ​​(e.g., C or assembly language). In a specific example, third-party application 5666 (e.g., an application developed by an entity different from the vendor of a particular platform using an Android™ or iOS™ software development kit (SDK)) can be on a mobile operating system (such as iOS™ Android) Mobile software running on a PHONE or another mobile operating system. In this example, third-party application 5666 can call API call 5612 provided by operating system 5604 to facilitate the functionality described herein.

[0397] Figure 57 This is a block diagram illustrating components of a machine 5700, according to some embodiments, capable of reading instructions from a machine-readable medium (e.g., a machine-readable storage medium) and executing any one or more of the methods discussed herein. Specifically, Figure 57A schematic representation of machine 5700, in an example form of a computer system, is shown. In machine 5700, instructions 5716 (e.g., software, programs, applications, applets, or other executable code) can be executed to cause machine 5700 to perform any or more of the methods discussed herein. In alternative embodiments, machine 5700 operates as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, machine 5700 can operate as a server machine or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Machine 5700 can be, but is not limited to, server computers, client computers, personal computers (PCs), tablet computers, laptop computers, netbooks, set-top boxes (STBs), personal digital assistants (PDAs), entertainment media systems, cellular phones, smartphones, mobile devices, wearable devices (e.g., smartwatches), smart home devices (e.g., smart appliances), other smart devices, network devices, network routers, network switches, network bridges, or any machine capable of sequentially or otherwise executing instructions 5716 specifying actions to be taken by machine 5700. Furthermore, although only a single machine 5700 is shown, the term "machine" will also be considered to include a collection of machines 5700, which individually or jointly execute instructions 5716 to perform any or more of the methods discussed herein.

[0398] In various embodiments, machine 5700 includes a processor 5710, memory 5730, and I / O components 5750 that can be configured to communicate with each other via bus 5702. In example embodiments, processor 5710 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), other processors, or any suitable combination thereof) includes, for example, processors 5712 and 5714 capable of executing instructions 5716. The term "processor" is intended to include multi-core processors that may include two or more independent processors (also referred to as "cores") capable of executing instructions simultaneously. Although Figure 57 Multiple processors are shown, but machine 5700 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0399] According to some embodiments, memory 5730 includes main memory 5732, static memory 5734, and storage cell 5736, which are accessible via bus 5702 to processor 5710. Storage cell 5736 may include machine-readable medium 5738 on which instructions 5716 embodying any one or more of the methods or functions described herein are stored. During execution of instructions by machine 5700, instructions 5716 may also reside wholly or at least partially within main memory 5732, static memory 5734, at least one of processor 5710 (e.g., within the processor's cache memory), or any suitable combination thereof. Therefore, in various embodiments, main memory 5732, static memory 5734, and processor 5710 are considered to be machine-readable medium 5738.

[0400] As used herein, the term "memory" refers to a machine-readable medium 5738 capable of temporarily or permanently storing data and can be considered to include, but is not limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, and cache memory. While machine-readable medium 5738 is shown as a single medium in the example embodiment, the term "machine-readable medium" should be considered to include a single medium or multiple media capable of storing instructions 5716 (e.g., a centralized or distributed database or associated cache and server). The term "machine-readable medium" will also be considered to include any medium or combination of media capable of storing instructions (e.g., instructions 5716) executable by a machine (e.g., machine 5700), such that when executed by one or more processors of machine 5700 (e.g., processor 5710), the instructions cause machine 5700 to perform any or more of the methods described herein. Therefore, "machine-readable medium" refers to a single storage device or apparatus, and a "cloud-based" storage system or storage network comprising multiple storage devices or apparatuses. Therefore, the term "machine-readable medium" should be understood to include, but is not limited to, one or more data storage libraries in the form of solid-state memory (e.g., flash memory), optical media, magnetic media, other non-volatile memory (e.g., erasable programmable read-only memory (EPROM)), or any suitable combination thereof. The term "machine-readable medium" specifically excludes non-legal signals themselves.

[0401] I / O component 5750 includes various components for receiving input, providing output, generating output, sending information, exchanging information, capturing measurements, etc. Generally, it should be understood that I / O component 5750 may include... Figure 57Many other components are not shown. I / O components 5750 may be grouped according to function for the purpose of simplifying the following discussion only, and the grouping is not intended to be limiting in any way. In various example embodiments, I / O components 5750 include output components 5752 and input components 5754. Output components 5752 include visual components (e.g., displays such as plasma display panels (PDPs), light-emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tubes (CRTs)), acoustic components (e.g., speakers), haptic components (e.g., vibration motors), other signal generators, etc. Input components 5754 include alphanumeric input components (e.g., keyboards, touchscreens configured to receive alphanumeric input, photoelectric keyboards, or other alphanumeric input components), point-based input components (e.g., mice, touchpads, trackballs, joysticks, motion sensors, or other pointing instruments), haptic input components (e.g., physical buttons, touchscreens or other haptic input components that provide position and force for touch or touch gestures), audio input components (e.g., microphones), etc.

[0402] In other example embodiments, I / O component 5750 particularly includes components such as biometric component 5756, motion component 5758, environmental component 5760, or position component 5762. For example, biometric component 5756 includes components for detecting performance (e.g., hand performance, facial performance, voice performance, body posture, or eye tracking), measuring biosignals (e.g., blood pressure, heart rate, body temperature, sweat, or brain waves), and recognizing a person (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or EEG-based recognition). Motion component 5758 includes accelerometer components (e.g., accelerometers), gravity sensor components, rotation sensor components (e.g., gyroscopes), etc. Environmental component 5760 includes, for example, an illuminance sensor component (e.g., a photometer), a temperature sensor component (e.g., one or more thermometers for detecting ambient temperature), a humidity sensor component, a pressure sensor component (e.g., a barometer), an acoustic sensor component (e.g., one or more microphones for detecting background noise), a proximity sensor component (e.g., an infrared sensor for detecting nearby objects), a gas sensor component (e.g., a machine olfactory detection sensor, a gas detection sensor for detecting the concentration of harmful gases for safety purposes, or measuring pollutants in the atmosphere), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment. Position component 5762 includes a position sensor component (e.g., a Global Positioning System (GPS) receiver component), an altitude sensor component (e.g., an altimeter or a barometer for detecting air pressure (from which altitude can be derived)), an orientation sensor component (e.g., a magnetometer), etc.

[0403] A wide variety of technologies can be used to implement communication. I / O component 5750 may include communication component 5764, operable to couple machine 5700 to network 5780 or device 5770 via coupling 5782 and coupling 5772, respectively. For example, communication component 5764 includes a network interface component or another suitable device interfaced with network 5780. In other examples, communication component 5764 includes wired communication components, wireless communication components, cellular communication components, near field communication (NFC) components, etc. Components (e.g.) (low energy) Components, and other communication components that provide communication via other modes. Device 5770 can be another machine or any of a variety of peripheral devices (e.g., peripheral devices coupled via Universal Serial Bus (USB)).

[0404] Furthermore, in some embodiments, the communication component 5764 detects identifiers or includes components operable to detect identifiers. For example, the communication component 5764 includes a radio frequency identification (RFID) tag reader component, an NFC smart tag detection component, an optical reader component (e.g., an optical sensor for detecting one-dimensional barcodes (such as Universal Product Code (UPC) barcodes), multi-dimensional barcodes (such as Quick Response (QR) codes, Aztec codes, data matrices, data words, MaxiCode, PDF417, SuperCode, Uniform Business Code Reduced Space Symbol (UCC RSS)-2D barcodes, and other optical codes), an acoustic detection component (e.g., a microphone for recognizing tagged audio signals), or any suitable combination thereof. Additionally, various information can be derived via the communication component 5764, such as location via Internet Protocol (IP) geolocation, etc. The location measured by signal triangulation can be detected to indicate a specific location. Or the location of NFC beacon signals, etc.

[0405] In various example embodiments, one or more portions of network 5780 may be an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), the Internet, a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a conventional telephone service (POTS) network, a cellular telephone network, a wireless network, etc. A network, another type of network, or a combination of two or more such networks. For example, network 5780 or a portion thereof may include a wireless or cellular network, and coupling 5782 may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile Communications (GSM) connection, or another type of cellular or wireless coupling. In this example, coupling 5782 can implement any of a variety of data transmission technologies, such as Single Carrier Radio Transmission (1xRTT), Evolved Data Optimized (EVDO), General Packet Radio Service (GPRS), GSM Evolution Enhanced Data Rate (EDGE), the 3rd Generation Partnership Project (3GPP) including 3G, fourth-generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA), Global Microwave Access Interoperability (WiMAX), Long Term Evolution (LTE) standards, other standards defined by various standards-setting organizations, other telematics protocols, or other data transmission technologies.

[0406] In an example embodiment, instructions 5716 are sent or received on network 5780 via a network interface device (e.g., a network interface component included in communication component 5764) using a transmission medium and utilizing any of a plurality of known transport protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, in other example embodiments, instructions 5716 are sent or received to device 5770 via coupling 5772 (e.g., peer coupling) using a transmission medium. The term “transmission medium” should be considered to include any intangible medium capable of storing, encoding, or carrying instructions 5716 for execution by machine 5700, and includes digital or analog communication signals or other intangible media used to facilitate communication of the software.

[0407] Furthermore, machine-readable medium 5738 is non-transitory (in other words, it does not possess any transient signals) because it does not embody propagating signals. However, labeling machine-readable medium 5738 as "non-transitory" should not be interpreted as meaning that the medium cannot be moved; the medium should be considered as movable from one physical location to another. Additionally, since machine-readable medium 5738 is tangible, it can be considered a machine-readable device. Carrier media include tangible machine-readable media that store machine-readable instructions and transient media (e.g., signals) that carry machine-readable instructions.

[0408] In this specification, multiple instances can implement components, operations, or structures described as singular instances. Although the individual operations of one or more methods are illustrated and described as separate operations, one or more of these operations can be performed concurrently, and not necessarily in the order shown. The structures and functionalities of components shown as separate in the example configuration can be implemented as composite structures or components. Similarly, the structures and functionalities shown as single components can be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of this subject matter.

[0409] Although an overview of the subject matter of the invention has been described with reference to specific exemplary embodiments, various modifications and changes can be made to these embodiments without departing from the broader scope of embodiments of this disclosure. These embodiments of the subject matter of the invention may be referred to herein individually or collectively by the term "invention" for convenience only and are not intended to automatically limit the scope of this application to any single disclosure or inventive concept (if more than one is disclosed).

[0410] The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to implement the teachings disclosed. Other embodiments can be derived from and based on these embodiments, allowing for structural and logical substitutions and changes without departing from the scope of this disclosure. Therefore, this “details” should not be construed as limiting, and the scope of the various embodiments is defined only by the appended claims and the full scope of their equivalents.

[0411] As used herein, the term "or" can be interpreted as inclusive or exclusive. Furthermore, multiple instances may be provided for a resource, operation, or structure described herein as a single instance. Additionally, the boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and specific operations are shown in the context of a particular illustrative configuration. Other allocations of functionality are contemplated, and these allocations may fall within the scope of various embodiments of this disclosure. Generally, structures and functions presented as separate resources in the example configuration may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within the scope of embodiments of this disclosure as represented by the appended claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. A method comprising: Detect device activities being performed by the primary user device being used by the user; Identifying a user equipment using a machine's hardware processor, the user equipment being capable of performing supplementary activities corresponding to the device's activities, the user equipment including a mobile communication device, the identification of the user equipment comprising: Based on a set of functions retrieved from a third-party server according to the type of the slave user device, it is determined that the slave user device is capable of capturing data of a specific type from the sensor that is not available on the master user device; In response to receiving biometric information of a user captured by the slave user equipment from the slave user equipment, determine whether the user is wearing the slave user equipment; In response to determining that a user is wearing the slave user device, instructions are generated for the slave user device to perform supplementary activities based on: the supplementary activities including activity components utilizing specific data types from sensors that are not available on the main user device; and Send instructions to the user equipment to perform the supplementary activities.

2. The method according to claim 1, further comprising: Access attribute data associated with the user on the primary user device; Infer user characteristics from attribute data associated with the user; Based on the inferred user characteristics and the individual user characteristics of multiple other users, similar users similar to the user are identified from among the multiple other users. as well as Based on the user characteristics of the identified similar users, the user preferences of the identified similar users are inferred to perform the supplementary activities corresponding to the device activities.

3. The method according to claim 1, further comprising: Access attribute data associated with the user on the primary user device; as well as User preferences are inferred from the user's attribute data to execute supplementary activities corresponding to the device activity.

4. The method according to claim 1, wherein, The identification of the slave user equipment is based on the device status of the slave user equipment, which indicates the device's ability to perform the supplementary activities in real time.

5. The method of claim 1, wherein the biometric information includes the user's biometric information, and wherein the slave device includes a smartwatch with a heart rate sensor, wherein the biometric information includes the user's heart rate, and wherein determining whether the user is wearing the slave device includes: When the heart rate sensor indicates no heart rate, it is determined that the user is not wearing a smartwatch.

6. The method according to claim 1, further comprising: Based on a comparison between the inferred user location and the location of the slave user device, it is determined whether the slave user device is within the operable distance for the user to perform supplementary activities. The identification of the slave user device is based on the fact that the slave user device is within the operable distance for the user to perform supplementary activities.

7. The method of claim 1, wherein the device activity performed by the primary user equipment includes browsing web pages associated with a specific location, and further includes generating a mapping direction to the specific location using the current location information provided by the user equipment.

8. The method according to claim 1, wherein, The slave user device includes a smartphone with a temperature sensor, and determining whether the user is wearing the slave user device includes: determining that the user is wearing the smartphone when the temperature indicated by the temperature sensor exceeds a specified temperature value.

9. The method according to claim 1, further comprising: The identification of the slave user equipment is based on the determination that the slave user equipment is active.

10. The method of claim 9, further comprising: Receive sensor data from the user equipment; and The activity metric from the user equipment is calculated based on the received sensor data; The identification from the user device is based on the activity metric exceeding a threshold.

11. The method according to claim 10, wherein, The threshold is based on historical values ​​of the activity metric.

12. The method according to claim 1, wherein, The supplementary activity includes a notification, which includes notification content corresponding to the device activity.

13. The method according to claim 12, wherein, The notification content includes at least one of visual content, audio content, and tactile content.

14. The method according to claim 1, further comprising: Determine the characteristics of the hardware components from the user equipment used to perform supplementary activities; as well as The characteristics of the user equipment's hardware components will be compared with characteristic thresholds; Generating instructions for performing supplementary activities from the user equipment includes: generating deletion content for the supplementary activities based on a comparison of the characteristics of the hardware components of the user equipment with characteristic thresholds.

15. The method according to claim 14, wherein, The hardware component includes the display component from the user device, and the characteristics of the hardware component include the display size of the display component.

16. The method according to claim 1, further comprising: Determine the type of the user equipment.

17. The method according to claim 1, wherein, The specific data type includes location data indicating the location from the user device.

18. The method according to claim 17, wherein, The sensor includes a Global Positioning System (GPS) component.

19. A system comprising: One or more hardware processors; as well as A memory storing a first instruction that, when executed by at least one of the one or more hardware processors, causes the system to perform an operation, the operation including: Detect device activities being performed by the primary user device being used by the user; Identifying a slave user equipment capable of performing supplementary activities corresponding to the device activities, the slave user equipment including a mobile communication device, the identification of the slave user equipment includes: Based on a set of functions retrieved from a third-party server according to the type of the slave user device, it is determined that the slave user device is capable of capturing data of a specific type from sensors that is not available on the main user device; In response to the biometric information of the user captured by the user equipment received from the user equipment, it is determined whether the user is wearing the user equipment; In response to determining that the user is wearing the slave user device, a second instruction is generated for the slave user device to perform supplementary activities based on: the supplementary activities including activity components utilizing specific data types from sensors that are not available on the main user device; and The second instruction is sent to the user equipment to perform supplementary activities.

20. A computer-readable storage medium storing first instructions that, when executed by at least one hardware processor of a machine, cause the machine to perform operations, the operations including: Detect the device activities being performed by the primary user equipment; Identifying a slave user equipment capable of performing supplementary activities corresponding to the device activities, the slave user equipment including a mobile communication device, the identification of the slave user equipment includes: Based on a set of functions retrieved from a third-party server, and based on the type of the slave user equipment, it is determined that the slave user equipment is capable of capturing data of a specific data type from sensors that is not available on the main user equipment; and In response to receiving biometric information of a user captured by the slave user equipment from the slave user equipment, determine whether the user is wearing the slave user equipment; In response to determining that a user is wearing a slave user device, a second instruction is generated for the slave user device to perform supplementary activities based on: the supplementary activities including activity components utilizing specific data types from sensors that are not available on the main user device; and Send a second instruction to the user equipment to perform supplementary activities.

Images