Patent Description:
Regulatory and compliance regimes are a means to reduce cybersecurity threats and related threats to data privacy, e.g. identity theft, credit card fraud, etc. Entities that receive sensitive personal data through their business processes, e.g. payment card data, social security numbers, are required to, or otherwise agree to, perform by the standards published by such entities, e.g. the Payment Card Industry Data Security Standard ("PCI DSS"). Complying with, and demonstrating compliance with, such standards is a significant and increasing cost of doing business.

Remote purchases are one example of a communications channel facing cybersecurity threats. A remote purchase may be performed by online payment via a web store remote application, or by a phone transaction with a customer service agent. These transactions may make use of point of sale software and/or payment kiosks, e-commerce web stores for online orders or inside sales teams for phone orders. Remote purchases may include the provisioning of sensitive data and may be subject to a cybersecurity standard, such as the Payment Card Industry Data Security Standard (PCI DSS). Although all such "merchants" have signed an agreement with their bank that they will comply with PCI DSS, it can be costly for such enterprises and parties that accept payment cards to comply with PCI DSS. Compliance with a cybersecurity standard, such as PCI DSS, may necessitate that enterprises and parties implement controls, protocols, software and facilitate testing of a platform that is intended to receive remote purchases. In some examples, compliance may also compel an additional cost of a third-party audit, for example by a Regulatory Compliance Assessor (RCA)RCA just as failure to comply can lead to significant fines and even constraints on future acceptance of payment cards.

Merchant enterprises that deal with remote purchases can be obligated to comply with cybersecurity standards, such as the Payment Card Industry Data Security Standard (PCI DSS), by their financial institutions as a precondition to using their financial institution's services. Consequently, merchant enterprises face the dilemma of bearing the costs of complying with a cybersecurity standard, such as PCI DSS, or bearing the cost of contracting a service provider to implement the necessary controls, protocols, and software that shows compliance.

In general, there is a class of communications problems associated with transmissions of sensitive data from a remote user to a server-side application, or from a remote user to an agent connected to a server-side application. Each transmission may be conducted in a manner that necessitates a predetermined level of compliance with cybersecurity standards. Similarly, there are a class of problems associated with the exposure of sensitive data, such as a payment card number on devices such as servers and workstations. Related issues may also impact other devices that are connected to those exposed devices.

<CIT> discloses a system and methods for Point to Point Encryption and Tokenization Using a Mobile Device.

<CIT> discloses methods, a computer-readable medium, servers and systems for enabling merchants to pass payment tokens, instead of actual payment information, to third party HOPs and SOPs. This, for example, enables a merchant to charge a consumer, such as on a recurring basis or for a one-off purchase, without having the consumer enter payment information each time and without the merchant actually having to handle payment information. As such, merchants can avoid costs and responsibilities associated with handling and storing consumer payment data, while at the same time it also gives merchants the benefit of engaging in purchase transactions with consumers without requiring that the consumers reenter payment data each time they want to make a purchase.

<CIT> discloses securely receiving data input at a computing device without storing the data locally. The invention allows an application, such as a mobile app, to receive payment information (e.g. credit card information) directly from a user without requiring the application to comply with the PA DSS or another standard. The application can employ any type of user interface for receiving user input as well as one or more overlaid input fields that receive sensitive payment information. The overlaid input fields can be part of a web page or other interface that can securely submit data to a remote computer system (e.g. a server) where it can be stored, processed, or transmitted in accordance with the PCI DSS. In this way, the sensitive payment information (or another type of information) is not stored, processed, or transmitted by the application on the local device.

<CIT> discloses a method and associated computing system. Data received by a computing environment includes a mixture of non-sensitive data and sensitive data along with related metadata indicative of a sensitivity of the sensitive data. The computing system includes the computing environment. An operation is performed on the sensitive data in the computing environment by: (a) determining that the data used for the operation are sensitive data, (b) intercepting the operation on the sensitive data, and (c) registering newly created sensitive data, as a result of the operation, with metadata indicating one or more addresses of the sensitive data. An external access to the sensitive data in the computing environment is intercepted. A compliance firewall rule is applied to the sensitive data intended to leave the computing environment. The compliance firewall rule defines an action to be applied to the sensitive data such that the sensitive data are protected against unauthorized access.

<CIT> discloses a method in which protection is provided to prevent a computer user from unintentionally giving away sensitive data (e.g., security credentials, credit card number, PINs, personal data, or bank account number) to an illegitimate or unintended entity by means of a client application capable of communicating the sensitive data across a network to other computer users. To provide the protection, user input is monitored to detect a user entry of the sensitive data into the client application for communication to other users. When such an entry occurs, action is taken to reduce the likelihood of an unintentional giveaway of the sensitive data or to reduce the effects of an unintentional giveaway.

This disclosure describes techniques for automating the transfer of risk associated with compliance of a cybersecurity standard, such as the Payment Card Industry Data Security Standard (PCI DSS), from one party to another. More specifically, this disclosure describes techniques to architect a separation of software components, services, communications channels and data such that the handling of sensitive data in a standards-compliant manner may be isolated to a designated network, namely a Secure Data Processing (SDP) network. In various examples, an SDP network and related infrastructure may be configured to isolate the use and transfer of sensitive data that, for purposes of business operations or the business system application, would otherwise be exposed to a portion of a client workstation and/or an application server, e.g. a company's business system. Sensitive data may include personally identifiable information, such as a Primary Account Number (PAN) (i.e. a credit card number, social security number, or bank account number) and/or user authentication credentials. In this way, a client workstation and corresponding application servers, which would ordinarily be exposed to sensitive data inherent in certain transactions, remain free from exposure to sensitive data. In this way, these transactions are freed from the risk of cybersecurity threats and are therefore outside the scope of PCI DSS compliance.

Traditionally, system components of a computing environment that are exposed to sensitive data may be subjected to a Regulatory Compliance Assessor (RCA) audit. By way of example, an RCA audit may be pursuant to a PCI DSS cybersecurity standard. The PCI DSS cybersecurity standard has adopted scoping categories that determine whether a system component is subject to an RCA audit. The scoping categories include:.

Category <NUM> - System components that process, store or transmit sensitive data such as cardholder data (CHD) or are not isolated or restricted through controlled access from other Category <NUM> system components.

Category <NUM> - System components that have controlled access to a Category <NUM> system component and do not themselves ever process, store or transmit sensitive data.

Category <NUM> - System components that are isolated from all Category <NUM> system components.

In this regard, system components that fall within Category <NUM> and Category <NUM> are subject to an RCA audit pursuant to the PCI DSS cybersecurity standard.

In a non-limiting example, consider a client workstation that is facilitating a consumer e-commerce transaction. In this example, the consumer may navigate to an e-commerce website to purchase a particular item. To facilitate the transaction, the consumer may enter a PAN into an input field within the e-commerce website, as consideration for the transaction. The client workstation may transmit transaction details to an application server, via a web server, to execute the transaction. In this example, the PAN is considered sensitive data, pursuant to the PCI DSS cybersecurity standard. Further, the client workstation, web server, and application server that receive, store, and/or transmit the PAN may be considered as Category <NUM> devices, pursuant to the PCI DSS cybersecurity standard, and therefore subject to an RCA audit.

An RCA audit may act to transfer some of the liability associated with managing a system's cybersecurity threats from a system owner to an RCA auditor. While the transfer of some liability of cybersecurity threats may benefit the system owner, the cost penalty of transferring liability may be burdensome on some system owners. Therefore, this disclosure describes an SDP network and related infrastructure that is configured to isolate a client workstation from exposure to sensitive data, thus keeping the client workstation and interfacing web servers and application servers outside of scope for PCI DSS compliance and not subject to an RCA audit.

Referring to the previous example, the techniques described herein may facilitate isolating the PAN (i.e. sensitive data) that is entered as part of an e-commerce transaction from being received, stored, and/or transmitted by a client workstation. In one example, the PAN may be entered directly into a hosted webpage invoked, via a secure plug-in, by a secure communications server of the SDP network. The hosted webpage may isolate entry of the PAN from the client workstation, thus resulting in the client workstation being classified as a Category <NUM> device pursuant to the PCI DSS cybersecurity standard, and therefore not subject to RCA audit. The secure plug-in is installed on the client workstation such that it remains segregated from transactional data flow with a web server or application. Thus, despite being connected to the client workstation, the webserver and application servers are not exposed to the PAN, and thus remain Category <NUM> devices. In another example, the PAN may be entered via a secure input device that is communicatively connected to the client workstation. The secure input device may correspond to a secure card reader, a point of sale device, or an integrated key pad. The secure input device may transform the PAN to devalued data prior to transmission to the client workstation. Even though the devalued data is transformed from sensitive data, the devalued data retains no extrinsic value or meaning, and thus receiving, storing and/or transmitting the devalued data does not invoke a Category <NUM> classification, pursuant to the PCI DSS cybersecurity standard. Instead, upon receipt of the PAN as devalued data, the client workstation is considered a Category <NUM> device and therefore not subject to an RCA audit. Similarly, the web server and application server that interact with the client workstation to receive, store, and/or transmit the devalued data are also considered to be Category <NUM> devices pursuant to the PCI DSS cybersecurity standard, and therefore not subject to an RCA audit.

In summary, the PAN (i.e. sensitive data) may be transmitted from the client workstation directly to a secure communications server within the SDP network as sensitive data, via a secure plug-in and hosted webpage or as devalued data in response to entry via a secure input device. At the secure communications server, the devalued data may be decrypted and/or transformed via a Point-to-Point Encryption (P2PE) server to recreate the PAN (i.e. sensitive data). The PAN (i.e. sensitive data) may be transmitted via the secure communications server to a tokenization server, which generates and returns a token to the secure communications server based on the sensitive data. The token may represent the sensitive data and may be used instead of the sensitive data (i.e. the PAN) to initiate a transaction. The token itself does not include sensitive data. The token has no extrinsic or exploitable value or meaning and is instead configured to map back to the sensitive data at the tokenization server, e.g. during an authorization of a payment card in a sales order entry process.

In this example, since secure communications server and the tokenization server each receive, store, and transmit sensitive data, each server is considered to be a Category <NUM> device, pursuant to the PCI DSS cybersecurity standard, and therefore subject to an RCA audit.

Therefore, the techniques described herein facilitate isolating a Category <NUM> system components for handling sensitive data to a secure communications server of an SDP network and a tokenization server. The client workstation, an interacting web server, and application server remain Category <NUM> devices, since they are isolated from sensitive data, and thus not subject to an RCA audit.

In addition, this disclosure further describes techniques that protect a client workstation from being considered a Category <NUM> device in the event that a user inadvertently enters sensitive data (i.e. PAN) into the client workstation instead of via a secure input device or via a hosted webpage invoked by a secure plug-in. Consider an example of a consumer or sales agent entering sensitive data directly into an input field of a client workstation. Since the client workstation has received sensitive data (i.e. PAN), albeit inadvertently, the client workstation may be considered a Category <NUM> device, and thus subject to an RCA audit. Additionally, in the event that the web server and application server have controlled access to the client workstation (i.e. communicative connection), the web server and application server may be considered at least Category <NUM> devices, and thus subject to an RCA audit pursuant to the PCI DSS cybersecurity standard.

To protect the client workstation from inadvertently being considered a Category <NUM> device, this disclosure describes a secure data shield component that interacts with the client workstation to prevent the inadvertent entry of sensitive data into an input field on the client workstation. The secure data shield component may be configured to prevent data entry on the client workstation that is substantially similar to sensitive data. Consider, as a non-limiting example, a secure data shield component that prevents an inadvertent entry of a <NUM>-character PAN. In this example, the secure data shield may prevent the entry of data strings that are substantially similar to a <NUM>-character PAN. A substantially similar data string may comprise of a data string length that is less than the <NUM>-character PAN by a predetermined number of characters. The predetermined number of characters may comprise two characters, three characters, four characters, or any number of characters that is greater than or equal to one character. In various examples, the characters may include numbers, letters, symbols, or any combination thereof. In this way, the secure data shield component may halt the inadvertent entry of a complete PAN (i.e. sensitive data) at a point of partial entry. While this example describes a <NUM>-character PAN, one of ordinary skill in the art may adapt the secure data shield component to prevent an inadvertent entry of a PAN comprising of any number of characters or patterned string of characters.

By shielding the client workstation from the complete entry of the sensitive data, the client workstation, the interacting web server, and the interacting application server, may remain Category <NUM> devices and therefore not subject to an RCA audit pursuant to the PCI DSS cybersecurity standard.

The term "techniques," as used herein, may refer to system(s), method(s), computer-readable instruction(s), module(s), algorithms, hardware logic, and/or operation(s) as permitted by the context described above and through the document.

<FIG> and <FIG> illustrate exemplary computing environments that facilitate isolating sensitive data to a Secure Data Processing (SDP) network. <FIG> illustrates a first computing environment <NUM> that is configured to process sensitive data <NUM> as devalued data <NUM> from a secure input device <NUM>. <FIG> illustrates a second computing environment <NUM> that is configured to process sensitive data <NUM> via a secure plug-in <NUM> that is native to a client workstation <NUM>.

