(57)【特許請求の範囲】
【請求項１】
取得源を管理するためのデータ取得源管理方法であって、
ネットワークによりリアルタイムマルチメディアデータオンデマンド（ＲＴＭＤＯＤ）サーバに連結された１組の取得源を認識するソースリストを生成する工程であって、前記１組の取得源の中の各取得源がそこからリアルタイムマルチメディアデータを供給するようになっているソースリスト生成工程と、
前記ＲＴＭＤＯＤサーバとデータ通信するデータリクエスタシステムからリストリクエストを受理する工程と、
前記リストリクエストに応答して前記データリクエスタシステムにソースリストを供給する工程とを包含する管理方法であって、
前記ソースリスト供給工程が、
前記データリクエスタシステムから前記ＲＴＭＤＯＤサーバへとログインデータを伝達する段階と、
前記データリクエスタシステムをリクエスタリスト上に登録する段階であって、そこからログインデータを受理するのに応答して登録し、そのリクエスタリストは複数のデータリクエスタシステムの少なくとも１つを包含しているように登録する段階と、
前記リクエスタリスト上に登録された複数のデータリクエスタシステムの各々に前記ソースリストを伝達する段階と、
前記ソースリスト上に登録された前記取得源の各々のステイタスをベリファイする段階であって、前記取得源の各々の前記ステイタスはアクティブか非アクティブかのいずれかであるベリファイ段階と、
そこから非アクティブのステイタスを有する取得源を除去することにより前記ソースリストをアップデートする段階と、
前記アップデートされたソースリストを複数のデータリクエスタシステムの各々に伝達する段階とを包含しており、
さらに当該管理方法は、前記ＲＴＭＤＯＤサーバで前記データリクエスタシステムからのデータリクエストを受理する工程であって、当該データリクエストはそこからデータが供給される取得源の組の中にある第１の取得源を認識するようになっているデータリクエスト受理工程と、
前記データリクエストに応答して前記ＲＴＭＤＯＤサーバからのデータ取得リクエストを第１の取得源へと伝達する工程と、
前記データ取得リクエストに応答して前記第１の取得源でデータの伝達を開始する工程とを包含しているデータ取得源管理方法。
【請求項２】
請求項１記載のデータ取得源管理方法であって、さらに、前記データリクエスタシステムから前記ＲＴＭＤＯＤサーバによって受理されたデータリクエストに応答して、前記ＲＴＭＤＯＤサーバから前記データリクエスタシステムへとデータレスポンスを供給する工程を包含しているデータ取得源管理方法。
【請求項３】
請求項１記載のデータ取得源管理方法であって、前記ＲＴＭＤＯＤサーバに連結された１組の取得源を認識するソースリストを生成する工程が、
前記１組の取得源からの登録データを前記ＲＴＭＤＯＤサーバへと伝達する段階と、
前記１組の取得源からの登録データを前記ＲＴＭＤＯＤサーバによってベリファイする段階と、
前記１組の取得源を前記ソースリスト上に登録し、その登録データを、登録された１組の取得源に対応するように、ベリファイされた前記登録データに応答してソースデータベース上に貯蔵する段階とを包含しているデータ取得源管理方法。
【請求項４】
請求項２記載のデータ取得源管理方法であって、前記ＲＴＭＤＯＤサーバから前記データリクエスタシステムへとデータレスポンスを供給する工程が、
前記ＲＴＭＤＯＤサーバから前記データリクエスタシステムにデータを伝達する段階であって、前記データは前記データリクエストにより指示されかつ前記データリクエストに応答する前記１組のデータ取得源の少なくとも１つによって供給されるようになっているデータ伝達段階を包含しているデータ取得源管理方法。
【請求項５】
請求項４記載のデータ取得源管理方法であって、対応する少なくとも１つの取得源から前記ＲＴＭＤＯＤサーバへと伝達されるデータが、続いてそこからリアルタイムで前記データリクエスタシステムによって受理されるようになっているデータ取得源管理方法。
【請求項６】
請求項２記載のデータ取得源管理方法であって、さらに、前記ＲＴＭＤＯＤサーバから前記第１の取得源へと前記データ取得リクエストが伝達されるのに続いてデータ伝達エラーが起こった際に、そのデータリクエストに応答して前記ＲＴＭＤＯＤサーバにより前記データリクエスタシステムへとエラーメッセージを供給する工程を包含しているデータ取得源管理方法。
【請求項７】
請求項１記載のデータ取得源管理方法であって、前記取得源の組の中の各取得源が前記ＲＴＭＤＯＤサーバとデータ通信しているデータ取得源管理方法。
【請求項８】
請求項７記載のデータ取得源管理方法であって、前記取得源の組の中の各取得源のステイタスが周期的にベリファイ可能であるデータ取得源管理方法。
【請求項９】
請求項８記載のデータ取得源管理方法であって、前記取得源の組の中の各取得源が、前記取得源の組の中の各取得源から前記ＲＴＭＤＯＤサーバへと少なくとも１つのステイタス信号を伝達することによりベリファイ可能であるデータ取得源管理方法。
【請求項１０】
請求項９記載のデータ取得源管理方法であって、所定の時間間隔で前記取得源から少なくとも１つのステイタス信号が受理されないときは、当該取得源のステイタスは非アクティブとしてアップデートされ前記ソースリストから除去されるデータ取得源管理方法。
【請求項１１】
請求項８記載のデータ取得源管理方法であって、前記ＲＴＭＤＯＤサーバとデータ通信している取得源の組の中の各取得源のステイタスはアクティブであるデータ取得源管理方法。
【請求項１２】
請求項１記載のデータ取得源管理方法であって、前記ＲＴＭＤＯＤサーバとデータ通信している各取得源のステイタスは、前記取得源の組の中の各取得源から前記ＲＴＭＤＯＤサーバへと周期的にステイタス信号を伝達することによりベリファイ可能であるデータ取得源管理方法。
【請求項１３】
請求項１記載のデータ取得源管理方法であって、前記データリクエストは前記データリクエスタシステムへの外的刺激によって受理されるデータ取得源管理方法。
【請求項１４】
請求項１３記載のデータ取得源管理方法であって、前記外的刺激はユーザーからの移動電話で生成されるＳＭＳ信号やユーザーからの電子メールの受け取りなどの１つであるデータ取得源管理方法。
【請求項１５】
取得源を管理するためのデータ取得源管理システムであって、
ネットワークによりリアルタイムマルチメディアデータオンデマンド（ＲＴＭＤＯＤ）サーバに連結された１組の取得源を認識するソースリストを生成する手段であって、前記１組の取得源の中の各取得源がそこからリアルタイムマルチメディアデータを供給するようになっているソースリスト生成手段と、
前記ＲＴＭＤＯＤサーバとデータ通信するデータリクエスタシステムからリストリクエストを受理する手段と、
前記リストリクエストに応答して前記データリクエスタシステムにソースリストを供給する手段とを包含する管理システムであって、
前記ソースリスト供給手段が、
前記データリクエスタシステムから前記ＲＴＭＤＯＤサーバへとログインデータを伝達する手段と、
前記データリクエスタシステムをリクエスタリスト上に登録する手段であって、そこからログインデータを受理するのに応答して登録し、そのリクエスタリストは複数のデータリクエスタシステムの少なくとも１つを包含しているように登録する手段と、
前記リクエスタリスト上に登録された複数のデータリクエスタシステムの各々に前記ソースリストを伝達する手段と、
前記ソースリスト上に登録された前記取得源の各々のステイタスをベリファイする手段であって、前記取得源の各々の前記ステイタスはアクティブか非アクティブかのいずれかであるベリファイ手段と、
そこから非アクティブのステイタスを有する取得源を除去することにより前記ソースリストをアップデートする手段と、
前記アップデートされたソースリストを複数のデータリクエスタシステムの各々に伝達する手段とを包含しており、
さらに当該管理システムは、前記ＲＴＭＤＯＤサーバで前記データリクエスタシステムからのデータリクエストを受理する手段であって、当該データリクエストはそこからデータが供給される取得源の組の中にある第１の取得源を認識するようになっているデータリクエスト受理手段と、
前記データリクエストに応答して前記ＲＴＭＤＯＤサーバからのデータ取得リクエストを第１の取得源へと伝達する手段と、
前記データ取得リクエストに応答して前記第１の取得源でデータの伝達を開始する手段とを包含しているデータ取得源管理システム。
【請求項１６】
請求項１５記載のデータ取得源管理システムであって、さらに、前記データリクエスタシステムから前記ＲＴＭＤＯＤサーバによって受理されたデータリクエストに応答して、前記ＲＴＭＤＯＤサーバから前記データリクエスタシステムへとデータレスポンスを供給する手段を包含しているデータ取得源管理システム。
【請求項１７】
請求項１５記載のデータ取得源管理システムであって、前記ＲＴＭＤＯＤサーバに連結された１組の取得源を認識するための手段が、
前記１組の取得源からの登録データを前記ＲＴＭＤＯＤサーバへと伝達する手段と、
前記１組の取得源からの登録データを前記ＲＴＭＤＯＤサーバによってベリファイする手段と、
前記１組の取得源を前記ソースリスト上に登録し、その登録データを、登録された１組の取得源に対応するように、ベリファイされた前記登録データに応答してソースデータベース上に貯蔵する手段とを包含しているデータ取得源管理システム。
【請求項１８】
請求項１６記載のデータ取得源管理システムであって、前記ＲＴＭＤＯＤサーバから前記データリクエスタシステムへとデータレスポンスを供給する手段が、
前記ＲＴＭＤＯＤサーバから前記データリクエスタシステムにデータを伝達する手段であって、前記データは前記データリクエストにより指示されかつ前記データリクエストに応答する前記１組のデータ取得源の少なくとも１つによって供給されるようになっているデータ伝達手段を包含しているデータ取得源管理システム。
【請求項１９】
請求項１８記載のデータ取得源管理システムであって、対応する少なくとも１つの取得源から前記ＲＴＭＤＯＤサーバへと伝達されるデータが、続いてそこからリアルタイムで前記データリクエスタシステムによって受理されるようになっているデータ取得源管理システム。
【請求項２０】
請求項１６記載のデータ取得源管理システムであって、さらに、前記ＲＴＭＤＯＤサーバから前記第１の取得源へと前記データ取得リクエストが伝達されるのに続いてデータ伝達エラーが起こった際に、そのデータリクエストに応答して前記ＲＴＭＤＯＤサーバにより前記データリクエスタシステムへとエラーメッセージを供給する手段を包含しているデータ取得源管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ取得源（data acquisition source ）管理方法に関する。特に、本発明は、マルチメディアデータの取得源を中央で管理し、各種のチャンネルや、セルラーＭＭＳ（Multimedia Messaging Service）及びインターネットを含む伝送媒体などの取得源からリアルタイムでキャプチャされたマルチメディアデータを分配するためのデータ取得源管理システムを構築するためのデータ取得源管理方法に係るものである。
【背景技術】
【０００２】
リアルタイムマルチメディアデータオンデマンド（ＲＴＭＤＯＤ）システム、例えばインターネットをベースとしたリアルタイムマルチメディアデータオンデマンドシステムは、コンピュータに接続された画像や音響の取得源を基礎としており、コンピュータはインターネット接続網を介してサーバに直接的に接続され、そのサーバはインターネット上の取得源によって取得されたマルチメディアデータを分配する能力を有している。
【０００３】
従来、リアルタイムマルチメディアデータオンデマンドシステムにおける取得源から取得されたマルチメディアデータの分配は、サーバに献身的に接続された永続的なＦＴＰ（File Transfer Protocol）のような手段によって遂行されてきた。取得源は、ＦＴＰ接続を介してサーバ上に貯蔵されるべく、取得されたデータを連続的に伝達している。データへのリクエストが受理されると、サーバに貯蔵されていたデータはリクエストした源へと分配されていく。
【０００４】
上述した方法の１つの欠点は、取得源が、データを貯蔵すべきサーバへと連続的にデータを送り続けているので、広範な帯域幅を必要とすることである。さらに、リクエストによって取り出されたデータは、取得源のステイタス（現況）が連続的にモニターされているとは限らないので、それがリアルタイムであるという保証がないことである。また、取得源がデータを取り出したり伝達したりできるように、従来のシステムを用いてセットアップするためには、特別なソフトウェアが必要とされる。さらに、それらのシステムの遂行はしばしば複雑であり、サーバへの接続をセットアップする作業が複雑であるため、ネットワークのプロトコルにおける技術的知識や達人を必要とし、それらは平均的なインターネットユーザーの能力や知識や忍耐を超えたものになることがある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従って、明らかに、データ取得源を管理するための方法が必要となり、従来のリアルタイムマルチメディアデータオンデマンドシステムの前述した欠点を解決できるようなシステムが必要とされるのである。
【０００６】
本発明は、データ取得源を中央で管理し、取得されたリアルタイムマルチメディアデータを中央で分配するためのシステム及び方法に向けられている。本発明の１つの実施態様では、複数の取得源のためのクライアントサーバモデルを用いて、中央サーバの制御下で独立して機能するような方法が提供される。
【０００７】
本発明はデータ取得源の管理方法に関する。特に、本発明は、マルチメディアデータの取得源を中央で管理し、各種のチャンネルや、セルラーＭＭＳ（Multimedia Messaging Service）及びインターネットを含む伝送媒体などの取得源からリアルタイムでキャプチャされたマルチメディアデータを分配するためのデータ取得源管理システムを構築するためのデータ取得源管理方法に係るものである。データ取得源は、インターネットに固定電線で接続されているか無線で接続されているか、あるいは二者択一的にインターネットプロトコルが可能となるネットワークに接続されているかどうかは無関係であり、データ取得源のステイタスをモニターするサーバのための中央サーバに登録されており、最小限のセットアップと構成を伴い、著しく削減された入手可能な帯域幅を利用して、登録されたいかなる取得源からも、直接的に、リアルタイムデータに対するリクエストを許容するようになっている。
【課題を解決するための手段】
【０００８】
従って、本発明は第１の面において、取得源を管理するためのデータ取得源管理方法を開示する。このデータ取得源管理方法は複数の工程を包含しており、それらは、
リアルタイムマルチメディアデータオンデマンド（ＲＴＭＤＯＤ）サーバにより少なくとも１つの取得源を包含するソースリスト（取得源一覧表）を生成する工程であって、当該ソースリストに包含される少なくとも１つの取得源の各々がそこからデータを供給するために用いられかつ前記ＲＴＭＤＯＤサーバとデータ通信できるようになっているようなソースリスト生成工程と、
前記ソースリストをデータリクエスタシステムに供給する工程であって、このソースリストは当該データリクエスタシステムからのリストリクエストを受けたＲＴＭＤＯＤサーバが応答してＲＴＭＤＯＤサーバにより供給されるようになっており、前記データリクエスタシステムは前記ＲＴＭＤＯＤサーバとデータ通信できるようになっているようなソースリスト供給工程と、
前記ＲＴＭＤＯＤサーバにより前記データリクエスタシステムからデータリクエストを受理する工程であって、このデータリクエストは前記ソースリストに登録されかつそれにより指示されている少なくとも１つのデータ取得源の１つ又は複数からのデータのためのリクエストであるようなデータリクエスト受理工程とを包含している。
【０００９】
さらに、本発明は第２の面において、取得源を管理するためのデータ取得源管理システムを開示する。このデータ取得源管理システムは複数の手段を包含しており、それらは、
リアルタイムデータオンデマンド（ＲＴＭＤＯＤ）サーバにより少なくとも１つの取得源を包含するソースリスト（取得源一覧表）を生成する手段であって、当該ソースリストに包含される少なくとも１つの取得源の各々がそこからデータを供給するために用いられかつ前記ＲＴＭＤＯＤサーバとデータ通信できるようになっているようなソースリスト生成手段と、
前記ソースリストをデータリクエスタシステムに供給する手段であって、このソースリストは当該データリクエスタシステムからのリストリクエストを受けたＲＴＭＤＯＤサーバが応答してＲＴＭＤＯＤサーバにより供給されるようになっており、前記データリクエスタシステムは前記ＲＴＭＤＯＤサーバとデータ通信できるようになっているようなソースリスト供給手段と、
前記ＲＴＭＤＯＤサーバにより前記データリクエスタシステムからデータリクエストを受理する手段であって、このデータリクエストは前記ソースリストに登録されかつそれにより指示されている少なくとも１つのデータ取得源の１つ又は複数からのデータのためのリクエストであるようなデータリクエスト受理手段とを包含している。
【００１０】
本発明の実施態様が添付図面に示されている。図１は本発明の１つの実施態様によるデータ取得源管理方法のプロセスを表す流れ図である。図２は図１のデータ取得源管理方法を遂行するためのデータ取得源管理システムの第１のレイアウトを表す概略図である。図３は図１のデータ取得源管理方法の工程でソースリストを生成するプロセスの流れ図である。図４は図１のデータ取得源管理方法の工程でソースリストを流布するプロセスの流れ図である。図５はデータ取得源管理システムのリアルタイムマルチメディアデータオンデマンド（ＲＴＭＤＯＤ）サーバのシステムを表す概略図である。図６は図２の取得源管理システムの第２のレイアウトを表す概略図である。
【発明を実施するための最良の形態】
【００１１】
上述した問題を解決するためのデータ取得源管理方法について説明する。
【００１２】
本発明の１つの実施態様について、図１を参照しながら、データ取得源管理方法１００を遂行するための図２に示すデータ取得源管理システム２０について説明する。図１においてデータ取得源管理方法１００のプロセスの流れ図が示され、図２はデータ取得源管理システム２０の第１のレイアウトを示している。
【００１３】
図２において、データ取得源管理システム２０は、リアルタイムマルチメディアデータオンデマンド（ＲＴＭＤＯＤ）サーバシステム２２、複数のデータリクエスタシステム２４（データ要求者としても知られている）、及び複数のデータ取得源２６を包含している。ＲＴＭＤＯＤサーバと複数のデータリクエスタシステム２４と複数の取得源２６とは、ネットワークシステム２１によって相互に接続されている。ネットワークシステム２１は、インターネット、イントラネット（社内通信網）、セルラーマルチメディアメッセージングサービスシステム（携帯電話通信網）、あるいは類似の通信インフラストラクチュア（無線ＬＡＮその他の各種通信網）とすることができる。
【００１４】
ＲＴＭＤＯＤサーバシステム２２のアーキテクチュア（基本構造）はクライアントサーバモデルに従っており、そこではマルチプルクライアントが中央サーバの制御の下で独立して機能し、データリクエスタ２４と取得源２６はクライアントであり、ＲＴＭＤＯＤサーバシステム２２は中央サーバとして備えられている。
【００１５】
取得源２６はそこからデータを出す創作源である。取得源２６のハードウェアとＲＴＭＤＯＤサーバ２２とのインターフェースを受け持つように、ソフトウェアプログラムがカスタマイズされている。
【００１６】
データ取得源管理方法１００は取得源２６を管理するものでもある。データ取得源管理方法１００において、ＲＴＭＤＯＤサーバ２２はソースリスト（図示せず）を生成し、このソースリストには、図１に示す工程１０２で入手可能な取得源の数量が包含される。入手可能な取得源の数は、ゼロ・１つあるいは複数である。ソースリストに包含される取得源２６はそこからデータを供給するためのものである。取得源２６はＲＴＭＤＯＤサーバ２２とデータを相互に通信しあうようになっている。
【００１７】
それからソースリストは、工程１０４でデータリクエスタ２４へと供給され、データリクエスタ２４からのリストリクエストを受理したＲＴＭＤＯＤサーバに応答して供給されることになる。データリクエスタ２４はＲＴＭＤＯＤサーバ２２とデータを相互に通信しあうようになっている。いったんソースリストがデータリクエスタ２４へと流布されると、ＲＴＭＤＯＤサーバ２２は、図１の工程１０６においてデータリクエスタ２４からのデータリクエストを受理できるようになる。データリクエスト（図示せず）は、ソースリスト上に登録されている入手可能な取得源２６の１つあるいは複数からのデータに対するリクエストである。
【００１８】
工程１０６でＲＴＭＤＯＤサーバ２２によって受理されたデータリクエストに応答して、ＲＴＭＤＯＤサーバ２２は、後述する工程１０８においてデータレスポンスをデータリクエスタ２４へと供給するための準備をする。データリクエストはデータリクエスタ２４とは独立して開始されたり、あるいは外部の刺激によって開始されることもでき、例えば、ユーザーからの移動電話で生成されるＳＭＳ（信号）によって、あるいはユーザーからの電子メールや類似の活性化された信号によって開始されることもできる。
【００１９】
工程１０２において、ソースリストが生成され、１つ又は複数の取得源がＲＴＭＤＯＤサーバ２２に登録されたときにアップデート（更新）される。登録は、各取得源２６のスタートアップ（開始準備）を受けて開始される。工程１０２で、登録データ（図示せず）は取得源２６から図３の工程１２０におけるＲＴＭＤＯＤサーバ２２へと伝達される。図３はソースリストを生成するプロセスの流れ図である。それから登録データは図３の工程１２２においてＲＴＭＤＯＤサーバによってベリファイ（（確証）される。いったん登録データが工程１２２でベリファイされると、取得源２６は、工程１２４においてソースリスト上に最終的に登録され、取得源２６に対応する登録データがソースデータベース（図示せず）上に貯蔵される。
【００２０】
図４は図１の工程１０４におけるソースリストを流布するプロセスの流れ図である。工程１０４において、最初にログインデータが、データリクエスタ２４から図４の工程１３０におけるＲＴＭＤＯＤサーバ２２へと伝達される。図４において、ログインデータはデータリクエスタ２４に記入されるためにＲＴＭＤＯＤサーバ２２内へと供給される。工程１３０でログインデータが受理されるのに応答して、データリクエスタは工程１３２のリクエスタリスト（図示せず）上に登録される。リクエスタリストは少なくとも１つのデータリクエスタ２４を含む。いったんデータリクエスタがＲＴＭＤＯＤサーバ２２上に登録され、あるいは記入されると、ソースリストはＲＴＭＤＯＤサーバ２２から工程１３４における対応するデータリクエスタ２４へと伝達される。
【００２１】
しかしながら、ある時間間隔の後で、１つ又は複数の取得源２６を非アクティブ（不活性）にすることもできる。従って、ソースリストにおける各取得源２６のステイタス（現況）はコンスタントにチェックする必要がある。各取得源２６のステイタスはアクティブ（活性）か非アクティブ（不活性）かのいずれかである。さらに工程１０４において、各取得源２６のステイタスは、工程１４０において周期的にベリファイされる。他の方法として、各取得源２６のステイタスは、対応する取得源２６がステイタス信号をＲＴＭＤＯＤサーバ２２へと周期的に送っているかどうかによって、さらにベリファイすることができる。
【００２２】
上述した周期的なベリファイ工程は、ＲＴＭＤＯＤサーバ２２から取得源２６へとあるいはその反対方向に（図示せず）ステイタスリクエスト信号が、心臓の鼓動のように脈打つのに類似している。ステイタス信号のやりとりが行われているときに、取得源２６から所定の時間間隔内にステイタス信号が受理されない場合は、対応する取得源２６のステイタスが非アクティブであるとしてアップデート（更新）され、それから対応する取得源２６は工程１４２でソースリストから削除され、これによりソースリストがアップデートされる。工程１４２でソースリストがアップデートされることにより、ＲＴＭＤＯＤサーバ２２上に記入されている全てのデータリクエスタ２４へと更新されたソースリストが再伝達され、工程１４４でリクエスタリスト上に登録される。取得源２６のステイタス確証は、取得源２６がダイナミックに割り当てられるＩＰアドレスを用いている状況下で好適なものとなる。
【００２３】
工程１０６でのデータリクエスタ２４からのデータリクエスタを受けて、ＲＴＭＤＯＤサーバ２２は、図１の工程１０８で述べたようにして、データレスポンスを用意し伝達する。工程１０８において、リクエストされたデータは、ＲＴＭＤＯＤサーバ２２からデータリクエスタ２４へと伝達される。しかし、これが起こる前に、データ（図示せず）を取得するために、１つのリクエストが対応する取得源２６へと送られたとする。対応する取得源２６からＲＴＭＤＯＤサーバ２２によって受理されたデータは、それからリアルタイムでデータリクエスタ２４へと伝達され、このデータはマルチメディアデータとすることができる。他の方法として、データの伝達前あるいは伝達中にエラーが発生した場合は、エラーメッセージがデータレスポンスとして送られる。
【００２４】
ＲＴＭＤＯＤサーバによるデータリクエストとデータレスポンスは、連続的なものであることが望ましい。いったん１つのデータが送られると、ＲＴＭＤＯＤサーバ２２は、最初のデータリクエストに対するデータレスポンスが受理されるまでは、他のデータリクエストを送ろうとはしない。これはＲＴＭＤＯＤサーバ２２が取得源２６にオーバーロードをかけるのを避けるためであり、取得源２６は限定されたネットワーク能力とコンピュータ能力しか持っていないかもしれないからである。しかしながら、ＲＴＭＤＯＤサーバ２２は、データリクエスタ２４から多数の取得源へと同時に多数のデータリクエストを供給する能力を有している。
【００２５】
いったんデータリクエストに対応するデータがデータリクエスタ２４によって完全に受理されると、データリクエスタ２４はＲＴＭＤＯＤサーバ２２からログアウトするプロセスに入ることができる。データリクエスタ２４からのログアウト指令がいったん受理されると、ＲＴＭＤＯＤサーバ２２は対応するデータリクエスタ２４をリクエスタリストから除去するプロセスに入る。このことは、ソースリストがアップデートされるときはいつでもＲＴＭＤＯＤサーバ２２によってアップデートされるべきデータリクエスタ２４の数量を減少させることになる。
【００２６】
好適には、ＲＴＭＤＯＤサーバ２２は４つのサブシステムを包含している。それらは、ベリファイする（確証用）サブシステム３０、データを取り込む（導入用）サブシステム３２、データを発送するサブシステム３４、そしてデータ源を管理するサブシステム３６である。これら４つのサブシステムは図５に示され、図５はＲＴＭＤＯＤサーバ２２のシステムを表現する概略図である。ベリファイ用サブシステム３０は、ソースリストに含まれる取得源２６のステイタスをベリファイしアップデートするためのものである。データ導入用サブシステム３２は、データリクエスタ２４からのデータリクエストを受理した際に、取得源２６からのデータの回復を管理するためのものである。データ発送用サブシステム３４は、データリクエスタ２４との通信及びデータ伝達を管理するためのものである。データ源管理用サブシステム３６は、ソースリスト及びリクエスタリストを管理しかつ更新するためのものである。
【００２７】
データ取得源管理システム２０は、現在のリアルタイムマルチメディアデータオンデマンドシステムを改良することができる。なぜなら、それは取得源２６、例えばビデオ２６ａ、オーディオ２６ｂ（図６）あるいは他のメディアタイプが、接続のタイプやファイヤウォールのようなセキュリティ手段の存在にもかかわらず、ＲＴＭＤＯＤサーバ２２と接続しかつ登録することを可能にするからである。好適には、取得源２６は現存するデバイスドライバだけを用いて、例えば特別に取得しなければならないソフトウェアの代わりにＴＷＡＩＮドライバを用いるデジタルカメラを使って、データ取得源管理システム２０を構成し、デバイスに依存することなく、設置及び構成の複雑さを著しく減少させるようなシステムにすることが望ましい。
【００２８】
従来のシステムと比較して、本発明は最小の帯域幅だけしか必要としない。なぜなら、データ取得源管理システム１００は、ＲＴＭＤＯＤサーバ２２の内部にデータを貯蔵するために取得源が連続してデータをＲＴＭＤＯＤサーバに伝達している必要がないからである。データのリクエスト及び伝達は、データリクエスタからリクエストがなされた時だけ発生するのであり、帯域幅の使用は大幅に削減されるからである。
【００２９】
上述した説明において、データ取得源管理システムを遂行するためのデータ取得源管理方法は、従来の取得源管理システムが有する前述した欠点を解決するための本発明の実施態様に従って記述された。本発明はその範囲及び精神から離れることなく多くの変形及び修正を加えることができることは当業者であれば理解できることは明らかであろう。
【図面の簡単な説明】
【００３０】
【図１】本発明の１つの実施態様によるデータ取得源管理方法のプロセスを表す流れ図。
【図２】図１のデータ取得源管理方法を遂行するためのデータ取得源管理システムの第１のレイアウトを表す概略図。
【図３】図１のデータ取得源管理方法の工程でソースリストを生成するプロセスの流れ図。
【図４】図１のデータ取得源管理方法の工程でソースリストを広めるプロセスの流れ図。
【図５】データ取得源管理システムのＲＴＭＤＯＤサーバのシステムを表す概略図。
【図６】図２の取得源管理システムの第２のレイアウトを表す概略図。
【符号の説明】
【００３１】
２０  データ取得源管理システム
２２  ＲＴＭＤＯＤサーバ
２４  データリクエスタ
２６  取得源
１００  データ取得源管理方法
１０２  ソースリスト生成工程
１０４  ソースリスト流布工程
１０６  データリクエスト受理工程
１０８  データレスポンス供給工程
【図１】
0004510632.tif 000002
【図２】
0004510632.tif 000003
【図３】
0004510632.tif 000004
【図４】
0004510632.tif 000005
【図５】
0004510632.tif 000006
【図６】
0004510632.tif 000007