WO2010131980A1

WO2010131980A1 - Systems, methods and devices for management of a plurality of mobile devices

Info

Publication number: WO2010131980A1
Application number: PCT/NO2010/000177
Authority: WO
Inventors: Mads Olsen; Freddy Alex Eriksen; Oleg Belous
Original assignee: Lapback As
Priority date: 2009-05-12
Filing date: 2010-05-12
Publication date: 2010-11-18
Also published as: NO20091865L

Abstract

The invention relates to systems, methods and devices for management of a plurality of mobile devices of varying platforms through a single management application. More specifically, this application relates to management of data stored on mobile devices and enabling GEO location features using either triangulation or a device built-in GPS.

Description

Systems, methods and devices for management of a plurality of mobile devices

Technical Field

[0001] The invention relates to systems, methods and devices for management of a plurality of mobile devices of varying platforms through a single management application. More specifically, this application relates to management of data stored on mobile devices and enabling GEO location features using either triangulation or a device built-in GPS.

Background Art

[0002] The use of mobile devices, including mobile telephones, personal-digital assistants, and the like, has both been increasing in recent years and becoming more diverse in application and at the same time holding more and more important and in some cases confidential/private data.

[0003] One consequence of this expanded functionality and data-storage capability is that the data on mobile devices is now frequently of greater value than the mobile device itself. Of course, the concern about the security of information that resides on the device is prompted not only by fears of potential theft, but also by the possibility that the device will be mislaid or lost.

[0004] Concerns can be split into two main concerns: a) Data on the device might be private and/or confidential and in case of loss/theft, these data will be open and accessible, b) Personal data like private pictures, documents, notes, messages and the like will be permanently lost.

[0005] There is accordingly a general need in the art for improved methods and systems for managing the security and accessibility of data on mobile devices.

[0006] There are several device management platforms and technologies in the market for end-users, such as Syncronica, Funambol, Mobical, Zyb and Voxmobili. Common to these solutions is the use of SyncML (Open Mobile Alliance Data Synchronization and Device Management), which limits management to synchronization of Contact, Calendar, SMS, MMS and Email. [0007] It is an object of the present invention to overcome the drawbacks of the systems indicated above to enable Backup/restore/delete of example Documents, Pictures, Videos, MMS and other files and data and to provide GEO location features to the user. In addition to the delete option it is further an object to overcome the indicated security issues by providing systems and methods which can remotely lock mobile devices.

Disclosure of Invention

[0008] The object of the invention is met by a system, methods and devices configured for management of mobile devices.

[0009] In particular it is disclosed a system for management of mobile devices at least comprising:

At least one mobile device, where the mobile device further comprises at least one mobile device manager client configured to access data in the at least one mobile device.

At least one first node connected to the at least one mobile device over a telecom network; where the first node at least comprises: at least one database; at least one service client configured to provide management of the content in mobile devices; an Internet server; at least one interface configured for secure connection/communication with web portals. The system for management of mobile devices further comprises; at least one graphical user interface, GUI, installed on a computer, where the GUI is configured to provide secure connection/communication with said at least one first node and the GUI is further configured to display the content of one or more mobile devices.

[0010] According to the present invention it is also disclosed a mobile device manager client configured for content management of a mobile device where the mobile device manager client is embedded in the mobile device and where the mobile device manager client at least comprises: Means configured to read user specific data stored in the mobile device; means configured to write user specific data to a memory of the mobile device; means configured to receive user specific data over a secure protocol from a first node; means configured to transmit user specific data over a secure protocol to the first node. [0011] The present invention also discloses a node configured for content management of mobile devices connected to at least one mobile device over a telecom network. The node comprises at least: at least one database; at least one service client configured to provide management of the content in mobile devices; an Internet server; at least one interface configured for secure connection/communication with web portals; at least one interface configured for communication with mobile devices.

[0012] It is further disclosed a graphical user interface installed on a computer, where the graphical user interface is configured to provide secure connection/communication with at least one first node. The graphical user interface is further configured to display the content of one or more mobile devices, where the displayed content is hyperlinks linked to stored data in the first node, the stored data is the mirror image of the content of the one or more mobile devices.

[0013] In accordance with the present invention it is also necessary to provide methods for login and authentication that facilitates the use of the system for management of mobile devices, hence it is disclosed a method for login and authentication from a computer for a management and transfer of data system where the system is configured for management and transfer of data between one or more mobile devices, and at least a first node. The method further comprises at least the steps a-f: a) At a computer from a web client sending a request for a particular graphical user interface, GUI, to an Internet server, where the Internet server is a part of the first node. b) At the Internet server responding by sending a login interface to the computer. c) At the computer enter login data and sending the login data over a secure communication path to the Internet server; d) At the Internet server sending the login data to a data base for verification. e) At the database respond by returning a verification if login data is correct. f) The Internet server sends the particular GUI to the mobile device if the verification test in the previous step were acknowledged. [0014] When an end user has logged in to the system for management of mobile devices he will be provided with a service enabling him to manage the content of one or more mobile devices. Generally this content managing is achieved by following a method for management and transfer of data between one or more mobile devices and at least a first node. The method comprises at least the following steps a-g: a) At a computer with a particular GUI; saving a job, such as backup, restore, delete, lock, or locate. b) Transmit said job over a secure communication line to an Internet server, where the Internet server is an element of the first node. c) At the Internet server saving the received job to a data base. d) At preset time intervals transmitting query commands to a service client from the one or more mobile devices. e) At the service client responding by sending query commands to the data base which is checking for one or more saved jobs. f) At the database responding by sending at least one queried job to the service client. g) The service client transmits the job wirelessly to the one or more mobile devices.

[0015] The method for management and transfer of data may also include the additional steps h-m related to status updates and job execution: h) At the one or more mobile devices executing the received job. i) Simultaneously or substantially simultaneously initialising a transmitting session by transmitting wirelessly status of the data content in the one or more mobile devices to the service client, j) At the service client sending the received update status to the database, k) At the end of the session transmitting from the one or more mobile devices to the service client an end of session message. I) At the service client responding by transmitting an acknowledged job message to the one or more mobile devices and simultaneously or substantially simultaneously sending a session completed to the data base. m) The internet server queries the data base for last updated status at preset time intervals and transmits job status updated message to the computer. [0016] Other advantageous features will be apparent by the accompanying claims.

Brief Description of Drawings [0017] Following is a brief description of the drawings in order to make the invention more readily understandable, the discussion that follows will refer to the accompanying drawings, in which [0018] fig. 1 is a block diagram showing a framework for management of mobile devices according to one embodiment of the present invention, [0019] fig. 2 is an example of a high level architecture according to one embodiment of the present invention, [0020] fig. 3 is a block diagram showing another example of the architecture according to one embodiment of the present invention, [0021] fig. 4 is a more detailed block diagram showing another example of the architecture according to one embodiment of the present invention, [0022] fig. 5 shows to flowcharts for execution of methods for management of data in mobile devices according to one embodiment of the present invention, [0023] fig 6 shows a typical handshake process between a mobile device and a first node, [0024] fig. 7 shows a flowchart for execution of authentication algorithms on a mobile device , [0025] fig 8 shows a login and authentication process and steps for performing general tasks, [0026] fig. 9 shows steps for performing get location tasks initiated from a computer, [0027] fig. 10 shows handshaking between mobile device and a first node for location services , [0028] fig, 11 shows the steps for performing backup of mobile devices initiated from a computer,

[0029] fig. 12 shows handshaking between mobile device and a first node for back up of mobile device ,

[0030] fig. 13 shows the steps for performing restore of data on mobile devices,

[0031] fig 14 shows handshaking between mobile device and a first node for restoring data in mobile device,

[0032] fig. 15 shows the steps for performing delete data on mobile devices,

[0033] fig 16 shows handshaking protocol between mobile device and a first node for delete data in mobile device,

[0034] fig 17 shows the steps for performing setting of parameter data on mobile devices initiated fro a computer,

[0035] fig 18 shows the steps for sending messages from a computer to mobile devices initiated by a computer, and

[0036] fig 19 shows the steps for sending command messages from a computer to mobile devices.

Mode(s) for Carrying Out the Invention

[0037] In the following it is firstly disclosed general embodiments in accordance to the present invention, thereafter particular exemplary embodiments will be described. Where possible reference will be made to the accompanying drawings and where possible using reference numerals in the drawings. It shall be noted however that the drawings are exemplary embodiments only and other features and embodiments may well be within the scope of the invention as described.

[0038] It shall be noted that the wording mobile device 1 refers to any type of mobile device that is capable of communicating wirelessly and which simultaneously have the capability of accessing Internet servers for downloading software to its platform. Further it is a requisite that the mobile device includes displaying means. The mobile devices 1 will be a platform for user specific and user personal data. Such data may comprise SMS, MMS, Contacts (PIM data), Call History, Music, Pictures, E-mail, Documents, and Video. Furthermore the mobile device may comprise one or more locations units such as GPS modules 11 , and they may also include one or more flash memory cards. In the event that the mobile device do not include a GPS-module triangulation as known in the art may be used instead. The mobile device 1 shall comprise a mobile device manager client 10 also referred to as the mobile device client 10. The mobile device client 10 provides the ability to exchange data wirelessly with a first node 2. The provision of data exchange of the types indicated above requires that data will be transferred in binary format between the mobile devices 1 and the first node 2 in contrast to Sync ML and others which use text based data on an XML platform. In the following the wording node 2 is used for a general node which according to the present invention at least comprises at least one database 15. The database will preferably ay least support MS SQL, Oracle, MySQL, Firebird and other relational databases. Furthermore, the node 2 will comprise at least one service client 14. The service client or service clients 14 are configured to provide management of the content in mobile devices 1. The service client 14 will include an interface which enables communication over the air with mobile devices 1. The communication platform can be any known platform that is suitable for wireless communication from mobile devices 1 , such as GSM, GPRS, 3G, 4G, HSPDA, EDGE and more and the protocol can be TCP/IP or any other suitable protocol adapted for packet switched networks. The node 2 further comprises means for storing data such as disk storage means 16. The node will also include a number of clients 17 which are downloadable to mobile devices. These clients 17 are a necessary requisite for enabling the mobile devices 1 to read and write user data to and from the mobile devices 1. The clients 17 supports a number of mobile device platforms among others MS Mobile 2003/5.0/6X, Symbian Series 60 third edition (Symbian 9.x), Symbian UIQ, MIDP 2.0/2.1 (series 40 all editions, Java platform 6, 7, 8), iPhone, Blackberry, Android and Palm. Finally the node 2 includes an Internet server 13, the Internet server may physically be embedded in the node, or it may physically be external to the node 2. The elements comprised in the node 2 do not necessarily have to be a physical part or the node 2; furthermore they may very well be virtual elements. [0040] An idea behind the present invention is that management of the content of mobile devices is far more easy and intuitive from a computer; hence the system for management of content in mobile devices 1 is managed from a computer 3. The computer can in principle be any computer that is suitable to communicate with other devices over a HTTP/HTTPS protocol and which furthers includes a web portal and displaying means. A particular GUI, especially adapted for displaying the content of one or more mobile devices, is executable from the computer 3. The GUI or graphical user interface is a client which enables the end user to see the content of one or more particular mobile device. Such a GUI is commonly referred to as a dashboard within the art. The content will preferably be displayed according to their types, and the content as such is not downloaded to the computer, however the content will be presented as clickable hyperlinks. Clicking on a hyperlink will enable downloading of the corresponding content from the first node 2. Furthermore the user will be able to request back up of data from a mobile device to the first node 2, to restore data from the first node 2 to one or more mobile devices 1. Still further the end user may be able to get location data for one or mode mobile devices and to lock one or more mobile device 1.

[0041] An end user which manages his/her phone according to the present invention will not necessarily have to install any software on his computer 3 since the first node 2 provides the management tools, the GUI, through an internet server 13 to the users web browser.

[0042] There are many possible scenarios in which the system for mobile device management according to the present invention can be applied. One scenario is a situation where a single person is the end user and where this end user wants to have an easy access to his mobile content. Furthermore he wants to ensure that data will not be lost and finally that third parties shall not have the access to the content of his mobile device, even if the mobile device is mislaid. Furthermore he wants to utilize the user friendly interface to download and look or listen to content on his mobile device. [0043] In another scenario the end user may be an organisation which wants to have an easy access to the content of a number of mobile devices. Private data may be omitted from the access, according to an organisations privacy policy. One important aspect for an organisation is the possibility to lock the content of lost devices thereby making sure that confidential content cannot be exploited by third parties. The feature of getting location data in real time for mobile devices can be of particular interest to some organisations.

[0044] A particularly inventive feature according to the present invention is the option of tagging images and/or documents with GEO coordinates, i.e. geotagging. Geotagging is the process of adding geographical identification metadata to various media such as photographs, video, websites, or RSS feeds and is a form of geospatial metadata. The Geotagging-enabled information can be used to find location-based content of the mobile devices. The mobile device client 10 embedded in the mobile devices 1 according to the present invention may facilitate geotagging of images, videos and documents. An option at the computer is then to download geotagged user data from the first node 2 by clicking on appropriate hyperlinks. A geographical map can be launched on the computer indicating the position related to the downloaded document(s) or multimedia. Thus a person who uses his mobile device as a camera may at a later time get a correlation between taken pictures/movies and their geographic location by utilizing the options provided by the dashboard on the computer 3. The geotagging feature may be of particular value to police, salvage corps, insurance companies, providers of electricity and gas, owners of telecom infrastructure and transport and communication authorities among others.

[0045] In the following reference is made to the drawings where figure 1 shows a typical framework for management of mobile devices according to one embodiment of the present invention. The figure consists of four main blocks, namely a block of mobile devices, a block of one or more first nodes, a customer GUI and finally an administration web interface management computer. The block of mobile devices indicates that a number of platforms and types of mobile devices can be utilized according to this embodiment. The one or more first nodes consist of a MobileWipe Service, IIS ASP. Net, database MS SQL, Oracle, MySQL, File storage, Mobile Clients (for download) and OS - Windows 2005 server.

[0046] The MobileWipe service corresponds to the at least one service client 14 discussed above.

[0047] IIS ASP. Net, is an example of a non exhaustive choice of web server, server-side script engine and software framework included in the one or more first nodes 2.

[0048] The IIS, Internet Information Services, - formerly called Internet

Information Server - is a set of Internet-based services for servers created by Microsoft for use with Microsoft Windows. This is a web server which currently include FTP (File Transfer Protocol), FTPS (also known as FTP Secure and FTP-SSL), SMTP (Simple Mail Transfer Protocol), NNTP (Network News Transfer Protocol), and HTTP/HTTPS (Hypertext Transfer Protocol/Hypertext Transfer Protocol Secure.

[0049] The ASP (Active Server Pages), also known as Classic ASP or ASP Classic, is a server-side script engine for dynamically-generated web pages. The Component Object Model (COM) is supported by the active scripting engine hence facilitating development of functionality in ASP websites. Each object from the Component Object Model provides a related group of frequently-used functions and data attributes.

[0050] The Microsoft .NET Framework is a software framework which includes a large library of coded solutions to prevent common programming problems. It further comprises a virtual machine that manages the execution of programs written specifically for the framework.

[0051] The non exhaustive examples of databases included in the one or more first nodes 2 in figure 1 , is discussed above.

[0052] The means for file storage is a generic term in the example of figure 1 and any suitable means for data storage known from the art can be included. Disk storage is a typical non limiting choice of storage means in the first node 2. [0053] The indicated Mobile clients in figure 1 corresponds to the above discussed clients 17 which are a necessary requisite for enabling mobile devices to read and write user data to and from mobile devices.

[0054] OS - Windows 2005 server is a server operating system produced by

Microsoft, it is only exemplary and other server operating systems may be utilized such as the Windows Server 2008.

[0055] Note that the framework indicated in figure 1 is only exemplary and is directed against Microsoft environment, additional elements such as additional server-side script engines, web servers, alternatives to IIS etc. may be employed by the first node.

[0056] Figure 2 shows a generic view of a high level architecture according to one embodiment of the present invention. The figure merely serves as a generic example for ease of understanding of how a system according to the present invention may look on a high level. The transport protocol between the GUI and the generic Internet is HTTPS, however any other suitable secure transport protocol may be used between the GUI, i.e. the computer 3 and the network to the first node. Note that an SMS gateway is included in the figure. One of the tasks of the SMS gateway is to transmit SMSs to mobile devices. Downloading of a mobile device manager client 10 may be performed following the steps of:

• The end user wants to take advantage of the inventive management of mobile devices system according to the present invention, hence from the already downloaded GUI requesting a mobile device manager client 10 from the first node 2. He will in his request on the GUI indicate the type of mobile device he owns.

• The first node will respond by requesting the SMS gateway to transmit an SMS to the end users mobile device. The SMS will include a link. The end user responds by "clicking" on the link after having opened the SMS, or alternatively the end user will be asked if he wants to open/install the mobile device manager client 10. In the first event "clicking" on the link will result in a download of the mobile manager 10 from the first node 2. The interface will be a web client on the mobile device and an Internet server at the first node and the protocol can be any known protocol suitable for the task. The latter example is more "automated" in that the end user only have to answer yes to a "pop up" message in the display of his mobile device.

• The mobile manager client 10 will then be installed, either by following the algorithm indicated for the "manual" solution, which is the Yes from the end user will enable downloading of the client from the first node, or the client is already downloaded together with the SMS but has not been unpacked/activated.

[0057] Now turning to figure 3, the figure shows a principal block diagram of one embodiment of the present invention. The third an also compulsory element of the GUI is omitted, hence making the figure easy to understand. In this figure the mobile device is described by two major elements the Mobile Device Manager which corresponds to the mobile device client 10 discussed above. It is further indicated that this particular mobile device includes a GPS module. The boxes that indicates SMS, MMS etc. are non exhaustive examples of data that is stored in the mobile device. The Mobile Device Data Management Server(s) corresponds to a simplified view of the first node 2. DB is a generic data base whereas File store is a correspondingly generic means for storage of data. The mobile Device Management Service corresponds to the service clients 14 discussed above. [0058] Figure 4 is a block diagram which in a more detailed way describes the elements constituting the system according to the present invention. In the discussion above most of the elements are described in details; however some further explanation with respect to the communication links between the mobile device 1 and the first node 2 is needed. The service client 14 of the first node 2 interacts with the mobile device client 10 in the mobile device. The communication protocol can be any of GPRS, EDGE, and HSPDA etc. or generally speaking any suitable telecommunication protocol/mobile communication system may be used. Further, the convergence between data communication and telecommunication may well lead to the use of other communication platforms in the future. The communication link between the mobile device client 10 and the service client 14 is used for backup of data from the mobile device 1, for restoring data in the mobile device 1. The service client 14 uses this link when GEO data is requested from the mobile device client 10. Deletion of the content of the mobile, as well as locking the mobile is also supported by commands sent from the service client 14 to the mobile device client 10. Other commands and options will be described with support from the figures 7-14. The web browser 12 embedded in the mobile device 1 and the Internet server of the first node 2 is interacting using traditional web interfaces. This interface supports downloading of the mobile device client 10 from the first node 2 via the Internet server 13 in the node 2. Downloading the mobile device client 10 is a prerequisite for interaction between the mobile device 1 and the service client 14.

[0059] Figure 5 shows two flow charts where the charts numbered 10 indicates in a simple way the steps in the interaction between the mobile device client 10 and the first node 14 during normal use. First step is to activate the mobile device 10.1 the following step 10.2 is that the mobile device client 10 checks for commands at the first node 2. If a new command is received then a job will be executed 10.4. The job can be Backup, restoring data etc. Having finished the job then the client 10 will wait 10.5 for a predefined period of time, before continuing at step 10.2. In the event that no new commands have been sent the client 10 will jump to the wait 10.5 a predefined period of time instance.

[0060] The flowchart indicated as 11 shows a SMS command scenario. The initial step 11.1 is to send a SMS command from the first node 2 to the mobile device client 10 on the mobile device 1. The SMS will be decrypted and it will be verified whether the SMS is valid 11.2 or not. If the SMS is not valid nothing will happen. If the SMS is valid then the mobile client 10 will initialise a check 11.3 for new job at the first node 2. If there is a new job the job will be executed 11.4. Handshake between one or more mobile devices and the first node

[0061] In the general principles laid out above attention has not been paid to an example of handshake procedures between the one or more mobile devices 1 and the first node 2. [0062] In fig 6 the steps in a handshake procedure between a mobile device and the first node is shown, note that the designation in figure 6 is simplified for ease of understanding and the mobile device can be interpreted as the mobile device client 10 and the first node shall be construed as the first node 2 comprising all necessary elements such as data base 15, internet server 13 etc.

[0063] Connection of the mobile device:

1. The mobile device client 10 sends an IMEI Packet to the first node 2

2. Additionally, in the IMEI packet the client 10 sends to the first node 2 StructuredStore? data with a next field: a. The protocol features supported by the client 10 is also sent e.g.: i.e. PR_SupportedFeatures: type(UINT64), value: bit set that define supported by client protocol features, such as for example rsync algorithm.

3. The first node 2 responds by sending an acknowledge (AckPacket) to IMEIPacket from p.4 with dwUserData set to "1" if registration of the device 1 is required otherwise that is when the device 1 is registered a "0" is sent.

4. In the Ack packet, which the first node 2 sent as response to the IMEI packet, the client 10 receives the first node's 2 value of PR_SupportedFeatures and adjusts this with its own bit set. In subsequent communications the client 10 and first node 2 will use protocol features supported by both sides.

5. The connection is considered to be established.

[0064] It is also shown in figure 6 an example of communication between the mobile device 1 and the first node 2 or the server as is the notion in the figure regarding updating dashboard of the mobile device 1, by dashboard it is meant the GUI on the mobile device 1.

[0065] Updating the configuration data:

1. Client 10 sends IsNewConfigurationAvailablePacket to the first node 2. 2. The first node 2 responds by sending an AckPacket to IsNewConfigurationAvailablePacket with dwUserData set to "1" if the configuration settings are updated on the first node 2 side.

3. If the configuration settings must be updated then the first node 2 sends ConfigurationDataPacket.

4. Client 10 should receive MessagePacket and display its contents before proceeding that is if it's not empty.

[0066] Get command(s) from server:

1. Client 10 sends IsNewCommandAvailablePacket to the first node 2 according to one aspect of the present invention.

2. The first node 2 responds by sending AckPacket to IsNewCommandAvailablePacket with dwUserData set to "1" if the first node 2 has a command for the client 10 to execute.

3. If dwUserData was set to "1 " the first node 2 or the server also sends CommandDataPacket to the mobile device 1.

[0067] Now turning to figures 7-19 in which steps for performing different tasks are shown. Most examples indicate the steps where a task is initiated from the computer 3 and also an example of handshake protocols between a mobile device 1 and the first node 2.

Methods for Login and Authentication From a Computer

[0068] Figure 8 illustrates one example of a method for login and authentication from a computer 3 to a first node 2 according to the present invention. The object of the login process is to get access to a system for management and transfer of data between one or more mobile devices 1 , and at least the first node 2.

[0069] Firstly, an end user will launch a web browser at a computer 3. The user will send 1.1 a request 1.1.1 for a particular graphical user interface, GUI, to an Internet server 13. The particular GUI is particularly suitable for management and control of the content of one or more mobile devices 1. The graphical user interface may according to one embodiment be a dashboard. The dashboard and the computer it is running on will preferably not handle real user data in standard mode. It is faster and gives a better response to only download pointers to the elements at the first node 2. The pointers will then preferably be clickable hyperlinks which gives the user access to requested user data.

[0070] The Internet server can be any type of a known server which may be physically embedded in the first node 2 or is external to the node. Load considerations may render it preferable to arrange the Internet server 13 physically separated from the rest of the first node. Technically speaking this will not make any difference with respect to the functionality of the system according to the present invention.

[0071] The next step will be the response from the Internet server 13 which responds by sending a login interface 1.3.1 to the computer 3. The transport protocol for the communication can be any known protocol known to the person skilled in the art, however in the figures HTTPS is indicated as one option.

[0072] The end user will respond by entering login data on his computer 3 to the received login interface.

[0073] Having finished the login session the login data will be sent 1.1.2, preferably, over a secure communication path to the Internet server 13. The login data may also be encrypted hence requiring a decryption key at the receiving party. Strong encryption will not require the same degree of security to the communication links.

[0074] The receiving party, that is the Internet server 13, will respond by sending the login data 1.3.2 to a data base 15 for verification. As discussed above the database can be of any suitable type, and the database may comprise a number of databases.

[0075] The database 15 is responding by returning a verification 1.5.1 if login data is correct. If the login data is incorrect the database will return an error message to the Internet server 13, the Internet server will forward the error message to the computer 3 at the end user. The end user may be given a preset number of login retries before being finally abandoned. This is only a matter of design. In the event that the login information is correct then the Internet server 13 sends 1.3.3 the particular GUI to the computer (3). [0076] As indicated above the GUI is configured to display the content of one or more mobile devices 1 on a display on the computer 3. The displaying of the content of the one or more mobile devices 1 will typically involve transmitting the content of the one or more mobile devices 1 to the first node 2. The first node will respond by storing the received data in storage means integral to the first node, where the storage means can be any of the types discussed above. An end user will enter a request for displaying of the content of one or more mobile devices 1 on the GUI, the request is sent to the first node 2. The first node will provide the GUI with hyperlinks to the content of the one or more mobile devices stored in the first node 2, refer to the discussion of clickable pointers in the previous section.

[0077] Data saved from the mobile devices 1 to the first node 2 can be viewed in a web browser at the computer 3 and shared with friends through different internet services like FaceBook, MySpace, Yahoo and more.

Methods for Login and Authentication Between First Node and Mobile Device

[0078] Reference is now made to figure 7 in which a flow chart indicates an example of steps necessary for authentication of a mobile device 1. In contrast to the previous section this example is directed to the communication between the first node 2 and the mobile device 1 whereas the previous example were more general and also indicated communication initiated by the computer 3.

[0079] In the first step 700 the first node 2 receives packets from the mobile device 1. The sent packets will be initiated by the mobile device client 10, however to increase readability the notion mobile device 1 shall comprise all elements and clients in the mobile device 1 in this example.

[0080] The first node 2 analyses the received packet and executes a "received

IMEI packet" test 710. If the packet is not an IMEI packet then the steps 1- 3 below will be executed. If the packet is an IMEI packet then the steps 4-9 will be executed.

1. The first node executes a "LoginPacket received test" 720, that is the first node 2 executes a test to see if the mobile device 1 already has sent its login data to the first node 2. If no continue at step a 721 , if yes continue at step b 722. a. As a consequence of the negative outcome of the previρus tests the first node 2 will reject the mobile device 1 from connecting to the first node 2, as the mobile device did not send an IMEI packet neither login data hence the first node cannot identify the mobile device. b. Following the positive outcome of the test for received LoginPacket the first node 2 will execute a test 722 were it inquire the mobile device 1 if it is waiting for login, if the mobile device 1 is still waiting for login then continue at step 2 otherwise reject by going to step a.

2. If the mobile device 1 waits for login then a test for correctness 723 of the login key will be executed, if the login keys are wrong then the mobile device 1 will be rejected connection hence continue at step a. If the login key (LoginKey) is correct then continue at step 3.

3. As a consequence of correct LoginKey the mobile device will send 724 its IMEI packet to the first node 2. The subsequent step will be execution of the first "received IMEI packet" 710 test.

4. As a response to the received IMEI packet the first node will execute a test to verify if the mobile device 1 has been registered or not 730. If the test turn out to be negative then execute step 5. If the test is true then continue in step 7.

5. The first node 2 will check 731 if the first device 1 waits for registration if it does not then the following step will be step 5a, otherwise the following step will be step 6. a. As the device does not provide registration data the mobile device 1 will be rejected 732 connection to the first node 2.

6. After the mobile device 1 has sent its registration data the first node 2 will register the device and install 733 the mobile device 1 in its storing means for example its data base 15.

7. The authentication process is complete 734 and the system i.e. the first node 2 is ready to receive tasks from the mobile device 1.

[0081] The steps indicated above is an example of an authentication process between a mobile device 1 and a first node 2 it requires the use of IMEI packets, however other identifiers sent from the mobile device 1 can be used in place of the indicated IMEI packets.

General Methods for Management of Content in Mobile Devices

[0082] Reference is now made to figure 8, item 1.7. The figure shows the general steps for a method for management and transfer of data between one or more mobile devices 1 and at least a first node 2 where the GUI dashboard at the computer is the end users interface. In this figure it is referred to general handshaking between all elements of the system hence including the computer 3. It shall be understood that details related to handshaking between the mobile device and the first node 2 maybe omitted. The method necessitates that the previous steps of login and authentication were successful.

[0083] Firstly, the end user will use his GUI on the computer 3 to choose the kind of job he wants to execute against the one or more mobile devices, hence he starts by saving the wanted job. The job can be a backup of the content in the mobile devices 1 , it can be a restore content in one or more mobile devices 1 , a delete all content, to lock the mobile devices 1 or to locate one or more mobile devices 1 among others.

[0084] Having saved the job at the computer the next step will obviously be to transmit said job 1.1.3 over a communication line to the Internet server 13. Reference is made to the login section above with respect to the choice of communication line/link and level of security. Further the elements of the first node 2 are the same as described in the login section hence it will be superfluous to describe the elements in this section.

[0085] At the Internet server 13 the received job 1.3.4 will be saved to the data base 15.

[0086] The mobile device client 10 of the mobile devices 1 sends query commands 1.2.1 continuously, at preset time intervals, or as a response to a mobile device users input, to the service client 14. It shall however be understood that many or the advantageous features according to the present invention is based on automatic and regularly sent queries, this is due to the fact that jobs are initiated from the GUI and it will for instance be meaningless to use locate or lock commands based on randomly sent queries from the mobile devices 1. The query frequency is a matter of design and will be tailored to achieve a best trade off between battery life time and operability of the management system.

[0087] The service client 14 responds by sending query commands 1.4.1 to the data base 15. The data base 15 will check if there is one or more saved jobs in the data base which matches the query.

[0088] If there is a match then the database 15 will respond by sending at least one queried job 1.5.2 to the service client 14.

[0089] The service client 14 will then transmit the job 1.4.2 preferably wirelessly to the one or more mobile devices 1.

[0090] The one or more mobile devices 1 will then execute the received job.

Simultaneously or substantially simultaneously a transmitting session will be initialised at the mobile device 1. In this session status data will be sent wirelessly 1.2.2 from the mobile device 1 to the service client 14. The status data can be any type of content that is accessible for the mobile device client 10 in the mobile.

[0091] The service client 14 responses by sending 1.4.3ihe received update status to the database 15. A normal session of this type will generally be ended by sending one or more end of session messages. The receiver of the end of session message may respond by sending an "ack received end of session". Hence the one or more mobile devices 1 will transmit at least one end of session message to the service client 14. At the service client 14 the acknowledged job message will be followed by simultaneously or substantially simultaneously sending a session completed to the data base 15.

[0092] The internet server 13 queries on a regular basis or event triggered 1.5.4 the data base 15 for last updated status. Further the Internet server 13 will finish the job by sending a job status updated message 1.3.5 to the computer 3.

Methods for Execution of Location Services

[0093] Reference is now made to figure 9. The elements involved in this method are similar to the elements involved in the methods for general management described above, the communication links/lines are also similar. In the general example above the job to be performed were of a general character in this method the job is a locate task. It is the wish of the end user at the computer 3 to get location data for one or more mobile devices 1. The introductory steps in the methods are similar to those in the general methods for performing a job. This method differs essentially from the previous described method in the steps following after having received the job 1.4.2 from the service client 14 at the one or more mobile devices 1.

[0094] Furthermore for a more detailed picture of the handshake between the mobile device 1 and the first node 2 reference is made to figure 10

[0095] The one or more mobile devices 1 will execute the received "request location coordinates" job by sending a location query 2.2.2 from the mobile device manager client 10 embedded in the one or more mobile devices to a GPS-module 11 in the mobile device. It is a prerequisite for this method to work that the mobile device has a GPS-module embedded or alternatively that the location coordinates can be provided to the mobile device manager client 10 manually or by triangulation as is known from the art.

[0096] The GPS-module 11 will respond by returning location coordinates 2.3.1 to the mobile device manager client 10. The mobile device manager client 10 will transmit the location coordinates 2.2.3 to the service client 14 and the service client 14 sends the location coordinates 2.5.3 to the internet server 13.

[0097] The Internet server 13 will forward 2.4.2 the received location coordinates to the computer 3.

[0098] The end user sitting at the computer 3 with the GUI displayed on his screen may in accordance to one embodiment experience that a map in a web browser 2.9 with location coordinates indicated is launched on his computer 3. Hence he will have the possibility of receiving real time position data on one or more maps on his computer 3 for one or more mobile devices.

[0099] As indicated in figure 10 the actual transfer of location data from the mobile device 1 and the first node 2 will normally include a number of iterations. These iterations in the handshake procedure includes necessary steps to take to verify that a transfer process is complete and further that it has been successful, without errors.

[0100] An practical example of the handshaking between the mobile device client 10 of tne mobile device 1 and the service client 14 of the first node according to one embodiment with support from figure 10 is described in the following.

[0101] In the steps described it is essential that the device has built-in or has a Bluetooth GPS module, then it is possible to automatically locate the device. As described above if this is not the case triangulation or manual input of geo data must be entered by the user of the mobile device 1. The service client 14 will try to locate devices 1 within a set period e.g. 5 minutes. If no location information are retrieved, then the location service will stop (progress bar indicates 5 minute interval).

[0102] GPS support requires that the first node 2 has the capability to send SMS.

1. The service client 14 sends SMS message containing 'locate' command to one or more mobile devices 1.

2. The mobile device client 10 receives the SMS message via SMS interceptor module and connects to the service client 14 of the first node 2, for ease of understanding the internal communication in the mobile devices 1 are omitted.

3. The mobile device client 10 sends ProgressTotalPacket with dwType set to CommandSubjectLocate and dwTotal equal to the timeout of locate operation, in milliseconds typically approx 5 minutes.

4. The mobile device client 10 periodically sends ProgresslncrementPacket with dwType set to CommandSubjectLocate this will typically be sent every 3-5 seconds.

5. The mobile device client 10 sends ProgressEndPacket with dwType set to CommandSubjectLocate when a preset timeout period elapses or location is taken from the GPS device 11.

6. If geographical coordinates are taken from GPS device 11 the mobile device client 10 sends LocationPacket, filled in with appropriate data. [0103] A more detailed description of the packet and header structure is described in a following description where a general review of most of the packets, headers, payload and data set are described.

A Method for Executing Back Up of Mobile Devices

[0104] It is referred to figure 11 where the necessary steps for back up of mobile devices initiated from the computer 3 are shown. The general method described above covers most of the steps necessary for back up of mobile devices. However the final step described for the general method is followed by the additional step of showing the back up transfer status in the particular GUI 3.7 on the computer 3.

[0105] Furthermore the backup between the mobile device 1 and the first node 2 will include a number of sub steps necessary to control the transfer of data refer to figure 12. Figure 12 indicates the necessary steps and the necessary signals in the data transfer as such. The procedure shown in figure 12 corresponds to the 3.2.2, 3.4.2 and 3.5.2 in figure 11.

[0106] A practical example of the handshaking between the mobile device client 10 of the mobile device 1 and the service client 14 of the first node according to one embodiment with support from figure 12 is described in the following.

[0107] The progress info during backup process is performed by the first node 2. 1. For each of the command subjects requested the following steps applies: a. The mobile device client 10 sends total number of items or alternatively total size for the files in ProgressTotalPacket. b. For each of the item to back up the following applies: i. The mobile device client 10 sends PackageltemStart packet with transaction ID. ii. The mobile device client 10 sends

PackageChunkHeaderPacket with meta-information about item(s). iii. a) The following steps applies only if rsync is supported: iv. b) The service client 14 of the first node 2 initiates scan of existing backup copy and sends sequence of calculated digests (weak, strong) for each block. v. c) The mobile device client 10 receives the set of digests and start rSync search process. vi. The mobile device client 10 sends one or more

PackageChunkDataPacket representing item's or file's data, it is recommended to transfer them as compressed packets. vii. The mobile device client 10 sends empty PackageltemEnd packet. viii. The service client 14 of the first node 2 updates its progress information here using the formula PackageltemEnd packets received/total number of items from ProgressTotalPacket c. The mobile device client 10 waits for all PackageltemEnd packets from the service client 14. d. The mobile device client 10 sends ProgressEnd Packet indicating that all items are backed up.

[0108] A more detailed description of the packet and header structure is described in a following description where a general review of most of the packets, headers, payload and data set are described.

A Method for Executing Restoration of Data in Mobile Devices

[0109] It is referred to figure 13 where the necessary steps for restoration of data in mobile devices initiated from the computer 3 are shown. The general method described above covers most of the steps necessary for restoration of mobile device data. However the final step described for the general method is followed by the additional step of showing the restore transfer status in the particular GUI 4.7 on the computer 3.

[0110] Furthermore the restore between the mobile device 1 and the first node 2 will include a number of sub steps necessary to control the transfer of data refer to figure 14. Figure 14 indicates the necessary steps and the necessary signals in the data transfer as such. The procedure shown in figure 14 corresponds to the 4.2.3, 4.4.3 and 4.5.2 in figure 13. [0111] A practical example of the handshaking between the mobile device client 10 of the mobile device 1 and the service client 14 of the first node for restoration of data in the mobile device 1 according to one embodiment with support from figure 14 is described in the following.

[0112] During restore the service client 14 of the first node 2 updates progress info itself.

[0113] The mobile device client 10 sometimes doesn't need to retrieve whole data (the item probably exists and doesn't need to be restored). Therefore it works the way shown below.

[0114] For each of chunk types that need to be restored the following steps/handshaking applies:

1. The service client 14 of the first node 2 sends total number of items which shall be restored in ProgressTotalPacket. All ack packets from the mobile device client 10 must be sent prior to ack packets from the Internet server 13 (i.e. the mobile device client 10 is not allowed to send ChangelDPacket prior to all ack packets on PackageChunkHeaderPackets)

2. For each of the items sent in item one above: a. The service client 14 of the first node 2 transfers complete meta- information about all items in series of PackageChunkHeaderPacket. b. On each PackageChunkHeaderPacket the mobile device client 10 send AckPacket containing dwUserData set to "1" if it wants this packet and set to "0" if not. c. The service client 14 of the first node 2 asynchronously receives AckPacket s and then transfer items requested i.e. only PackageChunkDataPackets. d. For each of the item received the mobile device client 10 executes the following steps/handshaking: i. Performs restore logic having PackageChunkHeaderPacket and PackageChunkDataPacket's ii. Sending AckPacket containing dwUserData set to "1 " if the header changed upon restoration and otherwise to "0" . If set, transfer ChangelDPackets packet with updated data.

[0115] Restoration of files backed up from storage cards may be performed in the following way:

1. If file is found on the same place it backed up from (no matter device memory or storage card) the file is updated at the same place.

2. If card is found file backed up from, restoration is performed on that card

3. Otherwise restoration is performed on the card with maximum available space at the moment of restoration i.e. if the card exists.

[0116] A more detailed description of the packet and header structure is described in a following description where a general review of most of the packets, headers, payload and data set are described.

A Method for Deletion of Data in Mobile Devices

[0117] It is now referred to figure 15 where the necessary steps for deletion of data in mobile devices initiated from the computer 3 are shown. This feature is of particular interest where the owner or owners of mobile devices wants to protect stored data from access by third parties who have stolen or found mobile devices. Private and confidential information such as e-mails and documents are commonly stored on mobile devices today, hence these devices are a potentially security risk for the owners or the end users. The general method described above covers most of the steps necessary for deletion of mobile device data. However the final step described for the general method is followed by the additional step of showing the deletion status in the particular GUI 5.7 on the computer 3.

[0118] As indicated for the previous jobs deletion of data necessitates control of data transfer between the one or more mobile devices and the first node. It is essential that control of the deletion process in the mobile devices is maintained in the first node during the process, hence the process of deletion includes a number of sub steps shown in figure 16, these steps are necessary to enable a secure deletion process on the mobile devices. When the job is completed the mobile devices sends a "ProgressEndPacket" to the first node 2. [0119] The delete process in its simplest form can be described by general procedure indicated below. The mobile device 1 owner can login to the to the service client 14 from his computer 3 via his downloaded GUI using a downloaded client according to the present invention and chose to delete chosen data on his mobile device 1. This feature is used in case of loss, theft or misplacement of the mobile device. User chose what he/she wants to delete (example: Pictures, SMS, Email, contacts, documents) whereby the chosen content is deleted on the mobile device 1. The delete procedure comprises the following steps:

1. From the dashboard on the computer 3, the user chose which data to delete on the mobile device 1 and then press a delete button. This event is trigging the service client 14 in the first node 2 to save the data chosen to be deleted in the database 15 for the relevant mobile device 1.

2. The mobile device client 10 checks for new job in a set interval (e.g. every 5 minutes). If the delete command is registered in the database 15 for that mobile device 1 , the service client in the first node 2 gives that job to the mobile device client 10 and the mobile device client 10 perform the deletion of chosen data on the mobile device 1.

[0120] A practical example of the handshaking between the mobile device client 10 of the mobile device 1 and the service client 14 of the first node according to one embodiment with support from figure 16 is described in the following.

[0121] During wipe process the mobile device client 10 updates progress info on the service client 14 of the first node 2.

[0122] 1. For each of command subjects requested to wipe/delete the following handshaking applies:

1. The mobile device client 10 sends total number of items or total size for the files in the ProgressTotalPacket.

2. For each of the item upon wipe deletion the mobile device client 10 sends ProgresslncrementPacket with increment value if this a file. 3. The mobile device client 10 sends ProgressEndPacket indicating that all items are wiped/deleted.

[0123] A more detailed description of the packet and header structure is described in a following description where a general review of most of the packets, headers, payload and data set are described.

Locking mobile devices

[0124] The owner of the one or more mobile devices 1 can login to the first node 2 and from the GUI, dashboard, on his computer 3 choose to lock his mobile device. This feature is used in case of loss or misplacement of the mobile device. After the mobile device is locked the mobile device cannot be used by anyone before it is unlocked either from the GUI, dashboard, of the computer 3 or from using a unlock code directly on the mobile device itself. A unique unlock code is automatically generated when user lock the mobile device 1 and this code may be displayed on the computer's dashboard. In the following it is indicated an example of the necessary steps for locking mobile devices from a computer with a client according to the present invention. The lock procedure comprises the following steps:

1. The user press a button saying "Lock mobile device" on a web dashboard, GUI, or any other button indicating this function on his computer. This event is trigging the first node 2 to save a Lock command in the database 15 related to the relevant mobile device 1.

2. The mobile device client 10 checks for new job in a set interval (e.g. every 5 minutes). If the Lock command is registered in the database 15 for that mobile device 1 , the service client in the first node 2 gives that job to the mobile device client 10 and the mobile client 10 locks the mobile device 1.

[0125] The Lock disable the use of the mobile device 1 and may also display a screen saying that the mobile device 1 is locked and that either unlock code has to be inserted or mobile device has to be unlocked from the GUI i.e. the client according to the present invention on the computer 3 in order to unlock the mobile device 1. The user cannot access any menus or access any data on the mobile device 1. Independently of which button the user chooses on the mobile device 1 or which commands he tries to enter the same message is given, rendering the data and all features on the mobile device 1 unavailable.

A Method for Setting of Parameter Data in Mobile Devices

[0126] It is referred to figure 17 where the necessary steps for setting of parameter data in mobile devices are shown. The general method described above covers most of the steps necessary for setting of parameter data of mobile devices. This method differs from the previous described methods in that the step where the job 1.4.2 from the service client 14 to the mobile devices 1 includes transmitting settings 6.4.2 wirelessly to the one or more mobile devices 1.

A Method for Sending Messages to Mobile Devices

[0127] It is referred to figure 18 where the necessary steps for sending messages from a computer 3 to one or more mobile devices 1 are shown. The general method described above covers most of the steps necessary for sending messages from a computer 3 to one or more mobile devices 1. This method differs from the previous described methods in that the step where the job 1.4.2 from the service client 14 to the mobile devices 1 includes transmitting one or more messages 7.4.2 wirelessly to the one or more mobile devices 1.

A Method for Sending SMS Command to Mobile Devices

[0128] Reference is made to figure 19 in which the necessary steps for sending SMS commands from a computer 3 to mobile devices 1 where the job status is updated at the computer 3.

[0129] The method necessitates that the steps of login and authentication were successful.

[0130] Firstly, the end user will use his GUI on the computer 3 to choose the sending SMS commands from a computer 3 to mobile devices job. He starts by saving the wanted job.

[0131] Having saved the job at the computer the next step will obviously be to transmit said job 8.1.1 over a communication line to the Internet the service client 14 of the first node 2 13.

[0132] At the Internet server 13 the received "Job saved with status SMS" 8.1.1 is forwarded to an SMS gateway 8.3 and fig. 2 as a formatted SMS call. The gateway 8.3 forwards 8.3.1 the formatted SMS to the chosen mobile device client 10.

[0133] The mobile device client 10 of the mobile devices 1 sends query commands i.e. check for new jobs, 8.2.1 continuously, at preset time intervals, or as a response to a mobile device users input, to the service client 14.

[0134] The service client 14 responds by sending query commands 8.5.1 to the data base 15. The data base 15 will check if there is one or more saved jobs in the data base which matches the query.

[0135] If there is a match then the database 15 will respond by sending at least one queried job 8.6.1 to the service client 14.

[0136] The service client 14 will then transmit the job 8.5.2 preferably wirelessly to the one or more mobile devices 1.

[0137] The one or more mobile devices 1 will then execute the received job.

Simultaneously or substantially simultaneously a transmitting session will be initialised at the mobile device 1. In this session data will be sent wirelessly 8.2.2 if there are any data to send from the mobile device 1 to the service client 14.

[0138] The service client 14 responses by sending 8.5.2 the received data to the database 15. A normal session of this type will generally be ended by sending one or more end of session messages. The receiver of the end of session message may respond by sending an "ack received end of session". Hence the one or more mobile devices 1 will transmit at least one end of session message to the service client 14. At the service client 14 the acknowledged job message will be followed by simultaneously or substantially simultaneously sending a session completed to the data base 15.

[0139] The internet server 13 queries on a regular basis or event triggered 8.6.3 the data base 15 for new data. Further the Internet server 13 will finish the job by sending a job status updated message in set interval 8.4.2 to the computer 3.

Packet Structure/Composition [0140] The content of the packets, the structures of the packets, the payload and header contents for the communication between the mobile device client 10 and the service client 14 of the first node 2 is described in this section. This level of description is on a low level of abstraction, hence the definitions and structures described are merely examples, improvements and amendments will be a natural consequence of product development. Hence changes in details will be within the scope of this invention and may also not alter the functionality according to the present invention

Packet structure

[0141] The protocol packet between the mobile device client 10 and the service client 14 contains packet header and packet data following each other, in accordance with the following table 1.

[0142]

Table 1

[0143] The data contained in packet depends from the packet header dwType member (see below). Packet header [0144] The packet header has the next binary structure that is the fields follow each other in order of declaration. [0145] Byte ordering in data types is low-byte-first. Aligning to 4-byte boundary is required see table 2. [0146]

Table 2

[0147] Length representation

[0148] If compressed flag is specified then len field is represented as the structure indicated in the table 3. [0149]

[0150] Otherwise it is 4-byte unsigned int (DWORD).

Installation data packet

Purpose

[0151] The purpose of the Installation data packet is to transfer all data needed for the mobile device client 10 registration in Mobile device client 10 and the service client 14 of the first node 2 software. Structure

[0152] The structure of the Installation data packet is depicted in the table 4.

Table 4

[0153] Advanced data about the mobile device client 10 configuration is optional and may contain information about flash cards. [0154] Format of the flash card data entry is indicated in table 5 (in PR_FlashCard objects). [0155]

Table 5

[0156] "TSS000728 - Retrieving memory card unique ID retrieved from http://wiki.forum.nokia.com/index.php/TSS000728,.- _Retrieving_memory_card_unique_ID, from Forum Nokia Wiki.

[0157] Table 6

[0158]

Table 7

Keywords (APIs, classes, methods, functions):

[0159] Description [0160] The unique serial number from the MMC card identification register (CID) can be retrieved with the following function (if supported by the media):

[0161] Tint RFs::GetMediaSerialNumber( TMediaSerialNumber &aSerialNum, Tint aDrive );

[0162] Solution [0163] RFs::GetMediaSerialNumber() returns 16 bytes (128 bits) which are a copy of the card's CID register, defined as follows:

[0164]

Table 8

[0165] Check for updated configuration availability (IsNewConfigurationAvailablePacket)

Purpose

[0166] The purpose of the "Check for updated configuration availability

(IsNewConfigurationAvailablePacket)" is to ask the service client 14 of the first node 2 if updated configuration exist (or forcibly get configuration from server). The service client 14 of the first node 2 should response with AckPacket with dwllserData set to 1 if one of the fields sent with later ConfigurationDataPacket has been changed. Otherwise the service client 14 of the first node 2 should set 0 to AckPacket's dwUserData field.

Structure

[0167] The structure of the "Check for updated configuration availability (IsNewConfigurationAvailabiePacket)" is shown in table 9.

[0168]

Table 9

Configuration data packet Purpose

[0169] The purpose of the "Configuration data packet" is to deliver configuration settings to the mobile device client 10:

1. Connect period. How often the mobile device client 10 should look for new messages from the service client 14 of the first node 2 trough GPRS/GSM.

2. Backup period. How often the mobile device client 10 should automatically backup its state to the server.

3. What to backup if automatic backup is requested.

4. SMS messaging (availability of a the mobile device client 10 to handle incoming SMSes from the service client 14 of the first node 2. 5. Lock period. When the mobile device client 10 loses connection and this interval elapses, the mobile device client 10 should lock itself automatically.

6. Wipeout period. When the mobile device client 10 loses connection and this interval elapses, the mobile device client 10 should wipe out itself automatically.

Structure

[0170] The structure of the "Configuration data packet" is shown in table 10.

Table 10

Backup schedule description

Format

[0171] The backup schedule contains the next information

1. How many time intervals should elapse before two subsequent backups.

2. The duration of a single interval (a minute, an hour, a day or a week)

3. Days of a week when backup events should occur (only for backup)

4. Time of a day when event should occur (only for backup)

[0172] Backup schedule is encoded with double word (32 bits) using the format shown below in table 11 (from higher to lower bits). [0173]

Table 11

Field Bits Range reserved 0 0 - 1

Type of time

1-4 0 to 7 actually (see constants below) interval

Number of time

5-10 0 to 60 actually intervals bit mask of week days (Sunday - 1st bit,

Week mask 11-17 Monday - 2nd, etc.)

Time of a day 18-29 0 to 1439 - time of a day, in minutes reserved2 30-31 0 - 3

[0174] The types of time interval is depicted in table 12. [0175]

Table 12

[0176] The positive number of time intervals is specified in the highest byte of backup period descriptor. [0177] Time of a day [0178] Time period in minutes: from midnight until the time when scheduled backup should be done, (for example, for 2:13 AM this number would be

133)

[0179] Week mask [0180] Mask of 7 bits, where Oth corresponds to Sunday and 6th - to Saturday. If the particular bit is set, the backup should occur on that day [0181] Backup schedule notes

[0182] Fields validity for different time intervals is shown table 13. [0183]

Table 13

[0184] If time of a day field is more than 1440, then time of a day is considered to be absent (corporate edition behaviour), and scheduled event is triggered exactly after n periods have elapsed (since the moment of changing configuration). Week days and time of a day are ignored for lock and wipe periods. The Backup list is represented in command format.

Message packet

Purpose

[0185] The purpose of this packet is to transfer human-readable message to the mobile device client 10 when it is connected. [0186] Structure

[0187] The structure of the "Message packet" data packet" is shown in table 14.

[0188]

Table 14

[0189]

Check for command availability (IsNewCommandAvailablePacket)

Purpose

[0190] The purpose of the "Check for command availability" is to ask the service client 14 of the first node (2 if commands for device exist. The service client 14 of the first node 2 should response with AckPacket with dwUserData set to 1 if one or more commands exist. Otherwise the service client 14 of the first node 2 should set 0 to AckPacket's dwUserData field.

Structure

[0191] This packet does not contain any data.

Command data packet

Purpose

[0192] The purpose of the "Command data packet" is to deliver to the mobile device client 10 command data from the service client 14 of the first node 2.

[0193] Structure

[0194] The structure of the "Command data packet" is shown in table 15.

Table 15

Progress total packet

Purpose

[0195] The purpose of the "Progress total packet" is to tell to the other side (either the mobile device client 10 or the first node 2 the total number of items being transferred or total number of bytes if files are being transferred, so that progress information could be updated correctly.

Structure

[0196] The structure of the "Progress total packet" is shown in table 16.

[0197]

Table 16

[0198] When doing backup, the packet should be acknowledged with AckPacket with dwUserData set to "0" if backup is denied due to per-user quote constraint this is also known as 'MaximumMBPerUser'.

[0199] When doing restore, the packet should be acknowledged with AckPacket with dwUserData set to "0" if restore is possible and "1" and structured store attachment if restore is not possible and error occurred. This attachment should contain information about an error which should be shown to a user on the administrative part.

Progress increment packet

Purpose

[0200] The purpose of the "Progress increment packet" is to tell that item of given Command Subject processed (backed up/wiped) successfully.

Structure

[0201] The structure of the "Progress increment packet" is shown in table 17.

[0202] Table 17

[0203] When restoring dwType is equal to ChunkType enumeration value. The reason for that is that one CommandSubject, for instance Contact command subject may refer to heterogeneous item types for instance to device contact and to SIM contact. So that while restoring appropriate items (device contact or SIM contact) could be distinguished from each other.

[0204] Currently this packet type is used for wipe command only. The progress info for another command types is adjusted automatically.

Progress end packet

Purpose

[0205] The purpose of the "Progress end packet" is to tell that all items of given Command Subject processed successfully.

Structure

[0206] The structure of the "Progress increment packet" is shown in table 18.

[0207]

Table 18

[0208] When restoring dwType is equal to ChunkType enumeration value. The reason for that is that one CommandSubject, for instance Contact command subject, may refer to heterogeneous item types (for instance to device contact and to SIM contact). So that while restoring appropriate items (device contact or SIM contact) could be distinguished from each other.

Package Chunk Header packet Purpose

[0209] The purpose of the "Package Chunk Header packet" is to transfer meta- information about the item/file which is being transferred. Note that this packet is completely sent to the mobile device client 10 on restore to define is an item should be transferred from the service client 14 of the first node 2 or not.

Structure

[0210] The structure of the "Package Chunk Header" packet is shown in table 19.

Table 19

[0211] The following restrictions may apply to the auxiliary item's meta data:

1. Data must not contain object types

2. Meta data should be as small as possible, but no more than 3000 bytes.

3. The chunk order within structured store is significant, so shuffling chunks is restricted. Although, you're allowed to insert new chunk to the middle of this meta data so that previous order wouldn't be lost. The chunk order is maintained by particular store item.

Package Chunk data packet

Purpose

[0212] To transfer item (like SMS item, contact item, etc). The meta-information about this item is given in PackageChunkHeaderPacket. Structure [0213] The structure of the "Package Chunk data packet" is shown in table 20. [0214]

Table 20

Win32 Nam

Length Description Type e data meta-information

PackageChunkHeaderPac specified in previous ket.dwDataSize bytes PackageChunkHeaderPack et for

Item start packet

Purpose

[0215] To notify receiver that transferring transaction is about to begin. Sender should pass transaction ID (unique value of any number of bytes). After successful transferring of item data and sending PackageltemEnd packet sender is responsible to wait for all transaction IDs in PackageltemEnd packets.

Structure

[0216] The structure of the "Item start packet" is shown in table 21.

[0217]

Table 21

Item end packet

Purpose

[0218] The purpose of the "Item end packet" is to end transferring transaction.

Structure

[0219] If this packet is sent by the side that sent PackageltemStart packet, the packet must be empty.

[0220] If this packet is sent by another side, the packet has the structure of . [0221] where transaction ID is the received in PackageltemStart structure transaction ID. Change ID packet Purpose [0222] The data from PackageChunkHeaderPacket might be changed upon restoration. This packet is solely intended to notify the service client 14 of the first node 2 that item's metadata is changed after restoration and the service client 14 of the first node 2 should update its database and all related items to reflect this change.

Structure

[0223] The same as PackageChunkHeaderPacket's structure.

Location packet

Purpose

[0224] This packet is intended to transfer geographic coordinates such as latitude and longitude.

Structure

[0225] The structure of the Location packet is shown in table 23.

Table 23

Acknowledgement packet

Purpose

[0226] This packet is intended to acknowledge receiving particular packet and send auxiliary information in response. Structure

[0227] The structure of the Acknowledgement packet is shown in table 24.

Table 24

sent to (see Packet header)

Auxiliary information (packet

4 bytes DWORD dwUserData dependent) RSync Item Digests packet Purpose [0228] This packet is used for sending item digests between 'Generator' and

'Sender' in ip-rsync algorithm Structure

[0229] The structure is indicated in table 25.

Table 25

[0230] Error code packet exists to report any error happening on mobile client to the service client 14 of the first node 2 and to show this error on user interface E.g. in case locate command if error happens during location process Symbian mobile client sends this packet with code of error (e.g. 710 if no device found) to server. The service client 14 of the first node 2 receives this error and calls showing error description message on user interface.

[0231] The structure of the error code packet is shown in table 26.

[0232]

Table 26

Format of the command Purpose [0233] To represent server-to-the mobile device client 10 command requests in binary form.

Structure

[0234] One may think of a command like a action-subject conjunction, like store mail,mms,docs or wipe all or locate. The verb acts like command type and the nouns are the command subjects described below in table 27.

[0235]

Table 27

Command type

[0236] The commandType field from the structure above may equal to values below given in table 28. [0237]

Table 28

Command subjects

[0238] Command subject represent partial data type which the mobile device client 10 should backup to server, restore from server, wipe or lock. The following command subject constants are defined in table 29.

[0239]

Table 29

Const

Symbolic name Description ant

0 CommandSubjectNone No subject

Contacts (address

1 CommandSubjectContacts book)

2 CommandSubjectCalendar Calendar

3 CommandSubjectSMS SMS

4 CommandSubjectMMS MMS

5 CommandSubjectEmail Email

6 CommandSubjectDocuments Documents

7 CommandSubjectCards Files on flash card

8 CommandSubjectCallHistory Call history

9 CommandSubjectlMEI IMEI/IMSI

Everything specified

10 CommandSubjectEverything above

11 CommandSubjectBlueTooth Switch Bluetooth off

12 CommandSubjectlnput Lock input

13 CommandSubjectCamera Switch camera off

Redirect incoming

14 CommandSubjectRedirect calls to the following number

15 CommandSubjectOutboundC Disable outbound

Command data

[0240] The commandData field is an array of bytes representing all the subjects. Every byte represent one subject. If command subject requires injecting string (for example, documents may require list like *.txt,*.xls ) then the string (in Unicode encoding, low-byte-first) is placed in array exactly after this CommandSubject postfixed with CommandSubjectAuxiliary byte. The length of the string data is determined by its zero terminator (also should be stored in list).

[0241 j So for acting on *.txt,*.xls files stream should look like, in hex form, as shown in table 30.

[0242]

Table 30

[0243]

[0244] Examples

[0245]

Table 31

[0246] Reference numerals to the drawings

Table 32

1 One or more mobile devices

2 A first node

3 A computer

10 Mobile device manager client 10 also referred to as the mobile device client 10

11 GPS-module (GPS API)

12 Mobile device web browser. Can be used for downloading the mobile device manager client 10

13 Internet Server

14 Service client

15 Database

16 Storage means

17 Clients 17 which are downloadable to mobile devices, i.e. the mobile device manager clients 10.

[0247] IMEI The International Mobile Equipment Identity or IMEI is a number unique to every GSM and WCDMA and iDEN mobile phone, as well as some satellite phones. It is found printed on the inside of a phone. It can also be found by typing *#06# into the keypad of the phone.

Claims

1. System for management of mobile devices at least comprising: a) at least one mobile device (1), at least comprising: i) at least one mobile device manager client (10) configured to access data in the at least one mobile device (1); b) at least one first node connected to the at least one mobile device over a telecom network; where the first node at least comprises: i) at least one database; ii) at least one service client configured to provide management of the content in mobile devices; iii) an Internet server; iv) at least one interface configured for secure connection/communication with web portals, and c) at least one graphical user interface, GUI, installed on a computer, where the GUI is configured to provide secure connection/communication with said at least one first node and the GUI is further configured to display the content of one or more mobile devices.

2. A mobile device manager client configured for content management of a mobile device where the mobile device manager client is embedded in the mobile device and where the mobile device manager client at least comprises: a) means configured to read user specific data stored in the mobile device; b) means configured to write user specific data to a memory of the mobile device; c) means configured to receive user specific data over a secure protocol from a first node; d) means configured to transmit user specific data over a secure protocol to the first node.

3. The mobile device manager client according to claim 2, c h a r a c t e r i s e d i n that the mobile device manager client is configured to read data from a GPS module in the mobile device.

4. The mobile device manager client according to claim 3 , characterised in that the mobile device manager client is downloadable through a web browser in the mobile device.

5. The mobile device manager client according to claim 2-4, characterised in that the user specific data is one or more of: SMS, MMS, Multimedia files such as movies, music, or ringtones, PIM data such as contact details, calendar details, schedules or tasks, documents and GEO data.

6. A node configured for content management of mobile devices connected to at least one mobile device over a telecom network; where the node at least comprises: a) at least one database; b) at least one service client configured to provide management of the content in mobile devices; c) an Internet server; d) at least one interface configured for secure connection/communication with web portals; e) at least one interface configured for communication with mobile devices.

7. The node according to claim 6, characterised in that the node comprises means configured to send formatted SMS calls to at least one SMS gateway.

8. The node according to claim 6 or 7, characterised in that the internet server comprises an interface configured for downloading of software clients to mobile devices.

9. The node according to claim 6-8, characterised in that the node further comprises software clients configured for use on mobile device platforms.

10. The node according to claim 6-9, characterised in that the node further comprises means for storing data.

11. A graphical user interface accessible on a computer (3), where the graphical user interface is configured to provide secure connection/communication with at least one first node and the graphical user interface is further configured to display the content of one or more mobile devices (1) and where the displayed content is hyperlinks linked to stored data in the first node (2), the stored data is the mirror image of the content of the one or more mobile devices (1).

12. A method for login and authentication from a computer (3) for a management and transfer of data system where the system is configured for management and transfer of data between one or more mobile devices (1), and at least a first node (2) at least comprising the steps of: a) sending a request (1.1.1) for a particular graphical user interface, GUI, to an Internet server (13), where the Internet server (13) is associated with the first node (2), from a web client (1.1) on the computer (3); b) at the Internet server (13) responding by sending a login interface

(1.3.1) to the computer (3); c) at the computer (3) enter login data and sending the login data

(1.1.2) over a secure communication path to the Internet server (13); d) at the Internet server (13) sending the login data (1.3.2) to a data base (15) for verification; e) at the database (15) respond by returning a verification (1.5.1) if login data is correct, and f) the Internet server (13) sends (1.3.3) the particular GUI to the computer (3) if the verification test in the previous step were acknowledged.

13. A method according to claim 12, c h a r a c t e r i s e d i n that the GUI is configured to display the content of one or more mobile devices (1) on a display of the computer (3), displaying the content of the one or more mobile devices (1) comprises the steps of: transmitting the content of the one or more mobile devices (1) to the first node (2), at the first node (2) storing the data, entering a request for displaying of the content of one or more mobile devices (1) on the GUI, the request is sent to the first node (2), and at the first node providing the GUI with hyperlinks to the content of the one or more mobile devices stored in the first node (2).

14. A method for management and transfer of data between one or more mobile devices (1) and at least a first node (2) at least comprising the steps of: a) at a computer (3) with a particular GUI (1.1,2.1,3.1,4.1,5.1,6.1,7.1,8.1); saving a job, such as backup, restore, delete, lock, locate; b) transmit said job (1.1.3,2.1.1,3.1.1,4.11,5.1.1,6.1.1,7.1.1,8.1.1) over a secure communication line to the Internet server (13), where the Internet server is an element of the first node; c) at the Internet server (13) saving the received job (1.3.4,2.4.1,3.3.1,4.3.1,5.3.1,6.3.1,7.3.1) to a data base (15); d) at preset time intervals transmitting query commands (1.2.1,2.2.1,3.2.1,4.2.1,5.2.1,6.2.1,7.2.1,8.2.1) to a service client (14) from the one or more mobile devices (1); e) at the service client (14) responding by sending query commands (1.4.1,2.5.1,3.4.1,4.4.1,5.4.1,6.4.1,7.4.1,8.5.1) to the data base (15) which is checking for one or more saved jobs; f) at the database (15) responding by sending at least one queried job

.1.5.2,2.6.1 ,3.5.1 ,4.5.1 ,5.5.1 ,6.5.1 ,7.5.1 ,8.6.1) to the service client (14), and g) at the service client (14) transmitting the job

(1.4.2.2.5.2.3.4.1.4.4.2.5.4.2.6.4.2.7.4.2.8.5.2) wirelessly to the one or more mobile devices (1).

15. A method according to claim 14, characterised in that the method further comprises the steps of: h) at the one or more mobile devices (1) executing the received job; i) simultaneously or substantially simultaneously initialising a transmitting session by transmitting wirelessly

(1.2.2,2.2.3,3.2.2,4.2.3,5.2.2,8.2.2) status of the data content in the one or more mobile devices (1) to the service client (14); j) at the service client (14) sending (1.4.3,3.4.2,4.4.3,5.4.2,8.5.2) the received update status to the database (15); k) at the end of the session transmitting from the one or more mobile devices (1) to the service client (14) an end of session message; I) at the service client (14) responding by transmitting an acknowledged job message to the one or more mobile devices (1) and simultaneously or substantially simultaneously sending a session completed to the data base (15), and m) the internet server (13) queries (1.5.4,3.5.3,4.5.3,5.5.3,8.6.3) the data base (15) for last updated status at preset time intervals and transmits job status updated message (1.3.5,3.3.2,4.3.2,5.3.2,8.4.2) to the computer (3).

16. A method according to claim 14, characterised in that the method further relates to requesting the location of one or more mobile devices (1) hence the job is a locate task and where the method further comprises the steps of: h) at the one or more mobile devices (1) executing the received job by sending a location query (2.2.2) from a mobile device manager client

(10) embedded in the one or more mobile devices to a GPS-module

(11); i) at the GPS-module (11) receiving the query from the mobile device manager client and returning location coordinates (2.3.1) to the mobile device manager client (10); j) at the mobile device manager client (10) transmitting the location coordinates (2.2.3) to the service client (14); k) at the service client (14) sending the location coordinates (2.5.3) to the internet server (13); I) at the Internet server (13) sending location coordinates (2.4.2) to the computer (3) with a particular GUI, and m) at the computer (3) with the particular GUI utilizing the location coordinates for opening of a map in a web browser (2.9) with location coordinates indicated.

17. A method according to claim 15, characterised in that the method further relates to requesting backup for one or more mobile devices (1) where the method further comprises the additional step following step m of showing the back up transfer status in the particular GUI (3.7) on the computer (3).

18. A method according to claim 15, characterised in that the method further relates to restoring data for one or more mobile devices (1) in the data base (15) where the method further comprises the additional step following step m of showing the restore transfer status in the particular GUI (4.7) on the computer (3).

19. A method according to claim 15, characterised in that the method further relates to deleting data in one or more mobile devices (1) where the method further comprises the additional step following step m of showing the deletion status in the particular GUI (5.7) on the computer (3).

20. A method according to claim 14, characterised in that the method further relates to setting of parameter data in one or more mobile devices (1) where the method in step g comprises at the service client (14) to transmit settings (6.4.2) wirelessly to the one or more mobile devices (1).

21. A method according to claim 14, characterised in that the method further relates to sending messages from a computer (3) to one or more mobile devices (1) where the method in step g comprises at the service client (14) to transmit one or more messages (7.4.2) wirelessly to the one or more mobile devices (1).

22. A method according to claim 14, characterised in that the method further relates to sending SMS messages from a computer (3) to one or more mobile devices (1) where the method in step c comprises at the Internet server (13) to transmit a formatted SMS call (8.4.1) to a SMS gateway (8.3), and at the SMS gateway (8.3) to send a formatted SMS message (8.3.1) to the mobile device manager client (10), and then continue with step d-g.

23. A method according to any of the claims 14-22, characterised in that data transmitted between the first node (2) and the one or more mobile devices (1) are binary coded data.

24. A method according to claim 14, characterised in that the GUI is configured to display the content of one or more mobile devices (1) on a display of the computer (3), displaying the content of the one or more mobile devices (1) comprises the steps of: transmitting the content of the one or more mobile devices (1) to the first node (2), at the first node (2) storing the data, entering a request for displaying of the content of one or more mobile devices (1) on the GUI, the request is sent to the first node (2), and at the first node providing the GUI with hyperlinks to the content of the one or more mobile devices stored in the first node (2).

25. A method for login and authentication from a mobile device (1) to a first node (2) in a system for management and transfer of data where the system is configured for management and transfer of data between the one or more mobile devices (1), and at least the first node (2) at least comprising the steps of: a) the first node (2) executes a test to reveal whether one or more identification packets have been received or not, if they have been received continue with step g; b) the first node (2) executes a "LoginPacket received test" (720), to check if the mobile device (1) already has sent login data to the first node (2) if no continue at step c 721 , if yes continue at step d 722, c) the first node (2) rejects (721) the mobile device (1) from connecting to the first node (2), d) the first node (2) executes a test (722) were it inquire the mobile device (1) if it is waiting for login, if the mobile device (1) is still waiting for login then continue at step e, otherwise reject (721) the mobile device (1) from connecting to the first node (2), e) a test for correctness (723) of the login key is executed, if the login keys are wrong then the mobile device (1) is rejected (721) from connecting to the first node (2), if the login key is correct then continue at step f, f) the mobile device (1) sends (724) an identification packet to the first node (2) and the next step is a) g) the first node (2) executes a test (730) to verify if the mobile device (1) has been registered or not (730) if the mobile device has been registered then continue with step k, otherwise execute step h, h) the first node (2) checks (731) if the first device (1) waits for registration, if it does not then the following step will be step i, otherwise the following step will be step j PatXML /T^ 118981/HT

i) the mobile device (1) is rejected (732) connection to the first node

(2), j) the mobile device (1) sends its registration data to the first node (2), the first node (2) registers the mobile device (1) and install (733) the mobile device (1) in a storing means (15), k) the login and authentication is complete (734).

26. A method according to claim 25, characterised in that the first step a includes to check if the received identification packet is an IMEI packet.

PatXML ff<\_ 118981/HT

Abstract