METHOD AND SYSTEM TO AUTHENTICATE USER IDENTITY

FIELD OF INVENTION

The present invention relates to a novel method and system for authentication of an identity of a user. More particularly, the present invention discloses a method and system for authentication of the identity of a user using a portable device, without providing the login information of the user.

BACKGROUND OF INVENTION

Currently users are authenticated on networked interfaces and devices using a combination of different digital data, either memorized by the user or stored on devices and/or magnetic card(s) possessed by the user. The personal identification is established by the knowledge and trust that each user has a unique combination of this data.

The service authenticating a user on its interfaces is unable to tell if the user validating is the original user intended or an impostor who has managed to steal the original user's credentials. User credentials could be anything from Login IDs, Passwords, Electronic Cards, etc. Also the original user is too late in identifying the breach of his identity on a network or service until he has discovered that a malicious intent has been successful thus causing him/her damages of varying degrees.

In banking and electronic payment sector user authentication systems play a key role in order to ensure secure transactions. Due to the advancement of electronic cards and ATM machines user may avoid carrying money in physical form without interrupting his/her financial requirements. People have option to make payments through swiping their cards in shopping complexes or fetching money and performing several other activities through ATM machines. Due to ease in transactions, use of magnetic cards and use of ATM machines has become very popular and become usual part of life. Hence the user may always require secured transactions in order to avoid any unauthorized use of their cards or Identity credentials.

In addition, there is increase in the need and trend of having se eral accounts by the users and carrying several credit card and debit cards for various purposes. Therefore users may face inconvenience of carrying various personal identity authentication means such as magnetic cards like credit and debit cards. In addition, a user has to remember other authentication details such as passwords and other authentication credential. Users often face difficulty in recalling password and authentication credentials of their various accounts. Therefore many users might and do store such credentials in an unsecured place by which they unknowingly compromise with security.

Some other banking and payment systems have evolved in near past to provide further ease to user and to free the user from carrying physical transaction media such as secured internet banking systems or online payment systems. These systems enable the user to make financial transaction by providing user identity credential to a secured server through internet enable and server compatible device. The system requires a unique alpha-numeric user name and password and other identity credentials of the users. In these systems, user is often burdened with the liability to maintain the confidentiality of his identity credentials. In addition, many a times user has to maintain several accounts at the same time. Therefore there is always risk associated with making payments through devices owned by other person as the authentication credentials of the user may get saved or stolen or hacked by any existing means and afterwards misused by unauthorized user. Online transactions are so quick that if misused by any unauthorized users it may be difficult to track them as well as not possible to recover the loss occurred.

The major problem associated with the above mentioned systems is the difficulty faced by the users to handle .several accounts, remember authentication credentials and maintain confidentiality at the same time.

These several problems associated with the existing systems that are needed to be looked and corrected in order to provide highly secured and easy to handle electronic authentication systems. Therefore, there is immense need of a simplified and unified system which may overcome the above mentioned problems and provide a highly secured and easy to operate authentication system.

SUMMARY OF THE INVENTION

To achieve the abovementioned advantages, and overcome the disadvantages, there - is provided in accordance with the disclosure, a method and a system for providing authentication to the identity of a user by using a portable device, without feeding in the user identification credentials in the server. BRIEF DESCRIPTION OF THE FIGURES:

Figure 1 shows a flowchart giving the flow of information between the different components of a system.

Figure 2 shows the components of the device of the system.

Figure 3 shows the components of the Web-service of the system.

Figure 4 shows the components of the Validation-server of the system.

Figure 5: depicts the registration process of the User (101) and the Device (105) with the Validation-server (104) through the Appliation (105 A 2)

Figure 6: depicts the Pre-Signup process or registration of the Web-service (103) with the Validation-server (103)

Figure 7: depicts the process of User (101) Siginup/registration for the first time with the Web-service (103) through the Application (105 A 2)

Figure 8: depicts the process by which already registered/logged in User (101) with the Web- service (103) activates the services of the Web-service (103) through the Application (105 A

2) -

Figure 9: depicts the Post-registration process of the User (101) with Web-service (103) or Post-Activation process of the Web-service (103)

Figure 10: depicts the process for User (101) Login to the Web-service (103) for user authentication through the Application (105 A 2)

DETAILED DESCRIPTION OF THE INVENTION

The detailed description set forth below in connection with the appended drawings is intended as a description of various embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The_ detailed description includes specific details for the purpose of providing a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the present invention.

One or more embodiments of the present invention will now be described. Fig. 1 illustrates a System (100) which includes a User (101), at least two Information exchanging units (102 A and 102 B), a Web-service (103), a Validation-server (104) and a Device (105) having a platform (015 A 1) to run an Application (105 A 2). The Information exchanging units (102 A and 102 B), the Validation-server (104) and the Web-service (103) may be connected with each other through a communication channel.

The System (100) as described in Figure 1 enables the User (101) to perform user authentication. The Device (105) may be connected with the Web-service (103) and Validation-server (104) through the communication channel. The communication channel may be selected from a network connection such as but not limited to internet, intra-net, LAN, WAN, wireless connectivity and wired communication channel such as but not limited to Internet, Intranet and Extranet. For example the network connection such as Local Area Networks (LAN), Dial Up Connection, Broadband Access like multilink dial-up, integrated services digital network, leased lines, cable internet access, digital subscriber line (DSL, ADSL, SDSL and VDSL), DSL rings, power-line internet, ATM and frame relay and Wireless Broadband access like Wi-Fi, WiMAX, Satellite broadband, Mobile broadband and Local Multipoint Distribution Service.

The Device (105) communicates with the Validation server (104) and the web server (103) through the network connection with the help of at least two Information exchanging unit (102 A or 102 B), wherein at least one Information exchanging unit (102 A) is connected with the Device (105) adapted to exchange an Information (106) by means of an Application (105 A) and is capable of interacting with the another Information exchanging unit (102 B) containing a static or dynamic Information as provided or generated by the Web-service (103).

The Information exchanging unit (102 A) may be capable of receiving, decoding, exchanging, storing, displaying, transmitting or discharging the information communicated by the Information exchanging unit (102 B). The Information exchanging unit (102 A) of the Device is selected from group comprising an Image capturing device, Image sensing device, Bar code reader, Bar code scanner, Magnetic sensors, Near field communication device, Image sensing device, Biometric sensing device^ Radio frequency identification device, Optical information reader, Digital information reader and other like units capable of receiving, decoding or/and transferring the information through contact or without contact with another unit capable of transferring, displaying, encoding and/or receiving the information.

The Information exchanging unit (102 B) of the Web-service (103) is an Information containing medium capable of expressing, displaying, encoding, transferring, exchanging, transmitting or discharging the Information (106). The Information containing medium (102 B) contains or displays the Information which may be received by the Information exchanging unit (102 B) and transferred to the Device (105). The Information containing medium (102 B 1) is selected from group comprising a paper medium, plastic medium, metal medium, electronic display medium, magnetic medium, sound or signal transmitting medium and other like medium encoded with the Information (106) or capable of transmitting the Information (106).

The Information (106) may be a machine readable Information, preferably the machine readable information is selected from group comprising a digital code, visual representation, electric signal, alphanumeric code, numeric code, bar code, multi-dimensional barcode, multiple bar code, infrared signal, sound wave, radio frequency, magnetic signal and other like machine readable information. The Information (106) may be static or dynamic in nature.

The Device (105) as shown in Figure 2 comprises a Platform (105 A 1) to run the Application (105 A 2), a Platform (105 B) to connect with the Information exchanging unit (102 A), a Display unit (105 C) to display/receive/transmit/convey the input or output generated or received by the Device (105) to the User (101), a Storage medium (105 D) to store, retrieve, record or process the input or output generated or received by the Device (105) and other Conventional Application (105 E). The Application (105 A 2) may be installed in the Device (105) through the Platform (105 A 1) and enables the Device (105) or User (101) to communicate with the Validation-server (104) and the Web-service (103) through the communication channel. The Information exchanging unit (102 A) is connected with the device through the Platform (105 B) of the Device (105). The Information exchanging unit (102 A) may be connected internally or externally with the Platform (105 B). The Display Unit (105 C) enables the User (101) to visualize/hear/receive the input/output operations performed on the Application (105 A 2) in an appropriate format such as in a visual, audio, perceptions or sensory formats The Display Unit (105 C) may be a communication element such as a screen or visual display unit such as a CRT (Cathode Ray Tube), LCD (Liquid crystal displays), LED Display (Light- Emitting Diode), Plasma displays and other like conventional display units or such as an audio visual or audio units or perception units. The Platform (105 A) to run the Application (105 A 2) may be an operating system, such as a mobile operating system for example Android, Bada, IOS, S40, Windows Phone, iPhone OS and other conventional OS as required to run the Application (105 A 1) or other applications compatible to the Device (105). The Device (105) may further comprise drivers and hardware as supporting components in order to run the Application (105 A 1) on the Device (105).The Device (105) is a computing device capable of running the Application (105 A 2) and communicating with at least one Information exchanging unit (102 A or 102 B), preferably the computing device is selected from group comprising a mobile device, cellular phone, tablet phones, pager, smart phone, smart devices, portable computing devices, portable laptops and other internet enabled devices adapted to run the application. The Device (105) may be a computing device capable of running the Application (105 A 2) and communicating with at least one Information exchanging Unit (102 B) through at least one Information exchanging Unit (102 A) with the help of the Application (105 A 2).

The Web-service (103) as shown in Figure 3 may comprise a Remote server (103 A), a Webserver Application (103 B), optionally a Display Unit (103 C), a Storage Medium (103 D) to store, retrieve, record or process the input or output generated or received by the Web-service (103), and optionally a Database (103 E) to store or process the data generated or received by the Web-service (103). The Web-service (103) may be any service which requires the user authentication for making a valid transaction by the user, wherein the transaction can be a financial or non- financial in nature. The Web-service (103) is preferably a Bank ATM Services, online banking services, other Banking services, online payment services, customer membership services, attendance management services, online booking services and other electronic payment or financial transaction systems or non-financial transaction systems where user authentication is required.

The Web-server Application (103 B) enables the user to interact/communicate or login with the Web-service (103) and the Validation-server (104). The Web-server Application (103 B) communicates to the Validation-server (104) through the Remote server (103 A) for performing valid authentication of the device and the user in order to perform the valid transaction through the Web-service (103) by the user. The Remote server (103 A) registers, stores, processes and/or authenticates the input or output data received by the user and/ or communicates to the application through the Validation-server (104) and the Web-service (103).

The Display unit (103 C) may be optionally incorporated with the client server of the Web- service (103) which facilitates the user to receive the transaction processing on the remote server (103 A) through the Web-server Application (103-B). The Display Unit (103 C) may be any screen or visual display unit or audio-visual unit or audio unit or perception unit or similar units as described above as Display unit (105 C).

The Validation-server (104) as shown in Figure 4 comprises a Control unit (104 A) to control the validation of the information, received and sent by the Validation-server (104). The Control Unit (104 A) also controls the operations of the system for authentication of the user, and manage the generation and synchronization of algorithms generated by the Web-service (103) and the Validation server (104). The Validation-server (104) may also include a Storage medium (104 B) to store, retrieve, record or process the input or output generated or received by the Validation-server (104) or Control unit (104 A) and a Database (104 C) to store/collect or process the data generated or received by the Validation-server (104) or Control unit (104 A). The Control unit (104 A) may registers or stores the user data in the database received or generated by the Control unit (104 A); and/or verifies/validates the User (101) of the Device (105); and/or validates the User (101) data received from the Application (105 A 2) and the Web-service (103); and/or controls or communicates the Information (106) or the data to the Application (105 A 2) and the Web-service (103) for user authentication or validation; and/or enables the User (101) to perform a valid transaction through a successful and authenticated communication/interaction between the Application (105 A 2) and the Web-service (103). The valid transaction may be a transaction performed by the verified user of the Device (105) and the Web-service (103), wherein the transaction may be a financial or a non-financial transaction. The financial transaction may be any transaction which may include transfer or exchange of money or payment or any such service which may include exchange of money. For example banking services, payment systems, ATM machines, online payment systems, online banking, online booking services, membership benefits and other like services. The Non-financial transaction may be any transaction which does not include transfer or exchange of money but may require a user authentication. For example attendance management system, login into any web service such as private websites, mailbox services, blogs and other like services. The system as described above may include a method for user authentication, the method comprising steps of:

(A) Registering the Device (105) with the Validation-server (104) through the Application (105 A 2);

(B) User (101) Signup for the first time with the Web-service (103) through the Application (105 A 2); or Already registered/ logged in User (101) with the Web-service (103), activates the services of the Web-service (103) through the Application (105 A 2); and

(C) User (101) authentication by the Web-service (103) through the Application (105 A 2) for performing a valid transaction by the User (101).

For Illustration:

(A) Registering the Device (105) with the Validation-server (104) through the Application (105 A 2) as shown in Figure 5, includes steps:

(i) User (101) installs or downloads the Application (105 A 2) on the Device (105), on successful download or installation, User (101) runs the Application (105 A 2) on the Device (105) through the Platform (105 A 1). The Device (105) stores the Application (105 A 2) in its Storage medium (105 D).For an instance, a single User (101 ) may installs or download the Application (105 A 2) in multiple number of Devices (105).

(ii) Application (105 A 2) asks the User (101) to input the User Information(s), wherein the User Information may be a single user information or multiple user information as predefined in the Application (105 A 2) such as name, e-mail address, date of birth, pin code, mobile number of the User (101), preferably at least one User Information may be unique for the User (101), For example E-mail Address, unique alpha numeric sequence, unique numeric sequence and other like unique user information. For instance the Application (105 A 2) ask the User (101) to input the User's (101) valid E-mail address as User Information.

(iii) After inputting the user information, the Application (105 A 2) asks the User (101) to input an Access key for the Application (105 A 2). The Access key may be a password, secret word, secret code, unique image, unique string of characters, biometric authentication such as finger print, face recognition, iris recognition; and other secret codes used for user authentication to prove identity as a valid user of the Device (105) or required by the User (101) to access the Application (105 A 2). The Access key may be of any length or format as pre-defined by the Validation-server (103).

(iv) Further to Step (iii), the Application (105 A 2) sends the User Information along with the Access key to the Validation- server (104) for validation of the User Information and Access key.

(v) the Validation-server (104) validates and stores the User Information against the Access key in chronological sequence against the time of registration and the row index or serial nuber which may be treated as the primary key and unique to the User (101) and may be called as UserlD in the Storage Medium (104 B) or Database (104 C), wherein the UserlD may be a unique numeric or alphanumeric sequence generated incrementally for each new user by the Validation-server (104), For illustration as shown in Table 1.

Table 1: User Table (Validation-server)

(vi) Further to step (v), the Validation-server (104) creates a unique identity for the Device (105) may be called as DevicelD, for example the unique identity for the Device (105) is a unique alphanumeric sequence or numeric code derived from or seeded with the User's Information, for example combination of User's (101) E-mail address and Time of registration for example (E-mail Address) (Time) may serve as a DevicelD.

For an instance, the DevicelD may be stored against the UserlD, Status and the time of registration in the Table 2 as shown below, of the Database (104 C) of the Validation-server (104). The Status may indicate the activity of the Application (105 A 2) set by the Validation- server (104), if the Application (105 A 2) is successfully registered with the Validation-server (104) and Validation-server has the valid UserlD against DevicelD, the status may be set as Active and User (101 ) is allowed to use the Application (105 A 2) with the given User Information and Access key. In case the Device (105) is stolen by any other person and User (101) requests the Validation-server to block the Application (105 A 2) by blocking the DevicelD or UserlD, the Status may be set as Inactive or Stolen and the Application (105 A 2) may not perform any desired function. The DevicelD or UserlD against which the Status is set as Inactivate or Stolen, the Application (105 A 2) may be permanently blocked against the DevicelD and UserlD which is Inactive.

Table 2: Device Table (Validation-Server)

(vii) the Validation-server may associates the DevicelD with the UserlD and generate the DevicelD-UserlD pairing, the pairing may or may not be stored in the Storage Medium (104 B) or Database (104 C).

(viii) Upon association or Further to step (vii), the Validation-server (104) sends back the DevicelD to the Device (105) and the Device (105) stores the DevicelD in the Storage Medium (105 D) of the Device (105).

(ix) Further to step (viii), the User (101) and the Device (105) may be successfully registered to the Validation-server (104) through the Application (105 A 2). The Validation-server (104) may serve a confirmation message to the User (101) through the Application (105 A 2) for successful registration of the Device (105) and the User (101) with the Application (105 A 2).

(B) (1) User (101) Signup for the first time with the Web-service (103) through the Application (105 A 2) as shown in Figure 7; or (2) Already registered User (101) Signin with the Web-service (103) through the Application (105 A 2) as shown in Figure 8:

(1) User ( 101 ) Signup for the first time with the Web-service (103) through the Application (105 A 2), includes steps:

(i) Pre-Signup process as shown in Figure 6: Validation-server (104) registers at least one Web-service (103) to which User (101 ) may request for Signup. The Web-service (103) may be registered with the Validation-server (104) and connected to the Validation-server through the communication channel, upon registration the registered User (101 ) of the Device (105) may Signup to the Web-service (103) through the Application (105 A 2); For registration of the Web-service (103) with the Validation-server (103), the Validation-server(103) generates a unique identifier allotted to the Web-service (103), through which the Validation-service (104) may recognize the registered Web-service (103). The unique identifier may be a unique numeric sequence and may be called as ServicelD. The ServicelD may be stored in the Storage Medium (104 B) or Database (104 C), For illustration the ServicelD may be stored against the name of the Web-service (103) in Services Table of the Database (104 C) as shown in Table 3 below:

Table 3: Services (Validation-Server)

Upon validating and generating the ServicelD for the Web-service (103), the Validation- server (104) registers the Web-service (103) and activates the services of the Web-service (103) for the registered User (101) of the Application (105 A 2).

(ii) Further to Step (i), User (101) may select a registered Web-service (103) from the list of registered Web-services (103) and request for a Signup form. The User (101) may request or receive a Signup form from the Web-service (103). The Web-service (103) may generate a static Information may be called as Signup Information. On receiving, scanning, or decoding the Signup Information encoded, printed, transmitted or displayed through/on the Information exchanging unit (102 B) of the Web-service (103) by the Information exchanging unit (102 A) of the Device (105), User (101) may send a request for the Signup form of the Web- service through the Application (105 A 2) to the Validation-server (104). For Instance, the Signup Information is a Static QR generated by the Web-service (103) encoded with the Signup request information displayed or printed on any Information Containing medium for example on the screen of the website of the Web-service (103) or printed on paper medium distributed by the Web-service (103) . User (101) scans or captures the static QR through the Device (105) and the static QR is decoded by the Application (105 A 2). The Application (105 A 2) sends decoded Signup request information along with the DevicelD to the Validation-server (104).

(iii) Further to Step (ii), the Validation-server (104) validates or checks the presence of the decoded Signup information and retrieves the corresponding Signup form of the Web-service (103) by the Web-service (103) or from the Database (104 C) of the Validation-server (104) where the Signup form may be stored against the decoded Signup information.

(iv) Further to step (iii), the Validation-server (104) sends the Signup form and Signup configuration details to the Application (105 A 2).

(v) Upon receiving the Signup form by the Application (105 A 2), User (101) inputs the data as required by the Web-service (103) in the Signup form.

(vi) Further to step (v), upon submission of the Signup form by the User (101), the Application (105 A 2 ) checks for an active Session token in the Storage Medium (105 D). In absence of the Session token, the Application (105 A 2) asks the User (101) to enter the valid Access key, then the Application (105 A 2) retrieves DevicelD from the Storage medium (105 D) and sends the DevicelD along with the Access Key to the Validation-server (104).

(vii) Further to step (vi), the Validation-server (104) checks for the validity of the Access key and the DevicelD by matching both in the Database (104 C).

(viii) Upon validating the Access key and DevicelD, the Validation-server (104) generates a unique random identifier and stores the unique random identifier in the Database (104 C). For an instance, the unique random identifier may be called as SessionToken and stored against the DevicelD and the Expiry time, wherein the Expiry time is the time limit or duration as defined by the Validation-server (104) and upon the expiration of the defined time duration or Expiry time, the Application (105 A 2) further asks User (101) for the Access key and Validation-server (104) generates a new session token by validating the Access key and DevicelD. The session token is stored in the SessionToken Table of the Database (104 C) as shown below at Table 5, Table 5: SessionToken (Validation-Server)

(ix) Further to step (viii), the Validation-server (104) communicates the Session Token to the Application (105 A 2). On receiving the active Session Token, the Application (105 A 2) forwards the DevicelD and Session Token along with User (101) Signup form to the Web- service (103). The Web-service stores the active Session Token in the Storage Medium (103 D).

(x) Further to step (ix), the Web-service (103) forwards the DevicelD to the Validation- server (104) as a challenge. The Validation-server (104) may be required to respond with the Session token as stored against the DevicelD and currently active for the DevicelD in question. The Validation-server (104) sends the Session Token to the Web-service (103).

(xi) Upon receiving the Session Token from the Validation-server (104), the Web-service (103) matches the Session Token received from the Application (105 A 2) and the Session Token received by the Validation-server (104). If both the Session Token matches with each other, the Web-service validates the Device (105) to be a valid device and the User (101) to be a valid user.

(xii) Further to step (xi), the Web-service (103) creates a User profile, and stores the User profile or User information in the Storage Medium (103 D). For an instance, the User profile or User information as obtained by the User filled Signup form is stored against the UserlD in the User Table of the Storage Medium (103 D) of the Web-service (103), as shown below at Table 6: Table 6: UserTable (Web-service)

(xiii) Post registration of the User (101) with the Web-service (103) as shown in Figure 9: Further to step (xii), the Web-service (103) sends the UserlD and the DevicelD to the Validation-server (104). The Validation-server (104) associates the UserlD and DevicelD and forms a UserlD-DevicelD association, the Validation-server (104) treats the association as a secret and divides the association into 'm' parts, such that 'n' out of 'm' part is required for User (101) authentication wherein (n<m) and; 'n' and 'm' both are integers. For an instance the Validation-server (104) divides the association into 3 parts such that each one part is assigned to the Validation-server (104), the Device (105) and the Web-service (106). The Validation-server (104) retains one part and stores the part as a Secret share in the Database (104 C) or in the Storage Medium (104 B), for an instance the Validation-server (104) stores the one part of the secret against the User ID and the ServicelD in the Device Mapping or User Mapping Table of the Database (104 C) as shown below at Table 7:

Table 7: Device Mapping/ User Mapping (Validation-server)

(xiv) Further to step (xiii), the Validation-server (104) sends the remaining 2 parts of secret to the Web-service (103), the Web-service (103) stores one part as a Secret Share in the Storage Medium (103 D), for an instance the Web-service (103) stores the one part of the secret as a Secret Share against the DevicelD in the User Association Table of the Storage Medium (103 D) as shown below ai Table 8: ^'

Table 8: User Association (Web-service)

(xv) Further to step (xiv), the Web-service (103) sends .the remaining one part of the secret to the Application (105 A 2), the Application (103) stores the remaining one part as a Secret Share in the Storage Medium (105 D), for an instance the Application (105 A 2) stores the remaining part of the secret as a Secret Share against the ServicelD in the Application Table of the Storage Medium (105 D) as shown below at Table 9:

Table 9: Application (Application/Device)

(xvi) Further to step (xv), the User (101) is assumed to be logged in or signed in with the Web-service (103) successfully and the Signup process may be assumed to be completed.

(2) Already registered/ logged in User (101) with the Web-service (103), activates the services of the Web-service (103) through the Application (105 A 2), includes steps:

(i) Already registered or logged in User (101) with the Web-service (103), request/receives the web-service activation Information,, wherein the web-service activation Information is a -dynamic Information, for an instance the activation ^' Information is in the format of dynamic Activation QR, User (101) requests/looks for the dynamic Activation QR through the client server or the Display unit (103 C) of the Web-service (103). (ii) Upon receiving the request for the dynamic Activation Information, the Web-service (103) forwards the ServicelD and SessionID to the Validation-server (104) to get a unique dynamic Activation Information.

(iii) Further to step (ii), the Validation-server (104) records/stores the request in the Database (104 C) or the Storage Medium (104 B) and generates a unique Activation Information against the request, for an instance the request is stored as a unique row index along with the ServicelD, SessionID, Expiry Time and unique QR index in the QR Request Table of the Database (104 C) as shown below at Table 10:

Table 10: QR Request Table (Validation-server)

(iv) Further to step (iii), the Validation-server (104) sends the Activated Information in a suitable format to the Web-service (103), the Web-service displays/transmit or make available the Activated Information in a format compatible to the Device (105), for an instance the Activated QR Index is encoded in the format of QR Image by the Validation- server (104) and sends to the Web-service (103). The Web-service (103) displays the QR Image through the Display (103 C).

(v) Further to step (iv), the User may receive or decode or scans the Activation Information sent by the Web-service (103) through the Web-service Display (103 C) or any client server of the Web-service (103), for an instance User (101) scans the QR Image through the Application (105 A 2).

(vi) Further to step (v), ^' the Application (105 A 2) communicate to the Validation-server (104) and the Validation-server (104) checks for an active Session token in the Database (104 C). In absence of the Session token, the Validation-server (104) asks the User (101) through the Application (105 A 2) to enter the valid Access key, then the Application (105 A 2) retrieves the DevicelD from the Storage medium (105 D) and sends the DevicelD along with the Access Key to the Validation-server ( 104).

(vii) Further to step (vi), the Validation-server (104) checks for the validity of the Access key and the DevicelD by matching both in the Database (104 C).

(viii) Upon validating the Access key and DevicelD, the Validation-server (104) generates a unique random identifier and stores the unique random identifier in the Database (104 C). For an instance, the unique random identifier may be called as SessionToken and stored against the DevicelD and the Expiry time, wherein the Expiry time is the time limit or duration as defined by the Validation-server (104) and upon the expiration of the defined time duration or Expiry time, the Application (105 A 2) further asks User (101) for the Access key and Validation-server (104) generates a new session token by validating the Access key and DevicelD. The session token is stored in the SessionToken Table of the Database (104 C) as shown above at Table 5.

(ix) Further to step (viii), the Validation-server (104) communicates the Session Token to the Application (105 A 2). On receiving the active Session Token, the Application (105 A 2) forwards the DevicelD and Session Token along with Activation Information to the Web- service (103).The Web-service stores the active Session Token in the Storage Medium (103 D).

(x) Further to step (ix), the Web-service (103) forwards the Activation Information along with the DevicelD to the Validation-server (104).

(xi) Further to step (x), the Validation-server (104) fetches the currently active Session Token for the DevicelD. The Validation-server (104) also fetches the SessionID from the Database (104 C), for an instance Validation-server (104) fetches the SessionID from the QR Request Table (See above at Table: 9) of the Database (104 C) against the Active QR Index forwarded by the Web-service.

(xii) Further to step (xi), the Validation- server (104) sends the Session Token along with the SessionID to the Web-service.

(xiii) Further to step (xii), If the Session Token received from the Validation-server (104) matches with Session Token received from the Application (105 A 2), the Web-service (103) recognizes the Device (105) as a valid device and User (101) as a valid user of the Device (105).

(xiv) Further to the step (xiii), the Web-service (103) stores the sessionID as a key to locate the row in form of Row Index in the Storage Medium (103 D). The Web-service (103) checks for the UserlD against which this Activation Information was served. If the information is retrieved successfully the services of the Web-service may be assumed to be activated or else the process gets aborted.

(xv) Post- Activation of the Web-service (103) as shown in Figure 9, Further to step (xiv), the Web-service (103) sends the UserlD and the DevicelD to the Validation-server (104). The Validation-server (104) associates the UserlD and DevicelD and forms a UserlD-DevicelD association, the Validation-server (104) treats the association as a secret and divides the association into 'm' parts, such that 'n' out of m part is required for User (101) authentication wherein (n<m) and; 'n' and 'm' both are integers. For an instance the Validation-server (104) divides the association into 3 parts such that each one part is assigned to the Validation-server (104), the Device (105) and the Web-service (106). The Validation- server (104) retains one part and stores the part as a Secret share in the Database (104 C) or in the Storage Medium (104 B), for an instance the Validation-server (104) stores the one part of the secret against the User ID and the ServicelD in the Device Mapping or User Mapping Table of the Database (104 C) as shown above at Table 7.

(xvii) Further to step (xvi), the Validation-server (104) sends the remaining 2 parts of secret to the Web-service (103), the Web-service (103) stores one part as a Secret Share in the Storage Medium (103 D), for an instance the Web-service (103) stores the one part of the secret as a Secret Share against the DevicelD in the User Association Table of the Storage Medium (103 D) as shown above at Table 8.

(xviii) Further to step (xvii), the Web-service (103) sends the remaining one part of the secret to the Application (105 A 2), the Application (103) stores the remaining one part as a Secret Share in the Storage Medium (105 D), for an instance the Application (105 A 2) stores the remaining part of the secret as a Secret Share against the ServicelD in the Application Table of the Storage Medium (105 D) as shown above at Table 9,

(xix) Further to step (xviii), the User (101) may be assumed to activate the services of the Web-service (103) successfully and the activation process may be assumed to be completed. (C) User (101) authentication by the Web-service (103) through the Application (105 A 2) for performing a valid transaction by the User (101) as shown in Figure 10, include steps:

(i) User (101) having activated services of the Web-service (103) may requests the Web- service (103) for a dyamic Login Information (For Example any Information (106) such as a dynamic QR Image) for the user authentication or Web-service (103) may serve the dynamic Login Information through its client server or the Display unit (103 C).

(ii) Further to step (i), the Web-service (103) forwards the ServicelD and the SessionID to the Validation-server (104) and request the Validation-server (104) to generate a dynamic Login Information in order to serve the Application (105 A 2) in response of the request.

(iii) Further to step (ii), the Validation-server (104) generates a new Login Information and serves it back to the Web-service (103), the Web-service (103) displays/transmit the Login Information to the User through its Display unit (103 C) as mentioned in step (i) of User (101) authentication.

(iv) Further to step (iii), the User (101) scans/receives/decodes the Login Information received by the Web-service client server or the Display unit (103 C).

(v) Further to step (iv), the Application (105 A 2) checks for the valid/active Session Token, if not present the Application (105 A 2) asks User (101) to enter the Access key ,

(vi) On receiving the Access key, the Application retrives the DevicelD and send the DevicelD along with the Access key to the Validation-server (104).

(vii) On validating the Acess key and the DevicelD, the Validation-serevr (104) generates a new valid Session Token for a limited time as defined by the Validation-server (104), on expiry of which a new Session Token would be required by the Application (105 A 2).

(viii) In presence of a valid/active Session Token, the Login Information received by the Application (105 A 2) is decoded by the Application (105 A 2) and the Application (105 A 2) identifies the Web-service (103).

(ix) Further to step (viii), the Application searches for the share of the secret assigned to it and stored in the Storage Medium (105 D) against the ServicelD of the Web-service, for an instance the Secret Share is stored at Application Table (See above at Table 8) against the ServicelD.

(x) Further to step (ix), if the Secret share is present in the Storage Medium (105 D) of the Application (105 A 2), the process proceeds further or else the process is aborted.

(xi) If the Secret share is found in the Storage Medium (105 D), the Application forwards the DevicelD, Login Information, Session Token and the Secret Share to the Web-service (103).

(xii) Further to step (xi), the Web-service (103) forwards the DevicelD to the Validation- server (104) as a challenge. The Validation-server (104) may be required to respond with the Session token as stored against the DevicelD and currently active for the DevicelD in question. The Validation-server (104) sends the Session Token to the Web-service (103).

(xiii) Upon receiving the Session Token from the Validation-server (104), the Web-service (103) matches the Session Token received from the Application (105 A 2) and the Session Token received by the Validation-server (104). If both the Session Token matches with each other, the Web-service validates the Device (105) to be a valid device and the User (101) to be a valid user.

(xiv) Further to step (xiii), the Validation-server (104) fetches the currently active Session Token for the DevicelD. The Validation-server (104) also fetches the SessionID from the Database (104 C), for an instance Validation-server (104) fetches the SessionID from the QR Request Table (See above at Table: 9) of the Database (104 C) against the Active QR Index forwarded by the Web-service.

(xv) Further to step (xiv), the Validation-server (104) sends the Session Token along with the SessionID to the Web-service.

(xv) Further to step (xv), If the Session Token received from Validation-server (104) and the one received from the Application (105 A 2) matches with each other, the Web-service (103) then proceeds to retrieve the Secret Share stored against the DevicelD in the Storage Medium (103 D), for an instance the Secret Share is stores against the DevicelD (See Table 8) in User Association Table of the Storage Medium (103 D). (xvi) Further to step (xv), the Web-service (103) merges the retrieved Secret Share of the step (x) with the Secret share retrieved at step (v) to reveal the original association between the DevicelD and the UserlD.

(xvii) Further to step (xvi) and once the association is recovered, the Web-service (103) checks for the DevicelD which is present in the revealed association.

(xviii) Further to step (xvii), the Web-service (103) matches DevicelD obtained from step (xii) with the DevicelD obtained from the Application (105 A 2).

(xix) On successful match, the user authentication may be assumed to be completed and Web-service (103) allows the User (101) to make valid transactions through the Application (105 A 2) . The Web-service (103) may or may not ask for further security verification, such as but not limited to alphanumeric codes, numeric codes, PINS or other personal user information or security codes.

In an embodiment, the system (100) may include a method for user authentication for User (101) having Device (105) registered with the Validation-servre (104), the method comprising steps of:

(B) (1) User (101) Signup for the first time with the Web-service (103) through the Application (105 A 2) as shown in Figure 7; and/ or (2) Already registered/ logged in User (101) with the Web-service (103), activates the services of the Web-service (103) through the Application (105 A 2) as shown in Figure 8; and

(C) User (101) authentication by the Web-service (103) through the Application (105 A 2) for performing a valid transaction by the User (101).

In another embodiment, the system (100) may include a method for user authentication for already registered User (101) having registered Device (105) with activated service(s) of the Web-service (103) may proceed- with the User authentication by the Web-service (103) through the Application (105 A 2) for performing a valid transaction by the User (101) as shown in Figure 10. For an illustration a Web-service may be a ATM machine upon successfully following the above mentioned steps of the method for user authentication, the User (101) may not require to enter the security pin code for making financial transaction and thus this minimize the changes of unauthorized use of the stolen ATM cards by stealing the Card and the password from the User (101).

In addition to the embodiments described above, the present invention can be deployed in various other types of Applications including, for example, digital signatures, encryption, secure ATM cards and secure payment systems, person identification system etc. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art should know how to deploy the present invention in many other types of Applications.

The methods or algorithm(s) and encryption/decryption described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of control logic, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.

The description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit of scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein, but is to be accorded the full scope consistent with the claims.