Title of Invention

METHOD OF USER PROFILE BASED MOBILE ACCESS

Abstract

This invention explains a method and a system of user profile based mobile access in a scenario of a pool of users consisting of primary user and a plurality of secondary users wherein the said method comprises the steps of: creating a profile for each user in the mobile handset and setting a specific userlD and password for authentication of the said profile; setting and changing various attributes for each profile created; logging in through a particular profile by the secondary user; filtering out the User records relevant to the current profile; using the user records and network services pertaining to the profile; and logging the call information and caller's number of the said profile.

Full Text

FIELD OF TECHNOLOGY This invention relates in general to mobile communication devices. Further, this invention relates to mobile handset functionality in mobile handheld devices, smart phones, etc. More particularly, this invention relates to a system and method for user profile based mobile access. DESCRIPTION OF THE RELATED ART In the present scenario, the available mobile communication devices provide for access restriction mainly through the key-lock feature(s). As per this feature: • When the phone is switched on or when it is in idle mode for some time, the phone automatically shifts to Lock Mode. In this mode, the handset does not allow access to any of its features. • To shift from Lock mode to normal mode, an "authorization code" is required. This authorization code is a pre-defined key sequence (entered by pressing the keys one after another in the same pre-defined order). • If the key sequence is correct, the user is allowed access to the complete menu including all Network services and User records available on the handset. This feature safeguards the handsets against accidental key presses and unauthorized users, i.e. as long as the handset is in lock mode no feature of the handset is used. The restriction, if applied, controls every feature of the handset. If this restriction is not applied, every feature of the handset is available to any user. STRUCTURE AND STEPS OF RELATED ART When the phone is switched on or when it is in idle mode for some time, the phone automatically shifts to Lock Mode. In this mode, the handset does not allow access to any of its features. To shift from the lock mode to the normal mode in which all features are accessible, an authorization code is needed. When this code is entered, the phone is unlocked and its services are available for use. The handset provides full access to the complete menu including all user records and network services available on the handset. Wherever applicable, the user can read, erase and modify user records. In addition, the user has access to all network services as well. After usage, the user can lock the handset again in similar fashion if he/she wants. OPERATION OF RELATED ART Few major players in mobile handset market use the key-lock feature in variations: • One major handset manufacturer's handsets require "Unlock" and '*" key presses for coming out of Lock mode. This sequence is fixed and cannot be changed. This variation safeguards the handsets against accidental key presses provided the handset is in Lock Mode. • Another major handset manufacturer's handsets require a 4-digit key sequence to be pressed. The key sequence is defined by the owner of the handset and can be changed. This variation safeguards the handset from accidental key-presses as well as from unauthorized access. Currently available handsets with the key-lock feature have practical limitations. It allows either an unqualified access to the handset features (Network services and User records) or restricts access to even the basic Network services. The user (if not the owner) can make unlimited calls, view all of owner's data and in some cases modify it, which is not always desirable. This weakness may lead to severe problems and uncomfortable situations for the handset owner. Some of these common problems have been identified below for better illustration: • Suppose the user's family member or his/her friend asks for his/her handset for making a call. The user will unlock the handset and give it to him/her. Although the original purpose was to make a call, the friend/family member has access to all of the user's personal records including archived SMS, saved messages, schedules, alarms, memos, mobile banking passwords etc. • In another situation, if the user's children ask him/her for the handset because they want to play games available in It. Suppose the user has stored some adult-only data (i.e. which the user does not want his/her children to have a look) e.g. jokes, wallpapers, voice mails, multimedia files, movie clips. The user cannot possibly refuse this simple request. Now after playing games, children start to surf the handset data just out of curiosity and end up viewing such adult-only data. The user will never want this to happen but nothing can be done about it. A friend/relative after getting the handset in Unlock state can use expensive network services. The owner won't know about it and may blame the service provider for extra billing. This is a very common situation and is highly undesirable. In currently available handsets, there is no way to know the cost incurred when some friend/relative used one's handset. This is highly undesirable as the owner always wants to keep track of the usage of his handset and available services. SUMMARY OF THE INVENTION The primary object of this invention is therefore to invent a system and method of user profile based mobile access. It is another object of the invention to invent a system and method for providing an extra level of security in mobile communication devices which allows access to multiple users through provisioning of various profiles such that each profile owner has access to various mobile functionalities according to the profile attributes, profile owner's private data and the data public to everyone using the handset. It is a further object of this invention to provide a comfortable level of security for the private data of all occasional users of the mobile and especially the handset owner whereby the private data of the mobile owner or other users can be decoupled from various mobile funcfionalities, and whereby the functionalities can be used without compromising the privacy of other users. The proposed system is meant to restrict access to the personal user records. At the same time, it allows for access to the basic functionality of the mobile handset. The occasional user can "login" into the phone with one of the initially created User Profiles and can have access to his/her own private data, the public data and the other mobile functionalities. These functionalities are set at the time of the creation of the profile (as the attribute of the User Profile) and are specific to that profile. This profile will not have access to private data any other profile. The handset owner (superuser) creates the profile and is responsible for managing profiles. Profile management includes creation, deletion and changing attributes of the profile. In case of superuser privileges (meant for the handset owner), all user records in the handset can be accessed, modified (if applicable) and erased. Accordingly, the present invention comprises a system and method to provide creafion of User Profiles based on access rights to services, databases and applications, comprising: a) User can define the profiles. b) User can assign Service, Database and Applications access to different profiles. c) User can change profile in the device for Guest users of the device. d) User can add/delete/modify the profiles. e) User can enable/disable access in profiles like SMS/MMS/WAPA/oice Calls/Data Calls/Bluetooth/lnfra-red data transfer. Accordingly, the present invention further comprises a method of setting User profiles as given above is applicable to Network terrestrial and satellite services(like GSM/GRPS/UMTS/CDMAyTDMA/lnmarset/WLAN etc) and Non-Network services(like Bluetooth/Infra-red etc). Accordingly, the present invention further comprises a method of setting User profiles as given above and is applicable to applications available in device (either native or downloaded etc.). Accordingly, the present invention further comprises a method of setting User profiles as given above is and applicable to databases available in device (like Phonebook, Multimedia contents, SMS/MMS messages etc.). Accordingly, the present invention further comprises a method of setting User profiles as given above is applicable to games available in device (either native or downloaded etc.). Accordingly, the present invention further comprises a method of setting User profiles as given above and is a program which controls access for each profile in different services, application and databases. Accordingly, this invention explains a method of user profile based mobile access in a scenario of a pool of users consisting of primary user and a plurality of secondary users wherein the said method comprises the steps of: (a) creating a profile for each user in the mobile handset and setting a specific userlD and password for authentication of the said profile; (b) setting and changing various attributes for each profile created; (c) logging in through a particular profile by the secondary user; (d) filtering out the User records relevant to the current profile; (e) using the user records and network services pertaining to the profile; and (f) logging the call information and caller^s number of the said profile. The said method is adapted to operate in scenario of a primary user and a pool of secondary users. The attributes set for each profile include various combinations of Mobile applications. User records, Network services and access permissions allowed by the handset. The attributes set for each profile is changed anytime by the person having the authentication to change the attributes wherein the primary user has the default right to chance the attributes of all secondary uses. The user records include Phonebook entries, Messages, Alarms, Memos, Scheduler, Ring tones, Icons, etc. The Network Services include incoming and outgoing calls, send and received SMS and data services. The User records and Network services are accessed through Ul applications. For user records, if read only permission is allowed for a profile in an application, the profile user is only adapted to read User records present for that application. For user records, the attribute change is always applicable as an add-on. For Network Services, outgoing calls and sending SMS are only allowed if the corresponding attributes are set. For Network Services, on receiving a call/SMS incoming SMS does not belong to any profile which does not have SMS read/write permissions. For Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is a secret phonebook entry in the current profile, the call/SMS belong to the current profile. For Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is not a private phonebook entry for the current profile, then the call/SMS belongs to all the user profiles for which it is a private phonebook entry. For Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is not secret to any profile's phonebook, and is a public number, then the call/SMS belongs to all User profiles. For Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is not in the phonebook at all, then the call/SMS belongs to the primary user. For Network Services, incoming SMS are accessible only to the profile to which it belongs. For Network Services, incoming calls is received by the current profile and the call logs are sent to the profile to which the call belongs. A profiler in the Database access library filters out the User records relevant to the current profile so that the profile has access to only its own private information. Each user record contains a profile identification number, which is used for filtering profile relevant information where the said relevant user records are accessed by the user logged in through the profile. The profiler filters out the various handset features and network services according to the attribute set of the current profile. In lock mode, profile name and password is required for login on to the handset. After logging in through a particular profile, all User records and Network services according to the attribute set of the profile is available to the secondary user. All the public user data and private data created in that profile is available to the profile logged in. If an SMS is received, the sender's number will be checked in the phonebook and if the sender's number was added by the current profile in the phonebook earlier, the user reads the message. If a SMS is received, the sender's number will be checked in the phonebook and if the number is stored as public data, the message is read and if the number is stored as private entry by some other profile, the user is required to enter the password for that profile to read the message. If an incoming number does not belong to the current profile, a message is displayed accordingly. If the incoming number is not stored in phonebook, it belongs to the primary user and the user enters the primary user password to see the message/call. If an alarm is set in first profile and the said first profile expires while handset is in second profile then the user is required to enter the password for first profile to see the notice given by the alarm. The call information and caller's number is sent to call-log of the profile who added the number. If caller's number is added by current profile, user can see the call information and caller's number. If call number is stored as public data, call informafion and caller's number is viewed by user. If the call number is stored as private data by some other profile or not stored in handset, user cannot see the call information and caller's number. Accordingly, this invention further explains a system for user profile based mobile access in a scenario of a pool of users consisting of primary user and a plurality of secondary users wherein the said system comprising: (a) means for creating a profile for each user in the mobile handset and setting a specific userid and password for authentication of the said profile; (b) means for setting and changing various attributes for each profile created; (c) means for logging in through a particular profile by the secondary user; (d) means for filtering out the User records relevant to the current profile; (e) means for using the user records and network services pertaining to the profile; and (f) means for logging the call information and caller's number of the said profile. The other objects, features and advantages of the present invention will be more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 illustrates the system of the current scenario. Figure 2 presents a flowchart of various steps involved in profile based access to user records and network services on the handset. Figure 3 illustrates how the Profiler module maps various user and network related events to various user profiles. DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. Figure 1 illustrates the system of the current scenario.In current scenario, when a User Interface (Ul) application is launched it has complete access to the application database. There is limited protection involved in database access for a particular application. Figure 2 presents a flowchart of various steps involved in profile based access to user records and network services on the handset. It shows logging in when in Lock Mode or after POWER UP, and thereafter access to various applications. It also shows how the records relevant to the user profile will be filtered for access to current profile. User is asked for a Login and Password. After keying in a valid combination, credentials of the particular login are verified and the user is checked. User is presented with those Ul applications which he/she has credentials to access. When the Ul applications generates or gets an event, the Profiler module checks the event. If the event belongs to the current profile (Refer explanation of Drawing 3), event is handled according to the current profile and corresponding data is displayed. If the event does not belong to the current profile and if the event is not an incoming call, then the authentication is done for the user to allow event handling and see the related data in the process. If the event is an incoming call, then the user is allowed to handle the call and call logs are recorded in call history of profile to which the event actually belongs. Figure 3 illustrates how the Profiler module maps various user and network related events to various user profiles. Moreover it illustrates the different actions taken for different scenarios. If there is an incoming event, the event along with current profile identifier is sent to the profiler. Profiler checks whether the event is an incoming call or an incoming SMS event. If it is a call or SMS event: a) If the Caller's or sender's number is not in Phonebook at all, then event belongs to current profile. b) If the number is in Phonebook and the number is added by current profile then event belongs to current profile. c) If the number is not created by current profile and it is stored as public number then event belongs to current profile. d) If the number is not created by current profile and it is stored as private number then event does not belongs to current profile. If it is not call or SMS event, get event related information such as whether it is trying to read or write data. If it is trying to read data: a) If data is created by current profile then the event belongs to current profile b) If data is created by some other profile and stored as public data, then event belongs to current profile. c) If data is created by some other profile and stored as private data, then event does not belongs to current profile. If the user or the event handler is trying to write the data (for example: by downloading a content or by adding an entry in phonebook), then profiler checks whether current profile has write permissions to the related folder or not. If the user has permissions, then event belongs to current profile otherwise it does not belongs to current profile The proposed user profile based structure for access to mobile handset features is described hereunder: Profile Management The creafion, deletion and attributes of a User profile is done as described below. Only the superuser has the privileges to do this activity. On buying the handset, the owner is provided with only the superuser profile with a default password, which is identical in all the handsets. The owner immediately changes the superuser password to his preferred password. For profile creation, the owner needs to give the login name and the password for the profile. Then the user can set various attributes for the profile. These attributes include various combinations of Mobile applications, User records. Network services and access permissions (read/write etc.) allowed by the handset. The granularity of the combinations is implementation dependent. E.g. In a handset, read/write permissions on all Ul applications is allowed. Then the owner can create a User profile with attribute set: SMS read only, Organizer read-write, Phonebook (no access). On profile deletion, all profile specific User records and the particular profile record will be erased. The owner can also change the attributes of a profile anytime. In this case, the new attributes will not take effect immediately but when the user attempts to invoke the relevant functionality i.e. the User records created for this profile with the previous attribute set will remain accessible to the profile. E.g. If in previous attribute set, alarm is allowed but is not there in the new attribute set, then although no new alarms can be set, the previous one will not be removed until it goes off. The owner can create profiles according to his needs. E.g. If people ask for his/her handset for making a call often, he can create a profile allowing outgoing calls and Phonebook access only. If he just wants to protect his/her confidential information i.e. his/her user records, he/she can create a profile which allows access to all features. Hence the profile can access all features on the handset but User records outside his profile will not be available to it. Feature Access Handset features are accessible to the profile user according to the profile's attribute set. Access to following items is done on a handset: • User records: Phonebook entries. Messages, Alarms, Memos, Scheduler, Ring tones, Icons etc. • Network Services: Call (incoming/outgoing), SMS (send/receive), data services. User records and Network services are accessed through Ul applications. The following general rules are applicable for access to User Records: • If read only permission is allowed for a profile in an application, the profile user can only read User records present for that application. He/she can not write/modify User records for that application. E.g. If only read permission for Phonebook is given, then the profile user can only view and use the public entries in Phonebook. He/she cannot add his own entries in the phonebook. Attribute change is always applicable to the new User Records. E.g. if SMS read/write permission is allowed, then the profile user can save SMS. But later, if the profile attributes are changed to SMS read-only, then the profile user cannot erase/modify previously saved SMS. He/She cannot save new messages as well. The following general rules are applicable for accessing Network Services: • Outgoing calls and Sending SMS are only allowed if the attributes are set accordingly. • On receiving a call/SMS, following rules are applied to know the User profile to which the call/SMS belongs o Incoming SMS does not belong to any profile which does not have SMS read/write permissions. o If the peer number (the number which sent the SMS or made the call) is a secret phonebook entry in the current profile, the call/SMS belong to the current profile. o If the peer number is not a private phonebook entry for the current profile, then the call/SMS belongs to all the user profiles for which it is a private phonebook entry. o If the peer number is not secret to any profile's phonebook, and is a public number, then the call/SMS belongs to all User profiles. o If the peer number is not in the phonebook at all, then the call/SMS belongs to the superuser. Incoming SMS are accessible only to the profile to which it belongs. Incoming calls can be received by the current profile but the call logs are sent to the profile to which the call belongs. STRUCTURE OF THE INVENTION The invention introduces a profiler in the Database access library. This profiler filters out the User records relevant to the current profile. Hence the profile has access to only its own private information. Each user record contains a profile identification number, which is used for filtering profile relevant information. The relevant user records are the ones that can be accessed by the user logged in through the profile. The profiler also filters out the various handset features and network services according to the attribute set of the current profile. Hence unwanted use of the network services (Calls, SMS, Data access) is also restricted. A simplified view of the Profiler functionality is provided in the figure "Structure of Profile based handset". Here all profiles use various network services, but they have access to only the public data and their respective private data. OPERATION OF THE INVENTION In lock mode, profile name and password is required for login on to the handset. After logging in through a particular profile, all User records and Network services according to the attribute set of the profile are available to the user. All the public user data will be available to profile. In addition, private data created in that profile are also available. If a SMS is received, the sender's number will be checked in the phonebook. If the sender's number was added by the current profile in the phonebook, the user can read the message. If the number is stored as public data, the message can be read. If the number is stored as private entry by some other profile, the user is required to enter the password for that profile to read the message. If the number does not belong to the current profile, a message "Message received for Profile X" will be displayed, where X is the profile name for which the message is received. If the number is not stored in phonebook, it belongs to the superuser. Hence, if the current profile is not the superuser profile, the user has to enter the superuser password to see the message. If an Alarm is set in profile W and it expires while handset is in profile 'B\ the user is required to enter the password for profile 'A' to see the notice given by the alarm. If a Call is received, caller's number will be checked in phonebook. User is allowed to attend the call irrespective of the profile. The call information and caller's number will be sent to call-log of the profile who added the number. If caller's number is added by current profile, user can see the call information and caller's number. If number is stored as public data, call information and caller's number can be viewed by user. If the number is stored as private data by some other profile or not stored in handset, user cannot see the call information and caller's number. ADVANTAGES OF THE INVENTION The invention provides an extra level of security to the mobile owner. This security feature is provided on owner's private User records and from unwanted access to the network services as well. Also, a more granular approach to access of mobile features rather an "everything or nothing" approach is the demand for future mobile users. This extra security feature provides the mobile owner to create various profiles on his/her mobile phone. In the case he/she needs to lend his/her handset to someone else (for a call or SMS etc), which happens very often and can not be avoided, he/she can switch to another profile or create another profile for the temporary user. This will protect the personal data and also the temporary user can access his/her own private data (in case he/she creates them) and use the Network services without compromising the owner's privacy. This invention will also be more desirable by the handset buyers because it will also give them an idea of what has been the call/SMS cost for each profile on the handset. Moreover, a profile based access will encourage users to use friend's mobile phones often rather than a landline phone. So this invention will help leading players in mobile market to direct the landline telecom revenue to themselves. The profile based access to the handset is applicable to all User records and all User initiated network services. The User records/ Network services to which this type of security is provided are subject to choice of the manufacturer. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart therefrom. GLOSSARY OF TERMS AND DEFINITIONS THEREOF User records: All data/records that can be created and modified by the user e.g. Phonebook records, archived SMS, Scheduler, Alarms, Memos, Setting options. Multimedia data. Wallpaper, Voice tools etc. Each such user record has a profile identification contained in it, depending upon the profile that created the User records. Current Profile: The profile through which a user is currently logged on to the handset. Network services: Network related applications (e.g. Calls / SMS). User Profile: A combination of login name and password having a defined set of privileges at the time of its creation. At least one combination is required to access any User records / Network services on the handset. Private data: This type of data is private to the user profile, and is not be accessible by any other user profile in the handset except the superuser. Public data: This type of data is accessible to all user profiles on the handset, but may not necessarily be modifiable. Event: A key press. Alarm, Incoming call, Incoming SMS, WAP Push Notifications, Bluetooth/lnfrared/USB/SERIAL Connection, External Device Connection and other Network Triggers WE CLAIM 1. A method of user profile based mobile access in a scenario of a pool of users consisting of primary user and a plurality of secondary users wherein the said method comprises the steps of: (a) creating a profile for each user in the mobile handset and setting a specific userlD and password for authentication of the said profile; (b) setting and changing various attributes for each profile created; (c) logging in through a particular profile by the secondary user; (d) filtering out the User records relevant to the current profile; (e) using the user records and network services pertaining to the profile; and (f) logging the call information and caller's number of the said profile. 2. A method as claimed in any of the preceding claims wherein the said method is adapted to operate in scenario of a primary user and a pool of secondary users. 3. A method as claimed in any of the preceding claims wherein the attributes set for each profile include various combinations of Mobile applications, User records, Network services and access permissions allowed by the handset. 4. A method as claimed in any of the preceding claims wherein the attributes set for each profile is changed anytime by the person having the authentication to change the attributes wherein the primary user has the default right to chance the attributes of all secondary users. A method as claimed in any of the preceding claims wherein the user records include Phonebook entries, Messages, Alarms, Memos, Scheduler, Ring tones, Icons, etc. A method as claimed in any of the preceding claims wherein the Network Services include incoming and outgoing calls, send and received SMS and data services. A method as claimed in any of the preceding claims wherein the User records and Network services are accessed through Ul applications. A method as claimed in any of the preceding claims wherein for user records, if read only permission is allowed for a profile in an application, the profile user is only adapted to read User records present for that application. A method as claimed in any of the preceding claims wherein for user records, the attribute change is always applicable as an add-on. .A method as claimed in any of the preceding claims wherein for Network Services, outgoing calls and sending SMS are only allowed if the corresponding attributes are set. .A method as claimed in any of the preceding claims wherein for Network Services, on receiving a call/SMS incoming SMS does not belong to any profile which does not have SMS read/write permissions. !.A method as claimed in any of the preceding claims wherein for Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is a secret phonebook entry in the current profile, the call/SMS belong to the current profile. (.A method as claimed in any of the preceding claims wherein for Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is not a private phonebook entry for the current profile, then the call/SMS belongs to all the user profiles for which it is a private phonebook entry. kA method as claimed in any of the preceding claims wherein for Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is not secret to any profile's phonebook, and is a public number, then the call/SMS belongs to all User profiles. i.A method as claimed in any of the preceding claims wherein for Network Services, on receiving a call/SMS if the number which sent the SMS or made the call is not in the phonebook at all, then the call/SMS belongs to the primary user. i.A method as claimed in any of the preceding claims wherein for Network Services, incoming SMS are accessible only to the profile to which it belongs. A method as claimed in any of the preceding claims wherein for Network Services, incoming calls are received by the current profile and the call logs are sent to the profile to which the call belongs. A method as claimed in any of the preceding claims wherein a profiler in the Database access library filters out the User records relevant to the current profile so that the profile has access to only its own private information. A method as claimed in any of the preceding claims wherein each user record contains a profile identification number, which is used for filtering profile relevant information where the said relevant user records are accessed by the user logged in through the profile. A method as claimed in any of the preceding claims wherein the profiler filters out the various handset features and network services according to the attribute set of the current profile. A method as claimed in any of the preceding claims wherein in lock mode, profile name and password is required for login on to the handset. A method as claimed in any of the preceding claims wherein after logging in through a particular profile, all User records and Network services according to the attribute set of the profile is available to the secondary user. ■ A method as claimed in any of tiie preceding claims wherein all the public user data and private data created in that profile is available to the profile logged in. . A method as claimed in any of the preceding claims wherein if a SMS is received, the sender's number will be checked in the phonebook and if the sender^s number was added by the current profile in the phonebook earlier, the user reads the message. A method as claimed in any of the preceding claims wherein if a SMS is received, the sender's number will be checked in the phonebook and if the number is stored as public data, the message is read and if the number is stored as private entry by some other profile, the user is required to enter the password for that profile to read the message. A method as claimed in any of the preceding claims wherein an incoming number does not belong to the current profile, a message is displayed accordingly. A method as claimed in any of the preceding claims wherein if the incoming number is not stored in phonebook, it belongs to the primary user and the user enters the primary user password to see the message/call. .A method as claimed in any of the preceding claims wherein if an alarm is set in first profile and the said first profile expires while handset is in second profile then the user is required to enter the password for first profile to see the notice given by the alarm. ). A method as claimed in any of the preceding claims wherein the call information and caller's number is sent to call-log of the profile who added the number. ). A method as claimed in any of the preceding claims wherein if caller's number is added by current profile, user can see the call information and caller's number. LA method as claimed in any of the preceding claims wherein if call number is stored as public data, call information and caller's number is viewed by user. IA method as claimed in any of the preceding claims wherein if the call number is stored as private data by some other profile or not stored in handset, user cannot see the call information and caller's number. J. A system for user profile based mobile access in a scenario of a pool of users consisting of primary user and a plurality of secondary users wherein the said system comprises: (a) means for creating a profile for each user in the mobile handset and setting a specific userlD and password for authentication of the said profile; (b) means for setting and changing various attributes for each profile created; (c) means for logging in through a particular profile by the secondary user; (d) means for filtering out the User records relevant to the current profile; (e) means for using the user records and network services pertaining to the profile; and (f) means for logging the call information and caller's number of the said profile. 34. A method for user profile based mobile access substantially as herein described and illustrated with the accompanying drawings. 35. A system for user profile based mobile access substantially described and illustrated with the accompanying drawings.

Documents:

661-CHE-2004 AMENDED PAGES OF SPECIFICATION 17-10-2012.pdf

661-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 17-10-2012.pdf

661-CHE-2004 FORM-1 17-10-2012.pdf

661-CHE-2004 POWER OF ATTORNEY 17-10-2012.pdf

661-CHE-2004 CORRESPONDENCE OTHERS 12-09-2012.pdf

661-CHE-2004 POWER OF ATTORNEY 12-09-2012.pdf

661-CHE-2004 AMENDED CLAIMS 18-06-2012.pdf

661-CHE-2004 AMENDED PAGES OF SPECIFICATION 18-06-2012.pdf

661-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 18-06-2012.pdf

661-CHE-2004 FORM-13 19-06-2006.pdf

661-CHE-2004 FORM-5 18-06-2012.pdf

661-CHE-2004 POWER OF ATTORNEY 18-06-2012.pdf

661-che-2004-abstract.pdf

661-che-2004-claims.pdf

661-che-2004-correspondnece-others.pdf

661-che-2004-description(complete).pdf

661-che-2004-description(provisional).pdf

661-che-2004-drawings.pdf

661-che-2004-form 1.pdf

661-che-2004-form 5.pdf