WO2012111019A1

WO2012111019A1 - Automated mobile transaction processing system and method

Info

Publication number: WO2012111019A1
Application number: PCT/IN2011/000490
Authority: WO
Inventors: Ravi Jagannathan
Original assignee: Ravi Jagannathan
Priority date: 2011-02-14
Filing date: 2011-07-25
Publication date: 2012-08-23

Abstract

An automated mobile transaction processing system and method. A transaction initialization unit having a client application generates a two-dimensional (2D) barcode including at least one data parameter such as, a MAC data, a Payer input, an auto invoke string and other details with respect to a Payer. A transaction request processing unit having an optical image capturing unit captures and retrieves the data parameters of the 2D barcode in order to auto invoke a payee application on the transaction request processing unit. A transaction server configured with a transaction processing application further receives a payment request from the payee application along with the data parameters of the Payer via a wireless network in order to verify and confirm the transaction between the Payer and Payee within a business environment. The system and method therefore provides a secured, user-friendly, and cost effective 2D barcode based payment mechanism within a wide range of business applications.

Description

AUTOMATED MOBILE TRANSACTION PROCESSING SYSTEM AND METHOD

TECHNICAL FIELD

[0001] Embodiments are generally related to electronic transaction processing systems and methods. Embodiments are also related to mobile communication devices. Embodiments are additionally related to two-dimensional (2D) barcode based transaction mechanism.

BACKGROUND OF THE INVENTION

[0002] Mobile communication devices such as, PDA's (Personnel Digital Assistance), Smart phones (Symbian, Android, IPHONE etc) are becoming ubiquitous and are also rapidly becoming more powerful and functional. Many users carry their mobile phones more frequently and to more places than their wallets or car keys. Because mobile phones are becoming an inseparable part of daily life, there is an increasing interest in expanding the functionality of mobile phones beyond just phone calls. For example, there is some interest in enabling mobile phones to make payments or to facilitate other types of transactions.

[0003] It is however unlike cash transactions where complete anonymity of the Payer and Payee is maintained, all non-cash payments (including mobile payment) require some exchange of information from the Payer to Payee or vice-versa for the completion of the transaction. In the simplest of cases such as a Credit Card, the Payer has to provide either the physical card/ card number. Similarly, most prior art mobile transaction applications over a network (e.g., internet) requires the phone number/account number of the recipient/sender. Such prior art mechanisms leads to significant risk since certain important personal information has to be shared with unknown entities/strangers and a sufficient amount of underlying trust has to be present. [0004] In addition, some prior art transaction applications employ a Magnetic Stripe for secured transaction which can be prone to user information thefts. The Magnetic Stripe is widely prevalent, the key disadvantage of this transaction mode is that the data contained in it can be easily extracted by any reader and the magnetic stripe data is easy to reproduce/clone. A NFC and/or a Smart Card can be adapted to provide secure transaction by protecting users from information thefts in the network. It is however, the NFC and Smart Card based transaction applications require high level of hardware dependence and replacement.

[C005] A mobile transaction processing system can be employed in such transaction environments in order to provide a secure barcode (e.g., quick response (QR) code) based payment mechanism. Such systems generally include a Transaction server for generating and transmitting the barcode with respect to the Payer (e.g., a customer). The Payer further transmits the barcode and other Payer information (i.e., exchange of information in clear text) to the Payee (e.g., a merchant) in order to confirm the payment. Generation and transmission of the barcode at the server end can be cost consuming, cumbersome and insecure. Furthermore, the performance of such prior art mechanisms are highly affected by the speed and traffic of the network.

[0006] Based on the foregoing, it is believed that a need exists for an improved automated mobile transaction processing system and method. A need also exists for an improved mechanism for generating a two-dimensional (2D) barcode on the Payer mobile device, as described in greater detail herein.

BRIEF SUMMARY

[0007] The following summary is provided to facilitate an understanding of some of the innovative features unique to the disclosed embodiment and is not intended to be a full description. A full appreciation of the various aspects of the embodiments disclosed herein can be gained by taking the entire specification, claims, drawings, and abstract as a whole.

[0008] It is, therefore, one aspect of the disclosed embodiments to provide for an improved automated mobile transaction processing system and method.

[0009] It is another aspect of the disclosed embodiments to provide for an improved two-dimensional (2D) barcode based payment mechanism.

