JP2020140240A - 読み放題サービスシステムおよびＢｔｏＢプラットフォーム - Google Patents

Abstract

【課題】ＢｔｏＢ型の読み放題サービスシステムにおいて，ＢｔｏＢ型の読み放題サービスを採用する企業が，自社商品の売上げに繋がるベネフィットを得られるようにする。【解決手段】読み放題サービスシステム１は，ＢｔｏＢ型の読み放題サービスに適したシステムで，ポータルサーバ３およびストレージサーバ４を含むＢｔｏＢプラットフォーム２，ユーザ認証サーバ５とから少なくとも構成される。ポータルサーバ３は，電子書籍ＩＤごとに，電子書籍ＩＤに対応する電子書籍の記載範囲とこの記載範囲に記載されている内容を示す単語を記憶し，閲覧ログで示される電子書籍とこの閲覧範囲に対応する記載範囲の単語を含ませたタグクラウドをログ集計結果としてユーザ名ごとに出力するログ集計部３５を備える。【選択図】図１

Description

本発明は，所定数の電子書籍が読み放題になる読み取りサービスに係る発明で，特に，ＢｔｏＢ（Business to Business）向けの読み取りサービスに係る発明である。

消費者が企業から購入または支払い契約する商品には様々な種類がある。商品には，洋服などの物，介護などのサービスおよび金融商品が含まれる。金融商品には，資産運用を目的とした投資信託や外貨預金などの投資商品などに加え，経済リスクに備えることを目的とした生命保険や損害保険などの保険商品も含まれる。

商品を購入した消費者の満足度を向上するには，商品を購入したことで消費者が得られるベネフィットを向上させることが必要である。特に，保険商品の場合，その性質上，経済リスクが発生しない限り金銭的な損が顧客に発生するため，保険商品の販売契約数を増やすには，金銭以外のベネフィットを向上させることが重要になる。なお，金銭以外のベネフィットを向上させることは，保険商品以外のすべて商品において重要なことである。

商品（例えば，保険商品）を購入した消費者などに提供する金銭以外のベネフィットとして，電子書籍の読み放題サービスが考えられる。読み放題サービスの対象になる電子書籍を商品（例えば，保険商品）に係る電子書籍に限定すれば，消費者は，消費者が購入した商品に関連する知識を深め，自分自身のＱＯＬ（Quality of life）を高めることができる。

電子書籍の取次サービスを行うことを商売としている企業である電子書籍取次業者でない限り，商品を販売する一般企業は，電子書籍の取次サービスを行わないので，商品を購入した消費者などに提供する電子書籍の読み放題サービスの実現には，電子書籍取次業者が，消費者ではなく，一般企業に対して電子書籍の読み放題サービスを提供することが必要になる。

消費者を対象としたＢｔｏＣ（Business to Consumer）型の読み放題サービスはすでに様々なサービスがすでに存在する。ＢｔｏＣ型の読み放題サービスの場合，消費者は，定額料金（例えば，一定の月額）を支払うことで，一定期間の間（例えば，１カ月間），読み放題サービスに登録された電子書籍（漫画や雑誌など）が読み放題になる。

ＢｔｏＣ型の読み放題サービスに係る発明としては，例えば，特許文献１に係る発明が既に開示されている。特許文献１に係る発明は，読み放題サービス（定額利用料）の電子コンテンツ提供サービスにおいて電子コンテンツの著作権者に対する収益配分量を決定するための発明であるが，特許文献１の図５には，電子コンテンツ提供サービスの構成が図示され，また，特許文献１の図１０には，電子コンテンツ提供サービスの動作が図示されている。

ＢｔｏＣ型の読み放題サービスの場合，読み放題サービスの利用者が払う定額利用料の合計などが収益になり，読み放題サービスに電子書籍を提供している著作権者には，所定のアルゴリズムに従い読み放題サービスの収益から算出された額がロイヤリティとして配分される。

読み放題サービスの収益から著作権者に支払うロイヤリティを算出するアルゴリズムは様々ある。電子書籍が閲覧されたページ数に応じて著作権者に支払うロイヤリティを算出するのが一般的であるが，特許文献１では，ユーザ専用の書庫（固定容量の記憶領域）に電子書籍が格納されていた時間および電子書籍のデータ量に応じてロイヤリティを決定している。また，特許文献２では，課金対象者の数を著作権者に支払うロイヤリティの算出に利用している。

特開２０１４−１２３３１８号公報 特開２０１４−１３２５０３号公報

ＢｔｏＣ型の読み放題サービスの場合，電子書籍の閲覧に係る費用は消費者が支払うことになる。これに対し，ＢｔｏＢ型の読み放題サービスの場合，電子書籍の閲覧に係る費用は，電子書籍取次業者から読み放題サービスを供与される企業（例えば，保険会社）の負担になるため，ＢｔｏＢ型の読み放題サービスには，著作権者に対する支払いを算出する仕組みに加えて，ＢｔｏＢ型の読み放題サービスを採用する保険会社などの企業が，自社商品（例えば，各種の生命保険）の売上げに繋がるベネフィットを得られる仕組みも必要になる。

そこで，本発明は，前述した内容を鑑みてなされたもので，本発明が目的とすることは，ＢｔｏＢ型の読み放題サービスシステムにおいて，ＢｔｏＢ型の読み放題サービスを採用する保険会社などの企業が，自社商品の売上げに繋がるベネフィットを得られるようにすることを目的とする。

上述した課題を解決できる本発明は，読み放題サービスを利用するユーザをユーザ認証する少なくとも一つのユーザ認証サーバと，前記ユーザが操作するユーザデバイスと，ポータルサーバとストレージサーバを含むＢｔｏＢプラットフォームとから少なくとも構成される読み放題サービスシステムである。本発明に係る前記ユーザ認証サーバは，前記ユーザをユーザ認証する処理と，ユーザ認証に成功すると，前記ポータルサーバにアクセスするための画面を前記ユーザデバイスに送信する処理を行う。本発明に係る前記ストレージサーバは，電子書籍ＩＤにより識別される複数の電子書籍を格納したストレージと，読み放題サービスの識別に用いるサービスＩＤに関連付けて，読み放題サービスの対象になる電子書籍の電子書籍ＩＤを少なくとも登録したライブラリを備える。本発明に係る前記ポータルサーバは，前記ユーザ認証サーバに対応するサービスＩＤを管理し，前記ユーザ認証サーバをリファラとするアクセスが前記ユーザデバイスからあると，リファラ情報で示される前記ユーザ認証サーバに対応するサービスＩＤをログインサービスＩＤとして保持した後，前記ログインサービスＩＤに対応する前記ライブラリに電子書籍ＩＤが登録されている電子書籍の閲覧に係る機能を提供するポータル画面をユーザデバイスへ送信する処理を行うポータル部と，前記ユーザデバイスから閲覧リクエストを受けた電子書籍を前記ユーザデバイスへストリーミング形式で配信する処理と，ストリーミング形式で配信した電子書籍の電子書籍ＩＤとこの電子書籍の閲覧範囲をユーザ名に関連付けた閲覧ログを記憶する処理を行う電子書籍配信部と，電子書籍ＩＤごとに，電子書籍ＩＤに対応する電子書籍の記載範囲とこの記載範囲に記載されている内容を示す単語を記憶し，前記閲覧ログで示される電子書籍とこの閲覧範囲に対応する記載範囲の単語を含ませたタグクラウドをログ集計結果としてユーザ名ごとに出力するログ集計部を備える。
前記タグクラウドを前記企業に提出することで，前記企業側は，前記企業の商品を購入したユーザごとに，ユーザがどのようなニーズをもっているのか把握することができる。
更に，本発明において，前記ポータル画面は，前記ログインサービスＩＤに対応する前記ライブラリに電子書籍ＩＤが登録されている電子書籍の中から，前記ユーザが入力した検索語を含む電子書籍をから検索実行する機能を前記ユーザに提供するように構成されており，前記ポータル部は，前記ポータル画面を利用した電子書籍の検索が行われると，電子書籍の検索における電子書籍の出現頻度を電子書籍ごとに管理するカウンタをインクリメントする処理を行い，前記ログ集計部は，前記サービスＩＤごとかつ前記サービスＩＤに対応した前記ライブラリに格納されている電子書籍ＩＤごとの出現頻度をログ集計結果として出力する処理を行うことが望ましい。
電子書籍の出現頻度を前記企業に提出することで，前記企業は，出現頻度の高い電子書籍の内容から，前記企業の商品を購入したユーザがもっているニーズの傾向を把握することができる。
なお，前記カウンタとして，検索された回数を電子書籍ごとに管理する検索ヒットカウンタを前記ポータル部に備えさせたことが望ましい。また，前記カウンタとして，検索結果がユーザデバイスに表示された回数を電子書籍ごとに管理する検索結果表示カウンタを前記ポータル部に備えさせたことが望ましい。

なお，本発明では，本発明に係る読み放題サービスシステムを構成するＢｔｏＢプラットフォームについても特許権を請求する。

このように，本発明に係る読み放題サービスシステムは，ＢｔｏＢ型の読み放題サービスを利用して，顧客に読み放題サービスを提供する企業が，読み放題サービスを利用した顧客が電子書籍を閲覧した箇所の内容を示すタグクラウドをユーザ名ごとに出力できるように構成されている。

読み放題サービスシステムのオーバービューを図示した図。 読み放題サービスシステムのブロック図を図示した図。 読み放題サービスシステムの動作を説明するフローを図示した図。 ポータル画面を図示した図。 検索結果を表示するポータル画面を図示した図。 電子書籍の詳細情報を表示するポータル画面を図示した図。 ユーザデバイスに表示される電子書籍を図示した図。 ポータルサーバが備えるログＤＢの内容を図示した図。 ログの収集に係る読み放題サービスシステムの動作を説明するフローを図示した図。

ここから，本発明に係る実施形態について記載する。本実施形態は，本発明の理解を容易にするためのものであり，本発明は，本実施形態に限定されるものではない。また，特に断りのない限り，図面は，本発明の理解を容易にするために描かれた模式的な図である。

図１では，本実施形態に係る読み放題サービスシステム１のオーバービューを図示している。実施形態に係る読み放題サービスシステム１は，ＢｔｏＢ型の読み放題サービスに適したシステムで，ポータルサーバ３およびストレージサーバ４を含むＢｔｏＢプラットフォーム２と，ユーザ認証サーバ５と，ユーザデバイス６から少なくとも構成され，更に，図１では，電子書籍に含まれるテキストを総なめにして検索語を探し出す電子書籍の全文検索機能を有する検索エンジン７がストレージサーバ４と接続している。

図１で図示したユーザデバイス６は，電子書籍の閲覧に利用される端末装置である。ユーザデバイス６としては，スマートフォンやタブレットコンピュータが好適な形態であるが，ウェブブラウザ６０が実装されていればユーザデバイス６の具体的な形態は任意である。なお，ユーザデバイス６には電子書籍ビューア６１が実装されている。電子書籍ビューア６１は，ウェブブラウザ６０に組み込むアドオンでもよいが，ウェブブラウザ６０とは別のアプリケーションでもよい。

図１で図示したユーザ認証サーバ５は，ＢｔｏＢプラットフォーム２を利用するユーザ８を認証する機能を備えたサーバである。ユーザ認証サーバ５は，ユーザ認証サーバ５に対応する企業の企業ＩＤを記憶し，更に，ユーザ認証で用いる情報を少なくとも記憶する。ユーザ認証サーバ５として，企業が運営しているウェブサイトを利用することが好適な形態で，企業が運営しているウェブサイトを利用する場合，ウェブサイトを利用して企業がユーザ８に提供するサービスの一つに読み放題サービスが設定される。なお，ここで言う企業とは，ＢｔｏＢプラットフォーム２を運営している電子書籍取次業者と読み放題サービスの利用契約を締結している企業を意味する。

本実施形態に係るユーザ認証サーバ５は，ユーザ認証サーバ５にアクセスしたユーザ８のユーザ認証に成功すると，ポータルサーバ３へアクセスするための画面を送信する処理を行うように構成されている。ポータルサーバ３へアクセスするための画面には，ポータルサーバ３のＵＲＬがリンク形式で貼られたアイテム（例えば，アイコン）が含まれる。ポータルサーバ３へアクセスするための画面はユーザデバイス６のウェブブラウザ６０によって表示され，ユーザ８が，ユーザデバイス６を操作してこのアイテムを選択すると，ユーザデバイス６のウェブブラウザ６０は，アイテムに貼られているＵＲＬを利用してポータルサーバ３へアクセスする。なお，ポータルサーバ３へアクセスする際，ユーザ認証サーバ５のＵＲＬがリファラ情報として，ユーザ認証サーバ５からポータルサーバ３へ送信される。

ポータルサーバ３へアクセスする際，ユーザ認証サーバ５がポータルサーバ３へ送信する情報には，リファラ情報以外の様々な情報を含ませることができる。例えば，ユーザ認証サーバ５がユーザ認証したユーザ８のユーザ名（ユーザ８のメールアドレスをユーザ名に用いるのが好適である）やユーザ認証サーバ５の署名などをこの情報に含ませることができる。

実施形態に係る読み放題サービスはＢｔｏＢ型のサービスになるため，ＢｔｏＢプラットフォーム２のストレージサーバ４には，企業ごとに個別なライブラリ４０が設けられる。ストレージサーバ４に設けられるライブラリ４０には，ライブラリ４０に対応する企業が販売している商品に関連する様々な電子書籍の電子書籍ＩＤが格納され，企業がユーザ８に提供する読み放題サービスのサービスがライブラリ４０に付加されている。

ポータルサーバ３は，ＢｔｏＢプラットフォーム２の窓口となるサーバである。ポータルサーバ３は，ユーザ認証サーバ５のＵＲＬに関連付けてサービスＩＤを記憶し，ユーザ認証サーバ５をリファラとするアクセスがあると，ユーザデバイス６から送信されたリファラ情報（ユーザ認証サーバ５のＵＲＬになる）に対応するサービスＩＤを，ユーザデバイス６とのセッションで用いるログインサービスＩＤとして保持する。ログインサービスＩＤに対応するライブラリ４０が，ユーザデバイス６とのセッションで用いるライブラリ４０になり，ポータルサーバ３は，ログインサービスＩＤに対応するライブラリ４０に電子書籍ＩＤが登録されている電子書籍の閲覧に係る機能をユーザ８に提供する。

図２では，本実施形態に係る読み放題サービスシステム１のブロック図を図示している。図２で図示したストレージサーバ４は，サーバまたはクラウドサービスを利用して構築することが可能である。ストレージサーバ４は，ＢｔｏＢプラットフォーム２に登録された様々な電子書籍の本体やメタ情報を電子書籍ＩＤに関連付けて格納したストレージ４１と，企業に提供する読み放題サービスごとに，読み放題サービスの識別に用いるサービスＩＤを付加し，サービスＩＤに対応する読み放題サービスの対象になる電子書籍の電子書籍ＩＤを少なくとも登録したライブラリ４０を備えている。ストレージ４１に格納する電子書籍の形式は様々あるが，電子書籍の形式としては，米国の標準化団体ＩＤＰＦ（International Digital Publishing Forum）が推進するＥＰＵＢが有名である。

ストレージ４１は一つまたは複数のストレージデバイスにより構築され，本実施形態には，ライブラリ４０は，仮想化技術が用いられた仮想ボリュームにより構築されている。仮想化技術の重複排除機能を利用することで，同じ電子書籍を複数のライブラリ４０に登録しても，電子書籍の本体は一つで済むため，電子書籍の記憶に必要な記憶容量を抑えることができる。ストレージ４１における電子書籍の本体へは，電子書籍ＩＤを利用して仮想ボリュームが用いられたライブラリ４０からのアクセスが可能である。

更に，ストレージサーバ４は，ライブラリ４０に格納された電子書籍を検索する処理を実行する検索エンジン７と接続している。本実施形態では，ストレージサーバ４とは別に検索エンジン７を備えているが，ストレージサーバ４が検索エンジン７を備える形態も考えられる。

ストレージサーバ４が備える検索エンジン７は，コンピュータプログラムにより実現される機能である。検索エンジン７は，ポータルサーバ３から指定されたライブラリ４０を検索範囲として，ライブラリ４０に電子書籍ＩＤが格納されている電子書籍の中から，ポータルサーバ３から引き渡された検索語に関連する電子書籍を検索した後，電子書籍の検索結果をポータルサーバ３に引き渡す処理を行う。

電子書籍の検索に書誌情報や索引情報を用いる手法もあるが，本実施形態に係る検索エンジン７は，電子書籍に含まれるテキストを総なめにして検索語を探し出す電子書籍の全文検索を電子書籍の検索を用いる。電子書籍の検索に全文検索を用いることで，検索語を含む電子書籍を漏れなく検索できるし，また，検索語が含まれる電子書籍のページを表示させることもできるので，ユーザ８が所望する電子書籍のファインダビリティ（findability）は向上する。

ＢｔｏＢプラットフォーム２に含まれるポータルサーバ３は，サーバまたはクラウドサービスを利用して構築することが可能である。図２で図示したように，ポータルサーバ３は，コンピュータプログラムにより実現される機能として，ＢｔｏＢプラットフォーム２の窓口となるポータル部３０と，ユーザデバイス６に電子書籍を配信ときに起動する電子書籍配信部３１を備えている。また，ポータルサーバ３は，コンピュータプログラムにより実現される機能として，検索エンジン７から送信された検索結果を最適化する処理を行う検索結果最適化部３２と，電子書籍をストレージサーバ４に登録する処理を行う電子書籍登録部３３を備えている。

更に，ポータルサーバ３は，電子書籍の閲覧に係るログを管理する機能として，各種ログを記憶させるログＤＢ３４（DataBase）とログ集計部３５を備える。ログ集計部３５はコンピュータプログラムにより実現される機能で，ストレージデバイスにログＤＢ３４を設けることもできるが，本実施形態では，大容量のストレージデバイスを利用してポータルサーバ３にログＤＢ３４を設けている。

ポータルサーバ３のログ集計部３５は，電子書籍ＩＤごとに，電子書籍ＩＤに対応する電子書籍の記載範囲と記載範囲に記載されている内容を示す単語を記憶し，閲覧ログで示される電子書籍とこの閲覧範囲に対応する記載範囲の単語を含ませたタグクラウドをユーザ名ごとに生成する処理を行う。フィックス型の電子書籍の場合，記載範囲や閲覧範囲の記述にページ数を用いることができるが，リフロー型の電子書籍ではページ数は決まっていないので，リフロー型の電子書籍の場合，総ページ数に対する割合（１００分率）を記載範囲や閲覧範囲の記述に用いる。

ポータル部３０は，ユーザ認証サーバ５に対応する読み放題サービスのサービスＩＤを管理し，ユーザ認証サーバ５のリファラ情報を通知するアクセスがユーザデバイス６からあると，リファラ情報で示されるユーザ認証サーバに対応するサービスＩＤをログインサービスＩＤとして保持し，ログインサービスＩＤに対応するライブラリ４０に電子書籍ＩＤが登録されている電子書籍の閲覧に係る機能を提供するポータル画面をユーザデバイス６へ送信する処理を行う。

電子書籍配信部３１は，ユーザ８が閲覧を希望した電子書籍をユーザデバイス６に配信する処理を行う機能である。電子書籍の配信形式には，ユーザ８が選択した電子書籍をユーザデバイス６にダウンロードさせるダウンロード形式と，ユーザ８が選択した電子書籍をユーザデバイス６にダウンロードさせることなく，ユーザデバイス６に実装されたウェブブラウザ６０を利用して電子書籍をオンラインで閲覧させるストリーミング形式の２つの形式がある。電子書籍の読み放題サービスはサブスクリプション型サービスの一つの形態になり，読み放題サービスの対象となる電子書籍はユーザ８のものにならないため，本実施形態に係る電子書籍配信部３１はストリーミング形式で電子書籍をユーザデバイス６に配信する。

読み放題サービスシステム１のポータルサーバ３が備える電子書籍登録部３３は，電子書籍をストレージサーバ４に登録する処理を行う機能である。電子書籍をストレージサーバ４に登録する操作を行う者は電子書籍取次業者になる。ストレージサーバ４に登録する電子書籍には，様々なメタ情報を付与することができる。本実施形態では，電子書籍の表紙を利用したアイコン，電子書籍の書誌情報などを電子書籍のメタ情報に含ませている。なお，書誌情報には，電子書籍のタイトル，電子書籍の著者，電子書籍の出版社，電子書籍の版数，電子書籍の発行年月日および電子書籍の要約などが含まれる。

電子書籍取次業者がストレージサーバ４に電子書籍を登録する際，この電子書籍の電子書籍ＩＤ，この電子書籍およびこの電子書籍を登録するライブラリ４０のサービスＩＤが電子書籍登録部３３に指定される。なお，同じ電子書籍を一つまたは複数のサービスＩＤを指定することができる。電子書籍登録部３３が，読み放題サービスシステム１の運営者が送信した電子書籍を指定されたライブラリ４０に登録する処理を行うと，指定された電子書籍（本体やメタ情報）が，指定された電子書籍ＩＤに関連付けられた状態でストレージサーバ４のストレージ４１に格納され，指定されたライブラリ４０には，指定された電子書籍ＩＤが登録される。なお，電子書籍の検索に全文検索を用いる場合，電子書籍登録部３３は電子書籍を検索エンジン７に引き渡し，検索エンジン７は，全文検索に必要なインデックス情報（電子書籍に含まれる単語になる）を記憶する。

検索結果最適化部３２は，後述する立ち位置ごとに，立ち位置に対する関連度を電子書籍ＩＤに関連付けて記憶し，検索エンジン７から検索結果が送信されると，ユーザ８が選択した立ち位置に対応する関連度を利用して，検索結果を並び替える処理を行う機能である。検索結果最適化部３２は，立ち位置に対応する関連度が高い電子書籍ほど上位に表示されるように，検索エンジン７から送信された検索結果を並び替える。

まず，電子書籍の閲覧に係る読み放題サービスシステム１の動作について説明する。図３では，電子書籍の閲覧に係る読み放題サービスシステム１の動作を図示している。読み放題サービスの利用契約を締結した企業の商品を購入したユーザ８が，ユーザデバイス６を操作して，ユーザ８が購入した商品を販売している企業に対応するユーザ認証サーバ５へログイン要求すると（Ｓ１），ユーザ認証サーバ５は，ユーザ名とパスワードを入力するように構成されたログイン画面をユーザデバイス６へ送信する（Ｓ２）。

ユーザデバイス６は，ログイン画面に入力されたユーザ名とパスワードをユーザ認証サーバ５へ送信し（Ｓ３），ユーザ認証サーバ５は，ユーザ名とパスワードがユーザデバイス６から送信されると，これらを照合することで，ユーザ認証サーバ５にアクセスしたユーザ８をユーザ認証する（Ｓ４）。ユーザ認証に成功すると，ユーザ認証サーバ５は，ポータルサーバ３にアクセスするための画面をユーザデバイス６に送信し，ユーザ８は，この画面を利用してポータルサーバ３へアクセスする（Ｓ５）。なお，ユーザ認証に失敗すると，これ以降の手順は実行されない。

企業が運営しているウェブサイトをユーザ認証サーバ５に用いる場合，ユーザ８は，企業が運営しているウェブサイトのログイン画面にユーザ名とパスワードを入力する。また，ユーザ認証に成功すると，ポータルサーバ３にアクセスするための画面として，ユーザ８に提供できるサービスの一覧を示したサービスメニューを表示するメニュー画面がこのウェブサイトからユーザデバイス６へ送信される。なお，読み放題サービスに係るメニューには，ポータルサーバ３のポータル部３０へアクセスするためのＵＲＬがリンク形式で記述されている。

ポータルサーバ３にアクセスするための画面をユーザ８が操作すると，ユーザデバイス６は，ポータルサーバ３のポータル部３０へアクセスし，この際に，ユーザ認証サーバ５のＵＲＬを含むユーザ認証サーバ５のリファラ情報がユーザデバイス６からポータルサーバ３へ通知される（Ｓ６）。ポータルサーバ３のポータル部３０は，ユーザ認証サーバ５のリファラ情報を通知するアクセスがユーザデバイス６からあると，ユーザデバイス６から通知されたユーザ認証サーバ５のリファラ情報を検証する（Ｓ７）。リファラ情報の検証には，ユーザ認証サーバ５のＵＲＬが利用される。ポータル部３０には，ＢｔｏＢプラットフォーム２の利用が許可されたユーザ認証サーバ５のＵＲＬが予め登録されており，ユーザデバイス６から通知されたリファラ情報に含まれるユーザ認証サーバ５のＵＲＬが予め登録されており，ユーザデバイス６から通知されたリファラ情報に含まれるユーザ認証サーバ５のＵＲＬがポータル部３０に予め登録されているか否かにより，ユーザ認証サーバ５のリファラ情報を検証する。

ポータルサーバ３のポータル部３０は，ユーザ認証サーバ５の正当性の検証に成功すると，リファラ情報で示されるユーザ認証サーバに対応するサービスＩＤをログインサービスＩＤとして保持した後（Ｓ８），電子書籍の閲覧に係る機能を提供するポータル画面をユーザデバイス６へ送信する（Ｓ９）。

図４は，ポータル画面３００を図示している。なお，図４で図示したポータル画面３００は一例にしか過ぎない。図４で図示したポータル画面３００は，ユーザ８が，検索語を設定し，検索語に関連する電子書籍の検索実行をできるように構成されている。なお，図４で図示したポータル画面３００は，電子書籍の検索結果を表示する検索結果表示エリア３００ｅを含む構成になっている。

電子書籍の検索結果の表示順位は，検索エンジン７から得られるスコア値に基づき決定されるのが一般的であるが，ＢｔｏＢ型の読み放題サービスの場合，知りたい立場に基づく立ち位置をユーザ８から取得し，ユーザ８の立ち位置に対する関連度に基づき電子書籍の検索結果の表示順位を決めると，ユーザ８の立ち位置に対する関連度が高い電子書籍を最初に表示できるので，読み放題サービスの利便性を高められる。

知りたい立場に基づく立ち位置は，企業が販売している商品に応じて決定される。例えば，企業が販売している商品が生命保険の場合，ユーザ８の知りたい立場としては，健康，グレーゾーン，り患直後および闘病中などがある。また，ユーザ８の知りたい立場が健康の場合，疾病予防の知識をユーザ８の知りたい立場に基づく立ち位置に利用でき，ユーザ８の知りたい立場がり患直後の場合，治療方法やセカンドオピニオンをユーザ８の知りたい立場に基づく立ち位置に利用できる。図４で図示したポータル画面３００では，興味項目を選択可能にするボタンオブジェクト３００ａを合計で１０個表示できる。

ユーザ８の知りたい立場に基づく立ち位置に加えて，図４で図示したポータル画面３００は，任意の単語を検索語として入力できるフォーム３００ｂと，検索対象（書誌または全文）を選択できる選択フォーム３００ｃと，検索実行するためのボタンオブジェクト３００ｄを含んでいる。ユーザ８が，ポータル画面３００に表示したボタンオブジェクト３００ａを利用して立ち位置を選択し，検索実行のボタンオブジェクト３００ｄを操作すると，ユーザ８が入力した検索語を用いた全文検索が実行される。

ユーザ８が，図４で図示したポータル画面３００を利用して，立ち位置の選択と検索語の入力を行ってから検索実行に係る操作を行うと，ユーザデバイス６は，ユーザ８が入力した検索語と，ユーザが選択した立ち位置を取得し（Ｓ１０），ユーザデバイス６からポータルサーバ３のポータル部３０へ検索リクエストが送信される（Ｓ１１）。なお，この検索リクエストは，ユーザ８が設定した検索語を含んでいる。

ポータルサーバ３のポータル部３０は，ユーザデバイス６から検索リクエストを受信すると，電子書籍を検索するライブラリ４０を指定する情報になるログインサービスＩＤを付加した検索リクエストをストレージサーバ４の検索エンジン７に送信する（Ｓ１２）。

ストレージサーバ４の検索エンジン７は，インデックス情報を利用して，検索リクエストで指定されたログインサービスＩＤに対応するライブラリ４０に電子書籍ＩＤが格納されている電子書籍の中から，検索リクエストの検索語を含む電子書籍を全文検索し（Ｓ１３），この検索語を含む電子書籍の検索結果すべてを含ませた検索結果リストをポータルサーバ３の検索結果最適化部３２に送信する（Ｓ１４）。検索結果に含ませる電子書籍の情報は任意でよいが，ここでは，電子書籍の電子書籍ＩＤと電子書籍のメタ情報にしている。

ポータルサーバ３の検索結果最適化部３２は，検索エンジン７から電子書籍の検索結果リストが引き渡されると，ユーザが選択した立ち位置に対応する関連度が高い電子書籍の検索結果ほど表示順位が上位になるように検索結果リストに含まれる検索結果を並び替える処理を行う（Ｓ１５）。立ち位置に対応する関連度を利用して検索結果を並び替えるのは，全文検索を行うと，全文検索で検索される電子書籍の数が膨大になり，ユーザ８が所望する電子書籍に辿り着けないケースが発生するからである。

検索結果最適化部３２は，ユーザ８が選択した立ち位置に対応する関連度が高い電子書籍の検索結果ほど上位に表示されるように検索結果リストに含まれる検索結果を並び替える際，立ち位置に対応する関連度を少なくとも利用して表示順位を電子書籍ごとに算出し，表示順位が高いほど上位になるように検索結果リストの検索結果を並び替える。

検索結果最適化部３２は，立ち位置に対応する関連度を利用して検索結果リストに含まれる検索結果を並び替えると，並び替え後の検索結果リストをポータル部３０に引き渡し，ポータル部３０とユーザデバイス６の間で，電子書籍のタイトルなどを表示する検索結果表示処理（Ｓ１６）が実行される。

検索結果表示処理（Ｓ１６）において，ポータルサーバ３のポータル部３０は，並び替え後の検索結果リストに含まれる検索結果を表示する検索結果画面を作成してユーザデバイス６へ送信する（Ｓ１６０）。ポータルサーバ３のポータル部３０には検索結果画面に一度に表示できる検索結果の表示件数が定められており，検索結果の件数が表示件数を超える場合，ポータルサーバ３のポータル部３０は，検索結果リストに含まれる検索結果を複数の検索結果画面に分けて表示する。

図５では，検索結果を表示するポータル画面３０１を図示している。図４で図示したポータル画面３００とは別に検索結果画面を生成することもできるが，図５では，図４で図示したポータル画面３００の検索結果表示エリア３００ｅに検索結果リストを表示している。図５で図示したポータル画面３０１で表示している電子書籍の検索結果には，最初の検索結果画面に含まれる電子書籍の検索結果，すなわち，表示順位がトップから順に表示件数分の電子書籍の検索結果が表示されている。図５の検索結果画面で表示している一つの検索結果３０１ａには，電子書籍の電子書籍ＩＤを関連付けたタイトル３０１ｂや，電子書籍の電子書籍ＩＤを関連付けたアイコン３０１ｃなどが含まれ，検索結果画面を移動させるためのオブジェクト３０１ｇが表示されている。図５で図示したポータル画面３０１で表示している検索結果３０１ａには，これらに加えて，電子書籍の著者３０１ｄ，電子書籍の出版社３０１ｅおよび電子書籍において検索語が含まれる箇所の文３０１ｆが電子書籍ごとに表示されており，アイコン３０１ｃ（またはタイトル３０１ｂ）を選択することで，電子書籍の詳細が表示されるようになっている。

なお，図５では，図４で図示したポータル画面３００の検索結果表示エリア３００ｅに検索結果リストを表示しているので，図５で図示したポータル画面３０１においても立ち位置の選択が可能になっている。図５で図示したポータル画面３０１において別の立ち位置が新たに選択されると，ユーザデバイス６は，この時点の検索語と，ユーザ８が新たに選択した立ち位置を含む検索リクエストをポータルサーバ３へ送信し（Ｓ１６１ａ），手順は図３のＳ１２に戻り，ユーザ８が新たに選択した立ち位置に基づく表示順位で電子書籍の検索結果が表示される。

ポータルサーバ３から送信された検索結果画面を表示した後，ユーザ８がオブジェクトｉを選択する操作を行うと，ユーザデバイス６は，画面移動リクエストをポータルサーバ３のポータル部３０へ送信する（Ｓ１６１）。画面移動リクエストには，ポータルサーバ３にリクエストする検索結果画面の番号が含まれる。ポータルサーバ３のポータル部３０は，画面移動リクエストを受信すると，画面移動リクエストの番号に対応する検索結果画面をユーザデバイス６へ送信する（Ｓ１６２）。

ポータルサーバ３から送信された検索結果画面を表示した後，ユーザ８が一つのアイコン３０１ｃ（またはタイトル３０１ｂ）を選択する操作を行うと，ユーザデバイス６は，電子書籍ビューア６１を起動させた後，選択されたアイコン３０１ｃ（またはタイトル３０１ｂ）に関連付けられている電子書籍ＩＤを含む閲覧リクエストをポータルサーバ３へ送信する（Ｓ１７）。

閲覧リクエストが送信されると，ポータルサーバ３のポータル部３０は，閲覧リクエストに含まれる電子書籍ＩＤを電子書籍配信部３１に引き渡し，電子書籍配信部３１は，ログインサービスＩＤに対応するライブラリ４０にアクセスして，閲覧リクエストに含まれる電子書籍ＩＤに対応する電子書籍の本体の送信を要求し（Ｓ１８），ストレージサーバ４は，電子書籍ＩＤに対応する電子書籍の本体をストレージ４１から読み出してポータルサーバ３へ送信する（Ｓ１９）。

電子書籍の本体をポータルサーバ３のポータル部３０が取得すると，ポータルサーバ３とユーザデバイス６の間で閲覧処理（Ｓ２０）が実行される。閲覧処理（Ｓ２０）において，ポータル部３０は電子書籍配信部３１を起動させ，電子書籍配信部３１は電子書籍の本体をストリーミング形式でユーザデバイス６に配信し（Ｓ２００），ユーザデバイス６の電子書籍ビューア６１に電子書籍を表示させる（Ｓ２０１）。ユーザデバイス６に配信する電子書籍の表示開始位置は電子書籍の最初（表紙）でもよいが，ユーザ８が入力した検索語を含む電子書籍の箇所（例えば，段落）を電子書籍の表示開始位置にしてもよい。電子書籍配信部３１は電子書籍の本体をストリーミング形式でユーザデバイス６に配信した後，ユーザ８が電子書籍のページを移動させる操作を行い，ユーザデバイス６からページ移動リクエストがあると（Ｓ２０２），ページ移動リクエストで示される位置に対応する電子書籍の内容をユーザデバイス６に配信する。

図６では，ユーザデバイス６に表示される電子書籍の閲覧画面３０２を図示している。電子書籍の閲覧画面３０２には，電子書籍のコンテンツ３０２ａに加え，電子書籍の表示内容を操作するコントロールパネル３０２ｂと詳細表示ボタン３０２ｃが表示されている。

図６で図示した詳細表示ボタン３０２ｃが選択されると，電子書籍ビューア６１が起動しているユーザデバイス５は，電子書籍の閲覧画面３０２で表示している電子書籍の電子書籍ＩＤを含む詳細表示リクエストをポータルサーバ３のポータル部３０へ送信し（Ｓ２０３），ポータルサーバ３のポータル部３０は，詳細表示リクエストの電子書籍ＩＤで識別される電子書籍の詳細情報を表示する詳細表示画面をユーザデバイス６へ送信する（Ｓ２０４）。

図７では，電子書籍の詳細表示画面３０３を図示している。図７では，図６で図示した閲覧画面３０２の上に電子書籍の詳細表示画面３０３を表示している。詳細表示画面３０３に表示した詳細情報３０３ａは，電子書籍ＩＤが関連付けられたタイトル３０３ｂ，電子書籍ＩＤが関連付けられたアイコン３０３ｃ，電子書籍の著者３０３ｄ，電子書籍の出版社３０３ｅ，電子書籍の版数３０３ｆ，電子書籍の発行日３０３ｇおよび電子書籍の要約３０３ｈが含まれる。また，詳細表示画面３０３は，電子書籍の詳細情報３０３ａに加え，詳細情報３０３ａに対応する電子書籍を販売している電子書店へ画面を移行させる書籍購入ボタン３０３ｉを含んでいる。なお，本実施形態では，詳細表示画面３０３を閉じる操作は，電子書籍の閲覧画面３０２の詳細表示ボタン３０２ｃを選択する操作にしている。

これまで説明したように，本実施形態に係る読み放題サービスシステム１では，ＢｔｏＢプラットフォーム２にアクセスしたユーザ８がオンラインで利用できるライブラリ４０は，ユーザ８がアクセスしたユーザ認証サーバ５の企業に対応するライブラリ４０に限定される。例えば，生保Ａに対応するユーザ認証サーバ５によりユーザ認証に成功したユーザ８（左側のユーザ８）に対しては，ユーザ８が契約を締結した生保Ａに対応するライブラリ４０に電子書籍ＩＤが格納された電子書籍が読み放題になる。また，生保Ｂに対応するユーザ認証サーバ５によりユーザ認証に成功したユーザ８（右側のユーザ８）に対しては，ユーザ８が契約を締結した生保Ｂに対応するライブラリ４０に電子書籍ＩＤが格納された電子書籍が読み放題になる。

なお，これまでの説明では，電子書籍の全文検索について記載しているが，全文検索以外の手法でも，本実施形態に係る読み放題サービスシステム１を構成できる。また，検索結果を並び替えする処理を省くように，本実施形態に係る読み放題サービスシステム１を構成することもできる。更に，ストレージサーバ４とは別に検索エンジン７を配置するように，本実施形態に係る読み放題サービスシステム１を構成することもできる。

ここから，電子書籍の閲覧に係るログを管理する機能について説明する。図８は，ポータルサーバ３が備えるログＤＢ３４の内容を図示している。図８（ａ）では，ログＤＢ３４に格納されるファイルを図示している。図８（ａ）で図示したように，ログＤＢ３４には，検索ログを登録する検索ログファイル３４０，電子書籍が検索された回数である検索ヒット回数のカウントに用いる検索ヒット回数テーブル３４１，検索表示回数のカウントに用いる検索表示回数テーブル３４２および閲覧ログの登録に用いる閲覧ログファイル３４３が設けられる。

図８（ｂ）では，検索ログファイル３４０に登録される検索ログの構造を図示している。検索ログファイル３４０は，ポータルサーバ３のポータル部３０が，ユーザ８が検索を実行するごとに検索ログを追加するログファイルである。検索ログファイル３４０に追加する検索ログは，検索を実行したユーザ８のユーザ名と，このユーザ８が検索に用いた検索語を含む。なお，検索ログには検索日時などを含ませることができる。

図８（ｃ）では，検索ヒットテーブルのレコード構造を図示している。検索ヒット回数テーブル３４１は，電子書籍が検索された回数である検索ヒット回数を記憶するテーブルである。検索ヒット回数テーブル３４１には，サービスＩＤと電子書籍ＩＤにより識別されるレコードが設けられ，このレコードは，ポータルサーバ３のポータル部３０によって操作される検索ヒットカウンタを含んでいる。検索ヒット回数テーブル３４１に設けられたレコードは，サービスＩＤと電子書籍ＩＤにより識別されるので，同じ電子書籍が二つのライブラリ４０に登録されている場合，この電子書籍ＩＤそれぞれに対応する二つのレコードが検索ヒット回数テーブル３４１に設けられる。

図８（ｄ）では，検索表示回数テーブル３４２のレコード構造を図示している。検索表示回数テーブル３４２は，ユーザデバイス６に検索結果が表示された回数を記憶するテーブルである。検索表示回数テーブル３４２には，サービスＩＤと電子書籍ＩＤにより識別されるレコードが設けられ，このレコードは，ポータルサーバ３のポータル部３０によって操作される検索表示カウンタを含んでいる。検索表示回数テーブル３４２に設けられたレコードは，サービスＩＤと電子書籍ＩＤにより識別されるので，同じ電子書籍が二つのライブラリ４０に登録されている場合，この電子書籍ＩＤそれぞれに対応する二つのレコードが検索表示回数テーブル３４２に設けられる。

図８（ｅ）では，閲覧ログファイル３４３に登録される閲覧ログの構造を図示している。閲覧ログファイル３４３は，ポータルサーバ３の電子書籍配信部３１が，ユーザデバイス６に電子書籍を表示するごとに閲覧ログを追加するログファイルである。閲覧ログファイル３４３に追加する閲覧ログは，電子書籍を閲覧したユーザ８のユーザ名，このユーザ８が閲覧した電子書籍の電子書籍ＩＤ，および，電子書籍の閲覧範囲を含む。電子書籍の閲覧範囲には，ユーザ８が電子書籍を閲覧したときの開始位置と終了位置を含み，開始位置および終了位置はページ数で記述してもよく，総ページ数に対する割合（１００分率）で開始位置および終了位置を記述してもよい。

本実施形態にて，検索ログファイル３４０，検索ヒット回数テーブル３４１および検索表示回数テーブル３４２はポータル部３０によって更新され，閲覧ログファイル３４３は，電子書籍配信部３１によって更新される。

図９では，ログの収集に係る読み放題サービスシステムの動作を説明するフローを図示している。図３のＳ７において，ポータルサーバ３のポータル部３０は，ユーザ認証サーバ５の正当性の検証に成功すると，図３のＳ８において，ログインサービスＩＤに加え，ユーザ認証に成功したユーザ８のユーザ名を取得する。なお，ユーザ認証に成功したユーザ８のユーザ名は，ユーザ認証サーバ５がユーザデバイス６へ送信したＵＲＬのパラメータに含ませることができる。

また，図３のＳ１１において，ユーザデバイス６から検索リクエストが送信されると，ポータルサーバ３のポータル部３０は，図３のＳ８で取得したユーザ名と検索リクエストから取得した検索語を含む検索ログを検索ログファイル３４０に登録する（Ｓ３０）。

また，図３のＳ１５が実行された後，並び替え後の検索結果リストが検索結果最適化部３２から引き渡されると，ポータルサーバ３のポータル部３０は，検索結果リストに検索結果が含まれる電子書籍の電子書籍ＩＤごとに，ログインサービスＩＤとこの電子書籍ＩＤで一意に決まる検索ヒット回数テーブル３４１のレコードの検索ヒットカウンタを一つインクリメントする（Ｓ３１）。

また，図３のＳ１６０を実行する前に，ポータルサーバ３のポータル部３０は，ユーザデバイス６に送信する検索結果画面に検索結果が含まれる電子書籍の電子書籍ＩＤごとに，ログインサービスＩＤとこの電子書籍ＩＤで一意に決まる検索表示回数テーブル３４２のレコードの検索表示カウンタを一つインクリメントする（Ｓ３２）。更に，図３のＳ１６２を実行する前に，ポータルサーバ３のポータル部３０は，ユーザデバイス６に送信する検索結果画面に検索結果が含まれる電子書籍の電子書籍ＩＤごとに，ログインサービスＩＤとこの電子書籍ＩＤで一意に決まる検索表示回数テーブル３４２のレコードの検索表示カウンタを一つインクリメントする（Ｓ３３）。

また，図３のＳ２０において，ユーザ８が電子書籍のページを移動させる操作を行うと，電子書籍配信部３１は，図３のＳ８で取得したユーザ名，ユーザ８が閲覧した電子書籍の電子書籍ＩＤ，および，電子書籍の閲覧範囲を含む閲覧ログを閲覧ログファイル３４３に追加する（Ｓ３４）。

最後に，ポータルサーバ３が備えるログ集計部３５について説明する。ログ集計部３５は，ＢｔｏＢプラットフォーム２に電子書籍を提供した著作権者に対して支払うことになるロイヤリティの基になる著作権者向けのログ集計結果と，ＢｔｏＢプラットフォーム２の利用が許可されている企業に対するベネットフィットとなる企業向けのログ集計結果を出力する機能を有する。

本実施形態において，ポータルサーバ３が備えるログ集計部３５は，閲覧ログファイル３４３に登録されている閲覧ログごとに閲覧範囲から閲覧量を求め，閲覧ログファイル３４３に閲覧ログが登録されている電子書籍ＩＤと，この電子書籍ＩＤに係る閲覧量の合計値を対応付けた情報を著作権者向けのログ集計結果として出力する。

本実施形態において，ポータルサーバ３が備えるログ集計部３５は，検索ヒットテーブルと検索結果表示テーブルを参照し，ライブラリ４０に付加されたサービスＩＤごと，かつ，ライブラリ４０に登録されている電子書籍ＩＤごとに，検索ヒットカウンタの値と検索結果表示カウンタの値を対応付けたテーブルを企業向け集計結果の一つとして出力する。電子書籍ＩＤごとに，検索ヒットカウンタの値と検索結果表示カウンタの値を対応付けたテーブルを用意しておくことで，サービスＩＤに対応する読み放題サービスをユーザ８に提供する企業は，企業の商品を購入したユーザ８が興味を抱いている内容を推測する足掛かりが得られる。

更に，ポータルサーバ３が備えるログ集計部３５は，ユーザ名ごとに，ユーザ名に対応するユーザ８がもっているニーズを表すタグクラウド（キーワードクラウドとも称される。）を生成し，このタグクラウドを企業向けのログ集計結果を出力する。

タグクラウドを生成するために，電子書籍ＩＤごとに，電子書籍ＩＤに対応する電子書籍の記載範囲と記載範囲に記載されている内容を示す単語が，ポータルサーバ３のログ集計部３５に予め登録される。そして，タグクラウドの生成が指示されると，ポータルサーバ３のログ集計部３５は，閲覧ログファイル３４３に登録されている閲覧ログごとに，閲覧ログの電子書籍ＩＤで示される電子書籍とこの閲覧範囲に対応する記載範囲を特定し，特定した記載範囲の単語をユーザ名に関連付けて一時的に記憶した後，ユーザ名ごとに単語を集めることでユーザ名ごとのタグクラウドを生成する。

タグクラウドでは，出現頻度が高いほど単語のフォントサイズを大きくするのが一般的で，ユーザ名ごとにタグクラウドを対応付けた情報を用意しておけば，企業の営業などからユーザ８に係る情報の提供要求を受けたとき電子書籍取次業者はこのユーザ８に対応するタグクラウドを企業に提供できる。

１ 読み放題サービスシステム
２ ＢｔｏＢプラットフォーム
３ ポータルサーバ
３０ ポータル部
３１ 電子書籍配信部
３２ 検索結果最適化部
３３ 電子書籍登録部
３４ ログＤＢ
３４０ 検索ログファイル
３４１ 検索ヒット回数テーブル
３４２ 検索表示回数テーブル
３４３ 閲覧ログファイル
３５ ログ集計部
４ ストレージサーバ
４０ ライブラリ
４１ ストレージ
５ ユーザ認証サーバ
６ ユーザデバイス
６０ ウェブブラウザ
６１ 電子書籍ビューア
７ 検索エンジン
８ ユーザ

Claims (5)

1. 読み放題サービスを利用するユーザをユーザ認証する少なくとも一つのユーザ認証サーバと，前記ユーザが操作するユーザデバイスと，ポータルサーバとストレージサーバを含むＢｔｏＢプラットフォームとから少なくとも構成され，
   前記ユーザ認証サーバは，前記ユーザをユーザ認証する処理と，ユーザ認証に成功すると，前記ポータルサーバにアクセスするための画面を前記ユーザデバイスに送信する処理を行い，
   前記ストレージサーバは，電子書籍ＩＤにより識別される複数の電子書籍を格納したストレージと，読み放題サービスの識別に用いるサービスＩＤに関連付けて，読み放題サービスの対象になる電子書籍の電子書籍ＩＤを少なくとも登録したライブラリを備え，
   前記ポータルサーバは，前記ユーザ認証サーバに対応するサービスＩＤを管理し，前記ユーザ認証サーバをリファラとするアクセスが前記ユーザデバイスからあると，リファラ情報で示される前記ユーザ認証サーバに対応するサービスＩＤをログインサービスＩＤとして保持した後，前記ログインサービスＩＤに対応する前記ライブラリに電子書籍ＩＤが登録されている電子書籍の閲覧に係る機能を提供するポータル画面をユーザデバイスへ送信する処理を行うポータル部と，前記ユーザデバイスから閲覧リクエストを受けた電子書籍を前記ユーザデバイスへストリーミング形式で配信する処理と，ストリーミング形式で配信した電子書籍の電子書籍ＩＤとこの電子書籍の閲覧範囲をユーザ名に関連付けた閲覧ログを記憶する処理を行う電子書籍配信部と，電子書籍ＩＤごとに，電子書籍ＩＤに対応する電子書籍の記載範囲とこの記載範囲に記載されている内容を示す単語を記憶し，前記閲覧ログで示される電子書籍とこの閲覧範囲に対応する記載範囲の単語を含ませたタグクラウドをログ集計結果としてユーザ名ごとに出力するログ集計部を備える，
   ことを特徴とする読み放題サービスシステム。
2. 前記ポータル画面は，前記ログインサービスＩＤに対応する前記ライブラリに電子書籍ＩＤが登録されている電子書籍の中から，前記ユーザが入力した検索語を含む電子書籍をから検索実行する機能を前記ユーザに提供するように構成されており，前記ポータル部は，前記ポータル画面を利用した電子書籍の検索が行われると，電子書籍の検索における電子書籍の出現頻度を電子書籍ごとに管理するカウンタをインクリメントする処理を行い，前記ログ集計部は，前記サービスＩＤごとかつ前記サービスＩＤに対応した前記ライブラリに格納されている電子書籍ＩＤごとの出現頻度をログ集計結果として出力する処理を行う，
   ことを特徴とする，請求項１に記載した読み放題サービスシステム。
3. 前記カウンタとして，検索された回数を電子書籍ＩＤごとに管理する検索ヒットカウンタを前記ポータル部に備えさせた，
   ことを特徴とする，請求項２に記載した読み放題サービスシステム。
4. 前記カウンタとして，検索結果がユーザデバイスに表示された回数を電子書籍ＩＤごとに管理する検索結果表示カウンタを前記ポータル部に備えさた，
   ことを特徴とする，請求項２または請求項３に記載した読み放題サービスシステム。
5. 請求項１から請求項４のいずれか一項に記載した読み放題サービスシステムを構成するＢｔｏＢプラットフォーム。