WO2015132732A1

WO2015132732A1 - Systems and methods for executing payment transactions

Info

Publication number: WO2015132732A1
Application number: PCT/IB2015/051572
Authority: WO
Inventors: Abhinav Sinha; Abhishek Sinha; Anupam Varghese
Original assignee: Eko India Financial Services Private Limited
Priority date: 2014-03-07
Filing date: 2015-03-04
Publication date: 2015-09-11

Abstract

The present disclosure relates to facilitating financial transactions to an acquiring merchant in a manner such that, instead of the customer buying the service/product in context, one or more issuing merchants settle the payment amount (that the customer is due to pay) to the acquiring merchant on behalf of the customer.

Description

SYSTEMS AND METHODS FOR EXECUTING PAYMENT TRANSACTIONS

BACKGROUND

Field

[0001] The present disclosure generally pertains to field of retailing of products and execution of payment transaction. Specifically, the proposed systems and methods relate to display and promotion of goods and services with all relevant information in which consumers may have an interest allowing the consumers/customers/users/clients to make an informed purchase decision and execute payment transactions by arranging and/or adjusting transaction amount with the merchant(s). More particularly, embodiments of the present disclosure relate to systems and methods for an application that facilitates payment for products/services of consumers' interest such that two or more merchants settle the purchase/usage of service of a customer, on behalf of the customer.

Description of the Related Art

[0002] The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

[0003] The advent of the Internet has provided merchants with new channels for reaching customers and providing information, advertising, and offerings related to their goods and/or services. However, sales and marketing campaigns are often not as effective as they are intended to be or should be, because they provide customer information, advertisements, or offers about which the customer may not actually be interested, or alternatively provide the customer with information, advertisements, or offers about which the customer may be interested but at wrong time. [0004] Therefore, advertisers are constantly searching for more efficient means to allow their products/services to be advertised to consumers who have a need for their products/services or who is currently spending money on similar products/services with a competitor. Current options for electronic web based advertising are costly and yield limited results. To reach an acceptable number of consumers', advertisers must run huge and highly expensive campaigns to advertise their products/services, which reach masses of people but only yield a low return in consumer interest and purchases.

[0005] Another important element of online and/or retail shopping is the payment method being used. Generally, online payments methods are used to pay for purchases of goods and/or services, wherein these methods may involve payment instruments such as credit cards, debit cards, or net-banking. Few online shopping portals also allow payment through cash on delivery.

[0006] Currently users who purchase goods and services over the Internet have to deal with credit card companies who dominate the market and charge high processing fees, which even if paid by the merchant from whom the product/service is purchased, adds to the overall cost of goods/services. Also many users shy away from making online payments on unknown sites for trust and security reasons. Digital cash has lower rates than credit card companies, but the adoption has been slow and there are no turnkey solutions still in place.

[0007] Some problems of the current methods include credit card fraud that deters users from using their credit card numbers on the web; high cost of processing that deters merchants from setting up e-Commerce sites; and inability to buy items from multiple merchants with one payment transaction that makes the process cumbersome.

[0008] Even in non-online/non-web based architectures such as retail shops, although most of the above payment transactions are available, it is always the user's account from which the amount for the transaction is debited (or the same is to be paid during credit card cycle) and therefore the user, has to have, the capability to pay for the product/service at that time itself.

[0009] There is therefore a need for systems and methods for conducting financial transactions along with simultaneously enabling significantly improved advertising/marketing by merchants and/or vendors, wherein such systems and methods remove above mentioned drawbacks and limitations of prior art.

[00010] All publications herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.

[00011] In some embodiments, the numbers expressing quantities of ingredients, properties such as concentration, reaction conditions, and so forth, used to describe and claim certain embodiments of the invention are to be understood as being modified in some instances by the term "about." Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that can vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, the numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values presented in some embodiments of the invention may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.

[00012] As used in the description herein and throughout the claims that follow, the meaning of "a," "an," and "the" includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.

[00013] The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. "such as") provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention. [00014] Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.

SUMMARY

[00015] The following disclosure presents a simplified summary of the innovation in order to provide a basic understanding of some aspects of the innovation. This summary is not an extensive overview of the innovation. It is not intended to identify key/critical elements of the innovation or to delineate the scope of the innovation. Its sole purpose is to present some concepts of the innovation in a simplified form as a prelude to the more detailed description that is presented later.

[00016] The innovation disclosed herein, in one aspect thereof, comprises systems and methods for facilitating financial transactions to a merchant in a manner such that, instead of the customer buying the service/product in context, one or more merchants settle the payment amount (that the customer is due to pay) on behalf of the customer. One should appreciate that the embodiments and implementations described below are completely exemplary in nature and are used only for helping in better explanation of the proposed inventive subject matter. No limitation to the scope of the disclosure should be assumed based on the below described subject matter as the disclosure covers all possible transactions that are or can be construed of being within the scope of the instant disclosure.

[00017] In an aspect, system of the present disclosure can include a registration module configured to enable a customer, also hereinafter interchangeably referred to as user/client/consumer, to register with the system through details that can include, but are not limited to, name, address, credit/debit card information, account number, PAN card number, along with a pre-defined amount (for instance, a limit of Rs. 10000/-) upto which the user expects to make transactions. Such a system can either be a hardware, a software, or a combination thereof such that the system can be, for instance, downloaded as an application from the web, or by any other of means. The system can be installed or implemented on any of a mobile phone, smart phone, PC, tablet, Laptop, or any other desired/appropriate computing device. Such a system can be used in any environment, including but not limited to, in retail shops, online shopping, purchase of tickets, or any other desired end use.

[00018] In another aspect, system of the present disclosure can further include a product/service purchase module configured to enable the customer/user to purchase goods/products/services from any medium (online or offline). For simplicity of the instant disclosure, merchant involved in this actual transaction can be defined as an acquiring merchant, wherein the acquiring merchant is a merchant who acquires a customer, i.e., a customer expresses his/her intent of taking the product/service being offered by the merchant. One should appreciate that, in the instant disclosure, reference to online shopping or offline product/service purchase should be interpreted to include any kind of transaction (arising from a purchase or otherwise) that involves use of the proposed system. Similarly, reference to "products/goods" in the instant disclosure should be interpreted to include services. For instance, in an online environment, the product/service purchase module can be configured to enable users to browse through multiple products, and choose one of their preferences, and then move onto the payment page for purchasing the product from an acquiring merchant/vendor/seller.

[00019] In yet another aspect, system of the present disclosure can include an obligation- based payment module configured to enable payment for the purchased product/service by the customer to the acquiring merchant. In accordance with an embodiment of the present application, system of the present disclosure, before processing payment for the purchased good/product/service, can present to the user, one or more offers, also hereinafter interchangeably referred to as "obligations" or simply as "obligs", that have been posted by one or more merchants, referred to as issuing merchants hereinafter, wherein the issuing merchants include merchants who bind the user/customer with an obligation with an amount and / or an expiry. For instance, issuing merchants IM_1 and IM_2 can present their respective obligs to the user on the payment page or any other page before the actual payment/transaction is performed, giving an offer to the user to buy the oblig to enable a situation where the IM_1 and/or IM_2, based on user selection of respective obligs, pay to the concerned acquiring merchant (say AM I) on behalf of the customer. In an instance, in case a customer CI buys a product PI from AM_1 worth USD 40, during the process of payment, CI can be presented with three obligs 0_1, 0_2, and 0_3, respectively from IM_1, IM_2, and IM_3, wherein 0_1 can state that IM_1 can pay USD 10 on behalf of CI in case CI agrees to buy product P2 (worth say USD 120) from IM_1. Similarly, 0_2 can state that IM_2 can pay USD 10 on behalf of CI in case CI agrees take a service SI (worth say USD 250) from IM_2, and 0_3 can state that IM_3 can pay USD 20 on behalf of CI in case CI agrees to buy a product P3 (worth say USD 90) from IM_3. In such case, the customer can take the three obligs (0 1, 0 2, and 0 3) and enable payment for product P2 by the three issuing merchants. In an implementation, each oblig can be associated with an expiry date by when the customer is expected to meet with the oblig. Once such a transaction is complete, the user should therefore comply with the oblig by the expiry date, else the respective issuing merchant (IM) can automatically deduct the amount that was paid by him on behalf of the customer from the amount that is preloaded by the customer. In an embodiment, the proposed system can also enable the user/customer to register with one or more accounts/debit cards/credit cards, wherein the customer can clearly define the amounts being loaded by each account/card, such that in case the oblig is not met by the customer at a later date, the amount paid by the respective issuing merchant (IM) can automatically be deducted, making the proposed architecture risk-free for the issuing merchants.

[00020] In another aspect, system of the present disclosure can include an obligation completion module configured to enable the customer/user to meet up and execute the obligs taken by the customer on or before the expiry/deadline date. Such obligs can be met any of online and/or offline (retail) transactions as would have been defined in the obligs. Such obligs, in an embodiment, can also give discounts to users/customers so as to give a better incentive. Any other parameters such as repeatability, number of customers, type of customers, geography of transaction, kind of transaction (online or offline), mode of customer payment (credit card or debit card), can also be defined by IM's while defining the obligs/offers. In another aspect, issuing merchants can also define the type of customers that they would like to make offers to, the offer amounts that they would like to give, along with defining any other parameter. In another embodiment, customer's performance history in terms of meeting the obligs or defaulting on them can be taken as a parameter to suggest one or more obligs to the customer. Furthermore, system/application of the present disclosure can also analyze the customer profile in terms of the type of products/services that the customer/user likes to buy, types of obligs that the user meets/honors, purchase history, purchase volume, among any other demographic or user activity based parameter to better optimize and give relevant oblig offers to the users.

[00021] Other systems, methods, features, and advantages of the present invention will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[00022] In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

[00023] FIG. 1 illustrates an exemplary architecture of proposed financial transaction system in accordance with an embodiment of the present disclosure. [00024] FIG. 2 illustrates exemplary functional modules of the proposed system in accordance with an embodiment of the present disclosure.

[00025] FIG. 3 illustrates an exemplary flow for the system and method thereof in accordance with an embodiment of the present disclosure.

[00026] FIGs. 4(a), 4(b), 4(c), and 4(d) illustrate an exemplary manner in which a customer can pre-load an amount (in case of prepaid scenario) and/or set a per transaction limit (in case of a credit card scenario) in accordance with an embodiment of the present disclosure. [00027] FIGs. 5(a), 5(b), and 5(c) illustrate an exemplary manner in which a customer can conduct a transaction using the proposed system in accordance with an embodiment of the present disclosure.

[00028] FIGs. 6(a) and 6(b) illustrate an exemplary acquiring merchant interface in accordance with an embodiment of the present disclosure..

[00029] FIG. 7 illustrates an exemplary oblig calendar in accordance with an embodiment of the present disclosure.

[00030] FIGs. 8(a), 8(b), 8(c), and 8(d) illustrate an exemplary mechanism for creation of an oblig by an issuing merchant in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION

[00031] Systems and methods are disclosed for facilitating payment transaction between a customer and a merchant ('acquiring merchant'), wherein one or more other merchants ('issuing merchants') will settle a purchase/ service transaction of a customer with the acquiring merchant, on behalf of the customer. In following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, to one skilled in the art that embodiments of the present disclosure may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

[00032] Embodiments of the present disclosure include various steps, which will be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special- purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, firmware and/or by human operators.

[00033] In various embodiments, the article(s) of manufacture (e.g., the computer program products) containing the computer programming code may be used by executing the code directly from the machine-readable storage medium or by copying the code from the machine- readable storage medium into another machine-readable storage medium (e.g., a hard disk, RAM, etc.) or by transmitting the code on a network for remote execution. Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present disclosure with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various

embodiments of the present disclosure may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the present disclosure could be accomplished by modules, routines, subroutines, or subparts of a computer program product.

[00034] Throughout the following discussion, numerous references will be made regarding servers, services, interfaces, engines, modules, clients, peers, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor (e.g., ASIC, FPGA, DSP, x86, ARM®, ColdFire®, GPU, etc.) configured to execute software instructions stored on a computer readable tangible, non -transitory medium (e.g., hard drive, solid state drive, RAM, flash, ROM, etc.). For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions. One should further appreciate the disclosed computer-based algorithms, processes, methods, or other types of instruction sets can be embodied as a computer program product comprising a non-transitory, tangible computer readable media storing the instructions that cause a processor to execute the disclosed steps. The various servers, systems, databases, or interfaces can exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web service APIs, known financial transaction protocols, or other electronic information exchanging methods. Data exchanges can be conducted over a packet-switched network, the Internet, LAN, WAN, VPN, or other type of packet switched network.

[00035] Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product.

[00036] If the specification states a component or feature "may", "can", "could", or "might" be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.

[00037] The present disclosure, in one aspect thereof, can include systems and methods for settlement of payment transactions between a customer and an acquiring merchant, wherein one or more issuing merchants can be used for partially or completely settling a purchase/ service transaction of a customer, on behalf of the customer. The present disclosure enables firstly, easy and secure way of handling electronic payments and secondly, enables promotion of sales without any expenditure on advertising. One should appreciate that embodiments and implementations described below are completely exemplary in nature and are used only for helping in better explanation of the proposed inventive subject matter. No limitation to the scope of the disclosure should be assumed based on the below described subject matter as the disclosure covers all possible transactions that are or can be construed of being within the scope of the instant disclosure.

[00038] In an aspect, the present disclosure relates to a system of financial transaction that employs two sets of merchants, hereinafter interchangeably referred to as "Merchant" or "trader" or "retailer or "vendor" or "seller" among other like/synonymous terms. The two sets of merchants include "Acquiring Merchants" and "Issuing Merchants". The system further employs a customer, hereinafter interchangeably referred to as "Customer" or "consumer" or "purchaser" or "user" among other like/synonymous terms. Merchant, in general, can be defined as an entity that is in business of selling their products/services to customers. Customer, on the other hand, can be defined as an entity that wishes to acquire product or service from a merchant. "Acquiring Merchant" can be defined as a merchant to whom a customer approaches with intent of purchasing a product/service offered by the merchant, and therefore the acquiring merchant is the one who acquires the customer. Issuing Merchant, on the other hand, can be defined as a merchant who is interested in sales promotion and is willing to partially or completely settle payment obligation with an acquiring merchant on behalf of customer in lieu of an obligation from the customer to purchase certain product/service from him by a defined date/time. [00039] An "oblig" or an "obligation" can be defined as any form of commitment that the customer makes to the issuing merchant in lieu of consideration made available (i.e. payment made by an issuing merchant to a acquiring merchant) by the issuing merchant on behalf of the customer. "Oblig Characteristics" can be defined as commitments that have been defined by the issuing merchant at the time of offer to customer to settle the consideration with acquiring merchant. Oblig characteristics can include any parameter that the issuing merchant wishes to define such as but not limited to amount, time period or repeatability, type of customer, geography of transaction, among many other parameters/attributes that define the conditions based on which the oblig is defined and accepted by the customer. A 'card' as referred to here could include any pre-paid/ debit/ credit/ cash card or an account or a wallet, essentially, any source of funds.

[00040] System of the present disclosure can also include customer-end application hereinafter referred to as "Customer Interface", and can also include a separate and/or integrated a merchant-end interface hereinafter referred to as "Merchant Interface". These interfaces can be defined as systems used by the customer/merchants to facilitate transactions. These interfaces can include, but are not limited to, a mobile application, tablet, Laptop, PC, smart phone, web- based application, among any other appropriate/suitable/applicable financial transaction fulfillment interface. They are programmed to do transactions relevant to application.

[00041] FIG. 1 illustrates an exemplary architecture 100 of proposed financial transaction system in accordance with an embodiment of the present disclosure. Architecture 100 can include a plurality of customers such as customer 102 operatively coupled with one or more acquiring merchants 104 (referred to AM's hereinafter) and also with one or more issuing merchants 106-1, 106-2,... , 106-N (collectively referred to as issuing merchants 106) (referred to as IM's hereinafter). One should appreciate that although the present architecture 100 has been shown with reference to one customer 102, one AM 104, and two IM's 106, any number of customers, AM's, and IM's can be used in the proposed system, and such a number is not a limiting factor in any manner whatsoever. Furthermore, one customer 102 can always work in parallel or sequentially with two or more AM's 104 and also receive communications from a plurality of IM's. It is also possible for the proposed application/system to identify the most suited issuing merchant 106 for the customer in context by enabling a bidding between IMs 106 to take place, and winner of the bid to be the only IM 106 that makes an oblig offer to the customer 102. This however is only an exemplary implementation, and any other means can be adopted by the proposed system to identify one or more IM's 106 that can make offers to the customer 102 to enable the customer 102 to choose one or more offers 106 to completely or partially settle the purchase of the product/service from the AM 104, wherein the balance amount can be paid by the customer 102.

[00042] According to one embodiment, architecture 100 of the proposed system can be implemented as an application that can be accessed remotely or locally by a

customer/user/client/consumer 102 either as a standalone application or after installation.

[00043] According to another embodiment, product/service in the present system can be purchased by the user 102 through any mode such as online shopping or through a retail shop, and therefore the proposed system application can be installed on a client device and

activated/used/opened during the time the payment is to be made to the acquiring merchant 104 from whom the respective product/service is purchased. User 102 can be expected to create an account with the system/architecture 100 through a defined registration process and include details such as account details, name, username, password, demographic/psychographic details, shopping preferences, preferred location/websites of shopping, estimated shopping volume, preferences of brands/product categories, address, date of birth, verification information, preferences, type and kind of products liked, past shopping history, among many other parameters that can be envisaged.

[00044] According to another embodiment, during the purchase of a product from a retailer, at the time of payment, the client/customer 102 can access the proposed system 100 and select the acquiring merchant 104 as the payee. Such acquiring merchant 104 can either be pre- filled or automatically detected based on GPS, or can be manually entered or intelligently retrieved by the user 102. Alternatively, the proposed system can also be presented to the user while the user is making a payment through say a website such as amazon.com, wherein after finalization of the shopping kart, the user can move onto the payment page, where the interface of the proposed system/application can be presented. Before, after, or along with selection of the acquiring merchant 104, system can also present the user 102 with one or more issuing agents 106 who have offers, also referred to as obligations or obligs, indicating that they would be willing to pay (based on a defined set of conditions), on behalf of the customer, a first defined amount towards the purchase of the product by the customer from the acquiring merchant. For this, the user would have to accept the obligation that has been set by the IM 106, wherein such obligation can state that the IM 106 can pay a first defined amount to the AM 104 if the customer/user 102 buys/purchases/uses a product/service from the IM 106 for a second defined amount by a defined deadline/expiry. In case the user accepts the oblig, the respective IM 106 can tag the customer 102 with the selected oblig and can immediately pay the first defined amount to the AM 104. Therefore, account details of the AM 104 can be made available to the IM 106 at run-time or can already have been stored with the IM 106 and the first defined amount can be transacted. Post completion of the transaction, the user 102 is expected to comply with the oblig, by say buying the product that was discussed in the oblig. While buying such a product as well, the customer can take another set of one or more obligs to pay to the new AM 104. In case the user 102 does not buy the product and therefore does not meet the oblig by the defined timeline, the amount that was paid by the IM 106 on behalf of the customer 102 can be deducted from the amount that was pre-loaded by the customer 102 or can be charged to the credit card of the customer 102 depending on the settings and configurations defined by the customer 102. It would be appreciated that the system 100 would ensure that none of the IM 106 or the AM 104 incur any loss at any stage and always get the amount being incurred by them back. AM 104 always get the amount back sooner the purchase transaction is completed, and the IM 106, in case the oblig is not met by the customer 102 gets the amount back sooner the oblig has expired.

[00045] In an embodiment, customers and/or IM's and/or AM's can be communicatively coupled with each other by means of a web application/interface. IM's can either be pre-loaded into the customer interface of the proposed system or can be generated in real time. Such IM's can be configured such that the offers/obligs are presented to the customer 102 based on their preferences, likelihood of oblig completion, time of transaction, oblig compliance history, know your customer (KYC) details of the user, customer transaction history, frequency of purchase, quantum of purchase, mode of payment, type of transaction, product/service in context, or any other parameters.

[00046] In an instance, consider that a user 102 is browsing online for a laptop on 15'th

June 2014 and selects a Dell laptop for USD 700. Post selection, when the user 102 is taken to the payment gateway, system of the present disclosure can initialize the application (or the proposed system can be presented to the user automatically as one of the payment means) and enable retrieval of one or more ongoing obligs. In an instance, there can be N number of obligs, one of which can be by Canon stating that Canon would be willing to pay USD 200 on behalf of the customer 102 to Dell if the customer 102 buys a canon SLR worth USD 600 by the deadline of 15'th November 2014. Alongside, another oblig can be by Rolex stating that Rolex would be willing to pay USD 200 on behalf of the customer 102 to Dell if the customer 102 buys a Rolex watch worth USD 1200 by the deadline of 15'th December 2014, and also states and on such as purchase of Rolex watch the user 102 would get a discount of 10% on the MRP. In such a case, out of the N obligs that have been presented to the customer 102, the customer 102 can select a plurality of obligs such as one by Canon and Rolex, and pay the balance (USD 700-USD 200- USD 200) = USD 300 through cash/card. In case the user than does not meet with the obligs by the due dates of 15'th November and 15'th December 2014 for Canon and Rolex respectively, Canon and Rolex can deduct their already paid amounts of USD 200 each from the amount preloaded by the customer into the proposed system/application. In an embodiment therefore, the customer 102 can never make transactions that involve payments being made by IM's that exceed the total amount pre-loaded by the customer 102. In another alternate embodiment however, the customer 102 can always use a credit card that can be charged by the IM's 106 in case the obligs get expired and therefore the requirement for pre-loaded amount may not be mandatory. However, one would appreciate that the IM and/or the AM in such a case would not be at any risk and would always get their amounts under any circumstance. This therefore gives a strong opportunity to the IM's 106 to market their products/services at minimal or no cost. The system may or may not charge to the IM's 106 for posting their obligs to the customers or may only charge when an accepted oblig has been completed by the customer 102. Any other defined monetary or commercial mode of enabling creation, maintenance, edit, change, or deletion of the obligs can be performed and all such architectures are completely within the scope of the instant disclosure.

[00047] One should also appreciate that customer 102, can also be presented with obligs without an actual AM 104 being in context, wherein the customer 102 can be presented with one or more obligs by the IM's 106 by offering them discounts or confirming them on accepting the obligs and being willing to pay for the oblig amount at a later transaction made by the customer 102. For instance, a customer can select an oblig from Nike before hand, which can state that Nike would be willing to pay USD 50 to any AM 104 that the customer 102 may select in the future if the customer 102 would buy Nike shoes worth USD 450 by lO'th August 2014.

[00048] According to one embodiment, the IM's 106 can, before issuing oblig offers can check the customer's profile to assess whether making the offer to the customer 102 makes sense, the offer amount to be proposed, probability of the customer 102 accepting/honoring the offer, previous offers that the customer 102 honored, previous purchases of the customer 102, frequency of purchase, mode of payment, products purchased, brand of which the products were purchased, among any other parameter. The IM 106 can also check if the AM 104 to which the IM 106 is going to pay on behalf of the customer 102 is actually a competitor of the IM 106, in which the IM 106 can decide not to make an offer or decide to make an offer to the customer 102, depending on the configuration/preferences of the IM 106. One should appreciate that these are exemplary embodiments, and any change in configuration/construction of the manner in which and the customer to which the offers are made by IM's 106 are completely within the scope of the present disclosure. In another instance, the AM 104 can also configure its payment architecture such that it does not accept receiving payments from any IM 106 on behalf of the customer 102 for one or more reasons. [00049] In another embodiment, customer's performance history in terms of meeting the obligs or defaulting on them can be taken as a parameter to suggest one or more obligs to the customer. Furthermore, system/application of the present disclosure can also analyze the customer profile in terms of the type of products/services that the customer/user likes to buy, types of obligs that the user meets/honors, purchase history, purchase volume, among any other demographic or user activity based parameter to better optimize and give relevant oblig offers to the users.

[00050] One should appreciate that the above mentioned system architecture can be performed in both real-life in retail embodiments as well as in online applications. Such online applications can assist in browsing through various means like simple search, category search, merchant/brand search, item/service search or any other method of searching.

[00051] FIG. 2 illustrates exemplary functional modules of the proposed system 200 in accordance with an embodiment of the present disclosure. In an aspect, system 200 of the present disclosure can include a registration module 202 configured to enable a customer, also hereinafter interchangeably referred to as user/client/consumer, to register with the system through details including, but not limited to, name, address, credit/debit card information, account number, PAN card number, along with a pre-defined amount (for instant a top up of USD 5000) that the user expects to make transactions of. Such a system 200 can either be implemented by means of a hardware, a software, or a combination thereof such that the system can be, for instance, downloaded as an application from the web, or by any other of means. The system can be installed or implemented on any of a mobile phone, smart phone, PC, tablet, Laptop, or any other desired/appropriate computing device. Such a system can be used in any environment, including but not limited to, in retails shops, online shopping, purchase of tickets, or any other desired end use.

[00052] In another aspect, system 200 of the present disclosure can further include a product/service purchase module 204 configured to enable the customer/user to purchase goods/products/services from any medium (online or offline). For simplicity of the instant disclosure, the merchant involved in this actual transaction can be defined as an acquiring merchant, wherein the acquiring merchant is a merchant who acquires a customer, i.e., a customer expresses his/her intent of taking the product/service being offered by the merchant. One should appreciate that, in the instant disclosure, reference to online shopping or offline product/service purchase should be interpreted to include any kind of transaction (arising from a purchase or otherwise) that involves use of the proposed system. Similarly, reference to "products/goods" in the instant disclosure should be interpreted to include services. For instance, in an online environment, the product/service purchase module can be configured to enable users to browse through multiple products, and choose one of their liking, and then move onto the payment page for purchasing the product.

[00053] In yet another aspect, system 200 of the present disclosure can include an obligation-based payment module 206 configured to enable payment for the purchased product/service by the customer to the acquiring merchant. In accordance with an embodiment of the present application, system of the present disclosure, before payment processing for the purchased goods/products/services, can present to the user, one or more offers, also hereinafter interchangeably referred to as "obligations" or simply as "obligs", that have been posted by one or more merchants, referred to as issuing merchants hereinafter, wherein the issuing merchants include merchants who bind the user/customer with an obligation with an amount and expiry. For instance, issuing merchants IM_1 and IM_2 can present obligs to the user on the payment page or any other page before the actual payment is performed, giving an offer to the user to buy the oblig to enable a situation where the IM_1 and/or IM_2, based on user selection of respective obligs, pay to the concerned acquiring merchant (say AM_1) on behalf of the customer. In an instance, in case a customer CI buys a product PI from AM_1 worth USD 40, during the process of payment, CI can be presented with three obligs 0 1, 0 3, and 0 3, respectively from IM l, IM_2, and IM_3, wherein 0_1 can state that IM_1 can pay USD 10 on behalf of CI in case CI agrees a product P2 (worth say USD 120) from IM_1. Similarly, 0_2 can state that IM_2 can pay USD 10 on behalf of CI in case CI agrees take a service SI (worth say USD 250) from IM_2, and 0_3 can state that IM_3 can pay USD 20 on behalf of CI in case CI agrees to buy a product P3 (worth say USD 90) from IM_3. In such case, the customer can take the three obligs (0 1, 0 2, and 0 3) and enable payment for product P2 by the three issuing merchants. In an implementation, each oblig can be associated with an expiry date by when the customer is expected to meet with the oblig. Once such a transaction is complete, the user should therefore comply with the oblig by the expiry date, else the respective issuing merchant (IM) can automatically deduct the amount that was paid by him on behalf of the customer from the amount that is preloaded by the customer. In an embodiment, the proposed system can also enable the user/customer to register with one or more accounts/debit cards/credit cards, wherein the customer can clearly define the amounts being loaded by each account/card, such that in case the oblig is not met by the customer at a later date, the amount paid by the respective issuing merchant (IM) can automatically be deducted.

[00054] In another aspect, system 200 of the present disclosure can include an obligation completion module 208 configured to enable the customer/user to meet up and execute the obligs taken by the customer on or before the expiry/deadline date. Such obligs can be met any of online and/or offline (retail) transactions as would have been defined in the obligs. Such obligs, in an embodiment, can also give discounts to users/customers so as to give a better incentive. Any other parameters such as repeatability, number of customers, type of customers, geography of transaction, kind of transaction (online or offline), mode of customer payment (credit card or debit card), can also be defined by IM's while defining the obligs/offers.

[00055] According to one embodiment, system 200 of the present disclosure can enable reminders being sent to customers for completing their obligations/obligs. An oblig calendar can also be presented by the customer/user to show the expiry dates for each oblig that the customer has/had selected.

[00056] FIG. 3 illustrates an exemplary flow 300 for the system and method thereof in accordance with an embodiment of the present disclosure. As can be seen, a customer 302 registers with desired account, personal, preference, and other desired information at 302(a). Customer 302 at 302(b), can also be configured to set an upper transaction limit for each transaction. In addition, the customer can, depending on whether he/she is using a credit card or a debit card, be asked to transfer and/or preload an amount of his convenience, which would then define the number of obligs he/she can take on. For instance, in case the customer has preloaded (like pre-paid) an amount of USD 100, he can only take 10 obligs of USD 10 each, or 2 obligs of USD 50 each, or any other possible combination. This would ensure that even if the oblig is not executed by the customer 302, the IM does not suffer a loss and can always deduct the amount from the amount preloaded by the customer.

[00057] In an embodiment, the customer can, at 302(c) then select an item/product/service and make an intention of purchasing the same. Such selection can then be finalized by selecting the AM from which the product would be purchased at 304(a), wherein multiple AM's can be viewed and then scrutinized for finalization of the vendor/AM 304. Upon finalization of the product and AM 304, the customer 302 can be taken to the payment page or any other page at 304(b) where obligs from one or more IM's can be presented to the customer 302. Such obligs can be selected based on any defined criteria, and in one embodiment, all existing and currently running obligs can be presented and then filtered by the user 302 by entering certain conditions.

[00058] In another embodiment, at 306(a), a payment processing server(s) or any other computing/processing element of the proposed system 300 can be used to accept input from customer 302 as to the obligs that he/she would like to use for payment of the product for the current AM. Balance amount, if any, can be given/deducted from the account of the customer. Once the payment of the AM has been done partially or completely by the IM, customer 302 can be reminded of the obligs that he/she has/had accepted and the deadline for the same.

[00059] In another embodiment, obligs could be chained. For example, at the time of fulfilment of a certain obligation 01, the customer could choose to take on one or more other obligs, say 02 and 03 such that the issuing merchants offering 02 and 03 would pay for fulfilment of a customer obligation 01 (here the merchant fulfilling 01 becomes the acquiring merchant). [00060] In another embodiment, an oblig could be fulfilled not by the customer himself/ herself but by any other person or entity or persons or entities who would be willing to fulfil the obligation on behalf of the customer. The customer may use any of his existing social networks to discover and enable such a fulfillment. Such obligation transfer means can be incorporate say through an email, SMS, chat, message, or any other means, wherein the obligation is transferred and accepted by another user, who then has to meet the obligation else the amount in the obligation would be deducted from his/her account.

[00061] One should appreciate that an oblig may not always mention any particular purchase of a product/service that needs to be done by the customer. For instance, an oblig 01 by an issuing merchant can mentioned that the IM can pay USD 50 on behalf of the customer if the customer sends their product information to say 50 people, which if accepted, can be tracked by the customer to make sure the oblig is met with.

[00062] The proposed system therefore includes a settlement program, which manages the customers, their obligs, acquiring merchants, and issuing merchants. Such a system can be implemented in the form of an application and accessed either as a standalone or a web-based application, and installed on any desired computing device, allowing the customer to, for instance, browse through merchants and in parallel, merchants can also quote their prospective customers.

[00063] FIGs. 4(a), 4(b), 4(c), and 4(d) illustrate an exemplary manner in which a customer can pre-load an amount (in case of prepaid scenario) and/or set a per transaction limit (in case of a credit card scenario) in accordance with an embodiment of the present disclosure. FIG. 4(a) illustrates an exemplary representation of the home screen, which enables access to set a transaction limit or transfer an amount. FIG. 4(b) represents how a credit/prepaid/debit or any other card/account can be used to define the transaction limit or even transfer the limit amount depending on the implementation. FIG. 4(c) illustrates an exemplary confirmation representation showing that USD 200 has been set as the transaction limit. This limit can then define the number of obligs that the customer can take while purchasing products/services. FIG. 4(d) shows the home screen after or before a user/customer sets the transaction limit, wherein the screen also shows the calendar that indicates to the user the expiry dates for each oblig. Notification history can indicate the reminders that have been issued by the application/system to enable the user to meet the obligs. The third option can enable the user to again modify/reset/change the set transaction limit by adding more money/amount if desired.

[00064] FIGs. 5(a), 5(b), and 5(c) illustrate an exemplary manner in which a customer can conduct a transaction using the proposed system in accordance with an embodiment of the present disclosure. At FIG. 5(a), a customer can visit a cafe such as Acme Cafe and have a Coffee, for which the bill is USD 5. In such a case, the payment can either be initiated by the acquiring merchant using a merchant interface (shown in FIG. 6) by indicating the customer to whom the bill is to be given, or the customer can initiate the transaction by selecting the Cafe, or allowing the system to automatically select the same based on GPS location or other parameters. Once the bill is received, one, or few, or all the obligs can be displayed in the customer interface, enabling the customer to choose one or more obligs to fulfill the payment. As shown in FIG. 5(a), the customer can, from a list of obligs, select two obligs, namely of FlicKart.com of USD 1, and of SomeTel of USD 4, which would total to the payment of the complete bill of USD 5. As can be seen, the expiry of the first oblig by FlicKart.com is November 10, 2013, and the expiry of the second oblig by SomeTel is Jan 1, 2014. Conditions of the oblig such as product/service being sold, condition, terms, and all other details can be accessed by clicking on the respective oblig. Once selected, the confirm button can be selected to make the payment, confirmation of which can be seen at FIG. 5(b). Once paid, as shown in FIG. 5(c), the user can be taken back to the home page to access more deals, products, browse AM/EVP s. User can also

view/modify /create/update his/her profile.

[00065] FIGs. 6(a) and 6(b) illustrate an exemplary merchant interface 600 that enables the acquiring merchant to initiate the payment process by selecting the customer (as shown in FIG. 6(a)) or by adding a new customer through details such as phone number, PAN card number or any other means/identifier such as email address, registered account identifier with the system. Such customers can either be stored in the list of customers in the merchant interface or can be added in real time. Once the customer is selected, the AM can then request the customer for payment as shown in representation FIG. 6(b).

[00066] FIG. 7 illustrates an exemplary oblig calendar 700 in accordance with an embodiment of the present disclosure. Such a calendar can help the customer/user view the expiry dates of various obligs that he has accepted or can/may accept.

[00067] FIGs. 8(a), 8(b), 8(c), and 8(d) illustrate an exemplary mechanism for creation of an oblig by an issuing merchant. At 8(a), IM can be expected to enter account/card details to increase/modify the balance for issuing the obligs and make transactions to the AM. FIG. 8(b) illustrates the manner in which the obligs can be created/viewed/modified. For instance, as shown in this representation, an active campaign of this IM relates to a limit of USD 100 being given as an oblig amount to 100 customers with the expiry date being 10 days away. During creation, as shown below, the IM can enter the amount that it would be willing to pay to the AM when the customer confirms taking on the oblig, the product details, discount, expiry date, among other desired details. One should appreciate that in case an oblig is created by McDonalds for USD 10 that would be paid to any AM on behalf of a customer that would be willing to buy a meal of USD 50. In such a case, it may be possible that the customer only take the oblig amount of USD 5, or 7 or any other amount instead of the allocated USD 10 amount. Also instead of an expiry date, a deadline date from the date the oblig is taken can also be entered and put forth. Therefore, any such modification in the system is completely within the scope of the instant disclosure. FIG. 8(c) shows a further representation that enables the IM to target the campaign to a defined age group, sex, location, among any other parameter that may be defined in the system. FIG. 8(d) shows a final representation illustration a confirmation screen giving an option to the customer to modify/create or amend the oblig or define conditions when the oblig can be processed. Once this is confirmation, the oblig would be activated and continued based on defined conditions.

[00068] According to one embodiment, obligations can include time, money, or can be of any different kind, wherein the issuing merchant can mention that the customer needs to buy a product/service for 'x' amount (lower than an amount for which the oblig was taken) within a period. Oblig can also be transferable. Obligs can also state that the customer has to get 2 new friends to try product of the same issuing merchant within the next 2 months. Any other type of oblig having any desired condition can therefore be created by the IM. Basically, we can keep the design of the obligs also open to the issuing merchant.

[00069] As used herein, and unless the context dictates otherwise, the term "coupled to" is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms "coupled to" and "coupled with" are used synonymously. Within the context of this document terms "coupled to" and "coupled with" are also used euphemistically to mean "communicatively coupled with" over a network, where two or more devices are able to exchange data with each other over the network, possibly via one or more intermediary device.

[00070] It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms "comprises" and "comprising" should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refers to at least one of something selected from the group consisting of A, B, C, ... , and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc.

Claims

We Claim

1. A financial transaction system comprising: a product/service purchase module configured to enable a customer to buy a product/service from an acquiring merchant for a defined amount; and an obligation-based payment module configured to present one or more obligation offers from one or more corresponding issuing merchants to the customer, wherein said one or more obligation offers offer to enable corresponding issuing merchants to pay at least one part of the defined amount on behalf of the customer to the acquiring merchant provided the customer meets the conditions outlined in the one or more obligation offers.

2. The system of claim 1, wherein the conditions for one or more obligation offers comprise one or a combination of product of the issuing merchant to be purchased, price at which the product is to be purchased, expiry date of the offer, constraints on transferring the obligation offer, constraints on using other obligation offers to meet an obligation offer, and transaction related constraints.

3. The system of claim 1, wherein the customer selects at least one of said one or more obligation offers that pays part of or the complete defined amount, wherein in case of part payment, balance amount from the defined amount is paid by the customer.

4. The system of claim 3, wherein obligation of the at least one selected obligation offer is transferable to another customer.

5. The system of claim 3, wherein, the at least one selected obligation offer is honored by the customer by means of taking one or more additional obligation offers, wherein the total amount of obligation offers taken by the customer cannot exceed the amount that the customer has with said system.

6. The system of claim 1, wherein if a selected obligation offer is not honored by the customer based on the conditions outlined in the offer, amount paid by the issuing merchant of the selected obligation offer is deducted from the amount in customer's account. The system of claim 1, wherein the system comprises a registration module configured to enable the customer to create an account and credit a defined transaction amount to the account such that the system allows said customer to take obligations only to the extent allowed by the defined transaction amount.

The system of claim 1, wherein the system enables said customer to input and/or update one or a combination of demographic details, shopping preferences, past shopping history, products purchased, volumes purchase, previous shopping amounts, brands purchase, services takes, obligation offers taken up, obligation offers honored, and customer/shopping attributes.

The system of claim 1, wherein said one or more obligation offers are submitted to said customer based on one or a combination of criteria defined by the one or more issuing merchants, previous product/service purchase history of the customer, previous obligation offer honoring history, customer's shopping preferences, time/date/day of the year, the product/service, the acquiring merchant, preferred mode of payment, online/offline shopping mode for the product/service, vendors details, and shopping attributes.