WO2017115386A1

WO2017115386A1 - Multi-account mapping system and method

Info

Publication number: WO2017115386A1
Application number: PCT/IN2016/050459
Authority: WO
Inventors: Sunil Kumar HASIJA
Original assignee: Hasija Sunil Kumar
Priority date: 2015-12-28
Filing date: 2016-12-28
Publication date: 2017-07-06

Abstract

A multi-account mapping system and method is disclosed. The system includes a universal card comprising multiple slots, each slot having an associated multi-digit identifier and being mapped to at least one account, the at least one account is selected from preconfigured types of account; a database that stores the mappings of the slot and the at least one account along with details of the universal card; and an interface module that facilitates access of the at least one account mapped to the universal card.

Description

Multi-Account Mapping System and Method

Field of the Invention

[001] The present invention relates to account access systems, specifically, the present invention relates to a universal card for mapping and accessing multiple accounts. Background

[002] It is common for an individual to hold multiple accounts like bank accounts, credit card accounts, social media accounts, etc. Debit cards, credit cards, reward cards, etc. are commonly used by an individual to withdraw money or for other transactions. Typically, for a single account, a debit card or a credit card is issued by the concerned bank. Such a card may be a physical card provided to an account holder. In case the account holder has multiple accounts in other banks, the account holder would hold equivalent number of cards.

[003] Similarly, an individual may have to carry multiple reward cards or coupons or details of email accounts, etc. Maintaining details of all such multiple accounts may be uncomfortable and risky. Even if one of such cards is misplaced, the account holder would be required to go thru the ordeal of contacting the relevant authority, performing formalities and getting the account in order.

Summary

[004] In accordance with an embodiment of the present disclosure, a multi-account mapping system is disclosed. The system includes a universal card comprising multiple slots, each slot having an associated multi-digit identifier and being mapped to at least one account, the at least one account is selected from preconfigured types of account; a database that stores the mappings of the slot and the at least one account along with details of the universal card; and an interface module that facilitates access of the at least one account mapped to the universal card. [005] The foregoing and other features and advantages of the invention will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures. Brief Description of Drawings

[006] FIG. 1 shows, in a block diagram a multi-account mapping system in accordance with an embodiment of the present invention.

[007] FIG. 2 is a block diagram depicting various modules of the client side application in accordance with an embodiment of the present invention.

[008] FIG. 3 is a block diagram that depicts various modules of the server side application in accordance with an embodiment of the present invention.

[009] FIG. 4A illustrates the logical flow of registration process for first time users for mapping one account to one slot in accordance with an embodiment of the present invention. [0010] FIG. 4B illustrates the logical flow of registration process for first time users to map multiple accounts to one slot in accordance with an embodiment of the present invention.

[0011] FIG. 4C illustrates logical flow for creating login password in accordance with an embodiment of the present invention.

[0012] FIG.5 illustrates a flow chart depicting steps for accessing an account linked to a universal card in accordance with an embodiment of the present invention.

[0013] FIG. 6 illustrates a flow chart depicting steps for accessing one type of account linked to a multi-digit identifier of a universal card in accordance with an embodiment of the present invention.

[0014] FIG 7 illustrates an exemplary access procedure of the accounts mapped to a universal card in accordance with an embodiment of the present invention .

Description

[0015] The present disclosure provides a universal card via which an account holder may be able to access multiple accounts. The universal card may be a physical card or a virtual card.

Multiple accounts include bank accounts for which debit cards or credit cards, reward cards, metro travel cards, loyalty cards, etc. are issued to an account holder, one or more wallets of an account holder, one or more stock trading accounts, one or more derivative accounts, one or more insurance accounts, one or more email accounts, one or more social media accounts, one or more mobile no. accounts, one or more DTH accounts, one or more utilities, one or more job portals, one or more institution logins, one or more employee logins, one or more student logins, one or more hotel room key, one or more automobile key, one or more NFC (near field communication) transaction login, one or more M2M (Machine to machine) login, one or more UPI (unified payment interface) login, etc. In accordance with an embodiment, one universal card may be mapped to ten different accounts of an individual/entity. Entity includes without limitation a company, a firm, a trust, etc.

