(57)【要約】【課題】議論ツリーの発言数が膨大になると、議論ツリーを表示や印刷をするときに、不要な発言により利便性を損なうことになる。また、膨大な発言の中からユーザが着目している発言に関連する項目のみ表示や印刷を行いたい場合に、表示項目から注目ノードを選択して表示や印刷を行うことが煩雑になる。【解決手段】表示部のビューサイズに応じて表示部に表示する発言数を決定し、議論ツリーの発言からおよび発言属性から、表示する発言を自動で決定する。【選択図】図４
2014170400.tif 000002
【特許請求の範囲】
【請求項１】
複数のメッセージをツリー構造で保持する保持手段と、
出力装置におけるビューサイズに応じて表示可能なメッセージ数を算出する算出手段と、
前記保持手段で保持されたメッセージのうちから、前記算出手段で算出された表示可能なメッセージ数以下の表示メッセージを決定する決定手段と
を備えるメッセージ管理装置。
【請求項２】
メッセージの表示優先度を判定する優先度判定手段をさらに備え、
前記決定手段は、前記優先度判定手段で判定されたメッセージの表示優先度に基づいて前記表示メッセージを決定することを特徴とする請求項１に記載のメッセージ管理装置。
【請求項３】
前記優先度判定手段は、メッセージのユーザ属性、重要度属性、ノード属性およびテーマ属性のうちの少なくとも１つに基づいてメッセージの表示優先度を判定することを特徴とする請求項２に記載のメッセージ管理装置。
【請求項４】
メッセージ間の関連度を判定する関連度判定手段をさらに備え、
前記決定手段は、前記関連度判定手段で判定された関連度が所定閾値以上の複数のメッセージを結合可能なメッセージと決定し、前記結合可能なメッセージのうちから１つの表示メッセージを決定することを特徴とする請求項１から３のいずれかに記載のメッセージ管理装置。
【請求項５】
前記出力装置は、表示装置であり、
前記ビューサイズは、前記表示装置の物理サイズまたは画素数とすることを特徴とする請求項１から４のいずれかに記載のメッセージ管理装置。
【請求項６】
前記出力装置は、仮想表示装置であり、
前記ビューサイズは、前記仮想表示装置の論理サイズとすることを特徴とする請求項１から４のいずれかに記載のメッセージ管理装置。
【請求項７】
前記仮想表示装置の論理サイズは、印刷用紙のサイズまたは印刷用紙のサイズに応じた画素数とすることを特徴とする請求項６に記載のメッセージ管理装置。
【請求項８】
前記仮想表示装置の論理サイズは、複数枚の印刷用紙のサイズの合計または複数枚の印刷用紙のサイズの合計に応じた画素数とすることを特徴とする請求項６に記載のメッセージ管理装置。
【請求項９】
前記仮想表示装置の論理サイズは、複数の表示装置の物理サイズまたは画素数の合計とすることを特徴とする請求項６に記載のメッセージ管理装置。
【請求項１０】
前記算出手段、前記出力装置の表示方向を取得し、取得した表示方向に応じてそれぞれ横方向および縦方向に表示可能なメッセージ数を算出することを特徴とする請求項１から９のいずれかに記載のメッセージ管理装置。
【請求項１１】
前記出力装置は、複数であり、
前記算出手段は、第１の出力装置と異なる、第２の出力装置におけるビューサイズに応じて、前記第１の出力装置で表示可能なメッセージ数を算出することを特徴とする請求項１から１０のいずれかに記載のメッセージ管理装置。
【請求項１２】
複数の出力装置から優先出力装置を決定する優先出力装置決定手段をさらに備え、
前記第２の出力装置は、前記優先出力装置決定手段によって決定された優先出力装置であることを特徴とする請求項１１に記載のメッセージ管理装置。
【請求項１３】
前記保持手段は、メッセージ間の関係をノード間のエッジとして保持し、
前記決定手段で決定された表示メッセージ間の関係を示すエッジを再構築する手段をさらに備えることを特徴とする請求項１から１２のいずれかに記載のメッセージ管理装置。
【請求項１４】
前記決定手段は、表示メッセージの数が前記表示可能なメッセージ数以下になるまで決定処理を繰り返すことを特徴とする請求項１から４のいずれかに記載のメッセージ管理装置。
【請求項１５】
複数のメッセージをツリー構造で保持する保持ステップと、
出力装置におけるビューサイズに応じて表示可能なメッセージ数を算出する算出ステップと、
前記保持ステップで保持されたメッセージのうちから、前記算出ステップで算出された表示可能なメッセージ数以下の表示メッセージを決定する決定ステップと
を備えるメッセージ管理方法。
【請求項１６】
コンピュータを請求項１乃至１１のいずれかに記載のメッセージ管理装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はメッセージ管理装置、メッセージ管理方法およびプログラムに関する。
【背景技術】
【０００２】
場所や時間に縛られないコミュニケーション手段として、ｃｈａｔやマイクロブログ、ＳＮＳ等が普及している。そこで、発言（メッセージと呼ばれることもあり）に賛成、反対、補足、代案などの属性を発言者が選択して付与し、発言の引用関係をツリー構造で表示することにより、議論の経緯の把握を容易にする情報可視化方法がある。
【０００３】
また、複数の項目の全てが表示領域内に同時に表示されるように、複数の項目それぞれの表示サイズを各項目の属性値に応じて決定することにより、一覧から目的の項目を探しやすくする方法が提案されている（特許文献１参照）。
【０００４】
さらに、エンティティの属性として評判又は影響度のスコアを付加して、ランク付けされたエンティティのサブセットの表示を行う方法が提案されている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１７１３４６号公報
【特許文献２】特表２０１２−５１０６６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
コミュニケーション手段の規模拡大や、センサやロボットなどが自動的に発言を行うことにより、近年、コミュニケーション手段で扱う発言数が爆発的に増加している。このため、コミュニケーション手段を利用するユーザが発言および発言の引用関係を正確に把握することが困難になりつつある。特許文献１および２は、ビューのサイズに応じて、表示される発言ノードの数、および、どの発言ノードが表示されるかを適切に決定する技術ではない。そのため、一覧に表示する表示項目数が多い場合、議論の流れを把握しにくい課題がある。
【課題を解決するための手段】
【０００７】
本発明のメッセージ管理装置は、複数のメッセージをツリー構造で保持する保持手段と、表示装置におけるビューサイズに応じて表示可能なメッセージ数を算出する算出手段と、前記保持手段で保持されたメッセージのうちから、前記算出手段で算出された表示可能なメッセージ数以下の表示メッセージを決定する決定手段とを備えることを特徴とする。
【発明の効果】
【０００８】
本発明によって、発言数が多い場合でも、ビューに対して適切な数の発言を含む議論ツリーをユーザに表示することにより、ユーザが所望の発言を確認する作業を容易に行えるようになる。
【図面の簡単な説明】
【０００９】
【図１】本発明のシステム構成例を示す図である。
【図２】実施例１に係る電子掲示板システムの画面表示例を示す図である。
【図３】実施例１に係る計算処理を説明するための議論ツリーの模式図とデータスキーマ例を示す図である。
【図４】実施例１に係る議論ツリーの画面表示例を示す図である。
【図５】本実施例１に係る議論ツリーの表示処理のユーザ接続管理部に関するフローチャートである。
【図６】実施例１に係る議論ツリーの表示を行うためのグラフ記述データ例を示す図である。
【図７】実施例１に係るノード削減時のグラフ記述データを作成するための処理フローを示す図である。
【図８】実施例２に係る議論ツリーの画面表示例を示す図である。
【図９】実施例２に係るビューサイズ取得部に関するフローチャートである。
【図１０】実施例３に係るビューサイズ取得部に関するフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための最良の形態について図面を参照して説明する。尚、以下の実施例は特許請求の範囲に係る本発明を限定するものでなく、また本実施例で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１１】
［実施例１］
＜システム構成＞
図１は、本実施例のシステム構成を示すブロック図である。
【００１２】
サーバ１は、本明細書では、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤ（図示せず）、通信部１１等を含む。電子掲示板システム１０は、サーバ１の上に構成されたシステムである。電子掲示板システム１０は、ネットワーク５を介して接続された１つ以上のクライアント、例えば、クライント２〜４からアクセスして利用するクラウド上のサービスである。クライアント２〜４は、例えば、パーソナルコンピュータ、タブレットまたはスマートフォンなどとしてもよい。利用者はクライアント２〜４におけるＷｅｂブラウザ等のクライアントアプリケーションを操作することにより、電子掲示板システム１０によって提供されるユーザインタフェースを利用することができる。電子掲示板システム１０の後述のフローチャートで示す手順は、サーバ１のＲＡＭ、ＲＯＭ、ＨＤＤ（図示せず）のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００１３】
電子掲示板システム１０は、議論ツリー保持部２０、議論ツリー構成部２１、ユーザ接続管理部２２およびメッセージ入力部２３を含む。
【００１４】
ユーザ接続管理部２２は、通信部１１を介して、電子掲示板システム１０に接続する複数の利用者からの入力情報及び各利用者へ表示する出力情報の制御を行う。ユーザ接続管理部２２が取得した利用者からの入力情報は、議論ツリー構成部２１に渡され、議論ツリーに構成される。また、ユーザ接続管理部２２は議論ツリー構成部２１から議論ツリーの情報を取得して、利用者への表示する出力情報とする。ユーザ接続管理部２２は、利用者毎に、複数の処理部で利用者に対する情報の入出力を利用者単位に管理する。これらの処理部は、制御部４０、ビューサイズ取得部４１、表示ノードサイズ算出部４２、メッセージ間関連度判定部４３、メッセージ優先度判定部４４及び描画データ作成部４５を含む。各処理部の詳細は後述する。
【００１５】
メッセージ入力部２３は、センサやロボットなどとして自動的に発言及びその他情報を議論ツリー構成部２１に入力する。
【００１６】
議論ツリー構成部２１は、ユーザ接続管理部２２及びメッセージ入力部２３から受信した情報から、複数のメッセージ（発言とも呼ばれる）をツリー構造で保持する議論ツリーを構成する。構成される議論ツリーにおいて、各ノードはそれぞれ１つの発言を示す。また、発言間の情報を保持するようにノード間のエッジが構成される。ここで、発言間の情報は、親ノードの発言（以下、対象発言）に対する賛成、反対または補足などの情報である。
【００１７】
議論ツリー保持部２０は、議論ツリー構成部２１によって構成された議論ツリーを保持する。
【００１８】
＜電子掲示板の表示画面＞
図２は、本実施例においてクライアント側の表示部で表示される、電子掲示板システムの画面表示例である。クライアント２（例えば、パーソナルコンピュータ）は、描画部５０を介して電子掲示板システムの画面２００を第１の表示部５１（例えば、モニタ）に表示する。
【００１９】
電子掲示板システムの画面２００は、議論ツリー表示領域２０１、注目ノード表示領域２０２および発言入力領域２０３を含む。各領域では、クライアント２の入力手段とするマウスなどのポインティングデバイスまたはキーボード（図示せず）を用いて、対象発言の選択、発言の入力、または処理の選択を行うことができる。
【００２０】
議論ツリー表示領域２０１は、議論ツリーを表示するビューである。図２に示す例において、議論の全てのノードを含む議論ツリー（以下、全議論ツリー）が表示されている。注目ノード表示領域２０２は、利用者が現在選択している注目ノードおよびその親ノードを表示するビューである。発言入力領域２０３は、利用者が新しい発言を入力するためのビューです。
【００２１】
利用者は、議論ツリー表示領域２０１において表示されている議論ツリーのノードを選択することで、新しい発言を入力する際の対象発言、または議論の経緯を確認すべき発言を選択することができる。注目ノード表示領域２０２は、ここで選択されたノードとその親ノードを表示する。また、発言入力領域２０３は、ここで選択されたノードの発言を、新しい発言を入力する際の対象発言として表示する。
【００２２】
図２に示す例において、全議論ツリーが表示されているが、利用者は、議論ツリー表示領域２０１の下部２１１において全議論ツリー表示または議論経緯確認のどちらかを選択することができる。ここで、全議論ツリー表示はデフォルトで選択される。議論経緯確認が選択される場合に、利用者が注目しているノード（注目ノード）２１０に至るまでの議論の経緯を把握するために必要なノードのみを議論ツリーとして表示する。また、必要なノードを判定するためにどの属性を優先的に用いるかを示す優先属性が、優先属性の入力欄２１４において入力することができる。本実施例において、優先属性としては、ユーザ属性または、重要度属性または、ノード属性または、テーマ属性の何れか１つ以上を選択することが可能である。各属性の詳細は後述する。
【００２３】
なお、全議論ツリー表示が選択される場合に、議論ツリー表示領域２０１において、全議論ツリーのノード数が多い場合、電子掲示板システムは、スクロールバーを利用した部分表示、または全議論ツリーを表示するために縮小表示を行うことができる。
【００２４】
なお、本実施例における議論ツリー表示領域２０１においては、１つのノードにつき、発言者、発言ＩＤおよび発言内容が表示される。図２に示すように、ノードをつなぐ線と線に付された発言属性で、ノード間の関係を示す。発言者が新しい発言を入力する前に、後述する発言入力領域２０３で発言属性を選択する。発言者が選択した発言属性は議論ツリーを構成する情報として、図３に示すデータベースに記録される。
【００２５】
注目ノード表示領域２０２には、議論ツリー表示領域２０１において選択された注目ノード２１０およびその親ノードが表示されている。１つ目のノードは親ノードであり、その発言者２２１、発言ＩＤ２２２および発言内容２２３が表示されている。２つ目のノードは注目ノード２１０であり、その発言者２２４、発言ＩＤ２２５および発言内容２２６が表示されている。また、この２つの発言の関係は「補足」という発言属性で表示されている。
【００２６】
発言入力領域２０３は、利用者が注目しているノード２１０に対して、新しい発言を入力するためのビューである。発言入力領域２０３の上部２３１には、対象発言の情報として、対象発言の発言ＩＤおよび発言内容がそれぞれ表示欄２３２および２３３に表示される。表示欄２３２および２３３に表示される対象発言の発言ＩＤおよび発言内容は、それぞれ注目ノード表示領域２０２に表示されるノード２１０の発言ＩＤ２２５および発言内容２２６に一致している。発言入力領域２０３の下部には、発言属性の選択欄２３４、および新規発言の入力欄２３５が表示される。本実施例における発言属性の選択肢は「補足」、「反対」、「賛成」、「質問」および「新規」を含む。電子掲示板システムは、利用者によって発言属性の選択欄２３４と新規発言の入力欄２３５に入力された情報から、対象発言に対する新規発言を議論ツリーへ追加する。その時、新規発言は、選択した対象発言の子ノードとして表示される。
【００２７】
＜電子掲示板に係るデータベース＞
図３は、本実施例における議論の経緯を把握するために必要なノードを抽出する計算処理を説明するための議論ツリーの模式図とデータスキーマ例を示す図である。
【００２８】
図３（ａ）は議論ツリーの模式図を示しており、図３（ｂ）はデータスキーマ３０２を示している。議論ツリーの模式図（３０１）のノードに記載した文字列ＸＸ：Ｙにおいて、ＸＸは図３（ｂ）における発言ＩＤ３０３の値を示し、Ｙは図３（ｂ）における発言者ＩＤ３０７の値を示す。データスキーマ３０２は、発言ＩＤ３０３、対象発言ＩＤ３０４、参照元発言数３０５、参照元発言ＩＤリスト３０６、発言者ＩＤ３０７及び重要度３０８を含む。発言ＩＤ３０３は、発言を特定するための情報である。対象発言ＩＤ３０４は、発言を入力する際の対象発言を特定するための情報である。参照元発言数３０５は、発言を対象発言とした新たな発言の数を示す。参照元発言ＩＤリスト３０６は、発言を対象発言とした新たな発言のＩＤリストを示す。
【００２９】
例えば、発言ＩＤが５のノード（以降、「発言ＩＤがＸＸのノード」を「ノードＸＸ」と記載する）に着目する。ノード５は、ノード４に対する発言であるので、対象発言ＩＤ３０４は４である。ノード６およびノード７がノード５を対象発言としているので、ノード５の参照元発言数３０５は２となり、ノード５の参照元発言ＩＤリスト３０６は６と７となる。また、ノード２およびノード１０を対象とした発言はないので、ノード２およびノード１０の参照元発言数３０５は０となり、ノード２およびノード１０の参照元発言ＩＤリスト３０６は空である。新たな発言が追加されると、データスキーマ３０２に新たな行が追加される。また、新たな発言の対象発言となったノードの参照元発言数３０５と参照元発言ＩＤリスト３０６が更新される。
【００３０】
発言者ＩＤ３０７は、発言者を特定する情報であり、氏名やメールアドレス等とすることができる。重要度３０８は、発言の参照などに応じてメッセージ間関連度を算出する。重要度の算出方法としては、発言ノード間のリンク関係について一般的なＰａｇｅＲａｎｋ（登録商標）アルゴリズムによって算出する方法や、その他の独自の算出方法などでも良い。
【００３１】
＜議論ツリーの表示画面＞
図４は、本実施例における議論ツリーの表示画面例を示す図である。
【００３２】
ユーザによって、ノード４１０が選択され、さらに、図２の議論経緯確認２１３が選択されると、ユーザ接続管理部２２は、議論ツリーとして表示される発言ノードを決定する。そして、ユーザ接続管理部２２の描画データ作成部４５によって描画データが作成され、クライアントに送信され、クライアント側の表示部に表示される。
【００３３】
ユーザ接続管理部２２のビューサイズ取得部４１はクライアント側の表示部で議論ツリーを表示するためのビューサイズを取得する。そして、ユーザ接続管理部２２は、表示部のビューサイズに応じて、議論ツリーとして表示可能なノード数（表示可能なメッセージ数）を算出する。
【００３４】
図４（ａ）は、クライアント３の表示部で表示される場合の議論ツリーの表示画面例を示している。ここで、クライアント３は、表示画素数の多いタブレットであり、横４８０ドット、縦６４０ドット（以降、「横Ｘドット、縦Ｙドット」を、「Ｘドット×Ｙドット」と記載する）のＶＧＡ（Ｖｉｄｅｏ  ｇｒａｐｈｉｃｓ  Ａｒｒａｙ）表示を使用している。図４（ａ）に示すように、議論ツリー４０１は、横方向に５ノード、縦方向に６ノードの表示が可能である。
【００３５】
また、図４（ｂ）は、クライアント４の表示部で表示される場合の議論ツリーの表示画面例を示している。ここで、クライアント４は、表示画素数の少ないスマートフォンであり、２４０ドット×３２０ドットのＱＶＧＡ（Ｑｕａｒｔｅｒ  ｓｉｚｅ  Ｖｉｄｅｏ  Ｇｒａｐｈｉｃｓ  Ａｒｒａｙ）表示を使用している。図４（ｂ）に示すように、議論ツリー４０６は、横方向に２ノード、縦方向に３ノードの表示が可能である。
【００３６】
図４（ａ）と図４（ｂ）を比較すると、図４（ｂ）の表示画面例では、図４（ａ）の議論ツリー４０１に表示されているノードのうち４つのノードが表示されている。すなわち、ユーザによって選択されたノード４１０、ならびにノード４１０と関連が強いため、表示優先順位が高いと判定したノード４０７、ノード４０８およびノード４０９が表示されている。図４（ａ）の議論ツリー４０１に表示されているその他の発言ノードは図４（ｂ）に非表示となる。図４（ｂ）の議論ツリー４０６に表示されているノード４０７〜４１０は、マウスなどのポインティングデバイス、またはキーボードを用いて選択することができる。また、非表示のメニュー（図示せず）などで発言ノードを再表示することも可能である。
【００３７】
＜議論ツリーの表示処理＞
ユーザ接続管理部２２は通信部１１を介してクライアントからユーザの選択情報を取得し、議論ツリー構成部２１を介して議論ツリー保持部２０から議論ツリーの情報を取得する。そして、ユーザ接続管理部２２は、議論ツリーの情報から表示すべきノード（表示ノード）を抽出し、描画データ作成部４５を介して描画データを作成する。作成した描画データは、クライアントに送信され、クライアント側の表示部に表示される。
【００３８】
以下、図５を参照して、本実施例における議論ツリーの表示処理フローについて詳細に説明する。
【００３９】
ステップＳ５０１において、制御部４０は、図２の全議論ツリー表示２１１から議論経緯確認２１３への切り替え、ユーザによって選択されたノードの変更、または、優先属性入力欄２１４に入力された優先属性の変更などを、表示リクエストとして受信する。制御部４０は、ユーザによって選択されたノードおよび入力された優先属性を一時的に保存する。
【００４０】
ステップＳ５０２において、ビューサイズ取得部４１は、表示部で表示する発言ノードを決定するためのノード表示条件を取得する。ノード表示条件は、表示部の情報であり、ノード表示条件に基づいて議論ツリーを表示するためのビューサイズが取得される。本実施例において、ＶＧＡ表示では、ビューサイズとして４８０×６４０ドット などが取得できる。ノード表示条件は事前にアプリケーションのメニューなどで設定する方法などでも良い。
【００４１】
ステップＳ５０３において、制御部４０は、議論ツリー構成部２１より議論ツリーに関する情報を得る。
【００４２】
ステップＳ５０４において、表示ノードサイズ算出部４２は、議論ツリーのノードを表示するのに必要なサイズ（表示ノードサイズ）を算出する。議論ツリーの各ノードの表示画素数（例えば、７０ドット×８０ドットなど）とステップＳ５０３で得られた議論ツリーに関する情報とから表示ノードサイズを算出することができる。
【００４３】
ステップＳ５０５において、表示ノードサイズ算出部４２は、ステップＳ５０２で取得されたビューサイズと、ステップＳ５０４で算出された表示ノードサイズを比較する。
【００４４】
本実施例において、ビューサイズが、４８０ドット×６４０ドット（ＶＧＡ表示）で、議論ツリーの表示ノードサイズが、４００ドット×６００ドットの場合は、議論ツリーがビューサイズに収まるので、ステップ５１３の処理へ進む。
【００４５】
また、ビューサイズが、２４０ドット×３２０ドット（ＱＶＧＡ表示）で、議論ツリーの表示ノードサイズが、４００ドット×６００ドットの場合は、議論ツリーがビューサイズに収まらないので、ステップＳ５０６へ進む。そして、ステップＳ５０６からステップＳ５１１によって、議論ツリーとして表示されるノード（表示ノード）を削減して、表示ノードサイズがビューサイズ以下になるための処理を行う。
【００４６】
ここでビューサイズと議論ツリーの表示ノードサイズとを比較することにより、議論ツリーがビューサイズに収まるか否かを判定する手法を説明したが、これに限定されない。表示ノードサイズ算出部４２はビューサイズからビューに表示可能なメッセージ数を算出し、議論ツリーの表示ノード数と比較し、表示ノード数が表示可能なメッセージ数を超えれば、議論ツリーがビューサイズに収まらないと判定することもできる。あるいは、表示ノードサイズ算出部４２は、ビューサイズからそれぞれ横方向および縦方向において表示可能なメッセージ数を算出し、横方向および縦方向の議論ツリーの表示ノード数と比較する。横方向および縦方向のいずれかにおいて表示ノード数が表示可能なメッセージ数を超えれば、議論ツリーがビューサイズに収まらないと判定することもできる。
【００４７】
ステップＳ５０６において、メッセージ間関連度判定部４３は、ノード間の関連度を算出する。ノード間の関連度の算出方法としては、ノードパスの長さ（ｄｉｓｔａｎｃｅ）、近接中心性（Ｃｌｏｓｅｎｅｓｓ  Ｃｅｎｔｒａｌｉｔｙ）などで算出する方法が考えられる。また、発言の類似度でノード間の関連度を算出しても良い。
【００４８】
ステップＳ５０７において、メッセージ間関連度判定部４３は、ステップＳ５０６で算出されたノード間の関連度がメッセージ間関連度判定部４３によって設定された所定閾値以上の場合に、それらのノードをまとめることが可能な結合ノードだと判定する。
【００４９】
ステップＳ５０８において、メッセージ間関連度判定部４３は、ステップＳ５０７で判定された結合可能なノードの代表ノードを決定する。代表ノードの決定方法として、図３に示した重要度３０８などから、結合可能なノードのうち優先度の高いノードを判定して代表ノードを決定することで、ノードをまとめる。
【００５０】
なお、代表ノードの決定は、重要度３０８だけでなく、他の方法として、ユーザに指定された他の優先属性、すなわち、ユーザ属性、ノード属性、または、テーマ属性に従ってもよい。また、これらの優先属性を順位付けすることにより複数の属性を組み合わせた順位によって代表ノードを決定してもよい。ユーザ属性に従って代表ノードを決定する場合は、発言者ＩＤ３０７が一致するノードから重要度の高いノードを代表ノードと決定する。ノード属性に従って代表ノードを決定する場合は、ユーザによって選択されたノードに対して、ノード間の関連度の高いノードを代表ノードと決定する。テーマ属性に従って代表ノードを決定する場合は、各ノードの発言情報をもとにテーマに対する発言の類似度検索を行い類似度の高い順に代表ノードを決定する。テーマと発言の類似度の算出方法は、テーマが発言中に現れる相対的な重みづけ（ＴＦ−ＩＤＦ：Ｔｅｒｍ  Ｆｒｅｑｕｅｎｃｙ−Ｉｎｖｅｒｓｅ  Ｄｏｃｕｍｅｎｔ  Ｆｒｅｑｕｅｎｃｙ）による算出方法が考えられるが、ＴＦ−ＩＤＦに限定するものではない。代表ノードの算出する方法として、算出方法例を記載したが、これらの方法に限定するものではない。また、これらの組み合わせにより算出する方法でも良い。
【００５１】
ステップＳ５０９において、メッセージ優先度判定部４４は、ユーザによって入力された優先属性に従って、ノードをまとめた後の各ノードの優先度（表示優先度）を判定する。優先属性として、ユーザ属性（発言者ＩＤ３０７）または、重要度属性（重要度３０８）または、ノード属性（図示せず）または、テーマ属性（図示せず）の何れか１つ以上を選択することが可能である。メッセージ優先度判定部４４は、こられの属性のうち１つまたは複数の属性からノードの優先度を判定する。このステップにおける優先度の判定は、ステップＳ５０８における代表ノードを決定するために行われる優先順位の判定と類似の処理で行うことができる。重要度属性が選択された場合に、重要度が高いノードを優先度の高いノードと判定することができる。ユーザ属性が選択された場合は、発言者ＩＤ３０７が一致するノードを優先度の高いノードと判定することができる。ノード属性が選択された場合は、ユーザによって選択されたノードに対して、ノード間の関連度の高いノードを優先度の高いノードと判定することができる。テーマ属性が選択された場合は、各ノードの発言情報をもとにテーマに対する発言の類似度検索を行い類似度の高い順に優先度の高いノードを判定することができる。
【００５２】
ステップＳ５１０において、メッセージ優先度判定部４４は、ステップＳ５０９で算出されたノードの優先度がメッセージ優先度判定部４４によって設定された閾値と比較を行う。範囲外の場合（優先度が低いノードの場合）に、それらのノードを破棄することが可能な破棄ノードだと判定する。
【００５３】
ステップＳ５１１において、メッセージ優先度判定部４４は、ステップＳ５１０で判定された破棄可能なノードを非表示ノード（破棄ノード）とする。
【００５４】
また、ステップＳ５０６からステップＳ５０８のノードまとめ処理及び、ステップＳ５０９からステップＳ５１１のノード破棄処理によるノードの削減処理は、必ずしも両方の処理を行う必要はない。表示ノードサイズがビューサイズ以下になるための処理であれば、処理の順序や特定の処理のみ行ってもよい。
【００５５】
ステップＳ５１２において、制御部４０は、ステップＳ５０６からステップＳ５１１の処理による表示ノード数の変更があるか判定を行う。表示ノード数の変更がある場合に、処理はステップＳ５０５へ進み、ステップＳ５０５において、制御部４０は、ビューサイズと、ステップＳ５０６からステップＳ５１１の処理による表示ノード数変更後の算出された表示ノードサイズとを比較する。これらのステップＳ５０５からステップＳ５１２の処理（決定処理）を、表示ノードサイズがビューサイズ以下になる（決定処理後の表示メッセージの数が、表示可能なメッセージ数以下になる）まで繰り返す。一方、表示ノード数の変更がない場合に、処理はステップＳ５１３へ進む。
【００５６】
ステップＳ５１３において、描画データ作成部４５は、表示ノード間のエッジデータ（ノード間の結合線）を作成する。図３で示されたデータスキーマには、ステップＳ５０５からステップＳ５１２の処理で非表示となったノードが存在する場合、非表示となったノード情報から表示ノード間（表示メッセージ間）のエッジデータを再構築する。
【００５７】
ステップＳ５１４において、制御部４０は、表示ノード（表示メッセージ）をデータベースに登録する。すなわち、議論経緯確認が選択された場合に利用者側の表示部で表示するための議論ツリーデータ（データスキーマ）を作成する。
【００５８】
ステップＳ５１５において、描画データ作成部４５は、ステップＳ５１４で作成された議論ツリーデータ（データスキーマ）から表示部で表示するための描画データを作成する。
【００５９】
ステップＳ５１６において、制御部４０は、表示リクエストの返信として、ステップＳ５１５で作成された描画データをクライアントに送信し、クライアント側の表示部で表示する。
【００６０】
＜描画データの作成＞
図６は、本実施例における描画データ作成部４５が作成する、議論ツリーの表示を行うためのグラフモデルデータ例を示す図である。図６に示すように、グラフモデルデータは、発言ノードとノード間エッジのデータを含む。
【００６１】
グラフモデルデータ６０１は、ノード削減前の全ノードのグラフ記述データであり、発言ノード数が３個、ノード間エッジが２個の議論ツリーを表示するためのデータを示す。
graph
[               node  [   id 001]
node  [   id 002]
node  [   id 003]
edge  [   source 002    target 001]
edge  [   source 003    target 002]
]
【００６２】
グラフモデルデータ６０１においては、発言ノードとして、id 001のnode、id 002のnode、およびid 003のnodeが含まれる。グラフモデルデータ６０１の議論ツリーの表示ノード数が３となる。また、エッジとして、id 002のnodeからid 001のnodeへのedge、およびid 003のnodeからid 002のnodeへのedgeが含まれる。
【００６３】
グラフモデルデータ６０２は、表示ノード数の変更に応じて作成されたグラフ記述データである。ここで、ビューサイズ取得部４１の取得した表示部のビューサイズが小さく、表示部で表示可能なメッセージ数が２と判定される。そして、ステップＳ５０５においてビューサイズ（すなわち、２）が表示ノード数（すなわち、３）以下であるため、ステップＳ５０６からステップＳ５１１の表示ノード削減処理による表示ノード数変更がある。表示ノード削減処理の結果、id 002のnodeが非表示と判定された。描画データ作成部４５は、id 002のnodeを削除したグラフ記述データを作成する。また、削除したノードに関連するエッジを再構築して表示ノード間のエッジを作成する。図６のグラフモデルデータ６０２は、エッジの再構築を行ったノード削減後のグラフ記述データを示す。
graph
[               node  [   id 001]
node  [   id 003]
edge  [   source 003    target 001]
]
【００６４】
図６のグラフモデルデータ６０２に示すように、描画データ作成部４５は、id 002のnodeの削減と伴い、id 002のnodeをつなぐedgeを削除した。すなわち、id 002のnodeからid 001のnodeへのedge及び、id 003のnodeからid 002のnodeへのedgeを削除した。また、新たに、削除したエッジの端点を繋ぐエッジとして、id 003のnodeからid 001のnodeへのedgeを生成する。なお、描画データ作成部４５は、複数の連続したノードが削減された場合も同様の処理を行うことで、ノードを削減した描画を行うことが可能となる。
【００６５】
図７は、本実施例の描画データ作成部４５におけるノード削減時のグラフ記述データを作成するための処理フローを示す図である。
【００６６】
ステップＳ７０１において、描画データ作成部４５は、ビューサイズ取得部４１が取得したビューサイズが小さい場合に表示ノード削減処理を行ったために、表示ノード数に変更があるか判定を行う。
【００６７】
ステップＳ７０１で表示ノード数に変更があると判定された場合、ステップＳ７０２において、描画データ作成部４５は、削除されたノードの検出を行う。図６のグラフモデルデータ６０１におけるid 002のnodeが、削除されたノードとして検出される。
【００６８】
さらに、ステップＳ７０３において、描画データ作成部４５は、削除されたノード間のエッジの検索を行う。
【００６９】
ステップＳ７０４において、描画データ作成部４５は、削除されたノード間のエッジを削除する。図６のグラフモデルデータ６０１における、id 002のnodeからid 001のnodeへのedge及び、id 003のnodeからid 002のnodeへのedgeが削除される。
【００７０】
ステップＳ７０５において、描画データ作成部４５は、表示ノード間エッジの作成を行う。ここで、図６のグラフモデルデータ６０２における、id 003のnodeからid 001のnodeへのedgeが作成される。
【００７１】
以上説明した本実施例によれば、議論ツリーの描画において、ノード削減によってエッジデータが不正になった場合も、正しく議論ツリーの表示が行える。
【００７２】
本実施例によって、発言数が多い議論ツリーにおいても、ユーザが所望の発言を確認する作業を容易に行えるようになる。また、議論一覧から目的の項目を探しやすくする表示を行うことが可能となる。本実施例では、近年のコミュニケーション手段における発言（ノード）や発言間情報（エッジ）が増加する場合においても、ビューサイズに応じて表示されるノード数を変更することで、議論の流れを把握することが容易に行えるメッセージ管理システムを提供する。
【００７３】
［実施例２］
近来、スマートフォンやタブレットノードなど端末は、重力向きを検知する加速度センサが搭載されていて、ディスプレイの向きを検知することができるようになった。ディスプレイの向きに応じて画像の表示方向を切り替えるのは一般的な手法となってきた。本実施例において、表示部における議論ツリーの表示方向を取得し、表示方向に応じて表示可能なメッセージ数を算出する仕組みを提供する。
【００７４】
また、実施例１において、表示可能なメッセージ数を算出するためのノード表示条件はディスプレイなどの表示部に関する情報である。本実施例において、ノード表示条件は、表示部に関する情報だけでなく、印刷装置が選択されている場合に印刷用紙サイズとすることができる。たとえば、Ａ４用紙かつ６００ｄｐｉの解像度などがノード表示条件として取得できる。この場合に、ビューサイズ取得部４１の取得したビューサイズが５０４０ドット×７１２８ドットとなる。また、印刷方法としてポスター印刷（２ｘ２の４枚で印刷）を選択している場合は、Ａ４×４枚の用紙かつ６００ｄｐｉの解像度などがノード表示条件として取得できる。この場合に、ビューサイズ取得部４１の取得したビューサイズは、１００８０ドット×１４２５６ドットとなり、Ａ４用紙が１枚の場合に比べて、ビューサイズが４倍になった。
【００７５】
図８は、本実施例における表示可能なメッセージ数を算出する計算処理を説明するための議論ツリー表示例である。
【００７６】
ビューサイズ取得部４１は、表示可能なメッセージ数を算出するためのビューサイズとして、表示部の画素数もしくは物理サイズ、または、印刷用紙サイズのような仮想表示部の論理サイズの何れかを取得することができる。
【００７７】
まず、図８のビュー８０１および８０２を参照して、表示部の画素数を取得し表示可能なメッセージ数を算出する処理を説明する。
【００７８】
表示部の画素数の取得方法として、ＶＧＡ表示では、４８０ドット×６４０ドットなどの値を通信により取得する場合、ユーザが入力することによって取得する、または事前設定ファイルから取得する方法が考えらえる。
【００７９】
図８のビュー８０１に示す、表示部を縦表示にした場合、画素数が２４０ドット×６００ドットとなる。それに対して、図８のビュー８０２に示す、表示部を横表示にした場合、画素数が６００ドット×２４０ドットとなる。各ノードの縦方向が４０ドットと仮定すれば、ビュー８０１に示す縦方向表示の場合は、表示可能なメッセージ数として縦１０ノードなのに対して、ビュー８０２に示す横方向表示の場合は表示可能なメッセージ数として縦４ノードと算出される。このため、横方向表示（８０２）の場合に、縦方向表示（８０１）の場合の議論ツリーに対して、表示ノードの削減処理が行われ縦方向４ノードの議論ツリー表示となる。
【００８０】
次に、図８のビュー８０３および８０４を参照して、仮想表示部の論理サイズを取得し表示可能なメッセージ数を算出する処理を説明する。
【００８１】
ビューサイズ取得部４１は、ビュー８０３に示す用紙サイズに応じた画素数を算出する。たとえば、Ａ４用紙の場合は、６００ｄｐｉの解像度で印刷する場合に、５０４０ドット×７１２８ドットの論理サイズをビューサイズとして取得し、この論理サイズに対して、表示可能なメッセージ数を算出する。
【００８２】
また、ポスター印刷（拡大連写印刷）により複数ページ（複数枚の印刷用紙）に分けて印刷したドキュメントを貼り合わせて、１枚のポスターにする場合は、複数ページのサイズの合計を仮想表示部の論理サイズとすることで表示可能なメッセージ数を算出する。
【００８３】
図８のビュー８０４に示す、用紙を縦表示にした場合に１枚の用紙画素数が５００ドット×１０００ドットと仮定すれば、４枚の用紙に印刷する場合の仮想表示部の論理サイズは、１０００ドット×２０００ドットとなる。このため、（エッジ部を含めて）縦方向に１ノードあたり２００ドットと仮定すれば、縦方向に１０ノードの発言ノードを表示できる。
【００８４】
なお、これらの論理サイズ算出方法は、印刷による紙への出力の場合に限定しない。他にモニタやタブレット端末、プロジェクタなどを複数使うことで、仮想表示部に表示を行う場合も本実施例を適用できる。
【００８５】
なお、ビューサイズ取得部４１は表示部の物理サイズを取得し、表示可能なメッセージ数を算出することもできる。物理サイズの例として７．１インチディスプレイや、６ｃｍ×１０ｃｍなどの物理サイズを取得する。または、印刷の場合は、Ａ４用紙サイズである２１０ｍｍ×２９７ｍｍ×などを取得する。これらは、通信により取得する場合、ユーザが入力することによって取得する、または事前設定ファイルから取得する方法が考えられる。物理サイズを取得した場合も、画素数と同様に各ノードの物理サイズから、表示可能なメッセージ数を算出する。
【００８６】
図９は、本実施例におけるビューサイズ取得部４１がビューサイズを取得して表示可能なメッセージ数を算出する処理フローを示す図である。
【００８７】
ステップＳ９０１において、ビューサイズ取得部４１は、制御部４０で取得されたユーザ入力の設定値から、表示可能なメッセージ数を表示部の物理サイズで算出するか判定を行う。
【００８８】
ステップＳ９０１で表示部の物理サイズで算出すると判定された場合は、ステップＳ９０２において、ビューサイズ取得部４１は、表示部の物理サイズの取得を行う。
【００８９】
ステップＳ９０１で表示部の物理サイズ以外で算出すると判定された場合は、処理はステップＳ９０３へ進む。ステップＳ９０３において、ビューサイズ取得部４１は、制御部４０で取得されたユーザ入力の設定値から、表示可能なメッセージ数を仮想表示部の論理サイズで取得するか判定を行う。
【００９０】
ステップＳ９０３で仮想表示部の論理サイズで算出すると判定された場合は、ステップＳ９０４へ進む。ステップＳ９０４において、ビューサイズ取得部４１は仮想表示部の論理サイズを取得する。
【００９１】
また、ステップＳ９０３で仮想表示部の論理サイズで算出しないと判定された場合は、ステップＳ９０５へ進む。ステップＳ９０５において、ビューサイズ取得部４１は、デフォルト設定として表示部の画素数の取得を行う。
【００９２】
ステップＳ９０６において、ビューサイズ取得部４１は、表示部４１の表示方向の検出を行う。
【００９３】
ステップＳ９０７において、ビューサイズ取得部４１は、ステップＳ９０６で検出した表示方向の検出結果と、ステップＳ９０１からステップＳ９０５の処理で取得したビューサイズから、縦方向と横方向の表示可能なメッセージ数を決定する。
【００９４】
以上説明した本実施例によれば、仮想表示部で発言数が多い議論グラフにおいても、ユーザが所望の発言を確認する作業を容易に行えるようになる。また、仮想表示部で議論一覧から目的の項目を探しやすくする表示することが可能となる。
【００９５】
［実施例３］
本実施例では、利用者側に複数の表示部または仮想表示部を有する場合に対処する仕組みを提供する。
【００９６】
図１０を参照して、本実施例における利用者側に複数の表示部または仮想表示部を有する場合の表示可能なメッセージ数の算出処理フローについて詳細に説明する。
【００９７】
本実施例においては、クライアント側に第１の表示部と第２の表示部を有する電子掲示板システム１０では、複数の表示部のうち優先表示部を決定して、優先表示部に応じて表示可能なメッセージ数の算出処理を行うことができる。例えば、クライアント２はパーソナルコンピュータのモニタを第１の表示部５１（第１の出力装置）とし、プレゼンテーション画面を第２の表示部５２（第２の出力装置）とする。この場合、プレゼンテーション画面においての表示を優先して、表示可能なメッセージ数を算出することができる。また、例えば、クライアント２はパーソナルコンピュータのモニタを第１の表示部（第１の出力装置）とし、印刷装置で紙へ印刷を行うための仮想表示部を第２の表示部（第２の出力装置）とする。この場合、紙へ印刷においての表示を優先して、表示可能なメッセージ数を算出することができる。ここで説明した利用者側に表示部を複数有する電子掲示板システム１０は一例であり、本実施例において描画部を複数有する電子掲示板システムを限定するわけではない。
【００９８】
ステップＳ１００１において、ビューサイズ取得部４１は、利用者側に表示部（または仮想表示部）が複数存在するか判定を行う。ステップＳ１００１で表示部（または仮想表示部）が複数存在すると判定された場合に、処理は優先出力装置決定のためのステップＳ１００２に進む。
【００９９】
ステップＳ１００２において、ビューサイズ取得部４１は、制御部４０で取得されたユーザ入力の設定値から、複数の表示部（または仮想表示部）のうちどの表示部に応じて表示可能なメッセージ数を算出するためのビューサイズを決定するか取得する。
ステップＳ１００３において、ビューサイズ取得部４１は、ステップＳ１００２で決定した表示部のビューサイズの取得を行う。
【０１００】
ステップＳ１００４において、ビューサイズ取得部４１は、ステップＳ１００２で決定した表示部の表示方向の検出を行う。
【０１０１】
ステップＳ１００５において、ビューサイズ取得部４１は、ステップＳ１００４で検出した表示部の表示方向の検出結果と、ステップＳ１００３の処理で取得した表示部の表示サイズとから、縦方向と横方向の表示可能なメッセージ数を決定する。
【０１０２】
以上説明した本実施例によれば、利用者側に複数の表示部を有する場合で発言数が多い議論ツリーにおいても、ユーザが所望の発言を確認する作業を容易に行えるようになる。
【０１０３】
［他の実施形態］
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良い。また、仮想化ＯＳなどで構成される場合も含めて１つの機器からなる装置に適用しても良い。さらに、情報処理装置がインターネットを経由したクラウドコンピューティングで構成されるシステムに適用しても良い。
【０１０４】
なお、本発明は、前述した実施形態の機能を実現するソフトウエアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。また、プログラムの実行環境は、パーソナルコンピュータやパーソナルコンピュータでのオペレーションシステムを仮想化した仮想ＰＣやリモートＰＣを含む。さらには、画像形成装置、プリンタやＭＦＰ（マルチファンクションペリフェラル）等の組み込みコンピュータで実行される場合も含まれる。
【図１】
2014170400.tif 000003
【図２】
2014170400.tif 000004
【図３】
2014170400.tif 000005
【図４】
2014170400.tif 000006
【図５】
2014170400.tif 000007
【図６】
2014170400.tif 000008
【図７】
2014170400.tif 000009
【図８】
2014170400.tif 000010
【図９】
2014170400.tif 000011
【図１０】
2014170400.tif 000012