(57)【要約】【課題】通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信する。【解決手段】サーバ機器は、アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、処理をコンピュータに実行させる画面送信プログラムが提供される。【選択図】図４
2019191962.tif 000002
【特許請求の範囲】
【請求項１】
サーバ機器は、
アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
【請求項２】
前記サーバ機器は、
アクティブウィンドウのエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第１通信プロトコルで前記クライアント機器に送信し、
アクティブウィンドウでないエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第２通信プロトコルで前記クライアント機器に送信する、
請求項１に記載の画面送信プログラム。
【請求項３】
アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
ことをサーバ機器のコンピュータが実行する画面送信方法。
【請求項４】
サーバ機器とクライアント機器とを有する画面送受信システムであって、
前記サーバ機器は、
アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信する第１送信部と、
アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する第２送信部と、を有し、
前記クライアント機器は、
前記アクティブウィンドウのエリアに係る画面データを受信する第１受信部と、
前記アクティブウィンドウでないエリアに係る画面データを受信する第２受信部と、
受信した前記アクティブウィンドウのエリアに係る画面データと前記アクティブウィンドウでないエリアに係る画面データとに基づき、画面上の画像を更新する画像更新部と、を有する、
画面送受信システム。
【請求項５】
サーバ機器は、
画面全体の画像を示すキーフレームに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
キーフレームとの差分の画像を示す予測フレームに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
【請求項６】
サーバ機器は、
画面全体の画像を分割した分割画像に係る画面データであって、前回の分割画像から変化した画面データのうち、所定回数分の画面データの送信履歴を記憶した記憶部を参照して、画面データが所定回数送信されていない場合、該画面データを通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
画面データが所定回数の少なくともいずれかで送信されている場合、該画面データを第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
【請求項７】
クライアント機器は、
画面の操作イベントを受け付け、
前記画面の操作イベントのうち、所定時間毎の操作イベント及び特定の操作イベントの位置情報を、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
前記画面の操作イベントのうち、前記所定時間毎の操作イベント及び特定の操作イベント以外の操作イベントの位置情報を、前記第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、画面送信プログラム、画面送信方法及び画面送受信システムに関する。
【背景技術】
【０００２】
クライアント機器から要求された処理の実行結果に対応するコマンドと表示データとのそれぞれを別個にクライアント機器に対して送信するデータ送信装置が提案されている（例えば、特許文献１参照）。
【０００３】
特許文献１では、データ送信部が、表示データと前回の表示データとの差分から変化率を算出し、変化率が閾値未満の場合、表示データの差分を第１の通信プロトコル（例えばＴＣＰ）によりクライアント機器に送信する。変化率が閾値以上の場合、表示データの差分を第２の通信プロトコル（例えばＵＤＰ）によりクライアント機器に送信する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−１４０３７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記手法では、いずれの通信プロトコルにおいてもクライアント機器側で受信すべきデータの到着が遅れている場合、データの到着が遅延しているのか、それともデータを損失したのかを判定するために、一定の待機時間を必要とする。これにより、通信の高速化に対するパフォーマンスが悪化する場合がある。
【０００６】
そこで、１つの側面では、本開示は、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することを目的とする。
【課題を解決するための手段】
【０００７】
１つの実施態様では、サーバ機器は、アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、処理をコンピュータに実行させる画面送信プログラムが提供される。
【発明の効果】
【０００８】
１つの側面では、本開示は、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することができる。
【図面の簡単な説明】
【０００９】
【図１】通信中に損失したデータの再送処理を説明するための図。
【図２】一実施形態に係る画面送受信システムのサーバ機器及びクライアント機器の機能構成の一例を示す図。
【図３】一実施形態に係るサーバ機器のハードウェア構成の一例を示す図。
【図４】一実施形態の実施例１に係る画面送信処理の一例を示すフローチャート。
【図５】一実施形態に係るウィンドウ一覧テーブルの一例を示す図。
【図６】一実施形態の実施例１に係る画面送信処理を説明するための図。
【図７】一実施形態の実施例２に係る画面送信処理の一例を示すフローチャート。
【図８】一実施形態の実施例２に係る画面送信処理を説明するための図。
【図９】一実施形態の実施例３に係る画面送信処理の一例を示すフローチャート。
【図１０】一実施形態の実施例３に係る画面送信処理を説明するための図。
【図１１】一実施形態の実施例４に係る画面送信処理の一例を示すフローチャート。
【図１２】一実施形態に係る管理テーブルの一例を示す図。
【図１３】一実施形態に係る画面送受信システムのサーバ機器及びクライアント機器の機能構成の他の一例を示す図。
【図１４】一実施形態の実施例５に係る操作送信処理の一例を示すフローチャート。
【図１５】一実施形態の実施例５に係る操作送信処理を説明するための図。
【発明を実施するための形態】
【００１０】
以下、一実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
【００１１】
［はじめに］
仮想デスクトップ（ＶＤＩ：Virtual Desktop Infrastructure、以下、「ＶＤＩ」ともいう。)では、遠隔地のサーバ機器をクライアント機器から操作し、サーバ機器のデスクトップ画像の画面（以下、「デスクトップ画面」ともいう。）をクライアント機器に表示する。仮想デスクトップは、ユーザがインタラクティブに操作するシステムであり、通常のデスクトップを使用する場合と同様のレスポンスを求められる。
【００１２】
仮想デスクトップでは、クライアント機器でのユーザ操作をサーバ機器に転送し、サーバ機器上で動作するＶＤＩアプリ１１３によって処理された後、サーバ機器にて生成されたデスクトップ画面がクライアント機器に伝送される。伝送されたデスクトップ画面は、クライアント機器の画面上に表示される。
【００１３】
仮想デスクトップでは、通常のコンピュータの操作に比べて、操作およびデスクトップ画面がネットワークを介して転送される点が異なる。このため、通常のデスクトップを使用する場合と同様のレスポンスを実現するためにはサーバ機器とクライアント機器との間においてデータの高速通信が必要となる。
【００１４】
仮想デスクトップシステムが使用する通信プロトコルの一例としては、ＴＣＰ（Transmission Control Protocol）及びＵＤＰ（User Datagram Protocol）がある。ＴＣＰは、プロトコル自身が通信するデータの信頼性を保障する仕組みを持つ。よって、仮想デスクトップシステムは転送されたデータの信頼性を前提に処理を実施する。
【００１５】
一方、ＵＤＰは、高速であるがプロトコルに信頼性を保障する仕組みがない。このため、仮想デスクトップシステムではＵＤＰ上で実現する仮想デスクトップ用プロトコルに信頼性を保障する仕組みを、以下のようにして実現する。なお、ＴＣＰには以下の仕組みが予め備えられている。
【００１６】
仮想デスクトップ用プロトコルに信頼性を保障する典型的な仕組み（処理）としては、通信中に損失したデータを再送することが挙げられる。図１を参照しながら、通信中に損失したデータを再送する処理の一例を説明する。図１は、通信中に損失したデータの再送処理を説明するための図である。
【００１７】
サーバ機器からデータが送信されると、ネットワークを介してクライアント機器にてデータを受信する。ネットワークを伝送されるデータがクライアント機器側で受信されるまでには通信時間がかかるため、転送遅延が生じる。サーバ機器からのデータを受信しない場合、クライアント機器側では、そのデータの到着が遅れているのか、伝送中に損失したのかを判定するために一定時間待機する。
【００１８】
クライアント機器は、一定時間待機した後、受信すべきデータを受信していない場合、再送要求を送信する。サーバ機器は、再送要求を受信すると、当該データを再送し、再送データがクライアント機器側で受信される。このように、データの損失に伴い、一定の待機時間と再送要求から再送データの受信までの時間との合計時間がパフォーマンスの悪化、つまり、処理遅延として生じる。
【００１９】
ＵＤＰ上で実現する通信プロトコルにおいて、一部のデータの損失が発生した場合に、損失したデータを再送させることなく処理を行うことで、再送時間が生じないため、パフォーマンスを向上させることができる。しかし、この場合においても、クライアント機器は、受信すべきデータを受信していない場合、データが損失したか又はデータの到着が遅延しているかを判定する必要がある。この場合、図１に示す一定の待機時間がパフォーマンスの悪化、つまり、処理遅延として生じる。
【００２０】
以下に説明する一実施形態に係る画面送受信システムでは、受信すべきデータを受信していない場合においても一定の待機時間を排し、できる限り高いパフォーマンスを発揮するようにする。
【００２１】
具体的には、データを送信する側で、送信するデータが、受信側で必ず処理することが必要なデータであるか、受信側で必ずしも処理する必要がないデータであるかを判定する。必ずしも処理する必要がないデータとは、例えば、ＶＤＩで画面をより詳細に表示するためのデータや、画面の動きをより滑らかにするためのデータなどが相当する。
【００２２】
受信側で必ず処理することが必要なデータは、信頼性を保証する通信プロトコルによって、送信元から受信先に伝送する。信頼性を保証する通信プロトコルでは、データの損失が発生した場合には再送処理を行う。
【００２３】
一方、受信側で必ずしも処理する必要がないデータは、信頼性を保証しないが高速な通信プロトコルによって、送信元から受信先に伝送する。受信すべきデータを受信していない場合においても一定時間の待機することや再送要求は行わない。データの損失が発生した場合にも再送は行わない。
【００２４】
受信側では、必ず処理することが必要なデータは信頼性を保証する通信プロトコルによって受信することが保証されるため、従来通りに処理を行う。一方、必ずしも処理する必要がないデータは、受信側では受信できたデータは処理を行うが、受信できなかったデータは無視する。これにより、再送時間を不要とするだけでなく、受信できなかったことを検知するための図１に示す一定の待機時間を不要とし、パフォーマンスを向上させることができる。
【００２５】
［画面送受信システム／サーバ機器及びクライアント機器の機能構成］
以上の処理を実行する一実施形態に係る画面送受信システムの構成と、サーバ機器及びクライアント機器の機能構成の一例について、図２を参照して説明する。図２は、一実施形態に係る画面送受信システムの構成、サーバ機器及びクライアント機器の機能構成の一例を示す図である。
【００２６】
画面送受信システム１は、サーバ機器１０とクライアント機器２０とを有する。ここでは、クライアント機器２０は１つ示しているが、クライアント機器２０の数は１つに限られず、複数であり得る。サーバ機器１０についても、１つに限られず複数であり得る。サーバ機器１０とクライアント機器２０とは、ネットワーク４０により接続されている。
【００２７】
画面送受信システム１は、遠隔地のサーバ機器１０をクライアント機器２０から操作し、サーバ機器１０のデスクトップ画面をクライアント機器２０に表示することで、仮想デスクトップ（ＶＤＩ)のサービスを提供する。
【００２８】
ＶＤＩのクライアント機器２０は、記憶部２１、第１受信部２２、第２受信部２３、画像更新部２４、表示部２５、受付部２６、制御部２７及び送信部２８を有する。記憶部２１は、ＶＤＩアプリケーションプログラム（以下、「ＶＤＩアプリ２１１」という。）を記憶する。制御部２７がＶＤＩアプリ２１１を実行し、受付部２６がユーザの操作を受け付ける。送信部２８は、所定の情報をサーバ機器１０や他の装置に送信する。
【００２９】
ＶＤＩのサーバ機器１０は、記憶部１１、画面処理部１２、判定部１３、第１送信部１４、第２送信部１５、受信部１６及び制御部１７を有する。受信部１６は所定の情報をクライアント機器２０や他の装置から受信する。制御部１７及び画面処理部１２は、記憶部１１に記憶されたＶＤＩアプリケーションプログラム（以下、「ＶＤＩアプリ１１３」という。）を実行することで、デスクトップ画面を生成する。
【００３０】
生成されたデスクトップ画面データは、信頼性を保証する必要があるデータか又は信頼性を保証する必要がないデータかにより異なる通信プロトコルでクライアント機器２０に送信される。そこで、判定部１３は、受信側のクライアント機器２０で必ず処理することが必要なデータか、必ずしも処理する必要がないデータかを判定する。
【００３１】
第１送信部１４は、信頼性を保証する仕組みを持ち、データの再送により必ずデータが受信側のクライアント機器２０に転送される第１通信プロトコルを用いてデータを送信する。第２送信部１５は、信頼性を保証する仕組みを排し、データの伝送を高速化した第２通信プロトコルを用いてデータを送信する。
【００３２】
生成したデスクトップ画面データがクライアント機器２０で必ず処理することが必要なデータであると判定されると、第１送信部１４は、当該デスクトップ画面データを信頼性を保証する第１通信プロトコルでクライアント機器２０に送信する。一方、生成したデスクトップ画面データがクライアント機器２０で必ずしも処理する必要がないデータであると判定されると、第２送信部１５は、信頼性を保証しない第２通信プロトコルでクライアント機器２０にデスクトップ画面データを送信する。
【００３３】
以下では、信頼性を保証する第１通信プロトコルの一例としてＴＣＰを挙げ、信頼性を保証しない第２通信プロトコルの一例としてＵＤＰを挙げ説明する。しかし、これは一例であり、信頼性を保証する第１通信プロトコルは、未受信のデータを検出するために一定時間待機し、未受信のデータを検知しなかった場合に再送する仕組みを有しているＵＤＰやその他のプロトコルであってもよい。つまり、信頼性を保証する第１通信プロトコルは、サーバ機器１０が送ったデータが完全にクライアント機器２０に届く仕組みを持つプロトコルであればいずれを用いてもよい。
【００３４】
一方、信頼性を保証しない第２通信プロトコルは、サーバ機器１０が送ったデータが完全にクライアント機器２０に届く仕組みを持っていない。また、信頼性を保証しない第２通信プロトコルは、未受信のデータを検知するために一定時間待機せず、かつ、再送する仕組みを有さないＵＤＰやその他のプロトコルであってもよい。つまり、信頼性を保証しない第２通信プロトコルでは、未受信のデータを検知するための一定の待機時間及び再送要求からデータが再送されるまでの時間を要しないため、第１通信プロトコルよりもデータ通信が速い。
【００３５】
クライアント機器２０側では、第１受信部２２が、第１送信部１４から送信された画面データを受信する。また、第２受信部２３が、第２送信部１５から送信された画面データを受信する。画像更新部２４は、第１受信部２２及び第２受信部２３にて受信した画面データにより画像を更新し、表示部２５に表示する。これにより、サーバ機器１０にて生成された画面が、クライアント機器２０の画面上に表示される。第１受信部２２は、受信すべきデータを受信しない場合、一定時間待機し、その後、再送要求をサーバ機器１０に送信する（図１参照）。第２受信部２３は、データが到着するか否かを検知せず、データが到着しない場合にはそのデータを無視する。
【００３６】
記憶部１１には、ウィンドウ一覧テーブル１１１、管理テーブル１１２、ＶＤＩアプリ１１３及び画面送信プログラム１１４が記憶されている。画面送信プログラム１１４は、信頼性を保証する第１通信プロトコル又は信頼性を保証しない第２通信プロトコルのいずれかによりデスクトップ画面データを送信するかを判定し、判定結果に従い該画面データを送信する処理をサーバ機器１０に実行させる。
【００３７】
なお、サーバ機器１０及びクライアント機器２０は、パーソナルコンピュータ、タブレット型端末、スマートフォン、ＨＭＤ（Head Mount Display）や時計型のウエアラブル表示機器等、いずれの情報処理装置であってもよい。
【００３８】
［サーバ機器１０及びクライアント機器２０のハードウェア構成］
次に、一実施形態に係るサーバ機器１０及びクライアント機器２０のハードウェア構成について、図３を参照して説明する。図３は、一実施形態に係るサーバ機器１０のハードウェア構成の一例を示す図である。ここでは、サーバ機器１０のハードウェア構成について説明し、同一のハードウェア構成を有するクライアント機器２０については説明を省略する。
【００３９】
サーバ機器１０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６を有する。また、サーバ機器１０は、通信Ｉ／Ｆ１０７及びＨＤＤ（Hard Disk Drive）１０８を有する。サーバ機器１０の各部はバスＢで相互に接続されている。
【００４０】
入力装置１０１は、キーボードやマウスなどを含み、ユーザ操作等を受け付けるために用いられる。表示装置１０２は、ＬＣＤ（Liquid crystal Display）モニタ等のディスプレイ、プリンタ、ＣＲＴ（Cathode Ray Tube）などを含み、生成する画面データやその他の情報を表示する。通信Ｉ／Ｆ１０７は、サーバ機器１０をネットワーク４０に接続するインターフェースである。これにより、サーバ機器１０は、通信Ｉ／Ｆ１０７を介してクライアント機器２０に画面データを送信したり、操作情報を受信したりすることができる。
【００４１】
ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、サーバ機器１０の全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のデータベースやプログラム等が格納されてもよい。
【００４２】
外部Ｉ／Ｆ１０３は、外部装置とのインターフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、サーバ機器１０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａは、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）であってもよい。記録媒体１０３ａは、ＳＤメモリカード（SD Memory card）、ＵＳＢメモリ（Universal Serial Bus memory）であってもよい。
【００４３】
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリである。ＲＯＭ１０５には、ネットワーク設定等のプログラム及びデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＣＰＵ１０６は、ＨＤＤ１０８やＲＯＭ１０５などの記憶装置から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
【００４４】
かかる構成により、本実施形態に係るサーバ機器１０では、ＣＰＵ１０６が、例えばＲＡＭ１０４、ＲＯＭ１０５、ＨＤＤ１０８内に格納されたプログラム及びデータを用いて画面送信処理を実行する。
【００４５】
画面処理部１２、判定部１３及び制御部１７の各機能は、例えば、画面送信プログラム１１４が、ＣＰＵ１０６に実行させる処理により実現可能である。また、第１送信部１４、第２送信部１５、受信部１６の機能は、例えば、通信Ｉ／Ｆ１０７により実現可能である。記憶部１１の機能は、例えば、ＲＡＭ１０４、ＲＯＭ１０５及びＨＤＤ１０８により実現可能である。
【００４６】
ウィンドウ一覧テーブル１１１及び管理テーブル１１２に記憶された情報は、ＲＡＭ１０４、ＨＤＤ１０８又はネットワーク４０を介してサーバ機器１０に接続されるクラウドコンピュータの記憶部に格納され得る。画面処理部１２、判定部１３及び制御部１７の各機能は、ＣＰＵ１０６に実行させる替わりに、サーバ機器１０に接続される複数のクラウドコンピュータやフォグコンピュータに実行させてもよい。
【００４７】
＜実施例１＞
［画面送信処理］
次に、一実施形態の実施例１に係る画面送信処理の一例について図４〜図６を参照して説明する。図４は、一実施形態の実施例１に係る画面送信処理の一例を示すフローチャートである。図５は、一実施形態に係るウィンドウ一覧テーブル１１の一例を示す図である。図６は、一実施形態の実施例１に係る画面送信処理を説明するための図である。本処理は、サーバ機器１０により実行される。
【００４８】
Ｗｉｎｄｏｗｓ（登録商標）などのウィンドウシステムでは、アクティブウィンドウをユーザが着目しているエリアとみなすことができる。そこで、実施例１では、ＶＤＩにおいて、ユーザが注目しているエリアの画面データは信頼性を保証するＴＣＰにて通信し、クライアント機器２０側にて受信した画面データによる画面更新を確実に行う。一方、ユーザが着目していないエリア、すなわちアクティブウィンドウ以外（非アクティブウィンドウ）のエリアの画面変更は、必ずしもクライアント機器２０に反映されなくてもかまわないと考え、信頼性を保証しないＵＤＰにて通信し、通信の高速化を図る。ＴＣＰは、信頼性を保証する第１通信プロトコルの一例であり、ＵＤＰは、信頼性を保証しない第２通信プロトコルの一例である。以下、実施例１に係る画面送信処理について説明する。
【００４９】
クライアント機器２０が、ＶＤＩアプリ２１１を動作させ、サーバ機器１０に接続すると、画面処理部１２は、デスクトップ画面のキャプチャを開始する（ステップＳ１０）。次に、画面処理部１２は、アクティブウィンドウのエリア（以下、「エリアＡ」とする。）を取得する（ステップＳ１２）。
【００５０】
アクティブウィンドウのエリアの取得は、ウィンドウ一覧テーブル１１１を用いて実行される。図５に示すウィンドウ一覧テーブル１１１は、デスクトップ画面のウィンドウ番号（Ｗ  Ｎｏ．）、ウィンドウの位置（座標）、ウィンドウの状態を記憶する。例えば、図６に示すデスクトップ画面Ｄｐは、３つのウィンドウＷ１、Ｗ２、Ｗ３から構成され、ウィンドウＷ１はアクティブ、ウィンドウＷ２、Ｗ３は非アクティブの状態である。
【００５１】
この場合、ウィンドウ一覧テーブル１１１は、ウィンドウ「Ｗ１」の左上座標（１００、１００）、右下座標（２００、２００）と状態「アクティブ」を記憶する。また、ウィンドウ「Ｗ２」の座標（２００、８０）、（３００、１９０）と状態「非アクティブ」を記憶する。また、ウィンドウ「Ｗ３」の座標（０、０）、（Ｘ、Ｙ）と状態「非アクティブ」を記憶する。
【００５２】
図４に戻り、ステップＳ１２において、画面処理部１２は、ウィンドウ一覧テーブル１１１を参照して、アクティブウィンドウのエリアＡとして、ウィンドウ「Ｗ１」の位置とサイズ（座標）を取得する。次に、判定部１３は、送信対象毎の通信の信頼性の要否を判定する（ステップＳ１３）。
【００５３】
送信対象がエリアＡであると判定された場合、判定部１３は、通信の信頼性が保証される必要があると判定し、ステップＳ１４に進む。ステップＳ１４において、画面処理部１２は、キャプチャしたデスクトップ画面ＤｐからアクティブウィンドウのエリアＡの画像を切り出す。画面処理部１２は、転送するデータ量を抑えるために、切り出した画像を圧縮する（ステップＳ１６）。第１送信部１４は、圧縮した画像と、アクティブウィンドウのエリアＡの位置情報を示す座標のデータとをＴＣＰでクライアント機器２０に送信する（ステップＳ１８）。これによれば、アクティブウィンドウのエリアＡに係る画面データは、信頼性を保証するＴＣＰでクライアント機器２０に送信される。これにより、アクティブウィンドウのエリアＡの画像は確実にクライアント機器２０の画面上に反映される。
【００５４】
ステップＳ１３において、送信対象がエリアＡ以外であると判定された場合、判定部１３は、通信の信頼性が保証される必要はないと判定し、ステップＳ２０に進む。ステップＳ２０において、画面処理部１２は、キャプチャしたデスクトップ画面Ｄｐから、アクティブウィンドウのエリアＡをマスクし、マスクした画像を圧縮する（ステップＳ２２）。
【００５５】
具体的には、画面処理部１２は、図６に示すように、デスクトップ画面ＤｐのアクティブウィンドウのエリアＡを黒く塗りつぶすことでエリアＡをマスクした画像を作成する。画面処理部１２は、転送するデータ量を抑えるためにエリアＡをマスクした画像の圧縮を行う。黒く塗りつぶされたエリアＡは効率よく圧縮することができる。
【００５６】
そして、第２送信部１５は、圧縮した画像と、マスクしたエリアＡの位置情報を示す座標とをＵＤＰでクライアント機器２０に送信する（ステップＳ２４）。これによれば、アクティブウィンドウのエリアＡ以外の画面データは、信頼性を保証しないＵＤＰでクライアント機器２０に送信される。これにより、アクティブウィンドウのエリアＡ以外の画面データを高速に送信することができる。
【００５７】
ステップＳ１８及びステップＳ２４の処理後、ＶＤＩが切断されたかが判定され（ステップＳ２６）、ＶＤＩアプリ２１１によるＶＤＩの実行が切断されたと判定されるまでステップＳ１０〜Ｓ２６のループ処理が繰り返し実行され、ＶＤＩが切断されたと判定されたとき、本処理を終了する。
【００５８】
以上によれば、サーバ機器１０は、クライアント機器２０側で必ずしも処理する必要がないデスクトップ画面データと、クライアント機器２０側で必ず処理する必要があるデスクトップ画面データとを判定し、振り分ける。そして、サーバ機器１０は、前者のデスクトップ画面データは信頼性を保証しないが高速な第２通信プロトコルを用いてクライアント機器２０に送信する。また、後者の画面データは信頼性を保証する第１通信プロトコルを用いてクライアント機器２０に送信する。
【００５９】
つまり、実施例１では、クライアント機器２０側で必ずしも処理する必要がないアクティブウィンドウのエリアＡ以外の画面データ（非アクティブウィンドウのエリアの画面データ）は、信頼性を保証しないが高速なＵＤＰの通信プロトコルを用いて伝送される。非アクティブウィンドウのエリアの画面データの場合、画面データの損失が発生した場合にも再送は行わないし、データを受信できたかを検知するための一定の待機時間も要しない。これにより、クライアント機器２０側では画面データを受信できたかを検知するための一定の待機時間及び再送要求を含む再送時間を不要とし、パフォーマンスを向上させることができる。
【００６０】
一方、クライアント機器２０側で必ず処理することが必要なアクティブウィンドウのエリアＡの画面データは、信頼性を保証するＴＣＰの通信プロトコルを用いてサーバ機器１０からクライアント機器２０に伝送される。これにより、ユーザが着目しているアクティブウィンドウのエリアＡの画面データの受信は保証される。よって、アクティブウィンドウのエリアの画面データの場合、画面データの損失が発生した場合には再送が行われる。以上により、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することができる。
【００６１】
＜実施例２＞
［画面送信処理］
次に、一実施形態の実施例２に係る画面送信処理の一例について図７及び図８を参照して説明する。図７は、一実施形態の実施例２に係る画面送信処理の一例を示すフローチャートである。図８は、一実施形態の実施例２に係る画面送信処理を説明するための図である。本処理は、主にサーバ機器１０により実行される。
【００６２】
実施例２では、実施例１に係る画面送信処理を更に効率化するために、サーバ機器１０からクライアント機器２０に送信する画面データを、デスクトップ画面の全体画像のうち変化のあった部分の画像のみに限定する。以下、実施例２に係る画面送信処理について説明する。
【００６３】
クライアント機器２０が、ＶＤＩアプリ２１１を動作させ、サーバ機器１０に接続すると図７に示す本処理が開始される。画面処理部１２は、前回キャプチャした画面の画像を初期化する（ステップＳ３０）。前回キャプチャした画面の画像の初期化には、空白画像を使用することができる。次に、画面処理部１２は、デスクトップ画面のキャプチャを開始する（ステップＳ１０）。
【００６４】
次に、画面処理部１２は、今回キャプチャしたデスクトップ画面の画像と、前回キャプチャしたデスクトップ画面の画像との比較を行い、デスクトップ画面の更新が行われた変更エリア（以下、「変更エリアＤ」とする。）を検出する。次に、画面処理部１２は、変更エリアＤが存在するかを判定する（ステップＳ３４）。デスクトップ画面に更新がなかった場合、画面処理部１２は、変更エリアＤが存在しないと判定し、ステップＳ１０に戻り、次のデスクトップ画面のキャプチャを行い、ステップＳ１０以降の処理を繰り返す。
【００６５】
ステップＳ３４において、デスクトップ画面に更新があった場合、画面処理部１２は、変更エリアＤが存在すると判定し、アクティブウィンドウのエリア（以下、「Ａ」とする。）を取得する（ステップＳ１２）。次に、判定部１３は、送信対象毎の通信の信頼性の要否を判定する（ステップＳ１３）。
【００６６】
送信対象がエリアＡの場合、判定部１３は、通信の信頼性が保証される必要があると判定し、ステップＳ３６に進む。送信対象がエリアＡ以外の場合、判定部１３は、通信の信頼性が保証される必要はないと判定し、ステップＳ３８に進む。
【００６７】
ステップＳ３６において、画面処理部１２は、キャプチャしたデスクトップ画面ＤｐからアクティブウィンドウのエリアＡのうちの変更エリアＤの画像を切り出す。これにより、例えば、図８の例では画像Ｄ１が切り出される。画面処理部１２は、切り出した画像を圧縮する（ステップＳ１６）。第１送信部１４は、圧縮した画像と、切り出した画像の位置情報をＴＣＰでクライアント機器２０に送信する（ステップＳ１８）。これによれば、図８に示すように、アクティブウィンドウの変更エリアＤ１に係る画面データは、信頼性を保証するＴＣＰでクライアント機器２０に送信される。これにより、アクティブウィンドウの変更エリアＤ１の画像は確実にクライアント機器２０に反映される。
【００６８】
また、ステップＳ３８において、画面処理部１２は、キャプチャしたデスクトップ画面ＤｐからアクティブウィンドウのエリアＡ以外のエリア（＝非アクティブウィンドウのエリア）のうちの変更エリアＤの画像を切り出す（ステップＳ３８）。これにより、例えば、図８の例では画像Ｄ２が切り出される。画面処理部１２は、切り出した画像を圧縮する（ステップＳ３９）。第２送信部１５は、圧縮した画像と、該画像の位置情報をＵＤＰでクライアント機器２０に送信する（ステップＳ２４）。これによれば、非アクティブウィンドウの変更エリアＤ２に係る画面データは、信頼性を保証しないが高速なＵＤＰでクライアント機器２０に送信される。これにより、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することができる。
【００６９】
ステップＳ１８及びステップＳ２４の処理後、ＶＤＩが切断されたかが判定される（ステップＳ２６）。ＶＤＩが切断されていないと判定されると、今回取得したキャプチャ画像を前回キャプチャ画像として保持する（ステップＳ４０）。その後、ステップＳ１０に戻り、ＶＤＩが切断されるまでステップＳ１０以降の処理が繰り返し実行される。ステップＳ２６にてＶＤＩが切断されたと判定されたとき、本処理を終了する。
【００７０】
以上に説明した一実施形態の実施例２に係る画面送信処理によっても、アクティブウィンドウの変更エリアの画面データはＴＣＰで送信され、非アクティブウィンドウの変更エリアの画面データはＵＤＰで送信される。これにより、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することができる。特に、実施例２では、画面更新が行われた変更データのみをサーバ機器１０からクライアント機器２０へ送信するため、送信対象の画面データが少なくなり、画面データの送信速度をより高速にできる。
【００７１】
＜実施例３＞
［画面送信処理］
次に、一実施形態の実施例３に係る画面送信処理の一例について図９及び図１０を参照して説明する。図９は、一実施形態の実施例３に係る画面送信処理の一例を示すフローチャートである。図１０は、一実施形態の実施例３に係る画面送信処理を説明するための図である。本処理は、主にサーバ機器１０により実行される。
【００７２】
実施例３では、デスクトップ画面Ｄｐを動画としてサーバ機器１０からクライアント機器２０に送信する。動画では、デスクトップ画面Ｄｐの全体を圧縮したキーフレームと、キーフレームからの差分の画像を圧縮した予測フレームとによって構成される。図１０に示すように、キーフレームは一定間隔で送信され、予測フレームを送信する基準となるフレームであり、デスクトップ画面Ｄｐの全体を送信する。このため、サーバ機器１０からクライアント機器２０に確実に送信する必要がある。一方、予測フレームはキーフレームの間を補う画像であり、キーフレームとの差分の画像を送信する。このため、必ずしもすべてがクライアント機器２０側に送信される必要はない。
【００７３】
以下では、２０フレームごとにキーフレームを送信するものとし、図９のフローチャートでは、カウンタｎを用意する。そして、図１０に示すように、カウンタｎを２０で割った余りが０であるときにはキーフレームが送信され、それ以外のときには予測フレームが送信されるものとする。以下、実施例３に係る画面送信処理について説明する。
【００７４】
クライアント機器２０が、ＶＤＩアプリ２１１を動作させ、サーバ機器１０に接続すると図９の本処理が開始され、まず、画面処理部１２は、キーフレームと予測フレームを切り替えるカウンタｎに０を設定する初期化処理を行う（ステップＳ５０）。次に、画面処理部１２は、デスクトップ画面Ｄｐのキャプチャを開始する（ステップＳ１０）。
【００７５】
次に、判定部１３は、カウンタｎを２０で割った余りが０であるか否かを判定する（ステップＳ５２）。判定部１３は、カウンタｎを２０で割った余りが０であると判定した場合、送信対象がキーフレームであり、通信の信頼性が保証される必要があると判定し、ステップＳ５４に進む。一方、カウンタｎを２０で割った余りが０以外である場合、判定部１３は、送信対象が予測フレームであり、通信の信頼性を保証する必要はないと判定し、ステップＳ６０に進む。
【００７６】
ステップＳ５４において、画面処理部１２は、デスクトップ画面をキャプチャした画像をキーフレームとして圧縮する。第１送信部１４は、圧縮したキーフレームをＴＣＰでクライアント機器２０に送信する（ステップＳ５６）。次に、画面処理部１２は、送信したキーフレームを、前回キーフレームとして、後続する予測フレームを作成するために記憶部１１に保存する（ステップＳ５８）。
【００７７】
また、ステップＳ６０において、画面処理部１２は、デスクトップ画面をキャプチャした画像を前回キーフレームからの予測フレームとして圧縮する。第２送信部１５は、圧縮した予測フレームをＵＤＰでクライアント機器２０に送信する（ステップＳ６２）。
【００７８】
ステップＳ５８及びステップＳ６２の処理後、ＶＤＩが切断されたかが判定される（ステップＳ２６）。ＶＤＩが切断されていないと判定されると、画面処理部１２は、次回の送信対象をキーフレームとするか予測フレームとするかを切り替えるために、カウンタｎを１増やす（ステップＳ６４）。そして、ステップＳ１０に戻り、ＶＤＩが切断されるまでステップＳ１０以降のループ処理が繰り返し実行される。ステップＳ２６にてＶＤＩが切断されたと判定されたとき、本処理を終了する。
【００７９】
以上に説明した一実施形態の実施例３に係る画面送信処理によれば、図１０に示すように、画面全体の画像であるキーフレームはＴＣＰで送信され、キーフレームからの差分の画像である予測フレームはＵＤＰで送信される。これにより、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することができる。
【００８０】
＜実施例４＞
［画面送信処理］
次に、一実施形態の実施例４に係る画面送信処理の一例について図１１を参照して説明する。図１１は、一実施形態の実施例４に係る画面送信処理の一例を示すフローチャートである。本処理は、主にサーバ機器１０により実行される。
【００８１】
ＶＤＩでは、デスクトップ画面の更新が行われた場合にのみ、更新されたエリアの画像を送信することによって、データ転送量を抑えることが一般的である。すなわち、デスクトップ画面の特定のエリアに関して、サーバ機器１０側の画面の更新がクライアント機器２０側に正常に反映されなかった場合、クライアント機器２０側の表示が正常化されるのは次回サーバ機器１０の画面が更新されたときとなる。
【００８２】
ＶＤＩで使用するデスクトップ画面には、頻繁に更新が行われるエリアと更新が稀なエリアが存在しうる。頻繁に更新が行われているエリアは、クライアント機器２０側に正常に反映されなかった場合も、すぐにデスクトップ画面が更新されクライアント機器２０側も正常化されることが期待できる。そのため、必ずしも、サーバ機器１０の更新のすべてがクライアント機器２０に反映されなくとも許容することができる。これに対して更新が稀なエリアでは、サーバ機器１０側の画面の更新がクライアント機器２０側に正常に反映されなかった場合、クライアント機器２０側の表示が正常化するまでに長時間を要する恐れがある。そこで、更新が稀なエリアは確実にクライアント機器２０に反映されることが必要である。
【００８３】
そこで、以下に説明する実施例４に係る画面送信処理では、管理テーブル１１２を参照しながら、デスクトップ画面の更新が稀なエリアは通信の信頼性を保証するＴＣＰで画面データを送信する。一方、頻繁に更新が行われるエリアは通信の信頼性を保証しないが高速なＵＤＰで画面データを送信する。
【００８４】
実施例４では、デスクトップ画面のエリアを更新頻度が高いエリアとそうでないエリアに分類管理するために管理テーブル１１２を用意する。図１２は、一実施形態に係る管理テーブル１１２の一例を示す。
【００８５】
管理テーブル１１２には、デスクトップ画面上のエリアを表すメッシュ位置、メッシュ位置毎の前回キャプチャ時の画像データを示す前回画像、固定長のキューで管理される送信履歴（Ｈ１〜Ｈ５）が記憶されている。
【００８６】
ここでは、解像度が８００×６００のデスクトップ画面Ｄｐを１００×１００のメッシュに４８分割するときを例に挙げる。つまり、デスクトップ画面を４８（＝８×６）のメッシュ画像に分割する。
【００８７】
送信履歴Ｈ１が直近のキャプチャに対する送信状況であり、Ｈ５が５回前のキャプチャに対する送信状況である。Ｈ２〜Ｈ４は、それぞれ２回〜４回前のキャプチャに対する送信状況である。送信履歴情報のＡはＴＣＰ送信、ＢはＵＤＰ送信、Ｎは無送信を表す。デスクトップ画面をキャプチャし、メッシュ画像毎に本処理を行うたびに、Ｈ１〜Ｈ４の送信履歴情報は、Ｈ２〜Ｈ５の送信履歴情報にそれぞれ１シフトされる。そしてＨ５の送信履歴情報は破棄され、Ｈ１の送信履歴情報には最新の送信状況が記録される。
【００８８】
図１１の実施例４に係る画面送信処理では、クライアント機器２０が、ＶＤＩアプリ２１１を動作させ、サーバ機器１０に接続すると、まず、画面処理部１２は、管理テーブル１１２を初期化する（ステップＳ７０）。管理テーブル１１２の初期化では、メッシュに分割したエリアごとのレコードを作成し、前回の各メッシュ画像はすべて空白画像とし、送信履歴はＮとする。
【００８９】
次に、画面処理部１２は、デスクトップ画面Ｄｐのキャプチャを開始する（ステップＳ１０）。画面処理部１２は、デスクトップ画面Ｄｐをキャプチャしたら、その画面の画像をエリア毎の画像（以下、「メッシュ画像」ともいう。）に分割し（ステップＳ７２）、各メッシュ画像についてエリア毎に以下の処理を行う。
【００９０】
画面処理部１２は、何れかのエリアのメッシュ画像を取得する（ステップＳ７４）。判定部１３は、取得したメッシュ画像と前回の当該エリアのメッシュ画像とを比較し、変化の有無を検出する（ステップＳ７６）。判定部１３は、デスクトップ画面Ｄｐの該当エリアのメッシュ画像に変化があるかを判定する（ステップＳ７８）。
【００９１】
判定部１３は、該当エリアのメッシュ画像に変化があると判定すると、管理テーブル１１２を参照して、該当エリアの送信履歴を判定する（ステップＳ８０）。判定部１３は、該当エリアの送信履歴Ｈ１からＨ５がすべてＮ（無送信）であると判定した場合、そのエリアの画像は過去５回は送信されていないので、画面変更は稀であるとみなし、ＴＣＰで送信すると判定する。
【００９２】
画面処理部１２は、判定結果に基づき、対象となるメッシュ画像を圧縮し（ステップＳ８２）、第１送信部１４は、圧縮したメッシュ画像をＴＣＰで送信する（ステップＳ８４）。次に、画面処理部１２は、管理テーブル１１２の該当エリアのメッシュ位置に対応させて前回画像にメッシュ画像を保存し、送信履歴のＨ１からＨ４をＨ２からＨ５にシフトし、送信履歴のＨ１に信頼性を保証するＴＣＰ送信を示すＡを保存する（ステップＳ８６）。
【００９３】
ステップＳ８０において、判定部１３は、管理テーブル１１２を参照して、該当エリアのメッシュ画像の送信履歴Ｈ１〜Ｈ５のうち少なくともいずれかがＮ（無送信）ではないと判定した場合、直近５回で対象となるメッシュ画像が送信されたと判定する。そして、判定部は、該当メッシュ画像の画面変更は頻繁であるとみなし、圧縮したメッシュ画像をＵＤＰで送信すると判定する。
【００９４】
画面処理部１２は、判定結果に基づき、対象となるメッシュ画像を圧縮し（ステップＳ８８）、第２送信部１５は、圧縮したメッシュ画像をＵＤＰで送信する（ステップＳ９０）。次に、画面処理部１２は、管理テーブル１１２の該当エリアのメッシュ位置に対応させて前回画像にメッシュ画像を保存し、送信履歴のＨ１からＨ４をＨ２からＨ５にシフトし、送信履歴のＨ１に信頼性を保証しないＵＤＰ送信を示すＢを保存する（ステップＳ９２）。
【００９５】
ステップＳ７８において、判定部１３は、デスクトップ画面Ｄｐの該当エリアのメッシュ画像に変化がなかったと判定した場合、管理テーブル１１２のそのエリアの送信履歴の状態を判定する（ステップＳ９４）。送信履歴のＨ１からＨ４までがＮ（無送信）であり、最も古い履歴のＨ５がＢ（信頼性を保証しないＵＤＰ）であると判定した場合、最後に送信した画像は信頼性を保証しないＵＤＰ送信であるためクライアント機器２０に届いている保証はない。また、今後も頻繁には画面の変更が発生しない可能性がある。このため、この場合、メッシュ画像の画面に変化がなくとも第１送信部１４を用いて信頼性を保証するＴＣＰ送信を行うことによって、クライアント機器２０側に表示されるデスクトップ画面の画像を正常化することが好ましい。
【００９６】
そこで、ステップＳ９４において、判定部１３は、送信履歴のＨ１からＨ４までがＮ（無送信）であり、かつ、Ｈ５がＢ（ＵＤＰ送信）であると判定した場合、対象となるメッシュ画像を圧縮する（ステップＳ９６）。そして、第１送信部１４は、圧縮した対象となるメッシュ画像をＴＣＰで送信する（ステップＳ９８）。次に、次に、画面処理部１２は、管理テーブル１１２の該当エリアのメッシュ位置に対応させて前回画像にメッシュ画像を保存し、送信履歴のＨ１からＨ４をＨ２からＨ５にシフトし、送信履歴のＨ１に信頼性を保証するＴＣＰ送信を示すＡを記憶する（ステップＳ１００）。
【００９７】
一方、ステップＳ９４において、判定部１３は、送信履歴のＨ１からＨ４までがＮ（無送信）であり、かつ、Ｈ５がＢ（ＵＤＰ送信）であるという条件を満たさないと判定した場合、クライアント機器２０へのメッシュ画像の送信は行わないと判定する。この場合、画面処理部１２は、管理テーブル１１２の送信履歴のＨ１からＨ４をＨ２からＨ５にシフトし、送信履歴のＨ１に無送信を示すＮを記録する（ステップＳ１０２）。
【００９８】
ステップＳ８６、ステップＳ９２、ステップＳ１００及びステップＳ１０２の処理後、判定部１３は、未処理のメッシュ画像があるかを判定する（ステップＳ１０４）。判定部１３は、未処理のメッシュ画像があると判定すると、ステップＳ７４に戻り、未処理のメッシュ画像を取得して、ステップＳ７４以降の処理を実行する。
【００９９】
ステップＳ１０４において、判定部１３は、未処理のメッシュ画像がないと判定すると、ＶＤＩが切断されたかを判定する（ステップＳ２６）。ＶＤＩが切断されていないと判定されると、ステップＳ１０に戻り、ＶＤＩが切断されるまでステップＳ１０以降のループ処理が繰り返し実行される。ステップＳ２６にてＶＤＩが切断されたと判定されたとき、本処理を終了する。
【０１００】
以上に説明した一実施形態の実施例４に係る画面送信処理によれば、デスクトップ画面の更新が稀なエリアは通信の信頼性を保証するＴＣＰで画面データを送信し、頻繁に更新が行われるエリアは通信の信頼性を保証しないが高速なＵＤＰで画面データを送信する。これにより、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することができる。
【０１０１】
＜実施例５＞
一実施形態の実施例５に係る画面送信処理では、クライアント機器のマウス操作について、主要な位置情報は通信の信頼性を保証するＴＣＰで送信し、詳細な位置情報は通信の信頼性を保証しないＵＤＰで送信する例を挙げて説明する。
【０１０２】
一実施形態の実施例５に係る画面送信処理を実行するクライアント機器２０及びサーバ機器１０の機能構成の一例を説明した後、一実施形態の実施例５に係る画面送信処理の一例について説明する。図１３は、一実施形態に係るクライアント機器２０及びサーバ機器１０の機能構成の他の一例を示す図である。
【０１０３】
図１３に示すクライアント機器２０及びサーバ機器１０の各部は、図２に示したクライアント機器２０及びサーバ機器１０の各部と同一符号が付与されている場合は同一機能を有するため、ここでは機能説明を省略する。
【０１０４】
図１３に示すクライアント機器２０は、図２に示したクライアント機器２０が有する記憶部２１、第１受信部２２、第２受信部２３、画像更新部２４、表示部２５、受付部２６に加えて第１送信部２８ａ、第２送信部２８ｂ及び判定部２９を有する。
【０１０５】
第１送信部２８ａは、通信の信頼性を保証する仕組みを持ち、データを損失した場合には再送により必ずデータが受信側のサーバ機器１０に転送される第１通信プロトコルを用いてデータを送信する。第２送信部２８ｂは、通信の信頼性を保証する仕組みを排し、データの伝送を高速化した第２通信プロトコルを用いてデータを送信する。
【０１０６】
判定部２９は、受信側のサーバ機器１０で必ず処理することが必要なデータか、必ずしも処理する必要がないデータかを判定する。
【０１０７】
図１３に示すサーバ機器１０は、図２に示したサーバ機器１０が有する記憶部１１、画面処理部１２、判定部１３、第１送信部１４、第２送信部１５、制御部１７に加えて第１受信部１６ａ、第２受信部１６ｂ及び操作実行部１８を有する。
【０１０８】
第１受信部１６ａは、通信の信頼性を保証する第１通信プロトコルを用いてクライアント機器２０の第１送信部２８ａから送信されたデータを受信する。第２受信部１６ｂは、通信の信頼性を保証しない第２通信プロトコルを用いてクライアント機器２０の第２送信部２８ｂから送信されたデータを受信する。第１受信部１６ａは、データが到着しない場合、一定時間待機し、その後、再送要求をサーバ機器１０に送信する。第２受信部１６ｂは、データが到着するか否かを検知しる仕組みを有さず、データが到着しない場合にはそのデータを無視する。操作実行部１８は、クライアント機器２０から受信したデータに基づき、デスクトップ画面Ｄｐの操作を実行する。
【０１０９】
［画面送信処理］
次に、一実施形態の実施例５に係る画面送信処理の一例について図１４及び図１５を参照して説明する。図１４は、一実施形態の実施例５に係る画面送信処理の一例を示すフローチャートである。図１５は、一実施形態の実施例５に係る操作送信処理を説明するための図である。本処理は、主にクライアント機器２０によって実行される。
【０１１０】
実施例５では、クライアント機器２０で行われるマウス操作を例に挙げて説明する。ただし、ユーザ操作は、マウス操作に限られず、キーボード操作やタッチパネル操作等のあらゆる入力操作であってもよく、本画面送信処理は、いずれの入力操作に対しても適用できる。
【０１１１】
実施例５では、図１５に示すように、ユーザ操作によるマウスの移動に対して、一定期間経過毎のマウス操作の主要な位置情報（例えばＭ１，Ｍ２，Ｍ４・・・）及びクリック操作等の主要な位置情報（例えばＭ３）は、通信の信頼性を保証するＴＣＰで送信する。一方、マウス操作の詳細な位置情報（例えばｍ１，ｍ２，ｍ３，ｍ４、・・・ｍ１０）は、通信の信頼性を保証しないＵＤＰで送信する。
【０１１２】
クリック操作等のマウス操作の主要な位置情報は、クライアント機器２０からサーバ機器１０に必ず送信される必要がある。一方、細かなマウスの移動に伴うマウスの位置情報のすべてをサーバ機器１０に送信する必要はない。そこで、ボタン操作を伴うイベントと、一定時間経過毎のマウス操作を伴うマウスイベント（図１５のＭ１、Ｍ２、Ｍ３，Ｍ４等）は通信の信頼性を保証するＴＣＰで送信し、その他のマウス移動イベント（図１５のｍ１〜ｍ１０等）は通信の信頼性を保証しないが高速なＵＤＰで送信する。
【０１１３】
マウス操作時、クライアント機器２０からサーバ機器１０へマウスイベントが送信される。このとき、図１４に示すように、受付部２６は、マウス操作を受け付け、マウスの位置情報とボタン状態を取得する（ステップＳ１１０）。次に、判定部２９は、受け付けた操作がボタン操作か否かを判定する（ステップＳ１１２）。判定部２９は、受け付けた操作がボタン操作であると判定すると、第１送信部２８ａは、受け付けたマウスの位置情報とボタン状態の情報を通信の信頼性を保証するＴＣＰで送信する（ステップＳ１１４）。そして、第１送信部２８ａは、送信時刻を記憶部２１に保存する（ステップＳ１１６）。
【０１１４】
ステップＳ１１２において、判定部２９は、ボタン操作でないと判定すると、操作処理部３０は、前回の送信時刻からの経過時間を算出する（ステップＳ１１８）。
【０１１５】
判定部２９は、経過時間が予め定められた既定の時間を超えたかを判定する（ステップＳ１２０）。判定部２９が経過時間が既定の時間を超えたと判定した場合、第１送信部２８ａは、マウスイベントの位置情報を、通信の信頼性を保証するＴＣＰで送信する（ステップＳ１２２）。これは、前回の送信時刻からの経過時間が規定の時間を超えているため、確実にマウスの位置をサーバ機器１０に反映するためである。
【０１１６】
一方、ステップＳ１２０において、判定部２９が経過時間が既定の時間を超えていないと判定した場合、第２送信部２８ｂは、マウスイベントの位置情報を通信の信頼性を保証しないＵＤＰで送信する（ステップＳ１２６）。この場合、前回の送信からさほど時間が経過していないため、マウスの移動がサーバ機器１０に伝えられなくとも大きな問題はない。よって、マウスイベントのマウスの位置情報を通信の信頼性を保証しないが高速なＵＤＰを使用して送信する。
【０１１７】
ステップＳ１１６、ステップＳ１２４及びステップＳ１２６の処理後、判定部１３は、ＶＤＩが切断されたかを判定する（ステップＳ１２８）。ＶＤＩが切断されていないと判定されると、ステップＳ１１０に戻り、次のマウス操作を受け付け、ＶＤＩが切断されるまでステップＳ１１０以降のループ処理が繰り返し実行される。ステップＳ１２８にてＶＤＩが切断されたと判定されたとき、本処理を終了する。
【０１１８】
以上に説明した一実施形態の実施例５に係る画面送信処理によれば、クライアント機器２０において、クリック操作等の主要な情報は、クライアント機器２０からサーバ機器１０に送信される必要がある。一方、細かなマウスの移動に伴うマウスの位置情報のすべてをサーバ機器１０に送信する必要はない。そこで、ボタン操作を伴うイベントと、一定時間経過毎のマウスイベントは通信の信頼性を保証するＴＣＰで送信し、その他のマウス移動イベントは通信の信頼性を保証しないが高速なＵＤＰで送信する。これにより、通信のパフォーマンスを維持しつつ、送信すべき画面データを正しく送信することができる。
【０１１９】
以上に説明したように、一実施形態に係る画面送受信システム１によれば、データが送信先に届かなくても処理を継続できると判断した場合には、データをネットワーク４０に送出する側で信頼性を保証しない第２通信プロトコルで高速に伝送することを選択する。これにより、ＶＤＩのパフォーマンスを向上させることができる。
【０１２０】
また、受信側では、第２通信プロトコルで受信するデータに関しては、データ損失の検知が不要であり、伝送データの到着の遅延が損失かを判定するための一定の待機時間が不要なため、ＶＤＩのパフォーマンスをより向上させることができる。
【０１２１】
以上、画面送信プログラム、画面送信方法及び画面送受信システムを上記実施形態により説明した。ただし、本開示の画面送信プログラム、画面送信方法及び画面送受信システムは上記実施形態に限定されるものではなく、本開示の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。
【０１２２】
デスクトップ画面の処理の一部がクラウド上のサーバ機器１０で実行され、他の処理が端末で実行されるようなネットワークシステム内の複数のコンピュータが連携して一連の処理が行われてもよい。
【０１２３】
以上の説明に関し、更に以下の項を開示する。
（付記１）
サーバ機器は、
アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
（付記２）
前記サーバ機器は、
アクティブウィンドウのエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第１通信プロトコルで前記クライアント機器に送信し、
アクティブウィンドウでないエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第２通信プロトコルで前記クライアント機器に送信する、
付記１に記載の画面送信プログラム。
（付記３）
アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
ことをサーバ機器のコンピュータが実行する画面送信方法。
（付記４）
アクティブウィンドウのエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第１通信プロトコルで前記クライアント機器に送信し、
アクティブウィンドウでないエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第２通信プロトコルで前記クライアント機器に送信する、
付記３に記載の画面送信方法。
（付記５）
サーバ機器とクライアント機器とを有する画面送受信システムであって、
前記サーバ機器は、
アクティブウィンドウのエリアに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信する第１送信部と、
アクティブウィンドウでないエリアに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する第２送信部と、を有し、
前記クライアント機器は、
前記アクティブウィンドウのエリアに係る画面データを受信する第１受信部と、
前記アクティブウィンドウでないエリアに係る画面データを受信する第２受信部と、
受信した前記アクティブウィンドウのエリアに係る画面データと前記アクティブウィンドウでないエリアに係る画面データとに基づき、画面上の画像を更新する画像更新部と、を有する、
画面送受信システム。
（付記６）
前記第１送信部は、
アクティブウィンドウのエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第１通信プロトコルで前記クライアント機器に送信し、
前記第２送信部は、
アクティブウィンドウでないエリアであって、前回の画面データから変更されたエリアに係る画面データを、前記第２通信プロトコルで前記クライアント機器に送信する、
付記５に記載の画面送受信システム。
（付記７）
サーバ機器は、
画面全体の画像を示すキーフレームに係る画面データを、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
キーフレームとの差分の画像を示す予測フレームに係る画面データを、第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
（付記８）
サーバ機器は、
画面全体の画像を分割した分割画像に係る画面データであって、前回の分割画像から変化した画面データのうち、所定回数分の画面データの送信履歴を記憶した記憶部を参照して、画面データが所定回数送信されていない場合、該画面データを通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
画面データが所定回数の少なくともいずれかで送信されている場合、該画面データを第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
（付記９）
クライアント機器は、
画面の操作イベントを受け付け、
前記画面の操作イベントのうち、所定時間毎の操作イベント及び特定の操作イベントの位置情報を、通信の信頼性を保証する第１通信プロトコルでクライアント機器に送信し、
前記画面の操作イベントのうち、前記所定時間毎の操作イベント及び特定の操作イベント以外の操作イベントの位置情報を、前記第１通信プロトコルより高速であって、通信の信頼性を保証しない第２通信プロトコルでクライアント機器に送信する、
処理をコンピュータに実行させる画面送信プログラム。
【符号の説明】
【０１２４】
１    画面送受信システム
１０  サーバ機器
１１  記憶部
１２  画面処理部
１３  判定部
１４  第１送信部
１５  第２送信部
１６  受信部
１６ａ  第１受信部
１６ｂ  第２受信部
１７  制御部
１８  操作実行部
２０  クライアント機器
２１  記憶部
２２  第１受信部
２３  第２受信部
２４  画像更新部
２５  表示部
２６  受付部
２７  制御部
２８  送信部
２８ａ  第１送信部
２８ｂ  第２送信部
２９  判定部
３０  操作処理部
１１１  ウィンドウ一覧テーブル
１１２  管理テーブル
【図１】
2019191962.tif 000003
【図２】
2019191962.tif 000004
【図３】
2019191962.tif 000005
【図４】
2019191962.tif 000006
【図５】
2019191962.tif 000007
【図６】
2019191962.tif 000008
【図７】
2019191962.tif 000009
【図８】
2019191962.tif 000010
【図９】
2019191962.tif 000011
【図１０】
2019191962.tif 000012
【図１１】
2019191962.tif 000013
【図１２】
2019191962.tif 000014
【図１３】
2019191962.tif 000015
【図１４】
2019191962.tif 000016
【図１５】
2019191962.tif 000017