WO2000063855A1 - Improved system and method for anonymous transactions - Google Patents

Improved system and method for anonymous transactions Download PDF

Info

Publication number
WO2000063855A1
WO2000063855A1 PCT/US2000/010678 US0010678W WO0063855A1 WO 2000063855 A1 WO2000063855 A1 WO 2000063855A1 US 0010678 W US0010678 W US 0010678W WO 0063855 A1 WO0063855 A1 WO 0063855A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
party
identification
card
alias
Prior art date
Application number
PCT/US2000/010678
Other languages
French (fr)
Other versions
WO2000063855A9 (en
Inventor
Peter R. Barton
Original Assignee
Barton Peter R
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Barton Peter R filed Critical Barton Peter R
Priority to AU44763/00A priority Critical patent/AU4476300A/en
Priority to AU12169/01A priority patent/AU1216901A/en
Priority to PCT/US2000/028954 priority patent/WO2001048628A2/en
Publication of WO2000063855A1 publication Critical patent/WO2000063855A1/en
Publication of WO2000063855A9 publication Critical patent/WO2000063855A9/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/24Credit schemes, i.e. "pay after"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403Solvency checks
    • G06Q20/4037Remote solvency checks

Definitions

  • the disclosed invention relates to the field of electronic transactions and particularly to processes and devices for facilitating the anonymous authentication of customer profile information to an authorized requester, and a system and method for protecting the privacy of customers when ordering merchandise by mail by not having to reveal their address to the merchant and/or shipper.
  • information databases are assembled to host a myriad of transactional information. This information, which may be gathered from a number of sources, is stored, categorized and sold.
  • a prime information target is the retail transaction. Membership cards, club cards and credit cards which link a transaction to an individual's database, reveal the purchase, the time of day of the purchase and the retail outlet. This information is then tied to a demographic which is sold to the direct marketing industry. In many cases these databases actually invade a person's privacy and are almost transparent to the unwitting consumer.
  • a credit card company or bank can use the information it acquires in the course of credit or bank card transactions to determine the spending habits of particular customers. The credit card company or bank can then either use that information in its own business or make that information available to others.
  • the consequences of the availability of information about an individual's spending habits range from the annoying to the serious. At a minimum, the individual receives more targeted junk mail than he or she might otherwise; more seriously, the same information that is used to target the individual for junk mail can be used to target the individual for activity which is tantamount to harassment.
  • the disclosed system and method concerns a means by which a service provider or merchant is an information requester authenticating customer related information and/or records which reside in a secure, offline database without revealing the true identity of the customer.
  • a service provider or merchant is an information requester authenticating customer related information and/or records which reside in a secure, offline database without revealing the true identity of the customer.
  • the service provider or authentication requester is able to authenticate the existence of the customer without having the true identity of the customer revealed.
  • the present invention provides an automated, inexpensive system and method for the confirmed request, processing and confirmed transfer of anonymous customer or subscriber related authentication among service providers and/or information requesters.
  • the system is preferably comprised of a software and hardware system to facilitate centralized offline customer identity and business information authentication, while maintaining the anonymity of the customer.
  • This advantageously allows a service provider or information requester to easily and inexpensively authenticate customer related business information without the true identity of the customer being revealed to the service provider.
  • a benefit of the present invention is that the actual transaction is not associated with the true identity or demographics of the customer.
  • Another benefit of the present invention is that a highly efficient method is provided for requesting, processing, and anonymously authenticating customer or subscriber related identification and business information between the service provider or information requester and the secure, central, database repository.
  • this comprises an information hub which includes an interactive server and a database.
  • the database contains a lookup table which blinds the database from the server.
  • the coded or addressed anonymous customer identification confirmation or authentication system of the present invention employs an offline central consumer information database or repository, in communication with service providers or information requesters.
  • the system and method provide for the processing and authentication of requested, specifically identified customer profiles, without identifying the true identity of the customer, and without revealing any business or transaction information to the service provider or information requester.
  • the authenticity of the information requester is verified prior to responding.
  • one feature of the present invention is that there is a blinding or "bunkering" of any attempt by unauthorized information requesters to cross check against a known transaction to match the alias of the customer or subscriber with the true identity of the customer or subscriber.
  • a multiplicity of service providers or information requesters having a system authorization code can electronically request, process and confirm the validity of an anonymous customer's information and/or records.
  • This can be done, for example, from a secure data repository by means of a hardware/software system.
  • the hardware/software system is comprised of an offline database and a central server comprising an information processing hub.
  • the information processing hub communicates with each service provider or information requester via a communication link.
  • a feature of the present invention is that a confirmed authentication of uniquely identified and stored information between an authorized requester and the database repository is triggered by the use of a unique, assigned alias identifier.
  • the requested subscriber or customer records and/or business information are uniquely identified by means of an alias identification of the customer, which can be alphanumeric, digital, analog or the like.
  • the system can authenticate the existence of the customer alias as relating to the true identity of an individual subscriber.
  • authenticated coded triggers are used to release a predetermined portion of the data including, for example, the true identity of the subscriber, to an information requester having authorization for that clearance.
  • the information is encrypted.
  • an alpha numeric code is used to identify files within the uniquely addressed customer information profiles.
  • the system of the present invention confirms requests for authentication to maintain the integrity of the system and the anonymity of the subscriber or customer.
  • the authentication is protected by encryption and a digital signature of the information requester or by use of an authentication code such as a PIN or the like.
  • personal or business records and/or information related to a particular subscriber maintained within the offline database can include at least part of at least one subscriber's profile.
  • subscriber profiles consist of the subscriber's physical address, social security number, credit limits, e- mail address, and the like.
  • a single centralized offline database or repository is provided in communication with a central processing server.
  • the central processing server acts as a "gatekeeper" to maintain the secrecy of the customer's true identity.
  • a plurality of servers communicate with the service providers and in turn with a central server in a multi-tiered system.
  • a computer implemented method for providing authentication to an authorized information requester.
  • the information requester may be provided with authentication of the existence of coded, uniquely identified personal business type records and/or information relating to a particular anonymous subscriber or customer.
  • the records or information are contained in a "blinded" offline database that communicates with each authorized information requester by means of a central processing server.
  • the method may be accomplished by the subscriber information requester initially generating an authorized formatted request for authentication of the uniquely identified records and/or information related to a particular anonymous subscriber or customer using an alias that retains the anonymity of the subscriber or customer.
  • the method also includes transmitting the request to a confirming central processing server with access to an offline database via the communication link. Additionally, the method includes receiving the formatted request, authenticating the authorization of the information requester and confirming receipt of the formatted request by the central system database. The method also includes processing the request of the subscriber or information requester by blinded communication with the database, generating a formatted response in the database authenticating the alias or denying the alias, transmitting the response, and formatting a server response to the service provider or information requester via the communication link.
  • the formatted response to the subscriber or information requester can comprise a denial of the request, an authentication or an authenticated informational compliance. Additionally, the informational compliance can be full or partial.
  • the requester is logged into the central server. For example, if the information requester is not authorized to address the offline database, the identification of the customer or subscriber is blocked and the information requester is denied further communication. In this example, such a formatted response is a denial of authentication.
  • a medium which contains a unique identification that is either anonymous or an alias with respect to the true identity of the subscriber and/or customer.
  • the medium can be in the form of a standard plastic card with a magnetic strip containing the encoded information or alias information or it can be in the form of a smart card that has an encoded chip.
  • an alias I.D. such as a picture I.D., that authenticates the anonymous code for the user.
  • a personal identification number can be used such that the user of the medium would be required to enter a PIN on a keypad or the like, to authenticate the anonymous code.
  • the service provider authenticates the transaction by means of an electronic connection such as telephone wires or the Internet to one or more centrally based processing servers in communication with the offline database as previously described.
  • the medium can be a credit card issued by, for example, American Express, VISA or MasterCard.
  • the service provider requests verification of the anonymous user through a central processing server to an offline database.
  • an authentication code response is sent to the service provider and information located in the look up table, such as the purchase, the purchaser and the amount, is then encrypted and transferred to a credit card provider bank to be posted to the subscriber's account.
  • a "Kid Card” is a credit or debit card that makes limited purchasing power available to children.
  • the transactions performed with the Kid Card are anonymous and the products available for purchase with the Kid Card are subject to parental control.
  • children are guided through the shopping experience by the Web pages supplied by the hosting entity.
  • the transactions performed with the Kid Card are anonymous.
  • a child that purchases an item over the Internet, for example, can use the Kid Card to pay for the item.
  • an alias set of information is used. This alias set of information is compared to an offline secure database that compares the alias information to the true identity data and authenticates the transaction.
  • the true identity of the purchaser is thus never compromised and therefore never available to the processing company for inclusion on a demographic list or the like.
  • the present invention provides a means for consumers to order merchandise via telephone, the Internet, or any other means, to be shipped to their business or residence, without having to reveal their true address to the shipper and/or merchant.
  • This is accomplished by re-labeling the packages with the true address of the consumer sometime after the packages are shipped by the merchant. As described in detail below, this is preferably accomplished in combination of the anonymous transaction system, using one of at least two possible methods.
  • the first method involves shipping the packages to a temporary location where the true address is re-labeled on behalf of the consumer using information from the offline database.
  • this is accomplished by having the shipping company re-label the packages while in transit by communicating through a secure network connection to the offline-database.
  • the offline database In response to a valid authorization request, the offline database returns the true address to the shipper.
  • this process is automated and is implemented using wireless technology while the package is in transit.
  • Figure 1 is an example of a schematic view of an information flow model that can be used in accordance one embodiment of the present invention.
  • Figure 2 is an example of a schematic view of an information flow model that can be used with one embodiment of the present invention having a central processing server and an offline database.
  • Figure 3 is a block diagram depicting one example of a method that can be used to create a new account.
  • Figure 4 depicts an example of a process that can be used to book a Primary account from part 1 of the application in accordance with one embodiment of the present invention.
  • Figure 5 depicts an example of a process that can be used to process part 2 of the application in accordance with one embodiment of the present invention.
  • Figure 6A depicts an example of bunker operations for application processing in accordance with one embodiment of the present invention.
  • Figure 6B depicts one example embodiment of an acquisition process in accordance with one embodiment of the present invention.
  • Figure 6C depicts an example application process that can be used in one embodiment of the present invention.
  • Figure 7 depicts an example of a method that can be used to establish an Alias account as an extension of an existing account.
  • Figure 8A is an example of a method that can be used to perform maintenance in accordance with one embodiment of the present invention.
  • Figure 8B is an example of some account management and maintenance tasks in accordance with one embodiment of the present invention.
  • Figure 8C is an example of a collection method that can be used in accordance with one embodiment of the present invention.
  • Figure 9A depicts a process that can be used to replace the alias name and address with the real name and address before the statement is printed in accordance with one embodiment of the present invention.
  • Figure 9B depicts an example of a statement process that can be used in accordance with one embodiment of the present invention.
  • Figure 9C depicts one example of a plastics process that can be used to emboss alias credit cards in accordance with one embodiment of the present invention.
  • Figure 10 depicts a method that can be used for payment of the Alias account in accordance with one embodiment of the present invention.
  • Figure 11A is an example that depicts one method that can be used by the bunker to support mail redirection in accordance with one embodiment of the present invention.
  • Figure 11B is one example of a method that can be used for mail redirection from both the host and bunker perspective in accordance with one embodiment of the present invention.
  • Figure 12 depicts an example process flow which shows the type of information flowing in and out of the Bunker receiving point, the Host and the Bunker in accordance with one embodiment of the present invention.
  • Figure 13 is an example of database tables that can be used to implement the bunker database in accordance with one embodiment of the present invention.
  • Figure 14 is a schematic diagram that depicts one embodiment of the disguised mailing feature in accordance with one embodiment of the present invention.
  • Figure 15 is a flowchart depicting methods that can be used to implement the disguised mailing feature in accordance with an embodiment of the present invention.
  • Figure 16 is a flowchart depicting methods that can be used to implement the disguised mailing feature in accordance with an embodiment of the present invention.
  • an information hub housing a central server receives a request for authentication from a service provider or information requester.
  • the central server verifies that the service provider or information requester is authorized to obtain authentication for the transaction or the requested information from the database. For example, upon verification of the validity of the request, the central server queries the database for authentication of the anonymous customer.
  • the database contains, for example, a lookup table that links the anonymous identification of the medium card holder, for example, a credit card holder, to the true identity of the card holder.
  • the lookup table functions a barrier between the system traffic and the stored identity information.
  • a verification response is generated by the central server to authenticate the transaction. This could be used, for example, with telephone cards, frequent flyer club cards, grocery store cards and the like.
  • a “Subscriber” is an entity who subscribes to a transaction based service and whose data is in the offline database.
  • a "Service Provider or Information Requester” is an entity with which the particular Subscriber is consummating a transaction. Service Providers could be, for example, local retailers, banks, travel agencies and the like.
  • Subscriber D is an alias system identifier that can be used as an alias or a code to uniquely identify a particular Subscriber and its records.
  • Subscriber Profile or “Service Profile” means customer-related business information and/or records such as a particular Subscriber's financial information, or address.
  • Subscriber Related Business Information Request is a request from a Service Provider for authentication of all or part of a particular Subscriber Profile or Service Profile.
  • the Profile preferably contains readable system code allowing the system to verify the requester is on the system.
  • a "Subscriber Related Business Information Request Response” is a response to a Subscriber Related Business Information Request.
  • the Response could be a listing of all or part of a particular Service Profile, an authentication of a Subscriber's identity, or a denial of such information.
  • the Response is encrypted.
  • a Subscriber Related Business Information Request Response can also include a 'Transaction Authorization" or "Confirmation Request” such as used in the credit card industry.
  • the alias method and system 20 comprises a number of Service Providers or Information Requesters 21, each communicating with a system server/database 22 by means of a pre-existing communication link 23, such as the public telephone system.
  • the system server/database 22 can be a centralized information hub, having a pre-existing communication link 23 for the purposes of receiving, authenticating and transmitting information to Service Providers 21.
  • the central information hub may comprise more than one physical element.
  • a multi-tiered server system (not shown) may be practical in some applications.
  • the communications link 23 may alternatively be a private leased line, a local area network, cable TV network, or the Internet.
  • the system server/database 22 comprises a server and an offline database as more fully described below in relation to FIG. 2.
  • a Subscriber Profile data and/or authentication is relayed to a requesting Service Provider 21 through a system server/database 22, in computer accessible code, via a communications link 23.
  • the information flow is virtually instantaneous, and the response information puts the necessary information in the hands of the Service Provider or Information Requester 21. This information is preferably delivered in a usable form, expediting the transaction.
  • HG. 2 there is shown an example of an information flow diagram that can be used in of one aspect of the inventive alias method and system 20.
  • the transfer of a Subscriber's authentication or Subscriber Profile information between the Service Provider or Information Requester and the offline centralized database is shown.
  • the system server is accessible to all Service Providers 21.
  • the Service Providers 21 can access the System Server 22 by merely addressing the alias customer information profile by means of the Service Provider's identification through the communication link.
  • the example system 20 comprises an authorized Service Provider 24, a System Server 26, an offline database 28, and an interconnecting communications link 30.
  • the communications link 30 connects the Service Provider 24 and database 28 with the server 26.
  • the diagram in FIG. 2 schematically represents an example of the data flow within the system 20.
  • the processes represent execution steps for creating, transferring and confirming information between Service Provider 24, server 26, and offline database 28.
  • this communication takes place by means of communications link 30.
  • Service Provider or Information Requester 24 by means of unit process 33, generates a Subscriber Related Business Information Request 32.
  • the request is generated in a specified format and includes an informational header.
  • This header includes, for example, the Subscriber's alias, PIN or other anonymous inquiry keys and information.
  • the header may include address information and a formatted message portion comprised of, for example, the date, time, and amount of the transaction.
  • the data used to generate the Subscriber Related Business Information Request 32 can be provided in more than one way.
  • a first example of a method for creating the Subscriber Related Business Information Request 32 is by using an application Graphical User Interface, preferably written in Java.
  • the Graphical User Interface provides the user with input fields for all elements of the Subscriber Related Business Information Request 32, including input fields for the Service Provider 24.
  • the Graphical User Interface can perform input validations, convert the input data into a binary stream using Java serialization, and store the document.
  • the document can be stored in binary object form in the Service Provider or Information Requester's 24 relational database.
  • a second example of a method for creating the Subscriber Related Business Information Request 32 is through the use of the Client Integration Subsystem.
  • the Client Integration Subsystem is a configurable set of services and infrastructure. These services can be written, for example, in the C++ and Java programming languages. Furthermore, the services can, for example, allow an organization to "plug-in" their existing systems to automatically generate Subscriber Related Business Information Request 32. For example, the Request 32 could seek the coded information in a credit card transaction that authorizes a merchant's request and identifies the return path.
  • the resulting document is stored in the Service Provider or Information Requester's 24 relational database coupled with additional document information.
  • additional document information could include date and time stamps, document state information, creating user identification, and the like.
  • this information could be linked to a particular Subscriber Related Business Information Request 32 and simultaneously stored along with the Subscriber Related Business Information Request 32.
  • the date and time stamps are used to determine whether the request is sent and received within the industry allotted time period. This, for example, would prevent hacking through the use of different requester locations attempting to obtain client Subscriber Related Business Information in the offline database 28.
  • the user identification information is preferably used by the System Server 26 and the offline database 28 to help verify the validity of the Subscriber Related Business Information Request 32. This can be done, for example, by determining that the Subscriber Related Business Information Request 32 was sent by an authorized Service Provider or information Requester 24.
  • Subscriber Related Business Information Request 32 is completed by entering the necessary data, it is marked as ready to be sent. Conversely, if the Subscriber Related Business Information Request 32 is not completed, for example, due to missing data, it is marked for review and stored until the Subscriber Related Business Information Request 32 data is entered into the Subscriber Related Business Information Request 32. Preferably, this prevents overriding the system by not having a complete request. This is important, for example, when service information provider or information requesters 24 are given security codes allowing access to differing information and/or levels of information.
  • the Subscriber Related Business Information Request 32 is prepared to be sent to the System Server 26 by means of unit process 34 via communications link 30.
  • An example of the aspects of unit process 34 include application of the digital signature, data encryption, alias and attaching the routing information.
  • the Subscriber Related Business Information Request 32 carrying the alias identifier is encrypted by an encrypting service.
  • the encrypting service utilizes Pretty Good Privacy encryption with a private key based on the system server's 26 public key.
  • an online service can be used or alternatively, the software can be downloaded from www.MIT.edu. for inclusion in process 34.
  • the document is digitally signed using the Service Provider's 24 private key. Preferably, this private key has been previously configured by the system administrator.
  • the Subscriber Related Business Information Request 32 is sent to the server 26 using communication link 30.
  • Various systems can be used to connect the Service Provider or Information Requester 24 to the System Server 26.
  • the message can be sent either via X400 protocol or using a virtual private network protocol.
  • the choice is based on the configuration implemented by the generating entity's system administrator, based on system requirements for response times and cost of implementation.
  • a lookup of the server 26 destination address in the Service Provider or Information Requester's 24 database is performed.
  • the process 34 appends the appropriate routing information for the transmission type used by the generating entity system.
  • a fully qualified Internet address is an example of appropriate routing information.
  • the data is preferably sent over an existing communication system such as the Internet or a Virtual Private Network.
  • the Subscriber Related Business Information Request 32 is received by server 26 from Service Provider or Information Requester 24.
  • this can be accomplished by means of unit process 36 via communications link 30.
  • the system is activated by data being received.
  • unit process 36 includes steps for receiving the message, authenticating the signature on the message and responding to the sender if the signature is valid.
  • the server 26 upon receipt of a Subscriber Related Business Information Request 32, the server 26 first logs the receipt and then authenticates the digital signature.
  • an interim file representation of the document is created, after extracting the document from the transport mechanism and stripping off header information. The file is then stored in a system-defined, file system directory.
  • the document digital signature is verified using the Pretty Good Privacy signature authentication service based on the sender's public key, which is retrieved via the previously configured information in the Pretty Good Privacy security database.
  • the Subscriber Related Business Information Request 32 is decrypted using the Pretty Good Privacy decryption software and stored.
  • a verification of receipt message 38 (shown in dotted lines) is sent back to Service Provider or Information Requester 24 via the communication link 30.
  • the Service Provider or Information Requester 24 verifies the sender as the System Server 26.
  • the Subscriber Related Business Information Request 32 is based on several criteria. Preferably, if the Subscriber Related Business Information Request 32 is not authentic, the Request 32 is not honored. For example, in one embodiment, the invalid Request 32 is first returned to the Service Provider or Information Requester 24 via the Communications Link 30. Then, a message is sent noting the receipt of an invalid Subscriber Related Business Information Request 32.. Furthermore, receipt of the invalid Subscriber Related Business Information Request 32 is logged by the System Server 26. Preferably, the address of the invalid Service Provider or Information Requester 24 is "blocked" from the system 20 and the information pertaining to the unauthorized Service Provider or Requester 24 is maintained in the system 20 for future reference.
  • valid Subscriber Related Business Information Requests 32 received by the System Server 26, are processed in accordance with unit process 40.
  • the processing includes decrypting the message and preparing the message for forwarding to the offline database 28.
  • a message header is appended to the message and a document timer is activated to track the time until the System Server 26 receives a request response from the offline database 28.
  • the System Server 26 preferably records receipt of the Subscriber Related Business Information Request 32 into the System Server's 26 relational database.
  • the Subscriber Related Business Information Request 32 is marked as received by the System Server 26.
  • the Server 26 can also be configured to execute certain user defined operations which are triggered during this processing depending upon the nature of the Subscriber Related Business Information Request 32 as further described below. For example, if the request is a credit card transaction, certain information may be forwarded to the issuing bank after database manipulation as further described below.
  • the document file is read in by the Server's 26 document handier, decrypted, and the document is then stored in the Server 26.
  • a document handler rules engine is used to process the document in accordance with unit process 40.
  • a rules agenda is created based on the contents of the document.
  • the rules engine matches patterns in the rules conditions with the document and executes actions associated with the conditions. Examples of actions include updating database tables, modifying/transforming the document header information, and adding additional/alternative document routing instructions.
  • a timer is activated by storing a new record with Subscriber Related Business Information Request 32 information in the timer table.
  • subscriber Related Business Information Requests 32 is ready to be forwarded to offline database 28 by means of unit process 42 via communication link 30.
  • An example embodiment of unit process 42 includes the steps of encrypting the message, digitally signing the message, and sending the message to the offline database 28.
  • the functions required to prepare a document for forwarding are based on the type of Service Provider 24 from which the Subscriber Related Business information Request 32 is received. For example, if offline database 28 has authority and access to the data required to respond to the Subscriber Related Business Information Requests 32, it can create a Subscriber Related Business Information Request Response.
  • the offline database 28 receives, logs, and authenticates the Subscriber Related Business Information Request 32. For example, in unit process 44, the offline database 28 receives the message, the signature on the message is authenticated and a response is sent to the System Server 26 if the signature is valid. In this manner only the Server 26 can access the offline database 28.
  • process 44 creates an interim file representation of the document after extracting the document from the transport mechanism and stripping off header information.
  • the priority code is interpreted so that the appropriate information from the lookup table can be retrieved.
  • the Subscriber Related Business information Request 32 is stored and the appropriate customer related information is coupled with the document header.
  • the file is stored in a system-defined file system directory.
  • the digital signature is verified using the Pretty Good Privacy signature authentication service based on the sender's public key, which is retrieved via previously configured information in the Pretty Good Privacy security database. If the signature is authentic, the document is decrypted using the Pretty Good Privacy decryption software based on the server's private key data.
  • the header information is separated from the Subscriber Related Business Information Request 32 and the Subscriber Related Business Information Request document 32 is stored.
  • a message 38 (shown in phantom) acknowledging the receipt of the Subscriber Related Business Information Request 32 is then sent by the offline database 28 to the Server 26 via communications link 30.
  • Erroneous Subscriber Related Business Information Request 32 receipts are logged and the Server 26 is notified via message 38. In this manner only requests from server 26 are accepted for processing.
  • the Subscriber Related Business Information Request 32 is processed as set out above in unit process 44 by offline database 28 it is processed in accordance with unit process 46.
  • An example of the method steps within unit process 46 includes: the Subscriber Related Business Information Request 32 is decrypted, the document is stored into the offline database 28 and the Subscriber Related Business Information Request Response 47 is created.
  • the offline database 28 formats the data into a document message and the offline database 28 appends reader information such as routing and document type to the message.
  • the subscriber Related Business Information Request 32 is stored in the offline database 28.
  • the Offline Database 28 responds.
  • the Offline Database 28 sends a Subscriber Related Business Information Request Response 47 back to the Service Provider or Information Requester 24 through the System Server 26 via communications link 30.
  • the Subscriber Related Business Information Request Response 47 is generated in accordance with unit process 46.
  • the Subscriber Related Business Information Request Response 47 is prepared using an application Graphical User Interface preferably written in Java.
  • the Graphical User Interface for example, provides the user with input fields for all elements of the Subscriber Related Business Information Request Response 47, including input fields for the Service Provider or Information Requester 24.
  • the Graphical User Interface performs input validations, converts the input data into a binary stream using Java serialization, and stores the document in binary object form into the offline database's 28 relational database.
  • the document is stored into the offline database's 28 relational database.
  • the document may be stored with additional document information such as date and time stamps, document state information, creating user identification and the like which are linked to a particular Subscriber Related Business Information Request Response 47.
  • the document state information is used by the system to determine whether the Subscriber Related Business Information Request Response 47 is ready to be transferred to the System Server 26.
  • the user identification information is used by the System Server 26 to help verify the validity of the Subscriber Related Business Information Request Response 47 by determining that the Subscriber Related Business Information Request Response 47 was sent by offline database 28 or an entity having access to the subscriber information and authority to disseminate authentication or information.
  • the Subscriber Related Business Information Request Response 47 when the Subscriber Related Business Information Request Response 47 is completed by entering the necessary data, it is marked as ready to be sent. Conversely, if the Subscriber Related Business Information Request Response 47 is not completed due to missing data, it is marked for review and stored until the Subscriber Related Business Information Request Response 47 data is entered into the Subscriber Related Business Information Request Response 47. Preferably, a message is sent to the Server 26 requesting additional information be placed in the database 28 to fill the request.
  • Subscriber Related Business Information Requests Response 47 After Subscriber Related Business Information Requests Response 47, has been processed, it is ready to be forwarded to System Server 26 by means of unit process 48 via communication link 30.
  • Subscriber Related Business Information Requests Response 47 is encrypted, digitally signed, and sent to the Server 26.
  • the Subscriber Related Business Information Request Response 47 is preferably stored in the relational database coupled with additional information such as date and time stamps, and user identification.
  • the Subscriber Related Business Information Request Response 47 is received by the System Server 26, it is handled in accordance with unit process 50.
  • the system server receives the Subscriber Related Business Information Requests Response 47
  • the signature on the Subscriber Related Business Information Requests Response 47 is authenticated, and a response 38 is sent to the offline database 28 if the signature is valid.
  • the Subscriber Related Business Information Request Response 47 is acknowledged by message 38 to the offline database 28 via link 30 and its receipt is logged.
  • the Subscriber Related Business Information Request Response 47 is processed by Server 26. An example of this processing includes authentication of the Subscriber Related Business Information Request Response 47 and validation of the intended Service Provider 24 address. Additionally, the receipt event is logged.
  • the document is decrypted as above described and checked against existing Subscriber Related Business Information Request 32 for a match.
  • Subscriber Related Business Information Request Response 47 match errors and destination errors are logged and notifications sent back to the offline database 28.
  • the respective unit process 50 creates an interim file representation of the document after extracting the document from the transport mechanism and stripping off header information.
  • the file is stored in a system-defined file system directory.
  • the document digital signature is then verified using signature authentication service based on the sender's key.
  • an acknowledgment message 38 is created and sent back to the Offline Database 28 via the same communication mechanism that the document was received.
  • the converted response is stored in the server's 26 persistent storage mechanism.
  • Subscriber Related Business Information Request Response 47 response is received by Server 26, it is processed as shown by unit process 52.
  • processing includes storing the document, logging its receipt and managing the timers associated with the original request.
  • Subscriber Related Business Information Requests Response 47 is decrypted, an ID is matched against the initial request sent, the message is stored into the System Server 26 database, the document timer is deactivated, the Subscriber Related Business Information Requests Response 47 is prepared for forwarding to the requesting Service Provider 24 and a message header for sending Subscriber Related Business Information Requests Response 47 to the requesting Service Provider 24 is appended.
  • the Subscriber Related Business Information Request Response 47 receipt is logged and the document state is set to "complete.” Such a setting indicates that the Subscriber Related Business Information Request Response 47 is ready, for example, to be encrypted, signed, and forwarded to the Service Provider or Information Requester 24, as represented by unit process 54..
  • the document file is read in by the Server's 26 document handler process and the document is then stored in the Server 26.
  • the Document Handler Rules Engine is then activated to process the document.
  • a rules agenda is created based on the contents of the document.
  • the rules engine matches patterns in the rules conditions with the document and executes actions associated with the conditions.
  • the rules match the Subscriber Related Business Information Request Response 47 by document identifier information with the Subscriber Related Business Information Request 32.
  • the system timer that was created when the document was originally received by the server 24 is deleted from the server timer table.
  • the destination for the Subscriber Related Business Information Request Response 47 is validated and any erroneous Subscriber Related Business Information Request Responses 47 are logged.
  • the Document Handler process modifies the Subscriber Related Business Information Request Response 47 header information for document transmission status and stores the information to the database.
  • the Subscriber Related Business Information Requests Response 47 is sent to the Service Provider 24 using the communication link 30 in accordance with unit process 54.
  • the Subscriber Related Business Information Requests Response 47 is encrypted, digitally signed, and then sent to the Service Provider 24.
  • the system appends the appropriate routing information for the transmission type used by the Service Provider 24.
  • acknowledgment of receipt is received via 38 and logged.
  • match and destination error notifications are received and logged, corrections are made and the response re-sent if necessary. Receipt of the Response to the Subscriber Information Request by Service
  • the Service Provider or Information Requester 24 upon receipt of the Subscriber Related Business Information Request Response 47, the Service Provider or Information Requester 24 authenticates the System Server 26 as the sender and logs the receipt of the Subscriber Related Business Information Request Response 47 in accordance with unit process 56. For example, within unit process 56, Subscriber Related Business Information Request Response 47 is received, the digital signature is authenticated, and a response 38 is sent to the System Server 26 if the signature is valid. Additionally, the digital signature is verified and the Subscriber Related Business Information Request Response 47 is matched against the Subscriber Related Business Information Request 32. Preferably, the Subscriber Related Business Information Request Response 47 is processed in a manner similar to unit process 46 in accordance with unit process 58.
  • the Service Provider or Information Requester 24 processes the Subscriber Related Business Information Request Response 47 in unit process 58.
  • Subscriber Related Business Information Request Response 47 is decrypted and matched to the Subscriber Related Business Information Requests 32 stored in the requesting Service Provider's 24 database.
  • the document status is set to complete or rejected depending on the response data sent in the Subscriber Related Business Information Requests Response 47 by the offline database 28.
  • the completion of this step is the termination of the process.
  • a log entry is made into the system server database recording information about the document reception process.
  • the document state is set to complete by the document processor of Server 26 by updating the document header in the database.
  • a trigger is fired to perform a system defined service upon document completion. Triggers, for example, can perform actions such as sending a user-defined message to a socket, storing data in another database, performing communications and the like. In this manner transaction data can preferably be sent to, for example, an issuing bank.
  • system server/offline database architecture consists of six subsystems: process control subsystem, communication subsystem, document processing subsystem, security subsystem, user interface subsystem and a data handling and storage subsystem.
  • a descriptive example of the process control subsystem includes a system that invokes and controls the other custom and commercial software that make up the system server.
  • This subsystem is able to automatically restart erroneously terminated processes and logs such terminations for later analysis.
  • users are able to configure the process control subsystem to take additional actions when a process terminates.
  • An example of the communication subsystem is further comprised of an X400 agent and/or virtual private network communication agent.
  • this subsystem uses either agent to send documents out of the system server to external recipients, and relies on a fully qualified Internet address for routing.
  • the communication subsystem's message receiving functions include determining how to route a message to its recipient, and accepting and transferring mail from and to intermediate agents. Additionally, address interpretation and transformation into a compatible format is handled by the communication subsystem.
  • the communication subsystem also implements special actions indicated by the message header such as verifying delivery. For example, when message delivery cannot be done, the communication subsystem queues messages, or reroutes documents with erroneous addresses, as required.
  • the communication subsystem determines the recipient's pre-existing public communication system host, then initiates a transfer protocol session with the host. Preferably, an unsuccessfully transferred message is queued for later delivery.
  • the communication subsystem receives and processes all incoming document transfer protocol sessions from client systems. For example, outbound documents are packaged and sent to the communication agent for processing. Additionally, the communication subsystem automatically processes received messages by first authenticating, then decrypting, and then sending the message to the document processing subsystem. In one embodiment, the communication subsystem places a time stamp on each message that when compared with the message status indicates when a message has not been successfully delivered. Unsuccessfully sent messages are preferably resent a predetermined number of times according to preset communications subsystem parameters.
  • the document processing subsystem processes all messages received into the System Server 26.
  • this subsystem can be responsible for message parsing, message storage, Subscriber Related Business Information Request processing, Subscriber Related Business Information Request Response processing, message routing and message timers.
  • messages are processed in the order in which they are received and deleted after successful processing.
  • a message is logged into the activity log upon reception and then parsed.
  • the message parser divides the message into two parts: header and message data.
  • Message type information contained in the header determines which type of action the system server should take with the message data.
  • the message data is stored.
  • the message data is stored according to message type and the message header is logged.
  • a Subscriber Related Business Information Request is stored in a Subscriber Related Business Information Request table
  • a Subscriber Related Business Information Request Response is stored in a Subscriber Related Business Information Request Response table.
  • table entries are crossed referenced, and transmission verification messages and the status of the corresponding message are logged.
  • the Subscriber after the message is stored, the Subscriber
  • Subscriber Related Business Information Request 32 is processed. For example, the first step in processing a Subscriber Related Business Information Request 32 is to log the event. Then the name of the service provider 24 is extracted and the service provider's address is obtained from a lookup table. The Subscriber Related Business Information Request 32 is then sent to the offline database 28. Preferably, the Subscriber Related Business Information Request 32 is marked as sent when a return receipt is received. In alternative embodiments, Subscriber Related Business Information Requests 32 can be in any of four states based on responses from the offline database 28: pending, sending, inactive, or completed.
  • the Subscriber Related Business Information Request 47 is processed and sent to the service provider, the Subscriber Related Business Information Request Response 47 is processed after it is received from the service provider. For example, when a Subscriber Related Business information Request Response 47 is received by the document processing subsystem, the corresponding Subscriber Related Business Information Request identification number is located and the Subscriber Related Business Information Request status is checked. The Subscriber Related Business Information Request Response 47 is marked as invalid if the Subscriber Related Business Information Request 47 is not pending. Preferably, Document status is updated when the Subscriber Related Business Information Request Response 47 is processed, forwarded to the requesting Service Provider or Information Requester 24 and stored into the system.
  • a message's time in the document processing system is tracked by a timer.
  • default events are set to occur at pre- set times.
  • such default events include setting a message's status to a certain value if no response has been received or to send the message again if no return receipt is received.
  • the security subsystem primarily secures four areas: system data and file access, the relational database, the system administrative user interfaces and data and messages.
  • system data and file access to the offline database 28 is protected by a user identification string that allows access to only the owner.
  • access to the relational database is controlled through a data owner's user identification string and password, and no access privileges are granted to any other user.
  • the system administration user interfaces and data are protected by another set of user identification numbers and passwords.
  • users can not gain access to the system administration user interfaces and data through other databases.
  • messages are secured by encryption and a digital signature.
  • commercial security software does the encrypting and decrypting, message authentication, and digital signature verification.
  • Software specifically designed to secure document transmissions using Public Key Cryptography is preferred.
  • Public Keys can be manually transferred between system/client administrators via e-mail or disk/tape.
  • key transfers are authenticated by verifying the digital signature of the sent document.
  • all messages preferably receive a digital signature based on the private key of the sending system. For example, upon receipt, the digital signature of a message is automatically verified. Messages that fail digital signature verification are not processed, but rather are stored and the failure noted in the automated activity log. Preferably, the sender is not notified when a message fails verification. This, for example, is to prevent attacks from hostile systems.
  • the user interface subsystem allows a system administrator to add or delete service providers, add or update message routing information and monitor system activity.
  • the interface is accessed through Java software applets which can be executed within a web browser, such as
  • offline database system data is stored in the commercial relational database.
  • the offline database system uses a database access and storage facility implemented using embedded structured query language in the user application processes and Java Database Connectivity.
  • the Unix file system can be used to store system data.
  • aliases or codes such as personal identification numbers, and the like can be used in association with the medium to reduce risk of unauthorized use of the medium.
  • security codes may be issued to the Subscriber such that one or more of the security codes must be used depending on the magnitude of the transaction.
  • plastic cards are an easy medium in which to embed alias identification
  • alternative embodiments may employ other mediums such as electronic transfer medium, smart cards, chips, and the like.
  • any medium can be used in accordance with this invention. For example, codes on keypads and even fingerprints would be acceptable identification to trigger the system.
  • An offline database also referred to as a "processing bunker" allows for two separate accounts to be established for an individual.
  • the bunker is the only place that contains information that associates an account used for establishing a line of credit to the alias account used to protect the identity of the cardholder.
  • Primary account the account applied for that has all the accurate information about the cardholder and is used to establish a line of credit.
  • Shadow account or Alias account an account that uses an alias name and alias address to protect the anonymity of the cardholder. It is preferably attached to a Primary account through the bunker. In the examples and some of the Figures presented herein, this account is also referred to as a "Casper" account.
  • Normal Account a standard credit-card account that has nothing to do with the Primary and Shadow accounts of the present invention.
  • Bunker The process that supports linking of the Primary and Shadow accounts together.
  • the bunker may be in a separate facility, or in an existing data center depending on the amount of separation desired in each specific implementation of the present invention.
  • an existing credit card processing system is also referred to as "FDR".
  • the bunker is preferably constructed to provide a standalone source for synchronizing information between the Primary account and the Shadow account. It also provides services for properly addressing communications to the cardholder. These functions are preferably driven from a database containing information on both accounts. In one embodiment, the bunker has no public network connections outside of the building. In this fashion, the present invention provides an extremely secure environment for the matching information.
  • This example embodiment can be used with existing credit-card processing models with minimal intrusion.
  • the remainder of this example describes the bunker functionality and its interaction with a typical existing credit-card processing model.
  • a new product is provided that protects the identity of the cardholder. It allows the establishment of a line of credit that is split across two accounts.
  • the two accounts are referred to as the Primary account and the Shadow account.
  • the Primary account is the account booked using factual information provided on an application.
  • the Shadow account is the account booked using information from the Primary account with an Alias name and address.
  • the Primary account is a standard credit account that can be used like a traditional credit card.
  • the credit line for the card is established as some portion of the credit line approved during application processing. The remaining portion is assigned to the Alias card.
  • two cards are used because of possible restrictions that may be placed upon the use of the Alias card.
  • the Alias card may be restricted in places where proof of ID is required, such as for hotel, airline and rental car reservations.
  • the acquisition of Shadow accounts can be accomplished in two ways.
  • the first is through new account solicitation.
  • For a new account a new application is completed and a new credit card account and an Alias account is created.
  • the second way relates to associating an Alias card account with an existing credit card account already on file. The following example describes both of these scenarios.
  • FIG. 3 is a block diagram depicting one example of a method that can be used to create a new account.
  • a new account acquisition is accomplished using a two-part application 60.
  • Both parts 62 and 64 of the application 60 have a document tracking number (shown as "123" in Figure 3).
  • the document tracking number is used in this example embodiment to construct a relationship between the Primary credit card account and the Shadow account.
  • the document tracking number is unique.
  • Each part of the application 62 and 64 is sent to a different destination as shown by Figure 3.
  • part 1 of the application 62 is mailed to the issuer's application processor.
  • Part 2 of the application 64 is mailed to a receiving point for the bunker.
  • each of the application parts 62 and 64 has only the document tracking number ("123") in common. This number is used in the bunker to create the relationship between the Primary account and the Shadow account.
  • the document tracking number is captured in a master file when the application is processed. In this fashion, the document tracking number can be passed to the bunker after the account is booked.
  • bunker receiving is not in the bunker location itself, but in a location where part 2 of the application is actually received and the Alias name and document tracking number is captured for input into the bunker.
  • key points for protecting the anonymity of the account holder include sending part 1 of the application 62 to a different location than part 2 of the application 64, and the only common information between all parts is the document tracking number on the application 60.
  • rules for processing the application 60 follow the issuer's standard process. Such a process may already be in existence for processing normal credit-card accounts and the like. For example, credit bureau reports are requested and the account is scored to determine eligibility. Preferably, the only special requirements are that the credit line being established is split between the two accounts, the Primary and the Shadow account, and the capturing of the document tracking number from the application so that it can be later passed to the bunker for matching with the Alias.
  • Figure 4 depicts an example of a process that can be used to book a Primary account from part 1 of the application 62.
  • part 1 of the application 62 is mailed from the cardholder.
  • a data entry terminal 72 is used to enter the information from the application 62 into a computer system, such as the IBM mainframe 74 shown in Figure 4. If the application is not approved, standard rejection letters are typically sent back to the applicant. However, if the application is approved, it will be booked.
  • Information related to the new Primary account is then stored in the account file 76. This information includes the actual name and address of the cardholder but does not include the alias information.
  • Figure 5 depicts an example of a process that can be used to process part 2 of the application 64 in accordance with one embodiment of the present invention.
  • Part 2 of the application 64 is handled separately from part 1. This part 64 is used to assign an alias name to the Shadow account when it is built.
  • Part 2 of the application 64 contains the alias name and the document tracking number that matches the number on part 1 of the application 62.
  • a data entry operator using a data entry application on a personal computer (PC) or the like 80 captures the information.
  • the application on the PC 80 creates a file that is stored on removable media 82 and transferred on a daily or other periodic basis to the bunker.
  • FIG. 6A An example of bunker operations for application processing is shown in figure 6A.
  • the bunker receives a file 82 comprising part 2 alias information as described above. This information is used as input to a matching database process or application program 88.
  • Alias information is posted to the data store 90 using the document tracking number. If the document tracking number is already on file, a check is made to determine if the alias information has already been posted. If it has not, then a new account record is created and added to a file that is sent to the host (not shown) for posting. If the alias information has already been posed, then an error is reported.
  • the above-described process takes information for a cycle and uses it to create input for the next cycle. That is, if an account is approved before the day's cycle kicks off, the new account is created during the night cycle and the information for the bunker is extracted from files created during that cycle. The file will then be hand-carried to the bunker for processing. This input to the bunker is then processed and the new Alias accounts and other account updates are loaded into files that will be transferred by hand back to the account processing facility for the next night's cycle.
  • FIG. 6B Details of one example embodiment of an acquisition process is shown in Figure 6B. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s). IT is noted that in these example, the Shadow and/or Alias account is also referred to as the "Casper" Account. These details expand on the principles described above and provide a specific implementation of one example embodiment. It should be noted that these details are for exemplary purposes only and should not be construed to limit the scope and breadth of the present invention, which could be implemented using alternative means.
  • the credit line has to be increased and/or split to accommodate both the cards on approval.
  • the host will receive non-mon (non- monetary transaction) from the bunker for updating the credit line of the primary account. Also the output is merged with that of the Casper specific output.
  • An example of a process including typical inputs and outputs that can be used to match the Primary and Alias accounts for acquisition is as follows
  • Figure 6C depicts an application process as described above for a specific example embodiment. It is noted that in Figure 6C, a three part application is referenced rather than a two part application as described above. However, the third part of the example application is merely a record for the application card-holder in this example. It should be noted that in a preferred embodiment, at least a two part application is used as described in detail above with respect to Figures 3-5.
  • This Account File will is written to tape or other removable media that is to be sent to the bunker. Proper formatting of the data is typically required. This is actually a non-mon sent to the bunker from the host.
  • Bunker updates its database using the Account File 76 and generates an Alias Account File that is sent to the host through a tape or other removable media. These records will be posted in the next day's Cycle as a new Account Processing Facility. This is a non-mon from the bunker to the host.
  • Figure 7 depicts an example of a method that can be used to establish an Alias account as an extension of an existing account.
  • the cardholder completes an application 60 or request for the Alias account similar to the new account process as described above.
  • This application also has two parts, 62 and 64.
  • One part 62 goes to the issuer 104 and the other part 103 goes to the bunker receiving point (not shown).
  • the issuer 104 receives the application and performs a credit investigation for approval of the Alias account. If the research is successful and an Alias card is to be issued, the credit line is increased to accommodate both cards.
  • a new entry screen is created that is used to send the account information to the bunker 108, as shown by 105. In this fashion, the process works in a similar fashion as the new account process described above.
  • the account information is pulled from the master file either using an account dump or some other means of collecting the information that needs to be passed to the bunker.
  • the file that is created will go to the bunker as illustrated above in Figure 6 and the Alias account is created to be booked during the next cycle.
  • Example Bunker Processing Typically, two data sources provide input for construction of matching database records. One source is the part 2 information 64 containing the Alias name and document tracking number. The second is account information 76 created by processes on the host. Standard date and time tracking of information is performed for management of the data. Reports are typically generated to insure that processing works as desired and standard audit trails are established.
  • a data entry program is created that can be used to capture part 2 information 62. This information can then be transmitted to the bunker or hand carried into the bunker depending on location of the data entry personnel. Regardless, this is an offline process that requires a bulk transfer on a daily or other periodic basis. An additional data entry is provided to the issuer for doing approval of Alias accounts associated with an existing account. This should connect to a local server at the credit-card processing facility so that it can collect the account information needed for the bunker process.
  • New account information is collected for those accounts that are being created as part of the Alias credit-card product, as shown by 106.
  • the information is then formatted for transfer to the bunker, as shown by 110.
  • Account information is also collected from the system for those existing accounts that are having an associated Alias account. The information is preferably pulled from an account dump and then formatted for the bunker.
  • the following example summarizes an example process in accordance with the present invention that can be used create an Alias account. This example process is from the perspective of the bunker.
  • Daily maintenance tapes are preferably produced containing updates made to the Primary and Shadow accounts. These updates are preferably used to insure that the matching database 92 in the bunker is accurate. Updates that require processing include name and address changes as well as changes in available credit.
  • the updates may be extracted from an existing file 120 such as shown in Figure 8 A.
  • This file 120 is a daily record of all non-mon's that were posted. Typical changes required by existing credit-processing systems include additional steps as shown in Figure 8. For example, one step 122 takes the data from the daily update file 120 and creates a file for those records associated with Alias accounts. The file is then be transferred to the bunker for processing 124. Outputs from the bunker, if any, are updates that are input into the next day's cycle, as shown by steps 128 and 126.
  • the bunker receives a request from the cardholder to terminate the Alias account. In response, the bunker sends a non-mon to notify the host about the same. It also sends non-mons to update the status and credit line of Primary account. • In case of the Primary account, the change of name and address is transferred to the bunker through a file/tape, which the bunker uses to update the database with the new real name and real address.
  • (b) Bunker generates non-mons to do an AT (Account Transfer) of the Alias account to the Primary account i.e. terminate the Alias account and update the Primary account.
  • the bunker generates non-mons for putting the Primary account into the working queue and for updating the status of the Primary account.
  • the bunker When an Alias or its Primary account goes into collections the bunker receives notification so that appropriate actions can be taken.
  • the normal procedure when a Alias account goes delinquent will be for the bunker to generate non-mon's combining the two accounts into the Primary account. This will allow the collectors to have access to the information they need to work the account as well as provide proper reporting.
  • the Alias account is preferably closed to prevent its use.
  • a file is created that contains all the Alias accounts that have gone into collections.
  • an agreement with the cardholder specifies that either account going into collections is terms for termination of the Alias account.
  • Example Bunker Processing Those Alias accounts that become delinquent and require collections are passed to the bunker. The appropriate non-mons will be generated to combine the two accounts. The non-mons are then added to the file to be transmitted for the next night's cycle.
  • a special queue is set up to catch the accounts that need to be sent to the bunker. This queue can then be captured and sent to the bunker to be processed. Once the changes have been made to the account they will be placed in a working queue.
  • Statements and mailers sent to the cardholder of an Alias account are preferably ether redirected by placing a mailing label over the alias-mailing information or by changing the name and address of the mail piece before it is mailed.
  • By placing a label over the mailing information can create an item that can compromise the anonymity of the cardholder. That is, all the information (Real name, Alias name, Real address and alias address) is available on the mail piece. Accordingly, a preferred method is to change the name and the address before it prints. In this fashion, the only information that is exposed is the real name and address and any other information that is on the mail piece.
  • the host preferably prints information to a file. This file is transferred to the bunker, which replaces the alias name and address with the actual name and address.
  • Figure 9A depicts a process that can be used to replace the alias name and address to the real name and address before the statement is printed.
  • the records for Alias accounts are moved into a separate file. This file is then carried to the bunker where the correct name and addresses are changed 136. When this is complete the output tape is then returned to the credit-processing printing facility, where a monthly statement 138 is printed.
  • Bunker Processing Example Typically, the bunker will receive three different files for mail processing.
  • the standard statement file is received for Alias accounts. On the statement the alias name and address is overlaid wherever it appears on the statement and the payment coupon. The same is true on the Plastic and PIN mailers. Once the files have been passed they are transmitted back to the credit-processor to be printed and mailed.
  • the statements for the Alias accounts are preferably treated as if they are being printed by an external print shop.
  • the print files for the Alias accounts are separated and sent to the bunker for processing.
  • card and PIN Mailers have strict security requirements placed on them.
  • an association must certify any facility that handles these items.
  • anyone that handles these items other than the cardholder and the postal system typically must typically be certified.
  • a preferred approach is to make use of a facility that has already been certified.
  • the bunker provides an extract file to such a facility that can be used to change the name and address information on the Alias accounts mailers to be the real name and address.
  • the name on the card will be the alias name. This will allow the cards to be mailed to the correct address.
  • the account number on the mailer will be the matching one on the card so quality assurance of the plastics will still be able to insure that the process is working correctly.
  • FIG. 9B An detailed example of a specific implementation of a statement process is shown in FIG. 9B. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
  • Figure 9C depicts and example of a plastics process that can be used to emboss alias credit cards. Preferably, there is no major impact on the embossing part of the process.
  • One or more of the input files are preferably flagged to identify the Plastics/Cards associated with an Alias account. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
  • the alias name and address is replaced with the actual ones in order to send the Card to the correct destination.
  • the host receives this information from the Bunker before sending it for embossing, as shown in Figure 9C.
  • Payments are to be handled in a normal manner, that is a manner that is used for normal or standard credit-card accounts. This means that the cardholder will be required to make payment to each account that has a balance. Preferably, there will be no transfer of balance from one account to another to reduce complexity of the system. In one embodiment, the cardholder receives a payment coupon with each statement that will allow them to make payment for that account.
  • FIG 10 depicts a method that can be used for payment of the Alias account.
  • a payment coupon is sent with the monthly statement 150. Only the payment coupon is sent in with the payment 151.
  • the payment coupon has the real name and address on it. This was performed as part of the re-labeling process in the bunker before the statement was mailed, as described above.
  • the payment-processing center 152 the payment is credited to the account based on the account number presented on the payment coupon. There are no additional bunker and host processing requirements for this process.
  • mail redirection is not the responsibility of the bunker.
  • the bunker is typically required to support it.
  • Figure 11A is an example that depicts one method that can be used by the bunker to support mail redirection.
  • a separate database 162 is provided that can be queried using, for example, the box number assigned to the Alias account. The query returns the correct name and address of to be used.
  • This database 162 is preferably outside of the bunker and is made available via a secure network connection for use by those doing mail redirection.
  • the information included in the address subset database 162 is as follows:
  • the box number is preferably be unique. Further, a special zip code is preferably acquired from the post office to trigger this special handling. The zip code should be assigned to the facility that handles the manual re-labeling process for those items that are captured through special processing. The box number will be generated in the bunker and assigned when the Alias account is built.
  • Example Bunker Processing Two extract databases are typically built daily containing information for creating mailing labels. Both extracts contain the real name and address for mailing purposes. One extract is keyed by the box number in the alias address and the other uses the real account number as its key. These two databases can then be loaded on another machine or transmitted to the re- mail facility for use in creating labels.
  • FIG. 11B A detailed example of a specific implementation of a mail redirection process from both the host and bunker perspective is shown in FIG. 11B. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
  • Figure 12 is a block diagram that depicts an example process flow which shows the type of information flowing in and out of the Bunker receiving point, the Host and the Bunker. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
  • FIG 13 is an example of database tables that can be used to implement one specific embodiment of the bunker database in accordance with one embodiment of the present invention. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s). The following tables include details of the various fields shown in the example data base design shown in Figure 13.
  • Fields 2, 3 and 4 comprise the Part 2 of the account requisition form.
  • ⁇ Fields 5, 6, and 7 comprise the Part 1 of the account requisition form.
  • any part of the requisition form may come first at the bunker. Whichever part arrives first at the Bunker will be stored in the database. The other part of the requisition form will be entered in the database, using the Documen TrackingNumber mentioned on that part.
  • Part 2 has to arrive at the bunker, before Part 1.
  • the Primary AccountNumber will be one of the fields in Part 2, which will be used to obtain Part 1 details from the host.
  • the Temporary Database will be queried based on the Primary AccountNumber, so that the appropriate record can be updated.
  • DTN Document Tracking Number
  • the DTN is preferably captured to pass on to the bunker for matching with the alias.
  • the DTN will be stored in some miscellaneous field on the host database.
  • the Primary account number should be captured.
  • the DTN will typically not be stored.
  • the host database will have a method for distinguishing the primary accounts having Alias accounts from those which do not have (regular accounts).
  • the bunker can request for an account dump based on the Primary account number through a non-mon. Other possible ways could be to delete and recreate an existing account or do an account transfer.
  • the Alias name file would just have the DTN and the alias name. Other details like the mother's maiden name etc. would be taken from the Part 1 of the application or from the existing account.
  • Part two of the application would be keyed in through a user interface on the bunker side.
  • the issuer would process part one of the application.
  • ⁇ Credit line is split between the 2 accounts by the bunker (assumed to be predefined, either cardholder specific or issuer specific.)
  • the bunker would have the information about the split in the credit line stored in a control file. For Primary and Alias Card/Plastic, embossing comes separately.
  • the Temporary Database on the bunker side will contain only such records for which Alias accounts are to be created.
  • Updates to a Alias account may include change of alias address or a request to stop the Alias account by the user.
  • ⁇ Credit limit of a Alias Account can be changed only by changing the limit of its Primary Account.
  • the bunker would then re-adjust the limit of the Alias account and create non-mons for updating both on the host side.
  • the bunker would issue the Alias account number by selecting a number from the block of available numbers.
  • ⁇ Audit log would be generated for all the file transfers on bunker as well as host to ensure that all files sent by one are received by the other.
  • the Matching Database will have a field to indicate the last modification date/time for every account.
  • the Temporary Database on the bunker side will be purged after creating the Alias accounts in it.
  • the format of transferring the files from host to bunker can be anything but from bunker to host, it has to be in the format which the host can understand without changes to the existing system.
  • the Part 1 of the application may come before the part 2 of the application.
  • the Part 1 may be received much later than Part 2, even after weeks.
  • Part 1 may not be received at all.
  • the Alias Account number will not be replaced along with the alias name, address.
  • the acquisition function will generate an error log to inform the operator that the account block for a particular issuer is over. So to be able to create a new Alias account, the operator should increase the block limit.
  • the name and the alias address will also be stored in the Bunker database. This is required, because if a request comes from the host to change the alias name and address, there has to be some way of finding the old name and address to compare it with. Since the request has come from the host, the host database already has the new values. Hence to restore the old values, they need to be stored in the Mail Redirection Database.
  • the host After deactivating the Alias account, the host should send an Account Transfer confirmation to the bunker.
  • Kid Card embodiment represents a presently preferred embodiment of the invention and, as such, is merely a representative of the subject matter that is broadly contemplated by the present invention. It is further to be understood that the scope of the present invention fully encompasses embodiments other than the Kid Card and that the scope of the present invention is not limited by the following example embodiment.
  • the Kid Card is a credit or debit card that makes limited purchasing power available to children.
  • the transactions performed with the Kid Card are anonymous, and the products available for purchase with the Kid Card are subject to parental control.
  • children are guided through the shopping experience by the Web pages supplied by the hosting entity.
  • the transactions performed with the Kid Card are anonymous.
  • a child that purchases an item over the Internet uses the Kid Card to pay for the item.
  • an alias set of information is used as described above. This alias set of information is compared to an offline secure database in the bunker that compares the alias information to the true identity data and authenticates the transaction.
  • the true identity of the purchaser is thus never compromised and therefore never available to the processing company for inclusion on a demographic list.
  • parents can put restrictions on the types of items that the
  • Kid Card may purchase.
  • the authenticating database might be configured to allow the purchase of only Typel and Type2 items. Thus, if a child attempted to purchase a Type3 item such as adult content material or a Tommy Gun, the transaction would be denied.
  • the parental control can take the form of restrictions on the products that are available for purchase.
  • a group of parents who have created a Web page can offer the Kid Card.
  • the group controlling the content of the Web page additionally controls product availability by selecting the items that are available for purchase by children.
  • Yet another example of parental control is based on a password scheme.
  • the service provider requires a password from the child before allowing the child to enter the shopping area. Based on that password and input the service provider has received from the parents, the products available to the child for purchase are filtered.
  • the parents have control over what items are made available to their children by creating a shopping profile. Such a profile could be generated, for example, as part of the application process for the Kid Card.
  • the Internet Service Provider acts as the guide to the children's shopping experience.
  • the ISP could be America On Line (“AOL”) or any other provider.
  • the entity providing the Kid Card service could be a web page and not an ISP at all.
  • AOL will be used as both the ISP and the entity providing the Kid Card service.
  • AOL is the ISP. Additionally, AOL hosts a special "kids only" shopping area. The kids only shopping area may be accessible only with an additional password. The additional password could be assigned, for example, as part of the application process for the Kid Card. Because the kids only shopping area is within AOL, AOL is able to create the flow of the pages available to the children as they shop. Therefore, in this example, AOL guides the shopping children through the online store, displaying whatever advertisements and marketing materials deemed appropriate by AOL.
  • the Kid Card can be a credit card with a predetermined limit.
  • the Kid Card can be a debit card with an available balance that has been paid in advance.
  • the application process for the debit Kid Card might require that a certain amount of money be prepaid on the debit Kid Card to cover any future purchases made with the card.
  • the debit Kid Card no longer allows the purchase of goods. Additional funds must be paid to replenish the purchasing power of the Kid Card and allow the child to purchase additional goods.
  • the Kid Card can purchase items up to a certain monetary limit. For example, if the credit limit was $200.00 then purchases equaling that amount can be made before payment is required.
  • a feature of one embodiment is the availability of prepaid gift cards. These cards operate on the same principle as a debit card or a prepaid phone card. For example, a parent could purchase a Kid Card for $200.00 and give it as a gift to a child. The child is then able to purchase $200.00 worth of goods with the Kid Card. The difference in this example embodiment is that when the funds are exhausted on the gift Kid Card, the level of funds cannot be replenished.
  • the present invention provides a means for a consumer to order merchandise without revealing their true address to the merchant and/or shipper.
  • FIG 14 is a schematic diagram that depicts one embodiment of the disguised mailing feature in accordance with one embodiment of the present invention.
  • a cardholder 200 having an alias account makes a purchase from a merchant 202.
  • the purchase can be over the telephone, over the Internet or any other computer network, or via any other means available.
  • the merchant uses the alias address associated with the alias account, as described above, to ship the package.
  • this alias address is a warehouse or the like, referred to herein as the disguised mailing center (DMC).
  • DMC disguised mailing center
  • a bin number associated with the Alias account is used to store the package in a specific location within the DMC.
  • the Alias box number shown in the Mail Redirection data table 182, above can be used for this purpose.
  • the Alias box number is then used to generate a subscriber information request to the offline database to retrieve the true mailing address of the consumer.
  • the package is re-labeled with the true address and sent to the consumer 208. Preferably, this takes place within twenty-four hours to avoid any further delays to the consumer.
  • the consumer is provided with a mailing label that sends the package directly back to the merchant 202.
  • the return address printed on the return label will be that of the DMC 204.
  • the re-labeling process takes place by the shipper in transit.
  • the shipper can contact a server 22, which contacts the offline database with a request for address information.
  • the shipper can then re-label the package with the true address while the package is in transit, and thereby eliminate any extra delays.
  • Figure 15 is a flow chart that depicts a process that can be used to re-label packages in accordance with one embodiment of the present invention as described above.
  • the consumer orders a product using an anonymous transaction technique in accordance with the present invention as described above. Accordingly, the user typically, uses an credit or debit card associated with an Alias account to purchase the merchandise.
  • the merchant mails the package (or directs a shipper to mail the package), to the Alias address.
  • the Alias address is a warehouse or a location referred to as a disguised mailing center
  • the bin number (or set of characters) is input into a re-labeling system.
  • the bin number is a unique set of characters which is used to correlate an anonymous name/address (i.e. pseudonym) with a real name/address.
  • the bin is read into the system by scanning in a bar code or the like that comprises the bin. Alternatively, this information can be hand-keyed into the system. In any case, this action generates a request to a server that in turn contacts the bunker for the true address of the consumer. Once this information is retrieved, the package is re-labeled with the true address, as indicated by step 258.
  • the package is shipped to the consumer in accordance with consumer preferences (i.e. overnight, no signature necessary, etc.).
  • a second example of a method that can be used to re-label packages is depicted by the process flowchart in Figure 16.
  • the consumer orders a product from a merchant using an anonymous transaction technique as described above.
  • package is shipped using the Alias address associated with the account.
  • the shipper issues a request to the bunker for the true address of the consumer. This is accomplished in a manner as described above, typically through a server 23. Again, the Alias address or bin number in this example, is used to identify the consumer.
  • step 270 the shipper receives the true address of the consumer and re-labels the package with that address, as shown by step 272. Finally, as indicated by step 274, the package is shipped to the consumer in accordance with consumer preferences (i.e. overnight, no signature necessary, etc.).
  • the anonymous mailing is accomplished by mailing the merchandise to post office box, which is rented by the credit card processing company, on behalf of the cardholder.
  • the address associated with the cardholder alias name is the post office box assigned to the cardholder.
  • the post office box is as close geographically, to the actual address of the cardholder.
  • the cardholder picks up the merchandise from the post office box in person. While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation.

