WO2015056119A1 - Système et procédé pour permettre des transactions - Google Patents
Système et procédé pour permettre des transactions Download PDFInfo
- Publication number
- WO2015056119A1 WO2015056119A1 PCT/IB2014/064822 IB2014064822W WO2015056119A1 WO 2015056119 A1 WO2015056119 A1 WO 2015056119A1 IB 2014064822 W IB2014064822 W IB 2014064822W WO 2015056119 A1 WO2015056119 A1 WO 2015056119A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- authentication code
- user
- module
- transaction
- data
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000012545 processing Methods 0.000 claims abstract description 21
- 238000004891 communication Methods 0.000 description 21
- 235000014510 cooky Nutrition 0.000 description 5
- 230000001010 compromised effect Effects 0.000 description 4
- 239000011159 matrix material Substances 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 235000013305 food Nutrition 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
- G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
- G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/30—Individual registration on entry or exit not involving the use of a pass
Definitions
- the subject matter relates to the field of enabling online based transactions and offline based transactions using electronic devices. More particularly, but not exclusively, the subject matter relates to enabling individuals to carry out secured and simplified transactions even in the absence of a card, using user's electronic device
- the user can store the requisite details in that account. Thereafter, the user can log into the account during subsequent visits, and make purchases without entering the details that are stored. In this technique however, the user will have to create such accounts in each of the e-commerce sites where he desires to make purchases, if the user wishes to enjoy the aforementioned facility. Furthermore, any security compromise at the e-commerce sites' end may result in compromising the stored details. It must be noted that these email-and-pas sword based accounts are open for access to anyone on internet and hence can get impersonated. It must be also be noted that these accounts are active for access in a permanent way i.e. with same credentials. The credentials to access account is not temporary and hence the chance for compromise is present all the time.
- a system for enabling transaction includes an application module and a transaction module.
- the application module is configured to collect data from a user.
- the transaction module includes a storage module and a processing module.
- the storage module is configured to store at least a part of the collected data from the user.
- the processing module is configured to, set a temporary authentication code to data collected from user based on a request received from the user; provide the temporary authentication code to the specified recipient; and provide at least a part of the stored collected data from the user, to at least a first third-party application, based on authentication carried out using the authentication code and its role in transaction.
- Another embodiment provides a method for enabling transaction.
- the method includes collecting data from a user; storing at least a part of the collected data from the user; generating a temporary authentication code based on a request received from the user; providing the authentication code to the specified recipient; and providing at least a part of the stored collected data from the user, to at least a first third-party application, based on authentication carried out using the authentication code and its role in transaction.
- FIG. 1 is a block diagram of an exemplary system 100 for enabling transactions, in accordance with an embodiment
- FIG. 2 illustrates an interface provided in an application module 102 that enables a user to register, in accordance with an embodiment
- FIG. 2A to 2C illustrate interfaces provided in an application module 102 that enables collection of data from the user, in accordance with an embodiment
- FIG. 3 is an illustration of an exemplary interface provided by the application module 102 to enable the user to request for an authentication code, in accordance with an embodiment
- FIG. 3A is an illustration of an exemplary interface provided by the application module 102 to enable the user to set an authentication code, in accordance with an embodiment
- FIG. 4A and 4B are illustrations of an exemplary interfaces provided by the application module 102 for displaying the generated authentication code, in accordance with embodiments;
- FIG. 5 exemplifies communication of a first third-party application 502 with a transaction module 106, in accordance with an embodiment
- FIG. 6 exemplifies communication of a second third-party application 602 with the transaction module 106, in accordance with an embodiment
- FIG. 7 is a flowchart of an exemplary method for enabling transactions, in accordance with an embodiment.
- FIG. 8 is a flowchart of an exemplary method of carrying out authentication using an authentication code, in accordance with an embodiment.
- Embodiments relate to technique for enabling individuals to carry out secured and simplified online and offline transactions.
- a system is provided to enable users to make purchases on e- commerce sites.
- This system comprises of an application module, which can be installed on a user's communication device, such as a tablet or a smart phone.
- the system also includes a transaction module, which can reside on cluster of servers in the internet. Each of these servers can perform the role of processing module or storage module.
- the application module is enabled to collect data corresponding to the user, such as, personal details of the user, one or more billing details, one or more shipping details and details corresponding to one or more financial instruments (Ex: credit cards and debit cards, net banking details, online wallet accounts and loyalty discount cards, among others).
- the application module communicates with a transaction module provided in the system, and stores the data in the storage module.
- the user In the event of the user wanting to make a purchase on an e-commerce site, the user through the application module, sends a request to the transaction module to generate a temporary authentication code.
- the transaction module on receiving the request, generates a temporary authentication code, which can be in the form of a number and sends it to the application module.
- the user enters this authentication code in the e-commerce site, which can be referred to as a first third-party application.
- the e-commerce site communicates this authentication code to the transaction module.
- the transaction module does validity checks, which may just include comparing the received authentication code and the generated authentication code.
- the transaction module communicates at least a part of the data, such as a billing address, shipping address and personal details to the e-commerce site. Hence, the user will not have to enter such details manually at the e-commerce site and more importantly the financial instrument data is protected from merchant. E-commerce site may then pass the authentication code to payment gateway, which can be referred to as second third-party application.
- payment gateway communicates authentication code, the system shares another part of user's data, the financial instrument details, to enable transaction.
- FIG. 1 is a block diagram of an exemplary system 100 for enabling transactions, in accordance with an embodiment.
- the system 100 includes an application module 102 and a transaction module 106.
- the transaction module 106 includes a storage module 108 and a processing module 110.
- modules described can reside in part or fully in any of the physical entities, such as, but not limited to, electronic device of user, cluster of servers and third-party applications. Therefore, in this description and claims, as one skilled in the art can appreciate, functionalities described can be part of any entity and need not be tied to any discrete entity.
- the application module 102 is installed in a communication device.
- the communication device can be, for example, mobile phone, a tablet, a desktop or a laptop, among others.
- the application module 102 can be a web based application that can be accessed by a user through the communication device.
- the application module 102 is configured to communicate with the transaction module 106 through a communication network 104.
- the communication can occur through internet protocol.
- the communication can occur through messaging service, such as Short Messaging Service (SMS), USSD, Multimedia Messaging Service (MMS), email and phone call, among others.
- SMS Short Messaging Service
- USSD USSD
- MMS Multimedia Messaging Service
- email email and phone call, among others.
- the communication network 104 can be a wired, wireless or a combination of wired and wireless network. Communication can also be through Inter Process Communication (IPC), when the two or more modules are part of the same software in a device.
- IPC Inter Process Communication
- the application module 102 enables a user to create an account for enabling the transaction.
- the account can be created by accessing the application module 102.
- the application module 102 is downloaded onto the user's device, thereby enabling communication between the application module 102 and the transaction module 106.
- FIG. 2 illustrates an interface 200 provided in the application module 102 that enables the user to register, in accordance with an embodiment.
- the user provides at least the mandatory data to register and create an account.
- the mobile device and the transaction module 106 sets up a 2-way encryption key, which is used in future operations for encrypting data.
- the mobile device number such as, the mobile number and IMIE number, among others, can be used for this purpose from the mobile device, which protects the system 100 against spoofing from other unauthorized devices.
- the registration can be carried out using another means, such as at ATM, online website or financial instrument issuing authority, among others.
- a user may submit data, such as, personal details, billing addresses, shipping addresses and financial instrument details to a third party application.
- registration to the application module 102 can be initiated through the third party website, wherein the details submitted to the third party application, either partially or completely, is synced with the application module 102.
- the process of creating an account is well known in the art, and hence not discussed in detail.
- FIG. 2A to 2C illustrate interfaces provided in the application module 102 that enable collection of data from the user, in accordance with an embodiment.
- FIG. 2A illustrates an interface 202 that enables addition of a billing address.
- FIG. 2B illustrates an interface 204 that enables addition of a shipping address.
- FIG. 2C illustrates an interface 206 that enables addition of details corresponding to a financial instrument. It shall be noted that, multiple such billing addresses, shipping addresses and financial instruments can be added using the respective interfaces provided by the application module 102. It shall be further noted that, one or more fields illustrated in the figures may be absent.
- one or more fields may be present. Furthermore, some of the fields may be mandatory, while others may be optional. It shall be noted that any data relevant for a transaction can be collected in user's device apart from the sections described here in this embodiment.
- the data received by the application module 102 is communicated to the transaction module 106.
- a part of the data received by the application module 102 is communicated to the transaction module 106.
- data corresponding to the financial instruments may be communicated to the transaction module 106, while data corresponding to the billing and shipping addresses may not be communicated to the transaction module 106 at the instance of adding the addresses, they may be communicated, when the need arises.
- sensitive information such as, some or all of the details corresponding to the financial instrument, is stored in the transaction module 106, and such data may be deleted, encrypted or password protected in the application module 102.
- storage module which is part of transaction module 106 can exist in part or full in any physical entities.
- data collected from user may be stored in user device.
- data collected from user may get stored in cluster of servers hosting database.
- data collected gets stored in both user device and remote cluster of servers.
- the application-module 102 is further configured to enable the user to request for a temporary authentication code.
- FIG. 3 is an illustration of an exemplary interface 300 provided by the application module 102 to enable the user to request for a temporary authentication code, in accordance with an embodiment.
- the user can select a billing address, shipping address and financial instrument to be used for the transaction, while requesting for the authentication code. The selection made by the user will be communicated to the transaction module 106. It shall be noted that, in an embodiment, default values, such as default billing address, shipping address and financial instrument may be displayed. Thereafter, if required, the user can select an alternate value, for example by selecting a value by clicking on the dropdown button.
- the default values may be selected by the user, or alternatively, the default value may be selected by the system based on user's selection trend.
- the user can make changes, such as, for example, phone number, email address and physical address, among others while requesting for authentication code.
- the user sets the authentication code, as illustrated in FIG. 3A.
- the authentication code that the user sets may be of his own choice or based on the instructions received by him.
- the user is enabled to override at least a part of the collected data corresponding to the user, prior to sending the request for the authentication code to the processing module.
- the application module 102 is configured to collect additional data related to the transaction, such as, transaction limit, expiry time, merchant and product, among others.
- additional data related to the transaction such as, transaction limit, expiry time, merchant and product, among others.
- the user has to enter a password and authenticate himself before opening the application module 102 to enable a transaction or to access some or all of the functionalities of the application module 102.
- the user has to enter a password and authenticate himself before requesting the authentication code.
- FIG. 4A and 4B are illustrations of exemplary interfaces provided by the application for displaying the generated authentication code, in accordance with embodiments.
- FIG. 4A the selection made by the user and the authentication code, which is a four digit number code, is displayed.
- FIG. 4B the selection made by the user and the authentication code, which is a matrix barcode, is displayed.
- an authentication code is displayed by a third party website, such as an e-commerce website. This authentication code is further used to enable the transaction.
- the authentication code includes alphanumeric character.
- the authentication code includes barcode, such as matrix barcode.
- the authentication code can include one or more of alphanumeric character, barcode, text, pictogram, audio and video. It shall be noted that in case of multiple authentication codes used to enable a transaction, the term 'authentication code' used in description and claims can denote one or more authentication codes.
- the authentication code represents at least a part of the data collected from the user.
- the application module 102 enables the user to select a destination to which the authentication code has to be communicated.
- the destination for example, can be specified by specifying, one or more of, phone number, email address or identification code, which can correspond to friend, family or social acquaintance, which may be recognizable by the application module 102 or the transaction module 106, among others. It shall be noted that, actual sensitive information is not communicated, thereby making the system 100 more secure.
- the recipient can be first third party application, which avoids the step of passing authentication code again to first third party application manually.
- the user can add constraints before requesting the authentication code.
- the constraints can be one or more of, specifying the transaction amount, maximum transaction amount, expiry time for the authentication code, number of times the authentication code can be used, merchant system identifier like website domain and sender/recipient role in transaction, among others.
- System 100 can have default values for the constraints if they are not provided by user.
- the application module 102 enables the user to alter data that was previously entered by the user, which is updated in the transaction module 106.
- the transaction module 106 includes the storage module 108 and the processing module 110.
- the transaction module 106 is enabled to communicate through the communication network 104 with the application module 102.
- the storage module 108 is configured to store the data provided by the application module 102.
- the data stored in the storage module 108 can include, billing details, shipping details, personal details and details corresponding to the financial instruments, which corresponds to the user of the respective application module 102.
- Storage module 108 can exist in part or full in any physical entities and hence in one of the embodiments, storage module 108 may be present along with application module 102.
- the processing module 110 is configured to generate an authentication code based on the request received from the user, for example through the application module 102. Further, the processing module 110 is configured to provide at least a part of the stored collected data corresponding to the user, to at least a first third-party application, based on authentication carried out using the authentication code.
- the transaction module 106 is configured to communicate with the first third-party application.
- FIG. 5 exemplifies communication of a first third-party application 502 with the transaction module 106, in accordance with an embodiment. The communication can occur through the communication network 104.
- the first third-party application 502 is configured to receive an authentication code from a user.
- the first third-party application 502 in addition to the authentication code, is configured to receive a second data set from the user.
- the second data set for example, can be an email address, user name, phone number or identification code.
- the first third-party application 502 is configured to communicate the authentication code along with the second data set, if required, to the transaction module 106, which uses the same to authenticate a transaction.
- the first third-party application 502 is further configured to receive data, such as, one or more of, billing address, shipping address and details corresponding to a financial instrument, as may be required and authorized, from the transaction module 106, upon successful authentication.
- data such as, one or more of, billing address, shipping address and details corresponding to a financial instrument, as may be required and authorized
- the transaction module 106 is configured to communicate with a second third-party application.
- FIG. 6 exemplifies communication of a second third-party application 602 with the transaction module 106, in accordance with an embodiment.
- the communication between the second third-party application 602 and the transaction module 106 can occur through the communication network 104.
- temporary authentication code is passed from first third party application 502 to second third party application 602.
- user re-enters temporary authentication code at second third party application 602.
- the second third-party application 602 is further configured to receive data, such as, one or more of, billing address, shipping address and details corresponding to a financial instrument, as may be required and authorized, from the transaction module 106, upon successful authentication.
- Roles of third party applications are maintained by system 100 and system can have controls like password and firewall checks for every interaction by third party applications.
- the third party applications receive data based on the role of the third party application in the transaction.
- FIG. 7 is a flowchart of an exemplary method for enabling transactions, in accordance with an embodiment.
- the method includes, at step 702, collecting data from a user. Subsequently, at step 704, at least a part of the collected data corresponding to the user is stored. Further, when the user has to initiate a transaction, the user makes a request to set a temporary authentication code to data collected from the user, which is received by the transaction module 106, at step 706. Subsequent to receiving the request, a temporary authentication code is set corresponding to data collected from user at step 708. Thereafter, at step 710, the authentication code is provided to the user.
- step 712 at least a part of the stored collected data corresponding to the user is provided to at least a first third-party application 502, based on authentication carried out using the authentication code.
- some of the steps mentioned above are carried out during registration process or while updating data. Hence, some of the steps may not be necessary each time a transaction has to be enabled. Some of the data may be set as default based on user settings so that it is not required each time a transaction has to be enabled
- the application module 102 collects the data from the user at step 702.
- the data received by the application module 102 is communicated to the transaction module 106 through the communication network 104.
- the collected data is stored in the storage module 108, at step 704.
- the transaction module 106 receives a request from the user to generate an authentication code through the application module 102, at step 706. Upon receiving this request, the processing module 110 generates the code, at step 708.
- the transaction module 106 uses a algorithm to generate an authentication code, which is sufficiently random.
- the user's data may also be used in the algorithm to generate the authentication code.
- authentication code generated may include the actual user data itself but in an encoded manner.
- the processing module 110 communicates the generated authentication code to the application module 102, at step 710.
- the user enters the authentication code into the first third-party application 502, along with an optional second data set.
- the processing module 110 uses the data received from the first third-party application 502, and provides at least a part of the stored collected data corresponding to the user, to the first third-party application 502, based on authentication carried out using the authentication code.
- FIG. 8 is a flowchart of an exemplary method of carrying out authentication using the authentication code, in accordance with an embodiment.
- a user through the application module 102 requests for an authentication code to enable a transaction.
- the request is received by the transaction module 106, which generates an authentication code.
- the transaction module 106 communicates the generated authentication code to the application module 102, at step 802.
- the user accesses the authentication code from the application module 102, and enters the same in the first third-party application 502 along with a second data set, which is associated with the user's account, at step 804.
- the first third-party application 502 communicates the received data to the transaction module 106, at step 806.
- the transaction module 106 performs validation checks. For example, the transaction module 106 verifies whether the entered authentication code and the second data set match with the generated authentication code. If they do not match, then the authentication fails. On the other hand, if they match, then the transaction module 106 verifies whether a predefined time has elapsed since the generation of the code or has the code been used for a transaction earlier. It shall be noted that, essentially authentication rules, which may include verifying whether the authentication code has been used beyond a permissible limit, are checked before enabling the transaction.
- a user uses the system 100 to make an e-commerce transaction.
- the user downloads and installs the application module 102 in his mobile device. Subsequently, the user creates an account by providing personal details and submits multiple billing addresses, shipping addresses and details corresponding to multiple financial instruments, to the application module 102.
- the user also selects default values for the data submitted to be used in a transaction.
- the application module 102 communicates the data to the transaction module 106, which stores the data.
- the user while make a purchase on an e- commerce site, which can be interpreted as first third-party application 502, requests an authentication code to be generated using the application module 102.
- the user allows default values stored earlier to be used while making the request.
- the transaction module 106 receives the request and the selection, generates an authentication code and communicates it back to the application module 102.
- the user enters the authentication code and his mobile number associated with his account in the e-commerce site.
- the e-commerce site communicates the received data to the transaction module 106.
- the transaction module 106 communicates the personal details, billing address and shipping address to the e-commerce site. Hence, the user will not have to enter the personal details, billing address and shipping address manually in the e-commerce site.
- the transaction module 106 communicates details of the selected financial instrument to a payment gateway associated with the e-commerce site. Hence, the user will not have to enter the details corresponding to the financial instrument in an interface corresponding to the payment gateway.
- the user specifies a destination in the application module 102 or in the e-commerce site, to which the authentication code has to be sent. Subsequently, the authentication code is sent to the said destination and can be used as described earlier.
- merchant website can display a code, which may be a random number generated by it and asks the user to set that as temporary authentication code through his device to enable transaction. User can then enter the code in his device. The merchant website can initiate a call to system using temporary authentication code to fetch user's data when user confirms that the operation is completed from device. In an exemplary embodiment, merchant website can make continuous calls to system in background for certain duration without requiring user even to confirm completion of his operation in website.
- a user uses the system 100 to make an offline transaction, such as, paying for fuel at a gas station.
- the user downloads and installs the application module 102 in his mobile device. Subsequently, the user creates an account and submits multiple billing addresses, shipping addresses and details corresponding to multiple financial instruments, to the application module 102.
- the application module 102 communicates the data to the transaction module 106, which stores the data.
- the user to make a payment at the gas station, requests an authentication code to be generated using the application module 102.
- the user selects a financial instrument while making the request.
- the transaction module 106 receives the request and the selection, generates an authentication code and communicates it back to the application module 102.
- the authentication code can be a matrix barcode.
- the barcode is scanned at the gas station.
- the data collected as a result of scanning is communicated to the transaction module 106.
- the transaction module 106 Upon successful authentication, the transaction module 106 provides details of the selected financial instrument to an application, such as a banking application, which can be interpreted as the first third-party application 502 or the second third-party application 602, thereby enabling the transaction.
- an application such as a banking application, which can be interpreted as the first third-party application 502 or the second third-party application 602, thereby enabling the transaction.
- an application such as a banking application, which can be interpreted as the first third-party application 502 or the second third-party application 602, thereby enabling the transaction.
- the user will not have to swipe the card at the gas station. Further, the user need not even carry cards for enabling the user to make payments using cards.
- the authentication code also includes the information to be transferred to the third-party application.
- the third party application may include library to decode the authentication code and use the same to enable transaction.
- the user specifies a destination in the application module 102 or a third-party application to which the authentication code has to be sent. Subsequently, the authentication code is delivered at the said destination and can be used as described earlier.
- transaction can be enabled using an ATM.
- the ATM scans the authentication code from user device in form of bar code.
- the authentication code generated in user device can include entire data in encoded form instead of a code mapping to user's data.
- the authentication code is then used by part of transaction module in ATM, which performs decoding of encoded data to extract the financial instrument details and details corresponding to the amount to be released without contacting any remote server.
- the amount can be withdrawn from the ATM.
- ATM withdrawal is enabled without even using the card.
- the system 100 can be used to enable peer to peer transaction without even exchanging sensitive financial instrument details.
- a first user can request authentication code to be generated using the authentication module 102, and also specify the amount to the transferred.
- the authentication code is subsequently generated and shared with a second user.
- the second user communicates the authentication code along with a second data set to the transaction module 106, through, for example, application module 102 present in the second user's device.
- the transaction is completed.
- the embodiments enable carrying out secured and simplified online and offline transactions. Further, some embodiments enable carrying out secured and simplified online and offline transactions even in the absence of a card.
- the example embodiments described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
La présente invention concerne un système et un procédé pour permettre des transactions. Le système comprend un module d'application et un module de transaction. Le module d'application est configuré pour collecter des données auprès d'un utilisateur. Le module de transaction comprend un module de stockage et un module de traitement. Le module de stockage est configuré pour stocker au moins une partie des données collectées auprès de l'utilisateur. Le module de traitement est configuré pour : définir un code d'authentification provisoire pour des données collectées auprès de l'utilisateur sur la base d'une requête reçue de l'utilisateur ; fournir le code d'authentification provisoire à l'utilisateur, à une application de tierce partie ou à tout autre destinataire spécifié ; et fournir au moins une partie des données collectées stockées correspondant à l'utilisateur, à au moins une tierce partie, sur la base de l'authentification exécutée à l'aide du code d'authentification et de son rôle dans la transaction.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IN4711/CHE/2013 | 2013-10-18 | ||
IN4711CH2013 IN2013CH04711A (fr) | 2013-10-18 | 2014-09-25 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015056119A1 true WO2015056119A1 (fr) | 2015-04-23 |
Family
ID=52827726
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2014/064822 WO2015056119A1 (fr) | 2013-10-18 | 2014-09-25 | Système et procédé pour permettre des transactions |
Country Status (2)
Country | Link |
---|---|
IN (1) | IN2013CH04711A (fr) |
WO (1) | WO2015056119A1 (fr) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2370475A (en) * | 2000-12-22 | 2002-06-26 | Hewlett Packard Co | Secure online transaction where a buyer sends some information direct to a bank and some via a vendor |
EP1710737A1 (fr) * | 2003-12-31 | 2006-10-11 | China Unionpay | Systeme de paiement sur reseau securise et procede d'authentification pour paiement sur reseau securise |
-
2014
- 2014-09-25 IN IN4711CH2013 patent/IN2013CH04711A/en unknown
- 2014-09-25 WO PCT/IB2014/064822 patent/WO2015056119A1/fr active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2370475A (en) * | 2000-12-22 | 2002-06-26 | Hewlett Packard Co | Secure online transaction where a buyer sends some information direct to a bank and some via a vendor |
EP1710737A1 (fr) * | 2003-12-31 | 2006-10-11 | China Unionpay | Systeme de paiement sur reseau securise et procede d'authentification pour paiement sur reseau securise |
Also Published As
Publication number | Publication date |
---|---|
IN2013CH04711A (fr) | 2015-04-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11836724B2 (en) | Systems and methods for performing ATM fund transfer using active authentication | |
US11443290B2 (en) | Systems and methods for performing transactions using active authentication | |
JP7189769B2 (ja) | 位置照合を使用する認証システムおよび方法 | |
US11170379B2 (en) | Peer forward authorization of digital requests | |
US20180082283A1 (en) | Shared card payment system and process | |
US10453062B2 (en) | Systems and methods for performing person-to-person transactions using active authentication | |
US20120059758A1 (en) | Protecting Express Enrollment Using a Challenge | |
US20120191615A1 (en) | Secure Credit Transactions | |
US20180005493A1 (en) | Systems and methods for transferring resource access | |
EP2701415A1 (fr) | Dispositif électronique mobile et son utilisation pour des transactions électroniques | |
WO2016164706A1 (fr) | Plateforme d'authentification de notification de pousser pour un remplissage de formulaire sécurisé | |
US20120239570A1 (en) | Systems and methods for performing ATM transactions using active authentication | |
US11816666B2 (en) | Secure payment processing | |
KR20210069035A (ko) | 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법 | |
KR20180029227A (ko) | 전자 거래를 위한 보안 및 사용자 인증 | |
WO2019197808A1 (fr) | Système de transaction électronique | |
WO2015056119A1 (fr) | Système et procédé pour permettre des transactions | |
US20240193603A1 (en) | Systems and methods for performing atm fund transfer using active authentication | |
KR101812240B1 (ko) | 사용자단말과 휴대폰을 이용한 인터넷뱅킹용 보안카드 정보입력 시스템 및 그 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14853777 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 14853777 Country of ref document: EP Kind code of ref document: A1 |