U.S. patent application number 13/490363 was filed with the patent office on 2012-09-27 for secure electronic payment methods.
Invention is credited to Mehran Randall Rasti.
Application Number | 20120246075 13/490363 |
Document ID | / |
Family ID | 40754838 |
Filed Date | 2012-09-27 |
United States Patent
Application |
20120246075 |
Kind Code |
A1 |
Rasti; Mehran Randall |
September 27, 2012 |
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.
Inventors: |
Rasti; Mehran Randall;
(Fredericksburg, VA) |
Family ID: |
40754838 |
Appl. No.: |
13/490363 |
Filed: |
June 6, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11957266 |
Dec 14, 2007 |
|
|
|
13490363 |
|
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
H04L 63/0884 20130101;
H04L 63/083 20130101; H04L 63/0421 20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 20/40 20120101
G06Q020/40 |
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.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] 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.
[0002] This application also cites the following related
applications filed by the same person.
TABLE-US-00001 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
[0003] Not Applicable
REFERENCES TO SEQUENCE LISTING, TABLES, OR COMPUTER PROGRAMS
TABLES
[0004] Not Applicable
BACKGROUND OF THE INVENTION
[0005] 1. Field of Invention
[0006] 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.
[0007] 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.
[0008] 2. Status of Prior Art
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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").
[0015] 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
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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".
[0023] 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.
[0024] 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).
[0025] 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.
[0026] 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.COPYRGT. and iPhone.COPYRGT. 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.
[0027] 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.
[0028] 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.
[0029] 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
[0030] 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.
[0031] 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.
[0032] 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".
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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
[0038] A "digital string" is at least one of an alpha-numeric
and/or a binary character.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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
[0045] 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.
[0046] 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
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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: [0056] 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. [0057] 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. [0058] c. At least one identifier password strings as
depicted in data field (d) of FIG. 1B, and data field (d) in FIG.
2A. [0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] In Event Label 7, of FIG. 3C said receiver sends said
temporary data record to said trustee computer system.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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:
[0086] 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.
[0087] 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].
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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".
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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
[0102] 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.
[0103] 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.
[0104] 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.
[0105] 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).
[0106] 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.
[0107] 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
[0108] 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: [0109] 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. [0110] 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". [0111] 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. [0112] 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. [0113] 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. [0114] 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. [0115] 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. [0116] 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.RTM., and i-Pad.RTM. 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.
[0117] 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. [0118] 10.
Said trustee is also involved in maintenance, the design, coding,
installation, configuration, user training, distribution, and
selling of said hardware and software. [0119] 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. [0120] 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. [0121] 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.
[0122] 14. Said trustee is the sole authority in assigning rule
numbers and associated algorithms to its client merchants and
receivers of funds. [0123] 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. [0124] 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".
[0125] 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.
[0126] 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. [0127] 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".
* * * * *