CN101563704B - Method and system for identity authentication - Google Patents

Abstract

The Greenlist tool provides a way for a payer wishing to pay a merchant to locate, verify and initiate a transfer of assets to another party by passing a transaction request to a third party acting as a transaction initiator. This task is done without revealing confidential information about the counterparty, while distributing the responsibility for a particular risk outcome to the least-risky undertaker: and (4) banks. Greenlist verifies identity before making financial transactions or before gaining access to restricted information. Greenlist can be fully trusted by the stakeholder. Responsibility for the risk may be transferred to the registry of the information contained in the registry. This risk transfer greatly reduces the cost of the payer to undertake the risk. The third party is responsible for determining that someone or some entity purporting to be an authorized party is not an imposter, and now the third party can provide new levels of service for a variety of transactions at a much cheaper cost.

Description

Method and system for identity authentication

Cross References to Related Applications

This application claims the benefit of US Provisional Application No. 60/733,982, filed November 3, 2005.

technical field

The present invention relates to computer systems and methods for conducting transactions such as payment deposits or for obtaining authenticated access to restricted information without the need for security or encryption devices.

Background technique

In today's rapidly evolving computer-dependent world, people make purchases, payments, deposits, and other financial transactions without the simple act of exchanging traditional money, checks, or even handing a credit or debit card over the counter. Many transactions that people conduct today are done over the phone or the Internet. In order to carry out this transaction, people must submit a unique identifier to have their preferred payment instrument accepted and activated. This identifier includes a person's name, address, credit card number, CVS number, and often includes a PIN or "shared secret" such as a mother's maiden name or the name of a family pet. Identifiers can be quickly spread across multiple credit card company databases, health care databases, mortgage company databases, and online merchant databases. These identifiers may be transmitted over wireless networks or parts of the Internet, which may expose them to the risk of being copied during transmission. These identifiers can be captured by spyware that sends keystrokes on a computer to a thief lurking anywhere in the world.

It is not uncommon in a customer's relationship with a bank, health care provider, insurance company, merchant, or credit card company to require access to account records. This could be to dispute a payment, to prove that a payment was made, to verify an order, or simply to check an account balance. In order to gain access to their records, people must provide their unique identifier information to prove their identity. In certain healthcare situations, only a person's authorized physicians have access to the healthcare provider's database pertaining to their healthcare records.

With numerous in-person and online registrations with various utilities, online merchants, and banks and health care providers, it has become common practice for people to use the same passwords, PINs, and "shared secrets" so that on a given day the Be able to remember what should be served when accessing a particular database. An unintended by-product of this dissemination of a person's unique identifier in so many locations is the emergence of the crime of identity theft. Once weaker links in the chain of trust are broken, fraudsters are able to steal identities and direct unauthorized flows of funds.

Depending on the payment instrument used, this illegal activity may go undetected for days, weeks or even months. In theory, there is no way to alert the true owner of this unique identifier that his or her access information is being gained, since it is assumed that the person gaining access to this information is that owner. Financial harm is not the only kind of harm caused by fraudsters. For example, illegal access to health records could prevent freedom to be employed at work, cancel insurance policies, or restrict movement.

Therefore, there is a need in the art for a simple and convenient system and method for verifying the identity of others without requiring security or encryption devices. There is also a need in the art to notify people when their identity is authenticated, and by whom and for what purpose. In-depth attestation of identity is required involving access to restricted records, such as digital signatures of registries that store the person's unique identifier. Banks and health care organizations need to obtain proof that the correctness of information is protected by liability contracts. Individuals need to be able to know and approve transactions that may involve private aspects of their identities.

The needs that users consider to be addressed are:

· How can I be safely identified on the Internet?

·Who is willing to guarantee to a third party for me?

·Should I be notified when my information is obtained, and by whom and for what purpose?

• How do I know what information about me has been leaked, by what entity, and how their knowledge has been obscured or hidden.

Privacy management is the new industry. Numerous identity registries exist today, and identifiers can be associated between these registries. When these associations occur there needs to be information flow to customers so that they can approve the use of their private identifiers.

This need in the art extends to, but is not limited to, specific interest groups where access to information or approval of transactions involving the transfer of financial or information assets is a substantial element. This is a critical part of the interaction between various users, customers, businesses, agencies, regulators, and/or other stakeholders. These interactions may include validation and authentication for instances such as:

· authorize access to financial, health care, subscription, personal or other information for review purposes;

· Determining the status of the involved identity for shipping and receiving the actual item;

· Determining the appropriate status for the transfer of tokens and access rights for digital products;

· Eligibility to view and print tickets, reservations, airline boarding passes or other electronic documents;

• Used for determination of authenticity of sources when unconcealed or partially obscured but real persons send material for publication or compilation of online repositories such as Wikipedia.

Ultimately, the art needs to reconcile between the public and private parts of the information that is potentially shared. Specifically, there is a need to guarantee access and transactions while maintaining privacy and protecting the identifiers of the information. This includes identifiers suitable for public disclosure, for direct use (such as "one-way" public payment addresses known as Linked Credit Account LCAs, and other types of payment addresses with similar one-way characteristics), or for Indirect use (e.g. only an identifier used solely to initiate the authentication process). Also included are healthcare identifiers used to access an individual's personal healthcare information (PHI), as well as identifiers and related transactions involving other interested parties.

Contents of the invention

It is an object of the present invention to provide a simple and convenient way for individuals and institutions to authenticate identities for transactions to receive payments and credits, or identities in motion to gain access to restricted information.

Another object of the invention is to create a system that accepts authenticated identities without requiring security or encryption means.

Another object of the present invention is to use specific types of identities in conjunction with various accounts to conduct financial transactions or access restricted information.

Another object of the present invention is to utilize specific types of identities in conjunction with various systems or networks for financial transactions or access to restricted information.

Another object of the invention is to use specific types of identities in conjunction with financial systems and networks.

The above and other objects of the present invention will become apparent from the following description.

The identity and transactions enabled by the present invention apply to banks, customer payment addresses, and making and receiving payments; to health care providers, individual health care identifiers, and access to health care information records; and other interested parties whose Respective identity/authentication providers, subscriber identifiers, and transactions with respect to their respective parties. The invention preferably includes the use of ENUM technology to associate telephone numbers with respective identifiers (eg specific payment addresses) in public systems (eg DNS) or in private systems.

In one aspect, the invention includes an Identity Authority serving as a registry for listing identifiers in directories with open and restricted access. This registry is conveniently referred to herein as the "Greenlist". It is designed to be used by third parties to verify identities to conduct financial transactions or gain access to restricted information. Third parties are used as transaction initiators. These entities bear certain risks of negative outcomes when a party is not who they claim to be. A unique feature of the Greenlist Registry (or Directory of Identifiers) is that it can be fully trusted by stakeholders. This trust can be built through certainty. Responsibility for the risk may be transferred to the registry for the information contained in the registry. The transfer of responsibility can greatly reduce the cost of taking risks. A third party, responsible for ascertaining that a person or entity claiming to be an authorized party, is not an imposter, can now provide a new level of service for a variety of transactions at a much lower cost.

Trust in Greenlist can be "built" with digital signatures dictated by liability and fraud prevention contracts. By authorizing their banks to act as registries and provide record access information in an extension of ENUM, the Internet standard method of using telephone numbers in the Internet's domain name system, various entities can define and create their communities of interest. Telephone Number Mapping (TElephoneNUmber Mapping, ENUM or Enum) is a set of protocols that use the indirect query method to unify the telephone number system E.164 with the Internet addressing system DNS to obtain NAPTR records. This record is stored in the DNS database.

In a VoIP environment (telephone calls via the Internet), ENUM has been used in the following way: If the calling party on the PSTN network or the Internet recognizes the called party's ENUM number by the called party's E.164 number, the E.164 The number will be translated to the corresponding URI at the ENUM gateway. This E.164 number will be used to look up and extract the NAPTR record for the URI that indicates the called party's instructions on how the call should be delivered or terminated. The registrant (called party) specifies, for example, an e-mail address in the "NAPTR record" defined in RFC 2915 (replaced by RFC 3403), that is, "Naming Authority Pointer Resource Records (Naming Authority Pointer Resource Records)" and the URI it contains , fax number, personal website, VoIP number, mobile phone number, voice mail system, IP phone address, web page, GPS coordinates, call diversion or instant messaging.

ENUM technology is being used in a range of public or private environments. Records stored in DNS are accessible via public queries. Records stored in a private database utilizing DNS and ENUM technology have controlled access. VoIP is an example of an application that supports ENUM, where the application utilizes ENUM to map phone numbers to URIs for some business, which the application can then use for its business.

The use of ENUM as a directory service structure makes ENUM even more valuable as a public resource. As described in US Patent Application Serial No. 10/786,023, filed February 26, 2004, the Identity Authority, Greenlist, can be accessed directly to obtain public identity information, such as public payment addresses. The present invention includes improvements over the "publicly available" aspects discussed in US Patent Application Serial No. 10/786,023. Greenlist provides each user with web pages that the payer (or other party) can access. Via digital certificates or other authentication methods, different payers of a transaction and exposure initiators may be allowed to view different information (eg, an insurance provider may have access to a social security number). Moreover, the Greenlist operator guarantees that the payee is who it claims to be and that the payment address specified by the payee is true.

Greenlist acts as a virtual safe deposit box where identities can be stored and extracted without data supplementation. Extraction can be done by simple database query conventions. Information that needs to be confirmed as true and guaranteed by a registry entity wishing to transfer the responsibility of the risk bearer can be derived from an outside process as described in US Patent Application Publication No. 2005/0259658, filed August 6, 2005 , or not derived from it. Because identity information can only be removed or modified by the original repository responsible for its accuracy and timeliness, all information can be trusted to be authentic.

