Apparatus, method and computer readable storage medium for automatically updating payment information

Abstract

Various embodiments generally relate to techniques for generating an automatically navigated website and enforcing rules for updates to payment token information.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application Serial No. 16 / 423,939, filed May 28, 2019 (published December 31, 2019 as U.S. Patent No. 10,523,681). The contents of the aforementioned patent application are incorporated herein by reference in their entirety. Background Technology

[0003] The list of companies involved in data breaches seems endless and continues to grow. And these are just the data breaches that have made national news; many companies have yet to be exposed. These breaches have occurred in all types of businesses, including universities, health insurance companies, and retailers from large to small—any institution that collects its customers' data is vulnerable, and hackers seem to be enjoying a new era of data breaches. One particularly common type of breach involves hackers gaining access to account information related to bank accounts, credit card accounts, debit card accounts, and so on. Typically, users are notified that their account information has been compromised and instructed to update their account information. Users are also responsible for identifying other retailers and locations that have possessed the compromised account information and updating the information there as well. This can be a time-consuming and arduous task, and one that users do not wish to perform. Summary of the Invention

[0004] The various embodiments described herein may include devices, systems, and apparatuses, etc., including a memory storing instructions and processing circuitry coupled to the memory. The processing circuitry is operable to execute the instructions, which, when executed, cause the processing circuitry to: receive an instruction for changing payment token information associated with a website comprising one or more web pages; initiate a script comprising one or more rules to cause execution of one or more actions navigating to a web page within the website to change the payment token information; automatically navigate to the web page to change the payment token information; and automatically change the payment token information using the new payment token information.

[0005] The embodiments discussed herein may also include a system for performing a computer-implemented method, the method comprising: receiving an instruction for changing payment token information associated with a website; generating one or more rules for automatically navigating to one or more web pages of the website to change the payment token information based on analysis of one or more web pages of the website; storing the one or more rules for performing the change of payment token information in a navigation file, the navigation file including the one or more rules for automatically navigating the website to the web page to change the payment token information in response to being initiated; initiating the navigation file to cause the execution of the one or more rules and navigation to the web page to change the payment token information; and causing the payment token information to change.

[0006] The embodiment may also include a computer-readable storage medium storing computer-readable program code executable by a processor to: crawl one or more web pages of a website to generate one or more rules for automatically navigating to the web pages to change payment token information associated with the website, and store the one or more rules for changing the payment token information in a navigation file, the navigation file causing the execution of the one or more rules for automatically navigating to the web pages to change the payment token information in response to being initiated. Attached Figure Description

[0007] Figure 1A An example of a system that provides automatic payment information updates is shown.

[0008] Figure 1B A second example of a system that provides automatic payment information updates is shown.

[0009] Figure 2A / Figure 2B The first and second examples of the processing flow are shown.

[0010] Figure 3A A third example of the processing flow is shown.

[0011] Figure 3B The fourth example of the flowchart is shown.

[0012] Figure 4A The first example of the first sequence diagram of automatic payment information update is shown.

[0013] Figure 4B A second example of a second sequence diagram for automatic payment information updates is shown.

[0014] Figure 5A The fifth example of the processing flow is shown.

[0015] Figure 5B The sixth example of the processing flow is shown.

[0016] Figure 5CThe seventh example of the processing flow is shown.

[0017] Figure 6 An example of a computing architecture is shown.

[0018] Figure 7 An example of a communication architecture is shown.

[0019] Figure 8 An example of a machine learning processing flow is shown. Detailed Implementation

[0020] Various embodiments generally relate to systems and operations for performing automated updates to websites used for payment token information (e.g., virtual credit card numbers). For example, embodiments include: determining that a website needs updating and running or executing one or more scripts to perform the update with minimal or no user interaction. The update may include replacing and / or providing a new virtual credit card number that can be used for future transactions via a checkout operation performed on the website. During the update, embodiments include: presenting a "veneer" webpage or screen to the user while the update is occurring in the background. The script can execute behind the veneer webpage and crawl the website to a specific webpage containing the information to be updated. The script can then continue updating the information. In some cases, for security reasons, the user may need to enter credentials so that the script can access personal account information while the update is being performed. However, in other cases, the script can securely retrieve credentials from a secure location, such as a web browser's secure server or a stored password section.

[0021] The embodiments also include systems and operations for generating one or more rules or instructions in a script (or executable) file for performing automatic updates. These operations can also be performed transparently to the user without their knowledge. Furthermore, rules can be generated by navigating to a website (e.g., a merchant website) that includes one or more web pages containing payment token information, analyzing the website (e.g., analyzing object models and elements to determine how to navigate to a specific web page containing account information), and identifying fields containing payment token information. These rules can be generated and / or updated from time to time and are securely stored on a storage system. These and other details will become more apparent in the following description.

[0022] Referring now to the accompanying drawings, wherein the same reference numerals are used throughout to refer to the same elements. In the following description, numerous specific details are set forth for illustrative purposes in order to provide a thorough understanding thereof. However, it will be apparent that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form for ease of description. It is intended to cover all modifications, equivalents, and substitutions within the scope of the claims.

[0023] Figure 1A An example of system 100 is shown, which enables users to pay for goods and services on website 112 via payment token information and performs automatic updates to payment information for those websites based on leaks, user requests, system requests, etc. For example, system 100 may include payment information system 102, which can interact and communicate with website 112 via Internet 108 to provide payment for goods and services that a user wishes to purchase by utilizing payment token information (e.g., credit card number, virtual account, account identifier, etc.). The payment token information may be securely stored on website 112 in an encrypted manner and can be used to make purchases by linking to, for example, a debit or credit card account associated with the user. The payment token information may be updated from time to time, for example, based on security vulnerabilities, fraud detection, general security settings (system requests), user requests, etc. System 100, including payment information system 102, enables automatic payment token updates with little or no user interaction, and these updates can occur transparently to the user. In embodiments, payment information system 102 may be part of one or more systems operated by a bank or credit card company providing financial services.

[0024] Payment information system 102 can utilize a set of instructions or rules stored in an executable or script file to navigate to web pages of website 112 to update payment token information. Furthermore, payment information system 102 can determine when instructions or rules for the website need to be updated and perform crawling or analysis of the website, including its web pages, to determine new instructions or rules.

[0025] In an embodiment, payment information system 102 may be coupled to storage system 104, which includes one or more data storage devices for storing information and data. Payment information system 102 may utilize storage system 104 to store, for example, instructions and / or rules for executing automatic updates to navigation website 112. Therefore, payment information system 102 may determine that an automatic update is needed, retrieve appropriate instructions or rules from storage system 104, and execute updates to one or more websites. In another example, payment information system 102 may generate new or updated instructions or rules to execute automatic updates to payment information and store the newly generated rules in storage system 104. In some cases, payment information system 102 and storage system 104 may be co-located, for example, within the same infrastructure, on the same network (subnetwork), on the same set of devices or devices (servers), etc. However, embodiments are not limited to this approach, and in some cases, payment information system 102 and storage system 104 may not be co-located. For example, storage system 104 may be a cloud-based storage system and may not be co-located with payment information system 102.

[0026] System 100 also includes a plurality of computing devices 110-y, where y can be any positive integer. Computing devices 110 can be any type of device capable of connecting to the Internet 108 via a wired and / or wireless connection to interact with websites 112-x, where x can be any positive integer. Note that in some cases, website 112 may be considered part of the Internet 108, but for purposes of discussion, it is shown separately in Figure 1. In an embodiment, computing devices 110 can be used by a user to access website 112 and make purchases through website 112.

[0027] In one embodiment, website 112 may store payment token information that can be used for purchases made via website 112. In some cases, as previously discussed, the payment token information may need to be updated. Payment information system 102 may present a “covered” webpage or overlay webpage to the user on the user’s computing device 110 to prevent the user from visually seeing the update. In some cases, the user may be using a mobile application, such as a mobile phone, and a “covered” webpage or screen may be presented in the mobile application as the payment information system navigates to the correct webpage with the payment token information and performs the update. The mobile application may send a message to the mobile device’s operating system, and the operating system may cause the covered graphic to be displayed on the display device. The operating system may continue to display the graphic until the mobile application sends another message indicating that the update is complete. In another example, the mobile application may be programmed with one or more routines that themselves initiate when an update is triggered. The mobile application, including one or more routines that are executing, may cause a pre-stored graphic to be displayed on the display device while the update is taking place.

[0028] In some cases, the update can be performed both in the web browser and on the webpage. During the update, the web browser can be caused to open a new "tab," for example, by executing a JavaScript code snippet including the "open_in_new_tab(url)" function, where the URL points to an image or webpage while the update is happening. The "tab" can be deleted when the update is complete. In another example, an invisible iframe can be used for navigation and to perform the update. The embodiments are not limited to this approach.

[0029] In some cases, this update can be caused and / or performed by a web browser extension, which may result in a "covered" webpage or screen being displayed in a window associated with the extension and / or webpage presented on the display device. A covered webpage can be any type or kind of webpage or screen capable of preventing the user from seeing navigation and updates. For example, graphics such as images, advertisements, etc., may be presented to the user in a pop-up webpage covering a website 112 used for making a purchase. In another example, a covered webpage could be a webpage that is being navigated by a script but has a blur effect applied. These and other details will become more apparent in the following description.

[0030] Figure 1B An example of system 150 is shown, which can be used with Figure 1A The system is similar to or the same as the system 100, and includes a more detailed view of the payment information system 102 that performs automatic updates of payment token information and generates rules / instructions for performing the updates. Figure 1BThe system 150 shown includes a payment information system 102 and a computing device 110 coupled to one or more websites 112 and the Internet 108. As previously discussed, the computing device 110 can be any type of computing device capable of communicating with the Internet 108, one or more websites 112 and the payment information system 102, such as a personal computer, mobile computing device, mobile phone, etc.

[0031] In this embodiment, the payment information system 102 is a computing device or system capable of providing payment services for online goods and servers, performing updates to payment token information on websites, determining instructions and / or rules for automatically performing payment token information updates, etc. The payment information system 102 may include any number of computing devices, such as one or more servers, server clusters, computers, etc. Furthermore, the payment information system 102 includes processors, circuitry, hardware, any number of components, systems, and engines that perform the operations discussed herein. These components, systems, and engines may be implemented solely in hardware (circuitry), solely in software, and / or a combination thereof.

[0032] In the example shown, the payment information system 102 includes: an update detection engine 152, a leakage detection engine 154, a rule generation engine 156, and a payment update engine 158. One or more engines may operate individually or in combination to perform the operations discussed herein.

[0033] In this embodiment, the update detection engine 152 can detect and / or determine when an update to the payment token information is needed. In this example, the update detection engine 152 may be a service and / or one or more processes executing on the payment information system 102, which may receive application programming interface (API) messages or other types of messages from one or more other services indicating that the payment token information needs to be updated. For example, the update detection engine 152 may determine whether a user has requested or disclosed an update, whether an administrator has requested or disclosed an update, whether a security information breach has occurred (via a retail security vulnerability, an online security vulnerability, or otherwise), whether periodic updates are required, and so on. Figure 2A An example processing flow 200 is shown, which can be executed by an update detection engine 152 to detect updates required for payment token information, such as credit card number updates.

[0034] At box 202, update detection engine 152 may receive an instruction to perform a payment token information update. As discussed, this instruction may be received from another service or engine in the form of an API call or message. For example, a user or administrator may cause an update via input with a graphical user interface (GUI), which may be sent to update detection engine 152 via an API call or message. In another example, the instruction may be received from a service or process operating to detect the occurrence of security vulnerabilities, such as a process of leak detection engine 154. In a third example, payment information 102 may include a process that causes automatic updates on a periodic or semi-periodic basis (e.g., every 90 days). Embodiments are not limited to these examples; for example, update detection engine 152 may receive update instructions based on other factors such as security policies, lost / stolen credit / debit card indications, etc.

