US20110047076A1 - Alias reputation interaction system - Google Patents

Abstract

Systems and method for generating reputation information for an alias are provided. The alias is associated with an entity. Payment transaction information related to a first alias associated with a first entity is received. The payment transaction information includes payment transactions performed by the first entity. In addition, non-payment transaction information related to the first alias is also received. The non-payment transactions include transaction between the first alias and one or more objects. The payment transaction information and the non-payment transaction information is analyzed to associate the one or more objects with the first alias. Thereafter, reputation information for the first alias is generated based at least in part on the payment transaction information and the non-payment transaction information.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS
• This application claims benefit under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/236487 filed Aug. 24, 2009 and entitled “Alias Identity and Reputation Engine”, U.S. Provisional Patent Application No. 61/240195 filed Sep. 5, 2009 and entitled “Alias Hierarchy and Data Services”, and U.S. Provisional Patent Application No. 61/241237 filed Sep. 10, 2009 and entitled “Alias Reputation Interaction System”, the disclosures of which are incorporated by reference herein in their entirety for all purposes.
• This application is related to U.S. Non-provisional Application No. ______ (Attorney Docket No. 016222-053210US) entitled “ALIAS IDENTITY AND REPUTATION VALIDATION ENGINE” filed on Jul. 29, 2010 and U.S. Non-Provisional Application No. ______ (Attorney Docket No. 016222-053110US) entitled “ALIAS HIERARCHY AND DATA STRUCTURE”, filed on Jul. 29, 2010.
BACKGROUND
• E-commerce has grown exponentially over the last decade. Along with the growth of e-commerce, many instances of fraud are also on the rise. Instances of fraud in the on-line world are harder to detect due to the relative anonymity enjoyed both by the seller and buyers.
• Currently, there is no comprehensive system of gathering data about consumers and merchants that will help to mitigate the instances of fraud by alerting consumers and merchants alike about the possibility of a unsuccessful transaction, prior to the transaction.
• There are many entities that provide information on a merchant's reliability and reputation, e.g., www.yelp.com. However, the currently available services are based mostly on consumer feedback. Consumer feedback is very subjective and as such is not very reliable for building a comprehensive profile for a merchant. On the other hand, currently there is no mechanism to provide such reputation information about individual consumers.
• Thus there is a need for a system that can gather information from various sources to build a comprehensive reputation profile for a consumer and/or a merchant.
SUMMARY
• Certain embodiments of the present invention provide a method for generating reputation information for an alias. The alias is associated with an entity. The method comprises receiving payment transaction information related to a first alias associated with a first entity. The payment transaction information includes payment transactions performed by the first entity. The method further includes receiving non-payment transaction information related to transactions between the first alias and one or more objects. Thereafter the method includes analyzing the payment transaction information and the non-payment transaction information and associating the one or more objects with the first alias based at least in part on the payment transaction information and the non-payment transaction information. The method further includes generating reputation information for the first alias based at least in part on the payment transaction information and the non-payment transaction information related to the first alias and to the one or more objects.
• In some embodiments, the method further includes receiving information about a transaction between a first object and a second object and associating the second object with the first object. In addition the method may include monitoring transaction information between the first alias and the one or more objects and updating the associations between the first alias and the one or more objects. Updating the associations may further include severing an association between a first object and the first alias or creating an association between a second object and the alias where none existed before.
• In some embodiments, the method also includes receiving information about payment transaction and non-payment transaction of a second alias and analyzing the information about the payment transaction and the non-payment transaction of the second alias to determine whether the second alias is associated with the first entity. If it is determined that the second alias is associated with the entity then associating the second alias with the first alias and associating the reputation information of the first alias with the second alias.
• Some embodiments of the present invention provide a system for generating reputation information for an entity. The system includes a data receiving module configured to receive payment transaction information and non-payment transaction information of an alias associated with an entity, an analysis module configured to analyze the payment transaction information and non-payment transaction information and associate an object with the alias based at least in part on the payment transaction information and non-payment transaction information, a storage module configured to store the association information between the object and the alias, a reputation information generation module configured to receive the association information and generate reputation information for the alias based on the payment transaction information and non-payment transaction information, and a network interface module configured to communicate with one or more external systems to receive the payment transaction information and non-payment transaction information and to send the reputation information.
• In some embodiments, the data receiving module receives the payment transaction information from a payment processing network and is further configured to periodically receive the payment transaction information between the object and the alias. In some embodiments, the analysis module is further configured to determine whether there is a first object that shares payment transaction information and/or non-payment transaction information with a second object, wherein both the first object and the second object are associated with the alias and associate the first object with the second object, if it is determined that the first object shares payment transaction information and/or non-payment transaction information with the second object. In some embodiments, the reputation generation module is further configured to receive information regarding a request for a transaction between a first object and the alias, determine a reputation for the first object and the reputation for the alias, determine a risk score for the transaction between the first object and the alias, and provide the risk score to the first object and to the alias.
• In some embodiments, the system may include a payment processing network configured to receive the reputation information of the first object and the reputation information of the alias and determine whether to allow or deny a transaction between the first object and the alias, based at least in part on the reputation information of the first object and the reputation information of the alias.
• The following detailed description, together with the accompanying drawings will provide a better understanding of the nature and advantages of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates a system incorporating an alias identity and reputation validation server computer according to an embodiment of the present invention.
• FIG. 2 illustrates a schematic for types of information associated with an alias of an individual according to an embodiment of the present invention.
• FIG. 3 illustrates a schematic for types of information associated with an alias of an entity according to an embodiment of the present invention.
• FIG. 4 illustrates an alias hierarchy and data structure according to an embodiment of the present invention.
• FIG. 5 illustrates the various management functions that may be performed on an object according to an embodiment of the present invention.
• FIG. 6 is a block diagram illustrating a payment transaction process according to an embodiment of the present invention.
• FIG. 7 is a block diagram of an alias identity and reputation validation computer server according to an embodiment of the present invention.
• FIG. 8 is a block diagram of a system for managing alias reputation information, according to an embodiment of the present invention.
• FIG. 9 is a functional block diagram of an alias identity and reputation validation system according to an embodiment of the present invention.
• FIG. 10 is a block diagram of a computer system.
DETAILED DESCRIPTION
• Certain embodiments of the present invention provide a method for conducting a transaction using a computer system. The method includes receiving a request for providing reputation information about an alias associated with an entity, searching a database to locate reputation information for the alias, and providing the reputation information for the alias where the reputation information includes a reputation score.
• Reputation information can be any information that indicates the trustworthiness of an entity to do business. For example, reputation information can include data such as number of years in business, yearly revenue, number of repeat customers, refund policy, warranty information, etc.
• In some embodiments, the method further includes receiving information about a payment device, a computer device, and location associated with the entity and searching the database to check whether there is a second alias whose payment device information, computer device information, and location information matches with the entity's information. If the payment device information, the computer device information, and the location information of the second alias match with the payment device information, the computer device information, and the location information of the entity then the second alias is associated with the entity.
• Another embodiment of the present invention provides a method for transferring alias reputation information across a plurality of domains using a reputation server computer. The method includes receiving information related to a first alias associated with a first entity, the first entity being coupled to a first domain, calculating a reputation score of the first alias, storing the information related to the first entity and the reputation score of the first alias in a database, receiving a request, from a client system coupled to a second domain, for providing a reputation score for a second alias, determining whether the second alias is associated with the first entity, and providing the reputation score of the first alias to the client system coupled to the second domain, if it is determined that the second alias is associated with the first entity.
• In some embodiments, a method for creating an alias data structure is provided. The method includes receiving information about a first alias associated with an entity, receiving information about a first object associated with the entity, analyzing the information about the first object; and associating the first object with the first alias based at least in part on the information about the first alias and information about the first object.
• Some embodiments of the present invention provide a method for generating reputation information for an alias, wherein the alias is associated with an entity. The method includes the steps of receiving payment transaction information of an alias associated with the entity, the payment transaction information including payment transactions performed by the first entity, receiving non-payment transaction information of the alias, the non-payment transactions including transaction between the alias and one or more objects, analyzing the payment transaction information and the non-payment transaction information, associating the one or more objects with the alias based at least in part on the payment transaction information and the non-payment transaction information, and generating reputation information for the alias based at least in part on the payment transaction information and the non-payment transaction information associated with the entity and the one or more objects.
• Transaction information is any information related to a transaction performed by an entity. In some embodiments, transaction information can include several items of information. For example, consider that a user ‘A’ purchases a gaming console from merchant ‘B’ for $300 using a credit card. in this instance transaction information includes name of the user ‘A’, name of the merchant ‘B’, the purchase price, the data and time of the transaction, location of merchant ‘B’, the model and serial number of the gaming console, the number of the credit card used for the purchase, the authorization information provided by the payment processing entity, and any other details that can be used to identify the transaction.
• FIG. 1 shows asystem100 including a reputation identity andvalidation server computer120. The reputation identity andvalidation server computer120 includes an alias hierarchy anddata structure database104. The details of the reputation identity andvalidation server computer120 and the alias hierarchy anddata structure database104 will be explained in detail below.System100 also includes afirst client computer101 and asecond client computer102.Client computers101 and102 may be coupled to amerchant computer110 that is coupled to a first online market place, e.g., a merchant doing business on Amazon.com. The same merchant computer may also be coupled to a second online marketplace, e.g., eBay. Theclient computer101 and102, the reputation identity andvalidation server computer120, and themerchant computer110 may communicate with each other over a network, e.g., the Internet.
Operation of the Reputation Identity and Validation Server Computer
• The operation of the reputation identity andvalidation server computer120 according to an embodiment will now be described.
• Merchant110 usually uses an alias to conduct business on the first online marketplace. An alias is an assumed name that themerchant110 may use to interact with potential consumers on the first online marketplace. For example, a merchant selling surfing and water related products may use an alias “summerfun” to identify him on the first online market place. Similarly, a consumer may also use an alias to interact with other consumers and/or merchants on the first online marketplace. The use of the alias has many advantages over conventional ways of using one's name or other details. First, a merchant or consumer needs to divulge his personal and financial details to the other party while conducting a transaction. The merchant and/or the consumer merely have to provide his alias to the other party in the transaction. The backend processing may then use the alias information and process the transaction. For example, a consumer with an alias “beachboy” may purchase a surfing board from a merchant with an alias “beachboy.” As part of the transaction, the consumer merely has to provide “summerfun” with his alias “beachboy.” When the merchant processes the transaction, a back-end payment processing system, e.g., VisaNet can match up the alias with the correct consumer and process the transactions through regular processing channels. Thus, the consumer “beachboy” has avoided giving his credit card number to the merchant “summerfun” and the transaction was conducted merely by providing an alias identity. Another advantage of using an alias is the relative anonymity that a consumer and merchant may enjoy. However, as discussed earlier, the anonymity of persons conducting transactions over the Internet gives rise to trust issues.
• In a typical transaction, a consumer will want to be assured that the transaction will proceed smoothly. This is not an issue with a traditional brick-and-mortar store since the consumer can actually carry his purchase with him immediately upon payment. Even in case of backordered items, the consumer can rely on the reputation of the store and knows that he has means to redress his problems should they arise. Online purchases do not enjoy the same type of trust relationships, partly because of the relative anonymity of the respective parties, lack of a proper mechanism to solve any issued that may arise, and lack of reliable information on trustworthiness of the parties involved in a transaction.
• To address some of these issues, various online marketplaces have come up with their own ratings system for each merchant doing business on that marketplace. However, as discussed above, the ratings information is often unreliable and does not provide a true picture about the trustworthiness of a merchant. Moreover, the ratings system is limited to the merchants only and no ratings system currently in operation provides ratings on consumers. A merchant rating is often the most commonly used system for reputation information. However, each consumer may also have a certain reputation of his own. For example, there may be a consumer who has a habit of returning every/most of the products he buys within the return period. Such a behavior may indicate the consumer is using the products for free and has no intention of ever buying the products. Such information about the consumer may be helpful to the merchant. If the merchant can access this information prior to conducting a transaction with the consumer, the merchant may decide against selling a product to that consumer since returned products end up costing the merchant money to restock and resell.
• The reputation identify and validation server computer solves these issues by compiling a database of information associated with individuals and entities and provide this information on request.
• Referring toFIG. 1, in one embodiment, a user of theclient computer101 conducts a transaction with merchant who using themerchant computer110 at a first online marketplace. The user of theclient computer101 has a bad experience with the merchant and leaves a negative feedback on the ratings section of the first online marketplace. Consider that the merchant has garnered enough negative reviews at the first online marketplace and as a consequence the merchant finds it difficult to sell his goods at the first online marketplace. The merchant now closes his shop at the first online marketplace and opens a new storefront at a second online marketplace using thesame merchant computer110. Since the merchant is new to the second online marketplace, he has no reputation/rating at the second online marketplace. In effect he has completely delineated himself from the negative ratings at the first online marketplace and now again continue perpetuating fraud at the second online marketplace with impunity. The current rating systems are restricted to a particular domain and hence cannot be accessed by users on other domains. For example, a user using theclient computer102 currently has no way to find out if the merchant at the second online marketplace is the same merchant with negative ratings at the first online marketplace.
• In an embodiment of the present invention, theclient computer102 can send a request to the reputation identity and validation computer server for providing reputation information about an alias associated with an entity, e.g., the merchant, prior to conducting a transaction with the entity. The reputation identity andvalidation server computer102 can search a database that stores alias reputation information and locate the reputation information for the alias and provide the reputation information to theclient computer102. Since the reputation and validation engine captures information about an alias from various sources and is not specific to a particular domain, even if the merchant moves from the first online marketplace to a second online marketplace, he cannot hide his identity from the alias identity and reputation validation server. Thus, even though the merchant is new to the second marketplace, the alias identity and reputation validation server computer can analyze the information gathered from the merchant at the second marketplace and match it with information received from the first marketplace and conclude that this is the same merchant. Once this is determined, all the reputation information and ratings for the merchant from the first marketplace is ported to the second marketplace. Thus, even on the first day of starting is business on the second marketplace, a merchant may have a long history of reputation information associated with him. This helps to rout out the bad merchants and promote good merchants.
• FIG. 2 illustrates some of the sources that the alias identity and reputationvalidation server computer120 may use to gather information about an entity or an individual and create a profile of that individual. An individual may use analias201 called “beachboy.” The alias identity and reputationvalidation server computer120 may store information about hiscredit card202,mobile phone203, the computer(s) that he uses to conductonline transactions204, a history of product returns205, hislocation206, information about histransactions207, and information about hishousehold208. It is to be noted that the list of items listed inFIG. 2 are for illustration purposes only. One skilled in the art will realize that there are many more sources of information that may be used to create a profile for an individual.
• FIG. 3 illustrates the various sources of information that may be used to create an alias profile of abusiness entity301. Thealias profile301 may include information about the financial institutions used by the entity to conduct itsbusiness302, the complaint history of theentity303, information about the server computer used by theentity304, any other aliases used by theentity305, location of theentity306, transaction information about theentity307, and anyratings information308. It is to be noted that the list of items listed inFIG. 3 are for illustration purposes only. One skilled in the art will realize that there are many more sources of information that may be used to create a profile for an entity.
• Since the alias identity and reputationvalidation server computer120 collects information from several sources, a potential merchant/entity and/or and individual will find it difficult to hide their identity from the alias identity and reputationvalidation server computer120. The data about an alias is stored within the alias identity and reputationvalidation server computer120 in form of an alias hierarchy anddata structure104.
• In an embodiment, once the alias identity and reputation validation server computer receives a request to provide reputation information about an alias associated with an entity, the alias identity and reputation validation server computer checks to see if the entity has additional aliases. If it is determined that the entity has additional aliases, the alias identity and reputation validation server computer searches for reputation information of the additional aliases. The alias identity and reputation validation server computer can then provide the information about the other aliases in addition to the reputation information of the alias that is requested. For example, if a single entity is using two different aliases “summerfun” and “indiansummer” to do business on two different marketplaces, the alias identity and reputation validation server computer can consolidate the reputation information for both these aliases and make that consolidated reputation information available to anyone searching for reputation information about either “summerfun” or “indiansummer.” Thus it will be hard for that entity to hide its identity from the alias identity and reputation validation server computer.
• In some embodiments, the alias identity and reputation validation server computer may determine whether the entity has additional aliases by receiving information about a payment device, e.g., a credit card or an account held at a financial institution, information about a computer device used by the entity, and location of the entity. In some embodiments, the information about the computer device may include an Internet Protocol (IP) address of the computer device, hardware configuration information of the computer device, and information about applications installed on the computer device. The alias identity and reputation validation server computer then searches the database to check whether there is a second alias whose payment device information, computer device information, and location information matches with the entity's information. If the payment device information, the computer device information, and the location information of the second alias match with the payment device information, the computer device information, and the location information of the entity, the alias identity and reputation validation server computer associates the second alias with the entity. For example, as described above, if a single entity is using two different aliases to conduct its business but is using the same payment device, the same server computer and is operating out of the same location, the alias identity and reputation validation server computer analyzes this information and concludes that both these aliases belong to the same entity and links the two aliases together.
• In some embodiments, the reputation information for an alias may be presented in the form of a reputation score. In some embodiments, a ‘reputation score’ can refer to any relative value that can be associated with the reputation of an alias. The reputation score can measure the relative reputation of an alias (e.g., a Website name, a payee name that is not the same as an actual payee name, etc.) relative to other aliases. It may alternatively be an absolute score. Such scores may be represented by numbers, letters, or any other suitable type of value. In general, the reputation score conveys a level of trustworthiness of a particular alias, both as a standalone value and in relation to other aliases. For example, in one embodiment, the reputation score can be based on a scale of 1 to 100, where 1 represents the lowest score indicating very poor customer service while a score of 100 indicates superior customer service. It is to be understood, that various other ways of indicating a reputation score are also possible. The reputation score may be displayed in the vicinity of the alias whenever the alias is presented to the requestor. In other embodiments, the reputation information and/or reputation score may be stored on a central server or the alias identity and reputation validation computer server and the user may be provided a link to access the reputation information/reputation score. Upon clicking the link, a potential user who is looking for reputation information about an alias, will be directed to a dedicated location where the reputation information is available. In some embodiments, access to the reputation information may be provided free of cost to the user. In other embodiments, access to the reputation information may be subscription based for a nominal fee.
• In some embodiments, the alias identity and reputation validation server computer receives information related to a first alias that is associated with a first entity. The first entity is coupled to a first domain, e.g., the first online marketplace ofFIG. 1. The alias identity and reputation validation server computer calculates a reputation score of the first alias based on information related to the first alias. The alias identity and reputation validation server computer stores the information related to the first entity and the reputation score of the first alias in a database. The alias identity and reputation validation server computer receives a request from a client computer that is coupled to a second domain e.g., the second online marketplace ofFIG. 1 for providing a reputation score for a second alias. The alias identity and reputation validation server computer determines whether the second alias is associated with the first entity. If the alias identity and reputation validation server computer determines that the second alias is associated with the first entity, the alias identity and reputation validation server computer provides the reputation score of the first alias to the client computer coupled to the second domain. For example, consider that the first entity is a merchant having an alias ‘merchant1’ is operating as firstmarket.com and the same merchant uses the alias ‘merchant2’ and operates as secondmarket.com. Consider that ‘merchant1’ has been in business for a long time and has garnered a reputation score of 80, which can indicate that ‘merchant1’ has good customer service. On the other hand ‘merchant2’ is relatively new and does not have a reputation score. In this instance, a user wishing to do business with ‘merchant2’ might be apprehensive about dealing with ‘merchant2’. In this instance, the alias identity and reputation validation server can analyze the information about ‘merchant2’, e.g., server details, location, IP address, etc. and determine that ‘merchant2’ is the same as ‘merchant1’ and can transfer the reputation information, e.g., a reputation score of ‘merchant1’, and associate that reputation score to ‘merchant2’. Thus a user wishing to do business with ‘merchant2’ can now be provided with the reputation score even though ‘merchant2’ is new to the market.
• In some embodiments, the alias identity and reputation validation computer server, as part of calculating the reputation score for an alias, analyzes transaction information related to the first alias to determine a transaction risk score for the first alias. The alias identity and reputation validation computer server also analyzes the non-transaction based information related to the first alias and calculates a reputation score based at least in part on the transaction risk score and the non-transaction information. A transaction risk score can be an indication about the likelihood of a particular transaction being processed successfully. In other words, a transaction risk scores can predict a likelihood of success of a particular transaction. For example, consider that the transaction history of a user with alias ‘user A’ reveals that ‘user A’ has been involved in numerous transactions that resulted in the ‘user A’ returning the product that was previously bought. A potential merchant who wants to sell a product to ‘user A’ can be provided with this information in the form of a transaction score indicating that there is low likelihood of the transaction completing successfully. The merchant can then decide whether he wants to do business with ‘user A’. In addition, this information can be used to generate reputation information for ‘user A’.
• In some embodiments, the transaction information for the first alias may include information about a payment method used by the first entity, a history of chargebacks offered by the first entity, a financial entity where the first entity has an account, and complaints received by the first entity for its products or services. The non-transaction information for the first alias may include information about a computer system used by the first entity, location of the computer system used by the first entity, and contact information of the first entity. It should be noted that the examples for transaction and non-transaction information discussed above are for illustration purposes only. One skilled in the art will realize that there are many more types of transaction and non-transaction information that may be received and analyzed by the alias identity and reputation validation computer server.
• In some embodiments, in order to determine whether the second alias is associated with the first entity, the alias identity and reputation validation computer server receives information about the second alias. The information includes transaction information and non-transaction information. The alias identity and reputation validation computer server compares the information about the second alias with information related to the first alias. If the information about the second alias matches with the information related to the first alias, the alias identity and reputation validation computer server associates the second alias with the first entity. In some embodiments, the information about the second alias need not completely match the information related to the first alias. Criteria for matching can be set in order to conclude that the second alias is linked to the first entity. For example, certain types of transaction information and non-transaction information may be given importance in the matching process. If a certain percentage of important items of transaction information and non-transaction information are common between the second alias and the first alias, the alias identity and reputation validation computer server can conclude that the second alias also belongs to the first entity. For example, the information about a bank account for the first entity may have higher importance than a history of chargebacks offered by the entity. Similarly, information about the hardware configuration of the server used by the first entity may have more significance than the information about applications running on the server. It will be realized that the criteria may be customized according to the use cases and may be modified at any given point.
• The alias identity and reputation validation computer server stores data related to one or more aliases. Each item that is linked to an alias is called an “object.” An object can be a device, a person, or an entity/organization. For example, reference numerals202-207 ofFIG. 2 and reference numerals302-308 ofFIG. 3 are objects linked to their respective alias. The alias identity and reputation validation computer server receives transaction data related to one or more aliases and creates an alias hierarchy and data structure in order to establish the various bindings between the aliases and their objects.
Alias Hierarchy and Data Structure
• FIG. 4 illustrates an alias hierarchy anddata structure tree400 according to an embodiment of the present invention. The alias hierarchy anddata structure tree400 includes a top-level alias401 to which all other aliases and objects are linked. Thealias401 may be associated with an entity/organization, a person/individual, or a device. In some embodiments,alias401 may be linked to other aliases within or outside a particular tree.Alias401 may be linked tovarious hierarchy groups410,420, and430. The hierarchy groups are used to arrange the data in a manageable form and for ease of search using standard database queries. Each of these hierarchy groups may represent a particular area, e.g., devices, household, individual, entity/business, etc. InFIG. 4, thehierarchy group410 is referred to as the business domain. This hierarchy group relates to a business entity that may be owned or operated by owner of thealias401. Thehierarchy group410 may have several objects linked to it. Each of the objects linked to thehierarchy group410 in turn may have an alias associated with them. As illustrated, thehierarchy group410 may have anobject411 associated with it. Theobject411 may be a network used by the business entity. Theobject411 may further haveobjects412 and413 associated with it. In an embodiment, object412 may be the internet service provider (ISP) used by the business entity and theobject413 may be the telephone company that provides telephone service to the business entity. In addition, thehierarchy group410 may have other network type objects linked to it. Theobject413 may also haveother objects414 and415 linked to it. Theobject413 may represent a financial institution, e.g., a bank, which issues acredit card414 and where the business entity has itschecking account415. Each of theobjects414 and415 may also have an alias associated with them. Similarly,hierarchy group410 may have anotherfinancial institution416 associated with it that may represent a different bank where the business entity has an account.
• Hierarchy group420 is related to an individual domain. Thehierarchy group420 includes information about an individual and his household. For example,hierarchy group420 may have anobject421 that represents the spouse of the individual, anobject422 that specifies the gender of the individual, anobject423 that represent the children of the individual, and anobject424 that represents the household of the individual. Theobject424 may be further liked to one or more objects that represent, the address of the household, the parcel number of the household, etc. Similarly, object421 may be further linked to other objects that represent the spouse's age, gender, any other children of the spouse, etc.
• Hierarchy group430 is related to devices that may be used by a business entity or an individual. Thehierarchy group430 may also have various subjects associated with it. In an embodiment, the hierarchy group may haveobjects431,432,433, and444 associated with it. Theobject431 may represent the vehicle owned by the individual or the business entity. Theobject432 may represent the computer owned by the individual or the business entity. Theobject433 may represent various other electronic devices owned by the individual or the business entity. Theobject434 may represent a cell phone owned by the individual or the business entity. In some embodiments, theobject434 may have additional objects associated with it that may represent various attributes of theobject434. For example, theobject434 may have attributes that represent a phone number, serial number of the cell phone device, a serial number of a SIM card installed in the cell phone, associated with theobject434. In some embodiments, each of the attributes may be an object and have a unique alias associated with the object. As described earlier, each of the objects associated with any of the hierarchy groups may have a unique alias associated with them.
• In some embodiments, an object in one hierarchy group may also be associated with another object in a different hierarchy group. For example, object434 (cell phone) may be associated withobject414 in the instance where the cell phone is also a payment device, e.g., implementing contactless card technology. In some embodiments, one hierarchy group may be linked to another hierarchy group for the same alias or a different alias. For example, if a husband and wife share the same household, the hierarchy group associated with the household may be linked to alias of the husband as well as the alias of the wife, or to any other hierarchy groups that are linked to the alias of the husband or the wife.
• Thus it can be seen that each hierarchy group can include multiple levels of objects linked to each other within the same hierarchy group. In addition, objects in one hierarchy group can be linked to objects in different hierarchy groups.
• In some embodiments, the alias identity and reputation validation computer server generates the alias hierarchy and data structure. The method for generating the alias hierarchy and data structure includes receiving transaction information related to a first alias that is associated with an entity. The method further includes receiving transaction information between a first object and the entity, and associating the first object with the first alias based at least in part on the transaction information related to the first alias and transaction information between the first object and the entity. For example, when person A buys a gaming console using his credit card, the gaming console can be associated with that person based on the transaction of buying the gaming console. The person may have an alias associated with him. The credit card and the gaming console are objects. So when information about a transaction of the person A buying the gaming console is received by the alias identity and reputation validation computer server, it can associate the gaming console with the alias of person A. An entity can be a person or an organization, e.g., a business. An object can be a device, a person, or an organization
• In some embodiments, the transaction information received by the alias identity and reputation validation computer server can include payment transaction information as well as non-payment transaction information. For example, as described above, whenever someone buys an item, the payment transaction information can be received by the alias identity and reputation validation computer server, e.g., via a payment processing network. A non-payment transaction is the one where the details of the transaction cannot be captured by the payment processing entity or any other financial institutions. For example, a person may decide to meet another person in a city where the two persons only had an on-line interaction prior to the in-person meeting. In such an instance, it would be beneficial for both the persons to know whether the other person is reputable enough to be trusted. Some of the other non-payment transactions may include cash-only transactions that cannot be automatically captured by the payment processing entity.
• In some embodiments, the alias identity and reputation validation computer server continually monitors transaction information related to an alias, e.g. a person. The alias identity and reputation validation computer server updates the association of the alias with an object in response to the received transaction information. For example, if that person purchases a camera using his alias, the camera is automatically associated with the alias of that person. In some embodiments, updating the association includes adding objects to a particular alias hierarchy. In some embodiments, updating the associations can also include severing the association if it is determined that the object is no longer associated with the alias based at least in part on the transaction information related to the first object. For example, if that same person now returns the camera, the association between the camera and the alias of the person is severed based on the information received from the transaction of returning the camera.
• In some embodiments, the method of generating the alias hierarchy structure further includes analyzing the associations of various objects. If it determined that there are two objects that are associated with the same alias, the alias identity and reputation validation computer server associates the two objects with each other. For example, if a male person A is associated with a female person B and a child C under the same hierarchy group, then the alias identity and reputation validation computer server analyzes this association and determines whether the female person B should be associated with the child C. In some embodiments, if the female person B is associated with the child C if there are other factors that suggest that association is proper. As described above, in addition to associating an object with an alias, an alias can also be associated with another alias in a similar manner by analyzing the association of one or more objects with the two aliases.
• In addition to the transaction information about objects being automatically received by the alias identity and reputation validation computer server, each object can be individually managed manually by the owner of the alias to which the object is associated with. Not all information about an object can be automatically obtained. In such instances, it may be necessary to manually manage the information and association of such objects. For example, if a buyer purchases a computer from a seller, both of whom are individuals, using cash payment, there is no reliable way of recording this transaction. The alias identity and reputation validation computer server will have no way of knowing that the computer now belongs to the buyer and that the computer should be associated with the buyer. In such instances, the buyer will have to send the information about the computer to the alias identity and reputation validation computer server so that the alias identity and reputation validation computer server may associate the computer with the buyer.
• Some embodiments of the present invention provide means for managing objects. The means can be provided a web interface that can communicate with the alias identity and reputation validation computer server. A user can enter information relating to an object via the web interface and communicate that information to the alias identity and reputation validation computer server. The alias identity and reputation validation computer server can then update the association accordingly. One skilled in the art will realize that management function for the objects may be provided using various other means. For example the management functions for the various objects may be implemented as a GUI interface accessible by the user. The GUI interface may be accessible to the person or entity over a network, e.g., the Internet. In some embodiments, the various management functions for the object may be accomplished by using a portable communication device, e.g., a cellular phone. In some embodiments, a method for managing one or more objects associated with an alias is provided. The method includes receiving input related to a first object that is associated with a first alias. The input specifies an operation to be performed on the object. The method further includes performing the specified operation on the object and updating association information between the first object and the first alias based at least in part on results obtained after performing the specified operation. In some embodiments, the specified operation is chosen from a list comprising deleting the first object, duplicating the first object, updating one or more attributes of the first object, and revoking one or more privileges associated with the first object. The various operations that can be performed on an object are described below.
• FIG. 5 illustrates the various management functions that can be performed on anobject500, according to an embodiment of the present invention. In an embodiment, the management functions can be facilitated through a web interface accessible by the user. In other embodiments, the management function can be implemented in a client-server environment where the user computer is the client and the alias identity and reputation validation computer server can act as the host server. In some embodiments, the object management functions can be categorized as maintenance functions510 andtransactional functions520. In some embodiments, the maintenance functions510 can include a createfunction511, anupdate function512, a revokefunction513, and aduplicate function514. The transactional function may include anauthenticate function521, aroot alias function522, asignature function523, and arisk score function524.
• Createfunction511 can be used to add a new object to an alias hierarchy and associate that object with an alias and/or other objects. For example, as described above, if a user purchases a mobile communication device from another user by paying cash, the payment processing system cannot capture this transaction. In such an instance, the user can manually add the mobile communication device to his alias using the createfunction511. Theupdate function512 can be used to update association information between an object and an alias or another object. For example, consider that a person owns a gaming console that has been linked to his alias. If the person then gifts the gaming console to his kid, the person may want to disassociate the gaming console from his alias and add the gaming console to the kid's alias. The person can then use the update function to change the linkage of the gaming console from his alias to his kid's alias. In some embodiments, theupdate function512 can include the createfunction511 and the revokefunction513. The revokefunction513 can be used to delete an association of an object with an alias or to delete an object from a hierarchy group. In some embodiments, the revoke function can also be used to disable one or more attributes of an object. For example, wireless connectivity of a portable media player can be disabled using the configuration menu of the portable media player. Theduplicate function514 may be used to assign a same alias to two different objects. For example, a person may have a home computer and a work computer. He may want to interchangeably use both computers without any external system knowing which computer he is using at any given time. In such an instance, the person can manually assign the same alias to both the computers and link the two computers to his alias using theduplicate function514.
• Transactional functions520 are managed by the alias identity and reputation validation server as part of transaction authorization and authentication process described below inFIG. 6. Usually, a payment processing system, e.g., VISANet, incorporating the alias identity and reputation validation computer server may perform the transactional operations related to an object. The various transaction functions described below may be performed real-time when a transaction is received by the payment processing system for validation and authorization. These transactional functions are transparent to the parties involved in the transaction.
• Authorizefunction521 relates to determining whetherobject500 is authorized to conduct the transaction. For example, object500 may be a child in a household that has a credit card liked to it. The credit card for the child is also linked to his father's alias and has a certain spending limit associated with it. If the child attempts to conduct a transaction that is more than the spending limit on his credit card, authorizefunction521 checks the alias hierarchy to determine whether the child, e.g.,object500, is authorized to spend the requested amount and accordingly deny the transaction if the transaction amount is more than the spending limit. In some embodiments, authorizefunction521 may cause generation of a message that is delivered to the father (root alias) of the child indicating the details of the transaction. The father may then decide to approve the transaction.
• Root alias function522 may be used to determine the root alias ofobject500. For example, in the example above, the system may check the root alias of the child requesting the transaction prior to processing the transaction. In other words, the system may determine the root alias, e.g.,alias domain401 ofFIG. 4, of the alias hierarchy that the child belongs to and verify that the information provided by the child during the transaction matches with information of the root alias. In the instance that the child's credit card is stolen and is being used in a different city then the child's usual place of residence, the system may check the root alias to determine the probability that the person using the credit card currently is the child based on other information about the child stored in the alias hierarchy. The system may deny or put a hold on the transaction if it is determined that the root alias information does not match with the person currently using the credit card. The system may request additional information from the child and/or the father (root alias) to determine authenticity of the transaction.
• Signature/authenticate function523 may be used to authenticateobject500 as being the proper entity as represented. This function is similar to verification of signature or other authenticating methods used in the conventional payment processing system. The difference being this is done real-time as part of the payment processing process using the information in the alias tree in addition to information gathered from other sources.
• Risk score function524 may be used to generate a risk score for the particular transaction. In some embodiments, the risk score may be based on results obtained fromfunctions521,522, and523. Based on the various determinations aboutobject500 and its root alias, the system can generate a real-time risk score for the transaction. Risk score is described in detail above.
• The various functions described above in relation to management and verification of an object are for illustrative purposes only. One skilled in the art will realize that various other functions may be provided for managing and verifying the objects. The additional functions may be in addition to or in lieu of the functions described above.
The Alias Identity and Reputation Validation Computer Server
• As described above, the alias identity and reputation validation computer server received information about payment transaction information and non-payment transaction information for an alias and/or and object and based on that information, the alias identity and reputation validation computer server manages an association between an object and an alias. In some embodiments, the alias identity and reputation validation computer server receives the payment transaction information through a payment processing network, which acts as a payment clearance entity for payment transactions.FIG. 6 shows an embodiment of a typical payment processing transaction.
• FIG. 6 shows a system620 that can be used in an embodiment of the invention. The system620 includes amerchant622 and anacquirer624 associated with themerchant622. In a typical payment transaction, aconsumer630 may purchase goods or services at themerchant622 using aportable consumer device632. Theacquirer624 can communicate with anissuer628 via apayment processing system626.
• Theconsumer630 may be an individual, or an organization such as a business that is capable of purchasing goods or services.
• Theportable consumer device632 may be in any suitable form. For example, suitable portable consumer devices can be hand-held and compact so that they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). They may include smart cards, ordinary credit or debit cards (with a magnetic strip and without a microprocessor), keychain devices (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), etc. Other examples of portable consumer devices include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, and the like. The portable consumer devices can also be debit devices (e.g., a debit card), credit devices (e.g., a credit card), or stored value devices (e.g., a stored value card).
• Thepayment processing system626 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing system may include VisaNet™. Payment processing systems such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services.
• Thepayment processing system626 may include a server computer. A server computer is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. Thepayment processing system626 may use any suitable wired or wireless network, including the Internet.
• Themerchant622 may also have, or may receive communications from, anaccess device634 that can interact with theportable consumer device632. The access devices according to embodiments of the invention can be in any suitable form. Examples of access devices include point of sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld specialized readers, set-top boxes, electronic cash registers (ECRB), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like.
• If theaccess device634 is a point of sale terminal, any suitable point of sale terminal may be used including card readers. The card readers may include any suitable contact or contactless mode of operation. For example, exemplary card readers can include RF (radio frequency) antennas, magnetic stripe readers, etc. to interact with theportable consumer devices632.
• In a typical purchase transaction, theconsumer630 purchases a good or service at themerchant622 using aportable consumer device632 such as a credit card. The consumer'sportable consumer device632 can interact with anaccess device634 such as a POS (point of sale) terminal at themerchant622. For example, theconsumer630 may take a credit card and may swipe it through an appropriate slot in the POS terminal. Alternatively, the POS terminal may be a contactless reader, and theportable consumer device632 may be a contactless device such as a contactless card.
• An authorization request message is then forwarded to theacquirer624. After receiving the authorization request message, the authorization request message is then sent to thepayment processing system626. Thepayment processing system626 then forwards the authorization request message to theissuer628 of theportable consumer device632.
• After theissuer628 receives the authorization request message, theissuer628 sends an authorization response message back to thepayment processing system626 to indicate whether or not the current transaction is authorized (or not authorized). Thetransaction processing system626 then forwards the authorization response message back to theacquirer624. Theacquirer624 then sends the response message back to themerchant622.
• After themerchant622 receives the authorization response message, theaccess device634 at themerchant622 may then provide the authorization response message for theconsumer630. The response message may be displayed by the POS terminal, or may be printed out on a receipt.
• At the end of the day, a normal clearing and settlement process can be conducted by thetransaction processing system626. A clearing process is a process of exchanging financial details between and acquirer and an issuer to facilitate posting to a consumer's account and reconciliation of the consumer's settlement position. Clearing and settlement can occur simultaneously.
• FIG. 7 illustrates a block diagram of an alias identity and reputation validation computer server (henceforth “alias sever”)700 according to an embodiment of the present invention. Thealias server700 includes anetwork interface module710. Thenetwork interface module710 communicates with one or more external systems in order to send and receive data. In some embodiments, thenetwork interface module710 communicates with a payment processing network to gather payment transaction data related to one or more aliases and/or objects. In some embodiments, thenetwork interface module710 communicates with one more devices (objects) on the Internet to gather non-payment transaction data related to the devices in order to determine the alias that the devices are associated with. In an embodiment, the non-payment transaction information includes information about data transmission between an alias and an object. In some embodiments, thenetwork interface module710 sends the reputation information to any client computer that requests such information.
• Thealias server700 further includes adata receiving module711 that receives payment transaction information and non-payment transaction information of an alias associated with an entity and/or an object, from thenetwork interface module710. Thedata receiving module711 communicates the received data to adata analysis module712. In some embodiments, thedata receiving module711 includes thenetwork interface module710 and receives the payment transaction information directly from a payment processing network. In some embodiments, thedata receiving module711 is configured to periodically receive the payment transaction information between the object and the alias. Thedata analysis module712 analyzes the payment transaction information and non-payment transaction information related to the object and/or the entity and associates the object with the alias based at least in part on the payment transaction information and non-payment transaction information, wherein the payment transaction information and non-payment transaction information includes transactions between the alias and the object. Thedata analysis module712 communicates the association information between the alias and the object to a reputation information/score generating module713 and also communicates the association information to astorage system714. In some embodiments, thedata analysis module712 determines whether there is a first object that shares payment transaction information and/or non-payment transaction information with a second object, wherein both the first object and the second object are associated with the alias and associates the first object with the second object, if it is determined that the first object shares payment transaction information and/or non-payment transaction information with the second object.
• The reputation information/score generating module713 further analyzes the received association information and applies a set of predetermined criteria to evaluate transaction risk for the object and the alias. In some embodiments, the criteria include looking at the prior history for the alias to predict future behavior of the alias, the type of transaction, the amount of transaction, etc. In some embodiments, the reputation information/score generating module713 can generate a numeric score to indicate a reputation of the alias. In some embodiments, the reputation information/score generating module713 generates reputation information for the alias based on the payment transaction information and non-payment transaction information. In some embodiments, the reputation information/score generating module713 receives information regarding a request for a transaction between a first object and the alias. In this instance, the reputation information/score generating module713 determines a reputation for the first object and the reputation for the alias and in addition determines a risk score for the transaction between the first object and the alias. The reputation information/score generating module713 then provides the risk score to the first object and to the alias. In some embodiments, the reputation information/score generating module713 continually updates the reputation information for an alias based on payment transactions and non-payment transactions conducted by the alias.
• In some embodiments, the reputation score is calculated based on frequency of transactions performed by an alias over a period of time. For example, consider that a person buys gas from a particular gas station near his house once a week on Saturday. Thealias server700 gathers this information over a period of time to build a profile of that person. In doing so, the alias server may assign a score of 400 for that particular activity. This score is adjusted on a weekly basis based on the person's gas purchase. So, when the person purchases gas inweek 1 at that gas station his reputation for that transaction may be lowered to zero until he buys gas again the following week. If that person buys the gas as expected inweek 2 at that gas station, his reputation score becomes 400 again since he has acted in conformity to his pattern of behavior. On the other hand if the person buys gas inweek 2 from a different gas station, his reputation score may only be 200 since the expected behavior did not occur. In the instance where the person follows a regular routine of filling gas at the particular gas station, his reputation score keeps on improving with each successive gas purchase. The same method can be applied to any other payment transaction conducted by the person to determine a reputation score. Details of frequency based transaction processing are described in commonly-owned and co-pending U.S. patent application Ser. No. 12/773,770 filed on May 4, 2010, the contents of which are hereby incorporated by reference in their entirely for all purposes. Thereafter, the non-payment transactions can be factored in to generate comprehensive reputation information about that person.
• In some embodiments, the reputation information/score is generated based on the context of transactions performed by the alias using a customized technique in addition to the frequency. Context-based transactions can be further categorized into expected state context and current state context. For example, in the gas station example described above, the system can predict based on the person's past behavior that the person is likely to buy gas at that gas station on a certain day of the week. In some embodiments, the system can alert the gas station that they should expect the person to buy gas. The gas station may then offer a coupon or some other incentive to the person increasing the chances that the person will buy gas from that gas station. The current state context refers to the situation where the person actually buys gas at the gas station as expected. In some embodiments, when the expected state context matches the current state context, it may result in a positive reputation for the person and vice versa.
• In some embodiments, the reputation score may vary by time and space. For example, if analysis of consumer's transactions over time indicates that he buys gas at a gas station near his residence in city A every week, the consumer may be assigned a reputation score of e.g., 700 (very good). However, if a transaction indicates that the consumer bought gas in a different city B, which he has never visited before, he and/or the transaction may be assigned a reputation score of 50 (very low) for city B indicating that this does not conform to the consumer's pattern of transactions. A low reputation score may alert the concerned organizations, e.g., the issuer, to monitor the transaction for possible fraud. In such instances, the issuer may use an out of band communication method, e.g., a phone call, to confirm the transaction with the consumer before authorizing the transaction in city B. This helps to safeguard the consumer from possible fraud on his account and also helps the issuer by limiting their exposure to potential fraudulent transactions using their payment devices.
• Once the reputation information/score generating module713 generates the reputation information/score, that information/score is communicated to thestorage system714. As discussed above, thestorage system714 also stores the association information between the object and the alias. In some embodiments, the reputation information/score and the association information between the object and the alias can be stored in an alias database implemented in thestorage system714. The alias database may be a conventional database including capability of being searched at multiple levels with the use of proper queries. In some embodiments, thestorage system714 also stores the alias hierarchy and data structure, e.g., as discussed with reference toFIG. 4 above. Thealias server700 further includes aprocessor715 that controls the operation of thealias server700 and provides the computing power to perform the various operations. Thealias server700 also includes aprocessor715 that is coupled to the various modules and provides the means for operating thealias server700.
• In some embodiments, thealias server700 sends the reputation information for an alias and/or an object to a payment processing network. The payment processing network receives the reputation information of the object and the reputation information of the alias and determines whether to allow or deny a transaction between the object and the alias, based at least in part on the reputation information of the object and the reputation information of the alias.
• Some embodiments of thealias server700 can perform a method for generating reputation information for an alias, wherein the alias is associated with an entity. The method includes receiving payment transaction information related to a first alias associated with a first entity. In some embodiments, the payment transaction information includes payment transactions performed by the first entity. The method further includes receiving non-payment transaction information related to the first alias where the non-payment transactions include transaction between the first alias and one or more objects. Thealias server700 analyzes the payment transaction information and the non-payment transaction information and associates the one or more objects with the first alias based at least in part on the payment transaction information and the non-payment transaction information. Thealias server700 generates reputation information for the first alias based at least in part on the payment transaction information and the non-payment transaction information related to the first alias and to the one or more objects. In some embodiments, thealias server700 receives information about a transaction between a first object and a second object, from among one or more objects and associates the second object with the first object. In some embodiments, thealias server700 periodically monitors transaction information between the first alias and the one or more objects and updates the associations between the first alias and the one or more objects. As discussed above, the updating of the associations can include severing an association between a first object and the first alias or creating an association between a second object and the alias where none existed before.
• In some embodiments, thealias server700 receives the payment transaction information is received from a payment processing network, e.g., VisaNet. In some embodiments, generating reputation information includes generating a reputation score for the first alias. In some embodiments, the method for generating reputation information includes providing risk analysis information for a transaction between the first alias and an object after initiation of the transaction but prior to completion of the transaction. In some embodiments, the method further includes receiving information about payment transaction and non-payment transaction of a second alias, analyzing the information about the payment transaction and the non-payment transaction of the second alias to determine whether the second alias is associated with the first entity, and if it is determined that the second alias is associated with the entity, associating the second alias with the first alias and associating the reputation information of the first alias with the second alias.
• FIG. 8 is a block diagram of asystem800 for generating and managing reputation information according to an embodiment of the present invention. Thesystem800 includes a payment processing andanalysis module802, adata collection module804, analias indexing module806, analias profiling module808, analias caching module810, an aliasbatch processing module812, analias joining module814, apredictive alias module816, and aweb server818.
• The payment processing andanalysis module802 captures all the payment transaction data for an alias. In some embodiments, the payment processing andanalysis module802 is operated by a payment processing entity and captures real-time data related to payment transactions conducted by a person or an entity. In some embodiments, the payment processing andanalysis module802 uses a frequency based transaction processing technique described above to analyze the process the payment transaction. The payment processing andanalysis module802 can be implemented using specialized server computer(s) that includes customized software and are programmed to manage payment authorization and processing.
• The payment processing andanalysis module802 communicates the collected raw transaction data to thedata collection module804. Thedata collection module804 can be implemented as one or more server computers. In some embodiments, thedata collection module804 is a hadoop cluster with over 10 petabytes of storage capacity. A Hadoop Distributed File System (HDFS) can store large files across multiple machines. The hadoop system achieves reliability by replicating the data across multiple hosts, and does not require RAID storage on hosts. In some embodiments, thedata collection module804 can store up to 7-years of transaction data for multiple aliases. In some embodiments, thedata collection module804 can be implanted as part of a cloud computing system. The raw transaction data collected by thedata collection module804 is made available to thealias indexing module806 and thealias profiling module808 to create the linkages between various transactions and the aliases/objects that are involved in the transactions.
• Thealias indexing module806 creates the links between the transactions captured by the payment processing andanalysis module802 and the various aliases/objects involved in the transactions. In some embodiments, thealias indexing module806 outputs the information about the links between the aliases and objects to thealias caching module810 for immediate delivery to a requesting party. For example, a consumer may buy gas at a particular gas station. Thealias indexing module806 may include information indicating a link between the person and the gas station. However, thealias indexing module806 may not have any information about the person e.g., name, or the gas station e.g., location of the gas station. In some embodiments, the consumer and the gas station may be represented by a series of alphanumeric characters. In some embodiments, thealias indexing module806 also stores other information relating to system security and stability. In some embodiments, thealias indexing module806 can be part of a cloud computing system or can be implemented using customized server computers. In some embodiments, thealias indexing module806 may have storage capacity of between 1 and 10 petabytes.
• Thealias profiling module808 stores the information related to all the objects and aliases assigned to those objects. For example, the alias profiling module may include data about a person or an entity as described in relation toFIG. 4 above. Thealias profiling module808 provides this information to thealias indexing module806 in order to enable thealias indexing module806 to create the appropriate links based on the transaction data provided by thedata collection module804. The information in thealias profiling module808 is continually updated based on each transaction involving an alias and/or an object. In some embodiments, thealias profiling module808 can be implemented as a hadoop cluster with over 1 petabytes of storage capacity. In other embodiments, thealias profiling module808 may be part of a cloud computing system. For example, as discussed above, a consumer has been purchasing gas at a particular gas station for the past 4 years. Thedata collection module804 will have transaction information for all the transactions of the consumer at that gas station for the 4 years. Thealias profiling module808, however, will have information indicating that the consumer stays at location A and buys gas at gas station B. Thealias indexing module806 will include information linking the person to the gas station but will not have any information about the person or the has station.
• Thealias caching module810 receives alias information from thealias indexing module806 for delivery to the end-user via thewebserver818. In some embodiments, thealias caching module810 stores some of the reputation and alias profile information available in thealias indexing module806 in memory. In the instance that there is need for near real-time alias and/or reputation information to be provided to a requestor, thealias caching module810 can immediately provide this information without the system having to query thealias indexing module806, thealias profiling module808, or thedata collection module804. In some embodiments, thealias caching module810 includes a large RAM memory that holds the alias information. Thealias caching module810 can include several terabytes to up to 1 petabyte of RAM memory.
• The aliasbatch processing module812 is configured to perform batch processing of tasks related to one or more aliases. In some embodiments, the aliasbatch processing module812 can process operations relating to the various objects/aliases. For example, the aliasbatch processing module812 may perform the ‘update’ function described above for several objects or perform several functions for the same object concurrently. In some embodiments, the aliasbatch processing module812 is coupled to thealias joining module814 and apredictive alias module816. Thealias joining module814 accepts input from the consumer or an external system for operations relation to an object/alias. For example, if a consumer wants to link a camera to his alias, he may fill out a registration form that came with the camera in order to register the camera in his name. In such an instance, thealias joining module814 can receive the registration information either from the consumer or from the external system that accepts the consumer registration, e.g., a manufacturer's website. Thealias joining module814 can collect such information for various aliases and provide that information to the aliasbatch processing module812 for processing. Once processed, this information is sent to thealias profiling module808 for storage.
• Thepredictive alias module816 analyses the information in thealias profiling module808 and communicates data out to various entities. For example, as described above, the system has information about a consumer buying gas at a particular gas station on Friday of every week. Using this information, thepredictive alias module816 can communicate information to the gas station informing them to expect the consumer to buy gas on the following Friday. This information could be sent to the gas station on Thursday along with some other relevant information that may enable the gas station owner to proactively provide some coupon or incentive, e.g., loyalty points, to increase the consumer's chances of buying gas at his gas station on Friday.
• Thewebserver818 can provide an interface to the consumers for requesting alias reputation information. In some embodiments, thewebserver818 can provide near real-time reputation information output to the requestor. In some embodiments, the reputation information can be provided by thewebserver818 using real-time technique or an in-flight technique. In the real-time method, there is direct communication between the requestor and the server providing the information. Several queries may be needed before the desired information is provided to the requestor. In the in-flight technique data is upgraded as it passes through the system without adding any additional delays to the communication time. For example, consider that person A is offering his car for sale on Craig's list and person B is interested in buying that car. In the real-time method, Person B contacts person A to tell him that he would like to see the car. Person A can then search the reputation information about person B to find out whether person B is trustworthy. In contrast, in the in-flight method, person B can communicate with person A via thesystem800 that he would like to see the car. When the message is delivered to person A, it is enhanced with additional information regarding person B such as, his reputation score and any other information that may be relevant for person A to make an informed decision whether to enter into a transaction with person B. Such in-flight data transmission reduces the delay for data delivery. Details of the webserver are described in relation toFIG. 9 below.
• FIG. 9 is a functional block diagram for an alias identity andreputation system900 according to an embodiment of the present invention.
• Block901 represents the alias service architecture that provides the various alias related services and functions described above. The alias service architecture communicates with all other functional units using one or more Internet Protocols in a real-time environment. The alias service architecture comprises a portion ofsystem800 described above. The alias service architecture takes inputs from various functional units and communicates results with one or more functional units.
• Block902 represents the e-mail and SMS enrollment function. In some embodiments, block902 is implemented using a plurality of computer systems that provide e-mail and SMS capability such as, mobile phones, PDA's, and other mobile computing devices. An alias can interact with the alias service architecture via his mobile device. In some embodiments, an entity may enroll an object in or remove an object from his alias hierarchy using his mobile device using, e.g., the various maintenance functions described in relation toFIG. 5.
• Block903 represents enrollment of objects using web-based services. For example, as described above in relation toFIG. 5, an entity may perform maintenance functions on an object via web portal that provides a user interface. The entity can register via the web portal and once registered, the entity can create an alias hierarchy tree by entering information about one or more objects.
• Revocation services block904 relates to auto enrollment and un-enrollment of various devices. In some embodiments, various devices, such as a mobile phone, can to auto enrolled and added to the alias hierarchy of the entity that owns the phone. For example, when a new mobile device is powered up for the first time by a user at his home, the phone may transmit certain data to the alias service identifying the phone and the user. The transmitted data may include GPS location of the phone, a serial number of the phone, a MSISDN number of the phone, among other data. The alias service may use the GPS co-ordinates of the phone to determine an address of the location and determine whether the address is associated with the user. In some embodiments, the alias service may also cross reference the phone serial number with information on the receipt issued when the phone was purchased to verify the purchaser of that phone. Based on such data, the alias service may determine that there is a high likelihood that the person who purchased the phone is the same person who is trying to activate the phone. Based on that, the phone may be auto enrolled in the alias system and linked to user's alias tree. On the other hand, if the phone is lost or stolen, the user may simple report the phone as being lost/stolen and the alias service may automatically remove the phone from the user's alias hierarchy.
• File gateway services905 may be used to request batch file transfers between the alias service and the various systems connected to the alias service. For example, file gateway services may support the Open File Delivery service (OFD) or International File Exchange Server (IFES) implemented by VISA Inc.
• XML/SOAP messages system906 provides a communication method for the alias service to interface with external systems. Specifying the communication protocol for exchanging data with the external systems eliminates the need to support multiple protocols and makes data exchange easier and faster. XML/SOAP messages system906 may be used to communicate directly with third party entities that are not part of the alias system but nonetheless interact with the entities that are part of the alias service. For example,inventory control910 is a service that is provided by most manufactures and distributor of goods and services that an entity may interact with. In some embodiments, the alias service may obtain such inventory data directly from a manufacturer/distributor and cross check that with the data provided by a user to make sure that the information matches. For example, a user may register his mobile device and provide a model number and serial number as part of the registration. The alias service may contact the manufacturer of that mobile phone to determine whether the serial number and model number provided by the user actually exist. This is another way of making sure that the data used to build an entity's alias hierarchy is as accurate as possible.
• Shipping service911 can also send information to the alias service. In some embodiments, the shipping information may be used to determine the destination address of an item. This information may be used to verify that the person enrolling that item is the same person who resides at that location.Tracking service912 provides information relating to tracking of various objects associated with the alias. In some embodiments,tracking service912 andshipping service911 may be provided by the same entity, e.g., FedEx.
• Alias inquiry service907 may be used to query the alias service to get more information about an alias. In some embodiments, an entity may usealias inquiry service907 to determine whether a particular alias exists and get the current status of the alias. For example, prior to conducting a transaction over the Internet, a merchant may usealias inquiry service907 to query the alias service to determine whether the buyer's alias exists and the current status of that alias. Based on that information, the merchant can make a decision on whether to proceed with the transaction. In some embodiments, the current status of the alias may include a risk score of the alias that provides an indication of the trustworthiness of the alias. Thus, in some embodiments,alias inquiry service907 may be used to determine whether a particular alias is trustworthy, e.g., by requesting a reputation score for the alias from the alias service.
• Aliastransparent enrollment service908 provides enrollment and un-enrollment for devices. In some embodiments, the enrollment and un-enrollment of the devices is performed in a manner that is transparent to the user. For example, consider thatdevice1 is enrolled underalias1. Consider thatdevice1 is then sold toalias2. Whenalias2 enrolls the device under his alias hierarchy, the alias service may automaticallyun-enroll device1 from the alias hierarchy ofalias1 without theentity having alias1 having to take any affirmative steps to un-enrolldevice1. In some embodiments, aliastransparent enrollment service908 keeps track of devices/objects as they move from one alias hierarchy to another or also within the same hierarchy and update the association of the objects with the various alias hierarchies.
• Image alias service909 relates to analyzing an image to determine the authenticity of the transaction and providing that information in real-time to a payment processing system as part of the transaction approval process. For example, when a person uses an ATM machine to conduct a transaction, the ATM machine often captures the image of the person. In addition, the ATM can also gather information about the payment device being used. The image of the user, location of the ATM machine, and payment device related information can be sent to the alias service. The alias service may then analyze the image to ensure that the user is the holder of the payment device and the location of the ATM matches the known location of the user at that time. Based on this information, the alias service can determine a probability that the actual owner of the payment device is conducting that transaction. This information may be sent to a payment processing system that is processing that transaction, which can determine whether to proceed with the transaction or not based on the data received from the alias service. Thus, a potential fraudulent withdrawal can be stopped based on analyzing the image of the person attempting to make cash withdrawal. In another embodiment, a person buying a product may be imaged at the POS terminal. The image may include the person, the purchased product, the POS device, etc. This image may be analyzed to determine the alias of the person and the product he just bought. Using this information, the product may be automatically added to the alias hierarchy of that person. In yet another embodiment, an image may be analyzed to determine the metadata associated with the image. The metadata may reveal the location where the picture was taken, the type of camera used to take that picture, etc. Thus, based on the image, the alias service may determine a camera used by the user and add that camera to the person's alias hierarchy.
• It is to be noted that the various services described inFIG. 9 are meant for illustrative purposes only and do not constitute an exhaustive list of services that may be used with the alias service architecture. One skilled in the art will realize that many other services may be similarly used in conjunction with the alias service architecture.
• FIG. 10 is a high level block diagram of a computer system that may be used to implement any of the components of thealias server700 described above and may include one or more of the subsystems or components shown inFIG. 10, which is a block diagram of a computer apparatus. The subsystems shown inFIG. 10 are interconnected via asystem bus1045. Additional subsystems such asprinter1044,keyboard1048, fixeddisk1049, monitor1046, which is coupled todisplay adapter1082, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller1041, can be connected to the computer system by any number of means known in the art, such asserial port1084. For example,serial port1084 orexternal interface1081 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection viasystem bus1045 allowscentral processor1043 to communicate with each subsystem and to control the execution of instructions fromsystem memory1042 or fixeddisk1049, as well as the exchange of information between subsystems. Thesystem memory1042 and/or fixeddisk1049 may embody a computer readable medium.
• Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
• The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
• One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
• A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
• It should be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.

Claims (17)

1. A computer-implemented method for generating reputation information for an alias, wherein the alias is associated with an entity, by a computer system, the method comprising:

receiving payment transaction information related to a first alias associated with a first entity, the payment transaction information including payment transactions performed by the first entity;

receiving non-payment transaction information related to the first alias, the non-payment transactions including transaction between the first alias and one or more objects;

analyzing the payment transaction information and the non-payment transaction information;

associating the one or more objects with the first alias based at least in part on the payment transaction information and the non-payment transaction information; and

generating reputation information for the first alias based at least in part on the payment transaction information and the non-payment transaction information related to the first alias and to the one or more objects.

2. The method ofclaim 1 further comprising:

receiving information about a transaction between a first object and a second object, from among the one or more objects; and

associating the second object with the first object.

3. The method ofclaim 2 wherein the first object and the second object includes a person, a device, or another entity.

4. The method ofclaim 1 further comprising:

monitoring transaction information between the first alias and the one or more objects and updating the associations between the first alias and the one or more objects.

5. The method ofclaim 4 wherein updating the associations include:

severing an association between a first object and the first alias; or

creating an association between a second object and the alias where none existed before.

6. The method ofclaim 1 wherein the payment transaction information is received from a payment processing network.

7. The method ofclaim 1 wherein generating reputation information includes generating a reputation score for the first alias.

8. The method ofclaim 1 further comprising providing risk analysis information for a transaction between the first alias and an object after initiation of the transaction but prior to completion of the transaction.

9. The method ofclaim 1 further comprising:

receiving information about payment transaction and non-payment transaction of a second alias;

analyzing the information about the payment transaction and the non-payment transaction of the second alias to determine whether the second alias is associated with the first entity; and

if it is determined that the second alias is associated with the entity, associating the second alias with the first alias and associating the reputation information of the first alias with the second alias.

10. A system for generating reputation information for an entity, the system comprising:

a data receiving module configured to receive payment transaction information and non-payment transaction information of an alias associated with an entity;

an analysis module configured to analyze the payment transaction information and non-payment transaction information, and associate an object with the alias based at least in part on the payment transaction information and non-payment transaction information, wherein the payment transaction information and non-payment transaction information includes transactions between the alias and the object;

a storage module configured to store the association information between the object and the alias;

a reputation information generation module configured to receive the association information and generate reputation information for the alias based on the payment transaction information and non-payment transaction information; and

a network interface module configured to communicate with one or more external systems to receive the payment transaction information and non-payment transaction information and to send the reputation information.

11. The system ofclaim 10 wherein the non-payment transaction information includes information about data transmission between the alias and an object.

12. The system ofclaim 10 wherein the data receiving module receives the payment transaction information from a payment processing network.

13. The system ofclaim 12 wherein the data receiving module is further configured to periodically receive the payment transaction information between the object and the alias.

14. The system ofclaim 10 wherein the analysis module is further configured to:

determine whether there is a first object that shares payment transaction information and/or non-payment transaction information with a second object, wherein both the first object and the second object are associated with the alias; and

associate the first object with the second object, if it is determined that the first object shares payment transaction information and/or non-payment transaction information with the second object.

15. The system ofclaim 10 wherein the reputation generation module is further configured to:

receive information regarding a request for a transaction between a first object and the alias;

determine a reputation for the first object and the reputation for the alias;

determine a risk score for the transaction between the first object and the alias; and

provide the risk score to the first object and to the alias.

16. The system ofclaim 15 further comprising a payment processing network configured to receive the reputation information of the first object and the reputation information of the alias and determine whether to allow or deny a transaction between the first object and the alias, based at least in part on the reputation information of the first object and the reputation information of the alias.

17. The system ofclaim 10 wherein the object is a person, a device, or another entity.

Images