WO2010131980A1 - Systèmes, procédés et dispositifs de gestion d'une pluralité de dispositifs mobiles - Google Patents

Systèmes, procédés et dispositifs de gestion d'une pluralité de dispositifs mobiles Download PDF

Info

Publication number
WO2010131980A1
WO2010131980A1 PCT/NO2010/000177 NO2010000177W WO2010131980A1 WO 2010131980 A1 WO2010131980 A1 WO 2010131980A1 NO 2010000177 W NO2010000177 W NO 2010000177W WO 2010131980 A1 WO2010131980 A1 WO 2010131980A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
mobile device
data
mobile devices
client
Prior art date
Application number
PCT/NO2010/000177
Other languages
English (en)
Inventor
Mads Olsen
Freddy Alex Eriksen
Oleg Belous
Original Assignee
Lapback As
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lapback As filed Critical Lapback As
Publication of WO2010131980A1 publication Critical patent/WO2010131980A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/66—Substation equipment, e.g. for use by subscribers with means for preventing unauthorised or fraudulent calling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72448—User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions
    • H04M1/72457—User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions according to geographic location
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/082—Access security using revocation of authorisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/37—Managing security policies for mobile devices or for controlling mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2250/00—Details of telephonic subscriber devices
    • H04M2250/10—Details of telephonic subscriber devices including a GPS signal receiver
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H04W4/185—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals by embedding added-value information into content, e.g. geo-tagging

