JP2004506351A - リモートテレビジョン再生制御 - Google Patents

Abstract

無関係のウェブホスティングサービスをスタンドアロン型のメディアベースのデバイスと統合するための、方法、システム、コンピュータ媒体、及びその他の実施形態が提供される。ユーザは、インターネット上の様々なポータルを介してウェブブラウザを使用してメディアベースのデバイスに便利にアクセスし制御することができる。一実施形態では、ユーザは、１つ又は２つ以上の無関係のウェブポータルを介してメディアベースのデバイスにアクセスし、これによりメディアベースのデバイスを単一のウェブセッションで制御しアクセスすること、及びメディアベースのデバイス上に格納されている情報と第三者のオンライン情報及びサービスソースから発せられた情報との両方を単一の統合化された提示で見ることが可能となる。
【選択図】図２

Description

【発明の属する技術分野】
本発明は、一般にウェブユーザがコンピュータネットワークを介してメディアベースのデバイス及びアプライアンスに容易にアクセスし及びその制御を行うことを可能にすることに関し、特に共にインターネットと通信可能な状態にあるクライアントユーザインタフェイスからディジタルビデオレコーダのリモート制御を行うための方法、システム、及びコンピュータメディアに関する。
【従来の技術】
従来の技術は、メディアベースのデバイスの入力を直接制御し、又は短距離用（ｓｈｏｒｔ−ｒａｎｇｅｄ）リモートコントローラを使用して制御するものであった。すなわち、一般に、メディアベースのデバイスは、該デバイス自体に配設された制御パネルを使用して、又は該メディアベースのデバイスと通信可能な状態にあるリモートコントローラ（すなわち一般にはハンドヘルド型のもの）を使用して、直接プログラムすることが可能である。該ハンドヘルド型のリモートコントローラは通常は、該デバイスの周囲の短距離からの制御入力を、直接的なハードワイヤード延長ケーブルにより、又は何らかのワイヤレスメディア（例えば赤外線及び無線周波数）により提供する。これらの従来技術は、ユーザがデバイスに物理的に近接している（例えばメディアベースのデバイスと同じ部屋内にいる）場合には良好に機能するが、ユーザが物理的に異なる場所にいる状況には対処することができないものであり、このため、それが短距離であってもデバイスにアクセスすることができない。ユーザが何故デバイスから物理的に離れることになるかに関する理由及び状況は極めて多く存在するが、その詳細は重要ではなく、それよりも、ユーザがメディアベースのデバイスを該デバイスの物理的な場所から離隔した場所から制御することができないという欠点を克服することが重要である。当業者には自明であるように、ハンドヘルド型リモートコントローラは、一層長距離のハードワイヤード及び／又はワイヤレス送信に適合するよう設計することが可能であるが、かかる代替策は依然として不満足なものとなる。これは、送信距離の増大に比例して法外なコストが必要となるからである。
【発明が解決しようとする課題】
結果的に、必要とされているものは、メディアベースのデバイス及びアプライアンスの遠隔地からのユーザによる制御及びプログラミングを可能にする解決策である。該デバイスに対するアクセス及び制御を、便利で一般的で比較的単純な用法で、世界中のあらゆる場所から（例えばウェブブラウザから）行うことができることが望ましい。更に、多数のソース（例えばメディアベースのデバイス及び様々なメディアコンテンツプロバイダ並びにその他のオンラインサービスプロバイダ）からの情報をシームレスに統合してユーザが単一のウェブセッションで情報の組み合わせを利用することを可能にする態様で、ウェブブラウザベースのソリューションを提供することができれば有利である。デバイス及びアプライアンスが、かかる情報及びコンテンツのプロバイダと通信して、それらの間で自動的に情報の送受信を行うことができれば、有益である。最後に、メディアベースのデバイスのリモート制御を可能にするため及び関連情報にアクセスするために必要とされる方法、システム、及びコンピュータメディアはまた、ポータルを含む様々なウェブサーバにも一定の態様で（例えばアプリケーションプログラムインタフェイスを介して）利用可能であるべきである。
【課題を解決するための手段】
本書で説明する本発明の実施形態は、スタンドアロン式のメディアベースのデバイスのアクセス及び制御に関する従来技術の制限を克服するためにワールドワイドウェブ（ＷＷＷ）を利用するものである。ウェブユーザ、対象となるメディアベースのデバイスを用いたコンテンツプロバイダ、及び一般にメディアベースのデバイスの補助的なサービスやシステム管理やシステムメンテナンスを提供するウェブホスティングサービスプロバイダは、本書に記載の本発明の実施形態により利益を得ることが可能であり、該実施形態は、メディアベースのデバイス及びアプライアンスのための複数のスタンドアロン型のアプリケーションであってそれら自体では互いにうまく動作することのない該複数のスタンドアロン型のアプリケーションの統合を可能にするものである。このため、本書に記載の本発明の実施形態は、ウェブホスティングサービスとして提供することが可能なウェブアプリケーションであって、既存のスタンドアロン型のメディアベースのデバイスをユーザにとって一層有効なものとすることを可能にするウェブアプリケーションを作成する際に有益なものとなる。
本書に記載の本発明の実施形態は、スタンドアロン型のメディアベースのデバイス及びアプライアンスを用いた互いに無関係のウェブホスティングサービスを統合し、及びメディアベースのデバイス及びアプライアンスに対するアクセス及び制御をユーザがインターネット上の様々なポータルを介してウェブブラウザ等のクライアントユーザインタフェイスを用いて便利に行うことを可能にする、方法、システム、コンピュータメディア、及びその他の実施形態からなる。本発明の技術的な特徴の１つは、ユーザが１つ又は２つ以上の互いに無関係のウェブポータルを介してメディアベースのデバイス及びアプライアンスにアクセスして該メディアベースのデバイスを単一のウェブセッションで制御しプログラムすることを可能にする。この本発明の特徴によれば、メディアベースのデバイス及びアプライアンスの両方に格納された情報を含む統合された表現（該表現は一実施形態では、第三者によるオンラインでの情報及びサービスのソースから送出されたものとすることが可能である）がユーザに提供される。すなわち、メディアベースのデバイス及びアプライアンスに制御入力を提供するために該デバイス及びアプライアンスと同じ部屋にいる必要はなく、本書に記載の本発明の実施形態は、従来のプログラミング技術に関連する制限を克服し、ユーザがインターネットを介して全世界にわたり遠隔場所からメディアベースのデバイスにアクセスすることを可能にする。
本発明のもう１つの特徴は、スタンドアロン型のメディアベースのデバイス及びアプライアンスがネットワークと定期的に通信する状態にあるか連続的に通信する状態にあるかにかかわらず該ネットワーク上に動作可能なスタンドアロン型のメディアベースのデバイス及びアプライアンスをシミュレートすることにある。本発明の一実施形態によれば、メディアベースのデバイス及びアプライアンスの仮想的な表現が、ネットワーク上に生成されて、メディアベースのデバイスの動作をシミュレートするようクライアントユーザインタフェイスに提示される。本発明の別の実施形態では、メディアベースのデバイス及びアプライアンスは、ネットワークを介してリアルタイム及びオン・ザ・フライでクライアントユーザインタフェイスと通信する。
本発明の更に別の実施形態によれば、メディアベースのデバイスに格納された情報と無関係のオンラインソースから発せられた情報との両方が組み合わされて統合された表現が生成され、該表現が単一のウェブセッションを介してユーザへ提示され、ユーザは、１つのウェブ表現を介して、該組み合わされた情報にアクセスし見ることができ、及び関心のある特定の情報を選択し操作することができる。かかる本来であれば無関係で本質的に異なる場所に位置する情報ソースとして、テレビジョン、衛星ベースのペイ・パー・ビュー、及びケーブルベースのテレビジョンガイド情報、ユーザプリファレンス及び認証情報並びにその他の関連サービス及び付帯サービスを含む、ウェブホスティングサービス及びオンラインサービスが挙げられる（但しこれらに限定されるものではない）。
本書に記載の実施形態は、コンピュータベースの通信システムにおいて実施されるクライアント／サーバアーキテクチャで実施される。「ウェブという枠組み（ｗｅｂ ｐａｒａｄｉｇｍ）」を使用してインターネットを介したメディアベースのデバイス及びアプライアンスのアクセス及び制御を可能とすることにより、本書に記載の本発明の実施形態は、メディアベースのデバイス及びアプライアンスをプログラムするための便利で効率的な方法をユーザに提供する。一実施形態では、メディアベースのデバイス及びアプライアンスは、ディジタルビデオレコーダ（ＤＶＲ）（パーソナルビデオレコーダ（ＰＶＲ）としても知られる）と類似した性質を有する対話型テレビジョン装置から構成される。ネットワークを介したクライアントユーザインタフェイスからの制御入力を可能にするためにスタンドアロン型のＤＶＲで一般に用いられるローカル制御インタフェイスをポートする（ｐｏｒｔ）ことにより、本書に記載の本発明の実施形態は、インターネットの更なる普及に起因して次第に慣れ親しむようになる制御入力のための状況を提供する。インターネットの全世界に対する呼びかけ（ａｐｐｅａｌ）に、ＤＶＲを制御するためのウェブアプリケーションを結合させることにより、制作及び製造に関する膨大なコストを伴うことのないスケーラブルなソリューションが可能となる。
本発明の技術的な利点の１つは、本発明が、コンピュータベースの通信システムを含んでいる点にある。該通信システムは、（１）バックエンドのクライアント／サーバサブシステムを介してスタンドアロン型のメディアベースのデバイス及びアプライアンスから情報を抽出し、（２）更に別のサーバサブシステムを介してオンラインの及び無関係のウェブホスティングサービスから情報を抽出し、（３）上記様々なソースから抽出された情報を結合させ、（４）該結合させたデータのローカル表現をデータベースに維持し、（５）前記抽出された情報の結合に基づき統合された表現を生成して、仮想的な態様又はリアルタイムな態様でメディアベースのデバイスの動作をシミュレートし、（６）多数のポータルがフロントエンドサブシステムに対してリクエストを行うこと及び統合された表現をＡＰＩ（アプリケーションプログラムインタフェイス）を介して受信することを可能にし、（７）統合された表現をクライアントユーザインタフェイスへ送信し、（８）該表現の受信に応じてクライアントユーザインタフェイスからの命令を受容してデータベース及びメディアベースのデバイス及びアプライアンスを更新し、（９）該受信した命令をオンライン及びウェブホスティングサービスから取得した更なる情報と結合させ、（１０）該命令及び結合された更なる情報を用いてメディアベースのデバイス及びアプライアンスを更新することが可能である。
本発明のコンピュータベースの通信システムの一態様は、ネットワークコンピューティングシステム、ネットワーク／メディアベースのデータ統合システム、及びメディアベースのコンピューティングシステムの間の通信を可能にする。該ネットワークコンピューティングシステムがデータ統合システムを介してメディアベースのコンピューティングシステムと通信することを可能にするために、ＡＰＩで実施された一組のプロセスが提供される。一実施形態では、ネットワークコンピューティングシステムは、インターネットを介して提供されるウェブホスティングサービスを含む。該ウェブホスティングサービスは、データ統合システムの外部に位置するものである。同実施形態では、スタンドアロン型のＤＶＲが、メディアベースのコンピューティングシステム内のネットワークに接続される。データ統合システム内で提供されるＡＰＩは、ネットワークコンピューティングシステム内の様々な外部ウェブポータルがメディアベースのコンピューティングシステム内のＤＶＲと通信することを可能にするフレキシブルなアプローチを可能にする。更に、該ＡＰＩは、ネットワークコンピューティングシステム上のクライアントが、ウェブポータルのローカル環境に固有の一定の構成で、統合された表現をクライアントユーザインタフェイスにおいてリクエストし取得することを可能にする。したがって、該ＡＰＩは、数百万ものユーザのために広範なウェブサイトにより利用されることになる統合された表現を、単一かつ容易にアクセスできる態様で提示する。該ＡＰＩは、ユーザアカウントの作成、ユーザログイン、ユーザプリファレンス、リクエストの追加、番組ガイド情報の取得、関心のあるテレビ番組の探索、及び本書で一層詳細に説明するその他の処理を容易化する様々な機能をカプセル化する。
本発明の更に別の技術的な態様では、メディアベースのコンピューティングシステムは、リクエスト、データ、及びその他の制御入力情報をＤＶＲから様々なネットワークを介して通信することを可能にする。ＤＶＲはまた、コマンドを受信し、及び様々なネットワークを介して受信したコマンド及びデータに基づきデータ及びステータス情報を送出することが可能である。特に、ＤＶＲは、一定の態様で外部ソースから（例えば、好適には多数のウェブサーバを有するコンピュータベースの通信システムを介して）プログラムされることが可能となる。すなわち、ＤＶＲをプログラムするために使用される機構である従来のハンドヘルド型リモートコントローラやＤＶＲ上に配設されたコントロールパネルの代わりに、外部ソースを使用して該プログラミングを容易化することが可能となる。
本要約及び以下の詳細な説明に記載する特徴及び利点は、全てを網羅するものではなく、当業者であれば、図面、明細書、及び特許請求の範囲を参照することにより、多くの更なる特徴及び利点が自明となろう。更に、本明細書中で使用する用語は、主に読み易さ及び教示を目的として選択したものであって、本発明の要旨を制限するために選択したものではなく、かかる本発明の要旨は、特許請求の範囲に依存して決定する必要がある、ということに留意されたい。
本発明の教示は、以下の発明の詳細な説明を図面に関連して考察することにより容易に理解することができよう。
同図面は、本発明の例示のみを目的としてその好適な実施形態を示したものである。当業者であれば、本書に記載の本発明の原理から逸脱することなく本開示の構成及び方法の代替的な実施形態を採用することが可能である、ということが以下の詳細な説明から容易に理解されよう。
【発明の実施の形態】
序論
クライアントユーザインタフェイスからメディアベースのデバイス及びアプライアンスへのコンピュータベースの通信システムを介したアクセス、再検討、及び選択的な制御入力の提供を行うためのシステム、方法、コンピュータメディア及びその他の実施形態について説明する。以下の記述では、説明を目的として本発明の完全な理解を提供するために多数の特定の細部について説明する。しかし、本発明はこれら特定の細部なしでも実施可能であることが当業者には理解されよう。別の実施形態では、不必要な細部によって本発明が不明瞭にならぬよう、構造及び装置をブロック図形式で示している。
本明細書中における「一実施形態」又は「ある実施形態」なる言及は、具体例に関連して説明する特定の特徴、構造、又は特性が本発明の少なくとも１つの実施形態に含まれることを意味している。また本明細書中の様々な場所にある「一実施形態では」なる記載は、必ずしもその全てが同一の実施形態を指す必要のないものである。
以下に示す詳細な説明の幾つかの部分は、コンピュータメモリ内のデータビットについての操作のアルゴリズム及び図式的な表現を用いて提示したものである。かかるアルゴリズム的な記述及び表現は、データ処理分野における当業者が、自分の研究内容を他の当業者に最も効果的に伝えるために使用する手段である。本書では（及び一般に）、アルゴリズムとは、所望の結果へと導く複数のステップ（命令）の首尾一貫したシーケンスであると考えられる。該ステップは、物理的な量の物理的な操作を必要とするステップである。通常は、これらの量は、格納し、伝送し、結合し、比較し、及びその他の操作を行うことが可能な電気的、磁気的、又は光学的な信号という形をとる（但し必ずしもそうである必要はない）。主として一般的な用法であるという理由で、それらの信号を、ビット、値、要素、シンボル、キャラクタ、項、数といったものと称することが便利である場合があることが分かっている。更に、物理的な量の物理的な操作を必要とする複数のステップの特定の構成を、一般性を欠くことなく（モジュール）コードデバイスと称することが便利である場合があることも分かっている。
しかし、これらの用語及びそれに類似する用語の全ては、適当な物理的な量と関連付けされるべきものであって、これらの量に付与される単なる便利なラベルに過ぎないものである、ということに留意すべきである。特に言及する場合または後続の議論から自明である場合を除き、詳細な説明全体を通して、「処理する」、「算出する」、「計算する」、「決定する」、又は「表示する」といった用語を使用した議論は、コンピュータシステム又はそれに類似した電子的計算装置の動作及びプロセスを指すものである、と考えられる。ここで、該コンピュータシステムは、コンピュータシステムメモリ若しくはレジスタ又はその他のかかる情報記憶装置、送信装置、又は表示装置内の物理的（電子的）な量として表されるデータを操作し変換するものである。
本発明の一態様は、コンピュータプログラムという形で本書で説明するプロセスステップ及び命令の一実施形態を含む。代替的に、本発明のプロセスステップ及び命令は、ファームウェアまたはハードウェアで実施することが可能であり、ソフトウェアで実施する場合には、それをリアルタイムネットワークオペレーティングシステム及びアプリケーションにより使用される異なるプラットフォームへダウンロードして、該プラットフォームから実行することが可能である。
本発明はまた、本書に記載の動作を実行するための装置に関するものである。この装置は、必要とされる目的のために特別に構成することが可能であり、又は汎用コンピュータから構成して、該汎用コンピュータ内に格納されたコンピュータプログラムにより選択的に起動し若しくは再構成することも可能である。かかるコンピュータプログラムは、コンピュータにより読み出しを行うことが可能な記憶媒体に格納することが可能である。かかる記憶媒体は、フロッピィ（Ｒ）ディスク、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスクを含むあらゆるタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、光学カード（ｏｐｔｉｃａｌ ｃａｒｄ）、特定用途集積回路（ＡＳＩＣ）、又は電子的な命令を格納するのに適したあらゆるタイプのメディアであって（但しこれらに限定されるものではない）、コンピュータシステムバスに結合されるものである。更に、本明細書中で言及するコンピュータは、単一のプロセッサを含むことが可能であり、又は、計算能力の増大のために多数プロセッサ設計を採用したアーキテクチャとすることが可能なものである。
本書に示すアルゴリズム及び表示は、如何なる特定のコンピュータ又はその他の装置にも固有のものとはならない。様々な汎用的なシステムを本書での教示に従うプログラムと共に使用することが可能であり、また必要とされる方法ステップを実行するために特別な装置を構成するのが便利であることが分かっている。かかる様々なシステムに必要とされる構成は、以下の説明から理解されよう。更に、特定のプログラミング言語を参照して本発明を説明することはしない。様々なプログラミング言語を使用して本書に記載の本発明の教示を実施することが可能であり、特定の言語に対する以下の参照は、本発明の実施可能性並びにベストモードを開示するために提供したものである、ということが理解されよう。
更に、特許請求の範囲では、本発明は、情報システム上で動作するもの、又は情報システムと協働して動作するものとして請求されている。該特許請求するような情報システムは、以下の実施形態で後述するようなネットワークと通信可能な状態にあるブラウザ及びユーザインタフェイスアプリケーションからのディジタルビデオレコーダその他のメディアベースのデバイス及び／又はアプライアンスのリモートコントロールを提供するための情報システム全体又はかかるシステムの一部のみとすることが可能である。例えば、本発明は、最も単純な意味では通信ネットワークでありさえすればよい情報システムと共に動作して、メディアベースのデバイス及びアプライアンスに存在するプログラムデータの再検討及び選択を容易化することが可能である。別の極端な場合には、本発明は、無関係のデータソースからデータを探し出し、抽出し、及び格納し、かかるデータをユーザ制御入力を用いて統合して、以下の実施形態で後述するようなメディアベースのデバイス及びアプライアンスをプログラムし更新する情報システム又はかかるシステムの一部のみと共に動作することが可能である。このため、本発明は、最小限の機能を有する情報システムから、本書で開示する全ての機能を提供する情報システムまで、任意の情報システムと共に動作することが可能である。
システムの概要
ここで、本発明の幾つかの実施形態を詳細に参照する。該実施形態の例が図面に示されている。使用可能なあらゆる場所において、同一の又は同様の構成要素を指すために、図面全体にわたり同一の符号が使用されている。
本発明の１つの態様は、メディアベースのデバイス及びアプライアンスがネットワークに対して必ずしも常に接続されない状況に対処するものである。この状況に対処するために、メディアベースのデバイスがあたかもスタンドアロン型の装置として働いているかのようにユーザが経験することになる複製（ｒｅｐｌｉｃａｔｉｏｎ）にとって必要な全ての情報がデータベース内に格納される。このデータベースに格納された情報は、他の関連情報のソースと共に、クライアントユーザインタフェイス（ブラウザ等）へ送るべき統合された表現を構築して、あたかも「ライブ（ｌｉｖｅ）」（すなわちスタンドアロン）モード（すなわちビュー及び制御入力のためのモード）にあるかのように機能しているメディアベースのデバイスの動作をシミュレートすることを可能にする。したがって、本発明は、メディアベースのデバイス及び／又はアプライアンスがピア・ツー・ピアモード又は定期モードでネットワークとの通信セッションに参加している最中であるか否かに関わらず、遠隔場所からの、及びネットワークを介した、メディアベースのデバイス及び／又はアプライアンスに対するアクセス及び制御を可能にする。
以下で説明する一実施形態では、メディアベースのデバイス及び／又はアプライアンスがネットワーク及びデータベースとのコネクションを定期的に確立する際に、クライアントと、データベースと、メディアベースのデバイスとの間で、「バッチ（ｂａｔｃｈｅｄ）」処理モードで情報がやりとりされる。この実施形態では、クライアントでメディアベースのデバイスを使用してシミュレートを行うために必要なデータの複製を類推して、ネットワークを介してメディアベースのデバイスを仮想的に構築する（ｖｉｒｔｕａｌｉｚｅ）ことが可能である。
後述する別の実施形態の場合には、メディアベースのデバイスがクライアントとピア・ツー・ピアの通信セッションを確立する際に、クライアントからのメディアベースのデバイス及び／又はアプライアンスの制御入力及び更新が、オン・ザ・フライで（すなわち、ほぼ瞬時に結果を得ることを可能にするリアルタイムで）実行される。
１．バッチ処理（ｂａｔｃｈｅｄ ｐｒｏｃｅｓｓｉｎｇ）を介したメディアベースのデバイス及び／又はアプライアンスのリモートコントロールの一実施形態
ここで図１Ａのブロック図を参照する。同図には、メディアベースのデバイス及びアプライアンスの通信ネットワークを介したリモートコントロールを可能にする本発明によるコンピュータベースの通信システム１０の一例が示されている。図１Ａにおいて、通信システム１０は、ネットワーク／メディアベースのデータ統合システム１４（以下、統合システム１４と称す）に結合されたネットワークコンピューティングシステム１２を含み、次いで該統合システム１４が、メディアベースのコンピューティングシステム１６に通信可能に結合される。ネットワークコンピューティングシステム１２は、多数のユーザが通信システム１０を介して通信を行って、メディアベースのコンピューティングシステム１６のメディアベースのデバイス及びアプライアンスに対する遠隔場所からのアクセス及び制御を行うことを可能にする。メディアベースのコンピューティングシステム１６は、メディアベースのデバイス及びアプライアンスにネットワークシステムを介してアクセスすることを可能にし、これにより、該デバイス及びアプライアンスのスタンドアロン能力が一層向上することになる。統合システム１４は、複数のユーザ及びメディアベースのデバイスが通信状態になることが可能な異なるネットワーク間のインタフェイスを提供し、更に、多数のデータソースからのデータを捕捉し、結合し、及び統合して該捕捉したデータをクライアントユーザインタフェイス及びメディアベースのデバイスへ提供するための中央化された収容手段を提供する。
図２は、図１Ａの通信システム１０の更なる詳細を有する通信システム１０Ａの一実施形態を示すブロック図である。図２に示す実施形態では、通信システム１０Ａは、ネットワーク／メディアベースのデータ統合システム１４ａに結合されたネットワークコンピューティングシステム１２ａを含み、次いで該データ統合システム１４ａが、メディアベースのコンピューティングシステム１６ａに通信可能に結合される。詳細には、及び一例として、ネットワークコンピューティングシステム１２ａは、リクエスト側のコンピュータ装置に配設されたユーザインタフェイスから行われたリクエストを介して該リクエスト側のコンピュータ装置から供給側のコンピュータ装置へのアクセスをユーザが行うことを可能にする、クライアント−サーバコンピュータモデルに基づくものである。図２に示すように、ネットワークコンピューティングシステム１２ａに良く適した該クライアント−サーバコンピュータモデルの一実施形態は、１つ又は２つ以上のクライアントコンピュータ１８（「クライアントアプリケーション１８」及び「クライアント１８」と交換可能に使用される）を備え、その各々は、ネットワーク２４と通信する２２ためのユーザインタフェイス（例えばブラウザ２０）を有している。次いで、該ネットワーク２４が、１つ又は２つ以上のサーバコンピュータ２８−１〜２８−ｎ（サーバ２８−１，２８−２，…，２８−ｎと交換可能に称する）に結合される（２６）。本発明を説明する上での便宜上、呼称「サーバコンピュータ」は「サーバ」と交換可能に使用するものとする。次いで、サーバ２８−１，２８−２，…，２８−ｎが、データライン３０により示すように、統合システム１４ａに対して通信可能に結合される。
図２の実施形態にはまた、メディアベースのコンピューティングシステム１６ａが、クライアント−サーバコンピュータモデルに基づき同様に示されている。本発明を理解する上での便宜上及びその容易化のため、本書では、メディアベースのコンピューティングシステム１６ａは、「バックエンドサブシステム１６ａ」及び「バックエンド１６ａ」と交換可能に称することとする。図２の実施形態に見られるように、バックエンドサブシステム１６ａは、複数のメディアベースのデバイス及びアプライアンス３６に結合された（３４）複数のＲＮＳサーバ３２を含む。本発明の理解の容易化及び便宜のため、「メディアベースのデバイス及びアプライアンス３６」は。「メディアベースのデバイス３６」と交換可能に称することとする。以下で一層詳細に説明するように、メディアベースのデバイス３６は、クライアントコンピュータと同様の通信タスクを実行するための機能を更に含み、ＲＮＳサーバ３２は更に、クライアント−サーバコンピュータモデルにおけるサーバコンピュータと同様に動作するよう設計されている。以下で一層詳細に説明するように、ＲＮＳサーバ３２は、ネットワーク３８を介してメディアベースのデバイス３６と通信することが可能である。
ネットワークコンピューティングシステム１２ａとバックエンドサブシステム１６ａとの間で、ネットワーク／メディアベースのデータ統合システム１４ａは、それらの間に中央化されたインタフェイスを提供する。本発明を理解する上での便宜及び容易化のため、統合システム１４ａは、前記バックエンドサブシステム１６ａに対して、「フロントエンドサブシステム１４ａ」及び「フロントエンド１４ａ」と交換可能に称することとする。該フロントエンド１４ａ及びバックエンド１６ａが協働して、本発明による「Ｍｙ Ｒｅｐｌａｙ ＴＶ（私のＴＶ再生）（ＭＲＴＶ）」システムを構成する。一般に、フロントエンド１４ａは、様々な本質的に異なるデータソースからの情報を抽出し、捕捉し、格納し、及び統合し、該組み立てられた情報をクライアントユーザインタフェイス（ブラウザ２０等）及びメディアベースのデバイス３６へ送信する。更に、フロントエンド１４ａは、様々なソースからのデータをシステム１２ａ，１６ａにわたり共有することを可能にし、これにより、通信システム１０Ａを介したメディアベースのデバイス６８のユーザ制御入力が容易になる。図２の実施形態では、フロントエンド１４ａは、データライン４２を介してデータベース４４に接続されると共にデータライン３０を介してサーバ２８−１，２８−２，…，２８−ｎに結合された中間層サーバ４０を含む。該データベース４４は、バッチリクエストサーバ４８に通信可能に結合され（４６）、及びその他のオンラインデータソースに、例えば、データベース５０にデータライン５２を介して、及びオンラインサービス５４にデータライン５６を介して通信可能に接続される。バッチリクエストサーバ４８は、データライン５８を介してＲＮＳサーバ３２と通信し、及びライン６０を直接介してメディアベースのデバイス３６と通信することが可能となっている。
本発明によるネットワーク２４の一実施形態はインターネットを含む。しかし、本発明は、ネットワーク２４が分散配置されたクライアント１８をサーバ２８−１〜２８−ｎに接続する限り、多数のトポロジを介して広範な種類のコンピュータネットワークと共に適切且つ良好に動作するものである、いうことが当業者には理解されよう。本発明を理解する上での便宜及び容易化のために、ネットワーク２４をインターネット２４と称する場合がある。しかし、本発明は、本書に記載するタイプのものに限定されるものではないことが理解されよう。このため、本書の記述が特定タイプのネットワークを規定する範囲において、かかる記述は純粋に例示的なものであって、特定タイプのネットワークに対する本発明の適用可能性を制限することは意図していない。例えば、ネットワーク２４として使用することができる他のパブリック又はプライベート通信ネットワークとして、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、イントラネット、エクストラネット、バーチャルプライベートネットワーク（ＶＰＮ）、及びワイヤレスネットワーク（すなわち、ハードワイヤード通信リンクの代わりに当業界で既知の適当なワイヤレスインタフェイスを用いるもの）が挙げられる。一般に、これらのタイプの通信ネットワークは、他のコンピュータ及び記憶装置に通信可能に結合された、記憶装置、サーバコンピュータ、データベース、及びクライアントコンピュータからなる他のネットワークに通信可能に結合することが可能である。
クライアント１８、サーバ２８−１〜２８−ｎ、サーバ３２，４０，４８、及びメディアベースのデバイス３６は、本発明を有益に利用することが可能であり、また本発明のプロセスステップ及びモジュールの一実施形態をコンピュータプログラムという形で含むことが可能である。代替的には、本発明のプロセスステップ及びモジュールは、ファームウェア又はハードウェアで実施することが可能であり、ソフトウェアで実施する場合には、該プロセスステップ及びモジュールを、リアルタイムネットワークオペレーティングシステム及びアプリケーションにより使用される異なるプラットフォームにダウンロードして、該プラットフォームから実行することが可能である。
Ａ．クライアントの例示的な実施形態
クライアント１８の各ユーザは、通信システム１０Ａで作業を行い、ネットワーク２４を介してサーバ２８−１〜２８−ｎのうちの１つ又は２つ以上にアクセスする。ここで図３のブロック図を参照する。同図には、クライアントコンピュータ１８の一実施形態が示されている。該クライアントコンピュータ１８は、表示装置６４、キーボード６６、制御入力装置６８、ネットワークコントローラ７０、及び入出力装置７２にバス７４により結合されたコントロールユニット６２を備えている。
コントロールユニット６２は、算術演算装置、マイクロプロセッサ、汎用コンピュータ、パーソナルディジタルアシスタント、又は表示装置６４に電子的な表示信号を提供するよう構成された他の情報アプライアンスを含み得るものである。一実施形態では、コントロールユニット６２は、グラフィカルユーザインタフェイスを有する汎用コンピュータからなる。該グラフィカルユーザインタフェイスは、例えば、Ｊａｖａ（Ｒ）言語で書かれたプログラムをＷｉｎｄｏｗｓ（Ｒ）又はＵＮＩＸ（Ｒ）ベースのオペレーティングシステムといったオペレーティングシステムの上で実行することにより生成することが可能なものである。図３の実施形態では、１つ又は２つ以上のアプリケーション、電子メールアプリケーション、スプレッドシートアプリケーション、データベースアプリケーション、及びウェブブラウザアプリケーションが、通信システム１０Ａ（及び以下で詳述する１０Ｂ）の一部として、表示を生成し、情報を格納し、及び情報を取り出す。コントロールユニット６２はまた、当業者には理解されるように、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＬＤＡＰ、及びＳＭＴＰといった標準的なネットワークプロトコルを用いたファイル（例えばメディアオブジェクト）の分散のためのネットワークといった他のシステムに対する他の従来の接続を有している。
当業者には明らかであるように、コントロールユニット６２は、本発明の思想及び範囲から逸脱することなく、図３に示す構成要素よりも多数又は少数の構成要素を含むことが可能である。例えば、コントロールユニット６２は、例えば一次又は二次キャッシュといった更なるメモリ、又は１つ又は２つ以上の特定用途集積回路（ＡＳＩＣ）を含むことが可能である。同様に、例えば、イメージ走査装置、ディジタルスチルカメラ若しくはディジタルビデオカメラ、又は電子的なデータをコントロールユニット６２に捕捉し及び／又はダウンロードするよう構成され又は構成されていない他の装置を含む更なる構成要素をコントロールユニット６２に結合することが可能である。
また、図３に示されているように、コントロールユニット６２は、中央処理装置（ＣＰＵ）７６（他の場合には交換可能にプロセッサ７６とも称す）、主記憶装置７８、及びデータ記憶装置８０を含み、それら全てはシステムバス７４に通信可能に結合されている。
ＣＰＵ７６は、データ信号を処理し、複雑命令セット計算機（ＣＩＳＣ）アーキテクチャ、縮小命令セット計算機（ＲＩＳＣ）アーキテクチャ、又は複数の命令セットの組み合わせを実施したアーキテクチャを含む、様々な計算アーキテクチャを有することが可能である。図３には単一のＣＰＵしか示されていないが、多数のＣＰＵを含むことも可能である。
主記憶装置７８は、ＣＰＵ７６により実行することが可能な命令及びデータを一般に格納することができる。一般に、主記憶装置７８は、例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）デバイス、スタティックランダムアクセスメモリ（ＳＲＡＭ）デバイス、又は当業界で既知の何らかの他のメモリとすることが可能である。図４は、クライアントコンピュータ１８のための主記憶装置７８Ａの特定の一実施形態の更なる詳細を一例として示したものである。図４Ａの実施形態では、記憶装置７８Ａは、好適には、従来のタイプのインターネット（ウェブ）ブラウザアプリケーション８２（２０）を含むものとなる。該ブラウザアプリケーション８２は、インターネット及びプロセスＨＴＭＬ、ＤＨＴＭＬ、ＸＭＬ、ＸＳＬ、又はその他のマークアップ言語に対するアクセスを提供し、表示装置６４上にイメージを生成する。当業界で既知であるように、ウェブブラウザは、インターネット上のウェブページの閲覧を容易化するものであり、この場合、ユーザは、ウェブページのユニフォームリソースロケータ（ＵＲＬ）を入力し、又はウェブページ上のハイパーリンクをクリックする。該操作により、ウェブページ自体が適当なウェブサーバから取り出される。ウェブブラウザアプリケーション８２の例として、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（Ｒ）又はＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（Ｒ）ブラウザが挙げられる。主記憶装置７８Ａはまた、ネットワークアプリケーションプログラム８５を含み、及び随意選択的に、クライアントコンピュータ１８とサーバ２８−１〜２８−ｎとの間の通信を可能にするクライアントプログラム８６を含む。ネットワークアプリケーション８５は、ネットワークコントローラ７０と共に機能して、クライアント１８とネットワーク２４との間の通信を確立する。クライアントプログラム８６は、本発明によるメディアベースのデバイス３６に関する情報を生成し、編集し、移動し、追加し、探索し、除去し、及び／又は閲覧するために、ブラウザ８２と共に機能する（但しブラウザ８２がかかる機能を含まない場合）。記憶装置７８Ａはまた、ワードプロセシングアプリケーション、電子メールアプリケーション、及びスプレッドシートアプリケーションを含む１つ又は２つ以上のアプリケーションプログラム８７を制限を伴わずに含むことが可能である。また、主記憶装置７８Ａは、オペレーティングシステム（ＯＳ）８４を含む。例えば、ＯＳ８４は、Ｗｉｎｄｏｗｓ（Ｒ）９８／２０００ベースのオペレーティングシステムといった従来のものとすることが可能である。他の実施形態では、本発明を更に、ネットワークリソースを管理するために使用されるオペレーティングシステムである任意のコンピュータネットワークオペレーティングシステム（ＮＯＳ）と共に使用することが可能である。ＮＯＳは、多数の入力又はリクエストを同時に管理することが可能であり、またマルチユーザ環境で必要となるセキュリティを提供することが可能である。完全に自立したＮＯＳの一例として、アメリカ合衆国ワシントン州レッドモンド在Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ により製造されるＷｉｎｄｏｗｓ（Ｒ）ＮＴが挙げられる。一般に主記憶装置７８Ａは本例示以外の特徴を含むことが可能であることが当業者には理解されよう。命令及びデータは、本書に記載する技術のうち任意のもの又はその全てを実施するためのコードデバイス（ｃｏｄｅ ｄｅｖｉｃｅ）を含むことが可能である。
図３を再び参照する。データ記憶装置８０は、ＣＰＵ７６のためのデータ及び命令を格納するものであり、ハードディスクドライブ、フロッピィ（Ｒ）ディスクドライブ、ＣＤ−ＲＯＭ装置、ＤＶＤ−ＲＷ装置、フラッシュメモリデバイス、又は当業界で周知の他の何らかの大容量記憶装置を含む１つ又は２つ以上の装置から構成することが可能である。
システムバス７４は、コントロールユニット６２を介して情報及びデータの通信を行うための共有バスを表している。システムバス７４は、業界標準アーキテクチャ（ＩＳＡ）バス、周辺機器相互接続（ＰＣＩ）バス、ユニバーサルシリアルバス（ＵＳＢ）、又はそれらと同様の機能を提供するための当業界で周知の他のバスを含む１つ又は２つ以上のバスを表している。
ここで、表示装置６４、キーボード６６、制御入力装置６８、ネットワークコントローラ７０、及び入出力装置７２を含み、システムバス７４を介してコントロールユニット６２に結合される、更なる構成要素について説明する。表示装置６４は、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、又はそれらと同様の機能を有する表示装置、スクリーン、若しくはモニタとすることが可能である。代替的には、クライアント１８の代替的な実施形態に対応する表示装置６４の別の実施形態として、例えば、パーソナルディジタルアシスタント（ＰＤＡ）のタッチパネル式液晶ディスプレイ（ＬＣＤ）、及びセルラー電話の表示画面が挙げられる。
キーボード６６は、ＣＰＵ７６に対して情報及びコマンド選択の通信を行うためにコントロールユニット６２に結合された英数字入力装置を表している。制御入力装置６８は、ＣＰＵ７６に対する位置データ及びコマンド選択の通信を行うよう構成されたユーザ入力装置を表している。該制御入力装置６８は、マウス、トラックボール、スタイラス、ペン、タッチスクリーン、カーソル方向キー、ジョイスティック、タッチパッド、又はカーソルの移動を生じさせる他の機構を含むことが可能である。ネットワークコントローラ７０は、コントロールユニット６２をネットワーク２４にリンクさせ、多数の処理システムに対する接続を可能にするためのネットワークＩ／Ｏアダプタを含むことが可能である。複数の処理システムのネットワークは、ＬＡＮ、ＷＡＮ、及び多数の装置が通信することができる相互接続された他の任意のデータ経路を含むことが可能である。
１つ又は２つ以上の入出力装置７２がシステムバス７４に結合される。例えば、入出力装置７２は、オーディオ入力を受信すると共にオーディオ出力を送信するよう構成されたオーディオ装置とすることが可能である。オーディオ入力は、入出力装置７２及びネットワークコントローラ７０内のマイクロフォンを含む様々な装置を介して受信することが可能である。同様に、オーディオ出力は、ＣＰＵ７６及びネットワークコントローラ７０を含む様々な装置から発することが可能である。一実施形態では、入出力装置７２は、汎用コンピュータ内で使用するよう設計された汎用オーディオアドイン拡張カードとなる。随意選択的に、入出力装置７２は、１つ又は２つ以上のアナログ−ディジタル又はディジタル−アナログコンバータ、及び／又はオーディオ処理を促進させるための１つ又は２つ以上のディジタル信号プロセッサを含むことが可能である。
クライアントコンピュータ１８のハードウェアの一実施形態について説明してきたが、図３に示すコンピュータハードウェアの他にも、クライアント１８の代替的な実施形態が存在する、ということが当業者には理解されよう。かかるクライアント１８と置換することが可能な代替的な実施形態としては、当業者であれば理解されるように、プロセッサベースのポータブルハンドヘルド装置が挙げられる。例えば、クライアント１８と置換することが可能なポータブルハンドヘルド装置として、ＰＤＡ、双方向（ｔｗｏ−ｗａｙ）ページャ、電子メール端末、グローバルポジショニングシステム（ＧＰＳ）、及びモバイル／セルラー電話が挙げられる。かかる代替的な実施形態を本発明と共に使用する場合には、図３の実施形態に関して記載したユーザインタフェイス、通信媒体、及びプロトコルアダプタを修正して、対応するメディアイネーブルド（ｍｅｄｉａ−ｅｎａｂｌｅｄ）ポータブルワイヤレス装置の条件を満たすようにすべきである、ということがユーザインタフェイス分野の当業者には理解されよう。例えば、本発明は、ＨＴＭＬ、ＤＨＴＭＬ、ＰＯＰ３、ＳＭＴＰ、ＳＮＭＰ、ＦＴＰ、ＮＦＳ、ＩＭＡＰ、ＮＮＴＰ、及びＷＡＰを含む（但しこれらに限定されない）様々なインターネットプロトコルに対するインタフェイスを行う一組のプロトコルアダプタに関する実施形態も開示している。対応する通信プロトコルに関連してメディアイネーブルドポータブルワイヤレス装置上で使用されるようにウェブブラウザ２０，８２を修正することが可能であることが当業者には理解されよう。更に、これに対応して、データフローライン２２が、信号のワイヤレス伝送に適したものとしてワイヤレス通信メディア（例えば無線周波数信号や赤外線信号）を表したものとなることは明らかである。
Ｂ．サーバコンピュータの例示的な一実施形態
ここで図３及び図４Ｂを参照する。ネットワークコンピューティングシステム１２ａの実施形態に含まれるサーバ２８−１〜２８−ｎについて一層詳細に説明する。本発明を理解する上での便宜及び容易化のために、サーバ２８−１〜２８−ｎの特徴を一般的に説明するために「サーバ２８」と交換可能に称することとする。やはりまた、便宜上、クライアントコンピュータ１８及びサーバ２８の両者で使用される同様の構成要素に同様の符号を用いている。サーバ２８は一般に、コンピュータシステム１０Ａのフロントエンド１４ａをクライアント１８のユーザに提供することを責務とするものである。一実施形態では、サーバ２８は、様々なオンラインサービスを提供するウェブ「スーパーサイト」を意味するものと定義されるウェブポータルとすることが可能である。代替的には、サーバ２８は、無関係のエンティティ及びシステム管理者により提供され又はウェブホスティングされるウェブサイトとすることが可能である。これらの特定の実施形態は、ネットワーク２４がインターネットである場合に良く適したものとなる。
図３の実施形態では、サーバ２８は、好適には、表示装置６４、キーボード６６、制御入力装置６８、第１ネットワークコントローラ及びインタフェイス７０、入出力装置７２、及び第２ネットワークコントローラ及びインタフェイス７３を含み、それらは共にバス７４を介して結合される。サーバ２８は、やはりバス７４に結合されたプロセッサ７６、記憶装置７８、及びデータ記憶装置８０を有するコントロールユニット６２を更に含む。図３に示すように、第１ネットワークコントローラ及びインタフェイス７０は、ライン２６を介してネットワーク２４に通信可能に結合され、最終的にはクライアント１８に結合される。第２ネットワークコントローラ及びインタフェイス７３は、図２にデータライン３０により示すように、フロントエンド１４ａに通信可能に結合される。プロセッサ７６は、データ信号を処理するものであり、ＣＩＳＣ若しくはＲＩＳＣ又は複数の命令セットの組み合わせを実施したアーキテクチャを含む様々な計算アーキテクチャから構成することが可能である。一実施形態では、サーバ２８は、図４Ｂで説明するような主記憶装置７８Ｂを有するマルチプロセッサシステムを含む。一例として、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ／２０００サーバをサーバ２８に使用することが可能であるが、Ｄｅｌｌ Ｃｏｍｐｕｔｅｒ Ｃｏｒｐｏｒａｔｉｏｎ により製造・販売されるＤｅｌｌ １８００を含む他のマルチプロセッサシステムもまた本発明と共に適切且つ良好に機能することが可能である。
ここで図４Ｂを参照する。同図には、サーバ２８のための主記憶装置７８Ｂの特定の実施形態の更なる詳細が示されている。図４Ｂの実施形態では、記憶装置７８Ｂは好適には、オペレーティングシステム８８、その他のアプリケーション９０、サーバアプリケーションプログラム９２（サーバ９２）、及び「フロントエンド」サーバアプリケーション９４を備え、それら全てはシステムバス７４を介して共に通信可能に結合されている。サーバ９２は、例えばＡｐａｃｈｅ ＨＴＴＰサーバといった、あらゆる任意の既知のサーバアプリケーションとすることが可能である。フロントエンドサーバアプリケーション９４は、ＡＰＩとの間でリクエスト及びデータの送受信を行うことにより（これについては後述する）中間層サーバ４０との通信を確立するためのインタフェイスである。一般に、サーバ２８は、フロントエンド１４ａに応対する（ｈｏｓｔ）ものであり、典型的にはシステム１４ａ，１６ａに対する外部のウェブサイトである。サーバ２８が、様々な汎用ウェブサイト（サイトによっては様々なオンラインサービスを提供する「スーパーサイト」として機能する）を表すことができるものである一方、その他が一層制限された目的のためのものであることより、便宜上、及び不必要な細部により本発明が不明瞭になるのを回避するために、本書ではサーバ２８を「ウェブポータル２８０」と交換可能に称することとする。記憶装置７８Ｂはまた、ワードプロセシングアプリケーション、電子メールアプリケーション、及びスプレッドシートアプリケーションを含む１つ又は２つ以上の他のアプリケーションプログラム９０を制限を伴うことなく含むことが可能である。ネットワークアプリケーションモジュール９８は、ネットワークコントローラ７０の一部であり、サーバ２８がライン２６を介してネットワーク２４と通信することを可能にする。随意選択的に、ブラウザ９６を含めることも可能である。上述のように、記憶装置７８Ｂは、プロセッサ７６により実行することが可能な命令及び／又はデータを格納する。該命令及び／又はデータは、本書に記載の何れか及び／又は全てを実施するためのコードを含むことが可能である。これらのモジュール８８，９０，９２，９４，９６は、特に図示しない他のモジュールに加えて、システムバス７４によりプロセッサ７６に結合され、該プロセッサ７６と通信し協働して、サーバ２８の機能を提供する。コンピュータシステムの記憶装置７８Ｂの複数のモジュール又は部分として本発明を説明することになるが、該モジュール又は部分は、永久データ記憶装置といった他のメディアに格納することも可能であり、またクライアント／サーバ環境の場合のような複数の異なるコンピュータを有するネットワーク上に分散させることも可能である、ということが当業者には理解されよう。
図２を再び参照する。本発明によれば、ネットワーク２４は、サーバ２８及びクライアント１８並びにその他のデバイスの多数の構成要素間の通信を可能にする。これらは、同じ場所に配置されたもの、同じ場所に配置されていないもの、又は便宜、セキュリティ、若しくはその他の理由のために分散されたものとすることが可能である。クライアント１８とサーバ２８との間の通信を容易化するために、クライアント−サーバコンピュータネットワークオペレーティングシステム（ＮＯＳ）を図４Ｂの記憶装置７８Ｂ内のオペレーティングシステム８８に使用して、ネットワークリソースを管理することが可能である。ＮＯＳは、多数の入力又はリクエストを同時に管理することが可能であり、マルチユーザ環境に必要とされるセキュリティを提供することが可能である。オペレーティングシステム８８としては、例えば、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴ／２０００、及びＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ のＳＯＬＡＲＩＳ（Ｒ）コンピューティング環境で使用されるＵＮＩＸ（Ｒ）といった、従来タイプのＮＯＳを挙げることができる。本発明で使用することができる他の従来タイプのオペレーティングシステムとして、ＬＩＮＵＸ（Ｒ）が挙げられる。
Ｃ．フロントエンドの例示的な一実施形態
更に図２のブロック図を参照する。フロントエンド１４ａの一実施形態の更なる詳細について説明する。フロントエンド１４ａは、サーバ２８が通信することになる中間層サーバ４０を含む。フロントエンド１４ａは更に、該中間層サーバ４０に結合された（４２）データベース４４を含み、次いで該データベース４４がサーバ４８に結合されて、フロントエンド１４ａからバックエンド１６ａに「バッチ」で（すなわち定期的に）情報が提供されることになる。様々な他のデータベース５０及びオンラインデータソース５４が（それぞれライン５２，５６により）データベース４４と通信可能になっている。
本発明の他の特徴を詳述する前に、ここで幾つかの定義を本発明の特定の実施形態（この場合にはメディアベースのデバイス３６はＤＶＲ３７である）に関連して行うこととする。例えば、メディアベースのデバイス３６がＤＶＲ３７である特定の実施形態では、データベース４４は、１）複数のＤＶＲ３７の各々毎に構成されたチャネルのリスト、及び、２）国内放送局による全チャネルの電子番組ガイド（ＥＰＧ）データを格納する。以下、図１０を参照してＤＶＲ３７の特定の実施形態について詳細に説明するが、以下の定義は、例示のため、及び本発明を理解するために提供したものである。
電子番組ガイド（ＥＰＧ）は、電子的な形式で表されたテレビ（ＴＶ）ガイドデータとして定義され、例えばＴｕｒｂｕｎｅ Ｍｅｄｉａ Ｓｅｒｖｉｃｅｓ（ＴＭＳ）といったオンラインデータソースから提供される。これについては、図５のＴＭＳ ＦＴＰサーバ１１２に関して以下で説明することとする。従来知られているように、ＦＴＰは、ファイル転送プロトコルを意味するものとして定義される。一般に、ＥＰＧは、国内放送局により提供されるテレビジョン、ケーブル、及びペイ・パー・ビュー・ショー（ｓｈｏｗ）の放送スケジュールを含む。ＥＰＧデータを例示的に表現したものが、図１９Ａ及び図１９Ｂに示す再生ガイドである。
チャネルガイドは、以下で図１２Ａを参照して一層詳細に説明するように、ＥＰＧから組み立てられた放送されることになる全てのショーのリストを意味するものとして定義される。図１２Ａは、構成された複数のチャネルのリストの一例を示すものであり、チャネルガイド１９０を含んでいる。該チャネルガイドは、ユーザにより選択されて再生ガイド内に現れることになる実際のチャネルを示すチャネルラインナップのリストを含む。一般に、該チャネルガイドは、これから放送される番組及び過去に放送された番組を列挙する対話型のオンスクリーン番組ガイドである。
再生ガイドは、放送時に録画するようユーザにより選択されたショーであって、図１９Ｂを参照して以下で更に説明するように、記憶装置に格納されている、又は格納すべきショーを意味するものとして定義される。一般に、再生ガイドは、ユーザにより生成された記録チャネル及び現在記録されているショーを含む。再生ショー（Ｒｅｐｌａｙ Ｓｈｏｗ）は、再生ガイドの特定のビューを意味するものとして定義される。この場合には、図１９Ａを参照して以下で更に詳細に説明するように、記録すべき各番組毎に別個の再生チャネルが割り当てられる。
再生チャネル（Ｒｅｐｌａｙ Ｃｈａｎｎｅｌ）は、再生ガイドの特定のビューを意味するものとして定義される。該ビューは、図１２Ａを参照して以下で更に説明するように、探索ベースの基準又はチャネルガイドの基準に従って呼び出される保留中の及び完了した番組記録リクエストに関連する記述を示すものである。再生チャネルは、再生ショーのコレクションを含むことが可能である。
再生ゾーン（Ｒｅｐｌａｙ Ｚｏｎｅ）は、ユーザにより選択されたカテゴリーにより編成されたテレビ及びビデオ番組を意味するものとして定義される。
ｉ．中間層サーバ
図２を再び参照する。中間層サーバ４０は、データライン４２により示すように、少なくとも１つのデータベース４４に通信可能に結合される。更に、中間層サーバ４０は、データライン３０により示すように、サーバ２８に通信可能に結合される。クライアント１８により発せられサーバ２８を介して通信されたユーザリクエストは、該中間層サーバ４０で受信される。該リクエストは、図１６Ｂに関して後述するように、好適には１つのＡＰＩ２６４で実施された一組の機能に従ってサーバ４０により処理される。システム１０Ａ全体にわたって使用される複数組のＡＰＩと区別する際の更なる明瞭化を提供するために、中間層サーバ４０上にあるＡＰＩをＭｙＲｅｐｌａｙＴＶ（ＭＲＴＶ）ＡＰＩ２６４と交換可能に称することとする。一般に、該ＡＰＩ２６４は、中間層サーバ４０により受信されたＨＴＴＰコールを介してサーバ２８によりアクセスすることができる。以下で一層詳細に説明するように、ＡＰＩ２６４は、（１）対話型のメディアベースのデバイス３６，３７とウェブポータル２８との間のフロントエンドサブシステム１４ａを介したデータ転送を可能にするためのプロシージャ及びファンクションコール、パラメータ、及びフォーマッティング仕様と、（２）動作中のＤＶＲ６８Ｂの仮想的な表現をクライアント１８に提供すべき統合された態様で生成するために中間層サーバ４０上で使用されるソフトウェアとを含む。ＡＰＩ２６４はまた、ネットワークコンピューティングシステム１２ａ中の外部デバイスがフロントエンド１４ａ全体にわたる情報にアクセスすること及びバックエンド１６ａと通信することを可能にする。
図２に示す中間層サーバ４０の特定の実施形態の更なる詳細が図３に示されている。中間層サーバ４０は、図３に示すようにクライアント１８及びサーバ２８に関して説明する概略的なハードウェア構成を有することが可能である。当業者には自明であるように、主として便宜を図って中間層サーバ４０の概略的なハードウェアを説明すると共に不必要な細部により本発明が不明瞭にならないようにするために、図３では同様の符号を用いている。このため、サーバ４０は、プロセッサ７６、主記憶装置７８、及びデータ記憶装置８０を有するコントロールユニット６２を含む。該コントロールユニット６２は、バス７４を介して、表示装置６４、キーボード６６、制御入力装置６８、１つ又は２つ以上のネットワークコントローラ７０，７３、及び入出力装置７２に結合される。
主記憶装置７８Ｃの特定の実施形態を中間層サーバ４０に関して図４Ｃに示す。主記憶装置７８Ｃは、既述のオペレーティングシステム８８を含み、またＴｏｍｃａｔ（Ｒ）（サーブレット）サーバを有するＡｐａｃｈｅ（Ｒ）ウェブサーバ１０２上で実行されるＪａｖａ（Ｒ）サーブレットといったサーバツールを含む。Ｔｏｍｃａｔ（Ｒ）は、Ｊａｖａ（Ｒ）サーブレット仕様とＪＳＰ（Ｊａｖａ（Ｒ）ＳｅｒｖｅｒＰａｇｅｓ）仕様とを組み合わせたリファレンス・インプリメンテーション（ｒｅｆｅｒｅｎｃｅ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）であり、スタンドアロンモードで実行することができ、又はＡｐａｃｈｅ（Ｒ）ウェブサーバ１０２に組み込むことができる。Ｔｏｍｃａｔ（Ｒ）を使用することにより、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（Ｒ）ＪＳＰ１０４及びサーブレット１００に関する動作上の定義が、本発明に従って提供されるアプリケーションプログラミングインタフェイス（ＡＰＩ）２６４を駆動することになる。Ｊａｖａ（Ｒ）サーブレット１００は、データベース４４との間でＨＴＴＰフォーマットでリクエストを受信すると共にＸＭＬフォーマットでデータを送信する中間層サーバ４０上で実行されるように書くことができる。かかるＪａｖａ（Ｒ）サーブレット１００は、ＸＭＬファイルをデータベース４４に格納できるデータへと変換し、データベース４４からデータを抽出し、及び該抽出したデータをＸＭＬへと変換した後にウェブサーバ２８を介して外部のクライアント１８へ送るための機能を提供する。好適には、データベースとの対話機能及びＸＭＬへのデータフォーマット変換機能を組み込んだＪａｖａ（Ｒ）サーブレット１００が、ＲＮＳサーバ３２上で実行されるＪａｖａ（Ｒ）アプリケーションと、中間層サーバ４０上で実行されるＪａｖａ（Ｒ）サーブレット１００との間で共有される。中間層サーバ４０の記憶装置７８Ｃは、Ｊａｖａ（Ｒ）アプレット１０６、ＣＧＩスクリプト１０８、データベースインタフェイスアプリケーション１１０、及び（上述したような）他のアプリケーション９０といった類のアプリケーションを更に含むことができる。一般に、ＡＰＩ２６４は、Ｊａｖａ（Ｒ）サーブレット１００の制御下で実行される。Ａｐａｃｈｅ（Ｒ）ウェブサーバ１０２は、ＤＶＲ３７の制御入力インタフェイスの仮想的な表現を有するＨＴＴＰページであってブラウザ２０，８２上に表示するためのＨＴＴＰページを生成することが可能である。
データベースインタフェイスアプリケーション１１０は、データベース等の広範なリレーショナルコンピューティングシステムのデータにアクセスし、該データを格納し、及び抽出する機能を含む１つ又は２つ以上のプログラムであり、従来の既知の技術により実施することが可能なものである。例えば、データベースインタフェイスアプリケーション１１０は、オブジェクト・リンキング・アンド・エンベディング・データベース（ＯＬＥＤＢ）、オープン・データベース・コネクティビティ（ＯＤＢＣ）、及び／又はＪａｖａ（Ｒ）データベース・コネクティビティ（ＪＤＢＣ）ソフトウェアドライバを使用して到達することができるあらゆるリレーショナルデータソースからスキーマを抽出し定義するプログラムとして実施することができる。
記憶装置７８Ｃは、本発明の思想及び範囲から逸脱することなく、図４Ｃに示すよりも一層多数又は少数の構成要素を含むことが可能である、ということが当業者には理解されよう。
ｉｉ．オンラインサービス及びデータベース
図２のデータベース４４について一層詳細に説明する。データベース４４は、あらゆるリレーショナルデータベースシステム、テーブル、又はビューを表すものである。好適には、任意のＯＬＥＤＢ、ＯＤＢＣ、又はＪＤＢＣ互換のデータベースが、本発明に最も適して動作するものとなる。図２には単一のデータベース４４しか示していないが、多数の異種データベースを含めることが可能である。かかるデータベースの例として、Ｍｉｃｒｏｓｏｆｔ ＳＱＬサーバ、Ｏｒａｃｌｅ、Ｉｎｆｏｒｍｉｘ、ＤＢ２、Ｓｙｂａｓｅ、及びＭｉｃｒｏｓｏｆｔ Ａｃｃｅｓｓが挙げられる。中間層サーバ４０及びバッチリクエストサーバ４８の両者は、データベース４４からのデータを格納し抽出することが可能である。例えば、データフロー４２に示すような情報の一抽出態様では、ＪＤＢＣを使用してデータベース４４からのユーザプロファイル情報にアクセスしている。
データベース４４は、様々なソース（例えばライン５６により該データベース４４に結合されたオンラインサービス５４）から受信した情報を格納する。１つの特定のオンラインサービスが、図５の実施形態に示すように、Ｔｕｉｂｕｎｅ Ｍｅｄｉａ Ｓｅｒｖｉｃｅ（ＴＭＳ）により提供され、この場合には、以下で一層詳細に説明するように、ＴＭＳ ＦＴＰサーバ１１２が、データベース４４への電子番組ガイド（ＥＰＧ）データのＭＰＲＥＧモジュール１１４に対する供給を提供する。選択されたＥＰＧデータをＲＮＳサーバ３２を介してＤＶＲ３７にロードするために、クランチャ（Ｃｒｕｎｃｈｅｒ）モジュール１１６を配設することが可能である。随意選択的に、データライン５２により示すように、他のデータベースをデータベース４４に結合して特定タイプの情報をデータベース４４に提供することが可能である。例えば、ユーザ認証データベース５０をフロントエンド１４ａに含めて個人プロファイル情報のコレクションに対するユーザ認証を行うことが可能である。本発明に良好に適して動作する１つの特定の所有権を有する認証データベース５０がＳｉｌｋｎｅｔ（Ｒ）である。第三者のサーチエンジン又はその他のコンテンツプロバイダを含む更なるオンラインデータソースが、既存の情報、機能、特徴、及びサービスと統合するための更なる情報（例えばコンテンツ、放送、ショー、及び映画等）をデータベース４４に提供することが可能であることが当業者には理解されよう。図２及び図５に示すように、データベース４４は、ライン４６により示すようにバッチリクエストサーバ４８に結合される。図２及び図５に示す特定の実施形態に加えて、多数の構成のデータベースが本発明に適して良好に動作することが可能であり、この場合には、データベース４４は、他の情報ソースに通信可能に結合されると共に該データベース４４に格納されているデータと組み合わせるべき他の情報を受信するハブとして構成されることが理解されよう。
ｉｉｉ．バッチリクエストサーバ
ここで、図２及び図５を参照すると共に時折図１３Ａ及び図１３Ｂを参照してサーバ４８について詳細に説明する。本発明を理解する上での便宜及び容易化のため、サーバ４８を「バッチリクエストサーバ４８」と交換可能に称することとする。サーバ４８は、「バッチ」リクエストのために配設され、これは、データベース４４からサーバ４８へデータをプルし（ｐｕｌｌ）、及び／又はサーバ４８からデータベース４４へデータをプッシュする（ｐｕｓｈ）ために、データベース４４とサーバ４８との間で定期的に通信セッションが確立されることを意味している。更に、バッチリクエストサーバ４８とＲＮＳサーバ３２との間でデータ交換を行うために、それらの間で定期的なセッションが確立される。図２及び図５におけるサーバ４８の特定の実施形態は、以降で別の実施形態で説明するような負荷平衡型の分散通信システムにおけるメディアベースのデバイス３６とデータベース４４との間の直接的かつ連続的なリアルタイム通信セッションではなく、フロントエンド１４ａとバックエンド１６ａとの間の「バッチ」通信を提供するものである、ということが当業者には理解されよう。
サーバ４８との「バッチ」通信を提供する１つの特徴は、メディアベースのデバイス３６の数が増大した際にＲＮＳサーバ３２の信頼性に影響を与える可能性を最小限にすることである。ＲＮＳサーバ３２の信頼性を保持する様々な方法が存在することに留意されたい。当業者には明らかであるように、バッチリクエストサーバ４８は、図３と同様の構成要素を含むことができ、それらに関するの説明は既述のところである。
ここで、図６を参照して一例としてのバッチリクエストサーバ４８の１つの特定の実施形態について説明する。図６には、本書に記載する「バッチ」処理機能を容易化するためのソフトウェアモジュールを内部に有するバッチリクエストサーバ４８の主記憶装置１２０のブロック図が示されている。図６に示すように、主記憶装置１２０は、メディアベースのデバイス３６にＲＮＳサーバ３２を介してデータを「プッシュ」するための第１モジュール１２２を含む。この機能を達成するために、該モジュール１２２は、システム１０ａ，１０Ｂを使用するために登録されたメディアベースのデバイス３６の全ての性質を帯びたデータを抽出する（２４５）ためにデータベース４４に照会を行う（２４３）よう設計することが可能である。抽出された登録データを識別するための便利なパラメータは、各デバイス３６に関連するシリアル番号を追跡することによるものである。データベース４４の照会にとって有用となり得る別のパラメータとしては、例えば、図７の分類図に示すものが挙げられる。
更なる例示を提供するために、モジュール１２２の一実施形態について説明する。モジュール１２２は、スクリプトとして実施し、ＣＲＯＮジョブとして呼び出し、結果的に抽出したデータをＢｅｒｋｅｌｅｙＤＢファイル内に配置することが可能なものである。より詳細には、この特定の例の場合には、ＣＲＯＮジョブは、Ｊａｖａ（Ｒ）プログラムを実行させることができ、該プログラムが、各トランザクションをＸＭＬスニペットへと変換するデバイス３６に関するトランザクション情報の照会をデータベース４４に対して定期的に行い、最後の照会がメディアベースのデバイス３６のシリアル番号により配列されてから以降の全てのトランザクションを含む単一索引付き（ｓｉｎｇｌｅ−ｉｎｄｅｘｅｄ）ＢｅｒｋｅｌｅｙＤＢファイルを構築する。該ＢｅｒｋｅｌｅｙＤＢファイルは好適には、ＸＭＬでフォーマットされた全てのデバイス３６についてのトランザクションを含むものとなる。データが抽出されると、モジュール１２２は、ロードシェアリングサーバに関する以下の記述において説明するように、ＲＳＹＮＣコマンドを使用してＢｅｒｋｅｌｅｙＤＢファイルを全てのＲＮＳサーバ３２にプッシュする。
図６を再び参照する。バッチリクエストサーバ４８は更に、ＲＮＳサーバ３２にトランザクションをプッシュする第２モジュール１２４を含むことが可能である。該第２モジュール１２４は、全てのメディアベースのデバイス３６についての保留中のトランザクションのリストをデータベース４４に照会するよう設計することができる。モジュール１２２と同様に、モジュール１２４は、スクリプトとして実施し、ＣＲＯＮジョブとして呼び出し、抽出されたデータをＢｅｒｋｅｌｅｙＤＢファイル内に配置することが可能である。次いで該ファイルをＲＮＳサーバ３２の全てにプッシュすることが可能となる。
主記憶装置１２０は、バッチリクエストサーバ４８がＲＮＳサーバ３２からプルするファイルのための特定のフォルダを監視するよう機能する第３モジュール１２６を含むことが可能である。該特定のフォルダは好適には、ＲＮＳサーバ３２の全てから収集されたトランザクション結果ファイルの全てを含むものとなる。第３モジュール１２６は好適には、該結果ファイルのフォーマットをＸＭＬフォーマットデータ（データベース４４に格納することが可能なもの）へと変換するためのＪａｖａ（Ｒ）プログラムを含む。モジュール１２２，１２４と同様に、第３モジュール１２６は、スクリプトとして実施し、ＲＳＹＮＣコマンドを使用して結果ファイルを定期的に収集するＣＲＯＮジョブとして呼び出すことが可能である。
Ｄ．バックエンドの例示的な実施形態
図２を参照する。フロントエンド１４ａに対して通信可能に結合されたバックエンドサブシステム１６ａは、一実施形態では、該フロントエンド１４ａに結合された１つ又は２つ以上のメディアベースのデバイス３６を備える。別の実施形態では、複数のメディアベースのデバイス３６が、複数のロードシェアリングサーバ３２のうちの少なくとも１つに結合され、該結合されたロードシェアリングサーバ３２がフロントエンド１４ａとの通信を行う。かかる実施形態の更なる詳細について以下で説明する。
ｉ．ロードシェアリングサーバ
図２を参照する。同図には、複数のメディアベースのデバイス３６（その各々は制御データライン６０により示すようにフロントエンド１４ａに通信可能に結合されている）を有するバックエンド１６ａの一実施形態が示されている。該実施形態は、限られた数のメディアベースのデバイス３６については適当に良好に動作する。より大量のメディアベースのデバイス３６が配設された場合には、バックエンド１６ａを修正して、増大した通信トラフィック及び負荷に適応させなければならない。
バックエンド１６ａの別の実施形態に関し、フロントエンド１４ａと複数のメディアベースのデバイス３６との間の通信の負荷平衡をとるための機構について図２を参照して詳述する。図２に示すように、バックエンドサブシステム１６ａは、複数のロードシェアリングサーバ３２のうちの少なくとも１つと通信可能な状態にある複数のメディアベースのデバイス３６を含む。便宜上及び例示のため、ロードシェアリングサーバ３２を再生ネットワークサービス（ＲＮＳ）サーバ３２と交換可能に称することとする。以下の説明から明らかとなるように、ＲＮＳサーバ３２の１つの技術的な利益は、それによりシステム１０Ａを大量のメディアベースのデバイス３６へと規模拡大することが可能になると共に、多様なアプリケーションを使用するために必要となる柔軟性及び拡張性が提供されることにある。
制御／データライン３４に関し、各メディアベースのデバイス３６をＲＮＳサーバ３２に直接結合することが可能であるが、好適な態様は、メディアベースのデバイス３６をネットワーク３８（破線で示す）を介してＲＮＳサーバ３２に通信可能に結合することである。こうすることにより、バックエンド１６ａは、メディアベースのデバイス３６の分散サブシステムとして機能する。データ通信ライン５８は、ＲＮＳサーバ３２がバッチリクエストサーバ４８を介してフロントエンド１４ａに結合されていることを示している。本発明は、複数のサーバ３２なしでも適当かつ良好に動作するが、メディアベースのデバイス３６の数が増大した際に、複数のサーバ３２は、負荷平衡を提供するために有益なものとなる、ということに留意されたい。すなわち、メディアベースのデバイス３６及びＤＶＲ３７の数が増大した際に、単一のＲＮＳサーバ３２は容易に過負荷となり、このためネットワーク通信に失敗することになる可能性がある。
同実施形態において、バックエンドサブシステム１６ａを、メディアベースのデバイス３６がネットワーク３８（一実施形態ではインターネット）を介してＲＮＳサーバ３２にアクセスすることを可能にするクライアント−サーバコンピュータモデルに類似したものとすることが可能である。バックエンドサブシステム１６ａは、例えば、負荷平衡型のドメインネームサービス（ＤＮＳ）を用いることにより、負荷平衡がとられた一組の分散型ＲＮＳサーバ３２を構成する。ＤＮＳはディレクトリサービスであり、その一般的な機能は、当業界で周知のように、完全な故障許容システム（ｆａｕｌｔ ｔｏｌｅｒａｎｃｅ ｓｙｓｔｅｍ）を用いてインターネットホスト名のインターネットプロトコル（ＩＰ）アドレスへのマッピングを容易化することである。更に、複数の負荷平衡型ＤＮＳサーバは、インターネット上の異なるサーバ会社のウェブホスティングによるものとすることが可能であり、ＤＶＲ３７は、地理的に最適化されたものと置換することを意図したランダムアルゴリズムに基づきインターネット上の適当なサーバ会社に向けることが可能である。
本書で説明するように、ＲＮＳサーバ３２とＤＶＲ３７との間の通信を確立することが可能な幾つかの方法が存在する。それらの間のデータフローは、プルモデル、プッシュモデル、又はブロードキャストモデルに分類することができる。プルモデルは、各ＤＶＲ３７がＲＮＳサーバ３２に定期的に接続して（例えばダイヤルインして）フロントエンド１４ａから送信されたリクエストをアップロードしようとすることを意味するものと定義される。ＤＶＲ３７により受信されたリクエストは、「ｔｏ ｄｏ」リストに配置することが可能である。プルモデルの例示的な特定の実施形態について以下で説明するが、より高いレベルの概念でのプルモデルの実施は、一般に、ＤＶＲ３７とＲＮＳサーバ３２との間における対話、すなわち、セッションを確立するためのＤＶＲ３７とＲＮＳサーバ３２との間のモデムネゴシエーション、ピア・ツー・ピア・ポイント・ネゴシエーション、ＤＶＲ３７により行われるＵＲＬリクエスト、データ転送、及び該セッションの終了、を含むことが可能である。これに対し、プッシュモデルは、ＲＮＳサーバ３２がＤＶＲ３７殿接触を開始してフロントエンド１４ａから送信された記録命令の性質を帯びたリクエストをダウンロードすることを意味するものと定義される。例えば、プルモデルと同じＰＰＰ接続を使用して呼び出された際に、ＤＶＲ３７は、例えばその呼出側の識別子が所定のＲＮＳサーバ３２と一致する場合に、ＲＮＳサーバ３２とのセッションに参加することができる。代替的には、ブロードキャストタグ付き記録命令（ｂｒｏａｄｃａｓｔ ｔａｇｇｅｄ ｒｅｃｏｒｄｉｎｇ ｉｎｓｔｒｕｃｔｉｏｎ）を使用することが可能である。例えば、垂直帰線消去期間（ＶＢＩ）を使用して、ブロードキャストデータストリーム中に命令を埋め込むことができる。ＤＶＲ３７は、そのタグ（例えばシリアル番号）を検出すると、関連する命令をその「ｔｏ ｄｏ」リストに格納する。この実施形態では、ＤＶＲ３７は好適には、ＲＮＳサーバ３２によりブロードキャストされたデータを受信するために特定のブロードキャストチャネルに常に同調するものとなる。
ＲＮＳサーバ３２がフロントエンド１４ａ又はその他のオンラインデータソースから情報を取得することを可能にする幾つかの方法が存在し、該情報は最終的にはＤＶＲ３７に提供される。かかる代替例について説明する。最初に図２の通信システムを参照する。フロントエンド１４ａは、バッチリクエストサーバ４８及びデータライン５８を介してＲＮＳサーバ３２にデータをプッシュすることができる。定期的に、バッチリクエストサーバ４８は、保留中のリクエストの全てのデータベースをＲＮＳサーバ３２の全てにプッシュする。一実施形態では、該保留中のリクエストは、ＢｅｒｋｅｌｅｙＤＢファイル中に収容することができる。更に、別のＢｅｒｋｅｌｅｙＤＢファイルが全ユーザのリストを含むことが可能である。該ユーザは、システム１０Ａ，１０Ｂを介してＤＶＲ３７を使用するために各ユーザに対応するＤＶＲ３７を登録した者である。ＤＶＲ３７は、それに対応するシリアル番号が埋め込まれたＨＴＴＰリクエストをＲＮＳサーバ３２へ送出し、該ＤＶＲ３７がシステム１０Ａ，１０Ｂと相互に動作する（ｉｎｔｅｒｏｐｅｒａｔｅ）よう構成されているか否かに関する判定が行われる。本書で説明するように、ＤＶＲ３７は、ＲＮＳサーバ３２にＵＲＬを送ることにより、保留中のリクエストのリストを提供するようＲＮＳサーバ３２に命令することが可能なものである。
ＲＮＳサーバ３２は、図３の場合と同様の構成要素を含むことができ、それらに関する説明は既述のところである、ということは当業者には自明であろう。ＲＮＳサーバ３２の主記憶装置１３０の１つの特定の実施形態を一例としての図８を参照して説明する。ＤＶＲ３７がＲＮＳサーバ３２とのセッションを最初に確立する際に、シリアル番号が埋め込まれたＵＲＬがＤＶＲ３７からＲＮＳサーバ３２に送られる。図８に見られるように、主記憶装置１３０は、ＤＶＲ３７がシステム１０Ａ、１０Ｂと相互に動作するよう正しく登録されているか否かを検証する機能を提供する第１モジュール１３２を含む。例えば、モジュール１３２は、Ｐｅｒｌ（Ｒ）スクリプトで書かれたＣＧＩであって（登録済の全ＤＶＲのシリアル番号のリストを含む）ＢｅｒｋｅｌｅｙＤＢファイルを解析してＨＴＴＰリクエスト中に埋め込まれたシリアル番号と該ＢｅｒｋｅｌｅｙＤＢファイルとの突き合わせを行うＣＧＩとして実施することが可能である。更に、ＤＶＲ３７は、レスポンスのリストをリクエストする別のＵＲＬをＲＮＳサーバ３２に送ることができる。第２モジュール１３４は、特定のＤＶＲ３７に関する保留中のリクエストを判定し抽出する機能を提供する。例えば、モジュール１３４は、Ｐｅｒｌ（Ｒ）スクリプトで書かれたＣＧＩであってＢｅｒｋｅｌｅｙＤＢファイルを解析してＨＴＴＰリクエスト中に埋め込まれたシリアル番号と該保留中のリクエストのリストとの突き合わせを行うＣＧＩとして実施することが可能である。保留中のリクエストを探し出した場合には、モジュール１３４は、それに関連する情報を抽出して対象となるＤＶＲ３７に送信する。
また、ＤＶＲ３７は、ＲＮＳサーバ３２から受信したリクエストに対するレスポンスのリストを示す別のＵＲＬを特定のＲＮＳサーバ３２に送ることができる。該レスポンスのリストがＲＮＳサーバ３２により受信される際に、該レスポンスをレスポンスログファイルに結合するために別のモジュール１３６が使用される。第３モジュール１３６もまた、Ｐｅｒｌ（Ｒ）スクリプトで書かれたＣＧＩとして実施することが可能である。該レスポンスログファイルは、多数のＤＶＲ３７からのレスポンスを結合するものであり、分散されたバックエンド１６ａの規模が拡大された場合に顕著に大きなものとなり得る、ということが理解されよう。したがって、定期的に、ＲＮＳサーバ３２は、レスポンスログファイルをバッチリクエストサーバ４８を介してデータベース４４にプッシュする。これにより、レスポンス（例えば、新しいチャネルラインアップ、新しい再生ガイド、特定のＤＶＲ３７により正しく処理されたリクエストのリスト、及び対応するエラー等を含む）でデータベース４４を更新することが可能となる。プッシュ機能を実施するために、例えば、ＣＲＯＮジョブを呼び出す標準的なＵＮＩＸ（Ｒ）コマンドを定期的に（例えば１５分毎に）実行するよう含め、これにより、結合されたリストをバッチリクエストサーバ４８にプッシュすることが可能である。ＵＮＩＸ（Ｒ）に精通した者により従来知られているように、ＣＲＯＮジョブは、指定された時間間隔でシェルコマンドの実行を取り扱うものである。
ここで図５を参照する。同図には通信システム１０Ｂの別の実施形態が示されている。図５は、コンバータモジュール１１６（クランチャモジュール１１６と交換可能に称することとする）及びＭＲＥＰＧモジュール１１４に結合されたＴＭＳ ＦＴＰサーバ１１２が追加されている点を除き、図２と同様のものである。該ＴＭＳ ＦＴＰサーバ１１２は、ローカライズされた（ｌｏｃａｌｉｚｅｄ）ＥＰＧフォーマットへと変換される番組データのオンラインデータソースである。該サーバ１１２から取り出されたＥＰＧがデータベース４４へ送られると共に、該ＥＰＧの選択された部分が、クランチャモジュール１１６及びＲＮＳサーバ３２を介してＤＶＲ３７へと送られる。
図９のブロック図を参照する。同図には、ＴＭＳ ＦＴＰサーバ１１２からＤＶＲへの選択されたＥＰＧデータのデータフローが示されており、かかるＥＰＧデータは、ＴＭＳ ＦＴＰサーバ１１２からクランチャ１１６を介してＲＮＳサーバ３２に向かってプッシュされる。一実施形態では、クランチャモジュール１１６は、ＴＭＳ ＦＴＰサーバ１１２からＥＰＧデータを定期的に収集して、チャネルガイド及び再生ゾーンデータを構築し、かかる情報をＲＮＳサーバ３２へ供給する。特定の実施形態では、クランチャ１１６は、定期的に起動してサーバ１１２からＴＭＳデータファイルをダウンロードするＣＲＯＮジョブを実行するよう設計することができる。該クランチャ１１６は、ＥＰＧデータを、ＤＶＲ３７に適したフォーマットを有する多数の個々のファイルへと「クランチ（ｃｒｕｎｃｈ）」する（すなわち分解する）スクリプト（例えばＰｅｒｌ（Ｒ）スクリプト）を使用して実施することが可能である。これらのフォーマットされたファイルはまた、その中に挿入されたＳＵＺＵＫＩデータを含むことができる。ＳＵＺＵＫＩデータは、関連する識別タグを有するジャンルベースのショーのコレクションを含むものである。次いで、該タグをシステム１０Ｂにより使用して、再生ゾーン機能としての便宜のために参照される特定ジャンルのショーをフィルタリングしてユーザが選択できるようにすることが可能である。クランチャ１１６の制御下で、ＵＮＩＸ（Ｒ）において知られているＲＳＹＮＣコマンドを使用して、これらファイルをＲＮＳサーバ３２に分配することができる。従来既知であるように、ＲＳＹＮＣコマンドは、セキュアなチャネルを使用したデータ転送を可能にするものである。
本書に記載するプッシュモデル、プルモデル、又はブロードキャストモデルの場合、ＲＮＳサーバ３２は、クランチャ１１６からこれらのファイルを受信すると共にフロントエンド１４ａからリクエストを受信する分散された負荷平衡型の一組のサーバである。ＤＶＲ３７とそれに対応するＲＮＳサーバ３２との間でインターネット接続が確立される場合には、該ＤＶＲ３７は、ＲＮＳサーバ３２に格納されているデータを受信する。例えば、チャネルガイド内のあらゆるショーは、該ショーに指定された一意の定義であってフロントエンド１４ａからＤＶＲ３７にプッシュされる定義に関連付けされる。ＤＶＲ３７は、このデータを、該ＤＶＲ３７がクランチャ１１６から受信した他のデータに基づき突き合わせする。ＤＶＲ３７は、そのチャネルガイド内の番組データのリストを含み、前記突き合わせ及びクランチャ１１６から受信したデータに基づいてそのチャネルガイドを構築する。
データベース４４へのＥＰＧデータのアップロードに関し、ＭＲＥＰＧモジュール１１４は、ソフトウェアにより実施されたバッチプロセスを含み、ＴＭＳ ＦＴＰサーバ１１２からデータを抽出してデータベース４４を更新する。ＭＲＥＰＧモジュール１１４は、ＴＶ番組ガイドコンテンツをデータベース４４に提供することを責務とする。該ＭＲＥＰＧモジュール１１４はまた、ユーザが、タイトル、叙述、及び／又はクレジットに基づいてショーを見つけることを可能にする探索機能を提供する。更に、ＭＲＥＰＧモジュール１１４は、データベース４４内のＥＰＧデータを維持すること、及びかかるデータをＴＭＳからの供給に基づき最新の状態に保つことを責務とする。ブラウザ２０に送られるチャネルガイドは、データベース４４からのＥＰＧデータから構築されてＭＲＥＰＧモジュール１１４によりロードされる。ＤＶＲ３７は、クランチャモジュール１１６により構築されＲＮＳサーバ３２を介してロードされたチャネルガイドを有する。したがって、２つのバージョンのチャネルガイドが存在し、すなわち、その一方がデータベース４４内に、他方がＤＶＲ３７内に存在する（但し何れもＴＭＳ ＦＴＰサーバ１１２を出所とするものである）。このチャネルガイドに関するデータベース４４及びＤＶＲ３７内のＴＭＳデータのデュアルロードは、ＤＶＲ３７に必要なチャネルガイドデータのみを提供して該ＤＶＲ３７における不必要なメモリ割り当てを回避することを目的としたものである。
ここで図９の実施形態を参照する。同図において、ログミル（Ｌｏｇ−Ｍｉｌｌ）モジュール１４０は、複数の管理上のシステムタスクを蓄積するシステムログファイルをそれぞれ含む複数のＤＶＲ３７からのログの全てを収集する。このシステムログファイルは、そのサイズが次第に大きくものであるため、ＤＶＲ３７のデータ記憶装置からの記憶スペースの解放が達成される。該システムログファイルをＲＮＳサーバ３２にアップロードするためのアプリケーションをＤＶＲ３７上に含ませることが可能である。システムログファイルがＲＮＳサーバ３２にアップロードされた際に、ログミルアプリケーションモジュール１４０は、該システムログファイルをデータベース１４２にアーカイブすることが可能である（図１３Ｂの符号２５７，２５９を参照のこと）。このようにする一例として、ログミルモジュール１４０が、定期的に起動されるＣＲＯＮジョブであって、ＲＳＹＮＣルーチンを使用して全てのＲＮＳサーバ３２にわたり分散されたシステムログファイルを取り出し、それらを併合してデータベース１４２に供給する、ＣＲＯＮジョブを実行することが挙げられる。データベース１４２はデータベース４４とは別個のものとすることが可能であることが理解されよう。データベース１４２がＯｒａｃｌｅから提供される一実施形態では、 ＳＱＬ＊Ｌｏａｄコマンドがログミルモジュール１４０により呼び出されて、システムログファイルがエントリとしてデータベース中にアーカイブされる。システムログファイルをアーカイブすることにより、利用状態を追跡することが可能となり、すなわち、ＤＶＲ３７の特定の機能を利用しているユーザの数を追跡することが可能となる。ログミルはまた、算術演算、請求書作成、将来の予測、立案、並びにターゲットとなる広告、製品、及びコンテンツに使用するための情報を収集するのに有用である。
ｉｉ．メディアベースのデバイス及びアプライアンス
メディアベースのデバイス及びアプライアンス３６について、例示として図３に示すハードウェアの一般的な実施形態を参照して（及び時折図１３Ａ，１３Ｂを参照して）一層詳細に説明する。本発明を理解する上での便宜及び容易化のため、図３（その一部はメディアベースのデバイス及びアプライアンス３６に適用可能なものである）に関して以前に説明したものと同様の構成要素には同様の符号を付してある。図３の実施形態において、メディアベースのデバイス３６は、制御入力装置６８、第１ネットワークコントローラ及びインタフェイス７０、及び入出力装置７２を含み、それらは共にバス７４を介して結合されている。随意選択的に、メディアベースのデバイス３６は、表示装置６４に結合することが可能であり、又は表示装置６４を含むことが可能であり、また共にバス７４を介して結合された第２ネットワークコントローラ及びインタフェイス７３及びキーボード６６を含むことが可能である。該デバイス３６は、本書で明示的に記載するよりも多数又は少数の構成要素を含むことが可能である、ということが理解されよう。メディアベースのデバイス３６は更に、やはりバス７４を介して結合されたプロセッサ７６、記憶装置７８、及びデータ記憶装置８０を有するコントロールユニット６２を含む。
図２及び図５の一実施形態によれば、第１ネットワークコントローラ及びインタフェイス７０は、フロントエンド１４ａのバッチリクエストサーバ４８に対するデータライン６０を介したメディアベースのデバイス３６の通信可能な結合を容易化することが可能である。随意選択的に、第２ネットワークコントローラ及びインタフェイス７３を本書で明示的に示していない他のネットワーク及びデバイスに結合することも可能である。プロセッサ７６は、データ信号を処理し、クライアント１８及びサーバ２８に関して上述した様々な計算アーキテクチャを含むことが可能なものである。
ここで図４Ｄを参照する。同図には、メディアベースのデバイス３６に関する主記憶装置７８Ｄの特ＴＩＥの実施形態の更なる詳細が示されている。図４Ｄの実施形態において、主記憶装置７８Ｄは好適には、オペレーティングシステム８４、その他のアプリケーション８７、及びネットワークアプリケーション８５（それらの機能については既述のところである）を含むものとなる。主記憶装置７８Ｄは更に、ビデオキャプチャエンジン１５０、トランザクションハンドラ（アプリケーション）プログラム１５２、及びリクエストハンドラ（アプリケーション）プログラム１５４を含み、それら全てはシステムバス７４を介して通信可能に結合されている。随意選択的に、ブラウザ８２を含めることが可能である。
上述のように、主記憶装置７８Ｄは、プロセッサ７６により実行することが可能な命令及び／又はデータを格納する。該命令及び／又はデータは、本書に記載の複数の技術のうちの何れか又は全てを実行するためのコードから構成することが可能である。モジュール８２，８４，８５，８７，１５０，１５２，１５４は、特に図示しない他のモジュールに加えて、システムバス７４によりプロセッサ７６に結合され、メディアベースのデバイス３６の機能を提供するよう通信し協働する。コンピュータベースのシステムの記憶装置７８Ｄの複数のモジュール及び部分について本発明を説明するが、該モジュール又は部分は、永久データ記憶装置といったメディアに格納することも可能であり、またクライアント／サーバ環境といった複数の異なるコンピュータを有するネットワークにわたり分散させることも可能である、ということが当業者には理解されよう。
一般に、メディアベースのデバイス３６は、図４Ｄに関して説明する機能、又は明示的には図示しないがそれ等価な機能並びに追加の機能を含むことが可能である、ということに留意されたい。本発明は、広範なデバイスで実施することが可能なものであり、本書に記載する実施形態に限られたものではない。メディアベースのデバイス３６の例として、家庭用機器、対話型テレビ、ポータブルネットワークテレビ、テレビ機能を有するポータブルネットワークデバイス、又はセットトップ用アプリケーション及びデバイスを挙げることができる（但し、これらに限定されるものではない）。
図１０を参照する。同図には、本発明での使用に良く適した１つのタイプのセットトップデバイスが、例えばＲｅｐｌａｙＴＶ， Ｉｎｃ．（Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， Ｃａｌｉｆｏｒｎｉａ）から販売されているようなディジタルビデオレコーダ（ＤＶＲ）３７を含む対話型テレビサブシステム１６０として示され実施されている。便宜上、ＤＶＲ３７を「ビデオ再生システム３７」と交換可能に称することとする。図４の実施形態では、ＤＶＲ３７は、放送プロバイダ１６４からの放送コンテンツ（すなわち番組）を見るためのテレビベースの表示装置１６２に結合される。番組１６６（例えばテレビ番組）は、国内放送局１６４から受信され、他のコンテンツ、データ、及び制御データ１６８（例えば、ネットワークからの広告、番組ガイド、及び制御入力等）と共に、表示装置１６２に渡される。
図３及び図４Ｄを参照する。ＤＶＲ３７は、クライアント１８に関して上述した機能と同様の機能を有するクライアントベースのシステムである。例えば、ＤＶＲ３７は、到来する番組信号１６６を格納するために使用されるハードドライブ等のデータ記憶装置８０を含む。次いで、該格納された信号は、後ほど見ることができ、又は直ちに記憶媒体８０から見ることができる。ＤＶＲ３７は、プロセッサ７６及び記憶装置７８Ｄ（又は該記憶装置の機能を割り当てるために使用される同様の構成要素）を含み、該特定のデバイス３７に関する上述の機能を実施する。更に、ＤＶＲ３７は、コンテンツ１６６の最初のソースから切断されたとき、すなわち、スタンドアロンデバイスとして機能しているときを判定することが可能である。
本発明による一実施形態では、ＤＶＲ３７は、ネットワークサーバ（一特定実施形態においてロードシェアリング「ＲＮＳ」サーバ３２として本書で説明されているもの）からのデータライン３４により示すように、ネットワークを介して制御情報１６８を受信する。制御ライン３４は、ＤＶＲ３７を個々のＲＮＳサーバ３２に結合する通信リンクが存在することを示している。コンテンツ情報１６６としては、電子広告、電子番組ガイド、認証情報、クライアント１８から発せられた制御入力、及び本書に記載するオンラインソース及びデータベースからの他のタイプのデータが挙げられる（但し、これらに限定されるものではない）。レスポンスにおいて、ＤＶＲ３７は、広告の感想、取引情報、及び更新されたプログラミング及びプロファイル情報といった制御情報１６８をサーバ３２，４８に送信することが可能である。サブシステム１６０は、ケーブルコンテンツ、テレビコンテンツ、高品位ＴＶコンテンツ、ディジタルＴＶコンテンツ、ペイ・パー・ビュー・コンテンツ、及びネットワーク（インターネットを含む）を介して放送されたコンテンツを含む（但しこれらに限定されない）様々なタイプの番組を受信することが可能である、ということが理解されよう。また、表示装置１６２は、ディジタル又はアナログテレビ、インターネットアプライアンス、セルラー装置、又はワイヤレス装置を含む（但しこれらに限定されない）あらゆる特定のタイプの表示装置とすることが可能である、ということが理解されよう。ＤＶＲ３７及び表示装置１６２は、図示のように別個の物理的な装置とすること、共に一体化されたもの、又は図示するよりも更に多くの機能ユニットに分割されたものとすることが可能である。
ＤＶＲ３７の一実施形態は制御ライン３４，６０の１つ又は２つ以上を実施するための電話線を含むことが理解されよう。例えば、かかる制御ライン３４，６０は、ＲＪ−４５（Ｒｅｇｉｓｔｅｒｅｄ Ｊａｃｋ−４５）コネクタを含むことが可能であり、別の実施形態では、Ｅｔｈｅｒｎｅｔ（Ｒ）接続又はトークンリングＴｙｐｅ３通信を含むことが可能である。図２に示すシステム１０Ａでは、情報１６８は、「バッチ」モード動作において説明するように、規則的に（例えば２４時間毎に）ＤＶＲ３７との間でやりとりされる。別の実施形態では、データ制御ライン３４，６０としてインターネット接続を使用して、規則的に又は一層頻繁に接続を行う。例えば、図５に示すシステム１０Ｂの更なる実施形態では、情報１６８は、リアルタイムモードでほぼ瞬時の結果を伴ってＤＶＲ３７とクライアント１８との間でやりとりされる。制御ライン３４，６０の更に別の実施形態は、当業界で周知のワイヤレス通信媒体とすることが可能である。
図１０はまた、サブシステム１６０を制御するために使用されるリモートコントロール装置１７０を示している。典型的には、ＤＶＲ３７は、装置のハウジング上に配設されたタッチパネルという形の制御入力を含むものとなる。後述するように、本発明の一実施形態は、通信システム１０Ａ，１０Ｂを介してイネーブルにされるメディアベースのデバイス３６のユーザ制御を含むものとなる。例えば、一特定実施形態では、サブシステム１６０はインターネットを介して制御することができる。
本書に記載する実施形態が動作する文脈は、個々のユーザのＤＶＲ３７に関するものであるが、本発明は、対話型テレビサブシステム１６０に限定することを意図したものではない。例えば、他のタイプのメディアベースのデバイス及びアプライアンス３６が図２に示されている。しかし、一般的には、ＤＶＲ３７の場合には、ユーザは、以前に記録された「録画された（ｔａｐｅｄ）」コンテンツをハードドライブ若しくはその他の記憶媒体８０から再生することにより、又は自分のテレビ（若しくはその他のコンテンツソース）の電源を入れて見るべき番組若しくはショーを選択することにより、番組コンテンツを選択する。選択された番組コンテンツがＤＶＲ３７により受信されると、該コンテンツが先ず記憶媒体８０に格納され、次いでテレビモニタ６４といった表示装置１６２上に表示される。
図４Ｄを再び参照する。ＤＶＲ３７の主記憶装置７８Ｄで実行されるソフトウェアアプリケーション及びプログラムを表す様々なモジュールについて本発明の理解を容易化するために図１０を時折参照して説明する。ＤＶＲ３７は、１つ又は２つ以上の番組１６６（ビデオ放送等）を放送するテレビ、ケーブル、又はペイ・パー・ビュー・放送局といった国内放送局１６４からの信号を受信する。該放送は、記憶装置７８Ｄ内のビデオキャプチャエンジン１５０により受信される。該ビデオキャプチャエンジン１５０は、キャプチャした番組コンテンツをその受信時に記憶媒体８０に渡し、及びユーザにより選択された際に表示装置１６２に渡す。ビデオキャプチャエンジン１５０は、（必要に応じて）複数の考え得る放送番組のうちの何れを（例えばチャネルを変えることにより）ユーザが選択したかを示すためにチューナ（明示的には図示しない）に結合することが可能である。次いでユーザは、番組１６６をその受信中に表示させること又は後で再生するために番組１６６をセーブすること（又はその両方）ができる。
クライアント１８におけるユーザには、一般に、ガイドへの番組リストの追加、ガイドからの番組の削除、ガイド上の番組リストの更新、ＤＶＲ３７からのガイドの取得、及びＤＶＲ３７からのチャネルガイドの取得、を行うための機能が提供される。一実施形態では、及び一例として、クライアント１８におけるユーザにより提供されるこれらのタイプの制御入力リクエスト、コマンド、及び命令は、フロントエンド１４ａ内のトランザクションファイルに格納し、及びバックエンド１６ａにプッシュすることが可能であり、最終的にはＲＮＳサーバ３２を介してＤＶＲ３７に送信される。
図１３Ａ及び図１３Ｂのシーケンス図を時折参照して「バッチ」モードの実施について説明する。定期的に、ＤＶＲ３７は、ネットワーク（例えばインターネット）にダイヤルして（２４９，２５３）、トランザクションファイルのダウンロード（２５１，２５５）をＤＶＲ３７にリクエストする。この通信を容易化するために、ＤＶＲ３７は、ＲＮＳサーバ３２に対する接続が行われる頻度及び時期を一般に制御するネットワークアプリケーションモジュール８５を含む。該ネットワークアプリケーションモジュール８５はまた、ＲＮＳサーバ３２との間で如何なるデータを送受信するかを制御する。
一実施形態では、ＤＶＲ３７は、リクエストリストを解析して各リクエスト毎にファイルを作成することによりＲＮＳサーバ３２からのリクエストを取得することができる。該ファイルは、コンテンツに従って適当に名前を付けることができ、またＸＭＬにフォーマットすることができるものである。リクエストハンドラ１５４は、新しいリクエストがＤＶＲ３７に到着したときが知らされる。これら機能を実行するために、及び一例として、制御ライン３４，６０が、インターネットとの通信のようなネットワーク接続であるものと解釈した場合、ＤＶＲ３７は、インターネットとポイント・ツー・ポイント・プロトコル（ＰＰＰ）接続を確立し、ｈｔｔｐコマンドを介してＲＮＳサーバ３２と通信する。ＤＶＲ３７は、図４Ｄの主記憶装置７８Ｄに示すように、ＨＴＴＰ／ＰＰＰクライアントモジュール１５６を含む。該ＨＴＴＰ／ＰＰＰクライアントモジュール１５６は、ネットワークアプリケーションモジュール８５の制御下で、インターネットへのダイヤルアップアクセスを可能にする通信プロトコルを使用することによりＤＶＲ３７がＲＮＳサーバ３２とＰＰＰ接続を確立することを一般に可能にする。こうすることにより、ＤＶＲ３７からＲＮＳサーバ３２へｈｔｔｐ転送２５３を行うことが可能になる。より詳細には、ＰＰＰ接続は、当業界で周知のように、ポイント・ツー・ポイント・リンクを介して多数の他のプロトコルからのデータグラムを転送するための標準的な方法を提供するインターネットプロトコルを使用する。ＤＶＲ３７とサーバ３２との間のＰＰＰ接続は、通常の電話回線を介した接続を可能にし、これによりＤＶＲ３７がネットワークに参加することが可能となる。インターネットへのゲートウェイに対する電話を切ってリダイヤルする機能に加え、セッションを確立し終了させることによりＰＰＰ接続を可能にする更なる機能をモジュール１５６に設けることができる。各ＤＶＲ３７がクライアントとして機能する点から見て、例えば、ＵＲＬ”ｒｎｓ．ｒｅｐｌａｙｔｖ．ｎｅｔ”に対応する１つのＲＮＳサーバ３２が存在する。ＰＰＰ接続の１つの利点は、（ダイヤルアップコンピュータへファイルを転送して該ファイルをシステム内にダウンロードするのではなく）該ＰＰＰ接続によりＤＶＲ３７とサーバ３２との間の直接のファイル転送が可能となる点である。
代替的には、ＰＰＰ接続は、高速回線ＤＳ１，ＤＳ３内にダイヤルすることにより全二重リンクで実施することができる。
ＤＶＲ３７がＲＮＳサーバ３２とセッション２５３，２５５を確立し、該ＤＶＲ３７へトランザクションファイルをダウンロードすることが可能となる。例えば、ネットワークアプリケーションモジュール８５の制御下での幾つかの例示的な特徴として、（１）フロントエンド１４ａからチャネルガイドデータをダウンロードすること、（２）フロントエンド１４ａから再生ゾーンデータをダウンロードすること、（３）フロントエンド１４ａから新しいソフトウェアアップグレードをダウンロードすること、（４）ＤＶＲ３７からフロントエンド１４ａにログファイル情報をアップロードすることが挙げられる。これら４つの機能を実施する１つの態様は、ＤＶＲ３７がｈｔｔｐリクエストをＲＮＳサーバ３２に提供することであり、該ＲＮＳサーバ３２は、該リクエストに応じてＣＧＩゲートウェイを使用し、ＤＶＲ３７から受信したリクエストを実行するＰｅｒｌスクリプトを呼び出す。
トランザクションファイルを受信するにあたり、ＤＶＲ３７は、図４Ｄに示すように、トランザクションハンドラモジュール１５２を含む。該トランザクションハンドラ１５２は、トランザクションファイルをリクエストへと構文解析し、各リクエスト毎にリクエストハンドラ１５４をコールする。
リクエストハンドラ１５４は、リクエストを実行し、考え得る競合をチェックし、各リクエスト毎にレスポンスを返す。かかるレスポンスの各々は、同実施形態ではＸＭＬでフォーマットすることが可能である。トランザクションハンドラ１５２は、該レスポンスをトランザクションレスポンスファイル中に編集し、及び該ファイルをＲＴＶＳ通信モジュール１５８に返す。該ＲＴＶＳ通信モジュール１５８は、ＲＮＳサーバ３２と通信するためのインターネットに対する定期的かつ自動的なダイヤルアップをネットワークアプリケーション８５が制御する場合に、前記トランザクションレスポンスファイルをＲＮＳサーバ３２にアップロードするよう機能する。
特定の実施形態では、一組のルーチンを他のアプリケーション８７に含めることが可能である。１つのかかるルーチンは、リクエストハンドラ１５４の制御下でリクエストリストを解析することによりリクエストを取得し、及びそれに対応するファイルを作成する。リクエストファイル内に含めることが可能な情報としては、リクエスト識別子、実行すべきコマンド、及び該コマンドを実行することになるターゲットインタフェイスが挙げられる。例えば、リクエストファイルは、再生ガイドインタフェイス上のコマンド「再生チャネルの追加（ＡｄｄＲｅｐｌａｙＣｈａｎｎｅｌ）」に関連付けされた一意の識別子を含むことが可能である。ＤＶＲ３７に新しいリクエストが到達すると、そのことがリクエストハンドラ１５４に知らされて、該リクエストハンドラ１５４が各リクエストを処理してその結果を「結果」ファイル内に配置する。例えば、「結果」ファイルは、一意の識別子に関するコマンドが成功したことの指示、コマンドの実行により生成された特定の結果、及びそれに関連するタイムスタンプを含むよう構成することができる。本書に記載のリクエスト及び結果ファイルは単なる例示的なものであり、他の実施形態もまた本発明と共に適当に良好に機能するものとなる、ということが理解されよう。
ここで、他のアプリケーションモジュール８７に含めることが可能な様々な特徴について説明する。モジュール８７は、リクエストに適応して単一のショーを追加するよう構成することが可能である。該モジュールは、競合又はフリーディスクスペースの利用可能性をチェックした後に、指定された記録イベントを追加するために使用される。次の表１は、かかるモジュールにより使用されるデータ構造を生成するのに有用な例示的なデータを列挙したものである。
【表１】

アプリケーションモジュール８７は更に、ショーベースの再生チャネルを、そのショーからの品質（ｑｕａｌｉｔｙ）及び補償される状態（ｇｕａｒａｎｔｅｅｄ ｓｔａｔｕｓ）を使用して追加する能力を含むことが可能である。好適には、ショーの編数及び期間に基づいて利用可能な記憶スペース８０が計算される。表１に列挙した例示的なデータに加えて、更なるデータ、すなわち、（１）追加すべき再生ショーの名称、及び（２）追加すべき再生チャネルの名称をデータ構造に含めることも可能である。この例示的なデータと同じ組み合わせを使用して、ＤＶＲ３７により受信したリクエストに適応して多数のショーを追加することが可能である。
受信したリクエストがテーマベースの再生チャネルの追加を含む場合には、アプリケーションモジュール８７は、（テーマベースのショーの期間に基づく）利用可能な記憶スペース８０、エンコーダの品質レベル、及び補償される値の指示子を求める機能を含むことが可能である。次の表２は、かかるモジュールにより使用するためのデータ構造を生成するのに望ましい例示的なデータを列挙したものである。
【表２】

ＤＶＲ３７で受信したリクエストはまた、記録リスト中に維持されているスケジューリングされた記録リクエストを削除するためのものとすることが可能である。したがって、アプリケーションモジュール８７は、スケジューリングされたショーを再生チャネル上の記録リストから削除する機能を含むことが可能である。次の表３は、この機能を提供するためにモジュール８７により使用されるデータ構造を生成するのに有用な例示的なデータを列挙したものである。
【表３】

アプリケーションモジュール８７はまた、ＤＶＲ３７で受信した、再生チャネルを削除するためのリクエストに適応する機能を含むことが可能である。この機能を可能にするために、ショーに対応する再生チャネルｉｄを該リクエスト中に与えることになろう。
更に、アプリケーションモジュール８７は、ユーザがチャネルのパラメータ（例えば補償される時間）を変更することを可能にする機能を含むことができる。パラメータが変更されると、再生チャネルが更新され、競合及び利用可能な記憶スペース８０がチェックされ、及び該更新の成功の通知が提供される。
更に、アプリケーションモジュール８７は、スタティック再生チャネルをショーベースの再生チャネルへと変更する機能を提供することが可能である。この機能を容易化することができる例示的なデータとして、（１）再生ショーの名称、及び（２）再生チャネルの名称が挙げられる。
アプリケーションモジュール８７のその他の機能として、受信したリクエストに適応してＤＶＲ３７からの再生ガイド並びにチャネルガイドを取得することが挙げられる。アプリケーションモジュール８７の既述の機能が提供される場合、当業者に理解されるであろう１つの技術的な利点は、ＤＶＲ３７で受信した対応するリクエストをあたかも標準的な対話から生じたものとして扱って「ｔｏ ｄｏ」リスト中に組み込むことが可能である点である。データのプル、プッシュ、又はブロードキャストフローの何れが使用される場合であっても、ＤＶＲ３７は、追加のインフラストラクチャを必要とせず、このため追加の専用のソフトウェアが必要になることもない。
Ｅ．通信システムのバッチ処理のための例示的な方法
ユーザがＤＶＲ３７を制御し又は関連情報にアクセスするための好適な方法のプロセスについて説明する。該プロセスは、図１１に符号１８０で示すようなホームページをユーザがリクエストすることにより開始されるインターネット上でのユーザ認証で始まる。当業者であれば容易に理解されるように、ホームページ１８０を探し出すためにワールドワイドウェブ上のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を利用する。該ユーザが、システム１０Ａ，１０Ｂに対する新規ユーザである場合には、ウェブサーバ２８−１．．．２８−ｎを介して登録を行う機会が該ユーザに提供されることになる。既に登録しているユーザの場合には、該ユーザは、ホームページ１８０から個人情報（例えばユーザ名１８２及びパスワード１８４）を入力することにより、ログインすることができる。認証プロセスの更なる詳細については後述することとする。
認証に成功すると、ウェブサーバ２８−１．．．２８−ｎは、ＡＰＩを介して１つ又は２つ以上のステップを開始して、ユーザがログイン後に見ることになるＤＶＲ３７のユーザインタフェイスを表す情報ウェブページを生成する。この最初の情報ページの一例を図１２Ａに示す。この情報は、デフォルト値により、システム管理により、又はブラウザ１８から発せられたＨＴＴＰリクエスト中に埋め込まれたクッキー情報（すなわち、ブラウザコンピュータ内にローカルで配置された小さなデータファイルすなわちクッキーに格納された、特定のウェブページが特定のブラウザで如何に使用されたかに関する情報）により示すことが可能な状態情報に基づいて生成することが可能である、ということが当業者には理解されよう。例えば、ログインプロセスを完了したばかりのユーザに最終的に返される情報は、図１２Ａに示すようなＥＰＧ（ｅｌｅｃｔｒｏｎｉｃ ｐｒｏｇｒａｍ ｇｕｉｄｅ ｏｆ ｃｈａｎｎｅｌｓ）、再生ガイド、「ショー探索」ページ、及び「マニュアル記録」ページである。後者については以下で更に詳述することとする。
図１３Ａは、ユーザがシステム１０Ａ，１０Ｂから情報を取得し同システムに命令を与えるための１つの方法のプロセス２３０を示すデータフロー図である。図１３Ｂは、図１３Ａのデータフローに関する更なる詳細を示すシーケンス図である。この図全体を通して、データフローライン（「ステップ」と交換可能に称することとする）は、該方法の各部が好適に実施される順序を反映したものである。以下の説明では、図２及び図５も時折参照する。システム１０Ａ，１０Ｂから情報を取得し同システムに命令を与えるプロセス２３０を開始する前に、ユーザは、適当なウェブページ２３１で応答するサーバ２８−１．．．２８−ｎのうちの１つのウェブサイトへナビゲートする（ｎａｖｉｇａｔｅ：進行する）（２２９）。該プロセス２３０は、システム１０Ａ，１０Ｂへのログイン（２３２）で開始する。ユーザは、例えば図１１のユーザインタフェイス１８０に識別情報を入力する。ユーザ名及びパスワードが、図１３Ｂのステップ２３２，２３４，２３６に示すように、クライアントブラウザからデータベースへと送信される。データベース上の所定の情報を用いてユーザが認証されると、図１２Ａに示すようなＥＰＧ等の情報を有する最初の情報ページ１９０が、データベース２３８から受信したデータから生成されて（２４０）クライアントブラウザ２０へと送信される。かかる最初の情報ページ１９０、並びにそれに続くページは、図１２Ｂに示すようなドロップダウンメニュー、並びに図１２Ａに示す「Ｇｏ」ボタン１９２のようなボタンを含むことが可能である。ユーザは、各ドロップダウンメニュー中の所望のエントリを選択し、及び／又は「Ｇｏ」ボタン１９２をクリックして、コマンドを呼び出すことが可能である。こうすることにより、ブラウザ２０は、ステップ２３２に示すように、サーバ２８−１といった既に接続されているウェブサーバにＨＴＴＰリクエストを送る。ドロップダウンメニュー及びボタン駆動機能は、様々な方法で実施することが可能である、ということが当業者には理解されよう。
ＨＴＴＰリクエストがサーバ２８−１で受信されると、該サーバ２８−１は、フローライン２３４に示すように、中間層サーバ４０上のＡＰＩの範囲内で適当なステップを開始し又は適当なファンクションコールを行う。該ステップは更に、中間層サーバ４０とデータベース４４との間の通信（２３６）を伴うものとなる。フローライン２３６は、中間層サーバ４０が、データベース４４からリクエストされた情報を取得し又は該データベース４４に命令を格納するステップを示している。これを行うための１つの方法が、ＪＤＢＣ（Ｊａｖａ（Ｒ） ＤａｔａＢａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ、Ｊａｖａ（Ｒ） データベースＡＰＩとしても知られる）であり、この場合には、生データが中間層サーバ４０からデータベース４４へ送られる。データベース４４は、フローライン２３８に示すように（好適には生形式（ｒａｗ ｆｏｒｍａｔ）で（但し必ずしも生形式である必要はない））リクエストされたデータを中間層サーバ４０に返す。
次いで、中間層サーバ４０は、取り出されたデータ及び更新された情報を組み合わせてフォーマットされたデータを生成し、該データがウェブサーバ２８−１に送られる（２４０）。中間層サーバ４０上のＡＰＩは、生形式で受信されたデータを、データ構造を柔軟に定義するのに良く適した形式へとパッケージ化する（すなわちフォーマットする）、プログラム可能なロジックを含むものである、ということに留意されたい。有利な１つのフォーマットがＸＭＬである。これは、ＸＭＬフォーマットが、共に緊密に結合されていない態様でデータのタグ付け（ｔａｇｇｉｎｇ）を行うことを可能にし、これにより、データ構造を定義する際の一層高い柔軟性が提供されるからである。しかし、ＨＴＭＬを含めた別のフォーマットも、本発明の本書に記載する実施形態で適切かつ良好に動作するものとなる。上記ステップ２４０に続いてステップ２４２が実行され、これにより、次いでサーバ２８−１が、クライアントブラウザ２０に良く適したフォーマット（例えば、ＨＴＭＬ、Ｊａｖａ（Ｒ）、Ｊａｖａ（Ｒ）スクリプト）を有する表現を組み立ててブラウザ２０に送ることになる。代替的な実施形態では、この表現で良好に機能する別のフォーマットは、システム１０Ａ，１０Ｂがワイヤレスメディアによるクライアント−サーバアクセス用に修正される場合には、ＷＭＬ（すなわち、Ｗｉｒｅｌｅｓｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ：携帯電話のブラウザといったワイヤレスデバイスのためのコンテンツ及びユーザインタフェイスを指定するために使用されるＸＭＬ言語）である。当業者には容易に明らかとなるように、図１３Ａに示すプロセスステップは、ユーザリクエスト（例えば情報のリクエスト及び指定した番組を記録するためのリクエスト）に関連する様々な場合に柔軟に適応するものとなる。ステップ２３４’，２３６’，２３８’，２４０’，２４２’は、クライアント１８、サーバ２８、中間層サーバ４０、及びデータベース４４の間の更なる通信を示したものであるが、既述のステップと同様のものである。
中間層サーバ４０は、様々なウェブポータル２８−１．．．２８−ｎとデータベース４４との間のＡＰＩを介した通信を可能にし、フロントエンド１４ａを使用してＤＶＲ３７を制御するためのユーザ命令及び操作に関する通信を容易化するものである。ＡＰＩの１つの技術的な利点は、該ＡＰＩにより、ポータル（例えば２８−２）が、中間層サーバ４０から受信した情報を、ユーザが該情報に興味を持ったときに基づく頻度で、特定のポータル（例えば２８−２）の環境内にローカルにキャッシュすることが可能になる点である。更に、本発明の本書に記載の実施形態のＡＰＩは、ポータル２８−２が、システム管理者が特定のポータル（例えば２８−２）を操作するタイプのグラフィカルユーザインタフェイス（すなわちＧＵＩ）とは異なる所有権を有するタイプのＧＵＩを使用して情報を表示することを可能にするように、中間層サーバ４０からの情報のコンテンツを提示することを可能にする、という柔軟性を有するものとなる。ビジネスロジック（例えば、記録に関する時間の競合やディスクスペースのチェック処理）を中間層サーバ４０に含めて、ポータル２８−１．．．２８−ｎから送られたリクエストを受信し及び対応するレスポンスを送り返す標準化された機構を提供するＡＰＩ部分を形成することが可能である。
ポータル２８−２といったウェブサーバ２８−１．．．２８−ｎがウェブブラウザ２０において対話型テレビ装置のデータを提示するために、各ウェブポータルは、ウェブポータル２８−１．．．２８−ｎの資産（ｐｒｏｐｅｒｔｙ）と完全に又は部分的に接続された状態にあるデータベース４４から受信したコンテンツを、使用し、コピーし、エンコードし、格納し、アーカイブし、分配し、送信し、修正し、変換し、可聴形式に変換し、公的に表示し、及び公的に実行することが可能となっている。該ＡＰＩは、コンテンツをダウンロードし、プリントし、又は実行することを、ウェブポータルがブラウザ２０のユーザに許可することを可能にする。該コンテンツは、対話型テレビ装置のデータ、例えば、最高優先順位で見るべきショーのリスト（ｔｏｐ ｗａｔｃｈｅｄ ｓｈｏｗ ｌｉｓｔ）といったものを含む。本発明の本書に記載の実施形態のＡＰＩは、特定のウェブポータルの形式及び見た目と雰囲気にコンテンツを合わせることを可能にする。
上記議論から明らかなように、ＡＰＩは、本発明の本書に記載の実施形態のフロントエンドにおいて重要な役割を果たすものである。該ＡＰＩは、データ構造定義、中間層サーバ４０とポータル２８−１．．．２８−ｎとの間の通信を容易化する機能、並びにデータベース４４中のデータの取り出し及び操作を行う一連のルーチンを含む。ルーチンとは、データベース４４との通信を含む様々なタスクを実行するために呼び出すことができるＡＰＩ内に存在し該ＡＰＩの一部を形成する各ステップの呼び出し可能なアルゴリズム又はシーケンスを意味するものと定義される。ＡＰＩのルーチンは、ＤＶＲ３７を動作させ又はデータベース４４に格納されている関連情報にアクセスするためにサーバ２８−１．．．２８−ｎにより呼び出すことが可能である。本発明の本書に記載の実施形態で実施されるかかるルーチンのリストを図１４に示す。それに対応する入力パラメータ及び出力ファイルを図１５に示す。ルーチンの名称並びにパラメータ及びファイルの名称は、それぞれの機能を示すものとなるように付され、その殆どは当業者には自明となろう。幾つかの直観性の低い用語については、フロントエンド１４ａの説明で既述のところである。
本発明の１つの特徴は、ユーザがコンピュータネットワークを介して１つ又は２つ以上のデータベースと通信することによりメディアベースのデバイス３６をリモートで動作させることを可能にする点である。図１６Ａに示す本発明の一実施形態を参照すると、ユーザリクエスト２６０は、例えばポータル２８−２といったウェブサーバにより最初に受信され処理される。該ポータル２８−２は、該リクエストをＡＰＩ２６４に対するファンクションコール２６２へと変換する。次いで、ＡＰＩ２６４に埋め込まれたルーチンが呼び出され、これに従って該ＡＰＩ２６４が実施されている中間層サーバ４０が処理を進めて、少なくとも１つのデータベース２６８と通信する（２６６，２７０）。ステップ２６６は、メディアベースのデバイス３６を制御し及び／又はデータベース２６８から関連データを取り出す（２７０）命令を提供することを含む。データベース２６８自体は、図２及び図５で既に説明したように、メディアベースのデバイス３６及びその他の情報ソースと通信可能な状態にあるハブとして構成することが可能である。ポータル２８−２によりコールされた全てのルーチンが実行された後、ポータル２８−２は、ＡＰＩ中のルーチンの実行結果を組み込むことによりユーザリクエストに応答する。
図１６Ｂは、本発明の一実施形態に従って様々なユーザリクエスト２６０に応じてデータベース２６８内のデータに対するアクセス及び操作を行うためにウェブサーバ（例えばポータル２８−２）がＡＰＩルーチンを如何に利用することが可能であるかを高レベルで示したものである。図２及び図５におけるデータベース４４は、単なる例示としてのものであり、４つのデータベース２８０，２８２，２８４，２８６（その各々については以下で説明する）を示す図１６Ｂの実施形態は適切且つ良好に動作するものである、ということに留意されたい。図１６Ｂに示すＡＰＩルーチン２６４は、データベース２６８からデータを抽出し該データベース２６８に命令を挿入するよう構成されている。同図において、データフローの支配的な方向は、各ルーチンを１つ又は２つ以上のデータベースに結合する矢印の方向により示されている。しかし、大量のデータがデータベース２６８との間で転送される前に、幾つかのパラメータ又はトリガデータ（ｔｒｉｇｇｅｒｉｎｇ ｄａｔａ）の交換が生じているものと仮定している。データベース２８０は、ユーザに関する情報を含み、例えば、ＳｉｌｋＮｅｔ（Ｒ）といった商用の認証データベースの複製、及び更なるユーザプロファイルデータから構成される。このデータベースは、ＡＰＩルーチンであるアカウント作成（ＣｒｅａｔｅＡｃｃｏｕｎｔ）２８８、ログイン（Ｌｏｇｉｎ）２９０、及びプロファイル取得（ＧｅｔＰｒｏｆｉｌｅ）２９２によりアクセスされ、それらルーチンは共に、ユーザ認証を行い、及びサーバ２８−１及び中間層サーバ４０を介したユーザとシステム１０Ａ，１０Ｂとの間の通信の初期化を行う。ボックスプロファイルデータベース２８２は、個々のメディアベースのデバイスに関連する情報（個々のチャネルラインナップを含む）をアーカイブする。データベース２６８は、ユーザが動作させることを所望するＤＶＲ３７に特に関連する情報を見るためのユーザリクエストに応じて、プロファイル取得（ＧｅｔＰｒｏｆｉｌｅ）２９４並びにチャネルラインナップ取得（ＧｅｔＣｈａｎｎｅｌＬｉｎｅＵｐ）２９６によりアクセスされる。ＥＰＧデータベース２８４は、オンラインサービス５４等の商用データベースとすることも、商用ソースから既に抽出されている情報を含むデータベースとすることも可能である。このデータベース２８４は、番組情報を取り出すためにＥＰＧ取得（ＧｅｔＥＰＧ）２９８及びショーガイド（ＳｈｏｗＧｕｉｄｅ）３００によりアクセスされる。最後に、ボックストランザクションデータベース２８６は、ＤＶＲ３７により記録された番組に関連する情報、及び将来の番組を記録するためのＤＶＲ３７に対するリクエストを含む。このデータベース２８６は、リクエスト追加（ＡｄｄＲｅｑｕｅｓｔ）ルーチン３０４又はリクエスト削除（ＤｅｌｅｔｅＲｅｑｕｅｓｔ）ルーチン３０６を介してリクエストが行われる度に、中間層サーバ４０と情報を交換する。該データベース２８６はまた、再生ガイド取得（ＧｅｔＲｅｐｌａｙＧｕｉｄｅ）３０２を介して関連情報を見るためのユーザリクエストに応じてアクセスされる。
ＥＰＧ取得ルーチン２９８は、特定のユーザについてカスタマイズされたＥＰＧを取り出す機能を提供する。これを行うための１つの特定の態様は、モジュール２９８が、クライアント１８から受信した命令からのユーザ入力を許可すること及びユーザのＥＰＧのドキュメントを返すことである。例えば、ユーザは、ユーザＩＤ、特定のＤＶＲのＩＤ、リクエストされたＥＰＧの開始時間及び期間、開始チャネル、及び表示すべきチャネルの数といった様々な識別子を含むことが可能である。
チャネルラインナップ取得ルーチン１９６は、特定のＤＶＲ３７のチャネルラインナップを取り出す機能を提供する。このラインナップは、ユーザが例えばユーザＩＤ及び特定のＤＶＲ３７のＩＤを提供した場合に取り出すことが可能である。該取り出される情報は、契約したサービス（例えばケーブル又は衛星ディスクサービス）及びラインナップを（例えば特定のチャネルを削除することにより）カスタマイズしたユーザの嗜好に起因して、様々な番組チャネルのＤＶＲ３７に対する利用可能性によって決まる。実施形態によっては、チャネルラインナップ取得ルーチン２９６に対するコールをＥＰＧ取得ルーチン２９８に埋め込んで、該ＥＰＧ取得ルーチン２９８に対する単一のコールにより特定のユーザ並びに特定のＤＶＲ３７に関してカスタマイズされたＥＰＧを取り出すようにすることが可能である。
ショーガイドルーチン３００は、ユーザＩＤ、ＤＶＲのＩＤ、開始時間、及びリクエストした詳細レベルに基づき、例えばＥＰＧ情報を提供する商用ソース（例えばＴＭＳによる供給（ＴＭＳ ｆｅｅｄ））から入手可能なショーの詳細な説明を取り出す機能を提供する。更に、該ルーチン３００は、ショータイトル、俳優、監督といった属性により示唆されるユーザの関心に適合するショーを見出すために全ての利用可能なショーの詳細情報を探索することができる。かかる場合、ユーザは、突き合わせすべき属性及び単語又は語群を含む照会の基準を提供することができ、ショーガイドルーチン３００は、探索結果としてショーのリストを返すことになる。ＥＰＧ取得ルーチン２９８に関し、実施形態によっては、ショーガイドルーチン３００が、チャネルラインナップ取得ルーチン２９６に対するコールを含むことが可能である。
図１６Ｂに示す殆どの他のルーチンの機能及び機構は、当業者であれば図１４及び図１５において提供した説明に照らして容易に理解されよう。しかし、リクエスト追加ルーチン３０４については図１７に関して更に説明する。該ルーチン３０４は、ユーザが異なるタイプのリクエストを行うことを可能にする一組のルーチンを含む。図１７に示すように、これらのリクエストは、ＤＶＲ３７のステータスを更新するための単純なもの（すなわちリクエストタイプ＝なし）から番組の記録（すなわちリクエストタイプ＝ショー又はリクエストタイプ＝テーマ）及び削除（すなわちリクエストタイプ＝更新）をプログラムするためのものまで及ぶことが可能である。記録リクエストは、ショーにより、又は時間及び番組チャネル（すなわちマニュアル記録リクエスト）により、指定することが可能である。記録リクエストはまた、特定の探索基準に対応し又は（例えば識別子Ｓｕｚｕｋｉにより識別される）再生ゾーンに対応するテーマに基づくものとすることが可能である。
上記の説明は、本発明の一実施形態のフロントエンド１４ａの動作のための基本構成を概説したものである。この構成は、ユーザにより行われたリクエストに応答するための一連のオプションを有するポータル２８−１といったウェブサーバを提供する。これらのオプションは、好適には中間層サーバ４０において実施されるＡＰＩ２６４に基づくものである。以下では、ユーザインタフェイス設計の要素を考慮しつつ、様々なルーチンを呼び出すための幾つかの例示的な方法について説明する。例えば、図１２Ａに示すチャネルガイドについて言及する。ページ１９０が提示されたユーザは、異なる時間範囲及び異なる組をなすチャネルに関するチャネルを見ることが可能である。該ユーザは、メニューバー１９４，１９６，１９８中の適当なオプションを選択して「ｇｏ」ボタン１９２を選択することにより所望の時間及びチャネルにジャンプすることができ、又はボタン１９５，１９７を使用してチャネルガイドを介してナビゲートすることができる。ユーザは、自分が興味のあるショーを見た際に、該ショーを選択し、図１２Ｂに符号２１８等で示すプルダウンメニューにアクセスして該ショーの詳細な説明を見ること又は該選択したショーを記録することが可能となる。ユーザはまた、選択したショーに類似した別のショーを探索すること及び／又は所望する場合に該ショーを記録することが可能である。
図１８は、ユーザが上記のアクションの何れかをとることを予想して２８−１等のウェブサーバがユーザリクエストに応答するための例示的な方法３２０を示すフローチャートである。ウェブサーバ２８−１は、チャネルガイドが最新であること、及び該チャネルガイドに表示される情報が、かかる情報を格納するアクセス対象となる適当なデータベースに含まれる情報と同期していることを最初に確認する（３２２）。しかし、かかる情報が現行のものでない可能性があることに留意されたい。これは、少なくともバッチ処理モードでは、データベースはＤＶＲ３７と定期的な時間間隔をおいてしか通信を行わないからである。ウェブサーバ２８−１が最新のチャネル情報を有していると該ウェブサーバ２８−１が判定した場合には、チャネルガイドが表示される（３２８）。またウェブサーバ２８−１が最新のチャネル情報を有していないと該ウェブサーバ２８−１が判定した場合には、ウェブサーバ２８−１は、チャネルラインナップ取得ルーチン２９６をコールし（３２４）、及びＥＰＧ取得ルーチン２９６をコールして、チャネルガイドを表示する（３２８）前に情報を更新する。チャネルラインナップは、各ＤＶＲ３７に固有のものであり、またＥＰＧデータのフィルタとして必要とされるものであり、これにより、ＤＶＲ３７に対して利用可能とならない番組に関する情報がふるい分けされる。ユーザは、幾つかの事の１つを行うことを選択するまで、上述のようにチャネルガイドを介してナビゲートすることができる。例えば、ユーザがショーの詳細な説明を見ること又は類似するショーを見つけることをリクエストした（３３０）場合、これに応じて、ウェブサーバは、ショーガイドルーチン３００を呼び出し（３３２）、取り出された情報を表示する（３３４）。一方、ユーザが、選択したショーを記録することを選択した（３３６）場合には、ウェブサーバ２８−１は、リクエスト追加ルーチン３０４をコールして（３３８）、更新された情報（例えば、リクエストが処理されたこと又はかかる記録のためのスペースがＤＶＲ３７中に存在しないことを示す情報）を表示する（３４０）。実施形態によっては、該更新された情報は、図１２Ａに示すような修正されたチャネルガイド内に、又は図１９Ａ及び図１９Ｂに示すような再生ガイド内に提示することが可能である。
強調すべきは、サーバ２８−１が、ユーザとユーザインタフェイスの実施形態に応じて該ユーザに対して利用可能となるオプションとに適応することが可能となる態様である。図１８の方法及び上述のオプションは、例えば、図１２Ｂに示すようなドロップダウンメニューを含む、図１２Ａに従って実施されたチャネルラインナップ表示に対応するものとなる。ユーザインタフェイスの異なる実施形態は、別のリクエストオプションをユーザに対して利用可能とするものとなる。例えば、ドロップダウンメニュー２２０，２２２を実施することにより、ユーザがチャネルラインナップ表示ページ中の記録オプションを変更することが可能となる。ユーザインタフェイスに対する同様の依存性が、全ての例示的な方法及びそれに対応する後述のフローチャートに当てはまる。
図１９Ａ及び図１９Ｂに示す再生ガイドは、再生ガイド情報を提示するための１つの方法を示している。図１９Ａの提示３５０は、再生チャネルにより編成された情報を示しており、該提示は、上述のように、個々のショー又は特定のテーマに基づくものとすることが可能である。再生ガイド情報を提示するための代替的な方法が図１９Ｂに示されている。この場合には、記録済のショーが再生ショーページ中に表示される。何れの場合にも、ユーザに対して利用可能となる１つの主たるオプションは、１つ又は２つ以上のショーを削除することである。図１９Ｂの提示の場合には、別のオプションは、将来のショーを記録するために１つ又は２つ以上のリクエストを削除することである。この場合も、再生ガイドの実際の実施形態は、どのオプションがユーザに対して利用可能となるかを判定する。
図２０は、図１９Ａ及び図１９Ｂに示すような再生ガイド情報の提示に対応してウェブサーバ２８−１がユーザリクエストに応答するための例示的な方法３６０を示すフローチャートである。ウェブサーバ２８−１は、該ウェブサーバ２８−１が最新の再生ガイド情報を有しているか否かを判定する（３６２）。ウェブサーバ２８−１が最新の再生ガイド情報を有していない場合には、該ウェブサーバ２８−１は、ステップ３６４でＡＰＩルーチンである再生ガイド取得ルーチン３０２を呼び出し、ステップ３６６でリクエスト追加ルーチン３０４を（「リクエストタイプ＝なし」で）呼び出して、情報を更新する。該リクエスト追加ルーチン３０４の呼び出しは、以前に保留にされたリクエスト（再生ガイド情報がリクエストされたときまでに実行済であっても未実行であっても良い）が存在する場合に必要となる。再生ガイド情報が表示される（３６８）と、ウェブサーバ２８−１は、ユーザからのリクエストを受容して、将来のショーを記録するために以前に記録されたショーを削除し又は以前のリクエストをキャンセルすることが可能となる。記録済のショーの削除がリクエストされる（３７０）と、サーバ２８−１は、リクエスト追加ルーチン３０４を（「リクエストタイプ＝更新 及び 更新タイプ＝ショー削除又はチャネル削除」で）呼び出して（３７２）、該リクエストをボックストランザクションデータベース２８６へ送る。次いで、更新された再生ガイドが表示される（３７４）。保留中のリクエストのキャンセルがリクエストされた場合（３７６）には、サーバ２８−１は、リクエスト削除ルーチン３０６を呼び出してキャンセルを達成し、次いで更新された再生ガイドを表示する（３８０）。この状況では、保留中のリクエストは、データベース４４中にあるリクエストであるが、一般には、リクエストのサーバ４８による処理が完了したこと、又はリクエストのサーバ４８による処理が未完であってデータベース４４により受信もされていないことを示す、ＤＶＲからのレスポンスである。何れの場合も、ボックストランザクションは、バッチプロセスで、例えば、予め設定された次の接続セッションで、ＤＶＲ３７へリクエストを送る。
図２１のフローチャートは、再生ガイド情報が図１９Ｂに示す再生ショー形式で提示される場合に対応するものである。該方法３９０の場合には、ユーザは、保留中のリクエストに対するアクセスを有さないため、記録済のショーの削除しかリクエストすることができない。最初に、ウェブサーバ２８−１は、該ウェブサーバ２８−１が最新の再生ガイド情報を有しているか否かを判定する（３９２）。該ウェブサーバ２８−１が最新の再生ガイド情報を有していない場合には、図１９Ｂの形式の再生ガイドが表示される（３９６）前に再生ガイド取得ルーチン３０２がコールされる。ユーザは、再生ガイド中に列挙されているショーの詳細な説明を見ること又は類似したショーのコレクションを見ることをリクエストする（３９８）ことが可能である。また、かかるリクエストが行われた場合には、ウェブサーバ２８−１は、ＡＰＩルーチンであるショーガイドルーチン３００をコールして情報を取り出し、その結果を表示する（４０２）。ユーザが記録済のショーのリストから選択したショーの削除をリクエストする（４０６）場合には、サーバ２８−１は、リクエスト追加ルーチン３０４を（「リクエストタイプ＝更新 及び 更新タイプ＝ショー削除又はチャネル削除」で）呼び出して、該リクエストをボックストランザクションデータベース２８６を介してＤＶＲ３７に送る。
図２２は、ユーザが特定の基準に基づきショーを探索することを可能にする「ショー探索」ページを示している。図示の例示的な実施形態では、ユーザは、単語又は語群をタイピングし、該単語又は語群に関して探索すべきフィールド（例えばショータイトルフィールド及び説明フィールド）を指定する。図２３は、このショー探索ページから開始されたユーザリクエストにウェブサーバ２８−１が応答するための対応する方法４２０の一実施形態を示したものである。ショー探索ページを表示し（４２２）、ユーザからの探索のための単語又は語群を受信した後、サーバ２８−１は、チャネルラインナップ取得ルーチン２９６をコールし、及びショーガイドルーチン３００をコールして、探索を実行する。探索の基準に合った１つ又は２つ以上のショーが見つかった場合、その結果が表示されて（４３４）、探索の基準により規定されるテーマに基づき再生チャネルを準備すること又は探索結果に列挙されたショーのうちの１つを記録することをユーザがリクエストする（４３６）ことが可能となる。かかるリクエストが行われると、サーバ２８−１は、リクエスト追加ルーチン３０４を呼び出して（４３８）、ＤＶＲ３７と通信可能な状態にあるボックストランザクションデータベース２８６へ該リクエストを送り、更新された情報を表示する（４４０）。探索の基準を満たすショーが見つからなかった場合には、エラーページが表示される（４３２）。
次に、図２４Ａ及び図２４Ｂに示す「マニュアル記録」ページの一例について考察する。ユーザは、将来の記録セッションの日時並びにＤＶＲ３７が記録すべき番組チャネルを指定することができる。図示しないが、図２４Ｂに示すマニュアル記録ページ４５２の代替的な実施形態では、一週間のうちの選択した曜日の指定した時間に繰り返し記録を行うリクエストが可能となる。図２５には、マニュアル記録ページを表示するための方法４６０が示されている。サーバ２８−１は、最初にマニュアル記録ページを表示し（４６２）、マニュアル記録リクエストを処理するために必要な情報を受信する（４６４）。次いで、サーバ２８−１は、リクエスト追加ルーチン３０４を（「リクエストタイプ＝ショー 及び ショータイプ＝単一マニュアル又は反復マニュアル」で）コールして（４６６）、該リクエストをボックストランザクションデータベース２８６を介してＤＶＲ３７へ送り、更新された情報をユーザへ返す（４６８）。
ユーザリクエストに応答するためのウェブサーバ２８−１に関する例示的な方法についての説明を切り上げ、システム１０Ａ，１０Ｂに対するユーザログインを実施するための好適な方法４７０を図２６に示す。図２６のフローチャートは、あらゆるウェブベースのサービスに使用することが可能な方法を表している。ホームページが表示され（４７２）、次いでユーザが、通信を開始した新規ユーザであるか否かを判定する（４７４）。新規ユーザについて収集された（４７６）情報に関し、ウェブサーバ２８−１は、アカウント作成ルーチン２８８をコールする（４７８）。ユーザの入力情報が有効である場合には（４８０）、プロファイル取得ルーチン２９４がコールされて（４８２）、該ルーチンからデフォルトページ４８４が決定され、その他の場合にはエラーページが表示される（４８６）。既存のユーザに関するユーザ名及びパスワードの性質を有する情報が収集された場合には（４８８）、ログインルーチン２９０に対するコールが行われる（４９０）。ユーザ情報の認証（４９２）時に、サーバ２８−１は、プロファイル取得ルーチン２９４をコールした（４８２）後に次に表示すべきデフォルトページ４８４（例えばＥＰＧガイド）を決定する。
２．オン・ザ・フライ処理を介したメディアベースのデバイス及びアプライアンスのリモートコントロールの一実施形態
ここで図１Ｂを再び参照する。同図には、本発明に従ってメディアベースのデバイス及びアプライアンスを通信ネットワークを介してリモートコントロールすることを可能にする、コンピュータベースの通信システム１９の別の一実施形態が示されている。図１Ｂの実施形態では、通信システム１９は、メディアベース／データ統合システム（ｍｅｄｉａ−ｂａｓｅｄ／ｄａｔｅ ｉｎｔｅｇｒａｔｉｏｎ ｓｙｓｔｅｍ）１７（「統合システム１７」と称す）に結合されたネットワークコンピューティングシステム１５を含む。該ネットワークコンピューティングシステム１５は、多数のユーザが、通信システム１９を介して通信を行って、遠隔場所から統合システム１７のメディアベースのデバイス及びアプライアンスに対するアクセス及び制御を行うことを可能にする。統合システム１７は、通信システム１９を介したメディアベースのデバイスへのアクセスを可能にし、これにより、該デバイス及びアプライアンスのスタンドアロン能力が向上する。
図２７は、図１Ｂの通信システム１９の更なる細部を有する通信システム１９Ａの一実施形態を示すブロック図である。図２７に示す実施形態では、通信システム１９Ａは、統合システム１７ａに結合されたネットワークコンピューティングシステム１５ａを含む。特に、例えば、ネットワークコンピューティングシステム１５ａ及び統合システム１７ａは、後述するように両方ともクライアント−サーバコンピュータモデルに基づくものである。
Ａ．フロントエンド及びバックエンドサブシステムの例示的な実施形態
図２７を参照する。同図には、通信システム１９Ａの代替的な実施形態が示されている。この実施形態の１つの技術的な特徴は、クライアント１８上のブラウザ２０がネットワーク２４（インターネット等）を介してほぼリアルタイムの通信レスポンスでメディアベースのデバイス３６と通信する（２２）ことを可能にする。この実施形態では、フロントエンドサブシステム１４ａ及びバックエンドサブシステム１６ａが修正されて、それらの内部のロジックを統合システム１７ａ内の中間層サーバ５００内へと再配置するようになっている。こうすることにより、ネットワークコンピューティングシステム１５ａ及び統合システム１７ａを、互いに通信可能に結合された２つのクライアント−サーバサブシステムとして実施することができる。ネットワークコンピューティングシステム１５ａは、１つ又は２つ以上のクライアントコンピュータ１８（好適にはその上で実行されるウェブブラウザ２０を有するもの）を含む。ネットワークコンピューティングシステム１５ａは更に、ライン２６で示すように、ネットワーク２４と通信可能な状態にある１つ又は２つ以上のサーバコンピュータ２８−１，．．，２８−ｎを含む。本発明を理解する上での便宜及び容易化のため、図２及び図５と同様の符号を図２７で使用している。
統合システム１７ａは、メディアベースのデバイス３６及びＤＶＲ３７を含み、それらは、通信リンク６０，３４，３８を介して複数の中間層サーバ５００のうちの１つと通信可能に結合されている。ＤＶＲ３７及びメディアベースのデバイス３６及びサーバ５００は、クライアント−サーバの関係で動作する。サーバ２８−１，．．，２８−ｎは、データフローライン３０で示すように、サーバ５００と通信可能な状態にある。１つ又は２つ以上のデータベース５０２がサーバ５００に結合される。データベース５０２は、ソース４４，５０，５４（図２７には明示的に示していない）と類似した様々なオンラインソース及びウェブホスティングソースからのデータを編集したものを格納するという性質上、データベース４４と類似したものである。更に、クライアントコンピュータ１８、サーバ２８−１，．．，２８−ｎ、及びメディアベースのデバイス３６（及びＤＶＲ３７）は、図４Ａないし図４Ｄに関して既に説明したものと同様の例示的なハードウェアを含むものである。したがって、これらのデバイスの各々についての詳細な説明は行わず、システム１９Ａの他の特徴に焦点を絞ることとする。
図２８を参照する。同図には、図２７の代替的な実施形態が示されており、該実施形態は、例示として、負荷平衡型の複製された一組をなすデータベース５０２及びアプリケーションサーバを含む。クランチャ及びログミルモジュールが、図９の場合のようなスタンドアロンモジュールではなくアプリケーションサーバモジュールとして書き替えられており、これにより多様なアプリケーションの急速な開発及び展開が可能となる。負荷平衡に良く適した１つの特定の実施形態として、ＢＥＡ Ｓｙｓｔｅｍｓにより提供されるＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ５１０が挙げられ、これは、図２７のサーバ５００に使用可能なものである。
図２８に示すように、該ＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ５１０は、ＴＭＳ ＦＴＳサーバ１１２からデータを抽出し、該抽出したデータをローカライズされたフォーマットに変換する、クランチャアプリケーション１１６を含む。該クランチャアプリケーション１１６は、データベース５０２に格納するためにデータをプール５１２中に集合させるモジュールへＴＭＳデータを送るよう機能するが、もはや図９の場合のようなスタンドアロンモジュールではない。更に、サーバ５１０は、ＲＮＳサーバ３２との通信を可能にするアプリケーションモジュール５１４を含む。別のアプリケーションモジュール５１６は、サーバ５１０がウェブサーバ５１８と通信することを可能にする。モジュール５１４，５１６の両者とも、データベース５０２との間でデータの送受信を行うためにＤＢ接続プール（ＤＢ Ｃｏｎｎｅｃｔｉｏｎ ｐｏｏｌ）５１２に結合される。
ここで図２９を参照して通信システムの別の実施形態５５０について説明する。該通信システム５５０は、ＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ５５２を使用するが、図２８に示したものとは異なる態様で使用する。図２９の実施形態では、ＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ５５２は、データベース５０２に結合され、次いで該データベース５０２が本書で既に説明したＳｉｌｋｎｅｔデータベース５０に結合される。ネットワークコンピューティングシステム１５ａの一部は、サーバ５５２に結合されたウェブサーバ２８を含む。ＲＮＳサーバ３２は、図２８の実施形態とは異なり、図２９ではデータベース５０２と通信可能に結合される。この図２９の実施形態では、通信は、データベース５０２を介して段階的に行われる（ｓｔａｇｅｄ）。一般に、この構成は、より少ないサーバリソースを使用するものとなる。これは、データベース５０２にアクセスするたった１つの手段しかサービスが行われないからである。この実施形態では、データベース５０２は、膨大な数のプロトコルにわたり多数のトランザクションを処理するのとは対照的に、データベース機能の実行に特化したものとされる。アプリケーションサーバ５５２は、かかるトランザクションタスクからデータベースサーバを効果的に保護するものである。特定の実施形態によれば、該サーバ５５２は、一般にＥｎｔｅｒｐｒｉｓｅ Ｊａｖａ（Ｒ） Ｂｅａｎ コンテナ（ｃｏｎｔａｉｎｅｒ）を含み、これにより、クライアント及びサーバの容易な態様での開発が促進される。また、Ａｐａｃｈｅ Ｘｅｒｃｅｓ 及び ＳＡＸ Ｊａｖａ（Ｒ） クラスライブラリ５５４を使用して、ウェブサーバ２８で受信したＸＭＬドキュメントの解析を行うことが可能である。
ここで図３０を参照して通信システムの別の実施形態５６０について説明する。図３０の実施形態では、一連の層が示されており、この場合、各層が、データパイプライン中の特定の機能を実行する。各層に示す構成要素は、明確に定義されたインタフェイスを介して隣接する層と通信する。第１層５６２（「プレゼンテーション層５６２」と交換可能に称する）は、ユーザが見るＨＴＭＬページを生成する。該第１層５６２は、第２層５６４からＸＭＬフォーマットでデータを受信する。該第２層５６４は、「外部インタフェイス層５６４」と交換可能に称することとする。該外部インタフェイス層５６４は、ウェブポータル２８に対して外部的にアクセス可能なインタフェイスを表している。このため、外部インタフェイス層５６４は、プレゼンテーション層５６２と第３層５６６（「データ管理層５６６」と交換可能に称する）との間の媒介として働く。該データ管理層５６６は、全てのデータアクセス及び管理機能をカプセル化する。ＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ の Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（Ｒ） Ｂｅａｎｓサービスを使用して、データ管理層５６６は、データベース５０２，５０に対する接続プールを操作し、トランザクションを管理し、サーバコンポーネントのライフサイクルを管理し、及び必要であれば別の負荷平衡層を提供する。
図３１を参照する。本書に記載のコンピュータベースの通信システムは、高度の耐故障性及びスケーラビリティを提供するよう構成することができる。図３１に示すように、ネットワークインフラストラクチャ５８０は、多数のネットワークセンタ（又はポッド）５８２及び該ポッドにトラフィックを方向付けするグローバル負荷分散装置（ｌｏａｄ ｂａｌａｎｃｅｒ）５８４を用いて動作する。１つのポッド（例えば、Ｗｅｓｔ Ｃｏａｓｔに関連するポッド）しか図示していないが、グローバル負荷分散装置５８４の管理及び制御下で他のポッド（例えば、Ｅａｓｔ Ｃｏａｓｔ又は世界の他の何処かにあるポッド）を含めることが可能である、ということが理解されよう。データベースの必要性をサポートするデータ管理を提供するために、ローカルデータベース５８６を各ポッドに含めることが可能である。更に、メインデータベース５８８（例えば図２のデータベース１２０，１２６）を企業の会社事務所に配置することが可能である。データベースは、該データベースの組み込み能力（ｂｕｉｌｔ−ｉｎ ｆａｃｉｌｉｔｉｅｓ）を使用することにより、及びローカルキャッシング技術により、同期を維持することが可能である。メインデータベース５８８は、アーカイブを行うため又はＴＭＳ等の外部データソース及びＳｉｌｋｎｅｔ等の内部データソースと通信を行うために使用される。
Ｂ．通信システムのリアルタイム処理のための例示的な方法
図２７を再び参照する。２つのクライアント−サーバシステム１５ａ，１７ａを連続して結合することにより、クライアントブラウザ２０とメディアベースのデバイス３６との間の通信をほぼリアルタイム態様で達成することが可能となる。これは、デバイス３６が、もはや中間層サーバ５００との通信を定期的な態様で（すなわちバッチ式に）行うことがなく、サーバ５００及びサーバ２８−１〜２８−ｎとの間でコマンドを送受信することが可能となるからである。
図２７に示すように、メディアベースのデバイス３６は、外部デバイス２８−１〜２８−ｎからのリクエストを操作する中間層サーバ５００と通信する。こうすることにより、ブラウザ２０から行われたリクエストが、ウェブサーバ２８を介して中間層サーバ５００に直接送信され、及びメディアベースのデバイス３６へほぼリアルタイムのレスポンスでオン・ザ・フライで提供されることになる。
中間層サーバ５００の１つの利点は、該中間層サーバ５００が、データベース５０２に対するリアルタイムアクセスを、該データベースのスキーマを露呈させることなく、競合チェックその他のデータ操作機能と共に提供する点である。ウェブサーバ２８は、データベース５０２に対して直接アクセスする必要はなく、中間層サーバ５００上の一組のＡＰＩを介してアクセスする。これは有利である。システム１９Ａのアーキテクチャがスキーマ又はデータベース５０２に依存しないからである。このため、システム１９Ａの残りの部分に必ずしも影響を与えることなく、データベース５０２及びスキーマを変更することが可能である。競合チェックといった更なる機能をシステム１９Ａに容易に追加することが可能である。例えば、追加機能をＪａｖａ（Ｒ）コードでプログラムすることができる。メディアベースのデバイス３６はまた、ＡＰＩを介してデータベース５０２と直接通信することが可能であり、もはや図２及び図５に示すようにサーバ３２，４８と通信する必要はない。このメディアベースのデバイス３６のリアルタイム通信に従事できるという特徴はまた、該デバイス３６が互いに通信することを可能にする。例えば、デバイス３６，３７は、中間層サーバ５００を介して互いに通信することが可能である。一実施形態では、デバイス３６が、ＤＶＲ３７とのオンライン「チャットセッション」の確立又は該ＤＶＲ３７へのＥ−ｍａｉｌの送信を望むことが可能である。一般に、中間層サーバ５００のの２つの部分が存在することになる。中間層サーバ５００の第１部分は、外部のリクエスト（すなわちウェブサーバ２８）を操作し、中間層サーバ５００の第２部分は、メディアベースのデバイス３６及びＤＶＲ３７からのリクエストを操作する。
図２８の特定の実施形態を参照する。ここで、ＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ５１０の幾つかの技術的な利点について説明する。サーバ５１０は、ＡＰＩを介してデータベース５０２にアクセスするための、異なる組をなすクライアントのための単一の方法を提供することが可能であり、これは、数百万というクライアントに関する高いスケーラビリティを達成するための機構である。便宜上、図９及び図２８と類似した構成要素には同様の符号を使用している。図２８では、本発明の理解を容易にするために、ＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ を表す単一のサーバ５１０が単一のデータベース５０２に通信可能に結合されている。しかし、図２８の実施形態は、、多数のミラーリングされた（ｍｉｒｒｏｒｅｄ）データベース５０２へのアクセスを提供する多数の負荷平衡型アプリケーションサーバ５１０をサポートするものである、ということが当業者には理解されよう。
既に詳述した例示的なＡＰＩルーチンは、小さな変更を伴うこの代替的な実施形態と共に適当且つ良好に機能するものである。この場合における最も重要な差は、ＡＰＩルーチンがもはや１つ又は２つ以上のデータベース（この場合にはデータベース５０２）にアクセスする必要がないことである。該ＡＰＩルーチンは、データベースではなくＤＶＲ３７にアクセスするための更なるオプションを（好適にはＲＮＳサーバ３２を介して）認識するようプログラムされるべきである。例えば、一実施形態では、新しいリクエストがインサートされた際に該リクエストのネットワーク化されたＤＶＲを通知する「インサートトリガ」を用いてデータベースを構成することが可能である。ウェブサーバ５１８からのファンクションコールを受信すると、アプリケーションサーバ５１０は、リクエストされた情報がアプリケーションサーバ内の何らかの記憶モジュール中に既に格納されている場合にデータベース５０２若しくはＤＶＲ３７との通信を確立すべきか又はその何れに対しても通信を確立すべきでないかを決定する。しかし、ＡＰＩルーチンに必要とされる如何なる変更も、該ルーチンがメディアベースのデバイスのリモートコントロールを可能にする際に従うことになる全体的な論理的なスキームに影響を与えることはない。
サーバ５１０を使用することの別の利点について以下に説明する。第１に、如何なるソフトウェアの変更もメディアベースのデバイス３６及びＤＶＲ３７に必要とはならない。第２に、外部ウェブサーバ５１８とサーバ５１０との間の通信をＨＴＴＰリクエスト、Ｊａｖａ（Ｒ）サーブレット、又はアプリケーションモジュール５１４，５１６を使用するＪａｖａ（Ｒ）アプリケーションを介して容易化することが可能である。したがって、ＲＮＳサーバ３２は、ＨＴＴＰリクエストをサーバ５１０に直接リダイレクトし、又はＪａｖａ（Ｒ）サーブレットを利用して必要とされるサーバ５１８との通信を実行することになる。第３に、ＲＮＳサーバ３２は、図２及び図５の実施形態の場合のように複数のＲＮＳサーバ３２にわたりミラーリングされた大量のファイルのコレクションをもはや維持する必要がない。その代わりに、図２８に示す代替的な実施形態を用いて、デバイス３６及びＤＶＲ３７によりリクエストされ提供されたデータの全てがＲＮＳサーバ３２によりサーバ５１０へと仲介される。第４に、全てのデータがデータベース５０２上に格納された際に、サーバ５１０上で実行されているクランチャアプリケーション１１６は、もはやファイルを処理して複数のＲＮＳサーバ３２間で分配する必要がなくなる。図２８の実施形態の場合、クランチャアプリケーション１１６は、ＴＭＳサーバ１１２からＥＰＧデータを取り出し、該取り出したＥＰＧデータを使用してチャネルガイドを構築し、該構築したチャネルガイドをデータベース５０２に格納する。第５に、サーバ５１０を単一のアクセスポイントとして使用してデータベース５０２に格納されているデータにアクセスするように多数のアプリケーションを開発することが可能である。これは、スケーラビリティ及びセキュリティを改善するだけでなく、メディアベースのデバイス３６及びＤＶＲ３７のための新たなアプリケーションを容易に且つ急速に開発する能力を改善するものとなる。
図２及び図５に示す実施形態の場合とは対照的に、ウェブサーバ５１８は、もはやＴｏｍｃａｔ（Ｒ）サーバと通信する必要がなくなり、ＡＰＩの負荷平衡を実施するためにＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ５１０と通信することになる。更に、これらの実施形態は、システムの冗長性を提供する場合に、すなわち、１つ又は２つ以上のサーバが動作不能になった場合又は特定のサーバで過負荷が生じた場合に、有利なものである。したがって、ウェブサーバ５１８及びメディアベースのデバイス３６からのＨＴＴＰリクエストは、ＷｅｂＬｏｇｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ５１０に送られて分散されることになる。
特定の実施形態に関して本発明をかなり詳細に説明してきたが、他の実施形態もまた実施可能である。当業者には理解されるように、本発明は、その本質的な特徴から逸脱することなく他の特定の形態で実施することが可能である。したがって、本発明は、特許請求の範囲及びその等価物の思想及び範囲に含まれるかかる代替例、修正例、及び変形例の全てを包含することを意図したものである。
【図面の簡単な説明】
【図１Ａ】
メディアベースのデバイス及びアプライアンスの通信ネットワークを介したリモートコントロールを可能にする本発明によるコンピュータベースの通信システムを示す高レベルブロック図である。
【図１Ｂ】
図１Ａのコンピュータベースの通信システムの代替的な実施形態を示す高レベルブロック図である。
【図２】
本発明による図１Ａのコンピュータベースの通信システムの第１の実施形態を示すブロック図である。
【図３】
本発明によるクライアントベースのコンピュータ、サーバ、及びメディアベースのデバイスのためのハードウェアの一実施形態を示すブロック図である。
【図４Ａ】
クライアントコンピュータの主記憶装置を示すブロック図である。
【図４Ｂ】
サーバの主記憶装置を示すブロック図である。
【図４Ｃ】
中間層サーバの主記憶装置を示すブロック図である。
【図４Ｄ】
メディアベースのデバイス及びアプライアンスの主記憶装置を示すブロック図である。
【図５】
図１Ａのコンピュータベースの通信システムの代替的な実施形態を示すブロック図である。
【図６】
バッチリクエストサーバの主記憶装置を示すブロック図である。
【図７】
クライアントユーザ及びＤＶＲに関する関連情報を示す例示的な分類図（ｃｌａｓｓ ｄｉａｇｒａｍ）である。
【図８】
ＲＮＳサーバの主記憶装置を示すブロック図である。
【図９】
ＲＮＳサーバがオンラインソースからＥＰＧデータを受信することを可能にする本発明によるバックエンドの一実施形態を示すブロック図である。
【図１０】
本発明によるディジタルビデオレコーダを有する対話型テレビジョンサブシステムの例示的な実施形態を示すブロック図である。
【図１１】
本発明のコンピュータベースの通信システムにログインしアクセスするための例示的なユーザインタフェイスを図式的に示す説明図である。
【図１２Ａ】
番組ガイド情報を示すための例示的なユーザインタフェイスを図式的に示す説明図である。
【図１２Ｂ】
図１２Ａのユーザインタフェイスのための例示的なドロップダウンメニューを図式的に示す説明図である。
【図１３Ａ】
図１Ａのコンピュータベースの通信システム全体を通したデータの流れを示すブロック図である。
【図１３Ｂ】
図２及び図５のコンピュータベースの通信システムのフロントエンドにログインすると共にそのバックエンドで「バッチ」通信を行うための一実施形態を示すシーケンス図である。
【図１４】
本発明によるＡＰＩの一実施形態で実施される機能及びそれに対応する機能を列挙した表である。
【図１５】
本発明によるＡＰＩの一実施形態で実施される機能及びそれに対応する入力パラメータ及び出力ファイルを列挙した表である。
【図１６Ａ】
本発明によるフロントエンドの実装の一実施形態を示す高レベルブロック図である。
【図１６Ｂ】
図１６ＡのフロントエンドにおけるＡＰＩの更なる詳細を示すデータフローのブロック図である。
【図１７】
ＡＰＩの一部として実施されるリクエスト追加ルーチンにより扱われる多数のリクエストを示すチャートである。
【図１８】
図１２Ａのユーザインタフェイスに基づくユーザリクエストに応答する機構を実施するための方法の一実施形態を示すフローチャートである。
【図１９Ａ】
再生チャネルにより編成された再生ガイド情報を示すための例示的なユーザインタフェイスを図式的に示す説明図である。
【図１９Ｂ】
記録済ショー（Ｒｅｃｏｒｄｅｄ Ｓｈｏｗ）により編成された再生ガイド情報を示すための例示的なユーザインタフェイスを図式的に示す説明図である。
【図２０】
図１９Ａに示すユーザインタフェイスに基づくユーザリクエストに応答する機構を実施するための１つの方法を示すフローチャートである。
【図２１】
図１９Ｂに示すユーザインタフェイスに基づくユーザリクエストに応答する機構を実施するための１つの方法を示すフローチャートである。
【図２２】
ショー探索ページに基づいて探索を実行するための例示的なユーザインタフェイスを図式的に示す説明図である。
【図２３】
図２２に示すユーザインタフェイスに基づくユーザリクエストに応答する機構を実施するための１つの方法を示すフローチャートである。
【図２４Ａ】
マニュアル記録ページに関する単一の記録を示すための例示的なユーザインタフェイスを図式的に示す説明図である。
【図２４Ｂ】
反復マニュアル記録のための例示的なユーザインタフェイスを図式的に示す説明図である。
【図２５】
図２４Ａに示すユーザインタフェイスに基づくユーザリクエストに応答する機構を実施するための１つの方法を示すフローチャートである。
【図２６】
ユーザログインプロセスを実施するための１つの方法を示すフローチャートである。
【図２７】
本発明による図１Ｂのコンピュータベースの通信システムの一実施形態を更に詳細に示すブロック図である。
【図２８】
図１Ｂのコンピュータベースの通信システムの代替的な一実施形態を示すブロック図である。
【図２９】
コンピュータベースの通信システムの代替的な一実施形態を示すブロック図である。
【図３０】
図２８のコンピュータベースの通信システムを詳細に示すブロック図である。
【図３１】
負荷平衡型（ｌｏａｄ−ｂａｌａｎｃｅｄ）コンピュータベースの通信システムのための分散アーキテクチャを示す高レベルブロック図である。
【符号の説明】
１０Ａ　　　　 通信システム
１２ａ　　　　 ネットワークコンピューティングシステム
１４ａ　　　　 データ統合システム
１６ａ　　　　 メディアベースのコンピューティングシステム
１８　　　　　クライアントコンピュータ
２８−１〜２８−ｎ　サーバコンピュータ
３２　　　　　ＲＮＳサーバ
３６　　　　　メディアベースのデバイス及びアプライアンス
３８　　　　　ネットワーク
４４，５０　　　 データベース
４８　　　　　バッチリクエストサーバ
５４　　　　　オンラインサービス

Claims (54)

1. ネットワークに通信可能に結合された第１サーバからコマンドを受信したことに応じて１つ又は２つ以上のデータソースからデータを抽出し、
   前記コマンドを前記抽出されたデータと組み合わせて、メディアデバイスを動作させるためのインタフェイスに対応する統合化された提示を形成し、
   前記ネットワークに結合されたクライアント上に表示するために前記統合化された提示を前記第１サーバに送信する、
   という各ステップ含む、前記ネットワークを介して前記メディアデバイスの動作をシミュレートする方法。
2. 前記第１サーバによりウェブホスティングされた第２サーバが前記コマンドを受信する、請求項１に記載の方法。
3. 前記第２サーバが、前記メディアデバイスの動作に関連する機能をカプセル化するために複数のオブジェクトのインスタンスを生成し、該オブジェクトが、前記メディアデバイスを動作させるためのプログラム可能なインタフェイスを含む、請求項２に記載の方法。
4. 前記メディアデバイスの動作が、前記プログラム可能なインタフェイスを使用してシミュレートされる、請求項３に記載の方法。
5. 前記コマンドのうちの１つにより、前記第１サーバが前記コマンドを受信するために前記第２サーバにアクセスする、請求項２に記載の方法。
6. 前記統合化された提示がＸＭＬ形式で送信される、請求項１に記載の方法。
7. 前記データソースが、データベース、前記メディアデバイス、及びオンラインサービスを含む、請求項１に記載の方法。
8. 前記データソースが、電子的な形式を有する放送番組ガイドを含む、請求項１に記載の方法。
9. 前記ネットワークがインターネットを含む、請求項１に記載の方法。
10. 前記メディアデバイスがディジタルビデオレコーダを含む、請求項１に記載の方法。
11. 前記インタフェイスが、ログインインタフェイス、チャネルガイド、再生ガイド、再生ショー、再生チャネル、ショー探索、及びマニュアル記録からなる一群のインタフェイスから選択される、請求項１に記載の方法。
12. 前記クライアントがブラウザを含む、請求項１に記載の方法。
13. 第１サーバにアクセスしてウェブホスティングされたアプリケーションを起動し、該ウェブホスティングされたアプリケーションが、メディアデバイスと通信して該メディアデバイスからデータを抽出することが可能なものであり、
    前記ウェブホスティングされたアプリケーションにより形成されると共に前記第１サーバへのアクセスに応じて該第１サーバにより送られる１つ又は２つ以上の統合化された提示を受信し、該統合化された提示の各々が、メディアデバイスの対応するインタフェイスを複製するために抽出されたデータを含み、
    前記インタフェイスの一部を選択して１つ又は２つ以上のコマンドを開始して前記メディアデバイスを動作させる、
    という各ステップを含む、ウェブホスティングされたアプリケーションを介してメディアデバイスを動作させる方法。
14. 前記ウェブホスティングされたアプリケーションが、受信したコマンドを前記メディアデバイスに送信して該メディアデバイスを動作させる、請求項１３に記載の方法。
15. 前記ウェブホスティングされたアプリケーションが、前記メディアデバイスの動作に関連する機能をカプセル化するために複数のオブジェクトのインスタンスを生成し、該オブジェクトが、前記メディアデバイスを動作させるためのプログラム可能なインタフェイスを含む、請求項１３に記載の方法。
16. 前記プログラム可能なインタフェイスを使用して前記メディアデバイスを動作させるステップを更に含む、請求項１５に記載の方法。
17. 前記コマンドのうちの１つによって前記第１サーバが前記第２サーバにアクセスし、前記ウェブホスティングされたアプリケーションが該第２サーバ上で実行される、請求項１３に記載の方法。
18. 前記統合化された提示がＸＭＬ形式で送信される、請求項１３に記載の方法。
19. 前記抽出されたデータを、前記ウェブホスティングされたアプリケーションにより受信された１つ又は２つ以上のデータソースからの更なるデータと組み合わせることにより、前記統合化された提示が形成される、請求項１３に記載の方法。
20. 前記データソースが、データベース及びオンラインサービスを含む、請求項１９に記載の方法。
21. 前記データソースが、電子的な形式を有する放送番組ガイドを含む、請求項１９に記載の方法。
22. 前記第１サーバへのアクセスが、ＨＴＴＰリクエストをインターネットを介して該第１サーバへ送ることを含む、請求項１３に記載の方法。
23. 前記メディアデバイスが、ディジタルビデオレコーダ、パーソナルディジタルアシスタント、携帯電話、及びページャからなる一群から選択される、請求項１３に記載の方法。
24. 前記インタフェイスが、ログインインタフェイス、チャネルガイド、再生ガイド、再生ショー、再生チャネル、ショー探索、及びマニュアル記録からなる一群のインタフェイスから選択される、請求項１３に記載の方法。
25. 前記データが定期的に抽出される、請求項１３に記載の方法。
26. 前記データがオン・ザ・フライで抽出される、請求項１３に記載の方法。
27. 既存の情報とメディアデバイスを含む複数のデータソースから抽出されたデータとのローカルな表現を維持し、
    前記既存の情報を前記抽出されたデータと組み合わせることにより統合化された提示を形成し、
    クライアントからの指示を受信したことに応じて該クライアント上に表示するために前記統合化された提示をネットワークコンピューティングシステムに送信し、
    前記統合化された提示の一部が選択されたことに応じて前記クライアントからコマンドを受信し、該コマンドが、前記メディアデバイス上で実行すべき動作を表すものであり、
    前記ローカルな表現を前記コマンドを用いて更新し、
    該コマンドを前記メディアデバイスに送って該メディアデバイス上で前記動作を実行する、
    という各ステップを含む、少なくとも１つのメディアデバイスを遠隔制御する方法。
28. 前記ネットワークコンピューティングシステムが、ネットワークに通信可能に結合された少なくとも１つのウェブサーバを含み、該ウェブサーバが、前記ネットワークを介して前記統合化された提示を受信し前記クライアントに転送する、請求項２７に記載の方法。
29. 前記ネットワークがインターネットを含む、請求項２８に記載の方法。
30. 前記データソースが、データベース及びオンラインウェブサイトからなる一群から選択される、請求項２７に記載の方法。
31. 前記統合化された提示が、前記メディアデバイスに関するユーザインタフェイスの仮想的な表現を含む、請求項２７に記載の方法。
32. 前記ローカルな表現を維持する前記ステップが、既存の情報及びデータベース上のデータを格納することを含む、請求項２７に記載の方法。
33. 前記メディアデバイスの動作に関連する機能をカプセル化するために複数のオブジェクトのインスタンスを生成するステップを更に含み、該オブジェクトが、前記メディアデバイス上での動作を呼び出すためのプログラム可能なインタフェイスを含む、請求項２７に記載の方法。
34. 前記プログラム可能なインタフェイスを使用して前記メディアデバイスにコマンドを送るステップを更に含む、請求項３３に記載の方法。
35. 前記統合化された提示がＸＭＬ形式で送信される、請求項２７に記載の方法。
36. 前記データソースが電子的な形式を有する放送番組ガイドを含む、請求項２７に記載の方法。
37. 前記メディアデバイスがディジタルビデオレコーダを含む、請求項２７に記載の方法。
38. 前記統合化された提示が、ログインインタフェイス、チャネルガイド、再生ガイド、再生ショー、再生チャネル、ショー探索、及びマニュアル記録からなる一群のインタフェイスから選択される、請求項２７に記載の方法。
39. 前記クライアントがブラウザを含む、請求項２７に記載の方法。
40. 前記ローカルな表現が定期的に維持される、請求項２７に記載の方法。
41. 前記ローカルな表現がオン・ザ・フライで維持される、請求項２７に記載の方法。
42. 負荷平衡化された構成で分散された１つまたは２つ以上のメディアデバイスを有する第１サブシステムと、
    該第１サブシステムに結合された第２サブシステムであって、前記メディアデバイスの各々から複製された１つ又は２つ以上のユーザインタフェイスの仮想的な表現を維持する、第２サブシステムと、
    該第２サブシステムに結合された第３サブシステムであって、前記仮想的な表現を表示し、及び選択されたユーザインタフェイスの部分に基づき前記メディアデバイスの動作をシミュレートする、第３サブシステムと
    とを含むシステム。
43. 前記ユーザインタフェイスが定期的に複製される、請求項４２に記載のシステム。
44. 前記第３サブシステムが、ネットワークに通信可能に結合された少なくとも１つのウェブサーバを含み、該ウェブサーバが、ネットワークを介して前記仮想的な表現を受信し表示のためにクライアントに転送する、請求項４２に記載のシステム。
45. 前記ネットワークがインターネットを含む、請求項４４に記載のシステム。
46. 前記第２サブシステムが、前記仮想的な表現を格納している少なくとも１つのデータベースを含む、請求項４４に記載のシステム。
47. 前記第２サブシステムが、第１サーバ及び第２サーバを含み、該第１サーバが前記メディアデバイスと定期的に通信し、前記第２サーバが対応するウェブサーバを介して前記クライアントに前記仮想的な表現を転送する、請求項４６に記載のシステム。
48. 前記クライアントがブラウザを含む、請求項４４に記載のシステム。
49. 前記メディアデバイスの各々がディジタルビデオレコーダを含む、請求項４２に記載のシステム。
50. 前記インタフェイスが、ログインインタフェイス、チャネルガイド、再生ガイド、再生ショー、再生チャネル、ショー探索、及びマニュアル記録からなる一群のインタフェイスから選択される、請求項４２に記載の方法。
51. ネットワークを介してメディアデバイスの動作をシミュレートするためのコンピュータプログラム製品であって、コンピュータにより読み出しを行うことが可能な媒体上に格納されており、
    ネットワークに通信可能に結合された第１サーバからコマンドを受信したことに応じて１つ又は２つ以上のデータソースからデータを抽出し、
    前記コマンドを前記抽出したデータと組み合わせて、メディアデバイスを動作させるためのインタフェイスに対応する統合化された提示を形成し、
    前記ネットワークに結合されたクライアント上に表示するために前記統合化された提示を前記第１サーバに送信する、
    という各動作を実行するよう構成されている、コンピュータプログラム製品。
52. ウェブホスティングされたアプリケーションを介してメディアデバイスを動作させるためのコンピュータプログラム製品であって、コンピュータにより読み出しを行うことが可能な媒体上に格納されており、
    第１サーバにアクセスしてウェブホスティングされたアプリケーションを起動し、該ウェブホスティングされたアプリケーションが、メディアデバイスと通信して該メディアデバイスからデータを抽出することが可能なものであり、
    前記ウェブホスティングされたアプリケーションにより形成されると共に前記第１サーバへのアクセスに応じて該第１サーバにより送られる１つ又は２つ以上の統合化された提示を受信し、該統合化された提示の各々が、前記メディアデバイスの対応するインタフェイスを複製するために抽出されたデータを含み、
    前記インタフェイスの一部を選択して１つ又は２つ以上のコマンドを開始して前記メディアデバイスを動作させる、
    という各動作を実行するよう構成されている、コンピュータプログラム製品。
53. 少なくとも１つのメディアデバイスを遠隔制御するためのコンピュータプログラム製品であって、コンピュータにより読み出しを行うことが可能な媒体上に格納されており、
    既存の情報とメディアデバイスを含む複数のデータソースから抽出されたデータとのローカルな表現を維持し、
    前記既存の情報を前記抽出されたデータと組み合わせることにより統合化された提示を形成し、
    クライアントからの指示を受信したことに応じて該クライアント上に表示するために前記統合化された提示をネットワークコンピューティングシステムに送信し、
    前記統合化された提示の一部が選択されたことに応じて前記クライアントからコマンドを受信し、該コマンドが、前記メディアデバイス上で実行すべき動作を表すものであり、
    前記ローカルな表現を前記コマンドを用いて更新し、
    該コマンドを前記メディアデバイスに送って該メディアデバイス上で前記動作を実行する、
    という各動作を実行するよう構成されている、コンピュータプログラム製品。
54. ウェブホスティングされたアプリケーションを実行している第１サーバに少なくとも１つのクライアントのブラウザからアクセスし、
    該ウェブホスティングされたアプリケーションがデータベースにアクセスして、メディアベースのデバイスから受信したユーザインタフェイス情報を前記ブラウザ上に表示し、
    ユーザの指示を受信して前記ユーザインタフェイス情報を変更し、
    前記第１サーバが、前記メディアベースのデバイスへのアーカイブ及び転送のために前記ユーザの指示を前記ウェブホスティングされたアプリケーションのデータベースに送る、
    という各ステップを含む、ウェブホスティングされたアプリケーションを介してメディアベースのデバイスに対する制御入力を提供するためのコンピュータにより実施される方法。

Images