KR20140057526A - Token-based apparatus and a first-computer-implemented method - Google Patents

Abstract

The present invention relates to a data processing system, such as a payment system, including a tokenizer, such as a card encryption and storage system (CES) employing tokenized features. In one embodiment, the present invention provides a first computer implemented method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer. The first computer-implemented method comprises the steps of: (a) receiving information for transaction execution, the secret information including manual information input by a user; (b) the first computer sending the secret information to the third computer; (c) the first computer receiving a token from the third computer that has no algorithmic relationship with the secret information; And (d) transmitting, by the first computer, the transaction-performing information excluding the secret information to the second computer, and the token.

Description

TOKEN-BASED APPARATUS AND A FIRST-COMPUTER-IMPLEMENTED METHOD BACKGROUND OF THE INVENTION 1. Field of the Invention [0001]

The present invention relates to the provision, storage and use of confidential information within enterprise enterprise systems. More particularly, it relates to using tokens as a replacement for confidential information in the systems described above.

In response to theft of payment card data due to improper information technology security, the payment card industry (PCI) has developed a set of security standards. At first, payment-application best-practices (PABP) guidelines required by merchants for the encryption of card numbers were published.

Due to the limitations of the PABP guidelines, the PCI data security standard (DSS) 1.1 specification and related PCI security audit procedures were published in September 2006. These programs required a level of encryption beyond that for the payment card transaction process and required compliance with them. Under these programs, merchants were required to record their DSS compliance according to their annual volume of transactions. Largest merchants had to be on-site audited to verify merchant and processor compliance. Medium- or small-scale merchants were allowed to not be audited by self-assessments that attest to various security issues and implementation programs.

According to the DSS, the cardholder data is defined as a primary account number (PAN) that has been parsed (i.e., unencrypted) or encrypted. A DSS is a system that "processes, stores, or transmits" cardholder data and a system on the same network segment (eg, a plurality of subnetworks that make up the corporate network) I made clear that I should follow.

In addition, personally-identifiable information (PII) is subject to regulatory scrutiny, for example, by United States federal or state laws. The term PII is information that can be used to uniquely identify a person, to contact a person, to uniquely identify a person's location, or to identify the identity with other material. For example, in the 2007 memorandum by the Office of the President, Office of the Ombudsman (OMB) and the US government, PII information is referred to as "individual, individual, such as name, social security number, biometric records, Information or information that can be used to identify or identify an individual's identity in combination with other personal or identifiable information, such as a birth date, or maiden name of the mother ".

Likewise, the European Union has agreed that "personal information" in Article 2a of the EU directive 95/46 / EC should be replaced with "all information relating to identifiable or identifiable natural persons (" data subjects " Shall be defined as "one or more factors that can identify physical, physiological, mental, economic, cultural or social identities, or persons who are directly or indirectly identifiable on the basis of an identification number").

Similarly, the section on California data breach notification law (SB1386) states that "personal information" should be replaced with "the name of the individual associated with any of the following data (first name, first initial and last name (1) Social Security number, combined with the security code, access code, and password required when accessing a personal financial account; (2) a driver's license number Or California card number, (3) account number, credit card, number or debit card number).

All computer systems and enterprise data centers involved in the process of encrypted sensitive data, such as PCI and PII data, must comply with these standards and requirements by DSS compliance and regulatory requirements in various jurisdictions.

In order to solve the above problems, the present invention provides a data processing system such as a payment system including a tokenizer, such as a card encryption and storage system (CES) employing tokenized features do. In tokenization, instead of entering confidential information, such as a payment card account number, into an application module, such as a corporate resource management (ERP) system (e.g., SAP ERP), before the secret information is sent to the application module Confidential information is captured in the tokenizer and stored in the tokenizer. The tokenizer then retires a random string called "token " as a pointer to the original payment card number to the calling application. Since the token preferably does not have an algorithmic relationship with the original payment card number, the payment card number can not be known from the token itself, such as simply applying an encryption algorithm to the token. Therefore, since the original card holder's data can not be estimated from the random string without going through the tokenizer having the payment card number and the corresponding token, the token is not originally recognized as the card holder's data. Here, the tokenizer includes a payment card number and a corresponding token. .

Under the PCI DSS regulatory scheme, if cardholder data (including any plaintiff or encrypted payment card account number) is located on the application module alone or with the cardholder name, service code and / or expiration date, You must receive. Thus, the data of the cardholder can be replaced with a string rather than an account number, and then the host application is no longer in possession of the cardholder data and is therefore out of the scope of the PCI DSS regulatory audit.

In one embodiment, the present invention provides a first computer implemented method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer. The first computer-implemented method comprises the steps of: (a) receiving information for transaction execution including secret information manually input by a user; (b) the first computer sending the secret information to the third computer; (c) the first computer receiving a token from the third computer that has no algorithmic relationship with the secret information; And (d) transmitting, by the first computer, the transaction-performing information excluding the secret information to the second computer, and the token.

In another embodiment, the invention provides an apparatus for preventing secret information from being transmitted to a second computer in communication with the apparatus. (B) transmitting the secret information to the third computer; (c) receiving the secret information and an algorithm (D) transmitting the transaction-performing information excluding the secret information to the second computer and the token.

In yet another embodiment, the present invention provides a non-transitory machine-readable storage medium having encoded program code therein. The program code is executed by an apparatus and the apparatus for executing the program code implements a method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer. The method comprises the steps of: (a) receiving transaction enforcement information including secret information manually entered by a user; (b) the first computer sending the secret information to the third computer; (c) receiving, by the first computer, a token that is not algorithmically related to the secret information from the third computer; And (d) transmitting, by the first computer, the transaction-performing information excluding the secret information to the second computer, and the token.

In yet another embodiment, the present invention provides a first computer implemented method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer. The first computer implemented method comprising the steps of: (a) inspecting the entry field of the window of the software program to determine whether the entry field contains secret information; (b1) when the entry field contains secret information, (b1) the first computer sends the secret information to a third computer, (b2) the first computer is not in an algorithmic relationship with the secret information Receiving a token from the third computer; And (c) replacing said secret information in said entry field of said window of said software program with said token by said first computer.

In yet another embodiment, the present invention provides a first computer implemented method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer. The first computer implemented method comprising: (a) the first computer receiving one or more packet data from the first computer; (b) the first computer examines the one or more packet data to determine whether the one or more packet data includes secret information, wherein if the entry field includes the secret information, b1) the first computer sends the secret information to a third computer; (b2) the first computer receives a token that is not algorithmically related to the secret information from the third computer; (c) modifying said one or more packet data by said first computer by replacing said secret information in said one or more packet data with said token; And (d) the first computer communicating the modified one or more packet data to the second computer.

Conventionally, there is a risk of hacking because it can be easily decrypted because it is encrypted with a general-purpose encryption module without securing it with a token value having the same data field area at the time of logon or data input, and data fields of encrypted values are different from input data fields There is a problem that the data field size and the like have to be specifically modified in an application such as an external application or the like and a load is applied to an application module when encryption is performed in an application module without a separate external tokenizer.

To improve this, the present invention places a separate tokenizer,

① When logging on or inputting data (tokenizing request) from Web Store (110, Internet shopping mall) or desktop interface (145, user's desktop or other input kiosk)

② Tokenizer (120, corresponding to Token Server) tokenize these logon data or input data to a random value with the same data field without referring to a specific algorithm (referring to general purpose encryption module)

(3) The tokenized value in the tokenizer is transferred to the application module 150 (corresponding to the ERP server including SAP) through the web store or the desktop interface. Therefore, there is no fear of hacking, there is no need to modify the data field size, So that there is no occurrence.

Figure 1 is a block diagram illustrating an example of a first payment process system with tokenization according to one embodiment of the present invention.
2 is a flow chart illustrating an example of an algorithm of a token application in an embodiment of the present invention.
3 is a flow chart illustrating an example of an algorithm for a desktop token interface in an embodiment of the present invention.
4 is a flow chart illustrating another example of an algorithm for a desktop token interface in an embodiment of the present invention.
5 is a block diagram illustrating an example of a second payment process system with tokenization in accordance with one embodiment of the present invention.
6 is a flow chart illustrating another example of an algorithm for a packet inspector in an embodiment of the present invention.
7A to 7E are collective views showing an example of program codes for implementing the algorithm of Fig.
8A to 8C are diagrams showing an example of program codes for implementing the algorithm of FIG. 4 collectively.
9A to 9C are diagrams showing an example of program codes for implementing the algorithm of FIG. 6 collectively.

Figure 1 illustrates an example of a first payment process system 100 with tokenization in accordance with one embodiment of the present invention. The system 100 in this embodiment includes a tokenizer 120, a webstore 110, an input module 140, an application module 150, and a payment card and a middleware 130. The web store 110 is used by a purchaser who desires to purchase and the input module 140 is used by a customer service representative to input a customer's order. The tokenizer 120 generates a token from the payment card number and provides the token to the web store 110 and the input module 140. Application module 150 is a general industrial enterprise system that includes a token instead of a payment card number instead of a payment card number. Thereby, the payment card number is not inputted to the application module 150. [ The payment card middleware 130 receives settlement requests from the application module 150 in a token format (corresponding to the payment card number provided by the tokenizer 120) Quot; clear-card form "(e.g., the number of the card number described on the card itself) to the clearing house 160. [

When the payment card data is input via the web store 110 or input via the input module 140, the tokenizer 120 performs tokenizing before the payment card data is captured, Process to isolate and protect the data of the cardholder. Thus, the regulation audit of the application module 150 can be avoided.

The payment process system 100 is, for example, compliant with the PCI DSS. PCI DSS requires an " in-scope "system (i.e., a system that is within the regulatory scope of the PCI DSS) through which the rest of the enterprise network is isolated, for example through a firewall. The DSS requires that the Internet connected to the web server be also isolated. Thus, the payment process system 100 applies the following three 'in-scope' network segments or zones for PCU purposes: (i) a web server zone containing the web store 110, (ii) ) Input module 140, (iii) a PCI server zone that includes the tokenizer 120 and payment card middleware 130. Using these properly defined and defined three network segments and their corresponding functionality greatly simplifies PCI compliance and maintenance, as opposed to remediating or modifying large sections of the enterprise network And can be easily managed.

<Talker>

The tokenizer 120 includes one or more computers having a token database 122 and a token application 124. The token database 122 is implemented by, for example, a simple look-up table or a more complex database system (such as the Oracle database 10g from Oracle Corporation). The token database 122 includes an encrypted payment card number in its database and a token corresponding to the encrypted payment card number.

The token application 124 encrypts the received payment card number and generates a random token corresponding to the payment card number. In one embodiment, when the payment card number is "371449635398183 ", correspondingly the randomly generated token may be an alphanumeric string value of" Nc4.times.WKms. In another embodiment, a portion of the token may be part of a payment card number, e.g., a payment card type (the first two digits of the payment card number, 37 American Express, 40 Visa, Card and the last four digits may be part of the token itself. According to this, the customer and the buyer can generally confirm or identify whether the card corresponding to the token is correct. For example, if the payment card number is "371449635398183 ", the corresponding token may be" 37-Nc4.times.WKms-8183, ". Here, (i) the first two digits "37," the card type is American Express, (ii) the middle part of the token is a randomly generated alphanumeric string, (iii) the last four digits "8183, It can be used to identify the cardholder's card number.

The token application 124 is preferably implemented as a Java application so as to execute a platform by a Java Runtime Environment of Sun Microsystems, In most standard workloads (e. G., Less than 10 million payment card transactions a year), the token application 124 is a SunFire 4100 from Sun Microsystems, Inc., x3650, Dell, Inc.'s Poweredge 2950, and the like.

The token application 124 interfaces with the token database 122 to write information. For example, the token application 124 may attempt to write the encrypted payment card number and the newly generated token into the database 122 as a new entry. In one embodiment, a table stored in the token database 122 may include a table with entries having the following payment card number / token pair.

Payment card number The corresponding token 371449635398183 37-Nc4xWKms-8183 371449635398290 37-waPaPcx6-8290 4012000033330232 40-sdkKXnO8-0232 4012000033330497 40-dTXeX5NN-0497 5424180279790213 54-9HCF2NH2-0213 5424180279790494 54-2CZYVkSt-0494

The token application 124 may then access the token database 122 to read information from the token database 122 (e.g., to retrieve a payment card number based on a given token, or to retrieve a token for an already stored payment card number) &Lt; / RTI &gt; The token application 124 also interfaces with one or both of the web store 110 and the input module 140 using a secure-socket layer (SSL) protocol. For example, token application 120 may be used by web store 110 and input module (e. G., Web server 110) to respond to a request to create a new token, or to retrieve a token already generated based on a payment card number from token database 122 140). &Lt; / RTI &gt; Moreover, the token application 124 interfaces with the payment card middleware 130, for example, in response to a request to retrieve the payment card number based on the provided token.

