Sign In to Follow Application
View All Documents & Correspondence

A System And Method For Carrying Out A Financial Transaction

Abstract: A method of processing a financial transaction between a first and second entity over a communication network including a mobile network transaction system is disclosed. The method includes registering the first entity and the second entity in a user database of the mobile network transaction system, wherein registering the first entity includes generating for the first entity a user identity and a personal identification number to validate the user identity; and further includes registering for the first entity a financial instrument and linking the financial instrument to the user identity; and wherein registering the second entity includes registering a mobile communication identifier for the second entity and further includes registering a financial instrument for the second entity and linking the financial instrument to me mobile communication identifier; receiving details of the financial transaction to be processed between the first entity and the second entity, the details including user identity for the first entity, receiving the personal identification number of the first entity and validating the financial transaction on receiving a valid response; transmitting to a payment gateway of the financial instrument of the first entity details of the validated transaction and details of the financial instrument for the second entity. A system for processing a financial transaction is also disclosed.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
16 January 2009
Publication Number
51/2010
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
Parent Application

Applicants

MCHEK INDIA PAYMENT SYSTEMS PVT LTD
A 102 DELPHI HIRANANDANI BUSINESS PARK POWAI, MUMBAI 400076.

Inventors

1. TAMAL DAS
NO. 27, S.V. TOWERS, 3RD FLOOR, 80 FEET ROAD, 6TH BLOCK, KORAMANGALA, BANGALORE 560095.
2. VALERIE ROZYCKI
NO. 27, S.V. TOWERS, 3RD FLOOR, 80 FEET ROAD, 6TH BLOCK, KORAMANGULA, BANGALORE 560095.

Specification

FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL SPECIFICATION
(See section 10, rule 13)

7. Title of the invention
"A SYSTEM AND METHOD FOR CARRYING OUT A FINANCIAL TRANSACTION"
2. Applicants)
Name Nationality Address
MCHEK. INDIA PAYMENT SYSTEMS PVT. LTD. INDIA A 102 DELPHI HIRANANDANI BUSINESS PARK POWAI, MUMBAI-76


3. Preamble to the description
PROVISIONAL SPECIFICATION
The following specification particularly describes the invention.

The invention relates to the field of financial transactions. More particularly the invention relates to a system and method for carrying out a financial transaction over a mobile phone. DESCRIPTION OF RELATED ART
When customers want to purchase goods or services from stores or other providers they may make payments through cash, cheque or cards such as credit cards, debit cards or smart cards. Such payment methods tend to be slow, cumbersome and involve significant security risks. Cash is often inconvenient to carry and is at a risk of being stolen. Cards such as credit cards, debit cards or smart cards are also at a risk of being stolen and misused. Moreover, to accept payments through credit card, debit card or smart cards, card readers are required at the point of sale. This may be inconvenient due to high cost of such machines and as it may not be possible for the merchants to carry such machines with them at all times.
With the advent of mobile phone technology it is now possible for customers to store their account details on the mobile phones and make payments through their mobile phone. In order to carry out a financial transaction on a mobile platform both the customer and the merchant are required to carry previously registered mobile phones.
However, existing cellular technology does not find wide scale application as a large number of customers do not own mobile phones. Some customers who own mobile phones are reluctant to use such payment systems, often on account of security and complexity of such systems. Another deterrent in the use of mobile based payment technology is the need for mobile users to enter their details and authenticate their mobile phone each time they change their mobile phone or service provider.
In view of these limitations there is a need for a system for carrying out financial transactions on a mobile phone that does not require users to have a personal mobile phone.
2

BRIEF DESCRIPTION OF THE DRAWINGS
Examples of embodiments of the invention are illustrated by way of illustration and not limitation in the figures of the accompanying drawings, in which like references indicate similar element and in which;
Figure 1 is a schematic illustration of a system for carrying a financial transaction over a shared mobile phone in accordance with an embodiment.
Figure 2 is a schematic illustration of a payment processing system in accordance with an embodiment.
Figure 3 is a schematic illustration of an alternate embodiment of the system for carrying a financial transaction over a shared mobile phone.
DETAILED DESCRIPTION
For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated method and system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.
It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be restrictive thereof. Throughout the patent specification, a convention employed is that in the appended drawings, like numerals denote like components.
Reference throughout this specification to "one embodiment" "an embodiment" or
similar language means that a particular feature, structure, or characteristic described in
3

connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase "in one embodiment'*, "in an embodiment" and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
A system and method for carrying out financial transactions over a mobile phone is described. More particularly a system and method for carrying out a financial transaction over a shared mobile phone is described.
A system for carrying out a financial transaction over a mobile phone wherein a service provider provides a payment processing system that provides an interface between an entity with a mobile phone at one end and an entity without a mobile phone at the other end is described. The payment processing system allows a user not having a mobile phone to carry out financial transactions using a shared mobile phone.
"A shared phone" in the present invention is a mobile phone that is owned and maintained by a merchant.
A "merchant" can be a sales person or other person (herein referred to as merchant) who is selling a product, service or performing other transaction with a user, and who owns and maintains the shared mobile phone.
A "user" in the present invention is a person who does not own a mobile phone and carries out a financial transaction over a shared mobile phone.
To carry out a financial transaction over a shared mobile phone, the user is required to
register with the service provider. On registration with the service provider, the user is
provided with a user ID and a password or Personal Identification Number [PIN].
Alternatively, the user may select the user ID and the password or PIN at the time of
registration. The user ID is a unique alias that can be easily remembered by the user and
identifies the user within the payment processing system. A PIN is an input secret entry, such
4

as an alphanumeric string that is used for authorisation of the financial transaction by the user. Once the user is registered with service provider, he may then submit details of his financial instrument such as a credit card, debit card or a bank account to the service provider. The service provider verifies the details of the financial instrument of the user and links the details of the financial instrument to the users ID and the PIN. The user may register the details of multiple financial instruments with the service provider. The user may also be allowed to change the PIN from time to time.
In accordance with an aspect the user may also register with the service provider through a bank. By way of a specific example, the user at the time of opening his bank account may request the bank to register his bank account with the service provider. In such embodiments, the bank submits the user's financial instrument details to the service provider, who then generates the user ID and PIN and sends it to the user.
The merchant registers with the service provider and may install a client application on the shared mobile phone. To register with the service provider the merchant submits the mobile number of the shared mobile phone and other details to the service provider. On registration, the merchant is provided with a merchant ID and PIN that are linked to the shared mobile phone number. Alternatively the merchant may select the merchant ID and the password or PIN at the time of registration. Once registered the merchant may then submit the details of his financial instrument such as account number, card number, card PIN and name to the service provider. The service provider verifies the financial instrument of the merchant and links the details of the merchant's financial instrument with the merchants ID. The merchant may register details of multiple financial instruments with the service provider.
In accordance with an embodiment, the merchant at the time of registration or at any
later stage may also register a second shared mobile phone with the service provider. The
second shared mobile phone number is also linked to the merchants ID. The merchant may
5

also install the client application on his mobile phone and on all subsequent mobile phones that the merchant registers with the service provider. The client application on the shared phone allows the user to initiate and authorise the financial transaction by interacting with the service provider's payment processing system. In accordance with an embodiment the client application on the shared phone is configured to display or present to the merchant and the user with various prompts in order to facilitate the entry of the transaction details and the authentication information. Such menu prompts can guide the merchant and user through the transaction process in a predetermined manner allowing information to be communicated to the payment processing system in an appropriate format.
With reference to figure 1, a system for mobile payment in accordance with an embodiment is illustrated. In a financial transaction between a user (200) and a merchant (180) the user (200) provides his user ID to the merchant (180). The merchant (180) or user (200) uses the shared mobile phone (190) and inputs the user ID into client application on the shared mobile phone (190) along with the transaction details. The user's ID and the transaction details are transmitted to the payment processing system (100) by the shared phone (190). The payment processing system (100) verifies the user (200) and the merchant (180) and identifies the shared phone number linked to the merchant's account. A request for authentication of the financial transaction is then sent to the shared mobile phone (190). The user authorises the financial transaction by entering his PIN into the shared mobile phone (190). On receiving the authentication from the shared phone (190) and verification of the user's PIN, the transaction details are sent to the payment gateway (170) and the payment is processed.
Figure 2 is a schematic illustration of a payment processing system in accordance with an embodiment. The payment processing system (100) comprises of transaction
validation platform (300) that is connected to a database (160) and a payment gateway (170).
6

The transaction validation platform (300) comprises of a transaction processor (110), a channel integration platform (120), a card management system (130), and a switch (140).
Again with reference to figures 1 and 2, in a financial transaction between a user (200) and a merchant (180), the user (200) provides his user ID to the merchant (180). The merchant (180) or user (200) then inputs the users ID and the details of the financial transaction including the type of transaction and the amount into the client application on the shared mobile phone (190). In accordance with an aspect the merchant may need to enter his PIN into the client application of the shared mobile phone (190) along with the user ID and transaction details. The merchant (180) may also need to enter his merchant ID to activate the client application on the shared mobile phone (190). The merchant may at the time of initiation of the transaction select the financial instrument or bank from which he wishes to carry out the transaction.
The client application on the shared phone (190) sends the user ID, transaction details and the merchant's PIN to transaction processor (110) of the payment processing system (100) via a SMS gateway (150). The transaction processor (110) validates the merchant (180) and verifies the limits of the transaction. Once the merchant (180) is validated the channel integration platform (120) then identifies the shared mobile phone on which the request for authentication of the financial transaction is to be sent, from the database (160). The shared phone on which the request for authentication of the financial transaction is to be sent may be the same shared phone (160) on which the user ID and the transaction details are submitted, as per the embodiment illustrated in figure 1. Alternatively, the shared phone on which the request for authentication of the financial transaction is sent may be the second shared mobile phone (210) that has been registered by the merchant, as illustrated in figure 3. In accordance with an aspect the merchant (180) at the time of registration of the second mobile phone with
service provider, selects the shared phone on which he wishes to receive the request for
7

authentication of the financial transaction. In accordance with an aspect multiple merchants may register a single mobile phone as a second shared phone (210) with the service provider. In the embodiment where multiple merchants register a single mobile phone as a second shared phone, the financial transaction is initiated on the shared phone that is owned by the individual merchant, while the request for authentication of the transaction is sent on the second shared phone that is owned and maintained by multiple merchants.
Once the mobile phone on which the request for authentication of financial transaction is identified by the channel integration platform (120), the transaction processor (110) sends a request for authentication of the financial transaction along with the details of the financial transaction to the shared phone (190 or 210). The user (200) then authenticates the financial transaction by inputting his PIN into the client application of the shared mobile phone (190 or 210). The PIN submitted by the user (200) on the client application on the shared mobile phone (190 or 210) is sent to the transaction processor (110) via the SMS gateway (150). The user's PIN is verified by the card management system (130) from the database (160). On successful verification of the user's PIN, the transaction details are sent to the payment gateway (170) via the switch (140). The payment gateway (170) provides a secure communication to the banks system for processing the financial transaction. Once the financial transaction is successfully processed, a message is sent to the transaction processor (110). The transaction processor then generates a receipt for the transaction and sends it to the shared phone (190). The receipt may also be sent to the second shared phone (210). The merchant (180) may then print and give a copy of the receipt to the user (200). Similarly in case of a failed transaction the transaction processor (110) generates and sends an error message to the shared phone (190) to the second shared phone (210).
In accordance with an aspect the financial transaction may also be initiated by some
remote party or a central server. For example the user may make payment of a bill generated
8

by a third party by using a shared mobile phone. By way of a specific example, the user may give the merchant his user ID and specify the type of the bill to be paid. The merchant may then input into the client application of the shared mobile phone the users ID, the details of the type of the bill to be paid and his merchant PIN. The client application of the shared phone sends the details of bill to be paid to the payment processing system. The payment processing system verifies the merchant and the user and identifies the details of the bill that the user wants to pay. The details of the bill, for example the amount due, the period of the bill along with a request for authentication of the transaction are sent to the shared phone by the payment processing system. The user then authorises the payment of the bill by entering his PIN into the shared mobile phone. On receiving the authentication from the shared phone and verification of the user's PIN, the transaction details are sent to the payment gateway and the payment of the bill is processed.
In accordance with an aspect in order to secure mobile financial transactions details sent by the shared mobile phone and the payment processing system are encrypted.
In accordance with an embodiment, the payment processing system may keep a detailed log of all transaction initiated and completed, such that a user or merchant may view the transaction history.
The system as described can be implemented on a mobile device, however, it should be understood that other devices can be utilized with one or more disclosed embodiments. Examples of such devices include smart phones and personal digital assistants (PDAs).
INDUSTRIAL APPLICABILITY
Various financial transactions may be carried out using the system described. Such transactions may include for example payments for a product or service provided by the merchant, payment of loan instalments, payment of premiums or payment of a bill. The
9


10

Documents

Application Documents

# Name Date
1 102-MUM-2009- AFR.pdf 2022-09-02
1 102-MUM-2009-FORM 3(01-02-2010).pdf 2010-02-01
2 102-mum-2009-abstract(18-1-2010).doc 2018-08-10
2 102-MUM-2009-CORRESPONDENCE(01-02-2010).pdf 2010-02-01
3 102-MUM-2009-CORRESPONDENCE(IPO)-(FER)-(26-05-2015).pdf 2015-05-26
3 102-MUM-2009-ABSTRACT(18-1-2010).pdf 2018-08-10
4 abstract1.jpg 2018-08-10
5 102-MUM-2009_EXAMREPORT.pdf 2018-08-10
5 102-MUM-2009-CLAIMS(18-1-2010).pdf 2018-08-10
6 102-MUM-2009-POWER OF AUTHORITY(9-2-2009).pdf 2018-08-10
6 102-MUM-2009-CORRESPONDENCE(18-1-2010).pdf 2018-08-10
7 102-MUM-2009-FORM 5(18-1-2010).pdf 2018-08-10
7 102-MUM-2009-CORRESPONDENCE(25-1-2010).pdf 2018-08-10
8 102-MUM-2009-FORM 3(18-1-2010).pdf 2018-08-10
8 102-MUM-2009-CORRESPONDENCE(9-2-2009).pdf 2018-08-10
9 102-MUM-2009-CORRESPONDENCE(IPO)-(AB 21)-(4-6-2016).pdf 2018-08-10
9 102-mum-2009-form 2.pdf 2018-08-10
10 102-mum-2009-correspondence.pdf 2018-08-10
11 102-MUM-2009-DESCRIPTION(COMPLETE)-(18-1-2010).pdf 2018-08-10
11 102-mum-2009-form 2(title page).pdf 2018-08-10
12 102-MUM-2009-FORM 2(TITLE PAGE)-(18-1-2010).pdf 2018-08-10
13 102-mum-2009-description(provisional).pdf 2018-08-10
13 102-mum-2009-form 2(18-1-2010).pdf 2018-08-10
14 102-MUM-2009-DRAWING(18-1-2010).pdf 2018-08-10
15 102-mum-2009-drawing.pdf 2018-08-10
15 102-MUM-2009-FORM 18(25-1-2010).pdf 2018-08-10
16 102-MUM-2009-FORM 1(18-1-2010).pdf 2018-08-10
16 102-mum-2009-form 1.pdf 2018-08-10
17 102-MUM-2009-FORM 1(9-2-2009).pdf 2018-08-10
18 102-mum-2009-form 1.pdf 2018-08-10
18 102-MUM-2009-FORM 1(18-1-2010).pdf 2018-08-10
19 102-MUM-2009-FORM 18(25-1-2010).pdf 2018-08-10
19 102-mum-2009-drawing.pdf 2018-08-10
20 102-MUM-2009-DRAWING(18-1-2010).pdf 2018-08-10
21 102-mum-2009-description(provisional).pdf 2018-08-10
21 102-mum-2009-form 2(18-1-2010).pdf 2018-08-10
22 102-MUM-2009-FORM 2(TITLE PAGE)-(18-1-2010).pdf 2018-08-10
23 102-MUM-2009-DESCRIPTION(COMPLETE)-(18-1-2010).pdf 2018-08-10
23 102-mum-2009-form 2(title page).pdf 2018-08-10
24 102-mum-2009-correspondence.pdf 2018-08-10
25 102-MUM-2009-CORRESPONDENCE(IPO)-(AB 21)-(4-6-2016).pdf 2018-08-10
25 102-mum-2009-form 2.pdf 2018-08-10
26 102-MUM-2009-FORM 3(18-1-2010).pdf 2018-08-10
26 102-MUM-2009-CORRESPONDENCE(9-2-2009).pdf 2018-08-10
27 102-MUM-2009-FORM 5(18-1-2010).pdf 2018-08-10
27 102-MUM-2009-CORRESPONDENCE(25-1-2010).pdf 2018-08-10
28 102-MUM-2009-POWER OF AUTHORITY(9-2-2009).pdf 2018-08-10
28 102-MUM-2009-CORRESPONDENCE(18-1-2010).pdf 2018-08-10
29 102-MUM-2009_EXAMREPORT.pdf 2018-08-10
29 102-MUM-2009-CLAIMS(18-1-2010).pdf 2018-08-10
30 abstract1.jpg 2018-08-10
31 102-MUM-2009-CORRESPONDENCE(IPO)-(FER)-(26-05-2015).pdf 2015-05-26
31 102-MUM-2009-ABSTRACT(18-1-2010).pdf 2018-08-10
32 102-MUM-2009-CORRESPONDENCE(01-02-2010).pdf 2010-02-01
33 102-MUM-2009-FORM 3(01-02-2010).pdf 2010-02-01
33 102-MUM-2009- AFR.pdf 2022-09-02