[0035] In this embodiment, at block 204, update detection engine 152 can determine the content of payment token information that needs to be updated. For example, the instruction received at block 202 to perform the update may include an identifier for identifying specific payment token information. Update detection engine 152 can utilize the identifier to perform a lookup to determine the specific payment token information stored in storage system 104 and associated websites (e.g., websites storing specific payment token information). Furthermore, update detection engine 152 can determine which websites need updating based on the identifier. For example, update detection engine 152 can analyze a user's transaction history to determine which websites or physical locations the user can use to make purchases with a specific token. Update detection engine 152 can consider many factors while analyzing history, such as the time period of the transactions (places older than 3 years can be excluded).

[0036] The update detection engine 152 can also use information received in the instructions and found in the storage system 104 to determine which rules / scripts are needed to perform the update. In one example, the database of the storage system 104 may include payment token information for multiple users / customers, and instructions for each website where a user has stored payment token information. Furthermore, the database or data storage device of the storage system 104 may include instructions for each set of instructions and / or rule sets that need to be initiated to perform each update to a specific payment token information. Therefore, the update detection 152 identifies specific payment token information, determines the associated websites with the specific payment token information that needs updating, and determines the rules / scripts for those websites for the storage system 104. The update detection engine 152 collects or retrieves this information, for example, by performing a database retrieval or fetch to perform updates to one or more websites.

[0037] At box 206, update detection engine 152 can initiate the execution of an update to payment token information. For example, update 152 can send an API message, including information such as account information, payment token information, website information, executable or script information, to another service or engine to cause the payment token information update. The embodiment is not limited to this method. In another example, update detection engine 152 can initiate the execution of the executable or script itself to cause the payment token information update.

[0038] In some cases, update detection engine 152 can determine that multiple account and payment token information needs to be updated. For example, as will be discussed in more detail below, update detection engine 152 can receive an indication of a breach of website information containing multiple account and payment token information. Update detection engine 152 can determine each account and payment token information affected by the breach, each additional website storing the affected payment token information, and the script for updating each affected payment token information based on one or more lookups performed in storage system 104. Update detection engine 152 can cause a large-scale update of the payment token information for each account affected by the breach. In some cases, update detection engine 152 can determine the order in which large-scale updates are performed, or can initiate updates to multiple websites simultaneously. This order can be based on multiple purchases made by a particular retailer, from the most recent to the earliest purchase, etc.

[0039] Return to reference Figure 1B The payment information system 102 includes a leak detection engine 154. The leak detection engine 154 may be one or more processes that monitor the activity of other websites, receive leak information or indications, and provide leak indications to the update detection engine 152 to perform automatic updates. Figure 2B An example of a processing flow 250 for the detection of security vulnerabilities by a leak detection engine 154 is shown. At box 252, the leak detection engine 154 may determine and / or receive information that a security vulnerability has occurred on a specific website and / or has affected a specific account. For example, the leak detection engine 154 may receive API messages indicating unauthorized access to the website, release of secret / confidential information, disclosure of payment token information, etc. In this example, the leak may affect one or more accounts associated with the website. In another example, the leak detection engine 154 may receive API messages indicating that a specific account has been compromised. In this example, the leak detection engine 154 receives the disclosure indication based on an indication provided by the user as part of the authentication process. Therefore, a leak can affect any number of accounts compromised based on a website and / or a single account for a specific user, and the embodiments are not limited to this approach.

[0040] At box 254, the leak detection engine 154 can indicate that a leak has occurred and provide information about the leak to other engines (e.g., update detection engine 152). For example, leak detection engine 154 can send or transmit an indication of a leak occurring and an indication of affected websites via API messages. In this example, update detection engine 152 can use the indication of affected websites to perform a lookup in the database to identify affected accounts and other affected websites, such as websites storing affected payment token information. In another example, leak detection engine 154 can send or transmit an indication of a leak and an indication of accounts affected by a partial leak via API messages. Update detection engine 152 can use this information to perform a lookup to identify affected payment token information and affected websites to perform updates, as previously discussed.

[0041] In this embodiment, a leak can be detected based on information from one or more public resources (e.g., online newspapers, emails, online public statements, etc.). A leak can also be detected by the leak detection engine 154 based on attempts to use a merchant-specific virtual number being used by another merchant. A merchant-specific virtual number may be a number that is only permitted for use by a specific merchant; and therefore, attempts to use it elsewhere can indicate that the number has been misused.

[0042] In some cases, the leak detection engine 154 may perform additional remedial and notification actions. For example, the leak detection engine 154 may send and / or cause leak notifications to be sent (push) to all mobile devices with affected accounts, send emails associated with the affected accounts, cause banners to appear on web pages of a website, lock or block the use of the number, etc. These instructions may include notifying users of the leak and automatically updating information about what is happening or will happen. In other cases, the leak detection engine 154 may require user input to cause automatic updates, for example, by presenting a notification on the mobile device's display for the user to accept and / or reject automatic updates. Embodiments are not limited to this approach.

[0043] Return to reference Figure 1B The payment information system 102 includes a rule generation engine 156, which can be used to generate rules and / or instructions for updating payment token information. In an embodiment, the rule generation engine 156 can generate new rules and / or instructions to update payment token information for new or unknown websites, and can update already generated rules and / or instructions based on changes to the website.

[0044] Figure 3AAn example of a processing flow 300 is shown, which includes operations that can be performed by a payment information system 102, which includes a rule generation engine 156 for generating and updating rules and / or instructions for performing automatic payment token information updates.

[0045] At box 302, rule generation engine 156 determines whether to perform a crawl or scrape of the website to generate one or more rules. For example, rule generation engine 156 may receive instructions such as API messages or calls indicating that a website crawl is required. In some cases, this crawl may be performed when a new website is detected storing payment token information. In other cases, it may be performed as an update when changes to the website are detected. Rule generation engine 156 may also perform crawls periodically or semi-periodically, which can be based on customer activity; for example, websites with more customer activity may be crawled more frequently than websites with less or lower customer activity.

[0046] At box 304, rule generation engine 156 can perform a crawl of the website to generate scripts that can be used to execute rules or instructions for automatic updates. For example, rule generation engine 156 can analyze Hypertext Markup Language (HTML) code, Extensible HTML (XHTML) code, Extensible Markup Language (XML) code, etc., to determine how to navigate to the website and one or more web pages containing payment token information (such as a virtual credit card). More specifically, rule generation engine 156 can examine each line of code and each element within that line to determine how to navigate to the payment token information web page, for example, identifying tags used to indicate account information, payment information, etc. For example, rule generation engine 156 can access the website's underlying code to determine how to crawl the correct web pages via an object model (such as the Document Object Model (DOM) interface for HTML and XML). This object model provides an API for the website's web pages, enabling programs (such as web browsers) to access and manipulate the content of the web pages. This object model can provide a tree structure ("node tree") with a root containing tags and multiple elements. Rule generation engine 156 can, for example, locate code that specifies or links to web pages associated with payment token information under the Account and Payment Options section. Payment token information is identified in the code, for example, through tags of elements in an object model. Rule generation engine 156 can determine fields associated with payment token information based on one or more fields storing the payment token information and / or one or more tags of one or more elements identifying the payment token information. Therefore, rule generation engine 156 can crawl via the object model, for example, from one web page to another, and look for information that may need updating. One or more rules generated for the script file are used by payment information system 102 to navigate to the website's account page.

[0047] In this embodiment, rule generation engine 156 can analyze each webpage associated with the website to determine rules for navigating and changing payment token information. At box 306, rule generation engine 156 can determine and / or update rules to navigate to a specific webpage. These updated or new rules can be stored in a script file and used for navigation to change payment token information at a later point in time. Furthermore, at box 308, rule generation engine 156 can determine whether any webpages of the website still need to be analyzed to generate rules. For example, rule generation engine 156 can determine whether a webpage including payment token information has already been analyzed. If webpages of the website still need to be analyzed, rule generation engine 156 can further navigate to different webpages to reach the webpage including payment token information. However, if all webpages of the website have been analyzed, at box 310, rule generation engine 156 can finally determine the rules and store them in, for example, storage system 104.

[0048] Return to reference Figure 1B The payment information system 102 includes a payment update engine 158, which can be used to update payment token information. Figure 3B An example of a processing flow 350 for updating payment token information is shown. At box 352, the payment update engine 158 can determine to perform an update for the payment token information. For example, the payment update engine 158 may receive an instruction based on the disclosure of confidential information, including the payment token information. At box 354, the payment update engine 158 can determine the credentials used to access the account area of ​​a website with the payment token information. The payment update engine 158 may prompt (e.g., display a webpage) for the credentials to access the account area. The credentials may be a username and password for a specific website. In other cases, the payment update engine 158 may retrieve the credentials from secure storage (e.g., storage system 104). In this example, the credentials may be stored securely or encrypted and may not be known or discovered by the payment information system 102 itself. The credentials will only be decrypted at one or more servers associated with a specific website for the purpose of performing an automatic update. In a third example, the credentials may be stored and retrieved from a web browser, for example... or INTERNET The credential itself is stored in the payment information system 102 and the storage system 104. Therefore, the payment information system 102 and the storage system 104 may not store the credential itself, at least not in a decrypted manner, and it may not be easily attacked.

[0049] At box 356, the payment update engine 156 enables the faceted webpage or screen to automatically update payment token information. For example, a faceted webpage can be presented to the user on the display to prevent the user from visually seeing the payment token information update. The faceted webpage can be a blank webpage and / or include information such as advertisements, logos, symbols, etc. In some cases, the update can be performed via a mobile application, and the mobile application's "faceted" screen can be presented to the user while the update / navigation is occurring. In the third example, a web browser extension can perform the update, and the faceted screen can be presented in a window associated with the extension.

[0050] At box 358, the payment update engine 156 can perform the update and navigate the website via the rule. For example, the payment update engine 156 can access the website via an address and visit a specific webpage containing payment token information. At decision box 360, the payment update engine 156 can determine whether a specific website includes payment token information. If not, the payment update engine 156 can continue navigating to the correct webpage. If the payment update engine 156 determines that it is on the correct webpage (e.g., a webpage containing payment token information), then at box 362, the payment update engine 156 can cause an update to the payment token information, for example, replacing the credit card number with a new one. For example, the payment update engine 156 can determine that each element on the webpage has payment token information and provide the correct information in those elements. This element can be tagged and / or identified and stored in a script file. Furthermore, at box 364, the payment update engine 156 can notify the user of the automatic update performed.

[0051] Figure 4A An example of a processing flow 400 for updating payment token information is shown. The example shown includes a graphical user interface (GUI) display that can be presented to the user while the automatic update is occurring. In this example, the GUI can be presented to the user on the display of a mobile device. However, the embodiments are not limited to this example, and the webpage can be displayed on any type of display, such as within a window of a web browser operating on a personal computer.

[0052] At 402, a first GUI display may be presented to the user to indicate that payment token information, such as a virtual credit card number, is being generated and saved for the website. At 404, a list of one or more websites may be presented to the user, which may be updated with new payment token information. One or more websites may include previous or older versions of the payment token information associated with the user's account. The user can select a specific website by entering information. In some embodiments, websites may be presented, for example, in order of usage frequency, and may be sorted from most to least used. At 406, the user may be prompted to enter their credentials to access the website's account area, for example, a webpage including the payment token information. At 408, a webpage may be presented to the user when the payment information system 102 automatically updates the payment token information. At 410, a display indicating that the update is complete may be presented to the user.

[0053] Figure 4B Another example of a processing flow 450, including a display, is shown, which can be presented to a user in a web browser when an automatic update is being performed. At 452, a first display can be presented to the user, prompting the user to log in to an account used for a specific website. As previously mentioned, in some embodiments, the user enters credentials, while in other embodiments, credentials can be stored and / or automatically retrieved to access the account area of ​​the webpage. For example, credentials can be stored in a storage system 104 associated with payment information system 102. In another example, credentials can be retrieved from the web browser's stored credentials.

[0054] At box 454, a display can be shown to the user to generate a name for the payment token information, such as a virtual credit card number. Once the user enters the name, at box 456, the payment information system can automatically generate the payment token information and automatically update the website with the newly generated payment token information. At box 458, a display indicating that the update is complete can be shown to the user, along with the new payment token information.

[0055] Figure 5A An example of logic flow 500 is shown, which may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 500 may illustrate operations performed by a payment information system.

[0056] At box 505, the embodiment includes receiving an instruction to change payment token information associated with a website comprising one or more web pages. This instruction may be based on leak detection, user / administrator settings, etc. In the embodiment, the instruction may be an API message that includes information related to the website (e.g., which website) and the associated payment token information.

[0057] At box 510, process 500 includes: initiating a script comprising one or more rules to cause execution of one or more actions that navigate to a webpage within one or more webpages of a website to change payment token information. The script may be for a specific website, and the rules may be steps that navigate to a webpage including payment token information (e.g., an account webpage).

[0058] At box 515, the processing flow includes automatically navigating to the webpage where the payment token information needs to be changed. For example, payment information system 102 can use a script that includes this rule to navigate to the webpage of a website with payment token information. This rule may include specific instructions, such as providing information, causing button input on a specific button, etc.

[0059] At box 520, the embodiment includes: automatically changing the payment token information using new payment token information (e.g., using a new virtual number linked to an account associated with the user).

[0060] Figure 5B An example of logic flow 540 is shown, which may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 540 may illustrate operations performed by a payment information system to determine rules for automatically navigating a website.

[0061] At box 545, logic flow 540 includes receiving an instruction to change payment token information associated with the website. Furthermore, the payment information system can determine that a rule needs to be changed. At box 550, an embodiment includes generating one or more rules that automatically navigate to one of the web pages to change the payment token information, based on analysis of one or more web pages of the website.

[0062] At block 555, logic flow 540 includes: storing one or more rules in a navigation file for performing changes to payment token information, the navigation file including one or more rules that automatically navigate the website to a webpage to change the payment token information in response to an initiation. In an embodiment, the navigation file may be a script including the rules. However, in other cases, the navigation file may include executable instructions, and the embodiment is not limited to this approach.

[0063] At box 560, logic flow 540 includes: initiating a navigation file that causes the execution of one or more rules and navigates to a webpage where payment token information is to be changed, and at box 565, it includes: causing the payment token information to be changed, for example, navigating to at least one specific webpage that includes the payment token information, identifying one or more fields (elements) for the payment token information, and updating one or more fields with the new payment token information.

[0064] The payment token information is then stored on the website for future use. In some cases, new payment token information can be used to "test" charges. For example, the payment token information can be used to attempt to send a fee of one cent through the website. The payment information system can verify whether the test charge passes. If the charge passes, the payment information system can determine that the information has been successfully updated. If the charge fails, the payment token information can determine that the update failed and perform remedial actions, such as performing another fetch to update the rules and re-implementing the changes with the new updated rules. Examples are not limited to this approach.

[0065] Figure 5C An example of logic flow 580 is shown, which may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 580 may illustrate operations performed by a payment information system to determine rules for automatically navigating a website.

[0066] At box 585, logic flow 580 includes: crawling one or more web pages of a website to generate one or more rules for automatically navigating to the web page to change payment token information associated with the website. For example, the web page may be presented to the user in a web browser, web browser extension, mobile application, etc. In the background, the crawl may navigate to the website and one or more web pages associated with the payment token information. The payment information system may access the website via a Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) address, and then access and analyze the object model and elements of each web page of the website to find the correct web page. Furthermore, the payment information system may view each element of each web page and perform one or more actions, such as accessing another web page, identifying elements associated with the token information via element tags, etc. Additionally, at box 590, the embodiment includes: storing one or more rules for changing the payment token information in a navigation file or script, which, in response to being initiated, causes the execution of one or more rules for automatically navigating to the web page to change the payment token information. For example, the payment information system may store each step required to navigate to the website, one or more web pages associated with the payment token information, identifiers or tags of the payment token information elements, etc.

[0067] Figure 6 An embodiment of an exemplary computing architecture 600 suitable for implementing the various embodiments described above is shown. In one embodiment, the computing architecture 600 may include or be implemented as part of system 100.

[0068] As used in this application, the terms "system" and "component" are intended to refer to computer-related entities, hardware, combinations of hardware and software, software or executing software, examples of which are provided in the exemplary computing architecture 600. For example, a component can be, but is not limited to, a processor, hard disk drive, multiple storage drives (optical and / or magnetic storage media), object, executable file, execution thread, program, and / or process running on a computer. For example, an application running on a server and the server itself can both be components. One or more components may reside in a process and / or execution thread, and components may be localized on a single computer and / or distributed across two or more computers. Furthermore, components can communicatively couple with each other to coordinate operation through various types of communication media. Coordination may involve one-way or two-way information exchange. For example, components may transmit information in the form of signals transmitted through a communication medium. This information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, other embodiments may alternatively employ data messages. Such data messages can be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0069] The computing architecture 600 includes various general-purpose computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to those implemented by the computing architecture 600.

[0070] like Figure 6 As shown, the computing architecture 600 includes a processing unit 604, a system memory 606, and a system bus 608. The processing unit 604 can be any of a variety of commercially available processors.

[0071] System bus 608 provides interfaces for system components (including but not limited to system memory 606) to processing unit 604. System bus 608 can be any of several types of bus architectures, which can be further interconnected to memory bus (with or without memory controller), peripheral bus, and local bus using any of a variety of commercial bus architectures. Interface adapters can be connected to system bus 608 via slot architectures. Example slot architectures can include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), Network User Bus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Fast, PCMCIA, etc.

[0072] The computing architecture 600 may include or implement various manufactured articles. Manufactured articles may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code (e.g., source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc.). Embodiments may also be implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to achieve the performance of the operations described herein.

[0073] System memory 606 may include various types of computer-readable storage media in the form of one or more higher-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), dual data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory (e.g., ferroelectric polymer memory), austenite memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic cards or optical cards, device arrays (e.g., redundant array of independent disks (RAID)) drives, solid-state storage devices (e.g., USB storage, solid-state drives (SSDs), and any other type of storage media suitable for storing information). Figure 6 In the illustrated embodiment, system memory 606 may include non-volatile memory 610 and / or volatile memory 612. The Basic Input / Output System (BIOS) may be stored in non-volatile memory 610.

