JP2013186805A - 端末装置、その制御プログラム、および、その制御方法、ならびに、コンテンツ再生システム - Google Patents

Abstract

【課題】端末装置が、サーバと通信しない状態で生成したコンテンツの付随情報を、サーバにおいて管理させることができるようにする。
【解決手段】コンテンツ再生システムでは、付随情報ＤＢの更新のための処理が、電子書籍（コンテンツ）の再生（閲覧）のための処理とは独立して、実行される。端末１００においてオフラインで電子書籍が閲覧された場合でも、端末１００ではしおり情報等の付随情報が生成され、当該付随情報が端末１００の付随情報ＤＢに登録する。そして、端末１００は、オンラインで、電子書籍の閲覧中か否かに関わらず、複数のコンテンツについての付随情報のバックアップを、コンテンツサーバ３００に対して行うことができる。
【選択図】図１

Description

本発明は、端末装置、その制御プログラム、および、その制御方法、ならびに、コンテンツ再生システムに関し、特に、コンテンツの付随情報を扱う端末装置、その制御プログラム、および、その制御方法、ならびに、コンテンツ再生システムに関する。

従来から、ユーザごとに閲覧可能なコンテンツをサーバで管理し、当該コンテンツのリストを、ユーザが操作する端末装置においても表示できるような技術があった。

また、このような技術には、たとえば、特許文献１（特開２０００−１５５７６６号公報）に開示されるように、端末装置から送られる栞等のコンテンツに付随する情報（以下、「付随情報」という）を管理するものもあった。当該文献に記載のネットワーキングライブラリシステムでは、閲覧者が閲覧を望むコンテンツを選択すると、当該閲覧者の履歴をチェックし、付随情報を挿入する旨の情報が登録されていれば、コンテンツとともに、当該付随情報を表示するためのデータが、閲覧者の端末装置に送信される。また、当該システムでは、閲覧者の閲覧終了時には、付随情報がシステムに送信される。

特開２０００−１５５７６６号公報

上記した従来の技術によれば、コンテンツの閲覧に用いられる端末装置は、システム（サーバ）と通信可能なときにのみ、付随情報の提供を受け、また、付随情報をサーバに送信することができた。

したがって、当該端末装置がサーバと通信不能な状態（たとえば、通信環境が整っていない場所）または通信しない状態でコンテンツが閲覧され、当該端末装置において付随情報が生成された場合、当該付随情報をサーバで管理させることができなかった。

本発明は、かかる実情に鑑み考え出されたものであり、その目的は、端末装置が、サーバと通信しない状態で生成したコンテンツの付随情報を、サーバにおいて管理させることができるようにすることである。

本発明に従った端末装置は、コンテンツを再生するための再生手段と、再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するための生成手段と、付随情報を格納するための記憶手段と、生成手段によって生成された付随情報をサーバ装置へ送信するための送信手段とを備え、再生手段は、記憶手段に格納された付随情報に基づいてコンテンツを再生し、送信手段は、生成手段によって生成された付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信するための送信手段とを備える。

好ましくは、サーバ装置から、送信手段が送信した付随情報が、すでにサーバ装置に格納されている他の付随情報と競合する旨の通知を受信するための受信手段と、受信手段が受信した通知に基づいて、送信手段が送信した付随情報の変更を許可するか否かの情報を入力するための入力手段とを備え、受信手段は、入力手段に送信手段が送信した付随情報の変更を許可する情報が入力された場合には、修正後の付随情報を記憶手段に格納する。

好ましくは、サーバ装置から、送信手段が送信した付随情報が、すでにサーバ装置に格納されている他の付随情報と競合する旨の通知を受信するための受信手段と、受信手段が受信した通知に基づいて、送信手段が送信した付随情報のサーバ装置での登録の指示を入力するための入力手段とを備え、送信手段は、入力手段に付随情報のサーバ装置での登録の指示が入力された場合には、サーバ装置に、送信手段が送信した付随情報の登録を指示する情報を送信する。

本発明に従った端末装置の制御プログラムは、記憶手段とコンテンツを再生する再生手段とを備える端末装置のコンピュータによって実行される、当該端末装置の制御プログラムであって、制御プログラムは、端末装置に、再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するステップと、付随情報を記憶手段に格納するステップと、生成された付随情報をサーバ装置へ送信するステップとを実行させ、再生手段は、記憶手段に格納された付随情報に基づいてコンテンツを再生し、付随情報をサーバ装置へ送信するステップは、生成された付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信する。

本発明に従った端末装置の制御方法は、記憶手段とコンテンツを再生する再生手段とを備える端末装置のコンピュータによって実行される、当該端末装置の制御方法あって、再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するステップと、付随情報を記憶手段に格納するステップと、生成された付随情報をサーバ装置へ送信するステップとを備え、再生手段は、記憶手段に格納された付随情報に基づいてコンテンツを再生し、付随情報をサーバ装置へ送信するステップは、生成された付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信する。

本発明に従ったコンテンツ再生システムは、コンテンツを再生するための再生手段を備える端末装置と、端末装置と通信可能なサーバ装置とを備えた、コンテンツ再生システムであって、端末装置は、再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するための生成手段と、付随情報を格納するための第１の記憶手段と、生成手段によって生成された付随情報をサーバ装置へ送信するための送信手段とを含み、サーバ装置は、コンテンツの付随情報を格納するための第２の記憶手段と、再生手段は、第１の記憶手段に記憶された付随情報に基づいてコンテンツを再生し、送信手段は、生成手段によって生成された付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信するための送信手段とを備える。

好ましくは、サーバ装置は、送信手段によって送信された付随情報を管理するための管理手段をさらに含み、管理手段は、送信手段によって送信された付随情報と第２の記憶手段に格納された付随情報とが競合するか否かを判断し、競合すると判断した場合には、送信手段によって送信された付随情報を、競合を回避するように修正し、修正後の付随情報を第２の記憶手段に格納する。

好ましくは、管理手段は、送信手段によって送信された付随情報と第２の記憶手段に格納された付随情報とが競合すると判断した場合に、端末装置に修正後の付随情報を送信する。

好ましくは、管理手段は、送信手段によって送信された付随情報と第２の記憶手段に格納された付随情報とが競合すると判断した場合に、端末装置に修正後の付随情報の登録の可否を問い合わせ、登録を許可する回答を受信したことを条件として、第２の記憶手段に、修正後の付随情報を第２の記憶手段に格納する。

本発明によれば、コンテンツの付随情報は、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立して、サーバ装置へ送信される。

これにより、端末装置において、サーバ装置と通信できない状態で生成された付随情報をも、サーバ装置において管理することができる。

本発明の端末装置およびサーバ装置の一実施の形態を含むコンテンツ配信システムの全体構成を模式的に示す図である。 端末のハードウェア構成を模式的に示す図である。 コンテンツサーバのハードウェア構成を模式的に示す図である。 メタ情報ファイルの内容の一例を示す図である。 端末がローカルモードで動作しているときに表示部に表示される本棚画面の一例を示す図である。 端末がオンラインモードで動作しているときに表示部に表示される本棚画面の一例を示す図である。 端末において図５または図６を参照して説明したような本棚画面を表示させるために処理部が実行する処理のフローチャートである。 図７のステップＳ６０における処理のサブルーチンのフローチャートである。 端末の処理部が実行する当該処理のフローチャートである。 端末の外観の一例を示す図である。 付随情報を表示するための画面の一例を示す図である。 バックアップ処理のフローチャートである。 図１２の処理における端末からの要求に応じて、コンテンツサーバにおいて実行される処理のフローチャートである。 端末において表示される、問合せの画面の一例を示す図である。 付随情報のバックアップが終了したことを報知する画面の一例を示す図である。 登録されなかった付随情報を受信した端末において表示される画面の一例を示す図である。 図１２のバックアップ処理の変形例のフローチャートである。 図１３のコンテンツサーバの処理部の処理の変形例のフローチャートである。 図１７のステップＳＡ５４０のサブルーチンのフローチャートである。 変形例（１）の図１８の処理の変形例に相当する処理のフローチャートである。 変形例（１）の図１９の処理の変形例に相当する処理のフローチャートである。 端末における、ダイアログの表示画面の一例を示す図である。 端末において付随情報の取り出しのために実行される処理のフローチャートである。 端末から取り出しの要求を受けたコンテンツサーバ３００において実行される処理のフローチャートである。 付随情報の取り出しの対象となるコンテンツの一覧を表示する画面の一例を示す図である。 付随情報の取り出し処理が終了したときに、その旨を報知するために、処理部が表示部に表示する画面の一例を示す図である。 端末装置の具体例を説明するための図である。 端末装置の具体例を説明するための図である。 端末装置の具体例を説明するための図である。 端末装置の具体例を説明するための図である。

以下、本発明の端末装置の実施の形態について、図面を参照して説明する。なお、以下の説明において、同一の機能および作用を有する要素については、同じ各図を通して同じ符号を付し、重複する説明を繰返さない。

＜システムの全体構成＞
図１は、本発明の端末装置およびサーバ装置の一実施の形態を含むコンテンツ配信システムの全体構成を模式的に示す図である。なお、本明細書では、「端末装置」を、便宜上単に「端末」と呼ぶ場合もある。

図１に示されたシステムでは、端末１００Ａ〜１００Ｃのそれぞれが、ネットワーク１０００を介して、コンテンツサーバ３００と通信する。これにより、端末１００Ａ〜１００Ｃのそれぞれでは、コンテンツがダウンロードされ、格納され、再生される。なお、端末１００Ａ〜１００Ｃにおけるコンテンツの再生は、ダウンロードの後に行われるものに限らず、ストリーミングで行われる場合もあり得る。また、本明細書では、端末１００Ａ〜１００Ｃを、総称して「端末１００」と呼ぶ場合もある。

端末１００Ａ〜１００Ｃは、たとえば、同一のユーザによって所有される場合もある。当該ユーザは、自己が購入等することにより使用権を有するコンテンツについて、端末１００Ａ〜１００Ｃのうちの１以上の端末でコンテンツをダウンロードし、それぞれの端末において当該コンテンツを再生することができる。

本明細書において、「ユーザがコンテンツの使用権を有する」とは、当該ユーザが当該コンテツを購入した場合に限らず、特定のグループの会員になることによってコンテンツの再生をする資格を有している場合や、自己が制作したコンテンツを自己がアクセス可能な記憶装置に格納していることによって当該コンテンツを再生させることができる場合、万人に提供されるいわゆるフリーコンテンツについて当該フリーコンテンツの再生が可能である場合などを含む。

図１のシステムにおいて、端末１００Ａ〜１００Ｃは、同一のユーザによって所有され、また、当該ユーザは、コンテンツ９０１，９０２，９０３の使用権を有する。そして、図１のシステムにおいて、当該ユーザは、端末１００Ａでコンテンツ９０１をダウンロードし、端末１００Ｂでコンテンツ９０２をダウンロードし、そして、端末１００Ｃでコンテンツ９０３をダウンロードしている。

本実施の形態において、コンテンツとは、電子書籍や音声ファイル、動画ファイル、テキストファイルなど、種々の形式のファイルを意味する。本明細書では、コンテンツの再生の一例として、主に、電子書籍の閲覧について説明する。なお、本発明において再生の対象となるコンテンツの種類は、電子書籍に限定されず、音楽コンテンツや、動画像コンテンツ、静止画像コンテンツ等の種々の形態のファイルが対象となるものとする。

図１のシステムには、書籍データベース（ＤＢ）３１０が設けられている。
書籍ＤＢ３１０には、各コンテンツの本体のデータ、各ユーザが購入したコンテンツを特定する情報（ユーザ購入履歴ＤＢ）、および、各コンテンツの格納場所などの情報が格納されている。なお、書籍ＤＢ３１０は、ユーザ購入履歴ＤＢおよび書誌情報ＤＢに格納された情報に基づいて、各ユーザが使用権を有するコンテンツのリスト（コンテンツリスト）を生成し、端末１００Ａ〜１００Ｃに配信する。

端末１００Ａ〜１００Ｃのそれぞれは、書籍ＤＢ３１０から、各端末のユーザが使用権を有するコンテンツについてのコンテンツリストを取得する。

＜端末ブロック構成＞
図２は、端末１００のハードウェア構成を模式的に示す図である。

端末１００は、当該端末１００の動作を全体的に制御する処理部１０１と、液晶表示装置等の表示装置によって構成される表示部１０２と、タッチセンサ等の入力デバイスによって構成される操作部１０３と、ハードディスク等の記録媒体によって構成される記憶部１０４と、モデム等の通信装置によって構成される通信部１０５と、フラッシュメモリ１０６とを含む。

処理部１０１は、ＣＰＵ（Central Processing Unit）等のプロセッサを含む。
記憶部１０４は、コンテンツ本体のデータを格納するコンテンツ記憶部１０４Ａと、コンテンツの書誌的な情報を格納するためのコンテンツＤＢ１０４Ｂと、端末１００のユーザに関する情報を記憶するためのユーザ情報記憶部１０４Ｃと、コンテンツの付随情報を記憶するための付随情報記憶部１０４Ｄとを含む。

記憶部１０４は、端末１００の本体に固定されたものであってもよいし、端末１００の本体に対して着脱可能な記憶媒体であってもよい。このような記憶媒体の具体例としては、たとえば、ＣＤ−ＲＯＭ（Compact Disk - Read Only Memory）、ＤＶＤ−ＲＯＭ（Digital Versatile Disk - Read Only Memory）、ＵＳＢ（Universal Serial Bus）メモリ、メモリカード、ＦＤ（Flexible Disk）、ハードディスク、磁気テープ、カセットテープ、ＭＯ（Magnetic Optical Disk）、ＭＤ（Mini Disk）、ＩＣ（Integrated Circuit）カード（メモリカードを除く）、光カード、マスクＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ（Electronically Erasable Programmable Read Only Memory）などの、不揮発的にプログラムやデータを格納する媒体が挙げられる。

処理部１０１は、その機能として、コンテンツ記憶部１０４Ａ等に格納されたコンテンツを再生するためのコンテンツ再生部１０１Ａと、コンテンツリストに含まれるコンテンツの情報を表示部１０２等の表示装置に表示するためのリスト表示部１０１Ｂとを含む。

端末１００は、表示装置を備えていなくてもよい。この場合、リスト表示部１０１Ｂは、端末１００に接続された表示装置に、コンテンツの情報を表示させる。表示部１０２は、当該表示装置のドライバソフトウェアやドライバ回路によって実現される。また、この場合、コンテンツ再生部１０１Ａは、当該表示装置に、映像（または、画像）の再生画面を表示させる。

再生対象となるコンテンツが音声データを含む場合、コンテンツ再生部１０１Ａは、端末１００の内部、または、外部のスピーカに、当該音声データに基づく音声を出力させる。

処理部１０１は、さらに、その機能として、コンテンツ取得部１０１Ｃと、コンテンツリスト取得部１０１Ｄとを含む。

コンテンツ取得部１０１Ｃは、通信部１０５およびネットワーク１０００を介して、コンテンツ配信サーバ２００から、所望のコンテンツを取得する。取得されたコンテンツは、記憶部１０４のコンテンツ記憶部１０４Ａに格納される。コンテンツリスト取得部１０１Ｄは、通信部１０５およびネットワーク１０００を介して、コンテンツサーバ３００から、コンテンツリストを取得する。取得されたコンテンツリストは、コンテンツＤＢ１０４Ｂへ格納される。

処理部１０１は、さらに、その機能として、付随情報を生成する付随情報生成部１０１Ｅと、他の装置から通信部１０５を介して付随情報を取得する付随情報取得部１０１Ｆと、他の装置に通信部１０５を介して付随情報を送信する付随情報送信部１０１Ｇとを含む。

処理部１０１の各機能は、たとえばＣＰＵが所定のプログラムを実行することにより、実現される。当該プログラムの一例としては、電子書籍閲覧用のアプリケーション（以下、「電子書籍アプリ」という）のプログラムを挙げることができる。

フラッシュメモリ１０６は、電源を切っても記憶した内容の消えない不揮発性メモリであり、後述するようにコンテンツサーバ３００からダウンロードされたコンテンツリストをキャッシュデータとして一時的に記録するキャッシュメモリとして機能する（キャッシュデータ以外のデータを記録するデータメモリとしても機能する）。また、フラッシュメモリ１０６のうちのキャッシュデータの記録されていない領域には、キャッシュデータ以外のデータを記録することができる。

ここで、「キャッシュデータ」とは、フラッシュメモリ１０６上に格納されたデータのことである。また、「キャッシュメモリ」とは、上記したコンテンツリストを一時的に記録すると共に、記憶部１０４へのデータの読み出しがあった場合には、そのデータを記憶部１０４からではなくフラッシュメモリから読み出す機能を有するメモリのことである。上記フラッシュメモリ１０６としては、ＮＡＮＤ型のフラッシュメモリを用いてもよいし、ＮＯＲ型のフラッシュメモリを用いてもよい。

＜コンテンツサーバのハードウェア構成＞
図３は、コンテンツサーバ３００のハードウェア構成を模式的に示す図である。

図３を参照して、コンテンツサーバ３００は、当該コンテンツサーバ３００の動作を全体的に制御する処理部３０１と、記憶媒体によって構成される記憶部３０２と、モデム等の通信装置によって構成される通信部３０３とを含む。

記憶部３０２は、書籍ＤＢ３１０と付随情報記憶部３１１を含む。
書籍ＤＢ３１０は、少なくとも、ユーザごとのコンテンツの購入履歴を格納するユーザ購入履歴ＤＢと、コンテンツごとの書誌的情報を格納する書誌情報ＤＢと、コンテンツ本体のデータを格納するコンテンツ格納部とを含む。付随情報記憶部３１１には、後述する付随情報ＤＢが格納される。

処理部３０１は、ＣＰＵ等のプロセッサを含む。そして、処理部３０１は、その機能として、リスト生成部３０１Ａと、リスト配信部３０１Ｂと、付随情報管理部３０１Ｃと、コンテンツ配信部３０１Ｘとを含む。

リスト生成部３０１Ａは、ユーザ購入履歴ＤＢと書誌情報ＤＢに格納された情報に基づいて、ユーザ毎のコンテンツリストを生成する。リスト配信部３０１Ｂは、送信を要求されたコンテンツリストを、通信部３０３およびネットワーク１０００を介して、端末１００等に送信する。付随情報管理部３０１Ｃは、コンテンツに付随する情報（書籍中の特定の頁を指定するためのしおり情報、書籍中の所望の箇所に貼り付ける付箋情報、書籍中の所定の箇所をマーキングするマーカ情報、書籍に付されるコメント等のタグ情報、等）の生成、編集等を行う。コンテンツ配信部３０１Ｘは、端末１００からの要求に応じて、コンテンツ本体のデータを配信する。なお、書籍ＤＢ３１０に格納されていないコンテンツの配信要求があった場合には、コンテンツ配信部３０１Ｘは、要求されたコンテンツを格納するサーバに、端末１００に対するコンテンツの送信を指示する。

図３に示された例では、書籍ＤＢ３１０がコンテンツサーバ３００に含まれるように構成されているが、書籍ＤＢ３１０はコンテンツサーバ３００とは異なる装置で構成されてもよい。また、書籍ＤＢ３１０に含まれるユーザ購入履歴ＤＢと書誌情報ＤＢとコンテンツ格納部は、同じ装置に含まれてもよいし、互いに異なる装置に含まれてもよい。

＜端末内のコンテンツＤＢ＞
端末１００のコンテンツＤＢ１０４Ｃは、コンテンツ記憶部１０４Ａに格納されるコンテンツの情報を格納するコンテンツＤＢを含む。ここで、当該コンテンツＤＢの記憶内容について説明する。表１に、当該記憶内容を模式的に示す。

コンテンツＤＢには、コンテンツＩＤと、コンテンツファイル名と、コンテンツ保存先と、表紙画像ファイル名と、表紙画像保存先とが、互いに関連付けられて記憶されている。

コンテンツＩＤは、各コンテンツを特定する情報である。
コンテンツファイル名は、各コンテンツの本体のファイルのファイル名である。

コンテンツ保存先は、各コンテンツの本体のファイルの、コンテンツ記憶部１０４Ａにおける記憶場所を特定する情報である。

表紙画像ファイル名は、端末１００においてコンテンツの情報が、（後述する本棚画面等において）一覧表示される際に、各コンテンツの概要を示す画像として表示されるファイルのファイル名である。たとえば、当該コンテンツが電子書籍である場合には、表紙画像ファイル名の一例として、当該電子書籍に対応する実書籍の表紙のサムネイル画像のファイル名が挙げられる。また、当該コンテンツが音楽コンテンツである場合には、表紙画像ファイル名の一例として、当該コンテンツが収録されるアルバムのジャケット画像のサムネイル画像が挙げられる。

表紙画像保存先は、上記表紙画像の、コンテンツ記憶部１０４Ａにおける記憶場所を特定する情報である。

コンテンツサーバ３００から配信されるコンテンツリストには、少なくともコンテンツＩＤとコンテンツファイル名と表紙画像ファイル名とが関連付けられている。そして、当該コンテンツおよびその表紙画像がダウンロードされてコンテンツ記憶部１０４Ａに格納されると、上記コンテンツＩＤ等の情報に、コンテンツ保存先と表紙画像保存先とが追加されて、コンテンツＤＢに格納される。

＜ユーザ購入履歴ＤＢ＞
次に、コンテンツサーバ３００における、ユーザ購入履歴ＤＢの記憶内容について説明する。表２に、当該記憶内容を模式的に示す。

ユーザ購入履歴ＤＢでは、ユーザＩＤと、購入済コンテンツＩＤとが、互いに関連付けられて格納されている。

ユーザＩＤは、図１のシステムを利用する各ユーザを特定する情報である。
購入済コンテンツＩＤとは、コンテンツ購入サイト等において各ユーザが購入したコンテンツのコンテンツＩＤである。なお、購入済コンテンツＩＤとして、ユーザが使用権を有するコンテンツのコンテンツＩＤが格納される場合もあり得る。

表２によれば、ユーザＩＤ「ＳＣ０００１」のユーザは、コンテンツＩＤ「ＡＢＣＤ１２３４」とコンテンツＩＤ「ＡＢＣＤ１２３５」の、少なくとも２つのコンテンツを購入したことが記録されている。

＜書誌情報ＤＢ＞
次に、コンテンツサーバ３００における、書誌情報ＤＢの記憶内容について説明する。表３には、当該記憶内容が模式的に示されている。

書誌情報ＤＢには、コンテンツＩＤと、タイトルと、著者と、出版社名と、発売日と、価格と、商品概要と、ファイル名と、ダウンロードＵＲＬ（１）と、表紙画像ファイル名と、ダウンロードＵＲＬ（２）とが、互いに関連付けられて記憶されている。

コンテンツＩＤは、各コンテンツを特定するための情報である。
タイトルおよび著者は、各コンテンツのタイトルおよび著者である。

出版社名は、対象となるコンテンツが電子書籍である場合には、当該電子書籍を出版した企業を特定する情報であり、対象となるコンテンツが音楽コンテンツである場合には、レーベル等である。

発売日および価格は、対象となるコンテンツの発売日および販売された価格である。
商品概要とは、対象となるコンテンツの内容等の概要を表わす情報である。

ファイル名とは、対象となるコンテンツの本体のファイル名である。
ダウンロードＵＲＬ（１）とは、対象となるコンテンツの本体のファイルをダウンロードするためにアクセスするＵＲＬ（Uniform Resource Locator）である。

表紙画像ファイル名とは、上記した表紙画像のファイル名である。
ダウンロードＵＲＬ（２）とは、対象となるコンテンツの表紙画像のファイルをダウンロードするためにアクセスするＵＲＬである。

＜コンテンツリスト＞
上記したように、本実施の形態のシステムでは、コンテンツサーバ３００は、端末１００に、当該端末１００のユーザについてのコンテンツリストを送信する。

リスト生成部３０１Ａは、端末１００からコンテンツリストの対象となるユーザＩＤを取得する。これに応じて、リスト生成部３０１Ａは、書籍ＤＢ３１０のユーザ購入履歴ＤＢにおいて、取得したユーザＩＤに関連付けられている購入済コンテンツＩＤを抽出する。そして、リスト生成部３０１Ａは、書籍ＤＢ３１０の書誌情報ＤＢにおいて、購入済コンテンツＩＤとして抽出したコンテンツＩＤに関連付けられている情報を抽出して、コンテンツリストを生成する。

たとえば、コンテンツリストの対象としてユーザＩＤ「ＳＣ０００１」を取得すると、リスト生成部３０１Ａは、書籍ＤＢ３１０のユーザ購入履歴ＤＢにおいて、当該ユーザＩＤに関連付けられているコンテンツＩＤ「ＡＢＣＤ１２３４」とコンテンツＩＤ「ＡＢＣＤ１２３５」を取得する。そして、書籍ＤＢ３１０の書誌情報ＤＢから、これらのコンテンツＩＤに対応する情報（表３に示されたこれらのコンテンツＩＤに関連付けられた情報）を抽出し、当該抽出した情報を、コンテンツリストとする。

つまり、コンテンツリストは、表２のユーザ購入履歴ＤＢにおいて対象となるユーザのユーザＩＤに関連付けられたコンテンツについての、表３の書誌情報ＤＢにおける各項目のデータを含む。

＜メタ情報ファイル＞
リスト生成部３０１Ａは、コンテンツリストの生成とともに、当該コンテンツリストのメタ情報ファイルを生成する。メタ情報ファイルの内容の一例を、図４に示す。

図４を参照して、メタ情報ファイルは、たとえば、ＨＴＭＬ（HyperText Markup Language）５に準拠したマニフェストファイルによって構成される。

図４に示されたメタ情報ファイルは、「# Version cid=」以下に示されるコンテンツリストのバージョンを示す情報や、「# Valid until on」以下に示されるコンテンツリストの有効期限を示す情報を含む。

なお、リスト生成部３０１Ａは、コンテンツリストと別ファイルとして図４に示したような情報を生成することもできるし、コンテンツリストにそのような情報を含めることもできる。

＜コンテンツの再生＞
次に、端末１００におけるコンテンツの再生について説明する。本実施の形態の端末１００は、ユーザに電子書籍を閲覧させるために、電子書籍（コンテンツ）を再生する。

本実施の形態の端末１００では、電子書籍の閲覧に関し、「ローカルモード」と「オンラインモード」の２つのモードで動作が可能であるとする。端末１００は、入力装置１５に対する操作や端末１００本体の姿勢の変化等に基づいてこれらの間で動作モードが切り替わるように構成されている場合もあれば、いずれかのモードで動作可能である場合もある。

「ローカルモード」とは、端末１００のコンテンツＤＢに格納されたコンテンツを閲覧するモードである。「オンラインモード」とは、端末１００のユーザが使用権を有するコンテンツであって、当該端末１００のコンテンツＤＢに格納されていないコンテンツを閲覧するためのモードである。

なお、「オンラインモード」について、端末１００のコンテンツＤＢに格納されていないコンテンツとは、当該ユーザが所有する他の端末１００のコンテンツＤＢに格納されていても、現にユーザが操作する端末１００のコンテンツＤＢには格納されていないコンテンツも含む。より具体的には、端末１００Ａを操作している場合に、端末１００ＢのコンテンツＤＢに格納されているコンテンツであっても、端末１００ＡのコンテンツＤＢに格納されていないコンテンツであれば、端末１００Ａにおけるオンラインモードの操作においては、コンテンツＤＢ１４０に格納されていないコンテンツということになる。

端末１００は、オンラインでは、ローカルモードとオンラインモードのいずれのモードでも動作可能である。一方、オフラインでは、ローカルモードでのみ、動作が可能である。なお、本明細書において、オンラインとは、ネットワークに接続されている状態を、オフラインとは、ネットワークに接続されていない状態を指す。

＜本棚画面（端末保存済みのコンテンツを表示するための画面）＞
図５は、端末１００がローカルモードで動作しているときに表示部１０２に表示される本棚画面の一例を示す図である。

本棚画面５００は、閲覧可能なコンテンツのリストを表示する画面である。
本棚画面５００には、表示形式を指定するための表示欄５０１と、モードを指定するための表示欄５０２と、電子書籍のタイトル等の情報をリスト表示するための表示欄５１１〜５１７とを含む。表示欄５１１〜５１７に情報を表示された各コンテンツは、コンテンツ記憶部１０４Ａにその本体のデータを格納されたコンテンツである。また、表示欄５０１では、「タイトル」が選択されている。これにより、表示欄５１１〜５１７には、コンテンツ記憶部１０４Ａに本体を格納されたコンテンツが、タイトルの５０音順に、配列されて表示されている。

また、本棚画面５００には、ソフトウェアボタン５２１〜５２５が表示されている。ソフトウェアボタン５２１は、各書籍の詳細な情報を表示させるためのボタンである。ソフトウェアボタン５２２は、各コンテンツのシリーズを構成するコンテンツを検索するために操作されるボタンである。ソフトウェアボタン５２３は、各コンテンツをお気に入り登録するためのボタンである。ソフトウェアボタン５２４は、各コンテンツを指定したユーザが操作するときのみ表示させるための登録（シークレット登録）をするためのボタンである。ソフトウェアボタン５２５は、各コンテンツについて、ネットワーク上の特定のサイトに感想等の共有情報を投稿するために操作されるボタンである。

本棚画面５００の表示欄５０２には、ローカルモードであることを表す「端末に保存」が示されている。表示欄５０２の表示内容を視認することにより、ユーザは、本棚画面５００がローカルモードの本棚画面であることを認識することができる。

＜本棚画面（サーバ保管のコンテンツを表示するための画面）＞
図６は、端末１００がオンラインモードで動作しているときに表示部１０２に表示される本棚画面の一例を示す図である。

図６を参照して、本棚画面６００は、図５の表示欄５０１，５０２のそれぞれに対応する表示欄６０１，６０２を含む。また、本棚画面６００は、図５のソフトウェアボタン５２１〜５２５のそれぞれと同じ機能を有するソフトウェアボタン６２１〜６２５を含む。

そして、本棚画面６００には、表示欄６１１〜６１７が含まれる。表示欄６１１〜６１７は、コンテンツサーバ３００から受信したコンテンツリストに含まれるコンテンツであって、当該端末１００のコンテンツ記憶部１０４Ａに格納されていないコンテンツを示す。

本棚画面６００の表示欄６０２には、オンラインモードであることを表す「サーバに保存」が示されている。表示欄６０２の表示内容を視認することにより、ユーザは、本棚画面６００がオンラインモードの本棚画面であることを認識することができる。

なお、本棚画面６００には、更新ボタン６５０が表示されている。更新ボタン６５０は、後述するようにコンテンツサーバ３００に、当該端末１００内の付随情報を送信するために操作されるボタンである。

＜本棚画面表示処理＞
図７は、端末１００において図５または図６を参照して説明したような本棚画面を表示させるために処理部１０１が実行する処理のフローチャートである。

図７を参照して、端末１００において電子書籍アプリが起動されると、処理部１０１は、ステップＳ１０で、当該電子書籍アプリのホーム画面を表示部１０２に表示させて、ステップＳ２０へ処理を進める。

ステップＳ２０では、処理部１０１は、入力装置１５に対して本棚画面の表示を要求する操作がなされたか否かを判断し、そのような操作がなされたと判断するとステップＳ３０へ処理を進める。

ステップＳ３０では、処理部１０１は、電子書籍アプリにおける動作モードの選択を受付ける。そして、処理部１０１は、オンラインモードが選択された場合にはステップＳ６０へ処理を進め、ローカルモードが選択された場合にはステップＳ４０へ処理を進める。

ステップＳ４０では、処理部１０１は、当該端末１００内のコンテンツＤＢから、コンテンツＤＢ１０４Ｂに格納されているコンテンツのデータ（表１に示された端末内コンテンツＤＢ）を読出して、ステップＳ５０へ処理を進める。

ステップＳ５０では、処理部１０１は、図５を参照して説明したような本棚画面を表示させるためのデータを生成して、ステップＳ９０へ処理を進める。

なお、図５の本棚画面５００の表示欄５０１内の情報は、デフォルトで設定された情報である。当該情報は、電子書籍アプリの起動中のユーザ操作等によって、変更することができる。

表示欄５１１〜５１７に表示する情報としては、表１に示されたような端末内コンテンツＤＢに格納される情報が利用される。具体的には、表示欄５１１〜５１７のそれぞれには、端末内コンテンツＤＢの各コンテンツについて登録された情報（タイトル、著者、出版社、等）が抽出されて、表示される。

図７に戻って、ステップＳ６０では、処理部１０１は、コンテンツサーバ３００から配信されるコンテンツリストを読出して、ステップＳ７０へ処理を進める。なお、ステップＳ６０におけるコンテンツリストの読出については、図８を参照して後述する。

ステップＳ７０では、処理部１０１は、コンテンツサーバ３００から受信したコンテンツリストと端末１００内のコンテンツＤＢに格納されたコンテンツＤＢのデータとの差分を算出して、ステップＳ８０へ処理を進める。ステップＳ７０の処理により、コンテンツサーバ３００から送信されたコンテンツリストに登録されているコンテンツであって、当該端末１００のコンテンツ記憶部１０４Ａに格納されていないコンテンツが抽出される。

ステップＳ８０では、処理部１０１は、ステップＳ７０で抽出したコンテンツについて、図６を参照して説明したような本棚画面を表示するためのデータを生成して、ステップＳ９０へ処理を進める。

ステップＳ９０では、処理部１０１は、ステップＳ５０またはステップＳ８０で表示用のデータを生成した本棚画面を表示部１０２に表示させて、処理を終了する。

以上、図７を参照して説明した処理によれば、選択された動作モード（ローカルモードまたはオンラインモード）に対応した本棚画面が、表示部１０２に表示される。

＜コンテンツサーバから送信されるコンテンツリストの読出＞
図８は、図７のステップＳ６０における処理のサブルーチンのフローチャートである。

なお、当該処理は、コンテンツサーバ３００における処理と協働して実現される。したがって、図８では、端末１００側の処理のフローチャートに加えて、コンテンツサーバ３００における処理のフローチャートも示されている。

図８を参照して、処理部１０１は、ステップＳＡ１０で、その時点で当該端末１００がコンテンツサーバ３００と接続が可能か否かを判断し、接続が可能であると判断するとステップＳＡ２０へ処理を進め、当該サーバに接続できないと判断すると、処理部１０１は、ステップＳ４０（図７参照）へ処理を戻す。これにより、端末１００の動作モードがローカルモードへ切り換えられる。

ステップＳＡ２０では、処理部１０１は、コンテンツサーバ３００に、コンテンツリストのメタ情報ファイルの送信取得を要求する。このとき、処理部１０１は、コンテンツサーバ３００に対して、ユーザを特定する情報（たとえば、ユーザＩＤ）を送信する。ユーザＩＤは、たとえば、記憶装置１６に格納されている。なお、処理部１０１は、端末１００の利用に際して、ユーザにログイン情報の入力を求めてもよい。このような場合には、ステップＳＡ２０では、処理部１０１は、当該ログイン情報として入力されたユーザＩＤを、コンテンツサーバ３００へ送信する。

端末１００からメタ情報ファイルの取得の要求を受けると、コンテンツサーバ３００の処理部３０１は、ステップＳＢ１０で、書籍ＤＢ３１０のユーザ購入履歴ＤＢにおいて、端末１００から送信されたユーザＩＤに関連付けられたコンテンツＩＤを取得する（購入履歴問合せ）。

なお、書籍ＤＢ３１０のユーザ購入履歴ＤＢが、コンテンツサーバ３００とは別の装置によって構成される場合には、処理部３０１は、当該装置に対して、問合せを、端末１００から受信したユーザＩＤの送信とともに行なう。これに応じて、当該装置は、ステップＳＣ１０で、受信したユーザＩＤに関連付けられたコンテンツＩＤを送信する（購入履歴送信）。

また、処理部３０１は、ステップＳＢ１０で取得したコンテンツＩＤに対応する書誌情報を、書籍ＤＢ３１０の書誌情報ＤＢから取得する。なお、書籍ＤＢ３１０の書誌情報ＤＢがコンテンツサーバ３００とは別の装置で構成されている場合には、処理部３０１は、当該装置に対して、ステップＳＢ１０で取得したコンテンツＩＤを送信とともに、書誌情報の問合せを行なう。当該装置は、これに応じて、コンテンツサーバ３００から受信したコンテンツＩＤに対応する書誌情報を送信する。

処理部１０１は、ステップＳＢ２０の処理によって取得した書誌情報に基づいて、ステップＳＢ１０で取得したユーザＩＤに対応するコンテンツリストを生成し、そして、当該生成したコンテンツリストについてのメタ情報ファイルを生成して、ステップＳＢ４０へ処理を進める。

ステップＳＢ４０では、処理部３０１は、端末１００に対して、ステップＳＢ３０で生成したメタ情報ファイルを送信する。

端末１０の処理部１０１は、これに応じて、ステップＳＡ３０で、コンテンツサーバ３００から受信したメタ情報ファイルが、既にキャッシュメモリに格納されているコンテンツリストのメタ情報ファイルと一致するか否かを判断し、一致すると判断するとステップＳＡ６０へ処理を進め、一致しないと判断するとステップＳＡ４０へ処理を進める。

ステップＳＡ４０では、処理部１０１は、コンテンツサーバ３００に対してコンテンツリストの取得を要求する。

ステップＳＡ４０におけるコンテンツリスト取得要求に応じて、コンテンツサーバ３００の処理部３０１は、端末１００に対してステップＳＢ３０で生成したコンテンツリストを送信する。

コンテンツサーバ３００からのコンテンツリストの送信に応じて、端末１００の処理部１０１は、ステップＳＡ５０で、受信したコンテンツリストを読出して、処理を図７へリターンさせる。

以上、図８を参照して説明した処理によれば、オンラインモードで本棚画面が表示される際には、まず端末１００がコンテンツサーバ３００に接続可能か否かが判断され（ステップＳＡ１０）、接続できない場合にはローカルモードへと、動作モードが切り換えられる。

一方、コンテンツサーバ３００に接続可能な場合、端末１００からコンテンツサーバ３００に対して、コンテンツリストのメタ情報ファイルの取得要求がなされる（ステップＳＡ２０）。

これに応じて、コンテンツサーバ３００では、改めてコンテンツリストが生成され（ステップＳＢ３０）、そして、当該コンテンツリストのメタ情報ファイルが端末１００へ送信される（ステップＳＢ４０）。

当該メタ情報ファイルを受信した端末１００では、キャッシュメモリに既に格納されているコンテンツリストのメタ情報ファイルと、受信したメタ情報ファイルが一致するか否かが判断される（ステップＳＡ３０）。そして、一致する場合には、改めてコンテンツサーバ３００からコンテンツリストを受信することなく、既にキャッシュメモリに格納されているコンテンツリストを読出す（ステップＳＡ６０）。一方、メタ情報ファイルが一致しなかった場合には、端末１００はコンテンツサーバにコンテンツリストの取得を要求する（ステップＳＡ４０）。

そして、端末１００では、コンテンツサーバ３００から受信したコンテンツリストが読出される（ステップＳＡ５０）。

なお、コンテンツサーバ３００では、ステップＳＢ１０〜ステップＳＢ３０で示したように、端末１００からメタ情報ファイルの取得要求がなされるたびにコンテンツリストおよびそのメタ情報ファイルが生成されたが、これらの生成は、このタイミングは図８を参照して説明されたものに限定されない。たとえば、書籍ＤＢ３１０のユーザ購入履歴ＤＢにおいて対象となるユーザＩＤについての履歴情報が更新されたとき、前回コンテンツリスト等が生成されてから一定の時間が経過したとき、等であってもよい。このように、端末１００からのメタ情報ファイルの取得要求の受信とは異なるタイミングでコンテンツリストおよびそのメタ情報ファイルが生成される場合には、コンテンツサーバ３００の処理部３０１は、ステップＳＡ２０による要求を受信すると、既に生成され記憶部３０２等に格納された、対象となるユーザＩＤに対応するメタ情報ファイルを、ステップＳＢ４０で、端末１００へ送信する。そして、ステップＳＡ４０のコンテンツリスト取得要求を受けると、処理部３０１は、ステップＳＢ５０の処理として、既に記憶部３０２等に格納されているコンテンツリストを、端末１００へ送信する。

＜コンテンツ表示処理＞
端末１００の電子書籍アプリでは、図５または図６を参照して説明したように、本棚画面が表示される。本棚画面５００，６００のそれぞれには、各コンテンツを選択するための表示欄５１１〜５１７，６１１〜６１７が表示される。

そして、本棚画面５００，６００のそれぞれにおいて、表示欄５１１〜５１７，６１１〜６１７のいずれかが選択されると、当該表示欄に対応するコンテンツを表示するための処理が実行される。

図９は、処理部１０１が実行する当該処理のフローチャートである。
図９を参照して、本棚画面５００，６００のいずれかにおいて、表示欄５１１〜５１７，６１１〜６１７のいずれかを選択する操作がなされると、処理部１０１は、ステップＳＡ１１０において、選択されたコンテンツが端末１００のコンテンツ記憶部１０４Ａ内に格納されているか否かが判断され、格納されている判断するとステップＳＡ１５０へ処理を進め、格納されていない、つまり、コンテンツサーバ３００に格納されていると判断するとステップＳＡ１２０へ処理を進める。

ステップＳＡ１５０では、処理部１０１は、コンテンツ記憶部１０４Ａに格納されたコンテンツであって、選択されたコンテンツを、ビューアで表示部１０２に表示させて、処理を終了する。

一方、ステップＳＡ１２０では、処理部１０１は、コンテンツサーバ３００に対して、選択されたコンテンツの本体のファイルのダウンロード要求を送信する。

これに応じて、コンテンツサーバ３００の処理部２０１は、要求されたコンテンツを端末１００へ配信する（ステップＳＥ１１０）。

これに応じて、端末１００の処理部１０１は、ステップＳＡ１３０で、コンテンツを受信し、コンテンツ記憶部１０４Ａに格納するとともに、格納後の情報に応じてコンテンツＤＢの情報を更新して、ステップＳＡ１４０へ処理を進める。これにより、新たにコンテンツ記憶部１０４Ａに格納されたコンテンツの情報が、端末内コンテンツＤＢ（表１参照）に追加される。

ステップＳＡ１４０では、処理部１０１は、ステップＳＡ１３０で受信したコンテンツを、ビューアで表示部１０２に表示させて、処理を終了する。

図１０は、端末１００の外観の一例を示す図である。図１０の端末１００は、電子書籍アプリの終了等の操作をするための操作ボタン１０３Ｐ〜１０３Ｑを含む。操作ボタン１０３Ｐ〜１０３Ｑは、操作部１０３に含まれる。図１０の端末１００の表示部１０２では、コンテンツの表示画面の一例（画面１１００）が示されている。

画面１１００は、電子書籍の表示画面である。画面１１００には、表示中のページにしおり情報が関連付けられていることを示すしおりアイコン７０１が表示されている。また、画面１１００に表示されたテキストの一部には、マーカ７０２が付されている。つまり、表示中のコンテンツの付随情報は、少なくとも、表示されているページに関連付けられたしおり情報と、マーカ７０２が付されている部分に関連付けられたマーカ情報を含む。

＜付随情報＞
端末１００では、図１０を参照して説明されたように、電子書籍本体とともに、上記のしおりやマーカ等の付随情報が処理されて、電子書籍が表示される。

付随情報は、あらかじめ設定されることもできるし、電子書籍の閲覧中のユーザの操作に基づいて生成される場合もある。付随情報の一例を、表４に示す。

表４に示された付随情報では、情報ＩＤとコンテンツＩＤに関連付けられている。情報ＩＤとは、生成される付随情報ごとに付されるＩＤである。コンテンツＩＤは、当該付随情報が関連付けられるコンテンツを特定する情報である。

付随情報では、種類と、第１項目と、第２項目と、特性とが関連付けられている。種類は、「しおり」「マーカ」「付箋」「タグ」等の、付随情報の種類を示す。第１項目および第２項目は、上記種類ごとに設定される値を特定する情報である。特性は、上記種類ごとに特性を特定する情報である。なお、付随情報の種類によっては、第２項目および／または特性の値は付随しない場合があり得る。

「しおり」については、第１項目は電子書籍のページを特定する情報であり、第２項目および特性は関連付けられない。「付箋」については、第１項目は、電子書籍内のページ等のテキストの位置を特定する情報であり、第２項目は関連付けられず、特性は付箋の色を特定する情報である。「マーカ」については、第１項目は電子書籍中のマーキングの開始位置を特定する情報であり、第２項目はマーキングの終了位置を特定する情報であり、特性はマーキングの色を特定する情報である。「タグ」については、第１項目はタグとして付されるコメントを特定する情報（たとえば、後述する表５中の「あとでよむ」）であり、第２項目は関連付けられず、特性は当該タグに対応する情報が表示される際の色を特定する情報である。

電子書籍アプリにおいて特定の操作（たとえば、操作ボタン１０３Ｐ〜１０３Ｑに対する操作）がなされると、表示部１０２に、付随情報を生成するための画面が表示される。図１１は、付随情報を表示するための画面の一例を示す図である。

図１１の画面１１０１には、図１０に示されているような閲覧の画面にオーバーラップして、ソフトウェアボタン（ボタン１０３１〜１０３５）が表示されている。

ボタン１０３１は、マーカ情報を生成するために操作されるボタンである。ボタン１０３２は、端末１００において搭載された辞書において閲覧中の電子書籍中の単語を検索するために操作されるボタンである。ボタン１０３３は、しおり情報を生成するために操作されるボタンである。ボタン１０３４は、付箋情報を生成するために操作されるボタンである。ボタン１０３５は、タグ情報を生成するために操作されるボタンである。

端末１００では、たとえば、或るコンテンツについての一回の閲覧（電子書籍アプリにおいて、当該電子書籍の閲覧が開始されてから終了するまで）において生成された付随情報が、表３に示されたように１つの情報ＩＤを付される。当該電子書籍の閲覧中は、ボタン１０３１〜１０３５に対する操作等によって生成された１つ１つの付随情報（表３の「しおり」や「マーカ」）が蓄積される。そして、当該電子書籍の閲覧が終了すると、閲覧中に生成された付随情報は、付随情報記憶部１０４Ｄの付随情報ＤＢに登録される。

付随情報ＤＢの内容の一例を、表５に示す。

表５の付随情報ＤＢでは、種類と、情報ＩＤと、コンテンツＩＤと、第１項目と、第２項目と、特性とが、関連付けられている。

表４に示されたように生成された付随情報は、当該付随情報に関連付けられている情報ＩＤとコンテンツＩＤとともに、付随情報ＤＢに追加される。つまり、電子書籍の閲覧が終了するごとに、付随情報ＤＢは、当該閲覧中に生成された付随情報を追加されるように、更新される。

表４に示されたような付随情報の生成、および、生成された付随情報の付随情報ＤＢへの格納は、付随情報生成部１０１Ｅが行う。付随情報生成部１０１Ｅは、各付随情報に一意に、情報ＩＤを生成して関連付ける。情報ＩＤは、付随情報ごとに一意であれば、当該電子書籍の閲覧が開始された年月日および時刻を組み合わせた値や、端末１００において生成された付随情報の通し番号や通しとなる文字列など、どのような形態であってもよい。本実施の形態では、情報ＩＤとして、「aaa」「sss」「ttt」「uuu」のような文字列が例示される。

表５の付随情報ＤＢでは、種類「しおり」「付箋」「マーカ」「タグ」ごとに、情報が示されている。

付随情報生成部１０１Ｅは、生成された付随情報を付随情報ＤＢに登録する際、生成された付随情報が、既に付随情報ＤＢに登録されている付随情報と競合する情報を含むか否かを判断することが好ましい。「競合する」とは、たとえば、生成された付随情報をそのまま付随情報ＤＢに登録すると、同じ電子書籍に対して複数の（または、予め定められた数以上の）しおり情報が設定されることになる場合、同じ部分に異なる（または、予め定められた数以上の）色のマーカが付されることになる場合、などが挙げられる。

そして、付随情報生成部１０１Ｅは、競合する情報を含むと判断した場合、たとえば、当該競合する部分を、新たに登録しようとする付随情報で上書きする。

なお、競合する情報を含むと判断した場合、付随情報生成部１０１Ｅは、既に登録されている付随情報と、これから登録しようとする付随情報の、競合する部分を示し、上書きをしてもよいかどうかをユーザに問い合わせる画面を表示してもよい。そして、当該画面に対してユーザが入力した情報に従って、付随情報ＤＢを更新する。つまり、上書きを許可する情報が入力されれば、付随情報ＤＢの競合部分を、新たに生成された付随情報で上書きする。上書きを禁止する情報が入力されれば、競合部分は上書きすることなく、付随情報ＤＢを更新する。新たに生成された付随情報における競合部分は削除して、付随情報ＤＢを更新する。また、双方を登録する情報が入力された場合には、既に登録されている情報と新たに生成された情報の競合する部分の双方を、区別可能に、付随情報ＤＢに登録する。なお、このような登録の態様は、周知の技術を適用することができると考えられるうため、本明細書ではこの内容は繰り返さない。

＜コンテンツサーバにおける付随情報の管理＞
図１に示されたシステムでは、コンテンツサーバ３００の付随情報記憶部３１１には、各端末１００（端末１００Ａ〜１００Ｃ）において生成された付随情報が登録される。以下、コンテンツサーバ３００における、端末で生成された付随情報の管理について、説明する。なお、説明の容易のため、以下の説明では付随情報のうち種類「マーカ」のみが対象とされて説明がなされるが、本実施の形態のシステムでは他の種類の情報についても、同様に管理がなされる。

表６に、端末１００Ａにおいて登録されている付随情報ＤＢの一例を示す。表７に、端末１００Ｂにおいて登録されている付随情報ＤＢの一例を示す。そして、表８に、コンテンツサーバ３００において登録されている付随情報ＤＢの内容の一例を示す。

表６では、４つの情報ＩＤ（「aaa」「sss」「ttt」「uuu」）に対応した付随情報ＤＢが示されている。表７では、１つの情報ＩＤ（「bbb」）に対応した付随情報ＤＢが示されている。

端末１００Ａから表６に示されたような付随情報ＤＢの情報が送信されると、コンテンツサーバ３００では、当該情報が、送信元の端末を特定する情報とともに、付随情報記憶部３１１に格納される。

さらに、端末１００Ｂから表７に示されたような付随情報ＤＢの情報が送信されると、コンテンツサーバ３００では、すでに付随情報記憶部３１１に格納されている各付随情報と競合しないかが判断される。コンテンツサーバ３００において判断される競合は、上記したような端末１００における競合の内容に加えて、異なる端末１００から送信されてきた付随情報ＤＢを構成する付随情報に情報ＩＤを同じくするものがある場合も含む。そして、競合が無いと判断されると、端末１００Ｂから送信されてきた付随情報ＤＢの各付随情報が、送信元の端末を特定する情報とともに、付随情報記憶部３１１に格納される。

表８では、コンテンツサーバ３００に登録された付随情報ＤＢにおいて、表６の付随情報ＤＢを構成する付随情報と、表７の付随情報ＤＢを構成する付随情報とが、追加された状態が示されている。

なお、表８の付随情報ＤＢでは、表６や表７の付随情報ＤＢが有する欄に加えて、「登録端末」の欄が設けられている。当該欄には、各付随情報の送信元の端末１００を特定する情報が登録されている。表８において、「Ａ」は端末１００Ａを示し、「Ｂ」は端末１００Ｂを示す。

＜付随情報のバックアップ＞
端末１００で生成された付随情報をコンテンツサーバ３００に送信する際に、処理部１０１が実行する処理（バックアップ処理）について、説明する。図１２は、バックアップ処理のフローチャートである。なお、図１２の処理は、たとえば端末１００において更新ボタン６５０（図６参照）が操作されたことを条件として、開始される。

図１２を参照して、処理部１０１は、まずステップＳＡ５１０で、当該端末１００内の付随情報を収集して、ステップＳＡ５２０へ処理を進める。このとき、付随情報記憶部３１１の付随情報ＤＢに格納されているすべての付随情報が収集されてもよい。また、処理部１０１は、付随情報ＤＢにおいて、バックアップ処理ごとに、コンテンツサーバ３００への送信が完了した付随情報に送信完了等のタグを付してもよい。そして、ステップＳＡ５１０では、処理部１０１は、付随情報ＤＢに格納された付随情報のうち、当該タグが付されていない付随情報を収集してもよい。また、表４を参照して説明されたような、閲覧中の電子書籍の付随情報は、たとえばフラッシュメモリ１０６に格納される場合がある。このような場合、ステップＳＡ５１０では、処理部１０１は、既に付随情報記憶部３１１の付随情報ＤＢに登録された付随情報に加えて、フラッシュメモリ１０６に格納されている付随情報を、収集する。

ステップＳＡ５２０では、処理部１０１は、コンテンツサーバ３００に、付随情報の保存を要求する情報（コマンド等）を、ステップＳＡ５１０において収集した付随情報とともに送信して、ステップＳＡ５３０へ処理を進める。

図１３は、図１２の処理における端末１００からの要求に応じて、コンテンツサーバ３００において実行される処理のフローチャートである。

図１３を参照して、ステップＳＡ５２０の要求を受信すると、コンテンツサーバ３００の処理部３０１は、ステップＳＢ５１０で、要求に添付された付随情報のうち最初のレコードを読み込んで、ステップＳＢ５２０へ処理を進める。ここで、レコードとは、表４等の付随情報において１行の情報、つまり、「種類」「第１項目」「第２項目」「特性」についての１セットの付随情報を言う。これに従えば、表６の付随情報ＤＢは４つのレコードを含み、表７の付随情報ＤＢは１つのレコードを含む。

ステップＳＢ５２０では、処理部３０１は、処理対象となっているレコードの情報を読み込んで、ステップＳＢ５３０へ処理を進める。ここで処理対象となるレコードは、初回のステップＳＢ５２０であればステップＳＢ５１０において読み込んだレコードであり、２回目以降のステップＳＢ５２０であればステップＳＢ５６０で処理対象に指定されたレコードである。

ステップＳＢ５３０では、処理部３０１は、ステップＳＢ５２０で読み込んだ付随情報が、既に付随情報記憶部３１１に登録されている付随情報ＤＢを構成する付随情報と競合するか否かを判断する。競合するか否かの判断基準は、上記した通りである。そして、競合すると判断するとステップＳＢ５４０へ処理を進め、競合していないと判断するとステップＳＢ５５０へ処理を進める。

ステップＳＢ５４０では、処理部３０１は、コンテンツサーバ３００に登録されている付随情報記憶部３１１内の付随情報ＤＢから、競合すると判断された付随情報を削除して、ステップＳＢ５５０へ処理を進める。

ステップＳＢ５５０では、処理部３０１は、ステップＳＢ５２０で読み込んだ付随情報をコンテンツサーバ３００に登録されている付随情報記憶部３１１内の付随情報ＤＢに登録（追加）して、ステップＳＢ５６０へ処理を進める。

ステップＳＢ５６０では、処理部３０１は、端末１００がステップＳＡ５２０で送信した付随情報のうち、次のレコードへと処理対象を変更して、ステップＳＢ５７０へ処理を進める。

ステップＳＢ５７０では、処理部３０１は、ステップＳＢ５６０での処理対象の変更ができなかった、つまり、既に受信した付随情報において最後のレコードまで処理対象とされたか否かを判断し、そうであると判断するとステップＳＢ５８０へ処理を進め、まだ処理対象とされていないレコードがあると判断するとステップＳＢ５２０へ処理を戻す。

ステップＳＢ５８０では、処理部３０１は、ステップＳＡ５２０の要求を送信してきた端末１００に対して、送信された付随情報の登録が完了したことを示す情報（保存応答）を送信して、処理を終了する。

図１２に戻って、ステップＳＢ５８０において送信された保存応答を受信すると、端末１００の処理部１０１は、ステップＳＡ５３０で、当該保存応答を受信して、処理を終了する。

以上、図１２および図１３を参照して説明した処理によれば、端末１００において生成された付随情報が、端末１００における操作（更新ボタン６５０に対する操作）によって、コンテンツサーバ３００に送信される。コンテンツサーバ３００では、受信した付随情報が、当該コンテンツサーバ３００に格納された付随情報ＤＢに登録される。

たとえば、コンテンツサーバ３００の付随情報記憶部３１１において、表８に示されたような付随情報ＤＢが登録されているときに、表９に示されるような付随情報が端末１００からコンテンツサーバ３００に送信された場合を考える。

このような場合、コンテンツサーバ３００の付随情報記憶部３１１の付随情報ＤＢは、表１０に示されるように更新される。

表１０の付随情報ＤＢは、表８に示された内容に、表９に示されるよう内容が追加されたものに相当する。なお、表９の付随情報は、端末１００Ｂから送信されている。したがって、表１０では、表９の付随情報に対応するレコード（情報ＩＤ「rrr」のレコード）の「登録端末」の欄には、端末１００Ｂを表す「Ｂ」が登録されている。

なお、図１３を参照して説明した処理において、端末１００から送信された付随情報が、既にコンテンツサーバ３００の付随情報ＤＢに登録されている付随情報と競合する場合には、新たに端末１００から送信されてきた付随情報に上書き更新される。

なお、ステップＳＡ５１０（図１２参照）では、端末１００に格納（保存）されている付随情報のうち、ユーザが選択したもののみを、コンテンツサーバ３００に送信することもできる。

この場合、端末１００では、更新ボタン６５０が操作されると、ユーザに対して、端末１００において登録され、まだコンテンツサーバ３００へ送信されていない、付随情報のうち、コンテンツサーバ３００に送信するものを選択するための問合せがなされる。図１４は、このような問合せの画面の一例を示す図である。

図１４を参照して、画面７００は、メッセージを表示する欄７００Ａと、ＯＫボタン７２１と、キャンセルボタン７２２と、コンテンツサーバ３００に付随情報を送信される候補とされたコンテンツのそれぞれに対応したボタン７１１〜７１６とを含む。

処理部１０１は、端末１００において登録され、かつ、まだコンテンツサーバ３００へ送信されていない付随情報を収集し、当該付随情報のコンテンツＩＤを取得することによって、ボタン７１１〜７１６のそれぞれに表示する内容（コンテンツのタイトル等）を決定する。ここで表示されるボタンの数は、「６」に限定されず、取得されたコンテンツＩＤの数である。また、このようなボタンは、上下方向に配列されているが、当該配列方向にスクロール可能に表示されることにより、画面７００により多くのボタンを関連付けることができる。１つの画面に多くのボタンを関連付け、それらの一部を画面に表示し、また、画面内に表示されるボタンをスクロール操作に応じて変化させることは、周知の技術によって実現可能であるため、ここでは説明を繰り返さない。

ユーザは、画面７００のボタン７１１〜７１６から、付随情報をコンテンツサーバ３００に送信するコンテンツを選択し、ＯＫボタン７２１を操作する。これにより、ステップＳＡ５１０で、処理部１０１は、選択されたコンテンツの付随情報を、収集する。一方、キャンセルボタン７２２が操作されると、バックアップ処理が実行されず、表示部１０２における表示は、電子書籍の閲覧等の画面に戻される。そして、このような処理内容を説明するための情報が、欄７００Ａに表示される。

ステップＳＡ５３０で保存応答を受信すると、処理部１０１は、付随情報のバックアップが終了したことを報知する画面を、表示部１０２に表示してもよい。図１５は、付随情報のバックアップが終了したことを報知する画面の一例を示す図である。

図１５を参照して、画面７５０には、バックアップが完了した旨のメッセージが表示されている。なお、付随情報のバックアップができなかったコンテンツがあった場合には、当該画面７５０の下方にその旨の表示がなされる。画面７５０に対してＯＫボタン７５１が操作されると、バックアップ処理が終了する。

なお、ステップＳＢ５４０では、競合する付随情報がある場合には、既に登録されている付随情報がコンテンツサーバ３００の付随情報ＤＢから削除された。このような削除は、同一の端末１００（たとえば、競合する付随情報の送信元がいずれも端末１００Ａである場合）から送信された付随情報間でだけ適用にされ、異なる端末から送信された付随情報間では適用されないようにしてもよい。もしくは、異なる端末から送信された付随情報間でのみ適用され、同一の付随情報から送信された付随情報の間では適用されないようにしてもよい。この場合、後からコンテンツサーバ３００へ送信された付随情報は、コンテンツサーバ３００の付随情報ＤＢには登録されない。この場合、処理部３０１は、競合したことによりコンテンツサーバ３００に登録できなかった付随情報を、送信元の端末１００に返信してもよい。このような返信を受けた端末１００では、その旨が表示部１０２に表示される。図１６は、登録されなかった付随情報を受信した端末１００において表示される画面の一例を示す図である。

図１６を参照して、画面７６０は、コンテンツサーバ３００でバックアップができなかったことを示すメッセージを表示する表示欄７６０Ａと、ＯＫボタン７５１と、返信されてきた付随情報に対応するコンテンツを表示するボタン７６１，７６２とを含む。この場合、画面７６０を見たユーザがＯＫボタン７５１を操作すると、バックアップ処理が終了する。

＜バックアップ処理の変形例（１）＞
本実施の形態のシステムでは、コンテンツサーバ３００において付随情報の競合が発生した場合に、処理部３０１は、新たにコンテンツサーバ３００に送信された付随情報を、競合が解消するように修正した後、付随情報ＤＢに登録してもよい。なお、以下の説明では、付随情報の競合の一例として、情報ＩＤが同一となることにより競合が生じた場合を説明する。

図１７は、図１２のバックアップ処理の変形例のフローチャートである。
図１７を参照して、処理部１０１は、ステップＳＡ５３０でコンテンツサーバ３００から保存応答を受信すると、ステップＳＡ５４０で、当該保存応答に含まれる情報に従い、必要に応じて、自機の付随情報ＤＢにおいて情報の書き換えを行う。

図１８は、図１３の処理部３０１の処理の変形例のフローチャートである。
図１８を参照して、ステップＳＢ５３０で処理対象の付随情報が既にコンテンツサーバ３００の付随情報ＤＢに登録されている付随情報と競合すると判断すると、ステップＳＢ５４１へ処理を進める。

ステップＳＢ５４１では、処理部３０１は、処理対象の付随情報の情報ＩＤを、すでの付随情報ＤＢに登録されているすべての付随情報と異なるように書き換えて、ステップＳＢ５５０へ処理を進める。

ステップＳＢ５５０では、処理部３０１は、処理対象の付随情報を、付随情報ＤＢに登録する。この場合、ステップＳＢ５４１において情報ＩＤを書き換えている場合には、情報ＩＤを書き換えられた後の付随情報を、付随情報ＤＢに登録する。

その後、処理部３０１は、ステップＳＢ５６０〜ステップＳＢ５７０の処理を実行し、ステップＳＢ５７０において未処理のレコードがなくなったと判断するとステップＳＢ５８１へ処理を進める。

ステップＳＢ５８１では、処理部３０１は、ステップＳＢ５４１において情報ＩＤを書き換えた場合には、書き換えの対象となった付随情報について、書換前後の付随情報を保存応答とともに送信元の端末１００に送信して、処理を終了する。

図１７に戻って、端末１００の処理部１０１は、ステップＳＡ５３０で、上記の書換前後の付随情報と保存応答を受信して、ステップＳＡ５４０へ処理を進める。

ステップＳＡ５４０では、処理部１０１は、ステップＳＡ５３０で書換前後の付随情報を受信した場合、自機の付随情報ＤＢにおいて、対象の付随情報の情報ＩＤを処理部３０１による書換後のものへと書き換えて、バックアップ処理を終了する。

以下、具体例を説明する。
コンテンツサーバ３００において表１０に示された付随情報ＤＢが登録されているときに、端末１００Ｂから、表１１に示されたような付随情報が送信されてきたとする。

表１１の付随情報は、情報ＩＤが「sss」のものを含む。なお、表１０に示されるように、すでにコンテンツサーバ３００に登録されている付随情報にも、情報ＩＤが「sss」のものが存在する（表１０の上から３行目のレコード）。したがって、表１１に示されるような付随情報を受信し、情報ＩＤ「sss」のレコードが処理対象となると、処理部３０１は、競合が生じたと判断する（ステップＳＢ５３０でＹＥＳ）。

そして、処理部３０１は、ステップＳＢ５４１で、当該付随情報の情報ＩＤを、表１０に示されたいずれのレコードとも重複しないように、書き換える。書換後の付随情報の一例を、表１２に示す。

表１２では、情報ＩＤが「vvv」に書き換えられている。なお、表１０から理解されるように、すでにコンテンツサーバ３００に登録されている付随情報ＤＢには、情報ＩＤが「vvv」のレコードは存在しない。

そして、処理部３０１は、ステップＳＢ５５０で、書換後の付随情報、つまり、表１２に示した付随情報を、付随情報ＤＢに登録する。登録後の付随情報ＤＢを、表１３に示す。

表１３では、表１０と比較して、情報ＩＤが「vvv」のレコードが追加されている。
さらに、処理部３０１は、書換前後の付随情報を、送信元の端末１００Ｂに送信する（ステップＳＢ５８１）。これにより、端末１００Ｂの処理部１０１は、ステップＳＡ５３０で、保存応答とともに、表１１の付随情報（書換前）と表１２の付随情報（書換後）を受信する。

そして、端末１００Ｂの処理部１０１は、ステップＳＡ５４０で、自機の付随情報ＤＢを、書換後の情報に従って書き換える。書換前の端末１００Ｂの付随情報ＤＢの一例を、表１４に示す。

表１４の付随情報ＤＢは、書換前のレコード（情報ＩＤ「sss」のレコード）を含む。
そして、ステップＳＡ５４０の処理によって情報を書き換えられた後の付随情報ＤＢの一例を、表１５に示す。

表１５では、表１４において情報ＩＤ「sss」のレコードの情報ＩＤのみが、「vvv」に書き換えられている。

＜バックアップ処理の変形例（２）＞
本変形例では、コンテンツサーバ３００において付随情報の競合が生じたと判断された場合、競合の対象となった付随情報の取り扱いをユーザに問合せる。

図２０に、本変形例のコンテンツサーバ３００の処理部３０１が実行する処理のフローチャートを示す。図２０は、変形例（１）の図１８の処理の変形例に相当する。

図２１に、本変形例の端末１００の処理部１０１が実行する、ステップＳＡ５４０（図１７参照）のサブルーチンのフローチャートを示す。図２１は、変形例（１）の図１９の処理の変形例に相当する。

図２０を参照して、ステップＳＢ５３０で競合があると判断すると、処理部３０１は、ステップＳＢ５５１へ処理を進める。ステップＳＢ５５１では、処理部３０１は、ステップＳＢ５２０で処理対象としたレコードを、コンテンツサーバ３００の付随情報ＤＢ中の競合の相手となった付随情報とともに競合ＤＢに登録して、ステップＳＢ５６０へ処理を進める。競合ＤＢは、たとえば、記憶部３０２内の特定の記憶領域内に設定される。

一方、ステップＳＢ５３０で競合していないと判断すると、処理部３０１は、ステップＳＢ５５０で処理対象のレコードを付随情報ＤＢに登録して、ステップＳＢ５６０へ処理を進める。

ステップＳＢ５６０では、処理対象が、端末１００から受信した付随情報の次のレコードへと変更される。

本変形例では、端末から受信した付随情報は、コンテンツサーバ３００の付随情報ＤＢ中の付随情報と競合すると判断されると、当該付随情報は、一旦競合ＤＢに格納される。

そして、受信した付随情報のすべてのレコードを処理した後（ステップＳＢ５７０でＹＥＳ）、処理部３０１は、ステップＳＢ５８２で、付随情報の送信元の端末１００に、保存応答とともに競合ＤＢに登録した付随情報のリスト（競合レコードリスト）を送信する。

これに応じて、付随情報の送信元の端末１００では、処理部１０１は、ステップＳＡ５３０でこれらを受信し、そして、ステップＳＡ５４０へ処理を進める。以下の処理を、ステップＳ５４０のサブルーチンのフローチャートを示す図２１を参照して説明する。

処理部１０１は、ステップＳＡ５４１で、競合レコードリストに含まれる各付随情報についての対処を問い合わせるダイアログを表示部１０２に表示する。図２２は、当該ダイアログの表示画面の一例を示す図である。

図２２を参照して、画面８００は、競合レコードリストに含まれるすべての付随情報を示す表８１０を含む。表８１０には、３つのレコードについて、端末１００側の付随情報と、それに競合するコンテンツサーバ３００側の付随情報が示されている。

また、画面８００は、各レコードのそれぞれの対処を指定するための欄８２１〜８２３を含む。

本変形例において指定できる対処は、以下の３種類である。
１．強制的にバックアップする
２．サーバの情報を取り込む
３．何もしない
「１．強制的にバックアップする」は、コンテンツサーバ３００の付随情報ＤＢに登録された付随情報を、当該端末１００から送信されたものに置き換えることを指示する対処である。

「２．サーバの情報を取り込む」は、当該端末１００で登録されている付随情報を、コンテンツサーバ３００の付随情報ＤＢに登録されている、競合する付随情報に置き換えることを指示する対処である。

「３．何もしない」は、競合が生じた付随情報は、コンテンツサーバ３００に登録されているものはそのまま、また、端末１００の付随情報ＤＢに登録されているものもそのままにしておくことを指示する対処である。この場合、コンテンツサーバ３００の付随情報ＤＢと端末１００の付随情報ＤＢとでは、競合した部分は互いに異なる情報を登録された状態になる。

画面８００は、実行ボタン８３１とキャンセルボタン８３２をさらに含む。キャンセルボタン８３２が操作されると、そこでバックアップ処理が終了する。したがって、競合したと判断されたすべてのレコードが、端末１００ではそのまま登録され続け、コンテンツサーバ３００では付随情報ＤＢには登録されず競合ＤＢに登録された状態となる。実行ボタン８３１が操作されると（ステップＳＡ５４２でＹＥＳ）、ステップＳＡ５４３へ処理が進められる。

ステップＳ５４３では、処理部１０１は、図２２を参照して説明したような問合せの結果、端末１００側で付随情報ＤＢの情報の書換を指示された付随情報（上記２．を指定された付随情報）があるか否かを判断する。そして、そのような付随情報があると判断するとステップＳＡ５４４へ処理を進め、ないと判断するとステップＳＡ５４５へ処理を進める。

ステップＳＡ５４４では、処理部１０１は、上記２．を指定された付随情報について、自機の付随情報ＤＢにおいて、競合した付随情報を既にコンテンツサーバ３００に登録されていた競合相手の情報に書き換えて、ステップＳＡ５４５へ処理を進める。

ステップＳＡ５４５では、処理部１０１は、図２２を参照して説明したような問合せの結果、コンテンツサーバ３００に登録された情報を強制的に端末１００側の情報に書換えるように指示された付随情報（上記１．を指定された付随情報）があるか否かを判断する。そして、そのような付随情報があると判断するとステップＳＡ５４６へ処理を進め、ないと判断すると処理を図１７に戻す。これにより、端末１００側の処理が終了する。

ステップＳ５４６では、上記１．を指定された付随情報について、コンテンツサーバ３００に強制バックアップの要求を送信して、処理を図１７に戻す。これにより、端末１００側の処理が終了する。

図２０に戻って、ステップＳＢ５８２で保存応答を送信した後、処理部３０１は、ステップＳＢ５８３で、端末１００から強制バックアップの要求を受信したか否かを判断する。そして、受信したと判断すると、ステップＳＢ５８４へ処理を進める。

ステップＳＢ５８４では、処理部３０１は、強制バックアップを行って、処理を終了させる。強制バックアップとは、ステップＳＢ５３０で競合すると判断した付随情報を、端末１００から送信されたものに上書きして、コンテンツサーバ３００の付随情報ＤＢを更新することをいう。つまり、端末１００から送信された付随情報がコンテンツサーバ３００に登録されている付随情報と競合した場合、強制的に、端末１００から送信された付随情報のみを残すように、コンテンツサーバ３００の付随情報ＤＢを更新することをいう。

なお、処理部３０１は、ステップＳＢ５８３において、たとえば特定の時間以上端末１００から強制バックアップ要求を受信しなければ、図２０に処理を進めるように構成されてもよい。

＜付随情報の取り出し＞
図１のシステムでは、端末１００は、コンテンツサーバ３００に、当該コンテンツサーバ３００の付随情報ＤＢに登録されている付随情報の取り出しを要求する場合もある。

図２３は、端末１００において付随情報の取り出しのために実行される処理のフローチャートである。図２４は、端末１００から取り出しの要求を受けたコンテンツサーバ３００において実行される処理のフローチャートである。

図２４を参照して、処理部１０１は、電子書籍アプリの実行中等に付随情報の取り出しを要求するための操作がなされると、ステップＳＡ７１０で、表示部１０２に、付随情報の取り出しの対象となるコンテンツの一覧を表示して、ステップＳＡ７２０へ処理を進める。図２５は、付随情報の取り出しの対象となるコンテンツの一覧を表示する画面の一例を示す図である。

図２５を参照して、画面９００では、メッセージを表示する欄９００Ａと、ＯＫボタン９２１と、キャンセルボタン９２２と、付随情報の取り出しの対象となるコンテンツのそれぞれに対応したボタン９１１〜９１６とを含む。付随情報の取り出しの対象となるコンテンツとは、コンテンツ記憶部１０４Ａに登録されているコンテンツである。ユーザは、ボタン９１１〜９１６のうち、付随情報の取り出しを希望するコンテンツに対応したボタンを操作することにより、付随情報の取り出しを希望するコンテンツを指定する。

ステップＳＡ７２０では、処理部１０１は、指定されたコンテンツの付随情報の取り出しの要求を、コンテンツサーバ３００に送信する。

図２４を参照して、処理部３０１は、これに応じて、ステップＳＢ７１０で、端末１００からの付随情報の取り出しの要求を受信して、ステップＳＢ７２０へ処理を進める。

ステップＳＢ７２０では、処理部３０１は、受信した情報に基づき、コンテンツサーバ３００内の付随情報ＤＢから付随情報を収集して、ステップＳＢ７３０へ処理を進める。具体的には、ステップＳＢ７２０では、処理部３０１は、コンテンツサーバ３００内の付随情報ＤＢにおいて、端末１００から取り出しの要求を受信したコンテンツＩＤに関連付けられて登録されている付随情報を収集する。

そして、処理部３０１は、ステップＳＢ７３０で、ステップＳＢ７２０で収集した付随情報を、取り出し応答として端末１００へ送信する。

図２３に戻って、処理部１０１は、ステップＳＡ７３０で、上記取り出し応答を受信して、ステップＳＡ７４０へ処理を進める。

ステップＳＡ７４０では、処理部１０１は、受信した付随情報で、自機の付随情報ＤＢを上書き更新して、処理を終了する。図２６は、付随情報の取り出し処理が終了したときに、その旨を報知するために、処理部１０１が表示部１０２に表示する画面の一例を示す図である。

なお、ステップＳＡ７４０では、処理部１０１は、自機の付随情報ＤＢに登録されている情報と受信した付随情報の間で競合が生じた場合、自機の登録情報を優先し、受信した情報から競合した情報を破棄してもよい。または、コンテンツサーバ３００に登録された情報を優先し、自機に登録されていた情報を、競合の開いてとなった受信した情報で置換して、自機の付随情報ＤＢを更新してもよい。

＜端末の具体例＞
以上説明した本実施の形態において、端末１００は、コンテンツの再生機能を有する情報処理装置であれば、種々の機器によって実現することができる。

たとえば、端末１００は、図２７に示されるように、タブレット端末によって実現されてもよい。

図２７に示されたタブレット端末（端末１００）では、その筐体に、表示装置１４とともに、操作ボタン１５Ａが備えられている。図２７に示された端末１００では、表示装置１４と重ねられてタッチセンサが設けられ、入力装置１５は、当該タッチセンサおよび／または操作ボタン１５Ａによって、構成される。

また、端末１００は、図２８に示されるように、スマートフォン端末によって、つまり、通話機能を有するような端末によって実現される場合もある。

図２８に示されたスマートフォン端末（端末１００）では、その筐体に、表示装置１４とともに、操作ボタン１５Ｂ〜１５Ｄが備えられている。図２８に示された端末１００では、表示装置１４と重ねられてタッチセンサが設けられ、入力装置１５は、当該タッチセンサおよび／または操作ボタン１５Ｂ〜１５Ｄによって、構成される。

また、端末１００は、図２９に示されるように、携帯性を備えた端末ではなく、オフィス等において設置されるパーソナルコンピュータによって実現される場合もあり得る。

パーソナルコンピュータによって実現される端末１００には、モニタ１４Ａと、キーボード１５Ｅおよびマウス１５Ｆとが、接続されている。この場合、表示装置１４は、モニタ１４Ａにおける表示を制御する。つまり、モニタ１４Ａのドライバソフトウェアまたはドライバ回路基板によって、実現される。この例では、キーボード１５Ｅおよび／またはマウス１５Ｆによって、入力装置１５が構成される。

また、端末１００は、図３０に示されるように、テレビジョン受像機によって実現される端末１００は、モニタと、リモートコントローラ（以下、「リモコン」と称する）とを含む。このような例では、リモコンによって入力装置１５が構成され、また、モニタによって表示装置１４が構成される。

＜その他の変形例等＞
図１のシステムでは、付随情報ＤＢの更新のための処理が、電子書籍（コンテンツ）の再生（閲覧）のための処理とは独立して、実行される。具体的には、たとえばオフラインで電子書籍が閲覧された場合でも、処理部１０１は表４等を参照して説明した付随情報を生成し、そして、当該付随情報を表５等を参照して説明した付随情報ＤＢに登録する。そして、オンラインで、電子書籍の閲覧中か否かに関わらず、複数のコンテンツについての付随情報のバックアップを、コンテンツサーバ３００に対して行うことができる。また、電子書籍の閲覧中か否かに関わらず、コンテンツサーバ３００に１以上の電子書籍（コンテンツ）の付随情報の取り出しを要求することができる。

これにより、オフラインで再生させたコンテンツについて生成した付随情報を、当該コンテンツの閲覧作業とは独立して、コンテンツサーバ３００に登録することができる。また、当該ユーザが所有する他の端末１００で生成された付随情報を、端末１００で受信し登録することができる。

なお、受信する付随情報は、同じユーザのものに限定されない。他のユーザがコンテンツサーバ３００に登録した付随情報であっても、端末１００において受信することができるように、システムは構成されてもよい。この場合、コンテンツサーバ３００では、付随情報は、他のユーザが受信することを許可するものが指定されて、登録されてもよい。この場合、コンテンツサーバ３００は、付随情報の取り出しを要求してきたユーザが、当該付随情報を登録したユーザと異なる場合は、登録されている付随情報のうち、上記指定があるもののみを、要求してきたユーザの端末１００へ送信する。

図１のシステムでは、付随情報ＤＢの更新は、更新ボタン６５０（図６参照）が操作されることによって、端末１００からコンテンツサーバ３００に付随情報が送信される、バックアップ処理によって行われる場合もあれば、図２３〜図２６を参照して説明したように、端末１００が、コンテンツサーバ３００に登録されている付随情報を取り出して行われる場合もある。なお、図１のシステムにおいて、これらの態様の双方で付随情報の更新が行われるように構成されてもよい。

今回開示された各実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１００，１００Ａ〜１００Ｃ 端末、１０１，２０１，３０１ 処理部、１０１Ａ コンテンツ再生部、１０１Ｂ リスト表示部、１０１Ｃ コンテンツ取得部、１０１Ｄ コンテンツリスト取得部、１０１Ｅ 付随情報生成部、１０１Ｆ 付随情報取得部、１０１Ｇ 付随情報送信部、１０２ 表示部、１０３ 操作部、１０４，３０２ 記憶部、１０４Ａ コンテンツ記憶部、１０４Ｃ ユーザ情報記憶部、１０４Ｄ，３１１ 付随情報記憶部、１０５，３０３ 通信部、１０６ フラッシュメモリ、２００ コンテンツ配信サーバ、３００ コンテンツサーバ、３０１Ａ リスト生成部、３０１Ｂ リスト配信部、３０１Ｃ 付随情報管理部、３０１Ｘ コンテンツ配信部。

Claims (9)

1. コンテンツを再生するための再生手段と、
   前記再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するための生成手段と、
   前記付随情報を格納するための記憶手段と、
   前記生成手段によって生成された付随情報をサーバ装置へ送信するための送信手段とを備え、
   前記再生手段は、前記記憶手段に格納された前記付随情報に基づいてコンテンツを再生し、
   前記送信手段は、前記生成手段によって生成された付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信するための送信手段とを備える、端末装置。
2. 前記サーバ装置から、前記送信手段が送信した前記付随情報が、すでに前記サーバ装置に格納されている他の付随情報と競合する旨の通知を受信するための受信手段と、
   前記受信手段が受信した通知に基づいて、前記送信手段が送信した前記付随情報の変更を許可するか否かの情報を入力するための入力手段とを備え、
   前記受信手段は、前記入力手段に前記送信手段が送信した前記付随情報の変更を許可する情報が入力された場合には、修正後の前記付随情報を前記記憶手段に格納する、請求項１に記載の端末装置。
3. 前記サーバ装置から、前記送信手段が送信した前記付随情報が、すでに前記サーバ装置に格納されている他の付随情報と競合する旨の通知を受信するための受信手段と、
   前記受信手段が受信した通知に基づいて、前記送信手段が送信した前記付随情報の前記サーバ装置での登録の指示を入力するための入力手段とを備え、
   前記送信手段は、前記入力手段に前記付随情報の前記サーバ装置での登録の指示が入力された場合には、前記サーバ装置に、前記送信手段が送信した前記付随情報の登録を指示する情報を送信する、請求項１に記載の端末装置。
4. 記憶手段とコンテンツを再生する再生手段とを備える端末装置のコンピュータによって実行される、当該端末装置の制御プログラムであって、
   前記制御プログラムは、前記端末装置に、
   前記再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するステップと、
   前記付随情報を前記記憶手段に格納するステップと、
   生成された付随情報をサーバ装置へ送信するステップとを実行させ、
   前記再生手段は、前記記憶手段に格納された前記付随情報に基づいてコンテンツを再生し、
   付随情報をサーバ装置へ送信するステップは、生成された前記付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信する、端末装置の制御プログラム。
5. 記憶手段とコンテンツを再生する再生手段とを備える端末装置のコンピュータによって実行される、当該端末装置の制御方法あって、
   前記再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するステップと、
   前記付随情報を前記記憶手段に格納するステップと、
   生成された付随情報をサーバ装置へ送信するステップとを備え、
   前記再生手段は、前記記憶手段に格納された前記付随情報に基づいてコンテンツを再生し、
   付随情報をサーバ装置へ送信するステップは、生成された前記付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信する、端末装置の制御方法。
6. コンテンツを再生するための再生手段を備える端末装置と、前記端末装置と通信可能なサーバ装置とを備えた、コンテンツ再生システムであって、
   前記端末装置は、
   前記再生手段が再生可能なコンテンツに付随する情報である付随情報を生成するための生成手段と、
   前記付随情報を格納するための第１の記憶手段と、
   前記生成手段によって生成された付随情報を前記サーバ装置へ送信するための送信手段とを含み、
   前記サーバ装置は、
   コンテンツの付随情報を格納するための第２の記憶手段と、
   前記再生手段は、前記第１の記憶手段に記憶された前記付随情報に基づいてコンテンツを再生し、
   前記送信手段は、前記生成手段によって生成された付随情報を、当該付随情報が対応するコンテツの閲覧の開始または終了とは独立してサーバ装置へ送信するための送信手段とを備える、コンテンツ再生システム。
7. 前記サーバ装置は、
   前記送信手段によって送信された前記付随情報を管理するための管理手段をさらに含み、
   前記管理手段は、
   前記送信手段によって送信された前記付随情報と前記第２の記憶手段に格納された付随情報とが競合するか否かを判断し、
   競合すると判断した場合には、前記送信手段によって送信された前記付随情報を、競合を回避するように修正し、修正後の前記付随情報を前記第２の記憶手段に格納する、請求項６に記載のコンテンツ再生システム。
8. 前記管理手段は、
   前記送信手段によって送信された前記付随情報と前記第２の記憶手段に格納された付随情報とが競合すると判断した場合に、前記端末装置に修正後の前記付随情報を送信する、請求項７に記載のコンテンツ再生システム。
9. 前記管理手段は、
   前記送信手段によって送信された前記付随情報と前記第２の記憶手段に格納された付随情報とが競合すると判断した場合に、前記端末装置に修正後の前記付随情報の登録の可否を問い合わせ、登録を許可する回答を受信したことを条件として、前記第２の記憶手段に、修正後の前記付随情報を前記第２の記憶手段に格納する、請求項７または請求項８に記載のコンテンツ再生システム。

Images