JP2008269637A - 情報処理装置および方法、プログラム、並びに記録媒体 - Google Patents

情報処理装置および方法、プログラム、並びに記録媒体 Download PDF

Info

Publication number
JP2008269637A
JP2008269637A JP2008148276A JP2008148276A JP2008269637A JP 2008269637 A JP2008269637 A JP 2008269637A JP 2008148276 A JP2008148276 A JP 2008148276A JP 2008148276 A JP2008148276 A JP 2008148276A JP 2008269637 A JP2008269637 A JP 2008269637A
Authority
JP
Japan
Prior art keywords
page
data
block
text
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008148276A
Other languages
English (en)
Other versions
JP4783401B2 (ja
Inventor
Tsuyoshi Kanai
剛志 金井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2008148276A priority Critical patent/JP4783401B2/ja
Publication of JP2008269637A publication Critical patent/JP2008269637A/ja
Application granted granted Critical
Publication of JP4783401B2 publication Critical patent/JP4783401B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Document Processing Apparatus (AREA)

Abstract

【課題】電子書籍用のデータを簡便に作成する。
【解決手段】出版社から供給される電子書籍用のデータは、さまざまなフォーマットによるデータであるため、ＸＭＬコンバータ部２１によりＸＭＬ形式のデータに変換される。データコンバータ部２２は、ＸＭＬコンバータ部２１によりコンバートされたＸＭＬ形式のデータに対して、ユーザに配布する形式のデータに変換すると共に、電子書籍として扱い安くするためのデータを付加する。著作権保護処理部２３は、作成されたデータに著作権情報を付加し、必要に応じ暗号化を施す。配信部２４は、配信するためのデータを記憶すると共に、ユーザの要求により、その記憶されているデータを配信する。本発明は、電子書籍用のデータを作成する装置に適用できる。
【選択図】図２

Description

本発明は情報処理装置および方法、プログラム、並びに記録媒体に関し、特に、電子化された書籍を扱うのに好適な情報処理装置および方法、プログラム、並びに記録媒体に関する。
テキストデータから構成される電子書籍が一般に普及しつつある。電子書籍は、紙の書籍（以下、紙書籍と称する）で、一般に活字として記録されている情報をテキストデータの情報として、所定の電子書籍用の端末装置により、あたかも紙書籍によりページが見開きの状態となっているように表示されるものである。電子書籍は、所定のボタンにより1ページ分のテキスト（画像）がスライドして表示されることにより、あたかも紙書籍を広げて、1ページずつ捲っているかのように表示される。
従来の電子書籍用の端末装置は、読みやすい表示を行うために、表示部が一時に表示し得る最大の文字数分の範囲内において、書籍用のテキストデータを、予め設定されている区切りに関するファイルに規定されている条件に基づいて、順次区切り、区切った各区切り単位のテキストデータを表示部に順次表示させるようにすることが提案されている（例えば、特許文献１参照）。
また、従来の電子書籍用の端末装置またはその端末装置で扱われるデータを簡便に作成できるようにする方法も提案されている（例えば、特許文献２参照）。
特開２００２―１９７０８８号公報 特開２００１−５２０１６号公報
電子書籍用の端末装置は、ユーザが携帯可能な大きさに設計さている。そのために、その端末装置のテキストデータを表示する表示部の大きさには制限があり、必ずしも、その大きさが全てのユーザにとって最適なものであるとは限らない。例えば、ユーザにより、同じ領域に同じ大きさで同じ文字が表示されていても、その見やすさには差異がある。
そこで、限られた表示領域の中で、テキストデータを見やすくするために、上述した特許文献１に開示されているようなことが提案されている。しかしながら、特許文献１においては、表示部が一時に表示し得る最大の文字数分の範囲内において、書籍用のテキストデータを、予め設定されている区切りに関するファイルに規定されている条件に基づいて、順次区切り、区切った各区切り単位のテキストデータを表示部に順次表示させるようにしているが、その文字の大きさが適切なものであるとは限らない。
例えば、視力の良いユーザは、与えられた文字の大きさで読みやすいかもしれないが、視力の悪いユーザは、与えられた文字の大きさよりもさらに大きい文字の方が読みやすいと思うこともあるであろうと考えられる。すなわち、ユーザの好みの文字の大きさで表示させることができないといった問題があった。
また、表示部に表示できる最大の文字数で表示を行うということは、小説のような文字の羅列だけで構成されているようなテキストデータの場合はまだ良いが、新聞や雑誌などの静止画像が含まれ、コンテンツの全体としてのレイアウト自体にも特徴があるもの、文字の羅列だけだが、レイアウト自体に特徴を有するようなもの（例えば、脚本のようなセリフ毎に段落を変えた方が良いようなもの）などには、適していない。
このようなことは、特許文献２についても同様である。特許文献２で開示されているデータ構造は、画像などに対して有効かも知れないが、テキストなどに対しては、レイアウトが変更されてしまう、拡大、縮小がユーザの所望するように行われないなどの問題がある。
すなわち、静止画やテキストなどで構成されるレイアウト自体もユーザに提供することは、ユーザにとってもそのコンテンツをより楽しめる要因となり、また、そのコンテンツを作成した作成者の意志も尊重でき、好ましい状態であるが、これらのことは上述した特許文献１や特許文献２などで開示されている方法では解決できない問題であった。
本発明はこのような状況に鑑みてなされたものであり、ユーザに適切な大きさの文字や画像を提供できるようにし、レイアウトなどの著作権者の意志を反映したコンテンツの表示を提供し、さらに、ユーザが紙書籍と違和感がないように扱えるデータ構造を簡便に構築できるようにすることを目的とする。
本発明の一側面の情報処理装置は、電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータを記憶する記憶手段と、前記コンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集する編集手段とを備える。
前記スクラップブックは、異なるコンテンツデータからコピーされた複数の前記Pageオブジェクトを含む場合であっても、前記Page属性オブジェクトは１つしか含まないようにすることができる。
前記スクラップブックに新たに記事を追加する場合、スクラップブックの他の記事が表示されている状態で、指示があったときだけ表示される記事とするクリップ保存か、または、他の記事と同様にスクラップブックにおいて設定されている書式で描画される引用保存かを設定するようにすることができる。
前記クリップ保存を設定した場合、新たに登録する記事は、前記Imageオブジェクトとして保存するようにすることができる。
前記引用保存を設定した場合、前記スクラップブックに追加するとして指定された記事に係わる前記Pageオブジェクトの第１のＩＤ、保存する記事の先頭となる前記Blockオブジェクトの第２のＩＤ、および、保存する記事の末尾となる前記Blockオブジェクトの第３のＩＤを取得し、前記第１のＩＤに対応する前記Pageオブジェクトに記述されているコマンドを１行毎に解析し、そのコマンドが、Blockオブジェクトを参照する指示を出すためのコマンドである場合、解析対象とされているコマンドが参照する前記BlockオブジェクトのＩＤは、前記第２のＩＤと前記第３のＩＤとに挟まれる番号のＩＤであるか否かを判断し、挟まれるＩＤでないと判断したときには、前記Pageオブジェクト内の次の行の解析に処理を移行し、挟まれるＩＤであると判断したときには、前記Blockオブジェクトが参照するのはTextオブジェクトであるか否かをさらに判断し、Textオブジェクトではないと判断した場合、処理対象とされている前記Blockオブジェクト、そのBlockオブジェクトが参照しているオブジェクト、そのオブジェクトを描画するのに必要な全てのオブジェクトの情報を取得し、前記Textオブジェクトであると判断した場合、参照されている前記Blockオブジェクトと前記Textオブジェクトの描画属性を、スクラップブック専用の前記Page属性オブジェクトにあった属性に変更し、さらに、前記Textオブジェクトから参照されている全てのオブジェクトの情報を取得するようにすることができる。
既に作成されているスクラップブックに新たな記事を追加する場合、既に作成されているスクラップブックの最終ページに対応するPageオブジェクト内の最後のコマンドの後に、新たに追加する記事のBlockオブジェクトを参照するためのコマンドを付加し、新たに追加される記事に必要なオブジェクトのデータを、前記スクラップブックのデータとして追記し、その追記されたオブジェクトに関するオブジェクトテーブルを更新するようにすることができる。
前記既に作成されるスクラップブックの最終ページに新たな記事を追加できるか否かを判断し、追加できないと判断される場合には、新たにPageオブジェクトを作成し、その新たに作成されるPageオブジェクトのＩＤは、前記スクラップブックを構成するオブジェクト内のＩＤで、最も大きい値を有するＩＤに１だけ加算した値とし、そのようなＩＤが付加されたPageオブジェクトを、前記スクラップブック内の最終ページとするようにすることができる。
本発明の一側面の情報処理方法は、電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集するステップを含む。
本発明の一側面のプログラムは、電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集するステップを含む処理を実行させるコンピュータが読み取り可能なプログラム。
本発明の一側面の記録媒体は、電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集するステップを含む処理を実行させるコンピュータが読み取り可能なプログラムを記録している。
本発明の一側面の情報処理装置および方法、プログラム、並びに記録媒体においては、複数のオブジェクトから構成されるコンテンツデータから、所定の記事が切り取られ、その切り取られた記事を描画するのに必要なオブジェクトだけが、前記コンテンツデータから抽出される。
本発明によれば、電子書籍用のデータを作成することができる。また、作成されたデータを用いて、所定の端末で、コンテンツを閲覧することができる。
本発明によれば、電子書籍用のデータのフォーマットをオブジェクト化し、かつ、レイアウト形式にブロックという概念を導入することで、フォーマットの拡張性を高めることができる。
本発明によれば、電子書籍用のフォーマットをオブジェクト化したことにより、既にある内容をほとんど変えずに、新たな内容を付け足すことが簡単になる。また、新たな内容を簡便に追加できることを用いて、ユーザが、購入した電子書籍と同じフォーマットで、自分だけのスクラップブックを作成できる。
本発明によれば、電子書籍としてのコンテンツの文字を拡大して閲覧することが可能となる。その文字の拡大により、レイアウトが崩れとしても、見た目のページの区切りがわからず、一気にページを移動しても予想していたページにたどり着けないといったようなことを防ぐことが可能となる。また、そのようにすることで、線形にページを移動することが可能となる。
以下に、本発明の実施の形態について図面を参照して説明する。図１は、本発明を適用した情報処理システムの一実施の形態の構成を示す図である。図１に示したシステムは、デジタルデータにされた書籍を扱うシステムである。デジタルデータにされた書籍とは、ここでは、デジタルデータを取り扱うユーザ側の所定の端末で閲覧できるテキスト、画像、若しくは、これらの組み合わせにより構成されるものである。
現在一般的には、紙媒体の書籍（紙書籍）が流通している。そのような紙書籍は、出版社１−１乃至１−Ｎにより作成され、出版される。そのような紙書籍を出版している出版社１−１乃至１−Ｎが、デジタルデータ化された書籍（以下、適宜、電子書籍と記述する）も出版するとして説明する。
なお、以下の説明において、出版社１−１乃至１−Ｎを個々に区別する必要がない場合、単に、出版社１と記述する。また、他の部分も同様に記述する。
各出版社１からのデータは、データ作成装置２に供給される。出版社１は、電子書籍用のデータを、自社で取り扱っているデータ形式で作成し、そのデータをデータ作成装置２に供給する。そのため、各出版社１から供給されるデータは、必ずしも同一の形式のデータであるとは限らないため、データ作成装置２では、主に、異なるデータ形式を同一のデータ形式に変換する（コンバートする）処理を実行する。
例えば、各出版社１から供給されるデータ形式には、ＨＴＭＬ（Hyper Text Markup Language）、ＰＤＦ（Portable Document Format：Adobe Systems社のソフトウェアAcrobatで扱うファイル形式）、Open eBook仕様の形式などがある。よって、各出版社１から供給される電子書籍のデータは、同一の形式のデータではない可能性があるため、データ作成装置２により、データのコンバートが行われる。
データ作成装置２により作成されたデータは、市場３またはネットワーク４を介してユーザ側に提供（配信）される。ここでは、市場３を介してユーザ側に提供されるのは、パッケージメディア５であるとする。パッケージメディア５とは、例えば、メモリースティック（商標）などの記録媒体のことであり、ユーザ側の端末で扱うことができる媒体である。
ネットワーク４は、インターネットなどである。その構成は、有線でも無線でも良く、ＷＡＮ（World Area Network）やＬＡＮ（Local Area Network）などで構成される。なお、図１には記載していないが、出版社１とデータ作成装置２は、ネットワーク４を介してデータの授受を行うようにしても良い。さらに説明を加えるならば、出版社１とデータ作成装置２の間でのデータの授受は、ネットワークなどを介したものであっても良いし、所定の記録媒体にデータを記録し、郵便などで授受されるようにしても良く、そのデータの授受の形態はどのようなものでも良い。
ネットワーク４には、ＰＣ（Personal Computer）６−１，６−２が接続されている。ＰＣ６―１，６−２には、電子書籍を閲覧するためのユーザ端末７−１，７−２が接続されるように構成されている。また、ユーザ端末７−３，７−４は、ネットワーク４と直接接続されるように構成されている。
ＰＣ６は、ネットワーク４を介して他の装置（ここでは、データ作成装置２）とデータの授受を行う機能を通常有している。ＰＣ６が用いられる場合、データ作成装置２からのデータは、ＰＣ６により受信され、ＰＣ６を介してユーザ端末７に供給され、記憶される。
また、ＰＣ６が用いられない場合、データ作成装置２から直接的にユーザ端末７にデータが供給され、記憶される。
ユーザ端末７は、データ作成装置２とＰＣ６を介する経路のみで、データの授受を行えるように構成されていても良いし、ＰＣ６を介さない経路のみで、データに授受が行えるように構成されていても良い。もちろん、ＰＣ６を介する経路と、ＰＣ６を介さない経路の、両方の経路をユーザが選択できるような構成とされていても良い。
さらに、ユーザ端末７は、データ作成装置２からのデータをパッケージメディア５に記録されている状態で供給を受けるような構成にされている。ユーザ端末７の構成などについての詳細は後述する。
図２は、データ作成装置２の機能を示す機能ブロック図である。データ作成装置２は、ＸＭＬ（eXtensible Markup Language）コンバータ部２１、データコンバータ部２２、著作権保護処理部２３、配信部２４、および、パッケージメディア作成部２５から構成されている。
ＸＭＬコンバータ部２１は、出版社１から供給されるさまざまな形式のデータを、ＸＭＬ形式のデータにコンバート（変換）する。ＸＭＬコンバータ部２１によりコンバートされたデータは、データコンバータ部２２に供給される。データコンバータ部２２は、供給されたＸＭＬ形式のデータを、電子書籍として配信する形式のデータ（バイナリーデータ）に変換する。またその変換を行う際、データコンバータ部２２は、オブジェクトで構成されるコンテンツデータに変換する。
データコンバータ部２２には、出版社１から、ＸＭＬ形式のデータも、直接的に供給される。すなわち、ＸＭＬ形式のデータであれば、ＸＭＬコンバータ部２１による処理を必要としないため、ＸＭＬコンバータ部２１を介さずに、直接的に、データコンバータ部２２に出版社１からデータが供給されるようにしても良い。
データコンバータ部２２によりコンバートされたデータは、著作権保護処理部２３に供給される。著作権保護処理部２３は、電子書籍に係わる著作権を保護するための処理を行う部分であり、具体的には、供給されたデータに暗号化などの処理を施したり、著作権データを埋め込んだりする。この著作権保護処理部２３による処理は、必要に応じて行われれば良く、例えば、無料で配布される場合で、著作権の保護が必要ないようなデータに対しては行われないようにしても良い。
なお、本情報処理システムには、例えば、本出願人が先に出願した特願２００３−１６３９６８号に開示されたコンテンツ配信技術を適用することができる。この技術を適用した場合、著作権保護処理部２３は、データコンバータ部２２によりコンバートされたデータを暗号化して被暗号化コンテンツを作成し、この被暗号化コンテンツに、コンテンツ識別情報、デジタル権利管理情報、ライセンス識別情報、有効化キーブロックEKB、および、暗号化されたコンテンツキーからなるヘッダー部分を付加して、コンテンツファイルを作成する。
著作権保護処理部２３から出力されたデータは、配信部２４により配信される。配信部２４は、内部または外部に記憶部（不図示）を有し、その記憶部に、供給されたデータを記憶し、必要に応じ（ＰＣ６やユーザ端末７からの要求に応じ）、その記憶しているデータを読み出し、ネットワーク４を介して配信する。
パッケージメディア作成部２５は、パッケージメディア５に、電子書籍のデータを記録させることにより、市場４で売買されるパッケージメディア５を作成する。このパッケージメディア５に記録されるデータは、データコンバータ部２２から供給されるデータ、著作権保護処理部２３から供給されデータの、どちらか一方、または、両方から構成されるデータである。
例えば、宣伝などの目的で、無料で配布されるようなパッケージメディア５に対しては、データコンバータ部２２から供給されるデータのみが記録される。また、販売目的で、特定のユーザ（購入したユーザ）のみに配布されるようなパッケージメディア５に対しては、著作権保護処理部２３からのデータのみが記録される。または、販売目的であっても、例えば、最初の１００頁は、データコンバータ部２２からのデータが記録され、残りの頁は、著作権保護処理部２３からのデータが記録されるようにしても良い。
ここでは、図２に示したように、データ作成装置２として１つの装置のように図示し、説明するが、図２に示したデータ作成装置２内の各部は、それぞれ異なる装置として構成し、データ作成装置２は、複数の装置から構成されるシステムとしても良い。
例えば、各部を、１つのサーバとして構成した場合、各サーバは、所定のネットワークで接続され、互いにデータの授受が行えるように構成される。このように、各部を１つのサーバとして構成するようにした場合、出版社１は、ＸＭＬ形式のデータ以外のデータを供給するときには、ＸＭＬコンバータ部２１を構成するサーバと接続し、ＸＭＬ形式のデータを供給するときには、データコンバータ部２２と接続するようにする。
このように接続する先を異ならせるようにした場合（必ずしも、各部が１つのサーバとして構成されている必要性はなく、図２に示したように構成されていても良いが）、課金額を接続先により変更するようにしても良い。
データ作成装置２は、この場合、出版社１とは別に設けられているわけだが、そのデータ作成装置２を管理する管理者としては、このようなサービスを提供する場合、何らかのかたちで、料金を徴収する。その料金の徴収先としては、まず、出版社１が考えられる。出版社１から料金を徴収（課金）する場合、ＸＭＬコンバータ部２１によるコンバートを必要とした場合と、必要としなかった場合とで課金額を変更するようにしても良い。
このようにすれば、課金額が低い額として設定されるであろう、ＸＭＬコンバータ部２１を介さない、すなわち、データコンバータ部２２を接続先とし、ＸＭＬデータを供給する接続が増加すると考えられる。そのような接続の増加に伴い、ＸＭＬコンバータ部２１が必要ないと判断されるようになった場合、ＸＭＬコンバータ部２１を削除する構成とすることも可能となる。そのことにより、データ作成装置２のメンテナンスなどに係る費用を軽減させることができる。
また、そのことにより、換言すれば、出版社１側が、ＸＭＬ形式でデータを作成するようになることにより、電子書籍用のデータは、ＸＭＬ形式にすることが主流となり、その結果、電子書籍用のデータをＸＭＬ形式以外のデータで扱う出版社や、その出版社からデータの供給を受ける側の会社などと差別化を図ることが可能となると考えられる。
データ作成装置２を１または複数の装置で構成するようにした場合、データ作成装置２を構成する装置は、パーソナルコンピュータなどで構成することが可能である。データ作成装置２をパーソナルコンピュータなどで構成した場合の内部構成を、図３に示す。
図３に示したデータ作成装置２のＣＰＵ（Central Processing Unit）４１は、ＲＯＭ（Read Only Memory）４２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Random Access Memory）４３には、ＣＰＵ４１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース４５は、キーボードやマウスから構成される入力部４６が接続され、入力部４６に入力された信号をＣＰＵ４１に出力する。また、入出力インタフェース４５には、ディスプレイやスピーカなどから構成される出力部４７も接続されている。
さらに、入出力インタフェース４５には、ハードディスクなどから構成される記憶部４８、および、インターネットなどのネットワークを介して他の装置（例えば、ユーザ端末７）とデータの授受を行う通信部４９も接続されている。ドライブ５０は、磁気ディスク６１、光ディスク６２、光磁気ディスク６３、半導体メモリ６４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。
図２に示したデータ作成装置２の機能ブロック図と、図３に示したデータ作成装置２の内部構成例との対応関係を示す。ＸＭＬコンバータ部２１は、例えば、ＣＰＵ４１が、ＲＡＭ４３（またはＲＯＭ４２）に展開されるプログラムに基づく処理を実行することにより実現される。データコンバータ部２１や、著作権保護処理部２３も、同様に、ＣＰＵ４１がＲＡＭ４３に展開されるプログラムに基づく処理を実行することにより実現される。
なお、著作権保護処理部２３が必要とする著作権の情報などは、記憶部４８に記憶される。
出版社１からのデータは、通信部４９を介して提供される。または、磁気ディスク６１、光ディスク６２、光磁気ディスク６３、半導体メモリ６４などの記録媒体に記録され、ドライブ５０から読み込まれることにより供給される。
配信部２４は、記憶部４８と通信部４９により構成される。記憶部４８には、ユーザ側に配信する電子書籍のデータが記憶され、その電子書籍のデータが必要に応じ読み出され、通信部４９により配信される。もちろん、このような処理の制御を行うのは、ＣＰＵ４１である。
パッケージメディア作成部２５は、ドライブ５０により構成される。ドライブ５０には、上述したように磁気ディスク６１などの記録媒体（パッケージメディア５）が挿入され、その記録媒体に、記憶部４８に記憶されているデータが記録されることにより、電子書籍のデータが記録されたパッケージメディア５が作成される。もちろん、大量生産するためには、複数のドライブ５０が必要であり、また、同時に書き込みが行えるように構成されていることが好ましい。
上述したように、データ作成装置２は、１台の装置で構成される必要はないため、図３に示した構成の装置が、例えば、ＸＭＬコンバータ部２１としての機能のみを有するサーバとして構成されるようにしても良い。
なお、パッケージメディア５として配布（販売）する場合、電子書籍は紙書籍と異なり、その作成には時間を要しない。換言すれば、パッケージメディア５に、電子書籍のデータを記録させるのに必要な時間は、同じ書籍を紙書籍とする時間に比べれば短い時間である。そのことを利用し、パッケージメディア作成部２５は、書店などの店頭に、専用の端末として設置されるようにしても良い。
書店などの店頭に設置された場合、ユーザが、その端末を操作し、所望の電子書籍を選択すると、例えば、ネットワーク４を介して接続されている配信部２４と接続され、そのユーザが所望とした電子書籍の情報が送信される。そして、その情報に基づき、対応する電子書籍のデータが端末に送信される。端末は、その送信されてきたデータを記録媒体に記録する。
もちろん、書店などに設置される端末自体に、電子書籍のデータを記憶させておき、そのデータが、記録媒体に記録されるようにして良い。しかしながら、データ作成装置２に接続され、その配信部２４からデータが配信されるようにした場合、電子書籍のデータを一元的に、データ作成装置２側で管理することができるため、新たなデータの追加、古くなったデータの削除など、データの更新などに係わる処理を行いやすくなる。
また、データ作成装置２側のみでデータを管理するようにすれば、例えば、よく売れる書籍や、逆に売れない書籍などに関する統計を取りやすくなる。
書店などに端末などが設置される場合、ユーザが端末の前で、操作を開始してから、所望の電子書籍のデータが記録された記録媒体を取得するまでに係る時間は、ユーザが許容できる範囲内であると考えられるため、そのような端末やシステムは、普及すると考えられる。そのため、端末を製造する製造会社も、利益を得ることができる。
また、このようにすれば、出版社１側は、在庫を抱えるというリスクをなくすことができるという利点がある。また、紙媒体の場合、売れなければ、その書籍は処分されるため、紙の無駄な消費につながり、出版社１側にとっても、無駄な出費となるが、上述したような処理が行われることにより、パッケージメディア５が販売されるようになれば、記録媒体自体が無駄になるということを防ぐことが可能となる。
さらに、パッケージメディア５として、揮発性の記録媒体を用いれば、紙書籍の場合と同様に、パッケージメディア５に予めデータを記録させた状態で、書店に並べて販売するとしても、仮に売れなく、回収することになっても、記録媒体自体は、再利用することができ、リスクの軽減、コストの軽減を図ることが可能となる。
なお、ここでは、出版社１から電子書籍のデータが供給されるとしたが、必ずしも、出版社１からのみ電子書籍のデータが供給される必要はない。例えば、作者が、データ作成装置２にデータを直接的に送信するような仕組みを設けても良い。このようにすれば、例えば、自主出版などと称され、作者が自己の資金で出版物を出版するような場合においても、電子書籍であれば、紙媒体にする必要がなく、紙代、印刷代などを削減することができ、さらに、上述したような形態を取ることにより、在庫を抱えることがなくなるので、売れるたぶんの経費だけですむことになる。
すなわち、作者側としては、出版にかかるコストの削減を図ることができ、データ作成装置２を管理する側としては、出版社１以外の顧客からも収益を得ることができる。また、ユーザ側も、今まで、発売されなかったような有名ではない作者の作品を、または、有名名作者であっても商業ベースにのせることができないなどの判断のために、一般的に販売されなかったような作品を、より簡便に購入することができるようになり、さまざまな作者の作品を購入することができる（選択の幅が広がる）。
次に、このようなデータ作成装置２により作成される電子書籍のデータを処理し、ユーザにテキストや画像などで構成される書籍を提供するユーザ端末７について説明を加える。図４は、ユーザ端末７の外観の構成を示す図である。ユーザ端末７は、電子書籍としてのテキストや画像（以下、適宜、コンテンツと記述する）を表示するための表示部７１を備える。その表示部７１を有する面に対して、側面に位置する部分には、まず、ＵＳＢ（Universal Serial Bus）インタフェース７２が設けられている。
このＵＳＢインタフェース７２は、ＰＣ６（図１）と接続し、データの授受を行うために設けられている。ユーザ端末７は、ＵＳＢインタフェース７２の他に、イーサネット（登録商標）に接続するためのイーサネットインタフェース７３も備えている。イーサネットインタフェース７３は、ネットワーク４（図１）を介してデータ作成装置２とデータの授受を行うために設けられている。
イーサネットインタフェース７３は、無線、有線を問わず、ネットワーク４に接続できる機能を有し、データ作成装置２とデータの授受を行える機能を有していればよい。
ユーザ端末７は、その側面にドライブ７４を有する。このドライブ７４には、パッケージメディア５が挿入される。ドライブ７４は、挿入されたパッケージメディア５から電子書籍のデータを読み出せるように構成されている。
さらに、ユーザ端末７は、その側面に、送りボタン７５と戻りボタン７６の２つのボタンを有する。この送りボタン７５と戻りボタン７６は、表示部７２に表示されているコンテンツをスクロールする際に操作される。この送りボタン７５と同様の役割を有するボタンとして、送りボタン７７が、表示部７１の下側に設けられている。また、戻りボタン７６と同様の役割を有するボタンとして、戻りボタン７８も、表示部７１の下側に設けられている。
このように、同様の役割を有するボタンを異なる部分に配置するのは、ユーザの使い勝手を考慮してのことである。ＵＳＢインタフェース７２、イーサネットインタフェース７３、および、ドライブ７４は、それぞれ、図４に示したように、ユーザ端末７の側面に、必ずしも設けられなくてはならないわけではなく、どのような位置に設けられても良い。しかしながら、送りボタン７５と戻りボタン７６は、ユーザがユーザ端末７を手で保持したときに、操作しやすい位置に設けられる方が好ましい。
ユーザ端末７の表示部７１の下側には、送りボタン７７と戻りボタン７８との間に、ジョグダイヤル（商標）が設けられており、送りボタン７７や戻りボタン７８と同様に、表示部７１に表示されているコンテンツをスクロールさせる際などに操作される。なお、ジョグダイヤル７９は、表示部７１に対して水平の方向（図中上下方向）に操作されるように構成されていると共に、垂直方向に押下されるようにも構成されているようにしても良く、その押下という処理により、決定などが指示されるように構成されていても良い。
ユーザ端末７は、さらに、拡大ボタン８０と決定ボタン８１を表示部７１の下側に備える。拡大ボタン８０は、表示部７１に表示されているコンテンツの文字の大きさなどを拡大したいときに操作される。決定ボタン８１は、何らかの選択、例えば、後述するスクラップする領域の選択などのときに、その選択で決定する際に操作される。
なお、図４に示したユーザ端末７の構成では、拡大ボタン８０のみが備えられているとして説明するが、縮小ボタンも備えられるようにしても良い。図４に示したように、拡大ボタン８０のみが備えられるような構成とされる場合には、例えば、所定の回数だけ、その拡大ボタン８０が操作されると、拡大処理ではなく、１００パーセントの表示戻るように設定される。
ユーザ端末７は、このような複数のボタンなどを備える構成とされているが、図４に示した構成は、一例であり、限定を示すものではない。すなわち、図４に示したボタン以外のボタンが設けられるようにしても良いし、逆に、必要がなければ（他のボタンと共用するなどして必要がなくなれば）削除された構成としても良い。また、そのボタンなどの配置も、図４に示した配置に限定されるものではなく、適宜変更可能である。
図５は、ユーザ端末７の内部構成例を示す図である。図５に示したユーザ端末７のＣＰＵ１０１は、ＲＯＭ１０２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ１０３には、ＣＰＵ１０１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース１０５は、入力部１０６が接続され、入力部１０６に入力された信号をＣＰＵ１０１に出力する。
入力部１０６は、送りボタン７５、戻りボタン７６、送りボタン７７、戻りボタン７８、ジョグダイヤル７９、拡大ボタン８０、および、決定ボタン８１から構成される。
入出力インタフェース１０５には、表示部７１も接続されている。さらに、入出力インタフェース１０５には、ハードディスクなどから構成される記憶部１０７、および、他の装置（例えば、データ作成装置２）とデータの授受を行う通信部１０８も接続されている。通信部１０８は、この場合、ＵＳＢインタフェース７２とイーサネットインタフェース７３から構成されている。
ドライブ７４は、パッケージメディア５としての記録媒体からデータを読み出したり、必要に応じデータを書き込んだりするときに用いられる。
データ作成装置２から提供され、通信部１０８により受信されたデータは、記憶部１０７に記憶され、その記憶されたデータに基づくテキストや画像が、表示部７１に表示される。または、ドライブ７４にセットされたパッケージメディア５に記録されているデータが読み出され、その読み出されたデータに基づくテキストや画像が、表示部７１に表示される。以下の説明においては、表示部７１に表示されるテキストや画像を、適宜、コンテンツと記述すると共に、そのコンテンツに係わるデータをコンテンツデータと記述する。
図６は、表示部７１に表示されるコンテンツの一例を示す図である。図６に示した例では、表示部７１内の上側の位置に、コンテンツのタイトルが表示されるタイトル表示ブロック１１１が表示されている。そのタイトル表示ブロック１１１の下側の、左側の位置には、画像が表示される画像表示ブロック１１２が表示されており、その右側の位置には、テキストが表示されるテキスト表示ブロック１１３−１が表示されている。
さらに表示部７１の下側の位置には、テキストを表示するテキスト表示ブロック１１３−２が表示されている。以下の説明においてはタイトル表示ブロック１１１、画像表示ブロック１１２、テキスト表示ブロック１１３−１，４３−２を、適宜、ブロックと総称する。
図６に示した表示部７１に表示されるコンテンツは、一例であり、限定を示すものではない。すなわち、レイアウトなどは、コンテンツにより変更されるし、説明の都合上、例えば、タイトルが表示されるタイトル表示ブロック１１１が表示されるとして示したが、タイトルがないコンテンツにおいては、タイトル表示ブロック１１１は表示されないし、タイトルが表示されるときであっても、その位置は、表示部７１の上側に限定されなくても良い。
さらに付言するに、これらの表示ブロック１１１乃至１１３は、予め表示部７１に設定されている領域ではなく、換言すれば、例えば、タイトル表示ブロック１１１というブロックが予め設定されているのではなく、説明のために付したものであり、上述したように、これらのブロックの表示される位置や内容は、記憶部１０７に記憶されているデータや、パッケージメディア５に記録されているデータなどに基づき決定されるものである。
従って、例えば、小説のようなコンテンツが表示される場合、表示部７１には、テキストしか表示されない。このような場合、テキスト表示ブロック１１３が表示部７１上に設けられ、その設けられた（領域として確保された）テキスト表示ブロック１１３内に、テキストが表示される。
ここで、コンテンツ（書籍）の種類について説明を加える。まず、漫画のような絵とテキストから構成され、かつ、その１コマ毎の配置（レイアウト）が作者の意図通りでなければならない（レイアウトを変更してしまうと、内容が変化してしまう）ような書籍がある。このような書籍は、拡大などがされたとしても、そのレイアウトが変更されることがないように設定されていなければならない。
本実施の形態においては、このような特徴を有する書籍（例えば、漫画のような書籍）は、画像（イメージ：IMAGE）として扱うとする。よって、漫画のような書籍は、画像表示ブロック１１２として取り扱われて表示部７１上に表示される。
小説のようなテキストのみから構成される書籍がある。テキストのみから構成されるため、そのテキスト（文字）の拡大や縮小が行われたとしても、その文字列の並びが変更されなければ（例えば、“あいう”という文字列が、“あいう”のままであれば、拡大や縮小が行われとしても）良い。
小説のようなテキストのみから構成される書籍は、本実施の形態においては、テキストデータとして扱うとする。よって、小説のような書籍は、テキスト表示ブロック１１３として取り扱われ、表示部７１上に表示される。
雑誌などのように、テキストと画像から構成される書籍もある。テキストは、小説のような場合と同様に、拡大や縮小が行われたとしても、その文字列の並びが変更されなければ良い。画像も同様に拡大や縮小が行われたとしても、その比率などが変化しなければ良い。
また、テキストと画像は、レイアウトが変更されないことが好ましいが、拡大や縮小などの処理が行われることにより、そのレイアウトが変更されたとしても、漫画のように、内容が変わってしまう可能性は低いため、そのレイアウトは変更することも可能である。しかしながら、例えば、所定のテキストの次に、そのテキストが示す内容に関連した画像が表示されるようにすることが好ましく、このような観点からは、レイアウトが変更されても、実質的にユーザが閲覧する順番としてのレイアウトは、変更されない方が好ましい。
このような異なる特徴を有するさまざまな書籍を取り扱うわけだが、本発明においては、コンテンツに対して拡大などの処理が行われたとしても、その拡大などの処理により、コンテンツの作成者が意図したレイアウトを崩されるようなことがないように処理されることが１つの特徴である。そのような特徴を有するコンテンツのコンテンツデータについて説明する。そのコンテンツデータは、データ作成装置２により作成される。
まず、出版社１から供給されたデータが、ＸＭＬコンバータ部２１によりコンバートされた後のデータ構造、換言すれば、データコンバータ部２２に供給されるＸＭＬ形式のデータのデータ構造について説明する。
最終的にユーザ側のユーザ端末６に配信されるコンテンツデータが作成されるには、ＸＭＬフォーマットによるソースデータがまず作成される。このソースデータは、図７に示すように、書誌情報部１３１、ストリームデータ部１３２、および、オブジェクトデータ部１３３から構成される。書誌情報部１３１には、コンテンツについての情報が記述される。
ストリームデータ部１３２には、コンテンツの主文の内容と流れを示すデータが記述される。コンテンツの主文の内容とは、例えば、小説の場合における本文であり、その本文のテキストデータと、その本文の流れ、すなわち、順序に関する情報が、ストリームデータ部１３２には記述される。
オブジェクトデータ部１３３には、画像や音声、その他の情報などが記述される。その他の情報とは、例えば、レイアウトに関する情報である。オブジェクトデータ部１３３には、ストリームデータ部１３２に記述されているデータに対して、付加価値的な情報が記述される。
このように、ストリームデータ部１３２とオブジェクトエータ部１３３を分離することにより、文字情報を主な情報源とする電子書籍用のコンテンツデータのコンバートが容易となり、また、表示する装置（ここでは、ユーザ端末７にコンテンツは表示されるとして説明しているが、ＰＣ６の表示装置としてのディスプレイ上や、ＰＤＡ（Personal Digital Assistant）などの装置）毎に変化するレイアウト情報などを、文字情報と独立して（別々に）編集できるため、編集がしやすくなる。このような場合、文字情報の方は共用できる。
なお、表示装置毎に変化するレイアウト情報とは、例えば、ＰＣ６のディスプレイ（不図示）と、ユーザ端末７の表示部７１の大きさは異なるため、１度に表示できるデータ量（結果として、文字数や画像のサイズなどに係わる）が異なるため、同一のデータにより表示が行われると、レイアウトが崩れてしまう可能性があり、適宜、コンテンツを表示させる装置により、レイアウト情報を変える必要がある。
本実施の形態においては、上述したように、ストリームデータ部１３２とオブジェクトデータ部１３３を分離しているため、また、以下に説明を加えるようなデータを有することにより、レイアウト情報の編集などの処理も簡便に行える。
書誌情報部１３１に記述されるデータについて説明を加える。図８は、書誌情報部１３１に記述されているデータが再生されることにより、ユーザ端末７の表示部７１に表示されるタイトル一覧の表示例を示す図である。図８に示した表示例では、「武田信玄 風の巻」、「武田信玄 林の巻」、「武田信玄 火の巻」、「武田信玄 山の巻」の順で表示されている。
この場合、“武田信玄”というシリーズの書籍で、１巻目が「風の巻」、２巻目が「林の巻」、３巻目が「火の巻」、４巻目が「山の巻」とされているタイトルが表示されている状態である。このような並びは、例えば、日本人であるならば、「風林火山」という言葉を思い出し、“風の巻”の次には、“林の巻”がくるのだなと理解できため、“１巻”、“２巻”などという表記でなくても、その前後関係を理解することができる。
しかしながら、ユーザ端末７でタイトルを、このような概念的な情報により並び替えて正確に表示させるには、そのような概念的な情報を予めユーザ端末７側に入力しておくなどの処理が必要であるが、全ての情報を予め用意し、入力しておくことは不可能である。
一般的には、このようなタイトルなどの並び替えは、例えば、５０音順に従って行われる。そのような５０音順に従った並び替えであれば、例えば、文字コードなどを利用することができるため、予め情報を用意し、入力するという処理を特に必要とはせず、ユーザ端末７が有する機能のみで、並び替えの機能を実現することが可能である。
しかしながら、図８に示したような“武田信玄”というシリーズの書籍のタイトルを並び変えるような場合、まず、“武田信玄”という部分は同一であるので、この部分だけでは、並び替えを行うことができない。そこで、次に、“風”、“林”、“火”、“山”の部分で並び替えが行われるわけだが、文字コードなどで並び替えが行われた場合、必ずしも、“風林火山”の順番になるとは限らない。
並び替えが正常に行われなければ、ユーザにとって、見づらいタイトルの並びとなってしまい、そのようなことが起こることは防がなければならない。そこで、本実施の形態においては、「reading」という属性を設け、常に、ユーザに対しては、正しい並び替えによる結果のみが提供されるようにする。この「reading」という属性は、ソートの対象となるものに付けられる。図８に示したような表示になるように、「reading」という属性が付けられたデータの一例を以下に示す。
<Title reading＝“タケダシンゲン １”> 武田信玄 風の巻 </Title>
<Title reading＝“タケダシンゲン ２”> 武田信玄 林の巻 </Title>
<Title reading＝“タケダシンゲン ３”> 武田信玄 火の巻 </Title>
<Title reading＝“タケダシンゲン ４”> 武田信玄 山の巻 </Title>
例えば、<Title reading＝“タケダシンゲン １”>という属性が付けられたタイトルは、「武田信玄 風の巻」であることを示している。また、“タケダシンゲン”という読みが与えられている書籍の中では、並び替えが行われときに、“１”番目に表記されるタイトルであることが示されている。<Title reading＝“タケダシンゲン １”>の中で、“タケダシンゲン”という読みの情報が含まれるのは、他の書籍（他のタイトル）との並び替えが行われるときの情報として用いられるからである。
<Title reading＝“タケダシンゲン １”>は、ユーザ端末７側でコンテンツデータを識別するための、また、コンテンツデータの、所定の規則に従った並び替えを行うときの情報として用いられる。その後に続く“武田信玄 風の巻”という情報は、ユーザ側が、コンテンツデータを識別するために用いられる（提供される）情報である。このように、「reading」という属性のデータは、ユーザ端末７側で用いられる情報と、ユーザ側に実施に提供される情報から構成される。
また、この「reading」という属性に関するデータは、出版社１側から提供されるデータに含まれていても良いし（出版社１またはコンテンツを作成した作成者などが付加するようにしても良いし）、データ作成装置２側で、付加するようにしても良い。
このような「reading」という属性が付けられたデータを含む、書誌情報部１３１に記述されるデータの一例を、図９に示す。なお、図９には、データを線で囲み、その線の外側に、数字を付したが、その線と数字は、説明のために付したものであり、データ自体に付されているものではない。以下の説明においても、同様の記述（図示）は、同様の意味を有するとする。
１行目の<?xml version>や２行目の<Info version>には、該当するフォーマットのバージョンが記述される。３行目の<BookInfo>は、以下の部分に書誌情報が記述されていることを示す。４行目の<Title reading>には、コンテンツのタイトルが記述される。５行目の<Author reading>には、コンテンツの著者名が記述される。
６行目の<BookID>には、該当するコンテンツを唯一識別できる情報が記述され、その情報により、コンテンツが特定されるようにする。７行目の<Publisher reading >には、コンテンツを出版する出版社名（出版社１の社名）が記述される。８行目の<Label reading >には、コンテンツを出版する出版社が設けた発行商標が記述される。
この１乃至８行目に記載されるデータのうち、４行目の<Title reading>に記述されるタイトル、５行目の<Author reading>に記述される著者名、７行目の<Publisher reading >に記述される出版社名、および、８行目の<Label reading >に記述されるレーベル名の、これら４つの要素は、文字の表現が重視されるため、意味をもたせるためのreading属性を記述できるようにされている。
これら４つの要素にreading属性を持たせることにより、ユーザは、タイトル、著者名、出版社名、および、レーベル名のいずれか（または、複数）により並び替えを行うことができる。このように、複数の情報により並び替えが行えるように設定しておくことにより、ユーザが、所望の書籍を検索する際など、容易にその所望の書籍を検索することができるようになる。
また、「reading」という概念を用いることにより、並び替えの段階であっても、その「reading」の部分に記述される表示順序を示す数字を、コンテンツの作成者の意図により割り当てることが可能となるため、その作成者の意図を、並び替えという段階においても反映させることができるようになる。
９行目の<Category>には、該当するコンテンツが、どういったジャンルのものかが記述され、ユーザが、電子書籍を整理しやすいようにするための情報として用いられる。１０行目の<Classification>には、どのようなデータが、コンテンツに含まれているのかが記述される。
例えば、紙書籍の場合、雑誌などに付録などが添付されているときがある。そのようなとき、紙書籍であれば、その雑誌の形（膨らみなど）から、付録が添付されていることをユーザが推測することができる。しかしながら、電子書籍のような電子情報の場合、そのような雑誌などの外観から推測できることと同様な推測を行わすための表現ができない。そこで、この<Classification>において、ユーザに、付録が付いていることを明示するための情報を記述することにより、その電子書籍にはどのようなデータが含まれているのかを認識させるための情報が設定されるようにする。
１１行目の<FreeText>には、コンテンツのあらすじなどが記述される。その記述された情報は、そのコンテンツが、どのような内容なのかを、ユーザに認識（理解）させるような情報として用いられる。１６行目の<DocInfo>は、ドキュメントの情報が以下に記述されていることを示す。１７行目の<Language>には、コンテンツの主言語が、例えば、ISO639で規定された言語コードで記述される。
１８行目の<Creator>には、コンテンツの作成者名、作成スタジオ名などが記述される。１９行目の<CreationDate>には、コンテンツが作成された日時が記述される。２０行目の<Producer>には、制作者、生産者などが記述される。２１行目の<Page>には、コンテンツを表示するのに必要な見かけ上のページ数が記述される。
ページについての概念は、通常の紙書籍とは異なり電子書籍の場合、明確に規定することができない。例えば、本実施の形態においては、上述したように、表示部７１に表示される文字などは、ユーザの所望の大きさに拡大できるように構成されている。
仮に所定の倍率で、ユーザ端末７の表示部７１に１度に表示されるコンテンツを１ページであると設定した場合、そのページに対して拡大の指示が出され、その指示が出された結果、拡大されると、１ページでは表示されきれずに、例えば、２ページにわたって表示されることになるときもある。従って、拡大率などに依存し、表示される状況により、同一のコンテンツであっても、ページ数は変化するし、ページという概念の規定の仕方により、ページ数も変化するために、２１行目の<Page>には、見かけ上のページ数が記述されるようにしている。
２３行目の<Keyword>には、コンテンツをユーザが検索する際に用いられる言葉が記述される。
書誌情報部１３１には、このようなデータがコンテンツ毎に書き込まれている。なお、図９に示したデータは、一例であり、必要に応じ、他のデータが（他のデータも）記述されるようにすることも可能である。また、逆に、必要がなければ、削除する（省略する）ことも可能である。このことは、以下の説明（他のデータ構造）においても、同様である。
次に、ストリームデータ部１３２に記述されるデータについて説明する。ストリームデータ部１３２には、電子書籍としてのコンテンツの主となる内容が、データの表示順に記述される。通常、ページ送り機能によって表示される内容は、このストリームデータ部１３２に記述される。
上述したように、紙書籍では、大きく分けて３種類のページの表現方法がある。漫画のようにページをイメージデータとして取得し、それを貼り付けるもの、雑誌のように、文字のかたまりを適当な位置に配置することによって、ページを表現するもの、小説のように、文字の流れを中心にレイアウトが組まれるものの３種類である。
これらの異なる表現であっても、同じフォーマットを利用するため（同じフォーマットを利用できるようにするため）、本実施の形態においては、仮想ページ（仮想描画領域）という概念を導入する。仮想ページとは、その仮想ページ内の領域に記述された内容を１ページとして扱うが、実際に表示部７１に表示させる際には、そのページ内で、表示可能な領域だけを表示するというものである。図１０を参照して、仮想ページについて説明を加える。
表示部７１に一度に表示できる領域を表示可能領域１５１としたとき、必ずしも、１ページとして扱うべき領域（仮想ページ）が、表示可能領域上に１ページとして表示される（すなわち、一度に表示される）わけではない。図１０中の上側の図は、表示可能領域１５１と、仮想描画領域１５２−１が、同一の領域である状態を示している。なお、図１０中の上側の図においては、説明のため、仮想描画領域１５２―１よりも小さい枠として表示可能領域１５１を示しているが、同一の大きさに規定されている。
図１０中の下側の図に示した仮想描画領域１５２−１は、図１０中の上側の図に示した仮想描画領域１５２−１の２倍の大きさとされている。本実施の形態におけるユーザ端末７においては、表示部７１に表示されている文字などが小さい場合、ユーザにより所望の大きさに拡大できるように構成されている。そのため、ユーザの指示により、表示部７１に表示さている文字の拡大が２倍と指示される場合があり、そのようなときには、図１０中の上側の図に示した状況から図１０中の下側の図に示した状況に変化する。
すなわち、図１０中の上側の図に示した状態では、“ＡＢＣＤＥ”というアルファベットが、仮想描画領域１５２−１に描画されている状態（１ページ分の文字として“ＡＢＣＤＥ”というアルファベットが描画される状態）と、実際に表示部７１に表示される表示可能領域１５１が一致しているため、表示部７１には、“ＡＢＣＤＥ”という文字列が表示される。
この状態から、２倍の表示が指示されると、仮想描画領域１５２−２は、この場合、横方向が２倍の大きさに拡大される。“ＡＢＣＤＥ”という文字列も、仮想描画領域１５２−２内で、２倍の大きさに拡大される。しかしながら、表示可能領域１５１は、表示部７１の大きさと等しいという制限があるため、変化することなく、固定的な大きさである。従って、図１０中の上側の図の状態では、“ＡＢＣＤＥ”という文字列全てが表示部７１に表示される状態であっても、図１０中の下側の図の状態では、“ＡＢ”と“Ｃ”の半分程度しか、表示部７１には表示されない状態となる。
図１０中の上側の図から図１０中の下側の図の状態に変化したことにより、１ページで表示されているものが、２ページにわたって表示されることになる。このように、本実施の形態における電子書籍のデータ、および、そのデータを扱うユーザ端末７は、拡大という処理が行えるように構成されているために、普遍的なページという概念を用いることができない。換言すれば、紙書籍で１００ページの書籍が、電子書籍でも１００ページと設定されていても、拡大の処理が指示されれば、そのページ数は増加することになり、必ずしも１００ページとして処理することはできない。
よって、本実施の形態においては、仮想ページという概念を導入する。この仮想ページは、拡大などの処理が指示されたとして場合であっても、１ページと設定されているページは１ページとして扱うためのものである。そして、そのページが仮想的に展開される領域が仮想描画領域１５２である。仮想描画領域１５２に描画されている仮想ページのうち、実際に表示部７１に表示される領域が、表示可能領域１５１である。
なお、表示可能領域１５１、仮想描画領域１５２などについて、また、拡大が指示されたときの拡大方法（後述するBlockstyleまたはブロックルール）については、本出願人が、先に出願した特願２００２−２８０２５７号に開示している方法を適用することが可能である。
このような仮想ページ（仮想描画領域）などの概念を用いて、以下に説明を加える。
ストリームデータ部１３２に記述されるデータについての説明に戻り、漫画のように、画像やテキストを表示する位置が厳密に定められているものは、イメージデータとして、ストリームデータ部１３２に記述される。上述したように、漫画のような書籍は、レイアウトが変更されると、その内容まで変更されてしまう可能性があり、たとえ、拡大などが指示されたとしても、そのレイアウトが変更されてしまうような拡大などは行われるようなことがないように設定されていなければならない。
そこで、ここでは、漫画など、レイアウトの変更が許可されないような書籍は、イメージデータとして扱うようにする。図１１に示したように、紙書籍で１ページにあたる部分は、電子書籍でも１ページとして扱われるように設定される。すなわち、１ページの仮想描画領域１５２は、表示可能領域１５１と、実質的に同じ大きさとされる。
図１１に示すように、漫画などでは、複数のコマ（枠）から１ページが構成される。その複数のコマから構成される１ページが１ページとして表示されるように制御がされる。このようなページに対して拡大が指示された場合、拡大の指示があっても、拡大処理が行われないか、または、縦と横が同じ比率で拡大されるかのいずれかである。どちらにしても、レイアウトの変更などはされないため書籍の作成者の意図が、崩れてしまうようなことはない。
図１１に示したような場合、画面サイズ（表示可能領域１５１）とイメージサイズ（仮想描画領域１５２）を同じ大きさであると設定し、ページ記述部（図１２に示すデータ）に、それ以外の記述をしなければ、実際に表示される「ページ」と仮想ページの大きさが等しくなる。
図１１に示したようなページのデータ（イメージデータ）は、図１２に示したような構成とされる。図１２に示したデータ構成例は、<Page>タグが利用された、１仮想ページの記述内容を示している。１行目の<Page>タグに続く“objid”は、そのページ（イメージデータ）を識別するための情報で、そのページを特定したい場合に用いられる情報である。
また、“pagestyle”は、ページのレイアウト情報を記述するオブジェクトを呼び出す部分（オブジェクトデータ部１３３（図７）に記述されているデータを読み出すための情報が記述される部分）で、このコマンドによってページのマージンなどに関するデータが読み出され、決定される。
２行目の<ImageBlock>タグには、描画するイメージ（画像）についての設定を行うための情報が記述される。<ImageBlock>タグ内の“objid”は、そのImageBlockを識別するための情報が記述される。なお、このタグにより、イメージブロックとして扱うことが宣言されている。
その後に続く“x0,y0,x1,y1”の情報で、描画される画像が、元画像のどの位置に存在するものなのかを示し、切り取った画像をxsize, ysizeで指定した大きさで表示する。
図１２に示したデータ例では、横600ドット、縦800ドットのサイズで画像を表示することが示されている。その画像が表示される画面サイズが横600ドット、縦800ドットの場合、画面全体に画像が表示されることになる。他の例を挙げれば、画像サイズが、横1000ドット、縦1200ドットであり、画面サイズが横600ドット、縦800ドットの場合、画像全体のうちの一部分である、600×800ドットの部分の画像が、実際に表示され、ユーザに提供されることになる。
“refobj”では、実際に描画される画像の元データ（画像が表示部７１に表示される際に処理される画像データ）の情報が、記述された部分を参照しており、図１２に示した例では、“objid”が“201”のもの（データ）を描画することを意味する。この参照先のデータは、オブジェクトデータ部１３３に記述されている。
また、“blockstyle”では、描画される画像が格納されるブロックの情報を参照している。この“blockstyle”の実データは、オブジェクトデータ部１３３に記述されている。図６を参照して説明したように、イメージ（画像）やテキストなどは、全てこのブロックの中に描画され、ページレイアウトは、ブロックの中に表示される内容に依存せず、このブロックに対して行われることになる。
ブロック情報には、ブロックの大きさや枠を付ける、または付けないなどの情報が記述される。画像を表示する際は、ブロックの大きさと画像の表示サイズが同じになるように記述される。
次に、主にテキストから構成されるテキストデータについて説明する。図１３に、ストリームデータ部１３２に記述されるテキストに関するデータの構成例を示す。小説のように、文字の流れから（内容から）ページの順番が決められるようなコンテンツは、図１３に示すように、<Page>タグで区切られる領域に、章のような大きな単位の文章の集まりが記述される。
図１３に示した例では、<Page>タグで区切られる領域に<TextBlock>タグで示されるテキスト情報が記述されている。１行目に記述されている“Page objid”や、“Pagestyle”については、上述したイメージブロックの場合と同様である。<TextBlock>タグ内の“textstyle”で、描画するテキストについての情報を記述しているオブジェクトが呼び出される。このオブジェクトでは、縦書きや横書きの設定、文字の大きさなどが指定される。
テキストブロックのデータは、図１３に示したように、テキストデータが、実データとして直接記述されている。換言すれば、図１２を参照して説明したイメージブロックのデータでは、実データは、オブジェクトデータ部１３３に記述されており、その参照先の情報が、ストリームデータ部１３２に記述されているが、テキストブロックのデータの場合は、参照先の情報ではなく、実データそのものがストリームデータ部１３２に記述される。
ここで、このように設定する利点について説明する。ここでは、電子書籍として、特許明細書の場合を例に挙げて説明する。特許明細書には、必要に応じ図面が添付される。明細書は、テキストデータとして扱われるようにし、図面はイメージデータとして扱われるようにする。明細書中において、図面によっては、何度も参照される図面がある。それに対して、明細書の文章（テキスト）中の同じ文章が何度も参照されることはなく、たとえ、同じ文章が存在しているとしても、それは、内容的な流れに沿っているものであり、前の文章を参照しているわけではない。
このようなことを換言すれば、図などのイメージデータは、何度も利用されることがあるが、文章のテキストデータは、１度だけ利用される。よって、テキストデータの実データは、ストリームデータ部１３２のデータとして記述される。そして、イメージデータの実データは、オブジェクトデータ部１３３に記述されることにより、異なる場面で、何度、参照されても良いように設定される。
図１４は、図１３に示したデータが処理されることにより表示部７１に表示されるテキストについて説明するための図である。図１４に示したように、図１３に示したデータに基づくテキストを、仮想描画領域１５２に展開した場合、その仮想描画領域１５２は、表示可能領域１５１の４倍の大きさに相当する。すなわち、ユーザ側には、所定の倍率のときに４ページと見なされるページ数として提供される。もちろん、拡大などの処理が指示された場合、その指示に基づいて、ページ数は変化する。
次に、雑誌のような画像やテキストが混じった書籍のデータについて説明する。図１５は、ストリームデータ部１３２に記述されるデータの一例を示す図である。雑誌のように、文のかたまりや、画像を意図した位置に配置することによってページが作り上げられるコンテンツは、<Page>タグで区切られた領域に、複数のブロックオブジェクトが描画され、それらの距離が<BlockSpace>タグ（例えば、図１５において２行目に記載されている情報）で指定されることによって実現される。
図１５に示したデータのうち、１行目に記述されている情報については、上述した場合と同様である。２行目や８行目の<BlockSpace>の情報は、前のBlock（ブロック）と後のBlockとの相対距離を指定するための情報である。
このように、ブロック間で、相対的に位置が決定されるようにすることにより、所定のブロックに対して拡大などの処理が指示され、そのブロックを含むページ全体のレイアウトが崩れてしまうようなことが発生しても、ブロックの前後関係は、必ず保つことができる。ブロックの前後関係を保つことができることにより、コンテンツを作成した作成者が意図した順番で、ユーザに閲覧させることは、常に可能となる。よって、再レイアウトして綺麗な表示をすることができる。
図１６は、図１５に示したデータが処理されることにより表示部７１に表示される画像やテキストについて説明するための図である。図１６においては、図中左右方向をＸ軸、図中上下方向をＹ軸としたが、この軸の設定自体も、後述するオブジェクトデータ部１３３のデータの一部として記述されており、その記述に従って、設定されるため、必ずしも、図１６に図示したように設定されるものではない。
テキスト表示ブロック１１３は、図１５に示した３乃至７行目のデータにより作成される。その位置は、２行目の<BlockSpace>の情報により決定される。その決定された位置に、テキストデータとしての“今日の天気”という文字列が表示される。
そのテキスト表示ブロック１１３の下側に、画像表示ブロック１１２が表示されるが、その表示位置は、テキスト表示ブロック１１３からの相対位置であり、８行目の<BlockSpace>の情報に基づいた位置である。すなわち、８行目には、<BlockSpace x=”20”>との記述があるが、テキスト表示ブロック１１３からＸ方向に２０だけ（２０ドット、２０ミリなど予め規定されている単位分）移動した位置に、画像表示ブロック１１２が表示される。
その画像表示ブロック１１２に表示される画像の実データは、９行目の＜ImageBlock objid=”122”＞という情報に基づいて取得されるわけだが、この場合、objidとして１２２が与えられ、オブジェクトデータ部１３３に記述されているデータである。
また、その画像の大きさ（画像表示ブロック１１２のサイズ）は、９，１０行目の< x0=”0” y0=”0” x1=”300” y1=”100” xsize=”300” ysize=”100>により規定される。このうち、前半部分の<x0=”0” y0=”0” x1=”300” y1=”100”>の情報は、画像のうちのどの部分を取得するかを指示する情報であり、後半部分の<xsize=”300” ysize=”100>の情報は、倍率を示す。この場合、座標で示すと、（０、０）から（３００、１００）の領域を表示することが示され、その領域を３００×１００で表示する、すなわち、１倍で表示することが示されている。
図１５に示したデータ構造では、２つのブロックが、図１６に示したように１ページに表示される例を示しているが、複数のブロックで１ページが構成されることもあり（例えば、図６に示したような場合）、そのような場合には複数のブロックの情報が、図１５に示したような形式で、ブロック毎に記述される。
このように、本実施の形態においては、ブロック単位で処理が行われ、各ブロックの表示位置は、前のブロックからの相対位置で規定されている。このように、前のブロックからの相対位置で表示位置が決定されるということは、各ブロック間で、その表示順序が決定されるということである。すなわち、前のブロックが表示された後でないと、そのブロックの表示位置から相対的に表示位置が求められる後のブロックが表示されないため、結果として表示の順序を規定していることにもなる。
表示の順序が規定されるということは、ユーザにコンテンツが提供される際、ユーザがコンテンツを読む順序も規定される（通常、上から下、左から右に読むということを前提としている）ことになる。これにより、拡大などの処理が行われることにより、レイアウトが変更されてしまったような場合においても、表示される順序には変化がないため、結果として、ユーザがコンテンツを読む順序には変更がないということになる。
このようなデータがストリームデータ部１３２には記述される。さらに電子書籍では、紙媒体とは異なるため、以下のようなことが可能であり、そのようなことを実現するためのデータもストリームデータ部１３２には記述される。まず、紙媒体とは異なるために可能となることについて、図１７を参照して説明する。
紙書籍では、全てのページが連続して存在する。換言すれば、紙書籍では、ページ毎に順次、連続的な数が割り振られている。ここで、紙書籍における雑誌とその雑誌に添付されている付録のような関係について考える。まず、雑誌の方に注目すると、その雑誌自体には、その雑誌のページ毎に順次、連続的な数が割り振られている。また、付録の方に注目すると、その付録自体にも、その付録のページ毎に順次、連続的な数が割り振られている。
すなわち、雑誌の方も、付録の方も、それぞれ独自に連続的なページ番号が割り振られている。図１７においては、雑誌にたとえたページ群を連続ページ群１７１とし、付録にたとえたページ群を独立ページ群１７２−１，１７２−２としている。紙書籍の場合、雑誌から付録へとページを変えるとき、雑誌をわきに置いて付録を持ち、その付録の所望のページを、ページをめくりつつ探すといった処理を行わなくてはならないが、電子書籍では、ページジャンプという機能によって、連続ページ群１７１から独立ページ群１７２内の所望のページに移動するといったことを、ユーザは、容易に行える。
ここでは、独立ページ群１７２は、連続ページ群１７１からジャンプ機能により閲覧可能なページ群であるとする。また、独立ページ群１７２にページがジャンプした後、元の連続ページ群１７１の所定のページに戻ることは可能であるように構成されている。また、独立ページ群１７２―１から独立ページ群１７２−２（その逆も可）にジャンプすることも可能であるように構成されている。
しかしながら、独立ページ群１７２の所定のページのみを、連続ページ群１７１からジャンプすることなしに閲覧することは不可能とされている。すなわち、独立ページ群１７２のみを始めから再生させるコンテンツとして指定することはできないように構成されている。これは、連続ページ群１７１と独立ページ群１７２との間には、主従関係が設定されているからである。
独立ページ群１７２は、独立ページ群１７２だけで識別されるものではなく、連続ページ群１７１と共に識別されるものとされている。独立ページ群１７２は、連続ページ群１７１の付加的な情報を提供するものとされている。そのために、連続ページ群１７１と切り離して独立ページ群１７２を存在させても、その独立ページ群１７２は、意味のないページの集まりと解される可能性がある。
独立ページ群１７２の各ページ（各ブロック）に記載されていることは、内容的には関連性がなく、各ページが独立的に存在していても良い。換言すれば、ページ（内容）が入れ替えられても全体としての内容的な入れ替えはなく、問題はない。すなわち、独立ページ群１７２に記載されている記事は、それぞれ独立した記事であり、それぞれの記事に、必ずしも関連性や順番付けがあるものではない。
他の具体例を挙げるなら、連続ページ群１７１は、例えば小説そのものを内容とし、独立ページ群１７２は、その小説に登場する登場人物の説明や、背景などの説明などを内容とする。よって、独立ページ群１７２に記載されている、登場人物の説明は、それぞれの登場人物毎に異なるものであり、それぞれの登場人物毎に独立して存在していても（特定の登場人物の説明だけをユーザに提供しても）、内容的には問題がない。
連続ページ群１７１内に、所定の登場人物が登場すると、例えば、その登場人物の名前がクリックできるように構成されており、その名前がクリックされると、独立ページ群１７２の、その登場人物の説明が記述されている部分に表示が切り換えられる。
ユーザは、その独立ページ群１７２に記載されている内容を閲覧し続けることができる。その登場人物以外の説明なども続けて閲覧できるようにされている。またユーザは、そのような独立ページ群１７２の所定の内容から、元の連続ページ群１７１の所定のページに戻ることができる。
また、例えば、登場人物の説明だけをまとめた独立ページ群１７２−１と、背景の説明だけをまとめた独立ページ群１７２−２といった、２つの独立ページ群１７２が、１つの連続ページ群１７１に対して存在していても良い。そのような場合、独立ページ群１７２−１から独立ページ群１７２−２に移動することは可能とされている。また、その逆の独立ページ群１７２−２から独立ページ群１７２−１に移動することも可能とされている。
しかしながら、ユーザは、直接、独立ページ群１７２だけを閲覧することはできないように構成されている。ユーザは、連続ページ群１７１を閲覧している状態からでないと、独立ページ群１７２の内容を閲覧できないようにされている。さらに換言するならば、連続ページ群１７１のコンテンツデータからのみ独立ページ群１７２のコンテンツデータは、閲覧可能であるというように設定されている。
このような関係を有している場合、独立ページ群１７２のコンテンツデータのコンテンツは、連続ページ群１７１のコンテンツデータのコンテンツに対して、付加的な情報を提供する内容であると言える。
このような連続ページ群１７１のコンテンツデータと独立ページ群１７２のコンテンツデータは、主従関係が存在しているため、共に配信されるようにした方が良く、独立ページ群１７２のコンテンツデータのみが配信されるということはないようにされている方が好ましい。また、このような連続ページ群１７１のコンテンツデータと独立ページ群１７２のコンテンツデータは、出版社１側で作成し、データ作成装置２に提供するようにしても良いし、データ作成装置２側で、出版社１側から供給されたデータを基に作成するようにしても良い。
このような独立ページ群１７２は、主たる内容を表示する連続ページ群１７１と分けて記述することにより、ページ内部の記述を特殊にすることなく実現することができる。そのデータ構造例を図１８に示す。
１乃至８行目が連続ページ群１７１のデータであり、９乃至２６行目が、独立ページ群１７２のデータである。１乃至８行目には連続ページ群１７１のデータが記述されているわけだが、そのデータは、連続ページ群１７１を構成するページを識別する識別子<Page objid>が列記されている。<Page objid>がわかれば、ページを決定することができるため、連続ページ群１７１のデータとしては、この識別子だけが列記されていればよい。
１０乃至２６行目には、独立ページ群１７２のデータが記述されているわけだが、そのデータは、まず、<Pages objid>という情報が記述されるが、その<Pages objid>は、独立ページ群１７２を識別する識別子である。図１７と対応付けると、独立ページ群１７２−１が、１０行目の<Pages objid=”1001”>であり、独立ページ群１７２−２が、１８行目の<Pages objid=”1002”>である。
１１乃至１７行目で、独立ページ群１７２−１を構成する各ページの識別子の情報が記述されている。図１８を参照するに、独立ページ群１７２−１（識別子としてのPages objidが”1001”であるページ群）は、<Page objid>が、”201”、”202”、および、”203”から構成されていることが示されている。このように、連続ページ群１７１と独立ページ群１７２を、それぞれ構成するページの情報が、ストリームデータ部１３２に記述される。
例えば、ユーザが、ユーザ端末７で、連続ページ群１７１の所定のページを閲覧しているときに、独立ページ群１７２の所定のページを閲覧したくなった場合、所定のボタンを操作するだけで、その所望のページを閲覧することができる。そして、その後、ユーザは、その独立ページ群１７２のページの閲覧を継続することも可能であるし、所定の操作を行うことで、ジャンプする前の元の連続ページ群１７１のページに戻ることも可能とされている。
このようなデータも、ストリームデータ部１３２には記述される。
次に、オブジェクトデータ部１３３（図７）に記述されるデータについて説明する。オブジェクトデータ部１３３には、ストリームデータ部１３２に記述されているデータが参照するデータが記述される。そのデータとしては、電子書籍としてのコンテンツを装飾するためのスタイル情報がまずある。そして、イメージデータや音声データなどの実データがあり、それらのデータは、ストリームデータ部１３２には、直接的に記述されない内容のものである。
また、オブジェクトデータ部１３３には、ウィンドウ情報や、ボタン情報など、電子書籍ならではの表現についてのデータも記述される。ウィンドウ情報は、例えば、表示部７１に表示されている文章中の難しい単語などの意味を、ウィンドウ（窓）として、その文章上に表示する際などに用いられる情報である。ボタン情報は、例えば、表示部７１上にボタンを表示させ、そのボタンに対してクリックなどの所定の操作が行われたときに、所定の情報を表示する際などに用いられる情報である。
表示部７１に表示されるボタンの例としては、後述するスクラップブック内で、スクラップされた記事が、画像として設定され、保存されたときに、その画像を表示させるためのボタンがある。
オブジェクトデータ部１３３に記述されるデータは、電子書籍としてのコンテンツを装飾するための情報が記述されるわけだが、そのデータの種類としては、例えば、PageStyle, BlockStyle, TextStyleなどの情報がある。これらの情報（データ）は、それぞれが識別子として持つ“stylelabel”によって呼び出されるため、同じ“stylelabel”を呼び出されているオブジェクトは、スタイル情報が変わることによって一括して変更される。
図１２に示したイメージブロックのデータの１行目や、図１３に示したテキストブロックのデータの１行目などには、そのブロックの識別子である“Page objid”とともに、そのブロックをどのように表示部７１に表示させるかを規定するための“Pagestyle”が記述されている。この“Pagestyle”の部分で記述される情報で参照されるデータが、オブジェクトデータ部１３３に記述されている。
その“Pagestyle”で参照される情報（スタイル情報）について、まず説明する。図１９は、オブジェクトデータ部１３３に記述されるスタイル情報のデータ構造例を示す図である。PageStyleは、PageStyleタグによって記述される。
１行目の“objid”属性で、“PageStyle”を識別するための情報が記述され、同じく“stylelabel”にユーザが自由に名前を変えられるラベルが記述できるようにされている。このようなユーザ、この場合、主に編集者になるが、その編集者が、オブジェクトに名前を任意に付けられるようにしておくことで、例えば、編集中の電子書籍に、このスタイルのオブジェクトを用いることはもちろんだが、後の時点で、他の電子書籍に、このスタイルのオブジェクトを適用する際、このスタイルのオブジェクトを自分が付けた名前（ラベル）で識別できるので、容易に、所望のオブジェクトを探し出すことが可能となる。
図１９に示した“stylelabel”は、“Honbun”となっているが、図１２または図１３を参照するに、図１２や図１３に示したデータの１行目の“Pagestyle”には、“Honbun”と記述されている。
よって、この場合、例えば、図１２に示したイメージブロックが描画される際、“Pagestyle”として、図１９のデータが、オブジェクトデータ部１３３から読み出される（参照される）ことになる。また、図１３に示したテキストブロックが描画される際も、図１９のデータが参照される。このように、１つの“Pagestyle”のデータは、複数のデータから参照されることがある。
このように、複数のデータから参照されるデータが共用されるようにすることで、電子書籍の全体のコンテンツデータ自体の容量を小さくすることができる。また、このようにすることで、図１９に示したような“Pagestyle”の情報を書き換えるだけで、複数のブロックに係わる表示を、一括して書き換えることができることになる。このことは、編集などの処理が容易に行えることを意味している。
図１９に示した“Pagestyle”のデータ構造について説明を続けるに、２乃至５行目の“evenfooterid”、“evenheaderid”、“oddfooterid”、“oddheaderid”では、見開き表示を考慮し、偶数ページ、奇数ページで利用されるヘッダーおよびフッターのオブジェクトのobjidが記述される。なお、図１９の説明におけるページとは、表示可能領域１５１（図１０）のことであり、表示部７１のサイズを１ページとした場合のことである。
ここで、見開き表示とは、図４に示したようなユーザ端末７のように１面だけの表示部７１を有するのではなく、２面の表示部７１を有するような装置における表示や、擬似的に２面構成で表示されるときの表示である。
６行目の“pageposition”では、見開き表示時に、そのページがどちら側に表示されるか（どの位置に表示されるのか）を指示するための情報が記述される。この指示によって、文字の拡大が指示され、結果として、拡大されていない状態でのレイアウトが崩れたときでも、意図したページデザインを保つことが可能となる。
７行目の“setemptyview”では、文字の拡大などの処理により所定のページの後に表示すべきページとの間に、空白のページの描画が必要となったとき、その空白のページにヘッダーやフッターを描画するかしないかを指示するための情報が記述される。例えば、showを指定された場合、ヘッダーやフッターが描画され、emptyが指定された場合、ヘッダーやフッターがない完全に空白なページが表示される。
８乃至１６行目の各行における、“topmargin”、“headheight”、“headsep”、“oddsidemargin”、“evensidemargin”、“textheight”、“textwidth”、“footspace”、“footheight”の各情報に従って、ページ内のレイアウト（マージンなどの余白など）が決定される。また、１７行目の“layout”の指定によって、ページ内の座標系を縦書き用の座標系にするか、横書き用の座標系にするかが指定される。
次に、図２０を参照して、オブジェクトデータ部１３３に記述されるデータのうち、Textstyleに関するデータについて説明する。図２０に示したTextstyleのデータは、例えば、図１３に示したデータ内の２行目の記述に基づいて読み出される（参照される）データである。図１３に示したデータ内の２行目には、<Textstyle=”tategaki”>との記述があるが、この”tategaki”というラベルにより識別されるデータが、オブジェクトデータ部１３３から読み出され、この場合、その読み出されるデータが、図２０に示したようなデータである。
“TextStyle”は、TextStyleタグによって記述される。１行目の“objid”属性に“TextStyle”を識別するための情報が記述され、同じく“stylelabel”にユーザが自由に名前を変えられるラベルが記述できるようにされている。２行目の“fontsize”で、描画される文字の大きさを指定するための情報が記述される。
３行目と４行目の“fontescapement”と“fontorientation”には、描画される文字を、どのように回転させ、どの向きに進ませるかを指定するための情報が記述される。これらの情報は、テキストにおいて、そのテキストが、縦書きであるか横書きであるかに依存する情報である。５行目の“fontfacename”には、描画される文字のフォントフェイス名の情報が記述される。例えば、図２０に示した例では、フォントフェイス名として“明朝”が指示されている。
６行目の“textcolor”には、描画される文字の色を指定するための情報が記述される。この情報により、ユーザは、好みの色で文字を描画させるようにすることができる。７乃至９行目の“wordspace”、“letterspace”、“charspace”には、それぞれ英単語間の空間距離、英字（アルファベット）間の空間距離、和文字間の空間距離を指定するための情報が記述される。
１０行目の“baselineskip”には、行間隔を指定するための情報が記述され、１１行目の“linespace”には、最低限保証すべき行と行の空間を指定するための情報が記述される。この“linespace”の情報により、レイアウトが崩れても最低限保証される隙間が明示されているため、綺麗に再描画することが可能となる。
次に、図２１を参照して、オブジェクトデータ部１３３に記述されるデータのうち、BlockStyleに関するデータについて説明する。図２１に示したBlockStyleのデータは、例えば、図１３に示したデータの内の２行目に記述に基づいて読み出される（参照される）データである。図１３に示したデータの内の２行目には、<Blockstyle=”textblock”>との記述があるが、この”textblock”というラベルにより識別されるデータが、オブジェクトデータ部１３３から読み出され、この場合、その読み出されるデータが、図２１に示したようなデータである。
“BlockStyle”は、“BlockStyle”タグによって記述される。１行目の“objid”属性で、“BlockStyle”を識別するための情報が記述され、同じく“stylelabel”にユーザが自由に名前を変えられるラベルが記述できるようにされている。２行目の“blockheight”には、描画用に確保するブロックの高さを指定するための情報が記述される。
ここで、図２１に示したデータ内には、“blockheight”によりブロックの高さは指定されているが、ブロックの横幅は、指定されていない。描画されるブロックの横幅は、“blockwidth”により指定される。図２１に示したデータは、ブロック内部に縦書きのテキストが記述される場合（図１３に示したテキストブロックにより読み出されるデータである場合）であり、そのようなときには、その文字数やその文字の大きさによって横幅が変化するため、ブロックの横幅を“blockwidth”で指定する意味がなく、また、指定することができないため、図２１に示したデータ内には、ブロックの横幅を指定する情報は、記述されていない。
３行目の“blockrule”には、そのブロックをどのように描画するかを指定するための情報が記述される。この“blockrule”は、主に、拡大が指示されたときの拡大方法に関する情報であり、図２１に示した例では、”vert-fixed”が指定されている。この”vert-fixed”は、拡大が指示されたときに、ブロックの縦方向のサイズは固定し、横方向のサイズのみを拡大することを意味する。他のルールとしては、縦方向と横方向を同じ比率で拡大するなどのルールが設定されており、ブロック内に表示される内容（画像、テキスト）に合わせたルールが設定される。
４行目の“layout”には、ブロック内部の座標系および組方向を指定するための情報が記述される。図２１に示した例では、“TbRl”が指定されている。この“TbRl”は、テキストブロックの右上を原点とし、テキストを縦書きで描画することを指示する際に用いられる。“LrTb”は、テキストブロックの左上を原点とし、テキストを横書きで描画することを指示する際に用いられる。
５乃至７行目の“topskip”、“sidemargin”、“footskip”には、ブロック内でのレイアウトを設定するための情報が記述される。
このようなデータが、オブジェクトデータ部１３３には記述される。なお、図を参照して説明したデータは、一例であり、限定を示すものではない。すなわち、上述したデータ以外のデータが、データとして記述されることもある（例えば、図示はしていないが、画像の実データなど）し、上述したデータであっても、そのデータ内に、適用されるコンテンツには必要がないデータであれば、削除（省略）することもこともある。
このようなデータの変更が容易であるのは、すなわち、データの編集、変更が容易であるのは、ストリームデータ部１３２とオブジェクトデータ部１３３を分離したことにある。ストリームデータ部１３２とオブジェクトデータ部１３３を分離することにより、以下のような利点がある。
通常、書籍の原稿は、ページレイアウトに依存することなく作成される。この著作者（作成者）が作成する原稿を有効利用するには、ページレイアウトに依存する部分と文章の部分をきちんと分離する必要がある。本実施の形態において利用されるフォーマット（すなわち、上述したデータ）は、文章の部分（ストリームデータ部１３２）とレイアウトの部分（オブジェクトデータ部１３３）を分離している。
また、ストリームデータ部１３２には、文章の流れを分断することなく記述することが可能であるため、デジタル入稿形式としても利用できるようになっている。そのため、本発明におけるフォーマットで原稿を作成すれば、電子書籍のコンテンツを作成する際に行われる、データのコンバートをする必要がなく、かつ、通常の原稿データとしても利用することができる。
ＸＭＬコンバータ部２１（図２）は、出版社１から供給されたデータを、図７に示したようなデータ構造で、図８乃至図２１を参照して説明したデータを含むデータにコンバートする。このように変換されたデータは、この場合、ＸＭＬ形式のデータである。さらに、ユーザ端末７に提供するためのバイナリデータ（バイナリファイル）にするための処理が、データコンバータ部２２（図２）において行われる。
次に、データコンバータ部２２において行われる処理について説明する。図２２は、データコンバータ部２２によりコンバートされた結果、生成されるファイル（すなわち、ユーザ端末７に対して配布されるデータ）の構成を示す図である。図２２に示しように、データコンバータ部２２によりコンバートされたデータは、バイナリファイルとされ、全てのコンテンツ情報がオブジェクトとして管理されるような構成に変換される。オブジェクトとして管理されるようにすることにより、データへのアクセスが高速に行えるようになり、また、圧縮や暗号をオブジェクト毎にかけることができるようになることから、データの利用を効率的に行えるようになる。
データへのアクセスが高速に行えるようになることにより、ユーザが、データの処理にかかる時間を待ち時間として認識することもなく、ストレスを感じさせるようなことを防ぐことができる。
また、オブジェクト毎に圧縮や暗号をかけることができるようにすることで、例えば、コンテンツデータ全体に暗号をかけなくても、一部のオブジェクトだけに暗号をかけておけば、結果的にコンテンツデータ全体に暗号をかけたときと同様の効果を得ることができる。詳細は以下に説明するが、オブジェクト同士は、参照するような関係がある。その参照する一方のオブジェクトに暗号をかけておけば、他方は、暗号がかけられていなくても、結果として、暗号をかけられているオブジェクトを利用することができないため、結果として再生することができない。
このように、暗号は、コンテンツデータ全体にかける必要がなく、最小限かけておけば良く、もって、暗号化や復号にかかる時間を少なくすることができ、そのためにかかる能力なども低くてすむため、他の処理に、残った能力を割り当てることができる。
配布されるデータは、図２２に示すように、配布されるデータそのものについての情報が記述されるヘッダー情報部１８１、コンテンツの内容を示すオブジェクト情報部１８２、および、オブジェクトの位置を示すオブジェクトテーブル情報部１８３の３つに部分から構成される。
ヘッダー情報部１８１には、ファイルのフォーマットの情報、暗号化されているか否かを示すフラグ、コンテンツが表示されると想定されるスクリーン（例えば、ユーザ端末７の表示部７１（図４））のサイズなどの情報が記述される。スクリーンのサイズの情報は、ユーザ端末７以外の端末などでも、適切にコンテンツが表示されるようにするために記述される情報である。
ヘッダー情報部１８１に含まれる、または、異なる部分として構成されるようにしても良いが、適宜、文献情報なども記述される。文献情報とは、図７に示した書誌情報部１３１に記述されている情報を含む情報であり、コンテンツのタイトルなどの情報や、サムネイル画像のデータなどから構成される情報である。
オブジェクト情報部１８２には、コンテンツの内容を表示するのに必要な情報をオブジェクトという単位で扱い、それらのオブジェクトの情報が記述される。そして、オブジェクトテーブル情報部１８３には、各オブジェクトにアクセスするのに必要な情報が記述される。
なお、オブジェクト情報部１８２の直前や、オブジェクトテーブル情報部１８３の直前には、文書を成形するためなどの理由で、なんらかのデータが挿入される構成とされていても良い。また、成形のためのデータが挿入されることも、必要に応じ許可される。
オブジェクトテーブル情報部１８３には、オブジェクト番号、オブジェクトデータの開始アドレス、オブジェクトデータのサイズがセットになって記述されている。そして、オブジェクトが取得される場合、このオブジェクトテーブル情報部１８３に記述された番号が検索され、その開始アドレスが取得され、オブジェクトの読み込みに必要なメモリ領域（例えば、ユーザ端末７のＲＡＭ１０３（図５）の領域）が確保される。
各オブジェクトは、それぞれのオブジェクトのタイプによって、オブジェクト内部の記述方法が異なる。オブジェクトのタイプとして、図２３に示すようなものが挙げられる。
“PageTree”は、ページ順序をツリー構造（木構造）で表現（管理）するためのオブジェクトである。“Page”は、ページ内容が記述されるオブジェクトである。“Header”は、ページのヘッダー部の内容が記述されるオブジェクトである。“Footer”は、ページのフッター部の内容が記述されるオブジェクトである。“PageAtr”（Page属性）は、Pageオブジェクトの属性が記述されるオブジェクトである。
“Block”は、ページ内に配置されるブロック(テキストや画像など)の内容が記述されるオブジェクトである。“BlockAtr”（Block属性）は、Blockオブジェクトの属性が記述されるオブジェクトである。“MiniPage”は、ページ内によりレイアウト情報の強い領域を指定するとともに、その領域内の内容が記述されるオブジェクトである。
“BlockList”は、ブロックをリスト化するときに記述されるオブジェクトである。“Text”は、ブロック内にテキストを表示するときに、その内容が記述されるオブジェクトである。“TextAtr”（Text属性）は、“Text”のオブジェクトの属性が記述されるオブジェクトである。“Image”は、ブロック内に画像を表示すためのオブジェクトである。“Canvas”は、ページ内にレイアウトを保持するような領域を指定するとともに、その領域内の内容が記述されるオブジェクトである。
“ParagraphAtr”（段落属性）は、段落内容の属性が記述されるオブジェクトである。“ImageStream”（Imageデータ）は、画像データが記述されるオブジェクトである。“Button”は、ボタンの情報が記述されるオブジェクトである。“Window”は、Window（ウィンドウ）として表示させる内容が記述されるオブジェクトである。“PopUpWin”は、ポップアップウィンドウで表示する内容が記述されるオブジェクトである。
“Sound”は、音声ファイルを鳴らすときの情報が記述されるオブジェクトである。“SoundStream”（Soundデータ）は、音声ファイル情報が記述されるオブジェクトである。“Font”は、フォント情報が記述されるオブジェクトである。“ObjectInfo”（Object情報）は、呼び出し元のオブジェクトの附属情報が記述されるオブジェクトである。“BookAtr”（書籍情報）は、書籍の初期設定を行うオブジェクトである。“TOC”（目次情報）は、Table Of Contents が記述されるオブジェクトである。
これらのタイプの異なるオブジェクトが参照しあうことにより、電子書籍のコンテンツが表現される。データコンバータ部２２（図２）は、供給されたＸＭＬ形式のデータを、このような内容が記述されたオブジェクトに変換するわけだが、図２５を参照し、具体例を挙げて、ＸＭＬ形式のデータ（以下、適宜、そのＸＭＬ形式のデータを構成する要素を、ＸＭＬ要素と記述する）と、オブジェクトの関係について説明する。
図２４中の左側を参照するに、データコンバータ部２２に供給されるＸＭＬ形式のデータは、書誌情報部１３１、ストリームデータ部１３２、および、オブジェクトデータ部１３３から構成されるデータである。この構成および各部に記述される内容については、図７を参照して説明した通りである。図２４に示した例において、書誌情報部１３１には、“題名”ＸＭＬ要素１９１と“著者名”ＸＭＬ要素１９２が記述されている。これらのデータは、データコンバータ部２２により、ヘッダー情報部１８１に記述される。ヘッダー情報部１８１には、データコンバータ部２２により作成された設定情報も、必要に応じて書き込まれる。
図２４に示した例では、ストリームデータ部１３２には、“第１章本文”ＸＭＬ要素１９３と“あとがき”ＸＭＬ要素１９４が記述されている。まず“第１章本文”ＸＭＬ要素１９３は、データコンバート部２２において、Pageオブジェクト２０１−１、Textオブジェクト２０２−１、および、Blockオブジェクト２０３−１に変換される。同様に、“あとがき”ＸＭＬ要素１９４は、データコンバート部２２において、Pageオブジェクト２０１−２、Textオブジェクト２０２−２、および、Blockオブジェクト２０３−２に変換される。
“第１章本文”ＸＭＬ要素１９３と“あとがき”ＸＭＬ要素１９４は、共に、内容がテキストで表されるものであるため、Textオブジェクト２０２−１，２０２−２に変換される。また、このTextオブジェクト２０２−１，２０２−２は、ブロック内にテキストを表示するときに記述されるオブジェクトであるが、そのテキストが表示されるブロックに関する情報は、それぞれ、Blockオブジェクト２０３−１，２０３−２に記述されている。さらに、このBlockオブジェクト２０３−１，２０３−２に基づくブロックが設けられる所定のページ内における位置などに関する情報が、Pageオブジェクト２０１−１，２０１−２に記述される。
このように、１つのＸＭＬ要素は、複数のオブジェクトに変換される。
さらに説明を続けるに、データコンバータ部２２に供給されるデータのうち、オブジェクトデータ部１３３に記述されている“挿絵画像データ”ＸＭＬ要素１９５は、Blockオブジェクト２０３−３とImageオブジェクト２０４に変換される。この場合、“挿絵画像データ”ＸＭＬ要素１９５は、画像データを参照するためのデータであるため、Imageオブジェクト２０４に変換される。
“挿入画像データ”ＸＭＬ要素１９５は、画像データそのものではなく、対応する画像データを参照するためのデータであり、その画像データそのものは、“画像データ”ＸＭＬ要素１９６として、オブジェクトデータ部１３３に記述されている。この“画像データ”ＸＭＬ要素１９６は、データコンバータ部２２により、Imageデータオブジェクト２０５に変換される。この場合、Imageデータオブジェクト２０５に基づく画像は、Imageオブジェクト２０４に記述されている内容に従って、ブロック内に表示されるとともに、Blockオブジェクト２０３−３に記述されている内容に従って、所定のページ内に表示される。
データコンバータ部２２に供給されるＸＭＬ形式のデータのオブジェクトデータ部１３３には、図２４に示した例では、“PageStyle”ＸＭＬ要素１９７、“TextStyle”ＸＭＬ要素１９８、および、“BlockStyle”ＸＭＬ要素１９９が含まれる。これらのＸＭＬ要素は、データコンバータ部２２により、それぞれ、Page属性オブジェクト２０６、Text属性オブジェクト２０７、および、Block属性オブジェクト２０８に変換される。これらのオブジェクトは、それぞれ、Pageオブジェクト２０１、Textオブジェクト２０２、および、Blockオブジェクト２０３から参照されるオブジェクトであり、それぞれの属性が記述されている。
このように、データコンバータ部２２は、入力されるＸＭＬ形式のデータを解析し、所定の変換ルールに基づいて複数のオブジェクトに変換する。所定のルールとは、例えば、“第１章本文”ＸＭＬ要素１９３というテキストに関わるＸＭＬ要素の場合、Pageオブジェクト、Textオブジェクト、および、Blockオブジェクトといった３つのオブジェクトに変換するといったルールである。
データコンバータ部２２は、ＸＭＬ形式のデータをオブジェクトに変換する際、そのオブジェクト（バイナリデータ）をどの領域に格納するのかも判断する。また、この変換時に、データコンバータ部２２は、各オブジェクトを、オブジェクト番号（オブジェクトＩＤ）（例えば、図２４において、Pageオブジェクト２０１―１のオブジェクトＩＤは“１００”である）と称される識別用の番号で管理し、そのオブジェクトＩＤ、そのオブジェクトＩＤで管理されるオブジェクトが格納されている領域のアドレス、および、そのオブジェクトＩＤで管理されるオブジェクトのサイズを、それぞれ関連付けたオブジェクト配置順序情報２１２を作成する。
そして、データコンバータ部２２は、作成したオブジェクト配置順序情報２１２を、オブジェクテーブル情報部１８３に記述する。
オブジェクト情報部１８２にオブジェクトが格納される際、その格納される領域は、近接した領域に同一の種類のオブジェクトが格納されるようにデータコンバート部２２により制御される（このように制御される方が好ましい）。図２４を参照し、一例を挙げて説明すると、Pageオブジェクト２０１―１とPageオブジェクト２０１―２は、Pageオブジェクトという同一の種類のオブジェクトであるため、オブジェクト情報部１８２の図中上側の近接した領域に格納されるように制御されている。
データコンバータ部２２において、このような変換および制御が行われることにより、図２３に示したような構成を有するバイナリ形式のデータが作成される。その作成されたバイナリ形式のデータが、ユーザ側に配布されるデータとされる。
オブジェクトについてさらに他の例を挙げて、説明を加える。図２５に、これらのオブジェクトが利用されてページ（電子書籍）を構成する場合の模式図を示す。図２５において、１つの四角形は、１つのオブジェクトを示す。
PageTreeオブジェクト２２１は、電子書籍としての本のページ構造が記述されているオブジェクトである。そのPageTreeオブジェクト２２１により示されるページ構成は、図２５に示した例では、Pageオブジェクト２２２乃至２２５から本が構成されていることを示している。Pageオブジェクト２２２乃至２２５は、実際に表示部７１に表示されるコンテンツの紙面（レイアウト）が、どのように構成されるかなどの情報が記述されている。
Pageオブジェクト２２２は、Page属性オブジェクト２２６を参照し、Pageオブジェクト２２３乃至２２５は、Page属性オブジェクト２２７を参照する。Page属性オブジェクト２２６，２２７には、それぞれ、ページのマージン、ヘッダー、フッターなどの情報が記述されている。上述した説明においては、図１９を参照して説明したPageStyleの情報が、このPage属性オブジェクトには記述されている。
図２５に示したように、Page属性オブジェクトは、複数のPageオブジェクトから参照されるように設定されている場合もある。共通に参照できる情報は、共用できるようにすることで、データ構成を簡略化することができ、コンテンツデータ全体のデータ量を小さくすることができる。また、編集なども容易に行えるようになる。
Pageオブジェクト２２５は、Blockオブジェクト２２８およびBlockオブジェクト２２９を参照する。Blockオブジェクト２２８，２２９には、ページの本文領域などに配置され、内部に描画するテキストやイメージなどの領域を確保するとともに、文字の拡大をしたときの動作を規定するための情報が記述されている。
このBlockオブジェクト２２８，２２９は、共に、Block属性オブジェクト２３０を参照する。Block属性オブジェクト２３０は、ブロックのサイズや、拡大が指示されたときの成型方法などが記述されている。上述した説明においては、図２１を参照して説明したBlockStyleの情報が、このBlock属性オブジェクトには記述されている。
Blockオブジェクトには、ページ内に配置されるテキストやイメージなどに関する情報が記述されているが、図２５に示したBlockオブジェクト２２８は、ページ内にテキストを表示させるための情報であるため、Textオブジェクト２３１を参照している。Textオブジェクト２３１には、ブロック内にテキストを記述するための情報が記述されている。
Textオブジェクト２３１は、Text属性オブジェクト２３２を参照している。Text属性オブジェクト２３２には、この場合、Textオブジェクト２３１の属性が記述されており、フォント情報や行間などの初期値の情報などが記述されている。上述した説明においては、図２０を参照して説明したTextStyleの情報が、このText属性オブジェクトには記述されている。
一方、図２５に示したBlockオブジェクト２２９は、ページに内に画像（イメージ）を表示させるための情報であるため、Imageオブジェクト２３３を参照している。Imageオブジェクト２３３には、ブロック内に画像を記述するための情報（位置やサイズなどの情報）が記述されている。
図２５に示した例では、ページ上に画像が描画される場合、Blockオブジェクト２２９が作成され、そのBlockオブジェクト２２９が、Imageオブジェクト２３３を呼び出すような構成とされている。また、実際の画像データは、Imageデータ２３４が参照されることによって取得されるように構成されている。
このように、データをオブジェクト化することによって、各オブジェクトの参照関係が明確になるとともに、フォーマットの拡張も行いやすくなる。フォーマットの拡張を行いやすいということに関し具体例を挙げて説明すると、図２５に示した例において、Imageオブジェクト２３３をMovieオブジェクト（動画像を表示させるためのオブジェクト）に変更し、動画を扱えるようにしても、ページレイアウトを記述するPageオブジェクト２２５を変更する必要はない。
すなわち、簡単に、静止画像（Image）を動画像（Movie）に変更することができる。もちろん、他の静止画像に置き換えることも可能である。
さらに、所定のコンテンツを表現する要素が、全てオブジェクトとして管理されているため、他のコンテンツのオブジェクトを使って本を表現したりすることも可能となる。例えば、所定のコンテンツ（本）を表現するために作成されたデータを、他のコンテンツ（本）を同じように表現させるためのデータとして流用することも可能となる。
このことを利用し、必要なオブジェクトだけを取り出といったようなことも容易に行うことができる。そのようなことに対して、具体的な例を挙げて説明を加える。ここまでの説明は、データ作成装置２における処理であったが、ここで、データ作成装置２により作成されたデータを扱うユーザ端末７側の処理について説明する。その処理の１つとして、スクラップブックの作成という処理がある。
このスクラップブックの作成処理について説明することにより、上述したように、データをオブジェクトとして扱うことによる利点についてさらに説明を加える。
ここで、スクラップブックとは、ユーザが、所定の書籍内の気に入ったセンテンスや画像などを残しておくための本のことである。例えば、紙媒体の新聞の場合、ユーザがその新聞から、気に入った記事を切り取り、ノートなどに貼り付けて管理するときの、そのノートのことを、ここではスクラップブックと称し、そのスクラップブックを電子書籍の１つとして作成することができる機能をスクラップブック機能と称する。
作成されたスクラップブックは、他の電子書籍と同様に扱うことができる。そのスクラップブックの作成に係わるユーザ側の基本的な操作としては、保存しておきたい部分（スクラップにしたい部分）を選択し、選択完了後にその部分をスクラップブックに追加（保存）させる。
図２６と図２７を参照し、スクラップブックについてさらに説明を加える。図２５に示したような構成を有する電子書籍を、ユーザがユーザ端末７で閲覧しているとき、その電子書籍内の、Imageデータオブジェクト２３４を処理することにより表示されている画像をスクラップにしたいと所望し、スクラップにするための所定の処理（後述）を行ったとする。
所定の処理が行われることにより、図２６に示したデータがコピーされる（図２５に示したツリー構造のデータの内の、一部分である枝が切り取られる）。そして、その切り取られた枝の部分が追加されたスクラップブックの一例を、図２７に示す。図２７に示したスクラップブック２５０は、PageTreeオブジェクト２５１で記述される電子書籍である。
スクラップブック２５０は、Pageオブジェクト２５２乃至２５４から構成される。スクラップされる記事（スクラップされた枝）が増加すると、スクラップブック自体のページ数も増加するため、Pageオブジェクトも、そのページの増加に対応して作成される。図２７に示した例では、Pageオブジェクト２５２乃至２５４は、全て、Page属性オブジェクト２５５を参照する構成とされている。
このようにすることで、スクラップブック２５０としてユーザに提供される本は、各ページが統一されたスタイルとなり、見やすいものとなる。スクラップブック２５０は、さまざまな本から切り抜かれたテキストや画像などから構成されるため、切り抜かれたままの状態が維持されて貼り付けられると、例えば、縦書きのテキストの次に、横書きのテキストがレイアウトされるなどする可能性がある。
そのようなページは、統一性がないページとなり、ユーザにとって見づらいものとなってしまう可能性がある。そこで、ページ毎のスタイルに統一性を持たせるようにする。すなわち、本実施の形態においては、全てのPageオブジェクトが、同じPage属性オブジェクトを参照させるように構成することにより、そのようなことを実現する。
図２７に示した例では、Pageオブジェクト２５４が、スクラップブック２５０内での最後のページであると設定されている。その為、その最後のページであるPageオブジェクト２５４に対して、図２６に示した切り取られた枝（データ）が貼り付けられる。このことにより、貼り付けられた枝は、Pageオブジェクト２５５で参照されるデータとなる。
本発明を適用していない電子書籍における、スクラップブックのような、必要な部分を取り出すような手法は、取り出したテキストデータをスクラップブック用の形式で取り出すことになる。しかしながら、本フォーマットは、上述したように、全てのデータがオブジェクト化されているため、フォーマット形式を変えることなく、スクラップした部分を追加することができる。すなわち、本発明によれば、データの切り張りが容易に行うことができる。
スクラップブックの作成について、さらに説明を加える。まず、図２８のフローチャートを参照し、ユーザが行うスクラップにする部分の選択に関する処理について説明する。ステップＳ１１において、ユーザは、ユーザ端末７の表示部７１に、所望のコンテンツ（本文）を表示させる。そして、その表示されている本文中に、スクラップしたい部分が存在している場合、所定の操作を行い、メニュー画面を表示部７１に表示させる（ステップＳ１２）。
所定の操作は、例えば、入力部１０６（図５）を構成するジョグダイヤル７９（図４）などが操作されることにより行われる。ユーザは、表示されたメニュー内から、スクラップの処理を実行させるための「文字クリップ」という項目を選択する。なお、表示されるメニューについての図示および説明は省略するが、そのメニュー内の項目には、どのような項目が設けられていても良い。
ステップＳ１３において、スクラップの処理を実行するための「文字クリップ」という項目が選択されると、ステップＳ１４において、先頭枠が指定される。図２９は、表示部７１に表示されている本文上に、先頭枠２７０が表示された状態を示している。先頭枠２７０とは、スクラップにする部分の先頭の文字（位置）を指定できる範囲を示す枠である。
この先頭枠２７０は、Pageオブジェクトで規定されるページ内（仮想ページ内）のみを移動できるように設定されている。ここで、再度ページについて説明を加えるに、ページとは、Pageオブジェクトで規定されており、そのPageオブジェクトで規定されるページは、例えば、１ページであっても、実際のページ（仮に紙書籍としたときのページ、または、表示部７１に所定の倍率のときに一度に表示される範囲を１ページとしたときのページ）数では、１００ページに相当させることもできるように設定されている。
また、Pageオブジェクトで規定されているページは、仮想描画領域１５２（図１０）内に描画されるものが１ページと設定される。従って、表示部７１に一度に表示されるもの（表示可能領域１５１に描画されるもの）を１ページと把握した場合、数ページにわたって表示されるものであっても、１つのPageオブジェクトで規定されているページ内であれば、１ページとして扱われる。
よって、先頭枠２７０は、表示可能領域１５１と仮想描画領域１５２が一致している場合（図１０中の上側の図に示したような場合）は、表示部７１内に表示されている本文以外の部分に移動することはないが、表示可能領域１５１と仮想描画領域１５２が一致していない場合（図１０中の下側の図に示したような場合）は、ユーザ側から見れば、複数ページにわたって先頭枠２７０が移動可能にされていると把握されるような移動がされるときもある。
いずれにせよ、先頭枠２７０は、Pageオブジェクトで規定されるページ外に移動されることはないように設定されている。これは、上述したように、本実施の形態においては、データをオブジェクト化して扱うようにしているためである。この場合、１つのPageオブジェクトに対して処理がされるのであって、複数のPageオブジェクトに対して行われるのではない。
このようにすることで、すなわち、複数のPageオブジェクトに対して処理（スクラップに係わる処理）が行われることがないため、例えば、複数のPageオブジェクトを含む１冊分のデータ全てが、１回のスクラップの処理により実行されてしまうようなことを防ぐことができる。さらに換言するならば、このようにすることで、違法なコピーを防ぐことができる。
後述するように、スクラップが指示された部分は、著作権などの関係で、コピーが許可されない場合もある。例えば、１冊の本を複数のPageオブジェクトで構成し、さらに、それらのPageオブジェクト内の少なくとも１つを、コピー不可に設定されている場合を考える。１冊の本を全てコピーしようとした場合、ユーザ側は、複数のPageオブジェクト毎にスクラップの処理を繰り返し行わなくてはならず面倒である。よって、この時点で、まずユーザは、コピーを断念すると考えられる。
さらに、ユーザがスクラップ処理を繰り返すことを断念しなくても、そのコピーしようとしている本の中の、少なくとも１つのPageオブジェクトはコピーが不可なので、結果として、１冊分をコピーすることは不可能である。このように、コピーに対して、実質、少なくとも２段階のプロテクトがかかっていることになるため、不正なコピーを防ぐことが可能となる。
図２８のフローチャートの説明に戻り、ステップＳ１４において、先頭枠２７０が、ユーザが所望する部分に移動されると、ステップＳ１５において、先頭文字が指定される。なお、この先頭枠２７０の移動は、入力部１０６（図５）としての例えば、ジョグダイヤル７９（図４）が操作されることにより行われ、位置の決定は、決定ボタン８１が操作されることにより行われる。以下に説明する先頭文字や末尾文字の選択に係わる操作も、基本的に同様に、ジョグダイヤル７９などにより移動が指示され、決定ボタン８１により決定が指示される。
図３０を参照するに、先頭文字が指定されるときには、表示部７１上に、かつ、先頭枠２７０内に、文字指定枠２７１が表示される。この文字指定枠２７１は、スクラップする文章（画像）の最初の文字（位置）を指定する際に表示され、ユーザの操作により、先頭枠２７０内で上下左右に移動可能にされている。
先頭文字が選択（指定）されると、ステップＳ１６において、末尾枠（基本的に、先頭枠２７０と同一の枠）が指定され、ステップＳ１７において、末尾文字が指定される（基本的に、文字指定枠２７１と同一の枠が用いられて指定される）。このステップＳ１６とステップＳ１７の処理は、基本的に、ステップＳ１４とステップＳ１５の処理と同様であるので、その詳細な説明は省略する。
なお、ここでは、選択する文字の範囲を指定するための枠が指定され、その後、その枠内から文字が選択されるとして説明したが、直接的に文字が選択されるようにしても良い。しかしながら、選択できる範囲を指定する枠を用いることにより、例えば、画像とテキストが入り交じっているようなページから、スクラップにする部分が選択される場合、その枠があることにより、画像が選択範囲内にあるのか、テキストが選択範囲内にあるのかをユーザにはっきりと明示することができると考えられる。
このようにして、スクラップする部分が選択される。ユーザは、その選択した部分で良ければ、ステップＳ１８によって、スクラップブックへの登録を決定する。なお、各ステップにおいて、ユーザは、元の処理に戻すことが可能とされており、随時、所望のステップの処理を行えるようになっている。
このようなスクラップブックへの登録に係わる処理は、ユーザ側は、入力部１０６（図５）を操作することにより指示し、ユーザ端末７側は、ＣＰＵ１０１が、入力部１０６からの信号が示す内容を判断し、その判断に基づき、また、ＲＡＭ１０３などに展開されているプログラムやデータに基づき、先頭枠２７０の移動などの処理を実行することにより行われる。
スクラップブックへの登録の処理が行われる際の、ユーザ端末７側で行われる処理について図３１乃至図３３のフローチャートを参照して説明する。ステップＳ３１において、スクラップブックへの新たな記事（テキスト、画像などであり、コンテンツの一部分を示すもの）の登録が指示された場合、既に、作成されているスクラップブックがあるか否かが判断される。例えば、図２７に示したような構造を有するスクラップブック２５０が、記憶部１０７（図５）に記憶されているか否かが、ＣＰＵ１０１により判断される。
なお、ユーザ端末７に対して、着脱自在の記録媒体に、スクラップブック２５０が、記録されるように設定されている、または、記録媒体にも記録できるように設定されている場合、その記録媒体は、ドライブ７４にセットされるため、ＣＰＵ１０１は、ドライブ７４にセットされている記録媒体（パッケージメディア５でも良い）に記録されているデータも参照し、ステップＳ３１における処理を実行する。
いずれにせよ、ステップＳ３１において、作成されているスクラップブックが存在していないと判断された場合、ステップＳ３２に処理が進められ、存在していると判断された場合、ステップＳ３３に処理が進められる。ステップＳ３２に処理が進められた場合、すなわち、スクラップブックは存在しないと判断された場合、新たにスクラップブックが作成され、そのスクラップブックの１ページ目に、新たに登録が指示された記事が追加できるような状態に設定される。
一方、ステップＳ３３に処理が進められた場合、すなわち、スクラップブックは存在すると判断された場合、その存在すると判断されたスクラップブックの最終ページ（例えば、図２７においては、Pageオブジェクト２５４で規定されるページ）に、新たに登録が指示された記事が追加できるような状態に設定される。
ステップＳ３２またはステップＳ３３の処理において、スクラップブックへ新たに記事を追加できる状態に設定されると、ステップＳ３４に処理が進められる。ステップＳ３４において、スクラップブックへの登録が指示された記事は、登録（保存）が許可されている記事であるか否かが判断される。保存が指示された記事に対して制限無くコピーされる事を許可すると、著作権などの関係から好ましくない状況が発生する可能性がある。
例えば、購入者に対しては１回のみコピーを許可する、制限無くコピーを許可する、ページ内の一部分ならコピーを許可するなどのコピーに対するライセンス条件が、コンテンツデータには記載されており（例えば、図２２のヘッダー情報部１８１に含まる。また、データ作成装置２の著作権保護処理部２３（図２）により付加される情報）、そのライセンス条件が参照されることにより、ステップＳ３４の処理が実行される。
ステップＳ３４において、ライセンス情報を参照した結果、保存が許可されていないと判断された場合、ステップＳ３５に処理が進められ、保存が許可されていると判断された場合、ステップＳ３６に処理が進められる。
ステップＳ３５において、スクラップブックに登録するとして指示された記事は、コピーが許可されていないため、保存はできないということをユーザに認識させるようなメッセージが表示部７１に表示される。そして、図３１に示したフローチャートの処理、すなわち、スクラップブックに係わる処理は終了される。
このように、コピーは許可されていない記事は、保存できないため、その後の処理が行われることはない。よって、ステップＳ３４における処理をステップＳ３１の前に行うようにし、結果として、無駄な処理となってしまうような処理がされないようにしても良い。
また、同様の理由から、例えば、図２８のフローチャートのステップＳ１３において、スクラップブックへの登録処理を実行するための「文字クリップ」という項目が選択された場合、かつ、その選択されたときに表示されている記事（本文）が、コピー禁止のものであると判断される場合（この時点で、ステップＳ３４における処理を実行する）、その時点で、表示されている記事はコピーできない記事であることをユーザに知らせるためのメッセージが表示される（ステップＳ３５における処理を実行する）ようにしても良い。
換言すれば、スクラップにできない記事が選択されていると判断された時点で、ユーザ側に、そのようなことを認識させるような処理が実行されるようにしても良い。なお、ステップＳ３４の処理に限らず、各ステップの処理は、必要に応じ、その処理の順番を入れ替えることは可能である。
図３１に示したフローチャートの処理の説明に戻り、ステップＳ３４において、ライセンス条件を参照した結果、選択された記事は、コピー（保存）が許可されている記事であると判断された場合、ステップＳ３６に処理が進められる。ステップＳ３６において、スクラップブックへの登録は、クリップ（Clip）保存であるか引用（Quotation）保存であるかが判断される。クリップ保存とは、見た目をそのまま保存し、引用保存は、文書内のデータをそのままコピーする保存である。
また、クリップ保存が選択された結果保存されたデータは、表示部７１に表示されたボタンが操作されたときに表示されるように設定される。引用保存が選択された結果保存されたデータは、標準の書式で描画（スクラップブックにおいて設定されている書式での描画）がされるように設定される。クリップ保存は、主に、画像をスクラップする際に用いられ、引用保存は、主に、テキストをスクラップする際に用いられる。
このように、２つの保存方式を用いるのは、まず、テキストの場合、その表示にかかる処理は比較的軽く、また、複数のテキストを、スクラップブックの１ページとして、表示部７１に１回の表示で表示させる事も可能であり、そのようにしても、見づらくはならないと考えられる。
テキストに対し画像の場合、その表示かかる処理は比較的重いため、複数の画像を、同一ページ内に表示する場合、そのページを表示させるまでに時間がかかってしまう可能性がある。また、画像の場合、複数の画像を、表示部７１に１回の表示で表示させると、１枚の画像は小さいものとなってしまい、見づららいものになってしまうと考えられる。また、画像は、必ずしも常に表示させておく必要性はなく、必要に応じて（ユーザが所望したとき）表示されればよいと考えられる。
そこで、本実施の形態においては、２つの保存方式を用い、ユーザによりその選択が行えるようにしている。なお、ここでは、ユーザが選択できるとして説明するが、ユーザが選択するのではなく、単に、画像が選択されたと判断されるときには、クリップ保存し、テキストが選択されたと判断されるときには引用保存するといったように、ユーザ端末７側で判断するように設定されていても良い。
ステップＳ３６において、新たに登録が指示された記事の保存方法は、クリップ保存であると判断された場合、ステップＳ３７に処理が進められる。クリップ保存が指示された場合、その指示された（スクラップにされた）記事は、画像オブジェクト（Imageオブジェクト）とされて保存（記録）される。
一方、ステップＳ３６において、新たに登録が指示された記事の保存方法は、引用保存であると判断された場合、ステップＳ３８に処理が進められる。引用保存が指示された場合、その指示された記事の文字列が取得される。この取得される文字列とは、図２８乃至図３０を参照して説明したような処理が行われることによりユーザにより選択された先頭文字から末尾文字までの文字列である。
文字列が取得されると、ステップＳ３９において、その追加された文字列を指定するための指定オブジェクトの取得処理が実行される。このステップＳ３９における指定オブジェクト取得処理に関しては、図３２を参照して後述する。
ステップＳ３７までの処理、または、ステップＳ３９までの処理が実行されることにより、ユーザが指定した記事が、スクラップブックに新たに追加するためのオブジェクトとして作成されたので、そのオブジェクトの追加の処理が、ステップＳ４０において実行される。このステップＳ４０におけるオブジェクト追加処理については、図３３を参照して後述する。
ステップＳ４１において、新たにオブジェクトが追加されたスクラップブックが、記憶部１０７（図５）またはドライブ７４（図５）にセットされている記録媒体（不図示）に記録（保存）される。このようにして、スクラップブックの更新が行われる。
図３２のフローチャートを参照して、ステップＳ３９における指定オブジェクト取得処理について説明する。ステップＳ６１において、３つのＩＤが取得される。第１のＩＤは、スクラップブックに追加保存するとして指定された記事に係わるPageオブジェクトのＩＤである。例えば、図２５を再度参照するに、Textオブジェクト２３１で規定されるテキスト内の部分が、スクラップ用の記事として指定された場合、Pageオブジェクト２２５のＩＤが取得される。
第２のＩＤは、保存する記事の先頭となるBlockオブジェクトのＩＤである。このＩＤをここでは、start_idとする。第３のＩＤは、保存する記事の末尾となるBlockオブジェクトのＩＤである。このＩＤをここでは、end_idとする。図３４を参照して、start_idとend_idについて説明する。図３４には、所定のページとそのページ内に含まれるブロックを図示している。
Page２８１は、３つのBlock２８２乃至２８４から構成されている。ユーザが、Block２８３内の所定の文字を先頭文字として選択し（ステップＳ１４，１５（図２８）の処理として選択し）、Block２８４内の所定の文字を末尾文字として選択した（ステップＳ１６，Ｓ１７の処理として選択した）場合、その間に存在する文字列が、記事として選択された範囲となる。
図２８乃至図３０を参照して説明したように、ユーザは、１ページ内であれば、枠２７０を移動させることが可能であるし、その枠２７０内であれば、先頭文字や末尾文字を選択することが可能であるので、スクラップにするとして指定される記事が、複数のブロックにまたがることも起こりえることである。
図３４に示したような場合、先頭文字が存在するBlock２８３のBlockオブジェクトのＩＤが、start_idとされ、末尾文字が存在するBlock２８４のBlockオブジェクトのＩＤが、end_idとされる。図３４には図示していないが、先頭文字と末尾文字の両方が、例えば、Block２８３内に存在するような場合、そのBlock２８３のBlockオブジェクトのＩＤが、start_idとend_idの両方に設定される。
また、Page２８１が、１つのBlock（例えば、Block２８２）のみで構成されているような場合、先頭文字と末尾文字の両方が、そのブロックに必然的に含まれることになるため、start_idとend_idは、結果として同一のものとなる。
このような３つのＩＤが、ステップＳ６１において取得される。ＩＤが取得されると、ステップＳ６２に処理が進めらる。ステップＳ６２において、その時点で、スクラップブック内で使われているオブジェクトＩＤの最大値が取得される。その取得されるオブジェクトＩＤの最大値を、ここでは、Old_IDと設定する。
図２５を再度参照するに、図２５に示した各オブジェクトに付された符号（２２１乃至２３４）を、そのオブジェクトのＩＤであるとし、図２５に示した構成の本がスクラップブックであるとすると、そのスクラップブック内のオブジェクトの内、最大の値が付されているのは、Imageオブジェクト２３４である。よって、この場合、Old_IDは、“２３４”と設定される。
なお、このように、その時点でのスクラップブックの最大値を有するＩＤを検出するのは、新たにオブジェクトを追加（保存）するわけだが、その追加されるオブジェクトに付されるＩＤと同じにならないようにするためである。よって、ステップＳ６３において、新たなオブジェクトに付されるＩＤが設定される。その設定は、Old_IDに１だけ加算された値とされる。このＩＤをNew_IDと設定する。
なお、１つの記事が選択されると、複数のオブジェクトが追加されることになる。例えば、図２６を参照して説明したように、Imageデータ２３４’による画像がスクラップされる記事として選択されたときには、４つのオブジェクトがスクラップブックに追加されることになる。よって、新たに追加されるオブジェクトが幾つになるかは、ステップＳ６３の時点では不明なため、New_IDは、新たに追加されるオブジェクトの１つに対して付されるＩＤであり、追加される他のオブジェクトに対しては、New_IDと連続する番号が、順次付されていくことになる。
ステップＳ６３において、New_idが設定されると、ステップＳ６４に処理が進められる。ステップＳ６４において、指定されたPageオブジェクト（ステップＳ６１により取得された第１のＩＤに対応するPageオブジェクト）の解析が開始される。そのPageオブジェクトに記述されているデータが１行毎（処理単位毎）に解析される。
ステップＳ６５において、解析対象とされている行に記載されているデータは、コマンドであるか否かが判断される。なお、このステップＳ６５においては、Pageオブジェクト内には、解析していないコマンドが存在しているか否か（Pageオブジェクト内に記載されているデータの最後の行であるか否か）もあわせて判断されている。
ステップＳ６５において、解析対象とされているデータは、コマンドであると判断された場合、ステップＳ６６に処理が進められ、そのコマンドは、Blockオブジェクトを参照する指示を出すためのコマンドであるか否かが判断される。
ステップＳ６６において、Blockオブジェクトを参照する指示を出すコマンドではないと判断された場合、ステップＳ６４に戻り、それ以降の処理が繰り返される。一方、ステップＳ６６において、Blockオブジェクトを参照する指示を出すコマンドであると判断された場合、ステップＳ６５に処理が進められる。ステップＳ６５において、解析対象とされているコマンドが参照するBlockオブジェクトのＩＤは、start_idとend_idとに挟まれる番号のＩＤであるか否かが判断される。
図３４を再度参照して説明する。図３４において、Block２８２乃至２８４に付されている符号を、Block２８２乃至２８４に対応するBlockオブジェクトのＩＤであるとする。図３４に示したような場合、Page２８１に対応するPageオブジェクトに記述されているコマンドには、Block２８２乃至２８４に対応するBlockオブジェクトを、それぞれ参照するためのコマンドが含まれている。
解析対象とされているコマンドが、Block２８２に対応するBlockオブジェクトを参照する指示を出すものであった場合、そのBlockオブジェクトのＩＤは、“２８２”である。この場合、start_id＝２８３であるため、start_idより前の番号であるので、ステップＳ６７においては、ＮＯと判断される。すなわち、この場合、スクラップにする記事に関係のないBlockオブジェクトであるので、ステップＳ６７以降の処理を行う必要がないため、ステップＳ６４に処理が戻される。
これに対し、解析対象とされているコマンドが、Block２８３に対応するBlockオブジェクトを参照する指示を出すものであった場合、そのBlockオブジェクトのＩＤは、“２８３”である。また、解析対象とされているコマンドが、Block２８４に対応するBlockオブジェクトを参照する指示を出すものであった場合、そのBlockオブジェクトのＩＤは、“２８４”である。
このような場合、start_id＝２８３であり、end_id＝２８４であるため、ＩＤが“２８３”と“２８４”は、start_idとend_idに挟まれる（この場合、イコール関係が成り立つ）ので、ステップＳ６７においては、ＹＥＳと判断される。すなわち、この場合、スクラップにする記事に関係のあるBlockオブジェクトであるので、ステップＳ６７以降の処理が行われることになる。
ステップＳ６７において、解析対象とされているコマンドが参照するBlockオブジェクトのＩＤは、start_idとend_idとに挟まれる番号のＩＤではないと判断された場合、ステップＳ６４に処理が戻されるが、そのとき解析対象とされるのは、次の行に記述されているデータ（次の処理単位にあたるデータ）である。
一方、ステップＳ６７において、解析対象とされているコマンドが参照するBlockオブジェクトのＩＤは、start_idとend_idとに挟まれる番号のＩＤであると判断された場合、換言すれば、スクラップの対象とさている記事を含むブロックのBlockオブジェクトのＩＤであると判断された場合、ステップＳ６８に処理が進められ、そのBlockオブジェクトが参照しているのは、Textオブジェクトであるか否かが判断される。
例えば、図３４において、Block２８３内に表示されているのはテキストであるが、Block２８４内に表示されているのは画像である場合も考えられる。そこで、ステップＳ６８において、処理対象とされているBlockオブジェクトが参照しているのは、Textオブジェクトであるか否かが判断される。ステップＳ６８において、処理対象とされているBlockオブジェクトが参照しているのは、Textオブジェクトではないと判断された場合、ステップＳ６９に処理が進められる。
ステップＳ６９において、処理対象とされているBlockオブジェクト、そのBlockオブジェクトが参照しているオブジェクト、そのオブジェクトを描画（処理）するのに必要な全てのオブジェクトの情報が取得される。このステップＳ６９における処理について、図２５を再度参照して説明する。例えば、図２５に示したような構造を有する本から、Pageオブジェクト２２５内のBlockオブジェクト２２９が処理対象とされている場合を考える。
処理対象とされているBlockオブジェクト２２９が参照しているオブジェクトは、Imageオブジェクト２３３と、Block属性オブジェクト２３０である。そして、そのオブジェクトを描画するのに必要な全てのオブジェクトとしては、Imageオブジェクト２３３のImageを描画するための必要なImageデータオブジェクト２３４である。
よって、このような場合、ステップＳ６９において取得される情報は、Blockオブジェクト２２９、Block属性オブジェクト２３０、Imageオブジェクト２３３、および、Imageデータオブジェクト２３４の情報である。このようにして、順次、必要なオブジェクトの情報が取得される。
図３２のフローチャートの説明に戻り、ステップＳ６８において、処理対象とされているBlockオブジェクトが参照しているのは、Textオブジェクトであると判断された場合、ステップＳ７０に処理が進められる。ステップＳ７０において、参照されている（処理対象とされる）BlockオブジェクトとTextオブジェクトの描画属性が、スクラップブック専用のものに変更される。
上述したように、スクラップブックには、さまざまな記事がスクラップにされる可能性がある。その記事はテキストだけであると想定した場合であっても、縦書きのテキスト、横書きのテキストなどがあり、さらに、文字のフォント、文字色など、さまざまな形態が考えられる。そのような様々な形態の記事が、そのままの形式で、１冊のスクラップブックに貼り付けられるとすると、そのスクラップブックは見づらいものとなってしまう。
そこで、スクラップブックに貼り付けられる記事は、統一性のある描画属性にすることにより、見やすいものとする。具体的には、全て横書き（または、縦書き）に統一し、フォントや色なども同一のものにする。そのような変更が終了されると、ステップＳ７１に処理が進められる。ステップＳ７１において、Textオブジェクトから参照されている全てのオブジェクトの情報が取得される。
このようにして、スクラップブックに登録が指示されたオブジェクトに関する情報が取得される。このようなステップＳ６４乃至７１までの処理が、繰り返されることにより、Pageオブジェクトの内容が、順次解析され、スクラップされた記事に係わるBlockオブジェクトなどの情報が取得される。そして、Pageオブジェクト内の全ての行に対して解析が終了されると、ステップＳ６５において、Pageオブジェクト内に解析されていないコマンドはないと判断されるため、ステップＳ７２に処理が進められる。
ステップＳ７２において、引用した文献（その文献を識別する（示す）情報）と日付を表示するためのオブジェクトが作成される。このステップＳ７２において、引用した文献と日付を表示するためのオブジェクトが作成されるのは、違法なコピーが行われないようにするためであり、さらに、違法なコピーがインターネットなどで流通しないように（流通したとしても、その著作権者などが明記されている状態に常にしておくように）するためである。
このようにして作成されたオブジェクトは、ステップＳ４０（図３１）においてスクラップブックに追加される。なお、このようにして作成されたオブジェクトには、順次、ステップＳ６３において設定されたNew_IDから始まる番号が、ＩＤとして割り振られる。
図３３は、ステップＳ４０（図３１）におけるオブジェクト追加処理について説明するフローチャートである。ステップＳ９１において、その時点でのスクラップブックの最終ページに対応するPageオブジェクトのＩＤが取得される。例えば、その時点で図２７に示したような構造のスクラップブック２５０が存在していたような場合、最終ページに対応するPageオブジェクトは、Pageオブジェクト２５４であり、そのPageオブジェクト２５４のＩＤが、ステップＳ９１の処理として取得される。
ステップＳ９１において、PageオブジェクトのＩＤが取得されると、ステップＳ９２に処理が進められ、取得されたＩＤに対応するPageオブジェクトにより描画されるページ（最終ページ）に、新たなブロックを追加することができるか否かが判断される。この判断は、１ページには３つのブロックしか存在させることができないなどの条件を設定し、その条件を満たすか否かを判断することにより行われるようにしても良いし、１ページの描画領域の大きさを設定し、その領域内に新たなブロックの領域を確保できるか否かを判断することにより行われるようにしても良い。
または、他の方法により判断が行われるようにしても良い。いずれの方法によっても良いが、上述したようにPageオブジェクトには、複数のブロックを無制限に追加することが可能とされているため、何らかの設定を設け、所定のブロック数のみが、１つのPageオブジェクトに登録されるように制御される必要がある。ステップＳ９２において、最終ページに新たなブロックを追加することができないと判断された場合、ステップＳ９３に処理が進められ、新たなブロックを追加するためのページが作成される。
すなわち、ステップＳ９３に処理が進められた場合、新規に、Pageオブジェクトが作成される。そして、その新規に作成されるPageオブジェクトに対して、そのオブジェクトを識別するためのＩＤが割り振られる。その割り振られるＩＤは、スクラップブックを構成するオブジェクト内のＩＤで、最も大きい値を有するＩＤに１だけ加算した値の番号である。そのような番号をＩＤとして付加されたPageオブジェクトが、ステップＳ９４以降の処理において、そのスクラップブック内の最終ページとして取り扱われる。
一方、ステップＳ９２において、最終ページに新たなブロックを追加できると判断された場合、新たなページを作成する必要がないため、ステップＳ９３の処理は省略され、ステップＳ９４に処理が進められる。ステップＳ９４において、最終ページに対応するPageオブジェクトの最後のコマンドの後に、取得されたBlockオブジェクト、および、引用された文献と日付を表示するために、ステップＳ７２（図３２）の処理として作成されたオブジェクトが、それぞれ参照されるようなコマンドが付加される。
そして、ステップＳ９５において、取得されたオブジェクト、および、引用された文献と日付を表示するためのオブジェクトのデータが、スクラップブックのデータに追記される。このように、オブジェクトが追記されたので、その追記されたオブジェクトに関するデータ（オブジェクトテーブル）が、ステップＳ９６において更新される。
このようにして、オブジェクトの追加が行われる。このような処理がユーザ端末７で行われることにより、ユーザは、所望の記事から構成されるスクラップブックを作成することができる。
このように、電子書籍においては、紙書籍では手間のかかる処理であっても、同様の処理を簡便に行うことができる。しかしながら、例えば、紙書籍の場合、ユーザは、その紙書籍の厚さを見るだけで、読み終わるのにかかる日数などを概算することができるが、電子書籍の場合は、目に見える厚さというものがないので、そのようなことはしづらいといったことが考えられる。
そのようなことを換言すれば、ユーザは、紙書籍の場合、パラパラとページをめくることにより、文字の大きさなどを把握し、ページ数を把握することにより、読み終わるための日数などを概算することもある。また、例えば、辞書などの場合、調べたい文字が、どの辺に記載されているかを、ページ数の感覚で把握することができる。
しかしながら、電子書籍の場合、紙書籍では不可能である文字を拡大して表示するということができる。そのために、拡大率により、同じ書籍であっても、ページ数が変化してしまう。よって、電子書籍で、パラパラとページをめくり（ボタンを操作し続け）、文字の大きさやページ数を把握し、読み終わる日数を概算するといったことは難しく、また、電子書籍が辞書などの場合、紙書籍の辞書ではできた、ページ数を感覚で把握するといったことが難しいと考えられる。
具体的に表現すれば、例えば、紙媒体の辞書において、１０ページ目に表示されている単語は、いつでも１０ページ目に表示（印刷）されているため、ユーザは、その単語を調べたければ、１０ページ当たりに存在しているという感覚を把握し、次回、同じ単語を調べたければ、１０ページ当たりであるという感覚をいかして調べることができる。
しかしながら、電子書籍の場合、拡大率が異なれば、前回調べた単語が、１０ページ目に存在していても、次回調べるときには、１０ページ目に存在するとは限らず、また、１０ページ目という紙の厚さや、ページのめくる速度による得られる感覚を把握することもできないために、単語を調べづらいといったことが考えられる。
このような、長い間ユーザに親しまれてきた紙書籍の場合に得られる感覚というものを、電子書籍でも、同様の感覚を得られるようにすることは、電子書籍の普及（その電子書籍のデータの販売による普及という意味はもちろん含むが、ユーザ端末７の普及も含む）につながると考えられる。
そこで、本実施の形態においては、アンカーという概念を導入し、電子書籍でも紙書籍のような、ページをパラパラとめくるということにより、ユーザが得られる感覚というものを実現できるようにする。そのような感覚というものを実現できるようにすることにより、上述したように、電子書籍の普及につながることはもちろんであるが、電子書籍におけるページの概念を、明確にできるという利点もある。
すなわち、上述したように、電子書籍では、ページは、文字の拡大などにより可変的に変化してしまう。さらに、本実施の形態においては、Pageオブジェクトで記述されるものを１ページとしているため、その１ページの長さが固定的なものでなく可変的なものである。さらに、ユーザ端末７の表示部７１に一度に表示されるものが、１ページであるとは言えない。
例えば、表示部７１に表示されているものが小説であるような場合、１行毎にスクロールされる（例えば、２行目に表示されていた文章が、１行目にスクロールされ、そのスクロールに対応して、他の行も１行ずつスクロールされる）こともあり、そのようなときには、ページという感覚は得られず、１ページの区切りは、どの部分に存在するかが把握しづらくなると考えられる。
このようにとらえると、電子書籍においては、ページという概念は曖昧であるといえる。そのことによる利点もあるが、問題点もある。しかしながら、以下に説明するようなアンカーという概念を導入することにより、ページに対する概念を明確にすることができ、ページという概念が曖昧であることに起因する問題点も解決されると考えられる。
そのような利点を有するアンカーについて説明する。図３５は、アンカーとページの関係について説明するための図である。図３５においては、ページ３０２−１乃至３０２−４は、１００パーセントの表示が指示されているときに、表示部７１に一度に表示される量であるとする。換言すれば、ページ３０２−１乃至３０２−４は、それぞれが、仮想描画領域１５２−１（図１０）に描画される１ページであり、表示可能領域１５１と大きさが一致している場合であるとする。すなわち、図１０中の上側に示した図の状態であるとする。
そのようなページ３０２−１乃至３０２−４（４ページ）に対して、文字の拡大の指示が出された場合、また、ここでは、その拡大率が、２倍（２００パーセント）である場合、図３５中の下側に示したように、ページ３０３−１乃至３０３−８の８ページの構成に変更される。すなわち、文字が２倍に拡大されることにより、ページ数も２倍になる。
ページ３０３−１乃至３０３−８の状態は、図１０中の下側に示した図の状態である。ページ３０３−１乃至３０３−８の各ページは、それぞれが、表示可能領域１５１と同じサイズとされているが、仮想描画領域１５２−２には、例えば、ページ３０３−１とページ３０３−２の２ページが描画されている状態である。
例えば、ユーザが、１００パーセントの表示で閲覧しているときに、ページ送りを実行すると、ページ３０１−１の次にページ３０３−２が表示され、ページ３０１−２の次にページ３０３−３が表示されるといったように、順次、ページを閲覧することになる。ユーザは、ページ３０２−１から３０３−４に移動するときには、３ページ先のページに移動させればよいという感覚を得る。
換言すれば、ページ３０２−１に表示されている“Ａ”という文字（ここでは、文字はもちろん、記事、単語など含む意味とする）から、ページ３０２−４に表示されている“Ｈ”という文字（記事）に移動する際、ユーザは、ページ３０２−１から３ページ分（ページ３０２−２，３０２−３，３０３−４）先のページに、目的とする“Ｈ”という文字が存在していることを感覚的に把握する。感覚的に把握するとは、例えば、ページ送りのためのボタン（例えば、図４の送りボタン５７）を操作している時間などである。
または、表示部７１上に、表示されているページが全体のページのうちのどの辺のページであるかを示す、例えばバーみたいなものが表示されている場合、ユーザは、そのバーの位置を参照することによりだいたいの位置を把握することができる。そのようなバーの位置などを認識することで、ページの位置を把握するようなことも、感覚的に把握しているという表現に該当する。
同じことが、２００パーセントの表示で閲覧されているときに行われたとする。すなわち、ページ３０３−１に表示されている“Ａ”という文字から、ページ３０３−８に表示されている“Ｈ”の文字まで移動させるとき、ユーザが、１００パーセントの表示時と同じ感覚で、３ページ先に移動させると、ページ３０３−４に移動してしまい、所望のページであるページ３０３−８に移動されないことになる。
これは、各倍率のときに、その倍率におけるページ数で移動の処理が行われるからである。具体的には、１００パーセントの表示において、ページ送りが実行されると、ページ３０２−１→ページ３０２−２→ページ３０２−３→ページ３０２−４の順でページ送りされ、２００パーセントの表示において、ページ送りが実行されると、ページ３０３−１→ページ３０３−２→ページ３０３−３→ページ３０３−４→ページ３０３−５→ページ３０３−６→ページ３０３−７→ページ３０３−８の順でページ送りされる。
図３５に示したように、アンカー３０１−１乃至３０１−５が、１００パーセントの表示が行われる際の各ページの先頭に打たれている。具体的には、ページ３０２−１の先頭にアンカー３０１―１が、ページ３０２−２の先頭にアンカー３０１―２が、ページ３０２−３の先頭にアンカー３０１―３が、ページ３０２−４の先頭にアンカー３０１―４が、それぞれ打たれている。
このようなアンカーという、各ページの先頭を示す情報が用いられてページ送りの処理が実行される。１００パーセントの表示時で、ページ３０３−１が表示されている状態のときに、ページ送りの処理が指示された場合、アンカーの情報が用いられて、そのページ送りの処理が実行される。すなわち、ページ３０３−１が表示されている状態であるので、まず、アンカー３０１−２が読み出され、そのアンカー３０１−２が指し示すページ３０２−２がページ送り先として表示される。
さらに、ボタンが操作され続けてページ送りの指示が継続されている状態であれば、アンカー３０１−３の情報が読み出され、そのアンカー３０１−３が指し示すページ３０２−３が、次のページ送り先として表示される。このようなアンカー情報が用いられたページ送りの処理が、ページ送りが指示されている間、繰り返し行われる。
２００パーセントの表示がされているときについて説明する。ページ３０３−１が表示部７１上に表示されているときに、ページ送りが指示されると、アンカー３０１−２の情報が読み出される。アンカー３０１−２は、ページ３０３−３の先頭を示す情報である。このように、アンカーの情報は、表示倍率に依存しない情報（１００パーセント表示を基準とし、その１００パーセントの表示時のみに依存する情報であり、他の拡大率のときには依存していない情報）とされている。
さらに、ボタンが操作され続けてページ送りの指示が継続されている状態であれば、アンカー３０１−３の情報が読み出され、そのアンカー３０１−３が指し示すページ３０３−５が、次のページ送り先として表示される。すなわち、この場合、２ページづつページが送られることになる。このようなアンカー情報が用いられたページ送りの処理が、ページ送りが指示されている間、繰り返し行われる。
このようなアンカーという情報が用いられたページ送りの処理が実行されれば、例えば、ページ３０３−１に表示されている“Ａ”という文字から、ページ３０３−８に表示されている“Ｈ”という文字に移動させるときに、ユーザは、３ページ分の移動を指示すればよいことになる。すなわち、ユーザは、１００パーセントのときと同じ感覚で、ページ送りをすれば、同じページ先に移動させることができる。よって、拡大率によらず、同じ感覚で処理を実行させることが可能となる。
このアンカーの情報は、存在しなくても電子書籍を読むこと（書籍を扱うこと）は可能であるが、存在することによって、該当する電子書籍のコンテンツが何ページで表現されているのかがわかり、また、Pageオブジェクトの大小にかかわらず、リニアに見た目のページを移動することができる。よって、紙書籍のような感覚的な扱いを、電子書籍でも提供することができる。
ところで、図３５を参照して説明したような１００パーセントの表示がされているときに、表示部７１に一度に表示されるのが、１ページであり、その１ページが、Pageオブジェクトにより規定される１ページである場合、換言すれば、図１０中の上側に示したように、表示可能領域１５１と仮想描画領域１５２−１が同一の大きさとされている場合、上述したようなページ送りの処理がされれば有効であると考えられる。
しかしながら、１つのPageオブジェクトにより規定されるページが、表示部７１に一度に表示されるのを１ページと表現したとき、１００ページ分に相当する場合もある。そのように設定することは可能である。よって、１つのPageオブジェクトにより規定されるページ内に、複数のアンカー情報を持たせ、できる限り、１００ページ分に相当するならば、１００ページとしてページ送りがされるように設定される方が好ましい。
図３６と図３７を参照し、アンカーについてさらに説明を加える。図３６，３６においては、仮想描画領域１５２は、２つ分の表示可能領域１５１から構成されている。図３６と図３７では、説明の都合上、２つの表示可能領域１５１を縦に並べて、また、一辺が接触した状態で図示している。図３６に示した例では、仮想描画領域１５２には、Block３１１乃至３１４の４つのブロックが存在している。換言すれば、Pageオブジェクトにより規定されるページには、４つのBlockオブジェクトにより規定される領域が確保されている。
図３６に示した状況は、Block３１１乃至３１３は、上段に示した描画可能領域１５１に含まれた状態であり、Block３１４は、下段に示した描画可能領域１５１に含まれた状態である。ブロック内に表示されるコンテンツが画像の場合、その画像が途中で分断されるのは好ましい表示ではないので、図３６に示したように、ブロックの全ての領域が、表示可能領域１５１内に含まれるように制御される。
図３６に示した状態は、仮想描画領域１５２（仮想ページ）が、Pageオブジェクトから参照される、Block３１３に対応するBlockオブジェクトと、Block３１４に対応するBlockオブジェクトの間で分断されている例を示している。
図３７に示した状況は、Block３２１とBlock３２２が上段に示した描画可能領域１５１に含まれているが、Block３２３は、上段と下段に示した描画可能領域１５２に含まれる。すなわち、Block３２３は分断されている。このようなことは、Block３２３内に表示されるコンテンツが、テキストである場合などに、起こりうることである。図３７に示した状態は、仮想描画領域１５２が、Textオブジェクトを参照するBlockオブジェクトの途中で分断される場合を示している。
このように、異なるBlockの間で分断される場合と、同一Block内で分断される場合とが存在する。図３６に示したようなときには、Block３１１にところに、アンカー３１５が打たれ、Block３１４のところにアンカー３１６が打たれる。同様に、図３７に示したようなときには、Block３２１のところに、アンカー３２４が打たれ、Block３２３のと途中に、アンカー３２５が打たれる。
このようにアンカーが打たれれば、異なるBlockの間で分断される場合と、同一Block内で分断される場合とで、状況が異なっても、アンカーの数は同じになる。よって、見た目上のページ数（この場合、２ページ）を同じにすることが可能となる。
図３６または図３７に示したような状況では、１つのPageオブジェクトは、２つのアンカー情報を有することになる。このように、１つのPageオブジェクトは、複数のアンカー情報を有することができる。また、図３７に示したように、アンカーの情報は、必ずしも所定のBlockの先頭位置を示すのではなく、Block内の所定の位置を示すようにしても良い。
図３８は、このようなことを考慮したときのPageTreeオブジェクトに記述されている情報と、アンカー情報との関係を説明するための図である。PageTreeオブジェクトには、図３８に示すように、参照するPageオブジェクトの情報が記述されている。図３８に示した例では、PageTreeオブジェクトは、Pageオブジェクト１乃至６（Page１乃至６）を参照している。このようなときのアンカー打ち情報としては、図３８に示した例ではPage１が１、Page２が５、Page３が３、Page４が３、Page５が２、Page６が３である。
この数値は、そのページが、幾つのアンカー情報を有しているか（そのページに、幾つのアンカーが打ち込まれているか）を示すものである。たとえは、Page１には１つのアンカーが打たれ、Page２には５つのアンカーが打たれていることが示されている。
PageTreeオブジェクトは、各Pageの前後関係や、まとまりを示す役割を有していることから、PageTreeオブジェクトによって束ねられている各ページが、いくつの仮想ページ（アンカーにより分断されるページ）を持っているかを管理させる（図３８に示したようなアンカー打ち情報を管理させる）ようにする。このようにすることによって、複数のページを移動するような場合でも、リニアにページ移動することが出来る。
また、アンカーにより分断されるページ数を累積換算することにより、その電子書籍の仮想ページの総数を出すことができる。この仮想ページの総数とは、ユーザに、その電子書籍が何ページの本であるのかを認識させたいページ数であると換言することができる。例えば、図３８に示した例では、アンカー打ち情報から、１７ページ（＝１＋５＋３＋３＋２＋３）が、ユーザに認識させたいページ数であり、リニアにページ移動させるときのページ数である。
PageTreeオブジェクトは、図３８に示したようなアンカー打ち情報を参照するが、PageTreeオブジェクトが参照するPageオブジェクトは、図３９に示したようなアンカー打ち情報を参照する。まず、図３９に示した例では、Page３（Pageオブジェクト）は、Block１乃至５を含む構成（Block乃至５に対応するBlockオブジェクトを参照する構成）とされている。
そのPage３が参照するアンカー打ち情報には、図３９に示すように、３つのアンカー打ち情報が含まれている。このPage３に３つのアンカー打ち情報が存在していることは、図３８に示したPageTreeオブジェクトが参照するアンカー打ち情報に記述されていることからも確認できる。
１つ目のアンカー打ち情報は、“Block２”のところに、アンカーが打たれていることを示している。この場合、Block２の先頭の部分にアンカーが打たれている。２つ目のアンカー打ち情報は、“Block３ ０x２００”のところにアンカーが打たれていることを示している。この場合、Block３内の“０x２００”で示される位置にアンカーが打たれている。この“０x２００”は、例えば、Ｘ−Ｙ座標系で示される所定の座標を示す値とされても良いし、ページ内のどの文字のところで分断されるのをバイト数で表したものでも良い。
３つ目のアンカー打ち情報は、“Block５ ０x１２０”のところにアンカーが打たれていることを示している。この場合、Block５内の“０x１２０”で示される位置にアンカーが打たれている。
このように、ページ内での分割位置を示すためのアンカー打ち情報も用意されている。Pageオブジェクトは、Page内にどのような情報が記述されるかを管理するところであることから、Page内のどのBlockのところで仮想ページが分断されるのかを管理させる（図３９に示したようなアンカー打ち情報を管理させる）。また、Textを参照しているBlockで分断される場合は、Text内部のどの文字のところで分断されるのかをバイト数などで明示する。このような記述がされることにより、ページ内のどの位置から描画するかがわかるようになる。
このようなアンカーに関する情報は、出版社１（図１）からデータ作成装置２に供給されるデータには含まれていない。そのため、アンカー情報は、データ作成装置２において付加されるデータである。このような、出版社１から供給されるデータには含まれていないデータを付加することにより、課金がされるようにしても良い。また、データを付加することで、他の会社が発行する電子書籍との差別化をはかることができる。
アンカー情報が付加されるタイミングとしては、データコンバータ部２２（図２）による処理が実行されるタイミングである。このように、アンカー情報は、ここでは、ユーザ側への配布用のデータが作成される際に、新たに付加される情報である。
ここでは、アンカー情報が、出版社１から供給されるソースデータには含まれていない情報であり、データ作成装置２により付加される情報の１例であるとして説明するが、アンカー情報以外の情報も、データ作成装置２により付加されるようにしても良いことは、言うまでもない。
次に、図４０のフローチャートを参照し、ページ送りが指示されたときのユーザ端末７内で行われる処理について説明する。ページ送りが指示されたときには、上述したような特徴を有するアンカーという概念の情報が用いられる。図４０に示したフローチャートの処理が開始されるのは、入力部１０６（図５）としての、送りボタン７５（７７）、または、戻りボタン７６（７８）（いずれも図４）が操作されたときであり、ＣＰＵ１０１（図５）が、それらのボタンが操作されたと判断したときである。
ステップＳ１１１において、ボタンが操作された時点で、表示部７１上に表示されているページが、何番目の仮想ページなのかの情報が取得される。図３７を再度参照するに、ボタンが操作された時点で、表示部７１上に表示されているページが、例えば、ブロック３２１乃至３２３が表示されているページであった場合、仮想ページの１ページ目（図３７に示した状態においては、２ページの仮想ページから構成されるとし、上段が１ページ目、下段が２ページ目とする）が表示されていると判断され、その１ページ目の情報が取得される。
ステップＳ１１２において、その時点で表示されているPageTreeオブジェクトが取得される。この取得は、ステップＳ１１１において取得された情報を用いて行われる。このステップＳ１１２における処理で、PageTreeオブジェクトが取得されると、ステップＳ１１３において、PageTreeオブジェクトのアンカー情報から、現在位置が特定される。ステップＳ１１３までの処理により、図３８で示した情報が取得されることになる。
すなわち、PageTreeオブジェクトが参照するアンカー打ち情報から、総ページ数が判断される。また、ステップＳ１１１の処理で、その時点でのページに関する情報が取得されているため、その時点でのページは、総ページ内のどの辺に位置するページであるかが判断可能となる。よって、現在位置を特定することができる。
ステップＳ１１４において、現在位置から仮想ページをＮページ進んだ位置が求められる。ここで、Ｎページ進んだ位置とは、送りボタン７５（７７）が操作されている場合には、現在位置より先に位置するページ（番号的に大きなページ番号が付されているページ）であり、戻りボタン７６（７８）が操作されている場合には、現在位置より前に位置するページ（番号的に小さなページ番号が付されているページ）である。
また、ここで、Ｎページと表現したのは、必ずしも１ページずつ移動（ページ送りまたはページ戻り）（１アンカー情報毎に移動）すると設定されている必要がないためである。例えば、ページ数が少ない書籍であれば、１ページずつページが移動されても良いが、ページ数が多い書籍である場合、１ページずつページが移動されるよりも、複数ページ（Ｎページ）が一度に移動される方が使い勝手が良くなると考えられる。
そこで、ここでは、Ｎページ移動されるとして説明する。ＮページのＮの設定の仕方であるが、その書籍の総ページ数を考慮して設定されるようにしても良い。例えば、総ページ数の５パーセントのページ数をＮと設定するなどでも良い。また、さらに、総ページ数と現在位置を考慮し、現在位置から、指示されている方向に存在するページ数を算出し（例えば総ページ数が１００ページで、現在位置が３０ページ目で、指示されている方向が送りページ方向である場合、７０ページと算出される）、その算出されたページ数の数パーセント（例えば、５パーセント）のページ数をＮと設定しても良い。そのパーセント自体も、ページ数に依存し、変化されるようにしても良い。
もちろんＮは、固定値でも良い。なお、Ｎページは、所定の秒数当たり、例えば、１秒当たりに移動されるページ数である。
どのような方式を用いてＮが設定されても良いが、ステップＳ１１４において、現在位置から、指示された方向にＮページだけ移動した位置が求められる。そして、ステップＳ１１５において、移動先として求められた位置に対応するPageオブジェクトにアクセスし、そのPageに対応するアンカー情報が取得される。例えば、図３９を参照するに、移動先のPageオブジェクトが、Page３に対応するオブジェクトである場合、図３９に示したようなアンカー打ち情報が取得されることになる。
ステップＳ１１６において、仮想ページ数の情報を基に、どの位置から描画するかを計算し、その計算された位置からの描画が、表示部７１上で行われる。この描画は、簡便な表示である。ユーザが、紙書籍でページ送りしているとき、各ページをじっくり閲覧しているわけでなく、ページの一部分のみ（ページの端の部分（先頭部分）など）を閲覧しているだけである。そこで、電子書籍の場合も、例えば、表示されているコンテンツが小説などのときには、各ページの始めの数行だけが、表示されればよいと考えられる。
このようにすることで、描画にかかる処理能力を削減することができ、処理にかかる時間を少なくすることができる。そのため、連続的に、表示部７１上の表示を切り換えていくことが可能となる。そのような簡易的な描画は、ボタンが操作されている間、すなわちページ送り（戻り）が指示されている間、繰り返し行われる。その為に、ステップＳ１１７において、続けて移動が指示されているか否かが判断される。
ステップＳ１１７において、ページの移動が継続的に指示されていると判断された場合、ステップＳ１１３に処理が戻され、それ以降の処理が繰り返し行われる。一方、ステップＳ１１７において、ページの移動は継続的に指示されていないと判断された場合、換言すれば、ページの移動の終了が指示された（ボタン操作は終了された）と判断された場合、ステップＳ１１８に処理が進められる。
ステップＳ１１８において、レイアウトなどが考慮された描画が行われる。これは、ページの移動が終了されたということは、ユーザは、その移動先のページを閲覧したいと所望しているためであると考えられる。そこで、そのようなときには、通常の表示が行われる方が好ましいので、そのようにされる。すなわち、ステップＳ１１８における処理は、移動先のページの通常の状態で表示されるべき表示がされるための処理である。
このように、ページ送り、または、ページ戻りの処理が行われる。ユーザは、紙書籍と同じような感覚で、ページ数の多い書籍であれば、早めにページをめくる（一度に多くのページをめくる）ことができ、ページ数の少ない書籍であれば、比較的ゆっくりページをめくる（１ページづつめくる）ことができる。また、ユーザは、ボタンを操作してる時間で、どのくらいのページの移動ができるのかという感覚的なことを、拡大率に関係なく、常に同じ感覚で行うことができる。
このように、本発明によれば、電子書籍のコンテンツデータのフォーマットをオブジェクト化し、かつ、レイアウト形式にブロックという概念を導入することで、フォーマットの拡張性を高めることが可能となる。
また、フォーマットをオブジェクト化したことにより、すでにある内容をほとんど変えずに、新たな内容を付け足すことが簡単になる。これによって、購入した電子書籍と同じフォーマットで、スクラップブックを作成できるという機能を実現することが可能となる。
さらに、文字拡大になどによるレイアウトの崩れがあることも予め想定し、アンカー情報を利用することによって、線形にページを移動することができるようなる。
上述した一連の処理は、それぞれの機能を有するハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
記録媒体は、図３に示すように、パーソナルコンピュータ（データ作成装置２）とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク６１（フレキシブルディスクを含む）、光ディスク６２（CD-ROM（Compact Disc-Read Only Memory），DVD（Digital Versatile Disc）を含む）、光磁気ディスク６３（MD（Mini-Disc）（登録商標）を含む）、若しくは半導体メモリ６４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ４２や記憶部４８が含まれるハードディスクなどで構成される。
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
本発明を適用した情報処理システムの一実施の形態の構成を示す図である。 データ作成装置の機能ブロック図である。 データ作成装置の内部構成例を示す図である。 ユーザ端末の外観の構成を示す図である。 ユーザ端末の内部構成例を示す図である。 表示部に表示される画面の一例を示す図である。 データ作成装置により作成されるデータの構成例を示す図である。 表示部に表示される画面の一例を示す図である。 データの内容を説明するための図である。 領域について説明するための図である。 領域について説明するための図である。 データの内容を説明するための図である。 データの内容を説明するための図である。 領域について説明するための図である。 データの内容を説明するための図である。 表示位置について説明するための図である。 連続ページ群と独立ページ群とについて説明するための図である。 データの内容を説明するための図である。 データの内容を説明するための図である。 データの内容を説明するための図である。 データの内容を説明するための図である。 データの構成例を示す図である。 オブジェクトについて説明するための図である。 ＸＭＬ形式のデータとバイナリ形式のデータの関係について説明するための図である。 オブジェクトについて説明するための図である。 スクラップされた記事のオブジェクトについて説明するための図である。 スクラップブックの構成例を示す図である。 スクラップする処理について説明するためのフローチャートである。 記事の選択について説明するための図である。 記事の選択について説明するための図である。 スクラップの保存の処理について説明するためのフローチャートである。 オブジェクトの取得の処理について説明するためのフローチャートである。 オブジェクトの追加の処理について説明するためのフローチャートである。 オブジェクトの取得について説明するための図である。 アンカーについて説明するための図である。 ブロックの分断について説明するための図である。 ブロックの分断について説明するための図である。 アンカー打ち情報について説明するための図である。 アンカー打ち情報について説明するための図である。 ページの移動に係わる処理について説明するためのフローチャートである。
符号の説明
１ 出版社， ２ データ作成装置， ３ 市場， ４ ネットワーク， ５ パッケージメディア， ６ ＰＣ， ７ ユーザ端末， ２１ ＸＭＬコンバータ部， ２２ データコンバータ部， ２３ 著作権保護処理部， ２４ 配信部， ２５ パッケージメディア作成部， ７１ 表示部， ７２ ＵＳＢインタフェース， ７３ イーサネットインタフェース， ７４ ドライブ， ７５ 送りボタン， ７６ 戻りボタン， ７９ ジョグダイヤル， ８０ 拡大ボタン， ８１ 決定ボタン， １３１ 書誌情報部， １３２ ストリームデータ部， １３３ オブジェクトデータ部， １５１ 表示可能領域， １５２ 仮想描画領域， １７１ 連続ページ群， １７２ 独立ページ群， １８１ ヘッダー情報部， １８２ オブジェクト情報部， １８３ オブジェクトテーブル情報部， ３０１ アンカー

Claims (10)

  1. 電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータを記憶する記憶手段と、
    前記コンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集する編集手段と
    を備える情報処理装置。
  2. 前記スクラップブックは、異なるコンテンツデータからコピーされた複数の前記Pageオブジェクトを含む場合であっても、前記Page属性オブジェクトは１つしか含まない
    請求項１に記載の情報処理装置。
  3. 前記スクラップブックに新たに記事を追加する場合、スクラップブックの他の記事が表示されている状態で、指示があったときだけ表示される記事とするクリップ保存か、または、他の記事と同様にスクラップブックにおいて設定されている書式で描画される引用保存かを設定する
    請求項１に記載の情報処理装置。
  4. 前記クリップ保存を設定した場合、新たに登録する記事は、前記Imageオブジェクトとして保存する
    請求項３に記載の情報処理装置。
  5. 前記引用保存を設定した場合、前記スクラップブックに追加するとして指定された記事に係わる前記Pageオブジェクトの第１のＩＤ、保存する記事の先頭となる前記Blockオブジェクトの第２のＩＤ、および、保存する記事の末尾となる前記Blockオブジェクトの第３のＩＤを取得し、
    前記第１のＩＤに対応する前記Pageオブジェクトに記述されているコマンドを１行毎に解析し、そのコマンドが、Blockオブジェクトを参照する指示を出すためのコマンドである場合、解析対象とされているコマンドが参照する前記BlockオブジェクトのＩＤは、前記第２のＩＤと前記第３のＩＤとに挟まれる番号のＩＤであるか否かを判断し、
    挟まれるＩＤでないと判断したときには、前記Pageオブジェクト内の次の行の解析に処理を移行し、
    挟まれるＩＤであると判断したときには、前記Blockオブジェクトが参照するのはTextオブジェクトであるか否かをさらに判断し、
    Textオブジェクトではないと判断した場合、処理対象とされている前記Blockオブジェクト、そのBlockオブジェクトが参照しているオブジェクト、そのオブジェクトを描画するのに必要な全てのオブジェクトの情報を取得し、
    前記Textオブジェクトであると判断した場合、参照されている前記Blockオブジェクトと前記Textオブジェクトの描画属性を、スクラップブック専用の前記Page属性オブジェクトにあった属性に変更し、さらに、前記Textオブジェクトから参照されている全てのオブジェクトの情報を取得する
    請求項３に記載の情報処理装置。
  6. 既に作成されているスクラップブックに新たな記事を追加する場合、既に作成されているスクラップブックの最終ページに対応するPageオブジェクト内の最後のコマンドの後に、新たに追加する記事のBlockオブジェクトを参照するためのコマンドを付加し、
    新たに追加される記事に必要なオブジェクトのデータを、前記スクラップブックのデータとして追記し、
    その追記されたオブジェクトに関するオブジェクトテーブルを更新する
    請求項１に記載の情報処理装置。
  7. 前記既に作成されるスクラップブックの最終ページに新たな記事を追加できるか否かを判断し、追加できないと判断される場合には、新たにPageオブジェクトを作成し、
    その新たに作成されるPageオブジェクトのＩＤは、前記スクラップブックを構成するオブジェクト内のＩＤで、最も大きい値を有するＩＤに１だけ加算した値とし、
    そのようなＩＤが付加されたPageオブジェクトを、前記スクラップブック内の最終ページとする
    請求項６に記載の情報処理装置。
  8. 電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集する
    ステップを含む情報処理方法。
  9. 電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集する
    ステップを含む処理を実行させるコンピュータが読み取り可能なプログラム。
  10. 電子書籍用のデータであり、全てのコンテンツ情報がオブジェクトとして管理されるような構成のバイナリ形式のコンテンツデータであり、前記コンテンツデータを構成するオブジェクトを木構造で管理するためのPageTreeオブジェクト、前記電子書籍を構成するページ毎に作成され、そのページの内容が記述されているPageオブジェクト、そのPageオブジェクトで管理されるページ内の領域を管理するBlockオブジェクト、そのBlockオブジェクトにより管理される領域内に記述されるテキストを管理するTextオブジェクト、そのBlockオブジェクトにより管理される領域内に記述される画像を管理するImageオブジェクト、前記Pageオブジェクトの属性が記述されているPage属性オブジェクト、前記Blockオブジェクトの属性が記述されているBlock属性オブジェクト、前記Textオブジェクトの属性が記述されているText属性オブジェクト、および、前記ImageオブジェクトのImageを描画するのに必要なImageデータオブジェクトのうち、該当するオブジェクトから構成されるコンテンツデータから、前記Pagetreeオブジェクト、前記Pageオブジェクト、前記Page属性オブジェクトを少なくとも含む構成とされるコンテンツデータをスクラップブックとして編集する
    ステップを含む処理を実行させるコンピュータが読み取り可能なプログラムを記録している記録媒体。
JP2008148276A 2008-06-05 2008-06-05 情報処理装置および方法、プログラム、並びに記録媒体 Expired - Fee Related JP4783401B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008148276A JP4783401B2 (ja) 2008-06-05 2008-06-05 情報処理装置および方法、プログラム、並びに記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008148276A JP4783401B2 (ja) 2008-06-05 2008-06-05 情報処理装置および方法、プログラム、並びに記録媒体

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2003284717A Division JP2005056039A (ja) 2003-08-01 2003-08-01 情報処理システムおよび方法、プログラム、並びに記録媒体

Publications (2)

Publication Number Publication Date
JP2008269637A true JP2008269637A (ja) 2008-11-06
JP4783401B2 JP4783401B2 (ja) 2011-09-28

Family

ID=40048959

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008148276A Expired - Fee Related JP4783401B2 (ja) 2008-06-05 2008-06-05 情報処理装置および方法、プログラム、並びに記録媒体

Country Status (1)

Country Link
JP (1) JP4783401B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5864796B1 (ja) * 2015-03-23 2016-02-17 全国大学生活協同組合連合会 テキスト処理装置及びコンピュータプログラム並びにコンテンツ処理装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07152739A (ja) * 1993-11-29 1995-06-16 Matsushita Electric Ind Co Ltd 文書印刷装置
JPH08227420A (ja) * 1995-11-13 1996-09-03 Hitachi Ltd 文書作成装置
JP2002229976A (ja) * 2001-02-01 2002-08-16 Canon Inc 情報処理装置及びその方法、コンピュータ可読メモリ、プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07152739A (ja) * 1993-11-29 1995-06-16 Matsushita Electric Ind Co Ltd 文書印刷装置
JPH08227420A (ja) * 1995-11-13 1996-09-03 Hitachi Ltd 文書作成装置
JP2002229976A (ja) * 2001-02-01 2002-08-16 Canon Inc 情報処理装置及びその方法、コンピュータ可読メモリ、プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5864796B1 (ja) * 2015-03-23 2016-02-17 全国大学生活協同組合連合会 テキスト処理装置及びコンピュータプログラム並びにコンテンツ処理装置

Also Published As

Publication number Publication date
JP4783401B2 (ja) 2011-09-28

Similar Documents

Publication Publication Date Title
KR101085283B1 (ko) 정보 처리 시스템 및 방법, 및 기록 매체
US10706091B2 (en) User driven computerized selection, categorization, and layout of live content components
JP4843867B2 (ja) 文書処理装置、文書処理方法および文書処理プログラム、ならびに、記録媒体
US9436419B2 (en) Selectively printing portions of a web page based on user selection
US5860073A (en) Style sheets for publishing system
CN101548273A (zh) 确定可演示文件的区域以及参考目录和引用的可扩展标记语言模式
KR20080053930A (ko) 문서 레이아웃의 적응을 용이하게 하는 시스템과, 콘텐트를배열하는 컴퓨터 구현 방법 및 컴퓨터 구현 시스템
JP2005056041A (ja) 情報処理装置および方法、プログラム、並びに記録媒体
WO2009000141A1 (fr) Procédé, système et dispositif de représentation d&#39;informations de structure logique de fichier de mise en page
JP2007094449A (ja) 情報編集装置、情報編集システム、情報編集方法、およびプログラム
JP4014160B2 (ja) 情報処理装置、プログラム、及び記録媒体
JP2004206170A (ja) 文書処理方法および装置
JP2008233969A (ja) コンピュータの処理対象のオブジェクトが各ノードを成す、木構造により表現される、構造化電子文書を編集するためのコンピュータプログラム、方法及び装置
Bagley et al. Creating reusable well-structured PDF as a sequence of component object graphic (COG) elements
JP2005056042A (ja) 情報処理装置および方法、プログラム、並びに記録媒体
JP7394333B2 (ja) 広告処理装置及び広告処理方法
JP4783401B2 (ja) 情報処理装置および方法、プログラム、並びに記録媒体
US8429559B2 (en) Elicitation method for custom image preferences using keywords
JP3308153B2 (ja) マルチメディア情報高次元化表示システム
JP2005056043A (ja) 情報処理装置および方法、プログラム、並びに記録媒体
TW201337605A (zh) 多用途網路編輯頁面自動轉檔技術
KR100856132B1 (ko) 웹 대상물의 관리 시스템
JP2005056040A (ja) 情報処理装置および方法、プログラム、並びに記録媒体
JP2003196264A (ja) ウエブページ作成方法、ウエブページ作成プログラム及びウエブページ作成装置
JP2012014488A (ja) 情報処理装置、情報処理方法、およびプログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101026

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101227

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110310

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20110414

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110506

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110623

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110708

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140715

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4783401

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees