JP2006507737A

JP2006507737A - Ｗｅｂページを介してメディア・ファイルにアクセス可能にするための方法よび装置

Info

Publication number: JP2006507737A
Application number: JP2004554265A
Authority: JP
Inventors: ブライッター、ゲルト; ヴァーグナー、ヘンドリック
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-11-26
Filing date: 2003-07-22
Publication date: 2006-03-02
Anticipated expiration: 2023-07-22
Also published as: TW200421128A; EP1570385A2; CN1695143A; WO2004049205A2; WO2004049205A3; US20060015581A1; AU2003254561A1; JP4600849B2; TWI238951B; US7711843B2

Abstract

【課題】インターネットにおいてリッチ・メディア・コンテンツを提供する手順を容易にする方法およびシステムを提供すること。
【解決手段】第１の態様は、Ｗｅｂページを介してメディア・ファイルにアクセス可能にするための方法および装置に対処する。第１にＷｅｂ設計ツールは、Ｗｅｂページを介してアクセス可能にするメディア・ファイルを受信する。次に、前記メディア・ファイルはストリーミング・サービス・プロバイダに送信される。その後、前記送信されたメディア・ファイルを明瞭に識別できるようにする、前記ストリーミング・サービス・プロバイダによって生成されたキーが受信され、前記キーから導出された識別子はメディア・ファイルにアクセスする際に通過するＷｅｂページ内に配置される。第２の態様は、要求に応じてビジターのコンピュータにストリーミングされるメディア・ファイルをホストするためにユーザの要求を処理するための、ストリーミング・サービス・プロバイダ側にインストールされた方法および装置に対処する。

Description

本発明は、一般に、リッチ・メディアにインターフェースしているＷｅｂページを自動的に生成するための環境に関する。具体的に言えば、本発明は、Ｗｅｂページを介してメディア・ファイルにアクセス可能にするための方法および装置を提供することに関し、それに対応して、ビジターの要求に応じてビジターのコンピュータにストリーミングされることになるメディア・ファイルをホストするための要求を処理するために、ストリーミング・サービス・プロバイダ側にインストールされた方法および装置に関する。

リッチ・メディア・データは、イメージ、動画、音声、オーディオ、およびビデオを組み込むことによって、人間およびコンピュータの対話のために、従来のコンピュータ・データのフォーマットをより自然なデータ・フォーマットに拡張する。マーケット、ビジネス、社会、および技術の景気先行指標は、こうしたデジタル記録コンテンツの重要性が増大していることを示している。

さらにリッチ・メディア・データは、インターネット・アプリケーションにおいてますます広く普及してきている。これらすべてのインターネット・アプリケーションは、異なる要件および用途を有するが、すべて同様のコンテンツ・データで動作している。こうした事実により、インターネット・アプリケーションは実に複雑になってきており、個々の要件に合わせて簡単にカスタマイズすることはできない。

しかしながら、リッチ・メディア・データに伴う主要な問題の１つは、ネットワークを介して莫大な量のデータを転送することである。過去には、データは蓄積交換パラダイムを使用して転送、すなわち完全なコンテンツが転送された後にデータが提示された。このパラダイムの著名な実施が、ＷｏｒｌｄＷｉｄｅＷｅｂ全体にわたってファイルを転送する標準的な方法の１つであるファイル転送プロトコル（ＦＴＰ）である。従来のデータの場合、転送されるデータの量が比較的少ないためこれは良好に働く。しかしながら、オーディオおよびビデオ・クリップの場合、レンダリングの要求からレンダリングの開始までの待ち時間は非実用的に長くなる。

数年前、ストリーミングと呼ばれるパラダイムが登場した。ストリーミングでは、メディアのレンダリングをそのコンテンツの転送と並行して実行することが可能となり、待ち時間が最低限まで削減される。ソフトウェアのストリーミングは、常に、ネットワークを介して常時データを送り出すストリーム・サーバとデータを受信してこれをレンダリングするプレーヤとのペアで行われる。

プレーヤは、常にストリーミング・データ接続を要求する側である。クライアントはこうした接続を確立しながら、いわゆるメタ・データをストリーム・サーバに送信し、これが要求されたリッチ・メディア・データ・オブジェクトを識別する。一般に、ストリーム・サーバはメタ・データを使用してそのキャッシュ内でリッチ・メディア・オブジェクトを見つけるが、メタ・データはアクセス・チケット、帯域幅情報、メディア内のオフセットなどの他の情報も含むことができる。

一般にストリーム持続時間全体にわたってネットワークに必要な帯域幅を書き込むことができることを意味する、データ・ストリームの品質を保証するために、現在のストリーム・サーバはリッチ・メディア・データ・オブジェクトをローカル・ファイル・システム上に常駐させる必要がある。したがって、リッチ・メディア・データ・オブジェクトのストリーミングを望むあらゆるストリーム・サーバは、そのローカル・ディスク・キャッシュ内にコピーを維持しなければならない。さらにストリーム・サーバは、ＣＰＵ、メモリ、ディスクＩ／Ｏ機能、ネットワーク接続などの使用可能なシステム・リソースを認識していなければならない。新しいストリーミング要求がそのリソースの１つを超える場合、確立されたデータ・ストリームの品質を保証するためにその要求は拒否されなければならない。

インターネットのような分散型シナリオでは、ストリーム・サーバとプレーヤとの間の距離が長い可能性がある。データは、全体の帯域幅が予測不可能な状態で未知数のノードを介して転送しなければならない。この種の問題を解決するために、いわゆるエッジ・サーバが確立される。

前述のように、現在のインターネット・アプリケーション内でリッチ・メディア・データを組み合わせることが必要または提案されるサービスが適用された、リッチ・メディア・コンテンツ・データを使用することによって、作成および構成要件はますます複雑になる。さらに、これらのリッチ・メディア・インターネット・アプリケーションが市場に出るまでの時間がますます短くなり、世界中からアクセスされるこれらのインフラストラクチャおよび管理要求を非常に短い期間で処理することが要求される。

上記の説明からわかることは、リッチ・メディア・サービスが非常に複雑なインフラストラクチャを必要とすることである。受け入れ可能なメディア・ストリーミング・サービスを得るためには、短いアクセス待ち時間を可能にする、莫大な量の分散型サーバ（エッジ・サーバ）、ホスト側のプロキシ・サービス、配布およびキャッシュ・サービス、ストリーミング・サービス、請求サービス、広告サービス、および課金サービスが必要である。

２４／７ＱＯＳを使用してこのインフラストラクチャの構築、動作、および維持することは非常に複雑かつ費用がかかるものであり、高度な技術を備えた操作員が必要である。インターネットにおける現在のリッチ・メディアに必要なインフラストラクチャ全体は、非常に高価なものである。一部のビジネス・モデルでは、これがこれらのメディア提供を使用するユーザにとって受け入れ難い経費となっている。

したがって現在では、ストリーム・サーバ、エッジ・サーバなどのストリーミング用のすべてのインフラストラクチャを設置および維持する必要なしに、リッチ・メディアを自社のエンド・ユーザにストリーミングすることを希望する会社にメディア・サービスを提供するシステムが登場している。リッチ・メディアを自社のＷｅｂサイトに含めることを希望する会社は、好ましくはＳＯＡＰ／ＸＭＬなどのインターフェースの助けを借りて、標準化されたＷｅｂサービスを単に呼び出すだけでメディアをアップロードすることができる。そのメディアを参照するキーが戻され、会社は次の段階としてＣＧＩスクリプトまたはサーブレットを自社のＷｅｂサイトに含め、これが第２のＷｅｂサービスと対話して、ＣＧＩスクリプトまたはサーブレットがリッチ・メディアを要求しているエンド・ユーザのブラウザに送信しなければならないいわゆるメタ・データを獲得し、その結果、ブラウザは最終的にメディア・サービスと接触して、自分のシステムにストリーミングされる要求されたコンテンツを獲得することができる。

上記の内容からわかることは、たとえメディア・サービスが使用される場合であっても、リッチ・メディアを含めることはＷｅｂ設計者にとってかなり複雑だと言うことである。特定のサーブレットまたはＣＧＩスクリプトをプログラミングしてＨＴＭＬページに含めなければならず、Ｗｅｂページの設計者は、ストリーミング技術、メタ・メディアおよびその所有権を主張できる形式、ＳＯＡＰおよび他のメディア関連領域について知らなければならない。

以上の点から、本発明の目的は、インターネットにおいてリッチ・メディア・コンテンツを提供する手順を容易にする方法およびシステムを提供することである。

前述の目的は、独立請求項に記載された方法およびシステムによって達成される。本発明の他の有利な実施形態は従属請求項に記載され、以下の説明で教示される。

本発明の第１の態様によれば、Ｗｅｂページを介してメディア・ファイルにアクセス可能にするための方法および装置が提供され、これによってメディア・ファイルは、すべてがネットワークを介して到達可能な要求に応じてストリーミング・サービス・プロバイダからビジターのコンピュータへとストリーミングされる。第１にＷｅｂ設計ツールは、Ｗｅｂページを介してアクセス可能にするメディア・ファイルを受信する。次に、前記メディア・ファイルはストリーミング・サービス・プロバイダに送信される。その後、前記送信されたメディア・ファイルを明瞭に識別できるようにする、前記ストリーミング・サービス・プロバイダによって生成されたキーが受信され、前記キーから導出された識別子はメディア・ファイルにアクセスする際に通過するＷｅｂページ内に配置される。

本発明の第２の態様は、要求に応じてビジターのコンピュータにストリーミングされるメディア・ファイルをホストするためにユーザの要求を処理するための、ストリーミング・サービス・プロバイダ側にインストールされた方法および装置に対処する。初めに、ストリーミングされるメディア・ファイルがストリーミング・サービス・プロバイダによってユーザから受信される。次にメディア・ファイルが格納され、前記受信されたメディア・ファイルを明瞭に識別できるようにするキーが準備される。その後、このキーがユーザに送信される。

言い換えれば、本発明の観念は、自分のＷｅｂサイトをリッチ・メディア・コンテンツで豊かにしなければならないユーザに、使いやすいインターフェースを提供し、サービスの提供を希望するストリーミング・サービス・プロバイダに、それぞれの手順を提供することである。

メディア・ファイルをＷｅｂページに配置するための方法を呼び出すことで、メディア・ファイルがストリーミング・サービス・プロバイダのメディア・データベースにアップロードされる。このコンテンツを参照するキーがストリーミング・サービス・プロバイダから戻される。こうしたアップロード呼び出しは、たとえばＳＯＡＰインターフェースを介して実施することができる。

アップロードされたコンテンツを参照するために、このキーを使用してｈｔｍｌファイルが生成される。これは、ユーザのＷｅｂサイトからのリッチ・メディアのストリームを希望するビジター・コンピュータのブラウザ／プレーヤが必要とする要求された情報を生成するために必要なすべてのアクションを実行する、たとえばＣＧＩまたはサーブレットの呼び出しを含むことができる。これはたとえば、必要なメタ・ファイルを獲得するための、ストリーミング・サービス・プロバイダへのＳＯＡＰ呼び出しの発行とすることができる。Ｗｅｂ設計ツールは、ｈｔｍｌページ中に生成されたｈｔｍｌファイルへのリンクを追加することができる。

ビジターがユーザのＷｅｂサイトを訪問し、メディアを再生するためにリンクをたどる（生成されたデータがビジターのブラウザに返送される）と必ず、ブラウザが生成されたメタ・ファイルを読み取り、適切な制御情報を使用してプレーヤをオープンすることから、プレーヤは正しいストリーム・サーバに接触して即時に再生を開始することができる。

本発明に関して説明されるツールは、要求されるインフラストラクチャに関して何も知る必要なしに、リッチ・メディアをユーザまたは会社のＷｅｂサイトに組み込むプロセスを容易にするために、ＩＢＭ (IBM Corporationの商標）コーポレーションによるＷｅｂＳｐｈｅｒｅ (IBM Corporationの商標）Ｓｔｕｄｉｏなどの様々なＷｅｂ設計ツールに組み込むことが可能である。

しかしながらこれは、上記のＷｅｂサービスで使用できるだけでなく、ＩＢＭコーポレーションによるＷｅｂＳｐｈｅｒｅ (IBM Corporationの商標）または他のＷｅｂアプリケーション・システムなどの製品が供給およびインストールされた、ストリーミング・サービス・プロバイダのインフラストラクチャを利用しやすくするためにも使用することができる。

時が経つにつれてリッチ・メディア向けのＷｅｂサービスがますます多く登場した場合、指定されたリッチ・メディアのＷｅｂサービスに動的に到達して最も適切なサービスを自動的に選択し、選択されたサービスの必要なインターフェースに関する知識を獲得し、そのインターフェースを実現するために正しいパラメータを自動的に生成するために、これらのツールは「イエロー・ページ」、すなわちＵＤＤＩなどのディレクトリ・サービスを使用するように拡張することができる。

本発明の上記ならびに追加の目的、特徴、および利点は、以下の詳細に記載された説明で明らかになろう。

本発明の新規な特徴は添付の特許請求の範囲に示される。しかしながら本発明自体ならびにその好ましい使用様式、他の目的、および利点については、添付の図面と共に例示的な実施形態の以下の詳細な説明を参照することによって最もよく理解されるであろう。

図１を参照すると、本発明に従った方法および装置が使用可能な環境１００を示すブロック図が示されている。Ｗｅｂスペース・プロバイダ１０２、ユーザのコンピュータ１０４、ストリーミング・サービス・プロバイダ１０６、サービス・ディレクトリ１０８、およびビジターのコンピュータが、インターネットなどのネットワーク１１２に接続されている。

Ｗｅｂスペース・プロバイダ１０２は、たとえばｈｔｍｌ（ハイパー・マークアップ言語）で書かれたインターネット・ページをホストするようにユーザに勧める。これはＷｅｂサーバ１２０およびデータ・ストレージ１２２を有する。Ｗｅｂサーバ１２０はホストされたページをビジターのコンピュータ１１０などの要求側に送達する。インターナショナル・ビジネス・マシンズ・コーポレーションによるＷｅｂサーバＷｅｂＳｐｈｅｒｅ、ＴｈｅＡｐａｃｈｅＳｏｆｔｗａｒｅＦｏｕｎｄａｔｉｏｎによるＷｅｂサーバＡｐａｃｈｅ、またはＢＥＡＳＹＳＴＥＭＳ，ＩＮＣによるＷｅｂサーバＷｅｂｌｏｇｉｃが、Ｗｅｂサーバを実現することができる。データ・ストレージ１２２はホストされたページを維持する。これは、インターナショナル・ビジネス・マシンズ・コーポレーションによるＤＢ２などのデータ・ベース・システム、またはＯｒａｃｌｅＣｏｒｐｏｒａｔｉｏｎまたはＳｙｂａｓｅＩｎｃによるデータ・ベース・システムを使用して実施することができる。

ユーザのコンピュータ１０４は、Ｗｅｂ設計ツール１３０、少なくとも１つのメディア・ファイル１３２、および少なくとも１つのｈｔｍｌファイル１３４を含む。Ｗｅｂ設計ツール１３０は、ＩＢＭコーポレーションによるＷｅｂＳｐｈｅｒｅＳｔｕｄｉｏによって形成することができる。

ストリーミング・サービス・プロバイダ１０６は、たとえばインターネットなどのネットワーク１１２を介してメディア・ファイルのストリーミングを処理するようにユーザに勧める。

ストリーミング・サービス・プロバイダ１０６にインストールされたＩＢＭのＶｉｄｅｏＣｈａｒｇｅｒ、ＲｅａｌＮｅｔｗｏｒｋｓ，ＩｎｃによるＲｅａｌＳｅｒｖｅｒ、またはＡｐｐｌｅＣｏｍｐｕｔｅｒｓＩｎｃ，によるＱｕｉｃｋｔｉｍｅストリーム・サーバなどのストリーミング・サーバ１４０は、ストリーミング自体を実行する。さらにストリーミング・サービス・プロバイダ１０６は、顧客ケアおよび請求ユニット１４２ならびにストレージ・サブシステム１４４を有する。顧客ケアおよび請求ユニットは、ストリーミング・サービス・プロバイダ１０６によって提供されるサービスに関する支払い手続を処理する。これは、クレジット・カードまたはデビット・カードの支払いを受け入れるように構成することができる。ストレージ・サブシステム１４４は、たとえばインターネットなどのネットワーク１１２を介してビジターのコンピュータ１１０などの要求側にストリーミングされるメディア・ファイルを維持する。

サービス・ディレクトリ１０８は、Ｗｅｂサービス・プロバイダとそれぞれの顧客との間でブローカとして働く、ＵＤＤＩディレクトリ（ＵｎｉｖｅｒｓａｌＤｅｓｃｒｉｐｔｉｏｎ，ＤｉｓｃｏｖｅｒｙａｎｄＩｎｔｅｇｒａｔｉｏｎ）として実現することができる。Ｗｅｂ設計ツール１３０は、ユーザの要求に応じて、ネットワーク１１２に接続された好適なＷｅｂスペース・プロバイダ１０２または好適なストリーミング・サービス・プロバイダ１０６を探すことができる。次にサービス・ディレクトリ１０８は可能性のリストを提供し、機能、サービス品質、およびコストなどの所与のサービス・プロパティに従って選択することができる。サービス・ディレクトリに含まれるデータベース１５０は、サービスに関する必要な情報を維持する。サービス・ディレクトリ１０８内の好適なプロバイダを探す代わりに、デフォルト・プロバイダまたはユーザが命名したプロバイダを使用することが可能であることが認められる。

ビジターのコンピュータ１１０は、Ｗｅｂスペース・プロバイダ１０２によってホストされ、ストリーミング・サービス・プロバイダ１０６によってストリーミングされる、ユーザのＷｅｂページからのストリーミング・メディア・コンテンツを要求する、たとえばインターネットなどのネットワーク１１２内にある任意数のビジターのマシンを表す。これは、たとえばＭｉｃｒｏｓｏｆｔ(Microsoft Corporationの米国およびその他の国における商標）ＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒまたはＮｅｔｓｃａｐｅＮａｖｉｇａｔｏブラウザによって形成される、要求されたｈｔｍｌページをレンダリングするためのブラウザ１６０と、ＡｐｐｌｅＣｏｍｐｕｔｅｒｓＩｎｃ．によるＱｕｉｃｋｔｉｍｅメディア・プレーヤ、ＲｅａｌＮｅｔｗｏｒｋｓＩｎｃ．によるＲｅａｌＰｌａｙｅｒメディア・プレーヤ、またはＭｉｃｒｏｓｏｆｔＩｎｃ．によるＷｉｎｄｏｗｓ(Microsoft Corporationの米国およびその他の国における商標）ＭｅｄｉａＰｌａｙｅｒなどの、要求されたメディア・ファイルをレンダリングするためのメディア・プレーヤ１６２とを含む。

Ｗｅｂスペース・プロバイダ１０２およびストリーミング・サービス・プロバイダ１０６は、本発明の主題を逸脱することなく１つの単一のエンティティで形成できることに留意されたい。

次に図２を参照すると、ページを開発および設計するため、すなわちインターネットで公開するためにＷｅｂ設計ツールで実施される、本発明に従った方法を示す流れ図が示されている。ユーザは、Ｗｅｂページを閲覧しているビジターがビジターのメディア・プレーヤへのメディア・ファイルのストリーミングを開始できるようにする方法で、メディア・ファイルをＷｅｂページにリンクさせることを望む（ブロック２０２）。第１に、Ｗｅｂ設計ツールはユーザにプロンプトを発行し、メディア・ファイルをページにリンクさせるよう求める（ブロック２０４）。次に、メディア・ファイルが提供されているかどうかを判別する（ブロック２０６）。提供されていない場合は再度求める。Ｗｅｂ設計ツールがアクションを打ち切るため、ステップをやり直すため、アプリケーションを終了するためなど、さらに他の標準機能をユーザに提供することを認める。しかしながら、図が見やすいように、流れ図には本発明およびその好ましい実施形態に密接に関係するステップのみが示されている。

メディア・ファイルが提供されている場合、Ｗｅｂ設計ツールは、使用可能なストリーミング・プロバイダのリストをサービス・ディレクトリから検索する（ブロック２０８）。別の方法として、サービス・ディレクトリにストリーミング・サーバのリストを要求せずに、使用されるＷｅｂ設計ツールの基本設定で好適なストリーミング・サーバを指定することもできる。

例示された方法によれば、Ｗｅｂ設計ツールの基本設定では、デフォルトのストリーミング・サービス・プロバイダが指定され、Ｗｅｂ設計ツールはユーザに対して、指定されたデフォルトのストリーミング・サービス・プロバイダを使用すべきであるか否かを検証するように指示する（ブロック２１０）。Ｙｅｓの場合、Ｗｅｂ設計ツールはメディア・ファイルをストリーミング・サービス・プロバイダに送信する（ブロック２１２）。Ｎｏの場合、ユーザは、サービス・ディレクトリから検索されたリストからストリーミング・サーバを選択するように指示される（ブロック２１４）。この選択プロセスを容易にするために、サービスの価格付けおよび品質などのプロバイダの条件に関する詳細をユーザに表示することができる。その後、１つのストリーミング・サービス・プロバイダが選択されているか否かが判別される（ブロック２１６）。Ｎｏの場合、選択に関する要求が維持される。Ｙｅｓの場合、Ｗｅｂ設計ツールはメディア・ファイルをストリーミング・サービス・プロバイダに送信する（ブロック２１２）。

次に、Ｗｅｂ設計ツールはストリーミング・サービス・プロバイダからキーが戻されるのを待つ。ストリーミング・サービス・プロバイダにアップロードされたメディア・ファイルを明瞭に識別するのに使用可能な任意の識別子が、メディア・ファイルのストリーミングを開始するのに必要なすべての詳細を含むメタ・ファイル、サーブレットすなわちネットワーク・サービスの一部として実行されるＪａｖａ(Sun Microsystemの米国およびその他の国における商標）プログラムへのリンク、またはストリーミング・サービス・プロバイダのストレージ・サブシステム内のメディア・ファイルへの参照などの、キーを形成する。次にこれは、キーが戻されたか否かを判別する（ブロック２２０）。Ｎｏの場合、Ｗｅｂ設計ツールは待機状態のままとなる（ブロック２１８）。Ｙｅｓの場合、メディア・ファイルが起動されるはずであるキーへのリンクまたはキー自体をｈｔｍｌページ内に配置する。ストリーミング・サービス・プロバイダがキーとしてリンクを戻した場合、そのキーはそれ以上修正せずに使用することができる。しかしながら、キーがメタ・ファイルによって形成される場合、代わりに前記ファイルへのリンクをｈｔｍｌページ内に配置することができる。

その後Ｗｅｂ設計ツールは、Ｗｅｂスペース・プロバイダ側のユーザのサイトを更新すべきであるか否かをユーザに指示する。Ｎｏの場合、この手順は終了する（ブロック２２６）。Ｙｅｓの場合、Ｗｅｂ設計ツールは、ユーザのＷｅｂサイトへの変更をアップロードするためにＷｅｂスペース・プロバイダへの接続を確立する（ブロック２２８）。その後この手順は終了する（ブロック２２６）。

図３を参照すると、新規なホスティング要求を受け入れる（ブロック３０２）ためにストリーミング・サービス・プロバイダによって実施される、本発明に従った方法を示す流れ図が示される。初めに、ストリーミング・サービス・プロバイダはストリーミングされるメディア・ファイルをホストするようにというユーザからの新しい要求を待ち（ブロック３０４）、ホスティング要求が受信されたか否かを判別する（ブロック３０６）。Ｎｏの場合、ストリーミング・サービス・プロバイダは待機状態のままとなる（ブロック３０４）。Ｙｅｓの場合、顧客すなわちホスティング・サービスを要求するユーザと請求の詳細が交換される（ブロック３０８）。顧客がストリーミング・サービス・プロバイダの加入者である場合、これにはクレジットまたはデビット・カード番号、あるいは顧客の口座に関する情報の交換が含まれる場合がある。

ユーザおよびストリーミング・サービス・プロバイダが請求の詳細に同意できない場合（ブロック３１０）、この手順は終了する（ブロック３１２）。同意できる場合、ストリーミング・サービス・プロバイダはユーザが送信したメディア・ファイルを受信し（ブロック３１４）、このメディア・ファイルをそのストレージ・サブシステムに格納する（ブロック３１６）。その後ストリーミング・サービス・プロバイダは、ユーザに戻されるキーを準備する（ブロック３１８）。前述のように、このキーは、メディア・ファイルのストリーミングを開始するのに必要なすべての詳細を含むメタ・ファイル、サーブレットへのリンク、またはストリーミング・サービス・プロバイダのストレージ・サブシステム内のメディア・ファイルへの参照などの、ストリーミング・サービス・プロバイダにアップロードされたメディア・ファイルを明瞭に識別するのに使用可能な任意の識別子によって形成することができる。

次に、ストリーミング・サービス・プロバイダはストリーミング・インフラストラクチャをセットアップし（ブロック３２０）、これには、受信したメディア・ファイルをストリーミングするのに好適な適切なストリーミング・サーバを開始すること、メタ・ファイルを準備すること、または帯域幅要件に関する情報を獲得するためにメディア・ファイルを分析することが含まれる場合がある。

最後に、ストリーミング・サービス・プロバイダがこのキーをユーザに送信した後（ブロック３２２）、この手順は終了する（ブロック３２４）。図２を参照しながら説明したように、ユーザはビジターによってアクセスされる自分のＷｅｂサイトにキーを組み込むことができる。以下では、ビジターがユーザのメディア・ファイルを見られるようにする方法について説明する。

次に図４を参照すると、ストリーミング・サーバを要求側、たとえばビジター（図１を参照）に送達する（ブロック４０２）ためにストリーミング・サービス・プロバイダによって実施される、本発明に従った方法を示す流れ図が示されている。初めにストリーミング・サービス・プロバイダは、メディア・ファイルをストリーミングするようにという新しい要求を待つ（ブロック４０４）。ユーザのＷｅｂページで参照された特定のメディア・ファイルを見たいユーザのＷｅｂサイトのビジターは、こうした要求を開始する。その後、ストリーミング・サービス・プロバイダは、それぞれのメディアＩＤを含むストリーミング要求が受信されたか否かを判別する（ブロック４０６）。ストリーミング・サービス・プロバイダによって生成されたキー（図３の説明を参照）またはユーザのＷｅｂページから開始されたサーブレットによって生成された要求が、メディアＩＤを形成することができる。

Ｎｏの場合、ストリーミング・サービス・プロバイダは待機状態のままとなる（ブロック４０４）。Ｙｅｓの場合、ストリーミング・サービス・プロバイダはメディアＩＤまたはキーに対応するメディア・ファイルを見つけるために、ストリーミング・データベース内、たとえばそれぞれのストレージ・サブシステム内を探索する（ブロック４０８）。

キーに対応するメディア・ファイルが見つからない場合（ブロック４１０）、手順は終了する（ブロック４１２）。見つかった場合、ストリーミング・サービス・プロバイダは、要求されたメディア・ファイルに関する要求側からのアクセス権をチェックする（ブロック４１４）。その後ストリーミング・サービス・プロバイダは、要求側が要求されたメディア・ファイルに関して十分なアクセス権を有するか否かを判別する（ブロック４１６）。Ｎｏの場合、手順は終了し、要求されたメディア・ファイルのストリーミングは実行されない（ブロック４１８）。Ｙｅｓの場合、ストリーミング・サービス・プロバイダは適切なストリーム・サーバを選択し、対応するメタ・ファイルを生成する（ブロック４２０）。適切なストリーム・サーバの選択には、いくつかのストリーミング・サーバの中でストリーミングの負荷を分散させるためのロード・バランシングステップが含まれる場合がある。

最後にストリーミング・サービス・プロバイダは、要求側すなわちビジターにメタ・ファイルを送信した後（ブロック４２２）、手順を終了する（ブロック４２４）。

本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現することができる。いかなる種類のコンピュータ・システム、または本明細書に記載された方法を実行するのに適合した他の装置も、好適である。ハードウェアとソフトウェアの典型的な組合せは、ロードおよび実行された場合に本明細書に記載された方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを備えた、汎用コンピュータ・システムとすることができる。本発明は、本明細書に記載された方法を実施できるようにするすべての機能を有し、コンピュータ・システムにロードされた場合にこれらの方法を実行することが可能な、コンピュータ・プログラムに組み込むことも可能である。

本コンテキストにおけるコンピュータ・プログラム手段またはコンピュータ・プログラムとは、情報処理機能を有するシステムに、ａ）他の言語、コード、または表記法への変換、ｂ）異なる材料形式での再生のいずれかまたは両方の特定の機能を直接または後で実行させることを意図する、任意の言語、コード、または表記法での命令セットの任意の表現を意味する。

本発明に従った発明および装置が使用可能な環境を示すブロック図である。ページを開発および設計するため、すなわちインターネットで公開するためにＷｅｂ設計ツールで実施される、本発明に従った方法を示す流れ図である。新規なホスティング要求を受け入れるためにストリーミング・サービス・プロバイダによって実施される、本発明に従った方法を示す流れ図である。ストリーミング・サーバを要求側に送達するためにストリーミング・サービス・プロバイダによって実施される、本発明に従った方法を示す流れ図である。

Claims

Ｗｅｂページを介してメディア・ファイルにアクセス可能にするための方法であって、前記メディア・ファイルはすべてがネットワークを介して到達可能な要求に応じてストリーミング・サービス・プロバイダからビジターのコンピュータへとストリーミングされるものであって、前記方法が、
Ｗｅｂページを介してアクセス可能にするメディア・ファイルを受信するステップと、
前記メディア・ファイルをストリーミング・サービス・プロバイダに送信するステップと、
前記送信されたメディア・ファイルを明瞭に識別できるようにする、前記ストリーミング・サービス・プロバイダによって生成されたキーを受信するステップと、
前記キーから導出された識別子を前記メディア・ファイルにアクセスする際に通過する前記Ｗｅｂページ内に配置するステップと、
を有する方法。
サーブレットが前記キーを形成している、請求項１に記載の方法。
メタ・ファイルが前記キーを形成している、請求項１に記載の方法。
固有の英数文字列が前記キーを形成している、請求項１に記載の方法。
メタ・ファイルが前記導出された識別子を形成している、前記請求項１から４のいずれか一項に記載の方法。
サーブレットが前記導出された識別子を形成している、前記請求項１から５のいずれか一項に記載の方法。
前記メディア・ファイルをストリーミング・サービス・プロバイダに送信するステップが、
少なくとも１つのストリーミング・サービス・プロバイダを備えたリストをディレクトリ・サービスから検索するステップを含む、前記請求項１から６のいずれか一項に記載の方法。
すべてがネットワークを介して到達可能な要求に応じてビジターのコンピュータにストリーミングされるメディア・ファイルをホストするためにユーザの要求を処理するための方法であって、前記方法が、
ストリーミングされるメディア・ファイルをユーザから受信するステップと、
前記メディア・ファイルを格納するステップと、
前記受信されたメディア・ファイルを明瞭に識別できるようにするキーを準備するステップと、
前記キーを前記ユーザに送信するステップと、
を有する方法。
サーブレットが前記キーを形成している、請求項８に記載の方法。
メタ・ファイルが前記キーを形成している、請求項８に記載の方法。
固有の英数文字列が前記キーを形成している、請求項８に記載の方法。
ストリーミングされるメディア・ファイルをユーザから受信する前記ステップが、
請求の詳細を前記ユーザと交換するステップと、
前記請求の詳細に同意する場合に限り、前記メディア・ファイルを除外するステップと、
を含む、請求項８から１１のいずれか一項に記載の方法。
Ｗｅｂページを介してメディア・ファイルにアクセス可能にするための装置であって、前記メディア・ファイルはすべてがネットワークを介して到達可能な要求に応じてストリーミング・サービス・プロバイダからビジターのコンピュータへとストリーミングされるものであって、前記装置が、
Ｗｅｂページを介してアクセス可能にするメディア・ファイルを受信するための手段と、
前記メディア・ファイルをストリーミング・サービス・プロバイダに送信するための手段と、
前記送信されたメディア・ファイルを明瞭に識別できるようにする、前記ストリーミング・サービス・プロバイダによって生成されたキーを受信するための手段と、
前記キーから導出された識別子を前記メディア・ファイルにアクセスする際に通過する前記Ｗｅｂページ内に配置するための手段と、
を有する装置。
すべてがネットワークを介して到達可能な要求に応じてビジターのコンピュータにストリーミングされるメディア・ファイルをホストするためにユーザの要求を処理するための装置であって、前記装置が、
ストリーミングされるメディア・ファイルをユーザから受信するための手段と、
前記メディア・ファイルを格納するための手段と、
前記受信されたメディア・ファイルを明瞭に識別できるようにするキーを準備するための手段と、
前記キーを前記ユーザに送信するための手段と、
を有する装置。
請求項１から１２のいずれか一項に記載の方法をコンピュータに実行させるためのコンピュータ読取り可能プログラム手段を有する、コンピュータ使用可能媒体上に格納されたコンピュータ・プログラム。