GB2539523A

GB2539523A - System and method for generating long token and subtoken for processing an interaction

Info

Publication number: GB2539523A
Application number: GB1600413.7A
Authority: GB
Inventors: Singh Sethi Ranvir
Original assignee: Individual
Current assignee: Individual
Priority date: 2015-01-13
Filing date: 2016-01-11
Publication date: 2016-12-21
Also published as: AU2016200136A1; GB201600413D0

Abstract

A server processes an interaction between a first user device and a second user device by utilizing one or more tokens. The server includes a database and set of modules where the set of modules includes a token processing module, token associating module, validation confirmation obtaining module and an interaction processing module. The token processing module receives input from the first user including a request to associate a long token or subtoken with first user device. The subtoken is derived or obtained from long token or the long token is derived or obtained from subtoken based on predefined relationship. A subtoken maybe a symbol or commonly used word and maybe an email address or phone number. Confirmation is then obtained of validation from a second user device for processing an interaction when predefined relationship exists between long token and subtoken and processing the interaction between first user and second user based on confirmation.

Description

SYSTEM AND METHOD FOR GENERATING LONG TOKEN AND SUBTOKEN FOR

PROCESSING AN INTERACTION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to Australian patent application no. AU2015900074 filed on January 13, 2015, and AU2015900898 filed on March 12, 2015 the complete disclosure of which, in its entirely, is herein incorporated by reference.

BACKGROUND

Technical Field

[0002] The embodiment herein generally relates to a system that uses communication networks to authenticate user's identity, and more particularly, to a system and method to authenticate a plurality of users and processing an interaction based on long token and subtoken.

Description of the Related Art

[0003] For a user it is not practical or appropriate to remember and recite credit card and bank details while shopping, and for this reason the user always has a physical card with a microchip or magnetic tape for fast reading of the data, in personal possession. The physical card is read by a special point of sale device. The user cannot retrieve money from an Automatic Teller Machine without the physical card. The physical card numbers are frequently misused. Cash is used for face to face transactions, but exact change is not always available and carrying more cash than one would need to spend at all times is not an option. [0004] Fixed passwords are no longer appropriate for controlling computer access. Effective access control calls for a use of dynamic passwords, which are generated by a tokens, a calculator-type device or fob. Many such devices have now been introduced into the marketplace, but such devices are not necessarily appropriate for all situations. Some devices plug into smartphones to convert smartphones into credit or debit card readers. These devices are costly and inconvenient to carry. Some of the disadvantages of the dynamic passwords generated by the tokens are that the dynamic passwords are being monitored, trapped, copied, and replayed over communication lines and on networks. Gongle and Yahoo have introduced methods in which a non-secret publically known key such as an email address is utilised in conjunction with a smartphone to login without a password.

[0005] Therefore the computational devices are getting more personal and private and pervasive of malicious software, users are not comfortable to indulge in machine to machine communication with their devices. Their only alternative is to recite these long tokens. If these tokens are less long, they tend to expire quickly.

[0006] Accordingly, there is a need for more secure authentication mechanism wherein, users can easily and quickly share the token verbally or otherwise without exposing their devices to other devices for machine to machine transmission of tokens. In such a system, no constant information is neither exchanged nor required as basis of conducting an interaction between two parties.

SUMMARY

[0007] In one aspect, a server for processing an interaction between a first user device and a second user device by utilizing one or more tokens is disclosed. The server includes a memory unit that stores (a) a database, (b) a set of modules, and (c) instructions and a processor which when configured by the instructions executes the set of modules. The set of modules includes a token processing module, a token associating module, a validation confirmation obtaining module and an interaction processing module. The token processing module receives an input from a first user comprising a request to associate a long token with the first user device. The token associating module associates the subtoken token with the first user device. A subtoken is derived or obtained from the long token based on a predefined relationship. A long token is derived or obtained from a subtoken based on a predefined relationship. A subtoken is a reusable code. A subtoken can also be a symbol or commonly used word. A subtoken is an email address or phone number. The validation confirmation obtaining module obtains a confirmation of validation or data from which the confirmation is derived from the second user device for processing an interaction when the predefined relationship exists between (a) the long token that is received at the second user device from the first user or first user device, and (b) the subtoken that is received at the second user device from the first user or first user device. The interaction processing module processes the interaction between the first user and the second user based on the confirmation obtained from the validation confirmation obtaining module.

[0008] The set of modules further includes a location validation module, a subtoken derivation module, comprises a long token comparison module, and an identifier communication module. The location validation module obtains a location associated with the first user device and the second user device and checks if the location associated with the first user device and the second user device are within a predefined area. The subtoken derivation module derives or obtains the subtoken from the long token based on the predefined relationship. The predefined area includes a location associated with the first user characterized by a first predefined outer area and a first predefined inner area. The first predefined inner area is within the first predefined outer area and the long token or the subtoken (a) is obtained for the first predefined inner area,(b) unique within first predefined outer area (c) is valid only within the first predefined inner area, or (c) is deactivated upon the long token moves or the subtoken moves out of the first predefined inner area, or the location associated with the long token or subtoken gets changed to a location that is not inside the first predefined inner area. The long token comparison module compares the long token associated with the second user device and the long token associated the first user device from the server. The subtoken is associated with one or more predefined area and the subtoken is unique within a predefined area to process the interaction between the first user and the second user. In an embodiment, the interaction may be logging into a device or a website or exchanging of data between users, user devices by utilising the subtoken. In an embodiment the subtoken is an email or phone number in predefined relationship with a long token. The interaction is a transaction between the first user and the second user. The first user is a payer or payee and the second user is a payer or payee. The identifier communication module communicates a payee identifier to the payer device for processing the interaction. The payer and payee is associated with the first user and the second user. The payee identifier and a payer identifier are associated with the location of the subtoken or the long token characterized by the predefined area, and the location associated with the subtoken or long token is (i) located remotely with respect to a physical location of the first user or the second user or (ii) a physical location of the first user or second user. The payee identifier is communicated to payer device to obtain approval of transaction from payer on payer device. The first user identifier is communicated to second user device to obtain approval of interaction from second user on second user device.

1.0009.1 In another aspect, One or more non-transitory computer readable storage mediums storing one or more sequences of instructions, which when executed by one or more processors, processes an interaction between a first user and a second user is disclosed. The one or more non-transitory computer readable storage mediums storing one or more sequences of instructions includes receiving an input from a first user comprising a request to associate a long token with a first user device. The first user device is associated with the first user and a second user device is associated with the second user, associating the long token with the first user device. A subtoken is derived or obtained from the long token based on a predefined relationship. A long token is derived or obtained from the subtoken based on a predefined relationship, obtaining a confirmation of validation or data from which the confirmation is derived from the second user device for processing an interaction when the predefined relationship exists between (a) the long token that is received at the second user device from the first user or first user device, and (b) the subtoken that is received at the second user device from the first user or first user device, and processing the interaction between the first user and the second user based on the confirmation obtained from the validation confirmation obtaining module.

1.000 I 0.1 In yet another aspect, a user device for authenticating an interaction between a first user and a second user by using a long token or a subtoken is disclosed. The user device includes a display unit, a database, instructions, and a processor which when configured by said instructions executes said set of modules. The set of modules includes a long token or a subtoken processing module, a subtoken manifesting module, a long token or a subtoken communicating module, a subtoken receiving module, predefined relationship checking module, a long token receiving module, and a token notification module. The long token or a subtoken processing module obtains the long token or the subtoken. The subtoken manifesting module manifests the subtoken on the user device. The long token or a subtoken communicating module communicates the long token or the subtoken, (i) to the server, when the long token or the subtoken is first obtained by the user device associated with the first user before it is obtained by the server; or (ii) from the server, when the long token or the subtoken is first obtained by the server before it is obtained by the user device associated with the first user, the long token or subtoken is communicated from the user device to a second user device associated with the second user. The subtoken receiving module receives the subtoken from the first user or a first user device. The long token receiving module receives the long token from the first user or a first user device. Predefined relationship checking module checks for a predefined relationship between long token and subtoken received at the second user device. The token notification module notifies or implies a successful comparison between the long token or the subtoken associated with the first user device and the subtoken or the long token received by the second user device.

[00011] The set of modules further includes an approval receiving module, and a predefined relationship monitoring module. The approval receiving module receives an approval for a transaction or interaction from the second user device. Approval is based on a user identifier or amount or both. The predefined relationship monitoring module checks if there is a subtoken with predefined relationship with one or more long token from a database of long tokens which is present in the user device of a second user to be utilized for processing the interaction. In an aspect subtoken is email or phone of a user and a long token is obtained in predefined relationship with subtoken.

[00012] In yet another aspect, a transaction device utilized as a payer device and a payee device for processing a transaction between a payer and a payee by obtaining a long token or a subtoken of the transaction device is disclosed. The transaction device includes a memory unit that stores (a) a set of modules, and (h) a database and a processor is configured to execute the set of modules. The set of modules includes an amount module, a long token or a subtoken obtaining module, and a token receiving module. The amount module (i) sends a transaction amount associated with the transaction to a server or (ii) receives the transaction amount associated with the transaction from the server. The long token or a subtoken obtaining module obtains the long token or the subtoken on the transaction device, and communicates the long token or the subtoken to the payer or the payee through the transaction device. The token receiving module receives the long token or the subtoken from the payer or the payee through the transaction device.

[00013] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF DRAWINGS

[00014] The embodiments herein will he better understood from the following detailed description with reference to the drawings, in which: [00015] FIG. I illustrates a system view of a first user interacting with a second user through a server according to an embodiment herein; [00016] FIG. 2A and 2B illustrates an exploded view of the server of FIG.1, according to an embodiment herein; [00017] FIG. 2C illustrates an exploded view of a database of a payer device according to an embodiment herein; [00018] FIG. 2D illustrates an exploded view of a database of a payee device according to an embodiment herein; [00019] FIG. 2E illustrates an exploded view of user device for processing an interaction between a first user and a second user according to an embodiment herein; [00020] FIG. 3A and 3B is a flowchart that illustrates a method for verifying stranger authentication through the server 108 of FIG.1, according to an embodiment herein; [00021] FIG. 4A and 4B is a flowchart that illustrates a method for pairing two devices through the server 108 of FIG I, according to an embodiment herein; [00022] FIG. 5A and 5B is a flowchart that illustrates a method for pairing one device with plurality of devices which can exchange identity, data or read an allocated memory space in a one-way paired mode, through the server 108 of FIG I, according to an embodiment herein; [00023] FIG. 6A, 6B and 6C is a flowchart that illustrates a method for pairing a device with website in which they can exchange identity, data or read an allocated memory space of in a one way paired mode, through the server 108 of FIG. 1, according to an embodiment herein; [00024] FIG. 7A and 7B is a flowchart that illustrates a method for pairing a website session with a device after which they can exchange identity, data or read an allocated memory space of each other, through the server 108 of FIG. 1, according to an embodiment herein; [00025] FIG. 8A and 8B is a flowchart that illustrates a method for pairing a website session with another website session in which they can exchange identity, data or read an allocated memory space of each other, through the server 108 of FIG. 1, according to an embodiment herein; [00026] FIG. 9A, 9B and 9C is a flowchart that illustrates a method for pairing a website with another website or another session of same website in which they can exchange identity, data or read an allocated memory space of in a one way paired mode, through the server 108 of FIG. 1, according to an embodiment herein; [00027] FIG.IOA and 10B is a user interface view of a subtoken generated by using a method such that identical subtokens may be used by several users simultaneously through the server 108 of FIG 1, according to an embodiment herein; [00028] FIG. 11A, 11B, 11C and 11D is a flowchart that illustrates a method of payment by a nearby payee to a payer through the server 108 of FIG 1, according to an embodiment herein; [00029] FIG. I 2A, I 2B, I 2C and I 2D is a flowchart that illustrates a method of payment to payer by payee through the server 108 of FIG 1, according to an embodiment herein; [00030] FIG. 13A, 13B, 13C and 13D is a flowchart that illustrates a method of payment to a payee through an ATM from payer's account through the server 108 of FIG 1, according to an embodiment herein; [00031] FIG. I 4A, I 4B, I 4C, I 4D and I 4E is a flowchart that illustrates a method of paying reaming payments to a payee by payer through the server I 08 of FIG 1, according to an embodiment herein; [00032] FIG. 15A, 15B, 15C, 15D and 15E is a flowchart that illustrates a method of paying recurring payments to a website in the server, according to an embodiment herein; [00033] FIG. 16A, 16B, 16C, and 16D is a flowchart that illustrates a method of purchase from a payer to a payee through an automatic vending machine (AVM) in the server, according to an embodiment herein; [00034] FIG. 17A, 17B, 17C, and 17D is a flowchart that illustrates a method of purchase from a payer to a payee through an automatic checkout machine (ACM) in the server, according to an embodiment herein; [00035] FIG. I 8A, I 8B, I 8C and I 8D is a flowchart that illustrates a method of purchase from a payer to a website through the server 108 of FIG 1, according to an embodiment herein; [00036] FIG. 19A, 19B, 19C, 19D, is a flowchart that illustrates a method of purchase from a website to an application through the server 108 of FIG 1, according to an embodiment herein; [00037] FIG. 20 is a flowchart that illustrates a method of transmission of transaction document through the server 108 of FIG 1, according to an embodiment herein; [00038] FIG. 21 is a flowchart that illustrates a method of transmission of multiple transaction documents based on an agreement identifier through the server 108 of FIG 1, according to an embodiment herein; [00039] FIG. 22 illustrates an interface view of a database model of the server according to an embodiment herein; [00040] FIG. 23A and 23B illustrates a method for pairing two devices in a geographically non-intersecting areas through the server 108 of FIG 1, according to an embodiment herein; [00041] FIG. 24A and 24B illustrates a method for pairing two devices in geographically intersecting areas through the server 108 of FIG 1, according to an embodiment herein; [00042] FIG. 25 is a flowchart that illustrates a method for token generation in a device, through the server 108 of FIG. 1, according to an embodiment herein; [00043] FIG. 26 is a flowchart that illustrates a method for token generation in a server of FIG. 1, according to an embodiment herein; I.00044.IFIG. 27 illustrates a method for obtaining a long token for authenticating an interaction between a first user device and a second user device; and [00045] FIG. 28 is a schematic diagram of a computer architecture used in accordance 10 to the embodiments herein.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[00046] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description.

Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skilled in the art to practice the embodiments herein.

Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[00047] As mentioned, there remains a need for more secure authentication mechanism wherein, users can easily and quickly share the token verbally or otherwise without exposing their devices to other devices for machine to machine transmission of tokens.

Referring now to the drawings, and more particularly to FIGS. 1 to 30, where similar reference characters denote corresponding features consistently throughout the figures, these are shown preferred embodiments.

[00048] FIG. 1 illustrates a system view 100 of a first user 102 interacting with a second user 112 through a server 108 according to an embodiment. The system view 100 includes a first user device 104, a second user device 110, a network 106, and a server 108.

The first user 102 interacts with the second user 112 through the network 106 provided by the server 108. The first user 102 interacts with the second user I 12 through a network 106 with a smart phone, a computer or both, or such computation devices. In one embodiment, the first user device 104 obtains a subtoken by interacting with a server 108, whereas second user device 110 receives the subtoken from first user 102 or first user device 104 and sends it back to server 108 for matching. In an embodiment the subtoken is already known to the user as it is its email or phone number. In one embodiment the first user 102 is a payer and a second user 112 is a payee. In one embodiment, the first user device 104 is a payer device and the second user device is a payee device 110. In one embodiment, the first user 102 is a payee and a second user 11 is a payer and the first user device 104 is a payee device and the second user device is a payer device 110. In an embodiment, a user may be payer or a payee, both. The user may decide to be a payer or a payee, that is, a first user may obtain a token from server and share it with second user to transfer funds or receive funds, that is, first user may he a payer and or payee, within the same embodiment. The token includes a long token and a subtoken. The token can flow from first user device to second user device or viceversa.

[00049] The long token or the subtoken is created for interacting between the first user 102 and the second user 112. In an embodiment long token or the subtoken may be obtained for any location, including a location that is remote from device location. By setting location of the long token and the subtoken to within a predefined area, two users, by exchanging the long token or the subtoken, may interact or transact with each other. This interaction may happen when two users are in proximity and also when they are remote from each other. The location acts as additional factor of authentication, in addition to the long token or the subtoken. In one embodiment, the long token or the subtoken is unique to the location. In one embodiment, if a user moves out of the predefined area from that location, the long token or the subtoken is deactivated. In one embodiment, a user may only interact with an interface by obtaining long token or subtoken of a pre-agreed location. The subtoken is derived or obtained from the long token based on a predefined relationship. The predefined relationship exists between (a) the long token that is received at the second user device from the first user or first user device, and (b) the subtoken that is received at the second user device from the first user or first user device. For example, bank employee may only access intranet system of bank from a location that is pre-assigned to the user by the bank, which provides additional security to the user and the hank. For example, a user may speak its phone number or email to initiate interaction with another device. For example a user may speak a four digit code to initiate interaction with another device.

[00050] In an embodiment the long token may he unique and not repeatable. In an embodiment subtoken may be not unique and reusable. In an example, the long token is "AC5804358340583434" of eighteen characters and subtoken is "3434" where first two characters of long token may be an alphabets or numbers, last four digit is the long token is "3434" where the predefined relationship is "last four digits". Complex predefined relationship may be established by using secret keys or algorithms or both and may be changed regularly by the server for all or some users of the system. Upon application of the predefined relationship to the long token, the subtoken may be derived and matched with a subtoken entered by human into the machine. In this manner a long token may be validated without the need for communicating the whole of long token by the users for processing the interaction. Only the subtokens are communicated by the humans and the long tokens are exchanged by the machines. Hence, while machines are able to communicate quickly, control is still with humans as to proceed with any interaction or transaction or not. Previous methods of machine token transmission such as using NFC, QR code, sound have not gone down well with humans as users want to have the final control. For example, when the token is communicated with sound, the human will have no control at all as the sound will reach its smartphone and proceed with an interaction with another device. Pairing of machine token or long token with a human communicable subtoken gives users the control and hence makes the machine interactions more user friendly. Long token is long because it is long enough that it will be always unique as its chance of repeating is statistically negligible. Whereas, subtoken is small and repeatable and therefore human friendly like 4 digit or like. Or subtoken is easy to recall and recite for user like email or phone. The payer is sought an approval prior to processing a payment wherein in an embodiment identifier of payee is disclosed to payer. Hence regardless of whether the subtoken is shared by payer to payee or payee to payer, the payer provides the server with explicit approval prior to processing of the payment by the server. The approval displays payee identifier or amount or both to payer. A payer may input amount. Input of amount includes approval. The server may deactivate the subtoken instantly where it detects that more than one user has entered the same active subtoken in their devices simultaneously. In an embodiment, the subtoken may be drawings, numbers, symbols, catch phrase and the like. In an embodiment, the long token "long tokeesubtokeelong token" where predefined relationship may be an email between the two astrix and the subtoken may be an email address. For example long token "AC5804sd35834*john@xxemail.com*05836565" where predefined relationship is "email between two astrix" and subtoken is "john@xxemail.com" is email address of a user.

