WO2009004398A1

WO2009004398A1 - Method and device for data operation progress indication

Info

Publication number: WO2009004398A1
Application number: PCT/IB2007/001815
Authority: WO
Inventors: Frank Willuns
Original assignee: Nokia Corporation
Priority date: 2007-07-03
Filing date: 2007-07-03
Publication date: 2009-01-08

Abstract

A method is provided, comprising receiving a first action request requesting an action to be performed for at least one data object; determining a measure of data objects to be handled by said action; sending a first response message including said measure of data objects; initiating said requested action; in response to the receiving of each further action request, further determining a measure of progress of said action, and sending at least one further response message including said measure of progress, until said action has been completed, subsequent to completing said requested action, sending a success message.

Description

Method and device for data operation progress indication

Related field

The present invention is related to the field of data exchange protocols, and in particular to the provision of a progress indication for operations.

Background art

Devices, both mobile and stationary, having storage capabilities for various kinds of data are omnipresent. The applications and functionalities of such devices range from communication devices such as mobile phones and devices with email function, information and organization devices such as personal digital assistants and laptops, media devices such as music and video players, up to industrial control devices, electronic equipment in automobiles or medical equipment, and many more. Data may be stored on permanent and/or volatile memory elements, for example on hard disks, internal or external flash memory elements, optical discs, or any other suitable storage medium. In many situations, data exchange between two or more devices may be desired. Data may be transferred from one device to another one via any available communication interfaces present on both devices. These interfaces may include wired or wireless communication interfaces, short range connections, such as Bluetooth, WLAN, infrared, and others.

A common protocol for data exchange, in particular for connections based on infrared interfaces or Bluetooth radio connections, is the OBEX (Object Exchange) protocol. OBEX utilizes an object-based approach, i.e. data is considered in the form of data objects. A data object may for example be a text file, an address record, a digital picture or a music file.

Objects may be transmitted in push-pull procedures where an object is transferred from one device on request from another device (pull) or without any previous request (push). OBEX also allows a remote client to perform local operations on the server. The client may create physical copies of data objects or move or rename these in the server file system across system drive borders. Also, sessions may be established between devices with a connection even when idle. In general, a client to server concept applies for the communication according to this protocol. Each operation is initiated by a client and completed by a server. Objects are included into object models in order to be processed by other devices. Headers are used to transport information on the objects, similar to an http header.

When in an exemplary situation an object is required by a first device (the client) from a second device (the server for this communication), the client device may issue a request for a certain object. The request message may for example include a command indication and several headers. In the headers, any necessary information may be given, such as a name for identifying the requested object, e.g. a file name. In response, the server will transmit the requested object to the client. Again, parameters and headers as desirable may be included in a message together with the object. This procedure corresponds to a pull object transfer.

Another example operation is an action operation, which is again initiated by a corresponding message transmitted. Headers within the transmitted message may indicate for example the action to be performed, a destination, permissions for performing certain actions, and further parameters. Actions to be performed may include (re)moving, copying, renaming or setting permissions for an object at the server device. When a client has requested e.g. the moving or copying of an object, the server will be busy for some time while executing the action. Since the related object data is not actually exchanged with the client in these action operations, the necessary period of time for a certain action is usually not known to the client, and it may thus try to request another operation while the server is still busy with the requested action. This may in particular apply for actions performed on large data objects, such as a large image file or other objects of considerable size or in a case where many objects are addressed with the same action. That is, the server will not be able to respond to the request properly, but at the same time the client does not have information on this "busy" state or on the progress of the action at the server side.

It shall be noted that the exact nature of the data transmitted, e.g. packet size, coding, and similar issues are not limited by the OBEX protocol or this invention. OBEX and similar protocols may be provided as device independent and transport independent session protocols. The person skilled in the art will be familiar with further aspects and details of the OBEX protocol, as well as other protocols for data exchange and their respective characteristics. Details of OBEX may e.g. be taken from the protocol specification, "Object Exchange Protocol", Infrared Data Association (IrDA), version 1.3 of January 2003, in combination with the "Approved Errata for April 2003".

Summary

