Management of remotely stored data

A service provider may assist in management of remotely stored data. The service provider may cause a user device to update remotely stored personal information, including payment information, across one or more third party electronic sites (e.g., websites, applications, and/or other remote data repositories). The service provider may build a site directory of sites that store personal data. The site directory may include information to enable update of personal information for a specific site, such as which pages to access, what data to input, what type of inputs are acceptable, and other selections and/or inputs to create, modify, update, or switch personal information maintained by a site with new or different personal information. The service provider may create a script that, when executed by an application on a user device, may cause the user device to automatically update the personal information on one or more third party sites.

BACKGROUND

The proliferation of computing systems and the Internet has resulted in massive amounts of data stored in many different remote locations. Once data, such as personal data, is made available on the Internet, it may be difficult to track that data and update the data if the data is not well managed and is stored across many different third party sites. For example, a user may provide address data to multiple different sites, such as electronic commerce sites, social network sites, and other sites. When the user moves to a new house or apartment, the user may find it difficult, time consuming, and impractical to proactively update his or her address data at all of these sites, which results in continued existence or propagation of inaccurate or expired data, such as an out-of-date address of the user being associated with the user.

DETAILED DESCRIPTION

This disclosure is generally directed to management of remotely stored data. In some embodiments, a service provide may assist a user in updating remotely stored personal information, including payment information, across one or more third party electronic sites (e.g., websites, applications, and/or other remote data repositories). The service provider may build a site directory of sites that store personal data. The site directory may include information to enable update of personal information for a specific site, such as which pages to access, what data to input, what type of inputs are acceptable, and other selections and/or inputs to create, modify, update, or switch personal information maintained by a site with new or different personal information. The personal information may include payment information (e.g., credit card numbers, bank account numbers, and/or other payment information), address information, contact information (e.g., emails, phone numbers, and/or other communication data), and/or other personal information.

The service provider may create a script that, when executed by an application on a user device, may cause the user device to automatically update the personal information on one or more third party sites. By creating a script for the user device, the script may better mimic normal user input while leveraging user data stored on the user device (e.g., cookies, saved usernames/passwords, etc.). The service provider may perform rigorous testing of the script prior to deployment of the script to the user device. In various embodiments, the script may be robust to accommodate for different versions of sites operated by a third party or different presentations of the site, such as interaction with a mobile version of a site, a specific language of the site (e.g., German version versus English version, etc.), different browser settings, and so forth. Once the script is successfully tested, it may be deployed to user device, possibly in response to requests from user devices to use the script.

The service provider may occasionally or continually update site information in response to detected changes to sites. For example the service provider may actively analyze or crawl sites to determine changes to the sites. The service provider may also collect error reports from user devices to identify changes to sites. However, some errors may result from interruptions in connectivity of a user device or other temporary faults, and may not be associated with changes to a site. The service provider may distinguish between temporary errors, which may be remedied by retrying to execute the script at a later time, and errors resulting from changes to a site. In the latter situation, the service provider may create a new script to facilitate interaction with a newest version of the site.

In some embodiments, the script may be used to switch or update payment information, such as credit card information or other bank information. For example, a user may decide to update a default payment instrument, such as a credit card, across one or more remotely stored accounts that are maintained by third party sites (e.g., electronic commerce sites, bill pay services, etc.). The update may change information associated with the card (e.g., a new expiration data, card number, etc.), or the update may replace a first payment instrument with a second, different payment instrument. For example, the user may desire to use a new credit card for some or all of his or her online accounts, such as favorite electronic commerce sites that store payment information for the user.

Providers and/or servicers of the payment instruments may greatly benefit by having their payment instruments quickly updated across multiple sites, since this may increase use of those payment instruments on the sites. For example, when a user loses a credit card, reports fraudulent activity, or otherwise cancels the credit card, it may take multiple days or weeks to receive a new credit card and then update sites that store this card as a default payment instrument. During this time, the user may not make purchases using the card since the card is unavailable for use (e.g., has not arrived yet and/or been inputted to sites). However, using the techniques herein, information for a replacement credit card may be updated at sites as soon as the information is available from the credit card provider or servicer, which may be electronically provided to the user for use via the techniques provided here, possibly before receipt of a new physical card. Thus, banks and other services providers may greatly benefit by enabling updates of payment information across sites to maintain use of a payment instrument during or after issuance of a new payment instrument.

The user device may include an application that presents one or more user interfaces (UIs) to facilitate interaction with the scripts and with one or more sites. UIs may enable the user to selectively determine which sites are associated with specific types of data, such as payment instruments, addresses, communication addresses (e.g., phone numbers, emails, etc.), and so forth. The UIs may enable the user to manage these data and selectively update the data by execution of scripts obtained by the service provider.

FIG. 1is a schematic diagram of an illustrative computing environment100that includes a service provider102that assists a user103associated with a user device104in managing remotely stored data located at one or more third party sites106(“sites”). The service provider102may access the sites106and the user device104via one or more network(s)108, which may include wired or wireless networks used to access the Internet and/or other local or wide networks. The user devices may include mobile telephones, notebook computers, tablets, desktop computers, wearable devices and/or other devices used to interact with the sites106.

The service provider102may include a site analyzer110, which may include instructions to cause inspection and analysis of the sites106. The site analyzer110may collect site data112, such as site data112(1)-112(N), which may include data for each site that is analyzed. To collect the site data112, the site analyzer110may send requests114to sites and receive page data116in response to the requests114. The site analyzer110may inspect the page data116to determine inputs associated with different portions of a site (e.g., pages, tabs, etc.) and functions of those inputs. For example, a site may have multiple fields that enable input of a username. Some of these fields may be associated with a login while others may be used to update a user name, retrieve a password, and/or perform another action. Thus, the site analyzer110may capture and analyze information provided by the site and/or other associated information (e.g., external references/links, and/or other associated data) to determine an intent or function of a data input field. The term input field is used to represent any type of input field including selectors (e.g., drop down lists, radial buttons, etc.), text input, biometric input, and/or other types of input data.

In some embodiments, the site analyzer110may use credentials to access privileged locations within a site, such as user data fields that may not be accessed without input of credentials (e.g., username/password, etc.). The site analyzer110may also access sites using different perspectives, as discussed below with reference toFIG. 5, to determine variations of site data served to different user devices. Perspectives may include access of a site having different language versions, mobile/native versions, browser variations, paid/free versions, and so forth. Additional details about the site analyzer110are provided below.

The service provider102may have access to user data118, which may include payment data120and/or other data122, such as address or contact information including phone numbers, emails, etc. The payment data may include information to enable use of a payment instrument, such as credit card numbers, expiration dates, bank account numbers, and/or other payment information. In some embodiments, some or all of the user data118may be stored on the user device104. However, the user data118may be stored or at least accessible by the service provider102in some embodiments.

The service provider102may include a script generator124that generates scripts to perform specific functions on behalf of the user and that are associated with one or more of the sites. For example, the script generator124may generate a script that updates or switches default payment information stored by a site with little or no user action. The script may be generated based on the site data112collected and generated by the site analyzer110. The script may be used to cause the user device to interact with a site, and thus may be executed by the user device. In some embodiments, the user device104may sent a request126for a script. The service provider102may then transmit a script128to the user device104. The script128may include one or more rules that may be dynamically implemented to cause the user device to perform specific operations with a site, such as input credentials, update data, and/or perform other functions. The rules may enable the script to interact with different variations of data provided by a site, such as data provided to a mobile device (i.e., mobile version of a site), data in a particular language (e.g., German, French, English, etc.), and so forth. Additional details about the script generator124are provided below.

As discussed above, the user device104may execute the scripts received from the service provider104. By executing the scripts on the user device104, the user may more fully control execution of the scripts and control use of the user's personal data, especially when the user data is stored, at least in part, on the user device104. Further, execution of the script by the user device104may minimize errors or connectivity problems caused by security features of some sites, which may fingerprint a user device approved to access the site, etc. The user device104may send a script130, which may be modified by the user device104after receipt from the service provider, to a site. For example, the modification may be to input personal information that is stored on the user device into the script. The site may then send a result132to the user device in response to execution of the script130. For example, when the script is used to update persona data, the result132may be a confirmation page that the data has been successfully updated. In some embodiments, the user device104may forward or send information pertaining to the result to the service provider102for collection by an event logger, as further explained below. The user device104may include an application that presents one or more user interfaces134that enable the user103to interact with the service provider, manage information, cause updates of information (via the scripts), and/or perform other functions discussed herein. Some examples of possible user interfaces are provided inFIGS. 8-14.

FIG. 2Ais a block diagram of an illustrative computing architecture200of the service provide102shown inFIG. 1. The computing architecture200may be implemented in a distributed or non-distributed computing environment.

The computing architecture200may include one or more processors202and one or more computer readable media204that stores various modules, applications, programs, or other data. The computer-readable media204may include instructions that, when executed by the one or more processors202, cause the processors to perform the operations described herein for the service provider102.

In some embodiments, the computer-readable media204may store the site analyzer110, the script generator124, a site action verifier206, an event logger208, and a user data manager210, which are described in turn. In addition the computing architecture200may include the site data112and possibly at least some of the user data118. The site data112and/or the user data118may be input and/or updated by the user device104via interaction with UI discussed below with reference toFIGS. 8-14. The components may be stored together or in a distributed arrangement.

The site analyzer110may access various data provided from a site, such as pages and other content, including input forms. For example, the site analyzer110may crawl all pages provided by a site, such as a host uniform resource located (e.g., www.website.com). The site analyzer110may determine input fields and assign a purpose to respective input fields. For example, the site analyzer110may determine that a first email input field is used to subscribe to a newsletter while a second email input field is used to confirm a user identity. The site analyzer110may determine a purpose of an input field based on sematic analysis of information on a page or proximate to the input field, links associated with the page, spatial information in the page (e.g., tree distance describing how many hops to traverse the tree, a pixel distance, etc.) between different input fields, and/or other information. In some embodiments, the site analyzer110may seek to identify certain features of a site and thus not analyze the entire site. For example, the site analyzer110may determine how to access a portion of the site used to set or change a default payment instrument, which may be an intended goal of an operation performed by the service provider, for example. Once this part of the site is identified and analyzed, other remaining portions of the site may not be analyzed. The site analyzer110may populate the site data112with data for many sites, and possibly for different versions of a same site.

The script generator124may use the site data112to create scripts that cause a user device to perform certain predetermined functions with little or no user input. For example, the scripts may cause a user device to update a default payment type, update an address, and/or input other information to a site (e.g., credentials, personal data, etc.). An example of minimal user input is the user having to manually read and input a CAPTCHA or other security question. The script generator124may create scripts that function with different versions of the site and/or after some changes to the site, such that the scripts may include rules to enable dynamic decision making during interaction with the site. This may enable successful interaction with a site despite access to the site using a particular perspective (e.g., language, browser type, device type, Internet Protocol (IP) address, etc.). For example, dynamic rules may be implemented by the script to inspect a page retrieved by a user device and then take certain predetermined actions based on the data included in the retrieved page. Thus, the scripts may be robust to enable navigation and input of data to various different versions of a site (e.g., different language, different presentations, and so forth).

The site action verifier206may verify proper functionality of scripts before the scripts are issued to the user device or in response to other triggers, such as reported errors associated with scripts. In some embodiments, the site action verifier206may be emulated or executed on different devices, such as mobile devices, notebook computers, tablet computers, and/or other devices to mimic use by a user device. The site action verifier206may output results, which may trigger human inspection and/or updates by the script generator124when the script does not function as anticipated or as desired (i.e., the script does not complete an intended task).

The event logger208may capture data from the user devices in response to interaction with the scripts and/or other interactions with the sites106. For example, when a user device executes a script that unsuccessfully performs an operation, the user device may send an entry to the event logger208to record the failure event. The event logger208may also record successful execution of scripts, which may be helpful to determine that an error is local or temporal, and not experienced by at least some other devices, for example.

The user data manager210may enable input and/or control of at least some of the user data118that may be stored and/or accessible by the service provider102. For example, when at least some of the user data118is stored in the computing architecture200, the user data manager210may enable a user to input user data, modify user data, delete user data, and/or perform other functions with the user data. The user data may include personal information, payment information, contact information, site information (e.g., credentials such as username/password, preferences, etc.), and/or other user data.

Additional functionality of the components of the service provider102are discussed with reference to the flow diagrams shown inFIGS. 3-7and the following discussion included below.

FIG. 2Bis a block diagram of an illustrative computing architecture220of the user device shown inFIG. 1.

The computing architecture220may include one or more processors222and one or more computer readable media224that stores various modules, applications, programs, or other data. The computer-readable media224may include instructions that, when executed by the one or more processors222, cause the processors to perform the operations described herein for the user device104.

In some embodiments, the computer-readable media224may store a browser226, a script module228, and an interface module230, which are described in turn. The computing architecture220may also include at least some of the user data118, which may be stored in the computer-readable media224and/or in other memory.

The browser226may be a conventional web browser or other application that is configured to enable an exchange of data with the sites106. In some embodiments, the browser226may be a specialized application used to access a specific content provider. However, the browser226may typically be implemented as a general purpose application that can read hypertext markup language (HTML) documents and other documents and languages commonly associated with data available by way of the Internet. The browser226may include one or more plug-ins and/or toolbars that enable at least some of the functionality discussed herein.

The script module228may enable execution of a script provided by the service provider102. The script module228may operate to cause the browser226or another resource or application to perform certain predetermined functions with little or no user interaction. Scripts may be requested and caused to execute via use of the UIs described below with reference toFIGS. 8-14and possibly using other triggers. Thus, the script module228may execute the script on the user device104, possibly as a plug-in or toolbar associated with the browser226. In some embodiments, the script module228may update the script with at least some of the user data118, such as to add payment information, cookies, user credential, etc. to a script that causes an update of the information at one of the sites106. However, the user information may already be included in the script in some instances when the information is available to the script generator124(e.g., when the user data118is available by the service provider102). The script module228may receive the scripts form the service provider102and/or may transmit event log information back to the service provider102in response to execution of a script, such as to report an error event, report a successful event, and/or report other information such as a change in a site or other site data.

The interface module230may enable user interaction with one or more of the user interfaces134, such as the UIs shown inFIGS. 8-14. The interface module230may operate with the browser226and/or independent from the browser226to enable management, creation, and update of the site data112, the user data118, execution of scripts, and other functions discussed herein. The interface module230may link the UIs to implement functionality of the script module228.

Additional functionality of the components described above with reference toFIGS. 2A and 2Bis discussed with reference to various flow diagrams shown inFIGS. 3-7and described below.

FIG. 3is a flow diagram of an illustrative process300to create a script for use by a user device to update remotely stored data. The process300is described with reference to the environment100and may be performed by the service provider102. Of course, the process300may be performed in other similar and/or different environments.