Definitions

  • 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.
  • the object of the invention is met by a system, methods and devices configured for management of mobile devices.
  • 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.
  • 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.
  • a mobile device manager client configured for content management of a mobile device
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • fig. 1 is a block diagram showing a framework for management of mobile devices according to one embodiment of the present invention
  • fig. 2 is an example of a high level architecture according to one embodiment of the present invention
  • fig. 3 is a block diagram showing another example of the architecture according to one embodiment of the present invention
  • fig. 4 is a more detailed block diagram showing another example of the architecture according to one embodiment of the present invention
  • FIG. 5 shows to flowcharts for execution of methods for management of data in mobile devices according to one embodiment of the present invention
  • fig 6 shows a typical handshake process between a mobile device and a first node
  • fig. 7 shows a flowchart for execution of authentication algorithms on a mobile device
  • fig 8 shows a login and authentication process and steps for performing general tasks
  • fig. 9 shows steps for performing get location tasks initiated from a computer
  • fig. 10 shows handshaking between mobile device and a first node for location services
  • fig, 11 shows the steps for performing backup of mobile devices initiated from a computer
  • fig. 12 shows handshaking between mobile device and a first node for back up of mobile device
  • fig. 13 shows the steps for performing restore of data on mobile devices
  • fig 14 shows handshaking between mobile device and a first node for restoring data in mobile device
  • fig. 15 shows the steps for performing delete data on mobile devices
  • fig 16 shows handshaking protocol between mobile device and a first node for delete data in mobile device
  • fig 17 shows the steps for performing setting of parameter data on mobile devices initiated fro a computer
  • fig 18 shows the steps for sending messages from a computer to mobile devices initiated by a computer
  • fig 19 shows the steps for sending command messages from a computer to mobile devices.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the MobileWipe service corresponds to the at least one service client 14 discussed above.
  • 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.
  • 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.
  • FTP File Transfer Protocol
  • FTPS also known as FTP Secure and FTP-SSL
  • SMTP Simple Mail Transfer Protocol
  • NNTP Network News Transfer Protocol
  • HTTP/HTTPS Hypertext Transfer Protocol/Hypertext Transfer Protocol Secure
  • the ASP Active Server Pages
  • Classic ASP or ASP Classic is a server-side script engine for dynamically-generated web pages.
  • 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.
  • 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.
  • 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.
  • 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.
  • OS - Windows 2005 server is a server operating system produced by
  • FIG. 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.
  • 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.
  • "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.
  • FIG 3 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.
  • 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.
  • FIG 4 is a block diagram which in a more detailed way describes the elements constituting the system according to the present invention.
  • 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.
  • FIG. 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.
  • 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
  • the mobile device client 10 sends an IMEI Packet to the first node 2
  • 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.
  • 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.
  • AckPacket acknowledge
  • IMEIPacket IMEIPacket
  • 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.
  • the connection is considered to be established.
  • Client 10 sends IsNewConfigurationAvailablePacket to the first node 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.
  • Client 10 should receive MessagePacket and display its contents before proceeding that is if it's not empty.
  • Client 10 sends IsNewCommandAvailablePacket to the first node 2 according to one aspect of the present invention.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the end user will respond by entering login data on his computer 3 to the received login interface.
  • 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.
  • 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.
  • the database can be of any suitable type, and the database may comprise a number of databases.
  • 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).
  • 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.
  • 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.
  • FIG. 7 a flow chart indicates an example of steps necessary for authentication of a mobile device 1.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 3 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.
  • 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.
  • 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.
  • 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.
  • the first node 2 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.
  • 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.
  • 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.
  • FIG 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the database 15 will respond by sending at least one queried job 1.5.2 to the service client 14.
  • the service client 14 will then transmit the job 1.4.2 preferably wirelessly to the one or more mobile devices 1.
  • the one or more mobile devices 1 will then execute the received job.
  • a transmitting session will be initialised at the mobile device 1.
  • 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.
  • 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".
  • the one or more mobile devices 1 will transmit at least one end of session message to 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.
  • 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.
  • 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.
  • 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.
  • the Internet server 13 will forward 2.4.2 the received location coordinates to the computer 3.
  • 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.
  • 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.
  • 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).
  • GPS support requires that the first node 2 has the capability to send SMS.
  • the service client 14 sends SMS message containing 'locate' command to one or more mobile devices 1.
  • 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.
  • 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.
  • the mobile device client 10 periodically sends ProgresslncrementPacket with dwType set to CommandSubjectLocate this will typically be sent every 3-5 seconds.
  • 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.
  • FIG. 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.
  • 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
  • PackageChunkDataPacket representing item's or file's data, it is recommended to transfer them as compressed packets.
  • the mobile device client 10 sends empty PackageltemEnd packet.
  • 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.
  • the mobile device client 10 sends ProgressEnd Packet indicating that all items are backed up.
  • FIG. 13 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.
  • 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.
  • FIG 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.
  • 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.
  • 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.
  • 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)
  • 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.
  • Restoration of files backed up from storage cards may be performed in the following way:
  • file 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.
  • FIG 15 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.
  • 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.
  • the mobile devices sends a "ProgressEndPacket" to the first node 2.
  • 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.
  • the delete procedure comprises the following steps:
  • 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.
  • a set interval e.g. every 5 minutes.
  • the mobile device client 10 updates progress info on the service client 14 of the first node 2.
  • the mobile device client 10 sends total number of items or total size for the files in the ProgressTotalPacket.
  • the mobile device client 10 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.
  • 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.
  • the lock procedure comprises the following steps:
  • 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.
  • a set interval e.g. every 5 minutes.
  • 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.
  • FIG 17 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.
  • FIG 18 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.
  • 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.
  • 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.
  • 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.
  • the database 15 will respond by sending at least one queried job 8.6.1 to the service client 14.
  • the service client 14 will then transmit the job 8.5.2 preferably wirelessly to the one or more mobile devices 1.
  • the one or more mobile devices 1 will then execute the received job.
  • a transmitting session will be initialised at the mobile device 1.
  • 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.
  • 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".
  • the one or more mobile devices 1 will transmit at least one end of session message to 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.
  • 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
  • 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.
  • 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]
  • len field is represented as the structure indicated in the table 3.
  • Installation data packet 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.
  • Advanced data about the mobile device client 10 configuration is optional and may contain information about flash cards.
  • Format of the flash card data entry is indicated in table 5 (in PR_FlashCard objects).
  • 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.
  • Keywords (APIs, classes, methods, functions):
  • Tint RFs :GetMediaSerialNumber( TMediaSerialNumber &aSerialNum, Tint aDrive );
  • RFs::GetMediaSerialNumber() returns 16 bytes (128 bits) which are a copy of the card's CID register, defined as follows:
  • (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.
  • SMS messaging availability of a the mobile device client 10 to handle incoming SMSes from the service client 14 of the first node 2.
  • Lock period When the mobile device client 10 loses connection and this interval elapses, the mobile device client 10 should lock itself automatically.
  • Wipeout period When the mobile device client 10 loses connection and this interval elapses, the mobile device client 10 should wipe out itself automatically.
  • the backup schedule contains the next information
  • Backup schedule is encoded with double word (32 bits) using the format shown below in table 11 (from higher to lower bits).
  • 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
  • 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
  • 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.
  • 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.
  • This packet does not contain any data.
  • 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.
  • 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.
  • 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'.
  • 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.
  • Meta data should be as small as possible, but no more than 3000 bytes.
  • 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.
  • PackageChunkHeaderPac specified in previous ket.dwDataSize bytes PackageChunkHeaderPack et for
  • the purpose of the "Item end packet" is to end transferring transaction.
  • This packet is intended to transfer geographic coordinates such as latitude and longitude.
  • This packet is intended to acknowledge receiving particular packet and send auxiliary information in response.
  • 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.
  • commandType field from the structure above may equal to values below given in table 28.
  • 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.
  • 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).
  • Mobile device manager client 10 also referred to as the mobile device client 10
  • GPS API GPS-module
  • Mobile device web browser Can be used for downloading the mobile device manager client 10
  • Clients 17 which are downloadable to mobile devices, i.e. the mobile device manager clients 10.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Position Fixing By Use Of Radio Waves (AREA)

Abstract

L'invention porte sur des systèmes, des procédés et des dispositifs de gestion d'une pluralité de dispositifs mobiles de diverses plateformes par l'intermédiaire d'une seule application de gestion. Plus spécifiquement, cette invention porte sur la gestion de données stockées sur des dispositifs mobiles et l'activation de fonctions de géolocalisation utilisant soit une triangulation soit un GPS intégré au dispositif.
PCT/NO2010/000177 2009-05-12 2010-05-12 Systèmes, procédés et dispositifs de gestion d'une pluralité de dispositifs mobiles WO2010131980A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NO20091865 2009-05-12
NO20091865A NO20091865L (no) 2009-05-12 2009-05-12 Systemer, metoder og anordninger for administrasjon av flere mobile enheter

Publications (1)

Publication Number Publication Date
WO2010131980A1 true WO2010131980A1 (fr) 2010-11-18

Family

ID=43085201

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NO2010/000177 WO2010131980A1 (fr) 2009-05-12 2010-05-12 Systèmes, procédés et dispositifs de gestion d'une pluralité de dispositifs mobiles

Country Status (2)

Country Link
NO (1) NO20091865L (fr)
WO (1) WO2010131980A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1659818A1 (fr) * 2004-11-19 2006-05-24 Nec Corporation Protection d'information stockée sur une borne portative perdue ou volée par un dispositif de contrôle qui informe la borne d'une instruction de protection
US20070038680A1 (en) * 2005-08-10 2007-02-15 Qwest Communications International Inc. Management of mobile-device data
US20070035390A1 (en) * 2005-08-10 2007-02-15 Theodosios Thomas Methods, systems, and computer program products for providing context-based, hierarchical security for a mobile device
WO2008086611A1 (fr) * 2007-01-19 2008-07-24 Research In Motion Limited Nettoyage sélectif d'un dispositif à distance
EP2017767A1 (fr) * 2007-04-10 2009-01-21 Hitachi Software Engineering Co., Ltd. Système et procédé de gestion de fichier, et terminal mobile

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1659818A1 (fr) * 2004-11-19 2006-05-24 Nec Corporation Protection d'information stockée sur une borne portative perdue ou volée par un dispositif de contrôle qui informe la borne d'une instruction de protection
US20070038680A1 (en) * 2005-08-10 2007-02-15 Qwest Communications International Inc. Management of mobile-device data
US20070035390A1 (en) * 2005-08-10 2007-02-15 Theodosios Thomas Methods, systems, and computer program products for providing context-based, hierarchical security for a mobile device
WO2008086611A1 (fr) * 2007-01-19 2008-07-24 Research In Motion Limited Nettoyage sélectif d'un dispositif à distance
EP2017767A1 (fr) * 2007-04-10 2009-01-21 Hitachi Software Engineering Co., Ltd. Système et procédé de gestion de fichier, et terminal mobile

Also Published As

Publication number Publication date
NO20091865L (no) 2010-11-15

Similar Documents

Publication Publication Date Title
EP1704746B1 (fr) Gestion et acces a distance a des bases de donnees, a des services et a des dispositifs associes a un terminal mobile
US8554176B2 (en) Method and apparatus for creating a remotely activated secure backup service for mobile handsets
US7584201B2 (en) Management of mobile-device data
US7567541B2 (en) System and method for personal data backup for mobile customer premises equipment
EP1523152B1 (fr) Passerelle de connection
US8213971B2 (en) Apparatus and method for activating computer applications with SMS messaging
US8260353B2 (en) SIM messaging client
US7941128B2 (en) Data backup system
US20070056043A1 (en) Remote cell phone auto destruct
EP2003842B1 (fr) Procédé et dispositifs pour la mise à disposition la sauvegarde de données sécurisées à partir d'un dispositif de communication mobile sur un dispositif informatique externe
US9094370B2 (en) Remote access to information on a mobile terminal from a web browser extension
WO2009055182A1 (fr) Système et procédé de transfert automatique de données d'un dispositif à un autre
US10621201B2 (en) Method and apparatus for storing and retrieving profile data for electronic devices
US20050138211A1 (en) Data synchronization system with data security and proxy capabilities
US20130018980A1 (en) Communication System and Communication Device
WO2010131980A1 (fr) Systèmes, procédés et dispositifs de gestion d'une pluralité de dispositifs mobiles
KR20210141427A (ko) 분실된 휴대 단말에 대한 안심 서비스를 제공하기 위한 방법 및 장치
JP2004318708A (ja) 電子名刺自動交換システムおよび電子名刺自動交換方法
Punja et al. Blackberry Forensics
Lakes Forensic Analysis of Mobile Phones
WO2006015104A2 (fr) Communication assistee par serveur entre clients
JP2008210356A (ja) 電子決済システム及び電子決済方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10775149

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 21/02/2012)

122 Ep: pct application non-entry in european phase

Ref document number: 10775149

Country of ref document: EP

Kind code of ref document: A1