User content access management and control

User content access management and control are described, including determining, based on a user-defined rule, that a triggering event has occurred, wherein the user-defined rule is associated with an account that belongs to the user, and the user-defined rule comprises an action to be performed based on a triggering event; and performing the action based on the triggering event, wherein the action affects access to the account.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a non-provisional of U.S. Provisional Patent Application No. 61/664,576, filed Jun. 26, 2012, the entire contents of which are incorporated herein in their entirety by reference.

BACKGROUND

1. Technology Field

The subject matter described herein relates generally to online services and, more particularly, to user content access management and control of user information residing in computer software.

2. Background Information

Online services are becoming more prevalent. Users of very young ages to very old ages are communicating with each other using one or more online services, as well as storing information and data online (e.g., storing and backing up data, sharing images and videos, etc.).

After online services are first used, however, users do not always continue to access the services. For example, a user may abandon or stop using one image sharing site and start using another image sharing site. A user may stop using a college-focused service after graduation from college. A user may die or be incapacitated and cease accessing online services.

When users stop accessing their online services, there is a need to determine what should happen to their accounts and data stored within those services. Some users may not want their accounts and the associated data to be wiped out or deleted after, they die, for example. A user (e.g., User A) may share his or her login information (i.e., user names and passwords) with another user (e.g., User B) to manage his or her accounts and/or data in this instance. However, User A may not trust User B enough to hand over login information to all of User A's accounts (e.g., User A's image sharing account may include images not meant to be viewed by User B). User B may also turn out to be not as reliable or trustworthy as expected after gaining access to User A's accounts.

SUMMARY

One aspect of the present application may include a computer-implemented method to enable a user to control access to user information, comprising determining, based on the user-defined rule, that a triggering event has occurred, wherein the user-defined rule is associated with an account that belongs to the user, and the user-defined rule comprises an action to be performed based on the triggering event, and performing the action based on the triggering event, wherein the action affects access to the account.

Another aspect of the present application may include a computer-implemented method to enable a user to control access to user information, comprising receiving a rule from the user having access to an account that contains content of the user, wherein the rule defines a first triggering event associated with a first action and a second triggering event associated with a second action, performing the first action based on a first determination that the first triggering event has occurred, and performing the second action based on a second determination that the first triggering event and the second triggering event have occurred.

Another aspect of the present application may include a non-transitory computer readable medium having stored therein computer executable instructions for receiving a rule from a user having access to an account that contains content of the user, wherein the rule defines a first triggering event associated with a first action and a second triggering event associated with a second action, performing the first action based on a first determination that the first triggering event has occurred, and performing the second action based on a second determination that the first triggering event and the second triggering event have occurred.

Another aspect of the present application may include at least one computing device comprising storage and at least one processor configured to receive a rule from a user having access to an account that contains content of the user, wherein the rule defines a first triggering event associated with a first action and a second triggering event associated with a second action, perform the first action based on a first determination that the first triggering event has occurred, and perform the second action based on a second determination that the first triggering event and the second triggering event have occurred.

Another aspect of the present application may include a computer-implemented method to enable a user to control access to user information, comprising maintaining an account, the account being accessible by the user, and storing a user identifier in storage, performing a first determination by a processor that a difference between a current time and a recent user access time of the account exceeds a threshold value, performing a second determination by the processor that the stored user identifier matches a third-party database entry, and performing an action by the processor, based on the first determination and the second determination, the action comprising at least one of restricting access to the account and determining a status of the user.

Another aspect of the present application may include a non-transitory computer readable medium having stored therein computer executable instructions for maintaining an account, the account being accessible by a user, and storing a user identifier in a storage, performing a first determination by a processor that a difference between a current time and a recent user access time of the account exceeds a threshold value, performing a second determination by the processor that the stored user identifier matches a third-party database entry, and performing an action by the processor, based on the first determination and the second determination, the action comprising at least one of restricting access to the account and determining a status of the user.

Another aspect of the present application may include at least one computing device collectively having storage and at least one processor, comprising a first determining unit that performs a first determination that a difference between a current time and a recent user access time of an account exceeds a threshold value, the account being accessible by a user, a second determining unit that performs a second determination that a user identifier stored in the storage matches a third-party database entry, and an action unit that, based on the first determination and the second determination, performs an action comprising at least one of restricting access to the account and determining a status of the user.

