WO2013175668A1 - メッセージ管理装置、メッセージ管理方法および記録媒体 - Google Patents

Description

メッセージ管理装置、メッセージ管理方法および記録媒体

　本発明は、複数のユーザ同士で投稿内容等を閲覧させる技術に関する。

　近年、インターネットを利用したサイトによって様々なメッセージの閲覧、共有、交換などができるサービスが普及している。このようなサービスにおいては、所定の主題に関して複数のユーザ相互間による結び付きの度合いであるリンク強度に基づいてメッセージの送信先を選択する技術が知られている（例えば特許文献１参照）。

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

　ところで、上記技術では、リンク強度に基づいてメッセージの送信先が選択されるが、そのメッセージを実際に閲覧したときの感じ方は人によって千差万別である。
　本発明は、上述した事情に鑑みてなされたものであり、その目的の一つは、メッセージのような投稿内容の実際の評価を反映した上で、未知のユーザに投稿内容を送信することができる技術を提供することにある。

　上記課題を解決するために本発明に係るメッセージ管理装置は、投稿ユーザが投稿した投稿内容を、当該投稿ユーザと関係が構築されている関係ユーザに閲覧可能に提供する提供部と、前記投稿内容に対する前記関係ユーザからの評価に基づいて評価値を決定する評価部と、前記評価値が所定の基準を充足した場合に、前記関係ユーザ以外の他のユーザに前記投稿内容を閲覧可能に提供する再提供部と、を備える。

　なお、投稿内容とは、テキストのような文字情報のみならず、音声や、リンク先情報、映像を含む概念である。また、評価値や基準としては、後述するような様々なものが想定される。
　投稿ユーザが投稿した投稿内容とは、投稿ユーザの操作に基づいて当該投稿ユーザが操作する端末装置から投稿（送信）された投稿内容をいう。また、ユーザに閲覧可能に提供するとは、当該ユーザが操作する端末装置に、投稿内容が文字情報であれば、表示させたり、音声で読み上げたりすることをいい、投稿内容が映像であれば、再生することなどをいう。

　本発明において、前記他のユーザとは、前記関係ユーザと関係が構築されているユーザの一部または全員を含んでいる。例えば、関係ユーザのうち、投稿内容に対して肯定的な評価で応答したユーザと関係が構築されているユーザとしても良いし、投稿内容の評価に関係なく、関係ユーザと関係が構築されているユーザの全員としても良い。

　また、本発明において、前記提供部は、前記投稿ユーザが投稿した投稿とともに、閲覧可能なユーザに操作可能な応答用ボタンを表示部に表示可能に提供し、前記評価部は、前記投稿内容に対する前記応答用ボタンの操作を受け付けて、受け付けた回数に基づいて評価値を決定する構成としても良い。
　ここで、前記応答用ボタンには、前記投稿内容に対して肯定を示す肯定応答用ボタンと、否定を示す否定応答用ボタンとを含み、前記再提供部は、前記肯定応答用ボタンの操作の回数と、前記否定応答用ボタンの操作の回数とに基づいて前記評価値を決定する構成としても良い。

　また、本発明において、前記再提供部は、前記評価値に応じて前記投稿内容を閲覧可能にする人数を制限しても良い。
　一方、前記再提供部は、前記投稿ユーザと関係が構築されている関係ユーザとして新たなユーザが加わった場合、前記投稿ユーザが投稿した過去の投稿内容のうち、前記評価値が所定の基準を充足した投稿内容の一部または全部を、前記新たなユーザに閲覧可能に提供しても良い。

　本発明は、メッセージ管理装置のみならず、当該メッセージの管理方法や、サーバとしてのコンピュータで機能させるプログラムとしても概念することができる。
　また、上記プログラムは記録媒体に記憶させても良い。この記録媒体を用いれば、例えば上記コンピュータに上記プログラムをインストールすることができる。ここで、上記プログラムを記憶した記録媒体は、ＣＤ－ＲＯＭ等の非一過性の記録媒体であっても良い。

実施形態に係るシステムの概要動作を示す図である。 実施形態に係るシステムの構成を示す図である。 同システムにおける管理サーバの構成を示すブロック図である。 同システムにおける端末装置の構成を示すブロック図である。 同システムにおいて投稿内容の閲覧等に構築される機能ブロック図である。 ユーザ登録テーブルの一例を示す図である。 フレンド登録テーブルの一例を示す図である。 ユーザ同士におけるフレンド関係の一例を示す図である。 投稿データテーブルの一例を示す図である。 評価データテーブルの一例を示す図である。 投稿内容の提供動作を示すフローチャートである。 投稿内容の評価、再提供の動作を示すフローチャートである。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 端末装置における表示画面の一例を示す図である。 招待受諾通知を受信する際の動作を示すフローチャートである。 再提供する人数を制限する場合の例を示す図である。 応用例に係るシステムで構築される機能ブロック図である。

＜実施形態の概要＞
　まず、実施形態に係るメッセージ管理装置を含むシステムの動作概要について説明する。
　図１は、この動作概要を説明するための図である。この図に示すシステムにおいて、管理サーバは、メッセージ管理装置であり、複数の端末装置に対し通信可能となっている。
　システムにおいて、あるユーザ（投稿ユーザ）が端末装置を介して、自分の近況や出来事などの記事を投稿すると、当該投稿内容は、投稿ユーザを識別するユーザＩＤなどとともに管理サーバ１０に送信される。管理サーバでは、ユーザ同士のフレンド関係をテーブルとして予め記憶している。管理サーバが、投稿ユーザから投稿内容を受信したとき、当該投稿ユーザに対してフレンド関係にある関係ユーザを、上記テーブルを参照して特定し、投稿内容や、当該投稿内容を評価するための応答用ボタンなどを閲覧可能となるように、関係ユーザの端末装置に提供する。これにより、関係ユーザは、投稿ユーザによって投稿された記事を閲覧することができる。

　この記事を端末装置で閲覧した関係ユーザは、当該記事についての良し悪しなどを、応答用ボタンの操作等によって評価する。関係ユーザによって評価がなされると、その評価内容が端末装置から管理サーバに送信される。管理サーバは、関係ユーザからの評価を集計し、その評価を示す評価値が基準を充足したか否かを判別する。基準を充足したときに、管理サーバは、基準を充足した投稿内容、すなわち高評価の投稿内容を閲覧可能となるように、投稿ユーザの関係ユーザ以外の他のユーザに、例えば投稿ユーザの関係ユーザに対してフレンド関係を有するユーザの端末装置に再提供する。
　これによって、実際に評価の高い投稿内容を、ユーザ同士でフレンド関係が構築されたコミュニティに自動的に広めることが可能になる。

　次に、実施形態の詳細について図面を参照して説明する。

＜全体構成＞
　図２は、実施形態に係るシステムの全体的な構成を示すブロック図である。
　この図に示されるように、システム１では、複数の端末装置２０－１、２０－２、２０－３、…が、移動通信網Ｎｂ、ゲートウェイ１５およびインターネットＮａを介して管理サーバ１０に接続された構成となっている。
　なお、以降において、端末装置２０－１、２０－２、２０－３、…については、端末装置を特定せずに一般的に説明するので、符号における「－（ハイフン）」以下を省略して単に「２０」とする。端末装置２０は、表示パネル２１０に重ねられたタッチパネル２２０を有し、ユーザが表示パネル２１０に表示された画面に対してタッチ操作等することで、必要な情報の入力や各種の指示が与えられる構成となっている。

　管理サーバ１０は、ユーザ同士のフレンド関係を管理したり、端末装置２０から受信した投稿内容や評価を管理したり、所定の基準を充足したユーザの投稿内容を、当該ユーザと特定の関係にある関係ユーザに送信したりするものである。このため、管理サーバ１０では、各種の情報をテーブル化して管理する。

　図３は、管理サーバ１０のハードウェア構成を示すブロック図である。この図に示されるように、管理サーバ１０は、装置全体を制御するＣＰＵ（Central Processing Unit）１０１と、ＣＰＵ１０１の主記憶として機能するＲＡＭ（Random Access Memory）１０２と、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）１０３と、ネットワークを介して通信するためのインターフェース（Ｉ／Ｆ）１０５と、時間情報を出力するＲＴＣ（Real Time Clock）１０６と、各種のプログラムやデータを記憶するストレージユニット１０８と、を含む。ストレージユニット１０８では、データベース１１８が構築されるとともに、ＣＰＵ１０１によって管理される。

　なお、データベース１１８によって管理される各種のテーブル等の詳細については後述する。
　また、管理サーバ１０は、図１においては１台で構築されているが、２台以上に分散させるとともに外部からみたときに仮想的に１台であるかのようにみえる構成としても良い。一方で、管理サーバ１０の一部の機能を他のサービスを提供しているサーバで構築しても良い。また、管理サーバ１０が中継サーバを介して端末装置２０と接続するように構成しても良い。

　図４は、端末装置２０のハードウェア構成を示すブロック図である。端末装置２０は、例えばユーザが操作する携帯電話機であり、図に示されるように、ＣＰＵ２０１と、メモリ２０２と、通信部２０４と、ＲＴＣ２０６と、表示パネル２１０と、タッチパネル２２０と、を含む。

　このうち、ＣＰＵ２０１は端末装置２０の全体を制御し、メモリ２０２は、基本プログラムや、管理サーバ１０から各種のサービスの提供を受けるためのアプリケーションプログラム、各種のデータなどを記憶する。ここでいうアプリケーションプログラムは、投稿内容の送信、閲覧、評価等の機能を実行するものであり、特定のサイトからダウンロードされて、端末装置２０にインストールされている。通信部２０４は、移動通信網Ｎｂを介して管理サーバ１０と通信する。ＲＴＣ２０６は、現在時刻の時間情報を出力する。

　表示パネル２１０は、例えば液晶表示装置や有機ＥＬ（Electro Luminescence）装置などのディスプレイである。タッチパネル２２０は、詳細な説明については省略するが、表示パネル２１０と一体に構成され、表示パネル２１０によって表示された画面のタッチ位置（ＸＹ座標値）を検出し、検出したタッチ位置を示す位置情報をＣＰＵ２０１に供給する。ＣＰＵ２０１は、タッチパネル２２０からの位置情報に基づいて、タッチ位置の移動方向や、移動速度、タッチ操作の種類等を検出する。

　ここで、検出可能なタッチ操作の種類には、例えばタップ、フリック、ドラッグ、ピンチ等が含まれる。このうち、タップとは、表示画面を指で軽く叩く操作である。フリックとは、画面に表示された対象物を指で軽く払う操作である。ドラッグとは、画面に表示された対象物を指で接触させた状態で移動させる操作である。ピンチとは、表示画面に二本の指を接触させた状態で広げたり狭めたりする操作である。

　なお、端末装置２０は、移動通信網Ｎｂに限られず、無線ＬＡＮ（Local Area Network）に接続される構成であっても良い。無線ＬＡＮに接続される場合、端末装置２０は、無線基地局（アクセスポイント）およびインターネットＮａを経由して、上記管理サーバ１０に接続される。また、端末装置２０は、携帯電話機に限られず、タブレット型コンピュータやＰＤＡ（Personal Digital Assistant）などでも良い。

　図５は、システム１において、投稿内容の提供、評価、再提供等の機能が実行される際に、管理サーバ１０および端末装置２０で構築される機能ブロックを示す図である。
　この機能ブロックは、管理サーバ１０においては、所定のプログラムを実行することによって、端末装置２０においては、予めインストールされた上記アプリケーションプログラムを実行することによって、それぞれ構築される。
　なお、図２におけるインターネットＮａや、ゲートウェイ１５、移動通信網Ｎｂ、また、図３におけるＩ／Ｆ１０５、図４における通信部２０４などについては、データや情報等の伝送経路に過ぎないので、図５においては図示を省略している。

　図５に示されるように、管理サーバ１０側では、データベース１１８とともに、当該データベース１１８を管理する管理部１２１、投稿内容の評価値を決定する評価部１２２、投稿ユーザによる投稿内容を当該ユーザと関係のある関係ユーザに送信する提供部１２５、および、投稿ユーザによる投稿内容の評価値が所定の基準を充足したときに、当該投稿内容を関係ユーザ以外の他のユーザに送信する再提供部１２６がそれぞれ構築される。このうち、データベース１１８には、ユーザ登録テーブルＴＢ１と、フレンド登録テーブルＴＢ２と、投稿データテーブルＴＢ３と、評価データテーブルＴＢ４とが構築される。これらのテーブルの詳細については、後述することにする。

　なお、管理サーバ１０は、複数の端末装置２０にデータや情報等を送信し、逆に、複数の端末装置２０から情報等を受信する。図５において、提供部１２５や再提供部１２６から端末装置２０以外に向かう矢印は、当該端末装置２０以外の端末装置にも情報が出力されることを示し、端末装置２０以外から管理部１２１に向かう矢印は、他の端末装置からも情報が入力されることを示している。

　一方、端末装置２０側では、ＣＰＵ２０１がアプリケーションプログラムを実行することによって、操作検出部２３１および表示制御部２３２が構築される。また、表示パネル２１０の表示領域は、入力部２１１と、表示部２１５とに分けられる。
　このうち、表示部２１５には、管理サーバ１０から提供または再提供された投稿内容が表示されるほか、後述するように肯定応答用ボタン２１６と否定応答用ボタン２１７とが表示される。
　操作検出部２３１は、タッチパネル２２０から出力される位置情報に基づいて、タッチ位置や、その移動方向、移動速度、タッチ操作の種類等を検出して出力する。
　表示制御部２３２は、操作検出部２３１や、提供部１２５、再提供部１２６からの情報に基づいて表示パネル２１０の表示領域における表示を制御する。

　ところで、端末装置２０から発信された投稿内容や、投稿内容の評価、さらにはユーザ同士のフレンド関係については、管理サーバ１０の側におけるデータベース１１８で管理される。そこで次に、データベース１１８で管理されるテーブル等について説明する。

＜ユーザ登録テーブル＞
　図６は、ユーザ登録テーブルＴＢ１の一例を示す図である。
　ユーザ登録テーブルＴＢ１は、ユーザに関する情報を記憶するテーブルであり、図に示されるように、ユーザＩＤと、ユーザの名前情報と、プロフィール画像情報とをユーザ毎に対応付けて記憶する。
　これらのうち、ユーザＩＤは、ユーザをシステム１において一意に識別する。ユーザの名前情報は、コミュニティにおいてユーザ同士で識別される名前を示し、実名やニックネームが用いられる。プロフィール画像情報は、当該ユーザを示す画像を示し、ユーザによって登録や、選択、編集などされたものが用いられる。このプロフィール画像情報は、投稿者が誰であるのかを一見して判るようにするために、投稿内容の近傍に表示させるものである。なお、プロフィール画像情報については必ず登録すべきものではなく、ユーザが登録しないことを選択することも可能である。登録しないことを選択した場合には、システムで用意された画像を表示するようにしても良いし、何も表示しないようにしても良い。また、プロフィール画像情報については、実体そのものではなく、実体のリンク先（参照先）であっても良い。いずれにしても、ユーザＩＤ等から、プロフィール画像情報を取得できる手段が講じられていれば良い。

＜フレンド登録テーブル＞
　本実施形態において、投稿ユーザによる投稿内容は、当該ユーザとフレンド関係にある関係ユーザに閲覧可能に提供される。また、投稿ユーザによる投稿内容の評価値が所定の基準を充足したときに、当該投稿内容は、上記関係ユーザ以外の他のユーザに閲覧可能に提供される。このように、ユーザ同士の関係を管理するのが、フレンド登録テーブルＴＢ２である。
　本実施形態において、あるユーザが、別のユーザに対して投稿を閲覧可能に提供させるコミュニティに招待し、当該招待に対して当該別のユーザが承諾したときに、あるユーザからみて別のユーザへのフレンド関係が成立するものとする。

　図７は、フレンド登録テーブルＴＢ２の一例を示す図である。この図に示されるように、フレンド登録テーブルＴＢ２は、招待元のユーザを示すユーザＩＤと、招待先（相手）のユーザを示すユーザＩＤと、フレンド関係が成立した登録日時情報（年／月／日、時：分：秒）とを対応付けて記憶する。

　図８は、図７に示したフレンド登録テーブルＴＢ２において、ユーザ同士がどのようなフレンド関係となっているのかを示す図である。
　図７および図８の例では、ユーザＩＤが「ｘｘ１１」であるユーザからみて、ユーザＩＤが「ｘｘ９３」、「ｘ１２４」、…、「ｘ２５３」であるユーザへのフレンド関係が成立している。また、ユーザＩＤが「ｘｘ９３」であるユーザからみて、ユーザＩＤが「ｘ１１３」、「ｘ３４６」、…、「ｘ５１７」であるユーザへのフレンド関係が成立している。同様に、ユーザＩＤが「ｘ１１３」であるユーザからみて、ユーザＩＤが「ｘ２１９」、「ｘ４５９」、…、「ｘ５６３」であるユーザへのフレンド関係が成立している。
　ここで、例えばユーザＩＤが「ｘｘ１１」であるユーザからみて、ユーザＩＤが「ｘ１１３」であるユーザとは、直接的なフレンド関係を有していないが、ユーザＩＤが「ｘｘ９３」であユーザを介して繋がっている、ということもできる。

＜投稿データテーブル＞
　システム１において、投稿ユーザによる投稿内容は関係ユーザに閲覧可能に提供され、当該投稿内容のうち、評価値が所定の基準を充足したものについては、他のユーザにも閲覧可能に再提供される。この提供、再提供のために投稿内容を管理するのが投稿データテーブルＴＢ３である。

　図９は、投稿データテーブルＴＢ３における記憶内容の一例を示す図である。この図に示されるように、投稿データテーブルＴＢ３は、投稿された内容を一意に識別する投稿ＩＤと、投稿者（ユーザ）を一意に識別する投稿者ＩＤと、投稿された日時を示す投稿日時情報と、種別情報と、元投稿ＩＤと、元投稿者ＩＤと、提供回数情報とを投稿毎に対応付けて記憶する。投稿内容の本体（本文、画像、リンク先など）については、投稿ＩＤと関連付けられて別のテーブル（図示省略）で管理・記憶される。

　本実施形態においてユーザによる投稿の形式としては、厳密にいえば、狭義の「投稿」と、「応答」との２種類がある。このうち、狭義の「投稿」とは、話題の基礎となる記事を発信した場合をいう。「応答」とは、ある「投稿」に対して、他のユーザがコメントを付して返信することをいう。このため、「応答」には、必ず基礎となる「投稿」が存在することになる。また、本実施形態では、所定の基準を充足した投稿について、システムが他のユーザに閲覧可能に再提供する場合がある。この場合の種別情報を、「投稿」、「応答」と区別するために「再送」としている。
　投稿データテーブルＴＢ３において、種別情報には、その投稿が、狭義の「投稿」であるのか、「応答」であるのか、「再送」であるのかを示す情報が登録される。
　また、投稿者ＩＤには、種別情報が「投稿」、「応答」である場合には、投稿したユーザのユーザＩＤが登録される。ただし、「再送」の場合には、システム側の提供であることが示す情報が登録される。

　元投稿ＩＤは、種別情報が「応答」である場合に、その根拠となった投稿の投稿ＩＤが登録され、種別情報が「再送」である場合に、再送によって提供された投稿の投稿ＩＤが登録される。元投稿者ＩＤは、種別情報が「応答」である場合に、その根拠となった投稿の投稿者ＩＤが登録され、種別情報が「再送」である場合に、再送によって提供された投稿の投稿者ＩＤが登録される。
　このようにして、投稿データテーブルＴＢ３では、１つの「投稿」に対して「応答」が順次紐付けられる。なお、「投稿」に対しては「応答」がない場合も当然にある。

　提供回数情報には、ユーザに投稿、応答が提供された回数を示す情報が登録される。本実施形態において、投稿ユーザによる「投稿」の内容や、当該「投稿」に対する「応答」の内容は、当該投稿ユーザに対してフレンド関係にある関係ユーザに閲覧可能に提供されるので、その時点で提供回数情報は「１」となる。所定の基準を充足した投稿内容は、上記関係ユーザ以外の他のユーザに閲覧可能に提供されるので、その時点で提供回数情報は「１」だけインクリメントされる。

　なお、以降の説明においては、「投稿」と「応答」と「再送」とについては、特に区別する必要がない限り、単に投稿として表現することにする。例えば図９に示した投稿データテーブルＴＢ３において、投稿ＩＤ、投稿者ＩＤ、投稿日時情報については、「応答」、「再送」を含んでいるが、ここでは区別していない。
　また、投稿内容の本体については、上述したように投稿ＩＤと関連付けられて別のテーブルで管理・記憶されるが、図９に示したテーブルにおいて、投稿内容の本体の項目を追加して登録する構成として良い。

＜評価データテーブル＞
　図１０は、評価データテーブルＴＢ４における記憶内容の一例を示す図である。この図に示されるように、評価データテーブルＴＢ４は、図９の投稿データテーブルＴＢ３において種別情報が「投稿」である投稿ＩＤに対して、肯定評価値情報、否定評価値情報および更新日時情報を対応付けて記憶する。
　このうち、肯定評価値情報と否定評価値情報とは、それぞれ投稿ＩＤにかかる投稿内容の肯定評価値と否定評価値とを示す情報である。本実施形態において評価値は、例えば当該投稿内容に対する肯定評価値から否定評価値を減じた値とする。更新日時情報は、評価値が更新された最新の日時情報であり、ＲＴＣ２０６から取得される時間情報が登録される。

  次に、システム１において、投稿内容の提供、評価、再提供等の機能が実行される際の処理について説明する。

　図１１は、端末装置２０からの投稿内容を関係ユーザに提供するまでの動作を示すフローチャートである。
　まず、管理サーバ１０において管理部１２１は、いずれかの端末装置２０から、投稿内容を受信したか否かを判別する（ステップＳａ１１）。
　端末装置２０での投稿については、表示制御部２３２によって例えば図１３に示されるような表示された画面によって実行される。詳細には、投稿ユーザが、入力部２１１にテキストをソフトウェアキーボードなどによって入力するとともに、ソフトウェアボタン２７３の表示部分をタッチ等の操作をすることによって実行される。
　なお、投稿に対する応答の表示例については後述する。
　また、画像やリンク先を含めて投稿する場合には、特に図示しないが別途の所定の操作がなされる。
　このようにして端末装置２０から投稿が指示された場合、投稿内容の本体のほか、当該端末装置２０のユーザＩＤ、種別情報などが付帯する。

　投稿を受信していなければ（ステップＳａ１１の判別結果が「Ｎｏ」であれば）、処理手順がステップＳａ１１に戻る。このため、管理部１２１は、ここでは端末装置２０から投稿内容を受信するまで、待機することになる。

　次に、いずれかの端末装置２０から、投稿内容を受信すると（ステップＳａ１１の判別結果が「Ｙｅｓ」になると）、管理部１２１は、当該投稿内容を投稿データテーブルＴＢ３に登録する（ステップＳａ１２）。
　詳細には、管理部１２１は、第１に、一意に生成した投稿ＩＤに対し、投稿者ＩＤとして当該投稿に付帯するユーザＩＤを登録し、第２に、当該受信時点の時刻情報をＲＴＣ２０６から取得して、投稿日時情報として当該時刻情報を登録し、第３に、当該投稿に付帯する種別情報を登録する。また、種別情報が「応答」であれば、管理部１２１は、元投稿ＩＤ、元投稿者ＩＤについても登録する。

　続いて、管理部１２１は、フレンド登録テーブルＴＢ２を参照して、投稿したユーザＩＤ（招待元）に対するユーザＩＤ（招待先）を読み出し、投稿ユーザに対する関係ユーザを特定して、提供部１２５に通知する（ステップＳａ１３）。例えば投稿ユーザの投稿者ＩＤが「ｘｘ１１」であれば、ユーザＩＤが「ｘｘ９３」、「ｘ１２４」、…、「ｘ２５３」のユーザが、投稿ユーザに対する関係ユーザとして特定される（図７参照）。また、管理部１２１は、投稿内容のほかに、投稿ユーザのユーザＩＤに対応するプロフィール画像情報や、名前情報、投稿日時情報についても提供部１２５に供給する。なお、このときに特定した関係ユーザ（のユーザＩＤ）については、後において再び利用する場合があるので、管理部１２１は、データベース１１８において投稿ＩＤに対応付けて記録する。

　提供部１２５は、管理部１２１から供給された投稿内容などの情報を、通知された関係ユーザの端末装置２０（の表示制御部２３２）に提供する（ステップＳａ１４）。
　この提供に伴って、管理部１２１は、投稿データテーブルＴＢ３において登録した投稿に対応する提供回数情報として初期値の「１」をセットする（ステップＳａ１５）。
　この後、処理手順が再びステップＳａ１１に戻る。このため、管理部１２１は、端末装置２０から投稿内容を受信する毎に、ステップＳａ１１～Ｓａ１５の処理を実行することになる。

　図１２は、関係ユーザから投稿内容の評価を受信してから、条件を充足した投稿内容を他のユーザに再提供するまでの動作を示すフローチャートである。
　まず、管理サーバ１０において管理部１２１は、いずれかの端末装置２０から、投稿内容の評価を受信したか否かを判別する（ステップＳｂ１１）。端末装置２０において、肯定応答用ボタン２１６または否定応答用ボタン２１７が操作された場合、どちらのボタンが操作されたのかを示す情報や、評価対象となった投稿ＩＤなどが通知される。
　評価を受信していなければ（ステップＳｂ１１の判別結果が「Ｎｏ」であれば）、処理手順がステップＳｂ１１に戻る。このため、管理部１２１は、ここでは端末装置２０から投稿内容の評価を受信するまで、待機することになる。

　いずれかの端末装置２０から、投稿内容の評価を受信すると（ステップＳｂ１１の判別結果が「Ｙｅｓ」になると）、管理部１２１は、評価データテーブルＴＢ４にアクセスして投稿ＩＤに対応する肯定評価値情報および否定評価値情報を取得して、評価部１２２に転送し、評価部１２２は、肯定応答用ボタン２１６が操作されたのであれば、取得した肯定評価値情報の値（肯定評価値）を「１」だけ加算し、否定応答用ボタン２１７が操作されたのであれば、取得した否定評価値情報の値（否定評価値）を「１」だけ加算して、加算後の値を管理部１２１に通知する。管理部１２１は、加算された肯定評価値または否定評価値を書き戻して、評価データテーブルＴＢ４を更新する（ステップＳｂ１２）。これによって、投稿内容の評価が評価データテーブルＴＢ４に反映される。
　また、評価データテーブルＴＢ４を更新したとき、管理部１２１は、更新後の肯定評価値情報または否定評価値情報と、評価対象の投稿ＩＤとともに、当該投稿内容を提供した関係ユーザを提供部１２５に通知する。提供部１２５は、管理部１２１から通知された情報を、通知された関係ユーザの端末装置２０（の表示制御部２３２）に提供する。これによって、関係ユーザの端末装置２０では、投稿内容に対して肯定評価値、否定評価値を合わせて表示する場合に、肯定評価値、否定評価値を評価の都度、最新の値に更新することができる。

　次に、評価部１２２は、更新された評価値が所定の基準を充足したか否かを判別して、その判別結果を管理部１２１に通知する（ステップＳｂ１３）。ここで、所定の基準とは、肯定評価値から否定評価値を減じた評価値が例えば閾値以上となったときであり、具体的にはここでは「１０」以上となったときとする。したがって、更新した評価値が「１０」以上となったか否かが評価部１２２によって判別される。なお、基準としては、このほかにも、後述するように種々のものが想定される。

　評価値が所定の基準を充足していなければ（ステップＳｂ１３の判別結果が「Ｎｏ」であれば）、処理手順がステップＳｂ１１に戻る。このため、管理部１２１は、ここでは端末装置２０から投稿内容の評価を再び受信するまで、待機することになる。
　評価値が所定の基準を充足したならば（ステップＳｂ１３の判別結果が「Ｙｅｓ」になれば）、管理部１２１は、基準を充足した投稿ＩＤに対し、過去に当該投稿ＩＤに対応付けた関係ユーザ、すなわち、評価対象となっている投稿内容を提供した関係ユーザを特定し、当該関係ユーザからみてフレンド関係が成立しているユーザ（他のユーザ）を、フレンド登録テーブルＴＢ２を参照して特定して、再提供部１２６に通知する（ステップＳｂ１４）。例えば基準を充足した投稿ＩＤが図１０において「ｙｙｙｙ８１」であれば、当該投稿ＩＤに対応付けられた投稿者ＩＤは図９の（２）を参照すれば「ｘｘ１１」であり、その投稿者ＩＤで識別される投稿者に対してフレンド関係にある関係ユーザは、ユーザＩＤが「ｘｘ９３」、「ｘ１２４」、…、「ｘ２５３」で識別される者である。このため、ユーザＩＤが「ｘｘ９３」、「ｘ１２４」、…、「ｘ２５３」のそれぞれからみてフレンド関係が成立しているユーザが他のユーザとして特定される。このとき、管理部１２１は、特定した他のユーザのなかに、関係ユーザが含まれていれば、再提供部１２６への通知対象から除外しても良い。
　また、管理部１２１は、基準を充足した投稿内容のほかに、基準を充足した投稿ユーザのユーザＩＤに対応するプロフィール画像情報や、名前情報、投稿日時情報についても再提供部１２６に供給する。

　再提供部１２６は、管理部１２１から供給された投稿内容などの情報を、通知された他のユーザの端末装置２０（の表示制御部２３２）に提供する（ステップＳｂ１５）。これにより、提供された端末装置２０では、当該投稿内容が閲覧可能に提供される。
　管理部１２１は、再提供にかかる投稿のデータを投稿データテーブルＴＢ３に追加登録する（ステップＳｂ１６）。詳細には、管理部１２１は、種別情報を「再送」とし、投稿者ＩＤをシステムとし、投稿日時情報に、再提供した時刻情報を登録し、元投稿ＩＤおよび元投稿者ＩＤに、基準を充足した投稿ＩＤおよび投稿者ＩＤを登録し、提供回数情報に、最初の提供の次の最提供であることを示す「２」をセットする。例えば図９において（１）は、投稿ＩＤが「ｙｙｙｙ８１」である（２）の投稿が条件を充足して、再提供されたときに登録されたときのデータである。
　この後、処理手順が再びステップＳｂ１１に戻る。このため、管理部１２１は、端末装置２０から評価を受信する毎に、ステップＳｂ１１～Ｓｂ１６の処理を実行することになる。

　次に、システム１において、投稿内容の提供、評価、再提供等の機能が実行される際に、端末装置２０において表示される画面の具体例について説明する。
　なお、投稿をする場合の画面については、すでに図１３に例示しているので、ここでは、それ以外の場合について説明する。

　図１４は、図１３に示されるような内容を投稿ユーザが投稿した場合に、当該投稿ユーザに対する関係ユーザの端末装置２０の表示部２１５において表示される画面の例（一部）を示している。
　この図に示されるように、表示部２１５では、投稿内容、投稿者のプロフィール画像、名前、投稿日時とともに、肯定的な評価を下すための肯定応答用ボタン２１６と、否定的な評価を下すための否定応答用ボタン２１７と、肯定評価値に基づく内容と、否定評価値に基づく内容と、が表示される。換言すれば、提供部１２５から情報の提供を受けた表示制御部２３２は、表示部２１５に、投稿内容とともに、プロフィール画像、名前、投稿日時を、図に示されるように表示させる。

　この表示画面のうち、肯定評価値に基づく内容とは、その投稿に対する肯定評価値を含んで作成された定型文である。また、否定評価値に基づく内容とは、その投稿に対する否定評価値を含んで作成された定型文である。肯定評価値に基づく内容と否定評価値に基づく内容とは、いずれも上記ステップＳｂ１２において提供部１２５から提供された肯定評価値、否定評価値を参照して作成される。なお、図１４は、投稿ユーザによる投稿の直後に、関係ユーザの端末装置２０で表示された画面の例を想定しているので、誰も評価していない状態、すなわち肯定評価値、否定評価値ともに「０」となっている。
　また、この表示画面において、（１）の「投稿」に対する「応答」は、コメント入力用の入力部２１８にテキスト等を入力するとともに、ソフトウェアボタン２７５の表示部分をタッチ等の操作をすることによって実行される。
　この表示画面において、例えばフリックなどの操作をすれば、投稿や応答など上下にスクロール表示される。

　図１５は、表示画面の一例であり、図１４に示した「投稿」に対して、「応答」があった場合の表示例である。この表示画面において、（２）、（３）は、（１）の「投稿」に対する「応答」である。（２）、（３）の「応答」は、（１）の「投稿」に対して下側に、インデントして表示されている。なお、（２）の「応答」は、（３）の「応答」よりも時間的に先になされた例である。また、（４）の「投稿」は、（１）の「投稿」よりも時間的に先になされた例である。

　図１６は、図１４に示した「投稿」に対して多数の「応答」があった場合の表示例である。この表示例では、「応答」を３つまで表示させ、他については省略されているが、ソフトウェアボタン２１９をタッチ操作等することによって省略された「応答」がすべて表示される。
　また、この表示例では、肯定評価値が「５４」であり、否定評価値が「３」である場合を示している。この場合、「投稿」についての評価値は「５１」になり、閾値の「１０」以上の高評価になるので、他のユーザに再提供される。

　図１７は、基準を充足した「投稿」が他のユーザの端末装置２０に再提供された場合の表示例である。
　この例では、投稿内容が、高評価であったために、システム（管理サーバ１０）が再提供したものである旨の但し書きが付されて表示、すなわち引用であることが判るように表示されている。なお、この投稿の日時については、投稿ユーザが最初に投稿した日時であっても良いし、システムが再送した日時であっても良い。

　ところで、本実施形態にあっては、上述したように、あるユーザによる招待を、招待先である別のユーザが承諾したときに、あるユーザからみて別のユーザへのフレンド関係が成立する構成としている。このため、フレンド関係が成立した時点では、投稿ユーザによる高評価の投稿内容がすでに他のユーザに再提供されてしまい、再提供後にフレンド関係が成立したユーザには、当該高評価の投稿内容を閲覧できない不都合が考えられる。そこで、この不都合を解消する構成について以下説明することにする。

　図１８は、この構成による動作を説明するフローチャートである。
　あるユーザによる招待を招待先のユーザが受諾する場合、招待先のユーザの端末装置２０から管理サーバ１０に招待を承諾する旨の招待受諾通知が通知される。管理サーバ１０において管理部１２１は、いずれかの端末装置２０から、招待受諾通知を受信したか否かを判別する（ステップＳｃ１１）。
　招待受諾通知を受信しなければ（ステップＳｃ１１の判別結果が「Ｎｏ」であれば）、処理手順がステップＳｃ１１に戻り、これにより、管理部１２１は、招待受諾通知を受信するまで待機する。
　招待受諾通知を受信すると（ステップＳｃ１１の判別結果が「Ｙｅｓ」になると）、管理部１２１は、フレンド登録テーブルＴＢ２に、招待受諾通知の根拠となった招待元のユーザＩＤと、受諾通知を送信した招待先のユーザＩＤとで成立したフレンド関係を追加登録する（ステップＳｃ１２）。このとき、ＲＴＣ２０６から取得した時間情報を、登録日時情報として登録する。

　次に管理部１２１は、投稿データテーブルＴＢ３を参照して、招待元のユーザＩＤが元投稿ＩＤとなっているとともに、種別情報が再送（投稿者ＩＤがシステム）であって、かつ、投稿日時情報がフレンドの登録日時情報よりも前となっている投稿ＩＤを特定する（ステップＳｃ１３）。このときに特定する投稿ＩＤについては、条件を満たすもの全部であっても良いし、条件を満たすもののうち、時間的に新しいもの（古いもの）の３つというように一部としても良い。
　そして、管理部１２１は、特定した投稿ＩＤに対応する投稿内容を、招待先のユーザＩＤとともに、再提供部１２６に通知する。
　これにより、再提供部１２６は、管理部１２１から供給された投稿内容などの情報を、招待を受諾したユーザの端末装置２０（の表示制御部２３２）に提供する（ステップＳｃ１４）。これにより、提供された端末装置２０では、当該投稿内容が閲覧可能に提供される。
　この後、処理手順が再びステップＳｃ１１に戻る。このため、管理部１２１は、端末装置２０から招待受諾通知を受信する毎に、ステップＳｃ１１～Ｓｃ１４の処理を実行することになる。
　この構成によれば、招待を受諾したユーザは、フレンド関係が成立する以前の招待元による高評価の投稿内容を閲覧することが可能になる。

　なお、実施形態では、応答用ボタンとして、肯定応答用ボタン２１６と否定応答用ボタン２１７との２種類を想定したために、一旦、閾値の１０以上となった評価値が、否定応答用ボタン２１７の操作によって閾値よりも低くなった後に、肯定応答用ボタン２１６の操作によって再び閾値の１０以上となる場合がある。この場合に、ステップＳｂ１３の判別結果を再び「Ｙｅｓ」と判別するのは、同じ投稿内容が同じユーザに繰り返し再提供されることにつながる。このため、ステップＳｂ１３の判別結果が「Ｙｅｓ」となった投稿ＩＤについてはフラグを立てて、以後、ステップＳｂ１４の判別において評価値が閾値以上となっても、当該フラグが立っていれば、処理手順を以降のステップＳｂ１４に移行させずに、ステップＳｂ１１に戻す構成、すなわち同じ投稿ＩＤについてステップＳｂ１３の判別結果が「Ｙｅｓ」となるのは１度だけとする構成としても良い。

＜応用・変形例＞
　本発明は、上述した実施形態に限定されるものではなく、例えば次に述べるような各種の応用・変形が可能である。なお、次に述べる応用・変形の態様は、任意に選択された一または複数を適宜に組み合わせることもできる。

＜ＳＮＳ等＞
　投稿内容を閲覧させるコミュニティの場を、ＳＮＳ（Social Networking Service）会員に限定する構成としても良い。すなわち、ユーザは、予め登録したアカウントやパスワードを入力するなどのログイン等を経た上で、ＳＮＳのサービスとして投稿内容を閲覧する構成としても良い。

＜応答用ボタン、基準等＞
　実施形態にあっては、応答用ボタンとして、肯定応答用ボタン２１６と、否定応答用ボタン２１７との２種類としたが、いずれか一方でも良い。すなわち、肯定応答用ボタン２１６のみであれば、操作された回数によって高評価であることが判るし、否定応答用ボタン２１７のみであっても、操作されないことによって逆に高評価であることが判るからである。
　これらの操作に対応する評価値の算出についても、単純な加減算でなくて、重みを付けるなどした演算によっても良い。
　また、例えば評価の度合いを、「＋２」、「＋１」、「０」、「－１」、「－２」というように細分化して、それぞれの度合いに対応するボタンを表示させるとともに、度合いに応じて評価値を算出しても良い。

　評価値についても、単なるボタンの操作回数という概念ではなく、時間的な概念を併用しても良い。例えば、投稿からの経過時間に対する評価値の平均的な上昇度などが所定値を超えたか否かで判別しても良い。
　また、関係ユーザの総数に対して肯定応答用ボタン２１６（否定応答用ボタン２１７）で応答した人数の割合が、所定値を超えたか否かで判別しても良い。

＜関係ユーザ、他のユーザ＞
　実施形態においては、高評価の投稿内容を、投稿ユーザからみてフレンド関係にある関係ユーザに対して、フレンド関係にあるユーザを他のユーザとしたが、他のユーザとしては、ランダムに選択されたユーザとしても良いし、投稿ユーザの属性（性別、年齢、居住地など）が共通、または似通ったユーザを選択しても良い。

　実施形態においては、高評価の投稿内容を、関係ユーザに対してフレンド関係にあるユーザ（他のユーザ）の全員に閲覧可能となるように再提供したが、他のユーザの一部に制限しても良い。

　例えば、関係ユーザのうち、高評価につながった肯定応答用ボタン２１６を操作した関係ユーザとフレンド関係にあるユーザに対してのみ、再提供する構成としても良い。一般にフレンド関係については、趣味や思想などが似通った者同士で成立しやすいので、肯定応答用ボタン２１６を操作した関係ユーザとフレンド関係にあるユーザにとっても、当該投稿内容が高評価となりやすい。したがって、この構成によれば、高評価となった投稿内容については、その投稿内容を欲する傾向の高いと考えられるユーザに効率良く再提供することができる。

　また例えば、投稿内容を再提供する人数については、評価値に応じた人数に制限する構成としても良い。
　詳細には、図１９に示されるように、評価値を例えば４段階に予めランク付けするとともに、ランクのそれぞれに再提供する人数の上限を定めておく。そして、投稿内容については、基準を満たしたときに直ちに再提供するのではなく、例えば基準を満たしたときから１時間経過した時点における評価値が図１９においてどのランクであるのかを判別して、投稿内容を再提供する人数を、当該ランクに応じた人数に制限するのである。
　なお、人数を制限する場合に、他のユーザをどのようなルールで選定するのかについては、例えば抽選でも良いし、フレンド関係の成立した古い（新しい）順としても良い。

＜ｐｕｓｈ型、ｐｕｌｌ型＞
　実施形態にあっては、「投稿」または「応答」が発生する毎に、当該投稿／応答の内容が端末装置２０から管理サーバ１０に送信されて、関係ユーザの端末装置２０に閲覧させるｐｕｓｈ型サービスとして説明したが、反対に、端末装置２０からの要求に応じて、自己に関連する「投稿」や「応答」、「再送」を管理サーバ１０から引き出して閲覧させるｐｕｌｌ型サービスとした構成として良い。

＜ウェブ型＞
　実施形態においては、端末装置２０にインストールされたアプリケーションプログラムの実行によって投稿内容をユーザに閲覧させる、いわゆるネイティブ型の構成としたが、本発明は、この構成に限られない。例えば、管理サーバ１０側で表示の制御・態様を記述したウェブ画面を作成して端末装置２０に送信する一方、端末装置２０側のブラウザがウェブ画面を表示するとともに、ウェブ画面（タッチパネル）に対する操作に応じた処理を実行するウェブ型の構成としても良い。

　図２０は、ウェブ型とした応用例に係るシステム１において、投稿内容の提供、評価、再提供等の機能が実行される際に、管理サーバ１０および当該端末装置２０で構築される機能ブロックを示す図である。
　端末装置２０では、表示の制御が記述されたウェブ画面を、表示パネル２１０におけるに入力部２１１、表示部２１５に表示させるためのブラウザ２３３が構築される。
　一方、管理サーバ１０側では、提供部１２５、再提供部１２６が、それぞれ管理部１２１から供給される情報に基づき、ウェブ画面を作成して、端末装置２０に送信する構成となる。このため、提供部１２５、再提供部１２６が、ブラウザ２３３を介して表示パネル２１０に画面を間接的に表示させることになる。

＜提供部、再提供部、表示制御部＞
　実施形態や応用例では、提供部１２５、再提供部１２６および表示制御部２３２を別個のブロックとして記載しているが、端末装置２０で閲覧させる内容を規定しているのは、提供部１２５、再提供部１２６であって、表示制御部２３２は表示パネル２１０の仕様に合わせて表示を駆動制御しているに過ぎない。このため、実質的には、提供部１２５、再提供部１２６が投稿内容を閲覧可能に提供する、と言ってなんら差し支えない。

１…システム、１０…管理サーバ、２０…端末装置、１０１、２０１…ＣＰＵ、１１８…データベース、１２１…管理部、１２５…提供部、１２６…再提供部、２１１…入力部、２１５…表示部、２１６…肯定応答用ボタン、２１７…否定応答用ボタン、２３１…操作検出部、２３２…表示制御部。
 

Claims (8)

1. 　投稿ユーザが投稿した投稿内容を、当該投稿ユーザと関係が構築されている関係ユーザに閲覧可能に提供する提供部と、
   　前記投稿内容に対する前記関係ユーザからの評価に基づいて評価値を決定する評価部と、
   　前記評価値が所定の基準を充足した場合に、前記関係ユーザ以外の他のユーザに前記投稿内容を閲覧可能に提供する再提供部と、
   　を備えるメッセージ管理装置。
2. 　前記他のユーザとは、前記関係ユーザと関係が構築されているユーザの一部または全員を含む
   　ことを特徴とする請求項１に記載のメッセージ管理装置。
3. 　前記提供部は、前記投稿ユーザが投稿した投稿とともに、閲覧可能なユーザに操作可能な応答用ボタンを表示部に表示可能に提供し、
   　前記評価部は、前記投稿内容に対する前記応答用ボタンの操作を受け付けて、受け付けた回数に基づいて評価値を決定する
   　ことを特徴とする請求項１または請求項２に記載のメッセージ管理装置。
4. 　前記応答用ボタンには、前記投稿内容に対して肯定を示す肯定応答用ボタンと、否定を示す否定応答用ボタンとを含み、
   　前記再提供部は、前記肯定応答用ボタンの操作の回数と、前記否定応答用ボタンの操作の回数とに基づいて前記評価値を決定する
   　ことを特徴とする請求項３に記載のメッセージ管理装置。
5. 　前記再提供部は、前記評価値に応じて前記投稿内容を閲覧可能にする人数を制限する
   　ことを特徴とする請求項１に記載のメッセージ管理装置。
6. 　前記再提供部は、前記投稿ユーザと関係が構築されている関係ユーザとして新たなユーザが加わった場合、前記投稿ユーザが投稿した過去の投稿内容のうち、前記評価値が所定の基準を充足した投稿内容の一部または全部を、前記新たなユーザに閲覧可能に提供する
   　ことを特徴とする請求項１に記載のメッセージ管理装置。
7. 　投稿ユーザが投稿した投稿内容を、当該投稿ユーザと関係が構築されている関係ユーザに閲覧可能に提供するステップと、
   　前記投稿内容に対する前記関係ユーザからの評価に基づいて評価値を決定するステップと、
   　前記評価値が所定の基準を充足した場合に、前記関係ユーザ以外の他のユーザに前記投稿内容を閲覧可能に提供するステップと、
   　を備えるメッセージ管理方法。
8. 　複数のユーザのそれぞれによって各々が操作される端末装置と通信可能なコンピュータを、
   　前記複数のユーザのうち、一の投稿ユーザが端末装置を操作することによって投稿した投稿内容を、当該投稿ユーザと関係が構築されている関係ユーザが操作する端末装置に閲覧可能に提供する提供部、
   　前記投稿内容に対する前記関係ユーザからの評価に基づいて評価値を決定する評価部、および、
   　前記評価値が所定の基準を充足した場合に、前記関係ユーザ以外の他のユーザが操作する端末装置に前記投稿内容を閲覧可能に提供する再提供部、
   　として機能させるプログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images