Sign In to Follow Application
View All Documents & Correspondence

System And Method For Enabling Secure Contactless Payment Transaction

Abstract: The present disclosure envisages a computer implemented method for detecting and subsequently preventing fraudulent financial transactions in real-time. The method and system envisaged by the present disclosure envisages detecting a fraudulent financial transaction executing either on a customer device or a merchant device in real time, and alerting the corresponding customer/merchant in real time and preventing the (fraudulent) financial transaction from being executed. The present disclosure envisages tracking the (hardware) characteristics of either the customer device or merchant device or both in real-time, to identify/detect any abnormalities therein, and subsequently use the identified/detected (hardware related) abnormality as a cue to validate the genuineness of a financial transaction being executed on either the customer device or merchant device or both. FIG.1

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
10 November 2016
Publication Number
12/2019
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
n.anuvind@formulateip.com
Parent Application

Applicants

NAFFA INNOVATIONS PRIVATE LIMITED
#117, The Arcade, Brigade Metropolis, Garudacharpalya, Mahadevpura, ITPL Main Road, Bangalore - 560048, Karnataka, India

Inventors

1. KUMAR ABHISHEK
B - 602, Brigade Metropolis Apartments, Garudacharpalya, Mahadevpura, ITPL Main Road, Bangalore - 560048, Karnataka, India

Specification

DESC:CROSS-REFERENCE TO RELATED APPLICATIONS
[001] This patent application is related to and claims the benefit of priority from the Indian Provisional Patent Application with Serial No. 201641027384 titled “SYSTEM AND METHOD FOR ENABLING SECURE CONTACTLESS PAYMENT TRANSACTION”, filed on August 10, 2016 and subsequently Post-dated by 3 month to November 10, 2016, and the contents of which are incorporated in entirety by the way of reference.

TECHNICAL FIELD
[002] The present disclosure relates to methods and systems that provide for implementation of financial transactions in a secured manner. Particularly, the present disclosure relates to methods and systems that detect the occurrence of fraudulent financial transactions, and employ counter measures to prevent recurrence of fraudulent financial transactions.

BACKGROUND
[003] The onset of technological developments such as internet banking, mobile banking and e-wallets have brought upon a steady increase in the number users preferring electronic money transfer instead of the conventional modes of money transfer such as the money orders, cheques and hand-to-hand cash exchange. However, in-line with an increase in the number of users preferring to perform financial transaction online, the number of incidents involving unauthorized use (misuse) of an unsuspecting user’s credit card/debit card/bank account for fraudulent financial transactions has also increased.
[004] Typically, whenever a user (for example, a merchant or a customer) initiates a financial transaction on his internet enabled device (for example, a smart phone), sensitive information corresponding to the user including but not restricted to bank account number, username, transaction password is stored on the internet enabled device during the course of execution of the financial transaction. Since the sensitive information (corresponding to the user) is stored on the internet enabled device during the execution of the financial transaction, it is possible for an attacker to hack the internet enabled device and install a malware therein so that he could access the sensitive information stored in the internet device, and misuse the sensitive information at his leisure for performing fraudulent financial transactions.
[005] Typically, to clandestinely elicit sensitive information during the execution of a financial transaction involving a customer device and a merchant device, an attacker could hack the merchant device and install a malware therein, using which he could access the sensitive information that the merchant device receives (albeit in an encrypted format) from the customer device during the course of execution of a financial transaction. Alternatively, an attacked could clandestinely push a malware into the customer device via internet, and subsequently use the malware to access the sensitive information stored on the customer device and use the sensitive information thereafter to perform fraudulent financial transactions.
[006] Typically, a user (either a customer or a merchant) would not become aware of occurrence of a fraudulent financial transaction, until such a transaction is executed by the attacker. Even when the user recognizes the execution of a fraudulent transaction on his bank account either via a corresponding, compromised credit card/debit card/net banking account, the time lost on his part before he contacts the concerned authorities and blocks his credit card/debit card/internet banking account from any further use, could be used by an attacker for performing multiple (repetitive) fraudulent transactions.
[007] Further, if the device hacked by an attacker is a merchant device accessible to members of the public on a continuous basis (for example, Point-of-Sale device in a Petrol pump), then an attacker would have been able to elicit sensitive information corresponding to all the credit/debit cards that were swiped through the merchant device, until a user identifies the occurrence of a fraudulent transaction, reports it either to the merchant or the (user’s) bank, and blocks the compromised merchant device from further use.
[008] Moreover, in most of the incidents involving fraudulent financial transactions, the fraudulent nature of a financial transaction is identified (by either of the parties involved in the transaction) only after the fraud has been committed. Whenever a customer device/merchant device is attacked with malware with the intention of stealing sensitive information therefrom, such an attack would not be recognized by the customer/merchant, until sensitive information stolen from the customer device/merchant device through the malware, is used for executing fraudulent financial transactions.
[009] Therefore, in the view of the foregoing drawbacks, there was felt a need for a computer implemented system and method that detects fraudulent transaction in real-time, and without necessitating any inputs from any of the parties involved in a financial transaction. There was also felt a need for a computer implemented system and method that tracks financial transactions in real time and categorizes a financial transaction as fraudulent if the financial transaction bring about a deviation in predetermined hardware characteristics of the device on which it has been executed, and also terminates the execution of such a (fraudulent) financial transaction, thereby preventing the (fraudulent) financial transaction from culminating in unauthorized transfer/withdrawal/utilization of money.

OBJECTS
[010] An object of the present disclosure is to envisage a system and method that alert a merchant/customer, in real-time, about the occurrence/execution of a fraudulent financial transaction.
[011] Yet another object of the present disclosure is to absolve the merchant/customer of the responsibility of determining the authenticity of financial transactions.
[012] One more object of the present disclosure is to envisage a system and method that determines the authenticity of financial transactions with requiring any initiation from the parties/entities involved in the financial transaction.
[013] Still a further object of the present disclosure is to envisage a system and method that detects fraudulent financial transactions in real time without any human intervention.
[014] Yet another object of the present disclosure is to envisage a system and method that prevents reoccurrence of fraudulent financial transactions.
[015] Another object of the present disclosure is to envisage a system and method that provides for implementation of safe and secure online payment transactions.
[016] One more object of the present disclosure is to envisage a system and method that provides for fraudulent transactions to be detected in real-time on a merchant device as well as a customer device.
[017] Yet another object of the present disclosure is to envisage a system and method that classifies a financial transaction as a fraudulent transaction during the execution of such a transaction, and prevents such a transaction from being completed.

SUMMARY
[018] The present disclosure envisages a computer implemented method for detecting and subsequently preventing fraudulent financial transactions in real-time. The method and system envisaged by the present disclosure envisages detecting a fraudulent financial transaction executing either on a customer device or a merchant device in real time, and alerting the corresponding customer/merchant in real time and preventing the (fraudulent) financial transaction from being executed.
[019] The present disclosure envisages tracking the (hardware) characteristics of either the customer device or merchant device or both in real-time, to identify/detect any abnormalities therein, and subsequently use the identified/detected (hardware related) abnormality as a cue to validate the genuineness of a financial transaction being executed on either the customer device or merchant device or both.
[020] In accordance with the present disclosure, the hardware characteristics including (but not restricted to) the size of a primary storage sector (for example, hard drive space) and a secondary storage sector (preferably, a Random Access Memory sector) of at least one of the customer device and merchant device are monitored in real-time by a computer processor. The said real-time monitoring reveals the amount data storage space consumed by the primary storage sector and the RAM sector for executing a financial transaction.
[021] In accordance with the present disclosure, the data storage space consumed by the merchant device/customer device across the primary storage sector and RAM sector is tracked in real-time starting from the beginning of execution of the financial transaction. Subsequently, any changes/deviations in terms of the data storage space utilized for the execution of the financial transaction is also determined. Preferably, the information corresponding to the data storage space consumed by the merchant device/consumer device during the execution of a financial transaction, and the ‘historical values’ indicative of the ‘actual’ space to be utilized by the merchant device/consumer device during the execution of the financial transaction, are extracted (from the customer device/merchant device) in the form of metadata, and transmitted to a (computer) processor for processing/analyses.
[022] The method envisaged by the present disclosure involves comparing the values corresponding to the data storage space consumed by the merchant device/customer device across the primary storage sector and RAM sector with ‘historical values’ denoting the data storage space previously consumed/ought to be consumed during the execution of a genuine financial transaction.
[023] Subsequently, any unwarranted/unjustified deviations in terms of the data storage space being used across the primary storage sector and the RAM sector (of at least one of the customer device and merchant device) is identified in real-time by comparing the ‘historical values’ with the values denoting the amount of data storage space consumed during the execution of the financial transaction. In the event that any unwarranted/unjustified deviations are detected in terms of usage of data storage space (either on the merchant device or consumer device), the financial transaction which brought about such unwarranted/unjustified deviations is classified as a fraudulent transaction. Subsequently, the execution of the financial transition which has been termed fraudulent is terminated in real-time, irrespective of whether the merchant/customer raises a concern about the authenticity of the financial transaction.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
[024] The present disclosure will be better understood from the following detailed description, with reference to the accompanying drawings, in which:
[025] FIG.1 is a flowchart illustrating the steps involved in a method for detecting and preventing, in real-time, the execution of a fraudulent financial transaction on a merchant device; and
[026] FIG.2 is a block diagram illustrating the constituents of a system for detecting and preventing, in real-time, the execution of a fraudulent financial transaction on a merchant device.

DETAILED DESCRIPTION
[027] To obviate the drawbacks discussed in the ‘background’ section, the present disclosure envisages a computer implemented system and method for detecting the occurrence (execution) of a fraudulent financial transaction in real-time. The present disclosure also envisages preventing a financial transaction from being executed either on a merchant device or a customer device, as soon as the said transaction is determined to be a fraudulent financial transaction.
[028] Referring to the drawings, FIG.1 describes a flow chart illustrating the steps involved in the method for detecting and preventing, in real-time, the execution of a fraudulent financial transaction on a merchant device. At step 100 of the said method, a (computer) processor communicably coupled to the merchant device monitors the primary storage sector (for example, the ‘Internal Memory’ in case of a mobile phone and the ‘Hard Disk Drive in case of a computer) and the Random Access Memory (RAM) sector on a continuous basis, beginning with the initiation of a particular financial transaction and until the end of the said financial transaction.
[029] In accordance with the present disclosure, the processor cooperates with a repository preferably located on a remote server – both remote server and repository not shown in FIG.1 – to receive the ‘historical values’ indicating the actual amount of primary storage sector space and RAM space required (on the merchant device) for the execution of the financial transaction. The ‘historical values’ are preferably based on the amount of primary storage sector space and RAM sector space previously used up for the execution of the said financial transaction. Since a financial transaction is implemented using a computer readable instruction set preinstalled on the merchant device, the ‘historical values’ are typically based on the primary storage sector space and RAM space previously utilized by the said instruction set.
[030] In accordance with the present disclosure, any updates to the instruction set are required to be duly logged on to the repository, so that the ‘historical values’ indicating the actual amount of primary storage sector space and RAM space required (on the merchant device) for the execution of the financial transaction, are accordingly modified keeping in view the introduction of an update to the instruction set.
[031] Subsequently, at step 102, the processor determines the amount of data storage space utilized across the primary storage sector and the RAM sector for the execution of the financial transaction. Further, at step 104, the processor analyses the amount of data storage space utilized across the primary storage sector and the RAM sector for the execution of the financial transaction. The processor, in accordance with the present disclosure compares the amount of data storage space utilized across the primary storage sector and the RAM sector with the historical values indicative of the actual amount of primary storage sector space and RAM space required (on the merchant device) for the execution of the financial transaction.
[032] In accordance with the present disclosure, the execution of a financial transaction on a particular merchant device is controlled by a computer readable purpose-specific instruction set installed into the merchant device. Theoretically, since the architecture of the instruction set controlling the execution of the financial transaction on the merchant device would not change unless it is updated, it is inferred that for every financial transaction performed on the merchant device, the storage space required (across the primary storage sector and RAM sector) for storing the instruction set on the merchant device and the storage space required for executing the financial transaction would remain unchanged.
[033] In accordance with the present disclosure, the ‘historical value’ indicative of the actual amount of primary storage sector space previously utilized for storing the instruction set and executing a financial transaction using the instruction set is referred to as a ‘first threshold value’. Similarly, the ‘historical value’ indicative of the RAM sector space previously utilized for storing the instruction set and executing a financial transaction using the instruction set is referred to as a ‘second threshold value’.
[034] At step 106, the processor compares the amount of primary storage sector space consumed during the execution of the financial transaction using a predetermined instruction set, with the ‘first threshold value’ which indicates the actual amount of primary storage sector space previously consumed during the execution of the financial transaction using the same instruction set. Further, at step 106, the processor compares the amount of RAM space utilized for the execution of the financial transaction using the predetermined instruction set, with the ‘second threshold value’ indicative of the actual amount of RAM space previously consumed during the execution of the financial transaction using the same instruction set.
[035] At step 108, the processor categorizes a financial transaction as a fraudulent financial transaction only in the event that the amount of data storage space utilized across said primary storage sector and RAM sector for storing the predetermined instruction set and for executing the financial transaction increases beyond the first threshold value and the second threshold value respectively. In accordance with the present disclosure, since the architecture of the instruction set controlling the execution of the financial transaction on the merchant device would not change unless it is updated, for every financial transaction performed on the merchant device, the storage space required (across the primary storage sector and RAM sector) for storing the instruction set on the merchant device and the storage space required for executing the financial transaction should remain unchanged. But whenever the processor identifies such an increase in the amount of data storage space utilized across said primary storage sector and RAM sector (for storing the predetermined instruction set and for executing the financial transaction), it (the processor) relates such an increase (in the amount of data storage space utilized) to the presence of a malware within the instruction set, which in turn would have been introduced by an attacker to elicit sensitive information corresponding to the financial transaction executed on the merchant device. Further, at step 110, the processor notifies the merchant device in real-time about the categorization of a financial transaction under execution as a fraudulent financial transaction, and the subsequent termination of the fraudulent financial transaction.
[036] In accordance with the present disclosure, the processor also monitors a customer device that communicates with the merchant device during the execution of the financial transaction. A financial transaction is typically initiated by the customer device and is executed at the merchant device, with the customer device and the merchant device communicating with one another throughout the course of execution of the financial transaction. In accordance with the present disclosure, the processor cooperates with the repository (located on a remote server) to receive a ‘historical value’ indicative of the number of keystrokes required to be performed on the customer device to communicate with the merchant device and to initiate a financial transaction. Subsequently, when a user initiates the financial transaction, the processor monitors the number of keystrokes performed by the user, and subsequently compares the number of keystrokes performed by the user with the historical value (referred to as ‘third threshold value’ hereafter) indicative of the number of keystrokes required to be performed on the customer device to initiate the financial transaction.
[037] In accordance with the present disclosure, since the number of keys required to be pressed on the customer device to communicate with the merchant device and trigger the execution of a financial transaction remains unchanged for any number of financial transactions performed on the customer device (given that the customer device 28 executes the same instruction set for implementing all the financial transactions), any change in the number of keystrokes performed on the customer device, and preferably any increase in the number of keystrokes performed on the customer device denotes possible activation of a malware on the customer device by an attacker to elicit sensitive information corresponding to the financial transaction being initiated on the customer device.
[038] In accordance with the present disclosure, the processor compares the number of keystrokes performed on the customer device during the execution of the financial transaction, with the number of keystrokes (denoted by ‘third threshold value’) that are ideally required to be performed for communicating with the merchant device and triggering the execution of the financial transaction. If the processor identifies a difference between the actual number of keystrokes required (third threshold value) and the number of keystrokes performed on the customer device, the processor blocks the customer device from communicating with the merchant device and also prevents the customer device from initiating the financial transaction.
[039] In accordance with the present disclosure, if the processor identifies an increase in the number of keystrokes performed on the customer device for communicating with the merchant device and triggering the execution of the financial transaction, then the processor attributes such an increase in the number of keystrokes to the activation of a malware. Selectively, the processor might also infer that the customer device is being operated by an unauthorized user, possibly an attacker who intends to elicit sensitive information corresponding to the financial transaction being initiated from the customer device.
[040] In accordance with the present disclosure, the processor categorizes the financial transaction as a fraudulent financial transaction if the number of keystrokes performed on the consumer device exceeds the second threshold value, and the amount of data storage space utilized across said primary storage sector and RAM sector of the merchant device during the execution of said financial transaction increases beyond the first threshold value and the second threshold value respectively. Subsequently, the processor blocks the customer device from communicating with the merchant device and also prevents the customer device from initiating the financial transaction.
[041] In accordance with the present disclosure, the method further includes the step of creating a data file (based on a block chain protocol) which stores information corresponding to at least the amount of data storage space utilized across said primary storage sector and RAM sector utilized for the execution of said financial transaction, the number of keystrokes performed on said customer device, the first threshold value, and the second threshold value. The data file is preferably stored on the repository 24 located on the remote server 26.
[042] Referring to FIG.2, there is shown a block diagram illustrating the components of a computer implemented system for detecting and preventing, in real-time, execution of a fraudulent financial transaction on a merchant device. As shown in FIG.2, the computer implemented system 200 includes a (computer) processor communicably coupled to the merchant device 22. The processor 20 is configured to monitor the primary storage sector (for example, the ‘Internal Memory’ in case of a mobile phone and the ‘Hard Disk Drive in case of a computer) and the Random Access Memory (RAM) sector of the merchant device 22 on a continuous basis, beginning with the initiation of a particular financial transaction and until the end of the said financial transaction.
[043] In accordance with the present disclosure, the processor 20 cooperates with a repository 24 preferably located on a remote server 26 to receive the ‘historical values’ indicating the actual amount of primary storage sector space and RAM space required (on the merchant device) for the execution of the financial transaction. The ‘historical values’ are preferably based on the amount of primary storage sector space and RAM sector space previously used up for the execution of the said financial transaction. Since a financial transaction is implemented using a computer readable instruction set preinstalled on the merchant device, the ‘historical values’ are typically based on the primary storage sector space and RAM space previously utilized by the said instruction set. In accordance with the present disclosure, any updates to the instruction set are required to be duly logged on to the repository, so that the ‘historical values’ indicating the actual amount of primary storage sector space and RAM space required (on the merchant device) for the execution of the financial transaction, are accordingly modified keeping in view the introduction of an update to the instruction set.
[044] Subsequently, the processor 20 determines the amount of data storage space utilized across the primary storage sector and the RAM sector for the execution of the financial transaction. The processor 20, in accordance with the present disclosure compares the amount of data storage space utilized across the primary storage sector and the RAM sector with the historical values indicative of the actual amount of primary storage sector space and RAM space required (on the merchant device) for the execution of the financial transaction.
[045] In accordance with the present disclosure, the execution of a financial transaction on a particular merchant device is controlled by a computer readable purpose-specific instruction set installed into the merchant device. Theoretically, since the architecture of the instruction set controlling the execution of the financial transaction on the merchant device would not change unless it is updated, it is inferred that for every financial transaction performed on the merchant device, the storage space required (across the primary storage sector and RAM sector) for storing the instruction set on the merchant device and the storage space required for executing the financial transaction would remain unchanged.
[046] In accordance with the present disclosure, the ‘historical value’ indicative of the actual amount of primary storage sector space previously utilized for storing the instruction set and executing a financial transaction using the instruction set is referred to as a ‘first threshold value’. Similarly, the ‘historical value’ indicative of the RAM sector space previously utilized for storing the instruction set and executing a financial transaction using the instruction set is referred to as a ‘second threshold value’.
[047] The processor 20 compares the amount of primary storage sector space consumed during the execution of the financial transaction using a predetermined instruction set, with the ‘first threshold value’ which indicates the actual amount of primary storage sector space previously consumed during the execution of the financial transaction using the same instruction set. Further, at step 106, the processor compares the amount of RAM space utilized for the execution of the financial transaction using the predetermined instruction set, with the ‘second threshold value’ indicative of the actual amount of RAM space previously consumed during the execution of the financial transaction using the same instruction set.
[048] Further, the processor 20 categorizes a financial transaction as a fraudulent financial transaction only in the event that the amount of data storage space utilized across said primary storage sector and RAM sector for storing the predetermined instruction set and for executing the financial transaction increases beyond the first threshold value and the second threshold value respectively. In accordance with the present disclosure, since the architecture of the instruction set controlling the execution of the financial transaction on the merchant device would not change unless it is updated, for every financial transaction performed on the merchant device, the storage space required (across the primary storage sector and RAM sector) for storing the instruction set on the merchant device and the storage space required for executing the financial transaction should remain unchanged. But whenever the processor 20 identifies such an increase in the amount of data storage space utilized across said primary storage sector and RAM sector (for storing the predetermined instruction set and for executing the financial transaction), it (the processor 20) relates such an increase (in the amount of data storage space utilized) to the presence of a malware within the instruction set stored on the merchant device 22, which in turn would have been introduced by an attacker to elicit sensitive information corresponding to the financial transaction executed on the merchant device. Further, the processor 20 notifies the merchant device in real-time about the categorization of a financial transaction under execution as a fraudulent financial transaction, and the subsequent termination of the fraudulent financial transaction.
[049] In accordance with the present disclosure, the processor 20 also monitors the customer device 28 that communicates with the merchant device during the execution of the financial transaction. A financial transaction is typically initiated by the customer device 28 and is executed at the merchant device 22, with the customer device 28 and the merchant device 22 communicating with one another throughout the course of execution of the financial transaction. In accordance with the present disclosure, the processor 20 cooperates with the repository 24 (located on a remote server 26) to receive a ‘historical value’ indicative of the number of keystrokes required to be performed on the customer device 28 to communicate with the merchant device 22 and to initiate a financial transaction.
[050] Subsequently, when a user initiates the financial transaction, the processor 22 monitors the number of keystrokes performed by the user, and subsequently compares the number of keystrokes performed by the user with the historical value (referred to as ‘third threshold value’ hereafter) indicative of the number of keystrokes required to be performed on the customer device 28 to initiate the financial transaction.
[051] In accordance with the present disclosure, since the number of keys required to be pressed on the customer device to communicate with the merchant device and trigger the execution of a financial transaction remains unchanged for any number of financial transactions performed on the customer device 28 (given that the customer device 28 executes the same instruction set for implementing all the financial transactions), any change in the number of keystrokes performed on the customer device 28, and preferably any increase in the number of keystrokes performed on the customer device 28 denotes possible activation of a malware on the customer device 28 by an attacker to elicit sensitive information corresponding to the financial transaction being initiated on the customer device 28.
[052] In accordance with the present disclosure, the processor 22 compares the number of keystrokes performed on the customer device 28 during the execution of the financial transaction, with the number of keystrokes (denoted by ‘third threshold value’) that are ideally required to be performed for communicating with the merchant device 22 and triggering the execution of the financial transaction. In the event that the processor 20 identifies a difference between the actual number of keystrokes required (third threshold value) and the number of keystrokes performed on the customer device 28, the processor 20 subsequently blocks the customer device 28 from communicating with the merchant device and also prevents the customer device from initiating the financial transaction.
[053] In accordance with the present disclosure, if the processor 20 identifies an increase in the number of keystrokes performed on the customer device 28 for communicating with the merchant device and triggering the execution of the financial transaction, then the processor 20 attributes such an increase in the number of keystrokes to the activation of a malware. Selectively, the processor might also infer that the customer device 28 is being operated by an unauthorized user, possibly an attacker who intends to elicit sensitive information corresponding to the financial transaction being initiated from the customer device 28.
[054] In accordance with an embodiment of the present disclosure, the processor 20 categorizes the financial transaction as a fraudulent financial transaction if the number of keystrokes performed on the consumer device 28 exceeds the second threshold value, and the amount of data storage space utilized across said primary storage sector and RAM sector of the merchant device 22 during the execution of said financial transaction increases beyond the first threshold value and the second threshold value respectively. Subsequently, the processor 20 blocks the customer device 28 from communicating with the merchant device 22 and also prevents the customer device 28 from initiating the financial transaction.

TECHNICAL ADVANTAGES
[055] The technical advantages envisaged by the present disclosure include the realization of a system and method that alert a merchant/customer, in real-time, about the occurrence/execution of a fraudulent financial transaction. The present disclosure envisages a system/method that differentiates between genuine financial transactions and fraudulent financial transactions, without necessitating any human intervention, and solely based on analyses of predetermined hardware characteristics of devices involved in financial transactions. The present disclosure envisages detecting fraudulent financial transaction initiated at both the customer’s end (customer’s internet enabled electronic device) as well as at merchant’s end (merchant’s internet enabled electronic device), in real-time. The present disclosure envisages terminating a fraudulent financial transaction ahead of completion, while identifying the electronic device from where the fraudulent financial transaction was initiated, thereby preventing reuse of the identified electronic device for initiating repetitive fraudulent financial transactions.
[056] Further, the present disclosure envisages absolving the merchant and the customer (involved in a financial transaction) of the responsibility of determining the authenticity of the financial transaction, and envisions a system and method that automatically determines the authenticity of financial transactions without necessitating any initiation and inputs from the parties/entities involved in the financial transaction. Further, the system and method envisaged by the present disclosure categorically identifies the source of a fraudulent financial transaction, and intimates the corresponding merchant/customer about the occurrence of a fraudulent financial transaction on his electronic device, thereby preventing any possible inadvertent reoccurrence of fraudulent financial transactions. ,CLAIMS:1. A computer implemented method for detecting and preventing, in real-time, execution of a fraudulent financial transaction on a merchant device, said method comprising the following computer-implemented steps:
monitoring, by a processor, a primary storage sector and a Random Access Memory (RAM) sector embedded into said merchant device, and identifying data storage space utilized across said primary storage sector and RAM sector during the execution of a financial transaction;
collecting, by the processor, space usage data indicative of amount of the data storage space utilized across said primary storage sector and RAM sector during the execution of said financial transaction;
analysing, by the processor, said space usage data and evaluating the amount of data storage space utilized across said primary storage sector and RAM sector during the execution of said financial transaction;
categorizing, by the processor, said financial transaction as fraudulent financial transaction in real time and during the execution thereof, only in the event that the amount of data storage space utilized across said primary storage sector and RAM sector during the execution of said financial transaction increases beyond a predetermined first threshold value;
notifying said merchant device, in real time, about the occurrence of said fraudulent financial transaction, and triggering said merchant device to abort the execution of said fraudulent financial transaction.
2. The method as claimed in claim 1, wherein the method further includes the following steps:
selectively monitoring a customer device in communication with said merchant device during the execution of said financial transaction;
determining number of keystrokes performed on said customer device during the execution of said financial transaction;
comparing the number of keystrokes performed on said customer device during the execution of said financial transaction, with a predetermined second threshold value, and determining whether the number of keystrokes performed on said customer device exceeds the predetermined second threshold value;
categorizing said financial transaction as fraudulent financial transaction only in the event that the number of keystrokes performed on said customer device exceeds the second threshold value, and the amount of data storage space utilized across said primary storage sector and RAM sector of said merchant device during the execution of said financial transaction increases beyond the predetermined first threshold value and second threshold value respectively; and
blocking said customer device from communicating with said merchant device, and further blocking the execution of said fraudulent financial transaction.
3. The method as claimed in claim 1 or 2, wherein the method further includes the step of creating a data file based on a block chain protocol, said data file including information corresponding to at least the amount of data storage space utilized across said primary storage sector and RAM sector utilized for the execution of said financial transaction, the number of keystrokes performed on said customer device, the first threshold value, and the second threshold value.
4. A computer implemented system for detecting and preventing, in real-time, execution of a fraudulent financial transaction on a merchant device, said system comprising:
a processor, said processor communicably coupled to the merchant device, said processor configured to:
monitor a primary storage sector and a Random Access Memory (RAM) sector embedded into said merchant device, and identify data storage space utilized across said primary storage sector and RAM sector during the execution of a financial transaction;
collect space usage data indicative of amount of the data storage space utilized across said primary storage sector and RAM sector during the execution of said financial transaction;
analyse said space usage data and evaluate the amount of data storage space utilized across said primary storage sector and RAM sector during the execution of said financial transaction;
categorize said financial transaction as fraudulent financial transaction in real time and during the execution thereof, only in the event that the amount of data storage space utilized across said primary storage sector and RAM sector during the execution of said financial transaction increases beyond a predetermined first threshold value and a second threshold value respectively;
notify said merchant device, in real time, about the occurrence of said fraudulent financial transaction, and trigger said merchant device to abort the execution of said fraudulent financial transaction.
5. The system as claimed in claim 4, wherein the processor is further configured to:
selectively monitor a customer device communicating with said merchant device during the execution of said financial transaction;
determine number of keystrokes performed on said customer device during the execution of said financial transaction;
compare the number of keystrokes performed on said customer device during the execution of said financial transaction, with a predetermined second threshold value, and determine whether the number of keystrokes performed on said customer device exceeds the predetermined second threshold value;
categorize said financial transaction as fraudulent financial transaction only in the event that the number of keystrokes performed on said customer device exceeds the second threshold value, and the amount of data storage space utilized across said primary storage sector and RAM sector of said merchant device during the execution of said financial transaction increases beyond the first threshold value; and
block said customer device from communicating with said merchant device, and further abort the execution of said fraudulent financial transaction.
6. The system as claimed in claim 4 or 5, wherein the processor is further configured to create a data file based on a block chain protocol, said data file including information corresponding to at least the amount of data storage space utilized across said primary storage sector and RAM sector utilized for the execution of said financial transaction, the number of keystrokes performed on said customer device, the first threshold value, and the second threshold value.

Documents

Orders

Section Controller Decision Date
15 Shraddha Turkar 2020-10-28
15 Shraddha Turkar 2021-01-20

Application Documents

# Name Date
1 PROOF OF RIGHT [10-08-2016(online)].pdf 2016-08-10
2 Power of Attorney [10-08-2016(online)].pdf 2016-08-10
3 Form 5 [10-08-2016(online)].pdf 2016-08-10
4 Form 3 [10-08-2016(online)].pdf 2016-08-10
5 Drawing [10-08-2016(online)].pdf 2016-08-10
6 Description(Provisional) [10-08-2016(online)].pdf 2016-08-10
7 201641027384-RELEVANT DOCUMENTS [09-08-2017(online)].pdf 2017-08-09
8 201641027384-OTHERS [09-08-2017(online)].pdf 2017-08-09
9 201641027384-FORM FOR SMALL ENTITY [09-08-2017(online)].pdf 2017-08-09
10 201641027384-EVIDENCE FOR REGISTRATION UNDER SSI [09-08-2017(online)].pdf 2017-08-09
11 201641027384-Changing Name-Nationality-Address For Service [09-08-2017(online)].pdf 2017-08-09
12 201641027384-PostDating-(10-08-2017)-(E-6-142-2017-CHE).pdf 2017-08-10
13 201641027384-OnlinePostDating- [10-08-2017]- E-6-142-2017-CHE.pdf 2017-08-10
14 201641027384-APPLICATIONFORPOSTDATING [10-08-2017(online)].pdf 2017-08-10
15 Correspondence by Agent_General Power of Attorney_14-08-2017.pdf 2017-08-14
16 abstract 201641027384 .jpg 2017-08-17
17 201641027384-FORM 18 [10-11-2017(online)].pdf 2017-11-10
18 201641027384-DRAWING [10-11-2017(online)].pdf 2017-11-10
19 201641027384-CORRESPONDENCE-OTHERS [10-11-2017(online)].pdf 2017-11-10
20 201641027384-COMPLETE SPECIFICATION [10-11-2017(online)].pdf 2017-11-10
21 201641027384-FORM-9 [05-07-2018(online)].pdf 2018-07-05
22 201641027384-FORM 18A [05-07-2018(online)].pdf 2018-07-05
23 201641027384-FER.pdf 2019-04-18
24 201641027384-FORM 4(ii) [18-10-2019(online)].pdf 2019-10-18
25 201641027384-RELEVANT DOCUMENTS [15-11-2019(online)].pdf 2019-11-15
26 201641027384-OTHERS [15-11-2019(online)].pdf 2019-11-15
27 201641027384-MARKED COPIES OF AMENDEMENTS [15-11-2019(online)].pdf 2019-11-15
28 201641027384-FORM 13 [15-11-2019(online)].pdf 2019-11-15
29 201641027384-FER_SER_REPLY [15-11-2019(online)].pdf 2019-11-15
30 201641027384-DRAWING [15-11-2019(online)].pdf 2019-11-15
31 201641027384-CORRESPONDENCE [15-11-2019(online)].pdf 2019-11-15
32 201641027384-CLAIMS [15-11-2019(online)].pdf 2019-11-15
33 201641027384-AMMENDED DOCUMENTS [15-11-2019(online)].pdf 2019-11-15
34 201641027384-ABSTRACT [15-11-2019(online)].pdf 2019-11-15
35 201641027384-US(14)-HearingNotice-(HearingDate-07-08-2020).pdf 2020-07-06
36 201641027384-Written submissions and relevant documents [21-08-2020(online)].pdf 2020-08-21
37 201641027384-RELEVANT DOCUMENTS [21-08-2020(online)].pdf 2020-08-21
38 201641027384-RELEVANT DOCUMENTS [21-08-2020(online)]-1.pdf 2020-08-21
39 201641027384-PETITION UNDER RULE 137 [21-08-2020(online)].pdf 2020-08-21
40 201641027384-FORM 13 [21-08-2020(online)].pdf 2020-08-21
41 201641027384-Annexure [21-08-2020(online)].pdf 2020-08-21
42 201641027384-RELEVANT DOCUMENTS [25-08-2020(online)].pdf 2020-08-25
43 201641027384-PETITION UNDER RULE 137 [25-08-2020(online)].pdf 2020-08-25
44 201641027384-Written submissions and relevant documents [04-12-2020(online)].pdf 2020-12-04
45 201641027384-MARKED COPIES OF AMENDEMENTS [04-12-2020(online)].pdf 2020-12-04
46 201641027384-FORM 13 [04-12-2020(online)].pdf 2020-12-04
47 201641027384-AMMENDED DOCUMENTS [04-12-2020(online)].pdf 2020-12-04
48 201641027384-US(14)-HearingNotice-(HearingDate-17-11-2020).pdf 2021-10-17
49 201641027384-US(14)-ExtendedHearingNotice-(HearingDate-20-11-2020).pdf 2021-10-17

Search Strategy

1 201641027384_03-04-2019.pdf