DETAILED DESCRIPTION

The subject matter described herein is taught by way of example implementations. Various details have been omitted for the sake of clarity and to avoid obscuring the subject matter. Examples shown below are directed to structures and functions for implementing user content access management and control.

Service providers may detect inactive service accounts and take or perform actions on these accounts. In some example implementations, service providers may perform data hygiene and/or clean up accounts of, for example, users who are deceased.

Accounts and/or data may be shared or access given to one or more other users. For example, a mechanism may be implemented to allow User A to specify that User B is given permission and/or ownership to access User A's account and/or data under one or more conditions (e.g., User A's account has been inactive for a specified period and/or User A has died). In some example implementations, User A may define different or additional actions to be taken or performed associated with the conditions or triggering events.

In some example implementations, a mechanism may be implemented to allow User A to specify that User C is prevented from (i.e., not allowed) accessing User A's accounts and/or data under one or more conditions. User C may or may not have access to User A's accounts when the preventive action is instituted.

In some example implementations, users may be given the ability to define a set of rules to manage their accounts and/or the associated data or content (may collectively be referred to as “accounts”). For example, one or more rules may include one or more triggering events, each of which may include one or more associated actions associated with an account.

Example of actions may include, but are not limited to, account deletion, content transfer, password resets, and the like. For example, accounts may be identified for “clean up” or other actions using epitaphs or eulogies.

A user may specify a set of rules including associated triggering events and/or associated actions to indicate how the user's accounts may be managed. The rules may be specified as successive rules (i.e., applying rule 1, then rule 2, then rule 3, etc.). For example, the user can specify:Rule 1 with Condition 1: If I have not logged in for more than 3 months and/or used any of services A, B, and C:Action 1 associated with Condition 1: Email me at my alternate email address user1_at_myotheremail.com.Rule 2 with Condition 2: If a defined link in a defined email does not get clicked:Action 2 associated with Condition 2: Delete all of my documents with label LABEL1.Action 3 associated with Condition 2: Set User B as new owner for all my documents.Action 4 associated with Condition 2: Deactivate and delete my account.

With each rule, a user can specify a plurality of conditions and actions, as well as arrange order in which the conditions and actions may occur. Further, a user can also group a plurality of different conditions with a plurality of different actions. In some example implementations, a service provider or its system may suggest some common set of rules. A user may use the suggested rules as defaults and/or a starting point to customize the user-specific rules, triggering events, and/or actions.

A service provider may be any entity that stores user accounts and/or data or is likely implementing similar services. For example, cloud based service providers (e.g., providing computing and/or storage) may implement at least some of the example implementations described herein to manage service demand or allow users to control their accounts and content.

As used herein, the terms “account,” “data” associated with an account, or “content” associated with an account refer to information and data of or about the user, related to or associated with the user, generated by or for the user, and/or for communicating with or providing service to the user. An account and/or data or content associated with the account may be associated with a website, product, service, online service, or application. The term “application” includes, but is not limited to, software (e.g., a non-transitory computer readable medium having instructions executable by a processor), which is online (e.g., accessible by communication protocol and structure, such as the Internet or other communication network). The application may be embodied in the structure described below with respect toFIG. 19below.

As used herein, the term “website” or “web site” or “site” refers to a set of web pages for providing or supporting related services. A website can be hosted on at least one computing device (e.g., a system, server, web server, application server, client, or any label) accessible via a network or connection (wired and/or wireless). A website can be accessed and/or supported using at least one top-level Uniform Resource Locator (URL, e.g., “abc.gov,” “123.org,” “zxc.com,” “bestads.com,” “virtualbank.com,” and the like). A website can be operated and/or supported by one or more business entities. For example, ZXC Corporation may operate the website “zxc.com” that includes web pages, content, and/or services from “zxc.bestads.com” (e.g., advertisement services provided by another firm) and “virtualbank.com/zxc-payment-services” (e.g., financial services provided by a financial institution).