[00051] FIG. 2A & 2B illustrates an exploded view of the server 108 of FIG.1 according to the embodiment. The server 108 includes a token processing module 202, a token associating module 204, a validation confirmation obtaining module 206, an approval communication module 207, a location validation module 208, a predefined relationship storing module 209, a long token matching module 210, a subtoken matching module 211, a token generating module 212, an interaction processing module 214, a token deactivation module 216, an approval receiving module 218, a transaction processing module 220, an identifier communication module 222, a token verification module 224, a subtoken derivation module 226, a long token reusing module 227, a security check module 228 and a database 232. The subtoken derivation module 226 works with the predefined relationship storing module 209 and token generation module 212 to generate a long token and a subtoken. In an embodiment, token generation module is present in user device to generate the long token and the subtoken. The subtoken processing module 202 receives request to associate a subtoken with a first user. The token associating module 204 associates the long token or the subtoken with the first user device based on a predefined relationship. In an embodiment, the predefined relationship may be used to derive the subtoken from the long token. In an embodiment, the predefined relationship may be used to derive the long token from the subtoken. In an example, if the value of the subtoken is known then the long token may be derived or obtained from the known subtoken based on the predefined relationship. If the value of long token is known then the subtoken may be derived or obtained from the known long token based on the predefined relationship. In an embodiment long token and subtoken both are unknown and derived or obtained based on a predefined relationship. In an embodiment, the token associating module 204 associates the long token with the location. In an embodiment, the subtoken is specific to the location characterized by a predefined area or distance. In an embodiment subtoken has predefined relationship with long token. The token associating module 204, associates identical subtokens that are separated by a predefined area or distance. The token generation module generates long token subtoken or both. A location of the first user 102 is a physical location or an assumed location. In one embodiment, the location of the first user is characterized by a first predefined outer area and a first predefined inner area. The first predefined inner area is within the first predefined outer area. The long token or the subtoken (a) is obtained for the first predefined inner area, (b) unique within first predefined outer area (c) is valid only within the first predefined inner area, or (c) is deactivated upon the long token or the subtoken moves out of the first predefined inner area, or the location associated with the long token or subtoken gets changed to a location that is not inside the first predefined inner area.

[00052] The validation confirmation obtaining module 206 obtains a confirmation of validation or data from which a confirmation is derived from the second user device for processing an interaction when the predefined relationship exists between (a) the long token that is received at the second user device from the first user or first user device, and (b) the subtoken that is received at the second user device from the first user or first user device. In an embodiment the validation confirmation constitutes receiving of the device level predefined relationship check passed by a long token from a device and the long token is sent to server. In an embodiment validation confirmation is a packet of data from which the server may derive which long token is confirmed. The validation data in an embodiment will constitute long tokens and subtokens from a device. The approval communicating module 207 receives an approval or a denial message from a user based on a transaction, where the approval communication module further notifies a completion or a decline of the transaction to the users. The payee is a merchant and the amount is a transaction total. The payer device and payee device are informed upon a successful completion or a failure of the transaction by the approval communication module. The location validation module 208 obtains a location associated with the first user device and the second user device and checks if the location associated with the first user device and the second user device are within the predefined area. The predefined relationship storing module 209 stores predefined relationship between a long token and subtoken. This may be changed from time to time and different users are applied different predefined relationship. The long token matching module 210 matches data based on a first user long token or associated with the first user device with data based on a second user long token associated with second user device and the interaction processing module 214 processes interaction when the data based on the first long token and the second long token are matched.

[00053] The subtoken matching module 211 configured to match data based on a first user subtoken associated with the first user device and a second user subtoken associated with the second user device. The token generation module 212 generates the long token or the subtoken or both for processing the interaction between the first user and the second user and the subtoken is within the predefined relationship with the long token. In an embodiment, token generation module further generates the long token and the subtoken for authenticating the first user and the second user for logging in purpose and the approval receiving module receives an approval for authenticating the first user and the second user. In an embodiment the subtoken is same and email. The interaction processing module 214 processes the interaction between the first user and the second user based on the confirmation obtained from the validation confirmation obtaining module. The interaction processing module further processes the interaction between first user device and second user device when location associated with a first user subtoken and a second user subtoken are within the predefined area and data based on the first user subtoken and the second user subtoken is matched. In an embodiment, the interaction processing module processes multiple interactions based on a single approval received from the payer device, wherein the payer device is associated with the first user device or the second user device. The approval receiving module 218 receives an approval for the transaction from the payer device and also for authenticating the first user and the second user for logging in purpose.

[00054] The approval receiving module 218 receives an approval from the first user device and for interacting with a second user device. However, approval receiving module may display a password to the second user which then shared to the first user and entered into the first user device to obtain to two-way approval and two-way interaction. The transaction processing module 220, configured to process the transaction between the payer and the payee upon (0 successfully receiving the approval and (ii) a match is found between the long token or the subtoken associated with the payer device and the long token or the subtoken associated with the payee device. The payer device and payee device are informed upon a successful completion or a failure of the transaction by the approval communication module 207. The interaction is an exchange of a transaction document, data, or message between the first user or the second user. The transaction document is exchanged between the payee and the payer based on an identifier of the first user or the second user. The identifier communication module 222, configured to communicate a payee identifier to the payer device for processing the interaction. The payer and payee is associated with the first user and the second user. The payee identifier communication module is first user identifier communication module that displays first user name to second user on second user device at the time of obtaining approval for interaction from the second user on second user device by first user device. The token verification module 224 verifies whether the long token or the subtoken associated with the payer or the payee exists in a database of long tokens or subtokens. The database of the long tokens or subtokens is associated with the location characterized by the predefined area associated with the payee device or the predefined area associated with the payer device. The payer and payee is associated with the first user and the second user. The security check module 228 performs an additional security check for the payer 104 upon detection of breach of a threshold amount by a cumulative total of the transaction starting from a previous additional security check. The subtoken reusing module 227 reuses the subtoken for an interaction between a third user and a fourth user when the interaction between the first user 102 and the second user 112 is completed. In an embodiment the subtoken is resuable and simultaneously used for first and second user and third and fourth user. In an embodiment, long token or the subtoken or both is communicated to the second user from the first user through a sound wave and the long token consists of biometric data. The long token gets merged with encrypted biometric of payer in payer device in real time and sent back to server from payee wherein long token is matched and biometric part is matched separately. This ensures that authorized payer is using payer device for the transaction. In an embodiment the token obtained by the server at validation obtaining module 206 is a long token, it is directly matched with a list of tokens still unmatched in the server and hence two interacting users are matched. In an embodiment the token obtained by server is a subtoken, the subtoken is matched after finding list of active subtokens within predefined area associated with the received subtoken by 206.

[00055] FIG. 2C illustrates an exploded view of the payer device 104 of FIG, 1 according to the embodiment herein. The payer device 104 includes an amount module 234, a long token or subtoken obtaining module 236, a long token or subtoken receiving module 238, an approval module 240 and a database 242. The amount module 234 sends a transaction amount associated with the transaction to the server 108 or receives the transaction amount associated with the transaction from the server 108. The long or subtoken obtaining module 236 obtains the long or subtoken on the payer device 104. In an embodiment, the long token or subtoken obtaining module 236 obtains both the long token and the subtoken on the payer device 104. The payer is first user and payee is second user and the first user device obtains a subtoken by interacting with server and second user device 110 receives the subtoken from first user 102 or first user device 104. The subtoken is unique to a location and is based on the predefined relationship with a long token, and payer device 104 communicates the subtoken to the payee 112 or the payee device 110. The subtoken receiving module 238 is employed to receive the subtoken from the payee 102 or the payee device 104 and the payee is first user and payer is second user or vice versa. The flow of token between first user and second user can be reversed. The token includes long token and subtoken.

[00056] The approval module 240 notifies payer's approval of the transaction to a server based on the amount. The approval includes input of the amount by the payer 104 or payee identifier or a plurality of payee identifiers. In an embodiment, a device may have both subtoken obtaining module 236 and subtoken receiving module 238. In an embodiment the payer and payee may decide for themselves the flow of subtoken to be from payer to payee or payee to payer. Whereas another embodiment may have only one, subtoken obtaining module 236 or subtoken receiving module 238 for a payer and payee shall have the other module, to compliment. Likewise in an embodiment there is only long token obtaining module and in other embodiment a long token receiving module to compliment.

[00057] FIG. 2D illustrates an exploded view of the payee device 110 of FIG, 1 according to the embodiment herein. The payee device 110 includes an amount module 244, a long token or subtoken obtaining module 246, a token receiving module 248 and a database 250. The amount module 244 sends a transaction amount associated with the transaction to the server 108 or receives the transaction amount associated with the transaction from the server 108. The long token or subtoken obtaining module 246 obtains the long token or subtoken or both on the payee device 110. The subtoken is unique to a location within the predefined area, and payee or payee device communicates the subtoken to the payer 102 or the payer device 104. The token receiving module 248 is employed to receive the subtoken or long token or both from the payer 102 or the payer device 104. The payer is first user and payee is second user. The token is associated with the long token and the subtoken.

[00058] FIG. 2E illustrates an exploded view of user device for processing a transaction or interaction between a first user and second user according to an embodiment. In an embodiment, the user device includes a database 252, a long token or subtoken obtaining module 253, a predefined relationship checking module 254, a subtoken manifesting module 256, a predefined relationship status communication module 257, a long token or subtoken communication module 258, a subtoken receiving module 260, a long token receiving module 261, a token notification module 262, and a subtoken deactivation module 264. The long token or subtoken obtaining module 253 that obtains a subtoken. In an embodiment subtoken is associated with a predefined area based on an interaction from the user device with a server, and the subtoken is valid for a location characterized by a predefined area and has a predefined relationship with a long token. The subtoken manifesting module 256 manifests the subtoken on the user device. The predefined relationship status communication module 257 is communicates status of predefined relationship associated with a long token to the server. The status message may include a long token or a packet of data from which the Predefined Relationship Status can be derived by the server. In an embodiment the device may obtain one or both, the long token and subtoken, and share with server or obtain the long token and subtoken directly with server. In on embodiment there is no need to obtain a subtoken as it is already known like email or phone number. The long token and subtoken communicating module 258 communicates the long token and subtoken to the server and when the subtoken is first obtained by the user device associated with the first user before it is obtained by the server from the server. When the long token and subtoken is first obtained by the server before it is obtained by the user device associated with the first user and the long token and subtoken is communicated to the first user device by the server. The first user device and first user then shares long token and subtoken to a second user and second user device associated with the second user. The subtoken receiving module 260 receives the subtoken from the first user or a first user device. The token notification module 262 notifies or implies a successful comparison between the subtoken associated with the first user device and the subtoken entered by the second user of the second user device. The predefined relationship checking module 254 that generates a request to compare the subtoken received at second user device and the long token received at second user device based on predefined relationship stored at predefined relationship storing module 268. Predefined relationship storing module 268 stores instruction of predefined relationship between long token and subtoken which is used to confirm validity of a directly received long token by direct machine such as a sound wave or NFC. The long token conflict monitoring module 266 checks for any two long tokens both of which result in the same subtoken based on predefined relationship. Upon detection of conflict, long token conflict monitoring module 266 sends last generated long token's deactivation message to server and corresponding first user is issued with a new set of long token and subtoken. The conflict message in an embodiment also sends a new suggested subtoken that will not conflict The Approval receiving module 265 is used to receive approval from second user device 110 for granting interaction or transaction permission to first user device 104. The predefined relationship status communication module 257 communicates to server a data by which the server acquires status of a long token's predefined relationship status within a second user device 110. The status message in an embodiment constitutes the long token that passed the predefined relationship with respect to a subtoken. In an embodiment, the status message may include a package of data from which server may derive the status.

[00059] F1G. 3A and 3B is a flowchart that illustrates a method for verifying authenticity of a stranger before opening a secure access for the stranger, through the server 108 of FIG.1, according to an embodiment. In an example embodiment, in step 302, a stranger knocks a locked door. In step 304, the stranger's device obtains a long token and shares the long token with the resident's user device through sound waves. In step 306, a subtoken is shared verbally by the stranger to the resident who is reluctant to open the locked door and resident enters subtoken in resident user device. In a preferred embodiment the subtoken is a reusable subtoken. In step 308, the long token is communicated with the server by stranger's device. In step 310, existence of a predefined relationship is checked between the long token and the subtoken by the resident user device. In an embodiment, the predefined relationship exists between (a) the long token that is received at the resident user device from the stranger user or stranger user device, and (b) the subtoken that is received at the resident user device from the stranger user or stranger user device. In step 312, upon confirmation of predefined relationship server receives the long token from the resident device. In step 314, the server matches the long tokens of both users. In the event the check at step 310 fails, the flow moves to step 316, wherein location of devices is utilized to attempt an interaction between the stranger and the resident. In step 316, server receives subtoken and location of the resident device. At step 318, server matches subtokens of resident and stranger as the locations associated with the users are within a predefined area or threshold distance. In step 320, subtoken and location of stranger is communicated with the server. In step 322, upon a successful match of both long tokens or subtokens of both parties that are interacting at the given location, the server 108 records in a database. In step 324, a message is sent to both users or only to the resident by the server 108, stating that they have been successfully matched and the stranger is identified and authenticated to the system on his device. In step 326, the secure access may be opened by the resident confidently as the interaction is recorded by the server 108 where the stranger is a known user. In an embodiment a voice or video call can be initiated between the parties and thus precludes need for a security intercom. In one embodiment, stranger communicates his long token and subtoken into a door's interface, then receives an approval notice to approve opening of the door if the stranger, who is having a secured access to his device, is supposed to have access to the door. Upon stranger's approval, the door is sent a signal to unlock once so the stranger, who is now identified by the server, can enter from the door. The server or the door's interface, verifies that the long token has a predefined relationship with subtoken entered into the door's interface received from stranger or stranger's device. The steps 316, 318 and 320 are optional and are useful if for any reason the transmission of long token cannot he performed between stranger device and resident device, for example, if there is a background noise that is interfering with the long token communication. In that case, the predefined relationship may not be found, and location becomes the fallback option for initiating the interaction.

[00060] FIG. 4A and 4B is a flowchart that illustrates a method for pairing two devices which can exchange identity, data or read an allocated memory space of each other, through the server 108 of FIG.1, according to an embodiment. In an example embodiment, in step 402, the users of two devices agree to pair the devices. In step 404, a first user device gets a long token and shares the long token to a second user device through sound waves. In step 406, a first user verbally shares a subtoken to the second user, who is nearby. In step 408, the first user device communicates long token to a server and the second user enters the subtoken in to a second user device. In a preferred embodiment the subtoken is a reusable subtoken. In step 408, the first user device communicates long token to a server and the second user enters the subtoken into a second user device. In step, 410, existence of a predefined relationship is checked between the long token and the subtoken received from the first user by the second user device. In step 412, upon confirmation of predefined relationship the server matches the long tokens of both users. In the event the check at step 410 fails, the flow moves to step 420, wherein location of second user devices is utilized to attempt an interaction between the first user and the second user. The server receives subtoken and location of the resident device. At step 422, server matches subtokens of first user and second user as the locations associated with the users are within a predefined area or threshold distance. In step 424, the first user subtoken and location is communicated to the server. In step 426 both the user devices are matched by the server and two way pairing is initiated. 108. In step 428, the interaction and exchange of data or identity between the allocated memory of application devices is made.

[00061] FIG. 5A and 5B is a flowchart that illustrates a method for pairing one device 30 with plurality of devices which can exchange identity, data or read an allocated memory space in a one-way paired mode, through the server 108 of FIG 1, according to an embodiment. In an example embodiment, in step 502 the first user of a device gets data from plurality of devices. in step 504, the first user device 104 gets long token and shares the long token with user device N or a plurality of such users. In step 506, the first user 102 of the first user device 104 shares the subtoken with user device N or a plurality of such users (for example, a professor sharing his subtoken with his class) whose is nearby and within a predefined area. In a preferred embodiment the subtoken is a reusable subtoken. In step 508, the N user 112 enters the subtoken in the user device N 104. In step 520 the first user subtoken and location is communicated to the server. In step 510, the n user of device (n) checks for predefined relationship between long token and subtoken received from the first user. If predefined relationship doesn't exist then move to step 516. In step 516, the server receives subtoken and location from n user of device (n). In step, 518 the server matches both users subtokens and location as they are in predefined area. If predefined relationship exists then in step 512, the server matches long tokens of first user and (N) user. In step, 514 the server sends each user n devices first username, if they accept to send any data or allow data access to first user from their respective device. In step 524, all devices that agreed is one way paired with first user and first device. In step 526, the N user device can access data that is shared by the devices that is granted permission.

1.00062.1F1G. 6A and 6B is a flowchart that illustrates a method for pairing a device with a website which can exchange identity, data or read allocated memory space in a one way paired mode, through the server 108 of FIG. 1. In an example embodiment, in step 602, a device to send data to website. In step, 604 the device gets a long token and shares the long token to a user of a website. In step 606, the device shares subtoken to the user of the website. In a preferred embodiment the subtoken is a reusable subtoken. In step 608, the device communicates long token to a server and the user of the website enters the subtoken into the website. In step 610, the website checks for predefined relationship between long token and subtoken received from the device, if predefined relationship does not exist then move to step 616. In step 616, server receives subtoken and internet protocol address from the website. If predefined relationship exists then move to step 612. In step 612, server receives long token from website and matches long token of website and device. In 614, both device, user's subtokens and internet protocol address of latitude and longitude as they are in predefined area. In step 618, server translates internet protocol address into latitude and longitude location. In step 620, the device subtoken and internet protocol address is communicated to the server and server translates internet protocol address into location. In step 622, server sends the device, if they accept to send any data or allow data access to website, if they do not accept to send data or allow data access to website process ends at the step 628. If they accept to send data or allow data access to website move to step 624. In step 626, user of device agreed and one way paired with website. In step 626, website can access data is shared by the device that granted permission.

[00063] There is one way agreement as the permission is from first user device 104, so first user allocated memory may interact and send data to the website's session. This may easily be reversed wherein the subtoken is generated at the website and then shared with the second user device110, and then permission notification is sent to the website. Upon acceptance, the website session may send the data in a one-way flow to the device. in an embodiment, same person may be interacting with device as well as website interface, wherein same person is the first user and the second user. In a related embodiment, the step 622 notification to first user device may include a permission to login to the website. Upon acceptance, the user is logged into the website, wherein username of user is sent to from the server to correspond with the website session or ip address of the website instance.

[00064] FIG. 7A, 7B AND 7C is a flowchart that illustrates a method for pairing a website session with a device which can exchange identity, data or read an allocated memory space of each other, through the server 108 of FIG. 1, according to an embodiment. Therefore this is a two way pairing. In an example embodiment, in step 702, a device and a website are to be paired. In step 704, the device gets a long token and shares the long token with website user through sound waves. In step 705, the device shares a subtoken to the user of website. In a preferred embodiment the subtoken is a reusable subtoken. In step 706, the device communicates long token to a server and the user of the website enters the subtoken into the website. In step 708, a random password is shown to the user on website, the user enters the password on the device. In step 710, the website checks for predefined relationship between long token and subtoken received from the device. If predefined relationship does not exist then move to step 716. In step 716, server receives subtoken, random password and internet protocol address from the website. If predefined relationship exists then move to step 712. In step 712 the server receives long token from website and matches the long token of website and device. In step 714, server matches both device, user's subtokens and internet protocol address of latitude and longitude as they are in predefined area. In step 718, server translates internet protocol address into latitude and longitude location. In step 720, the device subtoken and location is communicated to the server. In step 722, upon successful match of both subtokens of device and website, two way paring is initiated. In step 724, allocated memory of application of device and website can interact and exchange data or identity. In one embodiment, when an approval is obtained from a user, it is a one-way pairing wherein only approving user is providing access, hence pairing is asymmetric. Whereas when second subtoken or password is employed, the pairing may be a two-way or symmetric.

[00065] FIG. 8A and 8B is a flowchart that illustrates a method for pairing a website session with another website session which can exchange identity, data or read allocated memory space of each other, through the server 108 of FIG. 1, according to an embodiment.

In an example embodiment, in step 802, two users to be two way paired on two websites or same website. In step 804, first user gets a long token from a first website and shares the long token to second user. In step 806 the first user shares a subtoken to the second user. In a preferred embodiment the subtoken is a reusable subtoken. In step 808, the first user communicates long token to a server and the second user of the website enters the subtoken into the second website. In step 810, a random password is shown to the second user on second website, the second user shares the random password to the first user of the first website and the first user enters the passwords on the first website. In step 812, the second website checks for predefined relationship between long token and subtoken received from the device. If predefined relationship does not exists then move to step 818. In step 818, server receives subtoken, random password and internet protocol address from the website. In step 820, server translates internet protocol address into latitude and longitude location. if predefined relationship exists then move to step 814. In step 814, the server receives long token from second website and server matches the long token of second and first website. In step 816 server matches both first website and second website subtokens, passwords and internet protocol address of latitude and longitude as they are in predefined area. In step 822, the first website subtoken and internet protocol address is communicated to the server. in step 824, upon successful match of both subtokens and passwords, two way pairing between users of websites is initiated. in step 826, allocated website instances can now interact and exchange data or identity between users. For example, now they can initiate a chatting session. In step 826, the allocated memory of application device and website can now interact and exchange the data or identity.

[00066] FIG. 9A, 9B and 9C is a flowchart that illustrates a method for pairing a website with another website which can exchange identity, data or read an allocated memory space of in a one way paired mode, through the server 108 of FIG. 1, according to an embodiment. In step 902, website instance to send data to same or another website. In step 904, first user gets a long token from a first website and shares the long token to second user website. In an embodiment this can be done using QR code or sound converted into electronic signal or data and sent to another user using a phone where it gets again converted into sound and captured by the website session of other user by computer mic. In step 906, the first user shares a subtoken to the second user. In a preferred embodiment the subtoken is a reusable subtoken. In step 908, the first user communicates long token to a server and the second user enters the subtoken in second website. In step 910, the website checks for predefined relationship between long token and subtoken received from the device, if predefined relationship does not exist move to step 916. In step 916, server receives subtoken, location from the website. If predefined relationship exists move to step 912. In step 912, server receives long token from first website and server matches long token of first website and second website. In step 914, server finds and matches both websites subtokens and location as they are in predefined area and locations are derived from internet protocol address. In step 918, the users subtoken and location is communicated to the server. In step 920, server sends to first website to accept to send any data or allow data access to second website. If not accept to send any data or allow data access to second website then end in step 922. In step 924, website user agrees and it pairs one way with website. In step 926, website may now access data that is shared by the user of website that grants permission.

[00067] FIG.10A and 10B is a user interface view 1000 of a subtoken generated by using a method such that identical subtokens may be used by several users simultaneously through a server 108 of FIG.1, according to an embodiment. in an example embodiment, in step 1002, the subtoken is generated in a payer device 104 to transfer the funds. A long token is transmitted from payer device to payee device. in step 1004, the subtoken is entered into a payee device, the subtoken may be a four digit numeric or alpha-numeric code that is shared by users verbally. Even subtoken can be shared by sound between devices. A subtoken gets manifested in one device or both devices, the transacting users agree on subtoken for transaction to process. In an embodiment, subtoken is simply spoken and it is a small 4 digit token. In step 1006, the payer 102 receives the name of payee 112 and amount.

The payer 102 may accept or decline the received information. In step 1008, upon the payment of the amount by the payer 102 to the payee 112, the payer 102 receives a transaction reference number on processing the transaction. The transaction reference number is saved in the application. In step 1010, upon the payment of the amount by the payer 102 to the payee 112, the payee device 110 receives a successful transaction message.

However, in an embodiment the subtoken flow may be reversed, that is, a subtoken may be passed from payee to payer. in an embodiment, the options of subtoken flow may be present, payer to payee and payee to payer and it is for the payer and payee to decide how they prefer to transact. hi an embodiment amount may be entered by payer. ln an embodiment, amount is entered by a payee. When amount is entered by payee, payer approves it by interacting with an approval notification. When amount is entered by payer, the amount is approved by payer. In an embodiment the amount is entered by payer, the payer may still have to approve a payee identifier by interacting with an approval notification. In an embodiment, amount is entered by payer and payee; the amount of payer and payee is matched in that case, as it acts and a equivalent password, for transaction to process. Password is explained in other embodiments.

[00068] In an example embodiment, in step 1002, the long token is generated in a payer device 104 to transfer the funds. in step 1004, the subtoken is entered into a payee device, the subtoken may be a four digit numeric or alpha-numeric code. In step 1006, the payer 102 receives the name of payee 112 and amount. The payer 102 may accept or decline 30 the received information. In step 1008, upon the payment of the amount by the payer 102 to 25 the payee 112, the payer 102 receives a transaction reference number on processing the transaction. The transaction reference number is saved in the application. In step 1010, upon the payment of the amount by the payer 102 to the payee 1 12, the payee device 110 receives a successful transaction message. However, in an embodiment the long token flow may be reversed, that is, a long token may be passed from payee to payer. In an embodiment, the options of long token flow may be present, payer to payee and payee to payer and it is for the payer and payee to decide how they prefer to transact. In an embodiment amount may be entered by payer. In an embodiment, amount is entered by a payee. When amount is entered by payee, payer approves it by interacting with an approval notification. When amount is entered by payer, the amount is approved by payer. In an embodiment the amount is entered by payer, the payer may still have to approve a payee identifier by interacting with an approval notification. In an embodiment, amount is entered by payer and payee; the amount of payer and payee is matched in that case, as it acts and a password, for transaction to process.

[00069] FIG. 11A, 11B, 11C and 11D is a flowchart that illustrates a method of payment by a nearby payee to a payer through the server 108 of FIG 1, according to an embodiment. In an example embodiment, in step 1102, a payer gets a long token and shares the long token to payee through sound waves. In step 1104, the payer verbally shares a subtoken to nearby payee. In a preferred embodiment the subtoken is a reusable subtoken. In step 1106, the payer communicates long token to a server and payee enters subtoken and amount into a payee device. In step 1108, the payee device checks for predefined relationship between long token and subtoken received from the payer. If predefined relationship exists the move to step 1110 else move to step 1112. In step 1112, the server receives subtoken and location from payee device. In step 1110, the server receives long token from payee device and matches the long tokens of both users. In step 1114, the server matches both users subtokens and location as they are in predefined area. In step 1116, the payer subtoken and location is communicated to server. In step 111 8, the server sends payer device, payee name and amount to accept or reject. This request is processed, in preferred embodiment, though not a requirement, only if the application is already open in the payee device 110. In step 1120, the request is declined and the payer device 104 is informed that the payment is declined by the payer 102. In step 1122, the request is accepted, and the server 108 receives approval from the payer 102. In step 1124, the payment request is sent through payment gateway to process the transaction. In step 1126, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. hit coin) escrow system. In the step 1128, a message is communicated to the payer device and the payee device indicating that the transaction is unsuccessful. In the step 1130, a message is communicated to the payer device and the payee device indicating that the transaction is successful. In an embodiment the payer or payee or both are securely logged into their respective devices or interfaces. Upon login, the server know the user's account details, such as account balance, or bank account details, or credit or debit card details. However, in an embodiment a login may not be necessary wherein account balance is associated to the device and not the user. In an embodiment credit available to a payer may be sent to a device by a server to compare with amount of transaction to determine outcome of a transaction, and updated credit available is reported hack to the server.

[00070] FIG. 12A, 12B, 12C and 12D is a flowchart that illustrates a method of payment to a payer by a payee and the payee gets token from any location in the world through the server 108 of FIG 1, according to an embodiment. In an example embodiment, in step 1202, the payer gets a long token. In step 1204, payer shares the long token to payee through sound waves or electronically. In step 1206, the payer verbally shares a subtoken to payee for any location in the world. In a preferred embodiment the subtoken is a reusable subtoken. In step 1208, the payer communicates long token to a server and payee enters subtoken and amount into payee device. In step 1210, the payee device checks for predefined relationship between long token and subtoken received from the payer. If the predefined relationship doesn't exists then move to step 1214 else move to 1212. In step 1214, the server receives subtoken and location from payee device. In step 1216, the server matches both users subtokens and location as they are in predefined area. In step 1212, the server receives long token from payee device and matches the payer 102 and the payee 112 on the basis of the same subtoken association and being within predefined area. In step 1218, the payer subtoken and location is communicated to server. In step 1220, the server sends payer device, payee name and amount to accept or reject. This request is processed, in preferred embodiment, though not a requirement, only if the application is already open in the payee device 110. In step 1222, the request is declined and the payee device 110 is informed that the payment is declined by the payer 102. In step 1224, the request is accepted, and the server 108 receives approval from the payer 102. In step 1226, the payment request is sent through payment gateway to process the transaction. in step 1228, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. bit coin) escrow system. In the step 1230, a message is communicated to the payer device and the payee device indicating that the transaction is unsuccessful. In the step 1232, a message is communicated to the payer device and the payee device indicating that the transaction is successful.

[00071] FIG. 13A, 13B, 13C and 13D is a flowchart that illustrates a method of payment to a payee through an ATM from payer's account with the server 108 of FIG. 1, according to an embodiment. In an example embodiment, in step 1302, the payer 102 requests for a long token. in step 1304, the payer shares the long token to ATM through sound waves. In step 1306, the payer device communicates the long token to a server. In step 1308, the payer enters the subtoken and amount into an ATM nearby. In a preferred embodiment the subtoken is a reusable subtoken. In step 1318, the payer communicates the subtoken and location to the server. In step 1310, the ATM checks for predefined relationship between long token and subtoken received from the payer. If the predefined relationship doesn't exist then move to step 1314 else move to step 1312. In step 1314, the server receives subtoken and location from ATM. In step 1316, the server matches user and ATM subtoken and location as they are in predefined area. In step 1312, the server receives long token from payee device and matches the long tokens of user and ATM. In step, 1320, the server sends payer device, payee atm identifier and amount to accept or reject. In step 1322, the request is declined and the ATM or its owner is informed that the payment is declined by the payer 102 who is trying to withdraw funds from ATM. In step 1324, the request is accepted, and the server I418 receives approval from the payer 102. in step 1326, the payment request is sent through payment gateway to process the transaction. In step 1328, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. bit coin) escrow system. In the step 1330, a message is communicated to the payer device and the ATM device indicating that the transaction is unsuccessful. In the step 1332, upon successful reservation of funds, cash is made accessible to payer 102 by the automatic teller machine, upon successful delivery of cash the transaction process is completed by the server 108.

[00072] FIG. 14A, 14B, 14C, 14D and 14E is a flowchart that illustrates a method of paying reclining payments to a payer by payee where they reach agreement while they are nearby through the server 108 of FIG 1, according to an embodiment. In an example embodiment, in step 1402, a payer gets a long token for its own location. In an embodiment the payer and payee are in different parts of the world and long token is share over phone using sound and its electronic transmission. In step 1404, the payer shares the long token to payee through sound waves. In step 1406, the payer verbally shares a subtoken to nearby payee and payee enters the subtoken into payee device. In a preferred embodiment the subtoken is a reusable subtoken. In step 1408, the payer communicates long token to a server and payee enters subtoken into payee device. In step 1418, the payer subtoken and location is communicated to the server. In step, 1410, the payee device checks for predefined relationship between long token and subtoken received from the payer. If the predefined relationship doesn't exist then move to step 1414 else move to 1412. In step 1414, the server receives subtoken and location from payee device. In step 1412, the server receives the long token from the payee device and matches the long tokens of both users. In step 1416, the server matches both users subtoken and location as they are in predefined area. In step 1420, the server sends payer device, payee name to accept or reject for multiple transactions. This request is processed, in preferred embodiment, though not a requirement, only if the application is already open in the payee device 110. In step 1422, the request is declined and the payee 112 is informed that the payment is declined by the payer 102. In step 1424, the request is accepted, and the server 108 receives approval from the payer 102. In step 1426, both the users are informed by the server 108 that the authority is received successfully. In step 1428, a globally unique identifier is generated by a sever 108, to identify agreement between both the users. In step 1430, the unique identifier is sent by the server 108 to payee device 110 or a payee's database where payee stores its customer contact information. In step 1432, the payee 112 may send debit requests with the unique identifier with amounts. In step 1434, the server 108 finds the payer 102 and matches with the payee112 based on unique identifier. in step 1436, the payment request is sent through payment gateway to process the transaction. in step 1440, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. hit coin) escrow system. in the step 1442, a message is communicated to the payer device and the payee device indicating that the transaction is unsuccessful. In the step 1444, a message is communicated to the payer device and the payee device indicating that the transaction is successful. The recurring payment continue uninterrupted even when payer changes its bank account as the payer can update account in its user device or user interface with new account details, and there is no need for payee to know payer's account details.

[00073] FIG. 15A, 15B, 15C, 15D and 15E is a flowchart that illustrates a method of paying recurring payments to a website, through the server 108 of FIG 1, according to an embodiment. In an example embodiment, in step 1502, a payer gets a long token. In step 1504, the payer shares the long token to website through sound waves. In step 1506, the payer enters a subtoken into website. In a preferred embodiment the subtoken is a reusable subtoken. in step I 508, the payer communicates long token to a server. In step 1518, the payer subtoken and location is communicated to server. In step 1510, the payee device checks for predefined relationship between long token and subtoken received from the payer. If the predefined relationship doesn't exist then move to step 1514 else move to 1512. In step 1514, the server receives subtoken and location translated from IP address of website. In step 1512, the server receives long token from website and matches the long tokens of payer. In step 1516, the server matches payer and website subtokens and location as they are in predefined area. In step 1520, the server sends payer device, website name to accept or reject for transactions. This request is processed, in preferred embodiment, though not a requirement, only if the application is already open in the payee device 110. In step 1522, the request is declined and the website is informed that the payment is declined by the payer 102. in step 1524, the request is accepted, and the server 108 receives approval from the payer 102. In step 1526, the website and the payer 102 are informed by the server 108 that the authority is received successfully. In step 1528, a globally unique identifier is generated by a sever 108, to identify agreement between the payer 102 and the website. In step 1530, the unique identifier is sent by the server 108 to the website where the unique identifier is stored and associated with the payer in its customer database. In step 1532, the website may send debit requests with the unique identifier with amounts. In step 1536, the server 108 finds the wehsite and matches with the payer 102 based on unique identifier to confirm the agreement of payments between the payer and the website. In step 1538, the payment request is sent through payment gateway to process the transaction. In step 1540, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. bitcoin) escrow system. In the step 1542, a message is communicated to the payer device and the payee website indicating that the transaction is unsuccessful. In the step 1544, a message is communicated to the payer website and the payee device indicating that the transaction is successful. The method explained in the embodiment can easily be reversed where a website is a payer 102 and a user is a payee 112 that is able to transfer payment regularly. A payment is a payment, and when the payment is a negative, leveraging the agreement identifier, it is still a payment wherein a payer 102 is now a payee 112 and payee 112 is now a payer 102.

[00074] FIG. 16A, 16B, 16C, 16D,is a flowchart that illustrates a method of purchase from a payer to a payee through an automatic vending machine (AVM) in the server 108 of FIG 1, according to an embodiment. In an example embodiment, in step 1602, a payer gets a long token. In step 1604, a subtoken for current location is made visible in a payer device.

In step 1606, the payer communicates long token to a server and payer enters the subtoken and amount in to an automatic vending machine nearby. In a preferred embodiment the subtoken is a reusable subtoken. In step 1608, the automatic vending machine checks for predefined relationship between long token and subtoken received from the payer. If the predefined relationship doesn't exist then move to step 1612 else move to 1610. In step 1612, the server receives subtoken and location from automatic vending machine. In step 1610, the server receives long token from AVM and matches the long tokens of payer and AVM. In step 1614, the server matches payer and AVM subtokens and location as they are in predefined area. In step 1618, the server sends payer device, payee name to accept or reject for transactions. In step 1620, the request is declined and the automatic vending machine is informed that the payment is declined by the payer 102. In step 1622, the request is accepted, and the server 108 receives approval from the payer 102. In step 1624, the payment data is sent through the payment gateway. In step 1626, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. hit coin) escrow system. In the step 1628, a message is communicated to the payer device and the payee device indicating that the transaction is unsuccessful. In the step 1630 upon successful reservation of funds, goods are made accessible to the payer 102 by the automatic vending machine, upon successful deliver of goods purchased and transaction is process is completed by the server 108.

[00075] FIG. 17A, 17B, 17C, 17D, is a flowchart that illustrates a method of purchase from a payer to a payee through an automatic checkout machine (ACM) in the server 108 of FIG 1, according to an embodiment herein. In an example embodiment, in step 1702, a payer gets a long token. In step 1704, a subtoken for current location is made visible in a payer device. In step 1706, the payer communicates long token to a server and payer enters the subtoken and amount in to an automatic checkout machine nearby. In a preferred embodiment the subtoken is a reusable subtoken. In step 1708, the automatic vending machine checks for predefined relationship between long token and subtoken received from the payer. If the predefined relationship doesn't exist then move to step 1712 else move to 1710. In step 1712, the server receives subtoken and location from automatic vending machine. In step 1710, the server receives long token from ACM and matches the long tokens of payer and ACM as they are in predefined area. In step 1714, the server matches payer and ACM subtokens and location as they are in predefined area. In step 1718, the payer subtoken and location is communicated to server. In step 1720, the server sends payer device, payee name to accept or reject for transactions. In step 1722, the request is declined and the payee 112 is informed that the payment is declined by the payer 102. In step 1724, the request is accepted, and the server 108 receives approval from the payer 102. In step 1726, the payment data is sent through the payment gateway. In step 1728, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. bit coin) escrow system. In the step 1728, a message is communicated to the payer device and the payee device indicating that the transaction is unsuccessful. In the step 1730, a message is communicated to the payer device and the payee device indicating that the transaction is successful. The automatic check out machine can be a self-checkout where the shopper is interacting with its device and also the machine or the machine may he manned by a checkout clerk who is interacting with the machine and shopper is interacting with its device only.

[00076] FIG. 18A, 18B, 18C, I 8D, is a flowchart that illustrates a method of purchase from a payer to a website through the server 108 of FIG 1, according to an embodiment herein. In an example embodiment, in step 1802, a payer gets a long token for a current location. In step 1804, a subtoken is made visible in a payer device. In a preferred embodiment the subtoken is a reusable subtoken. In step 1806, the payer communicates long token to a server and payer enters the subtoken into the website to pay. In step 1808, the website checks for predefined relationship between long token and subtoken received from the payer. If the predefined relationship doesn't exist then move to step 1812 else move to 1810. In step 1812, the server receives subtoken and internet protocol address from website. In step 1810, the server receives long token from website and matches the long tokens of website with payer device long token. In step 1816, the server matches payer and website subtokens and internet protocol address of latitude and longitude as they are in predefined area. In step 1818, the payer subtoken and location is communicated to server. Internet protocol address of website gets converted into location. In step 1820, the server 108 sends the payer device 104 and website name, a notification to accept or decline the amount. In step 1822, the request is declined and the website is informed that the payment is declined by the payer 102. In step 1824, the request is accepted, and the server 108 receives approval from the payer 102. In step 1826, the payment data is sent through the payment gateway. In step 1828, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. bit coin) escrow system. In the step 1830, a message is communicated to the payer device and the payee device indicating that the transaction is unsuccessful. In the step 1832, a message is communicated to the payer device and the payee device indicating that the transaction is successful.

[00077] FIG. 19A, 19B, 19C, 19D, is a flowchart that illustrates a method of purchase by a website user (payer) to an application through the server 108 of FIG 1, according to an 30 embodiment. In an example embodiment, in step 1902, a payer gets a long token for a 33 website account. In step 1904, a subtoken is made visible in a website. In a preferred embodiment the subtoken is a reusable subtoken. in step 1906, the payer communicates long token to a server and payer enters the subtoken and amount in to an application. in step 1908, the application checks for predefined relationship between long token and subtoken received from the payer. if the predefined relationship doesn't exist then move to step 1912 else move to 1910. In step 1912, the server receives subtoken and location from application. In step 1910, the server receives long token from application and matches the long tokens of both users. In step 1914, the server matches payer and applications subtokens and location as they are in predefined area. Internet protocol address of website gets converted into location.

In step 1916, the payer subtoken and location is communicated to server. In step 1918, the server 108 sends the website, the application name with a notification to accept or decline the amount. In step 1920, the request is declined and the application is informed that the payment is declined by the payer 102. In step 1922, the request is accepted, and the server 108 receives approval from the payer 102. In step 1924, the payment data is sent through the payment gateway. In step 1926, the outcome of the payment is received from the gateway that may connect to banks, an accounting system or a crypto currency (e.g. hit coin) escrow system. In the step 1928, a message is communicated to the payer website user and the payee application indicating that the transaction is unsuccessful. In the step 1930, a message is communicated to the payer website user and the payee application indicating that the transaction is successful.

1.00078] FIG. 20 is a flowchart that illustrates a method of transmission of transaction document (e.g. a purchase receipt) through the server 108 of FIG 1, according to an embodiment. In an example embodiment, in step 2002, the payee 112 sends the document with metadata location of the long token or subtoken, the long token or subtoken and date & time stamp of the transaction. In step 2004, the document is matched by the server 108 with the payer device 104 based on the metadata within the predefined area. In step 2006, the file is sent by the server 108 to the user. This method may easily be reversed wherein a payer 102 wants to send a document to a payee 112 by using the same metadata. However, as the devices may be one-way paired as well as explained already, the itemized description of each item that is being purchased can be shown in real time one-by-one or together on the shopper's device before the payment is approved. Hence, shopper can see list of items being scanned on its own device rather than screen associated with the merchant prior to approving a payment.

[00079] FIG. 21 is a flowchart that illustrates a method of transmission of multiple transaction documents (e.g. a utility bill) based on an agreement identifier through the server 108, according to an embodiment. In an example embodiment, in step 2102, the bill is sent by the payee 112 to the server 108 with a metadata of the unique agreement identifier. In step 2104, the payer 102 is determined by the server 108 which is associated with the unique agreement identifier. In step 2106, the file is sent by the server 108 to payer 102. Hence documents such as utility bill may be sent regularly without exchanging details such as email address. The embodiment may be easily reversed where the file, for example a salary slip for an agreement between an employer who is a payer and an employee who is a payee 112, is sent by the server 108 to the payee 112.

[00080] FIG. 22 illustrates an interface view of a database model of the token generation through the server 108 of FIG.1, according to an embodiment. The server 108 includes an assumed location 2202, a user table 2204, a unique identifier 2206 for agreements or authorisations between users, a website session 2208, a merchant 2210, a location table 2212 and an employee 2214. An assumed location 2202 may have several profiles or locations where a user is not physically available but he would like to acquire a token. The user table 2204 has a current location, a device id, and a long token or a subtoken based on its current location in the table. The merchant 2210 may have many locations, and each location may have many employees 2214. The employee 2214 may have access in the same lines as that of the user, but acts on behalf of the business. The business can have a fixed location defined in the location table 2212.

[00081] The unique identifier 2206 stores one-way or two authorisations or agreements between first user device 104 and second user device 110, and either of the user may he a merchant 2210. The website sessions 2208 stores an internet protocol address, a calculated location of the internet protocol address, a website and a session ID of the user interacting with the long token or the subtoken. The merchant is participating in loyalty programs 2216, and user is member of those loyalty programs 2218. The shopping data that is agreed between user and merchant to share is shared with the server of the respective loyalty program.

[00082] FIG. 23A and FIG. 23B illustrates a method for pairing two devices in geographically non-intersecting areas through the server 108 of FIG I, according to an embodiment. The method includes four concentric circles Al, A2, Bl and B2. In FIG. 23A, it is demonstrated by a geometric drawing that all points within Al are closer than any two points, where one point is in Al and other point is in Bl. Al and B1 have radius r, and A2 and B2 and radius R. A2 and B2 are non-intersecting, therefore in a limiting case they may be touching tangentially. B1 and Al have a radius value of r where any two points within Al are closer than any two points, between Al and Bl. The maximum distance possible between any two points in circle Al is 2r. The minimum distance possible between any two points, Al and B1 is 2(R-r). A non-unique long token or subtoken can be generated at the centre of Al, and deactivated as soon as it reaches the circumference of Al to ensure it always remain farther than 2(R-r) from another identical long token or subtoken within B2.

Larger circles A2 and B2 have to be at least two times as big as smaller circles Al and B1 in terms of radius for this to happen. Prior to granting a random long token or subtoken to a user with associated location at centre on Al, the method checks for presence of other identical active long tokens or subtokens associated with any point within the radius 2R from the centre of Al, which is distance between centre of A2 and B2 at their nearest limiting case. Likewise, prior to granting a random long token or subtoken to a user with associated location at centre on Bl, the method checks for presence of another identical active long token or subtoken associated with any point within radius 2R from the centre of Bl. If another identical active long token or subtoken exists for another user in associated with a point in radius 2R from centre of Al, another random long token or subtoken is checked.

Once a long token or subtoken is generated at a location, it is considered to be associated with the specific areaA2 around the location, that is, centre of A2, and it is associated with the location that is centre of A2. if there is another identical long token or subtoken, even outside the circleA2, if its own associated area overlaps with A2, it is considered that an identical long token or subtoken already associated with this area, and the server 108 attempts to find another long token or subtoken for the location. Moreover, the two identical long tokens or subtokens must not move out of inner circles Al and Bl, for them to always remain farther than 2r from each other. An identical long token or subtoken must he at least 2R distance at the time of association with a location from the nearest identical long token's or subtoken's location for non-intersecting areas through the server 108 of FIG I where that location is characterised by a circle or radius R. [00083] In FIG. 23B, an example is made by placing location associated devices in the circles Al, A2, B1 and B2. Moreover, this location need not be actual locations of devices, as uses can assume locations that are different from their physical locations. FIG. 23B is demonstrated by a geometric drawing where D1 and D2 are within Al and D3 is in Bl. In one embodiment, Al and Bi have a radius 5km, wherein a long token or subtoken is deactivated before it reaches the circumference of inner circle whist approaching from the boundary from centre outward, and A2 and B2 and radius 10km. B2 and A2 are non-intersecting. B1 and Al have a value of 5km where any two points within Al are closer than any two points, between Al and B I. Hence, Di, and D2 are closer than Di and D3 or D2 and D3. The maximum distance possible between any two points in circle Al is 2r i.e. 10km.

The minimum distance possible between any two points, Al and B2 is 2(R-r) i.e 10km. A non-unique long token or subtoken may be obtained by device DI at the centre of A2. The long token or subtoken is deactivated if DI obtained long token or subtoken for its physical location and approaches the circumference of Al to ensure it always remains farther than 2(R-r) i.e. 10km from another identical long token or subtoken associated with device D3, within B2. In one embodiment, prior to generating or associating a long token or subtoken for a location, a server will have to check for presence of an identical long token or subtoken for at least 20 Km radius from this location for which long token or subtoken is being generated. Hence, now two identical long tokens or subtokens can be simultaneously utilised by devices. If device Dl shares this long token or subtoken with any device D2 that is within Al, or whose associated location is inside Al, a server can determine conclusively that this long token or subtoken was received from Dl and no D3 despite both having identical long token or subtokens by calculating distances associated with the long tokens or subtokens. Since any number of such circles can be made, therefore unlimited number of identical long tokens or subtokens can be generated and processed simultaneously by users.

[00084] FIG. 24A and FIG. 24B illustrates a method for pairing two devices in geographically intersecting areas through the server 108 of FIG. 1, according to an embodiment. The method includes four concentric circles A I, A2, B1 and B2, in a limiting case, B2 will tangentially touch Al and vice versa. Al and B1 have radius r, and A2 and B2 and radius R. Large circles A2 and B2 are allowed to intersect. Maximum distance possible between any two points in circle Al is 2r. Minimum distance possible between any two points, one in Al and other in B1 is (R-r). if overlapping of large circles A2 and B2 is allowed, large circles A2 and B2 has to be at least three times as big in terms of radius compared to small circles Al and Bl. In one embodiment, prior to associating a long token or subtoken with a location, a server must check for present of another identical active long token or subtoken associated with a location that is within 4r distance of this location, which is distance between centre of A2 and B2 at their nearest limiting case. Whereas in the previous example, it was 2R, but the ratio of r and R was 2, hence, even then this value was 4r. Hence, for circles, the nearest identical long token or subtoken has to be more than 4r where freedom of play allowed for a long token or subtoken is 2r, that is diameter of the inner circle, long token or subtoken being obtained at the centre. The circles A2 and B2 are just for visual understanding as distances may be determined in multiples of r.

[00085] In FIG. 24B, an example is made by placing location associated devices in the circles Al, A2, B1 and B2. Moreover, these locations need not be actual locations of devices, as uses can assume locations that are different from their physical locations. FIG. 24B illustrates a method for pairing two devices in geographically intersecting areas through the server 108 of FIG. 1, according to an embodiment herein.A1 and B1 have radius r i.e. 4km, and A2 and B2 and radius R i.e. 12km. Large circles A2 and B2 are allowed to intersect. Maximum distance possible between any two points in circle Al is 2r i.e. 8KM.

Minimum distance possible between any two points, one is Al and other is B2 is (R-r) i.e. 8KM. If overlapping of large circles A2 and B2 is allowed, large circles A2 and B2, has to be at least three times as big in terms of radius compared to small circles Al and B I. The server would need to check for presence of another identical long token or subtoken within at least 16Km radius, which is minimum distance between centre of A2 and B2 for the limiting case. Hence, now two identical long tokens or subtokens may be simultaneously utilised by devices. Since any number of such circles can be made, therefore unlimited number of identical long tokens or subtokens may he generated and processed simultaneously.

[00086] FIG. 25 is a flowchart that illustrates a method for long token or subtoken generation in a device, through the server 108 of FIG. I, according to an embodiment. In step 2502, a set or array of random numbers for a location is generated by a device. In step 2504, the location, a device identifier and the set of random numbers is received by the server 108 of FIG. 1. In an embodiment the location may be obtained from a profile location of the user already stored in server. In step 2506, a subtoken from the array is elected by the server 108 of FIG. 1, for check. In step 2508, the server 108 of FIG. 1, checks if the subtoken already exists in live/active state within predefined area from the location. In step 2510, if all attempts to find subtoken fail, the server 108 finds maximum subtoken in the predefined area and increments it by one and sends it to device. In step 2512, serial of the subtoken within the set or array is communicated to the device. In step 2514, the subtoken associated with the serial is displayed on the device. A similar check can he done by the device wherein device receives all the active subtokens within its predefined area from the server and generates a unique subtoken that is not in the list sent by the server. In step 2526, a 20 character long random long token is appended before subtoken to generate a long token. In this method long token or subtoken is getting associated with a location where long token or subtoken is generated by device.

[00087] FIG. 26 is a flowchart that illustrates a method for long token or subtoken generation in a server 108 of FIG. 1, according to an embodiment. In step 2602, the subtoken for a location is requested by the device. In step 2604, the location and a device identifier is received by the server 108. In step 2606, a random subtoken is generated by the server 108. In step 2608, the server 108, checks if this subtoken already exists in live/active state within predefined area from the location. In step 2610, if three attempts to find subtoken fail, the server 108 finds maximum subtoken in the predefined area and increments it by one and sends it to the device. In step 2612, the subtoken is communicated to the device. In step 2614, a subtoken is displayed on the device. In step 2616, a 30 character long random string is appended before subtoken to generate a long token. In this method subtoken is getting associated with a location where subtoken is generated by server. In the same manner, comparison subtokens may also be done by device as well as server. For device comparison of subtokens, the server may a send all the subtokens that are obtained by first users within predefined area to a second user device and second user device may perform the matching within its own processor and confirm to server that a match has been found. Or the device may send a long token or subtoken to the server and server may match the received subtoken with all the obtained subtokens with a predefined area to find a match between first user and second user subtokens.

[00088] FIG. 27 illustrates a method for obtaining a long token or subtoken for authenticating an interaction between a first user device and a second user device according to an embodiment. In step 2702, an input from the first user 102 including a request to associate a long token or a subtoken with a first user device is received. In step 2704, the long token or the subtoken with the first user device is associated and a subtoken is derived or obtained from the long token or the long token is derived or obtained from the subtoken based on a predefined relationship. In step 2706, a confirmation of validation or data is obtained from which the confirmation is derived from the second user device for processing an interaction when the predefined relationship exists between (a) the long token that is received at the second user device from the first user or first user device, and (b) the subtoken that is received at the second user device from the first user or first user device. In step 2708, an interaction is processed between the first user and the second user based on the confirmation obtained from the validation confirmation obtaining module.

[00089] FIG. 28 is a schematic diagram of a computer architecture used in accordance to the embodiments herein. The system includes at least one processor or central processing unit (CPU) 10. The CPUs 10 are interconnected via system bus 12 to various devices such as a random access memory (RAM) 14, read-only memory (ROM) 16, and an input/output (I/0) adapter 18. The I/0 adapter 18 can connect to peripheral devices, such as disk units 11 and tape drives 13, or other program storage devices that are readable by the system. The system can read the inventive instructions on the program storage devices and follow these instructions to execute the methodology of the embodiments herein.

[00090] The system further includes a user interface adapter 19 that connects a 30 keyboard 15, mouse 17, speaker 24, microphone 22, and/or other user interface devices such as a touch screen device (not shown) or a remote control to the bus 12 to gather user input. Additionally, a communication adapter 20 connects the bus 12 to a data processing network 25, and a display adapter 21 connects the bus 12 to a display device 23 which may be embodied as an output device such as a monitor, printer, or transmitter, for example.

[0009 This invention leverages the geo-spatial nature of computational devices such as smart phones. Even desktops have internet protocol addresses, and these addresses are mappable on to geo-locations as there are many websites that presently locate, that is, latitude and longitude, desktop within a reasonable error. Areas of concentric shapes can be made such that all points within the inner area are closer to each other than any two points of distant non-intersecting concentric areas. By combining this geometric property with available technology, a new method of generating long tokens and subtokens is devised wherein identical long tokens and subtokens can be used by many users simultaneously. This method is not limited to circles as many shapes can made within the scope of invention. This would lead to smaller subtokens that can he easily spoken by humans verbally. This will preclude the need for users to scan large subtokens by NFC tags and QR codes. However, this type of subtoken can as well be transmitted by scans like QR code and NFC tags etc. Moreover, in addition to a location specific token associated with interacting interfaces or user have to be within a threshold distance, in some embodiments they must be within a threshold distance of a secret location. The secret location will add another factor of authentication in addition to matching of subtokens and threshold-ness of the subtokens of interacting parties. For example, a bank may not allow its employee to login into bank's network unless a subtoken is obtained from a smart phone in which the bank employee is logged in, and entered into a desktop, and then accept login notification on his smart phone, but in addition to all of these, the subtoken must have been acquired of a secret location.

Therefore, if the smart phone is stolen or acquired for misuse, even with a logged in access to the smart phone, a hacker cannot access the banks network unless the hacker also knows the secret location for which the subtoken has to he obtained. This establishes use of location associated subtokens in its own right even without them to be unique within a predefined area. A mobile number in addition to subtoken, would further simplify the transaction between two parties. A username (such as user's email address) may also be replaced by subtoken in order to login. Users logging in using email and phone number. Users are already used to making payments using email and phone number. An even smaller subtoken like 4 digits is very convenient for users to login or make payments. Using this invention, a user is able to utilise all of these options. A payer is able to make payment without sharing card details with a merchant or nor a shopper when shopper is not paying for the purchase.

Moreover various devices are used for reading payment data from credit cards. Users have ready access to smartphones and reader-devices are used to convert smartphones in card reading devices. Using this invention a device can receive and pay perform both actions without need for reader-devices thereby anyone can quickly receive payments as well using smartphone.

[00092] The description of the specific embodiments herein so fully reveals the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to he understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the invention.