Patent Application
20080288578
The present invention relates generally to communication systems. In particular the invention concerns multiple terminal devices used by a single entity, e.g. a person, and a method and a corresponding device for enabling flexible data sharing between such terminal devices.
Modern wireless communication systems such as GSM (Global System for mobile communications) and UMTS (Universal Mobile Telecommunications System) are capable of transferring various types of data over the air interface between the network elements such as a base station and a mobile terminal. As the general demand for transfer capacity continuously rises thanks to e.g. new multimedia services coming available, new more efficient techniques have been developed in order to exploit the existing resources to a maximum extent.
A problem still not addressed by the emerging new technologies relates to a scenario in which a single entity, e.g. a person or a company/club, owns a plurality of devices for different reasons and/or uses. For example, some of the devices may be light and small in size like many of the modern mobile terminals tend to be, and thus they fit into pocket nicely while on the move, but the rest of the devices may be large and relatively heavy, like multimedia terminals with bigger screen without forgetting desktop computers, however offering some benefits not available in their smaller counterparts, what comes to e.g. screen resolution and overall usability thereof. Unfortunately contemporary terminal devices do not effectively support data synchronization and sharing in case of a common user/owner having multiple devices. Current devices have been optimised for standalone use.
Publication EP 1102191 discloses a method and an apparatus for reconciling data within a plurality of devices via a central server. With reference to
With several devices in possession, an optimal data location and/or related synchronization method depend on the application. For example, in a calendar application the same data should be directly available in all necessary devices. Thereupon an optimal solution would require either automatic or at least semi-automatic synchronization of the calendar data. In other applications, considering e.g. picture/video viewers or audio players, the amount of associated data may be so huge that automatic data synchronization between multiple devices is neither cost-efficient nor sensible as to transmission capabilities such as maximum reachable data transfer speed and available storage space. Therefore, the user may be willing to explicitly select the data to be synchronized between the devices.
Existing low-range connections like infrared and Bluetooth surely work in some occasions but definitely not in all of them: the users may not consent to carry several devices with them all the time, and thus the required range unavoidably expands too wide soon. Moreover, considering especially modern mobile terminals the user may have several devices but only one SIM card, thus real-time data synchronization by simply sending messages from a device to another is then not possible.
In addition, if the devices the data of which is to be kept in synchronization do not bear fully compatible attributes, e.g. processing, memory, data visualization or audio reproduction means, a straightforward data middle-storaging and forwarding solution is not sufficient as one device, e.g. a mobile terminal, cannot possibly utilize or maybe even receive/store information provided by another device, e.g. a more sophisticated multimedia terminal or a laptop/desktop computer equipped with more cultivated features.
The object of the present invention is to alleviate the defects found in prior art solutions by utilizing a concept of a virtual device service offering a number of virtual devices for flexible data synchronization. As to the utility of the invention, data can thus be copied between the actual physical devices via the corresponding virtual devices even if they utilize a common SIM card, are not active/logged into network at the same time, or the distance between them is too big in order to exploit direct low-range transmission techniques like Bluetooth or infrared. Moreover, the devices may not share common properties but data synchronization, however, being still possible due to the data conversion/filtering techniques offered by the virtual device service domain. As one more additional benefit, if a physical device is lost or broken, for example, the corresponding virtual device can work as an automatic data backup or additional storage medium.
Information that is transferred to a virtual device (and from which to another virtual device for delivery to the corresponding another physical device) can be determined either manually, via e.g. the user interface of the physical device on case-by-case (file etc) basis, or automatically including also semi-automatic procedures. Predefined and advantageously user adjustable settings stored in a physical device may indicate that all files or data with a certain type upon change or creation/deletion thereof should always be updated also in one or more other devices belonging to the virtual device domain.
Respectively, information about the target devices to which the information should be finally transferred for synchronization via virtual devices can be stored in the source physical device or in a virtual version thereof. On the other hand, each virtual device may poll both the corresponding physical device, e.g. on a timed manner to retrieve updated data, and the other virtual devices for checking whether some data to be kept in synchronization between them (and thus also between the actual physical devices) has been changed lately. The data transfer from a virtual device to a target physical device may occur in a timed manner, upon receiving a synchronization request from the target device, or straight after the target device has registered in the network/service etc. Naturally the data update/synchronization procedure may be made conditional by first informing the target device about updated data and then waiting for its acceptance for actual update data transfer. Moreover, virtual service may maintain a centralized database of various data objects located in existing virtual devices and of preferred synchronization mappings and linkage in addition to pure decentralized solution in which only the virtual devices either carry such mappings or perhaps just by polling type arrangements update the data between them whenever necessary.
Sketching out a scenario wherein data is transmitted from the target virtual device to the target physical device in a delayed manner (as timed or upon occurrence of some predetermined event), even only a single SIM card can serve the basis for successful data transfer addressing, and, for example, manual copying of phone book information between two mobile terminals, which is a very common but annoying procedure among multiple terminal owners with only a single SIM card, can be omitted as the user may send the phone book or other preferred data to itself via the virtual device service and, before the timer to expire or the predetermined event to occur, change the SIM card from the one terminal to another and wait for the automatic, e.g. push like, or manually initiated update from the virtual device. Thus the two device memories are relatively easily kept in synchronization even with only a single SIM card that is used for virtual-physical device interface addressing as well. Of course, in a more general scenario in which multiple devices are used one at a time with the same SIM card, some other addressing means (like mobile terminal IMEI code, IP address) can be utilized for the virtual device service addressing purposes, and e.g. aforesaid timer based solution is not necessary as the phone book update may occur upon the registration of the target device to network, whereby the target device still utilizes the same SIM card as the source device but different addressing means for virtual device service purposes.
In particular, explicitly (˜manually) initiated data transfer between physical devices can be made easier due to the adoption of the virtual device service concept presented herein. A specific “My Devices” or corresponding menu can be created and tailored in a terminal device to be presented on the U′, e.g. a display, thereof upon activation of such functionality. Different devices may be listed on the display as sorted according to preferred criteria, e.g. a freely user-definable and thus readable/easy-to-understand name given to each physical device having a virtual counterpart on the virtual device domain. Of course, such user-defined name shall be linked to true device-addressing means used by the network at least on the virtual device service side. In many cases fully automated solutions, that are based e.g. data type analysis, are not feasible, considering, for example, transferring of all downloaded multimedia files between devices for synchronization purposes, as if automated such transfer would occupy a lot of transfer capacity of the system and perhaps introduce unwanted costs to the user. Probable as it is that a relatively high percentage of multimedia files downloaded to a device is exploited only once, and thus, the rest of the devices do not need to be updated at all in relation to such files.
In one aspect of the invention a method for managing a virtual device service at a service entity supporting information transfer between a plurality of devices enabled to communicate with the service entity, is characterized in that it has the steps of
Optionally, said information transmitted to the second device may be made compatible with the capabilities of the second device by exploiting various data pruning/conversion techniques.
In another aspect of the invention a method for transferring information from a first device to at least one other device via a virtual device service is characterized in that it has the steps of
Said specifying of the second device can be executed on the basis of providing the user of the device with a list of the members of said group by e.g. visualizing them on the UI with available identifiers, and then, by user selection specifying the current target device. Alternatively the specifying may be made automatically on the basis of predefined settings for occasions in which a file/data of certain type changes including creation/deletion of such data.
Same methodology applies to determining the information to be sent, i.e. both the manual and automatic techniques can be used.
In a further aspect of the invention, a device operable in a communications network, comprising processing means and memory means for processing instructions and storing data, is characterized in that it is configured to determine the information to be sent to a second device, to specify the second device from a group of one or more devices, and to send the information to a virtual service entity to be stored in a first location associated with the first device and to be further forwarded to the second device via a second location associated with the second device upon occurrence of a predetermined event.
In a further aspect of the invention, a virtual device service entity comprising processing means and memory means for processing instructions and storing data, and data transfer means for transferring data, is characterized in that it is configured to receive information from a first device, said information targeted to at least a second device, to store the information in a first location associated with the first device, to store said information stored in the first location associated with the first device in a second location associated with the second device, and upon occurrence of a predetermined event to transmit the information in the second location to the second device.
Still in a further aspect of the invention, a system comprising a virtual device service entity and at least a first and a second device capable of communicating with said virtual device service entity, is characterized in that
The concept is further described with reference to
Hereinafter the invention is described in more detail by reference to the attached drawings, wherein
Reverting to
As the virtual device domain contains virtual devices that should, at least partly, be kept synchronized in relation to the changes in data stored in actual physical devices, the virtual device service entity shall create a corresponding virtual domain in which the virtual devices of e.g. certain person or other entity reside. In its simplest form, the domain could just be a list in the memory of the service entity about devices (˜device identifiers) belonging to it. The virtual device domain may be set-up in method start-up phase 302 based on the information provided to the service entity by, for example, a separate virtual device domain set-up request message from a terminal or by directly programming the service entity on the spot, for example. Such message can include separate fields or more complex code words determining a preferred virtual device service configuration, i.e. what devices should be included in a domain and to what extent (data types, data entities etc) they should be kept in synchronization. After creation of a virtual counterpart the terminal may be configured to automatically log in to the virtual device (service) domain e.g. upon registration to the network, and then automatically or as a response to a user request or at least after acceptance by him update data between the virtual and physical devices. Alternatively the terminal may register to the virtual device domain only after initiative taken by the user via the UI of his terminal, for example.
The required mappings/linkage between devices and data thereof may be held in a centralized database, in which case a central entity controlling the domain at the service side can take care of all data exchange between virtual devices and thus the virtual devices just act as physical device related data storages or merely deal with the data transfer from/to the physical counterparts. Alternatively, the virtual devices may perform all the data exchange within virtual device service and utilize the centralized database for acquiring mapping information. In a third solution model mapping information is truly scattered in the virtual devices that act independently or in control of a central entity.
For example, a table may include device identifiers followed by each data element/type stored in a virtual device with optional mappings to data elements/types in other virtual devices. The mappings including direct links between already compatible elements and more complex links requiring e.g. data conversion/adaptation stage may be user-defined and dynamically deliverable/alterable with a settings message, for example, or they can be produced automatically meaning the corresponding data elements in different devices have a common or “standard” meaning, and thus a mapping/link between them may be established without further guidance by the user. Naturally also data elements that are not “pre-mapped” between virtual devices shall be possible to be exchanged, and therefore, virtual devices should include free memory-space (or an option to dynamically reserve more memory) for data elements without direct pre-defined counterpart in the target virtual device. Such data elements without mappings are probable due to explicit data exchange, i.e. the user has manually sent a data element and specified a certain target device belonging to the virtual domain so that the data can be properly forwarded in the virtual domain without any predefined mapping information.
Moreover, during set-up and preferably also dynamically later, the user may be provided with the possibility to generate groupings that are more generic than direct data element mappings between virtual devices and thus faster/easier to create/delete. One group may be established for e.g. work related terminals and another for devices intended for private use. Group definitions shall be stored at least in the service side as to the automated data exchange, and in both the physical terminal and service side as to explicit data transfer. Groups may be defined or handled solely in a physical terminal device side only if the device upon sending such group targeted data converts the target address identifier (which can be a group identifier) to corresponding independent device identifiers. Identifiers to be used for device addressing within the virtual service can be based on e.g. SIM information, IMEI (International Mobile station Equipment Identity) code, specific user name/password combinations given upon device registration to the service etc whatever addressing means seen suitable for the purpose.
In step 304 the information to be sent is determined either automatically by the sending device on the basis of predefined criteria, in which case an optional authorization may be asked from the user even on single data element basis, or manually by the user feedback (through selection or by typing in) via e.g. a service related menu shown on the UI of the device. In another, more virtual device service entity driven, option the service entity polls the devices belonging to the same virtual device domain e.g. in a periodical manner to check if a data element to be synchronized according to the mappings/linkage has changed in order to then retrieve and forward such data.
Step 306 includes specifying the recipient(s) for the information. Respectively in this stage, the performed actions may be automatic and be based on the available existing mappings/linkage information between data elements/types stored in the terminal device/service entity, or manual through user feedback, i.e. the user selects the receiving device(s) from a group of devices associated with the virtual device service. If the specifying is executed at the service entity, step 306 may be executed actually following data transfer step 308. It should be noted that especially in case of explicit, manually initiated data transfer also steps 306 and 304 might be executed in reversed order without any difficulty.
In step 308 the determined information is sent towards the virtual device service by the source device. Information transfer may be wire based or wireless depending on the way the source device is connected to the service. For example, mobile terminals are likely to be connected to services through a wireless connection whereas a desktop computer is fixedly connected to the network via e.g. a standard twisted pair network cable.
In step 310 the virtual device service entity receives the information either directly from the source device or via a number of intermediary devices, and in step 312 stores it in a first location associated with the source device, e.g. to an identifier thereof, sending the data. Such location can be seen to form a part of a virtual device corresponding to the actual physical device as to the data stored in the devices.
In step 314, which is in principle optional, the virtual device service entity checks whether the information should be altered somehow to better fit the capability of target devices that have been defined in step 306. If that's the case, different data adaptation methods including image/text/sound conversions can be performed 316 before placing the data in the target virtual device(s) to be forwarded to the target physical devices. Such adaptation measures may include also e.g. complete deletion of certain data (or substitution with alternative data, e.g. a picture replaced with text “[picture removed]”) if the target device does not support receiving data of that nature. In case of a plurality of target virtual devices such adaptation methods may differ depending on the target device and thus, the same source data may be delivered to many target devices in a different form to each of them.
In step 318 the possibly adapted data is stored in at least one another location, the location(s) in practise corresponding to the target virtual device(s). The data also remains in the first location unless the user has through configuring set the system to only transfer the data and not to act as data storage. In that case after transferring the data to the at least one another location the data may be deleted. Steps 316 and 318 may be executed in reversed order, i.e. adaptation happens at the target virtual device not until the target virtual device has noticed e.g. through data type analysis that the corresponding physical device does not support the data without adaptation.
Step 320 refers to monitoring/waiting for a predetermined event to occur that shall then launch the transmission of the data to the target physical device from the target virtual device thereof. Such events may be either fixed on determined dynamically at the service entity or by the terminal having a virtual counterpart. The physical device may inform the service entity about new event settings with a dedicated message or by embedding the settings information to some other message as a parameter, for example. The event may be a registration to the network or to the virtual device service, said registration recognized by the service. Likewise the event can be an expiration of a timer (note that any timed data update procedure can be seen as that), reception of an explicit update request or data query from the physical device etc. It's clear that such events can be independently determined for each virtual device or alternatively, to a certain group of virtual devices.
Finally the data is delivered to the target physical device(s) in step 322. The service entity may then delete the data stored in the virtual domain if the service was merely used for transferring data or leave it to reside in the virtual device as well if also e.g. data back-up services are needed for. The method execution is ended in step 324.
Respectively, a block diagram of user equipment such as a mobile terminal, a PDA, or a desktop/laptop computer capable of utilizing the virtual device service is depicted in
Correspondingly, a similar type of virtual device visualization and selection means can be applied to various different purposes than just explicit data transfer without difficulty. Such purposes include e.g. device status inquiries and device grouping, i.e. whatever purpose with a device selection aspect.
The protocols and protocol stacks utilized in information transfer according to the invention can be selected from the existing ones as the transfer capabilities required for implementing the invention are not particularly complex or special as such, which can be seen as one benefit of the invention. The information exchange between the virtual devices and other entities like the physical devices, which can also be deemed as proxies, may be implemented using a data sharing technology e.g. SyncML data synchronization protocol, or even traditional FTP (File Transfer Protocol).
It should be obvious to a one skilled in the art that different modifications can be made to the present invention disclosed herein without diverging from the scope of the invention defined by the claims. For example, utilized devices and methods steps may vary still converging to the basic idea of the invention. As one observation, from the physical (terminal) device's standpoint the virtual device service can be implemented as an aggregate entity the internal functions and components of which are not visible. Thus, on the virtual domain the existence of an virtual device corresponding to some physical target device is essential, and how the data is delivered thereto, i.e. happens it through the described virtual source device or some other entity, is not always necessary to fix to any certain solution although data transmittal through the virtual source device associated with the physical device transmitting the data is somewhat advantageous as the virtual device serves as a data back-up device at the same time.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/FI2004/000199 | 4/1/2004 | WO | 00 | 7/28/2008 |
