Abstract:
A secure system and method are disclosed to effectuate financial transactions over a secure internet backbone establishing and using a secure financial proxy account and a pre-registered personal handheld mobile device where all funds within the account remain in an “inactive” non-usable state until activated and allocated only by the registered mobile handheld device.

Description:
SUMMARY OF THE INVENTION 
       [0001]    The invention describes a secure mobile wallet financial transaction system by allowing users (both customers and merchants) to set up a secure financial proxy account, and using registered mobile hand held devices (smartphone, non-smartphone and tablets) that can securely transact payments either using a tablet/mobile hand held device (smart phone) based POS, an automated teller machine (ATM) or an on-line checkout using secure proprietary applications for customers by generating unique user and device specific, single-use, time-sensitive, alpha-numeric digital tokens and the transactional server encrypting these tokens with a customer&#39;s personal public/private encryption key specific to the registered mobile device application; the user is able to activate and allocate a specific amount of funds from his pool of funds. 
         [0002]    The invention describes a user setting up a financial proxy account; a unique registration and authentication process of the user&#39;s mobile handheld device to the financial proxy account, a proprietary unique mobile application downloaded to the registered device, a registered merchant with a secure proprietary POS application on their device or website checkout page, or ATM. Using the consumer&#39;s registered mobile hand held device, a proprietary mobile phone application, a registered merchant&#39;s handheld wireless POS terminal (Tablet-POS) or a stationary wired device (ATM/Kiosk/POS) with the system&#39;s proprietary POS application software capable of recognizing, decoding and validating the user and device specific, single-use, time-sensitive unique encrypted transactional digital token codes from the registered mobile device and the back end transactional server able to decrypt and approve/disapprove the transaction based on the transactional digital token information providing a secure closed loop environment for secure transactional payment processing. The invention also provides for an option to include non-smart phones through the use of a java-based non-smartphone application through a telecommunication data network or SMS and MMS text-messaging protocol. 
         [0003]    Similarly using the same financial-proxy system as described above a Merchant sets up a financial business proxy account providing all necessary personal identifying information and is able to download the financial proxy account system&#39;s point of sale application (POS) to their registered telecommunication hand-held device, or to their website for e-commerce or be able to integrate this into an existing current POS system. 
         [0004]    What is described is a secure mobile based financial proxy system, for both consumers and merchants using their registered handheld devices while at the same time providing the security of a unique closed loop system using proprietary mobile phone and POS applications which recognize the system&#39;s uniquely encrypted, consumer and mobile device specific digital transactional tokens to authenticate and process payment or other type of transactions securely. The system can also be used in an automated teller (ATM) setting and in an online transaction purchase setting obviating the need for an ATM card or the transmission of any personal information into the ATM or during an on-line purchase checkout. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]      FIG. 1  shows the Process Flow of the Secure Financial Proxy Account Set-Up 
           [0006]      FIG. 2  shows the Process Flow of the Using a Smart Phone Mobile Device Application to Allocate Funds 
           [0007]      FIG. 3  shows the Process Flow of how a Merchant Sets Up a Secure Transactional Purchase 
           [0008]      FIG. 4  shows the Transaction Description Flow for the Point Of Sale Using a Barcode Scanner 
           [0009]      FIG. 5  shows the Alternate Transaction Description Flow for the Point Of Sale Using a Camera to Capture or Take a Picture of the Barcode 
           [0010]      FIG. 6  shows the Alternate Transaction Description Flow for the Point Of Sale Using NFC, Optical, Infrared, RFID, etc. 
           [0011]      FIG. 7  illustrates the Process of Forming a Proprietary Encrypted Barcodes Using Private Key/Public Key Authentication 
           [0012]      FIG. 8  shows How to Scan a Proprietary Barcode to Make a Purchase 
       
    
    
     DETAILED DESCRIPTION 
     Step 1 
     Account Set-Up 
       [0013]    As shown in  FIG. 1 , a user establishes a secure proxy financial account with an electronically-based financial-type of institution over a web-based mobile phone or web-based PC. After identifying the mobile phone using either the phone number or machine identifier number, a uniquely specific mobile phone application is sent to the phone through an sms (“Short Message Service”) link. Once the mobile specific link is opened account set up and phone registration takes place; the user provides all necessary personal information including a personal Identification (PIN) number and as an option provides additional personal identifying biometric features using various phone feature modalities (the camera for facial recognition, the microphone for voice spectral analysis and recognition and/or finger print reader device accessory built into some mobile handheld devices). This data is gathered and passed to and stored on the authentication server. Once the data is collected in the same session the mobile handheld device is registered by sending to the mobile device a unique single-use time sensitive authentication code developed by the back-end system and sent to the mobile through a separate channel (sms or voice). The authentication code is required to be entered during the application set up session to complete the account set up and registration process. At completion of the mobile phone registration process an application specific public/private key may also get assigned to the handheld devices account and get uploaded to the mobile phone application to securely complete the account set up and phone registration, in one variant of the invention. 
         [0014]    Using the mobile phone application the user chooses an amount of money and inputs a personal identifier (PIN) through a graphical interface (GUI) and the application can gather other biometric information. In the increased security variant, the Information gets encrypted using the public/private key protocol specific to the mobile application/hand-held device and sends the information as a request to the authentication server. The server side application validates the request by authenticating the hand-held device initially by identifying the hand-held device using the mobile devices phone # (which is NOT encrypted with the Private/Public key) and provides for account look up, The hand-held device&#39;s private key is used to decrypt the remaining authentication information, identifying the unique application Identifier and the user&#39;s personal information (PIN and Biometric data) and the MEIN/Device number. This data is compared to the one-way hashing results obtained during the phone registration and mobile application set up process. Once authenticated the transactional server verifies the requested amount is available and if so the algorithmically generates a user and device specific numeric or alphanumeric encrypted digital token which identifies the mobile device, the user, and the specified requested amount. The user and device specific digital token gets encrypted with the accounts public key and is transmits to the mobile phone device over a secure protocol (SSL) 256-bit encrypted channel. After being received by the specific mobile device the application decrypts the information using the private encryption key to obtain the originally generated digital token. The encrypted digital token is transmitted to the merchant&#39;s point of sale through various modalities as described within by being optically displayed or manually inputted at a proprietary point of sale (POS or ATM) system which facilitates the completion of the intended transaction. 
       Step 2 
     Using a Smart Phone Mobile Device Application to Allocate Funds 
       [0015]    As was described in Step 1 and illustrated in  FIG. 1 , the customer who is seeking to effectuate a secure mobile financial transaction (mobile wallet) opens a secure financial proxy account which may optionally be associated with their main bank accounts or credit/debit card. After providing all personal information (Name, Address, Mobile Country Code, Mobile Number, PIN#, Security Questions) and obtaining biometric information in the way of facial recognition data through front facing mobile device camera, or voice recording data, or fingerprint data to set-up their secure financial proxy account. (Note: Most mobile devices to date are equipped with a front facing camera which may take various facial measurements (as are presently standardized and accepted in the biometric validation industry), providing an additional layer of security utilizing the measurements for a biometric validation application component. These points are captured during set up of the application and stored in the users account. They are passed to the authentication server to be subsequently utilized in conjunction with the pin # (to authenticate the user for a requested transaction.) 
         [0016]    In the same account set-up session the user&#39;s mobile phone is subsequently registered to the account using the telecommunication network by sending the mobile phone a unique authentication code to the mobile number (either by voice channel or a data channel) which is required to be entered by the user during the account set up process session in order to register their mobile device and to successfully complete their account set up process. All the personal account information and security informational data is obtained, except for the mobile country code and mobile number, is stored and encrypted using a one-way hash function by the authentication server. A text message (SMS) containing a link for the system&#39;s mobile phone application is sent to the registered mobile device which allows for the system&#39;s proprietary application to be downloaded to the hand-held device. Once the link is opened the application is downloaded, the application setup process takes place for the specific hand held device obtaining specific authentication data providing the authentication server with the following: a dynamically generated Unique Application Alphanumeric Identification Number (both stored on the application and stored on the authentication server), the user&#39;s PIN# (and other biometric information if available (voice, facial recognition profile), the hand-held device machine equipment number identifier (MEIN# or MEID#) and the unit&#39;s mobile phone number including the mobile country code. Once all this authentication information is obtained by the authentication server a one-way hashing encryption function is utilized on this data (except for the mobile no.) and the results stored on the authentication server in the user&#39;s account. Subsequent to obtaining and storing this information the authentication server application may also create a unique Public/Private Encryption Key for that specific user and their mobile phone application and is both transmitted to the mobile phone application and is stored on the authentication server within the user&#39;s account. This is described in Process Flow in  FIG. 7 . 
         [0017]    As shown in  FIG. 1 , funds can be loaded through various resources (direct deposit, gifting, bank accts etc. . . . ). The funds within the account remain in an ‘inactive or dormant” state. Only the user and the user&#39;s registered mobile hand-held device, after being authenticated can “activate/allocate” a specific amount of funds to be used within a specified given amount of time. 
         [0018]    As shown by  FIG. 2 , a request is sent to the back-end authentication server over 256-bit encryption protocol as follows: Using the mobile phone application the user requests a certain amount of funds to be allocated from the dormant inactive state of funds by selecting the currency and an amount of funds needed and then the user provides their personal identifier information in the way of a PIN and the application obtains additional biometric information. A further embodiment involves using the user&#39;s hand-held device public encryption key (which was assigned and downloaded from the system to the application during application set-up) the following data gets encrypted using the user&#39;s public key: the mobile device (MEIN# or MEID#), the uniquely generated application identifier-UID, and the customer&#39;s personal information (including biometric information obtained). In the enhanced security variant, all the aforementioned data gets encrypted with the user&#39;s public key except for the hand-held device mobile number which is used as a look up identifier gets passed to the authentication server. Authentication of the user and the hand-held device occurs after decrypting the information using the user&#39;s assigned private key obtaining the authentication information and using all or any combination of this information in an authentication protocol on the application server. 
         [0019]    Once the authentication process has been completed, a user and device specific, algorithmically generated time-sensitive, single-use numeric or alphanumeric encrypted digital token is generated as a valued digital token against those specifically requested funds which now become allocated and active for pending use. Using the user&#39;s assigned public/private encryption key the algorithmically generated digital valued token is encrypted with the user&#39;s public key and sent to the specific registered mobile device using the telecommunication network thus activating and allocating the customer&#39;s account for the requested funds as for a potential pending transaction, as explained in  FIG. 8 . Using a secure transport protocol (SSL/TSL-256 bit encryption) the information get passed to the specific mobile hand-held device, and the results may be decrypted using the user&#39;s private encryption key on the mobile application in the enhanced security variant, and are displayed in numeric or alphanumeric terms for manual input and/or as an optical representation such as a barcode or some other optically encoded depiction. 
       Step 3 
     Merchant Sets Up Secure Transactional Purchase 
       [0020]      FIG. 3  illustrates how the Merchant (or Financial Institution) adds its level of security. At a registered Merchant&#39;s POS, ATM or Website checkout containing the system proprietary point of sale application the user&#39;s unique time-sensitive, single-use unique transactional digital token code gets transmitted to the point of sale application using one of several transmitting modalities gets validated for being proprietary and having the correct price; then is passed to the system&#39;s transactional server for processing over ssl/tsl 256-bit encryption protocol. The transactional server verifies the code is active for the specified mobile phone account and processes and confirms the transaction. Once the uniquely encrypted digital transaction (token) code is used, it becomes inactive and useless for any additional transactions and can never be repeated for the user&#39;s specific account. 
         [0021]    The Modes of Transmission can vary. The digital token information from the mobile device is displayed and may be entered manually into the POS application along with the mobile device&#39;s phone number, or be encoded as a barcode image (or other type of optical depiction) and be captured by the POS device using a camera or CCD type device that reads and decodes the bar-code graphic. In Addition in the field of possibilities is wireless automatic transmission, including near field communication (NFC), Bluetooth (BT), and Infrared (IR), Light Transmission protocols, audio frequency transmission or Wi-Fi etc. including further developments in this field. 
       Using a Non-Smart Phone Mobile Application 
       [0022]    Furthermore, even with a Non-smart phone and using a Java-based mobile application, a user can activate their account using encrypted sms, mms, ussd type protocol to obtain the previously above described information in a similar manner described as follows. 
         [0023]    The user opens the java-based mobile application sms function of their registered mobile device. He/she types in the known short code or long-code telephone number for the account financial-like entity that supports and manages the mobile account. The user then sends a request to activate a specified amount of funds from their secure proxy account using their PIN# The request is encrypted with a private/public key encryption and is sent to the authentication server to authenticate the user&#39;s handheld device and the transaction amount request. After verification and authentication an algorithmically generated user and device specific, single-use time-sensitive pseudorandom numeric or alphanumeric encrypted digital token is generated and assigned to user account for the specified amount, gets encrypted using the user&#39;s private/public key and sent over the telecommunication network to the specific phone. The java-based mobile application decrypts the digital valued token so that the user then can manually enter this at either an ATM/or POS into the appropriate fields along with their mobile device number and their personal identifier information. The back-end transactional server then confirms and executes the request processing the described transaction in all the above material. 
       Merchant Sign Up to System 
       [0024]    Using a web-session to sign up and open the account a merchant provides all pertinent information; the Information confirmed using the Business ID using tax ID# or some other type of business identification for verification. During the same session the merchant creates a Username and Password and registers a handheld mobile device (or tablet) to be used as their mobile point of sale (mPOS) and downloads the proprietary point of sale application (POS). Similarly to the customer&#39;s set up the merchant mobile POS application set up provides the authentication server with the MEIN#, a mPOS application unique Identifier number (created from the application), the unit&#39;s telephone number (Tablet or mobile smart-phone) and the Merchant&#39;s Password. 
         [0025]    Once the account set up and registration is completed a Financial Proxy Account is created for the merchant, similar to the customer, to allow payment reconciliation between the merchant&#39;s account and customer&#39;s account using their respective registered mobile handsets. 
       Step 4 
     Transaction Description Flow—Point of Sale 
       [0026]    A registered user requests and specific amount and activates the funds their account using their registered mobile phone application. After being authenticated the user receives a unique time-sensitive, single-use, encrypted digital token code to their device. The merchant opens their registered POS application on the device and is also authenticated using a similar authentication protocol. As shown in  FIGS. 4 and 5 , using the device (and application) the merchant can scan ( 4   a ) or takes a picture ( 4   b ) of the digital token being depicted as a barcode which decodes the barcode representation of the token. Alternatively, as in  FIG. 5 , the user&#39;s digital token information can be passed using NFC, an audio wave form, or light medium to transfer the information directly to the POS ( 4   c ). The POS application validates the digital token information confirming it is proprietary prior to sending the information to the transactional server for processing. The transaction server verifies the digital token is proprietary to the system&#39;s application authentic using the user&#39;s Public/Private key encryption, verifies the digital token code is active in the system for the specified amount confirming or disapproving the transaction. 
         [0027]    Upon approval of the transaction real time reconciliation of the account takes place debiting the user&#39;s proxy financial account and crediting the merchant&#39;s proxy financial account. The monies do not leave the system remaining in the pooled financial proxy account at all and securely stay within the original financial entity. 
       Transaction Description Flow 
     Automated Teller Machine or Financial Institution 
       [0028]    A registered user activates their account using their mobile phone and after being authenticated receives a user and device specific, unique time-sensitive, single-use encrypted digital token to their device. The user selects the system&#39;s ATM application to receive money. Using manual input or the ATM built-in camera device, (and application) scans or takes a picture from the user&#39;s mobile phone screen and decodes the barcode representation of the encrypted digital token, as shown in  FIG. 5 . Alternatively, the user can use NFC or other modalities to transfer the digital token information as shown in  FIG. 6 . Similar to the “Transactional Description Flow for the POS above, the ATM application validates the information confirming it is from a registered user&#39;s mobile device application prior to sending the information to the transactional server for processing. The transactional server verifies the active encrypted digital token code for the specified amount and sends approval to ATM to dispense correct amount. Funds get transferred to ATM owner&#39;s main bank account on file or credited to the ATM owner&#39;s financial proxy account within the system. 
       Step 4 
     An Alternative Secure Transaction 
       [0029]    As shown in  FIG. 4 , Retail merchants that sign up to the system are able to provide information regarding their product including description, price, reserve price, volume, colors and website address to the system&#39;s web services. The web service creates a unique barcode for the aforementioned information which will allow for direct purchase and a secure transaction by a user scanning the barcode information using the registered mobile device application. The merchant is able to display the barcode in advertisements (e-media, online, print media etc. . . . ). The user can open the mobile application enter their required authentication information and scan the barcode. The barcode information and the authentication information get passed back to the authentication and transaction server to authenticate the user. This Process Flow is shown in  FIG. 8 . Once the user is authenticated, in the same session using the website address the product description along with a picture and a purchase option is offered to the user using the mobile application. Once the purchase option is selected a unique user and device specific, time-sensitive, digital token is generated for the amount and allocated from the dormant funds from the user&#39;s secure proxy account and is sent to the merchant&#39;s secure proxy account for purchase. A receipt is generated and sent to the user phone and account confirming the purchased item and is delivered to the user using the address on file. 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Creation of a Unique User and Device Specific, Time-Sensitive, Single- 
               
               
                 Use Encrypted Digital Token Used for Purchase Transactions 
               
               
                 Generate a Random Number Seed: 5423687225 
               
             
          
           
               
                 Authentication Info 
                 Number 
                 Number (Mod8 + 2) 
               
               
                   
               
               
                 1) Mobile # 
                 444-555-2222 
                 6667774444 
               
               
                 2) Mobile Equip # 
                 4444222255 
                 6666444477 
               
               
                 3) Application ID # 
                 5555333366 
                 7777555588 
               
               
                 4) Random # Seed (above) 
                 5423687225 
                 7645829447 
               
               
                 5) User&#39;s PIN # 
                 5246669541 
                 7468883763 
               
               
                   
               
               
                 Algorithm 
               
               
                 1) Calculate exponent component 
               
               
                 Use the Last Column and Add Each Number in Their Respective Column to be used as exponents: Ex: (6 + 6 + 7 + 7 + 7) = 33 Ex: (6 + 6 + 7 + 6 + 4) = 29 Ex: (6 + 6 + 7 + 4 + 6) = 29 Ex: (7 + 6 + 7 + 5 + 8) = 33 etc . . . 
               
               
                 2) Calculate Base Component 
               
               
                 Use the random number results from the mod 8 + 2 function as the bases (7645829447) 
               
               
                 Example: (base from step 2){circumflex over ( )}(exponent from step #1) 
               
               
                 7{circumflex over ( )} 33 , 6{circumflex over ( )} 29 , 4{circumflex over ( )} 29 , 5{circumflex over ( )} 33  . . . using all bases from step 2 to obtain 10 groups of numbers. Select 2 numbers from each group to obtain a 20 digitally unique random number which is to be used as the uniquely generated WiGime transactional code. 
               
               
                 Example: 45866932145698756321→ this token gets one -way Hashed and stored in database under mobile account #: 0001-444-555-2222 
               
               
                 The Country Code + Mobile Number + the Un-Hashed token gets encrypted using the user&#39;s assigned WiGime&#39;s Public key/Pvt Key 
               
               
                 Example: 0001- 4445552222-45866932145698756321→ Apply User&#39;s Public Key 
               
               
                 Encrypted Token result gets sent to specific mobile device gets decrypted by the user&#39;s assigned WiGime Private encryption key and gets depicted on the mobile hand set device as a Barcode or gets passed to mobile handset as digital information to be transferred to a WiGime&#39;s Point of Sale Application (POS) 
               
             
          
         
       
     
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 2 
               
             
             
               
                   
               
               
                 Database Storage of Account Information and Private/Public 
               
               
                 Key Encryption of the Encrypted Digital Token 
               
             
          
           
               
                 Authentication 
                   
                 One- Way 
                 Con- 
               
               
                 Info 
                 Number 
                 Hashed (Database) 
                 firmed 
               
               
                   
               
               
                 1) CC+ Mobile # 
                 0001+444-555-2222 
                 6667774444 
                 yes/no 
               
               
                 2) Mobile Equip # 
                 4444222255 
                 6666444477 
                 yes/no 
               
               
                 3) Application ID # 
                 5555333366 
                 7777555588 
                 yes/no 
               
               
                 4) User&#39;s PIN # 
                 5246669541 
                 7468883763 
                 yes/no 
               
               
                   
               
               
                 The second column (“Number”) Steps 2-4 get encrypted using the User&#39;s assigned WiGime Public Key 
               
               
                 Step #1 gets passed also to authentication server for account look up 
               
               
                 Each step above needs to be confirmed for authentication to be processed 
               
               
                 When all steps are confirmed a Random number generator is used to create a 20 digit random number to be used as the digital token against the requested funds from the account 
               
               
                 Example: 45866932145698756321→ this token gets one -way Hashed and stored in database under mobile account #: 0001-444-555-2222 
               
               
                 The Country Code + Mobile Number + the Un-Hashed token gets encrypted using a user&#39;s WiGime Public key/Pvt Key 
               
               
                 Example: 0001- 4445552222-45866932145698756321→ Apply Public Key 
               
               
                 Encrypted Token result gets sent to handset, decrypted using the device&#39;s Pvt key and gets depicted onto the mobile hand set device as a Barcode or gets passed to mobile handset as digital information to be transferred to WiGime&#39;s Point of Sale Application (POS) 
               
             
          
         
       
     
         [0000]    
       
         
               
             
               
             
           
               
                 TABLE 3 
               
               
                   
               
               
                 User Authentication from a Registered 
               
               
                 Mobile Phone and Mobile Application 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 WiGime Account creation and mobile application set up allows the system 
               
               
                 to obtain uniquely identifiable information for identifying and 
               
               
                 authenticating: 1) The User, 2) The Hand Set and 3) The Mobile 
               
               
                 Application when being authenticated for an encrypted WiGime digital 
               
               
                 token against requested funds from the user&#39;s account. The following 
               
               
                 information is obtained during mobile application set up: 
               
               
                 1) Country Code + Mobile Cell Phone #--&gt; Passed to server and 
               
               
                 stored in the database for the mobile account and hand set device 
               
               
                 2) Mobile Equipment ID# → passed to server and one-way hashed in 
               
               
                 the database for the mobile account and hand set device 
               
               
                 3) Unique Application ID (generated during set up) → Passed to server 
               
               
                 and one-way Hashed in the database for the mobile account and hand set 
               
               
                 device 
               
               
                 4) Personal Identification Number (PIN#)→ Passed to authentication 
               
               
                 server and one-way hashed for the mobile hand set device 
               
               
                 Steps 2 through 4 get encrypted on the mobile application using the 
               
               
                 user&#39;s assigned WiGime Public encryption key 
               
               
                 Step 1 can remain un-encrypted OR optionally can be encrypted with the 
               
               
                 Company&#39;s Public Encryption Key. 
               
               
                   
               
             
          
         
       
     
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 4 
               
             
             
               
                   
               
               
                 Authentication of User/Handheld Device to Request Activation 
               
               
                 and Allocation of Funds from User&#39;s Financial Proxy 
               
               
                 Account on Authentication and Transactional Server 
               
             
          
           
               
                   
                   
                 One- Way 
                   
               
               
                 Authentication Info 
                 Number 
                 Hashed Data 
                 Confirmed 
               
               
                   
               
               
                 1) CC+ Mobile # 
                 CC+444-555-2222 
                 NOT Hashed 
                 yes/no 
               
               
                 2) Mobile Equip # 
                 4444222255 
                 6666444477 
                 yes/no 
               
               
                 3) Application ID # 
                 5555333366 
                 7777555588 
                 yes/no 
               
               
                 4) User&#39;s PIN # 
                 5246669541 
                 7468883763 
                 yes/no 
               
               
                   
               
               
                 When an encrypted digital token is requested for specific amount of funds the information above gets passed from the mobile hand set device using the registered mobile application and sent to the authentication server (steps 2-4)encrypted using the user&#39;s assigned WiGime PUBLIC Key from a Public/Pvt encryption key (residing on the user&#39;s mobile device) and sent over to authentication server using (SSL). After the mobile account is looked up using the Country Code and Mobile number, the information is decrypted using the user&#39;s assigned WiGime PVT KEY, the information compared to the hashed account authentication information. Each step above needs to be confirmed for authentication to be approved 
               
               
                 When all steps are confirmed authentication process is complete and the transactional server creates a pseudorandom digital token on behalf of the user and device for the requested amount as described previously.