図面 (/)

技術 通信システム及び通信プログラム

出願人 沖電気工業株式会社
発明者 新村昭好鈴木寿紀
出願日 2014年3月28日 (6年7ヶ月経過) 出願番号 2014-067744
公開日 2015年6月25日 (5年4ヶ月経過) 公開番号 2015-118684
状態 特許登録済
技術分野 入出力制御
主要キーワード 画面出力情報 入出力応答 TLコード リモートデスクトップ接続 デバイスポート ポート番 カーネルドライバ ドライバスタック
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年6月25日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (13)

課題

仮想デバイスドライバを用いることなくリモートアクセス環境を実現することが可能な、通信ステム及び通信プログラムを提供する。

解決手段

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

概要

背景

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

このような技術のひとつとして、リモートデスクトップ接続が挙げられる。例えば、サーバとクライアントとがリモートデスクトップ接続により接続されると、クライアントは、サーバを直接操作しているかのようなデスクトップ画面を表示して、サーバ上のプログラムファイルアクセス可能となる。ここで、クライアントにUSB(Universal Serial Bus)メモリなどのローカルデバイスが接続される場合がある。このような場合に、あたかもサーバにそのローカルデバイスが接続されたかのような制御を行うための技術が開発されている。

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

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

概要

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

目的

本発明は、上記問題に鑑みてなされたものであり、本発明の目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記第2の通信プログラムは、前記クライアント装置に接続された前記外部装置を識別し、識別した前記外部装置を示す識別情報を前記サーバ装置に送信する、請求項1に記載の通信システム。

請求項3

前記命令情報は、前記識別情報を含み、前記第2の通信プログラムは、前記識別情報が示す前記外部装置に対応する前記デバイスドライバに前記入出力制御情報を中継する、請求項2に記載の通信システム。

請求項4

前記第1の通信プログラムは、前記仮想化されたデスクトップ環境の接続元である前記クライアント装置を識別し、識別した前記クライアント装置に前記命令情報を送信する、請求項1〜3のいずれか一項に記載の通信システム。

請求項5

前記第2の通信プログラムは、前記入出力制御情報に基づき前記外部装置から出力された出力情報を前記サーバ装置に送信し、前記第1の通信プログラムは、前記クライアント装置から受信された前記出力情報を前記アプリケーションに中継する、請求項1〜4のいずれか一項に記載の通信システム。

請求項6

前記入出力制御情報は、IOCTL(I/OControl)である、請求項1〜5のいずれか一項に記載の通信システム。

請求項7

前記サーバ装置は、前記第2の通信プログラムとの間で通信を確立して前記前記第2の通信プログラムと前記第1の通信プログラムとの間の通信を中継する通信管理プログラムと、前記外部装置との通信を行うための接続情報を記憶する記憶部と、をさらに備え、前記通信管理プログラムは、前記第2の通信プログラムからの接続要求に応じて前記第2の通信プログラムとの通信を確立し、前記記憶部に記憶された前記接続情報を用いて前記第1の通信プログラムと前記第2の通信プログラムとの通信を中継する、請求項1〜6のいずれか一項に記載の通信システム。

請求項8

前記接続情報は、前記クライアント装置の識別情報、前記外部装置の識別情報、および通信チャネル情報を含む、請求項7に記載の通信システム。

請求項9

前記通信管理プログラムは、前記クライアント装置の識別情報を検索キーとして前記記憶部から前記接続情報を検索する、請求項8に記載の通信システム。

請求項10

クライアント装置と前記クライアント装置の仮想化されたデスクトップ環境として機能するサーバ装置のアプリケーションとの通信を制御する通信プログラムであって、第1の前記通信プログラムは、前記サーバ装置に含まれ、前記アプリケーションから前記クライアント装置に接続された外部装置への命令情報を前記クライアント装置に送信し、第2の前記通信プログラムは、前記クライアント装置に含まれ、前記サーバ装置から前記命令情報を受信し、受信された前記命令情報を入出力制御情報に変換して前記外部装置に対応するデバイスドライバに中継する、通信プログラム。

技術分野

0001

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

背景技術

0002

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

0003

このような技術のひとつとして、リモートデスクトップ接続が挙げられる。例えば、サーバとクライアントとがリモートデスクトップ接続により接続されると、クライアントは、サーバを直接操作しているかのようなデスクトップ画面を表示して、サーバ上のプログラムファイルアクセス可能となる。ここで、クライアントにUSB(Universal Serial Bus)メモリなどのローカルデバイスが接続される場合がある。このような場合に、あたかもサーバにそのローカルデバイスが接続されたかのような制御を行うための技術が開発されている。

0004

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

0005

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

先行技術

0006

特表2009−508212号公報
特開2007−316786号公報
特開2003−296270号公報

発明が解決しようとする課題

0007

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

0008

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

課題を解決するための手段

0009

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

0010

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

0011

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

0012

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

0013

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

0014

前記入出力制御情報は、IOCTL(I/O Control)であってもよい。

0015

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

0016

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

0017

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

0018

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

発明の効果

0019

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

図面の簡単な説明

0020

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

実施例

0021

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

0022

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

0023

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

0024

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

0025

ネットワーク4は、ネットワーク4に接続されている装置から送信される情報の有線、または無線伝送路である。例えば、ネットワーク4は、インターネット専用線、IP−VPN(Internet Protocol−Virtual Private Network)等により構成される。他にも、ネットワーク4は、モデムを介した直接ダイアルアップ、企業LAN(Local Area Network)やWAN(Wide Area Network)により構成されてもよい。サーバ1は、ひとつ又は複数のクライアント2とネットワーク4を介して接続され、例えばTCP/IP等の伝送制御プロトコルにより相互に通信する。

0026

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

0027

まず、第1に、デバイスドライバが遠隔地で動作されることを想定された設計になっていないという問題がある。例えば、遠隔地にあるサーバ1の仮想デバイスドライバが、IOCTL(I/O Control)等の制御コードを送信する場合を考える。このような場合、IOCTLを発行する仮想デバイスドライバは短時間で応答が帰ってくることを期待しているため、ネットワーク4の遅延等によりIOCTLのタイムアウトエラー等が発生してしまう場合があった。また、接続されるローカルデバイスによっては、クライアント2からサーバ1へのリダイレクトが正常に動作せず、仮想デバイスドライバがサーバ1上に作成できない場合があった。

0028

第2に、サーバ1とクライアント2とが異なるOS(Operating System)により動作する場合に対応していないという問題がある。詳しくは、ローカルデバイス3がクライアント2に接続されることを想定してデバイスメーカーが作成したデバイスドライバが、仮想デバイスドライバとして動作するため、サーバ1のOSをデバイスメーカーがサポートしていない場合は遠隔操作を実現できない。例えば、ローカルデバイス3が、WindowsXP(登録商標)(32bit)やWindows(登録商標)7(32bit)等のOSで動作するPC(Personal Computer)に接続されることが想定されている場合を考える。このような場合、サーバ1のOSがWindowsServer(登録商標)2008(64bit)等のサーバ用OSやLinux(登録商標)等のWindows(登録商標)OS以外のOSである場合、サーバ1上のアプリケーションはローカルデバイス3を遠隔制御できなかった。

0029

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

0030

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

0031

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

0032

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

0033

<2.実施形態>
[2−1.第1の実施形態]
まず、図2を参照して、第1の実施形態に係る通信システムの構成を説明する。図2は、第1の実施形態に係る通信システムの構成を示すブロック図である。

0034

[2−1−1.サーバ1の構成]
図2に示すように、サーバ1は、プロセッサ101、メモリ102、リモートサービス・サーバ・アプリケーション110、アプリケーション120、およびサーバ用デバイス通信プログラム130を有する。サーバ1は、WindowsServer(登録商標)2008や、Linux(登録商標)等のOSにより動作する。

0035

(プロセッサ101)
プロセッサ101は、演算処理装置および制御装置として機能し、各種プログラムに従ってサーバ1内の動作全般を制御する。プロセッサ101は、例えばCPU(Central Processing Unit)、マイクロプロセッサによって実現される。なお、プロセッサ101は、使用するプログラムや演算パラメータ等を記憶するROM(Read Only Memory)、および適宜変化するパラメータ等を一時記憶するRAM(Random Access Memory)を含んでいてもよい。

0036

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

0037

(リモート・サービス・サーバ・アプリケーション110)
リモート・サービス・サーバ・アプリケーション110は、リモート・サービス・クライアント・アプリケーション210との通信により、サーバ1をクライアント2の仮想化されたデスクトップ環境として機能させるプログラムである。詳しくは、リモート・サービス・サーバ・アプリケーション110は、RDP(Remote Data Protocol)などの通信プロトコルにより、リモート・サービス・クライアント・アプリケーション210と通信する。このようなRDPによる通信は、ターミナルサービスシステム等のリモート・クライアント・アクセスシステムとして実装されてもよい。

0038

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

0039

(アプリケーション120)
アプリケーション120は、マルチメディア処理データベースアクセス等を行う各種アプリケーションである。アプリケーション120は、クライアント2による遠隔操作により動作する。この際、アプリケーション120は、リモート・サービス・サーバ・アプリケーション110を介して画面出力情報をクライアント2に送信する。他方、アプリケーション120は、サーバ用デバイス通信プログラム130を介してローカルデバイス3を制御するための情報をクライアント2に送信することで、ローカルデバイス3を制御する。ここで、アプリケーション120は、クライアント2に接続されたローカルデバイス3を、IOCTLコード内の物理デバイスオブジェクト(PDO:Physical Device Object)としては識別しない。アプリケーション120は、後述するサーバ用デバイス通信プログラム130により提供されるAPI(Application Programming Interface)を介して、ローカルデバイス3の制御を行う。そして、アプリケーション120は、サーバ用デバイス通信プログラム130を介して受信した、ローカルデバイス3からの応答に基づいて動作する。

0040

上述したように、仮想環境におけるローカルデバイス3への入出力制御は、リモート・サービス・サーバ・アプリケーション110によるRDPを介した通信ではなく、後述のサーバ用デバイス通信プログラム130により行われる。具体的には、アプリケーション120は、ローカルデバイス3の制御のために、上記特許文献1で開示された技術で用いられているような、RDPを介して通信する入出力要求パケット(IRP:I/O Request Packet)を使用しない。アプリケーション120は、独自プロトコルにより記述された入出力要求情報(命令情報)を使用して、ローカルデバイス3を制御する。

0041

入出力要求情報は、クライアント2に接続された1つ以上のローカルデバイス3から特定のローカルデバイス3を識別するための識別情報、およびローカルデバイス3への出力命令入力命令等の制御情報の組み合わせを、1つ以上含む情報である。入出力要求情報を記述するための独自プロトコルとしては、例えばXML(EXtensible Markup Language)やJSON(JavaScript(登録商標) Object Notation)等を用いてもよい。なお、入出力要求情報は、サーバ用デバイス通信プログラム130により中継され、クライアント用デバイス通信プログラム230によりIOCTL等の制御コードに変換される。入出力要求情報は、1つまたは複数のローカルデバイス3への要求を含んでいてもよい。

0042

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

0043

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

0044

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

0045

[2−1−2.クライアント2の構成]
図2に示すように、クライアント2は、プロセッサ201、メモリ202、リモート・サービス・クライアント・アプリケーション210、クライアント用デバイス通信プログラム230、デバイスドライバ240、カーネルドライバ251、バスドライバ252、ホストコントローラドライバ253、およびホストコントローラ254を有する。クライアント2は、WindowsXP(登録商標)(32bit)やWindows(登録商標)7(32bit)等のOSで動作する、PCやノートPC、タブレット端末等のスタンドアローン型コンピュータである。クライアント2は、ローカルに格納していないファイルやアプリケーションにアクセスするために、リモートアクセス環境によりサーバ1と通信する。

0046

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

0047

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

0048

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

0049

(クライアント用デバイス通信プログラム230)
クライアント用デバイス通信プログラム230は、サーバ1から入出力要求情報を受信し、受信された入出力要求情報を入出力制御情報に変換して、ローカルデバイス3に対応するデバイスドライバ240に中継する機能を有する。入出力制御情報とは、入出力要求パケット(IRP:I/O Request Packet)や、特に入出力制御コード(IOCTL:I/O Control)と呼ばれるIRPの特別なグループ命令である。クライアント用デバイス通信プログラム230は、独自プロトコルにより記述された入出力要求情報を、入出力制御情報に変換してデバイスドライバ240に中継することで、アプリケーション120からローカルデバイス3へのアクセスを実現する。クライアント用デバイス通信プログラム230は、サーバ1のアプリケーション120がローカルデバイス3を制御できるように常駐する。クライアント用デバイス通信プログラム230は、クライアント2のドライバスタックの最上位の要素または層として捉えることができる。

0050

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

0051

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

0052

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

0053

(デバイスドライバ240)
デバイスドライバ240は、ローカルデバイス3を制御し、アプリケーションソフトウェアに対して抽象化したインターフェースを提供する。デバイスドライバ240は、クライアント用デバイス通信プログラム230およびカーネルドライバ251と通信する。

0054

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

0055

(バスドライバ252)
バスドライバ252は、バスコントローラバスアダプタバスブリッジ等を制御する。バスドライバ252は、カーネルドライバ251およびホストコントローラドライバ253と通信する。

0056

(ホストコントローラドライバ253)
ホストコントローラドライバ253は、ホストコントローラ254のドライバ層であり、上位のバスドライバ252からハードウェアを抽象化する。例えば、ホストコントローラドライバ253は、ホストコントローラ254に対するI/O処理割り込み処理スケジューリング処理等を行う。ホストコントローラドライバ253は、バスドライバ252およびホストコントローラ254と通信する。

0057

(ホストコントローラ254)
ホストコントローラ254は、クライアント2とローカルデバイス3とを接続するハードウェアである。ローカルデバイス3は、ホストコントローラ254のポートを通して、クライアント2に接続する。例えば、ホストコントローラ254は、USBポートファイアワイア(IEEE1394)ポート、RS−233cなどのデバイスポートを含む。クライアント2は、PNP(Plug and Play)をサポートしていてもよいが、デバイスポートはPNPに限定されない。

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

次いで、ステップS104で、クライアント2は、デバイスドライバ(デバイスドライバ240、カーネルドライバ251、バスドライバ252)をロードする。詳しくは、クライアント2は、新たに検出されたローカルデバイス3をサポートするために必要なドライバまたはドライバスタックをロードまたはインストールする。上記ステップS102において、クライアント用デバイス通信プログラム230の起動によりローカルデバイス3が検出された場合には、ローカルデバイス3が接続された時点で既にインストール等が完了しているため、再度のインストール等は実施しない。インストール等は、PNP処理として実施されてもよい。クライアント2は、インストールが完了したことをクライアント用デバイス通信プログラム230に通知する。

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

図5Aに示すように、まず、ステップS102で、クライアント用デバイス通信プログラム230は、ローカルデバイス3を検出する。次いで、ステップS104で、クライアント用デバイス通信プログラム230は、デバイスドライバ(デバイスドライバ240、カーネルドライバ251、バスドライバ252)をロードする。そして、ステップS106で、クライアント用デバイス通信プログラム230は、デバイス中継事前準備を行う。

0075

次いで、ステップS202で、リモート・サービス・クライアント・アプリケーション210は、リモート・サービス・サーバ・アプリケーション110とのリモートサービス通信を開始する。次に、ステップS204で、リモート・サービス・サーバ・アプリケーション110は、アプリケーション120を起動する。

0076

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

0077

次いで、ステップS208−1で、アプリケーション120は、サーバ用デバイス通信プログラム130に、入出力要求情報を送信する。次に、ステップS208−2で、サーバ用デバイス通信プログラム130は、クライアント用デバイス通信プログラム230に、上記ステップS208−1で受信した入出力要求情報を中継する。次いで、図5Bに示すように、ステップS208−3で、クライアント用デバイス通信プログラム230は、受信した入出力要求情報を入出力制御情報に変換して、デバイスドライバ240に送信する。そして、ステップS208−4で、デバイスドライバ240は、受信した入出力制御情報に基づいて、ローカルデバイス3をIOCTLにより制御する。

0078

ローカルデバイス3は、上記ステップS208−4において受けたIOCTLに基づき各種処理を行い、その応答(入出力応答情報)を、ステップS208−5でデバイスドライバ240に返信する。次いで、ステップS208−6で、デバイスドライバ240は、上記ステップS208−5で返信された入出力応答情報を、クライアント用デバイス通信プログラム230に送信する。次に、ステップS208−7で、クライアント用デバイス通信プログラム230は、サーバ用デバイス通信プログラム130に、上記ステップS208−6で受信した入出力応答情報を中継する。そして、ステップS208−8で、サーバ用デバイス通信プログラム130は、受信した入出力応答情報を、アプリケーション120に送信する。

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

このように、リモート・サービス・サーバ・アプリケーション110は、クライアント2Aとの通信を、セッション140Aとして管理・識別することで、クライアント2Aとの通信と他のクライアント2との通信とを区別する。クライアント2B、2Cについても同様である。

0087

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

0088

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

0089

[2−3.第3の実施形態]
本実施形態は、サーバ1とクライアント2との間にファイアウォール又はNAT(Network Address Translation)等の中継装置が介在する場合に、サーバ1が、中継装置の利点を生かしながらローカルデバイス3を制御する形態である。図7図8を参照して、本実施形態に係る通信システムの構成を説明する。図7は、第3の実施形態に係る通信システムの構成を示すブロック図である。図8は、第3の実施形態に係る通信システムの概要を説明するための図である。

0090

[2−3−1.中継装置5の構成]
図7に示すように、中継装置5は、ファイアウォールプログラム510、およびNATプログラム520を有する。また、図8に示すように、サーバ1は、複数のクライアント2から中継装置5を経由したアクセスを受けることができる。

0091

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

0092

(NATプログラム520)
NATプログラム520は、パケットヘッダに含まれるIPアドレスを、別のIPアドレスに変換するプログラムである。NATプログラム520は、NAT(Network Address Translation)を行ってもよいし、NAPT(Network Address Port Translation)を行ってもよい。

0093

[2−3−2.サーバ1の構成]
図7に示すように、本実施形態に係るサーバ1は、図2を参照して上記説明した第1の実施例に係るサーバ1の要素に加えて、デバイス通信管理プログラム132、および接続情報DB(Data Base)134を有する。

0094

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

0095

0096

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

0097

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

0098

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

0099

そして、デバイス通信管理プログラム132は、接続情報DB134に記憶された接続情報を用いて、サーバ用デバイス通信プログラム130とクライアント用デバイス通信プログラム230との通信を中継する。詳しくは、まず、デバイス通信管理プログラム132は、アプリケーション120がローカルデバイス3を制御する際に、制御する対象のローカルデバイス3に対応する接続情報を接続情報DB134から検索する。ここで、IPアドレスによってクライアントを識別する上記特許文献3を参考に、クライアント2のIPアドレスおよびポート番号を検索キーとして、制御対象のローカルデバイス3が接続されたクライアント2の接続情報を検索することが考えられる。しかし、NATプログラム520によりIPアドレスが1対多で変換された場合、IPアドレスおよびポート番号ではクライアント2を特定することが困難となる。そこで、デバイス通信管理プログラム132は、接続先のクライアント2のクライアント名を検索キーとして接続情報DB134から接続情報を検索する。検索キーが接続先のクライアント2のクライアント名であるため、NATプログラム520によりIPアドレスが1対多で変換される場合であっても、制御対象のローカルデバイス3が接続されたクライアント2の接続情報を特定することが可能となる。検索後、デバイス通信管理プログラム132は、検索した接続情報(接続状態のもの)に含まれる通信チャネルIDが示す通信チャネルを使用して、クライアント用デバイス通信プログラム230との通信を行う。

0100

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

0101

[2−3−3.動作処理]
図9図11は、第3の実施形態に係る通信システムの動作を示すシーケンス図である。図9に示すように、まず、ステップS102で、クライアント用デバイス通信プログラム230は、デバイス中継事前準備を行う。ここでの処理は、図5Aを参照して上記説明したステップS102〜S106における処理と同様である。なお、クライアント用デバイス通信プログラム230は、常駐型のサービスプロセスである。

0102

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

0103

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

0104

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

0105

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

0106

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

0107

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

0108

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

0109

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

0110

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

0111

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

0112

S314−Nにおけるデバイス中継通信のオープンに係るポーリングにおいて、通信チャネルの検索に成功すると、デバイス通信管理プログラム132は、オープンに成功した旨を示すオープンOK回答をサーバ用デバイス通信プログラム130に応答する。

0113

そして、ステップS324で、サーバ用デバイス通信プログラム130は、オープンOK回答の受信に応じて、デバイス通信のオープンが完了した旨を、アプリケーション120に通知する。

0114

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

0115

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

0116

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

0117

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

0118

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

0119

次いで、ステップS410で、クライアント用デバイス通信プログラム230は、デバイスドライバ240を介して、ローカルデバイス3をIOCTLにより制御する。

0120

次に、ステップS412で、ローカルデバイス3は、上記ステップS410において受けたIOCTLに基づき各種処理を行い、その応答(入出力応答情報)をクライアント用デバイス通信プログラム230に返信する。

0121

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

0122

次に、ステップS416で、デバイス通信管理プログラム132は、受信した入出力応答情報を、サーバ用デバイス通信プログラム130に中継する。

0123

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

0124

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

0125

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

0126

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

0127

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

0128

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

0129

1サーバ
101プロセッサ
102メモリ
110リモート・サービス・サーバ・アプリケーション
120 アプリケーション
130 サーバ用デバイス通信プログラム
132 デバイス通信管理プログラム
134接続情報DB
140セッション
2クライアント
201 プロセッサ
202 メモリ
210 リモート・サービス・クライアント・アプリケーション
230 クライアント用デバイス通信プログラム
240デバイスドライバ
251カーネルドライバ
252バスドライバ
253ホストコントローラドライバ
254 ホストコントローラ
3ローカルデバイス
4ネットワーク
5中継装置
510ファイアウォールプログラム
520 NATプログラム

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