US20120246075A1 - Secure electronic payment methods - Google Patents

Secure electronic payment methods Download PDF

Info

Publication number
US20120246075A1
US20120246075A1 US13/490,363 US201213490363A US2012246075A1 US 20120246075 A1 US20120246075 A1 US 20120246075A1 US 201213490363 A US201213490363 A US 201213490363A US 2012246075 A1 US2012246075 A1 US 2012246075A1
Authority
US
United States
Prior art keywords
pay
receiver
payer
identifier
trustee
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/490,363
Inventor
Mehran Randall Rasti
Original Assignee
Mehran Randall Rasti
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US11/957,266 priority Critical patent/US8281145B2/en
Application filed by Mehran Randall Rasti filed Critical Mehran Randall Rasti
Priority to US13/490,363 priority patent/US20120246075A1/en
Publication of US20120246075A1 publication Critical patent/US20120246075A1/en
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0884Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/083Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using passwords

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 (20)

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.
US13/490,363 2007-12-14 2012-06-06 Secure electronic payment methods Abandoned US20120246075A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/957,266 US8281145B2 (en) 2007-12-14 2007-12-14 Doing business without SSN, EIN, and charge card numbers
US13/490,363 US20120246075A1 (en) 2007-12-14 2012-06-06 Secure electronic payment methods

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/490,363 US20120246075A1 (en) 2007-12-14 2012-06-06 Secure electronic payment methods

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/957,266 Continuation US8281145B2 (en) 2007-12-14 2007-12-14 Doing business without SSN, EIN, and charge card numbers

Publications (1)

Publication Number Publication Date
US20120246075A1 true US20120246075A1 (en) 2012-09-27

Family

ID=40754838

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/957,266 Expired - Fee Related US8281145B2 (en) 2007-12-14 2007-12-14 Doing business without SSN, EIN, and charge card numbers
US13/490,363 Abandoned US20120246075A1 (en) 2007-12-14 2012-06-06 Secure electronic payment methods

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/957,266 Expired - Fee Related US8281145B2 (en) 2007-12-14 2007-12-14 Doing business without SSN, EIN, and charge card numbers

Country Status (1)

Country Link
US (2) US8281145B2 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130268756A1 (en) * 2011-09-07 2013-10-10 Elwha Llc Computational systems and methods for anonymized storage of double-encrypted data
US20130287204A1 (en) * 2011-09-07 2013-10-31 Elwha Llc Computational systems and methods for double-encrypting data for subsequent anonymous storage
US20130290700A1 (en) * 2011-09-07 2013-10-31 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US20140025571A1 (en) * 2012-07-23 2014-01-23 Its, Inc. System and method for dual message consumer authentication value-based eft transactions
US9042546B2 (en) 2012-10-16 2015-05-26 Elwha Llc Level-two encryption associated with individual privacy and public safety protection via double encrypted lock box
US9141977B2 (en) 2011-09-07 2015-09-22 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US9159055B2 (en) 2011-09-07 2015-10-13 Elwha Llc Computational systems and methods for identifying a communications partner
US9167099B2 (en) 2011-09-07 2015-10-20 Elwha Llc Computational systems and methods for identifying a communications partner
US9183520B2 (en) 2011-09-07 2015-11-10 Elwha Llc Computational systems and methods for linking users of devices
US9521370B2 (en) 2012-07-12 2016-12-13 Elwha, Llc Level-two decryption associated with individual privacy and public safety protection via double encrypted lock box
US9596436B2 (en) 2012-07-12 2017-03-14 Elwha Llc Level-one encryption associated with individual privacy and public safety protection via double encrypted lock box
US9690853B2 (en) 2011-09-07 2017-06-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9781389B2 (en) 2012-07-12 2017-10-03 Elwha Llc Pre-event repository associated with individual privacy and public safety protection via double encrypted lock box
US9825760B2 (en) 2012-07-12 2017-11-21 Elwha, Llc Level-two decryption associated with individual privacy and public safety protection via double encrypted lock box
US9928485B2 (en) 2011-09-07 2018-03-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9940608B2 (en) * 2013-05-16 2018-04-10 Mts Holdings, Inc. Real time EFT network-based person-to-person transactions
US10185814B2 (en) 2011-09-07 2019-01-22 Elwha Llc Computational systems and methods for verifying personal information during transactions
US10198729B2 (en) 2011-09-07 2019-02-05 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10263936B2 (en) 2011-09-07 2019-04-16 Elwha Llc Computational systems and methods for identifying a communications partner

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9710852B1 (en) 2002-05-30 2017-07-18 Consumerinfo.Com, Inc. Credit report timeline user interface
US9569797B1 (en) 2002-05-30 2017-02-14 Consumerinfo.Com, Inc. Systems and methods of presenting simulated credit score information
US9400589B1 (en) 2002-05-30 2016-07-26 Consumerinfo.Com, Inc. Circular rotational interface for display of consumer credit information
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US9690820B1 (en) 2007-09-27 2017-06-27 Experian Information Solutions, Inc. Database system for triggering event notifications based on updates to database records
US9990674B1 (en) 2007-12-14 2018-06-05 Consumerinfo.Com, Inc. Card registry systems and methods
US8127986B1 (en) 2007-12-14 2012-03-06 Consumerinfo.Com, Inc. Card registry systems and methods
US9112886B2 (en) * 2007-12-27 2015-08-18 Verizon Patent And Licensing Inc. Method and system for providing centralized data field encryption, and distributed storage and retrieval
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US8055767B1 (en) * 2008-07-15 2011-11-08 Zscaler, Inc. Proxy communication string data
US9256904B1 (en) * 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9124431B2 (en) 2009-05-14 2015-09-01 Microsoft Technology Licensing, Llc Evidence-based dynamic scoring to limit guesses in knowledge-based authentication
US8856879B2 (en) * 2009-05-14 2014-10-07 Microsoft Corporation Social authentication for account recovery
US8640216B2 (en) * 2009-12-23 2014-01-28 Citrix Systems, Inc. Systems and methods for cross site forgery protection
FR2960671A1 (en) * 2010-06-01 2011-12-02 Inst Telecom Telecom Paris Tech Process for securisation digital data and identities especially in processes using information and communications technology
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US9058497B2 (en) * 2010-12-23 2015-06-16 Microsoft Technology Licensing, Llc Cryptographic key management
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US9607336B1 (en) 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry alerts
US9361652B2 (en) * 2011-06-29 2016-06-07 Philip Ti-Fei Su Accessing third-party communication service via a social networking system
US9483606B1 (en) 2011-07-08 2016-11-01 Consumerinfo.Com, Inc. Lifescore
US9251723B2 (en) * 2011-09-14 2016-02-02 Jonas Moses Systems and methods of multidimensional encrypted data transfer
US10032036B2 (en) * 2011-09-14 2018-07-24 Shahab Khan Systems and methods of multidimensional encrypted data transfer
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US9240980B2 (en) * 2011-09-27 2016-01-19 Koninklijke Philips N.V. Management of group secrets by group members
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US20140058875A1 (en) * 2012-08-21 2014-02-27 Biddocs Online, Inc. Methods for facilitating an electronic signature and devices thereof
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9916621B1 (en) 2012-11-30 2018-03-13 Consumerinfo.Com, Inc. Presentation of credit score factors
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US9043867B2 (en) * 2013-01-11 2015-05-26 The Court Of Edinburgh Napier University Information sharing
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US20140281516A1 (en) 2013-03-12 2014-09-18 Commvault Systems, Inc. Automatic file decryption
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US9692753B2 (en) 2014-01-17 2017-06-27 Safecard, Llc Password encode card system and method
US10019567B1 (en) * 2014-03-24 2018-07-10 Amazon Technologies, Inc. Encoding of security codes
USD760256S1 (en) 2014-03-25 2016-06-28 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759689S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759690S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
US9892457B1 (en) 2014-04-16 2018-02-13 Consumerinfo.Com, Inc. Providing credit data in search results
US9405928B2 (en) * 2014-09-17 2016-08-02 Commvault Systems, Inc. Deriving encryption rules based on file content
US9779256B2 (en) * 2016-03-07 2017-10-03 Roger G Marshall Iamnotanumber© card system: an image-based technique for the creation and deployment of numberless card systems

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030042301A1 (en) * 2001-08-31 2003-03-06 Sanguthevar Rajasekaran Enhancements to multi-party authentication and other protocols
US7454376B1 (en) * 2000-07-21 2008-11-18 Argenbright Stephen G Online investment trust creation and management

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4214230A (en) * 1978-01-19 1980-07-22 Rolf Blom Personal identification system
US5960085A (en) * 1997-04-14 1999-09-28 De La Huerga; Carlos Security badge for automated access control and secure data gathering
US6463533B1 (en) * 1999-04-15 2002-10-08 Webtv Networks, Inc. System for generating site-specific user aliases in a computer network
US20040083184A1 (en) * 1999-04-19 2004-04-29 First Data Corporation Anonymous card transactions
US20040260653A1 (en) * 1999-04-19 2004-12-23 First Data Corporation Anonymous transactions
US7032240B1 (en) * 1999-12-07 2006-04-18 Pace Anti-Piracy, Inc. Portable authorization device for authorizing use of protected information and associated method
AU2105001A (en) * 1999-12-15 2001-06-25 E-Scoring, Inc. Systems and methods for providing consumers anonymous pre-approved offers from aconsumer-selected group of merchants
AU2762001A (en) * 2000-01-05 2001-07-16 Iprivacy Llc Method and system for private shipping to anonymous users of a computer network
IL135150D0 (en) * 2000-03-17 2001-05-20 Avner Geller A method and a system for secured identification of user's identity
US7412422B2 (en) * 2000-03-23 2008-08-12 Dekel Shiloh Method and system for securing user identities and creating virtual users to enhance privacy on a communication network
US20030158960A1 (en) * 2000-05-22 2003-08-21 Engberg Stephan J. System and method for establishing a privacy communication path
US7565326B2 (en) * 2000-05-25 2009-07-21 Randle William M Dialect independent multi-dimensional integrator using a normalized language platform and secure controlled access
WO2002095554A2 (en) * 2001-05-18 2002-11-28 Imprivata Inc. System and method for authentication using biometrics
AU2002312381A1 (en) * 2001-06-07 2002-12-16 First Usa Bank, N.A. System and method for rapid updating of credit information
US7805378B2 (en) * 2001-07-10 2010-09-28 American Express Travel Related Servicex Company, Inc. System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions
US7195154B2 (en) * 2001-09-21 2007-03-27 Privasys, Inc. Method for generating customer secure card numbers
US20030120608A1 (en) * 2001-12-21 2003-06-26 Jorge Pereyra Secure method for purchasing and payment over a communication network and method for delivering goods anonymously
US20030195857A1 (en) * 2002-04-10 2003-10-16 Alessandro Acquisti Communication technique to verify and send information anonymously among many parties
US7200756B2 (en) * 2002-06-25 2007-04-03 Microsoft Corporation Base cryptographic service provider (CSP) methods and apparatuses
US7590861B2 (en) * 2002-08-06 2009-09-15 Privaris, Inc. Methods for secure enrollment and backup of personal identity credentials into electronic devices
US7454785B2 (en) * 2002-12-19 2008-11-18 Avocent Huntsville Corporation Proxy method and system for secure wireless administration of managed entities
US20040172293A1 (en) * 2003-01-21 2004-09-02 Paul Bruschi Method for identifying and communicating with potential clinical trial participants
AR042707A1 (en) * 2004-01-05 2005-06-29 Salva Calcagno Eduardo Luis Procedure and multi card - key to avoiding fraud online
US8037512B2 (en) * 2004-04-02 2011-10-11 Paradox Technical Solutions Llc Protection of privacy data
US7613919B2 (en) * 2004-10-12 2009-11-03 Bagley Brian B Single-use password authentication
WO2007130855A2 (en) * 2006-05-01 2007-11-15 Michael Pomerantsev Secure sharing of personal information
US8738921B2 (en) * 2006-05-16 2014-05-27 Transactionsecure Llc System and method for authenticating a person's identity using a trusted entity

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7454376B1 (en) * 2000-07-21 2008-11-18 Argenbright Stephen G Online investment trust creation and management
US20030042301A1 (en) * 2001-08-31 2003-03-06 Sanguthevar Rajasekaran Enhancements to multi-party authentication and other protocols

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9928485B2 (en) 2011-09-07 2018-03-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US20130287204A1 (en) * 2011-09-07 2013-10-31 Elwha Llc Computational systems and methods for double-encrypting data for subsequent anonymous storage
US20130290700A1 (en) * 2011-09-07 2013-10-31 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US10185814B2 (en) 2011-09-07 2019-01-22 Elwha Llc Computational systems and methods for verifying personal information during transactions
US10263936B2 (en) 2011-09-07 2019-04-16 Elwha Llc Computational systems and methods for identifying a communications partner
US9141977B2 (en) 2011-09-07 2015-09-22 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US9159055B2 (en) 2011-09-07 2015-10-13 Elwha Llc Computational systems and methods for identifying a communications partner
US9167099B2 (en) 2011-09-07 2015-10-20 Elwha Llc Computational systems and methods for identifying a communications partner
US9183520B2 (en) 2011-09-07 2015-11-10 Elwha Llc Computational systems and methods for linking users of devices
US9195848B2 (en) * 2011-09-07 2015-11-24 Elwha, Llc Computational systems and methods for anonymized storage of double-encrypted data
US9432190B2 (en) * 2011-09-07 2016-08-30 Elwha Llc Computational systems and methods for double-encrypting data for subsequent anonymous storage
US9473647B2 (en) 2011-09-07 2016-10-18 Elwha Llc Computational systems and methods for identifying a communications partner
US9491146B2 (en) * 2011-09-07 2016-11-08 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US10079811B2 (en) * 2011-09-07 2018-09-18 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US10074113B2 (en) 2011-09-07 2018-09-11 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US20130268756A1 (en) * 2011-09-07 2013-10-10 Elwha Llc Computational systems and methods for anonymized storage of double-encrypted data
US9690853B2 (en) 2011-09-07 2017-06-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9747561B2 (en) 2011-09-07 2017-08-29 Elwha Llc Computational systems and methods for linking users of devices
US10198729B2 (en) 2011-09-07 2019-02-05 Elwha Llc Computational systems and methods for regulating information flow during interactions
US20170302632A1 (en) * 2011-09-07 2017-10-19 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US9667917B2 (en) 2012-07-12 2017-05-30 Elwha, Llc Level-one encryption associated with individual privacy and public safety protection via double encrypted lock box
US9825760B2 (en) 2012-07-12 2017-11-21 Elwha, Llc Level-two decryption associated with individual privacy and public safety protection via double encrypted lock box
US9781389B2 (en) 2012-07-12 2017-10-03 Elwha Llc Pre-event repository associated with individual privacy and public safety protection via double encrypted lock box
US9596436B2 (en) 2012-07-12 2017-03-14 Elwha Llc Level-one encryption associated with individual privacy and public safety protection via double encrypted lock box
US9521370B2 (en) 2012-07-12 2016-12-13 Elwha, Llc Level-two decryption associated with individual privacy and public safety protection via double encrypted lock box
US10277867B2 (en) 2012-07-12 2019-04-30 Elwha Llc Pre-event repository associated with individual privacy and public safety protection via double encrypted lock box
US10348494B2 (en) 2012-07-12 2019-07-09 Elwha Llc Level-two decryption associated with individual privacy and public safety protection via double encrypted lock box
US20140025571A1 (en) * 2012-07-23 2014-01-23 Its, Inc. System and method for dual message consumer authentication value-based eft transactions
US9042546B2 (en) 2012-10-16 2015-05-26 Elwha Llc Level-two encryption associated with individual privacy and public safety protection via double encrypted lock box
US9940608B2 (en) * 2013-05-16 2018-04-10 Mts Holdings, Inc. Real time EFT network-based person-to-person transactions

