KR20180029227A - Security and user authentication for electronic transactions - Google Patents

Abstract

Systems and methods for generating, propagating, controlling and processing security codes of limited lifetime are used for electronic financial transactions, such as payment transactions in particular, to authenticate users. It is contemplated to provide a single security code that can be used across multiple accounts or other security systems, each with a limited lifetime. Each security code is a random number from a random number generator. Each security code for each user corresponds to a security code validity period of each limited duration. Thus, a table or matrix is generated that associates a plurality of users with each respective set of randomly selected security codes (each having respective validity periods), and this matrix is associated with each of the entities, And is provided to each user. At the same time, at least a current security code is provided for each of the users, and each entity being accessed can track which code from which user is currently valid.

Description

Security and user authentication for electronic transactions

The present invention most generally relates to user authentication as a prelude to get an electronic transaction with an entity of some type of access. More particularly, the present invention relates to systems and methods for electronic transactions and other secure electronic access by the use of security codes generated and managed as disclosed herein.

One of the most important examples of reliable user authentication is electronic payment transactions.

Credit, debit and prepay online card fraud are increasing as online shopping and third party payment transactions increase. New technologies address "card present" fraud at Merchant Point of Sale (POS) terminals through the use of EMV (Europay, Mastercard, and Visa - ie "chipped" cards) However, current security measures against online "Card Not Present" (CNP) fraud issues are insufficient.

CNP fraud is expected to have double digit growth for online fraud credit card purchases over the next decade, with US fraud losses growing by as much as $ 2.8 billion in 2013 for credit card transactions, It is estimated to be up to $ 100 million.

Debit and prepay card fraud worsens dollar loss figures. As fraud increases, financial institutions (FIs) have to pay more for fraud recovery, management, and operations. Financial institutions also face cardholder dissatisfaction and potential customer loss. Therefore, the market impact is significant.

In addition, automated clearinghouse (ACH) debit payments grow as Check Not Present transactions increase. ACH debits are less expensive, but involve limited control over account holders. Seller / seller / payee often receives extensive (and often non-restrictive) authorization to access a personal check account when the consumer establishes payment with the seller.

In the field of payment cards (including use in a CNP transaction), during the CNP transaction (for example, via telephone), you can use an indicator that the card holder is holding the card in hand, It is known to associate a short (usually three or four digit) numeric code with a payment card to increase the confidence that a predetermined payment transaction will occur.

There are several types of these conventional security codes.

A conventional security code of the first type is generally referred to as CVV1 ("card verification value"). This code is sometimes referred to in the art as CVC1 ("card validation code"). This code is invisible to the magnetic strip of the card and is retrieved, for example, when swiping the card to the POS terminal belonging to the merchant during the card presentation transaction. It is delivered as part of the transaction and is verified by the card issuer. Proof of the CVV1 code supports that the payment card is actually physically handled by the seller (or other entity) swiping the card.

The CVV1 code is fixed because it is recorded on the magnetic strip of the card, and is also specified on a predetermined payment card. If the card is physically replicated and the magnetic strip data is copied, the CVV1 code will remain valid and available by unauthorized users.

A conventional security code of the second type is generally referred to as CVV2 (or sometimes CVC2). The CVV2 code is a fixed number printed on the payment card (for example, on the back of the sign strip, or sometimes spaced from the account number), spaced from the card account number. The CVV2 code is used for CNP transactions (such as telephone or online purchase of a shoe or service) and is intended to indicate that the person who initiates the transaction holds the card or sees the physical record of the card (along with the CVV2 code on the card) . Among other forms of misuse, the use of the CVV2 code helps to prevent situations where self-strip information is illegally copied (technically speaking, a relatively simple step) and then used for CNP transactions. Most CNP transactions will require additional knowledge of the CVV2 code. In accordance with industry practice, the CVV2 code is not stored by sellers or payees during an electronic payment transaction. As a result, if transaction information (e.g., including customer payment card account numbers) is hacked or otherwise stolen by the seller or payee, this information becomes less available without knowledge of the corresponding CVV2 code.

Like the CVV1 code, the CVV2 code is fixed (i.e., unchangeable for a predetermined physical payment card), and is uniquely associated with a single payment card. CVV2 code is not maintained theoretically (by convention or by agreement between vendors and payment processors), but bad people who copy or maintain code illegally may not be prevented. It should be noted that although it has been customarily used, the CVV2 code is clearly demonstrated on the front of the payment card, and is illegitimately used if the card is stolen.

The use of PINs (Personal Identification Numbers) is also generally known to be associated with the use of, for example, debit cards. In a conventional example, the payment card is swapped to read the account information from the magnetic strip of the card, and the PIN is manually entered on the keypad or other input device by the user. A communication link is established with the bank or financial institution, which allows the transmission of card information and the entered PIN.

Conventionally, a predetermined PIN code is usually associated with each single payment card or other electronic entity or system for which the user desires to gain access. This worsens the proliferation of personal security codes that the user must manage, remember, and maintain security (i.e., protect against loss and / or unauthorized access).

FIs, sellers, and consumers all know how to minimize fraud, reduce exposure to data breaches, mitigate brand reputation risk, when transactions occur, when they are approved and when they are approved, We want a solution that reduces transaction risk by increasing control of the system.

Thus, it is possible to save money of FIs and sellers from unauthorized transactions or fraud losses, to provide account holders with greater control over transactions, minimize friction of the authentication process and transaction completion, It is desirable to find a security solution that solves some of the problems of the prior art to improve the adoption of the procedures.

FIs are the ones that threaten disintermediation of payment cards or check transactions (that is, the risk of losing a transaction to a third party intruder who may be building a safer or different trading methodology), online purchase volume, market share and account It will not sacrifice its holders. Sellers want to minimize abandoned purchases, chargebacks and disputed transactions. A preferred solution would be to maximize the utilization of existing processes, be easily integrated, be scalable, and not sacrifice the speed of the authentication process.

An attractive solution will address the needs of all parties: FIs, cardholders, account holders and sellers for online purchase transactions. Preferably, such a solution will reduce CNP fraud, limit FI exposure, reduce fraud, contention and deposit cancellation costs, and provide added benefits to cardholders and account holders.

The present invention most generally relates to systems and methods for user authentication that interact with or access a secured entity, particularly an electronic entity, such as secure computer networks or an individual or commercial web site, that the user desires to access . However, the present invention is obviously applicable to systems for physical access by individuals, such as secure buildings, and the like. Certain aspects of the invention relate to the generation, propagation, and management of security codes used in user authentication.

In particular, in a non-limiting example of the present invention, the present invention increases the security of the user authentication process in electronic transactions, particularly electronic payment transactions, but also minimizes the adoption burden of required security codes, And more particularly to systems and methods for maximizing user convenience.

The present invention provides a method and system for providing a single user for user authentication that is available across a range of payment modes belonging to a user (such as credit cards, debit cards, checking account, etc.), instead of having each of several security codes associated with each payment mode. To a randomized security code of limited lifetime. This conveniently reduces the number of security codes the user must remember and protect.

At the same time, however, the security code has a limited lifetime (e. G., A day) and thus changes, thereby reducing security exposure if the code is lost at any predetermined moment. In addition, the code can be easily changed if signatures such as fraudulent usage are detected, or because it may be needed in response to detection of a lost card or limited fraudulent use (i.e., for certain account or payment modes) Of accounts or payment modes) can be selectively (or automatically) locked and unlocked.

In the example of the present invention, a virtual matrix is generated in which a plurality of respective users (e.g., payment account holders) are associated with respective sets of randomly generated security codes. Each security code has a particular validity period that does not overlap (or at least overlaps, as described below) the validity of the other security codes in the set associated with the predetermined user. The current version of the matrix (for the current set of users and / or security codes) may be periodically distributed to payment processors or financial institutions and referenced for authentication. At the same time, at least the currently valid security code for the predetermined user is communicated to this user.

In a particular example of the invention, information on the matrix (particularly security codes) is mathematically obfuscated (e.g., using a hash function) before the matrix is distributed to the respective payment processors. Preferably, the obfuscation method is unique to each of the payment processors, such as using each hash salt unique to each of the payment processors.

Indeed, the electronic payment transaction process request is received by the associated payment processor along with one of the security codes for authenticating the authenticated user allegedly in response to the request to initiate the electronic payment transaction request. During the expiration period corresponding to the electronic payment transaction process request time, the received security code is compared with the security code of the current matrix corresponding to the authenticated user according to the assertion by the payment processor. This comparison does not approve or approve the transaction.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein: FIG.
Figure 1 is a high-level schematic illustration illustrating interconnection between hardware deployments associated with various "participants" of an electronic payment transaction.
Figure 2 illustrates a process for generating groups of security codes, including associated interactions between various payment processing entities in accordance with the present invention.
2A illustrates an example of how a matrix of temporarily known random patterns is generated.
Figure 3 illustrates a user's initial registration process for using the present invention.
Figures 3A-3H illustrate other implementations that require security code such that variations or security of the registration process, including grouping various accounts, are common to both.
4 illustrates a process for delivering a security code according to the present invention to a user.
5 illustrates electronic payment steps using a credit or debit card or a check, using the security code of the present invention.
Figure 6 illustrates other steps for authenticating an electronic payment transaction.
Figure 7 illustrates other steps in validating submitted security code within the framework of Figure 6;
Figure 8 illustrates the results of transaction record and transaction analysis steps within the framework of Figure 6;
Figure 9 illustrates a process for sending a notification to a user, which is used as some other processes of the present invention.
Figure 10 illustrates a process for selectively locking or unlocking financial accounts associated with the present invention.
11 illustrates a process for sending notifications to payment processors or financial institutions.
Figure 12 illustrates a process for validating an electronic payment transaction.

It will be appreciated that the details of the various aspects of the invention disclosed herein are applicable to a wide range of concepts of the present invention in various combinations that are as extensible as possible, even in the absence of a particular language herein.

For the purposes of this disclosure, the following definitions are generally intended to be further modified herein.

An "account" is any financial relationship that can transfer funds and hold funds for the purpose of purchasing and selling shippings and services. Typically, accounts include, but are not limited to, current accounts, deposits, lines of credit, credit cards, debit cards, prepaid cards (including payroll, gift and bonus), electronic wallets, Brand ACH cards, decoupled debit cards, virtual or physical cards used for purchases or accounts with or without checks, electronic fund transfers (EFT), or other means of transferring funds. can do.

A "transaction" is a transfer of money between business, home, inter-personal, intergovernmental, and other public or private organizations conducted through computer-mediated networks that may occur online or offline.

A "payment processor" is an entity that receives an electronic payment request, reviews the details of an electronic payment request, and acts as a broker to handle the transfer of funds from an associated financial institution (e.g., a card issuing bank) Quot; As shown, the payment processor may be, for example, a card payment processor or a Receiving Depository financial institution or bank. This also includes encompassing the Automated Clearing House (ACH) and the Federal Reserve, to the extent that it is accompanied by payment processor activity. However, for purposes of simplicity of disclosure herein, the term "payment processor" is not intended to be limited to the context of this description, and will be used basically in this context.

Figure 1 schematically illustrates a system for performing electronic payment transactions in which the present invention is incorporated.

The primary elements illustrated in Figure 1 may communicate directly or operably with each other. It is intended that the mediation elements do not need to be explicitly shown to be "operably communicated" with another element, but are intended to encompass the possibilities of mediation elements between communication paths between two elements. "Groupings" of the illustrated elements (e. G., Central system) means that proximity is clearly acceptable, but does not mean that it requires any physical proximity (within the limitations of conventional networking principles) Outline. Further, the communication "links" between the elements of FIG. 1 are intended to reflect the general relevance of the elements and are not meant to be restrictive or particularly exclusive (i.e., other communication links not illustrated in FIG. Or even between them).

As shown in FIG. 1, the "central system" includes elements that perform a fundamental part of the operations according to the present invention. The central database server 1 may, for example and without limitation: priority and corresponding information such as account holder registration profiles and notification priority or conditional transaction rules or account locking priority; To notify the registered account holders of the current security code active on all accounts registered in the account holder's profile as well as to the account holders of the participating payment processors, Generated security codes (sometimes referred to herein as random patterns temporarily known in the art); A dedicated or virtual hardware system (e. G., ≪ RTI ID = 0.0 > e. ≪ / RTI > held in cloud or on-premise data centers that centrally holds data supporting the present invention, Lt; / RTI > An example of a central database server 1 is Amazon Relational Database Service (sometimes referred to as Amazon RDS), which enables creation and operation of a virtual server on a remote system. Implementations on physical servers will also be effective in accordance with the present invention.

The HSM (Hardware Security Module) 2 may be stored in a cloud or an in-house data center and may be used to securely create, store and manage cryptographic keys used to encrypt or hash the processed and generated sensitive information during operation in accordance with the present invention Is used. As described below, it may also be used for true random number generation to fill the security code matrix (i.e., each individual security code has its respective validity period, . A commercially available implementation of the HSM 2 includes, for example, Luna SA 7000 HSM applications from SafeNet, Inc., available from Amazon Web Services and using, for example, Luna SA software (version 5) . The "intrinsic" random number generation known in the art depends on a scientifically random physical phenomenon (e.g., atmospheric noise or radioactive decay detected by a radio receiver) to maximize the randomness of the generated number, Is a preferred method for use.

The central application server 3 is a collection of middle-tier application servers or servers held in a cloud or in-house data center dedicated to effectively executing the functions and procedures that implement the business logic of the system. ("Middle layer" refers generally to the application server and the database server (s) as part of a multi-tiered architecture) that perform the business logic of the application and are operably located between the user interface and the web servers. Retains the necessary frameworks to execute, and connects to the central database server 1 to support the necessary data-centric operations. It may also be used by external clients or vendors who communicate with the central database server 1 to manage account holder registrations, account holder priorities, or receive transaction information from processors (or issuers or financial institutions) ). ≪ / RTI > For these process technology purposes, it is also possible to use a notification server 9, (e. G., Email exchange servers, SMS aggregators, mobile applications pushing alert services, Such as account holder notifications or business-to-business (B2B) communications, via Amazon Simple Notifications Service as part of an Amazon Web Services solution, It is responsible for outbound connections to other vendors to send data payloads. Some of these functions may also be implemented in separate hardware systems for a deeper, more distributed multi-tiered architecture. A commercially available example of the central application server 3 is Amazon Elastic Compute Cloud (sometimes known as Amazon EC2), but a physical server implementation would also be appropriate in accordance with the present invention.

One or more database servers 4, 6, which eventually handle and process a plurality of different databases, in an exemplary "payment processor" (or similarly located financial institution with electronic payment processing) / RTI > In general, a payment processor will already possess one or more database servers (and databases running on servers) to perform conventional operations. Certain operations in the payment processor according to the present invention are also database-server resident and may be implemented on existing hardware or may be implemented on an independent database server (or servers), if desired. With appropriate connectivity, the required implementation need not be local to the payment processor, but may be located, for example, locally at the central system or at another physical location. In this context, the present disclosure of the present invention is for the sake of simplicity and clarity of disclosure, if physically independent units are stated as examples of two servers associated with a payment processor. However, as described herein, all of the foregoing considerations apply to the present invention, and the functionality that results in one database server may be implemented in another database server.

Accordingly, the payment processor may have a security code database server 4 in accordance with the invention in communication with the central system (i.e., including the central database server 1, the HSM 2, and the application server 3) have. A commercially available example of a secure code database server (4) is the Dell 13G PowerEdge R730xd. The security code database server 4 may enable the participating payment processors, including the verification of the security codes entered by the account holders created and registered according to the present invention during the electronic payment transaction, Lt; RTI ID = 0.0 > and / or < / RTI > These examples may be implemented within a separate hardware system, dedicated or virtual, within a cloud or in-house data center, or within an existing database instance on an existing database server of the payment processor (i.e., integrated into the equipment previously presented to the payment processor) . The payment processor will also have one or more unique previously presented database servers 6. The database server 6 is typically a data store owned and / or operated by a participating payment processor or financial institution, hosted on a dedicated or virtual hardware system, held in a cloud or on-premises data centers, And data and methods necessary for processing authentication (i. E., Whether or not it is in accordance with the present invention).

A representative account holder (or, in other words, a consumer who has one or more financial accounts and wishes to pay for a shipment or services via an electronic payment transaction) is illustrated at 5. Typically, accounts include, but are not limited to, checks, deposits, lines of credit, credit cards, debit cards, prepaid cards (including payroll, gift, and bonus), electronic wallets, A branded ACH card, a decoupled debit card (ie an account linked to an account issued by one entity but associated with another entity (usually a fund), a virtual or physical card used for the purchase, or Accounts with or without checks, electronic fund transfers (EFT), or other means of transferring funds. In particular, for payment cards, the present invention is meant to apply to open-loop cards, closed-loop cards, single-load cards, and reloadable cards. As is known in the art, an "open loop " payment card refers to card types generally accepted among sellers (such as Visa®, American Express®, etc.) while" closed loop "payment cards Limited credit card or issuing credit cards) or a group of sellers.

The account holder 5 may occasionally complete a financial transaction, in particular an electronic payment transaction. A "transaction" is a transfer of money between business, home, interpersonal, intergovernmental, and other public or private organizations conducted through computer-mediated networks that may occur online or offline.

The account holder 5 may initiate a targeted financial transaction from a personal electronic device, such as, without limitation, a desktop or laptop computer, a tablet computer, a smart phone, a cell phone, or any other portable or fixed device. Alternatively, the transaction may be executed via a " live "customer service agent (telephone or face-to-face).

Appropriate interfaces for interaction with the system of the present invention include, for example (in accordance with the present invention) managing the registration profiles and priorities, including notification priorities or conditional transactions or account locking priorities; To receive alerts and notifications relating to transactions, changes to registration profiles, according to the present invention, or to obtain a current security code in accordance with the present invention; Initiating a request to manage account status or system behavior, such as permanently or temporarily locking an account participating in a transaction, either totally or conditionally, or that a foreign travel or payment card or device has been damaged, damaged, lost or stolen Mobile or desktop applications or applets, or text messages that connect to an API (Application Programming Interface) hosted on the central application server 3 and issue direct or indirect calls to inform the issuing bank.

The account holder 5 may interact with the seller (or recipient) 7 or the intermediary charging entity (not shown) occasionally for purchase or other payment transactions and to submit a transaction authentication request. Transactional authentication may be accomplished using a biometric scan, such as via a web site, a mobile or desktop application, or a voice communication (e.g., a human agent, or an automated speech recognition system), or a fingerprint or voice recognition or retina scan, 7) (for example, a card not present transaction) performed through a device that delivers transaction information to the customer; Or a customer presentation transaction (for example, an account presentation) in which the account holder 5 personally appears to the merchant (or recipient) 7 with any representation of a payment card, check, device, chip or financial account for purchase or payment Card presenting transaction).

The merchant (or recipient) 7 for the purposes of the present invention may be, for example, debit, credit, check or ACH by a device or application used to complete the card transaction authorization initiated by the account holder 5 It is an arbitrary entity that accepts payment methods. This can be represented as a web application or mobile application installed on the device that the account holder 5 accesses or operates. This may also be used to name some examples, in which an account holder enters transaction information by typing or scanning the information contained in the card or its physical or virtual representation, or by scanning the account holder's biometric information (such as a point of sale terminal) It may be the physical device of the merchant location. In a particular example of the present invention, the merchant 7 may operate, for example, the HP Moonshot ProLiant m350.

In accordance with the present invention, for example, one or more additional web servers 8 may be needed to host a web site or web application that interfaces with account holder 5. [ Amazon EC2 of the above-mentioned example may also be used herein. The web server 8 may be located in a central system of the cloud or in-house data center. Web server 8 may alternatively be part of the local network of the payment processor. The function may be used to receive inputs from the account holder 5 to manage the registrations and to register applications and other relevant information, e.g., current security codes in accordance with the present invention, to the account holders 5, May be provided by third party entities hosting APIs.

Finally, the notification server 9 (e.g., and without limitation, HP Moonshot ProLiant m800) may be any server that acts as an intermediary for delivering or pushing notifications to the account holder 5. Some examples of such servers or groups of servers may be exchange servers for processing and delivering e-mail messages or may be servers of the SMS unified manager for processing and delivering SMS text messages to a mobile phone belonging to account holder 5. [ Or may be a web service provider (e.g., Amazon Simple Notifications Service in an Amazon Web Services solution) that integrates all or part of these services together.

The following is an overview of the server interactions / connections shown in FIG. A more detailed description of the various processes according to the present invention will be discussed in greater detail.

<A>: The central database server 1 is used to retrieve the genuine random numbers from the hardware periodic random number generator (RNG) or to encrypt or decrypt sensitive information, such as security codes generated according to the present invention, For example, via the SQL CLR assembly, to securely store and retrieve the HSM (2) APIs.

<B>: To submit account holder registration changes, or to update transaction information received from payment processors, or to send notifications to account holders, account holder registration changes or new security codes (Temporary Known Random The central application server 3 connects to the central database server 1 to retrieve information for updating the payment processors with related information,

<C>: in this case, to update the processor's database server (4) with account holder registration changes or new security codes (Temporary Known Random Patterns), or to update the database server The database server 4 of the processor and the central application server 3 are preferably connected to the central server 1 via a server or multi-tier servers in the network of the payment processor, if possible, to retrieve the changes generated in the central database server 1, To the database server 4 of the mobile terminal.

<D>: The account holder 5 is used to create, delete or modify the registration profiles or user priorities and to use the communication means used by the account holder to retrieve information from the system, For example, a desktop or laptop computer, a smart phone, or a portable tablet computer).

<E>: Information collected by the Web server 8 (for example, registration changes) is transmitted to the central application server 3 via API calls. The web server 8 also issues API calls to the central application server 3 to retrieve information from the system and present it to the account holder 5.

&Lt; F >: The central application server 3 sends a notification code to the account holder 5 to push an alert, such as current security code, or information about transactions and activities involving accounts registered under the account holder's registration profile, (9).

<G>: The notification server pushes alerts, such as email messages, SMS text messages, or mobile application push alerts, to the account holder 5.

&Lt; H >: The account holder can use the seller or payee (7) interface and remotely, for example via the seller's website, to make payment transactions for shipment accounts or services, Through mobile or remote applications installed on the device, through an automated telephone system or human agent, or through a physical terminal at the merchant location.

<I>: The seller or recipient 7 transmits the transaction information submitted by the account holder 5 via the applicable networks and channels to be processed by the database server 6 of the processor for approval or rejection .

<J>: In the case of transactions that may be performed in accordance with the present invention, the database server (6) of the processor, in order to validate the security code according to the invention, which is entered as part of the transaction authentication request, And communicates with the server 4. The database server 6 of the processor may also communicate transaction information to the database server 4 of the processor or the security code database server 4 of the payment processor may communicate with the central server 2, (3) to the database server (6) of the processor.

Figure 2 shows a process for generating security codes in accordance with the present invention, particularly a process for generating security codes in accordance with the present invention, in which a plurality of account holders 5 (sometimes referred to herein as "users" &Lt; / RTI &gt; illustrates a process for generating a matrix. (For purposes of this disclosure, each of the sets of security codes may be variously referred to herein sometimes as "patterns" or "random patterns" or "temporally known random patterns").

In a particular example of the invention, each security code is a mathematically random number with a limited lifetime or expiration date (usually, but not necessarily, of dates or times). The random numbers are preferably generated by an intrinsic random number generator (as is known in the art) to maximize the unpredictability in the sequences of security codes to be generated.

In another aspect of the invention, each validity period of the security codes is sequential in time, so there is in fact a "next" security code (in time order) that can be used by the account holder after one of the security codes has expired . The validity periods may be purely sequential, with virtually no temporal superimposition, but may be a relatively small temporal superimposition (compared to the length of the validity period) between the end of the validity period and the time of the subsequent validity period , Overlapping one hour when the validity period is one day). That is, one security code may remain valid for a short time during the validity period of the "next" security code. The reason for providing this nesting validity period is that the transaction is entered in a short time before the end of the day of validity (e.g., 11.30 pm when the end of the validity period on a date basis is 12:00 pm) If there is an unexpected delay in the exchange of information or other processing as described herein that delays the actual processing of the electronic payment until after 12:00 pm, which requests the code submission, all irritation of the customer (i.e., user / account holder) It is to avoid complaints. A relatively short overlap means balancing the minimization of security risks with two or more pending security codes being valid at one time while ensuring ease of use for the account holder.

The creation of a new matrix, as shown in Figures 2 and 2a, is initiated at the central application server 3 (e.g., by a software application running at a scheduled frequency). For purposes of this non-limiting example, daily operations are assumed, but can be scheduled to occur several times a day, or less frequently than daily (e. G., Once every three days, for example).

Users of groups in the general sense, or a matrix according to the present invention of other individuals, require secure code-protected access for use or otherwise access electronic entities. Generally, the predetermined matrix includes all users / customers / payers / etc (e.g., all payment card holders associated with a payment processor) associated with a predetermined payment processor participating in another system in accordance with the present invention. A set of additional security codes may be generated as a kind of redundancy available when the originally assigned sets of security codes may have to be replaced (e.g., when fraudulent activity is detected). However, due to the characteristics of the present invention as disclosed herein, it is also within the scope of the present invention to associate two or more users with a predetermined set of security codes, as may be discussed further below.

Again, for purposes of illustration, the present invention is primarily described electronically in the context of authentication of electronic payment transactions, but it may also be possible to use other types of electronic means, such as electronic entities, such as private networks, government agency websites, It can be applied to authenticated access.

Typically, the matrix is populated by random numbers to define sets of respective security codes, each of the security codes of a predetermined set each having a particular one-day time-length period, or a particular limited validity period, such as a particular day. Each of the sets of security codes is associated with a unique identifier. Once the matrix is populated in this manner, users are associated with a set of security codes that are associated with one of the unique identifiers (referred to herein as pattern ID) to match this identifier. With this criterion, a predetermined user associated with a predetermined set of security codes at a predetermined moment and the current valid code that the user must use to authorize transactions is identified for an applicable validity period (e.g., a particular day) .

The secure code generation process preferably cycles through all the pattern IDs for a predetermined validity period and assigns a new random number value (for example, four digits of a predetermined length) to each pattern ID for this validity period. And then proceed to generate a third set of random numbers for all of the pattern IDs, one by one, a third set, a fourth set, etc., for the next validity period.

That is, the matrix is preferably a set of random numbers for the first pattern ID, then a complete set for the second pattern ID, and then preferably for each of the different pattern IDs, not the third, fourth, fifth, It is assembled by generating a random number for the. As a result, if there is any kind of recognizable predictability that is used for a sequence of random numbers generated by a random number generator by chance (e.g., in HSM (2)), then the predictability is a set of random numbers for a single user But will spread among different users. This is illustrated below with reference to FIG.

As can be seen in FIG. 2, the first step in generating this random number for each iteration is to obtain a new random number value 101 from an RNG, e.g., HSM (Hardware Security Module) 2. The HSM 2 preferably provides a real RNG, but any other kind of RNG, including a pseudo-random number generator, hardware or software based RNG may be used for this purpose. For example, a third party binary application, or database engine, that provides a web service providing a real random number or an interface to a software or hardware based algorithm for generating random numbers may also be used.

The RNG on the HSM 2 may transmit a new random number value (e. G., A random number) assigned to the pattern ID 104 of the current iteration corresponding to the current iteration date (or any other desired time period) 103). This example generates one random number 103 for each of the dates 105 for each of the respective pattern IDs 104. [ However, the plurality of random number values may be assigned to each of the pattern IDs that may or may not be associated with a particular date or period of time, or may be associated with a time period that is shorter or longer than a day. The random number values may also be associated with the frequency of occurrence of a particular event or process or with a particular process identifier. 2, the process of generating random numbers 103 is iterative at the first level of the sequence of pattern IDs, and then incremented to the next validity period (in this specification, the validity period is the date to be).

Figure 2a is a schematic representation of a matrix according to the present invention illustrating a preferred process for filling a matrix. The left column contains pattern IDs (abbreviated in the range of 0 to 99999) associated with a set of random-number security codes (row-by-row), respectively. In this specification, for example, each of the random numbers for each of the pattern IDs is a date-specific validity criterion (1 day, 2 days, 3 days, etc.). For each of the dates indexed with the primary cursor (a dark downward arrow relative to the "seven" column), the secondary cursor (in this specification, the row corresponding to pattern ID 3, for example) fills in the next randomly generated security code (Corresponding to the group of steps "for each pattern ID" in Fig. 2). Thus, in Figure 2a, the last generated code is (0166) at (Pattern ID 3; 7 days). Subsequently, the secondary cursor will move to the next pattern ID (i.e., 4) (pattern ID 4; 7 days), generate a new random code, continue for all pattern IDs of the matrix for 7 days, Will advance to the next date column (i.e., 8 days) (corresponding to the next level of the iteration of FIG. 2, denoted "for each date") and the random assignment will be repeated. As a result, as mentioned above, random number generation may occur at random number generation, which may occur if a set of randomized security codes for any predetermined user (i.e., for any predetermined pattern ID) is misappropriate Absence or any pattern will not be apparent in the row-wise direction.

Note that more patterns (i.e., sets of security codes) than customers / users may be generated for the matrix. This may, for example, make available a set of "redundant" codes for use by the customer as a replacement set of codes if the initial set of security codes appears to be compromised. For example, see the following disclosure of FIG. 4 for a reassignment of a new pattern ID.

However, situations in which less patterns are generated than customers / users can also be considered in accordance with the present invention. In this case, two or more users may be associated with a predetermined pattern ID. Thus, for example, the possibility that two users may know strictly speaking other people's security codes, but in practice, they will generally know that one user "shares" a set of their security codes with another user Since there is not much and there is not much more specifically to know that a user has a set of common security codes, with the idea that assigning users to pattern IDs is virtually opaque to users, low.

The generation of these random values may be optionally cross-referenced or otherwise compared to a list of values to be excluded from the matrix. For example, certain culturally unpleasant or otherwise sensitive values (eg, "13" in Western cultures or "4" in some Oriental cultures) may be excluded. The RNG-generated value will be reviewed for an exclusion list, and if found, a new call to the RNG is made to generate replacement values until the generated value is not in the exclusion list.

Once the complete matrix of security codes (temporarily known random patterns) is filled, then, in step 107, the central database server 1 is sent to be stored on the central database server 1, Into the database table. The matrix may also be stored in other formats, such as in a file system or in pictographic representation.

For purposes of the described process, this temporarily known matrix of random patterns generated as shown in this flowchart is used to assign a pattern ID to each of the registered account holders, as shown in step 211 of FIG. 3 A new random security code may be used for transactions initiated by the account holder 5.

The same version of the matrix is distributed to each participating payment processor in step 109 (since it may be updated or otherwise revised) so that payment processors can support payment transactions in accordance with the present invention. Preferably, each of the versions of the matrix of participating payment processors is hashed in a manner unique to this payment processor before being distributed. The uniquely hashed matrix is then loaded locally by each of the payment processors on the secure code database server 4 associated with this payment processor.

The random number values in the matrix are hashed utilizing Secure Hash Algorithm (SHA), which is preferably approved to be reliable and secure by industry standards and rules. For example, SHA-512 may be used in accordance with this aspect of the invention. Several secure hash algorithms, including SHA-512, are disclosed, for example, in Federal Information Processing Standards Publication 180-4, published March 2012, the contents of which are incorporated herein by reference to the extent permitted by the relevant patent office Quot; In order to hash the random number values of the matrix before being sent to payment processors or banks, each of the payment processors may, for example, allocate a unique hash salt 111 (from HSM (2), for example) Or otherwise associated. This hash salt 111 is also delivered in a secure and encrypted manner to each of the payment processors for use in the transaction authentication process. As is known in the art, "hash salt" is a mathematical standard for a predetermined hash process. Note that for a predetermined string (e.g., one of the numeric security codes of the present invention), the predetermined hash salt applied using a predetermined hash algorithm will always produce the same hashed version of the string.

Using the unique hash salts 111 (i.e., unique hash solids for each of the respective paying processors), unique hashed copies of the same matrix are generated for different payment processors (step 112), and each of the matrices Contains unique hashed representations of random numbers. Thus, the actual sets of random numbers generated and assigned for each pattern ID are kept clean at only the central database server 1 to deliver them to the registered account holders. Each of the payment processors will only have a distinct hashed representation of these values of the "payment processor " that is different from the hashed representation of any other payment processor in the corresponding examples of the security code database 4 (step 113).

Figure 3 illustrates the process of how an account holder 5 according to the present invention registers with the system. The account holder 5 starts the registration request. If the account holder registration profile has already been submitted 201, the account holder 5 may proceed to register the new / additional accounts in the existing profile at step 212. Otherwise, if a new account holder registration is required, the account holder 5 proceeds to step 202 to enter the information necessary to create the registration profile. This information may include, for example, a full name, a billing address, contact information (e.g., a mobile phone number or e-mail address), and notification priorities. This information is validated in the central application server 3 by the subprocess 203 to verify the entered account holder information. This sub-process 203 may include address verification, Identity Verification Services, and other types of Know-Your-Customer steps.

Once the entered account holder information has passed the verification step (step 204), a temporary random number or numeric code is generated at 205, indicating whether the account holder 5 has access to an email address or a physical device associated with the provided mobile phone number , It is communicated to the account holder via the notification sub-process (800) via the entered e-mail address or mobile telephone number. Upon receipt of the temporary code (having a limited lifetime) in step 206, the account holder 5 is requested to retransmit to the registration application service in step 207, and is then verified by the central application server 3. If the temporary code entered by the account holder matches the code generated in step 205 and is still valid in time (step 208), the collected account information is used to generate an account holder profile (step 209) (1). When the registration profile is created in the central database server 1, the pattern ID 104 (see FIG. 2A, for example) is assigned to the newly created account holder profile at 211, The holder 5 will be identified in the matrix of security codes. The account holder 5 will then drive the security codes to be provided as shown in FIG. The account holder is then notified via the subprocess 800 (see FIG. 9) of the profile creation results according to notification priorities, and the notification priorities are the SMS text message to the mobile phone number provided, the email message to the email address provided , Or a mobile application push notification. This account holder registration result notification may include information that is essential to interact with the service, including, but not limited to, a unique account holder profile identifier and a code to use in making electronic payment transactions.

Once the account holder profile presents, the account holder 5 may proceed 212 to associate one or more accounts with his or her account holder profile. The account registration process 212 may include step 213 (e.g., debit, credit, or checking account) of identifying a new account and entering account information (step 214). The bank account contains the account number and the bank's RTN (Routing and Transit Number). The card account may be any validation code printed on the physical card of the entire card number (typically 15 to 16 digits, sometimes fewer and sometimes larger digits), expiration date, any form or shape, or EMV (Europay, MasterCard, Visa), a digital verification code, or, if applicable, a virtual card.

The central application server 3 verifies whether or not the inputted information is valid. (The bank identification number of the card) or the ABA RTN (routing number) of the account to the corresponding bank or payment processor (cross reference to signed financial institutions and / or payment processors supporting the system according to the invention) Using previously available resources to map, the predetermined account is checked for compliance at 215 to participate in the system of the present invention.

If the account is appropriate (step 215), the system proceeds to the sub-process 216 to verify that the entered account is legally owned by the account holder, otherwise, via the notification sub-process 800 that the account can not be added The account holder is notified. The account validation step may include a call to address validation and CVV validation, a call to a web service (e.g., operated by a payment processor, or card issuer, or another third party) that verifies account holder information, A dollar value authentication request, or any other service provided by an authorized association to verify the authenticity of the account. In the case of a bank account, the verification process may include a small set of trial deposits to be verified by verifying the amount received by the account holder, for example, two deposits in a random amount of 1 to 99 cents.

After verification that the account is effectively owned by the account holder 5 at 217, the system proceeds to add this account to the account holder profile at 218 and store it on the central database server 1 at 219. The payment processor or bank ID information of the account is retrieved at step 220 by examining the central database server 1 at 221. Using the ID information 222, the system can either pay for updating these systems by calling the API provided by the payment processor, or by sending them to the system of the payment processor and loading them, or to record the addition of a predetermined new account And transfers this information at 223 to the payment server database server 6 by any other means provided by the processor. The information sent to the payment processor includes the account holder's registration profile information and, in particular, the associated pattern ID associated with the registration profile information to enable the processor to validate the security code of the account holder of the current matrix of security codes of future transaction authorization requests.

Finally, the account holder is notified via the notification sub-process 800 and receives an acknowledgment of account registration at 224.

The presently disclosed methods and systems for generating and managing security codes can be used in domains other than electronic payment security and financial transaction security. For example, a web site, a laboratory, an office, etc. may implement the present invention to deliver security codes daily to employees as an additional authentication or access control mechanism. In different areas, the codes according to the present invention may be implemented as additional proof of identity to account holders to apply credit transactions, new accounts or services from a seller, service provider or other types of government or private associations .

The account holder may register to receive the daily security code according to the present invention for use within a single domain or across many (particularly, many unrelated) domains, as described above. For example, the account holder may register credit cards for two different issuers / processors, as well as for the account holder's workspace access control system, and so on. Account holders having a plurality of registration profiles as described above may wish to select to group the profiles into one or more groups each having a respective security code according to the present invention. That is, therefore, the account holder can use a single (or at least less than a total number of domains requiring security codes) security code that is valid every day for every different implementation the account holder registers.

In this example of grouping of implementations, the Security Code Registration Profile (SCRP) is a single example of an individual user and a single financial account, or a non-financial account that requires secure access. Non-financial accounts include, but are not limited to, website access, computer sign-on screens, or physical access control situations. In the present invention, SCRP is a single account holder profile of a single processor's database.

A plurality of credit cards, debit cards, financial accounts, and security logins may be grouped as desired to enable easier use while reducing the number of security codes to use and remember. Once grouped, all SCRPs in the group will have the same pattern ID and will receive the same security code each day. In this way, for example, an individual can receive the same security code for all debit cards and credit cards.

The grouping should not be limited to a single individual. For example, a family may choose to have credit cards and debit cards for the entire family in the same group, and all family members may have the same security code daily for all credit cards and debit cards.

In another example, all employees with corporate credit cards may be grouped and receive the same security code daily for each of their corporate credit cards. In another example, all members of an army squad / platoon / unit / etc could receive the same security code daily as a way to identify their platoon membership.

Individuals can be members of several groups, as well as SCRPs that are not members of any group. For each group and non-group SCRP, the individual will receive a unique security code. For example, a person may have all credit cards, debit cards, "Company Group" single business credit card; And "non-grouped" checking accounts. In this case, according to the present invention, a person will receive three unique security codes each day.

Grouping criteria may be determined by the system, or by account holders, respectively, or by rules previously established by an authorized administrator for a group of groups. For example, the automatic grouping rules may be such that if two account holder profiles share the same e-mail, telephone, or other previously verified contact information, the codes generated and delivered daily for the matching profile will be grouped and synchronized daily will be.

In another example, a registered account holder may have the ability to initiate an invitation request to be grouped with another account holder's profile to receive a daily unified code for a particular implementation upon authentication of an authenticated account holder or group manager .

Figure 3A illustrates the high-level steps introduced when the account holder's profile is automatically or on-demand, grouped together with another account holder or group.

When the group assignment process 231 is initiated, if the on-demand request is made by the account holder 232, the authentication request 233 to join the group is initiated. If the account holder is authorized to join the requested group 234, the account holder's registration profile example is assigned at step 235 and the notification process 800 is initiated to notify all interested parties in the group assignment process. However, if at step 234 the account holder is deemed unauthenticated for the requested group, no action is taken and the account holder remains in the currently assigned group for each step 236. The notification step 800 is also triggered to warn unauthorized stakeholders attempting to access the requested group in this scenario.

In an alternative path where the request to join the group is identified as being not on demand (i.e., automatically) at step 232, then a process for locating automatic profile grouping rules for the account holder is performed at step 240. If the rules are found to match the criteria established at step 241, then the account holder's registration profile example is automatically assigned to the existing group at step 242 and accordingly notifications are sent at step 800. Otherwise, no action is taken and the account holder remains in the current or newly assigned group at step 236, and notifications are initiated at step 800.

Some examples of the referenced groups are illustrated below in Figures 3B-3G. For example, FIG. 3B illustrates a single security code registration profile, in this example, a single individual P1 with a credit card P1C1 that belongs to the group G1, which is inherently unique. This means that the security code is not shared with other registered accounts of account P1C1. That is, pattern IDs and their associated security codes do not intentionally match.

It should be noted that each of the security code registration profiles (SCRPs) is assigned a pattern ID assigned to a certain security code with a predetermined time period. Because infinite security codes are available, it is reasonably possible that, although the number is very large, any two predetermined random instantaneous pattern IDs will have the same security code assigned to them.

Figure 3c illustrates a single account holder P2 with three different credit card SCPRs (P2C1, P2C2, P2C3), as well as one debit card SCRP P2D1, all grouped together into a single group G2. This means that according to the invention, all four accounts registered under these SCRPs will receive the same security code corresponding to group G2 daily. A practical example of such a scenario is an account holder who wants all cards in the wallet to receive the same security code every day.

Figure 3D has one credit card SCRP P3C1, which is of course group G3, as well as two different credit card SCRPs P3C2 and P3C3, and one debit card SCRP P3D1, all of which have a single Account holder P3 is shown. This illustrates an example in which an account holder may choose to have one or more SCRPs grouped into one group and one or more remainders to be grouped into separate groups so that the two groups receive a separate security code each day. For example, the account holder may be a business credit card that receives a valid security code and a different security code for all personal credit and debit cards and personal accounts grouped together to receive a single valid security code for every card of an individual, and You may have separate groups for debit card accounts.

Figure 3E shows an example where different SCRPs belonging to different individual account holders may also be grouped together to receive the same security code each day. This diagram may be used by members of a family, business, organization, or social group who desire to receive the same security code each day for a set of accounts under different security code registration profiles, for example. In this example, both credit card SCRPs P4C1 belonging to account holder P4, as well as credit card SCRP P5C1 of account holder P5 and SCRPs P6C1 and P6D1 belonging to both account holder P6 are all registered under a single group G5. Therefore, the account holders P4, P5, and P6 receive the same security code each day.

As previously indicated above, security codes may be used in domains or applications other than electronic payment security and financial transaction security. 3f illustrates a plurality of individual account holders having access code SCRPs, which may be, for example, a physical code access to an office building, or a security code used to virtually access a web site or network on a secure public or private network, P7 to P11 are exemplified. In this example, P7A2, P9A1, P10A1, and P11A1 of all access code SCRPs belonging to individual account holders P7, P9, P10, and P11 are grouped together into a single group G7 to receive the same security code each day. At the same time, the individual account holder P7 also holds a separate SCRP P7A1 belonging to a separate group G6, which is shared with another SCRP P8A1 belonging to a different personal account holder P8. SCRPs P7A1 and P8A1 also receive the same security code each day as they are both associated with the same group G6. In this example, a single account holder P7 holds a plurality of SCRPs of the groups G6 and G7 that are registered and different from the different individual account holders. The actual application of this example is to postpone two different roles on different networks, for example "restricted user" and "administrator-user ", and for each role, different security It can be an individual who needs code.

Another domain exemplified herein is a social code, which may be a security code used by individual account holders who are simply recognized or identified as belonging to a social group, e. G. A secret social club, . Figure 3G shows each of the respective social code SCRPs P12S1, P13S1, P14S1, P14S1, P14S1, P14S1, P14S1, P14S2, and P14S1 of all the same group G8, which ensure that a plurality of individual account holders P12, P13, P14, P15, and P16 each receive the same security code every day P15S1, and P16S1.

Figure 3h illustrates an example of how SCRPs and groups to which SCRPs are allocated to represent the present invention may be represented in tabular form and stored in a database. Table T1 holds each of the SCRP, the PID of the account (entity) to which the account belongs, and each of the assigned group GroupId (e.g., G1, G2, G3, etc.). Tables T2A, T2B, and T2C are segments of the table that hold which security code pattern PatternID is assigned to each group GroupId of a predetermined date period (i.e., validity period). The date period is indicated by "From date" and "To date" specifying the start date and end date of each valid period of the PatternID. Each PatternID is then shown in Table T3, which assigns a different security code for each of the dates Day1Code, Day2Code, and so on. That is, each date closely traverses these tables to see which Group GroupId, SCRP is assigned; Then examining which Pattern ID is valid for this GroupId during a predetermined date / time period; It can then be determined which security code is valid for a particular SCRP by examining which security code is assigned for this particular date / time period (date in this example). The GroupId and date combination always renders the same security code (two codes for a short duration of date / time period variation), regardless of how the PatternID assignment rotates for each GroupId. Thus, two SCRPs sharing the same GroupId assignment are also guaranteed to share the same security code each day.

Figure 4 describes the steps that occur during the process of regularly providing the corresponding active security code (s) to the registered account holders.

In order to receive the current active security code associated with the profile of the account holder, the account holder 5 can request the security code or automatically receive the security code via the automatic push driven from the central application server 3. [

If a code is requested by the account holder 5, the request 301 is eventually sent from the account holder 5, for example via the device installed application, or at least to the central application server 3 (E. G. API calls from payment processor or account holder's online banking web site pages), or mobile originated SMS text messages, by directing text messages to central application server 3 And then sending it to the account holder 5 with a system-provided SMS short code to initiate an SMS response (including the current security code).

The request from account holder 5 must include a Profile ID 302 identifying the account holder and a source identifier identifying the device or application from which the request originated. The Profile ID must uniquely identify the registration profile associated with the account holder (5). The source identifier of the device may be a mobile telephone number or mobile application identifier used to send the request, or any other ID associated with the device used to perform (i.e., transmit) the request. Preferably, the request includes a Source ID and a Profile ID to validate the request.

To find the account holder profile (step 303), the central application server 3 invokes the process of the central database server 1 to examine the account holder profile (step 304). To maximize authentication security, the process first verifies the Source ID as an authenticated device / input source that is known to be associated with a registered user or account holder. If the account holder profile is found at 305 using the received Source ID and the Profile ID indicated by the account holder in the request is valid for the identified account holder profile (step 306), the central application server 3 sends a security code request (Step 307). Otherwise, if the Profile ID does not match the identified account holder profile, the notification subprocess 800 is used to notify the account holder that an invalid security code request has been received. The sub-process 800 may use one or more notification priorities specified in the account holder profile, such as an SMS message or an e-mail message.

The account holder 5 may alternatively initiate a response to the notification received from the system or a request to update or replace the current security code (e.g. in the case of a suspicious fraudulent activity). In this case, the central database server 1 assigns a different pattern ID 104 to the corresponding account holder's registration profile, and pushes this update to all participating payment processors. The account holder is then notified of the new current security code associated with the new pattern ID (and, indeed, the new fundamental matrix) (step 800).

For an automated, periodic "push" of the current security code, the request 312 is automatically transmitted to inspect a plurality of account holders 5 of the central database server 1, (Step 313). The frequency of these updates may be selected by account holders, since they may be the date that updates are sent. Once a group of account holders requiring automatic updates is established, a subprocess (labeled as " for each account holder "in FIG. 4) is executed to notify each account holder of the current security code.

In order to send a notification or an alert to the account holder (in any of the above cases), the central application server 3 initiates a request 307 for checking the security code of the predetermined account holder (step 308). The corresponding pattern ID is retrieved from the registered Profile ID of the account holder and the security code corresponding to this pattern ID is pooled from the temporarily known random pattern matrix or table for the current validity period (for example, the current date) . The account holder 5 is then notified of the current security code (800).

This notification of the current security code may simply return a Web browser or plug-in application installed on the desktop or mobile application request or account holder's device. The security code may also include an SMS text message, or an email message, or a mobile application push notification to the mobile phone number registered and validated for the account holder, for example, based on previously established notification priorities of the account holder Lt; / RTI &gt;

In a variation of the present invention, the process of providing the new security code to the user may be performed by periodically changing the pattern ID so that the user is in fact associated with a completely new set of security codes (i.e., updating the security code in the set of predetermined security codes Rather than simply updating the data). For example, on a periodic basis (e.g., every 7 days), a sub-process (not illustrated herein) may be used and the new pattern ID is regularly reassigned to all users. For example, if the pattern IDs are numbers, the RNG (which is the same as that used in the HSM (2), which is possible but not necessary) will be used to generate a random new pattern ID within the available range of pattern IDs to be reassigned to the user .

Periodically reassigning the pattern IDs preferably further increases the randomness of the association of any predetermined security code with any predetermined user and thus hacking, pattern deduction, and accessing the user &apos; s security codes And / or other efforts to predict future security codes.

Figure 5 illustrates an electronic payment authorization request made by the account holder 5 for high-level merchant or payee payment interfaces, e.g., a purchase progress. The main focus of this disclosure is the call to the transaction authorization sub-process 500, which is described in more detail below with respect to FIG.

At the start of a purchase or electronic payment transaction request, the account holder 5 submits the essential information to initiate the payment authorization request to complete the transaction with the seller or recipient 7 (step 401).

Assuming that the account is associated with an account previously associated with the profile of account holder 5, account holder 5 typically includes a security code currently in effect as part of the transaction request. For example, the security code may be stored in a place in the conventional CVV2 code of the payment card, or in place of other card information such as a CVV, or in conjunction with the card number, or implemented by an electronic token or a proxy number, May be submitted in the same manner as a separate field specifically dedicated to receive the security code.

For payment of a check, the security code of the present invention may have a field indicator of the memo field of the check, for example, a check, in the memo field of the check. For example, a 4-digit security code according to the present invention may be prefixed with a word or symbol. May be limited to predetermined symbols or characters on both sides, e.g., "+4567+" to "+".

Alternatively, the security code may be concatenated with a check number printed on the check to effectively generate an extended check number according to a predefined, generally accepted and anticipated format. For example, check number 101, which is used with security code 456 for example, may actually be printed as "101456" in the normal check number field. The check will be processed in the ACH file in the usual manner by the bank receiving the extended check number "101456 ".

In other examples, the security code may be provided either manually by the account holder in the input field or verbally to the actual person, or separately via the speech recognition system. The seller then includes information of the ACH request file (e.g., appendix or input detail fields).

The seller or recipient 7 has a conventional payment interface for receiving information submitted by the account holder 5. Depending on whether the account holder 5 uses the card or check 402 and if the seller is online, the system immediately sends an electronic payment authorization request 405 via the associated payment processor (see 6 in FIG. 1), or the ACH Scheduling and forming a transfer request 403, and later transferring the ACH transfer request 403 to the seller or recipient 7 via a previously established channel between the corresponding payment processor, receiving bank, or other financial institution for processing ACH requests To the associated payment processor. This may include a payment gateway service provider, a payment processing network, a Federal Reserve or an electronic payment network, or any other service or server intermediary between the seller or recipient 7 and the processor or receiver bank.

The payment processor then initiates the transaction authentication sub-process 500, either by receiving a card payment request or as part of the processing of the ACH transaction request 404, described in detail below with respect to FIG. The subprocess 500 acknowledges or rejects the transaction authentication request and sends the result 406 back to the seller or recipient 7 in step 407 in a manner appropriate to the needs of the seller or recipient 7. The seller or beneficiary 7 notifies the account holder 5 of the authentication result at the account holder interface 409. [

Figure 6 illustrates a sub-process 500 of transaction authorization. When the card or check payment process 400 is initiated according to FIG. 5, the payment processor or receiving bank determines at 502 whether the transaction type and account are eligible for processing according to the present invention. The payment processor may be located in a location (e.g., one of the servers associated with the payment processor, e.g., the security code database server 4 or the database server 6) that contains the information necessary to determine whether the transaction is suitable for processing in accordance with the present invention (Relatively) hosted APIs in the network of the payment processor or in the central system illustrated in FIG. Conformance may also be determined, for example, by examining the transaction authentication request payload of one of the ISO 8583 fields, or specific indicators included in the received NACHA ACH file.

If the transaction at 502 is not validated with the processing according to the present invention, then the payment processor continues with the authentication approval process at 509 that is normal (i.e., not using the conventional, secure code of the present invention). Otherwise, the database server (6) of the processor may determine whether the security code database server (4) of the payment processor (which may be local to the processor's network or at a remote location) &Lt; / RTI &gt; The database server 6 of the processor may be, for example, a remote stored procedure call, or an extended stored procedure, or a SQLCLR that interfaces with the assembly installed in the database server 6 of the processor accessing the secure code database 4 of the payment processor To the security code database 4 of the payment processor. Alternatively, the database server 6 of the processor eventually communicates with a local or remote service or API accessing the secure code database 4 of the payment processor.

The information received from the database server 6 of the processor as part of the authentication request is checked to determine if the account in question is associated with an active account holder registration profile stored on the security code database 4 of the payment processor. The transaction data received from the payment server's database server 6 is used to look up the account holder's registration Profile ID and the corresponding pattern ID 104 to retrieve a valid security code associated with the account holder and the card or account used . In one example according to an embodiment described herein, this transaction data may be an account alias 604 (instead of an actual card number or bank account number used by the account holder 5 to further restrict the dissemination of sensitive financial information) See FIG. 7). In this sense, the account alias is a representation of the card number or bank account number used by the payment processor, basically according to internal criteria, to minimize the spread of the card or bank account numbers. You do not need to know the account holder. Usually, a token or proxy number is used by the payment processor, but in accordance with the invention, a card number or bank account number itself (although not desirable) or a profile ID or pattern ID itself may be used.

Once it is determined 503 that the account used for the transaction authentication request has been registered, the security code database server 4 of the payment processor also determines if the account has been locked 504 and thus is not suitable for transaction authentication requests. The account may be locked upon request by the account holder, or may be automatically locked permanently or temporarily, based on the signatures of fraudulent activities detected by the system. This detection may be performed with internal analysis and algorithms, or a third party list management service such as a third party fraud or risk management rule system, or a commercially available FICO (R) Falcon Platform. If the account is flagged as locked in the security code database 4 of the payment processor, an invalid transaction attempt will be logged 510 for reporting and record keeping. The account holder 5 will also be notified, for example, if necessary, to correct the blocking problem.

If the account is not flagged as locked at 504 (as determined at 505) and the security code is properly included in the transaction request 501, then the security code database server 4 of the payment processor may send the security code received at the subprocess 600 Proceed to validate (see discussion of FIG. 7 below). Subprocess 600 returns an indication that the security code is valid at 506, followed by a subprocess 1100 for validating the transaction details (see FIG. 12).

In this specification, 505 "Is the security code presented? The attention shifts to the decision. Although there is no security code in step 505 (i.e., submitted as part of the transaction authentication request), details of the transaction based on other factors, such as the authentication process 509 that does not include the processing of the security code of the present invention Note that the process still branches directly to subprocess 1100 to validate. In this way, other security functions as disclosed herein may still be used, even if the security code according to the present invention is not reviewed for a particular transaction.

If the valid transaction detail sub-process 1100 determines that the payment transaction request is valid 508, the secure code database server 4 of the payment processor is successfully returned to the payment server's database server 6, Continue with the authorization request acknowledgment.

The validation process according to the present invention is not only part of the electronic payment transaction authentication process, but the validation process according to the present invention may not necessarily result in final transaction authorization by the payment processor.

However, if the validation of the security code fails at 506 or the transaction is deemed invalid at 508 according to the valid transaction detail subprocess 1100, the invalidation attempt is logged 509 for reporting and record keeping, and the corrective action can be taken appropriately The account holder is notified. The notification sent to the verified device (s) of the account holder may include a valid security code if legitimately attempted by the account holder to retry using the correct security code. Notifying the account holder of an invalidation attempt may also include the ability to quickly and easily lock in any other transaction attempts to the account in question by, for example, simply responding to notifications received with the locking instructions 900. [ And provides the account holder 5 with an opportunity to take action to prevent the fraudulent use of this account. This notification exchange may occur via an SMS text message for an activated registered mobile phone number on the account holder's profile, or via an application that is installed on the device owned by the account holder and properly registered and previously validated.

After the payment processor is advised to continue the authorization process at 509 or to reject the transaction authorization at 511, the processor database server 6 may again send the final transaction authorization results to be recorded in the system and further analyzed in the sub-process 700 .

FIG. 7 illustrates a subprocess 600 where the security code is validated in accordance with the present invention when initiated during the transaction authentication subprocess 500 of FIG. The sub-process 600 determines whether the security code submitted by the account holder 5 is valid or invalid.

The security code database server 4 of the payment processor receives the security code validation request received at 601 submitted by the account holder 5 as part of the transaction authorization request 500. Security code 601 is hashed at 602 using an industrially accepted Secure Hash Algorithm (SHA), e.g., SHA-512, to obtain the received security code hashed at 603. More specifically, the received security code 601 is hashed using the same payload processor-specific hash salt 111 that matches the hash salt used to hash the security codes in the matrix when the matrix was originally created, The hash salt 111 is used to mirror the hash algorithm in which the security codes in the matrix are hashed when the matrix is created.

Using the account alias 604 indicating that the payment account is associated with the transaction to be validated, the security code database server 4 examines the corresponding pattern ID in step 605. The pattern ID 606 is used to retrieve a locally stored version of the hashed matrix stored in the security code database server 4 of the processor to inspect the hashed value corresponding to the pattern ID 606 found in step 609 do. The correct security code of the group of security codes corresponding to the pattern ID 606 is stored in the account holder, which determines when each security code is to be updated (i.e., with a subsequent security code when the validity of the predetermined security code expires) And the date and time 607 of the payment transaction with the stored cut-off time 608 selected by the user. The result of this lookup operation 609 obtains a hashed reference version 610 of the current security code associated with the received account alias 604. This hashed value is compared with version 603 of the hashed security code submitted in a known manner at step 611.

It should be noted that while the submitted security code and the stored security code (in the matrix) are hashed, a comparison of the authentication between the submitted security code and the stored security code (in the matrix) is made. That is, when held by each payment processor, the security codes of the matrix are always kept in a hashed (i.e., ambiguous) form. Moreover, the hash is "one-way" - it can not be reversed to obtain the underlying information in a definite form. Thus, the security codes are further protected because only the hashed version of the matrix of security codes is locally located for each payment processor, even if the security code database of the payment processor is hacked or otherwise penetrated. This type of hash helps to solve the potential problems of dishonest payment processor employees or other "in house" individuals who may have access to customer security codes.

In order to authenticate an ACH or check transaction, the time may be specified in the authentication request as well as the date (e.g., of the check) (taking into account such factors as mail delays or sequential processing delays). In this case, the submitted security code will be valid for all security codes in the valid matrix for the date, regardless of the cutoff time. Because the actual transaction authorization may occur after the check is prepared and submitted, it may be necessary to inspect the security codes for dates up to 1, 7, 30, or perhaps 90 days prior to the current date of processing.

If the received hashed value 603 and hashed value 610 match (step 612) from the local version of the payment processor-specific matrix, the process indicates 613 that the submitted security code is valid. Otherwise, the system indicates that the code is invalid at 614.

FIG. 8 illustrates the steps (recording and analyzing transaction results) of the sub-process 700 referred to in FIG. This data can be received, for example, concurrently with the transaction request being received and processed at the payment processor side, or at substantially the same time. Otherwise, this information can be accumulated in a periodically generated report, for example at the end of the day.

Once the transaction authentication sub-process 500 is complete, the request may be made by the security code database server 4 of the processor to record transaction details at 701. [

In step 702, a determination is made in the secure code database server 4 of the payment processor whether the transaction requires real-time or immediate notifications or otherwise. An exemplary notification may be such that a notification to the account holder 5 is required, whether the invalid security code is submitted in transaction or otherwise suitable for processing according to the present invention. As a result, a message is posted to the central application server 3 by calling the APIs exposed by the central application server 3.

When the central application server 3 receives the transaction notification at 703, a determination is made at step 704 whether a notification should be sent to the account holder (5). When a notification is requested, a sub-process 800 for notifying the account holder is executed. (See Fig. 9 below)

The transaction fraud analysis 705 can also be made selectable, using conventional algorithms and other standard analyzes. The fraud analysis may consist of a set of internal rules designed to represent fraud if a particular number or set of conditions is satisfied, or the analysis may be passed to an external third party fraud or risk management service (not shown here) have. Optionally, an action may be taken to ensure the payment method in question, including automatically locking the underlying account or invalidating the associated current security code.

Similar to step 704, step 706 considers whether the account holder should be informed of the fraud analysis results, and if so, a fraud notification sub-process 707 follows. Sub-process 707 is not described in detail herein, but is generally similar to specific message payloads, rather than notification sub-process 800 (described below).

If the transaction for intermediate or real time notifications is not marked at 702, then at 708 the transaction is marked or scheduled to be included in a report to be sent to the central application server 3 at a later time, such as at 709, a batch process. This typically represents a batch file with deltas of new details received after the last batch file was created. The central application server 3 then processes the batch files received from the security code database 4 of the payment processor and transfers them to the central database 1 in step 711 for storage. The transaction details received are recorded at step 712 for future review, recordkeeping, and analysis, for example, business intelligence processes, reporting, or billing.

9 illustrates the steps of sub-process 800 for sending notifications to account holder 5. Subprocess 800 is referred to herein, for example, among others, with reference to Figures 3, 4, and 8.

When a notification is pushed to account holder 5, at 801 the request is sent to central application server 3 with a message payload (i.e., specific details or information 802 requesting notification). For example, when the security code is pushed to the notification to the account holder 5, the request 801 includes the security code, the information identifying the account holder 5, and the possible information or indicator of the type of notification to be sent.

The central application server 3 communicates with the central database 1 at 803 (at 804) to examine the account holder's notification delivery priorities. The list of selected preferred notification delivery methods 805 may include, for example, one or more of an email (or a particular notification repository), an SMS, a push notification via an app, a pager message,

Optionally, the notification template can be requested by the central application server 3 at 806 to format the notification in the desired manner. If applicable, the template information may be probed against the account holder 5 on the central database 1 at 807 and 808, possibly based on the account holder priorities specified previously.

In this sense, for example, the notification template for sending the current security code may be "{name}, your security code today is {security-code}". The variable content of the notification (e.g., the account holder's name, as indicated) may be pooled from, for example, the notification details 802 discussed above and substituted into the template as needed at step 809. The replacement step 809 generates the actual message content 810, such as "Maddy, your security code today is 364 &quot;, which may for example be the target communication method (s) (e-mail 813, SMS 815, To the account holder 5 in step 811. [ The notifications containing the template may be one of several languages, and the use of other character sets (e.g., other than English) is considered.

Figure 10 illustrates a subprocess 900 for selectively locking or unlocking registered payment accounts in accordance with the present invention. The term "locked" or "unlocked " in this context means to control the current capability (or disability) of the account to be used in accordance with the present invention.

The sub-process 900 allows the account holder 5 to manage a plurality of accounts handled by a plurality of payment processors or receiving banks by issuing by a plurality of associations and interfacing with a single application or service. In one example, the account holder may be able to determine whether there is more than one suspicious deceptive use of the accounts, or if the associated payment card or checkbook is lost, or even in the context of control of the parent of minor access to the account (s) , You may want to investigate one or more of your accounts.

If the account holder 5 decides at 901 to lock (or unlock) one or more of his or her registered accounts, the account holder 5 may, for example, register the profile ID 902 associated with the account holder's registration profile, An ID 903 of the account (s) in question, and an ID of the device from which the request is initiated, optionally (e.g., the mobile phone number of the smartphone used by account holder 5) . The request is sent to the central application server 3 and validated at 904. Once the request is validated, the account holder profile examines the central database 1 (step 905).

In accordance with the present invention, account identification ("account ID") is generally simple and easy to remember for each corresponding account of an account holder, and allows account holders to make various It is used to help distinguish between accounts. The account ID may be a predetermined numeric or alphanumeric word or phrase predetermined by the account holder 5. [ For example, the account ID may be a sequential number, or a letter, or a combination of letters and numbers, for example, to identify "Visa Card 4572" or "BofA bank account 1721" The account ID may also be part of a card number or bank account number, for example. The account ID may also be a keyword or number, for example "ALL ", as a shortened indicator that all accounts under the profile of the account holder are locked / unlocked.

Once the account holder profile is located and the accounts are marked valid (at 906), there is an iterative process for changing / updating the locked / unlocked state of each account in question (see "for each account" Lt; / RTI &gt;

For each account that is locked / unlocked, the central application server 3 sends a process for changing the state of the account of the central database 1 to locked or unlocked 908 as requested by the account holder 5 &Lt; / RTI &gt; The central application server 3 then calls the payment processor or other relevant financial institution at 909 and corresponds to the test 910 in the central database 1. Once the associated payment processor 911 is located, the central application server 3 sends an update request to the security code database server 4 of the payment processor to update the status of the account and is performed at 913.

Using the account holder notification sub-process 800, the account holder 5 is informed of the results of the requested locking / unlocking operation and the account holder 5 receives the confirmation (914).

Requests to lock the account (s) may suffer from being periodically locked to a set time period or specifically locked for a day, such as locking for a certain period of time, e.g., for a fixed time period. For example, the account holder 5 may request that the account be locked, for 7:00 pm to 9:00 pm on weekdays, and / or for all of April 29, 2016 to April 5, Thereby preventing the associated transaction from being approved. In some cases it may be possible to specify only date unit time periods (as opposed to time units), such as in the case of a bank check on a particular date.

Conditions may also be applied, for example, to specific sellers, seller types (e.g., not cinemas), or geographic areas.

FIG. 11 illustrates the steps of a subprocess 1000 for notifications sent to associated financial institutions and payment processors that are somewhat similar to the subprocess 900 of FIG.

Beyond requests for locking or unlocking accounts, the account holder 5 may, for example, notify one of the associated payment processors that the corresponding payment card has been lost or stolen, (Thus allowing fraud analysis to be adjusted). In another example, the account holder 5 may wish to convey a request for an alternative payment card, for example, if a new checkbook or card for the checking account has been compromised.

The sub-process 1000 is initiated when the account holder 5 submits a request or other communication 1001 with a Profile ID 1002 and one or more account IDs 1003 for the accounts in question. The central application server 3 processes the request 1001 at 1003 and validates the request at 1004 (using user and account IDs). Once validated, the account holder profile looks at the central database 1 at 1005.

When the notification request 1001 is validated at 1006, the process begins as indicated by a group of steps over the requested (central application server 3, central database 1, and payment processor database server 6), and Quot; for each "account") state or priorities. The account ID may be a predetermined numeric or alphanumeric word or phrase determined by the account holder 5 to allow the system to identify accounts of the account holder's profile. The same considerations that make up the account ID as discussed above in FIG. 10 apply here.

For each identified account, the central application server 3 activates the process in the central database 1 (step 1008) to change the state of the account in the manner requested by the account holder 5 in step 1007 invoke). In step 1009, the central application server 3 requests a payment processor or bank corresponding to the account in question, which responds to an inquiry step 1010 in the central database 1 to acquire an associated payment processor 1011 do. Once the associated payment processor 1011 is identified for the account in question, the central application server 3 sends a request 1012 to the payment server's database server 6 to update the status of the account (see step 1013) do.

The account holder 5 is then notified of the result (s) of the requested action (s) (using the notification subprocess 800) and receives an acknowledgment 1014 when the request is to be performed.

Finally, FIG. 12 illustrates the steps of sub-process 1100 (valid transaction detail), as described, for example, in sub-process 500 (FIG.

When the subprocess 500 originates in the security code database 4 of the payment processor or when the details of the transaction have to be validated for any applicable rules previously established in the account holder's registration profile, This subprocess 1100 for validating the payment processor 1100 is executed in the security code database 4 of the payment processor.

Once the Profile ID 1101 is determined, a determination is made that the account holder's registration profile is found (1102) and there are any account holder-established transaction rules to apply (1103). If there are no applicable transaction rules, then sub-process 1100 is terminated and the transaction details process is "passed" (i.e., completed).

Otherwise, the applicable rules (e.g., transaction amounts / restrictions 1106, seller related details (e.g., merchant name, or any applicable commercial merchandise category code) 1107, (E.g., transaction 1108), or any other transaction related details 1109, e.g., local transaction date and time, and product or service purchase information) are executed and typically from a payment processor processing transaction authentication sub-process 500 Is validated as applicable at 1105, using transaction details received when entered into the subprocess.

In other details, examples of transaction validation rules contemplated herein include, but are not limited to:

Transaction Account Limitations: The account holder (5) may predefine the maximum or upper limits for any predetermined transaction attempt on the registered account. For example, the account holder may wish to refuse any transaction attempts of, for example, $ 500.00 or more for a predetermined credit card registered in the account holder's registration profile.

Merchant or Seller Category Constraint: The account holder may choose to prohibit transactions for a particular seller or seller category, if attempted. Conversely, account holders may specify that one or more accounts may be used only in specific concrete sellers, or in certain seller categories. The account holder may also specify a list of sellers or merchant categories for which the registered account is used exclusively in any other seller or seller category and for which any transactions attempted in any other seller or seller category are rejected. For example, an account holder may choose to use and approve only certain items, such as groceries or gas, or specific locations or seller categories, or to refuse all purchases attempted at a bar, for example, You may want to limit categories.

Recurring transaction rules: The account holder may decide whether to approve or reject transactions that are recurring from particular sellers or claimants, or may specify the number and frequency with which recurring transactions must be approved. The account holder may choose to be denied for a registered account for all recurring transactions, unless specified as a transaction validation rule setting for the account holder's registration profile. For example, an account holder may specify that an account accepts only recurring transactions of less than $ 1200.00 per quarter from a particular utility and less than $ 150.00 per month from a particular cable TV provider. The account holder may be set to be active until it is removed, or to specify the expiration date, or the number of installments to be authorized.

Other rules or any combination of these may also be specified. For example, recurring transaction rules may include seller category restrictions, or maximum transaction volume.

After the transaction validation rules are reviewed at 1105, if the transaction passes all applicable rules at 1110, the process returns a "pass" Otherwise, a "failure" result is returned 1111, and additionally the account holder may be notified of the validation failure via the notification subprocess 800, optionally.

Variations of this embodiment may also involve real-time communication with the account holder in the event that the rule validation fails, in order to enable the account holder to actively participate in the transaction approval process. For example, if a recurring ACH payment is received and the account holder does not set up rules for a particular payment type, the account holder may ask for authorization or confirm the rejection and, if possible, any other transaction attempts from a particular recipient or claimant To establish transaction rules that recur at a point in time, account holders may be notified via automated or real agent phone calls, or SMS text messages, or mobile application push notifications, for example. For example, other real-time communications of the account holder during the processing of offline transactions, such as offline transactions, such as checks or ACH payments, in order to allow the account holder to correct the entered invalid security code, &Lt; / RTI &gt;

While the present invention has been described above with reference to specific embodiments for purposes of illustration and illustration of the invention, it is to be understood that the invention is not limited to reference to the specific details of these examples. More specifically, those skilled in the art will readily appreciate that modifications and improvements can be made in the preferred embodiments.

Although the present invention has been described above in the context of electronic payment transactions, the disclosed concept is more generally applicable to secure electronic access to sensitive electronic networks or other electronic entities requiring user authentication to reduce exposure of the underlying security code . For example, the invention may be applied for user authentication when interacting with the tax authority in relation to issuing refunds, or dealing with a tax authority that authorizes user authentication at the time of tax return application. More generally, the present invention allows a user to interact with a plurality of, for example, government agencies (taxes, licenses, law enforcement, etc.) in the same manner as using a plurality of financial entities described above A single security code can be used conveniently. The present invention can be remotely embedded and executed from an entity to be accessed (e.g., accessed via an API), and can include, for example, a Profile ID, a requester ID (corresponding to an entity the user is seeking to access, (Similar to the technique described above), the password of the requestor, and the security code to be submitted by the user.

While the present invention has been described above with reference to specific embodiments for purposes of illustration and illustration of the invention, it is to be understood that the invention is not limited to reference to the specific details of these examples. More specifically, those skilled in the art will readily appreciate that modifications and improvements can be made in the preferred embodiments without departing from the scope of the invention.

Claims (32)

A method of using a security code of a limited lifetime to allow a financial entity to authenticate an electronic payment transaction,
Receiving a previously established matrix that associates a plurality of users with respective sets of unique security codes, each of the sets of each of the security codes having a validity period, receiving the previously established matrix step;
Receiving a request for processing an electronic payment transaction, the request comprising a security code for authentication, the received security code being allegedly associated with a user of the plurality of users, Receiving the request;
The security code in the previously established matrix held by the financial entity corresponding to one user of the plurality of users during the validity period corresponding to the time of the request for the processing of the electronic payment transaction; Comparing the received security code; And
And accepting or disallowing the transaction in accordance with a lack of a corresponding relationship or correspondence between the received security code and the corresponding security code in the matrix during the corresponding validity period. How to use a security code with a limited lifetime. The method according to claim 1,
Wherein the limited lifetime security code is common to a plurality of electronic payment modes belonging to the user. 3. The method of claim 2,
The payment modes of the user include authenticating an electronic payment transaction, including at least one of a checking account, a credit card account, an automated bill exchange transaction, a debit card account, a prepaid credit card account, a gift card account, To use a security code with a limited lifetime. 3. The method of claim 2,
Wherein a plurality of financial entities corresponding to the plurality of payment modes are provided with security codes of the same matrix so that a predetermined security code for the user may be used for all user payment modes within a predetermined validity period, How to use a security code with a limited lifetime to authenticate the transaction. 5. The method of claim 4,
Wherein before a matrix of security codes with a hash salt unique to a predetermined one of the plurality of financial entities is received by the predetermined one of the financial entities, A method of using a security code with a limited lifetime to authenticate an electronic payment transaction, comprising: hashing the codes. 6. The method of claim 5,
Comparing the received security code to the corresponding security code in the previously established matrix for a corresponding validity period and comparing the hashed security code received with the hashed security code of the matrix for the user Further comprising the step of hashing the received security code using the same hash salt as used to hash the matrix of security codes, including to do so How to. The method according to claim 1,
Wherein each of the security codes in the matrix is generated by a random number generator, the security code being limited to authenticate an electronic payment transaction. The method according to claim 1,
Wherein the expiration date is one calendar day, wherein the expiration date is one calendar day. The method according to claim 1,
Further comprising forwarding the security code for the current validity period to the user. &Lt; Desc / Clms Page number 22 &gt; The method according to claim 1,
The current security code may optionally be invalidated, using a security code with a limited lifetime to authenticate the electronic payment transaction. The method according to claim 1,
The current security code may be optionally replaced before the expiration of the validity period so that an electronic payment transaction is generated that causes the generation of a new matrix containing hashed security codes containing the replaced security code for a pending validity period How to use a security code with a limited lifetime to authenticate. 3. The method of claim 2,
One or more payment modes of the user,
Receiving a lock / unlock request from the user, proof of the user's identity, and a payment mode or modes to be locked / unlocked;
Informing the financial institution and / or the payment processor associated with each of the new locked or unlocked payment modes or modes; And
Confirming the locking or unlocking with the user
Lt; RTI ID = 0.0 &gt; and / or &lt; / RTI &gt; The method according to claim 1,
Further comprising applying predefined transaction authorization rules to a predetermined transaction in addition to authentication of the user's security code. &Lt; Desc / Clms Page number 21 &gt; 14. The method of claim 13,
The transaction approval rules,
Limits on trading volume;
Restrictions on transactions with particular sellers or seller categories; And
The method comprising using one or more of the registrations for transactions that recur recurring transactions. A method for generating and distributing a limited lifetime security code for user authentication in an electronic payment transaction,
Associating a plurality of users with respective unique pattern IDs;
Generating a set of random security codes for each of the pattern IDs, wherein each security code in each of the sets obtains a matrix associating the plurality of users with sets of respective security codes corresponding to different validity periods, Generating a set of random number security codes for each of the pattern IDs, each code corresponding to a respective validity period;
Delivering the matrix to at least one of the plurality of users in the matrix, each payment process associated with one or more payment modes; And
Delivering at least a current valid security code to each of said users for use in authenticating electronic payment transactions, said authentication being performed during said associated validity period of time of an electronic payment transaction and within said matrix for said user Generating a security code of limited lifetime for user authentication in an electronic payment transaction, said security code comprising comparing said security code with a code and a security code submitted by said user as part of said electronic payment transaction &Lt; / RTI &gt; 16. The method of claim 15,
Wherein the validity period of the security codes is measured in terms of date, time, or date and time. 16. The method of claim 15,
Wherein the validity period of the security codes is one day, for a user authentication in an electronic payment transaction. 16. The method of claim 15,
The method of generating and distributing a limited lifetime security code for user authentication in an electronic payment transaction, said method comprising delivering at least the currently valid security code, said currently valid security code and subsequently one or more security codes, . 16. The method of claim 15,
The step of delivering at least the currently valid security code comprises at least one of delivering at least a currently valid security code upon user request and at least pushing out the currently valid security code, A method for generating and distributing security codes of limited lifetime. 16. The method of claim 15,
Wherein the at least one payment mode comprises one or more of a checking account, a credit card account, an automated bill exchange transaction, a debit card account, a prepaid credit card account, a gift card account, A method for generating and distributing security codes of limited lifetime for user authentication. 16. The method of claim 15,
Generating a set of random number security codes comprises generating a set of random number security codes for each of the plurality of users for each of the plurality of users for a predetermined validity period prior to generating each security code for each of the plurality of users for a subsequent validity period. A method for generating and distributing security codes of limited lifetime for user authentication in electronic payment transactions, including generating security codes. 16. The method of claim 15,
Wherein the different validity period is temporally sequential, generating and distributing a limited lifetime security code for user authentication in an electronic payment transaction. 23. The method of claim 22,
There is a temporary overlap between the end point of the validity period for the first security code and the point in time of the validity period for the second subsequent security code, and a method for generating and distributing limited-life security codes for user authentication in an electronic payment transaction . 16. The method of claim 15,
The matrices include a set of security codes for a limited lifetime for user authentication in an electronic payment transaction, which is hashed prior to delivering the matrix to each of the payment processors, using respective hash solids unique to each of the payment processors &Lt; / RTI &gt; A method for generating and managing a plurality of limited lifetime and sets of user specific security codes to cause each user to interact with a plurality of electronic entities using a single respective security code,
Generating a plurality of random numbers having a predetermined number of digits in length using a random number generator;
Populating a matrix of each of the plurality of sets of security codes using each of the generated random numbers, wherein each security code of each security code set is associated with a respective validity period in the matrix, Each set having a unique identifier; populating the matrix with the random numbers;
Associating a set of each said security code with each user;
Generating a copy of the matrix of security codes for each of the plurality of electronic entities using the security codes to interact with the plurality of electronic entities and generating a copy of a matrix of security codes for each of the plurality of electronic entities, Mathematically hashing the security codes of each copy using a hash salt to obtain a matrix of security codes of a plurality of uniquely hashed versions;
Communicating respective uniquely hashed versions of the matrix of security codes to each of the electronic entities, and communicating the corresponding hash salt separately to each of the electronic entities; And
And communicating at least a current valid security code of the set of security codes associated with each user to each user. 26. The method of claim 25,
Wherein the electronic entities comprise one or more of bank entities, payment processor entities and secure computer networks. 26. The method of claim 25,
Wherein a secure hash algorithm is used to hash the random numbers in the matrix. 26. The method of claim 25,
Wherein the validity period of each of the security codes is a preselected 24 hour period. 26. The method of claim 25,
Wherein the validity period of each of the security codes of each set is temporally sequential; and generating and managing a plurality of sets of limited lifetime and user specific security codes. A method of using a security code of a limited lifetime to allow a financial entity to authenticate an electronic payment transaction,
The method comprising: receiving a previously established matrix associating a plurality of users with sets of respective unique security codes, each security code having a validity period, each security code corresponding to a predetermined matrix uniquely corresponding to a predetermined matrix Receiving the previously established matrix mathematically hashed with unique hash salts;
Receiving an electronic payment transaction processing request, wherein the request comprises a security code for authentication, and wherein the received security code is related to being asserted with a user of the plurality of users, ;
Hashing the received security code using the same hash salt as the hash salt associated with the received matrix;
The hashed security code in the previously established matrix held by the financial entity corresponding to the asserted user of the plurality of users during the validity period corresponding to the electronic payment transaction process request time, Comparing the received security code; And
Accepting or not approving the transaction in accordance with a lack of correspondence or correspondence between the hashed received security code and the corresponding hashed security code in the matrix during the corresponding validity period. How to use a security code with a limited lifetime to authenticate. 31. The method of claim 30,
Wherein the matrix is populated using a random number generator to generate a plurality of random numbers of a predetermined number of digits in length. 32. The method of claim 31,
Wherein the random number generator is a true random number generator using a limited lifetime security code to authenticate an electronic payment transaction.

Images