[0016] FIG. 1 shows, in a block diagram, the preferred embodiment of the multi-account mapping system of the present invention. The multi-account mapping system consists of a universal card 10 (not shown), a client device 20, a universal card server 30, a network 40 and one or more external servers 50. A detailed description of each is as follows: [0017] The universal card 10 may be a physical card or a virtual card. The physical card may be a plastic card incorporating one or more security features. In case the universal card is a virtual card, it may be a text file, an alphanumeric code, an animation, a multimedia file, a Uniform Resource Locator (URL), a Quick Response Code (QR code), a bar code, a biometric input, a one time password (OTP), a token, a short code, a sentence, a scanned image, a photograph, a Short Message Service (SMS), a personal message, an email, a widget plugin, a powerpoint file, a zip file, a rar file, an iso file, etc. saved by a user on a mobile device or some computer storage.

[0018] Multiple accounts of a user may be mapped to a single universal card 10. Each universal card 10 may have a card identifier. The card identifier may be a 12-digits number, a 16-digits number, an alphanumeric number, a picture, a string of special characters, a QR code, a bar code, etc. or combinations thereof. Optionally, in case of a physical universal card, a security feature say, a magnetic stripe, a hologram, an EMV chip, a chip, etc. containing information of the user may be incorporated at the back side of the universal card 10. Additionally, the universal card 10 may also have printed thereon the user's name and/or any other relevant or desired information. For reasons that will be more apparent further herein, the user's name and/or other relevant information, such as, for example, demographic data may also be encoded within the security feature.

[0019] In an embodiment, when the universal card 10 is issued to the user, login details of the universal card including password/personal identification number (PIN code) for accessing the card may also be issued. The password/PIN code may be a multi-digit number comprising of numeric, alphabets, alphanumeric digits or special characters, a sentence, a QR code, a bar code, an URL Link, a download link, a biometric input, a token, an OTP, a widget plugin, a text file, a powerpoint, an excel file, an animation, a multimedia input, a short code, a scanned image, a photograph, an SMS, an email, a personal message, a Bluetooth connection, a Wifi connection, an infrared input, a sound file, etc. [0020] The client device 20 includes without limitation a smartphone, a personal computer, a personal digital assistants (PDA), a smart phone, a laptop, a tablet, an automatic teller machine (ATM) terminal, a swiping machine, a point of sale (POS) terminal, a wearable device, or another type of communication devices. In an embodiment, in order to implement the teachings of the present disclosure, it is preferred that the client device 20 may have predefined capabilities such as a camera, a recording software, a biometric sensor, an input/output device, etc. Further, the client device 20 may consist of a processor, a memory and a client side application 100.

[0021] The processor controls and coordinates the functioning of all the modules of the client side application 100 stored in the memory. A detailed description of all the modules such as an identification module 201, a processing module 203, an interface module 205 and a communication module 207 will be discussed in details in FIG. 2.

[0022] The universal card server 30 may be a heterogeneous server or a cloud server. The universal card server 30 establishes a communication between the client device 20 and one or more external servers 50. The universal card server 30 consists of a server side application 200. The server side application 200 consists of various modules such as a processing module 301, an identifier generation module 303, a multi-digit identification module 305, an authentication module 307, a notification module 309, and a communication module 311. Further, the server side application 200 also consists of a database 313. A detailed description of each module will be discussed in FIG. 3. [0023] In one embodiment, the universal card server 30, external servers 50 and the client devices 20 correspond with each other via a network 40. The network 40 may be for example, Internet, a local area network (LAN), other wide area network (WAN), a telephone network, such as the Public Switched Telephone Network (PSTN), an intranet, or a combination of networks. The network 40 may be wired, wireless, or a combination of wired and wireless. [0024] The external server 50 (such as VISA^®, MASTERCARD^®, private server, application server, email server, etc.) includes any web server with processing capabilities and/or capability to receive and respond to requests of client device 20 via the server 30.

[0025] FIG. 2 is a block diagram depicting various modules of the client side application 100. The modules include without limitation an identification module 201, a processing module 203, an interface module 205 and a communication module 207. A detailed description of each module is as follows:

[0026] The identification module 201 may receive inputs from the user. The user may provide inputs via keypad, various sensors, scanners or recognizers such as a fingerprint scanner, image recognition integrated system (IRIS) scanner, facial recognition, voice recognition or other biometric sensors installed therein.