In various examples, a user may initiate a transaction that includes sensitive data <NUM> via a client workstation <NUM>. The sensitive data <NUM> may include payment cardholder data (CHD), such as a credit card number and authentication credentials sufficient to draw funds from an associated financial account. By way of example, unauthorized access of sensitive data <NUM> may allow another party to commandeer funds from the associated financial account without first gaining the user's authorization. Sensitive data <NUM> may also include personally identifiable data and any other information that is subject to privacy law and/or regulation(s).

Referring to <FIG>, the first computing environment <NUM> describes the input of sensitive data <NUM> via a secure input device <NUM>. The secure input device <NUM> corresponds to a registered PCI DSS device, which is configured to receive sensitive data <NUM> as a user input and transform the sensitive data into devalued data prior to transmission to a client workstation <NUM>.

In one example, the secure input device <NUM> may be configured to devalue sensitive data <NUM> upon receipt and make use of a Point-to-Point Encryption (P2PE) server <NUM> to do so. Accordingly, the secure input device <NUM> itself is not considered a Category <NUM> device (i.e. processes, stores, or transmits sensitive data <NUM>), because it performs real-time encryption to protect sensitive data <NUM>.

The secure input device <NUM> may correspond to a secure card reader, a point of sale device, or an integrated card reader. Alternatively, or additionally, the secure input device <NUM> may comprise of a keypad, with an optional display, where sensitive data <NUM>, such as a PAN, may be entered Note, however, that even though the client workstation <NUM> is communicatively connected to the secure input device <NUM>, since the secure input device <NUM> is a registered PCI DSS device, the client workstation <NUM> is considered a Category <NUM> device. Thus, the client workstation <NUM> remains out of scope for an RCA audit. It is noteworthy, that the client workstation <NUM> is further protected from inadvertent entry of sensitive data via secure data shield component, which is discussed in further detail with reference to <FIG>.

In the illustrated example, the client workstation <NUM> may receive sensitive data <NUM> from the secure input device <NUM> as devalued data <NUM>. In one example, the sensitive data <NUM> may correspond to a Primary Account Number (PAN) (i.e. a credit card number or bank account number) to provision consideration for a transaction. Thus, the devalued data <NUM> corresponds to a representation of the PAN that retains no extrinsic value or meaning. In some examples, devalued data may be generated by a two-way (i.e. reversible) mathematical function that converts the sensitive data to an unintelligible value. Therefore, the client workstation <NUM> may transmit the devalued data <NUM> via an ordinary communications path <NUM>, without risk of inadvertently compromising any sensitive data <NUM>.

The ordinary communications path <NUM> may be a typical communications connection established via any type of wired and/or wireless network, including but not limited to local area networks (LANs), virtual private networks (VPNs), wide area networks (WANs), satellite networks, cable networks, Wi-Fi networks, Wi-Max networks, mobile communications networks (e.g. <NUM>, <NUM>, and so forth), or any combination thereof.

It is noteworthy that even though most communications connections have some degree of encryption and security, the ordinary communications path <NUM>, as described herein, is not security-rated nor is it otherwise considered to possess sufficient security to transmit sensitive data. Thus, the ordinary communications path <NUM> is configured to transmit non-sensitive data, such as devalued data <NUM>.

The client workstation <NUM> may transmit the devalued data <NUM> to an application server <NUM> via the ordinary communications path <NUM>. Upon receipt of the devalued data <NUM>, the application server <NUM> may transmit the devalued data to the Secure Data Processing (SDP) network <NUM> via an ordinary communications path. In various examples, the SDP network <NUM> may include functions that handle sensitive data <NUM> in a manner that is compliant with prevailing cybersecurity standards, such as the PCI DSS cybersecurity standard. Functions may include, but are not limited, to encryption, tokenization, secure communications, interfacing with third parties, or any combination thereof. The SDP network <NUM> is described in further detail with reference to <FIG>, <FIG>, and <FIG>.

The SDP network <NUM> may interact with the P2PE server <NUM> that is configured to decrypt/transform the devalued data <NUM> to the sensitive data <NUM> that was originally input at the secure input device <NUM>. It is noteworthy that the P2PE server <NUM> may communicate with an secure communications server of the SDP network <NUM> via a secure communications path <NUM> that is configured to provide sufficient security for transmitting the sensitive data to the SDP network <NUM>. In contrast to an ordinary communications path <NUM>, the secure communications path <NUM> is security-rated or otherwise considered to possess sufficient security to transmit sensitive data. In this way, transmitting sensitive data <NUM> over the secure communications path <NUM> mitigates any risk of a cybersecurity threat exposing the sensitive data <NUM>.

Upon receipt of the sensitive data <NUM> from the P2PE server <NUM>, the SDP network <NUM> may transmit the sensitive data <NUM> to a tokenization server <NUM> via a secure communications path <NUM> to receive a token <NUM>. The tokenization server <NUM> may be configured to generate the token <NUM> based at least in part on the sensitive data <NUM>. Tokenization, when applied to data security, is a process of substituting sensitive data with a non-sensitive equivalent (i.e. the token <NUM>). The token may represent the sensitive data and may be used instead of the sensitive data (i.e. the PAN) to initiate a transaction at the client workstation, such as a payment authorization. In this example, the token <NUM> has no extrinsic or exploitable value or meaning. Instead, the token <NUM> is configured to map back to the sensitive data <NUM> through the tokenization server <NUM>. Therefore, the tokenization server <NUM> may transmit the token <NUM> to the SDP network <NUM> via an ordinary communications path <NUM> without risk of inadvertently compromising any sensitive data <NUM>.

Moreover, the SDP network <NUM> may transmit the token <NUM> to the application server <NUM> via an ordinary communications path <NUM>. In some examples, the application server <NUM> may transmit an acknowledgment <NUM> of receipt of the token <NUM> to the client workstation <NUM> via an ordinary communications path <NUM>.

In summary, the first computing environment <NUM> describes the use and transformation of sensitive data <NUM> at the SDP network <NUM> (or, components thereof as discussed in more detail with reference to <FIG>, <FIG>, and <FIG>), the P2PE server <NUM>, and a tokenization server <NUM>. Each of these above-referenced systems interact directly with sensitive data <NUM> and therefore are considered Category <NUM> devices, pursuant to the PCI DSS cybersecurity standard. Note that the secure input device <NUM> is not considered a Category <NUM> device since it performs real-time encryption of sensitive data. Notwithstanding, the client workstation <NUM> and application server <NUM> - along with any intermediary web servers - remain free from exposure to the sensitive data <NUM> and receive only instances of devalued data <NUM> or a token <NUM>, each of which is representative of sensitive data <NUM>, but do not include sensitive data <NUM>. Thus, the client workstation <NUM>, application server <NUM>, and an intermediary web server, are considered Category <NUM> devices pursuant to the PCI DSS cybersecurity standard and therefore out of scope of an RCA audit.

Referring to <FIG>, the second computing environment <NUM> describes the input of sensitive data <NUM> via secure plug-in <NUM>. The secure plug-in <NUM> may reside on the client workstation <NUM> and may interact with web pages, web browers-based application, and client applications native to the client workstation <NUM>. The secure plug-in <NUM> is specifically served via the SDP network <NUM> and is configured to invoke a hosted webpage associated with a secure communications server of the SDP network <NUM>. The secure communications server of the SDP network <NUM> is discussed in more detail with reference to <FIG>, <FIG>, and <FIG>. The inclusion of the secure plug-in <NUM> acts to isolate the sensitive data <NUM> from other client applications that reside and/or operate via the client workstation <NUM> and to segregate a connected web server and application server from exposure to the sensitive data <NUM>. In this way, the sensitive data <NUM> captured by the hosted webpage invoked by the secure plug-in <NUM> is protected from being exposed via another client application on the client workstation <NUM>.

In this example, a secure communications server of the SDP network <NUM> (i.e. the secure communications server of the SDP network <NUM> is discussed in further detail with reference to <FIG>, <FIG>, and <FIG>) may receive the sensitive data <NUM> from the secure plug-in <NUM> via a secure communications path <NUM>. Upon receipt of the sensitive data <NUM>, the secure communications server of the SDP network <NUM> may transmit the sensitive data <NUM> to a tokenization server <NUM> via secure communications path <NUM> to receive a token <NUM>. Further, the token <NUM> to an application server <NUM> associated with the client workstation <NUM> via an ordinary communications path <NUM>. In some examples, the application server <NUM> may transmit an acknowledgment <NUM> of receipt of the token <NUM> to the client workstation <NUM> via an ordinary communications path <NUM>.

In summary, the second computing environment <NUM> describes the use and transformation of sensitive data <NUM> at a secure communications server of the SDP network <NUM> and the tokenization server <NUM>. Since the secure plug-in <NUM> is configured to invoke a hosted webpage associated with the secure communications server of the SDP network <NUM>, the use and transformation of sensitive data <NUM> received at the secure plug-in <NUM> is considered as being received at the SDP network <NUM>. The secure communications server of the SDP network <NUM> and the tokenization server <NUM> interact directly with the sensitive data <NUM>, and therefore are considered Category <NUM> devices, pursuant to the PCI DSS cybersecurity standard. Notwithstanding, the client workstation <NUM>, the application server <NUM>, and any intermediary web servers, remain free from exposure to the sensitive data <NUM> and receive only a token <NUM>, which is representative of sensitive data <NUM>, but do not include the sensitive data <NUM>. Thus, the client workstation <NUM>, application server <NUM>, and an intermediary web server, are considered Category <NUM> devices, pursuant to the PCI DSS cybersecurity standard and therefore out of scope of an RCA audit.

In various examples, the application server <NUM> may operate on one or more distributed computing resource(s). The one or more distributed computing resource(s) may include one or more computing device(s) that operate in a cluster or other configuration to share resources, balance load, increase performance, provide fail-over support or redundancy, or for other purposes.

Moreover, the client workstation <NUM> may correspond to any sort of electronic device, such as a cellular phone, a smartphone, a tablet computer, an electronic reader, a media player, a gaming device, a personal computer (PC, a laptop computer), etc. In various examples, the client workstation <NUM> may be a remote device relative to the application server <NUM>, intermediary web servers, and the SDP network <NUM>.

<FIG> and <FIG> illustrate blocks of process interactions between a client workstation and the SDP network. <FIG> illustrates an example process that uses a secure input device to receive sensitive data as devalued data. <FIG> illustrates an example process that uses a secure plug-in native to a client workstation to receive sensitive data.

Referring to <FIG>, the first computing environment <NUM> includes various components that are the same or substantially similar to the first computing environment <NUM> described with reference to <FIG>, except for the SDP network <NUM>. As such, for brevity and ease of description, various details relating to the first computing environment <NUM> are omitted herein to the extent that the same or similar details have been provided above with reference to <FIG>.

In this example, the client workstation <NUM> may receive an instance of devalued data <NUM> from a secure input device <NUM>. The devalued data <NUM> may correspond to a transaction being performed on the client workstation <NUM> and may be representative of, but not inclusive of, financial account data (i.e. PAN) to authorize payment for the transaction. In this way, the client workstation <NUM> may transmit the devalued data <NUM> to an application server <NUM> associated with the transaction via an ordinary communications path <NUM>. The application server <NUM> may transmit the devalued data <NUM> to the SDP network <NUM> via an ordinary communications path <NUM> for the purpose of receiving a token <NUM>. The token <NUM> may represent the sensitive data <NUM> may be used for a transaction conducted at the client workstation, such as a payment authorization.

In the illustrated example, the SDP network <NUM> may comprise a gateway server <NUM>, a firewall <NUM>, and a secure communications server <NUM>. The gateway server <NUM> may be communicatively connected to the firewall <NUM> via an ordinary communications path <NUM> and the firewall <NUM> may be communicatively connected to the secure communications server <NUM> via an ordinary communications path <NUM>.

Referring to <FIG>, the secure communications server <NUM> may receive devalued data <NUM> from the gateway server <NUM>. As discussed earlier, the devalued data <NUM> is representative of, but not inclusive of, sensitive data <NUM> entered via a secure input device <NUM> at a client workstation <NUM>.

In this example, the secure communications server <NUM> may interact with the P2PE server <NUM> to decrypt/transform the devalued data <NUM> into sensitive data <NUM>. In some examples, the secure communications server <NUM> and the P2PE server <NUM> may interact via a secure communications path <NUM>. In other examples, the secure communications path <NUM> and the P2PE server <NUM> may interact via a secure communications path that is proprietary to the P2PE server <NUM>.

The secure communications server <NUM> may transmit the sensitive data <NUM> to a tokenization server <NUM>. The tokenization server <NUM> may generate a token <NUM> that represents the sensitive data <NUM>. The token <NUM> may then be used in place of the sensitive data <NUM>. In one non-limiting example, consider a transaction initiated at a client workstation <NUM>. Upon receipt of the sensitive data <NUM> (i.e. cardholder payment data), the tokenization server <NUM> may generate a token <NUM> that represents the sensitive data <NUM> (i.e. cardholder payment data). The token <NUM> may then be used instead of the cardholder payment data (i.e. sensitive data <NUM>) to authorize payment for the transaction initiated at the client workstation <NUM>. The token <NUM> itself does not include the cardholder payment data (i.e. sensitive data <NUM>). Instead, the token <NUM> comprises devalued data <NUM> that can be used by the tokenization server <NUM> to map to the sensitive data <NUM> stored within the third-party processing service. In this way, the token <NUM> represents but does not include the sensitive data <NUM> that is stored securely within the third-party processing service. Therefore, being fully devalued and having no extrinsic value, the tokenization server <NUM> may transmit the token <NUM> to the secure communications server <NUM> via an ordinary communications path <NUM>.

