Patent Application
20140006271
This invention relates generally to electronic payment processing. Specifically, this invention relates to methods of making payments to others regardless of the network on which the user enters the system.
Electronic payment systems are more cost effective than paper billing. The cost of generating and sending paper bills is usually higher and more cumbersome than sending payment electronically. Presently there are many devices and methods that electronically process bills. By way of example and not limitation, there are systems for electronically paying bills wherein the payor uses a home or office computer to access a centralized payment location or payment processor associated with the payee. Once the payor accesses the centralized payment location or processor, the payor can access the payor's bill and pay it by entering the applicable information from the payor's checking account or credit card and then authorizing a payment therefrom.
There also are other systems in which multiple payees forward their bills to a centralized payment service that gathers all the individual bills for member payors who then have to sign into the centralized payment service and authorize payment through either a registered bank account or credit card. There also are other centralized payment services that gather bills for each member payor and then forwards a listing of all of a payor's bills to the member payor as either a single or multiple electronic transmissions. After receipt, the payor can authorize payment through the centralized payment service by authorizing a debit from the payor's registered checking account or registered credit card. Some of these systems utilize single-item tokenization whereby the service generates tokens representing only the financial account information utilized in each payment transaction for security purposes.
A drawback to the prior art systems is that either the payor or the payee or both must be members of the centralized payment service, or the payor or payee must be a member of a certain provider's network, or have an account at a particular bank, or with a particular credit card in order to make a payment. A further drawback of the prior art systems is that, while individual credit card information may be masked via an individual item token, the systems do not contain a method for creating a unique and secure identifier that contains all of the data elements relating to the payment relationship between the payor and the payee. The absence of this identifier (or token) prevents parties with pre-existing payment relationships from being able to find and/or transact with one another across multiple networks or devices on a recurring basis in a secure and convenient manner.
Thus, one of the objects of the present invention is to create a unique identifier for each user and each payment relationship so that any network may be used to transmit payments, even if the payee is not a member of that network.
It is a further object of the present invention that a payment may be made by a payor regardless of which network or input device is used by the payor.
It is yet another object of the present invention to provide a method for making a recurring payment without the payor having to re-enter or store information about either the payor or about the payment relationship in multiple networks or locations for each transaction.
It is a further object of the present invention to provide a unique identifier to locate, authenticate, and take payment actions with respect to a third party with whom a payor has an existing payment relationship.
It is a further object of the present invention to provide a mechanism for sending electronic invoices or electronic payables notifications by creating a universal ID that prompts payment system participation by a target (i.e. recipient/third party) of the notification.
The present invention is a cross-network system and method for electronic payment processing using a universal ID (“PID” or token) that represents the payment relationship between two parties that includes but is not limited to various network profiles of each party to the transaction, third party credit information, the payment and credit history between the parties (the user and the target, i.e. the person/entity to whom a payment is going to be made or to whom an invoice or electronic payable notifications has been sent), sources that can be used and the networks from which the user can initiate the transaction, so that the user can send or receive a payment regardless of the point or type of entry.
The system of the present invention comprises a communication interface that can be a computer, telephone, cellphone, Ipad, Kindle, mobile wallet, or any other device that is capable of transferring and receiving information electronically. The communication interface may also be a unique network such as, but not limited to, Facebook, LinkedIn, Twitter, My Space, Gmail, Yahoo Mail, as well as closed loop buyer-seller networks such as Ariba, Salesforce.com, Alibaba, or any other private or public network so long as the network requires that each user possess a unique user ID and password to identify the user. In addition to the communication interface, the system of the present invention also comprises a processor that is electronically accessible by the system user through the interface. The system of the present invention also comprises one or more databases that may be accessed by the processor. The system databases reside either in one or more dedicated servers and/or in the system processor. In a preferred embodiment of the present invention there are at least four unique databases due to multiple networks, origins of payment and payment relationships (hereinafter referred to as a “PID”). The four databases comprise a user profile database in which profile information related to each system user is stored; a user network database in which network IDs are stored which identify the different networks and hardware devices belonging to each system user; a payment source database in which tokens representing the different types of electronic payment sources belonging to each system user is stored; and a PID database in which all of the PIDs/tokens for each system and the user's payment relationships are stored together with payment relationship details associated with each unique payment relationship. The PIDs/tokens are created by the processor and contain all relevant profile and network information from all of the databases pertaining to that particular user-target relationship so that any future payments between the user and target regardless of which one is paying the other, will be facilitated. Alternatively, in another embodiment of the present invention, the information related to each system user and/or the PID information may be stored locally on the system user's access devices.
The processor of the present invention is connected both to the communication interface and databases. It obtains and processes information from the system user interface to either create or access the database entries for each of the four databases for each particular system user as the user logs onto the system. The processor also creates unique user IDs, network IDs, and PIDs for each system user using a hash algorithm. The processor also facilitates the payments desired by the system user by accessing each database for each particular payment request or action being processed. The processor also sends notifications to the user if a payment transfer is not successful and to the user and target if the transaction is successfully completed.
Using the system and method of the present invention, a system user logs onto the system from the communication device at which time the user is authenticated. The processor then establishes if the user is a new or existing system user. If the user is new to the system of the present invention, the user is prompted to create a profile, which the processor causes to be stored within the profile database. In a preferred embodiment of the present invention, the profile contains basic information about the user such as, but not limited to, name, address, telephone number, and email address. It could also include Federal Tax ID, business type, state and federal vendor numbers, Dunn and Bradstreet reference number, etc. The profile information also may include all networks from which the user can access the system of the present invention and associated information and history from each of the registered networks. Once the profile is created, the processor creates and stores one or more network IDs for each user wherein each network ID corresponds to a specific external network to which the user belongs and from which the user can access the system of the present invention. By way of example and not limitation, if a user belongs to both Facebook and Gmail, a unique network ID will be generated for each of these networks and stored by the processor in the user network database as being associated with that particular system user. Each network ID contains authentication information such as the user's ID and password for each of the user's access networks.
In addition, at the user's option, the profile information may also include payment information which identifies one or more sources from which the system user can make or receive payments such as, but not limited to, bank account information, credit card account information, PayPal account information, gift card information, echeck/ACH information, mobile wallet information or any other type of electronic financial account information or source, which is then stored by the processor in the payment sources database and associated with that particular user. In addition, in a preferred method of the present invention, the user also may prioritize the payment sources into which payments can be received or from which payments can be made.
If the user is not new to the system, each time that the user logs into the system from a network not previously associated with that particular user, the processor generates a new network ID for that user which is stored in the network ID database as being associated with that system user. Each time thereafter that the user logs into the system from that network, the network ID will be accessed by the processor so that the user immediately will be authenticated.
Each time a system user wants to establish a new relationship with another person or entity (hereinafter “target”) for future payments or make a payment to or receive a payment from a new target, the processor requires the user to input certain identifying information about the target to create a target profile which may include, but not limited to, information about the relationship of the parties and the payment transaction being initiated, including but not limited to invoice details, payment details, credit information, transaction history, terms of payment and discounts offered. Over time the payment relationship information is adjusted or modified as transactions continue to occur between the parties and further information is contributed to the system by either the user or the target regarding that payment relationship. By way of example and not limitation, a user may use the system to send an electronic invoice or payables notification to a target wherein the user will initiate the communication by entering information about the target, details about the payment desired and other relevant information related to the payment relationship. In response thereto, the system will establish a new unique PID and a new profile for the target, such that the target upon receipt of the notification/invoice is enabled to become a user of the system and/or add further relevant information to the new unique PID. By way of another example and not limitation, the user can select from a list of user or network contacts those parties to whom or from whom payments will be made. The processor then creates a unique PID to identify that particular user-target relationship and stores the unique PID in the PID database. The PID that is created by the processor contains all relevant profile and network information from all of the databases pertaining to that particular user-target relationship so that any future payments between the user and target regardless of which one is paying the other, will be facilitated.
In a preferred method of the present invention if the user or target has chosen to add at least one payment source for transactions with the target, then a PID is created using a hash algorithm or the like which combines the user profile with the target profile and their payment source profiles. In a preferred method of the present invention if the user chooses not to add the payment source information relating to the target, then a PID is created which combines just the user profile with the target profile, and other available relationship details, but does not include the payment source.
In addition, in an alternative method of the present invention, the PID may also be stored within the user's hardware access devices' database or on both. The PID is stored so that future payments may be made securely between the same two parties (regardless of who is paying whom) without either one having to re-input the information relating to that relationship.
In a preferred method of the present invention, after the user logs on and is authenticated, either a list of registered targets and/or PIDs will be generated on the user's communication device by the system from which the user makes a selection. In an alternative method of the present invention, a static device such as, but not limited to, smart cards, FOB, or gift cards containing their own unique PID, can be used instead of the user selecting a PID/target from the user's list of PIDs/targets. Once the PID/target is either selected or entered into the system through a static device, the processor extracts the target information from the PID using the same hash algorithm or the like by which the PID was originally created. After extracting the target information, the processor either extracts the payment sources available for payment from the PID using the same hash algorithm or if no payment sources are contained within the PID, the processor searches the origin of payment database to determine what associated payment information is available for that user so that payment may be made. If there are several payments sources associated with the user and the user has prioritized the sources, the present invention tries to process a payment using the first payment source and continues trying each subsequent payment source, if any, until it can successfully transfer the funds and make a payment. If no successful transfer can be made, notification is sent to the user. If a successful transfer has been achieved, notification is sent to the user and the target.
In order to facilitate an understanding of the present invention, reference is now made to the appended drawings in which like numerals refer to like parts. These drawings should not be construed as limiting the present invention, but are intended to be examples thereof:
The present invention is a cross-network system and method for electronic payment processing using a universal ID (called “PID”) through which a user can securely and conveniently send payments to or receive payments from anyone who has access to the internet. Using the system and method of the present invention, a user can authorize the sending or the receipt of an electronic invoice or a payment to another person or entity regardless of the user's point or type of entry.
Referring first to
Referring first to
Communication interface 10 can be any hardware device having a platform capable of running applications and capable of receiving and sending information electronically. By way of example and not limitation, as shown in
The processor 12 of the present invention is connected both to the communication interface 10 and database 29. The processor 12 obtains and processes information from the communication interface 10 to authenticate or identify the user and either create or access database entries for each user as the user enters the system. The processor 12 also can create unique user IDs, network IDs, and PIDs for each user using a hash algorithm. In addition, the processor 12 facilitates payments made or invoices sent by the user to a target 100 by accessing information stored within the database 29 for each payment being processed.
The system database 29 resides either in one or more dedicated servers and/or in the system processor 12. Specifically, as shown in
By way of example and not limitation, if a user belongs to both Facebook and LinkedIn, a unique network ID will be generated for each of these networks and stored by the processor in the user network database as being associated with that particular system user. Each subsequent time that the user logs in from that same external network, the system will be able to recognize and authenticate the user.
At the user's option, the profile information may also include payment information which identifies one or more sources from which the system user can make or receive payments such as, but not limited to, MasterCard, Visa Card, American Express Card, bank account information, credit card account information, PayPal account information, gift card information, echeck/ACH information or any other type of electronic financial account information or source. This payment information is stored by the processor 12 in the user payment database 34 as sub-tokens. Each token that is generated by a payment processor represents each different type of electronic payment sources belonging to each system user. In addition, in a preferred method of the present invention, the user also may prioritize the payment sources from which payments can be made or in which payments can be received.
The database 29 also comprises a user PID database which stores a PID/token representing all relevant profile and network information from all of the databases related to a particular user-target/payor-payee relationship. In subsequent transactions between the parties, the same PID can be used to facilitate the transaction.
Each time a system user wants to establish a new relationship with another person or entity (“target”) for future payments or make a payment to or receive a payment from a new target, the processor 10 requires the user to input certain identifying information about the target to create a target profile which may include, but not limited to, information about the relationship of the parties, credit information, transaction history, terms of payment, discounts offered or any other related information. Over time the payment relationship information is adjusted or modified as transactions continue to occur between the parties.
In a preferred embodiment, the system provides a user the choice of selecting some or all of the user's network contacts as those parties to whom or from whom payments may be made. The processor then creates a unique PID to identify that particular user-target relationship and stores it in the PID database 36 for future use.
In another embodiment of the present invention, the information related to each system user and/or the user's PIDs are stored locally on the user's access device(s). In a further embodiment of the present invention, the PIDs are stored in both the system database and the user's access device(s). The PIDs are stored so that future payments may be made securely between the same two parties (regardless of who is paying whom) without either one having to re-input the information relating to that relationship.
Referring to
In addition, the first time a user enters the system directly through the system's website, a unique user ID and a password will be created for that user and stored by the processor 12 in the user profile database 30. However, if the user enters the system from another network 14, rather than logging directly onto the system's website, the processor 12 creates a network ID which represents the user's network and the user's username and password on that network. Each network ID is stored within the system's user network database 32. Thus, each subsequent time that a user enters the system of the present invention through that same other network, the processor 10 will match the network ID stored within the network database 32 with the credentials sent by the other network, to authenticate 41 the user. Thus, the user will not have to provide credentials to the system so long as the user logs onto the system from the same other network. Additionally, the PID may be made accessible to individual third-party networks for use together with any in-network tools that may exist in each case such as, by way of example, and not limitation, CRM, ERP, and accounting systems and tools and the like.
If a previously registered user logs onto the system from a new other network 46, another network ID will be created by the processor 12 and associated with that user and stored within the user networks database 32. This process is repeated each and every time the user logs in from a new network 46 or new device 10 that the user has not previously used. The next time the user logs into the system from any registered network (i.e. one for which a network ID has already been created and associated with that user), the user will not have to provide any credentials, as the processor 12 will recognize the user by matching the ID sent by the other network with the network IDs in the system's databank 32, thereby identifying and authenticating the user as shown in step 41.
If the user is either new or is a registered user wishing to add or change the types of payments that can be made by the system, the user enters relevant payment source information such as, but not limited to, bank account and bank routing numbers, credit card account information, echeck numbers, etc., which the system sends to a payment processor which creates a sub-token identifying each type of payment that the user can make. The payment sub-tokens are then stored in the user payment database 34 and become a sub-token within the system of PIDs.
Each time that a user initiates a payment request via an electronic invoice or payables notification, or initiates the making of a payment to a target, the processor 12 creates a token, which in a preferred embodiment is known as a PID. The PIDs are stored in the user PID database 36 shown in
Once a user is authenticated, the processor 12 presents the user with a list of targets (i.e. payees) with whom the user had a previous transaction such that there is an associated PID stored within the user PID database 36. By selecting a previous target, the processor 12 will retrieve the PID from the PID database 36 and immediately transfer payment according to the prior transaction as shown in steps 42 and 64.
If a PID is not selected or available, the processor 12 determines whether the user has accessed the system using a previously registered network or whether the network is new. If the user is signing on from a new network 46, the processor 12 creates a new network ID 48 which is stored in the user network database 32 shown in
Referring next to
After one or more PIDs have been created and associated with the user, the processor 12 presents the user with a list of targets who have PIDs associated with that user as shown in step 60. The user then selects the registered target as shown in step 78with whom the user has created a PID as shown in step 62 and then the processor goes through the steps shown in
Referring next to
In an alternative method of the present invention, a static device such as, but not limited to, smart cards, FOB, or gift cards containing their own unique PID, can be used instead of the user selecting a PID from the user's list of PIDs. Once the PID is either selected or input into the system from a static device, the processor extracts the target information from the PID using the same hash algorithm by which the PID was originally created. After extracting the target information, the processor either extracts the payment sources available for payment from the PID or if no payment sources are contained within the PID, the processor searches the origin of payment database to determine what associated payment information is available for that user so that payment may be made. If there are several payments sources associated with the user and the user has prioritized the sources, the present invention tries to process a payment using the first payment source and continues trying each subsequent payment source, if any, until it can successfully transfer the funds and make a payment. Once the payment is transferred, notification is sent to the user and the target.
While particular embodiments and techniques of the present invention have been shown and illustrated herein, it will be understood that many changes, substitutions and modifications may be made by those persons skilled in the art. It will be appreciated from the above description of presently preferred embodiments and techniques that other configurations and techniques are possible and within the scope of the present invention. Thus, the present invention is not intended to be limited to the particular embodiments and techniques specifically discussed hereinabove.
