US20100174660A1 - Methods and computer-readable media for facilitating forensic investigations of online transactions - Google Patents

Abstract

A method, comprising: receiving a first identifier associated with an online transaction and a second identifier used by end user equipment involved in the online transaction; obtaining evidentiary information pertaining to the end user equipment based on the second identifier; storing in a database a record that associates the first identifier with the evidentiary information; and retrieving one of (i) the evidentiary information in said record and (ii) the first identifier in response to a request identifying the other of (i) the evidentiary information in said record and (ii) the first identifier. Where the online transaction is effected over a network after the end user equipment has gained access thereto, the evidentiary information may include information pertaining to a subscriber whose credentials were used by the end user equipment to gain access to the network. The information pertaining to the subscriber may include personal information about the subscriber. Alternatively, the evidentiary information may include location information.

Description

FIELD OF THE INVENTION
• The present invention relates generally to online transactions and, more particularly, to methods and computer-readable media for maintaining records of online transactions so as to facilitate forensic investigations of such transactions.
BACKGROUND
• While most transactions conducted online are genuine, there is a certain amount of fraud involving online transactions, and the ensuing financial loss suffered by merchants continues to increase annually. Also, the distributed nature of the Internet tends to facilitate the availability of products or services whose procurement may in actual fact be illegal due to the purchaser's age, location or other attribute. While investigations into possible fraud or illegality of a conventional transaction are straightforward, the same cannot be said about online transactions where scarce data, if any, about the true individual who made the transaction remains traceable after the fact.
• Against this background, there is a need in the industry for solutions for maintaining records of online transactions that will facilitate forensic investigations of those transactions.
SUMMARY OF THE INVENTION
• According to a first broad aspect, the present invention seeks to provide a method, which comprises receiving a first identifier associated with an online transaction and a second identifier used by end user equipment involved in the online transaction; obtaining evidentiary information pertaining to the end user equipment based on the second identifier; storing in a database a record that associates the first identifier with the evidentiary information; and retrieving one of (i) the evidentiary information in said record and (ii) the first identifier in response to a request identifying the other of (i) the evidentiary information in said record and (ii) the first identifier.
• According to a second broad aspect, the present invention seeks to provide a computer-readable medium comprising computer-readable program code which, when interpreted by a transaction management entity, causes the transaction management entity to execute a method. The computer-readable program code comprises first computer-readable program code for causing the transaction management entity to be attentive to receipt of a first identifier associated with an online transaction and a second identifier used by end user equipment involved in the online transaction; second computer-readable program code for causing the transaction management entity to obtain evidentiary information pertaining to the end user equipment based on the second identifier; third computer-readable program code for causing the transaction management entity to store in a database a record that associates the first identifier with the evidentiary information; and fourth computer-readable program code for causing the transaction management entity to retrieve one of (i) the evidentiary information in said record and (ii) the first identifier in response to a request identifying the other of (i) the evidentiary information in said record and (ii) the first identifier.
• According to a third broad aspect, the present invention seeks to provide a system comprising: a transaction record database comprising a plurality of records, each of said records relating a respective first identifier associated with an online transaction to respective evidentiary information pertaining to end user equipment involved in the online transaction; and a transaction management entity configured to respond to a request identifying one of (i) a given first identifier associated with a given online transaction and (ii) evidentiary information related by one of said records to a given first identifier by retrieving the other of (i) the given first identifier and (ii) the evidentiary information related thereto.
• According to a fourth broad aspect, the present invention seeks to provide a method of investigating an online transaction associated with a transaction identifier. The method comprises providing the transaction identifier to a transaction management entity; obtaining from the transaction management entity evidentiary information pertaining to the end user equipment involved in the online transaction associated with the transaction identifier; and comparing the evidentiary information to information associated with a transaction object used to effect the online transaction.
• According to a fifth broad aspect, the present invention seeks to provide a method of identifying a suspect potentially responsible for effecting an online transaction associated with a transaction identifier. The method comprises providing the transaction identifier to a transaction management entity; obtaining from the transaction management entity evidentiary information pertaining to the end user equipment involved in the online transaction associated with the transaction identifier; and identifying as a suspect a party associated with the evidentiary information.
• According to a sixth broad aspect, the present invention seeks to provide a network entity for participating in an online transaction taking place over a network. The network entity comprises a memory and a processing unit. The processing unit is configured to obtain a transaction identifier associated with an online transaction and a logical identifier associated with end user equipment involved in the online transaction; store in said memory a record that relates said transaction identifier to said logical identifier; and transmit said transaction identifier and said logical identifier over the network to an entity responsible for storing a relationship between the transaction identifier and evidentiary information pertaining to end user equipment involved in said online transaction.
• These and other aspects of the invention will become apparent to those of ordinary skill in the art upon review of the following description of certain embodiments of the invention in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
• A detailed description of embodiments of the present invention is provided herein below, by way of example only, with reference to the accompanying drawings, in which:
• FIG. 1 shows an architecture allowing a user of end user equipment connected to a packet-switched network to access and interact with merchant sites of that network, for example, to make online transactions, in accordance with an embodiment of the present invention.
• FIG. 2A shows possible contents of a database that stores information associated with various logical identifiers assigned to various end user equipment used to access the packet-switched network shown inFIG. 1.
• FIG. 2B shows possible contents of a transaction record database that stores records for various transactions that have been attempted or effected by various subscribers.
• FIG. 3 shows an example of message flow in the architecture ofFIG. 1, in the context of attempting a transaction.
• FIG. 4 shows an example of message flow followingFIG. 3 once the transaction has been approved or denied, including an example flow of a message sent to a transaction management entity for further processing.
• FIG. 5 shows an example of message flow during a forensic investigation of a transaction of interest.
• FIGS. 6-8 are block diagrams and flow diagrams illustrating the example creation of an association between logical identifiers assigned to end user equipment and respective service point locations for that end user equipment, such association being useful in the population of the database ofFIG. 2A.
• It is to be expressly understood that the description and drawings are only for the purpose of illustration of certain embodiments of the invention and are an aid for understanding. They are not intended to be a definition of the limits of the invention.
DETAILED DESCRIPTION OF NON-LIMITING EMBODIMENTS
• FIG. 1 depicts a packet-switchednetwork14 to which are connected a plurality of merchant sites implemented by a plurality of servers30₁. . .30_N. Computing devices that gain access to the packet-switchednetwork14 can interact with the merchant sites in order to effect online transactions. In a non-limiting embodiment, the packet-switchednetwork14 is the Internet and the merchant sites are web sites.
• Access to the packet-switchednetwork14 is controlled or managed by a service provider that has a number of subscribers. In various non-limiting embodiments, the service provider may be an Access Service Provider (ASP), a Regional Access Network Provider (RANP) or an Internet Service Provider (ISP). Individual subscribers are given permission to access the packet-switchednetwork14 when using certain authorized end user equipment and/or when providing certain authorized login credentials.
• FIG. 1 shows one example ofend user equipment12 that may be used to access the packet-switchednetwork14 by auser10. Specifically, theend user equipment12 comprises acomputing device16 and anetwork interface unit18. Thecomputing device16 may be implemented as a personal computer (PC), such as a desktop computer, a laptop computer or a tablet PC. Thecomputing device16 is provided with at least one input device such as a keyboard, a mouse, a touchscreen, a stylus, a microphone, etc., as well as a display and possibly one or more other output devices (e.g., speakers) that enable interaction with theuser10. Thecomputing device16 is operative to run a software application implementing a network browser (e.g., a web browser) with which theuser10 can interact via the display (and possibly the one or more other output devices) and the at least one input device in order to access and interact with merchant sites of the packet-switchednetwork14.
• Acommunication link20 is provided between theend user equipment12 and the packet-switchednetwork14. Thenetwork interface unit18 interfaces with thecommunication link20 and enables thecomputing device16 to exchange data with the packet-switched network14 (and, ultimately, with the merchant sites). For example, depending on the nature of thecommunication link20, thenetwork interface unit18 may be implemented as a modem such as a broadband modem (e.g., a digital subscriber line (DSL) modem or a cable modem) or a narrowband modem (e.g., a dial-up modem). In other embodiments, such as in the case of Fiber to the premises (FTTP), thenetwork interface18 may be implemented as an optical network termination (ONT)-based Ethernet connection. Although it is shown as being a separate component inFIG. 1, thenetwork interface unit18 may be integrated into the computing device16 (e.g., it may be a card internal to the computing device16).
• Thecommunication link20 may traverse one or more network elements and comprise one or more physical links and one or more logical links. For example, thecommunication link20 may comprise aphysical link17 between thenetwork interface unit18 and anetwork element21. Thephysical link17 may comprise a copper twisted pair, a coax cable, an Ethernet link, a fiber optic link (e.g., fiber to the premises (FTTP)), a fixed wireless link, a satellite link, or a combination thereof. Depending on the nature of thephysical link17, thenetwork element21 may be a DSL access multiplexer (DSLAM), a cable modem termination system (CMTS), or another type of network element. Thecommunication link20 may also comprise a dedicatedlogical link19 between thenetwork element21 and anothernetwork element23 that provides access to the packet-switchednetwork14. For instance, thenetwork element23 may be a network access server (NAS), a router, etc. It will be appreciated that thecommunication link20 may take on other forms in other embodiments.
• For the purposes of exchanging data with the packet-switchednetwork14, theend user equipment12 may be assigned a logical identifier. In two non-limiting example embodiments, the logical identifier may be assigned to thecomputing device16 or to thenetwork interface unit18. The logical identifier, which can be an Internet Protocol (IP) address (e.g., in compliance with IPv4 or IPv6) or a proprietary address, label or tag, can be assigned in a static or dynamic fashion. In the static case (e.g., a static IP address), the logical identifier does not change over time. In the dynamic case (e.g., a dynamic IP address), the logical identifier may change over time (e.g., a dynamic IP address).
• Assignment of the logical identifier to theend user equipment12 can be effected under control of the service provider and may be the responsibility of a designated network element that is part of thecommunication link20, such as the network element23 (particularly in embodiments where thenetwork element23 is a network access server). The designated network element may assign the logical identifier to theend user equipment12 when theend user equipment12 is activated (e.g., when thenetwork interface unit18 and/or thecomputing device16 is/are powered-up) or otherwise regains network connectivity and/or at certain time intervals which may range from an hour or less to several months or more. For instance, in embodiments where the logical identifier is a dynamic IP address, the network element assigning the dynamic IP address to theend user equipment12 may do so in accordance with the Dynamic Host Configuration Protocol (DHCP) using a pool of IP addresses accessible to that network element. It will be recognized that assignment of the logical identifier to theend user equipment12 may be effected in different ways in different embodiments.
• The service provider maintains adatabase36 that stores information associated with the various logical identifiers assigned to various end user equipment used to access the packet-switchednetwork14. Thedatabase36 can be linked to various components of the infrastructure ofFIG. 6 in different ways. For example, in one embodiment, thedatabase36 may be integrated with thenetwork element23. In another embodiment, thedatabase36 may be connected to thenetwork element23 either directly or via aservice provider network86, for example. In still other embodiments, thedatabase36 may be distributed amongst a plurality of network elements and/or physical locations. Also, it should be appreciated that thedatabase36 may be managed, maintained and/or updated by an entity that may be the same entity as, or a different entity from, the service provider responsible for providing theend user equipment12 with access to the packet-switchednetwork14.
• With additional reference toFIG. 2A, there is shown an example of possible contents of thedatabase36. An example process by which thedatabase36 may be populated and maintained is described later on. For the time being, it is sufficient to consider that thedatabase36 stores a plurality of records40₁. . .40_Mfor respective logical identifiers assigned to various end user equipment being used to access the packet-switcheddata network14. The record for a particular logical identifier contains “evidentiary information” pertaining to the end user equipment to which the particular logical identifier was assigned.
• Evidentiary information can be viewed as information that can serve as evidence towards establishing who has attempted/effected an online transaction and/or where that online transaction was attempted/effected from. The value of evidentiary information can be high when investigating online transactions, particularly days or weeks after they have taken place. Such analysis may be commissioned by, inter alia, financial institutions (such as banks, credit card companies, etc.), as well as government bodies (such as law enforcement agencies, taxation departments, etc.).
• The evidentiary information that can be contained in a given one of the records40₁. . .40_Mis not particularly limited and may take on various forms, some of which are best illustrated by way of example.
• Accordingly, a first example of evidentiary information that can be contained in the record for a given logical identifier includes information (such as name, age, gender, etc.) regarding a particular subscriber whose credentials were supplied via the end user equipment to which the given logical identifier was assigned, when access to the packet-switchednetwork14 was sought.
• A second example of evidentiary information that can be contained in the record for a given logical identifier includes location information indicative of where the end user equipment to which the given logical identifier was assigned was located, when access to the packet-switchednetwork14 was sought. Such location information may specify a “service point” at which the end user equipment was determined to be located. The “service point” refers to a point where a network access service is provided to a subscriber by the service provider. By way of a specific non-limiting example, the service point may be a house or other building, or an area thereof. The location of the service point, which is hereinafter referred to as the “service point location”, may be expressed as a geo location (latitude, longitude, elevation, and the datum which identifies the coordinate system used, such as, without limitation, the World Geodetic System 1984 (WGS841) datum). Alternatively or in addition, the service point location may be expressed as a civic location (a set of elements that describe detailed street address information). Still other possibilities exist and are within the scope of the invention.
• Returning toFIG. 1, the servers30₁. . .30_Nand the merchant sites that they implement are operated, managed or otherwise associated with various entities, including, for example, companies, governmental organizations, non-profit organizations, and individuals. Each of the servers30₁. . .30_Ncomprises suitable hardware, firmware, software, control logic, or a combination thereof for implementing a plurality of functional components, including an interface and a processing unit.
• The interface of each of the servers30₁. . .30_Nis adapted to receive messages from, and send messages to, communication equipment (such as the end user equipment12) connected to the packet-switchednetwork14, as well as to receive data from, or send data to, other elements (e.g., computers or databases) communicatively coupled to that server but not necessarily connected to the packet-switchednetwork14.
• The processing unit of each of the servers30₁. . .30_Nis adapted to effect various processing operations to implement that server's functionality. For example, when theuser10 uses theend user equipment12 to interact with a given merchant site implemented by a given one of the servers30₁. . .30_N, this will typically involve the network browser implemented by thecomputing device16 interacting with the given one of the servers30₁. . .30_Nin order to allow theuser10 to view, hear or otherwise be exposed to content (e.g., web pages) of the given merchant site via the display and/or one or more other output devices of thecomputing device16, and to input information (e.g., by entering text, selecting an option, etc.) and/or one or more commands (e.g., by clicking on a graphical button or a hyperlink) via the at least one input device of thecomputing device16.
• In accordance with an embodiment of the present invention, each of the servers30₁. . .30_Nincludes or has access to acorresponding memory90. Thememory90 corresponding to a given one of the servers30₁. . .30_Nstores an association between, on the one hand, logical identifiers used by various end user equipment to effect transactions with the given one of the servers30₁. . .30_Nand, on the other hand, “transaction identifiers” for those transactions. The contents of thememory90 corresponding to a given server are kept up to date as new transactions are effected with the given server.
• A “transaction identifier” for a particular transaction may be generated by an entity involved in validating or otherwise processing the particular transaction. One example of such an entity includes apayment gateway60.
• Thepayment gateway60 is a network element that is connected to afinancial network68 and that is used by one or more of the servers30₁. . .30_Nto process online transactions attempted to be made via the merchant sites implemented by those one or more servers. Thefinancial network68 interconnects a plurality of servers or other computers associated with banks and/or other financial institutions. Examples of servers that could be interconnected via thefinancial network68 include atransaction validation server51 that could be associated with, for example, a card issuing bank and aserver70 that could be associated with, for example, an acquiring bank. It should be appreciated that in certain embodiments, thefinancial network68 may be part of the packet-switchednetwork14, may comprise individual point-to-point links or may be dispensed with altogether.
• Thetransaction validation server51 may be connected to the various servers30₁. . .30_N(or computers associated with those servers) via respective communication paths established over the packet-switchednetwork14 and thefinancial network68 and which may traverse one or more network elements such as gateways and other servers. Thetransaction validation server51 is operated, managed or otherwise associated with an entity responsible for validating online transactions. In a specific non-limiting embodiment, this entity may be a card issuing bank that issues credit cards or debit cards.
• Thetransaction validation server51 comprises suitable hardware, firmware, software, control logic, or a combination thereof for implementing a plurality of functional components, including an interface and a processing unit. The interface of thetransaction validation server51 is adapted to receive messages from and send messages to other servers and/or other computers, and to exchange data with other elements (e.g., databases). The processing unit of thetransaction validation server51 is adapted to effect various processing operations to implement that server's functionality.
• Thetransaction validation server51 includes or has access to adatabase53, which stores information used by thetransaction validation server51 to validate online transactions attempted to be effected by various users. Accordingly, thedatabase53 stores a plurality of records, each of which is associated with a respective “transaction object” and contains “transaction object information” pertaining to the respective transaction object, as well as ancillary information that may be required to process an online transaction attempted to be made using the respective transaction object.
• A “transaction object” refers to any physical or virtual object designed to be used in an attempt to make a transaction. For example, a transaction object may constitute a payment card (e.g., a credit card, a debit card, etc.), an account (e.g., a bank account, an online wallet account, login credentials for accessing secure content or a VPN, etc.), an electronic check, a set of one or more digital cash (electronic money) certificates, or any other physical or virtual object designed to be used in an attempt to make a transaction. The transaction object information can therefore take on various forms.
• For example, the transaction object information may include payment card information regarding a payment card in situations where, for instance, theuser10 desires to purchase or otherwise obtain a product/service/content offered on a network site, pay a bill for a previously obtained product/service/content via the network site, or make a donation to a charity or other institution through the network site using the payment card. Such payment card information may be, for instance, credit card information regarding a credit card (e.g., a number, expiry date, and/or holder's name) or debit card information regarding a debit card (e.g., a number and/or holder's name). The payment card may comprise one or more card elements adapted to convey part or all of the payment card information, such as one or more sets of characters (e.g., printed and/or embossed characters), a magnetic stripe, and/or a chip (e.g., an EMV chip).
• In another example, the transaction object information may include electronic check information regarding an electronic check (e.g., a check number and/or a checking account number) in situations where, for instance, theuser10 desires to effect a payment via a network site using the electronic check. In order to process the payment attempted to be effected by theuser10 using the electronic check, an entity (e.g., a bank or other financial institution, or the service provider) that allows theuser10 to use the electronic check may store on a computer-readable medium (e.g., as part of a database) information regarding the electronic check, including the electronic check information provided by theuser10.
• In yet another example, the transaction object information may include digital cash information regarding a set of one or more digital cash certificates (e.g., digital cash certificate identifiers) in situations where, for instance, theuser10 desires to effect a payment via a network site using the set of one or more digital cash certificates. In order to process the payment attempted to be effected by theuser10 using the set of one or more digital cash certificates, an entity (e.g., a bank or other financial institution) that allows theuser10 to use the set of one or more digital cash certificates may store on a computer-readable medium (e.g., as part of a database) information regarding the set of one or more digital cash certificates, including the digital cash information provided by theuser10.
• In a further example, the transaction object information may include account information regarding an account (e.g., an account number and/or holder's name and/or login credentials) in situations where, for instance, theuser10 desires to effect a transfer of funds to or from the account via a network site, or where theuser10 desires to access secure online content or a VPN via the network site. In order to process the attempted transfer or access, an entity (e.g., a bank or other financial institution, a corporate extranet server) that allows theuser10 to use the account may store on a computer-readable medium (e.g., as part of a database) information regarding the account, including the account information provided by theuser10.
• The ancillary information contained in a particular record of thedatabase53 also depends on the nature of the transaction object associated with the particular record and can thus take on many forms. For example, where the transaction object associated with the particular record is a credit card, the ancillary information contained in the particular record may include a credit limit, a balance due, a billing address (i.e., an address where credit card bills are to be sent), a shipping address, a list of recent transactions, a list of one or more authorized transaction points (which could include the billing address and/or the shipping address), a list of one or more unauthorized transaction points, a spatio-temporal history of previous online transactions attempted using that credit card, a list of eligible card holders' names and/or possibly other information regarding the credit card.
• In accordance with an embodiment of the present invention, the service provider maintains atransaction management entity80 including or having access to atransaction record database82. Thetransaction management entity80 provides entities such as merchant sites, banks and credit card companies with a centralized point to which information regarding effected transactions can be sent. To this end, thetransaction management entity82 may be reachable via the packet-switchednetwork14 and theservice provider network86, or via a direct connection to one or more of the above entities. The contents of thetransaction record database82 are thus continuously updated based on information about transactions taking place in the packet-switchednetwork14, as received from a variety of sources.
• With additional reference toFIG. 2B, there is shown an example of possible contents of thetransaction record database82. Thetransaction record database82 stores a plurality ofrecords84₁. . .84_Tfor various transactions that have been attempted/effected by various subscribers. The manner in which thetransaction record database82 is populated will be described later on in greater detail. Generally speaking, it can be said that a new record in thetransaction record database82 is created upon receipt of a transaction identifier and a logical identifier from an entity (such as a merchant site, bank or credit card company) having recorded an attempt to effect a transaction. The transaction identifier can be used to index the new record, while the logical identifier can be used to look up one or more elements of evidentiary information by consulting thedatabase36. The one or more elements of evidentiary information returned from thedatabase36 are stored in the record that has just been created in thetransaction record database82 for the transaction in question.
• To illustrate more specifically how thetransaction record database82 may be populated, consider the situation where theuser10 decides to effect an online transaction with the merchant site implemented by the server30_n. For example, theuser10 may decide to: purchase or otherwise obtain a product and/or a service and/or content offered on the merchant site; pay a bill for a previously obtained product/service/content via the merchant site; transfer funds from one account to another via the merchant site; buy or sell securities (e.g., stocks, bonds, etc.) via the merchant site; make a donation to a charity or other institution through the merchant site; etc. It will be appreciated that various other situations may arise in which online transactions may be desired or may need to be effected.
• For the purposes of the present example, it is assumed that theuser10 has used theend user equipment12 to successfully gain access to the packet-switchednetwork14, and that theend user equipment12 has been assigned a logical identifier, say 211.104.103.102. Successful access to the packet-switchednetwork14 may have been gained by theuser10 having provided the credentials of a legitimate subscriber, say, subscriber “ABC”, via theend user equipment12. Thus, with reference toFIG. 2A, thedatabase36 stores a record40_Xfor logical identifier 211.104.103.102, which contains evidentiary information, such as the identity of subscriber “ABC” (or other personal information pertaining to subscriber “ABC”). Alternatively or in addition, the service provider determines a service point location (say, “15 Main Street”) associated with theend user equipment12 and stores this information in the record40_X. One way in which the service point location associated with theend user equipment12 can be determined is described in greater detail later on.
• In the course of attempting to effect an online transaction while interacting with the merchant site implemented by the server30_n, theuser10 provides transaction object information via theend user equipment12. This can be done in various ways. For example, theuser10 may use one or more of the at least one input device of thecomputing device16 to enter the transaction object information and cause this information to be sent by theend user equipment12 to the server30_n(or another computer associated with the server30_n) over the packet-switchednetwork14. Alternatively, the transaction object information may have been previously stored in thecomputing device16, in which case theuser10 may use one or more of the at least one input device of thecomputing device16 to cause theend user equipment12 to send the previously stored transaction object information to the server30_n(or another computer associated with the server30_n) over the packet-switchednetwork14.
• For purposes of this example, the transaction object is a particular credit card, the transaction object information is credit card information regarding the particular credit card and thetransaction validation server51 is a server associated with a card issuing bank that issued the particular credit card. Also, for purposes of this example, each of the records in thedatabase53 is associated with a credit card and includes credit card information regarding that credit card. One of these records may be associated with the particular credit card and thus may include credit card information regarding the particular credit card.
• The online transaction attempted to be effected by theuser10 may be subjected to various conventional security measures intended to protect information traveling to and from theend user equipment12 over the packet-switchednetwork14. For example, the credit card information provided by theuser10 via theend user equipment12 may be encrypted (e.g., using the Secure Socket Layer (SSL) protocol) prior to being sent over the packet-switchednetwork14. In other examples, card security code (CSC) verification may be employed whereby theuser10 is asked to enter the credit card's CSC, and/or address verification systems (AVS) may be employed whereby an address entered by theuser10 is compared to a billing address known to the credit card's issuing bank. Various other security measures may be employed in different cases.
• With reference now toFIG. 3, thecomputing device16 of theend user equipment12 transmits to the server30_namessage102. In this example, themessage102 conveys: (i) order information indicative of the selected product/service/content; (ii) purchase amount information indicative of an amount to be paid to purchase the selected product/service/content; and (iii) the credit card information regarding the particular credit card. Alternatively, the order information, the purchase amount information and possibly even the credit card information may already be known to the server30_ndue to prior interaction between thecomputing device16 and the server30_n. In such a case, themessage102 may simply convey an indication or confirmation of a desire of theuser10 to purchase the selected product/service/content.
• Additionally, themessage102 may also convey the logical identifier assigned to theend user equipment12, in this case 211.104.103.102. Alternatively, the logical identifier assigned to theend user equipment12 may not be conveyed by themessage102 but may already be known to the server30_ndue to prior interaction between thecomputing device16 and the server30_n.
• Themessage102 is received at the server30_n, which proceeds to send amessage104 to apayment gateway60. In this example, thepayment gateway60 is used by the server30_nto process online transactions attempted to be made via the merchant site implemented by the server30_n. Thus, the manner in which thepayment gateway60 can be reached may be known in advance to the server30_n. It is recalled that thefinancial network68 interconnects thepayment gateway60 to the transaction validation server51 (which is associated with the card issuing bank that issued the particular credit card) and the server70 (which is associated with the acquiring bank used by the merchant that operates, manages or is otherwise associated with the server30_n).
• Themessage104 sent to thepayment gateway60 may be identical to themessage102, i.e., it may be a relayed version of themessage102 when themessage102 contains sufficient information. Alternatively, themessage104 may be generated by the server30_nbased on themessage102 and possibly other information known to the server30_n(e.g., the order information, the purchase amount information and/or the credit card information). Ultimately, in this example, themessage104 conveys: (i) the purchase amount information indicative of an amount to be paid to purchase the selected product/service/content; and (ii) the credit card information regarding the particular credit card.
• Themessage104 is received at thepayment gateway60 which, in accordance with a specific non-limiting embodiment of the present invention, proceeds to generate a unique transaction identifier for the particular transaction being attempted. By way of specific non-limiting example, let the transaction identifier beA7GH6X. Also, having determined that themessage104 originates from the server30_n, thepayment gateway60 proceeds to send amessage106 over thefinancial network68 to the server70 (which, it is recalled, is associated with the acquiring bank used by the merchant associated with the server30_n). Themessage106, which can be viewed as a request for transaction authorization, is intended to elicit from the financial network68 a response as to whether the transaction identified by the transaction identifierA7GH6Xis approved or denied. In this example, thepayment gateway60 generates themessage106 based on themessage104 such that themessage106 conveys: (i) the purchase amount information indicative of an amount to be paid to purchase the selected product/service/content; and (ii) the credit card information regarding the particular credit card. The transaction identifierA7GH6Xmay also be provided to facilitate processing.
• Theserver70 receives themessage106 and processes it to gain knowledge that an attempt is being made to effect a transaction having the transaction identifierA7GH6Xand involving the merchant associated with the server30_n. Based on the credit card information conveyed by themessage106, theserver70 proceeds to send amessage108 to thetransaction validation server51 over thefinancial network68. Themessage108 may be identical to themessage106, i.e., it may be a relayed version of themessage106. Alternatively, themessage108 may be generated by theserver70 based on themessage106 and possibly other information known to theserver70. In this example, themessage108 conveys: (i) the purchase amount information indicative of an amount to be paid to purchase the selected product/service/content; and (ii) the credit card information regarding the particular credit card. The transaction identifierA7GH6Xmay also be provided to facilitate processing.
• Themessage108 is received at thetransaction validation server51, which is associated with the card issuing bank that issued the particular credit card that has been used by theuser10 to attempt to purchase the selected product/service/content. Thetransaction validation server51 proceeds to process themessage108 to determine whether the transaction identified by the transaction identifierA7GH6Xis to be approved or denied. To this end, thetransaction validation server51 consults thedatabase53 to identify a particular one of the records therein for the credit card information conveyed by themessage108.
• Thetransaction validation server51 may perform various processing operations to determine whether the transaction identified by the transaction identifierA7GH6Xis to be approved or denied. For example, based on the ancillary information (e.g., a credit limit, a balance due, etc.) included in the particular one of the records in thedatabase53 and the purchase amount information conveyed by themessage108, thetransaction validation server51 may determine whether the transaction identified by the transaction identifierA7GH6Xis to be approved or denied. It will be appreciated that approval or denial of the transaction identified by the transaction identifierA7GH6Xmay be determined by thetransaction validation server51 based on other factors in addition to or instead of those mentioned above.
• With reference now toFIG. 4, upon determining whether the transaction identified by the transaction identifierA7GH6Xis approved or denied, thetransaction validation server51 returns amessage114 to theserver70 over thefinancial network68. Themessage114 indicates whether the transaction identified by the transaction identifierA7GH6Xwas approved or denied.
• If the transaction identified by the transaction identifierA7GH6Xwas denied, themessage114 may indicate (e.g., by a code) a reason for this denial, such as insufficient funds, an unavailable bank link, etc. Depending on the circumstances, thetransaction validation server51 may also take further action, such as freezing a credit account corresponding to the particular credit card, informing security/law enforcement authorities, etc.
• On the other hand, if the transaction identified by the transaction identifierA7GH6Xwas approved, thetransaction validation server51 may update, in thedatabase53, the record associated with the particular credit card to take into account approval of this transaction. For example, one or more elements of ancillary information (e.g., a balance due, an available credit, etc.) included in the record in question may be updated to reflect the fact that the transaction identified by the transaction identifierA7GH6Xwas approved.
• Theserver70 receives themessage114, and processes it to determine whether the transaction identified by the transaction identifierA7GH6Xwas approved or denied. If approved, the transaction identified by the transaction identifierA7GH6Xis eventually settled via a settlement process involving the acquiring bank and the card issuing bank. This settlement process is well known and thus not described herein. Meanwhile, theserver70 proceeds to return amessage116 to thepayment gateway60. Themessage116 may be identical to themessage114, i.e., it may be a relayed version of themessage114. Alternatively, themessage116 may be generated by theserver70 based on themessage114. Themessage116 indicates whether the transaction identified by the transaction identifierA7GH6Xwas approved or denied and, if denied, may indicate a reason therefor.
• Themessage116 is received at thepayment gateway60, which proceeds to send amessage118 to the server30_n. Themessage118 indicates whether the transaction identified by the transaction identifierA7GH6Xwas approved or denied and, if denied, may indicate a reason therefor. The information conveyed by themessage118 issued by the payment gateway includes the transaction identifierA7GH6X.
• The server30_nreceives themessage118, including the transaction identifierA7GH6X. The server30_nprocesses themessage118 to ascertain whether the transaction identified by the transaction identifierA7GH6Xwas approved or denied. Approval or denial (and a reason for denial, if applicable) may be recorded by the server30_n, for future reference. The server30_nproceeds to send amessage120 to thecomputing device16 of theend user equipment12 in order to communicate approval or denial of the online transaction to theuser10.
• Upon receiving themessage120, thecomputing device16 processes themessage120 so as to communicate approval or denial of the online transaction to theuser10. For example, this may be achieved by displaying a “transaction approved” or “transaction denied” message (or any conceivable variant thereof) on the display of thecomputing device16.
• In addition, the server30_nstores the transaction identifier received with the message118 (in this caseA7GH6X) in association with the logical identifier assigned to theend user equipment12 used to effect the transaction in question (in this case 211.104.103.102). This can be done by creating a record in thememory90. The stored association between the transaction identifierA7GH6Xand the logical identifier 211.104.103.102 may prove valuable when it comes to launching a possible investigation into potential fraudulence of illegality of the transaction identified by the transaction identifierA7GH6X.
• In addition, the server30_ngenerates amessage121 that is sent to thetransaction management entity80. Themessage121 can be sent to thetransaction management entity80 over the packet-switchednetwork14 or over a dedicated link, for example. Themessage121 contains the aforementioned information that was stored in thememory90 of the server30_n, namely (i) the transaction identifierA7GH6Xfor the transaction in question and (ii) the logical identifier 211.104.103.102 assigned to theend user equipment12 that was used to effect the transaction in question. As an option, once themessage121 is sent to thetransaction management entity80, the association between the transaction identifierA7GH6Xand the logical identifier 211.104.103.102 need no longer be maintained in thememory90 of the server30_n.
• Thetransaction management entity80 is attentive to receipt of themessage121, upon receipt of which thetransaction management entity80 extracts therefrom the transaction identifierA7GH6Xand the logical identifier 211.104.103.102. Thetransaction management entity80 then queries thedatabase36 on the basis of the received logical identifier 211.104.103.102 to obtain evidentiary information contained in the record associated with the logical identifier 211.104.103.102.
• It is recalled that the evidentiary information may take on various forms, such as a subscriber identity or other personal information and/or a service point location, to name a few non-limiting possibilities. In the non-limiting example being considered here, record40_Xin thedatabase36, which is associated with the logical identifier 211.104.103.102, stores the identity of subscriber “ABC” and the service point location “15 Main Street”. Thetransaction management entity80 then creates anew record84_jin thetransaction record database82, which relates the transaction identifierA7GH6Xreceived from the server30_nto the evidentiary information (the identity of subscriber “ABC” and the service point location “15 Main Street”) received from thedatabase36.
• Therecords84₁. . .84_Tin the transaction record database82 (including the record84_j) thus relate timely obtained evidentiary information to transaction identifiers. The evidentiary information can then be provided at some later time to an interested party in response to an eventual request from the latter specifying a particular one of these transaction identifiers.
• Several applications of thetransaction record database82 are now described. Firstly, consider the scenario where, at the time when a transaction (such as the aforesaid transaction identified by the transaction identifierA7GH6X) is effected, the service provider does not necessarily have an indication of whether this transaction is fraudulent or illegal. However, at some later time, let it be assumed that an interested party adopts a more suspicious view, based on its own research, customer complaints, a fraud detection mechanism, etc. The interested party may then undertake a forensic investigation regarding a “transaction of interest” associated with a particular transaction identifier.
• With reference now toFIG. 5, the investigation proceeds with an interested party500 (such as a merchant, a bank, a credit card company, a law enforcement agency, a governmental body, etc.) identifying the particular transaction identifier associated with the transaction of interest. To this end, theinterested party500 may send amessage502 to thetransaction management entity80 specifying the particular transaction identifier. Themessage502 may reach thetransaction management entity80 via the packet-switchednetwork14 and theservice provider network86. Alternatively, themessage502 may reach thetransaction management entity80 via a direct link from theinterested party500. Thetransaction management entity80 consults thetransaction record database82 in an attempt to match the particular transaction identifier with the transaction identifier stored in one of therecords84₁. . .84_T. If a match is not found, then the service provider has not stored a record of this transaction having taken place, and the interested party may wish to query other service providers who may have provided a conduit for the transaction of interest.
• Assuming however that a matching record is identified, the corresponding evidentiary information (or a portion thereof) is retrieved from thetransaction record database82 and provided to the interested party in the form of amessage504. The level of detail provided in themessage504 could vary depending on the relationship between the interested party and the service provider. Thus, it is within the scope of the present invention to allow a law enforcement agency to be privy to a greater amount of detail concerning the evidentiary information than a credit card company.
• In one embodiment, where the transaction of interest is known to be fraudulent (e.g., a fraudulent purchase, login, etc.), the evidentiary information may reveal to the interested party certain details about the culprit. For example, when the evidentiary information provided in themessage504 comprises a service point location, then the interested party may conclude where the fraudulent transaction of interest was made from. In another example, when the evidentiary information provided in themessage504 comprises the identity of a particular subscriber, then the interested party may conclude who is guilty of having effected the transaction of interest. Other example scenarios are of course possible, and each may lead to specific actions that may be taken by the interested party to identify and then pursue and/or prosecute the culprit, as will be appreciated by those skilled in the art.
• In another embodiment, the evidentiary information may reveal to the interested party that the transaction of interest has a likelihood of having been illegal or fraudulent. For example, when the evidentiary information provided in themessage504 comprises a service point location, and if the particular credit card is authorized to be at any of a limited set of locations which do not include the service point location provided in themessage504, the interested party may conclude that the transaction of interest was fraudulent. In another example, when the evidentiary information provided in themessage504 comprises the identity of a particular subscriber, and if the particular subscriber is found to be or is registered as being of a certain age, the interested party may conclude that the transaction of interest was illegal. Other example scenarios are of course possible, and each may lead to specific actions that may be taken by the interested party to further investigate the issue of fraud, as will be appreciated by those skilled in the art.
• In a second scenario for using thetransaction record database82, rather than contain the particular transaction identifier, themessage502 may contain target evidentiary information, such as a specific user or a specific location. Upon receipt of themessage502, thetransaction management entity80 consults thetransaction record database82 in an attempt to match the target evidentiary information with the evidentiary information stored in one or more of therecords84₁. . .84_T. Assuming that a matching record is identified, the corresponding transaction identifier(s) is(are) retrieved from thetransaction record database82 and provided to the interested party in the form of themessage504. In the case where a particular suspect has been identified, for example, this application of an embodiment of the present invention allows the interested party to access transaction identifiers pertaining to all the transactions having been effected by that suspect (or from a specific location associated with that suspect). These transaction identifiers can be related to the actual transactions and analyzed for fraudulent activity in order to help establish the innocence or guilt of the suspect.
• In a third scenario for using thetransaction record database82, consider the case where an interested party wishes to be notified when online transactions are attempted by a specific user or from a specific location (e.g., from a prison with Internet access). In one embodiment, in a provisioning phase, thetransaction management entity80 receives a request containing “evidentiary information of interest”. Then, at the time when a transaction (such as the aforesaid transaction identified by the transaction identifierA7GH6X) is effected, thetransaction management entity80 checks the evidentiary information against the target evidentiary information and, if there is a match, the interested party can be alerted by sending the corresponding transaction identifier. The interested party then relates the transaction identifier to the transaction and establishes legitimacy/legality of the transaction.
• In the scenarios considered above, the transaction identifierA7GH6Xwas generated by thepayment gateway60 upon receipt of themessage104, and was relayed to the server30_nas part of themessage118. However, it should be appreciated that in various alternative embodiments, the transaction identifierA7GH6Xmay have been generated by thepayment gateway60 later on in the transaction validation, such as upon receipt of themessage116 from theserver70. Also, the transaction identifierA7GH6Xcould have been generated by other network entities involved in processing of the transaction and at various instances, such as:
• • by theserver70 upon receipt ofmessage106 from thepayment gateway60;
  • by thetransaction validation server51 upon receipt of themessage108 from theserver70;
  • by theserver70 upon receipt of themessage114 from thetransaction validation server51;
  • by the server30_nupon originally receiving themessage102 from thecomputing device16; or
  • by a shipping agent that produces a waybill.
• Still other possibilities are within the scope of the present invention.
• It should also be appreciated that although thepayment gateway60, theserver70, thetransaction validation server51 and the server30_nhave been described as separate entities, this has been done for convenience and illustration only. It should therefore be understood that in certain embodiments, any one or more of thepayment gateway60, theserver70, thetransaction validation server51 and the server30_nmay be integrated into a single network entity or component.
• In the scenarios considered above, the relationship between the transaction identifierA7GH6Xand the logical identifier 211.104.103.102 was maintained by the server30_nin itsmemory90 and then was sent to thetransaction management entity80. However, it should be appreciated that in various alternative embodiments, this relationship may be maintained by other entities of interest prior to being sent to thetransaction management entity80, such as:
• • by the payment gateway60 (in which case themessage104 sent from the server30_nto thepayment gateway60 can be modified to inform the payment gateway of the logical identifier 211.104.103.102);
  • by the server70 (in which case both themessage104, as well as themessage106 sent from thepayment gateway60 to theserver70, can be modified to inform theserver70 of the logical identifier 211.104.103.102); or
  • by the transaction server51 (in which case themessages104 and106, as well as themessage108, can be modified to inform the transaction server of the logical identifier 211.104.103.102).
• Still other possibilities are within the scope of the present invention.
• In the scenarios considered above, the transaction identifierA7GH6Xand the logical identifier 211.104.103.102 were sent to thetransaction management entity80, which then obtained evidentiary information from thedatabase36 based on the received logical identifier 211.104.103.102. The resultant relationship between the transaction identifierA7GH6Xand the retrieved evidentiary information was then stored in therecord84_jof thetransaction record database82. However, it should be appreciated that in various alternative embodiments, this relationship may be maintained by other entities of interest, such as by a third party (e.g., a law enforcement agency's Internet server) reachable via the packet-switchednetwork14. For example, thetransaction management entity80 may transmit the retrieved evidentiary information along with the corresponding transaction identifierA7GH6Xto the law enforcement agency's Internet server for storage thereon.
• As has been mentioned above, the evidentiary information that can be contained in the record for a given logical identifier may include location information indicative of where the end user equipment to which the given logical identifier was assigned was located when access to the packet-switchednetwork14 was sought. An example process by which thedatabase36 may be populated with such location information will now be described with reference toFIG. 6. Specifically, this example description will illustrate one possible manner by which an association between the logical identifier assigned to theend user equipment12 and the location of a service point where theend user equipment12 is located (e.g., “15 Main Street”), may be stored in thedatabase36 as part of one of the records40₁. . .40_M.
• In this example, thenetwork element21 of thecommunication link20 connecting theend user equipment12 to the packet-switchednetwork14 is an access multiplexer. In one embodiment, theaccess multiplexer21 may be a DSLAM. Theaccess multiplexer21 is connected to thenetwork element23, which, in this embodiment, is a network access server (NAS). TheNAS23, which may also sometimes be referred to as a broadband remote access server (BRAS), a remote access server (RAS) or a broadband access server (BAS), provides access to the packet-switchednetwork14. Communication between theaccess multiplexer21 and theNAS23 can take place over the dedicatedlogical link19 between these elements. The dedicatedlogical link19, which may traverse an intervening access data network (not shown), can be implemented in various ways. For example, in one embodiment, the dedicatedlogical link19 may be implemented as an asynchronous transfer mode (ATM) permanent virtual circuit (PVC). In another embodiment, the dedicatedlogical link19 may be implemented as a virtual local area network (VLAN). It will be appreciated that various other implementations of the dedicatedlogical link19 are possible.
• Theaccess multiplexer21 allows data arriving from theNAS23 along given ATM PVCs, VLANs or other dedicated logical links to be sent over corresponding physical links via corresponding one of its ports, and vice versa. Thus, theaccess multiplexer21 can be said to implement amapping134 between, on the one hand, dedicated logical links and, on the other, ports of theaccess multiplexer21. In this example, themapping134 implemented by theaccess multiplexer21 relates the dedicatedlogical link19 to theport104 of theaccess multiplexer21. In one example embodiment, themapping134 can be maintained by theaccess multiplexer21.
• In another example embodiment, themapping134 can be maintained by an operation support system (OSS)122. TheOSS122 represents a collection of systems that perform management, inventory, engineering, planning, repair and other functions for a service provider. TheOSS122 may be connected to theNAS23 via theservice provider network86. One of the functions of theOSS122 may include management of network elements, assets and equipment. Thus, theOSS122 maintains amapping124 between, on the one hand, ports of various access multiplexers or other network elements under control of the service provider and, on the other, service point locations of end user equipment (such as the end user equipment12) connected to those ports. In this case, themapping124 maintained by theOSS122 relates aport104 of thenetwork element21 to a service point location, i.e., the location of a service point where theend user equipment12 is located. As mentioned previously, this service point location may be expressed as a civic address, a geo location, or any other information identifying where the service point is located. In this specific example, it is assumed that the service point location is “15 Main Street”.
• The infrastructure shown inFIG. 6 further comprises anauthorization element142, which can be connected to theNAS23 via theservice provider network86. The nature of the connection between theNAS23 and theauthorization element142 is immaterial. For example, in one embodiment, theauthorization element142 may be a server (e.g., an Authentication, Authorization, and Accounting (AAA) server) responsive to queries from theNAS23. In such an embodiment, theauthorization element142 and theNAS23 may communicate using the Remote Authentication Dial In User Service (RADIUS) protocol, a description of which is available at www.ietf.org/rfc/rfc2865.txt. In another embodiment, theauthorization element142 may be a functional element integrated with theNAS23.
• In this example, theNAS23 is operative to maintain apool127 of pre-allocated logical identifiers that can be used by various end user equipment, including theend user equipment12. In some embodiments, thepool127 of logical identifiers may be built up as a cooperative effort between theNAS23 and theOSS122, while in other embodiments, it may not be necessary for theOSS122 to be involved in creating thepool127 of logical identifiers. In still other embodiments, thepool127 of logical identifiers may be maintained by theauthorization element142, and may be made accessible to theauthorization element142 without needing to pass through theNAS23.
• It will be appreciated that numerous modifications and variations of the infrastructure ofFIG. 6 are possible. For example, in some embodiments, theaccess multiplexer21 can be omitted. This may be true in embodiments where theend user equipment12 implements a wireless access point. For instance, in such embodiments, the connection between the wireless access point and theNAS23 may be provided by a dedicated point-to-point link. As another example, in some embodiments, instead of the dedicatedlogical link19, there may be a shared link leading to theend user equipment12.
• Reference is now made toFIG. 7, which illustrates an example of a possible event flow upon activation of theend user equipment12, which may occur, for instance, as thenetwork interface unit18 and/or thecomputing device16 of theend user equipment12 is/are powered up. Thereafter:
• • a) theend user equipment12 establishes physical layer connectivity with theaccess multiplexer21 over thephysical link17;
  • b) this is followed by establishment of Ethernet connectivity between theend user equipment12 and theaccess multiplexer21;
  • c) theend user equipment12 verifies its ability to communicate using Point-to-Point Protocol over Ethernet (PPPoE). For a more detailed explanation of PPPoE, one may refer to Internet Request For Comments (RFC) 2516, available from the Internet Engineering Task Force (http://www.ietf.org), hereby incorporated by reference herein;
  • d) next, assuming that theend user equipment12 has the ability to communicate using PPPoE, theend user equipment12 verifies whether it should make a so-called “access request” automatically or in response to user input (which can be obtained via a software application). For purposes of this example, let it be assumed that conditions have been met such that theend user equipment12 should make an access request;
  • e) theend user equipment12 begins entry into PPPoE communication by broadcasting an “initiation” packet over the dedicatedlogical link19;
  • f) theNAS23 responds to receipt of the initiation packet by sending an “offer” packet to theend user equipment12. At this stage, it can be said that alogical connection182 has been defined between a first endpoint (the end user equipment12) and a second endpoint (the NAS23);
  • g) following receipt of the offer packet, theend user equipment12 sends anaccess request184 to theNAS23 with the ultimate goal of accessing the packet-switchednetwork14. Theaccess request184 may comprise credentials that can be hard coded or programmably installed on theend user equipment12. Alternatively, the credentials may be entered by theuser10 of theend user equipment12.
  • h) upon receipt of theaccess request184 containing the credentials along the dedicatedlogical link19, theNAS23 executes an authorization procedure as follows. TheNAS23 communicates the credentials to theauthorization element142, e.g., via a RADIUS Access-Request message188. In response to receipt of the credentials from theNAS23, theauthorization element142 determines whether the credentials allow access to the packet-switchednetwork14. For example, this can be determined by consulting a database (not shown) of credentials for various subscribers. If the credentials allow access to the packet-switchednetwork14, theauthorization element142 returns an acceptance message (e.g., a RADIUS Access-Accept message). On the other hand, if the credentials do not allow access to the packet-switchednetwork14, theauthorization element142 returns a refusal message (e.g., a RADIUS Access-Reject message). For purposes of this example, assume that the credentials allow access to the packet-switchednetwork14, resulting in issuance of anacceptance message190. In this example, two alternatives are possible
    • alternative 1 (where thepool127 of logical identifiers is maintained by the authorization element142): theauthorization element142 obtains alogical identifier193 from thepool127 of logical identifiers that is maintained by theauthorization element142. Thelogical identifier193 is sent to theNAS23, which assigns thelogical identifier193 to the dedicatedlogical link19;
    • alternative 2 (where thepool127 of logical identifiers is maintained by the NAS23): responsive to receipt of theacceptance message190 from theauthorization element142, theNAS23 obtains alogical identifier193 from thepool127 of logical identifiers that is maintained by theNAS23. Thelogical identifier193 so obtained is assigned by theNAS23 to the dedicatedlogical link19.
  • i) theNAS23 sends a “confirmation” packet back to theend user equipment12, thus completing establishment of a PPPoE session between the endpoints of thelogical connection182;
  • j) additional hand-shaking may be performed between theend user equipment12 and theNAS23 in order to establish a Point-to-Point Protocol (PPP) session between the endpoints of thelogical connection182;
  • k) following this, further hand-shaking may be undertaken between theend user equipment12 and theNAS23 in order to establish an Internet Protocol Control Protocol (IPCP) session between the endpoints of thelogical connection182.
  • l) during the IPCP session, theNAS23 releases thelogical identifier193 towards theend user equipment12 that issued theaccess request184, in order to allow theend user equipment12 to identify itself using thelogical identifier193 in future communications over the dedicatedlogical link19. Since the dedicatedlogical link19 to which has been assigned thelogical identifier193 leads to theend user equipment12 and since theend user equipment12 will identify itself using thelogical identifier193 in future communications, it can be said that thelogical identifier193 is in actuality assigned to theend user equipment12.
• It can thus be appreciated that once thelogical identifier193 has been obtained from thepool127 of logical identifiers (either by theNAS23 or by the authorization element142), theNAS23 assigns thelogical identifier193 to the dedicatedlogical link19.
• In an embodiment where thedatabase36 is integrated with or connected directly to theNAS23, the fact that theNAS23 assigns thelogical identifier193 to the dedicatedlogical link19 allows theNAS23 to construct and maintain amapping144 between, on the one hand, various dedicated logical links (such as the dedicatedlogical link19 and others) and, on the other, logical identifiers corresponding to those dedicated logical links.
• In an embodiment wheredatabase36 is integrated with or connected directly to theauthorization element142, thelogical identifier193 and the identity of the dedicatedlogical link193 to which it is assigned are sent back by theNAS23 to theauthorization element142, and it is theauthorization element142 that maintains theaforementioned mapping144 between dedicated logical links and logical identifiers corresponding to those dedicated logical links.
• Of course, those skilled in the art will be able to think of other ways of causing theend user equipment12 to send theaccess request184 over thelogical connection182 between theend user equipment12 and theNAS23, as well as other ways of assigning a logical identifier to the dedicatedlogical link19. It should further be mentioned that, in some cases, the establishment of the aforementioned PPPoE, PPP and/or IPCP sessions may not be required. This is particularly the case where the dedicatedlogical link19 is a VLAN.
• In view of the preceding description, and in particular given the previously describedmappings124,134 maintained in theOSS122 and/or theaccess multiplexer21 and the previously describedmapping144 maintained in theNAS23 or theauthorization element142, the following describes how one can create an association between logical identifiers and service point locations.
• Specifically, with reference toFIG. 8, by combining themapping124 with themapping134, theOSS122 can create anintermediate mapping166 between, on the one hand, dedicated logical links and, on the other hand, service point locations of end user equipment having logical connections with theNAS23 which traverse those dedicated logical links. In this example, theintermediate mapping166 would associate the dedicatedlogical link19 to the service point location of theend user equipment12. In one embodiment, theOSS122 transmits theintermediate mapping166 to the database36 (or a server associated therewith).
• At the database36 (or a server associated therewith), theintermediate mapping166 received from theOSS122 may be combined with the aforementioned mapping144 (received from theNAS23 or the authorization element142), thus creating a final mapping176 between, on the one hand, logical identifiers (such as IP addresses) and, on the other, service point locations of end user equipment having logical connections with theNAS23 which traverse respective dedicated logical links to which those logical identifiers have been assigned. In this example, the final mapping176 would specify that thelogical identifier193 corresponds to the service point location of theend user equipment12. This is precisely the type of association that is useful to store in thedatabase36.
• It will also be appreciated that in embodiments where logical identifiers are dynamically assigned to various end user equipment12 (e.g., in a dynamic IP address system), thedatabase36 may be updated accordingly.
• From the above, it should be apparent that thedatabase36 can be populated with logical identifiers (such as IP addresses) and service point locations associated with those logical identifiers. More generally, thedatabase36 can be populated with records for various logical identifiers, each record containing location information. The location information that can be contained in the record for a given logical identifier may be indicative of where the end user equipment to which the given logical identifier was assigned was located when access to the packet-switchednetwork14 was sought.
• While the above-described example illustrates one possible technique for populating a portion of thedatabase36, it will be appreciated that different techniques may be employed in different embodiments.
• Although the above-described example relates to an online transaction involving an online purchase using a credit card, it will be recognized that principles described herein apply to other types of online transactions, including, for example, those involving online purchases or payments using other payment objects (e.g., digital cash, electronic checks), online fund transfers involving accounts (e.g., bank accounts, online wallet accounts), attempts to access secure online content; and attempts to access a virtual private network, to name a few non-limiting possibilities.
• It should further be appreciated that although the above references to online transactions have involved thecomputing device16 effecting an online transaction with a merchant site over the packet-switchednetwork14, it is also within the scope of the invention for thecomputing device16 to be implemented as a communication device which is one party to a call and which effects an online transaction with another party reachable over the packet-switchednetwork14. Specifically, the communication device could be embodied as a VoIP phone, a Plain Old Telephone Service (POTS) phone equipped with an analog terminal adapter (ATA), or a soft phone (i.e., a computer equipped with telephony software). For its part, one party to the call can be a purveyor of goods or services.
• It should further be appreciated that any one or more of the above describedmessages102,104,106,108,114,116,118,120,121 may be encrypted prior to being transmitted. This encryption may be effected using the SSL protocol or some other suitable encryption technique, without limitation.
• Those skilled in the art will also appreciate that, in some embodiments, certain functionality of a given component described herein (e.g., thetransaction validation server51, theserver70, thepayment gateway60, thetransaction management server80, the servers30₁. . .30_N) may be implemented as pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.) or other related elements. In other embodiments, the given component may comprise a processor having access to a code memory which stores program instructions for operation of the processor to implement functionality of that given component. The program instructions may be stored on a medium which is fixed, tangible, and readable directly by the given component (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB key, etc.). Alternatively, the program instructions may be stored remotely but transmittable to the given component via a modem or other interface device connected to a network over a transmission medium. The transmission medium may be either a tangible medium (e.g., optical or analog communications lines) or a medium implemented using wireless techniques (e.g., RF, microwave, infrared or other wireless transmission schemes).
• Although various embodiments of the present invention have been described and illustrated, it will be apparent to those skilled in the art that numerous modifications and variations can be made without departing from the scope of the invention, which is defined in the appended claims.

Claims (36)

1. A method, comprising:

receiving a first identifier associated with an online transaction and a second identifier used by end user equipment involved in the online transaction;

obtaining evidentiary information pertaining to the end user equipment based on the second identifier;

storing in a database a record that associates the first identifier with the evidentiary information; and

retrieving one of (i) the evidentiary information in said record and (ii) the first identifier in response to a request identifying the other of (i) the evidentiary information in said record and (ii) the first identifier.

2. The method defined inclaim 1, wherein the request identifies the first identifier.

3. The method defined inclaim 2, wherein the request is received after said receiving the first identifier.

4. The method defined inclaim 3, wherein the request is issued by a party conducting a forensic investigation of the online transaction.

5. The method defined inclaim 1, wherein the request identifies the evidentiary information.

6. The method defined inclaim 5, wherein the request is received after said receiving the first identifier.

7. The method defined inclaim 5, wherein the request is received prior to said receiving the first identifier.

8. The method defined inclaim 7, wherein the request is issued by a party monitoring online transactions effected by a user associated with the first identifier.

9. The method defined inclaim 1, wherein the second identifier is a logical identifier assigned to the end user equipment.

10. The method defined inclaim 9, wherein the second identifier is an Internet Protocol address.

11. The method defined inclaim 9, wherein the online transaction is effected over a network, the method further comprising assigning the logical identifier to the end user equipment in response to the end user equipment requesting access to the network.