Some identity information can only be extracted by members of interest groups only. Owners of the payer's and payee's records are reminded by means of preferences specified at registration (eg, email, fax, voice message, or instant message) when the bank performs the mobile authentication step. Greenlists can be used by different interest groups to initiate authenticated access or authenticated transactions, for example to grant digital rights, to receive goods, or to print documents such as tickets or boarding passes.

In one aspect, the invention includes a system for authenticating a payer and a payee in an electronic funds transfer, the system comprising: a bank computer connected to a payer's computer and a directory computer via a computer network, the said payer has at least one account with said bank and has been authenticated to said bank computer; wherein said directory computer is adapted to maintain a first database of authenticated registrant information, said registrant information including reference to said said payee's authenticated information identified by said payee's at least one associated credit account, said directory computer being further adapted to periodically provide said bank computer via said computer network with said first database a portion of said first database comprising said authenticated information of said payee; wherein said bank computer is adapted to maintain a second database comprising data of said portion of said second database, said second database further comprising ENUM data for registrants in said portion of said first database; and wherein said bank computer is adapted to identify said payee from receiving ENUM information and payment information at said payer computer, utilizing said portion of said first database to map said information identifying said payee to said linked credit account of said payee, and sending payment from at least one account of the payer to an associated credit account of the payee.

In another aspect, the invention includes a method of authenticating a payer in a financial transaction, the method comprising: (a) receiving via a computer network from an authenticated payee having an account with a first bank including associated credit; information of account information and telephone number information; (b) associating said payee's linked credit account information and telephone number information with a URN via said first bank's computer; (c) at the second bank's sending, in communication by the computer, information comprising said telephone number information and said associated URN to a database; and (d) electronically receiving funds from a payer account to said associated credit account.

In another aspect, the invention includes a method of authenticating a payer and a payee in a financial transaction, the method comprising: (a) receiving a payout via a computer network from a payer having an account with a bank and having been authenticated (b) using ENUM to associate said payee's phone number information with said payee's associated credit account information via a computer linked to said computer network; the payer sends verification that the telephone number has been associated with the linked credit account information of the payee; (d) receiving authorization from the payer via the computer network to receive from the payee transfer funds from the payer account to the linked credit account; and (e) electronically transfer the funds from the payer account to the linked credit account.

In another aspect, the invention includes a method of providing authentication, the method comprising: (a) receiving authenticated registrant information, the authenticated registrant information including a registrant telephone number and registrant account information; (b ) storing said registrant account information in an electronic database accessible by a computer in communication with a computer network; (c) associating said registrant information with ENUM data; (d) sending said registrant information to a directory computer; ( e) sending the associated information to the directory user.

In various embodiments: (1) the directory user is a bank; (2) the directory user is a healthcare facility; (3) the registrant account information includes an associated credit account; (4) the associated information includes Personal health care information.

In another aspect, the invention includes a system for authenticating a sender and a recipient of an asset transfer, the system comprising: a bank computer linked via a computer network to the sender's computer and a directory computer, the sender The party has at least one property account with the bank and has been authenticated to the bank computer; wherein the directory computer is adapted to maintain a first database of authenticated registrant information including information on the recipient said recipient's authenticated information identified by at least one associated account of said recipient, said directory computer being further adapted to periodically provide said bank computer via said computer network with a portion of said first database, said Said portion of the first database includes said authenticated information of said recipient; wherein said bank computer is adapted to maintain a second database comprising said portion of said first database from data, said second database further comprising ENUM data for registrants in said portion of said first database; and wherein said bank computer is adapted to receive ENUM data from said sender computer identifying said recipient information and payment information, utilizing said portion of said first database to map said information identifying said recipient to said at least one associated account of said recipient, and from at least one of said sender An account sends an asset transfer to at least one associated account of the recipient.

In various embodiments: (1) the bank is a licensee of the directory computer; (2) the associated account is an identifier of the recipient that can be encoded as a URN; (3) the payment information Including information identifying the recipient; (4) the transfer of assets is actually the transfer of assets or ownership of assets from the sender to the recipient. (5) the asset is a payment or financial instrument; (6) the asset is a digital construct; (7) the asset is one or more physical items; (8) the asset is information, a right, or an access license .

Description of drawings

Figure 1 is a diagram illustrating preferred components of a system embodiment of the present invention;

Fig. 2 shows the preferred main directory recording process;

Figure 3 illustrates the preferred home directory bank setup/maintenance process;

Figure 4 illustrates the preferred master directory record/maintenance process;

Fig. 5 shows preferred bank subsystem Greenlist update process;

Fig. 6 shows preferred Greenlist Internet inquiry process;

Figure 7 illustrates the preferred master LCA account assignment/verification process.

Detailed ways

Figure 1 is a diagram illustrating preferred components of a system embodiment of the present invention. Greenlist100 is a directory group and processing system. Greenlist maintains a database 105 . Banks 110 registered with Greenlist may offer Greenlist subscriptions to customers. The bank 110 maintains its own database 115 .

Greenlist subscribers 120 can choose to use ENUM functionality: Greenlist subscribers are ENUM registrants, banks and Greenlist are responsible for ENUM registration, and the subscriber's phone number (as a domain name) is entered into the domain name system of the Internet represented uniformly by DNS 130. Alternatively, the subscriber's phone number (as a domain name) may be entered into a simulated system, possibly with controlled access (eg, a simulated system for a private ENUM).

Payment (or other) transactions may be conducted by transaction processing system 140 . Transactions may be initiated by an initiator 150 such as a payer, payee, or third party. The originator 150 may (or may not) be a Greenlist subscriber, electing to initiate a transaction with another Greenlist subscriber 120 .

The transaction processing system 140 may discover that the transaction will require the introduction of a Greenlist subscriber 120 or require specific information from the Greenlist subscriber 120 . Examples may include (but are not limited to) the following: Payee may be notified that payment has been received, thereby allowing shipment of purchased goods; Payer's preferred notification method and public payment address may be required to enable Payer to authorize Payer The bank of the bank makes the payment from the linked non-public account.

Transaction processing system 140 may satisfy its information and processing requirements involving Greenlist subscribers 120 by first setting up an ENUM query via DNS 130 using the subscriber's phone number to extract the subscriber's Greenlist identity. The system 140 can then interact with the bank's system 110 as needed. In one example, the bank 110 may interact with the subscriber 120, which is itself the payer, to receive authorization to make the payment.

Once the transaction processing system 140 has fulfilled its information and processing requirements involving Greenlist subscribers 120, which may incorporate ENUM-enabled applications that can query systems such as DNS 130, the transaction processing system 140 can complete the transaction and send Return status notification.

When a subscriber 120 enrolls with Greenlist Bank 110, the subscriber may be assigned one or more identifiers related to a transaction processing system 140 associated with a particular interest group. These identifiers can be public or private. Such identifiers may be encoded as "names" (more formally as Uniform Resource Names). Additionally, such identifiers may be associated with the subscriber's phone number for extraction from DNS 130, or with simulated public or private systems (more formally, by utilizing a NAPTR resource record as expressed in the Terminology section below).

A specific example is the use of a public payment address such as a linked credit account (LCA) that can be retrieved by an ENUM query of DNS using the phone number as a starting point and resulting in a payment transaction facilitated by the Greenlist 100 and the bank 110.

In one aspect, the invention includes elements and functionality that can be grouped into three conceptual layers. The outer layer, the transaction/customer layer, is closest to the /customer. The middle layer, the registry layer, makes the customer a conceptual part of the infrastructure. The innermost layer, the ENUM/Greenlist layer, is the conceptual infrastructure of the system of the present invention.

I. Transaction/customer layer (merchant layer and SME-SMB layer)

For financial transactions, an additional layer, including in one embodiment of the user's bank, seeks to discover verified payment addresses so that money can be sent between banks in a more efficient manner than existing payment models. This is done by querying the Greenlist.

In one embodiment, the user does not need to be aware that any ENUM-enabled directory is being queried, as this is done through the user's bank acting as a proxy. The user simply goes through his bank's online banking portal, which may have a drop-down tab that provides him with a search option to discover his friend's payment address. All users know or care about is a trusting relationship with their personal bank. This act of providing search tools and results implies that payment address verification has been completed and met the bank's requirements. This relationship of trust already exists between the customer and their personal bank before the customer asks their bank to register them with the Identity Bureau.

Users can enroll in mobile authentication features via the Greenlist web portal.

Mobile authentication features include:

a) These features can be activated for the user's existing bank account;

b) these features can be activated for their Agent Greenlist bank accounts when the user maintains their real bank account number with another bank; and

c) In addition to activating strong mobile authentication features, these features can also specify separate receive-only payment addresses.

After the user's registration is completed, it is said that it will be (or has been) "registered" in the Greenlist. It has been "Greenlisted (Greenlisted)".

II. Registry/Banking Layer (Bank Clearinghouse Layer and Healthcare Clearinghouse Layer)

This layer is where multiple links occur. It is the registration, registration, provisioning layer for users. This layer assigns Greenlist account numbers to users registered in the Greenlist to enable them to then make mobile authenticated electronic payments. This layer also functions as an ENMU registrar, or uses the user's existing ENMU registrar on behalf of the user to subsequently provide the user's Greenlist registration information to the user's ENUM domain (maintained by the user's ENUM Tier II provider described below).

Banks can take this additional step for their customers (registrants) when they want their customers to be able to receive electronic payments from others who do business with other banks and are already registered with other Greenlist payment systems. Greenlist Bank may digitally sign the "payload" it provides in the user's ENUM field.

In the event that the user has not registered his phone number for ENUM, the bank may act as an ENUM registrar on behalf of the user, or as a proxy for the user with an existing ENUM registrar. This process registers the user's phone number into "ENUM" and establishes a relationship for the user's ENUM domain to be maintained by the ENUM Tier II provider. Once complete, the Greenlist Bank, either as or via the ENUM Registrar, may provide the user's Greenlist "load" information into the user's ENUM domain maintained by the user's ENUM Tier II provider.

