JP6410423B2

JP6410423B2 - 通信制御装置、通信制御方法、及び、プログラム

Info

Publication number: JP6410423B2
Application number: JP2013245196A
Authority: JP
Inventors: 亨強矢
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-11-27
Filing date: 2013-11-27
Publication date: 2018-10-24
Anticipated expiration: 2033-11-27
Also published as: US20180103027A1; JP2015104076A; US9866541B2; US20150150089A1; US10447680B2

Description

本発明は、ネットワークで接続された複数の装置間での通信セッションの制御に関する。

近年、動画像や音声などのマルチメディアデータをＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）と呼ばれる通信プロトコルを用いてストリーミング配信し、視聴する技術が広く実用化されている。

ＲＴＰは、主に音声や動画像などをリアルタイムでデータ転送するためのプロトコルであり、ＩＥＴＦによりＲＦＣ３５５０として定義されている。

ＲＴＰは、非コネクション型のプロトコルであるＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）の上位プロトコルである。ＲＴＰを用いて動画像や音声のデータをパケット化して通信する場合、一般にネットワークに流れるＲＴＰパケットのことをストリームデータ、或いはメディアストリームなどと呼ぶ。

このＲＴＰを用いたメディアストリームの開始や終了などの制御を行うためのプロトコルとして、一般にＲＴＳＰ（ＲｅａｌＴｉｍｅＳｔｒｅａｍｉｎｇＰｒｏｔｏｃｏｌ）が知られている。ＲＴＳＰは、ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）によりＲＦＣ２３２６として定義されている。

ＲＴＳＰで制御する通信セッションは、ストリームデータを受信するクライアントから送信元のサーバに対して、所定の時間メッセージの送信が無かった場合、通信セッションがタイムアウトしたとして、サーバがセッションを切断する場合がある。

通信セッションを継続したい場合、クライアントは所定の時間が経過する前に、メッセージを送信することにより通信セッションを継続することができる。この通信セッションを継続する仕組みはキープ・アライブとも呼ばれる。

ＲＴＳＰでは、通信セッションを開始する際に、通信セッションがタイムアウトする時間をサーバからクライアントに通知する。クライアントは、通知されたタイムアウト時間が経過する前に、任意のＲＴＳＰコマンドをサーバに送信することにより通信セッションを継続することができる。

また従来、通信セッションを継続する手段として、ＲＴＳＰに加えて、ＲＴＣＰ（Ｒｅａｌ−ＴｉｍｅＴｒａｎｓｐｏｒｔＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）と呼ばれるプロトコルを利用する通信システムが知られている（例えば、特許文献１）
ＲＴＣＰは、ＲＴＰと組み合わせて使用される。ＲＴＣＰはデータのフロー制御や送信者と受信者間の情報を伝達するためのプロトコルで、ＩＥＴＦによってＲＦＣ３５５０で定義されている。

ＲＴＣＰでは、通信の状況をクライアント側からサーバ側に通知するためにＲｅｃｅｉｖｅｒＲｅｐｏｒｔ（以降、ＲＲと記述する）と呼ばれる種類のパケットが使用される。

従来、このＲＲをクライアントからサーバに定期的に通知することによって、サーバに通信セッションを継続させる方法が知られている。

特表２００５−５２６２９４号公報

しかし、複数の通信手順（通信プロトコル）を用いて通信セッションを管理する場合、サーバが認証しないクライアントとの通信セッションが確立され又は継続されてしまう場合がある。

例えば、クライアントの認証を行う機能をサポートする第１のプロトコルと、クライアントの認証を行う機能をサポートしない第２のプロトコルとを併用する場合に以下の課題が生じる。すなわち、サーバが認証しないクライアントとの通信セッションが確立され又は継続されてしまう場合がある。

例えば、ＲＴＳＰは、サーバとクライアント間で通信セッションを確立又は維持する際に、サーバがクライアントの認証を行う機能をサポートしている。

一方、ＲＴＣＰでは、サーバがクライアントの認証を行う機能をサポートしていない。従って、上述の従来例のように、クライアントからサーバにＲＲを定期的に通知することによって通信セッションを継続させる場合に、クライアントの認証を必要としない。

従って、ＲＴＳＰを用いた通信においてクライアントの認証を行った結果、サーバがクライアントと通信セッションを継続しないと判断したにもかかわらず、ＲＴＣＰによる通信によって、当該クライアントとの通信が継続してしまう場合がある。

このように、サーバとクライアント間でのセキュアな通信が行われなくなってしまう場合がある。

本発明は、このような課題を鑑みて、よりセキュアな通信セッションの制御を実現することを目的とする。

本発明の目的を達成するために、例えば本発明にかかる通信制御装置は以下の構成を備える。

すなわち、通信装置との通信セッションの維持に関する判定のために前記通信装置の認証を行う第１の通信プロトコル、及び、前記通信装置の認証をせずに前記通信装置と通信を行う第２の通信プロトコルを用いて前記通信装置との通信を行う通信手段と、前記第１の通信プロトコルに基づく前記通信装置の認証が成功している状態においては、前記第１の通信プロトコルに基づいて構築された通信セッションの維持に関するセッションタイムアウトの判定を前記第１の通信プロトコルによる通信状況と前記第２の通信プロトコルによる通信状況とに基づいて行い、前記第１の通信プロトコルに基づく前記通信装置の認証が失敗している状態においては、前記第１の通信プロトコルに基づいて構築された通信セッションの維持に関するセッションタイムアウトの判定を前記第２の通信プロトコルによる通信状況によらず前記第１の通信プロトコルによる通信状況に基づいて行う制御手段とを有する。

以上の構成からなる本発明によれば、よりセキュアな通信セッションの制御を実現することができる。

サーバ１００の構成を示す図。サーバ１００における通信セッションのタイムアウト時間を記憶する処理の一例を示すフローチャート。サーバ１００における通信セッションを継続するか切断するか判定処理の一例を示すフローチャート。実施形態１にかかるサーバ１００における通信セッション制御の一例を示すシーケンス図。実施形態２にかかるサーバ１００における通信セッション制御の一例を示すシーケンス図である。サーバ１００において、ＲＴＳＰ認証失敗後に再び認証が成功した場合の処理の一例を示すシーケンス図。

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

＜実施形態１＞
本発明の一実施形態である通信制御装置の例を図１に示す。図１は、本発明の第１の実施形態におけるサーバ１００（通信制御装置）の構成例を示すブロック図である。

サーバ１００は例えば、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）やタブレット端末等のクライアントに対して映像データを送信する送信装置とすることができる。あるいはサーバ１００は、撮像を行う撮像部を有するネットワークカメラとしてもよい。ネットワークカメラにサーバ１００の機能を搭載する場合、撮像部において撮像された映像データをＰＣやタブレット端末等のクライアントに送信してもよい。

図１において、サーバ１００は、生成部１０１、制御部１０２、管理部１０３、保持部１０４、通信部１０５を有する。

伝送路１０６は、いわゆる３Ｇや４Ｇ等の携帯電話方式の通信サービスや、インターネット、或いはＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）等のネットワークである。

通信部１０５はデータを送受信する機能を備え、伝送路１０６と通信可能な様に接続される。尚、通信手段は無線でも有線でも良い。

通信部１０５は、通信装置（以下、「クライアント」という）との通信セッションを維持するためにクライアントの認証を行う第１の通信手順を用いてクライアントとの通信セッションを構築することができる。また通信部１０５は、クライアントと通信するためにクライアントの認証を必要としない第２の通信手順を用いてクライアントとの通信を行うことができる。

本実施例では、通信部１０５はＲＴＳＰ（第１の通信手順）によって、クライアントとの通信を行うことができるものとする。また本実施例において通信部１０５はＲＴＣＰ（第２の通信手順）によって、クライアントとの通信を行うことができるものとする。

ここで、ＲＴＳＰを用いた通信においては、サーバ１００とクライアントとの間に通信セッションが構築される。クライアントはＲＴＳＰ（第１の通信手順）により規定された手順を用いて、サーバ１００から送信される映像の再生、一時停止、停止等の操作をサーバ１００に対して行うことができる。例えば、サーバ１００がネットワークカメラである場合、クライアントはネットワークカメラが撮像した映像の送信の一時停止、再開、停止等をＲＴＳＰに規定された手順を用いて行うことができる。

本実施例において、通信セッションとは、第１の通信手順を用いてサーバ１００の映像送信を制御するために用いられるセッションである。本実施例では、通信セッションを切断すると、サーバ１００からクライアントへの映像ストリーミングも終了されるものとする。あるいは、第１の通信手順を用いてサーバ１００の映像送信を制御するために用いられる通信セッションが切断された場合でも、映像ストリーミングは継続されることとしてもよい。

ＲＴＳＰを用いた通信においては、サーバとクライアント間で通信セッションを確立及び維持する際に、サーバ１００がクライアントの認証を行うことができる。

ＲＴＳＰを用いた通信において、サーバ１００はクライアントから第１のデータ（例えば、第１のＲＴＳＰコマンド）を受信した後に、第２のデータ（例えば、第２のＲＴＳＰコマンド）を受信する。第１のＲＴＳＰコマンド及び第２のＲＴＳＰコマンドは、例えば、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドとすることができる。

サーバ１００は、第１のデータが受信されてから第１の所定時間が経過するまでに第２のデータを受信し、かつ、第２のデータを送信したクライアントが所定のクライアントであると認証された場合には、クライアントとの通信セッションを維持する。第１の所定時間はタイムアウト時間である。

また、ＲＴＣＰを用いた通信においては、サーバ１００とクライアントとの間に通信セッションは構築されない。本実施例において、ＲＴＣＰの通信手順が、構築された通信セッションを維持するために用いられる場合について説明する。クライアントは、ＲＴＣＰにより規定された手順を用いて、サーバ１００から送信されたデータの受信状況をＲＲに記載してサーバ１００に通知する。ＲＲには例えば、パケットロスト数や、パケット到達時間のジッター等についての情報が記載される。

本実施例にかかるサーバ１００は、ＲＴＳＰを用いて構築された通信セッションのタイムアウト時間を、ＲＲを受信する度に更新する。

例えば、ＲＴＣＰを用いた通信において、サーバ１００はクライアントから第３のデータ（例えば、ＲＴＣＰの第１のＲＲ）を受信した後に、第４のデータ（例えば、ＲＴＣＰの第２のＲＲ）を受信する。

ＲＴＣＰを用いた通信において、サーバ１００は、第３のデータが受信されてから第２の所定時間が経過するまでに第４のデータを受信した場合には、ＲＴＳＰの通信手順によって構築された通信セッションを維持する。

本実施例にかかるサーバ１００は、ＲＴＳＰを用いて構築した通信セッションを維持するか否かを、ＲＴＳＰコマンドの受信及びＲＲの受信によって判断する。従って、クライアント装置がＲＴＳＰコマンド又はＲＲの一方のみを用いて、通信セッションを維持するか否かを決定する場合であっても、本発明のサーバ１００によれば適切にセッションの維持を行うことができる。

生成部１０１は、例えばＲＴＰプロトコルを用いる場合、外部から入力された動画像や音声の符号化されたデータを、通信に適したサイズに分割し、更にメディアの種類毎に適切なヘッダを付加してＲＴＰのデータパケットを生成する。

制御部１０２は、サーバ１００の各構成を制御する。制御部１０２は、クライアントとの通信セッションの作成や切断に関する指示を行う。また、制御部１０２はサーバ１００からクライアントに送信するデータのフロー制御を行う。

本実施形態において、制御部１０２は通信装置との通信セッションを維持するかを決定する制御を第１の通信手順（例えば、ＲＴＳＰ）及び前記第２の通信手順（例えば、ＲＴＣＰ）を用いて行う。また、制御部１０２は、第１の通信手順によりクライアントが所定のクライアントであると認証されない場合には、以下の制御を行う。すなわち、第２の通信手順によりクライアントとの通信セッションを維持することを制限する制御を行う。

制御部１０２は例えば、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）などのプロセッサとすることができる。制御部１０２がプロセッサとして構成される場合、例えば制御部１０２は、後述の保持部１０４に記憶されたプログラムを実行することにより、サーバ１００の各構成を制御する。

管理部１０３は、通信セッションが作成されたクライアントからサーバ１００に送信されるデータの内容及び当該データが受信された時刻を後述の保持部１０４に保持させる。管理部１０３は、クライアントから送信されたデータとともに、当該データが送信された時刻を保持部１０４に保持させることとしてもよい。また管理部１０３は、保持部１０４に記憶させた情報に基づいて、クライアントとの通信セッションの維持に関する情報の管理を行う。

保持部１０４は、クライアントから受信したデータの内容を保持する。また保持部１０４は、サーバ１００がクライアントからデータを受信された時刻、又は、クライアントからデータが送信された時刻の情報を保持する。本実施例において、保持部１０４に保持される時刻は、通信セッションのタイムアウト時間の計測が開始される時刻である。たとえば、タイムアウト時間が６０秒である場合、保持部１０４に保持された時刻から６０秒が経過すると、サーバ１００はクライアントとの通信セッションを切断する。

次に、本実施形態のサーバ１００による通信セッション制御の詳細について、図２及び図３を用いて説明する。図２及び図３は、本実施形態のサーバ１００における通信セッション制御の一例を示すフローチャートである。

サーバ１００の制御部１０２がプロセッサ及びメモリを内蔵する形態では、図２及び図３に示した処理は、図２及び図３に示される手順を制御部１０２が保持部１０４に格納されたプログラムをメモリに展開して実行することにより実現される。サーバ１００は、各手順を実行することにより、各手順を実現する各構成として機能する。あるいは、図２及び図３に示す処理の一部又は全体をハードウェアが行うこととしてもよい。

クライアントからパケットを受信した際に、サーバ１００がパケットの最終受信時間を記憶する処理の例について、図２を用いて説明する。

図２において、まず制御部１０２は、通信部１０５が受信したパケットの種別を判定する（Ｓ２０１）。パケットがＲＴＳＰコマンドであった場合は、ステップＳ２０２へ進み、ＲＴＣＰのＲＲであった場合はステップＳ２０５へ進む。

ここで、ＲＴＳＰコマンドとは、ＲＴＳＰを用いた通信において、クライアントからサーバ１００に送信されるコマンドである。

また、ＲＴＣＰのＲＲとは、ＲＴＣＰを用いた通信において、クライアントからサーバに送られるパケットである。サーバから通知されたセッションのタイムアウト時間が経過する前にクライアントがＲＲをサーバに通知することによって、クライアントはサーバに通信セッションを継続させることができる。

ステップＳ２０１において制御部１０２が行う判定は上記の例に限られず、通信部１０５において受信したデータが、クライアントの認証を行う通信手順を用いて送信されたデータであるか否かを判定することとすればよい。

通信部１０５が受信したパケットがＲＴＳＰコマンドであった場合（Ｓ２０１においてＲＴＳＰの場合）、制御部１０２はＲＴＳＰの認証機能が有効であるか判定する（Ｓ２０２）。ここで、ＲＴＳＰの認証機能とは、ＲＴＳＰを用いた通信手順において、サーバ１００にアクセスを行ったクライアントが、サーバ１００との通信セッションを構築することを許可するクライアントであるか判定する機能である。認証の方式として、例えば、ＤＩＧＥＳＴ認証やＢＡＳＩＣ認証を用いることができる。ＲＴＳＰの認証機能が有効であるか、無効であるかの設定は保持部１０４に保持されているものする。クライアントがサーバ１００に指示して、認証機能の有効又は無効を切り替えられることとしてもよい。

ＲＴＳＰの認証モードが有効である場合（Ｓ２０２においてＹｅｓの場合）、制御部１０２はＲＴＳＰ認証を実行して、クライアントがサーバ１００との通信セッションを構築することを許可するクライアントであるか判定する（Ｓ２０３）。ステップＳ２０３においてクライアントが認証された場合（Ｓ２０３においてＯＫの場合）、制御部１０２はステップＳ２０４の処理を行う。一方、ステップＳ２０３においてクライアントが認証されなかった場合（Ｓ２０３においてエラーの場合）、制御部１０２は処理を終了する。

ステップＳ２０３において、クライアントが所定のクライアントであると認証されなかった場合、サーバ１００はＲＴＳＰによる認証が失敗した状態であることを保持部１０４に保持する。あるいは、サーバ１００はＲＴＳＰによる認証が成功した状態であることを保持部１０４に保持することとしてもよい。

また、ステップＳ２０２においてＲＴＳＰ認証モードが無効である場合（Ｎｏの場合）は、制御部１０２は、ＲＴＳＰ認証を行わずにステップＳ２０４の処理を行う。

ステップＳ２０４では、制御部１０２は管理部１０３を制御して、通信セッション毎に、最後にＲＴＳＰコマンドを受信した時刻（最終受信時間）を保持部１０４に保持させて処理を終了する。保持部１０４に保持されたＲＴＳＰコマンドの受信時刻から所定のタイムアウト時間（例えば、６０秒）がカウントされる。当該タイムアウト時間以内に新たなＲＴＳＰコマンドが受信され、かつ、ＲＴＳＰによるクライアントの認証に成功した場合には、サーバ１００は通信セッションを維持すると判定する。

一方、ステップＳ２０１において、受信したパケットの種類がＲＴＣＰのＲＲであると判定した場合、制御部１０２はステップＳ２０５の処理を行う。

通信部１０５が受信したパケットがＲＴＣＰコマンドであった場合（Ｓ２０１においてＲＴＣＰのＲＲの場合）、ステップＳ２０５において制御部１０２は、その時点で当該通信セッションがＲＴＳＰ認証に失敗した状態か否かのチェックを行う。ＲＴＳＰ認証が失敗した状態の場合（ステップＳ２０５においてＹｅｓの場合）、制御部１０２は処理を終了する。ＰＴＳＰ認証が失敗した状態であることは保持部１０４に保持されている。

一方、ＲＴＳＰ認証に成功した状態か、或いはＲＴＳＰ認証が無効である場合（ステップＳ２０５においてＮｏの場合）、制御部１０２はステップＳ２０６の処理を行う。ＰＴＳＰ認証が成功した状態であること、ＲＴＳＰ認証が無効であることは保持部１０４に保持されている。

ステップＳ２０６では、制御部１０２は管理部１０３を制御して、通信セッション毎に、最後にＲＴＣＰのＲＲを受信した時刻（最終受信時間）を保持部１０４に保持させる。保持部１０４に保持されたＲＲの受信時刻から所定のタイムアウト時間（例えば、６０秒）がカウントされ、当該タイムアウト時間以内に新たなＲＲが受信された場合には、サーバ１００は通信セッションを維持すると判定する。

以上のとおり、図２に示したフローによれば、以下の処理を行うことができる。

即ち、クライアントから第１のデータ（ＲＴＳＰコマンド）を第１の通信手順（ＲＴＳＰ）を用いて受信した場合を第１の場合とする（Ｓ２０１でＲＴＳＰの場合）。また、第１のデータを送信したクライアントが所定の通信装置であると認証された場合を第２の場合とする（Ｓ２０３でＹｅｓの場合）。第１の場合であって、かつ、第２の場合、第１のデータを受信した時刻を保持部１０４に保持する。

また、クライアントから第１のデータを第１の通信手順を用いて受信し、かつ、クライアントが所定の通信装置であると認証されない場合には、第１のデータを受信した時刻を保持部１０４に保持しない。（Ｓ２０１でＲＴＳＰ、Ｓ２０３でエラーの場合）。

ＲＴＳＰコマンド（第１のデータ）を受信した時刻が保持部１０４に保持されない場合、新たなＲＴＳＰコマンドを受信しても、タイムアウト時間の計測を開始する時刻が更新されない。従って、セッションタイムアウトにより、クライアントとの通信セッションが維持されなくなる。

また図２に示したフローによれば、以下の処理を行うことができる。

すなわち、クライアントから第３のデータ（ＲＲ）を第２の通信手順（ＲＴＣＰ）を用いて受信した場合を第３の場合とする（Ｓ２０１でＲＴＣＰＲＲの場合）。また、第１の通信手順によりクライアントが所定のクライアントであると認証された状態である場合を第４の場合とする（Ｓ２０５でＮｏの場合）。第３の場合であって、かつ、第４の場合、第３のデータを受信した時刻を保持部１０４に保持する。

またクライアントから第３のデータを第２の通信手順を用いて受信し、かつ、第１の通信手順によりクライアントが所定のクライアントであると認証されていない状態である場合には、第３のデータを受信した時刻を保持部１０４に保持しない。（Ｓ２０１でＲＴＣＰＲＲ、Ｓ２０５でＹｅｓの場合）。

ＲＲ（第３のデータ）を受信した時刻が保持部１０４に保持されない場合、新たなＲＲを受信しても、タイムアウト時間の計測を開始する時刻が更新されないので、セッションタイムアウトにより、クライアントとの通信が維持されなくなる。

図２を用いて説明した処理は、通信セッション毎に通信部１０５がクライアントから送信されたパケットを受信する度に実行される。ステップＳ２０４及びステップＳ２０６においては、図２を用いて説明した処理が繰り返される度に、保持部１０４に保持した時間が更新される。

次に、図２を用いて説明した処理によって記憶されたパケットの最終受信時間と通信セッションのタイムアウト時間を基に、当該通信セッションを継続するか切断するか判定する処理の例について図３を用いて説明する。制御部１０２は、定期的に（例えば、１秒おきに）図３の処理を実行する。

まず制御部１０２は、保持部１０４から、最後にＲＴＳＰコマンドを受信した時刻と、最後にＲＴＣＰのＲＲを受信した時刻を取得する（Ｓ３０１）。

次に制御部１０２は、最後にＲＴＳＰコマンドを受信した時刻から現在の時刻までの経過時間と、当該通信セッションのタイムアウト時間とを比較して、ＲＴＳＰを用いて構築された通信セッションをタイムアウトとするか確認する（Ｓ３０２）。

最後にＲＴＳＰコマンドを受信した時刻から現在の時刻までの経過時間が、ＲＴＳＰを用いた通信におけるタイムアウト時間を経過していなかった場合（Ｓ３０２においてＮｏの場合）は、制御部１０２はステップＳ３０３の処理を実行する。すなわち、クライアントとの通信セッションを継続する（Ｓ３０３）。

最後にＲＴＳＰコマンドを受信した時刻から現在の時刻までの経過時間が、ＲＴＳＰを用いた通信におけるタイムアウト時間を経過している場合（Ｓ３０２においてＹｅｓの場合）は、制御部１０２はステップＳ３０４の処理を実行する。

ステップＳ３０４において、制御部１０２は、当該通信セッションがＲＴＳＰ認証に失敗した状態か否かのチェックを行う。ＲＴＳＰ認証が失敗した状態であった場合（Ｓ３０４においてＹｅｓの場合）、制御部１０２はステップＳ３０６へ進み、クライアントとの通信セッションを切断する制御を行う。ステップＳ３０６において制御部１０２は、クライアントとの通信セッションを切断する。

ステップＳ３０４においてＲＴＳＰ認証に成功した状態である場合、及び、ＲＴＳＰ認証が無効である場合（Ｓ３０４においてＮｏの場合）には、制御部１０２はステップＳ３０５へ進む。

ステップＳ３０５において制御部１０２は、ＲＴＣＰのＲＲを最後に受信した時刻から現在の時刻までの経過時間と、ＲＴＣＰを用いた通信セッションのタイムアウト時間とを比較することで、当該通信セッションをタイムアウトとするか確認する。

ＲＴＣＰのＲＲを最後に受信した時刻から現在の時刻までの経過時間が、タイムアウト時間を経過していない場合（ステップＳ３０５においてＮｏの場合）は、制御部１０２はステップＳ３０３の処理を実行する。すなわち、制御部１０２はクライアントとの通信セッションを継続する（Ｓ３０３）。

ＲＴＣＰのＲＲを最後に受信した時刻から現在の時刻までの経過時間が、タイムアウト時間を経過していた場合（Ｓ３０５においてＹｅｓの場合）は、制御部１０２はステップＳ３０６の処理を実行する。すなわち制御部１０２は、クライアントとの通信セッションを切断する（Ｓ３０６）。

以上のとおり、図３に示したフローによれば、以下の処理を行うことができる。

すなわち、第２のデータ（ＲＴＳＰコマンド）を送信したクライアントが所定のクライアントであると認証された場合を第５の場合とする（Ｓ２０３においてＹｅｓの場合）。また、保持部１０４に保持された時刻から所定時間が経過するまでに第２のデータを第１の通信手順（ＲＴＳＰ）を用いて受信した場合を第６の場合とする（Ｓ３０２においてＮｏの場合）。第５の場合であってかつ第６の場合には、クライアントとの通信セッションを維持するように制御する（Ｓ３０３）。

また、図３に示したフローによれば、以下の処理を行うことができる。

すなわち、保持部１０４に保持された時刻から所定時間が経過するまでに第４のデータ（ＲＲ）を第２の通信手順（ＲＴＣＰ）を用いて受信した場合には、クライアント装置との通信セッションを維持するように制御する（Ｓ３０５でＮｏ）。

図３の処理は、例えば１秒から数秒おきに繰り返し実行し、通信セッションを適時タイムアウトさせることで、セキュアな通信セッションの維持を可能にする。

次に、図２及び図３を用いて説明した処理の流れの一例について、図４及び図５に示したシーケンス図を用いて説明する。図４は、本発明の一実施形態であるサーバにおける通信セッション制御の一例を示すシーケンス図である。

サーバ１００がＲＴＳＰ及びＲＴＣＰを用いてクライアントとの通信セッションを制御する例について、図４を用いて説明する。

図４に示した例において、サーバ１００は、ＲＴＳＰを用いた通信におけるタイムアウト時間が経過する前にＲＴＳＰコマンドの１つであるＧＥＴ＿ＰＡＲＡＭＥＴＥＲをクライアントから受信すると、クライアントの通信セッションを継続する。

また図４に示した例においてサーバ１００は、ＲＴＣＰを用いた通信におけるタイムアウト時間が経過する前にＲＲをクライアントから受信すると通信セッションを継続する。

本実施例では、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲを受信してから通信セッションがタイムアウトするまでの時間が６０秒である場合について説明する。また、ＲＲを受信してから通信セッションがタイムアウトするまでの時間が６０秒である場合について説明する。

図４において、時刻４０３は、サーバ１００がクライアントから第１のＲＴＳＰコマンド（第１のＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信した時刻４００からタイムアウト時間である６０秒が経過する時刻を示す。

サーバ１００は、時刻４０３が経過する以前に第２のＲＴＳＰコマンドを受信し、かつ、当該ＲＴＳＰコマンドを送信したクライアントがサーバ１００に認証された場合には、当該クライアントとの通信セッションを継続する。

一方、第１のＲＴＳＰコマンドを受信した後、時刻４０３が経過する以前に第２のＲＴＳＰコマンド（第２のＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信せず、ＲＲ受信によるセッション維持もなされない場合、クライアントとの通信セッションを切断する。また、時刻４０３が経過する以前に第２のＲＴＳＰコマンドを受信した場合であっても、当該ＲＴＳＰコマンドを送信したクライアントがサーバ１００に認証されない場合には、通信セッションを切断する。

タイムアウト時間は６０秒に限られない。また、ＲＴＳＰを用いた通信におけるタイムアウト時間と、ＲＴＣＰを用いた通信におけるタイムアウト時間は必ずしも同じ長さでなくともよい。

時刻４０４は、サーバ１００がＲＴＣＰの第１のＲＲを受信してからタイムアウト時間である６０秒が経過する時刻を示す。また時刻４０５は、サーバ１００がクライアントから第２のＲＲを受信してからタイムアウト時間である６０秒が経過する時刻を示す。

サーバ１００は、第１のＲＲを受信した後、時刻４０４が経過する前に第２のＲＲを受信した場合にはクライアントとの通信セッションを継続する。

一方、サーバ１００は時刻４０４が経過する前に第２のＲＲを受信せず、ＲＴＳＰコマンドによるセッション維持もなされない場合には、クライアントとの通信セッションを切断する。時刻４０５についても時刻４０４と同様にして、クライアントとの通信セッションを継続するか否かを判定する。

時刻４０１は、第１のＲＴＳＰコマンドを受信した時刻４００と第２のＲＴＳＰコマンドの受信した時刻との間において、クライアントがＲＴＳＰ認証モードの変更やパスワードの変更などの設定変更を行った時刻を表す。

図４に示した時刻４０１において、例えば、サーバ１００においてＲＴＳＰ認証モードの変更やパスワードの変更などがあった場合、第２のＲＴＳＰコマンドを送信したクライアントがＲＴＳＰの認証に失敗することがある。この場合、サーバ１００がクライアントを認証しないことを示すエラーコード４０２（Ｕｎａｕｔｈｏｒｉｚｅｄ）をクライアントに返す。

ＲＴＳＰを用いた通信においてクライアントが認証されなかった場合（認証エラーの場合）、サーバ１００は、第２のＲＴＳＰコマンドの受信後、ＲＴＣＰのＲＲを受信してもクライアントとの通信セッションを継続しないようにする。

例えば、クライアントからＲＲを受信することによる通信セッションの継続を無効にする。すなわち、時刻４０５のタイムアウト時刻は無効となる。

図４の例では、クライアントが認証されないまま時刻４０３を経過した場合、保持部１０４に保持されているＲＲの最終受信時刻（第２のＲＲの受信時刻）から６０秒が経過する前に第３のＲＲを受信したとしても、通信セッションを維持させない。

そして、第１のＲＴＳＰコマンド（ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信した時刻からタイムアウト時間である６０秒が経過する時刻４０３を、クライアントとの通信セッションのタイムアウト時刻とする。図４の例において、第１のＲＴＳＰコマンドは、当該コマンドをサーバ１００が受信したときにクライアントの認証に成功したコマンドである。このようにして、ＲＴＳＰを用いた通信においてサーバがクライアントを認証しなかった場合には、その後、ＲＴＣＰを用いた通信によってクライアントとの通信セッションが継続されないようにすることができる。

このようにして、サーバ１００がクライアントの認証を行う機能を実現できる第１の通信手順と、サーバ１００がクライアントの認証を必要としない第２の通信手順を併用して通信を行う場合にも、認証したクライアントとのみ通信を継続することができる。従って、サーバ１００とクライアントとの間で、よりセキュアな通信を実現することができる。

本実施例では、ＲＴＳＰを用いた通信においてクライアントが認証されなかった場合でも、クライアントとの通信セッションのタイムアウト時刻が経過するまでは、通信セッションを維持するものとする。このようにして、一度クライアントが認証に失敗しても、タイムアウト前に再度認証を行い、認証に成功した場合には、通信セッションを維持させることができる。

ＲＴＳＰの認証が失敗し、その後に同じ通信セッションでＲＴＳＰの認証が成功した場合の処理の例について、図６を用いて説明する。

時刻６０１は、クライアントにおいて、ＲＴＳＰ認証モードの変更やパスワードの変更などがあった時刻を表す。

コマンド６０２は、クライアントが時刻６０１において行った変更のために、サーバ１００がクライアントを認証しないことを示すエラーコードである。コマンド６０２は、第１のＲＴＳＰコマンドの受信に応答して、サーバ１００からクライアントに送信される。

クライアントのＲＴＳＰ認証に失敗すると、サーバ１００は、ＲＴＳＰ認証に失敗した状態では、当該通信セッションにおいて、ＲＴＣＰのＲＲによる通信セッションの継続を無効とする。即ち、図６の６０３に示すＲＴＣＰＲＲは、ＲＴＳＰ認証がエラーとなった状態で受信したものなので、６０３に示すＲＴＣＰＲＲを受信したことを理由とするセッションの継続は行わない。図６では、ＲＴＳＰ認証がエラーになる前のＲＴＣＰＲＲの受信から６０秒のセッションタイムアウト時刻が経過するまでは、セッションが継続される。

ＲＴＣＰ認証がエラーになった後、セッションタイムアウト時刻が経過するまでに、第２のＲＴＳＰコマンドを受信し、クライアントのＲＴＳＰ認証が成功した場合、サーバ１００はクライアントに認証が成功したことを示すコマンド６０４を送信する。

サーバ１００は、コマンド６０４を送信した以後は、ＲＴＣＰのＲＲを受信したことを理由として通信セッションを継続する機能を有効に切り替える。すなわち、ＲＲ６０５はクライアントのＲＴＳＰ認証が成功した状態で受信したものなので、ＲＲ６０５による当該セッションの継続は有効となる。

こうして、第１の通信手順によりクライアントが所定のクライアントであると認証されなかった第１の時刻からクライアントが認証された第２の時刻までの期間には第２の通信手順によりクライアントとの通信セッションを維持することを制限する。ここで、第１の通信手順はＲＴＳＰであり、第２の通信手順はＲＴＣＰとすることができる。そして、第２の時刻以後は第２の通信手順によりクライアントとの通信セッションを維持することを許可する制御を行う。

このようにすれば、サーバ１００によるクライアントの認証が失敗した後、当該クライアントがサーバ１００によって認証された場合には、クライアントがＲＴＣＰのＲＲを送信することにより通信セッションを継続させる機能を有効にすることができる。

＜実施形態２＞
実施形態１では、ＲＴＳＰを用いた通信においてクライアントが認証されなかった場合、それ以降、サーバ１００がＲＴＣＰのＲＲを受信してもクライアントとの通信セッションを継続しないようにする例について説明した。

しかし、クライアントが認証されなかった場合、それ以降に受信したＲＲのうち所定の時間内にＲＲを受信した場合には、ＲＲの受信に応じてサーバ１００がクライアントとの通信セッションを継続させることとしてもよい。

実施形態２では、第１のＲＲを受信してから所定時間が経過する前に第２のＲＲを受信した場合、第１のＲＲの受信時刻と第２のＲＲの受信時刻の間でＲＴＳＰのクライアント認証が失敗しても、第２のＲＲの受信に応じて通信セッションを継続させる。

実施形態２における送信装置の構成については、実施形態１において図１を用いて説明した内容と同じであるため説明を省略する。

実施形態２における通信セッション制御の例を、図５を用いて説明する。

実施形態１において図４を用いて説明した内容と同様に、ＲＴＳＰによる通信及びＲＴＣＰによる通信のタイムアウト時間は６０秒である場合について説明する。

時刻５０３は第１のＲＴＳＰコマンド（第１のＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信してから６０秒後の時刻を表す。

時刻５０４は第１のＲＲを受信してから６０秒後の時刻を表す。時刻５０５は、第１のＲＲの後に送信される第２のＲＲをサーバが受信してから６０秒後の時刻を表す。また、時刻５０６は、第２のＲＲの後に送信される第３のＲＲをサーバが受信してから６０秒後の時刻を表す。

図５において、時刻５０１は、第１のＲＴＳＰコマンドを受信した時刻と第２のＲＴＳＰコマンドの受信した時刻との間において、クライアントがＲＴＳＰ認証モードの変更やパスワードの変更などの設定変更を行った時刻を表す。

図５の時刻５０１において、例えば、ＲＴＳＰ認証モードの変更やパスワードの変更などがあった場合、第２のＲＴＳＰコマンドに応じて実行されるクライアント認証が失敗すると、サーバ１００は認証エラーを示すエラーコード５０２を応答する。

ここで、本実施形態では第２のＲＲを受信してから第３のＲＲを受信するまでに、クライアントの認証が失敗となった場合について説明する。

実施形態１においては、クライアントが認証されなかった場合、それ以降に受信した第３のＲＲによっては通信セッションが継続されない場合について説明した。しかし、本実施形態では、第２のＲＲを受信した時刻から所定のタイムアウト時間が経過するまでに第３のＲＲを受信した場合には、サーバ１００は第３のＲＲの受信に応じて通信セッションを継続すると判定する。

そして、クライアントの認証が失敗した後に受信した第３のＲＲから所定のタイムアウト時間が経過するまでに第４のＲＲを受信しても、第４のＲＲの受信に応じて通信セッション継続する機能は無効とする。

このようにしても、ＲＴＳＰを用いた通信においてサーバがクライアントを認証しなかった場合には、その後、ＲＴＣＰを用いた通信によってクライアントとの通信セッションが継続されないようにすることができる。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１００サーバ
１０２制御部
１０３管理部
１０４保持部
１０５通信部

Claims

通信装置との通信セッションの維持に関する判定のために前記通信装置の認証を行う第１の通信プロトコル、及び、前記通信装置の認証をせずに前記通信装置と通信を行う第２の通信プロトコルを用いて前記通信装置との通信を行う通信手段と、
前記第１の通信プロトコルに基づく前記通信装置の認証が成功している状態においては、前記第１の通信プロトコルに基づいて構築された通信セッションの維持に関するセッションタイムアウトの判定を前記第１の通信プロトコルによる通信状況と前記第２の通信プロトコルによる通信状況とに基づいて行い、前記第１の通信プロトコルに基づく前記通信装置の認証が失敗している状態においては、前記第１の通信プロトコルに基づいて構築された通信セッションの維持に関するセッションタイムアウトの判定を前記第２の通信プロトコルによる通信状況によらず前記第１の通信プロトコルによる通信状況に基づいて行う制御手段と、を有することを特徴とする通信制御装置。
前記第１の通信プロトコルに基づいてアクセスした前記通信装置が通信セッションを構築することを許可する通信装置であると判定される場合は認証成功と判定し、
前記第１の通信プロトコルに基づいてアクセスした前記通信装置が通信セッションを構築することを許可しない通信装置であると判定される場合は認証失敗と判定する判定手段を有することを特徴とする請求項１に記載の通信制御装置。
前記認証が成功している状態とは、前記通信装置の認証に成功したと判定されたタイミングから、前記通信装置の認証に失敗したと判定されたタイミングまでの期間に対応することを特徴とする請求項１又は２に記載の通信制御装置。
前記認証が失敗している状態とは、前記通信装置の認証に失敗したと判定されたタイミングから、前記通信装置の認証に成功したと判定されたタイミングまでの期間に対応することを特徴とする請求項１乃至３のうち、何れか１項に記載の通信制御装置。
前記制御手段は、前記通信装置の認証が成功している状態においては、前記第１及び第２の通信プロトコルの何れかに基づくデータの受信から所定時間内に前記第１及び第２の通信プロトコルのうち少なくとも何れかに基づくデータが受信された場合には前記通信セッションを維持する一方、前記通信装置の認証が失敗している状態においては、前記第１の通信プロトコルに基づくデータの受信から前記所定時間内に前記第１の通信プロトコルに基づくデータを受信しなかった場合には、前記所定時間内に前記第２の通信プロトコルに基づくデータを受信したとしても、前記通信セッションを切断するようセッションタイムアウトの判定を行うことを特徴とする請求項１乃至４のうち、何れか１項に記載の通信制御装置。
前記通信手段は、前記通信装置から第１のデータ及び前記第１のデータよりも後に受信される第２のデータを前記第１の通信プロトコルを用いて受信し、
前記制御手段は、前記第１のデータが受信されてから所定時間が経過するまでに前記第２のデータを受信し、かつ、前記第２のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記通信装置との通信セッションを維持するようにセッションタイムアウトの判定を行うことを特徴とする請求項１に記載の通信制御装置。
前記制御手段は、前記通信装置の認証が成功している状態における前記第１の通信プロトコルに基づくデータの受信に応じて、前記第１の通信プロトコルに基づく第１データ受信時刻を更新し、且つ、前記第２の通信プロトコルに基づくデータの受信に応じて、前記第２の通信プロトコルに基づく第２データ受信時刻を更新し、前記第１及び第２データ受信時刻からの経過時間がいずれも所定時間に達すると、前記通信セッションを切断することを特徴とする請求項１に記載の通信制御装置。
前記第１及び第２データ受信時刻をメモリに記憶させる記憶制御手段を有することを特徴とする請求項７に記載の通信制御装置。
前記制御手段は、前記通信装置の認証が失敗している状態において前記第２の通信プロトコルを用いたデータの受信をしても、前記第２データ受信時刻を更新しないことを特徴とする請求項７又は８に記載の通信制御装置。
通信装置との通信セッションの維持に関する判定のために前記通信装置の認証を行う第１の通信プロトコル、及び、前記通信装置の認証をせずに前記通信装置との通信を行う第２の通信プロトコルを用いて前記通信装置との通信を行う通信手段を有する通信装置の制御方法であって、
前記第１の通信プロトコルに基づく前記通信装置の認証が成功している状態においては、前記第１の通信プロトコルに基づいて構築された通信セッションの維持に関するセッションタイムアウトの判定を前記第１の通信プロトコルによる通信状況と前記第２の通信プロトコルによる通信状況とに基づいて行い、前記第１の通信プロトコルに基づく前記通信装置の認証が失敗している状態においては、前記第１の通信プロトコルに基づいて構築された通信セッションの維持に関するセッションタイムアウトの判定を前記第２の通信プロトコルによる通信状況によらず前記第１の通信プロトコルによる通信状況に基づいて行う制御ステップを有することを特徴とする通信制御方法。
前記通信装置から第１のデータ及び前記第１のデータよりも後に受信される第２のデータを前記第１の通信プロトコルを用いて受信する場合、
前記制御ステップにおいて、前記第１のデータが受信されてから第１の所定時間が経過するまでに前記第２のデータを受信し、かつ、前記第２のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記通信装置との通信セッションを維持するようにセッションタイムアウトの判定を行うことを特徴とする請求項１０に記載の通信制御方法。
前記第１の通信プロトコルにより前記通信装置が所定の通信装置であると認証された状態で前記通信装置から第３のデータを前記第２の通信プロトコルを用いて受信した場合には、前記第３のデータを受信した時刻を保持手段に保持し、前記第１の通信プロトコルにより前記通信装置が所定の通信装置であると認証されていない状態で前記通信装置から前記第３のデータを前記第２の通信プロトコルを用いて受信した場合には、前記第３のデータを受信した時刻を前記保持手段に保持しない保持ステップを有し、
前記制御ステップにおいて、前記保持手段に保持された時刻から所定時間が経過するまでに第４のデータを前記第２の通信プロトコルを用いて受信した場合には、前記通信装置との通信セッションを維持するように制御することを特徴とする請求項１０に記載の通信制御方法。
前記制御ステップにおいて、前記第１の通信プロトコルにより前記通信装置が所定の通信装置であると認証されなかった第１の時刻から前記第１の通信プロトコルにより前記通信装置が所定の通信装置であると認証された第２の時刻までの期間には前記第２の通信プロトコルの通信状況により前記通信装置との通信セッションを維持することを制限し、前記第２の時刻以後は前記第２の通信プロトコルの通信状況により前記通信装置との通信セッションを維持する制御を行うことを特徴とする請求項１０に記載の通信制御方法。
コンピュータを、請求項１乃至９のうち何れか１項に記載の通信制御装置の各手段として動作させるためのプログラム。