Abstract

An automated system for the confirmed efficient authentication of an anonymous subscriber's profile data. The system is comprised of software/hardware interface to facilitate centralized access and exchange to easily and inexpensively allow the confirmed authentication of subscriber profiles of customers wishing to blind their transactions, while maintaining current services. In one aspect the system allows a subscriber to anonymously accomplish credit card transaction without associating any aspect of the transaction with any information associated with the true identity of the subscriber. The system can also allow disguised mailings.

Description

Improved System and Method for Anonymous
Transactions
BACKGROUND OF THE INVENTION
Field of the Invention
The disclosed invention relates to the field of electronic transactions and particularly to processes and devices for facilitating the anonymous authentication of customer profile information to an authorized requester, and a system and method for protecting the privacy of customers when ordering merchandise by mail by not having to reveal their address to the merchant and/or shipper.
Description of the Related Art
As computing capacity increases and data handling and storage become easier and less expensive, information databases are assembled to host a myriad of transactional information. This information, which may be gathered from a number of sources, is stored, categorized and sold. A prime information target is the retail transaction. Membership cards, club cards and credit cards which link a transaction to an individual's database, reveal the purchase, the time of day of the purchase and the retail outlet. This information is then tied to a demographic which is sold to the direct marketing industry. In many cases these databases actually invade a person's privacy and are almost transparent to the unwitting consumer.
It is particularly easy to assemble such information when the transactions involve a third party. For example, a credit card company or bank can use the information it acquires in the course of credit or bank card transactions to determine the spending habits of particular customers. The credit card company or bank can then either use that information in its own business or make that information available to others. The consequences of the availability of information about an individual's spending habits range from the annoying to the serious. At a minimum, the individual receives more targeted junk mail than he or she might otherwise; more seriously, the same information that is used to target the individual for junk mail can be used to target the individual for activity which is tantamount to harassment.
One way an individual can avoid this problem is to pay for everything with bearer notes such as cash, since nothing on a bank note indicates who its owner is or was. This same property, however, makes cash fungible for both the owner and the thief. It is both easy to lose and easy to negotiate. For these reasons, few people desire to carry a large amount of cash. One way of solving this difficulty is to use electronic cash, as described in David Chaum, "Security without Identification: Transaction Systems to make Big Brother Obsolete," Communications of the ACM, vol. 28, no. 10, pp. 1030-144, October, 1985. When electronic cash is used in an automated transaction, a purchase cannot be associated with a customer. The scheme, however, may be insecure against fraud; see Steven H. Low, et al., "Collusion in a Multi-Party Communications Protocol for Anonymous Credit Cards" submitted to IEEE/A CM 50 Transactions on Networking. In addition, since the electronic cash is given to a customer, a means is needed to prevent the individual from duplicating and spending it over and over again.
What is needed is a way of performing transactions that has the convenience and safety of card transactions, such as credit card transactions, and the anonymity of cash transactions. It would therefore be advantageous to have a safe, secure, easy to use system to facilitate the confirmed authentication of customer related identity and business information between a service provider and a customer.
In addition, it is often desirable to protect the identity of consumers when ordering merchandise over the telephone or the Internet or by any other means, when such merchandise is to be shipped to the residence or business of the consumer. The problem is, that the consumer must ordinarily give a proper mailing address to the merchant in order to receive the shipped goods.
One solution to this problem is to use post office boxes. However, this solution is often expensive, inconvenient and often requires the use of the consumers real name rather than an alias name. Therefore, what is needed is a system and method to protect the identity of consumers names and addresses when ordering merchandise that is to be shipped to the consumer.
SUMMARY OF THE INVENTION
The disclosed system and method concerns a means by which a service provider or merchant is an information requester authenticating customer related information and/or records which reside in a secure, offline database without revealing the true identity of the customer. As recognized by the present invention, it is desirable that during or subsequent to a customer transaction, the service provider or authentication requester is able to authenticate the existence of the customer without having the true identity of the customer revealed.
The present invention provides an automated, inexpensive system and method for the confirmed request, processing and confirmed transfer of anonymous customer or subscriber related authentication among service providers and/or information requesters. The system is preferably comprised of a software and hardware system to facilitate centralized offline customer identity and business information authentication, while maintaining the anonymity of the customer. This advantageously allows a service provider or information requester to easily and inexpensively authenticate customer related business information without the true identity of the customer being revealed to the service provider. Thus, a benefit of the present invention is that the actual transaction is not associated with the true identity or demographics of the customer.
Another benefit of the present invention is that a highly efficient method is provided for requesting, processing, and anonymously authenticating customer or subscriber related identification and business information between the service provider or information requester and the secure, central, database repository. In one aspect of the present invention, this comprises an information hub which includes an interactive server and a database. For example, in one embodiment, the database contains a lookup table which blinds the database from the server. Preferably, the coded or addressed anonymous customer identification confirmation or authentication system of the present invention employs an offline central consumer information database or repository, in communication with service providers or information requesters. The system and method provide for the processing and authentication of requested, specifically identified customer profiles, without identifying the true identity of the customer, and without revealing any business or transaction information to the service provider or information requester. In a preferred embodiment, the authenticity of the information requester is verified prior to responding. Thus, one feature of the present invention is that there is a blinding or "bunkering" of any attempt by unauthorized information requesters to cross check against a known transaction to match the alias of the customer or subscriber with the true identity of the customer or subscriber.
Another advantage of the present invention is that a multiplicity of service providers or information requesters having a system authorization code, can electronically request, process and confirm the validity of an anonymous customer's information and/or records. This can be done, for example, from a secure data repository by means of a hardware/software system. Preferably, the hardware/software system is comprised of an offline database and a central server comprising an information processing hub. In this example embodiment, the information processing hub communicates with each service provider or information requester via a communication link.
A feature of the present invention is that a confirmed authentication of uniquely identified and stored information between an authorized requester and the database repository is triggered by the use of a unique, assigned alias identifier. For example, the requested subscriber or customer records and/or business information are uniquely identified by means of an alias identification of the customer, which can be alphanumeric, digital, analog or the like. In one embodiment the system can authenticate the existence of the customer alias as relating to the true identity of an individual subscriber. In another embodiment, authenticated coded triggers are used to release a predetermined portion of the data including, for example, the true identity of the subscriber, to an information requester having authorization for that clearance. In accordance with this embodiment, preferably the information is encrypted. In one aspect, an alpha numeric code is used to identify files within the uniquely addressed customer information profiles. In a preferred embodiment, the system of the present invention confirms requests for authentication to maintain the integrity of the system and the anonymity of the subscriber or customer. In another embodiment the authentication is protected by encryption and a digital signature of the information requester or by use of an authentication code such as a PIN or the like.
In a preferred embodiment, personal or business records and/or information related to a particular subscriber maintained within the offline database can include at least part of at least one subscriber's profile. In one aspect subscriber profiles consist of the subscriber's physical address, social security number, credit limits, e- mail address, and the like. In accordance with a preferred embodiment contemplated herein, a single centralized offline database or repository is provided in communication with a central processing server. For example, the central processing server acts as a "gatekeeper" to maintain the secrecy of the customer's true identity. In another embodiment, a plurality of servers communicate with the service providers and in turn with a central server in a multi-tiered system.
In another aspect of the present invention, a computer implemented method is disclosed for providing authentication to an authorized information requester. For example, the information requester may be provided with authentication of the existence of coded, uniquely identified personal business type records and/or information relating to a particular anonymous subscriber or customer. In a preferred embodiment, the records or information are contained in a "blinded" offline database that communicates with each authorized information requester by means of a central processing server. The method, for example, may be accomplished by the subscriber information requester initially generating an authorized formatted request for authentication of the uniquely identified records and/or information related to a particular anonymous subscriber or customer using an alias that retains the anonymity of the subscriber or customer. The method also includes transmitting the request to a confirming central processing server with access to an offline database via the communication link. Additionally, the method includes receiving the formatted request, authenticating the authorization of the information requester and confirming receipt of the formatted request by the central system database. The method also includes processing the request of the subscriber or information requester by blinded communication with the database, generating a formatted response in the database authenticating the alias or denying the alias, transmitting the response, and formatting a server response to the service provider or information requester via the communication link.
In one example embodiment, the formatted response to the subscriber or information requester can comprise a denial of the request, an authentication or an authenticated informational compliance. Additionally, the informational compliance can be full or partial. In a preferred embodiment, the requester is logged into the central server. For example, if the information requester is not authorized to address the offline database, the identification of the customer or subscriber is blocked and the information requester is denied further communication. In this example, such a formatted response is a denial of authentication.
In accordance with a preferred aspect of the invention, a medium is provided which contains a unique identification that is either anonymous or an alias with respect to the true identity of the subscriber and/or customer. For example, the medium can be in the form of a standard plastic card with a magnetic strip containing the encoded information or alias information or it can be in the form of a smart card that has an encoded chip. Alternatively, in addition to the card, there may be an alias I.D., such as a picture I.D., that authenticates the anonymous code for the user. In an example embodiment, a personal identification number ("PIN") can be used such that the user of the medium would be required to enter a PIN on a keypad or the like, to authenticate the anonymous code. A benefit in these examples is that the user of the medium remains totally anonymous to the service provider or requester. Also in the above examples, the service provider authenticates the transaction by means of an electronic connection such as telephone wires or the Internet to one or more centrally based processing servers in communication with the offline database as previously described. In accordance with another embodiment, the medium can be a credit card issued by, for example, American Express, VISA or MasterCard. For example, the service provider requests verification of the anonymous user through a central processing server to an offline database. Next, an authentication code response is sent to the service provider and information located in the look up table, such as the purchase, the purchaser and the amount, is then encrypted and transferred to a credit card provider bank to be posted to the subscriber's account.
In accordance with another embodiment, a "Kid Card" is a credit or debit card that makes limited purchasing power available to children. Preferably, the transactions performed with the Kid Card are anonymous and the products available for purchase with the Kid Card are subject to parental control. In one example embodiment, children are guided through the shopping experience by the Web pages supplied by the hosting entity.
For example, in one embodiment, the transactions performed with the Kid Card are anonymous. A child that purchases an item over the Internet, for example, can use the Kid Card to pay for the item. When real-time approval is sought by the entity processing the transaction, rather than using true identity data to authenticate the transaction, an alias set of information is used. This alias set of information is compared to an offline secure database that compares the alias information to the true identity data and authenticates the transaction. In this example, the true identity of the purchaser is thus never compromised and therefore never available to the processing company for inclusion on a demographic list or the like.
In addition, the present invention provides a means for consumers to order merchandise via telephone, the Internet, or any other means, to be shipped to their business or residence, without having to revel their true address to the shipper and/or merchant. This is accomplished by re-labeling the packages with the true address of the consumer sometime after the packages are shipped by the merchant. As described in detail below, this is preferably accomplished in combination of the anonymous transaction system, using one of at least two possible methods. The first method involves shipping the packages to a temporary location where the true address is re-labeled on behalf of the consumer using information from the offline database.
In a second embodiment, this is accomplished by having the shipping company re-label the packages while in transit by communicating through a secure network connection to the offline-database. In response to a valid authorization request, the offline database returns the true address to the shipper. Preferably, this process is automated and is implemented using wireless technology while the package is in transit.
BRIEF DESCRIPTION OF THE FIGURES
Figure 1 is an example of a schematic view of an information flow model that can be used in accordance one embodiment of the present invention.
Figure 2 is an example of a schematic view of an information flow model that can be used with one embodiment of the present invention having a central processing server and an offline database.
Figure 3 is a block diagram depicting one example of a method that can be used to create a new account.
Figure 4 depicts an example of a process that can be used to book a Primary account from part 1 of the application in accordance with one embodiment of the present invention.
Figure 5 depicts an example of a process that can be used to process part 2 of the application in accordance with one embodiment of the present invention.
Figure 6A depicts an example of bunker operations for application processing in accordance with one embodiment of the present invention.
Figure 6B depicts one example embodiment of an acquisition process in accordance with one embodiment of the present invention. Figure 6C depicts an example application process that can be used in one embodiment of the present invention.
Figure 7 depicts an example of a method that can be used to establish an Alias account as an extension of an existing account.
Figure 8A is an example of a method that can be used to perform maintenance in accordance with one embodiment of the present invention.
Figure 8B is an example of some account management and maintenance tasks in accordance with one embodiment of the present invention.
Figure 8C is an example of a collection method that can be used in accordance with one embodiment of the present invention.
Figure 9A depicts a process that can be used to replace the alias name and address with the real name and address before the statement is printed in accordance with one embodiment of the present invention.
Figure 9B depicts an example of a statement process that can be used in accordance with one embodiment of the present invention.
Figure 9C depicts one example of a plastics process that can be used to emboss alias credit cards in accordance with one embodiment of the present invention.
Figure 10 depicts a method that can be used for payment of the Alias account in accordance with one embodiment of the present invention.
Figure 11A is an example that depicts one method that can be used by the bunker to support mail redirection in accordance with one embodiment of the present invention.
Figure 11B is one example of a method that can be used for mail redirection from both the host and bunker perspective in accordance with one embodiment of the present invention. Figure 12 depicts an example process flow which shows the type of information flowing in and out of the Bunker receiving point, the Host and the Bunker in accordance with one embodiment of the present invention.
Figure 13 is an example of database tables that can be used to implement the bunker database in accordance with one embodiment of the present invention.
Figure 14 is a schematic diagram that depicts one embodiment of the disguised mailing feature in accordance with one embodiment of the present invention.
Figure 15 is a flowchart depicting methods that can be used to implement the disguised mailing feature in accordance with an embodiment of the present invention.
Figure 16 is a flowchart depicting methods that can be used to implement the disguised mailing feature in accordance with an embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
In accordance with a preferred embodiment in operation, an information hub housing a central server receives a request for authentication from a service provider or information requester. In this example embodiment, the central server verifies that the service provider or information requester is authorized to obtain authentication for the transaction or the requested information from the database. For example, upon verification of the validity of the request, the central server queries the database for authentication of the anonymous customer. The database contains, for example, a lookup table that links the anonymous identification of the medium card holder, for example, a credit card holder, to the true identity of the card holder. In this example embodiment, the lookup table functions a barrier between the system traffic and the stored identity information. Continuing with the example, if the information requested matches the search in the lookup table, a verification response is generated by the central server to authenticate the transaction. This could be used, for example, with telephone cards, frequent flyer club cards, grocery store cards and the like.
After reading this description, it will become apparent to one of ordinary skill in the art how to implement the invention in alternative embodiments and alternative applications. Moreover, other examples for blinding interaction and transaction will readily come to mind, once the inventive aspect of the instant invention is understood. Although the instant system can be used to blind customer profiles from a service provider for a number of applications, credit card transactions will be used as a specific example for ease of understanding. As such, this detailed description of a preferred and alternative embodiments should not be construed to limit the scope or breadth of the present invention.
Subscriber
For purposes herein, a "Subscriber" is an entity who subscribes to a transaction based service and whose data is in the offline database. A "Service Provider or Information Requester" is an entity with which the particular Subscriber is consummating a transaction. Service Providers could be, for example, local retailers, banks, travel agencies and the like. "Subscriber D" is an alias system identifier that can be used as an alias or a code to uniquely identify a particular Subscriber and its records. "Subscriber Profile" or "Service Profile" means customer-related business information and/or records such as a particular Subscriber's financial information, or address. "Subscriber Related Business Information Request" is a request from a Service Provider for authentication of all or part of a particular Subscriber Profile or Service Profile. The Profile preferably contains readable system code allowing the system to verify the requester is on the system. A "Subscriber Related Business Information Request Response" is a response to a Subscriber Related Business Information Request. For example, the Response could be a listing of all or part of a particular Service Profile, an authentication of a Subscriber's identity, or a denial of such information. In a preferred embodiment, the Response is encrypted. A Subscriber Related Business Information Request Response can also include a 'Transaction Authorization" or "Confirmation Request" such as used in the credit card industry.
Turning to FIGURE 1, there is shown an example of a schematic that can be used for the alias method and system 20 of the instant invention. In a preferred embodiment, the alias method and system 20 comprises a number of Service Providers or Information Requesters 21, each communicating with a system server/database 22 by means of a pre-existing communication link 23, such as the public telephone system. For example, the system server/database 22 can be a centralized information hub, having a pre-existing communication link 23 for the purposes of receiving, authenticating and transmitting information to Service Providers 21. In an alternative embodiment, the central information hub may comprise more than one physical element. For example, a multi-tiered server system (not shown) may be practical in some applications. Furthermore, a public communications system is not necessary to link the system server database 22 to the Service Providers 21. The communications link 23 may alternatively be a private leased line, a local area network, cable TV network, or the Internet. In a preferred embodiment, the system server/database 22 comprises a server and an offline database as more fully described below in relation to FIG. 2.
In a preferred embodiment, a Subscriber Profile data and/or authentication is relayed to a requesting Service Provider 21 through a system server/database 22, in computer accessible code, via a communications link 23. In one example, the information flow is virtually instantaneous, and the response information puts the necessary information in the hands of the Service Provider or Information Requester 21. This information is preferably delivered in a usable form, expediting the transaction.
Turning to HG. 2 there is shown an example of an information flow diagram that can be used in of one aspect of the inventive alias method and system 20. In the example depicted by FIG. 2, the transfer of a Subscriber's authentication or Subscriber Profile information between the Service Provider or Information Requester and the offline centralized database is shown. Preferably, the system server is accessible to all Service Providers 21. For example, the Service Providers 21 can access the System Server 22 by merely addressing the alias customer information profile by means of the Service Provider's identification through the communication link.
As further shown in FIG. 2, the example system 20 comprises an authorized Service Provider 24, a System Server 26, an offline database 28, and an interconnecting communications link 30. Preferably, the communications link 30 connects the Service Provider 24 and database 28 with the server 26. Additionally, the diagram in FIG. 2 schematically represents an example of the data flow within the system 20. In this example, the processes represent execution steps for creating, transferring and confirming information between Service Provider 24, server 26, and offline database 28. Preferably, this communication takes place by means of communications link 30.
Generation of Request for Subscriber Authentication or Information
In a preferred embodiment, Service Provider or Information Requester 24, by means of unit process 33, generates a Subscriber Related Business Information Request 32. For example, the request is generated in a specified format and includes an informational header. This header includes, for example, the Subscriber's alias, PIN or other anonymous inquiry keys and information. Additionally, the header may include address information and a formatted message portion comprised of, for example, the date, time, and amount of the transaction.
In a preferred embodiment, the data used to generate the Subscriber Related Business Information Request 32 can be provided in more than one way. A first example of a method for creating the Subscriber Related Business Information Request 32 is by using an application Graphical User Interface, preferably written in Java. In one embodiment, the Graphical User Interface provides the user with input fields for all elements of the Subscriber Related Business Information Request 32, including input fields for the Service Provider 24. Additionally, the Graphical User Interface can perform input validations, convert the input data into a binary stream using Java serialization, and store the document. For example, the document can be stored in binary object form in the Service Provider or Information Requester's 24 relational database.
A second example of a method for creating the Subscriber Related Business Information Request 32 is through the use of the Client Integration Subsystem. In a preferred embodiment, the Client Integration Subsystem is a configurable set of services and infrastructure. These services can be written, for example, in the C++ and Java programming languages. Furthermore, the services can, for example, allow an organization to "plug-in" their existing systems to automatically generate Subscriber Related Business Information Request 32. For example, the Request 32 could seek the coded information in a credit card transaction that authorizes a merchant's request and identifies the return path.
In both example embodiments, the resulting document is stored in the Service Provider or Information Requester's 24 relational database coupled with additional document information. For example, such information could include date and time stamps, document state information, creating user identification, and the like. Furthermore, this information could be linked to a particular Subscriber Related Business Information Request 32 and simultaneously stored along with the Subscriber Related Business Information Request 32. Preferably, the date and time stamps are used to determine whether the request is sent and received within the industry allotted time period. This, for example, would prevent hacking through the use of different requester locations attempting to obtain client Subscriber Related Business Information in the offline database 28. Additionally, the user identification information is preferably used by the System Server 26 and the offline database 28 to help verify the validity of the Subscriber Related Business Information Request 32. This can be done, for example, by determining that the Subscriber Related Business Information Request 32 was sent by an authorized Service Provider or information Requester 24.
In this example, when the Subscriber Related Business Information Request
32 is completed by entering the necessary data, it is marked as ready to be sent. Conversely, if the Subscriber Related Business Information Request 32 is not completed, for example, due to missing data, it is marked for review and stored until the Subscriber Related Business Information Request 32 data is entered into the Subscriber Related Business Information Request 32. Preferably, this prevents overriding the system by not having a complete request. This is important, for example, when service information provider or information requesters 24 are given security codes allowing access to differing information and/or levels of information.
Send Subscriber Business Information Request from Service Provider or Information Requester to the System Server
In a preferred embodiment, once created, the Subscriber Related Business Information Request 32 is prepared to be sent to the System Server 26 by means of unit process 34 via communications link 30. An example of the aspects of unit process 34 include application of the digital signature, data encryption, alias and attaching the routing information. For example, the Subscriber Related Business Information Request 32 carrying the alias identifier is encrypted by an encrypting service. In one example embodiment, the encrypting service utilizes Pretty Good Privacy encryption with a private key based on the system server's 26 public key. In one embodiment, an online service can be used or alternatively, the software can be downloaded from www.MIT.edu. for inclusion in process 34. Continuing the example, the document is digitally signed using the Service Provider's 24 private key. Preferably, this private key has been previously configured by the system administrator.
In one embodiment, the Subscriber Related Business Information Request 32 is sent to the server 26 using communication link 30. Various systems can be used to connect the Service Provider or Information Requester 24 to the System Server 26. For example, the message can be sent either via X400 protocol or using a virtual private network protocol. Preferably, the choice is based on the configuration implemented by the generating entity's system administrator, based on system requirements for response times and cost of implementation. In both example methods, a lookup of the server 26 destination address in the Service Provider or Information Requester's 24 database is performed. Preferably, the process 34 appends the appropriate routing information for the transmission type used by the generating entity system. A fully qualified Internet address is an example of appropriate routing information. Finally, the data is preferably sent over an existing communication system such as the Internet or a Virtual Private Network.
Receipt of Subscriber Related Business Information Request by System Server
In a preferred embodiment, the Subscriber Related Business Information Request 32 is received by server 26 from Service Provider or Information Requester 24. For example, this can be accomplished by means of unit process 36 via communications link 30. In one embodiment, the system is activated by data being received. Preferably, unit process 36 includes steps for receiving the message, authenticating the signature on the message and responding to the sender if the signature is valid. For example, upon receipt of a Subscriber Related Business Information Request 32, the server 26 first logs the receipt and then authenticates the digital signature. Within process 36, in the same example, an interim file representation of the document is created, after extracting the document from the transport mechanism and stripping off header information. The file is then stored in a system-defined, file system directory. Subsequently, the document digital signature is verified using the Pretty Good Privacy signature authentication service based on the sender's public key, which is retrieved via the previously configured information in the Pretty Good Privacy security database. Continuing the example, if the signature is authentic, the Subscriber Related Business Information Request 32 is decrypted using the Pretty Good Privacy decryption software and stored. Preferably, a verification of receipt message 38 (shown in dotted lines) is sent back to Service Provider or Information Requester 24 via the communication link 30. In a preferred embodiment, the Service Provider or Information Requester 24 verifies the sender as the System Server 26.
In an example embodiment, the validity of the Subscriber Related Business
Information Request 32 is based on several criteria. Preferably, if the Subscriber Related Business Information Request 32 is not authentic, the Request 32 is not honored. For example, in one embodiment, the invalid Request 32 is first returned to the Service Provider or Information Requester 24 via the Communications Link 30. Then, a message is sent noting the receipt of an invalid Subscriber Related Business Information Request 32.. Furthermore, receipt of the invalid Subscriber Related Business Information Request 32 is logged by the System Server 26. Preferably, the address of the invalid Service Provider or Information Requester 24 is "blocked" from the system 20 and the information pertaining to the unauthorized Service Provider or Requester 24 is maintained in the system 20 for future reference.
Processing of the Subscriber Business Information Request for Subscriber by
System Server
In a preferred embodiment, valid Subscriber Related Business Information Requests 32, received by the System Server 26, are processed in accordance with unit process 40. For example, the processing includes decrypting the message and preparing the message for forwarding to the offline database 28. Preferably, a message header is appended to the message and a document timer is activated to track the time until the System Server 26 receives a request response from the offline database 28.
In an alternative embodiment, to process the Subscriber Related Business
Information Request 32 in accordance with 40, the System Server 26 preferably records receipt of the Subscriber Related Business Information Request 32 into the System Server's 26 relational database. In this same embodiment, the Subscriber Related Business Information Request 32 is marked as received by the System Server 26. Furthermore, the Server 26 can also be configured to execute certain user defined operations which are triggered during this processing depending upon the nature of the Subscriber Related Business Information Request 32 as further described below. For example, if the request is a credit card transaction, certain information may be forwarded to the issuing bank after database manipulation as further described below.
In one embodiment, the document file is read in by the Server's 26 document handier, decrypted, and the document is then stored in the Server 26. For example, a document handler rules engine is used to process the document in accordance with unit process 40. Based on a user defined rules set, preferably stored in an ASCII text file, a rules agenda is created based on the contents of the document. In this example, the rules engine matches patterns in the rules conditions with the document and executes actions associated with the conditions. Examples of actions include updating database tables, modifying/transforming the document header information, and adding additional/alternative document routing instructions. Preferably, a timer is activated by storing a new record with Subscriber Related Business Information Request 32 information in the timer table.
Send the Subscriber Business Request for Subscriber Profile from the System
Server to the Database
In a preferred embodiment, subscriber Related Business Information Requests 32, thus processed, is ready to be forwarded to offline database 28 by means of unit process 42 via communication link 30. An example embodiment of unit process 42 includes the steps of encrypting the message, digitally signing the message, and sending the message to the offline database 28. Preferably, the functions required to prepare a document for forwarding are based on the type of Service Provider 24 from which the Subscriber Related Business information Request 32 is received. For example, if offline database 28 has authority and access to the data required to respond to the Subscriber Related Business Information Requests 32, it can create a Subscriber Related Business Information Request Response.
Receipt of the Subscriber Business Information Request for Subscriber
Information from System Server by Offline Database
In one embodiment, the offline database 28 receives, logs, and authenticates the Subscriber Related Business Information Request 32. For example, in unit process 44, the offline database 28 receives the message, the signature on the message is authenticated and a response is sent to the System Server 26 if the signature is valid. In this manner only the Server 26 can access the offline database 28.
In a preferred embodiment, after receipt of the Subscriber Related Business
Information Request 32, the information is processed in accordance with unit process 44. For example, process 44 creates an interim file representation of the document after extracting the document from the transport mechanism and stripping off header information. Here, the priority code is interpreted so that the appropriate information from the lookup table can be retrieved. Continuing the example, the Subscriber Related Business information Request 32 is stored and the appropriate customer related information is coupled with the document header. Preferably, The file is stored in a system-defined file system directory. Subsequently, the digital signature is verified using the Pretty Good Privacy signature authentication service based on the sender's public key, which is retrieved via previously configured information in the Pretty Good Privacy security database. If the signature is authentic, the document is decrypted using the Pretty Good Privacy decryption software based on the server's private key data.
In one embodiment, once the document is decrypted, the header information is separated from the Subscriber Related Business Information Request 32 and the Subscriber Related Business Information Request document 32 is stored. For example, a message 38 (shown in phantom) acknowledging the receipt of the Subscriber Related Business Information Request 32 is then sent by the offline database 28 to the Server 26 via communications link 30. Preferably, Erroneous Subscriber Related Business Information Request 32 receipts are logged and the Server 26 is notified via message 38. In this manner only requests from server 26 are accepted for processing.
Processing of the Subscriber Business Information Request for Subscriber Information and Generation of Response by Offline Database
In an alternative embodiment, once the Subscriber Related Business Information Request 32 is processed as set out above in unit process 44 by offline database 28 it is processed in accordance with unit process 46. An example of the method steps within unit process 46 includes: the Subscriber Related Business Information Request 32 is decrypted, the document is stored into the offline database 28 and the Subscriber Related Business Information Request Response 47 is created. For example, the offline database 28 formats the data into a document message and the offline database 28 appends reader information such as routing and document type to the message. Additionally, the subscriber Related Business Information Request 32 is stored in the offline database 28.
When the Subscriber Related Business information Request 32 has been processed, the Offline Database 28 responds. For example, the Offline Database 28 sends a Subscriber Related Business Information Request Response 47 back to the Service Provider or Information Requester 24 through the System Server 26 via communications link 30. Preferably, the Subscriber Related Business Information Request Response 47 is generated in accordance with unit process 46. In one example, the Subscriber Related Business Information Request Response 47 is prepared using an application Graphical User Interface preferably written in Java. The Graphical User Interface, for example, provides the user with input fields for all elements of the Subscriber Related Business Information Request Response 47, including input fields for the Service Provider or Information Requester 24. Preferably, the Graphical User Interface performs input validations, converts the input data into a binary stream using Java serialization, and stores the document in binary object form into the offline database's 28 relational database.
In a preferred embodiment, the document is stored into the offline database's 28 relational database. For example, the document may be stored with additional document information such as date and time stamps, document state information, creating user identification and the like which are linked to a particular Subscriber Related Business Information Request Response 47. Preferably, the document state information is used by the system to determine whether the Subscriber Related Business Information Request Response 47 is ready to be transferred to the System Server 26. Additionally, the user identification information is used by the System Server 26 to help verify the validity of the Subscriber Related Business Information Request Response 47 by determining that the Subscriber Related Business Information Request Response 47 was sent by offline database 28 or an entity having access to the subscriber information and authority to disseminate authentication or information. In one embodiment, when the Subscriber Related Business Information Request Response 47 is completed by entering the necessary data, it is marked as ready to be sent. Conversely, if the Subscriber Related Business Information Request Response 47 is not completed due to missing data, it is marked for review and stored until the Subscriber Related Business Information Request Response 47 data is entered into the Subscriber Related Business Information Request Response 47. Preferably, a message is sent to the Server 26 requesting additional information be placed in the database 28 to fill the request.
Send the Response to the Request for Subscriber Information to System Server from Offline Database
In a preferred embodiment, after Subscriber Related Business Information Requests Response 47, has been processed, it is ready to be forwarded to System Server 26 by means of unit process 48 via communication link 30. For example, within unit process 48, Subscriber Related Business Information Requests Response 47 is encrypted, digitally signed, and sent to the Server 26. After processing, the Subscriber Related Business Information Request Response 47 is preferably stored in the relational database coupled with additional information such as date and time stamps, and user identification.
Receipt of the Response to the Subscriber Information Request by System Server from Offline Database
In one embodiment, after the Subscriber Related Business Information Request Response 47 is received by the System Server 26, it is handled in accordance with unit process 50. For example, within unit process 50, the system server receives the Subscriber Related Business Information Requests Response 47, the signature on the Subscriber Related Business Information Requests Response 47 is authenticated, and a response 38 is sent to the offline database 28 if the signature is valid. Preferably, the Subscriber Related Business Information Request Response 47 is acknowledged by message 38 to the offline database 28 via link 30 and its receipt is logged. Continuing the example, the Subscriber Related Business Information Request Response 47 is processed by Server 26. An example of this processing includes authentication of the Subscriber Related Business Information Request Response 47 and validation of the intended Service Provider 24 address. Additionally, the receipt event is logged. Preferably, the document is decrypted as above described and checked against existing Subscriber Related Business Information Request 32 for a match. For example, Subscriber Related Business Information Request Response 47 match errors and destination errors are logged and notifications sent back to the offline database 28. Furthermore, the respective unit process 50 creates an interim file representation of the document after extracting the document from the transport mechanism and stripping off header information. In this same example, the file is stored in a system-defined file system directory. The document digital signature is then verified using signature authentication service based on the sender's key. Preferably, if the signature is authentic, an acknowledgment message 38 is created and sent back to the Offline Database 28 via the same communication mechanism that the document was received. In one method, the converted response is stored in the server's 26 persistent storage mechanism.
Processing the Response to the Subscriber Information Request by System Server
In an alternative embodiment, after the Subscriber Related Business Information Request Response 47 response is received by Server 26, it is processed as shown by unit process 52. Such processing, for example, includes storing the document, logging its receipt and managing the timers associated with the original request. For example, within unit process 52, Subscriber Related Business Information Requests Response 47 is decrypted, an ID is matched against the initial request sent, the message is stored into the System Server 26 database, the document timer is deactivated, the Subscriber Related Business Information Requests Response 47 is prepared for forwarding to the requesting Service Provider 24 and a message header for sending Subscriber Related Business Information Requests Response 47 to the requesting Service Provider 24 is appended. Preferably, the Subscriber Related Business Information Request Response 47 receipt is logged and the document state is set to "complete." Such a setting indicates that the Subscriber Related Business Information Request Response 47 is ready, for example, to be encrypted, signed, and forwarded to the Service Provider or Information Requester 24, as represented by unit process 54..
In a preferred embodiment, the document file is read in by the Server's 26 document handler process and the document is then stored in the Server 26. The Document Handler Rules Engine is then activated to process the document. For example, a rules agenda is created based on the contents of the document. The rules engine matches patterns in the rules conditions with the document and executes actions associated with the conditions. The rules match the Subscriber Related Business Information Request Response 47 by document identifier information with the Subscriber Related Business Information Request 32. Preferably, the system timer that was created when the document was originally received by the server 24 is deleted from the server timer table. Subsequently, in this example, the destination for the Subscriber Related Business Information Request Response 47 is validated and any erroneous Subscriber Related Business Information Request Responses 47 are logged. Preferably, The Document Handler process modifies the Subscriber Related Business Information Request Response 47 header information for document transmission status and stores the information to the database.
Send Response to Subscriber Information Request from System Server to
Service Provider
In one example embodiment, the Subscriber Related Business Information Requests Response 47 is sent to the Service Provider 24 using the communication link 30 in accordance with unit process 54. For example, within unit process 54, the Subscriber Related Business Information Requests Response 47 is encrypted, digitally signed, and then sent to the Service Provider 24. Additionally, the system appends the appropriate routing information for the transmission type used by the Service Provider 24. Furthermore, acknowledgment of receipt is received via 38 and logged. Preferably, match and destination error notifications are received and logged, corrections are made and the response re-sent if necessary. Receipt of the Response to the Subscriber Information Request by Service
Provider
In an example embodiment, upon receipt of the Subscriber Related Business Information Request Response 47, the Service Provider or Information Requester 24 authenticates the System Server 26 as the sender and logs the receipt of the Subscriber Related Business Information Request Response 47 in accordance with unit process 56. For example, within unit process 56, Subscriber Related Business Information Request Response 47 is received, the digital signature is authenticated, and a response 38 is sent to the System Server 26 if the signature is valid. Additionally, the digital signature is verified and the Subscriber Related Business Information Request Response 47 is matched against the Subscriber Related Business Information Request 32. Preferably, the Subscriber Related Business Information Request Response 47 is processed in a manner similar to unit process 46 in accordance with unit process 58.
Service Provider Processing of the Response to the Subscriber Information
Request
In an alternative embodiment, the Service Provider or Information Requester 24 processes the Subscriber Related Business Information Request Response 47 in unit process 58. For example, within unit process 58 Subscriber Related Business Information Request Response 47 is decrypted and matched to the Subscriber Related Business Information Requests 32 stored in the requesting Service Provider's 24 database. Furthermore, the document status is set to complete or rejected depending on the response data sent in the Subscriber Related Business Information Requests Response 47 by the offline database 28. Preferably, the completion of this step is the termination of the process.
In a preferred embodiment, a log entry is made into the system server database recording information about the document reception process. For example, the document state is set to complete by the document processor of Server 26 by updating the document header in the database. Preferably, a trigger is fired to perform a system defined service upon document completion. Triggers, for example, can perform actions such as sending a user-defined message to a socket, storing data in another database, performing communications and the like. In this manner transaction data can preferably be sent to, for example, an issuing bank.
The Systems Server and Offline Database
An example of the system server/offline database architecture consists of six subsystems: process control subsystem, communication subsystem, document processing subsystem, security subsystem, user interface subsystem and a data handling and storage subsystem.
Process Control Subsystem
A descriptive example of the process control subsystem includes a system that invokes and controls the other custom and commercial software that make up the system server. This subsystem, for example, is able to automatically restart erroneously terminated processes and logs such terminations for later analysis. Preferably, users are able to configure the process control subsystem to take additional actions when a process terminates.
Communication Subsystem
An example of the communication subsystem is further comprised of an X400 agent and/or virtual private network communication agent. Preferably, this subsystem uses either agent to send documents out of the system server to external recipients, and relies on a fully qualified Internet address for routing.
For example, the communication subsystem's message receiving functions include determining how to route a message to its recipient, and accepting and transferring mail from and to intermediate agents. Additionally, address interpretation and transformation into a compatible format is handled by the communication subsystem. The communication subsystem also implements special actions indicated by the message header such as verifying delivery. For example, when message delivery cannot be done, the communication subsystem queues messages, or reroutes documents with erroneous addresses, as required. To send messages to a recipient, the communication subsystem determines the recipient's pre-existing public communication system host, then initiates a transfer protocol session with the host. Preferably, an unsuccessfully transferred message is queued for later delivery.
In an embodiment where the System Server 26 functions as a routing hub for the system, the communication subsystem receives and processes all incoming document transfer protocol sessions from client systems. For example, outbound documents are packaged and sent to the communication agent for processing. Additionally, the communication subsystem automatically processes received messages by first authenticating, then decrypting, and then sending the message to the document processing subsystem. In one embodiment, the communication subsystem places a time stamp on each message that when compared with the message status indicates when a message has not been successfully delivered. Unsuccessfully sent messages are preferably resent a predetermined number of times according to preset communications subsystem parameters.
Document Processing Subsystem
In a preferred embodiment, the document processing subsystem processes all messages received into the System Server 26. For example, this subsystem can be responsible for message parsing, message storage, Subscriber Related Business Information Request processing, Subscriber Related Business Information Request Response processing, message routing and message timers. Preferably, messages are processed in the order in which they are received and deleted after successful processing.
In a preferred embodiment, a message is logged into the activity log upon reception and then parsed. For example, the message parser divides the message into two parts: header and message data. Message type information contained in the header determines which type of action the system server should take with the message data. After parsing, the message data is stored. Preferably, the message data is stored according to message type and the message header is logged. For example, a Subscriber Related Business Information Request is stored in a Subscriber Related Business Information Request table; and a Subscriber Related Business Information Request Response is stored in a Subscriber Related Business Information Request Response table. In an alternative embodiment, table entries are crossed referenced, and transmission verification messages and the status of the corresponding message are logged.
In an example embodiment, after the message is stored, the Subscriber
Related Business Information Request 32 is processed. For example, the first step in processing a Subscriber Related Business Information Request 32 is to log the event. Then the name of the service provider 24 is extracted and the service provider's address is obtained from a lookup table. The Subscriber Related Business Information Request 32 is then sent to the offline database 28. Preferably, the Subscriber Related Business Information Request 32 is marked as sent when a return receipt is received. In alternative embodiments, Subscriber Related Business Information Requests 32 can be in any of four states based on responses from the offline database 28: pending, sending, inactive, or completed.
In a preferred embodiment, after the Subscriber Related Business
Information Request 47 is processed and sent to the service provider, the Subscriber Related Business Information Request Response 47 is processed after it is received from the service provider. For example, when a Subscriber Related Business information Request Response 47 is received by the document processing subsystem, the corresponding Subscriber Related Business Information Request identification number is located and the Subscriber Related Business Information Request status is checked. The Subscriber Related Business Information Request Response 47 is marked as invalid if the Subscriber Related Business Information Request 47 is not pending. Preferably, Document status is updated when the Subscriber Related Business Information Request Response 47 is processed, forwarded to the requesting Service Provider or Information Requester 24 and stored into the system.
In a preferred embodiment, a message's time in the document processing system is tracked by a timer. In one example, default events are set to occur at pre- set times. Preferably, such default events include setting a message's status to a certain value if no response has been received or to send the message again if no return receipt is received.
Security Subsystem
In an alternative embodiment, the security subsystem primarily secures four areas: system data and file access, the relational database, the system administrative user interfaces and data and messages. For example, system data and file access to the offline database 28 is protected by a user identification string that allows access to only the owner. Preferably, access to the relational database is controlled through a data owner's user identification string and password, and no access privileges are granted to any other user. Additionally in this example, the system administration user interfaces and data are protected by another set of user identification numbers and passwords. Preferably, users can not gain access to the system administration user interfaces and data through other databases.
In one embodiment, messages are secured by encryption and a digital signature. For example, commercial security software does the encrypting and decrypting, message authentication, and digital signature verification. Software specifically designed to secure document transmissions using Public Key Cryptography is preferred. In alternative embodiments, Public Keys can be manually transferred between system/client administrators via e-mail or disk/tape. Preferably, key transfers are authenticated by verifying the digital signature of the sent document.
Furthermore, all messages preferably receive a digital signature based on the private key of the sending system. For example, upon receipt, the digital signature of a message is automatically verified. Messages that fail digital signature verification are not processed, but rather are stored and the failure noted in the automated activity log. Preferably, the sender is not notified when a message fails verification. This, for example, is to prevent attacks from hostile systems. User Interface Subsystem
In a preferred embodiment, the user interface subsystem allows a system administrator to add or delete service providers, add or update message routing information and monitor system activity. Preferably, the interface is accessed through Java software applets which can be executed within a web browser, such as
Netscape Navigator or as a stand alone application.
Data Storage Subsystem
In one embodiment, offline database system data is stored in the commercial relational database. For example, the offline database system uses a database access and storage facility implemented using embedded structured query language in the user application processes and Java Database Connectivity. In an alternative embodiment, the Unix file system can be used to store system data.
It will be realized by the skilled artisan that many transactional applications lend themselves to the anonymity provided by the instant invention. Accordingly, in one aspect, particular service providers or Information Requesters have security codes and/or priority codes which allow them access to some, if not all, of the information contained in the offline database. This, for example, would be the situation with an issuing bank with a particular credit card that has been issued to a Subscriber in the anonymous system and various pieces of information with regard to, for example, financial status of the Subscriber are required in accordance with the Agreement between the Subscriber and the bank. Preferably, this information flow is handled by the server as set forth above after authentication of the total transaction.
It will be realized that alternative embodiments of the system in accordance with the instant invention can provide some or all of the information contained in the database to a particular Service Provider or Information Requester depending upon the degree of anonymity, the position of the Service Provider or Information Requester, and the access codes/alias identifiers of the system. Thus, in accordance with one aspect of the invention, no information is allowed to any Service Provider or Information Requester and in that aspect the system has the capability of providing authentication or authorization code for a particular transaction completely devoid of any subscriber information. Further, it will be realized that particular embodiments will allow grocery cards and club cards such as frequent flyer and the like (which are primarily involved in gathering demographic information with regard to purchasers)to be "blinded" by the use of the instant invention.
In accordance with the instant invention, it will be realized that, for example, a number or series of aliases or codes such as personal identification numbers, and the like can be used in association with the medium to reduce risk of unauthorized use of the medium. In accordance with a preferred embodiment, security codes may be issued to the Subscriber such that one or more of the security codes must be used depending on the magnitude of the transaction. Further, it will be realized that although plastic cards are an easy medium in which to embed alias identification, alternative embodiments may employ other mediums such as electronic transfer medium, smart cards, chips, and the like. Thus, as long as the medium can maintain and contain at least one set of alias identifiers that can be recognized by the system, any medium can be used in accordance with this invention. For example, codes on keypads and even fingerprints would be acceptable identification to trigger the system.
Example Embodiments
The following is an example of one specific embodiment of the present invention. While this particular example embodiment of the improved system and method for anonymous transactions is fully capable of attaining the above described features and benefits of the invention, it is to be understood that this example embodiment represents a presently preferred embodiment of the invention and, as such, is merely a representative of the subject matter that is broadly contemplated by the present invention. It is further to be understood that the scope of the present invention fully encompasses embodiments other than the example embodiments presented herein. Accordingly the examples presented herein should not be construed to limit the scope or breadth of the present invention. In the example embodiment presented herein, an account is provided that can be used while maintaining the anonymity of its user. An offline database, also referred to as a "processing bunker" allows for two separate accounts to be established for an individual. In a preferred embodiment, the bunker is the only place that contains information that associates an account used for establishing a line of credit to the alias account used to protect the identity of the cardholder.
Below are some definitions used below that are useful for describing this example embodiment of the present invention.
Primary account - the account applied for that has all the accurate information about the cardholder and is used to establish a line of credit.
Shadow account or Alias account - an account that uses an alias name and alias address to protect the anonymity of the cardholder. It is preferably attached to a Primary account through the bunker. In the examples and some of the Figures presented herein, this account is also referred to as a "Casper" account.
Normal Account - a standard credit-card account that has nothing to do with the Primary and Shadow accounts of the present invention.
Bunker - The process that supports linking of the Primary and Shadow accounts together. The bunker may be in a separate facility, or in an existing data center depending on the amount of separation desired in each specific implementation of the present invention.
Credit-Card Processing System - As described in detail below, the present invention can be used with existing credit-card processing systems. In some of the Figures and examples below, an existing credit card processing system is also referred to as "FDR".
The bunker is preferably constructed to provide a standalone source for synchronizing information between the Primary account and the Shadow account. It also provides services for properly addressing communications to the cardholder. These functions are preferably driven from a database containing information on both accounts. In one embodiment, the bunker has no public network connections outside of the building. In this fashion, the present invention provides an extremely secure environment for the matching information.
This example embodiment can be used with existing credit-card processing models with minimal intrusion. The remainder of this example describes the bunker functionality and its interaction with a typical existing credit-card processing model.
In the example embodiment, a new product is provided that protects the identity of the cardholder. It allows the establishment of a line of credit that is split across two accounts. The two accounts are referred to as the Primary account and the Shadow account. The Primary account is the account booked using factual information provided on an application. The Shadow account is the account booked using information from the Primary account with an Alias name and address.
In one embodiment, the Primary account is a standard credit account that can be used like a traditional credit card. The credit line for the card is established as some portion of the credit line approved during application processing. The remaining portion is assigned to the Alias card. In this example embodiment, two cards are used because of possible restrictions that may be placed upon the use of the Alias card. For example, the Alias card may be restricted in places where proof of ID is required, such as for hotel, airline and rental car reservations.
ACQUISITION
In one embodiment, the acquisition of Shadow accounts can be accomplished in two ways. The first is through new account solicitation.. For a new account, a new application is completed and a new credit card account and an Alias account is created. The second way relates to associating an Alias card account with an existing credit card account already on file. The following example describes both of these scenarios.
New Accounts. Figure 3 is a block diagram depicting one example of a method that can be used to create a new account. As shown, in one embodiment, a new account acquisition is accomplished using a two-part application 60. Both parts 62 and 64 of the application 60 have a document tracking number (shown as "123" in Figure 3). The document tracking number is used in this example embodiment to construct a relationship between the Primary credit card account and the Shadow account. Preferably, the document tracking number is unique. Each part of the application 62 and 64 is sent to a different destination as shown by Figure 3.
Specifically, part 1 of the application 62 is mailed to the issuer's application processor. Part 2 of the application 64 is mailed to a receiving point for the bunker. Preferably, each of the application parts 62 and 64 has only the document tracking number ("123") in common. This number is used in the bunker to create the relationship between the Primary account and the Shadow account.
In a preferred embodiment, the document tracking number is captured in a master file when the application is processed. In this fashion, the document tracking number can be passed to the bunker after the account is booked. In one embodiment, bunker receiving is not in the bunker location itself, but in a location where part 2 of the application is actually received and the Alias name and document tracking number is captured for input into the bunker.
Thus, key points for protecting the anonymity of the account holder include sending part 1 of the application 62 to a different location than part 2 of the application 64, and the only common information between all parts is the document tracking number on the application 60.
In a preferred embodiment of the present invention, rules for processing the application 60 follow the issuer's standard process. Such a process may already be in existence for processing normal credit-card accounts and the like. For example, credit bureau reports are requested and the account is scored to determine eligibility. Preferably, the only special requirements are that the credit line being established is split between the two accounts, the Primary and the Shadow account, and the capturing of the document tracking number from the application so that it can be later passed to the bunker for matching with the Alias.
Figure 4 depicts an example of a process that can be used to book a Primary account from part 1 of the application 62. As shown, part 1 of the application 62 is mailed from the cardholder. A data entry terminal 72 is used to enter the information from the application 62 into a computer system, such as the IBM mainframe 74 shown in Figure 4. If the application is not approved, standard rejection letters are typically sent back to the applicant. However, if the application is approved, it will be booked. Information related to the new Primary account is then stored in the account file 76. This information includes the actual name and address of the cardholder but does not include the alias information.
Figure 5 depicts an example of a process that can be used to process part 2 of the application 64 in accordance with one embodiment of the present invention. Part 2 of the application 64 is handled separately from part 1. This part 64 is used to assign an alias name to the Shadow account when it is built. Part 2 of the application 64 contains the alias name and the document tracking number that matches the number on part 1 of the application 62. As shown, a data entry operator using a data entry application on a personal computer (PC) or the like 80 captures the information. In one embodiment, the application on the PC 80 creates a file that is stored on removable media 82 and transferred on a daily or other periodic basis to the bunker.
An example of bunker operations for application processing is shown in figure 6A. The bunker receives a file 82 comprising part 2 alias information as described above. This information is used as input to a matching database process or application program 88. Alias information is posted to the data store 90 using the document tracking number. If the document tracking number is already on file, a check is made to determine if the alias information has already been posted. If it has not, then a new account record is created and added to a file that is sent to the host (not shown) for posting. If the alias information has already been posed, then an error is reported.
It is important to note that in one embodiment, the above-described process takes information for a cycle and uses it to create input for the next cycle. That is, if an account is approved before the day's cycle kicks off, the new account is created during the night cycle and the information for the bunker is extracted from files created during that cycle. The file will then be hand-carried to the bunker for processing. This input to the bunker is then processed and the new Alias accounts and other account updates are loaded into files that will be transferred by hand back to the account processing facility for the next night's cycle.
Details of one example embodiment of an acquisition process is shown in Figure 6B. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s). IT is noted that in these example, the Shadow and/or Alias account is also referred to as the "Casper" Account. These details expand on the principles described above and provide a specific implementation of one example embodiment. It should be noted that these details are for exemplary purposes only and should not be construed to limit the scope and breadth of the present invention, which could be implemented using alternative means.
For an existing account, the credit line has to be increased and/or split to accommodate both the cards on approval. The host will receive non-mon (non- monetary transaction) from the bunker for updating the credit line of the primary account. Also the output is merged with that of the Casper specific output. An example of a process including typical inputs and outputs that can be used to match the Primary and Alias accounts for acquisition is as follows
Input:
Document Tracking Number and/or the primary account number from the Account file.
Output:
Corresponding Alias Account details from the Temporary Database (See Figure 6B).
Process:
Query the Temporary Database for the given Document tracking number or Primary Account Number or the like, to obtain its Alias account details. Figure 6C depicts an application process as described above for a specific example embodiment. It is noted that in Figure 6C, a three part application is referenced rather than a two part application as described above. However, the third part of the example application is merely a record for the application card-holder in this example. It should be noted that in a preferred embodiment, at least a two part application is used as described in detail above with respect to Figures 3-5.
The following is a summary of an example acquisition process, for a new and existing account, as can be seen in Figures 6B and 6C.
Input:
New account
A 2-part form is filled up.
■ The 2 parts have a common Document Tracking Number.
■ Part 1 of the Application, which is mailed to the Issuer's Processor, is treated just as a normal account. ■ Tape from the bunker (non-mon to the mainframe) for creating new Alias accounts.
■ Non-mons from the bunker requesting the update of Primary account status and credit line.
Existing account Part 2 of the application is filled up. The Primary account number is supplied to the bunker as the Part 1 information.
A non-mon from the bunker requesting the Part 1 details.
■ Tape from the bunker (non-mon to the mainframe) for creating new Casper accounts. ■ Non-mons from the Bunker requesting the update of Primary account status and credit line.
Output: Account file that goes to the bunker.
■ Creation of Alias or Casper and Primary Accounts (in case of new account)
Process:
Rules for processing the application (both part 1 and part 2) preferably follow the Issuer's standard process.
Update the master file.
Capture the newly booked primary accounts to the Account File.
This Account File will is written to tape or other removable media that is to be sent to the bunker. Proper formatting of the data is typically required. This is actually a non-mon sent to the bunker from the host.
Bunker updates its database using the Account File 76 and generates an Alias Account File that is sent to the host through a tape or other removable media. These records will be posted in the next day's Cycle as a new Account Processing Facility. This is a non-mon from the bunker to the host.
Existing Accounts. Figure 7 depicts an example of a method that can be used to establish an Alias account as an extension of an existing account. The cardholder completes an application 60 or request for the Alias account similar to the new account process as described above. This application also has two parts, 62 and 64. One part 62 goes to the issuer 104 and the other part 103 goes to the bunker receiving point (not shown). Typically, the issuer 104 receives the application and performs a credit investigation for approval of the Alias account. If the research is successful and an Alias card is to be issued, the credit line is increased to accommodate both cards. A new entry screen is created that is used to send the account information to the bunker 108, as shown by 105. In this fashion, the process works in a similar fashion as the new account process described above.
In one embodiment, the account information is pulled from the master file either using an account dump or some other means of collecting the information that needs to be passed to the bunker. The file that is created will go to the bunker as illustrated above in Figure 6 and the Alias account is created to be booked during the next cycle. Example Bunker Processing. Typically, two data sources provide input for construction of matching database records. One source is the part 2 information 64 containing the Alias name and document tracking number. The second is account information 76 created by processes on the host. Standard date and time tracking of information is performed for management of the data. Reports are typically generated to insure that processing works as desired and standard audit trails are established.
A data entry program is created that can be used to capture part 2 information 62. This information can then be transmitted to the bunker or hand carried into the bunker depending on location of the data entry personnel. Regardless, this is an offline process that requires a bulk transfer on a daily or other periodic basis. An additional data entry is provided to the issuer for doing approval of Alias accounts associated with an existing account. This should connect to a local server at the credit-card processing facility so that it can collect the account information needed for the bunker process.
Example Host Processing. New account information is collected for those accounts that are being created as part of the Alias credit-card product, as shown by 106. The information is then formatted for transfer to the bunker, as shown by 110. Account information is also collected from the system for those existing accounts that are having an associated Alias account. The information is preferably pulled from an account dump and then formatted for the bunker.
Example of creating a new Alias account
The following example summarizes an example process in accordance with the present invention that can be used create an Alias account. This example process is from the perspective of the bunker.
Example Input:
The Alias Name file containing the part two of the new account requisition form. The account file for the Primary account, for which the Alias Account is to be created.
Example Output:
Creation of the matching database.
Creation of a non-mon to create an Alias Account on the Cardholder Master File. This non-monetary transaction will be an input to the next day's cycle to the host.
Example Process:
Retrieve the information from the Alias Name file entered by the operator at the Bunker Receiving and store it in the Temporary Database.
For a new account, retrieve the information from the Account file present in the Bunker Receiving and store it in the Temporary Database.
For existing account, for each Primary Account Number on Part 2, send a non- mon to the host to obtain the Part 1 details for the same. Store these details in Temporary Database .
For each Alias Account, fetch the corresponding details from the Temporary Database for either the Document Tracking Number or the Primary Account Number.
Select an account number for the new Alias account from the Accounts Block Table. If the end of the account block has reached, generate an error log for the operator.
If no error, generate an alias address for the new Alias account.
Add a new record to the Matching Database which has information like Primary account number, Alias account number and the Alias Box number and other information.
Enter the date and time in LasfUpdateDateAndTime field of Matching Database. This is for maintaining the audit log.
Add a record to the Mail Redirection Database containing Alias Box number, Real Name and Address and Alias Name and Address of the Cardholder. Create a non-monetary transaction and the Alias accounts file, for the host to create a new Alias account. Create a non-mon for the host to update the status and Credit line of the Primary account.
Maintenance
Daily maintenance tapes are preferably produced containing updates made to the Primary and Shadow accounts. These updates are preferably used to insure that the matching database 92 in the bunker is accurate. Updates that require processing include name and address changes as well as changes in available credit.
The updates may be extracted from an existing file 120 such as shown in Figure 8 A. This file 120 is a daily record of all non-mon's that were posted. Typical changes required by existing credit-processing systems include additional steps as shown in Figure 8. For example, one step 122 takes the data from the daily update file 120 and creates a file for those records associated with Alias accounts. The file is then be transferred to the bunker for processing 124. Outputs from the bunker, if any, are updates that are input into the next day's cycle, as shown by steps 128 and 126.
Examples of maintenance tasks are as follows:
• Request for a change in Alias Name, Address or the Credit Line for Alias
Account. These changes are preferably performed only on the bunker side. If Host updates the master file and sends a non-mon to the bunker, the bunker preferably sends a non-mon back to the Host to rollback the changes made to the master file. If these changes were first done on the bunker side, then the bunker sends a non-mon to the host to update the Alias account on the host database. Examples of some account management and maintenance tasks are shown in Figure 8B.
• Request to terminate the Alias account by the Cardholder. In this example, the bunker receives a request from the cardholder to terminate the Alias account. In response, the bunker sends a non-mon to notify the host about the same. It also sends non-mons to update the status and credit line of Primary account. • In case of the Primary account, the change of name and address is transferred to the bunker through a file/tape, which the bunker uses to update the database with the new real name and real address.
• Request for a change in the credit line for Primary account. This process is shown in Figure 8B. The Host treats this change as a normal maintenance change for a Normal account. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s). Host updates the credit line for the Primary account and send a non-mon to the bunker to make changes accordingly. The bunker then updates the credit line for the Primary and Alias account as per the Credit Ratio. The bunker will send a non-mon back to the host to the update the Alias account credit line as a part of the next day's cycle. It is noted that the communications between the bunker and the credit processing system is through removable media or a secure network connection, as described above. These connections are depicted in Figure 8B by the reference numerals 127 and 129.
Collections
One method that can be used to process and account that goes into collection is presented follows.
(a) The Host through a non-mon informs the Bunker about the account going into collection.
(b) Bunker generates non-mons to do an AT (Account Transfer) of the Alias account to the Primary account i.e. terminate the Alias account and update the Primary account.
(c) The bunker generates non-mons for putting the Primary account into the working queue and for updating the status of the Primary account.
(d) The host sends a confirmation for AT to the Bunker. The Bunker would then update the corresponding flags on its database. A detailed specific embodiment of a collection method is presented in Figure 8C. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
When an Alias or its Primary account goes into collections the bunker receives notification so that appropriate actions can be taken. The normal procedure when a Alias account goes delinquent will be for the bunker to generate non-mon's combining the two accounts into the Primary account. This will allow the collectors to have access to the information they need to work the account as well as provide proper reporting. The Alias account is preferably closed to prevent its use. In one example, during the nightly collections process, a file is created that contains all the Alias accounts that have gone into collections. Preferably, an agreement with the cardholder specifies that either account going into collections is terms for termination of the Alias account.
Example Bunker Processing. Those Alias accounts that become delinquent and require collections are passed to the bunker. The appropriate non-mons will be generated to combine the two accounts. The non-mons are then added to the file to be transmitted for the next night's cycle.
Example Host Processing. In one example, a special queue is set up to catch the accounts that need to be sent to the bunker. This queue can then be captured and sent to the bunker to be processed. Once the changes have been made to the account they will be placed in a working queue.
Communications
Statements and mailers sent to the cardholder of an Alias account are preferably ether redirected by placing a mailing label over the alias-mailing information or by changing the name and address of the mail piece before it is mailed. By placing a label over the mailing information can create an item that can compromise the anonymity of the cardholder. That is, all the information (Real name, Alias name, Real address and alias address) is available on the mail piece. Accordingly, a preferred method is to change the name and the address before it prints. In this fashion, the only information that is exposed is the real name and address and any other information that is on the mail piece.
For all communications, such as Statements, Plastics and PIN mailers for the Alias Accounts, the host preferably prints information to a file. This file is transferred to the bunker, which replaces the alias name and address with the actual name and address.
Figure 9A depicts a process that can be used to replace the alias name and address to the real name and address before the statement is printed. As shown, to correctly address the statement, the records for Alias accounts are moved into a separate file. This file is then carried to the bunker where the correct name and addresses are changed 136. When this is complete the output tape is then returned to the credit-processing printing facility, where a monthly statement 138 is printed.
Bunker Processing Example. Typically, the bunker will receive three different files for mail processing. The standard statement file is received for Alias accounts. On the statement the alias name and address is overlaid wherever it appears on the statement and the payment coupon. The same is true on the Plastic and PIN mailers. Once the files have been passed they are transmitted back to the credit-processor to be printed and mailed.
Host Processing Example. The statements for the Alias accounts are preferably treated as if they are being printed by an external print shop. The print files for the Alias accounts are separated and sent to the bunker for processing.
When the bunker is finished they are returned and sent to output services for normal printing.
Typically, card and PIN Mailers have strict security requirements placed on them. Generally, an association must certify any facility that handles these items. Anyone that handles these items other than the cardholder and the postal system typically must typically be certified. To make this process as streamline and cost effective as possible a preferred approach is to make use of a facility that has already been certified. In this example, the bunker provides an extract file to such a facility that can be used to change the name and address information on the Alias accounts mailers to be the real name and address. The name on the card will be the alias name. This will allow the cards to be mailed to the correct address. The account number on the mailer will be the matching one on the card so quality assurance of the plastics will still be able to insure that the process is working correctly.
An detailed example of a specific implementation of a statement process is shown in FIG. 9B. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
Figure 9C depicts and example of a plastics process that can be used to emboss alias credit cards. Preferably, there is no major impact on the embossing part of the process. One or more of the input files are preferably flagged to identify the Plastics/Cards associated with an Alias account. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
For the Alias Cards/Plastics, the alias name and address is replaced with the actual ones in order to send the Card to the correct destination. Thus, the host receives this information from the Bunker before sending it for embossing, as shown in Figure 9C.
Payment
Payments are to be handled in a normal manner, that is a manner that is used for normal or standard credit-card accounts. This means that the cardholder will be required to make payment to each account that has a balance. Preferably, there will be no transfer of balance from one account to another to reduce complexity of the system. In one embodiment, the cardholder receives a payment coupon with each statement that will allow them to make payment for that account.
Making payment by check on the alias account poses little chance of compromising the account relationship. Figure 10 depicts a method that can be used for payment of the Alias account. A payment coupon is sent with the monthly statement 150. Only the payment coupon is sent in with the payment 151. The payment coupon has the real name and address on it. This was performed as part of the re-labeling process in the bunker before the statement was mailed, as described above. When the payment arrives at the payment-processing center 152 the payment is credited to the account based on the account number presented on the payment coupon. There are no additional bunker and host processing requirements for this process.
Mail Services
In a preferred embodiment, mail redirection is not the responsibility of the bunker. However, the bunker is typically required to support it. Figure 11A is an example that depicts one method that can be used by the bunker to support mail redirection. As shown, to support mail outside of the bunker, a separate database 162 is provided that can be queried using, for example, the box number assigned to the Alias account. The query returns the correct name and address of to be used. This database 162 is preferably outside of the bunker and is made available via a secure network connection for use by those doing mail redirection.
In one example, the information included in the address subset database 162 is as follows:
• Alias Box Number (Key) • Real Name
• Real Address
The box number is preferably be unique. Further, a special zip code is preferably acquired from the post office to trigger this special handling. The zip code should be assigned to the facility that handles the manual re-labeling process for those items that are captured through special processing. The box number will be generated in the bunker and assigned when the Alias account is built.
Example Bunker Processing. Two extract databases are typically built daily containing information for creating mailing labels. Both extracts contain the real name and address for mailing purposes. One extract is keyed by the box number in the alias address and the other uses the real account number as its key. These two databases can then be loaded on another machine or transmitted to the re- mail facility for use in creating labels.
A detailed example of a specific implementation of a mail redirection process from both the host and bunker perspective is shown in FIG. 11B. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
Figure 12 is a block diagram that depicts an example process flow which shows the type of information flowing in and out of the Bunker receiving point, the Host and the Bunker. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s).
EXAMPLE DATA BASE DESIGN
Figure 13 is an example of database tables that can be used to implement one specific embodiment of the bunker database in accordance with one embodiment of the present invention. This figure is self-explanatory as would be apparent to persons skilled in the relevant art(s). The following tables include details of the various fields shown in the example data base design shown in Figure 13.
It should be noted that this is just one example of database fields that can be used in one example embodiment of the present invention.
Temporary Database 184
Figure imgf000048_0001
Figure imgf000049_0001
Notes:
Fields 2, 3 and 4 comprise the Part 2 of the account requisition form.
Fields 5, 6, and 7 comprise the Part 1 of the account requisition form.
Flag IsNew decides if the Primary account is new or existing.
In case of new account, any part of the requisition form may come first at the bunker. Whichever part arrives first at the Bunker will be stored in the database. The other part of the requisition form will be entered in the database, using the Documen TrackingNumber mentioned on that part.
In case of existing Primary account, Part 2 has to arrive at the bunker, before Part 1. The Primary AccountNumber, will be one of the fields in Part 2, which will be used to obtain Part 1 details from the host. When the Part 1 arrives later, the Temporary Database will be queried based on the Primary AccountNumber, so that the appropriate record can be updated.
Matching Database 180
Figure imgf000049_0002
Figure imgf000050_0001
■ Mail Redirection Database 182
Figure imgf000050_0002
Figure imgf000051_0001
■ Account Block Database 186
Figure imgf000051_0002
■ Issuer Database 188
Figure imgf000051_0003
Additional Notes pertaining to the example embodiment of the Database described above.
Document Tracking Number (DTN) is preferably unique to the issuer and the Cardholder.
In case of new account, the DTN is preferably captured to pass on to the bunker for matching with the alias. The DTN will be stored in some miscellaneous field on the host database.
In case of existing account, the Primary account number should be captured. The DTN will typically not be stored.
The host database will have a method for distinguishing the primary accounts having Alias accounts from those which do not have (regular accounts).
The bunker can request for an account dump based on the Primary account number through a non-mon. Other possible ways could be to delete and recreate an existing account or do an account transfer.
The Alias name file would just have the DTN and the alias name. Other details like the mother's maiden name etc. would be taken from the Part 1 of the application or from the existing account.
Part two of the application would be keyed in through a user interface on the bunker side. The issuer would process part one of the application.
The credit investigation will be done on the host side, before starting the bunker processing.
Credit line is split between the 2 accounts by the bunker (assumed to be predefined, either cardholder specific or issuer specific.)
The bunker would have the information about the split in the credit line stored in a control file. For Primary and Alias Card/Plastic, embossing comes separately.
Separate card carriers will be used to mail them. The Temporary Database on the bunker side will contain only such records for which Alias accounts are to be created.
When a Alias account goes into collections it is terminated and its details are combined into the Primary account, which is then sent for collections. The decision of terminating the Primary account will be taken by the issuer.
Updates to a Alias account may include change of alias address or a request to stop the Alias account by the user.
The Alias Box number and the special zip code in the alias address cannot be modified by the cardholder. The bunker process, in some critical conditions can modify it.
In case a credit limit changes in the Alias account, it would be transferred to the bunker since a Alias account is treated as a normal account by the host. The bunker will then change the limit back to the original limit.
Credit limit of a Alias Account can be changed only by changing the limit of its Primary Account. The bunker would then re-adjust the limit of the Alias account and create non-mons for updating both on the host side.
The bunker would issue the Alias account number by selecting a number from the block of available numbers.
If a Cardholder wishes to update the real address, it will first be updated on the host and then the same change will be incorporated in the Mail Redirection
Database on the bunker side.
Audit log would be generated for all the file transfers on bunker as well as host to ensure that all files sent by one are received by the other.
If a primary account no longer has a Alias account, the database on the host will be modified accordingly, to reflect the same.
The Matching Database will have a field to indicate the last modification date/time for every account. The Temporary Database on the bunker side will be purged after creating the Alias accounts in it.
■ There would be flags to indicate the active/inactive statuses of Primary and Alias accounts on the bunker side. Whenever any account is to be terminated the corresponding flag would be set to false implying inactive. Additionally, there would be a flag to indicate if a non-mon has been generated for that inactive account.
If one account goes into collections, the bunker will be informed about the same. Bunker would then generate a non-mon to do an account transfer of Alias account to Primary account. The host would then put the Primary account into the working queue.
■ The format of transferring the files from host to bunker can be anything but from bunker to host, it has to be in the format which the host can understand without changes to the existing system.
The issues to be considered while creating the Temporary Database are following:
The Part 1 of the application may come before the part 2 of the application.
Therefore Part 1 of the application needs to be stored in the Temporary
Database. The Part 1 may be received much later than Part 2, even after weeks.
Part 1 may not be received at all.
The statements printed for the Alias account would have only the name and address replaced.
Out of the three I-files only the file containing the embossing details will be affected in case of embossing.
In case of the statement generation activity, the Alias Account number will not be replaced along with the alias name, address. The acquisition function will generate an error log to inform the operator that the account block for a particular issuer is over. So to be able to create a new Alias account, the operator should increase the block limit.
■ The name and the alias address will also be stored in the Bunker database. This is required, because if a request comes from the host to change the alias name and address, there has to be some way of finding the old name and address to compare it with. Since the request has come from the host, the host database already has the new values. Hence to restore the old values, they need to be stored in the Mail Redirection Database.
■ After deactivating the Alias account, the host should send an Account Transfer confirmation to the bunker.
If a cardholder wants a Alias account for the second time, i.e. after having closed the previous Alias account, a new record will be added to the Mail Redirection Database.
In case of changes to the alias name and address from the operator, a new record will be added to the Mail Redirection Database.
There would be background process or a scheduler running on the bunker side to compare the system date with the ActiveDate in the Issuer Database. This scheduler will trigger the bunker processing based on the system date in addition to the Bunker Receiving.
Kid Card Example Embodiment
The following is a description that depicts one example embodiment of the present invention. While this particular Kid Card embodiment is fully capable of attaining the above described features and benefits of the present invention, it is to be understood that the Kid Card embodiment represents a presently preferred embodiment of the invention and, as such, is merely a representative of the subject matter that is broadly contemplated by the present invention. It is further to be understood that the scope of the present invention fully encompasses embodiments other than the Kid Card and that the scope of the present invention is not limited by the following example embodiment.
In a preferred embodiment, the Kid Card is a credit or debit card that makes limited purchasing power available to children. Preferably, the transactions performed with the Kid Card are anonymous, and the products available for purchase with the Kid Card are subject to parental control. In one embodiment, children are guided through the shopping experience by the Web pages supplied by the hosting entity.
Anonymity
In a preferred embodiment, the transactions performed with the Kid Card are anonymous. For example, a child that purchases an item over the Internet uses the Kid Card to pay for the item. When real time approval is sought by the entity processing the transaction, rather than using true identity data to authenticate the transaction, an alias set of information is used as described above. This alias set of information is compared to an offline secure database in the bunker that compares the alias information to the true identity data and authenticates the transaction. In this example, the true identity of the purchaser is thus never compromised and therefore never available to the processing company for inclusion on a demographic list.
Parental Control
In one embodiment, parents can put restrictions on the types of items that the
Kid Card may purchase. For example, the authenticating database might be configured to allow the purchase of only Typel and Type2 items. Thus, if a child attempted to purchase a Type3 item such as adult content material or a Tommy Gun, the transaction would be denied.
Alternatively, the parental control can take the form of restrictions on the products that are available for purchase. For example, a group of parents who have created a Web page can offer the Kid Card. In this example embodiment, the group controlling the content of the Web page additionally controls product availability by selecting the items that are available for purchase by children.
Yet another example of parental control is based on a password scheme. In this embodiment, the service provider requires a password from the child before allowing the child to enter the shopping area. Based on that password and input the service provider has received from the parents, the products available to the child for purchase are filtered. Thus, the parents have control over what items are made available to their children by creating a shopping profile. Such a profile could be generated, for example, as part of the application process for the Kid Card.
ISP Guide
In a preferred embodiment, the Internet Service Provider ("ISP") acts as the guide to the children's shopping experience. For example, the ISP could be America On Line ("AOL") or any other provider. Alternatively, the entity providing the Kid Card service could be a web page and not an ISP at all. However, for simplicity in the example, AOL will be used as both the ISP and the entity providing the Kid Card service.
In this example, AOL is the ISP. Additionally, AOL hosts a special "kids only" shopping area. The kids only shopping area may be accessible only with an additional password. The additional password could be assigned, for example, as part of the application process for the Kid Card. Because the kids only shopping area is within AOL, AOL is able to create the flow of the pages available to the children as they shop. Therefore, in this example, AOL guides the shopping children through the online store, displaying whatever advertisements and marketing materials deemed appropriate by AOL.
Credit/Debit Cards
In one embodiment, the Kid Card can be a credit card with a predetermined limit. Alternatively, the Kid Card can be a debit card with an available balance that has been paid in advance. For example, the application process for the debit Kid Card might require that a certain amount of money be prepaid on the debit Kid Card to cover any future purchases made with the card. In this example, when the funds are used up, the debit Kid Card no longer allows the purchase of goods. Additional funds must be paid to replenish the purchasing power of the Kid Card and allow the child to purchase additional goods.
Alternatively, in the credit card embodiment, the Kid Card can purchase items up to a certain monetary limit. For example, if the credit limit was $200.00 then purchases equaling that amount can be made before payment is required.
Additionally in this example, bills must be sent out by the company providing the Kid Card shopping service.
Prepaid Gift Cards
A feature of one embodiment is the availability of prepaid gift cards. These cards operate on the same principle as a debit card or a prepaid phone card. For example, a parent could purchase a Kid Card for $200.00 and give it as a gift to a child. The child is then able to purchase $200.00 worth of goods with the Kid Card. The difference in this example embodiment is that when the funds are exhausted on the gift Kid Card, the level of funds cannot be replenished.
Disguised Mailing Feature
As stated, it is often desirable to protect the identity of consumers when ordering merchandise over the telephone, Internet or by any other means, when said merchandise is to be shipped to the residence or business of the consumer. The present invention provides a means for a consumer to order merchandise without revealing their true address to the merchant and/or shipper.
Figure 14 is a schematic diagram that depicts one embodiment of the disguised mailing feature in accordance with one embodiment of the present invention. As shown a cardholder 200 having an alias account, as described above, makes a purchase from a merchant 202. The purchase can be over the telephone, over the Internet or any other computer network, or via any other means available. The merchant uses the alias address associated with the alias account, as described above, to ship the package. In one embodiment, this alias address is a warehouse or the like, referred to herein as the disguised mailing center (DMC). Typically, a bin number associated with the Alias account is used to store the package in a specific location within the DMC. For example the Alias box number shown in the Mail Redirection data table 182, above, can be used for this purpose. The Alias box number is then used to generate a subscriber information request to the offline database to retrieve the true mailing address of the consumer.
Once this address is obtained, the package is re-labeled with the true address and sent to the consumer 208. Preferably, this takes place within twenty-four hours to avoid any further delays to the consumer.
In case of returns, the consumer is provided with a mailing label that sends the package directly back to the merchant 202. Preferably, the return address printed on the return label will be that of the DMC 204.
Alternatively, in a preferred embodiment, the re-labeling process takes place by the shipper in transit. For example, the shipper can contact a server 22, which contacts the offline database with a request for address information. The shipper can then re-label the package with the true address while the package is in transit, and thereby eliminate any extra delays.
Figure 15 is a flow chart that depicts a process that can be used to re-label packages in accordance with one embodiment of the present invention as described above. First, as shown by step 250, the consumer orders a product using an anonymous transaction technique in accordance with the present invention as described above. Accordingly, the user typically, uses an credit or debit card associated with an Alias account to purchase the merchandise.
Next as indicated by step 252, the merchant mails the package (or directs a shipper to mail the package), to the Alias address. In one embodiment, the Alias address is a warehouse or a location referred to as a disguised mailing center
(DMC). Next, as indicated by step 256, the bin number (or set of characters) is input into a re-labeling system. In one example embodiment, the bin number is a unique set of characters which is used to correlate an anonymous name/address (i.e. pseudonym) with a real name/address. The bin is read into the system by scanning in a bar code or the like that comprises the bin. Alternatively, this information can be hand-keyed into the system. In any case, this action generates a request to a server that in turn contacts the bunker for the true address of the consumer. Once this information is retrieved, the package is re-labeled with the true address, as indicated by step 258. Finally, as indicated by step 260, the package is shipped to the consumer in accordance with consumer preferences (i.e. overnight, no signature necessary, etc.).
A second example of a method that can be used to re-label packages is depicted by the process flowchart in Figure 16. As indicated by step 264, the consumer orders a product from a merchant using an anonymous transaction technique as described above. As described above, package is shipped using the Alias address associated with the account. Next, as indicated by step 268, the shipper issues a request to the bunker for the true address of the consumer. This is accomplished in a manner as described above, typically through a server 23. Again, the Alias address or bin number in this example, is used to identify the consumer.
Next, as indicated by step 270, the shipper receives the true address of the consumer and re-labels the package with that address, as shown by step 272. Finally, as indicated by step 274, the package is shipped to the consumer in accordance with consumer preferences (i.e. overnight, no signature necessary, etc.).
In a third embodiment, the anonymous mailing is accomplished by mailing the merchandise to post office box, which is rented by the credit card processing company, on behalf of the cardholder. The address associated with the cardholder alias name is the post office box assigned to the cardholder. In one embodiment, the post office box is as close geographically, to the actual address of the cardholder. In this example embodiment, the cardholder picks up the merchandise from the post office box in person. While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation.

