METHOD AND APPARATUS FOR CREDIT TRANSACTION EMPLOYING UNBREAKABLE ENCRYPTION

Abstract

A method and apparatus for a streamlined electronic credit transaction that provides more security in a streamlined transaction process than any current deferred net settlement system. The removal of the physical credit card restores the proper risk balance to all participants and performs processing in real time, faster than any current system. The method relies on secure authentication and encryption security communications, based on the provably secure unbreakable mathematics of underdetermined systems of equations, which are maintained everywhere throughout the transaction process.

Claims

1. A method for providing and using credit comprising: a) registering an issuer using a central server that issues electronically to the issuer a issuer open identification value, a first issuer master key and a second issuer master key; b) registering a bank using the central server that issues electronically to the bank a bank open identification value, a first bank master key and a second bank master key; c) registering a consumer by an issuer webserver operating an issuer website for the issuer, receiving from the consumer a consumer personal identifier value and storing the consumer personal identifier value in association with a consumer record for the consumer in a cash issuer database coupled to the issuer webserver; d) providing electronically a consumer cash application to a consumer computing device of the consumer after registration of the consumer; e) storing, upon execution of the consumer cash application on the consumer computing device, the issuer website as a choice in the consumer cash application; f) creating by the issuer webserver a consumer authentication token, a consumer open identification value, a first consumer master key and a second consumer master key; g) transmitting electronically the consumer authentication token, the first consumer master key and the second consumer master key to the consumer cash application and to the central server; h) receiving a personal identification number (PIN) by the consumer cash application, and encrypting by the consumer cash application the consumer authentication token, the first consumer master key and the second consumer master key using the PIN and storing encrypted versions of the consumer authentication token, the first consumer master key and the second consumer master key in a consumer storage on the consumer computing device; i) publicly listing the consumer on a system website using the consumer open identification value and the consumer personal identifier; j) registering a merchant by a bank webserver operating a bank website, receiving from the merchant a merchant personal identifier value and storing the merchant personal identifier value in association with a merchant record for the merchant in a bank database coupled to the bank webserver; k) providing electronically a merchant application to a merchant computer of the merchant after registration of the merchant; l) storing, upon execution of the merchant application on a merchant computer, the bank website as a default settlement bank in the merchant application; m) creating by the bank webserver a merchant authentication token, a merchant open identification value, a first merchant master key and a second merchant master key; n) transmitting electronically the merchant authentication token, the first merchant master key and the second merchant master key to the merchant application and the central server; o) receiving a personal identification number (PIN) by the merchant application, and encrypting by the merchant application the merchant authentication token, the first merchant master key and the second merchant master key using the PIN and storing encrypted versions of the merchant authentication token, the first merchant master key and the second merchant master key in a merchant storage on the merchant computer; and p) publicly listing the merchant on the cash system website using the merchant open identification value and the merchant personal identifier.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0068] FIG. 1 depicts and exemplary embodiment of a method for performing a registration with a central system to enable future credit transactions for consumers, merchants, banks and credit issuers.

[0069] FIG. 2 depicts and exemplary embodiment of a method for performing a credit transaction between a consumer and merchant and the interaction between them and the central system, as well as the bank and credit issuer.

[0070] FIG. 3 depicts and exemplary embodiment of a method for performing a gift giving transaction for a consumer and the interaction with the central system and credit issuer.

[0071] FIG. 4 depicts and exemplary embodiment of a method for performing a gift redemption transaction for a consumer and the interaction with the central system, the merchant, the bank and the credit issuer.

[0072] FIG. 5 depicts a diagram of the transaction processing for approval and settlement of the two major credit card associations, Visa and MasterCard.

[0073] FIGS. 6-9 depict exemplary embodiments of the authentication and encryption protocol used in the embodiments herein.

DETAILED DESCRIPTION

[0074] The present invention enacts and processes a financial credit transaction between parties, generally a merchant (seller) and a consumer (buyer). QwyitCash refers to all parts of the protocol, including the incorporation of the QwyitTalk stream cipher and Qwyit authentication.

[0075] The complete QwyitCash protocol includes authentication key management through the Qwyit Directory Server system.

[0076] Introduction

[0077] The present invention, termed QwyitCash, is a provably secure unbreakable mathematic method used in a streamlined, secure credit transaction process between a Consumer, a Merchant, and both party's banks. QwyitCash relies on the communication security of the Qwyit protocol's method. Qwyit is a one-pass embedded symmetric key authentication method, based on underdetermined equation sets, and includes the world's fastest, most secure stream cipher for data encryption (QwyitTalk). QwyitCash is an extension of Qwyit's provably secure cryptographic primitives resulting in a provably secure transaction process. QwyitCash is the first and only fully transparent, understandable, secure,unbreakable, fast, no cost credit transaction processing system with equal, shared risk for all participants.

[0078] Provably secure and unbreakable means: [0079] The mathematics used is unsolvable other than brute force investigation of the entire possibility range and that takes essentially forever; and [0080] The possible range of attack on each and every process step outcome is limited to a known range of results that are effectively handled by all the participants without monetary loss.

[0081] The mathematics claim has been verified by independent cryptographic experts and is currently under review by NIST for certification as a U.S. National Standard for Lightweight Cryptography; and the process security claims can easily be verified by any readerwhich is the entire point of providing a transparent, understandable system (based on the verified mathematics).

[0082] Approach

[0083] The entirety of the credit card business and technical transaction model is based on using the actual, physical card as an authentication token. All of the complexity of all of the proposed credit transaction processing methods has been based on the faulty assumption that this is necessary. What is necessary is that the person asking to use credit for a purchase is indeed the person who has been granted credit by an entity from whom the merchant will be able to collect.

[0084] The requirement doesn't impose a physical cardthat was just a method created when neither an instant communication system nor a positively secure encapsulating method of authentication credentials existed. The global, nearly universally available Internet has arrived to remove the first hurdle; and QwyitCash is now available to remove the second. When using QwyitCash over the Internet, the credit transaction is exactly the same as it's always been, only there isn't any need to carry a physical card.

[0085] There is a need, after having been granted credit under specific terms, for the borrower to carry some kind of authentication credentials that the credit issuer requires. Plainly, there is no need to translate the credentials to a physical card with another unique data set (number, expiration, etc.)there is only the need to digitize the credentials and securely store and present them whenever asking to borrow against one's credit line.

[0086] Further, there is the requirement for the merchant to be able to communicate with the issuer, and receive either approval or denial of the credit request, then act accordingly (sale or no sale), and collect on the debt (settlement). Whether or not a representative (or two) is inserted into the process of handling the package and the real money for the goods/services (merchant bank), isn't relative to the resultand their insertion should not add new requirements, only new data (identifying, accounts, etc.).

[0087] A credit transaction couldn't be any simpleryet the current convoluted storage ideas (cards, devices that store cards, etc.) and horrifically complicated/complex communications transmissions keep getting worse and worse. QwyitCash has significantly streamlined the process and met all of the requirements of the necessary transaction parties, all while delivering provable security without a credit card.

[0088] System RequirementsParticipants and Processes Definition

[0089] There are four participant classifications: [0090] 1. QwyitCash Issuer (QI) [0091] 2. QwyitCash Bank (QB) [0092] 3. Merchant [0093] 4. Consumer

[0094] There are four processes in the QwyitCash transaction system: [0095] 1. Participant Initial and Subsequent Registration [0096] 2. Normal Transaction Payment [0097] 3. Gift Transaction Creation [0098] 4. Gift Transaction Payment [0099] a. Gift Transaction StatusThe Consumer can check whether they have available Gift Transactions (a small subset of GT Payment) [0100] Merchants and QBs participant in 1, 2, and 4 [0101] Consumers and QIs participate in all [0102] System RequirementsMessage Format (All Processes) [0103] All QwyitCash messaging uses a single standard message format that includes all of the necessary data elements for all of the transmissions in the system. This unique single format demonstrates the simplicity, transparency and security of the system. The element values and/or sender/receiver are listed in the process outlines.

[0104] The QC message format: [0105] Field Name [Number of characters]field information (value type, range if applicable) [0106] Message Type [4]QC process message type identifier (alphabet), generally XX-X; e.g., QM-S [0107] OpenID [24]Message Owner's ID (hexadecimal) [0108] OpenID2 [24]Target or partner Owner's ID; e.g., a Merchant's QB's ID (hexadecimal) [0109] Authentication Token [256]Owner's AuthToken/Keys at either a QI or QB (hexadecimal) [0110] Result Flag (RF) [4]Flag values for process step outcomes (alpha-numeric, A-F (capitals), 0-9) [0111] Value Flag (VF) [24]Flag values dependent on process step and RF values (all alpha-numeric) [0112] Amount [18]Dollar amount total (includes .xx as last 3 values, where xx are the cents (decimal), and the period is included. For refunds, there will be a (minus sign) included. [0113] TransactionID [48]Current, or specific, transaction (hexadecimal) In total, comma delimited: [0114] MT [4], OpenID [24], OpenID2 [24], AuthToken [256], RF [4], VF [24], Amount [18], TransactionID [48].

[0115] These field sizes will accommodate QwyitCash operation forever; as the AuthToken field size will hold a 1024-bit symmetric key/token (256-bit recommended currently). All other sizes accommodate a galaxy-worth of participants, transactions, dollarsall without any transmission or processing performance degradation. And this standard message is substantially smaller than current credit processing transmissions.

[0116] System RequirementsMessages

[0117] Description Format: Message Name, Sender/Owner, Receiver

Registration Messages

[0118] QI-N: QwyitCash Issuer (QI) New Participant Registration.fwdarw.QC.com

[0119] QB-N: QwyitCash Bank (QB) New Participant Registration.fwdarw.QC.com

[0120] QI-O: QC.com reply with OpenID assignment.fwdarw.QI

[0121] QB-O: QC.com reply with OpenID assignment.fwdarw.QB

[0122] QI-K: QI New Participant Keys.fwdarw.QC.com

[0123] QB-K: QB New Participant Keys.fwdarw.QB.com

[0124] QI-C: QC.com Confirmation.fwdarw.QI

[0125] QB-C: QC.com Confirmation.fwdarw.QB

[0126] QM-N: Merchant New Participant Communication Check.fwdarw.QC.com

[0127] QC-N: Consumer New Participant Communication Check.fwdarw.QC.com

[0128] QM-R: QC.com reply.fwdarw.Merchant

[0129] QC-R: QC.com reply.fwdarw.Consumer

Normal Transaction Processing Messages

[0130] QM-S: Merchant Start.fwdarw.QC.com

[0131] QM-R: QC.com Reply.fwdarw.Merchant

[0132] QCC: QwyitCash Code from QC.com.fwdarw.Merchant, Merchant.fwdarw.Consumer

[0133] QC-S: Consumer Start.fwdarw.QC.com

[0134] QC-R: QC.com Reply.fwdarw.Consumer

[0135] QI-S: QC.com QwyitCash Issuer Start.fwdarw.QI

[0136] QI-R: QI reply.fwdarw.QC.com

[0137] QM-R: QC.com reply.fwdarw.Merchant

[0138] QM-A: Merchant Accept.fwdarw.QC.com

[0139] QC-A: Consumer Accept.fwdarw.QC.com

[0140] QB-T: QC.com Settlement start.fwdarw.QwyitCash Bank (QB)

[0141] QI-T: QC.com Settlement start.fwdarw.QI

[0142] QB-R: QB reply.fwdarw.QC.com

[0143] QM-X: Merchant Cancel.fwdarw.QC.com

[0144] QC-X: Consumer Cancel.fwdarw.QC.com

Gift Transaction Giving Processing Messages

[0145] QC-G: Consumer Gift Giving Transaction Start.fwdarw.QC.com

[0146] QI-G: QC.com QI Gift Start.fwdarw.QI

[0147] QI-R: QI reply.fwdarw.QC.com

[0148] QC-R: QC.com reply.fwdarw.Gift Giving Consumer

[0149] QC-A: Consumer Accept Gift Giving Transaction.fwdarw.QC.com

[0150] QI-T: QC.com QI Settlement Record.fwdarw.QI

Gift Transaction Redemption Processing Messages

[0151] This process is an overlay of Normal Transaction Processing, the only new messages:

[0152] QC-D: Consumer Decline Gifts.fwdarw.QC.com

[0153] QC-I: Consumer Interim Gift Transaction use.fwdarw.QC.com

[0154] QC-F: Consumer Last of Multiple Gift Transaction use.fwdarw.QC.com

[0155] System RequirementsResult Flag Values

The following are all of the Result Flag values for the QC processes:

Registration Result Flags

[0156] ZNEWNew OpenID request or value reply

[0157] ZMQKNew Master Qwyit Key (MQK)

[0158] ZMEKNew Master Exchange Key (MEK)

[0159] ZNPCNew QwyitCash Participant (Merchant/Consumer) ConfirmedRegistration Complete!

[0160] ZNWMNew Merchant Communication check

[0161] ZNWCNew Consumer Communication check and PIN storage

[0162] ZNMSNew Merchant SuccessRegistration Complete!

[0163] ZNCSNew Consumer SuccessRegistration Complete!

Normal Transaction Processing Result Flags

[0164] ZZZZNot a viable Qwyit message. Try again.

[0165] ZZMSMerchant Start messageopen the transaction.

[0166] ZZCSConsumer Start messagejoin the transaction by QCC found in VF

[0167] ZNRENo Transaction Record Match! Check QC Code and Amount Entry and try again

[0168] ZCCCQC.com has returned this transaction's QC Codefound in Value Flag (VF)

[0169] ZQISQI Start messageauthorize the transaction.

[0170] ZATXIssuer has received wrong Authentication Tokentry again (although PIN is correct; key may be corruptpossible re-registration), or choose another QwyitCash Issuer

[0171] ZCDXIssuer has DENIED creditchoose another QwyitCash Issuer

[0172] ZFAAFull Amount Approved! (Normal transaction)

[0173] ZZOKAccepted transaction. Awaiting other party Acceptance and Settlement

[0174] XXXXTransaction Canceled. End of Transaction.

[0175] ZDUNTransaction Complete! Thank you!

[0176] ZPRBSettlement Issueto be corrected upon Audit

[0177] ZENDTransaction Settlement Complete

Gift Transaction Giving Processing Result Flags

[0178] ZCGTConsumer Gift Giving Transaction (GGT)

[0179] ZQIGQI Gift Transaction Start messageauthorize the GGT

[0180] ZGOKConsumer Accepted Gift Giving TransactionGGT is now available for Recipient, QI notified of Consumer acceptance

[0181] ZGDNGift Giving Transaction Complete! Thank you!

Gift Transaction Redemption Processing Result Flags

[0182] ZGTIGift Transaction availableOne of multiple

[0183] ZGTFGift Transaction availableLast of multiple or Single

[0184] ZGTDConsumer Declines to use any available Gift Transactions

[0185] ZQIRQI Gift Transaction Redemption messagevalidate GGT, Recipient, Amount

[0186] ZGNRNo QI Gift Transaction record match! QC.com must cancel transaction with Consumer

[0187] ZGXXNo Gift Transaction confirmation, Transaction Canceled by QC.com. Try Again

[0188] ZFGAGift Transaction Approval (Gift Redemption)

Gift Transaction Status Check Processing Result Flags

[0189] ZCGCConsumer Gift Check

Note: If any participant receives a not-viable QwyitTalk communications message in any process, they will auto-reply to the sender to try again in a Qx-R format with an RF=ZZZZ. If receive two consecutive messages from the same entity, the reply will be with an RF=XXXX and any in-progress transaction will be canceled. The following message streams assume proper QwyitTalk formatted message traffic.

[0190] Registration Process

[0191] Registration Process Flow Diagram

See FIG. 1.

[0192] Registration ProcessOverview

[0193] The following are the requirements to register for provision of QwyitCash credit transactions: [0194] QIs and QBs will register at QwyitCash.com using Qwyit two-channel authentication; they will provide the required information for their QwyitCash participant classification using the Qwyit protocol Verified Setup (VSU). [0195] An entity may register as both classifications [0196] The QI and/or QB will operate the QwyitCash (QC) Provider software, which includes [0197] QI: Consumer registration, Transaction Processing, Approval and Settlement [0198] QB: Merchant registration, Transaction Processing, Approval and Settlement [0199] Merchants and Consumers will register at their chosen QB or QI, respectively. [0200] Consumers will register at any of the QwyitCash Issuers (QI) using the QI's process (online using HTTPS, paper form entry, etc.); they will provide QI requirements to purchase on credit [0201] Consumers can check the status and availability of any and all QIs at QwyitCash.com [0202] For first-time Consumer QwyitCash participation registration, QI provides all QwyitTalk communication registration (as detailed below using the QwyitTalk Verified Setup (VSU) process and submits to QC.com (OpenID, 2 QwyitTalk keys, Authentication Token)QI doesn't keep the Consumer's QC.com communication keys [0203] QI provides a 256-bit 64-hex-digit Authentication Token to Consumer for submission whenever using this QI's line of credit for a purchasethis AuthToken is the credit card replacement [0204] For any subsequent Consumer QI registration(s), the Consumer must again meet the QI's process, beginning with a new 256-bit 64-hex-digit Authentication Token [0205] The QwyitCash app will store the QI as a choice to be selected during a QC transaction. The app will also store the Consumer's QwyitCash keys and AuthToken after encryption by their chosen PIN, as detailed below in the PIN Stealth section. During registration, the Consumer will also choose and enter a Personal Identifier (24 chars max). This will not need to be system-unique, as it will be in combination with their unique OpenID. [0206] Consumers will be publicly listed (OpenID and Personal Identifier) on QC.com once they have downloaded, opened and performed Setup with their QC app. [0207] Merchants will register at any of the QwyitCash Banks (QB) using the QB's process (online, etc.); they will provide QB requirements for transaction settlement into their account(s) [0208] Merchants can check the status and availability of any and all QBs at QwyitCash.com [0209] For first-time Merchant QwyitCash participation registration, QB provides all QwyitTalk communication registration (also using QwyitTalk's VSU) and submits to QC.com (OpenID, 2 QwyitTalk keys, Token)QB doesn't keep the Merchant's QC.com communication keys [0210] QB provides a 256-bit 64-hex-digit Authentication Token to Merchant for submission whenever using this QB's Bank for transaction settlement [0211] For any subsequent Merchant QB registration(s), the Merchant must again meet the QB's process, beginning with a new 256-bit 64-hex-digit Authentication Token [0212] The QwyitCash app will store the QB as the default settlement bank to be used during a QC transaction. The app will also store the Merchant's QwyitCash keys and AuthToken using any Best Practices storage technique, including PIN stealth (there isn't the same lost device security requirement as there is for a Consumer's QwyitCash device.) [0213] Note: There are so many different types and sizes of Merchants; the number of QB registrations and/or tying together multiple locations, stores, online operations and servers, etc. may require an additional QwyitTalk network communications process for coordination. It also may easily be accomplished by individual POS registration. Regardless of the system in place, this document will treat/define a Merchant as a single entity/single QwyitTalk keyed relationship. Any QwyitTalk network will be able to support this definition (accomplished by federated trust) while maintaining security. [0214] As part of all participants registration noted above, they will perform a Qwyit VSU and receive their Qwyit communication keys (2, 64-hex-digits, 256-bits each recommended) as per the Qwyit Protocol Reference Guide [0215] QIs, QBs will properly store and protect these keys using Best Practices techniques [0216] Merchants will store and protect these keys dependent on their Qwyit network setup and POS communication processes, and as noted above [0217] Consumers will encrypt these keys in storage by memorizing the QwyitCash produced PIN shown during registrationthis PIN is not stored anywhere other than in the Consumer's memory, and the keys are useless without PIN entry each transaction [0218] Consumer QwyitCash PIN is minimally a 6-hex-digit number, randomly generated [0219] Consumers may update this PIN at any time [0220] Consumers will have N tries to correctly enter the PIN before lock-out, being required to update registration (essentially, re-register) at their QI [0221] Lost or stolen QC-enabled smart phones will have a N in >16,777,216 chance of accessing QwyitCash and performing a successful transaction (this is considered secure) [0222] There are no static, off-line dictionary attacks to know when the correct PIN is enteredonly during a transaction will QC.com deny an incorrectly entered PIN (as the key decryption to generate the correct keys will be wrong)

Registration ProcessDetails

[0223] Merchant/QB and Consumer/QI Step 1: Find desired QB (Merchant) or QI (Consumer) by reviewing those certified by QC.com as participating in QwyitCash credit processing and payment. After selection, follow the QC Provider's instructions in order to apply for an account; most likely, this will be performed online, using a secure HTTPS connection. After credit validation and verification, under the auspices of each individual QC Provider (this may be during the first session or some future interaction), at some point just after acceptance by both parties, the QC Provider will generate a unique Authentication Token for the Consumer/Merchant and request unique, unused OpenIDs from QC.com.

[0224] Note: Consumers certainly can register with multiple QwyitCash Issuers. All of the QC registration items will be held in a QC application running on their smart device; the application will handle multiple QI material. Merchants may register at different QwyitCash Banks, as well; except that QC Merchant transactions do not have a step for selecting a QB (for convenience!). If Merchants have multiple QBs, each POS QC app will need to have the default information for that POS session. Each POS may certainly have a different QB (and the QC POS app may allow storage of multiple QBs), but every transaction from a single POS during any one session will go to the same QB.

[0225] QI Step 1: Create QI-N: [0226] Values: QI-N, QI, null, New Customer's AuthToken, ZNEW, null, 0.00, ABC123 (randomly assigned beginning here) [0227] For Consumers who are re-registering (for any reason), the QI may ask if they have registered previously. However the QI authenticates that they are the same person (address, etc.), must be the same way they authenticate originally. All of the QwyitCash registration info (OpenID, Keys, PIDs, PINs, etc.) will be replaced. [0228] Send to QC.com
Note: For all of the following, the descriptive word Values: is no longer repeated for the value assignments for each record.

[0229] QB Step 1: Create QB-N: [0230] QB-N, QB, null, New Merchant's AuthToken, ZNEW, null, 0.00, ABC123 (randomly assigned beginning here) [0231] Re-registration will provide all new QC information [0232] Send to QC.com

[0233] QC.com Step 2: Decrypt QI-NIQB-N [0234] Generate unique OpenID; create a record in the key store for new Customer/Merchant, using new OpenID and their AuthToken. Create QI-OlQB-O: [0235] QB-O, QB, NewOpenID, New Merchant's AuthToken, ZNEW, null, 0.00, ABC123 [0236] QI-O, QI, NewOpenID, New Customer's AuthToken, ZNEW, null, 0.00, ABC123 [0237] Send to QI/QB

[0238] QI Step 3: Decrypt QI-O [0239] Assign the new OpenID to their Consumer's account, matching their new Authentication Token [0240] Perform a QwyitTalk VSU with the Consumer as per that protocol, in order to obtain their QwyitTalk keys used in QwyitCash [0241] Notify Consumer to go to QC.com, obtain proper platform QwyitCash application and perform first connect Setupthis will allow entry of the VSU keys and PID [0242] Part of the VSU registration with the QI will ask for input of a Personal Identifier (24 characters maximum). This should be something unique and that can be given (and said) publicly (but there will be no check in any QI or QC.com recordsthe combination of this Personal ID (PID) with the coming truly unique OpenID will be singularit's up to people to be decent.) This ID will be held publicly in the Consumer's QC app, as well as at QC.comit is sent in this step [0243] Upon completion of the VSU with the Consumer, send the keys and PID to QC.com for system participationand delete the keys as they are not stored by the QI. Create QI-K: [0244] QI-K, QI, Consumer's OpenID, New Consumer's Master Qwyit Key (MQK), ZMQK, New Consumer's Personal ID, 0.00, ABC123 [0245] Send to QC.com [0246] QI-K, QI, Consumer's OpenID, New Consumer's Master Exchange Key (MEK), ZMEK, New Consumer's Personal ID, 0.00, ABC123 [0247] Send to QC.com

[0248] QB Step 3: Decrypt QB-O [0249] Assign the new OpenID to their Merchant's account, matching their new AuthToken [0250] Perform a QwyitTalk VSU with the Merchant as per that protocol, in order to obtain their QwyitTalk keys used in QwyitCash [0251] Notify Merchant to go to QC.com, obtain proper platform QwyitCash application and perform first connect Setupthis will allow entry of the VSU keys [0252] Upon completion of the VSU with the Merchant, send the keys to QC.com for system participationand delete the keys as they are not stored by the QB. Create QB-K: [0253] QB-K, QB, Merchant's OpenID, New Merchant's Master Qwyit Key (MQK), ZMQK, null, 0.00, ABC123 [0254] Send to QC.com [0255] QB-K, QB, Merchant's OpenID, New Merchant's Master Exchange Key (MEK), ZMEK, null, 0.00, ABC123 [0256] Send to QC.com

[0257] Merchant Step 3: Obtain QwyitCash application for their platform [0258] Upon opening QC app, since there are no keys, it will prompt for OpenID and Key input (Setup menu item, for re-registrations)performing the VSU at QB website has produced key value receipt in multiple channels; these will be entered into QwyitCash

[0259] Consumer Step 3: Obtain QwyitCash application for their platform [0260] Upon opening QC app, since there are no keys, it will prompt for OpenID and Key input (Setup menu item, for re-registrations)performing the VSU at QI website has produced key value receipt in multiple channels (and PID creation); these will be entered into QwyitCash

[0261] QC.com Step 4: Decrypt QI-KIQB-K [0262] Update Consumer/Merchant records in the key store for new QwyitCash QwyitTalk keys, using new OpenID and their AuthToken. [0263] Reply Confirmation of New QwyitCash Participant. Create QI-CIQB-C: [0264] QB-C, QB, NewOpenID, New Merchant's AuthToken, ZNPC, null, 0.00, ABC123 [0265] QI-C, QI, NewOpenID, New Customer's AuthToken, ZNPC, null, 0.00, ABC123 [0266] Send to QI/QB

[0267] QB Step 5: Decrypt QB-C [0268] New QwyitCash Merchant participant Confirmed! Update records to show Active [0269] REGISTRATION COMPLETE

[0270] QI Step 5: Decrypt QI-C [0271] New QwyitCash Consumer participant Confirmed! Update records to show Active [0272] REGISTRATION COMPLETE

[0273] Merchant Step 5: Continuing QC Setup [0274] Merchant QwyitCash keys are stored in the application dependent on the platform and POS device formportable, single-server network control, etc. The QC app will ask for appropriate input for key storage. Regardless of the type, there are no new data elements to be stored at QC.com (as there are with a Consumer), so the first message is simply a communication check. Create QM-N: [0275] QM-N, Merchant, OpenID, Merchant's AuthToken, ZNWM, null, 0.00, ABC123 [0276] Send to QC.com

[0277] Consumer Step 5: Continuing QC Setup [0278] Consumer QwyitCash keys are stored in the application using a PIN. The PIN is used by QwyitTalk to store a securely Qwyit-encrypted version; which must be decrypted by PIN entry every use. The PIN is an up-to-eight (8) hexadecimal digit value that is randomly assigned by the applicationand prior to sending this confirmation, it will be generated and shown to the Consumer. Human memorization of up to 10 digits is routine (phone numbers, SSNs, etc.), and QwyitCash will use a minimum of six (6), with seven (7) preferable (presented as xxx-xxxx for quick memorization). The Consumer must memorize, and then enter the PIN to continue Setupthe PIN will never be stored anywhere, by any device. [0279] If unsuccessful (which will only be shown by the reply from QC.com in Step 7, Consumer will have two (n) additional attempts. N (N) unsuccessful entries will result in lockout, and the Consumer will need to return to Step 1, and re-register with their QI. (The number of unsuccessful tries will be tied to the PIN length) [0280] Create QC-N: [0281] QC-N, Consumer, OpenID, Consumer's AuthToken, ZNWC, Personal Identifier, 0.00, ABC123 [0282] Send to QC.com [0283] Note: The Personal Identifier was entered along with the VSU key datait is submitted to QC.com for use in positively identifying a participant (for Gift transactions, etc.).

[0284] QC.com Step 6: Decrypt QM-N [0285] Upon successful decryption, reply Confirmation of New QwyitCash Participant. [0286] Create QM-R: [0287] QM-R, QC.com, Merchant, Merchant's AuthToken, ZNMS, null, 0.00, ABC123 [0288] Send to Merchant

[0289] QC.com Step 6: Decrypt QC-N [0290] Upon successful decryption, add Personal Identifier to Consumer's record and reply Confirmation of New QwyitCash Participant. Create QC-R: [0291] QC-R, QC.com, Consumer, Consumer's AuthToken, ZNCS, null, 0.00, ABC123 [0292] Send to Consumer

[0293] Note: It is possible, during this Consumer communication check, to allow/have the Consumer's QC-N include the PIN using the VF field. Then QC.com could update the Consumer's record in the key store to have the PIN. As there is no apparent, as yet, need for this (and it unnecessarily introduces the PIN into the message chain), it is not recommended.

[0294] Merchant Step 7: Decrypt QM-R [0295] Upon successful decryption, If RF=ZNMS [0296] Screen says Welcome to QwyitCash! You are Operational! [0297] REGISTRATION COMPLETE

[0298] Consumer Step 7: Decrypt QC-R [0299] Upon successful decryption, If RF=ZNCS [0300] Screen says Welcome to QwyitCash! Better Than Money! You may charge at any participating merchant! Your PIN is AEF4 5678you MUST memorize it to use QwyitCash. It is NOT stored! If you are unable to log in N times, you will be required to re-register at your QI! The PIN will never be stored or shown again (as there is no storage of it); the Consumer must correctly enter it upon every QwyitCash transaction. [0301] REGISTRATION COMPLETE

[0302] Normal Transaction Payment

[0303] Normal Transaction Payment Flow Diagram

[0304] See FIG. 2.

[0305] Normal Transaction PaymentOverview

[0306] Normal Transaction Payment (QwyitCash Credit Processing) is identical to current MerchantConsumer credit processing. QwyitCash has streamlined the process, fully securing it while removing the physical credit cardbut hasn't changed the needs or preparedness of any of the participants. We invented a better way to perform and process credit transactions. The Merchant totals the merchandise or services to be bought, the Customer/Consumer is asked how they will pay, and QwyitCash (credit) is declared. The Consumer asks their lender to back the purchase, the Merchant's bank and the Consumer's credit Issuer transact a financial exchange, and the Consumer takes the good/services. QwyitCash transaction processing works for all types of credit transactions, including Internet, physical location, phone, restaurant, etc.

[0307] Normal Transaction PaymentUnique QwyitCash Codes (OCC)

[0308] These 23-unique alpha-numeric values (called QC codes, QCC), creating 12,167 (23.sup.3) possible Codes for each transaction amount, will be either shown, told or automated from the Merchant to the Consumer in Step 3, joining the transaction. These values have unique spoken and written characteristics in order to avoid verbal communication and input errors; for translating QwyitCash to other languages, these codes may be adjusted to retain spoken/written uniqueness. Merchant screens may/should be designed for easy Consumer reference to distinctly show the three code values along with the transaction Amount (where not read automatically by the Consumer's smart device):

[0309] a b, f, h, i, m, o, q, r, s, u, w, x, y, 1, 2, 4, 5, 6, 7, 8, 9, 0

[0310] Notes on Transaction Synching

[0311] Consumer Step 3 entails entering the 3-character QCC. While noted that this entry may be automated, and code definition has been limited for verbal communication error reduction, there is a small possibility of waiting for a clear code. There are 12,167 QCC's per transaction amount available during any open transaction interval (lasting from 5-120 seconds, estimated approximately.) It is possible that all codes are being used, and any particular transaction will need to wait until a transaction is closed (canceled or completed) and a code becomes available. This will almost never occur, even if every credit transaction in the world were to be QwyitCash processed. [e.g., 400 B/year =190K/15-seconds, with an average of 10K different values ($50-150 average transaction), each w/12,167 codes leaves 121.7M codes to cover 190K transactions.] Should it occur, the transaction would simply be delayed by a few seconds as codes roll off in order to send an available Code for the Merchant to provide. If desired, the QCC can be increased to 4 characters, with each Amount having 279,841 values; the only drawback is more Consumer error possibilities (unless QCC and Amount entry are automated, in which case 4 characters would be recommended.)

[0312] Should the Consumer enter the wrong code, their reply will alert them to No Transaction Record match, Result Flag=ZNRE, and they would re-enter the correct value. With manual entry, there is a minute chance of entering the wrong code that happens to be the correct code for another open Consumer transaction for the exact amount. This error is eliminated with automated entryif it passed, and no one noticed (all parties), the finances are correct, but the payees are wrong; yes this might have tax or other implications (Merchant sales taxes, etc.), but an error to completion is nearly impossible.

[0313] Normal Transaction Payment Credit ProcessingDetails

[0314] Note: All QwyitCash platform software applications for Merchant and Consumer will always show a Cancel button so any transaction may be terminated by either party at any time up until Merchant and Consumer both Accept the transaction.

[0315] Merchant Step 1: Create QM-S message after totaling Amount and confirming that Consumer will pay using QwyitCash [0316] QM-S, Merchant, Merchant's QB, Merchant AuthToken for this QB, ZZMS, null, xxx.xx, ABC123 (randomly assigned beginning here) [0317] Amount may include for a refund [0318] Send to QC.com

[0319] Note: Some Merchants may allow Consumer to pay partial amounts using QwyitCash, and the rest of the transaction in other ways. If this is to be done, the Merchant MUST only start a QC transaction for the PARTIAL amount. This is because of the transaction joining method; so Merchant must split the purchase PRIOR to starting a QC credit transaction.

[0320] QC.com Step 2: Decrypt QM-S, Evaluate RF [0321] Open Normal Status transaction record w/QM-S values [0322] Assign unique QCC (await open QC Code value per amount, if necessary), add to record [0323] Create QM-R, reply to Merchant [0324] Values: QM-R, QC.com, Merchant's QB, Merchant, ZCCC, abf, xxx.xx, ABC123 (where VF=assigned QCC) [0325] Send to Merchant

[0326] Merchant Step 3: Decrypt QM-R, evaluate RF and VF [0327] Convey QCC to Consumer

[0328] Note: It is certainly possible to allow the Consumer's smart device to read the QCC from the Merchant, automating entry and reducing errors. This is opposite of current systems where Merchant devices read Consumer devices. Existing hardware (photo and image processing) already exists on most smart devices, so this automation wouldn't involve any cost.

Consumer Step 3: Opens QwyitCash application, enters PIN, selects QI for this transaction, enters Amount, and QCC; this creates QC-S message

[0329] QC-S, Consumer, QI's ID, Consumer's QI AuthToken, ZZCS, abf, xxx.xx, null (where VF=input QCC, which must match Merchant QCC and Amount) [0330] The TransactionID will be null in this first QC-S until synched with the Merchants [0331] Send to QC.com

QC.com Step 4: Decrypt QC-S

[0332] If RF=ZZCS: Find QCC/Amount match in open QM-S records awaiting payment settlement [0333] No such record exists [0334] Create QC-R, RF=ZNRE [0335] QC-R, QC.com, Consumer, null, ZNRE, null, xxx.xx, ABC123 [0336] Send to Consumer to try again (QC software will show Wrong amount or Codetry again, and Consumer would repeat Step 3 from the beginning (PIN, etc.)) [0337] QM-S Record found [0338] Update with Consumer info (Consumer's OpenID, QI-AuthToken, QI-OpenID, QCC and Amount (record has now been synched) [0339] Nextcheck if there are any OPEN Gift transactions available for this Consumer. If NO, proceed [0340] Create QI-S (QI Authorization record) [0341] QI-S, QC.com, QI's OpenID, Consumer's AuthToken, ZQIS, null, xxx.xx, ABC123 [0342] Send to QI [0343] If YES, proceed for Gift-based transactionSee Gift Redemption for complete process details

QI Step 5: Decrypt QI-S

[0344] Validate Consumer's AuthToken, and if OK, make credit decision based on person and Amount and record all QwyitCash record values for billing consumer, etc. This record must be accepted by the Consumer in Step 7 and isn't final until receiving a QI-T request. [0345] Wrong Authentication Token [0346] Create QI-R, set RF=ZATX, Amount=0.00 [0347] QI-R, QI, Consumer, null, ZATX, null, 0.00, ABC123 [0348] Send to QC.com [0349] Credit Denied [0350] Create QI-R, RF=ZCDX, Amount=0.00 [0351] QI-R, QI, Consumer, null, ZCDX, null, 0.00, ABC123 [0352] Send to QC.com [0353] Credit ApprovedFull Amount requested [0354] Create QI-R, RF=ZFAA, Amount=full amount allowed, xxx.xx [0355] QI-R, QI, Consumer, null, ZFAA, null, xxx.xx, ABC123 [0356] Send to QC.com
QC.com Step 6: Decrypt QI-R (Replies, as all of the messaging, are matched by TransactionID)

[0357] For the following RF values, Reply to Consumer because of issues

[0358] If RF=ZATX [0359] Create QC-R, RF=ZATX, Amount=0.00 [0360] QC-R, QC.com, QI, Consumer's AuthToken, ZATX, null, 0.00, ABC123 [0361] Send to Consumer

[0362] If RF=ZCDX [0363] Create QC-R, RF=ZCDX, Amount=0.00 [0364] QC-R, QC.com, QI, null, ZCDX, null, 0.00, ABC123 [0365] Send to Consumer

[0366] For the following RF value, Reply to Consumer and Merchantcredit approved

[0367] If RF=ZFAA Then Full Amount Approved [0368] Update transaction w/QI approval (Approved amount will equal Transaction amount, so proceed) [0369] Create QC-R, RF=ZFAA, Amount=QI approved Amount [0370] QC-R, QC.com, QI, null, ZFAA, null, xxx.xx, ABC123 [0371] Send to Consumer [0372] Create QM-R, RF=ZFAA, Amount=QI approved Amount [0373] QM-R, QC.com, Consumer, null, ZFAA, Personal ID, xxx.xx, ABC123 [0374] Send to Merchant
Merchant Step 7: Decrypt QM-R, evaluate RF (If Merchant is keeping an audit log of all transactions, the Consumer's OpenID and PID is returned in this credit reply for synching to transaction)

[0375] If RF =ZFAA then Screen notified Consumer Credit Approved! Accept/Cancel? Show the QCC and Amount [0376] Create QM-A, RF=ZZOK (Accept), RF=XXXX (Cancel) [0377] QM-A, Merchant, QB's ID, Merchant's QB AuthToken, ZZOK, abf, xxx.xx, ABC123 [0378] Send to QC.com
Consumer Step 7: Decrypt QC-R (Consumer now has the proper TransactionID)

[0379] If RF=ZATX then Screen notified Authentication Code errorTry again or choose another QwyitCash Issuer [0380] Begin again at Step 3 (using same QCC) [0381] If occurs a 2.sup.nd time, ABORT TRANSACTION by performing Step Xand check for connection/key storage errors

[0382] If RF=ZCDX then Screen notified Credit has been DENIEDCancel or Try again with a different QwyitCash Issuer [0383] Begin again at Step 3 (using same QCC, but different QI)

[0384] If RF=ZFAA then Screen notified Approved! Accept/Cancel? Show the QCC and Amount [0385] Create QC-A, RF=ZZOK (Accept), RF=XXXX (Cancel) [0386] QC-A, Consumer, QI's ID, Consumer's QI AuthToken, ZZOK, abf, xxx.xx, ABC123 [0387] Send to QC.com

[0388] If RF=ZNRE then Screen notified Wrong Amount or CodeTry entering again [0389] Begin again at Step 3 (using same QCC) [0390] If occurs a 2.sup.nd time, ABORT TRANSACTION by performing Step Xand check for connection/key storage errors

QC.com Step 8: Decrypt QM-A, QC-A

[0391] For either RF=XXXX (Merchant and/or Consumer Canceled) [0392] Follow Step X process for Transaction Cancelation

[0393] For both RF=ZZOK (both have Accepted) [0394] Update QM-S Open Normal Transaction record for both acceptance [0395] Create QM-R, reply to Merchant [0396] QM-R, QC.com, Merchant's QB, null, ZDUN, abf, xxx.xx, ABC123 [0397] Send to Merchant [0398] Create QC-R, reply to Consumer [0399] QC-R, QC.com, Consumer's QI, null, ZDUN, abf, xxx.xx, ABC123 [0400] Send to Consumer [0401] Create QB-T (QB Settlement record) [0402] QB-T, QC.com, QI's OpenID, Merchant's AuthToken, ZDUN, abf, xxx.xx, ABC123 [0403] Send to QB [0404] Create QI-T (QI Settlement record) [0405] QI-T, QC.com, QB's OpenID, Consumer's AuthToken, ZDUN, abf, xxx.xx, ABC123 [0406] Send to QI [0407] No need here to wait for QB/QI replyif unsuccessful for any reason, QM-S record will remain OPEN for periodic (24 hour recommended) audit and final settlement

QI Step 9: Decrypt QI-T

[0408] Validate Consumer's AuthToken, and if OK (can also check against the previously approved credit decision) and record all QwyitCash values for settlement, etc.Settlement will be with the same TransactionID at the QB's OpenID in OpenID2 [0409] Wrong Authentication Token [0410] Create QI-R, RF=ZPRB, Amount=xxx.xx [0411] QI-R, QI, QB, Consumer's AuthToken, ZPRB, null, xxx.xx, ABC123 [0412] Send to QC.com [0413] Settlement Approved [0414] Create QI-R, RF=ZEND, Amount=xxx.xx [0415] QI-R, QI, QB, Consumer's AuthToken, ZEND, null, xxx.xx, ABC123 [0416] Send to QC.com

QB Step 9: Decrypt QB-T

[0417] Validate Merchant's AuthToken, and if OK record all QwyitCash values for settlement, etc.Settlement will be with the same TransactionID at the QI's OpenID in OpenID2 [0418] Wrong Authentication Token [0419] Create QB-R, RF=ZPRB, Amount=xxx.xx [0420] QB-R, QB, QI, Merchant's AuthToken, ZPRB, null, xxx.xx, ABC123 [0421] Send to QC.com [0422] Settlement Approved [0423] Create QB-R, RF=ZEND, Amount=xxx.xx [0424] QB-R, QB, QI, Merchant's AuthToken, ZEND, null, xxx.xx, ABC123 [0425] Send to QC.com

Merchant Step 9: Decrypt QM-R

[0426] Evaluate RF [0427] If RF=ZDUN then Screen notified Transaction Complete! Thank Your Customer! [0428] TRANSACTION COMPLETE

Consumer Step 9: Decrypt QC-R

[0429] Evaluate RF [0430] If RF=ZDUN then Screen notified Transaction Complete! Enjoy your merchandise! [0431] TRANSACTION COMPLETE

QC.com Step 10: Decrypt QB-R, QI-R

[0432] If RF=ZEND [0433] Update QM-S record as having successfully notified QB and/or QI for settlement

[0434] If RF=ZPRB [0435] Update QM-S record as having a QB and/or QI settlement error (of any type)

[0436] TRANSACTION COMPLETE

QC.com Step Periodic (some minute interval): Check QM-S records for completenesswill have both QI and QB settlement codes (the corresponding RF values):

[0437] If both values=ZEND, then move the QM-S record to the Complete Settlement area for audit storage

[0438] If either value=ZPRB, then move the QM-S record to the Settlement Problem Area for periodic submission for resolution to the corresponding QI and QB (24-hour recommended, in a TBD QwyitTalk communication sequence, if desired)

Merchant Step X: Merchant can cancel any time prior to Acceptance in Step 7

[0439] Create QM-X message, RF=XXXX [0440] QM-X, Merchant, null, null, XXXX, QCC, xxx.xx, ABC123 [0441] Send to QC.com
Consumer Step X: Consumer can cancel any time prior to Acceptance in Step 7

[0442] Create QC-X message, RF=XXXX [0443] QC-X, Consumer, null, null, XXXX, QCC, xxx.xx, ABC123 [0444] Send to QC.com
QC.com Step X: If at any time, receive a QM-X or QC-X message:

[0445] Decrypt QM-X or QC-X, evaluate RF, if RF=XXXX [0446] Look for, and if exists, update QM-S Open Normal Transaction from Open status to Canceled [0447] If record does not exist, simply ignore

Gift Transaction Creation

Gift Transaction Creation Flow Diagram

See FIG. 3.

[0448] Gift Transaction CreationOverview

[0449] The streamlined QwyitCash system enables Consumers to buy gift cards for each otherand just as with the removal of the physical credit card from normal credit transactions, QwyitCash has removed the physical gift card from Gift Card purchases. This does not impact the purchase of any particular Merchant's cards, but it does remove the need to buy Credit Card Processor and Bank/debit cards (such as a Visa gift card.) Gift Transaction Creation allows any Consumer to give another QwyitCash participating Consumer a Gift Transaction that they may use everywhere QwyitCash is accepted. Whenever paying by QC, the Consumer will be notified that they have Gift Transactions available (shown the Amounts and from which Consumers) and asked if they want to use one (or more). This is akin to PayPal Personal without the cash transaction feesand just like buying a Credit Gift Card, but without the physical card.

[0450] Gift Transaction CreationPurchase and Give Gift Transaction ProcessingDetails

[0451] Consumer Step 1: Opens QwyitCash application, enters PIN, and selects Purchase and Give Gift Transaction (GT). Selects QI for this Gift Giving Transaction (GGT), enters Amount to Give, and the Personal Identifier of the recipient (RPI), and the OpenID of the recipient (ROI); this creates a QC-G message [0452] QC-G, Consumer's OID, ROI, Consumer's Chosen-QI AuthToken, ZCGT, RPI, xxx.xx (Amount to Give), TransactionID (Created here to start, ABC123) [0453] Send to QC.com

[0454] Note: QC.com will have all QC Consumer participants listed publicly by Personal ID and OpenID. QC app will HTTP (publicly) connect to QC.com and allow Consumers to select recipients and auto-fill the values. This should be a requirement to avoid multiple cyclic transmissions with failed recipient value entry attempts. There will also be a warning: Are you sure this is the correct recipient? If not, a stranger will be given your gift! There will NOT be any way for a Giver to cancel an approved GGT; double acceptance of the entered recipient should be standard app practice for Step 1. (Consumer will again accept this recipient, for the 3.sup.rd time, in Step 5.)

[0455] QC.com Step 2: Decrypt QC-G and Identify recipient (by ROI/RPI) [0456] No record exists for Recipient [0457] Reply to Consumer to try again at Step 1 (may happen more than once) [0458] Record exists for Recipient, create Open Gift Giving Transaction (GGT) record w/Consumer and Recipient values, including storing the QI's info (for future settlement) [0459] Create QI-G (QI Gift Authorization record) [0460] QI-G, QC.com, QI's OpenID, Consumer's AuthToken, ZQIG, RPI, xxx.xx, ABC123 [0461] Send to QI

[0462] QI Step 3: Decrypt QI-G [0463] Validate Consumer's AuthToken, and if OK, make credit decision based on person and Amount and record all QwyitCash record values for billing consumer, etc. This record is different than a Normal Transaction in that it may be held for an extended period of time prior to settlement; the originating (Gift Giving) Consumer will be billed, but the record will be settled during another transactions QI-S record. QI's will handle these as required. These records must be accepted by the Consumer in Step 5. [0464] Wrong Authentication Token [0465] Create QI-R, set RF=ZATX, Amount=0.00 [0466] QI-R, QI, Consumer, Consumer's AuthToken, ZATX, null, 0.00, ABC123 [0467] Send to QC.com [0468] Credit Denied [0469] Create QI-R, RF=ZCDX, Amount=0.00 [0470] QI-R, QI, Consumer, null, ZCDX, null, 0.00, ABC123 [0471] Send to QC.com [0472] Credit ApprovedFull Amount requested [0473] Create QI-R, RF=ZFAA, Amount=full amount allowed, xxx.xx [0474] QI-R, QI, Consumer, null, ZFAA, null, xxx.xx, ABC123 [0475] Send to QC.com

[0476] QC.com Step 4: Decrypt QI-R (These QI replies are matched by TransactionIDthey are the same credit codes for both Normal and Gift Giving Transactions)

[0477] For the following RF values, Reply to Consumer because of issues [0478] If RF=ZATX [0479] Create QC-R, RF=ZATX, Amount=0.00 [0480] QC-R, QC.com, QI, Consumer's AuthToken, ZATX, null, 0.00, ABC123 [0481] Send to Consumer [0482] If RF=ZCDX [0483] Create QC-R, RF=ZCDX, Amount=0.00 [0484] QC-R, QC.com, QI, null, ZCDX, null, 0.00, ABC123 [0485] Send to Consumer

[0486] For the following RF value, Reply to Consumercredit approved [0487] If RF=ZFAA Then Full Amount Approved [0488] Match by TransactionID in GGT, update transaction w/QI approval [0489] Create QC-R, RF=ZFAA, Amount=QI approved Amount [0490] QC-R, QC.com, QI, null, ZFAA, null, xxx.xx, ABC123 [0491] Send to Consumer

[0492] Consumer Step 5: Decrypt QC-R [0493] Evaluate RF and Amount [0494] If RF=ZATX then Screen notified Authentication Code errorTry again or choose another QwyitCash Issuer [0495] Begin again at Step 1 (re-try, choose another QI, or cancel) [0496] If occurs a 2.sup.nd time with same QI, ABORT TRANSACTION by performing Step Xand check for connection/key storage errors (re-register w/QI as AuthToken may be corrupt) [0497] If RF=ZCDX then Screen notified Credit has been DENIEDCancel or Try again with a different QwyitCash Issuer [0498] Begin again at Step 1 (choose a different QI, or cancel) [0499] If RF=ZFAA then Screen notified Approved! Accept to Give Gift or Cancel? Show the RPI/ROI and Amount [0500] Create QC-A, RF=ZGOK (Accept), RF=XXXX (Cancel) [0501] QC-A, Consumer, ROI, null, ZGOK, RPI, xxx.xx, ABC123 [0502] Send to QC.com

[0503] QC.com Step 6: Decrypt QC-A [0504] For RF=XXXX (Consumer Canceled) [0505] Follow Step X process for Transaction CancelationGIFT GIVING TRANSACTION CANCELED [0506] For RF=ZGOK (Consumer Accepted) [0507] Update Open GGT record for acceptance and sent to QI for final readiness [0508] Create QC-R, reply to Consumer [0509] QC-R, QC.com, ROI, null, ZGDN, Personal ID, xxx.xx, ABC123 [0510] Send to Consumer [0511] Create QI-T (QI Settlement record) [0512] QI-T, QC.com, ROI, Consumer's AuthToken, ZGOK, Personal ID, xxx.xx, ABC123 [0513] Send to QI

[0514] Consumer Step 7: Decrypt QC-R [0515] Evaluate RF [0516] If RF=ZGDN then Screen notified Gift Giving Transaction Complete! Gift Transaction is available for Recipient! [0517] GIFT GIVING TRANSACTION COMPLETE

[0518] QI Step 7: Decrypt QI-T [0519] Evaluate RF and TransactionID [0520] If RF=ZGOK then Update GGT, bill Giving Consumer and ready record for subsequent, final settlement when used by Recipient [0521] Create QI-R, RF=ZGDN, Amount=xxx.xx [0522] QI-R, QI, Giving Consumer, null, ZGDN, null, xxx.xx, ABC123 [0523] Send to QC.com [0524] GIFT GIVING TRANSACTION COMPLETE

[0525] Note: QI is alerted that their Open GGT (however they have recorded it in their DB) is now accepted and active for the Recipient (ROI/RPI now known, recorded in QI's GGT). This is important because they will receive a QI-S message from QC.com to use this record/transaction for credit approval against some other QM-S sale, which will have a different TransactionID. Final settlement doesn't happen now, but later when the Recipient uses the GGT-QI holds the funds after billing Giving Consumer.

[0526] QC.com Step 8: Decrypt QI-R [0527] For RF=ZGDN (QI Recipient Ready) [0528] Update Open GGT to QI availability to Recipient, GGT Complete! [0529] GIFT GIVING TRANSACTION COMPLETE

[0530] Consumer Step X: Consumer can cancel any time prior to Acceptance in Step 5 [0531] Create QC-X message, RF=XXXX [0532] QC-X, Consumer, null, null, XXXX, Recipient's Personal ID, xxx.xx, ABC123 [0533] Send to QC.com

[0534] QC.com Step X: If at any time, receive a QC-X message: [0535] Decrypt QC-X, evaluate RF, if RF=XXXX [0536] Look for, and if exists, update QC-G Open Gift Giving Transaction from Open status to Canceled [0537] If record does not exist, simply ignore

[0538] Gift Transaction Payment

[0539] Gift Transaction Payment (Redemption) Flow Diagram

[0540] See FIG. 4.

[0541] Gift Transaction Payment (Redemption) ProcessingOverview

[0542] For any QwyitCash payment transaction, after synching with the Merchant's sales transaction, the Consumer will be notified if they have any available Gift Transactions; these are called Gift Giving Transactions (GGT) in the system, and are marked by the sending Consumer, the receiving Consumer (recipient) and the amount available. The Consumer may choose none, one, or many to cover the transaction amount. Should the Consumer choose not to use any GGTs, then the transaction is processed normally. If the Consumer chooses a GGT that is equal to or greater than the transaction, just that payment will be used (and if greater, the amount remaining is adjusted). If there is a remaining amount on the transaction after GGT selection (which can be more than one), then the Consumer's QI entry during the synch step will be used for credit approval.

[0543] Gift Transaction Payment (Redemption) ProcessingDetails

[0544] Note: Where the step, or parts of it, is identical to Normal Transaction Processing, the details are omitted since they can be found above.

[0545] Merchant Step 1: Create QM-S

[0546] QC.com Step 2: Decrypt QM-S

[0547] Merchant Step 3: Decrypt QM-R, Convey QCC to Consumer

[0548] Consumer Step 3: Opens QwyitCash application, enters PIN, selects QI for this transaction, enters Amount, and QCC; this creates QC-S message [0549] For simply checking the status of any available Gift Transactions, set RF=ZCGC and there would be no QI/Amount/QCC (See Gift Transaction Status Check); otherwise this QC-S is identical to Normal Processing [0550] Send to QC.com

[0551] QC.com Step 4: Decrypt QC-S [0552] If RF=ZZCS: Find QCC/Amount match in open QM-S records awaiting payment settlement [0553] No such record exists [0554] QM-S Record found [0555] Firstcheck if there are any OPEN Gift transactions available for this Consumer. If NO, proceed as per Normal Transaction Processing [0556] If YES, proceed here for Gift-based transactionafter updating the Merchant Transaction created in Step 2 to Gift Status (indicating this (where updated) unique, processing). [0557] This access point is also performed upon receiving a Step 3 QC-S request where RF=ZCGC (Consumer Gift Transaction Check)see Gift Transaction Status Check [0558] All of the available Gift Transactions will now be sent to Consumer (one per transmission); RF=ZGTI for each available where multiple, RF=ZGTF for single or final of multiple available [0559] Create QC-R, RF=ZGTI (if multiple, for each except last) [0560] QC-R, QC.com, OpenID of Giver, null, ZGTI, Personal ID of Giver, xxx.xx (amount of gift available), ABC123 [0561] Send to Consumer to ask if want to use (QC software will ready each of these for display to Consumer) [0562] Create QC-R, RF=ZGTF [0563] QC-R, QC.com, OpenID of Giver, null, ZGTF, Personal ID of Giver, xxx.xx (amount of gift available), ABC123 [0564] Send to Consumer to ask if want to use (QC software will ready this for display to Consumer)
Consumer Step 5: Decrypt QC-R (Consumer now has proper TransactionID)

[0565] Evaluate RF and Amount. If RF=ZGTI or ZGTF then Screen notified You have Gift Transactionswant to use it? (or one or more? if multiple). Reminder: at this point, QC.com has already synched and updated the QM-S record w/Consumer's info, including QI info should the GTs not add up to the total transaction value. Once Consumer has selected enough GTs to equal or exceed the transaction amount, app will interrupt and ask to send. [0566] Consumer chooses NOT to use any GT [0567] Create QC-D, RF=ZGTD (Decline), QC app has already synched and updated the QM-S record [0568] QC-D, Consumer, null, null, ZGTD, null, null, ABC123 [0569] Send to QC.com [0570] If Consumer chooses to use MORE THAN ONE GT (there can be more than one of the interim; e.g. Consumer has 5 GTs available, and choses to use 3, there will be two (2) ZGTI replies and one (1) ZGTF reply) [0571] Create QC-I, RF=ZGTI [0572] QC-A, Consumer, OpenID of Chosen Giver, null, ZGTI, Personal ID of Chosen Giver, xxx.xx (Amount of Gift), ABC123 [0573] Send to QC.com [0574] Consumer chooses to use a SINGLE GT or LAST of multiple GTs [0575] Create QC-F, RF=ZGTF [0576] QC-A, Consumer, OpenID of Chosen Giver, null, ZGTF, Personal ID of Chosen Giver, xxx.xx (Amount of Gift), ABC123 [0577] Send to QC.com
QC.com Step 6: Decrypt QC-D, QC-I, QC-F, reply from Consumer to use/decline GT(s)

[0578] If RF=ZGTD: Consumer has declined use of any GT(s) [0579] END OF GIFT REDEMPTIONContinue in Normal processing at Step 4, send to QI with info Consumer provided in Step 3, original QC-S

[0580] If RF=ZGTI: Consumer has accepted multiple GTs, more transmissions coming [0581] Decrypt QC-I [0582] Check Merchant Total AmountGift Amount=Running Merchant Total Amount; QC app dictates the running total must still be>0 and the total Gift Amount is to be used (otherwise, not a QC-I) [0583] Update GT record as TOTAL USED [0584] Create QI-S [0585] QI-S, OpenID of Recipient (Consumer), OpenID of Gift Giver, null, ZQIR, Personal ID of Recipient (Consumer), xxx.xx (Amount of Gift), ABC123 [0586] Send to QI

[0587] If RF=ZGTF: Last (only) Consumer accepted GT, end of Gift transmissions [0588] Decrypt QC-F, Get Gift Amount, have Running Merchant Total Amount (If there have been no QC-I messages, this is just the Merchant Total Amount) [0589] Check Running Merchant Total AmountGift Amount=Remaining Total [0590] If Remaining Total=0 [0591] Update GT record as TOTAL USED [0592] Create QI-S [0593] QI-S, OpenID of Recipient (Consumer), OpenID of Gift Giver, null, ZQIR, Personal ID of Recipient (Consumer), xxx.xx (Gift Amount), ABC123 [0594] Send to QI [0595] If Remaining Total is <0 then subtract Running Total from Gift Amount for Gift Amount to be Used, and Gift AmountGift Amount to be Used=Remaining Gift Amount [0596] Update GT record as PARTIAL USED, update to Remaining Gift Amount, send Gift Amount to be Used to QI [0597] Create QI-S [0598] QI-S, OpenID of Recipient (Consumer), OpenID of Gift Giver, null, ZQIR, Personal ID of Recipient (Consumer), xxx.xx (Gift Amount to be Used), ABC123 [0599] Send to QI [0600] If Remaining Total >0, so full Gift Amount is to be sent, and the Remaining Total of the transaction will need to be sent to the Original QI for approval [0601] Update GT record as TOTAL USED [0602] Create QI-S [0603] QI-S, OpenID of Recipient (Consumer), OpenID of Gift Giver, null, ZQIR, Personal ID of Recipient (Consumer), xxx.xx (Gift Amount), ABC123 [0604] Send to QI [0605] Create QI-S [0606] QI-S, QC.com, QI's OpenID, Consumer's AuthToken, ZQIS, null, xxx.xx (Remaining Total), ABC123 [0607] Send to QI

[0608] Note: There could be several different QI's sent to in this Step; the addresses are found in the GGT records from matching the Recipient, Giver OpenIDs and Amounts. The OpenID (e.g., address) of which QIs to send to will have been stored in the original GGT records during Step 2 of Gift Giving Transaction Processing.

QI Step 7: Decrypt QI-S, evaluate RF; If=ZQIR, these are Gift Redemptions

[0609] Validate GGT by Recipient OpenID (ROI), Recipient Personal ID (RPI), Amount, Gift Giver's Open ID and whether still available (TransactionID will be different, as record created in Giving transaction process, and transaction is already authorized and billed to Giving Consumer). Compare amounts; if amount requested is same (cannot be more), mark record as TOTAL USED AWAITING CONSUMER ACCEPT. If amount requested is less, mark record as PARTIAL USED AWAITING CONSUMER ACCEPT, noting amount. [0610] No such record (somehow, QC.com had an open available GGT that QI does notthis shouldn't happen, but, if does . . . ) [0611] Create QI-R, set RF=ZGNR, Amount=0.00 [0612] QI-R, OpenID of Recipient, OpenID of Gift Giver, null, ZGNR, Personal ID of Recipient, 0.00, ABC123 [0613] Send to QC.com [0614] GGT Available and ApprovedFull Amount requested [0615] Create QI-R, RF=ZFGA, Amount=full amount allowed, xxx.xx [0616] QI-R, QI, Consumer, null, ZFAA, null, xxx.xx, ABC123 [0617] Send to QC.com
Decrypt QI-S, If=ZQIS, this MAY occurit is for any Remaining Total after Gifts used

[0618] Validate Consumer's AuthToken, and if OK, make credit decision based on person and Amount and record all QwyitCash record values for billing consumer, etc. This record must be accepted by the Consumer in Step 8 and isn't final until receiving a QI-T request. [0619] Wrong Authentication Token [0620] Create QI-R, set RF=ZATX, Amount=0.00 [0621] QI-R, QI, Consumer, Consumer's AuthToken, ZATX, null, 0.00, ABC123 [0622] Send to QC.com [0623] Credit Denied [0624] Create QI-R, RF=ZCDX, Amount=0.00 [0625] QI-R, QI, Consumer, null, ZCDX, null, 0.00, ABC123 [0626] Send to QC.com [0627] Credit ApprovedRemaining Amount requested [0628] Create QI-R, RF=ZFAA, Amount=Remaining amount allowed, xxx.xx [0629] QI-R, QI, Consumer, null, ZFAA, null, xxx.xx, ABC123 [0630] Send to QC.com

[0631] Note: This step may be performed by multiple QI's, as the Consumer may have multiple GGTs provided by different Giving Consumers using different QI's; as well as a remaining transaction amount needing approval.

QC.com Step 8: Decrypt QI-R

[0632] For the following RF values, Reply to Consumer because of issues

[0633] If RF=ZGNR (QI did not have an open Gift Transaction for that Recipient, given by that Gift Giver)mark Open GGT as ERROR, CLOSED AT QI. [0634] Create QC-R, RF=ZGXX, Amount=0.00 [0635] QC-X, QC.com, QI's OpenID, null, ZGXX, Personal ID of Gift Giver, 0.00, ABC123 [0636] Send to Consumer

[0637] If RF=ZATX [0638] Create QC-R, RF=ZATX, Amount=0.00 [0639] QC-R, QC.com, QI, Consumer's AuthToken, ZATX, null, 0.00, ABC123 [0640] Send to Consumer

[0641] If RF=ZCDX [0642] Create QC-R, RF=ZCDX, Amount=0.00 [0643] QC-R, QC.com, QI, null, ZCDX, null, 0.00, ABC123 [0644] Send to Consumer
For the following RF value, Reply to Consumer and Merchantcredit approved;

[0645] If RF=ZFAA Then Remaining Amount Approved [0646] Check TransactionID, update transaction w/QI approval for Remaining Amount (Full transaction will be more than this partial approval). QC.com will not reply to Consumer until all QI approvals arriveseparating/marking distinctly for Step 10 Settlement.

[0647] If RF=ZFGA Then Gift Amount Approved [0648] Check Gift TransactionID, update transaction w/QI approval (already marked as PARTIAL or FULL). As each/any approval arrives, QC.com will mark them distinctly for Step 10 Settlement, and check the total approved amount versus the full transaction amount. If any of the Gifts, or the remaining amount are NOT approved, they will trigger a Transaction Canceled. So there SHOULD NOT be any issue with waiting (something never returns) until the approved amounts equal the transaction amount. When they equal, proceed with notifications to Consumer and Merchant. [0649] Create QC-R, RF=ZFAA, Amount=Total Approved Transaction Amount [0650] QC-R, QC.com, QI, null, ZFAA, null, xxx.xx, ABC123 [0651] Send to Consumer [0652] Create QM-R, RF=ZFAA, Amount=Total Approved Transaction Amount [0653] QM-R, QC.com, Consumer, null, ZFAA, null, xxx.xx, ABC123 [0654] Send to Merchant

Consumer Step 9: Decrypt QC-R

[0655] If RF=ZGXX then Screen notified QC Issuer cannot confirm Gift TransactionCanceled by QC.comTry again and choose another Gift, if available [0656] Begin again at Step 3 [0657] GIFT REDEMPTION CANCELED

[0658] If RF=ZATX then Screen notified Authentication Code errorCanceled by QC.com [0659] Begin again at Step 3 [0660] GIFT REDEMPTION CANCELED

[0661] If RF=ZCDX then Screen notified Credit has been DENIEDCanceled by QC.com [0662] Begin again at Step 3 [0663] GIFT REDEMPTION CANCELED

[0664] If RF=ZFAA then Screen notified Approved! Accept/Cancel? Show the QCC and Amount, Same as Consumer Step 7 in Normal Processing

Merchant Step 9: Decrypt QM-R, Same as Step 7 in Normal Processing

QC.com Step 10: Decrypt QM-A, QC-A

[0665] For either RF=XXXX (Merchant and/or Consumer Canceled) [0666] Follow Step X process for Transaction Cancelation

[0667] For both RF=ZZOK (both have Accepted) [0668] Update QM-S Open Gift Transaction records for both accepting [0669] Create QM-R, reply to Merchant [0670] QM-R, QC.com, Merchant's QB, null, ZDUN, abf, xxx.xx, ABC123 [0671] Send to Merchant [0672] Create QC-R, reply to Consumer [0673] QC-R, QC.com, Consumer's QI, null, ZDUN, abf, xxx.xx, ABC123 [0674] Send to Consumer [0675] If more than one approval for this same TransactionID, for each of the QI approvals marked in Step 8, send a distinct Settlement record (each amount will be different from the totaland may be from different QI's). [0676] Create QB-T (QB Settlement record) [0677] QB-T, QC.com, QI's OpenID, Merchant's AuthToken, ZDUN, abf, xxx.xx, ABC123 [0678] Send to QB [0679] Create QI-T (QI Settlement record) [0680] QI-T, QC.com, QB's OpenID, Consumer's AuthToken, ZDUN, abf, xxx.xx, ABC123 [0681] Send to QI [0682] No need here to wait for QB/QI replyif unsuccessful for any reason, QM-S record will remain OPEN for periodic (24 hour recommended) audit and final settlement

[0683] QI Step 11: Decrypt QI-TSame as Step 9 in Normal Processing

[0684] QB Step 11: Decrypt QB-TSame as Step 9 in Normal Processing

[0685] Merchant Step 11: Decrypt QM-RSame as Step 9 in Normal Processing

[0686] Consumer Step 11: Decrypt QC-RSame as Step 9 in Normal Processing

[0687] QC.com Step 12: Decrypt QB-R, QI-RSame as Step 10 in Normal Processing

[0688] QwyitCash Gift Transaction Status Check (Consumer)

[0689] Consumer's may open their QC app and check whether they have any available Gift Transactions at any time. This would simply be performing Steps 3 (as noted above), 4 and 5 in the above Gift Transaction Redemption Process; after viewing, then simply closing/canceling.

[0690] Security and Operational Benefits

[0691] QwyitCash has solved a large percentage of credit transaction problems, weaknesses, vulnerabilities and fraud; here are some of the QwyitCash solutions: [0692] Uses a provably secure, fast, small, authentication and data security technique, QwyitTalk [0693] This uniquely allows 256-bit symmetric key authentication and encryption from end-to-end in real time. No other current Public or Secret key methods would allow global, billions/day transmission/transaction processing in real time, let alone at that level of security [0694] No other system can provide one-pass, key exchange and update, embedded authentication and child key derivation as well as the world's fastest 5 CPU cycles/byte unique-key-per-256-bit stream encryption for real time, no performance degradation processing [0695] The user requirements for implementation are minimal and no more complicated than today's physical card handling and use (arguably less from receipt to destruction) [0696] The cost of implementing QwyitTalk across any and every platform cannot be matched (free), at the end-points (Consumer smart devices, Merchant POS) and processors (QC.com, QI, QB) [0697] There are no capital investments required by any processors (no new servers, acceleration, bandwidth upgrades, etc.)current equipment can be used and no unique security requirements for transmissions [0698] The minimal transmissions per transaction can't be matched by any system (see Appendix A) [0699] Seamless online addition of QwyitTalk VSU with existing online credit application for QI/QB [0700] Provably secure; independent review and NIST consideration [0701] Removal of the physical card [0702] Eliminates physical card fraud: theft, lost, forgery, etc. [0703] Eliminates associated system cost [0704] Eliminates system complexity (hence vulnerability) [0705] The system completely removes the need for any Merchant to store card numbers: this is one of the largest fraud areas, attacking Merchants and stealing millions of cards. The convenience of having a card on file w/a Merchant is for online credit payment, and paying w/QwyitCash online is less effort than signing in and paying with a stored card. Merchants no longer need/should store Consumer payment info [0706] No security risk at any POS [0707] Merchant QCC is for inputif someone attempts to use the Code instead of the intended Consumer, they will either pay, or the transaction wouldn't complete [0708] Consumer PIN entry only forms the keys in memory during transmission sending/receiving (reading), they are only live for micro-seconds. The PIN is only alive during the transaction and would need to be re-entered for another transaction; it is easily removed by either canceling, quitting the QC app or powering off the device (as well as auto time out after X seconds whether the transaction has completed or not) [0709] All QC participants have a unified, simplified, transaction balance with equal security risk

[0710] PIN Stealth

[0711] QwyitCash has eliminated the security threat of the lost/stolen physical credit card, as a QC-enabled smart device holds only the PIN-secured versions of all keys, AuthTokens and any associated secured data; public, open data such as QI connectivity instructions, OpenIDs, etc. need no protection.

[0712] There is nothing anyone can do without knowing the PINstealing a device and coercing the Consumer to give up the PIN will enable use of the device for illegitimate purchases. This vulnerability will never be removed by any system; but is handled by the same credit protections that currently exist for fraudulent physical card transactions. It should also be noted that halting use of an illegitimate QC device can happen at two different transaction process locations: QC.com (stopping any transactions by invalidating/revoking the QC keys) and the QI (invalidating/revoking the associated AuthToken). Any trouble call into QC will reach both parties.

[0713] The only remaining serious threat to QwyitCash is the cloned device; e.g., malware installed (somehow/anyway) on a device to send the keylogged/mouse-click/screen captured/trapped PIN and then-easily decrypted credentials to an attacker, who will then be able to perform illegitimate (but real) transactions. There are several points to be made in this regard: [0714] The amount of fraud committed this way is miniscule compared to what QwyitCash has stopped in its implementation; and account alerts sent upon any transaction stops this fraud after only a single use. These alerts are commonplace on credit accounts and would be available in QC. [0715] It is a no-sum, forever escalating battle to stop this type of attack [0716] Physically Unclonable Functions (PUFs), and other hardware advances, some existing, others envisioned, are specifically targeted to solving this problem: when QC is a majority of the type of transaction processing, these systems would become more prevalent and the threat eliminated [0717] There are ways to prevent this, using QwyitTalk primitives and existing unique identifiers of any device (IMEI, ICCID, IMSI, MSISDN, etc.)with the assumption that the attack is performed post-initial setup. Butthis requires more user steps and interaction [0718] There are always other dual-channel techniques that stop and/or lessen this vulnerability (2-factor (SMS, email) notification, multi-factor, etc.), yet these also add user steps and some are vulnerable to attack themselves [0719] The end result is that the Risk/Reward scenario of malware-sending QC attacks canand certainly would beseriously addressed if/when it ever rose to the level of a serious problem

[0720] QwyitCash's PIN encryption at initial registration and at every transaction (and after X second timeout):

[0721] Givens: [0722] PIN, 6 digits minimally, 8 ideally, 7 satisfactorilyis randomly created by the QC app at initialization [0723] New PIN can be created at any time by running Setup.fwdarw.New PIN [0724] All AuthTokens, QC.com QwyitTalk communication keys and any other application-related digital information that may be required outside of the QC processes, are stored in a single area/file after PIN encrypted, uniquely identified

[0725] Encryption Process: [0726] PIN is entered/clicked by Consumer [0727] A random 256-bit 64 hexadecimal character salt/IV is created (called the QC Seed, QCS)length equals the QC.com communication key lengths (MQK, MEK) set by the system [0728] The PIN (Offset Key) and QCS (Value Key) are run through the QwyitTalk PDAF, resulting in a 256-bit 64 hex char Seed Key (result length dependent on QCS length, dependent on MQK/MEK length) [0729] The QCS (Offset Key) and Seed Key (Value Key) are run through the QwyitTalk PDAF, resulting in a 256-bit 64 hex char Encryption Key (result length dependent on QCS length, dependent on MQK/MEK length) [0730] The Encryption Key and each to-be-secured value (AuthToken, MQK, MEK) are run through the QwyitTalk MOD16 function, resulting in the PIN-encrypted QC values [0731] Encrypted values are stored as above; the QCS is openly stored

[0732] Decryption Process: [0733] PIN is entered/clicked by Consumer [0734] PIN and QCS in PDAF, resulting in Seed Key (same as encryption) [0735] QCS and Seed Key in PDAF, resulting in Encryption Key (same as encryption) [0736] Encryption Key and PIN-encrypted Key in MOD16D to reveal plaintext Key (token, etc.) The QCS and stored PIN-encrypted values may be changed/updated as per system recommendations (which may be dependent on Consumer device types, usage amounts, etc.). The values are updated whenever a PIN is changed. The open key values are never stored anywhere except temporary memory, and deleted upon every transmission creation and send. This is at most 4 times per transaction (Gift processing, 3 in all others) and takes only a few micro seconds to perform; real time processing without any performance degradation, regardless of Consumer device capabilities.

[0737] The security of this encryption is based on QwyitTalk's underdetermined equation sets; it is unsolvable and therefore unbreakable. And there are only N tries out of the >16,777,216 keys (6 hex-digit PINs minimally) before lockout. It should be noted that it would be sufficient to simply MOD16 add the PIN repeatedly throughout the length of the Keys (a simply PIN offset) without any need for the QCS and the PDAF steps, and the security of the QwyitTalk system would be identical. The only reason for the dual step is on the human-error chance that one of the keys is somehow given out, the others remain secure through the dual one-way PDAFsas there is more than one PIN upon a dictionary attack of the other same-PIN-encrypted values that will yield the now-known key, leaving the others still secure (the chances of guessing the right one are less than the 16.7M original set, but still sufficient to make the effort of somehow stealing a single key not worthwhile. Under this attack, the small size of the PIN is an asset!)

[0738] QwyitCash Summary

[0739] QwyitCash provides more security in a streamlined transaction process than any current deferred net settlement system. The removal of the physical credit card restores the proper risk balance to all participants and performs processing in real time, faster than any current system. QwyitCash relies on QwyitTalk secure authentication and encryption security communications, based on the provably secure mathematics of underdetermined systems of equations, which are maintained everywhere throughout the QwyitCash transaction process.

[0740] Credit Card Processing Comparison to QwyitCash

[0741] FIG. 5 depicts a picture of the transaction processing for approval and settlement of the two major credit card associations, Visa and MasterCard. The QwyitCash processing network is considerably streamlined in comparison, as well as more secure, as the steps below require multiple transmissions. For instance, that single line for the Payment Gateway or Terminal when using EMV smart payment cards has 12 sections, with multiple transmissions per section! That single line is more steps than the entire QwyitCash transmission process!