SYSTEM AND METHOD FOR VERIFICATION, AUTHENTICATION, AND NOTIFICATION OF TRANSACTIONS
A system and method for verifying, authenticating, and providing notification of a transaction, such as a commercial or financial transaction, with and/or to at least one party identified as engaging in the transaction and/or identified as having a potential interest in the transaction or type of transaction, are provided. A central system accepts information regarding a transaction, including information about at least one party identified as engaging in the transaction, such as by a credit account number or Social Security number or merchant account number, and/or identified as having a potential interest in the transaction. Based on the information regarding the transaction and any supplemental information the central system determines, the central system communicates with and/or to at least one party and/or additional or alternative parties, via at least one communications device or system having a communications address, such as a telephone number or Short Message Service address, predetermined as belonging to the at least one party and/or additional or alternative parties. Via said communications, at least one party having an interest or a potential interest in the transaction may be notified of it, and may further be enabled or required to supply additional verifying or authenticating information to the central system. If the transaction was initiated or engaged in via a communications link, such as via the Internet, said communications preferably occur over at least one different communications link and/or protocol, such as via a wireless voice network. The central system may then compute a result based on the outcomes of said communications, and may then transmit the result to the user and/or to a second system or device.
This application is a continuation (CON) application of U.S. patent application Ser. No. 10/354,609, filed Jan. 30, 2003, entitled “System and Method for Verification, Authentication, and Notification of a transaction,” which claims priority to U.S. Provisional No. 60/354,275 with filing date Feb. 4, 2002, both of which are incorporated herein by reference in their entireties.
BACKGROUND OF THE INVENTION1. Field of the Invention
The invention relates to fraud prevention and fraud “early warning” notifications for transactions, in particular remote and/or electronic transactions such as “e-commerce” and “m commerce” transactions wherein it is desirable to authenticate and verify one or more parties' identities and intentions before the transaction is concluded and/or to notify one or more parties of the occurrence of the transaction.
2. Description of the Related Art
In a transaction in which security is a concern, such as an electronically conducted transaction involving a funds transfer or a purchase or payment, there are three basic questions which must be satisfied:
-
- 1. Are the parties to the transaction who they say they are? (Do they own the goods, services, or funds or financial accounts that they represent they do?)
- 2. Do they have the necessary authority or authorization to approve the transaction?
- 3. Is the environment in which the transaction occurs secure? That is, can other parties gain access to the private information being exchanged during such a transaction?
Regarding question 1, the payments industry has devoted considerable attention to methods and systems designed to a) verify the identity of a purchaser, b) assess the risk of any given transaction, and c) take follow-on action in high-risk cases, either by subsequently inquiring of the payer whether the transaction was proper, or by denying funds or credit at the time of the transaction subject to later manual contact with the payer.
For more complex or higher-value transactions, per question 2 a buyer may be subject to a set of audit and control procedures designed to limit his/her purchasing authority. In most consumer purchasing cases, the buyer and authority-holder are usually the same person. In many organizational purchasing situations, the buyer(s) and authority-holder(s) are not the same. The payments industry has one primary tool for limiting purchasing authority, which is the spending limit or credit limit associated with the buyer's account. Attempted solutions to question 1 also help address question 2, since verifying identity helps address cases wherein a buyer is suborning the purchasing authority of another party by use of a stolen credit card number or other private information.
As regards question 3, the most relatively secure environment for purchase transactions remains a merchant's store, in which a buyer and seller can interact face to face, multiple forms of identification can be reviewed, and the opportunities for theft of private information are generally limited. At the other extreme are telephone, mail, and electronic commerce, in which the buyer is represented merely by his/her account information as supplied by phone, on a mailed form, or by data entry via a computer or other electronic device. Here, the opportunities for fraud and the theft of private information are relatively high. Further, there is a prevailing public perception that electronic purchasing environments (for example, virtual storefronts or Internet auctions) are inherently insecure in regard to the transmission and/or storage of private information.
The above factors are reflected in the relative “discount rate” (price) charged to merchants by credit card processors for in-store transactions vs. “card not present” transactions, for example. Typically, merchants pay 60% more per sales dollar in a “card not present” transaction than when a credit card is physically presented for swiping.
These differences in risk also apply when accounts themselves are opened, closed, and modified remotely, as via mail, telephone, wire, or other electronic means.
Current transaction-verification systems and methods, such as for credit, debit, and purchase-card purchases and payments, Automated Teller Machine (ATM) interactions, e-ticket redemption, and the like, may be grouped into four broad categories: 1) physical identification of the purchasing party or of a difficult to-mimic characteristic of the purchasing party, such as by signature comparison or biometric scanning, 2) data entry of passwords or other identification codes, such as the Personal Identification Number (PIN) codes used with ATMs and calling cards, 3) validation of embedded digital authenticating information, such as is found in “smart cards”, and 4) verifying private knowledge presumed known only to the account holder, such as the account holder's billing address or Social Security Number (SSN), prior to approving a transaction, including opening, closing, and modifying an account. A fifth category, devoted to limiting the exposure of sensitive private information such as credit card numbers to insecure or weakly secure environments subject to high levels of electronic theft or hacking, such as the Internet, is the substitution of dummy information for the actual private information, which dummy information is reconciled with the actual private information after its receipt by the payment processing organization.
Additional systems and methods have been employed by credit reporting agencies, which agencies already monitor the status of individuals' credit accounts. Such organizations may offer their customers regular monthly communications by mail or electronic mail identifying new accounts established in the customer's name or with the customer's federal tax identification number since the last such communication.
Especially in categories (2) (3) and (4) above, transaction approval by a bank or other merchant processing or payment processing organization or network is often coupled with an automated risk detection processes and human follow-up, as when a credit card issuer's risk assessment system determines that an unexpectedly large, out-of-state purchase is “high risk” for a given account holder, and then provides that information to a customer service representative who may call the account holder's telephone to attempt to confirm the transaction's validity, typically after the fact, or to leave a message for the account holder that the card account is suspended pending the account holder's reply. It is often the case that the account holder's ability to judge what constitutes a fraudulent transaction conducted in his/her name considerably exceeds that of said risk assessment system and customer service representative. Despite this judgment-gap, today's account holders have, at best, only after-the-fact means available to them from their financial institutions, or from merchants, to audit transactions occurring in their name, including the opening, closing, and modification of accounts, or at-the-time means which involve significant new technologies and new processes to implement, learn, and use. In some cases the burden of implementing, learning and using falls on the merchant or other provider of goods, services, or funds, as well as the account holder.
Merchants subjected to fraudulent transactions are informed after the fact as well, when the true account holder disputes a transaction with his/her payments organization. In the case of credit card transactions, the merchant is then charged back for the value of the disputed transaction and may also be charged a dispute investigation fee, resulting in a loss of profits and goods.
Additional research and development in the payments industry has focused on adding encrypted identifying codes or digital certificates to credit cards via an embedded microprocessor (as in “smart cards”) or via software on a personal computer (“e-wallets”); and on physically printing unique numeric identification numbers or numeric passwords (such as CVV2/CVC2/CID codes) on credit cards. Said codes are a relatively recent security feature for use in “card-not-present” transactions and now appear on, for example, Visa, MasterCard, American Express and Discover cards. As of this writing, these codes are comprised of a three- or four-digit number which provides a cryptographic check of the information embossed on the card, called CVV2 (Visa, 3-digit), CVC2 (MasterCard, 3-digit), and CID (American Express, 4-digit, and Discover, 3-digit). These code values help validate two things: a) the customer has the physical credit card in his/her possession, and b) the card account is legitimate. CVV2/CVC2/CID data are printed only on the card; they are not contained in the magnetic stripe information per se, nor do they appear on sales receipts or statements. The use of these codes attempts to make it more difficult for a person who has stolen a credit card number, but not the actual card, to enter into fraudulent transactions, provided the other parry or parties to such transactions have also invested in the requisite changes to their systems and processes to support the use of these codes.
The prior art attempts, with mixed results, to solve the common problem of how to authenticate and verify a transaction, such as purchase, funds transfer, account opening or closing or modification, etc., particularly when conducted remotely or electronically, how to authenticate and verify the relevant party or parties, and how to provide the earliest possible warning of fraud, with a high degree of accuracy and completeness and near-zero delay.
U.S. Pat. No. 6,182,894 to Hackett describes systems and methods to use CVV2/CVC2/CID values, in lieu of PIN codes, to verify that a consumer engaged in a point-of-sale (POS) transaction possesses the transaction card at the time of purchase and/or is the true card owner. The CVV2/CVC2/CID information is provided to the POS system as an additional authenticating datum, and if said datum matches what is stored in the relevant authorization system for the applicable card account number, and authorizing parameters are satisfied, authorization proceeds. If not, authorization is denied. Such systems and methods do not protect against card theft or hacking (should such CVV2/CVC2/CID data flow from the consumer to the merchant or card processor electronically, or are stored on an intermediate system), because they authenticate only that certain data from the physical card match data stored in the authorization system, without authenticating the identity of the card holder/user, and without verifying the intentions of the true card owner or other co-authorizing party (if different). Further, they do not provide the advantage of notification of the true card owner or other co-authorizing or auditing parties of the occurrence of a transaction, and in particular a high-risk transaction. Finally, such systems and methods also fail to provide for any additional automated data gathering, authentication, and verification for and by the party regarding the opening, closing, or modification of an account remotely.
U.S. Pat. No. 5,727,163 to Flews describes a system and method for concluding a transaction by telephone that was initiated over the Internet. The purchaser dials a special telephone number associated with the transaction and provides his/her credit card number in full by dialing it on his/her touch-tone keypad (that is, using DTMT tones). Such a system and method have the advantage of partially isolating private payment information across two different communication links, but do not address the problem of notification or authentication of the legitimate account holders or other parties having a potential interest in the transaction, nor verification of the intent and approval of said legitimate account holders or other parties having approval authority for the transaction. Instead, they provide assurance solely to the purchaser that his/her private financial information need not be communicated in full through a network perceived to be insecure (that is, through the Internet). Such a system and method, which require purchasers to take additional proactive steps to complete remote transactions, have had limited adoption by consumers and merchants due to the complexity they add to all affected transactions. This system and method are further limited to collecting payment data, such as a credit card number, for processing by the merchant's point-of-sale or ordering system, under the purchasing party's control. They do not provide for any additional data gathering, authentication, and verification for and by the party attempting to collect payment or open, close, or modify an account remotely, nor for and by any third party whose approval is normally required to conclude the transaction.
U.S. Pat. No. 6,324,526 to D'Agostino describes a system and method for providing a transaction code, supplied case by case by the purchaser's financial institution, in lieu of a credit card number for a purchase transaction. As has been noted, systems and methods based on dummy transaction or account number codes have had limited consumer acceptance because of the complexity to set up and use them. Such systems and methods attempt to address only the security of the purchaser's account information, by eliminating exposure thereof to a third party over a network perceived to be insecure (that is, over the Internet). Nor do such systems and methods provide for any additional data gathering, authentication, and verification for and by the party attempting to collect payment or open, close, or modify an account remotely, nor for and by any third party whose approval is normally required to conclude the transaction.
U.S. Pat. No. 6,270,011 to Gottfried describes a system and method for coupling a fingerprint recognition device to a credit card scanner. As has been noted, systems and methods of this type have extremely narrow application because of the need for the affected parties' physical presence, the associated cost of implementation and on-going support, and general public concerns over personal privacy when biometric devices are employed. Systems and methods of this type attempt to address only authentication of a purchaser's identity, and ignore notification of a party or parties who may be subject to identity fraud or fraudulent transactions.
U.S. Pat. No. 6,341,724 to Campisano describes a system and method for using the telephone number of a credit card owner, plus a PIN code, as an alias for the actual card number in a credit card transaction. This system and method replace the account number with another sequence of digits which is not printed or encoded on the credit card itself. Systems and methods of this type are a variation on the concept of a dummy account number, per U.S. Pat. No. 6,324,526 to D'Agostino, and provide the benefit of allowing a purchaser to make a credit card purchase without having to remember his/her card number. However, such systems and methods do not provide protection against the use of stolen account information, nor against the use of stolen dummy account information such as said telephone number and PIN. They further require credit card users to learn a new process for making credit card purchases, and require system and rule changes by merchants to allow the purchaser's telephone number and PIN to be used in lieu of a card account number. For debit card transactions, the purchasers would further have to supply two PIN values, one for the debit card account, the other for encryption purposes. Nor do such systems and methods provide for any additional data gathering, authentication, and verification for and by the party attempting to collect payment or open, close, or modify an account remotely; nor for and by any third party whose approval is normally required to conclude the transaction.
U.S. Pat. No. 6,023,682 to Checchio describes a system and method for communicating a credit card number to a payment-authorizing computer system from a point-of-sale credit card terminal, using encryption where the key is a personal identification code (“PIC”) belonging to the card owner, and then verifying that the personal identification code matches that stored in the payment-authorizing computer system's memory. This system and method introduce the advantage of using personal information (such as a PIN code) to verify a card-user's identity, but also require changes to payment authorization systems and merchant's order-taking or payment-processing systems to implement, further require the purchaser to supply his/her personal identification code to the merchant, and have utility only at a physical point-of-sale, that is, in a non-remote transaction. Because the PIC is communicated through the same process and media as the transaction itself, said personal identification code, particularly for e-commerce transactions, is vulnerable to theft via hacking of the merchant's systems or interception of the merchant's communications to the payment-processing bank or applicable credit card processing network. Such systems and methods also fail to provide for any additional data gathering, authentication, and verification for and by any third party whose approval is normally required to conclude the transaction.
U.S. Pat. No. 6,088,683 to Jalili describes a method for customers to order goods from merchants on one network, such as the Internet, and then complete the purchase via a second network, such as the telephone network, using “Caller ID” service or a call-back to check the customer's telephone number as a form of proof of the customer's identity, and involving an independent processing center that receives the customer's financial information over the second network in advance and stores it for future reference, The merchant uses the second network to deliver transaction details and the customer's ID to the processing center, which then uses the second network to receive or initiate contact from/to to the customer to check his/her identity and his/her purchase intentions. Said method revises the method described in U.S. Pat. No. 5,727,163 to Bezos, by moving responsibility for the exchange of the customer's financial information from between the customer and merchant over a second network at the time of the transaction, as per Bezos, to between the customer and processing center over a second network in advance of the transaction. In Jalili, the processing center also performs the step of debiting and crediting the accounts of the customer and merchant, respectively. Therefore, the utility of this method is limited to cases wherein both a purchaser and a merchant are independently willing and able to establish an advance relationship with, exchange private information (such as account information for the purchaser and merchant processing information for the merchant) with, and allow debiting/crediting of their accounts by, such a processing center prior to entering into a purchase transaction between themselves. The method is also limited to purchases, and particularly to purchases involving a single customer and a single merchant. The need for a preparatory process occurring over the second network, the need to use the second network to perform all steps to prepare and conclude a transaction other than the step of the customer's placing of his/her order, and the need to establish a processing center, also limit the utility of this method. Because the purchaser does not actually supply his/her payment information to the merchant, the method further creates an opportunity for fraud perpetrated within processing center, stemming from its unique position of trust between the two other parties. If, however, the processing center is not independent of the merchant, then any utility derived from the separation of the processing center from the merchant, such as the assurance to the customer that his/her private account information need never be transmitted directly to the merchant, is lost. The method also adds the complication of the merchant having to provide a new and additional or alternative form of customer identification information to the processing center in order to receive a customer's payment. The method also fails to provide for any additional automated data gathering, authentication, and verification for and by a party regarding non-purchase transactions, such as the opening, closing, or modification of an account remotely; nor for and by any third party whose approval is normally required to conclude a purchase transaction. The method also fails to address purchases or non-purchase transactions initiated other than via a network. Lastly, the method requires a new sort of account to be established, namely, the customer's registration with the processing center.
Additional weaknesses and limitations of the prior art in general include:
Systems and methods of physical recognition: Such systems and methods require deployment, training, and support of a new purchaser and/or merchant transaction-processing infrastructure on a wide scale (such as deployment of biometric scanners and related interfaces to payment systems) and require the physical presence of purchaser to interact with that infrastructure to complete a transaction. This solution is therefore highly limited in the scope of its application.
Systems and methods using passwords and ID codes: Generally effective for ATM and debit card transactions, such systems and methods are not used widely for credit card transactions. Passwords and codes (such as PIN codes) remain subject to theft (as by Internet hacking, card “skimming”, identity theft, etc.). Once a password or ID code is compromised, no further safeguards are possible, and entirely new customer accounts must be created. Passwords and ID codes are not commonly used, supported and enforced by merchants for credit card purchases.
Systems and methods using CVV2/CVC2/CID codes: Systems and methods utilizing such codes are presently limited to credit card accounts only, do not protect against the loss or theft, such as by hacking, of credit or debit-and-credit cards or card account numbers along with such codes, and do not prevent the fraudulent creation or subsequent modification of an account.
Systems and methods using verification of private knowledge: Such systems and methods are vulnerable to theft of private information via hacking, and identity theft. This is particularly troublesome internationally, where the most common type of private knowledge checking in the U.S. for credit card transactions, namely, an account's billing addresses, is rarely possible today abroad.
Systems and methods using smart cards: While smart cards add password (PIN) features and can also create dummy credit card numbers usable for one transaction only, systems and methods utilizing smart cards require the installation and use of a smart card reader by the user, and have thus had limited adoption by consumers. These special features are further available only when purchases are made via the computing device where the smart card reader is installed.
Systems and methods using digital signature information (“E-Wallets”): As with smart cards, systems and methods for e-wallets require specialized software to be installed on the computing device of the e-wallet's owner, and therefore have not been widely adopted by consumers. Their features are likewise only available for purchases made via the computing device where such software is installed.
Other limitations and weaknesses in the prior art: Notification of a transaction, and any interaction with the actual party or parties who are truly authorized to conclude and approve it, as opposed to interaction with parties who are perpetrating fraud by representing themselves as said actual, authorized parties, is generally left unaddressed by the prior art. Notification or interaction which does occur in the prior art is typically after the fact, either by the actual, authorized party's reviewing his/her billing or account statements, by consulting his/her credit report via a credit reporting agency, or, if the payment processor (for example, the relevant credit card processor or bank) so determines, through a follow-up telephone call from a customer service representative of such credit card processor or bank, or through other messages delivered after the fact through a variety of basic communications media. These inherently after-the-fact processes do not interrupt or halt a fraudulent remote transaction before it is completed, nor can they halt additional fraudulent transactions (which may fit within a purchaser's normal risk profile) made quickly thereafter using the same account number or other identifying information. Prior art which attempts to address the objective of verification of a transaction before it is concluded adds prohibitive requirements for the establishment, registration with, and use of intermediaries such as processing centers between customers and merchants, fails to address the objectives of notification and approval of or by third-parties, and fails to address the class of transactions comprising the opening, closing, and modification of accounts.
It is desirable to verify and authenticate a transaction, and in particular a potentially risky transaction, without relying on the installation and use of new equipment by one or more of the parties having an interest in, involved in, or represented to be involved in, said transaction, nor requiring substantial alterations to existing processes or additional education and training for conducting such transactions, nor requiring new intermediary entities to be established. It is further desirable to do so in a manner that thwarts any potential party to such a transaction who attempts to authorize or enter into it fraudulently. It is further desirable for such verification and authentication to work even when the mechanisms, systems and methods described in the prior art may already be in use but still fail to protect fully against fraud, especially when fraud is perpetrated as a result of the theft of private information. This is especially important in the area of transactions conducted remotely, and in particular electronically. It is also desirable to notify automatically the actual party or parties having legitimate authority to approve or audit a transaction, whether directly engaged in such transaction or not, of the occurrence and/or details of said transaction. It is also desirable to be determine the behavior of any embodiment of a system and method for such notification, verification and authentication, through the use of stored profiles of parties and transaction types and other parameters, and also through profile information and other parameters which may be provided with and as part of an individual transaction.
The invention described herein provides a method and system for verifying, authenticating, and providing notification-of a transaction such as a commercial or financial transaction, with and/or to at least one party represented or identified as engaging in said transaction or having a potential interest in said transaction or type of transaction, in particular a remote or electronic transaction, while it occurs and/or after it occurs, via one or more of a plurality of communication links and communication addresses associated with said at least one party, so as to create a higher degree of certainty that the transaction is non-fraudulent than is possible using any of the prior art, without introducing significant delay in the completion of legitimate transactions, and without requiring implementation of new equipment or software, or learning of unfamiliar processes or technologies, or establishment and use of separate processing centers or other intermediaries.
BRIEF SUMMARY OF THE INVENTIONIt is an object of the invention to provide a means of verifying and authenticating the identities and intentions of one, some or all parties represented or identified as engaging in a transaction or having a potential interest in said transaction or type of transaction while it is in progress, and/or soon thereafter;
It is also an object of the invention to provide a means of accepting or obtaining information and parameters about said transaction, including information about one or more parties represented or identified as engaging in or having a potential interest in said transaction, from a transaction-processing system or device, such as a banking transaction system or credit card authorization or risk assessment system, as it is processing the transaction;
It is also an object of the invention to provide a means of communications with and/or to one or more parties having a potential interest in the transaction, some of whom may be represented as engaged in the transaction through the use of identity-related data, such as an account number or numbers;
It is also an object of the invention to provide a means of defining, at the time of the transaction or in advance of the transaction, or both, which specific parties have a potential interest in a given transaction, and the nature of such interest;
It is also an object of the invention to allow said communications to occur over a plurality of communications media and/or communications links, to increase the likelihood of successful and secure communication with and/or to said one or more parties;
It is also an object of the invention to provide a means of defining, initiating and controlling said interactions and their content;
It is also an object of the invention to provide a means of obtaining and/or storing information about the nature, communication addresses, and other parameters of said one or more parties' communications devices used for said communications, to enable additional verification and authentication of the identity or identities of said one or more parties;
It is also an object of the invention, in its preferred embodiment, to allow the behavior of said preferred embodiment to be controlled and managed under varying conditions and circumstances in accordance with stored profiles and, additionally or alternatively, in accordance with information provided along with the transaction information;
It is also an object of the invention to provide a means, in its preferred embodiment, for the adapting the inventive systems' behavior based on prevailing conditions and circumstances regarding said transaction, which conditions and circumstances may change during or because of the utilization of the invention;
It is also an object of the invention to provide a means of recording and remembering the details of said transaction and the result or results of any subsequent communications for later review and use by the user of the invention;
It is also an object of the invention to provide a means of reporting and/or transmitting and/or forwarding a result or results regarding said transaction and said result or results of said subsequent communications.
Accordingly, the invention, to address the above and other objects, provides a system and method for verifying, authenticating, and providing notification of a transaction, such as a commercial or financial transaction, with and/or to at least one party represented or identified as engaging in said transaction or having a potential interest in said transaction or type of transaction, in particular a remote or electronic transaction, while it occurs and/or after it occurs, and in accordance with any parameters which may be supplied in or with information about the transaction, additionally or alternatively with any profile or profiles which may be associated with the transaction.
In the preferred embodiment of the invention, the occurrence of communications with said at least one party and at least one of a plurality of communications devices and associated predetermined communications addresses known to belong to said at least one party, using at least one communications link other than the communications link used to initiate the transaction itself, isolates the transaction medium or environment from the notification and/or verification medium or environment, such that a very high degree of accuracy and completeness of authentication and verification can be achieved with a minimum of delay, and without requiring any new authentication/verification technologies to be implemented or learned by the transacting party or parties.
The invention goes beyond current practices by providing a highly automated means and a method for, individually and in combination:
-
- 1. Notification, verification and authentication of any or all of the party or parties involved in, identified as involved in, and/or predetermined to have a potential interest in, a transaction while it is still in progress, and/or afterward;
- 2. Verifying and authenticating using a plurality of communications links which may operate on networks having near-universal, worldwide availability and high reliability;
- 3. Separating and isolating the communications link and/or medium of the initial transaction (for example, the World Wide Web) from the communications link(s) and/or medium or media used to verify and authenticate it (for example, the public switched telephone network, wireless networks, Instant Messaging services), in such cases as the transaction's primary medium is deemed insufficiently secure or insufficiently able to verify and authenticate a party or parties;
- 4. Utilizing a plurality of concurrent and/or sequential communications with and/or to a plurality of communications devices and addresses, using a plurality of communications links and communications media;
- 5. Attempting communications with and/or to any or all of the party or parties involved in, identified as involved in, and/or predetermined to have a potential interest in transaction using alternate communications links or media in the event that attempted interaction or interactions using the preferred associated communications link or medium fails;
- 6. Predefining and dynamically determining a plurality of sequences of actions and communications to be taken under differing conditions for differing transactions and differing pluralities of parties thereto, based on information and parameters regarding the transaction and/or user-definable profiles regarding transactions, types of transactions, and/or parties and potential parties involved in, identified as involved in, and/or predetermined to have a potential interest in such transactions;
- 7. Communicating with a third party or parties involved in, identified as involved in, and/or predetermined to have a potential interest in, who are not initially part of such a transaction (such as an employer, parent, or law enforcement official in performance of his/her duty), for purposes such as seeking such third party or parties' approval thereof, or to notify same;
- 8. Assigning one or more roles to one or more parties involved in, identified as involved in, and/or predetermined to have a potential interest in a transaction;
- 9. Interacting differently with each of said one or more parties based upon his/her ascribed role;
- 10. Avoiding intrusiveness in the consummation of the transaction, by eliminating the need to install and proactively use any new or unfamiliar equipment, software, processes, or purchasing methods by the party or parties having an interest in, involved in, or represented to be involved in the transaction;
- 11. Intermingling of parameter-based non-transactional information, such as sales, marketing, product or support information, with transaction and confirmation information in said communications, and
- 12. Predetermining and/or dynamically determining the format and content of said communications, such as via user-defined templates and/or scripts.
The preferred embodiment of the invention associates one or more predetermined communications devices and addresses, such as telephone numbers or wireless SIP addresses, with a plurality of parties who may have an interest in, be involved in, or be identified as involved in, a transaction, and related identifying information, which may include an account number or credit card number. Such identity, device and address information are preferably defined and stored in advance in a non-volatile storage or database in the form of a profile associated with each such party, or are additionally or alternatively provided to the inventive system within or along with information about a specific transaction.
When a transaction is initiated with reference to such party or parties, such as via identifiers such as credit card account number(s), bank account numbers, or Social Security Numbers (SSNs) or tax identification numbers, a central system then attempts to communicate via a plurality of communications links with and/or to one or more of said plurality of parties via at least one of each such party's known, predetermined communications device(s), to notify the party or parties of the transaction and, additionally or alternatively, to interact with the party or parties to authenticate and verify their identities, intentions and/or approvals in regard to the transaction. The invention further provides several alternative means and methods for establishing such communications with and/or to each such party, either in parallel or serially, in the event that the primary means and/or method associated with each such party is not successful. Each communication or set of communications is preferably governed by logic rules, which may be predefined or dynamically determined, and which may be encoded as a script to be executed in or by the central system, said rules being determined in part based upon a categorization of the transaction, the identities or a categorization of one or more of said plurality of parties, and/or other parameters obtained along with the information describing the transaction.
Because each such interaction occurs with the actual owner/user of the communication device at a known and predefined communications address (such as his/her pre-verified wireless SIP address), if any party engaged in the transaction is not the owner/user of said predefined communications address, then 1) the interaction by definition alerts the actual owner/user to a fraudulent transaction in progress, and 2) the fraudulent owner/user is thwarted, because he/she will be physically unable to authenticate him/herself using the communications device found at said communications address. Further, even if the fraudulent party is able to obtain such a communications device belonging to the true owning/using party, the fraudulent party must still supply further authenticating information presumed to be known only to the actual owning using party. Preferably, the communications linkage employed for such interaction is different from the communications linkage used to initiate the transaction, thereby further limiting the potential for fraud and for the theft of private information.
Additional utility may be derived when the user of the invention is in the role of a financial services organization, such as a credit card issuer, payments-processing network, merchant processor or acquirer, employing the invention alongside or within its transaction-authorization and/or account-management processes and systems to reduce transactional risk for its merchant and/or consumer customers. Such financial services organizations already have, in the normal course of their business, advance knowledge of potential parties to transactions, including identifying information and other parameters about such parties which may include their account numbers and their contact information, such as home telephone numbers, e-mail addresses, and wireless device addresses; knowledge of transactions relating to their customers as they occur; and a presumed relationship of trust with said potential parties to transactions. Their advance knowledge and existing trust relationships minimize their effort to implement and widely deploy the invention for maximum utility. In addition to the fraud-reducing and fraud “early warning” benefit of the invention, financial services organizations may also benefit from improved customer relationships through increased value-adding contacts occurring as a result of the use of the invention, and from the resulting higher level of service provided, Financial service organizations that employ the invention may also benefit from the utility of a reduced perception by their consumer and merchant customers of the risks of conducting transactions electronically or remotely. Note that the additional utility to entities in the role of financial services organizations is not inherently limited to such entities, nor is it the only additional utility they may obtain. This and other additional utility may be also be obtained by other users, whether utilizing a similar or alternative embodiment of the invention.
In the preferred embodiment of the invention, when a transaction message is received by the central system from a second system or device, the central system parses the received message, authenticates said second system or device, and then may use the parsed data values to determine or derive a set of corresponding rules that inform or define the central system's subsequent actions and subsequent communications with or to a relevant party or parties over a plurality of communication links. Such rules may be predefined, and if predefined are stored in advance in the central system's volatile and/or nonvolatile storage memory or database(s). The central system takes a plurality of actions according to said rules.
In the preferred embodiment, the central system may establish a plurality of communications links, which may include but are not limited to wireless and landline telephony, SMS and wireless text messaging, instant messaging, and electronic mail and other Internet Protocol (IP) transmissions, in a sequence defined by said rules, to reach a plurality of parties having a potential interest in, involved in, or represented to be involved in, said transaction. The central system attempts to communicate with and/or to each of said plurality of parties via at least one predefined communications device specifically associated with that party.
As each of said communication links is successfully established, the central system preferably delivers information to the corresponding party regarding the transaction, which information may include 1) the transaction details, which may include the nature or purpose of the transaction and/or a total price or amount, 2) additional information of potential value to said party, such as product-, sales-, service- and/or marketing-related information provided by the other party/parties or a third party or parties, and 3) other parameters, which may include identifying information regarding one or more of said parties. Said delivery of information is preferably composed and formatted by the central system per a predefined message template or script that may be related to the transaction or the type of transaction, the communications medium employed, and the language in which the party is known to be conversant. For example, in a telephone call, said delivery of information may be comprised of concatenated segments of prerecorded audio and/or text-to-speech synthesis.
Each such party may then be prompted to confirm his/her identity and intentions, which may include providing a PIN code, CVV2/CVC2/CID code (for a credit card), or other unique and private identifier(s), such as the initial letters of his/her mother's maiden name, which datum or data may be predefined to the central system, or may be supplied within or derived from the initiating transaction message. A confirming action or actions may be performed by said party via said communications link, using a means appropriate to his/her corresponding communications device. For example, on a telephone, DTMF digits may be pressed to convey the information prompted for by the central system.
Based on the results of said interaction(s) with said plurality of parties, the central system preferably computes or otherwise derives a result, which it then preferably transmits to said second system or device from which the transaction message originated, and/or to an associated third system. Further, based on said retrieved stored rules and/or said dynamically derived rules, the central system also preferably transmits one or more of a plurality of notification messages about said transaction and said result to one or more of said plurality of parties, over a plurality of communication links, and may also log said results in a nonvolatile memory or other storage or database for later retrieval, action, and for analysis, and/or for billing purposes.
The central system communicates through a plurality of communications links using a plurality of communications protocols, configured according to such rules as are to be supported and implemented in any specific embodiment of the invention. These communication links and protocols may include but are not limited to wireless and wireline telephony (which may include text-to-speech processing, recorded speech, DTMF tones, and combinations thereof), electronic mail, instant messaging fax, paging, Short Message Service (SMS) and other wireless text messaging, and other existing widely used services and protocols, as described more fully hereafter. In the preferred embodiment of the invention, the central system also provides a means to add and delete a plurality of types of communication links and protocols, as such types of communication links and protocols become available and desirable or cease to be available or desirable; and a means of receiving, translating, and acting upon a plurality of informational codes and formats of transaction message as may be provided by differing types of second system or device originating such transaction message under differing conditions.
The invention achieves a very high degree of accuracy and completeness of authentication, notification and verification of a transaction and the identity and intentions of one or more of the plurality of parties represented as entering into or conducting the transaction, with a minimum of delay, and without requiring new authentication/verification technologies to be implemented or learned by such parties, by:
-
- a) Automatically communicating with and/or to the relevant party or parties represented as conducting a transaction, such as an electronic or remote transaction, using at least one communications link which is typically and preferably other than the one used to initiate the transaction itself, if any;
- b) Communicating with and/or to said party or parties only on communications devices having specific predetermined communications addresses known to belong to them, as a mechanism of additional authentication and verification;
- c) Additionally or alternatively, further verifying said party or parties' stated identities by cross-checking physical information known or discernable about their communications devices (e.g., telephone Automatic Number Identifier value) with other, external sources of identity information (e.g., a telephone number billing address database);
- d) Notifying said party or parties of the transaction's details, such as a merchant's identity, purchase amount, etc., through said communications devices;
- e) Additionally or alternatively, providing supplemental information of potential utility to said party or parties, such as sales, marketing, product and support-related information, through said communications devices;
- f) Additionally or alternatively, interrogating said party or parties to further authenticate their identities and/or verify their intentions regarding the transaction using said at least one communications link;
- g) Additionally or alternatively, further verifying said party or parties' stated identities and intentions by obtaining confirming input from said party or parties, through said communications devices, which may include passwords or other private knowledge (such as a predefined PIN code, predefined CVC2/CVV2/CID code, or several initial letters of a predefined security word such as a mother's maiden name) through said communications devices;
- h) Enabling communication with and/or to one or more of a plurality of parties related directly or indirectly to the transaction, some of whom may not have been identified or were not known to either the initiating parties or to the system or entity (remote to the inventive system) responsible for processing the transaction, and
- i) Supporting stored, user-definable profiles, rules, and parameters regarding such transactions and such parties, which profiles, rules, and parameters, in a preferred embodiment, are used to vary the behavior of the inventive system and thereby the sequence of steps followed in the inventive method.
- outside the transaction environment itself. The above advantages apply whether the transaction is still in progress, or after the fact.
In
The Transaction Message is received by the CS's [2] Data Messaging Layer [
The Transaction Message, if communicated over a public data network or other potentially insecure network, such as the Internet, may be further encoded or encrypted either in whole or in part by the RTE [1] for added security, such as with PM encryption or a similar standard encrypting protocol, such as the Internet's TLS.
The preferred CS [2] in general is further comprised of one or more processors; memories and data storage; software and software libraries, such as may be written in and accompany the C++ and Java programming languages, for handling and manipulating said message as described hereafter; an operating system for managing low-level elements of the system; security elements, such as firewall and/or encryption software, for limiting external access to the system, encrypting content, and defending against various forms of electronic attack upon it; and, database or other data-managing software, to store, manage, and perform searches and retrievals on information about parties, transactions, transaction processing rules, communication methods, and the like, as more fully described hereafter. The CS [2] is additionally comprised of a range of communications hardware and software, collectively referred to as the “Communications Subsystems,” which are used to notify or interact with one or more of a plurality of parties represented or identified as engaging in a transaction or having a potential interest in a transaction. Said Communications Subsystems [211-218.ff.] are described further hereafter.
The minimum necessary contents of said Transaction Message are shown in
Additional data fields and values may be supplied in the Transaction Message to further define the party or parties' communication addresses to be used in authenticating this transaction [23c,f, ff., 23d, ff.]; a specific stored Rule Set (see below) to be invoked [23i]; a specific stored message content template to be used either for this transaction in general [23j,k] or for each party [231, ff.]; additional information to transmit to the relevant party or parties during the communications sessions which follow [23o,p], and the like, as enumerated more fully in
The message protocol and format of the Transaction Message is defined according to the physical or logical port and/or communication service through which it arrives at the CS's [2] Data Messaging Layer [201], and additionally (for certain types of Internet messages) according to meta-tags and/or content-descriptor codes found at the start of the message which further define the formatting and content of the message. The message is parsed by the Data Messaging Layer [201] according to said format and protocol, and thereby decomposed into a series of name-value pairs which correspond to the data fields shown in
If the minimum required information as identified in
Where any name-value pair is not defined in the message, default values are looked up in the CS's [2] primary database tables and views [
If any of the parties is a member of a Party Group, either by prior association therewith through the CS's [2] Parties database view, shown in
-
- SELECT DISTINCT [Party ID], [Party Role] FROM [Groups] INNER JOIN [Transaction Parties] ON [Groups].[Party Group ID]=[Transaction Parties].[Party Group ID] WHERE [RTE ID]=$PartyID[0]$;
- (where $xxx$ indicates substitution of the value of environment variable ‘xxx’, per
FIG. 26 , and [Transaction Parties] comprises the IDs of the parties who were specified in the original transaction message received from the RTE [1]).
In this way, certain transaction types for a given party may automatically spawn communications with additional parties, such as an employee's work supervisors or auditors, a minor's parents, or law enforcement personnel, without requiring explicit mention of such additional parties in the incoming Transaction Message. Such Groups are preferably user-definable in advance, via the mechanism of the Profile databases [
Each party is given a Role in accordance with its Profile [
Once the incoming Transaction Message's contents are validated, the full list of target parties and their roles is defined, and all relevant name-value pairs that enable subsequent processing are established, then a software-based object or other data structure (the “Transaction Object”) containing these data is created in the CS's [2] volatile and/or nonvolatile memory or storage. The Transaction Object is then queued for subsequent processing by the Rules and Script Processing Layer [202] (“RSP”) of the CS (2).
The RSP [202], in addition to sharing the basic elements of the CS [2] as described above, is comprised of programming and database logic for the execution of both stored and dynamically-defined Action Scripts, where such Action Scripts define generalized, parameterized processes for communicating with and/or to one or more parties. The basic functions and components of such Scripts are shown and described in detail in
The RSP [202] draws on the queue of work created in the CS's [2] memory or other storage by the Data Messaging Layer [201], each work item being one Transaction Object comprised of 1) name-value pairs describing the transaction, as manipulated by the Data Messaging Layer [201] and available to scripts as Environment Variables (see
Transaction Objects may be drawn from this queue in sequential order, unless there is an overlap among the identified parties of two or more such Transaction Objects. In such a case, the following logic is preferably applied: 1) If the parties' roles are all, for example, “Notify” [per
The Script associated with a given Transaction Object may preferably be determined as follows. First, the Rule Set [
Once the Rule Set is known and associated with the Transaction Object, its record in the Rule Set database view may be used to provide the following information, which may be used to control the further processing the transaction, per
-
- Message Template ID [5b], along with the Transaction Language [5d], defines what message template (per
FIG. 10 ) will be used to generate the contents of the actual communications with the party (or parties) for this transaction. This value becomes an Environment Variable (seeFIG. 26 ) for the transaction. - Message templates consist of free-form text with embedded field substitution codes and file insertion codes, which may be of a form such as “$xxx$”, where ‘xxx’ is the name of an Environment Variable (see
FIG. 26 ), $file://yyyyy$ where ‘yyyyy’ is a filepath on the Central System [2], and $=zzzz(xxx1, xxx2, . . . )$, where ‘zzzz’ is a script function name and ‘xxx1’, ‘xxx2’, etc. are Environment Variables passed to the function identified by ‘zzzz’. In the “file” case, the contents of said file are inserted in the message template in place of the “$file:// . . . $” marker. In the other two cases, the variable or function is evaluated and the results thereof are inserted in place of the substitution marker.- A message template is defined by an ID and by a language, such as “English”. Therefore, a single message template may have multiple instances across multiple languages, distinguished by the values in the “Language” field from record to record.
- Message Template Stylesheet URL [5c] alternatively or additionally allows a web-based stylesheet, such as an XML-based (i.e., XSL) document, to be retrieved and used to format the aforesaid message to the party (or parties), via reference to a Universal Resource Locator (URL). This provides the advantage of allowing the operator or user of the RTE [1] to dynamically redefine the presentation of information to the relevant parties merely by updating an accessible web site with a new presentation format applicable to one or more of the transactions said RTE [1] may originate.
- As such, this aspect of the inventive system is an important innovation, by providing its users with a programmable message content and formatting mechanism that need not be maintained in or supplied to the inventive system, but may instead be incorporated dynamically, by reference, at the time the transaction is processed.
- Transaction Language [5d] is used along with the Message Template ID [5b] to define the message template.
- Transaction Currency [5e] is used when financial amounts are referenced in the communication to or with the party or parties.
- Confirming Value Type [5f] defines what form and format of datum is required as input from the party to successfully authenticate and verify the transaction and the party's identity. It may be a value such as “PIN” for a PIN code, or “CVV2,” “CVC2,” or “CID” for a credit card confirmation code, for example.
- External Media Address Reference Flag [5g], if True, indicates that an external database call shall be made to a service provider [
FIG. 1 , 12, “Remote Data Sources”] or other external data source which can provide additional information about the party's communication address or identity, such as the billing telephone address for the party's home telephone number, for cross-referencing and/or logging purposes and/or for later use in computing the result for the party. - Allowed Media [5h] encodes, such as in a text string or binary value, the types of communications links and/or media applicable to this type of transaction for this party. This media list acts as a filter on the party's communication profile records [
FIG. 6 ], limiting the communication link alternatives for the party to only those link and/or media which are coded for in the Allowed Media [5h] field. For example, the party may have e-mail as one communication preference, but for a certain transaction type, the Allowed Media [5h] filter value keeps e-mail from being used to authenticate and verify the party and his/her intentions for the transaction, for example to avoid the time-delay and relatively low level of security associated with e-mail-based communications, while for other transaction types, e-mail is still used, in accordance with the Profile. The RSA [202] insures that in no case are fewer than one communication link alternative in force under any circumstances, even if the use of that one alternative would otherwise violate the Allowed Media [5h] filter. - Script ID [5i] defines which Action Script [
FIG. 9 andFIG. 26 ] is to be employed for the transaction. (The Script defines how the CS [2] will interact with the party or parties hereafter.) - Default Communications Sequence Pattern ID [5j] identifies the default communication strategy to be used when attempting to reach the party or parties. This value may be overridden by any Communication Sequence Pattern [
FIG. 6 , 6n] defined in the CS's [2] databases, or in the Transaction Message, for any specific party or parties for this transaction type.
- Message Template ID [5b], along with the Transaction Language [5d], defines what message template (per
Once the above data have been gathered and stored in the system's memory or other storage along with the other transaction information aggregated into the Transaction Object, the RSP [202] executes the aforesaid Script. In general, Scripts preferably 1) attempt to establish communication link sessions simultaneously with all relevant parties associated with the transaction, and where possible, 2) deliver messages to the parties over such communication link sessions, 3) prompt for and accept input from the party of parties defined as having, for example, “Confirm” Roles [
An important advantage of the invention is the adaptive logic represented by such Scripts, in lieu of a static process logic mechanism that executes a single statically-defined sequence of instructions in every case and under every condition.
In general, for each party, the preferred embodiment's RSP [202] will perform the following standard actions under the control of the Script [5i]. Note that communications to multiple patties will occur simultaneously (unless directed otherwise by said Script) via concurrently executing, asynchronous system processes in the CS's [2] Communications Control Layer [203] (“CCL”). The process flow for the preferred embodiment of the invention, with the RSP [202] executing a Script, is diagrammed in
-
- 1. Perform an external database or data service query or reference [B], as of, for example, a telephone number billing address database, using relevant data about the party as a key (for example, his/her telephone number), to gather external data about the party for use in computing the result for the party and the overall result message to the RTE [1], provided the External Media Address Reference Flag [
FIG. 5 , 5g] (see above) for the transaction's Rule Set is True [A]. - 2. Consult the party's Communication Profile record [
FIG. 6 , 6a-c, 6i-o] for this transaction type and account number (if applicable), using an SQL query or stored (database) procedure, and then:- a. Group all the corresponding communication devices, addresses, and media for the party by their Communications Sequence Group [61] (“CSG”) number, if applicable;
- b. Where no CSG number is assigned to a communication device, a distinct temporary CSG is assigned by the RSP [202] to each such device;
- c. Order the CSGs by the associated Communications Priority [6m] number; this step defines the order in which the party's communication devices will be tried, with the Group mechanism of step (a) collecting multiple devices to be tried together simultaneously;
- d. Identify i) the party's Role [6k] for this device, address, and media type (noting that not all supported devices and media types necessarily support two-way interactive communications), ii) the expected Confirmation Value [6o] if any, for “Confirm”-type parties (noting that this value may have been additionally or alternatively supplied in the incoming Transaction Message from the RTE [1] and the confirming value may be stored in this field if the CS [2] is securely operated by the financial organization which supplied this value for the party's account [6c], and may be omitted in other cases, or at the financial organization's discretion. When omitted, any Confirming Value [6o] must be supplied by the RTE [1] in the Transaction Message received from the RTE [1]—ideally with encryption applied), and iii) the Communications Sequence Pattern ID [6n].
- The above steps (a)-(d) are aggregated in
FIG. 25 as process box [C], “Select Party's next device Group (CSG)”. - 3. For each Communications Sequence Group [6i] for the party, in ascending order of Communications Priority [6m], initiate simultaneous, multithreaded communications sessions to all devices within said CSG [61] via the Communications Control Layer [203] (“CCL”) [
FIG. 25 , D]. The CCL [203] initiates such sessions via commands it issues to the Communications Subsystems [FIG. 1 , 212-218 ff.] - A Communications Sequence Group [61] with more than one communications device and address in it causes the CCL [203] to attempt to reach a single party simultaneously on a plurality of his/her devices and addresses. The first such contact attempt to succeed [E] becomes the sole active communication session to the party, and all other sessions are immediately, automatically terminated [F]. This is accomplished through the CCL's [203] monitoring and analyzing session-progress events [per
FIG. 8 , 8k: “Generate Event on Connection Flag”] generated via the various Communications Subsystems [FIG. 1 , 211-218 ff.]. In practice, most Communications Sequence Groups [61] will contain just one device and addresses, and thus just one communication session at a time will be attempted for each party. - Once a communication session is successfully initiated with a party on a given device and at a given communication address (such as a telephone with a particular telephone number) in a “Confirm” Role [
FIG. 6 , 6k;FIG. 7 , 7e], as perFIG. 25 [1], no further attempts to interact with that party in its “Confirm” Role for the current transaction are preferably made. However, further communications may preferably continue to occur in a “Notify” role. This may be accomplished by the CCL [203] setting a flag or semaphore (FIG. 25 , 1] for the party (such as the PartyConfirmed[n] Environment Variable perFIG. 26 ) once one “Confirm” contact has occurred, such that further “Confirm” devices are ignored by the CCL [203] for the current party in the current transaction [FIG. 25 , M]. - This feature contributes a special advantage of the invention, by allowing a given party to engage in contact with the inventive system in multiple Roles for the same transaction, such as, for example, a “Confirm” Role on his/her mobile Instant Messaging device and a “Notify” Role to his/her e-mail system.
- 4. Each communications device for the party has an associated user-defined Communications Sequence Pattern [
FIG. 8 , 8a] that is used to manage the attempts to reach and establish a communication link session with the device; for each such Pattern, consult Communication Sequence Pattern (8a] database record, via SQL query or stored (database) procedure, to obtain the following parameters, or the equivalent, in a preferred embodiment of the inventive system:- Interactivity Flag [8b], which specifies whether input from the party is possible from said device;
- Outbound Inbound [8c], which specifies whether the communication link is to be initiated by the CCL [203] or by the party communicating inbound to the CCL [203];
- Attempt Timeout Value [8d], which sets the time before an attempt is deemed to have failed (for example, for a phonecall with multiple rings and no answer);
- Sequence Timeout Value [8e], which sets the total time before an entire Sequence is deemed to have failed if no successful connection occurs;
- First Attempt Delay [8f] which postpones the first attempt at communication link session by a fixed amount of time (for example, to allow a party to switch his/her line from data to voice mode on a dual-purpose communication device);
- Smart Retry Flag [8g], which, if True, instructs the CCL [203] to time subsequent communication attempts based on the outcome of the prior attempt (for example, retrying a phone number sooner if the last result was busy, vs. ring-without-answer);
- Maximum Number of Attempts [8h], which defines a total number of attempts allowed before conceding failure;
- Attempts Spacing [8i], which defines the timing between subsequent attempts, and alternatively or additionally, between specific attempts in the Sequence;
- Action on Final Failure [8j], which defines whether upon the ultimate failure of the sequence, a new sequence should begin (e.g., a Sequence Pattern in which the system waits for the party to call it), or not, and
- Generate Event on Connection Flag [8k], which, if True, instructs the communication process executing the connection attempt to send an alert event to the CCL [203] upon success. This event is used in conjunction with Communication Sequence Groups [61] to identify which of a series of simultaneous communication link attempts to a party's several devices has succeeded first, and is thus to be continued, the rest being terminated.
- 5. Dispatch these data, via the Transaction Object's Script, to the CCL [203], which creates individual software processes and/or threads of execution for each potential communication link session based on the aforesaid parameters. (See
FIG. 25 , “Script Execution” process block.) These processes record in the CS's [2] memory and/or databases or other storage the results of all sessions and session attempts for each party for each transaction for later computation [L,R]. The design and processes of said communication sessions is described hereafter.
- 1. Perform an external database or data service query or reference [B], as of, for example, a telephone number billing address database, using relevant data about the party as a key (for example, his/her telephone number), to gather external data about the party for use in computing the result for the party and the overall result message to the RTE [1], provided the External Media Address Reference Flag [
Once each party's communication session a) occurs successfully and, if in a “Confirm” Role, obtains the required input from the contacted party [
Note that in a large-scale embodiment, the inventive system is likely to process a large volume of Transaction Messages and Transaction Objects concurrently, via multithreaded processing and load-balancing among multiple processors and subsystems, and its design should not be construed as requiring serial processing of Transaction Messages and Transaction Objects.
Communications Control Layer and Communications SubsystemsThe Communications Control Layer [203] of the preferred embodiment of the inventive system coordinates and manages the activity of the Communications Subsystems. The CCL [203], in addition to sharing the basic elements of the CS [2] as described above, is comprised of software specific to the establishment and management of simultaneous communications link sessions across a plurality of media. Said software may be implemented using such software frameworks and with such application development tools and platforms as CallXML (an open-source mark-up language for creating server-based interactive telecommunications applications) or the Adaptive Communications Environment (an open-source software framework and library for managing signaling, events, dynamic reconfiguration of services, and concurrent process synchronization for multithreaded real-time communications).
The Communications Subsystems are of three general types: 1) telephony-related for voice and audio communications, 2) Internet- and data-related for data and text messaging, and 3) specialty data-network related, for certain other types of data transfer such as EDI and SNA/RJE. The Communications Subsystems are each comprised of hardware and software for transmitting and receiving signals to and from a specific class of devices (terminals) over a particular communications link or links or communications network or networks using a specific protocol or family of protocols. Each is further comprised of a collection of logical and physical ports, or other equivalent interfaces, each capable of sustaining concurrent communications with one, or more where applicable, individual device(s) and/or terminal(s) across a corresponding communications link or network. (Said devices and networks are presumed to be external to the inventive system, but in other embodiments need not be.)
A high-level representation of a subset of the communications links and media supported by a preferred embodiment of the inventive system is shown in
The Communications Subsystems provide a layer of abstraction to the CCL [203], which is then able to interact with the various communication media and devices of the party or parties to a transaction in terms of generic communication sessions.
The following tables relate the communications devices and media and the networks which support them, per the aforesaid Figures. The first table identifies the media explicitly shown in
The following table shows media, networks, and devices are covered indirectly in
The CCL [203] initiates one or more concurrent, multithreaded processes which queue requests to obtain communication ports from one or more of the Communications Subsystems [
The preferred embodiment of the inventive system provides for three generalized sequences for contacting a party: 1) attempting to reach each device associated with that party sequentially, 2) attempting to reach each device associated with that party in parallel, and 3) combinations thereof. Further, each device may be tried several times in succession until contact is established with it, as defined in its associated Communications Sequence Pattern [
The inventive system also provides, through a corresponding Communications Sequence Pattern definition, a mechanism to allow a party to initiate contact with the system within an allowed time interval, using the Environment Variable “Inbound/Outbound” [
When attempting to establish contact with a party's device, the appropriate Communications Subsystem executes a cycle of attempts, the timing of which is defined by the values for the corresponding Communications Sequence Pattern's fields, shown in
-
- First Attempt Delay [8f], if specified, provides for a user-defined time to elapse prior to the first contact attempt, so that, for example, the party may change a dual-use line from data mode to telephone mode for the purpose of receiving a telephony-based contact.
- Smart Retry Flag [8g], if True, indicates that the Communications Sequence Pattern for the device shall be self-modifying (under the control of the CCL [2031] based on the outcome of each successive contact attempt. Particularly for telephony-based communications, this mechanism allows the inventive system to change the timing and quantity of future attempts based on the condition of the device (or network) being reached, as reported by such network to the respective Communications Subsystem interface. For example, Instant Messaging services provide a status indicator which may include values such as “Active”, “Busy” or “Off line”; telephony networks respond with, among others, answer-supervision (i.e., signaling that the call has been answered), busy signals, or repeated rings without answer. Smart Retry provides, for example, for increasing the frequency and number of attempts in “busy” cases, decreasing in “off line”/“ring no answer” cases.
- Maximum Number of Attempts [8h] defines the total number of attempts the inventive system should make to reach a device before the respective Communication Sequence Pattern is deemed exhausted. This value may be modified dynamically by the CCL [203] if the Smart Retry Flag [8g] is set.
- Attempts Spacing [8i] defines the time intervals between successive attempts, either as a general value, or as specific values for each attempt in the Sequence. This value may be modified dynamically by the CCL [203] if the Smart Retry Flag [8g] is set.
As shown in
For the first successful “Confirm” Role session and for all “Notify” sessions, as such Roles [
Particularly in the case of communications sessions requiring input from the reached party, the message may consist of multiple segments that are composed and delivered to the party's communication device serially by the appropriate Communications Subsystem.
If an input is indeed required [
The Script may define whether the input must be validated before proceeding, and if so, may give the party multiple attempts to enter correct information before abandoning the attempt. Such attempts at receiving input may further be governed by Timeout parameters (see
If input was prompted for, a corresponding Environment Variable flag is set (see
At the conclusion of any and all input-gathering and delivery of message segments, the communication link session is terminated (by the Communications Subsystem, and optionally by the party as well if the party reacts more quickly than the Communications Subsystem). The results may be stored [L] for use by the system later on.
If the session was successfully initiated (whether or not correct input was actually received), and was, for example, a “Confirm” Role session, as may have been indicated through the use of the aforesaid PartyConfirmContact[n] Environment Variable, further attempts to contact the party in a “Confirm” Role (or equivalent, based on the embodiment of the inventive system) are preferably disabled for the current transaction.
For all non-“Confirm” devices, and if a “Confirm” Role contact has not yet been made successfully on any “Confirm” Role device, for example, the processes/threads executing the Communication Sequence Patterns in regard to the corresponding devices continue.
After the failure of an attempt, the attempt parameters and corresponding failure data provided by the appropriate Communication Subsystem are preferably logged in the system's databases or other volatile or nonvolatile memory or storage and, if there are further attempts allowed, per the effective Maximum Number of Attempts setting [
If the attempt schedule is exhausted, the executing process may initiate a new process with a new Communication Sequence Pattern, if such additional Sequence is defined for use upon the unsuccessful exhaustion of the current one [
This mechanism, an innovative advantage of the inventive system, allows the chaining of Communication Sequence Patterns to arbitrary lengths, executing until success occurs or the final Sequence in the chain of Sequences fails. It is also possible thereby (if only sometimes desirable) to set up an endless cycle of communication attempts through self-referencing chains of Sequences, such that the inventive system will attempt to establish contact with a party indefinitely, until successful. This is particularly useful in the case of a transaction which, by its nature and that of its parties, indicates an emergency situation, such as an authorization transaction (non-commercial in nature) regarding the entry by some party to a restricted or secured area or system, or an extremely urgent and critical commercial transaction requiring immediate confirmation by a party not otherwise directly engaged therein at the time.
It is further possible and desirable, under certain conditions, to establish an inbound Communication Sequence Pattern [
The following Table 2 presents component technologies which may be used by one skilled in the art to construct the communications interfaces and links shown in
It is increasingly possible and practical for the physical interfaces and ports, such as those described above, to be substituted by Internet Protocol connections to service providers and service bureaus which accept IP-based inputs (such as SMTP-formatted e-mails) and translate and deliver such inputs to other types of device, such as fax, telex, and mobile browser-based devices. The inventive system, per its potential embodiment(s) described herein, does not purport to specifically require any particular interface type for the stated communication links or communication media, nor to require that message conversion occur within the inventive system, rather than in and by an external service provider's system(s). The full scope and capability of the inventive system and method are enumerated in the invention's claims.
Message TemplatesAs shown in
The use of a URL to supply some or all message contents is a powerful innovation, because it allows remote content and even remote templates to be included dynamically and programmatically on a transaction-by-transaction basis (that is, without requiring any user-initiated changes or updates to the inventive system or its databases' contents whatsoever).
A message template is defined by an ID and by a language [10b], such as “English”. Therefore, a single message template may have multiple instances across multiple languages, distinguished by the values in the “Language” field from record to record. A corresponding currency name may also be associated for use with financial content in the message template, as per
In some circumstances, a stylesheet retrieved and referenced by a Universal Resource Locator (URL) or Universal Resource Identifier (UDI) may be substituted for a stored message template or a message template passed to the central system [2] in the incoming Transaction Message. This powerful innovation allows mark-up methods of message content definition and formatting definition to be applied remotely to the inventive system, on a transaction-by-transaction basis, dynamically and programmatically (that is, without requiring any user-initiated changes or updates to the inventive system or its databases' contents whatsoever).
Rule, Profile, Script, Communication Sequence Pattern, and Message Template ManagementPrior to first use of the preferred embodiment of the inventive system, at least one entry is required in each of its various database views [
An authorized user may log into the inventive system and, upon being granted access thereby, may view data and log records related to his account and edit his/her Profile and select from among predefined Communication Sequence Patterns. (If a superuser, s/he may view and edit the accounts and Profiles, Rules Sets, and Communication Sequence Patterns of others within his/her proscribed range of access.)
In practice, parties having a potential interest in transactions which may be processed by the inventive system will tend to updated their own Profiles as may regard their preferred communication devices. Sequences of contact thereon, preferred language, and related Roles, for various transaction types which the operator or other user of the inventive system may provide to them, per the specific embodiment of the inventive system. The operator or other user of the inventive system will tend to manage and update all other information, particularly rule- and message-oriented information.
Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications and other uses will become apparent to those skilled in the art. Therefore, the present invention is not limited by the specific disclosure herein.
Claims
1-110. (canceled)
111. A computer-implemented system for providing a transaction, the system comprising:
- a transaction processing module configured to process a transaction and to communicate via a first communications link and one or more second communications links, wherein the transaction processing module:
- receives, via the first communications link, incoming information associated with a transaction;
- identifies at least one party associated with the transaction, wherein the at least one party is authorized to verify the transaction and is a non-merchant with regards to the transaction;
- transmits, via the one or more second communications links, a verification request to the at least one party to verify the transaction, wherein the one or more second communications links are different from the first communications link;
- recognizes an occurrence of an event;
- determines authenticity of the transaction based on the recognition of the occurrence of the event; and
- continues processing the transaction initiated over the first communications link.
Type: Application
Filed: Jun 23, 2010
Publication Date: Jan 20, 2011
Inventor: Alexander William EVANS
Application Number: 12/821,469
International Classification: G06Q 40/00 (20060101);
