JP5437998B2 - ユーザデバイスを経由したアイテムの消費 - Google Patents

Description

この出願は、２００７年６月１4日に申請された米国特許出願No. 11/763,374(AM2-0073US) の継続出願であり、それは２００７年５月２１日に申請された米国仮出願 No. 60/939,357(AM2-0073USP1) の利益を要求するものであって、その双方の出願は、その全体を参照することによって本書に組み込まれる。

ユーザは伝統的に本、雑誌、新聞等などのメディアアイテムをハードコピーの形で消費してきた。例えば、実物の本を書店または図書館から得ることができる。ユーザは指先でページをめくるという従来の方法で本を読むことができる。

ユーザはまた電子的な形でメディアアイテムを受け取り、消費することもできる。例えばパソコンを使用して、ユーザは従来の電話またはケーブルモデムを経由して、ネットワークアクセス可能なメディアアイテムの情報源に接続することができる。ユーザはこの情報源からドキュメントをダウンロードできる。ユーザはそのドキュメントをプリントアウトして、従来の方法で読むことができる。あるいは電子的な形、つまりコンピュータのモニター上に表示された形で読むこともできる。

電子メディアアイテムの提供者は様々な課題に直面する。例えば、電子的な形で利用できるにもかかわらず、多くのユーザは従来のハードコピーの形でメディアアイテムを消費し続けることを好む。提供者はそのようなユーザの興味を引き付けると同時に、技術的な観点とビジネスに関連した観点から実現可能な解決策を提供するという課題に直面している。

アイテムをユーザデバイスへダウンロードするシステムを説明した概観を示す図である。 ワイヤレス通信を利用した図１のシステムの実施形態の一例を示す図である。 図２のシステムを利用する為の実例となるアイテム提供システム（ＩＰＳ）とユーザデバイスを示す図である。 図３の例示ユーザデバイスをさらに詳細に描写したものを示す図である。 図３と図４のユーザデバイスの実例となるデザインを示す図である。 図５のユーザデバイスとやりとりするための実例となるユーザーインターフェースの仕組みを示す図である。 図２と図３で示されるシステム側面を実現するために使用される、汎用的な処理装置を示す図である。 図２と図３のシステムの動作について、一つの例示的な方法を描いた信号ダイアグラムである。 図３のＩＰＳで使用する為のコンテンツ受入れシステムの概観を示す図である。 図３のＩＰＳで使用する為の実例となる予約購読モジュールを示す図である。 図３のＩＰＳで使用する為の実例となるインデックス生成機能と、注釈処理機能を示す図である。 図９のコンテンツ受入れシステムを使用して、電子書籍および他のあらかじめ生成されたアイテムを受け取って処理する為の一つの実例となる方法を描く信号ダイアグラムである。 図９のコンテンツ受入れシステムを使用して、予約購読に関連したアイテムを受け取って処理する為の一つの実例となる方法を描く信号ダイアグラムである。 図９のコンテンツ受入れシステムを使用して、個人アイテムを受け取って処理する為の一つの実例となる方法を描く信号ダイアグラムである。 図９のコンテンツ受入れシステムを使用して、電子書籍と他のあらかじめ生成されたアイテムを受け取って処理する為の一つの実例となる方法を描くフローチャートである。 図９のコンテンツ受入れシステムを使用して、予約購読に関連したアイテムを受け取って処理する為の一つの実例となる方法を描くフローチャートである。 図９のコンテンツ受入れシステムを使用して、個人アイテムを受け取って処理する為の一つの実例となる方法を描くフローチャートである。 図３のＩＰＳで使用するための実例となるto-doリストサーバモジュールを示す図である。 図１８のto-doリストサーバモジュール動作について、一つの実例となる方法を描くフローチャートである。 図１８のto-doリストサーバモジュールの管理について、一つの実例となる方法を描くフローチャートである。 図３のユーザデバイスで使用する為の実例となるto-doリストプロセッサを示す図である。 図２１のto-doリストプロセッサの動作について、一つの実例となる方法を描くフローチャートである。 図３のＩＰＳで使用する為の実例となるコンテンツ配送モジュールを示す図である。 図２３のコンテンツ配送モジュールの動作について、一つの実例となる方法を描くフローチャートである。 アイテム受領時に、ユーザデバイスがそれを処理する一つの実例となる方法を描くフローチャートである。 各バージョンが一つ以上の点で以前のバージョンと異なる、一連のバージョンを示す図である。 複数の差分ファイル形成のため図２３のコンテンツ配送システムによって行われる、実例となるデルタ形成処理を描くフローチャートである。 図２７の手順で生成された差分ファイルを利用して図２３のコンテンツ配送モジュールによって行われる、実例となるサーバ側の増分更新処理を描くフローチャートである。 図２８のサーバ側手順を補完するための、実例となるデバイス側の増分更新処理を描くフローチャートである。 図２または図３のシステムで使用することができる様々なコンテンツ配送管理機能を示す図である。 図３０で特定される確実なフルフィルメント処理機能の実行について、実例となる方法を描くフローチャートである。 図３０で識別される遅延通知機能の実行について、実例となる方法を描くフローチャートである。 図３０で識別されるテレフォン ホーム（ＴｅｌｅＰｈｏｎｅ Ｈｏｍｅ、ＴＰＨ）処理機能の動作について、実例となる方法を描くフローチャートである。 図３０の予約購読開始機能の動作について、一つの実例となる方法を描くフローチャートである。 図４で示されるホーム提示モジュールによって作られた実例となるホームページである。 図３５で示されるホームページのコンテキストで提供される、実例となるメニューである。 図３５で示されるホームページを通じてアクセスされる、実例となるセットアップページである。 図３のＩＰＳでの使用のため、実例となるマーチャントストア モジュールを示す図である。 図３８の店舗モジュールで作られた、実例となるホームページである。 図３８の店舗モジュールで作られた、実例となる閲覧ページである。 図３８の店舗モジュールで作られた、実例となるアイテム詳細ページである。 図３８のマーチャントストア モジュールでなされた購入の実例となる取り消し方法を描くフローチャートである。 図３のＩＰＳとユーザデバイスでそれぞれ使用される、実例となるサーバ側メディアライブラリモジュールと、デバイス側コンテンツ管理モジュールを示す図である。 図４３のコンテンツ管理モジュールで作られた、実例となるコンテンツ管理ページを示す図である。 図４４のコンテンツ管理ページのコンテキストで提供される、実例となるメニューを示す図である。 図４４のコンテンツ管理ページのコンテキストで提供される、実例となる別のメニューを示す図である。 図３のＩＰＳとユーザデバイス間の情報を同期化させるための、実例となる方法を描くフローチャートである。 図２と図３で示されるリーダー(reader)モジュールで作られた,実例となるアイテム表示ページである。 ページの中で動的にリンクを生成するための、実例となる方法を描くフローチャートである。 図４８のアイテム表示ページのコンテキストで表示される注釈関連メニューを示す図である。 図４８のアイテム表示ページのコンテキストで提供される実例となるプログレスバーである。 図３と図４で説明されたユーザデバイスにおける、オーディオ配送、管理、再生機能を示す図である。 実例となる閲覧プロキシモジュールの使用を強調した、図２のシステムの修正描写である。 図５３の閲覧プロキシモジュールの動作の、実例となる方法を描いたフローチャートである。 図４のブラウザーモジュールで作られる、実例となるホームページである。 図４のブラウザーモジュールを使ってアドレスの入力時に使用する、実例となるユーザーインターフェースのパネルの説明を示す図である。 システムによって実行される様々な管理機能を強調した、図２のシステムの修正描写である。 ＩＰＳが定期的に一つ以上の代表的なユーザデバイス対し、テストプローブを送る図５７のテスティング機能の動作について、一つの実例となる方法を描くフローチャートである。 マニュアルモードのアップグレードに対応した、図５７のアップグレード関連の機能の動作について、一つの実例となる方法を描くフローチャートである。 自動モードのアップグレードに対応した、図５７のアップグレード関連の機能の動作について、一つの実例となる方法を描くフローチャートである。 図３のユーザデバイスへアップグレードを転送するために使用される、実例となるフォーマットを示す図である。 実例となるプロビジョニング機能の使用を強調した、図２のシステムの修正描写である。 新しいデバイスの購入後、購入したユーザが特定のユーザデバイスと結びつく前の段階で、アイテム購入品をバーチャルアカウントに結びつける実例となる方法を描くフローチャートである。 テストデバイスと代表的なデバイスアンダーテスト（ＤＵＴ）を含む、実例となるアレンジメントの説明を示す図である。 図６４のアレンジメントの動作について、実例となる方法を描くフローチャートである。

本開示および全ての図面を通して、同様の構成要素には、それを参照するために同じ番号が用いられる。１００番台は、図１に初出する機能を参照し、２００番台は、図２に初出する機能を参照し、３００番台は、図３に初出する機能を参照するなどとなる。

一つの実例となる実施形態に従って、この開示はアイテムをユーザデバイスへダウンロードするための機能を説明する。この機能は様々なシステム、モジュール、コンピュータで読み取り可能な媒体、データ構造、方式や他の形で明らかとなり得る。

上記の「アイテム」とは、どのタイプのコンテンツにも対応する。例えば、アイテムはデジタルメディアアイテムに対応する。メディアアイテムは制限なしに、テキストコンテンツ、画像コンテンツ、音声コンテンツ、ビデオコンテンツ、ハイパーテキスト・プロトコルコンテンツなど、およびこれらの種類のコンテンツのいかなる組み合わせをも含む。それに加え、又は代替として、アイテムはマシン読み取り可能なプログラムコードや、マークアップ言語コンテンツ、スクリプトコンテンツなどの命令を含むコンテンツを含み得る。例えば、アイテムはソフトウェア アップグレードのようなものに対応する。

さらに具体的に述べると、例えば「アイテム」という言葉は、本（例えば「電子書籍」）、雑誌の一つの号などの、売買可能なコンテンツの特定の単位を指し得る。代替として、アイテムは本の中の一章、アルバムの中の一曲など、より小さな売買可能な単位の部分を指す場合がある。またその代わりに、アイテムは、ある方法で関連づけられた、一つの大きな要素アイテムの収集物を指すこともある。例えば、アイテムは、ある年の雑誌の複数号を指し得る。

「エントリー」という言葉は、アイテムを指す情報に対応する。例えば、エントリーのリストは、それぞれのメディアアイテムを識別する参照情報を含む。

いくつかの図が様々なロジック、モジュール、構成要素、機能などを示すことにより、機能を説明する。「論理」「モジュール」「構成要素」「機能」などの言葉は、一般にハードウェア、ソフトウェア、ファームウェア、または、これらの要素の組み合わせたもの、さらに他の種類の実施形態を表す。例えば、ソフトウェアの実施形態の場合、「論理」「モジュール」「構成要素」「機能」などの言葉は、一つまたは複数の処理装置（ＣＰＵなど）上で実行される時、特定のタスクを実行するための命令を含むコンテンツを指す。命令を含むコンテンツは、一つ以上の機械読取可能な媒体に保存することができる。

「機械読取可能な媒体」などの用語は、様々な種類のストレージデバイス（磁気、光学、静的装置など）を含む、任意の形態で、情報を保持するいかなる種類のメディアをも指す。「機械読取可能な媒体」という用語は、一つの場所から別の場所へ情報を転送する為の様々な有線と無線のリンク、またはそのどちらか一方を含む情報を表現する、一時的な形も包含する。

他の図は、信号ダイアグラムとフローチャートの形、またはそのどちらか一方で機能を説明する。この方式の説明では、ある動作が、ある順序で実行される、別個のタスクで構成されるとして説明される。そのような実施形態は例示的なものであり、制限するものではない。これらの図で説明された個々の動作は共にグループ化され一つの動作として実行され、一方、ある一つの動作は、複数の部分で実行される。ある動作は、図で説明された順番と異なる順番で実行されることもある。ある動作は、図で示されるものとは異なる動作の主体により実行されることもある。図の中で示される動作は、ソフトウェア、ファームウェア、ハードウェア、手作業による処理、その他の形、またはこれらを組み合わせた形で実行され得る。

一般に、実施形態のなかで説明される様々な機能は任意の機能としてみなされることがある。つまりこれらの機能は、除外または他の機能と替えられることがある。さらに、ここで説明される様々な実施形態は、追加機能を加えることによって補うこともできる。

この情報開示は次の主なセクションを含む。

セクションＡは、システムの概要と、その動作の方法を提供する。

セクションＢは、セクションＡのシステムで使用され得る、様々な構成要素に関する追加情報を提供する。

セクションＣは、システムが実行する様々な管理機能を説明する。

セクションＤは、システムが実行し得る様々なプロビジョニング機能を説明する。
Ａ．システムの概要と動作の方法
Ａ．１．実例となるシステムの概要

図１は、アイテム提供システム（ＩＰＳ）１０２からユーザデバイス１０４へアイテムをダウンロードする為の、実例となるシステム１００を示す。デバイス１０４では、ユーザは従来のハードコピーの形ではなく、電子的な形でメディアアイテムを消費することができる。表示されてはいないが、ユーザデバイス１０４は、潜在的に多数のユーザデバイスの一つを表す。

上で説明したように、「アイテム」という言葉は広い含意を持つ。網羅してはいないが、次のリストは代表的なアイテムの種類を識別する。

・アイテムは、電子書籍アイテムに相当し得る。さらに電子書籍アイテムは、電子形態の本、または本の一つ以上の部分（本の章など）、または複数の本の収集（本のシリーズなど）などを指す。電子書籍は、あらかじめ生成されたアイテムとして、ここで参照されるアイテムの一般的なクラスの例である。あらかじめ生成されたアイテムという用語は、典型的に（必然的ではないが）、コンテンツがＩＰＳ１０２によって受領され蓄えられた後、コンテンツに対するユーザのオンデマンド要求に対応して、ユーザに提供されるコンテンツを指す。

・コンテンツのアイテムはまた予約購読関連アイテムに相当し得る。予約購読関連アイテムは、スケジュールに基づいて、または事前に確立された取り決めに基づいて、ユーザが受け取るアイテムを指す。制限なしに、典型的な予約購読関連アイテムの形は、雑誌、定期刊行物、新聞、会報などを含む。他の形の予約購読関連アイテムは、Really Simple Syndication(RSS)フィードなどのように、様々なタイプの電子フィードを含む。あらかじめ生成されたアイテムと比べ、一般的に予約購読関連アイテムは、あらかじめ生成されたアイテムに対するユーザのオンデマンド要求というよりむしろ、ＩＰＳ１０２によるアイテムの受領に対応してユーザに提供される。

・アイテムはまた、個人文書アイテム、または単に「個人アイテム」に相当し得る。個人アイテムは、ユーザが事前にＩＰＳ１０２に転送する文書を指す。そこでＩＰＳ１０２は、アイテムをデバイスが読み取ることができるフォーマットへ変換する。

・アイテムはまた、一曲の音楽、音楽のコレクション、オーディオブックなどのオーディオコンテンツに相当し得る。

・アイテムはまた、ユーザによって作られたクエリーに対応して生成された情報のセットに相当し得る。

・アイテムはまた、ソフトウェア更新のような、命令を含んだコンテンツに相当し得る。

・アイテムはまた、事業体または事業体の組み合わせにより、ユーザデバイスへダウンロードされる広告用のマテリアルに相当し得る。このタイプのアイテムのダウンロードを管理するため、様々なルールが適用される。

・アイテムはまた、より完全なアイテムのバージョンのサンプルにも相当し得る。例えば、サンプルタイプのアイテムは、ユーザがその完全版、またはアイテムの他の部分（章など）を得ることを可能とさせるため、一つまたはそれ以上のリンクを埋め込むことができる。別の場合には、出版社や作者は、電子書籍または他のアイテムをシリーズで何回かに分けてリリースすることもできる。各一回分は、アイテムとみなされる。

・アイテムは、アイテムの草案に相当し得る。つまり、作者が必ずしも完成したとみなしていない状態にあるアイテムである。

・アイテムという言葉は、さらに別の形のコンテンツを包含する。つまり上記タイプのアイテムは代表的なものである。

・アイテム供給システム（ＩＰＳ）１０２はユーザデバイス１０４へアイテムを転送するいかなる機能または機能を組み合わせたものにも相当する。例えば、ＩＰＳ１０２は、ネットワークにアクセス可能なサーバ側の機能、様々なデータ記憶装置と他のデータ処理装置、またはその一方に相当し得る。ＩＰＳ１０２は、一つの物理的なサイトで提供される一つの機能の集まりにより実現され得る。その代わりに、ＩＰＳ１０２は、また、任意で複数の物理サイトで提供される、複数の機能の集まりにより実現され得る。ＩＰＳ１０２は、一つまたは複数の事業体により管理され得る。

例えば、ＩＰＳ１０２はユーザのアイテム購入の際、ユーザにアイテムを提供する事業体に相当する。この役割では、ＩＰＳ１０２は基本的には書店のように機能し得る。ある特定の商業環境では、ＩＰＳ１０２は、ユーザがハードコピーの本を購入し実物の配送を受けられるサービスをも提供し得る。これに関連して、ＩＰＳ１０２は全体のサービスの一部として、ユーザが電子アイテムを個々のユーザデバイスへダウンロードすることを可能にし得る。別の場合には、ＩＰＳ１０２は、手数料なしを基準に、または他の種類の代わりの対価取り決めを基準に、ユーザにアイテムを提供する事業体に相当し得る。つまり、アイテムの「提供者」という用語は、教育機関、政府組織、図書館、非営利組織など、また二つ以上の事業体の協力的な結合体などを包含するように広く理解されるべきである。

ユーザデバイス１０４は、ＩＰＳ１０２からアイテムを受け取る、いかなる種類の電子処理デバイス１０４にも相当する。ある実施形態では、ユーザデバイス１０４は容易に持ち運びできるものである。つまり、ユーザはある場所から他の場所へユーザデバイス１０４を自由に運ぶことができる。ある特定の場合には、ユーザデバイスは本の読み取り装置として設計され、それは電子書籍リーダーデバイスとしても知られる。この場合には、ユーザデバイス１０４は、紙の印刷した本の電子版として機能する。ユーザは、実物の本と同様にユーザデバイス１０４を持ち、電子的に本のページをめくることなどができる。制限なしに、図１はある特定の種類の電子書籍リーダーデバイスを示す。この特定の種類のリーダーデバイスに関する追加の詳細は以下に提供される。代わりに、ユーザデバイス１０４は、ポータブルミュージックプレーヤー、個人用の携帯情報端末（ＰＤＡ）、携帯電話、ゲームモジュール、ラップトップコンピュータ、またそれらのデバイスの組み合わせたものなど、他のタイプの持ち運びできる装置にも相当し得る。代わりに、またはそれに加え、ユーザデバイス１０４は、パソコン、テレビに取り付けられたセットトップボックス、ゲーミングコンソールなど容易に持ち運びできないデバイスにも相当し得る。

通信環境１０６は、双方向でＩＰＳ１０２とユーザデバイス１０４を結合する。つまり、ＩＰＳ１０２は、通信環境１０６を経由して、アイテム、アップグレードと他の情報、またはそのどちらか一方をユーザデバイス１０４へダウンロードする。ＩＰＳ１０２は、通信環境１０６を経由して、ユーザデバイス１０４から様々な指示と他のデータを受け取る。

通信環境１０６は、有線と無線のリンクの組み合わせ、またはそのどちらか一方を含む、通信機能の組み合わせを含み得る。例えば、図２は（以下で順に説明されるが）、広域情報通信網（ＷＡＮ）とワイヤレス環境の組み合わせを含む通信環境１０６の一つの実施形態を示す。通信環境１０６のワイヤレス要素のため、ユーザは有線リンクを経由したＩＰＳ１０２への接続なしに、アイテムを購入して消費するためにユーザデバイス１０４を使用することができる。例えば、ユーザは乗客として車に乗っている間、公園を歩き回っている間、湖でボートに乗っている間などに、デバイスを使って電子書籍を購入して消費することができる。

図１は、アイテムをユーザへダウンロードするための処理手続きの一部を上位レベルの形で説明した４つのやりとりを示す。最初のメッセージ１０８では、ＩＰＳ１０２はユーザデバイス１０４へ通知メッセージを送ることができる。通知メッセージ１０８は、ＩＰＳ１０２から一つ以上のアイテムをダウンロードし、他の動作を実行すること、またはそのどちらかを行うようユーザデバイス１０４に指示する。二番目のメッセージ１１０では、ユーザデバイス１０４は、一つ以上のダウンロードされるアイテムを識別するリストの提供をＩＰＳ１０２に求める。（および／または、例えばＩＰＳへ情報を送り返すなど別の動作が実行される） ユーザデバイス１０４は、二番目のメッセージ１１０に応答してＩＰＳ１０２からリストを受け取る。（注 図１は、ＩＰＳ１０２からユーザデバイス１０４へのリストの転送を特に示していない） もし指示命令がダウンロードするアイテムをを特定するなら、三番目のメッセージ１１２において、ユーザデバイス１０４はＩＰＳ１０２へ要求を送り、リストで特定されたアイテムをダウンロードするようにＩＰＳに求める。四番目のメッセージ１１４では、ＩＰＳ１０２は要求されたアイテムをユーザデバイス１０４へダウンロードする。実際には、ユーザデバイス１０４はプル(pull)アプローチでアイテムを取得する。しかし、プルアプローチはプッシュ(push)動作で始まる。（ＩＰＳ１０２がユーザデバイス１０４へ送る「プッシング(pushing)」通知メッセージ１０８のため）

一例では、通知メッセージ１０８は、電話の呼び出しのように音声モードのやりとりを始めるために使用される、ある種類の通知メッセージに相当し得る。この場合、通知メッセージ１０８は、地上フォンホームまたは、テレフォンホーム（ＴＰＨ）信号と称される（地上フォンホーム、テレフォンホーム、ＴＰＨなどの識別名は、ここでの説明を容易にするための便宜上の任意の名前である）。他のメッセージはデータモードのメッセージの形をとり得る。例えば、ユーザデバイス１０４は、実際には正式にＴＰＨ信号に返答することなく、ＴＰＨ信号を受領し、それに応答するように構成され得る。つまり、ユーザデバイス１０４はＴＰＨ信号を受け取るが、音声通信は行わず、ＩＰＳ１０２からのアイテムダウンロードするためのステップを開始する。ある環境では、ワイヤレスプロバイダーシステムでは、呼び出しが返答された場合料金を課すが、ユーザデバイスが呼ばれたが返答しなかった場合には課金しない。このように返答なしにユーザユーザデバイス１０４を呼ぶ方策は、ユーザデバイス１０４またはＩＰＳ１０２に料金を課することなしに、ＩＰＳ１０２が処理命令をユーザデバイス１０４へ伝えることを可能にする。

Ａ．２．実例となるシステムのワイヤレス実施形態
図２は、図１の一般システム１００の、一つの実例となる実施形態を描いたシステム２００を示す。概観すると、システム２００は上記で確認された構成要素を含む。つまり、ＩＰＳ１０２は通信環境１０６を経由してユーザデバイスにつながる。

通信環境１０６は様々な構成要素を含む。第一の構成要素はワイヤレスプロバイダーシステム２０２である。ワイヤレスプロバイダーシステム２０２は、ワイヤレス交換２０４をユーザデバイス２０４に与える、いかなる環境にも相当する。例えば、ワイヤレスプロバイダーシステム２０２は、様々なデータ処理装置、通信タワーなど（示されてはいないが）を使用して実現される。あるいは、またさらにワイヤレスプロバイダーシステム２０２は、ユーザデバイス１０４と情報を交換するために衛星技術に依存することもできる。ワイヤレスプロバイダーシステム２０２は、制限はないが、電波信号のように、信号を転送するためのいかなる電磁気学的エネルギーの形態を使うことができる。ワイヤレスプロバイダーシステム２０２は、例えば、符号分割多重接続（ＣＤＭＡ）プロトコルを使って実現される、スペクトラム拡散技術のような信号を転送するいかなる通信技術をも使うことができる。ワイヤレスプロバイダーシステム２０２は、一つの事業体または、複数の事業体の協力的な結びつきによって管理され得る。

通信環境１０６はまた通信支援システム２０６を含む。通信支援システム２０６の一つの目的は、ＩＰＳ１０２とワイヤレスプロバイダーシステム２０２の間を通過する情報の仲介として仕えることである。通信支援システム２０６は、制限なしに、一つ以上のサーバタイプのコンピュータ、データ記憶装置とデータ処理装置またはどちらか一方などによって、いかなる方式においても実現することができる。通信支援システムは、一つ以上のアプリケーションプログラミングインターフェース（ＡＰＩ）２０８を使用できるようにする。ＩＰＳ１０２は、様々な特定の機能を実行するため、ＡＰＩ２０８を呼び出すことができる。

通信支援システム２０６は、専用通信パイプまたはプライベートパイプと呼ばれる専用通信路２１０を経由して、ワイヤレスプロバイダーシステム２０２と通信する。通信路２１０は、それが通信支援システム２０６とワイヤレスプロバイダーシステム２０２間の情報を転送するために独占的に使用されるという意味で、専用である。対照的に、通信支援システム２０６は、公共の広域情報通信網（ＷＡＮ）２１２などの非専用通信手法を経由してＩＰＳ１０２と通信する。例えば、ＷＡＮ２１２はインターネットを表す。

通信支援システム２０６はアダプターの役割を果たすことができる。例えば、ある特定の実施形態で、ＩＰＳ１０２は、公共の広域情報通信網を経由して情報を受け取るように設定されるデータセンターとして機能すると仮定する。さらに、ワイヤレスプロバイダーシステム２０２は、プライベートパイプを経由してクライアントとやりとりするように設定されると仮定する。通信支援システム２０６は、広域情報通信網（ＷＡＮ）２１２を経由してＩＰＳ１０２とやりとりし、ワイヤレスプロバイダーシステム２０２はプライベートパイプ２１０を経由して、通信支援システム２０６とやりとりする。このようにＩＰＳ１０２とワイヤレスプロバイダーシステム２０２の処理選択を適合させる。この仲介の役割により、通信支援システム２０６は仮想移動体通信事業支援者（ＭＶＮＥ）と呼ばれ、ＩＰＳ１０２は仮想移動体通信事業者（ＭＶＮＯ）と呼ばれる。

ビジネスパラダイムの点から、ＩＰＳ１０２は大量のアドレス（ｗｈｏｌｅｓａｌｅ ａｃｃｏｕｎｔ）を使ってワイヤレスプロバイダーシステム２０２とやりとりする。これをもとに、ＩＰＳ１０２は、すべてのユーザデバイスによるワイヤレスプロバイダーシステム２０２の総合使用量に基づき、ワイヤレスプロバイダーシステム２０２に料金を払う。ＩＰＳ１０２は、エンドユーザに課す料金を通じて、これらのコストを取り戻す。この実例となるビジネスシナリオでは、ワイヤレスプロバイダーシステム２０２は、ユーザデバイスを操作するユーザに直接請求書を送らない。

さらに具体的に述べると、ワイヤレスプロバイダーシステム２０２は、サービスを利用するすべてのユーザに関連する通信トラフィック２１４の全体の量を処理する。通信トラフィック２１４の全体の量のサブセットが、ＩＰＳに関連した通信トラフィック２１６を表し、またマーチャントに関連した通信トラフィックとも呼ばれる。ＩＰＳに関連したトラフィック２１６は、ＩＰＳ１０２と、ＩＰＳ１０２とやりとりするすべてのユーザデバイス間で生じる情報の交換を表す。ワイヤレスプロバイダーシステム２０２は、ＩＰＳに関連した通信トラフィック２１６とやりとりする固有のキー情報に基づいて、ＩＰＳに関連した通信トラフィック２１６と他のトラフィックを区別する。ワイヤレスプロバイダーシステム２０２は、ＩＰＳに関連したトラフィック２１６の総量に基づいて請求書を準備することができる。上で述べたように、ワイヤレスプロバイダーシステム２０２は、デバイスを使用する個々のユーザではなく、ＩＰＳ１０２からのサービスに対して支払いを求めることがある。

上記で説明した例は典型的なものである。他の方策を、ＩＰＳ１０２とユーザデバイス１０４の間の情報を交換するために使うことができる。代わりの場合には、例えばシステム２００を、ワイヤレスプロバイダーシステム２０２が個々のユーザから直接コストを取り戻すように構成することができる。または、システム２００は、個々のユーザの選択で、ワイヤレスプロバイダーシステム２０２がＩＰＳ１０２（総計で）またはユーザへ請求書を提出するように構成することもできる。

ユーザは、ワイヤレスプロバイダーシステム２０２を迂回する代わりの通信ルートを通って、ＩＰＳ１０２にアクセスすることができる。例えば、代わりのアクセスパス２１８で示されるように、ユーザはパソコンなどを使用し、ワイヤレスプロバイダーシステム２０２と通信支援システム２０６を使用することなく、広域情報通信網（ＷＡＮ）２１２を経由してＩＰＳ１０２にアクセスすることができる。ユーザは、このルートを通って従来の方法でアイテムをダウンロードすることができる。そしてユーザはパソコンからユーザデバイス１０４へ、例えばユニバーサルシリアルバス（ＵＳＢ）の転送機構を経由し、ポータブルメモリデバイスなどを手動で運ぶことにより、アイテムを転送することができる。この転送方式はオーディオブックなどの大きいファイルに対して適切であり得る。ワイヤレスの方法で多量のデータを転送することは、比較的高いコストがかかり得る。しかし、システム２００はワイヤレス交換２０４を経由して、オーディオファイルのような大きいサイズのファイル転送を構成することができる。

図２のシステム２００はセキュリティ関連機能も提供する。ある機能によると、システム２００は複数層の認証を適用する。つまり、ワイヤレスプロバイダーシステム２０２は、最初のレベルの認証を実施するため、認証機能性Ａ₁２２０を含む。通信支援システム２０６は、二番目のレベルの認証を実施するため認証機能性Ａ₂２２２を提供する。ＩＰＳ１０２は三番目の層の認証を実施するため認証機能性Ａ₃２２４を提供する。各層の認証は、現在ＩＰＳ１０２とのやりとりを試みているユーザデバイスが本当にＩＰＳ１０２をアクセスする権限があるか確かめるためチェックを行う。認証の分散された性質は、不当な方法でユーザデバイスを得た人が、ＩＰＳ１０２によって提供されたサービスにアクセスできないことを確実にすることに役立つ。

別のセキュリティ関連機能によると、システム２００は、ユーザがデバイス１０４を使用する方法を制限する様々な制約を提供する。例えば、ユーザデバイスは、ＩＰＳ１０２に結びついた一つ以上のあらかじめ決められたアドレスのみのアクセスを許可するように、通信支援システム２０６の設定を行うことができる。このことは、例えばユーザは、ユーザデバイス１０４を使って最初にＩＰＳを経由しないで、ネットワークアクセス可能なサイトに直接アクセスすることができないことを意味する。これは、ユーザが、ユーザデバイス１０４を、ネットワークアクセス可能なリソースとの無制限のインターフェースとして使用することがないようにする。

さらに具体的に述べると、ＩＰＳ１０２はウェブ閲覧プロキシ（以下で詳細に述べられる）を含み得る。ユーザがネットワークアクセス可能なリソース２２６にアクセスしようとしたとき、通信支援システム２０６は最初に、ユーザは閲覧プロキシモジュールへ送られる。そして、閲覧 プロキシモジュールは要求を拒否、または要求を受け入れ、ネットワークアクセス可能なリソース２２６にアクセスすることをユーザに許可することができる。閲覧 プロキシモジュールは、ｌネットワークアクセス可能なリソース２２６へのアクセスを拒否するか受け入れるかどうかを決定する際、様々なルールを適用する（以降説明される）。このようにして、通信支援システム２０６とＩＰＳ１０２は、ユーザがネットワークアクセス可能なリソースに直接アクセスすることを許可しない。

別の場合では、システム２００は、ユーザがネットワークアクセス可能なリソースと直接やりとりすることを許可する、すなわちＩＰＳ１０２を経由せずにそれが行なわれる。

Ａ．３ 実例となるアイテム供給システム（ＩＰＳ）とユーザデバイス
図３は、ＩＰＳ１０２とユーザデバイス１０４（図１と２で紹介）のさらに詳細な描写を含むシステム３００を示す。示されてはいないが、図３のシステム３００は、図２で示されるワイヤレス機能を使用することができる。別の実施形態では、システム３００は図２で示されるものとは別の通信環境を使用することができ、ワイヤレス通信の使用を任意で除外することができる。

まずＩＰＳ１０２の詳細に焦点をあてると、このシステム１０２は様々な機能を実行する。異なるモジュールは異なる機能と結びつく。一つのモジュールは、コンテンツ受入れシステム３０２である。コンテンツ受入れシステム３０２は、一つ以上のコンテンツのソース３０４からコンテンツを受け取る。ソース３０４は、電子書籍出版社、新聞社、他の定期刊行物の出版社、様々なフィードソース、音楽ソースなど、いかなるタイプの供給者のコンテンツをも表す。

ソース３０４は、一つの事業体または、別個のそれぞれの事業体によって管理される。さらにＩＰＳ１０２を管理している事業体が、一つ以上のソース３０４を管理する同じ事業体に相当し得る。代わりに、あるいはそれに加え、ＩＰＳ１０２を管理している事業体は、一つ以上のそれぞれのソース３０４を管理している一つ以上の異なる事業体とやりとりし得る。後者の場合では、ＩＰＳ１０２を管理している事業体は、ソース事業体からコンテンツを受け取るためにソース事業体と契約を結ぶ。

上の例では、ソース３０４に関連する事業体は、商業組織または他の種類の組織に相当し得る。別の場合では、一つ以上のソースがアイテムの創作者などの個々のユーザに相当し得る。例えば、ユーザはＩＰＳ１０２へ直接アイテムを提供することができる。代わりに、あるいは、それに加え、ユーザは、コンテンツをアイテムのコミュニティリポジトリに提供し、ＩＰＳ１０２はこのリポジトリなどからコンテンツを得ることができる。

コンテンツ受入れシステム３０２は様々な仕組みを通じてコンテンツを得ることができる。例えば、コンテンツ受入れシステム３０２は、一つ以上のネットワーク３０６を経由してコンテンツを得る。ネットワーク３０６は、インターネット、構内通信網（ＬＡＮ）、またはその組み合わせなどのＷＡＮを表す。コンテンツ受入れシステム３０２は、いかなるプロトコルまたは、プロトコルの組み合わせをも使用して、様々な形態の情報を受け取ることができる。例えばコンテンツ受入れシステム３０２は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求をすることによって、またはファイル転送プロトコル（ＦＴＰ）要求をすることによって、またはフィード（ＲＳＳフィード）を受け取ることによって情報を受け取ることができる。別の場合では、ＩＰＳ１０２はソース３０４のピアツーピア（Ｐ２Ｐ）ネットワークを経由してコンテンツを得ることができる。もっと一般的に言えば、コンテンツ受入れシステム３０２は、任意のオンデマンド（情報転送のプル(pull)方法に基づく）の方式により、先取りする形でコンテンツを要求することができる。またはコンテント受入れシステム３０２は、（情報転送のプッシュ(push)方法に基づいて）ソース３０４により開始され、実行された独立した転送動作に応答して、コンテンツを受け取ることができる。代わりに、コンテンツ受入れシステム３０２は、プルとプッシュを組み合わせた転送の仕組みを使用して、コンテンツを受け取ることもできる。

コンテンツ受入れシステム３０２は、アイテムの形でコンテンツを受け取ることができる。制限なしに、アイテムは、電子書籍、オーディオブック、音楽、雑誌の号、定期刊行物の号、新聞の版、様々なフィードなどを含み得る。例えば、コンテンツ受入れシステム３０２は、ユーザデバイス１０４が読むことができないフォーマットで表現されているアイテムを受け取ることもある（ここでユーザデバイスは、任意の一つ以上のあらかじめ定義されたフォーマットでコンテンツを受け取り、処理し、表示するように構成され得る）。この状況に焦点をあてると、コンテンツ受入れシステム３０２は、最初のフォーマットからデバイスが読むことができるフォーマット（制限なく、mobiフォーマットなど）に、アイテムを変換することができる。

コンテンツ受入れシステム３０２は、受け入れたコンテンツを、（任意に別のフォーマットに変換して）コンテンツ記憶３０８に保存する。コンテンツ記憶３０８は、電子的な形でアイテムを保持するため一つ以上のストレージシステムを含んでおり、一つのサイトまたは複数のサイトに分散して置かれ、一つ以上の事業体により管理される。

セクションＢ（以下）は、コンテンツ受入れシステム３０２の動作に関する追加の情報を提供する。概観すると、コンテンツ受入れシステム３０２は、あらかじめ生成されたアイテム（電子書籍など）、予約購読関連アイテム（新聞など）、個人アイテム（ユーザが提供したワープロの文書など）を処理する個々のモジュールを有する。

ＩＰＳは予約購読モジュール３１０も含む。予約購読モジュール３１０は、予約購読関連アイテムに関するユーザの予約購読を管理する。一般に予約購読は、いかなるタイプの対価または、対価の組み合わせに基づいた、一つ以上の購読関連アイテム（コンテンツ受入れシステム３０２によって受領し、得られる予定のアイテム）を受け取る権利をユーザに与える。制限なく、予約購読関連アイテムの種類は、雑誌、定期刊行物、会報、新聞、様々なフィードなどを含む。ユーザはそのような予約購読を購入することによって、もっと一般的には、そのような予約購読を受け取るための登録をすることにより（料金の支払いが含まれていない場合もある）、予約購読関連アイテムを受け取るための準備をする。代わりに、またはそれに追加して、ＩＰＳ１０２は、ユーザの関与なしに（そして場合によりユーザの承認なしに）予約購読関連アイテムを受け取るためユーザを自動的に登録する。後者のシナリオは、ＩＰＳ１０２（または他の事業体）が要求されていない広告、ニュースレターなどを受け取るためユーザを登録する場合に適切である。システム３００は、ユーザがそのような要求されていない情報の受け取りを拒否することを可能にする。

ＩＰＳ１０２は新たに受け取った定期購入関連アイテムを、どのユーザデバイスが受け取るべきかを、予約購読モジュール３１０に対して情報を求める。例えば、フォーブス誌の電子版を受け取った際、ＩＰＳ１０２はこの雑誌を受け取るために支払いをしたユーザを判断するため、予約購読モジュールに対して情報を求める。そしてＩＰＳ１０２は適切なユーザデバイスにその号をを送る。

アイテム配送システム３１２は、ユーザデバイス１０４へコンテンツを実際に転送する機能を表す。一つの例示では、アイテム配送システム３１２は二つの構成要素、すなわち、to-doリストサーバモジュール３１４と、コンテンツ配送モジュール３１６である。to-doリストサーバモジュール３１４は、一般に、ユーザデバイス１０４に対して処理命令を提供する。命令は、ユーザデバイスにアイテムを取り込み、他の動作を実行するように指示する。コンテンツ配送モジュール３１６は、to-doリストサーバモジュール３１４から受け取った命令の中で、特定されたアイテムを得ることをユーザデバイス１０４に許可する。

さらに詳細に述べると、情報取り込みの最初の段階では、to-doリストサーバモジュール３１４はユーザデバイス１０４へ通知メッセージを送る。上で説明したように、一つの例示となる実施形態では、to-doリストサーバモジュール３１４は電話の呼び出しとして通知メッセージを送る。ユーザデバイス１０４は（休眠中の場合）起動することによって、通知メッセージに返答する。起動には、最初の電力状態から二番目の電力状態（二番目の電力状態は、最初の電力状態よりさらに電力を消費する）に移行することが関与し得る。ユーザデバイス１０４は、信号に正式に返答することなく、任意に通知メッセージに応答することができ、それによってワイヤレスメッセージに伴う料金を回避、または減らす。そしてユーザデバイス１０４は、to-doリストサーバモジュール３１４と通信し、to-doリストサーバモジュール３１４からの指示を要求する。さらに具体的には、各ユーザデバイスに対しto-doリストサーバモジュール３１４は、ここで「to-do キュー」とも呼ばれるエントリーのリストを保持する。エントリーは、ユーザデバイスが動作を実行するための命令を与える。以下でさらに詳細に述べられるが、デバイスが実行するように指示される異なる命令があり、そこでの命令の集まりは、ＩＰＳ−デバイス間の対話プロトコルを定義する。一つのそのような動作（例えば、ＧＥＴ命令プロトコルと結びついたもの）は、例えば、指定された適切なネットワークアドレス（ＵＲＬなど）や適切な変数などによる指定された場所から、アイテムを取り込むようにユーザデバイスに指示する。第一の段階では、ユーザデバイス１０４は一般に、そのようなn個のエントリーを取り込むが、ここでｎは整数である。あるシナリオでは、ｎという数は、ユーザデバイス１０４に関連したto-doキューの中のアイテムの合計数のサブセットである。ダウンロード手続きの二番目の段階では、ユーザデバイス１０４は、コンテンツ配送モジュール３１６と連絡し、ＧＥＴ関連エントリーで確認された一つ以上のアイテムを取り込む。

一般に、通知メッセージ（電話の呼び出しとして実現され得る）を受け取った後、アイテム配送システム３１２は、例えばハイパーテキスト転送プロトコル（ＨＴＴＰ）、または他のプロトコル、またはプロトコルの組み合わせを使用したデータモードで、ユーザデバイス１０４とやりとりする。ダウンロードの手続きは以下でさらに詳細に説明される（例えば、図８の説明の状況など）。

ＩＰＳ１０２はまた、店舗モジュール３１８も含む。店舗モジュール３１８はアイテムカタログ３２０へのアクセスを提供し、次いでアイテムカタログ３２０は複数のアイテム（電子書籍、オーディオブック、予約購読関連アイテムなど）に関する情報を提供する。以下でさらに詳細に説明されるが、店舗モジュール３１８は、ユーザがアイテムカタログ３２０内を検索、閲覧することを可能にする機能を含む。店舗モジュール３１８はまた、ユーザがアイテムを購入する（もっと一般的に言えば、任意の条件に基づいてアイテムを得る）ことを可能にする機能も含む。例えば、ユーザはワイヤレス通信を使って、ユーザデバイス１０４経由で店舗モジュール３１８とやりとりする。代わりに、またはそれに追加して、ユーザは任意で有線リンクを経由したパソコンなど、別の種類のデバイス３２２を経由して、店舗３１８とやりとりすることができる。どちらのケースも、ユーザが店舗モジュール３１８を経由してアイテムを購入、または取得する際、ＩＰＳ１０２はアイテムをユーザへ配送するためアイテム配送システム３１２を呼び出す。

ＩＰＳ１０２はまた、個人メディアライブラリモジュール３２４も含む。個人メディアライブリモジュール３２４は、各ユーザの以前の購入リストを蓄える。さらに具体的には、例えば、個人メディアライブラリモジュール３２４は、すでにユーザが所有する電子書籍アイテム、および他のオンデマンドの選択（例えば、予約購読の号などの「アラカルト」選択など）に関するメタデータ情報を提供する。個人メディアライブリモジュール３２４は、コンテンツ記憶３０８の中のアイテムへのリンクも提供する。以下でさらに詳細に説明されるが、ユーザがすでに購入した電子書籍アイテム（など）をダウンロードする際、ユーザデバイス１０４はコンテンツ配送システム３１６に連絡する。コンテンツ配送システム３１６は、アイテムをユーザにダウンロードするため、個人メディアライブラリモジュール３２４の許可情報とリンク情報とやりとりする。ある使用のシナリオでは、ユーザデバイス１０４は、このような方法でコンテンツ配送システム３１６にアクセスし、以前ユーザによって購入されたが、ある理由でユーザデバイス１０４によって削除されてしまったアイテムのダウンロードを開始することができる。

ＩＰＳ１０２はまた、閲覧 プロキシモジュール３２６も含む。閲覧 プロキシモジュール３２６は、ユーザがユーザデバイス１０４上にあるブラウザーモジュール（以下で論議される）を経由して、一つ以上のネットワークアクセス可能なリソース３２８にアクセスすることを可能にする。図２のコンテキストでで説明したように、ユーザが特定のネットワークアクセス可能なリソースへのアクセスを要求したとき、システム３００は最初にユーザを閲覧 プロキシモジュール３２６へ向かわせる。閲覧 プロキシモジュール３２６は次に、そのようなアクセスを認めるか否か決めるため、認められた場合、どの条件でそのようなアクセスを認めるかを決定するため、様々な環境固有のビジネス規則を適用する。この仕組みを通じて、ある実施形態では、ユーザがユーザデバイス１０４を使ってネットワークアクセス可能なリソース３２８に直接アクセスすることを防ぐ。

ＩＰＳ１０２はまた、一つ以上の権限情報記憶３３０のような、様々なセキュリティ関連機能も含む。権限情報記憶３３０は、様々なＩＰＳ１０２の構成要素が、ユーザによる店舗モジュール３１８へのアクセスや、アイテムのダウンロード、設定の変更など様々な機能の実行を許可するかどうかの、判断を可能にするための情報を提供する。

上記の列挙されたモジュールのリストは代表的なものであり、ＩＰＳ１０２によって実施される機能の種類を網羅してはいない。「他のサーバ側の機能」という名称によって示されるように、ＩＰＳ１０２はさらなる機能を含み得、それらの多くは以下で説明される。

ここでシステム３００のデバイス側の機能を説明する。ユーザデバイス１０４は、デバイスto-doリスト処理モジュール３３４を含む。デバイスto-doリスト処理モジュール３３４の目的は、アイテム配送システム３１２からアイテムをダウンロードするため、アイテム配送システム３１２とやりとりすることである。つまり、ダウンロード手続きの第一の段階では、デバイスto-doリスト処理モジュール３３４は、最初にto-doリスト処理モジュール３１４から通知メッセージを受け取り、to-doリスト処理モジュール３１４は、デバイスto-doリスト処理モジュール３３４に、（もし「休眠」していたなら）起動して、to-doリスト処理モジュール３１４に連絡して、n個のエントリーセットを取り込むように促す。各エントリーは、デバイスto-doリスト処理モジュール３３４が動作を実行するように指示する命令を含む。第二の段階では、ＧＥＴタイプのエントリーに対しては、デバイスto-doリスト処理モジュール３３４は、ＧＥＴタイプのエントリーによって認識されたアイテムを要求して持ってくるため、コンテンツ配送モジュール３１６に連絡する。以下でさらに詳細に説明されるが、ユーザデバイス１０４は、ダウンロード処理の完了、またはダウンロード処理の失敗の信号を送る。

アイテムがダウンロードされると、ユーザデバイス１０４は、例えばフラッシュタイプのメモリ、または他の種類のメモリなどデバイス側メモリ３３６にアイテムを格納する。示されてはいないが、ユーザデバイス１０４は、他のコンテンツのソース３３８とも情報を交換することができる。一つの例示的な場合において、他のコンテンツのソース３３８は、パソコンまたは他のデータ処理デバイスを表し得る。そのような他のコンテンツのソース３３８は、ユニバーサルシリアルバス（ＵＳＢ）接続と他の種類の接続、またはそのどちらかを経由して、ユーザデバイス１０４にアイテムを転送することができる。このシナリオでは、他のコンテンツのソース３３８は、次いで、有線接続（例えば、非ワイヤレス接続）を経由してＩＰＳ１０２（または他のソース）からアイテムを受け取ることができる。例えば、オーディオブックを受け取る際に、ユーザはパソコンを使用して、ネットワークアクセス可能なソースのコンテンツから、非ワイヤレスで、オーディオブックをダウンロードすることができる。ユーザは次に、ＵＳＢ接続を通じてユーザデバイス１０４へオーディオブックを転送することができる。別の例となる場合では、別のコンテンツのソース３３８は、フラッシュタイプのメモリモジュール、磁気メモリモジュール。光学メモリモジュールなど、いかなる持ち運び可能なメモリモジュールの種類をも表し得る。

ユーザデバイス１０４はまた、リーダーモジュール３４０を含む。リーダー３４０の実例となる目的は、ユーザデバイス１０４を使った、ユーザによる消費のためメディアアイテムを表示することである。例えば、リーダー３４０はユーザに電子書籍を表示することに使用され、紙ベースの実物の本を読むことを装った体験をユーザに提供する。

ユーザデバイス１０４はまた、コンテンツ管理モジュール３４２を含む。コンテンツ管理モジュール３４２の目的は、ユーザがユーザデバイス１０４を使って、消費できるアイテムを管理することを可能にすることである。例えば、コンテンツ管理モジュール３４２は、ユーザが消費できるアイテムのリストを見ることを可能にする。コンテンツ管理モジュール３４２はまた、個々のアイテムのソースを特定する。そのようなソースの一つはデバイスメモリ３３６に相当し、別のソースは取り付けられた持ち運び可能なメモリ（例えば、他のソース３３８で表現される）に相当し、また別のソースは個人メディアライブラリモジュール３２４の中で特定されるアイテムに対応し（ＩＰＳ１０２によって提供されたデバイス側メタデータによって示され得る）、また別のソースは購読モジュール３１０により特定される予約購読関連アイテムに相当するなどである。コンテンツ管理モジュール３４２は、ユーザが様々な方法でアイテムを選別し、ソートすることを可能にする。例えば、ユーザはデバイス記憶３３６から発したされたアイテムを選択して見ることができる。

ユーザデバイス１０４はまた、店舗対話モジュール３４４を含む。店舗対話モジュール３４４は、ユーザデバイス１０４が店舗モジュール３１８とやりとりすることを可能にする。ユーザは店舗対話モジュール３４４を使って、アイテムを検索して閲覧したり、アイテムを購入したり、カスタマーレビューを読んだり、書いたりすることができる。上記で述べたように、ユーザはパソコンなどを使って、有線リンクを経由して店舗モジュール３１８とやりとりすることができる。

上記で列挙されたモジュールのリストは代表的なものであり、ユーザデバイス１０４で実行される機能の種類を網羅してはいない。「他のデバイス側機能」という名称で示されるように、ユーザデバイス１０４はさらなる機能を含み得、それらの多くが以下で説明される。実際に、図４は、追加のデバイス側機能を示す。完全性を期すために、図４は、デバイス側to-doリスト処理モジュール３３４、デバイスメモリ３３６、リーダーモジュール３４０、コンテンツ管理モジュール３４２、店舗対話モジュール３４４を含む、上記で述べた様々なモジュールを特定する。これらの機能は上記で述べられた機能を実行する。

図４は、ブラウザーモジュール４０２も含んだユーザデバイス１０４を示す。ブラウザーモジュール４０２は、ユーザデバイス１０４が、ＩＰＳ１０２によって提供された閲覧 プロキシモジュール３２６を経由して、一つ以上のネットワークアクセス可能なリソース３２８にアクセスすることを可能にする。上で説明したように、閲覧 プロキシモジュール３２６は、一連の環境固有のルールに基づいて、ネットワークアクセス可能なリソース３２８へのアクセスを許可または拒否する。もし許可されたアクセスなら、デバイス側のブラウザーモジュール４０２はネットワークアクセス可能なソースから受け取ったコンテンツを解釈する機能を含み、ユーザにそのコンテンツを表示する。

ユーザデバイス１０４はまた、検索と索引付けの機能モジュール４０４も含み得る。この機能モジュール４０４の索引付けの側面は、ＩＰＳ１０２から受け取ったアイテムの索引付けをすること、および／または、ＩＰＳ１０２または他のソースにより生成され、供給された索引とやりとりする仕組みを提供する。特定のアイテム（電子書籍や新聞の版など）の索引は、アイテムの中の構成部分（単語など）を特定し、構成部分をアイテム中のそれぞれの位置に結びつける。機能モジュール４０４の検索の側面は、アイテムの中の特定された構成部分（単語、段落など）を検索する、および検索に関連した他の機能を実行する仕組みを提供する。検索の側面は、索引付けの側面に依存する。

ユーザデバイス１０４はまた、注釈モジュール４０６もも含み得る。注釈モジュール４０６は、ユーザが特定アイテムを補うために注釈を作成することを可能にする。例えば、ユーザは、しおりを入れるような方法でページに印をつける為、ある種の注釈を作成することができる。ユーザは電子書籍の中の単語、段落、文などのアイテムの一部分を強調させるため、別のタイプの注釈を作成することができる。ユーザはアイテムに対して一つ以上のメモを加えることにより、さらに別のタイプの注釈を作成することができる。一般的に注釈モジュール４０６は、作られた注釈のタイプ、注釈と結びついたアイテムの中の場所と、注釈の内容（例えば、メモタイプの注釈の場合など）などのを特定する注釈情報を格納することができる。

さらに具体的には、ユーザデバイス１０４はローカルに注釈を保存することができる。さらにＩＰＳ１０２は、任意でバックアップ記憶に注釈を保存することができる。つまり、これにより、デバイス側の記憶から削除された場合、ユーザが注釈をダウンロードすることを可能にすることができる。どこに保存されても、ユーザデバイス１０４は、注釈の「ターゲット」または題目である対応するアイテムを表示する際に、注釈を復元することができる。例えばユーザが、一回以上注釈をつけられた電子書籍にアクセスするとき、注釈モジュール４０６は注釈情報にアクセスし、テキストの中のユーザの注釈を表示する。また注釈モジュール４０６は、ユーザがアイテムの一つ以上の部分を特定して抽出し（例えば「切り抜き」など）、その部分を切り抜きファイルの中に保管することを可能にする関連機能を実行する。一つの例となる場合では、切り抜きは、非暗号化のテキストファイルに保存される。例えば、注釈はユーザなどの特定の個人、事業体と関連付けることができる。代わりに、またはそれに追加して注釈は電子書籍などの注釈付けされたアイテムの写しと関連付けることができる。

ユーザデバイス１０４はまた、ホーム提示モジュール４０８も含む。ホーム提示モジュール４０８は、ユーザが最初に、および／または他の時点でユーザデバイスを起動させたとき、ホームページを提供する。ホームページは一般的なポータルとして機能することができ、ユーザがメディアアイテムやユーザデバイス１０４によって提供された様々な機能にアクセスすることを可能にする。一つの例となる場合では、ホームページは、ユーザデバイス１０４を使って消費できるアイテムの一部（または全部）の要約を表示する。

ユーザデバイス１０４はまた、オーディオ再生モジュール４１０を含む。オーディオ再生モジュール４１０は、ユーザがミュージック、オーディオブックなどのオーディオアイテムを再生して、やりとりすることを可能にするインターフェースを提供する。

上記で述べられたユーザデバイス１０４の機能は、ユーザとやりとりするアプリケーション、またはユーザとユーザデバイス１０４とのやりとりにおける、上位レベルの役割を果たすアプリケーションに関する。ユーザデバイス１０４は、バックグラウンドタイプの動作など、様々な下位レベルのタスクを実行するための、多くの他の機能も含み得る。

電力管理機能４１２は、そのようなバックグラウンドタイプの動作ンの一つを実行する。さらに具体的には、動力管理機能４１２は、ユーザデバイス１０４により消費される電力の管理を実行するハードウェアおよび／またはソフトウェアの機能の集合に相当する。動力管理機能４１２は一般的に、ユーザデバイス１０４により消費される動力を減らすために動作する。動力管理機能４１２は、活発に使用されていない機能（または、これらの機能は活発に使われていないという前提で）を選択して電力を落とすことにより、目標を達成する。動力管理機能４１２は、ワイヤレス通信と関連する一つ以上の機能のような、大きな電力を要求する機能の動力を落とすことにより、特に著しい電力節約を達成する。

ユーザデバイス１０４はまた、パフォーマンスモニタリングとテスティング（ＭＴ）機能４１４を含む。ＭＴ機能４１４は、デバイス１０４の動作を特定する動作ログ４１６を維持する。ＩＰＳ１０２と他の事業体、またはその一方は、ユーザデバイス１０４と全体としてのシステム３００の動作の中での異常を診断する手助けをするため、通信環境１０６から収集した他の情報とともに、動作ログ４１６にアクセスする。またＭＴ機能性は、ＩＰＳ１０２と他の事業体、またはその一方によって提供されたテスト機能やりとりする。例えば、ＭＴ機能４１４は、以下のセクションＣでさらに詳細に説明される方法で、ＩＰＳ１０２によって生成されたテストプローブに応答する。

ユーザデバイス１０４はまたアップグレード関連機能４１８を含む。アップグレード関連機能４１８は、ユーザデバイス１０４がソフトウェアアップグレードのような命令付きのアップグレードアイテムを受け取り、統合することを可能にする。たとえばアップグレード関連機能４１８は、ＩＰＳ１０２（と他の事業体、またはどちらか）によって供給された命令付きアイテムを自動的に受け取ることができる。ＩＰＳ１０２の管理者は、命令付き更新アイテムがユーザデバイス１０４へ転送されるアップグレード手続きを、手作業で始めることができる。または自動化されたＩＰＳ側ルーチンが、アップグレード手続きを始めることもできる。いずれにしてもユーザデバイスは、ユーザの関与なしに、またはユーザの最小限の関与で、命令付きアップグレードアイテムを受け取ることができる。この意味で、アップグレード手続きは「透明」であると見ることができる。別の場合には、アップグレード関連機能４１８は、ユーザが手動で命令付きアイテム（所定のウェブサイトなど）のソースにアクセスし、このソースからアイテムをダウンロードして実行することもできる。

一実施形態では、アップグレード関連機能４１８はバージョン情報をＩＰＳ１０２へ転送する。バージョン情報は、ユーザデバイス１０４により使用されている命令付きコンテンツのバージョンを識別する。ＩＰＳ１０２は、このバージョンが期限切れかどうか（現在のバージョン情報を参照することによって）判断する。期限切れの場合、ＩＰＳ１０２は、例えばユーザデバイス１０４へ命令付きアイテムをダウンロードするなど、適切に対応する。セクションＣは、アップグレード関連機能４１８によって実行される処理についてさらなる情報を提供する。

繰り返して述べるが、上記で列挙されたモジュールのリストは代表的なものであり、ユーザデバイス１０４により実行される機能のタイプを網羅するものではない。「他のデバイス側機能性」の名称により示されるように、ユーザデバイス１０４はさらなる機能を含み得る。

Ａ．４．実例となるユーザーインターフェースの特徴
上述のＩＰＳ１０２は、任意のタイプのユーザデバイス１０４と交信することができる。一例では、ユーザデバイス１０４は、携帯用のデバイスであり、これは、場所から場所へと手軽に携行されるよう設計されているデバイスを意味する。具体的な一例では、ユーザデバイス１０４は、例えば、ユーザが実際の書籍を手に持つような形を模倣する形態で、ユーザが、ユーザデバイス１０４を手に持ちながらメディアアイテムを消費できるようにする。携帯用ユーザデバイスは、電子書籍リーダーデバイス、携帯用音楽プレーヤー、携帯情報端末、移動電話、ゲームモジュール、ラップトップコンピュータなどの形をとること、および／またはこうした種類のデバイスの任意の組み合わせという形をとることができる。その代わりに、またはそれに加えて、ユーザデバイス１０４は、パーソナルコンピュータ、テレビに取り付けられるセットトップボックス、ゲーム機など、手軽に持ち運びできないデバイスに相当し得る。

限定されるものではないが、図５は、ＩＰＳ１０２との交信に用いられ得るユーザデバイス５００の１つの種類を示す。ユーザデバイス５００は、ユーザの手に容易に収まるよう設計されたＶ字型の本体を備ることができ、概ねペーパーバック書籍のサイズである。他のユーザデバイスは、他の形状およびサイズを採用し得る。

典型的な一つの設計では、ユーザデバイス５００は、主表示部５０２および補助表示部５０４という２つの表示部を備える。主表示部５０２は、店舗対話モジュール３４４、リーダーモジュール３４０、ブラウザーモジュール４０２などにより提供される様々なページを提示する。一例では、補助表示部５０４は、カーソルを提示するために用いられる。ユーザは、カーソルの位置を合わせて、主表示部５０２の、横方向に隣り合った部分を特定することができる。限定されるものではないが、１つの実例では、主表示部５０２および／または補助表示部５０４は、マサチューセッツ州ケンブリッジ（Ｃａｍｂｒｉｄｇｅ，Ｍａｓｓａｃｈｕｓｅｔｔｓ）のＥ Ｉｎｋ Ｃｏｒｐｏｒａｔｉｏｎなどによって提供されている電子ペーパー技術を用いて実現され得る。この技術は、不揮発性の機構を用いて情報を提示する。この技術を用いて、ユーザデバイス５００は、デバイスの電源が切られても表示装置上に情報を保持することができる。

ユーザデバイス５００は、様々な入力キーおよび機構を備える。カーソル移動機構５０６によって、ユーザは、補助表示部５０４内でカーソルを移動させることができる。典型的な一例では、カーソル移動機構５０６は、カーソルを補助表示部５０４内で上下に移動させるよう回転させることができるカーソルホイールを備えることができる。カーソル移動機構５０６は、ホイールを押下することでユーザが選択を行えるように構成され得る。タッチ・センシティブ表示装置、主表示部５０２の縁（単数または複数）に沿って垂直および／または水平に配置された一連のキー、主表示部５０２内の１つ以上のグラフィカル・スクロール・バー（単数または複数）など、他のタイプの選択機構を用いることができる。

ユーザデバイス５００は、次ページボタン５０８、５１０および前ページボタン５１２など、様々なページめくりボタンも備える。次ページボタン５０８、５１０は、（現在表示されているページに対して）アイテム内の次のページへ、ユーザを進める。前ページボタン５１２は、（現在表示されているページに対して）前のページへ、ユーザを進める。ユーザデバイス５００は、ページめくり入力機構５１４も備えることができ、これは、ユーザの親指が機構５１４の上を通過するときに、その親指によって作動させることができる。この、ユーザが体験することは、実際の書籍でユーザがページをめくる形（例えば、書籍を「パラパラとめくっていく」ことによる）を模倣するものである。ユーザデバイス５００は、ユーザがブラウジング・モジュール４０２を用いる際に前のページへ進めるようにするバックボタン５１６も備え得る。図示されてはいないが、ユーザデバイス５００は、電源をオン・オフするスイッチ、無線インターフェースを有効化および無効化するスイッチなどを備えることができる。

ユーザデバイス５００は、キーボート５１８も備え得る。キーボート５１８は、英数字キーを備え得る。このキーは、ユーザがデバイス１０４を実際の書籍のように手に持つ間に、ユーザのキーとの対話を容易にするように形成し、方向づけをすることができる。ユーザは、キーボード５１８を用いて、検索語、注釈、ＵＲＬなどを入力することができる。キーボード５１８は、様々な特殊機能キーも備え得る。

図６は、ユーザが図５のユーザデバイス５００を用いて主表示部５０２においてコンテンツを選択することができる１つの形を示す。すなわち、主表示部５０２がコンテンツ６０２の或るページを表示すると仮定する。コンテンツ６０２は、その右端の垂直な縁に沿って配置された、複数の選択ポイントを備え得る。この選択ポイントは、コンテンツ６０２の関連部分に横方向に対応する。例えば、典型的な選択ポイント６０４は、コンテンツ６０２のページ内の選択可能アイテム６０６に対応する。補助表示部５０４がカーソル６０８を提示する。ユーザは、カーソル移動機構５０６を回転させることにより、補助表示部５０４内でカーソルを上下に移動させることができる。

操作中、図６に示されている選択ポイント６０４などの所望の選択ポイントに、カーソル６０８が横方向に並ぶよう、ユーザはカーソル移動機構５０６を操作することができる。カーソル移動機構５０６がカーソルホイールである場合、ユーザはホイールを回転させて、補助表示部５０４の垂直の広がりに沿った所望の位置までカーソル６０８を移動させることができる。この実施形態では、続いて、ユーザがカーソルホイールを押下して、選択ポイント６０４に対応するアイテム６０６を正式に選択することができる。

１つの典型的なタイプのブックリーダータイプのデバイスについて、さらなる情報を以下の一連の出願おいて見出すことができる。

・米国特許出願第１１／２４６２９３号明細書、２００６年３月２９日出願、題「電子メディア・リーダー表示装置（Ｅｌｅｃｔｒｏｎｉｃ Ｍｅｄｉａ Ｒｅａｄｅｒ Ｄｉｓｐｌａｙ）」、発明者名ホワイトホーン（Ｗｈｉｔｅｈｏｒｎ）ら
・米国特許出願第１１／２４６２９４号明細書、２００６年３月２９日出願、題「電子メディア・リーダー・キーパッド（Ｅｌｅｃｔｒｏｎｉｃ Ｍｅｄｉａ Ｒｅａｄｅｒ Ｋｅｙｐａｄ）」、発明者名トマスＪ．ホッブス（Ｔｈｏｍａｓ Ｊ．Ｈｏｂｂｓ）ら
・米国特許出願第１１／２４６２９５号明細書、２００６年３月２９日出願、題「Ｖ字型電子メディア・リーダー（Ｗｅｄｇｅ−Ｓｈａｐｅｄ Ｅｌｅｃｔｒｏｎｉｃ Ｍｅｄｉａ Ｒｅａｄｅｒ）」、発明者名ホワイトホーンら
・米国特許出願第１１／２７７８９８号明細書、２００６年３月２９日出願、題「ハンドヘルド電子ブック・リーダー・デバイス用ページ・ターナー（Ｐａｇｅ Ｔｕｒｎｅｒ Ｆｏｒ Ｈａｎｄｈｅｌｄ Ｅｌｅｃｔｒｏｎｉｃ Ｂｏｏｋ Ｒｅａｄｅｒ Ｄｅｖｉｃｅ）」、発明者名グレッグＥ．ツェール（Ｇｒｅｇｇ Ｅ．Ｚｅｈｒ）ら
・米国特許出願第１１／２７７８９３号明細書、２００６年３月２９日出願、題「デュアル表示装置を有するハンドヘルド電子ブック・リーダー・デバイス（Ｈａｎｄｈｅｌｄ Ｅｌｅｃｔｒｏｎｉｃ Ｂｏｏｋ Ｒｅａｄｅｒ Ｄｅｖｉｃｅ Ｈａｖｉｎｇ Ｄｕａｌ Ｄｉｓｐｌａｙｓ）」、発明者名グレッグＥ．ツェールら
・米国特許出願第１１／２７７８７３号明細書、２００６年３月２９日出願、題「非対称形のハンドヘルド電子ブック・リーダー・デバイス（Ｈａｎｄｈｅｌｄ Ｅｌｅｃｔｒｏｎｉｃ Ｂｏｏｋ Ｒｅａｄｅｒ Ｄｅｖｉｃｅ Ｈａｖｉｎｇ Ａｓｙｍｍｅｔｒｉｃａｌ Ｓｈａｐｅ）、発明者名グレッグＥ．ツェールら
・米国特許出願第１１／２７７８７９号明細書、２００６年３月２９日出願、題「ハンドヘルド電子ブック・リーダー・デバイスのキーボード配列（Ｋｅｙｂｏａｒｄ Ｌａｙｏｕｔ ｆｏｒ Ｈａｎｄｈｅｌｄ Ｅｌｅｃｔｒｏｎｉｃ Ｂｏｏｋ Ｒｅａｄｅｒ Ｄｅｖｉｃｅ）」、発明者名グレッグＥ．ツェールら
繰り返すが、図５および６に示されているユーザーインターフェースの設計は、典型的なものである。異なるタイプのユーザーインターフェース・機構を有する他のタイプのユーザデバイスが、ＩＰＳ１０２との交信に用いられてもよい。

Ａ．５．実例となるデータ処理デバイス
図１、２および３に示されているシステムの様々な態様が、１つ以上のデータ処理デバイスによって実現され得る。例えば、ＩＰＳ１０２の様々な構成要素が、それぞれのサーバタイプのコンピュータおよび関連するデータ処理装置（例えば、ルータ、データ記憶デバイスなど）によって実現され得る。ユーザデバイス１０４は、データ処理デバイスにも相当し得る。図７は、サーバ側の任意の機能および／またはデバイス側の任意の機能を含む、上記のシステムの任意の態様を実現するために用いられ得る一般的なデータ処理デバイス７０２の概要を示す。

処理デバイス７０２は、１つまたは複数のＣＰＵなどの、１つまたは複数の処理ユニット７０４を備える。処理デバイス７０２は、システム・メモリ７０６も備えており、システム・メモリ７０６は、揮発性および／または不揮発性記憶機構の任意の組み合わせに相当するとよい。システム・メモリ７０６は、オペレーティング・システム・構成要素７０８、様々なプログラム・モジュール７１０、プログラム・データ７１２および／またはその他の構成要素を提供する情報を格納すればよい。処理デバイス７０２は、処理ユニット（単数または複数）７０４を用いて、システム・メモリ７０６により提供される命令を実行することによって、機能を実行する。処理デバイス７０２は、１つまたは複数の種類の取り外し可能記憶装置７１４および１つまたは複数のタイプの固定記憶装置７１６も備えているとよい。

処理デバイス７０２は、１つまたは複数の入力デバイス７１８（キーボード、マウスデバイス、特殊選択キーなど）および１つまたは複数の出力デバイス７２０（表示装置、プリンタ、オーディオ出力機構など）も備えているとよい。

処理デバイス７０２は、１つまたは複数の通信インターフェース・機構７２２も備えているとよい。この通信インターフェース・機構７２２は、処理デバイス７０２が、リモートコンピュータ、ブックリーダーデバイスなどの他の処理デバイス７２４と交信できるようにする。通信インターフェース・機構７２２は、１つまたは複数の無線インターフェース・機構７２６も備えているとよい。処理デバイス７０２がユーザデバイス１０４を表す場合には、無線インターフェース・機構７２６は、ユーザデバイス７２６が電話の呼び出しを受信し、さらにデータモードでＩＰＳ１０２と通信できるようにするとよい。

上に列挙したモジュールのリストは、典型的なものであり、処理デバイス７０２によって実行される機能のタイプを網羅するものではない。「他のデバイス機能性」７２８の名称で示されているように、処理デバイス７０２はさらなる機能を備えていてもよい。

Ａ．６．実例となるアイテムのダウンロード方法
上記の各セクションで説明したように、ＩＰＳ１０２のアイテム配信システム３１２は、デバイス側to‐doリスト処理モジュール３３４と交信して、ＩＰＳ１０２のコンテンツ記憶３０８からアイテムをダウンロードする。アイテム配信システム３１２は、次いで、to‐doリストサーバモジュール３１４およびコンテンツ配信モジュール３１６の２つの構成要素を備える。to‐doリスト処理モジュール３３４は、to‐doリストサーバモジュール３１４と交信してエントリーをダウンロードするが、このエントリーが、ＩＰＳ１０２から読み出されるべきアイテムを特定する。to‐doリスト処理モジュール３３４は、コンテンツ配信モジュール３１６と交信して、このエントリーによって特定された実際のアイテムを読み出す。図８は、ＩＰＳ１０２からユーザデバイス１０４にアイテムをダウンロードするための１つのプロトコル８００についてのさらなる情報を提供する。このプロトコルは実例となるものであり、種々の環境に合うよう様々な点で変更されるとよい。

動作（１）で、ＩＰＳのコンテンツ受信システム３０２は、コンテンツを受信して、コンテンツ記憶３０８内に格納する。コンテンツ受信システム３０２は、この動作を、新たな電子書籍またはその他の事前作成アイテムを受け取るのに応答して実行するとよい。または、コンテンツ受信システム３０２は、この動作を、新たな定期購読関連アイテムを受け取るのに応答して実行得る。または、コンテンツ受信システム３０２は、この動作を、ユーザによって送付された個人用文書を受け取るのに応答して実行してもよい。さらに他の複数のシナリオが可能である。

動作（２）で、to‐doリストサーバモジュール３１４の適切なキューにエントリーが追加される。電子書籍の選択（例えば購入）の場合、店舗モジュール３１８が、to‐doリストサーバモジュール３１４にエントリーを追加し、これが、選択された電子書籍を入手する命令に相当する。この場合、動作（２）は、動作（１）に対して非同期的に生じる。すなわち、この２つの動作は、関連する一体化したトランザクションの一部ではないことを意味する。この概略図には示されていないが、ユーザの電子書籍（またはその他、定期購読の号など、個々に選択されたもの）の購入はさらに、ＩＰＳ１０２に、ユーザの購入についての情報をメディアライブラリモジュール３２４に格納するよう促す。予約購読関連アイテムを受け取る場合、アイテム受信システム３０２は、定期購読モジュール３１０と連動して、エントリーをto‐doリストサーバモジュール３１４に追加する。この場合、動作（２）は動作（１）に応答して生じる。したがって、この動作は単一のトランザクションの一部と見なされるとよい。さらに詳しく後述するように、予約購読の新たな号を受け取る場合は、予約購読モジュール３１０が、ユーザの、その予約購読の以前の購入に基づいて、その発行物のユーザの所有権を示す。個人用アイテムの場合、ユーザの個人用アイテムの受信、変換、格納専用の機能が、任意選択で、エントリーをto‐doリストサーバモジュール３１４に追加することができる（ユーザが実際に、別の非無線モードの配信ではなく無線通信路を介して文書を受け取ることを選んだ場合）。

動作（３）で、to‐doリストサーバモジュール３１４は、通知メッセージをデバイスのto‐doリスト処理モジュール３３４へ送信する。１つの実例では、通知メッセージは電話の呼び出しとして実装されてもよく、これは本願明細書では、ＴｅｌｅＰｈｏｎｅ Ｈｏｍｅ（ＴＰＨ）信号とも呼ばれる。その後の、アイテム配信システム３１２と、to‐doリスト処理モジュール３３４との間の通信はすべて、例えばＨＴＴＰプロトコルもしくはその他何らかのプロトコル、または複数プロトコルの組み合わせを用いて、データモードで動作する。

動作（４）で、デバイスのto‐doリスト処理モジュール３３４が（その時点で休眠状態であれば）起動し、ＴＰＨ信号に反応する。この通知プロセスは、第一の電力状態から第二の電力状態に切り替わることを含み得、第二の電力状態は、第一の電力状態よりも多くの電力を消費する。起動すると、to‐doリスト処理モジュール３３４は、メッセージをto‐doリストサーバモジュール３１４へ送信する。このメッセージは、to‐doリストサーバモジュール３１４に、ｎ個のエントリー、例えば、限定されるものではないが１０個のエントリーなどのリストを転送するよう要求する。ｎ個のエントリーは、to‐doリストサーバモジュール３１４によってユーザデバイス１０４用に維持されるリスト内のエントリーのサブセットを表し得る。to‐doリストサーバモジュール３１４は、最大ｎエントリーまでのリストを転送することによってこの要求に応答する。

上記のように、各エントリーは、命令を伝達するエンベロープを提供する。そのような１つの種類の命令は、ユーザデバイス１０４に、ＩＰＳ１０２からアイテムを読み出すよう命じる。他のタイプの命令もあるが、それはセクションＢに記載する。動作（５）で、to‐doリストサーバモジュール３１４から読み出されたｎエントリーのうちの１つまたは複数のエントリーがＧＥＴ命令に相当すると仮定すると、to‐doリスト処理モジュール３３４は、コンテンツ配信モジュール３１６へ要求を送信して、ＧＥＴ命令で特定されたアイテムをダウンロードするようこのモジュール３１６に依頼する。

動作（６）で、コンテンツ配信モジュール３１６は、コンテンツ記憶３０８からのアイテムの読み出しを試行することで、アイテムの要求に応答する。コンテンツ配信モジュール３１６は、成功すれば、要求されたアイテムをユーザデバイス１０４へ転送する（これは、図８に示されているように、動作（５）の一部と見なされるとよい）。フィードの場合など、状況次第で、ユーザデバイスが既に以前のバージョンをローカルに所有している場合には、コンテンツ配信モジュール３１６は、要求されたコンテンツの現バージョンと、そのコンテンツの以前のバージョンとの差を表す差分ファイルの読み出しおよびダウンロードを試行するとよい。この前置きの説明を過度に複雑にしないように、増分更新動作の詳細は、本記載の後の部分に提供する。

動作（６）は、様々な許可確認ステップも含むとよい。例えば、電子書籍および他の個々に選択されたものの場合、コンテンツ配信モジュール３１６は、個人用メディアライブラリモジュール３２４と通信して、ユーザがそのアイテムを受け取ることを承認されているかどうかを判断することができる。予約購読関連アイテムの場合、コンテンツ配信モジュール３１６は、予約購読モジュール３１０と通信して、ユーザがそのアイテムを受け取ることを承認されているかどうかを判断することができる（例えば、ユーザが特定の予約購読の各号を受け取ることを一般に承認されているかどうかを判断することによって）。図８を過度に複雑にしないよう、許可確認に関連した信号フローは省略されているが、この詳細は、後からの図面および付随する記載で提供される。

動作（５）で、コンテンツ配信モジュール３１６は、様々なヒントもユーザデバイス１０４にダウンロードするとよい。そのようなヒントの１つは、要求されたアイテムに対応する索引をＩＰＳ１０２が保持しているかどうかをユーザデバイス１０４に知らせる。例えば、ＩＰＳ１０２は、初めにこのアイテムを受信したときまたはその他何らかの時点で、この索引を作成していることもある。別のヒントは、要求されたアイテムの注釈をＩＰＳ１０２が保持しているかどうかをユーザデバイス１０４に知らせる。この注釈は、前の一時点または複数時点でユーザによって形成されて、ＩＰＳ１０２によってバックアップされた情報に相当するとよい。ユーザデバイス１０４は、このヒントを用いて、要求されたアイテムの検索索引および／または注釈を配信するようＩＰＳ１０２に要求しても無駄ではないかを判断する。すなわち、コンテンツ配信モジュール３１６が、検索索引がないことをユーザデバイス１０４に知らせれば、索引を要求することは有益な行為ではない。ヒントを用いることによって、ユーザデバイス１０４が、索引情報および／または注釈情報をＩＰＳ１０２が格納しているかどうかを判断するために無線で遅い可能性のある問い合わせおよび／または応答手順を行う必要性を排除する。

ユーザデバイス１０４が、ヒントによって、ＩＰＳ１０２が実際に検索索引およびバックアップの注釈のいずれか（または両方）を有することを通知されると仮定する。動作（７）で、to‐doリスト処理モジュール３３４は、この種類の補助情報を要求および受け取る。

動作（８）で、to‐doリスト処理モジュール３３４は、デバイスメモリ３３６内にアイテム（および任意選択で補助情報）を格納する。

動作（９）で、to‐doリスト処理モジュール３３４は、to‐doリストサーバモジュール３１４へ削除メッセージを送信する。このメッセージは、ユーザデバイス１０４が、特定されたアイテムのサブセットをＩＰＳ１０２から読み出すことに成功したこと、およびしたがって、to‐doリストサーバモジュール３１４はこのアイテムを適切なキューから削除してよいということを、ｔo‐doリストサーバモジュール３１４に通知する。動作（１０）で、to‐doリストサーバモジュール３１４は、ユーザデバイス１０４によって送信された削除メッセージ受け取りの応答をすることができる。

読み出されたｎ個のエントリーは、to‐doリストサーバモジュール３１４によって保持されている、より網羅的なアイテムのリストのサブセットのみに対応することがある。この場合には、to‐doリスト処理モジュール３３４は、さらに最大ｎ個までのエントリーを読み出して、このエントリーにより特定されたアイテムをコンテンツ配信モジュール３１６から受け取ることによって、上記の動作を繰り返す。

図示してはいないが、ダウンロード・プロセスでエラーが生じると、ユーザデバイス１０４はエラー情報をＩＰＳ１０２に伝達することができ、かつ／または逆もまた同様である。

Ｂ．システム内の実例となる構成要素
セクションＡでシステムの概要を説明したが、このセクションは、システムの様々な構成要素についてさらに詳しく説明する。各構成要素は、上記の総合的システムを背景として用いられ得るが、各構成要素は、他の種類のシステムで用いることも可能である。

Ｂ．１．実例となるコンテンツ受信機能
Ｂ．１．ａ．コンテンツ受信システムの概要
上記のように、コンテンツ受信システム３０２は、１つまたは複数のソース３０４からアイテムを受け取り、適切であれば、そのアイテムをデバイス読取可能なフォーマットに変換する。このような変換は、変換プロセスはゼロからコンテンツを生成しないため、本願明細書では広い意味で「コンテンツ形成」とも呼ばれる。コンテンツ受信システム３０２は、事前作成アイテム（電子書籍など）、予約購読関連アイテム、および個人用アイテムを取り扱う別々のモジュールを備えているとよい。すなわち、コンテンツ受信システム３０２は、電子書籍処理モジュール９０２、予約購読関連処理モジュール９０４、およびユーザ供給処理モジュール９０６を備える。

電子書籍処理モジュール９０２は、典型的にはユーザがオンデマンド方式で選択するアイテムを受け取り、処理および格納する。例えば１つのシナリオでは、電子書籍処理モジュール９０２は、新たな電子書籍を、出版社ソースまたは他の種類のソースから受信し、このアイテムを望ましいフォーマットに変換し、このアイテムをコンテンツ記憶３０８に格納するとよい。このモジュール９０２によって実行される処理は、新たに受信されたアイテムの検索索引を形成すること、このアイテムの詳細ページを形成することなども含み得る。その結果、ユーザは、電子書籍アイテムが格納された後の或る時点でこのアイテムを購入し、したがってユーザへのアイテムのダウンロードを開始することができる。電子書籍受信プロセスはダウンロード・プロセスと切り離されており、この２つの動作は非同期的に生じるということを意味する。

予約購読関連処理モジュール９０４は、アイテムを、予約購読関連ベースで受け取り、処理および格納する。１つ典型例では、ユーザが予約購読を購入するとよく、これによって、ユーザは、雑誌、機関誌、ニュースレター、新聞、ブログ、フィードなどのその後の号など、予約購読関連アイテムのその後のｊ号、版、一話分などを受け取る権利を与える予約購読を購入することができる。この場合の受信プロセスはダウンロード・プロセスに関連付けられており、新たな予約購読関連アイテムの受信が、このアイテムを受け取るように登録しているユーザへのこのアイテムのダウンロードを引き起こすことを意味する。

予約購読関連の受信動作の変形では、予約購読関連コンテンツ処理モジュール９０４は、場合によってはユーザの関与および／または認可なしで、ユーザの予約購読を自動的に確立し、この予約購読に従ってアイテムを配信するとよい。この特徴は、ユーザに広告を提供するため、ユーザに様々なアラートおよび他のイベントを通知するためなどに有用であり得る。別の例として、ユーザが、１つまたは複数のタイプの予約購読を明確に購入し、それに応答して予約購読関連処理モジュール９０４は、明確に購入された予約購読、並びに１つまたは複数の他の（ユーザが明確に購入しなかった）予約購読の配布を承認してもよい。さらに別の場合には、ユーザは、例えば、ユーザがまだ刊行されていないアイテムを事前購入する場合など、アイテムの単一の出版物を予約購読してもよい。アイテムが刊行されると、このアイテムを事前購入したユーザにこのアイテムを配信するよう、予約購読関連処理モジュール９０４が呼び出されることになる。

ユーザ供給処理モジュール９０６は、もともとユーザにより供給されるアイテムを形成する。つまり、第一段階で、ユーザ供給処理モジュール９０６はユーザからアイテムを受け取る。アイテムは、ワープロ文書、ＰＤＦ文書など、任意の種類の個人用文書に相当し得る。第二段階で、ユーザ供給処理モジュール９０６は、このアイテムをデバイス読取可能なフォーマットに変換し、次に、変換済みアイテムをユーザに返送する。ユーザは、そのユーザデバイス１０４を用いて、変換済みアイテムを消費することができる。

コンテンツ処理モジュール（９０２、９０４、９０６）のいずれも、１つまたは複数の変換ツール９０８に依存し得る。各変換ツールは、コンテンツをオリジナルのフォーマットから定義されている目標のフォーマットに変換する機能を提供する。例えば、．ｍｏｂｉ変換ツール９１０は、コンテンツをオリジナルのフォーマットから．ｍｏｂｉフォーマットに変換する。他のツール（９１２、．．．９１４）は、アイテムを、オリジナルのフォーマットから他の個別の種類のデバイス読取可能なフォーマットに変換する。一例では、変換ツール９０８は、所定数の受け取り可能なオリジナルのフォーマットでアイテムを受け取る。限定されるものではないが、実例となる一実施形態では、受け取り可能なオリジナルのフォーマットには、Ａｄｏｂｅ ＰＤＦフォーマット、ＴＸＴフォーマット、ＨＴＭＬフォーマット、リッチテキストフォーマット（ＲＴＦ：ｒｉｃｈ ｔｅｘｔ ｆｏｒｍａｔ）、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ文書フォーマット（ＤＯＣ）などが挙げられ得る。受け取り可能な画像のフォーマットには、限定されるものではないが、ＪＰＥＧフォーマット、ＧＩＦフォーマット、ＰＮＧフォーマット、ＢＭＰフォーマットなどが挙げられ得る。

Ｂ．１．ｂ．実例となる予約購読モジュール
図１０は、予約購読モジュール３１０についてのさらなる情報を示す。これは、図３との関連で紹介されたものである。予約購読モジュール３１０は、予約購読管理モジュール１００２を含む。予約購読管理モジュール１００２は、予約購読の形成および終了、並びに予約購読のその他の側面を管理する。一例では、店舗モジュール３１８が、ユーザの予約購読の購入（またはより一般的に、ユーザの予約購読の入手）を受け取ることができる。店舗モジュール３１８は、ユーザの選択を予約購読管理モジュール１００２に伝達することができる。次に、予約購読管理モジュール１００２は、予約購読記憶１００４と、例えば新たなエントリーを記憶１００４に追加すること、記憶１００４内のエントリーを消去すること、記憶１００４内のエントリーを変更することなどによって、やりとりする。

より具体的には、予約購読モジュール３１０は、利用可能な予約購読を、個々の親タイプ・ノードとして特定する。予約購読の特定の号が受信および処理されると、予約購読モジュール３１０は、この発行物を、対応する親予約購読の子ノードとして関連付ける。ユーザが特定の予約購読を購入すると仮定する。その時点で、ユーザは、その予約購読に対応する特定の親ノードに関連付けられる。加えて、または代わりに、予約購読が、デバイスまたはその他の事業体に関連付けられることが可能である。さらに、一実施形態では、予約購読モジュール３１０は、ユーザを予約購読の個々の号ではなく親予約購読に関係付けることで、この予約購読の各号のユーザ所有権を管理する。

予約購読管理モジュール１００２はさらに、コンテンツ配信モジュール３１６とやりとりして、ユーザが予約購読関連アイテムをダウンロードするための適切な承認を得ているかどうかを、コンテンツ配信モジュール３１６に（予約購読アイテムの個々に選択されたものではなく、予約購読の条件に則って受信されるアイテムの場合に関して）知らせる。一例では、そのような許可確認は、号ごとではなく（特定の一実施形態における、許可確認がアイテムごとに行われる電子書籍およびその他個々に選択されたものの場合とは違って）予約購読ごとに行われる。

Ｂ．１．ｃ．実例となる索引作成機能および注釈取り扱い機能
コンテンツ受信プロセスにより生成されたコンテンツに加えて、補助情報がアイテムに関連付けられ得る。そのような種類の補助情報の１つは索引情報である。もう１つのタイプの補助情報は注釈情報である。図１１は、そのような補助情報を生成する機能の概要を提供する。

デバイス索引の形成については、ＩＰＳ１０２は、サーバ側索引作成機能１１０２を提供するとよい。サーバ側索引作成機能１１０２は、索引を作成するサーバ側索引作成モジュール１１０４を含むことができる。サーバ側索引作成モジュール１１０４は、作成した索引をサーバ側索引記憶１１０６に格納する。ユーザデバイス１０４は、索引を作成するデバイス側索引作成機能１１０８を備え得る。したがって、ＩＰＳ１０２およびユーザデバイス１０４はどちらも、アイテムの索引を作成する能力がある。

索引がサーバ側索引作成機能１１０２によって提供されるか、またはデバイス側索引作成機能１１０８によって提供されるかを決定するために、様々な規則が用いられ得る。一考察によれば、ユーザデバイス１０４は、デバイス側索引作成機能１００８を用いて索引の作成を試行するが、この処理が遅すぎることが分かると、ユーザデバイス１０４は、サーバ側索引作成機能に索引を作成するよう要求することができる。

注釈の形成および取り扱いについては、ユーザは、デバイス側注釈作成機能性１１１０を用いて特定のアイテムの注釈を形成する。（デバイス側注釈作成機性１１１０は、図４で紹介された注釈モジュール４０６と同義であると見なされるとよい。）ユーザは、ブックマーク・タイプの注釈、ハイライト・タイプの注釈、メモ・タイプの注釈、切り抜きタイプのコンテンツの抜粋などを形成することができる。ユーザデバイス１０４は、「最後に読んだページ」位置も形成することができる。このタイプの注釈は、アイテムが開かれていた最後の位置を特定する。デバイス側注釈作成機能性１１１０は、注釈を任意のデバイス側記憶に格納する。ユーザデバイス１０４は、この注釈を、対応するアイテムを表示するときに読み出し、再形成することができる。例えば、デバイスがアイテムを再び開くと、ユーザデバイス１０４は、デバイス１０４が閉じられたときにユーザが閲覧していた、同じページを示すとよい。

システム３００は、ユーザによってユーザデバイス１０４で形成された注釈のバックアップを格納するために、サーバ側注釈取り扱い機能１１１２にも依存するとよい。サーバ側注釈取り扱い機能１１１２は、様々な時点でユーザデバイス１０４から注釈を受け取る、同じ名前のモジュール１１１４を備え得る。一例では、ユーザデバイス１０４は、様々なイベントが生じたときに実行する一連の動作の一部として、注釈をＩＰＳ１０２に転送することができる。そのようなイベントは、デバイス１０４がＩＰＳ１０２とやりとりしなければならない任意の機会を含み得る（例えば、ＴＰＨ信号の受信に応答してなど）。サーバ側注釈取り扱いモジュール１１１４は、ユーザデバイス１０４から受け取る注釈をサーバ側注釈バックアップ記憶１１１６に格納することができる。

ＩＰＳ１０２がバックアップの注釈を保存していれば、ＩＰＳ１０２は、ユーザデバイス１０４にヒント情報を提供することで、この事実をユーザデバイス１０４に通知することができる。ヒント情報は、コンテンツ配信モジュール３１６からユーザデバイスに送付されるアイテムと共に送られる。そのヒントが、バックアップの注釈が利用可能であることを示せば、ユーザデバイス１０４は、その注釈をダウンロードすることを選び得る。ユーザデバイス１０４は、こうした注釈を、このような注釈のローカル記憶が消去されている場合などに受信を望む可能性がある。

Ｂ．１．ｄ．事前作成アイテムを受信および処理するための実例となる手法
セクションＢ．１の残りは、電子書籍およびその他の事前作成アイテム、予約購読関連アイテム、並びに個人用アイテムを受信および処理するプロセスについて、さらなる情報を提供する。

図１２から開始すると、この図面は、電子書籍アイテムおよびその他の事前作成アイテムを受信および処理する１つの形を示す信号フロー図である。動作（１）で、電子書籍処理モジュール９０２は、電子書籍等を出版社または他のソースから受け取る。電子書籍処理モジュール９０２は、任意選択で、電子書籍アイテムをデバイス読取可能なフォーマットに変換し、このアイテムの索引を形成し、かつ／または店舗モジュール３１８内に、このアイテムを表す詳細ページを形成してもよい。

動作（２）で、電子書籍処理モジュール９０４は、アイテムおよびその補助部分をコンテンツ記憶３０８に格納する。

動作（３）で、ユーザはマーチャント・コンテンツ・ストア３１８から電子書籍を購入するか、または他の形で入手するために、デバイス側店舗対話モジュール３４４を操作してもよい。

動作（４）で、電子書籍処理モジュール９０２は、ユーザが電子書籍またはその他の個々に選択されたアイテムを購入したことを示す重要情報をメディアライブラリモジュール３２４に格納してもよい。以下にさらに詳しく記載するように、コンテンツ配信モジュール３１６は、アイテムの配信時、メディアライブラリモジュール３２４と通信し、ユーザがそのアイテムを受け取ることを承認されているかどうかを判断する（例えば、ユーザが実際にそのアイテムを購入したかどうかを判断）してもよい。

それに応答して、動作（５）で、店舗モジュール３１８は、購入されたアイテムに対応するエントリーを、ユーザのto‐doリストに追加することができる。このアクションは、直ちに（または後の或る時点で）ＴＰＨ信号をユーザデバイス１０４へ送信してアイテム入手のための命令が未処理であることをユーザデバイス１０４に通知するように、to‐doリストサーバモジュール３１４を促す。

信号図の上半分は、動作の中の形成段階１２０２に相当し、その段階で新たな電子書籍が受信および処理される。信号図の下半分は、動作の中の配信段階１２０４に対応し、その段階では、以前に格納されたアイテムをユーザが購入し、受け取る。形成段階１２０２は配信段階１２０４に先行するが、この２つの段階（１２０２、１２０４）は、その他の点ではつながっていない。

図１５は、電子書籍処理動作をフローチャート形式で表す手順１５００を示す。

ブロック１５０２で、電子書籍処理モジュール９０２が、例えばアイテムの出版社またはその他何らかのソースから、新たなアイテムを受け取る。

ブロック１５０４で、電子書籍処理モジュール９０２は任意選択で、新たなアイテムをデバイス読取可能なフォーマットに変換するが、これはすなわち、アイテムが既にデバイス読取可能なフォーマットで表されていないと仮定してのことである。

ブロック１５０６で、電子書籍処理モジュール９０２は任意選択で、アイテムの索引、アイテム詳細ページ、および／またはアイテムに関連した他の補助情報を形成する。

ブロック１５０８で、電子書籍処理モジュール９０２は、変換済みアイテムと、アイテムに関連した任意の補助情報とを格納する。

ブロック１５１０で、後の任意の時点で、店舗モジュール３１８が、ユーザのアイテムの購入を受け取る。

ブロック１５１２で、電子書籍処理モジュール９０２が、購入情報をメディアライブラリモジュール３２４に格納する。この情報は、ユーザが特定の電子書籍等を購入したことを特定する。

ブロック１５１４で、店舗モジュール３１８またはその他何らかのサーバ側モジュールが、エントリーを、to‐doリストサーバモジュール３１４内の、当該デバイスのto-doキューに追加する。このエントリーは、購入されたアイテムを読み出すようユーザデバイス１０４に命令する命令を含む。

ブロック１５１６は、アイテムをダウンロードするために呼び出されるアイテム配信手順を全般的に指す。後の図面が、この動作をさらに詳しく説明する。

Ｂ．１．ｅ．予約購読関連アイテムを受信および処理するための実例となる手法
図１３は、予約購読関連アイテムを受信および処理する１つの形を示す信号フロー図である。動作（１）で、予約購読関連処理モジュール９０４が、予約購読関連アイテムを受け取り、処理する。この処理は、アイテムをデバイス読取可能なフォーマットに変換すること、アイテムに索引を付けることなどを含めばよい。

動作（２）で、予約購読関連処理モジュール９０４は、受信した予約購読関連アイテムをＩＰＳコンテンツ記憶３０８に格納する。図１５には示されていないが、予約購読モジュール３１０において、新たな号は、対応する親予約購読の子ノードとして特定される。上で説明したように、一例では、配信時の許可確認は、アイテムごと（例えば号ごと）ではなく、全般的な予約購読レベルごとに行われる。しかし、ユーザが予約購読関連アイテムの独立した選択（例えば個々の選択）を行った場合には、上記の電子書籍許可確認が、そのアイテムへのアクセスを管理するために用いられる。

動作（３）で、予約購読関連処理モジュール９０４は、予約購読モジュール３１０と通信し、新たに受信された予約購読関連アイテムを受信すべきユーザを決定する。

動作（４）で、予約購読関連処理モジュール９０４は、特定された予約購読しているユーザの各to‐doキューにエントリーを格納してもよい。

図１６は、予約購読関連の処理動作をフローチャート形式で表す手順１６００を示す。

ブロック１６０２で、予約購読関連処理モジュール９０４が、雑誌の号、新聞の版、フィード・アイテムなどの、新たな予約購読関連アイテムを受け取る。

ブロック１６０４で、予約購読関連処理モジュール９０４は、受信したアイテムを、適切であればデバイス読取可能なフォーマットに変換し、さらに任意選択で、デバイス索引などの補助情報を生成する。

ブロック１６０６で、予約購読関連処理モジュール９０４は、受信した（および場合によっては変換された）予約購読関連アイテムをコンテンツ記憶３０８に格納する。

ブロック１６０８で、予約購読関連処理モジュール９０４は、予約購読モジュール３１０と通信し、予約購読関連アイテムを受信すべきユーザを決定する。

ブロック１６１０で、予約購読関連処理モジュール９０４は、この予約購読関連アイテムを受け取ることになるユーザのto‐doキューそれぞれにエントリーを提供する。

ブロック１６１２は、アイテムをダウンロードするために呼び出されるアイテム配信手順を全般的に指す。後の図面が、この動作をさらに詳しく表す。

Ｂ．１．ｆ．個人用文書を受信および処理するための実例となる手法
図１４は、個人用アイテム（個人用文書など）を受信および処理する１つの形を示す信号フロー図である。動作（１）で、ユーザは、電子メール機能またはその他のメッセージ作成機能を用いて、個人用アイテムを、ユーザ供給処理モジュール９０６に送付する。例えば、ユーザは、電子メール・メッセージへの添付として個人用アイテムを含めてもよい。一例では、ユーザは、電子メール・メッセージで単一の個人用アイテムを送付してもよい。別の例では、ユーザは電子メール・メッセージで、例えばその電子メール・メッセージへの複数の添付として、複数の個人用アイテムを送付してもよい。ユーザ供給処理モジュール９０６は、ユーザが、１つまたは複数の添付を、例えばＺＩＰファイルまたは他の形式のパッケージにまとめることを可能にする。

一実施形態では、ユーザ供給処理モジュール９０６は、１つまたは複数の事前に承認された電子メール・アドレスからのユーザからのみ電子メール・メッセージを受け取るよう設定される。一例では、ユーザは、設定手順（例えば、１つまたは複数の設定ユーザ・インターフェース・ページを介する）で電子メール・アドレス（単数または複数）を選択することができ、それによって、許可される電子メール・アドレスのリストが確立される。ユーザ供給処理モジュール９０６は、最初に、ユーザによって用いられるとよいデフォルトの電子メール・アドレスを提供し得る。ユーザは、後でこのデフォルト電子メール・アドレスを変更するか、それにアドレスを追加してもよい。許される電子メール・アドレスを制限することは、ユーザに送付される好ましくないアイテムをなくすか、または量を減らすのに役立つ可能性がある。好ましくないアイテムは、こういったアイテムを受け取るためにユーザが無線配信料金を請求される場合、特に悪質であると考えられる。一方、別の実施形態では、ユーザ供給処理モジュール９０６が、ユーザ供給処理モジュール９０６に個人用アイテムを送付するために用いられてよい電子メール・アドレスにいかなる制限も加えない場合もある。

動作（２）で、ユーザ供給処理モジュール９０６は、受信し、その受信したメッセージを処理してもよい（そのメッセージが許可アドレス・リストで特定されているアドレスに由来する場合に）。当該の処理は、メッセージのソース、変換済みアイテム（単数または複数）が送信されることになる目標の宛先、および／またはその他、そのメッセージについての重要情報を特定するために、メッセージを解釈することを含み得る。この処理は、個人用アイテム（単数または複数）をメッセージから抽出して、そのアイテムをデバイス読取可能なフォーマットに変換することも含む。１つまたは複数の個人用アイテムがＺＩＰファイルなどにパッケージ化されている場合、抽出動作は、１つまたは複数の個人用アイテムを、このパッケージ・ファイルから取り出すことを含むこともある。

上記の処理動作は、完全に成功するか、完全に失敗するか、または部分的に成功する（かつ部分的に失敗する）可能性がある。部分的な失敗は、電子メール・メッセージが添付として複数の個人用アイテムを含んでおり、ユーザ供給処理モジュール９０６がこのアイテムのうちの一部の変換には成功するが、他のアイテムでは不成功となる場合に生じ得る。例えば、変換が不成功であったアイテムは、サポートされていないオリジナルのフォーマットで表されることもある。動作（３）で、ユーザ供給処理モジュール９０６は、任意の種類の失敗（全体的な失敗または部分的な失敗）を電子メールの送信者に通知してもよい。部分的な失敗の場合、ユーザ供給処理モジュール９０６は、処理が成功したアイテム（単数または複数）の処理を、例えばこうしたアイテムをユーザに配信することによって続けるしてもよい。

ユーザは、変換済み個人用アイテム（単数または複数）を受け取るために、少なくとも２つの配信オプションを選択することができる。第ーのオプションでは、ユーザは、変換済み個人用アイテム（単数または複数）が無線形式でユーザに転送されるよう要求することができる。この場合には、動作（４）でユーザ供給処理モジュール９０６が、to‐doリストサーバモジュール３１４内のユーザのto‐doキューにエントリーを追加する。第二のオプションでは、ユーザは、変換済み個人用アイテム（単数または複数）が、非無線の経路を介してユーザが利用できるようになるよう要求することができる。例えば、ユーザは、変換済み個人用アイテム（単数または複数）が、電子メール形式でユーザに送信されるよう要求することができる。ユーザは、変換済み個人用アイテム（単数または複数）を電子メール・メッセージから抽出し、続いてその変換済み個人用アイテム（単数または複数）を、ＵＳＢ接続などの結線リンクを介してユーザデバイス１０４へ伝送してもよい。または、ユーザは、変換済みアイテム（単数または複数）が、ネットワークアクセス可能なサイトに載せるように要求してもよい。ユーザは、個人用コンピュータまたは同様の機構を用いてこのサイトにアクセスし、変換済みアイテム（単数または複数）を（非無線の環境を通じて）ダウンロードし、続いて変換済みアイテム（単数または複数）を、ＵＳＢ接続またはその他の機構を介してユーザデバイスに伝送してもよい。動作（５）は、１つまたは複数の個人用アイテムの、非無線の経路を介した配信を全般的に表す。一般的に、ユーザは、コンテンツの無線ダウンロードに見込まれる費用を回避するために、非無線の経路を用いることの方を好む可能性がある。

図１７は、個人用アイテム処理動作をフローチャート形式で表す手順１７００を示す。

ブロック１７０２で、ユーザ供給処理モジュール９０６は、ユーザから電子メール・メッセージなどのメッセージを受け取る。これは、添付のユーザ供給アイテム（または複数のアイテム）を含む。

ブロック１７０４で、ユーザ供給処理モジュール９０６は、メッセージが、許されるアドレスから来たものであるかどうかを、許可アドレス・リストを調べることによって判断する。許可される場合、ユーザ供給処理モジュール９０６は、メッセージを解析および解釈し、さらにそれに添付されている個人用アイテム（単数または複数）を抽出する。アイテムの抽出には、任意の種類のパッケージ・ファイルからアイテムを取り出すことが含まれ得る。

ブロック１７０６で、ユーザ供給処理モジュール９０６は、個人用アイテム（単数または複数）が現在実際にデバイス読取可能なフォーマットでなければ、個人用アイテム（単数または複数）をデバイス読取可能なフォーマットに変換する。ユーザ供給処理モジュール９０６は、この変換を実行するために単一の機構に依存することができる。あるいは、ユーザ供給処理モジュール９０６は、複数の利用可能な変換機構のうちの任意の１つまたは複数のものに依存することができる。例えば、ユーザ供給処理モジュール９０６は、特定のタイプのアイテムを変換するのに最も適していると見なされる変換機構を選択することができる。加えて、または代わりに、ユーザは、特定のアイテムに適用される１つまたは複数の機構を特定する命令を送付することができる。一例では、ユーザ供給処理モジュール９０６が、１つのタイプの変換機構を用いたアイテムの処理に成功しなければ、別の変換機構などを試すことができる。

加えて、または代わりに、変換は任意選択で、変換済みアイテムのユーザデバイスによる提示によりよく適応する形に個人用アイテムをサイズ変更することを含み得る。すなわち、この準備によって、変換済みアイテムをデバイス上に提示されたときに、より読みやすくしてもよい。

加えて、または代わりに、変換は、この場合もやはりユーザデバイスによる変換済みアイテムの提示によりよく適応するよう、個人用アイテムを、例えば９０度回転させることを含み得る。

加えて、または代わりに、変換は、ユーザデバイス上で複数のページにおいて提示されるよう、個人用アイテムを複数の部分に分割することを含み得る。例えば、ブロック１７０６の右側に示されているように、ユーザ供給処理モジュール９０６は、個人用アイテムを９０度回転させて、続いてそれを複数の部分に分割し得る。この動作は、大きな画像を有する、一部の個人用アイテム（例えば、スキャンされたページ画像を有するＰＤＦ文書）に適し得る。この場合もやはり、この準備によって、変換済みアイテムがデバイス上に提示されたときに、より読みやすくなり得る。

ブロック１７０８で、ユーザ供給処理モジュール９０６は、ユーザが、変換済み個人用アイテム（単数または複数）の受信にどの経路を用いたいかを判断する。一例では、ブロック１７０８で行われる判断は、暗に示されていてもよい。例えば、ユーザ供給処理モジュール９０６は、変換されると無線経路を通じて送信されるべきアイテムを受け取るための、第一の電子メール・アドレスを提供し得る。ユーザ供給処理モジュール９０６は、非無線の経路を通じて送信されるべきアイテムを受け取るための、第二の電子メール・アドレスを提供してもよい。ユーザが第一の電子メール・アドレスに個人用アイテム（単数または複数）を送信すると、ユーザが、変換済みアイテムを無線経路を介して受信したいということが分かる。ユーザが個人用アイテム（単数または複数）を第二の電子メール・アドレスに送信すると、ユーザが、変換済みアイテム（単数または複数）を非無線の経路を介して受信したいということが分かる。別の例では、ユーザ供給処理モジュール９０６が、個人用アイテムの受信用に単一の電子メール・アドレスを提供してもよい。ユーザ供給処理モジュール９０６は、メッセージ自体の中で提供される命令を解釈することなどによって、選択された配信経路を識別してもよい。

ユーザが無線配信経路を選択したと仮定する。この場合、ブロック１７１０で、ユーザ供給処理モジュール９０６は、to‐doリストサーバモジュール３１４内のユーザのto‐doキューにエントリーを追加する。

ブロック１７１２は、アイテム（単数または複数）をダウンロードするために呼び出されるアイテム配信手順を全般的に指す。後の図面が、この動作をさらに詳しく表す。

次に、ユーザが非無線の配信経路を選択したと仮定する。ブロック１７１４で、ユーザ供給処理モジュール９０６は、例えば変換済みアイテム（単数または複数）を電子メールでユーザに送り返す、変換済みアイテムをネットワークアクセス可能なサイトに載せるなどの、代わりの伝送機構によって、変換済みアイテム（単数または複数）をユーザが利用できるようにする。

ブロック１７１６に示されているように、ユーザ供給処理モジュール９０６は、アイテム（単数または複数）の処理に失敗があるかどうかを確認することができる。エラーがあれば、ブロック１７１８で、ユーザ供給処理モジュール９０６はエラー通知メッセージを送信者へ送信する。部分的な失敗しかなければ、処理が成功していると考えられるアイテム（単数または複数）について処理を続行する。

Ｂ．２．実例となるTo‐Doサーバモジュール
このセクションは、to‐doリストサーバモジュール３１４の実例となる構成および動作についてさらなる情報を提供する。to‐doリストサーバモジュール３１４は、ユーザデバイス１０４に命令を送信し、それによってユーザデバイス１０４に、アイテムを読み出しその他のアクションを実行するよう命令することによって動作するということを思い出されたい。

to‐doサーバモジュール３１４は、to‐doリスト受信モジュール１８０２を備える。to‐doリスト受信モジュール１８０２は、前のセクションに記載した様々な処理モジュール（９０２、９０４、９０６）などの様々なソースからエントリーを受け取る。例えば、to‐doリスト・エントリー受信モジュール１８０２は、ユーザが電子書籍または同様のコンテンツを購入したとき、予約購読関連アイテムが受け取られるとき、ユーザが個人用文書をＩＰＳ１０２へ送信するときなどに、エントリーを受け取り得る。こうしたイベントはすべて、ＧＥＴタイプ・エントリーを作成させ、これは、ユーザデバイス１０４がＧＥＴタイプ・エントリーに対応するアイテムをダウンロードするための命令として機能する。他のＩＰＳ側モジュールがＧＥＴタイプ・エントリーをキューに追加し、ユーザデバイス１０４に、命令を有するアップグレードを提供するアイテムをダウンロードするべきであると通知してもよい。

他の種類のエントリーは、他の種類の命令を伝達することができる。一例では、ＩＰＳ１０２内の要素が、以前に受信してそのデバイスメモリ３３６に格納したと考えられるアイテムを消去するようユーザデバイス１０４に命令する、消去（ＤＥＬ：ｄｅｌｅｔｅ）命令を作成してもよい。ある状況では、ユーザがアイテムを購入しており、それがＧＥＴタイプ・エントリーの作成を促した可能性もある。しかし後で、ユーザの信用状態が不十分であり、アイテムの購入が不可能であると判断されることもある。この場合、ＩＰＳ１０２内の適切な要素（店舗モジュール３１８など）がＤＥＬタイプ・エントリーをユーザのto‐doキューに追加するとよい。

別の場合には、ＩＰＳ１０２内の適切な要素（監視および／またはテスト機能など）が、ユーザのto‐doキューにコマンド（例えばＰＵＴ命令）を追加し、ユーザデバイス１０４に、パフォーマンス・ログおよび／またはその他の情報を監視および／またはテスト機能に送付するように要求してもよい。

別の場合には、ＩＰＳ１０２内の適切な要素がto‐doキューに情報を追加し、これがユーザデバイス１０４に、このエントリーを受け取った際、例えばポップアップ形式またはその他のタイプのアラート関連の形式で情報をユーザに表示するよう促してもよい。

ＩＰＳ１０２は、種々のアプリケーションおよび環境に合うよう、さらなる追加のタイプの命令をユーザのto‐doキューに追加してよい。

to‐doリストサーバモジュール３１４は、to‐doキューとも呼ばれる複数のto‐doリストを保持するto‐doリスト記憶１８０４を備えているとよい。より具体的には、to‐doリストサーバモジュール３１４は、例えばユーザデバイスＡにはto‐doリストＡ、ユーザデバイスＢにはto‐doリストＢなど、個々のユーザデバイスに対して別々のキューを保持することができる。ユーザデバイスは、図１８で点線のボックスによって表されているように、それ自体の個々のto‐doリストとやりとりする。これは、メールボックス・ストアＡ内のエントリーがユーザデバイスＡ用に指定されていることを示す。

to‐doサーバモジュール３１４は、デバイス対話モジュール１８０６も含む。デバイス対話モジュール１８０６の目的は、to‐doサーバモジュール３１４が、デバイス側to‐doリスト処理モジュール３３４とやりとりできるようにすることである。デバイス対話モジュール１８０６は、通知モジュール１８０８を含む。通知モジュール１８０８は、通知メッセージを、例えば呼び出しタイプのＴＰＨ信号の形式で、ユーザデバイス１０８へ送付する。その後、デバイス対話モジュール１８０６は、データモードでユーザデバイス１０４とやりとりする。すなわち、デバイス対話モジュール１８０６は、ユーザのto‐doキュー内にあるｎ個のエントリーのリストに関するユーザデバイスの要求を受け取り、受け取り次第、デバイス対話モジュール１８０６はこのリストを提供する。デバイス対話モジュール１８０６は、後で、リストから１つまたは複数のエントリーを削除するためのユーザデバイスの命令を受け取ることができ、これは、ユーザデバイスが、このエントリーに関連したアイテムのダウンロードに成功したことを示す。

to‐doサーバモジュール３１４は、to‐doリスト管理モジュール１８１０を含む。to‐doリスト管理モジュール１８１０は、ユーザのto‐doキューに書き込まれたエントリーを管理する。一例では、或る事業体が、ＧＥＴタイプ・エントリーをユーザのキューに書き込むことができ、続いて同じ事業体または別の事業体が、ＤＥＬタイプ・エントリーを書き込んで、以前に取得するようデバイスが依頼されたのと同じアイテムを消去するようユーザデバイス１０４に命令してもよい。この状況では、一例においてto‐doリスト管理モジュール１８１０はＧＥＴタイプ・エントリーを消去してもよいが、ＤＥＬタイプ・エントリーは消去してはならない。この動作は、ユーザデバイス１０４が既にＧＥＴタイプ・エントリーを受け取っており、対応するアイテムをダウンロードしている最中である可能性のあるシナリオで適切であり得る。

別の場合には、to‐doリスト管理モジュール１８１０は、ユーザのto‐doキューが、新聞またはその他の定期刊行物のいくつかの版を含んでいると判断する。to‐doリスト管理モジュール１８１０は、ユーザは古い新聞を読みたくはないという前提の下に、その定期刊行物の最新版以外すべてを削除してもよい。ユーザには、この動作を無効にするセットアップ選択のオプションが与えられるとよい。別の場合には、ユーザは以下で説明する形で、旧版の新聞にコンテンツ管理モジュール３４２を介してアクセスしてもよい。

概して、to‐doリスト管理モジュール１８１０は、to‐doリスト・キューが、矛盾した、もしくは重複したエントリー、またはその他何らかの好ましくないエントリー・タイプのコンテンツを含まないことを確実にする助けになる。

図１９は、to‐doサーバモジュール３１４の動作の１つの形をフローチャート形式で示す手順１９００を示す。手順１９００は、特定のユーザデバイスへのアイテムの配信に関連して説明される。to‐doサーバモジュール３１４は、同じ手順を用いてアイテムを他のユーザデバイスへ送付する。

ブロック１９０２で、to‐doサーバモジュール３１４は、１つまたは複数のto‐doエントリーを受け取る。この動作は、新たな電子書籍および同様のものの購入、新たな予約購読関連アイテムの受信などによって引き起こされ得る。

ブロック１９０４で、to-doサーバモジュール３１４は、エントリーを適切なメールボックスに格納する（こうしたメールボックスは、最終的にアイテムを受け取ることになるユーザデバイスに関連している）。

ブロック１９０６で、to‐doサーバモジュール３１４は、ＴＰＨ信号をユーザデバイスへ送信して、ユーザデバイスに、ダウンロードできる１つまたは複数のエントリーの存在を知らせる。より具体的には、一つの実施形態では、ＴＰＨスケジューリング機能がＴＰＨイベントを受け取ることができる。１つまたは複数の考慮事項に基づき、ＴＰＨスケジューリング機能は、ＴＰＨ信号を直ちに送信するか、またはＴＰＨ信号の送信を遅らせるかを（例えば、場合により複数のＴＰＨイベントを合体させて単一のＴＰＨ信号を送信することによって）決定するとよい。ＴＰＨスケジューリング機能についてのさらなる詳細は、以下に提供される。ＴＰＨスケジューリング機能は、通知モジュール１８０８の特徴として実装されてもよい。

ブロック１９０８で、to‐doサーバモジュール３１４は、ｎ個のエントリーを、このアイテムをユーザデバイスが要求するのに応答して、ユーザデバイスに提供する。

ブロック１９１０で、各エントリーによって特定された動作の実行にユーザデバイスが成功した後（１つまたは複数のアイテムをダウンロードした、１つまたは複数のアイテムを消去したなど）、ユーザデバイス１０４は、削除命令をto‐doサーバモジュール３１４へ送信する。動作１９１０で、to‐doサーバモジュール３１４は、to‐doキューの各エントリーを削除することでこの要求に応答する。

図２０は、to‐doリストサーバモジュール３１４のto‐doリスト管理モジュール（「管理モジュール」）１８１０の動作の１つの形を示す手順２０００を示す。一つの実施形態では、２０００の手順は、例えば図１９の動作１９０２と１９０４との間で新たなエントリーがto‐doキューに追加されると実行される。

ブロック２００２で、管理モジュール１８１０は、to‐doキュー内のエントリーを分析する（to‐doキューに追加されるべき候補エントリーと共に）。より具体的には、管理モジュール１８１０は、ユーザデバイスへの送信待ちの、キューに現在格納されているエントリーを詳細に検査する。管理モジュール１８１０は、既にユーザデバイス１０４へ送付されたエントリーも考慮するとよい。

ブロック２００４で、管理モジュール１８１０は、何らかの理由で矛盾し合うと考えられるか、またはその他何らかの懸念をもたらすと考えられる、２つまたはそれより多くの任意のエントリーを特定する。矛盾の一例は、ＧＥＴタイプ・エントリーが、同じアイテムのＤＥＬタイプ・エントリーと相反する場合である。対処可能な問題のもう１つの例は、to‐doキューが同じ新聞またはその他の定期刊行物に対していくつかの版を含んでいる場合などである。対処可能な問題のもう１つの例は、to‐doキューが完全に重複したエントリーなどを含んでいる場合である。

ブロック２００６で、管理モジュール１８１０は、可能であれば、矛盾するエントリーによってもたらされる任意の問題を解決または軽減するための措置をとる。動作２００４は、例えばキューへの１つまたは複数のエントリーを消去すること、キューに１つまたは複数のエントリーを追加することなど、キューに変更を加えることを必要とすることもある。動作２００４はさらに、または代わりに、訂正コマンドをユーザデバイスへ送信することを含んでもよい。

Ｂ．３．実例となるTo‐doリスト処理モジュール
図２１は、デバイス側to‐doリスト処理モジュール３３４の詳細を示す。図２１に示されているモジュールは、to‐doリストサーバモジュール３１４に関して図１８に示されているモジュールの多くを補完する。

to‐doリスト処理モジュール３３４は、ＩＰＳ１０２から通知メッセージを、例えば電話の呼び出しの形式で受け取る、ＴＰＨ受信モジュール２１０２を含む。ＴＰＨ受信モジュール２１０２は、ＴＰＨ信号に正式に返答することなく、この信号に基づいて作動することができ、その後にto‐doリスト処理モジュール３３４は、データモードを用いてＩＰＳ１０２と情報を交換する。ＴＰＨ信号を受け取ると、ユーザデバイス１０４は、第一の電力状態から第二の電力状態へ移行し得、この第二の電力状態は、第二の電力状態よりも多くの電力を消費する。これは、ユーザデバイスがまだ第二の電力状態にないと仮定してのことである。

to‐doリスト処理モジュール３３４は、to‐doリストサーバモジュール３１４とのすべてのやりとり（このやりとりのＴＰＨの側面を除いて）を取り扱うのに用いられるリストサーバ対話モジュール２１０４を含む。すなわち、リストサーバ対話モジュール２１０４は、ｎ個のエントリーのリストをto‐doリストサーバモジュール３１４から受け取るための要求を送信してもよい、その結果、読み出し動作が成功すれば、当該のリストを受け取ることができる。ユーザデバイスが、リスト内のエントリーによって参照されているアイテムを取得した（かつ／またはそのエントリーによって特定される他のアクションを実行した）後、リストサーバ対話モジュール２１０４は、削除命令をto‐doリストサーバモジュール３１４へ送信して、to‐doリストサーバモジュール３１４に、そのto‐doキューから対応するアイテムを削除するよう命令するとよい。

to‐doリスト処理モジュール３３４は、コンテンツ配信（ＣＤ：ｃｏｎｔｅｎｔ ｄｅｌｉｖｅｒｙ）対話モジュール２１０６を含む。ＣＤ対話モジュール２１０６の目的は、サーバ側コンテンツ配信モジュール３１６とやりとりして、ｎこのエントリーのリスト内で特定されるアイテムを要求し、取得することである。ＣＤ対話モジュール２１０６は、コンテンツ配信モジュール３１６から様々なヒント、並びに補助情報（例えば、索引情報、バックアップの注釈など）も受け取ることができる。ＣＤ対話モジュール２１０６は、受け取るアイテムおよびその他の情報をデバイスメモリ３３６またはその他何らかの記憶メディア（または複数の記憶メディア）に格納することができる。

to‐doリスト処理モジュール３１４は、デバイス側管理モジュール２１０８も含むことができる。このデバイス管理モジュール２１０８は、to‐doリスト処理モジュール３３４の動作を調整する。さらにデバイス管理モジュール２１０８は、デバイス側増分更新モジュール２１１０およびデバイス側エラー取り扱いモジュール２１１２を含み得る。増分更新モジュール２１１０およびエラー取り扱いモジュール２１１２は、協働して、ＣＤ対話モジュール２１０６によって実行される読み出し動作を管理する。増分更新動作は、後のセクションに詳しく記載する。

まず、要求される特定のタイプのアイテムに対して適切であれば（規定のコンテンツを有するなら）、増分更新モジュール２１１０は、ＣＤ対話モジュール２１０６にまず差分ファイルを要求することで、特定されたアイテムを取得するよう命令してもよい。差分ファイルは、所望のコンテンツのデバイス側のバージョンと、コンテンツの現在のバージョンとの差を表す。何らかの理由でこの動作が成功しなければ（エラー取り扱いモジュール２１１２によって評価して）、増分更新モジュール２１１０は、特定されたアイテムの完全版を要求するようＣＤ対話モジュール２１０６に命令することができる。記載されるように、ＩＰＳ１０２のコンテンツ配信モジュール３１６は、デバイス側増分更新モジュール２１１０とは独立しているがそれと相補的な形で増分更新動作を取り扱う、サーバ側増分更新モジュールを含む。

図２２は、デバイスのto‐doリスト処理モジュール３３４の動作をフローチャート形式で表す手順２２００を示す。

ブロック２２０２で、ＴＰＨ受信モジュール２１０２は、to‐doリストサーバモジュール３１４から通知メッセージを、任意選択で電話の呼び出しの形式で受け取る。ダウンロード・プロセスは、他のイベントによって開始されることも可能である。例えば、このプロセスは、「新たなアイテムを確認」コマンド（例えば、１つまたは複数のデバイス・メニューによって利用可能にされる）の有効化に応答して開始され得る。このプロセスは、ユーザデバイス１０４の無線通信を（オフ状態から）オンにすることでも開始され得る。このプロセスは、ユーザデバイス１０４が、無線サービスが利用可能でなかった地理的な場所から、それを利用可能な場所に入ったときなどにも開始され得る。

ブロック２２０４で、通知メッセージに応答して、ユーザデバイスは（まだ適切な状態でなければ）適切な電力状態に移行する。次に、リストサーバ対話モジュール２１０４は、to‐doリストサーバモジュール３１４によって保持されているto‐doキューから、ｎ個のエントリーを要求して受け取る。

ブロック２２０６で、ＣＤ対話モジュール２１０６が、ｎ個のエントリーによって特定されたアイテムを要求する。

ブロック２２０８で、（ダウンロードが成功すれば）ＣＤ対話モジュール２１０６が、アイテムをヒントと共に受け取る。第一のヒントは、ユーザデバイス１０４に、ＩＰＳ１０２においてアイテムの索引が利用可能であると通知する。第二のヒントは、ユーザデバイス１０４に、ＩＰＳ１０２においてバックアップの注釈が利用可能であると通知する。第一および第二のヒントは、索引および／またはバックアップの注釈がそれぞれ利用可能でないことを示すためにも用いられ得る。

ブロック２２１０で、ＣＤ対話モジュール２１０６は、（適切であると見なされれば）任意選択で補助情報をダウンロードする。そのような追加の情報は、検索索引情報および注釈情報を含む。

ブロック２２１２で、ＣＤ対話モジュール２１０６は、読み出されたアイテム（単数または複数）および補助情報を、デバイスメモリ３３６および／またはその他何らかの記憶場所（単数または複数）に格納する。

ブロック２２１４で、リストサーバ対話モジュール２１０４は、アイテムのダウンロードに成功したことをto‐doリストサーバモジュール３１４に通知し、to‐doリストサーバモジュール３１４が対応するエントリーをto‐doキューから削除できるようにする。

図２２は、動作２２０６〜２２１４が、一括した形で、例えば複数のアイテムを効率的にダウンロードして他の複数アクションを統合されたプロセスとして実行することによって、実行されてもよいということを示す。別の実施形態では、ブロック２２０４でｎ個のエントリーのリストを受信した後、ユーザデバイス１０４は、ｎ個のエントリーのすべてをユーザデバイス１０４が処理するまで、リスト内の第一のエントリーに対して動作２２０６〜２２１４を実行し、続いて、リスト内の第二のエントリーに対して動作２２０６〜２２１４を実行するなどしてもよい。

Ｂ．４．実例としてのコンテンツ配信モジュール
Ｂ．４．ａ．コンテンツ配信モジュールの概要
図２３は、サーバ側コンテンツ配信モジュール３１６についてのさらなる詳細を提供する。サーバ側コンテンツ配信モジュール３１６は、ユーザデバイス１０４の要求に応じて、ユーザデバイス１０４へのアイテムの配信に部分的に関係する多数の機能を実行する。

まず、コンテンツ配信モジュール３１６は、ダウンロード・モジュール２３０２を含む。ダウンロード・モジュール２３０２は、ＣＤ対話モジュール２１０６と連携して、このモジュール２１０６からアイテムの要求を受け取り、さらに可能であれば、要求されたアイテムをＣＤ対話モジュール２１０６に配信する。ダウンロード・モジュール２３０２は、要求されたアイテムをコンテンツ記憶３０８から読み出す。ダウンロード・モジュール２３０２は、索引記憶１１０６および注釈記憶１１１６から補助情報も読み出すことができる。索引記憶１１０６は、要求されているアイテムの索引を格納している（利用可能であれば）。注釈記憶１１１６は、（利用可能であれば）要求されているアイテムのバックアップの注釈を格納している。

ダウンロード・モジュール２３０２は、差分情報記憶２３０６から差分情報を読み出す増分ダウンロード・モジュール２３０４を含み得る。ダウンロード・モジュール２３０２の目的は、可能であれば、要求されたコンテンツの完全版ではなく、要求されたコンテンツの差分版をダウンロードすることである。要求されたコンテンツの差分版は、要求されたコンテンツのデバイス側のバージョンと、要求されたコンテンツの現在のバージョンとの差に相当する。より具体的には、差分情報記憶２３０６は、様々な差分ファイルを提供するが、このファイルそれぞれが、要求されたコンテンツの、あるかもしれないデバイス側のバージョンと、要求されたコンテンツの現在のバージョンとの差に対応する（現在のバージョンと見なされるものは、各新バージョンの受信で変化する）。概して、ダウンロード・モジュール２３０２は、ＩＰＳ１０２からユーザデバイス１０４へ伝送される情報の量を減らすために、コンテンツ全体ではなく、要求されたコンテンツの差分版（差分情報記憶２３０６内の差分ファイルの集合から選択される）の送付を試行する。過度に図２３の説明を複雑にしないように、増分更新プロセスの詳細は、説明の後の部分で提供される。

コンテンツ配信モジュール３１６のいくつかのモジュールが、様々な個別の能力をもってダウンロード・モジュール２３０２を支援する。例えば、コンテンツ配信モジュール３１６は、ヒント提供モジュール２３０８を含む。ヒント提供モジュール２３０８は、特定の要求されたアイテムに関して、索引が索引ストア１１０６に存在するかどうかを特定するヒントを準備し、送付する。ヒント提供モジュール２３０８はさらに、特定の要求アイテムに関してバックアップの注釈が注釈記憶１１１６に存在するかどうかを特定するヒントを準備し、送付する。各ヒントは、ブール形式のはい‐いいえ形式のフィールドとして、またはその他何らかのフォーマットで表され得る。ヒント提供モジュール２３０８は、ダウンロード・モジュール２３０２によって提供されるアイテムと共にヒントを送信することができる。

コンテンツ配信モジュール３１６は、注釈フォーマットモジュール２３１０をも含む。注釈記憶１１６は、バックアップの注釈を、注釈記憶１１１６において一般形式で格納することができる。バックアップの注釈が利用可能で、ユーザデバイス１０４がこの注釈を要求すると仮定すると、注釈フォーマットモジュール２３１０はバックアップの注釈を、その一般形式から、電子書籍アイテム自体のフォーマットなど、対応するアイテム自体のフォーマットに準拠する形式に変換してもよい。続いて、ダウンロード・モジュール２３０２は、その注釈を所望のフォーマットでユーザデバイスに送付してもよい。

一実施形態では、注釈記憶１１６は、上で特定したすべてのタイプの注釈を完全に表す。実例となる別の実施形態では、注釈記憶１１１６は、注釈およびユーザ・メモのコンテンツの場所のみを格納する。この場合、注釈記憶１１１６は、ハイライト・タイプおよび切り抜きタイプの注釈に関連した実際の抜粋は格納しなくてもよい。一実施形態では、注釈フォーマットモジュール２３１０は、コンテンツ記憶３０８と通信し、注釈の格納場所に基づいて抜粋を要求するとよい。これによって、システムは、ハイライト・タイプおよび切り抜きタイプの注釈を再構成することができる。

コンテンツ配信モジュール３１６は、暗号化モジュール２３１２をも含む。暗号化モジュール２３１２は、特定のユーザのユーザデバイス１０４に配信されるアイテムを、任意選択で暗号化することができる。これは、コンテンツ記憶３０８からアイテムを受信して、デジタル著作権管理（ＤＲＭ：Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）および／または他の保護関連の処理をアイテムのヘッダに適用することを含んでもよい。暗号化モジュール２３１２は、暗号化関連の処理をアイテムに適用する前に、メモリ内にアイテム全体のコピーを格納する必要はない。言い換えれば、暗号化モジュール２３１２は、アイテムをユーザデバイス１０４へストリーム形式で流し、必要に応じてアイテムの複数部分に暗号化を適用することができる。一例では、暗号化モジュール２３１２は、配信するすべてのアイテムに暗号化を適用する。別の例では、暗号化モジュール２３１２は、一部のアイテム（例えば電子書籍、予約購読関連アイテムなど）には暗号化を適用するが、他のアイテム（例えば個人用アイテムおよびＩＰＳ作成メッセージなど）には適用しない。

コンテンツ配信モジュール３１６は、個人化モジュール２３１４をも含む。個人化モジュール２３１４は、アイテムがユーザに配信される前に、個人化情報をアイテムに挿入することができる。例えば、アイテムは、１つまたは複数のプレースホルダーフィールドを含み得る。個人化モジュール２３１４は、プレースホルダーフィールドを、例えばユーザの名前などの個人化情報で埋めることができる。

コンテンツ配信モジュール３１６は、メタデータ投入モジュール２３１６をも含む。名称が示唆するように、メタデータ投入モジュール２３１６は、アイテムがユーザに配信される前に、アイテムにメタデータを挿入する。このメタデータは、アイテムの作者の名前を含み得る。説明されるように、コンテンツ管理モジュール３４２は、この名前情報を、１つまたは複数のユーザ・インターフェース・ページでユーザに表示しともよい。メタデータは、アイテムのテキストが始まる場所を特定する情報も含み得る。この場所情報は、ユーザデバイス１０４によって提供される１つまたは複数のメニューを介して呼び出すことができる「冒頭に行く」機能を可能にする。メタデータは、アイテムのカスタム・タイトルも含み得る。このメタデータによって、コンテンツ配信モジュール３１６が、１ページまたは複数ページなどで、「ありがとう、Ｊｈｏｎ」などの個人用メッセージを用いてアイテムを提示できるようになる。最後に言及した特徴は、上述の個人化モジュール２３１４の役割と重なる。

アイテムに投入されるメタデータは、アイテムを特定するために店舗モジュール３１８によって用いられる一意のＩＤ番号などのアイテム識別情報も含み得る。より具体的には、実例となる一実施形態では、コンテンツ受信システム３０２は、コンテンツを受信および処理するとき、ＩＤ番号と、アイテム自体とを、コンテンツ・ストア３０８内で結び付けない。コンテンツ受信システム３０２は、ＩＤ情報をＩＰＳ１０２内の他の場所に格納する。特定のアイテムの配信時に、メタデータ投入モジュール２３１６は、アイテムと、そのＩＤ番号とを関連付けて、この情報の組み合わせをパッケージとして発送してもよい。例えば、メタデータ投入モジュール２３１６は、配信前にＩＤ情報をアイテムのヘッダに挿入してもよい。

一例では、暗号化モジュール２３１２およびメタデータ投入モジュール２３１６（および／またはその他のモジュール）は、別々の動作として順次動作してもよい。別の例では、暗号化モジュール２３１２およびメタデータ投入モジュール２３１６（および／または他のモジュール）は、全般的に、統合された単一の動作として動作してもよい。

コンテンツ配信モジュール３１６は、承認モジュール２３１８をも含む。承認モジュール２３１８は、ユーザが、要求されているアイテム（単数または複数）を受け取る権利を有するかどうかを判断する。承認モジュール２３１８は、ユーザが、要求されているコンテンツに対して適切に支払いを行ったかどうかを示す情報など、承認情報の１つ以上のフィールドを参照して、決定してもよい。上で説明されたように、承認モジュール２３１８は、電子書籍アイテムおよびその他の個々に選択されたものについて、メディアライブラリモジュール３２４とやりとりして、ユーザがアイテムを購入したか（またはその他の形で、受け取る権利を正式に与えられているか）どうかを判断することができる。予約購読により提供される予約購読関連アイテムについては、承認モジュール２３１８は、予約購読モジュール３１０とやりとりして、ユーザが通常、特定の予約購読の発行物を受け取ることを（例えば、アイテムごとに承認の問い合わせを行わずに）承認されているかどうかを判断するとよい。

コンテンツ配信モジュール３１６は、ダウンロード制限モジュール２３２０をも含む。ダウンロード制限モジュール２３２０は、承認モジュール２３１８の一部、または別のモジュールとして実現され得る。ダウンロード制限モジュール２３２０は任意選択で、アイテムのダウンロードを、例えば実例となる一例では５つのデバイスなどの最大数のデバイスに制限してもよい。

上述のモジュールのリストは、代表となるものであり、コンテンツ配信モジュール３１６によって実行される機能の種類を網羅するものではない。「他のモジュール」２３２２の名称で示されているように、コンテンツ配信モジュール３１６はさらなる動作を実行してもよい。さらに、一部の実施形態では、コンテンツ配信モジュール３１６は、図２３において特定されるモジュールのうちの１つまたは複数を省略してもよい。

図２４は、コンテンツ配信モジュール３１６の動作の実例となる１つの形をフローチャート形式で説明する手順２４００を示す。図２４に示される動作の順序は、様々な形で変更されてもよい。さらに、図２４に示される１つまたは複数のブロックを省略してもよい。さらに、１つまたは複数の動作が同時に実行されてもよい。本例では、図２４は、こうした機能を異なる複数の機能として示し、こうした機能の説明を容易にする。

ブロック２４０２で、コンテンツ配信モジュール３１６は、to‐doリスト処理モジュール３３４から、１つまたは複数のアイテムの要求を受け取る。説明を容易にするために、フローチャートは、ユーザデバイス１０４が単一のアイテムを要求したと仮定する。

ブロック２４０４で、コンテンツ配信モジュール３１６は、例えば承認モジュール２３１８およびダウンロード制限モジュール２３２０に関して上述したように、様々な承認関連の動作を実行する。

ブロック２４０６で、コンテンツ配信モジュール３１６は、特定されたアイテムをサーバ・コンテンツ記憶３０８から読み出す。

ブロック２４０８で、コンテンツ配信モジュール３１６は、任意選択で、アイテム内のプレースホルダーフィールドにユーザの名前を挿入することなどによって、アイテムを個人化することができる。

ブロック２４１０で、コンテンツ配信モジュール３１６は、識別番号をアイテムに割り当て、かつ／または他のメタデータをアイテムに投入することができる。

ブロック２４１２で、コンテンツ配信モジュール３１６は、任意選択で、特定のユーザに対して配信する各アイテムのヘッダを暗号化してもよい。上で説明したように、コンテンツ配信モジュール３１６は、アイテム全体がメモリに格納されることを必要とすることなく、アイテムに暗号化を適用することができる。

ブロック２４１４で、コンテンツ配信モジュール３１６は、用意されたアイテムをユーザデバイス１０４に送付することができる。アイテムは複数のヒントを伴うことができ、ヒントはそれぞれ、ＩＰＳ１０２がアイテムの索引およびアイテムのバックアップの注釈を保持しているかどうかを表す。

ブロック２４１６で、コンテンツ配信モジュール３１６は、サーバ側の索引の要求および／またはバックアップの注釈の要求など、補助情報の要求を受信してもよい。

ブロック２４１８で、コンテンツ配信モジュール３１６は、要求された補助情報をユーザデバイス１０４へ送付してもよい。

ブロック２４１０で、このプロセスは、アイテムに識別子を割り当て、さらに他のメタデータを投入してもよい。

図２５は、ユーザデバイス１０４が、アイテムを受け取った際、処理を行うことができる１つの形を説明する実例となる手順２５００を示す。

ブロック２５０２で、ユーザデバイス１０４は、要求したアイテムを受け取る。このアイテムは、特定のタイプのコンテンツに相当し、電子書籍アイテム、予約購読関連アイテム、ユーザのクエリに対する返答のまとまりなどであればよい。アイテムは、キーとしても知られる１つまたは複数の識別番号によって表され得る。一例では、予約購読関連アイテムの各版または号には、一意の識別番号が指定される。

ブロック２５０４で、ユーザデバイス１０４は、アイテムのタイプおよびキー（例えば識別番号）が、ユーザデバイス１０４によって現在格納されているアイテムと同じであるかどうかを判断する。同じであれば、電子書籍アイテムおよび予約購読関連アイテムの場合、これは、ユーザデバイスが現在、既に所有しているアイテムの完全に重複するコピーを受信しているということを意味する。フィードの場合、これは、ユーザデバイス１０４が、フィードの少なくとも新しいバージョンを受信しているということを意味すると考えられ、これは、フィードの前のバージョンに対し１つまたは複数の部分を追加および／または省略するものであると考えられる。バージョン識別子が、受信されるフィードのバージョンを特定するために用いられ得る。

アイテムが重複していると見なされると、ブロック２５０６で、ユーザデバイス１０４は、新たに受信したアイテムを、同じタイプおよびキーを有する以前に格納されたアイテムと集約し、それによって、このエントリーの単一の記録のみを形成してもよい。

アイテムが重複していると見なされなければ、ブロック２５０８で、ユーザデバイスは、その新たに受信されたアイテムを、異なる新アイテムとして格納することができる。一実施形態では、この時点で、ユーザデバイス１０４はさらに、受信されたヒントを確認して適切な補助情報（注釈バックアップ情報および／または索引情報など）をダウンロードしてもよい。

Ｂ．４．ｂ．増分更新の例示的な方法
図２６〜２９は、増分更新を実行する手順を説明するものである。この手順の一般的な目的は、ユーザデバイスに、要求アイテムの 完全版ではなく、可能であれば差分版を提供することである。要求アイテムの差分版は、デバイスが既に所有するコンテンツのバージョン（たとえば「デバイスバージョン」）と、コンテンツの現行バージョンとの違いを表すものである。差分版を受領すると、デバイスは直ちに、アイテムの差分版を既存の先行（デバイス）バージョンに統合（たとえばパッチ）することにより、要求アイテムの完全版を構築する。この手順では、IPS 102 からユーザデバイス 104に送信する情報量、またそれに伴うコスト（特にワイヤレス通信コスト）を削減するため、要求アイテムの差分版をユーザデバイス 104に提供することを試みる。

増分更新の実行は、IPS 102およびユーザデバイス 104の両方で行われる。二つの増分更新はそれぞれに独立して実行されるが、互いを補完し合うものである。図２７と図２８は、IPS 102から見た増分更新手順を、図２９は、ユーザデバイス 104から見た増分更新の実行を説明する。

まず、図２６は増分更新を実行することが適切であり得る場合の概略を示す。この場合、ユーザはフィードを受け取るように予約している。フィードとは、所定の時間（たとえば１時間ごと）または他の、トリガーイベントに応答してユーザに供給される情報部分の集まりに相当する。例えば、ヘッドラインニュースの内容を提供するフィードの場合について考慮されたい。このようなフィードは、トップ10ニュースの内容のリストを一時間毎に送信する。n 時の収集において所定の参照コンテンツを含むとすると、n+１時の収集は、n時のコンテンツ以降の「バージョン」として表示される。

フィードのひとつのバージョンのには、直前のバージョンのフィードに共通して共用される、一つあるいは複数の部分が含まれ得る。二ユースフィードでは、ある日の午後２時のトップ10ニュースの内容に、午後１時に特定された同じニュースの内容が多く含まれる場合がある。また、全てのニュースが同じものかも知れない。このような状況では、午後２時のニュースフィードの差分版のみをダウンロードすることが望ましい。ニュースフィードの差分版 は、午後２時のニュースフィードの午後１時のニュースフィードとは異なる部分のみを特定する。コンテンツの現行バージョンは、少なくとも２つの点で従前のコンテンツバージョンとは異なる。第一に、現行のコンテンツバージョンは従前のコンテンツバージョンには存在しない一つあるいは複数の部分が追加される。第二に、現行のコンテンツバージョンは、加えて、もしくは代わりに、従前のコンテンツバージョンに存在している一つあるいは複数の部分が削除される場合がある。

図２６は、バージョンＶ₁からバージョンＶ₄までの一連のコンテンツの展開を示す。バージョンＶ₄は、 時間的に最新のコンテンツの現行バージョンを表す。バージョンＶ₁において、コンテンツは基本部分Ａ₁と補足部分Ａ₂がを含む。バージョンＶ₂において、コンテンツは基本部分Ａ₁と補足部分Ａ₂およびＡ₃を含む。バージョンＶ₃において、コンテンツは基本部分Ａ₁と補足部分Ａ₂、Ａ₃およびＡ₄を含む。最後にバージョンＶ₄において、コンテンツは基本部分Ａ₁と補足部分Ａ₃およびＡ₄が含まれるが、バージョンＶ₃に存在した部分Ａ₂は削除される。

この増分更新手順のある実施形態において採用した例示的な方策では、現行バージョン（たとえばＶ₄）と従前の各バージョンとの差異を示す差分ファイルが事前に編集されている。例えば、一番目の差分ファイルは、バージョンＶ₄とバージョンＶ₃の差異を示す。この差分ファイルは、単純に、部分Ａ₂が削除されているという表示で成り立っている。二番目の差分ファイルは、バージョンＶ₄とバージョンＶ₂の差異を示す。この差分ファイルは、部分Ａ₂が削除済みであるという指示と、（バージョンＶ₂に関連して追加されている）部分Ａ₄に含まれる情報とで成り立っている。三番目の差分ファイルは、バージョンＶ₄とＶ₁の差異を示す。この差分ファイルは、部分Ａ₂が削除されているという指示と、（バージョンＶ₁に関連して追加された）部分Ａ₃およびＡ₄に対応する情報とで成り立っている。これらの差分ファイルでは、削除された部分を再現する必要はない。削除済み部分への参照で充分である。

増分更新手順のアプリケーション段階では、コンテンツ配信モジュール316が、ユーザが要求しているアイテムを特定し、ユーザがバージョンＶ₃、バージョンＶ₂、バージョンＶ₁などの従前バージョンを所有しているかどうかを判定する。制限なしに、ある場合では、ユーザデバイス 104は、IPS102に送信する要求に含まれるヘッダ情報に保有するコンテンツのバージョン（がもしあれば）をコンテンツ配信モジュール316に通知する。コンテンツ配信モジュール316は、まず、要求されたコンテンツの現行バージョンとデバイスバージョンの違いを示す差分ファイルへのアクセスを試みる。この差分ファイルを入手することができれば、そして、このファイル全体ではなく、この差分ファイルを送信するほうが効率的であることが判断された場合、コンテンツ配信モジュール316は要求されたアイテム全体ではなく、この差分ファイルを送信する。そうでなければ、コンテンツ配信モジュール316は要求アイテム全体を送信する。前述の通り、ユーザデバイス 104は、まず差分ファイルを要求することによって並行分析を実行する。ユーザデバイス 104が遅滞なく差分ファイルを受領し、無事に処理しなければ、要求アイテムの完全版を要求する。

図２７〜２９は、上記の解説をフローチャートにまとめたものである。まず図２７は、差分ファイルを生成する手順 2700 を示す。この動作は、IPSのコンテンツ配信モジュール 316により、また具体的には図23に示される増分更新モジュール 2304によりバックグラウンド処理として実行される。

ブロック2702では、コンテンツ配信モジュール316は、例えば、フィードの新版、新聞アイテムの新版など、コンテンツの新しいバージョンの受領を記憶する。

ブロック 2704では、コンテンツ配信モジュール316は、現行バージョンＶ_nと、一連の従前バージョンＶ_n-1、Ｖ_n-2、Ｖ_n-3などの差異を示す一連の差分ファイルを生成する。 コンテンツ配信モジュール316は、計算する差分ファイルの数を決定するために様々なルールを適用する。ある場合では、この配信モジュール316 は差分ファイルの数を、所定数に制限する。この目的は、要求アイテムをユーザに最も効率のよい方法でダウンロードすることだということを思い起こされたい。したがって、別の場合に、この配信モジュール316が、差分ファイルが大きく、および/もしくは複雑になりすぎて、一つの差分ファイルよりむしろアイテム全体をダウンロードするほうが効率的であると判断されれば、配信モジュール316は、差分ファイルの生成を停止する。コンテンツ配信モジュール316 は、これらの差分ファイルを差分ファイル記憶2306に保存することができる（図23参照）。 これらの差分ファイルは、対応するフルアイテムとともに保存するか、もしくは参照情報によって、対応するフルアイテムと連動させることができる。

ブロック 2706では、 コンテンツ配信モジュール316 は前回の反復作業の既に関係のなくなった差分ファイルをすべて削除する。例えば、従前の反復作業において、バージョン Vn-1はアイテム最新バージョンであり、 全ての差分ファイルはこのバージョンを基準に編集されていた。ある実施形態では、ユーザは要求アイテムの最新バージョンを要望するであろうという推測に基づき、コンテンツ配信モジュール316はこれらの古くなった差分ファイルを全て削除する。

図２８は、ユーザデバイスが、要求されたコンテンツに応じ、アイテムに具体的な要求をする増分更新手順のアプリケーション段階を示す手順2800を表す。コンテンツ配信モジュール316の増分更新モジュール2394を、この手順2800を実行するために使用することができる。

ブロック 2802では、コンテンツ配信モジュール316 はアイテムに対する要求を受領する。コンテンツ配信モジュール316 は、ユーザデバイスのHTTP要求のヘッダからバージョン情報を読み取るなどの様々な機構を介して、ユーザデバイス 104 が要求されたコンテンツの従前バージョンＶ_kを有するかどうかを判断する。

ブロック 2804では、コンテンツ配信モジュール316 は、現行バージョンＶ_nとデバイスのバージョンＶ_kの違いに相当する差分ファイル へのアクセスを試みる。あるケースでは、コンテンツ配信モジュール316は、この差分ファイルへのアクセスを、3回など、無制限にn回試みることができる。

コンテンツ配信モジュール316が（ブロック 2806で判定されるように）差分ファイルへのアクセスに成功すると、完全版の代わりに差分ファイルを提供する。すなわち、ブロック 2810では、コンテンツ配信モジュール316は、完全なアイテムではなく差分ファイルを送信する。そうでなければ、ブロック 2812で、コンテンツ配信モジュール316はアイテム全体を送信する。

上に記載した実行方法は、バージョン全体ではなく、差分ファイルを送信するほうが効率的であると判断された場合のみ、図２７の差分形成手順2700が差分ファイルを保存するように動作するという推測に基づく。この場合、手順2800で対応する差分ファイルが見つからなかった場合、 手順は、即座に完全版にアクセスし、ダウンロードする。別の場合では、バージョン全体ではなく、差分ファイルを送信するほうが効率がよいかどうかの判断は、任意の判断ブロック 2808が示すように、図２８のダウンロードプロセスの一環として実行される。デルタであるか、完全版であるかの判断が行なわれる時点に関わらず、この判断は、多くの要因に基づいて行われる。

・第一に、アイテム全体に対する差分ファイルの大きさが関係する。差分ファイルがアイテム全体より大きい場合、アイテム全体の代わりに差分ファイルを送信する意味がない。この場合、コンテンツ配信モジュール316 がファイル全体を送信すると判断する。

・第二に、この判断のプロセスには、差分ファイルよりアイテム全体のほうがうまく圧縮（および/または暗号化）できる場合があるという事実が考慮される。従って、相対的なサイズを判断するには、圧縮されたアイテム全体に対する圧縮された差分ファイルのサイズが考慮される。

・第三に、ユーザデバイスに以前から存在しているバージョンに差分ファイルをパッチすること、また、（アイテム全体ではなく）差分ファイル処理に一意的に関連する他のオペレーションの実行が求められているアイテムの数は限られている。アイテム全体ではなく、差分ファイルを送信するほうが効率的かどうかの決定には、これらのタイムラグ条件が考慮される。

図２９は、ユーザデバイス 104により実行される補助的増分更新を示す手順2900を表す。図２１の増分更新モジュール 2110とエラー処理モジュール 2112 を、この手順2900を実行するために使用することができる。

ブロック 2902では、ユーザデバイス 104は、デフォルトの規則として、要求アイテムの差分ファイル バージョン へのアクセスを試みる。アクセスに成功した場合、ユーザデバイス 104は現在有するコンテンツバージョンへの差分ファイルのパッチを試みる。ユーザデバイス 104 は、任意的に既定の回数nだけ、この動作を実行することを試みる。

ブロック 2904では、ユーザデバイス 104は、差分ファイルパッチとしての要求アイテム入手に成功したかどうかを判定する。成功していれば、処理は終了する。成功していなければ、ブロック 2906において、ユーザデバイス 104はアイテム全体を要求し得る。ユーザデバイス106は、差分ファイルかアイテム全体をダウンロードするかの決定に際し、（成功/失敗といった種類の条件よりも、もしくはそれに加えて）他の条件を適用する。

繰り返すが、サーバ側のコンテンツ配信モジュール316は、その増分更新動作を（手順 2900により）実行するユーザデバイス 104と並行して、（手順2800により）増分更新動作を実行する。IPS 102かユーザデバイス 104のどちらかが、要求アイテムの差分ファイルバージョンを読み込む試みを放棄することを決定する。

Ｂ．５．配信管理機能
Ｂ．５．ａ．配信管理機能の概要
上記に説明した事例では、IPS 102は、アイテムを受領し、適切なto-doキュー（購読関連アイテムの場合）にエントリーを追加し、ユーザデバイスがエントリーにアクセスし、対応するアイテムをダウンロードするようTPH 信号を送信する。このセクションでは、この一般的プロセスをより効率的に、また/もしくは、その他の目的を達成するために策定された様々な管理機能について説明する。

図３０は、コンテンツ配信管理機能3000の集合である。第一の機能は、高信頼実現機能3002である。高信頼実現機能3002は、アイテムがユーザデバイスに配信される準備ができる時点より前に、配信関連処理を実行する。このような導入的な処理には、アイテムが配信される準備ができるより前に、デバイスのto-doキューにエントリーを追加することが含まれる。

第二の機能は、TPH スケジューリング機能3004である。TPH スケジューリング機能3004 は、一般的に、ユーザデバイス104の電力消費量を削減するためにTPH信号の送信スケジュール調整を試みる。より具体的には、ユーザがデバイスをを起動し、TPH 信号に対して作動させる（たとえば to-doキューからエントリーの受領やアイテムダウンロードなど）ことは（電力消費量の観点から）割高である。典型的なあるケースでは、そのようなイベントはバッテリ寿命の総容量の約１%を消費する。この問題に取り組むため、TPH スケジューリング機能3004は to-doキューへの全ての報告できる追加に対してTPH信号を送るのではなく、複数の報告できるイベントをまとめ、ひとつのTPH信号を送信することができる。TPH スケジューリング機能3004は、この後により詳細に説明するように、いつ、どのようにTPH信号を送信するかを判断するために、他の条件も考慮する。ある事例では、TPH スケジューリング機能3004は、通知モジュール1808の特徴機能として実現される。

第三の機能は、遅滞通知機能 3006、別名、新聞配達少年機能である。遅滞通知機能3006は、発行者によるIPS 102への予約購読関連アイテムの提供が遅れていることを判定する。これに応答して遅滞通知機能 3006は、アイテムの受領者全員を特定し得る。遅滞通知機能3006は、個別の遅滞通知を作成し、受領者に送信する。

第四の機能は、予約購読開始機能3008である。予約購読開始機能は、まずユーザがデバイスを起動させ、IPS 102にコンタクトするまで購読の開始は差し控える。この対策は、有料、無料購読の両方に適用する。

上に列挙した機能リストは、IPS 102が実行する代表的な機能であって全てではない。「その他の調整機能」3010の名称が示すように、IPS 102には追加の管理機能が含まれ得る。IPS 102はまた、図３０の機能のうち、一つか複数を削除または無効にすることもできる。

以下の項で、それぞれの機能についてより詳細に記載する。
Ｂ．５．ｂ．例示的な高信頼実現機能

図３１は、上記に紹介した高信頼実現機能 3002を実現する手順 3100を示すフローチャートである。

ブロック3102では、高信頼実現機能 3002は高信頼実現処理を開始するトリガーイベントを受け取る。このイベントは、予約購読関連アイテムの受信などに相当得る。

ブロック3104では、高信頼実現機能3002は、アイテムを受け取るよう登録された一つか複数のデバイスへのTPH信号送信に備えて導入処理を実行する。ある場合では、高信頼実現機能 3002は、アイテムを受け取る予定のデバイスに関連付けられたto-doキューに、エントリーを格納する。高信頼実現機能 3002 がto-doキューにエントリーを追加する時点で、アイテムはユーザデバイスに転送される準備ができていないので、コンテンツ受信モジュール 302がアイテムを変換し得る。キューにエントリーが追加されたとき、to-doリスト サーバモジュール 314が TPH信号を時期尚早に送信しないよう、エントリーに、まだ送信の準備ができていないことを示すフラグを付けることができる。この機構は、デバイスがダウンロード処理の一環としてエントリーを要求する際、任意に、効果的に、デバイスから見えるエントリーリストからエントリーを隠すことができる（たとえば 図２２のブロック2204）。

ブロック3106では、高信頼実現機能 3002は、TPH信号を、アイテムが送信できる時点で、受領者のデバイスへ送信することを可能にする。上に記載した予約購読関連アイテムの場合、高信頼実現機能3002は、コンテンツ受信システム302 がいつコンテンツの変換を完了し、コンテンツ記憶308に保存するかを判定する。このとき、高信頼実現機能3002は、TPH信号をユーザデバイスに送信してもよいことを示すように、to-doキュー上のエントリーの状態を変更する。

高信頼実現機能3002は、他種の導入的な動作を実行することができる。一般的に、導入的動作は、その他のオペレーションと並行して実行されるため、また/もしくは IPS 102の部分がアイドリング状態か100％作動していない場合、アイテムを迅速に配信することができる。

Ｂ．５．ｃ．例示的な遅滞通知機能
図３１は、上記に紹介した遅滞通知機能3006を実現する手順3200を示すフローチャートである。手順3200は、特定の予約購読関連アイテムに関連して説明されるが、予約購読関連アイテムまた/もしくは他の種類のアイテムの集合でも、全体として繰り返すことができる。

ブロック3202では、遅滞通知機能3006は、発行者またはその他の発信元によるIPS 102への予約購読関連アイテムの提供が遅れていることを判定する。もしくは、遅滞通知機能3006は、アイテムに関して他の遅れている発信元があることを判定し得る。遅滞通知機能3006は、アイテムが通常は何時受領されるかに関する情報に基づいてこの判定を行う。このような情報は、手作業で入力されるタイミング情報でによって表し得る。遅滞通知機能3006 が、アイテム受領が期待される時点から既定の時間が超過したと判定した場合、アイテムは遅れていると特定する。遅滞通知機能3006は、IPS 102の管理者、発行者自体など、様々なソースから、アイテムの期待される受領に関する情報を収集することができる。代わりに、または追加して、遅滞通知機能3006 は、アイテムの受信、処理にかかる典型的なタイミングを示す、経験的基準を蓄積、編集する。遅滞判定を行うにあたり、遅滞通知機能3006は、ユーザデバイスがコンテンツを受け取る時間帯(time zone)を考慮に入れることができる。例えば、第一の遅滞閾値は米国東海岸のユーザデバイスを操作するユーザに適用され得、第二の遅滞閾値は西海岸で自分のデバイスを操作するユーザに適用され得る。この閾値の違いは、東海岸のほうが、西海岸より早く配信の遅滞に応答し得る事実に関係する。より具体的には、東海岸時間で通常午前４時に新聞が到着する仮定する。配達時間が遅れることに関する心配は、西海岸より東海岸の利用者のほうが深刻である。それは東海岸の利用者の方が、西海岸より早く目覚め、朝食に新聞が読めることを期待しているからである。

ブロック3204では、アイテムが遅滞していると判定されたと仮定したとき、遅滞通知機能3006はこのアイテムを受け取る予定の各ユーザに遅滞通知を送信する。遅滞通知機能3006は、予約購読モジュール310と通信してアイテムを受け取る予定の一連のユーザをに決定することができる。遅滞通知機能はユーザに提供される遅滞通知を、汎用の遅滞通知メッセージにおけるプレースホルダフィールドにユーザの氏名を挿入するなどによって、任意で個人化することができる。この遅滞通知メッセージは、また、遅れている発行物の名前、号の発行日などが特定できるよう個人化することもできる。

ブロック3206では、遅滞通知機能3006は適切なユーザに遅滞通知を発送する。遅滞通知機能3006は、購読者の各々の時間帯を考慮し、遅滞通知を適切な時間に発送する。

ある場合では、遅滞通知機能3006は上に記載したその他のあらゆる種類のアイテム同様、文書として遅滞通知を送信し得る。遅滞通知機能3006は、適切なto-doキューにGETタイプのエントリーを追加することにより、遅滞通知 を配信し得る。別の実施形態では、遅滞通知機能3006はto-doキュー中に特別な命令を送信する。これらの命令は、ユーザデバイスに、命令の受領時、適切なポップアップメッセージなどを表示し、ユーザにアイテムが遅れて配信されることを通知するように促す。遅滞配信モジュール3006は、相次ぐアイテム配信の遅延があれば、それぞれのメッセージに適切な、段階的に程度を上げた丁寧な謝罪や救済策などを含む時差遅滞メッセージを任意で送信することができる。

ブロック3208では、遅滞発行物が配信された際（もし配信された場合）遅滞通知機能3006は、ユーザデバイスから（たとえば対応するto-doキューを介し、ユーザデバイスにDELタイプコマンドを送信することにより）その遅滞通知アイテムを削除することができる。この対策は、IPS 102のユーザが、自分のデバイスに、アイテム自体とアイテムの遅滞通知が双方届いているのを発見し、混乱することを避けるためである。しないようにである。

Ｂ．５．ｄ．例示的なTelephone Home --家庭用電話（TPH） 機能
図３３は、上に紹介したTPHスケジューリング機能3004の実行の手順3300を示すフローチャートである。TPHスケジューリング機能3004の実例となる目標は、ユーザデバイスを起動し、TPH信号を受信し、エントリーとアイテムをダウンロードする必要回数を減らすことであることを思い起こされたい。TPHスケジューリング機能3004は、様々なルールに基づいて複数のTPH信号を一つのTPH信号に統合することによって、また/もしくはTPH信号が発送されるタイミングを調整することによって、この目標を達成する。手順3300は、特定のユーザデバイスに関連付けられた例示的な一つのto-doキューに関して説明されるが、ここに説明するオペレーションは複数のto-doキューと、それに関連するユーザデバイスのために実行され得る。ある実施形態では、TPH スケジューリング機能3004は通知モジュール1808の機能として実現され得る。

ブロック3302では、ユーザのto-doキューには少なくとも一つのエントリーが含まれると仮定する。そうであるなら、ブロック3302では、TPHスケジューリング機能3004は、TPH信号をユーザデバイスに送信することが適切か、またはこのようなメッセージをしばらく後の時点まで保留するべきかを判定する。to-doリスト サーバモジュール314は、このエントリーに非送信状態フラグを付けることで、to-doキューのエントリーに対するTPH信号の送信を差し控える。この状態は、to-doリスト サーバモジュール304がTPH信号を送信しようとするときに変更され得る。

この判定をするにあたり、TPHスケジューリング機能3004は、次の条件の中の一つか、複数の組み合わせを考慮する。多くの考慮事項は、他の条件と重なる側面を含む。

・TPHスケジューリング機能3004は、いつTPH信号を送信するかを決定するために、時間帯情報など、一つか複数の時間に関係する要素を考慮し得る。例えば、TPHスケジューリング機能3004は、ユーザが日中、既にデバイス104を使用している可能性が高い場合、TPH信号を夜間よりも日中の時間に送信しようとする。この場合、デバイスは既にオンになっているため、TPH信号の送信によりデバイスを起動させなくてもよい。一方、TPHスケジューリング機能は、夜間のワイヤレス通信の方が日中より大幅に費用削減できるとすれば、日中よりも夜間にTPH信号を送ろうとする。他の時間関連の条件の適用としては、TPHスケジューリング機能3004は30分ごと、１時間ごとなど、一定のt間隔でTPH信号を送信するよう設定される（t間隔の間に最低でも一つはTPH送信イベントが登録されると仮定する）。

・TPHスケジューリング機能3004は、いつTPHアイテムを送信するかを決定するために、アイテムの種類を重要視し得る。例えば、電子書籍を明示的に購入したユーザは、購入直後にこのアイテムを受信しようとする可能性が高い。ユーザはこのアイテムに対し明示要求をし、また、この明示動作が最近のイベントだからである。一方、定期刊行物やブログの受信者は、それほどすぐに発行物を受信しなくても気にしないかも知れない。ユーザがこの発行物に強い興味を持ち続けるという有力な証拠がより少ないからである。したがって、TPHスケジューリング機能302は、電子書籍 に対するTPHアイテムをユーザの購入直後に送信し得る。しかしTPH スケジューリング機能3004は、予約購読関連アイテムの自動受領の際、TPH信号の送信を遅らせる場合がある。より一般的に説明すると、TPHスケジューリング機能3004は、アイテムの種類に異なる優先順位を割り当てる場合がある。TPHスケジューリング機能3004は、TPH信号をいかに早く発送するかを決定する要素のひとつとして、to-doキューのアイテムの優先度を考慮する。別の事例では、IPS 102のアップグレード 機能が、デバイスのto-doキューに、デバイスにインストラクション関連の更新をダウンロードするよう指示するエントリーを追加し得る。このエントリーは、TPH信号を即座に送信することを要求する、極めて優先度の高いアイテムとして特定され得る。

・TPHスケジューリング機能3004はまた、TPH信号をいつ送信するか決定するにあたり、to-doキューにエントリーが保存されている時間の長さも考慮し得る。TPHスケジューリング機能3004は、TPH信号の発送をあまり長く遅らせることは望まないであろう。

・TPHスケジューリング機能3004は、TPH信号をダウンロードするかどうか決定するにあたり、ユーザが行った従前の行動も考慮し得る。より具体的には、ある事例で、TPHスケジューリング機能3304は、多くのユーザの総合された行動を、その行動が特定のユーザにも同様に適用されるという前提のもとに、考慮し得る。別の事例では、TPHスケジューリング機能は、代わりに、もしくは加えて、特定のユーザの独特の行動を考慮し得る。一例を挙げると、特定のユーザは、例えば、一日のある時間にユーザデバイスを使用し、他の時間には使用しないなど、独特の行動パターンを持つ場合がある。TPHスケジューリング機能3004は、ユーザが一日のうちにとる、行動の種類のパターンを特定することができる。これらの考慮事項に基づき、TPHスケジューリング機能3004はユーザが既にデバイスを使用していると思われる時間で、デバイスが起動状態にあるときにTPH信号を送信する。別の事例では、ユーザは概して一日の特定の時間に特定の種類のコンテンツを受信しようとすると考えられる。例えば、ユーザは出勤前に新聞を読みたいと思うかも知れない。この場合、TPHスケジューリング機能3004は午前５時までにTHPを送信しようとするが、それ以外では、TPH スケジューリング機能3004は、ユーザが睡眠中と思われる夜中にTPH信号を送信する必要はない。

・TPHスケジューリング機能3004は、ユーザのデバイス104の現在の使用に関する情報も収集し得る。例えば、TPHスケジューリング機能3004はユーザがユーザデバイス104を（AC電源出力などの）常設の電源に差し込んでいるかどうかなどを判定する。TPHスケジューリング機能3004は、デバイス104を有限でない電源に差し込んでいると判断した場合のほうが、TPH信号をユーザデバイスに送信する傾向がある。TPHスケジューリング機能3004はまた、ユーザデバイス104のバッテリ残量を示す情報を受け取ることができる。TPHスケジューリング機能3004は、デバイスのバッテリ残量が少ないときは、TPH信号を送信しない傾向が高くなるであろう。

・TPH スケジューリング機能3004は、to-doキューに保存されているエントリーの量も考慮し得る。TPHスケジューリング機能3004は、ユーザのto-doキューが未報告のエントリーで溢れているときの方が、よりTPH信号を送信しやすい。TPHスケジューリング機能3004はまた、TPH送信動作の最近の割合も考慮し得る。

・TPHスケジューリング機能3004はまた、設定タイプのページなどを介して入力される、ユーザの明らかにした嗜好を考慮することができる。

・TPHスケジューリング機能3004はまた、予約購読関連アイテムに関し、ユーザがアイテムを購入したばかりかどうかも識別することができる。アイテムを購入したばかりのユーザは、この発行物を長期間、定期的に受け取っているユーザよりも、このアイテムの発行物をより欲している場合がある。

・TPH スケジューリング機能3004はまた、TPH信号を送信するタイミングを決定するにあたり、ダウンロードするアイテムのサイズも考慮し得る。例えば、TPHスケジューリング機能3004は、無線のダウンロード料金を抑えるために、特に大きなアイテムには、夜間にTPH信号を送信しようとするかも知れない。

・TPHスケジューリング機能3004がTPHスケジューリングを決定するにあたり、その他の条件も関係し得る。関連事項として、ユーザデバイス104は、様々なイベント、例えば、デバイスが何らかの理由で起動するなど、への応答として、（TPH信号がプロンプトしなくても）単独でto-do サーバモジュール314にコンタクトするよう設定されていることに注意されたい。ユーザデバイスは、その時点でペンディングになっているキュー上のいかなるエントリーをもダウンロードし得る。

ブロック3304では、TPHスケジューリング機能3004は、TPH信号を送信するか否かの最終決定をするにあたり、上記に特定された要素のうちの一つか複数を重視する。環境の違いにより、条件の優先順位に影響があり、それぞれの条件を重視する度合いも異なる。ある場合では、各ユーザもまた、TPH信号の送信に適用する重要性を定義し、それによって、上記に特定された様々な要素の重要度を調整することができる。

ブロック3306では、TPHスケジューリング機能3004は、TPH信号を発送し、ユーザデバイスがエントリーを読み込み、そのエントリーと関連する相当アイテムをダウンロードするように促す。

Ｂ．５．ｅ．例示的な予約購読開始機能
図３４は、上に紹介した予約購読開始機能3008を実現するための手順3400を示すフローチャートである。

ブロック3402では、予約購読開始機能3008は、ユーザが新規の予約購読を購入したことを判定する。

ブロック3404では、予約購読開始機能3008はユーザが実際に予約購読関連アイテムのダウンロードを開始するまで、または、その他の消費を引き起こす動作に応答するまで、予約購読発行物への請求（課金）を延期する。この対応は、ある意味でユーザへの厚意である。

Ｂ．６．例示的なホーム提示モジュール
図４で紹介したホーム提示モジュール408は、ユーザがユーザデバイス104とのやり取りを開始できるホームページを提供する。ホーム提示モジュール408は、そのホームページ上に様々な情報を示すことができる。図３５は、ホームページ3502の一つの実例的な実施形態を示す。

図３５のホームページ3502は、オーディオブック、個人アイテム、予約購読関連アイテムなど、ユーザが読み取りデバイスを使用して消費できる様々なアイテムのリストを示す。ホームページ3502上のそれぞれのエントリーは、アイテムの名称、電子書籍タイプのアイテムの作者など、アイテムに関する重要な情報を含む。各エントリーは、アイテムが閲覧できるように開き、対応するアイテムを選択するガイドとなるセレクタ（ページ3502の右端）を含む。特殊分類タイプセレクタ3504は、そのアイテムが予約購読に相当することを表示している。このアイテム上でクリックすると、ユーザは現在入手が可能な予約購読内の号のリストを閲覧することができる。さらに、ホームページ 上の各エントリーにはプログレスインディケータ3506などのプログレスインディケータが含まれる。プログレスインディケータ3506のドット数で、インディケータの全長に対し、ユーザはアイテムのどこまで読み進めたかを特定することができる。

ホームページ3502はまた、"Show and Sort"選択アイテムを含む。このエントリー上でクリックすると、ユーザにShow and Sortメニュー（未表示）が示され得る。このメニューにより、ユーザはホームページ3502に表示するアイテムを選択するのに使用する（一つまたは複数の）選別基準を選択することができる。ユーザはまた、ホームページ3502上に表示されたアイテムの順番を調節するのに使用できる（一つまたは複数の）並べ替え基準を選択することができる。

ホームページ3502は、メニューセレクタ3502も含む。メニューセレクタ3502を選択すると、ユーザデバイス104は図36に示されるメニュー3602を表示する。メニュー3602により、ユーザは、ユーザデバイスが実行する様々な機能を行き来し、特定のタスクを実行することができる。メニュー3602から選択できる一つの機能には、設定オプション3604が挙げられる。

図３６に示される設定オプション3604を起動させると、ユーザデバイス104は、図３７に示される設定ページ3702にユーザを移動させる。この設定ページにより、ユーザは（アカウント名、デバイス名など）デバイスに関連する様々な管理設定およびデバイスの操作方法を規定する様々な設定を変更することができる。設定ページ3702は、追加アイテムを保存できる容量を示す。

Ｂ．７．例示的な店舗モジュール
Ｂ．７．ａ．店舗モジュール概要
図３８は、図３において紹介した店舗モジュール318を示す。概要として、店舗モジュール318によりユーザはアイテムを検索し、選択したアイテムを購入（もしくは入手）することなどができる。ユーザはユーザデバイス104が提供する店舗対話モジュール344を介し、店舗モジュール318とやりとりする。ユーザはまた、無線ではない通信機構（たとえば電話またはケーブルモデム、DSL機構など）を介し店舗モジュール318にパソコンからアクセスするなど、一つか複数の代わりの機構を介して店舗モジュール318とやりとりすることもできる。

店舗モジュール318には、アカウント管理と設定モジュール3802が含まれる。このモジュール3802により、ユーザはユーザアカウントを設定し、その他の管理機能を実行することができる。

店舗モジュール318はまた、ユーザ情報3804を含むか、またはユーザ情報3804にアクセスすることができる。ユーザ情報3804は、ユーザに関する人口統計情報を提供する。ユーザ情報3804はまた、ユーザが行った従前の購入およびその他の種類の選択に関する情報も提供することができる。

店舗モジュール318は、アイテムカタログ320を含み得る。アイテムカタログ320には、店舗モジュール318を使用して選択することのできる様々なアイテムの説明が含まれ得る。アイテムカタログ320内のアイテムの説明は、アイテム詳細ページの形をとることができる。

店舗モジュール318には、アイテムレビューおよび入手（IRA）機能3806が含まれ得る。このIRA機能3806には、その中に、カタログ検索および提示モジュール3808が含まれ得る。このモジュール3808により、ユーザは、検索ワードを入力し、カテゴリを閲覧するなどすることにより、アイテムカタログ320内のアイテムを検討することができる。IRA機能3806にはまた、アイテム推奨モジュール3810も含まれる。IRA機能3806は、一つか複数の推奨アイテムをユーザに提示する。それは、例えば、（例えばユーザ情報保存3804に反映された）ユーザの過去の興味または一般的に人気のあるアイテムなどに基づく。

IRA機能3806にはまた、アイテム購入モジュール3810が含まれ得る。アイテム購入モジュール3812により、ユーザは、アイテムをショッピングカートに入れ、購入（または入手）することができる。このアイテム購入モジュール3810は、その中に、購入撤回モジュール3814を含み得る。購入撤回モジュールによりユーザは、以下により詳細に記載する方法でアイテム購入を撤回することができる。アイテム購入モジュール3810はまた、バーチャルアカウントモジュール3816をも含むことができる。下記（セクションD）にさらに詳細に記載するが、バーチャルアカウントモジュール3816によりユーザは、ユーザデバイスを購入（もしくは受領するよう手配）済みだが、まだ特定のユーザデバイスを割り当てられていない時点で、アイテムを購入することができる。

IRA機能3806は、「その他保存モジュール」3818の名称で示されるように、追加モジュールを含み得る。店舗モジュール318の他の実施形態では、また、図３８に示される一つか複数のモジュールが省略してもよい。

店舗モジュール318には、デバイスインターフェースモジュール3820が含まれ得る。デバイスインターフェースモジュール3820は一般的にサーバサイド店舗318に、デバイス側店舗対話モジュール344とやりとりをさせる機能を含む。デバイスインターフェースモジュールは、マークアップ提示モジュール3822を含む。マークアップ提示モジュール3822は、ユーザデバイスに一連のページ（例えば通常のページ3824）を提供する。このページは、マークアップ言語、またはいかなる他のフォーマットでも作成され得る。デバイスプレゼンテーションインターフェースモジュール3820はまた、デバイス応答処理モジュール3826も含み得る。デバイス応答処理モジュール3826は、マークアップ提示モジュール3822が提供したページとやりとりをしているユーザからの応答を受け取る。例えば、このユーザは、マークアップ提示モジュール3822が提供したページのリンクを選択し得る。このユーザの選択は、HTTPプロトコルまたは他のプロトコルあるいはプロトコルの組み合わせを使用して、デバイス応答処理モジュール3826に返送される。

図３９〜４１は、マークアップ提示モジュール3822が作成するページの代表的な集合である。図３９は、ユーザが最初に店舗モジュール318にアクセスする際、マークアップ提示モジュール3820がユーザに表示することができる導入ページ3902を示す。導入ページ3902は、ユーザが様々な閲覧カテゴリを見てまわり、推奨アイテムを閲覧し、検索を入力したりできるポータルサイトを提供する。図４０は、閲覧ページ4002を示す。閲覧ページ4002により、ユーザは様々な主題カテゴリを使用して、アイテムを閲覧することができる。図４１は、ユーザがアイテム購入モジュール3812を介して購入することのできる一つの電子書籍アイテムに関する情報を提供する、アイテム詳細提示4102を示している。アイテム詳細情報が１枚のページに収まらない場合、マークアップ提示モジュール3820は、この情報を図４０で示されるように、一連のページに渡って表示してもよい。

Ｂ．７．ｂ．例示的な購入撤回への対処法
図４２は、図３８の購入撤回モジュール3814を使用して購入撤回を行う実例的な手順4200を示すフローチャートである。

ブロック4202では、アイテム購入モジュール3812はユーザのアイテム購入を受け取る。ユーザは、フルフィルメント操作を開始する選択をすることにより、購入を行ってもよい。

ブロック4204では、IPS102が上に記載した方法で、購入されたアイテムを処理し、場合によってはユーザのデバイスに配信する。

ブロック4206では、購入撤回モジュール3814はユーザがブロック4302で行った購入を撤回できるオプションをユーザに提示する。ある場合には、購入撤回モジュール3814は、アイテム購入後にユーザに提供される「サンキュー」ページなどでこのオプションを表示する。前のブロック4204にて示したとおり、この段階でアイテム購入モジュール3812は、ユーザのアイテム購入を実行している途中である。

ブロック4208では、ユーザが実際に購入撤回オプションを起動させると想定する。

ブロック4210では、購入撤回モジュール3814は、可能であれば、ユーザのアイテム購入を撤回する。

Ｂ．８．例示的なコンテンツ管理モジュールとメディアライブラリモジュール
デバイス側のコンテンツ管理モジュール342は、ユーザがユーザデバイス104で消費できるアイテムの閲覧および管理ができるツールを提供する。図４４は、コンテンツマネージャ342に関するさらなる詳細を示す。図４４はまた、コンテンツマネージャ342が、サーバサイドの個人メディアライブラリモジュール324および購読モジュール310など、他のモジュールとやりとりをする方法を示す。

コンテンツマネージャモジュール342には、提示モジュール4302が含まれる。提示モジュール4302はユーザがユーザデバイス104を使って消費することのできる様々なアイテムを表示する。アイテムは、様々なソースに由来し得る。第一のソースは、ユーザデバイスの内部デバイスメモリ336に相当する。第二のソースは、フラッシュカードなどのように、ユーザデバイス104に接続されるポータブルメモリモジュール4304に相当する。第三のソースは、ユーザのサーバサイド個人メディアライブラリモジュール324で識別されるアイテムに相当する。より具体的には、コンテンツマネージャモジュール342は、メディアライブラリモジュール324から、電子書籍アイテムなどのオンデマンド（「アラカルト」）選択、特別に選択された新聞や雑誌の号などに関する情報を受け取ることができる。第四のソースは、予約購読モジュール310で識別されるアイテムに相当する。より具体的には、コンテンツマネージャモジュール342はユーザの予約購読およびそれに関する最新号に関する情報を提供することができる。予約購読に関連して、ある実例となる場合では、コンテンツマネージャモジュール342は、それぞれのユーザ購読の直近n日間を保存し得る。

ある実例となる場合では、コンテンツマネージャモジュール342は、個人メディアライブラリモジュール324また/もしくは予約購読モジュール310に保存されるアイテムを識別するデバイス側メタデータにアクセスすることができる。これによりユーザは、これらのサーバサイドモジュールにそのコンテンツを判定させるためにオンデマンドクエリをすることを回避できる。

別の機能では、提示モジュール4302には選別モジュール4306が含まれる。選別モジュール4306により、ユーザは、提示モジュール4302がどの種類のアイテムを表示するかを決定するために使用する（一つ又は複数の）基準を選択することができる。例えば、ユーザはデバイス側内部メモリ336に保存されたアイテムのみを表示するなどの制限ができる。

コンテンツマネージャモジュール342には、更新処理モジュール4308も含まれる。更新処理モジュール4308の目的は、個人メディアライブラリモジュール324のコンテンツを記載するデバイス側メタデータを更新することである。更新モジュール4308は、ユーザデバイスとIPS102が何かの理由でやりとりする際、様々な時点で呼び出され得る。例えば、更新モジュール4308はTPH信号の受信により引き起こされる動作の集合の一環として呼び出される場合がある。

個人メディアライブラリモジュール324に関しては、このモジュール324はユーザがアラカルト方式で（個別に選択して）以前購入したアイテムを保存する。より具体的には、個人メディアアイテムライブラリ324は、ユーザが購入した店舗コンテンツ記憶308のアイテムを参照するポインタ4308を保存することができる。上に記載した方法では、ユーザは以前購入したアイテムをコンテンツ配信モジュール316を介して受け取る。コンテンツ配信モジュール316は、次いで、要求されたアイテムを受け取る権限をユーザが有することを確認するため個人メディアライブラリモジュール324と通信することができる。ユーザはユーザのデバイスローカル記憶からうっかりコンテンツが削除されてしまったなどの理由で、アイテムを再度ダウンロードすることもできる。

ユーザは、これと似た方法で予約購読関連アイテムをダウンロードすることができる。すなわち、コンテンツ配信モジュール316は、予約購読モジュール324にアクセスし、ユーザが号をダウンロードする権限を有するかどうかを判定する。予約購読モジュール324が提供する許可情報は、個々の号ではなく、予約購読のレベルで運用される。

図４４は、コンテンツマネージャページ4402の提示モジュール4302により提供されたコンテンツマネージャページ4402を示す。ページ4402には、ユーザデバイス104を使用してユーザが消費することができる様々なアイテムが表示されている。ページ4402にはまた、アイテムの発信源を表示するタグを提供する。アイテムが個人メディアライブラリモジュール324を通じて入手できることを示す「Merchant」（店舗）、アイテムがデバイス側メモリ336に保存されていることを示す「デバイス」、また、アイテムが取り外し可能なメモリモジュールに保存されていることを示す「SDカード」などである。図４３には示されていないが、コンテンツマネージャページ4402は、アイテムがユーザデバイス104にダウンロードされている途中なのか、また/もしくはアイテムはその他の処理を実行中なのかを表示するインディケータを提供し得る。

図４５は、選別メニュー4502を含む別のコンテンツマネージャページを示す。選別メニュー4502は、どの種類のアイテムを（選択されたソースに対応して等）どの順番に表示するかを管理するために選別モジュール4304によって使用される。

図４６は、別のメニュー4602を表示する別のコンテンツマネージャページを示している。その他の機能として、このメニュー4602により、ユーザはアイテムを一つのソースから別のソースへと移動、削除すること等ができる。

図４７は、ユーザデバイス104とIPS102がどのように情報を共有するかを説明する手順4700を示す。

ブロック4702では、システム300上の一つか複数のモジュールがトリガーイベントを受け取る。このトリガーイベントは、ユーザデバイス104とIPS102の間で情報を共有するなどの、様々なハウスキーピング動作をするべき時であることを知らせる。代表的な一つのトリガーイベントは、情報同期オペレーション等の多数の動作をを開始させる、IPS102からユーザデバイス104へのTPH信号の送信に相当し得る。他のトリガーイベントとして、ユーザデバイス104の起動、またはユーザデバイス104の他の状態の変更などがある。

ブロック4702では、システム300上の一つか複数の適切なモジュールが、同期を目的として一つか複数の他のモジュールが有数る情報を共有する。一例を挙げると、ブロック4702では、ユーザデバイス104が、ユーザが特定のあるアイテムをIPS102に作成した、という注釈を送信することが、バックアップ注釈保存1116への保存のために必要なり得る。さらに、ブロック4702では、個人メディアライブラリモジュール324が参照するアイテムが反映されるメタデータを、個人メディアライブラリモジュール324がコンテンツマネージャモジュール342に送信することが必要となり得る。さらに、その他の情報共有動作が様々なトリガーイベントにより実行され得る。

上記の定期的な同期オペレーションに加え、ユーザによるハードリセットコマンドなどが原因でユーザデバイス104に保存されたコンテンツにアクセスできなくなった場合などに、IPS102はユーザデバイス104のコンテンツを復元するためにユーザデバイス104とやりとりすることができる。

Ｂ．９．例示的なリーダーモジュール、注釈機能、およびオーディオ再生モジュール
図３で紹介したリーダーモジュール340は、ユーザが電子書籍を読めるようにするインターフェースを提供することを思い起こされたい。図４８は、リーダーモジュール340が作成したテキストコンテンツの一つのページ4802、ハーマン・メルヴィル著「白鯨」を表示している。ユーザは適切なメニュー（非表示）を使って文字サイズを変更することができる。ユーザは、どこまで読み進んだかを、進行表示4804で見ることができる。表示の全長に対しする進行表示のドットの数は、ユーザがどこまで本を読み進んだかを示す。

読取可能なのコンテンツのいかなるページにも、起動させることができる一つか複数の埋め込みリンクを含むことができる。例えば、ページ4802のボタン4806に注目されたい。リーダーモジュール340により表示されている読み物は、本のある章など、より完成されたアイテムのサンプルである。ページ4802には、アイテムの完全版を選択するようにユーザを誘導するボタン4806が含まれる。別の実施形態では、ボタン4806は、ユーザが（本の別の章、雑誌の別号など）アイテムの別の部分を購入するように誘導する。また別の場合には、一つか複数の合致条件をもとに現在表示されているコンテンツに関連するアイテムを、リンクが識別する。例えば、図３８のアイテム推奨モジュール3810は、様々な合致条件をもとに関連アイテムを特定する。ボタン4806をクリックすると、店舗モジュール318が、識別されたアイテムを購入（もしくは入手）し、その配信を開始する。例えば、図解のケースでは、ページ4802でユーザが読んでいるコンテンツの完全版である。

図４９は、ユーザがページ上のリンクを起動させたとき、アイテム識別情報を動的に提供する実例的手順4900を表すフローチャートである。

ブロック4902では、ユーザデバイス104はボタン4806を含むページ4802のような、リンクがある表示を提供する。ユーザデバイス104は、テンプレートを使用してそのページを表示することができる。そのテンプレートには、リンクを示す手段が含まれるが、アイテムを一意的にに特定するどんなコードにも、そのリンクを結び付けない。つまり、このページには、実際のコードの代わりに、プレースホルダーフィールドが含まれる。

より具体的には、ある種のアイテムについて、コンテンツ受信システム302は、アイテムの識別情報を正式に統合することなく、そのアイテムをコンテンツ記憶308に保存することを思い起こされたい。コンテンツ配信モジュール316はそのようなアイテムをユーザに配信するとき、（メタデータインジェクションモジュール2316を使用して）識別情報をアイテムのヘッダに挿入する。しかしこの段階では、アイテムの内部のリンクには識別情報は組み込まれない。

ブロック4904では、ユーザデバイス104はユーザは選択したリンクを受け取る。

ブロック4906では、ユーザデバイス104または他のエンティティは、そのリンクに関係のある独自の識別情報（例えば独自の数字）を含むように、動的にそのリンク情報を組み込むことができる。上記のように、ページ4802がアイテムのサンプルを表示し、ボタン4806によりユーザがアイテムの完全版にアクセスすることができる具体的な場合を考察する。ユーザがボタン4806をクリックすると、デバイス104はボタン4806に関係のあるリンクに、アイテムの完全版に関連する識別情報を組み込む。その識別情報は、コンテンツ配信モジュール316により、サンプルアイテムと共にユーザデバイスに提供される。例えば、その識別情報は、サンプルアイテムのヘッダ内で送信さ得る。組み込まれたリンクは、アイテムの完全版購入のため、店舗モジュール318にアクセスするなど、あるアクションを実行するよう呼び出される。これにより、このアイテムのユーザへの配信が開始される。

図５０は、ユーザが電子書籍を読んでいる途中に呼び出すことができる、注釈メニュー5002を示す。ユーザはメニュー5002を呼び出し、文章の一説を反転表示させたり、文章に関連してメモ書きを足すことなどができる。ユーザは、カーソル移動機構506また/もしくは他の入力機構を使用してこれらの操作を行なうことができる。例えば、ユーザは、表示部分504の相当する終始位置にカーソルを移動させ（例えばカーソルホイールを回転させ）、（例えばカーソルホイールを押下して）位置を選択することにより、文章の一部を区切って反転表示させることができる。

引き続き注釈に関して説明すると、図４８に示されるように、ユーザはページ4802の隅にあるマークアイコン4806の横をクリックすることにより、ブックマークを入力することができる。さらに、図５１は電子書籍上でユーザが印を付けた箇所を特定する方法を示す。すなわち、図５１は、進捗表示画面を示す。黒い小さな三角形は、ユーザが文章上に作成したブックマークの位置を示す。

図５２は、（図４で紹介した）オーディオ再生モジュール410に関連する様々な機能とオーディオ再生モジュール410が稼動し得る環境を示す。ユーザデバイス104が、オーディオアイテムを受け取るために使用できる機構は少なくとも2つある。第一の機構では、ユーザはパーソナルコンピュータ5202またはその他の種類のデータ処理デバイスを使用して、オーディオアイテムのソース5204からオーディオアイテムをダウンロードすることができる。第一のアクセス機構では、パーソナルコンピュータ5202は、従来の電話、ケーブルモデム、DSL接続、Tl接続など、無線でない接続を介し、オーディオソース5204にアクセスすることができる。受領すると、ユーザは、USB接続、ポータブルメモリモジュール、もしくはその他の転送機構を使用してオーディオアイテムをユーザデバイス104に転送することができる。第二の機構では、図２に示されるのと同様の通信環境106を使ってオーディオソース5204からオーディオアイテムを受信し、そのオーディオアイテムをユーザデバイス104に転送することができる。つまり、通信環境106は電子書籍アイテムなどと同じ方法でオーディオアイテムを転送する。ここでは、オーディオソース5204は、図３に示されるコンテンツソースの一つとして機能する。既に説明した通り、通信環境106は、少なくとも一部は、無線通信に依存する。

オーディオソース5204は、有料または無料のオーディオアイテムの民間供給業者またはオーディオアイテムを供給する他種の団体に相当する（例えば図書館、政府機関などを含む）。ここにおいて、オーディオソース5204はパーソナルコンピュータ5202またはその他のWANでデバイスにアクセス可能な他のリソース（例えばインターネットでアクセス可能なサイトなど）にアクセスすることができる。オーディオソース5204はまた、他のユーザへの配布のためにオーディオアイテムを供給するユーザまたはユーザの集団に相当する。

オーディオ再生モジュール410は、オーディオアイテムを受け取ると、それをバックグラウンド音楽ファイル5206また/もしくはオーディオブックファイル5208に保存することができる。オーディオ再生モジュール410を、バックグラウンド音楽ファイル5206内のオーディオアイテムをバックグラウンドミュージックとして再生するよう設定することができる。例えば、オーディオ再生モジュール410は、ユーザが新聞を読んでいるときやウェブ検索中などに、バックグラウンド音楽ファイル5206内のオーディオアイテムを再生することができる。ある場合では、オーディオ再生モジュール410はバックグラウンド音楽ファイル5206内のオーディオアイテムを順不同に再生する。このオーディオ再生モジュール410により、ユーザはバックグラウンド音楽ファイル5206にアクセスし、再生中のバックグラウンドミュージックを中断し、順不同の曲目リスト中の次のアイテムへ飛ばすなどの制御をすることができる。

オーディオ再生モジュール410は、ユーザがテキストコンテンツと同じ方法でオーディオブックファイル5208に保存されたオーディオアイテムとやりとりし、消費することができるよう設定され得る。例えば、ページ5210は、ユーザがオーディオブックのオーディオプレイバックを制御できる、一つのユーザインターフェースページが表示されている。このオーディオ再生モジュール410により、ユーザは様々な早送り、戻しコマンドを使用し、オーディオアイテムのコンテンツ上を移動することができる。さらに、オーディオ再生モジュール410は、ユーザが途中で止めたオーディオアイテムの箇所を保存することができ、後にアイテムに戻った際、オーディオ再生モジュール410が、止めた場所から再生する。ユーザデバイス410の他のモジュールは、電子書籍アイテムと同様の方法でオーディオアイテムを管理することができる。例えば、コンテンツマネージャモジュール342は、利用可能なアイテム（例えば図４４"SunAlsoRises"エントリー参照）のリスト上のオーディオアイテムに関するメタデータを表示することができる。

Ｂ．１０．例示的なウェブ閲覧機能
図５３は、図２のシステム200を簡易化した描写である。この簡易描写の中で、デバイス側閲覧モジュール402は、インターネットなどのネットワーク212を介し、アイテム提供システム（IPS）102とやりとりをする。このIPS102には、閲覧プロキシモジュール326が含まれる。閲覧モジュール402は、ネットワークでアクセス可能なリソース226のひとつにアクセスしようとするとき、まず閲覧プロキシモジュール326に方向づけられる。この、例示的かつ代表的な方法では、デバイス閲覧モジュールはネットワークでアクセス可能なリソースに直接アクセスすることを妨げられる（図５３の×マークに示される）。注意すべきは、閲覧モジュール402がユーザデバイスがIPS102と通信を図る唯一の方法であるということである。閲覧プロキシモジュール326の使用が、アイテム配信システム312とto-doリスト処理モジュール間の転送プロトコル、店舗モジュール318とデバイス側店舗対話モジュール344間の相互作用などの他の通信経路に影響することはない。

IPS102は、ユーザによる「外部の」ネットワークでアクセス可能なリソースへのアクセスを制御するために、異なるビジネス規則を確立することができる。ある場合では、IPSは、第一のクラスである、料金を請求しない（または比較的低額な料金のみ請求する）無料リソース5302と、第二のクラスである、料金を請求する（または比較的高額な料金を請求する）有料リソースとを区別する。

図５４は、閲覧プロキシモジュール326を使用してネットワークでアクセス可能なリソースへのアクセスを制御する例示的方法、手順5400を示す。

ブロック5402では、閲覧プロキシモジュール326は、ウェブサイトなどの、ネットワークでアクセス可能なリソースに接続するユーザ要求を受け取る。

ブロック5404では、閲覧プロキシモジュール326は、ユーザが接続しようとしているサイトが、IPS102そのものが提供するサービスに相当するかどうかを判定する。相当する場合、ブロック5406において、閲覧プロキシモジュール32は、要求されたリソースへのユーザアクセスを許可する。

ブロック5404で答えが否である場合（つまり、ユーザがIPS102そのものへのアクセスを確立しようとしているのではない場合）流れは、ブロック5408へ進み、そこで閲覧プロキシモジュール326は、ユーザが一つか複数の無料（もしくは低額）指定リソース5302にアクセスしようとしているかどうかを判定する。そうである場合、ブロック5406において、閲覧プロキシモジュール326は（ブロック5406において）要求されたリソースへのユーザアクセスを許可する。

ブロック5408が否の返答を得た場合（つまり、ユーザはIPS102または無料リソース5302にアクセスしようと試みているのではないとき）、流れは、ブロック5410に進み、そこで閲覧プロキシモジュール326は、ユーザが一つか複数の指定有料リソース5304へのアクセスを試みているかどうかを判定する。そうである場合、ブロック5412で、閲覧プロキシモジュール326は、ユーザが請求料金を支払い済みか、支払うことに同意しているかどうかを判定する。ブロック5412への返答が肯定的である場合、閲覧プロキシモジュール326は（ブロック5414において）適切な料金を課し、（ブロック5406において）要求されたリソースへのユーザアクセスを許可する。ある場合では、システム300は、ユーザがアクセスしようとしているそれぞれのアイテムに料金を支払うことができるように（例えばアクセスごとの課金）設定され得る。別の場合では、システム300は、ユーザが既定の時間（一日、一週間など）内であれば何度でもアクセスできるよう、アイテムに支払いができるよう設定され得る。いずれの場合も、ユーザがアクセスを試みたとき、ユーザへのクエリ（問い合わせ）なしに、ユーザは自動的にアクセス関連の料金を承認するオプションを与えられ得る。

上記に説明した条件のいずれも満たされない場合、ブロック5416において、閲覧プロキシモジュール326は、要求されたアイテムへのユーザアクセスを拒否する。

図５５は、デバイス閲覧モジュール402により提供されるブックマークページ5502（お気に入りページとしても知られる）を示す。このページ5502には、リンクのリストが含まれる。ユーザは、好きなリンクをクリックすると、相当するネットワークでアクセス可能なリソースに接続することができる。.

図５６は、デバイス閲覧モジュール402が、ユーザデバイス104を使用して、URLなどのネットワークアドレスを入力するために使用することができるメニュー5602を示す。

Ｃ．例示的な管理関連機能
Ｃ．１．機能概要
このセクションでは、セクションAとセクションBで説明したシステムを使用して実行される様々な管理またはバックエンドタスクに関する情報を提供する。ある管理機能は、システムの様々な側面の動作性能を監視することに。関する。別の管理機能は、システムのパフォーマンステストに関する。別の管理機能は、システム上に存在し得る問題または他の課題の診断に関する。別の管理機能は、ユーザデバイス104が使用する命令を含むコンテンツ（例えばソフトウェア）のアップグレードに関する。上に記載した機能は互いに重なり合う場合がある。例えば、テスト機能と診断機能は動作性能監視機能に依存し得る。アップグレード関連の機能は、命令のアップグレードが適切かどうかを判定するにあたり、テスト機能と診断機能に依存し得る。

図５７は、図２で紹介したシステム200の簡易化した描写である。システム200は、上に記載した様々な管理機能を説明する手段として使用される。しかし、ここに記載する管理機能は、他の種類のシステムを使用して実現され得る。

システム200により、アイテム提供システム（IPS）202は通信環境を介してユーザデバイス104とやりとりをすることができる。この通信環境には、ワイヤレスプロバイダーシステム202と通信支援システム208が含まれる。通信支援システム208は、ワイドエリアネットワーク（WAN）、特にインターネットなどのネットワーク212を介してIPS102とやりとりをする。

システム200は、以下で説明するように、上に記載した様々な管理機能を様々なレベルで実行する。

Ｃ．２．例示的な動作性能管理、テスト、診断機能
図５７は、システム200の様々な部分が、それぞれの視点からシステム200の動作性能を監視することを説明する。例えば、ユーザデバイスには、ユーザデバイス104で確認できる動作性能上の問題に関して、システム200の動作性能に関連する様々なイベントを記録するためのデバイス側動作ロギングモジュール5702が含まれる。デバイス側動作ロギングモジュール5702は、動作性能に関する情報を（図４で紹介した）動作ログ416に保存する。

ワイヤレスプロバイダーシステム202には、ワイヤレスプロバイダーシステム202で確認できるパフォーマンス問題に関して、システム200の動作性能に関連する様々なイベントを記録するため、同様に動作ロギングモジュール5704を含む。動作ロギングモジュール5704は、動作性能に関する情報を動作ログ5706に保存する。

通信許可システム208は、通信許可システム208で確認できるパフォーマンス問題に関して、システム200の動作性能に関連する様々なイベントを記録するため、同様に動作ロギングモジュール5708を含む。動作ロギングモジュール5708は動作性能に関する情報を動作性能ログ5710に保存する。

IPS102は、様々な機能を実行するため、顧客サービスモジュール5712を含むことができる。第一の機能として、IPS102もまた、独自に様々なイベントを記録し、IPSサイド動作性能ログ5714に保存する。さらに、顧客サービスモジュール5712は、ユーザデバイス104、ワイヤレスプロバイダーシステム202、また/もしくは通信許可システム208が収集したあらゆる動作性能情報を入手することができる。ある特定の場合では、顧客サービスモジュール5712は、システム200の異なる部分から、自動的にパフォーマンス情報を収集する。別の場合では、顧客サービスモジュール5712は、システム200の異なる側面に対してユーザデバイス104、ワイヤレスプロバイダーシステム202また/もしくは通信許可システム208が収集したパフォーマンス情報を問い合わせることにより、オンデマンドでターゲットを絞った問い合わせを行うことができる。例えば、ユーザが国内の特定の地域でダウンロードの受信に関する問題を特定するため顧客サービス担当者に電話をする可能性がある。顧客サービス担当者は、問題の原因を見出すため、システムのいずれかの部分から提供される動作性能情報を調査することができる。

さらに、IPS102の管理者は、積極的にシステム200の様々な部分をテストすることができる。例えば、IPS102には、サーバサイド試験モジュール5716が含んでもよい。サーバサイド試験モジュール5716は、試験ユーザデバイス群に定期的に試験信号を送信し、応答を要求するために使用される。あるいは、試験モジュール5716は、オンデマンド方式で試験ユーザデバイスに試験信号を送信し得る。試験ユーザデバイスは、このような試験信号を受信、応答するために相補的な試験モジュール5718を含み得る（デバイス側動作性能ロギングモジュール5702とデバイス側試験モジュール5718は、一括して、図４で紹介した監視および試験機能414に相当することに注意）。サーバサイド試験モジュール5716は、それぞれの試験ユーザデバイスから受け取る応答（応答が受信されたかどうか、また/もしくは応答に関連する様々な動作性能評価項目を含む）を監視する。サーバサイド試験モジュール5716また/もしくは人間の管理者が結果を確認し、システム200上の動作性能に関する問題を診断することができる。

図５８は、試験モジュール（5716、414）の動作をフローチャートにまとめた手順5802を示す。

ブロック5802では、サーバサイド試験モジュール5716は、システム200をテストするべき時であるかどうかを判定する。

ブロック5804では、もしテストをする時期ならば、サーバサイド試験モジュール5804は一つか複数の試験デバイスに試験調査を送信する。

ブロック5806では、サーバサイド試験モジュール5806は試験ユーザデバイスから応答を受け取ったかどうか、もし受け取っていれば、その応答の性質を特定する。

Ｃ．３．例示的なアップグレード関連機能
図５７に戻ると、この図は、IPS102がサーバサイドアップグレードモジュール5720を含むることを示す。ユーザデバイス104は、（図４の文脈で紹介した）相補的なデバイス側アップグレードモジュール418を含む。概要として、ある場合では、サーバサイドアップグレードモジュール5720は、アップグレードまたは他の情報をユーザデバイス104に落とすため、手作業で操作される。それに対して、デバイス側アップグレードモジュール418は、識別されたアップグレードまたは他の情報を適切な方法でロードする。第二の場合では、サーバサイドアップグレードモジュール5720はユーザデバイスより、自動的に（デバイス側アップグレードモジュール418が提供する）バージョン情報を受け取る。サーバサイドアップグレードモジュール5720は、受け取ったバージョン情報を、現在のソフトウェアのバージョンと比較することができる。サーバサイドアップグレードモジュール5720は、たとえば、ユーザデバイスを最新のものにするため、希望する命令を含むアイテムの完全版かパッチをダウンロードすることにより、いずれかの適切なアップグレードを開始することができる。

図５９は、ユーザデバイス104を手作業で更新する手順5900を示す。

ブロック5902では、IPS102に関わる管理者は、ユーザデバイス104に実行するべきアップグレードを特定する。

ブロック5904では、サーバサイドアップグレードモジュール5720は、アップグレードをユーザデバイスに送信することができ、その時点で、デバイス側アップグレードモジュール418はアップグレードを命令の本体に組み込む。更新動作は、エンドユーザが任意的に更新オペレーションに参加することを求められておらず、更新動作を認識していなという意味において透明である。

図６０は、更新を自動モードでユーザデバイス104に提供する手順6000を示す。

ブロック6002で、サーバサイドアップグレードモジュール5720は、ユーザデバイスが使用しているインストラクションの現行バージョンに関する情報を受け取ることができる。

動作6604では、サーバサイドアップグレードモジュール5720は、そのデバイスのバージョンと命令の現行バージョンとを比較することができる。

動作6606では、サーバサイドアップグレードモジュール5720は、例えば命令の現行バージョンとデバイスの命令のバージョンの違いを示す差分ファイルを算出することにより、ユーザデバイスが使用するための自動アップグレードの準備を行うことができる。アップグレードモジュール5720は、パッチまたは完全版ファイルとしてそのアップグレードをユーザデバイス104に転送する。デバイス側アップグレードモジュール418は、そのアップグレードを受け取り、アップグレードを組み込む操作を行う。この場合も、エンドユーザが更新オペレーションに関与することは要求されておらず、更新オペレーションを認識していないであろうという意味において、更新オペレーションは透明である。

図６１は、システム200が、あらゆる種類の更新をユーザデバイス104に転送するために使用する典型的な通信パッケージを示す。このパッケージには、ヘッダ6102とボディ6104が含まれる。ヘッダ6102には、バージョン情報、属性情報、チェックサム情報などを伝達するフィールドが含まれ得る。ボディ6104には、管理票また/もしくは命令関連コンテンツ（スクリプトコンテンツ、プログラムコンテンツなど）、また/もしくはメディアコンテンツ、また/もしくは他の種類のコンテンツが含まれ得る。ボディは、ｔａｒファイルとして、または他のフォーマットもしくは複数のフォーマットの組み合わせを使用して表現することができる。パッケージにより表されるその情報は、権限をもたない個人によるアクセスを防止するため、ランダムな情報と共に暗号化され得る。

このパッケージは、あらゆる種類の動作をユーザデバイス104から引き出す、あらゆる種類の情報をユーザデバイス104と通信する汎用の入れ物の役割を果たす。ある場合では、管理者は、図６１に示されるパッケージを使用して、命令を有するアイテムをユーザデバイス104にダウンロードすることができる。デバイス104は、アイテムをそのメモリに読み込むことにより応答し、その後アイテムが提供するプログラム命令に基づき作動する。

別のケースでは、管理者は図６１に示されるパッケージを使用して、ユーザデバイス104が表示するあらゆる種類のメッセージコンテンツなどの別の種類のコンテンツを、ユーザデバイス104にダウンロードすることができる。例えば、ダウンロードしたコンテンツは、ユーザデバイス104が電源オフモードで表示するよう指示されるメッセージに関連したものであり得る（例えばユーザデバイスが、電源オフモードの動作でディスプレイに情報を表示する非揮発性ディスプレイ技術を使用している場合）。このメッセージを提供するために、パッケージには、メッセージ、および任意で、ユーザデバイス104にそのメッセージの表示方法を指示するスクリプトコンテンツを提供するビットマップが含まれ得る。その他のアプリケーションも可能である。

Ｄ．例示的なプロビジョニング機能
Ｄ．１．プロビジョニング機能概要
図６２は、新規ユーザデバイスを提供するシステム6200をす。より具体的には、システム6200は、工場もしくは工場のような環境で新たに製造されたユーザデバイス6204（またはそれの構成要素）とやりとりをするプロビジョニング機能6202を含む。新しいユーザデバイス6204には、プロビジョニングモジュール6206が含まれ得る。デバイス側プロビジョニングモジュール6206は、プロビジョニング機能6202から臨時問い合わせ先情報6208を受け取り、それには、一つか複数のID番号を含まれ得る。プロビジョニング機能6202はまた、通信環境6210とやりとりして、通信環境6210にプロビジョニング情報6212を提供することができる。プロビジョニング情報6212は、ユーザデバイス6204に保存されている臨時問い合わせ先情報6208に関連する。

図６２で示すように、ユーザデバイス6206は、臨時問い合わせ先情報6208を使用して通信環境6210への最初のアクセスを確立する。通信環境6210は、次に、より恒久的な問い合わせ先情報6214をユーザデバイス6204に転送することができる。その後ユーザデバイス6204は、より恒久的な問い合わせ先情報6214を使用してIPS102およびその他のネットワークでアクセス可能なリソースにアクセスすることができる。プロビジョニング手法により、ユーザは複雑で厄介な設定オペレーションを行わずに、ユーザデバイス6204を使用することができる。

プロビジョニングユーザデバイスの一つの例示的方法に関する追加詳細は、出願番号11/277,876、出願日2006年3月29日、発明の名称「無線デバイスプロビジョニングと起動」、発明者スブラム・ナラシムハン他に記載される。

Ｄ．２．例示的なバーチャルアカウント処理
図６３は、ユーザが、ユーザデバイス104を購入した直後に、アイテムを購入（またはより一般的に、アイテムを取得）できるようにする手順6300を解説する。この手順6300は、少なくとも部分的に、図３８のバーチャルアカウントモジュール3816により実行され得る。

ブロック6302で、この購入システムがユーザの新規ユーザデバイス購入を受け取る。

ブロック6304では、この購入システムもしくは他のモジュールがユーザにひとつのバーチャルアカウントを設定する。このバーチャルアカウントは、ユーザデバイスがユーザに割り当てられる前に設定される。

ブロック6306では、この購入システムはユーザが行った一つか複数のアイテム購入を受け取る。この購入システムは、これらの購入と、ブロック6304で作成されたバーチャルアカウントとを関連づける。

ブロック6308では、ユーザデバイスがユーザに割り当てられたとき、購入システムもしくは他のモジュールは、バーチャルアカウントと割り当てられたユーザデバイスを関連づけることができる。この連結動作により、ユーザは新規デバイスを使用して、バーチャルアカウントに適用されたアイテムを受領、消費することができる。

Ｄ．３．例示的な初期テスト
図６４は、この文脈においてはデバイスアンダーテスト（DUT）と呼ばれる新規ユーザデバイス6402のテストの方法を示す。例えば、この方法は工場または他の製作工程でデバイスをテストするために使用され得る。

導入として、ユーザデバイス6402には、優先ローミングリスト（PRL）6404と、最終使用＜amostrecentused（MRU）＞テーブル6406が含まれる。PRL6404には、ユーザデバイスが通信ステーションとの通信を確立するために調べるターゲット周波数のリストが含まれる。MRUテーブル6406は、ユーザデバイス104が通信ステーションとのアクセスを確立するために最後に使用した周波数を特定する。

図６４はまた、試験装置6408も示す。試験装置6408は、一部において、ユーザデバイス6402が通信ステーションとの通信を確立する能力を測定するために使用される。試験装置6408は、テスト実施の目的でユーザデバイス6402との通信を確立する際、テストチャンネル6410を使用することができる。

このテストを進めるするために、図６４に記載される方法は、試験装置6408のテストチャンネル6410を特定する情報を保存するように、ユーザデバイス6406のMRUテーブルをプログラムする。これにより、ユーザデバイス6402は、試験装置6408と迅速にコンタクトを確立することができ、すなわち、試験装置6408と通信するための周波数を探し回る必要がない。

更なる機能として、このテスト方法では、PRLテーブルにテストPELを保存する必要はなく、テスト後に、フィールドで使用するためのテストPRL6404と実際のPRL6404が置き換えられる。つまり本方法では、PRL6404はテスト動作の間中、実際のPRL情報が維持され得る。

図６５は、上に記載したテスト方法を実行するための手順6500を示す。

ブロック6502では、MRUテーブル6406は試験装置6408のテストチャンネル6410を特定する情報を保存する。

ブロック6504では、ユーザデバイス6402と試験装置6408がテストを実行する。テストを実施する際、適切なアクセス情報は、既にMRUテーブル6406に保存されているため、ユーザデバイス6402は試験装置6408のチャンネルを探す必要がない。

最後に、この発明は構造的特徴また/もしくは方法論上の動作に対して具体的な言語で記載されるが、添付の請求項に定義される発明は、必ずしも、記載される具体的機能もしくは動作に限定されるものではないことを理解されたい。むしろ、具体的機能および動作は、特許権を主張する発明の典型的な実施形態として公開するものである。

Claims (10)

1. プロキシモジュールあって、
   ネットワークアクセス可能なリソースにアクセスするための要求を、ユーザデバイスから受信し、
   前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースにアクセスすることを許可されているかどうかを判定し、
   前記要求されたネットワークアクセス可能なリソースにアクセスすることを、前記ユーザデバイスが許可されていると判定される場合、前記ユーザデバイスを前記要求されたネットワークアクセス可能なリソースにアクセス可能にするよう構成されたプロキシモジュールを備え、
   前記プロキシモジュールは、前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースに直接アクセスすることを制限するように構成されており、
   前記判定は、少なくとも
   （ａ）前記要求されたネットワークアクセス可能なリソースが、前記アイテム提供システムによって提供される故に、前記ユーザデバイスのアクセスを許可する、
   （ｂ）前記要求されたネットワークアクセス可能なリソースが、無料でアクセス可能なリソースというクラスのメンバである故に、前記ユーザデバイスの、前記プロキシモジュールを経由しないアクセスを許可する、および
   （ｃ）前記要求されたネットワークアクセス可能なリソースが、料金を支払うことでアクセス可能なリソースというクラスのメンバであり、かつ前記ユーザが前記料金の支払いに同意している故に、前記ユーザデバイスの、前記プロキシモジュールを経由しないアクセスを許可する
   というビジネス規則に基づいて、前記要求されたネットワークアクセス可能なリソースにアクセスすることをユーザデバイスが許可されることを確認することを特徴とするユーザデバイスにサービスを提供するアイテム提供システム。
2. 前記ユーザデバイスが、個別のネットワークアドレスに関連した、所定数の承認されているネットワークアクセス可能なリソースのみにアクセスできるようにし、それによって、前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースに直接アクセスすることを制限するように構成された通信許可システムをさらに備えたことを特徴とする請求項１に記載のアイテム提供システム。
3. 前記アイテム提供システムは、前記所定数の承認されているネットワークアクセス可能なリソースのうちの１つであることを特徴とする請求項２に記載のアイテム提供システム。
4. ユーザデバイスにサービスを提供するアイテム提供システムによるアイテム提供方法であって、
   プロキシモジュールにおいて、
   ネットワークアクセス可能なリソースにアクセスするための要求を、ユーザデバイスから受信し、
   前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースにアクセスすることを許可されているかどうかを判定し、
   前記要求されたネットワークアクセス可能なリソースにアクセスすることを、前記ユーザデバイスが許可されていると判定される場合、前記ユーザデバイスを前記要求されたネットワークアクセス可能なリソースにアクセス可能にするステップと、
   前記プロキシモジュールにおいて、前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースに直接アクセスすることを制限するステップと
   を含み、
   前記判定は、少なくとも
   （ａ）前記要求されたネットワークアクセス可能なリソースが、前記アイテム提供システムによって提供される故に、前記ユーザデバイスのアクセスを許可する、
   （ｂ）前記要求されたネットワークアクセス可能なリソースが、無料でアクセス可能なリソースというクラスのメンバである故に、前記ユーザデバイスの、前記プロキシモジュールを経由しないアクセスを許可する、および
   （ｃ）前記要求されたネットワークアクセス可能なリソースが、料金を支払うことでアクセス可能なリソースというクラスのメンバであり、かつ前記ユーザが前記料金の支払いに同意している故に、前記ユーザデバイスの、前記プロキシモジュールを経由しないアクセスを許可する
   というビジネス規則に基づいて、前記要求されたネットワークアクセス可能なリソースにアクセスすることをユーザデバイスが許可されることを確認することを特徴とする方法。
5. 通信許可システムにおいて、前記ユーザデバイスが、個別のネットワークアドレスに関連した、所定数の承認されているネットワークアクセス可能なリソースのみにアクセスできるようにし、それによって、前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースに直接アクセスすることを制限するステップをさらに含むことを特徴とする請求項４に記載のアイテム提供方法。
6. 前記アイテム提供システムは、前記所定数の承認されているネットワークアクセス可能なリソースのうちの１つであることを特徴とする請求項５に記載のアイテム提供方法。
7. コンピュータを、
   プロキシモジュールあって、
   ネットワークアクセス可能なリソースにアクセスするための要求を、ユーザデバイスから受信し、
   前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースにアクセスすることを許可されているかどうかを判定し、
   前記要求されたネットワークアクセス可能なリソースにアクセスすることを、前記ユーザデバイスが許可されていると判定される場合、前記ユーザデバイスを前記要求されたネットワークアクセス可能なリソースにアクセス可能にするよう構成されたプロキシモジュールを備え、
   前記プロキシモジュールは、前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースに直接アクセスすることを制限するように構成されており、
   前記判定は、少なくとも
   （ａ）前記要求されたネットワークアクセス可能なリソースが、前記アイテム提供システムによって提供される故に、前記ユーザデバイスのアクセスを許可する、
   （ｂ）前記要求されたネットワークアクセス可能なリソースが、無料でアクセス可能なリソースというクラスのメンバである故に、前記ユーザデバイスの、前記プロキシモジュールを経由しないアクセスを許可する、および
   （ｃ）前記要求されたネットワークアクセス可能なリソースが、料金を支払うことでアクセス可能なリソースというクラスのメンバであり、かつ前記ユーザが前記料金の支払いに同意している故に、前記ユーザデバイスの、前記プロキシモジュールを経由しないアクセスを許可する
   というビジネス規則に基づいて、前記要求されたネットワークアクセス可能なリソースにアクセスすることをユーザデバイスが許可されることを確認するユーザデバイスにサービスを提供するアイテム提供システムとして機能させることを特徴とするコンピュータプログラム。
8. 前記コンピュータを、前記ユーザデバイスが、個別のネットワークアドレスに関連した、所定数の承認されているネットワークアクセス可能なリソースのみにアクセスできるようにし、それによって、前記ユーザデバイスが、前記要求されたネットワークアクセス可能なリソースに直接アクセスすることを制限するように構成された通信許可システムとしてさらに機能させることを特徴とする請求項７に記載のコンピュータプログラム。
9. 前記アイテム提供システムは、前記所定数の承認されているネットワークアクセス可能なリソースのうちの１つであることを特徴とする請求項８に記載のコンピュータプログラム。
10. 請求項７ないし９のいずれかに記載のコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images