In this example, the secure communications server <NUM> and the tokenization server <NUM> each process, store, and/or transmit sensitive data <NUM>. Therefore, the secure communications server <NUM> and the tokenization server <NUM> are considered Category <NUM> devices pursuant to the PCI DSS cybersecurity standard and are within scope of an RCA audit.

The gateway server <NUM> is configured to isolate system components configured to serve sensitive data <NUM> from other system components that are to be isolated from sensitive data <NUM>. Referring to the PCI DSS cybersecurity standard, the gateway server <NUM> may isolate system components that process, store, or transmit sensitive data <NUM> (i.e. Category <NUM> devices) from system components that are to be isolated from sensitive data <NUM> (i.e. Category <NUM> devices). In the illustrated example, the gateway server <NUM> may receive and transmit non-sensitive data between the application server <NUM> and the secure communications server <NUM>, via the firewall <NUM>. In one example, the gateway server <NUM> may receive devalued data <NUM> from the application server <NUM> for transmission to the secure communications server <NUM>. In another example, the gateway server <NUM> may receive a token <NUM> from the secure communications server <NUM> for transmission to the application server <NUM>. Since the gateway server <NUM> does not process, store, or transmit sensitive data <NUM>, it is not considered a Category <NUM> device, pursuant to the PCI DSS cybersecurity standard. However, the gateway server <NUM> does have controlled access to a Category <NUM> system component, namely the secure communications server <NUM>, and therefore, the gateway server <NUM> is considered a Category <NUM> device pursuant to the PCI DSS cybersecurity standard, and within scope of an RCA audit.

The firewall <NUM> between the gateway server <NUM> and the secure communications server <NUM> is configured to prevent sensitive data <NUM> from being transmitted outward from the secure communications server <NUM> to the gateway server <NUM>. In this example, the firewall <NUM> provides an added level of security to ensure that the gateway server <NUM> does not inadvertently become a Category <NUM> device in response to inadvertent exposure to sensitive data <NUM>. In various examples, the firewall <NUM> may be configured to prevent an inadvertent transmission of data that resembles sensitive data <NUM>. For example, the firewall <NUM> may be configured to prevent transmission of a data string that resembles a PAN (i.e. sensitive data <NUM>). In this example, the firewall <NUM> may prevent transmission of any data string length that is substantially similar to the PAN. A substantially similar data string may comprise of a data string length that is less than the data length of the PAN by a predetermined number of characters. The predetermined number characters may comprise of two characters, three characters, four characters, or any number of characters greater than or equal to one character. In this way, the firewall <NUM> halt the inadvertent transmission of sensitive data <NUM> between the secure communications server <NUM> and the gateway server <NUM>.

By shielding the gateway server <NUM> from sensitive data <NUM>, the gateway server <NUM> may remain a Category <NUM> device, and the application server <NUM>, which is communicatively connected to the gateway server <NUM>, may remain a Category <NUM> device.

Referring to <FIG>, the second computing environment <NUM> includes various components that are the same or substantially similar to the first computing environment <NUM> described with reference to <FIG> and the second computing environment <NUM> described with reference to <FIG>. As such, for brevity and ease of description, various details relating to the second computing environment <NUM> are omitted herein to the extent that the same or similar details have been provided above with reference to <FIG> and <FIG>.

In this example, the client workstation <NUM> may receive an input of an instance of sensitive data <NUM> at a hosted webpage that is invoked by a secure plug-in <NUM> at the client workstation <NUM>. The secure plug-in <NUM> may be considered to interact with client applications that reside and/or operate on the client workstation <NUM>, and in response to a request (i.e. from a client application) for entry of sensitive data, such as a PAN, on the client workstation <NUM>, invoke a hosted webpage from the secure communications server <NUM> of the SDP network <NUM>. Sensitive data received via the hosted webpage is directly transmitted to the secure communications server <NUM>. Thus, the inclusion of the secure plug-in <NUM> acts to isolate sensitive data from the client applications that reside and/or operate via the client workstation <NUM>. By isolating the sensitive data <NUM> from other client applications on the client workstation <NUM>, the secure plug-in <NUM> ensures that the client workstation <NUM> remains a Category <NUM> device pursuant to the PCI DSS cybersecurity standard, and thus outside the scope of an RCA audit. Similarly, other devices connected to the client workstation <NUM>, such as the application server <NUM> and any intermediary web servers, remain free from exposure to the sensitive data <NUM>.

Upon receipt of the sensitive data <NUM> at the secure communications server <NUM>, the secure communications server <NUM> may transmit the sensitive data <NUM> to the tokenization server <NUM> via a secure communications path <NUM>, and in return, receive a token <NUM> associated with the sensitive data <NUM> via an ordinary communications path <NUM>. In some examples, the token may comprise of a devalued representation of the sensitive data <NUM>, which is then made available to further authorize a transaction initiated at the client workstation <NUM>, such as a payment authorization.

The secure communications server <NUM> may transmit the token <NUM>, via the firewall <NUM>, to the gateway server <NUM> for delivery to the application server <NUM>. In this example, the secure communications server <NUM> and the tokenization server <NUM> each process, store, and/or transmit sensitive data <NUM>. Therefore, the secure communications server <NUM> and the tokenization server <NUM> are considered Category <NUM> devices pursuant to the PCI DSS cybersecurity standard and are within scope of an RCA audit. Similarly, the gateway server <NUM> is considered a Category <NUM> device pursuant to the PCI DSS cybersecurity standard because it has controlled access to a Category <NUM> device, namely the secure communications server <NUM>. In this example, the gateway server <NUM> is also within scope of an RCA audit. However, the application server <NUM> and the client workstation <NUM> are isolated from the sensitive data <NUM> and do not have controlled access to a Category <NUM> device (i.e. the secure communications server <NUM> or the tokenization server <NUM>), and are therefore are considered Category <NUM> devices that are outside the scope of an RCA audit.

Since the SDP network <NUM>, namely the secure communications server <NUM>, firewall <NUM>, and gateway server <NUM> are collectively isolated, the SDP network architecture lends itself to being owned and operated by a single, separate cybersecurity business entity which may take on the responsibilities and liabilities, i.e. the risk, of handling sensitive data <NUM> from enterprises and other application users associated with the client workstation <NUM> and application server <NUM>.

In various examples, the secure communications server <NUM> and the gateway server <NUM> may operate on one or more distributed computing resource(s). The one or more distributed computing resource(s) may include one or more computing device(s) that operate in a cluster or other configuration to share resources, balance load, increase performance, provide fail-over support or redundancy, or for other purposes.

Moreover, the SDP network <NUM>, namely the secure communications server <NUM>, the firewall <NUM>, and the gateway server <NUM>, may be hosted on a cloud infrastructure that is hosted behind cybersecurity measures that prevent theft of data, or damage to data or functionality. In this example, the security of the cloud infrastructure may be verified by audit to ensure that the security level meet prevailing cybersecurity standards. By way of example, the cloud infrastructure may include the use of firewalls or whitelist/blacklist algorithms to prevent unauthorized access. In one example, the cloud infrastructure may itself be compliant with relevant PCI DSS requirements.

The cloud infrastructure may comprise a physical dedicated server or a virtual machine. In the latter case, the cloud infrastructure may be represented as a plurality of disaggregated servers that provide virtual application server functionality and virtual storage/database functionality. The disaggregated servers are physical computer servers, which may have a processor, a memory, an I/O interface and/or a network interface. The features and variations of the processor, the memory, the I/O interface and the network interface are substantially similar to those described with reference to <FIG>.

The cloud infrastructure may provide access to virtual application servers and virtual storage servers. In some examples, the cloud infrastructure may provide additional service abstractions such as Platform as a Service ("PAAS"), Infrastructure as a Service ("IAAS"), a Software as a Service ("SAAS"), or any combination thereof.

<FIG> illustrates a block diagram of various components of a client workstation <NUM> that interacts with the SDP network. In this example, the client workstation <NUM> may receive an input of sensitive data <NUM> (i.e. via a secure input device or a secure plug-in) that is associated with a transaction. The sensitive data may correspond to a Primary Account Number (PAN) (i.e. a credit card number or bank account number) that is required to authorize payment for the transaction.

The client workstation <NUM> may include input/output interface(s) <NUM>. The input/output interface(s) <NUM> may include any type of output interface known in the art, such as a display (e.g. a liquid crystal display), speakers, a vibrating mechanism, or a tactile feedback mechanism. Input/output interface(s) <NUM> also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display. Further, the input/output interface(s) <NUM> may further include a camera, a microphone, a keyboard/keypad, or a touch-sensitive display. A keyboard/keypad may be a push button numerical dialing pad (such as on a typical telecommunication device), a multi-key keyboard (such as a conventional QWERTY keyboard), or one or more other types of keys or buttons, and may also include a joystick-like controller and/or designated navigation buttons, or the like.

Additionally, the client workstation <NUM> may include network interface(s) <NUM>. The network interface(s) <NUM> may include any sort of transceiver known in the art. For example, the network interface(s) <NUM> may include a radio transceiver that performs the function of transmitting and receiving radio frequency communications via an antenna. In addition, the network interface(s) <NUM> may also include a wireless communication transceiver and a near-field antenna for communicating over unlicensed wireless Internet Protocol (IP) networks, such as local wireless data networks and personal area networks (e.g. Bluetooth or near field communication (NFC) networks). Further, the network interface(s) <NUM> may include wired communication components, such as an Ethernet port or a Universal Serial Bus (USB).

Further, the client workstation <NUM> may include one or more processor(s) <NUM> that are operably connected to memory <NUM>. In at least one example, the one or more processor(s) <NUM> may be a central processing unit(s) (CPU), graphics processing unit(s) (GPU), or both a CPU and GPU or any other sort of processing unit(s). Each of the one or more processor(s) <NUM> may have numerous arithmetic logic units (ALUs) that perform arithmetic and logical operations as well as one or more control units (CUs) that extract instructions and stored content from processor cache memory, and then execute these instructions by calling on the ALUs, as necessary during program execution. The one or more processor(s) <NUM> may also be responsible for executing all computer applications stored in the memory, which can be associated with common types of volatile (RAM) and/or non-volatile (ROM) memory.

In some examples, memory <NUM> may include system memory, which may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. The memory may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape.

The memory <NUM> may further include non-transitory computer-readable media, such as volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory, removable storage, and non-removable storage are all examples of non-transitory computer-readable media. Examples of non-transitory computer-readable media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium which can be used to store the desired information.

In the illustrated example, the memory <NUM> may include an operating system <NUM>, a user interface <NUM>, client application(s) <NUM>, an interface component <NUM>, a secure input component <NUM>, a secure data shield component <NUM>, and a secure plug-in component <NUM>. The operating system <NUM> may be any operating system capable of managing computer hardware and software resources. The operating system <NUM> may include an interface layer that enables applications to interface with the input/output interface(s) <NUM> and the network interface(s) <NUM>. The interface layer may comprise public APIs, private APIs, or a combination of both. Additionally, the operating system <NUM> may include other components that perform various other functions generally associated with an operating system.

The client application(s) <NUM> may correspond to a web application executed via a web browser. In this example, the web application may be executed on an application server <NUM> that is communicatively connected to the client workstation <NUM>. In one example, the client application(s) <NUM> may facilitate an e-commerce transaction which requires any entry of sensitive data, in the form of a PAN, as consideration.

The secure input component <NUM> may interface with a secure input device <NUM> to receive devalued data. In this instance, the secure input device <NUM> is configured to transform sensitive data prior to transmission to the secure input component <NUM>.

The secure data shield component <NUM> may be configured to prevent data entry on the client workstation that is substantially similar to sensitive data. For example, the secure data shield component <NUM> may prevent an inadvertent data entry of a data string that is substantially similar to sensitive data. A substantially similar data string may comprise of a data string length that is less than the sensitive data by a predetermined number of characters. The predetermined number of characters may comprise two characters, three characters, four characters, or any number of characters greater than or equal to one character. In this way, the secure data shield component <NUM> may halt the inadvertent entry of a complete string of sensitive data at a point of partial entry. In a non-limiting example, consider a data entry of a <NUM>-character PAN. In this example, the secure data shield component <NUM> may prevent the entry of data strings that are substantially similar to a <NUM>-character PAN in any input field within the user interface <NUM>, irrespective of whether the input field is intended to receive the PAN. In other words, if a user accidentally enters a partial PAN in a field intended for the devalued data, or some other text field (i.e. a name field, an address field, , or a feedback/suggestions field) on the user interface <NUM>, the secure data shield component <NUM> may halt any further data entries to that field to ensure that entry of the full PAN cannot be completed.

The secure plug-in component <NUM> may be configured to invoke a hosted webpage associated with a secure communications server of an SDP network for entry of sensitive data directly at the secure communications server. The secure plug-in component <NUM> may be installed onto the client workstation <NUM> at a point in time prior to the consumer initiating the e-commerce transaction. The secure plug-in component <NUM> may be configured to invoke a hosted webpage associated with the secure communications server for entry of sensitive data directly at the secure communications server. In this way, the inclusion of the secure plug-in acts to isolate sensitive data from the client application(s) <NUM> that reside and/or operate at the client workstation <NUM>, and similarly to segregate the application server and intermediary web servers from exposure to the sensitive data.

It is noteworthy that the hosted webpage may present its own user interface to capture sensitive data, rather than capturing data entries from a client application. In doing so, the hosted webpage acts to isolate the sensitive data from the intermediary web servers and the application server.

The interface component <NUM> may interact with an application server to receive an acknowledgment associated with receipt of a token at the application server.

The user interface <NUM> may provide a consumer with input fields to enter non-sensitive data and sensitive data (e.g. via a hosted webpage invoked by a secure plug-in component <NUM>).

<FIG> illustrates a block diagram of various components of a secure communications server <NUM> that is a part of the SDP network. The secure communications server <NUM> is configured to process, store, and/or transmit sensitive data <NUM>. Therefore, the secure communications server <NUM> is considered a Category <NUM> device pursuant to the PCI DSS cybersecurity standard and within scope of an RCA audit.

The secure communications server <NUM> may include input/output interface(s) <NUM> and network interface(s) <NUM>. The input/output interface(s) <NUM> may be similar to the input/output interface(s) <NUM> and the network interface(s) <NUM> may be similar to the network interface(s) <NUM>.

The secure communications server <NUM> may include one or more processor(s) <NUM> that is operably connected to memory <NUM>. The one or more processor(s) <NUM> may be similar to the one or more processor(s) <NUM> and the memory <NUM> may be similar to the memory <NUM>.

In the illustrated example, the memory <NUM> may include an operating system <NUM>, a gateway interface component <NUM>, a secure plug-in component <NUM>, a P2PE decryption component <NUM>, a tokenization component <NUM>, and a data store <NUM>. The operating system <NUM> may be similar to the operating system <NUM>.

The secure plug-in component <NUM> may be configured to interact with client application(s) on the client workstation. The secure plug-in component <NUM> may include logic that determines whether operations involve an entry or tracking of sensitive data. In response to detecting the entry or tracking of sensitive data, the secure plug-in component <NUM> may invoke the hosted webpage that is associated with the secure communications server <NUM>. In a non-limiting example, the secure plug-in component <NUM> may detect that sensitive data is being entered at a client workstation, and in doing so, invoke the hosted webpage to receive the sensitive data at the secure communications server <NUM>.

In response to a request for entry of sensitive data (i.e. a PAN) from a client application on the client workstation, the secure plug-in component <NUM> may invoke a hosted webpage associated with a secure communications server for entry of sensitive data directly at the secure communications server. In other words, sensitive data received via the hosted webpage is directly transmitted to the secure communications server. In this way, the inclusion of the secure plug-in acts to isolate sensitive data from the client application(s) that reside and/or operate at the client workstation, and to similarly segregate the application server and intermediary web servers from exposure to the sensitive data. Additionally, the sensitive data captured by the secure plug-in component is protected from being exposed via a non-secure path, such as an ordinary communications path.

It is noteworthy that the hosted webpage may present its own user interface to capture sensitive data at the client workstation, rather than capturing data entries from a client application. In doing so, the hosted webpage acts to isolates the sensitive data from the client workstation.

The gateway interface component <NUM> may interact with the gateway server <NUM> of the SDP network <NUM>. In various examples, the interface between the gateway interface component <NUM> and the gateway server <NUM> may be at least an ordinary communications path, and optionally secure communications path. In some examples, the gateway interface component <NUM> may transmit (e.g. a token) and receive (e.g. devalued data) to and from the gateway server <NUM> via the firewall <NUM>.

The P2PE decryption component <NUM> is configured to interact with a P2PE server to decrypt/transform devalued data to the sensitive data originally input at the secure input device.

In one example, the P2PE server may be in a different physical location to the secure communications server <NUM>, in which case the devalued data may be transmitted to the P2PE server over an ordinary communications path. The P2PE decryption component <NUM> may receive the sensitive data (i.e. transformed devalued data) from the P2PE server via a secure communications path. Optionally, the secure communications path may be proprietary to the P2PE server.

The tokenization component <NUM> is considered to interact with a tokenization server, which generates and returns a token. In some examples, the token may represent a payment authorization for an e-commerce transaction initiated at the client workstation. The tokenization component <NUM> may transmit sensitive data to the tokenization server via a secure communications path. In return, the tokenization component <NUM> may receive the token from the tokenization server via an ordinary communications path. The token represent the sensitive data. The token may then be used in place of the sensitive data. The token itself does not include sensitive data and has no extrinsic or exploitable value or meaning. Instead, the token is configured to map back to the sensitive data at the tokenization server.

The data store <NUM> may be configured to store sensitive data, token, and other sensitive and non-sensitive data associated with transforming devalued data to sensitive data and generating a token based on the sensitive data.

<FIG> illustrates a process for generating a token based on an input of sensitive data via a secure input device. In some examples, the input of sensitive data may relate to initiating a sales transaction via a secure input device. Further, the token may represent the sensitive data and may be used instead of the sensitive data (i.e. the PAN) to initiate a sales transaction. Process <NUM> is presented herein from the perspective of the secure communications server of the SDP network.

At <NUM>, the secure communications server may receive from a gateway server, devalued data associated with a sales transaction initiated at a client workstation. The devalued data may represent payment card information for the sales transaction. The secure communications server may receive the devalued data via an ordinary communications path and via a firewall that separates the secure communications server from the gateway server. In some examples, the devalued data may have been initially provided via a secure input device that is communicatively connected to the client workstation.

At <NUM>, the secure communications server may transmit the devalued data to a P2PE server for transformation to the sensitive data originally input at the secure input device. In one example, the secure communications server may transmit the devalued data to the P2PE server via an ordinary communications path and receive the sensitive data (i.e. transformed devalued data) via a secure communications path or a proprietary secure communications path.

At <NUM>, the secure communications server may transmit the sensitive data to a tokenization server in exchange for a token. The secure communications server may transmit the sensitive data to the tokenization server via a secure communications path. In this example, the token may represents the sensitive data. The token is then used, instead of the sensitive data, to authorize the sales transaction initiated at the client workstation. The token itself does not include sensitive data and is instead configured to map back to the sensitive data at the tokenization server. Therefore, the secure communications server may receive the token from the tokenization server via an ordinary communications path.

At <NUM>, the secure communications server may transmit the token to the gateway server, via the intermediary firewall, for delivery to an application server associated with the e-commerce transaction. The secure communications server may transmit the token to the gateway server via an ordinary communications path. Further, the gateway server may transmit the token to the application server via an ordinary communications path. In some examples, the application server may transmit an acknowledgment of receipt of the token to the client workstation that initiated the sales transaction.

In summary, process <NUM> describes the secure communications server, the P2PE server, and the tokenization server as interacting directly with sensitive data and therefore considered as Category <NUM> devices pursuant to the PCI DSS cybersecurity standard, and within scope of an RCA audit. The gateway server is described as having controlled access to the secure communications server and is considered a Category <NUM> device pursuant to the PCI DSS cybersecurity standard, and therefore within scope of an RCA audit. The client workstation and application server do not interact directly with sensitive data, nor do they have controlled access to a system component (e.g. secure communications server and tokenization server) that interacts directly with sensitive data. Therefore, the client workstation and application server are considered Category <NUM> devices pursuant to the PCI DSS cybersecurity standard, and out of scope of an RCA audit.

<FIG> illustrates a process for generating a token based on an input of sensitive data via a secure plug-in native to a client workstation. The secure plug-in may invoke a hosted webpage associated with a secure communications server of an SDP network. In this example, a consumer may input sensitive data directly into the hosted webpage for receipt at the secure communications server. The sensitive data may relate to an e-commerce transaction initiated by a consumer at the client workstation. Process <NUM> is presented herein from the perspective of the secure communications server of the SDP network.

At <NUM>, the secure communications server may receive, from a secure plug-in that resides on a client workstation, sensitive data associated with an e-commerce transaction initiated at a client workstation. The secure plug-in may be configured to invoke a hosted webpage associated with the secure communications server for entry of sensitive data directly at the secure communications server.

At <NUM>, the secure communications server may transmit the sensitive data to a tokenization server in exchange for a token. The token itself does not include sensitive data and is instead configured to map back to the sensitive data at the tokenization server. Therefore, the secure communications server may transmit the sensitive data to the tokenization server via a secure communications path and may receive the token via an ordinary communications path.

At <NUM>, the secure communications server may transmit the token to the gateway server, via the intermediary firewall, for delivery to an application server associated with the e-commerce transaction. The gateway server may transmit the token to the application server via an ordinary communications path. In some examples, the application server may transmit an acknowledgment of receipt of the token to the client workstation that initiated the e-commerce transaction.

In summary, process <NUM>, similar to process <NUM>, describes the secure communications server and the tokenization server as interacting directly with sensitive data and therefore considered as Category <NUM> devices pursuant to the PCI DSS cybersecurity standard, and within scope of an RCA audit. The gateway server is described as having controlled access to the secure communications server and is considered a Category <NUM> device pursuant to the PCI DSS cybersecurity standard, and therefore within scope of an RCA audit. The client workstation, intermediary web servers, and the application server do not interact directly with sensitive data, nor do they have controlled access to a system component (i.e. secure communications server and tokenization server) that interacts directly with sensitive data. Therefore, the client workstation and application server are considered Category <NUM> devices pursuant to the PCI DSS cybersecurity standard, and out of scope of an RCA audit.

Much of the above discourse regarding the SDP network has been in the context of payment systems and compliance with payment card standards such as PCI DSS. However, the core of the SDP network is to transfer risk. Specifically, sensitive data of any sort, not just payment information, can be placed on a separate secure channel belonging to another party, such that a user's enterprise infrastructure never touch, let alone process, the sensitive data. In this way, an end to end communications channel is segmented and securely shielded, not only by portions that touch sensitive data but also by each segment that is owned by different parties. Parties willing to assume the risk for sensitive data may then become responsible for those portions and may take fees from other parties not willing or able to bear that risk. The following are some example use cases.

Social network applications collect a large amount of user information. Not only do social application sites collect facts and media about a user, but also collect user behavior. Some companies are using summaries of user behavior for identification purposes. Other companies are using summaries of user behavior to evaluate individuals for creditworthiness or for employment. Accordingly, in some circumstances, a user may wish to anonymize or otherwise control access to at least some of this data.

Social networks are an example of public business to consumer (B2C) exposure. However, there are B2C scenarios that are less public, but no less sensitive. This arises in regulatory situations, such as a Department of Motor Vehicles, or in medical cases. For medical data, the Health Insurance Portability and Accounting Act (HIPAA) regulates the handling of patient data.

As with the social media scenario above, a secure plug-in component may contain logic to determine which user operations involve sensitive data. When the medical data is associated with a token and not with any personally identifiable data for the individual, then the medical data is devalued. When the medical data needs to be merged with the personally identifiable data, then this can be done in a segregated and limited system that is simpler to assure as compliant with HIPAA and be managed by a compliant third-party. Again, the secure plug-in component may activate a secure plug-in associated with the secure communications server to isolate the entered sensitive data. In this way, a separate third party, willing and able to comply with HIPAA regulations on data may guarantee such compliance while relieving the electronic medical records system from HIPAA requirements.

In both the social network and HIPAA scenarios outlined above, handling of private data may be performed either by a cybersecurity business entity or a third-party. By isolating the personally identifiable information and any other regulated or sensitive data away from all other content and ensuring that non-secure infrastructure has neither access or contact with that regulated or sensitive data, the user's data is protected.

Also note that in the payment examples, those services may be new services for delegating the handling of private data. Note that those services need not be centralized services but may be decentralized using distributed ledgers such as blockchain.

Claim 1:
A computer-implemented method, comprising:
under control of one or more processors (<NUM>, <NUM>):
receiving a set of data (<NUM>) that includes first sensitive data (<NUM>), the first sensitive data (<NUM>) corresponding to a first transaction initiated at a client workstation (<NUM>);
extracting, the first sensitive data (<NUM>) from the set of data (<NUM>);
transmitting, to a tokenization server (<NUM>) and via a secure communications path (<NUM>) , a request for a token (<NUM>) that represents the first sensitive data (<NUM>) extracted from the set of data (<NUM>), the request including the first sensitive data (<NUM>);
receiving, from the tokenization server (<NUM>) and via at least an ordinary communications path (<NUM>) , the token associated (<NUM>) with the first sensitive data (<NUM>);
transmitting, to a gateway server (<NUM>) and via at least the ordinary communications path (<NUM>), the token (<NUM>),
the method being characterised in the following steps:
detecting a partial entry of second sensitive data in an input field of the client workstation (<NUM>) that is not configured to receive sensitive data, the partial data entry of the second sensitive data having a data string length that is less than a number of characters of a completed string of the second sensitive data by a predetermined number of characters; and
in response to detecting that the partial data entry of the second sensitive data occurs within an input field that is not configured to receive sensitive data, preventing completion of the entry of the completed string of the second sensitive data in the input field.