[0010] It is further aspect of the disclosed embodiments to provide for an improved method for generating the two-dimensional (2D) barcode on a Payer mobile device.

[0011] The aforementioned aspects and other objectives and advantages can now be achieved as described herein. An automated mobile transaction processing system and method is disclosed herein. A Transaction Initialization Device (TID) unit (e.g., a Payer mobile device) having a Payer application generates a two-dimensional (2D) barcode (QR code) including at least one data parameter such as, a MAC generated using the MAC Key, a Payer input, an auto invoke string and other details with respect to a Payer. A Transaction Request Processing Device (TRD) unit (e.g., a Payee mobile device) having an optical image capturing unit (e.g., a digital camera) captures and retrieves the data parameters of the 2D barcode in order to auto invoke a Payee application. The Transaction Request Processing Device (TRD) unit sets of MAC key and ENC key for -generating the transaction request data utilizing the Payer data parameters in the barcode. A Transaction server configured with a transaction processing application further receives the transaction request data from the Payee application along with the data parameters of the Payer via a wireless network (e.g., a GPRS or SMS connection) in order to verify and confirm the transaction between the Payer and Payee within a business environment. The system and method therefore provides a secured, user-friendly, and cost effective 2D barcode based payment mechanism within a wide range of business applications.

[0012] The Transaction server and the Transaction Initialization Device unit perform a key derivation algorithm process in which the Transaction server and the Transaction Initialization Device unit generate a set of ENC Key and MAC Key. The same process is carried on between the Transaction server and the Transaction Request Processing Device unit. In the transaction life cycle the keys generated are utilized for authenticating the data between the components unit involved in the transaction flow. The keys are not derived solely by the Transaction server but there exists a key generation agreement protocol and hence the security level is higher. The 2D barcode generated on the transaction initialization device unit includes encrypted Payer information such as, Payer phone number, random number, unique counter and the Payer input (total transaction amount), the MAC data, the auto invoke string and other details.

[0013] The MAC data prevents tampering of the Payer information and re-creation of the Payer information by other devices within the network. The Transaction Request Processing Device unit retrieves the Payer input (amount transacted) and displays in order to receive a confirmation from the Payee for transaction processing. The Transaction Request Processing Device unit further encrypts the Payee mobile number/unique identification data, random number, amount encrypted Payer information, Payer MAC data and generates the Payee MAC data in order to transmit to the Transaction server. The Transaction server decodes and independently performs authentication and validation of the Payee and Payer encoded information in order to approve/reject the transaction request processing. [0014] The transaction processing system provides a real time fund transfer between the Payer and Payee accounts in the Transaction server. The Transaction server transmits a confirmation message with updated balance information to both Payer and Payee. The updated balance and other information can be transmitted to the Payer through a secured SMS channel. Similarly, the updated balance and other information can be transmitted to the Payee via a HTTP or Secured SMS channel. The Payer application and Payee application effectively permits the Payer and Payee to view account balance, transaction history and request for re-charge of the accounts respectively. The system typically adapts a dual layer secured storage medium for storing the RSA private keys and the AES keys (User PIN & encipherment of token file via a unique symmetric application key). The system also binds of the keys within in the Payer and Payee devices and encodes Payer and Payee information using the AES keys in order to generate a unique barcode containing the encoded information.

[0015] The system encrypts the user data (Payee and Payer) into multiple layer of encryption and provides an authentic validation with respect to the barcode upon scanning via a server ID. The Transaction server includes a unique process for decoding the multiple layers of encryption (to decode the Payee information first and then the Payer information), validating duplicate and out of sequence Payer information, real time management of Payer and Payee account information. The system and method described herein therefore provides a mechanism for the Payer to make payment to the Payee without the need for divulging/receiving personal information (such as Mobile Number, account number or name or ID) between the parties. The system by generating the barcode within the Transaction Initialization Device unit effectively solves the network traffic and network theft issues within the transaction network environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying figures, in which like reference numerals refer to identical or functionally-similar elements throughout the separate views and which are incorporated in and form a part of the specification, further illustrate the present invention and, together with the detailed description of the invention, serve to explain the principles of the present invention.

[0017] FIG. 1 illustrates a graphical representation of an automated mobile transaction processing system, in accordance with the disclosed embodiments;

[0018] FIG. 2 illustrates a block diagram illustrating the transaction flow in the automated mobile transaction system, in accordance with the disclosed embodiments;

[0019] FIG. 3 illustrates a block diagram of the automated mobile transaction system, in accordance with the disclosed embodiments;

[0020] FIG. 4 illustrates a functional process flow diagram of the automated mobile transaction system, in accordance with the disclosed embodiments;

[0021] FIG. 5 illustrates a work flow diagram illustrating the transaction process in the mobile transaction processing system, in accordance with the disclosed embodiments;

[0022] FIG. 6 illustrates a work flow diagram illustrating the transaction process between a Payee and payment platform, in accordance with the disclosed embodiments; and [0023] FIG. 7 illustrates a high level flow chart of operation illustrating logical operation steps of a method for processing a transaction between the Payer and the Payee within a business environment, in accordance with the disclosed embodiments.

DETAILED DESCRIPTION

[0024] The particular values and configurations discussed in these non-limiting examples can be varied and are cited merely to illustrate at least one embodiment and are not intended to limit the scope thereof.

[0025] The embodiments now will be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments of the invention are shown. The embodiments disclosed herein can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Also, the AES Enc and AES MAC keys can be referred to any Symmetric keys which use the AES algorithm.

[0027] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0028] FIG. 1 illustrates a graphical representation of an automated mobile transaction processing system 100, in accordance with the disclosed embodiments. The automated mobile transaction processing system 100 effectively provides mobile transactions with respect to a Payer (e.g., a customer) 110 and a Payee (e.g., a merchant) 140 within a business environment. The system 100 generally includes a Transaction server 160, a Transaction Initialization Device unit 120 and a Transaction Request Processing Device unit 150 that are operatively configured in association with a network (e.g., an internet, Telecom Operator Network) 130. Note that the Transaction Initialization Device unit 120 can be a Payer mobile device and the Transaction Request Processing Device unit 150 can be a Payee mobile device, in accordance with the design considerations.

[0029] The Transaction Initialization Device unit 120 having a Payer application 314 generates a two-dimensional (2D) barcode 165 including at least one data parameter such as, a MAC data, a Payer input, an auto invoke string and other details with respect to the Payer 110. The RSA keys are generated and stored into the Payer application 314 and Payee application 338 respectively and the session keys are created between the Transaction Initialization Device unit 20/Transaction Request Processing Device unit 150 and Transaction server 160 in the network 130. Note that the two-dimensional barcode 165 can be a quick response code. The 2D barcode 165 can be extremely powerful data capture and display tool well suited for the Payer mobile device 120. The 2D barcode 165 holds high capacity of characters in order to guarantee the interoperability within the network 130.

[0030] The barcode 165 can be generated on runtime in order to meet the dynamic data input in the Transaction Initialization Device unit 120. The barcode 165 can be unique for different data element in order to securely transmit the data elements in an optical channel without any network dependency. The barcode 165 can generally include a hyperlink to auto-invoke the Payee application 383, a clear text to allow information to be read by the Payee application 383, encrypted information which can be decrypted by the Transaction server, and MAC used for authentication of the transmitted data.

[0031] The Transaction Request Processing Device unit 150 captures and retrieves the data parameters of the 2D barcode in order to auto invoke a Payee application 338. The Transaction Request Processing Device (TRD) unit 150 sets of the MAC key and the ENC key for generating the transaction request data utilizing the Payer data parameters in the barcode 165. The Transaction server 160 further receives a payment request from the Payee 140 along with the data parameters of the Payer 110 via a wireless network 180. Note that the wireless network 180 can be such as, for example, but not limited to a GPRS or SMS connection. The Transaction server 160 further verifies and confirms the transaction between the Payer 110 and Payee 140 within a business environment. The system 100 therefore provides a secured, user-friendly, and cost effective 2D barcode based payment mechanism within a wide range of business applications.

[0032] FIG. 2 illustrates a block diagram 200 illustrating the transaction flow in the automated mobile transaction system 100, in accordance with the disclosed embodiments. Note that in FIGS. 1 -7, identical or similar blocks are generally indicated by identical reference numerals. The Transaction server 160 and the Transaction Initialization Device unit 120 perform a key derivation algorithm process in which the Transaction server 160 and the Transaction Initialization Device unit 120 generate a set of ENC Key and MAC Key. The same process is carried on between the Transaction server 160 and the Transaction Request Processing Device unit 150. In the transaction life cycle, the keys can be utilized for authenticating the data between the components unit involved in the transaction flow. The keys are not derived solely by the Transaction server 160 but there exists a key generation agreement protocol in order to enhance the security level in the transaction processing system 100. Note that the RSA asymmetric keys are utilized for creating a trust between the transaction initialization unit 120, the transaction request processing unit 150 and the, transaction server 160 within the network 130. The AES keys (encryption and MAC) are utilized for securely encoding and decoding information in the devices. The AES keys are utilized for ascertaining the identity and authenticity of the data sent by the mobile devices 120 and 150.

[0033] The 2D barcode 165 generated on the Transaction Initialization Device unit 120 includes encrypted Payer information such as, Payer phone number/Unique Identification, random number, unique counter and the Payer input (total transaction amount), the MAC data, the auto invoke string and other details. The generated 2D barcode 165 in the Transaction Initialization Device unit 120 is transmitted to the Transaction Request Processing Device unit 50 via the optical channel 210. The MAC data prevents tampering of the Payer information and re-creation of the Payer information by other devices within the network 30.

[0034] The TDP SP Manager 340 on the Transaction Request Processing Device unit 150 retrieves the Payer input data (such as amount) and displays using the Ul & Display Manager 336 in order to get the confirmation from the Payee 140 for processing the transaction request. The Transaction Request Processing Device unit 150 further encrypts the Payee mobile number/Unique Identification, random number, Amount, encrypted Payer information, Payer MAC data in order to transmit to the Transaction server 160. Note that the Transaction Request Processing Device unit 150 transmits the payment request via the HTTP TCP/IP or SMS channel 220. The Transaction server 160 decodes and independently performs authentication and validation of the Payee 140 and Payer 110 encoded information in order to approve/reject the transaction request processing.

[0035] The Transaction server 160 verifies the MAC of the encrypted data using the Payee's MAC key and decrypts the encrypted data using the Payee's encryption key. The decrypted data contains the amount information and the Payer's encrypted and MAC data. The Transaction server 160 also verifies the MAC of the payer using the payer's MAC key and decrypts the payer's encrypted data using the payer's encryption key. The Transaction server 160 further extracts, the Payer generated information and verifies the out of sequence status of the counter and compares the amount encoded in the Payee's encryption data and the Payer's encryption data.

[0036] The Transaction server 160 also performs the transaction feasibility check and generates unique transaction ID and updates the database 356 with the Payee and Payer information with the parameters, if the transaction is feasible, the server 160 sends authorization request message to the Transaction Request Processing Device unit 150 along with the transaction ID and amount requested information. The Transaction Request Processing Device unit 150 decodes and displays the message to the Payee 140. On Payee confirmation, the Payee application 338 sends a commit request message to the Transaction server 160. The commit request message includes encryption and MAC of the transaction ID along with the commit code.

[0037] The Transaction server 160 verifies the feasibility of the transaction on receiving the commit request from the Transaction Request Processing Device unit 50 in order to commit the transaction and update the balances of the Payee 140 and Payer 10 in real time. The Transaction server 160 also responds to the Transaction Request Processing Device unit 150 with the final transaction summary along with the updated balance of the Payee 140, the transaction id and time of transaction. Such information can be further stored into the transaction log of the transaction processing application 160. The Transaction server 160 also transmits the transaction summary to the transaction initialization unit 120 with respect to the committed transaction in the Transaction server 160. The updated balance and other information with respect to the Payer can be transmitted via a secured SMS channel 230. Similarly, the updated balance and other information with respect to the Payee can be transmitted to the via a HTTP or Secured SMS channel 220. The transaction summary includes the counter, random and the transacted amount and updated balance of the payer 1 10. The STRDVS 308 verifies the response for transaction and updates the balance information in the application and displays the summary to the payer 1 10. [0038] The transaction processing system 100 provides a real time fund transfer between the Payer 110 and Payee 140 in the transaction server 160. The transaction server 160 transmits a confirmation message with updated balance information to both Payer 110 and the Payee 140 via a secured SMS. The payer application 314 and the payee application 338 effectively permits Payer 110 and Payee 140 to view account balance, transaction history and request for re-charge of the accounts respectively. The system 100 typically adapts a dual layer secured storage medium for storing the RSA private keys and the AES keys (User PIN & encipherment of token file via a unique symmetric application key). The system 100 also binds of the keys within in the Payer and Payee devices 120 and 140 and encodes Payer and Payee information using the AES keys in order to generate a unique barcode containing the encoded information. The system 100 encrypts the user data (Payee and Payer) into multiple layer of encryption and provides an authentic validation with respect to the barcode 165 upon scanning via a server ID. The transaction server 160 includes a unique process for decoding the multiple layers of encryption (to decode the payee information first and then the payer information), validating duplicate and out of sequence payer information, real time management of payer and payee account information.

[0039] FIG. 3 illustrates a block diagram 300 of the automated mobile transaction processing system 100, in accordance with the disclosed embodiments. The Transaction Initialization Device unit 120 includes an optical code generation system (OCDS) 304, an user interface (Ul) and display module 302, a secure transaction authorization data generation system (STADGS) 306, a secure transaction authorization data verification system (STRDVS) 308, a transaction logging manager 310, a transaction TPD SP manger 312 and the payer application 314. Note thai the payer application 314 described herein can be a Payer-side core midlet engine. The OCDS 304 converts transaction initialization data generated by the STADGS 306 to a displayable data in the user interface (Ul) and display module 302 of the Transaction Initialization Device unit 120. The TPD SP manager 312 manages the installation and configuration in the Transaction Initialization Device unit 120 of the various TPD's which can be the part of the transaction ecosystem based on the business application framework.

[0040] Note that the term configuration and installation described herein can be a predefined behavior and optional parameter which can be required by STADGS 306 before generating the transaction authorization data. The transaction logging module 310 enables logging of all the transactions performed with the Transaction Request Processing Device unit 150 either successfully or unsuccessfully. The STRDVS 308 can be a secure transaction response data validation system which is responsible for validating the transaction response received from the Payer 110 by validating the parameters generated in the Transaction Initialization Device unit 120.

[0041] The transaction TPD SP manager 312 defines the processing of the STADGS 306 and STRDVS 308. The user interface (Ul) and display manger 302 of the Transaction Initialization Device unit 120 enables the Payer 110 to interactively navigate the process menus, TPD activation and management menus for viewing the transaction logs in a user friendly manner. The Transaction Request Processing Device unit 150 of the payment system 100 includes a barcode scanning module 316, an integrated digital camera 322, a web browser 326, and a device operating system 320. The Transaction Request Processing Device unit 150 also includes a web server module 324, a STRDGS 328, a STRDVS 334, a HTTP connection manager 332, a user interface and display manger 336, a transaction logging manager 330, a transaction TPD SP manager 340, the payee application 338. Note that the Payee application 338 can be a payee-side core midlet engine. The Transaction Request Processing Device unit 150 typically represents a TRD system running on the system which is registered to the SMS services and GPRS services with the cellular service network provider. The Transaction Request Processing Device unit 150 further supports the mid let application installation. The operations of the Transaction Request Processing Device unit 150 can be defined into a global server manger 348 of the Transaction server 160.

[0042] The barcode scanning module 316 of the Transaction Request Processing Device unit 150 can be a standalone application and is not part of the core service provider application. The barcode scanning module 316 can be a 2D barcode scanner application which runs on the operating system 320 of the Transaction Request Processing Device unit 150. The barcode scanning module 316 continuously scans in its proximity for a barcode displayed by the Transaction Initialization Device unit 120 via the integrated camera 322. The Payee application 338 is an enhanced version to provide additional features of Transaction Request Processing Device unit 150. The Payee application 338 is utilized for performing secure messaging processing. The STRDGS 328 is used for generation of transaction data request from the Transaction Request Processing Device unit 150 to the Transaction processing server 160. The STRDGS 328 is invoked by the web server module 324 of the Transaction Request Processing Device unit 50 in order to perform the required operation. The STRDGS 328 is invoked by STRDVS 334 in the partial leg of transaction lifecycle. The STRDVS 334 is also responsible to validate the transaction response received from the Transaction server 160.

[0043] The web server module 324 is a socket server application component which listens for an incoming socket connection. The web server module 324 is typically configured to run on a pre decided port on the local iP address in the operating system 320 of the Transaction Request Processing Device unit 150. In the design context of transaction flow, the web server module 324 gets socket connection request from the web browser 326. The OCDS 304 generates a string using the static URL on receiving the transaction authorization data from the STADGS 328. The generated string is further transmitted to the barcode generator in order to create a barcode image on the user interface of the transaction initialization unit 120. The Payer 110 further displays the generated barcode 165 to the proximity device ready to scan the barcode 65. The barcode scanning module automatically scans the barcode and decodes the string encoded by the OCDS in order to detect the string is the URL.

[0044] The Transaction Request Processing Device unit 150 extracts the HTTP URL that is decoded from the barcode 165 generated by the OCDS 304 of the Transaction Initialization Device unit 120. The Transaction Request Processing Device 150 extracts the URL and makes a native call to the operating system 320 for invocation of the decoded URL. The operating system 320 in turn calls web browser to fetch the URL. The web browser 326 detects the local device IP address which is (127.0.0.1 - Loop Back Address) of URL in order to interface the transaction request processing unit 150. The mobile web browser 326 initiates the call to the URL in order to transmit the data from the Transaction Request Processing Device unit 150 to the web server module 324 of the Transaction server 160. The web server module 324 further receives and transmits the data from the mobile web browser 326 to the STRDGS 328 for further processing in order to invoke the TPD SP manager 340.

[0045] The transaction TPD SP manager 340 further generates a summary of the transaction request parameters with respect to the transaction processor by encoding the data part in the URL. The transaction processing server 160 can be responsible for actually performing the transaction between the transaction initialization unit 120 and the transaction request processing unit 150. The transaction server 160 interfaces with a modem and HTTP gateway. The transaction processing server 160 generally includes a user manager 342, an admin manager 350, a transaction manager 344, a HTTP connection manager 352, a STDGV3 346, a service provider manager 354, a global server manager 348, a database 356, and a host to host connection manager 358. The user manager 342 provides an interface for the transaction initialization unit 120 and the transaction request processing unit 150 in order to manage the relationship with the transaction processing server 160.

[0046] The transaction processing server 160 also provides other features, such as, viewing the transaction logs, report generation, etc. The admin manager 350 facilitates the admin of the transaction processing server 160 to manage users, add or deactivate users, configure services parameters, report generation, configuration of networks like SMS and HTTP gateways, etc. The admin manager 350 also permits admin to create connection configuration between transaction processing server 160 and other host and global servers. The HTTP connection manager 352 requests listener and response dispatcher module using the HTTP gateway. The HTTP connection manager 352 listens for transaction request messages from the HTTP manager 352 in the transaction request processing unit 150. The service provider manager 354 maintains the processing and configuration of the services which can be enrolled from the global server manager 348. The service provider manager 354 also sends/receives the activation messages to the transaction identification unit 260 and the transaction request processing unit 240. The host to host connection manager 358 provides an interface between the transaction processing server 160 and other transaction servers in the network 130.

[0047] Note that the invention generally provides a secure transaction framework between any two devices (say Payer device and Payee device) where in the third device (say transaction server) is acting as the aggregator of the transactions and also the common binding factor between the two devices which are willing to do the transaction. As discussed above, the first step will to bind the transaction initialization unit 120 and the transaction request processing unit 150 with the transaction processing server 160, which is referred as activation of transaction processing server services in the transaction initialization unit 120 and the transaction request processing unit 150.

[0048] FIG. 4 illustrates an exemplary functional process flow diagram 400 of the mobile payment system 100, in accordance with the disclosed embodiments. The embodiments discussed herein generally relate to a mobile payment system 100 in context of a banking application, as illustrated in FIGS. 4-6. It can be appreciated, however, that such embodiments can be implemented in the context of other transaction systems and designs, and are not limited to the banking systems. The discussion of the banking system, as utilized herein, is presented for general illustrative purposes only.

[0049] A mobile wallet account would be set-up and created by a payment platform provider such as a bank 410 in the Transaction server 160 for both the customers and merchants. The Payer/customer 110 registers and downloads the application to the Transaction Initialization Device unit 120. The balance in the mobile wallet account can be loaded either by transfer of funds from a .bank account 420 or by cash payment. The payee/merchant 140 similarly registers and downloads the application on the transaction request processing unit 150. Note that the transaction request processing unit 150 should essentially include the image capturing unit 322 and the barcode scanning module 316, as described in FIG. 3. The Transaction Processing Server 160 would map the Payer bank account 420 with the Mobile Wallet of the Payer 110. The Transaction server 160 performs recharge function, and batch settlement functions with respect to the banking system 410 by means of using this mapped information between the Mobile Wallet Accounts and the Banking accounts of the Payer and Payee.

[0050] FIG. 5 illustrates a work flow diagram 500 illustrating the transaction process in the mobile payment system 100, in accordance with the disclosed embodiments. Again as a reminder note that in FIGS. 1 -7, identical or similar blocks are generally indicated by identical reference numerals. The Payer 110 initiates the transaction process on making a purchase by initializing the transaction and creating the barcode 165 based on the purchase details, as illustrated at block 510. The barcode 165 can be a two-dimensional (2D) Quick Response Code having, an AES encrypted data, a MAC data, payment information and other Payer information. The barcode 165 on the transaction initialization unit 120 can be scanned by the transaction processing request unit 150 and verified in order to validate the transaction with respect to the Payer 110, as illustrated at block 520. On accepting, the transaction processing application 160 debits the customer's account and credits merchant's account, as depicted at block 530.

[0051] FIG. 6 illustrates a work flow diagram 550 illustrating the transaction process between the Payee 140 and the Transaction server 160, in accordance with the disclosed embodiments. The transaction between the merchant 140 and the Transaction server 160 can be done via a GPRS connection. On initiating the transaction with the Transaction server 160, the merchant 140 creates a request in order to check the credit details of the Payer mobile valet, as illustrated at block 560. The Transaction server 160 thereby transmits transaction authorization response to the merchant 140 based on the availability of sufficient funds in the Payer mobile valet. If the Payer 110 has sufficient funds, the Transaction server 160 generates a transaction ID and sends it along with the transaction authorization response to the merchant 140. Otherwise, the Transaction server 160 terminates the process. In case of positive transaction authorization response from the Transaction server 160, the merchant 140 initiates commit/reject request in the transaction processing system 100. Based on the response from the merchant 140, the Transaction server 160 either credits the merchant's mobile account and debits the Payer's mobile valet account or terminates the transaction and sends the commit response to the merchant 140, as depicted at block 570.

[0052] FIG. 7 illustrates a high level flow chart of operation illustrating logical operation steps of a method 600 for processing a transaction between the Payer 110 and the Payee 140 within a business environment, in accordance with the disclosed embodiments. The 2D barcode 165 having at least one data parameter such as, a MAC data, a Payer input, an auto invoke string and other details with respect to the Payer 110 can be generated on the Transaction Initialization Device unit 120, as illustrated at block 610. The 2D barcode 165 can be captured utilizing the image capturing unit 322 of the Transaction Request Processing Device unit 150, as depicted at block 620. The data parameters in the 2D barcode 165 can be scanned and retrieved utilizing the barcode scanning module 316 of the Transaction Request Processing Device unit 150 in order to auto invoke the Payee application 338, as indicated at block 630. The payment request can along with the data parameters of both the Payer 110 and the Payee 140 can be transmitted to the Transaction server 160 via a wireless network 180, as illustrated at block 640. The Payee and Payer data parameters can be verified at the Transaction server 160 in order to confirm the transaction between the Payer 110 and Payee 140 within the business environment, as depicted at block 650. The system and method described herein therefore provides a mechanism for the Payer to make payment to the Payee without the need for divulging/receiving personal information (such as Mobile Number, account number or name or ID) between the parties. [0053] The system provides barcode based payment mechanism using the Mobile Device of the Payer and Mobile Device with a camera or PDA with a camera or Computer attached to a Webcam of the Payee. The main objectives of the system are: Reducing network traffic by minimizing the communication between devices and server by generating the barcode within the Payer mobile device, Changing the way of payments being made by the customers in retail stores and to street vendors, Secure way of making payment to other party without any need of knowing other parties credentials, Contact less connect between the payer and payee through mobile without any communication between mobiles, Reduce the need for having huge infrastructure by utilizing the existing infrastructure in usage such as Mobile phones, mobile bandwidth etc., Embedding digital identity of the payer and payee in such transactions, To benefit the macro and micro aspects of global economy.

[0054] The system provides a mechanism for the Payer to make a payment to a Payee without the need for exchanging any information in clear text to the Payee or receiving any information in clear text from the Payee. The Private Key (based on PKI) and the AES encryption and MAC keys stored in Mobile devices (either in SIM, Crypto SD card or generated in mobile devices itself) can be used for creating encoded information of the payer and payee for transmission via a wireless network to a payment transaction server for real time payment enablement. The Private key, AES encryption, MAC 1<eys can be generated on the mobile devices of the Payer and Payee for authentication with the Payment Transaction Server.

[0055] The barcode can be created on the payer mobile device containing encrypted payer information both pre-defined inputs such as Phone Number, Random Number, Unique Counter and other Payer Input (such as amount). The information in the barcode includes the MAC of the encrypted Payer information. The MAC is created using the MAC key to ensure that any tampering of the Payer information is detected and re-creation of Payer information by any other device (other than the Payer Mobile device) is not possible. The barcode thus generated can be optically scanned using the camera and a scanner application on the Payee Mobile device. The process of scanning auto-invokes a software application on the Payee device which can detect only the amount information and display to the payee for confirmation. On confirmation by the Payee, the Payee Mobile device creates encrypted information of the Payee Mobile number, random number, Payer input, encrypted Payer information, Payer MAC, etc.

[0056] The data generated information can be transmitted via the wireless network (GPRS) or Secure SMS to the Payment Transaction Server. The Payment Transaction Server further decodes and independently performs authentication and validations of the Payee and Payer encoded information via utilizing the unique encryption and MAC keys of the Payee and Payer). Based on the Payer balance available, the Payment Transaction Server also approves/rejects the payment request in order to provide a real time transfer of funds between the Payer and Payee accounts in the Payment Transaction Server. The Payment Transaction Server finally transmits a confirmation message for the payment request to the Payee Mobile device along with an updated balance in the Payee Account. The Payment Transaction Server also send a confirmation message for the payment request to the Payer Mobile device along with an updated balance in the Payer Account. The software application on the Payer and Payee Mobile device permits the payer and payee to view the balances in the respective Transaction Server accounts, view transaction history and request for recharge of the accounts.

[0057] It will be appreciated that variations of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.

Claims

CLAIMS What is claimed is:

1. An automated mobile payment processing system, said system comprising: a transaction initialization unit configured with a mobile transaction application initiates and validates a transaction within a business environment via generating a barcode.

a transaction processing request unit having an image capturing unit captures and detects said barcode in order to extract at least one encoded information within said barcode generated at said transaction initialization unit;

a transaction server having a server application receives a transaction request from said transaction processing request unit and transmits an appropriate response with respect to said transaction initialization unit and said transaction processing request unit in order to thereby provide a secured, user-friendly, non-reputed and cost effective barcode based payment mechanism within a wide range of business applications.

2. The system of claim 1 wherein said transaction initialization unit comprises a secure key generation application for generating at least one of the following encryption keys: at least one RSA Key; an AES encryption; and at least one MAC key.

3. The system of claim 1 wherein said transaction processing request unit comprises a secure key generation application for generating at least one of the following encryption keys: at least one RSA private Key; an AES encryption; and at least one MAC key.

4. The system of claim 1 wherein said transaction initialization unit comprises a secure key generation application for generating at least one of the following encryption keys: at least one RSA Key; an AES encryption key; and at least one MAC key.

5. The system of claim 1 further comprising a dual layer secured storage medium for storing said at least one RSA private keys and said AES encryption key.

6. The system of claim 1 wherein said transaction server transmits said response via at least one of the following channels: a GPRS channel; and a SMS channel.

7. The system of claim 1 wherein said transaction server comprises a transaction processor for decoding the multiple layers of encryption, validating duplicate and out of sequence payer information, real time management of account information.

8. The system of claim 1 wherein said transaction initialization unit comprises at least one of the following mobile devices: a Smartphone; and an iphone.

9. The system of claim 1 wherein said transaction processing request unit comprises at least one of the following mobile devices: a Smartphone; an iphone; a laptop; a palmtop; and a data processing unit.