[0074] Computer 602 may include various types of computer-readable storage media in the form of one or more low-speed memory cells, including an internal (or external) hard disk drive (HDD) 614, a floppy disk drive (FDD) 616 for reading from or writing to a removable disk 618, and an optical disc drive 620 (e.g., a CD-ROM or DVD) for reading from or writing to a removable optical disc 622. HDD 614, FDD 616, and optical disc drive 620 may be connected to system bus 608 via HDD interface 624, FDD interface 626, and optical drive interface 628, respectively. HDD interface 624 for external drive implementation may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0075] Drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, multiple program modules may be stored in drive and memory units 610, 612 (including operating system 630, one or more applications 632, other program modules 634, and program data 636). In one embodiment, one or more applications 632, other program modules 634, and program data 636 may include, for example, various applications and / or components of system 700.

[0076] Users can input commands and information into computer 602 through one or more wired / wireless input devices (e.g., keyboard 638 and pointing devices such as mouse 640). Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, etc. These and other input devices are typically connected to processing unit 604 via input device interface 642 coupled to system bus 608, but can be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, etc.

[0077] Monitor 644 or other types of display devices are also connected to system bus 608 via an interface (e.g., video adapter 646). Monitor 644 can be internal or external to computer 602. In addition to monitor 644, the computer typically includes other peripheral output devices such as speakers, printers, etc.

[0078] Computer 602 can operate in a networked environment using logical connections to one or more remote computers (e.g., remote computer 648) via wired and / or wireless communications. Remote computer 648 can be a workstation, server computer, router, personal computer, laptop computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 602, although for brevity only memory / storage device 650 is shown. The described logical connections include wired / wireless connections to a local area network (LAN) 652 and / or a larger network (e.g., a wide area network (WAN) 654). Such LAN and WAN network environments are common in offices and corporations and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to global communication networks, such as the Internet.

[0079] When used in a LAN network environment, computer 602 is connected to LAN 652 via a wired and / or wireless communication network interface or adapter 656. Adapter 656 facilitates wired and / or wireless communication to LAN 652 and may also include a wireless access point disposed thereon for communicating with the wireless functions of adapter 656.

[0080] When used in a WAN network environment, computer 602 may include modem 658, or a communication server connected to WAN 654, or other means for establishing communication over WAN 654 (e.g., via the Internet). Modem 658, which may be internal or external and wired and / or wireless, is connected to system bus 608 via input device interface 642. In a network environment, program modules depicted relative to computer 602 or parts thereof may be stored in remote memory / storage device 650. It will be understood that the network connections shown are exemplary and other means of establishing communication links between computers may be used.

[0081] Computer 602 is operable to communicate with wired and wireless devices or entities using the IEEE 602 family of standards (e.g., wireless devices arranged in a wireless communication manner (e.g., IEEE 602.11 air modulation techniques)). This includes at least Wi-Fi (or wireless fidelity), WiMax, and Bluetooth. TMWireless technologies, etc. Therefore, communication can be a predefined structure like traditional networks, or simply self-organized communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 602.118 (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to interconnect computers, connect to the Internet, and connect to wired networks (which use IEEE 602.3 related media and functions).

[0082] The various elements of the device previously described with reference to Figures 1-5C may include a variety of hardware elements, software elements, or combinations of both. Examples of hardware elements may include: devices, logic devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, applications, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether to use hardware and / or software components to implement an embodiment can vary based on any number of factors, such as desired computing speed, power stage, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints as required by a given implementation.

[0083] Figure 7 This is a block diagram depicting an exemplary communication architecture 700 suitable for implementing the various embodiments described above. Communication architecture 700 includes various common communication elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, embodiments are not limited to those implemented by communication architecture 700 and may be consistent with system 100.

[0084] like Figure 7As shown, the communication architecture 700 includes one or more clients 702 and servers 704. Server 704 may implement one or more devices as shown in Figure 1, such as payment information 102. Clients 702 and servers 704 are operatively connected to one or more corresponding client data stores 706 and server data stores 710, which can be used to store local information of the respective clients 702 and servers 704, such as cached files and / or associated context information.

[0085] Client 702 and server 704 can use communication framework 710 to exchange information with each other. Communication framework 710 can implement any known communication technology and protocol. Communication framework 710 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as an enterprise intranet, etc.), a circuit-switched network (e.g., a public switched telephone network), or a combination of packet-switched and circuit-switched networks (with suitable gateways and converters).