Also Published As

Publication number Publication date
US8281145B2 (en) 2012-10-02
US20090158030A1 (en) 2009-06-18

Similar Documents

Publication Publication Date Title
CA2418050C (en) Linking public key of device to information during manufacture
AU2007261082B2 (en) Portable consumer device verification system
AU2011316932B2 (en) Integration of verification tokens with portable computing devices
US6938019B1 (en) Method and apparatus for making secure electronic payments
US9177169B2 (en) Secure digital storage
JP4477625B2 (en) Search and hidden data backup for secure device
US6000832A (en) Electronic online commerce card with customer generated transaction proxy number for online transactions
AU2013216868B2 (en) Tokenization in mobile and payment environments
US9881297B2 (en) Methods and systems for secure mobile device initiated payments using generated image data
JP5802137B2 (en) Secure centralized authentication system having a private data storage device, and method
US7548890B2 (en) Systems and methods for identification and authentication of a user
US9141953B2 (en) Personal token read system and method
US10318932B2 (en) Payment card processing system with structure preserving encryption
KR101150241B1 (en) Method and system for authorizing a transaction using a dynamic authorization code
US9818092B2 (en) System and method for executing financial transactions
ES2599985T3 (en) Validation at any time for verification tokens
CN104603809B (en) Promote the system and method for transaction using virtual card on the mobile apparatus
US5917913A (en) Portable electronic authorization devices and methods therefor
US8046261B2 (en) EMV transaction in mobile terminals
US7694130B1 (en) System and method to authenticate a user utilizing a time-varying auxiliary code
US20090307140A1 (en) Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US8656180B2 (en) Token activation
US20120185398A1 (en) Mobile payment system with two-point authentication
US20180039973A1 (en) Radio frequency transactions using a plurality of accounts
JP6386567B2 (en) Network token system

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION