Sign In to Follow Application
View All Documents & Correspondence

Method And System For Secure Transaction Processing

Abstract: System and method of secure transaction processing are described. System and method for enhancing the security during processing of electronic transactions without compromising sensitive user information are disclosed. One or more electronic tokens of limited value and validity can be generated and propagated to relevant payment gateways for authentication on behalf of a user payment means. Further restrictions can be customized and applied on the usage of the electronic tokens during an electronic transaction. Subsequendy the dynamically generated electronic tokens can be used in place of the actual payment means for effecting the payment in an electronic transaction.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
05 May 2008
Publication Number
46/2009
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
Parent Application

Applicants

NEWGEN SOFTWARE TECHNOLOGIES LIMITED
BROOKLYN BUSINESS CENTRE, 5TH FLOOR, EAST WING, 103-105 PERIYAR EVR ROAD, CHENNAI-600084, TAMIL NADU.

Inventors

1. MR. DIWAKAR NIGAM
BROOKLYN BUSINESS CENTRE, 5TH FLOOR, EAST WING, 103-105 PERIYAR EVR ROAD, CHENNAI-600084, TAMIL NADU.
2. MR. VIRENDER JEET, A CITIZEN OF INDIA
C/O NEWGEN SOFTWARE TECHNOLOGIES LIMITED, BROOKLYN BUSINESS CENTRE, 5TH FLOOR, EAST WING, 103-105 PERIYAR EVR ROAD, CHENNAI-600084, TAMIL NADU.

Specification

Method and system for secure transaction processing
Field of Invention
The present invention relates to a method and system for secure transaction processing over any public network such as the Internet, wireless network, or any other medium of non-secure communication without submission of user's private information. The present invention relates generally to the field of secure communications and secure transactions on the Internet.
Background of the Invention
International commerce and society at large have increasingly become more and more dependent on electronic transactions. Many attempts have been made to provide secure and convenient payment options for electronic transactions. Financial institutions of the day offer a plurality of services to their customers, which are implemented using electronic transactions. To conduct such transactions in the domain of e-commerce and m-commerce, payment cards such as credit cards, debit cards and other such financial cards have been widely in use. However, despite the flexibility and convenience offered by these means, there have been regular incidents that have resulted in setbacks to the use of such cards. It's not uncommon to find people completely averse to usage of such cards for financial transactions. The reasons are many and varied, the biggest and obvious being security, besides smaller issues such as complexity of use, inhibitions in shifting to a different transaction method, and so on. There is widespread concern about the safety of such transactions and recent news stories have uncovered widespread fraudulent activity associated with the use of traditional credit card numbers in e-commerce over

the Internet. In addition, there is growing concern about consumer privacy, or lack thereof, due to widespread electronic profiling of consumers engaging in electronic transactions.
According to a report, the cost of credit card fraud reaches into billions of dollars annually. In 2006, fraud in the United Kingdom alone was estimated at £428 million, or US $750-830 million at prevailing 2006 exchange rates. A study shows that an estimated 20 to 40 percent of online purchases are fraud attempts. In USA, credit card fraud was estimated to have accounted for losses in excess of $3 billion in 2007. Another statistic reveals that 300 million hours were spent in resolving issues related to identity theft in USA.
The prevalent method of using credit card to perform a transaction over die Internet is highly insecure. The method requires user to key in his credit card information, usually the credit card number and CW number (written at the back of the card), and Card Expiry Date in an online electronic form presented by the merchant from whom the user is purchasing the merchandise. Once the user enters the information, it is digitally signed and encrypted. For this, digital signatures and encryption algorithm such as RSA and DSA are used. The encrypted information travels over the Internet - a public network to which everyone has access — and reaches the merchant's end. The information further travels from merchant's end to the merchant's acquiring bank. The merchant bank's payment gateway decrypts the information and further sends an authentication request to card issuing bank/agency. The encryption/decryption is done using a pair of public/private key and digital certificate. Once tiie authorization is received, the merchant is notified of the validity of the card credentials and the customer is informed whether the transaction was successful. This makes the transaction complete.

It might appear that since the information travels in encrypted form, it is safe. However, the very fact that a public network like the Internet is being used to carry this information, presents a grave concern. Even if the card number is in an encrypted form, there is a significant risk that the information can be intercepted on the Internet and subsequently used with malicious intent. Also, multiple parties other than the cardholder are involved to make a transaction complete. These include merchant, merchant's acquiring bank and card-issuing bank. This, again, increases the risk of critical data being passed to an unknown entity.
Further, another major issue in the Internet age is Phishing. It is a form of online identity theft that employs techniques such as spoofed emails and spyware leading to counterfeit websites to steal consumers' personal identity data and financial account credentials by monitoring their activities online and otherwise.
The natural corollary to this problem would be to transmit information over a private network, accessible to only the trusted individuals. For practical purposes, a private network is highly cost intensive and infeasible to build to cater to only a few trusted participants. Yet another method to ensure complete uniqueness and security of data could be transmission of biometric data along with the transaction data for complete security. However, such a biometric-based authentication system involves prohibitive infrastructure costs. Moreover, these are difficult to implement and require purchase of additional hardware.

In view of the above, several systems and methods have been proposed in current times in order to facilitate secure and convenient modes of transaction and overcome drawbacks of the prevalent methods of transaction over a public domain such as the internet.
U.S. Patent 6990470 mentions using a pseudo account number having a pseudo expiration date to perform the transactions over the Internet, wherein per-card key is generated and associated with an account number as well as generation of message authentication code, converting the message authentication code into a pseudo expiration date; generating an authorization request for the transaction, the request having an expiration date field containing the pseudo expiration date; and verifying the message authentication code based on the pseudo expiration date.
Also, another U.S. Patent 5883810 describes an online commerce system that facilitates online commerce over a public network using an online commerce card. The card does not exist in physical form, but instead existing digital form. The issued online commerce card is assigned a permanent customer account number that is maintained on behalf of the customer at the issuing institution. When the customer desires to conduct an online transaction, the customer asks the issuing institution to issue a transaction number for a single transaction. The issuing institution generates a temporary transaction number and associates it with the permanent account number in a data record. The customer receives the transaction number and submits that number to the merchant as a proxy for the customer account number. The transaction number looks like a real card number and the merchant handles the transaction number in the same manner as any regular credit card number. When the merchant submits a request for authorization, the issuing institution recognizes

the number as a transaction number for an online commerce card. After due authorizations, an authorization reply is sent back to the merchant under the transaction number.
The method described in U.S. Patent 5883810 uses the concept of using a temporary transaction number, which is valid only for a short duration of time. However, it is still riddled with many deficiencies:
1. This method burdens the user with downloading the registration module to his/her computer, laptop, etc.
2. The method involves generation of a random number and associating that number with the permanent customer account number stored on the server. This approach might not be feasible, as it is extremely difficult to quickly propagate the newly generated random number across the payment gateway servers.
3. The method assumes that at any given time, a large number of transactions would be using real credit card numbers and only a fraction of all the transactions would be using temporary transaction numbers. However, this is an immature and unrealistic assumption as user would prefer to transact using the temporary number rather than supplying permanent credit card numbers.
4. In addition, the method proposes an approach wherein a PIN and additional software is physically sent to the cardholder. This would pose a substantial risk to the information, as postal systems do not guarantee the correct delivery of physical mails, as substantiated, over the years, by several instances of lost mails or mails delivered to incorrect addresses.
5. Also, there is a time delay before the physical mail containing the PIN reaches the cardholder rendering him helpless to execute a transaction for those many days. Lasly, the method restricts the cardholders' options to

initiate the transaction by proposing to put up a banner on bank's Website or in the electronic statement of the customer where the customer can click for initiating the transaction.
US Patent No. 7136835 discloses a credit card system, which provides additional limited-use credit card numbers and/or cards. These numbers and/or cards can be used for a single transaction, thereby reducing the potential for fraudulent reuse of these numbers and/or cards. Once a predefined number of limited use card numbers have been used, additional limited use numbers associated with the card are allocated automatically. The credit card system finds application to "card remote" transactions such as by phone or Internet. Additionally, when a single use credit card is used for "card present" transactions, so called "skimming" fraud is eliminated. Various other features enhance the credit card system, which will allow secure trade without the use of elaborate encryption techniques.
However, the method and system used in US Patent No. 7136835 are implemented by maintaining a common pool of card numbers from which a limited-use number is selected based on user request. The numbers in the pool are reused on exhaustion of all the numbers or a predefined amount of time, which might affect the security of the disclosed system. Further, the system and method of the disclosed invention is implemented by allocation of credit card numbers for online transactions and the use of disposable credit cards for card present transactions. The issue and delivery of the card numbers and disposable cards to the user is a lengthy and insecure process. Moreover, the user would be required to carry a large number of disposable cards for conducting 'card present' transactions, which proves quite cumbersome.

Hence, there is a need for a system and method that provides a secure means of transaction processing preferably using encryption means for additional security over a communication network. The system and method should be easy to use and implement with currendy available infrastructure. The system should not use payment card or other identifiable personal information of the user during the transaction. Particularly, the means of transaction should not be explicitly related to the payment card number or user details by any predefined relation that can be compromised. Further, the denomination and usage of the means of transaction should be customizable by the user. Still further, the system and method must be scalable to cater to a fairly large number of transactions in real time, without giving a feeling of a substantial time lag during execution of the transaction.
Objects and Summary of the Invention
The present invention has the objective to provide a more secure means of transaction by using electronic tokens instead of users' financial or personal information.
It is an objective of the present invention to generate one or more tokens of a predefined format associated with the user's payment means and using the same for transactions in place of payment card and user details.
It is also an objective of the present invention to generate customizable tokens of pre/user defined parameters such as value and duration and propagate the same to one or more payment gateways for associating with the user's payment means.

To achieve the aforementioned and other objectives obvious to a person skilled in the art, the present invention provides a method of secure transaction processing comprising the steps of:
- generating one or more token numbers of a predefined length;
- associating and storing the token numbers with the payment means and one or more parameters in a storage means;
- propagating the token numbers to one or more financial institutions for authorization; and
issuing at least one of the token numbers on request and customizing the
associated parameters; and
executing one or more electronic transactions using one or more of the
token numbers. The present invention further provides for a system for secure transaction processing using a user payment means comprising:
secure token number generation means to generate one or more token
numbers of a predefined length to be associated with the user payment
means;
- storage means coupled to secure token generation means to store information related to the token numbers, associated user payment means, one or more parameters associated with the token numbers, and transaction details;
- means to propagate the token numbers to one or more payment gateways;
means to convey the secure token numbers to the user;
- means to customize the token numbers and one or more parameters associated with the token numbers; and
- means to execute one or more electronic transactions using at least one of the token numbers.

Brief Description of Drawings
The detailed description is described with reference to die accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
Figure 1 illustrates an exemplar)' system for providing a secure means of transaction as disclosed by the present invention.
Figure 2 illustrates a flow diagram of an exemplary method for providing a secure means of transaction as disclosed by the present invention.
Figure 3 illustrates a flow diagram of an exemplary method for conducting an online credit card transaction as disclosed by the present invention.
Figure 4 is illustrates a flow diagram of an exemplary method of processing a transaction in accordance with the present invention at a financial institution such as a bank's end.
Detailed Description of the Invention
Systems and methods for secure means of transaction processing are described. The system and methods are not intended to be restricted to any particular form or arrangement, or any specific embodiment, or any specific use, disclosed herein, since the same may be modified in various particulars or relations without departing from the spirit or scope of the claimed invention hereinabove shown and described of which the apparatus or method shown is

intended only for illustration and disclosure of an operative embodiment and not to show all of the various forms or modifications in which this invention might be embodied or operated.
The present invention facilitates a more secure means of transaction processing by obtaining the functionality of a payment means such a as payment card without ever revealing the user's payment card number during an electronic transaction. In an embodiment, the user can request for the generation of one or more electronic tokens of a pre/user determined value and valid for a limited time using one or more interfaces of the system of the instant invention disclosed herein below. One or more of the generated tokens with unique numbers may be provided by the cardholder for payment during electronic transactions in place of the payment card details.
To this end, the system and method of the present invention include means to generate a set of random numbers (henceforth called electronic tokens) to be associated with a user's payment means such as a payment card. Subsequently the electronic tokens can be propagated to VISA/MasterCard/Cirrus global payment gateway servers in order to validate the electronic tokens as valid card numbers during an electronic transaction. Further, constraints on usage of these tokens can be predefined by the system and/or user. The value and validity period of the tokens can be defined. In some embodiments, usage of the electronic tokens may be restricted to specific transaction types and values. In one approach, the user can append predetermined digits at predetermined locations of the generated number to arrive at a valid electronic token number. In yet another approach, the security of the transaction can be enhanced by issuing two or more token numbers to the user who can select one as the valid token number while the other is invalidated. The electronic tokens along with

the associated constraints and essential user identification details can be saved in a secure card number database. When the user logs in and requests for generation of a new token numbers, a number can be taken from this existing set of electronic tokens and sent to the user, giving the impression that a new electronic token is generated. Pre-generating a set of token numbers to be associated with one or more of a particular user's payment means facilitates faster transaction processing by the payment gateways. Once a predefined number of generated electronic tokens associated with a user's payment means have been used, a new set of numbers can be generated, associated with the user's payment means and propagated to VISA/MasterCard/Cirrus global payment gateway servers to be acknowledged as valid card numbers during electronic transactions.
An exemplary implementation of the system and method of the present invention is discussed in the following section with respect to the accompanying figures.
Fig. 1 illustrates an exemplary system 100 to provide a more secure means of transaction processing by using electronic tokens. According to an embodiment, exemplary system 100 can include an issuer transaction server 102, communicatively coupled to one or more user transaction devices 104 through one or more network interfaces 106 and one or more payment gateways 108. In some embodiments, issuer transaction server 102 can be the transaction server of an issuing bank. Network interfaces 106 can facilitate coupling of issuer transaction server 102 with user transaction system 104 through one or more wired or wireless communication networks. Issuer transaction server 102 and user transaction device 104 may further be

communicatively coupled to one or more payment gateways 108 such as VISA, MasterCard and Cirrus Global for facilitating electronic transaction processing.
User transaction device 104 can be configured as a merchant POS terminal, ATM, personal computer, laptop, personal digital assistant, wireless communications devices, or any hand-held device. User transaction device 104 can provide the user with an interface to request for generation of electronic tokens by the issuer transaction server 102. User transaction device 104 can be further coupled to one or more I/O interfaces 116. I/O interfaces 116 can provide input output capabilities for user transaction device 104. I/O interfaces 116 can include one or more ports for connecting a plurality of input devices such as card swipe readers, keypads and biometric input devices. I/O interfaces 116 can also include ports to couple output devices such as printers and display screens, converters and so on with user transaction device 104.
Issuer transaction server 102 can further include one or more transaction databases 110, secure electronic token generator 112 and secure electronic token database 114. Transactions database 110 preferably includes relevant information regarding users and associated payment means. Transactions database 110 can also include information required by the payment means issuing authority for each transaction made by a user, including merchant and order details, received billing and payment details and so on. Transaction database 110 can facilitate generation of statement of accounts for the users.
Secure electronic token generator 112 can include means to generate lists of random numbers/electronic tokens of a predetermined length to be used in place of the user payment means during an electronic transaction. Secure electronic token generator 112 can include encoded operational instructions for

generation of random numbers. In one approach, secure electronic token generator 112 may generate random seed values by using physically random signals such as white noise. To this effect, secure electronic token generator 112 may also include means to convert the random analog signals to digital values for seeding the random number generation. In alternate embodiments, secure electronic token generator 112 can generate electronic tokens to be used in lieu of a user's payment means details based on the operational instructions and pre/user defined restrictions stored in the secure electronic database 114.
Secure electronic token database 114 can store the list of token numbers generated by secure electronic token generator 112 and associated details. The associated details can include the specific user for whom the token numbers have been generated, specific restrictions in terms of transaction type, value, validity period or a combination thereof provided they do not exceed die restrictions placed upon the user's account (such as credit balance). It would be appreciated by a person skilled in the art that other predefined and/or user defined restrictions can be associated with the transactions using the generated token numbers. Secure electronic token database 114 can further store operational instructions to be executed by secure electronic token generator 112 in order to generate random numbers of a predetermined length based on specific pre/user-defined conditions.
In an embodiment, when a new user account is opened, Issuer transaction server 102 can direct secure electronic token generator 112 to generate a predetermined number of electronic tokens to be used in place of the user payment means in electronic transactions. Based on encoded and/or predefined restrictions stored in secure electronic token database 114, one or more electronic tokens can be generated. The generated token numbers are

associated with the user's payment means and associated restrictions can be stored in the secure electronic token database 114. The generated token numbers can be propagated to one or more payment gateways servers 108 servers to be acknowledged as valid user card number in place of the original payment means during electronic transactions. A user can request for generation of electronic tokens through user transaction device 104. Subsequent to user request, one or more token numbers associated with user payment means can be retrieved from the secure electronic database 114 and be provided to the user to be used in electronic transactions. The user can have the provision to customize other associated parameters of the issued token numbers subsequently. In a preferred approach, the user can append predetermined digits at predetermined locations of the received token number using I/O interfaces 116 to arrive at a valid electronic token number. In another embodiment, the security of the transaction can be enhanced by issuing two or more token numbers to the user who can select one as the valid token number while the others are invalidated. An alert can be sent to secure electronic token generator 112 to generate a predefined number of tokens when a predefined number of electronic tokens have been used by the user.
Figures 2-4 illustrate an exemplary method of implementing the present invention as described herein below. The exemplary method is represented as a collection of blocks in a logical flow graph, which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. The order in which the process is described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order to implement the process, or an alternate process. Additionally, individual blocks may be deleted from the process without departing from the spirit and scope of the subject matter described herein. For

the purposes of description the method of the present invention is disclosed in terms of transactions relating to customer's credit card account. It would be appreciated by a person skilled in the art that it is possible to implement the disclosed method and system of the invention to other environments used for effecting of electronic transactions.
Figure 2 describes an exemplary method for providing a secure means of transaction as disclosed by the present invention. At 202, a user can log into his/her bank account using an interface associated with a user transaction system as described above. The user interface can provide the user with a plurality of options such as requesting for token numbers, customizing restrictions on the usage of token numbers along with other transactional services as provided by the user's bank/issuer transaction server. At 204, the user can request one or more electronic token numbers. At 206, the transaction server at the user's bank issues one or more token numbers to the user. At 208, the user after optionally customi2ing the associated parameters of the token number submits the issued token number for making the purchase at a merchant transaction device. In an embodiment, the merchant transaction device can be a merchant's website accessed through the user transaction device such a personal computer. In other embodiments, merchant transaction device can be a POS terminal, ATM, laptop, personal digital assistant, wireless communications devices, or any hand-held device capable of connecting to the Internet or other such network and effecting transactions. The value and validity of the token number is verified along with the pre/user defined restrictions. Subsequent to positive authentication of the user and authorization of the transaction amount, at 210, the transaction is completed.

Figure 3 illustrates a flow of execution of an exemplary method for conducting an online credit card transaction using the electronic token number. At 302, a customer logs into the website of an issuing bank and accesses his account, The customer requests for issue of electronic tokens to be used on behalf of his credit card number by selecting the relevant option available on the website. The customer can further customize one or more parameters associated with the issued token number such as validity, lengtii, duration, transaction type and so on. At 304, the customer logs into a merchant website to conduct an electronic transaction supplying the token number in place of his credit card number for making an online purchase. At 306, the token number is sent to the merchant server, which forwards it to the merchant's bank. At 308, the merchant bank sends the token number to the customer's bank for authorizing the transaction. At 310, the customer bank/ issuer transaction server verifies the token number as being associated with a valid card number. Further, the associated restrictions are verified and an acknowledgement is sent to the merchant server for authorizing the transaction. At 312, the customer receives confirmation from the merchant server in respect of successful transaction. In case the verification at the customer's bank is negative owing to invalid token or violation of associated restrictions, the customer receives a message in respect of transaction failure. Thus the online credit card transaction is effected securely without compromising the credit card details or the use's personal details during an electronic transaction.
Figure 4 illustrates a flow diagram describing an exemplary method of implementing the method of the present invention for effecting a secure electronic credit card transaction. At 402, customer can open a new credit card account with a credit card issuing organization or an issuer bank.

At 404, subsequent to opening of a new customer account, a predefined number of electronic tokens can be generated by the token generation means coupled to issuing bank's transaction server. The generated token numbers and the predefined restrictions to be applied during electronic transactions are associated with the user's credit card number in the database of the issuing bank.
A preferred approach to further secure a 16-digit electronic token to be used as the temporary transaction number can be to generate a token number of a predefined length, say, a 14-digit number with the two missing digits being added by the customer at predefined positions to make a complete 16-digit transaction number. In some embodiments, the added digits can be predefined such as the initial two digits appearing on the customer's credit card or the first two digits of the CVY number of the card and so on. This enhances the security of the number during propagation from the bank to the customer. Therefore, even if the 14-digit number is intercepted by an eavesdropper, he still has to guess the two missing digits in order to discover the complete temporary transaction number. The level of security can be further enhanced by reducing the length of the issued number, while increasing the length of the number to be appended by the customer.
At 406, the generated numbers can be propagated to one or more payment gateways such as VISA/MasterCard/Cirrus global payment gateway servers to be acknowledged as valid card numbers associated to the user's credit card account during electronic transactions. The format of the generated numbers can be similar to credit card numbers and since the original card number is never revealed, the disclosed method imparts greater security during electronic transactions.

At 408, the customer can request for electronic tokens to be issued in lieu of his credit card number. To this effect, one or more user input means coupled to user devices such as a website or merchant POS terminal, ATM, personal computer, laptop, personal digital assistant, wireless communications devices, or any hand-held device can be used. Options for requesting for electronic tokens and customizing the restrictions to be applied to the usage of the tokens can be selected/inputted using the interfaces coupled to the user device. Further, the disclosed system of the present invention provides means to customize the validity and value of the generated tokens. Other restrictions on usage and transaction categories can also be customized. This user customization feature of the present invention facilitates the user to have complete control over the use of his credit card account. The disclosed method offers complete flexibility to the user in terms of deciding the duration validity and value validity of the electronic token number. Since the generated token will have limited validity, ranging from a predefined number of seconds to a predefined number of days, and limited value, the loss incurred incase the number is compromised will be minimal. In an embodiment, user can verify the duration and value validity using an additional step during a transaction. This shall prevent an unauthorized interceptor of information from altering the validity of the electronic token
At 410, the generated numbers are dispatched to the user. The token numbers can be sent to the user through output means coupled to user device. The numbers may be encrypted during transit to prevent misuse in case it falls into the hands of an unauthorized person. In another embodiment, two or more temporary transaction numbers can be issued by the bank at a predefined time interval. The customer may choose any one for the transaction which would

automatically invalidate the other generated numbers. In an alternative approach, the second number can be a valid number, while the first number would be an invalid number issued in order to fool eavesdroppers. Further, if the transaction number verification request has already been received once, the second request can be immediately turned down as a fraud request.
At 412, a user uses at least one of the generated token numbers to conduct an electronic transaction. The token numbers are forwarded by the merchant bank to the issuing bank's transaction server for authentication and authorization of the transaction. The issuing bank's transaction server authenticates the user and verifies that the token number is indeed a valid token number to be used in lieu of user's credit card number. Further, the value and validity of the token number verified and checked against the value of die transaction for authorization. One or more other user defined restrictions such as that on the allowable transaction types, value and duration validity are verified. Subsequent to positive verification of all parameters associated with the transaction, the transaction is authorized and a acknowledgement is sent to the merchant and/or user. Still further, the status of the generated tokens associated witii the user credit card account is updated along with other parameters of the user's credit card account.
At 414, once a predefined number of electronic tokens have been used by the user, the issuing bank transaction server is alerted. The issuing bank server then initiates generation of a predetermined number of tokens to replenish the list of token numbers to be used in place of a particular user's credit card number in electronic transactions. Further, the numbers are associated with the user's credit card account and existing restrictions if any. The duration, value and

associated restrictions on the generated electronic tokens can be subsequently customized by the user.
The disclosed system of the present invention does not require any additional investments in the form of extra hardware or expensive software for users, merchants, merchant's acquisition bank, and card-issuing bank. The system works within the established infrastructure of worldwide payment systems, thereby making it extremely convenient for consumers as well as merchants to transact in the existing manner. The system works well with established cryptographic standards such as DKS used in bank transaction systems. Further, the customer does not have to remember/save records of each o( his transactions to be verified against his monthly statement as every transaction is verified immediately and the user can be notified of the same. Another major advantage of die present invention is that phishing on the Internet can be totally avoided since a phishing website will not be able to generate valid tokens. Therefore, transactions would not be executed, and in case there is a large frequency of invalid token numbers being reported, the issuing bank transaction server can be alerted to suspend order execution to detect the source of invalid token numbers. Thus electronic transactions can be conducted in utmost security and convenience.
The embodiments described above and illustrated in die figures are presented by way of example only and are not intended as a limitation upon the concepts and principles of the present invention. As such, it will be appreciated by one having ordinary skill in the art that various changes in the elements and their configuration and arrangement are possible without departing from the spirit and scope of the present invention as set forth in the appended claims.

It will readily be appreciated by those skilled in the art that the present invention is not limited to the specific embodiments shown herein. Thus variations may be made within the scope and spirit of the accompanying claims without sacrificing the principal advantages of the invention.
We claim:
1. A method of secure transaction processing using a user payment means comprising the steps of:
- generating one or more token numbers of a predefined length; associating and storing the token numbers with the payment means and one or more parameters in a storage means;
- propagating the token numbers to one or more financial institutions for authorization; and
issuing at least one of the token numbers on request and customizing the associated parameters; and
executing one or more electronic transactions using one or more of the token numbers.
2. The method as claimed in claim 1, wherein the parameters include duration validity of the token numbers, value validity of the token numbers and transaction information.
3. The method as claimed in claim 1, wherein the step of executing includes inserting one or more predefined digits to at least one of the token numbers at one or more predefined positions.
4. The method as claimed in claim 1, wherein the step of issuing comprises the step of choosing at least one token number from two or more of the

issued token numbers for executing the transaction wherein the token numbers not chosen are invalidated.
5. The method as claimed in claim 1, wherein the step of executing comprises the step of notifying the user and financial institution that the token number has been used in a transaction.
6. The method as claimed in claim 1, wherein the step of executing comprises the step of authorizing the transaction using at least one of the token numbers based on the parameters associated with the token numbers and the payment means.
7. The method as claimed in claim 1 or claim 6 comprising the step of generating one or more token numbers of a predefined length when a predefined number of token numbers associated with the payment means have been used.
8. A system for secure transaction processing using a user payment means comprising:
- secure token number generation means to generate one or more token numbers of a predefined length to be associated with the user payment means;
storage means coupled to secure token generation means to store information related to the token numbers, associated user payment means, one or more parameters associated with the token numbers, and transaction details;
means to propagate the token numbers to one or more payment gateways;

- means to convey the secure token numbers to the user;
means to customize the token numbers and one or more parameters associated with the token numbers; and
- means to execute one or more electronic transactions using at least one
of the token numbers.
9. The system as claimed in claim 8, wherein storage means includes
operational instructions for generating the secure token numbers by
secure token number generation means.
10. The system as claimed in claim 8 further comprising means to send an
alert to secure token number generation means to generate one or more
tokens to be associated with the user payment means when a predefined
number of token numbers associated with the payment means have been
used.
11. The system as claimed in claim 8, wherein the input means includes means
to insert one or more predefined digits to at least one of the token
numbers at one or more predefined positions.
12. A computer program product for secure transaction processing,
comprising one or more computer readable media configured to perform
the method as claimed in any of the claims 1-7.

Documents

Orders

Section Controller Decision Date

Application Documents

# Name Date
1 1099-CHE-2008 FORM-18 14-10-2010.pdf 2010-10-14
1 1099-CHE-2008-PETITION UNDER RULE 137 [09-10-2019(online)].pdf 2019-10-09
2 1099-che-2008 form-3.pdf 2011-09-03
2 1099-CHE-2008-Written submissions and relevant documents (MANDATORY) [09-10-2019(online)].pdf 2019-10-09
3 1099-CHE-2008-HearingNoticeLetter26-09-2019.pdf 2019-09-26
3 1099-che-2008 form-1.pdf 2011-09-03
4 1099-CHE-2008-FORM 13 [23-09-2019(online)].pdf 2019-09-23
4 1099-che-2008 drawings.pdf 2011-09-03
5 1099-CHE-2008-FORM-26 [23-09-2019(online)].pdf 2019-09-23
5 1099-che-2008 description-complete.pdf 2011-09-03
6 Abstract [09-05-2017(online)].pdf 2017-05-09
6 1099-che-2008 correspondences-others.pdf 2011-09-03
7 Claims [09-05-2017(online)].pdf 2017-05-09
7 1099-che-2008 claims.pdf 2011-09-03
8 Description(Complete) [09-05-2017(online)].pdf 2017-05-09
8 1099-che-2008 abstract.pdf 2011-09-03
9 1099-CHE-2008-FER.pdf 2016-11-28
9 Description(Complete) [09-05-2017(online)].pdf_529.pdf 2017-05-09
10 Examination Report Reply Recieved [09-05-2017(online)].pdf 2017-05-09
10 Other Document [09-05-2017(online)].pdf 2017-05-09
11 Examination Report Reply Recieved [09-05-2017(online)].pdf 2017-05-09
11 Other Document [09-05-2017(online)].pdf 2017-05-09
12 1099-CHE-2008-FER.pdf 2016-11-28
12 Description(Complete) [09-05-2017(online)].pdf_529.pdf 2017-05-09
13 1099-che-2008 abstract.pdf 2011-09-03
13 Description(Complete) [09-05-2017(online)].pdf 2017-05-09
14 1099-che-2008 claims.pdf 2011-09-03
14 Claims [09-05-2017(online)].pdf 2017-05-09
15 1099-che-2008 correspondences-others.pdf 2011-09-03
15 Abstract [09-05-2017(online)].pdf 2017-05-09
16 1099-che-2008 description-complete.pdf 2011-09-03
16 1099-CHE-2008-FORM-26 [23-09-2019(online)].pdf 2019-09-23
17 1099-che-2008 drawings.pdf 2011-09-03
17 1099-CHE-2008-FORM 13 [23-09-2019(online)].pdf 2019-09-23
18 1099-CHE-2008-HearingNoticeLetter26-09-2019.pdf 2019-09-26
18 1099-che-2008 form-1.pdf 2011-09-03
19 1099-CHE-2008-Written submissions and relevant documents (MANDATORY) [09-10-2019(online)].pdf 2019-10-09
19 1099-che-2008 form-3.pdf 2011-09-03
20 1099-CHE-2008-PETITION UNDER RULE 137 [09-10-2019(online)].pdf 2019-10-09
20 1099-CHE-2008 FORM-18 14-10-2010.pdf 2010-10-14

Search Strategy

1 searctst_25-10-2016.pdf