12. The method defined inclaim 9, wherein obtaining the evidentiary information comprises consulting a second database comprising a plurality of records each relating a respective logical identifier to one or more of a respective service point location and personal information about a respective subscriber.

13. The method defined inclaim 12, wherein the online transaction is effected over a network, the method further comprising assigning new logical identifiers to various new end user equipment requesting access to the network and updating the second database with (i) the new logical identifiers so assigned and (ii) for each of the new logical identifiers, one or more of a respective location of the corresponding new end user equipment and personal information about a respective subscriber whose credentials were used by the corresponding new end user equipment to gain access to the network.

14. The method defined inclaim 1, wherein the online transaction is effected over a network after the end user equipment has gained access thereto and wherein the evidentiary information includes information pertaining to a subscriber whose credentials were used by the end user equipment to gain access to the network.

15. The method defined inclaim 14, wherein the information pertaining to the subscriber includes personal information about the subscriber.

16. The method defined inclaim 1, wherein the online transaction is effected over a network after the end user equipment has gained access thereto and wherein the evidentiary information includes location information.

17. The method defined inclaim 16, wherein the location information comprises a location of the end user equipment when access to the network was gained.

18. The method defined inclaim 1, wherein the first identifier is a unique transaction identifier generated by an entity that is a member of a financial network.

19. The method defined inclaim 1, wherein said first identifier and said second identifier are received from an entity that is a member of a financial network.

20. The method defined inclaim 1, wherein said first identifier and said second identifier are received from a merchant site with which the end user equipment interacts to effect the online transaction.

21. The method defined inclaim 1, wherein the online transaction involves at least one of an attempt to make a payment and an attempt to effect a fund transfer.

22. The method defined inclaim 1, wherein the online transaction involves at least one of an attempt to access secure online content and an attempt to access a virtual private network.

23. A computer-readable medium comprising computer-readable program code which, when interpreted by a transaction management entity, causes the transaction management entity to execute a method, the computer-readable program code comprising:

first computer-readable program code for causing the transaction management entity to be attentive to receipt of a first identifier associated with an online transaction and a second identifier used by end user equipment involved in the online transaction;

second computer-readable program code for causing the transaction management entity to obtain evidentiary information pertaining to the end user equipment based on the second identifier;

third computer-readable program code for causing the transaction management entity to store in a database a record that associates the first identifier with the evidentiary information; and

fourth computer-readable program code for causing the transaction management entity to retrieve one of (i) the evidentiary information in said record and (ii) the first identifier in response to a request identifying the other of (i) the evidentiary information in said record and (ii) the first identifier.

24. A system comprising:

a transaction record database comprising a plurality of records, each of said records relating a respective first identifier associated with an online transaction to respective evidentiary information pertaining to end user equipment involved in the online transaction; and

a transaction management entity configured to respond to a request identifying one of (i) a given first identifier associated with a given online transaction and (ii) evidentiary information related by one of said records to a given first identifier by retrieving the other of (i) the given first identifier and (ii) the evidentiary information related thereto.

25. The system defined inclaim 24, the transaction management entity being further configured to populate the transaction record database with a record for the given first identifier further to receipt of the given first identifier and a respective second identifier used by end user equipment involved in the given online transaction.

26. The system defined inclaim 25, wherein to populate the transaction record database with the record for the given first identifier, the transaction management entity is configured to obtain said evidentiary information by consulting a second database on a basis of the second identifier, the second database comprising a plurality of records each relating a respective identifier to respective evidentiary information.

27. The system defined inclaim 26, wherein the given online transaction is effected over a network after the end user equipment has gained access thereto and wherein the evidentiary information includes information pertaining to a subscriber whose credentials were used by the end user equipment involved in the given online transaction to gain access to the network.

28. The method defined inclaim 26, wherein the given online transaction is effected over a network after the end user equipment has gained access thereto and wherein the evidentiary information includes location information indicative of a location of the end user equipment involved in the given online transaction when access to the network was gained.

29. A method of investigating an online transaction associated with a transaction identifier, comprising:

providing the transaction identifier to a transaction management entity;

obtaining from the transaction management entity evidentiary information pertaining to the end user equipment involved in the online transaction associated with the transaction identifier; and

comparing the evidentiary information to information associated with a transaction object used to effect the online transaction.

30. The method defined inclaim 29, further comprising:

concluding that the online transaction was fraudulent or illegal when the comparing yields that the evidentiary information does not match the information associated with the transaction object used to effect the online transaction.

31. The method defined inclaim 30, wherein the online transaction is effected over a network after the end user equipment involved in the online transaction has gained access thereto and wherein the evidentiary information includes information pertaining to a subscriber whose credentials were used by the end user equipment involved in the online transaction to gain access to the network.

32. The method defined inclaim 30, wherein the online transaction is effected over a network after the end user equipment involved in the online transaction has gained access thereto and wherein the evidentiary information includes location information indicative of a location of the end user equipment involved in the online transaction when access to the network was gained.

33. A method of identifying a suspect potentially responsible for effecting an online transaction associated with a transaction identifier, comprising:

providing the transaction identifier to a transaction management entity;

obtaining from the transaction management entity evidentiary information pertaining to the end user equipment involved in the online transaction associated with the transaction identifier; and

identifying as a suspect a party associated with the evidentiary information.

34. A network entity for participating in an online transaction taking place over a network, comprising:

a memory; and

a processing unit configured to:

obtain a transaction identifier associated with an online transaction and a logical identifier associated with end user equipment involved in the online transaction;

store in said memory a record that relates said transaction identifier to said logical identifier; and

transmit said transaction identifier and said logical identifier over the network to an entity responsible for storing a relationship between the transaction identifier and evidentiary information pertaining to end user equipment involved in said online transaction.

35. The network entity defined inclaim 34, wherein the evidentiary information includes information pertaining to a subscriber whose credentials were used by the end user equipment involved in the online transaction to gain access to the network.

36. The method defined inclaim 34, wherein the evidentiary information includes location information indicative of a location of the end user equipment involved in the online transaction when access to the network was gained.

Images