JP7692016B2 - プログラム、方法、およびシステム - Google Patents

Description

特許法第３０条第２項適用 カバー株式会社が、本願発明を以下のとおり公開した。 「プレス発表」：２０２３年２月１７日、ｈｔｔｐｓ：／／ｐｒｔｉｍｅｓ．ｊｐ／ｍａｉｎ／ｈｔｍｌ／ｒｄ／ｐ／００００００９００．００００３０２６８．ｈｔｍｌ、「自社ホームページ」：２０２３年２月１７日、２０２３年２月２２日、２０２３年３月２７日、２０２３年７月７日、ｈｔｔｐｓ：／／ｃｏｖｅｒ－ｃｏｒｐ．ｃｏｍ／ｎｅｗｓ／ｄｅｔａｉｌ／２０２３０２１７、ｈｔｔｐｓ：／／ｃｏｖｅｒ－ｃｏｒｐ．ｃｏｍ／ｂｕｓｉｎｅｓｓ／ｖｔｕｂｅｒ、ｈｔｔｐｓ：／／ｈｏｌｏｌｉｖｅｓｕｐｅｒｅｘｐｏ２０２３．ｈｏｌｏｌｉｖｅｐｒｏ．ｃｏｍ／ｎｅｗｓ／ｈｏｌｏｐｌｕｓ／、ｈｔｔｐ：／／ｈｏｌｏｐｌｕｓ．ｃｏｍ／、「ツイッター」：２０２３年２月１８日、２０２３年３月２８日、ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ｈｏｌｏｌｉｖｅｔｖ／ｓｔａｔｕｓ／１６２６９１４６７７１７４１８１８８９？ｓ＝２０、ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ｈｏｌｏｌｉｖｅｔｖ／ｓｔａｔｕｓ／１６４０６５４９７４５５９６０８８３２？ｓ＝２０、「ＹＯＵＴＵＢＥ」：２０２３年２月１８日、２０２３年２月２８日、２０２３年３月１９日、ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｌｉｖｅ／ｒｘＸｊｐＴｈＣｇＵＹ？ｆｅａｔｕｒｅ＝ｓｈａｒｅ＆ｔ＝２８７６ ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｌｉｖｅ／ＸＭｏ４ｈ－ｐｄＣＭ８？ｓｉ＝ＦＲｎ＿０ＤＡｄＰＦｕ５ｌｖｔｋ、ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｌｉｖｅ／ＣＷＣａＩＫｉｗＵ３Ｕ？ｆｅａｔｕｒｅ＝ｓｈａｒｅ、アプリケーション「ホロプラス」のベータ版アプリのダウンロード用ＵＲＬをユーザにメール配信：２０２３年３月１６日、ｈｔｔｐｓ：／／ａｐｐｓ．ａｐｐｌｅ．ｃｏｍ／ｊｐ／ａｐｐ／ｔｅｓｔｆｌｉｇｈｔ／ｉｄ８９９２４７６６４、ｈｔｔｐｓ：／／ｐｌａｙ．ｇｏｏｇｌｅ．ｃｏｍ／ｓｔｏｒｅ／ａｐｐｓ／ｄｅｔａｉｌｓ？ｉｄ＝ｃｏｍ．ｃｏｖｅｒ＿ｃｏｒｐ．ｈｏｌｏｐｌｕｓ

特許法第３０条第２項適用 カバー株式会社が、本願発明を以下のとおり公開した。決算説明資料：２０２３年５月１２日、２０２３年３月期決算発表時、自社ＩＲニュースページ：２０２３年８月９日、ｈｔｔｐｓ：／／ｗｗｗ．ｎｉｋｋｅｉ．ｃｏｍ／ｎｋｄ／ｄｉｓｃｌｏｓｕｒｅ／ｔｄｎｒ／２０２３０５１２５７００２９／、ｈｔｔｐｓ：／／ｆｉｎａｎｃｅ．ｌｏｇｍｉ．ｊｐ／３７８１６７、ｈｔｔｐｓ：／／ｃｏｖｅｒ－ｃｏｒｐ．ｃｏｍ／ｉｒ、自社主催イベント「ｈｏｌｏｌｉｖｅ ＳＵＰＥＲ ＥＸＰＯ ２０２３ Ｓｕｐｐｏｒｔｅｄ Ｂｙ Ｂｕｓｈｉｒｏａｄ」：２０２３年３月１９日、幕張メッセ 国際展示場

本発明は、プログラム、方法、およびシステムに関する。

タレントなどの人やモノなど好きな応援対象（所謂推し）を応援するファン活動（所謂推し活）において、例えばＳＮＳなどから応援対象であるタレント本人の投稿や、応援対象のタレントが所属する事務所等のアカウントからの投稿をチェックすることで、応援対象の最新情報を収集することが主流となっている（例えば、非特許文献１、および、非特許文献２参照）。

"Twitter - Official Site"、［ｏｎｌｉｎｅ］、［令和５年７月２１日検索］、インターネット＜https://twitter.com/i/flow/login?redirect_after_login=%2F＞ "イマドキの若い女性の推し活に欠かせないSNS"、［ｏｎｌｉｎｅ］、［令和５年７月２１日検索］、インターネット＜https://news.mynavi.jp/article/womansns-50/＞

しかしながら、従来の情報収集方法では、応援対象に関するグッズ情報や配信情報などに限らず、日常的な投稿や、応援対象とは関係のない情報など様々な投稿が混在するため、ユーザは目的とする情報にすぐに辿り着き難いことがある。また、ユーザがフォローしていないアカウントによってユーザの応援対象に関する情報の投稿があったとしても、非フォローアカウントの投稿であるため、ユーザは見逃してしまう虞があった。また、手入力で条件を毎回設定して検索をする手間を生じさせてしまう。

本発明は、かかる実情に鑑み考え出されたものであり、好みの情報を容易に特定可能とするプログラム、方法、およびシステムを提供するものである。

（１） 本発明のある局面にしたがうプログラムは、属性が関連付けられた複数種類のコンテンツ（例えば、ニュース記事、投稿記事、動画など）をユーザに提供可能とするプログラム（例えば、記憶部１２０に記憶されているプログラム、コンテンツを提供するためのプログラムなど）であって、
前記属性は、複数種類の第１属性（例えば、図５のタレント情報データベースの所属グループ１に対応する図６（Ａ）のコミュニティＡ、コミュニティＢなど）と、複数種類の第２属性（例えば、図５のタレント情報データベースに記憶されるタレント、あるいは、所属グループ２のユニットなど）とを含み、
コンピュータ（例えば、配信サーバ１００、ユーザ端末３００）を、
前記複数種類の第１属性および前記複数種類の第２属性のうちから、前記ユーザからの操作に応じて予め選択された属性（例えば、図６の属性選択画面において、図９のステップＳ１０３、ステップＳ１０７などで選択された参加コミュニティおよび推しタレントなど）を特定可能に記憶するための記憶手段（例えば、アカウント管理部１３３は、図９のステップＳ１０４、ステップＳ１０８において、アカウント情報１２５として記憶する図７のユーザ情報データベースに、参加コミュニティおよび推しタレントＩＤをユーザＩＤに関連付けて記憶）と、
所定条件の成立（例えば、図１０のホーム画面や、図１１のコミュニティ画面、図２７の配信スケジュール画面に表示される推しフィルター２０に対するオンオフ操作）に応じて、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられたコンテンツに関するコンテンツ情報（例えば、図７のユーザ情報データベースに記憶されるユーザが予め選択した参加コミュニティ内に投稿されているコンテンツのコンテンツ見出し（６０，７０，９０））を当該ユーザが特定可能となる第１表示状態（例えば、図１６のステップＳ２０３により、図１０のホーム画面や図１１のコミュニティ画面を図１５（Ｂ）のように推しフィルター２０オフの状態で表示）と、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツに関するコンテンツ情報（例えば、図７のユーザ情報データベースに記憶される、ユーザが予め選択した参加コミュニティ内に投稿されているコンテンツであって、ユーザが予め選択した推しタレントのタレントＩＤが関連付けられた図１４の記事のコンテンツ見出し（６０，７０，９０））を当該ユーザが特定可能となる第２表示状態（例えば、推しフィルター２０をオンにする操作により、図１６のステップＳ２０４によって、図１５（Ａ）の推しフィルター２０がオン状態の画面）とを含む複数種類の表示状態のいずれかに切り替えて表示するための表示切替手段（例えば、コンテンツ管理部１３２、アカウント管理部１３３、入力情報送信部３５３、表示制御部３５２）として機能させ、
前記複数種類の第１属性は、各々、前記複数種類の第２属性の少なくともいずれかを含むグループであり、前記複数種類の第２属性は、各々、前記複数種類の第１属性に対応する複数種類のグループの少なくともいずれかに所属し得る属性である。

このような構成によれば、ユーザにより予め選択された第１属性が関連付けられたコンテンツに関するコンテンツ情報と、ユーザにより予め選択された第１属性および第２属性が関連付けられたコンテンツに関するコンテンツ情報とを切り替えて表示可能となる。これにより、ユーザは好みの情報を容易に特定可能となる。

（２） 上記（１）において、前記所定条件は、前記ユーザが属性を予め選択するときの一連の操作（例えば、図９の属性選択処理における操作）とは異なる操作であって、当該ユーザからの切替操作（例えば、推しフィルター２０への選択操作）に応じて成立する条件を含む。

このような構成によれば、表示する際に改めてユーザが属性を選択する操作などを要することなく、予め選択しておいた属性が関連付けられたコンテンツに関するコンテンツ情報に切り替えて表示させることができるため、操作性・ユーザの利便性を向上させることができる。

（３） 上記（２）において、前記表示切替手段は、前記第１表示状態および前記第２表示状態のいずれにおいても前記切替操作を受け付けるアイコンを表示し（例えば、図１５の推しフィルター２０がオンの状態（Ａ）であっても、オフの状態（Ｂ）であっても、推しフィルター２０は表示）、前記第１表示状態におけるアイコンへの操作（例えば、図１５（Ｂ）の推しフィルター２０がオフの状態における推しフィルター２０への操作、図１６のステップＳ２０１）に応じて前記第２表示状態（例えば、図１５（Ａ）の推しフィルター２０がオンの状態、図１６のステップＳ２０４）に切り替えて表示し、前記第２表示状態におけるアイコンへの操作に応じて前記第１表示状態に切り替えて表示（例えば、図１５（Ａ）の推しフィルター２０がオンの状態で、推しフィルター２０への操作によって、ステップＳ２０２、ステップＳ２０３で、図１５（Ｂ）の推しフィルターオフの状態で表示）する。

このような構成によれば、切り替えを簡易化・容易化できる。

（４） 上記（１）において、前記複数種類のコンテンツには、前記第１属性および前記第２属性とは異なる第３属性が関連付けられているコンテンツ（例えば、図６（Ａ）に例示する、常に参加状態であるコミュニティＰ内に投稿されたコンテンツ、図１０のホーム画面において参加しているコミュニティにかかわらず表示されるフィーチャー６１）を含み、
前記表示切替手段は、前記第３属性が関連付けられているコンテンツに関するコンテンツ情報については、前記ユーザにより予め選択されて記憶されている属性にかかわらず、前記第１表示状態および前記第２表示状態のいずれにおいても特定可能となるように表示（例えば、コミュニテＰ内に投稿されたコンテンツや、フィーチャー６１は、ユーザが予めいずれの参加コミュニティ、および、推しタレントを選択しているかにかかわらず表示される）する。

このような構成によれば、ユーザが予め選択しておいた属性とは異なる属性に関するコンテンツ情報も表示され得るようにすることで、切り替えの状態にかかわらず例えば運営者が全ユーザに知らせたい情報をユーザに報知することが可能となる。

（５） 上記（１）において、前記複数種類のコンテンツには、前記第１属性および前記第２属性のうち第１属性のみが関連付けられているコンテンツ（例えば、図１４、図２５の記事ａ９９など、関連タレントが誰も関連付けられていないコンテンツ）を含み、
前記第２表示状態は、前記第１属性のみが関連付けられているコンテンツに関するコンテンツ情報の表示を含まない（例えば、参加コミュニティ内に投稿されたコンテンツであっても、関連タレントがいずれも関連付いていないコンテンツのコンテンツ見出しは表示されない）表示状態である。

このような構成によれば、第２表示状態においては、第２属性まで関連付けられていないコンテンツに関するコンテンツ情報が表示されないため、ユーザは好みの第１属性および第２属性が関連付けられた情報を特定することが容易となる。

（６） 上記（１）において、前記複数種類の第２属性とは、複数種類のキャラクタ（例えば、図５の各タレント）であり、
前記複数種類の第１属性とは、前記第２属性であるキャラクタを区分けする複数種類のグループ（例えば、図５の各タレントを区分けする所属グループ１（グループＡ、グループＢなど））である。

このような構成によれば、キャラクタを区分けするグループに関する情報から、さらにユーザ好みのキャラクタの情報に絞った情報を特定することが可能となる。

（７） 上記（１）において、前記複数種類の第２属性には、複数のキャラクタからなる属性（例えば、図５の所属グループ２などのユニット（１期生、２期生など））が含まれる。

このような構成によれば、キャラクタを区分けするグループに関する情報から、さらにユーザ好みの複数のキャラクタからなる属性の情報に絞った情報を特定することが可能となる。

（８） 上記（１）において、前記複数種類のコンテンツは、特定種類のカテゴリ（例えば、図１０のホーム画面の推しトピック６２）を含む複数種類のカテゴリ（例えば、図１０の人気のユーザ投稿６３、記念配信６４、グッズ６５など）のいずれかに分類可能であり、
前記表示切替手段は、コンテンツに関するコンテンツ情報を前記複数種類のカテゴリ毎に分類して表示可能であり（例えば、図１０のホーム画面）、特定種類のカテゴリにおいては、前記第１表示状態および前記第２表示状態のいずれにおいても、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツのうちの所定数のコンテンツに関するコンテンツ情報を当該ユーザが特定可能となるように表示し（例えば、推しフィルター２０のオンあるいはオフのいずれの状態であるかにかかわらず、推しトピック６２には、ユーザが予め選択した参加コミュニティ内に投稿され、ユーザが予め選択した推しタレントが関連付けられたコンテンツのコンテンツ見出し６０が所定数表示され得る）、前記特定種類のカテゴリ以外のカテゴリにおいては、前記第１表示状態および前記第２表示状態のいずれであるかに応じたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となるように表示する（例えば、推しトピック６２以外のカテゴリは、推しフィルター２０のオンオフ操作によって、表示されるコンテンツ見出し６０が切り替わる）。

このような構成によれば、ユーザが予め選択している第１属性および第２属性が関連付けられたコンテンツのうちの一部が、表示状態の切替操作をせずとも表示可能となるため、切替操作の手間なく、ユーザは好みの第１属性および第２属性が関連付けられたコンテンツを特定可能となる。

（９） 上記（８）において、前記表示切替手段は、前記第１表示状態および前記第２表示状態のいずれにおいても、前記特定種類のカテゴリに分類されるコンテンツに関するコンテンツ情報（例えば、推しトピック６２に表示されるコンテンツ見出し６０）を、他のカテゴリに分類されるコンテンツに関するコンテンツ情報よりも優先して表示可能（例えば、図１０に例示するように他のカテゴリよりも表示順位が上である）とする。

このような構成によれば、ユーザは好みの第１属性および第２属性が関連付けられたコンテンツの特定が容易となる。

（１０） 上記（１）において、前記第１表示状態は、前記ユーザにより予め選択されて記憶されている第１属性のうち（例えば、図９の属性選択処理によって図７のユーザ情報データベースに記憶されているユーザが予め選択した参加コミュニティのうち）、ユーザからの操作に応じて選択された第１属性が関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる表示状態（例えば、参加コミュニティとしてコミュニティＡと、コミュニティＢとを選択していれば、さらに図１２のチャンネル一覧画面からコミュニティを個別に選択して、個々のコミュニティの画面（図１１に例示するコミュニティ画面）が、表示。あるいは、コミュニティアイコン１４に対する選択操作により、図１２のチャンネル一覧画面で、コミュニティバー８１を選択したコミュニティの画面が表示）を含む。

このような構成によれば、ユーザが予め選択した第１属性の中から、さらに好みの第１属性を選択して、当該さらに選択した第１属性毎のコンテンツ情報を表示させることができるため、ユーザは好みの情報の中からであってもさらに必要に応じて、さらに任意の情報を抽出可能となり、利便性が向上する。

（１１） 上記（１）において、前記第２表示状態は、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のうち（例えば、図９の属性選択処理によって図７のユーザ情報データベースに記憶されている推しタレントのうち）、ユーザからの操作に応じて選択された属性が関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる表示状態に切り替えて表示可能となる表示状態（例えば、推しタレントに複数人選択していたとしても、さらにタレント個々（例えば最推しタレントなど）に絞りこむことができる。変形例（属性抽出処理について）参照）を含む。

このような構成によれば、ユーザが予め選択した第２属性の中から、さらに好みの第２属性を選択して、当該さらに選択した第２属性毎のコンテンツ情報を表示させることができるため、ユーザは好みの情報の中からであってもさらに必要に応じて、さらに任意の情報を抽出可能となり、利便性が向上する。

（１２） 上記（１）において、前記コンピュータを、
前記コンテンツに対する前記ユーザからの好感アクション（例えば、図２４などのアイコン７０８に対するタップアクション））を受け付ける度に受付演出（例えば、図２４（Ａ）のアイコンやファンマークの出現や、図２４（Ｂ）の豪華演出、図２６のタップアクション演出処理）を行うための手段として機能させ、
前記受付演出は、前記アクションを受け付けたコンテンツに関連付けられている前記第２属性に関する演出（例えば、タップアクションがされたコンテンツに関連タレントが関連付けられていれば、図２５の記事ａ１に例示するように、各タレントに対応したファンマークの演出（図２４のファンマーク４２など）や、タレント演出がなされる）を含む。

このような構成によれば、受付演出に第２属性に関する演出が含まれているため、ユーザに対してアクションを取るよう促すことが可能となる。

（１３） 上記（１２）において、前記受付演出を行うための手段は、前記アクションを所定回数（例えば、タップ回数１００回）受け付けたときに、特別受付演出（例えば、図２４（Ｂ）、図２５の豪華演出、タレント演出、図２６のステップＳ５０８～ステップＳ５１３など）を行う。

このような構成によれば、アクションを所定回数行えば特別受付演出が行われるため、ユーザに対してアクションを取るよう促すことが可能となる。

（１４） 上記（１）において、前記複数種類のコンテンツは、前記複数種類の第２属性のいずれかが関連付けられている第２属性関連コンテンツ（例えば、図１４の関連タレントが関連付けられているコンテンツ）を含み、
前記表示切替手段は、前記第１表示状態および前記第２表示状態のいずれにおいても前記第２属性関連コンテンツに関するコンテンツ情報について、当該第２属性関連コンテンツに関連付けられている第２属性を特定可能となるように表示（例えば、推しフィルター２０がオンあるいはオフのいずれの状態であっても、コンテンツ見出し（６０，７０，９０）などに、関連タレント８８（出演関連タレント９４）が表示される）する。

このような構成によれば、ユーザは第１表示状態および第２表示状態のいずれにおいても第２属性関連コンテンツに関連付けられている第２属性を特定可能であるため、ユーザの利便性が向上する。

（１５） 上記（１）において、前記複数種類のコンテンツは、ユーザから投稿される投稿コンテンツを含み（例えば、図１４の投稿権限ユーザの記事など）、
前記コンピュータを、
前記ユーザからの投稿情報（例えば、図１８のステップＳ３１３で送信されるテキストや画像、カテゴリ、関連タレント、ユーザＩＤなどを特定するための投稿情報）に応じた投稿コンテンツに関するコンテンツ情報を生成するための手段（例えば、コンテンツ管理部１３２、入力情報送信部３５３）であって、当該投稿情報に第２属性を指定するための情報が含まれる場合に（例えば、図１７の関連タレントバー４０への操作、図１８のステップＳ３１０、ステップＳ３１１）当該投稿コンテンツが当該指定された第２属性が関連付けられたコンテンツに関するコンテンツ情報として生成（例えば、図１４のコンテンツデータベースに、関連タレントに選択されたタレントのタレントＩＤを関連付けて記憶して、図１０のホーム画面や図１１のコミュニティ画面において、コンテンツ見出し（６０，７０）を表示）するための手段（例えば、コンテンツ管理部１３２、入力情報送信部３５３）として機能させる。

このような構成によれば、ユーザ投稿にも第２属性を関連付けることができるため、ユーザ間において好みの情報の共有が容易となる。

（１６） 上記（１）において、前記複数種類のコンテンツは、ユーザから投稿される投稿コンテンツを含み（例えば、図１４の投稿権限ユーザの記事など）、
前記ユーザには、複数の特定ユーザが含まれ、
前記コンピュータを、
前記投稿コンテンツに関するコンテンツ情報に対するアクション（例えば、コメントやタップアクション）を受け付けるための手段（例えば、コンテンツ管理部１３２、入力部３３０）として機能させ、
前記複数種類の第２属性とは、前記複数の特定ユーザ各々に対応する複数種類のキャラクタ（例えば、特定ユーザは、図５のタレント各々に対応）であり、
前記表示切替手段は、前記投稿コンテンツに関するコンテンツ情報に対して前記特定ユーザからアクションを受け付けたことに応じて、当該投稿コンテンツに関するコンテンツ情報の表示態様を異なる表示態様に変化させて表示する（例えば、タレントに対応するユーザからアクションがあった場合には、コンテンツ見出し（６０，７０，９０）に、特別アクション７９を表示する）。

このような構成によれば、ユーザは、特定ユーザがアクションを行った投稿コンテンツであることを容易に特定可能となる。そのため、第２属性に関する情報を求めるユーザにとって利便性が向上する。また、ユーザが行った投稿コンテンツに対して特定ユーザからのアクションがあれば、ユーザは特別感を得ることができる。

（１７） 上記（１６）において、前記表示切替手段は、前記投稿コンテンツに関するコンテンツ情報に対して前記特定ユーザからアクションを受け付けたことに応じて、当該投稿コンテンツに関するコンテンツ情報の表示態様を、当該特定ユーザが前記ユーザにより予め選択されて記憶されている第２属性に対応する特定ユーザであるか否かに応じて異なる表示態様に変化させて表示する（例えば、コンテンツに対してアクションを行ったタレントが推しタレントであれば、推しタレントでなかった場合とは表示態様を変化させる。変形例（ホーム画面やコミュニティ画面などにおける特別アクションの表示態様について）参照）。

このような構成によれば、ユーザは、ユーザが予め選択した第２属性に対応する特定ユーザがアクションを行った投稿コンテンツであることを容易に特定可能となる。そのため、第２属性に関する情報を求めるユーザにとって利便性が向上する。また、ユーザが行った投稿コンテンツに対してアクションを行った特定ユーザが、ユーザが予め選択した第２属性に対応する特定ユーザであることを認識することができ、ユーザはさらなる特別感を得ることができる。

（１８） 上記（１６）において、前記表示切替手段は、前記投稿コンテンツに関するコンテンツ情報に対して前記特定ユーザからアクションを受け付けたことに応じて、当該投稿コンテンツに関するコンテンツ情報の表示態様を、当該特定ユーザが前記投稿コンテンツに関連付けられている第２属性に対応する特定ユーザであるか否かに応じて異なる表示態様に変化させて表示する（例えば、コンテンツに対してアクションを行ったタレントがコンテンツに関連付けられた関連タレント本人であれば、関連タレントでなかった場合とは表示態様を変化させる。変形例（ホーム画面やコミュニティ画面などにおける特別アクションの表示態様について）参照）。

このような構成によれば、ユーザは、投稿コンテンツに関連付けられている第２属性に対応する特定ユーザがアクションを行った投稿コンテンツであることを容易に特定可能となる。そのため、第２属性に関する情報を求めるユーザにとって利便性が向上する。また、ユーザが行った投稿コンテンツに対してアクションを行った特定ユーザが、投稿コンテンツに関連付けられている特定ユーザであることを認識することができ、ユーザはさらなる特別感を得ることができる。

（１９） 上記（１）において、前記コンピュータを、
前記ユーザにより予め選択されて記憶されている第２属性が関連づけられたコンテンツ情報を当該ユーザが特定可能となるようにする際に（例えば、推しタレントが関連タレントとして関連付けられたコンテンツが投稿されたとき）、当該ユーザに当該第２属性が関連付けられたコンテンツ情報が特定可能となる旨を報知（例えば、推しタレントに関する情報が投稿された旨をプッシュ通知）するための手段（例えば、制御部１３０、制御部３５０）として機能させる。

このような構成によれば、ユーザは予め選択した第２属性に関するコンテンツ情報の特定がより容易となる。

（２０） 上記（１）において、前記コンピュータを、
外部サービス（例えば、外部ウェブサービス４００）により提供される外部投稿（例えば、動画配信サービスにおける配信動画）を特定するための情報（例えば、ＷｅｂＡＰＩにより取得できる情報）であって、前記複数種類の第１属性および前記複数種類の第２属性のうち当該外部投稿情報に関連付けられている属性（例えば、図５の所属グループ１に対応するチャンネルアカウントや、所属グループ１に所属する図５の各タレント）を特定するための属性特定情報（例えば、図２７（Ｃ）に例示する配信画面のチャンネルアカウントの属性特定情報９６ａや、概要欄９５に入力されているハンドルの属性特定情報９６ｂ）を含む外部投稿情報を取得するための手段（例えば、通信部１１０）と
前記外部投稿情報に応じて、外部投稿された外部投稿コンテンツに関するコンテンツ情報（例えば、図２７（Ｃ）の配信動画がアップされることに応じて、図２７（Ｃ）の配信動画に遷移可能な図２７（Ａ）や図２７（Ｂ）のコンテンツ見出し９０）を生成するための手段（たとえば、コンテンツ管理部１３２）であって、当該外部投稿情報に属性特定情報が含まれる場合に当該外部投稿コンテンツ（例えば、ＷｅｂＡＰＩによって取得された配信動画情報に、参加コミュニティおよび推しタレントに関連した属性特定情報９６が含まれている場合の配信動画）が当該属性特定情報から特定される属性が関連付けられた外部投稿コンテンツに関するコンテンツ情報として生成（例えば、属性特定情報９６によりコミュニティ（所属グループ１に対応）および、各タレントのタレントＩＤを関連付けたコンテンツ見出し９０を生成）するための手段（例えば、コンテンツ管理部１３２）として機能させ、
前記第１表示状態は、前記外部投稿コンテンツのうち、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられた外部投稿コンテンツに関するコンテンツ情報の表示を含む表示状態（例えば、ユーザが予め選択した参加コミュニティに対応する所属グループ１の配信スケジュール画面が表示される）であり、
前記第２表示状態は、前記外部投稿コンテンツのうち、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられた外部投稿コンテンツに関するコンテンツ情報の表示を含む表示状態（例えば、推しフィルター２０をオンにする操作により、ユーザが予め選択した参加コミュニティに対応するグループの配信スケジュール画面からさらに、推しタレントが関連付けられている（配信者あるいは共同出演予定者など）配信のコンテンツ見出し９０を表示（図２７など））である。

このような構成によれば、外部サービスにより提供される外部投稿についても、ユーザの好みの情報に最適化して、ユーザが特定することを容易にし得る。

（２１） 本発明のある局面にしたがう方法は、属性が関連付けられた複数種類のコンテンツ（例えば、ニュース記事、投稿記事、動画など）をユーザに提供可能とするためのコンピュータ（例えば、配信サーバ１００、ユーザ端末３００）を制御する方法であって、
前記属性は、複数種類の第１属性（例えば、図５のタレント情報データベースの所属グループ１に対応する図６（Ａ）のコミュニティＡ、コミュニティＢなど）と、複数種類の第２属性（例えば、図５のタレント情報データベースに記憶されるタレント、あるいは、所属グループ２のユニットなど）とを含み、
前記複数種類の第１属性および前記複数種類の第２属性のうちから、前記ユーザからの操作に応じて予め選択された属性（例えば、図６の属性選択画面において、図９のステップＳ１０３、ステップＳ１０７などで選択された参加コミュニティおよび推しタレントなど）を特定可能に記憶するためのステップ（例えば、図９のステップＳ１０４、ステップＳ１０８）と、
所定条件の成立（例えば、図１０のホーム画面や、図１１のコミュニティ画面、図２７の配信スケジュール画面に表示される推しフィルター２０に対するオンオフ操作）に応じて、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられたコンテンツに関するコンテンツ情報（例えば、図７のユーザ情報データベースに記憶されるユーザが予め選択した参加コミュニティ内に投稿されているコンテンツのコンテンツ見出し（６０，７０））を当該ユーザが特定可能となる第１表示状態（例えば、図１６のステップＳ２０３により、図１０のホーム画面や図１１のコミュニティ画面を図１５（Ｂ）のように推しフィルター２０オフの状態で表示）と、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツに関するコンテンツ情報（例えば、図７のユーザ情報データベースに記憶されるユーザが予め選択した参加コミュニティ内に投稿されているコンテンツであって、推しタレントのタレントＩＤが関連付けられた図１４の記事のコンテンツ見出し（６０，７０，９０））を当該ユーザが特定可能となる第２表示状態（例えば、推しフィルター２０をオンにする操作により、図１６のステップＳ２０４によって、図１５（Ａ）の推しフィルター２０がオン状態の画面）とを含む複数種類の表示状態のいずれかに切り替えて表示するためのステップ（例えば、図１６のステップＳ２０１～ステップＳ２０４）とを備え、
前記複数種類の第１属性は、各々、前記複数種類の第２属性の少なくともいずれかを含むグループであり、前記複数種類の第２属性は、各々、前記複数種類の第１属性に対応する複数種類のグループの少なくともいずれかに所属し得る属性である。

このような構成によれば、ユーザにより予め選択された第１属性が関連付けられたコンテンツに関するコンテンツ情報と、ユーザにより予め選択された第１属性および第２属性までが関連付けられたコンテンツに関するコンテンツ情報とを、表示切替手段によってユーザは特定可能となる。これにより、ユーザは好みの情報を容易に特定可能となる。

（２２） 本発明のある局面にしたがうシステム（例えば、通信システム１）は、属性が関連付けられた複数種類のコンテンツ（例えば、ニュース記事、投稿記事、動画など）をユーザに提供可能とするための処理を行うコンピュータ（例えば、配信サーバ１００、ユーザ端末３００）を有するシステムであって、
前記属性は、複数種類の第１属性（例えば、図５のタレント情報データベースの所属グループ１に対応する図６（Ａ）のコミュニティＡ、コミュニティＢなど）と、複数種類の第２属性（例えば、図５のタレント情報データベースに記憶されるタレント、あるいは、所属グループ２のユニットなど）とを含み、
前記複数種類の第１属性および前記複数種類の第２属性のうちから、前記ユーザからの操作に応じて予め選択された属性（例えば、図６の属性選択画面において、図９のステップＳ１０３、ステップＳ１０７などで選択された参加コミュニティおよび推しタレントなど）を特定可能に記憶するための記憶手段（例えば、アカウント管理部１３３は、図９のステップＳ１０４、ステップＳ１０８において、アカウント情報１２５として記憶する図７のユーザ情報データベースに、参加コミュニティおよび推しタレントＩＤをユーザＩＤに関連付けて記憶）と、
所定条件の成立（例えば、図１０のホーム画面や、図１１のコミュニティ画面、図２７の配信スケジュール画面に表示される推しフィルター２０に対するオンオフ操作）に応じて、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられたコンテンツに関するコンテンツ情報（例えば、図７のユーザ情報データベースに記憶されるユーザが予め選択した参加コミュニティ内に投稿されているコンテンツのコンテンツ見出し（６０，７０））を当該ユーザが特定可能となる第１表示状態（例えば、図１６のステップＳ２０３により、図１０のホーム画面や図１１のコミュニティ画面を図１５（Ｂ）のように推しフィルター２０オフの状態で表示可能）と、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツに関するコンテンツ情報（例えば、図７のユーザ情報データベースに記憶されるユーザが予め選択した参加コミュニティ内に投稿されているコンテンツであって、推しタレントのタレントＩＤが関連付けられた図１４の記事のコンテンツ見出し（６０，７０，９０））を当該ユーザが特定可能となる第２表示状態（例えば、推しフィルター２０をオンにする操作により、図１６のステップＳ２０４によって、図１５（Ａ）の推しフィルター２０がオン状態の画面）とを含む複数種類の表示状態のいずれかに切り替えて表示するための表示切替手段（例えば、コンテンツ管理部１３２、アカウント管理部１３３、入力情報送信部３５３、表示制御部３５２）とを備え、
前記複数種類の第１属性は、各々、前記複数種類の第２属性の少なくともいずれかを含むグループであり、前記複数種類の第２属性は、各々、前記複数種類の第１属性に対応する複数種類のグループの少なくともいずれかに所属し得る属性である。

このような構成によれば、ユーザにより予め選択された第１属性が関連付けられたコンテンツに関するコンテンツ情報と、ユーザにより予め選択された第１属性および第２属性までが関連付けられたコンテンツに関するコンテンツ情報とを、表示切替手段によってユーザは特定可能となる。これにより、ユーザは好みの情報を容易に特定可能となる。

通信システムのハードウェア構成例を示す図である。 配信サーバの構成を説明するための図である。 管理者端末の構成を説明するための図である。 ユーザ端末の構成を詳細に説明するための図である。 属性に関するデータベースの一例である。 属性の選択画面の一例である。 ユーザに関するデータベースの一例である。 ユーザに関する情報のユーザ確認画面の一例である。 属性選択処理のフローチャートを説明するための図である。 配信サーバにより提供されるコンテンツに関するコンテンツ情報の表示態様の一例である。 配信サーバにより提供されるコンテンツに関するコンテンツ情報の表示態様の一例である。 属性毎のコンテンツの分類に関する表示態様の一例である。 配信サーバにより提供されるコンテンツの表示態様の一例である。 配信サーバにより提供されるコンテンツに関するデータベースの一例である。 切替操作に応じた、コンテンツに関するコンテンツ情報の表示態様の一例である。 属性抽出処理のフローチャートを説明するための図である。 ユーザ投稿画面の表示態様の一例である。 ユーザ投稿処理のフローチャートを説明するための図である。 ユーザの評価履歴状況に応じて取り得るアクションの一例である。 評価履歴状況に応じたユーザ投稿画面の表示態様の一例である。 評価履歴状況に応じたユーザ投稿処理のフローチャートを説明するための図である。 外的評価による評価履歴状況の変動の一例である。 評価履歴状況更新処理のフローチャートを説明するための図である。 ユーザからタップアクションを受け付けた際のタップアクション演出の一例である。 コンテンツ毎のタップアクション演出に関するデータベースの一例である。 タップアクション演出処理のフローチャートを説明するための図である。 外部投稿コンテンツに関するコンテンツ情報等の表示態様の一例である。

以下、図面を参照しつつ本発明に係る通信システムについての実施の形態について説明する。なお、本発明は以下の例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。

本発明に係る通信システムにおいては、属性が関連付けられた複数種類のコンテンツをユーザに提供可能である。属性には複数種類の第１属性（例えば、コミュニティ）と、複数種類の第２属性（例えば、タレント）とが含まれ、属性が関連付けられたコンテンツ（例えば、タレントに関するニュース投稿）に関するコンテンツ情報（例えば、ニュース投稿の見出しなど）を表示可能とする。当該コンテンツ情報は、所定のアイコン等に対するユーザからの切替操作によって、ユーザが予め選択したコミュニティ等が関連付けられているコンテンツ情報をユーザが特定可能となるように表示する第１表示状態（推しフィルターオフ）と、ユーザが予め選択したコミュニティ等およびタレント等のいずれもが関連付けられたコンテンツ情報をユーザが特定可能となるように表示する第２表示状態（推しフィルターオン）とを含む複数種類の表示状態のいずれかに切り替えて表示可能である。

また、本発明にかかる通信システムにおいて提供される複数種類のコンテンツは、特定の対象（例えば、タレント等）を応援するユーザの集まりであるファンコミュニティを介して提供される。当該ファンコミュニティのコミュニティ空間内においては、ユーザ各々が取る行動を他のユーザが認識できるよう反映させることでユーザ同士の交流を図ることができる。当該コミュニティを利用するユーザには、ユーザ本人以外からの評価である外的評価に応じて変動する評価履歴状況が関連付けられている。コミュニティ内においてユーザが取ったアクション（例えば、ユーザが投稿したコンテンツやコメント等）に対して外的評価がなされることにより、ユーザがコミュニティ内で取り得る行動が制御される。

図１は、通信システム１のハードウェア構成例を示す図である。通信システム１は、配信サーバ１００と、管理者端末２００と、複数のユーザ端末３００ａ、３００ｂ、３００ｃ…と、外部ウェブサービスシステム４００とを含む。複数のユーザ端末３００ａ、３００ｂ、３００ｃ…は、複数のユーザ各々が所有する端末であって、以下ではまとめてユーザ端末３００ともいう。

配信サーバ１００、管理者端末２００、およびユーザ端末３００は、各々、ネットワーク２を介して通信接続可能であり、双方向に情報（データ）を送受信できる。ネットワーク２は、例えばインターネットであり、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、移動通信網（例えば、５Ｇ、無線ネットワークなど）、有線電話網、ＦＴＴＨ（Fiber To The Home）、ＣＡＴＶ（Cable Television）網等のアクセス網などで構成される。

また、配信サーバ１００、管理者端末２００、およびユーザ端末３００は、ネットワーク２を介して外部ウェブサービスシステム４００に通信接続可能である。外部ウェブサービスシステム４００とは、例えばユーザ投稿による動画、テキスト、画像等の共有サービス（例えば、Ｙｏｕｔｕｂｅ（登録商標）など）であって、配信サーバ１００、管理者端末２００、およびユーザ端末３００などの他の端末からのアクセスに応じた情報（例えば、テキスト、画像、動画、投稿日時、アカウント名など）を当該端末に供給可能とするためのＷｅｂ ＡＰＩ（Application Programming Interface）を提供しているものである。外部ウェブサービスシステム４００は、本通信システム１の管理者および運営者とは異なる他者（第３者）により運営・管理されるシステムである。

配信サーバ１００は、例えば、通信機能を有するワークステーションまたはパーソナルコンピュータなどのコンピュータである。配信サーバ１００は、ユーザに提供可能とするコンテンツを複数管理し、コンテンツが提供されるコミュニティを管理する。配信サーバ１００は、ネットワーク２を介してユーザからの要求に応じて当該コンテンツを提供する。

配信サーバ１００により提供されるコンテンツは、図１４を参照して後述するように、種類毎に管理・設定されている。コンテンツとは、閲覧者に所定の情報を知らせるものであって、動画・音声・テキストなどの情報の内容を含む。配信サーバ１００が管理するコンテンツは、例えば運営者（管理者）によるニュース・お知らせ記事や、ユーザ投稿、Ｗｅｂ ＡＰＩを利用することで取得した外部ウェブサービスにより提供される配信動画などである。当該コンテンツは、ユーザ端末３００において、ブラウザあるいは、スマートフォンの専用アプリケーションなどの媒体を介して表示させることでユーザに提供可能となる。また、当該コンテンツが提供される媒体は、所定の応援対象を応援するファンコミュニティとしても機能する。

配信サーバ１００は、ユーザに提供可能なコンテンツに応じたテキストや画像などをユーザ端末において表示するための情報や音を出力するための音情報を記憶部１２０に記憶している。また、配信サーバ１００は、ユーザ端末３００からのアクセスに応じて、対応するコンテンツのテキストや画像などを表示するための表示情報や音を出力するための音情報を含むコンテンツデータを配信することにより、ユーザにコンテンツ（サービス）を提供する。

管理者端末２００は、サービス提供会社の運営者などによって使用される。管理者端末２００は、例えば、パーソナルコンピュータ等の操作入力機能や通信機能を有するコンピュータである。運営者は、管理者端末２００を介して、配信サーバ１００の記憶部１２０において管理するコンテンツ（以下、投稿情報ともいう。）の作成、コンテンツの表示に関する表示情報の構築・改修・更新などを行う。例えば、新たなコンテンツ等をユーザ端末３００において表示させるための画像の生成・構築や、既に設けられているコンテンツ等の画像の変更・改修などが行われる。また、運営者は、管理者端末２００を介して、配信サーバ１００の記憶部１２０において管理する情報の設定・更新などを行う。また、管理者端末２００においては、ユーザの各種コンテンツに対するアクションを行うことについての許可や制限などの設定を行うこともできる。

なお、本実施の形態では、配信サーバ１００および管理者端末２００を、それぞれ独立したコンピュータ（装置）としているが、１台のコンピュータによって実現されていてもよいし、また、これらのコンピュータのうちの１つのコンピュータ（例えば、配信サーバ１００）の機能が、複数台のコンピュータ（例えば、複数台のサーバ）によって実現されているものであってもよい。

ユーザ端末３００は、コンテンツを視聴・体験等するユーザによって使用される。ユーザ端末３００は、例えば、パーソナルコンピュータ、タブレット端末、スマートフォン等の操作入力機能や通信機能を有するコンピュータであってもよい。

ユーザ端末３００は、当該端末への操作に応じて、配信サーバ１００と通信してユーザが選択したコンテンツのコンテンツデータを受信する。また、ユーザ端末３００は、受信したコンテンツデータに基づいて、配信サーバ１００において管理されているコンテンツのうちユーザが選択したコンテンツの投稿情報をユーザ端末３００の記憶領域内において構築し、当該投稿情報の画像やテキストを表示する。これにより、ユーザ端末３００を介して、ユーザは、コンテンツの情報を特定・認識することが可能となる。

また、ユーザ端末３００は、表示されるコンテンツに対するアクション操作や、ユーザ自身によるコンテンツ投稿操作を受け付ける。ユーザ端末３００は、当該端末への操作に応じた情報（例えば、アクションや投稿内容を特定するための情報）を配信サーバ１００に送信して、配信サーバ１００を介してアクションや投稿内容を複数のユーザ端末に反映させることができる。アクション操作とは、例えば、コンテンツに対する好感や共感などの好意的な意思表示を示すタップアクション（所謂いいねの機能など）や、コメント投稿等が含まれる。以降、ユーザ自身によるコンテンツ投稿操作など、ユーザによる行動を総称してアクションとも称する。また、ユーザによるタップアクションや、好意的なコメントを含め好感アクションとも称する。

本実施の形態におけるユーザには、一般消費者であるコンシューマ（一般ユーザ、あるいは単にユーザとも称する。）や、タレント、著名人などが含まれる。タレントには、例えば、サービス提供会社（運営会社）に属するタレント、芸能人、俳優・女優、お笑い芸人、マルチタレント、司会者、ニュースキャスター、歌手、ミュージシャン、モデルなど、様々なジャンルの有能人が含まれる。また、著名人には、例えば、有名な会社経営者あるいは社員、スポーツ選手、ｅスポーツ選手、有名な学者・文化人・塾講師、有名な学生など、様々なジャンルの有名人が含まれる。以降、一般ユーザ以外のタレント、あるいは著名人等を、特別ユーザとも称する。

なお、特別ユーザは、ユーザ端末３００と構成が同じ端末を使用して配信されるコンテンツを閲覧等する一般ユーザとなる場合もあり、ユーザ端末３００とは構成が異なる別個の端末を使用して一般のユーザとなる場合もある。そのため、特別ユーザの使用するユーザ端末と、一般ユーザが使用するユーザ端末３００とは、互いに構成が同じ端末である場合も異なる端末である場合もあり得る。

＜配信サーバの構成＞
次に、配信サーバ１００の構成を説明する。図２に示すように、配信サーバ１００は、他のコンピュータと通信を行う通信部１１０と、各種データを記憶する記憶部１２０と、コンピュータ全体の制御を行う制御部１３０とを備える。通信部１１０、記憶部１２０、および、制御部１３０は、バスラインによって相互に接続される。

通信部１１０は、有線通信又は無線通信を行うためのＮＩＣ（Network Interface Card controller）を備える通信インターフェースである。通信部１１０は、ネットワーク２を介して、他のコンピュータと通信を行う。

記憶部１２０は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＨＤＤ（Hard Disk Drive）等から構成される。記憶部１２０は、各種制御処理を実行するためのプログラム（例えば、コンテンツを管理・提供するためのプログラムなど）、各種データ等を記憶する。記憶部１２０に記憶される各種データには、コンテンツの種類毎に設けられている投稿情報や、属性に関する情報、ユーザに関するユーザ情報などが含まれる。

制御部１３０は、ＣＰＵ（Central Processing Unit）等から構成される。制御部１３０は、記憶部１２０に記憶されているプログラムを実行することにより、配信サーバ１００の全体の動作を制御する。

以下、制御部１３０の機能的な構成を説明する。制御部１３０は、少なくとも、データ送受信部１３１、コンテンツ管理部１３２、および、アカウント管理部１３３として機能する。

データ送受信部１３１は、ユーザ端末３００から送信される各種情報の受信や、ユーザ端末３００に対して各種情報の送信を行う。データ送受信部１３１は、記憶部１２０に格納されている各種管理テーブルを参照する。データ送受信部１３１が送受信を行う各種情報には、例えば、コンテンツ管理部１３２において管理されているコンテンツに関する情報や、各種通知などが含まれる。

コンテンツ管理部１３２は、通信部１１０を介して、管理者端末２００あるいはユーザ端末３００により投稿されたコンテンツに応じたテキストや画像等を特定するための情報を記憶部１２０において記憶・更新する。コンテンツ管理部１３２は、例えば、ユーザに提供するコンテンツに関連付けることができる属性に関する情報を記憶部１２０の属性情報１２１として記憶する。コンテンツ管理部１３２は、管理者端末２００あるいはユーザ端末３００により投稿されたコンテンツのカテゴリや投稿者、コンテンツ毎に関連付けられた属性などの情報を特定するための情報を記憶部１２０のコンテンツデータ１２２として記憶・更新する。また、コンテンツ管理部１３２は、コンテンツに対して行われたアクション（行動）に関して種別の特定などを行うための情報をアクション情報１２３として記憶更新させ、コンテンツに関するアクション（行動）を取り得る権限に関する情報などを記憶部１２０の行動権限情報１２４として記憶する。

アカウント管理部１３３は、記憶部１２０において、配信サーバ１００により管理されるコンテンツを利用し得るユーザに関するユーザ情報を例えば、アカウント情報１２５として記憶・更新する。ユーザに関するユーザ情報には、例えば、ユーザを識別するためのＩＤや、ユーザ名、ユーザが取り得る行動に関する許可アクション情報などを含む。アカウント管理部１３３によって管理されるユーザ情報には、一般ユーザのアカウントに限らず、特別ユーザのアカウントや、管理者端末２００による投稿等を識別するためのアカウント情報も含まれる。

＜管理者端末の構成＞
次に、管理者端末２００の構成を説明する。図３に示すように、管理者端末２００は、他のコンピュータと通信を行う通信部２１０と、各種データを記憶する記憶部２２０と、操作などを入力するための入力部２３０と、画像・音声などを出力するための出力部２４０と、コンピュータ全体の制御を行う制御部２５０とを備える。通信部２１０、記憶部２２０、入力部２３０、出力部２４０、および、制御部２５０は、バスラインによって相互に接続される。

通信部２１０は、有線通信又は無線通信を行うためのＮＩＣを備える通信インターフェースである。通信部２１０は、ネットワーク２を介して、主に配信サーバ１００と通信を行う。記憶部２２０は、ＲＡＭ、ＲＯＭ等から構成される。記憶部２２０は、各種制御処理を実行するためのプログラム（例えば、配信サーバ１００によりユーザに提供されるコンテンツを管理するためのプログラムなど）、各種データ等を記憶する。

入力部２３０は、管理者からの入力操作を受け付けるための入力装置（例えば、タッチパネル、タッチパッド、マウス等のポインティングデバイス、キーボード等）を含む。出力部２４０は、管理者に対して情報を提示するための出力装置（ディスプレイ、スピーカ等）を含む。

制御部２５０は、ＣＰＵ等から構成される。制御部２５０は、記憶部２２０に記憶されているプログラムを実行することにより、管理者端末２００の全体の動作を制御する。

以下、制御部２５０の機能的な構成を説明する。制御部２５０は、少なくとも、コンテンツ設定部２５１、属性設定部２５２、行動権限設定部２５３、および、ユーザ評価情報更新部２５４として機能する。

コンテンツ設定部２５１は、管理者端末２００への操作に応じて、配信サーバ１００のコンテンツ管理部１３２により管理されるコンテンツに関する情報を記憶・更新する。これにより、例えば、コンテンツを特定するための情報や、コンテンツに関するカテゴリ分け、コンテンツが提供される際の演出等に関する設定・編集等がされた情報を、配信サーバ１００の記憶部１２０において記憶・更新させるようにすることができる。

属性設定部２５２は、管理者端末２００への操作に応じて、配信サーバ１００の属性情報１２１として記憶される属性に関する属性情報を記憶・更新させるようにする。これにより、例えば、新たな属性の追加や、属性の編成に変更があった場合の属性に関する情報を記憶部１２０において記憶・更新させることができる。

行動制限設定部２５３は、管理者端末２００への操作に応じて、配信サーバ１００のアクション情報１２３および行動権限情報１２４として管理される、提供されるコミュニティ空間内におけるコンテンツの投稿アクションや、コンテンツに対する反応を示すアクションなどの行動を行う権限に関する情報を記憶・更新する。これにより、例えば、後述するユーザの評価履歴状況毎に設定される行動（アクション）の追加・変更や、運営者によるユーザ個々の行動制限の設定を記憶部１２０において記憶・更新させることができる。

ユーザ評価情報更新部２５４は、管理者端末２００への操作に応じて、配信サーバ１００のアカウント情報１２５として記憶されるユーザ毎の評価履歴状況に影響を与え得る外的評価をユーザに対して行うことや、ユーザ毎の評価履歴状況自体を記憶・更新することができる。これにより、ユーザ毎の評価履歴状況に運営者からの評価によって変動を与え、ユーザが行動権限情報１２４に基づいて取り得る行動（アクション）が制御されるようになる。

＜ユーザ端末の構成＞
次に、ユーザ端末３００の構成を詳細に説明する。図４に示すように、ユーザ端末３００は、配信サーバ１００を含む他のコンピュータと通信を行う通信部３１０と、各種データを記憶する記憶部３２０と、操作などを入力するための入力部３３０と、画像などを出力するための出力部３４０と、コンピュータ全体の制御を行う制御部３５０とを備える。通信部３１０、記憶部３２０、入力部３３０、出力部３４０、および、制御部３５０は、バスラインによって相互に接続される。

通信部３１０は、有線通信又は無線通信を行うためのＮＩＣを備える通信インターフェースである。通信部３１０は、ネットワーク２を介して、配信サーバ１００を含む他のコンピュータと通信を行う。記憶部３２０は、ＲＡＭ、ＲＯＭ等から構成される。記憶部３２０は、各種制御処理を実行するためのプログラム（例えば、コンテンツを閲覧等するためのプログラム）、各種データ等を記憶する。

入力部３３０は、ユーザからの入力操作・音声を受け付けるための入力装置（例えば、タッチパネル、タッチパッド、マウス等のポインティングデバイス、キーボード、マイクロフォン等）を含む。

出力部３４０は、ユーザに対し情報（テキスト、画像、音声等）を提示・出力するための出力装置（ディスプレイ、スピーカ等）を含む。制御部３５０は、ＣＰＵ等から構成される。制御部３５０は、記憶部３２０に記憶されているプログラムを実行することにより、ユーザ端末３００の全体の動作を制御する。

以下、制御部３５０の機能的な構成を説明する。制御部３５０は、情報取得部３５１、表示制御部３５２、入力情報送信部３５３、および、ユーザ管理部３５４として機能する。

情報取得部３５１は、通信部３１０を介して配信サーバ１００からのコンテンツデータなどを取得し、コンテンツデータに基づいてコンテンツに関するテキストや画像（投稿情報）を表示するための情報を記憶部３２０に記憶する。当該投稿情報には、コンテンツに対して他のユーザ端末３００において行われたアクションをユーザ端末３００において表示させるための情報が含まれる。

表示制御部３５２は、情報取得部３５１が取得したコンテンツデータに基づいて記憶部３２０に記憶されているコンテンツに関するコンテンツ情報（例えば、コンテンツの記事の見出しなど）をユーザが特定可能となるように表示させる。例えば、タレントに関するニュース記事の見出しをユーザ端末３００に表示することで、ユーザはタレントに関するニュースのコンテンツであること認識し得る。

また、表示制御部３５２は、記憶部３２０に記憶されているプログラムに基づいて配信されているコンテンツに応じた態様のＵＩ（User Interface）画像（例えば、ユーザが選択可能なメニュー画像や操作を受け付ける操作画像を含む）を表示する。

入力情報送信部３５３は、入力部３３０において取得した音声情報や、操作入力情報などを配信サーバ１００に送信する。操作入力情報には、表示されるコミュニティ空間内の各種コンテンツに対するアクション（例えば、コメントやタップアクションなど）や、ユーザ自身によるコミュニティ空間内へのコンテンツの投稿情報、および、ユーザ端末３００において表示される各種アイコン等に対する選択操作などが含まれる。

ユーザ管理部３５４は、ユーザに関するユーザ情報を記憶部３２０において記憶・更新する。ユーザに関するユーザ情報には、例えば、ユーザを識別するためのＩＤや、ユーザ名、ユーザが予め選択した属性に関する情報、ユーザがコミュニティ内において取り得る（許可あるいは制限がされている）アクションに関する情報などを含む。

＜ファンコミュニティのコンテンツ提供機能について＞
（ファンコミュニティについての概要）
以下、本実施例にかかる配信サーバ１００により提供されるコンテンツを閲覧可能とさせるファンコミュニティについてより具体的に説明する。配信サーバ１００により提供されるコンテンツは、スマートフォンやタブレット等の端末で動作する専用アプリケーション（プログラム（例えば、ネイティブアプリケーション用プログラムなど））により提供される。当該専用アプリケーションは、共通の対象（例えば、タレント、キャラクタ、グッズなど）を応援するユーザが利用する所謂ファンコミュニティとして機能する。当該ファンコミュニティでは、共通の対象に関連するコンテンツの提供がされる（ユーザに閲覧可能とする）ことでユーザのファン活動を円滑にすることに加え、ファンであるユーザ同士の交流に限らず、ユーザの応援対象とユーザとが交流を図ることもできる。なお、コンテンツの提供は、専用アプリケーションに限らず、ＷＥＢアプリケーションによりブラウザを介して提供されてもよい。また、ＷＥＢアプリケーションによりブラウザを介して提供されるファンコミュニティを介してコンテンツが提供されてもよい。

本実施例における応援対象とは、例えば、ユーザが好意・興味・関心などを抱くことができるものであればキャラクタやモノなど種々の対象が適用できる。キャラクタとは、例えば、タレントや著名人といった実在する人物等（３次元）や、アニメキャラクタやマスコットキャラクタなどの架空の存在（２次元、２．５次元）が含まれる。そのほか、応援対象には、鉄道などのモノや、動物などが含まれる。

（ファンコミュニティにおける属性についての具体例）
以下、本実施例においては、ユーザの応援対象が、タレントであり、当該ファンコミュニティは、当該タレントのファンコミュニティである例について説明する。本実施例においてタレントは、複数人のタレントからなる大グループ（第１属性ともいう）に区分けされる。さらに、大グループに区分けされたタレントは、大グループよりも少ない人数で構成される小グループ（第２属性ともいう）に分けることもできる。例えば、小グループとは、大グループに所属するタレントの一部からなるユニット・グループなどである。

ファンコミュニティを利用するユーザが応援対象とする単位（属性）としては、１人のタレントだけでなく、タレント複数人、小グループ（ユニット）単位、大グループ単位で応援する場合があり得る。例えば、大グループ単位で応援する（ファンになる）ことを、所謂箱推しともいう。本実施例におけるファンコミュニティにおいては、ユーザは自身が応援する対象を予め好みの単位毎（属性毎）に設定（選択）しておくことができる。

図５を参照して、本実施例において属性情報１２１として記憶されるタレント情報データベースの例を用いて、本実施例におけるファンコミュニティのタレントについて説明する。本実施例においてタレントは、「所属グループ１」に分類されるグループに区分けされている。所属グループ１は、大グループであり、例えば、グループＡ、グループＢ・・・などに分類されている。

各所属グループ１には、所属するタレントを特定するための情報として「タレントＩＤ」と、「タレント名」などが関連付けられている。さらに各タレントには、各タレントが属する「所属グループ２」を特定する情報が関連付けられている。所属グループ２とは、所属グループ１よりも少ない人数で構成される小グループである。例えば、グループへ入った時期の単位で分類された「１期生」、「２期生」・・・や、所定のコンセプトで構成されたグループ（例えば、ゲームに関する実況中継を中心に行うタレントで構成された「ゲーマーズ」など）である。

なお、所属グループについては、タレントによっては、複数の所属グループに属していてもよい。また、所属グループ１には所属しているが、いずれの所属グループ２にも所属していないタレントが含まれていてもよい。その他、異なる所属グループ１に属するタレントによって構成される（異なる所属グループ１を跨って構成される。例えば、グループＡとグループＢなど）所属グループ２があってもよい。

例えば、タレントＩＤ「ｔ１」であってタレント名「ＡＡＡ」であるタレントは、所属グループ１は「グループＡ」に所属しており、所属グループ２は「Ａ－１期生」に所属している。一方、タレントＩＤ「ｔ６」であってタレント名「ＦＦＦ」であるタレントは、所属グループ１は「グループＡ」に所属しているが、所属グループ２は、「Ａ－３期生」と「Ａ－ゲーマーズ」の２グループに所属している。

＜属性選択処理のついての具体例＞
（属性選択についての画面例）
次に、図６～図９を参照して、ファンコミュニティを利用するユーザが、応援する属性（グループやタレント）を選択する画面の例および処理の流れについて説明する。図６に例示する応援する属性の選択（設定）画面は、ファンコミュニティアプリの利用開始時、あるいはマイページなどから設定変更を要求することにより、ユーザ端末３００において表示される。本実施例におけるファンコミュニティにおいては、図５を参照して説明したタレントの所属グループ１（第１属性）に対応するコミュニティ（第１属性）に参加することができる。図６（Ａ）は、参加コミュニティ設定画面の一例であって、ユーザは複数種類の第１属性の中から参加するコミュニティ（第１属性）を選択（設定）することができる。例えば、図６（Ａ）の参加コミュニティ設定画面には、参加コミュニティ選択エリア５０が含まれる。参加コミュニティ選択エリア５０には、ユーザが参加できるコミュニティ毎のアイコンが表示されている。ユーザは参加を希望するコミュニティのアイコンを選択操作することで、参加コミュニティを選択することができる。また、参加の選択ができたコミュニティには、チェックマークなどが表示される。

「コミュニティＡ」は、図５の「グループＡ」に対応し、「コミュニティＢ」は、図５の「グループＢ」に対応する。つまり、複数種類の第１属性には、グループＡ、あるいは、グループＡに対応するコミュニティＡや、グループＢ、あるいは、グループＢに対応するコミュニティＢが含まれる。なお、図６（Ａ）で「※コミュニティＰには常に参加しています。」と表示されるように、ユーザの選択にかかわらず常に参加することになっているコミュニティがあってもよい。例えば、「コミュニティＰ」は、タレントの所属グループには対応せず、ファンコミュニティ全体としてのお知らせ等をするコミュニティなどである。

図６（Ｂ）は、推しタレント設定画面の一例であって、ユーザは好みのタレント（第２属性）を選択（設定）することができる。図６（Ｂ）の推しタレント設定画面には、一例として、検索窓５１、所属グループ選択エリア５２、タレント選択エリア５３などが含まれる。検索窓５１は、キーワードが入力されることによりタレントを検索することを可能とする。所属グループ選択エリア５２には、ファンコミュニティアプリにおいて応援することができるグループ（所属グループ１、コミュニティに対応）のアイコンが表示されており、アイコンを選択することにより、例えばタレントを所属グループ１毎に、表示させることができる。なお、所属グループ選択エリア５２において、全グループの選択ができてもよい。また、ユニットごとに選択して表示させることができるアイコンが表示されていてもよい。

タレント選択エリア５３には、タレント１人１人のアイコンと名前が表示されているが、図６（Ｂ）に例示するように、例えばユニットごとの順番で表示されるものであってもよい。各タレントのアイコン等を選択操作することにより、推しタレントを選択することができる。また、選択されたタレントのアイコンには、チェックマークなどが表示される。

なお、グループ選択エリア５２のアイコン操作により、グループのタレントすべてを推しタレントとして選択できるものとしてもよい。あるいは、「すべて選択」のアイコンを表示させ、選択操作により表示されるすべてのタレントが選択可能であってもよい。また、タレント毎に限らず、ユニット単位（所属グループ２単位）で推しタレントの選択ができてもよく、最推し（推しタレントの中でも最も推しているタレント）の選択ができてもよい。

（選択した属性に関するユーザ情報データベース例）
図７は、アカウント情報１２５として記憶されるユーザ情報データベースの一例である。ユーザ情報データベースには、ユーザ毎に、ユーザを特定するための「ユーザＩＤ」、「レベル」、「累積ポイント」、「参加コミュニティ」、「推しタレントＩＤ」などが関連付けられている。「参加コミュニティ」および「推しタレントＩＤ」には、図６で例示した設定画面において、ユーザが選択した属性を特定するための情報が関連付けられている。例えば、図６の設定画面が、図７におけるユーザＩＤ「ｕ１」の設定画面であり、ユーザＩＤ「ｕ１」は、図６（Ａ）で参加コミュニティは「コミュニティＡ」を選択しており、図６（Ｂ）でタレント「ＡＡＡ」と、「ＢＢＢ」と、「ＥＥＥ」を選択しているため、ユーザＩＤ「ｕ１」には、所属コミュニティは「コミュニティＡ」、推しタレントＩＤは、各々のタレントに対応する「ｔ１」、「ｔ２」、「ｔ５」が関連付けられている。以降、ユーザＩＤを単にユーザとも称する。なお、「レベル」、「累積ポイント」とは、ファンコミュニティ内におけるユーザの行動によって変動するものであるが、詳細は後述する。

（ユーザ毎のマイページ例）
図８は、ファンコミュニティにおけるユーザ毎のマイページ画面の一例である。例えば、マイページアイコン１６に対するユーザからの選択操作があったことにより、ユーザ端末３００は、アカウント情報１２５として記憶される当該ユーザの情報を取得し、ユーザ端末３００に表示する。マイページ画面には、一例として、ネームエリア５４、ユーザ評価履歴状況５５、推しタレント情報５６、参加コミュニティ設定５７、お知らせ設定５８、設定・アプリ情報５９などが表示され、各種設定変更等の編集操作を行うことができる。

図８のマイページ画面は、ユーザ「ｕ１」のユーザ端末３００において表示される画面であり、ネームエリア５４には、ユーザ「ｕ１」のファンコミュニティ内で使用する名前「ｕｓｅｒＡ」と、アイコン画像が表示されている。アイコン画像は、例えば、タレントのファンマークにすることができる。ファンマークとは、タレントが自身を示すものとして使用する記号などのことであり、ファンが同じファンマークを使用することで、いずれのタレントのファンであるかを公に示すことができるものである。例えば、アイコン画像の右下に表示される画像編集アイコンへのタップ操作などによる編集や、初期設定画面において選択して設定することができる。

ユーザ評価履歴状況５５には、図７のユーザ情報データベースにおいてユーザ毎に関連付けられている「レベル」、「累積ポイント」を、ユーザ本人が確認できるように表示されている。評価履歴状況についての詳細は後述する。

推しタレント情報５６には、ユーザが予め選択したタレントをユーザ本人が特定（確認・認識）できるように表示されている。例えば、ユーザ「ｕ１」が図６（Ｂ）の推しタレント設定画面において選択して設定したタレント「ＡＡＡ」、「ＢＢＢ」、「ＥＥＥ」を確認できるように、各タレントのアイコンおよび名前が表示されている。また、推しタレントは、推しタレント情報５６に表示される編集アイコンへの操作などにより、図６（Ｂ）の画面が表示され、適宜変更することができる。

また、参加コミュニティ設定５７への選択操作があったときには、図６（Ａ）の参加コミュニティ設定画面が表示され、参加コミュニティを適宜変更することができる。

お知らせ設定５８や、設定・アプリ情報５９への操作がされると、プッシュ通知の設定等や、ファンコミュニティアプリの各種設定操作を行うことができる。なお、図８のマイページは、ユーザ自身の情報を確認し編集等できるものであればよい。例えば、参加コミュニティについても、推しタレント情報５６と同様にマイページの始めの画面（マイページアイコン１６を操作したときに表示される画面など）において、参加しているコミュニティ一覧が表示されていてもよい。また、参加コミュニティと、推しタレントとの変更画面（図６）がまとめて１つの編集アイコンへの操作により表示されるものであってもよい。

（属性選択処理の流れの例）
次に、図９を参照して、属性選択処理の流れについて説明する。図９は、図６を参照して説明した属性選択処理のフローチャートを説明するための図である。属性選択処理は、配信サーバ１００において、ユーザ端末３００からの要求（操作情報など）を受信することに応じてアカウント管理部１３３において繰り返し実行される。

ステップＳ１０１では、初回ログインであるか否かが判定される。初回ログインとは、例えば、ユーザが、本実施例におけるファンコミュニティアプリを初めてダウンロードして起動させたときや、ＷＥＢブラウザを介して本実施例におけるファンコミュニティアプリを初めて利用したときなどであって、ファンコミュニティにおける属性設定を初めて行うタイミングである。ステップＳ１０１で初回ログインであると判定されたときには、ステップＳ１０２で、ユーザ端末３００の表示部に属性選択画面を表示するための情報を送信する。属性選択画面とは、例えば、図６で例示した、参加コミュニティおよび推しタレントを選択する設定画面であり、初回ログイン時のチュートリアルなどの流れ（初回ログイン時の基本説明など）に組み込まれていてもよい。

次にステップＳ１０３では、ユーザ端末３００において、参加コミュニティ、および、推しタレントの選択・確定の操作がされたか否かの判定がされる。例えば、図６（Ａ）の参加コミュニティ選択エリア５０に表示される参加コミュニティのうち、ユーザは参加したいコミュニティを選択操作する。また、図６（Ｂ）で、タレント選択エリア５３に表示されるタレントのうち、好みのタレントを選択する。なお、図６の属性選択画面において、決定アイコンなどの、確定操作を行うためのアイコンが表示されていてもよい。当該決定アイコン、あるいは、「次へ」などのアイコンが操作されることによって送信される情報（選択された参加コミュニティおよび推しタレントを特定可能な情報を含む）を受信することなどにより、確定操作があったと判定されてもよい。ステップＳ１０３で参加コミュニティ、および、推しタレントの選択・確定がされたと判定されなかったときには、選択・確定操作がされるまで、ステップＳ１０３で繰り返し判定される。

一方、ユーザ端末３００において決定アイコンなどへの選択操作があったことにより、属性の選択・確定がされたと判定したときには、ステップＳ１０４に進み、ユーザ端末３００から受信した情報に基づいて選択された参加コミュニティ、および、選択された推しタレントを、選択された属性として記憶する。例えば、アカウント管理部１３３は、ユーザ「ｕ１」に、選択された参加コミュニティ、および、選択された推しタレントＩＤを関連付けるようにして、アカウント情報１２５として記憶して処理を終了する。

ステップＳ１０１に戻り、ステップＳ１０１において初回ログインであると判定されなかったときには、ステップＳ１０５で、参加コミュニティ設定、または、推しタレント設定の編集要求があったか否かの判定がされる。例えば、ユーザ端末３００において、図８で例示するマイページの推しタレント情報５６の編集アイコンに対する操作や、参加コミュニティ設定５７に対する操作などがあったときに、編集要求があったと判定される。

ステップＳ１０５において、編集要求があったと判定されたときには、ステップＳ１０６で、参加コミュニティ設定、または、推しタレントの設定編集画面をユーザ端末３００において表示するための情報を送信する。これにより、例えば、図６で例示した属性選択（設定）画面が表示される。一方、ステップＳ１０５において、参加コミュニティ設定、または、推しタレント設定の編集要求があったと判定されなかったときには、処理を終了する。

ステップＳ１０６で、設定編集画面を表示させたあとは、ステップＳ１０７で、参加コミュニティ、または、推しタレントの選択がされたか否かの判定がされる。例えば、ユーザ端末３００において、図６（Ａ）の各参加コミュニティの表示、または、図６（Ｂ）の各タレントの表示に対する選択操作がされることによって送信される情報（選択された参加コミュニティおよび推しタレントを特定可能な情報を含む）を受信することにより、選択がされたと判定される。

ステップＳ１０７で、参加コミュニティ、または、推しタレントの選択がされたと判定されたときには、ステップＳ１０９で、選択された参加コミュニティ、または、選択された推しタレントを選択された属性として更新・記憶して処理を終了する。例えば、配信サーバ１００において、ユーザ端末３００から受信した属性の選択操作に応じた情報に基づいて、アカウント情報１２５として記憶される図７のユーザ情報データベースを更新して記憶する。

ステップＳ１０７に戻り、参加コミュニティ、または、推しタレントの選択がされたと判定されなかったときには、ステップＳ１０９で戻る選択がされたか否かの判定がされる。例えば、図６の属性選択画面に、戻るアイコン１０を表示させ、当該戻るアイコン１０に対する選択操作があったか否かの判定がされる。戻るアイコン１０への選択操作があったと判定されたときには処理を終了する。あるいは、アプリの下部に表示されるホームアイコン１３等への操作により、別画面に移動することで処理を終了してもよい。一方、ステップＳ１０７で、戻る選択がされたと判定されなかったときには、ステップＳ１０７に戻る。

これにより、後述するように、ファンコミュニティにおいてユーザが予め選択した属性に関する情報を抽出して表示することが可能となるため、ユーザは、好みの所属グループ１（第１属性）に関する情報と、さらには、各タレント（第２属性）に関する情報を抽出して取得することが可能となる。なお、属性選択処理が配信サーバ１００で実行される例について説明したが、ユーザ端末３００で実行されるものであってもよい。

＜コンテンツの提供態様例＞
（コンテンツの一覧画面についての概要）
次に、配信サーバ１００によりファンコミュニティを介して提供されるコンテンツの提供態様例について、図１０～図１４を参照して説明する。図１０は、本実施例のファンコミュニティアプリ（以降、単にアプリとも称する。）におけるホーム画面の一例である。ホーム画面は、例えば、ユーザ端末３００において、当アプリへのログイン時（例えば、アプリ起動時など）や、アプリの下部に表示されるホームアイコン１３への選択操作がされることにより表示される。図１０のホーム画面で表示されるコンテンツを特定するための情報（コンテンツ記事の見出し）は、ユーザが参加しているコミュニティにおいて投稿されたコンテンツを特定するための情報が、主に表示されている。

なお、アプリ上部に表示されるチャンネルアイコン１２は、図１２に例示するように参加コミュニティ毎のチャンネル一覧を表示することが可能であって、アプリのいずれの画面に表示されていてもよく、所定の画面（例えば図１３のようにコンテンツの中身が表示されている場合など）では非表示としてもよい。チャンネルとは、例えば、話題（テーマ）の種類別に分類されたものである。アプリの上部に表示される検索アイコン１７は、コンテンツを検索するためのアイコンである。検索アイコン１７は、例えば、図１０のホーム画面や、後述する図１１（Ａ）のコミュニティ毎の画面などの、コンテンツの見出しが一覧表示されている場合などに表示されるものであってもよい。

また、アプリの下部に表示されるホームアイコン１３、コミュニティアイコン１４、通知アイコン１５、マイページアイコン１６は、アプリ内のいずれの画面においても表示されるようにしてもよく、所定の画面（例えば図１３のようにコンテンツの中身が表示されている場合など）では非表示としてもよい。ホームアイコン１３は、前述したように、選択操作がされることにより図１０のホーム画面を表示させるためのアイコンであり、コミュニティアイコン１４は、選択操作がされることにより後述する図１１（Ａ）などのコミュニティ毎の画面を表示させるためのアイコンである。通知アイコン１５は、選択操作がされることにより選択した属性（例えば、ユーザが推しタレントに設定したタレント）に関する投稿があった場合や、ユーザ自身の投稿への返信コメント、ユーザに対するメンションなど、各種お知らせを確認することができる画面を表示させるためのアイコンである。マーページアイコン１６は、選択操作がされることにより図８で例示したマイページを表示させるためのアイコンである。

（ホーム画面の概要）
図１０のホーム画面上部には、推しフィルター２０や、言語切り替えアイコン２１などが表示されている。推しフィルター２０は、表示されるコンテンツの見出し一覧が、ユーザが予め選択した推しタレントが関連付けられたコンテンツの見出しのみが表示されるように絞り込むことができるフィルターアイコンであるが、詳細については図１５、図１６などを参照して後述する。言語切り替えアイコン２１は、例えば日本語から英語への切り替えなど、選択操作がされることにより表示される言語を切り替えることを可能とするアイコンである。

配信サーバ１００により提供されるコンテンツは、複数種類のカテゴリのいずれかに分類可能であり、ホーム画面においては分類されたカテゴリ毎にコンテンツを表示させることができる。ホーム画面のコンテンツ一覧（見出し）画面には、例えば、フィーチャー６１、推しトピック６２、人気のユーザ投稿６３、記念配信６４、グッズ６５などのカテゴリ毎にコンテンツ（記事・スレッドともいう）のコンテンツ見出し６０（コンテンツ情報）が表示されている。例えば、フィーチャー６１は、運営者からのお知らせなどコンテンツ設定部２５１により設定されたユーザ全体に知らせたいお知らせ記事などが表示されている。フィーチャー６１に表示されるコンテンツは、いずれの参加コミュニティおよび、いずれの推しタレントをユーザが選択しているか否かにかかわらず表示される。また、フィーチャー６１に表示される見出しや画像などを選択操作すると、詳細情報を示す画面や、外部のウェブサイトなどに遷移するようにしてもよい。

推しトピック６２以降のカテゴリについては、参加しているコミュニティ内で投稿されたコンテンツが表示されるようになっている。本実施例におけるアプリでいう「コミュニティ」とは、図６で例示した、タレントが所属する所属グループ毎に対応したコミュニティＡ～Ｃや、ユーザが常に参加状態となっているコミュニティＰなどである。

（コミュニティのチャンネル一覧画面について）
図１１～図１４を参照して、本実施例におけるアプリの「コミュニティ」の詳細について説明する。図１１（Ａ）は、「コミュニティ」のコンテンツ一覧（見出し）画面の一例である（以降、コミュニティ画面、チャンネル画面ともいう）。各コミュニティは、図１２に示すように話題の種類ごとのチャンネルに分類される。例えば、図１１（Ａ）のコミュニティ画面は、「コミュニティＡ」（図５で例示したグループＡと対応）のチャンネル「公式チャンネル」の画面であり、図１２のチャンネル一覧画面におけるチャンネルの選択操作によって、図１１（Ａ）で表示されるチャンネル画面が切り替わる。

図１２で例示するチャンネル一覧画面は、例えばアプリ画面（例えば図１０）の上部に表示されるチャンネルアイコン１２へのタップ操作、あるいは、フリック操作（例えば、アプリ画面左側から右側へのフリック操作）により表示される。なお、図１２のチャンネル一覧画面が表示されている際に、表示させたときの動作（チャンネルアイコン１２への選択操作あるいは、アプリ画面右側から左側へ戻すフリック操作など）をすることで当該一覧画面を閉じることができる。

図１２のチャンネル一覧画面には、コミュニティバー８１、お気に入り確認アイコン３１、自分の投稿アイコン３２、はじめにアイコン３３、通知設定アイコン３４などが表示されている。コミュニティバー８１に表示されるコミュニティは、ユーザが参加（ユーザが選択）しているコミュニティを含む。当該コミュニティバー８１に表示される開閉アイコンを選択操作することにより、コミュニティ毎のチャンネル一覧８２が表示される。例えば、コミュニティＡに対応するチャンネル一覧８２には、各チャンネル名が表示される。各チャンネル名の横に表示される選択バー８３は、選択されているチャンネルがいずれかを示すものである。

例えば、図１２は、図７で例示するユーザ「ｕ２」のユーザ端末３００において表示される画面である。ユーザ「ｕ２」が参加しているコミュニティは、「コミュニティＡ」と「コミュニティＢ」であるため、図１２のチャンネル画面一覧には、「コミュニティＡ」のチャンネルバー８１ａと、「コミュニティＢ」のチャンネルバー８１ｂと、常に参加になっている「コミュニティＰ」のチャンネルバー８１ｃとが表示されている。選択バー８３は、「コミュニティＡ」の「公式チャンネル」の横に表示されているため、図１１（Ａ）にて表示するコミュニティの画面が、「コミュニティＡ」の「公式チャンネル」であることを示している。例えば、チャンネル一覧８０２に表示されるチャンネル名に対する選択操作により、選択バー８０２ｂは移動する。これにより、アプリ画面には、図１１（Ａ）の「コミュニティＡ」の「公式チャンネル」が表示されるようになる。

図１２のチャンネル一覧画面における選択操作があったときに、図１１（Ａ）のコミュニティ画面へ切り替わってもよい。また、図１２に示すようにチャンネル一覧画面を、別の画面の上に重畳されるように表示させ、チャンネル一覧画面の下に表示されている画面が、選択されたチャンネルの画面に切り替わり、図１２のチャンネル一覧画面を閉じる操作を行うことで、図１１（Ａ）のコミュニティ画面が全体に表示されるようにしてもよい。また、図１２のチャンネル一覧画面でチャンネルの選択がされることにより、アプリ画面下部に表示されるコミュニティアイコン１４への選択操作がされたときにも、選択されたチャンネルが、図１１（Ａ）のコミュニティ画面として表示されるようになる。

図１２のお気に入り確認アイコン３１は、選択操作がされることにより、アカウント情報１２５として記憶されているあるいは、記憶部３２０に記憶されるユーザがお気に入りに登録したコンテンツ（投稿ともいう）を確認することを可能とするアイコンである。自分の投稿アイコン３２は、選択操作がされることにより、ユーザ自身がコミュニティ内で投稿したコンテンツ（立てたスレッド）や、ユーザ自身がコンテンツ（立てられているスレッド）に対して行ったコメントなどを確認することを可能とするアイコンである。はじめにアイコン３３は、選択操作がされることにより、初回ログイン時に表示されるチュートリアルの再確認や、アプリの使い方、心構えなどを表示することを可能とするアイコンである。通知設定アイコン３４は、選択操作がされることにより。各種お知らせの設定（プッシュ通知がされる情報の選択など）をする画面を表示可能とするアイコンである。例えば、図８のマイページで例示したお知らせ設定アイコン５８を選択操作したときと同じ画面が表示されるようにしてもよい。

（コミュニティ画面について）
図１１（Ａ）のコミュニティ画面には、図１０で例示したホーム画面と同様に、推しフィルター２０、言語切り替えアイコン２１や、並べ替えアイコン２２、投稿アイコン２３などが表示される。並べ替えアイコン２２は、選択操作がされることにより、表示されるコンテンツの見出しの順番を、新着順や、人気順（例えば、好感アクションが多い順など）などに並べ替えることを可能とするアイコンである。投稿アイコン２３は選択操作がされることにより、ユーザがコミュニティ内にコンテンツの投稿（スレッドを立てる）を行うことを可能とするアイコンである。

コミュニティ内に投稿された各コンテンツは、図１１（Ａ）のコミュニティ画面において一部が、コンテンツ見出し７０（コンテンツ情報）により表示されている。例えば、コンテンツ見出し７０ａ、７０ｂ、７０ｃ・・・などが表示されており。各コンテンツ見出し７０には、投稿者７１、通報アイコン７２、お気に入りアイコン７３、内容情報７４などが表示されている。

投稿者７１には、対応するコンテンツの投稿者のアイコン、名前などを表示する。例えば、投稿者が、運営者や、後述する特別ユーザなどであった場合には、公式マークなどとともに表示する。

通報アイコン７２は、選択操作がされることにより、図１１（Ｂ）に示すような画面が表示（例えば、現画面にポップアップ表示）される。図１１（Ｂ）に表示される文字を選択することにより、ユーザは、例えば不快感を覚えるコンテンツを運営者に通報する操作や、ユーザ端末３００において非表示にする操作、コンテンツの投稿者自体を、ファンコミュニティアプリ内でブロックする操作（当該ブロックをした対象となるユーザの投稿等アクションを、操作した以降において自身のユーザ端末３００において表示させないようにする）などを可能とする。なお、非表示、ブロック等の操作は、運営者や特別ユーザ（が投稿したコンテンツ）に対しては行うことができず、その他一般ユーザにのみ行える操作であってもよい。

お気に入りアイコン７３は、選択操作がされることにより、ユーザが気に入った投稿をあとで確認することができるように保存しておくことを可能とするアイコンである。例えば、お気に入りアイコン７３が選択されることで、例えば、アカウント情報１２５として記憶される図７のユーザ情報データベースを、お気に入りアイコン７３が操作された投稿の記事ＩＤを、ユーザに関連付けて更新し記憶する。これにより、ユーザは、お気に入り投稿を、図１２のお気に入り確認アイコン３１を選択操作したときに確認できるようになる。

内容情報７４は、コンテンツの投稿内容のタイトルや説明文の一部を表示する。

さらにコンテンツ見出し７０には、投稿されているコンテンツが画像とともに投稿されていれば、画像７５が表示され、コンテンツに対してコメントがあった場合には、コメント（例えば、最新コメントや、最も人気のコメントの一部など）がピックアップコメント７６に表示される。また、コンテンツに対してのコメントがあった数がコメント数７７に表示され、コンテンツに対してのタップアクションがあった数がタップアクション数７８に表示される。コンテンツに対してのタップアクション数は、例えば、コンテンツ見出し（６０，７０）にタップアクション数７８とともに表示されるハートのアイコン７０８や、後述する図１３のコンテンツ画面に表示されるタップアクション数７８とともに表示されるアイコン７０８への全ユーザからのタップアクションがされた合計回数が表示される。

また、ファンコミュニティアプリを利用するユーザには、特別ユーザが含まれ、特別ユーザからのコメントやタップアクションがあった場合に、特別ユーザからのコメントやタップアクションがあったことを、コンテンツ見出し７０内において特別ユーザのアイコンとともに特別アクション７９として表示させることができる。特別ユーザとは、例えば、図５で例示したタレント本人と対応するユーザである。そのため、特別アクション７９が表示されていることで、タレント本人からのコメントやタップアクションなどのアクションがあったことをユーザは認識することができる。これにより、ファンコミュニティアプリにおいて、応援している対象との交流を促進させることができ、ユーザの満足度を高めることができる。

特別アクション７９には、タレント各々に対応するアイコンとともに、タレントによりコメントがあった場合には吹き出しマークなどのコメントがあったことを推測できるアイコンと、タレントによりタップアクションがあった場合には、ハートマークなどのタップアクションがあったことを推測できるアイコンとが表示される。例えば、図１１のコミュニティ画面におけるコンテンツ見出し７０ａには、タレント３人からアクションがあったことを示す特別アクション７９が表示されている。左側と中央に表示されているタレントのアイコンには、吹き出しマークとハートマークが表示されているため、コメントとタップアクションがあったことが示されている。一方、右側に表示されるタレントは、アイコンとともにハートマークのみ表示されているため、コメントはせずにタップアクションのみ行ったことが示されている。

また、コンテンツ見出し７０に表示させる特別アクション７９は、図１０のホーム画面のコンテンツ見出し６０内に表示されるようにしてもよい。

図１３は、図１１（Ａ）で表示されるコンテンツのうち、コンテンツ見出し７０ａが選択操作されたときに表示されるコンテンツ画面例であり、コンテンツ見出し７０ａの中身であるコンテンツ自体（投稿自体）の表示画面例である。なお、図１０のホーム画面においても、同様のコンテンツが表示されていた場合、ホーム画面において対応するコンテンツ見出し６０に対する選択操作により図１３のコンテンツ画面が表示される。

図１３のコンテンツ画面においては、上部に戻るアイコン１０ｂが表示され、投稿者７１、通報アイコン７２、お気に入りアイコン７３、タップアクション数７８や、カテゴリ８５、内容７４ｂ、関連タレント８８、および、特別アクション７９などが表示されている。また、コンテンツに対してコメントがあった場合には、下部にコメントが一覧表示されている。コメントの一覧表示には、コメント数を表示するコメント数７７ｂ、各コメントであるコメント８７、ユーザがコメント投稿をするためのコメント投稿欄８４などが表示される。

戻るアイコン１０ｂに対する選択操作があったときには、直前までユーザが表示していた画面に戻る。例えば、当コンテンツ画面に、図１１（Ａ）のコミュニティ画面から遷移してきた場合には、図１１（Ａ）のコミュニティ画面に戻り、図１０のホーム画面から遷移してきた場合には、図１０のホーム画面に戻る。

カテゴリ８５は、コンテンツにカテゴリが関連付けられていた場合に、関連付けられたカテゴリ名で表示される。内容７４ｂには、コンテンツのタイトルや説明文などの投稿されたテキスト情報が表示される。

関連タレント８８は、コンテンツに、図５のタレントが関連付けられていた場合に表示され、関連付けられたタレントのアイコンや名前などを表示する。特別アクション７９は、コンテンツに対して図５のタレントに対応する特別ユーザからアクションがあった場合に、当該特別ユーザからアクションがあったコンテンツであることを示すための表示である。

各コメント８７には、コメント投稿者を表示する投稿者７１ｂ、コメントに対する図１１（Ｂ）の通報や非表示等を行うことを可能とする通報アイコン７２ｂ、コメントに対する返信を可能とする返信アイコン８６、返信を一覧表示させる返信一覧８９などが表示されている。なお、コメント投稿欄８４には、ユーザ自身のアイコンが表示されていてもよい。

各コメント８７は、投稿者によって表示態様を変化させてもよい。例えば、コメント８７ａは、図５に例示するタレント「ＡＡＡ」に対応する特別ユーザ（ＡＡＡ本人）によるコメントである。例えば、図１３のコンテンツ画面の下部におけるコメント一覧の表示順を、もっとも上に表示されるようにしてもよく、色を他のユーザによるコメントと識別できるよう変化させてもよい（表示態様を異ならせてもよい）。これにより、ファンコミュニティにおいて、ユーザに対してタレントとの交流を促すことができ、ユーザの満足度が向上する。

次に、図１４を参照して、配信サーバ１００のコンテンツデータ１２２として記憶される各コミュニティにおけるコンテンツのデータベースの例を説明する。例えば、図１４は、「コミュニティＡ」のコンテンツデータベースである。コンテンツデータベースには、「チャンネル」、各チャンネルに対する「投稿権限」、コンテンツ毎の「記事ＩＤ」などの情報が記憶されている。

「チャンネル」は、話題別の分類であり、各チャンネルの画面は、図１２で例示したチャンネル一覧８２に対する選択操作により、選択して表示可能である。例えば、「公式チャンネル」は、運営者からの公式のお知らせが投稿されるチャンネルであり、「グループＡ雑談」は、「コミュニティＡ」に対応する図５の所属グループ１の「グループＡ」についての雑談がテーマであるチャンネルである。また、「切り抜き」は、ユーザのおすすめの切り抜き動画（例えば、動画配信サイトに投稿された動画であって、すでに動画配信サイトにおいて投稿された動画の一部が切り抜かれた動画である）のリンクなどを共有することをテーマとするチャンネルである。「過去おすすめ」は、例えばグループＡに関する動画（例えば、所属するタレントの過去の投稿動画）などを、おすすめすることをテーマとするチャンネルである。なお、図１２のチャンネル一覧８２における「すべてのチャンネル」に対する選択操作がされると、図１４のチャンネルのコンテンツがすべてまとめて表示されるようになる。また、これらのチャンネルは一例であり、例えば、一時的な特設チャンネルが設けられることがあってもよい。

「投稿権限」は、各「チャンネル」においてコンテンツの投稿が可能な権限を有するユーザに関する情報である。例えば、「公式チャンネル」や「過去おすすめ」については、公式アカウント（例えば、運営者や、タレントなどの特別ユーザ）からのみ投稿することができる。公式アカウントからの投稿は、例えば、管理者端末２００からの投稿や、ユーザ端末３００と同じ構成の端末からの投稿であっても、公式アカウントと識別されるユーザＩＤであれば行うことができる。また、「グループＡ雑談」や「切り抜き」については、全ユーザが投稿可能である。例えば、図１２のチャンネル一覧８２に、公式アカウントからのみ投稿可能なチャンネルには、公式マークを表示させ、全ユーザが投稿可能なチャンネルには、吹き出しマークなどが表示される。これにより、ユーザは、投稿が可能なチャンネルであるか否かを容易に識別できる。

「記事ＩＤ」は、各コンテンツを識別するＩＤであり、コンテンツ毎に付与される。また、「記事ＩＤ」毎に「カテゴリ」、「投稿者ＩＤ」、「タレントＩＤ」が関連付けられている。

「カテゴリ」は、コンテンツが投稿される際に関連付けることが可能なカテゴリである。例えば、「イベント」、「グッズ」、「配信・動画」、「ファンアート」、「切り抜き」、「音楽」、「記念配信」など、コンテンツ自体がどのようなテーマであるかを、容易に認識するために関連付けることができる。「カテゴリ」が関連付けられていた場合、図１３のコンテンツ画面例のカテゴリ８５に、カテゴリ名が表示されるようになる。

「投稿者ＩＤ」は、コンテンツの投稿者を識別するＩＤである。

「タレントＩＤ」は、図５のタレント情報データベースにおいて記憶されているタレントＩＤのうち、コンテンツの投稿時に関連付けられた関連タレントのタレントＩＤである。このように本実施例においては、コンテンツを投稿する際に、投稿者によって当該コンテンツの内容に応じて関連タレントを関連づけることができ、コンテンツ毎に関連付けた「タレントＩＤ」を記憶しておくことができる。つまり、各コンテンツデータがタレントのメタ情報とともに記憶されている。

例えば、記事ＩＤ「ａ１」には、カテゴリ「イベント」が関連付けられ、投稿者は「ｏｕ１」であり、タレントＩＤに「ｔ１」、「ｔ２」、「ｔ６」、「ｔ１４」が関連付けられている。前述の図１３は、記事ＩＤ「ａ１」の表示例であり、投稿者７１には、ユーザＩＤ「ｏｕ１」に対応する、「スタッフＳ」の名前と公式アカウントであることを示す公式マークが表示されている。また、カテゴリ８５には、記事ＩＤ「ａ１」に関連付けられたカテゴリ「イベント」が表示されている。

関連タレント８８には、記事ＩＤ「ａ１」に関連付けられたタレントＩＤ「ｔ１」、「ｔ２」、「ｔ６」、「ｔ１４」に各々対応するタレント「ＡＡＡ」、「ＢＢＢ」、「ＦＦＦ」、「ＭＭＭ」のアイコンや名前が表示されている。このように、投稿時に関連タレントを設定することができるため、コンテンツに関連タレントを表示させることができ、ユーザは、いずれのタレントに関する投稿なのかを容易に識別することが可能となる。なお、関連タレント８８は、図１１（Ａ）で例示したコミュニティ画面のコンテンツ見出し７０においても表示されていてもよい。

このように、コンテンツには関連タレントを関連付けることができる。そのため、関連タレントに、ユーザが予め選択した推しタレントが含まれていた場合には、配信サーバ１００は、アカウント情報１２５として記憶するユーザ情報データベースの情報に基づいて、ユーザに対して推しタレントに関する投稿があったことをプッシュ通知で報知することができる。例えば、推しタレントが関連タレントに関連付けられたコンテンツの投稿があったとき、あるいは、所定時間経過毎（例えば、５分、１５分経過毎など）に、推しタレントが関連タレントに関連付けられたコンテンツの投稿があったことをユーザにプッシュ通知する。プッシュ通知があったときは、ユーザからプッシュ通知に対する操作が行われることにより、推しタレントが関連付けられたコンテンツのコンテンツ画面（例えば図１３など）へ遷移することができる。推しタレントが関連タレントに関連付けられたコンテンツの投稿があったときとは、図１０のホーム画面や、図１１（Ａ）のコミュニティ画面において、当該コンテンツのコンテンツ見出し（６０，７０）が表示されるようになるときである。

なお、カテゴリ、および、関連タレントは、コンテンツの投稿時に投稿者の任意で設定することができるものとして、関連付けなくてもコンテンツの投稿ができるものであってもよい。例えば、コミュニティＡ内の投稿であって、記事ＩＤ「ａ９９」のように関連タレントが関連付いていないコンテンツが投稿されてもよく、この場合当該コンテンツには、コミュニティＡ（第１属性）のみが関連付いている。

（ホーム画面の具体例）
図１０に戻り、ホーム画面において表示されるコンテンツについての詳細を説明する。ユーザ端末３００毎のホーム画面には、コンテンツデータ１２２として記憶する図１４で例示したコンテンツデータベースのうち、アカウント情報１２５として記憶する図１３で例示したユーザ情報データベースにおいて関連付けられている「参加コミュニティ」と対応するコンテンツデータベースに記憶されているコンテンツが表示されるようになっている。すなわち、ユーザ毎のホーム画面の推しトピック６２以降のカテゴリについては、ユーザが参加しているコミュニティ内において投稿されたコンテンツのコンテンツ見出しのみが表示されるようになっている。例えば、図６、図９などで予め選択したコミュニティが、「コミュニティＡ」および「コミュニティＢ」であれば、ホーム画面には、「コミュニティＡ」、「コミュニティＢ」および、常に参加状態である「コミュニティＰ」に投稿されたコンテンツが、まとめて表示される。なお、常に参加状態のコミュニティがなかった場合には、ホーム画面には、ユーザが予め選択したコミュニティ内に投稿されたコンテンツが表示される。一方、参加していない「コミュニティＣ」に投稿されたコンテンツについては表示されない。また、推しトピック６２以降のカテゴリについては、後述する推しフィルター２０のオンオフ操作に応じて表示されるコンテンツ見出し６０が変化する。

なお、いずれのカテゴリにおいても、ホーム画面において表示可能なコンテンツは１つであってもよく、最新の所定数（例えば、２枚、５枚、７枚など）のコンテンツのコンテンツ見出し６０が表示されるようにしてもよい。あるいは、人気順の所定数のコンテンツのコンテンツ見出し６０が表示されるようにしてもよい。また、カテゴリ毎のコンテンツ見出し６０は、ユーザ端末３００のタッチパネル等に対し、左右のスライド操作などがされることにより、表示される見出しの切り替えなどがされるようにしてもよい。例えば、図１０の記念配信６４に表示されるコンテンツ見出し６０（例えば日付が最新）を左にスライドさせる操作（フリック操作など）をすることにより、画面右側から日付が古いコンテンツ見出し６０が現れるようになってもよい。また、例えば、画面右側に半分だけ表示されていてもよく、スライド操作をしなければ現れないものであってもよい。

なお、ホーム画面のいずれのカテゴリのコンテンツ見出し６０においても、コンテンツに、図５のタレントが関連付けられていた場合に、関連付けられたタレントのアイコンや名前などを表示する関連タレント８８が表示されていてもよい。

また、推しトピック６２には、ユーザが参加するコミュニティ内で投稿されたコンテンツのうち、ユーザが図６、図９などで例示した予め選択した推しタレントが関連付けられたコンテンツが、所定数表示されるようになっている。例えば、「コミュニティＡ」に参加しており、タレント「ＡＡＡ」を推しタレントに選択しているユーザの推しトピック６２には、図１４のコミュニティＡのコンテンツデータベースに記憶されているコンテンツのうち、タレント「ＡＡＡ」に対応するタレントＩＤ「ｔ１」が関連付けられたコンテンツが抽出して表示される。

人気のユーザ投稿６３には、ユーザが参加するコミュニティの公式アカウント以外の一般のユーザによる投稿がされたコンテンツのうち、人気があると考えられるコンテンツが所定数表示される。例えば、好感アクション（タップアクションおよび／またはコメント）が多い順、エンゲージメント率が高い（例えば、閲覧数に対して好感アクションがあった割合が高いコンテンツなど）順であってもよい。

また、ホーム画面に表示されるコンテンツには、コンテンツデータベースで記憶されるコンテンツのうち、特定のカテゴリが関連付けられているコンテンツが表示されるカテゴリがあってもよい。例えば、記念配信６４には、コンテンツデータベースで記憶されるコンテンツのうち、カテゴリ「記念配信」が関連付けられたコンテンツが表示され、グッズ７０５には、カテゴリ「グッズ」が関連付けられたコンテンツが表示される。なお、所定のコミュニティの特定のチャンネルの投稿のみが表示されるカテゴリがあってもよい。例えば、「コミュニティＰ」の特定のチャンネルに投稿された最新の所定数のコンテンツ見出し６０が表示されるカテゴリがあってもよい。また、ホーム画面に表示されるこれらのカテゴリは一例であり、一時的な特設カテゴリが設けられていてもよい。

なお、ホーム画面の推しトピック６２は、ホーム画面に表示し得るカテゴリのうち、フィーチャー６１を除いた最上部に優先して表示させている。これにより、ユーザは推しタレントの情報の特定が容易となる。しかし、これに限らず、推しトピック６２が、フィーチャー６１を含む最上部に優先して表示されてもよい。あるいは、推しトピック６２のよりも優先して表示される他のカテゴリがあってもよい。運営者がユーザに認識してほしいと考えるカテゴリの順番で表示させるようにすることができる。

また、推しトピック６２のコンテンツ見出し６０に表示されるコンテンツと、推しトピック６２以降の他のカテゴリのコンテンツ見出し６０に表示されるコンテンツとは重複していてもよく、あるいは、推しトピック６２に表示されていれば、他のカテゴリのコンテンツ見出し６０には表示されないものとしてもよい。なお、予めいずれのタレントも推しタレントに選択していないユーザには、推しトピック６２は表示されない。

（選択された属性に関するコンテンツの属性抽出処理の具体例）
次に、図１５、図１６を参照し、ユーザが予め選択した推しタレント（第２属性）が関連付けられたコンテンツが表示されるように絞り込むフィルター機能について説明する。本実施例におけるファンコミュニティアプリにおいて、ユーザ端末３００に表示されるコンテンツは、ユーザが予め選択した参加コミュニティ（第１属性）への絞り込みに加え、各コンテンツデータがタレントのメタ情報とともに記憶されているため、さらにユーザが予め選択した推しタレント（第２属性）への絞り込みをユーザの意思に基づく所定条件成立により行うことができる。

推しタレントが関連付けられたコンテンツへの絞り込みは、ユーザ端末３００に対する所定の切替操作により行われる。所定の切替操作とは、所定のアイコンを選択する操作などである。例えば、図１０のホーム画面、および、図１１（Ａ）のコンテンツ画面の推しフィルター６０に対する選択操作などである。

図１５は、図１１（Ａ）のコンテンツ画面において、推しフィルター２０のオン状態およびオフ状態であるときの画面例である。図１５（Ａ）は、推しフィルター２０がオンとなっており、ユーザが予め設定した推しタレントへの絞り込みが有効となっている状態での画面例である。図１５（Ｂ）は、推しフィルター２０がオフとなっており、ユーザが予め設定した推しタレントへの絞り込みが有効ではないときの状態での画面例である。

図１５は、例えば図７のユーザ「ｕ１」のユーザ端末３００に表示される画面例であるものとする。図１５（Ａ）では、推しフィルター２０がオンとなっているため、ユーザ「ｕ１」が予め推しタレントとして選択したタレントが関連付けられたコンテンツのみが抽出されている。すなわち、アカウント情報１２５として記憶されるユーザ情報データベースにおいて、ユーザ「ｕ１」に関連付けられているタレントＩＤは、タレント「ＡＡＡ」のタレントＩＤ「ｔ１」、タレント「ＢＢＢ」のタレントＩＤ「ｔ２」、タレント「ＥＥＥ」のタレントＩＤ「ｔ５」であるため、コンテンツデータ１２２として記憶するコンテンツ情報データベースのうち、いずれかのタレントＩＤが関連付けられたコンテンツのみが抽出される。例えば、図１４のコミュニティＡのコンテンツ情報データベースの、タレントＩＤ「ｔ１」、「ｔ２」が関連付いている記事ＩＤ「ａ１」のコンテンツや、「ｔ５」が関連付いている記事ＩＤ「ａ７」のコンテンツ（のコンテンツ見出し６０，７０）が表示される。

一方、ユーザ「ｕ１」が選択したタレントがいずれも関連付いていない記事ＩＤ「ａ４」は表示されない。例えば、参加コミュニティ内に投稿されたコンテンツであっても、そもそも関連タレントが関連付いていないコンテンツのコンテンツ見出し（６０，７０）は表示されない。これに対して、推しフィルター２０がオフになると、図１５（Ｂ）に示すように、ユーザ「ｕ１」が選択した推しタレントが関連付けられていないコンテンツである、タレント「ＤＤＤ」に関するコンテンツのコンテンツ見出し７０ｄや、タレント「ＦＦＦ」に関するコンテンツのコンテンツ見出し７０ｅ、あるいは、いずれのタレントも関連付けられていないコンテンツのコンテンツ見出し７０などが表示されるようになる。

（属性抽出処理の流れの例）
次に、図１６を参照して、ユーザが予め選択した属性に関するコンテンツを抽出する属性抽出処理の流れについて説明する。図１６は、図１５を参照して説明した属性抽出処理のフローチャートを説明するための図である。属性選択処理は、配信サーバ１００において、ユーザ端末３００からの要求（例えば、推しフィルター２０への操作情報など）を受信することに応じてコンテンツ管理部１３２によって繰り返し実行される。

ステップＳ２０１では、ユーザ端末３００から、コンテンツの表示要求操作があったか否かが判定される。表示要求操作とは、ユーザ端末３００において表示用データを読み込ませる操作と、所定条件成立による推しフィルター２０をオンまたはオフにする選択操作が含まれる。表示用データを読み込ませる操作には、例えばアプリへのログイン（アプリを開いたタイミングでのサーバへの問い合わせ）、リロード操作（再読み込み操作）、あるいは、アプリ画面のホームアイコン１３、コミュニティアイコン１４、図１２のチャンネル一覧８２に表示されるチャンネルなどへの選択操作が含まれる。所定条件の成立は、例えば、ユーザがユーザ端末３００の表示される推しフィルター２０のアイコンをタップ操作により切り替えることである。

ステップＳ２０１で、表示要求操作があったと判定されなければ処理を終了する。一方、ステップＳ２０１で、ユーザ端末３００から表示要求操作があったと判定されたときには、ステップＳ２０２で推しフィルターがオンになっているか否かが判定される。本実施例においては、推しフィルター２０のデフォルトの設定はオフの状態である。そのため、アプリ起動時などにおいてログインしたタイミング、あるいは、アプリ起動後はじめて表示するチャンネルのコンテンツ画面やホーム画面では、推しフィルター２０はオフになっている。この場合、ステップＳ２０２で、推しフィルター２０がオンになっていると判定されないため、ステップＳ２０３に進む。

ステップＳ２０３では、表示要求操作送信元のユーザ端末３００のユーザにより選択されている参加コミュニティに関する情報を抽出して、当該ユーザ端末３００に送信して処理を終了する。選択されている参加コミュニティとは、図６（Ａ）や図９で例示したユーザが予め選択したことでアカウント情報１２５として記憶されているユーザ毎の「所属コミュニティ」および、常に参加状態となっているコミュニティがある場合には、常に参加状態のコミュニティが含まれる。例えば、図７のユーザ「ｕ２」であれば、「コミュニティＡ」および「コミュニティＢ」に参加している。そのため、ステップＳ２０３において、ユーザ「ｕ２」のユーザ端末３００には、ホーム画面には「コミュニティＡ」、「コミュニティＢ」、および常に参加状態の「コミュニティＰ」内で投稿されたコンテンツが表示されるようにし、図１２のチャンネル一覧画面においては、「コミュニティＡ」、「コミュニティＢ」、および「コミュニティＰ」のコミュニティバー８１が表示されるようになる。

ステップＳ２０２に戻り、推しフィルターがオンになっていると判定されたときには、ステップＳ２０４に進む。例えば、推しフィルター２０をオンにする選択操作がされたときに、ステップＳ２０１で表示要求操作があったと判定され、かつ、ステップＳ２０２において推しフィルターがオンであると判定される。また、アプリ起動後、推しフィルター２０をオンにする操作をすでに行っているチャンネルのコミュニティ画面や、ホーム画面においてリロード操作を行った場合、あるいは、推しフィルター２０をオンにしている状態で図１３のコンテンツ画面を表示させたあとに、推しフィルター２０をオンにしていたコミュニティ画面やホーム画面に戻った場合にも、推しフィルター２０がオンの状態が記憶（記憶部１２０あるいは記憶部３２０へ記憶）されており、ステップＳ２０１で表示要求操作があったと判定され、かつ、ステップＳ２０２で推しフィルターがオンであると判定される。

ステップＳ２０４では、選択されている参加コミュニティのうち、選択されている推しタレントに関する情報を抽出して、ユーザ端末３００に送信して処理を終了する。例えば、ユーザ「ｕ２」であれば、「コミュニティＡ」、「コミュニティＢ」、および「コミュニティＰ」内で投稿されたコンテンツのうち、タレントＩＤ「ｔ２」、「ｔ３」、「ｔ４」、「ｔ７」、「ｔ８」が関連付いているコンテンツのみが抽出されて、チャンネルのコンテンツ画面や、ホーム画面に表示されるようになる。ホーム画面においては、推しトピック６２以降のカテゴリ（図１０におけるフィーチャー６１および、推しトピック６２以外のカテゴリ）については、参加しているコミュニティかつ、推しフィルター２０への選択操作によって、ユーザが予め選択した推しタレントが関連付けられたコンテンツのコンテンツ見出し６０が表示されるようになる。

なお、属性抽出処理が配信サーバ１００で実行される例について説明したが、ユーザ端末３００で実行されるものであってもよく、例えば、ユーザ毎の推しタレントに関する情報を、ユーザ端末３００の記憶部３２０で記憶し、配信サーバ１００から取得したコンテンツに関する情報（例えば、１０件ごとなど）をユーザ端末３００で抽出してもよい。

また、推しタレントとは異なるタレントが投稿したコンテンツや、推しタレントとは異なるタレントが主体（主役）のコンテンツであっても、コンテンツに関連付けられたタレントに、ユーザが予め選択した推しタレントが関連付けられていれば、推しフィルター２０をオンにすることにより、図１０のホーム画面や、図１１（Ａ）のコミュニティ画面において推しタレントとは異なるタレントに関するコンテンツのコンテンツ見出し（６０，７０）が表示されるようになる。例えば、図１１（Ａ）のコンテンツ見出し７０ｃに対応するタレント「ＡＡＡ」が投稿したコンテンツが、タレント「ＡＡＡ」の誕生日のイベントに関するコンテンツであったとする。しかし、「ＡＡＡ」の誕生日イベントに、タレント「ＢＢＢ」がお祝いで参加する予定（コラボともいう）であるため、関連タレントに「ＢＢＢ」が設定されていたとする。そうすると、コンテンツデータベースにおいて、コンテンツ見出し７０ｃに対応する記事に、タレント「ＢＢＢ」に対応するタレントＩＤ「ｔ２」が関連付くことになる。これにより、推しタレントにタレント「ＡＡＡ」を選択していないユーザのユーザ端末３００において推しフィルター２０をオンにした場合であっても、タレント「ＡＡＡ」の誕生日イベントに関するコンテンツ見出し７０ｃが表示されるようになる。その結果、一見推しタレントと関連しないとして見落としてしまいそうな情報であったとしても、ユーザは推しタレントに関する情報を見逃すことがなくなる。

なお、推しフィルター２０がオンの状態でなかったとしても（推しフィルターオン、オフいずれの状態においても）、関連タレント８８を、図１０のホーム画面、図１１（Ａ）のコミュニティ画面、あるいは、図１３のコンテンツ画面自体に表示させることができる。そのため、推しタレントを個々に設定せずとも、コンテンツには、グループの誰が関連しているかをユーザは認識することができ、興趣が向上する。

（ユーザからの投稿によるカテゴリやタレント等の関連付けの具体例）
次に、図１７、図１８を参照して、ユーザからコンテンツが投稿される際のユーザ投稿処理についての具体例を説明する。図１７は、ユーザの投稿画面例である。例えば、図１６のコミュニティコンテンツデータベースにおいて「投稿権限」が「ユーザ」と設定されているチャンネルのコンテンツ画面が表示されている際に、図１１（Ａ）で例示する投稿アイコン２３を選択することにより表示される。なお、公式チャンネル等の投稿権限が公式アカウントのみしか投稿できないチャンネルについては、権限のないユーザは、コンテンツ画面において投稿アイコン２３が選択できないようになっていてもよい。例えば、グレーで表示するなど表示態様を変更する、あるいは、投稿アイコン２３自体が表示されないようになっていてもよい。

図１７（Ａ）は、チャンネル「グループＡ雑談」のコンテンツ画面において、投稿アイコン２３を選択したときに表示される画面である。図１７（Ａ）には、タイトルや、本文等の入力欄や、画像アイコン３７、次へアイコン３８などが表示される。画像アイコン３７は、選択操作がされることにより、ユーザ端末３００で保存している画像をアップロードすることができる。次へアイコン３８が選択操作されることにより、図１７（Ｂ）の画面へ遷移する。なお、タイトル入力および本文への入力がされていなければ次に進めなくてもよい。本文への入力の代わりに、画像がアップロードされていれば、次に進めるようになっていてもよい。空の投稿が乱立することを避けるためである。

図１７（Ｂ）の画面では、投稿するコンテンツに関連付けるカテゴリと、関連タレントを選択することが可能である。例えば、カテゴリバー３９を選択すると、図１７（Ｃ）で例示するように、カテゴリ一覧３９ｂが開く。ユーザはカテゴリ一覧から、任意のカテゴリを選択することができる。なお、選択できるカテゴリは１つであってもよく、複数のカテゴリが選択できるようになっていてもよい。図１７（Ｂ）の関連タレントバー４０を選択すると、図６（Ｂ）のような、タレントの一覧が表示され、任意のタレント（関連付けたいタレント）を選択することができる。なお、関連タレントの選択は、１人に限らず複数人選択することが可能である。投稿するアイコン４１に対する選択操作がされれば、「グループＡ雑談」にコンテンツが投稿される。

（ユーザ投稿処理の流れについて）
次に、図１８を参照して、ユーザがコンテンツを投稿する際のユーザ投稿処理の流れについて説明する。図１８は、図１７を参照して説明したユーザ投稿処理のフローチャートを説明するための図である。ユーザ投稿処理は、ユーザ端末３００の制御部３５０によって繰り返し実行される。

ステップＳ３０１では、投稿アイコンが選択されたか否かが判定される。例えば、図１１（Ａ）などのコンテンツ画面の投稿アイコン２３に対する選択操作がされたか否かが判定される。投稿アイコン２３が選択されたと判定されなかったときには、処理を終了する。一方、投稿アイコン２３が選択されたと判定されたときには、ステップＳ３０２で、投稿されようとしているチャンネルが、ユーザ投稿が許可されているチャンネルであるか否かが判定される。例えば、図１４のチャンネル「グループＡ雑談」、「切り抜き」であれば、全ユーザに投稿が許可されているため、ステップＳ３０３で、図１７（Ａ）の投稿画面を表示する。これにより、例えば文字情報の入力や、画像アイコン３７への操作により画像添付を行うことができる。

一方、図１２のチャンネル一覧８０２で「すべてのチャンネル」が選択されているときのコンテンツ画面や、チャンネル「公式チャンネル」、「過去おすすめ」のコンテンツ画面が表示されていた場合には、公式アカウントにのみ投稿が許可されているため、ステップＳ３０２でユーザ投稿許可チャンネルであると判定されず、処理を終了する。

ステップＳ３０３で、投稿画面を表示したあとは、ステップＳ３０４で、次へが選択されたか否かが判定される。例えば、図１７（Ａ）の投稿画面において、次のページへ進む操作として、次へアイコン３８が選択されたか否かが判定される。ステップＳ３０３で、次へが選択されたと判定されたときには、ステップＳ３０５で文字入力が済みであるか否かの判定がされる。文字入力がされていなければ、ステップＳ３０４に戻る。

一方、ステップＳ３０４で、次へが選択されたと判定されなかったときには、ステップＳ３０６で閉じるが選択されたか否かの判定がされる。たとえば、閉じるアイコン３５への選択操作などである。ステップＳ３０６で閉じるが選択されたと判定されたときには、処理を終了する。一方、ステップＳ３０６で閉じるが選択されたと判定されなかったときには、ステップＳ３０４に戻る。

ステップＳ３０５で文字入力が済みであると判定されたときには、ステップＳ３０７で、カテゴリ等選択画面を表示させる。例えば、図１７（Ｂ）のカテゴリや関連タレントを選択できる画面である。

ステップＳ３０７で、カテゴリ等選択画面を表示させたあとは、ステップＳ３０８でカテゴリ選択があったか否かが判定される。ステップＳ３０８で、カテゴリが選択されたと判定されれば、ステップＳ３０９で投稿情報にカテゴリが関連付けられる。例えば、図１７（Ｃ）のカテゴリ一覧３９ｂで、「イベント」が選択されれば、投稿情報にカテゴリ「イベント」が関連付けられる。

ステップＳ３０８でカテゴリの選択があったと判定されなかったとき、あるいは、ステップＳ３０９でカテゴリが関連付けられたあとは、ステップＳ３１０で関連タレントの選択があったか否かの判定がされる。ステップＳ３１０で関連タレントの選択があったと判定されたときには、ステップＳ３１１で投稿情報に関連タレントを関連付ける。例えば、図１７（Ｂ）で、関連タレントバー４０が選択されることにより、タレント「ＡＡＡ」が選択されれば、投稿情報にタレントＩＤ「ｔ１」が関連付けられる。

ステップＳ３０９で関連タレントの選択があったと判定されなかったとき、あるいは、ステップＳ３１０で関連タレントの関連付けがされたあとは、ステップＳ３１２で投稿確定操作があったか否かの判定がされる。例えば、図１７（Ｂ）の投稿するアイコン４１に対する選択操作があるか否かの判定がされる。ステップＳ３１２において投稿確定操作があったと判定されたときには、ステップＳ３１３で投稿情報（例えば、入力された文字情報や、添付された画像情報、選択されたカテゴリ、選択された関連タレント、投稿者のＩＤなどを特定する情報が含まれる。）を配信サーバ１００に送信して処理をする。これにより、例えば、「グループＡ雑談」において、カテゴリ「イベント」を選択し、関連タレントとして「ＤＤＤ」を選択していた場合には、配信サーバ１００では、図１４で例示する記事ＩＤ「ａ４」のように、記憶される。

ステップＳ３１２に戻り、投稿確定操作があったと判定されなかったときには、ステップＳ３１４で閉じる選択がされたか否かが判定される。閉じる選択とは、例えば、図１７（Ｂ）の画面における閉じるアイコン３５への選択操作などである。ステップＳ３１４において閉じるが選択されたと判定されたときには、処理を終了する。

一方、ステップＳ３１４で閉じるが選択されたと判定されなかったときには、ステップＳ３１５で戻るが選択されたか否かが判定される。例えば、図１７（Ｂ）の戻るアイコン３６に対する選択操作などである。ステップＳ３１５で、戻るが選択されたと判定されたときには、ステップＳ３０３に戻り、図１７（Ａ）の文字入力の投稿画面の表示に戻る。これにより、ステップＳ３０４の次への選択前に投稿画面において入力していた文字や画像の情報を再編集することができる。一方、ステップＳ３１５で、戻るが選択されたと判定されなかったときには、ステップＳ３０７で、引き続きカテゴリ等選択画面を表示させる。なお、ユーザ投稿処理がユーザ端末３００で実行される例について説明したが、配信サーバ１００で実行され、ユーザ端末３００に表示情報が送信されるものであってもよい。

＜ファンコミュニティ内におけるユーザの評価に基づく行動制御機能について＞
（行動制御機能についての概要）
次に、本実施例のファンコミュニティ内におけるユーザの評価に基づく行動制御機能について説明する。本実施例におけるファンコミュニティにおいては、ユーザ自身もコミュニティ内にコンテンツを投稿することが可能であり、他のユーザと共有することができる。このように、他のユーザとの交流を図ることでコミュニティが活性化する一方、ユーザが取り得るアクションに何らの制限をかけない場合、他のユーザが不快感を覚え得るような投稿をするユーザが野放しになることで、コミュニティ内の治安・雰囲気が悪化する虞がある。そのため、ユーザ毎に信用度・誠実度などの指標となるレベルを定め、レベルに応じてコミュニティ内で取り得る行動を変化させる。本実施例においては、ユーザがコミュニティ内で取った行動に応じて、ユーザ本人とは異なる外部からの評価がなされることにより、ユーザの評価履歴状況が更新され、評価履歴状況に応じて、コミュニティ内で取り得る行動を変化させる。これにより、信用度・誠実度などの指標が高いユーザが取り得る行動が増え、指標が低いユーザが取り得る行動に制限がかかるようになる。すなわち、ファンコミュニティ内において受け入れられる行動を取ることで、評価履歴状況が変動する。

（ユーザのレベルの変動についての概要）
各ユーザの「レベル」は、図７のユーザ情報データベースで例示するように、ユーザＩＤに関連付けて記憶されている。「レベル」は「累積ポイント」に応じて変動する。「累積ポイント」は、後述する外的評価に応じて変動する。例えば、初期設定でユーザのレベルが１であり、累積ポイントが１０になると、レベルが２になる。レベル２からレベル３にあがるためには、レベル１から２に上がるときに必要であったポイント数よりも多いポイント数が必要となり、例えば累積ポイントが２１になったときに、レベル３になる。このように、レベルが上がっていくにつれ、必要なポイント数が多くなり、レベルが上がりにくくなる。また、外的評価に応じて「累積ポイント」は減少していくこともあるため、例えば、レベル２であったユーザの累積ポイントが２０を切ったときに、レベルが２から１に下がる。

また、各ユーザは、自身の「レベル」および「累積ポイント」を図８で例示したマイページの、ユーザ評価履歴状況５５で確認することができる。これによりユーザはレベルが上がるような行動を取るよう心掛けることができる。一方、他のユーザの「レベル」および「累積ポイント」は確認することができない。このように、自身のレベルについては、他のユーザに公表されないことで、コミュニティ内でレベルの低いユーザが引け目を感じてしまうことや、レベルの高いユーザが傲慢にふるまってしまうことを抑制できる。なお、「レベル」、「累積ポイント」は、いずれか一方のみマイページに表示されるようになっていてもよい。

（レベル別に取り得る行動について）
図１９、図２０、図２１を参照して、本実施例におけるユーザのレベル別に取ることができる行動について説明する。図１９は、レベル別に許可される（取り得る）行動内容の例を示す表であり、例えば、レベル「１～４９」、「５０～５９」、「６０～６９」、「７０～７９」、「８０～８９」、「９０～９９」、および「１００」の段階に区切られている。レベルの段階ごとに許可される行動については、配信サーバ１００の行動権限情報１２４などとして記憶されている。

レベルに応じて取ることができるか否かが制御される行動である「特定アクション」には、例えば「投稿リンク制限なし」、「企画作成」、「モデレータ招待」、「コミュニティ作成」などが含まれる。「投稿リンク制限なし」とは、ユーザがコミュニティ内にコンテンツの投稿を行う際に、投稿可能なＵＲＬの制限がなくなることであり、レベルが６０以上のユーザであれば制限が解除される。また、投稿リンク制限なしのユーザが行ったコンテンツの投稿は、レベルが５９以下のユーザのユーザ端末３００においても反映される。つまり、レベルが５９以下のユーザであれば、投稿が制限されるリンクが含まれるコンテンツであったとしても、レベル６０以上のユーザが投稿したコンテンツであれば、当該リンクを含めてレベル５９以下のユーザも閲覧（およびリンクにアクセスする操作も含む）することができる。

「企画作成」とは、コミュニティ内で企画（イベント）を立ち上げることができる権限であり、レベル８０以上のユーザから作成することができるようになる。例えば、所定の日時にリアルあるいはバーチャル空間に集合する所謂オフ会のようなイベント企画や、アンケート企画などを立ち上げることができる。すなわち、リーダー格としての行動を取ることができるようになる。また、レベル７９以下のユーザであっても、レベル８０以上のユーザが作成した企画に参加することができる。

「モデレータ招待」とは、コミュニティ内において投稿されたコンテンツの管理者としての役割ができるようになることであり、レベル９０以上のユーザとなればできるようになる。例えば、通常運営者が行う、目視により不適切な投稿がされたコンテンツやコメントの削除や、非表示設定（規制ともいう）を行うことである。また、悪質なユーザなどのアカウントを停止させる（例えば一定期間）措置を取ることができる権限であってもよい。レベル９０以上のユーザによって規制されたコンテンツは、レベル８９以下のユーザのユーザ端末３００においても表示されなくなる。

「コミュニティ作成」とは、図６（Ａ）などで例示した、ユーザが参加することができるコミュニティを新たに作成することができ、例えば、最も信用度が高いレベル１００のユーザにのみ許可される行動内容である。例えば、グループＡ（コミュニティＡに対応）のファンが作るグループＡを応援するコミュニティとして、「コミュニティＡ２」などを作成することができる。作成されたコミュニティＡ２は、図６（Ａ）の参加コミュニティ設定画面における参加コミュニティ選択エリア５０に表示されるようになる。あるいは、新たな「チャンネル」が作成できるようになってもよい。例えば、「コミュニティＡ」のチャンネルの中に、新たなテーマのチャンネルを追加することができる。新たに追加されたチャンネルは、図１２のチャンネル一覧表示８２に表示されるようになる。レベル１００のユーザが作成したコミュニティやチャンネルは、レベル９９以下のユーザも参加・選択をすることができる。

また、本実施例におけるユーザのレベルは、上がるだけでなく、下がることもある。そのため、図１９に例示する特定アクションは、レベルが上がったことによって許可された特定アクションであっても、レベルが下がることにより、制限がかかり取り得ることができなくなる。例えば、レベル８０以上のユーザは、コミュニティ内で企画を作成することができるが、レベルが７９に下がることで、企画を作成することができなくなる。また、作成された企画や、コミュニティが、ファンコミュニティアプリにおいて不適切であるとして、当該作成された企画や作成されたコミュニティの表示画面などにおいて他のユーザからの報告が行われることなども、当該企画やコミュニティを作成したユーザのレベルが下がり得る外的評価となる。

図２０は、「投稿リンク制限なし」ではないユーザのユーザ端末３００における投稿画面の例である。本実施例においては、レベル５９までの投稿リンクに制限があるユーザが投稿できるＵＲＬは、「動画共有サイトＡ」と、「ＳＮＳ－Ｂ」のリンクのみ許可されているものとする。この場合、投稿しようとする本文に、「動画共有サイトＡ」と、「ＳＮＳ－Ｂ」以外のＵＲＬが入力されると、図２０に例示するように「現在、ＵＲＬは「動画共有サイトＡ」と、「ＳＮＳ－Ｂ」のみ投稿可能です」などのメッセージが表示される。また、次へアイコン３８を投稿できるときと投稿できないときとで異なる態様で表示する場合には、次へアイコン３８を投稿できない態様で表示して、選択操作ができないようになっていてもよい。このように、アップロードされた画像などについては画像認識による自動判定により不適切な画像（暴力的など不快感を与える可能性のある画像）を非表示にすることが比較的容易であるのに対し、ＵＲＬについては、参照先が悪意のあるウェブサイト（例えば偽サイト、詐欺サイト、その他不快感を覚える内容が投稿されているページなど）であったとしても判定が容易ではなく、運営者による非表示設定などを行う必要があり手間がかかる。そのため、不適切な投稿でないか否かの判定が難しいコンテンツ（ここではＵＲＬのリンク）については、レベルが高いユーザ（信頼度が高いユーザ）のみが投稿できるようにすることで、運営者の負担を低減しつつ、かつ、不適切な投稿を抑制することでコミュニティ内の治安を安定させることができる。

なお、「投稿リンク制限なし」ではないユーザであっても投稿可能である「動画共有サイトＡ」と、「ＳＮＳ－Ｂ」などは、例えばファンコミュニティアプリにおいて応援対象となるタレントの配信動画が投稿されているウェブサイトなどであり、比較的安全性が高いリンク先などが定められている。

図２１を参照して、ユーザ投稿処理における、投稿リンク制限の判定処理の流れについて説明する。図２１は、図１８を参照して説明したユーザ投稿処理に、投稿リンク制限があるユーザであるか否かの判定（点線で囲っている処理）が加わった場合のフローチャートであるため、図１８と同一の処理については説明を省略する。

ステップＳ３０３において図１７（Ａ）の投稿画面が表示されると、ステップＳ３１６で、所定リンク以外のリンクが貼り付けられたか否かの判定がされる。所定リンク以外のリンクが貼り付けられたと判定されなければ、ステップＳ３０４に進み、次へが選択されたか否かが判定される。

一方、所定リンク以外のリンクが貼り付けられたと判定されれば、ステップＳ３１７に進み、所定リンク以外のリンク貼り付けが許可されているユーザであるか否かが判定される。例えば、ユーザ端末３００は、配信サーバ１００から取得して記憶部３２０に記憶したユーザ毎の「レベル」、「累積ポイント」に基づいて、レベルが８０以上であるか否かを判定する。

ステップＳ３１７において、所定リンク以外のリンク貼り付けが許可されているユーザであると判定されたときには、ステップＳ３０４に進み、次へが選択されたか否かが判定される。一方、ステップＳ３１７において、所定リンク以外のリンク貼り付けが許可されているユーザであると判定されなかったときには、ステップＳ３１８で、投稿が許可されていない旨を報知して、ステップＳ３１６に戻る。例えば、レベル１０のユーザであれば、所定リンク以外のリンク貼り付けが許可されていないため、図２０で例示するように、所定リンク以外のリンク貼り付けができない旨を報知する。

図１９に戻り、「通報カウント」とは、特定のコンテンツを、ユーザ全体に非表示にするか否かに影響を与えることができる権限である。本実施例においては、レベルが７０以上のユーザからの非表示や通報された人数が所定数蓄積したコンテンツを、ユーザ全体に非表示とすることができる。例えば、レベルが７０以上のユーザ５人から非表示あるいは通報がされたコンテンツは、全ユーザに非表示にすることができる。

また、「通報カウント」の対象となる、レベルが７０以上のユーザから非表示や通報された人数が所定数蓄積したユーザが投稿したコンテンツやコメントを、ユーザ全体に非表示とすることができる。例えば、レベルが７０以上のユーザ５人から非表示あるいは通報がされたユーザが投稿したコンテンツやコメントは、全ユーザに非表示にすることができる。

なお、非表示とするユーザには、コメントやコンテンツの投稿を行ったユーザ本人は含まれないものとしてもよい。これにより、自身の投稿したコンテンツやコメントがユーザ本人の端末において反映されるものの、例えば他のユーザからのアクションがないことで、規制対象となったことを察知する（気付かせる）ことができる。

「特典」には、付与される特典として、レベルに応じて異なる特典が関連付けられている。例えば、プレゼント企画などがあった際に、レベルの高さに応じて、よりレア度の高いアイテムなどのファンにとってより有益なアイテムが付与され得る。例えば、特典が、コメントの投稿などで使用できるスタンプや、タレントのライブで使用できるアイテム等であった場合、レベル５０～５９のユーザに付与される特典Ｅよりも、レベル６０～６９のユーザに付与される特典Ｄの方が、スタンプやアイテム等を購入した場合の金額が高く、レベルが上がるにつれて、付与される特典の相当金額が高くなる。

（評価値の変動例について）
次に、図２２を参照して、累積ポイント数（評価値）の変動例について説明する。図２２は、ユーザの「累積ポイント」を変動させる外的評価の例および、外的評価と変動数の関係の例を説明するための表である。コンテンツ（投稿された記事）やコメント等に対し、ユーザから（運営者含む）何らかのアクションがあった場合には、アカウント管理部１３３は、アクション情報１２３として記憶する外的評価であるか否かに応じて、ユーザの累積ポイントを変動・更新させる。累積ポイントが変動したことに応じてレベルが変動すれば、アカウント管理部１３３は行動権限情報１２４として記憶する行動権限をユーザに許可あるいは制限を行う処理をする。

外的評価は、ユーザ本人以外からの他のユーザからの評価である。例えば、ユーザが投稿したコンテンツやコメントに対して、「他のユーザからのいいね」があった場合には、１いいね（１タップアクション）につき、５ポイント増える。

あるいは、ユーザが投稿したコンテンツやコメントの内容などにより、運営者から見て信頼度が高いユーザであると好印象を抱いた場合などに、運営からの高評価により付与されるポイントがあってもよい。運営から付与されるポイントについては、予め定められたポイント数でもよく、適宜運営者による操作によって変更されてもよい。

また、応援対象の布教度に応じてポイントが付与されるようになってもよい。すなわち、応援対象に関するコンテンツ（動画やグッズなど）を宣伝する行為による、応援対象への利益貢献度に応じてポイントが付与される。例えば、宣伝行為には、応援対象であるタレントの配信動画のリンクを広める行為や、応援対象であるタレントのグッズを紹介する行為などが含まれる。例えば、ユーザが投稿したコンテンツにタレントあるいはタレントが所属するグループに関連する配信動画の動画リンクが貼られていた場合に、当該投稿コンテンツからの動画Ｖｉｅｗ数に応じてポイントが付与される。その他、タレントあるいはタレントが所属するグループに関するグッズページのリンクが貼られていた場合に、グッズページリンクのクリック数に応じてポイントが付与されるようにすることもできる。グッズページとは、例えば、ファンコミュニティの応援対象であるタレントのオフィシャルグッズページや、他社とのコラボ企画商品の販売ページなどであり、集計用にコミュニティ投稿用専用ＵＲＬが発行されていてもよい。あるいは、オフィシャルサイトのグッズページのコミュニティ投稿専用ＵＲＬを介して、商品の購入があった場合に、ＵＲＬを投稿したユーザにポイントが付与されるようにしてもよい。

一方、他のユーザからの通報や、非表示があるとポイントは減少する。例えば、図１１（Ｂ）に表示される画面への操作などにより、１通報があるごとに、５ポイント減るようにすることができる。あるいは、ユーザが投稿したコンテンツやコメントの内容などにより、運営者から見てコミュニティ内の雰囲気を悪化させる虞があるユーザであるとの懸念を抱いた場合などに、運営によりマイナス評価される（ポイントが減される）ことがあってもよい。運営から減されるポイントについては、予め定められたポイント数でもよく、適宜運営者による操作によって変更されてもよい。

また、外的評価の一例として、コンテンツに対してされたコメントのテキストの判定を行い、運営者などにより予め定められたポジティブワードが入っていた場合には、ポイントをアップさせ、運営者などにより予め定められたネガティブワードが入っていた場合には、ポイントを減少させるようにしてもよい。また、テキスト判定をＡＩによる自動判定により行ってもよい。例えば、ユーザ自身が投稿したコンテンツ自体、あるいは、ユーザが投稿したコンテンツに対してなされた他のユーザからのコメントについて、ポジティブワードあるいはネガティブワードの割合を自動判定した上で、いずれの要素が多いかによりポイントが付与、あるいはされないものであってもよい。ポジティブワード、ネガティブワードは、ユーザが定めたものではなく、外部要因による基準（例えば、運営側（ＡＩ判定含む）の基準）である。

（評価履歴状況更新処理の流れについて）
次に、図２３を参照して、ユーザの評価履歴状況更新処理の流れについて説明する。図２３は、図２２を参照して説明した外的評価に応じて変動するユーザの評価履歴状況を更新する処理のフローチャートを説明するための図である。評価履歴状況更新処理は、配信サーバ１００において、ファンコミュニティアプリ内で各ユーザが投稿したコンテンツやコメント等に対し何らかのアクション（例えば、タップアクション、コメント、通報、非表示などの外的評価の対象となるアクション）があったときなどにアカウント管理部１３３によって繰り返し実行される。なお、評価履歴状況とはアカウント情報として記憶される図７のユーザ情報データベースにおける「レベル」と「累積ポイント」を含む、ユーザがユーザ本人以外からの外的要因によって評価が行われた結果のことを示す。

ステップＳ４０１では、外的評価があったか否かが判定される。例えば、ユーザが投稿したコンテンツやコメントなどに対して、図２２で例示した外的評価があったか否かが判定される。外的評価があったと判定されなかったときには、処理を終了する。

一方、外的評価があったと判定されたときには、ステップＳ４０２で、外的評価は「ポイント数増」評価であったか否かが判定される。例えば、外的評価が、図２２で例示した、「他のユーザからのいいね」（他のユーザからのタップアクション）であれば、ポイント数が５増加するため、ステップＳ４０２においては、「ポイント数増」評価であったと判定される。

ステップＳ４０２で、外的評価が「ポイント数増」評価であったと判定されたときには、ステップＳ４０３で、外的評価に応じてユーザ毎にポイント数を加算して、評価履歴状況を更新して記憶する。例えば、レベル５９のユーザであって、累積ポイントに外的評価によって５加算されることによりレベル６０になるために必要なポイント数に達して、レベルが６０にあがったとする。その際、ユーザ情報データベースでは、レベルは６０、かつ、累積ポイント数は、５加算されたあとの数値に更新して記憶される。

次に、ステップＳ４０４では、ポイント数の変動によりレベルアップしたか否かが判定される。ステップＳ４０４で、ポイント数の変動によりレベルアップしたと判定されたときには、ステップＳ４０５でレベルアップ後のレベルに応じた特定アクションをユーザに許可して、アカウント情報１２５として記憶するユーザの許可アクション情報を更新して記憶する。例えば、レベルが６０になったことにより、図１９で例示するように、投稿リンクの制限がなくなったとする。そうすると、例えばアカウント情報１２５として記憶されるユーザ情報データベースにおいて、ユーザに投稿リンクの制限がない情報を関連付けて記憶する。なお、レベルアップしたとしても新たに許可されたアクションがない場合があり、その際には許可アクション情報は特に更新せずに処理を終了する。

ステップＳ４０５で、許可アクション情報が更新・記憶されたあとは、ステップＳ４０６で、ユーザに特定アクションが許可された旨を報知するための情報を送信して処理を終了する。例えば、ユーザ端末３００において「レベルアップにより、投稿リンクの制限がなくなりました」とのメッセージのプッシュ通知や、アプリ内でのお知らせ、あるいは、次回投稿時にポップアップ表示などをさせる。

ステップＳ４０２に戻り、外的評価が「ポイント数増」であったと判定されなかったときには、ステップＳ４０７に進み、外的評価は「ポイント数減」評価であるか否かの判定がされる。例えば、外的評価が、図２２で例示した「他のユーザからの通報」であれば、ポイント数が５減るため、ステップＳ４０７においては、「ポイント数減」評価であったと判定される。

ステップＳ４０７で、外的評価が「ポイント数減」評価であったと判定されたときには、ステップＳ４０８で、外的評価に応じてユーザ毎にポイント数を減じて評価履歴状況を更新して記憶する。例えば、レベル６０のユーザであったが、累積ポイントが外的評価によって５減じられることにより、累積ポイントがレベル６０であるために必要なポイント数を満たさなくなり、レベル５９にレベルが下がったとする。その際、ユーザ情報データベースでは、レベルは５９、かつ、累積ポイントは、５減算されたあとの数値に更新して記憶される。

次に、ステップＳ４０９では、ポイント数の変動によりレベルダウンしたか否かが判定される。ステップＳ４０９で、レベルダウンしたと判定されたときには、ステップＳ４１０で、レベルダウン後のレベルに応じて、レベルダウン前に許可されていた特定アクションを制限して、許可アクション情報を更新して記憶する。例えば、レベルが５９になったことにより、図１９で例示するように、投稿リンクの制限がかかるようになったとする。そうすると、例えばアカウント情報１２５として記憶されるユーザ情報データベースにおいて、ユーザに投稿リンクの制限がある情報を関連付けて記憶する。なお、レベルダウンしたとしても制限されるアクションがない場合があり、その際には許可アクション情報は特に更新せずに処理を終了する。

ステップＳ４１０で、許可アクション情報が更新・記憶されたあとは、ステップＳ４１１で、ユーザに特定アクションが制限された旨を報知するための情報を送信して処理を終了する。例えば、ユーザ端末３００において、「レベルダウンにより、投稿リンクに制限がかかりました」とのメッセージのプッシュ通知や、アプリ内でのお知らせ、あるいは、次回投稿時にポップアップ表示などをさせる。

ステップＳ４０７に戻り、外的評価は「ポイント数減」評価であると判定されなかったときには処理を終了する。例えば、ポイント数の変動に影響を与えるものとして定められていないアクションがあったときである。なお、評価履歴状況更新処理が配信サーバ１００で実行される例について説明したが、ユーザ端末３００で実行されたのちに、配信サーバ１００に情報が送信されるものであってもよい。

＜タップアクションによる演出表示について＞
（タップアクション演出処理の表示画面例）
次に、図２４、図２５、図２６を参照して、コンテンツや、コメント等に対して、ユーザによりタップアクションを受け付けた際の演出表示について説明する。本実施例においては、図１０、図１１、図１３を参照して説明したコンテンツ、あるいはコンテンツの見出しに表示されるタップアクション数７８（７８ｂ）に表示される、アイコン７０８に対する操作（例えばユーザ端末３００からのクリック操作、あるいは、タップ操作など）がされることで、タップアクションの数が加算されていく。さらに、タップアクションの数が加算される際に、ユーザ端末３００において、演出表示を行うことができる。例えば、アイコン７０８に対する操作がされる度に、所定のマークがアイコン７０８から飛び出してくる演出がなされる。

図２４は、ユーザからのタップアクションを受け付けた際の演出表示（受付演出）の一例である。図２４（Ａ）は、図１１（Ａ）などで例示したコミュニティ毎のチャンネル別の画面の例であり、上位に表示されているコンテンツ見出し７０に表示されるタップアクション数７８のアイコン７０８に対する操作がされた際の一例である。この場合、タップ操作回数が５０回に到達したため、個別タップアクション数４８には、「５０」が表示されている。そのため、ユーザは自身がタップアクションを行った回数を認識することができる。

図２４（Ａ）においては、３回連続タップ（連打）されたときを例示しており、１度目のタップ（４８回目のタップ）で、サムズアップマーク４１ａが、タップアクション数７８のアイコン７０８から飛び出してくるような演出がされる。次いで、２度目のタップ（４９回目のタップ）で、サムズアップマーク４１ｂがアイコン７０８から飛び出してくるような演出がされる。また、３度目のタップ（５０回目のタップ）で、ファンマーク４２が、アイコン７０８から飛び出してくるような演出がされる。ファンマーク４２は、アイコン７０８の操作がされたコンテンツに関連付けられた関連タレントのファンマークである。このように、連続タップにより、前のタップで飛び出たマークの演出時間（飛び出してから消えるまで）と、次のタップで飛び出たマークの演出時間が重複していた場合には、複数のマークが表示されている状態となる。このように、連続タップにより、マークが続々と飛び出す演出がされるため、ユーザはタップアクションの押し心地（操作性）に爽快感を得ることができ、さらなるタップアクションを促すことができる。なお、マークが飛び出る演出は、図２４（Ａ）で例示したように複数のマークが同時に表示されず、表示されるマークが１つずつとなるようにされていてもよい。

図２４（Ｂ）は、ユーザからのタップアクションが所定回数に達した場合に、表示される特別な演出（特別受付演出）である。例えば、アイコン７０８に対する操作が１００に達したときに、画面全体に様々なマークが降り注ぐ演出がされる。なお、所定回数とは、各アクション対象に対するユーザがタップアクションを行うことができる上限値であってもよい。すなわち、所定回数に達すると、アイコン７０８に対する操作により演出や、個別タップアクション数４８の更新が行われない。あるいは、所定の回数に到達する度（例えば、１０回毎）に行われるものであってもよい。また、上限値を設けなくともよい。

なお、所定回数とは、ユーザがコンテンツに対して行った個々のタップアクションの数である個別タップアクション数４８に限らず、これに替えて、あるいは加えて、ファンコミュニティにおけるユーザ全体のタップアクションの数であるタップアクション数７８に表示される数が、所定値（例えば１００回）となるごとに、当該１００回目のアクションを行ったユーザに対して演出が行われるようにしてもよい。

次に、図２５を参照して、タップアクションを受け付けることにより実行される演出の種類の例について説明する。図２５は、配信サーバ１００に記憶されるコンテンツデータ１２２、あるいは、配信サーバ１００から取得したコンテンツデータ１２２に基づいてユーザ端末３００の記憶部３２０において記憶されるタップアクションによる演出表示のコンテンツ別演出データテーブル例である。演出表示に関する情報は、コンテンツ（投稿された記事）毎に関連付けられている。

コンテンツ別演出データテーブルでは、記事ＩＤごとに、演出種別が定められている。また、演出種別ごとに演出に用いられる抽選確率が関連付けられている。演出種別は、タップアクションがされた回数が所定回数未満であるかと、所定回数到達時であるかに応じた演出が定められている。所定回数が、タップアクションが可能な上限値１００であったとすると、１～９９が所定回数未満となる。

所定回数未満の演出には、デフォルトの演出と、コンテンツに関連タレントが設定されていた場合には、ファンマークの演出が定められている。デフォルトの演出には、例えば、拍手、サムズアップ、ハート、レアマークなどのマークが定められている。ファンマークには、関連タレントに対応したマークが関連付けられる。例えば、記事ＩＤ「ａ１」には、図１４で例示するように、関連タレントには、タレントＩＤ「ｔ１」、「ｔ２」、「ｔ６」、「ｔ１４」が関連付けられている。そのため、関連タレント各々に対応するファンマークである「ｍａｒｋ＿ｔ１」、「ｍａｒｋ＿ｔ２」、「ｍａｒｋ＿ｔ６」、「ｍａｒｋ＿ｔ１４」が関連付けられる。各マークが演出に用いられる抽選確率については、一律に同一確率が定められてもよく、ファンマーク、あるいはレアマークについては、出現確率が小さく定められるようにしてもよい。このように、コンテンツに関連タレントが関連付けられていた場合には、タップアクションを行うことによりファンマークが出現する。これにより、ユーザがタップアクションを行うことを促すことができ、さらには、ユーザがコンテンツを投稿する際に、関連タレントを選択してから投稿をするよう促すことができる。その結果、他のユーザが推しタレントの情報を得ることを容易にすることができ、ユーザ行動によってファンコミュニティを活性化させることができる。

所定数到達時の演出には、豪華演出と、コンテンツに関連タレントが設定されていた場合には、タレント演出が定められている。タレント演出は、所定数未満のときのファンマークと同様に、記事ＩＤ「ａ１」に関連付けられている関連タレント各々に対応した演出である「ｓｐｅｃｉａｌ＿ｔ１」、「ｓｐｅｃｉａｌ＿ｔ２」、「ｓｐｅｃｉａｌ＿ｔ６」、「ｓｐｅｃｉａｌ＿ｔ１４」が定められている。例えば、ファンマークが飛び出すなど、タレントを想起させるアニメーションの表示などがされる。

また、コンテンツに関連タレントが設定されていなかったときには、図２５の記事ＩＤ「ａ９９」で例示するように、演出種別にファンマーク、および、タレント演出が定められておらず、所定数未満においてはデフォルトの演出が行われ、所定数到達時においては豪華演出が行われる。

なお、演出の各々について、例えば豪華演出にも複数の演出パターンが定められていてもよく、所定数未満におけるデフォルトの演出が１つであってもよい。また、所定数未満時のファンマークの演出、あるいは、所定数到達時のタレント演出は、いずれか一方のみ定められるものであってもよい。例えば、コンテンツに関連タレントが選択されていたとしても、所定数到達時の演出は、豪華演出のみとしてもよい。

（タップアクション演出処理の流れの例）
図２６を参照して、タップアクション演出処理の流れの例について説明する。図２６は、図２４、図２５などを参照して説明したタップアクション演出処理のフローチャートを説明するための図である。タップアクション演出処理は、配信サーバ１００により取得したコンテンツ情報に基づいて、ユーザ端末３００の制御部３５０により、ユーザからの操作に応じて繰り返し実行される。

ステップＳ５０１では、タップアクション操作があったか否かの判定がされる。例えば、図１０のホーム画面、図１１（Ａ）のコミュニティ画面、図１３のコンテンツ画面において、コンテンツやコメントに表示されるアイコン７０８に対するユーザからのタップ操作がされることである。ステップＳ５０１において、タップアクション操作があったと判定されなかったときには、処理を終了する。

一方、ステップＳ５０１において、タップアクション操作があったと判定されたときには、ステップＳ５０２で、当該コンテンツ等に対する当該ユーザによるタップアクション合計数は、所定数未満であるか否かの判定がされる。例えば、所定数が、ユーザが各アクション対象に対してタップアクション操作を行える上限値の１００であったとする。その場合、記憶部３２０において記憶（あるいは、配信サーバ１００のアクション情報１２３として記憶）されているタップアクション合計数が１００であると、ステップＳ５０２において、タップアクション合計数は所定数未満であると判定されず、処理を終了する。

ステップＳ５０１において、例えばタップアクション合計数が５０であった場合には、アクション合計数は所定数未満であると判定され、ステップＳ５０３で、記憶部３２０に記憶されるタップアクションカウンタ（タップアクション合計数を特定するためのカウンタ）を１加算する。ステップＳ５０３で、タップアクションカウンタが加算されると、ステップＳ５０４で、加算後のタップアクション合計数が所定数であるか否かの判定がされる。例えば、タップアクション合計数が５０であれば、ステップＳ５０３で１加算されることで、タップアクション合計数が５１となり、ステップＳ５０４では、所定数の１００であると判定されない。

ステップＳ５０４で、タップアクション合計数が所定数であると判定されなかったときには、ステップＳ５０５で、タップアクション操作があったコンテンツに、関連タレントが関連付けられているか否かの判定がされる。例えば、タップアクション操作があったコンテンツが図１４の記事「ａ１」であったとすると、関連タレントありと判定される。

ステップＳ５０５で、関連タレントありと判定されたときには、ステップＳ５０６で、図２５のコンテンツ別演出テーブルに基づいて、所定数未満のタップアクションを抽選して決定する。ステップＳ５０６で、演出が決定されたあとは、ステップＳ５０７で決定されたタップアクションの演出を実行し、タップアクション数更新情報を配信サーバ１００に送信して処理を終了する。例えば、抽選により、図２５の記事ＩＤ「ａ１」の演出種別ファンマークの「ｍａｒｋ＿ｔ１」が決定されたときには、タップアクション数７８、および、個別タップアクション数４８の数を更新するとともに、「ｍａｒｋ＿ｔ１」に対応するファンマークが飛び出す演出が実行される。

ステップＳ５０５に戻り、タップアクション操作があったコンテンツに、関連タレントが関連付けられていると判定されなかったときには、ステップＳ５０８に進み、デフォルトの所定数未満のタップアクションを抽選して決定する。ステップＳ５０９では、ステップＳ５０８において決定されたデフォルトのタップアクションの演出を実行し、タップアクション数更新情報を配信サーバ１００に送信して処理を終了する。例えば、図２５の記事ＩＤ「ａ９９」であれば、関連タレントが関連付いていないコンテンツであるため、デフォルトの中から演出の抽選が行われる。例えば抽選により「サムズアップ」が決定されれば、タップアクション数７８、および、個別タップアクション数４８の数を更新するとともに、「サムズアップ」に対応するマークが飛び出す演出が実行される。

ステップＳ５０４に戻り、タップアクション合計数が所定数であると判定されたときには、ステップＳ５１０に進む。例えば、ステップＳ５０３でタップアクションカウンタが加算されたことにより、個別タップアクションの数が１００になったときである。

ステップＳ５１０では、タップアクション操作があったコンテンツには関連タレントが関連付けられているか否かの判定がされる。例えば、タップアクション操作があったコンテンツが図１４の記事「ａ１」であったとすると、関連タレントありと判定される。

ステップＳ５１０で、関連タレントありと判定されたときには、ステップＳ５１１で、所定数到達時用のタップアクション演出を抽選して決定する。ステップＳ５１２では、ステップＳ５１１で決定された所定数到達時用のタップアクション演出を実行し、タップアクション数更新情報を配信サーバ１００に送信して処理を終了する。例えば、抽選により、図２５の記事ＩＤ「ａ１」の演出種別タレント演出の「ｓｐｅｃｉａｌ＿ｔ１」が決定されたときには、タップアクション数７８、および、個別タップアクション数４８の数を更新するとともに、「ｓｐｅｃｉａｌ＿ｔ１」に対応する演出が実行される。

ステップＳ５０８に戻り、タップアクション操作があったコンテンツに、関連タレントが関連付けられていると判定されなかったときには、ステップＳ５１３で、所定数到達時用のタップアクションの演出を実行し、タップアクション数更新情報を配信サーバ１００に送信して処理を終了する。例えば、図２５の記事ＩＤ「ａ９９」であれば、関連タレントが関連付いていないコンテンツであるため、タップアクション数７８、および、個別タップアクション数４８の数を更新するとともに、「豪華演出」に対応する演出が実行される。

なお、ステップＳ５０７、ステップＳ５０９、ステップＳ５１２、および、ステップＳ５１３において、タップアクション更新情報（例えば、タップアクションが実行されたことを特定する情報）が配信サーバ１００に送信されることにより、コンテンツデータ１２２として記憶されているコンテンツあるいはコメント毎のタップアクション数の集計が更新され、他のユーザのユーザ端末３００のタップアクション数７８（７８ｂ）に反映される。なお、タップアクション演出処理がユーザ端末３００で実行される例について説明したが、配信サーバ１００で実行され、ユーザ端末３００に表示情報が送信されるものであってもよい。

なお、コンテンツに関連タレントが関連付いていた場合には、関連付いている各タレントに対応するファンマーク、あるいは、タレント演出が抽選によって実行される例について説明したが、関連タレントにユーザが予め選択した推しタレントが関連付いていた場合に、推しタレントに対応するファンマークの抽選確率（当選確率）を他のファンマークよりも高めてもよい。

＜外部サービスにより提供されるＡＰＩの利用＞
次に、図２７を参照して、外部ウェブサービスシステム４００により提供されるＡＰＩを利用して、当該外部ウェブサービスシステム４００により提供されるコンテンツをユーザに利用可能とする例について説明する。外部ウェブサービスシステム４００は、例えば、動画配信サイトである。本実施例におけるファンコミュニティの応援対象となるタレントが、当該動画配信サイトにおいて動画配信を行っているものとする。本実施例においては、タレントが動画配信サイトにおいて動画配信をする配信スケジュールをユーザが容易に確認することができるようにする。

本実施例においては、外部ウェブサービスシステム４００により提供されるＡＰＩを利用することにより、動画の配信者および、配信者との共同配信（コラボともいう）相手の情報を取得し、対応するタレントのタレントＩＤが関連付けられた情報を生成してユーザ端末３００に表示可能とする。ユーザに表示する情報には、タレントＩＤが関連付けられていることにより、ユーザが予め選択した参加コミュニティ（第１属性）および推しタレント（第２属性）の配信を抽出してユーザが特定できるようにすることができる。

図２７（Ａ）および（Ｂ）は、ユーザ端末３００において表示される配信スケジュール画面の例である。例えば、アプリ画面下部に、配信スケジュールアイコン１８を表示させ、配信スケジュールアイコン１８に対する選択操作があったことにより表示されるものであってもよい。あるいは、図１２で例示したチャンネル一覧画面において選択できるようになっていてもよく、コミュニティ毎のチャンネル一覧表示８２の中に表示されていてもよい。

図２７（Ｃ）は、外部ウェブサービス４００により提供される動画コンテンツの画面例であり、図２７（Ａ）あるいは図２７（Ｂ）の画面から所定の操作を行うことにより、当該動画コンテンツ画面に遷移することができる。

図２７（Ａ）および図２７（Ｂ）の配信スケジュール画面では、推しフィルター２０、配信期間選択エリア９１、グループ選択エリア９２、配信日時９３、コンテンツ見出し９０、チャンネルアカウント９８、出演関連タレント９４などが表示されている。ユーザは、例えば、コンテンツ見出し９０に対する選択操作を行うことにより、図２７（Ｃ）の外部ウェブサービスにおける配信ページへ遷移する。遷移先は、チャンネルアカウント９８に表示されているアカウントの動画配信チャンネルである。出演関連タレント９４には、対応する配信に出演するタレントのアイコンが表示されている。例えば、図２７（Ａ）のコンテンツ見出し９０ａには、グループＡの公式チャンネルのアカウントによる配信があることが表示されており、コンテンツ見出し９０ｂには、タレントＢＢＢのチャンネルによる配信があることが表示されている。

配信期間選択エリア９１には、例えば、直近の過去の配信（コンテンツ）を特定するコンテンツ見出し９０（コンテンツ情報）の一覧を表示させる「直近の配信」、現在配信されている配信（コンテンツ）を特定するコンテンツ見出し９０の一覧を表示させる「現在配信中」、今後の予定されている配信（コンテンツ）を特定する「今後の予定」のアイコンが表示されており、各アイコンに対するユーザからの選択操作により、表示されるコンテンツ見出し９０の一覧を切り替えることができる。図２７（Ａ）は、「現在配信中」のアイコンが選択されている場合の配信スケジュール画面の例であり、現在配信されている配信を特定するためのコンテンツ見出し９０の一覧が表示されている。図２７（Ｂ）は、「今後の予定」のアイコンが選択されている場合の配信スケジュール画面の例であり、今後の予定されている配信を特定するためのコンテンツ見出し９０の一覧が表示されている。

グループ選択エリア９２には、図５で例示したタレントが所属する所属グループ１を選択するためのアイコンが表示されている。グループ選択エリア９２に表示されるグループは、ユーザが参加しているコミュニティに対応するグループのみが表示されている。例えば、図２７（Ａ）および図２７（Ｂ）は、図７におけるユーザ「ｕ２」のユーザ端末３００に表示される画面であり、図２７（Ａ）および図２７（Ｂ）においては、ユーザ「ｕ２」が参加するコミュニティＡおよび、コミュニティＢに対応する「グループＡ」および、「グループＢ」のアイコンが表示されている。各アイコンに対する操作がされることにより、いずれか（あるいは、いずれも選択できてもよい）のグループに所属するタレントに関する配信のコンテンツ見出し９０が表示されるようにする。図２７（Ａ）および図２７（Ｂ）においては、「グループＡ」のアイコンが選択されているため、グループＡに所属するタレントが出演する配信を特定するためのコンテンツ見出し９０が抽出して表示されている。グループＡに所属するタレントが出演する配信であるか否かは、コンテンツ見出し９０に出演関連タレント９４（図５のタレントＩＤ）が配信サーバ１００で関連付けられたことにより、ユーザは特定可能となる。なお、グループ選択エリア９２に表示されるグループは、ユーザが参加しているコミュニティに対応するグループのみが表示されている例を示しているが、これに限らず、参加しているコミュニティにかかわらず、すべてのグループが表示されるようになっていてもよい。

また、図９を参照して上述したように、配信スケジュール画面においても推しフィルター２０への選択操作がされることにより、ユーザが予め選択した推しタレントが出演する配信を抽出して表示させることができる。

図２７（Ａ）および図２７（Ｂ）の出演関連タレント９４に表示されるタレントは、動画配信サイトのＡＰＩを利用して取得した情報に基づいて表示される。例えば、図２７（Ｃ）の配信画面（配信中、配信後、配信前の投稿を含む）には、概要欄９５が設けられており、配信の投稿者が適宜概要欄９５のテキストを編集できる。概要欄９５に、属性特定情報９６を埋め込んでおくことにより、配信サーバ１００は、属性特定情報９６を取得してコンテンツ見出し９０を生成する。属性特定情報９６とは、例えば、動画配信サイトにおけるチャンネルアカウントである。図２７（Ｃ）は、タレント「ＣＣＣ」に対応するチャンネルアカウントによる配信であるため、配信サーバ１００は、チャンネルアカウントである属性特定情報９６ａを取得することができる。出演関連タレント９４には、タレントのアイコンに加え、タレントの名前も表示されていてもよい。また、出演関連タレント９４は、図１３などを参照して説明した関連タレント８８として表示されていてもよい。

また、概要欄９５には、タレント「ＡＡＡ」に対応するチャンネルアカウントを特定する情報（識別子）である属性特定情報９６ｂ（ハンドルとも称する）が入力されている。当該ハンドルは、対応するチャンネルアカウントに誘導するＵＲＬでもある。例えば、配信を行うチャンネルアカウントに対応するタレントと異なるタレントとの共同配信がされる際に、共同配信相手を特定するハンドルが入力される。当該入力行為は、他のチャンネルの前に＠マークを付けて文字情報を入力することで、他のチャンネルをメンションするともいう。例えば、タレント「ＣＣＣ」のチャンネルによる配信が、タレント「ＡＡＡ」との所謂コラボ配信であったときに、当該配信の概要欄９５に、タレント「ＡＡＡ」のチャンネルアカウントを特定するためのハンドルが埋め込まれている。概要欄９５に、属性特定情報９６ｂであるハンドルが入力されていることにより、サーバ１００は、配信するアカウント自体以外に、コラボ相手の情報である属性特定情報９６ｂを取得することができる。

以上により、配信サーバ１００は、属性特定情報９６を取得することにより、配信をするチャンネルアカウント（属性特定情報９６ａ）に対応したタレントのタレントＩＤと、ハンドル（属性特定情報９６ｂ）に入力されていた共同配信相手に対応したタレントのタレントＩＤとが関連付けられたコンテンツ見出し９０を生成する。例えば、外部ウェブサービス４００から取得した情報に、タレント「ＣＣＣ」および「ＡＡＡ」に対応する属性特定情報９６が含まれているとする。その場合、コンテンツデータ１２２として記憶される配信スケジュール画面に表示し得るコンテンツ見出し９０を管理するデータベースにおいて、タレント「ＣＣＣ」および「ＡＡＡ」のタレントＩＤ「ｔ３」、「ｔ１」が関連付いたコンテンツ見出し９０を特定するための情報が、コンテンツ管理部１３２により生成されて記憶されることで、コンテンツ見出し９０が生成される。また、配信サーバ１００は、図２７（Ｃ）の配信画面のタイトル９７のテキスト情報（例えば、「ＡＡＡとなかよし配信」）や、サムネイル画像情報９９を取得して、コンテンツ見出し９０にテキスト情報やサムネイル画像が表示されるようにする。これにより、図５に例示した属性情報１２１として記憶されているタレント情報データベースのいずれのタレントが出演する配信であるかを特定することができるため、ユーザが予め選択した属性が関連付けられている配信をユーザに特定させることができる。

例えば、以下においては図２７（Ｂ）が、図７におけるユーザ「ｕ１」の画面であるものとして説明する。なお、図２７（Ｂ）がユーザ「ｕ１」の画面であるものとした場合、ユーザ「ｕ１」はコミュニティＢには参加していないが、図２７（Ｂ）のように、グループ選択エリア９２にコミュニティＢのアイコンが表示され、選択によりグループＢの配信スケジュール画面を表示可能となっていてもよいし、参加しているコミュニティのアイコンのみが表示（コミュニティＢのアイコンは非表示）されるようにしてもよい。ユーザ「ｕ１」が推しタレントに選択しているタレントは、タレントＩＤ「ｔ１」、「ｔ２」、「ｔ５」に対応するタレント「ＡＡＡ」、「ＢＢＢ」、「ＥＥＥ」であるが、タレント「ＣＣＣ」は推しタレントに選択していない。しかし、推しタレントではない「ＣＣＣ」のチャンネルアカウントによる配信で、推しタレントとの共同配信があった場合であっても、属性特定情報９６ｂにより共同配信相手の情報も取得可能である。そのため、推しフィルター２０がオンの状態であっても、タレント「ＣＣＣ」の配信を特定するためのコンテンツ見出し９０が表示され、かつ、出演タレント９４が表示されるため、ユーザは推しタレントの情報を見落とすことがなくなる。

また、例えば配信途中で急遽共同配信をすることになり、外部ウェブサービス４００における配信画面の概要欄９５に新たな属性特定情報９６ｂ（ハンドル）が追加される編集があったとしても、随時抽出される。そのため、急遽共同配信が始まったとしても、図２７（Ａ）の現在配信中の配信スケジュールに、当該配信のコンテンツ見出し９０が表示される。また、当該コンテンツ見出し９０に、ユーザが予め選択した推しタレントが関連付いていれば、プッシュ通知を送ることができるため、ユーザは推しタレントの急な配信を見落とすことがなくなる。

なお、図２７の配信スケジュールに表示されるコンテンツ見出し９０は、外部ウェブサービス４００のＡＰＩを利用して自動生成される例について説明したが、これに限らず、例えば、管理者端末２００から手動で設定されるものであってもよい。例えば、コンテンツ見出し９０に遷移先のリンクと、関連タレントを関連付けるようにして、コンテンツ見出し９０を生成してもよい。ＡＰＩを利用できない場合であっても、タレントに関連したファンコミュニティアプリ外のリンク先に、ユーザを誘導することが可能となる。

また、外部ウェブサービスにおけるチャンネルアカウントが図５の所属グループ１に対応するグループの公式チャンネルであった場合に生成されるコンテンツ見出し９０には、タレントがいずれも関連付いていない（関連タレントが関連付いていない）ものであってもよい。この場合であっても、コンテンツ見出し９０には、タレント個々は関連付かないが、チャンネルアカウントに対応するグループの参加コミュニティおよびグループは関連付けられている。そのため、グループに対応するコミュニティに参加していれば、配信スケジュール画面に当該コンテンツ見出し９０は表示され、また、グループ選択エリア９２のグループ毎のアイコン操作により、グループ毎に抽出されるコンテンツ見出し９０として表示される。

＜具体的構成および効果の例＞
（１－１） 上述した実施の形態では、図１～図１８などを参照して説明したとおり、通信システム１が備える配信サーバ１００は、記憶しているプログラムや当該プログラムによりコンピュータを制御する方法（以下、単にプログラムという）に基づいて、属性（例えば、コミュニティやグループ、ユニット、タレントなど）が関連付けられた複数種類のコンテンツをユーザに提供可能とする。また、当該属性には、図６（Ａ）の参加コミュニティ一覧５０に表示されるコミュニティなどの複数種類のグループＡ、グループＢなどに対応したコミュニティ（第１属性）と、図５のタレント情報データベースに記憶される複数種類のタレント（タレントＩＤ，タレント名）やユニット（所属グループ２）など（第２属性）を含む。また、図６、図７、図９などを参照して説明したように、複数種類のグループに対応したコミュニティと、複数種類のタレントなどのうちから、ユーザからの操作に応じて予め選択された参加コミュニティおよび推しタレントを特定可能にするためにアカウント情報１２５として記憶されるユーザ情報データベース、あるいは、ユーザ端末３００の記憶部３２０において記憶する。

さらに、配信サーバ１００あるいはユーザ端末３００は、図１０、図１１、図１４～図１６、図２７などを参照して説明したように、推しフィルター２０への操作に応じて、ユーザにより予め選択されて記憶されている参加コミュニティが関連付けられたコンテンツ（例えば、図１４のコミュニティＡのコンテンツデータベースに記憶されるコンテンツなど）のうち、図１５（Ｂ）に例示するような推しフィルター２０がオフの状態でのコンテンツ見出し（６０，７０，９０）を、ユーザが特定可能となるようにユーザ端末３００の表示部に表示させる第１表示状態と、ユーザにより予め選択されて記憶されている参加コミュニティおよび推しタレントのいずれもが関連付けられたコンテンツに関するコンテンツ見出し（６０，７０，９０）を当該ユーザが特定可能となるように抽出して表示させる図１５（Ａ）などの推しフィルター２０がオンの状態の第２表示状態とを含む複数種類の表示状態のいずれかに切り替えて表示する。これにより、ユーザにより予め選択された（参加）コミュニティにおいて投稿されたコンテンツであって推しタレントが関連付けられているかにかかわらず表示されるコンテンツ見出しと、ユーザにより予め選択された（参加）コミュニティに投稿され、かつ推しタレントが関連付けられたコンテンツに関するコンテンツ見出しとを切り替えて表示可能となる。これにより、ユーザは好みの情報を容易に特定可能となる。例えば、コミュニティＡに参加しており、タレントＩＤが「ｔ１」のタレント「ＡＡＡ」を推しタレントに選択しているユーザであれば、図１４のコミュニティＡのコンテンツデータベースに記憶されるコンテンツのうち、タレントＩＤに「ｔ１」が関連付けられているコンテンツのコンテンツ見出しが抽出されて、図１０のホーム画面や、図１１（Ａ）のコミュニティ画面、図２７の配信スケジュール画面などに表示される。なお、推しフィルター２０は、図７に例示するユーザ情報データベースに記憶される複数のユーザ各々の評価履歴状況であるいずれのレベルであるかにかかわらずオンオフ操作をすることが可能である。

（１－２） また、推しフィルター２０のオンオフ操作は、ユーザが参加コミュニティや推しタレントを予め選択するときの一連の操作とは異なる操作であって、ユーザからのユーザ端末３００に表示される推しフィルター２０のアイコンへの操作に応じて成立する。これにより、図１０のホーム画面や、図１１（Ａ）のコミュニティ画面、図２７の配信スケジュール画面などを表示する際に改めてユーザが参加コミュニティや推しタレントを選択する操作や、選択するための画面に遷移させる操作などを要することなく、予め選択しておいたコミュニティ、あるいはコミュニティおよびタレントのいずれもが関連付けられたコンテンツに関するコンテンツ見出しが表示されるように切り替えて表示させることができるため、操作性・ユーザの利便性を向上させることができる。

（１－３） 図１５などに例示するように、推しフィルター２０は、推しフィルター２０がオンの表示状態であっても、オフの表示状態であっても、いずれにおいても常時表示されている。これにより、推しタレントが関連付けられたコンテンツを抽出した表示画面への切り替えを簡易化・容易化できる。

（１－４） ユーザに提供可能な複数種類のコンテンツには、図５の所属グループ１のグループＡ、グループＢなどに対応したコミュニティおよび、タレント（あるいは、所属グループ２のユニットなど）とは異なる属性（第３属性）である、ユーザの選択にかかわらず常に参加状態となっているコミュニティＰや、ユーザが参加しているコミュニティにかかわらず全ユーザに表示される図１０のフィーチャー６１などが関連付けられているコンテンツが含まれる。コミュニティＰに投稿されたコンテンツのコンテンツ見出し６０や、フィーチャー６１のコンテンツ見出し６０は、推しフィルター２０がオンあるいはオフのいずれの状態においても、ユーザが予め選択している参加コミュニティあるいは推しタレントにかかわらず、図１０のホーム画面に表示される。また、コミュニティＰは、図１２のチャンネル一覧画面に表示されるため、ユーザがコミュニティＰのコミュニティバー８１ｃを選択操作すれば、コミュニティＰのコミュニティ画面（図１１（Ａ））が表示可能となる。これにより、ユーザが予め選択しておいた属性とは異なる属性に関するコンテンツ見出しも表示され得るようにすることで、切り替えの状態にかかわらず例えば運営者が全ユーザに知らせたい情報をユーザに報知することが可能となる。

（１－５） ユーザに提供可能な複数種類のコンテンツには、関連タレントが関連付けられておらず、参加コミュニティのみが関連付けられているコンテンツ（例えば、図１４、図２５の記事ＩＤａ９９など）が含まれ、推しフィルター２０がオンの表示状態のときには、参加コミュニティのみが関連付けられ関連タレントが関連付けられていないコンテンツのコンテンツ見出しは表示されない。これにより、推しフィルター２０がオンの状態においては、推しタレントが関連付けられていないコンテンツのコンテンツ見出しは表示されないため、ユーザは好みのコミュニティと、タレントとが関連付けられた情報を特定することが容易となる。

（１－６） 図５、図６などを参照して説明したように、ユーザが予め選択できる推しタレントは、図５の所属グループ１の複数のグループＡ、グループＢなどのいずれかに所属する（区分けされている）複数人のタレントである。これにより、タレントを区分けするグループに関する情報の中から、さらにユーザ好みのタレントの情報に絞った情報を特定することが可能となる。

（１－７） また、図５、図６などを参照して説明したように、ユーザが予め選択できる推しタレントは、所属グループ１よりも小さい単位である所属グループ２毎に選択することができる。すなわち、複数のタレントで構成されたユニット単位で選択することができる。これにより、タレントを区分けするグループに関する情報の中から、さらにユーザ好みの複数のキャラクタからなるユニットの情報に絞った情報を特定することが可能となる。

（１－８） 図１０のホーム画面例などを参照して説明したように、ユーザに提供可能な複数種類のコンテンツは、推しトピック６２を含む複数種類のカテゴリのいずれかに分類可能であり、図１０に例示するように、複数種類のカテゴリ毎に分類してユーザ端末３００に表示可能である。また、推しトピック６２においては、推しフィルター２０がオンの状態あるいは、オフの状態のいずれであっても、ユーザにより予め選択されて記憶されている参加コミュニティおよび推しタレントのいずれもが関連付けられたコンテンツのうちの所定数のコンテンツに関するコンテンツ見出し６０を当該ユーザが特定可能となるように表示する。また、推しトピック６２以外の人気のユーザ投稿６３、記念配信６４、グッズ６５などのカテゴリにおいては、図１６を参照して説明したように、推しフィルター２０のオンあるいはオフのいずれの状態であるかに応じたコンテンツ見出し６０を当該ユーザが特定可能となるように表示する。推しトピック６２が表示されることにより、ユーザが予め選択している参加コミュニティおよび推しタレントが関連付けられたコンテンツのうちの一部が、表示状態の切替操作をせずとも表示可能となるため、切替操作の手間なく、ユーザは好みのコミュニティおよびタレントが関連付けられたコンテンツを特定可能となる。

（１－９） また、図１０に例示するホーム画面における推しトピック６２のコンテンツ見出し６０は、推しフィルター２０がオンあるいはオフのいずれの状態においても、他のカテゴリに分類されるコンテンツに関するコンテンツ見出し６０よりも上部に表示されるなど優先して表示させることができる。これにより、ユーザは好みのコミュニティおよびタレントが関連付けられたコンテンツの特定が容易となる。

（１－１０） 図１２を参照して説明したように、ユーザが予め選択した参加コミュニティのうち、図１２のチャンネル一覧画面においてコミュニティバー８１をユーザが選択操作することにより、図１１（Ａ）に例示するコミュニティ毎のコンテンツ画面を表示可能となる。これにより、ユーザが予め選択した参加コミュニティの中から、さらに好みのコミュニティを選択して、当該選択したコミュニティ毎のコンテンツ見出し７０を表示させることができるため、ユーザは好みの情報の中からであっても必要に応じて、さらに任意の情報を抽出可能となり、利便性が向上する。

（１－１１） 図２４～図２６を参照して説明したように、配信サーバ１００およびユーザ端末３００は、コンテンツのアイコン７０８に対するユーザからのタップアクションを受け付ける度に図２４（Ａ）あるいは図２４（Ｂ）などのような受付演出を行う。受付演出には、図２５のコンテンツ別演出テーブルに例示するように、ユーザからのアクションを受け付けたコンテンツ（記事ＩＤ）に関連付けられている関連タレントに対応したファンマークやタレント演出の演出表示が行われる。これにより、タップアクションによる受付演出に、タレントに関する演出が含まれているため、ユーザに対してタップアクションを取るよう促すことが可能となる。

（１－１２） また、タップアクションの受付演出は、ユーザからのタップアクションを所定回数（例えば１００回など）受け付けたときに、図２４（Ｂ）で例示するような豪華演出あるいはタレント演出などの特別な演出を行う。これにより、タップアクションを所定回数行えば特別な演出が行われるため、ユーザに対してタップアクションを取るよう促すことが可能となる。

（１－１３） ユーザに提供可能な複数種類のコンテンツには、関連タレントが関連付けられていることで、図１４のコンテンツデータベースにおいてタレントＩＤが関連付いているコンテンツが含まれ、関連タレントが関連付いているコンテンツに関しては、推しフィルター２０のオンあるいはオフのいずれの状態かにかかわらず、コンテンツに関連付けられているタレントのアイコンや名前などを表示する関連タレント８８が表示される。これにより、ユーザは推しフィルター２０がオンあるいはオフのいずれの状態であるか否かにかかわらず、コンテンツに関連付けられている関連タレントを特定可能であるため、ユーザの利便性が向上する。また、新たなタレントなどを知るきっかけを提供できる。

（１－１４） 図１４、図１７、図１８を参照して説明したように、ユーザに提供可能な複数種類のコンテンツには、ユーザから投稿される投稿コンテンツが含まれる。ユーザからの投稿時における図１７の関連タレントバー４０への選択操作などにより、図１８のステップＳ３１０、ステップＳ３１１で、投稿情報に関連タレントが関連付けられていた場合に、投稿情報によって生成されるコンテンツには、図１４のコンテンツデータベースで例示するようにタレントＩＤが関連付けられる。これにより、ユーザ投稿にもタレントを関連付けることができるため、ユーザ間において好みの情報の共有が容易となる。

（１－１５） 前記複数種類のコンテンツは、図１７、図１８を参照して説明したユーザ投稿処理により、ユーザから投稿される投稿コンテンツ（図１４の投稿権限「ユーザ」の記事など）を含み、ユーザには、図５のタレント各々に対応する複数の特定ユーザが含まれ、当該特定ユーザからのタップアクションやコメントなどのアクションがあった投稿コンテンツについては、図１０のホーム画面や、図１１（Ａ）のコミュニティ画面におけるコンテンツ見出し（６０，７０）、あるいは、図１３のコンテンツ画面において特別ユーザのアイコンとともに特別アクション７９を表示する。これにより、ユーザは、特定ユーザがアクションを行った投稿コンテンツであることを容易に特定可能となる。そのため、タレントに関する情報を求めるユーザにとって利便性が向上する。

（１－１６） 配信サーバ１００およびユーザ端末３００は、図７のユーザ情報データベースと、図１４のコンテンツデータベースに基づいて、ユーザにより予め選択されて記憶されている推しタレントが関連付けられたコンテンツが投稿された際に、ユーザに推しタレントが関連付けられたコンテンツが投稿された旨のプッシュ通知を送る。これにより、ユーザは推しタレントに関するコンテンツ情報の特定がより容易となる。また、ユーザが行った投稿コンテンツに対して特定ユーザからのアクションがあれば、ユーザは特別感を得ることができる。

（１－１７） 図２７を参照して説明したように、配信サーバ１００は、外部ウェブサービス４００により提供されるＡＰＩによって、配信するチャンネルアカウントの属性特定情報９６ａや、図２７（Ｃ）の外部ウェブサービス４００における配信画面の概要欄９５に含まれたハンドルの属性特定情報９６ｂ、タイトル９７、サムネイル画像９９の情報などを取得する。取得した情報に属性特定情報９６が含まれていることにより、属性特定情報９６に応じたタレントＩＤを特定し、当該特定されたタレントＩＤに基づいて生成されたコンテンツ見出し９０を含む図２７（Ａ）や図２７（Ｂ）の配信スケジュール画面をユーザ端末３００に表示させる。例えば、外部ウェブサービス４００から取得した情報に、タレント「ＡＡＡ」に対応する属性特定情報９６が含まれていれば、タレント「ＡＡＡ」のタレントＩＤ「ｔ１」が関連付いたコンテンツ見出し９０が生成される。コンテンツ見出し９０を特定するための情報が、コンテンツ管理部１３２により生成されて記憶される。そのため、チャンネルアカウントに対応するグループのうち、ユーザにより予め選択された参加コミュニティ（グループ）に関する配信のコンテンツ見出し９０が表示される。また、さらに推しフィルター２０への選択操作により、推しタレントが出演する配信のコンテンツ見出し９０に絞り込んで表示可能となる。これにより、外部ウェブサービス４００により提供される配信などの外部投稿についても、ユーザの好みの情報に最適化して、ユーザが特定することを容易にし得る。

（２－１） 上述した実施の形態では、図１～図４、図７、図８、図１９～図２３などを参照して説明したように、通信システム１が備える配信サーバ１００は、記憶している複数のユーザ各々が操作するユーザ端末３００から受け付けたアクションを、当該複数のユーザ各々が認識可能となるように当該複数のユーザ各々のユーザ端末３００に反映可能とするプログラムや当該プログラムによりコンピュータを制御する方法（以下、単にプログラムという）に基づいて、ユーザが投稿したコンテンツやコメントなどのアクションに対する、図２２に例示するような当該ユーザ本人以外からの評価である外的評価に応じて、当該ユーザ本人のレベルや累積ポイントなどの評価履歴状況を更新させる。また、図１９に例示するようにユーザの評価履歴状況が所定のレベルであるユーザであれば取り得る特定アクションを、所定のレベルではないユーザが取り得ないように、ユーザが取り得るアクションを制御する。また、例えば、特定状況である所定のレベル８０以上であるユーザが、レベル５９以下のユーザであれば制限されるリンクが埋め込まれたコンテンツを投稿する特定アクションを行っても、特定状況ではないレベル５９以下のユーザのユーザ端末３００においても、当該リンクが埋め込まれたコンテンツを表示可能とする。これにより、アクションを取ったユーザ以外からの評価である外的評価に応じて、ユーザが取り得るアクションが制御される。その上で、特定状況であるユーザから受け付けた特定アクションは複数のユーザ（特定状況ではないユーザが含まれるときであっても）に反映され得るため、コミュニティ内の治安をよい状態に維持させることが可能となる。

（２－２） 図２３のステップＳ４０２～ステップＳ４０６などで説明したように、アカウント管理部１３３は、レベルが上がり特定状況となったユーザに対して、レベルに応じた特定アクションを取り得ることを許容する。これにより、外的評価に応じて特定状況となったユーザに対して特定アクションを取り得ることを許容することで、特定状況ではないユーザが取り得るアクションに制限がかかるため、特定アクションを取り得る特定状況となるようなアクションを取るように促すことができ、コミュニティ内の治安がよい状態に維持し得る。

（２－３） 図１９を参照して説明したように、レベルに応じて取り得る特定アクションが段階的に定められている。例えば、レベル６０以上であれば、特定アクションとして投稿するコンテンツについてのリンクの制限がなくなり、レベル８０以上であれば、特定アクションとして企画作成をすることができる。これらの特定アクションは、図２３のステップＳ４０４～ステップＳ４０６で例示するように、レベルアップすることにより、レベルが５９から６０になったユーザに対して、投稿するコンテンツについてのリンクの制限がなくなることを許容し、レベルアップすることによりレベルが７９から８０になったユーザに対して、企画を作成することを許容するため、所定のレベルに達していないユーザが特定アクションを行うことが制限される。これにより、所定のレベルに達して特定状況となったユーザに対して許容する特定アクションを、レベルに応じて段階的に許容することにより、より上の段階を目指したアクションを取ることを促すことができ、コミュニティ内の治安がよい状態に維持し得る。

（２－４） 図２３のステップＳ４０７～ステップＳ４１１などで説明したように、アカウント管理部１３３は、レベルが下がり特定状況ではなくなったユーザに対して、レベルに応じて許可されていた特定アクションを取り得ることを制限する。これにより、外的評価に応じて特定状況ではなくなったユーザが特定アクションを取り得ることが制限されるため、特定状況を維持・改善できるようなアクションを取るように促すことができ、コミュニティ内の治安が安定し得る。

（２－５） 図１９を参照して説明したように、レベルに応じて取り得る特定アクションが段階的に定められている。例えば、レベル５９以下であれば、特定アクションである投稿するコンテンツについてのリンクの制限がなくなることが許容されていないため、投稿するコンテンツについてリンクの制限がある。レベル７９以下であれば、特定アクションである企画作成をすることが許容されていないため、企画を作成することに制限がされる。これらの特定アクションは、図２３のステップＳ４０９～ステップＳ４１１で例示するように、レベルダウンすることにより、レベルが６０から５９になったユーザに対して、許容されていた投稿するコンテンツについてのリンクを制限する。また、レベルダウンすることによりレベルが８０から７９になったユーザに対して、許容されていた企画を作成することを制限するため、所定のレベルではなくなったユーザが特定アクションを行うことが制限される。これにより、特定状況ではなくなったユーザに対して許容する特定アクションを段階的に制限することにより、極端に取り得るアクションが少なくなってしまうことを防止しつつ、特定状況を維持・改善できるようなアクションを促すことができ、コミュニティ内の治安がよい状態に維持し得る。

（２－６） 図８を参照して説明したように、ユーザの評価履歴状況に関する情報であるレベルや累積ポイントが表示されたユーザ履歴状況５５を、他のユーザには公表されない一方で、マイページ画面にてユーザ本人は確認することができる。これにより、外的評価に応じて更新される評価履歴状況に関連する情報を、ユーザ本人に対しては報知可能であるため、ユーザに対して自己の状況を把握させながらコミュニティの治安を良くすることに努めるように促すことができる。

（２－７） 図２２などを参照して説明したように、ユーザの評価履歴状況を更新させ得る外的評価には、運営者からの好印象によるポイント付与や、マイナス評価を含む。このように、外的評価にユーザとは異なる第三者である運営者からの評価が含まれるため、外的評価に私情が介入し難く、外的評価が公平なものとなり得る。

（２－８） 図２２などを参照して説明したように、ユーザの評価履歴状況を更新させ得る外的評価には、コミュニティアプリを利用する複数のユーザのうち、アクションを取ったユーザ本人とは異なる他のユーザからの好感アクションや通報などの評価を含む。このように、外的評価にアクションを取ったユーザ本人とは異なる他のユーザからの評価が含まれるため、コミュニティ内の治安がユーザ全体の意向に沿ったものとし得ることができる。

（２－９） 図１９などを参照して説明したように、レベル９０以上の「モデレータ招待」の特定アクションが許容されているユーザや、レベル７０以上の「通報カウント」の特定アクションが許容されているユーザから、非表示や通報などの規制対象とされたコンテンツやコメントに対して、複数のユーザ各々のユーザ端末３００などへ非表示などの規制処理を行う。これにより、ユーザのアクションに対する規制処理が、評価履歴状況が所定状況であるユーザにより規制対象とされたアクションに対して行われるため、むやみやたらにユーザのアクションに対する規制処理が行われてしまうことを抑制できる。

（２－１０） また、図１９などを参照して説明した「通報カウント」の特定アクションが許容されているユーザ所定数から規制対象とされたアクションは、複数のユーザ各々のユーザ端末３００において反映が規制される。これにより、評価履歴状況が所定状況であるユーザ所定数により規制対象とするアクションを受け付けたことにより、迷惑なアクションとみなして、当該アクションの反映が規制されるため、自由な交流・コミュニケーションを阻害することなく迷惑行為などを効率的に規制できる。

（２－１１） 図１９などを参照して説明したように、複数のユーザ各々の評価履歴状況であるレベルに応じて、例えばレベル５０～５９であれば、特典Ｅが付与され、レベル１００であれば、特典Ａ～Ｅよりもレア度が高い特典Ｓなどが付与され得る。このような構成によれば、評価履歴状況に応じて特典が付与され得るため、特典が付与される評価履歴状況となるようにユーザが意識するよう促すことができる。

（２－１２） 複数のユーザは同一のファンコミュニティに属しており、ユーザが取り得るアクションには、例えば、応援対象となるグループや、グループに所属するタレントに関連するコンテンツである配信動画やグッズなどに関する投稿を行う宣伝行為が含まれる。配信サーバ１００は、当該宣伝行為による配信動画の閲覧数やグッズ販売などへの利益貢献度に応じて外的評価が変動し、ユーザの評価履歴状況が更新される。これにより、ユーザが宣伝行為を行う動機付けとなり得るため、コミュニティが活性化する。

＜変形例＞
以上説明した実施の形態に対する変形例などを以下に列挙する。

（コンテンツ情報について）
上述した実施の形態では、コンテンツ（例えば、ニュース記事や、ユーザからの投稿情報など）に関するコンテンツ情報として、図１０、図１１、図２７などのコンテンツ見出し（６０，７０，９０）を例示した。しかしこれに限らず、コンテンツに関するコンテンツ情報は、例えば、図１３で例示したコンテンツ自体の画面における説明情報であってもよい。例えば、図１３のコンテンツ画面自体に表示されている各種情報である投稿者７１、内容７４ｂ、関連タレント８８、特別アクション７９、タップアクション数７８などが含まれる。

（属性選択処理について）
上述した実施の形態では、初回ログイン時に、図９のステップＳ１０２～Ｓ１０４において、参加コミュニティおよび推しタレントの選択ができる例について説明した。初回ログイン時における参加コミュニティおよび推しタレントの選択は、ステップＳ１０３においていずれも選択する必要があってもよく、いずれも選択しない（選択した属性はゼロ）操作ができるものであってもよい。また、参加コミュニティまたは推しタレントのいずれかのみ選択してもよく、いずれか一方については選択する必要があるものであってもよい。例えば、推しタレントを選択していたとしても、推しタレントが所属する所属グループ１に対応する参加コミュニティへの参加がされていなければ、コンテンツ画面において推しタレントに関する情報を抽出して表示できないものであってもよい。すなわち、推しフィルター２０をオン状態にしても、参加していないコミュニティに対応するグループに所属するタレントのコンテンツ見出しは表示されない。あるいは、参加コミュニティを選択した上でなければ、推しタレントの選択ができないものであってもよい。例えば、いずれかの参加コミュニティを選択しなければ、推しタレントを選択する画面に進めないものであってもよい。

上述した実施の形態では、図９のステップＳ１０１において、初回ログインであると判定されたときに、ステップＳ１０２において図６で例示した参加コミュニティおよび推しタレントの選択画面が表示される例について説明した。このとき、図６（Ａ）の参加コミュニティ設定、あるいは図６（Ｂ）の推しタレント設定について、予め（デフォルトで）全選択がされているものであってもよい。

上述した実施の形態では、図９のステップＳ１０１、ステップＳ１０２などにおいて、初回ログインであれば、ステップＳ１０２で属性選択画面がユーザ端末３００に表示される例について説明したが、初回ログイン時の画面には表示されず、あとでマイページなどから初回の属性の選択を行うものであってもよい。また、マイページなどでユーザによりあとから編集がされるまでは、初回ログイン時には、すべてのコミュニティに参加している状態となっているものであってもよい。

上述した実施の形態では、初回ログインではない場合（図９のステップＳ１０１ ＮＯ）において図６の設定編集画面を表示させたあとの、ステップＳ１０７における参加コミュニティ、または、推しタレントの選択がされたとの判定は、アイコン等への選択操作がされたタイミングである例について説明した。しかしこれに限らず、アプリ画面の下部に表示されるホームアイコン１３等への操作により、別画面に移動することで、図６の属性選択画面において選択された属性が決定されたものとして情報が送信されて受信することにより選択されたものとみなして、ステップＳ１０８に進むようにしてもよい。あるいは、図６の属性選択画面において、各参加コミュニティの表示、または、各タレントの表示に対する操作があったときに替えて、あるいは加えて、決定アイコンなどを表示させ、決定アイコンに対する操作があったとき（当該操作に応じて送信される情報を受信したとき）に選択がされたと判定されるものであってもよい。また、決定アイコンへの操作があったときには、ユーザ端末３００において特別な演出が行われてもよい。

（ホーム画面やコミュニティ画面などにおける特別アクションの表示態様について）
上述した実施の形態では、図１１（Ａ）などを参照して説明したように、タレントに対応する特別ユーザからのコメントやタップアクションがあったコンテンツについては、コンテンツ見出し７０内において特別ユーザのアイコンとともに特別アクション７９が表示される例について説明した。当該特別アクション７９は、コンテンツに対してアクションを行ったタレントが、ユーザが予め設定した推しタレントであった場合には、コンテンツ見出し７０内などに表示される特別アクション７９の表示態様を、アクションを行ったタレントが推しタレントではなかった場合とは異なる態様で表示させてもよく、コンテンツ見出し７０自体を、アクションを行ったタレントが推しタレントではなかった場合と異なる態様で表示させてもよい。あるいは、コンテンツに対してアクションを行ったタレントが、当該コンテンツに関連付けられている関連タレント本人であった場合には、コンテンツ見出し７０内に表示される特別アクション７９の表示態様を、アクションを行ったタレントが関連タレント本人ではなかった場合と異なる態様で表示させてもよく、コンテンツ見出し７０自体を、アクションを行ったタレントが関連タレント本人ではなかった場合と異なる態様で表示させてもよい。異なる態様とは、例えば、色彩が異なる態様や、メッセージの内容が異なる態様、メッセージの有無が異なる態様などである。

（コンテンツ画面におけるコメントの表示態様について）
上述した実施の形態では、図１３などを参照して説明したコンテンツ画面において、各コメント８７が、タレントに対応する特別ユーザからのコメントであった場合には、表示態様の変化や、表示順の変化を行うことができる例について説明した。これに替えて、あるいは加えて、コンテンツに対してコメントを行ったタレント（特別ユーザ）が、ユーザが予め設定した推しタレントであった場合には、当該推しタレントのコメント８７の表示態様を、アクションを行ったタレントが推しタレントではなかった場合と異なる態様で表示させてもよい。あるいは、各コメント８７の最も上位に表示させるなどである。あるいは、コンテンツに対してコメントを行ったタレントが、当該コンテンツに関連付けられている関連タレント本人であった場合には、当該関連タレント本人のコメント８７の表示態様を、アクションを行ったタレントが関連タレント本人ではなかった場合と異なる態様で表示させてもよい。異なる態様とは、例えば、色彩が異なる態様や、メッセージの内容が異なる態様、メッセージの有無が異なる態様などである。あるいは、各コメント８７の最も上位に表示させるなどである。

（ホーム画面に表示されるカテゴリについて）
上述した実施の形態では、図１０を参照して説明したホーム画面に、ユーザがいずれの参加コミュニティおよび、いずれの推しタレントをユーザが選択しているか否かにかかわらず表示されるフィーチャー６１に表示される例について説明した。しかしこれに限らず、フィーチャー６１は表示されないものであってもよい。例えば、ユーザが予め選択した参加コミュニティ（あるいは、選択にかかわらず常に参加状態となっているコミュニティを含む）に投稿されたコンテンツのみがホーム画面に表示されるものであってもよい。あるいは、フィーチャー６１は、カテゴリ毎にコンテンツ見出し６０が表示されるホーム画面とは異なる別の画面で表示されていてもよい。

上述した実施の形態では、推しタレントを選択しているユーザであれば、図１０のホーム画面に推しトピック６２が表示される例について説明した。しかしこれに限らず、推しタレントを選択していたとしても、推しトピック６２は表示されないものであってもよい。例えば、図１０のホーム画面において推しフィルター２０への選択操作によらなければ、いずれのカテゴリにおいても推しタレントが関連付けられたコンテンツ見出し６０の抽出がされないものであってもよい。あるいは、推しトピック６２は、カテゴリ毎にコンテンツ見出し６０が表示されるホーム画面とは異なる別の画面で表示されていてもよい。

（ユーザへの報知について）
上述した実施の形態では、ユーザが予め選択した推しタレントが関連付けられたコンテンツの投稿があったときにプッシュ通知が行われる例について説明した。これに加えて、コンテンツに対して特別ユーザであるタレント本人からのコメントがあったときには、一般ユーザに対して報知（お知らせ画面に表示、あるいはプッシュ通知など）が行われるようにしてもよい。あるいは、推しタレント本人からのコメントがあったときにのみ通知が報知されるようにしてもよい。あるいは、ユーザが予め設定した推しタレントであるタレント本人からのコメントがあったときには、推しタレントではないタレントからのコメントがあったときとは、報知態様が変化していてもよい。報知態様が変化とは、例えば、推しタレントからの通知であれば、アプリ画面下部に表示される通知アイコン１５が強調されていてもよい。

また、ユーザが行った投稿（コンテンツやコメント）に対し、特別ユーザを含む他のユーザからのコメントやタップアクションなどの好感アクションがされた場合に、当該投稿を行ったユーザに対し報知（お知らせ画面に表示、あるいはプッシュ通知など）が行われるようにしてもよい。このとき、例えば、通常であれば、１時間に１回まとめて通知がされるが、タレントである特別ユーザから、あるいは、推しタレントである特別ユーザからのアクションがされたときには、リアルタイムで報知がされるようにしてもよい。

なお、ユーザに対する報知は、推しタレントをユニット毎に選択していた場合には、ユニットに含まれるタレントのいずれかが関連付けられたコンテンツが投稿されたときや、ユニット単位で関連付けられたコンテンツが投稿された時などにプッシュ通知がされるものであってもよい。

（属性抽出処理について）
上記実施例においては、推しフィルター２０をオンにした場合、ユーザが予め選択した推しタレントが関連付けられたコンテンツ見出し（６０、７０）を抽出して表示される例について説明したが、推しタレントとして複数人選択していた場合には、さらに推しタレント毎に個別にタレントを絞ることができるようになっていてもよい。例えば、タレントＩＤ「ｔ１」、「ｔ２」、「ｔ３」のタレントを選択していたとすれば、推しフィルター２０をオンにする際に、「ｔ１」、「ｔ２」、「ｔ３」で、個別に選択できるようになっていてもよい。あるいは、推しタレントを予めユニット単位で選択していた場合には、ユニット単位で個別に選択できるようになっていてもよい。さらに、推しタレントの中から、さらに特別なタレント（最も推しているタレント）を予め選択しておくことで、最推しタレントでさらなるフィルターができるようになっていてもよい。このように、推しフィルター２０で、推しタレント全員を抽出したのちに、所定のアイコン等への操作によって、さらに個々に選択ができる（さらに絞りこむことができる）など、第１、第２、第３など複数段階でのフィルターが可能であってもよい。

また、推しタレントを予めユニット単位で選択していた場合には、ユニットに含まれるいずれかのタレントが関連タレントに関連付けられたコンテンツが投稿されれば、推しフィルター２０をオンの状態にすることにより、ユーザが予め選択したユニットのいずれかのタレントが関連付けられたコンテンツのコンテンツ見出しを抽出して表示可能としてもよい。

なお、タレントが所属する所属グループと対応するコミュニティとは異なるコミュニティ間であっても、いずれのタレントも関連づけることが可能であってもよい。例えば、タレントＩＤ「ｔ１」は、所属グループ１の「グループＡ」に所属するタレントであるが、「グループＢ」に対応する「コミュニティＢ」内で投稿されるコンテンツにタレント「ｔ１」が関連付けられるようになっていてもよい。そのため、タレントＩＤ「ｔ１」を選択しているユーザであって、「コミュニティＢ」にも参加していれば、ホーム画面あるいは「コミュニティＢ」内のコンテンツ画面において、推しフィルター２０をオンにする操作をすれば、タレントＩＤ「ｔ１」が関連付いているコンテンツが抽出して表示されるようになる。これにより、異なるグループ間でのコラボレーション企画などがあり、一方のグループに対応するコミュニティ内でしか投稿がされていなかった場合であっても、ユーザは推しタレントの情報を見逃すことなく取得できるようになる。なお、「コミュニティＢ」に参加していなくとも、推しタレントが関連付いているコンテンツについては、ホーム画面で表示されるようになっていてもよい。

（属性抽出処理における所定条件について）
上記実施の形態では、図１５、図１６などを参照して説明した、推しフィルター２０のオンまたはオフにするための所定条件として、ユーザがユーザ端末３００に表示される推しフィルター２０のアイコンをタップ操作することで、オンに操作されると所定条件が成立する例を説明した。しかしこれに限らず、所定条件とは、ユーザの意思に応じて推しフィルター２０のオンオフが切り替えられるものであればよく、例えば、音声指示による切り替えや、ユーザ端末３００自体を振動させる（例えば振るなど）ことで切り替えることなどが可能であってもよい。

（属性抽出処理における推しフィルター２０の記憶状態について）
上記実施の形態では、推しフィルター２０に対する操作後の、推しフィルター２０のオンの記憶状態について、アプリ起動後、図１３のコンテンツ画面を表示させたあとに、推しフィルター２０をオンにしていたコンテンツ画面やホーム画面に戻った場合にも、推しフィルター２０がオンの状態が記憶されており維持されている例について説明した。しかしこれに限らず、異なる画面に移った場合に、必ず、推しフィルター２０がオンあるいはオフのいずれかの状態になるようにしてもよい。例えば、推しフィルター２０がオンあるいはオフの状態の図１１のコミュニティ画面（あるいは、図１０のホーム画面）から図１３のコミュニティ画面を表示させたあと、図１１のコミュニティ画面（あるいは、図１０のホーム画面）に戻ったときに、推しフィルター２０がオフあるいはオンになっていてもよい。あるいは、図１０のホーム画面（あるいは、図１１のコミュニティ画面）にて推しフィルター２０をオンにし、図１１のコミュニティ画面（あるいは、図１０のホーム画面）を表示させたあとに、図１０のホーム画面（あるいは、図１１のコミュニティ画面）に戻ると、推しフィルター２０がオフあるいはオンの状態になっていてもよい。

（ユーザ投稿処理について）
上記実施の形態では、図１７のユーザ投稿画面例において、文字入力、画像アップのための投稿画面である図１７（Ａ）と、カテゴリや関連タレントを選択する画面である図１７（Ｂ）とが分かれている例について説明した。しかし、これに限らず、図１７（Ａ）と図１７（Ｂ）とが１つの画面で表示されて入力あるいは選択などが行われるようにしてもよい。例えば、スクロール等ができてもよく、別画面へ遷移をしなくてもよいようにする。また、文字入力、あるいは、画像投稿がなくても投稿ができるものであってもよい。あるいはタイトルがなかった場合でも、文字入力あるいは画像がアップされていれば投稿できるものとしてもよい。

また、カテゴリおよび関連タレントの選択は任意である例について説明したが、いずれも必須のものとしてもよい。あるいは、「カテゴリなし」、「関連タレントなし」の選択が可能であってもよく、図５の所属グループ２のユニットごとの選択ができるものであってもよい。また、ユニットごとの選択がされた場合には、ユニットに所属している個々のタレントのタレントＩＤおよびユニットを特定するためのユニットＩＤが、コンテンツに関連付けられていてもよい。あるいは、ユニットＩＤのみが関連付けられていてもよい。

（評価履歴状況更新処理について）
上述した実施の形態では、図２３のステップＳ４０６、および、ステップ４１１において、特定アクションの許可あるいは制限がされた旨を報知する例について説明した。しかし、これに限らず、ステップＳ４０６、およびステップＳ４１１におけるユーザに対する報知はなされないものであってもよい。あるいは、ステップＳ４０６で行動が許可された場合には、報知されるようになるが、ステップＳ４１１で行動が制限された場合には、報知しないなど、いずれかのみの報知がされるものであってもよい。例えば、制限がかかった場合については報知をしないことで、ユーザを動揺させてしまうことを回避できる。

（評価履歴状況の他の例について）
上述した実施の形態では、図１９を参照して説明したように、ユーザのレベルが、初期設定のレベルから外的評価に応じて段階を経て上がっていき、特定状況（例えば、レベル６０、レベル８０など）となる毎に、取り得る特定アクションがレベルに応じて許容されていく例について説明した。しかし、これに限らず、例えば、全ユーザについて初期設定では図１９の特定アクションが許容されていてもよく、レベルが下がることに応じて段階的に特定状況ではなくなっていき、特定アクションを取り得ることが制限されるようになっていてもよい。また、初期設定のレベルは、下限の１や上限の１００に限らず、８０などからスタートし、レベルの変動に応じて特定アクションを取り得ることについて、段階的に許容あるいは制限がされるものであってもよい。

上述した実施の形態では、ユーザのレベルや累積ポイントの変動は、ユーザ本人以外からの外的評価によるものである例について説明した。しかしこれに加えて、ユーザが、他のユーザの投稿やコメントへのタップアクションを行ったこと、あるいは、これに加えて他のユーザへのコメントをしたことにより累積ポイント数が増えるようにしてもよい。これにより、ユーザはコミュニティ内で活発に活動をするようになるため、コミュニティが活性化する。

上述した実施の形態では、ユーザが投稿したコンテンツやコメントに対して非表示・通報があったときには、ポイントが減少することにより、段階的に行動に制限がかかる例について説明した。これに替えて、あるいは、加えて、レベルに影響を与えるポイント（変動する累積ポイント）とは別に、評価履歴状況に、コミュニティアプリ内でのアクションの反映が規制される基準となる反映規制ポイントを定めてもよい。例えば、投稿したコンテンツや、コメント等に対して、他のユーザからの非表示あるいは通報が所定数（例えば、いずれか、あるいはいずれも合算して２０など）に達したユーザについては、行動が制限（反映規制）されるようにしてもよい。例えば、反映規制がかかったユーザが投稿したコンテンツやコメント等は、一定期間他のユーザには表示されないものとしてもよく、あるいは、一定期間コンテンツやコメント等の投稿自体ができないものとなってもよい。

なお、当該反映規制は、上述した図２２、図２３等のポイント数によって変動するレベルに応じて実行されるものとしてもよい。例えば、１よりも低いマイナスのレベルを設け、マイナスレベルとなったユーザに対して反映規制を行ってもよい。あるいは、コミュニティアプリスタート時のデフォルトのレベルを１０とし、１０よりも低いレベルとなっていくごとに、制限がかかっていくものとしてもよい。

（所定状況であるユーザからの好感アクションについて）
上述した実施の形態では、図１９を参照して説明したレベル別に取り得る特別アクション等の行動内容が変動する例について説明した。これに替えてあるいは加えて、レベルが高いユーザであることを他のユーザから認識できるようにしてもよい。レベルが高いユーザについては、コミュニティ内の雰囲気をポジティブにする行動を取る傾向が高く信頼度が高いと考えられる。そのため、レベルが高いユーザ（例えば、レベル９０以上）が行った、好感アクション（タップアクションや、好意的なコメントを含む）があったコンテンツの表示態様を変化させるようにしてもよい。あるいは、信頼度が高いユーザ複数人（例えば、５人などの所定数）から好感アクションを受け付けたときのみ表示態様の変化がされるものであってもよい。例えば、図１０のホーム画面におけるコンテンツ見出し６０や、図１１（Ａ）のコンテンツ見出し７０の表示態様、あるいは、タップアクション数７８の態様などを、色の変化、あるいは、信頼度が高いユーザからのアクションがあったことを示すマーク（例えば、特別アクション７９など）を表示させるようにしてもよい。あるいは、図１３で例示したコンテンツ画面において、コメントを目立たせる表示（上位表示、あるいは色の変化）などを行ってもよい。また、信頼度が高いユーザ複数人から好感アクションを受け付けたコンテンツや、コメントがあったときに、プッシュ通知や、お知らせでの表示がされてもよい。

また、当該信頼度が高いユーザから好感アクションがあった、コンテンツやコメントの投稿を行ったユーザに対して、信頼度が高いユーザからアクションがあったことを報知するようにしてもよい。例えば、該当するユーザのユーザ端末に対してプッシュ通知するようにしてもよく、アプリ内のお知らせで表示するようにしてもよい。

上述した実施の形態では、図１９の「通報カウント」の対象となるレベル７０以上のユーザ所定数（例えば、５人）から、非表示や通報などの規制対象とされたコンテンツやコメント自体、あるいはユーザに対して、複数のユーザ各々のユーザ端末３００などへコンテンツ自体の非表示や、規制対象とされたユーザが投稿したコンテンツ等を非表示とする例を説明した。これらの規制対象とされたコンテンツ等自体の規制処理と、規制対象とされたコンテンツ等を投稿したユーザの規制処理とで、非表示や通報を行った所定状況（例えばレベル７０以上）のユーザの人数の条件を異ならせてもよい。例えば「通報カウント」の対象となるレベル７０以上のユーザ第１数（例えば、５人）から規制対象とされたコンテンツやコメント等を全ユーザへ非表示とする規制処理を行い、第１数よりも多い第２数（例えば、２０人）から、投稿したコンテンツ等へ非表示や通報などがされたユーザについては、当該通報などがされたユーザが投稿したコンテンツ等をすべて全ユーザに非表示とする規制処理を行うようにしてもよい。

また、「通報カウント」の対象となる、レベルが７０以上のユーザから非表示や通報された人数が所定数蓄積したユーザが投稿したコンテンツやコメントを、ユーザ全体に非表示とすることができる。例えば、レベルが７０以上のユーザ５人から非表示あるいは通報がされたユーザが投稿したコンテンツやコメントは、全ユーザに非表示にすることができる。

なお、非表示とするユーザには、コメントやコンテンツの投稿を行ったユーザ本人は含まれないものとしてもよい。これにより、自身の投稿したコンテンツやコメントがユーザ本人の端末において反映されるものの、例えば他のユーザからのアクションがないことで、規制対象となったことを察知する（気付かせる）ことができる。

（評価履歴状況に関連する情報の報知について）
上述した実施の形態では、各ユーザは、自身の「レベル」および「累積ポイント」を図８で例示したマイページの、ユーザ評価履歴状況５５で確認することができる例について説明した。しかしこれに限らず、ユーザの評価履歴状況に関する情報であるレベルや累積ポイントは、ユーザ本人のみならず他のいずれのユーザにも報知しない一方で、運営者のみが管理者端末２００などにおいて確認できるものであってもよい。これにより、外的評価に応じて更新される評価履歴状況に関連する情報を、いずれのユーザにも報知しない一方で運営者には報知するため、ユーザのアクションを過度に委縮させないようにすることができつつ、運営者はユーザの評価履歴状況に関連する情報を把握し運営に役立てることができる。また、ユーザは自身の「レベル」に一喜一憂せずに、ファンコミュニティをより心地よく利用できるものとなる。

上述した実施の形態では、図２３などを参照して説明した評価履歴状況に関連する情報について、フィードバックとしてユーザに報知するようにしてもよい。例えば、所定期間（例えば、１日、あるいは、１週間など）における外的評価に応じて更新されたポイントの増減数や、レベルのアップダウンなどを、本日（あるいは、今週の）の行動の結果として、ユーザにフィードバックする。あるいは、これに替えて、あるいは加えて、所定期間におけるユーザが投稿したコンテンツ、あるいは、コメント（ユーザが取ったアクション）のテキストについて、例えばＡＩによる感情分析を行い、ポジティブワードの割合や、ネガティブワードの割合、あるいはいずれにも分類されないワードの割合をユーザに報知（例えば、所定の時間になればポップアップ画面にて表示、あるいは、お知らせページに表示など）してもよい。これにより、ユーザ自身が取った行動の傾向を客観的に知ることができ、コミュニティ内の治安を良くするための行動を取るよう心がけるよう促すことができる。

（外的評価について）
上述した実施の形態では、ユーザが投稿したコンテンツやコメントなどのアクションに対して非表示や通報等があったときには、ユーザのポイントが減少する例について説明した。これに加えて、例えば非表示にする場合に図１１（Ｂ）などの画面において非表示の理由を選択、あるいは、入力などができるようにしてもよい。ユーザが、他のユーザのアクションに対して非表示などを行う理由として、ライバルユーザであるなど個人的な事情により、コミュニティ内に悪影響を与え治安を悪化させるような虞のないアクションが非表示にされることがあるためである。そのため、実質的にコミュニティ内に悪影響のない非表示などは、ユーザのポイント数に影響を与えないものとし、実質的に悪影響のある非表示などのみポイント数に影響を与えるようにしてもよい。例えば、非表示の選択肢にポイントに影響のあるものと、ないものとを予め定めていてもよく、運営者によって非表示の理由を確認し、悪影響があると判断された非表示についてポイント数に影響を与えるよう操作がされてもよい。

上述した実施の形態では、ユーザが投稿したコンテンツやコメントなどのアクションに対してタップアクションやコメントがあったことなどの外的評価に応じて、ユーザのポイントが変動する例について説明した。このユーザが投稿するコンテンツについては、投稿数に制限がかかってもよい。例えば、ポイントがアップする外的評価の一例として、ユーザが投稿したコンテンツを通じた配信動画のＶｉｅｗ数や、グッズの購入数等の応援対象への利益貢献度を例示した。しかし、ポイントをアップさせようと、コンテンツの投稿が乱立してしまう虞があるため、例えばコンテンツの投稿について１日の１回などの制限がかかってもよい。また、レベルが高くなり、信頼度が高いユーザについては、１日あたりのコンテンツの投稿数の上限が増えるようになされてもよい。

〔ソフトウェアによる実現例〕
前述した実施の形態におけるサーバ、端末などのコンピュータが備える制御部の各種の制御ブロックは、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。ＣＰＵを用いてソフトウェアによって実現している場合、制御部を備えたコンピュータは、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

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

１ 通信システム、２ ネットワーク、１００ 配信サーバ、２００ 管理者端末、３００ ユーザ端末、４００ 外部ウェブサービスシステム

Claims (22)

1. 属性が関連付けられた複数種類のコンテンツをユーザに提供可能とするプログラムであって、
   前記属性は、複数種類の第１属性と、複数種類の第２属性とを含み、
   コンピュータを、
   前記複数種類の第１属性および前記複数種類の第２属性のうちから、前記ユーザからの操作に応じて予め選択された属性を特定可能に記憶するための記憶手段と、
   所定条件の成立に応じて、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる第１表示状態と、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる第２表示状態とを含む複数種類の表示状態のいずれかに切り替えて表示するための表示切替手段として機能させ、
   前記複数種類の第１属性は、各々、前記複数種類の第２属性の少なくともいずれかを含むグループであり、前記複数種類の第２属性は、各々、前記複数種類の第１属性に対応する複数種類のグループの少なくともいずれかに所属し得る属性である、プログラム。
2. 前記所定条件は、前記ユーザが属性を予め選択するときの一連の操作とは異なる操作であって、当該ユーザからの切替操作に応じて成立する条件を含む、請求項１に記載のプログラム。
3. 前記表示切替手段は、前記第１表示状態および前記第２表示状態のいずれにおいても前記切替操作を受け付けるアイコンを表示し、前記第１表示状態におけるアイコンへの操作に応じて前記第２表示状態に切り替えて表示し、前記第２表示状態におけるアイコンへの操作に応じて前記第１表示状態に切り替えて表示する、請求項２に記載のプログラム。
4. 前記複数種類のコンテンツには、前記第１属性および前記第２属性とは異なる第３属性が関連付けられているコンテンツを含み、
   前記表示切替手段は、前記第３属性が関連付けられているコンテンツに関するコンテンツ情報については、前記ユーザにより予め選択されて記憶されている属性にかかわらず、前記第１表示状態および前記第２表示状態のいずれにおいても特定可能となるように表示する、請求項１に記載のプログラム。
5. 前記複数種類のコンテンツには、前記第１属性および前記第２属性のうち第１属性のみが関連付けられているコンテンツを含み、
   前記第２表示状態は、前記第１属性のみが関連付けられているコンテンツに関するコンテンツ情報の表示を含まない表示状態である、請求項１に記載のプログラム。
6. 前記複数種類の第２属性とは、複数種類のキャラクタであり、
   前記複数種類の第１属性とは、前記第２属性であるキャラクタを区分けする複数種類のグループである、請求項１に記載のプログラム。
7. 前記複数種類の第２属性には、複数のキャラクタからなる属性が含まれる、請求項６に記載のプログラム。
8. 前記複数種類のコンテンツは、特定種類のカテゴリを含む複数種類のカテゴリのいずれかに分類可能であり、
   前記表示切替手段は、コンテンツに関するコンテンツ情報を前記複数種類のカテゴリ毎に分類して表示可能であり、特定種類のカテゴリにおいては、前記第１表示状態および前記第２表示状態のいずれにおいても、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツのうちの所定数のコンテンツに関するコンテンツ情報を当該ユーザが特定可能となるように表示し、前記特定種類のカテゴリ以外のカテゴリにおいては、前記第１表示状態および前記第２表示状態のいずれであるかに応じたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となるように表示する、請求項１に記載のプログラム。
9. 前記表示切替手段は、前記第１表示状態および前記第２表示状態のいずれにおいても、前記特定種類のカテゴリに分類されるコンテンツに関するコンテンツ情報を、他のカテゴリに分類されるコンテンツに関するコンテンツ情報よりも優先して表示可能とする、請求項８に記載のプログラム。
10. 前記第１表示状態は、前記ユーザにより予め選択されて記憶されている第１属性のうち、ユーザからの操作に応じて選択された第１属性が関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる表示状態を含む、請求項１に記載のプログラム。
11. 前記第２表示状態は、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のうち、ユーザからの操作に応じて選択された属性が関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる表示状態に切り替えて表示可能となる表示態様となる表示状態を含む、請求項１に記載のプログラム。
12. 前記コンピュータを、
    前記コンテンツに対する前記ユーザからの好感アクションを受け付ける度に受付演出を行うための手段として機能させ、
    前記受付演出は、前記アクションを受け付けたコンテンツに関連付けられている前記第２属性に関する演出を含む、請求項１に記載のプログラム。
13. 前記受付演出を行うための手段は、前記アクションを所定回数受け付けたときに、特別受付演出を行う、請求項１２に記載のプログラム。
14. 前記複数種類のコンテンツは、前記複数種類の第２属性のいずれかが関連付けられている第２属性関連コンテンツを含み、
    前記表示切替手段は、前記第１表示状態および前記第２表示状態のいずれにおいても前記第２属性関連コンテンツに関するコンテンツ情報について、当該第２属性関連コンテンツに関連付けられている第２属性を特定可能となるように表示する、請求項１に記載のプログラム。
15. 前記複数種類のコンテンツは、ユーザから投稿される投稿コンテンツを含み、
    前記コンピュータを、
    前記ユーザからの投稿情報に応じた投稿コンテンツに関するコンテンツ情報を生成するための手段であって、当該投稿情報に第２属性を指定するための情報が含まれる場合に当該投稿コンテンツが当該指定された第２属性が関連付けられたコンテンツに関するコンテンツ情報として生成するための手段として機能させる、請求項１に記載のプログラム。
16. 前記複数種類のコンテンツは、ユーザから投稿される投稿コンテンツを含み、
    前記ユーザには、複数の特定ユーザが含まれ、
    前記コンピュータを、
    前記投稿コンテンツに関するコンテンツ情報に対するアクションを受け付けるための手段として機能させ、
    前記複数種類の第２属性とは、前記複数の特定ユーザ各々に対応する複数種類のキャラクタであり、
    前記表示切替手段は、前記投稿コンテンツに関するコンテンツ情報に対して前記特定ユーザからアクションを受け付けたことに応じて、当該投稿コンテンツに関するコンテンツ情報の表示態様を異なる表示態様に変化させて表示する、請求項１に記載のプログラム。
17. 前記表示切替手段は、前記投稿コンテンツに関するコンテンツ情報に対して前記特定ユーザからアクションを受け付けたことに応じて、当該投稿コンテンツに関するコンテンツ情報の表示態様を、当該特定ユーザが前記ユーザにより予め選択されて記憶されている第２属性に対応する特定ユーザであるか否かに応じて異なる表示態様に変化させて表示する、請求項１６に記載のプログラム。
18. 前記表示切替手段は、前記投稿コンテンツに関するコンテンツ情報に対して前記特定ユーザからアクションを受け付けたことに応じて、当該投稿コンテンツに関するコンテンツ情報の表示態様を、当該特定ユーザが前記投稿コンテンツに関連付けられている第２属性に対応する特定ユーザであるか否かに応じて異なる表示態様に変化させて表示する、請求項１６に記載のプログラム。
19. 前記コンピュータを、
    前記ユーザにより予め選択されて記憶されている第２属性が関連づけられたコンテンツ情報を当該ユーザが特定可能となるようにする際に、当該ユーザに当該第２属性が関連付けられたコンテンツ情報が特定可能となる旨を報知するための手段として機能させる、請求項１に記載のプログラム。
20. 前記コンピュータを、
    外部サービスにより提供される外部投稿を特定するための情報であって、前記複数種類の第１属性および前記複数種類の第２属性のうち当該外部投稿情報に関連付けられている属性を特定するための属性特定情報を含む外部投稿情報を取得するための手段と
    前記外部投稿情報に応じて、外部投稿された外部投稿コンテンツに関するコンテンツ情報を生成するための手段であって、当該外部投稿情報に属性特定情報が含まれる場合に当該外部投稿コンテンツが当該属性特定情報から特定される属性が関連付けられた外部投稿コンテンツに関するコンテンツ情報として生成するための手段として機能させ、
    前記第１表示状態は、前記外部投稿コンテンツのうち、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられた外部投稿コンテンツに関するコンテンツ情報の表示を含む表示状態であり、
    前記第２表示状態は、前記外部投稿コンテンツのうち、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられた外部投稿コンテンツに関するコンテンツ情報の表示を含む表示状態である、請求項１に記載のプログラム。
21. 属性が関連付けられた複数種類のコンテンツをユーザに提供可能とするためのコンピュータを制御する方法であって、
    前記属性は、複数種類の第１属性と、複数種類の第２属性とを含み、
    前記複数種類の第１属性および前記複数種類の第２属性のうちから、前記ユーザからの操作に応じて予め選択された属性を特定可能に記憶するためのステップと、
    所定条件の成立に応じて、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる第１表示状態と、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる第２表示状態とを含む複数種類の表示状態のいずれかに切り替えて表示するためのステップとを備え、
    前記複数種類の第１属性は、各々、前記複数種類の第２属性の少なくともいずれかを含むグループであり、前記複数種類の第２属性は、各々、前記複数種類の第１属性に対応する複数種類のグループの少なくともいずれかに所属し得る属性である、方法。
22. 属性が関連付けられた複数種類のコンテンツをユーザに提供可能とするための処理を行うコンピュータを有するシステムであって、
    前記属性は、複数種類の第１属性と、複数種類の第２属性とを含み、
    前記複数種類の第１属性および前記複数種類の第２属性のうちから、前記ユーザからの操作に応じて予め選択された属性を特定可能に記憶するための記憶手段と、
    所定条件の成立に応じて、前記ユーザにより予め選択されて記憶されている第１属性が関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる第１表示状態と、前記ユーザにより予め選択されて記憶されている第１属性および第２属性のいずれもが関連付けられたコンテンツに関するコンテンツ情報を当該ユーザが特定可能となる第２表示状態とを含む複数種類の表示状態のいずれかに切り替えて表示するための表示切替手段とを備え、
    前記複数種類の第１属性は、各々、前記複数種類の第２属性の少なくともいずれかを含むグループであり、前記複数種類の第２属性は、各々、前記複数種類の第１属性に対応する複数種類のグループの少なくともいずれかに所属し得る属性である、システム。

Images