Thus, a method is given for providing a progress indication to a client when a server is busy with a local action operation. According to a first exemplary aspect the method may comprise receiving a first action request requesting an action to be performed for at least one data object; determining a measure of data objects to be handled by said action; sending a first response message including said measure of data objects; initiating said requested action; in response to the receiving of each further action request, further determining a measure of action progress, and sending at least one further response message including said measure of action progress, until said action has been completed; subsequent to completing said requested action, sending a success message. The measure of action progress may for example be a measure of remaining data objects to be handled, or a measure of data objects already handled. As long as a device (e.g. the server) is busy with an action, it may keep sending continue response messages that allow extracting information about the action progress. These response messages may be send in response to further action requests from a client, or in alternative embodiments also without client requests.

In some embodiments, the measure of data objects or remaining data objects (alternatively the measure of handled data objects) may be included in a header of said response message. AU response messages sent may in exemplary embodiments include said same header; in some cases, also the success message includes said same header indicating a predefined value. For example, when a length or count header has been indicated in all continue response messages, this header may be included into the success message with a header value of zero. In other cases, the success message does not contain any information besides an identifying code.

According to some embodiments, the determining of a measure may include determining the number of data objects to be handled for a first action response message, or of remaining data objects to be handled for any further response message. If desired, said number of data objects or number of remaining data objects may each be included in a count header of said response message. In alternative embodiments, the determining may include determining the number of data objects to be handled for a first action response and a number of data objects that have already been handled for any further response message.

In further embodiments, the determining may include determining a numerical quantity of data units contained within said at least one data object, and in response to the receiving of each further action request, determining a remaining numerical quantity of data units to be handled by said action or a numerical quantity of data units that have already been handled. Again, if desired, said numerical quantity of data units (e.g. a number of bits or bytes, or other suitable units) may be included in a length header of each of said response messages.

Furthermore, the method may comprise determining the measure of remaining data objects by decreasing the determined measure of data objects in accordance with the data objects already handled.

In some embodiments of an inventive method, the header included is a user defined header or an application parameter header.

According to exemplary implementations, the requested action may be the copying or moving of a data object.

The above exemplary method steps may e.g. be performed in a server device in an OBEX conform communication. According to another exemplary aspect of the invention, a method is provided comprising: transmitting an action request for at least one data object; receiving a response message; determining whether said response message is a continue message or a success message; if said response message is a continue message, transmitting a further action request; repeating said determining and transmitting of further action requests until it is determined that said response message is a success message. In some embodiments, this/these further action request(s) is an empty action request.

The method may in some embodiments further comprise extracting a measure indicating an action progress from said continue message. For example, the measure or indication may be extracted from a predefined header of said message. In some cases, the relevant header may be recognized by the client since it is transmitted in all continue messages.

According to some embodiments, the method may comprise displaying a visual progress indication based on said extracted measure. Also, the method may for example comprise checking whether two continue messages received include the same header, usually a header of a kind that transports a numerical value.

In exemplary embodiments, the determining whether the message is a continue message or a success message may comprise reading a predefined indicator byte of said message. In other embodiments, more than one byte or e.g. another parameter including a numerical value or text string may be used for indicating the message type.

The above exemplary method steps may for example be performed in a client device in an OBEX conform communication. Transmissions and communications may for example be effected via an infrared connection, or a Bluetooth connection.

Also, a computer program product is proposed according to the invention comprising program code portions stored in a computer readable medium, the program code portions being adapted to perform method steps according to any of the above passages when the program is run on a computer or processor.

Furthermore, a device is proposed comprising in exemplary embodiments means for receiving a first action request requesting an action to be performed for at least one data object (e.g. a communication interface, such as Bluetooth transceivers or an infrared communication interface); means for determining a measure of data objects to be handled by said action (this may e.g. be a processor or microcontroller, in some embodiments with access to a file system or database, and software code may be stored in a device for performing this determination via a processor); means for sending a first response message including said measure of data objects; means for initiating said requested action; means for further determining a measure of action progress, and sending at least one further response message including said current measure of action progress, until said action has been completed, in response to the receiving of each further action request; and means for sending a success message subsequent to completing said requested action. Such a device may for example be a server device in an OBEX communication, such as a mobile device, personal computer, industrial measuring device, personal digital assistant or any other device supporting a data exchange protocol.

Also, a device is proposed which may comprise means for transmitting an action request for at least one data object; means for receiving a response message; means for detemώving whether said response message is a continue message or a success message, means for transmitting a further action request if said response message is a continue message; means for repeating said determining and transmitting of further action requests until it is determined that said response message is a success message. Again, such a device may be any mobile or stationary device that supports a data exchange protocol such as OBEX, using an arbitrary communication interface, e.g. bluetooth or infrared communication.

Brief description of figures

In the following, the invention will be described in more detail by way of exemplary embodiments and with reference to the appended figures, in which Fig. 1 is a schematic illustration of a system according to exemplary embodiments, Fig. 2 shows exemplary protocol schemes for an action request with progress indication to the client, and Fig. 3 is a flow diagram describing exemplary method steps according to the invention.

Detailed description of exemplary embodiments

In Fig. 1, a proposed system with a client 1 and server 2 according to an inventive embodiment is illustrated. Communication between these devices may for example be achieved via a short range wireless transmission technology by respective transmission interfaces 6 and 7, such as Bluetooth or infrared transmission. For example, both devices may include infrared transceivers or radio communication units for Bluetooth communication, including various subunits. Details of such transmissions, including device structure, used protocols, or signal processing, are known to the person skilled in the art. One or both of the devices may include memory elements 8 of any kind with data that may be stored, processed, and/or transmitted to other devices. Also, software code for executing various functions, including functionalities related to this invention in some embodiments, may be stored on memory elements of these devices. Some or all features of the devices 1, 2 may be stored by a processing unit 4, 5 such as a CPU or a microcontroller. For data exchange via the provided communication link 10, the OBEX protocol may be followed as an example. The devices 1, 2 may further include other communication elements not shown in the figure, such as power supply elements, antennas and transceivers for long-haul radio communication, or wired communication interfaces. Also, user input may be effected by a variety of elements, such as keys and buttons, full keyboards, touch screens, joysticks, and many more. Output may be presented to the user visually and/or audibly, for example by display screens 9, LEDs, loudspeakers, or other means for information output. While some or all of these elements and further elements known in the art may be present on any of the devices, the devices may also be very different from each other, e.g. a digital assistant with touch screen and full processing capabilities and a server device without any user input or output features, but only a Bluetooth interface for communication. Fig. 2 shows a diagram illustrating a protocol flow with action progress indication between a client and a server device. A first request is transferred from the client to the server, indicating several parameters in an action request message. Parameters included in this message may comprise a connection identifier, an action identifier, an object name, a destination name, permission parameters, and/or further suitable parameters. The action identifier allows the server to determine the selected action to be performed on the specified object. According to the OBEX protocol as one example, a request or message may consist of several packets, depending on the actual transmission scheme and message size. The last packet or part of the request or message includes a "final" bit set in order to indicate completion of the message. However, in other protocols, this indication may be performed in a different way, and the "final" packets of Fig. 2 are only used as an example for describing a completed request or response. The server will respond with a first continue packet, which indicates a length header that gives a total amount of the data to be handled, e.g. a number of bytes of the object to be copied. The client may then respond to this continue message with another action request, and the server will once more respond with a second continue message, again including the same header as in the first continue message, but now likely with another parameter value. The further action request issued by the client may for example be an empty action request used for polling the progress, but it may also include information such as the object name or other headers. The new parameter value of the header may correspond to the currently remaining amount of data to be handled in the case of a length header. For example, when the action request issued by the client requested copying one or more objects with a certain amount M of bytes, the first continue response from the server to the client may include a length header indicating this number M. In the next continue packet transmitted to the client, the length header is included again, indicating the remaining number M-x of bytes to be handled, when x bytes have already been handled, e.g. copied to the required location. Without any errors, the amount of data to be handled will continuously decrease, but not necessarily with a constant rate. When the requested action has been completed on all objects, a final success packet is transmitted to the client instead of another continue packet. Optionally, the header as given in the previous continue packets may be included also in the success packet, now having a value of zero or some other value indicating that the action has been completed. Exemplary method steps are also shown in the flow diagram of Fig. 3 for a server and a client.

It is also conceivable to use the number of bytes already handled by the requested action as a progress indicator. Instead of indicating the remaining number of bytes M-x, the header may than include directly the value x. In the first response message from the server, the total number of bytes M to be handled may still be indicated. In such an embodiment, the progress indicator value such as the length header would therefore increase with time, and in each message the value of bytes already handled would be given to the client.

In other embodiments, the length header may be replaced or supplemented by other parameters. For example, a count header may be used indicating the number of objects N to be handled. As in the case of the length header, the same header with different parameter values may be transmitted in response to each further action request from the client, until the server has completed the previous action. Again, subsequent count headers will indicate a decreasing (or constant) number N-x of objects left, depending on the number x of objects that have already been handled at that time. Of course, it is once more also possible that in one embodiment not the number N-x of remaining objects is indicated, but rather the number x of handled objects. The receiving client may for example combine this information with the value N received in a first response in order to obtain a percentage of progress. Other headers and/or parameters are also conceivable for achieving this effect. For example, application parameter headers or any user-defined header may be transported in response messages to the client, including any value that may indicate a progress of the action operation, i.e. usually a counting value which may increase or alternatively decrease continuously or incrementally.

The information given to the client in the continue responses may allow the client to estimate the period of time during which the client will be busy, and schedule other processes accordingly. In other cases, the client may be able to indicate the progress of the action to a user. The client may be adapted to send action requests as long as the server responds with continue packets, and to stop sending these polling action requests when the server finally responds with a success message. On the client side, an exemplary embodiment of the invention may be illustrated as follows with reference to the method flow diagram of Fig. 3. The first device (client) sends a first action request to a second device (server), for example a request for moving a certain folder stored at the second device. The request is received at the server, and execution of the requested action may be initiated. The server determines the amount of data that has to be handled according to the request and responds with a continue message, which includes this amount of data in any suitable way, e.g. in an OBEX length header or count header for indicating the amount of data in byte or the number of objects. The client then receives the response message from the server and may determine from a specified indicator whether the message is a continue response message, e.g. from a binary response code such as 0x90 given in the first byte (byte 0) of the response message. Subsequently the client may check for further headers, such as length or count headers, or other predefined headers as explained above. In a continue message, the client may interpret the value of this predefined header as a value indicating the progress of the action at the server. Then, the client may transmit another action request message, which may be an empty message. In response to this request, the client will receive another response message from the server which currently executes the requested action, and again the client may check the response code to determine what kind of response message it is. As long as the action is still ongoing at the server, the response message received at the client will be a continue message including the same header as previous continue messages for this action. Evidently, the value given in the predefined header for progress indication will decrease (or stay the same) from one response message to the next message. As described above, the progress indication may alternatively increase if not the remaining number/amount of data objects is used as a measure, but the number of objects already handled. It shall be noted that the client is able to interpret the headers correctly as progress information since each of the continue response messages should include the same header. When the client finally determines that a received response message is not a continue message but a success message, this indicates that the server has successfully completed the requested action and is not busy any more. Thus, the client may send further operation requests or other messages as desired, and may stop the loop of repeated action requests. The values given in the headers of the response messages, i.e. for example the remaining number of objects given in the count header, may be extracted by the client and utilized in any suitable way. For example, a client device may store the progress indicating header values and retrieve desired statistics from these, such as a processing speed of the server. Also, the client device may convert the header values into a format suitable for displaying a progress indication to a user, for example a percentage of total objects or a schematic progress bar. Due to the continuous sending of further action request and the receiving of continue responses, the client is able to dynamically adapt the progress indication when necessary. In some embodiments, a progress indication may be given based on an estimate calculated from only a few first continue response messages, and then corrected when the estimate deviates largely from the actual values received in further response messages.

However, the client may in some embodiments also simply ignore the progress information supplied by the server, as long as it follows the described procedure and continues to send action requests until the server responds with a success message. It is also conceivable that a server would transmit several continue messages or packets back to the client without any further triggering action requests. This may e.g. be the case in some special OBEX protocol mode, or in different protocol implementing an embodiment according to the invention. That is, in such an embodiment a server may for example send continue messages back to the client until the requested action has been completed, and the client would not necessarily have to transmit empty or non-empty action requests. Again, the final success message would indicate a successful completion of the requested action. After the client has received a number of continue messages with progress indication and a final success message, the client is able to determine that the action has been completed and new requests may be transmitted.

It shall be noted that the attribution of roles like client and server is only for explanatory purposes and is e.g. used in the OBEX protocol and also in other standards or specifications. However, the roles may of course also be interchanged between devices or may change with different actions. Also, the terms used for describing messages and packets transmitted between those devices are not intended to be limiting and may in other embodiments or systems be replaced or supplemented by other messages, in which also any kind of header or parameter may be used to continuously indicate the busy state to the client device as described above.

Although exemplary embodiments of the present invention have been described, these should not be construed to limit the scope of the appended claims. Those skilled in the art will understand that various modifications may be made to the described embodiments and that numerous other configurations or combinations of any of the embodiments are capable of achieving this same result. Moreover, to those skilled in the various arts, the invention itself will suggest solutions to other tasks and adaptations for other applications. It is the applicant's intention to cover by claims all such uses of the invention and those changes and modifications which could be made to the embodiments of the invention herein chosen for the purpose of disclosure without departing from the spirit and scope of the invention.

Claims

1. A method comprising receiving a first action request requesting an action to be performed for at least one data object; determining a measure of data objects to be handled by said action; sending a first response message including said measure of data objects; initiating said requested action; in response to the receiving of each further action request, further determining a measure of progress of said action, and sending at least one further response message including said measure of progress, until said action has been completed; subsequent to completing said requested action, sending a success message.

2. The method of claim 1, wherein said measure of progress is a measure of remaining data objects to be handled.

3. The method of claim 1, wherein said measure of progress is a measure of data objects that have already been handled.

4. The method of any previous claim, wherein said measure of data objects or remaining data objects is included in a header of said response message.

5. The method of claim 4, wherein all response messages sent include said same header.

6. The method of claim 5, wherein the success message includes said same header indicating a predefined value.

6. The method of any previous claim, wherein said detenrtining of a measure of data objects comprises determining the number of data objects to be handled for a first action response message, and said determining of a measure of progress comprises determining a number of remaining data objects to be handled

7. The method of any of claims 1 to 5, wherein said determining of a measure of data objects comprises determining the number of data objects to be handled for a first action response message, and said determining of a measure of progress each comprises determining a number of data objects that have already been handled.

8. The method of claim 6 or 7, wherein said number of data objects or number of remaining data objects is each included in a count header of said response message.

9. The method of any of claims 2 to 8, further comprising determining the measure of remaining data objects by decreasing the determined measure of data objects in accordance with the data objects already handled.

10. The method of any previous claim, wherein said determining comprises determining a numerical quantity of data units contained within said at least one data object, and in response to the receiving of each further action request, determining a remaining numerical quantity of data units to be handled by said action, or a numerical quantity of data units that have already been handled by said action. .

11. The method of claim 10, wherein said numerical quantity of data units is included in a length header of each of said response messages.

12. The method of any of claims 4 to 11 wherein said header is a user defined header or an application parameter header.

13. The method of any previous claim, wherein said requested action is the copying or moving of a data object.

14. The method of any previous claim being performed in a server device in an OBEX conform communication.

15. A method comprising transmitting an action request for at least one data object; receiving a response message; determining whether said response message is a continue message or a success message, if said response message is a continue message, transmitting a further action request; repeating said determining and transmitting of further action requests until it is determined that said response message is a success message.

16. The method of claim 15, wherein said further action request is an empty action request.

17. The method of claim 15, wherein said further action request includes parameters identifying said object.

18. The method of any of claims 15 to 17, further comprising extracting a measure indicating an action progress from said continue message.

19. The method of any of claims 15 to 18, wherein said measure is extracted from a predefined header of said message.

20. The method of any of claims 15 to 19, further comprising displaying a visual progress indication based on said extracted measure.

21. The method of any of claims 15 to 20, further comprising checking whether two continue messages received include the same header.

22. The method of any of claims 15 to 21, wherein said determining comprises reading a predefined indicator byte of said message.

23. The method of any of claims 15 to 22, being performed in a client device in an OBEX conform communication.

24. The method of any previous claim, wherein transmissions are effected via an infrared connection.

25. The method of any previous claim, wherein transmissions are effected via a Bluetooth connection.

26. A computer program product comprising program code portions stored in a computer readable medium, the program code portions being adapted to perform method steps according to any of the previous claims when the program is run on a computer or processor.

27. A device comprising means for receiving a first action request requesting an action to be performed for at least one data object; means for determining a measure of data objects to be handled by said action; means for sending a first response message including said measure of data objects; means for initiating said requested action; means for further determining a measure of action progress, and sending at least one further response message including said current measure of action progress, until said action has been completed, in response to the receiving of each further action request; means for sending a success message subsequent to completing said requested action.

28. A device comprising means for transmitting an action request for at least one data object; means for receiving a response message; means for determining whether said response message is a continue message or a success message, means for transmitting a further action request if said response message is a continue message; means for repeating said determining and transmitting of further action requests until it is determined that said response message is a success message.