(57)【要約】【課題】  複数の通信手順を用いて通信セッションを管理する場合、サーバが認証しないクライアントとの通信セッションが確立され又は継続されてしまう場合がある。【解決手段】  通信装置との通信セッションを維持するために前記通信装置の認証を行う第１の通信手順、及び、前記通信装置と通信するために前記通信装置の認証を必要としない第２の通信手順を用いて前記通信装置との通信を行う通信手段と、  前記通信装置との通信セッションを維持するかを決定する制御を前記第１の通信手順及び前記第２の通信手順を用いて行い、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されない場合には、前記第２の通信手順により前記通信装置との通信セッションを維持することを制限する制御を行う制御手段と  を有することを特徴とする通信制御装置。【選択図】  図４
2015104076.tif 000002
【特許請求の範囲】
【請求項１】
通信装置との通信セッションを維持するために前記通信装置の認証を行う第１の通信手順、及び、前記通信装置と通信するために前記通信装置の認証を必要としない第２の通信手順を用いて前記通信装置との通信を行う通信手段と、
前記通信装置との通信セッションを維持するかを決定する制御を前記第１の通信手順及び前記第２の通信手順を用いて行い、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されない場合には、前記第２の通信手順により前記通信装置との通信セッションを維持することを制限する制御を行う制御手段と
を有することを特徴とする通信制御装置。
【請求項２】
前記通信手段は、前記通信装置から第１のデータ及び前記第１のデータよりも後に受信される第２のデータを前記第１の通信手順を用いて受信し、
前記制御手段は、前記第１のデータが受信されてから第１の所定時間が経過するまでに前記第２のデータを受信し、かつ、前記第２のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記通信装置との通信セッションを維持するように制御する
ことを特徴とする請求項１に記載の通信制御装置。
【請求項３】
前記通信装置から第１のデータを前記第１の通信手順を用いて受信し、かつ、前記第１のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記第１のデータを受信した時刻を保持し、前記通信装置から第１のデータを前記第１の通信手順を用いて受信し、かつ、前記通信装置が所定の通信装置であると認証されない場合には、前記第１のデータを受信した時刻を保持しない保持手段を有し、
前記制御手段は、前記保持手段に保持された時刻から所定時間が経過するまでに第２のデータを前記第１の通信手順を用いて受信し、かつ、前記第２のデータを送信した前記通信装置が前記所定の通信装置であると認証された場合には、前記通信装置との通信セッションを維持するように制御する
ことを特徴とする請求項１に記載の通信制御装置。
【請求項４】
前記第１の通信手順により前記通信装置が所定の通信装置であると認証された状態で前記通信装置から第３のデータを前記第２の通信手順を用いて受信した場合には、前記第３のデータを受信した時刻を保持し、前記通信装置から第３のデータを前記第２の通信手順を用いて受信し、かつ、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されていない状態である場合には、前記第３のデータを受信した時刻を保持しない保持手段を有し、
前記制御手段は、前記保持手段に保持された時刻から所定時間が経過するまでに第４のデータを前記第２の通信手順を用いて受信した場合には、前記通信装置との通信セッションを維持するように制御する
ことを特徴とする請求項１に記載の通信制御装置。
【請求項５】
前記制御手段は、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されなかった第１の時刻から前記第１の通信手順により前記通信装置が所定の通信装置であると認証された第２の時刻までの期間には前記第２の通信手順により前記通信装置との通信セッションを維持することを制限し、前記第２の時刻以後は前記第２の通信手順により前記通信装置との通信セッションを維持することを許可する制御を行う
ことを特徴とする請求項１に記載の通信制御装置。
【請求項６】
通信装置との通信セッションを維持するために前記通信装置の認証を行う第１の通信手順、及び、前記通信装置と通信するために前記通信装置の認証を必要としない第２の通信手順を用いて前記通信装置との通信を行う通信ステップと、
前記通信装置との通信セッションを維持するかを決定する制御を前記第１の通信手順及び前記第２の通信手順を用いて行い、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されない場合には、前記第２の通信手順により前記通信装置との通信セッションを維持することを制限する制御を行う制御ステップと
を有することを特徴とする通信制御方法。
【請求項７】
前記通信ステップにおいて、前記通信装置から第１のデータ及び前記第１のデータよりも後に受信される第２のデータを前記第１の通信手順を用いて受信し、
前記制御ステップにおいて、前記第１のデータが受信されてから第１の所定時間が経過するまでに前記第２のデータを受信し、かつ、前記第２のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記通信装置との通信セッションを維持するように制御することを特徴とする請求項６に記載の通信制御方法。
【請求項８】
前記通信装置から第１のデータを前記第１の通信手順を用いて受信し、かつ、前記第１のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記第１のデータを受信した時刻を保持手段に保持し、前記通信装置から第１のデータを前記第１の通信手順を用いて受信し、かつ、前記通信装置が所定の通信装置であると認証されない場合には、前記第１のデータを受信した時刻を前記保持手段に保持しない保持ステップを有し、
前記制御ステップにおいて、前記第２のデータを送信した前記通信装置が前記所定の通信装置であると認証され、かつ、前記保持手段に保持された時刻から所定時間が経過するまでに第２のデータを前記第１の通信手順を用いて受信した場合には、前記通信装置との通信セッションを維持するように制御する
ことを特徴とする請求項６に記載の通信制御方法。
【請求項９】
前記第１の通信手順により前記通信装置が所定の通信装置であると認証された状態で前記通信装置から第３のデータを前記第２の通信手順を用いて受信した場合には、前記第３のデータを受信した時刻を保持手段に保持し、前記通信装置から第３のデータを前記第２の通信手順を用いて受信し、かつ、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されていない状態である場合には、前記第３のデータを受信した時刻を前記保持手段に保持しない保持ステップを有し、
前記制御ステップにおいて、前記保持手段に保持された時刻から所定時間が経過するまでに第４のデータを前記第２の通信手順を用いて受信した場合には、前記通信装置との通信セッションを維持するように制御する
ことを特徴とする請求項６に記載の通信制御方法。
【請求項１０】
前記制御ステップにおいて、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されなかった第１の時刻から前記第１の通信手順により前記通信装置が所定の通信装置であると認証された第２の時刻までの期間には前記第２の通信手順により前記通信装置との通信セッションを維持することを制限し、前記第２の時刻以後は前記第２の通信手順により前記通信装置との通信セッションを維持することを許可する制御を行う
ことを特徴とする請求項６に記載の通信制御方法。
【請求項１１】
コンピュータを、
通信装置との通信セッションを維持するために前記通信装置の認証を行う第１の通信手順、及び、前記通信装置と通信するために前記通信装置の認証を必要としない第２の通信手順を用いて前記通信装置との通信を行う通信手段と、
前記通信装置との通信セッションを維持するかを決定する制御を前記第１の通信手順及び前記第２の通信手順を用いて行い、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されない場合には、前記第２の通信手順により前記通信装置との通信セッションを維持することを制限する制御を行う制御手段として機能させるためのプログラム。
【請求項１２】
前記通信手段は、前記通信装置から第１のデータ及び前記第１のデータよりも後に受信される第２のデータを前記第１の通信手順を用いて受信し、
前記制御手段は、前記第１のデータが受信されてから第１の所定時間が経過するまでに前記第２のデータを受信し、かつ、前記第２のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記通信装置との通信セッションを維持するように制御するように前記コンピュータを機能させるための請求項１１に記載のプログラム。
【請求項１３】
前記コンピュータを、
前記通信装置から第１のデータを前記第１の通信手順を用いて受信し、かつ、前記第１のデータを送信した前記通信装置が所定の通信装置であると認証された場合には、前記第１のデータを受信した時刻を保持し、前記通信装置から第１のデータを前記第１の通信手順を用いて受信し、かつ、前記通信装置が所定の通信装置であると認証されない場合には、前記第１のデータを受信した時刻を保持しない保持手段として機能させ、
前記制御手段は、前記保持手段に保持された時刻から所定時間が経過するまでに第２のデータを前記第１の通信手順を用いて受信し、かつ、前記第２のデータを送信した前記通信装置が前記所定の通信装置であると認証された場合には、前記通信装置との通信セッションを維持するように制御するように前記コンピュータを機能させるための請求項１１に記載のプログラム。
【請求項１４】
前記コンピュータを、
前記第１の通信手順により前記通信装置が所定の通信装置であると認証された状態で前記通信装置から第３のデータを前記第２の通信手順を用いて受信した場合には、前記第３のデータを受信した時刻を保持手段に保持し、前記通信装置から第３のデータを前記第２の通信手順を用いて受信し、かつ、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されていない状態である場合には、前記第３のデータを受信した時刻を保持しない保持手段として機能させ、
前記制御手段は、前記保持手段に保持された時刻から所定時間が経過するまでに第４のデータを前記第２の通信手順を用いて受信した場合には、前記通信装置との通信セッションを維持するように制御するように前記コンピュータを機能させるための請求項１１に記載のプログラム。
【請求項１５】
前記制御手段は、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されなかった第１の時刻から前記第１の通信手順により前記通信装置が所定の通信装置であると認証された第２の時刻までの期間には前記第２の通信手順により前記通信装置との通信セッションを維持することを制限し、前記第２の時刻以後は前記第２の通信手順により前記通信装置との通信セッションを維持することを許可する制御を行うように前記コンピュータを機能させるための請求項１１に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークで接続された複数の装置間での通信セッションの制御に関する。
【背景技術】
【０００２】
近年、動画像や音声などのマルチメディアデータをＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）と呼ばれる通信プロトコルを用いてストリーミング配信し、視聴する技術が広く実用化されている。
【０００３】
ＲＴＰは、主に音声や動画像などをリアルタイムでデータ転送するためのプロトコルであり、ＩＥＴＦによりＲＦＣ３５５０として定義されている。
【０００４】
ＲＴＰは、非コネクション型のプロトコルであるＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ    Ｐｒｏｔｏｃｏｌ）の上位プロトコルである。ＲＴＰを用いて動画像や音声のデータをパケット化して通信する場合、一般にネットワークに流れるＲＴＰパケットのことをストリームデータ、或いはメディアストリームなどと呼ぶ。
【０００５】
このＲＴＰを用いたメディアストリームの開始や終了などの制御を行うためのプロトコルとして、一般にＲＴＳＰ（ＲｅａｌＴｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）が知られている。ＲＴＳＰは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によりＲＦＣ２３２６として定義されている。
【０００６】
ＲＴＳＰで制御する通信セッションは、ストリームデータを受信するクライアントから送信元のサーバに対して、所定の時間メッセージの送信が無かった場合、通信セッションがタイムアウトしたとして、サーバがセッションを切断する場合がある。
【０００７】
通信セッションを継続したい場合、クライアントは所定の時間が経過する前に、メッセージを送信することにより通信セッションを継続することができる。この通信セッションを継続する仕組みはキープ・アライブとも呼ばれる。
【０００８】
ＲＴＳＰでは、通信セッションを開始する際に、通信セッションがタイムアウトする時間をサーバからクライアントに通知する。クライアントは、通知されたタイムアウト時間が経過する前に、任意のＲＴＳＰコマンドをサーバに送信することにより通信セッションを継続することができる。
【０００９】
また従来、通信セッションを継続する手段として、ＲＴＳＰに加えて、ＲＴＣＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルを利用する通信システムが知られている（例えば、特許文献１）
ＲＴＣＰは、ＲＴＰと組み合わせて使用される。ＲＴＣＰはデータのフロー制御や送信者と受信者間の情報を伝達するためのプロトコルで、ＩＥＴＦによってＲＦＣ３５５０で定義されている。
【００１０】
ＲＴＣＰでは、通信の状況をクライアント側からサーバ側に通知するためにＲｅｃｅｉｖｅｒ  Ｒｅｐｏｒｔ（以降、ＲＲと記述する）と呼ばれる種類のパケットが使用される。
【００１１】
従来、このＲＲをクライアントからサーバに定期的に通知することによって、サーバに通信セッションを継続させる方法が知られている。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特表２００５−５２６２９４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、複数の通信手順（通信プロトコル）を用いて通信セッションを管理する場合、サーバが認証しないクライアントとの通信セッションが確立され又は継続されてしまう場合がある。
【００１４】
例えば、クライアントの認証を行う機能をサポートする第１のプロトコルと、クライアントの認証を行う機能をサポートしない第２のプロトコルとを併用する場合に以下の課題が生じる。すなわち、サーバが認証しないクライアントとの通信セッションが確立され又は継続されてしまう場合がある。
【００１５】
例えば、ＲＴＳＰは、サーバとクライアント間で通信セッションを確立又は維持する際に、サーバがクライアントの認証を行う機能をサポートしている。
【００１６】
一方、ＲＴＣＰでは、サーバがクライアントの認証を行う機能をサポートしていない。従って、上述の従来例のように、クライアントからサーバにＲＲを定期的に通知することによって通信セッションを継続させる場合に、クライアントの認証を必要としない。
【００１７】
従って、ＲＴＳＰを用いた通信においてクライアントの認証を行った結果、サーバがクライアントと通信セッションを継続しないと判断したにもかかわらず、ＲＴＣＰによる通信によって、当該クライアントとの通信が継続してしまう場合がある。
【００１８】
このように、サーバとクライアント間でのセキュアな通信が行われなくなってしまう場合がある。
【００１９】
本発明は、このような課題を鑑みて、よりセキュアな通信セッションの制御を実現することを目的とする。
【課題を解決するための手段】
【００２０】
本発明の目的を達成するために、例えば本発明にかかる通信制御装置は以下の構成を備える。
【００２１】
すなわち、通信装置との通信セッションを維持するために前記通信装置の認証を行う第１の通信手順、及び、前記通信装置と通信するために前記通信装置の認証を必要としない第２の通信手順を用いて前記通信装置との通信を行う通信手段と、前記通信装置との通信セッションを維持するかを決定する制御を前記第１の通信手順及び前記第２の通信手順を用いて行い、前記第１の通信手順により前記通信装置が所定の通信装置であると認証されない場合には、前記第２の通信手順により前記通信装置との通信セッションを維持することを制限する制御を行う制御手段とを有する。
【発明の効果】
【００２２】
以上の構成からなる本発明によれば、よりセキュアな通信セッションの制御を実現することができる。
【図面の簡単な説明】
【００２３】
【図１】サーバ１００の構成を示す図。
【図２】サーバ１００における通信セッションのタイムアウト時間を記憶する処理の一例を示すフローチャート。
【図３】サーバ１００における通信セッションを継続するか切断するか判定処理の一例を示すフローチャート。
【図４】実施形態１にかかるサーバ１００における通信セッション制御の一例を示すシーケンス図。
【図５】実施形態２にかかるサーバ１００における通信セッション制御の一例を示すシーケンス図である。
【図６】サーバ１００において、ＲＴＳＰ認証失敗後に再び認証が成功した場合の処理の一例を示すシーケンス図。
【発明を実施するための形態】
【００２４】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００２５】
＜実施形態１＞
本発明の一実施形態である通信制御装置の例を図１に示す。図１は、本発明の第１の実施形態におけるサーバ１００（通信制御装置）の構成例を示すブロック図である。
【００２６】
サーバ１００は例えば、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）やタブレット端末等のクライアントに対して映像データを送信する送信装置とすることができる。あるいはサーバ１００は、撮像を行う撮像部を有するネットワークカメラとしてもよい。ネットワークカメラにサーバ１００の機能を搭載する場合、撮像部において撮像された映像データをＰＣやタブレット端末等のクライアントに送信してもよい。
【００２７】
図１において、サーバ１００は、生成部１０１、制御部１０２、管理部１０３、保持部１０４、通信部１０５を有する。
【００２８】
伝送路１０６は、いわゆる３Ｇや４Ｇ等の携帯電話方式の通信サービスや、インターネット、或いはＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワークである。
【００２９】
通信部１０５はデータを送受信する機能を備え、伝送路１０６と通信可能な様に接続される。尚、通信手段は無線でも有線でも良い。
【００３０】
通信部１０５は、通信装置（以下、「クライアント」という）との通信セッションを維持するためにクライアントの認証を行う第１の通信手順を用いてクライアントとの通信セッションを構築することができる。また通信部１０５は、クライアントと通信するためにクライアントの認証を必要としない第２の通信手順を用いてクライアントとの通信を行うことができる。
【００３１】
本実施例では、通信部１０５はＲＴＳＰ（第１の通信手順）によって、クライアントとの通信を行うことができるものとする。また本実施例において通信部１０５はＲＴＣＰ（第２の通信手順）によって、クライアントとの通信を行うことができるものとする。
【００３２】
ここで、ＲＴＳＰを用いた通信においては、サーバ１００とクライアントとの間に通信セッションが構築される。クライアントはＲＴＳＰ（第１の通信手順）により規定された手順を用いて、サーバ１００から送信される映像の再生、一時停止、停止等の操作をサーバ１００に対して行うことができる。例えば、サーバ１００がネットワークカメラである場合、クライアントはネットワークカメラが撮像した映像の送信の一時停止、再開、停止等をＲＴＳＰに規定された手順を用いて行うことができる。
【００３３】
本実施例において、通信セッションとは、第１の通信手順を用いてサーバ１００の映像送信を制御するために用いられるセッションである。本実施例では、通信セッションを切断すると、サーバ１００からクライアントへの映像ストリーミングも終了されるものとする。あるいは、第１の通信手順を用いてサーバ１００の映像送信を制御するために用いられる通信セッションが切断された場合でも、映像ストリーミングは継続されることとしてもよい。
【００３４】
ＲＴＳＰを用いた通信においては、サーバとクライアント間で通信セッションを確立及び維持する際に、サーバ１００がクライアントの認証を行うことができる。
【００３５】
ＲＴＳＰを用いた通信において、サーバ１００はクライアントから第１のデータ（例えば、第１のＲＴＳＰコマンド）を受信した後に、第２のデータ（例えば、第２のＲＴＳＰコマンド）を受信する。第１のＲＴＳＰコマンド及び第２のＲＴＳＰコマンドは、例えば、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドとすることができる。
【００３６】
サーバ１００は、第１のデータが受信されてから第１の所定時間が経過するまでに第２のデータを受信し、かつ、第２のデータを送信したクライアントが所定のクライアントであると認証された場合には、クライアントとの通信セッションを維持する。第１の所定時間はタイムアウト時間である。
【００３７】
また、ＲＴＣＰを用いた通信においては、サーバ１００とクライアントとの間に通信セッションは構築されない。本実施例において、ＲＴＣＰの通信手順が、構築された通信セッションを維持するために用いられる場合について説明する。クライアントは、ＲＴＣＰにより規定された手順を用いて、サーバ１００から送信されたデータの受信状況をＲＲに記載してサーバ１００に通知する。ＲＲには例えば、パケットロスト数や、パケット到達時間のジッター等についての情報が記載される。
【００３８】
本実施例にかかるサーバ１００は、ＲＴＳＰを用いて構築された通信セッションのタイムアウト時間を、ＲＲを受信する度に更新する。
【００３９】
例えば、ＲＴＣＰを用いた通信において、サーバ１００はクライアントから第３のデータ（例えば、ＲＴＣＰの第１のＲＲ）を受信した後に、第４のデータ（例えば、ＲＴＣＰの第２のＲＲ）を受信する。
【００４０】
ＲＴＣＰを用いた通信において、サーバ１００は、第３のデータが受信されてから第２の所定時間が経過するまでに第４のデータを受信した場合には、ＲＴＳＰの通信手順によって構築された通信セッションを維持する。
【００４１】
本実施例にかかるサーバ１００は、ＲＴＳＰを用いて構築した通信セッションを維持するか否かを、ＲＴＳＰコマンドの受信及びＲＲの受信によって判断する。従って、クライアント装置がＲＴＳＰコマンド又はＲＲの一方のみを用いて、通信セッションを維持するか否かを決定する場合であっても、本発明のサーバ１００によれば適切にセッションの維持を行うことができる。
【００４２】
生成部１０１は、例えばＲＴＰプロトコルを用いる場合、外部から入力された動画像や音声の符号化されたデータを、通信に適したサイズに分割し、更にメディアの種類毎に適切なヘッダを付加してＲＴＰのデータパケットを生成する。
【００４３】
制御部１０２は、サーバ１００の各構成を制御する。制御部１０２は、クライアントとの通信セッションの作成や切断に関する指示を行う。また、制御部１０２はサーバ１００からクライアントに送信するデータのフロー制御を行う。
【００４４】
本実施形態において、制御部１０２は通信装置との通信セッションを維持するかを決定する制御を第１の通信手順（例えば、ＲＴＳＰ）及び前記第２の通信手順（例えば、ＲＴＣＰ）を用いて行う。また、制御部１０２は、第１の通信手順によりクライアントが所定のクライアントであると認証されない場合には、以下の制御を行う。すなわち、第２の通信手順によりクライアントとの通信セッションを維持することを制限する制御を行う。
【００４５】
制御部１０２は例えば、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などのプロセッサとすることができる。制御部１０２がプロセッサとして構成される場合、例えば制御部１０２は、後述の保持部１０４に記憶されたプログラムを実行することにより、サーバ１００の各構成を制御する。
【００４６】
管理部１０３は、通信セッションが作成されたクライアントからサーバ１００に送信されるデータの内容及び当該データが受信された時刻を後述の保持部１０４に保持させる。管理部１０３は、クライアントから送信されたデータとともに、当該データが送信された時刻を保持部１０４に保持させることとしてもよい。また管理部１０３は、保持部１０４に記憶させた情報に基づいて、クライアントとの通信セッションの維持に関する情報の管理を行う。
【００４７】
保持部１０４は、クライアントから受信したデータの内容を保持する。また保持部１０４は、サーバ１００がクライアントからデータを受信された時刻、又は、クライアントからデータが送信された時刻の情報を保持する。本実施例において、保持部１０４に保持される時刻は、通信セッションのタイムアウト時間の計測が開始される時刻である。たとえば、タイムアウト時間が６０秒である場合、保持部１０４に保持された時刻から６０秒が経過すると、サーバ１００はクライアントとの通信セッションを切断する。
【００４８】
次に、本実施形態のサーバ１００による通信セッション制御の詳細について、図２及び図３を用いて説明する。図２及び図３は、本実施形態のサーバ１００における通信セッション制御の一例を示すフローチャートである。
【００４９】
サーバ１００の制御部１０２がプロセッサ及びメモリを内蔵する形態では、図２及び図３に示した処理は、図２及び図３に示される手順を制御部１０２が保持部１０４に格納されたプログラムをメモリに展開して実行することにより実現される。サーバ１００は、各手順を実行することにより、各手順を実現する各構成として機能する。あるいは、図２及び図３に示す処理の一部又は全体をハードウェアが行うこととしてもよい。
【００５０】
クライアントからパケットを受信した際に、サーバ１００がパケットの最終受信時間を記憶する処理の例について、図２を用いて説明する。
【００５１】
図２において、まず制御部１０２は、通信部１０５が受信したパケットの種別を判定する（Ｓ２０１）。パケットがＲＴＳＰコマンドであった場合は、ステップＳ２０２へ進み、ＲＴＣＰのＲＲであった場合はステップＳ２０５へ進む。
【００５２】
ここで、ＲＴＳＰコマンドとは、ＲＴＳＰを用いた通信において、クライアントからサーバ１００に送信されるコマンドである。
【００５３】
また、ＲＴＣＰのＲＲとは、ＲＴＣＰを用いた通信において、クライアントからサーバに送られるパケットである。サーバから通知されたセッションのタイムアウト時間が経過する前にクライアントがＲＲをサーバに通知することによって、クライアントはサーバに通信セッションを継続させることができる。
【００５４】
ステップＳ２０１において制御部１０２が行う判定は上記の例に限られず、通信部１０５において受信したデータが、クライアントの認証を行う通信手順を用いて送信されたデータであるか否かを判定することとすればよい。
【００５５】
通信部１０５が受信したパケットがＲＴＳＰコマンドであった場合（Ｓ２０１においてＲＴＳＰの場合）、制御部１０２はＲＴＳＰの認証機能が有効であるか判定する（Ｓ２０２）。ここで、ＲＴＳＰの認証機能とは、ＲＴＳＰを用いた通信手順において、サーバ１００にアクセスを行ったクライアントが、サーバ１００との通信セッションを構築することを許可するクライアントであるか判定する機能である。認証の方式として、例えば、ＤＩＧＥＳＴ認証やＢＡＳＩＣ認証を用いることができる。ＲＴＳＰの認証機能が有効であるか、無効であるかの設定は保持部１０４に保持されているものする。クライアントがサーバ１００に指示して、認証機能の有効又は無効を切り替えられることとしてもよい。
【００５６】
ＲＴＳＰの認証モードが有効である場合（Ｓ２０２においてＹｅｓの場合）、制御部１０２はＲＴＳＰ認証を実行して、クライアントがサーバ１００との通信セッションを構築することを許可するクライアントであるか判定する（Ｓ２０３）。ステップＳ２０３においてクライアントが認証された場合（Ｓ２０３においてＯＫの場合）、制御部１０２はステップＳ２０４の処理を行う。一方、ステップＳ２０３においてクライアントが認証されなかった場合（Ｓ２０３においてエラーの場合）、制御部１０２は処理を終了する。
【００５７】
ステップＳ２０３において、クライアントが所定のクライアントであると認証されなかった場合、サーバ１００はＲＴＳＰによる認証が失敗した状態であることを保持部１０４に保持する。あるいは、サーバ１００はＲＴＳＰによる認証が成功した状態であることを保持部１０４に保持することとしてもよい。
【００５８】
また、ステップＳ２０２においてＲＴＳＰ認証モードが無効である場合（Ｎｏの場合）は、制御部１０２は、ＲＴＳＰ認証を行わずにステップＳ２０４の処理を行う。
【００５９】
ステップＳ２０４では、制御部１０２は管理部１０３を制御して、通信セッション毎に、最後にＲＴＳＰコマンドを受信した時刻（最終受信時間）を保持部１０４に保持させて処理を終了する。保持部１０４に保持されたＲＴＳＰコマンドの受信時刻から所定のタイムアウト時間（例えば、６０秒）がカウントされる。当該タイムアウト時間以内に新たなＲＴＳＰコマンドが受信され、かつ、ＲＴＳＰによるクライアントの認証に成功した場合には、サーバ１００は通信セッションを維持すると判定する。
【００６０】
一方、ステップＳ２０１において、受信したパケットの種類がＲＴＣＰのＲＲであると判定した場合、制御部１０２はステップＳ２０５の処理を行う。
【００６１】
通信部１０５が受信したパケットがＲＴＣＰコマンドであった場合（Ｓ２０１においてＲＴＣＰのＲＲの場合）、ステップＳ２０５において制御部１０２は、その時点で当該通信セッションがＲＴＳＰ認証に失敗した状態か否かのチェックを行う。ＲＴＳＰ認証が失敗した状態の場合（ステップＳ２０５においてＹｅｓの場合）、制御部１０２は処理を終了する。ＰＴＳＰ認証が失敗した状態であることは保持部１０４に保持されている。
【００６２】
一方、ＲＴＳＰ認証に成功した状態か、或いはＲＴＳＰ認証が無効である場合（ステップＳ２０５においてＮｏの場合）、制御部１０２はステップＳ２０６の処理を行う。ＰＴＳＰ認証が成功した状態であること、ＲＴＳＰ認証が無効であることは保持部１０４に保持されている。
【００６３】
ステップＳ２０６では、制御部１０２は管理部１０３を制御して、通信セッション毎に、最後にＲＴＣＰのＲＲを受信した時刻（最終受信時間）を保持部１０４に保持させる。保持部１０４に保持されたＲＲの受信時刻から所定のタイムアウト時間（例えば、６０秒）がカウントされ、当該タイムアウト時間以内に新たなＲＲが受信された場合には、サーバ１００は通信セッションを維持すると判定する。
【００６４】
以上のとおり、図２に示したフローによれば、以下の処理を行うことができる。
【００６５】
即ち、クライアントから第１のデータ（ＲＴＳＰコマンド）を第１の通信手順（ＲＴＳＰ）を用いて受信した場合を第１の場合とする（Ｓ２０１でＲＴＳＰの場合）。また、第１のデータを送信したクライアントが所定の通信装置であると認証された場合を第２の場合とする（Ｓ２０３でＹｅｓの場合）。第１の場合であって、かつ、第２の場合、第１のデータを受信した時刻を保持部１０４に保持する。
【００６６】
また、クライアントから第１のデータを第１の通信手順を用いて受信し、かつ、クライアントが所定の通信装置であると認証されない場合には、第１のデータを受信した時刻を保持部１０４に保持しない。（Ｓ２０１でＲＴＳＰ、Ｓ２０３でエラーの場合）。
【００６７】
ＲＴＳＰコマンド（第１のデータ）を受信した時刻が保持部１０４に保持されない場合、新たなＲＴＳＰコマンドを受信しても、タイムアウト時間の計測を開始する時刻が更新されない。従って、セッションタイムアウトにより、クライアントとの通信セッションが維持されなくなる。
【００６８】
また図２に示したフローによれば、以下の処理を行うことができる。
【００６９】
すなわち、クライアントから第３のデータ（ＲＲ）を第２の通信手順（ＲＴＣＰ）を用いて受信した場合を第３の場合とする（Ｓ２０１でＲＴＣＰ  ＲＲの場合）。また、第１の通信手順によりクライアントが所定のクライアントであると認証された状態である場合を第４の場合とする（Ｓ２０５でＮｏの場合）。第３の場合であって、かつ、第４の場合、第３のデータを受信した時刻を保持部１０４に保持する。
【００７０】
またクライアントから第３のデータを第２の通信手順を用いて受信し、かつ、第１の通信手順によりクライアントが所定のクライアントであると認証されていない状態である場合には、第３のデータを受信した時刻を保持部１０４に保持しない。（Ｓ２０１でＲＴＣＰ  ＲＲ、Ｓ２０５でＹｅｓの場合）。
【００７１】
ＲＲ（第３のデータ）を受信した時刻が保持部１０４に保持されない場合、新たなＲＲを受信しても、タイムアウト時間の計測を開始する時刻が更新されないので、セッションタイムアウトにより、クライアントとの通信が維持されなくなる。
【００７２】
図２を用いて説明した処理は、通信セッション毎に通信部１０５がクライアントから送信されたパケットを受信する度に実行される。ステップＳ２０４及びステップＳ２０６においては、図２を用いて説明した処理が繰り返される度に、保持部１０４に保持した時間が更新される。
【００７３】
次に、図２を用いて説明した処理によって記憶されたパケットの最終受信時間と通信セッションのタイムアウト時間を基に、当該通信セッションを継続するか切断するか判定する処理の例について図３を用いて説明する。制御部１０２は、定期的に（例えば、１秒おきに）図３の処理を実行する。
【００７４】
まず制御部１０２は、保持部１０４から、最後にＲＴＳＰコマンドを受信した時刻と、最後にＲＴＣＰのＲＲを受信した時刻を取得する（Ｓ３０１）。
【００７５】
次に制御部１０２は、最後にＲＴＳＰコマンドを受信した時刻から現在の時刻までの経過時間と、当該通信セッションのタイムアウト時間とを比較して、ＲＴＳＰを用いて構築された通信セッションをタイムアウトとするか確認する（Ｓ３０２）。
【００７６】
最後にＲＴＳＰコマンドを受信した時刻から現在の時刻までの経過時間が、ＲＴＳＰを用いた通信におけるタイムアウト時間を経過していなかった場合（Ｓ３０２においてＮｏの場合）は、制御部１０２はステップＳ３０３の処理を実行する。すなわち、クライアントとの通信セッションを継続する（Ｓ３０３）。
【００７７】
最後にＲＴＳＰコマンドを受信した時刻から現在の時刻までの経過時間が、ＲＴＳＰを用いた通信におけるタイムアウト時間を経過している場合（Ｓ３０２においてＹｅｓの場合）は、制御部１０２はステップＳ３０４の処理を実行する。
【００７８】
ステップＳ３０４において、制御部１０２は、当該通信セッションがＲＴＳＰ認証に失敗した状態か否かのチェックを行う。ＲＴＳＰ認証が失敗した状態であった場合（Ｓ３０４においてＹｅｓの場合）、制御部１０２はステップＳ３０６へ進み、クライアントとの通信セッションを切断する制御を行う。ステップＳ３０６において制御部１０２は、クライアントとの通信セッションを切断する。
【００７９】
ステップＳ３０４においてＲＴＳＰ認証に成功した状態である場合、及び、ＲＴＳＰ認証が無効である場合（Ｓ３０４においてＮｏの場合）には、制御部１０２はステップＳ３０５へ進む。
【００８０】
ステップＳ３０５において制御部１０２は、ＲＴＣＰのＲＲを最後に受信した時刻から現在の時刻までの経過時間と、ＲＴＣＰを用いた通信セッションのタイムアウト時間とを比較することで、当該通信セッションをタイムアウトとするか確認する。
【００８１】
ＲＴＣＰのＲＲを最後に受信した時刻から現在の時刻までの経過時間が、タイムアウト時間を経過していない場合（ステップＳ３０５においてＮｏの場合）は、制御部１０２はステップＳ３０３の処理を実行する。すなわち、制御部１０２はクライアントとの通信セッションを継続する（Ｓ３０３）。
【００８２】
ＲＴＣＰのＲＲを最後に受信した時刻から現在の時刻までの経過時間が、タイムアウト時間を経過していた場合（Ｓ３０５においてＹｅｓの場合）は、制御部１０２はステップＳ３０６の処理を実行する。すなわち制御部１０２は、クライアントとの通信セッションを切断する（Ｓ３０６）。
【００８３】
以上のとおり、図３に示したフローによれば、以下の処理を行うことができる。
【００８４】
すなわち、第２のデータ（ＲＴＳＰコマンド）を送信したクライアントが所定のクライアントであると認証された場合を第５の場合とする（Ｓ２０３においてＹｅｓの場合）。また、保持部１０４に保持された時刻から所定時間が経過するまでに第２のデータを第１の通信手順（ＲＴＳＰ）を用いて受信した場合を第６の場合とする（Ｓ３０２においてＮｏの場合）。第５の場合であってかつ第６の場合には、クライアントとの通信セッションを維持するように制御する（Ｓ３０３）。
【００８５】
また、図３に示したフローによれば、以下の処理を行うことができる。
【００８６】
すなわち、保持部１０４に保持された時刻から所定時間が経過するまでに第４のデータ（ＲＲ）を第２の通信手順（ＲＴＣＰ）を用いて受信した場合には、クライアント装置との通信セッションを維持するように制御する（Ｓ３０５でＮｏ）。
【００８７】
図３の処理は、例えば１秒から数秒おきに繰り返し実行し、通信セッションを適時タイムアウトさせることで、セキュアな通信セッションの維持を可能にする。
【００８８】
次に、図２及び図３を用いて説明した処理の流れの一例について、図４及び図５に示したシーケンス図を用いて説明する。図４は、本発明の一実施形態であるサーバにおける通信セッション制御の一例を示すシーケンス図である。
【００８９】
サーバ１００がＲＴＳＰ及びＲＴＣＰを用いてクライアントとの通信セッションを制御する例について、図４を用いて説明する。
【００９０】
図４に示した例において、サーバ１００は、ＲＴＳＰを用いた通信におけるタイムアウト時間が経過する前にＲＴＳＰコマンドの１つであるＧＥＴ＿ＰＡＲＡＭＥＴＥＲをクライアントから受信すると、クライアントの通信セッションを継続する。
【００９１】
また図４に示した例においてサーバ１００は、ＲＴＣＰを用いた通信におけるタイムアウト時間が経過する前にＲＲをクライアントから受信すると通信セッションを継続する。
【００９２】
本実施例では、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲを受信してから通信セッションがタイムアウトするまでの時間が６０秒である場合について説明する。また、ＲＲを受信してから通信セッションがタイムアウトするまでの時間が６０秒である場合について説明する。
【００９３】
図４において、時刻４０３は、サーバ１００がクライアントから第１のＲＴＳＰコマンド（第１のＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信した時刻４００からタイムアウト時間である６０秒が経過する時刻を示す。
【００９４】
サーバ１００は、時刻４０３が経過する以前に第２のＲＴＳＰコマンドを受信し、かつ、当該ＲＴＳＰコマンドを送信したクライアントがサーバ１００に認証された場合には、当該クライアントとの通信セッションを継続する。
【００９５】
一方、第１のＲＴＳＰコマンドを受信した後、時刻４０３が経過する以前に第２のＲＴＳＰコマンド（第２のＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信せず、ＲＲ受信によるセッション維持もなされない場合、クライアントとの通信セッションを切断する。また、時刻４０３が経過する以前に第２のＲＴＳＰコマンドを受信した場合であっても、当該ＲＴＳＰコマンドを送信したクライアントがサーバ１００に認証されない場合には、通信セッションを切断する。
【００９６】
タイムアウト時間は６０秒に限られない。また、ＲＴＳＰを用いた通信におけるタイムアウト時間と、ＲＴＣＰを用いた通信におけるタイムアウト時間は必ずしも同じ長さでなくともよい。
【００９７】
時刻４０４は、サーバ１００がＲＴＣＰの第１のＲＲを受信してからタイムアウト時間である６０秒が経過する時刻を示す。また時刻４０５は、サーバ１００がクライアントから第２のＲＲを受信してからタイムアウト時間である６０秒が経過する時刻を示す。
【００９８】
サーバ１００は、第１のＲＲを受信した後、時刻４０４が経過する前に第２のＲＲを受信した場合にはクライアントとの通信セッションを継続する。
【００９９】
一方、サーバ１００は時刻４０４が経過する前に第２のＲＲを受信せず、ＲＴＳＰコマンドによるセッション維持もなされない場合には、クライアントとの通信セッションを切断する。時刻４０５についても時刻４０４と同様にして、クライアントとの通信セッションを継続するか否かを判定する。
【０１００】
時刻４０１は、第１のＲＴＳＰコマンドを受信した時刻４００と第２のＲＴＳＰコマンドの受信した時刻との間において、クライアントがＲＴＳＰ認証モードの変更やパスワードの変更などの設定変更を行った時刻を表す。
【０１０１】
図４に示した時刻４０１において、例えば、サーバ１００においてＲＴＳＰ認証モードの変更やパスワードの変更などがあった場合、第２のＲＴＳＰコマンドを送信したクライアントがＲＴＳＰの認証に失敗することがある。この場合、サーバ１００がクライアントを認証しないことを示すエラーコード４０２（Ｕｎａｕｔｈｏｒｉｚｅｄ）をクライアントに返す。
【０１０２】
ＲＴＳＰを用いた通信においてクライアントが認証されなかった場合（認証エラーの場合）、サーバ１００は、第２のＲＴＳＰコマンドの受信後、ＲＴＣＰのＲＲを受信してもクライアントとの通信セッションを継続しないようにする。
【０１０３】
例えば、クライアントからＲＲを受信することによる通信セッションの継続を無効にする。すなわち、時刻４０５のタイムアウト時刻は無効となる。
【０１０４】
図４の例では、クライアントが認証されないまま時刻４０３を経過した場合、保持部１０４に保持されているＲＲの最終受信時刻（第２のＲＲの受信時刻）から６０秒が経過する前に第３のＲＲを受信したとしても、通信セッションを維持させない。
【０１０５】
そして、第１のＲＴＳＰコマンド（ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信した時刻からタイムアウト時間である６０秒が経過する時刻４０３を、クライアントとの通信セッションのタイムアウト時刻とする。図４の例において、第１のＲＴＳＰコマンドは、当該コマンドをサーバ１００が受信したときにクライアントの認証に成功したコマンドである。  このようにして、ＲＴＳＰを用いた通信においてサーバがクライアントを認証しなかった場合には、その後、ＲＴＣＰを用いた通信によってクライアントとの通信セッションが継続されないようにすることができる。
【０１０６】
このようにして、サーバ１００がクライアントの認証を行う機能を実現できる第１の通信手順と、サーバ１００がクライアントの認証を必要としない第２の通信手順を併用して通信を行う場合にも、認証したクライアントとのみ通信を継続することができる。従って、サーバ１００とクライアントとの間で、よりセキュアな通信を実現することができる。
【０１０７】
本実施例では、ＲＴＳＰを用いた通信においてクライアントが認証されなかった場合でも、クライアントとの通信セッションのタイムアウト時刻が経過するまでは、通信セッションを維持するものとする。このようにして、一度クライアントが認証に失敗しても、タイムアウト前に再度認証を行い、認証に成功した場合には、通信セッションを維持させることができる。
【０１０８】
ＲＴＳＰの認証が失敗し、その後に同じ通信セッションでＲＴＳＰの認証が成功した場合の処理の例について、図６を用いて説明する。
【０１０９】
時刻６０１は、クライアントにおいて、ＲＴＳＰ認証モードの変更やパスワードの変更などがあった時刻を表す。
【０１１０】
コマンド６０２は、クライアントが時刻６０１において行った変更のために、サーバ１００がクライアントを認証しないことを示すエラーコードである。コマンド６０２は、第１のＲＴＳＰコマンドの受信に応答して、サーバ１００からクライアントに送信される。
【０１１１】
クライアントのＲＴＳＰ認証に失敗すると、サーバ１００は、ＲＴＳＰ認証に失敗した状態では、当該通信セッションにおいて、ＲＴＣＰのＲＲによる通信セッションの継続を無効とする。即ち、図６の６０３に示すＲＴＣＰ  ＲＲは、ＲＴＳＰ認証がエラーとなった状態で受信したものなので、６０３に示すＲＴＣＰ  ＲＲを受信したことを理由とするセッションの継続は行わない。図６では、ＲＴＳＰ認証がエラーになる前のＲＴＣＰ  ＲＲの受信から６０秒のセッションタイムアウト時刻が経過するまでは、セッションが継続される。
【０１１２】
ＲＴＣＰ認証がエラーになった後、セッションタイムアウト時刻が経過するまでに、第２のＲＴＳＰコマンドを受信し、クライアントのＲＴＳＰ認証が成功した場合、サーバ１００はクライアントに認証が成功したことを示すコマンド６０４を送信する。
【０１１３】
サーバ１００は、コマンド６０４を送信した以後は、ＲＴＣＰのＲＲを受信したことを理由として通信セッションを継続する機能を有効に切り替える。すなわち、ＲＲ６０５はクライアントのＲＴＳＰ認証が成功した状態で受信したものなので、ＲＲ６０５による当該セッションの継続は有効となる。
【０１１４】
こうして、第１の通信手順によりクライアントが所定のクライアントであると認証されなかった第１の時刻からクライアントが認証された第２の時刻までの期間には第２の通信手順によりクライアントとの通信セッションを維持することを制限する。ここで、第１の通信手順はＲＴＳＰであり、第２の通信手順はＲＴＣＰとすることができる。そして、第２の時刻以後は第２の通信手順によりクライアントとの通信セッションを維持することを許可する制御を行う。
【０１１５】
このようにすれば、サーバ１００によるクライアントの認証が失敗した後、当該クライアントがサーバ１００によって認証された場合には、クライアントがＲＴＣＰのＲＲを送信することにより通信セッションを継続させる機能を有効にすることができる。
【０１１６】
＜実施形態２＞
実施形態１では、ＲＴＳＰを用いた通信においてクライアントが認証されなかった場合、それ以降、サーバ１００がＲＴＣＰのＲＲを受信してもクライアントとの通信セッションを継続しないようにする例について説明した。
【０１１７】
しかし、クライアントが認証されなかった場合、それ以降に受信したＲＲのうち所定の時間内にＲＲを受信した場合には、ＲＲの受信に応じてサーバ１００がクライアントとの通信セッションを継続させることとしてもよい。
【０１１８】
実施形態２では、第１のＲＲを受信してから所定時間が経過する前に第２のＲＲを受信した場合、第１のＲＲの受信時刻と第２のＲＲの受信時刻の間でＲＴＳＰのクライアント認証が失敗しても、第２のＲＲの受信に応じて通信セッションを継続させる。
【０１１９】
実施形態２における送信装置の構成については、実施形態１において図１を用いて説明した内容と同じであるため説明を省略する。
【０１２０】
実施形態２における通信セッション制御の例を、図５を用いて説明する。
【０１２１】
実施形態１において図４を用いて説明した内容と同様に、ＲＴＳＰによる通信及びＲＴＣＰによる通信のタイムアウト時間は６０秒である場合について説明する。
【０１２２】
時刻５０３は第１のＲＴＳＰコマンド（第１のＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）を受信してから６０秒後の時刻を表す。
【０１２３】
時刻５０４は第１のＲＲを受信してから６０秒後の時刻を表す。時刻５０５は、第１のＲＲの後に送信される第２のＲＲをサーバが受信してから６０秒後の時刻を表す。また、時刻５０６は、第２のＲＲの後に送信される第３のＲＲをサーバが受信してから６０秒後の時刻を表す。
【０１２４】
図５において、時刻５０１は、第１のＲＴＳＰコマンドを受信した時刻と第２のＲＴＳＰコマンドの受信した時刻との間において、クライアントがＲＴＳＰ認証モードの変更やパスワードの変更などの設定変更を行った時刻を表す。
【０１２５】
図５の時刻５０１において、例えば、ＲＴＳＰ認証モードの変更やパスワードの変更などがあった場合、第２のＲＴＳＰコマンドに応じて実行されるクライアント認証が失敗すると、サーバ１００は認証エラーを示すエラーコード５０２を応答する。
【０１２６】
ここで、本実施形態では第２のＲＲを受信してから第３のＲＲを受信するまでに、クライアントの認証が失敗となった場合について説明する。
【０１２７】
実施形態１においては、クライアントが認証されなかった場合、それ以降に受信した第３のＲＲによっては通信セッションが継続されない場合について説明した。しかし、本実施形態では、第２のＲＲを受信した時刻から所定のタイムアウト時間が経過するまでに第３のＲＲを受信した場合には、サーバ１００は第３のＲＲの受信に応じて通信セッションを継続すると判定する。
【０１２８】
そして、クライアントの認証が失敗した後に受信した第３のＲＲから所定のタイムアウト時間が経過するまでに第４のＲＲを受信しても、第４のＲＲの受信に応じて通信セッション継続する機能は無効とする。
【０１２９】
このようにしても、ＲＴＳＰを用いた通信においてサーバがクライアントを認証しなかった場合には、その後、ＲＴＣＰを用いた通信によってクライアントとの通信セッションが継続されないようにすることができる。
【０１３０】
このようにして、サーバ１００がクライアントの認証を行う機能を実現できる第１の通信手順と、サーバ１００がクライアントの認証を必要としない第２の通信手順を併用して通信を行う場合にも、認証したクライアントとのみ通信を継続することができる。従って、サーバ１００とクライアントとの間で、よりセキュアな通信を実現することができる。
【０１３１】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１３２】
１００  サーバ
１０２  制御部
１０３  管理部
１０４  保持部
１０５  通信部
【図１】
2015104076.tif 000003
【図２】
2015104076.tif 000004
【図３】
2015104076.tif 000005
【図４】
2015104076.tif 000006
【図５】
2015104076.tif 000007
【図６】
2015104076.tif 000008