JP2015118684A - 通信システム及び通信プログラム - Google Patents

Abstract

【課題】仮想デバイスドライバを用いることなくリモートアクセス環境を実現することが可能な、通信システム及び通信プログラムを提供する。【解決手段】クライアント装置と前記クライアント装置の仮想化されたデスクトップ環境として機能するサーバ装置とを含む通信システムであって、前記サーバ装置は、アプリケーションから前記クライアント装置に接続された外部装置への命令情報を前記クライアント装置に送信する第１の通信プログラムを有し、前記クライアント装置は、デバイスドライバと、前記サーバ装置から前記命令情報を受信し、受信された前記命令情報を入出力制御情報に変換して前記外部装置に対応する前記デバイスドライバに中継する第２の通信プログラムと、を有する、通信システム。【選択図】図２

Description

本発明は、通信システム及び通信プログラムに関する。

近年、インターネット環境の進歩やモバイル端末の普及等に伴い、クライアントからサーバ上のアプリケーションを遠隔操作するためのリモートアクセス環境に関する技術が注目されている。

このような技術のひとつとして、リモートデスクトップ接続が挙げられる。例えば、サーバとクライアントとがリモートデスクトップ接続により接続されると、クライアントは、サーバを直接操作しているかのようなデスクトップ画面を表示して、サーバ上のプログラムやファイルにアクセス可能となる。ここで、クライアントにＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどのローカルデバイスが接続される場合がある。このような場合に、あたかもサーバにそのローカルデバイスが接続されたかのような制御を行うための技術が開発されている。

例えば、下記特許文献１では、クライアントで用いられるデバイスドライバと同様の仮想デバイスドライバをサーバに導入し、サーバが仮想デバイスドライバを介してクライアントに接続されたローカルデバイスを制御する技術が開示されている。また、サーバとクライアントとの通信の確立に関して、下記特許文献３では、クライアントから接続された場合に、サーバ側でクライアントのＩＰアドレスを記憶し、必要に応じてサーバ側からクライアントにデータを送信する技術が開示されている。

また、リモートアクセス環境とは異なる分野においても、端末装置に接続されたデバイスにアクセスするための技術が開発されている。例えば、下記特許文献２では、端末装置内のデバイスドライバを制御するためのデバイス制御実行基板を設け、上位層からのデバイスの呼び出し制御を抽象化する技術が開示されている。

特表２００９−５０８２１２号公報 特開２００７−３１６７８６号公報 特開２００３−２９６２７０号公報

しかし、上記特許文献１に記載された技術は、サーバで用いられる仮想デバイスドライバとして、クライアントで用いられるデバイスドライバと同じものを使用可能であることを前提とした技術である。従って、同じものを使用することが困難な場合には、リモートアクセス環境の実現が困難になるという問題があった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、仮想デバイスドライバを用いることなくリモートアクセス環境を実現することが可能な、新規かつ改良された通信システム及び通信プログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、クライアント装置と前記クライアント装置の仮想化されたデスクトップ環境として機能するサーバ装置とを含む通信システムであって、前記サーバ装置は、アプリケーションから前記クライアント装置に接続された外部装置への命令情報を前記クライアント装置に送信する第１の通信プログラムを有し、前記クライアント装置は、デバイスドライバと、前記サーバ装置から前記命令情報を受信し、受信された前記命令情報を入出力制御情報に変換して前記外部装置に対応する前記デバイスドライバに中継する第２の通信プログラムと、を有する、通信システムが提供される。

前記第２の通信プログラムは、前記クライアント装置に接続された前記外部装置を識別し、識別した前記外部装置を示す識別情報を前記サーバ装置に送信してもよい。

前記命令情報は、前記識別情報を含み、前記第２の通信プログラムは、前記識別情報が示す前記外部装置に対応する前記デバイスドライバに前記入出力制御情報を中継してもよい。

前記第１の通信プログラムは、前記仮想化されたデスクトップ環境の接続元である前記クライアント装置を識別し、識別した前記クライアント装置に前記命令情報を送信してもよい。

前記第２の通信プログラムは、前記入出力制御情報に基づき前記外部装置から出力された出力情報を前記サーバ装置に送信し、前記第１の通信プログラムは、前記クライアント装置から受信された前記出力情報を前記アプリケーションに中継してもよい。

前記入出力制御情報は、ＩＯＣＴＬ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）であってもよい。

前記サーバ装置は、前記第２の通信プログラムとの間で通信を確立して前記前記第２の通信プログラムと前記第１の通信プログラムとの間の通信を中継する通信管理プログラムと、前記外部装置との通信を行うための接続情報を記憶する記憶部と、をさらに備え、前記通信管理プログラムは、前記第２の通信プログラムからの接続要求に応じて前記第２の通信プログラムとの通信を確立し、前記記憶部に記憶された前記接続情報を用いて前記第１の通信プログラムと前記第２の通信プログラムとの通信を中継してもよい。

前記接続情報は、前記クライアント装置の識別情報、前記外部装置の識別情報、および通信チャネル情報を含んでもよい。

前記通信管理プログラムは、前記クライアント装置の識別情報を検索キーとして前記記憶部から前記接続情報を検索してもよい。

また、上記課題を解決するために、本発明の別の観点によれば、クライアント装置と前記クライアント装置の仮想化されたデスクトップ環境として機能するサーバ装置のアプリケーションとの通信を制御する通信プログラムであって、第１の前記通信プログラムは、前記サーバ装置に含まれ、前記アプリケーションから前記クライアント装置に接続された外部装置への命令情報を前記クライアント装置に送信し、第２の前記通信プログラムは、前記クライアント装置に含まれ、前記サーバ装置から前記命令情報を受信し、受信された前記命令情報を入出力制御情報に変換して前記外部装置に対応するデバイスドライバに中継する、通信プログラムが提供される。

以上説明したように本発明によれば、仮想デバイスドライバを用いることなくリモートアクセス環境を実現することが可能である。

本発明の一実施形態に係る通信システムの概要を示す図である。 第１の実施形態に係る通信システムの構成を示すブロック図である。 第１の実施形態に係るクライアントの動作を示すフローチャートである。 第１の実施形態に係るサーバの動作を示すフローチャートである。 第１の実施形態に係る通信システムの動作を示すシーケンス図である。 第１の実施形態に係る通信システムの動作を示すシーケンス図である。 第２の実施形態に係る通信システムの概要を説明するための図である。 第３の実施形態に係る通信システムの構成を示すブロック図である 第３の実施形態に係る通信システムの概要を説明するための図である。 第３の実施形態に係る通信システムの動作を示すシーケンス図である。 第３の実施形態に係る通信システムの動作を示すシーケンス図である。 第３の実施形態に係る通信システムの動作を示すシーケンス図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

＜１．本発明の一実施形態に係る通信システムの概要＞
まず、図１を参照して、本発明の一実施形態に係る通信システムの概要を説明する。

図１は、本発明の一実施形態に係る通信システムの概要を示す図である。図１に示すように、本実施形態に係る通信システムは、ネットワーク４により接続されたサーバ１（サーバ装置）およびクライアント２（クライアント装置）から成る。クライアント２には、ローカルデバイス３Ａ、３Ｂといった複数のローカルデバイス（外部装置）が接続され得る。以下では、ローカルデバイス３Ａ、３Ｂをはじめとする複数のローカルデバイスを特に区別する必要がない場合、ローカルデバイス３と総称する。

サーバ１およびクライアント２は、ネットワーク４を介したリモートデスクトップ接続により接続することが可能である。クライアント２は、サーバ１とのリモートデスクトップ接続により仮想のデスクトップ環境（以下、仮想環境とも称する）を構築する。サーバ１は、クライアント２の仮想環境として機能する。即ち、クライアント２は、サーバ１を直接操作しているかのようなデスクトップ画面を表示し、ユーザは、クライアント２に表示されたデスクトップ画面からサーバ１上のプログラムやファイルにアクセスすることができる。なお、リモートデスクトップ接続による仮想環境は、リモートアクセス環境の一例であり、本発明はかかる例に限定されない。

ネットワーク４は、ネットワーク４に接続されている装置から送信される情報の有線、または無線の伝送路である。例えば、ネットワーク４は、インターネットや専用線、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等により構成される。他にも、ネットワーク４は、モデムを介した直接ダイアルアップ、企業ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）により構成されてもよい。サーバ１は、ひとつ又は複数のクライアント２とネットワーク４を介して接続され、例えばＴＣＰ／ＩＰ等の伝送制御プロトコルにより相互に通信する。

図１に示すように、クライアント２にはローカルデバイス３が接続され得る。上述したように、上記特許文献１に開示された技術では、サーバで用いられる仮想デバイスドライバとして、クライアントで用いられるデバイスドライバと同じものを使用可能であることを前提としている。よって、同じものを使用することが困難な場合には、リモートアクセス環境の実現が困難になるという問題があった。

まず、第１に、デバイスドライバが遠隔地で動作されることを想定された設計になっていないという問題がある。例えば、遠隔地にあるサーバ１の仮想デバイスドライバが、ＩＯＣＴＬ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）等の制御コードを送信する場合を考える。このような場合、ＩＯＣＴＬを発行する仮想デバイスドライバは短時間で応答が帰ってくることを期待しているため、ネットワーク４の遅延等によりＩＯＣＴＬのタイムアウトエラー等が発生してしまう場合があった。また、接続されるローカルデバイスによっては、クライアント２からサーバ１へのリダイレクトが正常に動作せず、仮想デバイスドライバがサーバ１上に作成できない場合があった。

第２に、サーバ１とクライアント２とが異なるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）により動作する場合に対応していないという問題がある。詳しくは、ローカルデバイス３がクライアント２に接続されることを想定してデバイスメーカーが作成したデバイスドライバが、仮想デバイスドライバとして動作するため、サーバ１のＯＳをデバイスメーカーがサポートしていない場合は遠隔操作を実現できない。例えば、ローカルデバイス３が、ＷｉｎｄｏｗｓＸＰ（登録商標）（３２ｂｉｔ）やＷｉｎｄｏｗｓ（登録商標）７（３２ｂｉｔ）等のＯＳで動作するＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）に接続されることが想定されている場合を考える。このような場合、サーバ１のＯＳがＷｉｎｄｏｗｓＳｅｒｖｅｒ（登録商標）２００８（６４ｂｉｔ）等のサーバ用ＯＳやＬｉｎｕｘ（登録商標）等のＷｉｎｄｏｗｓ（登録商標）ＯＳ以外のＯＳである場合、サーバ１上のアプリケーションはローカルデバイス３を遠隔制御できなかった。

そこで、上記事情を一着眼点にして本発明の一実施形態に係る通信システムを創作するに至った。本発明の一実施形態に係る通信システムは、仮想デバイスドライバを用いることなくリモートアクセス環境を実現することができる。

具体的には、本実施形態に係るサーバ１は、仮想デバイスドライバではなく、サーバ用デバイス通信プログラム１３０（第１の通信プログラム）とクライアント用デバイス通信プログラム２３０（第２の通信プログラム）との通信を介してローカルデバイス３を制御する。サーバ用デバイス通信プログラム１３０は、サーバ１によるデバイス制御を中継する、サーバ１に格納されたプログラムである。クライアント用デバイス通信プログラム２３０は、サーバ用デバイス通信プログラム１３０から受信したデバイス制御のための情報をデバイスドライバに中継する、クライアント２に格納されたプログラムである。

本実施形態によれば、サーバ１で仮想デバイスドライバが動作することがなく、クライアント２内でのみデバイスドライバが動作するため、ネットワーク４の遅延等によるＩＯＣＴＬのタイムアウトエラー等の発生を回避することができる。また、デバイスドライバは、クライアント２でのみ用いられ、サーバ１で用いられることがないため、サーバ１のＯＳがデバイスメーカーのサポート外であっても、リモートアクセス環境を実現することができる。

以上、本発明の一実施形態に係る通信システムの概要を説明した。続いて、本発明の各実施形態について詳細に説明する。

＜２．実施形態＞
［２−１．第１の実施形態］
まず、図２を参照して、第１の実施形態に係る通信システムの構成を説明する。図２は、第１の実施形態に係る通信システムの構成を示すブロック図である。

［２−１−１．サーバ１の構成］
図２に示すように、サーバ１は、プロセッサ１０１、メモリ１０２、リモート・サービス・サーバ・アプリケーション１１０、アプリケーション１２０、およびサーバ用デバイス通信プログラム１３０を有する。サーバ１は、ＷｉｎｄｏｗｓＳｅｒｖｅｒ（登録商標）２００８や、Ｌｉｎｕｘ（登録商標）等のＯＳにより動作する。

（プロセッサ１０１）
プロセッサ１０１は、演算処理装置および制御装置として機能し、各種プログラムに従ってサーバ１内の動作全般を制御する。プロセッサ１０１は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、マイクロプロセッサによって実現される。なお、プロセッサ１０１は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、および適宜変化するパラメータ等を一時記憶するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含んでいてもよい。

（メモリ１０２）
メモリ１０２は、所定の記録媒体に対してデータの記録再生を行う部位である。メモリ１０２は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）として実現される。もちろん記録媒体としては、フラッシュメモリ等の固体メモリ、固定メモリを内蔵したメモリカード、光ディスク、光磁気ディスク、ホログラムメモリなど各種考えられ、メモリ１０２としては採用する記録媒体に応じて記録再生を実行できる構成とされればよい。なお、図２では、リモート・サービス・サーバ・アプリケーション１１０、アプリケーション１２０、およびサーバ用デバイス通信プログラム１３０といった構成要素がメモリ１０２から独立した要素として表現されているが、メモリ１０２に記憶されていてもよい。

（リモート・サービス・サーバ・アプリケーション１１０）
リモート・サービス・サーバ・アプリケーション１１０は、リモート・サービス・クライアント・アプリケーション２１０との通信により、サーバ１をクライアント２の仮想化されたデスクトップ環境として機能させるプログラムである。詳しくは、リモート・サービス・サーバ・アプリケーション１１０は、ＲＤＰ（Ｒｅｍｏｔｅ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）などの通信プロトコルにより、リモート・サービス・クライアント・アプリケーション２１０と通信する。このようなＲＤＰによる通信は、ターミナルサービスシステム等のリモート・クライアント・アクセスシステムとして実装されてもよい。

リモート・サービス・サーバ・アプリケーション１１０は、仮想環境のデスクトップ画面の情報を、リモート・サービス・クライアント・アプリケーション２１０に送信する。他方、仮想環境におけるローカルデバイス３への入出力制御は、リモート・サービス・サーバ・アプリケーション１１０によるＲＤＰを介した通信ではなく、後述するサーバ用デバイス通信プログラム１３０により行われる。

（アプリケーション１２０）
アプリケーション１２０は、マルチメディア処理、データベースアクセス等を行う各種アプリケーションである。アプリケーション１２０は、クライアント２による遠隔操作により動作する。この際、アプリケーション１２０は、リモート・サービス・サーバ・アプリケーション１１０を介して画面出力情報をクライアント２に送信する。他方、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０を介してローカルデバイス３を制御するための情報をクライアント２に送信することで、ローカルデバイス３を制御する。ここで、アプリケーション１２０は、クライアント２に接続されたローカルデバイス３を、ＩＯＣＴＬコード内の物理デバイスオブジェクト（ＰＤＯ：Ｐｈｙｓｉｃａｌ Ｄｅｖｉｃｅ Ｏｂｊｅｃｔ）としては識別しない。アプリケーション１２０は、後述するサーバ用デバイス通信プログラム１３０により提供されるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を介して、ローカルデバイス３の制御を行う。そして、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０を介して受信した、ローカルデバイス３からの応答に基づいて動作する。

上述したように、仮想環境におけるローカルデバイス３への入出力制御は、リモート・サービス・サーバ・アプリケーション１１０によるＲＤＰを介した通信ではなく、後述のサーバ用デバイス通信プログラム１３０により行われる。具体的には、アプリケーション１２０は、ローカルデバイス３の制御のために、上記特許文献１で開示された技術で用いられているような、ＲＤＰを介して通信する入出力要求パケット（ＩＲＰ：Ｉ／Ｏ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ）を使用しない。アプリケーション１２０は、独自プロトコルにより記述された入出力要求情報（命令情報）を使用して、ローカルデバイス３を制御する。

入出力要求情報は、クライアント２に接続された１つ以上のローカルデバイス３から特定のローカルデバイス３を識別するための識別情報、およびローカルデバイス３への出力命令や入力命令等の制御情報の組み合わせを、１つ以上含む情報である。入出力要求情報を記述するための独自プロトコルとしては、例えばＸＭＬ（ＥＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）等を用いてもよい。なお、入出力要求情報は、サーバ用デバイス通信プログラム１３０により中継され、クライアント用デバイス通信プログラム２３０によりＩＯＣＴＬ等の制御コードに変換される。入出力要求情報は、１つまたは複数のローカルデバイス３への要求を含んでいてもよい。

（サーバ用デバイス通信プログラム１３０）
サーバ用デバイス通信プログラム１３０は、アプリケーション１２０からクライアント２に接続されたローカルデバイス３への入出力要求情報を、クライアント２に送信する機能を有する。サーバ用デバイス通信プログラム１３０は、クライアント用デバイス通信プログラム２３０を介して、クライアント２のドライバスタックと通信する。ここで、サーバ用デバイス通信プログラム１３０は、特定のローカルデバイス３に対して特有である。詳しくは、サーバ用デバイス通信プログラム１３０は、ローカルデバイス３のデバイスドライバで提供されるＡＰＩと同じインターフェース仕様を提供する。このため、アプリケーション１２０は、リンク先を仮想デバイスドライバからサーバ用デバイス通信プログラム１３０に変更するだけで、既存の処理を変更することなく又は最小限の変更でローカルデバイス３を制御することができる。なお、サーバ用デバイス通信プログラム１３０は、アプリケーション１２０がローカルデバイス３を制御できるように常駐する。

ローカルデバイス３は、サーバ用デバイス通信プログラム１３０により送信された入出力要求情報に基づいて動作した結果である入出力応答情報（出力情報）を出力する。入出力応答情報とは、例えばＩＯＣＴＬ応答である。サーバ用デバイス通信プログラム１３０は、クライアント用デバイス通信プログラム２３０を介してローカルデバイス３から受信された入出力応答情報を、アプリケーション１２０に中継する。このように、サーバ用デバイス通信プログラム１３０は、アプリケーション１２０からローカルデバイス３への入出力要求情報、およびローカルデバイス３からアプリケーション１２０への入出力応答情報を中継する。このような中継を、以下ではデバイス中継通信とも称する。デバイス中継通信により、アプリケーション１２０によるローカルデバイス３の制御が可能となる。

以上、サーバ１の構成を説明した。続いて、クライアント２の構成を説明する。

［２−１−２．クライアント２の構成］
図２に示すように、クライアント２は、プロセッサ２０１、メモリ２０２、リモート・サービス・クライアント・アプリケーション２１０、クライアント用デバイス通信プログラム２３０、デバイスドライバ２４０、カーネルドライバ２５１、バスドライバ２５２、ホストコントローラドライバ２５３、およびホストコントローラ２５４を有する。クライアント２は、ＷｉｎｄｏｗｓＸＰ（登録商標）（３２ｂｉｔ）やＷｉｎｄｏｗｓ（登録商標）７（３２ｂｉｔ）等のＯＳで動作する、ＰＣやノートＰＣ、タブレット端末等のスタンドアローン型のコンピュータである。クライアント２は、ローカルに格納していないファイルやアプリケーションにアクセスするために、リモートアクセス環境によりサーバ１と通信する。

（プロセッサ２０１）
プロセッサ２０１は、演算処理装置および制御装置として機能し、各種プログラムに従ってクライアント２内の動作全般を制御する。プロセッサ２０１は、例えばＣＰＵ、マイクロプロセッサによって実現される。なお、プロセッサ２０１は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ、および適宜変化するパラメータ等を一時記憶するＲＡＭを含んでいてもよい。

（メモリ２０２）
メモリ２０２は、所定の記録媒体に対してデータの記録再生を行う部位である。メモリ２０２は、例えばＨＤＤとして実現される。もちろん記録媒体としては、フラッシュメモリ等の固体メモリ、固定メモリを内蔵したメモリカード、光ディスク、光磁気ディスク、ホログラムメモリなど各種考えられ、メモリ２０２としては採用する記録媒体に応じて記録再生を実行できる構成とされればよい。なお、図２では、リモート・サービス・クライアント・アプリケーション２１０、およびクライアント用デバイス通信プログラム２３０等の構成要素がメモリ２０２から独立した要素として表現されているが、メモリ２０２に記憶されていてもよい。

（リモート・サービス・クライアント・アプリケーション２１０）
リモート・サービス・クライアント・アプリケーション２１０は、リモート・サービス・サーバ・アプリケーション１１０との通信により、サーバ１をクライアント２の仮想化されたデスクトップ環境として機能させるプログラムである。詳しくは、リモート・サービス・クライアント・アプリケーション２１０は、ＲＤＰなどの通信プロトコルにより、リモート・サービス・サーバ・アプリケーション１１０と通信する。このようなＲＤＰによる通信は、ターミナルサービスシステム等のリモート・クライアント・アクセスシステムとして実装されてもよい。リモート・サービス・クライアント・アプリケーション２１０は、仮想環境のデスクトップ画面の情報を、リモート・サービス・サーバ・アプリケーション１１０から受信する。

（クライアント用デバイス通信プログラム２３０）
クライアント用デバイス通信プログラム２３０は、サーバ１から入出力要求情報を受信し、受信された入出力要求情報を入出力制御情報に変換して、ローカルデバイス３に対応するデバイスドライバ２４０に中継する機能を有する。入出力制御情報とは、入出力要求パケット（ＩＲＰ：Ｉ／Ｏ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ）や、特に入出力制御コード（ＩＯＣＴＬ：Ｉ／Ｏ Ｃｏｎｔｒｏｌ）と呼ばれるＩＲＰの特別なグループの命令である。クライアント用デバイス通信プログラム２３０は、独自プロトコルにより記述された入出力要求情報を、入出力制御情報に変換してデバイスドライバ２４０に中継することで、アプリケーション１２０からローカルデバイス３へのアクセスを実現する。クライアント用デバイス通信プログラム２３０は、サーバ１のアプリケーション１２０がローカルデバイス３を制御できるように常駐する。クライアント用デバイス通信プログラム２３０は、クライアント２のドライバスタックの最上位の要素または層として捉えることができる。

クライアント用デバイス通信プログラム２３０は、ＩＯＣＴＬコード内の物理デバイスオブジェクトとして、ローカルデバイス３を識別する。クライアント用デバイス通信プログラム２３０は、識別したローカルデバイス３を示す識別情報をサーバ１に送信する。サーバ用デバイス通信プログラム１３０から受信した入出力要求情報には、アプリケーション１２０がどのローカルデバイス３へのアクセスを行うかを示すため、この識別情報が含まれている。よって、クライアント用デバイス通信プログラム２３０は、この識別情報が示すローカルデバイス３に対応するデバイスドライバ２４０に、入出力制御情報を中継する。これにより、クライアント２に複数のローカルデバイス３が接続された場合であっても、アプリケーション１２０は、各ローカルデバイス３を混同することなく、それぞれを制御することができる。

ローカルデバイス３は、サーバ用デバイス通信プログラム１３０により送信された入出力要求情報に基づいて動作した結果である入出力応答情報を出力する。クライアント用デバイス通信プログラム２３０は、ローカルデバイス３から出力された入出力応答情報を、サーバ１に送信する。このように、クライアント用デバイス通信プログラム２３０は、アプリケーション１２０からローカルデバイス３への入出力要求情報、およびローカルデバイス３からアプリケーション１２０への入出力応答情報を中継する。

サーバ１からクライアント２への、アプリケーション１２０とデバイスドライバ２４０との間の通信は、リダイレクトされる。その結果、サーバ用デバイス通信プログラム１３０は、デバイスドライバ２４０の代理として、サーバ１内で動作する。一旦サーバ用デバイス通信プログラム１３０とアプリケーション１２０との間の関係が確立されると、サーバ用デバイス通信プログラム１３０とアプリケーション１２０との間の通信が、クライアント用デバイス通信プログラム２３０を介してデバイスドライバ２４０に転送される。ローカルデバイス３は、デバイスドライバ２４０に転送された通信に基づき、アプリケーション１２０の制御通りに動作することができる。

（デバイスドライバ２４０）
デバイスドライバ２４０は、ローカルデバイス３を制御し、アプリケーションソフトウェアに対して抽象化したインターフェースを提供する。デバイスドライバ２４０は、クライアント用デバイス通信プログラム２３０およびカーネルドライバ２５１と通信する。

（カーネルドライバ２５１）
カーネルドライバ２５１は、プロセッサ２０１、メモリ２０２、入出力用ハードウェア等のハードウェアを抽象化し、ハードウェアとソフトウェアがやりとりできるようにするために、プロセスの抽象化、プロセス間通信、システムコール等を提供する。カーネルドライバ２５１は、デバイスドライバ２４０およびバスドライバ２５２と通信する。

（バスドライバ２５２）
バスドライバ２５２は、バスコントローラ、バスアダプタ、バスブリッジ等を制御する。バスドライバ２５２は、カーネルドライバ２５１およびホストコントローラドライバ２５３と通信する。

（ホストコントローラドライバ２５３）
ホストコントローラドライバ２５３は、ホストコントローラ２５４のドライバ層であり、上位のバスドライバ２５２からハードウェアを抽象化する。例えば、ホストコントローラドライバ２５３は、ホストコントローラ２５４に対するＩ／Ｏ処理、割り込み処理、スケジューリング処理等を行う。ホストコントローラドライバ２５３は、バスドライバ２５２およびホストコントローラ２５４と通信する。

（ホストコントローラ２５４）
ホストコントローラ２５４は、クライアント２とローカルデバイス３とを接続するハードウェアである。ローカルデバイス３は、ホストコントローラ２５４のポートを通して、クライアント２に接続する。例えば、ホストコントローラ２５４は、ＵＳＢポート、ファイアワイア（ＩＥＥＥ１３９４）ポート、ＲＳ−２３３ｃなどのデバイスポートを含む。クライアント２は、ＰＮＰ（Ｐｌｕｇ ａｎｄ Ｐｌａｙ）をサポートしていてもよいが、デバイスポートはＰＮＰに限定されない。

新たなローカルデバイス３がホストコントローラ２５４を介してクライアント２に接続またはプラグインされた場合、デバイスドライバ２４０などのデバイスドライバがインストールされる。クライアント用デバイス通信プログラム２３０は、インストールされたデバイスドライバ２４０を介して、ローカルデバイス３にアクセスし制御することができる。

以上、クライアント２の構成を説明した。続いて、ローカルデバイス３の構成を説明する。

［２−１−３．ローカルデバイス３の構成］
ローカルデバイス３は、クライアント２に接続される外部装置である。クライアント２に接続されたローカルデバイス３のアクセスおよび制御は、サーバ１に直接リダイレクトされない。ローカルデバイス３は、サーバ用デバイス通信プログラム１３０およびクライアント用デバイス通信プログラム２３０を介して、サーバ１により選択的にアクセスおよび制御される。ローカルデバイス３は、例えば、デジタルカメラ、デジタルビデオカメラ、ハードディスク記憶デバイス、デジタルメディアレコーダ、プリンタ、スキャナ、ＩＣカードリーダ、シリアルポート接続機器であってもよい。この中でも、特に制御機構を内蔵する機器は、仮想デバイスドライバを用いたアクセスが困難な場合が多い。

以上、ローカルデバイス３の構成を説明した。続いて、図３〜図５Ｂを参照して、本実施形態に係る通信システムの動作を説明する。

［２−１−４．動作処理］
（クライアント２の準備動作）
図３は、第１の実施形態に係るクライアント２の動作を示すフローチャートである。図３では、クライアント２が、サーバ１からローカルデバイス３へのアクセス中継を準備する動作処理を示した。図３で示した各ブロックは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせにより実行される。各ブロックは、１つまたは複数のプロセッサにより実行されるコンピュータ命令として捉えることも可能である。また、各ブロックは、図３で示した順序とは異なる順序により実行されてもよい。

図３に示すように、まず、ステップＳ１０２で、クライアント２は、ローカルデバイス３を検出する。詳しくは、クライアント２に常駐するクライアント用デバイス通信プログラム２３０が、クライアント２に新たに接続されたローカルデバイス３を検出する。他にも、クライアント用デバイス通信プログラム２３０が起動した際に、クライアント２に接続されているローカルデバイス３を検出してもよい。クライアント用デバイス通信プログラム２３０は、検出したローカルデバイス３をＩＯＣＴＬコード内の物理デバイスオブジェクトとして識別する。

次いで、ステップＳ１０４で、クライアント２は、デバイスドライバ（デバイスドライバ２４０、カーネルドライバ２５１、バスドライバ２５２）をロードする。詳しくは、クライアント２は、新たに検出されたローカルデバイス３をサポートするために必要なドライバまたはドライバスタックをロードまたはインストールする。上記ステップＳ１０２において、クライアント用デバイス通信プログラム２３０の起動によりローカルデバイス３が検出された場合には、ローカルデバイス３が接続された時点で既にインストール等が完了しているため、再度のインストール等は実施しない。インストール等は、ＰＮＰ処理として実施されてもよい。クライアント２は、インストールが完了したことをクライアント用デバイス通信プログラム２３０に通知する。

そして、ステップＳ１０６で、クライアント２は、デバイス中継事前準備を行う。詳しくは、クライアント２は、クライアント用デバイス通信プログラム２３０がアプリケーション１２０からローカルデバイス３へのアクセスを中継するように、クライアント用デバイス通信プログラム２３０を構成する。クライアント用デバイス通信プログラム２３０は、新たに検出されたローカルデバイス３への入出力要求情報をサーバ用デバイス通信プログラム１３０から受信するために常駐し、待機する。これにより、クライアント２によるデバイス中継の準備が完了する。

以上、クライアント２の準備動作について説明した。続いて、図４を参照して、サーバ１によるローカルデバイス３の制御動作について説明する。

（サーバ１によるローカルデバイス３の制御動作）
図４は、第１の実施形態に係るサーバ１の動作を示すフローチャートである。図４では、サーバ１がローカルデバイス３を制御する動作処理を示した。図４で示した各ブロックは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせにより実行される。各ブロックは、１つまたは複数のプロセッサにより実行されるコンピュータ命令として捉えることも可能である。また、各ブロックは、図４で示した順序とは異なる順序により実行されてもよい。

図４に示すように、まず、ステップＳ２０２で、サーバ１は、リモートサービス通信を開始する。詳しくは、リモート・サービス・クライアント・アプリケーション２１０は、リモート・サービス・サーバ・アプリケーション１１０に対してリモート接続要求を行い、通信リンクを確立する。この処理は、一般的なターミナルサービス接続の開始と同様の処理として実装されてもよい。

次いで、ステップＳ２０４で、サーバ１は、アプリケーション１２０を起動する。詳しくは、サーバ１は、上記ステップＳ２０２において確立されたリモート接続の通信リンクにおいてアプリケーション１２０を起動する。

次に、ステップＳ２０６で、サーバ１は、アプリケーション１２０からのデバイス通信を確立する。詳しくは、サーバ１上のアプリケーション１２０は、クライアント２上のローカルデバイス３に入出力要求を発行するために、デバイス制御用のリンクを確立する。具体的には、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０が提供するＡＰＩを介し、クライアント用デバイス通信プログラム２３０との通信を確立する。クライアント用デバイス通信プログラム２３０は、サーバ用デバイス通信プログラム１３０からの接続要求を、図３を参照して上記説明した準備処理により待ち受けているため、サーバ１とクライアント２との間でデバイス制御用の通信が確立される。これにより、サーバ１はクライアント２とのデバイス中継通信が開始される。なお、クライアント用デバイス通信プログラム２３０は、デバイス制御用の通信が確立した際に、ローカルデバイス３を識別するための識別情報をサーバ１に送信する。デバイス中継通信中に新たなローカルデバイス３が接続された場合、クライアント用デバイス通信プログラム２３０は、その都度新たなローカルデバイス３を識別するための識別情報をサーバ１に送信してもよい。

そして、ステップＳ２０８で、サーバ１は、アプリケーション１２０からローカルデバイス３への入出力を制御する。詳しくは、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０を介して、入出力要求情報をローカルデバイス３に発行する。サーバ用デバイス通信プログラム１３０は、アプリケーション１２０から出力された入出力要求情報を、上記ステップＳ２０６において確立されたデバイス制御用の通信によりクライアント用デバイス通信プログラム２３０に送信する。クライアント用デバイス通信プログラム２３０は、受信した入出力要求情報を入出力制御情報に変換してデバイスドライバ２４０に中継し、デバイスドライバ２４０は、入出力制御情報をローカルデバイス３に中継する。ローカルデバイス３から出力された入出力応答情報は、デバイスドライバ２４０、クライアント用デバイス通信プログラム２３０、およびサーバ用デバイス通信プログラム１３０を介して、アプリケーション１２０に中継される。これにより、アプリケーション１２０によるローカルデバイス３の制御が実現される。

以上、サーバ１によるローカルデバイス３の制御動作について説明した。続いて、図５Ａ、図５Ｂを参照して、通信システムによる、上記説明した準備動作から制御動作までの一連の処理を説明する。

（通信システムの制御動作）
図５Ａおよび図５Ｂは、第１の実施形態に係る通信システムの動作を示すシーケンス図である。図５Ａおよび図５Ｂでは、クライアント２にローカルデバイス３が接続されてから、サーバ１がローカルデバイス３を制御するまでの一連の動作処理を示した。図５Ａおよび図５Ｂで示した各ブロックは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせにより実行される。各ブロックは、１つまたは複数のプロセッサにより実行されるコンピュータ命令として捉えることも可能である。また、各ブロックは、図５Ａおよび図５Ｂで示した順序とは異なる順序により実行されてもよい。

図５Ａに示すように、まず、ステップＳ１０２で、クライアント用デバイス通信プログラム２３０は、ローカルデバイス３を検出する。次いで、ステップＳ１０４で、クライアント用デバイス通信プログラム２３０は、デバイスドライバ（デバイスドライバ２４０、カーネルドライバ２５１、バスドライバ２５２）をロードする。そして、ステップＳ１０６で、クライアント用デバイス通信プログラム２３０は、デバイス中継事前準備を行う。

次いで、ステップＳ２０２で、リモート・サービス・クライアント・アプリケーション２１０は、リモート・サービス・サーバ・アプリケーション１１０とのリモートサービス通信を開始する。次に、ステップＳ２０４で、リモート・サービス・サーバ・アプリケーション１１０は、アプリケーション１２０を起動する。

次いで、ステップＳ２０６−１で、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０に、デバイス通信を開始するよう通知する。ステップＳ２０６−２で、サーバ用デバイス通信プログラム１３０は、この通知を受けて、クライアント用デバイス通信プログラム２３０とのデバイス制御用のリンクを確立して、デバイス中継通信を開始する。このように、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０を介して、クライアント用デバイス通信プログラム２３０で準備されているローカルデバイス３へのアクセスを行う通信リンクを確立する。

次いで、ステップＳ２０８−１で、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０に、入出力要求情報を送信する。次に、ステップＳ２０８−２で、サーバ用デバイス通信プログラム１３０は、クライアント用デバイス通信プログラム２３０に、上記ステップＳ２０８−１で受信した入出力要求情報を中継する。次いで、図５Ｂに示すように、ステップＳ２０８−３で、クライアント用デバイス通信プログラム２３０は、受信した入出力要求情報を入出力制御情報に変換して、デバイスドライバ２４０に送信する。そして、ステップＳ２０８−４で、デバイスドライバ２４０は、受信した入出力制御情報に基づいて、ローカルデバイス３をＩＯＣＴＬにより制御する。

ローカルデバイス３は、上記ステップＳ２０８−４において受けたＩＯＣＴＬに基づき各種処理を行い、その応答（入出力応答情報）を、ステップＳ２０８−５でデバイスドライバ２４０に返信する。次いで、ステップＳ２０８−６で、デバイスドライバ２４０は、上記ステップＳ２０８−５で返信された入出力応答情報を、クライアント用デバイス通信プログラム２３０に送信する。次に、ステップＳ２０８−７で、クライアント用デバイス通信プログラム２３０は、サーバ用デバイス通信プログラム１３０に、上記ステップＳ２０８−６で受信した入出力応答情報を中継する。そして、ステップＳ２０８−８で、サーバ用デバイス通信プログラム１３０は、受信した入出力応答情報を、アプリケーション１２０に送信する。

以上、クライアント２にローカルデバイス３が接続されてから、サーバ１がローカルデバイス３を制御するまでの一連の動作について説明した。

本実施形態によれば、クライアント２に接続されているローカルデバイス３に、リモート接続先のサーバ１からアクセスすることが可能となる。特に、本実施形態では、仮想デバイスドライバがサーバ１に作成されないため、サーバ１への仮想デバイスドライバの作成又は運用に失敗してしまうローカルデバイス３であっても、サーバ１上のアプリケーション１２０からアクセス可能となる。

以上、第１の実施形態について説明した。続いて、第２の実施形態について説明する。

［２−２．第２の実施形態］
本実施形態は、サーバ１に複数のクライアント２が同時にアクセスした場合に、サーバ１が、接続元の各クライアント２を識別して、識別したクライアント２に接続されたローカルデバイス３を制御する形態である。図６を参照して、本実施形態に係る通信システムについて説明する。

図６は、第２の実施形態に係る通信システムの概要を説明するための図である。図６に示すように、サーバ１に、クライアント２Ａ、２Ｂ、２Ｃといった複数のクライアント２が接続されている。また、クライアント２Ａにはローカルデバイス３Ａが接続され、クライアント２Ｂにはローカルデバイス３Ｂが接続され、クライアント２Ｃにはローカルデバイス３Ｃが接続されている。

図６に示すように、リモート・サービス・クライアント・アプリケーション２１０Ａは、リモート・サービス・サーバ・アプリケーション１１０とリモート接続の通信リンクを確立している。リモート・サービス・サーバ・アプリケーション１１０は、リモート・サービス・クライアント・アプリケーション２１０Ａとのリモート接続の通信リンクが確立されてから切断されるまでの一連の通信を、セッション１４０Ａとして管理・識別する。また、リモート・サービス・サーバ・アプリケーション１１０は、クライアント用デバイス通信プログラム２３０Ａとアプリケーション１２０Ａとのサーバ用デバイス通信プログラム１３０Ａを介した通信も、セッション１４０Ａとして管理・識別する。

詳しくは、サーバ用デバイス通信プログラム１３０Ａは、リモート接続の接続元であるクライアント２Ａを、セッション１４０Ａを管理するリモート・サービス・サーバ・アプリケーション１１０との通信により識別する。そして、サーバ用デバイス通信プログラム１３０Ａは、識別したクライアント２Ａにアプリケーション１２０Ａから中継した入出力要求情報を送信する。また、サーバ用デバイス通信プログラム１３０Ａは、クライアント用デバイス通信プログラム２３０Ａから受信した入出力応答情報を、アプリケーション１２０Ａに送信する。

このように、リモート・サービス・サーバ・アプリケーション１１０は、クライアント２Ａとの通信を、セッション１４０Ａとして管理・識別することで、クライアント２Ａとの通信と他のクライアント２との通信とを区別する。クライアント２Ｂ、２Ｃについても同様である。

本実施形態によれば、サーバ１に複数のクライアント２が同時にアクセスした場合であっても、サーバ１は、接続元の各クライアント２を識別して、識別したクライアント２に接続されたローカルデバイス３を制御することができる。

以上、第２の実施形態について説明した。

［２−３．第３の実施形態］
本実施形態は、サーバ１とクライアント２との間にファイアウォール又はＮＡＴ（Network Address Translation）等の中継装置が介在する場合に、サーバ１が、中継装置の利点を生かしながらローカルデバイス３を制御する形態である。図７、図８を参照して、本実施形態に係る通信システムの構成を説明する。図７は、第３の実施形態に係る通信システムの構成を示すブロック図である。図８は、第３の実施形態に係る通信システムの概要を説明するための図である。

［２−３−１．中継装置５の構成］
図７に示すように、中継装置５は、ファイアウォールプログラム５１０、およびＮＡＴプログラム５２０を有する。また、図８に示すように、サーバ１は、複数のクライアント２から中継装置５を経由したアクセスを受けることができる。

（ファイアウォールプログラム５１０）
ファイアウォールプログラム５１０は、サーバ１とクライアント２との通信の安全性を維持するためのプログラムである。例えば、ファイアウォールプログラム５１０は、送信先のＩＰアドレス、送信元のＩＰアドレス、ポート番号などを監視する。そして、ファイアウォールプログラム５１０は、例えば通過すべき送信先および送信元のＩＰアドレスおよびポート番号の組み合わせの設定に基づいて、パケットを通過させたり遮断したりする。

（ＮＡＴプログラム５２０）
ＮＡＴプログラム５２０は、パケットヘッダに含まれるＩＰアドレスを、別のＩＰアドレスに変換するプログラムである。ＮＡＴプログラム５２０は、ＮＡＴ（Network Address Translation）を行ってもよいし、ＮＡＰＴ（Network Address Port Translation）を行ってもよい。

［２−３−２．サーバ１の構成］
図７に示すように、本実施形態に係るサーバ１は、図２を参照して上記説明した第１の実施例に係るサーバ１の要素に加えて、デバイス通信管理プログラム１３２、および接続情報ＤＢ（Data Base）１３４を有する。

（接続情報ＤＢ１３４）
接続情報ＤＢ１３４は、デバイス通信管理プログラム１３２がローカルデバイス３との通信を行うための接続情報を記憶する記憶部としての機能を有する。接続情報の一例を、下記の表１に示す。表１に示すように、接続情報は、クライアント２の識別情報である「クライアント名」、ローカルデバイス３を識別情報である「デバイス種別」および「デバイスＩＤ」、および通信チャネル情報である「通信チャネルＩＤ」を含む。「デバイス種別」は、ローカルデバイス３の種別を示す情報であり、アプリケーション１２０がローカルデバイス３を制御して実行可能なＡＰＩを特定するための情報である。「デバイスＩＤ」は、「デバイス種別」が同一のローカルデバイス３を相互に識別するための識別情報である。なお、実行可能なＡＰＩが特定可能であり、且つ、アプリケーション１２０が制御するローカルデバイス３が特定可能であれば、ローカルデバイス３を識別するための情報は、「デバイス種別」および「デバイスＩＤ」に分かれていなくても良い。「通信チャネルＩＤ」は、ローカルデバイス３と通信するための通信チャネル（ソケット）を識別するためのファイルディスクリプタ（識別子）である。なお、接続情報ＤＢ１３４は、データベースとしてではなく、メモリ上に記憶されてもよい。

（デバイス通信管理プログラム１３２）
デバイス通信管理プログラム１３２は、クライアント用デバイス通信プログラム２３０との間で通信を確立して、クライアント用デバイス通信プログラム２３０とサーバ用デバイス通信プログラム１３０との間の通信を中継する機能を有する通信管理プログラムである。デバイス通信管理プログラム１３２は、リモートサービス通信が開始された後、クライアント用デバイス通信プログラム２３０からの接続要求を待って、サーバ用デバイス通信プログラム１３０とクライアント用デバイス通信プログラム２３０との通信を中継し、中継装置５を経由したデバイス中継通信を実現する。

詳しくは、まず、デバイス通信管理プログラム１３２は、クライアント用デバイス通信プログラム２３０からの接続要求に応じてクライアント用デバイス通信プログラム２３０との通信を確立する。ここで、例えばサーバ１からクライアント２に接続要求を送信する場合、ファイアウォールプログラム５１０において、全てのクライアント２への接続を許可するポートを設けることが要され、セキュリティの低下が懸念される。そこで、本実施形態に係るデバイス通信管理プログラム１３２は、クライアント用デバイス通信プログラム２３０からの接続要求に応じて、デバイス制御用の通信を確立する。このため、ファイアウォールプログラム５１０では、サーバ１への接続要求を許可するポートをひとつ設ければよく、セキュリティの低下を抑止することが可能である。

ここで、デバイス通信管理プログラム１３２は、クライアント用デバイス通信プログラム２３０との通信を確立すると、クライアント用デバイス通信プログラム２３０からローカルデバイス３にアクセスするための接続情報を受信する。そして、接続情報ＤＢ１３４は、デバイス通信管理プログラム１３２による通信の中継が行われている間、この接続情報を記憶する。通信が切断された場合、接続情報ＤＢ１３４は、切断された通信に関する接続情報を削除してもよい。他にも、接続／切断状態を示す接続フラグにより、接続情報に対応付けて接続／切断状態が一定期間キャッシュに記憶されてもよい。また、接続情報ＤＢ１３４は、全てのクライアント２の接続情報を接続フラグに対応付けて記憶しておき、デバイス通信管理プログラム１３２は、フラグを参照して通信が確立しているか否かを判定してもよい。

そして、デバイス通信管理プログラム１３２は、接続情報ＤＢ１３４に記憶された接続情報を用いて、サーバ用デバイス通信プログラム１３０とクライアント用デバイス通信プログラム２３０との通信を中継する。詳しくは、まず、デバイス通信管理プログラム１３２は、アプリケーション１２０がローカルデバイス３を制御する際に、制御する対象のローカルデバイス３に対応する接続情報を接続情報ＤＢ１３４から検索する。ここで、ＩＰアドレスによってクライアントを識別する上記特許文献３を参考に、クライアント２のＩＰアドレスおよびポート番号を検索キーとして、制御対象のローカルデバイス３が接続されたクライアント２の接続情報を検索することが考えられる。しかし、ＮＡＴプログラム５２０によりＩＰアドレスが１対多で変換された場合、ＩＰアドレスおよびポート番号ではクライアント２を特定することが困難となる。そこで、デバイス通信管理プログラム１３２は、接続先のクライアント２のクライアント名を検索キーとして接続情報ＤＢ１３４から接続情報を検索する。検索キーが接続先のクライアント２のクライアント名であるため、ＮＡＴプログラム５２０によりＩＰアドレスが１対多で変換される場合であっても、制御対象のローカルデバイス３が接続されたクライアント２の接続情報を特定することが可能となる。検索後、デバイス通信管理プログラム１３２は、検索した接続情報（接続状態のもの）に含まれる通信チャネルＩＤが示す通信チャネルを使用して、クライアント用デバイス通信プログラム２３０との通信を行う。

以上、本実施形態に係る通信システムの構成を説明した。続いて、図９〜図１１を参照して、本実施形態に係る通信システムによる動作処理の流れを説明する。

［２−３−３．動作処理］
図９〜図１１は、第３の実施形態に係る通信システムの動作を示すシーケンス図である。図９に示すように、まず、ステップＳ１０２で、クライアント用デバイス通信プログラム２３０は、デバイス中継事前準備を行う。ここでの処理は、図５Ａを参照して上記説明したステップＳ１０２〜Ｓ１０６における処理と同様である。なお、クライアント用デバイス通信プログラム２３０は、常駐型のサービスプロセスである。

次いで、ステップＳ３０４−１、Ｓ３０４−２で、クライアント用デバイス通信プログラム２３０は、リモートサービス通信が行われているか否かをポーリングする。このポーリングは、リモートサービス通信が開始されたことが検出されるまで繰り返される。なお、符号Ｓ３０４の末尾の数字は、ポーリングの回数を指すものとする。

次に、ステップＳ３０６で、リモート・サービス・クライアント・アプリケーション２１０は、リモートサービス通信を開始する。例えば、ユーザによる指示、又は自動的な起動設定等により、リモートサービス通信は開始され得る。なお、中継装置５は、クライアント２からサーバ１へのリモートサービス通信用のポートを開放しており、このリモートサービス通信は中継装置５を通過する。

次いで、ステップＳ３０８で、リモート・サービス・サーバ・アプリケーション１１０は、アプリケーション１２０を起動する。詳しくは、リモート・サービス・サーバ・アプリケーション１１０は、上記ステップＳ３０６において確立されたリモート接続の通信リンクにおいて、ログイン処理が実行された後にアプリケーション１２０を起動する。

次に、ステップＳ３１０で、アプリケーション１２０は、デバイス通信をオープンする。詳しくは、アプリケーション１２０は、サーバ用デバイス通信プログラム１３０に、デバイス制御用のリンクを確立するためのオープン命令を呼び出す。

次いで、ステップＳ３１２−１で、サーバ用デバイス通信プログラム１３０は、デバイス中継通信をオープンする。詳しくは、まず、サーバ用デバイス通信プログラム１３０は、環境変数又はレジストリを参照してリモート接続を行っているクライアント２の情報を取得する。そして、サーバ用デバイス通信プログラム１３０は、取得した接続先のクライアント情報に基づいて、デバイス通信管理プログラム１３２に対してデバイス中継通信のオープンをリクエストする。

次に、ステップＳ３１４−１で、デバイス通信管理プログラム１３２は、接続情報ＤＢ１３４から使用可能な通信チャネルを検索する。詳しくは、デバイス通信管理プログラム１３２は、接続情報ＤＢ１３４から、接続先のクライアント２とのデバイス制御用の通信チャネルを検索する。クライアント２とのデバイス制御用の通信が確立している場合、後述のステップＳ３２２における処理において、指定されたクライアント２および制御対象のローカルデバイス３に関する上記表１に示した接続情報が接続情報ＤＢ１３４に登録される。このため、クライアント２とのデバイス制御用の通信が確立している場合には、デバイス通信管理プログラム１３２による通信チャネルの検索が成功する。

通信チャネルの検索に失敗した場合、ステップＳ３１６−１で、デバイス通信管理プログラム１３２は、オープンに失敗した旨を示すオープンＮＧ回答をサーバ用デバイス通信プログラム１３０に応答する。サーバ１は、上記ステップＳ３１２−１〜Ｓ３１６−１の処理を、タイムアウトするまで定期的にポーリングする。ポーリングを行うのは、サーバ用デバイス通信プログラム１３０でもよいし、デバイス通信管理プログラム１３２でもよい。なお、符号Ｓ３１２−１、３１４−１、３１６−１の末尾の数字は、ポーリングの回数を指すものとする。

図１０に示すように、ステップＳ３０４−Ｎのポーリングにおいて、リモートサービス通信中であることが確認された場合、ステップＳ３１８で、クライアント用デバイス通信プログラム２３０は、デバイス中継通信をオープンする。詳しくは、クライアント用デバイス通信プログラム２３０は、リモートサービス通信の接続先のサーバ１に対して、デバイス中継通信のオープンをリクエストする。これにより、クライアント２からサーバ１への通信チャネルが形成され、デバイス制御用の通信が確立される。なお、中継装置５は、クライアント２からサーバ１へのデバイス制御用の通信のためのポートを開放しており、この通信チャネルは中継装置５を通過する。なお、中継装置５が存在しない場合には、上記第１、第２の実施形態と同様に、サーバ１がクライアント２へのデバイス制御用の通信を確立してもよい。

次いで、ステップＳ３２０で、クライアント用デバイス通信プログラム２３０は、デバイス通信管理プログラム１３２に初期データ送信する。例えば、クライアント用デバイス通信プログラム２３０は、接続しているローカルデバイス３ごとにデバイス種別、デバイスＩＤをペアとしたリストを、ステップＳ３１８において確立されたデバイス制御用の通信チャネルを用いて送信する。

次に、ステップＳ３２２で、デバイス通信管理プログラム１３２は、受信した初期データを、接続情報として接続情報ＤＢ１３４に登録する。このとき、デバイス通信管理プログラム１３２は、ＩＰアドレスではなくクライアント名を受信した初期データに対応付けて登録する。これにより、１対１のＩＰアドレス変換に加え、１対多のＩＰアドレス変換にも対応した、通信チャネルとクライアント２との紐付けが可能となる。なお、接続情報ＤＢ１３４に以前のデータが記憶されている場合、デバイス通信管理プログラム１３２は、新たに受信した初期データにより接続情報を更新してもよい。

Ｓ３１４−Ｎにおけるデバイス中継通信のオープンに係るポーリングにおいて、通信チャネルの検索に成功すると、デバイス通信管理プログラム１３２は、オープンに成功した旨を示すオープンＯＫ回答をサーバ用デバイス通信プログラム１３０に応答する。

そして、ステップＳ３２４で、サーバ用デバイス通信プログラム１３０は、オープンＯＫ回答の受信に応じて、デバイス通信のオープンが完了した旨を、アプリケーション１２０に通知する。

以上説明した処理により、デバイス中継通信が開始され、アプリケーション１２０は、クライアント２に接続されているローカルデバイス３を制御することが可能となる。以下、図１１を参照して、上記説明した処理により形成された通信チャネルを用いたデバイス制御処理の流れを説明する。

図１１に示すように、まず、ステップＳ４０２で、アプリケーション１２０は、入出力要求情報を、サーバ用デバイス通信プログラム１３０に送信する。

次いで、ステップＳ４０４で、サーバ用デバイス通信プログラム１３０は、受信した入出力要求情報を、デバイス通信管理プログラム１３２に中継する。

次に、ステップＳ４０６で、デバイス通信管理プログラム１３２は、入出力要求情報を送信するために用いるべき通信チャネルを検索する。詳しくは、デバイス通信管理プログラム１３２は、リモート接続先のクライアント２のクライアント名を検索キーとして、接続情報ＤＢ１３４から通信チャネルＩＤを検索する。

そして、ステップＳ４０８で、デバイス通信管理プログラム１３２は、入出力要求情報を、リモート接続先のクライアント２に中継する。詳しくは、デバイス通信管理プログラム１３２は、上記ステップＳ４０６で検索した通信チャネルＩＤに対応する通信チャネルを用いて、入出力要求情報を送信する。

次いで、ステップＳ４１０で、クライアント用デバイス通信プログラム２３０は、デバイスドライバ２４０を介して、ローカルデバイス３をＩＯＣＴＬにより制御する。

次に、ステップＳ４１２で、ローカルデバイス３は、上記ステップＳ４１０において受けたＩＯＣＴＬに基づき各種処理を行い、その応答（入出力応答情報）をクライアント用デバイス通信プログラム２３０に返信する。

次いで、ステップＳ４１４で、クライアント用デバイス通信プログラム２３０は、返信された入出力応答情報を、サーバ１に送信する。

次に、ステップＳ４１６で、デバイス通信管理プログラム１３２は、受信した入出力応答情報を、サーバ用デバイス通信プログラム１３０に中継する。

そして、ステップＳ４１８で、サーバ用デバイス通信プログラム１３０は、受信した入出力応答情報を、アプリケーション１２０に中継する。

以上、本実施形態に係る通信システムによる動作処理の流れを説明した。本実施形態に係るサーバ１は、クライアント２からの接続要求に応じてデバイス制御用の通信を確立するため、ファイアウォールプログラム５１０では、サーバ１への接続要求を許可するポートをひとつ設ければよく、セキュリティの低下を抑止される。また、サーバ１は、デバイス制御用の通信をクライアント名で管理するため、ＮＡＴプログラム５２０によりＩＰアドレスが１対多で変換される場合であっても、制御対象のローカルデバイス３に対応する通信チャネルを特定することができる。

＜３．まとめ＞
以上説明したように、本発明の一実施形態に係る通信システムは、仮想デバイスドライバを用いることなくリモートアクセス環境を実現することが可能である。具体的には、本実施形態に係るサーバ１は、サーバ用デバイス通信プログラム１３０とクライアント用デバイス通信プログラム２３０との通信を介して、クライアント２に接続されたローカルデバイス３を制御する。これにより、サーバ１で仮想デバイスドライバが動作することがなく、クライアント２内でのみデバイスドライバが動作するため、ネットワーク４の遅延等によるＩＯＣＴＬのタイムアウトエラー等の発生を回避することができる。また、デバイスドライバは、クライアント２でのみ用いられ、サーバ１で用いられることがないため、サーバ１のＯＳがデバイスメーカーのサポート外であっても、リモートアクセス環境を実現することができる。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、本開示の第１の実施形態および第２の実施形態は適宜組み合わせることが可能である。

また、情報処理装置に内蔵されるＣＰＵ、ＲＯＭ及びＲＡＭ等のハードウェアに、上記サーバ１またはクライアント２の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記録した記録媒体も提供される。

１ サーバ
１０１ プロセッサ
１０２ メモリ
１１０ リモート・サービス・サーバ・アプリケーション
１２０ アプリケーション
１３０ サーバ用デバイス通信プログラム
１３２ デバイス通信管理プログラム
１３４ 接続情報ＤＢ
１４０ セッション
２ クライアント
２０１ プロセッサ
２０２ メモリ
２１０ リモート・サービス・クライアント・アプリケーション
２３０ クライアント用デバイス通信プログラム
２４０ デバイスドライバ
２５１ カーネルドライバ
２５２ バスドライバ
２５３ ホストコントローラドライバ
２５４ ホストコントローラ
３ ローカルデバイス
４ ネットワーク
５ 中継装置
５１０ ファイアウォールプログラム
５２０ ＮＡＴプログラム

Claims (10)

1. クライアント装置と前記クライアント装置の仮想化されたデスクトップ環境として機能するサーバ装置とを含む通信システムであって、
   前記サーバ装置は、
   アプリケーションから前記クライアント装置に接続された外部装置への命令情報を前記クライアント装置に送信する第１の通信プログラムを有し、
   前記クライアント装置は、
   デバイスドライバと、
   前記サーバ装置から前記命令情報を受信し、受信された前記命令情報を入出力制御情報に変換して前記外部装置に対応する前記デバイスドライバに中継する第２の通信プログラムと、
   を有する、通信システム。
2. 前記第２の通信プログラムは、前記クライアント装置に接続された前記外部装置を識別し、識別した前記外部装置を示す識別情報を前記サーバ装置に送信する、請求項１に記載の通信システム。
3. 前記命令情報は、前記識別情報を含み、
   前記第２の通信プログラムは、前記識別情報が示す前記外部装置に対応する前記デバイスドライバに前記入出力制御情報を中継する、請求項２に記載の通信システム。
4. 前記第１の通信プログラムは、前記仮想化されたデスクトップ環境の接続元である前記クライアント装置を識別し、識別した前記クライアント装置に前記命令情報を送信する、請求項１〜３のいずれか一項に記載の通信システム。
5. 前記第２の通信プログラムは、前記入出力制御情報に基づき前記外部装置から出力された出力情報を前記サーバ装置に送信し、
   前記第１の通信プログラムは、前記クライアント装置から受信された前記出力情報を前記アプリケーションに中継する、請求項１〜４のいずれか一項に記載の通信システム。
6. 前記入出力制御情報は、ＩＯＣＴＬ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）である、請求項１〜５のいずれか一項に記載の通信システム。
7. 前記サーバ装置は、
   前記第２の通信プログラムとの間で通信を確立して前記前記第２の通信プログラムと前記第１の通信プログラムとの間の通信を中継する通信管理プログラムと、
   前記外部装置との通信を行うための接続情報を記憶する記憶部と、
   をさらに備え、
   前記通信管理プログラムは、前記第２の通信プログラムからの接続要求に応じて前記第２の通信プログラムとの通信を確立し、前記記憶部に記憶された前記接続情報を用いて前記第１の通信プログラムと前記第２の通信プログラムとの通信を中継する、請求項１〜６のいずれか一項に記載の通信システム。
8. 前記接続情報は、前記クライアント装置の識別情報、前記外部装置の識別情報、および通信チャネル情報を含む、請求項７に記載の通信システム。
9. 前記通信管理プログラムは、前記クライアント装置の識別情報を検索キーとして前記記憶部から前記接続情報を検索する、請求項８に記載の通信システム。
10. クライアント装置と前記クライアント装置の仮想化されたデスクトップ環境として機能するサーバ装置のアプリケーションとの通信を制御する通信プログラムであって、
    第１の前記通信プログラムは、前記サーバ装置に含まれ、前記アプリケーションから前記クライアント装置に接続された外部装置への命令情報を前記クライアント装置に送信し、
    第２の前記通信プログラムは、前記クライアント装置に含まれ、前記サーバ装置から前記命令情報を受信し、受信された前記命令情報を入出力制御情報に変換して前記外部装置に対応するデバイスドライバに中継する、通信プログラム。
    

Images