[0086] The communication framework 710 can implement various network interfaces arranged to receive, communicate, and connect to communication networks. A network interface can be considered a special form of input / output (I / O) interface. Network interfaces can employ connection protocols, including but not limited to direct connection, Ethernet (e.g., thick, thin, twisted-pair 10 / 100 / 1000BaseT, etc.), Token Ring, wireless network interfaces, cellular network interfaces, IEEE 702.7ax network interfaces, IEEE 702.16 network interfaces, IEEE 702.20 network interfaces, etc. Furthermore, multiple network interfaces can be used to connect to various communication network types. For example, multiple network interfaces can be used to allow communication over broadcast, multicast, and unicast networks. If processing demands require greater speed and capacity, a distributed network controller architecture can be similarly used for pooling, load balancing, and other methods to increase the communication bandwidth required by the client 702 and server 704. The communication network can be any one and a combination of wired and / or wireless networks, including but not limited to direct interconnection, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), Operational Missions as Internet nodes (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communication networks.

[0087] The components and features of the aforementioned devices can be implemented using any combination of discrete circuits, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Furthermore, where appropriate, the features of the devices can be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination thereof. Note that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuit".

[0088] Figure 8 This is a flowchart illustrating examples of processes 800 for generating and using machine learning models, based on various aspects. Machine learning is a branch of artificial intelligence that involves mathematical models that can learn from data, classify data, and make predictions about data. Such mathematical models, which can be called machine learning models, can classify input data between two or more categories; cluster input data into two or more groups; predict outcomes based on input data; identify patterns or trends in input data; identify the spatial distribution of input data; or any combination thereof. Examples of machine learning models can include: (i) neural networks; (ii) decision trees, such as classification trees and regression trees; (iii) classifiers, such as Naive Bayes (…). (iv) Classifiers such as k-means clusterers, mean-shift clusterers, and spectral clusterers; (v) Factorizers such as factorization machines, principal component analyzers, and kernel principal component analyzers; (vi) Ensembles or other combinations of machine learning models. In some examples, neural networks may include: deep neural networks, feedforward neural networks, recurrent neural networks, convolutional neural networks, radial basis function (RBF) neural networks, echo-state neural networks, long short-term memory neural networks, bidirectional recurrent neural networks, gated neural networks, hierarchical recurrent neural networks, random neural networks, modular neural networks, spiking neural networks, dynamic neural networks, cascaded neural networks, neurofuzzy neural networks, or any combination thereof.

[0089] Different machine learning models can be used interchangeably to perform tasks. Examples of tasks that can be performed, at least partially, using machine learning models include: various types of rating; bioinformatics; cheminformatics; software engineering; fraud detection; customer segmentation; generating online recommendations; adaptive websites; determining customer lifetime value; search engines; real-time or near-real-time advertising; classifying DNA sequences; sentiment computing; performing natural language processing and understanding; object recognition and computer vision; robot movement; playing games; optimization and metaheuristics; detecting network intrusions; medical diagnosis and monitoring; or predicting when assets (such as machines) will require maintenance.

[0090] Machine learning models can be built through a process that is at least partially automated (e.g., with little or no human intervention) (called training). During training, input data can be iteratively fed to the machine learning model so that it can recognize patterns associated with the input data or identify relationships between the input and output data. Through training, the machine learning model can transition from an untrained state to a trained state. Input data can be split into one or more training sets and one or more validation sets, and the training process can be repeated multiple times. Splitting can follow rules such as k-fold cross-validation, leave-one-out, leave-p, or leave-out. The following is about... Figure 8 The flowchart describes an overview of training and using machine learning models.

[0091] In box 804, training data is received. In some examples, the training data is received from a remote or local database, constructed from various subsets of data, or input by the user. The training data can be used in its raw form to train a machine learning model, or preprocessed into another form that can then be used to train the machine learning model. For example, the raw form of the training data can be smoothed, truncated, aggregated, clustered, or otherwise manipulated into another form that can then be used to train the machine learning model. In embodiments, the training data may include historical data to determine and / or provide context for navigating a website to a specific webpage (e.g., a webpage associated with account information). This data can be used to train a model that crawls the website to generate one or more rules for automated navigation.

[0092] In box 806, the machine learning model is trained using training data. Machine learning models can be trained in a supervised, unsupervised, or semi-supervised manner. In supervised training, each input in the training data is associated with a desired output. This desired output can be a scalar, vector, or different types of data structures, such as text or an image. This allows the machine learning model to learn the mapping between inputs and desired outputs. In unsupervised training, the training data includes inputs but not the desired output, forcing the machine learning model to find structure within its own inputs. In semi-supervised training, only some inputs in the training data are associated with the desired output.

[0093] In box 808, the machine learning model is evaluated. For example, the evaluation dataset can be obtained, for instance, via user input or from a database. The evaluation dataset may include inputs related to the desired output. This input can be fed to the machine learning model, and the output from the machine learning model can be compared to the desired output. If the output from the machine learning model closely corresponds to the desired output, the machine learning model can have high accuracy. For example, if 90% or more of the output from the machine learning model is the same as the desired output in the evaluation dataset (e.g., current transaction information), the machine learning model can have high accuracy. Otherwise, the machine learning model may have low accuracy. The 90% figure is merely an example. The actual and desired percentage of accuracy depends on the problem and the data.

[0094] In some examples, if the machine learning model has insufficient accuracy for a particular task, the process can return to box 806, where the machine learning model can be further trained with additional training data or otherwise modified to improve accuracy. If the machine learning model has sufficient accuracy for the particular task, the process can continue to box 810.

[0095] In box 810, new data is received. In some examples, the new data is received from a remote or local database, constructed from various subsets of data, or input by the user. The machine learning model may not be aware of the new data. For example, the machine learning model may not have processed or analyzed the new data before.

[0096] In box 812, a trained machine learning model is used to analyze new data and provide results. For example, new data can be fed as input to the trained machine learning model. The trained machine learning model can analyze the new data and provide results, including classifying the new data into a specific category, clustering the new data into a specific group, making predictions based on the new data, or any combination thereof.

[0097] In box 814, the results are post-processed. For example, the results may be added, multiplied, or otherwise combined with other data that are part of the job. As another example, the results may be converted from a first format (such as a time series format) to another format (such as a count series format). During post-processing, any number and combination of operations can be performed on the results.

[0098] It will be understood that the exemplary devices shown in the above block diagrams may represent functionally descriptive examples of many potential implementations. Therefore, the division, omission, or inclusion of block functions depicted in the figures does not imply that hardware components, circuits, software, and / or elements used to implement these functions will necessarily be divided, omitted, or included in the embodiments.

[0099] At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer implementation methods described herein.

[0100] Embodiments may be described using the expressions “one embodiment” or “embodiment” and their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearance of the phrase “in one embodiment” in various places in the specification does not necessarily refer to the same embodiment. Furthermore, unless otherwise stated, the foregoing features are to be understood as being used in any combination. Thus, any features discussed separately may be used in combination with each other unless it is indicated that these features are incompatible with each other.

[0101] Primarily referencing the symbols and nomenclature used herein, the detailed description herein may be presented based on procedural procedures executed on a computer or computer network. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0102] The process here is generally considered a self-consistent sequence of operations that produces the desired result. These operations require physical manipulation of physical quantities. Typically, though not always, these quantities appear as electrical, magnetic, or optical signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient to sometimes refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc., primarily for reasons of common usage. However, it should be noted that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities.

[0103] Furthermore, the operations performed typically refer to terms such as addition or comparison, which are generally associated with mental operations performed by a human operator. In any of the operations described herein that form part of one or more embodiments, this ability of a human operator is not required, or in most cases not desirable. Instead, these operations are machine operations.

[0104] Some embodiments may be described using the expressions “coupled” and “connected” and their derivatives. These terms are not necessarily synonyms. For example, some embodiments may be described using the terms “connected” and / or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term “coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0105] Various embodiments also relate to apparatus or systems for performing these operations. The apparatus is specifically constructed for the desired purpose and can be selectively activated or reconfigured by a computer program stored in a computer. The processes presented herein are not inherently related to a particular computer or other apparatus. The desired configurations for various such machines will be apparent from the given description.

