WO2011036733A1 - サーバ装置、及び画面転送システム - Google Patents

サーバ装置、及び画面転送システム Download PDF

Info

Publication number
WO2011036733A1
WO2011036733A1 PCT/JP2009/004922 JP2009004922W WO2011036733A1 WO 2011036733 A1 WO2011036733 A1 WO 2011036733A1 JP 2009004922 W JP2009004922 W JP 2009004922W WO 2011036733 A1 WO2011036733 A1 WO 2011036733A1
Authority
WO
WIPO (PCT)
Prior art keywords
unit
drawing command
screen
client device
sequence number
Prior art date
Application number
PCT/JP2009/004922
Other languages
English (en)
French (fr)
Inventor
谷澤佳道
川添博史
後藤真孝
Original Assignee
株式会社 東芝
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 株式会社 東芝 filed Critical 株式会社 東芝
Priority to PCT/JP2009/004922 priority Critical patent/WO2011036733A1/ja
Publication of WO2011036733A1 publication Critical patent/WO2011036733A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G06F3/1454—Digital output to display device ; Cooperation and interconnection of the display device with other functional units involving copying of the display data of a local workstation or window to a remote workstation or window so that an actual copy of the data is displayed simultaneously on two or more displays, e.g. teledisplay
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00—Aspects of data communication
    • G09G2370/02—Networking aspects

Definitions

  • the present invention relates to a server device and a screen transfer system.
  • the screen transfer system is a system in which a server device transmits a screen to a client device connected via a network.
  • a user can use a function of a server device by operating a client device to access the server device via a network.
  • the user inputs information to the client device using an input interface such as a mouse, a keyboard, a touch pen, or a touch screen.
  • the client device transmits the input information to the server device.
  • the server apparatus receives input information from the client apparatus, the server apparatus executes application processing on the server apparatus in accordance with the input information.
  • display drawing information is generated as a result of application processing, the server device transmits the drawing information to the client device.
  • the client device displays the drawing information on the display device or the like and notifies the user of new screen information.
  • the client device and server device communicate via a network. Therefore, when the network bandwidth is low, or when packet loss, communication failure, congestion, or the like occurs, the drawing information on the client device may be delayed or lost.
  • Patent Document 1 when the transmission data is thinned in the server device, there is a problem that the quality of the drawing information to the client device deteriorates.
  • An object of the present invention is to provide a server device and a screen transfer system that can transmit screen information to a client device without delay or loss.
  • a server device of the present invention receives input data from a client device via a network, and transmits a response screen drawing command for the input data to the client device via the network.
  • a history storage unit for storing the drawing command transmitted to the client device; a receiving unit for receiving notification data for notifying that a defect has occurred in the drawing command transmitted from the client device;
  • a first prediction unit that predicts whether or not drawing failure occurs in the client device by retransmitting the drawing command extracted from the history storage unit according to the notification data; and the first prediction unit
  • the drawing command stored in the history storage unit and the notification data A reconstruction unit which failure of al drawing reconstruct the drawing command so as not to cause, characterized in that it comprises a transmitter which transmits the drawing command to the rebuilt to the client device.
  • the output response in the client device can be displayed on the screen without delay or loss without making the user aware of the deterioration in quality.
  • FIG. 4 is a sequence diagram of processing in the client device according to the embodiment.
  • A The image figure of the window movement by the drag concerning the embodiment.
  • B The image figure of the rectangular copy in the screen update procedure of the window movement which concerns on the embodiment.
  • A The image figure of the background image drawing in the screen update procedure of the window movement which concerns on the embodiment.
  • the screen transfer system includes a server device 100 illustrated in FIG. 1A and a client device 200 illustrated in FIG. Server apparatus 100 and client apparatus 200 are connected to network 300.
  • a server apparatus 100 illustrated in FIG. 1A includes a drawing command generation unit 101, a sequence number addition unit 102, an encoding unit 103, a transmission unit (hereinafter referred to as a drawing command transmission unit) 104, a frame buffer 105, Display unit 106, reconstruction unit 107, prediction unit (hereinafter referred to as screen sharing quality prediction unit) 108, history storage unit 109, history acquisition unit 110, and reception unit (hereinafter referred to as missing notification reception unit) 111 With.
  • a drawing command generation unit 101 includes a sequence number addition unit 102, an encoding unit 103, a transmission unit (hereinafter referred to as a drawing command transmission unit) 104, a frame buffer 105, Display unit 106, reconstruction unit 107, prediction unit (hereinafter referred to as screen sharing quality prediction unit) 108, history storage unit 109, history acquisition unit 110, and reception unit (hereinafter referred to as missing notification reception unit) 111 With.
  • the drawing command generation unit 101 generates a drawing command in accordance with an OS (Operating System) executed in the server device 100 and the operating state of various applications.
  • the drawing command is a command for obtaining the latest drawing state on the display screen (desktop). By applying a drawing command to the frame buffer 105 in which the previous drawing state is stored, the latest drawing state can be obtained.
  • the drawing command is composed of a drawing command type indicating the type of the drawing command and drawing data indicating details of the content to be drawn.
  • 2A and 2B show examples of drawing commands.
  • FIG. 2A shows an example in which the drawing command type B1 is “BITMAP”.
  • the drawing data B2 includes area information B21 indicating the position of the area to be updated, and image information B22 after updating the area to be updated.
  • the image information B22 is rectangular bitmap data corresponding to a part of the desktop (e.g., values of three colors of red, green, and blue in each pixel of the rectangle).
  • the area information B21 is a coordinate value indicating the display position of the updated image on the desktop.
  • FIG. 2B shows an example in which the drawing command type C1 is “COPYRECT”. “COPYRECT” indicates that the bitmap data of a specific rectangular area in the frame buffer 105 is copied to another position.
  • the drawing data C2 includes copy destination area information C21 and copy source area information C22.
  • the drawing command generation unit 101 applies the drawing command to the frame buffer 105 and then outputs the drawing command to the sequence number adding unit 102.
  • the sequence number adding unit 102 has a storage area (not shown) for storing a sequence number count value. Each time the sequence number adding unit 102 receives a drawing command from the drawing command generating unit 101 or the reconstruction unit 107, the sequence number adding unit 102 adds the sequence number count value stored in the storage area to the drawing command. The sequence number adding unit 102 increments the sequence number count value by one each time a sequence number count value is added. The sequence number adding unit 102 outputs the rendering command with the sequence number count value added to the encoding unit 103 and the history storage unit 109.
  • the encoding unit 103 Upon receiving a drawing command from the sequence number adding unit 102, the encoding unit 103 performs an encoding process such as image compression on the drawing command. Thereafter, the encoding unit 103 outputs the encoded drawing command to the drawing command transmitting unit 104.
  • the drawing command transmission unit 104 forms the encoded drawing command into a communication packet. Thereafter, the drawing command transmission unit 104 transmits the generated packet to the network 300.
  • the frame buffer 105 stores screen data of the entire display screen of the display unit 106.
  • the frame buffer 105 receives a drawing command from the drawing command generation unit 101, the frame buffer 105 overwrites new screen data in a storage area for storing screen data in accordance with the drawing command type and drawing data of the drawing command.
  • the screen data overwritten in the storage area of the frame buffer 105 is displayed by the display unit 106.
  • the frame buffer 105 receives a screen data acquisition request from the reconstruction unit 107
  • the frame buffer 105 outputs the latest screen data in the designated area to the reconstruction unit 107.
  • the history storage unit 109 stores drawing commands.
  • the history storage unit 109 stores a sequence number and a drawing command in association with each other every time a drawing command is received from the sequence number adding unit 102. As a result, the history storage unit 109 stores a drawing history for a predetermined period.
  • the history storage unit 109 receives an acquisition request for the drawing commands accumulated from the reconstruction unit 107, the screen sharing quality prediction unit 108, and the history acquisition unit 109, the history storage unit 109 outputs a drawing command corresponding to the request to each unit. To do.
  • the history acquisition unit 110 When the history acquisition unit 110 receives a packet loss notification from the loss notification reception unit 111, the history acquisition unit 110 acquires a drawing command corresponding to the sequence number included in the loss notification from the history storage unit 109. Thereafter, the history acquisition unit 110 outputs a sequence number and a drawing command to the screen sharing quality prediction unit 108.
  • the screen sharing quality prediction unit 108 When the screen sharing quality prediction unit 108 receives the drawing command from the history acquisition unit 110, the screen sharing quality prediction unit 108 acquires the drawing command recorded after the drawing command from the history storage unit 109. Then, based on these drawing commands, it is predicted whether or not drawing failure will occur in the client device 200 when re-transmission processing is performed on the client device 200.
  • the screen sharing quality prediction unit 108 outputs a combination of the prediction result, the acquired drawing command, and the history information acquired from the history storage unit 109 to the reconstruction unit 107.
  • the reconstruction unit 107 When the reconstruction unit 107 receives a combination of the prediction result, the drawing command, and the history information from the screen sharing quality prediction unit 108, the reconstruction unit 107 confirms the content of the prediction result.
  • the prediction result is a content indicating a failure of drawing in the client device 200
  • the reconstruction unit 107 reconstructs a drawing command to be retransmitted so that the failure does not occur.
  • the reconstruction unit 107 outputs the reconstructed drawing command to the sequence number adding unit 102.
  • the display unit 106 displays the screen data stored in the frame buffer 105.
  • the missing notification receiving unit 111 receives the missing notification via the network 300, the missing notification receiving unit 111 outputs this to the history obtaining unit 110.
  • a client device 200 shown in FIG. 1B includes a receiving unit (hereinafter referred to as a drawing command receiving unit) 201, a detecting unit (hereinafter referred to as a loss detecting unit) 202, a decoding unit 203, a drawing executing unit 204, A frame buffer 205, a display unit 206, and a transmission unit (hereinafter referred to as a loss notification transmission unit) 207 are provided.
  • the drawing command receiving unit 201 receives a drawing command via the network 300.
  • the defect detection unit 202 has a storage area (not shown) for storing the sequence number count value.
  • the defect detection unit 202 stores the sequence number added to the drawing command and detects whether or not there is a defect in the drawing data of the received drawing command. If the defect detection unit 202 detects a defect, the defect detection unit 202 outputs the missing sequence number to the defect notification transmission unit 207. In addition, the rendering command is output to the decoding unit 203 together with the missing sequence number.
  • the defect detection unit 202 outputs the drawing command to the decoding unit 203.
  • the decoding unit 203 When receiving the drawing command, the decoding unit 203 performs decoding processing on the drawing command. Thereafter, the decoded drawing command is output to the drawing execution unit 204.
  • the drawing execution unit 204 Upon receiving the decoded drawing command, the drawing execution unit 204 overwrites the screen data in the frame buffer 205 with new screen data according to the drawing command type and drawing data included in the drawing command.
  • the frame buffer 205 stores the screen data of the entire display screen of the display unit 206.
  • the display unit 206 displays screen data stored in the frame buffer 205.
  • the loss notification transmission unit 207 packetizes this. Thereafter, the packet is sent to the server apparatus 100 via the network 300 as a missing notification.
  • the server device 100 and the client device 200 are connected via a network 300.
  • the server apparatus 100 and the client apparatus 200 are in a state where the network connection is completed and the screen transfer is being performed.
  • FIG. 3A is a flowchart of the screen update process of the server device 100. A screen update process in the server apparatus 100 will be described with reference to FIGS. 1 (a) and 3 (a).
  • the drawing command generation unit 101 updates the visual information presented to the client device 200 due to changes in the operating state of the OS and various applications executed in the server device 100. Is checked (step S101).
  • the drawing command generation unit 101 If there is a screen update (YES in step S101), the drawing command generation unit 101 generates a drawing command (step S102).
  • the drawing command generation unit 101 generates a drawing command of a type such as “BITMAP” or “COPYRECT” as described above by extracting a difference between visual information before and after the update by an arbitrary method.
  • the drawing command generation unit 101 may obtain a drawing command by directly hooking a drawing command issued by the OS.
  • the drawing command generation unit 101 inputs the generated drawing command to the frame buffer 105.
  • the frame buffer 105 overwrites the drawing command drawing data (new screen data) in the area indicated by the drawing command area information in the internal storage area.
  • the display unit 106 displays the screen data stored in the frame buffer 105.
  • the drawing command generation unit 101 outputs the generated drawing command to the sequence number adding unit 102. Thereafter, the process flow proceeds to step S103.
  • the sequence number adding unit 102 refers to the sequence number count value stored in the internal sequence number storage area.
  • the sequence number adding unit 102 adds this sequence number count value as a sequence number to the received drawing command (step S103).
  • the sequence number adding unit 102 resets the sequence number count value to zero at the start of screen transfer. Thereafter, the sequence number count value is incremented by 1 each time a sequence number is added in the process of step S103. When the sequence number count value exceeds a specified value (for example, 2 to the 32nd power minus 1), it is reset to zero again. Thereafter, the process flow proceeds to step S104.
  • a specified value for example, 2 to the 32nd power minus 1
  • the sequence number adding unit 102 outputs a drawing command and sequence number pair to the history storage unit 109.
  • the history storage unit 109 stores a drawing command / sequence number pair as a drawing history in an internal storage area (step S104).
  • sequence number adding unit 102 When the sequence number adding unit 102 receives a notification of completion of storage from the history storage unit 109, the sequence number adding unit 102 outputs a drawing command to which the sequence number is added to the encoding unit 103.
  • FIG. 4B is an example of a drawing history stored in the history storage unit 109.
  • the history storage unit 109 does not need to store all the information of the drawing command.
  • the sequence number and the corresponding drawing command type (“COPYRECT”, “BITMAP”, etc.) are stored.
  • the drawing command type is “COPYRECT”
  • the area information C21 and the copy source area information C22 are further stored.
  • the drawing command type is “BITMAP”
  • only the area information B21 is stored. That is, in the case of “BITMAP”, the bitmap data of the image information B22 is not stored.
  • the encoding unit 103 Upon receiving the drawing command, the encoding unit 103 performs an encoding process on the image information when the drawing command type is “BITMAP”. The encoding unit 103 compresses the bitmap data using an arbitrary algorithm such as JPEG (Joint Photographic Experts Group) or gzip (GNU ZIP). Next, the encoding unit 103 outputs the encoded drawing command to the drawing command transmission unit 104.
  • JPEG Joint Photographic Experts Group
  • gzip GNU ZIP
  • the drawing command transmission unit 104 converts a drawing command packet for communication, such as adding a UDP (User Datagram Protocol) header or an IP (Internet Protocol) header to the drawing command. Thereafter, the drawing command transmission unit 104 sends a drawing command packet to the network 300.
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • FIG. 3B is a flowchart when the client apparatus 200 receives a drawing command packet.
  • the drawing command receiving unit 201 when receiving the drawing command packet from the network 300, the drawing command receiving unit 201 excludes the UDP header and the IP header from the packet and takes out the drawing command (step S301). Thereafter, the drawing command receiving unit 201 outputs the extracted drawing command to the defect detection unit 202.
  • the missing detection unit 202 When the missing detection unit 202 receives the drawing command from the drawing command receiving unit 201, the missing detection unit 202 extracts the sequence number in the drawing command. Thereafter, the loss detection unit 202 compares the acquired sequence number with a sequence number count value stored in an internal sequence number count value storage area (not shown), and checks whether they match. (Step S302).
  • the comparison result between the two is divided into the following three cases.
  • the second case is “when the sequence number in the drawing command does not match the sequence number count value and the sequence number in the drawing command is larger than the sequence number count value (>)”.
  • the third case is “when the sequence number in the drawing command does not match the sequence number count value and the sequence number in the drawing command is smaller than the sequence number count value ( ⁇ )”.
  • the defect detection unit 202 determines that no defect has occurred. Then, the defect detection unit 202 outputs the received drawing command to the decoding unit 203. Thereafter, the process flow proceeds to step S305.
  • the decoding unit 203 When the decoding unit 203 receives the drawing command, the decoding unit 203 performs a corresponding decoding process when the drawing command is encoded. Thereafter, the decoded drawing command is output to the drawing execution unit 204.
  • the drawing execution unit 204 stores the screen data in the drawing command in the frame buffer 205 according to the drawing command. Thereafter, the display unit 206 retrieves the screen data stored from the frame buffer 205 and displays it on the screen (step S305).
  • the defect detection unit 202 determines that a defect has occurred. For example, assuming that the sequence number count value held internally is “100” and the sequence number in the drawing command is “103”, the loss detection unit 202 has sequence numbers “100”, “101”, “102”. It is determined that a defect has occurred in the drawing command packet corresponding to.
  • the defect detection unit 202 outputs the sequence number (“100”, “101”, “102” in the above example) of the rendering command packet in which the defect has occurred to the defect notification transmission unit 208.
  • the loss notification transmission unit 208 adds information necessary for communication such as a UDP header and an IP header to the sequence number notified from the loss detection unit 202, and forms a loss notification packet for notifying the server device 100 of the loss. Thereafter, the loss notification transmission unit 208 transmits a loss notification packet (step S303).
  • the loss detection unit 202 When the transmission of the loss notification packet is completed, the loss detection unit 202 outputs a combination of the drawing command input from the drawing command reception unit 201 and the sequence number of the drawing command in which the loss has occurred to the decoding unit 203. Thereafter, the process flow proceeds to step S305.
  • the decoding unit 203 When the decoding unit 203 receives the drawing command, the decoding unit 203 performs a corresponding decoding process when the drawing command is encoded. Thereafter, the decoded drawing command is output to the drawing execution unit 204.
  • the drawing execution unit 204 stores the screen data in the drawing command in the frame buffer 205 according to the drawing command. Thereafter, the display unit 206 retrieves the screen data stored from the frame buffer 205 and displays it on the screen (step S305).
  • the defect detection unit 202 determines that the drawing command received previously has been received in duplicate. Then, the loss detection unit 202 discards the received drawing command and ends the process (step S304).
  • the loss detection unit 202 compares the sequence number in the drawing command with the sequence number count value, the sequence number in the drawing command is added to the internal sequence number count value. Is overwritten and updated.
  • FIG. 4A is a flowchart when the server device 100 receives a loss notification packet.
  • the missing notification receiving unit 111 extracts one or a plurality of sequence numbers included in the missing notification packet (step S201). Then, the sequence number is output to the history acquisition unit 110.
  • the history acquisition unit 110 Upon receiving the sequence number, acquires a drawing command corresponding to the sequence number from the history storage unit 109 (step S202).
  • the history storage unit 109 stores a drawing command history as shown in FIG. 4B, for example.
  • the history storage unit 109 outputs history information for the requested sequence number.
  • the history information includes at least a drawing command type corresponding to the sequence number and area information.
  • the history acquisition unit 110 outputs the acquired drawing command history information to the screen sharing quality prediction unit 108.
  • the screen sharing quality prediction unit 108 When the screen sharing quality prediction unit 108 receives the history information, the screen sharing quality prediction unit 108 acquires all the history information of drawing commands after the sequence number from the history storage unit 109. Next, the screen sharing quality prediction unit 108 predicts whether or not drawing failure will occur in the screen state of the client device 200 when a missing drawing command is retransmitted according to a prediction routine described later.
  • the drawing command type is “COPYRECT”
  • the copy source area is represented as S [L].
  • the missing drawing command is expressed as “BITMAP: D [L]” or “COPYRECT: S [L] ⁇ D [L]”.
  • the history of the drawing command generated i-th after the drawing command is expressed as “BITMAP: D [i]” or “COPYRECT: S [i] ⁇ D [i]”.
  • the screen sharing quality prediction unit 108 executes the following prediction routine in order to predict whether or not drawing failure will occur in the screen state in the client device 200 when the missing drawing command is retransmitted (step S203). .
  • “TRUE” means “drawing failure occurs”
  • “FALSE” means “drawing failure does not occur”.
  • the shared quality prediction unit 108 can predict the presence or absence of a drawing failure in the client device 200 by executing a ⁇ prediction routine>.
  • the screen sharing quality prediction unit 108 outputs the prediction result (“TRUE” or “FALSE”) and the missing drawing command to the reconstruction unit 107.
  • the reconstruction unit 107 confirms the prediction result when the prediction result and the missing drawing command are input.
  • the prediction result is “FALSE” (“NO” in step S204)
  • the reconstruction unit 107 acquires the latest drawing data of the frame buffer 105 corresponding to the area information B21.
  • the acquired latest drawing data of the frame buffer 105 is converted into bitmap data, and the missing drawing command is output to the sequence number adding unit 102 (step S206).
  • the reconstruction unit 107 outputs the drawing command as it is to the sequence number adding unit 102 (step S206).
  • the subsequent operation of the sequence number adding unit 102 is the same as that described above (step S207).
  • sequence number added to the drawing command at this time is not a missing sequence number but a new number.
  • step S204 when the prediction result is “TRUE” (“YES” in step S204), if the missing drawing command is simply retransmitted, drawing in the client device 200 is broken. Therefore, the reconstruction unit 107 reconstructs the drawing command according to the following reconstruction routine (step S205).
  • the reconstruction unit 107 acquires history information of all drawing commands generated after the missing drawing command from the history storage unit 109. Thereafter, the following reconstruction routine is executed.
  • the history information of the i th drawing command generated after the drawing command is expressed as “BITMAP: D [i]” or “COPYRECT: S [i] ⁇ D [i]”.
  • S [i] is treated as an empty set for the BITMAP drawing command.
  • the output list is a list that temporarily stores drawing commands when the reconstruction unit predicts failure, and this step (S205) The drawing command is stored at, and is referred to in later steps (S206 and S207).
  • D [A] -D [i] indicates a partial area obtained by excluding the common part of D [A] and D [i] from the area of D [A].
  • the reconstruction unit 107 checks the drawing commands in the output list in order from the top. If the reconstructed drawing command is “BITMAP”, the reconstructing unit 107 acquires the latest drawing data of the frame buffer 105 corresponding to the area information B21. The acquired latest drawing data of the frame buffer 105 is converted into bitmap data (image information B22), and the reconstructed drawing command is output to the sequence number adding unit 102 (step S206).
  • the reconstruction unit 107 outputs the drawing command as it is to the sequence number adding unit 102 (step S206).
  • the subsequent operation of the sequence number adding unit 102 is the same as that described above (step S207).
  • FIG. 4B shows an example of history information of a series of drawing commands generated within a certain time.
  • the client device 200 when the sequence number 1 is lost, the client device 200 first receives a drawing command of the sequence number 2. At this time, the loss detection unit 202 of the client device 200 detects a loss of sequence number 1. After that, the loss of sequence number 1 is notified to the history acquisition unit 110 of the server device 100 through the loss notification transmission unit 207 and the loss notification reception unit 111 of the server device 100.
  • the history acquisition unit 110 of the server apparatus 100 acquires BITMAP: (70, 70, 350, 280) as the history information corresponding to the sequence number 1, it passes this to the screen sharing quality prediction unit 108.
  • the screen sharing quality prediction unit 108 acquires from the history storage unit 109 the history information of the drawing command of sequence number 2, sequence number 3, sequence number 4 after sequence number 1, the client uses the above-described ⁇ prediction routine>. It is predicted whether or not the drawing in the apparatus 200 will fail. In the example of FIG. 6, since the drawing area (70, 70, 350, 280) of sequence number 1 and the copy source area (70, 70, 350, 280) of sequence number 2 have a common part, The result is “TRUE” (failure occurs).
  • the reconstruction unit 107 receives the prediction result from the history storage unit 109 and reconstructs the drawing command.
  • the reconstructed rendering command is BITMAP: (280, 210, 560, 420).
  • the reconstruction unit 107 acquires the latest drawing data of the frame buffer 105 corresponding to this area, makes this bitmap data, and outputs this drawing command to the sequence number adding unit 102.
  • the sequence number adding unit 102 adds a new sequence number 5 to the drawing command (see FIG. 6A) and transmits it to the client terminal 200 via the network 300.
  • the client device 200 receives the drawing commands in the order of the sequence numbers 1 and 3. Accordingly, the loss detection unit 202 detects a loss of the sequence number 2 based on the sequence number counter value. The defect detection unit 202 notifies the history acquisition unit 110 of the server apparatus 100 of the defect of the sequence number 2 through the defect notification transmission unit 207, the network 300, and the defect notification reception unit 111 of the server apparatus 100.
  • the history acquisition unit 110 acquires a drawing command “COPYRECT: (70, 70, 350, 280) ⁇ (280, 210, 560, 420)” from the history storage unit 109 as a history corresponding to the sequence number 2.
  • the history acquisition unit 110 passes the acquired drawing command to the screen sharing quality prediction unit 108.
  • the screen sharing quality prediction unit 108 acquires the history information of the drawing commands of the sequence number 3 and the sequence number 4 after the sequence number 2 from the history storage unit 109. Thereafter, using the above-described ⁇ prediction routine>, it is predicted whether or not the drawing failure occurs in the client apparatus 200.
  • the copy source area (70, 70, 350, 280) of sequence number 2 and the drawing area (70, 70, 350, 210) of sequence number 3 have a common part, The result is “TRUE”.
  • the reconstruction unit 107 reconstructs the drawing command using the above-described ⁇ reconstruction routine>.
  • the output list as the rendering command after the reconstruction includes “COPYRECT: (70, 70, 350, 280) ⁇ (280, 210, 560, 420)”, “BITMAP: (280 , 210, 560, 350) ”and“ BITMAP: (280, 350, 490, 420) ”.
  • the reconstruction unit 107 adds the sequence number to the rendering command in the output list after acquiring the latest frame buffer rendering data corresponding to the area if the rendering command is “BITMAP” in order from the top. Output to the unit 102.
  • the sequence number adding unit 102 adds new sequence numbers 5, 6, and 7 to the drawing command and transmits it (see FIGS. 6B, 6C, and 6D).
  • ⁇ prediction routine> and ⁇ reconstruction routine> described in this embodiment are merely examples for operations.
  • An arbitrary routine other than this may be used as long as the failure of drawing in the client apparatus 200 can be avoided.
  • the server device 100 can predict the failure of drawing in the client device 200 by referring to the history of drawing commands sent in the past. In addition, when it is predicted that drawing will fail in the client device 200, the server device 100 can reconstruct the drawing command, thereby avoiding drawing failure in the client device 200. As a result, the output response in the client device 200 can be displayed on the screen without delay or loss without making the user aware of deterioration in quality.
  • the server apparatus 100 configures and transmits only the minimum drawing command necessary for avoiding the failure. Therefore, for example, compared to the case where the latest drawing state of the entire desktop is acquired and transmitted, the processing load of encoding and transmission in the server apparatus 100 is reduced. In addition, there is an advantage that the consumption of the network bandwidth can be reduced.
  • the client apparatus 200 when the client apparatus 200 according to the present embodiment detects a deficiency in the reception of the drawing command, the client apparatus 200 continues to execute drawing using the drawing command received thereafter without waiting for a response to the deficiency notification. Therefore, as compared with a case where, for example, a screen transfer system using TCP (Transmission Control Protocol) as a transmission protocol, the subsequent drawing is interrupted and a retransmission from the server device is waited for when a defect occurs. There is an advantage that the real-time property can be ensured that the drawing executed in 100 is immediately reflected in the client device 200.
  • TCP Transmission Control Protocol
  • FIG. 7 is a diagram illustrating a configuration of a screen transfer system according to the second embodiment.
  • the screen transfer system includes the server device 1000 and the client device 2000 shown in FIG. FIG. 7 also shows the flow of data in the screen transfer system by arrows. Dashed arrows indicate normal (comparative example) data flow, and solid arrows indicate data flow specific to the present embodiment. As an example, a case where a window displayed on the screen of the client device 2000 is moved by dragging will be described below.
  • the input unit 2001 accepts a pointer input input by a user of the client device 2000 with a pen, a mouse, or a key input input with a keyboard or the like.
  • the client apparatus 2000 transmits input data such as pointer input and key input to the server apparatus 1000 via the communication unit 2002 and the network 300.
  • the communication unit 1001 of the server apparatus 1000 receives input data. Thereafter, the input data is passed to the input processing unit 1002.
  • the input processing unit 1002 passes the input data to the application / OS 1003.
  • program execution is performed according to input data, and output display data indicating the processing result is displayed on the screen. (Depending on the processing contents, the data may not be output and displayed on the screen.)
  • the output display data on the screen is output from the application / OS 1003 to the drawing transfer unit 1004 as a screen drawing command.
  • the drawing transfer unit 1004 transmits the drawing command to the client device 2000 through the communication unit 1001 and the network 300.
  • the communication unit 2002 of the client device 2000 receives a drawing command from the server device 1000. Thereafter, a drawing command is executed in the display unit 2003, and output display data is displayed on the screen.
  • the screen sharing quality prediction unit 2004 is activated in the client device 2000 by using a pointer input from the input unit 2001 and a rectangular copy drawing command (details will be described later) from the communication unit 2002 as a trigger. . Then, the prediction unit (hereinafter referred to as a screen sharing quality prediction unit) 2004 predicts that the output display in the client device 2000 will be deficient. This is because a rectangular copy by dragging is an operation that generates a large amount of screen update data, and thus may induce a large amount of communication. This is because there is a high possibility of causing a failure of drawing due to packet loss, deterioration of operability, and the like.
  • the screen sharing quality prediction unit 2004 instructs the blocking unit (hereinafter referred to as a transfer blocking unit) 2006 not to transfer the input pointer input to the server apparatus 1000 thereafter.
  • the transfer blocking unit 2006 discards the pointer input data received from the input unit 2001 as it is.
  • the screen sharing quality prediction unit 2004 instructs the construction unit (hereinafter referred to as the reconstruction unit) 2005 to reconstruct the drawing command.
  • the reconstruction unit 2005 reconstructs the pointer input into a rectangular copy drawing command for the screen and passes it to the display unit 2003. Thereafter, a rectangular copy drawing command is executed in the display unit 2003, and an output is displayed on the screen.
  • the reconstructing unit 2005 reconstructs the rectangular copy drawing command in accordance with the movement of the drag and passes it to the display unit 2003.
  • the screen sharing quality prediction unit 2004 notifies the transfer blocking unit 2006 and the reconstruction unit 2005 to that effect. With this notification, the transfer blocking unit 2006 ends the operation of discarding the input data. In addition, the reconstruction unit 2005 ends the reconstruction of the rectangular copy drawing command.
  • the transfer blocking unit 2006 transmits the last drag input to the server apparatus 1000 via the communication unit 2002 and returns to the normal operation.
  • FIG. 8 is a diagram illustrating the operation of the client apparatus 2000.
  • TIP means a pen touch in pen input, and means that the pen is touched at the coordinate [x11, y11].
  • the screen sharing quality prediction unit 2004 receives a pointer input and detects that a pen touch has been started. Then, the pointer input is passed to the communication unit 2002 via the transfer blocking unit 2006.
  • a pointer input TIP [x12, y12] is input from the input unit 2001.
  • the screen sharing quality prediction unit 2004 detects that the drag has been performed since the coordinates are moved while the pen is touched. Then, the pointer input is passed to the communication unit 2002 via the transfer blocking unit 2006.
  • screen update data 3001 and 3002 by dragging a window are transmitted from the server apparatus 1000 by the above-described processing.
  • the screen update data 3001 is a rectangular copy drawing command.
  • the screen update data 3002 is a background image drawing command.
  • the client apparatus 2000 moves (drags) the window as shown in FIG.
  • the window size is 320 ⁇ 200.
  • two pieces of screen update data that is, a rectangular copy drawing command 3001 and a background image drawing command 3002 are transmitted from the server device 1000 to the client device 2000.
  • the screen sharing quality prediction unit 2004 determines whether the input pointer input [x12, y12] is within a 320 ⁇ 200 pixel rectangle from the starting point [x22, y22]. Here, the description will be made assuming that it is determined to be within the rectangle.
  • the screen sharing quality prediction unit 2004 predicts that the output screen display in the client device 2000 will be deficient based on the determination that it is within the rectangle.
  • the screen sharing quality prediction unit 2004 sends a blocking start command 3003 to the transfer blocking unit 2006 based on the prediction.
  • the transfer blocking unit 2006 receives a command from the screen sharing quality prediction unit 2004, and thereafter stops the transfer of the received data.
  • the communication unit 2006 displays the screen update data 3001 (rectangular copy [x21, y21] (320x200)-[x22, y22]) and the screen update data 3002 (background image drawing) sent from the server apparatus 1000. Part 2003.
  • the display unit 2003 executes processing of the received screen update data and outputs a display.
  • the screen sharing quality prediction unit 2004 issues an instruction restructuring instruction 3004 to the restructuring unit 2005.
  • the transfer blocking unit 2006 receives the pointer input (TIP [x13, y13]), but does not transfer it to the server apparatus 1000 but holds it as the latest pointer input. Thereafter, the same operation is performed when the next pointer input (TIP [x14, y14]) and the next next pointer input (TIP [x18, y18]) are input from the input unit 2001.
  • unTIP [x19, y19]
  • unTIP means the pen touch has been released. That is, it means that the drag operation that has been performed so far is completed at the coordinates [x19, y19].
  • the screen sharing quality prediction unit 2004 transmits a block termination end instruction 3007 to the transfer block unit 2006.
  • the transfer blocking unit 2006 transfers the last pointer input (unTIP [x19, y19]) to the server apparatus 1000 via the communication unit 2002.
  • the server apparatus 1000 changes from the execution state of the pointer input TIP [x12, y12] received from the client apparatus 2000 to the execution state of the pointer input (unTIP [x19, y19]) received from the client apparatus 2000 this time. Perform the process. As a result, the output screen update data 3008 and 3009 are transmitted to the client apparatus 2000.
  • the client device 2000 receives the screen update data 3008 and 3009 and executes the processing. Thereafter, the client apparatus 2000 returns to the same state as at the start of this sequence.
  • the client device 2000 when it is predicted that a large amount of screen update data is generated by the drag operation, the client device 2000 according to the present embodiment does not transmit the pointer input related to the drag operation to the server device 1000 and stores the image data held therein. Use it to display the output screen. As a result, the amount of communication between the client device 2000 and the server device 1000 can be reduced, and network congestion can be suppressed. As a result, in the client device 2000, it is possible to avoid the failure of drawing due to packet delay or loss.
  • the third embodiment includes a screen sharing quality prediction unit 108 and a reconstruction unit 107 in the client device of the screen transfer system.
  • the shape of the mouse pointer cursor (hereinafter referred to as a cursor) displayed on the client device indicates that the processing is waiting. Change to the hourglass mark. This correctly notifies the user of the screen transfer system that processing delay due to the network has occurred. As a result, it is possible to remove the user's stress and the cause of unexpected misoperation.
  • the screen transfer system includes the server device 1000 and the client device 2000 shown in FIG. Further, the data flow is as shown in FIG. 7 as in the second embodiment. Therefore, the prediction method in the screen sharing quality prediction unit 2004 specific to the present embodiment and the processing content of the reconstruction unit 2005 will be described below.
  • the screen sharing quality prediction unit 2004 acquires network information indicating the quality of the network 300 from the communication unit 2002.
  • the screen sharing quality prediction unit 2004 determines whether there is a delay in the network 300 based on the acquired network information.
  • a cursor image to be drawn on the display unit 2003 (hereinafter referred to as cursor image information) is designated to the reconstruction unit 2005.
  • the network information to be acquired and a method for determining the occurrence of delay based on the network information will be described later.
  • the reconstruction unit 2005 in this embodiment has the following functions in addition to the functions described in the first and second embodiments.
  • the reconstruction unit 2005 is notified of the position information of the cursor (including button press information and the like, the same applies hereinafter) from the input unit 2001 via the screen sharing quality prediction unit 2004 and stores the information. Also, the reconstruction unit 2005 is notified of the cursor image information from the screen sharing quality prediction unit 2004 and stores it. Alternatively, the reconstruction unit 2005 determines cursor image information to be drawn at the cursor position in response to a request from the screen sharing quality prediction unit 2004. In this case, the cursor image information specified by the drawing command may be overwritten and updated.
  • FIG. 10B is a flowchart showing the operation of the screen sharing quality prediction unit 2004.
  • step S1402 when receiving a drawing command or network information from the communication unit 2002 (step S1401), the screen sharing quality prediction unit 2004 starts a delay determination process (step S1402).
  • the screen sharing quality prediction unit 2004 If it is determined that the network 300 is in a delayed state, the screen sharing quality prediction unit 2004 notifies the reconstruction unit 2005 with, for example, the cursor image information X (step S1403). On the other hand, when it determines with it not being in a delay state, the screen sharing quality prediction part 2004 notifies the cursor image information W with respect to the reconstruction part 2005 (step S1405).
  • step S1404 When a change from the cursor image information X to the cursor image information W or a change from the cursor image information W to the cursor image information X occurs in the reconstruction unit 2005, the change of the cursor image information is prohibited for a predetermined time (step S1404). .
  • the prohibition of changing the cursor image information for a certain time is a flow necessary for the cursor image information not to be changed frequently.
  • the cursor image information X is used to notify the user that a delay has occurred in the network 300.
  • an hourglass mark image is used as the cursor image information X.
  • the same image as the hourglass mark image indicating that the computer is processing may be used.
  • different hourglass mark images may be used to explicitly indicate that the state is delayed.
  • the client device 2000 may perform the operation described below.
  • screen drawing on the display unit 2003 may be stopped. That is, when the network 300 is in a delay state, the output screen information transmitted from the server apparatus 1000 is not smoothly received. Therefore, the screen drawing is stopped in order to avoid unnecessarily consuming the resources of the client device due to the drawing being disturbed or delayed.
  • the position of the cursor image information X (hourglass mark) may not be updated and may be stopped. This is to notify the user that the client terminal 2000 cannot be operated.
  • the screen sharing quality prediction unit 2004 determines whether the network 300 is in a delay state by repeating the following three steps. (1) calculation of the delay value, (2) determination of whether or not the delay state is obtained by comparing the delay value with the delay determination constant, and (3) correction of the delay determination constant.
  • Delay value Y is calculated and obtained based on network information.
  • the delay value Y is, for example, a time width such as RTT (Round Trip Time). Since there are some variations in the network information to be used and its calculation method, it will be described later.
  • FIG. 11A shows a change of the delay index Y with respect to time.
  • the horizontal axis in FIG. 11A is the delay value Y.
  • the vertical axis represents time elapsed t.
  • the delay value Y obtained in “(1) Delay value calculation” is compared with two delay determination constants A and B (A ⁇ B) determined in advance. If Y is larger than B (that is, the previous Y was Y ⁇ B, but the current Y was B ⁇ Y), it is determined that the network 300 is in a delay state. If Y is smaller than A (that is, the current Y is Y ⁇ A even though the previous Y was A ⁇ Y), it is determined that the network 300 is not in a delay state. In cases other than the above, the previous determination result is maintained and is not changed.
  • FIG. 11A is a graph showing the result of the above determination. That is, as shown in FIG. 11A, if the network 300 is in the delay state from the time when the delay value Y exceeds the delay determination constant B to the time when it falls below the delay determination constant A, the screen sharing quality prediction is performed. The part 2004 determines.
  • the initial values of the delay determination constants A and B may be determined using link information that the client apparatus 2000 is connected to the network 300. For example, consider a case where the client device 2000 is connected to a wired LAN. When the client device 2000 is connected to a 100 Mbps wired LAN and when it is connected to a 1 Gbps wired LAN, it is desirable that the latter has a larger value of A and B. Next, consider a case where the client device 2000 is connected to a wireless LAN. In the case of using a wireless LAN compliant with IEEE802.11b and in the case of using a wireless LAN compliant with IEEE802.11g, it is desirable that the latter have larger values of A and B.
  • the delay value is calculated and calculated by any of the following methods (A) to (D) or a combination thereof.
  • the RTT value is used as network information.
  • the screen sharing quality prediction unit 2004 of the client device 2000 exchanges data with the server device 1000 for measuring RTT (Round Trip Time).
  • RTT Red Trip Time
  • a method for measuring RTT a generally known method is used. Since it is not limited by this invention, detailed description is abbreviate
  • the screen sharing quality prediction unit 2004 uses the RTT value obtained by the measurement as a delay value.
  • the screen sharing quality prediction unit 2004 of the client device 2000 can either “(1) the number of data transmitted to the server device 1000 that has not yet received a TCP Ack message” or “(2) the current number in the TCP stack.
  • Network information related to transmission data such as “segment size” is acquired from the communication unit 2002 and stored.
  • the screen sharing quality prediction unit 2004 calculates the ratio of data that has not yet received the TCP Ack message and uses it as a delay value.
  • the screen sharing quality prediction unit 2004 calculates the difference between the maximum segment size and the current segment size and uses it as a delay value.
  • the screen update data received by the communication unit 2002 may be delivered as a plurality of TCP packets, or may be retransmitted because some data is delivered missing. For this reason, the time when the communication unit 2002 starts to receive the screen update data is different from the time when the reception of the screen update data is completed. Accordingly, the screen sharing quality prediction unit 2004 starts a timer (not shown) at the time when the communication unit 2002 starts to receive screen update data. Then, the timer is stopped at the time when the reception of the screen update data is completed. Thereby, the time required from the start of reception of the screen update data to the completion of reception is measured. The screen sharing quality prediction unit 2004 uses the measured time taken from the start of reception of screen update data to the completion of reception as a delay value.
  • the screen sharing quality prediction unit 2004 may stop the timer even if the reception of the screen update data is not completed, and use the measured value at that time as the network information.
  • the screen sharing quality prediction unit 2004 adds a sequence number to the input data to be transmitted.
  • the client device 2000 first transmits input data of the sequence number “5” to the server device 1000.
  • the screen sharing quality prediction unit 2004 starts a timer (not shown) corresponding to the sequence number at the time when transmission of the input data is completed. At the same time, the sequence number is increased.
  • a timer (not shown) corresponding to the sequence number at the time when transmission of the input data is completed. At the same time, the sequence number is increased.
  • FIG. 11B each time input data of sequence numbers “5” and “6” is transmitted, a corresponding timer is started.
  • the screen sharing quality prediction unit 2004 confirms the sequence number added to the screen update data when receiving the screen update data returned from the server apparatus 1000 in response to the transmission of the input data.
  • the screen sharing quality prediction unit 2004 stops the timer corresponding to the aforementioned sequence number at the time when the reception of the screen update data is completed.
  • the client apparatus 2000 stops the corresponding timer.
  • the server apparatus 1000 always stores the latest sequence number added to the input data received from the client apparatus 2000.
  • the server apparatus 1000 is assumed to transmit the stored sequence number by adding it to the screen update data.
  • the screen sharing quality prediction unit 2004 measures the time required from the completion of input data transmission to the completion of reception of screen update data (“measurement time” in FIG. 11B) from the timer value corresponding to the sequence number.
  • the screen sharing quality prediction unit 2004 uses the measured time taken from the completion of input data transmission to the completion of reception of screen update data as a delay value.
  • the timer value at that time may be network information.
  • sequence number added to the input data or screen update data may be transmitted as data different from the input data or screen update data.
  • the sequence number may be included in the input data as part of a mouse event that is not directly related to user operation.
  • the sequence number may be included in the screen update data as part of the display drawing information outside the drawing range of the client device 2000.
  • the timing for measuring the time required from the completion of input data transmission to the completion of screen update data reception is arbitrary, and it is not always necessary to perform measurement every time input data transmission is completed. For example, measurement can be performed only when the mouse is clicked, which is important as input data.
  • the time measured using the above method (D) is considered to be a value close to the RTT between the client apparatus 2000 and the server apparatus 1000.
  • the shape of the cursor displayed on the client device is changed to an “hourglass mark” indicating that processing is waiting. .
  • packet delay and loss due to network congestion can be reduced, the output response in the client device can be displayed on the screen without delay or loss.
  • the user of the screen transfer system can correctly grasp that the processing delay caused by the network has occurred, the user's stress can be reduced.
  • the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying constituent elements without departing from the scope of the invention in the implementation stage.
  • various inventions can be formed by appropriately combining a plurality of components disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment.
  • constituent elements over different embodiments may be appropriately combined.
  • DESCRIPTION OF SYMBOLS 100 ... Server apparatus 101 ... Drawing command generation part 102 ... Sequence number addition part 103 ... Encoding part 104 ... Drawing command transmission part 105 ... Frame buffer 106 ... Display part 107- ..Reconstructing unit 108 ... Screen sharing quality prediction unit 109 ... History storage unit 110 ... History acquisition unit 111 ... Deficiency notification receiving unit 200 ... Client device 201 ... Drawing command receiving unit 202... Missing detector 203... Decoding unit 204... Drawing execution unit 205... Frame buffer 206.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

　サーバ装置１００は、ネットワーク３００を介してクライアント装置２００から入力データを受信し、入力データに対する応答画面の描画命令をクライアント装置２００に送信する。サーバ装置１００の欠損通知受信部１１１は、クライアント装置２００において描画命令の受信に欠損が生じたことを検知する。画面共有品質予測部１０８は、欠損に対して描画命令を再送信する場合に、クライアント装置で描画の破綻が生じるか否かを判定する。描画の破綻が生じると判定した場合に、再構築部１０７によって描画が破綻しないするように描画命令を再構築し、描画命令送信部１０４は再構築した描画命令をクライアント装置２００に送信する。

Description

サーバ装置、及び画面転送システム
　本発明は、サーバ装置、及び画面転送システムに関する。
　画面転送システムとは、サーバ装置がネットワークを介して接続されたクライアント装置に対して、画面を送信するシステムである。このシステムでは、利用者がクライアント装置を操作して、ネットワークを介してサーバ装置にアクセスし、サーバ装置の機能を利用することができる。
　まず利用者は、マウス、キーボード、タッチペン、タッチスクリーン等の入力インタフェースを用いてクライアント装置に情報を入力する。クライアント装置は、その入力情報をサーバ装置に対して送信する。サーバ装置は、クライアント装置から入力情報を受信すると、その入力情報に従ってサーバ装置上のアプリケーション処理を実行する。アプリケーション処理の結果、ディスプレイ描画情報が生成されると、サーバ装置はその描画情報をクライアント装置に送信する。クライアント装置は、描画情報を受信すると、ディスプレイ装置等に表示し、利用者に新しい画面情報を伝える。
　画面転送システムでは、クライアント装置とサーバ装置がネットワークを介して通信する。そのため、ネットワークの帯域幅が少ない場合や、パケットロスや通信障害、輻輳などが発生すると、クライアント装置への描画情報が遅延あるいは欠損することがある。
　上記の問題を解決するために、サーバ装置においてネットワーックの状況やＣＰＵ負荷などに応じて送信データを間引くことで、ネットワークの負荷を下げ、通信遅延を抑制する技術が発明されている。（例えば、特許文献１参照。）
特開２０００－５７０９４号公報
　しかしながら、特許文献１のように、サーバ装置において送信データを間引くと、クライアント装置への描画情報の品質が悪化するという課題があった。
　本発明の目的は、クライアント装置への画面情報を遅延や欠損なく送信することができるサーバ装置、及び画面転送システムを提供することを目的とする。
　上記目的を達成するために、本発明のサーバ装置は、クライアント装置からネットワークを介して入力データを受信し、前記入力データに対する応答画面の描画命令を前記ネットワークを介して前記クライアント装置に送信するサーバ装置であって、　前記クライアント装置へ送信した前記描画命令を記憶する履歴記憶部と、前記クライアント装置から送信された前記描画命令に欠損が生じたことを通知する通知データを受信する受信部と、前記通知データに応じて前記履歴記憶部から抽出した前記描画命令を再送信することによって前記クライアント装置で描画の破綻が生じるか否かを予測する第１の予測部と、前記第１の予測部によって描画の破綻が生じると予測した場合に、前記履歴記憶部に記憶された描画命令と前記通知データとから描画の破綻が生じないように描画命令を再構築する再構築部と、前記再構築した描画命令を前記クライアント装置に送信する送信部とを備えることを特徴とする。
　本発明によれば、利用者に品質の悪化を意識させずに、クライアント装置における出力応答を遅延や欠損なく画面表示することができる。
（ａ）本発明の第１の実施形態に係るサーバ装置を示す図。 （ｂ）同実施形態に係るクライアント装置を示す図。 （ａ）同実施形態に係る描画命令のフォーマットの例を示す図。 （ｂ）同実施形態に係る描画命令のフォーマットの例を示す図。 （ａ）同実施形態に係るサーバ装置における画面更新生成時の処理のフローチャート。 （ｂ）同実施形態に係るクライアント装置における描画命令受信時の処理のフローチャート。 （ａ）同実施形態に係るサーバ装置における欠損通知受信時の処理のフローチャート。 （ｂ）同実施形態に係る描画命令の履歴の例を示す図。 同実施形態に係る描画命令の実行後の画面表示の推移を示す図。 同実施形態に係るパケット欠損が生じた場合の描画命令の再構築を説明する図。 本発明の第２の実施形態に係る画面転送システムの構成と当該画面転送システムにおけるデータの流れ。 同実施形態に係るクライアント装置における処理のシーケンス図。 （ａ）同実施形態に係るドラッグによるウィンドウ移動のイメージ図。 （ｂ）同実施形態に係るウィンドウ移動の画面更新手順における矩形コピーのイメージ図。 （ａ）同実施形態に係るウィンドウ移動の画面更新手順における背景画像描画のイメージ図。 （ｂ）本発明の第３の実施形態に係る画面共有品質予測部における処理のフローチャート。 （ａ）同実施形態に係る遅延状態の判定方法を説明する図。 （ｂ）同実施形態に係る遅延値の計算方法の一例を説明する図。
　以下、図面を参照しながら本発明の実施形態について詳細に説明する。
（第１の実施形態）
　本実施形態に係る画面転送システムは、図１（ａ）に示すサーバ装置１００と、図１（ｂ）に示すクライアント装置２００とによって構成される。サーバ装置１００とクライアント装置２００は、ネットワーク３００に接続されている。
[サーバ装置１００]
　図１（ａ）に示すサーバ装置１００は、描画命令生成部１０１と、シーケンス番号付加部１０２と、エンコード部１０３と、送信部（以下、描画命令送信部という）１０４と、フレームバッファ１０５と、表示部１０６と、再構築部１０７と、予測部（以下、画面共有品質予測部という）１０８と、履歴記憶部１０９と、履歴取得部１１０と、受信部（以下、欠損通知受信部という）１１１とを備える。
　描画命令生成部１０１は、サーバ装置１００において実行されるＯＳ（Operating System：オペレーティングシステム）および各種アプリケーションの動作状態に応じて描画命令を生成する。描画命令とは、表示画面（デスクトップ）上に最新の描画状態を得るための命令のことである。直前の描画状態が記憶されたフレームバッファ１０５に対し描画命令を適用することにより、最新の描画状態を得ることができる。
　描画命令は、描画命令の種類を表す描画命令種別と、描画する内容の詳細を表わす描画データから構成される。図２（ａ）および図２（ｂ）に、描画命令の例を示す。
　図２（ａ）は、描画命令種別Ｂ１が「ＢＩＴＭＡＰ」の例を示している。この場合、描画データＢ２は、更新する領域の位置を表す領域情報Ｂ２１と、更新する領域の更新後の画像情報Ｂ２２からなる。画像情報Ｂ２２は、デスクトップの一部分に相当する矩形状のビットマップデータ（矩形の各画素における赤緑青３色の値など）である。領域情報Ｂ２１は、デスクトップ上における更新画像の表示位置を示す座標値である。
　図２（ｂ）は、描画命令種別Ｃ１が「ＣＯＰＹＲＥＣＴ」の例を示している。「ＣＯＰＹＲＥＣＴ」とは、フレームバッファ１０５における特定の矩形領域のビットマップデータを、別の位置にコピーすることを示す。この場合、描画データＣ２は、コピー先の領域情報Ｃ２１と、また、コピー元の領域情報Ｃ２２を含んでいる。
　描画命令生成部１０１は、フレームバッファ１０５に対し前記描画命令を適用した後、さらにシーケンス番号付加部１０２に描画命令を出力する。
　シーケンス番号付加部１０２は、シーケンス番号カウント値を格納するための記憶領域（図示せず）を有している。シーケンス番号付加部１０２は、描画命令生成部１０１もしくは再構築部１０７から描画命令を受け取るごとに、前記記憶領域に格納しているシーケンス番号カウント値をその描画命令に付加する。シーケンス番号付加部１０２は、シーケンス番号カウント値を付加するごとに、前記シーケンス番号カウント値を１つインクリメントする。シーケンス番号付加部１０２は、シーケンス番号カウント値を付加した描画命令をエンコード部１０３および履歴記憶部１０９に出力する。
　エンコード部１０３は、シーケンス番号付加部１０２から描画命令を受け取ると、その描画命令に画像圧縮などのエンコード処理を施す。その後、エンコード部１０３は、エンコードされた描画命令を描画命令送信部１０４に出力する。
　描画命令送信部１０４は、エンコードされた描画命令を、通信用のパケットに形成する。その後、描画命令送信部１０４は、生成したパケットをネットワーク３００に送出する。
　フレームバッファ１０５は、表示部１０６の表示画面全体の画面データを記憶する。フレームバッファ１０５は、描画命令生成部１０１から描画命令を受けると、その描画命令の描画命令種別と描画データに応じて、画面データを記憶する記憶領域に新たな画面データを上書する。フレームバッファ１０５の前記記憶領域に上書きされた画面データは、表示部１０６によって表示される。また、フレームバッファ１０５は、再構築部１０７から画面データの取得要求を受け取ると、指定された領域の最新の画面データを再構築部１０７に出力する。
　履歴記憶部１０９は、描画命令を記憶する。履歴記憶部１０９は、シーケンス番号付加部１０２から描画命令を受け取るごとに、シーケンス番号と描画命令とを対応させて記憶する。その結果、履歴記憶部１０９には所定期間の描画履歴が蓄積される。また、履歴記憶部１０９は、再構築部１０７、画面共有品質予測部１０８、履歴取得部１０９から蓄積している描画命令の取得要求を受け取ると、要求に対応する描画命令をそれぞれのユニットへ出力する。
　履歴取得部１１０は、欠損通知受信部１１１からパケットの欠損通知を受け取ると、欠損通知に含まれるシーケンス番号に対応する描画命令を履歴記憶部１０９から取得する。その後、履歴取得部１１０は、画面共有品質予測部１０８にシーケンス番号及び描画命令を出力する。
　画面共有品質予測部１０８は、履歴取得部１１０から描画命令を受け取ると、当該描画命令以降に記録された描画命令を履歴記憶部１０９から取得する。そしてこれらの描画命令をもとにして、クライアント装置２００に対し再送信の処置を行う場合に、クライアント装置２００において描画の破綻が生じるか否かを予測する。画面共有品質予測部１０８は、予測結果と、取得した描画命令、および履歴記憶部１０９から取得した履歴情報の組み合わせを再構築部１０７に出力する。
　再構築部１０７は、画面共有品質予測部１０８から予測結果、描画命令、および履歴情報の組み合わせを受け取ると、予測結果の内容を確認する。予測結果がクライアント装置２００における描画の破綻を示す内容であった場合に、再構築部１０７は、破綻が生じないように再送しようとする描画命令の再構築を行う。再構築部１０７は、再構築した描画命令をシーケンス番号付加部１０２に出力する。
　表示部１０６は、フレームバッファ１０５に格納されている画面データを表示する。欠損通知受信部１１１は、ネットワーク３００を介して欠損通知を受信すると、これを履歴取得部１１０に出力する。
［クライアント装置２００］
　図１（ｂ）に示すクライアント装置２００は、受信部（以下、描画命令受信部という）２０１と、検知部（以下、欠損検知部という）２０２と、デコード部２０３と、描画実行部２０４と、フレームバッファ２０５と、表示部２０６と、送信部（以下、欠損通知送信部という）２０７とを備える。
　描画命令受信部２０１は、ネットワーク３００を介して描画命令を受信する。欠損検知部２０２は、シーケンス番号カウント値を格納するための記憶領域（図示せず）を有している。欠損検知部２０２は、描画命令受信部２０１から描画命令を受け取ると、その描画命令に付加されたシーケンス番号を記憶し、受信した描画命令の描画データに欠損が生じているか否かを検知する。欠損検知部２０２は、欠損を検知した場合には、欠損したシーケンス番号を欠損通知送信部２０７に出力する。また、欠損したシーケンス番号とともに当該描画命令をデコード部２０３に出力する。一方、欠損を検知しなかった場合には、欠損通知送信部２０７には何も通知せず、欠損検知部２０２は当該描画命令をデコード部２０３に出力する。
　デコード部２０３は、描画命令を受け取ると、その描画命令にデコード処理を施す。その後、デコードされた描画命令を描画実行部２０４に出力する。
　描画実行部２０４は、デコード後の描画命令を受け取ると、その描画命令に含まれる描画命令種別と描画データに応じて、フレームバッファ２０５の画面データに新たな画面データを上書きする。
　フレームバッファ２０５は、表示部２０６の表示画面全体の画面データを記憶する。表示部２０６は、フレームバッファ２０５に格納されている画面データを表示する。欠損通知送信部２０７は、欠損検知部２０２からシーケンス番号を受け取ると、これをパケット化する。その後、欠損通知として当該パケットをネットワーク３００を介してサーバ装置１００に送出する。
［画面転送システムにおける処理の流れ］
　以下に、本実施形態に係る画面転送システムの動作を説明する。本実施形態における画面転送システムでは、サーバ装置１００とクライアント装置２００がネットワーク３００を介して接続されている。サーバ装置１００とクライアント装置２００の間は、ネットワーク接続が完了して画面転送を実施している状態にあるものとする。
（１）画面更新処理（サーバ装置１００）
　図３（ａ）は、サーバ装置１００の画面更新処理のフローチャートである。図１（ａ）及び図３（ａ）を参照しながら、サーバ装置１００における画面更新の処理を説明する。
　画面転送を実施している状態にあるとき、描画命令生成部１０１は、サーバ装置１００において実行されるＯＳおよび各種アプリケーションの動作状態の変化により、クライアント装置２００へ提示する視覚的情報に更新があるかどうかをチェックする（ステップＳ１０１）。
　画面更新がある場合は（ステップＳ１０１のＹＥＳ）、描画命令生成部１０１は、描画命令の生成を行う（ステップＳ１０２）。描画命令生成部１０１は、更新の前後の視覚的情報の差分を任意の方法で抽出することで、上述したような「ＢＩＴＭＡＰ」や「ＣＯＰＹＲＥＣＴ」などの種別の描画命令を生成する。あるいは別の方法として、描画命令生成部１０１は、ＯＳが発行する描画命令を直接フックすることにより、描画命令を得てもよい。
　描画命令生成部１０１は、生成した描画命令をフレームバッファ１０５に入力する。フレームバッファ１０５は、内部の記憶領域のうち、描画命令の領域情報に示す領域に描画命令の描画データ（新たな画面データ）を上書する。表示部１０６は、フレームバッファ１０５に記憶された画面データを表示する。また、描画命令生成部１０１は、生成した描画命令をシーケンス番号付加部１０２に出力する。その後、処理の流れはステップＳ１０３に進む。
　描画命令を受け取ると、シーケンス番号付加部１０２は、内部のシーケンス番号記憶領域に格納しているシーケンス番号カウント値を参照する。シーケンス番号付加部１０２は、このシーケンス番号カウント値をシーケンス番号として、受信した描画命令に付加する（ステップＳ１０３）。
　シーケンス番号付加部１０２では、画面転送の開始の際にシーケンス番号カウント値をゼロにリセットする。その後は、ステップＳ１０３の処理でシーケンス番号の付加を行うごとに、シーケンス番号カウント値を１ずつインクリメントする。シーケンス番号カウント値が規定値（例えば、２の３２乗－１）を超えたら、再びゼロにリセットする。その後、処理の流れはステップＳ１０４に進む。
　シーケンス番号付加部１０２は、描画命令とシーケンス番号の対を履歴記憶部１０９に出力する。履歴記憶部１０９は、内部の記憶領域に描画命令とシーケンス番号の対を描画履歴として記憶する（ステップＳ１０４）。
　シーケンス番号付加部１０２は、履歴記憶部１０９から記憶が完了した通知を受け取ると、シーケンス番号が付加された描画命令をエンコード部１０３に出力する。
　図４（ｂ）は、履歴記憶部１０９に記憶される描画履歴の一例である。履歴記憶部１０９は、描画命令のすべての情報を記憶する必要はない。本実施形態では、シーケンス番号と、それに対応する描画命令種別（「ＣＯＰＹＲＥＣＴ」、「ＢＩＴＭＡＰ」など）とを記憶する。描画命令種別が「ＣＯＰＹＲＥＣＴ」の場合は、さらに、領域情報Ｃ２１とコピー元の領域情報Ｃ２２を記憶する。また、描画命令種別が「ＢＩＴＭＡＰ」の場合は、領域情報Ｂ２１のみが記憶される。すなわち、「ＢＩＴＭＡＰ」の場合は、画像情報Ｂ２２のビットマップデータは記憶されない。
　エンコード部１０３は、描画命令を受け取ると、描画命令種別が「ＢＩＴＭＡＰ」の場合には画像情報に対しエンコード処理を施す。エンコード部１０３はビットマップデータに対して、例えばＪＰＥＧ（Joint Photographic Experts Group）やｇｚｉｐ（GNU ZIP）などの任意のアルゴリズムによる圧縮を行う。次に、エンコード部１０３は、エンコード後の描画命令を描画命令送信部１０４に出力する。
　描画命令送信部１０４は、描画命令にＵＤＰ（User Datagram Protocol）ヘッダやＩＰ（Internet Protocol）ヘッダを付与するなど、通信用の描画命令パケットに変換する。その後、描画命令送信部１０４は、描画命令パケットをネットワーク３００に送出する。
（２）描画命令パケットの受信時（クライアント装置２００）
　次に、図１（ｂ）及び図３（ｂ）を参照しながら、クライアント装置２００における描画命令パケット受信時の動作を説明する。図３（ｂ）は、クライアント装置２００における描画命令パケット受信時のフローチャートである。
　まず、描画命令受信部２０１は、ネットワーク３００から描画命令パケットを受信すると、そのパケットからＵＤＰヘッダやＩＰヘッダを除外し、描画命令を取り出す（ステップＳ３０１）。その後、描画命令受信部２０１は、取り出した描画命令を欠損検知部２０２に出力する。
　欠損検知部２０２は、描画命令受信部２０１から描画命令を受け取ると、描画命令中のシーケンス番号を取り出す。その後、欠損検知部２０２は、取得したシーケンス番号と、内部のシーケンス番号カウント値記憶領域（図示せず）に記憶しているシーケンス番号カウント値とを比較し、両者が一致するか否かを調べる（ステップＳ３０２）。
　両者の比較結果は、以下の３つのケースに分けられる。第１のケースは、「描画命令中のシーケンス番号とシーケンス番号カウント値が一致する場合（＝）」である。第２のケースは、「描画命令中のシーケンス番号とシーケンス番号カウント値が一致せず、かつ、描画命令中のシーケンス番号がシーケンス番号カウント値よりも大きい場合（＞）」である。第３のケースは、「描画命令中のシーケンス番号とシーケンス番号カウント値が一致せず、かつ、描画命令中のシーケンス番号がシーケンス番号カウント値よりも小さい場合（＜）」である。
　まず、第１のケースの場合では、欠損検知部２０２は、欠損は生じていないと判定する。そして、欠損検知部２０２は、受信した描画命令をデコード部２０３に出力する。その後、処理の流れはステップＳ３０５に進む。
　デコード部２０３は描画命令を受信すると、その描画命令にエンコード処理が施されている場合には対応するデコード処理を施す。その後、デコードした描画命令を描画実行部２０４に出力する。
　描画実行部２０４は、描画命令に従って描画命令中の画面データをフレームバッファ２０５に記憶する。その後、表示部２０６がフレームバッファ２０５から記憶された画面データを取り出し、画面に表示する（ステップＳ３０５）。
　次に、第２のケースの場合では、欠損検知部２０２は、欠損が生じたと判定する。例えば、内部で保有するシーケンス番号カウント値が「１００」で、描画命令中のシーケンス番号が「１０３」であったとすると、欠損検知部２０２は、シーケンス番号「１００」，「１０１」，「１０２」に相当する描画命令パケットに欠損が生じたと判定する。
　そして、欠損検知部２０２は、欠損が生じた描画命令パケットのシーケンス番号（上述の例では「１００」，「１０１」，「１０２」）を欠損通知送信部２０８に出力する。
　欠損通知送信部２０８は、欠損検知部２０２から通知されたシーケンス番号にＵＤＰヘッダやＩＰヘッダ等など通信に必要な情報を付加し、サーバ装置１００に欠損を通知する欠損通知パケットを形成する。その後、欠損通知送信部２０８は、欠損通知パケットを送信する（ステップＳ３０３）。
　欠損検知部２０２は、欠損通知パケットの送信が完了すると、描画命令受信部２０１より入力された描画命令と、欠損が生じた描画命令のシーケンス番号の組み合わせをデコード部２０３に出力する。その後、処理の流れはステップＳ３０５に進む。
　デコード部２０３は描画命令を受信すると、その描画命令にエンコード処理が施されている場合には対応するデコード処理を施す。その後、デコードした描画命令を描画実行部２０４に出力する。
　描画実行部２０４は、描画命令に従って描画命令中の画面データをフレームバッファ２０５に記憶する。その後、表示部２０６がフレームバッファ２０５から記憶された画面データを取り出し、画面に表示する（ステップＳ３０５）。
　また、第３のケースの場合では、欠損検知部２０２は、以前に受信した描画命令を重複して受信したと判断する。そして、欠損検知部２０２は、受信した描画命令を破棄し、処理を終了する（ステップＳ３０４）。
　上記第１乃至第３のいずれのケースであっても、欠損検知部２０２では描画命令中のシーケンス番号とシーケンス番号カウント値とを比較した後、内部のシーケンス番号カウント値に描画命令中のシーケンス番号が上書きされ、更新される。
（３）欠損通知パケットの受信時（サーバ装置１００）
　図１（ａ）及び図４（ａ）を参照しながら、サーバ装置１００における欠損通知パケットの受信時の動作を説明する。図４（ａ）は、サーバ装置１００における欠損通知パケット受信時のフローチャートである。
　まず、欠損通知受信部１１１は、クライアント端末２００からの欠損通知パケットを受信すると、その欠損通知パケットに含まれる１つ又は複数のシーケンス番号を取り出す（ステップＳ２０１）。そして、そのシーケンス番号を、履歴取得部１１０に出力する。
　履歴取得部１１０はシーケンス番号を受け取ると、履歴記憶部１０９から当該シーケンス番号に対応する描画命令を取得する（ステップＳ２０２）。履歴記憶部１０９には、例えば図４（ｂ）に示すような描画命令の履歴が記憶されている。履歴記憶部１０９は要求されたシーケンス番号に対する履歴情報を出力する。履歴情報には、シーケンス番号に対応する描画命令種別、及び領域情報を少なくとも有する。
　履歴取得部１１０は、取得した描画命令の履歴情報を、画面共有品質予測部１０８に出力する。
　画面共有品質予測部１０８は、履歴情報を受け取ると、履歴記憶部１０９からシーケンス番号以降の描画命令の履歴情報をすべて取得する。次に、画面共有品質予測部１０８は、後述する予測ルーチンに従って欠損した描画命令の再送信を行った場合に、クライアント装置２００における画面状態に描画の破綻が生じるか否かを予測する。
　ここでは、説明を簡潔にするために、描画命令種別を「ＢＩＴＭＡＰ」と「ＣＯＰＹＲＥＣＴ」の２種類のみとする。また、欠損した描画命令Ｌの描画先の領域情報をＤ［Ｌ］と表す。描画命令種別が「ＣＯＰＹＲＥＣＴ」の場合、コピー元の領域をＳ［Ｌ］と表す。以上の表記を用いて、欠損した描画命令を、「ＢＩＴＭＡＰ：Ｄ［Ｌ］」または「ＣＯＰＹＲＥＣＴ：Ｓ［Ｌ］→Ｄ［Ｌ］」と表記する。さらに、当該描画命令以降ｉ番目に発生した描画命令の履歴を「ＢＩＴＭＡＰ：Ｄ［ｉ］」または「ＣＯＰＹＲＥＣＴ：Ｓ［ｉ］→Ｄ［ｉ］」と表記する。
　画面共有品質予測部１０８は、欠損した描画命令の再送信した場合にクライアント装置２００における画面状態に描画の破綻が生じるか否かを予測するために、以下の予測ルーチンを実行する（ステップＳ２０３）。以下において、「ＴＲＵＥ」は「描画の破綻が生じる」ことを意味し、「ＦＡＬＳＥ」は「描画の破綻が生じない」ことを意味する。
＜予測ルーチン＞
（１）ｉ：＝１
（２）ｉ番目の描画命令が存在しなければ「ＦＡＬＳＥ」を出力して終了
（３）ｉ番目の描画命令がＢＩＴＭＡＰなら（５）へ遷移
（４）Ｄ［Ｌ］とＳ［ｉ］が共通部分を持つ場合、「ＴＲＵＥ」を出力して終了
（５）Ｄ［Ｌ］とＤ［ｉ］が共通部分を持つ場合、「ＴＲＵＥ」を出力して終了
（６）欠損した描画命令ＬがＢＩＴＭＡＰなら（８）へ遷移
（７）Ｓ［Ｌ］とＤ［ｉ］が共通部分を持つ場合、「ＴＲＵＥ」を出力して終了
（８）ｉ：＝ｉ＋１　の後で（２）へ遷移
　画面共有品質予測部１０８は、＜予測ルーチン＞を実行することにより、クライアント装置２００における描画の破綻の有無を予測することができる。画面共有品質予測部１０８は、予測結果（「ＴＲＵＥ」または「ＦＡＬＳＥ」）と、欠損した描画命令とを再構築部１０７に出力する。
　再構築部１０７は、予測結果および欠損した描画命令が入力されると、予測結果を確認する。予測結果が「ＦＡＬＳＥ」の場合（ステップＳ２０４の“ＮＯ”）、欠損した描画命令の再送信を行ってもクライアント装置２００における画面状態に描画の破綻が生じない。このとき再構築部１０７は、描画命令が「ＢＩＴＭＡＰ」ならば、領域情報Ｂ２１に対応する最新のフレームバッファ１０５の描画データを取得する。取得した最新のフレームバッファ１０５の描画データをビットマップデータとした上で、欠損した描画命令をシーケンス番号付加部１０２に出力する（ステップＳ２０６）。
　一方、描画命令種別が「ＣＯＰＹＲＥＣＴ」ならば、再構築部１０７は、この描画命令をそのままシーケンス番号付加部１０２に出力する（ステップＳ２０６）。これ以降のシーケンス番号付加部１０２の動作は、前述の内容と同一である（ステップＳ２０７）。
　なお、このとき描画命令に付加されるシーケンス番号は、欠損したシーケンス番号ではなく、新規の番号が割り当てられる。
　一方、予測結果が「ＴＲＵＥ」の場合（ステップＳ２０４の“ＹＥＳ”）、欠損した描画命令の再送信を単純に行うと、クライアント装置２００における描画に破綻が生じてしまう。そこで再構築部１０７は、以下の再構築ルーチンに従って描画命令の再構築を行う（ステップＳ２０５）。
　まず、再構築部１０７は、欠損した描画命令以降に発生したすべての描画命令の履歴情報を履歴記憶部１０９から取得する。その後、以下の再構築ルーチンを実行する。当該描画命令以降ｉ番目に発生した描画命令の履歴情報を「ＢＩＴＭＡＰ：Ｄ［ｉ］」または「ＣＯＰＹＲＥＣＴ：Ｓ［ｉ］→Ｄ［ｉ］」と表記する。なお、以下において、ＢＩＴＭＡＰ描画命令に対してはＳ［ｉ］は空集合として扱う。ここで出力用リストとは、再構築部が破綻を予測する際に、描画命令を一時的に格納するリストであって、本ステップ（Ｓ２０５）
にて描画命令を格納し、後のステップ（Ｓ２０６およびＳ２０７）で参照される。
＜再構築ルーチン＞
（１）出力用リストにＬを追加する
（２）ｉ：＝１
（３）ｉ番目の描画命令が存在しなければ（９）へ遷移
（４）出力用リストのすべての要素Ａについて（５）～（７）を実行する
（５）Ｄ［Ａ］とＳ［ｉ］が共通部分を持つ場合、出力用リストの最後尾に　 ＢＩＴＭＡＰ：Ｄ［ｉ］を追加する
（６）Ｄ［Ａ］とＤ［ｉ］が共通部分を持つ場合、Ａの描画領域、すなわちＤ［Ａ］をＤ［Ａ］－Ｄ［ｉ］で置き換える。ここでＤ［Ａ］－Ｄ［ｉ］とはＤ［Ａ］の領域からＤ［Ａ］とＤ［ｉ］の共通部分を除外した部分領域を指す
（７）Ｓ［Ａ］とＤ［ｉ］が共通部分を持つ場合、出力用リストの最後尾にＢＩＴＭＡＰ：Ｄ［ｉ］（Ｓ［Ａ］×Ｄ［ｉ］）を追加する。ここでＳ［Ａ］×Ｄ［ｉ］とはＳ［Ａ］とＤ［ｉ］領域の共通部分を指す。またＤ［ｉ］（Ｓ［Ａ］×Ｄ［ｉ］）とは、Ｓ［Ａ］とＤ［ｉ］領域の共通部分に対応するコピー先領域の部分を指す
（８）ｉ：＝ｉ＋１　の後で（３）へ遷移
（９）出力用リストが開始時と変化がなければ「ＴＲＵＥ」（破綻が生じる）、変化があれば「ＦＡＬＳＥ」（破綻が生じない）を出力する
　上記の再構築ルーチンの終了後、出力用リストに記された描画命令が、再構築後の描画命令となる。
　再構築部１０７は、当該出力用リスト内の描画命令を先頭から順にチェックしていく。再構築した描画命令が「ＢＩＴＭＡＰ」ならば、再構築部１０７は領域情報Ｂ２１に対応する最新のフレームバッファ１０５の描画データを取得する。取得した最新のフレームバッファ１０５の描画データをビットマップデータ（画像情報Ｂ２２）とした上で、再構築した描画命令をシーケンス番号付加部１０２に出力する（ステップＳ２０６）。
　一方、描画命令種別が「ＣＯＰＹＲＥＣＴ」ならば、再構築部１０７は、この描画命令をそのままシーケンス番号付加部１０２に出力する（ステップＳ２０６）。これ以降のシーケンス番号付加部１０２の動作は、前述の内容と同一である（ステップＳ２０７）。
［再構築の具体例１］
　上記で説明した画面共有品質予測部１０８と再構築部１０７の動作について、具体例を用いて以下に説明する。図４（ｂ）は、ある時間内に発生した一連の描画命令の履歴情報の例を示す。
　デスクトップにおいてウィンドウをいったん描画した後、ウィンドウ位置が右下方向に移動した状況を想定する。図４（ｂ）の例では、４個の描画命令が、「ＢＩＴＭＡＰ」→「ＣＯＰＹＲＥＣＴ」→「ＢＩＴＭＡＰ」→「ＢＩＴＭＡＰ」の順に発生したとしている。
　この一連の描画命令の実行結果を描画命令毎に表すと、図５（ａ）乃至（ｅ）のようになる。すなわち、サーバ装置１００が送信したこれらの描画命令が、１つも欠損なくクライアント装置２００で受信されると、図５（ａ）乃至（ｅ）と同じ工程で作成された画面データがクライアント装置２００の表示部２００６に表示される。
　以上の一連の描画命令において、シーケンス番号１の描画命令が伝送途中に欠損した場合の画面共有品質予測部１０８と再構築部１０７の動作を、図６を用いて説明する。
　例えば、シーケンス番号１が欠損した場合、クライアント装置２００は、はじめにシーケンス番号２の描画命令を受信することになる。このとき、クライアント装置２００の欠損検知部２０２は、シーケンス番号１の欠損を検知する。その後、欠損通知送信部２０７とサーバ装置１００の欠損通知受信部１１１を通じて、サーバ装置１００の履歴取得部１１０にシーケンス番号１の欠損を通知する。
　サーバ装置１００の履歴取得部１１０は、シーケンス番号１に対応する履歴情報としてＢＩＴＭＡＰ：（７０，７０，３５０，２８０）を取得すると、これを画面共有品質予測部１０８に渡す。
　画面共有品質予測部１０８は、履歴記憶部１０９から、シーケンス番号１以降のシーケンス番号２，シーケンス番号３，シーケンス番号４の描画命令の履歴情報を取得すると、上述の＜予測ルーチン＞を用いてクライアント装置２００における描画に破綻が生じるか否かを予測する。図６の例では、シーケンス番号１の描画領域（７０，７０，３５０，２８０）と、シーケンス番号２のコピー元領域（７０，７０，３５０，２８０）とは共通部分を持つため、予測ルーチンの結果は「ＴＲＵＥ」（破綻が生じる）となる。
　次に、再構築部１０７は、歴記憶部１０９からの予測結果を受けて、描画命令の再構築を行う。上述の＜再構築ルーチン＞を用いて、描画に破綻が生じないような描画命令を構成することが可能である。ルーチンの細かな実行の様子は説明を省略する。図６の例では、＜再構築ルーチン＞を実行した結果、再構築後の描画命令はＢＩＴＭＡＰ：（２８０，２１０，５６０，４２０）となる。
　再構築部１０７は、この領域に対応する最新のフレームバッファ１０５の描画データを取得し、これをビットマップデータとした上で、この描画命令をシーケンス番号付加部１０２に出力する。シーケンス番号付加部１０２は、この描画命令に新たなシーケンス番号５を付加して（図６（ａ）参照）、ネットワーク３００を介してクライアント端末２００に送信する。
［再構築の具体例２］
　次に、前記シーケンス番号２の描画命令が欠損した場合の再構築の例を、図６を用いて以下に説明する。
　シーケンス番号２の描画命令が伝送途中に欠損した場合、クライアント装置２００は、シーケンス番号１、３の順に描画命令を受信することになる。従って、欠損検知部２０２は、シーケンス番号カウンタ値に基づいて、シーケンス番号２の欠損を検知する。欠損検知部２０２は、欠損通知送信部２０７、ネットワーク３００、サーバ装置１００の欠損通知受信部１１１を通じて、サーバ装置１００の履歴取得部１１０にシーケンス番号２の欠損を通知する。
　履歴取得部１１０は、シーケンス番号２に対応する履歴として、履歴記憶部１０９から描画命令「ＣＯＰＹＲＥＣＴ：（７０，７０，３５０，２８０）→（２８０，２１０，５６０，４２０）」を取得する。履歴取得部１１０は、取得した描画命令を画面共有品質予測部１０８に渡す。
　画面共有品質予測部１０８は、履歴記憶部１０９からシーケンス番号２以降のシーケンス番号３，及びシーケンス番号４の描画命令の履歴情報を取得する。その後、上述の＜予測ルーチン＞を用いて、クライアント装置２００において描画に破綻が生じるか否かを予測する。図６の例では、シーケンス番号２のコピー元領域（７０，７０，３５０，２８０）と、シーケンス番号３の描画領域（７０，７０，３５０，２１０）とは共通部分を持つため、予測ルーチンの結果は「ＴＲＵＥ」となる。
　次に、再構築部１０７は、上述の＜再構築ルーチン＞を用いて、描画命令の再構築を行う。再構築ルーチンを実行した結果、再構築後の描画命令として出力用リストには、「ＣＯＰＹＲＥＣＴ：（７０，７０，３５０，２８０）→（２８０，２１０，５６０，４２０）」、「ＢＩＴＭＡＰ：（２８０，２１０，５６０，３５０）」、「ＢＩＴＭＡＰ：（２８０，３５０，４９０，４２０）」の３個が得られる。
　再構築部１０７は、この出力用リスト内の描画命令について、先頭から順番に、「ＢＩＴＭＡＰ」の描画命令であれば領域に対応する最新のフレームバッファの描画データを取得した後で、シーケンス番号付加部１０２に出力する。シーケンス番号付加部１０２は、この描画命令に新たなシーケンス番号５，６，７を付加して送信する（図６（ｂ），（ｃ），（ｄ）参照）。
　以上の手順によって得られる再構築後の描画命令により、クライアント装置２００において描画の破綻が回避され、欠損が生じない場合と同一のデスクトップ状態が得られる。
　なお、本実施形態に記載した＜予測ルーチン＞および＜再構築ルーチン＞は、あくまでも動作のための一例にすぎない。クライアント装置２００における描画の破綻が回避できるならば、これ以外の任意のルーチンを用いても良い。
　また、今回は描画命令種別を「ＢＩＴＭＡＰ」と「ＣＯＰＹＲＥＣＴ」の２種類のみに限って説明したが、これ以外の種類の描画命令が混在した環境であっても、同じようにルーチンを構成することが可能である。例えば、デスクトップ上の矩形領域を対象に描画処理を行う任意の描画命令は、「ＢＩＴＭＡＰ」の場合と同様にルーチンを構成することができる。
　以上のように、本実施形態におけるサーバ装置１００は、過去に送出した描画命令の履歴を参照することで、クライアント装置２００における描画の破綻を予測することができる。また、クライアント装置２００において描画が破綻すると予測された場合には、サーバ装置１００が描画命令に再構築を施すことで、クライアント装置２００における描画の破綻を回避することができる。これにより、利用者に品質の悪化を意識させずに、クライアント装置２００における出力応答を遅延や欠損なく画面表示することができる。
　また、本実施形態のサーバ装置１００は、破綻の回避に必要な最小限の描画命令のみを構成して送信する。従って、例えばデスクトップ全体の最新の描画状態を取得して送出するといった場合と比べて、サーバ装置１００におけるエンコードや送信の処理負荷が低減される。また、ネットワーク帯域の消費量も少なくて済むという利点がある。
　さらに、本実施形態のクライアント装置２００は、描画命令の受信に欠損を検知したとき、その欠損通知に対する応答を待つことなく、以降に受信した描画命令を用いて、引き続き描画実行する。従って、例えば伝送プロトコルにＴＣＰ（Transmission Control Protocol）を用いた画面転送システムのように、欠損が生ずると以降の描画を中断してサーバ装置からの再送信を待機するという場合と比べて、サーバ装置１００で実行された描画がすみやかにクライアント装置２００において反映されるというリアルタイム性を確保できる利点がある。
(第２の実施形態)
　 前述した第１の実施形態では、画面共有品質予測部１０８と再構築部１０７を画面転送システムのサーバ装置１００に備える構成としたが、第２の実施形態では、クライアント装置２００に備える構成とする。図７は、第２の実施形態に係る画面転送システムの構成を示す図である。
　本実施形態に係る画面転送システムは、図７に示すサーバ装置１０００とクライアント装置２０００とによって構成される。図７はまた、画面転送システムにおけるデータの流れを矢印によって示している。破線の矢印は通常（比較例）のデータの流れを示し、実線の矢印は本実施例特有のデータの流れを示す。以下に例として、クライアント装置２０００の画面に表示されたウィンドウをドラッグにより移動させる場合を説明する。
　まず、通常（比較例）のデータの流れを説明する。比較例となる通常の画面転送システムでは、クライアント装置２０００の利用者が、ペン、マウスなどで入力するポインタ入力や、キーボードなどで入力したキー入力を、入力部２００１が受け付ける。クライアント装置２０００は、そのポインタ入力やキー入力といった入力データを、通信部２００２、ネットワーク３００を介して、サーバ装置１０００に送信する。
　サーバ装置１０００の通信部１００１は、入力データを受信する。その後、入力データを入力処理部１００２へ渡す。入力処理部１００２は、入力データをアプリケーション／ＯＳ １００３に渡す。ＯＳやアプリケーションでは、入力データに応じたプログラム実行が行なわれ、画面に処理結果を示す出力表示データが表示される。（処理内容によっては、画面に出力表示されないこともある。)画面への出力表示データは、アプリケーション／ＯＳ １００３から画面の描画命令として、描画転送部１００４に出力される。描画転送部１００４は、当該描画命令を、通信部１００１、ネットワーク３００を通じてクライアント装置２０００に送信する。
　クライアント装置２０００の通信部２００２は、サーバ装置１０００からの描画命令を受信する。その後、表示部２００３において描画命令が実行され、画面に出力表示データが表示される。
　一方、本実施形態では、クライアント装置２０００において、入力部２００１からのポインタ入力と、通信部２００２からの矩形コピー描画命令（詳細は後述する）をトリガとして、画面共有品質予測部２００４が起動される。そして、予測部（以下、画面共有品質予測部という）２００４は、クライアント装置２０００における出力表示に欠損が発生するであろうと予測する。何故ならば、ドラッグによる矩形コピーは、多量の画面更新データを発生させる操作であるので、多量の通信を誘発する可能性がある。これにより、パケットの欠損による描画の破綻、操作性悪化などを引き起こす可能性が高いためである。
　上記の予測に基づき、画面共有品質予測部２００４は、以後、入力されたポインタ入力をサーバ装置１０００へ転送しないように、遮断部（以下、転送遮断部という）２００６に指令する。転送遮断部２００６は、画面共有品質予測部２００４からの指令を受け取ると、入力部２００１から受け取ったポインタ入力のデータをそのまま破棄する。
　また、画面共有品質予測部２００４は、構築部（以下、再構築部という）２００５に対し描画命令の再構築を指令する。その指令を受け取ると、再構築部２００５はポインタ入力を画面の矩形コピー描画命令に再構築し、表示部２００３へ渡す。その後、表示部２００３において矩形コピー描画命令が実行され、画面に出力が表示される。
　以降、クライアント装置２０００において、入力部２００１から連続してポインタ入力される場合、再構築部２００５はドラッグの移動に応じて矩形コピー描画命令を再構築し、表示部２００３へ渡す。
　入力部２００１からポインタ入力がなくなった際には、画面共有品質予測部２００４は転送遮断部２００６と再構築部２００５にその旨を通知する。この通知により、転送遮断部２００６では入力データを破棄する動作を終了する。また、再構築部２００５は、矩形コピー描画命令の再構築を終了する。
　その後、転送遮断部２００６は、最後のドラッグ入力を通信部２００２を介してサーバ装置１０００に送信し、通常動作に戻る。
　上述した本実施形態の処理の流れを、図８を用いて具体的に説明する。図８は、クライアント装置２０００の動作を示す図である。
　まず、入力部２００１から、ポインタ入力TIP[x11,y11]が入力される。ここで、TIPとは、ペン入力におけるペンのタッチを意味し、座標 [x11, y11] にペンがタッチされたことを意味する。あるいは、マウスの場合には座標[x11, y11]にて左ボタンが押されたことを意味する。
　画面共有品質予測部２００４はポインタ入力を受け、ペンのタッチが開始されたことを検知する。そして、そのポインタ入力を転送遮断部２００６を介して通信部２００２へ渡す。
　次に、入力部２００１からポインタ入力TIP[x12,y12]が入力される。画面共有品質予測部２００４は、ペンがタッチされたまま座標が移動していることから、ドラッグが行なわれたことを検知する。そして、そのポインタ入力を転送遮断部２００６を介して通信部２００２へ渡す。
　その後、上述した処理によってサーバ装置１０００から、ウィンドウのドラッグによる画面更新データ３００１，３００２が送信されてくる。画面更新データ３００１は、矩形コピー描画命令である。画面更新データ３００２は、背景画像描画命令である。
　例えば、クライアント装置２０００にて、図９（ａ）に示すようなウィンドウの移動（ドラッグ）を行ったとする。例えば、ウィンドウのサイズは３２０×２００である。図９（ａ）に示すようなウィンドウの移動に対処するためには、図９（ｂ）に示す矩形コピーの処理と、その後に図１０（ａ）に示す背景画像描画の処理を実施する必要がある。そのため、サーバ装置１０００から矩形コピー描画命令３００１及び背景画像描画命令３００２の２つの画面更新データがクライアント装置２０００に送信されてくる。
　画面共有品質予測部２００４は、画面更新データを受信すると、入力されたポインタ入力[x12,y12]が、起点 [x22,y22]から３２０×２００ピクセルの矩形内に入っているかどうかを判定する。ここでは、矩形内に入っていると判定したものとして説明する。
　画面共有品質予測部２００４は、上記の矩形内に入っているとの判定に基づき、クライアント装置２０００における出力画面表示に欠損が発生するであろうと予測する。画面共有品質予測部２００４は、その予測に基づき転送遮断部２００６へ遮断開始の指令３００３を送る。
　転送遮断部２００６は、画面共有品質予測部２００４からの指令を受け取り、以後、受け取るデータの転送を停止する。
　一方、通信部２００６は、サーバ装置１０００から送られてきた画面更新データ３００１(矩形コピー [x21,y21](320x200)-[x22,y22])と、画面更新データ３００２(背景画像描画)を表示部２００３に送る。表示部２００３は、受け取った画面更新データの処理を実行し、表示を出力する。
　次に、入力部２００１から次のポインタ入力(TIP[x13,y13])が入力されると、画面共有品質予測部２００４は再構築部２００５に命令再構築の指令３００４を出す。
　再構築部２００５は、命令再構築の指令３００４を受信すると、直前のポインタ入力(TIP[x12,y12])と、画面更新データ３００１(矩形コピー [x21,y21](320x200)-[x22,y22])に基づき、x23 = x22 + x13 - x12, y23 = y22 + y13 - y12 として、画面更新データ３００５(矩形コピー [x22,y22](320x200)-[x23,y23])を生成する。そして、生成した画面更新データ３００５を表示部２００３に送る。表示部２００３は、画面更新データ３００５に従って表示処理を行う。
　一方、転送遮断部２００６は、ポインタ入力(TIP[x13,y13])を受け取るが、サーバ装置１０００には転送せずに、最新のポインタ入力として保持する。以降、入力部２００１から、次のポインタ入力(TIP[x14,y14])、次の次のポインタ入力(TIP[x18,y18])が入力された場合も同様の動作を行う。
　その後、入力部２００１から、次のポインタ入力３００６(unTIP[x19,y19])が入力される。unTIPは、ペンのタッチが離されたことを意味する。つまり、これまで行なわれていたドラッグ操作が、座標[x19,y19]で終了したことを意味する。
　従って、画面共有品質予測部２００４は、転送遮断部２００６へ遮断終了の指令３００７を送信する。転送遮断部２００６は、遮断終了の指令３００７を受信すると、最後のポインタ入力(unTIP[x19,y19])を通信部２００２を介してサーバ装置１０００へ転送する。
　サーバ装置１０００は、前回にクライアント装置２０００から受信したポインタ入力TIP[x12,y12]の実行状態から、今回クライアント装置２０００から受信したポインタ入力(unTIP[x19,y19])の実行状態に遷移するまでの処理を行う。その結果、出力される画面更新データ３００８、３００９をクライアント装置２０００へ送信する。
　クライアント装置２０００は、画面更新データ３００８、３００９を受信し、当該処理を実行する。以降、クライアント装置２０００は、本シーケンス開始時と同様の状態に戻る。
　以上のように、本実施形態におけるクライアント装置２０００は、ドラッグ操作により大量の画面更新データが発生すると予測した場合、ドラッグ操作に関するポインタ入力をサーバ装置１０００に送信せず、内部に保有する画像データを利用して出力画面を表示する。これにより、クライアント装置２０００とサーバ装置１０００間の通信量を少なく抑えることができ、ネットワークの混雑を抑制できる。その結果、クライアント装置２０００において、パケットの遅延や欠損による描画の破綻を回避することができる。
（第３の実施形態）
　第３の実施形態は、第２の実施形態と同様に、画面共有品質予測部１０８と再構築部１０７を画面転送システムのクライアント装置に備えるものである。
　本実施例では、ネットワーク品質が悪化して、クライアント装置における描画実行が遅延した場合、クライアント装置に表示されるマウスポインタカーソル（以下、カーソルという)の形状を、処理待ち中であることを示す「砂時計マーク」に変更する。これにより、画面転送システムの利用者に対し、ネットワークに起因する処理の遅延が発生していることを正しく通知する。その結果、利用者のストレスや、思わぬ誤操作の原因を取り除くことができる。
　本実施形態に係る画面転送システムは、第２の実施形態と同様に、図７に示すサーバ装置１０００とクライアント装置２０００とによって構成される。また、データの流れも、第２の実施形態と同様に図７に示す通りである。従って、本実施形態に特有の画面共有品質予測部２００４における予測方法と、再構築部２００５の処理内容を以下に説明する。
　まず、本実施形態における画面共有品質予測部２００４について説明する。
　画面共有品質予測部２００４は、通信部２００２からネットワーク３００の品質を示すネットワーク情報を取得する。画面共有品質予測部２００４は、取得したネットワーク情報に基づき、ネットワーク３００において遅延が発生しているか否かを判定する。当該判定結果に応じて、再構築部２００５に対して、表示部２００３に描画するカーソルの画像（以下、カーソルイメージ情報という）を指定する。取得するネットワーク情報、および、それに基づいて遅延発生を判断する方法については後述する。
　次に、本実施形態における再構築部２００５について説明する。再構築部は、実施例１及び２で述べた機能に加え、以下の機能も有する。
　再構築部２００５は、入力部２００１から、画面共有品質予測部２００４を介して、カーソルの位置情報（ボタン押下情報等も含む。以下同様。)を通知され、記憶する。また、再構築部２００５は、画面共有品質予測部２００４から、カーソルイメージ情報を通知され、記憶する。あるいは、再構築部２００５は、画面共有品質予測部２００４からの要求に応じて、カーソル位置に描画するカーソルイメージ情報を決定する。この場合、描画命令にて指定されているカーソルイメージ情報を上書き更新してもよい。
　以下に、図１０（ｂ）を用いて本実施形態の画面共有品質予測部２００４の動作を説明する。図１０（ｂ）は、画面共有品質予測部２００４の動作を示すフローチャートである。
　まず、画面共有品質予測部２００４は、通信部２００２から描画命令、あるいはネットワーク情報を受信すると（ステップＳ１４０１）、遅延判定の処理を開始する（ステップＳ１４０２）。
　ネットワーク３００が遅延状態であると判定した場合、画面共有品質予測部２００４は、例えばカーソルイメージ情報Ｘを再構築部２００５に対して通知する（ステップＳ１４０３）。一方、遅延状態でないと判定した場合、画面共有品質予測部２００４は、カーソルイメージ情報Ｗを再構築部２００５に対して通知する（ステップＳ１４０５）。
　再構築部２００５においてカーソルイメージ情報Ｘからカーソルイメージ情報Ｗへの変更、あるいはカーソルイメージ情報Ｗからカーソルイメージ情報Ｘへの変更が発生した場合、一定時間カーソルイメージ情報の変更を禁止する（ステップＳ１４０４）。一定時間のカーソルイメージ情報の変更禁止は、カーソルイメージ情報が頻繁に変更されないために必要なフローである。
　ここで、カーソルイメージ情報Ｘは、ネットワーク３００に遅延が発生していることを利用者に通知するために用いられる。一般には、カーソルイメージ情報Ｘには砂時計マークの画像が用いられる。又はコンピュータが処理中であることを示す砂時計マークの画像と同一の画像を利用してもよい。更にはまた、遅延状態であることを明示的に提示するため、異なる砂時計マークの画像を利用しても良い。
　なお、ネットワーク３００が遅延状態であると予測しているとき、クライアント装置２０００は以下に述べる動作を行っても良い。
・ネットワーク３００が遅延状態であるとき、表示部２００３の画面描画を停止してもよい。即ち、ネットワーク３００が遅延状態であるときは、サーバ装置１０００から送信される出力画面情報の受信が円滑に行われない。よって、描画が乱れたり、遅延したりして、クライアント装置のリソースを不要に消費したりすることを避けるために、画面描画を停止させる。
・ネットワーク３００が遅延状態であるとき、カーソルイメージ情報Ｘ（砂時計マーク）の位置の更新を行わず、停止させてもよい。これは、利用者にクライアント端末２０００の操作ができないことを通知するためである。
・ネットワーク３００が遅延状態であるとき、入力情報の送信を停止してもよい。即ち、ネットワーク３００が遅延状態であるときは、ネットワーク３００に異常が発生している場合がある。従って、通信部２００２から入力情報を送信しても、応答として返信される出力情報を正しく受信できる可能性は低い。また、新たな送信データが発生することで、ネットワーク３００の更なる混雑や輻輳を招くおそれがある。これを避けるためである。
　次に、ステップＳ１４０２のネットワーク３００が遅延状態であるか否かの判定について説明する。画面共有品質予測部２００４は、以下に記す３つのステップを繰り返すことにより、ネットワーク３００が遅延状態であるか否かを判定する。（１） 遅延値の計算、（２） 遅延値と遅延判断定数との比較による遅延状態であるか否かの決定、（３） 遅延判断定数の修正である。
（１）遅延値Ｙの計算
　ネットワーク情報に基づき、遅延値Ｙを計算して求める。遅延値Ｙは、例えば、ＲＴＴ (Round Trip Time)などの時間幅である。利用するネットワーク情報と、その計算方法にはいくつかのバリエーションがあるため、後述する。
（２）遅延値と遅延判断定数との比較による遅延状態であるか否かの決定
　図１１（ａ）に、時間経過に対する遅延指数Ｙの変化を示す。図１１（ａ）の横軸は、遅延値Ｙである。また、縦軸は、時間経過ｔである。
　「（１）遅延値の計算」で得られた遅延値Ｙと、事前に定められた２つの遅延判断定数Ａ，Ｂ（Ａ＜Ｂ）の大小を比較する。ＹがＢより大きい（つまり、前回のＹはＹ＜Ｂであったにも関わらず、今回のＹは、Ｂ＜Ｙであった）ならば、ネットワーク３００が遅延状態であると判定する。ＹがＡより小さい（つまり、前回のＹはＡ＜Ｙであったにも関わらず、今回のＹは、Ｙ＜Ａであった）ならば、ネットワーク３００が遅延状態でないと判定する。上記以外の場合は、前回の判定結果を維持し、変更しない。
　図１１（ａ）は、上述の判定の結果をグラフ化したものである。即ち、図１１（ａ）に示すように、遅延値Ｙが遅延判断定数Ｂを超えた時刻から、遅延判断定数Ａを下回った時刻までを、ネットワーク３００が遅延状態であると、画面共有品質予測部２００４は判定する。
（３）遅延判断定数の修正
　「（１）遅延値の計算」で得られた遅延値Ｙに基づき、遅延値Ｙの平均値を計算する。このとき、上述の遅延判断定数ＡおよびＢの値を、遅延値Ｙの平均値を考慮して修正してもよい。
　ここで、遅延判断定数Ａ，Ｂの初期値は、クライアント装置２０００がネットワーク３００に接続しているリンク情報を用いて決定してもよい。例えば、クライアント装置２０００が有線ＬＡＮに接続している場合を考える。クライアント装置２０００が１００Ｍｂｐｓの有線ＬＡＮに接続している場合と、１Ｇｂｐｓの有線ＬＡＮに接続している場合とでは、後者の方がＡおよびＢの値が大きいことが望ましい。次に、クライアント装置２０００が無線ＬＡＮに接続している場合を考える。IEEE802.11b準拠の無線ＬＡＮを用いる場合と、IEEE802.11g準拠の無線ＬＡＮを用いる場合とでは、後者の方がＡおよびＢの値が大きいことが望ましい。
　次に、上述の「（１）遅延値の計算」におけるネットワーク情報の種類と遅延値の計算方法を説明する。遅延値は、以下（Ａ）～（Ｄ）に示すいずれかの方法、またはこれらの組合せによって計算して求める。
（Ａ）ＲＴＴ値をネットワーク情報として用いる。
　クライアント装置２０００の画面共有品質予測部２００４は、サーバ装置１０００との間で、ＲＴＴ (Round Trip Time)を測定するためのデータを交換する。ＲＴＴの測定方法は、一般的に知られた方法を利用するものとする。本発明で限定するものではないため、詳細説明は省く。画面共有品質予測部２００４は、測定により得られたＲＴＴ値を、遅延値として利用する。
（Ｂ）パケット欠損率をネットワーク情報として用いる。
　クライアント装置２０００の画面共有品質予測部２００４は、「（１）サーバ装置１０００に対して送信したデータのうち、未だTCP Ackメッセージを受信していない数」、もしくは「（２）TCPスタックにおける現在のセグメントサイズ」などの送信データに関するネットワーク情報を、通信部２００２から取得し記憶する。上記（１）を用いる場合、画面共有品質予測部２００４は、未だTCP Ackメッセージを受信していないデータの割合を計算し、遅延値として使用する。上記（２）を用いる場合には、画面共有品質予測部２００４は、最大セグメントサイズと現在のセグメントサイズとの差を計算し、遅延値として使用する。
（Ｃ）画面更新データ受信開始から受信完了に要する時間を、ネットワーク情報として用いる。
　通信部２００２が受信する画面更新データは、複数のTCPパケットとして届けられることもあるし、一部データが欠損して届けられたために再送処理が行われることもある。そのため、通信部２００２にて、画面更新データを受信開始する時刻と、画面更新データを受信完了する時刻は異なる。そこで画面共有品質予測部２００４は、通信部２００２において画面更新データを受信開始した時刻に、タイマー（図示せず）をスタートする。そして、画面更新データを受信完了した時刻に、当該タイマーをストップする。これにより、画面更新データの受信開始から受信完了に要する時間を測定する。画面共有品質予測部２００４は、測定した、画面更新データの受信開始から受信完了に要する時間を、遅延値として使用する。
　ただし、画面更新データの受信は開始されたが、画面更新データの受信完了に時間を要し、時間測定中のタイマーの値が非常に大きくなる場合がある。すなわち、画面更新データの受信開始から受信完了に要する時間が、遅延判断定数Ｂ以上となる場合である。この場合には、画面共有品質予測部２００４は、画面更新データの受信が完了していなくても、タイマーをストップし、その時点での測定値をネットワーク情報としてもよい。
（Ｄ） 入力データ送信完了から画面更新データ受信完了に要する時間を、ネットワーク情報として用いる。図１１（ｂ）を用いて、本ケースを説明する。
　画面共有品質予測部２００４は、入力データをサーバ装置１０００に送信する際、送信する入力データにシーケンス番号を付加する。図１１（ｂ）では、クライアント装置２０００は、まずシーケンス番号「５」の入力データを、サーバ装置１０００に送信している。
　そして、画面共有品質予測部２００４は、入力データを送信完了した時刻に、シーケンス番号に対応したタイマー（図示せず）をスタートする。それとともに、シーケンス番号を増加させる。図１１（ｂ）では、シーケンス番号「５」「６」の入力データを送信する毎に、対応するタイマーをスタートしている。
　また画面共有品質予測部２００４は、入力データの送信に対してサーバ装置１０００から返信される画面更新データを受信する際、画面更新データに付加されているシーケンス番号を確認する。画面共有品質予測部２００４は、画面更新データを受信完了した時刻に、前述のシーケンス番号に対応したタイマーをストップする。図１１（ｂ）では、シーケンス番号「５」の画面更新データをサーバ装置１０００から受信すると、クライアント装置２０００は対応するタイマーをストップしている。
　ここで上記では、サーバ装置１０００は、クライアント装置２０００から受信した入力データに付加されるシーケンス番号のうち、最新のものを常に記憶している。そして、サーバ装置１０００は、記憶したシーケンス番号を画面更新データに付加して送信することを仮定している。
　以上により、画面共有品質予測部２００４は、シーケンス番号に対応したタイマーの値から、入力データ送信完了から画面更新データ受信完了に要する時間（図１１（ｂ）における「測定時間」）を測定する。画面共有品質予測部２００４は、測定した、入力データ送信完了から画面更新データ受信完了に要する時間を、遅延値として使用する。
　ただし、入力データの送信は開始したが、対応する画面更新データの受信に時間を要し、タイマーの値が非常に大きくなる場合がある。このとき、画面更新データの受信が完了していなくても、タイマーをストップする。そして、その時点のタイマー値をネットワーク情報としてもよい。
　また、入力データや画面更新データに付加されるシーケンス番号は、入力データや画面更新データとは別のデータとして送信されてもよい。シーケンス番号を入力データに付加して送信する場合は、利用者操作に直接関係しないマウスイベントの一部としてシーケンス番号を入力データに含めてもよい。さらに、シーケンス番号を画面更新データに付加して送信する場合は、クライアント装置２０００の描画範囲の外のディスプレイ描画情報の一部として、シーケンス番号を画面更新データに含めてもよい。
　入力データ送信完了から画面更新データ受信完了に要する時間を測定するタイミングは任意であり、入力データ送信完了のたび、常に測定を実行する必要は無い。例えば、入力データとして重要な、マウスのクリックの際にのみ、測定を実行することも可能である。
　画面転送システムにおいて、ある入力データがクライアント装置２０００からサーバ装置１０００に送信されると、多くの場合において、カーソルの再描画等の処理がサーバ装置１０００で発生する。その結果、描画イベントが発生し、画面更新データがサーバ装置１０００からクライアント装置２０００へ送信される。従って、上述の(D)の方法を用いて測定した時間は、クライアント装置２０００とサーバ装置１０００との間のＲＴＴに近い値になると考えられる。
　また、上述の（Ｄ）の方法は、クライアント装置２０００とサーバ装置１０００との間でＲＴＴ測定用の特別なパケットが発生しないため、ネットワーク上のトラフィック量の増加を引き起こさない。
　本実施形態によれば、ネットワーク品質が悪化して、クライアント装置における描画実行が遅延した場合、クライアント装置に表示されるカーソルの形状を、処理待ち中であることを示す「砂時計マーク」に変更する。これにより、画面転送システムの利用者に対し、ネットワークに起因する処理の遅延が発生していることを正しく通知することができる。その結果、利用者の誤操作を防ぎ、さらなるネットワークの混雑を回避することができる。ネットワークの混雑に起因するパケットの遅延や欠損を低減できるので、クライアント装置における出力応答を遅延や欠損なく画面表示することが可能になる。
　また、画面転送システムの利用者は、ネットワークに起因する処理の遅延が発生していることを正しく把握することができるので、利用者のストレスを軽減することができる。
　尚、本発明は上記実施形態をそのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
１００・・・サーバ装置
１０１・・・描画命令生成部
１０２・・・シーケンス番号付加部
１０３・・・エンコード部
１０４・・・描画命令送信部
１０５・・・フレームバッファ
１０６・・・表示部
１０７・・・再構築部
１０８・・・画面共有品質予測部
１０９・・・履歴記憶部
１１０・・・履歴取得部
１１１・・・欠損通知受信部
２００・・・クライアント装置
２０１・・・描画命令受信部
２０２・・・欠損検知部
２０３・・・デコード部
２０４・・・描画実行部
２０５・・・フレームバッファ
２０６・・・表示部
２０７・・・欠損通知送信部
３００・・・ネットワーク

Claims (5)

  1. 　クライアント装置からネットワークを介して入力データを受信し、前記入力データに対する応答画面の描画命令を前記ネットワークを介して前記クライアント装置に送信するサーバ装置であって、
    　前記クライアント装置へ送信した前記描画命令を記憶する履歴記憶部と、
    　前記クライアント装置から送信された前記描画命令に欠損が生じたことを通知する通知データを受信する受信部と、
    　前記通知データに応じて前記履歴記憶部から抽出した前記描画命令を再送信することによって前記クライアント装置で描画の破綻が生じるか否かを予測する第１の予測部と、
    　前記第１の予測部によって描画の破綻が生じると予測した場合に、前記履歴記憶部に記憶された描画命令と前記通知データとから描画の破綻が生じないように描画命令を再構築する再構築部と、
    　前記再構築した描画命令を前記クライアント装置に送信する送信部と
    を備えることを特徴とするサーバ装置。
  2. 　前記第１の予測部は、前記履歴記憶部に記憶された描画命令の送信履歴に基づき前記再送信しようとする前記描画命令により前記クライアント装置の描画が破綻するか否かを予測することを特徴とする請求項１に記載のサーバ装置。
  3. 請求項１に記載のサーバ装置と、クライアント装置とから構成される画面転送システムであって、
    前記クライアント装置は
    　前記入力データを前記サーバ装置に送信する場合に、前記入力データによって前記ネットワークが混雑状態か否かを予測する第２の予測部と、
    　前記第２の予測部によって混雑状態が生じると予測した場合に、前記入力データの前記サーバ装置への送信を遮断する遮断部と、
    　前記第２の予測部によって混雑状態が生じると予測した場合に、前記サーバ装置から前記描画命令を受信することなく前記入力データに基づいて描画命令を構築する構築部と、
    　構築された前記描画命令による応答画面を表示する表示部と、
    を備えることを特徴とする画面転送システム。
  4. 　前記クライアント装置において、
    　前記第２の予測部は、前記ネットワークの混雑状態を示す数値を測定する機能をさらに有し、
    　前記第２の予測部が前記数値に基づき前記ネットワークが混雑状態であると予測した場合は、前記構築部は前記混雑状態を示す画面を表示させる描画命令を構築する
    ことを特徴とする請求項３に記載の画面転送システム。
  5. 　前記数値は、前記サーバ装置と前記クライアント装置間のラウンドトリップタイム、パケット欠損率、受信遅延時間のいずれかであることを特徴とする請求項４に記載の画面転送システム。
PCT/JP2009/004922 2009-09-28 2009-09-28 サーバ装置、及び画面転送システム WO2011036733A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/004922 WO2011036733A1 (ja) 2009-09-28 2009-09-28 サーバ装置、及び画面転送システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/004922 WO2011036733A1 (ja) 2009-09-28 2009-09-28 サーバ装置、及び画面転送システム

Publications (1)

Publication Number Publication Date
WO2011036733A1 true WO2011036733A1 (ja) 2011-03-31

Family

ID=43795505

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/004922 WO2011036733A1 (ja) 2009-09-28 2009-09-28 サーバ装置、及び画面転送システム

Country Status (1)

Country Link
WO (1) WO2011036733A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014067312A (ja) * 2012-09-26 2014-04-17 Fujitsu Ltd システム、端末装置および画像処理方法
JP2014067311A (ja) * 2012-09-26 2014-04-17 Fujitsu Ltd システム、端末装置および画像取得方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002512393A (ja) * 1998-04-20 2002-04-23 サン・マイクロシステムズ・インコーポレーテッド エラー修正を提供するための方法及び機構
JP2002191038A (ja) * 2000-12-20 2002-07-05 Hitachi Ltd 動画像配信システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002512393A (ja) * 1998-04-20 2002-04-23 サン・マイクロシステムズ・インコーポレーテッド エラー修正を提供するための方法及び機構
JP2002191038A (ja) * 2000-12-20 2002-07-05 Hitachi Ltd 動画像配信システム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014067312A (ja) * 2012-09-26 2014-04-17 Fujitsu Ltd システム、端末装置および画像処理方法
JP2014067311A (ja) * 2012-09-26 2014-04-17 Fujitsu Ltd システム、端末装置および画像取得方法

Similar Documents

Publication Publication Date Title
TWI651939B (zh) 上行資料解壓縮、壓縮的方法和裝置
JP6158323B2 (ja) 仮想デスクトップインフラ（ｖｄｉ）における性能向上
EP1206062A2 (en) Data communication system, data communication method, and recording medium with data communication program recorded thereon
EP2403249A1 (en) Transmission of image updates from a server to a thin client
EP2490406A1 (en) Image transmission from a server to a thin client
US10230563B2 (en) Methods and first network node for managing a stream control transmission protocol association
US9716907B2 (en) Updating thin-client display based on a thin-out rate
JP5867160B2 (ja) 通信制御装置、通信制御方法および通信制御プログラム
US9300818B2 (en) Information processing apparatus and method
US20160173387A1 (en) Network Traffic Accelerator
JP2012160834A (ja) 情報処理装置、画像送信プログラムおよび画像表示方法
US9037749B2 (en) Information processing apparatus and image transmission method
WO2011036733A1 (ja) サーバ装置、及び画面転送システム
JP2012114493A (ja) サーバ装置及びプログラム
US10033489B1 (en) Managing communications based on network conditions
JP2018536181A (ja) ワイヤレス表示モードを切り替え、不安定状態にあるグラフィックス処理ユニットをリフレッシュすること
US20120221630A1 (en) Server
US8913070B2 (en) Server, screen transfer system, and screen transfer method
US20160127745A1 (en) Efficient screen image transfer
TWI538523B (zh) 影像日誌儲存系統及其記錄方法
WO2011036715A1 (ja) サーバ、システム
JP4374013B2 (ja) 中継装置、並びに中継方法
WO2023100376A1 (ja) 通信システム、通信方法および通信プログラム
JP5665466B2 (ja) 画面表示システム
US20160036664A1 (en) Continued deep packet inspection classification after roaming

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: 09849764

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09849764

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP