JP2019159859A - 情報処理装置、プログラム、情報処理方法 - Google Patents

Abstract

【課題】チャットサービスにおいて交換される情報について、合意が形成されたか否かを管理することができる。【解決手段】情報処理装置は、複数のユーザのそれぞれを識別するユーザ識別情報と、各ユーザが投稿したポスト情報を識別するポスト識別情報と、ポスト情報に対する合意状態に関するステータス情報と、を関連付けて記憶する手段を備え、ポスト情報に対する合意を要求する第１ユーザの指示に応じて、ポスト情報に対する合意の相手方である第２ユーザに対して、合意を要求するためのリクエストを通知する手段を備え、第２ユーザがリクエストに応じて合意の承認を指示した場合、ステータス情報を、合意が形成された状態を示す情報に更新する手段を備える。【選択図】図２

Description

本発明は、情報処理装置、プログラム、及び、情報処理方法に関する。

近年、複数のユーザ間でのコミュニケーションツールとして、チャットサービスが用いられている。チャットサービスでは、特定のユーザ間でメッセージを交換することができる。メールシステムの代わりにチャットサービスを利用するユーザが増加傾向にある。

チャットサービスでは、大量のメッセージが交換されるため、メッセージの体系的な管理が求められている。例えば、特許文献１は、メッセージにカテゴリを設定する技術を開示している。

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

チャットサービスの普及に従い、チャットサービスにおいて交換される情報が多様化している。例えば、チャットサービスで交換した情報だけでビジネス上の取り決めを行うケースもある。

しかし、特許文献１では、チャットサービスにおいて交換される情報のカテゴリを管理することはできるが、ビジネス上の取り決めに対する合意が形成されたか否かを管理することはできない。

本発明の目的は、チャットサービスにおいて交換される情報について、合意が形成されたか否かを管理可能な情報処理装置及びプログラムを提供することである。

本発明の一態様は、
複数のユーザのそれぞれを識別するユーザ識別情報と、各ユーザが投稿したポスト情報を識別するポスト識別情報と、前記ポスト情報に対する合意状態に関するステータス情報と、を関連付けて記憶する手段を備え、
前記ポスト情報に対する合意を要求する第１ユーザの指示に応じて、前記ポスト情報に対する合意の相手方である第２ユーザに対して、前記合意を要求するためのリクエストを通知する手段を備え、
前記第２ユーザが前記リクエストに応じて合意の承認を指示した場合、前記ステータス情報を、前記合意が形成された状態を示す情報に更新する手段を備える、
情報処理装置である。

本発明によれば、チャットサービスにおいて交換される情報について、合意が形成されたか否かを管理することができる。

本実施形態の情報処理システムの構成を示すブロック図である。 本実施形態の概要の説明図である。 本実施形態のユーザ情報データベースのデータ構造を示す図である。 本実施形態のスレッド情報データベースのデータ構造を示す図である。 本実施形態のポスト情報データベースのデータ構造を示す図である。 本実施形態の情報処理の全体フローを示す図である。 本実施形態のスレッドの作成の処理のシーケンス図である。 図７の情報処理において表示される画面例を示す図である。 図７の情報処理において表示される画面例を示す図である。 本実施形態のチャットの処理のシーケンス図である。 図１０の情報処理において表示される画面例を示す図である。 本実施形態の合意形成の処理のシーケンス図である。 本実施形態の合意形成の処理のシーケンス図である。 図１２の情報処理において表示される画面例を示す図である。 図１２の情報処理において表示される画面例を示す図である。 本実施形態の合意の表示の処理のシーケンス図である。 図１６の情報処理において表示される画面例を示す図である。

以下、本発明の一実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。

本実施形態において、「合意」とは、複数のユーザの双方が、チャットサービスにおいて交換されるポスト情報に対して、同意することを意味する。
「合意の承認」とは、あるユーザが別のユーザに対して合意の要求を行った場合において、当該別のユーザが合意を受け入れる意思を示すことを意味する。

（１）情報処理システムの構成
情報処理システムの構成について説明する。図１は、本実施形態の情報処理システムの構成を示すブロック図である。

図１に示すように、情報処理システム１は、クライアント装置１０と、サーバ３０とを備える。
クライアント装置１０及びサーバ３０は、ネットワーク（例えば、インターネット又はイントラネット）ＮＷを介して接続される。

クライアント装置１０は、サーバ３０にリクエストを送信する情報処理装置の一例である。クライアント装置１０は、例えば、スマートフォン、タブレット端末、又は、パーソナルコンピュータである。

サーバ３０は、クライアント装置１０から送信されたリクエストに応じたレスポンスをクライアント装置１０に提供する情報処理装置の一例である。サーバ３０は、例えば、ウェブサーバである。

（１−１）クライアント装置の構成
図１を参照して、クライアント装置１０の構成について説明する。

図１に示すように、クライアント装置１０は、記憶装置１１と、プロセッサ１２と、入出力インタフェース１３と、通信インタフェース１４とを備える。

記憶装置１１は、プログラム及びデータを記憶するように構成される。記憶装置１１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、及び、ストレージ（例えば、フラッシュメモリ又はハードディスク）の組合せである。

プログラムは、例えば、以下のプログラムを含む。
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、チャットアプリケーション）のプログラム

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）

プロセッサ１２は、記憶装置１１に記憶されたプログラムを起動することによって、クライアント装置１０の機能を実現するように構成される。プロセッサ１２は、コンピュータの一例である。

入出力インタフェース１３は、クライアント装置１０に接続される入力デバイスからユーザの指示を受け付け、かつ、クライアント装置１０に接続される出力デバイスに情報を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイである。

通信インタフェース１４は、クライアント装置１０とサーバ３０との間の通信を制御するように構成される。

（１−２）サーバの構成
図１を参照して、サーバ３０の構成について説明する。

図１に示すように、サーバ３０は、記憶装置３１と、プロセッサ３２と、通信インタフェース３４とを備える。

記憶装置３１は、プログラム及びデータを記憶するように構成される。記憶装置３１は、例えば、ＲＯＭ、ＲＡＭ、及び、ストレージ（例えば、フラッシュメモリ又はハードディスク）の組合せである。

プログラムは、例えば、以下のプログラムを含む。
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理の実行結果

プロセッサ３２は、記憶装置３１に記憶されたプログラムを起動することによって、サーバ３０の機能を実現するように構成される。プロセッサ３２は、コンピュータの一例である。

入出力インタフェース３３は、サーバ３０に接続される入力デバイスからユーザの指示を受け付け、かつ、サーバ３０に接続される出力デバイスに情報を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイである。

通信インタフェース３４は、サーバ３０とクライアント装置１０との間の通信を制御するように構成される。

（２）本実施形態の概要
本実施形態の概要について説明する。図２は、本実施形態の概要の説明図である。

図２に示すように、ユーザＵ１及びＵ２は、それぞれ、各クライアント装置１０−１及び１０−２を使用して、チャットサービスを提供するサーバ３０を介して、チャットサービスに投稿された情報（以下「ポスト情報」という）を交換する。

クライアント装置１０−１が、ユーザＵ１の指示に従って、ユーザＵ１がユーザＵ２に対して投稿したポスト情報に対する合意を要求するための合意リクエストをサーバ３０に送信すると、サーバ３０は、クライアント装置１０−２に合意リクエストを送信する。

ユーザＵ２が合意リクエストに応じて合意の承認の指示をクライアント装置１０−２に与えると、クライアント装置１０−２は、ユーザＵ２の指示に従って、承認を示す合意レスポンスをサーバ３０に送信する。

サーバ３０は、クライアント装置１０−２から合意レスポンスを受信すると、ポスト情報に関する合意が形成されたものとして取り扱う。

これにより、サーバ３０には、ユーザＵ１とユーザＵ２との間で、当該ポスト情報に対する合意が形成されたことが記録される。

（３）データベース
本実施形態のデータベースについて説明する。以下のデータベースは、記憶装置３１に記憶される。

（３−１）ユーザ情報データベース
本実施形態のユーザ情報データベースについて説明する。図３は、本実施形態のユーザ情報データベースのデータ構造を示す図である。

図３のユーザ情報データベースには、ユーザに関するユーザ情報が格納される。
ユーザ情報データベースは、「ユーザＩＤ」フィールドと、「ユーザ名」フィールドと、「連絡先」フィールドと、を含む。各フィールドは、互いに関連付けられている。

「ユーザＩＤ」フィールドには、ユーザを識別するユーザＩＤ（「ユーザ識別情報」の一例）が格納される。「ユーザＩＤ」フィールドの情報は、サーバ３０にユーザ情報を登録する時にサーバ３０によって決定される。

「ユーザ名」フィールドには、ユーザの名前に関する情報（例えば、テキスト）が格納される。「ユーザ名」フィールドの情報は、ユーザによって任意に決定される。

「連絡先」フィールドには、ユーザの連絡先に関する連絡先情報（例えば、メールアドレス、ウェブサービスのアカウント、ソーシャルネットワーキングサービスのアカウント、及び、サーバ３０が提供するサービスのアカウントの少なくとも１つ）が格納される。「連絡先」フィールドの情報は、ユーザによって任意に決定される。

（３−２）スレッド情報データベース
本実施形態のスレッド情報データベースについて説明する。図４は、本実施形態のスレッド情報データベースのデータ構造を示す図である。

図４のスレッド情報データベースには、スレッドに関するスレッド情報が格納される。スレッドとは、複数のユーザの間で交換されるメッセージの集合を意味する。
スレッド情報データベースは、「スレッドＩＤ」フィールドと、「スレッド名」フィールドと、「メンバ」フィールドと、「スレッドアドレス」フィールドと、を含む。各フィールドは、互いに関連付けられている。
スレッド情報データベースは、ユーザＩＤに関連付けられている。

「スレッドＩＤ」フィールドには、スレッドを識別するスレッドＩＤ（「スレッド識別情報」の一例）が格納される。「スレッドＩＤ」フィールドの情報は、サーバ３０によって決定される。

「スレッド名」フィールドには、スレッドの名称を示す情報（例えば、テキスト）が格納される。「スレッド名」フィールドの情報は、スレッドのメンバによって任意に決定される。

「メンバ」フィールドには、スレッドのメンバのユーザＩＤが格納される。スレッドのメンバは、スレッドに含まれるメッセージ（つまり、自分、又は、自分以外のメンバが投稿したメッセージ）を受信可能であり、且つ、スレッドにメッセージを投稿可能なユーザである。

「スレッドアドレス」フィールドには、サーバ３０上におけるスレッドのアドレスに関するスレッドアドレス情報（例えば、ＵＲＬ（Uniform Resource Locator））が格納される。

（３−３）ポスト情報データベース
本実施形態のポスト情報データベースについて説明する。図５は、本実施形態のポスト情報データベースのデータ構造を示す図である。

図５のポスト情報データベースには、スレッドに含まれるポスト情報が格納される。
ポスト情報データベースは、「ポストＩＤ」フィールドと、「日時」フィールドと、「ポストユーザ」フィールドと、「コンテンツ」フィールドと、「コンテンツタイプ」フィールドと、「要求者」フィールドと、「応答者」フィールドと、「ステータス」フィールドと、を含む。各フィールドは、互いに関連付けられている。
ポスト情報データベースは、スレッドＩＤに関連付けられている。

「ポストＩＤ」フィールドには、ポスト情報を識別するポストＩＤ（「ポスト識別情報」の一例）が格納される。「ポストＩＤ」フィールドの情報は、サーバ３０によって決定される。

「日時」フィールドには、ポスト情報が投稿された日時に関する情報が格納される。「日時」フィールドの情報は、サーバ３０によって決定される。

「ポストユーザ」フィールドには、ポスト情報を投稿したユーザのユーザＩＤが格納される。

「コンテンツ」フィールドには、ポスト情報の内容に関するコンテンツ情報が格納される。「コンテンツ」フィールドの情報は、ユーザによって任意に決定される。
コンテンツ情報は、以下の少なくとも１つの種類の情報を含む。
・テキストデータ
・画像データ（静止画データ、動画データ、又は、それらの組合せ）
・音声データ
・スタンプイメージデータ
・電子ファイル

「コンテンツタイプ」フィールドには、コンテンツ情報の種類に関するコンテンツタイプ情報が格納される。
・「ＴＸＴ」は、テキストデータを意味する。
・「ＩＭＧ」は、画像データを意味する。
・「ＳＯＵＮＤ」は、音声データを意味する。
・「ＳＴＡＭＰ」は、スタンプイメージデータを意味する。
・「ＦＩＬＥ」は、電子ファイルを意味する。

「要求者」フィールドには、ポスト情報に対する合意を要求するユーザのユーザＩＤが格納される。

「応答者」フィールドには、ポスト情報に対する合意の要求に対して応答したユーザのユーザＩＤが格納される。

「ステータス」フィールドには、ポスト情報に対する合意に関するステータス情報が格納される。「ステータス」フィールドの情報は、サーバ３０によって決定される。
ステータス情報は、例えば、以下の情報を含む。
・「ＳＴＡ０」…合意が要求されておらず、且つ、合意が形成されていない状態を示す。
・「ＳＴＡ１」…合意が要求されたが、合意が形成されていない状態を示す。
・「ＳＴＡ２」…合意が形成された状態を示す。
・「ＳＴＡ３」…合意が拒否された状態を示す。

（４）情報処理
本実施形態の情報処理について説明する。図６は、本実施形態の情報処理の全体フローを示す図である。

本実施形態の情報処理は、スレッドの作成（ＯＰ１）と、チャット（ＯＰ２）と、合意形成（ＯＰ３）と、合意の表示（ＯＰ４）と、を含む。
スレッドの作成（ＯＰ１）は、スレッドを作成するための処理である。スレッドとは、チャット（ＯＰ２）において複数のユーザの間で交換されるポスト情報の集合である。スレッドには、複数のユーザがメンバとして参加する。
チャット（ＯＰ２）は、スレッドに参加している複数のユーザの間でポスト情報を交換するための処理である。
合意形成（ＯＰ３）は、チャット（ＯＰ２）において交換されたポスト情報に対する合意を形成するための処理である。
合意の表示（ＯＰ４）は、合意形成（ＯＰ３）において合意が形成されたポスト情報を表示させるための処理である。

以下の説明では、次の事項を前提とする。
・クライアント装置１０−１は、サーバ３０に対して、ユーザＵ１のユーザＩＤでログインしている。
・クライアント装置１０−２は、サーバ３０に対して、ユーザＵ２のユーザＩＤでログインしている。

（４−１）スレッドの作成の処理
本実施形態のスレッドの作成の処理について説明する。図７は、本実施形態のスレッドの作成の処理のシーケンス図である。図８は、図７の情報処理において表示される画面例を示す図である。図９は、図７の情報処理において表示される画面例を示す図である。

図７に示すように、クライアント装置１０−１は、スレッド作成の指示の受付（Ｓ１００−１）を実行する。なお、ステップＳ１００−１は、クライアント装置１０−２も実行可能である。

具体的には、プロセッサ１２は、画面Ｐ１００−１（図８）をディスプレイに表示する。
操作オブジェクトＢ１００−１ａ〜Ｂ１００−１ｂを含む。
操作オブジェクトＢ１００−１ａは、スレッドを追加するためのユーザ指示を受け付けるオブジェクトである。
操作オブジェクトＢ１００−１ｂは、スレッドを選択するためのユーザ指示を受け付けるオブジェクトである。

ユーザＵ１が操作オブジェクトＢ１００−１ａを操作すると、プロセッサ１２は、画面Ｐ１０２−１をディスプレイに表示する。

画面Ｐ１０２−１は、操作オブジェクトＢ１００−１ａ〜Ｂ１００−１ｂに加えて、操作オブジェクトＢ１０２−１と、入力フィールドオブジェクトＦ１０２−１と、を含む。
入力フィールドオブジェクトＦ１０２−１は、スレッド名を示すテキストの入力を受け付けるオブジェクトである。
操作オブジェクトＢ１０２−１は、スレッド名を確定させるためのユーザ指示を受け付けるオブジェクトである。

ユーザＵ１が入力フィールドオブジェクトＦ１０２−１に任意のスレッド名を示すテキストを入力し、且つ、操作オブジェクトＢ１０２−１を操作すると、プロセッサ１２は、画面Ｐ１０４−１をディスプレイに表示する。

画面Ｐ１０４−１は、操作オブジェクトＢ１００−１ａ〜Ｂ１００−１ｂに加えて、操作オブジェクトＢ１０４−１と、入力フィールドオブジェクトＦ１０４−１と、を含む。
入力フィールドオブジェクトＦ１０４−１は、スレッドに招待するユーザの指定を受け付けるオブジェクトである。入力フィールドオブジェクトＦ１０４−１には、ユーザ名が選択可能に表示される。各ユーザ名には、ユーザ情報データベース（図３）において各ユーザ名に関連付けられたユーザＩＤが割り当てられる。ユーザＵ１がユーザ名を選択すると、プロセッサ１２は、選択されたユーザ名に割り当てられたユーザＩＤを特定する。
操作オブジェクトＢ１０４−１は、スレッドに招待するユーザに招待リクエストを送信するためのユーザ指示を受け付けるオブジェクトである。

ステップＳ１００−１の後、クライアント装置１０−１は、スレッド作成リクエスト（Ｓ１０１−１）を実行する。
具体的には、ユーザＵ１が入力フィールドオブジェクトＦ１０４−１において任意のユーザ名を選択し、且つ、操作オブジェクトＢ１０４−１を操作すると、プロセッサ１２は、スレッド作成リクエストデータをサーバ３０に送信する。
スレッド作成リクエストデータは、以下の情報を含む。
・ユーザＵ１（つまり、スレッドを作成するユーザ）のユーザＩＤ
・入力フィールドオブジェクトＦ１０２−１に入力されたスレッド名に関する情報
・入力フィールドオブジェクトＦ１０４−１で選択されたユーザ名に割り当てられたユーザＩＤ（つまり、スレッドに招待すべきユーザのユーザＩＤ）

ステップＳ１０１−１の後、サーバ３０は、データベースの更新（Ｓ３００）を実行する。

具体的には、プロセッサ３２は、スレッド作成リクエストデータに基づいて、スレッド情報データベース（図４）に新規レコードを追加する。
新規レコードの各フィールドには、次の情報が格納される。
・「スレッドＩＤ」フィールドには、新規ＩＤが格納される。
・「スレッド名」フィールドには、スレッド名に関する情報が格納される。
・「メンバ」フィールドには、スレッド作成を要求するユーザのユーザＩＤが格納される。
・「アドレス」フィールドには、サーバ３０が任意に決定したスレッドアドレス情報が格納される。
これにより、新規スレッドが作成される。

ステップＳ３００の後、サーバ３０は、スレッド招待リクエスト（Ｓ３０１）を実行する。
具体的には、プロセッサ３２は、ユーザ情報データベース（図３）を参照して、スレッド作成リクエストデータに含まれるスレッドに招待すべきユーザのユーザＩＤに関連付けられた連絡先情報を特定する。
プロセッサ３２は、特定した連絡先情報が示す連絡先にスレッド招待リクエストデータを送信する。スレッド招待リクエストデータは、次の情報を含む。
・スレッド名に関する情報
・管理ユーザのユーザ名に関する情報
・スレッドアドレス情報

ステップＳ３０１の後、クライアント装置１０−２は、スレッド参加指示の受付（Ｓ１００−２）を実行する。

具体的には、プロセッサ１２は、画面Ｐ１００−２（図８）をディスプレイに表示する。
画面Ｐ１００−２は、表示領域Ａ１００−２と、操作オブジェクトＢ１００−２ａ〜Ｂ１００−２ｂと、を含む。
表示領域Ａ１００−２には、スレッド招待リクエストデータに含まれるスレッド名に関する情報と、管理ユーザのユーザ名に関する情報と、が表示される。

ステップＳ１００−２の後、クライアント装置１０−２は、スレッド招待レスポンス（Ｓ１０２−２）を実行する。
具体的には、ユーザＵ２が操作オブジェクトＢ１００−２ａを操作すると、プロセッサ１２は、招待レスポンスデータをサーバ３０に送信する。
招待レスポンスデータは、ユーザＵ２（つまり、スレッドへ参加するユーザ）のユーザＩＤを含む。

ステップＳ１０２−２の後、サーバ３０は、データベースの更新（Ｓ３０２）を実行する。
具体的には、プロセッサ３２は、ステップＳ３００の新規レコードの「メンバ」フィールドに、招待レスポンスデータに含まれるユーザＩＤを格納する。これにより、スレッドにユーザＵ２が追加される。

ステップＳ３０２の後、サーバ３０は、スレッド作成レスポンス（Ｓ３０３）を実行する。
具体的には、プロセッサ３２は、スレッド作成レスポンスデータをクライアント装置１０−１〜１０−２に送信する。
スレッド作成レスポンスデータには、ステップＳ３００の新規レコードの「アドレス」フィールドに格納されたスレッドアドレス情報が含まれる。

ステップＳ３０３の後、クライアント装置１０−１〜１０−２は、それぞれ、スレッド画面の表示（Ｓ１０４）を実行する。
具体的には、プロセッサ１２は、スレッド作成レスポンスデータに含まれるスレッドアドレス情報にアクセスすることにより、画面Ｐ１０６（図９）をディスプレイに表示する。

画面Ｐ１０６は、操作オブジェクトＢ１００−１ａ〜Ｂ１００−１ｂに加えて、表示オブジェクトＡ１０６ａ〜Ａ１０６ｃと、操作オブジェクトＢ１０６ａ〜Ｂ１０６ｂと、入力フィールドオブジェクトＦ１０６と、編集オブジェクトＢｅと、を含む。
表示オブジェクトＡ１０６ａには、スレッド名に関する情報が表示される。
表示オブジェクトＡ１０６ｂには、スレッドに参加しているユーザのユーザ名に関する情報が表示される。
表示オブジェクトＡ１０６ｃには、スレッドに投稿されたポスト情報が時系列に沿って表示される。つまり、表示オブジェクトＡ１０６ｃは、スレッドに投稿されたポスト情報のタイムラインである。
入力フィールドオブジェクトＦ１０６は、スレッドに投稿するポスト情報の入力を受け付けるためのオブジェクトである。
操作オブジェクトＢ１０６ａは、スレッドを選択するためのユーザ指示を受け付けるオブジェクトである。
操作オブジェクトＢ１０６ｂは、入力フィールドオブジェクトＦ１０６に入力したポスト情報をスレッドに投稿するためのユーザ指示を受け付けるオブジェクトである。
編集オブジェクトＢｅは、投稿されたポスト情報を編集するためのユーザ指示を受け付けるオブジェクトである。編集オブジェクトＢｅには、ポストＩＤが割り当てられている。編集オブジェクトＢｅが操作されると、編集オブジェクトＢｅに割り当てられたポストＩＤに関連付けられているコンテンツが編集可能になる。「編集」とは、コンテンツの変更又は削除を意味する。

（４−２）チャットの処理
本実施形態のチャットの作成の処理について説明する。図１０は、本実施形態のチャットの処理のシーケンス図である。図１１は、図１０の情報処理において表示される画面例を示す図である。

図１０に示すように、クライアント装置１０−１及び１０−２は、対象ポストの受付（Ｓ１１０−１）を実行する。
具体的には、プロセッサ１２は、画面Ｐ１０６（図１１）をディスプレイに表示する。
ユーザが、入力フィールドオブジェクトＦ１０６にポスト情報（例えば、「明日までにやります」というテキスト）を入力し、且つ、操作オブジェクトＢ１０６ｂを操作すると、プロセッサ１２は、入力フィールドオブジェクトＦ１０６に入力されたポスト情報を、投稿すべきポスト情報（以下「対象ポスト」という）として受け付ける。

ステップＳ１１０−１の後、クライアント装置１０−１は、ポストリクエスト（Ｓ１１１−１）を実行する。
具体的には、プロセッサ１２は、ポストリクエストデータをサーバ３０に送信する。
ポストリクエストデータは、以下の情報を含む。
・ステップＳ１１０−１において、ポスト情報を投稿するユーザのユーザＩＤ
・ステップＳ１１０−１において入力フィールドオブジェクトＦ１０６に入力されたポスト情報
・ステップＳ１１１−１の実行日時に関する情報

ステップＳ１１１−１の後、サーバ３０は、データベースの更新（Ｓ３１０）を実行する。
具体的には、プロセッサ３２は、ポスト情報データベース（図５）に新規レコードを追加する。新規レコードの各フィールドには、以下の情報が格納される。
・「ポストＩＤ」フィールドには、サーバ３０が任意に決定したポストＩＤが格納される。
・「日時」フィールドには、ポストリクエストデータに含まれる、ステップＳ１１１−１の実行日時に関する情報が格納される。
・「ポストユーザ」フィールドには、ポストリクエストデータに含まれるユーザＩＤが格納される。
・「コンテンツ」フィールドには、ポストリクエストデータに含まれるポスト情報が格納される。
・「ステータス」フィールドには、合意が形成されていない状態を示すステータス情報「ＳＴＡ０」が格納される。
これにより、新規ポスト情報が投稿される。

ステップＳ３１０の後、サーバ３０は、ポストレスポンス（Ｓ３１１）を実行する。
具体的には、プロセッサ３２は、スレッド情報データベース（図４）の「メンバ」フィールドを参照して、スレッドに参加するユーザのユーザＩＤを特定する。
プロセッサ３２は、ユーザ情報データベース（図３）を参照して、特定したユーザＩＤに関連付けられた「連絡先」フィールドの情報（つまり、スレッドに参加するユーザの連絡先情報）を特定する。
プロセッサ３２は、特定した「連絡先」フィールドの情報（例えば、クライアント装置１０−１〜１０−２）に対して、ポストレスポンスデータを送信する。
ポストレスポンスデータは、以下の情報を含む。
・ステップＳ３１０の新規レコードの「ポストユーザ」フィールドの情報
・ステップＳ３１０の新規レコードの「コンテンツ」フィールドの情報

ステップＳ３１１の後、クライアント装置１０−１〜１０−２は、タイムラインの更新（Ｓ１１３）を実行する。
具体的には、プロセッサ１２は、画面Ｐ１１０（図１１）をディスプレイに表示する。

画面Ｐ１１０は、表示オブジェクトＡ１０６ｃが画面Ｐ１０６と異なる。
表示オブジェクトＡ１０６ｃには、ポストレスポンスデータに含まれる情報（つまり、新規ポスト情報を投稿したユーザのユーザ名に関する情報、及び、ポスト情報）が表示される。

（４−３）合意形成の処理
本実施形態の合意形成の処理について説明する。図１２は、本実施形態の合意形成の処理のシーケンス図である。図１３〜図１５は、図１２の情報処理において表示される画面例を示す図である。

図１２に示すように、クライアント装置１０−１は、合意対象の受付（Ｓ１２０−１）を実行する。なお、ステップＳ１２０−１は、クライアント装置１０−２（つまり、ユーザＵ２）も実行可能である。
具体的には、プロセッサ１２は、画面Ｐ１２０−１（図１３）をディスプレイに表示する。

画面Ｐ１２０−１は、表示オブジェクトＡ１２０−１、及び、操作オブジェクトＢ１２０−１が画面Ｐ１１０と異なる。
表示オブジェクトＡ１２０−１には、タイムラインの各ポスト情報が選択可能に表示される。
操作オブジェクトＢ１２０−１は、表示オブジェクトＡ１２０−１において選択されたポスト情報を合意対象として確定させるためのユーザ指示を受け付けるオブジェクトである。

ステップＳ１２０−１の後、クライアント装置１０−１は、合意リクエスト（Ｓ１２１−１）を実行する。
具体的には、ユーザＵ１が表示オブジェクトＡ１２０−１においてポスト情報を選択し、且つ、操作オブジェクトＢ１２０−１を操作すると、プロセッサ１２は、合意リクエストデータをサーバ３０に送信する。
合意リクエストデータは、以下の情報を含む。
・ユーザＵ１（つまり、ポスト情報に対する合意を要求するユーザ（以下「合意要求ユーザ」という）のユーザＩＤ）
・表示オブジェクトＡ１２０−１において選択されたポスト情報（つまり、合意対象）に割り当てられたポストＩＤ

ステップＳ１２０１−１の後、サーバ３０は、データベースの更新（Ｓ３２０）を実行する。

具体的には、プロセッサ３２は、ポスト情報データベース（図５）を参照して、合意リクエストデータに含まれるポストＩＤを含む合意対象レコードを特定する。
プロセッサ３２は、合意対象レコードの各フィールドを以下のとおり更新する。
・「要求者」フィールドに、合意リクエストデータに含まれるユーザＩＤ（つまり、合意要求ユーザのユーザＩＤ）を格納する。
・「ステータス」フィールドに、合意が要求された状態を示すステータス情報「ＳＴＡ１」が格納される。

ステップＳ３２０の後、サーバ３０は、合意リクエスト（Ｓ３２１）を実行する。
具体的には、プロセッサ３２は、スレッド情報データベース（図４）を参照して、合意対象のポスト情報を含むスレッドの「メンバ」フィールドの情報（つまり、合意対象のポスト情報を含むスレッドのメンバのユーザＩＤ）を特定する。
プロセッサ３２は、ユーザ情報データベース（図３）を参照して、特定したユーザＩＤに関連付けられた「連絡先」フィールドの情報を特定する。
プロセッサ３２は、特定した「連絡先」フィールドの情報（例えば、クライアント装置１０−２）に対して、合意リクエストデータを送信する。
合意リクエストデータは、以下の情報を含む。
・合意対象レコードの「ポストＩＤ」フィールドの情報
・合意対象レコードの「コンテンツ」フィールドの情報
・合意対象レコードの「コンテンツタイプ」フィールドの情報
・合意対象レコードの「要求者」フィールドの情報

ステップＳ３２１の後、クライアント装置１０−２は、応答の受付（Ｓ１２０−２）を実行する。
具体的には、プロセッサ１２は、画面Ｐ１２０−２（図１３）をディスプレイに表示する。

画面Ｐ１２０−２は、表示オブジェクトＡ１２０−２、及び、操作オブジェクトＢ１２０−２ａ〜Ｂ１２０−２ｂが画面Ｐ１１０と異なる。
表示オブジェクトＡ１２０−２には、タイムラインの各ポスト情報が表示される。合意対象のポスト情報には、合意対象であることが示される。
操作オブジェクトＢ１２０−２ａは、合意対象のポスト情報に対する合意を承認するためのユーザ指示を受け付けるオブジェクトである。
操作オブジェクトＢ１２０−２ｂは、合意対象のポスト情報に対する合意を拒否するためのユーザ指示を受け付けるオブジェクトである。

ステップＳ１２０−２の後、クライアント装置１０−２は、合意レスポンス（Ｓ１２１−２）を実行する。
具体的には、ユーザＵ２が操作オブジェクトＢ１２０−２ａを操作すると、プロセッサ１２は、サーバ３０に合意レスポンスデータを送信する。
合意レスポンスデータは、以下の情報を含む。
・ユーザＵ２（つまり、ポスト情報に対する合意の承認を指示するユーザ（以下「承認ユーザ」という））のユーザＩＤ
・合意対象レコードの「ポストＩＤ」フィールドの情報（つまり、合意対象のポスト情報のポストＩＤ）を含む。

ステップＳ１２１−２の後、サーバ３０は、データベースの更新（Ｓ３２２）を実行する。
具体的には、プロセッサ３２は、合意レスポンスデータに含まれるポストＩＤに関連付けられた合意対象レコードを特定する。
プロセッサ３２は、合意対象レコードの各フィールドを以下のとおり更新する。
・「応答者」フィールドに、合意レスポンスデータに含まれるユーザＩＤ（つまり、承認ユーザのユーザＩＤ）を格納する。
・「ステータス」フィールドに、合意が形成された状態を示すステータス情報「ＳＴＡ２」を格納する。

ステップＳ３２２の後、サーバ３０は、合意レスポンス（Ｓ３２３）を実行する。
具体的には、プロセッサ３２は、ユーザ情報データベース（図３）を参照して、合意要求ユーザのユーザＩＤに関連付けられた「連絡先」フィールドの情報（つまり、合意要求ユーザの連絡先情報）と、承認ユーザのユーザＩＤに関連付けられた「連絡先」フィールドの情報（つまり、承認ユーザの連絡先情報）と、を特定する。
プロセッサ３２は、特定した連絡先情報（例えば、クライアント装置１０−１〜１０−２）に対して、合意レスポンスデータを送信する。
合意レスポンスデータは、ステップＳ３２２で更新された合意対象レコードの「コンテンツ」フィールドの情報を含む。

ステップＳ３２３の後、クライアント装置１０−１〜１０−２は、タイムラインの更新（Ｓ１２２）を実行する。
具体的には、プロセッサ１２は、画面Ｐ１２２（図１４）をディスプレイに表示する。

画面Ｐ１２２は、表示オブジェクトＡ１２２が画面Ｐ１２０−１〜Ｐ１２０−２（図１３）と異なる。
表示オブジェクトＡ１２２には、合意対象のポスト情報のステータスが「合意形成」であることが示される。また、合意対象のポスト情報のポストＩＤが割り当てられた編集オブジェクトＢｅは表示されない。つまり、「ステータス」フィールドにステータス情報「ＳＴＡ２」が格納されたレコードのポスト情報については、編集が禁止される。

ステップＳ１２１−２において、ユーザＵ２が操作オブジェクトＢ１２０−２ｂを操作すると、クライアント装置１０−２のプロセッサ１２は、サーバ３０に合意レスポンスデータを送信する。
合意レスポンスデータは、以下の情報を含む。
・ユーザＵ２（つまり、ポスト情報に対する合意の拒否を指示するユーザ（以下「拒否ユーザ」という））のユーザＩＤ
・合意対象レコードの「ポストＩＤ」フィールドの情報（つまり、合意対象のポスト情報のポストＩＤ）を含む。

ステップＳ３２２において、プロセッサ３２は、合意レスポンスデータに含まれるポストＩＤに関連付けられた合意対象レコードを特定する。
プロセッサ３２は、合意対象レコードの各フィールドを以下のとおり更新する。
・「応答者」フィールドに、合意レスポンスデータに含まれるユーザＩＤ（つまり、拒否ユーザのユーザＩＤ）を格納する。
・「ステータス」フィールドに、合意が拒否された状態を示すステータス情報「ＳＴＡ３」を格納する。
プロセッサ３２は、データベースを更新した後、クライアント装置１０−１に、合意が拒否されたことを示す通知を送信する。

ステップＳ１２２において、クライアント装置１０−１のプロセッサ１２は、画面Ｐ１２３をディスプレイ（図１５）に表示する。

画面Ｐ１２３は、表示オブジェクトＡ１２２が画面Ｐ１２１（図１４）と異なる。
表示オブジェクトＡ１２２には、合意対象のポスト情報のステータスが「拒否」であることが示される。また、合意が拒否されたポスト情報のポストＩＤが割り当てられた編集オブジェクトＢｅが再び表示される。つまり、「ステータス」フィールドにステータス情報「ＳＴＡ３」が格納されたレコードのポスト情報については、編集が許可される。

（４−４）合意の表示の処理
本実施形態の合意の表示の処理について説明する。図１６は、本実施形態の合意の表示の処理のシーケンス図である。図１７は、図１６の情報処理において表示される画面例を示す図である。

図１６に示すように、クライアント装置１０−１は、ユーザ指示の受付（Ｓ１３０）を実行する。
具体的には、プロセッサ１２は、画面Ｐ１３０（図１７）をディスプレイに表示する。

画面Ｐ１３０は、操作オブジェクトＢ１３０を含む。
操作オブジェクトＢ１３０は、合意が形成されたポスト情報を表示させるためのユーザ指示を受け付けるオブジェクトである。

ステップＳ１３０の後、クライアント装置１０−１は、表示リクエスト（Ｓ１３１）を実行する。
具体的には、ユーザが操作オブジェクトＢ１３０を操作すると、プロセッサ１２は、表示リクエストデータをサーバ３０に送信する。
表示リクエストデータは、ユーザＵ１（つまり、合意が形成されたポスト情報を表示させるためのユーザ指示を行ったユーザ（以下「表示要求ユーザ」という））のユーザＩＤを含む。

ステップＳ１３１の後、サーバ３０は、対象ポストの特定（Ｓ３３０）を実行する。
具体的には、プロセッサ３２は、表示リクエストデータに含まれるユーザＩＤに関連付けられたスレッド情報データベース（図４）に含まれるスレッドＩＤ（つまり、表示要求ユーザが参加しているスレッドのスレッドＩＤ）を特定する。
プロセッサ３２は、特定したスレッドＩＤに関連付けられたポスト情報データベース（図５）を参照して、「要求者」フィールドに表示要求ユーザのユーザＩＤを含み、且つ、「ステータス」フィールドにステータス情報「ＳＴＡ２」を含むレコード（以下「合意済レコード」という）を特定する。合意済レコードは、表示要求ユーザが要求したポスト情報のうち、合意が形成されたポスト情報を含む。

ステップＳ３３０の後、サーバ３０は、表示レスポンス（Ｓ３２１）を実行する。
具体的には、プロセッサ３２は、表示レスポンスデータをクライアント装置１０−１に送信する。表示レスポンスデータは、合意済レコードのポスト情報を含む。

ステップＳ３２１の後、クライアント装置１０−１は、合意表示（Ｓ１３２）を実行する。
具体的には、プロセッサ１２は、表示レスポンスデータに含まれるポスト情報に基づく画面Ｐ１３２（図１７）をディスプレイに表示する。

画面Ｐ１３２には、相手方ユーザ名（例えば、ユーザ情報データベース（図３）において、表示レスポンスデータに含まれる「応答者」フィールドのユーザＩＤに関連付けられた「ユーザ名」フィールドの情報）と、合意が形成されたポスト情報（例えば、表示レスポンスデータに含まれる「コンテンツ」フィールドの情報、及び、相手方ユーザのユーザ名）と、が表示される。

（５）変形例
本実施形態の変形例について説明する。

（５−１）変形例１
本実施形態の変形例１について説明する。変形例１は、３人以上のユーザ間で交換されたポスト情報に対する合意のステータスを管理する例である。

３人以上のユーザ間で交換されたポスト情報に本実施形態を適用する場合、サーバ３０は、ステップＳ３２２（図１２）において、全てのユーザ間でポスト情報に対する合意が承認された場合に合意が形成された状態を示すステータス情報「ＳＴＡ２」を「ステータス」フィールド（図５）に格納してもよい。

３人以上のユーザ間で交換されたポスト情報に本実施形態を適用する場合、サーバ３０は、ステップＳ３２２（図１２）において、各ユーザ間で合意が承認された場合に合意が形成された状態を示すステータス情報「ＳＴＡ２」を「ステータス」フィールドに格納してもよい。

（５−２）変形例２
本実施形態の変形例２について説明する。変形例２は、合意が要求されたポスト情報のうち、合意が形成されていないポスト情報を提示する例である。

変形例２のプロセッサ３２は、ステップＳ３３０（図１６）において、表示リクエストデータに含まれるユーザＩＤに関連付けられたスレッド情報データベース（図４）に含まれるスレッドＩＤ（つまり、表示要求ユーザが参加しているスレッドのスレッドＩＤ）を特定する。
プロセッサ３２は、特定したスレッドＩＤに関連付けられたポスト情報データベース（図５）を参照して、「要求者」フィールドに表示要求ユーザのユーザＩＤを含み、且つ、「ステータス」フィールドにステータス情報「ＳＴＡ１」を含むレコード（以下「合意要求レコード」という）を特定する。合意要求レコードは、表示要求ユーザが要求したポスト情報のうち、合意が形成されていないポスト情報を含む。

変形例２によれば、合意が要求されたポスト情報のうち合意が形成されていないポスト情報をユーザに提示することができる。

（６）本実施形態の小括
本実施形態について小括する。

本実施形態の第１態様は、
複数のユーザのそれぞれを識別するユーザ識別情報（例えば、ユーザＩＤ）と、各ユーザが投稿したポスト情報を識別するポスト識別情報（例えば、ポストＩＤ）と、ポスト情報に対する合意状態に関するステータス情報と、を関連付けて記憶する手段（例えば、記憶装置３１）を備え、
ポスト情報に対する合意を要求する第１ユーザの指示に応じて、ポスト情報に対する合意の相手方である第２ユーザに対して、合意を要求するためのリクエストを通知する手段（例えば、ステップＳ３２１を実行するプロセッサ３２）を備え、
第２ユーザがリクエストに応じて合意の承認を指示した場合、ステータス情報を、合意が形成された状態を示す情報に更新する手段（例えば、ステップＳ３２２を実行するプロセッサ３２）を備える、
情報処理装置（例えば、サーバ３０）である。

第１態様によれば、サーバ３０は、第１ユーザの指示に応じて、ポスト情報に対する合意を要求するためのリクエストが第２ユーザに通知し、且つ、第２ユーザが合意の承認を指示した場合、当該ポスト情報に対する合意が形成された状態として記録する。これにより、第１ユーザと第２ユーザとの間で交換されたポスト情報について合意が形成されたか否かを管理することができる。

本実施形態の第２態様は、
第１ユーザを識別する第１ユーザ識別情報と、第２ユーザを識別する第２ユーザ識別情報と、ポスト識別情報と、ステータス情報と、を関連付けて記憶する手段（例えば、ステップＳ３２２を実行するプロセッサ３２）を備える、情報処理装置である。

第２態様によれば、サーバ３０は、合意の対象となるポスト情報を交換した第１ユーザ及び第２ユーザと、当該ポスト情報と、を関連付けて記録する。これにより、合意の当事者を管理することができる。

本実施形態の第３態様は、
ユーザの指示に応じて、ユーザを識別するユーザ識別情報に関連付けられたポスト情報のうち、合意が形成された状態を示すステータス情報に関連付けられたポスト情報をユーザに提示する手段（例えば、ステップＳ３２１を実行するプロセッサ３２）を備える、情報処理装置である。

第３態様によれば、サーバ３０は、合意が形成されたポスト情報をユーザに提示する。これにより、ユーザは、自分と他者との間で合意が形成されたポスト情報を容易に確認することができる。

本実施形態の第４態様は、
更新する手段（例えば、ステップＳ３２０を実行するプロセッサ３２）は、リクエストが第２ユーザに通知された場合、ステータス情報を、合意が要求された状態を示す情報に更新する、情報処理装置である。

第４態様によれば、サーバ３０は、合意が要求された状態と、合意が形成された状態と、を区別して記録する。これにより、合意が要求されたものの、合意が形成されていないポスト情報を容易に特定することできる。

本実施形態の第５態様は、
ユーザの指示に応じて、ユーザを識別するユーザ識別情報に関連付けられたポスト情報のうち、合意が要求された状態を示すステータス情報に関連付けられたポスト情報をユーザに提示する手段を備える、情報処理装置である。

第５態様によれば、サーバ３０は、合意が要求されたものの、合意が形成されていないポスト情報をユーザに提示する。これにより、ユーザは、当該ポスト情報を容易に確認することができる。

本実施形態の第６態様は、
更新する手段は、第１ユーザが複数の第２ユーザに対して合意を要求した場合、全ての第２ユーザが合意の承認を指示したときに、ステータス情報を、合意が形成された状態を示す情報に更新する、情報処理装置である。

第６態様によれば、サーバ３０は、３人以上のユーザとの間で交換されたポスト情報に対する合意を要求した場合に、全てのユーザが合意を承認したポスト情報を合意が形成された状態として記録する。これにより、全てのユーザが合意を承認した場合に合意が形成される建付けに適用可能になる。

本実施形態の第７態様は、
更新する手段は、第１ユーザが複数の第２ユーザに対して合意を要求した場合、複数の第２ユーザの１人が合意の承認を指示したときに、第１ユーザと指示を行った第２ユーザとの間でのステータス情報を、合意が形成された状態を示す情報に更新する、情報処理装置である。

第７態様によれば、サーバ３０は、３人以上のユーザとの間で交換されたポスト情報に対する合意を要求する場合に、２人のユーザの組合せ毎に当該合意が形成された状態として記録する。これにより、３人以上のユーザでポスト情報を交換している場合、２人のユーザの組合せ毎にステータスを管理する建付けに適用可能になる。

本実施形態の第８態様は、
合意が形成された状態を示すステータス情報に関連付けられたポスト識別情報によって識別されるポスト情報の編集を禁止する手段を備える、
情報処理装置である。

第８態様によれば、
合意が形成された場合、合意の内容を合意が形成された後に変更されることを防ぐことができる。これにより、合意形成の信頼性を向上させることができる。

本実施形態の第９態様は、コンピュータ（例えば、プロセッサ１２又は３２）を上記各手段として機能させるためのプログラムである。

本実施形態の第１０態様は、コンピュータが、
複数のユーザのそれぞれを識別するユーザ識別情報と、各ユーザが投稿したポスト情報を識別するポスト識別情報と、ポスト情報に対する合意状態に関するステータス情報と、を関連付けて記憶し、
ポスト情報に対する合意を要求する第１ユーザの指示に応じて、ポスト情報に対する合意の相手方である第２ユーザに対して、合意を要求するためのリクエストを通知し、
第２ユーザが前記リクエストに応じて合意の承認を指示した場合、ステータス情報を、合意が形成された状態を示す情報に更新する、
情報処理方法である。

（７）その他の変形例

記憶装置１１は、ネットワークＮＷを介して、クライアント装置１０と接続されてもよい。記憶装置３１は、ネットワークＮＷを介して、サーバ３０と接続されてもよい。

上記の情報処理の各ステップは、クライアント装置１０及びサーバ３０の何れでも実行可能である。

以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態及び変形例は、組合せ可能である。

１ ：情報処理システム
１０ ：クライアント装置
１１ ：記憶装置
１２ ：プロセッサ
１３ ：入出力インタフェース
１４ ：通信インタフェース
３０ ：サーバ
３１ ：記憶装置
３２ ：プロセッサ
３３ ：入出力インタフェース
３４ ：通信インタフェース

Claims (10)

1. 複数のユーザのそれぞれを識別するユーザ識別情報と、各ユーザが投稿したポスト情報を識別するポスト識別情報と、前記ポスト情報に対する合意状態に関するステータス情報と、を関連付けて記憶する手段を備え、
   前記ポスト情報に対する合意を要求する第１ユーザの指示に応じて、前記ポスト情報に対する合意の相手方である第２ユーザに対して、前記合意を要求するためのリクエストを通知する手段を備え、
   前記第２ユーザが前記リクエストに応じて合意の承認を指示した場合、前記ステータス情報を、前記合意が形成された状態を示す情報に更新する手段を備える、
   情報処理装置。
2. 前記第１ユーザを識別する第１ユーザ識別情報と、前記第２ユーザを識別する第２ユーザ識別情報と、前記ポスト識別情報と、前記ステータス情報と、を関連付けて記憶する手段を備える、
   請求項１に記載の情報処理装置。
3. ユーザの指示に応じて、前記ユーザを識別するユーザ識別情報に関連付けられたポスト情報のうち、前記合意が形成された状態を示すステータス情報に関連付けられたポスト情報を前記ユーザに提示する手段を備える、
   請求項１又は２に記載の情報処理装置。
4. 前記更新する手段は、前記リクエストが前記第２ユーザに通知された場合、前記ステータス情報を、前記合意が要求された状態を示す情報に更新する、
   請求項１〜３の何れかに記載の情報処理装置。
5. ユーザの指示に応じて、前記ユーザを識別するユーザ識別情報に関連付けられたポスト情報のうち、前記合意が要求された状態を示すステータス情報に関連付けられたポスト情報を前記ユーザに提示する手段を備える、
   請求項４に記載の情報処理装置。
6. 前記更新する手段は、前記第１ユーザが複数の第２ユーザに対して前記合意を要求した場合、全ての第２ユーザが前記合意の承認を指示したときに、前記ステータス情報を、前記合意が形成された状態を示す情報に更新する、
   請求項１〜５の何れかに記載の情報処理装置。
7. 前記更新する手段は、前記第１ユーザが複数の第２ユーザに対して合意を要求した場合、前記複数の第２ユーザの１人が前記合意の承認を指示したときに、前記第１ユーザと前記指示を行った第２ユーザとの間でのステータス情報を、前記合意が形成された状態を示す情報に更新する、
   請求項１〜５の何れかに記載の情報処理装置。
8. 前記合意が形成された状態を示すステータス情報に関連付けられたポスト識別情報によって識別されるポスト情報の編集を禁止する手段を備える、
   請求項１〜７の何れかに記載の情報処理装置。
9. コンピュータを、請求項１〜８の何れかに記載の各手段として機能させるためのプログラム。
10. コンピュータが、
    複数のユーザのそれぞれを識別するユーザ識別情報と、各ユーザが投稿したポスト情報を識別するポスト識別情報と、前記ポスト情報に対する合意状態に関するステータス情報と、を関連付けて記憶し、
    前記ポスト情報に対する合意を要求する第１ユーザの指示に応じて、前記ポスト情報に対する合意の相手方である第２ユーザに対して、前記合意を要求するためのリクエストを通知し、
    前記第２ユーザが前記リクエストに応じて合意の承認を指示した場合、前記ステータス情報を、前記合意が形成された状態を示す情報に更新する、
    情報処理方法。

Images