プロトコル変換システム、コンテンツ送受信端末およびコンテンツ送受信制御方法
【課題】ＩＰストレージの排他制御を行う仕組みを追加で備えることなく、ＩＰストレージを媒体としたコンテンツ流通を可能とするコンテンツ送受信制御方法を提供する。
【解決手段】ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能（ｉＳＮＳプロキシ）を設置するとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置する構成において、ｉＳＮＳプロキシ（ＳＩＰ−ＵＥ）機能のホームネットワーク側で、ＩＰストレージに対して、コンテンツを送受信する端末（ＰＣ）にＩＰストレージに備わるｉＳＮＳクライアント機能のプロキシ機能を備えることで、コンテンツ送受信時には、ＩＰストレージ利用を不可として代理登録する。
【解決手段】ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能（ｉＳＮＳプロキシ）を設置するとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置する構成において、ｉＳＮＳプロキシ（ＳＩＰ−ＵＥ）機能のホームネットワーク側で、ＩＰストレージに対して、コンテンツを送受信する端末（ＰＣ）にＩＰストレージに備わるｉＳＮＳクライアント機能のプロキシ機能を備えることで、コンテンツ送受信時には、ＩＰストレージ利用を不可として代理登録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）ストレージとサーバ間の接続管理を行うためのプロトコルであるｉＳＮＳのクライアントとサーバ間の通信を、ＳＩＰプロトコルを中継プロトコルとする広帯域のＩＰ−ＳＡＮ管理網を利用するＩＰストレージに対するコンテンツ送受信制御方法に関する。
【背景技術】
【０００２】
単体、もしくは複数のハードディスクドライブの集合体、あるいは専用の制御部で複数のハードディスクドライブを制御するディスクアレイ装置等から構成されるストレージ装置が実用化されている。ストレージ装置とホスト装置（サーバ、ＰＣ）間を接続するインターフェース技術としては、ファイバチャネル（ＦＣ：Fiber Channel）、インフィニバンド（InfiniBand）、ＳＣＳＩ（Small Computer Systems Interface）などがある。ＳＣＳＩインターフェースは、近距離間を経済的に接続する用途として優れ、既に広く普及している。当該インターフェースでは、クライアントに相当する機能をイニシエータ、サーバに相当する機能をターゲットと呼び、イニシエータとターゲット間でＳＣＳＩコマンド（ＣＤＢ：Command Descriptor Block）を交換する。ｉＳＣＳＩ（Internet SCSI）技術は、２００４年にネットワークプロトコルであるＴＣＰ／ＩＰの上位プロトコルとしてＩＥＴＦ（The Internet Engineering Task Force）でＲＦＣ３７２０によって標準化された（非特許文献１参照）。現在、ｉＳＣＳＩ技術は、ギガビット以上の回線品質、特にデータセンター内、データセンター間や大規模ＬＡＮシステム等の基幹回線で利用されている。ｉＳＣＳＩ技術は、非特許文献１でＴＣＰコネクションを複数利用する方法を規定しているが、オプション機能のため必ずしも実装されているわけではない。
【０００３】
ｉＳＮＳ（Internet Storage Name Service）技術は、ＴＣＰ／ＩＰネットワーク上で、上記ｉＳＣＳＩ、ｉＦＣＰ（Internet Fiber Channel Protocol）デバイスの検出、構成管理等の機能を提供するインターネット標準のストレージ専用のネームサービス（名前解決）規格であり、２００５年９月にＲＦＣ４１７１として制定された（非特許文献２参照）。ｉＳＮＳサーバは、管理デバイスに実装されたｉＳＮＳクライアント機能を通じて各デバイスのプロファイル情報、例えば、ＩＰアドレスやＲＦＣ３７２１（非特許文献３参照）で定義されたｉＳＣＳＩ名を管理する他、ｉＳＮＳサーバとｉＳＮＳクライアント間の相互死活管理、デバイス間のアクセス関係を定義するディスカバリドメインの管理、同一ドメイン内でのプロファイル共有等を実現する。特に、ドメイン内のプロファイル共有によってドメイン所属デバイスのＩＰアドレスリストを取得できることから、これをアクセスコントロールリスト（ＡＣＬ）に適用して各デバイスからのアクセスに対して動的Ｌ３制御を行うことができる。
【０００４】
ＩＭＳ（IP Multimedia Subsystem）は、固定電話網や移動体通信網など、回路スイッチやパケットスイッチが異なっていた公衆通信サービスを、ＩＰ技術やインターネット電話で使われるプロトコルであるＳＩＰ（非特許文献４参照）で統合し、マルチメディアサービスを実現させる通信方式である。第３世代携帯電話規格の標準化団体であり、Ｗ−ＣＤＭＡ方式を策定した３ＧＰＰ（3rd Generation Partnership Project）と、ＣＤＭＡ２０００方式を策定した３ＧＰＰ２（3rd Generation Partnership Project 2）によって標準化が行われている。
ＩＭＳは、３ＧＰＰリリース５（http://www.3gpp.org/specifications）で、ＮＧＮ（New Generation Network）向けのＳＩＰベースMultimedia Domainが加えられたことに起因する。このため、３ＧＰＰではＩＭＳと呼ばれているが、３ＧＰＰ２ではＭＭＤ（Multimedia Domain）と呼ばれている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Internet Small Computer Systems Interface(iSCSI), RFC3720(Proposed Standard), Apr 2004. Updated by RFCs3980, 4850, 5048.
【非特許文献２】Internet Storage Name Service(iSNS), RFC4171(Proposed Standard), Sep 2005.
【非特許文献３】Internet Small Computer Systems Interface(iSCSI) Naming and Discovery, RFC3721(Proposed Standard), Apr 2004.
【非特許文献４】SIP: Session Initiation Protocol, RFC3261(Proposed Standard), June 2002. Updated by RFCs3265, 3853, 4320, 4916.
【非特許文献５】Session Initiation Protocol(SIP)-Specific Event Notification, RFC3265(Proposed Standard), June 2002.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ｉＳＣＳＩを代表とするＩＰストレージの普及が進んだことから、ＩＰストレージと当該ストレージに接続する機能（イニシエータ）を実装した機器が増えている。この結果、遠隔地にあるＩＰストレージとの接続など、広帯域網を想定した需要が増えると見込まれる。ＩＰストレージの接続管理機能として、ＲＦＣ４１７１で制定されたｉＳＮＳが存在する。しかし、ｉＳＮＳは、ＬＡＮ向けの技術であることから、ＳＩＰプレゼンス制御機能をｉＳＮＳの中継機能として適用するシステムが考えられる。当該システムに接続されるＩＰストレージを更に、コンテンツ流通の蓄積機能として拡張利用しようとすると、ｉＳＮＳにはない、ＩＰストレージへのセッション確立に対して排他制御を行う仕組みを追加で備える必要があった。
【０００７】
本発明は、このような問題点に鑑みてなされたものであり、本発明の目的は、ＩＰストレージの排他制御を行う仕組みを追加で備えることなく、ＩＰストレージを媒体としたコンテンツ流通を可能とするプロトコル変換システム、コンテンツ送受信端末およびコンテンツ送受信制御方法を提供することにある。
【課題を解決するための手段】
【０００８】
ＩＰストレージデバイスの普及に伴い、ｉＳＮＳのクライアント機能を備えたＰＣやデバイスの数が増えている（Ｗｉｎｄｏｗｓ（登録商標） ＯＳには標準でｉＳＮＳクライアント機能が用意されている）。しかし、ｉＳＮＳはイニシエータとターゲット間の接続可否を制御する機能に限定され、接続可能なイニシエータ間の排他制御を行う機能を持たない。このため、ＩＰストレージを介したコンテンツ送受を制御するためには新たに排他制御（状態管理）機能を備える必要がある。
【０００９】
既存のｉＳＮＳクライアント機能を有するデバイスに状態管理（通知）機能を搭載することは、独自機器となることから経済性が低下する。このため、本発明では、当該デバイスに接続して、コンテンツを読み書きする外部機能に連動するｉＳＮＳプロキシ機能を配置する。当該プロキシ機能が対象デバイスの状態を代理登録することで排他制御を実行する。この結果、既存のｉＳＮＳクライアント機能を有するデバイスを介したコンテンツの流通が可能となる。
【００１０】
本発明では、ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能（ｉＳＮＳプロキシ）を設置するとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置する構成において、ｉＳＮＳプロキシ（ＳＩＰ−ＵＥ）機能のホームネットワーク側で、ＩＰストレージに対して、コンテンツを送受信する端末にＩＰストレージに備わるｉＳＮＳクライアント機能のプロキシ機能を備えることで、コンテンツ送受信時には、ＩＰストレージ利用を不可として代理登録する。これにより、ＩＰストレージへのアクセスについて排他制御を実現する。
【００１１】
すなわち、本発明のプロトコル変換システムは、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有することを特徴とする。
【００１２】
また、本発明のコンテンツ送受信端末は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおける前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えることを特徴とする。
【００１３】
また、本発明のコンテンツ送受信制御方法は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるコンテンツ送受信制御方法であって、ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有し、前記コンテンツ送受信端末の処理手順は、前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージの利用を不可として代理登録するステップと、前記ＩＰストレージを利用不可としている間に、前記ＩＰストレージに対して、コンテンツを送受信するステップとを含むことを特徴とする。
【発明の効果】
【００１４】
本発明は、ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能（ｉＳＮＳプロキシ）を設置するとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置するシステムもとで利用するＩＰストレージの排他制御が可能となることから、ＩＰストレージを媒体としたコンテンツ流通が可能となる。ローカルに存在するＩＰストレージをコンテンツの蓄積機能とすることから、流通するコンテンツのサイズ、総量はローカルに配置するＩＰストレージ容量に依存する。この結果、コンテンツ流通事業者が設置するコンテンツアップロード形設備のスペックに制限されることなく、大規模で大容量のコンテンツ流通システムを構成できる。
【図面の簡単な説明】
【００１５】
【図１】ＩＭＳネットワークに対して、ＳＩＰ−ＡＳサーバとしてのｉＳＮＳゲートウェイサーバを設置し、ホームネットワーク上に設置されたｉＳＮＳクライアント機能を有するイニシエータとターゲットが存在し、各々がｉＳＮＳプロキシ機能を介して、ＩＭＳネットワークに接続された構成を示す図である。
【図２】図１に示すネットワーク構成の下で、コンテンツ送受信端末（図中では破線内部、ＰＣと記載）を追加した図である。
【図３】図２の処理のプロトコル処理シーケンスを示す図である。
【発明を実施するための形態】
【００１６】
本発明の実施の形態について図１から図３を参照して詳細に説明する。図１は、広域ＩＰネットワークであるＩＭＳネットワークにゲートウェイ装置を介して、２つのホームネットワークが接続された構成を示す。各ホームネットワーク内には、ｉＳＮＳクライアント１２を備えたｉＳＣＳＩターゲット（ストレージ）１４と、ｉＳＮＳクライアント１３を備えたｉＳＣＳＩイニシエータ（ＰＣ、あるいはサーバ）１５が存在する。また、ｉＳＮＳクライアント１２は、ｉＳＮＳプロキシ１７に接続され、ｉＳＮＳクライアント１３は、ｉＳＮＳプロキシ１８に接続されている。
【００１７】
一方、ＩＭＳネットワークには、ＳＩＰアプリケーションサーバ（ＳＩＰ−ＡＳ）の１種であるｉＳＮＳゲートウェイサーバ１１が設置される。ｉＳＮＳゲートウェイサーバ１１は、ＩＳＣ（IMS Service Control）インターフェースを介してＩＭＳコア２０に接続され、ｉＳＮＳサーバ１９とＩＭＳコア２０との間の通信を仲介する。
【００１８】
ＩＭＳコア２０は、ＣＳＣＦ（Call Session Control Function）サーバ２１と、ホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）２２とにより構成され、ＣＳＣＦサーバ２１は、ＳＩＰに基づくセッション制御を行うＳ−ＣＳＣＦ（Serving-CSCF）２３と、問い合わせを受け付けるＩ−ＣＳＣＦ（Interrogating-CSCF）２４と、ユーザ端末（ＵＥ）がアクセスするＰ−ＣＳＣＦ（Proxy-CSCF）２５とにより構成されている。ホーム加入者サーバ（ＨＳＳ）２２は、ｉＳＮＳプロキシ１７、１８の情報などを登録格納しているデータベースサーバである。ホーム加入者サーバ（ＨＳＳ）２２と、Ｓ−ＣＳＣＦ２３およびＰ−ＣＳＣＦ２５との間の情報の交換には、Ｄｉａｍｅｔｅｒプロトコルが用いられる。
【００１９】
本発明は、ｉＳＮＳゲートウェイサーバ１１とｉＳＮＳプロキシ１７、１８の機能により実現され、両者は、ｉＳＮＳＰ（ｉＳＮＳプロトコル）とＳＩＰを中継するプロトコル変換機能を有する。
各機能ブロックに付記した記号ＩＰ−は、ＩＰアドレスを意味し、ＩＰアドレス下部の数字は、受信ポート番号を意味する。また、ｉＳＮＳクライアント１２、１３、ｉＳＮＳプロキシ１７、１８、およびｉＳＮＳゲートウェイサーバ１１にはそれぞれ固有の名称（ｉＳＣＳＩ ｎａｍｅ、ＳＩＰ ＵＲＩ）が与えられる。
ｉＳＮＳゲートウェイサーバ１１には、ＸＭＬデータベース１６が付属し、ｉＳＮＳネームとＳＩＰ ＵＲＩ（Uniform Resource Identifier）のマッピング情報が保存される。なお、当該データベースは、ＩＭＳコア２０のホーム加入者サーバ（ＨＳＳ）２２への統合も可能である。
【００２０】
図２は、図１の構成よりＩＭＳコア部分とＵｔインターフェースを省略し、ｉＳＮＳプロキシとｉＳＮＳゲートウェイサーバ間の接続を簡略した図面に対して、本発明であるコンテンツ送受信端末（図中ではＰＣと記載、破線の内側）を追記した図面である。
以下、処理動作を説明する。なお、ＳＩＰ ＵＥ（User Equipment）機能を有するｉＳＮＳプロキシは、ＩＭＳネットワーク（ＩＭＳコア）に対して、ＳＩＰ ＵＥとしてのデバイス登録を完了しているものとする。
例えば、ＩＰアドレスＩＰ−ｇｔを有するｉＳＮＳプロキシは、
ＳＩＰ ＵＲＩ： ＳＩＰ ＵＲＩ−ｔ
ＩＰ ａｄｄｒｅｓｓ： ＩＰ−ｇｔ
Ｐｏｒｔ ｎｕｍｂｅｒ： ５０６０（ＴＣＰ／ＵＤＰ）
としてＩＭＳコア（ＨＳＳ）に登録済みであるとする。また、ＳＩＰ ＵＥは、ｉＳＮＳゲートウェイサーバのＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｇｗ（ＳＩＰ ＵＲＩについては、非特許文献４に規定されたフォーマットが存在するが、本発明の本質とは異なるため省略形式で記載する。）を既知とする。
【００２１】
［処理ｓ１（処理ｓ２２）］
ｉＳＮＳクライアント１２（処理ｓ２２ではｉＳＮＳプロキシクライアント２６）は、ｉＳＮＳプロキシ１７（ＩＰアドレス：ＩＰ−Ｐｔ）をｉＳＮＳサーバとして設定し、ｉＳＮＳプロキシ１７との間で確立したＴＣＰコネクションを通して、以下の情報を持ったｉＳＮＳプロトコル（非特許文献２参照）のデバイス登録要求ＤｅｖＡｔｔｒＲｅｇを発行する。なお、ｉＳＣＳＩイニシエータ１５、ｉＳＣＳＩターゲット１４ともにＴＣＰポート番号は、デフォルトの３２６０を使用するものとする。
Ｓｒｃ：（ｔａｇ＝３２） ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
上記のとおり、ｉＳＮＳクライアント１２（処理ｓ２２ではｉＳＮＳプロキシクライアント２６）は、ｉＳＮＳネームとしてｉＳＣＳＩ ｎａｍｅ−ｉを有する。ｉＳＣＳＩ ｎａｍｅは、非特許文献３で規定されたフォーマットが存在するが、本発明の本質ではないため省略形式で記載する。登録するＩＰアドレス（ｔａｇ１６）は、ホームネットワークで使用するローカルアドレスである。
【００２２】
［処理ｓ２］
ＤｅｖＡｔｔｒＲｅｇを受信したｉＳＮＳプロキシ１７は、自らに付与された固有のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｔを用いて、ｉＳＮＳゲートウェイサーバ１１のＵｔインターフェースに対して、ＸＣＡＰ（XML Configuration Access Protocol）のＰＵＴ操作で、以下の情報を登録する（正確なｘｍｌフォーマットでなく、包含されるべきｔａｇと値のリストで記載する）。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ｔａｇ１＞ ＮＵＬＬ
＜ｔａｇ２＞ ｉＳＣＳＩ
＜ｔａｇ１６＞ ＩＰ−ｈｔ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ３３＞ ｔａｒｇｅｔ
＜ｔａｇ３４＞ ｄｉｓｋ ２
すなわち、処理ｓ１で発行されたＤｅｖＡｔｔｒＲｅｇのタグ付き情報とＳＩＰ ＵＲＩの組情報として登録を行う。
【００２３】
［処理ｓ３］
ｉＳＮＳプロキシ（ＳＩＰ ＵＥ）１７から処理ｓ２の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、当該情報をＸＭＬデータベース１６に登録し、ＳＩＰ ＵＲＩをキーとしたｔａｇ付き情報の検索と、ｉＳＣＳＩ ｎａｍｅをキーとしたＳＩＰ ＵＲＩの検索を可能とする。ＸＭＬデータベース１６への情報登録の後、ｉＳＮＳプロキシ１７に対して登録完了のＳＩＰ信号である２００ ＯＫを発行する。
【００２４】
［処理ｓ４（処理ｓ２３）］
処理ｓ３の２００ ＯＫ受信後、ｉＳＮＳゲートウェイサーバ（ＳＩＰ ＵＲＩ−ｇｗ）１１に対して、以下の情報を持つＳＩＰ ＰＵＢＬＩＳＨ信号（ＳＩＰ Ｐｒｅｓｅｎｃｅの登録「利用可能（ｏｐｅｎ）」）をＰＩＤＦ形式で発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｏｐｅｎ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
【００２５】
［処理ｓ５（処理ｓ２４）］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ１のＤｅｖＡｔｔｒＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００２６】
［処理ｓ６（処理ｓ２５）］
ｉＳＮＳサーバ１９は、ｉＳＮＳサーバ１９からはｉＳＮＳクライアントに見えるｉＳＮＳゲートウェイサーバ（ＳＩＰ−ＡＳ）１１の発行したデバイス登録要求ＤｅｖＡｔｔｒＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｉの登録（利用可能）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（登録完了）信号ＤｅｖＡｔｔｒＲｅｇＲｅｐを発行する。ここで、ｉＳＮＳサーバ１９の固有の識別ＩＤは、ｉｓｎｓ：０００１とする。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００２７】
［処理ｓ７（処理ｓ２６）］
処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ４への応答信号としての２００ ＯＫを発行する。
【００２８】
［処理ｓ８（処理ｓ２７）］
ｉＳＮＳプロキシ１７は、処理ｓ７の２００ ＯＫを受けて、処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを再構成する。当該信号は、処理ｓ１で確立したＴＣＰコネクションを通して、ｉＳＮＳクライアント１２（処理ｓ２７ではｉＳＮＳプロキシクライアント２６）に発行される。
【００２９】
＜排他制御のためのストレージ登録削除処理＞
［処理ｓ９］
コンテンツ送受信端末（ＰＣ）内のｉＳＮＳプロキシクライアント（ｉＳＮＳプロキシとは別）２６は、ｉＳＮＳプロキシ１７をｉＳＮＳサーバとして設定し、ｉＳＮＳプロキシ１７との間で確立したＴＣＰコネクションを通して、以下の情報を持ったデバイス削除要求ＤｅｖＤｅＲｅｇを発行する。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００３０】
［処理ｓ１０］
ｉＳＮＳプロキシ１７は、ｉＳＮＳゲートウェイサーバ（ＳＩＰ ＵＲＩ−ｇｗ）１１に対して、以下の情報を持つＳＩＰ ＰＵＢＬＩＳＨ信号（ＳＩＰ Ｐｒｅｓｅｎｃｅの登録「利用不可（ｃｌｏｓｅ）」）をＰＩＤＦ形式で発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｃｌｏｓｅ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
【００３１】
［処理ｓ１１］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ９のＤｅｖＤｅＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００３２】
［処理ｓ１２］
ｉＳＮＳサーバ１９は、ｉＳＮＳサーバ１９からはｉＳＮＳクライアントに見えるｉＳＮＳゲートウェイサーバ（ＳＩＰ−ＡＳ）１１の発行したデバイス削除要求ＤｅｖＤｅＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｔの削除（利用不可）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（削除完了）信号ＤｅｖＤｅＲｅｇＲｅｐを発行する。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００３３】
［処理ｓ１３］
処理ｓ１２のＤｅｖＤｅＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ１０への応答信号としての２００ ＯＫを発行する。
【００３４】
［処理ｓ１４］
ｉＳＮＳプロキシ１７は、処理ｓ１３の２００ ＯＫを受けて、処理ｓ１２のＤｅｖＤｅＲｅｇＲｅｐを再構成する。当該信号は処理ｓ９で確立したＴＣＰコネクションを通して、ｉＳＮＳプロキシクライアント２６に発行される。
【００３５】
＜端末からのコンテンツ転送、メタ情報登録処理＞
［処理ｓ１５］
コンテンツ送受信端末（ＰＣ）は、以下の情報を用いて、ｉＳＣＳＩターゲット（ストレージ）１４と接続を行う。
＜ｉＳＣＳＩ ｎａｍｅ＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ＩＰ ａｄｄｒｅｓｓ＞ ＩＰ−ｈｔ
＜Ｐｏｒｔ ｎｕｍｂｅｒ＞ ３２６０
【００３６】
［処理ｓ１６］
ｉＳＣＳＩ接続によってコンテンツ送受信端末に接続されたストレージを既知のファイルシステムによりマウントし、ＯＳのコピーコマンド等を用いて、当該ストレージにコンテンツを転送する。
【００３７】
［処理ｓ１７］
ＸＤＭＳクライアント２７は、ｉＳＮＳプロキシ１７に対して、ＸＣＡＰのＰＵＴ操作で、以下の、ｉＳＣＳＩターゲット（ストレージ）１４に登録したコンテンツのメタ情報の登録依頼をする（正確なｘｍｌフォーマットでなく、包含されるべき情報名と値のリストで記載する）。
＜ＦｉｌｅＳｙｓｔｅｍ＞ ＦＡＴ３２
＜Ｐａｔｈ＞ ／ｈｏｍｅ／ｇｕｅｓｔ／ｖｉｄｅｏ
＜Ｅｘｔｅｎｓｉｏｎ＞ ｍｐｇ４
＜ＦｉｌｅＮａｍｅ＞ ｓｋｉｔｏｕｒ００１
＜Ｄａｔｅ＞ ２０１００２１０
＜Ｓｅｃ＞ ３６００
【００３８】
［処理ｓ１８］
ｉＳＮＳプロキシ１７は、自らに付与された固有のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＬ−ｔを付加して、ｉＳＮＳゲートウェイサーバ１１に対して、以下の情報を登録する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ＦｉｌｅＳｙｓｔｅｍ＞ ＦＡＴ３２
＜Ｐａｔｈ＞ ／ｈｏｍｅ／ｇｕｅｓｔ／ｖｉｄｅｏ＄
＜Ｅｘｔｅｎｓｉｏｎ＞ ｍｐｇ４
＜ＦｉｌｅＮａｍｅ＞ ｓｋｉｔｏｕｒ００１
＜Ｄａｔｅ＞ ２０１００２１０
＜Ｓｅｃ＞ ３６００
【００３９】
［処理ｓ１９］
ｉＳＮＳプロキシ１７から処理ｓ１８の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、当該情報をＸＭＬデータベース１６に登録する。登録後、ｉＳＮＳプロキシ１７に対して登録完了のＳＩＰ信号である２００ ＯＫを発行する。
【００４０】
［処理ｓ２０］
２００ ＯＫを受信したｉＳＮＳプロキシ１７は、ＸＤＭＳクライアント２７に対して、２００ ＯＫを発行し、メタ情報の登録が完了したことを通知する。
【００４１】
［処理ｓ２１］
コンテンツ送受信端末は、ｉＳＣＳＩターゲット（ストレージ）１４の解放を行う。
【００４２】
この後、処理ｓ２２〜ｓ２７により、ｉＳＣＳＩイニシエータ（コンテンツ送受信端末）のｉＳＮＳサーバ１９への再登録を行う。
【００４３】
図３は、図２の処理に対応したコマンドシーケンスを示す図である。図３のｓ１〜ｓ２７は、図２のｓ１〜ｓ２７と一致している。なお、処理ｓ２２〜ｓ２７は、処理ｓ１、ｓ４〜ｓ８（再登録のため処理ｓ２、ｓ３は省略可能）と同じである。
【符号の説明】
【００４４】
１１ ｉＳＮＳゲートウェイサーバ
１２，１３ ｉＳＮＳクライアＦント
１４ ｉＳＣＳＩターゲット
１５ ｉＳＣＳＩイニシエータ
１６ ＸＭＬデータベース
１７，１８ ｉＳＮＳプロキシ
１９ ｉＳＮＳサーバ
２０ ＩＭＳコア
２１ ＣＳＣＦサーバ
２２ ホーム加入者サーバ
２３ Ｓ−ＣＳＣＦ
２４ Ｉ−ＣＳＣＦ
２５ Ｐ−ＣＳＣＦ
２６ ｉＳＮＳプロキシクライアント
２７ ＸＤＭＳクライアント
ｓ１ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ２ ＸＭＬ文書の登録（ＰＵＴ）
ｓ３ ｓ２に対する応答（成功）信号
ｓ４ ＳＩＰプロトコルによる属性登録要求
ｓ５ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ６ ｓ５に対する応答（登録成功）信号
ｓ７ ｓ４に対する応答（登録成功）信号
ｓ８ ｓ１に対する応答（登録成功）信号
ｓ９ 端末内のｉＳＮＳプロキシクライアントによるデバイス属性削除要求
ｓ１０ ＳＩＰ ＰＵＢＬＩＳＨ信号によるＢＵＳＹ（利用不可）通知
ｓ１１ ｉＳＮＳ−ＧＷによるデバイス属性削除要求
ｓ１２ デバイス属性の削除完了応答
ｓ１３ ｓ１０に対する応答（ＢＵＳＹ登録完了）
ｓ１４ ｓ９に対する応答（デバイス属性削除完了）
ｓ１５ ｉＳＣＳＩストレージへのｉＳＣＳＩセッション確立
ｓ１６ ｉＳＣＳＩストレージへのコンテンツ送信（転送）
ｓ１７ ストレージマウントとコンテンツメタ情報転送
ｓ１８ ｓ１７の信号のリレー
ｓ１９ ｓ１７の信号への応答（登録完了）
ｓ２０ ｓ１９の信号のリレー
ｓ２１ 端末とｉＳＣＳＩストレージ間のｉＳＣＳＩセッション解放
ｓ２２ ｓ１に対応するデバイス属性（再）登録要求
ｓ２３ ｓ４に対応するＡＶＡＩＬＡＢＬＥ（利用可能）通知
ｓ２４ ｓ５に対応するデバイス属性（再）登録要求
ｓ２５ ｓ６に対応するデバイス属性の登録完了応答
ｓ２６ ｓ７に対応する応答（ＡＶＡＩＬＡＢＬＥ登録完了）
ｓ２７ ｓ８に対応する応答（（再）登録完了）
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）ストレージとサーバ間の接続管理を行うためのプロトコルであるｉＳＮＳのクライアントとサーバ間の通信を、ＳＩＰプロトコルを中継プロトコルとする広帯域のＩＰ−ＳＡＮ管理網を利用するＩＰストレージに対するコンテンツ送受信制御方法に関する。
【背景技術】
【０００２】
単体、もしくは複数のハードディスクドライブの集合体、あるいは専用の制御部で複数のハードディスクドライブを制御するディスクアレイ装置等から構成されるストレージ装置が実用化されている。ストレージ装置とホスト装置（サーバ、ＰＣ）間を接続するインターフェース技術としては、ファイバチャネル（ＦＣ：Fiber Channel）、インフィニバンド（InfiniBand）、ＳＣＳＩ（Small Computer Systems Interface）などがある。ＳＣＳＩインターフェースは、近距離間を経済的に接続する用途として優れ、既に広く普及している。当該インターフェースでは、クライアントに相当する機能をイニシエータ、サーバに相当する機能をターゲットと呼び、イニシエータとターゲット間でＳＣＳＩコマンド（ＣＤＢ：Command Descriptor Block）を交換する。ｉＳＣＳＩ（Internet SCSI）技術は、２００４年にネットワークプロトコルであるＴＣＰ／ＩＰの上位プロトコルとしてＩＥＴＦ（The Internet Engineering Task Force）でＲＦＣ３７２０によって標準化された（非特許文献１参照）。現在、ｉＳＣＳＩ技術は、ギガビット以上の回線品質、特にデータセンター内、データセンター間や大規模ＬＡＮシステム等の基幹回線で利用されている。ｉＳＣＳＩ技術は、非特許文献１でＴＣＰコネクションを複数利用する方法を規定しているが、オプション機能のため必ずしも実装されているわけではない。
【０００３】
ｉＳＮＳ（Internet Storage Name Service）技術は、ＴＣＰ／ＩＰネットワーク上で、上記ｉＳＣＳＩ、ｉＦＣＰ（Internet Fiber Channel Protocol）デバイスの検出、構成管理等の機能を提供するインターネット標準のストレージ専用のネームサービス（名前解決）規格であり、２００５年９月にＲＦＣ４１７１として制定された（非特許文献２参照）。ｉＳＮＳサーバは、管理デバイスに実装されたｉＳＮＳクライアント機能を通じて各デバイスのプロファイル情報、例えば、ＩＰアドレスやＲＦＣ３７２１（非特許文献３参照）で定義されたｉＳＣＳＩ名を管理する他、ｉＳＮＳサーバとｉＳＮＳクライアント間の相互死活管理、デバイス間のアクセス関係を定義するディスカバリドメインの管理、同一ドメイン内でのプロファイル共有等を実現する。特に、ドメイン内のプロファイル共有によってドメイン所属デバイスのＩＰアドレスリストを取得できることから、これをアクセスコントロールリスト（ＡＣＬ）に適用して各デバイスからのアクセスに対して動的Ｌ３制御を行うことができる。
【０００４】
ＩＭＳ（IP Multimedia Subsystem）は、固定電話網や移動体通信網など、回路スイッチやパケットスイッチが異なっていた公衆通信サービスを、ＩＰ技術やインターネット電話で使われるプロトコルであるＳＩＰ（非特許文献４参照）で統合し、マルチメディアサービスを実現させる通信方式である。第３世代携帯電話規格の標準化団体であり、Ｗ−ＣＤＭＡ方式を策定した３ＧＰＰ（3rd Generation Partnership Project）と、ＣＤＭＡ２０００方式を策定した３ＧＰＰ２（3rd Generation Partnership Project 2）によって標準化が行われている。
ＩＭＳは、３ＧＰＰリリース５（http://www.3gpp.org/specifications）で、ＮＧＮ（New Generation Network）向けのＳＩＰベースMultimedia Domainが加えられたことに起因する。このため、３ＧＰＰではＩＭＳと呼ばれているが、３ＧＰＰ２ではＭＭＤ（Multimedia Domain）と呼ばれている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Internet Small Computer Systems Interface(iSCSI), RFC3720(Proposed Standard), Apr 2004. Updated by RFCs3980, 4850, 5048.
【非特許文献２】Internet Storage Name Service(iSNS), RFC4171(Proposed Standard), Sep 2005.
【非特許文献３】Internet Small Computer Systems Interface(iSCSI) Naming and Discovery, RFC3721(Proposed Standard), Apr 2004.
【非特許文献４】SIP: Session Initiation Protocol, RFC3261(Proposed Standard), June 2002. Updated by RFCs3265, 3853, 4320, 4916.
【非特許文献５】Session Initiation Protocol(SIP)-Specific Event Notification, RFC3265(Proposed Standard), June 2002.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ｉＳＣＳＩを代表とするＩＰストレージの普及が進んだことから、ＩＰストレージと当該ストレージに接続する機能（イニシエータ）を実装した機器が増えている。この結果、遠隔地にあるＩＰストレージとの接続など、広帯域網を想定した需要が増えると見込まれる。ＩＰストレージの接続管理機能として、ＲＦＣ４１７１で制定されたｉＳＮＳが存在する。しかし、ｉＳＮＳは、ＬＡＮ向けの技術であることから、ＳＩＰプレゼンス制御機能をｉＳＮＳの中継機能として適用するシステムが考えられる。当該システムに接続されるＩＰストレージを更に、コンテンツ流通の蓄積機能として拡張利用しようとすると、ｉＳＮＳにはない、ＩＰストレージへのセッション確立に対して排他制御を行う仕組みを追加で備える必要があった。
【０００７】
本発明は、このような問題点に鑑みてなされたものであり、本発明の目的は、ＩＰストレージの排他制御を行う仕組みを追加で備えることなく、ＩＰストレージを媒体としたコンテンツ流通を可能とするプロトコル変換システム、コンテンツ送受信端末およびコンテンツ送受信制御方法を提供することにある。
【課題を解決するための手段】
【０００８】
ＩＰストレージデバイスの普及に伴い、ｉＳＮＳのクライアント機能を備えたＰＣやデバイスの数が増えている（Ｗｉｎｄｏｗｓ（登録商標） ＯＳには標準でｉＳＮＳクライアント機能が用意されている）。しかし、ｉＳＮＳはイニシエータとターゲット間の接続可否を制御する機能に限定され、接続可能なイニシエータ間の排他制御を行う機能を持たない。このため、ＩＰストレージを介したコンテンツ送受を制御するためには新たに排他制御（状態管理）機能を備える必要がある。
【０００９】
既存のｉＳＮＳクライアント機能を有するデバイスに状態管理（通知）機能を搭載することは、独自機器となることから経済性が低下する。このため、本発明では、当該デバイスに接続して、コンテンツを読み書きする外部機能に連動するｉＳＮＳプロキシ機能を配置する。当該プロキシ機能が対象デバイスの状態を代理登録することで排他制御を実行する。この結果、既存のｉＳＮＳクライアント機能を有するデバイスを介したコンテンツの流通が可能となる。
【００１０】
本発明では、ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能（ｉＳＮＳプロキシ）を設置するとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置する構成において、ｉＳＮＳプロキシ（ＳＩＰ−ＵＥ）機能のホームネットワーク側で、ＩＰストレージに対して、コンテンツを送受信する端末にＩＰストレージに備わるｉＳＮＳクライアント機能のプロキシ機能を備えることで、コンテンツ送受信時には、ＩＰストレージ利用を不可として代理登録する。これにより、ＩＰストレージへのアクセスについて排他制御を実現する。
【００１１】
すなわち、本発明のプロトコル変換システムは、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有することを特徴とする。
【００１２】
また、本発明のコンテンツ送受信端末は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおける前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えることを特徴とする。
【００１３】
また、本発明のコンテンツ送受信制御方法は、ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるコンテンツ送受信制御方法であって、ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有し、前記コンテンツ送受信端末の処理手順は、前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージの利用を不可として代理登録するステップと、前記ＩＰストレージを利用不可としている間に、前記ＩＰストレージに対して、コンテンツを送受信するステップとを含むことを特徴とする。
【発明の効果】
【００１４】
本発明は、ＩＭＳ網へのｉＳＮＳクライアント収容に際して、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換する機能（ｉＳＮＳプロキシ）を設置するとともに、ＩＭＳコアとｉＳＮＳサーバ間のＳＩＰ−ＡＳサーバに、ｉＳＮＳサーバとＩＭＳコア間のプロトコル変換を実現するゲートウェイ機能を配置するシステムもとで利用するＩＰストレージの排他制御が可能となることから、ＩＰストレージを媒体としたコンテンツ流通が可能となる。ローカルに存在するＩＰストレージをコンテンツの蓄積機能とすることから、流通するコンテンツのサイズ、総量はローカルに配置するＩＰストレージ容量に依存する。この結果、コンテンツ流通事業者が設置するコンテンツアップロード形設備のスペックに制限されることなく、大規模で大容量のコンテンツ流通システムを構成できる。
【図面の簡単な説明】
【００１５】
【図１】ＩＭＳネットワークに対して、ＳＩＰ−ＡＳサーバとしてのｉＳＮＳゲートウェイサーバを設置し、ホームネットワーク上に設置されたｉＳＮＳクライアント機能を有するイニシエータとターゲットが存在し、各々がｉＳＮＳプロキシ機能を介して、ＩＭＳネットワークに接続された構成を示す図である。
【図２】図１に示すネットワーク構成の下で、コンテンツ送受信端末（図中では破線内部、ＰＣと記載）を追加した図である。
【図３】図２の処理のプロトコル処理シーケンスを示す図である。
【発明を実施するための形態】
【００１６】
本発明の実施の形態について図１から図３を参照して詳細に説明する。図１は、広域ＩＰネットワークであるＩＭＳネットワークにゲートウェイ装置を介して、２つのホームネットワークが接続された構成を示す。各ホームネットワーク内には、ｉＳＮＳクライアント１２を備えたｉＳＣＳＩターゲット（ストレージ）１４と、ｉＳＮＳクライアント１３を備えたｉＳＣＳＩイニシエータ（ＰＣ、あるいはサーバ）１５が存在する。また、ｉＳＮＳクライアント１２は、ｉＳＮＳプロキシ１７に接続され、ｉＳＮＳクライアント１３は、ｉＳＮＳプロキシ１８に接続されている。
【００１７】
一方、ＩＭＳネットワークには、ＳＩＰアプリケーションサーバ（ＳＩＰ−ＡＳ）の１種であるｉＳＮＳゲートウェイサーバ１１が設置される。ｉＳＮＳゲートウェイサーバ１１は、ＩＳＣ（IMS Service Control）インターフェースを介してＩＭＳコア２０に接続され、ｉＳＮＳサーバ１９とＩＭＳコア２０との間の通信を仲介する。
【００１８】
ＩＭＳコア２０は、ＣＳＣＦ（Call Session Control Function）サーバ２１と、ホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）２２とにより構成され、ＣＳＣＦサーバ２１は、ＳＩＰに基づくセッション制御を行うＳ−ＣＳＣＦ（Serving-CSCF）２３と、問い合わせを受け付けるＩ−ＣＳＣＦ（Interrogating-CSCF）２４と、ユーザ端末（ＵＥ）がアクセスするＰ−ＣＳＣＦ（Proxy-CSCF）２５とにより構成されている。ホーム加入者サーバ（ＨＳＳ）２２は、ｉＳＮＳプロキシ１７、１８の情報などを登録格納しているデータベースサーバである。ホーム加入者サーバ（ＨＳＳ）２２と、Ｓ−ＣＳＣＦ２３およびＰ−ＣＳＣＦ２５との間の情報の交換には、Ｄｉａｍｅｔｅｒプロトコルが用いられる。
【００１９】
本発明は、ｉＳＮＳゲートウェイサーバ１１とｉＳＮＳプロキシ１７、１８の機能により実現され、両者は、ｉＳＮＳＰ（ｉＳＮＳプロトコル）とＳＩＰを中継するプロトコル変換機能を有する。
各機能ブロックに付記した記号ＩＰ−は、ＩＰアドレスを意味し、ＩＰアドレス下部の数字は、受信ポート番号を意味する。また、ｉＳＮＳクライアント１２、１３、ｉＳＮＳプロキシ１７、１８、およびｉＳＮＳゲートウェイサーバ１１にはそれぞれ固有の名称（ｉＳＣＳＩ ｎａｍｅ、ＳＩＰ ＵＲＩ）が与えられる。
ｉＳＮＳゲートウェイサーバ１１には、ＸＭＬデータベース１６が付属し、ｉＳＮＳネームとＳＩＰ ＵＲＩ（Uniform Resource Identifier）のマッピング情報が保存される。なお、当該データベースは、ＩＭＳコア２０のホーム加入者サーバ（ＨＳＳ）２２への統合も可能である。
【００２０】
図２は、図１の構成よりＩＭＳコア部分とＵｔインターフェースを省略し、ｉＳＮＳプロキシとｉＳＮＳゲートウェイサーバ間の接続を簡略した図面に対して、本発明であるコンテンツ送受信端末（図中ではＰＣと記載、破線の内側）を追記した図面である。
以下、処理動作を説明する。なお、ＳＩＰ ＵＥ（User Equipment）機能を有するｉＳＮＳプロキシは、ＩＭＳネットワーク（ＩＭＳコア）に対して、ＳＩＰ ＵＥとしてのデバイス登録を完了しているものとする。
例えば、ＩＰアドレスＩＰ−ｇｔを有するｉＳＮＳプロキシは、
ＳＩＰ ＵＲＩ： ＳＩＰ ＵＲＩ−ｔ
ＩＰ ａｄｄｒｅｓｓ： ＩＰ−ｇｔ
Ｐｏｒｔ ｎｕｍｂｅｒ： ５０６０（ＴＣＰ／ＵＤＰ）
としてＩＭＳコア（ＨＳＳ）に登録済みであるとする。また、ＳＩＰ ＵＥは、ｉＳＮＳゲートウェイサーバのＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｇｗ（ＳＩＰ ＵＲＩについては、非特許文献４に規定されたフォーマットが存在するが、本発明の本質とは異なるため省略形式で記載する。）を既知とする。
【００２１】
［処理ｓ１（処理ｓ２２）］
ｉＳＮＳクライアント１２（処理ｓ２２ではｉＳＮＳプロキシクライアント２６）は、ｉＳＮＳプロキシ１７（ＩＰアドレス：ＩＰ−Ｐｔ）をｉＳＮＳサーバとして設定し、ｉＳＮＳプロキシ１７との間で確立したＴＣＰコネクションを通して、以下の情報を持ったｉＳＮＳプロトコル（非特許文献２参照）のデバイス登録要求ＤｅｖＡｔｔｒＲｅｇを発行する。なお、ｉＳＣＳＩイニシエータ１５、ｉＳＣＳＩターゲット１４ともにＴＣＰポート番号は、デフォルトの３２６０を使用するものとする。
Ｓｒｃ：（ｔａｇ＝３２） ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
上記のとおり、ｉＳＮＳクライアント１２（処理ｓ２２ではｉＳＮＳプロキシクライアント２６）は、ｉＳＮＳネームとしてｉＳＣＳＩ ｎａｍｅ−ｉを有する。ｉＳＣＳＩ ｎａｍｅは、非特許文献３で規定されたフォーマットが存在するが、本発明の本質ではないため省略形式で記載する。登録するＩＰアドレス（ｔａｇ１６）は、ホームネットワークで使用するローカルアドレスである。
【００２２】
［処理ｓ２］
ＤｅｖＡｔｔｒＲｅｇを受信したｉＳＮＳプロキシ１７は、自らに付与された固有のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ−ｔを用いて、ｉＳＮＳゲートウェイサーバ１１のＵｔインターフェースに対して、ＸＣＡＰ（XML Configuration Access Protocol）のＰＵＴ操作で、以下の情報を登録する（正確なｘｍｌフォーマットでなく、包含されるべきｔａｇと値のリストで記載する）。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ｔａｇ１＞ ＮＵＬＬ
＜ｔａｇ２＞ ｉＳＣＳＩ
＜ｔａｇ１６＞ ＩＰ−ｈｔ
＜ｔａｇ１７＞ ３２６０
＜ｔａｇ３２＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ｔａｇ３３＞ ｔａｒｇｅｔ
＜ｔａｇ３４＞ ｄｉｓｋ ２
すなわち、処理ｓ１で発行されたＤｅｖＡｔｔｒＲｅｇのタグ付き情報とＳＩＰ ＵＲＩの組情報として登録を行う。
【００２３】
［処理ｓ３］
ｉＳＮＳプロキシ（ＳＩＰ ＵＥ）１７から処理ｓ２の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、当該情報をＸＭＬデータベース１６に登録し、ＳＩＰ ＵＲＩをキーとしたｔａｇ付き情報の検索と、ｉＳＣＳＩ ｎａｍｅをキーとしたＳＩＰ ＵＲＩの検索を可能とする。ＸＭＬデータベース１６への情報登録の後、ｉＳＮＳプロキシ１７に対して登録完了のＳＩＰ信号である２００ ＯＫを発行する。
【００２４】
［処理ｓ４（処理ｓ２３）］
処理ｓ３の２００ ＯＫ受信後、ｉＳＮＳゲートウェイサーバ（ＳＩＰ ＵＲＩ−ｇｗ）１１に対して、以下の情報を持つＳＩＰ ＰＵＢＬＩＳＨ信号（ＳＩＰ Ｐｒｅｓｅｎｃｅの登録「利用可能（ｏｐｅｎ）」）をＰＩＤＦ形式で発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｏｐｅｎ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
【００２５】
［処理ｓ５（処理ｓ２４）］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ１のＤｅｖＡｔｔｒＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００２６】
［処理ｓ６（処理ｓ２５）］
ｉＳＮＳサーバ１９は、ｉＳＮＳサーバ１９からはｉＳＮＳクライアントに見えるｉＳＮＳゲートウェイサーバ（ＳＩＰ−ＡＳ）１１の発行したデバイス登録要求ＤｅｖＡｔｔｒＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｉの登録（利用可能）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（登録完了）信号ＤｅｖＡｔｔｒＲｅｇＲｅｐを発行する。ここで、ｉＳＮＳサーバ１９の固有の識別ＩＤは、ｉｓｎｓ：０００１とする。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００２７】
［処理ｓ７（処理ｓ２６）］
処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ４への応答信号としての２００ ＯＫを発行する。
【００２８】
［処理ｓ８（処理ｓ２７）］
ｉＳＮＳプロキシ１７は、処理ｓ７の２００ ＯＫを受けて、処理ｓ６のＤｅｖＡｔｔｒＲｅｇＲｅｐを再構成する。当該信号は、処理ｓ１で確立したＴＣＰコネクションを通して、ｉＳＮＳクライアント１２（処理ｓ２７ではｉＳＮＳプロキシクライアント２６）に発行される。
【００２９】
＜排他制御のためのストレージ登録削除処理＞
［処理ｓ９］
コンテンツ送受信端末（ＰＣ）内のｉＳＮＳプロキシクライアント（ｉＳＮＳプロキシとは別）２６は、ｉＳＮＳプロキシ１７をｉＳＮＳサーバとして設定し、ｉＳＮＳプロキシ１７との間で確立したＴＣＰコネクションを通して、以下の情報を持ったデバイス削除要求ＤｅｖＤｅＲｅｇを発行する。
Ｓｒｃ：（ｔａｇ＝３２）ｉＳＣＳＩ ｎａｍｅ−ｔ
Ｋｅｙ： ＜ｎｏｎｅ ｐｒｅｓｅｎｔ＞
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ＮＵＬＬ
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００３０】
［処理ｓ１０］
ｉＳＮＳプロキシ１７は、ｉＳＮＳゲートウェイサーバ（ＳＩＰ ＵＲＩ−ｇｗ）１１に対して、以下の情報を持つＳＩＰ ＰＵＢＬＩＳＨ信号（ＳＩＰ Ｐｒｅｓｅｎｃｅの登録「利用不可（ｃｌｏｓｅ）」）をＰＩＤＦ形式で発行する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ｓｔａｔｕｓ＞ ｃｌｏｓｅ
＜ｃｏｎｔａｃｔ＞ ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
【００３１】
［処理ｓ１１］
ＳＩＰ ＰＵＢＬＩＳＨ信号を受信したｉＳＮＳゲートウェイサーバ１１は、ｃｏｎｔａｃｔに記載されたＳＩＰ ＵＲＩをキーとして、ＸＭＬデータベース１６からｉＳＣＳＩ ｎａｍｅを含むｔａｇ付き情報を検索する。検索結果から処理ｓ９のＤｅｖＤｅＲｅｇを再構成し、ｉＳＮＳサーバ１９に対して発行する。
【００３２】
［処理ｓ１２］
ｉＳＮＳサーバ１９は、ｉＳＮＳサーバ１９からはｉＳＮＳクライアントに見えるｉＳＮＳゲートウェイサーバ（ＳＩＰ−ＡＳ）１１の発行したデバイス削除要求ＤｅｖＤｅＲｅｇに基づき、ｉＳＣＳＩ ｎａｍｅ−ｔの削除（利用不可）を行い、ｉＳＮＳゲートウェイサーバ１１に対して、以下の応答（削除完了）信号ＤｅｖＤｅＲｅｇＲｅｐを発行する。
ＳＵＣＣＥＳＳ
Ｋｅｙ：（ｔａｇ＝１）ｉｓｎｓ：０００１
Ｏｐｅｒ Ａｔｔｒｓ：
ｔａｇ１： ｉｓｎｓ：０００１
ｔａｇ２： ｉＳＣＳＩ
ｔａｇ１６： ＩＰ−ｈｔ
ｔａｇ１７： ３２６０
ｔａｇ３２： ｉＳＣＳＩ ｎａｍｅ−ｔ
ｔａｇ３３： ｔａｒｇｅｔ
ｔａｇ３４： ｄｉｓｋ ２
【００３３】
［処理ｓ１３］
処理ｓ１２のＤｅｖＤｅＲｅｇＲｅｐを受信したｉＳＮＳゲートウェイサーバ１１は、ｔａｇ３２のｉＳＣＳＩ ｎａｍｅを検索キーとして、ＸＭＬデータベース１６からＳＩＰ ＵＲＩを検索し、当該ＳＩＰ ＵＲＩに対して、処理ｓ１０への応答信号としての２００ ＯＫを発行する。
【００３４】
［処理ｓ１４］
ｉＳＮＳプロキシ１７は、処理ｓ１３の２００ ＯＫを受けて、処理ｓ１２のＤｅｖＤｅＲｅｇＲｅｐを再構成する。当該信号は処理ｓ９で確立したＴＣＰコネクションを通して、ｉＳＮＳプロキシクライアント２６に発行される。
【００３５】
＜端末からのコンテンツ転送、メタ情報登録処理＞
［処理ｓ１５］
コンテンツ送受信端末（ＰＣ）は、以下の情報を用いて、ｉＳＣＳＩターゲット（ストレージ）１４と接続を行う。
＜ｉＳＣＳＩ ｎａｍｅ＞ ｉＳＣＳＩ ｎａｍｅ−ｔ
＜ＩＰ ａｄｄｒｅｓｓ＞ ＩＰ−ｈｔ
＜Ｐｏｒｔ ｎｕｍｂｅｒ＞ ３２６０
【００３６】
［処理ｓ１６］
ｉＳＣＳＩ接続によってコンテンツ送受信端末に接続されたストレージを既知のファイルシステムによりマウントし、ＯＳのコピーコマンド等を用いて、当該ストレージにコンテンツを転送する。
【００３７】
［処理ｓ１７］
ＸＤＭＳクライアント２７は、ｉＳＮＳプロキシ１７に対して、ＸＣＡＰのＰＵＴ操作で、以下の、ｉＳＣＳＩターゲット（ストレージ）１４に登録したコンテンツのメタ情報の登録依頼をする（正確なｘｍｌフォーマットでなく、包含されるべき情報名と値のリストで記載する）。
＜ＦｉｌｅＳｙｓｔｅｍ＞ ＦＡＴ３２
＜Ｐａｔｈ＞ ／ｈｏｍｅ／ｇｕｅｓｔ／ｖｉｄｅｏ
＜Ｅｘｔｅｎｓｉｏｎ＞ ｍｐｇ４
＜ＦｉｌｅＮａｍｅ＞ ｓｋｉｔｏｕｒ００１
＜Ｄａｔｅ＞ ２０１００２１０
＜Ｓｅｃ＞ ３６００
【００３８】
［処理ｓ１８］
ｉＳＮＳプロキシ１７は、自らに付与された固有のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＬ−ｔを付加して、ｉＳＮＳゲートウェイサーバ１１に対して、以下の情報を登録する。
Ｆｒｏｍ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｔ”
Ｔｏ： ｓｉｐ：“ＳＩＰ ＵＲＩ−ｇｗ”
＜ＳＩＰ ＵＲＩ＞ ＳＩＰ ＵＲＩ−ｔ
＜ＦｉｌｅＳｙｓｔｅｍ＞ ＦＡＴ３２
＜Ｐａｔｈ＞ ／ｈｏｍｅ／ｇｕｅｓｔ／ｖｉｄｅｏ＄
＜Ｅｘｔｅｎｓｉｏｎ＞ ｍｐｇ４
＜ＦｉｌｅＮａｍｅ＞ ｓｋｉｔｏｕｒ００１
＜Ｄａｔｅ＞ ２０１００２１０
＜Ｓｅｃ＞ ３６００
【００３９】
［処理ｓ１９］
ｉＳＮＳプロキシ１７から処理ｓ１８の情報を受け取ったｉＳＮＳゲートウェイサーバ１１は、当該情報をＸＭＬデータベース１６に登録する。登録後、ｉＳＮＳプロキシ１７に対して登録完了のＳＩＰ信号である２００ ＯＫを発行する。
【００４０】
［処理ｓ２０］
２００ ＯＫを受信したｉＳＮＳプロキシ１７は、ＸＤＭＳクライアント２７に対して、２００ ＯＫを発行し、メタ情報の登録が完了したことを通知する。
【００４１】
［処理ｓ２１］
コンテンツ送受信端末は、ｉＳＣＳＩターゲット（ストレージ）１４の解放を行う。
【００４２】
この後、処理ｓ２２〜ｓ２７により、ｉＳＣＳＩイニシエータ（コンテンツ送受信端末）のｉＳＮＳサーバ１９への再登録を行う。
【００４３】
図３は、図２の処理に対応したコマンドシーケンスを示す図である。図３のｓ１〜ｓ２７は、図２のｓ１〜ｓ２７と一致している。なお、処理ｓ２２〜ｓ２７は、処理ｓ１、ｓ４〜ｓ８（再登録のため処理ｓ２、ｓ３は省略可能）と同じである。
【符号の説明】
【００４４】
１１ ｉＳＮＳゲートウェイサーバ
１２，１３ ｉＳＮＳクライアＦント
１４ ｉＳＣＳＩターゲット
１５ ｉＳＣＳＩイニシエータ
１６ ＸＭＬデータベース
１７，１８ ｉＳＮＳプロキシ
１９ ｉＳＮＳサーバ
２０ ＩＭＳコア
２１ ＣＳＣＦサーバ
２２ ホーム加入者サーバ
２３ Ｓ−ＣＳＣＦ
２４ Ｉ−ＣＳＣＦ
２５ Ｐ−ＣＳＣＦ
２６ ｉＳＮＳプロキシクライアント
２７ ＸＤＭＳクライアント
ｓ１ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ２ ＸＭＬ文書の登録（ＰＵＴ）
ｓ３ ｓ２に対する応答（成功）信号
ｓ４ ＳＩＰプロトコルによる属性登録要求
ｓ５ ｉＳＮＳプロトコルによるデバイス属性登録要求
ｓ６ ｓ５に対する応答（登録成功）信号
ｓ７ ｓ４に対する応答（登録成功）信号
ｓ８ ｓ１に対する応答（登録成功）信号
ｓ９ 端末内のｉＳＮＳプロキシクライアントによるデバイス属性削除要求
ｓ１０ ＳＩＰ ＰＵＢＬＩＳＨ信号によるＢＵＳＹ（利用不可）通知
ｓ１１ ｉＳＮＳ−ＧＷによるデバイス属性削除要求
ｓ１２ デバイス属性の削除完了応答
ｓ１３ ｓ１０に対する応答（ＢＵＳＹ登録完了）
ｓ１４ ｓ９に対する応答（デバイス属性削除完了）
ｓ１５ ｉＳＣＳＩストレージへのｉＳＣＳＩセッション確立
ｓ１６ ｉＳＣＳＩストレージへのコンテンツ送信（転送）
ｓ１７ ストレージマウントとコンテンツメタ情報転送
ｓ１８ ｓ１７の信号のリレー
ｓ１９ ｓ１７の信号への応答（登録完了）
ｓ２０ ｓ１９の信号のリレー
ｓ２１ 端末とｉＳＣＳＩストレージ間のｉＳＣＳＩセッション解放
ｓ２２ ｓ１に対応するデバイス属性（再）登録要求
ｓ２３ ｓ４に対応するＡＶＡＩＬＡＢＬＥ（利用可能）通知
ｓ２４ ｓ５に対応するデバイス属性（再）登録要求
ｓ２５ ｓ６に対応するデバイス属性の登録完了応答
ｓ２６ ｓ７に対応する応答（ＡＶＡＩＬＡＢＬＥ登録完了）
ｓ２７ ｓ８に対応する応答（（再）登録完了）
【特許請求の範囲】
【請求項１】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、
前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有することを特徴とするプロトコル変換システム。
【請求項２】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおける前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えることを特徴とするコンテンツ送受信端末。
【請求項３】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるコンテンツ送受信制御方法であって、
ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有し、
前記コンテンツ送受信端末の処理手順は、
前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージの利用を不可として代理登録するステップと、
前記ＩＰストレージを利用不可としている間に、前記ＩＰストレージに対して、コンテンツを送受信するステップと、
を含むことを特徴とするコンテンツ送受信制御方法。
【請求項１】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムであって、
前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有することを特徴とするプロトコル変換システム。
【請求項２】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおける前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージへのイニシエータからの接続を、排他制御可能とする、ｉＳＮＳクライアント機能のプロキシ機能を備えることを特徴とするコンテンツ送受信端末。
【請求項３】
ｉＳＮＳクライアント端末とＳＩＰサーバとの間に配置され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換するプロトコル変換装置と、前記ＳＩＰサーバに接続され、ｉＳＮＳプロトコルとＳＩＰプロトコルを相互に変換し、ｉＳＮＳサーバにアクセス可能なゲートウェイサーバとを備えたプロトコル変換システムにおけるコンテンツ送受信制御方法であって、
ｉＳＮＳクライアント機能のプロキシ機能を備えるコンテンツ送受信端末を有し、
前記コンテンツ送受信端末の処理手順は、
前記プロトコル変換装置を介してｉＳＮＳクライアント機能によりｉＳＮＳ登録可能なＩＰストレージの利用を不可として代理登録するステップと、
前記ＩＰストレージを利用不可としている間に、前記ＩＰストレージに対して、コンテンツを送受信するステップと、
を含むことを特徴とするコンテンツ送受信制御方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１１−２５７７９４（Ｐ２０１１−２５７７９４Ａ）
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願番号】特願２０１０−１２９１１０（Ｐ２０１０−１２９１１０）
【出願日】平成２２年６月４日（２０１０．６．４）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願日】平成２２年６月４日（２０１０．６．４）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]