SECURE ELECTRONIC PAYMENT METHODS

Abstract

This invention presents methods for secure electronic funds transfer and using electronic credit cards and debit cards in conducting purchases and making payments on the internet, over the phone, and when customer is not present. Methods described provide for generating instances of encrypted pay identifiers or pay identifier records, both of which are payer and receiver specific. Said pay identifiers are used in place of credit cards, debit cards, check numbers, and bank accounts, and as generated, are unique per transaction. Said pay identifiers if copied illegally cannot be used in a different transaction, therefore it discourages identity theft. Presented methods are perfect for use in hand held devices and in local, remote, and near field communication (NFC) payment applications.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation in Part of U.S. patent application Ser. No. 11/957,266 filed on Dec. 14, 2007 and claims the benefit of this application.

This application also cites the following related applications filed by the same person.

	Filing Date:	Inventor:	US Patent No:
11/129,827	May 16, 2005	Mehran R. Rasti	Abandoned
60/710,693	Aug. 23, 2005	Mehran R. Rasti	Provisional
11/506,476	Aug. 19, 2006	Mehran R. Rasti	8,069,256
11/957,266	Dec. 14, 2007	Mehran R. Rasti	Allowed
13/178,036	Aug. 16, 2011	Mehran R. Rasti	Pending

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not Applicable

REFERENCES TO SEQUENCE LISTING, TABLES, OR COMPUTER PROGRAMS TABLES

Not Applicable

BACKGROUND OF THE INVENTION

1. Field of Invention

In today's digital world many financial transactions are conducted electronically. Credit card information, money transfer orders, intra-bank funds transfer and the like, are all communicated in digital format across various types of network and media employing both, old and new methods of communication, including but not limited to phone lines, wireless phone bands, and the internet. Identity theft has been and still is a big problem facing the business and the business still has to pay large premiums to insurance companies covering such losses. Identity theft is considered theft of property even though what is stolen is in actuality digital data strings.

Credit cards, debit cards, and their associated bank accounts or accounts out of which a payment is made are referred to as pay objects to which a value is attached. A theft of a pay object is definitely a theft of property, and therefore must be prevented. Even the most advanced methods of payment, such as Near Field Communications (NFC) would not make electronic money transfer any safer if same old methods of payment are used. Procedures and methods as outlined in this invention offer one of the most secure methods to transfer money, shop and pay through digital pay objects (e.g. digital credit cards) using portable phone devices and computer media, even when desk top PCs are used. Methods presented in this invention are designed to prevent identity theft through theft of digital pay objects, before it occur.

2. Status of Prior Art

A charge card and a bank account number is an identifier, and since said identifier is traceable to an owner of said account, a bank account is therefore one of an identity identifier. This inventor introduced the concept of identity identifiers on May 16, 2005 when he filed application Ser. No. 11/129,827, and has been working on methods of protection against identity theft before that date. In that application he introduced appending one out of many passwords to a person's Social Security Number (SSN); therewith protecting peoples' SSN through concatenation and pairing of such dedicated passwords. Later on, by the way of Application No. 60/710,693 he introduced “Standard-Made-up Social Security Number (SMSSN)” as a way to protect peoples' Social Security as well as credit card numbers.

Semi-Fixed Identity Identifiers were introduced in patent application Ser. No. 11/506,476 filed on Aug. 19, 2006 by the same inventor leading to U.S. Pat. No. 8,069,256.

Later on, Variable Identity Identifiers were introduced in Dec. 14, 2007 through application Ser. No. 11/957,266 and the application areas for the protection of said identifiers were expanded via application Ser. No. 13/178,036, filed on Jul. 7, 2011.

U.S. Pat. No. 8,069,256, application Ser. No. 11/957,266, and application number 13/178,036 use an entity called “trustee” that issues, and manages identity identifiers and registers it to its owner entities. The methods used in said previous applications comprise substituting identity identifiers with proxy identifiers and encrypting said proxy identifiers with binary passwords and using receiver specific encryption rules in generating receiver specific encrypted instances of said identity identifiers.

In all of the above patents and patent applications, the inventor has included credit card and debit card and account numbers (i.e. charge cards) in the Semi-Fixed Identity Identifier category, thereby applying same methods of protection as those introduced for Social Security Numbers, and organizational Employer Identification Numbers (EIN), among other types of identifiers.

This application uses, modifies, and expands upon the similar procedures and methods of said previous applications and patents but focuses on the particulars necessary in protecting debit card and credit card account numbers while transacting electronically, from being stolen or misused through identity theft of its account numbers. In this application, identical methods, procedures, and similar data constructs are used to safeguard electronic funds transfer and forwarding of funds among people and entities (“payers and receivers”).

Outlined in this application are a few processes that are associated with the methods disclosed in the parent application. There is however a major difference between the methods disclosed in this application versus that of said parent application; in this application the credit bureau plays no active role as an intermediary entity, instead a bank or a payment processor entity performs its own function in completing the claimed four way process.

BRIEF SUMMARY OF THE INVENTION

A “pay object” is a pay instrument such as a check, a debit card, a credit card, even a signature, or a fingerprint, as long as said pay object is linked to a bank account. A bank account itself is also considered a pay object. In the digital world money changes hands through character strings representing accounts and account numbers that are linked and associated with said pay objects. A person or an entity usually owns more than one pay object and pay object accounts out of which money can be withdrawn and paid to a receiver, or received from payers.

A “proxy pay identifier” is a “digital string” that replaces a “real” or an “original” pay object account number. The purpose behind using a “proxy” is to hide the real account number from exposure to the public during the course of doing business. A proxy pay identifier is created, managed, and paired to its original account number through a “trustee” organization. In a database, called payer database, each proxy pay identifier is stored and associated with an account number of a pay object, and is also associated with its account owner name (payer name), address, and other account information. Data column (b) in FIG. 1A shows some example pay objects, and column (c) in FIG. 1A shows proxy pay identifiers, each associated with one of said pay objects. Said trustee also designates a numeric index to each of said pay objects (FIG. 1A, column (a)), thus enabling a payer of a pay object account number to retrieve the corresponding associated proxy pay identifier by simply entering the index corresponding to the intended pay object, on a hand held device, a computer or on a pay terminal. See FIG. 1A.

As shown in FIG. 1B, by entering an index number of data-filed (a), along with said proxy pay identifier of data-filed (b), one or more of the corresponding identifier passwords of data-field (d) is/are also selected.

Data-field (f) in FIG. 1B shows a “rule number”. A rule number is entered by a payer when prompted by a running application program. A rule number calls an associated encryption and/or a hashing method that is used in transcribing data-fields (c), and data-fields (d) into an “encrypted pay identifier” (a “Pxy id”). The trustee assigns a pre-designated rule number to an entity or a person who intends to receive payment from said payer. Said receiver person or entity (“receiver”) comprise a person, individual businesses, government institutions, other forms of organization entities, that hold a “receiver account”, as defined.

By using an application program and entering different rule numbers, hence different encryption algorithms (“rules”), different instance of a said encrypted pay identifier are generated. The resulting received encrypted pay identifiers (e.g. credit card account number) would be different for different businesses and receivers. Thus by using said encrypted pay identifier data strings instead of credit card numbers, for example, theft of credit card numbers will become a phenomenon of the past.

In order to make electronic money transfer and charging more secure, one or more of the said identifier password strings of data-field (d) in FIG. 1B are also used. Said identifier password strings are also dependant on the payer owned said pay object account number. This follows that an imposter other than the “payer” of said charge card or pay object account number would not be able to charge or send money illegally, unless the imposter has gained access to both, the proxy pay identifier, and also its associated identifier password strings through theft of the device containing said data fields.

To circumvent the theft of the said proxy pay identifiers and identifier passwords, hand held computers, phone devices, and storage media are required to be equipped with hardware and software access protection mechanisms to circumvent unauthorized access to its data. Use of “access passwords” coupled with such protection mechanisms such as the well known “sleep mode, when not in use” is a requirement. Another layer of protection is also available. Proxy pay identifiers and identifier passwords can always be changed. In case of the theft or loss of the device, the “payer” is able to login to his/her computer account in trustee's secure computer site and put in a “request for change of personal information”.

An added rationale behind using proxy pay identifiers is the creation of an added level of abstraction in cases of reverse-engineering of the encrypted pay identifier data strings and the discovery of its comprising elements. In worst case scenarios, proxy pay identifiers are changeable by owners of said pay object accounts upon request through said trustee; by being associated with a pay object's fixed account number (“real account number”), said proxy pay identifiers serve to prevent the exposure of the real account number to the public and data hackers thus providing an added arsenal against identity theft, reverse-engineering, and fraud.

As depicted in FIG. 1B, an encrypted pay identifier is generated by applying one or more of character combining, comingling, hashing, and/or encrypting techniques called by a rule number (f), on a proxy pay identifiers (c), one or more of the identifier password strings (d), and a charge or transfer amount (e).

In a different embodiment of the invention, as depicted in FIG. 2A, a “constant character string” (data field (h)) is also introduced into the hashing and encryption data stream, for added security.

Trustee supplies all application programs (Apps) necessary to generate an encrypted instance of a proxy pay identifier. Said applications are used in hand held computers and variety of cell phones (e.g. Android© and iPhone© devices) having sufficient memory and processing power to run said program. Needed programs, proxy pay identifiers, and identifier passwords are either downloaded to said devices, or are supplied through variety of plug-in devices such as memory, laser, optical, and intelligent cards, processors and communication links that are supplied by said trustee. Said plug-in device or card is inserted into a hand held cell-phone, a personal computer, or alternately into a pay terminal unit of a computer device that is connected either remotely or on site to a computer system of a “merchant/receiver of funds”, a “trustee”, a “bank”, or a payment processor entity. These devices should provide for an access password protection mechanism before being able to run said trustee supplied Apps and also for the protection of the data resident in the plug-in devices, processors, and similar appliance.

A person having access to said hand held cell-phone, a pay terminal, or a computer device, starts the trustee supplied App/program by entering the correct access password, and enters three data items into the device. The first comprises a one or two digit index for selecting a proxy pay identifier associated with the pay object to be used in payment of funds; said index also retrieves the associated identifier password string(s), and/or a constant character string. The second number is the amount of purchase or money to be transferred (“transfer amount”) to said merchant/receiver. The third number entered, is the rule number that has been pre-assigned to the intended “receiver” of funds by said trustee. Upon completion of said data entry, an encrypted instance of the selected pay object is produced and depending on the embodiment that is being utilized, is sent to the trustee computer system either directly, or through a receiver or a merchant to be paid.

Since the records of both the payer and the receiver of said encrypted pay identifier exist in the trustee's databases, the trustee is able to decrypt the encrypted pay identifier to its comprising elements of proxy pay identifier to recognize the payer and also to use the transmitted rule number to identify the receiver. There are more detail procedures listed to ensure the legitimacy and accuracy of this operation. One example being the use of said identifier password to ensure who the payer is, as compared to the received proxy pay identifier that points to the pay object and its payer in said payer database. Other data comparison tools to mention are the comparison of names of both the payer and the receiver transmitted versus those existing on said trustee databases.

In the last step the trustee sends said information to the bank or a payment processor to debit the sender account and to credit the receiver account with the amount of purchase/transfer, less applicable fees if any.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1A: A proxy pay identifier associated with its corresponding pay object is selected by entering an index number. This figure shows selection of a proxy pay identifier by furnishing a numeric index to its associated pay object.

FIG. 1B: Making of an encrypted pay identifier by typing in an index to a pay object, the amount, and receiver's rule number. This figure shows the selection of a proxy pay identifier, and at least one of its related identifier passwords by entering the index to its corresponding pay object. A transfer amount and a receiver's rule number are also entered manually to generate an instance of an encrypted pay identifier.

FIG. 1C: Sample encrypted pay identifier. Said encrypted pay identifier is also referred to as a “Pxy pay Id”, or simply as a “pxy id”.

FIG. 2A: Using an additional constant character string, data field (h), in generating an encrypted pay identifier. This is a block flow diagram of how an encrypted pay identifier is made in a different embodiment of the invention, having added a constant character string field (h) into the process.

FIG. 3A: Application process to trustee for registering an electronic payer's account. This is a block diagram of the process necessary for a payer to register with a trustee in order to be able to use an electronic charge card or to transfer funds electronically between bank accounts.

FIG. 3B: Application process to trustee for registering an electronic receiver's account. This is a block diagram of the process necessary for a receiver to register with a trustee in order to receive funds electronically.

FIG. 3C: Charge or money transfer data flow chart using encrypted pay identifier. As a continuation of the process in FIG. 3A, the diagram shows data elements and the steps among the four entities: a payer, a trustee, a bank, and a receiver.

FIG. 3D: Charge or money transfer data flow diagram using a pay identifier record. This is a continuation of the process of FIG. 3A in a different embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

A. Definitions

A “digital string” is at least one of an alpha-numeric and/or a binary character.

An “entity” is one of a person, an organization, a business, a corporation, an association, a governmental unit or an agency. This invention uses a four way interaction between four entities being: a payer of funds, a receiver of funds, a trustee, and a bank.

A “pay object” is a digital string representing an account number of a pay instrument such as the account number of a credit card, a debit card, a bank or any account out of which funds are debited electronically.

A “payer” is identified by at least one identity identifier, and is one of a person or an entity owning ownership, usage and withdrawal rights to one or more of said pay objects' account numbers.

A “receiver” is one of a person or an entity that is identified by at least one identity identifier, and is the one seeking to receive and be credited with the funds transferred or the funds said payer was charged.

A “trustee” is an entity that among its other functions verifies and authenticates the identity of said payer, verifies or assigns one of an identifier that uniquely identifies said pay object, authenticates said payer's ownership of rights of usage and withdrawal of funds out of said pay objects account, verifies and authenticates the identity of said receiver and said receiver account number, in addition to many other roles and functions that will be outlined later. Please refer to the section outlining all of the functions and duties of the trustee.

A “proxy pay identifier” is formed as a digital string by said trustee organization and each is associated with one “pay object” (i.e. digital pay instruments such as charge card account or other types account numbers) in trustee's “payer database”. The function of a proxy pay identifier is to prevent the exposure of a pay object's real account number from the public.

B. Purpose of the Invention

Methods described are designed to protect a payer against identity theft when using an account to electronically send funds to a receiver or to electronically charge an item to a credit or a debit card account while shopping online or when not present in a location where the transaction is taking place. The methods provide sufficient track record of the steps in the payment process to protect the receiver of funds, as well. In time, the security provided by the methods of this invention shall benefit the receivers of funds in lowering their processing fees, since the insurance premiums paid by funds processors and banks will drop as fraud and identity theft decreases. The system is designed for real time implementation and online use, in which both the receiver of funds and the payer of funds receive an email or a text message (SMS) alert of a pending transaction, ideally within minutes after the start of a transaction. Said feature protects both sides of the transaction, against any errors, system malfunction, or fraud that may take place, in which case a fraudulent or an erroneous transaction is investigated and reversed.

A distinct security feature of this invention is that a charge card or a funds transfer transaction is made to be both payer, and receiver specific. This is done by using payer-specific passwords, and having different rule numbers (encryption rules) for different receivers and merchants. These features bar sharing, copying, or stealing of account information that is used in funds transfer or charging operations initiated by a known payer, intended to a known receiver, and authenticated by said trustee. In addition, use of proxy pay identifiers protect the owners of accounts, and the banks handling such accounts, against the original account numbers to become exposed to the public for variety of reasons while in transmission and processing, including reverse engineering of data strings in transit. Yet another added security feature is the addition of said “identifier password” strings; each being associated with a known pay object of a known payer.

C. Methods and Procedure

This invention uses as its basis some of the same methods and procedure already presented in the parent application, but improves and modifies it specifically for applications used in making secure electronic credit and debit card payments and electronic transfer of funds.

An entity or a person (“a receiver”) who expects to charge its customers and cliental to receive a transferred funds using any of the methods of this invention is required to register with said trustee as a merchant or a receiver of funds and to open a “receiver account” in said trustee's computer system. See FIG. 3B.

Said receiver shall supply to, and as requested by said trustee when applicable, its entity name, the name(s) of its account representatives, its bank account number, bank account details, physical and electronic addresses, phone numbers, in addition to the names on the account and a requested credit history. See Event Label 1 of FIG. 3B.

After checking and verifying the validity of the entire supplied information by said receiver, the trustee records said receiver's entire supplied information in said trustee's “receiver database”. In addition, said trustee creates a secure computer account for said receiver. Said trustee also provides said receiver with all of the necessary membership information, login user name, and changeable login access passwords. See Event Labels 2 and 3 of FIG. 3B.

Said trustee issues a rule number for said receiver and stores said rule number along with all other information of said receiver in said trustee's “receiver database”. A rule number comprises an alpha-numeric string that is assigned solely for an entity or a person receiving funds. More detailed information regarding rule numbers are found in the following sections. See Event Labels 2 and 3 of FIG. 3B.

An entity or a person (“a payer”) of a credit card, debit card, or a bank account (“pay object”) who expects to charge a purchase, charge a fee, or to send funds electronically by using any of the methods of this invention is required to register its “payer account” with an organization called, trustee. Said payer is a person, or one of the said entity who owns or has been designated by his or her organization as the care taker and custodian of said charge and/or funds transfer account”. See FIG. 3A.

As depicted by Event Label 1 of FIG. 3A, said payer shall supply to the trustee all of the information said trustee deems necessary, including: an authorized person's name as the payer name, along with the name of the entity the payer represents. Said payer being a party to a contract shall also supply at least one bank account number with account owners' names, credit histories, physical and electronic addresses, phone numbers and other account details as requested by said trustee. Said payer also supplies said payer identity identifier(s) including Social Security Number (SSN) and/or when applicable said entity's Employer Identification Number (EIN), charge and bank account numbers, and all identifying and credit history information related to said person, entity, and accounts said trustee should require.

After checking and verifying the validity of the entire supplied information said trustee records said payer's entire supplied information in a secure “payer database” and provides said payer with a login account user name and a changeable access password in its secure computer system; see Event Label 2 of FIG. 3A.

For each of a pay object (data field (b) in FIG. 1A) and a payer account the payer registers with the trustee, said trustee issues a “payer data-set” comprising:

• • a. A numeric index pointing to each and every pay object that the payer registers with trustee; data field (a) of FIG. 1A, FIG. 1B, and FIG. 2A.
  • b. One proxy pay identifier as depicted in data field (c) of FIG. 1A, FIG. 1B, and FIG. 2A). A proxy pay identifier is assigned to each of a payer's pay objects that the payer has registered with said trustee.
  • c. At least one identifier password strings as depicted in data field (d) of FIG. 1B, and data field (d) in FIG. 2A.
  • d. In a different embodiment of the invention, said trustee issues one or more added “constant character string”. This is shown as data field (h) in FIG. 2A. Depending on the encryption rule and methodology used, said constant character strings provide increased length, more processing options in adding variety, and allow added complexity when generating said encrypted pay identifiers in the real world applications.

A “payer data-set” comprises said payer name, along with data fields as enumerated above, in data items “a.” through “d.”, and data items (a), (c), (d), and (h) as shown in FIG. 2A.

The trustee records said payer data-set along with said payer name, identity identifier, said payer account number, payer's electronic addresses, phone number(s), and payer credit information in a payer identifier record that is indexed to both said pay objects, and to said payer identity identifier. Said payer data-set along with all other payer identifier records are stored in a “payer database” and indexed to said pay object account numbers within said trustee's secure computer system.” See Event Label 3 of FIG. 3A.

For each of the registered payer, said trustee makes available for download or execution within trustee's computer domain, all Apps, programs, and data-sets necessary to generate and produce instances of said encrypted pay identifiers.

In step 3, above, each of said data-set within said payer identifier record is also associated with and indexed to each of said payer identity identifier. At the completion of the registration process said registered payer may login to his or her computer account at the trustee's site and download said data-set with its accompanying Apps and processing programs to his or her plug-in memory, personal or hand held computer and/or phone device. Depending upon a payer's need and the type of processing equipment, a copy of said payer data-set is recorded in a read-only plug-in memory module/card and is sent to the registered payer via secure mail. See Event Label 3 of FIG. 3A.

In one embodiment of the invention a single set of payer data-set is optically burned in, bar-coded, magnetically recorded on a card, or saved in an intelligent card's memory. The media and technologies used in producing a “payer data-set card” may vary. Payer data-set cards comprising intelligent cards having embedded memory, RFID cards, optical cards with multi-dimensional bar codes, dotted matrices, colorful coded graphics, or variety of optical-magnetic media and laser technology to allow storage of the required number of characters offering the required error checking and accuracy tolerances.

Said payer data-set, comprising said payer name, proxy pay identifiers, identifier passwords, and constant character strings for pay objects, are downloaded, or transferred out of plug-in memory, and card devices then used in hand held computers, phone devices, or variety of other apparatus to enable said payer to generate instances of pay identifiers on-the-go, remotely, locally, and at retail sites. There are several alternative methods of fulfilling electronic payments. As said, the entire payer data-set, or parts thereof may be downloaded to a hand held computer device and transferred from said plug-in memory to a computer, a pay terminal, or downloaded into computers, pay terminal stations, and variety of other “point of pay devices” as well as a personal computer at home, a computer interface, or on computerized pay terminals of sorts at business sites. See Event Label 3 of FIG. 3A.

Alternately, a payer data-set card is built-in or is plugged into a hand held computer/phone device, a personal computer, or other portable devices with sufficient storage, adequate processing power, and internet connectivity capabilities (“portable device”). In one embodiment for applications requiring less security and simpler implementations of this invention, custom made processing Apps and programs that are designed and certified by said trustee are downloaded into the portable device or are copied out of plug-in memory into said portable devices. A “local processing mode” is when said application program codes execute within said portable devices, or on a pay terminal of a receiver having been equipped and embedded with chips containing the necessary code to produce encrypted or non-encrypted pay identifier.

For those applications requiring better security and a full implementation of this invention, said application programs necessary to encrypt and generate said encrypted pay identifiers usually reside on the trustee's secure computer site (“remote processing”). In other embodiments, a mix of local processing in combination with remote processing is used. Following is a partial list of devices in which said application programs are executed from and the media said pay identifier are generated on. Said devices include at least one of a processor unit, a plug-in module, an intelligent card, a telephonic computer device, a portable computerized device, a built-in module, a receiver's computerized pay terminal, a vending or dispensing machine of sorts, or a computerized device. Within the mentioned devices, said processing is performed locally, remotely, or in a mixed mode through one or more of wired and/or wireless links, data bandwidth (links), telephone links, and/or through secure internet links to said trustee computer system.

Yet in a different embodiment, a trustee custom made pay terminal (“a customized terminal”) is used. Said customized terminal is installed in the merchant/receiver pay terminals at user sites, and executable versions of the processing programs are burnt in and embedded in the circuit boards of said pay terminals, including but not limited to cash register terminals, parking meters, vending machines, Automated Teller Machines (ATMs), or variety of other payment accepting machines (“trustee approved devices”). Following is a partial list of devices where said encrypted and non-encrypted pay identifiers are produced on, stored, and include the media from which said pay identifiers are delivered from. Such a list include: a two dimensional (e.g. a QR bar code), or a multidimensional bar code, an optical or laser readable format, an RFID (Radio Frequency Identification) card, a plug-in module, a magnetic card, an intelligent card, a telephonic computer device, a portable computerized device, a built-in module, a receiver's computerized pay terminal, a vending or dispensing machine of sorts, a computerized device, and/or is delivered through a wired port, NFC (Near Field Communication), wireless link, a data bandwidth, a telephone link, and/or an internet link to said trustee computer system.

In Event Label 4 of FIG. 3A, said payer has access to a trustee approved device that is capable of generating different instances of encrypted pay identifiers.

The process continues in FIG. 3C, Event Label 4, where by executing said application programs and supplying an access password, said payer is able to generate an encrypted pay identifier, based on the rule number of the intended third party receiver of funds or a merchant. As explained in the Summary of the Invention and in other sections, a rule number is associated with one or more sets of character comingling, character displacement, character manipulation, encryption and/or hashing routine codes (“an encryption rule” or “a rule”). By setting a custom made rule number for different merchants and receivers of funds, we create different encrypted pay identifiers for different merchants and receivers of funds by applying a different encryption rule in comingling a proxy pay identifier with one or more identifier passwords, and optionally with a constant character string. See FIG. 2A. In this way, merchant or receiver “A” cannot use the same encrypted pay identifier with merchant or receiver “B”. Therefore for example, if a card number is stolen in a gas station, it cannot be used in an online store.

In FIG. 3C, Event Label 5, said payer asks the merchant or the receiver of funds for his or her receiver or merchant specific rule number and inputs said rule number in its hand held computer, a said portable device, a pay terminal, a cash register, a vending machine or a similar device. Depending on existing hardware and software architecture, any of the mentioned local, remote, or mixed processing is used to generate an encrypted pay identifier (i.e. encrypted charge/transfer account number) for its subsequent delivery to either of a receiver of funds (merchant), or to said trustee. See Event Label 6, of FIG. 3C.

In generating an encrypted pay identifier, the executing application program performs comingling, hashing, and encryption operations on the a proxy pay identifier of data field (c), along with an identifier password string (d) as shown in FIG. 1B. As mentioned already, the substitution of a proxy pay identifier (c) in lieu of its corresponding real charge or account number is for security reasons.

An encrypted instance of a pay identifier is generated according to the basic process of FIG. 1B, as follows: After entering an “access password”, the trustee furnished application program (App) is executed, and said payer is prompted by the program to enter an index (a) for selecting a pay object (i.e. one of said payer's credit cards, debit cards, or an account number of data field (b) as his or her source of funding. See FIG. 1A.

According to FIG. 1B, payer selection of index (a) causes selection of the selected indexed and associated proxy pay identifier (c), with one or more of the associated identifier password strings (d). Upon a special request to the trustee, said payer can be setup with the option of choosing his or her own identifier password string or a phrase (d) and entering it manually. At this point said payer is subsequently prompted by the App to enter the amount of charge or money transfer (data field (e)), as well as the receiver or merchant specific rule number (f) into said application program to generate an encryption pay identifier.

In a secure embodiment of said invention as depicted in the process of FIG. 2A, constant character string data field (h) is added into the encryption stream. As an added security measure said payer name is optionally encoded and hidden into said constant character string (h). The latter embodiment offers the most secure option for generating an encrypted pay identifier offered through methods of this invention.

According to FIG. 2A, a payer selects and enters index field (a) causing automatic selection of data fields (c), (d), and the constant character string field (h).
Said payer then inputs the charge or transfer amount of field (e), and the receiver or merchant specific rule number (f) for the comingling, hashing, and encryption processes to take place. In another embodiment said payer is prompted to manually enter an identifier password string (d), or a phrase.

In Event Label 6, of FIG. 3C a “temporary data record” comprising said encrypted pay identifier, said payer name, and said receiver rule number is passed to said receiver computer system or said receiver pay terminal. In a different embodiment of the invention, said bank, a payment processor, or said trustee receives one of said encrypted pay identifier comprising a hash of at least one of said payer name, said pay object account number, said receiver account number, said receiver name, a payment amount, and one of said rule number.

In Event Label 7, of FIG. 3C said receiver sends said temporary data record to said trustee computer system.

Upon receipt of said encrypted pay identifier in step 8 of FIG. 3C, said trustee receives payer name, said rule number and decrypts and/or un-hashes said received encrypted pay identifier into its components of the proxy pay identifier, amount of charge, and identifier password(s) by using the accompanying transmitted rule number. Said trustee uses decryption and un-hashing algorithms matching said rule number in decrypting and un-hashing said encrypted pay identifier.

In step 9 of FIG. 3C, said received proxy pay identifier, along with said payer name are matched up against the entries in trustee's “payer database”, and the payer's real charge or account number is retrieved out of said database.

In step 10 of FIG. 3C, said payer's real charge or account number, along with the amount of charge or transfer are ready to be sent to the bank for said amount, less any applicable transaction fees, to be debited out of said payer account number, according to step 11 of FIG. 3C.

In step 12 of FIG. 3C, an email and/or a short text message (SMS) is sent to said payer, informing him or her of the pending charge or funds transfer transaction. Said payer has the option to report to said trustee if the outstanding transaction is not acceptable or is fraudulent, so that the trustee may void said transaction or take other necessary actions.

In continuation of step 8, as designated by Event Label 8 of FIG. 3C, said trustee receives the rule number belonging to said merchant or receiver of funds. In step 13 of FIG. 3C, said rule number is entered into said trustee's “receiver database” and the receiver/merchant name along with receiver/merchant account number are retrieved out of said receiver database. This corresponds to Event Label 14 of FIG. 3C.

In step 15 of FIG. 3C, the name and the account number of the merchant or receiver of funds, with the amount of the charge or funds transfer, less applicable charges and transaction fee is transmitted to a bank to be credited to said merchant or the receiver.

In step 16 of FIG. 3C, an email and/or a short text message (SMS) notification is sent to said merchant or receiver of funds whose name and account information had been retrieved out of said receiver database. If a charge processing terminal was used, said short text message also appears on said merchant/receiver processing or pay terminal.

Event Label 17 of FIG. 3C shows that the merchant or receiver of funds is paid via a sum as a credit to its bank account after all applicable fees are debited, and after said payer's pending charges/transferred sums and fees are cleared through the bank as a debit out of said payer account.

Please note that depending on the policies and procedures set between the trustee any payment processor and/or the bank involved, the order of performing the steps of Event Labels 11 and 12 as well as procedures of Event Labels 15 and 16 in FIG. 3C are interchangeable.

In a different embodiment of this invention, partially encrypted pay identifier records are used as opposed to said encrypted pay identifiers that were described above. In this process what is depicted in FIG. 3A is followed by the process as shown in FIG. 3D.

In this embodiment, the above methods numbered [C1] through [C17] remain the same, and we continue our process starting from Event Label 4 of FIG. 3D, as follows:

In Event Label 4 of FIG. 3D, after entering an “access password”, said payer initiates the execution of the trustee furnished application program (App). Said program prompts the payer to enter an index (a) to a pay object (b), as shown in FIG. 1A, causing a selection of one of said pay object accounts as the funding source. As depicted in FIG. 1A, by selecting an index from data field (a) and selecting a pay object, the associated proxy pay identifier (c), and said associated identifier password (d) are moved into a pay identifier record.

In FIG. 3D, Event Label 5, said payer asks the merchant or the receiver of funds its receiver-specific rule number and inputs said rule number in the hand held computer, said portable device, or the variety of other devices and appliances as enumerated in paragraphs [C15] through [C17].

By following said trustee supplied program prompts, after entering said index number, the executing program prompts said payer to enter the amount of charge or transfer, and to also enter a rule number. Upon entry of said data, the executing program augments said pay identifier record with the entered transfer amount, and said rule number. The completed pay identifier record is now transferred to said trustee, using a secure data link or the internet. See FIG. 3D, Event Label 6.

A pay identifier record is a binary string comprising said receiver rule number, a transfer amount, and at least one of the data fields of said payer data-set. As indicated before, said payer name is also included in said payer data-set. In a said pay identifier record at least one of the fields in said pay identifier record is not encrypted. The distinction between a temporary data record and a pay identifier record is that in a pay identifier record not all, but at least one of the data fields of said payer data-set is encrypted or hashed.

In one embodiment of the invention, said pay identifier record comprises a date-dependant hash of the at least one of said payer name, said receiver name, said identifier password string(s), a payer account number, a receiver account number, a transfer amount, and a rule number.

In this embodiment as depicted in FIG. 2A, in constructing said pay identifier record the methods allow said payer using any of the said local, remote, NFC, or mixed processing modes to transfer said his or her payer data-set data out of a plug-in memory or a card into a pay apparatus including, but not limited to: personal and handheld computer, merchant or receiver's charge terminal, cash register, dispensing or vending machines of sorts, parking meter, or pay terminal of sorts. A payer device is used to transport the data fields of said payer data-set residing in a plug-in memory, on a laser, optical, or an intelligent card into any of the above mentioned pay apparatus (devices). In doing so, any combinations of the mentioned local, NFC, remote, or mixed modes are used to transport and transfer the data fields of said pay identifier record into said pay apparatus.

In step 6 of FIG. 3D, said payer transmits said pay identifier record comprising said proxy pay identifier, said payer name, said identifier password, said transfer or charge amount, and said receiver rule number to said trustee's secure computer interface.

In one embodiment said payer name is embedded in said pay identifier record, or for added security said payer name is eliminated in the data transfer of Event Label 7 of FIG. 3D to said trustee. Instead, said payer name is retrieved out of said trustee's payer database through matching of the transmitted proxy pay identifier with the one stored in the payer database.

In cases where said payer name is delivered to said trustee as part of said pay identifier record, by matching the transmitted proxy pay identifier with the proxy pay identifier resident in said payer database, said associated payer's name is retrieved and compared to the one received as part of said pay identifier record. This feature provides a validation of the transmitted record in the pending transaction. As an added validation measure, the associated pay object account number is matched against the pay object account number that is retrieved from the payer database through said matching of the proxy pay identifiers. See Event Label 8 of FIG. 3D.

As shown in Event Label 9 of FIG. 3D, said payer's name and payer's real account number are passed from said trustee to a payment processor and eventually to the bank that holds the payer account. Said payment processor and/or the bank may choose to add a transaction fee to the amount to be debited from said payer account.

As shown in Event Label 10 of FIG. 3D, said trustee notifies said payer of the scheduled pending account debit resulting from said charge or money transfer transaction via an email or via short text messaging system (SMS). Said payer has the option to report to said trustee if the outstanding transaction is not acceptable or is fraudulent, so that the trustee may void said transaction or take other actions necessary.

In continuation of the process as designated by Event Label 7 of FIG. 3D, as part of the transmission of said pay identifier record, said trustee receives the rule number belonging to said merchant or receiver of funds. In step 11 of FIG. 3D, said rule number is entered into said trustee's “receiver database”.

Said receiver/merchant rule number is used to retrieve the name and the account number of said merchant/receiver from said receiver database. See Event Label 12 of FIG. 3D.

In step 13 of FIG. 3D, the name and the account number of said merchant/receiver of funds, with the amount of the charge or the funds transfer, less applicable charges and transaction fees, is passed from said trustee to a payment processor and eventually to the bank that holds said receiver account, to be credited to said merchant or the receiver of funds.

In step 14 of FIG. 3D, an email and/or a short text message (SMS) notification is sent to said merchant or receiver of funds whose name and account information had been retrieved out of said receiver database. If a charge processing terminal was used, said short text message also appears on said merchant/receiver pay or processing terminal.

Event Label 15 of FIG. 3D shows that the merchant or receiver of funds is paid via a sum credited to its bank account, after applicable transaction fees are deducted. Said credit is also pending said payer's charges and transferred sums plus all applicable fees to be cleared through the bank as a debit against said payer account.

Please note that depending on the policies and procedures set between the trustee any payment processor and/or the bank involved, the order of performing the steps of Event Labels 9 and 10 as well as procedures of Event Labels 13 and 14 in FIG. 3D are interchangeable.

D. Properties of Data Fields Used and its Features

A “pay object” is a digital string representing an account number of a pay object; said pay object is an account number of a credit card, a debit card, or any account through which funds are sent and received electronically. A pay object comprising one or more of said digital string designated to uniquely identify the belonging of said pay object to a payer person or a payer entity. A payer usually owns more than one registered pay objects with the trustee.

A “proxy pay identifier” is formed as a digital string by said trustee organization and each is associated with one “pay object” (i.e. digital pay instruments such as charge card account or other types account numbers) in trustee's “payer database”. In one embodiment of the invention, a proxy pay identifier is obtained by applying a hash algorithm to an original or real account number of a pay object. Proxy pay identifiers create an added level of anonymity in hiding from the public a payer's pay object (i.e. charge card or other account number). For example, for a real credit card number, a trustee assigns a “proxy pay identifier”, an alpha-numeric or a binary string. The other hidden advantage of having proxy pay identifiers is to protect the real identifiers in cases of reverse-engineering and attempts in breaking the encrypted identifiers in use.

An “identifier password” comprises one or more of binary data strings used in the creation of encrypted pay identifiers. Where unencrypted pay identifiers are used, the transferred said identifier password can be tested to trace the transmitted pay identifier record to its payer. One or more of the identifier password strings are associated with the each of said payer's pay object; therewith making said generated encrypted proxy charge/transfer numbers to be both, payer, and pay object account specific. In addition, said identifier passwords are usually generated in being long strings that contain binary characters from the extended UTF (Unicode Transformation Format). This design feature incorporates added security by making the extended range of said UTF characters available to encryption routines, and also makes the resulting encrypted pay identifiers hard to remember by human beings and hard to write down.

In FIG. 2A we have introduced “constant character strings”. The quest for having built-in security into the methods of this invention does not stop with having said identifier passwords. In one embodiment of the invention, additional constant character strings containing UTF characters, are also employed into the character comingling, hashing, and encryption processes. Constant character strings make added options available in designing more complex and diverse encryption algorithms when generating encrypted pay identifiers in the real world. See FIG. 2A, data field (g).

A rule number is an alpha-numeric set of characters referencing a certain algorithm or a pre-designated set of algorithms dictating the manipulation operations and techniques used in transcribing one or more data strings into one entirely different data string. Among the operational and techniques used are “character displacement and substitution (comingling), “hashing”, and “encryption” of data strings, as well as combinations of said character manipulation techniques. Said character manipulation techniques that are used must be reversible and the manipulated resulting data fields must be reversible to its useable source strings. In these specifications we have referred to this operation as “decrypting” or “un-hashing”. In our applications a pair of matching encryption and decryption algorithms as well as a pair of hashing/un-hashing routines are referenced and called into execution using the same rule number. Depending on the requirements of an application, in charge or funds transfer applications different rule numbers are assigned to different merchants or receivers of funds, so that if an encrypted pay identifier (i.e. charge/transfer account number) is stolen or copied, one merchant may not use another merchant's encrypted pay identifier that had been intended for a different receiver of funds.

Since said rule numbers are associated with a merchant/receiver of funds and are receiver-specific. This is why a charge card payer or an entity transferring funds should ask the receiver for its pre-assigned rule number and enter it into a processor before generating an encrypted pay identifier.

E. Duties, Functions, and Roles of a Trustee

The trustee is a one of the four entities with functions and roles that make the methods of this invention work. A trustee is a private enterprise, an organization, or a payment processor agency that performs the following itemized list of duties, roles and functions:

• • 1. Said trustee solicits and encourages those shopping and charging electronically and those who need to transfer funds safely using electronic means to apply and register one of their existing bank accounts as “payer accounts” with said trustee. Said trustee also registers bank accounts of those merchants and receiver of funds in a similar process. Paragraphs [C1] through [C7] under Detailed Description of the Invention list a step by step description of said trustee's role and functions in registering payers and receivers.
  • 2. As outlined in paragraphs [C1] through [C7], said trustee creates secure computer accounts with logon user-names and changeable access passwords, and records said payer's entire supplied information in a “payer database”. Said trustee also stores said receiver's entire supplied information in a “receiver database”.
  • 3. For each pay objects of a payer account, said trustee allocates unique proxy pay identifier string, identifier password strings, and the needed constant character strings. The trustee records all of said data fields in data record called payer data-set. Please refer to paragraph [C8] for details.
  • 4. Said trustee designs and codes application programs (Apps) used for processing of the data fields of said payer data-set and other input in generating encrypted pay identifiers and pay identifier records as has been specified in this document.
  • 5. Said trustee makes available for download, a copy of said payer data-set as well as a processing application program, or otherwise delivers a recorded copy of said App and data-set to said payer as needed.
  • 6. For each receiver account, trustee designs and codes all needed encryption, hashing, decryption, un-hashing, and all character manipulation algorithms, and assigns a proper rule number to each pair of matching encryption decryption, hashing un-hashing, and character manipulation algorithms.
  • 7. Said trustee records said user-specific rule number and associated algorithms indexed to said receiver identity identifier and account number in said receiver database.
  • 8. Said trustee makes and supports its own custom-made hardware devices containing a rule number, associated full or partial encryption/hashing algorithms on chips built in pay terminals, cash registers, parking meters, gas station pumps, vending machines and in all point of sale pay stations and machines. Such devices include but are not limited to optical, intelligent and dumb cards, data cartridges, RFID devices, NFC devices, variety of hand-held computer-telephone combined devices, such as hardware and software for Android devices and “Apps” for i-Phone®, and i-Pad® devices. In addition, trustee specifies the specs for its supported hardware, and licenses third party designers and manufacturers to design, make, distribute, and install such proprietary devices for said trustee's customers.
  • 9. Said trustee designs custom made applications (Apps) to work on said mentioned devices, and may engage in licensing agreement with third party software designers and program shops to develop, improve, and modify said software and Apps.
  • 10. Said trustee is also involved in maintenance, the design, coding, installation, configuration, user training, distribution, and selling of said hardware and software.
  • 11. Said trustee may choose to work with and delegate the design and manufacturing of its supported equipment, hardware, software and program coding to some external contractors based upon their security guarantees, background knowledge and capability, reliability, and reputation, at its sole decision.
  • 12. A partial role of the trustee may be assigned to one or more license holder charge processors, banks, and other entities under its contract, and at its sole decision and choosing.
  • 13. Said trustee also oversees its hardware and software associates and contractors in the functional design, coding, testing, and certification of said hardware and software.
  • 14. Said trustee is the sole authority in assigning rule numbers and associated algorithms to its client merchants and receivers of funds.
  • 15. Said trustee is the sole authority in functional testing and certification of any and all hardware and software needed in generating and processing of said encrypted pay identifiers and said pay identifier records as described in this document.
  • 16. Said trustee stores, manages, and keeps confidential all of its payer and receiver cliental account and login information in its “payer database” and “receiver database”.
  • 17. Said trustee provides a secure computer environment as far as possible, and shall comply with all Federal and State laws in keeping financial and personal data of its clients secure.
  • 18. Barring man-made and natural disasters, power and network outages, and unprecedented virus, malware, and denial of service attacks, said trustee is responsible for keeping its computer network available and secure and available.
  • 19. Said trustee shall set its own “service fees” and fee schedule necessary for all of the itemized services it provides to all of its account holders. Such fees may be application fees, membership fees, annual fees, and per-transaction fees, both for “payers”, and “receivers”.

Claims

1. A four way method for electronically transferring funds from a payer having at least one pay object and a pay object account with a bank, through a trustee, to a receiver with a receiver account; said method using data strings comprising:

a proxy pay identifier, an identifier password, a constant data string, a transfer amount, and a rule number; wherein said proxy pay identifier, said identifier password, and said constant data string are associated with at least one said pay object and pay object account; wherein said rule number is associated with at least one of an encryption or hashing algorithm and its corresponding decryption or un-hashing algorithm; said trustee performing the steps comprising: verifying a payer name and an identity identifier of said payer; verifying said pay object account number of said pay object; verifying said payer name on said pay object account number and associated account information of said payer; verifying the withdrawal rights of said payer in withdrawing funds from said pay object account number through said bank or a payment processor; securely storing in a payer database of said trustee said pay object account number associated with said payer name and the account information of said payer and pay object account; verifying a receiver name and an identity identifier of said receiver; verifying a receiver account number of said receiver account; verifying said receiver name on said receiver account number and associated account information of said receiver; verifying the withdrawal rights of said receiver in withdrawing funds from said receiver account number through said bank or a payment processor; securely storing in a receiver database of said trustee said receiver account number associated with said receiver name and account information of said receiver and said receiver account; programming a plurality of different encryption and hashing algorithms and referencing each one of said encryption and hashing algorithm with a rule number allocated to at least one said receiver; associating one of said rule number to said receiver account number and storing in said receiver database of said trustee; delivering said rule number to said receiver; delivering to said payer at least one application program activated by an access password, along with a payer data-set comprising said payer name, said proxy pay identifier, said identifier password, and said constant data string;

said payer performing the steps comprising: executing one said application program supplied by said trustee and entering said access password; delivering said payer data-set comprising said payer name, said proxy pay identifier, said identifier password, and said constant data string to said application program; entering a transfer amount in said application program; asking said receiver for said rule number and entering said rule number in said application program; having said application program applying the associated encryption or hashing algorithms of said rule number to at least one of the data fields of said payer data-set and said transfer amount, generating an encrypted pay identifier; upon the successful execution of said application program delivering a temporary data record comprising said encrypted pay identifier, said payer name, and said rule number to said receiver;

said receiver delivering said temporary data record comprising said encrypted pay identifier, said payer name, and said rule number to said trustee;

said trustee performing the steps comprising: receiving said temporary data record from said receiver and retrieving said encrypted pay identifier, said payer name, and the rule number; decrypting said encrypted pay identifier and retrieving said payer name, said proxy pay identifier, said identifier password, said constant data string, and said transfer amount; matching the received said proxy pay identifier with said proxy pay identifier on said payer database and retrieving the associated said pay object account number, said payer name, and said pay object account information from said payer database; validating the pending transaction by comparing said payer name received from said receiver and the payer name retrieved from said payer database; retrieving the associated said receiver account number, and said receiver name from said receiver database by matching the received said rule number; notifying said payer of a pending transaction of said payment amount to said receiver; notifying said receiver of a pending transaction of said payment amount from said payer; transmitting said payer name, the said pay object account number, and said transfer amount to said bank or said payment processor; transmitting said receiver name, the said receiver account number, and said transfer amount to said bank or said payment processor;

said bank performing the steps comprising: applying said transfer amount plus any payer applicable fees as a debit from said pay object account number; applying said transfer amount less any fees applicable to said receiver as a credit to said receiver account number.

2. The method of claim 1, wherein the comprising characters of said rule number, said payer name, a transfer amount, and at least one of the data fields of said payer data-set are dispersed within one another, comingled together, hashed, and/or encrypted with one another into one binary string called an encrypted pay identifier, using a programmed algorithm called by said rule number.

3. The method of claim 1, wherein said encrypted pay identifier along with said rule number and said payer name are transferred to either of said trustee, to said payment processor, and/or to the bank for further processing.

4. The method of claim 1, wherein either one or both of said identifier password, and said constant data string are of at least zero in length.

5. The method of claim 1, further comprising the trustee reversing each one of said encrypted pay identifier to said encrypted pay identifier's original data fields through a decryption algorithm associated with the same rule number used in the encryption and/or hashing process.

6. The method of claim 1, wherein said application program is executed on at least one of a processor unit, a plug-in module, an intelligent card, a telephonic computer device, a portable computerized device, a built-in module, a receiver's computerized pay terminal, a vending or dispensing machine of sorts, or a computerized device; where said application program is executed remotely through at least one of a link to said trustee computer system, comprising a wired link, a wireless link, a data bandwidth, a telephone link, and/or the internet.

7. The method of claim 1, wherein said encrypted pay identifier is stored in the form of a two dimensional, or multidimensional bar code, an optical or laser readable format, in an RFID (Radio Frequency Identification) card, a plug-in module, a magnetic card, an intelligent card, a telephonic computer device, a portable computerized device, a built-in module, a receiver's computerized pay terminal, a vending or dispensing machine of sorts, or a computerized device; where said encrypted pay identifier is delivered through a wired port, NFC (Near Field Communication) device, wireless link, a data bandwidth, a telephone link, and/or the internet linked to said trustee computer system.

8. The method of claim 1, wherein said application program is executed using computerized communication networks and one or more of devices comprising a said payer computer device, a said receiver computer terminal, a said trustee computer system, and/or a pay terminal of sorts.

9. The method of claim 1, wherein said bank or said payment processor further performs functions of the trustee.

10. The method of claim 1, further comprising the trustee engaging in a contractual relationship with at least one of said bank or said payment processor.

11. A four way method for electronically transferring funds from a payer having at least one pay object and a pay object account with a bank, through a trustee, to a receiver with a receiver account; said method using data strings comprising:

a proxy pay identifier, an identifier password, a constant data string, a transfer amount, and a rule number; wherein said proxy pay identifier, said identifier password, and said constant data string are associated with at least one said pay object and pay object account; wherein said rule number is associated with at least one of an encryption or hashing algorithm and its corresponding decryption or un-hashing algorithm; said trustee performing the steps comprising: verifying a payer name and an identity identifier of said payer; verifying said pay object account number of said pay object; verifying said payer name on said pay object account number and associated account information of said payer; verifying the withdrawal rights of said payer in withdrawing funds from said pay object account number through said bank or a payment processor; securely storing in a payer database of said trustee said pay object account number associated with said payer name and the account information of said payer and pay object account; verifying a receiver name and an identity identifier of said receiver; verifying a receiver account number of said receiver account; verifying said receiver name on said receiver account number and associated account information of said receiver; verifying the withdrawal rights of said receiver in withdrawing funds from said receiver account number through said bank or a payment processor; securely storing in a receiver database of said trustee said receiver account number associated with said receiver name and account information of said receiver and said receiver account; programming a plurality of different encryption and hashing algorithms and referencing each one of said encryption and hashing algorithm with a rule number allocated to at least one said receiver; associating one of said rule number to said receiver account number and storing in said receiver database of said trustee; delivering said rule number to said receiver; delivering to said payer at least one application program activated by an access password, along with a payer data-set comprising said payer name, said proxy pay identifier, said identifier password;

said payer performing the steps comprising: executing one said application program supplied by said trustee and entering said access password; delivering said payer data-set comprising said payer name, said proxy pay identifier, said identifier password, and said constant data string to said application program; entering a transfer amount in said application program; asking said receiver for said rule number and entering said rule number in said application program; having said application program applying the associated encryption, comingling, or hashing algorithms of said rule number to at least one of the data fields of said payer data-set and said transfer amount, generating a pay identifier record; upon the successful execution of said application program transmitting said pay identifier record and said rule number to said trustee via a secure network;

said trustee performing the steps comprising: receiving said pay identifier record and said rule number from the payer; disassembling said pay identifier record and retrieving said proxy pay identifier, said identifier password, said payer name, and said transfer amount from said pay identifier record; matching the received said proxy pay identifier with said proxy pay identifier on said payer database and retrieving the associated said pay object account number, said payer name, and said pay object account information from said payer database; validating the pending transaction by comparing said payer name received from said trustee and the payer name retrieved from said payer database; retrieving the associated said receiver account number, and said receiver name and the from said receiver database by matching the received said rule number; notifying said payer of a pending transaction of said payment amount to said receiver; notifying said receiver of a pending transaction of said payment amount from said payer; transmitting said payer name, the said pay object account number, and said transfer amount to said bank or said payment processor; transmitting said receiver name, the said receiver account number, and said transfer amount to said bank or said payment processor;

said bank performing the steps comprising: applying said transfer amount plus any payer applicable fees as a debit from said pay object account number; applying said transfer amount less any fees applicable to said receiver as a credit to said receiver account number.

12. The method of claim 11, wherein said pay identifier record is a binary string comprising the characters of said payer name, said rule number, a transfer amount, and at least one of the data fields of said payer data-set, where in delivering said pay identifier record to said trustee at least one of the data fields of said pay identifier record is hashed, encrypted, comingled, or dispersed throughout said binary string.

13. The method of claim 11, wherein said pay identifier record comprising characters of said rule number, a transfer amount, and a hash of at least one of the data fields of said payer data-set and said payer name.

14. The method of claim 11, wherein at least one of the data fields of said pay identifier record and said rule number are transferred to said trustee, to the bank, or to said payment processor, unencrypted and unaltered.

15. The method of claim 11, wherein said application program is executed on at least one of a processor unit, a plug-in module, an intelligent card, a telephonic computer device, a portable computerized device, a built-in module, a receiver's computerized pay terminal, a vending or dispensing machine of sorts, or a computerized device; where said application program is executed remotely through at least one of a link to said trustee computer system, comprising a wired link, a wireless link, a data bandwidth, a telephone link, and/or the internet.

16. The method of claim 11, wherein said pay identifier record is stored in the form of a two dimensional, or multidimensional bar code, an optical or laser readable format, in an RFID (Radio Frequency Identification) card, a plug-in module, a magnetic card, an intelligent card, a telephonic computer device, a portable computerized device, a built-in module, a receiver's computerized pay terminal, a vending or dispensing machine of sorts, or a computerized device; where said pay identifier record is delivered through a wired port, NFC device, wireless link, a data bandwidth, a telephone link, and/or the internet linked to said trustee computer system.

17. The method of claim 11, wherein said application program is executed using computerized communication networks and one or more of devices comprising a said payer computer device, a said receiver computer terminal, and/or a said trustee computer system, communicating in any modes of local, NFC, remote, or a mix thereof.

18. The method of claim 11, wherein said bank or said payment processor further performs functions of the trustee.

19. The method of claim 11, further comprising the trustee engaging in a contractual relationship with at least one of said bank or said payment processor.

20. A method for transferring funds or charging an amount electronically, wherein a bank, or a payment processor receives from a receiver of funds one of an encrypted pay identifier comprising a hash of at least one of a payer name, a pay object account number, a receiver name, a receiver account number, a payment amount, and one of a rule number, through a trustee.