(58)【調査した分野】(Int.Cl.,DB名)
前記閲覧ソース生成部は、当該閲覧ソースデータに基づいてコンテンツを表示する閲覧用画面において、当該閲覧ソースデータに含まれる各コンテンツはそれぞれその少なくとも一部が表示されるような閲覧ソースデータを生成し、
前記閲覧アクションとは、前記一部のみが表示されているコンテンツの全体あるいは詳細を表示することを要求する操作である、請求項1ないし4のいずれかに記載のサーバ装置。
前記閲覧ソース生成部は、前記閲覧ソースデータに基づき表示される各コンテンツに対するフィードバックが可能なフィードバックボタンも表示されるように閲覧ソースデータを生成し、
前記閲覧アクションとは、閲覧しているユーザが前記フィードバックボタンを押した操作である、請求項1ないし6のいずれかに記載のサーバ装置。
前記表示態様決定部は、前記通常状態のコンテンツよりもその表示領域が大きくなるように前記閲覧アクションが行われたコンテンツの表示態様を決定する、請求項1ないし6のいずれかに記載のサーバ装置。
前記閲覧ソース生成部は、前記閲覧ソースデータを受信した所定の端末装置において、前記表示態様を変更したコンテンツが当該端末装置の画面内に表示される場合に、ユーザの注意をひくための制御であって当該表示態様の変更以外の所定の制御が当該端末装置において更に行われるように当該閲覧ソースデータを生成する、請求項1ないし9のいずれかに記載のサーバ装置。
【発明の概要】
【発明が解決しようとする課題】
【0004】
近年の娯楽の多様化等に伴い、あるユーザがSNSのために割ける時間は減少することが考えられる。そのため、携帯情報端末による上記SNSの利用についても、いわゆる「空き時間」や「隙間時間」にSNSを閲覧するというケースが考えられる。このような閲覧の利用状況を考慮すると、より時間をかけずに効率的にSNSを楽しむための仕組みが求められる。
【0005】
また近年では、SNSの利用ユーザが爆発的に増加している傾向がある。そのため、SNSで閲覧する上記投稿等の情報の数も増加する傾向にある。このような情報数の増加は、いわば情報が氾濫する状態であるともいえ、効率的な閲覧の妨げになると考えられる。特に、上記のような携帯情報端末の普及度合いを考えると、このような携帯情報端末でSNSを利用する機会も多い。しかし、携帯情報端末は、一般的にいって、その画面サイズ(表示面積)が(パーソナルコンピュータ等に比較すると)限られたサイズとなっている。上記のように情報が氾濫している状況を考慮すると、このように表示面積が限られている中で、ユーザが見たい情報を効率的に表示することが求められている。
【0006】
それ故に、本発明の目的は、限られた時間、限られた表示面積の中で、ユーザが見たい情報をより効率的にみることができる仕組みを提供できるサーバ装置、情報処理プログラム、情報処理システム、および情報処理方法を提供することである。
【課題を解決するための手段】
【0007】
上記目的を達成するために、例えば以下のような構成例が挙げられる。
【0008】
構成例の一例は、ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置であって、閲覧アクション情報記憶部と、表示態様決定部と、閲覧ソース生成部とを備える。閲覧アクション情報記憶部と、所定のユーザから投稿されたコンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報を記憶する。表示態様決定部と、通常状態のコンテンツの表示態様とは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する前記閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する。閲覧ソース生成部と、表示態様決定部で決定された表示態様で前記コンテンツを表示するための閲覧ソースデータを生成する。
【0009】
上記構成例によれば、例えばスマートフォンの画面等、表示面積が限られた中で、ユーザが見たい情報をより効率的に閲覧できるようにすることが可能である。
【0010】
他の構成例として、サーバ装置は、閲覧ソースデータを送信する送信部を更に備えでもよい。そして、表示態様決定部は、第1のユーザが行った閲覧アクションに関する情報に基づいて表示態様を決定し、閲覧ソース生成部は、第1のユーザが行った閲覧アクションに関する情報に基づいて決定された表示態様で第1のユーザとは異なる第2のユーザに閲覧させるコンテンツを表示するための閲覧ソースデータを生成し、送信部は、第2のユーザに当該閲覧ソースデータを送信するような構成としてもよい。
【0011】
上記構成例によれば、主に他のユーザの閲覧アクションが反映された表示態様で投稿コンテンツを提示することができ、例えば、ある時点で話題になっているコンテンツ等を容易に知ることができる。
【0012】
他の構成例として、閲覧アクション情報記憶部は、閲覧アクションに関する情報を累積して記憶し、表示態様決定部は、閲覧アクションの累積結果に基づいて表示態様を決定するよう構成されていてもよい。
【0013】
上記構成例によれば、例えば、直近数ヶ月において話題となっているコンテンツや、あるコンテンツに対する閲覧アクションの回数等、より多様な視点に基づき所定の投稿コンテンツの表示態様を変化させることができる。
【0014】
他の構成例として、サーバ装置は、閲覧ソースデータを送信する送信部を更に備えでもよい。そして、閲覧アクション情報記憶部は、第1のユーザが他のユーザのコンテンツに対して行った閲覧アクションに関する情報を記憶し、表示態様決定部は、第1のユーザが行った閲覧アクションに関する情報に基づいて、当該第1のユーザに閲覧させる上記他のユーザが投稿したコンテンツの表示態様を決定し、閲覧ソース生成部は、第1のユーザが行った閲覧アクションに基づいて決定された表示態様でコンテンツを表示するための閲覧ソースデータを生成し、送信部は、閲覧ソースデータを当該第1ユーザに送信するような構成としてもよい。
【0015】
上記構成例によれば、主に閲覧者自身の閲覧アクションを表示態様に反映させることができ、自分の興味・関心度の高いユーザや親密度の高いユーザなどの投稿コンテンツを目立たせて提示することができ、閲覧者がみたい情報を効率的に閲覧可能とすることができる。
【0016】
他の構成例として、表示態様決定部は、表示態様の決定を繰り返し実行するように構成しても良い。
【0017】
上記構成例によれば、当該システムをユーザが繰り返し利用することで、ユーザが気付かないうちにコンテンツの表示態様を変化させていくことができる。
【0018】
他の構成例として、閲覧ソース生成部は、複数のコンテンツが表示されるような閲覧ソースデータを生成し、表示態様決定部は、複数のコンテンツについて表示態様を個別に決定するよう構成しても良い。
【0019】
上記構成例によれば、例えば複数のコンテンツが一覧表示されるような画面において、どのコンテンツが話題になっているか等をユーザに把握させやすくすることができる。
【0020】
他の構成例として、閲覧ソース生成部は、当該閲覧ソースに基づいてコンテンツを表示する閲覧用画面において、当該閲覧ソースデータに含まれる各コンテンツはそれぞれその少なくとも一部が表示されるような閲覧ソースデータを生成し、閲覧アクションとは、この一部のみが表示されているコンテンツの全体あるいは詳細を表示することを要求する操作であってもよい。また、閲覧ソース生成部は、閲覧ソースデータに基づき表示される各コンテンツに対するフィードバックが可能なフィードバックボタンも表示されるように閲覧ソースデータを生成し、閲覧アクションとは、閲覧しているユーザがフィードバックボタンを押した操作であってもよい。
【0021】
上記構成例によれば、閲覧者が少なくとも興味・関心を持ったコンテンツに対する操作に基づいて表示態様を変更することができる。
【0022】
他の構成例として、表示態様決定部は、通常状態のコンテンツよりもその表示領域が大きくなるように閲覧アクションが行われたコンテンツの表示態様を決定するように構成されていてもよい。
【0023】
上記構成例によれば、ユーザが見たいコンテンツがどれであるかを直感的に把握させることができる。
【0024】
他の構成例として、閲覧ソース生成部は、閲覧ソースデータに基づき表示される各コンテンツが時系列順に表示されるように当該閲覧ソースデータを生成するように構成されていてもよい。
【0025】
上記構成例によれば、例えば、最近投稿されたコンテンツが何であるか、今何が話題になっているか等を把握しやすくし、ユーザの利便性を高めることができる。
【0026】
他の構成例として、サーバは、ユーザに関するプロフィール情報を記憶するプロフィール記憶部を更に備え、表示態様決定部は、ユーザ間のプロフィール情報を比較した結果、および、閲覧アクション情報に基づいて表示態様を決定するよう構成してもよい。
【0027】
上記構成例によれば、例えば閲覧者と同じ趣味を有するユーザのコンテンツを更に目立たせて表示することが可能となる。
【0028】
他の構成例として、閲覧ソース生成部は、閲覧ソースデータを受信した所定の端末装置において、表示態様を変更したコンテンツが当該端末装置の画面内に表示される場合に、ユーザの注意をひくための制御であって当該表示態様の変更以外の所定の制御が当該端末装置において更に行われるように当該閲覧ソースデータを生成するよう構成しても良い。
【0029】
上記構成例によれば、コンテンツを閲覧しているユーザに対して、表示態様が変化したコンテンツの存在について(例えばスクロール操作の結果画面内に入ってきたとき等)に気付かせやすくすることができる。
【0030】
他の構成例として、少なくとも一つのサーバと複数の端末装置とを備え、ユーザによる当該端末装置を用いたコンテンツの投稿および共有が可能な情報処理システムであって、 前記端末装置は、投稿送信部と、閲覧要求送信部と、閲覧アクション送信部と、閲覧画面表示部と、を備える。投稿送信部は、コンテンツをサーバに送信する。閲覧要求送信部は、コンテンツを表示するための閲覧画面を表示する要求を示す閲覧要求をサーバに送信する。閲覧アクション送信部は、コンテンツを閲覧するユーザが当該コンテンツに対して行った所定の操作である閲覧アクションに関する情報をサーバに送信する。閲覧画面表示部は、閲覧画面の基となる閲覧ソースデータをサーバから受信し、これに基づいて閲覧画面を生成して表示する。また、サーバは、投稿コンテンツ受信部と、閲覧アクション情報記憶部と、表示態様決定部と、閲覧ソース生成部と、閲覧ソース送信部とを備える。投稿コンテンツ受信部は、所定のユーザから送信されたコンテンツを受信する。閲覧アクション情報記憶部は、閲覧アクション送信部から送信された閲覧アクションに関する情報である閲覧アクション情報を記憶する。表示態様決定部は、通常状態のコンテンツとは異なる表示態様となるように、ユーザに閲覧させるコンテンツに対応する閲覧アクション情報に基づいて、当該コンテンツまたは当該コンテンツを投稿したユーザにかかる他のコンテンツの表示態様を決定する。閲覧ソース生成部は、閲覧要求の受信に応じて、表示態様決定部で決定された表示態様でコンテンツを表示するための閲覧ソースデータを生成する。閲覧ソース送信部は、生成された閲覧ソースデータをその要求元に送信する。更には、閲覧ソース生成部は、閲覧画面に複数のコンテンツが含まれるよう閲覧ソースデータを生成し、閲覧画面表示部は、複数のコンテンツが含まれた閲覧画面を生成して表示し、閲覧アクション送信部は、閲覧画面に含まれるいずれかのコンテンツに対して行われた閲覧アクションに関する情報を送信し、表示態様決定部は、送信された閲覧アクションに関する情報が閲覧アクション記憶部によって記憶された後に行われた閲覧要求に応じて、送信された情報に基づいて前記閲覧アクションが行われたコンテンツの表示態様を決定し、閲覧ソース生成部は、閲覧アクションが行われたコンテンツの表示態様を表示態様決定部で決定された表示態様に変更した閲覧ソースデータを生成し、閲覧ソース送信部は、表示態様が変更されたコンテンツを含む閲覧ソースデータを、閲覧要求を行った端末装置に送信するように構成しても良い。
【0031】
上記構成例によれば、例えばスマートフォンの画面等、表示面積が限られた中で、ユーザが見たい情報をより効率的に閲覧できるようにすることが可能である。また、他のユーザの閲覧アクションが反映された表示態様で投稿コンテンツを提示することができ、例えば、ある時点で話題になっているコンテンツ等を容易に知ることができる。
【0032】
他の構成例として、ユーザによるコンテンツの投稿および共有が可能な情報処理システムで用いられるサーバ装置であって、閲覧アクション情報記憶部と、表示態様決定部と、閲覧ソース生成部とを備える。閲覧アクション情報記憶部は、所定のユーザがコンテンツを投稿したユーザに対して行った所定の操作である閲覧アクションに関する情報を記憶する。表示態様決定部は、通常状態のコンテンツとは異なる表示態様となるように、コンテンツを投稿したユーザに対応する閲覧アクション情報に基づいて、当該コンテンツを投稿したユーザにかかるコンテンツの表示態様を決定する。閲覧ソース生成部は、表示態様決定部で決定された表示態様でコンテンツを表示するための閲覧ソースデータを生成する。
【0033】
上記構成例によれば、例えばスマートフォンの画面等、表示面積が限られた中で、ユーザが見たい情報をより効率的に閲覧できるようにすることが可能である。また、他のユーザの閲覧アクションが反映された表示態様で投稿コンテンツを提示することができ、例えば、ある時点で話題になっているコンテンツ等を容易に知ることができる。
【発明の効果】
【0034】
本実施形態によれば、ユーザが見たい情報について、より効率的に閲覧することが可能となる。
【発明を実施するための形態】
【0036】
以下、本発明の一実施形態について説明する。
【0037】
図1は、本実施形態に係る情報処理システムの全体像を示す模式図である。本実施形態の情報処理システムでは、サーバ20と、複数の端末装置10A〜10C(以下では総称して端末装置10と呼ぶこともある)とがネットワーク(例えばインターネット)を介して接続および通信可能に構成される。端末装置は、例えば、スマートフォン、携帯電話、PDA等の携帯型端末装置や、いわゆるタブレット型の情報処理装置等である(但し、他の実施形態では、パーソナルコンピュータ等の端末装置であってもよい)。本実施形態では、このようなシステムにおいて、いわゆるソーシャルネットワーキングサービス(以下、SNS)が実行される場合を想定する。また、本実施形態では、このようなサービスの中でも、特に、コミュニティ型の会員制のサービスを想定する。例えば、その利用のためにユーザ登録が必要となるようなサービスである(サーバ20において、利用ユーザのアカウント情報等が保存されるようなサービス)。そして、各ユーザは所定のコンテンツ(例えば所定のテキスト)を(サーバ20に)「投稿」することができる。以下の説明では、このコンテンツのことを「投稿コンテンツ」と呼ぶ。また、(自分や)他人の投稿コンテンツを「閲覧」することもできる。更に、各投稿コンテンツに対して、所定のアクションを行うことができる。例えば、ある投稿コンテンツに対して、「コメント」をつけたり、肯定的な評価または否定的な評価を示すボタン(いわゆる「いいね!」ボタンや「よくない」ボタン等)を押すというような「フィードバック」を行うことが可能である。以下の説明では、このようなアクションのことを「閲覧アクション」と呼ぶ。
【0038】
なお、本実施形態では、次のような操作についても閲覧アクションとして扱う。例えば、投稿コンテンツの詳細表示を求めるような操作も閲覧アクションとして扱う。これは、初期表示では投稿コンテンツの全文が表示されておらず、最初の1〜2行程度しか表示されていない状態において、例えば「全文表示」ボタンを押す、等の操作である。つまり、ユーザがある投稿コンテンツに着目して行った所定の操作を閲覧アクションとして扱う。また、例えば投稿コンテンツが縦方向に一覧表示されているような画面において、縦方向の画面スクロール操作が行われたときのそのスクロール速度や、投稿コンテンツがどれだけの時間閲覧されたかもここでいう閲覧アクションに含める。例えば、スクロール速度が速い場合は読み飛ばされている状態であり、このような状態でスクロール速度が急に遅くなったりスクロールが停止したりしたような場合は、そのときに画面内に表示されている投稿コンテンツがじっくりと読まれている(注目されている)と考えられる。そのため、このような画面遷移の状態や画面スクロール操作を検出し、これに基づいて投稿コンテンツに注目しているか否かを判定して、投稿コンテンツに注目されていると判定される場合は、その投稿コンテンツに対する上記閲覧アクションが行われたものとして扱う。また、例えば、投稿コンテンツに含まれる画像を拡大する操作や、投稿コンテンツに含まれているハイパーリンクをクリックする操作が行われた場合も上記閲覧アクションが行われたものとして扱う。
【0039】
また、その他、投稿コンテンツそのものが写真やイラスト等の画像であるような場合は、当該画像を拡大表示する操作(例えば当該画像をクリックやタッチすると、別画面や別ウィンドウで当該画像を投稿コンテンツ内で表示されているのよりも大きなサイズで表示するような場合)も上記閲覧アクションが行われたとして扱う。また、この画像に対して上記肯定的評価や否定的評価等のフィードバックが行われた場合も上記閲覧アクションが行われたとして扱う。また、例えば投稿コンテンツが音声や動画データのような場合、例えば投稿コンテンツ内では静止画として表示されている動画データを再生する操作が行われた場合も上記閲覧アクションが行われたとして扱う。また、その他、投稿コンテンツがダウンロード可能なものであり、これをダウンロードするような操作が行われた場合も上記閲覧アクションが行われたとして扱う。
【0040】
また、上記ユーザ間の関係について、例えば「フレンド」という関係が設定されたユーザ同士でのみ上記の閲覧が可能なように構成しても良い。つまり、端末装置側で閲覧する際に、「フレンド」ではないユーザの投稿コンテンツは閲覧できず、「フレンド」関係にあるユーザの投稿コンテンツのみが表示されるような構成としてもよい。ここで、本実施形態における「フレンド」とは、互いに認証した関係であることをいう。例えば、ユーザAが(まだ自分とはフレンドとしての関係が設定されていない)ユーザBに対して「フレンドリクエスト」を送信する。これに対して、ユーザBがこのリクエストを承認することで、初めて両者が「フレンド」であるとして設定される。
【0041】
図2に、端末装置10の機能ブロック図を示す。
図2において、端末装置10は、入力装置11、表示装置12、プロセッサ13、記憶装置14、メインメモリ15、通信部16を備えている。入力装置11は、端末装置10のユーザによって操作され、ユーザの操作に応じた信号を出力する。入力装置11は、例えば、十字スイッチや押しボタンやタッチパネルである。表示装置12は、端末装置10において生成された画像を画面に表示する。表示装置12は、典型的には液晶表示装置である。記憶装置14には、プロセッサ13によって実行されるコンピュータプログラムや当該プログラムで利用される各種データが格納されている。記憶装置14は、例えば、フラッシュEEPROMやハードディスク装置である。メインメモリ15は、コンピュータプログラムや情報を一時的に記憶する。通信部16は、有線、または無線通信によってネットワークと接続し、サーバ20や他の端末装置に所定のデータを送信したり、サーバ20や他の端末装置から所定のデータを受信したりする。
【0042】
図3は、サーバ20の機能ブロック図を示す。
図3において、サーバ20は、プロセッサ23、記憶装置24、メインメモリ25、通信部26を有する。記憶装置24には、プロセッサ23によって実行されるコンピュータプログラムや当該プログラムで利用される各種データが格納されている。記憶装置24は、例えば、ハードディスク装置である。メインメモリ25は、コンピュータプログラムや情報を一時的に記憶する。通信部26は、有線、または無線通信によってネットワークと接続し、他の端末装置との間で所定のデータの送受信を行う。
【0043】
次に、本実施形態にかかる情報処理システムで実行される情報処理(各端末装置10で実行される情報処理)の動作概要を説明する。本実施形態にかかる処理は、概略的に、以下のような動作が行われる。すなわち、ある投稿コンテンツに対して、これを閲覧しているユーザが閲覧アクションを行うと、そのアクションの内容に応じて、投稿コンテンツの表示態様を変化させる、という処理が行われる。ここで、本実施形態における表示態様の変更とは、表示される情報を増加させる、あるいは、強調させる目的で行われるものである。例えば、投稿コンテンツ自体のフォントサイズを大きくすることや、文字の色を変えることや、投稿コンテンツが表示される表示領域の大きさ(面積が増える結果、表示され得る文字数も増加する)を増加させることで表示態様を変化させる。そのため、例えば、投稿コンテンツの表示領域の隅のほうに、コメント件数を示す数値を小さく付するのみで、投稿コンテンツ自体の表示(その表示領域やフォントサイズ)については特に変更されないようなものは、ここでいう表示態様の変化には含まれない。以下の説明では、フォントサイズを大きくし、かつ、表示領域を大きくする場合を当該「表示態様の変更」の例として説明する。例えば、ある投稿コンテンツに対して、肯定的な評価が所定数以上行われた場合は、その投稿コンテンツを含む閲覧画面において、当該投稿コンテンツのフォントサイズ及びその表示領域をその他の投稿コンテンツよりも大きくして表示されるようにすることで、高評価の投稿コンテンツを目立たせることができる。
図4は、上記の閲覧アクションが行われる前の閲覧画面の一例である。
図4では、ユーザA〜ユーザDにかかる4つの投稿コンテンツ51A〜51Dが示されている(なお、図示は省略しているが、上記フィードバックを行うためのボタンや、詳細表示を行うためのボタンも適宜表示されているものとする)。また、
図5は、閲覧アクションに応じて表示態様が変化した投稿コンテンツを含む閲覧画面の一例である。
図5では、
図4におけるユーザBの投稿コンテンツ51Bに対して、肯定的な評価を示す操作が所定回数以上行われた場合の画面例である。
図5においては、投稿コンテンツ51Bのフォントサイズおよび表示領域が他の投稿コンテンツ51A、51C、51Dよりも大きなサイズで表示されている。
【0044】
また、その他、投稿コンテンツが写真やイラストなどの画像であるような場合は、その他の画像よりも大きなサイズで表示したり、当該画像を色枠で囲うことで強調表示したりすることで表示態様を変化させてもよい。
【0045】
なお、以下の説明では、
図4における投稿コンテンツ51A〜Dや、
図5における投稿コンテンツ51A、51Cおよび51Dのように、表示態様が変化させられていない状態を「通常状態」と称し、表示態様を変化させずに表示することを「通常状態で表示」のように称する。換言すれば、システム的にデフォルトとして設定されている表示態様のことをここでは「通常状態」と呼ぶ。例えば、フォントの色を例にすると、通常状態(デフォルト色)は黒色であり、閲覧アクションに応じて表示態様が変更された場合は青色にする、等である。
【0046】
次に、
図6を用いて、上述した動作概要をより具体的に説明する。
図6は、本実施形態にかかる処理の動作概要を説明するための図である。
図6では、ユーザAが操作する端末装置Aと、ユーザBが操作する端末装置Bと、ユーザCが操作する端末装置Cと、サーバとでそれぞれ行われる操作や処理について、縦軸方向に時系列順に並べて示したものである。なお、ユーザA、ユーザB、およびユーザCは互いに「フレンド」であると設定されているものとする。
【0047】
図6において、まず、ユーザAが端末装置Aを操作して所定のテキストを入力し、投稿コンテンツとしてサーバに送信(投稿)する(P1)。ここで、本実施形態では、説明の便宜上、投稿コンテンツの内容はテキストであるとするが、他の実施形態では、投稿コンテンツは例えば写真や音声、動画であってもよいし、これらの組み合わせであってもよい(例えば、テキストと写真の組み合わせでも良い)。
【0048】
サーバでは、上記の投稿コンテンツを受信し、当該投稿をユーザAと関連づけて所定の記録媒体に記録する(P2)。なお、図示は省略するが、ユーザA以外のユーザからも適宜投稿コンテンツが送信され、サーバに記録されているものとする。
【0049】
なお、他の実施形態では、サーバにおいて、上記受信した投稿コンテンツをその投稿ユーザとは関連づけず、当該投稿コンテンツのみを記録するようにしても良い。
【0050】
その後、ユーザBの操作に基づいて端末装置10Bが、複数の投稿コンテンツの一覧表示を要求するための閲覧リクエストをサーバに送信する(P3)。例えば、端末装置BにおいてSNSアプリが起動されたときに、「最近」の投稿(閲覧リクエストのあった時点から過去所定期間内の投稿)をサーバに要求する処理等が実行されることで、この閲覧リクエストが送信される。なお、説明の便宜のため、ここではこの「最近」の投稿の中に上記のユーザAの投稿コンテンツが含まれているとする。
【0051】
サーバでは、端末装置Bからの閲覧リクエストを受信し、これに応じて、端末装置Bにおいて表示される閲覧用画面の基となるデータ、すなわち閲覧ソースを生成する(P4)。すなわち、閲覧リクエストを送ったユーザのフレンド関係を参酌しながらサーバに記録されている所定の投稿コンテンツのデータ(典型的には、複数の投稿コンテンツである)を読み出す。換言すれば、閲覧リクエストを送ったユーザとフレンド関係が設定されているユーザにかかる投稿コンテンツを抽出する。そして、これらの投稿コンテンツが、例えば投稿日等の時系列でソートされて一覧表示されるような閲覧用画面の素になるデータ、例えば、HTML等のマークアップ言語で記述されるデータを生成する。また、この際、必要に応じて所定の投稿コンテンツの表示態様が上記通常状態とは異なるようにして閲覧ソースを作成する処理も行われるが、これについては後述する。なお、説明の便宜上、この時点では、投稿コンテンツの表示態様の変化はまだ行われていないものとする(通常状態での表示)。
【0052】
次にサーバは、上記閲覧ソースを端末装置Bに送信する(P5)。これに応じて、端末装置Bでは、当該閲覧ソースを受信し、これに基づいて閲覧用画面(例えば上記
図4参照)を生成して画面に表示する(P6)。例えば、端末装置01Bは、上記閲覧ソース(例えばHTML等のマークアップ言語で記述されたデータ)をレンダリングすることで閲覧用画面を生成して表示する。
【0053】
次に、ユーザBがこの閲覧用画面に対して閲覧アクションを行ったとする(P7)。例えば、ユーザAの投稿コンテンツに対して、肯定的な評価を示す操作(「いいね!」ボタンを押す等)を行ったとする。この場合、その操作内容がサーバに送信される。サーバでは、この操作内容を受信し、当該操作内容に関するデータを対象となった投稿コンテンツ(この場合は上記のユーザAの投稿コンテンツ)に関連づけて記録する(P8)。なお、本実施形態では、このような閲覧アクションを示すデータを累積して記憶する。
【0054】
その後、別の端末装置Cから、閲覧リクエストがサーバに送信されたとする(P9)。なお、この閲覧リクエストにも上記ユーザAの投稿コンテンツが含まれているとする。サーバは、当該閲覧リクエストに応じて閲覧ソースの作成を行う(P10)。この際、上記閲覧アクションを反映して投稿コンテンツの表示態様を上記通常状態と異ならせる(変更する)。例えば、フォントサイズおよび表示領域が通常状態より大きくなるように変更する。また、表示態様を変化させるか否かの決定や変化させる内容について、上記閲覧アクションの累積値に基づいて決定するようにしてもよい。例えば、上記の肯定的な評価を示す操作が所定回数以上行われていれば、表示態様を変更すると決定してもよい。また、その回数に応じて、例えばフォントサイズの大きさを段階的に変更するようにしてもよい。
【0055】
そして、上記のように表示態様が変更されるよう設定された閲覧ソースが作成されると、閲覧リクエストを送ってきた端末装置Cに当該閲覧用ソースが送信される(P11)。当該閲覧用ソースを受信した端末装置Cは、当該閲覧用ソースに基づいて閲覧用画面を生成し、画面に表示する(P12)。その結果、例えば上記
図5で示したような、(肯定的評価の閲覧アクションが行われた)投稿コンテンツのフォントサイズおよび表示領域が大きく表示された閲覧用画面が表示される。
【0056】
このように、あるユーザの投稿コンテンツに対して閲覧アクションが行われると、その後、所定の端末で閲覧用画面が表示される際、当該投稿コンテンツの表示態様が(閲覧アクションの内容に応じて)変更されて表示される。つまり、(主に)他人の閲覧アクションが表示態様の変化に反映されることになる。例えば、肯定的な評価を示す閲覧アクションが所定回数以上行われたときに表示態様を変更する場合を想定する。
図7に、このような流れの模式図を示す。
図7では、ユーザBの投稿コンテンツに対して肯定的評価が所定回数以上行われた場合を示している。この場合、閲覧用画面が表示された時点において、例えば人気のある投稿コンテンツや、好意的・肯定的な閲覧アクションがよく返されている投稿コンテンツが他の投稿コンテンツよりも目立つように表示される。そのため、閲覧するユーザにとって、どの投稿コンテンツが人気が高いか等(つまり、人気度、話題度、流行度)を視覚的に把握しやすくなる。その結果、ユーザにとって必要な情報や所望する情報(投稿)を拾いやすくすることができ、閲覧に際してのユーザの利便性、効率性を高めることができる。
【0057】
また、
図7の例では、ユーザA等が直接的に閲覧アクションを返した投稿コンテンツの表示態様が変更された例を挙げている。すなわち、「投稿コンテンツ」単位で表示態様が変更される場合を例に挙げているが、他の実施形態では、例えば
図7で示したもの以外のユーザBの投稿コンテンツについても一律に表示態様が変更されるようにしてもよい。つまり、「投稿者」単位で表示態様の変更を行うようにしても良い。例えば、ユーザBが投稿した複数の投稿コンテンツのうち、肯定的評価が所定数以上行われた投稿コンテンツが所定数以上あれば、ユーザBにかかる投稿コンテンツの全てについてその変更態様を変更するようにしてもよい。例えば、ユーザBが10の投稿コンテンツを投稿しているとする。そして、このうち肯定的評価が20回以上行われた投稿コンテンツが6つ以上であれば、ユーザBにかかる投稿コンテンツは全て(過去に投稿した分、および、今後投稿される分の双方を含めて)、表示態様を変更するようにしてもよい。また、別の例として、ユーザBの全ての投稿コンテンツを対象として、例えば肯定的評価の合計数が所定値以上であれば、ユーザBにかかる投稿コンテンツの全てについて表示態様を変更するようにしても良い。例えば、ユーザBが10の投稿コンテンツを投稿しており、これらに対する肯定的評価の合計回数が60以上であれば(つまり、どの投稿コンテンツに肯定的評価がなされているかに関わらず60回以上の肯定的評価が行われていれば)、ユーザBの投稿コンテンツについては全て表示態様を変更するようにしても良い。また、更には、ユーザBの投稿コンテンツの内、例えば過去3ヶ月分を対象にして上記のような判定を行うようにしても良い。つまり、肯定的評価の回数等を評価する期間を限定した上で上記のような判定を行っても良い。
【0058】
また、本実施形態では、閲覧アクションを行ったユーザ自身に着目した処理として、次のような処理も実行される。例えば、あるユーザが「他のユーザ」の投稿コンテンツに対して行った閲覧アクションに応じ、当該他のユーザのその他の投稿全般の表示態様を変化させて当該あるユーザに対して表示するという処理も行われる。いわば、このような「他のユーザ」を、あるユーザが気になったユーザや注目しているユーザ(以下では、便宜上「お気に入り」ユーザと呼ぶ)であるとして記憶しておき、当該他のユーザの投稿全般について表示態様を変化させて当該あるユーザに対して表示するというような処理である。つまり、ユーザ自身が過去に行った閲覧アクションを表示態様の変化に反映させるものである。
図8は、このような処理の例を示す模式図である。例えば、ユーザAが自己の端末装置Aで閲覧用画面を表示し、この画面では、ユーザC,B,F,Dの投稿コンテンツが時系列(投稿日時の新しい順)で表示されていたとする。そして、ユーザAは、ユーザBおよびDの投稿コンテンツに対して肯定的な評価を示す閲覧アクションを行ったとする。この場合、ユーザAが肯定的な評価を行ったユーザが誰であるかを示す情報(この場合はユーザBおよびDを示す情報)がユーザAに関連づけられてサーバ20に記憶される。そして、ユーザAがその後に閲覧用画面の表示を要求したとき、その画面にユーザDあるいはユーザBの投稿コンテンツが含まれる場合は、サーバ20において、その表示態様を変化させて表示する閲覧ソースが生成され、送信処理が行われる。その結果、上記閲覧アクションが直接的に行われた投稿コンテンツに限らず、その後に投稿された投稿コンテンツも含めて、ユーザBやユーザDの投稿コンテンツであれば一律に表示態様を変化させる処理が行われる。これにより、例えばユーザAにとって、親密度の高いユーザ(例えば家族や恋人等)や、(親密ではないが)興味や関心の高いユーザの投稿を目立たせて表示することができる。そのため、各ユーザ自身の好み等に応じた閲覧用画面を提供でき、その閲覧性や利便性を高めることができる。
【0059】
また、閲覧アクションが所定回数以上行われた場合に表示態様を変化させるようにすれば、自らが閲覧アクションを何度も行っているようなユーザは親密度が高い、あるいは、興味関心度が高いユーザと考えられる。例えば、ユーザAが(親密ではない)ユーザBのコンテンツに対して閲覧アクションを何度も行った場合を想定する。この場合に、当初は、ユーザAはユーザBに対して意識的には興味を持っておらず、軽い気持ちで閲覧アクションを行っていたとしても、何度か閲覧アクションを行った結果、ユーザBのコンテンツの表示態様が変化することで、ユーザAがユーザBに関心を持っていたことに事後的に気付かせることも可能となる。
【0060】
以下の説明では、端末装置10において、上述した
図7のような、主に他のユーザの閲覧アクションに基づいて表示態様を変更した閲覧用画面を表示する場合を「第1の表示モード」と呼ぶ。一方、上述の
図8を用いて示したような、ユーザ自身の閲覧アクションに基づいて表示態様を変更した閲覧用画面を表示する場合を「第2の表示モード」と呼ぶ。そして、本実施形態では、ユーザによる所定の操作で、当該第1の表示モードと第2の表示モードとを切替えることが可能である。
【0061】
なお、他の実施形態では、上記第1の表示モードと第2の表示モードを併用できるようにしてもよい。また、このとき、第1の表示モードにかかる表示態様と第2の表示モードにかかる表示態様を異ならせて表示するようにしても良い。例えば、フォント色について、通常状態では黒色、第1の表示モードにかかるものは赤色、第2の表示モードにかかるものは青色、というようにして上記第1の表示モードおよび第2の表示モードの双方を併用してもよい。
【0062】
次に、
図9〜
図16を参照して、本実施形態における情報処理システムの動作をより詳細に説明する。まず、本システムで用いられるデータについて説明する。
【0063】
図9は、サーバ20のメインメモリ25に格納されるプログラムおよび情報の一例を示す図である。メインメモリ25には、サーバ側SNS処理プログラム61、ユーザデータ62、投稿コンテンツデータ63、送信データ64、受信データ65等が格納される。
【0064】
サーバ側SNS処理プログラム61は、本実施形態にかかるSNSにおいてサーバ側の機能(SNSサーバ処理)を実現させるためのプログラムである。具体的には、後述する
図16のフローチャート処理を実行するためのプログラムである。
【0065】
ユーザデータ62は、本実施形態におけるSNSの利用ユーザに関する情報を記録したデータである。
図10は、ユーザデータ62のデータ構成の一例を示す図である。ユーザデータ62は、ユーザID66、アカウント情報データ67、フレンド関係データ68、お気に入りユーザデータ69等を含む。ユーザID66は、各ユーザを一意に識別するためのIDである。アカウント情報データ67は、例えば各ユーザのログインID、パスワード、氏名や年齢、趣味や出身地や出身学校等、各ユーザのアカウントやプロフィール等を示すデータである。フレンド関係データ68は、当該ユーザとフレンド関係が設定されたユーザを示すためのデータである。
【0066】
お気に入りユーザデータ69は、上記
図8を用いて説明したような、第2の表示モードにおいて表示態様を変更させるユーザを示すデータである。なお、本実施形態では便宜上「お気に入り」と称しているが、気になるユーザや注目しているユーザ、という程度のものも含む意図である。
図11は、当該お気に入りユーザデータ69のデータ構造の一例を示す。当該お気に入りユーザデータは、アクション日時70、アクション内容71、アクション対象ユーザ72の3つの項目を有する閲覧アクションレコードの集合からなるテーブル構造のデータである。アクション日時は、そのユーザが閲覧アクションを行った日時を示す。アクション内容71は、ユーザが行った閲覧アクションの内容を示すデータである。例えば、肯定的評価を示す操作であるか、否定的評価を示す操作であるか、詳細表示を求める操作であるか、等を示すデータである。アクション対象ユーザ72は、当該ユーザが当該閲覧アクションを行った対象ユーザのユーザID66を示す。当該アクション対象ユーザ72に着目することで、誰に対してどの程度(回数・頻度等)閲覧アクションを行ったかを算出することが可能である。また、これらお気に入りユーザデータ69の閲覧アクションレコードの数に基づいて、当該投稿コンテンツに対して行われた閲覧アクションの回数を算出することも可能である。そして、例えばこの回数が多いアクション対象ユーザは、閲覧アクションを行ったユーザにとって「親密度」が高いユーザである、あるいは、「興味・関心度」が高いユーザであると判別することが可能である。また、更に、アクション内容71に着目することで、あるユーザに対して好意的であるか非好意的であるか等を判別することも可能である。例えば、肯定評価が多いか否定評価が多いかで判別可能である。
【0067】
なお、このテーブル構造は一例であり、上記と同様の内容を示すものであれば、他のテーブルデータ構造であってもよい。
【0068】
図9に戻り、投稿コンテンツデータ63は、上述したようなサーバ20に送信された投稿コンテンツを示すデータである。
図12は、当該投稿コンテンツデータ63のデータ構成の一例を示す図である。投稿コンテンツデータ63には複数の投稿コンテンツレコード81が含まれており、各投稿コンテンツレコード81、投稿者ID82、投稿日時データ83、投稿内容データ84、閲覧アクションデータ85で構成される。その他、図示は省略するが、各投稿コンテンツレコード81は、自身を一意に特定可能なIDも含んでいるものとする。投稿者ID82は、その投稿コンテンツを投稿したユーザのユーザID66を示す。投稿日時データ83は、当該投稿コンテンツの投稿日時を示す。投稿内容データ84は、当該投稿コンテンツの内容を示すデータであり、テキストデータや写真データ等、投稿コンテンツの本体ともいえるデータである。
【0069】
閲覧アクションデータ85は、当該投稿コンテンツに対して行われた閲覧アクションを記録したデータである。換言すれば、当該投稿コンテンツに対して行われた閲覧アクションに関する情報を累積したデータともいえる。
図13に、当該閲覧アクションデータ85のデータ構造の一例を示す。当該データは、アクション日時87、アクション内容88、アクション実行ユーザ89の3つの項目を有する閲覧アクションレコードの集合からなるテーブル構造のデータである(図示は省略するが、各閲覧アクションレコードには一意に識別可能なIDが付されているものとする)。アクション日時87は、閲覧アクションが行われた日時を示す。アクション内容88は、閲覧アクションの内容を示すデータである。例えば、肯定的評価を示す操作であるか、否定的評価を示す操作であるか、詳細表示を求める操作であるか、等を示すデータである。アクション実行ユーザ89は、その投稿コンテンツに対して当該閲覧アクションを行ったユーザのユーザID66を示す。また、これら閲覧アクションレコードの数に基づいて、当該投稿コンテンツに対して行われた閲覧アクションの回数を算出することも可能である。例えば、アクション内容88が「肯定評価」であるレコードの数が10であれば、その投稿コンテンツに対して10回の「肯定評価」が行われたことになる。また、その他、上述したような「投稿者単位」で表示態様を変化させるような場合は、例えば、投稿者ID82毎に閲覧アクションデータ85に含まれる肯定的評価の数を算出すること等で、その投稿者自身に対する肯定的評価の数を算出すること等も可能である。
【0070】
図9に戻り、送信データ64は、端末装置10に送信するためのデータであり、例えば閲覧ソース等が含まれる。受信データ65は、端末装置10から受信したデータであり、例えば投稿にかかるデータや、閲覧リクエストや、端末装置10で行われた操作内容や閲覧アクションの内容を示すデータ等が含まれる。
【0071】
次に、端末装置10で用いられるデータについて説明する。
図14は、端末装置10のメインメモリ15に格納されるプログラムおよび情報の一例を示す図である。メインメモリ15には、端末側SNS処理プログラム91、端末ユーザデータ92、操作データ93、送信データ94、受信データ95等が格納される。
【0072】
端末側SNS処理プログラム91は、本実施形態にかかるSNSにおいて端末装置10側の機能(SNSクライアント処理)を実現させるためのプログラムである。具体的には、後述する
図15のフローチャート処理を実行するためのプログラムである。
【0073】
端末ユーザデータ92は、当該端末装置でSNS処理を利用しているユーザに関するデータである。例えば、上記ユーザID66と同じデータ等、主に、サーバ側で投稿者が誰であるか等を識別するために必要なデータ等が記憶されている。操作データ93は、端末装置10に対して行われた各種操作内容を示すデータである。
【0074】
送信データ94は、サーバ20に送信するためのデータである、上記端末ユーザデータ92や操作データ93等に基づいて生成され、例えば、自分のユーザIDや投稿内容、閲覧リクエスト、閲覧アクションを示すデータ、上記の表示モードの切替を要求するデータ等が含まれる。例えば、送信データ94は、ヘッダ部とボディ部に分けて構成され、ヘッダ部で、ユーザIDと当該送信データの種類(投稿、閲覧リクエスト、閲覧アクション、表示モード変更等)が示され、ボディ部で、その内容(投稿の場合はテキストや写真データ、閲覧アクションの場合は、対象となった投稿コンテンツを示すデータと、その閲覧アクションの内容を示すデータ等)が示される。受信データ95は、サーバ20から受信した各種データであり、例えば閲覧ソース等が含まれる。
【0075】
その他、メインメモリ15には、端末装置10の処理で用いられる各種データ(例えば送信前の投稿コンテンツを一時的に記憶しておくためのデータ等)も適宜記憶される。
【0076】
次に、
図15および
図16のフローチャートを参照して、本実施形態における端末装置10およびサーバ20において実行される処理の流れを説明する。
【0077】
まず、
図15を用いて端末装置10における処理の詳細について説明する。端末装置10において、SNSクライアントの処理の起動操作がユーザによって行われると、まず、ステップS1において、準備処理が行われる。この処理では、各種データの初期化が行われる。更に、初期画面を表示するために、所定の閲覧リクエストをサーバ20に送信し、サーバ20から閲覧ソースを受信する処理も行われる。そして閲覧用画面を生成し、初期画面として画面に表示する処理も行われる。なお、表示モードに関して、デフォルトでは「第1の表示モード」が選択されているとする。そのため、ここで表示される閲覧用画面も第1の表示モードで表示されるものとする。
【0078】
次に、ステップS2において、プロセッサ13は、操作データ93を取得する。続くステップS3で、プロセッサ13は、操作データ93に基づいて、操作内容が「投稿」の操作であるか否かを判定する。その結果、「投稿」操作であるときは(ステップS3でYES)、ステップS10において、プロセッサ13は、投稿者のユーザIDや投稿コンテンツ等を含む送信データ94を生成し、サーバ20に送信する処理を実行する。
【0079】
次に、ステップS11において、プロセッサ13は、所定の閲覧リクエスト(例えば、その時点における最新の投稿を含む閲覧用画面のリクエスト)を送信する。次に、ステップS12で、プロセッサ13は、サーバ20から送信された閲覧ソースを受信し、受信データ95に格納する。そして、プロセッサ13は、これに基づいて上記のような閲覧用画面を生成して画面に表示する。その後、ステップS7の処理へと進む。
【0080】
一方、上記ステップS3の判定の結果、「投稿」操作ではないときは(ステップS3でNO)、ステップS4において、プロセッサ13は、操作内容が「閲覧アクション」に該当する操作であるか否かを判定する。その結果、閲覧アクションに該当する操作であるときは(ステップS4でYES)、ステップS8において、プロセッサ13は、その閲覧アクションの内容を示す送信データ94を生成し、サーバ20に送信する処理を実行する。その後(サーバから受信完了の通知等を受けてから)、上記ステップS11に処理を進める。
【0081】
一方、上記ステップS4の判定の結果、「閲覧アクション」操作でもないときは(ステップS4でNO)、次に、ステップS5において、プロセッサ13は、表示モードの切替操作が行われたか否かを判定する。その結果、表示モードの切替操作が行われていたときは(ステップS5でYES)、ステップS9において、プロセッサ13は、その指示内容に応じて、上記第1の表示モードあるいは第2の表示モードのいずれかによる閲覧ソースの要求を示す送信データ94を生成し、サーバ20に送信する。その後、上記ステップS12に処理が進められる。
【0082】
一方、ステップS5の判定の結果、表示モードの切替操作も行われていないときは(ステップS5でNO)、ステップS6において、プロセッサ13は、当該SNS処理におけるその他の処理を適宜実行する。
【0083】
次に、ステップS7において、プロセッサ13は、処理終了のための条件が満たされたか否か(例えば終了操作が行われたか否か)を判定し、条件が満たされていないときは(ステップS7でNO)、上記ステップS2に戻り、処理を繰り返す。一方、条件が満たされていれば(ステップS7でYES)、端末装置10におけるSNSクライアント処理を終了する。
【0084】
次に、
図16を用いて、サーバ20における処理の詳細を説明する。サーバ20において、SNSサーバ処理が起動されると、まず、ステップS31において、プロセッサ23は、準備処理を実行する。この処理では、各種データの初期化が行われる。
【0085】
次に、ステップS32において、プロセッサ23は、端末装置10からの閲覧リクエスト等を待ち受ける処理を実行する。次に、ステップS33において、プロセッサ23は、端末装置10からの送信データ94(閲覧リクエスト等が含まれている)を受信したか否かを判定する。その結果、受信していなければ(ステップS33でNO)、上記ステップS32に戻り、待ち受けを繰り返す。一方、受信していたときは(ステップS33でYES)、ステップS34において、プロセッサ23は、受信データ65を参照して、受信した送信データ94の内容(以下、リクエスト内容と呼ぶこともある)を解析する。例えば、受信データ65のヘッダ部を参照して、送信内容の種類(投稿か閲覧アクションか等)を判別する。
【0086】
次に、ステップS35において、プロセッサ23は、端末装置10からのリクエスト内容が「投稿」であるか否かを判定する。その結果、「投稿」のときは、ステップS40において、プロセッサ23は、受信データ65に基づき、これに含まれる投稿コンテンツをその投稿ユーザのユーザIDと関連づけて(投稿者ID82に投稿ユーザのユーザID66を設定する)、投稿コンテンツデータ63に記録する。その後、上記ステップS32に戻り、処理が繰り返される。
【0087】
一方、ステップS35の判定の結果、「投稿」ではないときは(ステップS35でNO)、次に、ステップS36において、プロセッサ23は、端末装置10からのリクエストの内容が「閲覧アクション」であるか否かを判定する。その結果、「閲覧アクション」のときは、ステップS41において、プロセッサ23は、受信データ65に含まれる閲覧アクションの内容を判別する。そして、当該閲覧アクションの対象となった投稿コンテンツレコード81を投稿コンテンツデータ63から検索し、その投稿コンテンツレコード81の閲覧アクションデータ85に当該閲覧アクションを示す内容を記録する。そして、上記ステップS32に戻り、処理が繰り返される。
【0088】
一方、ステップS36の判定の結果、「閲覧アクション」でもないときは(ステップS36でNO)、ステップS37において、プロセッサ23は、端末装置10からのリクエスト内容が「閲覧ソースの要求」または「表示モードの変更」のいずれかであるか否かを判定する。その結果、「閲覧ソースの要求」または「表示モードの変更」であるときは(ステップS37でYES)、ステップS42において、プロセッサ23は、リクエスト内容に応じた閲覧ソースを生成する処理を実行する。この処理をより具体的に説明すると、「閲覧ソースの要求」である場合は、受信データ65やユーザデータ62に基づき、閲覧用画面に含める投稿コンテンツを投稿コンテンツデータ63から抽出する。例えば、リクエストを送信したユーザの「フレンド」関係や投稿日時に基づいて、投稿コンテンツを抽出する。更に、抽出した投稿コンテンツのそれぞれについて、閲覧アクションデータ85を参照して、その表示態様を決定する。例えば、閲覧アクションデータ85に含まれる閲覧アクションレコード数が所定値以上の投稿コンテンツについて、そのフォントサイズや表示領域を大きくすることを決定する。例えば、表示態様変更用のパラメータ(フォントサイズや領域サイズ)を決定する。この表示態様変更用のパラメータについては、予め定められた値としてもよいし、上記閲覧アクションレコード数に応じて大きさも変化するようにしてもよい(閲覧アクションレコード数が多いほどより大きくなる、等)。なお、このパラメータには上限値が予め定められており、この上限値以上はフォントサイズや表示領域は大きくしないものとする。そして、プロセッサ23は、上記決定された表示態様で(決定されたパラメータに基づいて)投稿コンテンツが一覧表示されるような閲覧ソースを生成する。
【0089】
なお、本実施形態では、上記のように表示態様を投稿コンテンツ毎に決定するが、他の実施形態では、上記ステップS42の処理において、上述したような「投稿者」単位で表示態様をどのようにするか決定するようにしても良い。例えば、あるユーザにかかる上記閲覧アクションデータ85に含まれる閲覧アクションレコード数が所定値以上の投稿コンテンツがあり、更に、このような投稿コンテンツの数が所定値以上あれば、これらの投稿コンテンツを投稿したユーザにかかる他の投稿コンテンツ(上記閲覧ソースに含まれるもの)についても表示態様を変更するようにしても良い。
【0090】
また、リクエスト内容が「表示モードの変更」である場合は、指定された表示モードに応じて表示態様を決定する処理も実行される。すなわち、次のような処理が行われる。第1の表示モードが指定されたときは、上述したような処理で閲覧ソースが生成される。一方、第2の表示モードが指定されたときは、当該リクエストを送信したユーザにかかるお気に入りユーザデータ69を参照し、表示態様を変更する対象となるユーザを判別する。次に、閲覧用画面に含める投稿コンテンツを投稿コンテンツデータ63から抽出する。更に、抽出した投稿コンテンツの中に、上記表示態様の変更対象となるユーザによる投稿コンテンツが存在するか否かを判別する。そして、このような投稿コンテンツが存在していれば、そのユーザにかかる投稿コンテンツの表示態様を適宜変更することを決定する。この際、各ユーザに対して行われた閲覧アクションの回数に応じて、例えばフォントサイズの大きさを変更するように決定しても良い。そして、プロセッサ23は、このように決定された表示態様で表示されるように閲覧ソースを生成する。
【0091】
次に、ステップS43において、プロセッサ23は、上記生成した閲覧ソースを含む送信データを生成し、リクエスト元となる端末装置10に送信する。その後、上記ステップS32に戻り、処理が繰り返される。
【0092】
次に、上記ステップS37の判定の結果、端末装置10からのリクエストの内容が「閲覧ソースの要求」または「表示モードの変更」でもないときは(ステップS37でNO)、ステップS38において、プロセッサ23は、その他の処理を適宜実行する。
【0093】
次に、ステップS39において、プロセッサ23は、処理終了のための条件が満たされたか否かを判定し、条件が満たされていないときは(ステップS39でNO)、上記ステップS32に戻り、処理を繰り返す。一方、条件が満たされていれば(ステップS39でYES)、サーバ20におけるSNSサーバ処理を終了する。
【0094】
このように、本実施形態では、閲覧アクションが行われた投稿コンテンツに対し、その閲覧アクションの回数等に応じて表示態様を変化させて表示する。換言すれば、ユーザがSNSを普段通り利用しているだけで、投稿コンテンツの表示態様が(徐々に)変化していくことになる。これにより、上述の第1の表示モードのように、主に閲覧者とは他のユーザによる閲覧アクションが投稿コンテンツの表示態様に反映された閲覧用画面を閲覧者に提供できる。この結果、閲覧者は、そのときに人気のある投稿コンテンツや高評価である投稿コンテンツ等がどれであるか等を効率的に把握でき、より効率的な閲覧等が可能となる。また、上記第2の表示モードのように、閲覧者自身の閲覧アクションが投稿コンテンツの表示態様に反映された閲覧用画面も提供できる。これにより、閲覧者自身との親密性が高いユーザや、注目しているユーザの投稿コンテンツをより効率的に把握・閲覧することができる。このような、第1の表示モードおよび第2の表示モードのいずれの場合であっても、閲覧者にとって、見たい投稿コンテンツをより効率的に見ることが可能となる。
【0095】
なお、閲覧アクションに応じた表示態様の変化に関して、上記実施形態では、閲覧アクションレコード数に応じて表示態様の変化内容(フォントの大きさ等)を決める例を示した、この他、当該閲覧アクションレコード数の算出に際して、アクション内容88を用いてフィルタリングをかけるようにしてもよい。例えば、閲覧アクションの内容が「肯定評価」である閲覧アクションレコードの数を算出するようにしてもよい。つまり、閲覧アクションが「肯定的な評価」であるか「否定的な評価」であるかを考慮して表示態様を変化させるようにしてもよい。一例としては、基本的には、肯定的な評価の回数(「肯定評価」の閲覧アクションレコード数)に応じてフォントサイズが段階的に大きくなるよう設定すると共に、否定的な評価の回数(「否定評価」の閲覧アクションレコード数)に応じて、上記大きくしたフォントサイズを元に戻していくような設定を行うようにしても良い。また、その他、否定評価が多い場合は、デフォルトのフォントサイズよりも小さくなるような設定を行っても良い。更には、否定評価の結果、フォントサイズの変更の他、フォントの色を、ネガティブな印象を想起させるような色に変更するようにしてもよい。
【0096】
また、表示態様を変化させるか否かの判断材料となる閲覧アクションについて、判断に用いる閲覧アクションに期限的な制限を利用するようにしても良い。例えば、直近1ヶ月の間に行われた閲覧アクションに基づいて表示態様を決定する、等である(これは、例えば上記アクション日時87に基づいて判定可能である)。これにより、例えば、1年前に投稿された投稿コンテンツがあり、その後、そのユーザが投稿していないような場合に、いつまでもその投稿コンテンツの表示態様が目立ってしまうようなことを防ぐことができる。また、例えば、あるユーザについて3ヶ月前に投稿していた投稿コンテンツについては肯定的評価が多かったが、直近1ヶ月における投稿コンテンツについては否定的な評価が多いような場合等、つまり、以前はその投稿の人気が高かったが最近は人気が低下しているユーザについて、表示態様を変化させずに表示できる。また、これとは逆に、以前はその投稿コンテンツに人気は無かったが、直近において人気が高くなった、あるいは話題になっているような投稿コンテンツ(およびその投稿を行ったユーザ)を表示態様の変化により目立たせることができる。このように、閲覧時点における投稿コンテンツの人気・注目度の「トレンド」を反映した閲覧用画面をユーザに提供することができる。
【0097】
また、他の実施形態では、投稿者に対する評価について、上記のような投稿コンテンツへの閲覧アクションを介さずに、より直接的に評価できるようにしてもよい。例えば、ユーザAがユーザBの投稿コンテンツを閲覧し、これに対する特段の閲覧アクションは行ってはいないものの、ユーザBの投稿を気に入ったような場合は、ユーザBを「好きな投稿者(お気に入りユーザ)」として指定・設定できるようにしてもよい。この場合、例えば、ユーザAが所定の操作を行うことで、上記お気に入りユーザデータ69にユーザBを記録できるように構成することが考えられる。これにより、ユーザAがユーザBの投稿に対して閲覧アクションを行っていないあるいはその回数が少ないような場合であっても、上記第2の表示モードにおいて、ユーザBの投稿コンテンツを目立たせて表示させることができる。また、上記第1の表示モードの場合についてもこれを適用するようにしてもよい。例えば、所定人数以上のユーザから「お気に入りユーザ」として設定されたユーザにかかる投稿コンテンツの表示態様を変更するようにしてもよい。また、あるユーザを「好きな投稿者(お気に入りユーザ)」として指定・設定するかどうかという二者択一な評価に基づいて表示態様を変更するだけではなく、その他にも、例えば、ユーザBに対する評価の度合い(評価値)をユーザAが設定できるようにし、ユーザBに対するユーザAの評価の度合い(評価値)の累積結果に応じて、ユーザBにかかる投稿コンテンツの表示態様を(一例として、段階的に)変更してもよい。
【0098】
また、投稿コンテンツの表示態様の変化に加え、当該投稿コンテンツにユーザの注意をひくために、更に音声出力を併用したり、スクロール速度の調整等の画面制御も行うようにしても良い。例えば、端末装置においてユーザが閲覧用画面をスクロール操作して「流し読み」しているような場合を想定する。この場合に、上記表示態様を変化した投稿コンテンツが表示画面内に含まれるタイミングを検出して、このタイミングで所定の音声を発したり、端末装置を振動させたり、スクロール速度を低下、あるいは一時的にスクロールを停止させるような制御を行ってもよい。例えば、音声出力させる場合、サーバ側で上記閲覧ソースデータを生成するとき、「この投稿コンテンツが表示画面内に入ったとき音声を出力する」旨の設定(例えばその旨を示すHTMLタグやスクリプト等)を、表示態様を変更した投稿コンテンツに対して更に設定しておく。そして、端末装置側では、上記の「音声出力」設定がなされた投稿コンテンツが表示画面内に含まれるタイミングの検出を行い、そのタイミングで端末装置に保存された所定の音声データ(例えば上記閲覧ソースデータと共にサーバから端末装置へ送信された音声データ)を再生し、音声を出力することが考えられる。また、その他、サーバ側では特段の処理は行わずに、端末装置側のみで上記の制御を行うようにしても良い。例えば、端末装置側で、上記「表示態様が変更された投稿コンテンツ」が表示画面内に含まれるタイミングの検出を行い、そのタイミングで所定の音声を出力するようにしてもよい。
【0099】
また、上述した閲覧アクションデータ85に関して、上記実施形態では、閲覧アクションレコードの数等に基づいて閲覧アクションが行われた回数を算出する例を示したが、この他、「人気度」や「興味関心度」を示すデータやパラメータを別途記録する構成としてもよい。例えば、アクション内容88が「肯定評価」である閲覧アクションレコードの数に応じて、「人気度」パラメータを増加させていく。そして、上記第1の表示モードにおける表示態様の変化の決定に際して、この「人気度」パラメータに基づいて表示態様の変化を決定するようにしてもよい。また、例えば、上記お気に入りユーザデータ69に関して、その内容に基づいて、あるユーザの他のユーザに対する「興味関心度」のパラメータを算出して、記録するようにしてもよい。例えば、肯定評価を行った回数の多い閲覧アクション対象ユーザについて、そのユーザへの「興味関心度」を示すパラメータ値を増加させる、等である。そして、当該「興味関心度」のパラメータに基づいて、上記第2の表示モードにおける表示態様の変化を決定するようにしてもよい。
【0100】
また、他の実施形態では、更に各ユーザのプロフィール情報に基づいて表示態様を変化させるようにしても良い。例えば、上記第1の表示モードにおいて、表示態様が変更されるコンテンツの投稿ユーザのうち、その閲覧者の(アカウント情報データ67に記憶されている)「趣味」が共通するユーザの投稿コンテンツについて、更に表示態様を変更するようにしてもよい。例えば、閲覧アクションに応じて表示領域の拡大を行い、趣味が共通するユーザの投稿コンテンツに関しては文字色を変更する、等である。その結果、他の投稿コンテンツに比べて、その表示領域が大きく、かつ、文字色も変更されて表示されている投稿コンテンツについて、その投稿者は閲覧者と趣味が共通していると推測できる。そして、このような趣味の共通性をきっかけに、その投稿者とより親密度を高めるようなことも期待できる。これは、上記第2の表示モードにおいても同様である。また、例えば、プロフィール情報における「趣味」と「出身地」とで、異なる文字色となるよう表示態様を変更してもよい。
【0101】
また、上記表示態様の変更に関して、その変更内容を閲覧者が指定できるように構成しても良い。例えば、所定の設定画面において、第1の表示モードにおける表示態様の変化を、「表示領域を拡大する」、「フォントサイズを大きくする」、「文字色を変更する」のいずれかを選択可能とする構成にしてもよい。
【0102】
また、ユーザが投稿コンテンツを投稿するとき、ある程度、その表示態様を当該ユーザが指定できるようにしてもよい。つまり、投稿の時点で、上記通常状態とは異なる表示態様で投稿できるように、ある程度指定可能なように構成しても良い。ここで指定できる表示態様は、上述した処理のような、閲覧アクションに基づく表示態様の変化内容とは異なる内容としておいてもよい。例えば、ユーザは投稿時に文字の色は指定できるが、フォントの大きさの変更は指摘できず、上述したような閲覧アクションに応じて変化させる表示態様については、文字色を変化させることは行わないようにしておき、フォントの大きさを変更することで表示態様を変化させるようにする、等の構成としてもよい。
【0103】
また、上述の実施形態では、上記のフレンド関係を前提とするようなSNSの場合を例に挙げた。この他、必ずしも上記のフレンド関係は必要の無いサービスにおいても上記のような処理は適用可能である。例えば、ショッピングサイトにおける商品レビューや、動画投稿サービス、コンテンツ投稿掲示板等についても上述のような処理は適用可能である。つまり、上述したような処理を適用することで、投稿コンテンツ(レビューや投稿された動画)に対して行われた閲覧アクションに応じて、当該投稿コンテンツの表示態様を変化させることも可能である。その結果、ユーザにとって、より有用性の高いレビュー(評価の高いレビュワーのレビュー)や人気の高い投稿動画等を効率的に見ることが可能となる。
【0104】
また、上記実施形態においては、閲覧アクションに関する情報に応じて表示態様を変更して表示する閲覧ソースの生成・送信に関する処理をサーバ20で処理する例を示した。このサーバ20での処理に関しては、他の実施形態では、複数の情報処理装置によってサーバシステムが構成され、上記サーバ20側で実行するべき処理を当該複数の情報処理装置が分担して実行してもよい。