III. ENUM/Greenlist layer

This is the conceptual layer that provides the basic structure of the information. This layer contains the ENUM domain maintained by the user's ENUM Tier II provider and is managed according to standards certified by ENUM CC1 LLC. This layer may also be referred to as the Greenlist root layer, as it contains the Greenlist maintained by Greenlist Bank.

the term

This section explains how certain words are used in this invention.

ENUM is Electronic NUMbering, the IETF protocol described in RFC 3761.

The ENUM subscriber is the assignee of the E.164 number, this assignee agrees to register the E.164 number for insertion and use as a domain name in the Internet DNS, and this assignee's subsequent requests will contain the same E.164 number A specific DNS resource record for associated data populates its ENUM field. This data consists of Uniform Resource Identifiers (URIs), such as network addresses, and each such URI is contained in its own Naming Authority Pointer DNS (NAPTR) resource record. It is these NAPTRs that populate the subscriber's ENUM domain, and it is the subscriber's ENUM Tier II provider that maintains and operates the subscriber's ENUM domain. ENUM subscribers have full control over the provisioning and content of NAPTR resource records in the ENUM domain of E.164 numbers.

An ENUM user is an individual or entity that queries DNS for an E.164 number, usually using an ENUM-supporting application software client or ENUM client to retrieve the DNS resource record associated with the E.164 number. ENUM users will generally only be aware of the application and not of the application's use of ENUM.

The ENUM registry can do many things, but at least it must register the user's phone number with the domain name server/service (DNS). For the purposes of this document, the ENUM Registrar of an ENUM subscriber will be considered the primary point of contact between that ENUM subscriber and the DNS, and will be responsible for handling and coordinating the registration of a phone number for ENUM, the establishment of the ENUM domain for that phone number, and the operation on behalf of the ENUM subscriber. The process of populating the domain with the DNS resource record associated with the phone number.

ENUM registrants are telephone number assignees, ENUM subscribers.

ENMU Tier II Providers are entities that operate ENUM domains for ENUM subscribers within the Internet DNS. ENUM Tier II providers are responsible for maintaining DNS resource records for ENUM subscribers.

An E.164 number is a telephone number that contains the E.164 telephone country code and can be dialed on the public telephone network. "E.164" refers to ITU-T Recommendation E.164, "International Public Telecommunication Numbering Plan". In this context, "telephone number" may be considered to refer to an E.164 number, which is a telephone number for ENUM.

URIs , or Uniform Resource Identifiers are described in RFC 3986. A URI identifies a resource on the Internet. There are two classes of URIs. More common are URLs , Uniform Resource Locators, and identify businesses and locations on the Internet, for example, http://www.paymentpathways.com . The other is used as a name, URN , the Uniform Resource Name. The ENUM protocol allows an ENUM subscriber to associate the ENUM subscriber's phone number with a URI for end-user retrieval from DNS. Typically, such URIs can be used to provide specific business-related contact information that can be found on business cards, including e-mail addresses, web pages, and SIP addresses for VoIP phone calls. URNs have been used in a range of other types of applications, including identifying publications by encoding International Standard Book Numbers (ISBNs) in public systems, and for transmitting financial information by encoding World Interbank Financial Telecommunication (SWIFT) addresses in private systems. information.

ENUM services are protocol elements in the ENUM protocol, which describe Internet-based services that can use URIs.

NAPTR is a Naming Authority Pointer DNS Resource Record described in several RFCs. ENUM uses NAPTR records. Each NAPTR record is identified by the ENUM domain name of the telephone number. Each NAPTR record contains a URI along with its ENUM transaction.

The ASP is the Application Service Provider and is generally responsible for specific URIs involving ENUM subscribers. For example, an ENUM subscriber may have a home page on the network maintained by a particular ASP. The URI of the web page (in other words, the HTTP address of the page) can be entered into the NAPTR in the ENUM domain of the ENUM subscriber. Then as a result, the ENUM user can look up the subscriber's phone number and retrieve the address of the subscriber's home page.

Greenlist is an identity bureau described here that enables third parties to verify identities for financial transactions or to gain access to restricted information. There is an enrollment process for entering identities into the Greenlist.

The Greenlist Registry maintains the Greenlist database and maintains appropriate relationships with:

1) ENUM registrant: agent, register the phone number of the Greenlist registrant into ENUM;

2) ENUM level II supplier: agent, manages the ENUM domain of the Greenlist registrant, and fills the registrant's NAPTR record into ENUM;

3) GreenList registrant ASP: Agent, assigns the GreenList payment address of the registrant, and creates the content of NAPTR; and

4) GreenList ENUM agent: agent, has a contract (responsibility transfer) relationship with the GreenList registrant. The purpose of this relationship is to deliver the content of NAPTR, the "signed" public payment address (accompanied by the bank account) to the ENUM domain of the enrollee, so that this public payment address can be accessed by persons with access to ENUM. The digital "signature" originating from the bank's public payment address is a guarantee that a properly "signed" ENUM record can be truly trusted to be true.

The Greenlist enrollment process is the process of selecting entities with identities entered into the Greenlist.

The Greenlist registration process is carried out by ENUM registrants who enter their numbers into ENUM.

The ENUM query procedure is to issue a DNS query for a phone number using the ENUM protocol and, if one exists, receive as a result a NAPTR resource record associated with that phone number.

The transaction identity authentication process is the process of verifying the identity, using ENUM to retrieve the public Greenlist information related to the phone number, and then accessing the dedicated Greenlist to authenticate the identity.

Linked credit accounts can be bank accounts designed to filter most or all debit ACH instructions. Linked credit accounts are linked to normal checking accounts, and the owner can instruct their bank on how often the involved funds are "swept" into their traditional bank account, which may or may not be located at the same institution as the LCA within the same institution. When the Greenlist is used to resolve certain public identifiers to locate secure public payment addresses, the Greenlist functions as a portal that only allows funds to move in one direction, thereby creating a one-way account. No one but the customer can withdraw funds from the linked credit account. Any account with a system that supports debits and credits can be modified by treating it as not debitable or as filtered to the point where only a few approved entities can debit it. This means that even phone accounts can be safely changed to support receiving credit (funds) by adding a layer of protection to the direction in which funds may flow that is a linked credit account that has essentially a one-way-like character.

Greenlist licensees are also referred to herein as Greenlist member banks .

Main directory

This section describes the concept and working of the home directory, including:

· Process description and

· Data, edit and query.

Following the associated credit account and associated messaging is the Greenlist Master Directory ("GMD"). Greenlist is the authoritative address book (eg, UPIC, IBAN, UID, etc.) In addition to having its own LCA or UPIC account number listed for receiving funds transfers, GMD Providers may make fund transfers to EPN UPIC, UID account number destinations or LCAs located in EPN and/or non-EPN affiliated banks etc. Common to all forms of affiliated credit merchants is the requirement that the FDIC-insured bank (or the bank's appropriate designated agent) must send at least a Greenlist ID# to the master Greenlist directory accessible from the Internet. Because the associated credit account number and UPIC are only credit deposits, the account number can be safely and publicly disclosed. The Greenlist master directory is the preferred method of disclosing this information.

Characteristics of a home directory include:

· Publicly available and Internet-accessible master directory of payee (biller) accounts;

· Deploy functionality on the network as a separate entity or with an embedded link with a pointer to the bank's home banking portal software;

Web-enabled and provides a user interface for retrieving bank member data using standard web-based search technologies (e.g., Google);

· The GMD supplier is the only authorized public of the identified LCA account;

Contains the payee's payment receiving response notification preference information;

· The main directory is designed to be synchronized with all local independent bank Greenlist directory facilities;

· In addition to providing a repository for LCA account information, provide a repository for UPIC customer information;

Maintain a high degree of security in relation to preventing data alteration and misdirection/interception of funds;

- Provides a repository with TripleDES key pair information from an authoritative TripleDES root server source (TBD).

Main directory process description

This section describes the process involving the home directory (see Figure 2), namely:

• Create a new bank member record in the authorized Greenlist bank principal (see Figure 3).

• Modify bank member records in the authorized Greenlist bank entity (see Figure 3).

• Invalidate the bank member record in the authorized Greenlist bank entity (see Figure 3).

• Provides an update mechanism to the Greenlist master directory (see Figure 4).

• Provide nightly updates to/from the member bank directory subsystem (see Figure 5).

• Provides Internet search functionality to the Greenlist master directory (see Figure 6).

• Assign valid LCA account ranges to licensed member banks in the Authorized Greenlist Banking Body (see Figure 7).

These process descriptions provide detailed information on building and using Greenlist's functionality. These descriptions include inputs, processes, outputs, dependencies, and data.

Creation of new bank member records in authorized Greenlist bank entities

This process involves the preferred master directory bank setup/maintenance process 200 shown in FIG.

A) input

1. Display entry input screen

a. The Greenlist system administrator 280 enters his authorization id and password to enter information into the Greenlist system.

b. Select Add/Modify/Invalidate Action Code.

c. The input data source is from the bank's registry contract agreement 310 between the Greenlist and the financial institution. Fill in the data element fields of the bank profile database (see below) with the information from the registration contract.

d. The registration contract also includes a block 325 identification of each bank's Linked Credit Account (LCA) number registered with Greenlist.

B) processing

1. Verify the entered Greenlist user id with the authorization criteria in the security authorization file 245 to perform add/modify/delete functions on bank profile data.

2. Display a data entry screen for all bank details database data elements 200.

