JP2015056127A - サーバ装置、情報処理プログラム、情報処理システム、および情報処理方法 - Google Patents

Abstract

【課題】情報の氾濫を防止し、限られた時間、限られた表示面積の中で、ユーザが見たい情報をより効率的にみることができる仕組みを提供できるサーバ装置、情報処理プログラム、情報処理システム、および情報処理方法を提供すること
【解決手段】所定のユーザから投稿されたコンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を記憶する。次に、当該コンテンツに対応する閲覧アクション情報に基づいてその表示態様を決定する。このとき、通常状態におけるコンテンツの表示態様とは異なる表示態様となるようにその表示態様を決定する。そして、決定された表示態様でコンテンツを表示するための閲覧ソースデータを生成する。
【選択図】図７

Description

本発明は、ユーザによるコンテンツの投稿および共有が可能な情報処理システムやこれに用いられるサーバ装置に関する。

近年、スマートフォン等の携帯情報端末が普及している。そして、ユーザは様々なネットワークサービスをこのような携帯情報端末を用いて利用する機会も増加している。
また、これとは別に、いわゆるソーシャルネットワークサービス（ＳＮＳ）も普及している。当該ＳＮＳは、パーソナルコンピュータのみならず、上記の携帯情報端末上でも利用可能であり、また、中には、携帯情報端末のみで利用可能なＳＮＳのようなものも提供されている。実際、携帯情報端末でＳＮＳを楽しむユーザも増加している。このようなＳＮＳでは、ユーザ同士で投稿を閲覧することが可能である（例えば、特許文献１）。また、このような投稿を閲覧する画面では、これらの投稿が時系列順で並べられて、それぞれ同じ表示態様で表示されている。

特表２０１２−５３０３２１号公報

近年の娯楽の多様化等に伴い、あるユーザがＳＮＳのために割ける時間は減少することが考えられる。そのため、携帯情報端末による上記ＳＮＳの利用についても、いわゆる「空き時間」や「隙間時間」にＳＮＳを閲覧するというケースが考えられる。このような閲覧の利用状況を考慮すると、より時間をかけずに効率的にＳＮＳを楽しむための仕組みが求められる。

また近年では、ＳＮＳの利用ユーザが爆発的に増加している傾向がある。そのため、ＳＮＳで閲覧する上記投稿等の情報の数も増加する傾向にある。このような情報数の増加は、いわば情報が氾濫する状態であるともいえ、効率的な閲覧の妨げになると考えられる。特に、上記のような携帯情報端末の普及度合いを考えると、このような携帯情報端末でＳＮＳを利用する機会も多い。しかし、携帯情報端末は、一般的にいって、その画面サイズ（表示面積）が（パーソナルコンピュータ等に比較すると）限られたサイズとなっている。上記のように情報が氾濫している状況を考慮すると、このように表示面積が限られている中で、ユーザが見たい情報を効率的に表示することが求められている。

それ故に、本発明の目的は、限られた時間、限られた表示面積の中で、ユーザが見たい情報をより効率的にみることができる仕組みを提供できるサーバ装置、情報処理プログラム、情報処理システム、および情報処理方法を提供することである。

上記目的を達成するために、例えば以下のような構成例が挙げられる。

構成例の一例は、ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置であって、閲覧アクション情報記憶部と、表示態様決定部と、閲覧ソース生成部とを備える。閲覧アクション情報記憶部と、所定のユーザから投稿されたコンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を記憶する。表示態様決定部と、通常状態のコンテンツの表示態様とは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する前記閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する。閲覧ソース生成部と、表示態様決定部で決定された表示態様で前記コンテンツを表示するための閲覧ソースデータを生成する。

上記構成例によれば、例えばスマートフォンの画面等、表示面積が限られた中で、ユーザが見たい情報をより効率的に閲覧できるようにすることが可能である。

他の構成例として、サーバ装置は、閲覧ソースデータを送信する送信部を更に備えでもよい。そして、表示態様決定部は、第１のユーザが行った閲覧アクションに関する情報に基づいて表示態様を決定し、閲覧ソース生成部は、第１のユーザが行った閲覧アクションに関する情報に基づいて決定された表示態様で第１のユーザとは異なる第２のユーザに閲覧させるコンテンツを表示するための閲覧ソースデータを生成し、送信部は、第２のユーザに当該閲覧ソースデータを送信するような構成としてもよい。

上記構成例によれば、主に他のユーザの閲覧アクションが反映された表示態様で投稿コンテンツを提示することができ、例えば、ある時点で話題になっているコンテンツ等を容易に知ることができる。

他の構成例として、閲覧アクション情報記憶部は、閲覧アクションに関する情報を累積して記憶し、表示態様決定部は、閲覧アクションの累積結果に基づいて表示態様を決定するよう構成されていてもよい。

上記構成例によれば、例えば、直近数ヶ月において話題となっているコンテンツや、あるコンテンツに対する閲覧アクションの回数等、より多様な視点に基づき所定の投稿コンテンツの表示態様を変化させることができる。

他の構成例として、サーバ装置は、閲覧ソースデータを送信する送信部を更に備えでもよい。そして、閲覧アクション情報記憶部は、第１のユーザが他のユーザのコンテンツに対して行った閲覧アクションに関する情報を記憶し、表示態様決定部は、第１のユーザが行った閲覧アクションに関する情報に基づいて、当該第１のユーザに閲覧させる上記他のユーザが投稿したコンテンツの表示態様を決定し、閲覧ソース生成部は、第１のユーザが行った閲覧アクションに基づいて決定された表示態様でコンテンツを表示するための閲覧ソースデータを生成し、送信部は、閲覧ソースデータを当該第１ユーザに送信するような構成としてもよい。

上記構成例によれば、主に閲覧者自身の閲覧アクションを表示態様に反映させることができ、自分の興味・関心度の高いユーザや親密度の高いユーザなどの投稿コンテンツを目立たせて提示することができ、閲覧者がみたい情報を効率的に閲覧可能とすることができる。

他の構成例として、表示態様決定部は、表示態様の決定を繰り返し実行するように構成しても良い。

上記構成例によれば、当該システムをユーザが繰り返し利用することで、ユーザが気付かないうちにコンテンツの表示態様を変化させていくことができる。

他の構成例として、閲覧ソース生成部は、複数のコンテンツが表示されるような閲覧ソースデータを生成し、表示態様決定部は、複数のコンテンツについて表示態様を個別に決定するよう構成しても良い。

上記構成例によれば、例えば複数のコンテンツが一覧表示されるような画面において、どのコンテンツが話題になっているか等をユーザに把握させやすくすることができる。

他の構成例として、閲覧ソース生成部は、当該閲覧ソースに基づいてコンテンツを表示する閲覧用画面において、当該閲覧ソースデータに含まれる各コンテンツはそれぞれその少なくとも一部が表示されるような閲覧ソースデータを生成し、閲覧アクションとは、この一部のみが表示されているコンテンツの全体あるいは詳細を表示することを要求する操作であってもよい。また、閲覧ソース生成部は、閲覧ソースデータに基づき表示される各コンテンツに対するフィードバックが可能なフィードバックボタンも表示されるように閲覧ソースデータを生成し、閲覧アクションとは、閲覧しているユーザがフィードバックボタンを押した操作であってもよい。

上記構成例によれば、閲覧者が少なくとも興味・関心を持ったコンテンツに対する操作に基づいて表示態様を変更することができる。

他の構成例として、表示態様決定部は、通常状態のコンテンツよりもその表示領域が大きくなるように閲覧アクションが行われたコンテンツの表示態様を決定するように構成されていてもよい。

上記構成例によれば、ユーザが見たいコンテンツがどれであるかを直感的に把握させることができる。

他の構成例として、閲覧ソース生成部は、閲覧ソースデータに基づき表示される各コンテンツが時系列順に表示されるように当該閲覧ソースデータを生成するように構成されていてもよい。

上記構成例によれば、例えば、最近投稿されたコンテンツが何であるか、今何が話題になっているか等を把握しやすくし、ユーザの利便性を高めることができる。

他の構成例として、サーバは、ユーザに関するプロフィール情報を記憶するプロフィール記憶部を更に備え、表示態様決定部は、ユーザ間のプロフィール情報を比較した結果、および、閲覧アクション情報に基づいて表示態様を決定するよう構成してもよい。

上記構成例によれば、例えば閲覧者と同じ趣味を有するユーザのコンテンツを更に目立たせて表示することが可能となる。

他の構成例として、閲覧ソース生成部は、閲覧ソースデータを受信した所定の端末装置において、表示態様を変更したコンテンツが当該端末装置の画面内に表示される場合に、ユーザの注意をひくための制御であって当該表示態様の変更以外の所定の制御が当該端末装置において更に行われるように当該閲覧ソースデータを生成するよう構成しても良い。

上記構成例によれば、コンテンツを閲覧しているユーザに対して、表示態様が変化したコンテンツの存在について（例えばスクロール操作の結果画面内に入ってきたとき等）に気付かせやすくすることができる。

他の構成例として、少なくとも一つのサーバと複数の端末装置とを備え、ユーザによる当該端末装置を用いたコンテンツの投稿および共有が可能な情報処理システムであって、 前記端末装置は、投稿送信部と、閲覧要求送信部と、閲覧アクション送信部と、閲覧画面表示部と、を備える。投稿送信部は、コンテンツをサーバに送信する。閲覧要求送信部は、コンテンツを表示するための閲覧画面を表示する要求を示す閲覧要求をサーバに送信する。閲覧アクション送信部は、コンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報をサーバに送信する。閲覧画面表示部は、閲覧画面の基となる閲覧ソースデータをサーバから受信し、これに基づいて閲覧画面を生成して表示する。また、サーバは、投稿コンテンツ受信部と、閲覧アクション情報記憶部と、表示態様決定部と、閲覧ソース生成部と、閲覧ソース送信部とを備える。投稿コンテンツ受信部は、所定のユーザから送信されたコンテンツを受信する。閲覧アクション情報記憶部は、閲覧アクション送信部から送信された閲覧アクションに関する情報である閲覧アクション情報を記憶する。表示態様決定部は、通常状態のコンテンツとは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する。閲覧ソース生成部は、閲覧要求の受信に応じて、表示態様決定部で決定された表示態様でコンテンツを表示するための閲覧ソースデータを生成する。閲覧ソース送信部は、生成された閲覧ソースデータをその要求元に送信する。更には、閲覧ソース生成部は、閲覧画面に複数のコンテンツが含まれるよう閲覧ソースデータを生成し、閲覧画面表示部は、複数のコンテンツが含まれた閲覧画面を生成して表示し、閲覧アクション送信部は、閲覧画面に含まれるいずれかのコンテンツに対して行われた閲覧アクションに関する情報を送信し、表示態様決定部は、送信された閲覧アクションに関する情報が閲覧アクション記憶部によって記憶された後に行われた閲覧要求に応じて、送信された情報に基づいて前記閲覧アクションが行われたコンテンツの表示態様を決定し、閲覧ソース生成部は、閲覧アクションが行われたコンテンツの表示態様を表示態様決定部で決定された表示態様に変更した閲覧ソースデータを生成し、閲覧ソース送信部は、表示態様が変更されたコンテンツを含む閲覧ソースデータを、閲覧要求を行った端末装置に送信するように構成しても良い。

上記構成例によれば、例えばスマートフォンの画面等、表示面積が限られた中で、ユーザが見たい情報をより効率的に閲覧できるようにすることが可能である。また、他のユーザの閲覧アクションが反映された表示態様で投稿コンテンツを提示することができ、例えば、ある時点で話題になっているコンテンツ等を容易に知ることができる。

他の構成例として、ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置であって、閲覧アクション情報記憶部と、表示態様決定部と、閲覧ソース生成部とを備える。閲覧アクション情報記憶部は、所定のユーザがコンテンツを投稿したユーザに対して行った所定の操作である閲覧アクションに関する情報を記憶する。表示態様決定部は、通常状態のコンテンツとは異なる表示態様となるように、コンテンツを投稿したユーザに対応する閲覧アクション情報に基づいて、当該コンテンツを投稿したユーザにかかるコンテンツの表示態様を決定する。閲覧ソース生成部は、表示態様決定部で決定された表示態様でコンテンツを表示するための閲覧ソースデータを生成する。

上記構成例によれば、例えばスマートフォンの画面等、表示面積が限られた中で、ユーザが見たい情報をより効率的に閲覧できるようにすることが可能である。また、他のユーザの閲覧アクションが反映された表示態様で投稿コンテンツを提示することができ、例えば、ある時点で話題になっているコンテンツ等を容易に知ることができる。

本実施形態によれば、ユーザが見たい情報について、より効率的に閲覧することが可能となる。

本実施形態に係る情報処理システムの全体像を示す模式図 端末装置１０の構成の一例を示す機能ブロック図 サーバ装置２０の構成の一例を示す機能ブロック図 本実施形態の閲覧画面の一例 本実施形態の閲覧画面の一例 本実施形態にかかる処理の動作概要を説明するための図 本実施形態の第１の表示モードを説明するための図 本実施形態の第２の表示モードを説明するための図 サーバ２０のメインメモリ２５に格納されるプログラムおよび情報の一例を示す図 ユーザデータ６２のデータ構成の一例 お気に入りユーザデータ６９のデータ構造の一例 投稿コンテンツデータ６３のデータ構成の一例 閲覧アクションデータ８５のデータ構造の一例 端末装置１０のメインメモリ１５に格納されるプログラムおよび情報の一例を示す図 端末装置１０における処理の詳細を示すフローチャート サーバ２０における処理の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。

図１は、本実施形態に係る情報処理システムの全体像を示す模式図である。本実施形態の情報処理システムでは、サーバ２０と、複数の端末装置１０Ａ〜１０Ｃ（以下では総称して端末装置１０と呼ぶこともある）とがネットワーク（例えばインターネット）を介して接続および通信可能に構成される。端末装置は、例えば、スマートフォン、携帯電話、ＰＤＡ等の携帯型端末装置や、いわゆるタブレット型の情報処理装置等である（但し、他の実施形態では、パーソナルコンピュータ等の端末装置であってもよい）。本実施形態では、このようなシステムにおいて、いわゆるソーシャルネットワーキングサービス（以下、ＳＮＳ）が実行される場合を想定する。また、本実施形態では、このようなサービスの中でも、特に、コミュニティ型の会員制のサービスを想定する。例えば、その利用のためにユーザ登録が必要となるようなサービスである（サーバ２０において、利用ユーザのアカウント情報等が保存されるようなサービス）。そして、各ユーザは所定のコンテンツ（例えば所定のテキスト）を（サーバ２０に）「投稿」することができる。以下の説明では、このコンテンツのことを「投稿コンテンツ」と呼ぶ。また、（自分や）他人の投稿コンテンツを「閲覧」することもできる。更に、各投稿コンテンツに対して、所定のアクションを行うことができる。例えば、ある投稿コンテンツに対して、「コメント」をつけたり、肯定的な評価または否定的な評価を示すボタン（いわゆる「いいね！」ボタンや「よくない」ボタン等）を押すというような「フィードバック」を行うことが可能である。以下の説明では、このようなアクションのことを「閲覧アクション」と呼ぶ。

なお、本実施形態では、次のような操作についても閲覧アクションとして扱う。例えば、投稿コンテンツの詳細表示を求めるような操作も閲覧アクションとして扱う。これは、初期表示では投稿コンテンツの全文が表示されておらず、最初の１〜２行程度しか表示されていない状態において、例えば「全文表示」ボタンを押す、等の操作である。つまり、ユーザがある投稿コンテンツに着目して行った所定の操作を閲覧アクションとして扱う。また、例えば投稿コンテンツが縦方向に一覧表示されているような画面において、縦方向の画面スクロール操作が行われたときのそのスクロール速度や、投稿コンテンツがどれだけの時間閲覧されたかもここでいう閲覧アクションに含める。例えば、スクロール速度が速い場合は読み飛ばされている状態であり、このような状態でスクロール速度が急に遅くなったりスクロールが停止したりしたような場合は、そのときに画面内に表示されている投稿コンテンツがじっくりと読まれている（注目されている）と考えられる。そのため、このような画面遷移の状態や画面スクロール操作を検出し、これに基づいて投稿コンテンツに注目しているか否かを判定して、投稿コンテンツに注目されていると判定される場合は、その投稿コンテンツに対する上記閲覧アクションが行われたものとして扱う。また、例えば、投稿コンテンツに含まれる画像を拡大する操作や、投稿コンテンツに含まれているハイパーリンクをクリックする操作が行われた場合も上記閲覧アクションが行われたものとして扱う。

また、その他、投稿コンテンツそのものが写真やイラスト等の画像であるような場合は、当該画像を拡大表示する操作（例えば当該画像をクリックやタッチすると、別画面や別ウィンドウで当該画像を投稿コンテンツ内で表示されているのよりも大きなサイズで表示するような場合）も上記閲覧アクションが行われたとして扱う。また、この画像に対して上記肯定的評価や否定的評価等のフィードバックが行われた場合も上記閲覧アクションが行われたとして扱う。また、例えば投稿コンテンツが音声や動画データのような場合、例えば投稿コンテンツ内では静止画として表示されている動画データを再生する操作が行われた場合も上記閲覧アクションが行われたとして扱う。また、その他、投稿コンテンツがダウンロード可能なものであり、これをダウンロードするような操作が行われた場合も上記閲覧アクションが行われたとして扱う。

また、上記ユーザ間の関係について、例えば「フレンド」という関係が設定されたユーザ同士でのみ上記の閲覧が可能なように構成しても良い。つまり、端末装置側で閲覧する際に、「フレンド」ではないユーザの投稿コンテンツは閲覧できず、「フレンド」関係にあるユーザの投稿コンテンツのみが表示されるような構成としてもよい。ここで、本実施形態における「フレンド」とは、互いに認証した関係であることをいう。例えば、ユーザＡが（まだ自分とはフレンドとしての関係が設定されていない）ユーザＢに対して「フレンドリクエスト」を送信する。これに対して、ユーザＢがこのリクエストを承認することで、初めて両者が「フレンド」であるとして設定される。

図２に、端末装置１０の機能ブロック図を示す。図２において、端末装置１０は、入力装置１１、表示装置１２、プロセッサ１３、記憶装置１４、メインメモリ１５、通信部１６を備えている。入力装置１１は、端末装置１０のユーザによって操作され、ユーザの操作に応じた信号を出力する。入力装置１１は、例えば、十字スイッチや押しボタンやタッチパネルである。表示装置１２は、端末装置１０において生成された画像を画面に表示する。表示装置１２は、典型的には液晶表示装置である。記憶装置１４には、プロセッサ１３によって実行されるコンピュータプログラムや当該プログラムで利用される各種データが格納されている。記憶装置１４は、例えば、フラッシュＥＥＰＲＯＭやハードディスク装置である。メインメモリ１５は、コンピュータプログラムや情報を一時的に記憶する。通信部１６は、有線、または無線通信によってネットワークと接続し、サーバ２０や他の端末装置に所定のデータを送信したり、サーバ２０や他の端末装置から所定のデータを受信したりする。

図３は、サーバ２０の機能ブロック図を示す。図３において、サーバ２０は、プロセッサ２３、記憶装置２４、メインメモリ２５、通信部２６を有する。記憶装置２４には、プロセッサ２３によって実行されるコンピュータプログラムや当該プログラムで利用される各種データが格納されている。記憶装置２４は、例えば、ハードディスク装置である。メインメモリ２５は、コンピュータプログラムや情報を一時的に記憶する。通信部２６は、有線、または無線通信によってネットワークと接続し、他の端末装置との間で所定のデータの送受信を行う。

次に、本実施形態にかかる情報処理システムで実行される情報処理（各端末装置１０で実行される情報処理）の動作概要を説明する。本実施形態にかかる処理は、概略的に、以下のような動作が行われる。すなわち、ある投稿コンテンツに対して、これを閲覧しているユーザが閲覧アクションを行うと、そのアクションの内容に応じて、投稿コンテンツの表示態様を変化させる、という処理が行われる。ここで、本実施形態における表示態様の変更とは、表示される情報を増加させる、あるいは、強調させる目的で行われるものである。例えば、投稿コンテンツ自体のフォントサイズを大きくすることや、文字の色を変えることや、投稿コンテンツが表示される表示領域の大きさ（面積が増える結果、表示され得る文字数も増加する）を増加させることで表示態様を変化させる。そのため、例えば、投稿コンテンツの表示領域の隅のほうに、コメント件数を示す数値を小さく付するのみで、投稿コンテンツ自体の表示（その表示領域やフォントサイズ）については特に変更されないようなものは、ここでいう表示態様の変化には含まれない。以下の説明では、フォントサイズを大きくし、かつ、表示領域を大きくする場合を当該「表示態様の変更」の例として説明する。例えば、ある投稿コンテンツに対して、肯定的な評価が所定数以上行われた場合は、その投稿コンテンツを含む閲覧画面において、当該投稿コンテンツのフォントサイズ及びその表示領域をその他の投稿コンテンツよりも大きくして表示されるようにすることで、高評価の投稿コンテンツを目立たせることができる。図４は、上記の閲覧アクションが行われる前の閲覧画面の一例である。図４では、ユーザＡ〜ユーザＤにかかる４つの投稿コンテンツ５１Ａ〜５１Ｄが示されている（なお、図示は省略しているが、上記フィードバックを行うためのボタンや、詳細表示を行うためのボタンも適宜表示されているものとする）。また、図５は、閲覧アクションに応じて表示態様が変化した投稿コンテンツを含む閲覧画面の一例である。図５では、図４におけるユーザＢの投稿コンテンツ５１Ｂに対して、肯定的な評価を示す操作が所定回数以上行われた場合の画面例である。図５においては、投稿コンテンツ５１Ｂのフォントサイズおよび表示領域が他の投稿コンテンツ５１Ａ、５１Ｃ、５１Ｄよりも大きなサイズで表示されている。

また、その他、投稿コンテンツが写真やイラストなどの画像であるような場合は、その他の画像よりも大きなサイズで表示したり、当該画像を色枠で囲うことで強調表示したりすることで表示態様を変化させてもよい。

なお、以下の説明では、図４における投稿コンテンツ５１Ａ〜Ｄや、図５における投稿コンテンツ５１Ａ、５１Ｃおよび５１Ｄのように、表示態様が変化させられていない状態を「通常状態」と称し、表示態様を変化させずに表示することを「通常状態で表示」のように称する。換言すれば、システム的にデフォルトとして設定されている表示態様のことをここでは「通常状態」と呼ぶ。例えば、フォントの色を例にすると、通常状態（デフォルト色）は黒色であり、閲覧アクションに応じて表示態様が変更された場合は青色にする、等である。

次に、図６を用いて、上述した動作概要をより具体的に説明する。図６は、本実施形態にかかる処理の動作概要を説明するための図である。図６では、ユーザＡが操作する端末装置Ａと、ユーザＢが操作する端末装置Ｂと、ユーザＣが操作する端末装置Ｃと、サーバとでそれぞれ行われる操作や処理について、縦軸方向に時系列順に並べて示したものである。なお、ユーザＡ、ユーザＢ、およびユーザＣは互いに「フレンド」であると設定されているものとする。

図６において、まず、ユーザＡが端末装置Ａを操作して所定のテキストを入力し、投稿コンテンツとしてサーバに送信（投稿）する（Ｐ１）。ここで、本実施形態では、説明の便宜上、投稿コンテンツの内容はテキストであるとするが、他の実施形態では、投稿コンテンツは例えば写真や音声、動画であってもよいし、これらの組み合わせであってもよい（例えば、テキストと写真の組み合わせでも良い）。

サーバでは、上記の投稿コンテンツを受信し、当該投稿をユーザＡと関連づけて所定の記録媒体に記録する（Ｐ２）。なお、図示は省略するが、ユーザＡ以外のユーザからも適宜投稿コンテンツが送信され、サーバに記録されているものとする。

なお、他の実施形態では、サーバにおいて、上記受信した投稿コンテンツをその投稿ユーザとは関連づけず、当該投稿コンテンツのみを記録するようにしても良い。

その後、ユーザＢの操作に基づいて端末装置１０Ｂが、複数の投稿コンテンツの一覧表示を要求するための閲覧リクエストをサーバに送信する（Ｐ３）。例えば、端末装置ＢにおいてＳＮＳアプリが起動されたときに、「最近」の投稿（閲覧リクエストのあった時点から過去所定期間内の投稿）をサーバに要求する処理等が実行されることで、この閲覧リクエストが送信される。なお、説明の便宜のため、ここではこの「最近」の投稿の中に上記のユーザＡの投稿コンテンツが含まれているとする。

サーバでは、端末装置Ｂからの閲覧リクエストを受信し、これに応じて、端末装置Ｂにおいて表示される閲覧用画面の基となるデータ、すなわち閲覧ソースを生成する（Ｐ４）。すなわち、閲覧リクエストを送ったユーザのフレンド関係を参酌しながらサーバに記録されている所定の投稿コンテンツのデータ（典型的には、複数の投稿コンテンツである）を読み出す。換言すれば、閲覧リクエストを送ったユーザとフレンド関係が設定されているユーザにかかる投稿コンテンツを抽出する。そして、これらの投稿コンテンツが、例えば投稿日等の時系列でソートされて一覧表示されるような閲覧用画面の素になるデータ、例えば、ＨＴＭＬ等のマークアップ言語で記述されるデータを生成する。また、この際、必要に応じて所定の投稿コンテンツの表示態様が上記通常状態とは異なるようにして閲覧ソースを作成する処理も行われるが、これについては後述する。なお、説明の便宜上、この時点では、投稿コンテンツの表示態様の変化はまだ行われていないものとする（通常状態での表示）。

次にサーバは、上記閲覧ソースを端末装置Ｂに送信する（Ｐ５）。これに応じて、端末装置Ｂでは、当該閲覧ソースを受信し、これに基づいて閲覧用画面（例えば上記図４参照）を生成して画面に表示する（Ｐ６）。例えば、端末装置０１Ｂは、上記閲覧ソース（例えばＨＴＭＬ等のマークアップ言語で記述されたデータ）をレンダリングすることで閲覧用画面を生成して表示する。

次に、ユーザＢがこの閲覧用画面に対して閲覧アクションを行ったとする（Ｐ７）。例えば、ユーザＡの投稿コンテンツに対して、肯定的な評価を示す操作（「いいね！」ボタンを押す等）を行ったとする。この場合、その操作内容がサーバに送信される。サーバでは、この操作内容を受信し、当該操作内容に関するデータを対象となった投稿コンテンツ（この場合は上記のユーザＡの投稿コンテンツ）に関連づけて記録する（Ｐ８）。なお、本実施形態では、このような閲覧アクションを示すデータを累積して記憶する。

その後、別の端末装置Ｃから、閲覧リクエストがサーバに送信されたとする（Ｐ９）。なお、この閲覧リクエストにも上記ユーザＡの投稿コンテンツが含まれているとする。サーバは、当該閲覧リクエストに応じて閲覧ソースの作成を行う（Ｐ１０）。この際、上記閲覧アクションを反映して投稿コンテンツの表示態様を上記通常状態と異ならせる（変更する）。例えば、フォントサイズおよび表示領域が通常状態より大きくなるように変更する。また、表示態様を変化させるか否かの決定や変化させる内容について、上記閲覧アクションの累積値に基づいて決定するようにしてもよい。例えば、上記の肯定的な評価を示す操作が所定回数以上行われていれば、表示態様を変更すると決定してもよい。また、その回数に応じて、例えばフォントサイズの大きさを段階的に変更するようにしてもよい。

そして、上記のように表示態様が変更されるよう設定された閲覧ソースが作成されると、閲覧リクエストを送ってきた端末装置Ｃに当該閲覧用ソースが送信される（Ｐ１１）。当該閲覧用ソースを受信した端末装置Ｃは、当該閲覧用ソースに基づいて閲覧用画面を生成し、画面に表示する（Ｐ１２）。その結果、例えば上記図５で示したような、（肯定的評価の閲覧アクションが行われた）投稿コンテンツのフォントサイズおよび表示領域が大きく表示された閲覧用画面が表示される。

このように、あるユーザの投稿コンテンツに対して閲覧アクションが行われると、その後、所定の端末で閲覧用画面が表示される際、当該投稿コンテンツの表示態様が（閲覧アクションの内容に応じて）変更されて表示される。つまり、（主に）他人の閲覧アクションが表示態様の変化に反映されることになる。例えば、肯定的な評価を示す閲覧アクションが所定回数以上行われたときに表示態様を変更する場合を想定する。図７に、このような流れの模式図を示す。図７では、ユーザＢの投稿コンテンツに対して肯定的評価が所定回数以上行われた場合を示している。この場合、閲覧用画面が表示された時点において、例えば人気のある投稿コンテンツや、好意的・肯定的な閲覧アクションがよく返されている投稿コンテンツが他の投稿コンテンツよりも目立つように表示される。そのため、閲覧するユーザにとって、どの投稿コンテンツが人気が高いか等（つまり、人気度、話題度、流行度）を視覚的に把握しやすくなる。その結果、ユーザにとって必要な情報や所望する情報（投稿）を拾いやすくすることができ、閲覧に際してのユーザの利便性、効率性を高めることができる。

また、図７の例では、ユーザＡ等が直接的に閲覧アクションを返した投稿コンテンツの表示態様が変更された例を挙げている。すなわち、「投稿コンテンツ」単位で表示態様が変更される場合を例に挙げているが、他の実施形態では、例えば図７で示したもの以外のユーザＢの投稿コンテンツについても一律に表示態様が変更されるようにしてもよい。つまり、「投稿者」単位で表示態様の変更を行うようにしても良い。例えば、ユーザＢが投稿した複数の投稿コンテンツのうち、肯定的評価が所定数以上行われた投稿コンテンツが所定数以上あれば、ユーザＢにかかる投稿コンテンツの全てについてその変更態様を変更するようにしてもよい。例えば、ユーザＢが１０の投稿コンテンツを投稿しているとする。そして、このうち肯定的評価が２０回以上行われた投稿コンテンツが６つ以上であれば、ユーザＢにかかる投稿コンテンツは全て（過去に投稿した分、および、今後投稿される分の双方を含めて）、表示態様を変更するようにしてもよい。また、別の例として、ユーザＢの全ての投稿コンテンツを対象として、例えば肯定的評価の合計数が所定値以上であれば、ユーザＢにかかる投稿コンテンツの全てについて表示態様を変更するようにしても良い。例えば、ユーザＢが１０の投稿コンテンツを投稿しており、これらに対する肯定的評価の合計回数が６０以上であれば（つまり、どの投稿コンテンツに肯定的評価がなされているかに関わらず６０回以上の肯定的評価が行われていれば）、ユーザＢの投稿コンテンツについては全て表示態様を変更するようにしても良い。また、更には、ユーザＢの投稿コンテンツの内、例えば過去３ヶ月分を対象にして上記のような判定を行うようにしても良い。つまり、肯定的評価の回数等を評価する期間を限定した上で上記のような判定を行っても良い。

また、本実施形態では、閲覧アクションを行ったユーザ自身に着目した処理として、次のような処理も実行される。例えば、あるユーザが「他のユーザ」の投稿コンテンツに対して行った閲覧アクションに応じ、当該他のユーザのその他の投稿全般の表示態様を変化させて当該あるユーザに対して表示するという処理も行われる。いわば、このような「他のユーザ」を、あるユーザが気になったユーザや注目しているユーザ（以下では、便宜上「お気に入り」ユーザと呼ぶ）であるとして記憶しておき、当該他のユーザの投稿全般について表示態様を変化させて当該あるユーザに対して表示するというような処理である。つまり、ユーザ自身が過去に行った閲覧アクションを表示態様の変化に反映させるものである。図８は、このような処理の例を示す模式図である。例えば、ユーザＡが自己の端末装置Ａで閲覧用画面を表示し、この画面では、ユーザＣ，Ｂ，Ｆ，Ｄの投稿コンテンツが時系列（投稿日時の新しい順）で表示されていたとする。そして、ユーザＡは、ユーザＢおよびＤの投稿コンテンツに対して肯定的な評価を示す閲覧アクションを行ったとする。この場合、ユーザＡが肯定的な評価を行ったユーザが誰であるかを示す情報（この場合はユーザＢおよびＤを示す情報）がユーザＡに関連づけられてサーバ２０に記憶される。そして、ユーザＡがその後に閲覧用画面の表示を要求したとき、その画面にユーザＤあるいはユーザＢの投稿コンテンツが含まれる場合は、サーバ２０において、その表示態様を変化させて表示する閲覧ソースが生成され、送信処理が行われる。その結果、上記閲覧アクションが直接的に行われた投稿コンテンツに限らず、その後に投稿された投稿コンテンツも含めて、ユーザＢやユーザＤの投稿コンテンツであれば一律に表示態様を変化させる処理が行われる。これにより、例えばユーザＡにとって、親密度の高いユーザ（例えば家族や恋人等）や、（親密ではないが）興味や関心の高いユーザの投稿を目立たせて表示することができる。そのため、各ユーザ自身の好み等に応じた閲覧用画面を提供でき、その閲覧性や利便性を高めることができる。

また、閲覧アクションが所定回数以上行われた場合に表示態様を変化させるようにすれば、自らが閲覧アクションを何度も行っているようなユーザは親密度が高い、あるいは、興味関心度が高いユーザと考えられる。例えば、ユーザＡが（親密ではない）ユーザＢのコンテンツに対して閲覧アクションを何度も行った場合を想定する。この場合に、当初は、ユーザＡはユーザＢに対して意識的には興味を持っておらず、軽い気持ちで閲覧アクションを行っていたとしても、何度か閲覧アクションを行った結果、ユーザＢのコンテンツの表示態様が変化することで、ユーザＡがユーザＢに関心を持っていたことに事後的に気付かせることも可能となる。

以下の説明では、端末装置１０において、上述した図７のような、主に他のユーザの閲覧アクションに基づいて表示態様を変更した閲覧用画面を表示する場合を「第１の表示モード」と呼ぶ。一方、上述の図８を用いて示したような、ユーザ自身の閲覧アクションに基づいて表示態様を変更した閲覧用画面を表示する場合を「第２の表示モード」と呼ぶ。そして、本実施形態では、ユーザによる所定の操作で、当該第１の表示モードと第２の表示モードとを切替えることが可能である。

なお、他の実施形態では、上記第１の表示モードと第２の表示モードを併用できるようにしてもよい。また、このとき、第１の表示モードにかかる表示態様と第２の表示モードにかかる表示態様を異ならせて表示するようにしても良い。例えば、フォント色について、通常状態では黒色、第１の表示モードにかかるものは赤色、第２の表示モードにかかるものは青色、というようにして上記第１の表示モードおよび第２の表示モードの双方を併用してもよい。

次に、図９〜図１６を参照して、本実施形態における情報処理システムの動作をより詳細に説明する。まず、本システムで用いられるデータについて説明する。

図９は、サーバ２０のメインメモリ２５に格納されるプログラムおよび情報の一例を示す図である。メインメモリ２５には、サーバ側ＳＮＳ処理プログラム６１、ユーザデータ６２、投稿コンテンツデータ６３、送信データ６４、受信データ６５等が格納される。

サーバ側ＳＮＳ処理プログラム６１は、本実施形態にかかるＳＮＳにおいてサーバ側の機能（ＳＮＳサーバ処理）を実現させるためのプログラムである。具体的には、後述する図１６のフローチャート処理を実行するためのプログラムである。

ユーザデータ６２は、本実施形態におけるＳＮＳの利用ユーザに関する情報を記録したデータである。図１０は、ユーザデータ６２のデータ構成の一例を示す図である。ユーザデータ６２は、ユーザＩＤ６６、アカウント情報データ６７、フレンド関係データ６８、お気に入りユーザデータ６９等を含む。ユーザＩＤ６６は、各ユーザを一意に識別するためのＩＤである。アカウント情報データ６７は、例えば各ユーザのログインＩＤ、パスワード、氏名や年齢、趣味や出身地や出身学校等、各ユーザのアカウントやプロフィール等を示すデータである。フレンド関係データ６８は、当該ユーザとフレンド関係が設定されたユーザを示すためのデータである。

お気に入りユーザデータ６９は、上記図８を用いて説明したような、第２の表示モードにおいて表示態様を変更させるユーザを示すデータである。なお、本実施形態では便宜上「お気に入り」と称しているが、気になるユーザや注目しているユーザ、という程度のものも含む意図である。図１１は、当該お気に入りユーザデータ６９のデータ構造の一例を示す。当該お気に入りユーザデータは、アクション日時７０、アクション内容７１、アクション対象ユーザ７２の３つの項目を有する閲覧アクションレコードの集合からなるテーブル構造のデータである。アクション日時は、そのユーザが閲覧アクションを行った日時を示す。アクション内容７１は、ユーザが行った閲覧アクションの内容を示すデータである。例えば、肯定的評価を示す操作であるか、否定的評価を示す操作であるか、詳細表示を求める操作であるか、等を示すデータである。アクション対象ユーザ７２は、当該ユーザが当該閲覧アクションを行った対象ユーザのユーザＩＤ６６を示す。当該アクション対象ユーザ７２に着目することで、誰に対してどの程度（回数・頻度等）閲覧アクションを行ったかを算出することが可能である。また、これらお気に入りユーザデータ６９の閲覧アクションレコードの数に基づいて、当該投稿コンテンツに対して行われた閲覧アクションの回数を算出することも可能である。そして、例えばこの回数が多いアクション対象ユーザは、閲覧アクションを行ったユーザにとって「親密度」が高いユーザである、あるいは、「興味・関心度」が高いユーザであると判別することが可能である。また、更に、アクション内容７１に着目することで、あるユーザに対して好意的であるか非好意的であるか等を判別することも可能である。例えば、肯定評価が多いか否定評価が多いかで判別可能である。

なお、このテーブル構造は一例であり、上記と同様の内容を示すものであれば、他のテーブルデータ構造であってもよい。

図９に戻り、投稿コンテンツデータ６３は、上述したようなサーバ２０に送信された投稿コンテンツを示すデータである。図１２は、当該投稿コンテンツデータ６３のデータ構成の一例を示す図である。投稿コンテンツデータ６３には複数の投稿コンテンツレコード８１が含まれており、各投稿コンテンツレコード８１、投稿者ＩＤ８２、投稿日時データ８３、投稿内容データ８４、閲覧アクションデータ８５で構成される。その他、図示は省略するが、各投稿コンテンツレコード８１は、自身を一意に特定可能なＩＤも含んでいるものとする。投稿者ＩＤ８２は、その投稿コンテンツを投稿したユーザのユーザＩＤ６６を示す。投稿日時データ８３は、当該投稿コンテンツの投稿日時を示す。投稿内容データ８４は、当該投稿コンテンツの内容を示すデータであり、テキストデータや写真データ等、投稿コンテンツの本体ともいえるデータである。

閲覧アクションデータ８５は、当該投稿コンテンツに対して行われた閲覧アクションを記録したデータである。換言すれば、当該投稿コンテンツに対して行われた閲覧アクションに関する情報を累積したデータともいえる。図１３に、当該閲覧アクションデータ８５のデータ構造の一例を示す。当該データは、アクション日時８７、アクション内容８８、アクション実行ユーザ８９の３つの項目を有する閲覧アクションレコードの集合からなるテーブル構造のデータである（図示は省略するが、各閲覧アクションレコードには一意に識別可能なＩＤが付されているものとする）。アクション日時８７は、閲覧アクションが行われた日時を示す。アクション内容８８は、閲覧アクションの内容を示すデータである。例えば、肯定的評価を示す操作であるか、否定的評価を示す操作であるか、詳細表示を求める操作であるか、等を示すデータである。アクション実行ユーザ８９は、その投稿コンテンツに対して当該閲覧アクションを行ったユーザのユーザＩＤ６６を示す。また、これら閲覧アクションレコードの数に基づいて、当該投稿コンテンツに対して行われた閲覧アクションの回数を算出することも可能である。例えば、アクション内容８８が「肯定評価」であるレコードの数が１０であれば、その投稿コンテンツに対して１０回の「肯定評価」が行われたことになる。また、その他、上述したような「投稿者単位」で表示態様を変化させるような場合は、例えば、投稿者ＩＤ８２毎に閲覧アクションデータ８５に含まれる肯定的評価の数を算出すること等で、その投稿者自身に対する肯定的評価の数を算出すること等も可能である。

図９に戻り、送信データ６４は、端末装置１０に送信するためのデータであり、例えば閲覧ソース等が含まれる。受信データ６５は、端末装置１０から受信したデータであり、例えば投稿にかかるデータや、閲覧リクエストや、端末装置１０で行われた操作内容や閲覧アクションの内容を示すデータ等が含まれる。

次に、端末装置１０で用いられるデータについて説明する。図１４は、端末装置１０のメインメモリ１５に格納されるプログラムおよび情報の一例を示す図である。メインメモリ１５には、端末側ＳＮＳ処理プログラム９１、端末ユーザデータ９２、操作データ９３、送信データ９４、受信データ９５等が格納される。

端末側ＳＮＳ処理プログラム９１は、本実施形態にかかるＳＮＳにおいて端末装置１０側の機能（ＳＮＳクライアント処理）を実現させるためのプログラムである。具体的には、後述する図１５のフローチャート処理を実行するためのプログラムである。

端末ユーザデータ９２は、当該端末装置でＳＮＳ処理を利用しているユーザに関するデータである。例えば、上記ユーザＩＤ６６と同じデータ等、主に、サーバ側で投稿者が誰であるか等を識別するために必要なデータ等が記憶されている。操作データ９３は、端末装置１０に対して行われた各種操作内容を示すデータである。

送信データ９４は、サーバ２０に送信するためのデータである、上記端末ユーザデータ９２や操作データ９３等に基づいて生成され、例えば、自分のユーザＩＤや投稿内容、閲覧リクエスト、閲覧アクションを示すデータ、上記の表示モードの切替を要求するデータ等が含まれる。例えば、送信データ９４は、ヘッダ部とボディ部に分けて構成され、ヘッダ部で、ユーザＩＤと当該送信データの種類（投稿、閲覧リクエスト、閲覧アクション、表示モード変更等）が示され、ボディ部で、その内容（投稿の場合はテキストや写真データ、閲覧アクションの場合は、対象となった投稿コンテンツを示すデータと、その閲覧アクションの内容を示すデータ等）が示される。受信データ９５は、サーバ２０から受信した各種データであり、例えば閲覧ソース等が含まれる。

その他、メインメモリ１５には、端末装置１０の処理で用いられる各種データ（例えば送信前の投稿コンテンツを一時的に記憶しておくためのデータ等）も適宜記憶される。

次に、図１５および図１６のフローチャートを参照して、本実施形態における端末装置１０およびサーバ２０において実行される処理の流れを説明する。

まず、図１５を用いて端末装置１０における処理の詳細について説明する。端末装置１０において、ＳＮＳクライアントの処理の起動操作がユーザによって行われると、まず、ステップＳ１において、準備処理が行われる。この処理では、各種データの初期化が行われる。更に、初期画面を表示するために、所定の閲覧リクエストをサーバ２０に送信し、サーバ２０から閲覧ソースを受信する処理も行われる。そして閲覧用画面を生成し、初期画面として画面に表示する処理も行われる。なお、表示モードに関して、デフォルトでは「第１の表示モード」が選択されているとする。そのため、ここで表示される閲覧用画面も第１の表示モードで表示されるものとする。

次に、ステップＳ２において、プロセッサ１３は、操作データ９３を取得する。続くステップＳ３で、プロセッサ１３は、操作データ９３に基づいて、操作内容が「投稿」の操作であるか否かを判定する。その結果、「投稿」操作であるときは（ステップＳ３でＹＥＳ）、ステップＳ１０において、プロセッサ１３は、投稿者のユーザＩＤや投稿コンテンツ等を含む送信データ９４を生成し、サーバ２０に送信する処理を実行する。

次に、ステップＳ１１において、プロセッサ１３は、所定の閲覧リクエスト（例えば、その時点における最新の投稿を含む閲覧用画面のリクエスト）を送信する。次に、ステップＳ１２で、プロセッサ１３は、サーバ２０から送信された閲覧ソースを受信し、受信データ９５に格納する。そして、プロセッサ１３は、これに基づいて上記のような閲覧用画面を生成して画面に表示する。その後、ステップＳ７の処理へと進む。

一方、上記ステップＳ３の判定の結果、「投稿」操作ではないときは（ステップＳ３でＮＯ）、ステップＳ４において、プロセッサ１３は、操作内容が「閲覧アクション」に該当する操作であるか否かを判定する。その結果、閲覧アクションに該当する操作であるときは（ステップＳ４でＹＥＳ）、ステップＳ８において、プロセッサ１３は、その閲覧アクションの内容を示す送信データ９４を生成し、サーバ２０に送信する処理を実行する。その後（サーバから受信完了の通知等を受けてから）、上記ステップＳ１１に処理を進める。

一方、上記ステップＳ４の判定の結果、「閲覧アクション」操作でもないときは（ステップＳ４でＮＯ）、次に、ステップＳ５において、プロセッサ１３は、表示モードの切替操作が行われたか否かを判定する。その結果、表示モードの切替操作が行われていたときは（ステップＳ５でＹＥＳ）、ステップＳ９において、プロセッサ１３は、その指示内容に応じて、上記第１の表示モードあるいは第２の表示モードのいずれかによる閲覧ソースの要求を示す送信データ９４を生成し、サーバ２０に送信する。その後、上記ステップＳ１２に処理が進められる。

一方、ステップＳ５の判定の結果、表示モードの切替操作も行われていないときは（ステップＳ５でＮＯ）、ステップＳ６において、プロセッサ１３は、当該ＳＮＳ処理におけるその他の処理を適宜実行する。

次に、ステップＳ７において、プロセッサ１３は、処理終了のための条件が満たされたか否か（例えば終了操作が行われたか否か）を判定し、条件が満たされていないときは（ステップＳ７でＮＯ）、上記ステップＳ２に戻り、処理を繰り返す。一方、条件が満たされていれば（ステップＳ７でＹＥＳ）、端末装置１０におけるＳＮＳクライアント処理を終了する。

次に、図１６を用いて、サーバ２０における処理の詳細を説明する。サーバ２０において、ＳＮＳサーバ処理が起動されると、まず、ステップＳ３１において、プロセッサ２３は、準備処理を実行する。この処理では、各種データの初期化が行われる。

次に、ステップＳ３２において、プロセッサ２３は、端末装置１０からの閲覧リクエスト等を待ち受ける処理を実行する。次に、ステップＳ３３において、プロセッサ２３は、端末装置１０からの送信データ９４（閲覧リクエスト等が含まれている）を受信したか否かを判定する。その結果、受信していなければ（ステップＳ３３でＮＯ）、上記ステップＳ３２に戻り、待ち受けを繰り返す。一方、受信していたときは（ステップＳ３３でＹＥＳ）、ステップＳ３４において、プロセッサ２３は、受信データ６５を参照して、受信した送信データ９４の内容（以下、リクエスト内容と呼ぶこともある）を解析する。例えば、受信データ６５のヘッダ部を参照して、送信内容の種類（投稿か閲覧アクションか等）を判別する。

次に、ステップＳ３５において、プロセッサ２３は、端末装置１０からのリクエスト内容が「投稿」であるか否かを判定する。その結果、「投稿」のときは、ステップＳ４０において、プロセッサ２３は、受信データ６５に基づき、これに含まれる投稿コンテンツをその投稿ユーザのユーザＩＤと関連づけて（投稿者ＩＤ８２に投稿ユーザのユーザＩＤ６６を設定する）、投稿コンテンツデータ６３に記録する。その後、上記ステップＳ３２に戻り、処理が繰り返される。

一方、ステップＳ３５の判定の結果、「投稿」ではないときは（ステップＳ３５でＮＯ）、次に、ステップＳ３６において、プロセッサ２３は、端末装置１０からのリクエストの内容が「閲覧アクション」であるか否かを判定する。その結果、「閲覧アクション」のときは、ステップＳ４１において、プロセッサ２３は、受信データ６５に含まれる閲覧アクションの内容を判別する。そして、当該閲覧アクションの対象となった投稿コンテンツレコード８１を投稿コンテンツデータ６３から検索し、その投稿コンテンツレコード８１の閲覧アクションデータ８５に当該閲覧アクションを示す内容を記録する。そして、上記ステップＳ３２に戻り、処理が繰り返される。

一方、ステップＳ３６の判定の結果、「閲覧アクション」でもないときは（ステップＳ３６でＮＯ）、ステップＳ３７において、プロセッサ２３は、端末装置１０からのリクエスト内容が「閲覧ソースの要求」または「表示モードの変更」のいずれかであるか否かを判定する。その結果、「閲覧ソースの要求」または「表示モードの変更」であるときは（ステップＳ３７でＹＥＳ）、ステップＳ４２において、プロセッサ２３は、リクエスト内容に応じた閲覧ソースを生成する処理を実行する。この処理をより具体的に説明すると、「閲覧ソースの要求」である場合は、受信データ６５やユーザデータ６２に基づき、閲覧用画面に含める投稿コンテンツを投稿コンテンツデータ６３から抽出する。例えば、リクエストを送信したユーザの「フレンド」関係や投稿日時に基づいて、投稿コンテンツを抽出する。更に、抽出した投稿コンテンツのそれぞれについて、閲覧アクションデータ８５を参照して、その表示態様を決定する。例えば、閲覧アクションデータ８５に含まれる閲覧アクションレコード数が所定値以上の投稿コンテンツについて、そのフォントサイズや表示領域を大きくすることを決定する。例えば、表示態様変更用のパラメータ（フォントサイズや領域サイズ）を決定する。この表示態様変更用のパラメータについては、予め定められた値としてもよいし、上記閲覧アクションレコード数に応じて大きさも変化するようにしてもよい（閲覧アクションレコード数が多いほどより大きくなる、等）。なお、このパラメータには上限値が予め定められており、この上限値以上はフォントサイズや表示領域は大きくしないものとする。そして、プロセッサ２３は、上記決定された表示態様で（決定されたパラメータに基づいて）投稿コンテンツが一覧表示されるような閲覧ソースを生成する。

なお、本実施形態では、上記のように表示態様を投稿コンテンツ毎に決定するが、他の実施形態では、上記ステップＳ４２の処理において、上述したような「投稿者」単位で表示態様をどのようにするか決定するようにしても良い。例えば、あるユーザにかかる上記閲覧アクションデータ８５に含まれる閲覧アクションレコード数が所定値以上の投稿コンテンツがあり、更に、このような投稿コンテンツの数が所定値以上あれば、これらの投稿コンテンツを投稿したユーザにかかる他の投稿コンテンツ（上記閲覧ソースに含まれるもの）についても表示態様を変更するようにしても良い。

また、リクエスト内容が「表示モードの変更」である場合は、指定された表示モードに応じて表示態様を決定する処理も実行される。すなわち、次のような処理が行われる。第１の表示モードが指定されたときは、上述したような処理で閲覧ソースが生成される。一方、第２の表示モードが指定されたときは、当該リクエストを送信したユーザにかかるお気に入りユーザデータ６９を参照し、表示態様を変更する対象となるユーザを判別する。次に、閲覧用画面に含める投稿コンテンツを投稿コンテンツデータ６３から抽出する。更に、抽出した投稿コンテンツの中に、上記表示態様の変更対象となるユーザによる投稿コンテンツが存在するか否かを判別する。そして、このような投稿コンテンツが存在していれば、そのユーザにかかる投稿コンテンツの表示態様を適宜変更することを決定する。この際、各ユーザに対して行われた閲覧アクションの回数に応じて、例えばフォントサイズの大きさを変更するように決定しても良い。そして、プロセッサ２３は、このように決定された表示態様で表示されるように閲覧ソースを生成する。

次に、ステップＳ４３において、プロセッサ２３は、上記生成した閲覧ソースを含む送信データを生成し、リクエスト元となる端末装置１０に送信する。その後、上記ステップＳ３２に戻り、処理が繰り返される。

次に、上記ステップＳ３７の判定の結果、端末装置１０からのリクエストの内容が「閲覧ソースの要求」または「表示モードの変更」でもないときは（ステップＳ３７でＮＯ）、ステップＳ３８において、プロセッサ２３は、その他の処理を適宜実行する。

次に、ステップＳ３９において、プロセッサ２３は、処理終了のための条件が満たされたか否かを判定し、条件が満たされていないときは（ステップＳ３９でＮＯ）、上記ステップＳ３２に戻り、処理を繰り返す。一方、条件が満たされていれば（ステップＳ３９でＹＥＳ）、サーバ２０におけるＳＮＳサーバ処理を終了する。

このように、本実施形態では、閲覧アクションが行われた投稿コンテンツに対し、その閲覧アクションの回数等に応じて表示態様を変化させて表示する。換言すれば、ユーザがＳＮＳを普段通り利用しているだけで、投稿コンテンツの表示態様が（徐々に）変化していくことになる。これにより、上述の第１の表示モードのように、主に閲覧者とは他のユーザによる閲覧アクションが投稿コンテンツの表示態様に反映された閲覧用画面を閲覧者に提供できる。この結果、閲覧者は、そのときに人気のある投稿コンテンツや高評価である投稿コンテンツ等がどれであるか等を効率的に把握でき、より効率的な閲覧等が可能となる。また、上記第２の表示モードのように、閲覧者自身の閲覧アクションが投稿コンテンツの表示態様に反映された閲覧用画面も提供できる。これにより、閲覧者自身との親密性が高いユーザや、注目しているユーザの投稿コンテンツをより効率的に把握・閲覧することができる。このような、第１の表示モードおよび第２の表示モードのいずれの場合であっても、閲覧者にとって、見たい投稿コンテンツをより効率的に見ることが可能となる。

なお、閲覧アクションに応じた表示態様の変化に関して、上記実施形態では、閲覧アクションレコード数に応じて表示態様の変化内容（フォントの大きさ等）を決める例を示した、この他、当該閲覧アクションレコード数の算出に際して、アクション内容８８を用いてフィルタリングをかけるようにしてもよい。例えば、閲覧アクションの内容が「肯定評価」である閲覧アクションレコードの数を算出するようにしてもよい。つまり、閲覧アクションが「肯定的な評価」であるか「否定的な評価」であるかを考慮して表示態様を変化させるようにしてもよい。一例としては、基本的には、肯定的な評価の回数（「肯定評価」の閲覧アクションレコード数）に応じてフォントサイズが段階的に大きくなるよう設定すると共に、否定的な評価の回数（「否定評価」の閲覧アクションレコード数）に応じて、上記大きくしたフォントサイズを元に戻していくような設定を行うようにしても良い。また、その他、否定評価が多い場合は、デフォルトのフォントサイズよりも小さくなるような設定を行っても良い。更には、否定評価の結果、フォントサイズの変更の他、フォントの色を、ネガティブな印象を想起させるような色に変更するようにしてもよい。

また、表示態様を変化させるか否かの判断材料となる閲覧アクションについて、判断に用いる閲覧アクションに期限的な制限を利用するようにしても良い。例えば、直近１ヶ月の間に行われた閲覧アクションに基づいて表示態様を決定する、等である（これは、例えば上記アクション日時８７に基づいて判定可能である）。これにより、例えば、１年前に投稿された投稿コンテンツがあり、その後、そのユーザが投稿していないような場合に、いつまでもその投稿コンテンツの表示態様が目立ってしまうようなことを防ぐことができる。また、例えば、あるユーザについて３ヶ月前に投稿していた投稿コンテンツについては肯定的評価が多かったが、直近１ヶ月における投稿コンテンツについては否定的な評価が多いような場合等、つまり、以前はその投稿の人気が高かったが最近は人気が低下しているユーザについて、表示態様を変化させずに表示できる。また、これとは逆に、以前はその投稿コンテンツに人気は無かったが、直近において人気が高くなった、あるいは話題になっているような投稿コンテンツ（およびその投稿を行ったユーザ）を表示態様の変化により目立たせることができる。このように、閲覧時点における投稿コンテンツの人気・注目度の「トレンド」を反映した閲覧用画面をユーザに提供することができる。

また、他の実施形態では、投稿者に対する評価について、上記のような投稿コンテンツへの閲覧アクションを介さずに、より直接的に評価できるようにしてもよい。例えば、ユーザＡがユーザＢの投稿コンテンツを閲覧し、これに対する特段の閲覧アクションは行ってはいないものの、ユーザＢの投稿を気に入ったような場合は、ユーザＢを「好きな投稿者（お気に入りユーザ）」として指定・設定できるようにしてもよい。この場合、例えば、ユーザＡが所定の操作を行うことで、上記お気に入りユーザデータ６９にユーザＢを記録できるように構成することが考えられる。これにより、ユーザＡがユーザＢの投稿に対して閲覧アクションを行っていないあるいはその回数が少ないような場合であっても、上記第２の表示モードにおいて、ユーザＢの投稿コンテンツを目立たせて表示させることができる。また、上記第１の表示モードの場合についてもこれを適用するようにしてもよい。例えば、所定人数以上のユーザから「お気に入りユーザ」として設定されたユーザにかかる投稿コンテンツの表示態様を変更するようにしてもよい。また、あるユーザを「好きな投稿者（お気に入りユーザ）」として指定・設定するかどうかという二者択一な評価に基づいて表示態様を変更するだけではなく、その他にも、例えば、ユーザＢに対する評価の度合い（評価値）をユーザＡが設定できるようにし、ユーザＢに対するユーザＡの評価の度合い（評価値）の累積結果に応じて、ユーザＢにかかる投稿コンテンツの表示態様を（一例として、段階的に）変更してもよい。

また、投稿コンテンツの表示態様の変化に加え、当該投稿コンテンツにユーザの注意をひくために、更に音声出力を併用したり、スクロール速度の調整等の画面制御も行うようにしても良い。例えば、端末装置においてユーザが閲覧用画面をスクロール操作して「流し読み」しているような場合を想定する。この場合に、上記表示態様を変化した投稿コンテンツが表示画面内に含まれるタイミングを検出して、このタイミングで所定の音声を発したり、端末装置を振動させたり、スクロール速度を低下、あるいは一時的にスクロールを停止させるような制御を行ってもよい。例えば、音声出力させる場合、サーバ側で上記閲覧ソースデータを生成するとき、「この投稿コンテンツが表示画面内に入ったとき音声を出力する」旨の設定（例えばその旨を示すＨＴＭＬタグやスクリプト等）を、表示態様を変更した投稿コンテンツに対して更に設定しておく。そして、端末装置側では、上記の「音声出力」設定がなされた投稿コンテンツが表示画面内に含まれるタイミングの検出を行い、そのタイミングで端末装置に保存された所定の音声データ（例えば上記閲覧ソースデータと共にサーバから端末装置へ送信された音声データ）を再生し、音声を出力することが考えられる。また、その他、サーバ側では特段の処理は行わずに、端末装置側のみで上記の制御を行うようにしても良い。例えば、端末装置側で、上記「表示態様が変更された投稿コンテンツ」が表示画面内に含まれるタイミングの検出を行い、そのタイミングで所定の音声を出力するようにしてもよい。

また、上述した閲覧アクションデータ８５に関して、上記実施形態では、閲覧アクションレコードの数等に基づいて閲覧アクションが行われた回数を算出する例を示したが、この他、「人気度」や「興味関心度」を示すデータやパラメータを別途記録する構成としてもよい。例えば、アクション内容８８が「肯定評価」である閲覧アクションレコードの数に応じて、「人気度」パラメータを増加させていく。そして、上記第１の表示モードにおける表示態様の変化の決定に際して、この「人気度」パラメータに基づいて表示態様の変化を決定するようにしてもよい。また、例えば、上記お気に入りユーザデータ６９に関して、その内容に基づいて、あるユーザの他のユーザに対する「興味関心度」のパラメータを算出して、記録するようにしてもよい。例えば、肯定評価を行った回数の多い閲覧アクション対象ユーザについて、そのユーザへの「興味関心度」を示すパラメータ値を増加させる、等である。そして、当該「興味関心度」のパラメータに基づいて、上記第２の表示モードにおける表示態様の変化を決定するようにしてもよい。

また、他の実施形態では、更に各ユーザのプロフィール情報に基づいて表示態様を変化させるようにしても良い。例えば、上記第１の表示モードにおいて、表示態様が変更されるコンテンツの投稿ユーザのうち、その閲覧者の（アカウント情報データ６７に記憶されている）「趣味」が共通するユーザの投稿コンテンツについて、更に表示態様を変更するようにしてもよい。例えば、閲覧アクションに応じて表示領域の拡大を行い、趣味が共通するユーザの投稿コンテンツに関しては文字色を変更する、等である。その結果、他の投稿コンテンツに比べて、その表示領域が大きく、かつ、文字色も変更されて表示されている投稿コンテンツについて、その投稿者は閲覧者と趣味が共通していると推測できる。そして、このような趣味の共通性をきっかけに、その投稿者とより親密度を高めるようなことも期待できる。これは、上記第２の表示モードにおいても同様である。また、例えば、プロフィール情報における「趣味」と「出身地」とで、異なる文字色となるよう表示態様を変更してもよい。

また、上記表示態様の変更に関して、その変更内容を閲覧者が指定できるように構成しても良い。例えば、所定の設定画面において、第１の表示モードにおける表示態様の変化を、「表示領域を拡大する」、「フォントサイズを大きくする」、「文字色を変更する」のいずれかを選択可能とする構成にしてもよい。

また、ユーザが投稿コンテンツを投稿するとき、ある程度、その表示態様を当該ユーザが指定できるようにしてもよい。つまり、投稿の時点で、上記通常状態とは異なる表示態様で投稿できるように、ある程度指定可能なように構成しても良い。ここで指定できる表示態様は、上述した処理のような、閲覧アクションに基づく表示態様の変化内容とは異なる内容としておいてもよい。例えば、ユーザは投稿時に文字の色は指定できるが、フォントの大きさの変更は指摘できず、上述したような閲覧アクションに応じて変化させる表示態様については、文字色を変化させることは行わないようにしておき、フォントの大きさを変更することで表示態様を変化させるようにする、等の構成としてもよい。

また、上述の実施形態では、上記のフレンド関係を前提とするようなＳＮＳの場合を例に挙げた。この他、必ずしも上記のフレンド関係は必要の無いサービスにおいても上記のような処理は適用可能である。例えば、ショッピングサイトにおける商品レビューや、動画投稿サービス、コンテンツ投稿掲示板等についても上述のような処理は適用可能である。つまり、上述したような処理を適用することで、投稿コンテンツ（レビューや投稿された動画）に対して行われた閲覧アクションに応じて、当該投稿コンテンツの表示態様を変化させることも可能である。その結果、ユーザにとって、より有用性の高いレビュー（評価の高いレビュワーのレビュー）や人気の高い投稿動画等を効率的に見ることが可能となる。

また、上記実施形態においては、閲覧アクションに関する情報に応じて表示態様を変更して表示する閲覧ソースの生成・送信に関する処理をサーバ２０で処理する例を示した。このサーバ２０での処理に関しては、他の実施形態では、複数の情報処理装置によってサーバシステムが構成され、上記サーバ２０側で実行するべき処理を当該複数の情報処理装置が分担して実行してもよい。

１０ 端末装置
１１ 入力装置
１２ 表示装置
１３ プロセッサ
１４ 内部記憶装置
１５ メインメモリ
１６ 通信部
２０ 端末装置
２３ プロセッサ
２４ 内部記憶装置
２５ メインメモリ
２６ 通信部

Claims (18)

1. ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置であって、
   所定のユーザから投稿されたコンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を記憶する閲覧アクション情報記憶部と、
   通常状態のコンテンツとは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する前記閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する表示態様決定部と、
   前記表示態様決定部で決定された表示態様で前記コンテンツを表示するための閲覧ソースデータを生成する閲覧ソース生成部と、
   を備える、サーバ装置。
2. 前記サーバ装置は、前記閲覧ソースデータを送信する送信部を更に備え、
   前記表示態様決定部は、第１のユーザが行った閲覧アクションに関する情報に基づいて前記表示態様を決定し、
   前記閲覧ソース生成部は、前記第１のユーザが行った閲覧アクションに関する情報に基づいて決定された表示態様で前記第１のユーザとは異なる第２のユーザに閲覧させるコンテンツを表示するための前記閲覧ソースデータを生成し、
   前記送信部は、前記第２のユーザに前記閲覧ソースデータを送信する、請求項１または２に記載のサーバ装置。
3. 前記閲覧アクション情報記憶部は、前記閲覧アクションに関する情報を累積して記憶し、
   前記表示態様決定部は、前記閲覧アクションの累積結果に基づいて前記表示態様を決定する、請求項１に記載のサーバ装置。
4. 前記サーバ装置は、前記閲覧ソースデータを送信する送信部を更に備え、
   前記閲覧アクション情報記憶部は、第１のユーザが他のユーザのコンテンツに対して行った前記閲覧アクションに関する情報を記憶し、
   前記表示態様決定部は、前記第１のユーザが行った前記閲覧アクションに関する情報に基づいて、当該第１のユーザに閲覧させる前記他のユーザが投稿したコンテンツの表示態様を決定し、
   前記閲覧ソース生成部は、第１のユーザが行った前記閲覧アクションに基づいて決定された表示態様で前記コンテンツを表示するための前記閲覧ソースデータを生成し、
   前記送信部は、前記閲覧ソースデータを前記第１ユーザに送信する、請求項１に記載のサーバ装置。
5. 前記表示態様決定部は、前記表示態様の決定を繰り返し実行する、請求項１ないし４のいずれかに記載のサーバ装置。
6. 前記閲覧ソース生成部は、複数の前記コンテンツが表示されるような閲覧ソースデータを生成し、
   前記表示態様決定部は、前記複数のコンテンツについて前記表示態様を個別に決定する、請求項１ないし５のいずれかに記載のサーバ装置。
7. 前記閲覧ソース生成部は、当該閲覧ソースデータに基づいてコンテンツを表示する閲覧用画面において、当該閲覧ソースデータに含まれる各コンテンツはそれぞれその少なくとも一部が表示されるような閲覧ソースデータを生成し、
   前記閲覧アクションとは、前記一部のみが表示されているコンテンツの全体あるいは詳細を表示することを要求する操作である、請求項１ないし６のいずれかに記載のサーバ装置。
8. 前記閲覧ソース生成部は、前記閲覧ソースデータに基づき表示される各コンテンツに対するフィードバックが可能なフィードバックボタンも表示されるように閲覧ソースデータを生成し、
   前記閲覧アクションとは、閲覧しているユーザが前記フィードバックボタンを押した操作である、請求項１ないし６のいずれかに記載のサーバ装置。
9. 前記表示態様決定部は、前記通常状態のコンテンツよりもその表示領域が大きくなるように前記閲覧アクションが行われたコンテンツの表示態様を決定する、請求項１ないし８のいずれかに記載のサーバ装置。
10. 前記閲覧ソース生成部は、前記閲覧ソースデータに基づき表示される各コンテンツが時系列順に表示されるように当該閲覧ソースデータを生成する、請求項１ないし９のいずれかに記載のサーバ装置。
11. 前記サーバは、前記ユーザに関するプロフィール情報を記憶するプロフィール記憶部を更に備え、
    前記表示態様決定部は、前記ユーザ間の前記プロフィール情報を比較した結果、および、前記閲覧アクション情報に基づいて前記表示態様を決定する、請求項１ないし１０のいずれかに記載のサーバ装置。
12. 前記閲覧ソース生成部は、前記閲覧ソースデータを受信した所定の端末装置において、前記表示態様を変更したコンテンツが当該端末装置の画面内に表示される場合に、ユーザの注意をひくための制御であって当該表示態様の変更以外の所定の制御が当該端末装置において更に行われるように当該閲覧ソースデータを生成する、請求項１ないし１１のいずれかに記載のサーバ装置。
13. ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置のコンピュータに実行させる情報処理プログラムであって、
    前記コンピュータを、
    所定のユーザから投稿されたコンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を記憶する閲覧アクション情報記憶手段と、
    通常状態のコンテンツとは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する前記閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する表示態様決定手段と、
    前記表示態様決定手段で決定された表示態様で前記コンテンツを表示するための閲覧ソースデータを生成する閲覧ソース生成手段として機能させる、情報処理プログラム。
14. ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置を制御するための情報処理方法であって、
    所定のユーザから投稿されたコンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を所定の記憶部に記憶する閲覧アクション情報記憶ステップと、
    通常状態のコンテンツとは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する前記閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する表示態様決定ステップと、
    前記表示態様決定ステップで決定された表示態様で前記コンテンツを表示するための閲覧ソースデータを生成する閲覧ソース生成ステップとを備える、情報処理方法。
15. ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバシステムであって、
    所定のユーザから投稿されたコンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を記憶する閲覧アクション情報記憶部と、
    通常状態のコンテンツとは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する前記閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する表示態様決定部と、
    前記表示態様決定手段で決定された表示態様で前記コンテンツを表示するための閲覧ソースデータを生成する閲覧ソース生成部とを備える、サーバシステム。
16. 少なくとも一つのサーバと複数の端末装置とを備え、ユーザによる当該端末装置を用いたコンテンツの投稿および共有が可能な情報処理システムであって、
    前記端末装置は、
    コンテンツを前記サーバに送信する投稿送信部と、
    前記コンテンツを表示するための閲覧画面を表示する要求を示す閲覧要求を前記サーバに送信する閲覧要求送信部と、
    前記コンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を前記サーバに送信する閲覧アクション送信部と、
    前記閲覧画面の基となる閲覧ソースデータをサーバから受信し、これに基づいて閲覧画面を生成して表示する閲覧画面表示部と、を備え、
    前記サーバは、
    所定のユーザから送信された前記コンテンツを受信する投稿コンテンツ受信部と、
    前記閲覧アクション送信部から送信された前記閲覧アクションに関する情報である閲覧アクション情報を記憶する閲覧アクション情報記憶部と、
    通常状態のコンテンツとは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する前記閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する表示態様決定部と、
    前記閲覧要求の受信に応じて、前記表示態様決定部で決定された表示態様で前記コンテンツを表示するための前記閲覧ソースデータを生成する閲覧ソース生成部と、
    前記生成された閲覧ソースデータをその要求元に送信する閲覧ソース送信部とを備える、情報処理システム。
17. 前記閲覧ソース生成部は、前記閲覧画面に複数の前記コンテンツが含まれるよう前記閲覧ソースデータを生成し、
    前記閲覧画面表示部は、前記複数のコンテンツが含まれた閲覧画面を生成して表示し、
    前記閲覧アクション送信部は、前記閲覧画面に含まれるいずれかのコンテンツに対して行われた前記閲覧アクションに関する情報を送信し、
    前記表示態様決定部は、前記送信された前記閲覧アクションに関する情報が前記閲覧アクション記憶部によって記憶された後に行われた閲覧要求に応じて、前記送信された情報に基づいて前記閲覧アクションが行われたコンテンツの表示態様を決定し、
    前記閲覧ソース生成部は、前記閲覧アクションが行われたコンテンツの表示態様を前記表示態様決定部で決定された表示態様に変更した前記閲覧ソースデータを生成し、
    前記閲覧ソース送信部は、前記表示態様が変更された前記コンテンツを含む閲覧ソースデータを、前記閲覧要求を行った端末装置に送信する、請求項１６に記載の情報処理システム。
18. ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置であって、
    所定のユーザがコンテンツを投稿したユーザに対して行った所定の操作である閲覧アクションに関する情報を記憶する閲覧アクション情報記憶部と、
    通常状態のコンテンツとは異なる表示態様となるように、コンテンツを投稿したユーザに対応する前記閲覧アクション情報に基づいて、当該コンテンツを投稿したユーザにかかるコンテンツの表示態様を決定する表示態様決定部と、
    前記表示態様決定部で決定された表示態様で前記コンテンツを表示するための閲覧ソースデータを生成する閲覧ソース生成部と、
    を備える、サーバ装置。

Images