For redundancy and stability, it is desirable that a plurality of token applications 124 run concurrently in the tokenizer 120. [ At this time, it is more preferable that at least two token applications 124 are executed in full-time. Here, one token application 124 may reside in a primary location and the other may reside in a backup location (e.g., another computer / processor). Similarly, it is preferred that the token database 122 is stored in one or more locations to provide redundancy, in which case the tokenizer 120 includes an initial database server in the initial location, And can be backed up by a recovery database server residing in the database.

To interact with source applications such as a web site and its associated applications (e.g., web store 110), the tokenizer 120 may include (i) a hypertext transfer protocol transport protocol, HTTP) or secure-HTTP (HTTPS) socket interface, and (ii) SSL socket interface. In this case, the tokenizer 120 uses two different APIs corresponding to these two interfaces. That is, (i) an HTTP API for delivering a pair (MIME Type URL Form Encoded) encrypted with a MINE type URL form, for example, a name-number pair (for example, "action = CE & data = 1234123412341234" (ii) For example, it is possible to use a socket API for transferring in a fixed format such as "FF0027CE01bbbbbb1234123412341234," " FF0027CE01bbbbbb1234123412341234, The reason for having two APIs is that the HTTP protocol uses the socket setup / teardown procedure for each transaction, while the socket connection Can be sustained in many transactions and is suitable for transactional interactions where a lot of transaction detokenization is required for a short time frame, such as using payment card middleware 130.

One request-response call from the web store 110 sends the payment card number to the tokenizer 120 in an unencrypted format and prior to passing the tokenized transaction to the application module 150, And receives a token corresponding to the payment card number from the tokenizer 120.

Referring to Figure 2, an algorithm 200 for the token application 124 according to an example is described. The algorithm is instantiated in step 201. [ At step 202 the token application 124 retrieves the input string from the calling module (e.g., web store 110, input module 140 and payment card middleware 130) Wait for reception. Then, at step 203, an input string is received from the calling module. Then, in step 204, it is determined whether the input string is a payment card number or a token. If the input string is determined to be a payment card number in step 204, the token application 124 proceeds to step 205. [ If the input string is determined to be a token in step 204, the token application 124 proceeds to step 206.

At step 205, the token database 122 performs a search to determine whether a payment card number already exists in the database. If it is determined in step 205 that the payment card number does not exist in the database, the token application 124 proceeds to step 209. [ If it is determined in step 205 that the payment card number is in the database, the token application 124 proceeds to step 211. [

At step 209, the token application 124 generates a token, preferably a random alphanumeric string. This alphanumeric string is not generated based on the payment card number and has no algorithm relation with the payment card number. Thus, the token can not be used to generate the payment card number without the tokenizer 120 in the future.

Then, at step 210, the token application 124 stores the payment card number along with the token in the token database 122 as an encrypted form. Then, at step 212, the token application 124 outputs the token to the calling module and returns to step 202. [

At step 211, the token corresponding to the payment card number is retrieved from the token database 122, and then the algorithm proceeds to step 212.

At step 206, the token database 122 performs a search to determine whether a token already exists in the database. If at step 206 it is determined that the token is not present in the database, then the token application 124 proceeds to step 202. If at step 206 it is determined that a token is present in the database, then the token application 124 proceeds to step 207. At step 207, the payment card number corresponding to the token is retrieved from the token database 122.

Then, at step 208, the token application 124 outputs the token to the calling module and returns to step 202. [

The PCI DSS specification requires applications to be isolated from database functions. Therefore, for compliance with the DSS, it involves a minimum configuration of four computers (application system and database system at the initial location, application system and database system at the backup location).

Because the tokenizer 120 functions appropriately for normal user privileges, other payment card applications may also be hosted on the four computer systems described above.

In another embodiment, the token application 124 may be a payment card middleware application instead of the payment card middleware 130, for example, and may remain in an isolated network segment to meet, for example, PCI DSS requirements.

<Enter payment card number>

The payment process system 100 can be used as a source of two possible payment card information: (i) an internet-facing website and associated cards (one-time pay or account-maintenance functions) (Ii) adopts a customer-service call or point-of-sale management, (ii) the end customer provides the cardholder's data to the customer service representative, and the customer service representative uses the cardholder The payment processing system 100 includes both the web store 110 and the input module 140 to realize this functionality. In another embodiment, the web store 110 and the input module (140) may be provided.

Web store 110 includes one or more computers having applications that are used by end customers (e.g., consumers who wish to make purchases from online web companies) who wish to purchase one or more goods and / or services. During payment of the transaction, web store 110 employs an application-programming interface (API) for transmitting payment card numbers to tokenizer 120. The tokenizer 120 returns the token for the web store 110 to be sent to the application module 150 along with other transaction data.

The input module 140 includes one or more computers having an order acceptance application interface (e.g., SAP graphical user interface (SAP GUI), or other software used by a buyer to enter customer data). In order to have the order accepted, the customer service representative uses the input module 140 at point of sale, for example, by telephone or face to face. The input module 140 includes a desktop token interface 145 that interfaces with the tokenizer 120. The desktop token interface 145 sends the payment card number to the tokenizer 120. The tokenizer 120 returns to send the token for the input module 140 to the application module 150 along with other transaction data.

 The input module 140 is preferably implemented in a customer-service workstation of a customer service center. The desktop token interface 145 may be an application in which a customer service representative manually enters (e.g., typing) the customer's payment card number. For example, the application may be a Microsoft Windows applet written in a Visual Basic programming language. The desktop token interface 145 uses the API to transmit the payment card number in an unencrypted format in the tokenizer 120. The tokenizer 120 encrypts and stores the payment card number in the token database 122 and returns the token corresponding to the card number to the desktop token interface 145. Next, the desktop token interface 145 stores the token in the window clipboard. (In other embodiments, a buffer may be used instead of the operating system clipboard in order to achieve a similar function.) Accordingly, the token is input into the appropriate entry-screen field located in the input module 140 Allowing a key stroke or mouse click for "paste &quot; Thus, the customer service representative can buy the desktop token interface 145 to tokenize the payment card number by just about four keystrokes or mouse clicks (in addition to the normally performed customer data entry).

Referring to FIG. 3, an algorithm 300 for the desktop token interface 145 is described. At step 301, the applet is started. Then, at step 302, the applet waits for a preset keystroke (e.g., ALT-F12) in the background to be depressed. For the purchase of a product or service, the keystroke will be pressed when a customer service representative using the order accepting software running on the input module 140 prepares to enter the payment card number. Instead of directly entering the payment card number into the order acceptance software (which may cause the order accepting software to undergo regulatory compliance), the customer service representative may use a preset keystroke to activate the applet.

Then, at step 303, a relatively small entry window is displayed on the screen of the customer service representative (e.g., above or adjacent to the order entry software window). It is preferable that the entry window has a single input field. The window may include a clickable 'submit' button. The customer service representative types the customer's payment card number into the input field of the entry window and presses the input key (or clicks the 'submit' button if there is one).

Then, at step 304, the customer's payment card number is received in an unencrypted format from the entry field of the entry window. Then, in step 305, it is determined whether the entered payment card number is a valid card number using, for example, a Luhn check (also called a Mod 10 check).

If it is determined in step 305 that the card number is not valid, then in step 306 an error message is displayed on the screen of the customer service representative and the applet returns to step 302. If it is determined in step 305 that the card number is valid, the algorithm proceeds to step 307. [

At step 307, a tokenization request containing a payment card number is transmitted to the tokenizer 120 (which returns a token corresponding to the payment card number) via a socket encrypted using the HTTPS protocol. At step 308, a token is received from the tokenizer 120. Then, in step 309, the token is copied to the Windows OS (Operating System) clipboard. The token may be displayed on the screen of the customer service representative to verify that the tokenization was successful. At step 309, the applet returns to step 302. At this time, the token can be stored in the Windows OS clipboard.

The customer service representative then changes the application focus from the applet window to the order acceptance software window. (It is known that in certain embodiments where the applet closes the entry window when the token is created, this process is not necessarily necessary because the application window is automatically closed and the application focus is returned to the order entry software window.) Next, The customer service representative pastes the token from the Windows OS clipboard into the payment card number field of the order acceptance software. This may be accomplished, for example, by a mouse control (e.g., right clicking, then clicking "Paste" from the drop-down menu) or keystroke (e.g., CTRL-V) . Then, for the process, the customer service representative submits the order to the application module 150 by pressing the &quot; send &quot; button of the order entry software window.

In the above case, the application module 150 does not input a payment card number in an unencrypted format, so that the application module 150 does not have to undergo a regulation audit.

A more detailed description is given in Figs. 7A to 7E showing an example of visual basic program code for the realization of the algorithm 300 of Fig.

In this embodiment, an example of the algorithm 300 of the desktop token interface 145 requests the token from the tokenizer 120 manually by the customer service representative, as described above. Next, the token is manually pasted into the field in the input module 140 filled with the unencrypted payment card number before clearing house transaction.

In another embodiment described later, the desktop token interface 145 automatically extracts the payment card number entered in the field in the input module 140 by the customer service representative in an unencrypted format. The desktop token interface 145 then requests the token from the tokenizer 120 and replaces the un-encrypted payment card number with a token before the clearinghouse transaction is made.

Referring to FIG. 4, an algorithm 400 for a desktop token interface 145 according to another embodiment is described. Unlike algorithm 300 is implemented in a Windows applet, algorithm 400 is implemented in a script. For example, SAP ERP software employs a Windows application front-end interface called SAP GUI. SAP GUI provides a way for SAP customers to develop scripts to extend the capabilities of SAP ERT. Thus, the algorithm 400 is preferably implemented in the SAP GUT script in the input module 140.

In this case, the customer service representative uses the SAP GUI order acceptance application interface executed in the input module 140 to purchase the goods or services. The customer service representative receives the customer's order and enters all of the appropriate order information (including the customer's payment card number) into the standard order screen (e.g., VA01 Create Sales Order screen). After entering all the order information, the buyer presses the "save" icon on the standard order screen. Normally, pressing 'Save' saves all information in the order screen, including the payment card number in an unencrypted format. This information is submitted to the application for the process, which requires the application module to receive regulatory audits. However, in this embodiment, when 'save' is pressed, the SAP GUI script starts a script that implements the algorithm 400 before the information is sent to the application 150.

At step 401, the script starts. Then, at step 402, the script determines whether the order screen form contains all the fields present in the standard order screen form to find one or more fields named CCNUM, to determine if there is a field where the payment card number is located (Or use other criteria in which fields with payment card numbers in an unencrypted format are located). If it is determined in step 402 that the custom screen form does not include a field having a payment card number in an unencrypted format, the script proceeds to step 405. At step 405, an error message is displayed on the screen of the customer service representative, and the script then leaves the error condition at step 410. If it is determined in step 402 that the custom screen form includes a field having a non-encrypted payment card number, the script proceeds to step 403.

At step 403, the script reads the payment card number in an unencrypted format from the field of the order screen form. Then, in step 404, it is determined whether the entered payment card number is a valid card number using, for example, Luhn check (or called Mod 10 check). If it is determined at step 404 that the card number is not valid, then at step 405 an error message is displayed on the screen of the customer service representative, and then the script leaves the error condition at step 410. If it is determined in step 404 that the card number is valid, the algorithm proceeds to step 406. [

At step 406, the tokenization request with the payment card number is transmitted to the tokenizer 120 (which returns the token corresponding to the payment card number) over the socket encrypted using the HTTPS protocol.

Then, at step 407, the token is received from the tokenizer 120. [ Then, at step 408, the script removes the un-encrypted payment card number from the order screen form and replaces it with the received token.

Then, in step 409, it is determined whether there is an additional payment card number in the order screen form. In this case, the script returns to step 403 to process the payment card number found on the order screen form. Otherwise, the script proceeds to step 411.

At step 411, the script submits to the application module 150 all information (including tokens that replace the unencrypted payment card number) located in the order screen form. Then, at step 412, the script comes out of a success condition.

If, at step 410, the script has an error condition, the customer service representative returns to the entry screen to correct the error (e.g., provide a missing payment card number or correct an invalid payment card number). If an appropriate correction is made, the customer service representative presses "save" for the retry, and the algorithm 400 is initialized once again.

In the above case, it is not necessary for the customer service representative to activate the applet manually or to paste the token into any application (in the case of algorithm 300). And the whole tokenization process can happen at the same time, and can happen in the background without any special knowledge or action in the part of the customer service representative.

A more detailed description is shown in Figs. 8A-8C showing an example of visual basic program code for the realization of the algorithm 400 of Fig.

<Application module>

The application module 150 is a commercial enterprise system that includes one or more computers including software for performing purchase orders, tracking, payment, account settlement, and related functionality. The system may be, for example, the trade name mySAP business suite software from SAP Americas, located in Newtown Square, Pennsylvania.

The application module 150 may receive a tokenization request from the web store 110 using an API capable of accessing functions in the application module 150, such as, for example, the SAP Business Application Programming Interface (BAPI) Lt; / RTI &gt; Alternatively or additionally, the application module 150 can be accessed using a universal client interface (e.g., SAP GUI) in the input module 140, which can access functions within the application module 150 150 receives a tokenized customer service transaction and an account updater from the input module 140. The application module 150 sends the tokenized request for authorization and payment to the payment card middleware 130 and receives the tokenized response for the above described requests from the payment card middleware 130. [ At this time, for example, a standard interface (for example, an SAP remote function call (RFC)) for communicating with the application module 150 may be used.

Since the application module 150 does not process, transmit, or store PCI or PII data, it does not need to be subjected to a regulation audit. Transactions that occur between the application module 150 and the web store 110 and / or the input module 140 all have a tokenized form and do not have PCI or PII data. Similarly, authorization and payment transactions between application module 150 and payment card middleware 130 also have a tokenized form and do not have PCI or PII data. This structure can be referred to as the 'pre-capture tokenization' approach. Thereby, all of the front-end sources of the entries for the payment card accounts, before delivering the transactions to the back-end system (e.g., application module 150) for the process, (E.g., web store 110 and input module 140) tokenize the payment card number in an unencrypted format.

<Payment Card Middleware>

Payment card middleware 130 includes one or more computers having software for receiving and responding to and requesting tokenized authorizations and payments from application module 150. [ And a request including a token provided to retrieve the corresponding payment card number from the database 122. [ Through the SSL interface, which sends a request for tokenization using the provided token and receives a response to a request for a payment card number in the unencrypted form, the payment card middleware 130 interfaces with the tokenizer 120 do. For example, using SSL or leased line, the payment card middleware 130 may send a request to the clearinghouse 160 (e. G., &Lt; RTI ID = 0.0 &gt; For example, an automated clearing house (ACH) payment system.

Payment card middleware 130 may include card processing software (e.g., PPS PayWare, a product of Princeton Payment Solutions). One embodiment of the payment card middleware 130 may be token-aware. That is, the payment card middleware 130 can identify the token and the payment card number in an unencrypted format. In this way, if the payment request has a payment card number in an unencrypted format, the payment card middleware 130 makes a clearing transaction request to the clearing house 160 using the tokenizer 120. However, if the payment request has a token instead of the payment card number, the payment card middleware 130 uses the tokenizer 120 to obtain the corresponding payment card number before making a clearing house transaction request to the clearing house 160. [ Accordingly, payment card middleware 130 may be used as middleware to process both tokenized and non-tokenized transactions from applications other than application 150. [

<Mass data transfer>

In addition to using the payment card data entry and processing the point-in-time of purchase, the payment process system 100 according to the embodiment may be configured to send a large amount of cardholder data stored in a commercial enterprise system table (e.g., SAP BSEGC or FPLTC table) Can be used to transport the material to the niger 120. In this case, a module (e.g., payment card middleware 130) of one or more of the tokenizers 120 may provide software to transfer data. In order to avoid locked payment card entries in the source table, this transfer may be performed when there are no valid payment transactions. However, the present invention is not limited to this, and the transferring routine can be performed at one or more additional times at which the transfer of the locked table entry can be secured while the previous transferring routine is executed. If the payment card middleware 130 automatically identifies the token and the payment card number in an unencrypted format, as described above, one is automatically returned and the other is provided. Then, the transfer of tokens can be performed in a downtime where a minimal commercial enterprise system is not operational.

<Packet Inspector>

Referring to Figures 5 and 6, a payment process system 500 according to a second embodiment is described. The payment process system 500 is similar to the payment process system 100 except as described below.

5 is a diagram of a payment process system 500 with tokenization, in accordance with an embodiment of the present invention. 5, instead of the desktop token interface, the payment process system 500 may include a packet inspector 545 (e.g., BIG-IP Local Traffic Manager under the trade name F5 Networks or BIG-IP Global Traffic Manager) Tokenize. In the payment process system 500, all packets (e.g., TCP / IP packets) from the input module 540 pass through the packet inspector 545 before being forwarded to the application module 550. The packet inspector 545 corrects the contents of a certain packet before delivering them. This will be described in more detail later.

The packet inspector 545 receives a packet containing the non-tokenized transaction from the input module 540, checks all incoming packets to look for a payment card number in an unencrypted form, 550). &Lt; / RTI &gt; The packet inspector 545 tokenizes the payment card number by transmitting to the tokenizer 520 the payment card number in an unencrypted format. The tokenizer 520 encrypts and stores the payment card number in the token database 522, and returns the token corresponding to the card number to the packet inspector 545. The packet inspector 545 replaces the un-encrypted type of payment card number found in the packet passing through the packet inspector 545 with a token before they are transmitted to the application module 550. Thus, packets containing transactions, sent to the application module 550, have only tokenized transactions.

6, an example of an algorithm 600 for the packet inspector 545 will be described. The algorithm 600 may be implemented in a script executed in the packet inspector 545 (e.g., tool command language (TCL) used in the BIG-IP product series of F5 Networks, Inc.). This script can access all traffic passing through the packet inspector 545 and can examine and change all data passing through the packet inspector 545. [

In step 601, a script is started. Then, at step 602, a packet arriving at the packet inspector 545 is received. Then, at step 603, the script checks the packet to determine if the quote page from which the packet originated is a &quot; target &quot; web page. The target web page is a web page that is known or expected to request a payment card number from a customer service representative. This is done by comparing the referer field in the HTTP header (the web page from which the packet originated) with a known target web page. If it is determined in step 603 that the packet did not come from the target web page, the script returns to step 602 to receive the next packet. In step 603, if it is determined that the packet comes from the target web page, the script proceeds to step 604.

At step 604, the script checks the packet to determine if a field named CCNUM exists (or uses another criteria in which there is a field with an unencrypted form of payment card number). The presence of that field means that it contains at least one packet with a payment card number. At step 604, if it is determined that the packet does not have a field with an unencrypted payment card number, the script returns to step 602 to receive the next packet. If it is determined in step 604 that the packet has a field with an unencrypted payment card number, the script proceeds to step 605. [

At step 605, the script reads the payment card number in an unencrypted format from the field of the packet. Then, in step 606, it is determined whether the payment card number is a valid card number (for example, Luhn check (also called Mod 10 check)). If it is determined at step 606 that the card number is not valid, the script returns to step 602 to receive the next packet, since there is no actual card number for which tokenization is required. If it is determined in step 606 that the card number is valid, then in step 607, a tokenizing request that includes the payment card number via the encrypted socket using HTTPS returns a token corresponding to the payment card number To-talker 520. &lt; / RTI &gt;

Then, at step 608, a token is received from the tokenizer 520. Then, at step 609, the script deletes the un-encrypted payment card number in the field of the packet and replaces it with the received token.

Then, in step 610, it is determined if there is an additional payment card number in the packet. In this case, the script returns to step 605 to process the next payment card number found in the packet. Otherwise, the script proceeds to step 611.

In step 611, the modified packet having the token that replaces the payment card number in the unencrypted form is transmitted to the application module 150. [ The script then returns to step 602.

A more detailed description is given in Figs. 9A-9C showing an example of TCL program code for the realization of the algorithm 600 of Fig.

&Lt; Alternative Embodiments and Modifications >

In order to explain essential parts of the present invention, those skilled in the art will be able to make various changes to the details, materials, arrangements and the like of the constitution shown in the above description and drawings without departing from the scope of the present invention It can be seen that

For example, the content of embodiments of the present invention may be applied to other systems that use secret information as well as the payment process system.

Thus, although the embodiments described above are directed to a payment processing system using tokens as a replacement for payment card numbers, it should be understood that the present invention includes the use of tokens as alternatives to other information stored separately from one or more applications something to do. Accordingly, the present invention may include an age verification system using a driver's license, a medical record management system, etc., in addition to the payment process system. Such information may include payment card number and other payment related information (e.g., bank account number, credit card number, debit card number, security code, access code, password) or other identification information A driver's license number, a national or school-issued identification number, physiological information, a date and place of birth, mother's marital status, etc.). And the term " confidential information &quot; should be understood to include all the other information described above if it is kept separate from one or more applications (computer or computer system). It should also be understood that the term "transaction" includes all transactions that apply secret information. For example, the confidential information may be medical-insurance transactions, age verification transactions, transaction identification transactions, and the like. The medical-insurance transaction may be used by the healthcare provider to pay the patient insurance company, and so on. The age confirmation transaction may be for checking the age of a customer who purchases a liquor using a driver's license, and the like. Transactions for transaction identification may be a social security number identification system or the like.

Typically, if encryption is used to protect data representing secret information, the encrypted string or number has a value that is larger than the data that originally referred to the secret information. When the ERP application restricts the size and / or type of data such as a social security number having a predetermined format to a predetermined format, the encrypted process has a larger value than the assigned field. This makes it difficult or impossible to re-introduce the encrypted value into the original field. However, the tokenizer of the embodiment of the present invention uses a token having a predetermined format as a substitute for secret information. That is, tokens having a predetermined length or type may be generated.

For example, if the tokenized secret information is a nine-digit social security number, a random token with nine digits may be generated in place of the actual social security number. Thus, the token can be used within the original social correction number field. Thus, in an embodiment of the present invention, the token can have a predefined and constant formatted value, replacing conventional software applications that require regulatory auditing.

Here, the term &quot; random &quot; should be understood to include pseudo-randomly-generated alphanumeric strings, as well as complete random selection or complete random character and / or number generation. The pseudo-random generation may include seed-based selection or generation of seed-based characters and / or numbers, and generation of another selection or character and / or number that may make it appear random, do. A hashing function may be used in embodiments of the present invention. Such a hashing function may be based on a combination of a random number, a non-random number, a random number and a non-random number, if not based on the secret information itself. The term &quot; random &quot; should be understood to include an alphanumeric sequence that is not random (unless it has an algorithmic relationship with secret information).

Here, the term "packet inspector" is used to receive packet data, examine its contents, selectively modify its contents, and forward this packet to other hardware and / or software systems for further processing Hardware and / or software. In one embodiment, the packet inspector is implemented entirely in software. And the packet inspector may remain within a general purpose computer (e.g., a computer such as input module 540) or other computing device. In another embodiment, the packet inspector may be a separate dedicated hardware packet inspection device. The packet inspector used in embodiments of the present invention may include other functions such as load-balancing or system fail-over protection.

The term &quot; module &quot;, as used herein, refers to an application-specific integrated circuit (ASIC), an electrical circuit, a processor (shared, dedicated or grouped) executing one or more software or firmware programs, a combinational logic circuit , And / or other suitable configurations for providing the functions described above.

The invention may be embodied in the form of a method or apparatus for carrying out the method. The present invention may also be embodied in the form of program code embodied in tangible media or non-transitory machine-readable storage media. The tangential media may be magnetic recording media, optical recording media, solid state memory, floppy diskettes, CD-ROMs, hard drives, and the like. When the program code is loaded into and executed by a device such as a computer, the device, such as the computer, may be an apparatus that implements embodiments of the present invention. The present invention may be embodied in the form of program code stored in a non-volatile, machine-readable storage device, which may, for example, be loaded into and executed in a device such as a computer. An apparatus such as the computer can be an apparatus that implements embodiments of the present invention. When implemented in a general purpose computer, the program code segment couples with the processor to provide a unique device that similarly implements a particular logic circuit.

The present invention may be implemented in the form of a sequence of signal values or a bit stream stored in a non-transitory recording medium created using the method and / or apparatus of the present invention.

One or more distributed computer program processes, data structures, dictionary (s) stored on one or more general purpose computers, mainframes, minicomputers, conventional telecommunications, memory storage means and storage devices, networked through conventional network hardware and software dictionary and / or other data may be implemented as described above. Nevertheless, other types of computer and network resources may be used in the present invention. The above-described conventional network hardware and software may be, for example, a LAN / WAN network backbone system and / or the Internet. The above-described general-purpose computer may be, for example, an IBM-compatible, Apple Macintosh, and / or RISC microprocessor-based computer. The above-mentioned telecommunication may be, for example, a modem, T1, fiber optic line, DSL, satellite and / or ISDN communication. The above-mentioned memory storage means may be, for example, a RAM or a ROM. The above-described storage device may be, for example, a computer-readable memory, a disk array, or a direct access storage. One or more of the networks described herein may be implemented within a wide area network such as a local area network, a wide area communication network, the Internet, an intranet, an extranet, a proprietary network, a virtual private network, a TCP / IP based network, , IEEE 802.11 or Bluetooth), an email-based network of email senders and recipients, a modem-based or cellular telephone network, an interactive telephonic network that can be accessed by a user using a telephone, or a combination thereof.

The embodiments of the invention described above are implemented by one or more computers that remain in the network transaction server system. In real-time transactions and / or batch-type transactions, input / output access is performed with appropriate hardware and software to allow user data transmission and reception and enable unattended execution of diverse operations. . Suitable hardware and software may be, for example, a personal computer and / or a mainframe computer supplied to the Internet wide area network communication hardware and software. The Internet broadband network communication hardware and software may include, for example, CQI-based, FTP, Netscape Navigator (trademark), Mozilla Firefox (trade name), Microsoft Internet Explorer (trade name), or Apple Safari , And / or a direct real-time or near-real-time TCP / IP interface that accesses real-time TCP / IP sockets. Similarly, the system of the present invention may include a remote Internet-based server accessible via conventional communication channels using one or more conventional browser software. The conventional browser software may be, for example, Netscape Navigator, Mozilla Firefox, Microsoft Internet Explorer, or Apple Safari. The conventional communication channel may be, for example, conventional telecommunication, broadband communication, or wireless communication. Thus, the present invention may suitably include such communication functionality and Internet browsing capabilities. Moreover, the various configurations of the server system of the present invention may be remote from each other, and may further include appropriate communication hardware / software and / or LAN / WAN hardware and / or software to achieve the functions.

Each functional configuration of the present invention may be implemented by one or more distributed computer-program processes running on one or more general purpose computers that are networked together by conventional network hardware and software. Each functional configuration may be implemented by executing a distributed computer-program process on a networked computer. Here, the networked computer may be, for example, a mainframe, and / or a symmetric or massively-parallel computer system, such as IBM SB2 (trade name) or HP 9000 (trade name). At this time, the networked computer may have an appropriate mass storage and other hardware / software that allows a functional configuration to perform the above-mentioned functions. The distributed computer-program process may be implemented using any of a variety of methods, including, for example, IBM DB2 (trade name), Microsoft SQL Server (trade name), Sybase SQL Server (trade name), or Oracle 10g Quot; full-scale "relational database engine, such as &lt; / RTI &gt; These computer systems may be geographically dispersed and connected by appropriate wide area or local area network hardware and software. In one embodiment, data stored in the token database or other program data may be accessed by the user through standard SQL queries for analysis and reporting purposes.

The basic configuration of an embodiment of the present invention may be server based, which may remain in hardware supporting an operating system such as Microsoft Windows NT / 2000 or UNIX.

The configuration of the system according to the present invention may be a mobile and a non-mobile device. A mobile device that may be applied to the present invention may include a personal digital assistant (PDA) style computer and other computers in conjunction with a wireless or portable telephone, one-way or two-way paging and messaging device, . The wireless or portable telephone may be a GSM telephone, a 2ME and WAP-enabled telephone, an Internet enabled telephone and a data-smart phone. The PDA style computer may be, for example, a PDA style computer manufactured by Apple Computer Corporation of Cupertino, California, or Palm, Inc of Santa Clara, California. The other computer may be a computer running an Android, a Symbian, a RIM Blackberry, a Palm web OS, or an iPhone operating system, a Windows CE (trade name) A handheld computer, or other handheld computer (which may include a wireless modem). Other telephone network technologies used in the service channels available for the system according to embodiments of the present invention include 2.5 G cellular network technology (such as GPRS and EDGE), 3G technology (CDMA1.times.RTT and WCDMA2000), and 4 G technology. Although a mobile device is used in the present invention, a non-mobile communication device may be considered by embodiments of the present invention. Non-mobile communication devices are personal computers, Internet devices, set-top boxes, landline phones, and the like. In addition, customers will be able to interact with personal computers running Apple Macintosh, Microsoft Windows 95/98 / NT / ME / CE / 2000 / XP / Vista / 7, UNIX Motif workstation platforms, or TCP / You can have another computer available. In an embodiment, software other than a web browser does not require a customer platform.

Optionally, the functional configuration may be implemented by a plurality of individual computer processes running on an IBM-type, Intel Pentium (trade name), RISC microprocessor-based personal computer. The individual computer processes may be generated through, for example, dBase (product name), Xbase (trade name), MS Access (trade name) or other "flat file" type database management system or product. The personal computer may be networked by conventional network hardware and software, and the functional configuration may include other separate hardware and software needed to accomplish the function. In this optional configuration, a non-relational database is used to represent at least a portion of the data stored by the system of the present invention, because the personal computer is not generally capable of executing a full-scale relational database engine of the type described above. A single layer file "table" (not shown) may be included in the networked at least one personal computer. These personal computers can run Unix, Microsoft Windows NT / 2000 (trade name), or Windows 95/98 / NT / ME / CE / 2000 / XP / Vista / 7 (trade name) operating systems. The functional configuration of the above-described system may include a combination of the above two configurations. For example, by a computer program process running on a personal computer, a RISC system, a mainframe, a symmetric or parallel computer system, and / or a combination of appropriate hardware and software networked together through appropriate wide area and near- A functional configuration can be implemented.

Further, the system of the present invention may be a larger computerized financial transaction system, including a multi-database or multi-computer system, or a 'warehouse'. Statistical and search solutions for the entire information management, processing, storage, search, special lockbox service providers, e-payment warehouse, biller organization, financial institution, Processing systems and / or storage methods, etc., in addition to the configurations of the present invention, for example, to achieve payment systems, commercial banks, and / or for cooperation or networking of such systems. The processing system may be, for example, a transaction, financial, management, statistics, data extraction and audit, data transmission / reception and / or accounting support and service system.

In one embodiment, the source code may be written into an object-oriented programming language using a relational database. Such an embodiment may include a programming language such as C ++ and a toolset such as Microsoft's Net (trade name) framework. Other programming languages that may be used in the system of the present invention include Java, HTML, Perl, UNIX shell scripting, assembly language, Fortran, Pascal, , Visual Basic, and QuickBasic. The present invention is implemented by hardware, software, or a combination of hardware and software.

Thus, the term "computer" as used herein refers to a combination of hardware and software, including at least one machine having a processor and appropriate instructions to control the processor. The term "computer" is used herein to refer to one or more computer devices (e.g., multi-personal computers), or one or more other devices (such as routers, hubs, packet-inspection appliances, firewalls, etc.) Quot;). &Lt; / RTI &gt;

A system consistent with the present invention may interact with a payment network, e.g., an ACH, that has already been implemented to provide options in payment. The options may be, for example, ACH, credit card payment, procurement card payment, and / or paper storage. And they may be generated internally or generated by an external software module. Here, the output file can be generated in a format that can be read by the external module. Payment by a payment system user using a credit card or procurement card, processed by the Internet or other means, may be effected. In this case, an additional level of security may be included and may further include appropriate payment card process capability to handle such functionality. The security level may be, for example, to authorize a credit card or debit card payment to be a credit card or debit card payment.

It is to be understood that within the scope of the present invention, one or more functional configurations may optionally be separated from the customer, dedicated electronic hardware and / or software. Accordingly, the present invention encompasses such various modifications, modifications, and equivalents.

Unless otherwise expressly stated, the numbers or ranges should be understood roughly as if preceded by "approximately" or "approximately".

Steps in one example of a method are not limited to being performed in the specific order described. The order of the steps in the method can be understood simply as an example. Similarly, additional steps may be included in the method if the various embodiments of the present invention are met, and certain steps may be omitted or combined.

In the following method claims, even though each configuration is labeled in a particular order by a claim, such configurations are not limited to being performed in that particular order.

The term "one embodiment" means a particular technical feature, structure, or characteristic associated with an embodiment that may be included in at least one embodiment of the invention. The term &quot; one embodiment &quot; frequently referred to in the specification is not required to refer to the same embodiment, and the separate or alternative embodiments do not exclude different embodiments.

Claims (23)

A first computer implemented method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer,
(a) receiving, by the first computer, transaction execution information including secret information manually input by a user;
(b) the first computer sending the secret information to the third computer;
(c) the first computer receiving a token from the third computer that has no algorithmic relationship with the secret information; And
(d) transmitting, by the first computer, the transaction-performing information excluding the secret information to the second computer; / RTI &gt;
The method according to claim 1,
Wherein the first computer includes a first software program that interfaces with the second computer and a second software program that is different from the first software program,
Wherein the second software program interfaces with the third computer rather than the second computer.
3. The method of claim 2,
Wherein the step (a) comprises the steps of: (a1) receiving the transaction execution information except for the secret information, by the first software program; And (a2) receiving, by the second software program, the secret information manually input by the user,
Wherein the step (b) includes the step of the second software program transmitting the secret information to the third computer,
Wherein the step (c) includes the step of the second software program receiving the token from the third computer,
The step (d) may further include the step of transmitting the transaction-performing information excluding the secret information to the second computer, and transmitting the token to the second computer
/ RTI &gt;
The method of claim 3,
Further comprising the second software program buffering the token in a buffer,
Before the step (d), the user pastes the token from the buffer into the entry field of the first software program.
5. The method of claim 4,
Wherein the buffer is an operating-system clipboard of the first computer.
The method of claim 3,
Wherein the step (a2) includes the steps of: the first software program causing the first computer to receive the secret information by the user typing the secret information into an entry field of a window displayed by the second software program; Implementation method.
3. The method of claim 2,
Wherein the step (a) includes receiving, by the first software program, the transaction-performing information including the secret information,
Wherein the step (b) comprises the steps of: (b1) inspecting an entry field of a window of the first software program including the secret information, and receiving the secret information from the first software program ; And (b2) the second software program transmitting the secret information to the third computer,
(C) the second software program receiving the token from the third computer; And (c2) replacing the secret information in the entry field of the window of the first software program by the second software program with the token,
Wherein the step (d) includes transmitting the to-be-executed information and the transaction-performing information except for the secret information by the first software program.
The method according to claim 1,
The first computer comprising:
A software program for interfacing with the second computer; And
A packet nspector for receiving packets from the software program, for forwarding the packets to the second computer, and for selectively modifying one or more of the packets before delivering the packets to the second computer; / RTI &gt;
9. The method of claim 8,
Wherein the step (a) includes receiving, by the software program, the transaction-performing information including the secret information,
The step (b) includes the steps of: (b1) receiving, by the packet inspector, one or more packet data from the software program, the secret information; And (b2) the packet inspector transmitting the secret information to the third computer,
(C) the packet inspector receiving the token from the third computer; And (c2) modifying the one or more packet data by the packet inspector replacing the secret information in the one or more packet data with the token,
Wherein the step (d) comprises the step of the packet inspector transmitting the modified one or more packet data to the second computer,
Wherein the modified at least one data packet includes information for performing transactions excluding the secret information and the token.
10. The method of claim 9,
Wherein the packet inspector is a dedicated hardware appliance having a processor and a processor executing the software program.
An apparatus for preventing secret information from being transmitted to a second computer communicating with the apparatus,
The apparatus,
(a) receiving transaction execution information including secret information manually input by a user,
(b) transmitting the secret information to the third computer,
(c) receiving, from the third computer, a token that is not algorithmically related to the secret information,
(d) transmitting the transaction-performing information and the token to the second computer, excluding the secret information.
12. The method of claim 11,
A first software program that interfaces with the second computer; and a second software program that is different from the first software program,
Wherein the second software program interfaces with the third computer rather than the second computer.
13. The method of claim 12,
Wherein the step (a) comprises the steps of: (a1) receiving the transaction execution information except for the secret information, by the first software program; And (a2) receiving, by the second software program, the secret information manually input by the user,
Wherein the step (b) includes the step of the second software program transmitting the secret information to the third computer,
Wherein the step (c) includes the step of the second software program receiving the token from the third computer,
Wherein the step (d) comprises transmitting the to-be-executed information and the transaction-performing information excluding the secret information to the second computer.
14. The method of claim 13,
The second software program being configured to buffer the token in a buffer,
Before the step (d), the user pastes the token from the buffer into the entry field of the first software program.
15. The method of claim 14,
Wherein the buffer is an operating-system clipboard of the first computer.
14. The method of claim 13,
Wherein the step (a2) comprises receiving the secret information by the second software program by the user typing the secret information into an entry field of a window displayed by the second software program.
13. The method of claim 12,
Wherein the step (a) includes receiving, by the first software program, the transaction-performing information including the secret information,
The step (b) includes the steps of: (b1) inspecting an entry field of a window of the first software program including the secret information, and receiving the secret information from the first software program; And (b2) the second software program transmitting the secret information to the third computer,
(C) the second software program receiving the token from the third computer; And (c2) replacing the secret information in the entry field of the window of the first software program by the second software program with the token,
Wherein the step (d) comprises transmitting the transaction-performing information except for the secret information, and the token.
12. The method of claim 11,
The apparatus,
A software program for interfacing with the second computer; And
And a packet inspector to receive packets from the software program, convey the packets to the second computer, and selectively modify one or more of the packets before delivering the packets to the second computer.
19. The method of claim 18,
Wherein the step (a) includes receiving, by the software program, the transaction-performing information including the secret information,
The step (b) includes the steps of: (b1) receiving, by the packet inspector, one or more packet data from the software program, the secret information; And (b2) the packet inspector transmitting the secret information to the third computer,
(C) the packet inspector receiving the token from the third computer; And (c2) modifying the one or more packet data by the packet inspector replacing the secret information in the one or more packet data with the token,
Wherein the step (d) comprises the step of the packet inspector transmitting the modified one or more packet data to the second computer,
Wherein the modified at least one data packet includes information for performing transactions excluding the secret information and the token.
20. The method of claim 19,
Wherein the packet inspector is a dedicated hardware appliance having a processor different from the processor executing the software program.
A non-transitory machine-readable storage medium having internally encoded program code, the non-transitory machine-
The program code is executed by the apparatus,
The apparatus for executing the program code implements a method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer,
The method comprises:
(a) receiving transaction execution information including secret information manually input by a user;
(b) the first computer sending the secret information to the third computer;
(c) receiving, by the first computer, a token that is not algorithmically related to the secret information from the third computer; And
(d) the first computer transmits to the second computer the transaction-performing information excluding the secret information, and the token
A non-transitory, machine-readable storage device comprising:
A first computer implemented method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer,
(a) the first computer examines the entry field of the window of the software program to determine whether the entry field contains secret information;
(b1) when the entry field contains secret information, (b1) the first computer sends the secret information to a third computer, (b2) the first computer is not in an algorithmic relationship with the secret information Receiving a token from the third computer; And
(c) replacing the secret information in the entry field of the window of the software program by the first computer with the token
/ RTI &gt;
A first computer implemented method for preventing secret information from being transmitted between a first computer and a second computer communicating with the first computer,
(a) the first computer receiving one or more packet data from the first computer;
(b) the first computer examines the one or more packet data to determine whether the one or more packet data includes secret information, wherein if the entry field includes the secret information, b1) the first computer sends the secret information to a third computer; (b2) the first computer receives a token that is not algorithmically related to the secret information from the third computer;
(c) modifying said one or more packet data by said first computer by replacing said secret information in said one or more packet data with said token; And
(d) the first computer communicating the modified one or more packet data to the second computer
/ RTI &gt;

Images