[0027] The processing module 203 controls and coordinates the functioning of all the modules.

[0028] The interface module 205 provides an interface through which the user may conduct a financial transaction, register his personal details, contact details, bank details, etc. The interface module 205 also provides an interface via which the user may register/access one or multiple accounts. In an embodiment, the interface provided by the interface module 205 may be a graphical user interface.

[0029] The communication module 207 establishes communication of the client device 20 with the server 30 and/or the external server 50 via the network 40. [0030] FIG. 3 is a block diagram that depicts various modules of the server side application 200. The modules may be a processing module 301, an identifier generation module 303, a multi- digit identification module 305, an authentication module 307, a notification module 309, and a communication module 311. Further, the server side application 200 includes a database 313. A detailed description of each module is as follows: [0031] The processing module 301 controls and coordinates the functioning of all the modules.

[0032] The identifier generation module 303 generates a unique card identifier for each universal card issued to a user. Optionally/additionally, the identifier generation module 303 generates a unique password/PIN code for each universal card issued to a user. The password/PIN code may be a multi-digit number comprising of alphabets, alphanumeric digits special characters, a URL, QR code, etc. [0033] The multi-digit identification module 305 generates a unique multi-digit identifier for each user. A multi-digit identifier may be a multi-digit number comprising of numeric digits, alphabets, alphanumeric digits, special characters, a URL, QR code, etc. In an embodiment, one of the digits of the multi-digit identifier indicates a slot position of an account which is mapped to the universal card. This digit may be prefixed by the system or user depending upon the configuration of the system. Remaining digits of the multi-digit identifier indicate password/PIN code for accessing the mapped account. Further, the multi-digit identification module 305 may be configured to display or hide the digit of the multi-digit identifier indicating the slot position. For example, if the multi-digit identifier is a URL or a QR code, the multi-digit identification module may maintain a lookup table mapping the multi-digit identifier to corresponding account and slot position but in such case the digit indicating slot position is not displayed.

[0034] In an embodiment, the multi-digit identification module 305 may be configured to generate various combinations of the digits of the unique multi-digit identifier. Each combination of the digits may be mapped to one or more accounts of different types. Alternately, the user may generate various combinations of the digits of the unique multi-digit identifier generated by the multi-digit identification module 305. As described above, the accounts may be of same type say bank accounts or varied accounts like coupons, rewards accounts, stocks, email accounts, etc.

[0035] For example, in a 5 digit identifier AB12C, we consider three combinations - AB12C, AB2C2, and AC3B2. Say, in this, the third digit indicates the slot number of an account that is mapped. Then, access password for one or more first accounts is AB12C, access password for one or more second accounts is AB2C2 while access password for one or more third accounts is AC3B2. In an embodiment, the digit indicating the slot number is prefixed by the system. Alternately, the digit indicating the slot position may be user-defined. In numerous variations to the teachings of the present invention, the digit indicating the slot position may be rule-based. For example, rather than having a dedicated digit to indicate slot position, sum of digits of the multi-digit identifier may indicate the slot position of an account. Other such variations are within the scope of the teachings of the present disclosure.

[0036] In an embodiment, the multi-digit identification module 305 may reserve one or more slot for specific type of accounts to be mapped. Say, slot 2 and 4 to be mapped only to stocks while 6 and 7 to be mapped only to credit cards. [0037] The authentication module 307 authenticates a user of the universal card. In an embodiment, the authentication module 307 authenticates a user at various stages when accessing the universal card or an account linked therein. For example, when the user logins by entering the card number/username and/or the password/PIN code for the first time of the universal card, the authentication module 307 checks whether the user is an authentic user or not. If the login is successful, the user may browse the universal card menu and perform activities such as registering multiple accounts using a unique multi-digit identifier, accessing one of the multiple accounts, etc. However, if the login is not successful, the user is instructed to re-enter the password/PIN code. Still if the login is not successful, the authentication module 307 may block or regenerate a time-bound code for account access as configured.

[0038] In another embodiment, when a user uses a universal card by either swiping the card or providing biometric details, the authentication module 307 checks whether the user is authentic or not. Once the user is authenticated, the user may be requested to enter the multi- digit identifier. The authentication module 307 checks whether the entered multi-digit identifier maps to the account which the user wishes to access. In an alternate embodiment, only multi-digit identifier login may be enabled by the system thus not requiring universal card login.

[0039] The notification module 309 provides various notifications/alerts to the user as configured by the server 30 or external server 50. [0040] The communication module 311 uses the network 40 to establish communication between the server 30 and one of the client device 20 and/or external server 50.

[0041] The database 313 stores data and metadata related to the universal card 10 such as user's name, card number, date of expiry, password/PIN code, contact details, banking details, personal details, know your customer (KYC) details, biometric details, demographic details, QR code details, bar code details, CVV number, etc. The database 311 also stores a mapping table. The mapping table is used for mapping or linking various combinations of multi-digit identifier (automatically generated or provided by the user) to multiple accounts of each user and/or slot position of the accounts. The database also stores unique identification of each user.

[0042] FIG. 4A illustrates the logical flow of registration process for first time users for mapping one account to one slot. In an optional embodiment, subscribers of a universal card may be issued initial login details which may be used to initiate the registration process. Using the login details, the user may commence the registration process of registering multiple accounts to the universal card.

[0043] At step 401, the user enters the login details provided to him at the time when the universal card 10 was issued. The user may login the universal card either by way of a n access device (say laptop, ATM machine, etc.) or a portal. In various embodiments, the login details may contain a password that may be one-time-use password and require the user to change the password for subsequent use. The identifier generation module enables the user to generate such password. In an optional embodiment, the identifier generation module enables the user to define a list of passwords for finite number of subsequent logins. For example, the user may define four passwords - 1234, 2354, 4563 and 7641. Therefore, the first time post registration to access the universal card, 1234 is to be entered, second time 2354 is to be entered, 4563 is to be entered third time and 7641 is to be entered fourth time. Thereafter, same sequence may be repeated or a new password may be defined. [0044] At step 403, the authentication module checks whether the login details entered are correct or not. If the login details are not correct, then the user is instructed to re-enter the login details. In an embodiment, a finite number of chances may be provided to the user post which the universal card registration procedure is halted.

[0045] However, if the login details are correct, at step 405, the multi-digit identification module commences registration procedure. In this, the multi-digit identification module enables a user to register or link an account to the universal card using the unique multi-digit identifier issued at the time of subscription. In an embodiment, a digit that indicates slot position of linked accounts is predefined. In an embodiment, the unique multi-digit identifier for each slot is predefined and the user is requested to link details of one of the account that is to be mapped to that slot of the universal card. Details include without limitation bank name, account number, username, functionalities such as dispensing cash, account balance enquiry, one or more limitations such dispensing currency of a particular amount, specific time/event for accessing the account, defining access parameters for users of a group, demographic limitations like place/channel of access of account, merchant type, etc., number of transactions allowed for the account before re-authentication, etc. [0046] For example, a unique multi-digit identifier 1X567 and its combinations are issued. At the time of mapping of various account, a user may link 51167 as a password for accessing a first bank account, 12567 maybe a password for accessing a second bank account, 53617 may be a password for accessing a third bank account, 54671 may be a password for accessing derivatives, etc. Therefore, the user may provide details of respective bank accounts/derivative when linking such bank account/derivative to the respective password.

[0047] In another embodiment, the multi-digit identification module enables a user to define the multi-digit identifier for each slot while linking a respective account to that slot. The multi- digit identifier includes a digit that indicates slot position of the mapped account. For example, the user may provide 11234 as a unique multi-digit identifier to access one bank card, 25678 to access stocks, 32345 for second bank card, etc. It should be noted that the above two embodiments are exemplary and other possible methods of providing different unique multi- digit identifiers to map different accounts of a single user are within the teachings of the present disclosure. [0048] At step 407, the server side application prompts the user to enquire if additional accounts need to be linked to the unique multi-digit identifier. If no, then step 411 is followed. However, if the user wants to link more accounts to the unique multi-digit identifier, then at step 409, the server side application checks whether the threshold number for registering accounts to the unique multi-digit identifier has crossed or not. If the threshold limit is crossed, then the notification module prompts the user that the user cannot register any more accounts to the unique multi-digit identifier and step 411 is followed. Further, if the threshold limit is not crossed, then steps from 405 are repeated till all the accounts are registered to the unique multi-digit identifier.

[0049] At step 411, the server side application stores all the entries made by the user and the registration process is completed.

[0050] In another embodiment, if the user wishes to use the universal card 10 virtually then during registration process, the user may provide unique identification such as biometric details to the multi-account mapping system. The unique identification is further stored in the multi- account mapping system. [0051] While the above embodiment has been described for numeric/alphanumeric passwords, it should be noted that the passwords may be one or more of a scanned image, a download link, an SMS, an email, personal messaging, a photograph, a SMS, a Bluetooth connection, Wifi connectivity, an email, etc. [0052] FIG. 4B illustrates the logical flow of registration process for first time users to map multiple accounts to one slot. In this embodiment, steps similar to steps 401 and 403 are followed initially. Thereafter, at step 404, the multi-digit identification module commences registration procedure. In this, the multi-digit identification module enables a user to register or link multiple accounts to one slot of the universal card using the unique multi-digit identifier issued at the time of subscription. The number and type of multiple accounts that can be linked to a multi-digit identifier may be preconfigured. In an embodiment, a digit that indicates slot position of linked accounts is predefined. In an embodiment, the unique multi-digit identifier for each slot is predefined and the user is requested to link details of the accounts that are to be mapped to that slot of the universal card. Details include without limitation bank name, account number, username, functionalities such as dispensing cash, account balance enquiry, one or more limitations such dispensing currency of a particular amount, specific time/event for accessing the account, defining access parameters for users of a group, demographic limitations like place/channel of access of account, merchant type, etc., number of transactions allowed for the account before re-authentication, etc. For example, a unique multi-digit identifier 1X567 and its combinations are issued. At the time of mapping of various accounts, a user may link 51167 as a password for accessing a first bank account, a first email account, a first social media account and a first derivative, 12567 maybe a password for accessing a second bank account, a second email account, a second social media account and a second derivative, etc. To map such accounts of different types, the multi-digit identification module may seek configuration details of all such accounts. The configuration details include without limitation functionalities such as dispensing cash, account balance enquiry, one or more limitations such dispensing currency of a particular amount, specific time/event for accessing the account, defining access parameters for users of a group, demographic limitations like place/channel of access of account, merchant type, etc., number of transactions allowed for the account before re-authentication, etc. [0053] Alternately, the multi-digit identification module enables a user to define the multi-digit identifier for each slot while linking respective multiple accounts to that slot. The multi-digit identifier may include a digit that indicates slot position of the mapped account. It should be noted that the above two embodiments are exemplary and other possible methods of providing different unique multi-digit identifiers to map different accounts of a single user are within the teachings of the present disclosure.

[0054] Step 404 is repeated till preconfigured number of accounts for a multi-digit identifier is mapped. For example, if the universal card system supports three accounts (say, an email, a bank account and a credit card) to be added to a multi-digit identifier, a user can add only three such accounts.

[0055] Thereafter steps 407 to 411 are followed to complete the registration.

[0056] In an optional embodiment, once the procedure of FIG. 4A or 4B is followed, one or more rules may be registered along with the mapping. These rules may relate to access of the mapped/linked accounts. For example, in accordance with one rule, accounts of a similar type e.g. a departmental store are stored at two slots (at Al slot, grocery chain 1 having a multi-digit identifier 1234 is stored, at A2 slot, grocery chain 2 having a multi-digit identifier 5678 is stored). In addition to the two accounts mapped at two slots, a rule may be mapped to the account of each slot wherein a particular account may be selected based on purchase parameters eg: quantity, price, name of retailer (eg: grocery chain 1 or 2), mobile no, global trade item number (GTIN), WPC , stock keeping unit (SKU) number.

[0057] In accordance with another exemplary rule, in addition to the multiple accounts mapped at corresponding slots, a rule may be mapped to one or more accounts of a slot wherein a transaction amount may be deducted as per a predefined criterion. For example, during mapping, a rule may be defined that 10% transaction amount is to be deducted from the account mapped at slot 1, 30% is to be deducted from account mapped at slot 2 and remaining transaction amount is to be deducted from account mapped at slot 5.