At302, the site analyzer110may analyze a site to determine content and/or input fields available via the site. For example, the site analyzer110may access various pages of a site to create a site directory. The site analyzer110may determine functionality associated with different pages or portions of content provided by the site, such as input fields used to login, update account information, input a default payment instrument, update user information, update preferences, and so forth. For example, the site analyzer110may perform a spatial analysis and/or a semantic analysis of pages to determine a purpose of the respective pages and/or purpose of input fields on the pages. In some embodiments, the site analyzer may analyze a site for a specific function while refraining from storing data for other parts of the site. However, the site analyzer110may determine exhaustive data for a site. The analysis may be used to create the site data112. The site analyzer110may view the site from different perspectives to capture differences in the site based on language, browser type, device type, free/paid versions, and so forth.

At304, the script generator124may generate a script to perform a specific function while interacting with a site. The specific function may be as simple as logging into a site (e.g., proving credentials to access privileged portions of the site like a user account, etc.) or as complex as replacing a default payment instrument with a new default payment instrument. The functions may include navigation within a site, population of input fields (and submission of data), among other possible tasks. The script may be created by the service provider102and then sent to the user device104for execution. The script may perform functions with little or no human interaction, such as update a default payment instrument stored at the site, provide login credentials to access portions of the site and/or perform other functions. The script generator124may use the site data112to create a robust script that includes dynamic rules that function despite variance of the site across caused by different perspectives used to access the site (e.g., different locations, languages, devices, account types, etc.). Thus, the script generator124may generate a script that includes rules that cause functionality in response to identified content retrieved during a current interaction with the user device when executing the script.

At306, the site action verifier206may test the script. The site action verifier206may be executed by different types of devices, different browsers, in different languages, different account types, in different regions/countries, and/or using other differences to change perspectives, which may enable identification of any failures of the script. The site action verifier206may preform repeat testing to ensure that scripts operate as expected. The testing may be performed prior to shipment of any script, or over time and after some shipments to ensure continued compatibility and functionality.

At308, the service provider102may send the script to the user device104, possibly in response to a request, to enable the user device104to execute the script. The user device104may execute the script using a script module228, which may cause a browser or other application to perform specific tasks on behalf of a user. The script may include at least some information in the user data118, which may be inputted into the script by the script generator124at the service provider102and/or input by the script module228at the user device104.

FIG. 4is a flow diagram of an illustrative process400to generate and use a script to cause a user device to update remotely stored data at a site. The process400is described with reference to the environment100. Of course, the process400may be performed in other similar and/or different environments. As shown inFIG. 4, the service provider102, the site106(1), and the user device104may exchange information through one or more networks such as the networks108. However, other devices and other configurations may be used to implement the process400.

At402, the service provider402may deploy the site analyzer110to exchange data with the site106(1), and possibly other associated sites, to determine site data. The site106(1) may provide information at404, which may include input fields, text, images, pages, and/or other static or dynamic content for analysis by the site analyzer110.

At406, the script generator124may build a script to perform a specific function. The script generator124may build the script based on the site data112.

At408, the site action verifier206may test the script using a validation test or tests to verify that the script successfully performs an intended function. The testing may be performed on a variety of devices, possibly under control of the service provider102or under direction of the service provider102. In some embodiments, the testing may be an iterative processes, such that when a script fails a validation test, the script is recreated, such as by reverting to a prior operation in the process400and possibly with assistance via human inspection. Thus, the process400may include one or more loops based on the operation408when the script does not perform as intended.

At410, the user device104may receive updated user data, which a user associated with the user device104may desire to pass or extend (write) to the site106(1) and possibly to other sites. The user data may include an update to a payment instrument or a new payment instrument, a change in personal information and/or communication information, and/or other user data.

At412, the user device104may request a script to perform a specific function. As an example, the specific function may be switching, at a site, a default payment instrument from a first payment instrument to a second payment instrument. The user of the user device104may desire to do this in response to updating an expired payment instrument, fraudulent activity (stolen card, etc.), obtaining a payment instrument with better benefits, and/or for other reasons. The user may use the interface module230, via the user device104, to initiate the function and request for the script. The request may be received at414by the service provider102, which then in turn may send the corresponding script at416. In some embodiments, the script may be updated to include at least some of the user data118, possibly inputted from the operation410. The user data may be input into the script by the service provider102, by the user device104, or by both, depending on a storage location of the user data and specific configurations or user preferences. For example user credentials may be input locally on the user device104while payment information may be input remotely by the service provider102. The script may be received by the user device104at418.

At420, the user device104may implement the script via the script module228. The script may cause the user device104to exchange data with the site106(1) and process data at422. Execution of the script may result in multiple exchanges of data between the site106(1) and the user device104in some instances, such as when multiple operations are performed (e.g., credentials, navigate pages, update payment information, etc.). Following at least some actions and the processing of data at422, the site106(1) may determine whether an error has occurred at424. The error may be a result recognized by the site106(1), but that is different from an intended result. Thus, the error may be proper receipt of an unintended outcome (e.g., acceptance of a null field, etc.). When no error occurs (following the “no” route from the decision operation424), the process400advances to the operation426where the update is confirmed and a confirmation is sent to the user device104for receipt at428. When an error occurs (following the “yes” route from the decision operation424), the process400advances to the operation430where the error is generated and communicated to the user device104for receipt at432. Following either the operation428or the operation432, the script module228may generate a reporting event at434for communication to the event logger208of the service provider102for receipt at436. Thus the event logger208may log data for successful and unsuccessful events associated with use of the script.

FIG. 5is a flow diagram of an illustrative process500to analyze sites using different perspectives that relate to variations in device configurations employed by different user devices. The process500is described with reference to the environment100and may be performed by the service provider102. Of course, the process500may be performed in other similar and/or different environments.

As discussed herein, a “perspective” is used to describe variations of data received or displayed by a user device based on how the site is accessed. The perspective may change based on a browser or application used to access the site, a language of the site (e.g., German, French, English, etc.), an IP address used to access the site, a location of the user device, a display size or other attributes of the user device104, a paid state or unpaid state of the site access, and/or other factors which may result in differences in the received data from the site or the display of the site at the user device104. These differences are accounted for by the script, possibly via dynamic rules, to enable the script to cause the user device to perform an intended action.

At502, the site analyzer110may analyze a site using a selected perspective. The perspective may be implemented by emulating a particular attribute, parameter, etc. that defines the perspective. For example, the site analyzer110may analyze a mobile version of a site, a German version of the site (e.g., www.website.de) which may be a redirected site based on a location of an accessing device, and so forth. As another example, the credentials used to access the site may be credentials associated with a free version or standard version of the site.

At504, the site analyzer110may determine site input fields and/or other site data associated with the selected perspective. The operation504may be performed as described above for the operation302, but in association with the selected perspective. The site data112may be associated with the perspective.

At506, the site analyzer110may analyze input fields to determine a purpose of the input fields, such as using spatial and/or semantic information provided by the site. For example, the site analyzer110may determine a purpose of an input field based on sematic analysis of information on a page or proximate to the input field, links associated with the page, spatial information in the page (e.g., tree distance describing how many hops to traverse the tree, a pixel distance, etc.) between different input fields, and/or other information.

At508, the site analyzer110may determine parameters for input of the information in the input fields. For example, the site analyzer110may determine one or more formats that are accepted by the input field, how to modify the input field (e.g., select pull down option, input text, select button, move slider, etc.), and/or other parameters associated with input fields.

At510, the site analyzer110may determine whether to access the site using a different perspective to further populate the site data112. For example, the site analyzer110may determine to access a premium or paid version of the site, which may include additional functionality and/or input fields. When the site analyzer110determines to implement another perspective (following the “yes” route from the decision operation510), then the process500may advance to an operation512to implement the perspective and return to execute the operations502through508. When the site analyzer110determines not to implement another perspective (following the “no” route from the decision operation510), then the process500may advance to an operation514.

At514, the site analyzer110may store collected data from the operations502through508as the site data112, which may include an association with the perspective. For example, the site data112may indicate if the data is included in a standard version of the site, a premium version of the site, or both. As another example, the site data112may indicate variations based on language, access location (e.g., location of the user device104accessing the site), different browsers, different devices types (e.g., large screen versus small screen, slow processor versus fast processor, etc.), and so forth.

At516, the script generator516may create a script that operates for one or more of the perspectives. For example, the script generator516may create a robust rule set within the script that allows the script to successfully perform a specified function on the site despite the perspective of the site obtained by the user device that execute the script. In some embodiments, the script generator124may generate different scripts for a site, which some scripts only work with certain perspectives (e.g., on a mobile version of the site, etc.). In these embodiments, the service provider102may determine a perspective of a user device prior to sending the script to the user device104for execution.

The perspectives may be obtained using different techniques, such as by collection of information by the event logger208from errors experience by user devices having different perspectives. Thus, the perspectives, and corresponding attributes, parameters, etc., may be discovered by reporting to the event logger, which may then initiate inspection of the site via the particular perspective. The perspectives may also be determined by using different test devices to access sites, such as tablet devices, mobile phones, desktop computers, and so forth, possibly using different browsers, located in different regions, and so forth.

FIG. 6Ais a flow diagram of an illustrative process600of a user device to process errors associated with a script used to update remotely stored data. The process600is described with reference to the environment100and may be performed by the user device104. Of course, the process600may be performed in other similar and/or different environments.

At602, the script module228may run or execute a script602. The operation602may be similar to the operation420described above with reference toFIG. 4. The script module228may cause the browser to perform actions in accordance with the script, which may or may not be visible to the user. For example, the script module228may cause the browser to perform background actions or tasks in accordance with the script. The background actions or tasks may not be readily visible to the user, and thus may allow the user to perform other tasks during execution of the script.

At604, the script module228may determine whether execution of the script has resulted in an error. The error may be determined by a prompt or reply received by a site that is modified by the script. For example, the error may be detected when an input form is represented during execution of the script following entry of information into the input form. As another example, an error may be determined in response to analyzing a confirmation of inputted information and determining the confirmed input is not the same an intended input. Other errors may occur due to connectivity, timeouts, or other data processing or communication errors. Regardless of the technique, the decision process604may determine whether an error has occurred. When an error has occurred (following the “yes” route from the decision operation604), then the process600may advance to an operation606.

At606, the script module228may send an error event to the event logger208of the service provider102. The event logger208may track occurrences of errors to determine whether an error is localized (e.g., device specific, regional, etc.) or global (e.g., affects most or all devices). In some embodiments, the event logger208may provide a reply to the message at606to instruct the user device (and script) to retry the script, such as when the error appears to be a local error or error that may be remedied by retrying the script or part of the script.

At608, the script module228may determine whether to retry to perform an action using the script. As discussed above, some errors may be remedied by retrying an action with or without a delay due to errors that are temporary (e.g., dropped data, lost connectivity, etc.). For example, a connection error may be remedied by regaining connectivity and preforming an action caused by the script. Other errors may not be remedied, such as errors resulting from changes to content or input fields served by the site. The script module228may determine to retry an action based on information from the event logger208and/or from local information from the script module228. When the script module228determines to retry an operation (following the “yes” route from the decision operation608), then the process600may advance to an operation610. At610, the script module228will undergo a delay and then advance to the operation602to run the script or continue the script. The length of the delay may be based on a type of error. For example, a connection error may require a longer delay (used to reestablish connection) than another type of error. The delay may be based on factors other than time, such as location, reconnection, etc.

When the script module228determines not to retry an operation (following the “no” route from the decision operation608), then the process600may advance to an operation612. At612, the script module228may receive a new script that may be used to remedy the error determined in the process600. For example, the new script may be recently generated by the script generator124in response to reporting of the error at the operation606. In some embodiments, the new script may be an update to an existing script. However, the new script may be an entirely new script.

At614, the script module614may run the new script and/or run a portion of the script (e.g., an updated portion that remedies the error). In some embodiments, the operation614may lead to the decision604described above, which determines whether an error has occurred using the script. For simplicity of explanation, the process600continues at an operation616.

At616, following the operation614or when no error has occurred following the “no” route from the decision operation604, the script module228may receive confirmation of a successful performance of the script, such as by a confirmation page that indicates an intended result or by other information received by the script module228from the site.

FIG. 6Bis a flow diagram of an illustrative process620of a service provider to process errors associated with a script used to update remotely stored data. The process620is described with reference to the environment100and may be performed by the service provider102. Of course, the process620may be performed in other similar and/or different environments. The process620may occur in response to the operation606described above with reference toFIG. 6A.

At622, the event logger208may receive error event from the script module228of the user device104. The event logger208may log the event, such as by recording an occurrence of the event along with other events received from other user devices or sources.

At624, the event logger208may determine whether the event from the user device104has reached or exceeded a threshold. The threshold may determine that the event requires human inspection at626. As an example, when the same device reports the error more than once (or another threshold value) within a certain amount of time (possibly a threshold value), then the request may be routed to a human at626for inspection and resolution. This may expedite a remedy of the error. When the event has not reached or exceeded the threshold (following the “no” route from the decision operation624), then the process620may advance to an operation628.

At628, the event logger208may determine whether to instruct the user device104to retry to existing script. If the error has not been reported before and is a first time error for the device, then the determination may be to cause the user device104to retry to script at630. For example, the error may be caused by a connection interruption between the user device104and the script106or other “local” error. However, if the error has been logged before and is determined to be associated with a change in the site or other “global” error, then the event logger208may determine to proceed to the operation632.

At632, the site analyzer110may analyze the site and/or other data sources to determine whether changes have been made to the site since a prior analysis of the site and/or whether other data sources have changes. Other data sources may include rules sets used to create, maintain, and execute scripts, changes to user devices and/or configuration of user devices (e.g., change of software, corrupt files or application, etc.), and so forth. In some embodiments, the analysis at632may be directed to a portion of the site related to the error since some sites updates some pages of their sites without updating the entire site. In various embodiments, the site analyzer110may compare a prior fingerprint of the site (and/or other data) to a new fingerprint of the site (and/or other data) to determine whether the site (and/or other data) has been updated and possibly to determine an extent of an update of the site (and/or other data).

At634, the site analyzer110may determine whether changes to the site are present where the changes caused the script to fail. When changes are present (following the “yes” route from the decision operation634), then the process620may continue at an operation636.

At636, the script generator may create a new script or update a portion of an existing script (which is also referred to herein as a “new script”). The new script may be generated as discussed above for the operation304described with reference toFIG. 3. However, the new script may only include an update to portions of the script that access parts of a site that have changed based on the analysis performed at632.

At638, following the operation636or when no changes are present (following the “no” route from the decision operation634), the script generator124may test the script (or the new script) to verify proper functionality. The test may include a test from a perspective that is the same or similar to a perspective of the user device104that reported the error. The test may be the same or similar to the operation306discussed above with reference toFIG. 3.

At640, the script generator124may determine whether the script (or new script) passed the test at the operation638. When the script passed the test and was performed successfully (following the “yes” route from the decision operation640), then the process620may advance to an operation642. At642, the service provider102may send the script to the user device, which may be received via the operation612of the process600described with reference toFIG. 6A. When the script fails the test and was not performed successfully (following the “no” route from the decision operation640), then the process620may advance to the operation626for human inspection. The human inspection may create a task for an analyst to manually resolve the error.

FIG. 7is a flow diagram of an illustrative process700to capture event data and update scripts based on the event data. The process700is described with reference to the environment100and may be performed by the service provider102. Of course, the process700may be performed in other similar and/or different environments. Some operations of the event logger208are discussed above with reference toFIGS. 6A and 6B. The event logger208may perform events in response to other triggers beyond receipt of errors.

At702, the event logger208may receive an event to log or otherwise record or store. The event may be logged in a database and categorized with one or more descriptors that attributes of the event. In some embodiments, the event logger may store event information in the site data112. The attributes may include information associated with a user device that reported the event, such as a perspective, location, and/or other user device information. The attributes may indicate an outcome of the event (e.g., success, error, retry, etc.). In some embodiments, the event may be access of an input field not currently supported by a script or other “new” information that may be used to cause an update to the script or cause a new analysis of the site.

At704, the event logger208may analyze the logged events. The analysis may identify sites or portions of sites that may require an update or a more thorough analysis by the site analyzer110. In some embodiments, the analysis may identify changes to sites based on new input fields accessed by user, trends in errors or retry events, and/or other actions that may trigger an update to a site or an analysis of a site by the site analyzer110.

At706, the event logger may select a site to update. The update may be a full update, which may be performed as if the site were new, or may be a partial update, which may use some existing information about the site from a previous analysis of the site.

At708, the site analyzer110may analyze the site for changes. The analysis may be similar to the operation302described with reference toFIG. 7. The analysis may target portions of the site based on information provided by the event logger110, such as new features of the site, portions of the site prone to errors, and/or other portions of the site. In some embodiments, the site analyzer110may obtain a fingerprint of the site, which may sample portions of the site, and compare the fingerprint to a prior fingerprint to determine changes in the site, for example.

At710, the site analyzer may determine whether changes are present on the site based on the analysis at the operation708. When changes are present (following the “yes” route from the decision operation710), then the process700may advance to an operation712to update the site data112. The script generator124may then use the updated site data to create a new script. When changes are no present (following the “no” route from the decision operation710), or following the operation712, the process700may advance to the operation702and continue to log events.

FIGS. 8-14show example user interfaces (UIs) which enable management of payment information and updating payment information, such as payment instruments, using the techniques and systems described above. The techniques and systems described above are not, however, limited to the following specific use-cases. Thus, the techniques and systems described above may be used to perform tasks other than switching or updating payment instruments stored at various sites and/or accessing payment information. The UIs that follow show general features that may cause execution of computing instructions by the script module228, possibly via the interface module230. The scripts are generated by the script generator124as discussed above. The UIs may be accessible via the browser226and/or via other application(s).

FIG. 8shows a UI800that includes a payment management interface to enable at least switching default payment instruments stored remotely at different sites. The UI800includes payment instruments802, which may be credit cards, checking accounts, savings accounts, virtual currency, credits, points, and/or any other redeemable value. Payment instruments may be represented with an icon804and/or a text description806. The icon804may indicate a type, servicer, or provider of the payment instrument, such as Visa®, MasterCard®, PayPal®, Bank, and so forth. An update control808may enable updating the payment type using another UI described below. A “switch payments” control810may enable switching payments for sites, which may be facilitated using yet another UI described below. An “add payment” control812may facilitate adding a new payment instrument, which may be facilitated using still another UI described below.

FIG. 9shows an illustrative UI900that includes a detail interface that shows remote storage of a payment instrument and enables adding additional sites for the payment instrument. The UI900may include a payment instrument902, which may be depicted with the icon804and the textual description806. A login control904may cause a script, created by the script generator124, to be executed to log the user device into a site associated with the payment instrument, such as a site of a provider or servicer of the payment instrument.

The UI900may include a listing of used sites906that use this payment instrument. In some embodiment, the used sites906may use this payment instrument as a default payment instrument which is selected by default when performing a transaction using one of these sites. By making the payment instrument a default payment instrument, the payment instrument is more likely to be used in a transaction involved with the site. This is desirable for bank, a servicer, or a provider of the payment instrument since it increases a likelihood that the payment instrument will be used. The current sites may be represented with a descriptor908, which may enable access to information about the site or the site itself. In some embodiments, selection of the descriptor908may cause a script to be executed that logs the user into the site and access a location of the site that stores this payment instrument, such as a user account. A change control910may cause a script, created by the script generator124, to be executed to change a payment instrument associated with a current site. The change control910may cause a script, created by the script generator124, to be executed to enable other features and/or access to another UI to facilitate interaction with the site or payment instrument.

The UI900may include a listing of unused sites912. The used sites906may not use this payment instrument or may not have this payment instrument selected as a default payment instrument which is selected by default when performing a transaction using one of these sites. A “add site” control912may cause a script, created by the script generator124, to be executed to add the payment instrument902to unused site and/or make the payment instrument902a default payment instrument for the selected unused site. An “add all” control may cause one or more scripts to update all the unused sites910.

FIG. 10shows an illustrative UI1000that includes a payment instrument input interface to enable updating a payment instrument locally and/or remotely. The UI1000may provide details of a payment instrument1002. The UI1000may enable update of information1004associated with the payment instrument, such as a name of a person associated with the payment instrument, a number or identifier, an expiration data, a nickname, notes, and/or other information. A “make default” control1006may make this payment instrument a default instrument during autofill operations, which may cause a script, created by the script generator124, to be executed to populate input fields in sites using the information1004or similar information when applicable. The autofill may be performed by a script, created by the script generator124, that is executed to update known and previously identified fields in a site with the corresponding information. The UI1000may include a “save changes” control1008, which may save changes to the payment instrument in the user data118or in another location. The UI1000may include a cancel control1010to cancel an update to the payment instrument (or exit the UI1000) and a delete control1012to delete or remove the payment instrument, possibly from the user data118or another location. An update control1014may cause changes received from information1004via the UI1000to be updated in sites that use this payment instrument. The update control1014may cause one or more scripts, created by the script generator124, to be executed to update sites with the information1004.

FIG. 11shows an illustrative UI1100that includes another payment instrument input interface to enable updating a payment instrument locally and/or remotely. The UI1100is associated with a payment entity1102, such as a bank, provider, or service. The UI1100includes information1104, which may be updated for the payment entity1102, such as a name, an account number, a routing number, notes, and/or other relevant information depending on the type of payment entity (e.g., bank, corporate provider, payment servicer, etc.). The UI1100may include a credentials input section1106that enables input of credentials, such as a username and password. A credential strength meter1108may provide feedback about a strength of the credentials. A “save changes” control1110may enable saving changes to the payment entity in the user data118or in another location. The UI1110may include a cancel control1112to cancel an update to the payment entity (or exit the UI1100) and a delete control1114to delete or remove the payment entity, possibly from the user data118or another location.

The UI1100may include a payment instrument section116that lists payment instruments associated with the payment entity. An update control1118may cause changes received from information1104via the UI1100to be updated in sites that use this payment instrument. The update control1118may cause one or more scripts, created by the script generator124, to be executed to update sites with the information1104.

FIG. 12shows an illustrative UI1200that includes a site management interface to enable adding updating remote data associated with the site. The UI1200allows selection of a site, such as an electronic merchant, service provider, or other site. The UI1200includes a search control1202to search for a site. A site input field1204may enable selection of a site or input of a site. Once a site is identified, other options may become available, as discussed below with reference to the UI1200. For example, payment instruments1206may be presented that may be associated with the selected site. Selection of one of these payment instruments may cause a script, generated by the script generator124, to be executed to update the payment instrument and/or default payment instrument of the selected site.

The UI1200may include a credentials input section1208that enables input of credentials, such as a username and password. A credential strength meter1210may provide feedback about a strength of the credentials.

The UI1200may include an auto-credentials control1212that enable use of a script, generated by the script generator124, to be executed to auto-input the credentials to the selected site when the site is visits by the user device operating the script module228. A master-password control1214may cause a prompt to use a master password prior to inputting the credentials.

A “save changes” control1216may enable saving changes to the site in the user data118or in another location. The UI1200may include a cancel control1218to cancel an update to the site (or exit the UI1200) and a delete control1220to delete or remove the payment entity, possibly from the user data118or another location.

FIG. 13shows an illustrative UI1300that includes a payment switching interface to enable switching payment instruments across one or more remote storage locations. The UI1300may include a first section1302that enables selection of a payment instrument to switch, update, or replace with a payment instrument selected from a second section1304. The switch, update, or replacement may be performed via one or more scripts, generated by the script generator124, and executed by the user device having the script module228. A user may select a payment instrument from the first section1302and select a payment instrument from the second section1304. The user may then select one of the following controls to cause further actions. A “switch all sites” control1306may cause all sites that use the selected payment instrument from the first selection to be replaced with the selected payment instrument from the second selection using one or more scripts executed by the script module228. In some embodiments, the “switch all sites” control1306may cause all sites that use the selected payment instrument from the first selection as a default payment instrument to be replaced with the selected payment instrument from the second selection as a default payment instrument using one or more scripts executed by the script module228. A “let me choose” control1308may enable selection of which sites to update using the selections in the UI1300or another UI. A cancel control1310may cancel any updates (or exit the UI1300).

FIG. 14shows an illustrative UI1400that includes a payment switching interface that reports progress of a switch of a payment instrument across one or more remote storage locations. The UI1400may be accessed in response to use of the UI1300. The UI1400includes a prior payment instrument1402that is to be updated, replaced, or switched with a replacement payment instrument1404. For example, the prior payment instrument1402may be a selection from the first section1302from the UI1300while the replacement payment instrument1404may be a selection from the second section1304from the UI1300.

A progress section1406may indicate progress of updates to sites to replace, update, or switch the payment instruments, where the update is caused by one or more scripts, generated by the script generator124, and executed by the user device via the script module228. The progress section1406may include a site identifier1408, a progress indicator1410, and a completion indicator1412. The progress indicator may provide information about a progress of an update, such as by using a bar or meter that graphically depicts progress of the update. The completion indicator1412may indicate a successful completion, which may then be communicated to the event logger208. An error indicator1414may indicate an error has occurred, which may be communicated to the event logger208and processed as described above in the processes600and620. For example the error indicator1414may enable a user to retry the script or the script may be automatically retried at a later time. A cancel control1416may cancel any updates (or exit the UI1400).

CONCLUSION