[0106] It is important to emphasize that the abstract of this disclosure is provided to enable the reader to quickly determine the nature of the technical disclosure. The premise of this disclosure is that the abstract must not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen from the foregoing detailed description, various features are combined in a single embodiment for the purpose of simplifying this disclosure. The approach of this disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than expressly stated in each claim. Rather, as reflected in the following claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the following claims are incorporated into the detailed description, wherein each claim stands independently as a separate embodiment. In the appended claims, the terms “including” and “in which” are used as their plain English equivalents to the respective terms “comprising” and “wherein”. Furthermore, the terms “first,” “second,” “third,” etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0107] The above description includes examples of the disclosed architecture. It is certainly impossible to describe every conceivable combination of components and / or methods, but those skilled in the art will recognize that many further combinations and permutations are possible. Therefore, this novel architecture is intended to encompass all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. An apparatus for automatically updating payment information, comprising: Memory that stores instructions; as well as A processing circuit coupled to the memory, operable to execute the instruction, which, when executed, causes the processing circuit to: Indications of security vulnerabilities that receive payment token information from a website and affect the payment token information associated with said website; Identify at least one of other websites that are associated with the payment token information and are affected by the security vulnerability of the website; Receive instructions for modifying payment token information for each of the other websites affected by the security vulnerability, each of the other websites comprising one or more web pages; Initiate a script that includes one or more rules to cause one or more actions to be performed to automatically navigate to one or more web pages of at least one of the other websites to change the payment token information; Automatically navigates to one or more web pages used to change the payment token information; Identify one or more fields on one or more web pages associated with the payment token information; and The payment token information is automatically changed using the new payment token information in one or more fields of one or more web pages associated with the payment token information; and The one or more rules used for automatic navigation are determined by crawling and analyzing each of the one or more web pages.

2. The apparatus of claim 1, wherein the processing circuitry enables the overlay webpage to cover each of the one or more webpages during automatic navigation to prevent the user from visually perceiving changes to the automatic navigation of the webpage and the payment token information.

3. The apparatus according to claim 1, wherein the processing circuit: The user is prompted to enter one or more credentials to access the account associated with the payment token information and the website; and Determine whether access to the account and the payment token information is permitted.

4. The apparatus according to claim 1, wherein the processing circuit: The one or more rules are stored in the script.

5. The apparatus according to claim 1, wherein the processing circuit: Detect at least one change in the one or more web pages and / or the website; and The crawling is initiated based on the detection of at least one change to determine the one or more rules.

6. The apparatus according to claim 1, wherein the processing circuit: Detecting a failure in the attempt to automatically change the payment token information; and Based on the detection of the fault, the crawling is initiated to determine the one or more rules.

7. The apparatus of claim 1, wherein the processing circuit crawls each of the one or more web pages and determines the one or more rules based on a document object model and / or one or more fields associated with the website.

8. The apparatus of claim 1, wherein the processing circuit automatically changes the payment token information by replacing information in one or more fields of the webpage with new payment token information.

9. The apparatus according to claim 1, wherein, The payment token information includes one or more of the following: virtual credit card number, address, expiration date, and username.

10. A method for automatically updating payment information, comprising: Indications of security vulnerabilities that receive payment token information from a website and affect the payment token information associated with said website; Identify at least one of other websites that are associated with the payment token information and are affected by the security vulnerability of the website; Receive instructions for modifying payment token information for each of the other websites affected by the security vulnerability, each of the other websites comprising one or more web pages; Based on the analysis and crawling of one or more web pages of the other websites, one or more rules are generated to automatically navigate to one or more web pages of the other websites to change the payment token information; The one or more rules are stored in a navigation file to perform changes to payment token information, the navigation file including the one or more rules that automatically navigate the other website to the webpage in response to an initiation to change the payment token information; Initiating the navigation file to cause the execution of one or more rules based on the instructions of the security vulnerability and automatically navigating to one or more pages of the other website to change the payment token information; and This causes changes to the payment token information on the other websites.

11. The method of claim 10, comprising: This allows the overlay webpage to cover each of the one or more webpages, preventing the user from visually seeing changes to the navigation of the webpage and the payment token information.

12. The method of claim 10, comprising: Crawl each of the one or more web pages and determine the one or more rules based on the Document Object Model and / or one or more fields associated with the website.

13. The method of claim 10, comprising: Identify one or more fields on one or more web pages associated with the payment token information; and The payment token information is automatically changed by replacing information in one or more fields of the one or more web pages.

14. A computer-readable storage medium storing computer-readable program code, said computer-readable program code being executable by a processor to: Crawl one or more web pages of a website to generate one or more rules for automatically navigating to those pages to modify payment token information associated with the website; and The one or more rules are stored in a navigation file for changing payment token information. In response to being initiated, the navigation file causes the execution of the one or more rules for automatically navigating to the one or more web pages to change the payment token information. Indications of security vulnerabilities that receive payment token information from different websites and affect the payment token information associated with those websites; Receive instructions for modifying payment token information for the different websites affected by the security vulnerability, each of the other websites including one or more web pages; Initiate a navigation file that includes one or more rules, causing one or more actions to be performed to automatically navigate to the one or more web pages to change the payment token information; Automatically navigates to one or more web pages on the different websites used to change the payment token information; Identify one or more fields from one or more web pages associated with the payment token information; and The payment token information is automatically changed using the new payment token information in one or more fields of one or more web pages associated with the payment token information.

15. The computer-readable storage medium of claim 14, further comprising computer-readable program code capable of executing: Detect at least one change in the one or more web pages and / or the website; and Based on the detection of the at least one change, a crawl is initiated to determine the one or more rules.

16. The computer-readable storage medium of claim 14, further comprising computer-readable program code capable of executing: Detecting a failure in the attempt to automatically change the payment token information; and Based on the detection of the fault, the crawling is initiated to determine the one or more rules.

17. The computer-readable storage medium of claim 14, further comprising computer-readable program code executable to: crawl each of the one or more web pages, and determine the one or more rules based on a document object model and / or one or more fields associated with the website.

Images