1つの例示的な実施形態に従い、本開示はアイテムをユーザ装置にダウンロードするための機能を説明する。該機能は、多様なシステム、モジュール、コンピュータが読取可能なメディア、データ構造、方法および他の形態で明示され得る。
上記で言及した「アイテム」は、いかなるタイプのコンテンツにも対応し得る。1つの事例において、アイテムはデジタルメディアアイテムに対応する。メディアアイテムは、テキストコンテンツ、画像コンテンツ、オーディオコンテンツ、ビデオコンテンツ、ハイパーテキストコンテンツ等、または、これらの種類のコンテンツのいかなる組み合わせも含み得るが、これらに限定されない。これに加えて、または、代替として、アイテムは機械が読取可能なプログラムコード、マークアップ言語コンテンツ、スクリプトコンテンツ等のような命令付きコンテンツを含むことができる。例えば、アイテムはソフトウェアのアップグレード等に対応し得る。
より具体的には、1つの事例において、「アイテム」という用語は、本(例えば「電子書籍(eBook)」)、雑誌の号等のような特定の単位の売買可能なコンテンツを指し得る。代替として、アイテムは、本の章またはアルバムの曲のような売買可能な単位のさらに小さい部分を指し得る。代替として、アイテムはいかなる様式の関連するコンポーネントアイテムのより大きなまとまりをも差し得る。例えば、アイテムは特定の年の雑誌の複数の号を指し得る。
「エントリ」という用語は、アイテムを指す情報に対応する。例えば、エントリのリストは、それぞれのメディアアイテムを特定する参照情報を含み得る。
特定の図面が、多様なロジック、モジュール、コンポーネント、機能等を示すことによって特徴を図説する。「ロジック」、「モジュール」、「コンポーネント」、「機能」等の用語は、一般的に、ハードウェア、ソフトウェア、ファームウェアまたはこれらの要素のいずれの組み合わせ、または、さらに他の何らかの種類の実施形態を表す。例えば、ソフトウェアによる実現の場合においては、「ロジック」、「モジュール」、「コンポーネント」または「機能」という用語は、処理ユニット(例えば、CPU)上で実行されると、指定されたタスクを実行する命令付きコンテンツを表し得る。命令付きコンテンツは、1つ以上の機械が読取可能なメディアに記憶することができる。
「機械が読取可能なメディア」等の用語は、多様な種類の記憶装置(磁気、光学、静的等)を含む、いかなる形態で情報を保持するためのいかなる種類のメディアをも指す。また、「機械が読取可能なメディア」という用語は、情報をある点から別の点に送信する多様な配線接続および/またはワイヤレスのリンクを含む、情報提示の一時的な形態も包含する。
他の図面は、信号図の形態および/またはフローチャートの形態で特徴を図説する。この様式の説明においては、特定の動作が、特定の順序で実行される連続した個別のタスクとして説明される。このよう実施形態装は説明のためであって制限ではない。これらの図面で説明される個別の動作はまとめてグループ化して、単一の動作において実行することができ、一方、特定の単一動作を複数の部分において実行することができる。特定の動作は、図面に図説した順序とは異なる順序で実行することができる。特定の動作は、図面において特定したエージェントとは異なるエージェントによって実行することができる。図面に示した動作は、ソフトウェア、ファームウェア、ハードウェア、手動処理、または他の形態、もしくはこれらの形態のいかなる組み合わせによっても実現され得る。
一般的に、実施形態において説明した多様な特徴は、任意選択の特徴として捉えられ得る、つまり、これらの特徴は省略、または他の機能と置換され得る。さらに、本明細書で説明される多様な実施形態は追加の特徴を加えることによって補完され得る。
本開示は以下の主要セクションを含む。
セクションAは、システムの概要と動作の方式を提供する。
セクションBは、セクションAのシステムで使用することができる多様なコンポーネントについて追加の情報を提供する。
セクションCは、システムが実行することができる多様な管理機能を説明する。
セクションDは、システムが実行することができる多様なプロビジョニング機能を説明する。
セクションEは、システムによって提供される多様なインデックス作成および検索関連機能を説明する。
セクションFは、システムによって提供される多様な電力管理機能を提供する。
A.システムの概要および動作の方式
A.1.例示的なシステム概要
図1は、アイテム提供システム(IPS)102からユーザ装置104にアイテムをダウンロードするための例示的なシステム100を示す。装置104で、ユーザは、従来のハードコピー形態ではなく、電子形態のメディアアイテムに目を通し得る。図示していないが、ユーザ装置104は、潜在的に多数のユーザ装置のうちの1つを表す。
先に説明したように、「アイテム」という用語は広義の意味を有する。以下のリストは、非包括的であるが、アイテムの代表的なタイプを特定する。
アイテムは、電子書籍アイテムに対応し得る。電子書籍アイテムは、次いで、電子形態の本または(本の章のような)本の1つ以上の部分、または(シリーズ本のような)複数の本の組み合わせ等を指し得る。電子書籍は、本明細書において、予め生成されたアイテムと称される、一般的な分類のアイテムの例である。予め生成されたアイテムという用語は、典型的に(必ずしもそうである必要はないが)、IPS102によって受信および格納された後、コンテンツに対するユーザのオンデマンド要求に応答して、ユーザに提供されるコンテンツを指す。
また、コンテンツのアイテムは、サブスクリプション関連アイテムにも対応し得る。サブスクリプション関連アイテムは、スケジュールに基づいて、または他の何らかのタイプの予め締結された契約に基づいて、ユーザが受信するいかなるアイテムをも指す。サブスクリプション関連アイテムの代表的形態は、雑誌、ジャーナル、新聞、ニュースレター等を含むがこれらに限定されない。サブスクリプション関連アイテムの他の形態は、RSS(Really Simple Syndication)フィード等の多様なタイプの電子フィードを含む。予め生成されたアイテムとは対照的に、サブスクリプション関連アイテムは、典型的に、予め生成されたアイテムに対するユーザのオンデマンド要求ではなく、IPS102によるアイテムの受信に応答してユーザに提供される。
また、アイテムは、個人文書アイテム、または単に「個人アイテム」にも対応し得る。個人アイテムは、前もってユーザがIPS102に転送する文書を指し、転送するとIPS102はアイテムを装置が読取可能なフォーマットに変換する。
また、アイテムは、音楽、音楽のコレクション、オーディブック等のようなオーディオコンテンツにも対応し得る。
また、アイテムは、ユーザが作成したクエリに応答して生成される一連の情報にも対応し得る。
また、アイテムはソフトウェア更新のような命令付きコンテンツにも対応し得る。
また、アイテムは、いかなるエンティティまたはエンティティの組み合わせによって、ユーザ装置にダウンロードされる広告資料にも対応し得る。このタイプのアイテムのダウンロードを規制するように多様なルールが適用され得る。
また、アイテムは、アイテムのさらに完結したバージョンのサンプルに対応し得る。1つの事例においては、サンプルタイプのアイテムは、ユーザにその完全バージョンの対応物またはアイテムの別の部分(例えば、章)を取得可能にする1つ以上のリンクを埋め込み得る。別の事例においては、出版元または著者は、シリーズで、複数回連載して電子書籍または他のアイテムを公開し得る。各連載はアイテムと見なされ得る。
アイテムは、アイテムの草稿、つまり、著者が必ずしも最終と見なしていない状態のアイテムに対応し得る。
「アイテム」という用語は、コンテンツのさらに他の形態を包含し得、上記のタイプのアイテムは代表例である。
アイテム提供システム(IPS)102は、アイテムをユーザ装置104に転送するためのいずれの機能または機能の組み合わせにも対応する。1つの事例では、IPS102は、ネットワークからアクセス可能なサーバベースの機能、多様なデータストア、および/または他のデータ処理機器に対応し得る。IPS102は、単一の物理サイトで提供される機能の単一の集合によって実現され得る。代替として、IPS102は、任意選択的に複数の物理サイトで提供される、複数の集合の機能によって実現され得る。IPS102は、単独のエンティティまたは複数のエンティティによって管理され得る。
1つの事例においては、IPS102は、ユーザがアイテムを購入すると、アイテムをユーザに提供するエンティティに対応する。この役割においては、IPS102は、究極的に、書店等として機能し得る。1つの特定の販売環境においては、IPS102は、ユーザに物理的に配達するハードコピーの本をユーザが購入することを可能にするサービスを提供し得る。この状況においては、IPS102によって、ユーザは、一連のサービス全体の一部として、電子アイテムをそれぞれのユーザ装置にダウンロードすることが可能になり得る。他の事例においては、IPS102は、無料ベース、または他の何らかのタイプの代替対価契約ベースで、ユーザにアイテムを提供するエンティティに対応する。このように、アイテムの「プロバイダ」という用語は、教育機関、政府機関、図書館、非営利団体等、またはいずれか2つ以上のエンティティの何らかの協調的組み合わせを包含するように広義に解釈されるべきである。
ユーザ装置104は、IPS102からアイテムを受信するためのいかなるタイプの電子処理装置104にも対応する。1つの実施形態においては、ユーザ装置104は容易に携帯可能、つまり、ユーザはユーザ装置104を1つの場所から別の場所へと自由に持ち運び得る。1つの特定の事例においては、ユーザ装置は、電子書籍リーダ装置とも称される、ブックリーダ装置として設計される。この事例においては、ユーザ装置104は、紙ベースの本の電子対応物として機能する。ユーザは、物理的な本と同様な方法でユーザ装置104を手に持ったり、本のページを電子的にめくったり、等を実行し得る。図1は、特定のタイプの電子書籍リーダ装置を図説するが、これに限定されない。この特定のタイプのリーダ装置に関する追加詳細を以下に提供する。代替として、ユーザ装置104は、携帯型音楽プレーヤー、パーソナルデジタルアシスタント(PDA)、携帯電話、ゲームモジュール、ノート型コンピュータ等、および/またはこれらの種類の装置のいかなる組み合わせのような、他のいかなるタイプの携帯装置にも対応し得る。代替として、またはこれに加えて、ユーザ装置104は、パーソナルコンピュータ、テレビに付属するセットボックス、ゲーム端末等のような容易に携帯できない装置に対応することができる。
通信インフラストラクチャ106は、IPS102をユーザ装置104に双方向に結合する。すなわち、IPS102は、通信インフラストラクチャ106を経由して、アイテム、アップグレード、および/または他の情報をユーザ装置104にダウンロードする。IPS102は、通信インフラストラクチャ106を経由して、ユーザ装置104から多様な命令や他のデータを受信する。
通信インフラストラクチャ106は、配線接続したリンクおよび/またはワイヤレスリンク等を含む、通信機能のいかなる組み合わせをも含み得る。例えば、図2(順に以下に記述)は、広域ネットワーク(WAN)とワイヤレスインフラストラクチャの組み合わせを含む通信インフラストラクチャ106の1つの実施形態を示す。通信インフラストラクチャ106のワイヤレスコンポーネントの効用によって、ユーザは、配線接続したリンクを経由するIPS102に束縛されることなく、ユーザ装置104を使用してアイテムを購入し、アイテムを消費し得る。このように、例えば、ユーザは、乗客として乗車している間、公園をハイキングしている間、湖でボートに乗っている間等に、装置を使用して電子書籍を購入して一読し得る。
図1は、アイテムをユーザにダウンロードする手順部分を非常に高レベルの形態で説明する、4件の情報交換を示す。第1のメッセージ108において、IPS102は、ユーザ装置104に通知メッセージを送信することができる。通知メッセージ108は、ユーザ装置104に、IPS102から1つ以上のアイテムをダウンロード、および/または他の動作を実行するように命令する。第2のメッセージ110において、ユーザ装置104は、ダウンロード(および/または、1つの事例ではIPS102に情報を返信する等の他の動作を実行)する1つ以上のアイテムを特定するリストを供給するように、IPS102に要求する。ユーザ装置104は、第2のメッセージ110に応答して、IPS102からリストを受信する(図1は、IPS102からユーザ装置104へのリストの送信を具体的に特定していないことに注意)。命令がダウンロードするアイテムを特定する場合、第3のメッセージ112において、ユーザ装置104は、IPS102に要求を送信し、リストに特定したアイテムをダウンロードするようにIPS102に依頼する。第4のメッセージ114において、IPS102は、要求されたアイテムをユーザ装置104にダウンロードする。実際には、ユーザ装置104は、プル手法を使用してアイテムを回収するが、プル手法は、プッシュ動作によって(IPS102が通知メッセージ108をユーザ装置104に「プッシュする」効用によって)開始する。
1つの事例においては、通知メッセージ108は、電話の呼び出し音のように、音声モードの対話を開始するために使用される特定のタイプの通知メッセージに対応し得る。この事例においては、通知メッセージ108は、地上波フォンホームまたはテレフォンホーム(TPH)信号としても称される。(地上波フォンホーム、テレフォンホーム、TPH等の識別子は、明細書の説明を容易にする便宜上の不特定のラベルであることが理解されるであろう。)他のメッセージは、データモードメッセージの形態を採り得る。1つの事例では、ユーザ装置104は、実際にはTPH信号に正式に応答せずに、TPH信号を受信して動作するように構成され得る。つまり、ユーザ装置104は、TPH信号を受信すると、音声接続は行なわずに、IPS102からアイテムをダウンロードするステップを開始する。一部の環境においては、ワイヤレスプロバイダシステムは、呼び出しに応答すると課金し得るが、ユーザ装置が呼び出されても応答しない場合は課金し得ない。このように、応答せずにユーザ装置104を呼び出すという戦略によって、IPS102は、ユーザ装置104またはIPS102に課金することなく、ユーザ装置104に命令を伝えることが可能になり得る。
A.2.システムの例示的なワイヤレス実施形態
図2は、図1の汎用システム100の1つの例示的な実施形態を表すシステム200を示す。概要を目的として、システム200は、上記で特定したコンポーネント、すなわち、通信インフラストラクチャ106を経由してユーザ装置104に結合したIPS102を含む。
通信インフラストラクチャ106は、複数のコンポーネントを含む。第1のコンポーネントは、ワイヤレスプロバイダシステム202である。ワイヤレスプロバイダシステム202は、ユーザ装置104とのワイヤレス交換204を提供するためのいかなるインフラストラクチャにも対応する。1つの事例においては、ワイヤレスプロバイダシステム202は、多様なデータ処理機器、通信塔およびその他(図示せず)を使用して実現される。代替として、またはこれに加えて、ワイヤレスプロバイダシステム202は、衛星技術に依存して、ユーザ装置104と情報を交換し得る。ワイヤレスプロバイダシステム202は、無線波信号等(これに限定されない)の信号を送信するように、いかなる形態の電磁気エネルギーも使用し得る。ワイヤレスプロバイダシステム202は、例えば、符号分割多元接続(CDMA)プロトコルを使用して実現される、スペクトル拡散技術等(これに限定されない)の、いかなる信号送信通信技術でも使用し得る。ワイヤレスプロバイダシステム202は、単一のエンティティまたは複数のエンティティの協調的な組み合わせによって管理され得る。
通信インフラストラクチャ106は、通信実現システム206も含む。通信実現システム206の1つの目的は、IPS102とワイヤレスプロバイダシステム202との間で情報を渡す場合に媒介として機能することである。通信実現システム210は、1台以上のサーバ型コンピュータ、データストアおよび/またはデータ処理機器等(これらに限定されない)のいかなる様式においても実現され得る。通信実現システムは、1つ以上のアプリケーションプログラミングインタフェース(API)208を公開し得る。IPS102は、API208を呼び出し、多様なそれぞれの機能を実行することができる。
通信実現システム206は、専用通信パイプまたはプライベートパイプとも称される専用チャネル210を経由してワイヤレスプロバイダシステム202と通信する。チャネル210は、通信実現システム206とワイヤレスプロバイダシステム206との間で情報を送信するために独占的に使用されるという意味で専用である。対照的に、通信実現システム206は、公共の広域ネットワーク(WAN)212のような非専用通信メカニズムを経由してIPS102と通信する。例えば、WAN212はインターネットを表し得る。
通信実現システム206はアダプタとして機能し得る。例えば、1つの特定の実施形態においては、IPS102は、広域公共網を経由して情報を受信するようにセットアップされるデータセンターとして機能すると想定する。さらに、ワイヤレスプロバイダシステム202は、プライベートパイプを経由してクライアントと対話するように設定されると想定する。通信実現システム206は、広域ネットワーク212を経由してIPS102と、およびプライベートパイプ210を経由してワイヤレスプロバイダシステム202と対話することによって、IPS102とワイヤレスプロバイダシステム202の処理優先権に対応する。この媒介役の効用によって、通信実現システム206は、仮想移動体通信事業者向けサービス事業及び事業者(MVNE(Mobile Virtual Network Enabler))と称され得る一方で、IPS102は仮想移動体通信事業者(MVNO)と称され得る。
ビジネスパラダイムの観点から、IPS102は、ホールセールアカウント(wholesale account)を使用してワイヤレスプロバイダシステム202と対話し得る。これに基づいて、IPS102は、全てのユーザ装置によるワイヤレスプロバイダシステム202の総計使用に基づいた料金をワイヤレスプロバイダ202に支払い得る。IPS102は、エンドユーザに課金する料金によってこれらの費用を回収し得る。この例示的なビジネス状況においては、ワイヤレスプロバイダシステム202は、ユーザ装置を操作するユーザに直接請求書を送付しない。
より具体的には、ワイヤレスプロバイダシステム102は、そのサービスの全ユーザに関連する通信トラフィック214の全体量を処置する。通信トラフィック214の全体量の一部分が、マーチャント関連通信トラフィックとも称される、IPS関連の通信トラフィックを表す。IPS関連トラフィック216は、IPS102と、IPS102と対話する全てのユーザ装置との間で発生する情報交換を表す。ワイヤレスプロバイダシステム202は、IPS関連トラフィック216に関連した固有のキー情報に基づいて、他のトラフィックからIPS関連トラフィック216を区別する。ワイヤレスプロバイダシステム202は、IPS関連トラフィック216の合計量に基づいて請求書を作成し得る。上記のように、ワイヤレスプロバイダシステム202は、装置の個別のユーザではなく、IPS102からのサービスに対して支払を求め得る。
上記の例は代表的な例である。IPS102とユーザ装置104との間で情報を交換する他の戦略を使用し得る。代替事例においては、例えば、システム200は、ワイヤレスプロバイダシステム202が個別のユーザから直接コストを確実に回収するように、構成され得る。あるいは、システム200は、個別のそれぞれのユーザの任意選択で、ワイヤレスプロバイダシステム202が請求書をIPS102(総計で)または個別のユーザのいずれかに送信するように、構成され得る。
ユーザは、ワイヤレスプロバイダシステム202の使用を迂回する代替通信経路を介してIPS202にアクセスし得る。例えば、代替アクセス経路218によって示すように、ユーザは、パーソナルコンピュータ等を使用して広域ネットワーク212を経由してIPS102にアクセスし得、ワイヤレスプロバイダシステム202と通信実現システム206とを回避する。ユーザは、この経路を介して従来の様式でアイテムをダウンロードし得る。ユーザは、次に、例えば、USB(ユニバーサルシリアルバス)送信メカニズムを経由したり、携帯型記憶装置を手動で移動したりすること等により、パーソナルコンピュータからユーザ装置104にアイテムを送信し得る。このモードの送信は、特に、オーディブック等のような大型のファイルに適し得る。このような大量のデータをワイヤレス方式で送信すると、比較的高い費用がかかり得る。しかし、システム200は、ワイヤレス交換204を経由して、(オーディオファイルのような)大型のファイルを送信するように構成することもできる。
図2のシステム200は、多様なセキュリティ関連特徴も提供する。1つの特徴に従って、システム200は、複層の認証を適用する。すなわち、ワイヤレスプロバイダシステム202は、第1のレベルの認証を実行する認証機能A1220を含む。通信実現システム206は、第2のレベルの認証を実行する認証機能A2222を提供する。IPS102は、第3の層の認証を実行する認証機能A3224を提供する。各層の認証は、IPS102との対話を現在試行しているユーザ装置が、正式に認証されてIPS102にアクセスすることを保証するように確認を実行する。認証の分散性は、不正な手段によってユーザ装置を入手した何者かがIPS102によって提供されるサービスへのアクセスを獲得できないことを保証するために役立つ。
別のセキュリティ関連特徴に従って、システム200は、ユーザが装置104を使用し得る様式を制限する多様な制約を提供し得る。例えば、通信実現システム206は、ユーザ装置がIPS102に関連する1つ以上の既定のアドレスにだけアクセスが可能であるように、構成され得る。つまり、1つの事例においては、ユーザは、まずIPS102を介してルーティングしていないと、ネットワークからアクセス可能なサイトに直接アクセスするためにユーザ装置104を使用することが不可能である。これによって、ユーザが、ネットワークからアクセス可能なリソースへの無制限の広帯域インタフェースとして、ユーザ装置104を使用することを防止する。
より具体的には、IPS102は、ウェブ閲覧プロキシを含み得る(以下に詳細を述べる)。ユーザがネットワークからアクセス可能なリソース226にアクセスしようとすると、通信実現システム206は、まず、ユーザを閲覧プロキシモジュールに向かわせる。閲覧プロキシモジュールは、次に、要求を拒否する、または、ユーザをネットワークからアクセス可能なリソース226にアクセス可能にすることによって、要求を受理する、のいずれかを実行し得る。閲覧プロキシモジュールは、ネットワークからアクセス可能なリソース226へのアクセス要求を拒否するか、または受理するかどうかを決定する場合に、多様なルール(以下に記述)を適用し得る。このようにして、通信実現システム206およびIPS102は、ユーザがネットワークからアクセス可能なリソースに直接アクセスすることを許可しない。
別の事例においては、システム200は、ユーザがネットワークからアクセス可能なリソースと直接対話することを可能にする、つまり、IPS102を介してルーティングしないことがあり得る。
A.3.例示的なアイテム提供システム(IPS)とユーザ装置
図3は、IPS102の詳細とユーザ装置104(図1および2に図示)を含むシステム300を示す。図示していないが、図3に示したシステム300は、図2に示したワイヤレス機能を使用し得る。別の実施形態においては、システム300は、図2に示した以外の何らかの通信インフラストラクチャを使用し得、ワイヤレス通信の使用を任意選択的に省略し得る。
まず、IPS102を詳細に述べると、このシステム102は多様な機能を実行する。これらの様々な機能には様々なモジュールが関連する。1つのモジュールは、コンテンツ受信システム302である。コンテンツ受信システム302は、1つ以上のコンテンツソース304からコンテンツを受信する。ソース304は、電子書籍発行元、新聞発行元、他の定期発行元、多様なフィードソース、音楽配信元等のような、いかなるタイプのコンテンツプロバイダをも表し得る。
ソース304は、単一のエンティティによって管理され得るか、または、個別のそれぞれのエンティティによって管理され得る。さらに、IPS102を管理するエンティティは、1つ以上のソース304を管理する同じエンティティに対応し得る。代替として、またはこれに加えて、IPS102を管理するエンティティは、1つ以上のそれぞれのソース304を管理する1つ以上の様々なエンティティと相互関係を持ち得る。後者の場合、IPS102を管理するエンティティは、これらのソースエンティティからコンテンツを受信するように、ソースエンティティと契約を締結し得る。
上記の例では、ソース304に関連するエンティティは、営利的団体または他のタイプの団体に対応し得る。別の事例においては、1つ以上のソースは、アイテムの作成者のような個人ユーザに対応し得る。例えば、ユーザは、IPS102にアイテムを直接提供し得る。代替として、またはこれに加えて、ユーザは、コンテンツをアイテムのコミュニティレポジトリ(community repository)に供給し得、IPS102は、このレポジトリからコンテンツを受信する等ができる。
コンテンツ作成システム302は、多様なメカニズムを介してコンテンツを取得し得る。1つの事例においては、コンテンツ受信システム302は、1つ以上のネットワーク306を経由してコンテンツを取得する。ネットワーク306は、インターネットのようなWAN、ローカルエリアネットワーク(LAN)またはこれらの組み合わせを表し得る。コンテンツ受信システム302は、いかなるプロトコルまたはプロトコルの組み合わせも使用して、多様な形態の情報を受信し得る。例えば、コンテンツ受信システム302は、HTTP(ハイパーテキストトランスファープロトコル)要求を行うことによって、FTP(ファイルトランスファープロトコル)要求を行うことによって、フィード(例えばRSSフィード)を受信すること等によって、情報を受信し得る。別の事例においては、IPS102は、ソース304のP2P(ピアツーピア)ネットワークを経由してコンテンツを取得し得る。より一般的には、コンテンツ受信システム302は、コンテンツのインおよびオンデマンド方式を積極的に要求し得る(情報送信のプルメソッドに基づいて)。あるいは、コンテンツ受信システム302は、ソース304によって開始および実行される独立の送信動作に応答して、コンテンツを受信し得る(情報送信のプッシュメソッドに基づいて)代替として、コンテンツ受信システム302は、プルとプッシュの送信メカニズムの組み合わせを使用してコンテンツを受信し得る。
コンテンツ受信システム302は、アイテムの形態でコンテンツを受信することができる。アイテムは、電子書籍、オーディブック、音楽、雑誌、ジャーナル発行、新聞の版、多様なフィード等を含み得るが、これらに制限されない。1つの事例においては、コンテンツ受信システム302は、ユーザ装置104が読取不可能なフォーマットで表現されたいくつかのアイテムを受信し得る(ユーザ装置が、1つ以上の既定フォーマットで表現されたコンテンツを受信、処理、表示するように任意選択的に構成され得る場合)。この状況に対応するために、コンテンツ受信システム302は、アイテムをオリジナルのフォーマットから装置が読取可能なフォーマットに変換し得る(.mobiフォーマット等であるが、これに限定されない)。
コンテンツ受信システム302は、受信したアイテムをコンテンツストア308に保存(および任意選択で別のフォーマットに変換)する。コンテンツストア308は、電子形態のアイテムを保存するための1つ以上のストレージシステムを含み、システムは、単一のサイトまたは複数のサイトに分散して所在し、1つ以上のエンティティによって管理される。
セクションB(以下)は、コンテンツ受信システム302の動作に関する追加情報を提供する。プレビューすると、コンテンツ受信システム302は、予め生成されたアイテム(例えば、電子書籍)、サブスクリプション関連アイテム(例えば、新聞)および個人アイテム(例えば、ユーザが入力したワープロ文書等)を処置するための個別のモジュールを含む。
IPS102は、サブスクリプションモジュール310も含む。サブスクリプションモジュール310は、サブスクリプション関連アイテムに対するユーザのサブスクリプションを管理する。一般的に、サブスクリプションによって、ユーザには、任意のタイプの検討事項または検討事項の組み合わせに基づいて、1つ以上のサブスクリプション関連アイテム(さらにコンテンツ受信システム302によって受信および格納される)を受信する権利が与えられる。サブスクリプション関連アイテムのタイプは、雑誌、ジャーナル、ニュースレター、新聞、多様なフィード等を含むがこれらに限定されない。ユーザは、このようなサブスクリプションを購入することによって、またはより一般的には、このようなサブスクリプションを受信するように登録することによって、サブスクリプション関連アイテムを受信するように手配することができる(一部の場合には、料金の支払が関与しないことがある)。代替として、またはこれに加えて、IPS102は、ユーザが関与することなく(そして、ユーザの承認がない可能性もある)、サブスクリプション関連アイテムを受信するようにユーザを自動的に登録し得る。後者の状況は、IPS102(または他のエンティティ)は、未承諾の広告、ニュースレター等を受信するようにユーザを登録する事例において適切であり得る。システム300によって、ユーザは、このような未承諾の情報の受信を停止することが可能にし得る。
IPS102は、サブスクリプションモジュール310に問い合わせて、新しく受信したサブスクリプション関連アイテムを受信するべきユーザ装置を決定し得る。例えば、雑誌「Forbes」の電子版を受信すると、IPS102は、サブスクリプションモジュール310に問い合わせて、この雑誌を受信するように支払を済ませたユーザを特定する。IPS102は、次に、適当なユーザ装置にこの号を送信する。
アイテム配信システム312は、ユーザ装置104へのコンテンツの送信を実際に実行する機能を表す。1つの例示的な典型例においては、アイテム配信システム312は、タスクリストサーバモジュール314とコンテンツ配信モジュール316という2つのコンポーネントを含む。タスクリストサーバモジュール314は、一般的に、ユーザ装置104に対する命令を提供する。命令によって、ユーザ装置104はアイテムの受信や他の動作を実行する。コンテンツ配信モジュール316によって、ユーザ装置104は、タスクリストサーバモジュール314から受信した命令に特定されたアイテムの取得が可能になる。
より具体的には、情報回収の第1段階において、タスクリストサーバモジュール314は、ユーザ装置104に通知メッセージを送信する。上記のように、1つの例示的な実施形態においては、タスクリストサーバモジュール314は、電話の呼び出し音として通知メッセージを送信し得る。ユーザ装置104は、(「休止状態」の場合)活動状態に戻ることによって、通知メッセージに応答するが、これは、第1の電力状態から第2の電力状態への切り替えが関与し得る(第2の電力状態は、第1の電力状態よりも多くの電力を消費する)。ユーザ装置104は、任意選択で、信号に正式に応答せずに通知メッセージに応答し得、これにより、ワイヤレスメッセージに関連する料金を回避または削減する。ユーザ装置104は、次に、タスクリストサーバモジュール314に問い合わせて、タスクリストサーバモジュール314からの命令を要求する。より具体的には、タスクリストサーバモジュール314は、各ユーザ装置に対して、以下「タスクキュー」とも称されるエントリのリストを維持する。エントリは、ユーザ装置が動作を実行するための命令を提供する。以下に詳細を説明するように、装置に実行を指示し得る多様な命令が存在するが、命令の一群はIPS装置の対話プロトコルを定義する。このような動作(例えば、プロトコルのGET命令に関連する)の1つは、例えば、適切なネットワークアドレス(例えばURL)と適切な引数とを指定することによって、特定の場所からアイテムを読み込むようにユーザ装置104に命令する。第1段階においては、ユーザ装置104は、一般的にn件のこのようなエントリを読み込むが、ここでnは整数である。ある状況においては、数字nは、ユーザ装置104に関連したタスクキュー内のアイテムの合計数の一部であり得る。ダウンロード手順の第2段階では、ユーザ装置104は、コンテンツ配信モジュール316に問い合わせて、GET関連エントリに特定された1つ以上のアイテムを読み込む。
一般的に、通知メッセージ(電話の呼び出し音として実現し得る)を受信後、アイテム配信システム312は、例えば、HTTP(ハイパーテキストトランスファープロトコル)または他の何らかのプロトコルまたはプロトコルの組み合わせを使用して、データモードでユーザ装置104と対話する。ダウンロード手順のさらに詳細を以下に説明する(例えば、図8の説明中)。
IPS102は、マーチャントストアモジュール318も含む。マーチャントストアモジュール318は、アイテムカタログ320へのアクセスを提供し、これによって、複数のアイテムに関する情報を提供する(電子書籍、オーディブック、サブスクリプション関連アイテム等)。以下に詳細を説明するように、マーチャントストアモジュール318は、ユーザがアイテムカタログ320を介して検索および閲覧可能になる機能を含む。マーチャントストアモジュール318は、ユーザのアイテム購入(または、より一般的には、いずれかの条件に基づいてアイテムを入手)を可能にする機能も含む。1つの事例においては、ユーザは、ワイヤレス通信を使用して、ユーザ装置104を経由でマーチャントストアモジュール318と対話し得る。代替として、またはこれに加えて、ユーザは、任意選択的に有線リンクを経由する、パーソナルコンピュータのような別のタイプの装置322を経由して、マーチャントストアモジュール318と対話し得る。いずれの事例においても、ユーザがマーチャントストアモジュール318を経由してアイテムを購入あるいはそれ以外の方法で入手すると、IPS102は、アイテム配信システム312を起動して、ユーザにアイテムを配信し得る。
IPS102は、個人メディアライブラリモジュール324も含む。個人メディアライブラリモジュール324は、各ユーザに対して、ユーザのこれまでの購入リストを保管する。より具体的には、1つの事例においては、個人メディアライブラリモジュール324は、ユーザが既に所有する電子書籍アイテムおよび他のオンデマンド選択(例えば、サブスクリプション発行物等の「アラカルト」選択)に関するメタデータ情報を提供する。個人メディアライブラリモジュール324は、コンテンツストア308内のアイテムへのリンクも提供する。以下に詳細を説明するように、ユーザが既に購入した電子書籍アイテム(または同等の物)をダウンロードするために、ユーザ装置104はコンテンツ配信モジュール316に問い合わせる。コンテンツ配信モジュールは、個人メディアライブラリモジュール324内の許可情報およびリンク情報と対話して、アイテムをユーザにダウンロードする。1つの使用状況においては、ユーザ装置104は、ユーザによってこれまでに購入済みであるが、何らかの理由によってユーザ装置104によって削除されたアイテムのダウンロードを開始するように、この様式でコンテンツ配信モジュール316にアクセスし得る。
IPS102は、閲覧プロキシモジュール326も含む。閲覧プロキシモジュール326によって、ユーザは、ユーザ装置104上に存在する閲覧モジュール(以下に説明)経由で1つ以上のネットワークからアクセス可能なリソース328にアクセスすることが可能になる。図2の状況で説明したように、ユーザが特定のネットワークからアクセス可能なリソースへのアクセスを要求すると、システム300は、まず、ユーザを閲覧プロキシモジュール326に向かわせる。閲覧プロキシモジュール326は、次に、このようなアクセスを与えるかどうか、また、与える場合は、このようなアクセスをどのような条件で与えるかを決定する多様な環境特有のビジネスルールを適用し得る。このメカニズムを介して、1つの実施形態においては、ユーザは、ユーザ装置104を使用してネットワークからアクセス可能なリソース328に直接アクセスすることを阻止される。
IPS102は、1つ以上の認証ストア330のような多様なセキュリティ関連特徴も含む。認証ストア330は、IPS102の多様なコンポーネントが、マーチャントストアモジュール318のアクセス、アイテムのダウンロード、設定の変更等のような様々な機能の実行をユーザに可能にするかどうかを決定できるようにする情報を提供する。
上記に列挙したモジュールのリストは、例であって、IPS102によって実行される機能のタイプを網羅するものではない。「他のサーバ側機能」という見出しによって示すように、IPS102は、追加の機能を含み得るが、その多くを以下に説明する。
ここで、システム300の装置側の特徴を見ると、ユーザ装置104は、装置のタスクリスト処理モジュール334を含む。装置のタスクリスト処理モジュール334の目的は、アイテム配信システム312と対話して、アイテム配信システム312からアイテムをダウンロードすることである。つまり、ダウンロード手順の第1段階では、装置のタスクリスト処理モジュール334は、まず、タスクリストサーバモジュール314から通知メッセージを受信し、タスクリストサーバモジュール314は、タスクリスト処理モジュール334に(「休止状態」の場合)活動状態に復帰し、タスクリストサーバモジュール314に問い合わせてn件のエントリのセットを回収するように指示する。各エントリは、装置のタスクリスト処理モジュール334に動作を実行するように指示する命令を含む。第2段階では、GETタイプのエントリの場合、装置のタスクリスト処理モジュール334は、コンテンツ配信モジュール316と連絡し、GETタイプのエントリによって特定されたアイテムを要求して読み込む。以下に詳細を説明するように、ユーザ装置104は、ダウンロードプロセスの完了成功、またはダウンロードプロセスの失敗を信号で送信する。
アイテムがダウンロードされると、ユーザ装置104は、アイテムを装置側メモリ336に格納するが、このメモリは、1つの例ではフラッシュタイプのメモリであり、他の例では他のいかなるタイプのメモリでもあり得る。図示していないが、ユーザ装置104は、他のいかなるコンテンツソース338とでも情報を交換し得る。1つの例示的な事例においては、他のコンテンツソース338は、パーソナルコンピュータまたは他のデータ処理装置を表し得る。このような他のコンテンツソース338は、USB(ユニバーサルシリアルバス)接続および/または他のいかなるタイプの接続をも経由して、ユーザ装置104にアイテムを送信し得る。この状況においては、他のコンテンツソース338は、次いで、配線接続(例えば、ワイヤレス以外の接続)を経由して、IPS102(または他のソース)からアイテムを受信し得る。例えば、オーディブックを受信するには、ユーザは、ネットワークからアクセス可能なこのようなコンテンツソースからオーディブックをワイヤレス以外でダウンロードするためにパーソナルコンピュータを使用し得る。ユーザは、次に、USB接続を経由してユーザ装置104にオーディブックを転送し得る。別の例示的な事例においては、他のコンテンツソース338は、フラッシュタイプのメモリモジュール、磁気メモリモジュール、光メモリモジュール等のようないかなるタイプの携帯型メモリモジュールをも表し得る。
ユーザ装置104は、リーダモジュール340も含む。リーダモジュール340の例示的な目的は、ユーザ装置104を使用するユーザによって消費するメディアアイテムを提示することである。例えば、リーダモジュール340は、紙ベースの物理的に存在する本の読書をシミュレーションするユーザ体験を提供するように、電子書籍をユーザに表示するために使用され得る。
ユーザ装置104は、コンテンツ管理モジュール342も含む。コンテンツ管理モジュール342の目的は、ユーザ装置104を使用して消費するために利用可能なアイテムの管理をユーザに可能にさせることである。例えば、コンテンツ管理モジュール342によって、ユーザは消費に利用可能なアイテムのリストを表示することが可能になる。コンテンツ管理モジュール342は、それぞれのアイテムのソースも特定する。このようなソースの1つは、装置メモリ336に対応する。別のソースは、付属の携帯型メモリに対応する(例えば、他のソース338によって表される)。別のソースは、個人メディアライブラリモジュール324に特定されたアイテムに対応する(つまり、IPS102によって提供される装置側メタデータによって明らかにされ得る)。別のソースは、サブスクリプションモジュール310によって特定されるサブスクリプション関連アイテムに対応する、等となる。コンテンツ管理モジュール342によって、ユーザは多様な方式でアイテムをフィルタおよびソートすることが可能になる。例えば、ユーザは、装置ストア336から発生したアイテムを選択的に表示し得る。
ユーザ装置104は、ストア対話モジュール344も含む。ストア対話モジュール344によって、ユーザ装置104はマーチャントストアモジュール318と対話することが可能になる。ユーザは、アイテムを検索したり閲覧したり、アイテムを購入したり、カスタマレビューを読んだり書いたりする等のために、ストア対話モジュール344に用い得る。上記に説明したように、ユーザは、パーソナルコンピュータ等を使用して、配線接続リンク経由でマーチャントストアモジュール318とも対話し得る。
上記に列挙したモジュールのリストは、例であって、ユーザ装置104によって実行される機能のタイプを包括するものではない。「他の装置側機能」という見出しによって示すように、ユーザ装置104は、追加の機能を含み得るが、その多くを以下に説明する。事実、図4は、追加の装置側機能を示す。完全性のため、図4は、装置のタスクリスト処理モジュール334、装置メモリ336、リーダモジュール340、コンテンツ管理モジュール342、およびストア対話モジュール344を含む上記の多様なモジュールも特定する。これらの特徴が上記の機能を実行する。
図4は、ユーザ装置104が閲覧モジュール402をも含むことを示す。閲覧モジュール402は、ユーザ装置104が、IPS102によって提供される閲覧プロキシモジュール326を経由して、1つ以上のネットワークからアクセス可能なリソース328にアクセスすることを可能にする。上記のように、閲覧プロキシモジュール326は、環境特定のルールセットに基づいて、ネットワークからアクセス可能なリソース328へのアクセスを許可または拒否する。アクセスが許可されると、装置側閲覧モジュール402は、ネットワークからアクセス可能なリソースから受信したコンテンツを解釈するため、およびこのようなコンテンツをユーザに提示するための機能を含む。
ユーザ装置104は、検索およびインデックス作成機能404も含む。この機能404のインデックス作成態様は、IPS102から受信したアイテムのインデックスを作成するため、および/またはIPS102によってまたは他の何らかのソースによって生成および供給されるインデックスと相互に関わるためのメカニズムを提供する。特定アイテム(電子書籍または新聞の版等)に対するインデックスは、アイテムのコンポーネント部分(例えば、単語)を特定し、コンポーネント部分をアイテム内のそれぞれの場所に連結する。機能404の検索態様は、アイテム内で特定したコンポーネント(例えば、語句等)を検索するため、および他の検索関連機能を実行するためのメカニズムを提供する。検索態様はインデックス作成態様に依存する。セクションEは、検索およびインデックス作成機能404によって実行される動作に関する追加情報を提供する。
ユーザ装置104は、注釈モジュール406も含み得る。注釈モジュール406によって、ユーザは特定のアイテムを補完する注釈を作成することが可能になる。例えば、ユーザは、あるタイプの注釈を作成してページに印を付け得るので、したがってこれはブックマークの様式で動作する。ユーザは、電子書籍の語句、文等のようなアイテムの部分をハイライトする別のタイプの注釈を作成し得る。ユーザは、1つ以上のメモをアイテムに追加することによって、別のタイプの注釈を作成し得る。一般的に、注釈モジュールは、作成された注釈の種類を特定する注釈情報、注釈に関連するアイテム内の場所、注釈の内容(例えば、メモタイプの注釈の場合)等を特定する注釈情報を保管し得る。
より具体的には、ユーザ装置104は、注釈をローカルに保管し得る。さらに、IPS102は、任意選択的に、バックアップストアに注釈を保管し得る。これによって、ユーザは、装置側ストアから削除した場合に、注釈をダウンロードすることが可能になる。保管場所に関わらず、ユーザ装置104は、注釈の「ターゲット」または対象となる対応するアイテムの提示に伴って注釈をリストアし得る。例えば、ユーザが以前に1回以上注釈した電子書籍にアクセスすると、注釈モジュール406は、注釈情報にアクセスしてユーザの注釈をテキスト内に表示し得る。注釈モジュール406は、アイテムの1部分以上を特定して抽出(例えば「クリップ」)し、さらにこのような部分をクリップファイルに保管することをユーザに可能にする関連機能も実行し得る。1つの例示的な事例では、クリップは、暗号化していないテキストファイルとして保管する。1つの事例では、注釈はユーザのような特殊なエンティティと関連付けることが可能である。代替として、またはこれに加えて、注釈は、電子書籍のような注釈付きアイテムのコピーに関連付けることが可能である。
ユーザ装置104は、ホーム提示モジュール408も含む。ホーム提示モジュール408は、ユーザがまずユーザ装置および/または他の連接部に電源を入れると、ホームページを提供する。ホームページは、ユーザ装置によって提供されるメディアアイテムおよび多様な機能にアクセスすることをユーザに可能にする汎用ポータルとして機能し得る。1つの例示的な事例においては、ホームページは、ユーザ装置104を使用して消費するために利用可能なアイテムの一部(または全て)の概要を提示し得る。
ユーザ装置104は、オーディオ再生モジュール410も含む。オーディオ再生モジュール410は、音楽、オーディブック等のようなオーディオアイテムを再生および相互にやり取りすることをユーザに可能にするインタフェースを提供する。
ユーザ装置104の上記の機能は、ユーザが対話し得る、または、そうでなければユーザがユーザ装置104との対話において高度なレベルの役割を果たす、アプリケーションに関連する。ユーザ装置104は、バックグラウンド型動作のような可能性がある多様な低レベルのタスクを実行する他の機能をいくつか含み得る。
電力管理機能412は、このようなバックグラウンド型動作の1つを実行する。より具体的には、電力管理機能412は、ユーザ装置104によって消費される電力を管理するハードウェアおよび/またはソフトウェア機能動作の一群に対応する。電力管理機能412は、一般的に、装置104によって消費される電力を削減するように働く。電力管理機能412は、活発に使用されていない(または、これらの機能が活発に使用されていないという想定が存在する)機能の電力を選択的に切断することによって、この目的を実現する。電力管理機能412は、ワイヤレス通信に関連する1つ以上の機能のように、大量の電力を要求する機能の電力を切断することによって、特に大幅な節電を実現する。セクションFは、電力管理モジュール412の動作に関する追加情報を提供する。
ユーザ装置104は、パフォーマンス監視およびテスト(MT)機能414も含む。MT機能414は、装置104の動作を特定するパフォーマンスログ416を維持する。IPS102および/または他のエンティティは、全体としてユーザ装置104とシステム300の動作における異常を診断することに役立つ、通信インフラストラクチャ106から集めた他の情報とともに、パフォーマンスログ416にアクセスし得る。MT機能414は、IPS102および/または他のエンティティによって提供されるテスト機能と相互に作動し得る。例えば、MT機能414は、セクションCで以下に詳細を説明する様式において、IPS102によって生成されるテストプローブに対応し得る。
ユーザ装置104は、アップグレード関連機能418も含む。アップグレード関連機能418によって、ユーザ装置104は、命令付き更新アイテム(例えばソフトウェア更新)を受信および統合することが可能になる。1つの事例では、アップグレード関連機能418は、IPS102によって(および/または他のエンティティによって)提供される命令付きアイテムを自動的に受信し得る。IPS102の管理者は、アップグレード手順を手動で開始し得、これによって、命令付き更新アイテムはユーザ装置104に転送される。または、自動化されたIPS側のルーチンがアップグレード手順を開始し得る。いずれにせよ、ユーザ装置は、ユーザが関与することなく、または、ユーザからの最低限の関与で、命令付き更新アイテムを受信し得る。この意味では、更新手順は「透過的」と見なし得る。別の事例においては、アップグレード関連機能418は、ユーザが命令付きアイテムのソース(規定のウェブサイト等のような)に手動でアクセスして、このソースからアイテムをダウンロードすることによって、動作され得る。
1つの実施形態では、アップグレード関連機能418は、バージョン情報をIPS102に転送し得る。バージョン情報は、ユーザ装置104によって使用される命令付きコンテンツのバージョンを特定する。IPS102は、このバージョン情報が旧バージョンかどうかを決定し得る(現在のバージョン情報を参照することによる)。旧バージョンの場合は、IPS102は、例えば、命令付きアイテムをユーザ装置104にダウンロードすることによって、適切に対応し得る。セクションCは、アップグレード関連機能418によって実行される動作に関する追加情報を提供する。
繰り返しになるが、上記に列挙したモジュールのリストは、例であって、ユーザ装置104によって実行される機能のタイプを包括するものではない。「他の装置側機能」という見出しによって示すように、ユーザ装置104は、追加の機能を含み得る。
A.4.例示的なユーザインタフェースの特徴
上記のIPS102は、いかなる種類のユーザ装置104とも対話し得る。ある事例においては、ユーザ装置104は、携帯型装置、つまり、場所から場所へ容易に持ち運ぶように設計された装置である。ある特定の事例においては、ユーザ装置104によって、ユーザは、例えば、ユーザが物理的な本を手に持っている状況をシミュレーションする様式で、ユーザ装置104を手に持っている間にメディアアイテムを読むことが可能になる。携帯型ユーザ装置は、電子書籍リーダ装置、携帯型音楽プレーヤー、パーソナルデジタルアシスタント、携帯電話、ゲームモジュール、ノート型コンピュータ等、および/またはこれらの種類の装置のいかなる組み合わせの形態をも採り得る。代替として、またはこれに加えて、ユーザ装置104は、パーソナルコンピュータ、テレビに付属するセットボックス、ゲーム端末等のような容易に携帯できない装置に対応し得る。
図5は、IPS102と対話するために使用され得る1つのタイプのユーザ装置500を示すが、これに限定されない。ユーザ装置500は、ユーザの手に容易に収まるように設計された楔形の本体を含み得、一般的に、文庫本の大きさを有する。他のユーザ装置は、様々な形状やサイズに適応し得る。
1つの典型的な設計においては、ユーザ装置500は、主表示部502と補助表示部504という2つの表示部分を含む。主表示部502は、ストア対話モジュール344、リーダモジュール340、閲覧モジュール402等によって提供される多様なページを提示する。1つの事例においては、補助表示部504は、カーソルを提示するために使用される。ユーザは、主表示部502の横方向の隣接部分を特定するためにカーソルを移動し得る。1つの例示的な事例においては、主表示部502および/または補助表示部504は、Massachusetts州CambridgeのE Ink Corporationによって提供されるような電子ペーパー技術を使用して実現し得るが、これに限定されない。この技術は、非揮発性メカニズムを使用して情報を表示する。この技術を使用すると、ユーザ装置500は、装置の電源を切断した場合でも表示部に情報を保存することができる。
ユーザ装置500は、多様な入力キーおよびメカニズムを含む。カーソル移動メカニズム506によって、ユーザは補助表示部504内でカーソルを移動し得る。1つの例示的な事例において、カーソル移動メカニズム506は、補助表示部504内でカーソルを上下に移動するように回転させ得るカーソルホイールを含み得る。カーソル移動メカニズム506は、ユーザがホイールを押し下げることによって選択を行うことが可能になるように構成され得る。タッチセンサ式の画面、主表示部502の縁に沿って縦方向および/または横方向に配列した一連のキー、主表示部502の1つ以上のグラフィックスクロールバー等、他のタイプの選択メカニズムも使用され得る。
ユーザ装置500は、次のページボタン(508、510)および前のページボタン512のようなページを操作する多様なボタンも含む。次のページボタン(508、510)によって、ユーザは、アイテムの次のページに進む(現在表示されているページに対して)。前のページボタン512によって、ユーザは、アイテムの前のページに進む(現在表示されているページに対して)。ユーザ装置500は、ユーザの親指がメカニズム514を通過することによって作動する、ページ捲り入力メカニズム514も含み得る。このユーザ体験は、ユーザが物理的な本のページをめくる方式をシミュレーションする(例えば、本を「パラパラと見る」)。ユーザ装置500は、閲覧モジュール402を使用する場合にユーザが前のページに進むことが可能になる後ろボタン516も含み得る。図示していないが、ユーザ装置500は、電源を入れるおよび切るスイッチ、ワイヤレスインタフェースを有効および無効にするスイッチ等を含み得る。
ユーザ装置500は、キーボード518も含み得る。キーボード518は英数字キーも含み得る。キーは、ユーザが物理的な本の様式で装置104を持っている間、ユーザのキーとの相互の動作を容易にする様式の形状や方向に決定され得る。ユーザは、検索語、注釈、URL等を入力するためにキーボード518を使用し得る。キーボード518は、多様な特殊機能のキーも含み得る。
図6は、ユーザが図5のユーザ装置500を使用して主表示部500でコンテンツを選択し得る1つの方式を図説する。すなわち、主表示部502は、コンテンツ602のページを表示すると想定する。コンテンツ602は、最も右側の縦方向の端に沿って配列された多様な選択ポイントを含み得る。選択ポイントは、コンテンツ602の関連部分に横方向に対応する。例えば、典型的な選択ポイント604は、コンテンツ602のページの選択可能なアイテム606に対応する。補助表示部504は、カーソル608を表す。ユーザは、カーソル移動メカニズム506を回転させることによって、補助表示部504内でカーソルを上下に移動し得る。
操作中、図6に示した選択ポイント604のように、カーソル608が所望の選択ポイントと横方向に一致するように、ユーザはカーソル移動メカニズム506を操作し得る。カーソル移動メカニズム506がカーソルホイールである場合、ユーザは、ホイールを回転させて、補助表示部504の縦方向の範囲に沿ってカーソル608を所望の場所に移動させ得る。この実施形態においては、ユーザは、次にカーソルホイールを押し下げて、選択ポイント604に対応するアイテム606を正式に選択し得る。
1つの典型的なタイプのブックリーダ型装置に関する追加情報は、次の一連の出願に見出し得る。
2006年3月29日付け提出の発明者Whitehorn,et al.による米国特許第11/246,293号、名称「Electronic Media Reader Display」
2006年3月29日付け提出の発明者Thomas J. Hobbs,et al.による米国特許第11/246,294号、名称「Electronic Media Reader Keypad」
2006年3月29日付け提出の発明者Whitehorn,et al.による米国特許第11/246,295号、名称「Wedge−Shaped Electronic Media Reader」
2006年3月29日付け提出の発明者Gregg E. Zehr,et al.による米国特許第11/277,898号、名称「Page Turner For Handheld Electronic Book Reader Keypad」
2006年3月29日付け提出の発明者Gregg E. Zehr,et al.による米国特許第11/277,893号、名称「Handheld Electronic Book Reader Device Having Dual Displays」
2006年3月29日付け提出の発明者Gregg E. Zehr,et al.による米国特許第11/277,873号、名称「Handheld Electronic Book Reader Device Having Asymmetrical Shape」
2006年3月29日付け提出の発明者Gregg E. Zehr,et al.による米国特許第11/277,879号、名称「Keyboard Layout for Handheld Electronic Book Reader Device」
繰り返しになるが、図5および6に示したユーザ装置は典型例である。IPS102と対話するために、異なるタイプのユーザインタフェースメカニズムを有する他のタイプのユーザ装置を使用し得る。
A.5.例示的なデータ処理装置
図1、2および3に示したシステムの多様な態様は、1つ以上のデータ処理装置によって実現され得る。例えば、IPS102の多様なコンポーネントは、それぞれのサーバ型コンピュータおよび関連のデータ処理機器(例えば、ルータ、データ格納装置等)によって実現することができる。ユーザ装置は、また、データ処理機器に対応し得る。図7は、いかなるサーバ側の特徴および/またはいかなる装置側の特徴をも含む、上記で参照したシステムのいかなる様態をも実現するためにも使用し得る汎用データ処理装置702の概要を示す。
処理装置702は、1つ以上のCPU等、1つ以上の処理ユニット704を含む。処理装置702は、揮発性および/または不揮発性格納メカニズムのいかなる組み合わせにも対応し得るシステムメモリ706も含む。システムメモリ706は、オペレーティングシステムコンポーネント708、多様なプログラムモジュール710、プログラムデータ712および/または他のコンポーネントを提供する情報を格納し得る。処理装置702は、システムメモリ706によって提供される命令を実行する処理ユニット704を使用することによって、機能を実行する。処理装置702は、1つ以上のタイプの着脱式ストレージ714と1つ以上にタイプの非着脱式ストレージ716も含むことができる。
処理装置702は、1つ以上の入力装置718(キーボード、マウス、特殊選択キー等)と1つ以上の出力装置720(画面、プリンタ、オーディオ出力メカニズム等)も含み得る。
処理装置702は、1つ以上の通信インタフェースメカニズム722も含み得る。これらの通信インタフェースメカニズム722によって、処理装置702は、リモートコンピュータ、ブックリーダ装置等の他の処理装置724と対話することが可能になる。通信インタフェースメカニズム722は、1つ以上のワイヤレスインタフェースメカニズム726を含み得る。処理装置702がユーザ装置104を表す場合、ワイヤレスインタフェースメカニズム726によって、ユーザ装置726は電話の呼び出し音を受信することや、データモードでIPS102と通信することも可能になり得る。
上記に列挙したモジュールのリストは、例であって、処理装置702によって実行される機能のタイプを包括するものではない。「他の装置機能」728という見出しによって示すように、処理装置702は、追加の機能を含み得る。
A.6.アイテムをダウンロードする例示的な方式
上記のセクションで説明したように、IPS102のアイテム配信システム312は、装置側のタスクリスト処理モジュール334と対話して、IPS102のコンテンツストア308からアイテムをダウンロードする。アイテム配信システム312は、したがって、タスクリストサーバモジュール314とコンテンツ配信モジュール316との2つのコンポーネントを含む。タスクリスト処理モジュール334は、タスクリストサーバモジュール314と対話して、エントリをダウンロードし、該エントリはIPS102から回収されるアイテムを特定する。タスクリスト処理モジュール334は、コンテンツ配信モジュール316と対話して、エントリによって特定された実際のアイテムを回収する。図8は、IPS102からユーザ装置104にアイテムをダウンロードするための1つのプロトコル800に関する追加情報を提供する。該プロトコルは例であって、様々な環境に適合するように多様な方式で変形され得る。
動作(1)において、IPSのコンテンツ受信システム302は、コンテンツを受信してコンテンツストア308に保管する。コンテンツ受信システム302は、新しい電子書籍または他の予め生成されたアイテムの受信に応答して、この動作を実行し得る。または、コンテンツ受信システム302は、新しいサブスクリプション関連アイテムの受信に応答して、この動作を実行し得る。または、コンテンツ受信システム302は、ユーザによって転送された個人文書の受信に応答して、この動作を実行し得る。まだ他の状況が可能である。
動作(2)において、タスクリストサーバモジュール314の適切なキューにエントリが追加される。電子書籍を選択(例えば、購入)した場合、選択した電子書籍を入手するという命令に対応して、マーチャントストアモジュール318がタスクリストサーバモジュール314にエントリを追加する。この事例においては、動作(2)は、動作(1)に対して非同期的に発生、つまり、これらの2つの動作は、連結統合トランザクションの一部ではない。この概要図面には示していないが、電子書籍(または、サブスクリプション発行等、他のアラカルト選択)をユーザが購入すると、IPS102は、ユーザの購入に関する情報もメディアライブラリモジュール324に保管するようになる。サブスクリプション関連アイテムを受信した場合、アイテム受信システム302は、サブスクリプションモジュール310と協働して、タスクリストサーバモジュール314にエントリを追加する。この事例においては、動作(2)は、動作(1)に応答して発生するので、これらの動作は、単独のトランザクションの一部として見なされ得る。サブスクリプションの新しい号を受信した場合、サブスクリプションモジュール310は、以下に詳細を説明する方式で、ユーザが以前にサブスクリプションを購入したことによって、ユーザがこの号を所有することを示す。個人アイテムの場合、ユーザの個人アイテムを受信、変換および保管する専用機能は、任意選択的に、タスクリストサーバモジュール314にエントリを追加し得る(実際に、ユーザが、代替の非ワイヤレスモードの配信ではなく、ワイヤレス通信経路を経由して文書を受信しようとしていた場合)。
動作(3)において、タスクリストサーバモジュール314は、装置のタスクリスト処理モジュール334に通知メッセージを送信する。1つの例示的な事例では、該通知メッセージは、本明細書においてテレフォンホーム(TPH)信号とも称される、電話の呼び出し音として実現され得る。アイテム配信システム312とタスクリスト処理モジュール334との間のこれ以降の通信は、全て、例えば、HTTPプロトコルまたは他の何らかのプロトコルまたはプロトコルの組み合わせを使用して、データモードで動作する。
動作(4)において、装置のタスクリスト処理モジュール334は、(その時たまたま休止状態であった場合は)活動状態に復帰して、TPH信号に応答する。通知プロセスは、第1の電力状態から第2の電力状態への切り替えが関与し得るが、第2の電力状態は第1の電力状態よりも多くの電力を消費するものとする。活動状態に復帰すると、タスクリスト処理モジュール334は、タスクリストサーバモジュール314にメッセージを送信し、10件のエントリ等(これに限定されない)のn件のエントリのリストを転送するようにタスクリストサーバモジュール314に要求する。n件のエントリは、ユーザ装置104のためにタスクリストサーバモジュール314によって維持されるリスト内のエントリの一部を表し得る。タスクリストサーバモジュール314は、n件までのエントリのリストを転送することによって、この要求に応答する。
上記のように、各エントリは、命令を伝達するエンベロープを提供する。このようなタイプの命令の1つが、ユーザ装置104に、IPS102からアイテムを回収するように指示する。他のタイプの命令も存在するが、セクションBで説明する。動作(5)において、タスクリストサーバモジュール314から回収されたn件のエントリのうちの1つ以上のエントリがGET命令に対応すると想定して、タスクリスト処理モジュール334は、コンテンツ配信モジュール316に要求を送信して、GET命令で特定されたアイテムをダウンロードするようにこのモジュール316に依頼する。
動作(6)において、コンテンツ配信モジュール316は、コンテンツストア308からアイテムを回収しようとすることによって、アイテムに対する要求に応答する。コンテンツ配信モジュール316が成功すると、要求されたアイテムをユーザ装置104に転送する(これは、図8に示したように、動作(5)の一部と見なし得る)。フィードの場合等一部の状況においては、ユーザ装置のローカルに既に前のバージョンがある場合、コンテンツ配信モジュール316は、要求されたコンテンツの最新バージョンとコンテンツの以前のバージョンとの違いを示すデルタファイルを回収してダウンロードしようとし得る。したがって、この導入説明を必要以上に複雑にしないように、増分更新動作の詳細は、この説明の後半に提供する。
動作(6)は、多様な許可確認ステップにも関与し得る。例えば、電子書籍や他のアラカルト選択の場合、コンテンツ配信モジュール316は、個人メディアライブラリモジュール324に問い合わせて、ユーザがアイテムを受信する認証を有しているかどうかを決定し得る。サブスクリプション関連アイテムの場合、コンテンツ配信モジュール316は、サブスクリプションモジュール310に問い合わせて、ユーザがアイテムを受信する認証を有しているかどうかを決定し得る(例えば、ユーザが一般的に特定のサブスクリプションの号を受信するように承認されているかどうかを決定することによる)。したがって、図8を必要以上に複雑にしないように、許可確認に関連した信号の流れ図は省略するが、この詳細は後の図面および添付の説明で提供する。
動作(5)において、コンテンツ配信モジュール316は、ユーザ装置104に多様なヒントもダウンロードし得る。このようなヒントの1つは、ユーザ装置104に、IPS102が要求されたアイテムに対応するインデックスを保管しているかどうかを伝える。例えば、IPS102は、初めてまたは他の何らかの時点でアイテムを受信したときに、このインデックスを生成していたことがあり得る。別のヒントは、IPS102が要求されたアイテムの注釈を保管しているかどうかをユーザ装置に伝える。これらの注釈は、これまでに1回以上、ユーザによって作成され、IPS102によってバックアップされた情報に対応し得る。ユーザ装置104は、ヒントを使用して、要求したアイテムの検索インデックスおよび/または注釈を配信するようにIPS102に要求する価値があるかどうかを決定する。すなわち、コンテンツ配信モジュール316が検索インデックスを有していないことをユーザ装置104に伝えた場合、インデックスを要求することは有用ではなくなる。ヒントの使用は、ユーザ装置104が、IPS102がインデックス情報および/または注釈情報を保管しているかどうかを決定するために、潜在的に無線の応答が遅い質問と応答の手順を実行する必要性を排除する。
ヒントによって、IPS102が確かに検索インデックスとバックアップ注釈のいずれか(または両方)を有していることがユーザ装置104に伝えられたと想定する。動作(7)において、タスクリスト処理モジュール334は、このタイプの補助情報を要求および受信する。
動作(8)において、タスクリスト処理モジュール334はアイテム(および任意選択で補助情報)を装置のメモリ336に格納する。
動作(9)において、タスクリスト処理モジュール334は、タスクリストサーバモジュール324に削除メッセージを送信する。このメッセージは、ユーザ装置104がIPS102から特定されたアイテムの一部の回収に成功したこと、このため、タスクリストサーバモジュール314は、これらのアイテムを適当なキューから削除し得ることを、タスクリストサーバモジュール314に伝える。動作(10)において、タスクリストサーバモジュール314は、ユーザ装置104によって、送信された削除メッセージの受信を確認し得る。
回収されたn件のエントリは、タスクリストサーバモジュール314によって維持されたより広範囲のアイテムリストの一部だけに対応し得る。このような場合には、タスクリスト処理モジュール334は、別のn件までのエントリを回収して、これらのエントリによって特定されるアイテムをコンテンツ配信モジュール316から受信することによって、上記の動作を繰り返す。
図示していないが、ダウンロードプロセスでエラーが発生すると、ユーザ装置104がエラー情報をIPS102に、および/またはIPS102がエラー情報をユーザ装置に、伝達することが可能である。
B.システムの例示的なコンポーネント
セクションAでシステムの概要を前述したが、このセクションは、システムの多様なコンポーネントを詳細に説明する。該コンポーネントは上記のシステム全体の状況で使用し得るが、該コンポーネントは、他のタイプのシステムでも使用し得る。
B.1.例示的なコンテンツ受信機能
B.1.a.コンテンツ受信システムの概要
上記のように、コンテンツ受信システム302は、1つ以上のソース304からアイテムを回収し、適切な場合には、アイテムを装置が読取可能なフォーマットに変換する。このような変換は、該変換プロセスは、コンテンツをゼロから作成するわけではないが、寛容に本明細書においては「コンテンツ作成」とも称される。コンテンツ受信システム302は、予め生成されたアイテム(電子書籍のような)、サブスクリプション関連アイテムおよび個人アイテムを処置するための個別のモジュールを含み得る。すなわち、コンテンツ受信システム302は、電子書籍処理モジュール902、サブスクリプション関連処理モジュール904およびユーザ提供処理モジュール906を含む。
電子書籍処理モジュール902は、ユーザが典型的にオンデマンド方式で選択するアイテムを受信、処理および保管する。例えば、ある状況においては、電子書籍処理モジュール902は、発行元ソースまたは他のタイプのソースから新しい電子書籍を受信し、このアイテムを所望のフォーマットに変換し、このアイテムをコンテンツストア308に保管し得る。このモジュール902によって実行される処理は、新しく受信したアイテムの検索インデックスの作成、このアイテムの詳細ページの作成等も関与し得る。そして、ユーザは、電子書籍アイテムが保管された後しばらくしてから、このアイテムを購入し得、ユーザへのアイテムのダウンロードを開始する。電子書籍の受信処理は、ダウンロードプロセスとは分離されている、すなわち、これらの2つの動作は非同期的に発生する。
サブスクリプション関連処理モジュール904は、サブスクリプション関連ベースでアイテムを受信、処理および保管する。1つの典型的な事例においては、ユーザは、雑誌、ジャーナル、ニュースレター、新聞、ブログ、フィード等の将来の発行物等、サブスクリプション関連アイテムの将来の号、版、連載等をユーザが受信する権利を得るサブスクリプションを購入し得る。この事例における受信処理は、ダウンロードプロセスに連結、つまり、新しいサブスクリプション関連アイテムの受信によって、このアイテムを受信するように登録済みのユーザへのアイテムのダウンロードをトリガする。
サブスクリプションに関連した受信動作の変形においては、サブスクリプション関連コンテンツ処理モジュール904は、ユーザの関与および/または承認がない可能性があっても、ユーザのサブスクリプションを自動的に確立し、これらのサブスクリプションに従ってアイテムを配信し得る。この特徴は、ユーザに広告を提供、ユーザに多様な警告や他のイベントを通知する場合等に有用になり得る。別の例として、ユーザは、1つ以上のタイプのサブスクリプションを明示的に購入し得、さらに、これに応答して、サブスクリプション関連コンテンツ処理モジュール904は、明示的に購入したサブスクリプション並びに1つ以上の他のサブスクリプション(ユーザが明示的に購入しなかった)の配布を認証する。また別の事例においては、ユーザがまだ発行されていないアイテムを予め購入する場合等、ユーザはアイテムの単独の発行物を予約し得る。アイテムが発行されると、サブスクリプション関連処理モジュール904が起動して、このアイテムを予め購入したユーザに配信することになる。
ユーザ提供処理モジュール906は、ユーザによって本来提供されるアイテムを作成する。つまり、第1段階では、ユーザ提供処理モジュール906は、ユーザからアイテムを受信する。アイテムは、ワープロ文書、PDF文書等のようないかなる種類の個人文書にも対応し得る。第2段階では、ユーザ提供処理モジュール906は、このアイテムを装置が読取可能なフォーマットに変換してから、変換したアイテムをユーザに返送する。ユーザは、自分のユーザ装置104を使用して、変換されたアイテムを読み得る。
いかなるコンテンツ処理モジュール(902、904、906)も、1つ以上の変換ツール908に依存し得る。各変換ツールは、コンテンツをオリジナルフォーマットから定義されたターゲットフォーマットに変換するための機能を提供する。例えば、.mobi変換ツール910は、コンテンツをオリジナルフォーマットから.mobiフォーマットに変換する。他のツール(912、…914)は、アイテムをオリジナルフォーマットから、他のそれぞれのタイプの装置が読取可能なフォーマットに変換する。1つの事例においては、変換ツール908は、規定数の許容可能なオリジナルフォーマットのアイテムを許容する。1つの例示的な実行形態においては、許容可能なオリジナルフォーマットは、アドビPDFフォーマット、TXTフォーマット、HTMLフォーマット、リッチテキストフォーマット(RTF)、マイクロソフトWordドキュメントフォーマット(DOC)等を含み得るが、これらに限定されない。画像の許容可能なフォーマットは、JPEGフォーマット、GIFフォーマット、PNGフォーマット、BMPフォーマットを含み得るが、これらに限定されない。
B.1.b例示的なサブスクリプションモジュール
図10は、図3の説明で導入したサブスクリプションモジュール310に関する追加情報を図説する。サブスクリプションモジュール310は、サブスクリプション管理モジュール1002を含む。サブスクリプション管理モジュール1002は、サブスクリプションの作成と終了、ならびにサブスクリプションの他の態様を管理する。1つの事例においては、マーチャントストアモジュール318は、サブスクリプションのユーザの購入を受信し得る(または、より一般的には、ユーザのサブスクリプション取得)。マーチャントストアモジュール318は、ユーザの選択をサブスクリプション管理モジュール1002に通信することができる。サブスクリプション管理モジュール1002は、次に、例えば、新しいエントリをストア1004に追加する、ストア1004のエントリを削除する、ストア1004のエントリを変更すること等によって、サブスクリプションストア1004と対話し得る。
より具体的には、サブスクリプションモジュール310は、それぞれの親タイプノードとして、利用可能なサブスクリプションを特定する。サブスクリプションの特定の号が受信されて処理されると、サブスクリプションモジュール310は、この号を、対応する親のサブスクリプションの子ノードとして関連付ける。ユーザが特定のサブスクリプションを購入すると想定する。この時点で、ユーザは、サブスクリプションに対応する特定の親ノードに関連付けられる。これに加えて、または代替として、サブスクリプションは装置または他のエンティティに関連付けることが可能である。さらに、1つの実施形態においては、サブスクリプションモジュール310は、ユーザを、サブスクリプションの個別の号ではなく、親のサブスクリプションに関係付けることによって、このサブスクリプションの号の各ユーザの所有を管理する。
サブスクリプション管理モジュール1002は、コンテンツ配信モジュール316とも対話して、ユーザがサブスクリプション関連アイテムをダウンロードするための適切な認証を有しているかどうかをコンテンツ配信モジュール316に伝える(サブスクリプションアイテムのアラカルト選択ではなく、サブスクリプションのアイテムにより、アイテムを受信する場合)。1つの事例においては、このような許可確認は、発行ベースではなく、サブスクリプションベースで発生する(許可確認がアイテムベースで発生する電子書籍や他のアラカルト選択の場合のようなある特定の事例とは異なる)。
B.1.c例示的なインデックス生成機能と注釈処置機能
コンテンツ受信プロセスによって作成されるコンテンツに加えて、補助情報がアイテムに関連し得る。このようなタイプの補助情報の1つはインデックス情報である。別のタイプの補助情報は注釈情報である。図11は、このような補助情報を作成する機能の概要を提供する。
装置インデックスの作成に関しては、IPS102は、サーバ側インデックス生成機能1102を提供し得る。サーバ側インデックス生成機能1102は、インデックスを生成するためのサーバ側インデックス生成モジュール1104を含み得る。サーバ側インデックス生成モジュール1104は、サーバ側インデックスストア1106に生成したインデックスを保管する。ユーザ装置104は、インデックスを生成するための装置側インデックス生成機能1108を含み得る。このように、IPS102とユーザ装置104の両方は、アイテムのインデックスを生成する能力を有する。
インデックスがサーバ側インデックス生成機能1102、または装置側インデックス生成機能1108によって提供されるかどうかを決定するには、多様なルールが使用され得る。1つの考慮事項によると、ユーザ装置104は、装置側インデックス生成機能1108を使用してインデックスを生成しようとするが、このプロセスに時間がかかりすぎることがわかった場合、ユーザ装置104は、サーバ側インデックス生成機能にインデックスを生成するように要求し得る。セクションEは、システム300がアイテムのインデックスを生成する方式に影響を与え得る追加の考慮事項に関する詳細を提供する。
注釈の作成と処置に関して、ユーザは、装置側注釈生成機能1110を使用して、特定アイテムに注釈を作成する。(装置側注釈生成機能1110は、図4に示した注釈モジュール406と同義であると見なし得る。)ユーザは、ブックマーク型注釈、ハイライト型注釈、メモ型注釈、クリップ型コンテンツ選択等を作成し得る。ユーザ装置104は、「最後に読んだページ」の位置を作成することもできる。このタイプの注釈は、アイテムが最後に開かれていた位置を特定する。サーバ側注釈生成機能1110は、いかなる装置側ストアにも注釈を保管し得る。ユーザ装置104は、対応するアイテムを表示する場合にこれらの注釈を回収および再作成し得る。例えば、装置がアイテムを再び開くと、ユーザ装置104は、装置104を閉じたときにユーザが見ていたのと同じページを表示し得る。
システム300は、ユーザがユーザ装置104に作成した注釈のバックアップを保管するために、サーバ側注釈処置機能1112にも依存し得る。サーバ側注釈処置機能1112は、多様なタイミングでユーザ装置104から注釈を受信するための同名のモジュール1114を含むことができる。1つの事例においては、ユーザ装置104は、多様なイベントが発生する場合に実行する動作のサイクルの一部として、IPS102に注釈を転送し得る。このようなイベントは、装置104がIPS102と対話することが必要ないかなる機会をも含み得る(例えば、TPH信号の受信に応答する場合等)。サーバ側注釈処置モジュール1114は、ユーザ装置104から受信する注釈を、サーバ側注釈バックアップストア1116に保管し得る。
IPS102がバックアップ注釈を保管する場合、ユーザ装置104にヒント情報を提供することによって、この実行をユーザ装置104に通知し得る。ヒント情報は、コンテンツ配信モジュール316からユーザ装置に転送されるアイテムに伴う。ヒントがバックアップ注釈が利用可能であることを示す場合、ユーザ装置104は、注釈をダウンロードするように選択し得る。ユーザ装置104は、これらの注釈のローカルストアが削除されていた場合等には、これらの注釈を受信するように希望し得る。
B.1.d.予め生成されたアイテムの受信および処理に対する例示的なアプローチ
セクションB.1の残りの部分は、電子書籍および他の予め生成されたアイテム、サブスクリプション関連アイテム、および個人アイテムの受信および処理のプロセスに関する詳細情報を提供する。
図12から開始すると、この図面は、電子書籍アイテムおよび他の予め生成されたアイテムの受信および処理の1つの方式を図説する信号の流れ図である。動作(1)において、電子書籍処理モジュール902は、電子書籍等を発行元または他のソースから受信する。電子書籍処理モジュール902は、任意選択で、電子書籍アイテムを装置が読取可能なフォーマットに変換し、このアイテムにインデックスを作成し、および/またはマーチャントストアモジュール318のこのアイテムを提示する詳細ページを作成し得る。
動作(2)では、電子書籍処理モジュール904は、アイテムとその補助部分をコンテンツストア308に保管する。
動作(3)では、ユーザは、マーチャントコンテンツストア318から電子書籍を購入、またはそれ以外の方法で入手するために装置側ストア対話モジュール344を操作し得る。
動作(4)では、電子書籍処理モジュール902は、ユーザが電子書籍または他のアラカルトアイテムを購入したことを示す、重要情報をメディアライブラリモジュール324に保管し得る。以下に詳細を説明するように、コンテンツ配信モジュール316は、ユーザがアイテムを受信するように認証されているかどうかを決定するために、アイテムの配信時にメディアライブラリモジュール324に問い合わせを実行し得る(例えば、ユーザがアイテムを実際に購入していたかどうかを決定する)。
これに応答して、動作(5)において、マーチャントストアモジュール318は、購入したアイテムに対応するエントリをユーザのタスクリストに追加し得る。この動作によって、タスクリストサーバモジュール314は、直ちに(またはいくらかの時間経過後)TPH信号をユーザ装置104に送信して、アイテムを取得するという命令がまだ実行されていないことをユーザ装置104に通知する。
信号図の上半分は、動作の作成段階1202に対応し、新しい電子書籍が受信されて処理される。信号図の下半分は、動作の配信段階1204に対応し、ユーザは前に保管されたアイテムを購入して受信する。作成段階1202は配信段階1204に先行するが、これらの2つの段階(1202、1204)はこれ以外には一緒に連結されることはない。
図15は、フローチャートの形態で電子書籍の処理動作を説明する手順1500を示す。
ブロック1502において、電子書籍処理モジュール902は、新しいアイテムを、例えば、アイテムの発行元または他の何らかのソースから受信する。
ブロック1504において、電子書籍処理モジュール902は、任意選択的に、新しいアイテムを装置が読取可能なフォーマットに変更するが、これは、アイテムがまだ装置が読取可能なフォーマットで表現されていないと想定する場合である。
ブロック1506において、電子書籍処理モジュール902は、任意選択的に、アイテムのインデックス、アイテム詳細ページ、および/またはアイテムに関連する他の補助情報を作成する。
ブロック1508において、電子書籍処理モジュール902は、変換したアイテムとアイテムに関連するあらゆる補助情報とを保管する。
ブロック1510において、その後のいずれかの時点で、マーチャントストアモジュール318はユーザがアイテムを購入したことを受信する。
ブロック1512において、電子書籍処理モジュール902は、メディアライブラリモジュール324に購入情報を保管する。この情報は、ユーザが特定の電子書籍等を購入したことを識別する。
ブロック1514において、マーチャントストアモジュール318または他の何らかのサーバ側モジュールが、タスクリストサーバモジュール314の装置のタスクキューにエントリを追加する。このエントリは、ユーザ装置104に購入したアイテムを受信するように指示する命令を含む。
ブロック1516は、一般的に、アイテム配信手順を指し、起動するとアイテムをダウンロードする。この動作は、後の図面で詳細に説明する。
B.1.eサブスクリプション関連アイテムの受信および処理に対する例示的なアプローチ
図13は、サブスクリプション関連アイテムを受信および処理する1つの方式を図説する信号の流れ図である。動作(1)において、サブスクリプション関連処理モジュール904は、サブスクリプション関連アイテムを受信して処理する。この処理には、アイテムを装置が読取可能なフォーマットに変換するステップ、アイテムにインデックスを作成するステップ等が関与し得る。
動作(2)において、サブスクリプション関連処理モジュール904は、受信したサブスクリプション関連アイテムをIPSコンテンツストア308に保管する。図15には図示していないが、サブスクリプションモジュール310において、新しいアイテムは、対応する親サブスクリプションの子ノードとして特定される。上記で説明したように、1つの事例においては、配信時の許可確認は、毎アイテム(例えば、毎号)ではなく、一般的なサブスクリプションレベルのベースで進む。しかし、ユーザがサブスクリプション関連アイテムの個別の選択を行った場合(例えば、アラカルト選択)、上記の電子書籍の許可確認が、アイテムへのアクセスを規制するために使用される。
動作(3)において、サブスクリプション関連処理モジュール904は、サブスクリプションモジュール310に問い合わせて、新しく受信したサブスクリプション関連アイテムを受信すべきユーザを決定する。
動作(4)において、サブスクリプション関連処理モジュール904は、特定されたサブスクリプションを受信するユーザのタスクキューの各々に、エントリを保管し得る。
図16は、フローチャートの形態でサブスクリプション関連の処理動作を説明する手順1600を示す。
ブロック1602において、サブスクリプション関連処理モジュール904は、雑誌の号、新聞の版、フィードアイテム等、新しいサブスクリプション関連アイテムを受信する。
ブロック1604において、サブスクリプション関連処理モジュール904は、適切であれば、受信したアイテムを装置が読取可能なフォーマットに変換し、任意選択的に、装置インデックスのような補助情報を作成する。
ブロック1606において、サブスクリプション関連処理モジュール904は、受信した(および潜在的に変換した)サブスクリプション関連アイテムをコンテンツストア308に保管する。
ブロック1608において、サブスクリプション関連処理モジュール904は、サブスクリプションモジュール310に問い合わせて、サブスクリプション関連アイテムを受信すべきユーザを決定する。
ブロック1610において、サブスクリプション関連処理モジュール904は、サブスクリプション関連アイテムを受信する予定のユーザのタスクキューの各々にエントリを提供する。
ブロック1612は、一般的に、アイテム配信手順を指し、起動するとアイテムをダウンロードする。この動作は、後の図面で詳細に説明する。
B.1.f個人文書の受信および処理に対する例示的なアプローチ
図14は、個人アイテム(個人文書等)を受信および処理する1つの方式を図説する信号の流れ図である。動作(1)において、ユーザは、電子メール機能または他のメッセージ生成機能を使用して、個人アイテムをユーザ提供処理モジュール906に転送する。例えば、ユーザは、個人アイテムを電子メールメッセージへの添付ファイルとして含み得る。1つの事例において、ユーザは、電子メールメッセージと共に単一の個人アイテムを転送し得る。別の事例において、ユーザは、例えば、電子メールメッセージへの複数の添付ファイルとして、電子メールメッセージと共に複数の個人アイテムを転送し得る。ユーザ提供処理モジュール906は、ユーザが、例えば、ZIPファイルまたは他の形態のパッケージに、1つ以上の添付ファイルを一緒にまとめることを可能にする。
1つの実施形態において、ユーザ提供処理モジュール906は、1つ以上の予め認証された電子メールアドレスからのユーザからの電子メールメッセージだけを受理するように構成される。1つの事例において、ユーザは、(例えば、1つ以上の構成ユーザインタフェースを経由して)構成手手順で電子メールアドレスを選択することが可能であり、したがって、電子メールアドレスの許可リストを確立する。ユーザ提供処理モジュール906は、最初に、ユーザによって使用され得る初期設定の電子メールアドレスを提供し得る。ユーザは、後で、この初期設定の電子メールアドレスを変更または追加情報を入力し得る。許可する電子メールアドレスに制限を設けることは、潜在的に、ユーザに転送される不要なアイテムを排除または量を削減することに役立つ。不要なアイテムは、ユーザがこれらのアイテムを受信するために無線配信料金が課金される場合、特に有害になり得る。しかし、別の実施形態においては、ユーザ提供処理モジュール906は、個人アイテムをユーザ提供処理モジュール906に転送するために使用され得る電子メールアドレスに何も制限を設け得ない。
動作(2)において、ユーザ提供処理モジュール906は、メッセージを受信および受信したメッセージを処理し得る(メッセージが許可アドレスリストに特定されたアドレスから送信されている場合)。このような処理には、メッセージのソース、変換されたアイテムが送信される予定の送信先、および/またはメッセージに関する重要な情報を特定するようにメッセージを解釈するステップが関与し得る。また、該処理には、メッセージから個人アイテムを抽出するステップや、アイテムを装置が読取可能なフォーマットに変換するステップも関与する。1つ以上の個人アイテムがZIPファイル等にパッケージ化される場合、抽出動作には、このパッケージファイルから1つ以上の個人アイテムを削除するステップが関与し得る。
上記の処理動作は、完全に成功、完全に失敗、または部分的に成功(および部分的に失敗)し得る。部分的な失敗は、電子メールメッセージが複数の個人アイテムを添付ファイルとして含み、ユーザ提供処理モジュール906が、これらのアイテムの一部の変換には成功するが、他の変換には成功しない場合に発生し得る。例えば、変換が成功しなかったアイテムは、サポートされない本来のフォーマットで表現される場合がある。動作(3)において、ユーザ提供処理モジュール906は、電子メールの送信者に、いずれかのタイプの失敗(完全な失敗または部分的な失敗のいずれか)を通知し得る。部分的失敗の場合、ユーザ提供処理モジュール906は、例えば、処理に成功したアイテムをユーザに配信することによって、処理に成功したアイテムの処理を継続し得る。
ユーザは、変換した個人アイテムを受信するように、少なくとも2つの配信オプションを選択し得る。第1のオプションにおいて、ユーザは、変換した個人アイテムをワイヤレス形態でユーザに転送するように要求し得る。この場合、動作(4)において、ユーザ提供処理モジュール906は、タスクリストサーバモジュール314のユーザのタスクキューにエントリを追加する。第2のオプションにおいて、ユーザは、変換した個人アイテムを非ワイヤレス経路を経由してユーザが利用できるようにするように要求し得る。例えば、ユーザは、変換したアイテムを電子メールの形態でユーザに送信するように要求し得る。ユーザは、電子メールメッセージから変換した個人アイテムを抽出してから、USB接続を経由する等、配線接続したリンクを経由して、変換した個人アイテムをユーザ装置104に送信し得る。あるいは、ユーザは、変換したアイテムをネットワークからアクセス可能なサイトに掲示するように要求し得る。ユーザは、パーソナルコンピュータ等のメカニズムを使用してこのサイトにアクセスし、(非ワイヤレスインフラストラクチャから)変換したアイテムをダウンロードしてから、USB接続または他のメカニズムを経由して変換したアイテムをユーザ装置に送信し得る。動作(5)は、一般的に、非ワイヤレス経路を経由する、1つ以上のパーソナルアイテムの配信を表す。ユーザは、一般的に、無線でコンテンツをダウンロードすると高い費用が発生する可能性を避けるために、非ワイヤレス経路を使用することを好み得る。
図17は、フローチャートの形態で個人アイテムの処理動作を説明する手順1700を示す。
ブロック1702において、ユーザ提供処理モジュール906は、電子メールメッセージのように、ユーザからメッセージを受信するが、これには、添付されたユーザ入力アイテム(または複数のアイテム)を含む。
ブロック1704において、ユーザ提供処理モジュール906は、許可アドレスリストに問い合わせることによって、メッセージが許可されたアドレスから送信されているかどうかを決定する。許可されている場合には、ユーザ提供処理モジュール906は、メッセージをパースして解釈するとともに、それに添付された個人アイテムを抽出する。アイテムの抽出には、いかなる種類のパッケージファイルからもアイテムを削除するステップが関与し得る。
ブロック1706において、ユーザ提供処理モジュール906は、事実、個人アイテムのフォーマットが装置が読取可能なフォーマットでない場合、個人アイテムを装置が読取可能なフォーマットに変換する。ユーザ提供処理モジュール906は、単一のメカニズムに依存してこの変換を実行できる。代替として、ユーザ提供処理モジュールは、複数の利用可能な変換メカニズムのうちのいずれか1つ以上に依存できる。例えば、ユーザ提供処理モジュール906は、特定のタイプのアイテムを変換するために最適と思われる変換メカニズムを選択することができる。これに加えて、または代替として、ユーザは、特定のアイテムに適用される1つ以上のメカニズムを特定する命令を転送し得る。1つの事例において、ユーザ提供処理モジュール906が1つのタイプの変換メカニズムを使用してアイテムの処理に成功しない場合、別のメカニズム等を試行できる。
これに加えて、または代替として、変換には、任意選択で、個人アイテムのサイズを、ユーザ装置によって変換されたアイテムの表現をより適合する形態に変更するステップが関与し得る。つまり、この対策は、装置上に提示される場合に変換されたアイテムをより読みやすくし得る。
これに加えて、または代替として、変換には、個人アイテムを例えば90度回転するステップが関与し得、ここでも、ユーザ装置によって変換されたアイテムの提示がより読みやすくなる。
これに加えて、または代替として、変換には、ユーザ装置上で複数ページで提示するために、個人アイテムを複数部分に分解するステップが関与し得る。例えば、ブロック1706の右側に図示したように、ユーザ提供処理モジュール906は、個人アイテムを90度回転させてから、複数の部分に分解し得る。この動作は、大きい画像(例えば、スキャンしたページ画像のあるPDF文書)を有する特定の個人アイテムに適し得る。ここでも、この対策によって、装置上で提示する場合に変換したアイテムはより読みやすくなり得る。
ブロック1708において、ユーザ提供処理モジュール906は、変換した個人アイテムを受信するためにユーザが使用を希望する経路を決定する。1つの事例において、ブロック1708で実行される決定は暗示的であり得る。例えば、ユーザ提供処理モジュール906は、変換後にワイヤレス経路から送信されるアイテムを受信するために、第1の電子メールアドレスを提供し得る。ユーザ提供処理モジュール906は、非ワイヤレス経路から送信されるアイテムを受信するために、第2の電子メールアドレスを提供し得る。ユーザが個人アイテムを第1の電子メールアドレスに送信する場合、ユーザは変換したアイテムをワイヤレス経路を経由して受信することを希望していると理解される。ユーザが個人アイテムを第2の電子メールアドレスに送信する場合、ユーザは変換したアイテムを非ワイヤレス経路を経由して受信することを希望していると理解される。別の事例において、ユーザ提供処理モジュール906は、個人アイテムを受信するために単一の電子メールアドレスを提供し得る。ユーザ提供処理モジュール906は、メッセージ自体に提供された命令を解釈すること等によって、選択した配信経路を区別し得る。
ユーザがワイヤレス配信経路を選択したと想定する。この事例では、ブロック1710において、ユーザ提供処理モジュール906は、タスクリストサーバモジュール314のユーザのタスクキューにエントリを追加する。
ブロック1712は、一般的に、アイテム配信手順を指し、起動するとアイテムをダウンロードする。この動作は、後の図面で詳細に説明する。
次に、ユーザが非ワイヤレス配信経路を選択したと想定する。ブロック1714において、ユーザ提供処理モジュール906は、変換したアイテムをユーザに電子メールで返信、変換したアイテムをネットワークからアクセス可能なサイトにポストする等、代替の送信メカニズムによって、変換したアイテムをユーザが利用できるようにする。
ブロック1716に示したように、ユーザ提供処理モジュール906は、アイテムの処理に何らかの失敗があるかどうかを解明し得る。失敗がある場合、ブロック1718において、ユーザ提供処理モジュール906は、エラー通知メッセージを発信者に送信する。部分的にだけ失敗している場合、処理が成功し得たアイテムに対して処理が進む。
B.2.例示的なタスクサーバモジュール
このセクションは、タスクリストサーバモジュール314の例示的な作成および動作に関する追加情報を提供する。タスクリストサーバモジュール314は、ユーザ装置104に命令を送信することによって動作し、したがって、ユーザ装置104にアイテムを読み込み、他の動作を実行するように命令することを思い起こされたい。
タスクサーバモジュール314は、タスクリスト受信モジュール1802を含む。タスクリスト受信モジュール1802は、前のセクションで説明した多様な処理モジュール(902、904、906)等、多様なソースからエントリを受信する。例えば、タスクリストエントリ受信モジュール1802は、ユーザが電子書籍等のコンテンツを購入する場合、サブスクリプション関連アイテムを受信する場合、ユーザが個人文書をIPS102に送信する場合等に、エントリを受信し得る。これらのイベント全てによって、GETタイプのエントリが生成されるが、これは、GETタイプエントリに対応するアイテムをダウンロードするようにというユーザ装置104への命令として機能する。他のIPS側のモジュールは、GETタイプのエントリをキューに追加し得、命令付きアップグレードを提供するアイテムをダウンロードすることが必要であることをユーザ装置104に通知する。
他のタイプのエントリは、様々なタイプの命令を伝達し得る。1つの事例においては、IPS102内のエンティティは、削除(DEL)命令を生成し得るが、この命令は、ユーザ装置104がこれまでに受信して装置メモリ336に格納し得たアイテムを削除するようにユーザ装置104に指示する。ある状況においては、ユーザはアイテムを購入した場合があり、これによって、GETタイプのエントリの生成が発生していた。しかし、その後、ユーザの信用状態が十分でないことが決定された場合には、アイテムの購入が不可能になる。この事例においては、IPS102の適切なエンティティ(マーチャントストアモジュール318等)は、ユーザのタスクキューにDELタイプのエントリを追加し得る。
別の事例においては、IPS102の適当なエンティティ(監視および/またはテスト機能等)は、ユーザ装置104にパフォーマンスログおよび/または他の情報を監視および/またはテスト機能に転送するように要求するコマンド(例えば、PUT命令)をユーザのタスクキューに追加し得る。
別の事例においては、IPS102の適切なエンティティは、このエントリの受信時、ユーザ装置104に、例えば、ポップアップ形態または他のタイプの警告関連形態で、情報をユーザに表示するように、情報をタスクキューに追加し得る。
IPS102は、様々なアプリケーションや環境に合わせて、さらに追加のタイプの命令をユーザのタスクリストに追加し得る。
タスクリストサーバモジュール314は、タスクキューとも称される、複数のタスクリストを維持するためのタスクリストストア1804を含み得る。より特定すると、タスクリストサーバモジュール314は、ユーザ装置AにはタスクリストA、ユーザ装置BにはタスクB等と、それぞれのユーザ装置に対して異なるキューを維持し得る。図18で、メールボックスストアAのエントリはユーザ装置A専用であることを示す、四角の破線によって表されるように、ユーザ装置は、その独自のそれぞれのタスクリストと情報のやり取りをする。
タスクサーバモジュール314は、装置対話モジュール1806も含む。装置対話モジュール1806の目的は、タスクサーバモジュール314が装置側タスクリスト処理モジュール334と対話することを可能にすることである。装置対話モジュール1806は、通知モジュール1808を含む。通知モジュール1808は、例えば、呼び出し音タイプのTPH信号の形態で、通知メッセージをユーザ装置108に転送する。装置対話モジュールは、したがって、データモードでユーザ装置と対話する。すなわち、装置対話モジュール1806は、ユーザのタスクキューのn件のリストに対するユーザ装置の要求を受信し、受信時、装置対話モジュール1806はこのリストを提供する。装置対話モジュール1806は、この後、リストから1つ以上のエントリを削除することを指示するユーザ装置の命令を受信し得、ユーザ装置がこれらのエントリに関連したアイテムのダウンロードに成功したことを示す。
タスクリストサーバモジュール314は、タスクリスト管理モジュール1810を含む。タスクリスト管理モジュール1810は、ユーザのタスクキューにポストされたエントリを管理する。1つの事例において、エンティティは、GETタイプのエントリをユーザのキューにポストし得ると、同じエンティティまたは別のエンティティは、DELタイプのエントリをポストし得、装置がこれまでに取得するように依頼した同じアイテムを削除するようにユーザ装置に指示する。この状況においては、1つの事例において、タスクリスト管理モジュール1810は、GETタイプのエントリを削除し得るが、DELタイプのエントリは削除し得ない。この動作は、ユーザ装置104が既にGETタイプのエントリを受信していた場合や、対応するアイテムをダウンロードするプロセスにおいて適切であり得る。
別の事例においては、タスクリスト管理モジュール1810は、ユーザのタスクキューが、新聞または他の定期刊行物のいくつかの版を含んでいると決定する。タスクリスト管理モジュール1810は、ユーザは古い新聞を読みたくないだろうという想定の下で、定期刊行物の最新版以外を全て削除し得る。ユーザには、この動作をオーバーライドするセットアップ選択を行うオプションが与えられ得る。別の事例では、ユーザは、以下に説明する方式で、コンテンツ管理モジュール342を経由して、新聞の古い版にアクセスし得る。
一般的に、タスクリスト管理モジュール1810は、タスクリストキューが、不一致または冗長のエントリ、または他の何らかの不要なエントリタイプのコンテンツを含まないことを保証することに役立つ。
図19は、タスクサーバモジュール314の動作の1方式をフローチャート形式で図説する手順1900を示す。手順1900は、特定のユーザ装置へのアイテムの配信を参照しながら説明する。タスクサーバモジュール314は、同じ手順を使用してアイテムを他のユーザ装置に転送する。
ブロック1902において、タスクサーバモジュール314は、1つ以上のタスクエントリを受信する。この動作は、新しい電子書籍等の購入、新しいサブスクリプション関連アイテムの受信等によって、トリガされ得る。
ブロック1904において、タスクサーバモジュール314は、エントリを適切なメールボックスに保管する(最終的にアイテムを受信するユーザ装置にこのようなメールボックスが関連付けられる)。
ブロック1906で、タスクサーバモジュール314は、TPH信号をユーザ装置に送信して、ダウンロードし得る1つ以上のエントリが存在することをユーザ装置に警告する。より具体的には、1つの実施形態では、TPHスケジュール機能がTPHイベントを受信し得る。1つ以上の考慮事項に基づいて、TPHスケジュール機能は、TPH信号を直ちに送信するかどうか、または、TPH信号の送信を遅らせるかどうかを決定し得る(例えば、可能性として複数のTPHイベントを一体化させて単一のTPH信号を送信することによる)。TPHスケジュール機能に関する追加詳細は以下に提供する。TPHスケジュール機能は、通知モジュール1808の特徴として実現され得る。
ブロック1908において、タスクサーバモジュール314は、ユーザ装置がこれらのアイテムを要求することに応答して、n件のエントリをユーザ装置に提供する。
ブロック1910において、ユーザ装置がエントリによって特定された動作の実行に成功した後(1つ以上のアイテムのダウンロード、1つ以上のアイテムの削除等)、ユーザ装置104は、タスクサーバモジュール314に削除命令を送信する。動作1910において、タスクサーバモジュール314は、タスクキューのエントリを削除することによって、この要求に応答する。
図20は、タスクリストサーバモジュール314のタスクリスト管理モジュール(「管理モジュール」)1810の動作の1つの方式を図説する手順2000を示す。1つの実施形態は、手順2000は、例えば、図19の動作1902と1904の間等、新しいエントリがタスクキューに追加される場合に実行される。
ブロック2002において、管理モジュール1810は、タスクキューのエントリを分析する(タスクキューに追加される候補エントリと共に)。より具体的には、管理モジュール1810は、ユーザ装置への送信を待機しているキューに現在保管されているエントリを特に確認し得る。管理モジュール1810は、ユーザ装置104に既に転送されたエントリも考慮し得る。
ブロック2004では、管理モジュール1810は、何らかの理由で互いに矛盾する、または他の何らかの問題を生じ得るいずれか2つ以上のエントリを考慮する。矛盾の一例は、GETタイプのエントリが、同じアイテムのDELタイプのエントリと相反する場合である。対応が必要な問題の別の例は、タスクキューが同じ新聞または他の定期刊行物の複数の版を含む場合である。対応が必要な問題の別の例は、タスクキューが、まったく二重のエントリを含む場合等である。
ブロック2006において、管理モジュール1810は、可能であれば、矛盾するエントリによって発生したいかなる問題も解決または軽減するステップを実行する。動作2004は、キューへの1つ以上のエントリを削除、キューに1つ以上のエントリを追加する等のように、キューへの変更を行うことを必要とし得る。動作2004には、これに加えて、または代替として、修正コマンドをユーザ装置に送信するステップが関与し得る。
B.3.例示的なタスク処理モジュール
図21は、装置側タスクリスト処理モジュール334の詳細を示す。図21に示したモジュールは、タスクリストサーバモジュール314に対する図18に示した多数のモジュールを補完する。
タスクリスト処理モジュール334は、例えば、電話の呼び出し音の形態で、IPS102から通知メッセージを受信するためのTPH受信モジュール2102を含む。TPH受信モジュール2102は、この信号に正式に応答することなく、TPH信号に対して応答し得、その後、タスクリスト処理モジュール334は、データモードを使用して、IPS102と情報を交換する。TPH信号を受信時、ユーザ装置104は、第1の電力状態から第2の電力状態に遷移し得るが、第2の電力状態は第1の電力状態よりも多くの電力を消費する。これは、ユーザ装置がまだ第2の電力状態になっていないと想定している。
タスクリスト処理モジュール334は、タスクリストサーバモジュール314との全ての対話を処置する場合に使用されるリストサーバ対話モジュール2104を含む(この対話のTPH態様を除く)。すなわち、リストサーバ対話モジュール2104は、タスクリストサーバモジュール314からn件のリストを受信する要求を送信してから、回収動作が成功するとこのようなリストを受信し得る。ユーザ装置が、リストのエントリによって参照されているアイテムを取得した(および/またはエントリによって特定された他の動作を実行)後、リストサーバ対話モジュール2104は、削除命令をタスクリストサーバモジュール314に送信し得、タスクリストサーバモジュール314に対応するアイテムをタスクキューから削除するように命令する。
タスクリスト処理モジュール334は、コンテンツ配信(CD)対話モジュール2106を含む。CD対話モジュール2106の目的は、サーバ側コンテンツ配信モジュール316と対話して、n件のエントリのリストに特定されたアイテムを要求および取得することである。CD対話モジュール2106は、コンテンツ配信モジュール316から多様なヒント、ならびに補助情報(例えば、インデックス情報、バックアップ注釈等)も受信し得る。CD対話モジュール2106は、装置メモリ336または他の何らかの格納メディアから受信するアイテムおよび他の情報を保管し得る。
タスクリスト処理モジュール314は、装置側管理モジュール2108も含み得る。この装置管理モジュール2108は、タスクリスト処理モジュール334の動作を調整する。装置管理モジュール2108は、したがって、装置側増分更新モジュール2110および装置側エラー処置モジュール2112を含み得る。増分更新モジュール2110とエラー処理モジュール2112は、協働し、CD対話モジュール2106によって実行される回収動作を規制する。増分更新動作は、セクションの後半で詳細を説明する。
プレビューの目的で、要求されている(規定のコンテンツを有する)アイテムの特定のタイプに対して適切な場合は、増分更新モジュール2110は、まずデルタファイルを要求することによって、特定されたアイテムを取得するようにCD対話モジュール2106に命令し得る。デルタファイルは、希望したコンテンツの装置側バージョンと、コンテンツの現在のバージョンとの違いを表す。この動作がいずれの理由により成功しない場合(エラー処置モジュール2112によって評価される)、増分更新モジュール2110は、特定されたアイテムの完全バージョンを要求するようにCD対話モジュール2106に命令し得る。説明するように、IPS102のコンテンツ配信モジュール316は、装置側増分更新モジュール2110に対して、独立的ではあるが補助的方式で、増分更新動作を処理するサーバ側増分更新モジュールを含む。
図22は、装置のタスクリスト処理モジュールの動作を説明する手順2200をフローチャート形態で示す。
ブロック2202において、TPH受信モジュール2102は、任意選択で電話の呼び出し音の形態で、タスクリストサーバモジュール314から通知メッセージを受信する。ダウンロードプロセスは、他のイベントによっても開始し得る。例えば、プロセスは、「新アイテムを確認」コマンド(例えば、1つ以上の装置メニュー経由で利用可能になる)の起動に応答して、開始し得る。プロセスは、ユーザ装置104の無線に(電源切断状態から)電源を入れることによっても開始し得る。プロセスは、ワイヤレスサービスが利用不可能であった場所から、利用可能な地理的場所にユーザ装置104が入る、等によっても開始し得る。
ブロック2204において、通知メッセージに応答して、ユーザ装置は適切な電力状態に移る(まだ適切な状態でなかった場合)。リストサーバ対話モジュール2104は、次に、タスクリストサーバモジュール314によって維持されたタスクキューから、n件のエントリを要求して受信する。
ブロック2206で、CD対話モジュール2106は、n件のエントリによって特定されるアイテムを要求する。
ブロック2208において、CD対話モジュール2106は、ヒントと共に、アイテム(ダウンロードが成功した場合)を受信する。第1のヒントは、ユーザ装置104に、IPS102で利用可能なアイテムのインデックスを通知する。第2のヒントは、ユーザ装置に、バックアップ注釈がIPS102で利用可能であることを通知する。第1および第2のヒントは、インデックスおよび/またはバックアップ注釈がそれぞれ利用可能ではないことを示すために使用し得る。
ブロック2210において、CD対話モジュール2106は、任意選択で補助情報をダウンロードする(適切だと判断した場合)。このような追加情報は、検索インデックス情報と注釈情報から成る。
ブロック2212において、CD対話モジュール2106は、読み込んだアイテムと補助情報を装置メモリ336および/または他の何らかの格納場所に保管する。
ブロック2214において、リストサーバ対話モジュール2104は、タスクリストサーバモジュール314に、アイテムのダウンロードが成功したことを通知するので、タスクリストサーバモジュール314は、対応するエントリをタスクキューから削除することが可能になる。
図22は、動作2206〜2214が、例えば、複数のアイテムを事実上ダウンロードして、統合プロセスとして他の動作を実行することによって、一括様式で実行され得ることを示す。別の実施形態は、n件のエントリのリストをブロック2204で受信した後、ユーザ装置104は、リストの第1のエントリに対して動作2206〜2214を実行してから、リストの第2のエントリに対して動作2206〜2214を実行する等、ユーザ装置104がn件のエントリの全てをプロセスするまで、実行し得る。
B.4.例示的なコンテンツ配信モジュール
B.4.a.コンテンツ配信モジュールの概要
図23は、サーバ側コンテンツ配信モジュール316に関して追加の詳細を提供する。サーバ側コンテンツ配信モジュール316は、要求後にユーザ装置104にアイテムを配信することに部分的に関連する多数の機能を実行する。
まず、コンテンツ配信モジュール316は、ダウンロードモジュール2302を含む。ダウンロードモジュール2302は、CD対話モジュール2106と協働して、このモジュール2106からアイテムに対する要求を受信し、可能な場合は、要求されたアイテムをCD対話モジュール2106に配信する。ダウンロードモジュール2302は、コンテンツストア308から、要求されたアイテムを読み込む。ダウンロードモジュール2302は、インデックスストア1106と注釈ストア1116から補助情報も読み込み得る。インデックスストア1106は、要求されているアイテムに対するインデックス(存在する場合)を保管する。注釈ストア1116は、要求されているアイテムに対する注釈(存在する場合)を保管する。
ダウンロードモジュール2302は、デルタ情報ストア2306からデルタ情報読み込む増分ダウンロードモジュールを含み得る。ダウンロードモジュール2302の目的は、可能な場合、要求されたコンテンツの完全バージョンではなく、要求されたコンテンツのデルタバージョンをダウンロードすることである。要求されたコンテンツのデルタバージョンは、要求されたコンテンツの装置側バージョンと、要求されたコンテンツの現在のバージョンとの違いに対応する。より具体的には、デルタ情報ストア2306は、多様なデルタファイルを提供し、それぞれのファイルは、要求されたコンテンツの装置側となる可能性があるバージョンと要求されたコンテンツの現在のバージョンとの違いに対応する(現在のバージョンと考えられる内容は、各新しいバージョンの受信によって変化する)。一般的に、ダウンロードモジュール2302は、要求されたコンテンツのコンテンツ全体ではなく、デルタバージョン(デルタ情報ストア2306のデルタファイルの集合から選択された)を転送して、IPS102からユーザ装置104に送信される情報量を削減しようとする。したがって、図23の説明を必要以上に複雑化させないために、増分更新プロセスの詳細は、説明の後半で提供する。
コンテンツ配信モジュール316のいくつかのモジュールは、多様なそれぞれの機能でダウンロードモジュール2302をサポートする。例えば、コンテンツ配信モジュール316は、ヒント提供モジュール2308を含む。ヒント提供モジュール2308は、特定の要求されたアイテムに対するインデックスがインデックスストア1106に存在するかどうかを特定するヒントを準備して転送する。ヒント提供モジュール2308は、特定の要求されたアイテムに対するバックアップ注釈が注釈ストア1116に存在するかどうかを特定するヒントも準備して転送する。各ヒントは、ブール式のYesとNoタイプのフィールド、または他の何らかのフォーマットで表現することができる。ヒント提供モジュール2308は、ダウンロードモジュール2302によって提供されたアイテムと共にヒントを送信し得る。
コンテンツ配信モジュール316は、注釈フォーマットモジュール2310も含む。注釈ストア116は、バックアップ注釈を一般的な形態で注釈ストア1116に保管し得る。バックアップ注釈が存在し、ユーザ装置104がこれらの注釈を要求すると想定すると、注釈フォーマットモジュール2310は、バックアップ注釈をその一般的な形態から、電子書籍アイテム自体のフォーマット等、対応するアイテム自体のフォーマットとの互換性がある形態に変換し得る。次に、ダウンロードモジュール2302は、ユーザ装置に所望のフォーマットで注釈を転送し得る。
1つの実施形態において、注釈ストア116は、上記で特定した注釈の全てのタイプを完全に記述する。別の例示的な実施形態において、注釈ストア1116は、注釈の場所とユーザメモのコンテンツだけを保管する。この事例においては、注釈ストア1116は、ハイライト型やクリップ型の注釈に関連付けられた実際の引用を保管し得ない。1つの実施形態では、注釈フォーマットモジュール2310は、注釈の保管場所に基づいて引用を要求するためにコンテンツストア308に問い合わせを実行し得る。これによって、システムは、ハイライト型とクリップ型の注釈を再構成することが可能になる。
コンテンツ配信モジュール316は、暗号化モジュール2312も含む。暗号化モジュール2312は、任意選択で、特定のユーザに対してユーザ装置104に配信されるアイテムを暗号化し得る。これは、コンテンツストア308からアイテムを受信するステップと、デジタル著作権管理(DRM)および/または他の保護関連処理をアイテムのヘッダに適用するステップと、を含み得る。暗号化モジュール2312は、暗号化関連処理をアイテムに適用する前に、アイテムのコピー全体をメモリに格納する必要はない。つまり、暗号化モジュール2312は、ユーザ装置にアイテムをストリーム様式で出力し得、必要に応じてアイテムに部分的に暗号化を適用する。1つの事例において、暗号化モジュール2312は、配信する全てのアイテムに暗号化を適用する。別の事例において、暗号化モジュール2312は、一部のアイテム(電子書籍、サブスクリプション関連アイテム等のような)には暗号化を適用するが、他のアイテム(個人アイテムやIPS生成メッセージ等のような)には適用しない。
コンテンツ配信モジュール316は、個人化モジュール2314も含む。個人化モジュール2314は、ユーザに配信される前にアイテムに個人情報を挿入し得る。例えば、アイテムは1つ以上のプレースホルダーフィールドを含み得る。個人化モジュール2314は、プレースホルダーフィールドに、ユーザの名前等のような個人情報を入力し得る。
コンテンツ配信モジュール316は、メタデータ注入モジュール2316も含む。名前が示すように、メタデータ注入モジュール2316は、ユーザに送信される前にアイテムにメタデータを挿入する。メタデータは、アイテムの作成者の名前を含み得る。後に記述するように、コンテンツ管理モジュール342は、1つ以上のユーザインタフェースページでこの名前情報をユーザに表示し得る。メタデータは、アイテムのテキストが開始する場所を特定する情報も含み得る。この場所情報によって、ユーザ装置104によって提供される1つ以上のメニューを経由して起動され得る「先頭へ移動」機能が有効になる。メタデータは、アイテムのカスタムタイトルも含み得る。このメタデータによって、コンテンツ配信モジュール316は、1つ以上のページに、「Thank You,John(ジョンさん、ありがとうございました)」等の個人化したメッセージと共にアイテムを表示することが可能になる。最後に説明した機能は、上記の個人化モジュール2314の役割と重複する。
アイテムに注入されたメタデータは、アイテムを特定するためにマーチャントストアモジュール318によって使用される固有のID番号等、アイテムの識別情報も含み得る。より具体的には、1つの例示的実施形態において、コンテンツ受信システム302がコンテンツを受信して処理する場合、ID番号をコンテンツストア308のアイテム自体には結合しない。コンテンツ受信システム302は、IPS102のどこか別の場所にID情報を保管する。特定アイテムの配信時、メタデータ注入モジュール2316は、アイテムにそのID番号を関連付けて、この情報の組み合わせをパッケージとして送信し得る。例えば、メタデータ注入モジュール2316は、配信前にアイテムのヘッダにID情報を挿入し得る。
1つの事例においては、暗号化モジュール2312とメタデータ注入モジュール2316(および/または他のモジュール)は、個別の動作として順次に動作し得る。別の事例において、暗号化モジュール2312とメタデータ注入モジュール2316(および/または他のモジュール)は、概して単一の統合動作として動作し得る。
コンテンツ配信モジュール316は、認証モジュール2318も含む。認証モジュール2318は、要求しているアイテムを受信する権利がユーザにあるかどうかを決定する。認証モジュール2318は、ユーザが要求しているコンテンツに対して適切な支払をしたかどうかを示す情報等、決定を行うために認証情報の1つ以上のフィールドに対する参照を実行し得る。上記に説明したように、電子書籍アイテムや他のアラカルト選択の場合、認証モジュール2318は、メディアライブラリモジュール324と対話し、ユーザがアイテムを購入したかどうか(または、受信する正当な権利があるかどうか)を決定し得る。サブスクリプション1件に提供されるサブスクリプション関連アイテムの場合、認証モジュール2318は、サブスクリプションモジュール310と対話し、ユーザが特定のサブスクリプションの号を受信するように概して認証されているかどうかを決定し得る(例えば、アイテム毎の認証問い合わせを行うことなく)。
コンテンツ配信モジュール316は、ダウンロード制限モジュール2320も含む。ダウンロード制限モジュール2320は、認証モジュールの一部として、または個別のモジュールとして実現され得る。ダウンロード制限モデル2320は、1つの例示的事例においては、5台の装置等、アイテムをダウンロードする装置の最大数を任意選択で制限し得る。
上記に列挙したモジュールのリストは、例であって、コンテンツ配信モジュール316によって実現される機能のタイプを包括するものではない。「他のモジュール」2322というラベルによって示すように、コンテンツ配信モジュール316は、追加の動作を実行し得る。さらに、一部の実施形態では、コンテンツ配信モジュール316は、図23に特定したモジュールのうちの1つ以上を省略し得る。
図24は、コンテンツ配信モジュール316の動作の1つの例示的な方式をフローチャート形式で説明する手順2400を示す。図24に図説した動作の順序は、多様な方式で変更され得る。さらに、図24に示した1つ以上のブロックは、省略され得る。さらに、1つ以上の動作は同時に実行され得、この場合、図24は、これらの機能の説明をわかりやすくするために、これらの機能を個別の動作として図説する。
ブロック2402において、コンテンツ配信モジュール316は、1つ以上のアイテムに対する要求をタスクリスト処理モジュール334から受信する。説明をわかりやすくするために、フローチャートは、ユーザ装置104は単一のアイテムを要求したと想定する。
ブロック2404において、コンテンツ配信モジュール316は、例えば、上記に説明したように、認証モジュール2318とダウンロード制限モジュール2320に関して、多様な認証関連動作を実行する。
ブロック2406では、コンテンツ配信モジュール316は、特定されたアイテムをサーバコンテンツストア308から読み込む。
ブロック2408において、コンテンツ配信モジュール316は、ユーザの名前をアイテムのプレースホルダーフィールドに挿入する等して、任意選択でアイテムを個人化し得る。
ブロック2410において、コンテンツ配信モジュール316は、識別番号をアイテムに割り当て得る、および/または他のメタデータをアイテムに注入し得る。
ブロック2412において、コンテンツ配信モジュール316は、任意選択で、特定のユーザに配信する各アイテムのヘッダを暗号化し得る。上記に説明したように、コンテンツ配信モジュール316は、アイテム全体をメモリに格納する必要なく、アイテムに暗号を適用し得る。
ブロック2414において、コンテンツ配信モジュール316は、準備したアイテムをユーザ装置104に転送し得る。アイテムには、IPS102がアイテムのインデックスおよびアイテムのバックアップ注釈を維持するかどうかをそれぞれ説明するヒントが付随し得る。
ブロック2416において、コンテンツ配信モジュール316は、サーバ側インデックスに対する要求および/またはバックアップ注釈に対する要求等、補助情報に対する要求を受信し得る。
ブロック2418において、コンテンツ配信モジュール316は、準備した補助情報をユーザ装置104に転送し得る。
ブロック2410において、プロセスは、識別子をアイテムに割り当て、さらに他のメタデータを注入し得る。
図25は、ユーザ装置104がアイテムを受信時に処理し得る1つの方式を説明する例示的手順2500を示す。
ブロック2502において、ユーザ装置104は、要求したアイテムを受信する。アイテムは、特定のタイプのコンテンツに対応し、電子書籍アイテム、サブスクリプション関連アイテム、ユーザのクエリに対する一連の応答等であり得る。また、アイテムは、キーとも称される、1つ以上の識別番号によっても表現され得る。1つの事例においては、サブスクリプション関連アイテムの各版または号には、固有の識別番号が割り当てられる。
ブロック2504において、ユーザ装置104は、アイテムのタイプおよびキー(例えば、識別番号)が、ユーザ装置104によって現在保管されているアイテムと同じであるかどうかを決定する。同じである場合、電子書籍アイテムやサブスクリプション関連アイテムの場合、これは、ユーザ装置は、現在、既にプロセスされているアイテムと完全に冗長なコピーを受信していることを意味する。フィードの場合には、これは、ユーザ装置104は、少なくとも新しいバージョンのフィードを受信しているが、これは、これまでのバージョンのフィードに関して、1つ以上の部分を追加および/または省略し得る。受信したフィードのバージョンを識別するには、バージョン識別を使用され得る。
ブロック2506において、アイテムが冗長であるとみなされる場合、ユーザ装置104は、新しく受信したアイテムと、同じタイプとキーを有するこれまでに保管したアイテムを統一し、これによって、このエントリに対して単一のレコードだけを作成する。
ブロック2508で、アイテムが本当には冗長であるとみなされない場合、ユーザ装置は新しく受信したアイテムを個別の新しいアイテムとして保管し得る。1つの実施形態においては、この時点で、ユーザ装置104は、受信したヒントを確認し、適切な補助情報(注釈バックアップ情報、および/またはインデックス情報等)をダウンロードし得る。
B.4.b.増分更新に対する例示的なアプローチ
図26〜29は、増分更新を実施するための手順を説明する。この手順の一般的な目的は、可能な場合、要求したアイテムの完全バージョンではなく、要求したアイテムのデルタバージョンをユーザ装置に提供することである。要求したアイテムのデルタバージョンは、装置によって既に処理されたコンテンツのバージョン(例えば、「装置バージョン」)とコンテンツの現在のバージョンとの違いを表す。デルタバージョンを受信すると、装置は、アイテムのデルタバージョンを既存の以前の(装置)バージョンに統合(例えば、パッチ)することによって、要求したアイテムの完全バージョンを作成する。手順は、要求したアイテムのデルタバージョンをユーザ装置104に提供して、IPS102からユーザ装置104に送信されている情報量、およびこれに伴うコスト(部分的に、ワイヤレス通信コストに関する)の削減に役立つ。
増分更新動作は、IPS102とユーザ装置104の両方で発生する。これらの2つの動作は、互いに独立して発生するが、これらの動作は、互いに補完し合う。図27と28は、IPS102の観点から増分更新手順を説明し、図29は、ユーザ装置104の観点から増分更新動作を説明する。
図26から開始すると、この図は、増分更新を実施することが適切になり得る、1つの事例の概要を示す。この場合、ユーザは、フィードを受信するサブスクリプションを有する。フィードとは、既定の時間(例えば、毎時)または他のトリガイベントに応答してユーザに提供される情報部分の一群に対応する。例えば、主要なニュース記事を提供するフィードの事例を検討する。このようなフィードは、毎時、上位10位までのニュース記事のリストを転送し得る。n時の一群が所定の参照コンテンツを有する場合、n+1時の一群は、n時のコンテンツの後の「バージョン」と見なされ得る。
フィードの1つのバージョンは、フィードの直前のバージョンと共通事項を共有する1つ以上の部分を含み得る。ニュースフィードの事例では、特定の日の午後2時の上位10位のニュース記事は、午後1時に特定されたニュース記事と同じニュース記事を多数含み得る。さらに、時によると、ニュース記事の全てが同じであり得る。この状況においては、午後2時のニュースフィードのデルタバージョンだけをダウンロードすることが望ましい。ニュースフィードのデルタバージョンは、午後1時のニュースフィードとは異なる午後2時のニュースフィードの部分だけを特定する。コンテンツの現在のバージョンは、少なくとも2つの点でコンテンツの前のバージョンとは異なり得る。第1に、コンテンツの現在のバージョンは、コンテンツの前のバージョンには存在しない1つ以上の部分を追加し得る。第2に、コンテンツの現在のバージョンは、これに加えてまたは代替として、コンテンツの前のバージョンに存在した1つ以上の部分を削除し得る。
図26は、バージョンV1からバージョンV4まで、順にコンテンツの変化を表す。バージョンV4は、最新時点でのコンテンツの現在のバージョンを表す。バージョンV1では、コンテンツは、基本部分A1と補助部分A2を含む。バージョンV2では、コンテンツは、基本部分A1と補助部分A2およびA3を含む。バージョンV3では、コンテンツは、基本部分A1と補助部分A2、A3およびA4を含む。最後にバージョンV4では、コンテンツは基本部分A1と補助部分A3およびA4,さらに、バージョンV3では存在したが今は省略された部分A2を含む。
増分更新手順の1つの実施形態によって採用される例示的な戦略は、現在のバージョン(例えば、V4)とそれぞれ前のバージョンとの間の違いを表すデルタファイルを前もって編集することである。例えば、第1のデルタファイルは、バージョンV4とバージョンV3との違いを表す。このデルタファイルは、部分A2が削除されたことを示す部分のみから構成される。第2のデルタファイルは、バージョンV4とバージョンV2との違いを表す。このデルタファイルは、部分A2を削除する指示と共に、部分A4に含まれる情報(バージョンV2に対して追加された)とから構成される。第3のデルタファイルは、バージョンV4とバージョンV1との違いを表す。このデルタファイルは、部分A2を削除する指示と共に、部分A3とA4に対応する情報(バージョンV1に対して追加された)とから構成される。デルタファイルには、省略された部分は作成する必要がない。省略部分への参照で十分である。
増分更新手順のアプリケーション段階では、コンテンツ配信モジュール316は、ユーザが要求しているアイテムのIDを決定し、バージョンV3、バージョンV2、バージョンV1等のように、ユーザが要求されたコンテンツの前のバージョンを有しているかどうかを決定する。1つの事例では、ユーザ装置104は、コンテンツ配信モジュール316に、IPS102に送信する要求に含まれたヘッダ情報に所有するコンテンツのバージョンを伝え得るが、これに限定されない。コンテンツ配信モジュール316は、まず、要求されたコンテンツの現在のバージョンと要求されたコンテンツの装置バージョンとの違いを表すデルタファイルにアクセスを試行する。このデルタファイルが取得され得る場合、そして、ファイル全体ではなく、デルタファイルを送信するほうが効率的であると決定される場合、コンテンツ配信モジュール316は、要求されたアイテム全体ではなく、デルタファイルを送信する。そうでない場合、コンテンツ配信モジュール316は、要求されたアイテム全体を送信する。説明したように、ユーザ装置104は、並行分析を実施し、まず、デルタファイルを要求する。ユーザ装置104が手順中にデルタファイルを受信せず、処理が成功しない場合、要求したアイテムの完全バージョンを求め得る。
図27〜29は、上記の説明をフローチャート形態で正式に表す。図27から開始すると、この図面は、デルタファイルを形成する手順2700を図説する。この動作は、バックグラウンドプロセスとして、IPSのコンテンツ配信モジュール316によって、特に、図23で示した増分更新モジュール2304によって実行され得る。
ブロック2702において、コンテンツ配信モジュール316は、新しい版のフィード、新しい版の新聞アイテム等、新しいバージョンのコンテンツを受信したことを記録する。
ブロック2704で、コンテンツ配信モジュール316は、一連のデルタファイルを形成し、現在のバージョンVnとこれまでの一連のバージョン、Vn-1、Vn-2、Vn-3等との違いを表す。コンテンツ配信モジュール316は、演算するデルタファイルの数を決定するために、多様なルールを適用し得る。1つの事例においては、配信モジュール316は、デルタファイルの数の上限を既定数にする。要求されたアイテムを最も効率的な方式でユーザにダウンロードすることが目的であることを思い起こされたい。したがって、別の事例において、配信モジュール316は、デルタファイルが大きくなりすぎる、および/または複雑になりすぎて、デルタファイルではなく、ファイル全体をダウンロードしたほうが効率的な場合があると決定すると、デルタファイルの形成を停止し得る。コンテンツ配信モジュール316は、デルタファイルストア2306にデルタファイルを保管し得る(図23に表示)。デルタファイルは、対応する完全なアイテムとともに保管されるか、そうでなければ、参照情報によって対応する完全なアイテムにリンクされ得る。
ブロック2706では、コンテンツ配信モジュール316は、関連性がなくなった前の反復からのいかなるデルタファイルも削除し得る。例えば、手順の前の反復においては、バージョンVn-1はアイテムの最新バージョンであったので、デルタファイルの全ては、このバージョンに対して編集された。1つの実施形態は、コンテンツ配信モジュール316は、ユーザは要求したアイテムの最新バージョンを希望するという想定に基づいて、これらの状態のデルタファイル全てを削除し得る。
図28は、増分更新手順のアプリケーション段階を表すが、この中で、ユーザ装置は、要求したコンテンツに対応する、アイテムの特定の要求を行う。コンテンツ配信モジュール316の増分更新モジュール2394は、手順2800を実行するために使用され得る。
ブロック2802において、コンテンツ配信モジュール316は、アイテムに対する要求を受信する。コンテンツ配信モジュール316は、ユーザ装置104は、ユーザ装置のHTTP要求のヘッダからバージョン情報を読み取ること等、多様なメカニズムを介して、要求したアイテムの以前のバージョンVkを有しているかどうかを決定し得る。
ブロック2804で、コンテンツ配信モジュール316は、現在のバージョンVnと装置のバージョンVkとの違いに対応するデルタファイルにアクセスを試みる。1つの事例においては、コンテンツ配信モジュール316は、3回等(これに限定されない)、このデルタファイルへのアクセスをn回試行し得る。
コンテンツ配信モジュール316がデルタファイルのアクセスに成功すると(ブロック2806で決定するように)、完全バージョンがない代わりにデルタファイルを提供し得る。すなわち、ブロック2810で、コンテンツ配信モジュールは、完全アイテムではなく、デルタファイルを送信する。そうでなければ、ブロック2812で、コンテンツ配信モジュール316はアイテム全体を送信する。
上記で説明した動作の方式は、図27のデルタ形成手順2700は、完全バージョンではなく、デルタファイルを送信するほうが効率が高いと思える場合のみに、デルタファイルを保管するように動作する、という想定に基づく。この事例においては、手順2800が対応するデルタファイルを発見しない場合、速やかに完全バージョンにアクセスしてダウンロードすることによって、処理を進める。他の事例においては、完全バージョンではなくデルタファイルを送信するほうが効率が高いかどうかを決定するステップは、例えば、任意選択の決定ブロック2808によって示されるように、図28のダウンロードプロセスの一部として実行され得る。デルタか完全バージョンか決定がどの岐路で行われるかに関係なく、この決定は、いくつかの因子に基づき得る。
まず、アイテム全体に対するデルタファイルのサイズが関係する。デルタファイルがアイテム全体より大きい場合、アイテム全体がなくデルタファイルを送信することは意味を成さない。この場合、コンテンツ配信モジュール316は、ファイル全体を送信すると決定する。
第2に、決定プロセスは、デルタファイルと比較すると、アイテム全体のほうが圧縮(および/または暗号化)に適し得るという事実を考慮し得る。このように、関連サイズを決定する場合、決定プロセスは、アイテム全体の圧縮サイズに対してデルタファイルの圧縮サイズを確認し得る。
第3に、デルタファイルをユーザ装置の既存バージョンにパッチするために、およびデルタファイル(アイテム全体ではなく)の処理に固有に関連する他の動作を実行するために必要な有限量のアイテムが存在する。決定プロセスは、アイテム全体に対してデルタファイルを送信するほうが効率性が高いかどうかを決定する場合に、これらの時間差がある考慮事項を考慮するように選択し得る。
図29は、ユーザ装置104によって実行される補助的な増分更新動作を説明する手順2900を示す。図21の増分更新モジュール2110とエラー処置モジュール2112は、この手順2900を実行するために使用され得る。
ブロック2902において、ユーザ装置104は、デフォルトのルールとして、要求したアイテムのデルタファイルバージョンにアクセスを試みる。成功すると、ユーザ装置104は、デルタファイルを現在所有するコンテンツのバージョンにパッチを試みる。ユーザ装置104は、任意選択で、既定数のn回この動作を試行し得る。
ブロック2904において、ユーザ装置104は、要求したアイテムをデルタファイルのパッチとして取得することに成功したかどうかを決定する。成功した場合、プロセスは終了する。成功していない場合、ブロック2906において、ユーザ装置104は、アイテム全体を要求し得る。ユーザ装置106は、デルタファイルをダウンロードするか、アイテム全体をダウンロードするかを決定する場合に、他の考慮事項(成功/失敗タイプの考慮事項ではなく、またはこれに加えて)を適用し得る。
繰り返しになるが、サーバ側コンテンツ配信モジュール316は、独自の増分更新動作(手順2900による)を実行するユーザ装置104と平行して増分更新動作(手順2800による)を実行し得る。IPS102またはユーザ装置104のいずれかは、要求したアイテムのデルタファイルバージョンを回収しようとする試みを停止することを決定し得る。
B.5.配信管理機能
B.5.a.配信管理機能の概要
上記で展開した例では、IPS102は、アイテムを受信し、エントリを適切なタスクキューに追加してから(サブスクリプション関連アイテムの場合)、TPH信号を送信して、エントリにアクセスしてから対応するアイテムをダウンロードするように、ユーザ装置に通知することによって、作動する。このセクションでは、この一般的なプロセスの効率性を高め、および/または他の目標を達成するように設計された多様な管理機能を説明する。
図30は、一群のコンテンツ配信管理機能300を示す。第1の機能は、確実なフルフィルメント機能3002に対応する。確実なフルフィルメント機能3002は、ユーザ装置に配信されるアイテムが準備される時点より前に、配信関連処理を実行することによって動作する。このような準備処理は、配信されるアイテムが準備される時点の前に、エントリを装置のタスクキューに追加するステップを含む。
第2の機能は、TPHスケジュール機能3004に対応する。TPHスケジュール機能3004は、一般的に、ユーザ装置104によって消費される電力を削減するように、TPH信号の送信をスケジュールしようと試みる。より具体的には、ユーザ装置が活動状態に復帰し、TPH信号に応答すること(例えば、タスクキューからエントリを受信してアイテムをダウンロードすること等)は、比較的コストが高い(電力消費の観点から)。1つの代表的事例では、このようなイベントは、バッテリ寿命全体の約1パーセントを消費する。この状況に対応するため、TPHスケジュール機能3004は、タスクキューに報告可能な追加が行われるたびにTPH信号を送信せず、代替として、複数の報告可能なイベントをまとめて、単一のTPH信号を送信し得る。TPHスケジュール機能3004は、以下に詳細を説明するように、いつおよびどのようにTPH信号を送信するかを決定する場合に、他の考慮事項を適用する。1つの実施形態では、TPHスケジュール機能3004は、通知モジュール1808の機能として実現され得る。
第3の機能は、新聞配達機能とも称される遅延通知機能3006に対応する。遅延通知機能3006は、IPS102への発行元からのサブスクリプション関連アイテムの提供が遅れていることを決定する。これに応答して、遅延通知機能3006は、アイテムの全ての受信者を特定し得る。遅延通知機能3006は、個人化した遅延通知を受信者に準備および送信し得る。
第4の特徴は、サブスクリプション開始機能3008に対応する。サブスクリプション開始機能は、まず、ユーザが装置に電源を入れてIPS102に問い合わせるまで、サブスクリプションの開始を行わない。この対策は、有料ベースと無料両方のサブスクリプションに適用し得る。
上記に列挙したモジュールのリストは、例であって、IPS102によって実行される機能のタイプを包括するものではない。「他の調整機能」3010という見出しが示すように、処理装置102は、追加の管理機能を含み得る。IPS102は、図30に示した特徴のうちの1つ以上を省略または無効にし得る。
以下のサブセクションで各機能を詳細に説明する。
B.5.b例示的な確実なフルフィルメント機能
図31は、上記で導入した確実なフルフィルメント機能3002を実現するための手順3100を示すフローチャートである。
ブロック3102で、確実なフルフィルメント機能3002は、確実なフルフィルメント処理を開始するトリガイベントを受信する。イベントは、サブスクリプション関連アイテム等の受信に対応し得る。
ブロック3104において、確実なフルフィルメント機能3002は、アイテムを受信するように登録した1つ以上の装置にTPH信号を送信するための準備ステップにおいて準備処理を実行する。1つの事例において、確実なフルフィルメント機能3002は、アイテムを受信するようにスケジュールした装置に関連するタスクキューに、エントリを保管し得る。確実なフルフィルメント機能3002がタスクキューにエントリを追加する時点で、コンテンツ受信モジュール302はアイテムを変換中であり得るので、この時点で、アイテムは、まだユーザ装置への転送には準備されていない。キューにエントリを追加する際、タスクリストサーバモジュール314が準備できていない状態でTPH信号を送信しないように、エントリは、送信準備がまだできていないことを示すフラグにタグ付けされ得る。このメカニズムは、任意選択で、ダウンロードプロセスの一部としてエントリを要求するときに装置が確認するエントリのリストからもエントリを効果的に隠し得る。
ブロック3106において、確実なフルフィルメント機能3002によって、アイテムの送信準備ができると、TPH信号を受信者に送信することが可能になる。上記のサブスクリプション関連アイテムの場合には、確実なフルフィルメント機能3002は、コンテンツ受信システム302がコンテンツの変換を終了して、コンテンツストア308に保管するタイミングを決定する。この時点で、確実なフルフィルメント機能3002は、TPH信号をユーザ装置に送信できることを示すように、タスクキュー内のエントリの状況を変更し得る。
確実なフルフィルメント機能3002は、他のタイプの準備動作を実行し得る。一般的に、これらの動作は他の動作と並行して実施されるので、および/またはこれ以外にはIPS102の一部はアイドルまたは完全に利用されていないので、準備動作によってアイテムの配信が早まる。
B.5.c例示的な遅延通知機能
図31は、上記で導入した遅延通知機能3006を実現するための手順3200を示すフローチャートである。手順3200は、特定のサブスクリプション関連アイテムに対して説明するが、手順3200は、サブスクリプション関連アイテムおよび/または他のタイプのアイテムの一群に対してまとめて反復され得る。
ブロック3202において、遅延通知機能3006は、発行元からIPS102へのサブスクリプション関連アイテムの提供が遅れていると決定する。または、遅延通知機能3006は、アイテムに関して、遅れについて他のなんらかの原因があると決定し得る。遅延通知機能3006は、アイテムを通常受信する時間に関する情報に基づいて、この決定を行い得る。このような情報は、手動で入力したタイミング情報によって表現され得る。遅延通知機能3006は、アイテムの予想受信時間を超えて既定時間が経過したと決定する場合、アイテムが遅れていると特定し得る。遅延通知機能3006は、IPS102の管理者から、発行元から等、多様なソースからアイテムの予想受信時間に関する情報を集め得る。代替として、またはこれに加えて、遅延通知機能3006は、アイテムが受信されてプロセスされる典型的なタイミングを反映する実証的規範を収集し得る。遅延の決定を行う場合、遅延通知機能3006は、ユーザ装置がコンテンツを受信するタイムゾーンを考慮し得る。例えば、第1の遅延閾値は、米国の東海岸でユーザ装置を動作しているユーザに適用し得、第2の遅延閾値は、西海岸で装置を動作しているユーザに適用し得る。閾値の差は、西海岸に比較すると東海岸では、遅延配信に対応する時間が短いという事実を説明し得る。より具体的には、東海岸の午前4時に通常配達される新聞を想定する。配信の遅延は、西海岸のユーザよりも東海岸のユーザにとってより重大な関心事となる。なぜなら、東海岸のユーザは西海岸のユーザより前に起床し、朝食時に新聞を読むことを期待しているからである。
ブロック3204において、アイテムが遅れると決定されると想定すると、遅延通知機能3006は、このアイテムを受信する予定の各ユーザに遅延通知を送信し得る。遅延通知機能3006は、アイテムを受信する予定のユーザのセットを決定するために、サブスクリプションモジュール310に問い合わせ得る。遅延通知機能は、任意選択で、一般的な遅延通知メッセージのプレースホルダーフィールドにユーザの名前を挿入する等によって、ユーザに提供される遅延通知を個人化し得る。遅延通知メッセージは、遅延発行の名前、遅延発行の日付等を特定するようにカスタム化し得る。
ブロック3206で、遅延通知機能3006は、遅延通知を適切なユーザに送信する。遅延通知機能3006は、遅延通知を適切な時刻に送信することによって、サブスクリプション加入者のそれぞれのタイムゾーンを考慮し得る。
1つの事例において、遅延通知機能3006は、例えば、上記のアイテムのなんらかの他のタイプのような文書として遅延通知を送信し得る。遅延通知機能3006は、GETタイプのエントリを適切なタスクキューに追加することによって、遅延通知を配信し得る。別の実施形態において、遅延通知機能3006は、タスクキューに特殊なコマンドを送信し得る。これらのコマンドは、コマンドの受信時にユーザ装置に適切なポップアップメッセージ等を表示するように指示し、アイテムが遅れて配信されることをユーザに知らせる。遅延配信モジュール3006は、任意選択で、アイテムの配信に続けて失敗すると、時間をずらせて一連の遅延メッセージを送信し得、各メッセージは、謝罪、改善等のような適切な深刻度を含む。
ブロック3208において、遅れた発行が配信される時(およびその場合)、遅延通知機能3006は、ユーザ装置から遅延通知アイテムを削除し得る(例えば、DELタイプコマンドを対応するタスクキュー経由でユーザ装置に送信することによる)。この対策によって、IPS102には、ユーザが装置を開いて配信されたアイテムとそのアイテムが遅れるという通知の両方を見るという混乱を防ぐ機会が与えられる。
B.5.d.例示的なテレフォンホーム(TPH)機能
図33は、上記で紹介したTPHスケジュール機能3004を実現するための手順3300を示すフローチャートである。TPHスケジュール機能3004の1つの例示的な目標は、TPH信号をスケジュールして、ユーザ装置の電源を入れる回数、TPH信号を受信する回数、エントリやアイテムをダウンロードする回数を減らすことであったことを思い起こされたい。TPHスケジュール機能3004は、部分的に、多様なルールに基づいて複数のTPH信号を単一のTPH信号にまとめることによって、および/またはTPH信号が送信されるタイミングを調整することによって、この結果を達成する。手順3300は、特定のユーザ装置に関連付けられた例示的なタスクキューに関して説明するが、ここで説明する動作は、複数のタスクキューおよび関連したユーザ装置に対して実行され得る。1つの実施形態では、TPHスケジュール機能3004は、通知モジュール1808の機能として実現され得る。
ブロック3302において、ユーザのタスクキューは少なくとも1つのエントリを含むと想定する。その場合、ブロック3302で、TPHスケジュール機能3004は、TPH信号をユーザ装置に送信すること、または少し後までこのようなメッセージを見送ることが適切かどうかを決定する。タスクリストサーバモジュール314は、このエントリに非送信状況のフラグを付けることによって、タスクキューのエントリに対するTPH信号の受信を見送り得る。この状況は、タスクリストサーバモジュール304がTPH信号を送信することを希望すると、変更され得る。
決定を行う場合、TPHスケジュール機能3004は、次の検討事項のいずれか1つ、または次の検討事項のなんらかの組み合わせに依存し得る。検討事項の多くは、他の検討事項と重なる態様を含む。
TPHスケジュール機能3004は、いつTPH信号を送信するかを決定する際、時刻情報等、1つ以上の時間関連因子を検討し得る。例えば、TPHスケジュール機能3004は、ユーザが日中に装置を既に使用している可能性が高い場合は、夜間ではなく日中の時間にTPH信号を送信する傾向が高くなり得る。この場合、装置の電源は既に入っているので、TPH信号の送信によって、装置の電源が入り得ない。一方で、TPHスケジュール機能は、日中ではなく夜間にワイヤレス通信を行うほうに顕著なコストの節約がある場合は、日中ではなく夜間にTPH信号を送信する傾向が高くなり得る。時間に関する考慮事項の別の適用では、TPHスケジュール機能3004は、30分毎、1時間毎等のように、各t時間間隔に単独のTPH信号を送信するように構成され得る(t間隔で少なくとも1つのTPH送信イベントが登録されている場合)。
TPHスケジュール機能3004は、TPHアイテムをいつ送信するかを決定する場合に、アイテムのタイプを重要であると考慮し得る。例えば、電子書籍を明示的に購入するユーザは、アイテムに対する明示的な要求を行い、さらにこの明示的な動作は最近のイベントであるため、この自分が購入した後すぐにこのアイテムを受信することに比較的関心がおそらく高い。一方で、ジャーナルまたはブログの受信者は、ユーザがこの資料に積極的な関心を抱いたままであるという確固とした証拠は少ないため、利用可能になった直後にアイテムを受信することに対するこだわりは少ない場合がある。したがって、TPHスケジュール機能302は、ユーザが購入直後に電子書籍に対するTPHアイテムを送信し得る。しかし、TPHスケジュール機能3004は、サブスクリプション関連アイテムの自動受信後にTPH信号の送信を遅らせ得る。より一般的に言うと、TPHスケジュール機能3004は、アイテムのタイプに異なる優先度を割り当て得る。TPHスケジュール機能3004は、次に、TPH信号をどの程度早く送信するかを決定する場合の1つの因子として、タスクキューにおけるアイテムの優先度を考慮し得る。別の例を見ると、IPS102のアップグレード機能は、装置のタスクキューに、装置に命令付き更新をダウンロードするように指示するエントリを追加し得る。このエントリは、非常に優先度が高いアイテムとして指定され得、TPH信号を直ちに送信することを要求する。
TPHスケジュール機能3004は、いつTPH信号を送信するかを決定する場合に、エントリがタスクキューに保管される期間も考慮し得る。TPHスケジュール機能3004は、長過ぎる時間、TPH信号の送信を遅らせることを希望し得ない。
TPHスケジュール機能3004は、TPH信号をダウンロードするかどうかを決定する場合に、ユーザによって示された以前の動作も考慮し得る。より具体的には、1つの事例では、TPHスケジュール機能3304は、この動作は同様に特定のユーザに適用し得るという想定に基づいて、多数のユーザの集積動作を考慮し得る。別の事例においては、TPHスケジュール機能は、代替として、またはこれに加えて、特定のユーザの固有な動作を考慮し得る。1つの例を挙げると、特定のユーザは、ユーザの装置を1日のある時間に操作するが別の時間には操作しないというような動作の固有パターンを有し得る。TPHスケジュール機能3004は、ユーザが1日のうちで典型的に実施するタイプの動作においてパターンも特定し得る。これらの考慮事項に基づいて、TPHスケジュール機能3004は、ユーザが既に装置を使用しているので、装置の電源が入った状態で動作していることが予想される時間内にTPH信号を送り得る。別の例によると、ユーザは、集団で考慮すると一般的に、1日の特定の時間に特定のタイプのコンテンツを受信することを希望し得る。例えば、ユーザは、出勤前に新聞を読むことを希望し得る。この場合、TPHスケジュール機能3004は、午前5時前にTPHを送信しようと試し得るが、TPHスケジュール機能3004は、そうでなければ、ユーザが就寝していると思われる夜間にTPH信号を送信する必要はない。
TPHスケジュール機能3004は、装置104のユーザの現在の使用についての情報も収集し得る。例えば、TPHスケジュール機能3004は、ユーザが永久的な電源(AC電源コンセント等)にユーザ装置106を差し込んだと決定し得る。TPHスケジュール機能3004は、ユーザが装置104を非枯渇型電源に差し込んだと決定し得る場合、ユーザ装置にTPH信号を送ろうとする可能性が高い。TPHスケジュール機能3004は、ユーザ装置104のバッテリレベルを明らかにする情報も受信し得る。TPHスケジュール機能3004は、装置のバッテリ状態が低い場合、TPH信号の送信にはより消極的であり得る。
TPHスケジュール機能3004は、タスクキューに保管されるエントリの量も考慮し得る。TPHスケジュール機能3004は、ユーザのタスクキューが未報告のエントリでいっぱいになっている場合、TPH信号の送信にはより積極的であり得る。TPHスケジュール機能3004は、TPH信号動作の最近の速度も考慮し得る。
TPHスケジュール機能3004は、例えば、設定ページ等を経由してユーザによって入力される等、ユーザの明示的な設定詳細も考慮し得る。
TPHスケジュール機能3004は、サブスクリプション関連アイテムに対しては、ユーザがアイテムを購入したばかりかどうかも特定し得る。アイテムを購入したばかりのユーザは、期間を延長して号を定期的に受信しているユーザよりも、このアイテムの号の受信により熱心であり得る。
TPHスケジュール機能3004は、TPH信号を送信するタイミングを決定する場合に、ダウンロードするアイテムのサイズも考慮し得る。例えば、TPHスケジュール機能3004は、無線ダウンロード関連料金が低くなるような夜間に特定の大きなアイテムに対するTPH信号を送信することを選択し得る。
また他の考慮事項は、TPHスケジュール機能3004によって行われるTPHスケジュール決定に影響を持ち得る。関連点として、ユーザ装置104は、何らかの理由で装置の電源が入った等、多様なイベントに応答して(例えば、TPH信号によって問い合わせるように指示されていなくても)、タスクサーバモジュール314に独立的に問い合わせを行うように構成され得る。ユーザ装置は、次に、その時点で保留中であり得る、キューのいかなるエントリもダウンロードし得る。
ブロック3304において、TPHスケジュール機能3004は、TPH信号を送信するかどうかの最終決定を行う場合に、上記で特定した因子のうちの1つ以上の重要性を考慮する。環境が異なれば、これらの考慮事項に対して異なる重みを適用し得、どの考慮事項を他よりも優先し得るかに影響を与える。1つの事例においては、各ユーザは、TPH信号の送信に適用する重みも定義し得、したがって、上記で特定した多様な因子の相対的重要性を制御する。
ブロック3306においては、TPHスケジュール機能3004は、TPH信号を送信し、ユーザ装置にエントリを読み込み、エントリに関連して対応するアイテムをダウンロードするように指示する。
B.5.e.例示的なサブスクリプション開始機能
図34は、上記で導入したサブスクリプション開始機能3008を実現するための手順3400を示すフローチャートである。
ブロック3402では、サブスクリプション開始機能3008は、ユーザが新しいサブスクリプションを購入したと決定する。
ブロック3404で、サブスクリプション開始機能3008は、ユーザがサブスクリプション関連アイテムを実際にダウンロードし始めるまで、または、他の何らかの消費トリガに応答して、サブスクリプションの号または版の料金をユーザに課金することを遅らせる。この方策は、部分的に、ユーザに対する優遇措置である。
B.6.例示的なホーム提示モジュール
図4の文脈で導入したホーム提示モジュール408は、ユーザがユーザ装置104との対話を開始することができるホームページを提供する。図35は、ホームページ3502の1つの例示的な実施形態を提供する。
図35のホームページ3502は、電子書籍、オーディブック、個人アイテム、サブスクリプション関連アイテム等を含む、リーダ装置を使用してユーザが読み得る多様なアイテムのリストを示す。ホームページ3502の各エントリは、アイテムのタイトル、電子書籍型アイテムの著者等のような、アイテムに関する顕著な情報を含む。各エントリは、対応するアイテムを選択するためのガイドとして機能するセレクタ(ページ3502に右端に沿って)を含み、これによってアイテムを開いて表示する。特殊なグループ型セレクタ3502は、サブスクリプションに対応するアイテムを示す。このアイテムをクリックすることによって、ユーザは、サブスクリプション内で利用可能な号のリストを表示し得る。さらに、ホームページの各エントリは、進捗インジケータ3506のような進捗インジケータを含む。進捗インジケータ3506の点の数は、インジケータ全体の長さと相対的にユーザがアイテムをどこまで読み進んだかを示す。
ホームページ3502は、「表示とソート」選択アイテムも含む。このエントリをクリックすると、ユーザは、表示とソートメニュー(図示せず)を受信し得る。このメニューによって、ユーザは、ホームページ3502に表示するアイテムを選択するために使用するフィルタ条件を選択することが可能になる。ユーザは、ホームページ3502で表示されるアイテムの順序を管理するために使用するソート条件も選択し得る。
ホームページ3502は、メニューセレクタ3502も含む。メニューセレクタ3502を選択すると、ユーザ装置104は、図36に示したメニュー3602を提示するようになる。メニュー3602によって、ユーザは、ユーザ装置によって実施される多様な機能を移動して、特殊なタスクを実行することが可能になる。メニュー3602を経由して選択することができるこのような機能の1つが、設定オプション3604である。
図36に示した設定オプション3604を有効にすると、ユーザ装置104のユーザは、図37に示した設定ページ3702に移動する。設定ページによって、ユーザは装置に関連した多様な管理設定(アカウント名、装置名等のような)を変更できるとともに、装置の動作の方式を規定する多様な設定も変更可能になる。設定ページ3702は、追加アイテムを保管するために利用可能なストレージの量も明らかにする。
B.7.例示的なマーチャントストアモジュール
B.7.a.マーチャントストアモジュールの概要
図38は、図3の説明で導入したマーチャントストアモジュール318を示す。一言でいうと、マーチャントストアモジュール318によって、ユーザは、アイテムを検索、選択したアイテムを購入(またはそうでなければ入手)等が可能になる。ユーザは、ユーザ装置104によって提供されるストア対話モジュール344を経由して、マーチャントストアモジュール318と対話する。ユーザは、非ワイヤレス通信方式(例えば、電話またはケーブルモデム、DSLメカニズム等)を経由して、マーチャントストアモジュール318にアクセスするパーソナルコンピュータを使用することのように、1つ以上の代替メカニズムを経由することによっても、マーチャントストアモジュール318対話し得る。
マーチャントストアモジュール318は、アカウント管理およびセットアップモジュール3802を含む。このモジュール3802によって、ユーザは、ユーザアカウントをセットアップし、他の管理機能を実施することが可能になる。
マーチャントストアモジュール318は、ユーザ情報3804へのアクセスを含む、または有する。ユーザ情報3804は、ユーザに関する人口統計上の情報を提供し得る。ユーザ情報3804は、ユーザによって行われた購入前および他のタイプの選択に関する情報も提供し得る。
マーチャントストアモジュール318は、アイテムカタログ320も含み得る。アイテムカタログ320は、マーチャントストアモジュール318を使用して選択され得る、多様なアイテムの説明を含み得る。アイテムカタログ320の中のアイテムの説明は、アイテム詳細ページの形態を採り得る。
マーチャントストアモジュール318は、アイテムレビューおよび入手(IRA)機能3806を含み得る。IRA機能は、それ自体、カタログ検索および提示モジュール3808を含み得る。このモジュール3808によって、ユーザは、検索語を入力、閲覧カテゴリを表示する等によって、アイテムカタログ320内のアイテムをレビューすることが可能になる。IRA機能3806は、アイテム推奨モジュール3810も含む。IRA機能3806は、例えば、ユーザのこれまでの関心に基づいて(例えば、ユーザ情報ストア3804に反映されるように)、または、一般的に人気のあるアイテムに基づいて等、1つ以上の推奨アイテムをユーザに提示する。
IRA機能3806は、アイテム購入モジュール3810も含む。アイテム購入モジュール3812によって、ユーザは、ショッピングカートにアイテムを入れて、アイテムを購入(またはそうでなければ入手)することが可能になる。アイテム購入モジュール3810は、それ自体に、購入解除モジュール3814を含み得る。購入解除モジュールによって、ユーザは、以下で詳細を説明する方式でアイテムの購入を解除することが可能になる。アイテム購入モジュール3810は、仮想アカウントモジュール3816も含み得る。以下(セクションD)で詳細に説明するように、仮想アカウントモジュール3816によって、ユーザは、ユーザがユーザ装置を購入(または受け取るように手配)した後、この時点では、ユーザにはまだ特定のユーザ装置が割り当てられていない場合にも、アイテムの購入を行うことが可能になる。
IRA機能3806は、「他のストアモジュール」3818というラベルによって示されるように、更に追加のモジュールを含み得る。マーチャントストアモジュール318の他の実装は、図38に示した1つ以上のモジュールを省略し得る。
マーチャントストアモジュール318は、装置インタフェースモジュール3820を含み得る。装置インタフェースモジュール3820は、一般的に、サーバ側マーチャントストア318が装置側ストア対話モジュールと対話することを可能にする機能を含む。装置インタフェースモジュールは、マークアップ提示モジュール3820を含む。マークアップ提示モジュール3822は、一連のページ(例えば、提示ページ3824のような)をユーザに装置に提供する。ページは、どのようなマークアップ言語または他のどのようなフォーマットにも構築され得る。装置提示インタフェースモジュール3820は、装置応答処理モジュール3826も含み得る。装置応答処理モジュール3826は、マークアップ提示モジュール3822によって提供されるページと対話するユーザからの応答を受信する。例えば、ユーザは、マークアップ提示モジュール3822によって提供されるページ内のリンクを選択し得る。ユーザの選択は、HTTPプロトコルまたは他の何らかのプロトコルまたはプロトコルの組み合わせを使用して、装置応答処理モジュール3826に伝達される。
図39〜41は、マークアップ提示モジュール3822によって作成される代表的なページ群を示す。図39は、紹介ページ3902を示すが、これは、ユーザがマーチャントストアモジュール318に初めてアクセスすると、マークアップ提示モジュール3820がユーザに表示し得るページである。紹介ページ3902は、ユーザに、多様な閲覧カテゴリを調べたり、推奨アイテムをレビューしたり、検索を入力したり等をさせるポータルを提供する。図40は、閲覧ページ4002を示す。閲覧ページ4002によって、ユーザは、多様な題材カテゴリを使用して、アイテムを閲覧することが可能である。図41は、アイテム詳細提示4102を示すが、これは、ユーザがアイテム購入モジュール3812を介して購入し得る単一の電子書籍に関する情報を提供する。アイテム詳細情報を1ページに収めることができない場合、マークアップ提示モジュール3810は、図40に示したように、この情報を一連のページに表示し得る。
B.7.b.購入解除に対する例示的なアプローチ
図42は、図38の購入解除モジュール3814を使用して、購入を解除するための例示的な手順4200を表すフローチャートを示す。
ブロック4202で、アイテム購入モジュール3812は、ユーザのアイテム購入を受信する。ユーザは、フルフィルメント動作を開始する選択を行うことによって、購入を実行し得る。
ブロック4204において、IPS102は、上記の方式で、購入したアイテムを処理して、ユーザの装置に配信する可能性がある。
ブロック4206で、購入解除モジュール3814は、ユーザがブロック4302で行った購入を解除することにつながるオプションをユーザに示す。1つの事例においては、購入解除モジュール3814は、このオプションを、アイテムの購入後にユーザに提供される「ありがとうございました」ページ等に提示し得る。この段階では、前のブロック4204に示したように、アイテム購入モジュール3812は、アイテムのユーザの購入をフルフィルメントする手続き中である。
ブロック4208において、ユーザは、実際には購入解除オプションを有効にすると想定する。
ブロック4210において、購入解除モジュール3814は、可能であれば、アイテムのユーザの購入を解除する。
B.8.例示的なコンテンツ管理モジュールとメディアライブラリモジュール
装置側コンテンツ管理モジュール342は、ユーザ装置104によって消費するために利用可能なアイテムをユーザがレビューおよび管理することを可能にするツールを提供する。図44は、コンテンツ管理機能342に関する追加の詳細を示す。図44は、コンテンツ管理機能が、サーバ側個人メディアライブラリモジュール342およびサブスクリプションモジュール310のような他のモジュールと対話し得る方式も図説する。
コンテンツ管理機能モジュール342は、提示モジュール4302を含む。提示モジュール4302は、ユーザ装置104を使用してユーザが消費するために利用できる多様なアイテムを示す。アイテムは、多様なソースに由来し得る。第1のソースは、ユーザ装置の内部デバイスメモリ336に対応する。第2のソースは、フラッシュカード等のような、ユーザ装置104に結合され得る携帯型メモリモジュール4304に対応する。第3のソースは、ユーザの装置側個人メディアライブラリモジュール324に特定したアイテムに対応する。より具体的には、コンテンツ管理機能モジュール342は、電子書籍アイテム、特別に選択した新聞や雑誌の号等、オンデマンド(「アラカルト」)選択に関する情報を、メディアライブラリモジュール324から受信し得る。第4のソースは、サブスクリプションモジュール310において特定されるアイテムに対応する。より具体的には、コンテンツ管理機能モジュール342は、ユーザのサブスクリプションおよびそれらのサブスクリプションに関連する最新号に関する情報を提供し得る。サブスクリプションに関して、1つの例示的な事例においては、コンテンツ管理機能モジュール342は、ユーザのサブスクリプションの各々に対して、最後のn日分を保管し得る。
1つの例示的な実施形態において、コンテンツ管理機能モジュール342は、個人メディアライブラリモジュール324および/またはサブスクリプションモジュール310上に保管したアイテムを特定する装置側メタデータへのアクセスを有する。これによって、内容を判断するために、ユーザがこれらのサーバ側モジュールにオンデマンドクエリを行う必要性を回避する。
別の特徴によると、提示モジュール4302はフィルタリングモジュール4306を含む。フィルタリングモジュール4306によって、ユーザは、提示モジュール4302によって表示されるアイテムのタイプを決定する場合に使用する条件を選択することが可能になる。例えば、ユーザは、提示を装置側内部メモリ336内に格納されたアイテムだけ等に限定することに積極的であり得る。
コンテンツ管理機能モジュール342は、更新処理モジュール4308も含む。更新処理モジュールの目的は、個人メディアライブラリモジュール324のコンテンツを記述する装置側メタデータを更新することである。更新モジュール4308は、ユーザ装置とIPS102がいずれの理由でも互いに対話すると、様々な時点で起動され得る。例えば、更新モジュール4308は、TPH信号の受信によってトリガされる一連の動作の一部として起動され得る。
ここで、個人メディアライブラリモジュール324を参照すると、このモジュール324は、ユーザがこれまでにアラカルト様式で購入したアイテムを保管する。より具体的には、個人メディアアイテムライブラリ324は、ユーザが購入したマーチャントコンテンツストア308内のアイテムを参照するポインタ4308を保管し得る。上記の方式では、ユーザは、コンテンツ配信モジュール316を経由してこれまでに購入したアイテムを受信し得、コンテンツ配信モジュール316は、次いで、ユーザが要求したアイテムを受信するように確かに認証されていることを確認するために個人メディアライブラリモジュール324に問い合わせを実行し得る。ユーザは、コンテンツがユーザ装置のローカルストアから誤って消去された場合等、いずれの理由でも再びアイテムをダウンロードすることを決定し得る。
ユーザは、同様な方式でサブスクリプション関連アイテムをダウンロードし得る。すなわち、コンテンツ配信モジュール316は、サブスクリプションモジュール324にアクセスして、ユーザが号等をダウンロードするように承認されているかどうかを決定する。サブスクリプションモジュール324によって提供された許可情報は、サブスクリプション内の個別の号ではなく、サブスクリプションレベルで実行される。
図44は、コンテンツ管理機能ページ4402の提示モジュール4302によって提供されるコンテンツ管理機能ページ4402を示す。このページ4402は、ユーザ装置104を使用してユーザが消費するために利用可能な多様なアイテムを示す。ページ4402は、アイテムが個人メディアライブラリモジュール324を経由して利用可能であることを示す「マーチャント」、アイテムが装置側メモリ336に格納されていることを示す「装置」、およびアイテムが着脱式メモリモジュールに格納されていることを示す「SDカード」等のように、アイテムのソースを示すタグも提供する。図43には示していないが、コンテンツ管理機能ページ4402は、アイテムがユーザ装置104にダウンロード中のプロセスにあるかどうか、および/またはアイテムは他の処理中であるかどうか、等を明らかにするインジケータを提供し得る。
図45は、フィルタリングメニュー4502を示す別のコンテンツ管理機能ページを示す。フィルタリングメニュー4502は、表示するアイテムのタイプ(選択したソースに対応する等)、およびアイテムを表示する順序を制御するフィルタリングモジュール4304によって使用される。
図46は、別のメニュー4602を示す別のコンテンツ管理機能ページを示す。他の機能の中でも、このメニュー4602によって、ユーザは、アイテムをあるソースから別のソースに移動したり、アイテムを削除したりすること等が可能になる。
図47は、ユーザ装置104とIPS102がどのように情報を共有するかを図説する手順4700を示す。
ブロック4702において、システム300における1つ以上のモジュールがトリガイベントを受信する。トリガイベントは、ユーザ装置104とIPS102との間で情報を共有する等、多様なハウスキーピング動作の時間であることを知らせる信号を送る。1つの代表的なトリガイベントは、IPS102からユーザ装置104へのTPH信号の送信に対応し得るが、情報の同期動作を含む、いくつかの動作を開始する。別のトリガイベントは、ユーザ装置104の電源を入れること、または、ユーザ装置104の状態の他の変化等に対応し得る。
ブロック4702において、システム300の1つ以上の適切なモジュールは、同期の目的で、1つ以上の他のモジュールと情報を共有する。1つの例を挙げると、ブロック4702は、バックアップ注釈ストア1116に保管するために、特定のアイテムに対してユーザが作成した注釈をIPS102に送信することをユーザ装置104に要求し得る。さらに、ブロック4702は、メタデータをコンテンツ管理機能モジュール342に送信することと個人メディアライブラリモジュール324に要求し得るが、この場合、このようなメタデータは、個人メディアライブラリモジュール324によって参照されるアイテムを反映する。さらに他の情報共有動作は、多様なトリガイベントの発生時に実行され得る。
上記の定期的な同期動作に加えて、IPS102は、例えば、ユーザがハードリセットコマンドを起動した等、ユーザ装置104の保管されたコンテンツがアクセス可能でなくなると、ユーザ装置104のコンテンツをリストアするように、ユーザ装置104と対話できる。
B.9.例示的なリーダモジュール、注釈機能、およびオーディオ再生モジュール
図3の説明で紹介したリーダモジュール340は、ユーザが電子書籍を読むことを可能にするインタフェースを提供することを思い起こされたい。図48は、Herman Melville著の小説「Moby Dick」に対応する、リーダモジュール340によって提供されるテキストコンテンツの1ページ4802を示す。ユーザは、適切なメニュー(図示せず)を介して、フォントのサイズを変更し得る。ユーザは、進捗表示4808から、本全体の進捗状況を表示し得る。進捗表示の点の数は、表示全体の長さと相対的に、ユーザが本をどこまで読み進めたかを反映する。
読むことが可能なコンテンツのいずれのページも、有効にされ得る1つ以上の埋め込み型リンクを含み得る。例えば、ページ4802のボタン4806に注目されたい。この事例においては、リーダモジュール340によって表示されている読書資料は、本の章等、より完全なアイテムのサンプルに対応する。ページ4802は、ユーザにアイテムの完全バージョンを選択させるボタン4806を含む。別の実施形態において、ボタン4806によって、ユーザはアイテムの別の部分を購入するように指示され得る(本の別の章、雑誌シリーズの別の号等)。別の事例においては、リンクは、1つ以上の一致する考慮事項に基づいて現在表示されているコンテンツに関連するアイテムを特定し得る。例えば、図38の推奨モジュール3810が多様な一致した考慮事項に基づいて関連アイテムを特定し得る。ボタン4806をクリックすると、マーチャントストアモジュール318は、例えば、例示的な事例において、ページ4802でユーザによって読まれているコンテンツの完全バージョンである、特定したアイテムを購入(またはそれ以外の手段で入手)して配信を開始するようになる。
図49は、ユーザがページのリンクを有効にすると、アイテム識別情報を動的に提供するための例示的な手順490を表すフローチャートを示す。
ブロック4902では、ユーザ装置104は、ボタン4806を含むページ4802のようなリンクを含む提示を提供する。ユーザ装置104は、ページを表示するテンプレートを使用し得る。テンプレートは、リンクを提示するための方策を含み得るが、リンクを、特定のアイテムを固有に特定するいかなる種類のコードにも関連付けることはない。つまり、ページには、実際のコードの代わりにプレースホルダーフィールドを含む。
より具体的には、特定のタイプのアイテムの場合、コンテンツ受信システム302は、識別情報をこれらのアイテムと正式に統合せずに、コンテンツストア308にアイテムを保管することを思い起こされたい。コンテンツ配信モジュール316がこのようなアイテムをユーザに配信する場合、識別情報をアイテムのヘッダに注入し得る(メタデータ注入モジュール2316を使用する)。しかし、この段階で、アイテム内部のリンクは、識別情報がまだ更新されていない。
ブロック4904において、ユーザ装置104は、ユーザが選択したリンクを受信する。
ブロック4906において、ユーザ装置104または他の何らかのエンティティは、リンクに関連付けられた固有の識別情報(例えば、固有の番号)を含むように、リンク情報を動的に更新し得る。上記のように、ページ4802がアイテムのサンプルを表示し、ボタン4806によって、ユーザがアイテムの完全バージョンにアクセスが可能になる特定の事例を考慮する。ユーザがボタン4806をクリックすると、装置104は、ボタン4806に関連付けられたリンクを、アイテムの完全バージョンと関連付けた識別情報で更新し得る。識別情報は、サンプルアイテムとともに、コンテンツ配信モジュール316によってユーザ装置に提供される。例えば、識別情報はサンプルアイテムのヘッダで伝達され得る。更新されたリンクは、次に、アイテムの完全バージョンを購入するために、マーチャントストアモジュール318にアクセスする等の動作を実行するように起動させることができ、これによって、このアイテムのユーザへの配信が開始する。
図50は、ユーザが電子書籍を読む間に起動し得る注釈メニュー5002を示す。ユーザは、メニュー5002を起動して、テキストの一節をハイライトしたり、テキストに関連したメモを追加したり等を実行し得る。ユーザは、カーソル移動メカニズム506を使用して、および/または他の何らかの入力メカニズムを使用して、これらの動作を実行し得る。例えば、ユーザは、カーソルを補助表示分504で対応する開始と終了の場所に移動させてから(例えば、マウスホイールを回転させる等による)、それらの場所を選択することによって(例えば、マウスホイールを押し下げる等による)、ハイライトするテキストの一部を区別し得る。
注釈について説明を続けると、図48に示したように、ユーザは、ページ4802の隅にあるマークアイコン4806の隣をクリックすることによって、ブックマークを入力し得る。さらに、図51は、ユーザによって印が付けられている電子書籍の場所を特定する方式を示す。すなわち、図51は進捗表示を示す。黒の小さい三角形は、テキスト内にユーザが作成したブックマークの場所を示す。
図52は、オーディオ再生モジュール410(図4で導入)に関連した多様な機能、およびオーディオ再生モジュール410が動作することができる環境を示す。ユーザ装置がオーディオアイテムを受信するために使用し得るメカニズムは少なくとも2つ存在する。第1のメカニズムでは、ユーザは、パーソナルコンピュータ5202または他のタイプのデータ処理装置を使用して、オーディオアイテムのソース5204からオーディオアイテムをダウンロードし得る。第1のアクセスメカニズムでは、パーソナルコンピュータ5202は、従来の電話またはケーブルモデム、DSL接続、T1接続等のような非ワイヤレス接続を経由して、オーディオソース5204にアクセスし得る。受信時、ユーザは、次に、USB接続、携帯型メモリモジュール、または他の送信メカニズムを経由してオーディオアイテムをユーザ装置104に転送し得る。第2のメカニズムでは、図2に示したのと同じ通信インフラストラクチャ106を使用して、オーディオソース5204からオーディオアイテムを受信してから、このオーディオアイテムをユーザ装置104に転送し得る。つまり、通信インフラストラクチャ106は、電子書籍等と同じ方式でオーディオアイテムを転送し、この場合、オーディオソース5204は、図3に示したコンテンツソース304のうちの1つのように機能する。説明したように、通信インフラストラクチャ106は、少なくとも部分的に、ワイヤレス通信に依存し得る。
オーディオソース5204は、課金ベースまたは無料ベース(例えば、図書館、政府機関等を含む)でオーディオアイテムを供給する、オーディオアイテムのサプライヤまたは他のタイプの組織を表し得る。この状況では、オーディオソース5204は、WANでアクセス可能なリソース(例えば、インターネットからアクセス可能なサイト等)として、パーソナルコンピュータ5202または他の装置からアクセス可能になり得る。オーディオソース5204は、他のユーザに普及するためにオーディオアイテムを供給するユーザまたはユーザのコミュニティも表し得る。
受信の際、オーディオ再生モジュール410は、オーディオアイテムをバックグラウンド音楽ファイル5206および/またはオーディブックファイル5208に保管し得る。オーディオ再生モジュール410は、バックグラウンド音楽ファイル5206のオーディオアイテムをバックグラウンド音楽として再生するように構成され得る。例えば、オーディオ再生モジュール410は、ユーザが新聞を読んでいる場合、ウェブを検索している場合等に、バックグラウンド音楽ファイル5206のオーディオアイテムを再生し得る。1つの事例において、オーディオ再生モジュール410は、無作為の順序でバックグランド音楽ファイル5206内のオーディオアイテムを再生し得る。オーディオ再生モジュール410は、ユーザに、バックグラウンド音楽ファイル5206にアクセスする、バックグラウンド音楽の再生を一時停止する、無作為の再生リスト内の次のオーディオアイテムをスキップする等を可能にする制御を提供し得る。
オーディオ再生モジュール410は、ユーザが、一般的に、テキストコンテンツと同じ方式で、オーディブックファイル5208保管されたオーディオアイテムとの相互にかかわること、および消費を可能にするように構成され得る。例えば、ページ5210は、ユーザにオーディブックのオーディオ再生を可能にする1つのユーザインタフェースページを示す。オーディオ再生モジュール410によって、ユーザは、多様な前方コマンド、後方コマンド等を使用して、オーディオアイテムのコンテンツ内部を移動することが可能になる。さらに、オーディオ再生モジュール410は、ユーザが傾聴を停止したアイテム内のポイントを保管する。その後該アイテムに戻ると、オーディオ再生モジュール410は、このポイントから前方へ再生を開始する。ユーザ装置410の他のモジュールは、電子書籍アイテムと同じバナーでオーディオアイテムを管理し得る。例えば、コンテンツ管理モジュール342は、利用可能なアイテムのリスト内のオーディオアイテムに関するメタデータを表示し得る(例えば、図44の「Sun Also Rises」エントリを参照)。
B.10.例示的なウェブ閲覧機能
図53は、図2のシステム200の略図を表す。この略図では、装置側閲覧モジュール402は、インターネットのようなネットワーク212を経由して、アイテム提供システム(IPS)102と対話する。IPS102は、閲覧プロキシモジュール326を含む。閲覧モジュール402は、ネットワークからアクセス可能なリソース226のうちの1つにアクセスしようとすると、まず、閲覧プロキシモジュール326に向けられる。この例示的および典型的な様式においては、装置閲覧モジュールがネットワークからアクセス可能なリソースに直接アクセスすることは不可能になる(図53に示したXの印によって示される)。閲覧モジュール402は、ユーザ装置がIPS102と通信する唯一の方式であることに注意する。閲覧プロキシモジュール326の使用は、アイテム配信システム312とタスクリスト処理モジュールとの間の通信プロトコル、およびマーチャントストアモジュール318と装置側ストア対話モジュール344との間の対話等、他の通信経路に影響を与えない。
IPS102は、ユーザが「外部」ネットワークからアクセス可能なリソースにアクセスすることを規制する様々なビジネスルールを確立し得る。1つの事例においては、IPSは、課金しない(または比較的低額を課金する)第1のクラスの無料リソース5302と、課金する(または比較的高額を課金する)第2のクラスの有料リソースとを区別し得る。
図54は、閲覧プロキシモジュール326を使用して、ネットワークからアクセス可能なリソースへのアクセスを規制する1つの例示的な方式を表す手順5400を示す。
ブロック5402で、閲覧プロキシモジュール326は、ウェブサイト等、ネットワークからアクセス可能なリソースへのユーザの接続要求を受信する。
ブロック5404において、閲覧プロキシモジュール326は、ユーザが接続を希望するサイトが、IPS102自体によって提供されるサービスに対応するかどうかを決定する。対応する場合、ブロック5406において、閲覧プロキシモジュール326は、要求したリソースへのアクセスをユーザに与える。
ブロック5404の応答が否定である場合(つまり、ユーザはIPS102自体へのアクセスを獲得しようとしない)、フローは、ブロック5408に進み、ここで、閲覧プロキシモジュール326は、ユーザが、専用の無料(または割引料金)のリソース5302のうちの1つ以上へのアクセスを獲得しようとするかどうかを決定する。獲得しようとする場合、ブロック5406において、閲覧プロキシモジュール326は、要求したリソースへのアクセスをユーザに与える(ブロック5406内)。
ブロック5408の応答が否定である場合(つまり、ユーザはIPS102または無料リソース5302へのアクセスを獲得しようとしない)、フローは、ブロック5410に進み、ここで、閲覧プロキシモジュール326は、ユーザが、専用の有料のリソース5304のうちの1つ以上へのアクセスを獲得しようとするかどうかを決定する。獲得しようとする場合、ブロック5412において、閲覧プロキシモジュール326は、次に、ユーザが必要な料金を支払い済みであるか、または支払うことに同意しているかどうかを決定する。このブロック5412の応答が肯定の場合、閲覧プロキシモジュール326は、適切な料金を評価(ブロック5414で)してから、ユーザに、要求したリソースへのアクセスを与える(ブロック5406で)。1つの事例において、システム300は、例えば、アクセス毎ベースで、ユーザがアクセスを希望する各アイテムに対する料金をユーザが支払い得るようにセットアップされ得る。別の事例においては、システム300は、既定の時間量(1日、1週間等)にアイテムにいくつでもアクセスする料金を支払い得るようにセットアップされ得る。いずれの事例でも、ユーザは、例えば、アイテムへのアクセスを希望するたびにユーザにクエリすることなく、アクセスを試行する場合に、アクセス関連の料金を自動的に許可するオプションを与えられ得る。
上記の状況が全く満たされない場合、ブロック5416において、閲覧プロキシモジュール326は、ユーザが要求したリソースにアクセスすることを拒否する。
図55は、装置閲覧モジュール402によって提供され得るブックマークページ5502(詳細設定ページとも称される)を示す。ページ5502は、リンクのリストを含む。ユーザは、対応するネットワークからアクセス可能なリソースに接続するように、いずれかのリンクをクリックし得る。
図56は、ユーザ装置104を使用して、URL等、ネットワークアドレスを入力するために装置閲覧モジュール402が使用し得るメニュー5602を示す。
C.例示的な管理関連機能
C.1.機能の概要
このセクションは、セクションAおよびBで説明したシステムを使用して実行され得る、多様な管理またはバックエンドタスクに関する情報を提供する。1つの管理機能は、システムの多様な態様のパフォーマンスを監視することに関する。別の管理機能は、システムの動作をテストすることに関する。別の管理機能は、システムに存在し得る障害または他の問題を診断することに関する。別の管理機能は、ユーザ装置104によって使用される命令付きコンテンツ(例えば、ソフトウェア)をアップグレードすることに関する。上記の機能は、重複し得る。例えば、テストと診断の機能は、パフォーマンス監視機能に依存し得る。アップグレード関連機能は、命令のアップグレードが適切であるかどうかを決定するテストおよび診断機能に依存し得る。
図57は、図2で紹介したシステム200の略図を提供する。このシステム200は、上記の多様な管理機能を説明する道具として使用される。しかし、本明細書で説明する管理機能も、他のタイプのシステムを使用して実現され得る。
システム200によって、アイテム提供システム(IPS)202は、通信インフラストラクチャを経由してユーザ装置104と対話することが可能になる。通信実現システム208は、広域ネットワーク(WAN)、さらに特定するとインターネットのようなネットワーク212を経由して、IPS102と対話する。
システム200は、以下に説明するように、多様なレベルで上記の多様な管理機能を実現する。
C.2.例示的なパフォーマンス監視、テスト、および診断機能
図57は、それぞれの「視点」から、システム200の多様な部分がシステム200のパフォーマンスを監視することができることを図説する。例えば、ユーザ装置は、ユーザ装置104に公開可能なパフォーマンス問題に関して、システム200のパフォーマンスに関連する多様なイベントを記録するための装置側パフォーマンスログモジュール5702を含み得る。装置側パフォーマンスログモジュール5702は、パフォーマンス情報をパフォーマンスログ416(図4の文脈で導入)に保管し得る。
ワイヤレスプロバイダシステム202は、同様に、ワイヤレスプロバイダシステム202に公開可能なパフォーマンス問題に関して、システム200のパフォーマンスに関連する多様なイベントを記録するためのパフォーマンスログモジュール5704を含み得る。パフォーマンスログモジュール5704は、パフォーマンス情報をパフォーマンスログ5706に保管し得る。
通信実現システム208は、同様に、通信実現システム208が認識可能なパフォーマンス問題に関して、システム200のパフォーマンスに関連する多様なイベントを記録するためのパフォーマンスログモジュール5708を含み得る。パフォーマンスログモジュール5708は、パフォーマンス情報をパフォーマンスログ5710に保管し得る。
IPS102は、多様な機能を実施するためのカスタマサービスモジュール5712を含み得る。第1の機能として、IPS102は、多様なイベントを独立的に記録して、このようなイベントもIPS側パフォーマンスログ5714に保管し得る。さらに、カスタマサービスモジュール5712は、ユーザ装置104、ワイヤレスプロバイダシステム202、および/または通信実現システム208によって収集されるいずれのパフォーマンス情報をも取得し得る。1つの特定事例においては、カスタマサービスモジュール5712は、システム200の様々な部分からパフォーマンス情報を自動的に収集する。別の事例では、カスタマサービスモジュール5712は、システム200の様々な態様に対してオンデマンドのターゲット問い合わせを実行し得、ユーザ装置104、ワイヤレスプロバイダシステム202、および/または通信実現システム208によって収集されたパフォーマンス情報の問い合わせを行なう。例えば、ユーザは、国の特定の領域でダウンロードの受信に関する障害を特定するためにカスタマサービス担当者に電話をかけ得る。カスタマサービス担当者は、障害の発生元の発見に役立てるため、システムのいずれかの部分によって提供されるパフォーマンス情報を確認し得る。
これに加えて、IPS102の管理者は、システム200の多様な部分を積極的にテストし得る。例えば、IPS102は、サーバ側テストモジュール5716を含み得る。サーバ側テストモジュール5716は、一連のテストユーザ装置にテスト信号を定期的に送信するために使用され、テストユーザ装置に応答するように要求し得る。または、テストモジュール5716は、オンデマンド方式で、テスト信号をテストユーザ装置に送信し得る。テストユーザ装置は、このようなテスト信号を受信および応答するために、補助テストモジュール5718を含み得る。(装置側パフォーマンスログモジュール5702および装置側テストモジュール5718は、合わせて、図4で導入した監視およびテスト機能414に対応することに注意する。)サーバ側テストモジュール5716は、応答を受信したかどうか、および/または応答に関連したパフォーマンスメトリクス等を含めて、各テストユーザ装置から受信する応答を監視し得る。サーバ側テストモジュール5716および/または管理者は、システム200内部のパフォーマンス問題の診断に役立てるために、結果を確認し得る。
図58は、テストモジュール(5716、414)の動作を形成する手順5802をフローチャート形態で示す。
ブロック5802において、サーバ側テストモジュール5716は、システム200をテストする時間かどうかを決定し得る。
ブロック5804において、テストを実施する時間である場合、サーバ側テストモジュール5804は、テストプローブを1台以上のテスト装置に送信し得る。
ブロック5806で、サーバ側テストモジュール5806は、テストユーザ装置から応答を受信したかどうかを特定し、受信した場合は、応答の性質を特定し得る。
C.3.例示的なアップグレード関連機能
図57に戻ると、この図面は、IPS102がサーバ側アップグレードモジュール5720を含むことを図説する。ユーザ装置104は、補助装置側アップグレードモジュール418(図4の文脈で導入した)を含む。概要として、1つの事例では、サーバ側アップグレードモジュール5720は、ユーザ装置104にアップグレードまたは他の情報を送るように手動で操作され得、この時、装置側アップグレードモジュール418は、適切な方式で特定されるアップグレードまたは他の情報をロードする。第2の事例では、サーバ側アップグレードモジュール5720は、ユーザ装置からバージョン情報を自動的に受信し得る(装置側アップグレードモジュールによって提供される)。サーバ側アップグレードモジュール5720は、受信したバージョン情報とソフトウェアの現在のバージョンとを比較し得る。サーバ側アップグレードモジュール5720は、次に、例えば、ユーザ装置を最新状態にするために望ましい命令付きアイテムのパッチまたは完全バージョンをダウンロードすることによって、適切であり得るいずれのアップグレードをも開始し得る。
図59は、ユーザ装置104に更新を提供する手動モードを表す手順5900を示す。
ブロック5902で、IPS102に関連付けられた管理者は、ユーザ装置104に行うべきアップグレードを特定する。
ブロック5904において、サーバ側アップグレードモジュール5720は、アップグレードをユーザ装置に送信し得、その際、装置側アップグレードモジュール418はアップグレードを命令の本文に組み入れる。更新動作は、エンドユーザが更新動作に参加することを任意選択で依頼されることがなく、更新動作に気づかないことがあり得る、という点で透過的である。
図60は、ユーザ装置104に更新を提供する自動モードを表す手順6000を示す。
ブロック6002において、サーバ側アップグレードモジュール5720は、ユーザ装置によって使用されている命令の現在のバージョンに関する情報を受信し得る。
動作6604において、サーバ側アップグレードモジュール5720は、装置のバージョンと命令の現在のバージョンとを比較し得る。
動作6606で、サーバ側アップグレードモジュール5720は、例えば、命令の現在のバージョンと命令の装置のバージョンとの違いを表現するデルタファイルを演算することによって、ユーザ装置によって使用されるアップグレードを自動的に準備し得る。アップグレードモジュール5720は、パッチまたは完全ファイルのいずれかとして、ユーザ装置104にアップグレードを送信し得る。装置側アップグレードモジュール418は、アップグレードを受信して、アップグレードを組み入れる動作を行う。ここでも、更新動作は、エンドユーザが更新動作に参加することを依頼されず、更新動作に気づかないことがあり得る、という点で透過的である。
図61は、いずれのタイプの更新をもユーザ装置104に送信するために、システム200によって使用される例示的な通信パッケージを示す。パッケージは、ヘッダ6102と本文6104とを含む。ヘッダ6102は、バージョン情報、属性情報、チェックサム情報および類似情報を伝達するフィールドを含み得る。本文6104は、マニフェスト、および/または命令付きコンテンツ(スクリプトコンテンツ、プログラムコンテンツ等)、および/またはメディアコンテンツ、および/または他のタイプのコンテンツを含み得る。本文は、ターファイル(tar file)として、または、他の何らかのフォーマットまたはフォーマットの組み合わせを使用することによって表現し得る。パッケージによって表現される情報は、未承認者が情報にアクセスすることを防止することに役立つように、無作為な情報と共にスクランブルされ得る。
パッケージは、ユーザ装置104からいかなるタイプの動作をも行なわせるために、いかなるタイプの情報でもユーザ装置104に伝達するための汎用目的の入れ物として機能する。1つの事例において、管理者は、命令付きアイテムをユーザ装置104にダウンロードするために、図61に示したパッケージを使用し得る。装置104は、このアイテムをメモリにロードすることによって応答する。装置104は、その後、アイテムに提供されたプログラム命令に基づいて動作する。
別の事例において、管理者は、ユーザ装置104によって表示されるいずれの種類のメッセージコンテンツ等、他のタイプのコンテンツをユーザ装置104にダウンロードするために、図61に示したパッケージを使用し得る。例えば、ダウンロードしたコンテンツは、電源切断モードで表示するようにユーザ装置104が命令されるメッセージに関連し得る(例えば、ユーザ装置が、動作の電源切断モードでディスプレイに情報を提示することができる、非揮発性のディスプレイ技術を使用する場合)。このメッセージを提供するために、パッケージは、望ましいメッセージおよび、任意選択で、ユーザ装置104にメッセージをどのように表示するかを命令するスクリプトコンテンツを提供するビットマップを含み得る。他のアプリケーションが可能である。
D.例示的なプロビジョニング機能
D.1.プロビジョニング機能の概要
図62は、新しいユーザ装置をプロビジョニングするためのシステム6200を示す。より具体的には、システム6200は、例えば、工場等の環境で新しく製造されたユーザ装置6204(またはそのコンポーネント)と対話するプロビジョニング機能6202を含む。新しいユーザ装置6204は、プロビジョニングモジュール6206を含み得る。装置側プロビジョニングモジュール6206は、プロビジョニング機能6202から、1つ以上の識別番号を含み得る、一時的な連絡情報6208を受信する。プロビジョニング機能6202は、通信インフラストラクチャ6210にプロビジョニング情報6212を提供するように、通信インフラストラクチャ6210とも対話し得る。プロビジョニング情報6212は、ユーザ装置6204によって保管される一時的な連絡情報に関する。
図62に示したように、ユーザ装置6206は、通信インフラストラクチャ6210への最初のアクセスを確立するように、一時的連絡情報6208を使用し得る。通信インフラストラクチャ6210は、次に、追加の永久的連絡情報6214をユーザ装置6204に転送し得る。ユーザ装置6204は、その後、IPS102および他のネットワークからアクセス可能なリソースにアクセスするために、追加の永久的連絡情報6214を使用し得る。プロビジョニングアプローチによって、ユーザは、複雑で面倒な構成操作を実施することなく、ユーザ装置6204を使用することが可能になる。
ユーザ装置をプロビジョニングする1つの例示的手法に関する追加の詳細は、2006年3月29日付の発明者、Subram Narasimhan, et.al. による米国特許第11/277,876号、名称「Over−the−air Device Provisioning and Activation」に説明されている。
D.2.例示的な仮想アカウントの処理
図63は、ユーザがユーザ装置104を購入直後にユーザにアイテムの購入(またはより一般的には、アイテムの入手)を可能にするための手順6300を図説する。この手順6300は、図38の仮想アカウントモジュール3816によって、少なくとも部分的に実施され得る。
ブロック6302で、購入システムは、ユーザが新しいユーザ装置を購入したことを受信する。
ブロック6304で、購入システムまたは他の何らかのモジュールは、ユーザの仮想アカウントを確立し得る。仮想アカウントは、ユーザ装置にユーザが割り当てられる前であっても確立される。
ブロック6306で、購入システムは、ユーザが行った1つ以上のアイテム購入を受信する。購入システムは、これらの購入をブロック6304で作成した仮想アカウントに関連付ける。
ブロック6308で、ユーザ装置がユーザに割り当てられると、購入システムまたは他の何らかのモジュールは、仮想アカウントを割り当てられたユーザ装置に関連付け得る。この連結動作によって、ユーザは、自分の新しいユーザ装置を使用して、仮想アカウントに適用されたアイテムを受信および消費することが可能になる。
D.3.例示的な初期テスト
図64は、この文脈において、テスト中装置(DUT)と称される、新しいユーザ装置6402のテストに対するアプローチを示す。例えば、このアプローチは、工場または他の生産段階のどこかで装置をテストするために使用され得る。
導入のために、ユーザ装置6402は、好ましいローミングリスト(PRL)6404と最近使用した(MRU)テーブル6406とを含むことができる。PRL6404は、ユーザ装置が通信局等との通信を確立するために調査し得るターゲット周波数のリストを含む。MRUテーブル6404は、ユーザ装置104が通信局へのアクセスを得るために最近使用した周波数を特定する。
図64は、テスト機器6408も示す。テスト機器6408は、部分的に、ユーザ装置6402が通信局と通信を確立できる能力をテストするために使用される。テスト機器6408は、テストの実施目的で、ユーザ装置6402との通信を確立するために、テストチャネル6410を使用し得る。
テストを迅速化するために、図64に示したアプローチは、テスト機器6408のテストチャネル6410を特定する情報を保管するように、ユーザ装置6406のMRUテーブルをプログラムする。これによって、ユーザ装置6402は、テスト機器6408との通信を迅速に確立することが可能になるが、これは、ユーザ装置6402が、テスト機器6408と通信する周波数を探す必要性を回避することによる。
さらなる特徴として、テスト手法は、PRLテーブルにテストPRLを保管する必要が無く、したがって、テスト後に、テストPRL6404をフィールドで使用される実際のPRL6404に置換する。つまり、本アプローチでは、PRL6404は、テスト動作全体で実際のPRL情報を維持し得る。
図65は、上記のテストアプローチを実現するための手順6500を示す。
ブロック6502においては、MRUテーブル6406は、テスト機器6408のテストチャネル6410を特定する情報を保管する。
ブロック6504で、ユーザ装置6402とテスト機器6408はテストを実行する。テストの実施において、適切なアクセス情報は既にMRUテーブル6404に保管されているため、ユーザ装置6402は、テスト機器6408のチャネルを探す必要がない。
E.例示的な検索およびインデックス作成技術
E.1.検索概要
このセクションでは、ローカルおよび/またはリモートに保管されたコンテンツを検索するために、演算装置上に実現され得る多様な検索技術を説明する。検索およびインデックス作成は、ローカルのユーザ装置(例えば、電子書籍リーダ装置、PDA、PC等)、リモートの演算装置(例えば、アイテム提供システム、サーバ等)または両方で実行され得る。検索動作は、プロセッサに比較的負荷がかかる動作になる傾向が強い。しばしば、コンテンツを検索する前に、コンテンツは、検索を容易にするために、カタログ化またはインデックスされる。その場合でも、検索は、まだ、かなりの処理リソースを必要とし得る。さらに、コンテンツにインデックスを作成するプロセスは、処理リソースも必要とする。これらのプロセッサの負荷は、演算装置によって消費される電力に反映される。
プロセッサの負荷および消費電力は、電子書籍リーダのような携帯型ローカルユーザ装置の状況においては、一層重要な考慮事項となる。比較的大量の処理および電力要件のために、電子書籍リーダ上の検索はほとんど存在しなかった。検索がPDAまたは他の携帯型ユーザ装置上で利用可能な場合、携帯型ユーザ装置は、検索やインデックス作成を実施するために、リモートの演算装置のより大型の処理能力を利用する傾向があった。しかし、検索がリモートの演算装置によって実行される場合、携帯型ユーザ装置がリモートの演算装置と通信外にある場合には、検索を利用可能となり得ない。
例示的な検索およびインデックス作成技術は、例示的な電子書籍リーダユーザ装置の文脈において、以下に説明する。しかし、本明細書で説明する概念は、PC(デスクトップまたはラップトップ)、サーバ、PDA、ポケット型PC、スマートフォン等の他のタイプのローカルおよび/またはリモート演算装置により一般的に適用され得る。
E.2.例示的なユーザ装置の検索コンポーネント
図66は、本明細書で説明する検索およびインデックス作成技術を実現することが可能な1つの例示的なユーザ装置104の模式図である。このセクションで説明する実施形態は、図44に示し、一般的に上のセクションAで説明した検索およびインデックス作成機能のいくつかの例を表す。一般的に、ユーザ装置104は、プロセッサ6600と、一群の電子アイテム6604および1つ以上の検索インデックス6606とを格納するメモリ6602とを含む。検索インデックス6606は、一群の電子アイテムにある言葉の整理されたカタログまたは辞書を含み、一群の電子アイテム6604を検索するために使用され得る。検索インデックス6606は、リモートソースから受信、または、ユーザ装置104でインデックスモジュール6608によって生成され得る。ユーザ装置104は、検索インデックス6606を使用して、一群の電子アイテム6604を検索するように構成された検索モジュール6610を含む。インデックスモジュール6608と検索モジュール6610は、概念を理解するために個別のモジュールとして示されるが、実際には検索およびインデックス作成機能は単一の検索/インデックスモジュールにより、および/またはいかなる数および組み合わせの個別のモジュールによって実現され得る。
例示的な実施形態では、メモリ6602は、ユーザ装置104の内部メモリを含む。これに加えて、この実施形態のユーザ装置104は、第2の群の電子アイテム6614および第2のコレクションの電子アイテムに対する検索インデックス6616を格納する着脱式メモリ6612(例えば、メモリカード、ディスク等)を含む。一般的に、各メモリは、そこに格納される電子アイテムに対応する1つ以上の検索インデックスを含む。このように、1つのメモリを削除しても、別のメモリ上に格納された電子アイテムの検索機能に影響を与えることはない。しかし、他の実施形態において、ユーザ装置は、多様な数および組み合わせのメモリタイプを含み得、検索インデックスは、対応する電子アイテムと共に、または別に格納され得る。
ユーザ装置104は、ユーザインタフェース6618も含み、これによって、ユーザは、検索クエリの入力、検索結果の変更、電子アイテムの閲覧、およびそうでなければユーザ装置104との対話を実行できる。検索クエリを入力すると、検索結果は、図5に示したデュアル画面配置のように、ユーザ装置104の1つ以上の画面6620上に表示され得る。上記で述べたように、ユーザ装置104は、他の多様な機能も含み得る(例えば、タスクリスト処理モジュール、リーダモジュール、コンテンツ管理モジュール、電力管理機能等)。他の機能の中には、検索および/またはインデックス作成モジュール6610および6608と相互に動作して、検索結果を管理したり、電子アイテムの格納場所を表示したり(例えば、内部メモリ内、着脱式メモリ内、リモートストレージ内等)、リモートマーチャントストアと対話したりすること等を実行し得る。
図67は、ユーザ装置104から検索可能になり得る、多様なコンテンツソースのシステム6700を図説する模式図である。内部メモリ6602および着脱式メモリ6612に加えて、ユーザ装置104は、多様な数の他のローカルおよび/またはリモートのコンテンツソースを検索することが可能になり得る。例えば、例示的な実施形態において、ユーザ装置104は、リモートのデータストア6702、インターネットのような広域ネットワーク、マーチャントストア6706、およびリモートの検索エンティティ6608と通信して検索するように構成される。ユーザ装置と多様なコンテンツソースとの間の通信は、上記A〜Dのセクションに詳しく説明したように、ワイヤレスおよび/または有線通信チャネルを経由し得る。
1つの実施形態において、リモートデータストア6702とマーチャントストア6706は、上記のセクションAで図3に関して説明したように、個人メディアライブラリモジュールとマーチャントストアモジュールをそれぞれ含み得る。インターネット6704の検索は、従来のインターネット検索エンジン、特殊なサーバ側検索エンジン、および/または装置側検索エンジンを使用して達成され得る。検索エンティティ6708は、情報のソースを検索することと結果をユーザ装置104に戻すことができるいずれのエンティティでもあり得る。1つの実施形態において、検索エンティティ6708は、部分的に人間に依存して、検索結果を編集して検索クエリに応答を提供するエンティティを含む。このような検索エンティティの多様な例は、CA州Sunnyvale所在のYahoo Inc.から入手可能なYahoo(登録商標)Answers、MD州Bethesda所在のWondir,Inc.、またはWA州Seattle所在のNowNow.comから入手可能なNowNow(登録商標)を含む。
E.3.例示的な検索方法
図68は、ユーザ装置104のユーザインタフェースを使用してどのように検索クエリが入力され得るかを示す詳細図である。上記セクションAで図5に関して述べたとおり、ユーザ装置104は、キーパッド518を有し得る。図68の下側の詳細図に示したように、キーパッドは検索キー6800を含み得る。検索キー6800を押すと、図68の上側の詳細図に示したように、検索メニュー6802が表示される。検索メニュー6802は、クエリフィールド6804と「go」フィールド6806を含む。ユーザは、キーパッド518を使用してクエリをタイプすることによって、リーダ画面602からテキストを選択することによって、サムホイール506を使用することによって、またはユーザインタフェース6618の他のいかなる入力によっても、検索メニュー6802のクエリフィールド6804にいかなる数の1つ以上の検索語をも有する検索クエリを入力し得る。入力中、検索クエリ語は、クエリフィールド6804に表示される。ユーザは、カーソル608を使用して「実行」フィールド6806を選択することによって、検索を開始することができる。
図69は、例えば、電子書籍リーダ等のユーザ装置によって実現され得る例示的なフルテキスト検索方法6906を示すフローチャートである。方法6900は、図説するためにユーザ装置104の状況で説明するが、他のいずれかのタイプのユーザ装置を使用して実現される可能性がある。6902で、ユーザ装置104は、例えば、検索メニュー6802を経由して検索クエリ入力を受信する。図説した例においては、1つの検索語「politics」だけが入力される。複数の検索クエリ語を入力すると、一部の実施形態では、検索モジュール6610は、言葉を暗示的な「近接」演算によって分割されているように処置し得る。しかし、他の実施形態は、他のいかなる暗示的または明示的な演算子(例えば、ブール式演算、近接演算等)も使用され得る。
検索クエリは、6904で、ステミング、トランケーション、または他の何らかの適切な検索法を使用して、クエリした言葉の変形を含むように拡張され得る。例えば、ステミングは、他の変形の中でも、単数形のクエリ語の複数形、複数形の言葉の単数形、クエリ語の動詞の他の時制、クエリ語の一般的なミススペル、クエリ語の外国語の翻訳、クエリ語の所有形、クエリ語を含むドメイン名というようなクエリ語の変形のうちのいずれか1つ以上を認識して含み得る。トランケーションは、接頭辞または接尾辞を変えた言葉を検索する能力を指す。トランケーションおよび他の多様な検索法の詳細は、当業者には明らかである。
6906で、ユーザ装置104は、利用可能なコンテンツのソースを決定する。この事例においては、コンテンツの利用可能なソースは、内部メモリ6602、着脱式メモリ6612、リモートのデータストア6702、インターネット6704、マーチャントストア6706、およびリモートの検索エンティティ6708を含む。
一部の場合には、検索クエリは、検索する1つ以上のコンテンツソースを示す、コマンド行または他の指定子を含み得る。コマンド行が存在する場合、コマンド行は、いずれかの適切な文字、記号、ボタンまたは他の指定子によって指定され得る。1つの例においては、検索する1つ以上のコンテンツソースを特定するコマンド行を開始するために、「@」記号が使用され得る。この例では、コマンド行「@web」は、検索がウェブ上で実施されるべきであることを示す。しかし、コマンド行をオフセットするために、他のいずれか適切な指定子が使用され得る(例えば、#、$、%、^、&、*、“、チェックボックス、個別のスコープフィールド、プルダウンメニュー等)。コマンド行は、1つ以上のコンテンツソース全体(例えば、ウェブ、リモートのデータストア、内部メモリ等)または特殊なウェブサイトのようなコンテンツソースの何らかの部分、コンテンツのタイプ(例えば、本、音楽、定期刊行物等)、アイテムのコレクション(例えば、ドラマ、父の物等)、または他のいずれかのコンテンツ部分を指定し得る。
6908で、ユーザ装置104は、検索クエリに存在するいずれかのコマンド行をも認識し、6910で、検索する1つ以上のコンテンツソースを特定し得る。図説した実施形態のように、検索クエリにコマンド行が見つからない場合、検索は1つ以上の既定のコンテンツソースに初期設定され得る。1つの実施形態において、検索は、ユーザ装置104の内部および/または着脱式メモリに格納されたローカルコンテンツを検索するように初期設定され得る。代替として、検索は、利用可能な全てのコンテンツソース、または、ユーザ装置104が利用可能な他のコンテンツソースのうちのいずれか1つ以上に初期設定される可能性がある。
6912で、ユーザ装置104は、クエリした言葉に対して1つ以上の特定されたコンテンツソースの検索を開始する。図説した例においては、コマンド行が入力されていないので、ユーザ装置104は「politics」という言葉に対して、デフォルトのメディアコンテンツソース(この事例においては装置のローカルメモリ)を検索する。
図70は、1つの例示的な検索方法7000の追加詳細を図説するフローチャートで、便宜性のためにユーザ装置104の状況で説明するが、他のユーザ装置にも適用し得る。検索方法7000の詳細は、図71と72に示した例示的な検索画面を参照して説明する。図70を参照すると、7002で、ユーザ装置104は、1つ以上のクエリした言葉を含む検索クエリを受信して、検索プロセスを開始する。検索は、検索モジュール6610によって実施され、7004で、1つ以上の検索インデックスでクエリした言葉を参照する。一般的に、インデックスは、ユーザ装置104上でアクセス可能な電子アイテムで使用される言葉の1つ以上の系統的リストを含む。インデックスは、電子アイテム、タイトル、ヘッダ、コンテンツのテーブル、および/またはメタデータのフルテキストを含み得る。1つの実施形態において、インデックスは、一部の電子項目(例えば、ローカルに保管された電子アイテム)のフルテキストの検索可能なインデックスと他の電子項目(例えば、リモートに保管された電子アイテム)の限定部分(例えば、タイトル、ヘッダ、およびメタデータ)の検索可能なインデックスを含み得る。以下に、いくつかの検索作成スキームを詳細に説明する。
一部の実施形態において、検索される電子アイテムおよび/または検索結果を表示する様式は、検索の要求時にユーザが何を実行しているかに依存して変わり得る。図示した実施形態において、ユーザ装置104は、7006で、電子アイテムが現在表示されているかどうかを決定する。図示されていない場合(例えば、検索がホーム画面、コンテンツ管理画面等から要求された場合)、7008で、検索モジュール6610は、クエリした言葉が各電子アイテムに出現するインスタンスの数順に検索結果を返す。このように、クエリした言葉のインスタンスまたはヒットが最も多い電子アイテムは、先頭にリストされる。電子アイテムが表示されている場合(例えば、検索は電子書籍または他の電子アイテム内の読書ペイン(pane)から要求された場合)、7010で、検索モジュール6610は、クエリした言葉がその中に出現する場合、現在表示されている電子アイテムを先頭にリストして、検索結果を返す。この事例では、残りの結果は、クエリした言葉のインスタンスの数順にリストされる。クエリした言葉が現在表示されている電子アイテムにない場合、検索結果はブロック7008と同じ様式で表示される。
図71は、図70のブロック7010と同じ様式で表示された電子アイテムのリストを示す例示的な検索結果画面7100である。この例では、コマンド行が入力されていないため、ユーザ装置104のローカルメモリに格納されたコンテンツを検索するように初期設定される。このように、検索結果画面7100は、クエリした検索語を含む、装置のローカルメモリ内の電子アイテムのリスト7102を表示する。検索語が出現した回数は、リスト7102の各電子アイテムの左側に括弧の中にリストされる。この例では、検索は「The Bluest Eye」というタイトルの電子アイテム内から要求された。したがって、検索が要求されたときに表示されていて、クエリ語「politics」を含むので、電子アイテム「The Bluest Eye」がリスト7102の先頭にリストされて、その後にクエリした言葉のインスタンスの数順にリストされたクエリ語を有する他の電子アイテムが続く。
他の実施形態においては、検索の要求時にユーザが電子アイテムを消費中の場合、検索は検索前に消費中の電子アイテムのテキストに限定され得る。逆に、ユーザが電子アイテムの外側から検索を要求する場合、検索は、ユーザ装置104がアクセス可能な全ての電子アイテム、ユーザ装置104のローカルメモリ内の全ての電子アイテム、またはユーザ装置104のローカルメモリ内の電子アイテムの一部(例えば、一群)のテキストに包含し得る。
図70をもう一度参照すると、ユーザには、7012で、検索の範囲を手動で設定または変更するオプションも与えられ得る。1つの実施形態において、ユーザは、例えば、図71の検索結果画面7100上のメニューボタン7104を選択して、1つ以上の表示されたメニュー項目(図示せず)に基づいて検索範囲を選択することによって、検索の範囲を限定し得る。例えば、ユーザには、コンテンツのタイプによって(例えば、本、定期刊行物、音楽等)、コンテンツのソースによって(例えば、内部メモリ、着脱式メモリ、リモートデータソース、マーチャントストア等)、および/または他の多様な数の範囲設定ツールによっても、検索を制限するオプションが与えられ得る。
図71の電子アイテムのリスト7102からの電子アイテムのうちの1つを選択すると、7104で、表示されるように選択した電子アイテム内でクエリした言葉が出現する場所のリストが作成される。1つの実施形態において、該場所は不変で、不変場所参照識別子によって特定される。不変場所参照識別子は、名前が示すように、電子アイテムが表示されている演算装置の画面サイズ、フォントタイプまたはサイズ、解像度、または他の表示状況に関わらず、電子アイテムのコンテンツの特定の場所またはセグメントを特定および伝えることが可能になる。一般的に、これは、電子アイテムのコンテンツ全体における場所または電子アイテムの個別のセグメントに固有の参照識別子を割り当てることによって、達成される。これらの参照識別子は、電子アイテムが表示される演算装置の表示状況に依存しない。この意味では、参照文字は不変である。
電子アイテムのコンテンツ内、またはこれに関連して、不変場所参照識別子を提供する数々の方式が存在する。これに加えて、電子アイテムを区分化して、不変場所参照識別子を割り当てられ得る多様な方式が存在する。例えば、各不変場所参照識別子は、電子アイテムの個別の文字または単語、単語の集合、文、段落、既定サイズのテキストのまとまり、データの単位、または他の何らかの区分に割り当てられ得る。不変場所参照識別のスキームの追加詳細は、2007年3月29日付提出の米国特許出願第11/693,677号、名称「Invariant Referencing in Digital Works」に確認できる。
7016で、周辺のテキストの中でクエリした言葉を含む電子アイテムの引用を、クエリした言葉が選択した電子アイテムで出現する場所とともに、またはその代わりに表示され得る。例えば、ユーザがニューヨーク・タイムズの2007年3月18日版の隣にある図71の選択可能ブロック7106を選択すると、ニューヨーク・タイムズのその版中に「politics」という言葉のインスタンスを示すインスタンス画面が表示され得る。
図72は、図71の選択可能ブロック7106のユーザ選択に応答して表示され得る、インスタンス画面7200の図説例である。図72に示したように、「politics」という言葉の最初の6件のインスタンス周辺のテキストの引用7202が、電子アイテムの引用の場所7204と共に表示される。クエリした言葉「politics」自体は各引用7202内で強調され得る(例えば、太字、イタリック体、下線付き、ハイライト等)。追加のインスタンス引用は、メニューボタンを使用して次のページのインスタンスに移動することによって表示され得る。引用7202のうちの1つを選択すると、ユーザ装置104は電子アイテムの選択した場所にジャンプ(7018)して、ユーザが引用場所から電子アイテムを読み始めることができるように、読書ペインを開く。
図71をもう一度参照すると、クエリした言葉を含む電子アイテムのリスト7102に加えて、検索結果画面7100は、まだインデックスされていないのでまだ検索可能でないいずれの電子アイテムのエントリ7108も含み得る。検索結果画面7100は、辞書リンク7110も表示して、ユーザ装置のローカルメモリに格納された1つ以上の辞書でクエリ語の定義を表示する。この事例においては、検索結果画面7100は、2つの辞書の定義があり、辞書リンク7110の隣にある選択可能ブロックを選択することによって表示され得ることを示す。検索結果画面は、検索され得るコンテンツ7112の他のソースのリストも含み得る。この事例においては、検索結果画面7100は、ユーザに、ウェブ、特定のウェブサイト、またはマーチャントストアでクエリした言葉を検索するオプションを与える。もちろん、検索結果画面7100は、検索結果を表示する可能な方式の一つに過ぎない。検索結果をユーザに提示する他の多数な方式は当業者には明らかである。
上述のように、検索結果画面はエントリ7106を含み、まだ検索可能ではない電子アイテムの件数を示す。ユーザは、どの電子アイテムがまだ検索可能ではないか、およびいつインデックス作成が予想できるかを知ることを希望し得る。まだ検索可能ではないアイテムのエントリ7108を選択すると、図73に示したようなインデックス作成状況画面7300が表示される。インデックス作成状況画面7300は、受信されてはいるがまだインデックスが作成されていない電子アイテムのキュー7302を含み得る。キュー7302は、ユーザ装置104による受信順、アルファベット順、または他のいずれかの適切な順序に系統化され得る。キュー7302は、各電子アイテムに対するインデックス作成状況インジケータ7304を含み得る(例えば、「インデックス作成中」または「インデックス未作成」)。図示していないが、「インデックス作成中」として示されるいずれの電子アイテムも、アイテムがどの程度インデックスされているか、および/または今後インデックス作成がどの程度残っているかを示す進捗バーまたは他のインジケータも含み得る。(例えば、インデックス済み60%、残り40%、残り500バイト、残り時間2分等)
一般的に、電子アイテムは、キューにリストされた優先度順にインデックスが作成される。しかし、ユーザは、リストの電子項目の隣の選択ブロックを選択するだけで、インデックス作成の優先順を変更して、リストの後方の電子アイテムのインデックスを最初に作成するように要求し得る。選択されると、電子アイテムのインデックス作成状況インジケータ7304は、「インデックスが未作成」から「インデックス作成中」に代わり、電子アイテムの隣の選択ブロックが消える。他の実施形態において、キュー7302内の電子アイテムには、ユーザによってインデックス作成の優先度を割り当てられ得る。例えば、ユーザに、インデックス作成優先度をリストの各電子アイテムに割り当てる機会が与えられ得る(例えば、数字または他のランクをリストの電子アイテムに割り当てることによる)。
E.4.例示的なインデックス作成技術
インデックス作成とは、電子アイテムを1つ以上のクエリ語で容易に検索できるように、1つ以上の電子アイテムで使用される言葉の系統化およびカタログ作成を行うプロセスを指す。フルテキスト検索に対するインデックス作成は、いくつかの様々な方式で実施され得る。1つのアプローチにおいては、メモリに格納された全ての電子アイテムで使用される言葉を、各それぞれの言葉の場所と共にカタログ化するように、単独のマスタインデックスが使用され得る。別のアプローチにおいては、各電子アイテムは、その特別な電子アイテム内の言葉および各言葉の場所のアイテムインデックスを含む。また別のアプローチでは、マスタとアイテムインデックスの両方が使用される。この「ハイブリッド型」アプローチでは、マスタインデックスは、メモリに格納された全ての電子アイテムで使用される言葉のリストを含み、マスタインデックスの各言葉は、各電子アイテムに対するアイテムインデックスのエントリに対するポインタが添付される。ハイブリッド型アプローチを使用することによって、マスタインデックスが破損または消失した場合、個別のアイテムインデックスから再作成され得る。また、アイテムインデックスが破損または消失した場合、マスタインデックスを再作成する必要なく、個別の電子アイテムのインデックスを再作成することが可能である。しかし、各インデックス作成技術には特定の利点があり、多様な実施形態において、ユーザ装置による検索のためにコンテンツのインデックスを作成するために、前述のいずれかまたは他のインデックス作成技術が使用され得る。
図74は、ハイブリッド型のインデックス作成7400を詳細に図説する模式図である。この例では、ユーザ装置104は、アイテム1(子ども用の果実に関する電子書籍)、アイテム2(子ども用の色に関する電子書籍)、およびアイテムN(子ども用の動物に関する電子書籍)を含む、メモリに格納された一群の電子アイテムを有する。各アイテムは、メモリに格納した対応するアイテムインデックス7402を有し、それらは電子アイテム内で言葉が出現する場所のリストを含む。アイテムインデックス7402は、一般的に、電子アイテム内の言葉の場所から成る。アイテムインデックス7402は、言葉の出現頻度、電子アイテムに言葉が出現する順、アルファベット順、または他のいずれかの適切な順序に基づいて体系化することができる。アイテムインデックス7402は、場所に対応する実際の言葉のリストを含み得るが、一般的には含まない。例えば、アイテム1は、特に、Apple、Banana、Grape、およびGreenという言葉の電子アイテム1内の場所を含むアイテムインデックス7402を有する。図説した例においては、Appleという言葉はアイテム1の場所1、場所3、および場所7の3回出現する。Bananaは、場所2で出現し、Grapeは場所6および7で出現し、Greenは場所7で出現する。
同様に、アイテム2は、特に、Blue、Brown、GreenおよびGreyという言葉の電子アイテム2内の場所を含むアイテムインデックス7402を有する。アイテム3は、特に、Brown、Cat、Cow、Dog、Eel、Fish、Green、GreyおよびZebraという言葉の電子アイテム3内の場所を含むアイテムインデックス7402を有する。
マスタインデックス7404もユーザ装置104のメモリに格納される。典型的に、マスタインデックスは、ユーザ装置104によってアクセス可能なメモリ各に提供され、それぞれのメモリに格納された電子アイテム全てで使用される言葉を含む。マスタインデックス7404は、それぞれのメモリに格納された電子アイテムのいずれかで使用された言葉のリスト7406を含む。各言葉に対して、マスタインデックスは、1つ以上のアイテムインデックスエントリへの参照7408を含む。参照は、言葉が出現する電子アイテムの識別子、電子アイテムで言葉が出現する回数(発生回数)、およびその言葉に対応するアイテムインデックスの場所(例えば、アイテムインデックスのどのエントリか)を含み得る。例えば、マスタインデックスの「Apple」という言葉には、参照「1−3−1」が添付されて、その言葉が第1の電子アイテムで出現すること、そのアイテムに3回出現すること、および、その電子アイテムに対するアイテムインデックスの第1のエントリであること、を示す。別の例として、「Brown」という言葉には、2つの参照「2−2−2」と「N−4−1」が添付される。参照「2−2−2」は、「Brown」という言葉が第2の電子アイテムで出現すること、そのアイテムで2回出現すること、その電子アイテムに対するアイテムインデックスの第2のエントリであること、を示す。参照「N−4−1」は、「Brown」という言葉が第Nの電子アイテムで出現すること、そのアイテムで4回出現すること、その電子アイテムに対するアイテムインデックスの第1のエントリであること、を示す。
図75は、例えば、メモリ6602または6612等のメモリに電子アイテム、アイテムインデックス、およびマスタインデックスを格納され得る1つの例示的な方式を模式的に図説する。示すように、メモリ6602は、1つ以上の電子アイテムデータ構造7500、1つ以上のアイテムインデックスデータ構造7502、および1つ以上のマスタインデックスデータ構造7504を含む。データ構造7500、7502および7504の各々は、データ構造の開始を指定するヘッダフィールド、それぞれのコンテンツまたはインデックスを含むコンテンツまたは本文フィールド、およびデータ構造の終了を指定する終了フィールド等を含み得る。データフィールドのいずれも、電子アイテムまたはインデックスの名前またはタイトル、作成日、作成者、データ構造のバイト数、インデックス作成順序等のようなデータ構造に関するメタデータを含み得る。データ構造7500、7502および7504は例であり、実際には、データ構造は1つ以上のいずれかの数のデータフィールドを有する。
この簡単な例においては、1つの電子アイテムデータ構造7500と1つのアイテムインデックスデータ構造7502だけがメモリ6602に示される。しかし、実際にはどのような数の電子アイテムデータ構造および対応するアイテムインデックスデータ構造でもメモリに格納され得る。また、一般的に1つのマスタインデックスデータ構造だけがメモリに格納されるが、一部の場合においては、複数のマスタインデックスデータ構造が存在し得る(例えば、以下に詳細を述べる結合の間)。
E.5.検索インデックスを取得する例示的な方法
上記で述べたように、電子アイテムの検索を容易にするために検索インデックスが使用される。ユーザ装置104が電子アイテムを受信すると、アイテムの検索インデックスが取得されるまで、アイテムは検索可能ではあり得ない。1つの実施形態において、ユーザ装置104は、サーバまたは他のリモートのデータストアからインデックスをダウンロードすることによって、または装置でインデックスを生成することによって、検索インデックスを取得し得る。他の実施形態において、インデックスは、これに加えてまたは代替として、ユーザのパーソナルコンピュータで生成することによって、または他のいずれかの適切な様式で取得し得る。
図76は、電子アイテムの検索インデックスを取得する例示的な方法7600のフローチャートで、便宜のためにユーザ装置104の状況で説明するが、他のユーザ装置にも適用し得る。方法7600は、7602で、ユーザ装置104で電子アイテムを受信すると開始する。7604で、ユーザ装置104は、電子アイテムの検索インデックスを取得する様式を決定する。7606で、検索インデックスをダウンロードするか生成するかどうかの決定が行われる。検索インデックスをダウンロードするか生成するかどうかの決定は、例えば、インデックスのサイズおよび/またはインデックスをダウンロードとした場合とインデックスを生成した場合のリソースコストの比較等、いくつかの様々な因子に基づくことがあり得る。
検索インデックスを生成すると決定した場合、7608で、ユーザ装置104のインデックスモジュール6608は、装置によってインデックスが作成されるアイテムのキューに電子アイテムを追加する(例えば、図73に示したリスト)。そして、キューの優先順またはユーザが指定した順序でインデックスが生成される。検索インデックスをダウンロードすると決定した場合、7610で、ユーザ装置104は検索インデックスをダウンロードする(例えば、タスクリスト処理モジュール334を使用する)。インデックスが生成またはダウンロードのいずれかによって取得されると、7612で、検索モジュール6610によって検索されるために、インデックスはユーザ装置104のメモリに格納される。
図77は、電子アイテムにこのようなインデックスを生成する1つの例示的な方法7700の詳細を示すフローチャートである。方法7700は、上記に示したハイブリッド型インデックス作成アプローチを使用して実現される。しかし、代替として他のインデックス作成が使用され得る。したがって、7702で、言葉の検索可能なアイテムインデックスが生成され、電子アイテムに出現する言葉の場所の体系化されたリストを含む。上記に示したように、アイテムインデックスは、アルファベット順、電子アイテム内の出現順、電子アイテム内の発生数順等、いずれかの適切な順序で体系化され得る。
1204で、言葉の検索可能なマスタインデックスが生成され、一群の電子アイテム内のいずれの電子アイテムでも使用される言葉のリストを含む。各言葉に対して、マスタインデックスは、それぞれの言葉の各アイテムインデックスエントリへの参照も含む。このように、言葉が5つの電子アイテムで出現すると、マスタインデックスは、各電子アイテムに対して1つずつ、アイテムインデックスエントリに対する5つの参照を有し得る。アイテムインデックスエントリへの参照は、中でも、言葉が出現する電子アイテムの識別子、それぞれの電子アイテムで言葉が出現する回数、およびそれぞれの電子アイテムに対してアイテムインデックス内で言葉がインデックスされている場所を含み得る。マスタインデックスは、最終的に、ユーザ装置104のメモリに格納された複数の電子アイテムからまたは一群の電子アイテムからの言葉を含み得る。しかし、方法7700のこの段階では、1つの電子アイテムだけのインデックスが作成されているので、マスタインデックスは、1つのインデックスされた電子アイテムからの言葉だけを含み得る。
7706で、ユーザ装置104のメモリに格納された一群の電子アイテムに、追加の電子アイテムを追加し得る。7708で、追加した電子アイテムの言葉の検索可能なアイテムインデックスが生成され、7710で、マスタインデックスは、追加した電子アイテムからの用語を含むように、更新される。このように、追加の電子アイテムが追加されると、それぞれで使用される言葉は、マスタインデックスに追加されるので、ユーザ装置104でテキスト検索可能になる。
インデックス生成プロセス中のある時点、7712で、インデックス生成の状況がユーザに表示され得る。状況は、画面7300のようなインデックス状況画面によって、または他のいずれかの適切な表示方法によって、表示され得る。他の例においては、インデックス作成状況は、コンテンツ管理画面、ホーム画面または他のいずれかの便利な様式において表示され得る。7714で、ユーザに優先度インタフェースを提示することができ、これによって、ユーザはインデックスが生成される順序を設定または変更できる。優先度インタフェースは、インデックス状況表示と組み合わせられ得るが、または別のインタフェースでもあり得る。インデックス状況および/または優先度インタフェースの表示は、方法7700のいずれかの時点で発生し得、必ずしも図77に示した順序で発生しない。また、インデックス状況および/または優先度インタフェースは、何らかのイベントの発生時(例えば、新しい電子アイテムの受信)、および/またはユーザの要求時に自動的に表示され得る。
検索およびインデックス作成は、プロセッサに比較的負荷がかかる動作である傾向が強い。このように、プロセッサ6600の速度および処理リソースに応じて、インデックス作成は、プロセッサ6600で実行中の他のプロセスを妨害、および/または遅延させ得る。いずれかの妨害または遅延を回避するために、一部の実施形態では、7706で、プロセッサによって他の動作が実施されている間、インデックス作成は一時停止または減速され得る。インデックス作成を一時停止または減速するかどうかは、プロセッサ6600によって実行される他の動作の相対的な重要性に依存する。つまり、インデックス作成は、他のプロセッサ動作がインデックス作成動作よりも高い優先度である場合のみ、一時停止または減速され得る。一般的に、ユーザによって、またはリモートの演算装置(例えば、アイテム提供システム102)によって要求される動作は、インデックス作成よりも高い優先度となる。しかし、多様な動作の優先度は、どのような希望順序にも設定され得る。
インデックスが一時停止され得るいくつかの例示的な例は、マーチャントストアから対話中またはアイテムの購入中、コンテンツ配信モジュールまたは個人メディアライブラリからのアイテムのダウンロード中、インターネットを閲覧中、表示を更新中等を含む。一部の場合においては、実施される他の動作は、プロセッサの処理リソースを完全に要求することがない場合がある、および/または断続的な処理だけを要求し得る。これらの事例においては、インデックス作成は、一時停止ではなく、単に減速され得る。インデックスが減速され得るいくつかの例示的な例は、オーディオ再生モジュール410を使用してオーディオアイテムを生成中およびインターネットの閲覧中を含む。もちろん、他の多様な実施形態において、インデックス作成は、処理が必要なこれらのおよび/または他のいずれかの動作に応答して、一時停止または減速され得る。一時停止および/または減速は、方法7700のいずれの時点でも発生し得、必ずしも図77に示した順序で発生しない。
7718で、該群に別のアイテムが受信または追加されていた場合、方法は、各追加の電子アイテムに対して、7706〜7716の動作を繰り返す。現在追加のアイテムが追加されていない場合、新しい電子アイテムを受信するまで、方法7700は終了する。
新しい電子アイテムの検索インデックスを生成する代わりに、ユーザ装置は、アイテム提供システム102等のリモートの演算装置から検索インデックスをダウンロードすることを決定し得る(図76の動作7606)。検索インデックスのダウンロードは、図78〜82を参照して以下に説明する。
図78は、電子アイテムに検索インデックスをダウンロードする1つの例示的な方法7800の詳細を示すフローチャートである。方法7800の動作の一部は、ユーザ装置によって実行される(「装置側動作」)として説明されるが、他の動作は、アイテム提供システム102のようなリモートの演算装置によって実行される(「サーバ側動作」)として説明される。一般的に、リモートの演算装置は、ユーザ装置104に比べて、スピードが速く、処理能力が高く、および/または電力制約が少ないことがあり得る。したがって、場合によっては、リモートの演算装置にインデックスを生成させてから、ユーザ装置104に送信することが有益となり得る。
方法7800は、リモートの演算装置からユーザ装置104に電子アイテムを送信する前または後のいつでも実行され得る。7802で、リモートの演算装置は、電子アイテムの言葉の検索可能なアイテムインデックスを生成し、7804で、電子アイテムの言葉の検索可能なアイテム特有のマスタインデックスを生成する。アイテム特有のマスタインデックスは、場合によっては、電子アイテムで使用される言葉だけから構成し得る。他の場合(例えば、複数の電子アイテムが次々に近い時間帯に送信された、または送信予定である場合)においては、アイテム特有のマスタインデックスは、複数の電子アイテムで使用される言葉を含み得る(例えば、近い時間帯に送信されたまたは予定のアイテム)。
7806で、1つ以上のユーザ装置104に送信される可能性があるアイテムおよびアイテム特有のマスタインデックスは、リモートの演算装置のメモリに格納される。インデックスは、7808で、1つ以上の公知の圧縮技術を使用して、圧縮され得る。まだ送信されていない場合、7810で、電子アイテムはユーザ装置104に送信され得る。電子アイテムの送信と同時に、またはその次に、7812で、検索インデックスはユーザ装置104に送信され得る。検索インデックスの送信は、以下に詳細を説明する多様な様々な因子またはビジネスルールに依存し得る。代替として、検索インデックスは、対応する電子アイテムと共にまたはその後に自動的に送信され得る。
7814で、ユーザ装置は、リモートの演算装置によって送信された電子アイテムを受信し、7816で、検索インデックスを受信し得る。7818で、電子アイテムは、ユーザ装置104のメモリに格納され、受信していた場合には、対応するアイテムインデックスも格納される。7820で、ユーザ装置104は、既存のマスタインデックスが受信した電子アイテムの言葉を含むように更新されるように、アイテム特有のマスタインデックスを既存のマスタインデックスに統合する。
図79は、電子アイテムの検索インデックスをダウンロードするかどうかを決定するために、ユーザ装置104のようなユーザ装置によって実現され得る例示的な方法7900の詳細を図説するフローチャートである。方法7900は、例えば、方法7600の動作7606に、および/または方法7800の動作7814から7816の間に、実現され得る。方法7900は、7902で、リモートの演算装置から電子アイテムを受信すると開始する。7904で、ユーザ装置104は、リモートの演算装置から、電子アイテムの検索インデックスを利用できるかどうかを示すヒントを受信する。実際には、ヒントは、電子アイテムとは別に、または電子アイテムと共に送信され得る(例えば、電子アイテムのヘッダフィールドのフラグとして)。
ヒントに少なくとも部分的に基づいて、7906で、ユーザ装置104は、ダウンロード用の検索インデックスが利用可能であるかどうかを決定する。7906で、ユーザ装置がダウンロード用の検索インデックスが利用可能であると決定すると、7908で、ユーザ装置104は、リモートの演算装置から検索インデックスを要求する。検索インデックスを要求した後ある時点で、7910で、ユーザ装置104は、要求したインデックスを受信したかどうかを確認し、受信した場合は、アイテムインデックスをメモリに保存して、アイテム特有のマスタインデックスを既存のマスタインデックスに統合する。
7906で、ユーザ装置104は、検索インデックスが利用可能でないと決定すると、電子アイテムは、ユーザ装置104でインデックスを作成するアイテムのキューに追加される。場合によっては、ユーザ装置104のインデックス作成モジュール6608が遅れると(例えば、インデックスを作成するアイテムのキューが既定の閾値を超える)、ユーザ装置104は、検索インデックスをダウンロードするように再要求し得る。一部の実施形態において、ユーザ装置は、ヒントが電子アイテムの検索インデックスが利用可能であると示していた場合にのみ、インデックスを再要求し得る。7918で、ユーザ装置104は、インデックスを受信したかどうかを確認し、受信した場合は、アイテムインデックスをメモリに保存して、アイテム特有のマスタインデックスを既存のマスタインデックスに統合する。
7918で、装置がインデックスを受信していないと決定すると、ユーザ装置は次に、7920で、図77を参照して一般的に説明したように検索インデックスの生成を開始する。7922で、インデックス生成に失敗すると、インデックスモジュール6608は、既定回数(例えば、3回)、電子アイテムのインデックス再生を再試行する。インデックス動作が既定回数失敗すると、インデックスモジュール6608は、電子アイテムのインデックス作成の試行を停止し、プロセスは、ユーザ装置104が次に再起動されるまで終了し得る。インデックス作成試行回数に対するこの制限によって、不必要なプロセッサのサイクルが防止され、したがって、電子アイテムが破損またはインデックス不能な場合にバッテリの電力を節約する。
図80は、検索インデックスをリモートのユーザ装置104に送信するかどうかを決定するために、アイテム提供システム102のような演算装置によって実現され得る例示的な方法8000の詳細を図説するフローチャートである。方法8000は、図79に示した装置側方法に対する当然の結果として、並行に実施される。8002で、アイテム提供システム102は、電子アイテムをユーザ装置104に送信し、8004で、電子アイテムの検索インデックスが利用可能であるかどうかを示すヒントを送信する。ヒントが電子アイテムの検索インデックスが利用可能であることを示した場合は、8006で、アイテム提供システム102は、電子アイテムに対応する検索インデックスに対する、ユーザ装置104からの要求を受信し得る。
検索インデックスの要求を受信すると、アイテム提供システム102は、1つ以上のビジネスルールを適用し、8008で、要求された検索インデックスを送信するかどうかを決定する。ビジネスルールは、要求されたインデックスを送信するかどうかを決定する1つ以上の因子を指定する。ビジネスルールは、以下のような因子に基づくことができるが、これらは例のためであって、これに限定されない。
ユーザ装置104のユーザが検索インデックスを受信するように承認されているかどうか(例えば、ユーザが優待アカウントを持っている場合にのみ送信する)、
検索インデックスの対価を受領しているかどうか、
検索インデックスの要求を何時に受信したか(例えば、オフピーク時の間の要求だけに送信する)、
検索インデックスのサイズ(例えば、既定サイズを超える場合または下回る場合にのみ送信する)、
アカウントタイプ(例えば、ユーザ装置がWiFiを経由して接続、コンピュータ経由のユニバーサルシリアルバスを経由して接続されている場合にのみ送信する)、および/または
検索インデックスが対応する電子アイテムのタイプ(例えば、本のインデックスは送信するが、定期刊行物のインデックスは送信しない)。
1つ以上のビジネスルールのいずれもが、要求されたインデックスを送信するかどうかを決定するために、どのような組み合わせでも適用され得る。ビジネスルールを適用後、アイテム提供システム102は、8010で、要求されたインデックスを送信するかどうかを決定する。送信する場合は、8012で、要求されたインデックスはユーザ装置104に送信され、プロセスは、別のアイテムがユーザ装置に送信されるまで終了する。8010で、アイテム提供システム102が要求されたインデックスを送信しないと決定する場合、アイテム提供システム102は何も実行し得ない。代替として、アイテム提供システム102は、検索インデックスが提供されないことを示す、および/またはユーザに検索インデックスを受信するために優待サービスにアップグレードするように誘う広告を送信するメッセージを送信し得る。
8014で、アイテム提供システム102は、検索インデックスの再要求を受信し得、ユーザ装置によるインデックスを作成するアイテムのキューが既定の閾値を超えることが示される(つまり、装置はバックログになっている)。再要求は、アイテム提供システム102に代替ビジネスルールを適用させるような要求を含み得る。代替として、アイテム提供システム102は、これが検索インデックスに対する2番目または次の要求であることを認識し、代替ビジネスルールを提供するように独立的に決定し得る。いずれにしろ、8016で、アイテム提供システム102は、1つ以上の代替ビジネスルールを適用して、検索インデックスを送信するかどうかを決定する。代替ビジネスルールは、通常のビジネスルールに関して上記に列挙したような因子に加えて、例えば、ユーザ装置でインデックスが作成される電子アイテムのキューが既定の閾値を超えるかどうかのような他の因子に基づくことがあり得る。
8018で、アイテム提供システム102が、再要求されたインデックスを送信すべきであると決定すると、8012で、要求されたインデックスがユーザ装置104に送信され、プロセスは、別のアイテムがユーザ装置に送信されない限り/送信されるまで終了する。8018で、アイテム提供システム102が、再要求されたインデックスがまだ送信されるべきではないと決定すると、8020で、アイテム提供システム102は何も動作を実行しない、拒否メッセージを送信する、または広告を送信する(例えば、優待アカウントへのアップグレード)、ことがあり得る。
図81は、ビジネスルールと代替ビジネスルールとを含むビジネスルールデータ構造8100を模式的に図説するが、データ構造は、例えば、アイテム提供システム102のメモリ等、メモリに格納され得る。示されるように、ビジネスルールデータ構造8100は、特に、データ構造の開始を指定するヘッダフィールド8102、1つ以上のビジネスルールを含むビジネスルールフィールド8104、1つ以上の代替ビジネスルールを含む代替ビジネスルールフィールド8106、およびデータ構造の終了を指定する終了フィールド8108を含む。いずれのデータフィールドも、設定されたビジネスルールの名前またはタイトル、ビジネスルールの作成日、ビジネスルールをいつ適用するか等、データ構造に関するメタデータを含み得る。データフィールドは例に過ぎず、実際には、データ構造は1つ以上のいずれの数のデータフィールドをも有し得る。例えば、ビジネスルールおよび代替ビジネスルールは、個別のデータ構造に格納され得、指定された状況に応じて個別に呼び出され得る。
図82は、装置側方法7900とサーバ側方法8000による通信8200のフローを図説する信号の流れ図である。信号の流れ図8200は、8202で、ユーザ装置による1つ以上の電子アイテムに対する要求で開始する。要求はアイテム提供システム102で受信されてから、いずれもの必要な支払および/または認証の後、8204で、要求された電子アイテムがユーザ装置104に送信される。電子アイテムの送信と同時にまたは送信後に、8206で、電子シテムに対する1つ以上の検索インデックスの可用性を示すヒントが、アイテム提供システム102から、ユーザ装置104に送信される。ヒントが、電子アイテムの検索インデックスが利用可能であることを示すと、8208で、ユーザ装置104は検索インデックスを要求する。利用可能でなければ、ユーザ装置は、電子アイテムを、ユーザ装置でインデックスを作成するアイテムのキューに追加して、8214に進む。
8210で、アイテム提供システム102は、検索インデックスに対する要求を受信して、ビジネスルールを適用して要求された検索インデックスを送信するかどうかを決定する。8212で、アイテム提供システム102は、要求されたインデックスを送信するか、メッセージを送信するか(例えば、要求を拒否、広告を送信する等)、または何も実行しないか、のいずれかを実行する。ユーザ装置104が要求したインデックスを受信すると、プロセスは8214で終了する。受信しない場合は、ユーザ装置104は、装置でインデックスを作成するアイテムのキューが既定の閾値を超えない限り/超えるまで、装置でインデックスを生成する。既定の閾値を上回ると、ユーザ装置は、8216で、検索インデックスを送信するように再要求し得る。8218で、アイテム提供システム102は再要求を受信し、代替ビジネスルールを適用して、検索インデックスを今送信するかどうか、ユーザ装置104がバックログかどうかを決定する。代替ビジネスルールに基づいて、アイテム提供システム102は、要求された検索インデックスを送信するか、メッセージを送信するか、何も実行しないか、のいずれかを実行する。
E.6.例示的な検索技術
インデックス作成と同様に、検索は、プロセッサに比較的負荷がかかる動作である。したがって、過去の携帯型装置は、インターネット検索等を実行するために、リモートの演算装置のより大型の処理能力を活用してきた。しかしながら、リモートの演算装置上で検索を実行することは、携帯型装置がリモートの演算装置と通信ができない場合、検索を実行できないことを意味する。したがって、状況によっては、検索を携帯型装置上で実行することが望ましい場合がある。しかしながら、携帯型装置で検索を実行することは、携帯型装置のプロセッサに負荷がかかることになり、結果として、より多くの電力を使用する。
図83は、処理を最小限にすることによってバッテリ消費を最小限にするように設計された1つの例示的な検索方法8300の注釈付きフローチャートであり、ユーザ装置104を参照して説明するが、他の携帯型装置に幅広く適用可能である。方法8300は、8302で、Q個の検索クエリ語を受信すると開始する(この事例において、言葉は「Blue」と「Fish」)。言葉はスペースによって分割され、論理演算子がないため、ユーザ装置104の検索モジュール6610は、検索クエリを暗示的な「近接」演算として処理する。つまり、検索は、相互の既定の近接範囲内に配置された2つのクエリ語を探す。
8304で、ユーザ装置104は、マスタインデックス内のクエリ語を発見する(発見した言葉はマスタインデックスで太字で表示されている)。8306で、ユーザ装置104は、各電子アイテムで各言葉が出現する回数を決定し、各クエリ語のインスタンスを少なくとも1つ有する電子アイテムのリストを生成する。各クエリ語のインスタンスを少なくとも1つ有する電子アイテムのリストは、ブロック8306の右側に示される。
8308で、ユーザ装置104は、ロジックを適用して、各電子アイテムのファジー因子(71)を決定する。ファジー因子は、最小の処理を使用して派生可能な数字であるが、各電子アイテムが既定の相互近接(つまり、近接値またはNV(near value))内で検索したクエリ語を有する比較的高い可能性を示す。一般的に、クエリ語のインスタンス数が多ければ多いほど、一部のクエリ語は相互の近接値内に発見される可能性が高い。例示的な実施形態において、ファジー因子は、各クエリ語のインスタンス数の平均から成る(アイテム2の場合、12と2の平均で7である)。しかし、他の実施形態では、適切なファジー因子を決定する他のロジックが使用され得る。例えば、別の実施形態において、ファジー因子は、全てのクエリ語の最小インスタンス数に等しくなり得る。この代替ロジックを適用すると、アイテム2のファジー因子は2になる(第2のクエリ語のインスタンス数)。
方法8300の注釈付きフローチャートは、図84に続く。8310で、各クエリ語のインスタンスを少なくとも1つ有する電子アイテムのリストは、ファジー因子に基づいてソートされる。ソートされたリストから、8312で、ユーザ装置は、既定の相互の距離(つまり近接値)内に存在するクエリ語を有する既定数のR件のエントリを特定する。距離は、文字数、単語数、バイトのオフセットまたは他のいかなる距離測定等の単位でも計算され得る。近接値未満離れて存在する用語を有する電子アイテムに対するエントリは、近接値一致(NVM)を有すると言う。ブロック8312の右側のリストの5つのエントリ(太字で表示)はNVMを有する。近接値は、固定数(例えば、1、2、3またはこれ以上の単位離れている)または変数になり得る。例えば、近接値は、電子アイテムの長さ、入力された検索クエリ語の数(例えば、3つの検索語がクエリされると、2つの検索語だけがクエリされる場合よりも、さらに離れている可能性がある)、電子アイテムの単語の平均サイズ、および/または検索クエリ語の相互の近接に影響を与える他のいずれの因子によっても増加する場合がある。
8314で、近接値一致を有する既定のR個のアイテムが、次に、図71に示した様式に類似の様式でユーザに表示される。最も多くの近接値一致を有する電子アイテムが先頭にリストされるが、近接値一致を有する電子アイテム内で検索が開始されると、開いている電子アイテムが先頭にリストされる。
ユーザが、8316で、次のR件の結果を表示するように要求すると、方法はブロック8312に戻って、1つ以上の近接値一致を有する次のR件のエントリを特定する。そうでなければ、方法は8318に進み、ユーザ装置104は、ユーザが検索結果のうちの1つのインスタンスを表示するように要求したかどうかを決定する。要求していない場合、方法は、次の検索が実施される、または検索の範囲が変更されるまで、終了する。8318で、ユーザが検索結果エントリのインスタンスを表示するように要求すると、ユーザ装置は、図72に示した様式と類似の様式で、要求した検索結果エントリのうちの最初のS件のインスタンスを表示する。
図85は、ファジー因子を決定するためのロジックと近接値を決定するためのロジックを含むファジー因子データ構造8500を模式的に示し、これは、例えば、ユーザ装置104のメモリ等、メモリに格納され得る。示すように、ファジー因子データ構造8500は、特に、データ構造の開始を指定するヘッダファイル8502、各電子アイテムのファジー因子を演算するためのロジックを含むファジー因子データフィールド8504、近接値を決定するためのロジックを含む近接値フィールド8506、およびデータ構造の終了を指定する終了フィールド8508を含む。データフィールドのいずれも、ファジー因子または近接値の名前またはタイトル、データ構造の作成日、ファジー因子または近接値をいつおよび/またはどのように適用すべきかの指示等、データ構造に関するメタデータを含み得る。データフィールドは例に過ぎず、実際には、データ構造は1つ以上のいずれかの数のデータフィールドを有し得る。例えば、ファジー因子フィールドおよび近接値フィールドは、個別のデータ構造に格納され、指定された状況に応じて個別に呼び出され得る。
E.7.例示的なハッシュ技術
ユーザ装置104のようなユーザ装置が、制御外のイベントを経験すると(「ホールセールイベント」)、ユーザ装置104は、そこに保管された電子アイテムが変化したかどうかを知り得ない。ホールセールイベントは、ユニバーサルシリアルバスプラグまたは他のデータ接続の接続または切断、装置の電源の入または切、着脱式メモリの接続または取り外し、装置の休眠状態から活動状態への変化、電子アイテムを装置にダウンロードすること、または、ユーザ装置104の制御外の他のいずれかのイベントを含み得るが、これらは例であって、これらに制限されるものではない。
電子アイテムが追加、削除または変更された場合、1つ以上のインデックスを更新することが必要になり得る。例えば、アイテムが追加または変更された場合、アイテムはインデックスを作成またはインデックスを再作成することが必要になり得る。アイテムが削除された場合、インデックスは削除すること、または言葉を削除するように更新することが必要になり得る。同様に、検索結果も、アイテムの追加や削除を反映するように更新することが必要になり得る。
ユーザ装置上の電子アイテムが変化したかどうかを決定する1つの方式は、装置のメモリ内に格納したインデックスを装置上のアイテムの現在のディレクトリと比較するだけである。しかし、上記に述べたように、携帯型装置上の処理リソースは貴重である。したがって、可能な場合には、特に、プロセッサに負荷がかかる動作の場合には、どのような不要な処理動作も避ける事が望ましい。装置のメモリに格納されたインデックスを装置上のアイテムの現在のディレクトリに比較することは、プロセッサに負荷がかかる動作になる可能性があり、ユーザ装置上のコンテンツはホールセールイベント中に変化していないので、多くの場合不要である。
図86は、装置上のコンテンツがイベント中に変化したかどうかを決定する1つの例示的な方法8600のフローチャート(図87の続き)で、ユーザ装置104を参照して説明するが、他の携帯型装置に広く適用可能である。一般的に、方法8600は、ユーザ装置上に保管された電子アイテムのディレクトリにハッシュ関数を適用して、イベントの前と後にディレクトリの比較的小さいハッシュを生成することによって、実現される。ハッシュは、ユーザ装置104上に保管した電子アイテムがイベント中に変化したかどうかを正確に決定するために比較され得るディレクトリの指紋として機能する。
より具体的には、方法8600は、8692で、ホールセールイベント等、イベントの前に装置上の電子アイテムのディレクトリの第1のハッシュを生成するハッシュ関数を適用するステップを含む。1つの実施形態において、ハッシュ関数は、メッセージダイジェストアルゴリズム4(MD4)ハッシュ関数、メッセージダイジェストアルゴリズム5(MD5)ハッシュ関数、またはセキュアハッシュアルゴリズム1(SHA−1)ハッシュ関数を含む。しかしながら、他の実施形態は、ハッシュしたディレクトリ内の小さい変化を反映することになる比較的小さい指紋を提供する、他のいずれのハッシュ関数も使用され得る。誤差許容、速度、サイズ等、指定の用途の多様な設計考慮事項に応じて、様々なハッシュ関数が使用され得る。8604で、ハッシュ関数は、イベント後の電子アイテムのディレクトリの第2のハッシュを生成するように、再び適用される。第1と第2のハッシュが、8606で比較されて、ディレクトリが変化したかどうかを決定する。8608で、ハッシュが一致することがわかると、方法は、8610で、ユーザ装置104上の電子アイテムはイベント中に変化していないことを認識する。このように、インデックス作成は不要なのに実施されるということはなく、プロセスが終了して、ユーザ装置104のバッテリ寿命を節約する。
8608で、ハッシュが一致しない場合、方法は8612に進み、キャッシュに保管されたいずれの検索結果も削除する。これは、ハッシュが一致しない場合、つまり、キャッシュした検索結果は、もはや装置のメモリに格納された電子アイテムを正確に反映し得ないことを意味するからである。例えば、イベント中に電子書籍が削除された場合、削除された電子書籍を含むいずれのキャッシュされた検索結果も不正確になる。対照的に、イベント中に電子アイテムが追加された場合、キャッシュされた検索結果は、追加された電子アイテムのクエリされた言葉のどのインスタンスも含まないことになる。
方法8600のフローチャートは、図87に続く。8614で、ディレクトリの電子アイテムが選択され、8616で、ユーザ装置104は、選択されたアイテムがマスタインデックスに出現するかどうかを決定する。アイテムは、ディレクトリのエントリ順、アルファベット順、最新の変更順、または他のいずれの所望の順序でも選択し得る。8616で、アイテムがマスタインデックスにない場合、ユーザ装置は、アイテムが追加されていたと決定し、8618で、検索インデックスを取得する(例えば、ダウンロードまたは生成することによる、図76を参照)。
アイテムがマスタインデックスにある場合、8620で、ユーザ装置104は、電子アイテムに対するディレクトリの特徴(例えば、サイズや変更時間)を電子アイテムに対するマスタインデックスエントリに比較して、エントリが一致するかどうかを確認する。8620で、ユーザ装置がディレクトリとマスタインデックスのエントリが一致しないと決定した場合、8622で、ユーザ装置104は、マスタインデックスからアイテムのエントリを消去して、アイテムに対するアイテムインデックスを削除し、8618に進み、アイテムの検索インデックスを再びダウンロードまたは生成する。8620で、ユーザ装置がディレクトリとマスタインデックスのエントリが一致すると決定すると、8624で、ユーザ装置104は、ディレクトリに他のいずれかのアイテムが存在するどうかを確認し、存在する場合は、ディレクトリの各アイテムに対してブロック8614に戻る。
8618で、検索インデックスのダウンロードまたは生成を開始後、ユーザ装置は、ディレクトリに他のいずれかのアイテムが存在するかどうかも確認し、存在する場合は、ディレクトリの各アイテムに対してブロック8614に戻る。
ディレクトリの全てのアイテムが比較されて、ユーザ装置104が、8624で、ディレクトリには確認するアイテムはもう残っていないと決定すると、方法8600は次に進み、マスタインデックスからアイテムのエントリを選んで、ディレクトリに存在するかどうかを確認する。具体的に、8626で、ユーザ装置104は、マスタインデックスからアイテムを選択し、8628で、選択したアイテムがディレクトリに出現するかどうかを確認する。選択したアイテムが、8628で、ディレクトリにあることがわかると、ユーザ装置104は、8630で、マスタインデックスに他のアイテムが残っているかどうかを確認し、残っている場合は、マスタインデックスの各アイテムに対して、動作8626と8628を繰り返す。
8628で、アイテムがディレクトリ内にない場合、8632で、アイテムに対するエントリがマスタインデックスから消去され、アイテムインデックスが削除され、方法はブロック8630に進んで、マスタインデックスにまだエントリがあるかどうかを確認する。
E.8.例示的な拡張可能な検索/インデックス作成技術
アイテム提供システム102によって作成されるコンテンツは、上記に説明した技術のうちの1つ以上を使用して、ユーザ装置104によって容易にインデックスを作成および検索され得る。しかしながら、第三者によって提供されるアプリケーションおよび他の電子アイテムは、ユーザ装置104が第三者のアイテムで言葉がどこでおよびどのように使用されるかを決定する方式を有するまでは、容易に検索され得ない。ユーザ装置104に第三者のアイテムのインデックス作成を可能にする1つの方式は、1つ以上のプラグインの使用を介することである。プラグインは、アイテム提供システム102によって、または介して、提供されるアプリケーションおよび電子アイテムに関連して使用され得る。一般的に、プラグインは、メインアプリケーションの1つ以上の既定のアプリケーションプログラミングインタフェース(API)を呼び出すアプリケーションである。この場合、APIは、標準のインタフェースを提供して、第三者に、ユーザ装置104のプログラムおよびモジュールと対話するプラグインを作成することを可能にする。
図23は、プラグインの使用を一般的に図説する模式図で、ユーザ装置104並びに他のいずれかの適切なユーザ装置に適用可能である。一般的に、ソフトウェア開発キット(SDK)の一部として、ソフトウェア開発者には、1つ以上のAPIが提供され得る。これらのAPIを使用して、開発者は、プラグイン8800、プログラム、またはユーザ装置104上に保管されたプログラムやモジュールと対話することができる他の電子アイテムを作成することが可能である。プラグイン8800は、ローカルに保管した電子アイテム8802、リモートに保管した電子アイテム8804、ローカルまたはリモートの第三者の電子アイテム8806、および/またはウェブデータ、証券コード、天気モジュール等の他のタイプの電子データアイテムのように、多様な様々なタイプの電子アイテムにインデックスを作成および/または検索するために、使用され得る。
プラグイン8800は、ユーザ装置104に登録、および/またはユーザ装置104とデータを交換するために、1つ以上のAPIを使用し得る。ユーザ装置104の検索とインデックスモジュール6610と6608も、1つ以上のAPIを呼び出して、プラグインからインデックス情報を要求することができる。このように、検索とインデックスのモジュール6610と6608は、アイテムで使用される用語や電子アイテムのこれらの用語の場所等、電子アイテム8802〜8808にインデックスを作成および検索するために必要な情報を受信できる。
1つの実施形態では、ユーザ装置104が電子アイテムを受信すると、インデックスモジュール6608はAPIを呼び出して、電子アイテムに含まれる言葉と電子アイテム内の各用語の場所を使用できるようにする。その言葉が使用できるようになると、インデックスモジュール6608は、電子アイテム内の言葉の検索可能なアイテムインデックスを生成して、APIを使用して使用できるようになった言葉を含むように、利用可能な一群の電子アイテム内の用語の検索可能なマスタインデックスを更新することによって、電子アイテムのインデックスを作成する。
代替として、インデックスの作成は、アイテム提供システム102のような演算装置によって実行され得る。この場合、用語が使用可能になると、アイテム提供システム102は、電子アイテムの言葉のアイテムインデックス、および電子アイテム内の言葉のアイテム特有のマスタインデックスを生成し得る。アイテムインデックスとアイテム特有のマスタインデックスは、次に、ユーザ装置104のようなユーザ装置に送信され得る。
多様なAPIが提供され得、これらは、ユーザ装置104の1つ以上のモジュール、プラグイン8800、および/または1つ以上の電子アイテム8802〜8808自体によって呼び出されることが可能である。例えば、プロセッサを経由して、インデックスモジュール6608によって呼び出すことが可能なインデックスAPIは、電子アイテムに含まれた言葉と、電子アイテム内の各言葉の場所を使用できるように提供され得る。プロセッサを経由して、検索モジュールによって呼び出すことが可能な検索APIは、電子アイテム内の場所のエントリに応答して、電子アイテムに含まれた言葉を使用可能にするように提供され得る。プロセッサによって呼び出すことが可能なナビゲーションAPIは、電子ブックリーダを電子アイテム内に入力された場所に対応する場所に移動させるように提供され得る。
E.9.他の例示的な検索技術
ローカルに保管された電子アイテムの検索とインターネットを直接検索することに加えて、状況によっては、1つ以上の検索エンティティを使用して、検索を支援することが望ましい場合がある。検索によっては、特定のタイプの検索エンティティによって更に容易に処置され得る。例えば、画像検索や質問の形態をとる検索は、コンピュータに実装される検索エンジンまたは検索モジュールを使用する検索クエリに基づいて満足に実施され得ない。
図89および90は、リモートの検索エンティティを使用する例示的な検索方法のフローチャートで、ユーザ装置104を参照して説明するが、他の携帯型装置に広く適用可能である。図89は、該方法の装置側態様を図説し、図90はサーバ側態様を図説する。
図89に示したように、装置側方法8900は、8902で、質問の形態のクエリを受信すると開始する。8904で、検索クエリは、人間の入力に依存して検索結果を生成する検索者エンティティのような、リモートのエンティティに送信される。上記で触れたように、検索者エンティティの例は、CA州Sunnyvale所在のYahoo Inc.から入手可能なYahoo(登録商標)Answers、MD州Bethesda所在のWondir,Inc.、またはWA州Seattle所在のNowNow.comから入手可能なNowNow(登録商標)を含む。
8904で、ユーザ装置104は、検索結果を含む、ブックレットの形態の電子アイテムを受信する。ブックレットは、検索クエリ内の質問に対する1つ以上の回答を含み得る。8906で、ブックレットは、ユーザ装置のメモリに格納される。8910で、ユーザ装置104は、検索インデックスがリモート検索エンティティから利用可能であるかどうかを決定する。1つの実施形態において、この決定は、図79で説明した決定と同様な様式で行われ得る。インデックスが利用可能である場合、8912で、ユーザ装置は、ブックレットの用語のアイテムインデックスと、ブックレットの用語のアイテム特有のマスタインデックスとを受信する。8914で、アイテムインデックスはメモリに格納され、アイテム特有のマスタインデックスは、ユーザ装置104上の既存のマスタインデックスに統合されて、プロセスが終了する。
8910で、インデックスが利用可能でない場合、ユーザ装置は、次に、8916で、ブックレットの言葉のアイテムインデックスを生成し、8918で、ブックレットからの言葉を含むように既存のマスタインデックスを更新する。この様式においては、ブックレットは、ユーザ装置によってテキスト検索可能になる。
図90に示したように、装置側方法9000は、9002で、質問の形態のユーザ装置からのクエリを受信すると開始する。9004で、リモートの検索エンティティは、質問に関して、1人以上の検索者からの入力を受信する。クエリは、ウェブサイト、電子メール、または他のいずれかの適切な配信メカニズムを経由して、検索者に配布され得る。検索者は、インターネット、本、または他のいずれのソースの独自の検索を実行し、質問に対する回答を提供し得る。検索者の回答は、次に、9006で編集されて、9008で、ブックレットのような電子アイテムの形態で、リモートのユーザ装置104に送信される。ブックレットは、検索クエリ内の質問に対する複数の回答を含み得る。一部の実施形態において、方法9000はここで終了し得る。しかしながら、他の実施形態において、リモートの検索エンティティは、9010で、検索インデックスを生成して(例えば、アイテムインデックスとアイテム特有のマスタインデックス)、9012で、検索インデックスをリモートのユーザ装置104に送信され得る。1つの実施形態は、検索インデックスは、図78および80に関する説明と同様な様式で、生成および送信され得る。
多様な例示的な装置およびシステムの実施形態を説明してきたが、これらの実施形態のコンポーネント、モジュールおよび機能は、状況に応じて、再配置、変更、および/または全体を省略され得る。
また、多様な例示的な方法を説明してきたが、状況に応じて、方法の特定の動作は説明した順序で実施する必要がなく、再配置、変更、および/または全体が省略され得ることを理解されたい。
さらに、いずれかの方法に関して上で説明したいずれかの動作は、1つ以上のコンピュータが読取可能なメディア上に格納される命令に基づいて、プロセッサまたは他の演算装置によって実現され得る。コンピュータが読取可能なメディアは、ユーザ装置のプロセッサによってローカルまたはリモートでアクセスできるいずれかの利用可能なメディアであることが可能である。コンピュータが読取可能なメディアは、コンピュータが読取可能な命令、データ構造、プログラムモジュールまたは他のデータ等、情報の格納のためのいずれかの方法または技術において実現された、揮発性および非揮発性、着脱式および非着脱式メディアを備え得るが、これらは例のためであって、これらに限定されるものではない。コンピュータが読取可能なメディアは、RAM、ROM、PROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、DVDまたは他の光学式ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージ装置、または望ましい情報を格納するために使用可能で、ユーザ装置のプロセッサによりアクセス可能な他のいずれかのメディア、を含むが、これらに限定されない。上記のいずれかの組み合わせも、コンピュータが読取可能なメディアの範囲内に含める。
F.例示的な電力管理技術
F.1.例示的な電力管理の概要
本明細書には、電子コンポーネントにおける誤差を補正するための技術が開示される。このセクションで説明する概念は、図4に示し、上記のセクションAで一般的に説明した、電力管理機能412の一部の例を表す。1つの説明された実施形態では、公知の信号をレジスタに提供する。信号は、オペアンプを使用して増幅され、測定される。測定された信号は、レジスタへの入力として提供される信号と比較されて、システムの誤差値を取得する。この誤差は、信号値が増幅時により正確に特徴付けられるように、レジスタに提供される未知の信号に適用される。誤差は、ソフトウェア、ハードウェア、またはこれらの組み合わせを使用して、オペアンプのようなコンポーネントの誤差を補正するために、未知の信号に適用され得る。
別の実施形態によると、電圧信号は、バッテリ寿命をより正確に計測するために、時間の関数として、平滑化される。
別の実施形態によると、電力状態モジュールは、トリガイベントに応答して、装置の電力状態を変更する。トリガイベントは、音声モードを使用して受信され得、データモジュールが送信に利用可能であることを示し得る。例えば、装置は、新しいデータコンテンツが利用可能であることを示す、呼び出し音のようなインジケータを受信し得る。装置は、データモードに切り替わって、コンテンツをダウンロードする。プロセスは、手動、つまり、ユーザの対話が必要な場合も、自動、または半自動、つまり、ユーザの認証を必要とするがこれ以外は自動な場合もある。装置は、データの受信後スタンドバイモードに戻ることができる。いつ新しいデータが利用可能であるかを検知するために音声モードを使用することによって、電力消費を削減し、ユーザ装置に、装置が低電力またはスタンドバイモードにある場合にはデータモジュールを受信することを可能にする。
本明細書で説明する技術は、いくつかの方式で実現することができる。1つの例示的な環境および状況は、添付の図面および継続中の考察を参照しながら、提供される。
F.2.誤差値補正のための例示的なシステム
電流の測定は、典型的に、レジスタ全体の電圧を測定することによって実行される。抵抗値は、数パーセントの誤差内で既知である。しかし、抵抗値、したがって誤差は、通常は、動作範囲を構成する大きいダイナミックレンジの電流の状況で、有用な値を持つために、増幅される。非常に低い電流では、そのレジスタ全体の電圧は非常に低く、オペアンプの誤差またはオフセット電圧が非常に著しくなる。
ハードウェアに内蔵されたオフセット補正を有するオペアンプが利用可能である。しかし、このようなハードウェアは、複雑で高価であり、典型的に、正常に動作するためには機械的な保守が必要である。
図91は、電力管理システムと測定の観点から、表示画面、ソフトウェア等のような、装置9100内で多様なコンポーネントおよびシステムに電力を提供する能力がある、電力コンポーネント9101のシステムを有する、携帯型装置9100を示す。電力コンポーネント9101のうちの1つが、電力供給104に対して電力を供給するバッテリ9102である。バッテリ9102は、ニッケルカドミウム、リチウムイオン、または他の電力供給メカニズムであり得る。電力供給104は、いずれかの負荷またはコンポーネントまたは他の電力提供または電力消費メカニズムであり得る。バッテリ9102の電流は、電流検知レジスタ9106における電圧低下を測定して、以下に詳細を述べるように、オペアンプ9108を使用して得られた信号を増幅することによって、測定され得る。オペアンプ9108は、バッテリ9102の測定した電流に関する信号をアナログからデジタルへのコンバータ(ADC)9110に出力し、ここで、アナログ信号は、処理回路9112によって使用されるデジタル形態に変換される。デジタル信号は、装置9100のメモリに格納され得るが、処理回路9112に送信またはそうでなければ利用可能にし得る。処理回路9112は、この情報を処理するロジックを含み、さらに、この情報をユーザに提示し得るか、または、他の電力管理コンポーネントおよび/またはソフトウェア9114を使用して情報を利用し得る。電力管理コンポーネントおよび/またはソフトウェア9114は、電力管理モジュールを含み、装置内のどこに電力を送るか、どの程度の電力が必要および/または利用可能であるか、どのように電力を分散するか等を決定し得るとともに、他の装置側機能9118も含み得る。
図92は、コンポーネント誤差を修正するためのシステムの1つの実施形態を示す。システム9200は、バッテリコンポーネント9202と電力供給コンポーネント9204とを備える。電流検知レジスタ9206は、バッテリ9202と電力供給コンポーネント9204との間に挿入され得る。オペアンプ9208は、電流を決定するために、レジスタ9206における電圧低下を測定するように構成され得る。アンプ9208は、レジスタ9206における電圧低下を表す信号を増幅する。例えば、オペアンプ9208は、およそ50の増幅率を提供し得る。この増幅率は、コンポーネント情報に基づいて想定され得るが、または、以下で説明する実際の測定や計算に基づいて決定され得る。増幅された信号は、アナログからデジタルへのコンバータ(ADC)9210に提供される。ADC9210は、処理回路9212に接続することができ、その処理回路はプロセッサ集積回路(IC)または他の処理メカニズムであり、コンピュータが読取可能なメモリを含むまたは付属し得る。ADC9110によって出力される信号は、誤差値を決定するために使用することができ、誤差値は、コンピュータが読取可能なメモリに格納され得るが、そうでなければ、処理回路9212および/またはソフトウェア9214にアクセス可能である。ソフトウェア9214は、処理回路9212に提供される信号を受信して利用するように実現され得る。
ソフトウェア9214は、誤差値を使用して、バッテリの電圧レベルのより正確な電流値を計算し、スタンドアロンプログラムであり得るが、または、装置上に提供される他のソフトウェアと統合され得る。誤差値は、ADC9110の出力信号に基づくか、またはユーザによって予め選択され得る。ソフトウェア9216は、システムの特定のコンポーネントの電源をいつ切断するかを決定するための、バッテリの電流および/または電圧レベルを監視する電力管理ソフトウェアであり得る。
F.3.例示的な誤差値決定および利用
図93は、誤差値を決定及び利用するためのプロセス9300の1つの例示的な実施形態を示す。図92のシステムは、このプロセスを説明する上での参照として使用され得る。
特定の例示的な方法の詳細を以下に説明する。しかしながら、状況に応じて、一定の動作は説明する順序で実施する必要がなく、変更され得ること、および/または全体が省略され得ることを理解するべきである。さらに、説明する動作は、1つ以上のコンピュータが読取可能なメディア上に格納される命令に基づいて、コンピュータ、プロセッサまたは他の演算装置によって実現され得る。コンピュータが読取可能なメディアは、装置上に格納された命令を実現する演算装置によってアクセス可能ないずれの利用可能なメディアでもあり得る。
9302で、第1の公知の電圧および/または電流信号がレジスタに送信される。例えば、バッテリ9202のような公知の電力源が、電流検知レジスタ9206に送信される。
9304で、電流検知レジスタ9206のような、レジスタにおける電圧低下を、測定器を使用して測定することができるが、測定器は、外部の測定器であり得る、または、装置に内蔵され得る。公知の電圧数値は、レジスタにおいて、例えば、0.59ミリボルト(mv)であり得る。この値は、オペアンプへの第2の入力値のベースとなる。
9306で、レジスタにおける信号が、オペアンプ9308のようなオペアンプに提供される。オペアンプの出力、Vdischargeが測定される。オペアンプ9208は、例えば、50の想定増幅率を有し得る。理論的には、Vdischarge(つまり、オペアンプ9208の出力)は、増幅率によって乗じたオペアンプの入力電圧になるだけで、この場合、0.59mv×50または29.5mvである。しかし、現実には、Vdischargeはかなり異なり得る。例えば、測定されたVdischargeは、72mvであり得る。この値の不一致によって、例えば、42.5のような誤差値が生まれる(72−29.5)。しかし、この誤差値は、想定した増幅値と同程度にしか正確ではない。想定した増幅値が誤っている場合、誤差値も誤りとなる。したがって、以下に説明するように、より正確な誤差値のためには、より正確な増幅決定が利用され得る。
9308で、第2の公知の電圧および/または電流信号がレジスタに提供されて、誤差値をより正確に決定する。
9310で、レジスタ全体の電圧を再び測定する。この値が、オペアンプに対する第2の入力値のベースとなる。
9312で、レジスタにおける信号が、オペアンプ9308のようなオペアンプに提供され、第2の出力値として測定される。
9314で、誤差値を決定する。1つの実施形態に従い、誤差は、想定増幅率を利用して、その増幅値に第1の入力値を乗じて、予想値を求め、予想値から測定値を引いて誤差値を決定する。別の実施形態にしたがって、第1と第2の入力値が比較されて、つまり、入力値の差(Δin)を以下のように決定する。
Δin=|第1の入力値−第2の入力値|
第1と第2の出力値が比較されて、つまり、出力値の差(Δout)を以下のように決定する。
Δout=|第1の出力値−第2の出力値|
ΔoutをΔinで除して、オペアンプの実際の増幅率を取得する。この実際の増幅率は、例えば、第1の公知の入力値を乗じることによって、予想値を決定する。予想値を、第1の測定出力から差し引いて、誤差値を決定する。
誤差を計算する1つの様式の例として、以下の例を検討する。第1の公知の入力値3.5をオペアンプに提供すると、出力は200となる。第2の公知の入力値0.78をオペアンプに提供すると、出力は56となる。入力値は、電圧または電流量であり得る。例えば、入力値、つまり、3.5と0.78は、測定電流量(Ibattery)を、50で除すことによって求められ得るが、ここで、50は電流検出抵抗が1/50オーム(Ω)、つまり、20mωであることに基づいて選択される。Δinは3.5−0.78=2.72、およびΔoutは200−56=144である。ΔoutをΔinで除すことによって、52.94が得られる。これは、オペアンプ回路の増幅率を表す直線の傾きである。増幅率を入力値で乗じて、出力値からその積を差し引くと、オフセット、または誤差値が得られ、例えば、56−0.78×52.94=14.7068となる。
オフセットを決定するまた別の代替法は、オペアンプ9208に接続されたADC9210のように、オペアンプに直列に接続されたADCの出力を利用する。オペアンプの出力は、ADCの測定出力に調整因子を加えることを除いては、Vdischargeと同様に扱うことができる。4の値は、この値が、最小有効ビット(LSB)の値の2分の1であるという事実から、調整因子として選択され得る。
誤差値が得られると、VBATTのような未知の電圧がレジスタに提供されると、今後のVdischarge値を補正するために、格納および/または利用される。例えば、誤差値は、より正確なVcompensated値を得るために、図94に示したVmeasuredに加える、または差し引かれることができる。この様式でVmeasuredを補正すると、正常な動作中にオペアンプ208のようなコンポーネントで発生するオフセット誤差を修正することになる。
9316で、未知の電圧がレジスタに加えられる。これは、バッテリ放電等のような装置の正常な動作中に発生する可能性があり、それによって、装置の多様なコンポーネントに電力を提供する。
9318で、オペアンプによって信号が増幅される。この増幅によって、ADC9210のようなADCにおける変換用に高品質の信号を作成する。しかしながら、上記のように、オペアンプは、信号に誤差を生み出す関連オフセット値を有する。
9320で、増幅された信号の値は、誤差値を使用して調整される。この調整は、電力管理ソフトウェアや他のコンピュータプログラムを使用して実施され得る。このように、誤差値は、時間の経過とともに発生する作業電圧値に影響を与えるオペアンプのオフセット補正を支援する。
オペアンプまたは他の電力コンポーネントのオフセットを計算するために誤差値やソフトウェアを使用することは、オフセット調整を有するオペアンプを回路設計に組み入れるよりも、より電流を節約するコンポーネント誤差修正技術である。オフセット調整を有するオペアンプは、典型的に、オフセット調整を有しないオペアンプ208よりも多くの電流を引き込む。さらに、誤差値は、指定のコンポーネントまたは指定の構成設定に対して修正することができる。したがって、誤差値を決定するには、装置の耐用期間に1回だけ実施する必要があるが、または、必要に応じて、何回か決定され得る。誤差値を決定するプロセスは、工場出荷時の態様であり得る。また、特定の起動状態等の下でも実施され得る。
F.4.例示的なバッテリ寿命決定システム
上記の誤差値に基づいて決定される補正された電流値は、バッテリの寿命をより正確に計測するために使用され得る。以下により具体的に説明するように、スパイクの影響を削減するために測定時間全体で電圧を概算することによって、バッテリ寿命をより正確に予想することが可能になり、したがって、システムのパフォーマンスを最適化する。
図94は、理論上の電圧曲線Vtheoryに比較した、特定のシステムの測定電圧Vmeasuredを示す。Vtheoryは、負荷が小さい、例えば、300maのバッテリの寿命の理想的曲線である。しかし、電流がバッテリから流れる場合、バッテリ電圧VBATTには直列抵抗が関連し、図面のVBATTによって表されるように曲線を低下させる。このように、VBATTの曲線は、典型的に、Vtheoryの曲線を下回る。さらに、観察された電圧(Vmeasured)は、装置が指定の時間内に電圧の低下または消失を発生させる様々な電力状態に入ることによって、不安定な可能性がある。補正された電圧Vcompensatedは、上記の誤差値に基づいて、Vmeasuredから調整され得る。
例えば、電源を入れたり切ったりしたコンポーネントによって発生する突然の電力スパイクは、電力を節約する特定のコンポーネントを無効にする必要性を示す1つ以上の監視メカニズムによって、装置に知らせ得る。簡単に言うと、システム100は、特定の装置がどのように電力を管理または分散するかを決定する、特定の水位線または閾値を有し得る。例えば、VcompensatedがVthreshold-softwareを下回ると、電力を節約するように特定のソフトウェアプログラムが停止され得る。VcompensatedがVthreshold-hardwareを下回ると、電力を節約するように特定のハードウェアコンポーネントが無効にされ得る。電力スパイクによって、一時的に、電圧値はこれらの閾値のうちの1つまたは両方を下回り得る。これらの閾値は、VBATT曲線がttsまたはtthに近づいている、したがって、低い値または完全に放電値に近づいていることを示すことが目的である。しかし、電力スパイクは、一時的に、それぞれ、ts1とts2のタイミングで、Vthreshold-softwareおよびVthreshold-hardwareを下回るように電力を低下し得る。したがって、電力管理モジュールに関連するソフトウェアおよび/またはハードウェアは、Vcompensated曲線を平滑化して、装置の電力モードに影響を与えるスパイクを回避する。これに加えて、または代替として、Vthreshold-hardwareおよび/またはVthreshold-hardwareの値は、電源を入れたり切ったりするコンポーネントによって発生するいずれのスパイクも、調整されたVthreshold-hardwareおよび/またはVthreshold-hardwareの値を決して超えないように、調整され得る。
図95は、電子装置に関連するソフトウェアによって認識されると、電圧−時間曲線を平滑化することによって、バッテリ寿命をより正確に決定するシステムを示す。このように、一時的な電圧のスパイクは、残っている電圧レベルや残っているバッテリ寿命の読取に影響を与えないように回避され得る。図92のコンポーネントに同様な図95のコンポーネントは、同様な参照番号を有する(例えば、バッテリ9202は9502に対応する)。
図95は、バッテリ電圧VBATTがADC9515に送信されて、アナログ信号をデジタル形態に変換することを除き、図92と同様である。VBATTを表すデジタル信号が、ソフトウェア9514に提供される。このソフトウェアは、誤差値ソフトウェア9514または他のソフトウェアプログラムに統合され得る、または独立的になり得る。また、このソフトウェアは、電力管理モジュール9516にも関連し、電力管理モジュール9516を実現し得る。電力管理モジュール9516は、図94に示したVcompensated曲線を平滑化し得、VBATTまたはVTHEORY曲線をより近く表す。曲線を平滑化する、または調整する1つの様式は、測定値を使用して、VBATT REALを計算することである。測定値は、次の式で利用することができる。
VBATT REAL=VBATT MEASURED+(Icompensated×Rseries resistance)
式中、VBATT MEASUREDは、VBATTの測定時に得られた実際の値である。Icompensatedは、上記の誤差値を使用して計算される。Rseriesは、回路基板の抵抗、配線の抵抗等に基づいた概算値である。この値は、ソフトウェア9514によって計算されて利用され得る。
F.5.バッテリ寿命を正確に決定するための例示的な技術
図96は、バッテリ寿命をより正確に決定するためのプロセス300の1つの実施形態の例である。図95のシステムは、このプロセスを説明する上での参照として使用され得る。
例示的な方法の詳細を以下に説明する。しかしながら、状況に応じて、一定の動作は説明する順序で実施する必要がなく、変更され得ること、および/または全体が省略され得ることを理解すべきである。さらに、説明する動作は、1つ以上のコンピュータが読取可能なメディア上に格納される命令に基づいて、コンピュータ、プロセッサまたは他の演算装置によって実現され得る。コンピュータが読取可能なメディアは、装置上に格納された命令を実現する演算装置によってアクセス可能ないずれの利用可能なメディアでもあり得る。
9602で、電子装置のバッテリ電圧を測定する。測定は、内蔵型または外部コンポーネントで実施され得る。
9604で、装置のコンポーネントに流れる電流が得られる。この電流値は、オペアンプ9508のオフセットを修正する誤差値調整を反映し得る。
9606で、直列抵抗値を決定する。これは、回路基板抵抗、配線、および電子回路に生じる他の抵抗の特徴に基づいた値であり得る。
9608で、バッテリ9502に残る残存電力(つまり寿命)をより正確に表すバッテリ電圧を取得する。これは、次の式を計算することにより実現され得る。
VBATT REAL=VBATT MEASURED+(Icompensated×Rseries)
VBATT MEASUREDは、VBATTの測定時に得られた実際の値である。Icompensatedは、上記の誤差値を使用して計算される。Rseriesは、回路基板の抵抗、配線の抵抗等に基づいた概算値である。この値は、ソフトウェア9514によって計算されて利用され得る。
F.6.例示的な電力段階切替システム
電力状態システムおよび装置を以下に説明するが、この実施形態は、非限定的な例として機能することを目的とする。
図97は、電子装置9700上に実現される電力状態の間を切り替えるためのシステムを示す。装置9700は、トリガイベントセンサ9702と電力状態モジュール9704とを有する。他のコンポーネント、特に、他の電力管理コンポーネントも含まれ得るが、簡便性を目的として、図説されていない。
トリガイベントセンサ9702は、ネットワークの可用性を検知するため、またはWANを経由して携帯型装置に送信されているデータを検知するためのWANスイッチであり得る。トリガイベントセンサ9702は、装置9700の電力状態を変更することが必要なイベントを検知するように動作可能である。1つの例によると、トリガイベントセンサ9702は、携帯型装置に送信するデータモジュールが利用可能な時を検知し、電力状態モジュール9704は、装置の電力状態を、第1の電力状態からデータモジュールを受信する第2の電力状態に変更する。トリガイベントは、データ接続またはネットワークの音声モードを介して、装置9700に送信され得る。
電力状態モジュール9704は、データ送信モードを用いてデータモジュールを送信、および、音声モードを使用してイベント信号を受信するように動作可能なプロセッサ、または他の集積回路または電子装置であり得る。プロセッサ9704は、トリガイベントセンサ9702から信号を受信し、装置9700の電力状態を変更し、ユーザの対話および/または通知があってもなくても、リモートのソースからデータを受信するように動作可能である。
1つの例によると、第1の電力状態はスタンドバイモード状態で、音声モード機能を有し得、第2の電力状態はデータ送信状態である。スタンドバイモード状態によって、装置9700は、携帯またはワイヤレスネットワークのような音声モードにわたって、「ピング」または「リング」のようなイベントトリガ信号を受信することが可能になり得る。イベントトリガ信号によって、装置はスタンドバイモードから「活動状態に復帰」する。イベント信号は、装置9700に対して、データコンテンツまたはデジタルアイテムがダウンロードまたはプッシュのために利用可能であることを示し得る。これに応答して、電力状態モジュール9704は、装置を第2の状態にし、ダウンロードまたはプッシュを発生可能にし得る。これは、広域ネットワーク(WAN)の有効モードであり得る。プロセッサは、ユーザに対して、データコンテンツまたは他のデジタルアイテムが受信されたことの通知を提供し得る。プロセッサは、次に、データコンテンツまたはデジタルアイテムを受信後、装置をスタンドバイモード状態に戻す。状態を切り替えるプロセスは、ソフトウェア、ハードウェア、またはこれらの組み合わせによって制御され得る。
多様なトリガイベントが装置9702の電力状態を変更し得る。例えば、転送するデータが利用可能であることを示すトリガイベントが受信され、さらに、装置702のバッテリレベルが閾値周辺または未満であることを示すトリガイベントが受信されると、プロセッサは、データ送信トリガイベントを無視し得る。これに加えて、または代替として、プロセッサは、データ送信トリガイベントの受信を記録し、トリガイベントを受信したことをユーザに通知し得るが、電力レベルが閾値周辺または未満であるために、データ送信が開始されなかったことは通知されない。
また、トリガイベントは、有線またはワイヤレスネットワークが利用可能であることを示す指標でもあり得る。このようなトリガイベントはプロセッサによって受信される可能性があり、プロセッサは、次いで、有線またはワイヤレスネットワークのセッションを有効にし得る。
F.7.電力段階切替の例示的なプロセス
図98は、装置9702のような電子装置上で電力状態を変更するためのプロセス9800の1つの例示的な実施形態を示す。
例示的な方法の詳細以下に説明する。しかしながら、状況に応じて、一定の動作は説明する順序で実施する必要がなく、変更され得ること、および/または全体が省略され得ることを理解されたい。さらに、説明する動作は、1つ以上のコンピュータが読取可能なメディア上に格納される命令に基づいて、コンピュータ、プロセッサまたは他の演算装置によって実現され得る。コンピュータが読取可能なメディアは、装置上に格納された命令を実現する演算装置によってアクセス可能ないずれかの利用可能なメディアであり得る。
9802で、電子装置によって信号が受信される。信号は、装置が接続されている有線またはワイヤレスネットワーク経由で送信され得る。信号は、上記に説明したように、トリガイベントを表し得る。
9804で、装置の電力状態は、トリガイベントに応答して、第1の電力状態から第2の電力状態に変更され得る。上記に説明したように、第1と第2の電力状態のうちの1つは、広域ネットワーク(WAN)が有効な状態で、電力状態のもう一方は、WAN以外が有効になった状態である。例えば、トリガイベントは、データモジュールが送信する準備ができており、装置がWANが有効になったモードになると、データ送信モードを使用して、装置によって受信され得ることを示し得る。トリガイベントに応答して、装置は第2のWANが有効になったモードに変わり、データ送信を可能にし得る。この結果、装置は、トリガイベントに応答して電力状態だけを変更することによって、電力を節約する。装置は、利用可能なデータモジュールを定期的に確認する必要はないく、代わりに、低電力の音声モードを使用して、データモジュールが準備されている兆候を監視する。
結論
結論にあたり、本発明は、構造的特徴および/または方法論的動作に特有の言語において説明してきたが、添付の請求項で定義される本発明は、必ずしも特有な特徴または説明された動作に限定されないことを理解されたい。そうではなく、特有の特徴および動作は、請求される本発明を実現する例示的形態として開示される。