3. The entry screen must include drop down boxes with valid values for specific data fields (eg, EPN; CHIPS; SWIFT's flags (if applicable)).

4. Check that the required fields and formats are entered.

5. Verify each entry field 225.

6. Verify that the Greenlist ID account number is a valid number for the financial institution 240 from the master Greenlist ID account file; or

7. Verify that the "LCA Number" is a valid Electronic Payments Network (EPN) UPIC Account #265, or

8. Verify the bank's routing number 255 to the ABA routing number.

9. Verify address structure, city/state/zip code combination 260.

10. Verify e-mail address syntax.

C) output

1. Post an entry in the Authorized Greenlist Bank Master File 240.

2. Print the entries in the new bank audit maintenance log 270.

3. Post a completion message on the entry screen.

D) System dependencies

1. A bank-approved security system must be in place.

E) data

1. Data verification source:

a. ABA Routing # edit verification file 255.

b. State Code Verification Form 260.

c. ZIP Code Verification Form 260.

d. CHIPS and SWIFT verification documents (if applicable).

e. EPN UPIC master account # list (if applicable) 265.

2. Filled/maintained data

a. Authorized Greenlist Bank Master File 240.

Modify bank member records within authorized Greenlist bank entities

This process involves the preferred master directory bank setup/maintenance process 200 shown in FIG.

A) input

1. The Greenlist Administrator enters the Action Code (Add/Modify/Delete) and the Bank to modify (ABA Routing # or Financial Institution's Assigned Identifier Number).

2. The Greenlist administrator modifies the bank information elements.

B) Processing

1. Identify the correct bank based on the ABA Routing#.

2. Display the bank profile element to be modified.

3. Perform a verification of any elements that were changed.

C) output

1. Post the entry to the authorized Greenlist bank master database.

2. Post a completion message on the entry screen.

3. Print the entries in the new bank audit maintenance log.

D) System dependencies

1. Security system.

E) data

1. Data verification source

a. Same as bank registration.

2. Filled/maintained data

a. Authorized Greenlist bank master database.

Invalidate bank member records in authorized Greenlist bank principals

This process involves the preferred home directory bank setup/maintenance process 200 shown in FIG. 3 .

A) input

1. The Greenlist Administrator enters the Action Code (Add/Modify/Delete) and the Bank to be deactivated (ABA Routing # or Financial Institution's Assigned Identifier Number).

2. The Greenlist administrator confirms the invalid request.

B) Processing

1. Identify the correct bank based on the ABA Routing#.

2. Display the bank details element to verify the location of the correct bank to be invalidated.

3. Prompt to the user "Confirm this bank entry will be invalidated".

4. Flag the record to prevent future transactions using the bank being invalidated.

C) output

1. Post status stamps to authorized Greenlist bank master files.

2. Post a completion message on the entry screen.

3. Post entry activity in the bank's master audit log.

D) System dependencies

1. Security system

E) data

1. Data verification source

a. None

2. Filled/maintained data

a. Greenlist bank master database.

Provides an update mechanism to the Greenlist master directory

This process involves the preferred master directory registration/maintenance process 230 shown in FIG. 4 .

A) input

1. The input screen of the service representative of the bank customer is used for manual input of the member information registration information of the bank customer, or for the bank customer to input the registration information through the bank's home banking portal 280 by himself. The customer fills in the record with the appropriate information, which is then validated by the bank and published in its Greenlist remote directory.

2. The Greenlist bank authentication process must verify that the transaction header is an authorized member of the authorized Greenlist bank principal 240 .

3. The Greenlist registration system must be structured to have the functionality to accept fixed format file material for mass registration. The system should populate the master directory account profile information with the member's transactions. All updates must be received by verified Greenlist member banks.

a. The input record must be in a fixed format.

b. The input record will contain a status flag field for Added, Modified, or Deleted.

4. Screen

a. Input screens must be provided for all account profile database data elements.

b. Where possible, the input screen must include drop-down boxes with valid values for specific data fields (eg, status, flags for notification preferences, etc.).

B) Processing

1. Access to the screen requires a security check to verify the individual's id, the bank's Greenlist system administrator's password has an appropriate security level to allow it to perform maintenance (add; modify; delete) on its customer's profile information.

2. The record status field identifies whether the transaction is adding, modifying or deleting a record.

3. Edit/Verify 225

a. Verify that the Greenlist number is a valid number from the master Greenlist list assigned (licensed) to the financial institution.

b. Verify the bank's routing number against File 255 of valid ABA routing numbers.

c. Verify that the EPN LCA number is a valid UPIC from the EPN Valid Account# Form 265.

d. Perform validation checks on the address structure, e-mail address, city/state/zip combination 260.

e. Deleting a transaction will mark the master record with a deletion marker and update the deletion date field with the system processing date.

f. Modifying the transaction type will overwrite the current master field with the field updated by the new transaction.

C) output

1. Updated Greenlist main catalog 235.

2. Display to user and confirmation notification to success/failure log file 275.

D) Dependents

1. The process is a real-time update process and has no subordinate processes.

E) data

1. Data verification source

a. ABA routing table 255 .

b. EPN UPIC account number 265.

c. US zip code file 260.

2. Filled/maintained data

a. Authorized Greenlist bank entities.

b. ABA edits the verification file.

c. State Code Verification Form.

d. Zip Code Verification Form.

e. CHIPS and SWIFT verification documents (if applicable).

Provides nightly update material to/from member bank directory subsystem

This process involves the preferred bank subsystem Greenlist update process 215 shown in FIG. 5 .

A) input

1. None (nightly batch process).

B) Processing

1. Create a nightly (or live) format replication from the Greenlist master directory 235 to the subset member remote local directories 295, 300, 305.

2. The VPN will authenticate to check that each bank entry in the bank master file marked for subdirectory update transactions is the correct ABA# as indicated in the Greenlist bank master file 240 .

3. The system will strip and pass only new additions, modifications and deletions to the member bank subdirectory.

4. The maintenance input screen will be designed to support the update of VPN information during the bank subsystem update process.

5. An edited report of the failed transaction will be generated.

C) output

1. Bank specific transaction files for incremental changes to the Greenlist master file 270 .

D) Dependents

1. Updated Greenlist main directory.

E) data

1. Data verification source

a. None.

2. Filled/maintained data

a. Greenlist main directory database.

b. Greenlist master transaction file.

Provides Internet search functionality for the Greenlist main directory

This process involves the preferred Greenlist Internet query process 220 shown in FIG. 6 .

A) input

1. Account Holder Name; Bank Name; Bank Location; ABA Routing Number; Address, City, State; LCA Number; Telephone Number; User ID and Password.

B) Processing

1. If a user ID and password are entered, verify the user ID and password. Determine the security level.

2. Check the state entry against the ZIP Code/State Table 260 edit.

3. Check the ABA routing number against the ABA routing table 250 edit.

4. Locate and display records matching any field of the entered information.

C) output

1. Display name; address; bank routing number; LCA number of all records matching the entered value.

D) System dependencies

1. None

E) data

1. Data verification source

a. Zip code file 260.

b. ABA routing # table 255.

c. Security authorization file 245 .

Allocate valid LCA account scopes to licensed member banks in the authorized Greenlist banking entity

This process involves the Preferred Home Directory LCA Account Assignment/Verification process 340 shown in FIG. 7 .

A) input

1. The Greenlist system administrator provides the user id and password.

2. Member bank identification.

3. Valid Greenlist account block input.

4. Bank ABA Routing Number.

B) Processing

1. Check the required fields and formats.

2. Verify user id and password against secure database.

3. Display the management home page.

4. Locate the bank record by entering ABA#.

5. Mark valid Greenlist ranges as allocated or freed for reuse.

6. Assign a "new owner" member bank to the Greenlist range.

7. Update the allocation period (from/to) on the Greenlist master file.

8. Add or remove Greenlist scopes for member banks based on status flags.

9. Update input display with completion notification.

C) output

1. Post an entry in the audit activity log.

D) Dependents

1. The authorized Greenlist Bank Master File record for the member bank being updated.

2. LCA master list database.

E) data

1. Data verification source

2. Security database - verify that the administrator id has the right to make updates.

3. The Greenlist range on the Greenlist master list database is not allocated.

4. Verify the LCA account number syntax and check the digits.

5. Verify that the bank is a current bank member located in the authorized Greenlist master bank database.

6. Data entered/maintained

7. LCA master list file.

Preferred home catalog data, edit and lookup

This section describes data, edits, and lookups involving the home directory. include:

· Preferred financial institutions eligible to run the Greenlist directory;

· bank/financial institution registration data elements;

·Customer registration/data creation;

Subsystem (payment transfer) directory;

· Internet lookup of the Greenlist main directory;

·Main directory account search and verification;

· Greenlist account allocation; and

· Greenlist home directory security/maintenance audit log.

Preferred Financial Institutions Eligible to Run the Greenlist Directory

A. Clearing institution

NACHA, Federal Reserve Bank of Cleveland (also known as ACH) or equivalent clearinghouses such as the Electronic Payment Network (EPN), and industry-specific clearinghouses such as Affiliated Network Business (via a correspondent bank).

B. Banking institutions

Any bank operating in the United States registered with the American Bankers Association and certified by each state licensing authority.

C. Non-Banking Financial Institutions (NBFIs)

Restricted to NBFIs that own banks, or NBFIs that are owned by banks: Metavante, for example.

Limited to NBFIs considered by the bank to be agents: for example, a joint partnership with the bank's Zenith information system.

Bank/Financial Institution Registration Data Elements

The bank profile data elements in each bank record preferably include the following elements:

·Bank (branch) name ^*

·Bank Address ^*

· Bank's main phone number ^*

·Bank Status ^*

·Password ^*

· ABA 9-digit routing/delivery number ^*

·Greenlist master/directory account ^*

·Bank parent entity main directory account number ^*

· Bank Master Directory primary and alternate administrator contact names ^*

·Bank master directory administrator contact address ^*

·Bank Master Directory Administrator Contact Phone Number ^*

· Bank main directory administrator e-mail address (if applicable)

·Bank administrator security authorization level ^*

·Account range issued by bank Greenlist

· Bank ACH Customer Support Number

·Bank CHIPS number (if applicable)

·Bank CHAPS number (if applicable)

· Bank IBAN number (if applicable)

· Bank Federal Electronic Transfer Agent Number (if applicable)

· Bank SWIFT number (if applicable)

· Bank EPN UPIC account number (if applicable)

・Preferred notification/response method for communication method requirements ^*

Create user id (system generated)

· Update user id (system generated)

·Create system date (system generated)

Create system timestamp (system generated)

· Update system date and time (system generated)

· Comment section

^* required field (must have content (no special characters))

Edits to be made by Greenlist on the Greenlist Master Bank Profile record entry:

• Verify home directory account number (check digit sum).

• Verify the ABA routing number against a valid ABA routing directory.

· Edit checks compare phone number prefixes with zip codes for correct geolocation matches.

·At least one contact information of the bank administrator must be entered.

• The required security authorization level must be valid and lower than that of the payment path's data system administrator.

· If available, verify the IBAN; UPIC; CHAPS; CHIPS; SWIFT; ACH number against published directories.

Note: EPN UPIC account number can be used instead of Greenlist LCA number.

bank database Bank LCA identifier AN 17 Y Bank (or branch) LCA record identifier Bank LCA status N 2 Y Values: "01" active; "02" pending; "03" inactive; "04" on hold Bank Federal Routing Number N 9 N BBK's Federal Reserve Bank routing/delivery number Bank name ANS 35 N The first line of the bank address ANS 35 N The second line of the bank address ANS 35 N The third line of the bank address ANS 35 N The fourth line of the bank address ANS 35 N City AN 32 N province / State AN 32 N zip code AN 11 N nation AN 2 N Values defined by ISO-3166 two-letter codes Internet address of the bank AN 50 N Primary/Parent LCA account number AN 17 N Bank's Group Master LCA Identifier Bank main administrator id N 10 N Administrator of the bank's payment transfer system Bank master administrator security level N 2 N Admin e-mail address AN 50 N Bank replacement administrator id N 10 N Backup administrator of the bank's payment transfer system Bank replacement administrator security level N 2 N Replace admin e-mail address AN 50 N Bank's technical contact name AN 80 N Technical contact number# N 11 N Permissions are non-international Bank Replacement Technical Contact Name AN 80 N Bank Replacement Technology Phone# N 11 N Permissions are non-international Technical contact e-mail address AN 50 N Bank Advice Preference Code AN 1 N Reminder preferences (e-mail; fax; phone) Bank notification information AN 26 N e-mail address; notification or fax phone number Support EPN N 1 Y Valid values: "0" not supported; "1" supported Support CHIPS N 1 Y Valid values: "0" not supported; "1" supported

CHIPS participant number N Y Bank SWIFT/BIC AN 11 Bank's BIC code Wired PaymentN/A 1 AN 35 Y CHIPS/Fedwire payment name/address 1 Wired PaymentN/A 2 AN 35 Y CHIPS/Fedwire payment name/address 2 Wired PaymentN/A 3 AN 35 Y CHIPS/Fedwire payment name/address 3 Wired PaymentN/A 4 AN 35 Y CHIPS/Fedwire payment name/address 4

Table 1

As part of the preferred input audit process, upon successful initialization of the bank's data record, the Greenlist system returns electronic response notifications to the bank (via e-mail or fax, as per the bank's "Response Communication Method for Required Notifications/Communications" field indicated). The reply to the bank is a confirmation of successful initiation of the record provided by the bank. The reply message can be similar to the following:

"(Bank name) has been successfully initialized in the Greenlist master bank file on (date and time). The Greenlist master bank account number for (Bank name) is (Bank GREENLIST identifier number). Authorized master administrators are (XYZ Administrator). All account management messages will be sent to (list e-mail or fax number). If you have questions please contact (Greenlist Data System Administrator) (phone number). Add to your Greenlist system now New Personal/Business Entity Home Directory Account."

Main directory Account Holder/Entity material LCA identifier AN 17 Y Individual or Entity's Linked Credit Account Blocking Debit Unique Identifier LCA status N 2 Y Values: "01" active; "02" pending; "03" inactive; "04" on hold UPIC identifier AN 17 Y EPN unified payment identification code UPIC status N 2 Y Values: "01" active/open; "02" pending; "03" closed LCA effective date D 8 N Effective date for LCA to become active (YYYYMMDD) Valid date of UPIC D 8 N Effective date when UPIC becomes active (YYYYMMDD) Primary/Parent LCA account number AN 17 N Group parent consolidated accumulation account (if applicable) Bank R/T# N 9 Y Federal Reserve Bank Routing/Sending for Customer Banks# Account Holder DDA Account# AN 34 N Y DDA# (if EPN is supported, the maximum value is 17). Remaining Confirmed Value/Zero Input Taxpayer ID# or FTIN# AN 12 N Y Federal Tax Identification Number

Account holder name AN 80 Y Account holder personal or entity name entity branch name AN 80 Y Company branch name (if applicable) Entity short name AN 16 N Account holder's short name Address 1 AN 64 Y 1st address line The second line of the address AN 64 Y The second address line of the address The third line of the address AN 64 Y Third address line The fourth line of the address AN 64 Y Fourth address line City AN 32 Y province / State AN 32 Y zip code AN 11 Y nation AN 2 Y Values defined by ISO-3166 two-letter codes Account Holder/Business Entity Phone Number N 11 N Permissions are limited to non-international Account holder mobile phone number N 11 N Y Permissions are limited to non-international Account holder's fax phone number N 11 N Y Permissions are limited to non-international The entity's technical contact name AN 80 N Y Technical contact number# N 11 N Y Entity's technical replacement contact name AN 80 N Y Technical Replacement Contact Number# N 11 N Y Account holder e-mail address AN 50 N Y Account Holder Notification Preference Code AN 1 N Y Notification Preferences ("00" None, "1" e-mail, "2" Fax, "3" Phone) Account holder notification information AN 26 N Y E-mail address; notification or fax phone number Accounting software package N 2 N Y A/P and A/R packages for account holders Accounting software update flag N 1 N Y "0" no, "1" yes SIC enterprise code N 4 Y Standard Industry Classification Code DUNS Id N 10 Y D&B D-U-N-S number Thomas Registration# N 10 Y Thomas Global Registered Company Identifier Payer's payment network preference N 1 Y "0" ACH, "1" SWIFT; "3" Fedwire; "4" CHIPS; "5" other BIC code AN 11 N SWIFT BIC Code BEI code AN 11 N SWIFT Business Entity Identifier IBAN code N 34 N International bank account number

Table 2

Customer registration/data creation:

The actual process of setting up a new LCA account begins with the recipient's bank. The bank can issue a promotional form to promote this new Greenlist product to its entire existing customer base, or include the option for a new account. Greenlist account holders may request to be listed on the main Greenlist directory, which is accessible on the Internet. This establishment can also be initiated by the bank's extended customer service functions (e.g., health care clinic/dentist registration desk; school administration office; trade association/union; corporate payroll or shareholder relations department; corporate receivable account department, insurance company; credit card companies, etc.). This system preferably accommodates potentially large batch input on behalf of member banks from member accounts of these types of organizations or entities. However, in each of these "on behalf of" initiated requests, there is still a requirement that each individual/business entity's affiliated bank or financial institution must have a pre-established on the Greenlist master directory, FED-ACH, or UPIC directory of the electronic payment network. Created bank account number.

The registration system is preferably a browser-based registration system. The point of entry is preferably one of the following: (1) a customer user interface connected to the bank's online home banking portal site; (2) a bank site kiosk within the bank; or (3) via an on-site terminal (workstation). In the last case, an individual or business entity customer may speak or provide information to a customer service representative in person or over the phone.

In order for the bank's "members" (payees/payees) to exist on the Greenlist master directory, business entities or individuals must first subscribe to the Greenlist affiliated bank or authorized partner organization bank (such as EPN) in Greenlist to establish LCA and DDA ( savings account).

In order to access the Greenlist system login screen, bank personnel or bank customer members must provide their bank DDA and password. The DDA number and password is the front-end security mechanism for the account holder portion of the Greenlist system. The DDA number is verified against the bank's active account database. The bank password is critical to prevent an intruder with knowledge of a business entity's or individual's bank checking account number from creating a "redirect LCA number" to their own LCA account number. Since the normal process is "remove and replace" by the system, the Greenlist verification process is able to catch and flag any "redirects".