[0058] In accordance with another exemplary rule, in addition to the multiple accounts mapped at corresponding slots, a rule relating to activation time of each account may be defined for the accounts mapped to each slot. For example, Al, A2, A3 and A4 may be activated by one password eg: 1234. A rule may be defined according to which Al maybe activated from 4am to 10am, A2 from 10am to 5 pm, while A3 from 5pm to 4am while account A4 may be activated on occurrence of an event like earthquake.

[0059] In accordance with yet another rule, a particular slot or password may be valid for one year or for a predefined number of transactions, say ten. Thereafter to activate it again, an OTP or other means of authentication may be required.

[0060] From the above, it is evident that the teachings of the present disclosure entail varied embodiments and any embodiment that can be practised as per the teachings of the present disclosure is within the scope of the present disclosure.

[0061] FIG. 4C illustrates logical flow for creating login password. [0062] At step 413, the user enters login details. These details may pertain to details provided at the time of subscription or last registered details.

[0063] At step 415, the server side application enquires whether the user wants to change/create login password.

[0064] At step 417, the server side application enquires from the user wants if the user wishes to create any rules for password access. The rules may be password rotation, password validity, account type password activation, etc. If the user responds negatively, the server side application stores the new password at step 419 and ends the process.

[0065] However, if the user selects a rule, say password rotation, the server side application provides a corresponding interface for seeking password details and associated rules at step 421. For e.g. if the user defines a login password list such as "1234", "2354", "4563", "7641", then the user may create rules such as for the first time login "1234" password would work, next time "2354" would work, third time "4563" would work and similarly for fourth time "7641" would work. For the fifth time, the first time password i.e. "1234" would work.

[0066] Alternately, if password validity rule is selected, the server side application may display corresponding options on the interface. The password may be valid for a particular time period such as 30 minutes or may be activated for a certain time period such as from 7PM onwards or from 3PM-7PM. Additionally/optionally, there may be other parameters such as and not limited to time period of transaction, day of transaction, merchant type, transaction type, transaction environment and location, predetermined amount, purchase parameter, image of the payer, location of payer/payee etc. [0067] In yet another embodiment, the server side application may provide an option for account type password activation. In this, depending upon the type of account that is linked to a slot of the universal card, password is defined.

[0068] The process then proceeds to step 408. [0069] FIG. 5 illustrates a flow chart depicting steps for accessing an account linked to a universal card.

[0070] At step 502, the user uses the interface provided by the interface module 205 to enter login details for example, card identifier, username, etc. The interface may be the interface of a universal card portal or a universal card machine. Optionally, the interface module may be configured to send a security code to be entered for successful login.

[0071] At step 504, the client device 20 transmits the login details to the universal card server 30 by using the communication module 207. The universal card server checks the login details and upon successful login, enquires with the user the account to be accessed at step 506. For this, the universal card server may prompt the user to first enter the slot number of the account which the user wishes to access followed by the multi-digit identifier. Alternately, the universal card server may prompt the user to enter the multi-digit identifier containing the slot number.

[0072] At step 508, the universal card server processes the multi-digit identifier for authentication. In an embodiment, additionally, real-time authentication may be performed. Once authenticated, the universal card server determines the account which is to be accessed by the user. The universal card server queries the database for fetching external server details linked to the account being accessed at step 510. Thereafter, the universal card server redirects the client device to the external server to enable the client device to correspond with the external server. [0073] FIG. 6 illustrates a flow chart depicting steps for accessing one type of account linked to a multi-digit identifier of a universal card. In this, the steps 602 to 608 correspond to steps 502 to 508 and are therefore not repeated for avoiding repetition.

[0074] At step 610, once the multi-digit identifier is authenticated, the universal card server enquires the user to select an account out of the multiple accounts linked to the same multi- digit identifier. Based upon user input at step 612, the universal card server queries the database for fetching external server details linked to the selected account. Thereafter, the universal card server redirects the client device to the external server to enable the client device to correspond with the external server.

[0075] In an embodiment, different unique multi-digit identifiers for an account can be used to define two different functionalities. For example, limiting cash available and other services on one of the password while full functionality in other password. As an exemplary implementation, family or a group of users can use a common universal card with cash limit defined for children with a unique multi-digit identifier.

[0076] In an embodiment, preference score can be allotted to stored accounts, providing an option to select a default account (master account) if a 'default password' is keyed. As per another variation, child accounts may be setup, which will be selected only if the master account is unable to the pay the amount.

[0077] In an embodiment, accounts may be automatically selected based on customized rules for example, transaction environment & location, merchant type, transaction type, time period of transaction, transaction environment and location, predetermined dollar amount, etc.

[0078] In an embodiment, the server may divide the bill among the stored accounts like 60% to account 1, 40% to account 7 and/or schedule auto-payments.

[0079] FIG 7 illustrates an exemplary access procedure of the accounts mapped to a universal card, in this embodiment, using the card at different channels may enable different services and accounts. At step 702, the universal card server receives a card identifier and associated metadata. The universal card server authenticates the card identifier and also processes the metadata to decipher the details of a requesting machine the user has used to access the accounts via the universal card. At step 704, the universal card server requests for multi-digit identifier from the user. Once the server authenticates the multi-digit identifier, it activates an account (out of the multiple accounts mapped for the multi-digit identifier) that is supported by the requesting machine. For example, using the universal card at ATM would enable different debit cards/bank accounts for dispensing cash; logging via a mobile app may activate different wallets; or via insurance website only insurance based accounts may be enabled.

[0080] Thereafter, the universal card server may enable the user to communicate/transact with the external server of the accessed account directly at step 706. [0081] In the embodiment of FIG. 7, other variations are possible. For example, NFC (near field communication) transactions or even opening a car may be facilitated.

[0082] Various additional features can be provided to the above multi-account mapping system. For example, default settings, passwords may be configured to provide functionalities/access with limited features (for all the steps described in figures above). Or, the password of first login as well as multi-digit identifier may be same.

[0083] The foregoing description of preferred embodiments of the present disclosure provides illustration and description, but is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosure.

[0084] No element, act, or instruction used in the description of the present disclosure should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article "a" is intended to include one or more items. Where only one item is intended, the term "one" or similar language is used.

Claims

I Claim:

1. A multi-account mapping system comprising: a. a universal card comprising multiple slots, each slot having an associated multi-digit identifier and being mapped to at least one account, the at least one account is selected from preconfigured types of account; b. a database that stores the mappings of the slot and the at least one account along with details of the universal card; and c. an interface module that facilitates access of the at least one account mapped to the universal card.

2. The multi-account mapping system as claimed in claim 1 wherein the preconfigured types of account comprise one or more of bank accounts for which debit cards or credit cards, reward cards, metro travel cards, or loyalty cards are issued to an account holder, one or more wallets of an account holder, one or more stock trading accounts, one or more derivative accounts, one or more insurance accounts, one or more email accounts, one or more social media accounts, one or more mobile number accounts, one or more DTH accounts, one or more utilities, one or more job portals, one or more institution logins, one or more employee logins, one or more student logins, one or more hotel room key, one or more automobile key, one or more NFC (near field communication) transaction login, one or more M2M (Machine to machine) login, and one or more UPI (unified payment interface) login.

3. The multi-account mapping system as claimed in claim 1 wherein the slots of the universal card include associated one or more rules for mapping at least one account.

4. The multi-account mapping system as claimed in claim 3 wherein the one or more rules comprises selection of one of the mapped accounts based on one or more purchase parameters.

5. The multi-account mapping system as claimed in claim 3 wherein the one or more rules comprises deduction of a transaction amount as per a predefined criterion.

6. The multi-account mapping system as claimed in claim 3 wherein the one or more rules comprises activation time for the at least one account mapped to the slot. The multi-account mapping system as claimed in claim 3 wherein the one or more rules comprises configuration of the at least one account for a predefined time period or number of transactions.

A method of mapping multiple accounts comprising: a. defining multiple slots in a universal card, each slot having an associated multi-digit identifier and being mapped to at least one account, the at least one account is selected from preconfigured types of account; b. storing the mappings of the slot and the at least one account along with details of the universal card in a database; and c. facilitating access of the at least one account mapped to the universal card as per the mappings stored in the database via an interface module.