CA2661577A1 - Method and apparatus for customer notification of use of identification - Google Patents

Method and apparatus for customer notification of use of identification Download PDF

Info

Publication number
CA2661577A1
CA2661577A1 CA 2661577 CA2661577A CA2661577A1 CA 2661577 A1 CA2661577 A1 CA 2661577A1 CA 2661577 CA2661577 CA 2661577 CA 2661577 A CA2661577 A CA 2661577A CA 2661577 A1 CA2661577 A1 CA 2661577A1
Authority
CA
Canada
Prior art keywords
customer
transaction
notification
present
issuer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA 2661577
Other languages
French (fr)
Inventor
Matt Magosse
Dane Ellis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to CA 2661577 priority Critical patent/CA2661577A1/en
Publication of CA2661577A1 publication Critical patent/CA2661577A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce

Abstract

A method of advising the customer upon the use of their customer identifier in the conduct of a transaction. Upon the use of the customer identifier and its submission to an issuer for validation or authorization, a customer notification is dispatched by SMS, e-mail or other communications method to an owner notification address held on file in respect of the customer identifier. The customer could set notification parameters, and in some cases could either allow or disallow the completion of the transaction. Customer identifiers of various types, used in both commercial and noncommercial transactions, could be protected from fraudulent use using this method.

Description

METHOD AND APPARATUS FOR CUSTOMER NOTIFICATION OF USE OF
IDENTIFICATION

This invention is in the field of e-commerce transaction systems and methods, and in particular deals with a method whereby a consumer is notified upon execution of an electronic transaction using a customer identifier associated with the consumer.

Background:
Over the past 10 or 15 years the transaction of business via the Internet, both in the business-to-business context as well as at a consumer level, has proliferated. Particularly in the consumer space, widened availability of personal computers and an increased comfort level with the use of e-commerce websites has resulted in far higher numbers of consumers who are prepared to transact business with various businesses through a website, using a credit card or other similar payment method.

One issue which can be seen as a threat to users of e-commerce systems in the transaction of their day-to-day business, and which also is likely hindering further or additional rapid adoption of electronic commerce transaction completion methods for other consumers is that of credit card fraud and identity theft.

Most financial institutions have not developed or employed software which allow for transaction approvals at point-of-sale locations without a requirement for matching the signature of the customer on the back of a credit card for example at the point-of-sale, but rather rely upon set parameters in the credit card used by the financial institution to authorize transactions when the transaction is sent through approved systems. In the instance of the completion of a transaction without signature verification, the customer has no way of knowing when his card has been compromised, breached or used without their consent by a third party until the account statement is later received.

There are various problems associated with the currently available technologies which are used for the sending and receiving of alerts regarding the use of customer identifiers or credit cards. While some of the technologies which are available for fraud detection are outdated and do not meet the needs of modern electronic commerce systems, others disclose a system where the customer will be notified and an authorization requested in advance of completion of the transaction. Still other methods claim to provide a real-time notification to the customer, but only when a transaction is confirmed at their financial institution. In many of the most basic embodiments, user detection of fraudulent card use is only detected when the consumer reviews their credit card statement - which whether carried out on paper or in an electronic format is a time intensive process and would more often than not be too late to fix anything if a fraudulent transaction is detected.

It would be desirable if there existed an apparatus or a system which would inform a customer each time that a transaction was initiated with their credit card or other similar customer identifier by providing the customer with the location, time and status of that transaction, in addition to an opportunity to respond to the financial institution in question in a timely manner in the event that it is felt by the consumer that the transaction which has been communicated to them has been initiated fraudulently.

It would also be desirable if there were a system available by which consumers could be briefly notified of the initiation of commerce transactions using their customer identifiers that would firstly function in a relatively high speed or high throughput environment, where the notifications for example could be dispatched by e-mail or SMS text messaging or the like.
In addition to providing a high speed and low bandwidth notification function, it would be desirable if the system or notification method which was created would really function in a "passive" manner, whereby the use of the system and the dispatch of a transaction notification would not necessarily require a confirmation from the consumer for the transaction to proceed.
This would allow for the use of lower function devices for the receipt of the notifications (SMS text messaging is specifically contemplated as a dispatch medium), and would not unduly hinder the speed with which electronic commerce transactions could be completed on behalf of consumers who had authorized or pre-authorized their business.

3umanary .

It is the object of the present invention to provide a method for customer notification of identification use which represents an advance over the current state-of-the-art in this area. This will allow for improvements in the detection and mitigation of credit card and identity fraud.

The types of identification use which it is intended to encompass with the method of the present invention include traditional financial methods of payment such as credit card numbers, gift card numbers and the like, as well as other financial or nonfinancial types of identification going as far as for example drivers licenses, passports and the like, so that a customer can receive notifications of the use of their various identifications and/or in an active environment or in certain transaction workflows can authorize the use of those identifications.

Generally speaking the method of the present invention accomplishes its goals comprising receiving at the issuer level [being the issuer of the identification question] notification of a transaction which relies upon or uses one or more customer identifiers maintained or administered by the issuer. The issuer will them through their computer system compare the details of that transaction request to a notification database which would include an owner notification address with respect to some or all of the customer identifiers issued or administered by the issuer. If there was an owner notification address contained within the notification database, the system of the issuer would then in accordance with any notification parameters contained in the system and either global or customer level generate a customer notification which would be dispatched to the customer using some type of a rapid communication method -- the communication method which is contemplated for the time being as either by e-mail or SMS text although other types of communication methods are also conceivable and considered within the scope of the present invention.

Beyond this most passive embodiment where a customer notification would be generated and dispatched to a customer upon receipt of the transaction request simply for informational purposes to make the customer aware of the fact that their customer identifier or identification has been used in the transaction, the second option is that a more active model could be implemented which would actually allow for the customer to authorize or disapprove a particular transaction by responding to the customer notification which is dispatched upon receipt by the issuer of the transaction request in question.

Implementation of the method of the present invention can be done either by creation of new hardware and software for integration into issuer level systems, or could in appropriate circumstances be deployed locally at the vendor or endpoint level although it is contemplated that security is maximized and market uptake is maximized by implementing this on the issuer at the backend so that it minimizes the need for any additional work at the endpoint.

In addition to the method of the present invention there is also contemplated the software of the present invention as well as the necessary hardware, all within the scope of the present invention- Specifically be added or modified database and communication software and database components which would be installed on the system of the issuer, or locally as required, are contemplated within the scope of the present invention.

In an embodiment of the method of the present invention where there is the ability for the customer to provide feedback or approval to the issuer by replying to a customer notification, additional actions could be triggered based upon the feedback provided -- for example transaction approval, transaction disapproval, credit card termination etc.

Description of the Drawings:

While the invention is claimed in the concluding portions hereof, preferred embodiments are provided in the accompanying detailed description which may be best understood in conjunction with the accompanying diagrams wnere like parts in each of the several diagrams are labeled with like numbers, and where:

Figure 1 is a flow chart demonstrating one embodiment of a method in accordance with the present invention, whereby a transaction notification is dispatched to a customer;

Figure 2 is a flow chart demonstrating another embodiment of a method in accordance with the present invention, whereby a transaction notification is dispatched to a customer and feedback is awaited from the customer in advance of finalizing the transaction;

Figure 3 is an illustration of a cell phone displaying an SMS text alert in accordance with the present invention, intended to demonstrate one embodiment of a transaction notification in accordance with the present invention;
Figure 4 is an architectural diagram of one embodiment of An Issuer computer system which would allow for the practice of the method of the present invention;

Detailed Description of the Illustrated Embodiments:

There will now be provided further background to the prior art methods which are overcome by the present invention, as well as the system and method of the present invention itself.

Prior art-There are two general categories of prior art which we outline herein for the sake of further demonstrating the commercial opportunity of the present invention and identifying shortcomings in the practice of those methods which will be overcome by the system and method of the present invention.

The first type of a prior art transaction approval method or authorization method which is practiced in the prior art and over which the present invention will present a significant advance is really not so much an automated transaction approval or processing method as it is a post transaction verification process. Specifically, one of the prior art methods of transaction review which is available at present to consumers whose credit cards or other customer identifiers are being used in either electronic commerce or storefront transactions is to simply review the transactions upon receipt of an account statement. When the paper account statement is received in the mail by the consumer, or if they have elected to receive statements electronically when the electronic statement becomes available from time to time, this method comprises basically verifying the contents of the statement against receipts or otherwise reviewing the contents of the statement to confirm that all of the transactions outlined on that statement are transactions which are rightfully items which should have been charged to the consumer.

If certain transactions on these statements are identified by a consumer in their manual review or reconciliation as suspicious or as transactions which were not authorized by the consumer, the consumer that needs to go through whatever type of a transaction challenge process exists with their credit card, if any, to potentially others seek further details or in a circumstance where fraudulent transaction has occurred to advise the credit card company of same. One of the first primary shortcomings of this process is the fact that it involves manual review of the statements, whether in electronic or paper format, which is not a task which most consumers find a lot of time for or enjoyment of, One of the other primary issues with this type of a review process is that there is typically a sensitive timeline associated with the identification and challenge of fraudulent transactions i.e. if the statement is not reviewed within 30 days or so it becomes more difficult to challenge of fraudulent transaction- Finally and most importantly, the delay involved in the process results in a far lesser ability to detect and deal with fraudulent use of a credit card or customer identifier insofar as it is not even possible for the consumer to review this statement until it becomes available to them in paper or electronic format and so it may be anything from a number of days to a number of weeks following the completion of the transaction before the information becomes available to the consumer. It would be desirable to provide a method which would allow for instantaneous or real-time reporting of transaction completion to the consumer so that if there was a circumstance of fraudulent use it would at least be remotely possible that the accepting vendor could be notified and a fraudulent transaction could be avoided.

The second type of a prior art transaction method which is provided for demonstrative purposes in the realm of electronic commerce transactions is an electronic commerce method whereby rather than a notification post transaction of the use of the credit card or other customer identifier, the consumer is actually the person who is completing an electronic commerce transaction via a website or similar method. In those circumstances, typically the consumer provides their credit card or payment details through a website during the conduct of electronic commerce transaction which is initiated or completed directly by them. Typically the vendor website through which the business was being transacted would operate in a secure environment i.e. SSL etc., and would be password-protected, but one of the primary limitations to this type of a transaction method in terms of the detection of fraudulent transactions is that really this method of transaction completion is driven directly by the consumer and so really this type of a method does not provide any notification to the owner of a credit card or customer identifier at the time of charging the amount of that transaction to the card, unless the user of the vendor system in this method is the cardholder and has set up the vendor system to provide an electronic notification to the proper e-mail address. In a circumstance where a fraudulent use is made of a credit card however, in this type of an e-commerce environment, the fraudster can simply set up a user account which they are using on the vendor website to provide any written notification directly to them rather than back to the holder of the credit card or customer identifier which is being used to pay for the transaction. One of the key means of overcoming this limitation is to associate some type of a communication mode such as e-mail or SMS text messaging directly with the credit card number at the financial level, rather than allowing for the set up or intervention of a vendor site or user account in the communication between the financial institution and the consumer. By associating a communication system and a specific means of communication directly between the financial institution or the issuer of the customer identifier in question and the consumer, one layer of "blindness" can he removed from the process. Even in a circumstance where a physical theft of credit card information results in an in person use in a fraudulent manner of the credit card of a consumer, by associating a communication method such as that proposed in the present invention at the financial institution level which would allow again for communication back to the rightful owner of that credit card upon its use in the transaction, even physical credit card abuse and fraud could potentially be detected or minimized in a better way than is presently possible.

Customer identifier:

For the sake of further discussion in the remainder of this document, one of the key concepts for understanding is that of the "customer identifier". The customer identifier is contemplated to encompass either a credit card number, in the context of a credit card which might be used either appropriately or fraudulently and for which the detection system notification system of the present method would be desirable, or it might also be the case that other types of identity fraud may also be detected or minimized using the present invention. For example in a financial context beyond the use of a credit card, and the consequent equation of a credit card number and other related information as an "customer identifier" it may also be the case for example that gift cards issued by a retailer, debit cards issued by a bank in jurisdictions where electronic banking was widely available or used, or other similar types of identifiers or account numbers could be protected by their use within the scope of the present invention.

It is even conceivable that the concept of a customer identifier within the scope of the present invention could be construed broadly enough to protect a nonfinancial account number or other similar piece of identification. ^o demonstrate a couple of examples let a remote end of the spectrum on that point, it could for example be the case that with the necessary adjustments the remainder of the method of the present invention as will be obvious to one skilled in the art, a customer identifier could for example be a (lLiV4L'S license - number -o---a passport number so that a consumer could even be notified in the proper context of the use of their drivers license number or passport number in a particular way. The system and method of the present invention could then potentially be used for example to notify a consumer that their drivers license was being used by someone to rent a vehicle, or to acquire further identification.

It will be understood that any type of a customer identifier from a credit card number through to these nonfinancial types of identification such as a drivers license, passport or any other type of account or identifier are contemplated within the scope of the present invention. The method of the present invention could be modified as appropriate to accommodate all of these types of customer identifiers and the necessary modifications will not only be straightforward but also obvious to one skilled in the art of database and e-commerce design and on that basis are contemplated within the scope of the present invention as well.

Owner notification address:

The second key definitional concept which is necessary to understand the system and method of the present invention, beyond that of the intended scope of an "customer identifier" as discussed above, is that of an owner notification address.

As is discussed elsewhere throughout this document, the key concept of the present invention is that the owner of a customer identifier, i.e. credit card etc., would receive a basic text or e-mail alert upon use of their credit card or other customer identifier in a particular type of transaction. Different types of alerts and communication medium can be contemplated in the will be understood that many types of communication medium which will accomplish the objective of being able to provide a fairly instantaneous and straightforward messaging conduit between an identity issuer and the customer will be obvious to those skilled in the art of e-commerce systems design and are contemplated within the scope of the present invention.

Two specific types of communication medium which would be used within the scope of the system and method of the present invention would be either e-mail or SMS text messaging. The necessary system components to provide for either an SMS text messaging or e-mail messaging alert system will be obvious to one skilled in the art but it is basically understood and contemplated that in the case of either such communication medium the basic information which is required is an address --an e-mail address or an SMS text address which is a phone number etc. The messaging address which is used for the purpose of delivery of alerts to a particular customer is contemplated to be the owner notification address, as discussed elsewhere herein.

Effectively what is contemplated here is that in order for the system of the present invention to properly function is necessary for there to exist a concordance of credit card numbers or other customer identifiers with the appropriate owner notification address in each case. On this basis when it is determined in accordance with the remainder of the method of the present invention that a customer alert is to be dispatched it can be dispatched to the appropriate owner notification address which is associated with the credit card number or customer identifier which has been used.

As is discussed in further detail elsewhere herein it is primarily contemplated that the ideal or optimal location for the maintenance of this information is at the issuer level. For example, the credit card issuer should be the one to maintain the actual owner notification address in respect of a particular credit card number, since this results in the ability to maintain a central owner notification address only a single Location and it is likely the case that the credit card issuer is the most secure step in a typical e-commerce transaction to maintain or administer that information.

it is far less likely that the information if maintained by the credit card issuer could be tampered with by a fraudster looking to quickly conduct a single fraudulent transaction through one particular vendor by setting up a new account or otherwise abusing a credit card number that they have acquired. Even in that circumstance where the credit card number is used by a fraudster to obtain goods or services the fact that they are not able at the individual vendor level to tamper with the assignment or correlation of an owner notification address with the credit card number or customer identifier will mean that the issuer of the customer identifier can communicate directly with the customer regarding the use of their customer identifier, with a far less likelihood of interference or inaccuracy than if the owner notification address were maintained at the individual vendor level which would allow for it to be easily set so that the notifications could be trapped or diverted by the fraudster and not put in the hands of the proper consumer or owner of the customer identifier in question.

Obviously where a customer has more than one credit card or customer identifier which is being monitored or handled in accordance with the method of the present invention, they may provide the same owner notification address in each case or different or notification addresses might also be used dependent upon what type of a business level messaging result was desired by the consumer.

For the sake of demonstration of the concept of correlation of owner notification addresses with particular customer identifiers, the following table is provided. This particular example contemplates a series of credit cards from a single credit card issuer as the series of customer identifiers, where:
Customer identifier (1) Owner notification address (2) 1 4567332594448501 jonsmith@hotmail.com 2 4567336525944801 3065553330@sms.saskte1.com 3 4543632594448505 chariesjones@gmail.com 4 4567300004448701 3065551212@sms.verizon.corn 5 !4567332511121501 3065551212@sms.verizon.com The five rows in this table are intended to demonstrate briefly the concept of a concordance of customer identifiers 1 with owner notification addresses 2 in accordance with the present invention. There are shown five rows in this table which represent five different customer identifiers 1, which in this case are formatted to be credit card numbers. It _s specifically contemplated that this type of information would be maintained at the credit card issuer level, so for example these five credit cards might all be credit cards issued by the same issuer. The owner notification address 2 which corresponds to each of these credit card numbers is also Included in the table.
It can be seen that the two specific means of notification or alerts discussed elsewhere above, namely e-mail and SMS text messaging, are contemplated or enabled by this type of information as shown in the table, since the owner notification addresses 2 contained within the table are formatted as e-mail addresses and SMS text addresses. As outlined above, other types of communication formats and media could be used and the necessary changes to the format or contents of the owner notification address 2 in the table such as this could be adjusted as necessary to effect of same. Also for the purposes of demonstration, it can be seen that the fourth and fifth rows in the table are two separate credit cards owned by the same customer, or at the very least which have been directed to the same SMS address 2 for notification purposes.

Association of customer identifier at issuer level:

One of the key concepts which will allow for the security and integrity of the method of the present invention is the fact that the customer identifier 1 with a communication method and owner notification address 2 which would allow for the forwarding of communications directly to the proper consumer who is the owner of that customer identifier 1 when within the scope of the method of the present invention such notification was necessary or desired.

Association of the customer identifier I with a particular owner notification address 2 will be understood by one skilled in the art of database and communications design but conceptually the key point here is that the owner notification address 2 in question needs to most desirably be maintained by the issuer of the customer identifier 1 in question, since they are the best suited place to maintain with integrity the concordance between particular customer identifiers and owner notification addresses and minimize fraud.

For example in the context of a credit card is best if the credit card company or the bank who is the issuer of that credit card maintain the owner notification address which would be used in the remainder of the method of the present invention, since the credit card issuer can likely best be relied upon to maintain this information in a central location which is least likely able to be tampered with by a fraudster. In the context of a credit card fraud, a fraudster will least be able to adjust the actual credit card company particulars associated with the credit card in question funless they have open access by theft of a password etc. to entire online access to the information and account details associated with that credit card in which case there is problem beyond the scope of the present invention]
-- there is likely a highest level of emotional comfort or perceived security for the consumer as well by having the actual credit card issuer take care of this information and administer the method of the present invention.

Similarly to extend this discussion to the concept of other types of customer identifiers 1 as discussed above, in the case of a gift card number for example or something along those lines, either the central issuer or administrator of the gift cards [in the context of a gift card program administered by a third.party company3 or the actual retailer having issued the gift card, the owner notification address 2 could be acquired or provided at the time of purchase or sale of a gift card and captured for use in that way so that when the gift card number was used the owner notification address 2 which was associated with that particular gift card at the time of its sale would be used to provide notification.

In the case of for example a passport or drivers license, the owner notification address 2 for the actual owner of the drivers license could be maintained by the provincial government motor license issuer and they could provide notification of the use in whatever context was appropriate of the drivers license number/customer identifier 1 of the consumer when they were in turn made aware of its use. In the context of these nontraditional or non-financial institution type of issuers, it may be necessary for the complete practice of the method of the present invention to require that companies using a drivers license for example as identification [for example rental car companies] need to actually conduct and authorization step of sorts electronically to actually validate the drivers license number back with its issuer, which could also then in turn trigger notification in accordance with the remainder of the method of the present invention. Use of the method of the present invention in this way wil be discussed in further detail below.

Intended commercial vendor audience:

The anticipated commercial applicability of the method and apparatus of the present invention is broad. Basically it is intended that the method of the present invention could, with appropriate hardware or software modifications, be implemented in many different formats to allow for its use or practice in virtually any commercial vendor environment.

Implementation of the system and method of the present invention at the issuer level in terms of credit cards or other types of financial customer identifiers 1, whereby the validation of the transaction and the notification of the consumer in respect of that transaction was undertaken at the credit card issuer level rather than at the individual vendor level, will also make things simpler in terms of potentially gaining market acceptance for the method of the present invention, since there would be no additional requirements for implementation of software or hardware changes at the vendor level in the necessary changes could really just be made in a limited number of places at the issuer level with no impact on the thousands of vendors who might be connected to authorize credit card transactions for example through an individual credit card issuer. Also, beyond the fact that it would be necessary to equate an owner notification address 2 with customer identifiers 1 in order for the method of the present invention to be used, there would also be no additional physical equipment or identification required for use by the customer or a vendor and as a result it is hoped that the minimal disruption of acquired point-of-sale habits would result in the easier widespread adoption of the present invention.

Overview of system caemponents and operation:

The goal of the present invention is to provide a system and method for the automated preparation and transmission of a customer notification 8 to a customer upon use of a particular customer identifier 1 associated with that customer in some type of a transaction. Reduction of identity and credit card fraud are two of the objectives of the present invention, It is intended that the scope of the present invention encompasses both the general business method or approach to the generation of customer notifications 8 as outlined herein, as well as the specific hardware or software tools or modifications which might be needed in order to make this system or method available in the marketplace.

Referring first to Figure 1 there is shown a first flowchart which demonstrates one embodiment of the method of the present invention, which is referred to as a "passive" embodiment insofar as what is contemplated in this particular Figure and illustrated embodiments is the issuance of a notification to consumers upon the commencement or completion of transactions using their customer identifier with no necessary need for customer feedback or authorization. In respect of this particular Figure in the embodiment, a customer's credit card number is conceived as the customer identifier 1 in question, and that is being used to conduct a commercial transaction in respect of which a customer notification 8 is desired to be generated. In the method outlined in this Figure, the vendor and the issuer in question have the necessary hardware and software in place in respect of the point-of-sale and transaction authorization systems to participate in the overall system or method of the present invention.

Looking at that Figure in further detail, there is shown at Step 1-1 the receipt of an authorization request 4 by an issuer 3 from a vendor 5. Tn the context of a commercial transaction where the customer identifier 1 being used as a credit card number, the issuer 3 would likely be the credit card issuer who was in charge of authorizing the transaction. As outlined elsewhere herein the invention is a system and method allowing for basic consumer level transaction authorization upon the use of a credit card or other customer identifier 1 in some type of a commercial transaction.

Where the customer identifier 1 is a credit card or other financial instrument identifier, the transaction type in question would likely be an actual purchase transaction. Where the customer identifier I is some other type of an identifier such as a drivers license, passport or other personally identifying information, the transaction in which someone may be seeking to use that information may or may not represent a commercial purchase transaction and it will be understood that all such types of transactions are contemplated within the scope of the present invention.

It is contemplated that the most secure method of providing the method of the present invention is to provide for the generation of the notifications of the present invention at the issuer 3 level, rather than the vendor 5 level. It will be understood and will be discussed elsewhere herein that the method of the present invention could also be offered by incorporation of the necessary software or hardware adjustments directly at the vendor level 5 and that is contemplated within the scope of the present invention as well.

In any event, once the transaction is initiated at a vendor 5 site, either electronically or in person, the vendor 5 system could transmit an authorization request 4 to the issuer 3. The authorization request 4 would typically outline the type of the transaction which was desired to be authorized or verified as well as including the customer identifier 1. At the issuer 3, the system could check a notification database 6 to verify whether or not with respect to the particular customer identifier 1 being used in this particular transaction there is an owner notification address 2 on file. If there was no owner notification address 2 on file the remainder of the steps in the method could be ignored -- this is shown as a conditional end step off of stage 1-2 in this Figure.

Alternatively if there was an owner notification address 2 on file in the notification database numeral six with respect to the particular customer identifier 1 contained within the transaction authorization request 4, the next step would be to determine whether or not a transaction notification 8 should be sent. It is contemplated that the system of the present invention could either on a customer by customer basis or on a default global level contain a series of transaction notification parameters 7. For example, either on a global or customer basis it may be determined that in the context of a commercial transaction they would only send a notification if the amount of the transaction was over a certain threshold amount or the like. The setting of transaction notification parameters 7 on the customer level is discussed in further detail elsewhere herein-for the purpose of this discussion, and the particulars of step 1-3 in this Figure, the details of the transaction authorization request 4, and the contents of any customer specific transaction notification parameters 7 as well as in the global transaction notification parameters 7 will be applied. The application of transaction notification parameters 7 is an optional step-it may be the case that there is no parameters in place to be applied and that in all cases a transaction notification will be issued to the customer. Both such scenarios are demonstrated by this flowchart.

Upon determination that there is an owner notification address 2 on file in respect of the particular customer identifier 1 identified in the transaction authorization request 4, and determining that a customer notification 8 should be dispatched upon the application of any transaction notification parameters 7, the final step in this simplest embodiment of the method of the present invention would be the transmission of a customer notification 8 to the customer notifying them of the use of their customer identitier 1, along with the details of the transaction in question. This is shown at Step 1-4 in this Figure. As outlined elsewhere herein, the actual dispatch of the customer notification 8 would likely comprise the sending of an e-mail message or an SMS text message.

Referring briefly to Figure 3 there is shown an example of the type of a notification which is contemplated in the context of the customer notification 8. It is specifically contemplated that the customer notification 8 would comprise a short SMS text message or an e-mail message outlining the details of the proposed transaction. There is shown in Figure 3 a customer's cell phone 14 which is one type of the device which could be used to receive customer notifications 8 in accordance with the present invention. In the particular case of this embodiment of the device and the customer notification 8, the notification itself is demonstrated as a basic SMS text message 8 which would appear on the cell phone when dispatched by the credit card issuer, in the context of a credit card transaction where the customer identifier 1 in question was a credit card number and the owner notification address 2 on file in the notification database 6 was the SMS address for the cell phone 14. Other examples of the types of communications which could be used as customer notifications 8 would include e-mail messages, for example to an e-mail enabled device or even to a desktop computer. It will be understood that all such types of communications formats and messaging options are contemplated within the scope of the present invention as long as they accomplish the same goal of providing electronic notification of the commencement or completion of a transaction with respect to a customer identifier 1 to the owner of the customer identifier 1 by way of a owner notification address 2 which might be stored in a central database.

Figure 2 is a flowchart showing an alternate embodiment of the method of the present invention which incLudes additional optional steps allowing for customer approval of the proposed or pending transaction. The first few steps of that process are the same as that shown with respect to the embodiment of Figure 1, namely at Step 2-1, the issuer 3 would receive an authorization request 4 from a vendor 5. The system of the issuer 3 would then, shown at Step 2-2, check a notification database numeral 6 within which customer identifiers 1 were stored in relation to owner notification addresses 2 where the customers in relation to those customer identifiers 1 wished to participate in the method of the present invention. Again, if it was determined that the particular customer identifier I in question was not associated with an owner notification address 2 held on file, the process would end.

Also shown again at Step 2-3 is the optional application of transaction notification parameters 7. As outlined elsewhere above, these transaction notification parameters if they existed at all could be set at either a global or a customer level. If it was determined that a notification 8 should be generated, this is shown at Step 2-4.

The difference between the embodiment of Figure 1 and the embodiment of Figure 2 is that it is contemplated that in the embodiment of the method shown in Figure 2, customer feedback could be provided to the custcmer notification 8. That customer feedback might comprise either an authorization for the transaction in question to proceed, or a denial of that transaction if the customer was not comfortable with the details thereof. In the case that a positive customer feedback was provided at Step 2-5, the transaction could be authorized and finalized, as demonstrated at Step 2-6, and alternatively if negative customer feedback was provided the transaction could be denied 2-7.

The types of customer feedback which can be contemplated here could take various formats. Insofar as what is contemplated is a fairly instantaneous and straightforward messaging method and process it might be as simple as the customer replying at all to the message containing the customer notification 8, the receipt of the reply itself by the issuer constituting an authorization or indication to the positive of the transaction proposed to be authorized. Alternatively it could for example be the case that if no feedback or a specific negative feedback indication was received, in addition to the denial of the particular transaction in question, the issuer in the context of a customer identifier 1 which was a credit card or bank card or the like could actually suspend or cancel the credit card in question if a negative feedback was sent by the customer.

Having outlined the general nature of the structure of the apparatus of the present invention and the basic operation or method contemplated, we will now outlined in further detail the conceptual details of the present invention.

Transaction types:

There are certain types of transactions and customer identifiers which lend themselves more obviously to use within the scope of the method of the present invention but it is desired to provide some further background here to fully a lab right on the types of customer identifiers 1 which it is conceived could be protected by use of the usage notification system and method of the present invention. The obvious type of transactions and customer identifiers which could be protected using this method are financial transactions both a point-of-sale or electronically or online, where credit cards are used. The credit card numbers would comprise the customer identifiers 1, and notifications in either the active or passive format could be provided to customers to allow them oversight of the use of their credit cards or similar financial accounts in various transactions.

Beyond a credit card it may be the case that a particular vendor is treated as the issuer themselves within the lexicon of the present application where for example the customer identifier 1 being used was an internal account number where a customer had a credit account or the like with a particular individual vendor and they wanted to protect the use of that account in this way.
It is also concede that the method of the present invention could be used to protect or monitor the use of other types of nonfinancial identification of a customer as well. For example, and as outlined in further detail elsewhere in this document, the customer identifier 1 might be a license number or a passport number, and rather than an authorization process per se, the method of the present invention might comprise simply a notification of use. For example it might be the case that a customer received notification that their passport number had been used as a piece of identification at a particular vendor or location -- no transaction authorization per se would necessarily be approved or provided at least the customer would receive at the very least notification of the use of their identification in this way. This would basically require a simple adjustment to transaction intake processes where these types of identification were used so that for example the issuers of passport or drivers licenses might require that a company or entity who wanted to use those as identification did a quick check online or in some way in the checking of that process would trigger the customer notification 8 in accordance with the remainder of the present invention. In a more elaborate such embodiment, entities using these types of nonfinancial identification for identification purposes even could be required or optionally could create a backend connection to the issuer database of the issuer of the drivers license or other identification, for the automated submission of transaction requests in accordance with the remainder of the present invention.

It will be understood based on this brief narrative that there is a broad reaching applicability of the method of the present invention in the quest for minimizing identity fraud and financial fraud and that virtually any kind of identification of an individual which it was desired to protect from unauthorized use could be morphed into an issuer notification database 6 such as that outlined herein so that the holders or customers of those pieces of identification or account numbers or the like could always be notified in accordance with their requests or requirements or with statutory requests or requirements of the use of their identification.

Passive versus active system:

Two types of systems or methods of the present invention are contemplated at a conceptual level here in terms of the behavior of the implemented system. It is explicitly contemplated that.

the method could perform in a "passive" way, whereby customer notifications 8 would just be generated and dispatched to the customer when the customer identifier 1 was used, and no feedback would be required or allowed to travel back from the customer and their device to the issuer 11. This would be along the lines of the embodiment of the method demonstrated in Figure 1. Upon receipt of the transaction authorization or notification request, the system of the present invention would simply dispatch a notification to the customer in accordance with any notification parameters 7 that were globally or locally programmed with respect to that particular customer, and this would comprise the entirety of the method with respect to that particular user in transaction.

In the second approach, the method would perform more "actively", whereby it would allow for the customer to provide feedback or authorization from their customer endpoint device such as a cell phone, e-mail client etc. back to the issuer 11.
Reference the embodiment demonstrated in Figure 2. In that particular case, demonstrating an "active" method, it is contemplated that it would be set up so that the customer could provide feedback by way of a reply to the notification message 8 back to the issuer 11 and those replies could generate or trigger alternate or different actions by issuer. For example the customer could either provide an approval, or even in a particular default setup by providing no response at all could approve, which would result in the completion of the transaction authorization. Alternatively the customer could send back an indication of a fraudulent use and numerous types of downstream action could be triggered by the issuer 11 on this basis. For example, the issuer 11 could decline the transaction but could also advised the vendor at the endpoint of the fraudulent nature of the transaction and require the seizure of the card if it was a credit card, or they could even trigger the cancellation of the credit card based either upon instructions or notification received from the customer or based upon rules programmed on the system of the issuer 11.

It is explicitly contemplated that both the "active" and "passive" methods of customer notification and authorization of identification use outlined are within the scope of the present invention.

Timing of customer notification:

Dependent upon the nature of the specific embodiment or method which is developed for the implementation of the present invention, the customer notification 8 where was determined to be generated and dispatched could he timed at different points in the process. In a more passive approach, the customer notification 8 could simply be generated and dispatched at the same time as completion of an authorization of a transaction or recordal of a transaction. In a more active model, referring to the active model of the method of the present invention outlined above where the customer would need to or could optionally provide feedback or confirmation regarding the use of their customer identifier 1, it would be necessary to actually dispatch the customer notification 8 in advance of the completion of transaction recordal or authorization. Both such approaches are contemplated within the scope of the present invention.

Issuer system:

It is specifically contemplated that the optimal embodiments of the system of the present invention would comprise the installation of the additional components for the practice of this method at the issuer level -- i.e. whichever authority was issuing the various categories of customer identifiers 1 in question whether that be a particular credit card issuer, drivers license authority etc. -- would be the most secure location within wt-rich to house a uuLLLiudLi.utu daLabast! 6 in accordance with the present invention which could be used to generate customer notifications 8 in accordance with the method hereof.

Figure 4 shows one embodiment of the system architecture of a issuer system which might be used in the practice of the method of the present invention. It will be understood that various types of software, hardware and system modifications will be understood to those skilled in the art which would allow for the rendering of system modifications or new systems of transaction and review or authorization which would result in the practice of the method of the present invention and all of those are contemplated within the scope hereof.

The architecture of the system outlined in Figure 4 is intended to demonstrate a number of the flexibilities or parameters which are anticipated in respect of the present invention, and to demonstrate the different types of hardware or interfaces which could be used in the practice of the method of the present invention.

Figure 4 really shows three separate tiers or categories of infrastructure which would be used in the practice of the system and method of the present invention. There is shown at 11 the issuer computer system, who would be at the core of the method of the present invention and would actually host the notification database 6 per se and would handle the generation of customer notifications 8 as required. The second general grouping of infrastructure or equipment demonstrated in that Figure are a couple of different vendor systems, in a commercial transaction context, shown at 13A and 13B, representing the endpoint sites where particular types of transactions might be taking place and from which authorizations are notifications were being generated which it was desired to handle in accordance with the remainder of the present invention. Finally there is shown a customer messaging system at 15.

In the case of the infrastructure shown, all of the various components are connected by one or more computer networks, which are particularly contemplated to likely be the Internet that will be understood by anyone skilled in the art of network infrastructure to encompass also other types of open or closed communication networks which might be used to communicate between some or all of the various components of the present invention and any other such communication networks or protocols are also contemplated within the scope of the present invention.

There is shown an issuer computer system 11 which could form a component of a transaction authorization or processing system and which would allow for the incorporation of the method of the present invention into or in place of prior art methods of customer notification of the use of their customer identifiers 1 with respect to various transactions- The issuer computer system 11 would be understood to one skilled in the art to comprise various database software components which could receive a transaction authorization request and would otherwise be capable of effecting the necessary steps to authorize and/or, in the case of for example a credit card or other financial customer identifier I charge to the account of the customer in question the transaction once authorized. In the system 11 shown in Figure 4, there is demonstrated the database server 14, which would contain the necessary computer software components 9 both in terms of an operating system as well as the other pre-existing or necessary authorization components to otherwise carry out the necessary business processes required by the issuer in the operation of the system 11 and the authorization of transaction requests being received from vendors or outside parties.

The primary element which has been added and is shown in the embodiment of the issuer computer system 11 demonstrated in Figure 4 is the notification database 6. A notification database 6 is contemplated to store the necessary information for the practice of the present method and invention which basically is the ability to store an owner notification address 2 with respect to at least one of the customer identifiers 1 administered by the issuer in question.

In its most basic iteration the information contained within the notification database 6 or related data structure in respect of a particular customer identifier 1 might just be the owner notification address 2. It will also be understood however that other information could also be contained within that notification database 6 in respect of a particular customer identifier 1 including customized notification conditions or parameters 7, which by their inclusion in the notification database 6 or related data structure could allow for further query, analysis or other capabilities on the content of the notification database numeral eight when that was desired or required by some extended functionality of the system of the present invention. It will be understood that the optional inclusion of this additional information in the notification database 6, either in the same table or in some other portion of the data structure as might be obvious to one skilled in the art, is contemplated within the scope of the present invention.
It may be the case that all of the customer identifiers 1 issued by a particular issuer have an owner notification address 2 associated therewith or it may alternatively he the case that only certain of the customer identifiers 1 have an owner notification address 2 associated their with and on that basis if not all of the customer identifiers 1 had the corresponding owner notification address 2 it would be the case that only certain customer identifiers 1 would trigger a transaction notification 8 in accordance with the method of the present invention when that particular customer identifier 1 was used.
Storage of the owner notification addresses 2 in respect of some or all of the customer identifiers 1 administered by a particular issuer could take place in a separate database table or structure, or it will also be understood to one skilled in the art that the necessary information for practice of the present invention might already be stored within pre-existing data structures of the issuer in which case the notification database 6 per se might not exist as a separate data structure but the information could be used from other places where stored in the data structures of the issuer 11.

It will be understood that while the issuer computer system 11 which is demonstrated in Figure 4 demonstrates a single server, that the incorporation of the necessary software or hardware components for the practice of the present invention or for the conventional or prior art practice of transaction authorization could be implemented on a single server or on a number of servers which may be located in the same physical location or may be physically separated and in communication with each other via a secure computer network. Again, variations in this type of network infrastructure or obvious to those skilled in the art and all such combinations of hardware and software which accomplish the goal as outlined here of transaction authorization or processing in addition to customer notification in accordance with the present invention are contemplated within the scope hereof.

The issuer computer system 11 can be seen to be connected via the Internet or another network cloud, shown at 12, both to vendor sites 13 as well as to a communications interface 15 by which customer notifications 8 could be dispatched. Shown at 15 is a radio tower which is intended to encompass or display both the capability of the issuer computer system 11 to dispatch for example SMS text messages as customer notifications 8 as well as potentially the ability to send via the Internet and e-mail notification to a customer rather than an SMS notification if that was the desired owner notification address 2 format or type which was provided by a particular customer identifier 1 owner.
The issuer 11 would be connected by an appropriate network interface to a network which would allow one or more endpoints to transmit transaction authorization or notification requests to the issuer computer system 11. It is also necessary that the same network interface, or another network interface, the present on the issuer computer system 11 which would allow for the notification of customers upon the use of their customer identifiers 1, in accordance with the remainder of the method hereof. The same network interface may be used for both purposes, or there may be certain hardware configurations which would have two separate network interfaces required. For example, two separate notwork interfaces might be required if the vendors or endpoints were communicating with the issuer 11 by way of some type of a closed or proprietary protocol or network, whereas customer notifications were being generated or dispatched by way of the Internet 12. Again it would be obvious to one skilled in the art that different types of network interfaces, connections and protocols can be used to accomplish the necessary communication between these various components of the system and that all such protocols and interfaces are contemplated within the scope hereof.

The system architecture shown in Figure 4 includes two different types of vendor or transaction initiating systems shown at 13A
and 13B, in an endeavor to demonstrate the various types of data capture or transaction initiating endpoint systems which could be used in association with the system and method of the present invention. To a degree the type of a transaction initiating system which might be encountered in the practice of the method of the present invention depends to a degree on the nature of the types of transactions which it was desired process, authorize or initiate using the method of the present invention -- for example talking purely about commercial transactions point-of-sale systems and e-commerce websites might be the primary locations or transaction initiating systems 13 which would be shown. It may however be the case that other types of data processing systems could also benefit from the practice of the present invention even where they were handling non-financial transactions and it will be understood that those types of systems could also be contemplated within the scope of the present invention.

Shown specifically at 13A is a point-of-sale computer system which is contemplated to be a cash register mainframe or similar POS system in a retail environment, which is in turn connected to a plurality of cash registers 9. Capture of the necessary customer identifiers numeral one and other transaction information at the cash registers 9 could be formatted at the POS server 13A into appropriate packet or transmission for submission to the issuer 11. Alternatively in a smaller POS

environment there might be a single credit card terminal or cash register used rather than a mainframe such as is shown in this is also contemplated within the scope of the present invention as might be implemented in a retail context.

A point-of-sale cash register or computer system which needed to authorize credit card transactions could easily be used as a data capture or transaction initiation and point for the system and method of the present invention, as could an e-commerce enabled website such as is shown at 13B. In either case all the transaction initiating system would need to do would be to initiate a transaction approval request as they would normally have done, and the method of the present invention at least in accordance with this embodiment would all be practiced on the back end at the issuer level and so as outlined elsewhere herein it makes for potentially a broader or more straightforward market entry or adoption of the method of the present invention.

In the context of an e-commerce system such as that shown the present invention could be simply executed in light of the fact that the e-commerce system 13B would potentially already be operatively connected to the Internet 12 or some other communication means for transmission of transaction authorization packets to the issuer 11, and also that the transactions being handled by that e-commerce server .13B would already be in such a form, namely and parsed or granular electronic format, such that would be easily possible to generate or collect the necessary information for the submission of a transaction authorization or approval request to the issuer 11 for notification considers-ion in accordance with the remainder of the present invention along with-conventional authorization in a credit card context.

Locally Hosted Software Component:

While it is primarily contemplated that the maximum efficiency and maximum security of the method of the present invention would be accomplished by implementation of the method and data structure required herein at the issuer level, so that only the issuer of customer identifiers numeral one would control the notification to the customers associated therewith of their use, it is also possible that the method of the present invention could be implemented using a revised software components installed locally at the vendor or local endpoint. The necessary system modifications to provide for the installation of a notification database 6 at a local endpoint along with the necessary customer messaging interface 15 will be understood to those skilled in the art of systems design and are contemplated within the scope hereof.

Customer Interface Beyond the system of the present invention which would either be implemented as a separate notification system or incorporated as an additional software or hardware modification to pre-existing systems in place with the issuers of customer identifiers 1, which might include financial accounts such as credit cards or the like or other nonfinancial identification and identifiers which also are within the scope of the present invention the final key elements of the hardware or of the system of the present invention is the consumer or customer interface.
As discussed elsewhere herein, the method of the present invention comprises at its heart a method by which customers will receive notifications of the use of their identification in some kind of a transaction. It is primarily contemplated in terms of present day communication techniques that the methods of provision of the customer notifications 8 in question will either be by SMS text messaging or by e-mail. The customer device in question then would typically be an addressable electronic device to which notifications of this type could be dispatched by the issuer 11 upon processing of a transaction request. Figure 3 shows a cell phone 14 with a sample SMS
message, comprising a customer notification 8, but it will be understood that other similar types of devices are all within the scope of the present invention.

Other types of communication can also be contemplated which would mandate different types of customer endpoint devices. For example it may even be the case that some kind of a text to voice computer model could be used which would basically results in the generation of an automated telephone call to the customer when their identification was used, and in a passive role a message could simply be dispatched to their telephone in this way, using their telephone number as the owner notification address, or in a more active role, it could be the case that the cell phone could be used to playback a message regarding the details of the potential use of the customer identifier 1 in the DTMF signals or other feedback could be provided by the user through the telephone call if there was to be feedback or authorization provided during the notification process. Again this type of a notification system is described to simply demonstrate the fact that there could be multiple additional types of communication protocols and communication methodologies which could be used for the issuance or transmission of customer notifications 8 to customer upon use of their customer identifier.

Setting notification parameters As described elsewhere above, in certain embodiments of the method of the present invention it will be the case that either on an individual customer level or on an individual issuer level it was desired to provide certain thresholds or parameters to the issuance or transmission of customer notifications S. At a customer level for example in a commercial context on our credit card authorization system in accordance with the method of the present invention it may be the case that a particular customer only wants to receive notification of potential transactions with their card in excess of a certain threshold amount and that these parameters 7 would be lodged within the notification database 6 or elsewhere in the data structure available or accessible to the issuer number 11 and their computer system so that those parameters could be applied upon the receipt of a particular transaction request in respect of that customer identifier 1. It may also be the case that simply at an issuer level the issuer 11 wished to provide some global parameters within which notifications 8 would be sent.

The means of setting customer level conditions were parameters could be by way of the same communication method which is used for the dispatch of receipt of notifications 8 to the customer i.e. SMS or e-mail, or there could also be provided some alternate type of a web interface or other interface by which the customer could interact with the issuer and set or adjust these parameters. If there was a web interface or other similar means for the customers to interact with the issuer, it would also provide the ability for the issuer computer system 11 to archive the details of notifrications 8 dispatched to customers so that customers could on demand look up some kind of a historical or archive query or report.

Overall then in terms of the present invention the real-time and rapid provision of the communication method between an issuer and a customer regarding the use of a customer identifier 1 represents an advance over the state-of-the-art. Implementation of this method of the present invention in such a way that can be used with a low bandwidth or rapid turnaround, for example in an SMS environment, renders it a benefit. Allowance for either active or passive methods of feedback if any from the customer to the issuer which could be incorporated into transaction clearing or authorization processes again represent an improvement over the present state of the art for transaction reporting in general and in a noncommercial context the invention presents a real leap forward in terms of being able to detect on an ongoing basis identity abuse or fraud.

The foregoing is considered as illustrative only of the principles of the invention. Further, since numerous changes and modifications will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation shown and described, and accordingly, all such suitable changes or modifications in structure or operation which may be resorted to are intended to fall within the scope of the claimed invention.

Claims

CLAIMS:

We claim
CA 2661577 2009-04-06 2009-04-06 Method and apparatus for customer notification of use of identification Abandoned CA2661577A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA 2661577 CA2661577A1 (en) 2009-04-06 2009-04-06 Method and apparatus for customer notification of use of identification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CA 2661577 CA2661577A1 (en) 2009-04-06 2009-04-06 Method and apparatus for customer notification of use of identification

Publications (1)

Publication Number Publication Date
CA2661577A1 true CA2661577A1 (en) 2010-10-06

Family

ID=42933024

Family Applications (1)

Application Number Title Priority Date Filing Date
CA 2661577 Abandoned CA2661577A1 (en) 2009-04-06 2009-04-06 Method and apparatus for customer notification of use of identification

Country Status (1)

Country Link
CA (1) CA2661577A1 (en)

Similar Documents

Publication Publication Date Title
US11699137B1 (en) Systems and methods for automatic triggering of a code scanning application by a user application
US20190259020A1 (en) Enrollment server
US20230385784A1 (en) Telecommunication Systems and Methods for Broker-Mediated Payment
US9292852B2 (en) System and method for applying stored value to a financial transaction
US8370265B2 (en) System and method for managing status of a payment instrument
AU2006275920B2 (en) Methods and systems for improved security for financial transactions through a trusted third party entity
US7483858B2 (en) Network-based system
AU2010247801B2 (en) Alterable security value
US20110173122A1 (en) Systems and methods of bank security in online commerce
US20070198410A1 (en) Credit fraud prevention systems and methods
US20090319425A1 (en) Mobile Person-to-Person Payment System
US20100229245A1 (en) System of security that prevents abuse of identity data in global commerce via mobile wireless authorizations
US20080114670A1 (en) Systems and methods for a transaction vetting service
US20110320347A1 (en) Mobile Networked Payment System
US20110119190A1 (en) Anonymous transaction payment systems and methods
WO2009152184A1 (en) Mobile payment system
JP2010505161A (en) System and method for verifying user identity in electronic transactions
JP2009512024A (en) System and method for preventing and protecting identity theft and unauthorized use
US8886932B2 (en) Message storage and transfer system
CN115720661A (en) Account rebalancing daemon for use with a secure digital asset custodian
Yadu et al. Security issues and solutions in e-payment systems
AU2009250337A1 (en) A system and method for facilitating a payment transaction
CA2661577A1 (en) Method and apparatus for customer notification of use of identification
Kabir Letter of Transmittal
Williams On-Line Credit and Debit Card Processing and Fraud Prevention for E-Business

Legal Events

Date Code Title Description
FZDE Dead