Through the bank's online banking portal system, a business or individual "member" will request mobile payment functionality from their bank (preferably utilizing the account variant of LCA's Filtered Debit (i.e. Linked Credit Account Number (LCA or UPIC for EPN Network Bank) The LCA is linked to the DDA account. A secure hot link from the home bank portal to the bank's native Greenlist payment system guides the member's enrollment.

New LCA member information requires name/address information, fields such as method of notification (e.g., fax, E-MAIL, phone), and other IDs for future use (e.g., UPIC, SS#, IBAN#, FEIN#, DUNS #,industry).

Please note: The communication aspect of the system preferably allows a decentralized multi-branch banking system to pass all branch submissions to its central parent site for consolidation, and nightly resends to the master directory system. The parent bank may choose to push all records involving all banking system member branch banks back to its overall branch Greenlist system location, whereby each branch will have a secondary master directory listing of all account holders for the entire banking system's member base.

The Greenlist master directory system performs edit and verification checks. Some edits include verifying the bank's ABA number, LCA, UPIC, and IBAN.

When the new bank customer's LCA account is created on the main directory, a message similar to the following is sent from their bank to the new account member:

"(Bank name) is pleased to inform you that your new (Bank name) LCA account and main directory Greenlist account have been activated and can receive payments on (system date)." Your LCA account number is (LCA personal/corporate entity account number) . It is recommended that business entities include the LCA number on the remittance portion of the receipt and instruct your payer to use this secure electronic account number instead of a paper check for payment. As a reminder, please note that LCA accounts can only be used to receive payments. Any debit origination will be blocked. Withdrawals cannot be made directly from this secure account. Money received into the LCA account will be transferred to your checking savings account on a regular basis according to a schedule established with (name of bank). "

The system will also create and send a notification audit report to the bank, notifying the successful or unsuccessful processing of the previous night's customer directory account maintenance.

The member registration process is completed at this stage. Records on the Greenlist Master Directory that include "members" of the new LCA (or UPIC) account number are at this time accessible via the Internet. The new Greenlist/LCA account number is active and ready to start receiving payments.

Another embodiment provides bulk batch processing of individual customers from organizations (e.g., federations, universities, clearing house members, and groups such as AARP, etc.) under the Unassigned-"Pending-Bank"-Allocation/Banking Activity Category register. Organizations of individual members are "sold" to banking entities that are already members of the Greenlist Directory or the EPN Network or are about to become new members of the Greenlist Directory or the EPN Network.

The collected profile data elements for each individual/business entity include:

Individual/Business Entity LCA Data Record

·Personal Greenlist account#

· Bank's 9-digit ABA routing/delivery number ^*

· Individual/Business Entity LCA (National Biller Directory) Number

· Bank current account (DDA) number of the individual/business entity

·Personal/Business Entity Name ^*

· Individual/Business Entity Full Address ^*

·Personal/Business Entity Phone Number ^*

· Personal/business entity mobile phone number (if applicable)

· International Destination Marking ^*

· Loyalty point field 1 or 10

· Personal/business entity fax number (if applicable)

· Personal/business entity e-mail number (if applicable)

·Business Entity Federal Tax ID# (if applicable)

·Business Entity DUNS# (if applicable)

·Enterprise industry

·Business entity LCA contact name

·Business entity LCA contact number

·Personal/Business Entity UPIC Number (if applicable)

· Personal Social Security # (may be required for insurance and health care providers)

· Individual/Business Entity Consolidated Parent LCA Number (if applicable)

· Individual/Business Entity Preferred Communication Method for Billing Advice/Response ^*

(Depending on the method selected, the data that assists the method becomes a required field)

·Personal/Business Entity's Preferred Communication Method for Collection Advice/Response ^*

(Depending on the method selected, the data that assists the method becomes a required field)

· Individual/Business Entity Status (New/Existing/Terminal/Pending/On Hold ^** )

·Account system creation date

·Account timestamp creation date

· Bank personnel Greenlist directory system ID number

·Extended remarks field

^* Required fields must contain content (no special characters).

Edits made by the bank's native Greenlist system include:

· Verify the field length of the input data.

• Verify the LCA number (check the sum of digits).

·Utilize the EPN UPIC verification document to verify the UPIC number.

· Allocated Greenlist Validity Scope for Banking Entities Registered by New Individual LCAs.

·Arrange geographic areas where zip codes and area codes are more effective.

· Please note: Individual bank allocations with a "hold" status will prevent funds from being transferred.

Please Note: Wherever possible the data entry fields are preferably pre-populated with bank information already stored in the Greenlist (eg bank LCA number and ABA number) system or the bank's own member account system.

Please note: The bank's stored routing number and LCA (next available sequence in the bank's block of numbers) in the Greenlist system will be generated by the Greenlist system.

• The system preferably tracks any changes to an individual's or business organization's banking association. The combination of the personal/business Greenlist account and the routing number of the associated bank provides a unique record identifier for financial transactions and responses in the Greenlist system.

When an individual closes their checking account with a financial institution, the Greenlist member submits a standard individual/business entity LCA status change (inactivity) transaction as part of their termination process. The Greenlist master directory will receive update transactions to reflect the change in LCA account status from "active" to "inactive". Procedurally, once an LCA customer changes their current account profile statistics, the bank will simultaneously submit an updated maintenance to its local Greenlist system. This information preferably flows through and updates the Greenlist master directory records during a nightly batch update process. LCA customers can be notified of when changes need to take effect (propagate throughout the system).

Bank Subsystem (Payment Transfer) Directory

Individual bank directories must be registered to be certified and maintained by Greenlist. Following this step will ensure a core infrastructure that financial institutions and businesses can rely on to eliminate fraud and costs involving paper and other single-factor payment methods such as offline debit and credit cards.

The look and feel of the native Greenlist system can be marked with a "proprietary badge" according to the look and feel standards the bank has adopted for its home banking portal. The individual bank may be responsible for any required coding for the incorporation of the Greenlist master into the bank's current home banking portal.

When an agreement is signed, Greenlist can physically install a discrete Greenlist hardware/software system in the bank's firewalled environment. The required VPN communication link to the home directory system can be established and secure directory management technology can be configured and activated.

With the assistance of a Greenlist "Directory Administrator" or authorized bank personnel, a bank's authorized "Greenlist Administrator" can register the bank by completing the bank profile registration screen on their newly installed Greenlist system.

Completion of this process generates a "Pending Bank Details" record and an updated transaction file that is sent to the Greenlist master directory system via a secure VPN connection. Bank information is validated/verified by the master directory system (eg, verified against Commonwealth Bank Routing#, valid Greenlist Authorized Bank Account#, valid UPIC number, etc.).

A successful verification will result in a "Confirmed Transaction Record" which is generated by the Greenlist Master Directory and sent back to the bank's Greenlist system to start the system and change the bank's System Status field from "Pending" to "Active" "state.

Internet lookup for the Greenlist master directory

In operation, in order to use Greenlist for payment and settlement processing, a person or entity (seller) wishing to bill a buyer (payer) preferably requires the buyer to deposit funds on the biller's LCA account. A buyer may determine a seller's account number by conducting an internet search of the Greenlist master directory.

To facilitate use of Greenlist, the billing party or person who will receive a claim (e.g. insurance) check or paycheck from the government or other source will be required to notify the paying entity via the billing party's (payee's) bank and the Greenlist promotional text Send payments via the Greenlist mobile payment network, ATM network, electronic payment network or federal ACH network. They will be required to provide their bank routing and LCA or UPIC account number to the payer.

All individual/corporate entity LCA and UPIC account numbers are open for public inquiries/searches. (If the corporate requirements of the system allow the inclusion of actual bank account numbers in the directory as record keys, special security logic can be used to help require viewers to register to access checking savings accounts. Access to bank profile record information in the Greenlist master directory has no Restricted public viewing is also open.

The Greenlist master directory site can be accessed via an internet link or via any public internet search engine such as Google.

Main directory account query verification

The successive levels of criteria for a search biller account record query of the master directory preferably include:

· Name (individual or business entity)

· Entity type dropdown (e.g. government, telephone company, gas and electric company)

· State or geographic area drop-down list

· Address (partial or complete)

·telephone number

· Bank name (and/or routing number)

·Bank branch location

This search will reveal the biller LCA, UPIC number and bank routing information, or return a message indicating that the account number is not found or unavailable. If the "not found" condition occurs, the system also displays a message explaining how to join the Greenlist system.

Please note: Individuals or businesses can have multiple account numbers if they conduct financial transactions with multiple banks.

Preferably, the customer's participating originating bank establishes a relationship with an authorized Greenlist financial institution (or EPN bank), or influences its existing bank to join the Greenlist system. This financial institution will be registered and have a running Greenlist system in its physical environment. The registry function built into the Greenlist system maintains a local directory and profile of all participating business entities and customers that initiate the bank's LCA account. The registry function of the Greenlist system maintains a copy of information between itself and the master directory. The master directory makes its members searchable nationally and internationally.

Greenlist account designation

As previously mentioned, in one embodiment, each bank "rents" its registered Greenlist account number block as part of a contractual arrangement with the Greenlist directory business organization. As long as the owner of the LCA account is assigned to the bank that subscribes to the LCA business, the bank pays Greenlist a monthly fee for the registered (active and inactive) LCA authorized accounts held by Greenlist for its "control". A Greenlist inventory system may require processes and systems for monitoring and tracking these Greenlist assets. When a member of the bank has a checking savings account with the bank, the account number is registered to the lessee bank. The tracking system will record the start and end dates of the period the account was registered with the bank.

Greenlist home directory security/maintenance audit log

The home directory update/maintenance process logic provides an audit trail of changes made to the home directory.

· Any records of adding, modifying and deleting data in the bank profile table.

• Password based security to allow authorized system administrators of banks to log into the Greenlist master directory to perform directory maintenance for their bank.

The security mechanism of the Greenlist main directory will be designed to provide 4 levels of security authorization:

A. Level 3 - Authorized viewing only (for bank staff; business entities and individual customers;

Greenlist non-sysadmin staff).

B. Level 2 - Authorization to change bank identification data.

C. Level 1 - Authorization to add/delete records.

D. Level 0 - Greenlist System Data Administrator.

• Audit trail with date and time stamp includes the ID of the individual who made the change.

• Records of changes made to the Directory's Bank Profile tables will be recorded in the PP Master and Master Maintenance Audit Log tables.

Maintain audit log table content:

· Bank main number

·Greenlist personal id.

· Bank system administrator id.

·System date

·System timestamp

·Transaction (add/delete) status changed from

· Transaction (add/delete) status changes to

· Transaction (change) field name

·Transaction (Change) field from

· Transaction (change) field to

legend

figure 1

100 Greenlist

105 (points to the Greenlist database)

110 bank

115 (points to bank database)

120 subscribers

130 DNS

140 transaction processing

150 starters

figure 2

200 New Member Bank Establishment Process

205 License Number Assignment Process

210 GL safety certification process

215 nightly members…renewal process

220 "Goggle" search process

225 input verification edit

230 Main directory update process

235 GL main catalog

240 Authorized GL Banking Subjects

245 security authorization file

250 license master file

255 ABA Bank Verification

260 ZIP/STATE TABLE

265 UPIC body

270 audit log

275 Confirmation report

280 New registration input from member bank

285 Registered by the bank of the GL system administrator

290 Directory Internet Search Queries

295 member banks 1 remote...

300 member banks 2 remote…

305 member banks 3 remote...

image 3

200 New Member Bank Establishment Process

205 License Number Assignment Process

225 Bank Input VerificationEdit

240 Authorized GL Bank Master File

245 security authorization file

250 permission master list file

255 ABA Bank Verification

260 New bank registration input...

260 ZIP/STATE TABLE

270 New Bank Audit Maintenance Log

310 Contract...

Figure 4

210 GL Bank Authentication/Authorization Process

225 input verification edit

230 Main directory update process

235 Current GL main directory

235 Updated GL main directory

240 Authorized GL Banking Subjects

250 license master file

255 ABA Routing#

260 ZIP/STATE TABLE

265 UPIC body

275 Acknowledgment success/failure report

280 New registration input request...

280 New bulk registration input request...

315 file organization

Figure 5

215 nightly member banks...renewal process

235 GL main catalog

240 Authorized GL Bank Master File

270 audit log

295 member banks 1 remote...

300 member banks 2 remote…

305 member banks 3 remote...

320 Communication/Update Banking Subsystem

Figure 6

290 Directory Internet Search Queries

235 GL main catalog

245 security authorization file

220 "Google" directory search process

260 ZIP/STATE TABLE

240 Authorized GL Bank Master File

255 ABA Bank Routing Table

Figure 7

210 GL safety certification process

225 New registration input verification edit

230 Main directory update process

235 GL directory master list file

240 Authorized GL Banking Subjects

245 security authorization file

265 UPIC body

325 LCA block allocation…

330 EPN update file

335 License file update process

340 License Verification Process

health care implementation

Healthcare clearinghouses are currently emphasizing the need for emerging Electronic Remittance Advice (ERA) payments (ie, HIPAA-compliant medical payments). ERA is required for Medicaid and Medicare, and many insurance companies use ERA for all payments. These payment communities all require the ability to process payments without today's security risks and payment delays. The following describes how the invention can be used in healthcare:

As noted above, the use of Greenlist eliminates the potential overdraft risk associated with debit ACHs by issuing credit ACHs. In addition to the aforementioned efficiencies of authenticating business associations provided by parties (such as banks) in a minimal cost manner, in the healthcare context, this use is expanded into two subtle uses.

• First, reverse the method of current account payments, putting control of the release of payments in the hands of the customer or small business.

Second, when a smaller or even medium-sized business is the health care provider and the party being billed is the insurance company; to date these entities have feared that payments for charges later determined not to be covered by insurance would be immediately debited are reluctant to provide their bank account information to insurers due to debits or “catch-backs” rather than being settled in the next month’s payment cycle.

Banks acting as Greenlist registries preferably register small businesses (eg, health care providers) in Greenlist and estimate service charges. Part of this monthly fee is the net income, and part of the fee is used as the net income of the payment address listed by the registry in the public Greenlist to block debits (or filter debits). In health care, there is the possibility that a clearinghouse for insurance companies and/or a Commonwealth Bank creates a company that acts as an agency registry (for banks) and performs the function of the Greenlist registry by obtaining a license to use the system.

Greenlist conducts many of the businesses that are in demand in today's insurance companies. Green list:

(a) Allow exclusive access to the full Greenlist data field. For example, social security numbers may be exposed to permitted participants between a company and its bank. This is useful for resolving a unique identifier pertaining to a customer's identity to a secure "place of payment" payment address (for payments via credit ACH). Also, clearinghouse identifiers can be obtained for PHI delivery (eg, NPI, TaxID, TSO, etc.).

(b) Receive HIPAA X12 835/ERA Bulk Enrollment Transaction Documentation from the Business (customer who chooses to be given a secure and listed Greenlist payment address so that their insurance co-pay reimbursement can be deposited electronically).

(c) Allow the clearing house to act as a payer's request/EFT clearing house. Thus, as more payers begin adjudicating in real time, the same clearinghouse that processes requests can return 835/ERAs provided by Greenlist with payment information and/or payment confirmations, even for payers that have not yet begun providing 835/ERA. Status response for the route. The payer (insurance company) can contract all of its needs with the clearinghouse without having a separate banking relationship for electronic payments to the provider.

(d) Allow for mass Greenlist enrollment at the time of ERA enrollment, especially in the early stages, where providers are in most cases not enrolling one after the other but "mass enrolling".

For each Provider registered with the Clearinghouse, a number of "placeholder" Greenlist registration "slots" will be allocated by default, regardless of whether the Provider chooses to use Greenlist. Then, if the health care provider decides to use Greenlist, they simply indicate this decision to the operations management system (PMS) vendor or clearing house, and the PMS or clearing house simply flips a switch so that the provider initiates the creation and distribution of The Register of Banks creates a blocking debit bank account during the registration process.

Greenlist directory providers conduct multiple businesses that are currently in demand among health care providers of all sizes. The advantages are consistent for clinics, large provider groups, and possibly small hospitals that do not have systems in place. These advantages include:

· There is no chance of reversing the payment, because the payment address is debit-blocking (filter debit);

· Notification by Greenlist switch (optional) using the method chosen by the customer (email, voicemail, SMS) when payment arrives;

Dedicated phone number (eg, from NetZero) for voicemail, so no commercial line is paid for delivery to the notification call provider;

Avoids the provider's concern that the insurance company is not working directly with "their" bank, as the system is bank neutral from the provider's perspective;

· HIPAA compliant payment methods;

· Payments can be received using the same system (Greenlist) regardless of how many insurance companies the provider works with (the clearing house's interest is intermediary); and

• Can be easily accommodated in a provider's office when each doctor or dentist wishes to be a separate "payee".

Currently, many Provider Offices wishing to pay to a specific TaxID must allow payment to one TaxID and allow reconciliation to be performed at a later time, since payers cannot accommodate multiple payments to a single TaxID.

In one embodiment, the Greenlist allows the clearing house to use the ERA/payment provider to determine the payee and then assign the payment to a specific TaxID, while pointing to the ERA so that the provider office/provider themselves can see the payee for each line item. The ledger and to whom the payments are distributed. Features of this embodiment include:

• Greenlist stores payment history to allow Providers to have a second path for reconciling payments from Payer to Provider and separate from all collectibles.

• Periodic "keep alive" tests on payee addresses. The Registry of Banks vouches that payments to registered payees will not be caught as electronic lockbox accounts listed on the Greenlist are filtered DDAs.

There is a trend towards the use of Greenlist among health care clearinghouses, and the move of insurance companies to ERA payments. Currently, Medicaid/Medicare requires ERA payments to ACH payment addresses.

Effective October 1, 2006, Medicaid will not allow the use of paper remittances for any provider who has elected or decided to elect to receive an ERA (electronic Explanation of Benefits). An inherent part of the ERA is the reconciliation including payment information and eventual payment. Any time an ERA is delivered without payment information, its value is reduced. As a result, CMS, ADA and AMA, and state associations (as well as industry groups) are forcing primarily clearing houses to get a method whereby providers and payers "can do what they currently do" and responsible clearing houses follow EFT/ACH clearinghouse for request reconciliation payments (also most logical at this point in the request process).

The bottom line is that eventually the required ERA (not allowing the provider to choose, but telling the provider that it can only be part of the insurance company's network if it would like to receive an ERA on paper) cannot be enforced without coordination of payment information. Medicaid is leading the process, and insurers will follow, as the check printing and Explanation of Benefit (EoB) printing process is inherently much more expensive than the electronic version. Insurance companies are currently emphasizing the goal of reducing operating expenses for mailboxes, customer service, imaging and printing systems, and more. This was not the case in previous years, as new processing requirements imposed by HIPAA took control of the industry. In 2006, many payers already offered incentives to providers of paper remittances willing to forego the ERA. This shift to preference, which is currently underscored by providers of all sizes, has the power of a flood. Greenlist addresses an important issue preventing full and rapid implementation of HIPAA 835/ERA payments: provider reluctance to provide bank account numbers.

social network implementation

The next step in the development of social networks will be payment transactions between two groups. Complementary to the directory of each social network of individuals is the directory of payment addresses, the Greenlist, which identifies and verifies that each individual or business entity is genuine. This will allow customers and business entities to make electronic payments or authorize account access through the social network.

Banks will see social networking as an ideal market to drive demand among large numbers of young, able-paying customers. Therefore, social networks are also ideal Greenlist distribution channels.

Currently, 2/3 of American youth have profiles on more than one network - and 53% would join another network if forced enough. With potentially millions of U.S. customers willing to be on the Greenlist, the incentives for leading banks to facilitate the enrollment process are even higher. Similarly, merchants are encouraged to list themselves due to the purchasing power of this segment of the population. Finally, Greenlist allows the bank to promote among an emerging generation of customers that the bank has so far not been in touch with. "Meet them where they are" is the right approach, and this segment of the population lives online and needs new payment services.

Currently, banks spend an average of $284 per customer on the market for acquiring new customers. This market pull strategy can be used to pull these young customers and their huge assets to the bank at a dramatically reduced cost. Such web portals offer the greatest and fastest opportunity to trigger rapid adoption.

However, social networking has taught the practice of hiding an individual's true identity behind fake names, fake personas, and the like. The transfer of information assets does not always flow down from the knowledge base to the consumers of the information. For example, customers who are skilled at using a false identity relative to their real identity can and do post false information on Wikipedia. This has resulted in the discovery and permanent banning of congressional staff members who edited, posted or removed information involving US lawmakers. In one implementation, Greenlist will perform this role by switching authentication requests (i.e., that a person is who they claim to be) to the lowest-cost, most trusted arbiter of identity authentication: the bank. In our view, banks will do authentication to assign extra value to posts in knowledge bases such as Wikipedia and charge less. In fact, users who wish to remain anonymous but identifiable upon payment of a fee can and will in the future post on both free and fee-based repositories, among others.

Finally, the implication of proving the user's membership in a paid subscription service is the culmination of Greenlist's role as the penultimate application layer exchange as the user moves between locations and attempts to access movie and music downloads to entertain friends.

Implementation Plans for Interest Groups

In other embodiments, the invention can be used with a community of interest where identifiers, authentication, and transactions are related. Examples of such interest groups include digital rights management, air travel or ticket reservations or confirmations, and shippers or receivers of goods. Interest groups can be run with information stored in public or private databases. For each such interest group, the implementation plan includes the following elements shown in Figure 1:

• An individual, user, customer, company, or other identifiable entity that may be a Greenlist subscriber 120 .

• An organization, corporation or other entity that may be a Greenlist licensee 110 . The licensee acts as a registry, maintains the relevant remote portion of the Greenlist data 115, and is responsible for authorization and possible notification functions.

• An identifier applied to each subscriber. This identifier is determined by the interest group. An identifier may be associated with a subscriber generally, or such an identifier may be associated with a specific use instance (eg, incorporating a confirmation number for a purchased good or service).

- Transaction Processor 140 for authentication and authorization with Greenlist licensees based on the Subscriber Identifier. This transaction processor is (or represents) a stakeholder responsible for providing assets to a specific interest group.

• Public or private database 130 for queries, including public or private ENUM queries that map subscriber's phone number to subscriber's identifier, as appropriate for that particular interest group.

In the payment embodiment described above, the bank acts as a Greenlist licensee, and the subscriber's identifier may be a Linked Credit Account (LCA). Transactions are payment transfers.

In the healthcare implementation described above, the bank also acts as a Greenlist licensee. Transactions may involve payment transfers and/or routine or emergency access to medical records, and parties to the transaction are notified in the manner specified by the parties themselves at the time of registration. Notification preferences may be modified or enhanced by conditionally specifying who to notify, in what manner, etc. An example of this could be for a first responder to have authority to access medical information via a Greenlist's public identifier without the delay of additional authentication and authorization typically required by the owner of the information asset being accessed. For example, the owning party may be unaware. Notification that health care information has been accessed by the first responder can be sent to the owner of the information, their health care provider (eg, their primary physician), and immediate family members.

For digital rights interests, subscribers may be assigned subscription identifiers. Greenlist licensees (such as banks or other companies licensed as Greenlist registries) will certify users as stakeholders who manage digital assets. For example, an individual with a media subscription may wish to download or play a video or music clip. Media Company will authenticate the individual via Licensee. This instance is similar to a payment transaction: for a transaction, the asset is financial; for this instance, the asset is digital.

For ticket-based interest groups, examples include users accessing and printing hotel or event ticket reservations or confirmations, or passengers printing airline boarding passes. The identifier may be incorporated into the confirmation number of the purchased ticket or room reservation. In these instances, stakeholders are responsible for information-based assets (tickets, confirmations, or boarding passes). Stakeholders wish to authenticate users requesting access eg for printing. This is also similar to the use of the invention in payment implementations.

For the delivery and receiving stakeholder, the stakeholder is responsible for the physical asset. In one example, the shipper will not send or deliver the shipment until the user has been authenticated as the legitimate recipient of the shipment. In another example, the merchant will not release the item for dispatch until receipt of payment has been confirmed. Identifiers will be appropriate for specific transactions and/or transfers of physical assets.

This embodiment is related to the following patents concerning distribution of product information from producers: 5,913,210; 6,154,738; 6,418,441; 7,117,227. See also US Patent Application Publication No. 2006/0011720.

US Patent No. 6,418,441 discloses and claims a "Network Registrar." A block diagram (FIG. 6 of the patent) shows how a retailer's inventory control system sends a UPC code and an in-stock quantity to a shared server that executes the retailer's sales transactions. The patent proposes payment by the shared sales server using standard credit card methods - however, Greenlist is an enhancement to this prior art, which further reduces the cost associated with the transactions when physical assets rather than financial or informational assets are traded (moved). The cost associated with the party's authentication. Patent 7,117,227 covers an Object Name System (ONS) mechanism for cross-referencing an electronic product code (from an RFID tag) with an Internet address where information on the tagged product can be retrieved. Pending application 2006/0011720 contains claims covering a global data synchronization network that has become a standard mechanism for providing product information from producers to their trading partners.

While specific embodiments of the invention have been described for purposes of illustration, it is to be understood that the description is for that purpose only and that changes may be made by those skilled in the art without departing from the scope of the invention, which It should be determined solely from the words of the appended claims. Any detail in the description not contained in the claims themselves should not be construed as limiting the invention.

Claims (17)

1. the system that the paying party in the EFT and beneficiary is carried out authentication, said system comprises:

Banking computer, said banking computer is connected to the computing machine and the catalogue computing machine of paying party via computer network, and said paying party has at least one account and has obtained authentication for said banking computer in said bank;

Wherein, Said catalogue computing machine is applicable to first database of safeguarding certified registrant's information; Said registrant's information comprises the certified information of the said beneficiary that at least one the related credit accounts to said beneficiary identifies; Said catalogue computing machine also is applicable to via said computer network periodically provides the part of said first database to said banking computer, and the said part of said first database comprises the said certified information of said beneficiary;

Wherein, Said banking computer is applicable to safeguards second database; Said second database comprises the said partial data from said first database, and said second database also comprises the registrant's of the said part that is used for said first database ENUM data; And

Wherein, Said banking computer is applicable to from said paying party computing machine and receives the information that identifies said beneficiary; The said information that identifies said beneficiary comprises ENUM information and payment information; The said part of utilizing said first database is the said said related credit accounts that identifies the information mapping of said beneficiary to said beneficiary, and sends geld from least one account of said paying party to the related credit accounts of said beneficiary.

2. the paying party in the financial transaction is carried out the method for authentication, said method comprises:

Receive the information that comprises related credit accounts information and telephone number information via computer network from the authentic beneficiary that has account in Bank One Corp.;

Computing machine via said Bank One Corp. is related with URN with telephone number information with the said related credit accounts information of said beneficiary;

With the communication of the computing machine of secondary bank in send the information that comprises said telephone number information and said related URN to database; And

Receive fund to said related credit accounts with the electronics mode from the paying party account.

3. the method for the paying party in the financial transaction and beneficiary being carried out authentication, said method comprises:

Receive the beneficiary telephone number information via computer network from have the also authentic paying party of account in bank;

Utilize ENUM via the computing machine that is linked to said computer network with the related credit accounts associating information of said beneficiary telephone number information with said beneficiary;

Send the checking that said telephone number has been associated with the said related credit accounts information of said beneficiary to said paying party via said computer network;

Receive from said paying party via said computer network and to authorize, with from said paying party account to said related credit accounts money transfer; And

With the electronics mode from said paying party account to the said related credit accounts said fund of transferring accounts.

4. the method for authentication is provided, and said method comprises:

Receive certified registrant's information, said certified registrant's packets of information is drawn together registrant's telephone number and registrant's accounts information;

Can by with the electronic databank of the computer access of computer network communication in the said registrant's accounts information of storage;

With said registrant's information and ENUM data association to form related information;

Send said registrant's information to the catalogue computing machine;

Send said related information to directory user.

5. method according to claim 4, wherein said directory user is a bank.

6. method according to claim 4, wherein said directory user is a healthcare facility.

7. method according to claim 4, wherein said registrant's accounts information comprises related credit accounts.

8. method according to claim 4, wherein said related information comprises personal healthcare information.

9. the system that the transmit leg and the take over party of assets transfer is carried out authentication, said system comprises:

Banking computer, said banking computer is linked to the computing machine and the catalogue computing machine of transmit leg via computer network, and said transmit leg has at least one asset account and has obtained authentication for said banking computer in said bank;

Wherein, Said catalogue computing machine is applicable to first database of safeguarding certified registrant's information; Said registrant's information comprises the said take over party's that at least one interlock account to said take over party identifies certified information; Said catalogue computing machine also is applicable to via said computer network periodically provides the part of said first database to said banking computer, and the said part of said first database comprises said take over party's said certified information;

Wherein, said banking computer is applicable to safeguards second database, and said second database comprises the said partial data from said first database, and said second database also comprises the registrant's in the said part of said first database ENUM data; And

Wherein, Said banking computer is applicable to from said transmit leg computing machine and receives the information that identifies said take over party; The said information that identifies said take over party comprises ENUM information and payment information; Utilize the said part of said first database that the said information mapping that identifies said take over party is arrived said at least one interlock account of said take over party, and send assets transfer at least one interlock account of said take over party from least one account of said transmit leg.

10. system according to claim 9, wherein said bank are the licensees of said catalogue computing machine.

11. system according to claim 9, wherein said interlock account is said take over party's the identifier that may be encoded as URN.

12. system according to claim 9, wherein said payment information comprises the information that said take over party is identified.

13. system according to claim 9, wherein said assets transfer is actual to be the entitlement of transferring assets or transferring assets from the said take over party of said sending direction.

14. system according to claim 9, wherein said assets are payment or financial instrument.

15. being numerals, system according to claim 9, wherein said assets constitute thing.

16. system according to claim 9, wherein said assets are one or more actual object.

17. system according to claim 9, wherein said assets are information, right or access permission.

Images