As used herein, the terms “product,” “service,” “online service,” or “application” refer to any information, communication, infrastructure, organization, or the like provided by one or more providers to at least one user. Examples of products, services, or applications may include, but are not limited to, forums, online platforms, bulletin boards, social networks, websites, sites, chat rooms, email communication, image sharing sites, data sharing platforms, video sharing sites, online searching, data storage, cloud storage, software, tax preparation and filing, online banking, online investment management, and the like. Products, services, or applications may be provided on any device ranging from a mobile device (e.g., smartphone application or “apps”), to a semi-mobile device (e.g., a laptop), and to a non-mobile device (e.g., a kiosk). A product, service, or application may communicate to a provider or another product, service, or application using a wired or wireless connection.

FIG. 1illustrates a first user interface according to an example implementation. User interface (UI)100is used to illustrate a mechanism for a user to define one or more rules; each rule may include one or more associated triggering events and/or one or more associated actions. Specifically, UI100provides a control110for activating a second user interface shown inFIGS. 2-7discussed below for defining or adjusting the individual the conditions and actions of the rule. A rule may be given a name (not shown), and a user may define one or more additional rules (not shown). Alternatively, the rule name may be defined by the service provider. In the example implementation shown inFIG. 1, the rule name112has been predefined by the service provider.

UI100also provides a display or summary of the defined conditions120and actions130,140,150. Specifically, in this implementation condition120provides that the service provider (“WXYZ”) will monitor user sign-in of the account and if a sign-in does not occur for a specified period of time (“time-out period”). Action130provides for the service provider WXYZ to notify the user if the account is not signed into during the specified timeout period. Action140provides for the service provider WXYZ to notify a different user (“trusted contacts”) if service provider WXYZ does not receive a response to the notification in Action130. Additionally, action140also provides for the transfer of account data to the trusted contact. Further, action150provides for the deletion of the account.

FIGS. 2-7illustrates a second user interface (UI)200provided for defining the conditions120and actions130,140,150of a rule defined by a user. The UI200may be accessed using the control110provided by UI100shown inFIG. 1. The like of UI200may be activated to define or revise the conditions120and actions130,140,150. UI200and the like may be used for any topic or type of user actions such as probate planning, estate planning, account planning, account and/or user information inheritance, contingency planning, other type of account management and/or control, etc. However, the example implementation is not limited thereto, and other topics or types of user actions may be substituted therefor, as would be understood by one skilled in the art.

UI200includes controls210to turn on or off the effects of the settings in UI200and an indicator212indicating whether the effects of the settings in UI200are turned on or off.FIG. 2illustrates the UI200in a turned off state.FIG. 3illustrates the UI in a turned on state. Additionally, a control to pause application of the rule to, for example, suspend the operation of the functionality of this example implementation may also be provided in some implementations. UI200displays the conditions120and actions130,140,150of the user defined rule that were shown in UI100. Additionally, UI200provides an inactivity section (“timeout period”)220, a warning section (“Notify me”)230, an action section (“Notify Others and Share Data”)240, and a final action sections (“Delete Account)250that allow for editing and defining the condition120and actions130,140,150of the defined rule. The UI200may also include a reminder control section260(not shown inFIG. 2, shown inFIGS. 3-7). Additionally, in some implementations, the UI200may also provide additional sections or controls such a save control to save the settings of UI200, and a reset control, for example.

Inactivity section220includes, for example, a control222for specifying duration (e.g., “3 Months” from last sign-in) for a triggering event. In UI200, the triggering event is implemented as being automatic based on last login by the user. However, implementations are not limited to this implementation and one or more other triggering events may be specified or used, such as receiving a notification of a change of status from a third party or a predefined code given to or created by the user for triggering purposes, etc. A change of status may include, for example, a report of death or disablement or incarceration from a government agency or from a person having a predefined relationship to the user. Additionally, UI200may also include a control for defining how an account as inactive.

Warning section230includes controls232,234to allow a user to specify one or more manners to receive a warning, including email and short message service (SMS), prior to the expiration of the duration specified by the control222. Additionally, in some implementations, a control may be provided to specify duration from the triggering event for a user to receive a warning (e.g., “2 Months” before action is taken by the service provider).

Action section240includes a control242,244for allowing a user to specify actions to be taken when the duration defined in control222from the triggering event has elapsed (e.g. “3 months” from last sign-in). Specifically, in this implementation, control242allows a user to identify contacts (known as “trusted contacts”) to be contacted and allowed to transfer or download account data specified by the user using the control242. As discussed below, the transfer or download of account data can also involve authentication of the trusted user prior to transfer of the data. Additionally, control244allows a user to prepare a reply to allow the service provider to reply to further communications received by the account. However, actions defined by a user are not limited to these example implementations. Other example actions may include, but are not limited to, sending an SMS, sending a voice message, locking an account, transferring an account, and the like. In some example implementations, the duration may be used differently. Additionally, in some implementations a control142for specifying a grace period duration (e.g., 2 Weeks), which may be implemented from when duration defined in control22from the triggering event has elapsed.

Final action section250includes a control252to allow a user to specify, for example, one or more additional actions (e.g., a “Final Action”). For example, a user may specify that his or her accounts be deleted after the triggered action specified in action section240has occurred.

The reminder section260could be provided that includes a control262to allow a user to specify that the user wants to receive remainder communications (emails, SMS messages, voicemails, etc.) regarding the settings of UI100and UI200. The reminder section could also include control264to allow a user to specify the frequency of the reminder. In some example implementations, UI100and UI200may include different, more, or less features than shown (i.e., a rule may include different, more, or less triggering events and/or actions).

FIG. 4illustrates the user interface200according to the example implementation with control242activated indicating that a contact will be identified as a trusted contact to be notified that the account is not being accessed by the user. By activating the control242, a User Interface UI300may be displayed for entry of the “trusted contact” information. UI300includes an entry field302to allow a user to enter one or more email addresses or contact names to be identified as “trusted contacts”. Additionally, UI300also includes a control304to allow a user to cancel the identification of contacts as “trusted contacts” and a control306to allow submission of the “trusted contact” information and proceed to a screen for identifying what data should be shared with the identified “trusted contact”.

FIG. 5illustrates the user interface200according to the example implementation with control242activated, a trusted contact has been identified, and document data is to be identified for transfer. After control306of UI300has been used to submit the “trusted contact” information has been submitted, User Interface UI400may be displayed for identifying what data should be shared with the identified “trusted contact”. UI400includes a plurality of controls402-422for identifying account data to be shared to the “trusted contact”. Examples of account data could include recommendations data, social media data, group's data, contact data, document data, photo data, profile data, stream data, voicemail data, and video data, or any other type of data that might be apparent to a person of ordinary skill in the art. Additionally, control424may be provided to allow a user to return to UI300and control426may be provided to allow a user to submit the selections of data.

FIG. 6illustrates the user interface200according to the example implementation with control242activated, a trusted contact has been identified, and document data has been identified for transfer. InFIG. 6at least one of the controls402-422have been selected indicating that account data is to be shared with the “trusted contact”. In some implementations, if one of the controls402-422have been used to identify account data for sharing with the trusted contact, controls428,430may be provided to allow the user to provide a verification contact, different from the contact provided in entry field302, to be used to authenticate the trusted user prior to sharing (authentication is discussed in more detail below). For example, control428may allow a user to identify a country location of the “trusted contact” and control430may allow a user to enter a contact phone number that can be used to authenticate the “trusted contact”. Other examples of verification contacts include alternative email addresses, addresses, or other contact information that would be apparent to a person of ordinary skill in the art.

FIG. 7illustrates the user interface200with an email dialog box500displayed. After control426of UI400has been used to submit the selections of data, the email dialog500is displayed to allow the user to draft the email that will be sent to the identified “trusted contact”. The email dialog500has a subject field502, email body field504, and controls506,508to be used to draft the email. Control504may be used to allow a user to return to UI400and control506to save the email to be sent at a future time. For example, the user has indicated that “John Doe” should receive an email with a title “Access my data”, and a body that is indicative that the recipient has been identified as a trusted person and the recipient is now entitled to download data. Additionally a link to access the transferred data may be provided. Additional information or actions may also be provided in some implementations.

Various aspects of the implementation have been discussed above with respect toFIGS. 1-7. However, implementations of the present application are not limited to the aspects shown inFIGS. 1-7. For example, UI400illustrates a checklist, but other equivalent interfaces as would be understood in the art may be substituted therefor, e.g., drop-down list or manual text entry field. Here, “Online Contacts” is the specified account data. Additionally, the specified person (i.e. “trusted contact”) was shown has having an account with the service provider, but the specified person (e.g., “Jane Doe”) may or may not have an account with the service provider. In some implementations, the specified person may be asked to create an account, if that is needed in an implementation, to access the specified account data.

Additionally, in some implementations the user interfaces100and200may also include includes a visual or graphical timeline. A visual or graphical timeline may show, for example, the inactivity duration, warning duration, and action duration visually. In some example implementations, a visual timeline may show other indicators (e.g., a mark may be shown for each month when a reminder email will be sent to the user). In some example implementations, the visual timeline may be a visual indicator that is shown differently (e.g., different location, size, color, etc.)

Further, in the implementation discussed above, the trigger event was a user's signing into the user's account, and the durations were measured from the user's last sign-in. However, alternative triggering events could be used. For example, a user may request a service provider to check a third-party database for the user (e.g., check a database of death certificates). This alternative may be implement by a setting or control provided in UI100or UI200that if activated cause the service provider to check a third-party database to identify the user as inactive. The service provider may check the database on demand, on a regular interval, or after the inactivity duration of, for example, six months has elapsed. If the database contains the user's name, the user's account is identified as inactive, setting off the inactive triggering event to take one or more actions defined in other parts of UI200.

Checking of the third party database may be an alternative to or in addition to monitoring the time elapsed since a previous sign-in. For example, the user may indicate that a third party database will be checked for the status of the user if there has been no log into the account for 6 months. Additionally, in some implementations, email or some other warning could be sent to the user prior to searching the third party data base or if identifying information is found in the third party database prior to an action being taken by the service provider. For example, a user may indicate that an email should be sent two weeks prior to considering an account inactive since the last previous login and checking the third-party database or an email could be sent when the identifying information is found in the third party database. Of course any of the features or aspects of the implementations may be combined as would be understood by a person of ordinary skill in the art.

FIG. 8illustrates a User Interface (UI)800that may be used to verify or authenticate the trusted contact after the triggering events discussed above have occurred and the specified duration of time has elapsed. The UI800includes a control810to proceed with the authentication or verification of the trusted contact and an indication section820explaining the authentication procedure to a trusted contact. In this implementation, the indication section820informs the trusted contact that an SMS message containing an authorization code will be sent to a phone number associated with the authenticated user and the user will be asked to type the authorization code into a user interface900discussed below. Additionally, the indication section820may also inform the trusted contact that a phone call may be used to receive the authorization code. The trusted contact has the option to ignore the authorization request and forfeit access to the shared data, or proceed with the authentication using the control810.

FIGS. 9 and 10illustrate a User Interface (UI)900that is used to authenticate trusted contact if the trusted contact chooses to proceed using the control810of UI800. The UI900includes a control910allowing the trusted contact to request an SMS message with an authorization code be sent and a control940allowing the trusted contact to request a telephone call having the code be spoken instead of the SMS message. Additionally, the UI900also includes an indication section920that informs the trusted contact that an authorization code will be sent via SMS or via a telephone call. Further, the UI900may also include an indication section930indicating the at least a portion of the telephone contact number to which the authorization code will be sent. After the trusted contact has selected one of the controls910and940to determine how the authorization code should be sent, the control910may become an indicator950(shown inFIG. 10) indicating that the authorization code is being transmitted.

FIGS. 11-13illustrate the UI900after the authorization code has been sent to the trusted contact. After the authorization code has been sent to the trusted contact, the UI900alters to include a text entry field960to allow the trusted contact to enter the sent authorization code and a control970that can be used to authorize access to the shared data. In some implementations, the control970may be greyed out or rendered unusable until a correct authorization code is entered in the text entry field960as shown inFIG. 11. Further, in some implementations, the UI900may also include an indicator980that is displayed when an incorrect authorization code is entered into the text entry field as shown inFIG. 12. Further, as shown inFIG. 13, the control970may become active when the correct authorization code has been entered into the text entry field960. The trusted contact may than use the control970to access the shared data using a User Interface (UI), such as UI1400shown inFIG. 14.

FIG. 14illustrates a UI1400used by the trusted contact to access the shared data after the trusted contact has been authorized using UI900. The UI1400includes an indicator section1410informing the trusted contact the type of data and the amount of data that has been shared, and a download section1420providing a plurality of links1430that can be used to download and access the shared data.

FIG. 15is a flowchart of an example method (process1500) according to at least one example implementation. Content (e.g., accounts and/or data) for a user is stored (operation1510). A first rule with one or more triggering conditions and one or more actions is received from the user (operation1515). For example, the user may use UI100(FIG. 1) and UI200(FIG. 2) to specify or define the rule with one or more triggering conditions and actions. A second rule with one or more triggering conditions and one or more actions may be received from the user (operation1520). In some example implementations, there may be one rule with two or more triggering conditions and/or two or more actions.

If a first triggering condition (e.g., defined in the first rule) has not occurred, at operation1525, wait for that or another triggering condition. If the first triggering condition has occurred, at operation1525, take a first action (operation1530). If a second triggering condition (e.g., defined in the second rule) has occurred, at operation1535, take a second action (operation1540). If the second triggering condition has not occurred, at operation1535, determine whether a reset action has occurred (operation1545).

A reset action is any action that has canceled or negated a triggering condition. Different triggering conditions have different reset actions. For example, a reset action to an inactive triggering condition may be an activity or active condition of an account (i.e., a login to an account resets the triggering condition of an inactive period of the account). If the answer at operation1545is no, process1500flows back to operation1535. If the answer at operation1545is yes, cancel the first action (operation1550, i.e., notifying the user (e.g., by email) that the triggering condition has been canceled). Process1500flows back to operation1525. In some examples, process1500may be implemented with different, fewer, or more operations. Process1500may be stored as instructions on a medium, loaded onto one or processors of one or more computing devices, and executed as a computer-implemented method.

FIG. 16is a flowchart of another example method (process1600) according to at least one example implementation. A rule is received from a user having access to an account that contains content of the user (operation1610). The rule, which may be defined by the user, specifies or defines a first triggering event associated with a first action and a second triggering event associated with a second action. The first action is taken based on a determination that the first triggering event has occurred (operation1620). The second action is taken based on another determination that the second triggering event has occurred (operation1630). In some examples, process1600may be implemented with different, fewer, or more operations. Process1600may be stored as instructions on a medium, loaded onto one or processors of one or more computing devices, and executed as a computer-implemented method.

FIG. 17is a flowchart of yet another example method (process1700) according to at least one example implementation. It is determined, based on a user-defined rule, that a triggering event has occurred (operation1710). The user-defined rule is associated with an account that belongs to the user, and the user-defined rule includes an action to be taken based on the triggering event. The action based on the triggering event is performed (operation1720). The action affects access to the account. For example, the account may be transferred, locked, or deleted. In some examples, process1700may be implemented with different, fewer, or more operations. Process1700may be stored as instructions on a medium, loaded onto one or processors of one or more computing devices, and executed as a computer-implemented method.

FIG. 18is another flowchart of a method (process1800) according to at least one example implementation. Information identifying the user who has access to one or more accounts is received (operation1810). The information may include user identifying information (e.g., name, address, telephone number, etc.) and user account information (e.g., a user identifier). The received information is stored (operation1815). A recent user access time for one or more of the user's accounts is determined (operation1820). A difference between the current time and the recent user access time is calculated (operation1825). For example, the user recently accessed his or her account on a date six months and one day ago. The difference between that date and the current time is determined or calculated to be six months and one day.

A comparison is made to determine whether the calculated difference exceeds a threshold (operation1830). If the answer is no, process1800flows back to operation1825. If the answer is yes, for example, the threshold is six months (e.g., the inactivity duration122specified in UI100,FIG. 1), the difference of six months and one day exceeds the threshold. The stored information identifying the user (e.g., including a user identifier) is compared with a database (operation1835). The database can be a third-party database (e.g., prison incarceration records, social security death registries, obituary databases, a death announcement database of a newspaper, government death records, etc.). If the database contains the user identifier (i.e., the stored user identifier matches an entry in the database, operation1840), then a pre-defined action is taken (operation1845).

Note that the pre-defined action is taken based on both determinations at operations1830and1840. In some example implementations, there may be a waiting period between the first and second determination or between the second determination and taking the pre-defined action. The pre-defined action may be restricting access to the user account and/or determining a status of the user or the account. The pre-defined action may be, for example, an action specified in action section240or final action section250of UI200,FIG. 2. If, however, the answer in operation1840is no, process1800flows back to operation1825. In some examples, process1800may be implemented with different, fewer, or more operations. Process1800may be stored as instructions on a medium, loaded onto one or processors of one or more computing devices, and executed as a computer-implemented method.

Example Computing Device and Environment

FIG. 19shows an example computing environment with an example computing device suitable for implementing at least one example implementation. Computing device1905in computing environment1900can include one or more processing units, cores, or processors1910, memory1915(e.g., RAM or ROM), internal storage1920(e.g., magnetic, optical, or solid state storage), and I/O interface1925, all of which can be coupled on a communication mechanism or bus1930for communicating information.

Computing device1905can be communicatively coupled to input/user interface1935and output device/interface1940. Either one or both of input/user interface1935and output device/interface1940can be a wired or wireless interface and can be detachable. Input/user interface1935may include any device, component, sensor, or interface, physical or virtual that can be used to provide input (e.g., keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, or the like). Output device/interface1940may include a display, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface1935and output device/interface1940can be embedded with or physically coupled to computing device1905(e.g., a mobile computing device with buttons or touch-screen input/user interface and an output or printing display, or a television).

Computing device1905can be communicatively coupled to external storage1945and network1950for communicating with any number of networked components, devices, and systems, including one or more computing devices of the same or different configuration. Computing device1905or any connected computing device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or by other labels.

Computing device1905can be used to implement techniques, methods, applications, processes, or computer-executable instructions to implement at least one implementation (e.g., a described implementation). Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can be originated from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).

Processor(s)1910can execute under any operating system (OS) (not shown), in a native or virtual environment. To implement a described implementation, one or more applications can be deployed that include logic unit1960, application programming interface (API) unit1965, input unit1970, output unit1975, determination unit(s)1980, rules/triggers management unit1985, action unit1990, and inter-unit communication mechanism1995for the different units to communicate with each other, with the OS, and with other applications (not shown). For example, determination unit(s)1980, rules/triggers management unit1985, action unit1990, along with one or more other units, may implement one or more processes shown inFIGS. 19-17 and 18. In some example implementations, determination unit(s)1980may include two or more separate units. The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided.

In some example implementations, when information or an execution instruction is received by API unit1965, it may be communicated to one or more other units (e.g., logic unit1960, input unit1970, output unit1975, determination unit(s)1980, rules/triggers management unit1985, action unit1990). For example, rules/triggers management unit1985may manage one or more rules, each of which may include one or more triggering events and/or associated actions. One or more rules, triggering events, and/or actions may be user defined.

Determination unit(s)1980may use API unit1965to retrieve a rule from rules/triggers management unit1985. Determination unit(s)1980may determine that a triggering event has occurred and communicate to the action unit1990. Action unit1990may use API unit1965to retrieve a rule and one or more corresponding actions from rules/triggers management unit1985. Action unit1990may then implement the one or more actions.

In some examples, logic unit1960may be configured to control the information flow among the units and direct the services provided by API unit1965, input unit1970, output unit1975, determination unit(s)1980, rules/triggers management unit1985, action unit1990in order to implement an implementation described above. For example, the flow of one or more processes or implementations may be controlled by logic unit1960alone or in conjunction with API unit1965.

Although a few example implementations have been shown and described, these example implementations are provided to convey the subject matter described herein to people who are familiar with this field. It should be understood that the subject matter described herein may be embodied in various forms without being limited to the described example implementations. The subject matter described herein can be practiced without those specifically defined or described matters or with other or different elements or matters not described. It will be appreciated by those familiar with this field that changes may be made in these example implementations without departing from the subject matter described herein as defined in the appended claims and their equivalents.