Claims

CLAIMS WHAT IS CLAIMED IS:
1. A method of accommodating anonymous transactions between two or more parties, the method comprising the steps of: receiving an electronic communication from a first party, said electronic communication identifying a second party to a transaction between said first party and said second party, wherein said identification of said second party is an alias such that said second party need not reveal their true identity to said first party to conduct said transaction; using said identification received from said first party to retrieve data that is related to said second party and material to said transaction; analyzing said retrieved data to determine whether to authorize said transaction; and providing an indication to said first party as to whether said transaction is authorized.
2. The method of claim 1, wherein said second party is a child under the age of majority.
3. The method of claim 1, wherein said electronic communication further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said first party.
4. The method of claim 1, wherein said electronic communication further comprises a PIN.
5. The method of claim 1, wherein said first party is a service provider, and wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
6. The method of claim 1, wherein said retrieved data comprises at least one of personal or business information.
7. The method of claim 6, wherein said business information comprises financial information relating to said second party.
8. The method of claim 1, further comprising the step of confirming receipt of said electronic communication received from said first party.
9. The method of claim 1 wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication system.
10. The method of claim 9, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication system.
11. The method of claim 1, further comprising the step of confirming receipt of said electronic communication received from said first party.
12. The method of claim 1, wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication system.
13. The method of claim 12, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication system.
14. A system of accommodating anonymous transactions between two or more parties, comprising: means for receiving an electronic communication from a first party, said electronic communication identifying a second party to a transaction between said first party and said second party, wherein said identification of said second party is an alias such that said second party need not reveal their true identity to said first party to conduct said transaction; means for retrieving data related to said second party and material to said transaction, said retrieval based on said identification received from said first party; means for analyzing said retrieved data to determine whether to authorize said transaction; and means for providing an indication to said first party as to whether said transaction is authorized.
15. The system of claim 14, wherein said second party is a child under the age of majority, further comprising means for allowing parental restrictions on the types of transactions performed.
16. The system of claim 14, wherein said electronic communication further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said first party.
17. The system of claim 14, wherein said electronic communication further comprises a PIN.
18. The system of claim 14, wherein said first party is a service provider, and wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
19. The system of claim 14, wherein said retrieved data comprises at least one of personal or business information.
20. The system of claim 19, wherein said business information comprises financial information relating to said second party.
21. The system of claim 14, further comprising means for confirming receipt of said electronic communication received from said first party.
22. The system of claim 14 wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication system.
23. The system of claim 22, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication system.
24. A server system for accommodating anonymous transactions between two or more parties, comprising: at least one processor; at least one database accessible by said processor; computer program code executable by said processor and configured to accommodate anonymous transactions between two or more parties, said computer program code comprising computer program code means for receiving an electronic communication from a first party, said electronic communication identifying a second party to a transaction between said first party and said second party, wherein said identification of said second party is an alias such that said second party need not reveal their true identity to said first party to conduct said transaction; computer program code means for retrieving data from said database, wherein said data is related to said second party and material to said transaction, said retrieval based on said identification received from said first party; computer program code means for analyzing said retrieved data to determine whether to authorize said transaction; and computer program code means for providing an indication to said first party as to whether said transaction is authorized.
25. The system of claim 24, wherein said second party is a child under that age of majority.
26. The system of claim 24, wherein said electronic communication further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said first party.
27. The system of claim 24, wherein said electronic communication further comprises a PIN.
28. The system of claim 24, wherein said first party is a service provider, and wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
29. The system of claim 24, wherein said retrieved data comprises at least one of personal or business information.
30. The system of claim 29, wherein said business information comprises financial information relating to said second party.
31. The system of claim 24, further comprising computer program code means for confirming receipt of said electronic communication received from said first party.
32. The system of claim 24, wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication system.
33. The system of claim 32, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication system.
34. A method of accommodating anonymous transactions between two or more parties, the method comprising the steps of: receiving at a terminal an identification of a party to said transaction, wherein said identification is an alias, enabling said party to enter into said transaction anonymously; transmitting said identification of said party electronically to an information hub for authentication of said transaction; said communication hub receiving said electronic transmission from said terminal, said electronic transmission including said party identification; using said identification received from said terminal to retrieve data that is related to said party and material to said transaction; analyzing said retrieved data to determine whether to authorize said transaction; and providing an indication to said terminal as to whether said transaction is authorized without revealing a true identification of said second party.
35. The method of claim 34, wherein said party is a child under the age of majority.
36. The method of claim 34, wherein said transaction is paid for with a credit card.
37. The method of claim 34, wherein said transaction is paid for with a debit card.
38. The method of claim 34, wherein said transaction is paid for with a prepaid gift card.
39. The method of claim 34, wherein said terminal receives said identification of said party via keypad entry or via computer readable media.
40. The method of claim 34, wherein said electronic transmission further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said first party.
41. The method of claim 34, wherein said electronic transmission further comprises a PIN.
42. The method of claim 34, wherein said transaction is being conducted with a service provider, and wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
43. The method of claim 34, wherein said retrieved data comprises at least one of personal or business information.
44. The method of claim 67, wherein said business information comprises financial information relating to said party.
45. The method of claim 34, further comprising the step of confirming receipt of said electronic communication received from said terminal.
46. The method of claim 34 wherein said electronic communication from said terminal is received via a communication link and wherein said communication link comprises at least one of a public or a private communication system.
47. The method of claim 46, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication system.
48. The method of claim 34, wherein said electronic transmission is generated using at least one of a graphical user interface or a client integration subsystem.
49. The method of claim 34, further comprising the step of storing data from said electronic transmission in a database local to said terminal.
50. The method of claim 34, further comprising the step of applying a digital signature and electronic encryption to said electronic transmission.
51 A system for accommodating anonymous transactions between two or more parties, the method comprising the steps of: means for receiving at a terminal an identification of a party to said transaction, wherein said identification is an alias, enabling said party to enter into said transaction anonymously; means for transmitting said identification of said party electronically to an information hub for authentication of said transaction; means for said communication hub receiving said electronic transmission from said terminal, said electronic transmission including said party identification; means for using said identification received from said terminal to retrieve data that is related to said party and material to said transaction; means for analyzing said retrieved data to determine whether to authorize said transaction; and means for providing an indication to said terminal as to whether said transaction is authorized without revealing a true identification of said second party.
52. The method of claim 51 , wherein said party is a child under the age of majority.
53. The system of claim 51, wherein said terminal receives said identification of said party via keypad entry or via computer readable media.
54. The system of claim 51, wherein said electronic transmission further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said first party.
55. The system of claim 51 , wherein said electronic transmission further comprises a PIN.
56. The system of claim 51 , wherein said transaction is being conducted with a service provider, and wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
57. The system of claim 51, wherein said retrieved data comprises at least one of personal or business information.
58. The system of claim 57, wherein said business information comprises financial information relating to said party.
59. The system of claim 51 , further comprising means for confirming receipt of said electronic communication received from said terminal.
60. The system of claim 51, wherein said electronic communication from said terminal is received via a communication link and wherein said communication link comprises at least one of a public or a private communication system.
61. The system of claim 60, wherein said communication link comprises at least one of the roup of the Internet, the PSTN, or a pre-existing public communication system.
62. The system of claim 51, wherein said electronic transmission is generated using at least one of a graphical user interface or a client integration subsystem.
63. The system of claim 51 , further comprising means for storing data from said electronic transmission in a database local to said terminal.
64. The system of claim 51, further comprising means for applying a digital signature and electronic encryption to said electronic transmission.
65. A method of accommodating anonymous transactions between two or more parties, the method comprising the steps of: a first party to a transaction receiving an identification of a second party to said transaction, wherein said second party identification is an alias, enabling said second party to enter into said transaction anonymously; said first party causing said identification of said second party to be transmitted electronically to an information hub for authentication of said transaction; said communication hub receiving said electronic transmission from said first party, said electronic transmission including said second party identification; using said identification received from said first party to retrieve data that is related to said second party and material to said transaction; analyzing said retrieved data to determine whether to authorize said transaction; and providing an indication to said first party as to whether said transaction is authorized without revealing a true identification of said second party.
66. The method of claim 65, wherein said second party is a child under the age of majority.
7. An anonymous transaction system, comprising: an anonymous transaction card having encoded thereon a machine readable identification of said holder, said machine readable identification being other than an actual identification of said holder; a service provider terminal configured to accept said anonymous transaction card, to read said machine readable identification, and to transmit said identification via electronic communication to an authorization database; and an authorization database configured to use said machine readable identification to retrieve data that is related to said holder and material to said transaction, analyze said retrieved data to determine whether to authorize said transaction, and provide an indication to said service provider as to whether said transaction is authorized.
68. The anonymous transaction system of claim 67, wherein said transaction card comprises at least one of the group of a debit card or a credit card.
69. The anonymous transaction system of claim 67, wherein said encoded label comprises at least one of the group of a bar-code label or a magnetic strip.
70. The anonymous transaction system of claim 67, wherein said anonymous transaction card further comprises a human readable identification of a holder of said anonymous transaction card, said human readable identification being other than an actual identification of said holder.
71. The anonymous transaction system of claim 67, wherein said electronic communication further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said service provider.
72. The anonymous transaction system of claim 67, wherein said electronic communication further comprises a PIN.
73. The anonymous transaction system of claim 67, wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
74. The anonymous transaction system of claim 67, wherein said retrieved data comprises at least one of personal or business information.
75. The anonymous transaction system of claim 50, wherein said business information comprises financial information relating to said holder of said anonymous transaction card.
76. The anonymous transaction system of claim 67 wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication system.
77. The anonymous transaction system of claim 76, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a preexisting public communication system.
78. The anonymous transaction system of claim 77, further comprising an alias identification card identifying said holder of said anonymous transaction card as the owner of said anonymous transaction card.
79. An anonymous transaction card, comprising: a human readable identification of a holder of said anonymous transaction card, said human readable identification being other than an actual identification of said holder; an encoded label on said card having encoded thereon a machine readable identification of said holder, said machine readable identification being other than an actual identification of said holder; wherein said machine readable identification is configured to be read by a service provider terminal and transmitted via electronic communication to a database; and herein said database is configured to use said machine readable identification to retrieve data that is related to said holder and material to said transaction, analyze said retrieved data to determine whether to authorize said transaction, and provide an indication to said service provider as to whether said transaction is authorized.
80. The anonymous transaction card of claim 79, wherein said transaction card comprises at least one of the group of a debit card or a credit card.
81. The anonymous transaction card of claim 79, wherein said encoded label comprises at least one of the group of a bar-code label or a magnetic strip.
82. The anonymous transaction card of claim 79, wherein said electronic communication further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said service provider.
83. The anonymous transaction card of claim 79, wherein said electronic communication further comprises a PIN.
84. The anonymous transaction card of claim 79, wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
85. The anonymous transaction card of claim 79, wherein said retrieved data comprises at least one of personal or business information.
86. The anonymous transaction card of claim 85, wherein said business information comprises financial information relating to said holder of said anonymous transaction card.
87. The anonymous transaction card of claim 79 wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication card.
88. The anonymous transaction card of claim 87, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication card.
89. The anonymous transaction card of claim 79, further comprising an alias identification card identifying said holder of said anonymous transaction card as the owner of said anonymous transaction card.
90. A method for conducting an anonymous transaction involving a payment from a first party to a second party, the method comprising the steps of: first party accepting a payment from a second party in the form of an anonymous transaction card, said anonymous transaction card identifying said second party by other than said second party's actual identification; receiving an electronic communication from said second party, said electronic communication identifying said first party to said transaction between said first party and said second party, wherein said identification of said second party is an alias such that said second party need not reveal their true identity to said first party to conduct said transaction; using said identification received from said first party to retrieve data that is related to said second party and material to said transaction; analyzing said retrieved data to determine whether to authorize said transaction; and providing an indication to said first party as to whether said transaction is authorized.
91. The method of claim 90, wherein said anonymous transaction card comprises an encoded label having machine readable identification of said second party, said machine readable identification being other than an actual identification of said second party
92. The method of claim 91, wherein said encoded label comprises at least one of the group of a bar-code label or a magnetic strip.
93. The method of claim 90, wherein said anonymous transaction card further comprises a human readable identification of a second party of said anonymous transaction card, said human readable identification being other than an actual identification of said second party.
94. The method of claim 90, wherein said anonymous transaction card comprises at least one of the group of a debit card or a credit card.
95. The method of claim 90, wherein said electronic communication further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said service provider.
96. A system for conducting an anonymous transaction involving a payment from a first party to a second party, the system comprising the steps of: means for accepting a payment from a second party in the form of an anonymous transaction card, said anonymous transaction card identifying said second party by other than said second party's actual identification; means for receiving an electronic communication from said second party, said electronic communication identifying said first party to said transaction between said first party and said second party, wherein said identification of said second party is an alias such that said second party need not reveal their true identity to said first party to conduct said transaction; means for using said identification received from said first party to retrieve data that is related to said second party and material to said transaction; means for analyzing said retrieved data to determine whether to authorize said transaction; and means for providing an indication to said first party as to whether said transaction is authorized.
97. The system of claim 96 wherein said anonymous transaction card comprises an encoded label having machine readable identification of said second party, said machine readable identification being other than an actual identification of said second party
98. The system of claim 97, wherein said encoded label comprises at least one of the group of a bar-code label or a magnetic strip.
99. The system of claim 96, wherein said anonymous transaction card further comprises a human readable identification of a second party of said anonymous transaction card, said human readable identification being other than an actual identification of said second party.
100. The system of claim 96, wherein said anonymous transaction card comprises at least one of the group of a debit card or a credit card.
101. The system of claim 96, wherein said electronic communication further comprises transaction information, said transaction information including at least one of the group of transaction date, transaction time, transaction amount, transaction type, or an identification of said service provider.
102. The system of claim 96, wherein said electronic communication further comprises a PIN.
103. The system of claim 96, wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
104. The system of claim 96, wherein said retrieved data comprises at least one of personal or business information.
105. The system of claim 104, wherein said business information comprises financial information relating to said second party of said anonymous transaction card.
106. The system of claim 96 wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication card.
107. The system of claim 106, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication card.
108. The system of claim 96, wherein said electronic communication further comprises a PIN.
109. The system of claim 96, wherein said service provider comprises at least one of the group of vendors, merchants, wholesalers, retailers, or e-commerce providers.
110. The system of claim 96, wherein said retrieved data comprises at least one of personal or business information.
111. The system of claim 110, wherein said business information comprises financial information relating to said second party of said anonymous transaction card.
112. The system of claim 96 wherein said electronic communication is received via a communication link and wherein said communication link comprises at least one of a public or a private communication card.
113. The system of claim 112, wherein said communication link comprises at least one of the group of the Internet, the PSTN, or a pre-existing public communication card.--
114. A method for protecting anonymity of a consumer when ordering merchandise to be delivered to the consumer, the method comprising the steps of: ordering merchandise using an alias credit or debit card, wherein the alias credit or debit card has an associated pseudonym and an associated true name and address of the consumer; shipping the merchandise using the pseudonym, wherein the pseudonym includes an address associated with a disguised mailing center (DMC); communicating the pseudonym to an offline database comprising the true name and address associated with the pseudonym; retrieving the true address; re-labeling the merchandise with the true address; and shipping the merchandise from the DMC to the true address.
115. The method of claim 114, wherein the pseudonym comprises an alias address.
116. The method of claim 114, wherein the pseudonym further comprises an alias name.
117. The method of claim 114, further comprising the step of re-labeling the merchandise with the true name.
118. The method of claim 114, wherein said communicating step comprises the steps of: generating a request for subscriber information to a central server; processing the request at the central server; sending the request from the central server to the offline database; receiving a response from the offline database at the server; and sending the response from the server to the DMC.
119. The method of claim 114, wherein the pseudonym includes a bin number.
120. The method of claim 119, wherein the bin number is used as a destination within the DMC.
121. The method of claim 114, wherein the pseudonym is automatically scanned into a re-labeling system.
122. A method for protecting anonymity of a consumer when ordering merchandise to be delivered to the consumer, the method comprising the steps of: ordering merchandise using an alias credit or debit card, wherein the alias credit or debit card has an associated alias name/address and an associated true address of the consumer; shipping the merchandise using the alias name/address; communicating the alias name/address to an offline database comprising the true address and the alias address; retrieving the true name/address; and re-labeling the merchandise with the true name/address.
123. The method of claim 122, wherein the communicating, retrieving, and relabeling steps are accomplished by the shipper while the merchandise is in transit.
124. The method of claim 123, wherein the communicating step is accomplished by the shipper using a wireless connection to a central server.
125. The method of claim 122, wherein said communicating step comprises the steps of: generating a request for subscriber information to a central server while the merchandise is in transit by the shipper; processing the request at the central server; sending the request from the central server to the offline database; receiving a response from the offline database at the server; and sending the response from the server to the shipper.
126. The method of claim 122, wherein the alias address includes a bin number.
127. The method of claim 122, wherein the alias name/address is automatically scanned into a re-labeling system.
128. A system for protecting anonymity of a consumer when ordering merchandise to be delivered to the consumer, the system comprising: means for ordering merchandise using an alias credit or debit card, wherein the alias credit or debit card has an associated alias name/address and an associated true name/address of the consumer; means for shipping the merchandise using the alias name/address, wherein the alias name/address is a disguised mailing center (DMC); means for communicating the alias name/address to an offline database comprising the true name/address and the alias name/address; means for retrieving the true name/address; means for re-labeling the merchandise with the true name/address; and means for shipping the merchandise from the DMC to the true name/address.
129. The system of claim 128, wherein said means for communicating comprises: means for generating a request for subscriber information to a central server; means for processing the request at the central server; means for sending the request from the central server to the offline database; receiving a response from the offline database at the server; and sending the response from the server to the DMC.
130. The system of claim 128, wherein the alias name/address includes a bin number.
131. The system of claim 130, wherein the bin number is used as a destination within the DMC.
132. The system of claim 128, wherein the alias name/address is automatically scanned into a re-labeling system.
133. A system for protecting anonymity of a consumer when ordering merchandise to be delivered to the consumer comprising: means for ordering merchandise using an alias credit or debit card, wherein the alias credit or debit card has an associated alias name/address and an associated true name/address of the consumer; means for shipping the merchandise using the alias name/address; means for communicating the alias name/address to an offline database comprising the true name/address and the alias name/address; means for retrieving the true name/address; and means for re-labeling the merchandise with the true name/address.
134. The system of claim 133, wherein the means for communicating, retrieving, and re-labeling are performed by the shipper while the merchandise is in transit.
135. The system of claim 133, wherein the means for communicating includes a wireless connection from the shipper to a central server.
136. The system of claim 134, wherein the means for communicating comprises: means for generating a request for subscriber information to a central server while the merchandise is in transit by the shipper; means for processing the request at the central server; means for sending the request from the central server to the offline database; means for receiving a response from the offline database at the server; and means for sending the response from the server to the shipper.
PCT/US2000/010678 1999-04-19 2000-04-19 Improved system and method for anonymous transactions WO2000063855A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU44763/00A AU4476300A (en) 1999-04-19 2000-04-19 Improved system and method for anonymous transactions
AU12169/01A AU1216901A (en) 1999-12-23 2000-10-19 System and method for anonymous transactions and disguised mailings
PCT/US2000/028954 WO2001048628A2 (en) 1999-12-23 2000-10-19 System and method for anonymous transactions and disguised mailings

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
US29427099A 1999-04-19 1999-04-19
US09/294,270 1999-04-19
US32343799A 1999-06-01 1999-06-01
US09/323,437 1999-06-01
US32629899A 1999-06-04 1999-06-04
US09/326,298 1999-06-04
US16554699P 1999-11-15 1999-11-15
US16554799P 1999-11-15 1999-11-15
US60/165,547 1999-11-15
US60/165,546 1999-11-15
US47437899A 1999-12-29 1999-12-29
US47411099A 1999-12-29 1999-12-29
US09/474,378 1999-12-29
US09/474,110 1999-12-29

Publications (2)

Publication Number Publication Date
WO2000063855A1 true WO2000063855A1 (en) 2000-10-26
WO2000063855A9 WO2000063855A9 (en) 2002-01-31

Family

ID=27569099

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/010678 WO2000063855A1 (en) 1999-04-19 2000-04-19 Improved system and method for anonymous transactions

Country Status (2)

Country Link
AU (1) AU4476300A (en)
WO (1) WO2000063855A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001035355A1 (en) * 1999-11-09 2001-05-17 First Data Resources Systems and methods for anonymous payment transactions
WO2002093436A1 (en) * 2001-05-11 2002-11-21 Swisscom Mobile Ag Method for transmitting an anonymous request from a consumer to a content or service provider through a telecommunication network
WO2003001866A1 (en) * 2001-06-27 2003-01-09 Snapcount Limited Transcation processing
US7836121B2 (en) 2004-04-14 2010-11-16 Ipass Inc. Dynamic executable
US10204333B2 (en) 2009-08-19 2019-02-12 Mastercard International Incorporated Location controls on payment card transactions
US11620628B2 (en) 2015-06-30 2023-04-04 Mastercard International Incorporated Method and system for fraud control based on geolocation

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5703344A (en) * 1995-06-30 1997-12-30 Visa International Service Association Electronic funds confirmation at point of transaction
US5815665A (en) * 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US6006200A (en) * 1998-05-22 1999-12-21 International Business Machines Corporation Method of providing an identifier for transactions
WO2000014648A1 (en) * 1998-09-04 2000-03-16 Impower, Inc. Electronic commerce with anonymous shopping and anonymous vendor shipping

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5703344A (en) * 1995-06-30 1997-12-30 Visa International Service Association Electronic funds confirmation at point of transaction
US5815665A (en) * 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US6006200A (en) * 1998-05-22 1999-12-21 International Business Machines Corporation Method of providing an identifier for transactions
WO2000014648A1 (en) * 1998-09-04 2000-03-16 Impower, Inc. Electronic commerce with anonymous shopping and anonymous vendor shipping

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001035355A1 (en) * 1999-11-09 2001-05-17 First Data Resources Systems and methods for anonymous payment transactions
WO2002093436A1 (en) * 2001-05-11 2002-11-21 Swisscom Mobile Ag Method for transmitting an anonymous request from a consumer to a content or service provider through a telecommunication network
US7590547B2 (en) 2001-05-11 2009-09-15 Swisscom Mobile Ag Method for transmitting an anonymous request from a consumer to a content or service provider through a telecommunication network
US8401867B2 (en) 2001-05-11 2013-03-19 Swisscom Ag Method for transmitting an anonymous request from a consumer to a content or service provider through a telecommunication network
US8812328B2 (en) 2001-05-11 2014-08-19 Swisscom Ag Method for transmitting an anonymous request from a consumer to a content or service provider through a telecommunication network
WO2003001866A1 (en) * 2001-06-27 2003-01-09 Snapcount Limited Transcation processing
US8229854B2 (en) 2001-06-27 2012-07-24 Orbiscom Limited Transaction processing
US8639623B2 (en) 2001-06-27 2014-01-28 Orbis Patents Ltd. Transaction processing
US10089618B2 (en) 2001-06-27 2018-10-02 Orbis Patents Limited Transaction processing
US7836121B2 (en) 2004-04-14 2010-11-16 Ipass Inc. Dynamic executable
US10204333B2 (en) 2009-08-19 2019-02-12 Mastercard International Incorporated Location controls on payment card transactions
US11620628B2 (en) 2015-06-30 2023-04-04 Mastercard International Incorporated Method and system for fraud control based on geolocation

Also Published As

Publication number Publication date
AU4476300A (en) 2000-11-02
WO2000063855A9 (en) 2002-01-31

Similar Documents

Publication Publication Date Title
US7264152B2 (en) Anonymous transaction authentication
US20040260653A1 (en) Anonymous transactions
US6675153B1 (en) Transaction authorization system
US7865414B2 (en) Method, system and computer readable medium for web site account and e-commerce management from a central location
US7702578B2 (en) Method, system and computer readable medium for web site account and e-commerce management from a central location
US20060178994A1 (en) Method and system for private shipping to anonymous users of a computer network
US7177830B2 (en) On-line payment system
US7565326B2 (en) Dialect independent multi-dimensional integrator using a normalized language platform and secure controlled access
US8396810B1 (en) Centralized authorization and fraud-prevention system including virtual wallet for network-based transactions
US20010044785A1 (en) Method and system for private shipping to anonymous users of a computer network
US20090293112A1 (en) On-line generation and authentication of items
US20020152180A1 (en) System and method for performing secure remote real-time financial transactions over a public communications infrastructure with strong authentication
US20050178824A1 (en) On-line merchant services system and method for facilitating resolution of post transaction disputes
WO2001048628A2 (en) System and method for anonymous transactions and disguised mailings
US20170337604A1 (en) Method, system and computer readable medium for web site account and e-commerce management from a central location
WO2000063855A1 (en) Improved system and method for anonymous transactions
US8069118B2 (en) Mediated electronic messaging with value-added services
Kravitz Highly scalable on-line payments via task decoupling
KR100485243B1 (en) payment method by on-line account commerce using security system
Pao et al. Security management of electronic data interchange
Hansmann et al. Smart Cards and e-business
FR2821190A1 (en) Electronic management of gifts, vouchers, gift cheques and certificate giving a commercial advantage.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/23-23/23, DRAWINGS, REPLACED BY NEW PAGES 1/18-18/18; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP