JP7047159B1 - プログラム及びサーバ - Google Patents

Abstract

【課題】ユーザにとって利便性の高い情報提供方法を実現すること。【解決手段】情報提供方法は、少なくとも１つのアイテムを公開する旨の公開指示を、前記第１ユーザの第１通信装置から受信し、前記公開指示に基づいて、前記公開指示により指定された少なくとも１つの公開アイテムを含み、前記第１ユーザに関連付けられた公開リストを生成又は更新し、前記公開アイテムと所定の関係を有する少なくとも１つの関連アイテムを、前記公開指示の有無にかかわらず前記公開リストに追加すること、を含む。【選択図】図９

Description

本発明の一実施形態は、情報提供方法、サーバ及びプログラムに関する。

従来、コンピュータ技術及びネットワーク技術の飛躍的向上に伴い、ｅコマース（電子商取引）が急速に発展している。特に、オンラインショップなどを運営する企業と一般消費者との間で行われる商取引は、ＢｔｏＣ（Ｂｕｓｉｎｅｓｓ ｔｏ Ｃｏｎｓｕｍｅｒ）と呼ばれ、日常生活に広く浸透している。ユーザは、コンピュータやスマートフォンを用いて自宅からオンラインショップにアクセスし、ネットワークを介して手軽に商品を購入することが可能になっている。

オンラインショップ等で商品を選択する際、購入候補の商品を保留するための機能として「ほしいものリスト」や「お気に入りリスト」などが利用される。ユーザは、購入に迷った商品や今後購入する予定の商品などをリストに入れておけば、いつでもリストに入った商品にアクセスして購入手続に進むことができる。最近では、「ほしいものリスト」を他のユーザに公開することにより、リストを公開したユーザに対して、他のユーザがリスト内の商品をプレゼントできる機能を備えたオンラインシステムも開発されている（例えば、特許文献１）。

特開２０１３－１０９７５７号公報

上記従来技術では、ユーザが「ほしいものリスト」に入れた商品しか他のユーザに公開されない。そのため、ユーザは、ほしい商品をこまめにチェックしてリストを更新する必要があった。しかしながら、日々新しい商品が公開される状況において、こまめに商品をチェックしてリストを更新することは困難である。このように、既存のオンラインシステムにはさらに改善の余地があった。

本発明の一実施形態の課題は、上記問題に鑑みてなされたものであり、ユーザにとって利便性の高い情報提供方法を実現することにある。

本発明の一実施形態の情報提供方法は、少なくとも１つのアイテムを公開する旨の公開指示を、前記第１ユーザの第１通信装置から受信し、前記公開指示に基づいて、前記公開指示により指定された少なくとも１つの公開アイテムを含み、前記第１ユーザに関連付けられた公開リストを生成又は更新し、前記公開アイテムと所定の関係を有する少なくとも１つの関連アイテムを、前記公開指示の有無にかかわらず前記公開リストに追加すること、を含む。

前記公開指示は、第１ユーザに関連付けられた保持リストに含まれる保持アイテムの少なくとも１つを公開する旨の指示であってもよい。

前記情報提供方法は、第２ユーザの要求に基づいて、前記公開リストに関する情報を前記第２ユーザの第２通信装置に送信し、前記公開リストに含まれる前記公開アイテムの少なくとも１つを購入する旨の購入指示を前記第２通信装置から受信し、前記購入指示により指定された購入アイテムを前記第１ユーザに関連付けられた購入リストに追加すること、をさらに含んでいてもよい。

前記購入アイテムが前記公開アイテムである場合と前記関連アイテムである場合とで購入の価格が異なっていてもよい。

前記情報提供方法は、前記公開アイテムが購入された旨の通知を前記第１通信装置に送信することをさらに含んでいてもよい。

前記情報提供方法は、前記第１ユーザと所定の関係を有する第３ユーザの第３通信装置の表示部に前記公開リストに基づく画像を表示することをさらに含んでもよい。このとき、前記公開リストに基づく画像は、前記公開アイテムの少なくとも１つが購入された旨の表示、又は、過去に購入された前記公開アイテムの数を含んでいてもよい。

前記購入アイテムが前記公開アイテムである場合と前記関連アイテムである場合とで前記公開アイテムが購入された旨の通知の態様が異なっていてもよい。

前記保持リストに含まれる前記保持アイテムは、認可前アイテムを含んでもよい。このとき、前記情報提供方法は、前記認可前アイテムの少なくとも１つを認可後に購入する旨の予約購入指示を前記第１通信装置から受信し、前記予約購入指示に基づいて、前記予約購入指示により指定された少なくとも１つの予約購入アイテムを含み、前記第１ユーザに関連付けられた予約購入リストを生成又は更新すること、をさらに含んでいてもよい。

前記公開リストに含まれる前記公開アイテム又は前記関連アイテムは、認可前アイテムを含んでもよい。このとき、前記情報提供方法は、前記認可前アイテムの少なくとも１つを購入する旨の予約購入指示を前記第２通信装置から受信し、前記予約購入指示に基づいて、前記予約購入指示により指定された少なくとも１つの予約購入アイテムを含み、前記第１ユーザに関連付けられた予約購入リストを生成又は更新すること、をさらに含んでいてもよい。

前記情報提供方法は、前記予約購入指示を前記第２通信装置から受信した旨の通知を前記第１通信装置に送信することをさらに含んでいてもよい。

前記情報提供方法は、前記第１ユーザと所定の関係を有する第３ユーザの第３通信装置の表示部に前記公開リストに基づく画像を表示することをさらに含んでもよい。このとき、前記公開リストに基づく画像は、前記認可前アイテムの少なくとも１つが予約購入された旨の表示、又は、過去に予約購入された前記認可前アイテムの数を含んでいてもよい。

前記情報提供方法は、前記購入アイテムと前記予約購入アイテムとで前記予約購入指示を前記第２通信装置から受信した旨の通知の態様が異なっていてもよい。

前記情報提供方法は、前記予約購入アイテムのうち公式アイテムとして認可された予約購入アイテムを前記第１ユーザに関連付けられた前記購入リストに追加すること、をさらに含んでいてもよい。

前記情報提供方法は、前記購入アイテムと前記予約購入アイテムとで購入の価格が異なっていてもよい。

前記情報提供方法は、前記公開リストに含まれる前記公開アイテムの少なくとも１つを、予め設定されたタイミングで購入する旨の事前購入指示を前記第２通信装置から受信し、前記事前購入指示により指定された事前購入アイテムを、前記予め設定されたタイミングで前記第１ユーザに関連付けられた前記購入リストに追加すること、をさらに含んでいてもよい。

前記情報提供方法は、データベースに登録された複数のアイテムの少なくとも１つを保持する旨の保持指示を前記第１ユーザの第１通信装置から受信し、前記保持指示に基づいて、前記保持指示により指定された少なくとも１つの保持アイテムを含み、前記第１ユーザに関連付けられた前記保持リストを生成又は更新すること、をさらに含んでいてもよい。

前記情報提供方法は、新たなアイテムを前記データベースに登録することをさらに含んでいてもよい。このとき、前記情報提供方法は、前記関連アイテムが前記新たなアイテムとして前記データベースに登録されると、前記関連アイテムを前記公開リストに追加すること、をさらに含んでいてもよい。

前記情報提供方法は、前記公開リストが生成又は更新されると、前記公開リストの生成又は更新を通知する通知指示を、前記第１ユーザと所定の関係を有する第３ユーザの第３通信装置に送信すること、をさらに含んでいてもよい。

前記情報提供方法は、前記公開リストが生成又は更新されると、前記公開リストの生成又は更新を通知する通知指示を、前記第１ユーザと所定の関係を有する第３ユーザの第３通信装置に送信すること、をさらに含んでいてもよい。

前記公開アイテムが電子書籍である場合において、前記関連アイテムは、前記公開アイテムの最新分、修正分もしくは不足分、前記公開アイテムに付随する商品、又は、前記公開アイテムの代替品を含んでいてもよい。

本発明の一実施形態のサーバは、前述のいずれかの情報提供方法を実行する制御部を備える。

本発明の一実施形態のプログラムは、前述のいずれかの情報提供方法をコンピュータに実行させる。

本発明の一実施形態によれば、ユーザにとって利便性の高い情報提供方法を実現することができる。

本発明の一実施形態における通信システムの構成を示すブロック図である。 本発明の一実施形態における第１通信装置の構成を示すブロック図である。 本発明の一実施形態におけるサーバの構成を示すブロック図である。 本発明の一実施形態におけるサーバの記憶部に格納されるデータテーブルの一例を示す図である。 本発明の一実施形態におけるサーバが備える情報提供機能の構成を示すブロック図である。 本発明の一実施形態における保持リスト管理部が管理する保持リストの構成の一例を示す図である。 本発明の一実施形態における公開リスト管理部が管理する公開リストの構成の一例を示す図である。 本発明の一実施形態における購入リスト管理部が管理する購入リストの構成の一例を示す図である。 本発明の一実施形態におけるサーバの制御部が実行する情報提供方法を示すフローチャートである。 第１ユーザの第１通信装置に表示されるＵＩ画像の一例を示す図である。 第１ユーザの第１通信装置に表示されるＵＩ画像の一例を示す図である。 第２ユーザの第２通信装置に表示されるＵＩ画像の一例を示す図である。 第２ユーザの第２通信装置に表示されるＵＩ画像の一例を示す図である。 本発明の一実施形態におけるサーバの制御部が実行する情報提供方法を示すフローチャートである。 第２ユーザの第２通信装置に表示されるＵＩ画像の一例を示す図である。 第１ユーザの第１通信装置に表示されるＵＩ画像の一例を示す図である。 第１ユーザの第１通信装置に表示されるＵＩ画像の一例を示す図である。 第３ユーザの第３通信装置に表示されるＵＩ画像の一例を示す図である。 本発明の一実施形態におけるサーバの記憶部に格納されるデータテーブルの一例を示す図である。 本発明の一実施形態におけるサーバが備える情報提供機能の構成を示すブロック図である。 第１ユーザの第１通信装置に表示されるＵＩ画像の一例を示す図である。 第１ユーザの第１通信装置に表示されるＵＩ画像の一例を示す図である。 第２ユーザの第２通信装置に表示されるＵＩ画像の一例を示す図である。 第１ユーザの第１通信装置に表示されるＵＩ画像の一例を示す図である。 本発明の一実施形態におけるサーバの記憶部に格納されるデータテーブルの一例を示す図である。 本発明の一実施形態におけるサーバが備える情報提供機能の構成を示すブロック図である。 第２ユーザの第２通信装置に表示されるＵＩ画像の一例を示す図である。 第２ユーザの第２通信装置に表示されるＵＩ画像の一例を示す図である。

以下、図面を参照して本発明の一実施形態である情報提供方法及びプログラム（具体的には、ユーザに電子書籍を提供する方法及びプログラム）について説明する。但し、本発明は、多くの異なる態様で実施することが可能である。すなわち、本発明は、以下に示す実施形態の記載内容に限定して解釈されない。本実施の形態で参照する図面において、同一部分又は同様の機能を有する部分には、同一の符号又は同一の符号の後にアルファベットを付した符号を用い、その繰り返しの説明は省略する。

本明細書及び特許請求の範囲において、各用語は、次のように定義される。

「ユーザ」とは、事業者が提供する特定のサービスを利用可能である者をいう。例えば、事業者が電子書籍の提供を実施している場合に、ユーザは、電子書籍の閲覧又は購入が可能な者をいう。通常、ユーザは、事業者が提供する特定のサービスを受けるために、その事業者に対してユーザ登録を行う。

「アイテム」とは、取引又はサービスの対象となる商品又はコンテンツである。アイテムは、物理的に存在する物品であってもよいし、電子的に存在するデジタルコンテンツであってもよい。例えば、本発明の一実施形態の情報提供方法では、電子書籍をアイテムとして取り扱うことができる。

アイテムが電子書籍である場合、購入する単位は、任意に設定することができる。例えば、「話」又は「巻」ごとに購入可能としてもよいし、作品単位で購入可能としてもよい。また、購入する「話」又は「巻」を指定してまとめて購入したり、指定した「話」から最新の「話」までをまとめて購入したりすることも可能である。さらに、アイテムを他のユーザにプレゼントする場合も、購入する単位は、任意に設定することができる。

「リスト」とは、所定の用途のために１又は複数のアイテムを格納するテーブルである。リストは、各ユーザに関連付けられて記憶部に記憶される。リストは、各ユーザに関連付けられた複数のリストが生成されてもよいし、各ユーザに関連付けられたアイテムの集合体として１つのリストが生成されてもよい。所定の用途は、各アイテムに関連付けられたフラグで設定されていてもよい。すなわち、データベースに登録されたアイテムのうち所定の用途を示すフラグが設定された１又は複数のアイテムを含むテーブルが「リスト」である。例えば、後述する「公開リスト」は、データベースに登録されたアイテムのうち「公開」を示すフラグが設定された１又は複数のアイテムを含むテーブルに相当する。

「保持リスト」とは、ユーザが購入を検討しているアイテム、又は、購入予定のアイテムを一時的に保持するためのテーブルである。すなわち、保持リストは、ユーザが「保持」する旨の指示を設定したアイテムを格納するテーブルである。具体的には、保持リストは、各ユーザに関連付けられ、各ユーザによって選択されたアイテムに関する情報（例えば、作品名、作者、購入価格、商品説明など）を格納する。保持リストは、いわゆる「ほしいものリスト」又は「お気に入りリスト」に対応する。保持リストは、各ユーザに関連付けられて、サーバ５００の記憶部５０２に格納される。保持リストに格納されたアイテムを「保持アイテム」という。

「公開リスト」とは、ユーザが他のユーザに購入を期待するアイテムを一時的に保持するためのテーブルである。すなわち、公開リストは、ユーザが「公開」する旨の指示を設定したアイテムを格納するテーブルである。具体的には、公開リストは、各ユーザに関連付けられ、各ユーザによって選択されたアイテムに関する情報を格納する。公開リストは、各ユーザに関連付けられて、サーバ５００の記憶部５０２に格納される。公開リストは、上述した保持リストとは別のテーブルとして記憶部５０２に格納されてもよいし、保持リストの一部を公開リストとして扱ってもよい。後者の場合、保持リストに含まれるアイテムのうち「公開」に設定されたアイテムのみを含むリストが公開リストに相当する。公開リストに格納されたアイテムを「公開アイテム」という。

「購入リスト」とは、ユーザが購入したアイテム（他のユーザが購入したアイテムを含む）を保持するためのテーブルである。すなわち、購入リストは、「購入済み」である旨を設定したアイテムを格納するテーブルである。具体的には、購入リストは、各ユーザに関連付けられ、購入されたアイテム（ユーザが所有権又は閲覧権限を有するアイテム）に関する情報を格納する。購入リストは、各ユーザに関連付けられて、サーバ５００の記憶部５０２に格納される。購入リストに格納されたアイテムを「購入アイテム」という。

「予約購入リスト」とは、ユーザが購入を予約した認可前アイテム（他のユーザが購入を予約した認可前アイテムを含む）を一時的に保持するためのテーブルである。換言すれば、予約購入リストは、ユーザが認可後に購入する旨の意思を示したアイテムを格納するテーブルである。具体的には、予約購入リストは、各ユーザに関連付けられ、購入が予約された認可前アイテムに関する情報を格納する。予約購入リストは、各ユーザに関連付けられて、サーバ５００の記憶部５０２に格納される。予約購入リストに格納されたアイテムを「予約購入アイテム」という。

「認可前アイテム」とは、サービスの対象となるアイテムのうち、公式アイテム（認可後アイテム）としてサービス提供者に認可される前のアイテムである。認可前アイテムは、無料（又は、実質的に無料）で公開される。例えば、アイテムが電子書籍である場合、認可前アイテムは、公式のサポートを受けない作者によって作成され、無料で閲覧可能になっているアイテムを指す。認可前アイテムは、所定の条件を満たしたとき、公式アイテムとして承認されるとともに取引対象となる。したがって、上述の予約購入アイテムは、認可前アイテムである期間は、購入することができず、公式アイテムとして承認された後、購入可能となる。

「事前購入リスト」とは、ユーザが購入予定日等の購入タイミングを予め設定して購入したアイテム（他のユーザが購入予定日等を予め設定して購入したアイテムを含む）を保持するためのテーブルである。すなわち、事前購入リストは、購入タイミングを設定して購入する旨の意思を示したアイテムを格納するテーブルである。具体的には、事前購入リストは、各ユーザに関連付けられ、購入が予定されたアイテムに関する情報を格納する。事前購入リストは、各ユーザに関連付けられて、サーバ５００の記憶部５０２に格納される。事前購入リストに格納されたアイテムを「事前購入アイテム」という。

「価格リスト」とは、データベースに登録されたアイテムごとに設定された購入価格を管理するためのテーブルである。例えば、アイテムが電子書籍である場合、購入価格は、「巻」ごとに設定されてもよいし、「話」ごとに設定されてもよい。また、価格リストは、アイテムごとに割引率又は割引後の購入価格を含んでいてもよい。例えば、予約購入指示又は事前購入指示により購入されたアイテムは、通常の購入指示により購入されたアイテムよりも安くなるように、割引率又は割引後の購入価格が設定されていてもよい。価格リストは、サーバ５００の記憶部５０２に格納される。

「スケジュールリスト」とは、アイテムに関する様々な期間又は期限（すなわち、スケジュール）を管理するためのテーブルである。スケジュールリストは、各ユーザに関連付けられていてもよい。この場合、スケジュールリストは、例えば、事前購入アイテムに設定された購入予定日、購入アイテムに関連する関連アイテムの発行日（発売日）などを格納してもよい。また、スケジュールリストは、将来的に発売されるアイテムの発行日など、データベース６００に登録されるアイテム全般のスケジュールに関する情報を確認してもよい。スケジュールリストは、各ユーザに関連付けられて、サーバ５００の記憶部５０２に格納される。

「関連アイテム」とは、公開アイテムと所定の関係を有するアイテムである。関連アイテムに関して「所定の関係」は、アイテムの種類に応じて任意に設定することができる。例えば、関連アイテムは、公開アイテムに付随するアイテム、公開アイテムを含む同一シリーズ（同一作品）のアイテム等であってもよい。公開アイテムが電子書籍である場合、関連アイテムとしては、例えば、公開アイテムの最新分（新しく刊行されたもの）、修正分（誤植等を修正したもの）もしくは不足分（既に発売されているもののまだ購入していないもの）、公開アイテムに付随する商品（登場するキャラクタのグッズなど）、又は、公開アイテムの代替品（公開アイテムとは異なる推薦品）を含み得る。公開アイテムの代替品は、例えば、ユーザの過去の購入履歴を教師データとする機械学習（例えば、ディープラーニング）を利用した解析により選定することができる。

「プログラム」とは、プロセッサ及びメモリを備えたコンピュータにおいてプロセッサより実行される命令又は命令群を指す。「コンピュータ」は、プログラムの実行主体を指す総称である。例えば、サーバ（又はクライアント）によりプログラムが実行される場合、「コンピュータ」は、サーバ（又はクライアント）を指す。また、サーバとクライアントとの間の分散処理により「プログラム」が実行される場合、「コンピュータ」は、サーバ及びクライアントの両方を含む。この場合、「プログラム」は、「サーバで実行されるプログラム」及び「クライアントで実行されるプログラム」を含む。「プログラム」が、複数のサーバ間で分散処理される場合も同様に、「コンピュータ」は、複数のサーバを含み、「プログラム」は、各サーバで実行される各プログラムを含む。

＜第１実施形態＞
［通信システムの構成］
図１は、本発明の一実施形態における通信システム１０００の構成を示すブロック図である。通信システム１０００は、第１通信装置１００、第２通信装置２００及び第３通信装置３００及びサーバ５００を有する。第１通信装置１００、第２通信装置２００、第３通信装置３００及びサーバ５００は、インターネット、通信回線などのネットワークＮＷに接続される。通信システム１０００は、クライアントである第１通信装置１００、第２通信装置２００及び第３通信装置３００とホストであるサーバ５００とで構成されるクライアントサーバシステムである。

第１通信装置１００、第２通信装置２００及び第３通信装置３００は、例えば、パーソナルコンピュータなどの情報処理装置、又は、スマートフォンなどの携帯端末である。第１通信装置１００は、第１ユーザの通信装置である。第２通信装置２００は、第１ユーザ以外の他のユーザの通信装置である。第３通信装置３００は、第１ユーザ及び第２ユーザ以外の他のユーザの通信装置である。ただし、第２ユーザと第３ユーザとを区別することは必須ではなく、第２ユーザと第３ユーザとは同一ユーザであってもよい。第１通信装置１００、第２通信装置２００及び第３通信装置３００の構成は同じであるため、ここでは第１通信装置１００に着目して説明する。

第１通信装置１００は、ネットワークＮＷに接続することにより、第２通信装置２００、第３通信装置３００又はサーバ５００と通信を行うことができる。第１通信装置１００は、サーバ５００が提供するアプリケーションプログラムをインストールしたり、各種サービスの提供を受けたりすることが可能である。第１通信装置１００にインストールされたアプリケーションプログラムを実行することにより、第１通信装置１００の表示画面には前述の各種サービスの提供を受けるためのユーザインタフェースが表示される。

アプリケーションプログラムは、サーバ５００からネットワークＮＷを介して第１通信装置１００にダウンロードされる。ただし、アプリケーションプログラムは、予め第１通信装置１００にインストールされていてもよい。さらに、アプリケーションプログラムは、磁気記録媒体、光記録媒体、光磁気記録媒体、半導体メモリなどのコンピュータ読み取り可能な記録媒体に記録した状態で提供されてもよい。この場合、第１通信装置１００は、記録媒体を読み取る装置を備えた情報処理装置であればよい。

サーバ５００が提供する各種サービスは、サーバ５００で実行されるウェブアプリケーションにより第１通信装置１００に提供されてもよい。第１通信装置１００は、ウェブブラウザを実行することによりサーバ５００に対して情報のリクエストを行ったり、サーバ５００から受信した情報の表示を行ったりすることができる。この場合、サーバ５００は、ＷＥＢサーバとして機能する。

サーバ５００は、第１通信装置１００、第２通信装置２００及び第３通信装置３００に対して、各種サービスを提供したり、各種サービスの提供のためのアプリケーションプログラムを提供したりする情報処理装置である。本実施形態では、サーバ５００は、ユーザに対して電子書籍を提供するサービスを実行する。したがって、アプリケーションプログラムには、例えば、電子書籍の選択及び購入等を行うためのＧＵＩ（グラフィカルユーザインタフェース）を提供するためのＧＵＩプログラムや電子書籍を閲覧するためのビューアプログラムなどが含まれる。

アプリケーションプログラムや各種サービスの提供に要するプログラムは、サーバ５００に含まれる記憶装置、サーバ５００が読み出し可能な記録媒体又はサーバ５００がネットワークＮＷを介して接続可能なデータベース６００に記録される。図１において、サーバ５００は、単一の情報処理装置として図示されているが、複数の情報処理装置で構成されていてもよい。

［通信装置の構成］
図２は、本発明の一実施形態における第１通信装置１００の構成を示すブロック図である。本実施形態の第１通信装置１００は、制御部１０１、記憶部１０２、表示部１０３、操作部１０４、センサ部１０５、撮像部１０６、位置検出部１０７、通信部１０８、音入出力部１０９及び報知部１１０を含む。ただし、第１通信装置１００は、これらの要素をすべて含むものに限定されない。また、前述のとおり、第１通信装置１００、第２通信装置２００及び第３通信装置３００は同じ構成を有するため、第２通信装置２００及び第３通信装置３００の説明は省略する。

制御部１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などのプロセッサ（演算処理装置）及びＲＡＭ等の記憶装置を備える。制御部１０１は、記憶部１０２に記憶されたプログラムをプロセッサにより実行して、各種機能を第１通信装置１００において実現させる。第１通信装置１００の各要素から出力される信号は、第１通信装置１００において実現される各種機能によって使用される。

記憶部１０２は、不揮発性メモリ、ハードディスクドライブなどの恒久的な情報保持及び情報の書き換えが可能な記録装置（記録媒体）である。記憶部１０２は、プログラム及び当該プログラムの実行に必要となるパラメータ等の情報を格納する。例えば、前述のアプリケーションプログラムは、記憶部１０２に格納される。

表示部１０３は、制御部１０１の制御に応じて、各種の表示画像（例えば、ＧＵＩ画像、電子書籍の閲覧画像など）を表示する表示領域を有する。表示部１０３は、例えば、液晶ディスプレイ又は有機ＥＬディスプレイなどの表示装置である。

操作部１０４は、ユーザの操作に応じた信号（例えば、命令又は情報を示す信号）を制御部１０１に出力する操作装置である。操作部１０４は、表示部１０３の表面に配置されたタッチセンサである。操作部１０４は、表示部１０３と組み合わせることによってタッチパネルを構成する。ユーザの操作に応じた命令又は情報は、ユーザの指又はスタイラスペン等の指示物で操作部１０４に接触することによって第１通信装置１００へ入力される。ただし、操作部１０４は、第１通信装置１００の筐体に配置されたスイッチを含んでもよい。

センサ部１０５は、第１通信装置１００の動き、第１通信装置１００の周囲の環境などに関する情報を収集して信号に変換する機能を備える装置である。本実施形態のセンサ部１０５は、例えば、加速度センサである。制御部１０１は、センサ部１０５の出力信号に基づいて、第１通信装置１００の動き（例えば、傾き、振動など）に関する情報を取得する。ただし、センサ部１０５は、照度センサ、温度センサ、磁気センサなど、他のセンサを含んでもよい。

撮像部１０６は、撮像対象の像を信号に変換する撮像装置（カメラ）である。第１通信装置１００は、撮像部１０６から出力された撮像信号に基づいて画像ファイル（静止画ファイル及び動画ファイルを含む）を生成する。撮像部１０６は、一次元コード又は二次元コードなどの識別コードを読み取るスキャナーとして機能してもよい。

位置検出部１０７は、位置情報に基づいて第１通信装置１００の位置を検出する。本実施形態の位置検出部１０７は、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）を用いて第１通信装置１００の位置を検出する。位置検出部１０７は、周辺のＷｉ－Ｆｉルータから受信した情報に基づいて第１通信装置１００の位置を検出してもよい。

通信部１０８は、制御部１０１の制御により、ネットワークＮＷと接続して、ネットワークＮＷに接続された第２通信装置２００、第３通信装置３００、サーバ５００などの他の装置と情報の送信及び受信を行う無線通信モジュールである。通信部１０８は、赤外線通信、近距離無線通信などを行う通信モジュールを含んでいてもよい。

音入出力部１０９は、音の入力及び出力を行う。例えば、音の入力は、音入出力部１０９のマイクにより行われる。音の出力は、音入出力部１０９のスピーカにより行われる。音入出力部１０９は、他の通信装置（例えば、第２通信装置２００、第３通信装置３００）との通話のほか、外部音の収集又は電子書籍の閲覧に伴う音声又は効果音等の出力に用いることもできる。

報知部１１０は、ユーザに対し、視覚的、聴覚的又は触覚的方法により第１通信装置１００の状態を報知する。具体的には、報知部１１０は、ユーザに対して光、音又は振動を用いて第１通信装置１００の状態を報知する。例えば、報知部１１０は、ランプを点滅させたり筐体全体を振動させたりすることにより、外部装置との通信の有無をユーザに報知することができる。筐体全体の振動は、報知部１１０のバイブレータにより行われる。また、報知部１１０は、電子書籍の更新等をユーザに報知することも可能である。例えば、報知部１１０は、新しい電子書籍が入荷されたり、他のユーザから電子書籍をプレゼントされたりしたことをユーザに光、音又は振動を用いて報知することができる。

［サーバの構成］
図３は、本発明の一実施形態におけるサーバ５００の構成を示すブロック図である。本実施形態のサーバ５００は、制御部５０１、記憶部５０２及び通信部５０３を含む。

制御部５０１は、ＣＰＵなどの演算処理回路（制御装置）及びＲＡＭ等の記憶装置を備える。制御部５０１は、記憶部５０２に記憶されたプログラムをＣＰＵにより実行して、各種機能をサーバ５００において実現させる。サーバ５００の各要素から出力される信号は、サーバ５００において実現される各種機能によって使用される。

記憶部５０２は、不揮発性メモリ、ハードディスクドライブなどの恒久的な情報保持及び情報の書き換えが可能な記録装置（記録媒体）である。記憶部５０２は、プログラム及び当該プログラムの実行に必要となるパラメータ等の情報を格納する。例えば、前述のアプリケーションプログラムやビューアプログラムは、記憶部５０２に格納されていてもよい。また、記憶部５０２は、ネットワークＮＷを介して他の装置（例えば、第１通信装置１００、第２通信装置２００又は第３通信装置３００）から受信した各種情報を格納してもよい。

図４は、本発明の一実施形態におけるサーバ５００の記憶部５０２に格納されるデータテーブルの一例を示す図である。図４に示すように、記憶部５０２は、データテーブルとして、保持リスト５１、公開リスト５２、購入リスト５３、価格リスト５４及びスケジュールリスト５５を含む。データテーブルは、本実施形態の情報提供方法を実行する際に生成又は更新される。

通信部５０３は、制御部５０１の制御により、ネットワークＮＷと接続して、ネットワークＮＷに接続された第１通信装置１００、第２通信装置２００、第３通信装置３００、他のサーバ、データベース６００などの他の装置と情報の送信及び受信を行う無線通信モジュールである。他のサーバとしては、例えば、ＷＥＢサーバ、決済サーバ、ＳＮＳサーバ、ゲームサーバ、メールサーバなどが例示できる。

［情報提供機能の構成］
サーバ５００は、第１通信装置１００、第２通信装置２００及び第３通信装置３００に対して情報提供機能５５０を備える。具体的には、本実施形態のサーバ５００は、ユーザに電子書籍を提供するコンテンツサーバである。まず、サーバ５００が備える情報提供機能５５０について説明する。以下に説明する情報提供機能５５０は、サーバ５００の制御部５０１が記憶部５０２から読み出したプログラムを実行することにより実現される。ただし、情報提供機能５５０を実現するための構成の一部または全部は、ハードウエアによって実現されてもよい。また、各機能ブロックに付与した名称及び符号は、説明の便宜上付したものであり、ソフトウェアの構成及び処理の順序を限定するものではない。

図５は、本発明の一実施形態におけるサーバ５００が備える情報提供機能５５０の構成を示すブロック図である。情報提供機能５５０は、指示データ受信部５５１、制御データ送信部５５２、保持リスト管理部５５３、公開リスト管理部５５４、購入リスト管理部５５５、決済処理部５５６、スケジュール管理部５５７、通知処理部５５８及びデータベース管理部５５９を含む。ただし、この例に限られるものではなく、情報提供機能５５０は、他の機能をさらに備えてもよいし、一部の機能を備えていなくてもよい。

指示データ受信部５５１は、第１通信装置１００、第２通信装置２００又は第３通信装置３００から送信される指示データを受信する。指示データは、各通信装置からサーバ５００に要求される各種サービスを指示するデータである。例えば、指示データは、サーバ５００に対して電子書籍の閲覧や購入に関する各種指示を行うデータを含む。

制御データ送信部５５２は、第１通信装置１００、第２通信装置２００又は第３通信装置３００に対して各種サービスに関する情報を提供するための制御データを送信する。制御データは、例えば、各通信装置からの要求に応答する表示データ（ＨＴＭＬデータを含む）又は各通信装置にインストールされたアプリケーションの制御に必要なデータなどが含まれる。

保持リスト管理部５５３は、各ユーザに関連付けられた保持リスト５１の生成及び更新（アイテムの追加及び削除を含む）を管理する。具体的には、保持リスト管理部５５３は、データベース６００に登録されたアイテムについて、ユーザから保持指示（選択したアイテムを保持する旨の指示）を受けたとき、保持指示で選択されたアイテムを含む保持リスト５１の生成又は更新を行う。他方、保持リスト管理部５５３は、保持リスト５１に含まれる保持アイテムについて、ユーザから削除指示（選択した保持アイテムを削除する旨の指示）を受けたとき、削除指示で選択された保持アイテムを保持リスト５１から削除する。生成された保持リストは、保持リストを生成したユーザのみが閲覧可能である。

図６は、本発明の一実施形態における保持リスト管理部５５３が管理する保持リスト５１の構成の一例を示す図である。図６に示すように、保持リスト５１は、項目５１ａ～５１ｆを含む。項目５１ａは、本実施形態の情報提供サービスに登録された各ユーザのＩＤ（識別番号）を示す。項目５１ｂは、保持アイテムのタイトルを示す。項目５１ｃは、保持アイテムの巻数を示す。項目５１ｄは、保持アイテムの話数を示す。項目５１ｅは、保持アイテムの作者を示す。項目５１ｆは、保持アイテムに関する他の情報を示す。他の情報としては、例えば、発行日、ユーザ評価、あらすじ、認可前作品であるか否か、公開リストに含まれるか否か等が含まれる。ただし、保持リスト５１の構成、例えば項目の数や内容は、この例に限られるものではない。

以上のように、保持リスト５１は、ユーザごとに、ユーザが購入を検討しているアイテム、又は、購入予定のアイテムを一時的に保持している。図６では、複数のユーザ（ユーザＩＤが「Ａ」から「Ｎ」までのユーザ）と、各ユーザに関連付けられた保持アイテムとを保持リスト５１としてまとめて管理する例を示しているが、この例に限られるものではない。例えば、保持リスト５１は、ユーザごとに個別のデータテーブルとして管理されていてもよい。すなわち、保持リスト５１は、各ユーザと各ユーザに関連付けられた保持アイテムとを管理できればよく、その形式を問わない。

図６に示す例の場合、例えば、「ユーザＡに関連付けられた保持リスト」とは、図６に示す保持リスト５１のうち、「Ａ」のユーザＩＤに関連付けられたアイテムのみを抽出した保持リスト５１Ａを指す。この点については、他のユーザに関連付けられた保持リストについても同様である。他方、上述のように、保持リスト５１がユーザごとに個別のテーブルとして管理されている場合、例えば、「ユーザＡに関連付けられた保持リスト」とは、ユーザＡに関連付けられた個別の保持リスト（個別のデータテーブル）を指す。

なお、本実施形態では、保持リスト５１において、ユーザごとに保持アイテムをまとめた構成とする例を示したが、この例に限られるものではない。例えば、アイテムごとに、そのアイテムを保持するユーザをまとめてもよい。この場合、最終的に、特定のユーザに関連付けられたアイテムのみを抽出した保持リストが、その特定のユーザに関連付けられた保持リストとして扱われる。

公開リスト管理部５５４は、各ユーザに関連付けられた公開リスト５２の生成及び更新（アイテムの追加及び削除を含む）を管理する。具体的には、公開リスト管理部５５４は、保持リスト５１に関連付けられたユーザから公開指示（選択した保持アイテムを「公開」に設定する旨の指示）を受けたとき、公開指示で選択された保持アイテムを含む公開リスト５２の生成又は更新を行う。他方、公開リスト管理部５５４は、保持リスト５１に関連付けられたユーザから非公開指示（選択した保持アイテムを「非公開」に設定する旨の指示）を受けたとき、非公開指示で選択された公開アイテムを公開リスト５２から削除する。

図７は、本発明の一実施形態における公開リスト管理部５５４が管理する公開リスト５２の構成の一例を示す図である。図７に示すように、公開リスト５２は、項目５２ａ～５２ｆを含む。項目５２ａ～５２ｆの内容は、保持リスト５１の項目５１ａ～５１ｆと同様である。公開リスト５２は、ユーザごとに、ユーザが他のユーザに購入を期待するアイテムを一時的に保持している。公開リスト５２は、保持リスト５１に含まれる保持アイテムのうち「公開」に設定されたアイテム（公開アイテム）に関する情報を含むため、保持リスト５１の一部を抽出したリストに相当する。

公開リスト５２の管理方法については、保持リスト５１と同様である。図７に示す例の場合、例えば、「ユーザＡに関連付けられた公開リスト」とは、図７に示す公開リスト５２のうち、「Ａ」のユーザＩＤに関連付けられたアイテムのみを抽出した公開リスト５２Ａを指す。この点については、他のユーザに関連付けられた公開リストについても同様である。

本実施形態において、保持リスト５１に関連付けられたユーザは、保持リスト５１に含まれる保持アイテムごとに公開又は非公開の設定を行うことが可能である。つまり、保持リスト５１に含まれる保持アイテムのうち、ユーザによって「公開」に設定されたアイテムが、公開アイテムとして公開リスト５２に含まれる。生成された公開リスト５２は、公開リスト５２を生成したユーザだけでなく、他のユーザも閲覧可能である。この場合、他のユーザは、保持リスト５１を生成したユーザ以外のすべてのユーザであってもよいし、保持リスト５１を生成したユーザと所定の関係を有するユーザであってもよい。「所定の関係を有するユーザ」は、保持リスト５１を生成したユーザと友達関係にあるユーザ、過去にプレゼント（公開アイテム）のやり取りがあったユーザなどを例示できる。

さらに、公開リスト管理部５５４は、公開リスト５２に含まれる公開アイテムと所定の関係を有する関連アイテムが存在すると、ユーザによる公開指示の有無にかかわらず、関連アイテムを公開リスト５２に追加する。すなわち、公開リスト管理部５５４は、上述の関連アイテムがデータベース６００に登録されていると、登録されている関連アイテムを自動的に公開リスト５２に追加する。これにより、公開リスト５２は、ユーザがわざわざ公開アイテムを追加しなくても自動的に更新される。公開リスト管理部５５４は、公開リスト５２が生成された後にデータベース６００に登録されたアイテムが公開アイテムと所定の関係を有する場合、公開アイテムとして、データベース６００に登録されたアイテムを公開リスト５２に追加してもよい。

公開リスト管理部５５４は、各ユーザに関連付けられた公開リスト５２の生成又は更新を行うと、公開リスト５２の生成又は更新を通知処理部５５８に通知する。この通知に応答して、通知処理部５５８は、公開リスト５２の生成又は更新を、公開リスト５２を生成したユーザ及び他のユーザに通知する。すなわち、公開リスト５２が生成又は更新されると、公開リスト５２の生成又は更新を通知する通知指示が、第１ユーザ及び第１ユーザと所定の関係を有する第２ユーザの第２通信装置２００又は第３ユーザの第３通信装置３００に送信される。これにより、第１ユーザ及び他のユーザは、第１ユーザに関連付けられた公開リスト５２Ａの生成又は更新を速やかに認識することができる。ただし、この例に限らず、通知処理部５５８は、公開リスト５２の生成又は更新を他のユーザのみに通知してもよい。換言すれば、通知処理部５５８は、公開リスト５２の生成又は更新を第１ユーザには通知しない構成としてもよい。この場合、他のユーザは、第１ユーザが関連アイテムの追加に気付かないタイミングで、公開アイテムをサプライズとして第１ユーザにプレゼントすることができる。

購入リスト管理部５５５は、各ユーザに関連付けられた購入リスト５３の生成及び更新（アイテムの追加及び削除を含む）を管理する。具体的には、購入リスト管理部５５５は、ユーザから購入指示（選択したアイテムを購入する旨の指示）を受けたとき、購入指示で選択されたアイテムを含む購入リスト５３の生成又は更新を行う。

他方、購入リスト管理部５５５は、購入リスト５３に含まれる購入アイテムについて、ユーザから削除指示（選択した購入アイテムを削除する旨の指示）を受けたとき、削除指示で選択された購入アイテムを購入リスト５３から削除する。生成された購入リスト５３は、ユーザのみが閲覧可能である。

各ユーザは、データベース６００に登録されたアイテムを購入することができる。各ユーザは、保持リスト５１を経由せずに直接アイテムを購入したり、いったん保持リスト５１に登録してからアイテムを購入したりすることができる。さらに、本実施形態では、保持リスト５１を生成したユーザ以外の他のユーザが、公開リスト５２を介して公開アイテムを購入することが可能である。すなわち、他のユーザが、保持リスト５１を生成したユーザに公開アイテムをプレゼントすることができる。そのため、購入リスト管理部５５５は、ユーザによる通常の購入指示を受けたときだけでなく、他のユーザが公開リスト５２を介して行った購入指示を受けたときも購入リスト５３の生成又は更新を行う。

図８は、本発明の一実施形態における購入リスト管理部５５５が管理する購入リスト５３の構成の一例を示す図である。図８に示すように、購入リスト５３は、項目５３ａ～５３ｆを含む。項目５３ａ～５３ｆの内容は、保持リスト５１の項目５１ａ～５１ｆと同様である。ただし、購入リスト５３の項目５３ｆは、アイテムの購入に関する情報（例えば、購入価格、決済機関、購入者に関する情報など）を含んでいてもよい。購入リスト５３は、ユーザごとに、ユーザが購入したアイテム（他のユーザが購入したアイテムを含む）を保持している。すなわち、購入リスト５３は、データベース６００に登録されたアイテムに対するユーザの所有権をまとめたリストとも言える。

購入リスト５３の管理方法については、保持リスト５１と同様である。図８に示す例の場合、例えば、「ユーザＡに関連付けられた購入リスト」とは、図８に示す購入リスト５３のうち、「Ａ」のユーザＩＤに関連付けられたアイテムのみを抽出した購入リスト５３Ａを指す。この点については、他のユーザに関連付けられた購入リストについても同様である。

本実施形態において、ユーザは、データベースに登録されたアイテム、又は、保持リスト５１に含まれるアイテムについて、購入指示を行うことができる。他方、保持リスト５１を生成したユーザ以外の他のユーザは、公開リスト５２に含まれるアイテムについて、購入指示を行うことができる。上述の他のユーザが公開リスト５２に含まれるアイテムを購入した場合、購入されたアイテムの所有権は、保持リスト５１を生成したユーザ（すなわち、他のユーザが購入指示を入力した公開リスト５２の所有者）に付与される。

決済処理部５５６は、購入されたアイテムについて購入手続のための決済処理を行う。本実施形態において、決済処理部５５６は、購入されたアイテムに関する決済情報を提携する決済サーバ（図示せず）に送信する。決済処理は、決済サーバで実行される。決済処理部５５６は、決済サーバから決済処理の結果を受信して所定の購入手続を行う。ただし、この例に限られるものではなく、サーバ５００が決済処理を実行してもよい。

決済処理部５５６は、データベース６００に登録されたアイテムと購入価格とを関連付けた価格リスト５４を有する。決済処理部５５６は、購入されたアイテムについて価格リスト５４を参照し、対応する購入価格（割引率又は割引後の購入価格を含む）を取得する。取得した購入価格は、購入されたアイテムに関する決済情報に組み込まれる。

スケジュール管理部５５７は、サーバ５００で取り扱われるアイテムごとに設定された様々なスケジュールを管理する。サーバ５００で取り扱われるアイテムには、将来的にデータベース６００に登録されるアイテム及び現時点においてデータベース６００に登録されているアイテムが含まれる。例えば、スケジュール管理部５５７は、未登録のアイテムがデータベース６００に登録される日（発行日）を管理したり、データベースに登録されたアイテムの関連アイテムの発行日又は更新日を管理したりすることができる。

スケジュール管理部５５７は、スケジュールリスト５５を有する。スケジュールリスト５５に格納される情報としては、例えば、事前購入アイテムに設定された日時又は購入アイテムに関連する関連アイテムの発行日などが例示できる。そのほか、スケジュールリスト５５に格納される情報としては、将来的にデータベース６００に登録されるアイテムの登録日（すなわち、発行日）又は認可前アイテムが公式アイテムとしてデータベース６００に登録される登録日などが例示できる。

スケジュール管理部５５７は、各アイテムについて発行日、登録日、購入予定日等のスケジュールが更新されたとき、スケジュールリスト５５を更新する。スケジュール管理部５５７は、スケジュールリスト５５を参照して、アイテムに関する所定の時期の到来を他の機能部に通知してもよい。

通知処理部５５８は、所定の条件が満たされたとき、第１通信装置１００、第２通信装置２００又は第３通信装置３００に、所定の条件が満たされたことを通知する。換言すれば、通知処理部５５８は、イベントが発生したとき、第１通信装置１００、第２通信装置２００又は第３通信装置３００に、イベントの発生を通知する。例えば、通知処理部５５８は、第１ユーザの公開リスト５２を介して第２ユーザが公開アイテムを購入したとき、第１ユーザの第１通信装置１００に、公開アイテムが購入されたこと（例えば、公開アイテムが第１ユーザの購入リスト５３に追加されたこと）を通知する。その際、通知処理部５５８は、公開アイテムを購入した第２ユーザに関する情報を併せて通知してもよい。また、通知処理部５５８は、第１ユーザが公開リスト５２の生成又は更新を行ったとき、第２通信装置２００又は第３通信装置３００に、第１ユーザの公開リスト５２が生成又は更新されたことを通知してもよい。

通知処理部５５８は、通知内容を決定し、当該通知内容を他の通信装置に表示させるための制御データを生成してもよい。ただし、この例に限らず、通知処理部５５８は、通知内容を決定して当該通知内容を制御データ送信部５５２に送信してもよい。この場合、通知内容を他の通信装置に表示させるための制御データは、制御データ送信部５５２で生成されてもよい。

データベース管理部５５９は、データベース６００の更新を行う。具体的には、データベース管理部５５９は、未登録のアイテムが発行（発売）されたとき、発行されたアイテムをデータベース６００に登録（追加）する。また、データベース管理部５５９は、データベース６００に登録されたアイテムが閲覧期限を超えた場合などに、登録されたアイテムをデータベース６００から削除する。

［情報提供方法の構成］
上述の情報提供機能５５０により実行される情報提供処理（情報提供方法）について説明する。本実施形態の情報提供方法は、サーバ５００の制御部５０１が記憶部５０２から読み出したプログラムを実行することにより実現される。換言すれば、本実施形態の情報提供方法は、図５に示した情報提供機能５５０によって実行される。

図９は、本発明の一実施形態におけるサーバ５００の制御部５０１が実行する情報提供方法を示すフローチャートである。図９は、第１通信装置１００の所有者である第１ユーザ（ここでは、上述のユーザＡとする）が、保持リスト５１Ａ及び公開リスト５２Ａを更新してから、公開リスト５２Ａに関連アイテムが追加されるまでのフローを示している。

図１０は、第１ユーザの第１通信装置１００に表示されるＵＩ（ユーザインタフェース）画像の一例を示す図である。具体的には、図１０は、ＵＩ画像として、データベース６００に登録された複数のアイテム（登録アイテム）の一部を表示する閲覧画像６０を表示している。閲覧画像６０は、第１通信装置１００の表示部１０３に表示される。表示部１０３とほぼ同じ領域には、操作部１０４としてタッチセンサが配置される。

第１ユーザは、図１０に示した閲覧画像６０を用いて、気になるアイテム又は購入予定のアイテムを探すことができる。図１０において、「ＡＡＡＡ」は、データベース６００に登録されたアイテム（電子書籍）のタイトルであり、第１話から第４話まで４つのアイテムが表示されている。第１ユーザが閲覧画像６０を上方にスクロールさせると、第５話以降の他のアイテムを表示させることができる。

図１０に示す閲覧画像６０において、第１ユーザが保持を希望するアイテムの保持ボタン６０１を押すと、選択されたアイテムの保持指示が第１ユーザの第１通信装置１００からサーバ５００に送信される。第１通信装置１００から送信された保持指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される（ステップＳ１１）。

サーバ５００の制御部５０１（具体的には、保持リスト管理部５５３）は、保持指示を受信すると、保持指示によって選択されたアイテムを保持リスト５１Ａに追加する。これにより、第１ユーザに関連付けられた保持リスト５１Ａが更新される（ステップＳ１２）。ここでは、第１ユーザに関連付けられた保持リスト５１Ａが既に生成されているものとし、保持アイテム６１ａとして、タイトル「ＡＡＡＡ」の第１話が追加されたものとする。ただし、第１ユーザに関連付けられた保持リスト５１Ａが存在しない場合（図６に示した保持リスト５１に、第１ユーザに関連付けられたアイテムが存在しない場合）、保持指示によって選択されたアイテムを含む保持リストが、第１ユーザに関連付けられて新たに生成される。

図１１は、第１ユーザの第１通信装置１００に表示されるＵＩ画像の一例を示す図である。具体的には、図１１は、ＵＩ画像として、第１ユーザに関連付けられた保持リスト５１Ａに対応する保持リスト画像６１を表示した例を示している。図１１に示す例では、追加された保持アイテム６１ａ以外に、既に４つの保持アイテム６１ａが保持リスト画像６１に含まれている。図１１に示す保持リスト画像６１は、図６に示したユーザＡに関連付けられた保持リスト５１Ａに対応する。すなわち、図６に示した保持リスト５１Ａを可視化したＵＩ画像が、保持リスト画像６１として、第１通信装置１００の表示部１０３に表示される。

他方、図１０において、第１ユーザが、あるアイテムの購入ボタン６０２を押すと、選択されたアイテムの購入指示が第１ユーザの第１通信装置１００からサーバ５００に送信される。第１通信装置１００から送信された購入指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。サーバ５００の制御部５０１は、購入指示を受信すると、購入指示によって選択されたアイテムについて決済処理を行い、決済処理完了後に、当該アイテムを第１ユーザに関連付けられた購入リスト５３Ａに追加する。これにより、第１ユーザに関連付けられた購入リスト５３Ａが更新される。このとき、第１ユーザに関連付けられた購入リスト５３Ａが存在しない場合は、購入指示によって選択されたアイテムを含む購入リストが第１ユーザに関連付けられて新たに生成される。

図９に説明を戻す。図９に示すフローチャートにおいて、保持リスト５１Ａが更新された後、制御部５０１は、公開指示を第１通信装置１００から受信したか否かを判定する（ステップＳ１３）。ステップＳ１３の判定結果がＮＯであれば、公開指示を受信するまで処理を繰り返す。ステップＳ１３の判定結果がＹＥＳであれば、公開指示によって選択されたアイテムを公開リスト５２Ａに追加する。これにより、第１ユーザに関連付けられた公開リスト５２Ａが更新される（ステップＳ１４）。ただし、この例に限らず、制御部５０１は、保持リスト５１Ａを更新した時点でいったん処理を終了してもよい。この場合、例えば、制御部５０１は、公開指示の検知を契機として、ステップＳ１４からあらためて処理を開始してもよい。

公開指示は、図１１に示す保持リスト画像６１から入力することができる。具体的には、図１１に示す保持リスト画像６１において、第１ユーザが公開を希望する保持アイテム６１ａの公開ボタン６０３を押すと、選択された保持アイテム６１ａの公開指示が第１ユーザの第１通信装置１００からサーバ５００に送信される。第１通信装置１００から送信された公開指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。サーバ５００の制御部５０１（具体的には、図５に示した公開リスト管理部５５４）は、公開指示を受信すると、公開指示によって選択されたアイテムを公開リスト５２Ａに追加する。

本実施形態において、保持リスト５１Ａに登録された時点では、各アイテムは、「非公開」の設定になっている。このとき、公開ボタン６０３が押されると、設定が「公開」に切り替わり、公開ボタン６０３が強調表示される。逆に、設定が「非公開」であるアイテムは、非公開ボタン６０４が強調表示される。ただし、この例に限らず、公開ボタン６０３及び非公開ボタン６０４に代えて、押すたびに「公開」と「非公開」とが切り変わるトグルボタンを配置してもよい。図１１に示す例では、タイトル「ＡＡＡＡ」の第１話、タイトル「ＤＤＤＤ」の第５話及びタイトル「ＤＤＤＤ」の第６話が「公開」に設定され、それら以外のアイテムが「非公開」に設定されている。

以上のように、保持リスト画像６１を介して１又は複数の保持アイテム６１ａを公開設定にすることにより、第１ユーザに関連付けられた公開リスト５２Ａを更新することができる。ただし、第１ユーザに関連付けられた公開リスト５２Ａが存在しない場合（図７に示した公開リスト５２に、第１ユーザに関連付けられたアイテムが存在しない場合）、公開指示によって選択されたアイテムを含む公開リストが第１ユーザに関連付けられて新たに生成される。第１ユーザに関連付けられた公開リスト５２Ａは、第１ユーザ以外の他のユーザの通信装置においても閲覧可能である。以下、本実施形態では、ユーザＩＤが「Ｂ」であるユーザＢを第２ユーザ、ユーザＩＤが「Ｃ」であるユーザＣを第３ユーザとして説明する。

図１２は、第２ユーザの第２通信装置２００に表示されるＵＩ画像の一例を示す図である。具体的には、図１２は、ＵＩ画像として、第１ユーザに関連付けられた公開リスト５２Ａに対応する公開リスト画像６２を表示した例を示している。なお、ここでは、第２ユーザが第１ユーザの公開リスト５２Ａを閲覧する例を示したが、第１ユーザ及び第２ユーザ以外の他のユーザ（例えば、第３ユーザ）が公開リスト５２Ａを閲覧する場合も同様である。

公開リスト画像６２は、保持リスト画像６１で「公開」に設定された３つの公開アイテム６２ａを含む。図１２に示す公開リスト画像６２は、図７に示したユーザＡに関連付けられた公開リスト５２Ａに対応する。すなわち、図７に示した公開リスト５２Ａを可視化したＵＩ画像が、公開リスト画像６２として、第２通信装置２００の表示部１０３に表示される。公開リスト画像６２に含まれる各アイテムには、第１ユーザが希望する優先順位を設定してもよい。

図１２に示す公開リスト画像６２は、第２ユーザの第２通信装置２００から第１ユーザの公開リスト画像６２の閲覧要求があったとき、第２通信装置２００の表示部１０３に表示される。すなわち、サーバ５００の制御部５０１は、第２ユーザの要求に基づいて、第１ユーザに関連付けられた公開リスト５２Ａに関する情報を第２通信装置２００に送信する。ただし、この例に限られるものではなく、例えば、公開リスト画像６２は、ＳＮＳを介して他の通信装置にシェアされてもよい。

図９に説明を戻す。図９に示すフローチャートにおいて、第１ユーザによる操作に応じて公開リスト５２Ａが更新された後、制御部５０１は、データベース６００に関連アイテムが登録されているか否かを判定する（ステップＳ１５）。ステップＳ１５の判定結果がＮＯであれば、関連アイテムのデータベース６００への登録があるまで処理を繰り返す。ステップＳ１５の判定結果がＹＥＳであれば、データベース６００に登録されている関連アイテムを公開リスト５２Ａに追加する（ステップＳ１６）。これにより、第１ユーザに関連付けられた公開リスト５２Ａが自動的に更新される。ただし、この例に限らず、制御部５０１は、公開リスト５２Ａを生成又は更新した時点でいったん処理を終了してもよい。この場合、例えば、制御部５０１は、データベース６００への新たなアイテムの登録（例えば、新たな電子書籍の発行）の検知を契機として、ステップＳ１６からあらためて処理を開始してもよい。

図１３は、第２ユーザの第２通信装置２００に表示されるＵＩ画像の一例を示す図である。具体的には、図１３は、ＵＩ画像として、図９に示すステップＳ１６の後の公開リスト５２Ａに対応する公開リスト画像６２を表示した例を示している。図９に示すステップＳ１６の後、公開リスト画像６２は、保持リスト画像６１で「公開」に設定された３つの公開アイテム６２ａに加えて、それら３つの公開アイテム６２ａと所定の関係を有する関連アイテム６２ｂを含む。本実施形態では、公開アイテム６２ａと関連アイテム６２ｂとが区別できるように、関連アイテム６２ｂを強調表示している。例えば、関連アイテム６２ｂの強調表示は、ハイライト表示であってもよいし、背景色を変更した表示であってもよい。また、データベース６００への新たなアイテム（最新刊など）の登録に応じて追加された関連アイテム６２ｂには、例えば「ＮＥＷ！」などの修飾文字を追加してもよい。

図１３に示す例では、タイトル「ＡＡＡＡ」の第１話の関連アイテム６２ｂとして、タイトル「ＡＡＡＡ」の第２話及び第３話が追加されている。また、タイトル「ＤＤＤＤ」の第６話の関連アイテム６２ｂとして、タイトル「ＤＤＤＤ」の第７話が追加されている。図示は省略するが、図７に示した公開リスト５２Ａにも上記関連アイテム６２ｂに関する情報が追加される。

このように、本実施形態では、第１ユーザによって公開リスト５２Ａが生成又は更新されると、サーバ５００の制御部５０１によって、公開リスト５２Ａに含まれる公開アイテムの関連アイテムが公開リスト５２Ａに自動的に追加される。つまり、第１ユーザが公開リスト５２Ａを生成又は更新すると、その後、第１ユーザによる公開指示の有無にかかわらず、サーバ５００の制御部５０１によって、自動的に公開リスト５２Ａの拡充処理が行われる。なお、このような公開リスト５２Ａの拡充処理によって関連アイテムが追加された場合、当該関連アイテムは、保持リスト５１Ａにも反映されてもよい。

公開アイテム又は関連アイテムの追加によって公開リスト５２Ａが更新されると、その旨の通知が第１ユーザ及び／又は他のユーザの通信装置に対して送信されてもよい。例えば、公開リスト５２Ａに含まれる公開アイテムの最新話がデータベース６００に登録されるたびに、その最新話が関連アイテムとして公開リスト５２Ａに追加され、第１通信装置１００、第２通信装置２００及び／又は第３通信装置３００に公開リスト５２Ａが更新された旨の通知が送信されてもよい。その際、公開リスト５２Ａが更新された旨の通知は、電子メール又はＳＮＳを介して行われてもよいし、アプリケーション内のメッセージボックスなどを介して行われてもよい。通知を受けた通信装置は、図２に示した表示部１０３に通知内容を表示してもよいし、報知部１１０を用いてユーザへの通知を行ってもよい。

以上のとおり、本実施形態によれば、ユーザが特定の操作を行わなくても、公開アイテムの登録に連動して関連アイテムが公開されるため、ユーザにとって利便性の高い情報提供方法を実現することができる。

次に、保持リスト５１を生成したユーザに対し、他のユーザが公開アイテムをプレゼントする例について説明する。

図１４は、本発明の一実施形態におけるサーバ５００の制御部５０１が実行する情報提供方法を示すフローチャートである。具体的には、図１４は、第２通信装置２００の所有者である第２ユーザ（ユーザＢ）が、保持リスト５１Ａを生成したユーザＡに対してプレゼントを行うまでのフローを示している。

図１３に示すように、公開リスト画像６２では、公開アイテム６２ａ及び関連アイテム６２ｂにプレゼントボタン６０５が配置される。図１３において、第２ユーザが、第１ユーザにプレゼントしたいアイテムのプレゼントボタン６０５を押すと、選択されたアイテムの購入指示が第２ユーザの第２通信装置２００からサーバ５００に送信される。第２通信装置２００から送信された購入指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される（ステップＳ２１）。

サーバ５００の制御部５０１は、第２通信装置２００から購入指示を受信すると、購入指示によって選択されたアイテムについて決済処理を行い、決済処理完了後に、当該アイテムを第１ユーザに関連付けられた購入リスト５３Ａに追加する（ステップＳ２２）。これにより、第１ユーザに関連付けられた購入リスト５３Ａが更新される。制御部５０１が購入指示を受信すると、購入指示によって選択されたアイテムについての決済処理が図５に示した決済処理部５５６により実行される。その後、決済処理の終了したアイテムについて、図５に示した購入リスト管理部５５５が購入リスト５３Ａに追加する。

このように、第２ユーザが第１ユーザに関連付けられた公開リスト画像６２に含まれる公開アイテム６２ａ又は関連アイテム６２ｂを購入した場合、購入されたアイテムの所有権は、第１ユーザに付与される。すなわち、第２ユーザは、第１ユーザに関連付けられた公開リスト画像６２のプレゼントボタン６０５を介して、第１ユーザにアイテムをプレゼントすることができる。購入指示には、プレゼントの送り主である第２ユーザのＩＤ及びプレゼントの送り先（すなわち、公開リスト５２Ａの公開者）である第１ユーザのＩＤが含まれる。

ここで、図１５は、第２ユーザの第２通信装置２００に表示されるＵＩ画像の一例を示す図である。サーバ５００の制御部５０１は、ステップＳ２２の購入リスト５３Ａの更新が終了したら、図１５に示すように、第１ユーザに関連付けられた公開リスト画像６２において、プレゼントした公開アイテム６２ａ又は関連アイテム６２ｂのプレゼントボタン６０５を「プレゼント済」と表示したオブジェクト６０５ａに変更してもよい。この場合、例えば、オブジェクト６０５ａの色をグレーに表示して、当該オブジェクト６０５ａは操作できない旨を示してもよい。第２ユーザは、第１ユーザの公開リスト画像６２を見れば、自分又は他のユーザ（例えば、第３ユーザ）によって既にプレゼントされたアイテムを認識できるため、重複するプレゼントの購入を回避することができる。

また、図１６は、第１ユーザの第１通信装置１００に表示されるＵＩ画像の一例を示す図である。サーバ５００の制御部５０１は、図１６に示すように、第１ユーザに関連付けられた保持リスト画像６１において、プレゼントされた保持アイテム６１ｂの公開ボタン６０３及び非公開ボタン６０４を、「受領済」と表示したオブジェクト６０６に変更してもよい。この場合、例えば、オブジェクト６０６の色をグレーに表示して、当該オブジェクト６０６は操作できない旨を示してもよい。

第１ユーザは、保持リスト画像６１を見れば、他のユーザ（ここでは、第２ユーザ）からアイテムがプレゼントされたことを直感的に認識することができる。そのため、第１ユーザは、他のユーザによって公開アイテム６２ａ又は関連アイテム６２ｂが購入されたことを知ることができ、該当するアイテムを速やかに保持リスト５１Ａから削除することができる。

さらに、本実施形態では、図１４に示すように、第２ユーザによって公開アイテム６２ａ又は関連アイテム６２ｂが購入された旨の通知を第１ユーザの第１通信装置１００に送信する（ステップＳ２３）。これにより、第１ユーザは、第２ユーザからプレゼントがあったことを速やかに認識することができる。この通知は、図５に示した通知処理部５５８によって実行される。通知処理部５５８の通知は、電子メール、ＳＮＳ（ソーシャルネットワーキングサービス）など公知のコミュニケーションツールを用いて行ってもよいし、第１通信装置１００にインストールされたアプリケーション内のメッセージボックス等を介して行ってもよい。さらに、通知処理部５５８は、制御部５０１が実行するウェブアプリケーションを介して通知を行ってもよい。

図１７は、第１ユーザの第１通信装置１００に表示されるＵＩ画像の一例を示す図である。サーバ５００の制御部５０１は、図１７に示すように、第１ユーザの閲覧画像６０において、プレゼントされたアイテムの保持ボタン６０１及び購入ボタン６０２を、「購入済」等と表示したオブジェクト６０７に変更してもよい。この場合、例えば、オブジェクト６０７の色をグレーに表示して、当該オブジェクト６０７は操作できない旨を示してもよい。さらに、閲覧画像６０には、第２ユーザ（ユーザＢ）によって公開アイテム６２ａ又は関連アイテム６２ｂが購入された旨の表示を行ってもよい。例えば、図１７に示すように、プレゼントされたアイテムに、第２ユーザからプレゼントされた旨のメッセージ６０８を表示してもよい。

図１７に示す例では、第１ユーザは、閲覧画像６０を見れば、他のユーザ（ここでは、第２ユーザ）からアイテムがプレゼントされたことを視覚的に認識することができる。そのため、第１ユーザは、他のユーザによって公開アイテム６２ａ又は関連アイテム６２ｂが購入されたことを速やかに認識することができ、該当するアイテムを速やかに保持リスト５１Ａから削除することができる。

また、第１ユーザの閲覧画像６０には、メッセージ６０８に加えて、又は、メッセージ６０８に代えて、御礼もしくはリアクションをプレゼントの送り主（ここでは、第２ユーザ）に通知するためのオブジェクトを設けてもよい。例えば、プレゼントの送り主に対するメッセージを作成するためのＵＩボタンを配置したり、定型文のメッセージ（「いいね！」や「ありがとう！」など）を送信するためのＵＩボタンを配置したりしてもよい。

さらに、第１ユーザの第１通信装置１００には、他のユーザからプレゼントされたアイテムの購入金額の総額が表示されてもよい。

（第１実施形態の変形例１）
図１７に示す例では、第１ユーザに対し、第２ユーザによって公開アイテム６２ａ又は関連アイテム６２ｂが購入されたことを通知する例を示したが、この例に限られるものではない。具体的には、サーバ５００の制御部５０１は、第１ユーザ及び第２ユーザ以外の第３ユーザが、第１ユーザにプレゼントがあったことを知ることができるようにしてもよい。

図１８は、第３ユーザの第３通信装置３００に表示されるＵＩ画像の一例を示す図である。サーバ５００の制御部５０１は、図１８に示すように、第３通信装置３００の表示部１０３に表示された公開リスト画像６２（第１ユーザに関連付けられた公開リスト）において、プレゼントされたアイテムのプレゼントボタン６０５を削除してもよい。さらに、削除したプレゼントボタン６０５に代えて、第２ユーザ（ユーザＢ）によって公開アイテム６２ａ又は関連アイテム６２ｂが購入された旨の表示を行ってもよい。例えば、図１８に示すように、プレゼントされたアイテムに、第２ユーザがプレゼントした旨のメッセージ６０９を表示してもよい。さらに、公開リスト画像６２には、過去に第１ユーザがプレゼントされたアイテムの数が表示されてもよい。

図１８に示す例では、第１ユーザの公開リスト画像６２を見た第３ユーザが、第１ユーザにプレゼントがあったことやプレゼントの数を視覚的に認識することができる。これにより、第３ユーザにおける第１ユーザへのプレゼント購入の意欲を高めることができる。

（第１実施形態の変形例２）
前述のように、本実施形態において、公開アイテムと関連アイテムとの間の「所定の関係」は、任意に設定することができる。したがって、関連アイテムとして公開リストに追加するアイテムには一定の制限を設けてもよい。例えば、公開アイテムの不足分（既に発売されているもののまだ購入していないもの）を関連アイテムとして追加する場合、公開アイテムの巻又は話よりも以前の巻又は話のみを追加してもよい。

このように、追加する関連アイテムに一定の制限を設けることにより、追加される関連アイテムの数を抑制することができる。これによりユーザが自ら公開した公開アイテムが目立たなくなったり、公開リストに含まれるアイテムが極端に増えすぎたりすることを防止することができる。

（第１実施形態の変形例３）
図１５では、第２ユーザが第１ユーザに公開アイテム６２ａ又は関連アイテム６２ｂをプレゼントすると、プレゼント済みであることを示すオブジェクト６０５ａを表示する例を示した。しかし、この例に限られるものではなく、サーバ５００の制御部５０１は、プレゼントされた公開アイテム６２ａ又は関連アイテム６２ｂを、第１ユーザに関連付けられた公開リスト５２Ａから削除してもよい。この場合、公開リスト５２Ａから削除された公開アイテム６２ａ又は関連アイテム６２ｂは、図１５に示した公開リスト画像６２からも削除される。

さらに、制御部５０１は、プレゼントされた公開アイテム６２ａに対応する保持アイテム６１ａを第１ユーザに関連付けられた保持リスト５１Ａから削除してもよい。この場合、保持リスト５１Ａから削除された保持アイテム６１ａは、図１６に示した保持リスト画像６１からも削除される。

既にプレゼントされたアイテムについては、保持リスト５１Ａに保持したり公開リスト５２Ａで公開したりする必要性がない。そのため、プレゼント済みのアイテムを保持リスト５１Ａ又は公開リスト５２Ａから削除することにより、不要なデータの増加を防ぐともに、保持リスト画像６１又は公開リスト画像６２の視認性を向上させることができる。

ここでは、プレゼントされたアイテムについて説明したが、各ユーザが自分で購入したアイテムについても同様である。すなわち、サーバ５００の制御部５０１は、各ユーザが自分で購入したアイテムについても、保持リスト５１から削除したり公開リスト５２から削除したりしてもよい。

（第１実施形態の変形例４）
第１実施形態において、決済処理部５５６は、公開リスト画像６２を介して第１ユーザにプレゼントされたアイテムが公開アイテム６２ａである場合と関連アイテム６２ｂである場合とで、購入価格を異ならせることが可能である。例えば、プレゼントされたアイテムが関連アイテム６２ｂである場合、公開アイテム６２ａである場合に比べて、購入価格を低くすることが可能である。この場合、公開リスト画像６２において、公開アイテム６２ａの購入価格と関連アイテム６２ｂの購入価格とを表示しておいてもよい。公開アイテム６２ａの購入価格及び関連アイテム６２ｂの購入価格は、図４に示した価格リスト５４に格納される。

これにより、公開アイテム６２ａだけでなく、関連アイテム６２ｂもプレゼントするよう第２ユーザに促すことができる。

（第１実施形態の変形例５）
第１実施形態において、通知処理部５５８は、公開リスト画像６２を介して第１ユーザにプレゼントされたアイテムが公開アイテム６２ａである場合と関連アイテム６２ｂである場合とで、プレゼントされた旨の通知の態様を異ならせることが可能である。例えば、通知処理部５５８は、通知の態様として、第１ユーザに通知するメッセージを異ならせてもよい。具体的には、プレゼントされたアイテムが公開アイテム６２ａである場合と関連アイテム６２ｂである場合とで、図１７に示したメッセージ６０８の内容を異ならせてもよい。

上述の例は、第１ユーザに通知するメッセージを異ならせる場合について述べたが、この例に限られるものではない。例えば、プレゼントされたアイテムが公開アイテム６２ａである場合と関連アイテム６２ｂである場合とで、図１８に示した第３ユーザへのメッセージ６０９の内容を異ならせてもよい。

また、図１７に示した閲覧画像６０において、御礼もしくはリアクションなどのメッセージをプレゼントの送り主に通知するためのオブジェクト（例えば、ＵＩボタン）が設けられる場合、プレゼントされたアイテムが公開アイテム６２ａである場合と関連アイテム６２ｂである場合とで、プレゼントの送り主に通知するメッセージの内容を異ならせてもよい。このとき、プレゼントの送り主へのインセンティブとして、メッセージに御礼の品を添付してもよい。例えば、御礼の品として、第１ユーザが所持するアイテムのいずれかを無料で閲覧できるチケットが添付されてもよい。さらに、上述のオブジェクトは、複数の御礼の品から送り主へ送る品を選択できるＵＩを備えていてもよい。

（第１実施形態の変形例６）
第１実施形態において、各ユーザについて所定のランク付けを行ってもよい。例えば、多くのプレゼントをもらっているか否か、多くのプレゼントを贈っているか否かなどを指標として各ユーザの評価を行い、その評価結果に基づいて、各ユーザのランク又はステータスを決定してもよい。各ユーザのランク又はステータスは、例えば、公開リスト画像６２に表示されてもよい。例えば、ユーザの名前の横に、ランク（プラチナ、ゴールドなど）、プレゼント受贈数、プレゼント贈与数などが表示されてもよい。

本変形例によれば、公開リスト画像６２を閲覧したユーザは、その公開リスト５２を公開しているユーザが、多くのプレゼントをもらっているユーザであることや多くのプレゼントを贈っているユーザであることなどを容易に認識することができる。

（第１実施形態の変形例７）
第１実施形態において、図１２又は図１３に示した公開リスト画像６２には、各アイテムに、公開アイテムとして公開された回数又はプレゼントされた回数が表示されてもよい。すなわち、各アイテムについて、過去にどのくらいプレゼント要求がなされたか、又は、過去にどのくらいプレゼントされたのか、などを示す指標又は数値が表示されてもよい。これにより、公開リスト画像６２を閲覧しているユーザに、指標又は数値が高いアイテムの購入（プレゼント）を促すことができる。さらに、プレゼント機能を使用することについて、各ユーザの抵抗感を下げることができる。

（第１実施形態の変形例８）
第１実施形態では、図１３に示すように、公開アイテム６２ａと所定の関係を有する関連アイテム６２ｂが、公開リスト画像６２に自動的に追加される例を示した。このとき、特定の関連アイテム６２ｂについては、自動的に第１ユーザにプレゼントするよう設定することも可能である。例えば、公開リスト画像６２において、公開アイテム６２ａに、プレゼントボタン６０５に加えて「最新刊をプレゼントする」などの表示と共にチェックボックスを設けてもよい。この場合、チェックボックスがチェックされると、対応する公開アイテム６２ａの最新刊がデータベース６００に登録されたとき、自動的に、その最新刊を関連アイテムとして第１ユーザにプレゼントすることができる。

チェックされた公開アイテム６２ａについては、そのアイテムに関する情報がスケジュール管理部５５７によって管理される。例えば、スケジュール管理部５５７は、アイテムに関する情報として、タイトル、最新刊の発行日、公開アイテム６２ａのチェックボックスにチェックをしたユーザに関する情報などをスケジュールリスト５５に格納する。ただし、この例に限られるものではなく、チェックされた公開アイテム６２ａの最新刊が発行されたときに、第２ユーザから第１ユーザに対してその最新刊が自動的にプレゼントされるように管理できれば、どのような管理方法を採用してもよい。

なお、本変形例では、チェックされた公開アイテム６２ａの最新刊が発行されたときに、自動的にプレゼントが行われることを例示したが、この例に限られるものではない。例えば、チェックされた公開アイテム６２ａのサイドストーリーなど、一連の作品とみなせるアイテムをプレゼントしたり、一連の作品であって第１ユーザが所持していない巻又は話を定期的にプレゼントしたりすることも可能である。

（第１実施形態の変形例９）
第１実施形態では、保持リスト５１に含まれる保持アイテムのうち選択したアイテムを「公開」に設定することにより公開指示を行う例を示したが、この例に限られるものではない。例えば、図１０に示した閲覧画像６０に「公開」又は「非公開」を設定するためのＵＩボタンを設け、図１１に示した保持リスト画像６１を経由することなく、閲覧画像６０から直接的に「公開」又は「非公開」の設定を行ってもよい。

このように「公開指示」は、選択したアイテムを公開リスト画像６２として他のユーザに公開するための指示であり、閲覧画像６０及び保持リスト画像６１のいずれからも実行することが可能である。

（第１実施形態の変形例１０）
第１実施形態で説明した保持リスト５１、公開リスト５２及び購入リスト５３は、それぞれファイル（データセット）として管理されてもよいが、この例に限らず、各アイテムをフラグで関連付けることにより管理してもよい。例えば、データベースに登録されたアイテムのうち、ユーザが保持指示を行ったアイテムに「保持」を示すフラグを設定する。この場合、「保持」のフラグを有するアイテムが保持アイテムに相当する。すなわち、第１ユーザ（ユーザＡ）に関連付けられ、かつ、「保持」のフラグが設定されたアイテムを抽出したリストが、図６に示した保持リスト５１Ａに対応する。このように、所定の用途に応じて設定されたフラグによってアイテムを管理することにより、情報量を抑制しつつ効率的なリスト管理を行うことができる。

ここでは保持リストを例示して説明したが、公開リスト５２及び購入リスト５３についても同様である。例えば、データベースに登録されたアイテムのうち、第１ユーザに関連付けられ、かつ「公開」を示すフラグを有するアイテムを抽出したリストが、図７に示した公開リスト５２Ａに相当する。また、データベースに登録されたアイテムのうち、第１ユーザに関連付けられ、かつ「購入済み」を示すフラグを有するアイテムを抽出したリストが、図８に示した購入リスト５３Ａに相当する。

以上のように、本変形例では、ユーザによって選択されたアイテムにフラグを設定することがリストの生成又は更新に対応する。例えば、保持リスト５１Ａが存在しない状態で第１ユーザが保持指示を行った場合、選択したアイテムに保持を示すフラグを設定することが、保持リスト５１Ａの生成を意味する。また、保持リスト５１Ａが存在する状態で第１ユーザが保持指示を行った場合、選択したアイテムに保持を示すフラグを設定することが、保持リスト５１Ａへの保持アイテムの追加（すなわち、保持リスト５１Ａの更新）を意味する。この点については、公開リスト５２Ａ及び購入リスト５３Ａについても同様である。

＜第２実施形態＞
本実施形態では、データベース６００に登録されるアイテムに認可前アイテムが含まれる場合の例について説明する。本実施形態の説明に用いる図面において、第１実施形態と同じ要素については同じ符号を用いて説明を省略する。

図１９は、本発明の一実施形態におけるサーバ５００の記憶部５０２ａに格納されるデータテーブルの一例を示す図である。図１９に示すように、本実施形態における記憶部５０２ａは、データテーブルとして、保持リスト５１、公開リスト５２、購入リスト５３、価格リスト５４、スケジュールリスト５５及び予約購入リスト５６を含む。データテーブルは、本実施形態の情報提供方法を実行する際に生成又は更新される。

予約購入リスト５６は、図８に示した購入リスト５３と同様の構成を有するデータテーブルであり、ユーザによって予約購入指示がなされた認可前アイテム（ユーザが認可後に購入する旨の意思表示をした認可前アイテム）を一時的に保持する。具体的には、予約購入リスト５６は、各ユーザに関連付けられ、購入の意思表示がなされた認可前アイテムに関する情報を格納する。

予約購入リスト５６に含まれる認可前アイテムは、当該認可前アイテムが公式アイテムとしてサービス提供者に認可されたとき（例えば、公式アイテムとしてデータベース６００に登録されたとき）、購入手続のための決済処理を経て購入リスト５３に追加される。ただし、この例に限られるものではなく、予約購入リスト５６に含まれる認可前アイテムは、公式アイテムとしてサービス提供者に認可されたとき、キャッシュレス決済（ポイント、コイン、チケット等の電子価値を対価とする購入手続）等の所定の手続を経て、購入リスト５３に追加されてもよい。

図２０は、本発明の一実施形態におけるサーバ５００が備える情報提供機能５５０ａの構成を示すブロック図である。情報提供機能５５０ａは、指示データ受信部５５１、制御データ送信部５５２、保持リスト管理部５５３、公開リスト管理部５５４、購入リスト管理部５５５、決済処理部５５６、通知処理部５５８、スケジュール管理部５５７、データベース管理部５５９及び予約購入リスト管理部５６０を含む。ただし、この例に限られるものではなく、情報提供機能５５０ａは、他の機能をさらに備えてもよいし、一部の機能を備えていなくてもよい。

予約購入リスト管理部５６０は、各ユーザに関連付けられた予約購入リスト５６の生成及び更新（追加及び削除を含む）を管理する。具体的には、予約購入リスト管理部５６０は、第１ユーザ又は他のユーザから予約購入指示を受けたとき、予約購入指示で選択されたアイテムを含む予約購入リスト５６の生成又は更新を行う。なお、認可前アイテムが公式化された場合とは、認可前アイテムが内容を維持したまま公式アイテムとして購入可能になった場合と、認可前アイテムと一連の作品であるとみなせる公式アイテムが購入可能になった場合とを含む。

他方、予約購入リスト管理部５６０は、予約購入リスト５６に含まれる予約購入アイテムについて、第１ユーザから解除指示（選択した予約購入アイテムの予約を解除する旨の指示）を受けたとき、解除指示で選択された予約購入アイテムを予約購入リスト５６から削除する。生成された予約購入リスト５６は、閲覧不能としてもよいし、第１ユーザ、又は、第１ユーザ及び他のユーザに対し閲覧可能としてもよい。

予約購入リスト管理部５６０は、予約購入リスト５６に含まれるアイテム（すなわち、認可前アイテム）が公式アイテムとして認可された場合に、認可されたアイテムを購入リスト管理部５５５に送信するとともに、予約購入リスト５６から削除する。購入リスト管理部５５５に送信されたアイテムは、決済処理を経た後、購入アイテムとして購入リスト５３に追加される。認可された公式アイテムの購入リスト管理部５５５への送信は、認可された公式アイテムの発行日又は認可日など、予め設定された日であってもよい。認可前アイテムが公式アイテムとして発行される日（例えば、データベース６００に登録される日）は、スケジュール管理部５５７によって管理される。

なお、本実施形態では、予約購入リストの管理を予約購入リスト管理部５６０が行う例を示すが、この例に限られるものではない。例えば、予約購入リスト管理部５６０を設けずに、購入リスト管理部５５５が、購入リスト５３の生成及び更新に加えて、予約購入リスト５６の生成及び更新を管理してもよい。

図２１は、第１ユーザの第１通信装置１００に表示されるＵＩ画像の一例を示す図である。具体的には、図２１は、ＵＩ画像として、データベース６００に登録された認可前アイテムの一部を表示する閲覧画像７０を表示している。閲覧画像７０は、第１通信装置１００の表示部１０３に表示される。

第１ユーザは、図２１に示した閲覧画像７０を用いて、気になる認可前アイテムを探すことができる。図２１において、「ＫＫＫＫ」は、データベース６００に登録された認可前アイテム（電子書籍）のタイトルであり、第１話から第４話まで４つのアイテムが表示されている。第１ユーザが閲覧画像７０を上方にスクロールさせると、第５話以降の他の認可前アイテムを表示させることができる。本実施形態では、図２１に示すように、各認可前アイテムには、応援ボタン７０１、保持ボタン７０２及び予約購入ボタン７０３が配置される。

図２１に示す閲覧画像７０において、第１ユーザが応援する認可前アイテムの応援ボタン７０１を押すと、選択された認可前アイテムを応援する旨の応援指示が第１ユーザの第１通信装置１００からサーバ５００に送信される。第１通信装置１００から送信された応援指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。制御部５０１は、各ユーザから送信される応援指示を集計し、応援指示に対応する認可前アイテムの人気等を評価することができる。サーバ５００が備える情報提供機能５５０は、応援指示を集計する応援管理部（図示せず）を含んでもよい。

また、閲覧画像７０において、第１ユーザが保持を希望する認可前アイテムの保持ボタン７０２を押すと、選択された認可前アイテムの保持指示が第１ユーザの第１通信装置１００からサーバ５００に送信される。第１通信装置１００から送信された保持指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。サーバ５００の制御部５０１（具体的には、保持リスト管理部５５３）は、保持指示を受信すると、保持指示によって選択された認可前アイテムを保持リスト５１Ａに追加する。これにより、第１ユーザに関連付けられた保持リスト５１Ａが更新される。

また、閲覧画像７０において、第１ユーザが購入を希望する認可前アイテムの予約購入ボタン７０３を押すと、選択された認可前アイテムの予約購入指示が第１ユーザの第１通信装置１００からサーバ５００に送信される。第１通信装置１００から送信された予約購入指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。サーバ５００の制御部５０１（具体的には、予約購入リスト管理部５６０）は、予約購入指示を受信すると、予約購入指示によって選択された認可前アイテムを予約購入リストに追加する。予約購入に関する事項については、後述する。

ここで、図２２は、第１ユーザの第１通信装置１００に表示されるＵＩ画像の一例を示す図である。具体的には、図２２は、ＵＩ画像として、第１ユーザに関連付けられた保持リスト５１Ａに対応する保持リスト画像７１を表示した例を示している。図２２に示す例では、認可前アイテムである保持アイテム７１ａと、通常のアイテムである保持アイテム７１ｂとが保持リスト画像７１に含まれている。各アイテムには、公開ボタン７０４及び非公開ボタン７０５が配置される。

保持リスト５１Ａが作成された後、第１ユーザが公開を希望する保持アイテム７１ａ又は７１ｂの公開ボタン７０４を押すと、選択された保持アイテム７１ａ又は７１ｂの公開指示が第１ユーザの第１通信装置１００からサーバ５００に送信される。第１通信装置１００から送信された公開指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。サーバ５００の制御部５０１（具体的には、公開リスト管理部５５４）は、公開指示を受信すると、公開指示によって選択されたアイテムを公開リスト５２Ａに追加する。これにより、第１ユーザに関連付けられた公開リスト５２Ａが更新される。

図２３は、第２ユーザの第２通信装置２００に表示されるＵＩ画像の一例を示す図である。具体的には、図２３は、ＵＩ画像として、第１ユーザに関連付けられた公開リスト５２Ａに対応する公開リスト画像７２を表示した例を示している。図２３に示すように、公開リスト画像７２は、公開アイテム７２ａ及び関連アイテム７２ｂを含む。図２３では、第１実施形態と同様に、公開アイテム７２ａと関連アイテム７２ｂとが区別できるように、関連アイテム７２ｂを強調表示している。関連アイテム７２ｂのうち、タイトル「ＫＫＫＫ」のアイテムは、認可前アイテムである。

本実施形態では、第１実施形態の図１３とは異なり、認可前アイテムにはプレゼント予約ボタン７０６ａが配置される。これに対し、通常のアイテムには、第１実施形態と同様に、プレゼントボタン７０６ｂが配置される。本実施形態の場合、第２ユーザがプレゼント予約ボタン７０６ａを押した場合とプレゼントボタン７０６ｂを押した場合とによって制御部５０１の実行する処理が異なる。

図２３において、第２ユーザが、第１ユーザにプレゼントしたいアイテムのプレゼントボタン７０６ｂを押すと、選択されたアイテムの購入指示が第２ユーザの第２通信装置２００からサーバ５００に送信される。第２通信装置２００から送信された購入指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。制御部５０１は、第２通信装置２００から購入指示を受信すると、購入指示によって選択されたアイテムについて決済処理を行い、決済処理完了後に、当該アイテムを第１ユーザに関連付けられた購入リスト５３Ａに追加する。これにより、第１ユーザに関連付けられた購入リスト５３Ａが更新される。このように、通常のアイテム（公式アイテム）の購入指示については、第１実施形態と同様に処理される。

これに対し、図２３において、第２ユーザが、プレゼント予約ボタン７０６ａを押すと、選択されたアイテムの予約購入指示が第２ユーザの第２通信装置２００からサーバ５００に送信される。第２通信装置２００から送信された予約購入指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。制御部５０１は、第２通信装置２００から予約購入指示を受信すると、予約購入指示によって選択されたアイテムを第１ユーザに関連付けられた予約購入リスト５６に追加する。ただし、第１ユーザに関連付けられた予約購入リスト５６が存在しない場合、予約購入指示によって選択されたアイテムを含む予約購入リスト５６が、第１ユーザに関連付けられて新たに生成される。

制御部５０１は、第１ユーザに関連付けられた予約購入リスト５６が生成又は更新されると、第１ユーザの閲覧画像７０を変更してもよい。具体的には、閲覧画像７０に表示される認可前アイテムのうち、予約購入リスト５６に含まれる予約購入アイテムについて、既に予約購入がなされた旨の表示を行ってもよい。

図２４は、第１ユーザの第１通信装置１００に表示されるＵＩ画像の一例を示す図である。制御部５０１は、図２４に示すように、保持ボタン７０２及び予約購入ボタン７０３に変えて、「予約購入済」等と表示したオブジェクト７０７を表示してもよい。この場合、例えば、オブジェクト７０７の色をグレーに表示して、当該オブジェクト７０７は操作できない旨を示してもよい。さらに、閲覧画像７０には、他のユーザによって公開アイテム７２ａ又は関連アイテム７２ｂが予約購入された旨の表示を行ってもよい。例えば、予約購入によりプレゼントされたアイテムに、他のユーザからプレゼントされた旨のメッセージを表示してもよい。

このように、制御部５０１は、第２ユーザの第２通信装置２００から予約購入指示があったことを第１ユーザの第１通信装置１００に送信してもよい。また、第１実施形態の変形例１と同様に、制御部５０１は、第２ユーザの第２通信装置２００から予約購入指示があったことを第１ユーザ及び第２ユーザとは異なる第３ユーザの第３通信装置３００に送信してもよい。

サーバ５００の制御部５０１（具体的には、予約購入リスト管理部５６０）は、予約購入リスト５６に含まれる認可前アイテムが公式アイテムとして認可されたことを契機として、認可されたアイテムを決済処理部５５６に送信する。決済処理部５５６において、送信されたアイテムの決済処理が終了したら、当該アイテムは購入リスト管理部５５５に送信される。その後、購入リスト管理部５５５は、決済処理の終了したアイテムを第１ユーザに関連付けられた購入リスト５３Ａに追加する。

以上のように、予約購入指示によって購入された認可前アイテムは、いったん予約購入リスト５６に格納され、公式アイテムとして認可されるまで購入手続が保留される。認可前アイテムが公式アイテムとして承認されるタイミングや公式アイテムとしてデータベース６００に登録されるタイミング等のスケジュールについては、スケジュール管理部５５７が管理する。

予約購入リスト管理部５６０は、スケジュール管理部５５７から、予約購入リスト５６に含まれる認可前アイテムが公式アイテムとして認可された旨の通知（例えば、公式アイテムとしてデータベース６００に登録された旨の通知）を受信すると、当該アイテムを決済処理に移行させる。このとき、予約購入リスト管理部５６０は、決済処理への移行を自動で行ってもよい。すなわち、予約購入リスト管理部５６０は、予約購入指示を行ったユーザに対してあらためて決済を行うか否かの確認をすることなく、認可されたアイテムを決済処理に移行させてもよい。予約購入リスト５６に含まれる認可前アイテムは、事前に購入の意思表示がなされているからである。ただし、予約購入リスト管理部５６０は、通知処理部５５８を介して、予約購入指示を行ったユーザに決済処理が行われた旨の通知を行ってもよい。これらの一連の処理は、図２１に示す閲覧画像７０で予約購入ボタン７０３が押された場合と、図２３に示す公開リスト画像７２でプレゼント予約ボタン７０６ａが押された場合とで同じである。

（第２実施形態の変形例１）
第２実施形態において、決済処理部５５６は、公開リスト画像７２を介して第１ユーザにプレゼントされたアイテムが通常の購入アイテムである場合と予約購入アイテムである場合とで、アイテムの購入価格を異ならせることが可能である。例えば、プレゼントされたアイテムが予約購入アイテムである場合、通常の購入アイテムである場合に比べて、購入価格を低くすることが可能である。通常の購入アイテムの価格及び予約購入アイテムの価格は、図１９に示した価格リスト５４に格納される。

（第２実施形態の変形例２）
第２実施形態において、通知処理部５５８は、公開リスト画像７２を介して第１ユーザにプレゼントされたアイテムが通常の購入アイテムである場合と予約購入アイテムである場合とで、プレゼントされた旨の通知の態様を異ならせることが可能である。例えば、図２３に示した公開リスト画像７２において、プレゼント予約ボタン７０６ａを押して公開アイテム７２ａを購入した場合と、プレゼントボタン７０６ｂを押して公開アイテム７２ａを購入した場合とで、図２４に示した閲覧画像７０のオブジェクト７０７の表示態様を異ならせることができる。プレゼント予約ボタン７０６ａ又はプレゼントボタン７０６ｂを押して関連アイテム７２ｂを購入した場合についても同様である。

上述の例は、プレゼントされた旨の通知を第１ユーザの第１通信装置１００に送信する場合について述べたが、この例に限られるものではなく、プレゼントされた旨の通知を第３ユーザの第３通信装置３００に送信する場合も同様である。

（第２実施形態の変形例３）
第２実施形態では、第１実施形態の変形例１と同様に、第１ユーザ及び第２ユーザ以外の第３ユーザが、第１ユーザに認可前アイテムのプレゼントがあったことを知ることができるようにしてもよい。例えば、第３通信装置３００の表示部１０２に公開リスト画像７２を表示する際、認可前アイテムである公開アイテム６２ａ又は関連アイテム６２ｂが購入された旨の表示を行ってもよい。その際、プレゼントしたユーザの氏名等を表示してもよい。さらに 、公開リスト画像７２には、過去に第１ユーザがプレゼントされた認可前アイテムの数が表示されてもよい。

本変形例によれば、第１ユーザの公開リスト画像７２を見た第３ユーザが、第１ユーザにプレゼントがあったことやプレゼントの数を視覚的に認識することができる。これにより、第３ユーザにおける第１ユーザへのプレゼント購入の意欲を高めることができる。

（第２実施形態の変形例４）
第２実施形態において説明したとおり、予約購入リスト管理部５６０は、スケジュール管理部５５７から予約購入リスト５６に含まれる認可前アイテムが公式アイテムとして認可された旨の通知を受信すると、自動的に当該アイテムを決済処理に移行させてもよい。しかしながら、例えば予約購入指示を行った時点ではポイント等の電子価値を十分所持していたものの、決済処理の段階では不足している事態も起こり得る。そのような場合、制御部５０１は、予約購入を行ったユーザの通信装置に、追加のポイント購入等を促す提案を表示したり、追加のポイント購入を行うためのＵＩオブジェクトを表示したりしてもよい。

また、ユーザが予約購入指示を行った際、当該ユーザのプロフィール画面等に所持しているポイント数などを表示させるとともに、そのうちのどの程度のポイントが予約購入によって消費されるかを表示させてもよい。これにより、例えばユーザが新たなアイテムを購入しようとしたとき、予約購入アイテムのために残しておくべきポイント数などを認識させることが可能である。さらに、ユーザが新たなアイテムを購入する際、所持しているポイントが不足している場合、予約購入のために確保してあるポイントの一部を使用するか否かを確認するメッセージを表示したり、当該ポイントの一部を使用するためのＵＩオブジェクトを表示したりしてもよい。

また、ユーザが予約購入指示を行った際に、予約購入アイテムの決済処理に必要なポイントを使用できないように凍結してもよい。この場合、予約購入アイテムが公式化されたときは、凍結したポイントと引き換えにアイテムが付与され、公式化されなかったときは、凍結したポイントを戻したり、他の電子価値に変換したりしてもよい。

＜第３実施形態＞
本実施形態では、公開アイテム又は関連アイテムを、予め購入するタイミングを設定して事前に購入する構成を備えた場合の例について説明する。本実施形態の説明に用いる図面において、第１実施形態と同じ要素については同じ符号を用いて説明を省略する。

図２５は、本発明の一実施形態におけるサーバ５００の記憶部５０２ｂに格納されるデータテーブルの一例を示す図である。図２５に示すように、本実施形態における記憶部５０２ｂは、データテーブルとして、保持リスト５１、公開リスト５２、購入リスト５３、価格リスト５４、スケジュールリスト５５及び事前購入リスト５７を含む。データテーブルは、本実施形態の情報提供方法を実行する際に生成又は更新される。

事前購入リスト５７は、図８に示した購入リスト５３と同様の構成を有するデータテーブルであり、ユーザが事前購入したアイテム（購入する日時を設定して事前に購入したアイテム）を一時的に保持する。具体的には、事前購入リスト５７は、各ユーザに関連付けられ、事前購入されたアイテムに関する情報を格納する。事前購入リスト５７に含まれるアイテム（事前購入アイテム）は、事前購入にあたって予め設定されたタイミングが到来したとき、購入手続のための決済処理を経て購入リスト５３に追加される。

図２６は、本発明の一実施形態におけるサーバ５００が備える情報提供機能５５０ｂの構成を示すブロック図である。情報提供機能５５０ｂは、指示データ受信部５５１、制御データ送信部５５２、保持リスト管理部５５３、公開リスト管理部５５４、購入リスト管理部５５５、決済処理部５５６、通知処理部５５８、スケジュール管理部５５７、データベース管理部５５９及び事前購入リスト管理部５６１を含む。ただし、この例に限られるものではなく、情報提供機能５５０ｂは、他の機能をさらに備えてもよいし、一部の機能を備えていなくてもよい。

事前購入リスト管理部５６１は、各ユーザに関連付けられた事前購入リスト５７の生成及び更新（追加及び削除を含む）を管理する。具体的には、事前購入リスト管理部５６１は、第１ユーザ又は他のユーザから事前購入指示（選択したアイテムを予め設定されたタイミングで購入する旨の指示）を受けたとき、事前購入指示で選択されたアイテムを含む事前購入リスト５７の生成又は更新を行う。

他方、事前購入リスト管理部５６１は、事前購入リスト５７に含まれる事前購入アイテムについて、第１ユーザから解除指示（選択した事前購入アイテムの購入を解除する旨の指示）を受けたとき、解除指示で選択された事前購入アイテムを事前購入リスト５７から削除する。生成された事前購入リスト５７は、閲覧不能としてもよいし、第１ユーザ、又は、第１ユーザ以外の他のユーザに対し閲覧可能としてもよい。

事前購入リスト管理部５６１は、事前購入リスト５７に含まれるアイテムについて予め設定されたタイミングが到来した場合に、対応する事前購入アイテムを購入リスト管理部５５５に送信するとともに、事前購入リスト５７から削除する。購入リスト管理部５５５に送信されたアイテムは、決済処理を経た後、購入アイテムとして購入リスト５３に追加される。

事前購入リスト５７に含まれるアイテムについて予め設定されたタイミングが到来したか否かは、スケジュール管理部５５７から通知される。すなわち、事前購入を行う際に設定される購入予定日等は、スケジュール管理部５５７によって管理される。スケジュール管理部５５７は、事前購入リスト５７に含まれる事前購入アイテムについて、予め設定されたタイミングが到来したとき、その旨を事前購入リスト管理部５６１に通知する。

なお、本実施形態では、事前購入リスト５７の管理を事前購入リスト管理部５６１が行う例を示すが、この例に限られるものではない。例えば、事前購入リスト管理部５６１を設けずに、購入リスト管理部５５５が、購入リスト５３の生成及び更新に加えて、事前購入リスト５７の生成及び更新を管理してもよい。

図２７は、第２ユーザの第２通信装置２００に表示されるＵＩ画像の一例を示す図である。具体的には、図２７は、ＵＩ画像として、第１ユーザに関連付けられた公開リスト５２Ａに対応する公開リスト画像８２を表示した例を示している。公開リスト画像８２は、３つの公開アイテム８２ａ及び３つの関連アイテム８２ｂを含む。公開アイテム８２ａ及び関連アイテム８２ｂには、プレゼントボタン８０１に加えて、事前購入のためのチェックボックス８０２が配置される。

チェックボックス８０２は、アイテムをプレゼントするタイミングを設定する際に使用するチェックボックスである。本実施形態では、第２ユーザがチェックボックス８０２にチェックを入れた状態でプレゼントボタン８０１を押すと、図２８に示すＵＩ画像が表示部１０３に表示される。

図２８は、第２ユーザの第２通信装置２００に表示されるＵＩ画像の一例を示す図である。具体的には、図２８は、ＵＩ画像として、購入予定日等の購入（プレゼント）のタイミングを設定するためのスケジュール設定画像８５を表示した例を示している。図２８に示す例では、図２７に示す公開リスト画像８２において、第２ユーザが、タイトル「ＡＡＡＡ」の公開アイテム８２ａについて事前購入指示を行ったものとする。

図２８に示すように、スケジュール設定画像８５には、アイテム欄８０５、入力欄８０６～８０８、送信ボタン８０９及びキャンセルボタン８１０が含まれる。アイテム欄８０５は、プレゼントするアイテムに関する情報を示す欄である。

入力欄８０６は、アイテムを購入する購入予定日等を設定する欄である。入力欄８０６は、例えばドロップダウンリストであり、各ボックスを選択して「日」、「時」及び「分」を入力することができる。これにより、選択したアイテムを第１ユーザにプレゼントする日時（タイミング）を設定することができる。ただし、この例に限らず、アイテムの購入予定日のみを指定する構成であってもよい。また、入力欄８０６には、購入予定日等に変えて、購入タイミングを特定する条件を設定してもよい。例えば、選択したアイテムの新刊が発売されたタイミングでプレゼントが実行されるように設定してもよい。この場合、入力欄８０６は、複数の条件から所望の条件を選択できるように構成してもよい。

入力欄８０７は、プレゼントするアイテムと一緒に送付するグリーティングカードなどを選択する欄である。「タップしてカードを選択する」と表示されたボックスをクリックすると、別のＵＩ画像（図示せず）に移行し、アイテムと一緒に送付するカードを選択することができる。

入力欄８０８は、プレゼントするアイテムに添えるメッセージを入力する欄である。「メッセージを記入してください」と表示されたボックスをクリックすると、入力欄８０８に直接メッセージを入力することができる。

送信ボタン８０９は、スケジュールの設定を完了させ、事前購入指示を送信するためのオブジェクトである。上述の入力欄８０６～８０８を用いて購入予定日等を設定した後、第２ユーザが送信ボタン８０９を押すと、選択されたアイテム及び設定されたスケジュールを含む事前購入指示がサーバ５００に送信される。事前購入指示の送信が完了すると、再び図２７に示した公開リスト画像８２が表示される。

キャンセルボタン８１０は、スケジュール入力をキャンセルするためのオブジェクトである。スケジュールの入力を途中でやめる際、キャンセルボタン８１０を押すと、スケジュールの設定が中断され、再び公開リスト画像８２が表示される。

上述したスケジュール設定画像８５の内容は、この例に限られるものではない。例えば、スケジュール設定画像８５は、上述した入力欄以外の他の入力欄を有していてもよいし、いくつかの入力欄が省略されていてもよい。また、本実施形態では、図２７に示した公開リスト画像８２からスケジュール設定画像８５に切り替わる例を示したが、この例に限らず、スケジュール設定画像８５をウィンドウ画面として公開リスト画像８２の一部に重畳表示させてもよい。

第２通信装置２００から送信された事前購入指示は、サーバ５００の通信部５０３を介して制御部５０１に受信される。制御部５０１は、第２通信装置２００から事前購入指示を受信すると、事前購入指示によって選択されたアイテムを事前購入リスト５７（図２５参照）に保持する。また、制御部５０１は、事前購入指示に設定されたスケジュールに関する情報（購入する日時や添付するメッセージ等）をスケジュールリスト５５（図２５参照）に保持する。

その後、スケジュール管理部５５７が、事前購入アイテムの購入タイミングの到来を事前購入リスト管理部５６１に通知すると、事前購入リスト管理部５６１は、事前購入リスト５７に保持された該当アイテムを決済処理部５５６に送信する。決済処理部５５６によってアイテムの決済処理が完了すると、決済後のアイテムに関する情報が購入リスト管理部５５５に送信され、第１ユーザに関連付けられた購入リスト５３に追加される。

以上のように、本実施形態では、公開リスト画像８２に含まれる各アイテムについて、事前に購入するタイミングを設定してプレゼントすることが可能である。これにより、例えば、誕生日、クリスマスなど、特定の日に合わせてプレゼントを贈ることができる。事前購入指示を出した後は、サーバ５００側でスケジュールを管理して購入手続を行うため、プレゼントを贈るユーザ（ここでは、第２ユーザ）の利便性が向上する。

（第３実施形態の変形例１）
第３実施形態において、決済処理部５５６は、公開リスト画像８２を介して第１ユーザにプレゼントされたアイテムが通常の購入アイテムである場合と事前購入アイテムである場合とで、アイテムの購入価格を異ならせることが可能である。例えば、プレゼントされたアイテムが事前購入アイテムである場合、通常の購入アイテムである場合に比べて、購入価格を高くしてもよい。事前購入アイテムの場合、グリーティングカードやメッセージを添付することで付加価値を高めるとともに、購入価格を高めに設定してプレゼントする側のユーザにも特別感を与えることができる。通常の購入アイテムの購入価格及び事前購入アイテムの購入価格は、図２５に示した価格リスト５４に格納される。

（第３実施形態の変形例２）
第３実施形態において、通知処理部５５８は、公開リスト画像８２を介して第１ユーザにプレゼントされたアイテムが通常の購入アイテムである場合と事前購入アイテムである場合とで、プレゼントされた旨の通知の態様を異ならせることが可能である。例えば、通常の購入アイテムの場合は、図１７に示した閲覧画像６０のように「Ｂさんからプレゼントされました！」等のメッセージを表示し、事前購入アイテムの場合は、購入タイミングまで通知は行わないようにしてもよい。また、通知処理部５５８は、購入タイミングが到来したとき、第１通信装置１００に表示された閲覧画像に「あなたの特別な日にＢさんからのプレゼントです」等のメッセージを表示してもよい。

上述の例は、プレゼントされた旨の通知を第１ユーザの第１通信装置１００に送信する場合について述べたが、この例に限られるものではなく、プレゼントされた旨の通知を第３ユーザの第３通信装置３００に送信する場合も同様である。

＜第４実施形態＞
第１実施形態から第３実施形態までは、サーバ５００が、アイテムとして電子書籍を提供するコンテンツサーバである例について説明したが、この例に限られるものではない。例えば、サーバ５００は、アイテムとして物品等を取り扱う電子商取引にも適用することができる。この場合、サーバ５００は、購入されたアイテムの決済処理が完了した後、購入者又はプレゼントの受贈者へのアイテムの配送手続を管理する手段を備えていてもよい。例えば、サーバ５００は、購入者又はプレゼント受贈者の住所等を含む伝票データを生成し、当該伝票データを外部の配送管理サーバ等に送信する配送管理部（図示せず）を備えていてもよい。

サーバ５００の提供するアイテムが物品等である場合、公開リストにおいて、数量を指定できるようにしてもよい。その際、プレゼントする側のユーザは、プレゼントするアイテムの数量を指定できるようにしてもよい。

以上、本発明について図面を参照しながら説明したが、本発明は前述の各実施形態（各変形例を含む。以下、同じ）に限られるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、各実施形態を基にして、当業者が適宜構成要素の追加、削除もしくは設計変更を行ったものも、本発明の要旨を備えている限り、本発明の範囲に含まれる。さらに、前述した各実施形態は、相互に矛盾がない限り適宜組み合わせが可能であり、各実施形態に共通する技術事項については、明示の記載がなくても各実施形態に含まれる。

前述した各実施形態の態様によりもたらされる作用効果とは異なる他の作用効果であっても、本明細書の記載から明らかなもの、又は、当業者において容易に予測し得るものについては、当然に本発明によりもたらされるものと解される。

５１、５１Ａ…保持リスト、５１ａ～５１ｆ…項目、５２、５２Ａ…公開リスト、５２ａ～５２ｆ…項目、５３、５３Ａ…購入リスト、５３ａ～５３ｆ…項目、５４…価格リスト、５５…スケジュールリスト、５６…予約購入リスト、５７…事前購入リスト、６０…閲覧画像、６１…保持リスト画像、６１ａ、６１ｂ…保持アイテム、６２…公開リスト画像、６２ａ…公開アイテム、６２ｂ…関連アイテム、７０…閲覧画像、７１…保持リスト画像、７１ａ、７１ｂ…保持アイテム、７２…公開リスト画像、７２ａ…公開アイテム、７２ｂ…関連アイテム、８２…公開リスト画像、８２ａ…公開アイテム、８２ｂ…関連アイテム、８５…スケジュール設定画像、１００…第１通信装置、１０１…制御部、１０２…記憶部、１０３…表示部、１０４…操作部、１０５…センサ部、１０６…撮像部、１０７…位置検出部、１０８…通信部、１０９…音入出力部、１１０…報知部、２００…第２通信装置、３００…第３通信装置、５００…サーバ、５０１…制御部、５０２、５０２ａ、５０２ｂ…記憶部、５０３…通信部、５５０、５５０ａ、５５０ｂ…情報提供機能、５５１…指示データ受信部、５５２…制御データ送信部、５５３…保持リスト管理部、５５４…公開リスト管理部、５５５…購入リスト管理部、５５６…決済処理部、５５７…スケジュール管理部、５５８…通知処理部、５５９…データベース管理部、５６０…予約購入リスト管理部、５６１…事前購入リスト管理部、６００…データベース、６０１…保持ボタン、６０２…購入ボタン、６０３…公開ボタン、６０４…非公開ボタン、６０５…プレゼントボタン、６０５ａ、６０６、６０７…オブジェクト、６０８、６０９…メッセージ、７０１…応援ボタン、７０２…保持ボタン、７０３…予約購入ボタン、７０４…公開ボタン、７０５…非公開ボタン、７０６ａ…プレゼント予約ボタン、７０６ｂ…プレゼントボタン、７０７…オブジェクト、８０１…プレゼントボタン、８０２…チェックボックス、８０５…アイテム欄、８０６～８０８…入力欄、８０９…送信ボタン、８１０…キャンセルボタン、１０００…通信システム

Claims (20)

1. コンピュータに、
   少なくとも１つのアイテムを公開する旨の公開指示を、第１ユーザの第１通信装置から受信し、
   前記公開指示に基づいて、前記公開指示により指定された少なくとも１つの公開アイテムを含み、前記第１ユーザに関連付けられた公開リストを生成又は更新し、
   前記公開アイテムと所定の関係を有する購入対象である少なくとも１つの関連アイテムを、前記公開指示の有無にかかわらず前記公開リストに追加すること、
   を含む、情報提供方法を実行させるためのプログラム。
2. 前記公開指示は、第１ユーザに関連付けられた保持リストに含まれる保持アイテムの少なくとも１つを公開する旨の指示である、請求項１に記載のプログラム。
3. 前記情報提供方法は、
   第２ユーザの要求に基づいて、前記公開リストに関する情報を前記第２ユーザの第２通信装置に送信し、
   前記公開リストに含まれる前記公開アイテムの少なくとも１つを購入する旨の購入指示を前記第２通信装置から受信し、
   前記購入指示により指定された購入アイテムを前記第１ユーザに関連付けられた購入リストに追加すること、
   をさらに含む、請求項１又は２に記載のプログラム。
4. 前記購入アイテムが前記公開アイテムである場合と前記関連アイテムである場合とで購入の価格が異なる、請求項３に記載のプログラム。
5. 前記情報提供方法は、前記公開アイテムが購入された旨の通知を前記第１通信装置に送信すること、
   をさらに含む、請求項３又は４に記載のプログラム。
6. 前記情報提供方法は、前記第１ユーザと所定の関係を有する第３ユーザの第３通信装置の表示部に前記公開リストに基づく画像を表示することをさらに含み、
   前記公開リストに基づく画像は、前記公開アイテムの少なくとも１つが購入された旨の表示、又は、過去に購入された前記公開アイテムの数を含む、請求項３乃至５のいずれか一項に記載のプログラム。
7. 前記購入アイテムが前記公開アイテムである場合と前記関連アイテムである場合とで前記公開アイテムが購入された旨の通知の態様が異なる、請求項５又は６に記載のプログラム。
8. 第１ユーザに関連付けられた保持リストに含まれる保持アイテムは、認可前アイテムを含み、
   前記情報提供方法は、
   前記認可前アイテムの少なくとも１つを認可後に購入する旨の予約購入指示を前記第１通信装置から受信し、
   前記第１通信装置から受信した前記予約購入指示に基づいて、当該予約購入指示により指定された少なくとも１つの予約購入アイテムを含み、前記第１ユーザに関連付けられた予約購入リストを生成又は更新すること、
   をさらに含む、請求項３乃至７のいずれか一項に記載のプログラム。
9. 前記公開リストに含まれる前記公開アイテム又は前記関連アイテムは、認可前アイテムを含み、
   前記情報提供方法は、
   前記認可前アイテムの少なくとも１つを購入する旨の予約購入指示を前記第２通信装置から受信し、
   前記第２通信装置から受信した前記予約購入指示に基づいて、当該予約購入指示により指定された少なくとも１つの予約購入アイテムを含み、前記第１ユーザに関連付けられた予約購入リストを生成又は更新すること、
   をさらに含む、請求項３乃至８のいずれか一項に記載のプログラム。
10. 前記情報提供方法は、前記予約購入指示を前記第２通信装置から受信した旨の通知を前記第１通信装置に送信すること、
    をさらに含む、請求項９に記載のプログラム。
11. 前記情報提供方法は、前記第１ユーザと所定の関係を有する第３ユーザの第３通信装置の表示部に前記公開リストに基づく画像を表示することをさらに含み、
    前記公開リストに基づく画像は、前記認可前アイテムの少なくとも１つが予約購入された旨の表示、又は、過去に予約購入された前記認可前アイテムの数を含む、請求項９又は１０に記載のプログラム。
12. 前記購入アイテムと前記予約購入アイテムとで前記予約購入指示を前記第２通信装置から受信した旨の通知の態様が異なる、請求項１０又は１１に記載のプログラム。
13. 前記情報提供方法は、前記予約購入アイテムのうち公式アイテムとして認可されたアイテムを前記第１ユーザに関連付けられた前記購入リストに追加すること、
    をさらに含む、請求項８乃至１２のいずれか一項に記載のプログラム。
14. 前記購入アイテムと前記予約購入アイテムとで購入の価格が異なる、請求項８乃至１３のいずれか一項に記載のプログラム。
15. 前記情報提供方法は、
    前記公開リストに含まれる前記公開アイテムの少なくとも１つを、予め設定されたタイミングで購入する旨の事前購入指示を前記第２通信装置から受信し、
    前記事前購入指示により指定された事前購入アイテムを、前記予め設定されたタイミングで前記第１ユーザに関連付けられた前記購入リストに追加すること、
    をさらに含む、請求項３乃至１４のいずれか一項に記載のプログラム。
16. 前記情報提供方法は、
    データベースに登録された複数のアイテムの少なくとも１つを保持する旨の保持指示を前記第１ユーザの第１通信装置から受信し、
    前記保持指示に基づいて、前記保持指示により指定された少なくとも１つの保持アイテムを含み、前記第１ユーザに関連付けられた保持リストを生成又は更新すること、
    をさらに含む、請求項１乃至１５のいずれか一項に記載のプログラム。
17. 前記情報提供方法は、
    新たなアイテムを前記データベースに登録すること、及び、前記関連アイテムが前記新たなアイテムとして前記データベースに登録されると、前記関連アイテムを前記公開リストに追加すること、
    をさらに含む、請求項１６に記載のプログラム。
18. 前記情報提供方法は、
    前記公開リストが生成又は更新されると、前記公開リストの生成又は更新を通知する通知指示を、前記第１ユーザと所定の関係を有する第３ユーザの第３通信装置に送信すること、
    をさらに含む、請求項１乃至１７のいずれか一項に記載のプログラム。
19. 前記公開アイテムが電子書籍である場合において、前記関連アイテムは、前記公開アイテムの最新分、修正分もしくは不足分、前記公開アイテムに付随する商品、又は、前記公開アイテムの代替品を含む、請求項１乃至１８のいずれか一項に記載のプログラム。
20. 請求項１乃至１９のいずれか一項に記載のプログラムを実行する制御部を備えたサーバ。

Images