(57)【要約】【課題】ＳＮＳ等から投稿された記事に対する検索の結果から注目するべき投稿記事の出典元のユーザ端末に対して担当スタッフを弾力的かつ効果的にネットワークを介して紐付ける。【解決手段】クラウドサーバ部４は、複数のモジュールを予め格納しているモジュールメモリ部４３と、モジュールをクライアント端末５１にダウンロードする通信制御４１４とを備える。モジュールメモリ部４３は、投稿記事の検索を行うモニタモジュールと、検索結果をクライアント端末５１の表示部５１２の第１の表示領域に、複数のスタッフを第２の表示領域に表示した状態で、いずれかのスタッフといずれかの記事とを関連付けるためのアサイン指示を受け付けて、記事を投稿したユーザ端末を紐付けるアサインモジュールとを格納している。【選択図】図３
2014194683.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数のソーシャルネットワークに接続されている複数のユーザ端末から投稿された記事とネットワーク上の情報処理装置との関連付けを支援するためのサービス支援サーバ装置において、
前記情報処理装置にダウンロードされて実行される複数のモジュールを予め格納しているメモリ部と、
前記情報処理装置からの要求を受け付けて前記メモリ部から前記要求に応じたモジュールを前記情報処理装置にダウンロードする通信部とを備え、
前記メモリ部は、
前記記事の検索処理を実行する検索モジュールと、
検索された記事を前記情報処理装置の表示部の第１の表示領域に表示すると共に、紐付け要員として予め登録されている複数のスタッフの各情報を前記情報処理装置の表示部の第２の表示領域に表示した状態で、前記第２の表示領域内のいずれかのスタッフの情報と前記第１の表示領域内のいずれかの記事とを関連付けるためのアサイン指示を受け付けて、前記関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を紐付けるアサインモジュールとを格納していることを特徴とするサービス支援サーバ装置。
【請求項２】
前記アサインモジュールは、前記アサイン指示を受け付けて、前記関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を投稿したユーザ端末を紐付けることを特徴とする請求項１に記載のサービス支援サーバ装置。
【請求項３】
前記検索モジュールは、検索された記事について、重要度に関連する解析を行って重要度に応じた識別マークを設定する解析モジュールを含み、
前記アサインモジュールは、前記解析によって設定された識別マークを当該記事に対応付けて表示するものであることを特徴とする請求項１又は２に記載のサービス支援サーバ装置。
【請求項４】
前記解析モジュールは、前記情報処理装置からの操作を受け付けて、前記重要度を変更する重要度変更モジュールを含むことを特徴とする請求項３に記載のサービス支援サーバ装置。
【請求項５】
前記解析モジュールは、重要度が前記重要度変更モジュールによって変更された場合、変更結果をフィードバックすることを特徴とする請求項４記載のサービス支援サーバ装置。
【請求項６】
前記解析モジュールは、ユーザ端末及び記事のいずれか一方に対する影響度を判別する影響度判別モジュールを備え、前記アサインモジュールは、影響度の高さを示すマークを当該記事に対応して表示することを特徴とする請求項１〜５のいずれかに記載のサービス支援サーバ装置。
【請求項７】
前記アサインモジュールは、前記第２の表示領域に表示されるスタッフの前記情報に当該スタッフの属性情報を含めることを特徴とする請求項１〜６のいずれかに記載のサービス支援サーバ装置。
【請求項８】
前記アサインモジュールは、検索するソーシャルネットワークのソースアイコンが選択的に指定されると、指定されたソーシャルネットワークからの投稿記事のみを表示することを特徴とする請求項１〜７のいずれかに記載のサービス支援サーバ装置。
【請求項９】
１又は複数のソーシャルネットワークに接続されている複数のユーザ端末から投稿された記事に対する検索の結果を利用する情報処理装置において、
画像を表示する表示部と、
画面上に、前記記事を検索した結果を第１の表示領域に表示すると共に、紐付け要員として予め登録されている複数のスタッフの各情報を第２の表示領域に表示した状態で、前記第２の表示領域内のいずれかのスタッフの情報と前記第１の表示領域内のいずれかの記事とを関連付けるための指示を行うアサイン指示部と、
前記指示を受け付けて、関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を紐付けるアサイン設定部とを備えたことを特徴とする情報処理装置。
【請求項１０】
前記アサイン設定部は、前記指示を受け付けて、関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を投稿したユーザ端末を紐付けることを特徴とする請求項９記載の情報処理装置。
【請求項１１】
前記１又は複数のソーシャルネットワークに接続されると共に前記アサイン指示部及び前記アサイン設定部を実行するための各モジュールを格納するメモリ部を有するサービス支援サーバ装置とネットワークを介して接続されており、アサイン指示の要求に応答して前記サービス支援サーバ装置のメモリ部から読み出される前記各モジュールをダウンロードすることを特徴とする請求項９又は１０に記載の情報処理装置。
【請求項１２】
１又は複数のソーシャルネットワークに接続されている複数のユーザ端末から投稿された記事に対する検索の結果を利用する情報処理装置による情報処理方法において、
表示部の画面上に、前記記事を検索した結果を第１の表示領域に表示すると共に、紐付け要員として予め登録されている複数のスタッフの各情報を第２の表示領域に表示した状態で、前記第２の表示領域内のいずれかのスタッフの情報と前記第１の表示領域内のいずれかの記事とを関連付けるためのアサイン指示を行うアサイン指示ステップと、
前記アサイン指示を受け付けて、前記関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を紐付けるアサイン設定ステップとを備えたことを特徴とする情報処理方法。
【請求項１３】
アサイン設定ステップは、前記アサイン指示を受け付けて、前記関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を投稿したユーザ端末を紐付けることを特徴とする請求項１２に記載の情報処理方法。
【請求項１４】
前記情報処理装置は、前記１又は複数のソーシャルネットワークに接続されると共に前記各ステップを実行するモジュールをそれぞれ格納するメモリ部を有するサービス支援サーバ装置とネットワークを介して接続されており、前記アサイン指示の要求に応答して前記サービス支援サーバ装置のメモリ部から読み出される前記各モジュールをダウンロードするステップを備えていることを特徴とする請求項１２又は１３に記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１又は複数のソーシャルネットワークに接続されている複数のユーザ端末から投稿された記事とネットワーク上の情報処理装置とを関連付ける情報処理技術に関する。
【背景技術】
【０００２】
インターネットを経由して実行されるコミュニケーションサービスとして、掲示板、チャット（ｃｈａｔ）、ブログ（ｂｌｏｇ）等、さらにこれらのサービスが組織的に可能とされたソーシャルネットワーキングサービス（SNS：SocialNetworking Service）等が知られている。例えばＳＮＳでは、ソーシャルネットワーク上には、所属する会員から種々の内容の投稿（メール）がなされており、それらの投稿記事は会員間で原則閲覧可能にされている。従って、サービスの運営上、投稿記事の内容を分析、評価することが求められる。
【０００３】
特許文献１には、インターネット上に形成されたコミュニティで取引を行う（段落００１５）利用者に対する評価を行うべくメール等を監視し、評価結果に応じて当該利用者に「警告」を発するようにした構成が記載されている。特許文献２には、会員が閲覧可能なようにＬＡＮ上に掲載された自己のホームページに対して、他の会員から誹謗中傷等の意見、感想がコメントされた場合に、情報検閲、苦情処理を行うようにすることが記載されている。
【０００４】
また、苦情対応には、上記の他、企業のコールセンタ等に苦情（ネガティブ発言含む）の連絡やメール等があると、当該ユーザにカスタマーズサービスマンを対応させるようにした現実的な苦情対応も行われている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３２３６０４号公報
【特許文献２】特開２００８−１８１４７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１では、「警告」はシステムが評価結果に基づいて行うものであり、特定の担当者に警告を紐付けて苦情対応させるというものではない。また、特許文献２には、苦情処理を行うとあるものの、具体的な方法については何等記載されていない。
【０００７】
本発明は、ＳＮＳ等から投稿された記事に対する検索の結果から注目するべき投稿記事、乃至は、その出典元（ユーザ端末）に対して担当スタッフを弾力的かつ効果的にネットワークを介して紐付けることのできるサービス支援サーバ装置、情報処理方法及びその装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明に係るサービス支援サーバ装置は、１又は複数のソーシャルネットワークに接続されている複数のユーザ端末から投稿された記事とネットワーク上の情報処理装置との関連付けを支援するためのサービス支援サーバ装置において、前記情報処理装置にダウンロードされて実行される複数のモジュールを予め格納しているメモリ部と、前記情報処理装置からの要求を受け付けて前記メモリ部から前記要求に応じたモジュールを前記情報処理装置にダウンロードする通信部とを備え、前記メモリ部は、前記記事の検索処理を実行する検索モジュールと、検索された記事を前記情報処理装置の表示部の第１の表示領域に表示すると共に、紐付け要員として予め登録されている複数のスタッフの各情報を前記情報処理装置の表示部の第２の表示領域に表示した状態で、前記第２の表示領域内のいずれかのスタッフの情報と前記第１の表示領域内のいずれかの記事とを関連付けるためのアサイン指示を受け付けて、前記関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を紐付けるアサインモジュールとを格納していることを特徴とするものである。
【０００９】
本発明によれば、関連付け予定のスタッフに割り当てられている情報処理端末に、ソーシャルネットワーク（ＳＮＳ）から投稿された記事を紐付けることで、抽出された記事が有益な記事の場合、当該記事を他のスタッフに配信して周知させる等の所望の効果的な利用に供することが可能となる。
【００１０】
また、前記アサインモジュールは、前記アサイン指示を受け付けて、前記関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を投稿したユーザ端末を紐付けることが好ましい。これによれば、ソーシャルネットワーク（ＳＮＳ）から投稿された記事に対する検索の結果から注目するべき投稿記事の出典元（ユーザ端末）に対して担当スタッフをネットワークを介して弾力的かつ効果的に紐付けることができる。
【００１１】
また、前記検索モジュールは、検索された記事について、重要度に関連する解析を行って重要度に応じた識別マークを設定する解析モジュールを含み、前記アサインモジュールは、前記解析によって設定された識別マークを当該記事に対応付けて表示するものであることが好ましい。これによれば、検索された記事に重要度を示す識別マークが付記されるので、重要度に対する視認性の向上が図れる。
【００１２】
また、前記解析モジュールは、前記情報処理装置からの操作を受け付けて、前記重要度を変更する重要度変更モジュールを含むことが好ましい。これによれば、重要度を変更指示することで、汎用性乃至は実際に、より則した解析が可能となる。
【００１３】
また、前記解析モジュールは、重要度が前記重要度変更モジュールによって変更された場合、変更結果をフィードバックすることが好ましい。これによれば、いわゆる学習機能によって重要度の解析結果の精度が向上する。
【００１４】
また、前記解析モジュールは、ユーザ端末及び記事のいずれか一方に対する影響度を判別する影響度判別モジュールを備え、前記アサインモジュールは、影響度の高さを示すマークを当該記事に対応して表示することが好ましい。これによれば、記事に対する影響度の視認性が向上する。
【００１５】
また、前記アサインモジュールは、前記第２の表示領域に表示されるスタッフの前記情報に当該スタッフの属性情報を含めることが好ましい。これによれば、紐付けのための判断材料が増え、紐付けされるスタッフの適合性も向上することでサービス支援により適するものとなる。また、自動選定に供することも可能となる。
【００１６】
また、前記アサインモジュールは、検索するソーシャルネットワークのソースアイコンが選択的に指定されると、指定されたソーシャルネットワークからの投稿記事のみを表示することが好ましい。これによれば、ソーシャルネットワーク上の所望する範囲に対して効率的に投稿記事の検索が可能となる。また、ソーシャルログインする態様とすれば、所望するＳＮＳの指定操作が容易となる。
【００１７】
また、本発明に係る情報処理装置は、１又は複数のソーシャルネットワークに接続されている複数のユーザ端末から投稿された記事に対する検索の結果を利用する情報処理装置において、画像を表示する表示部と、画面上に、前記記事を検索した結果を第１の表示領域に表示すると共に、紐付け要員として予め登録されている複数のスタッフの各情報を第２の表示領域に表示した状態で、前記第２の表示領域内のいずれかのスタッフの情報と前記第１の表示領域内のいずれかの記事とを関連付けるための指示を行うアサイン指示部と、前記指示を受け付けて、関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を紐付けるアサイン設定部とを備えたことを特徴とするものである。
【００１８】
また、本発明に係る情報処理方法は、１又は複数のソーシャルネットワークに接続されている複数のユーザ端末から投稿された記事に対する検索の結果を利用する情報処理装置による情報処理方法において、表示部の画面上に、前記記事を検索した結果を第１の表示領域に表示すると共に、紐付け要員として予め登録されている複数のスタッフの各情報を第２の表示領域に表示した状態で、前記第２の表示領域内のいずれかのスタッフの情報と前記第１の表示領域内のいずれかの記事とを関連付けるためのアサイン指示を行うアサイン指示ステップと、前記アサイン指示を受け付けて、前記関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を紐付けるアサイン設定ステップとを備えたことを特徴とするものである。
【００１９】
これらによれば、抽出された記事が有益な記事の場合、当該記事を他のスタッフに配信して周知させる等の、所望の効果的な利用に供することが可能となる。
【００２０】
また、関連付け予定のスタッフに割り当てられている通信端末に、前記関連付け予定の記事を投稿したユーザ端末を紐付けることで、注目記事の投稿者に対するフォローアップを支援することが可能となる。
【００２１】
また、情報処理装置は、サービス支援サーバ装置とネットワークを介して接続されており、処理のための各モジュールがダウンロードされることで、必要なサービスが実行される。
【発明の効果】
【００２２】
本発明は、関連付け予定のスタッフに割り当てられている通信端末に、ソーシャルネットワーク（ＳＮＳ）から投稿された記事を紐付けることで、抽出された記事が有益な記事の場合、当該記事を他のスタッフに配信して周知させる等の、所望の効果的な利用に供することを可能とする。
【００２３】
また、本発明は、ＳＮＳ等から投稿された記事に対する検索の結果から、注目するべき投稿記事の出典元（ユーザ端末）に対して担当スタッフをネットワークを介して弾力的かつ効果的に紐付けることを可能とする。
【図面の簡単な説明】
【００２４】
【図１】本発明が適用されるネットワークシステムの一実施形態を示す全体構成図である。
【図２】ＳＮＳサーバ部の一実施形態を示すブロック図である。
【図３】クラウドサーバ部の一実施形態を示すブロック図である。
【図４】クライアント部のクライアント端末の一実施形態を示すブロック図である。
【図５】クラウドサーバ部の投稿モジュールメモリに格納されている投稿モジュールをクライアント端末のモジュール実行部で実行する際の機能ブロック図である。
【図６】クラウドサーバ部のモニタモジュールメモリに格納されているモニタモジュールをクライアント端末のモジュール実行部で実行する際の機能ブロック図である。
【図７】クラウドサーバ部のアサインモジュールメモリに格納されているアサインモジュールをクライアント端末のモジュール実行部で実行する際の機能ブロック図である。
【図８】クラウドサーバ部のケースマネジメントモジュールメモリに格納されているケースマネジメントモジュールをクライアント端末のモジュール実行部で実行する際の機能ブロック図である。
【図９】クラウドサーバ部のインテリジェントメールモジュールメモリに格納されているインテリジェントメールモジュールをインテリジェントメール処理部で実行する際の機能ブロック図である。
【図１０】投稿処理の手順の一実施形態を説明するフローチャートである。
【図１１】モニタ処理の手順の一実施形態を説明するフローチャートである
【図１２】アサイン処理の手順の一例を示すフローチャートである。
【図１３】ケースマネジメント処理の手順の一実施形態を説明するフローチャートである。
【図１４】投稿処理において送信先を指定して実行される、ユーザ対応メール処理Ｉの手順の一例を示すフローチャートである。
【図１５】投稿処理で実行される、ユーザ対応メール処理IIの手順の一例を示すフローチャートである。
【図１６】インテリジェントメール処理部によって実行される、紐付けの依頼メールに対する応答メールを受信した際の処理の一例を示すフローチャートである。
【図１７】インテリジェントメール処理部によって実行される、インテリジェントメール処理の手順の一例を示すフローチャートである。
【図１８】初期画面の一例を示す図である。
【図１９】投稿モジュールのボタンが選択された場合の切替後の画面の一例を示す図である。
【図２０】ログイン後の初期画面からモニタモジュールのボタンが選択された場合の切替後の画面の一例を示す図である。
【図２１】サーチ結果の画面の一例を示す図である。
【図２２】アサインの依頼メールの作成画面の一例を示す図である。
【図２３】ケースマネジメントモード画面の一例を示す図である。
【発明を実施するための形態】
【００２５】
以下、本実施形態について説明する。なお、本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また、本実施形態で説明される構成、機能の全てが本発明に必須事項であるとは限らない。
【００２６】
図１は、本発明が適用されるネットワークシステムの一実施形態を示す全体構成図である。図１において、ネットワークシステムは、インターネット等のネットワーク１と、ネットワーク１に接続された複数のユーザ端末２，２…と、種々のＳＮＳサーバ部３，３…と、クラウドサーバ部４と、クラウドサーバ部４と連携する態様を有する１又は複数のクライアント部５，５…とを含む。
【００２７】
クラウドサーバ部４は、必ずしも１台である必要はなく、必要に応じてネットワーク上に分散配置する態様、例えばデータベース（ストーレッジ）部を分けて別の箇所に設けてもよい。クライアント部５は、一般的には、企業等の例えばＬＡＮ（Local Area Network）に接続された端末群（複数の端末）を想定しており、複数のクライアント端末５１，５１…を有する。クライアント部５内の複数のクライアント端末５１は、ルータ５０を介して通信路の制御が行われ、ネットワーク１側と、またＬＡＮ内の他のクライアント端末５１との間での通信が可能にされている。クライアント部５は、ネットワーク１を経由して、ユーザ端末２，２…と通信可能であり、また図略のウェブ（Web）サイト等とブラウザを用いてデータの検索、閲覧を可能にする。また、クライアント部５は、クラウドサーバ部４に準備されている、後述する各種の処理プログラムであるモジュールを必要に応じてダウンロードして実行し、処理の内容をクラウドサーバ部４のストーレッジであるメモリ部に、読み出し可能に保管するものである。ここでは、モジュールとは、ある機能を実行するためのプログラムの塊をいう。また、クラウドサーバ部４、クライアント部５の詳細は後述する。
【００２８】
ユーザ端末２は、種々の態様が想定される。ユーザ端末２は、携帯端末（携帯電話機、ＰＨＳ端末、スマートフォン、ＰＤＡ、タブレット端末等）、あるいはパーソナルコンピュータ（ＰＣ）である。ユーザ端末２は、個人の所有物か否かに限定されない。なお、ユーザ端末２は、ＳＮＳサーバ部３に登録されている場合もあれば、登録されていない場合もある。登録されていないユーザ端末２では、例えば、メールの他、掲示板、チャット（ｃｈａｔ）、ブログ（ｂｌｏｇ）への投稿（書込み）などが可能である。掲示板は、書込みと閲覧とが原則自由なもので、不特定多数の人々の情報提供及び閲覧を可能とするものである。チャットは、２人又はそれ以上の会員間でリアルタイムで打ち込んだ文章を端末画面上に表示してリアルタイムで会話的に通信するものである。ブログは、特定のドメイン内で運営されるウェブページ全体であるウェブサイトで、種々の話題について書き綴った文章や感想等を時系列に配置した日記的なウェブサイトである。
【００２９】
ＳＮＳサーバ部３は、既存の参加者の紹介等及び運用規則に従うことを条件に会員として参加できるウェブサイトを構成しているもので、これらの会員のみがメール、掲示板、チャット、ブログを利用して書込み（記事の投稿）や閲覧を可能にするコミュニケーションサービスである。ＳＮＳとしては、フェイスブック（Facebook）（登録商標）、ツイッター（Twitter）（登録商標）、またユーチューブ（You Tube（登録商標））等が知られている。
【００３０】
図２は、ＳＮＳサーバ部３の一実施形態を示すブロック図である。図２において、ＳＮＳサーバ部３は、コンピュータを備え、ＣＰＵ（Central Processing Unit）からなる制御部３１と、各種データを格納するストーレッジであるメモリ部３２とを有する。メモリ部３２は、ＳＮＳを運営等するために必要な種々の処理プログラムを格納する運営プログラムメモリ３２１、ログインしてきたユーザ端末２やクライアント端末５１に対して、それらの端末画面に表示する画面データや画面作成指示データが格納されている端末用画面作成指示データメモリ３２２、ＳＮＳの会員のデータを記憶する会員データメモリ３２３、及び各会員のＳＮＳ上のウェブページの内容を更新的に格納するウェブデータメモリ３２４を有する。
【００３１】
制御部３１は、運営プログラムメモリ３２１からのプログラムを図略のワークメモリ（ＲＡＭ：Random Access Memory）に読み出して実行することで、ＳＮＳの運営、すなわち上述の各種のサービス内容を実行制御するＳＮＳ運営制御部３１１と、会員の各種データを管理する会員データ管理部３１２と、ユーザ端末２、クライアント端末５１及びクラウドサーバ部４との間でデータ通信を行う通信制御部３１３として機能する。
【００３２】
会員データ管理部３１２は、ＳＮＳに登録するに際して、氏名と、ニックネームと、性別と、誕生日等の個人情報の入力乃至は格納処理、さらにログインＩＤ、パスワードの入力乃至は格納処理を行う。入力データは、会員データメモリ３２３に会員毎に対応付けて格納される。
【００３３】
ＳＮＳ運営制御部３１１は、会員による当該ＳＮＳに対するログインからログアウトまでの一連の処理を制御する。ユーザ端末２は、ウェブページ（HTML（HyperText Markup Language）形式のデータ）を閲覧可能なウェブブラウザを備えている。すなわち、ＳＮＳ運営制御部３１１は、あるユーザ端末２等から、ＳＮＳサーバ部３のＳＮＳ用のＵＲＬにアクセスが行われて、ユーザ名、パスワード及びログインＩＤが送信されてくると、会員データ管理部３１２によって適正な会員か否かの認証を行い、当該会員のログインに成功すると、ＳＮＳ運営制御部３１１は、会員のウェブページを当該会員のユーザ端末２へ送信する。ユーザ端末２は、ウェブブブラウザ上に、受信した当該会員のウェブページ等を表示する。そして、会員からの入力内容に従ってメール処理、チャット処理、その他の処理（投稿）を実行させると共に、入力されてきた投稿記事をウェブデータメモリ３２４に保管する。また、ＳＮＳ運営制御部３１１は、他の会員の投稿記事を、ログインしてきたユーザ端末２やクライアント端末５１に読み出して閲覧させる。
【００３４】
図３は、クラウドサーバ部４の一実施形態を示すブロック図である。図３において、クラウドサーバ部４は、コンピュータを備え、ＣＰＵからなる制御部４１と、各種データを格納するストーレッジであるメモリ部４２とを有する。メモリ部４２は、機能毎のモジュールメモリ（機能部メモリ）部４３とデータメモリ部４４とを有する。
【００３５】
制御部４１は、クラウドサーバ部４で、運営その他の所定の情報処理を実行する情報処理部４１１と、モジュールメモリ部４３の認証モジュールメモリ４３１のプログラムを図略のワークエリア（ＲＡＭ：Random Access Memory）に読み出して実行することで、ログインしてきたクライアント部５の認証を行う認証部４１２と、後述するインテリジェントメールモジュールを実行するインテリジェントメール処理部４１３と、クライアント部５、各ＳＮＳサーバ部３、及び（必要に応じて）ユーザ端末２との間でのデータ通信を行う通信制御部４１４として機能する。なお、クラウドサーバ部４は、ログインした状態のクライアント端末５１が、ＳＮＳサーバ部３を介して、会員であるユーザ端末２と通信する態様としてもよく、また、直接ユーザ端末２と通信可能としてもよい。
【００３６】
モジュールメモリ部４３は、各機能の処理プログラム（モジュール）を有し、認証処理を実行する認証モジュールメモリ４３１、投稿処理を実行する投稿モジュールメモリ４３２、モニタ処理を実行するモニタモジュールメモリ４３３、アサイン処理を実行するアサインモジュールメモリ４３４、ケースマネジメント処理を実行するケースマネジメントモジュールメモリ４３５、及びインテリジェントメール処理を実行するインテリジェントメールモジュールメモリ４３６を備えている。なお、投稿モジュールメモリ４３２〜ケースマネジメントモジュールメモリ４３５の処理内容は、図５〜図８を用いて詳細に説明する。インテリジェントメールモジュールメモリ４３６の処理内容は、図９を用いて詳細に説明する。
【００３７】
データメモリ部４４は、クライアント端末用画面・ＳＮＳ用データメモリ４４１と、クライアントデータメモリ４４２と、モニタデータメモリ４４３と、解析用データメモリ４４４と、アサインデータメモリ４４５と、インテリジェントメール通知スケジュールメモリ４４６とを備えている。データメモリ部４４の全部又は一部は、大容量を要することが想定されることから、通常のメモリの他、データベース（ストーレッジ）として、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）で構成されたものであることが好ましい。また、メモリ部４２では、基本的には、クライアント部５毎にアクセス可能なようにデータが保管されている。
【００３８】
クライアント端末用画面データ・ＳＮＳ用メモリ４４１は、クライアント端末５１の画面に表示される画像データ等、及びクラウドサーバ部４が会員として登録している各ＳＮＳのアドレスデータを格納する。クラウドサーバ部４は、基本的に全てのＳＮＳに対して会員として登録していることが好ましい。この結果、情報処理部４１１は、クライアント部５のクライアント端末５１から、クラウドサーバ部４を経由して全てのＳＮＳに（いわゆるソーシャルログインで）アクセスして、ＳＮＳの他の会員のウェブページを閲覧、モニタしたり、投稿したり、メールの授受ができるようになっている。
【００３９】
クライアントデータメモリ４４２は、クラウドサーバ部４の会員であってログインが許可された各クライアント部５に関するデータをクライアント部５毎に格納する。各クライアント部５に関するデータとは、クライアント部５を特定するデータ、及びクラウドサーバ部４と各クライアント端末５１とを通信可能に接続するためのドメインアドレスデータ、さらにクライアント認証のためのパスワード、ログインＩＤのデータ等である。
【００４０】
モニタデータメモリ４４３は、ＳＮＳサーバ部３経由のユーザ端末２からの投稿記事であって、いずれかのクライアント部５のクライアント端末５１で実行される、後述するモニタモジュールによるキーワード検索で抽出された投稿記事をクライアント部５に対応して個々に格納する。解析用データメモリ４４４は、後述するモニタモジュールで検索された投稿記事であるテキストデータの文章解析を行うための、辞書的な解析用データベースである。
【００４１】
アサインデータメモリ４４５は、投稿記事の内、注目する記事を投稿したユーザ端末２とクライアント部５を運営する事業主体内のスタッフのカスタマーサービスマンとして予め用意された要員（以下、スタッフという）のクライアント端末５１との紐付け結果（紐付けデータ）、及びスタッフ個々のデータ（スタッフデータ）を格納する。アサインデータメモリ４４５は、それぞれ紐付けされたスタッフとユーザとの間でフォローアップとしてやり取りされたメール等の履歴情報も個々に格納されており、これらのデータは、後述するケースマネジメント処理においても用いられる。なお、スタッフは、事業主体内のある組織（カスタマーサービス部門）の所属員に限定されてもよいし、より広い組織の人員乃至は全社員としてもよい。また、紐付けは、後述するように、同事業主体内のマーケッティング部門の人員によって行われてもよいし、モニタ結果に対して自動で選定処理されてもよい。インテリジェントメール通知スケジュールメモリ４４６は、後述するように、紐付け（アサイン）の依頼のためのスタッフへの依頼メールに対して応答メールが返信されてこない場合の、依頼メールの繰り返し送信の日程を決める送信スケジュールが格納されたものである。なお、依頼メールには、ＳＭＳ（Short Message Service）を含めてもよい。詳細は後述する。
【００４２】
図４は、クライアント部５のクライアント端末５１の一実施形態を示すブロック図である。図４において、クライアント端末５１は、コンピュータを備え、ＣＰＵからなる制御部５１ａと、各種データを格納するストーレッジであるメモリ部５１ｂとを有する。また、クライアント端末５１は、外部より入力可能なマウスやキーボードからなる入力部５１１と、入力データの表示の他、外部から取得したデータが表示される、液晶やプラズマディスプレイからなる表示部５１２とを備えている。
【００４３】
制御部５１ａは、ＣＰＵによって汎用プログラム（クラウドサーバ部４からダウンロードされるクラウドモジュールのアプリケーションのプログラムではなく、汎用としてインストールされているアプリケーションのプログラム）を実行することによって、文書（画像含む）作成の他、投稿のための文書作成等を行ったり、表示部５１２の画面に画像を表示したりする汎用プログラム実行部５２と、クラウドサーバ部４へのログイン後に、後述するクラウドモジュールメモリ５６にダウンロードされたクラウドモジュールのプログラムを実行するモジュール実行部５３と、ネットワーク１を介してクラウドサーバ部４やユーザ端末２等、またネットワーク１に接続されている図略のサイト等と通信する通信処理部５４として機能する。
【００４４】
メモリ部５１ｂは、クラウドサーバ部４にログインしない態様でクライアント端末５１を、通常使用の場合の、文章作成や画像表示等のための各種プログラムを格納する汎用プログラムメモリ５５と、クラウドサーバ部４にログインした場合にクラウドサーバ部４からのモジュールプログラムがダウンロードされるクラウドモジュールメモリ５６と、処理途中のデータを一時的に保管する等のワークメモリ５７とを備えている。
【００４５】
図５〜図８は、クラウドサーバ部４のモジュールメモリ部４３に格納されている各モジュールの処理内容を説明するブロック図である。図５〜図８に示す各ブロックは、クライアント部５のクライアント端末５１のクラウドモジュールメモリ５６にダウンロードされることで、クライアント端末５１のモジュール実行部５３にて実行される。従って、図５〜図８では、クライアント端末５１にダウンロードされた状態でのモジュール処理として説明する。
【００４６】
図５は、クラウドサーバ部４の投稿モジュールメモリ４３２に格納されている投稿モジュールをクライアント端末５１のモジュール実行部５３で実行する際の機能ブロック図である。投稿は、クライアント端末５１で行われる。すなわち投稿は、クラウドサーバ部４を経由してＳＮＳサーバ部３に対して行われ、また、さらにＳＮＳサーバ部３を介して特定のユーザ端末２に対して行われる。
【００４７】
図５において、モジュール実行部５３は、ダウンロードされた投稿モジュールを制御部５１ａのＣＰＵで実行することによって、投稿モード画面読出処理部５３１１と、ＳＮＳ選択処理部５３１２と、投稿処理部５３１３と、データ保管処理部５３１４として機能する。
【００４８】
投稿モード画面読出処理部５３１１は、クライアント端末５１の表示部５１２に対して、例えば図１９に示すような画面の表示を行う。
【００４９】
表示部５１２の画面６には、クラウドサーバ部４にログインした後の例えば初期画面（図１８参照）として、各モジュールに対応したボタンが表示されたモジュール選択画面が表示される。なお、図１８において、例えばログアウト指示ボタン等は省略されている。そして、この初期画面から所望する、すなわち図１９では投稿モジュールのボタンが選択された場合の切替後の画面の一例が示されている。
【００５０】
図１９において、投稿モジュールの画面６には、画面略中央の投稿記事入力ウィンドウ６１１、画面上側の投稿先（Post）リスト表示領域６１２、画面下側の処理ボタン表示領域６１３が配置されている。投稿記事入力ウィンドウ６１１は、入力部５１１を操作することで作成される投稿記事が表示される領域である。投稿先リスト表示領域６１２は、投稿先を指定するための領域である。投稿先は、クラウドサーバ部４が予め会員として登録したＳＮＳ等を含む。すなわち、クライアント部５の各クライアント端末５１は、クラウドサーバ部４のシステムを使用する態様では、クラウドサーバ部４が登録したＳＮＳにソーシャルログイン等のような特別の操作無しで接続可能とされる。例えば、クラウドサーバ部４は、登録対象のＳＮＳに対して、ソーシャルログイン機能、すなわち前述したＳＮＳであるソーシャルメディアのアカウントアドレスでログインできる機能を有する。従って、クラウドサーバ部４は、クラウドサーバ部４にログイン後のクライアント部５のクライアント端末５１によって投稿等のモジュールが実行される場合には、自動的に該当するＳＮＳにログイン可能にアカウント設定処理が実行される。投稿先リスト表示領域６１２の各ＳＮＳに対応するボタン（あるいはアイコン）のうち、希望するボタンが押下されることで、対応するＳＮＳが選択指定されるよう設定されていて、ソーシャルログインされる処理が行われる。
【００５１】
処理ボタン表示領域６１３には、左側から、投稿の指示を行う投稿指示ボタン、記事内容をクラウドサーバ部４に保管する指示を行う保管ボタン、及び投稿や保管のキャンセルを指示するキャンセルボタンが配置されている。
【００５２】
なお、画面６に表示されたボタンに対する指示は、一般的な操作方法、すなわち、画面６内を移動可能なカーソル画像（図略）と確定キーとを用いて行うことが可能である。あるいは、公知のように、画面６上に透明な感圧素子などが張設されたタッチパネル構造（入力部５１１の一実施例）とし、感知された押圧位置と画面６上のボタンの予め設定された表示座標との情報から、いずれのボタンが押圧されたかを判別する態様でもよい。
【００５３】
ＳＮＳ選択処理部５３１２は、入力部５１１の操作内容を受け付けて、投稿先リスト表示領域６１２に表示されている投稿先を示すボタンを選択する処理を行うものである。なお、デファクトとして、選択がない場合は、全てのＳＮＳが選択されたものとしてもよく、あるいはその逆としてもよい。
【００５４】
投稿処理部５３１３は、入力部５１１の操作内容を受け付けて、入力文章を投稿記事入力ウィンドウ６１１に表示し、さらに処理ボタン表示領域６１３の投稿指示ボタンの押下を受け付けて投稿処理を行うものである。
【００５５】
データ保管処理部５３１４は、処理ボタン表示領域６１３の保管ボタンへの操作を受け付けて、ＳＮＳ選択内容や投稿内容をクラウドサーバ部４のクライアントデータメモリ４４２に書き込むものである。なお、キャンセルボタンが押された場合には、投稿処理部５３１３やデータ保管処理部５３１４による処理がクリアされる。
【００５６】
なお、画面６の右上の「×」マークは、現在の画面から、前画面へ、あるいは図１８の初期画面への戻りを指示するものである。
【００５７】
図６は、クラウドサーバ部４のモニタモジュールメモリ４３３に格納されているモニタモジュールをクライアント端末５１のモジュール実行部５３で実行する際の機能ブロック図である。ここに、モニタモジュールは、ＳＮＳサーバ部３の会員であるユーザ端末２からの投稿記事を所定の条件の下で検索し、さらに所定の解析処理を施して、その結果を画面６に表示するものである。このモニタ処理は、種々の用途に適用されるが、自社製品やサービスの対する社会的な評判などの監視の他、有益な投稿記事を見つけて、関連部署内で回覧する等にも活用される。
【００５８】
図６において、モジュール実行部５３は、ダウンロードされたモニタモジュールを制御部５１ａのＣＰＵで実行することによって、モニタモード画面読出処理部５３２１と、サーチ条件設定処理部５３２２と、サーチ処理部５３２３と、解析処理部５３２４と、サーチ結果表示処理部５３２５と、解析結果変更処理部５３２６と、データ保管処理部５３２７として機能する。
【００５９】
モニタモード画面読出処理部５３２１は、クライアント端末５１の表示部５１２に対して、図２０に示すような画面６の表示を、一例として行う。図２０において、画面６は、ログイン後の初期画面からモニタモジュールのボタンが選択された場合の切替後の画面の一例を示している。なお、モニタモード画面読出処理部５３２１は、サーチ後には、図２１のような画面６の表示も行う。
【００６０】
図２０において、モニタモジュールの画面６には、上側から順に、例えばキーワード入力欄６２１、除外条件入力欄６２２、地理条件入力欄６２３、さらなる選択的な絞り込みのための注目条件（絞り込み条件）、例えば感情の状態に関する条件の注目条件設定欄６２４、検索ソースの選択欄６２５が配置されている。最下部には、保管ボタン、キャンセルボタン及び確定ボタン等を有する処理ボタン表示領域６２６が設けられている。最上部には、モニタモジュールから前画面、あるいは初期画面に戻る「×」ボタンが表示されている。キーワード入力欄６２１には、キーワードとして、例えば「Holiday Sales」が入力されている。あるいは、自社が提供している商品やサービスに関するキーワードを入力し、ソーシャルネットワーク上で最新の評価、評判がどのようなものかを探るようにしてもよい。また、注目条件設定欄６２４は、例えば投稿記事の内容を感情的に識別する場合の区分け、例えば積極性（Positive）、中立性（Neutral）、消極性（Negative）の選択欄が示されている。キーワード等によって検索された投稿記事は、解析処理部５３２４によって、後述するように解析処理に供される。
【００６１】
また、検索ソースの選択欄６２５は、クラウドサーバ部４がソーシャルログインを可能とするべく登録している各種のＳＮＳの選択画面である。ＳＮＳの選択状況は、例えばデファクトとして全てが選択された状態としてもよいし、その逆でもよい。検索範囲は、選択されたＳＮＳの会員のユーザ端末２の投稿記事となる。
【００６２】
サーチ条件設定処理部５３２２は、入力部５１１の操作を受け付けて、投稿記事に対するサーチ条件を設定するものである。サーチ条件としては、前述した、キーワード、除外条件、地理条件、注目条件（絞り込み条件）、検索ソースがある。なお、サーチ条件は、キーワードの他、検索ソースが採用されることが好ましく、さらには、注目条件（絞り込み条件）が採用されることが好ましい。その他のサーチ条件は、必要に応じて採用されることが好ましい。
【００６３】
サーチ処理部５３２３は、サーチ条件等が設定された状態で、処理ボタン表示領域６２６内の「ＯＫ」ボタンが選択されると、ウェブブラウザが実行されてサーチ処理を行う。サーチ処理は、基本的には一般的な文献サーチと同様な処理であり、例えば、各ＳＮＳを介して投稿された投稿記事内にサーチ条件の用語と同一の用語を照合し、一致する用語を含む投稿記事を抽出するものである。また、必要に応じて採用される地理的な条件については、地図を内蔵し、地図内で条件を満たす地名か否かを判断するようにすればよい。
【００６４】
解析処理部５３２４は、サーチの結果、抽出された投稿記事に対して、クラウドサーバ部４の解析用データメモリ４４４のデータベースを用いて所定の文章解析を実行するものである。ここでは、解析処理の一態様として感情解析が実行される。すなわち、ユーザの投稿記事から、その感情の解析を行うことで、ユーザの心理、特に企業にあってはユーザの評価、評判やユーザの嗜好を知ることが商品、サービスの開発にとって重要である。感情解析は、一例として以下のようにして実行される。解析用データメモリ４４４のデータベースは、この実施例では、感情の状態を示す文章例としての３個の文章データベースと、１個の用語スコアデータベースとを有する。感情の状態は、積極性、中立性、消極性の３種類に区分され、該当性乃至は確からしさを％比率（以下、スコアという。）で示している。前記３個の文章データベースは、前記した積極性、中立性、消極性に該当する文章例をそれぞれ区分して格納したもので、各文章例は、予めサンプルとして登録されたもの、及び事例として適宜追加されるものを含む。１個の用語スコアデータベースは、多数の用語（熟語も含むことが好ましい）を含み、かつ各用語に対して、積極性、中立性、消極性の３種類のいずれに該当するかの該当性等をスコアで設定している。例えば、「sweet」との用語の場合、積極性が６０％、中立性が３０％、消極性が１０％というようにスコアが設定され、また、例えば「stop」との用語の場合、積極性が１０％、中立性が２０％、消極性が７０％というようにスコアが設定される。本実施形態では、スコアの設定は、基本的に、当該用語を含む文章が、積極性、中立性、消極性の区分のうちの、どの区分の文章データベースに格納されているかによって計算される。例えば、前述の「sweet」の例では、「sweet」を含む文章が、仮に全部で１０個あるとした場合に、「積極性」区分の文章データベースに６個が、「中立性」区分の文章データベースに３個が、「消極性」区分の文章データベースに１個が存在していたことを意味する。参照される文章は、事例として適宜追加することでより該当性等を向上させることが可能となる。本システムはインターネット等のネットワークを用いること、また、世界中のユーザを対象とする場合には、データベースに登録される文章、用語の言語は英語に限らず、日本語やさらに他の国の言語を含めてもよい。
【００６５】
そして、解析処理は、検索された各投稿記事内から、用語抽出を行い、用語毎に行う。すなわち、解析対象の文章中から抽出された各用語について機械的に、積極性、中立性、消極性の各区分のスコアを区分毎に累積し（加算し）、最終的に累積値が最大となった区分の感情状態を、該当する感情区分として設定する。なお、用語単位での解析に代えて、あるいは加えて、２個続きの用語についての各区分毎のスコアを利用する方法を採用することで、より精度を上げることも好ましい。例えば、「…very sweet …」を含む文章があった場合に、「sweet…」と「very sweet」とを考慮するようにしたものである。また、解析結果の区分数は、３種類に限らず、注目対象である「消極性」に対する該当の有無という２区分としてもよい。また、解析は、本実施形態の方法に代えて、公知の他の方法も採用可能である。また解析は、感情に限定されるものではなく、モニタの目的によって種々の要素が採用可能である。
【００６６】
解析処理部５３２４で解析された結果は、注目内容として画面６に表示される。表示の態様は、感情区分を示すマークを該当性の有無によって認識容易に、例えば表示形態の違い（色、輝度の変更、サイズの大小変更、点滅の有無等を含む）を利用して行ってもよい。あるいは注目する対象は、ユーザ対応が必要となるような事例、代表的には「消極性」区分に該当するかどうかと考えられるから、「消極性」区分に該当するか否かのマークで識別表示する態様としてもよい。
【００６７】
サーチ結果表示処理部５３２５は、サーチ結果である投稿記事を時系列順に並べてリスト的に画面６に表示する。
【００６８】
解析結果変更処理部５３２６は、クライアント端末５１の操作者によって、投稿記事が読まれて、解析結果が妥当でないと判断された場合、例えば、感情区分を示すマークは「消極性」以外の「積極性」か「中立性」であることを示しているにも関わらず、投稿記事は「消極性」に該当すると思われる場合（あるいはその逆の場合）に、操作者によって、該当性の変更を指示操作することで、該当性を変更することができるようにするものである。解析結果変更処理部５３２６は、例えば、区分を示すマークの表示域の押下を受け付けて、指示された区分に変更する処理を行う。また、解析結果変更処理部５３２６は、区分が変更された投稿記事を注目事例ベースとして変更された区分の文章データベースに格納し、用語スコアデータベースの当該文章に含まれる各用語のスコアを計算し直す処理を実行する。このように、事例ベースを参照して用語の感情性に関するスコアをより現実に即して変更、すなわち学習させることができるので、クラウドサーバ部４が実行される度に精度向上が図れる。
【００６９】
図２１は、サーチ結果の画面の一例を示す図である。図２１に示す画面６において、左右方向中央部が、検索された投稿記事を上下に時系列順に並べるための表示ウィンドウ６３１である。表示ウィンドウ６３１の上部には、ヘッダウィンドウ６３２が表示されている。このヘッダウィンドウ６３２には、キーワード表示欄６３２１の他、凡例としての、アサインの有無表示欄６３２２、積極性表示欄６３２３、消極性表示欄６３２４が設けられている。キーワード表示欄６３２１には、図２０に対応して「Holiday Sales」が例示されている。アサインの有無表示欄６３２２には「Assigned」の文字が表示され、積極性表示欄６３２３には積極性が視認容易なマーク、ここでは「星形」マークが表示され、該当の有無で識別可能に表示される。例えば有彩色と無彩色というような色違いである。消極性表示欄６３２４には、注目すべき（Watch Out）であることを印象付ける所定のマーク、ここでは感嘆符（Exclamation Mark）「!」マークが表示され、該当の有無で識別可能に表示される。例えが有彩色と無彩色というような色違いである。すなわち、本実施形態では、有彩色の「星形」マークが「積極性」に対応し、有彩色の「!」マークが「消極性」に対応し、いずれにも該当しない、つまり両方のマークが無彩色のとき、「中立」に対応する。一方、入力部５１１によって「星形」マーク、「!」マークを指定すると、表示色が反転し、すなわち該当性が変更される。この変更は、解析結果変更処理部５３２６によって、上述のように処理される。
【００７０】
また、表示ウィンドウ６３１には、上下方向に複数の投稿記事が表示されている。操作部５１２によって下方へのスクロールを指示することで、より古い投稿記事の閲覧が可能とされている。各記事には、原則、ユーザの画像、投稿記事の表題、氏名、記事本文、投稿時刻などが表示されている。また、各記事の表示枠内には、上記凡例に対応した情報が表示されている。例えば、直近の投稿である最上段の記事には、「Watch Out」の欄に有彩色で「!」マークが表示されている。上から２つ目の記事では、有彩色で「星形」マークが表示されている。
【００７１】
また、最上位の記事には、１行目左側に「influence」表記欄６３１１、「VIP」表記欄６３１２が文字で表示されている。「influence」は、投稿回数とか投稿頻度、あるいは必要に応じて投稿内容などから判断し、このユーザが他のユーザに対する影響度の高いことを示すものである。「influence」の判断は、回数、頻度等であり、またこれらの情報をログすることで、アドレスや氏名等から自動的に選別して、クラウドサーバ部４のメモリ部、例えば解析用データメモリ４４４に保管する。「VIP」は、このユーザの社会に対する影響度が高いことを示すものである。「VIP」の判断は、有名人、著名人か否かであり、アドレスや氏名等で「VIP」リストを予め乃至は適宜追加的に準備しておき、検索されたアドレスや氏名等と「VIP」リストとを照合することで、クラウドサーバ部４のメモリ部、例えば解析用データメモリ４４４に保管する。あるいは、操作者が判断して「VIP」マークを付与する操作を行う態様でもよい。
【００７２】
なお、例えば最上位の投稿記事には、その１行目右側に「Assigned to Simon …」表記欄６３１３がある。「Simon …」はスタッフの一人である。なお、この表示は、サーチ結果の表示と直接関係するものではないが、当該ユーザにアサインされたスタッフによるユーザ対応中であるが示されている。４つ目、６つ目の投稿記事も同様に既にスタッフがアサインされていることが判る。なお、アサイン処理については、後述する。
【００７３】
また、各記事の表示欄の適所、例えば１行目左端には、記事の出典すなわちソースを示すマーク６３１４が表記されている。２つめの記事は、ツイッター（登録商標）であることが判る。図２１の例では、その他の記事として、各種ＳＮＳ経由で投稿されたものの他、ＳＮＳ経由でない投稿記事も検索されている。このように、モニタ処理は、いずれかのＳＮＳに限定して検索される態様でもよいし、検索範囲がＳＮＳ内に限定されない態様でもよい。いずれのＳＮＳからの投稿記事かは、ソースマーク６３１４の併記で容易に視認できるので、関連する記事のソースマークをウオッチすることで、噂や評判に対する対応策も立てやすいといった利点がある。
【００７４】
なお、図２１では、画面６の左側に、スタッフリスト表示欄６３３が表示されている。サーチ結果を単に表示する画面では、スタッフリスト表示欄６３３は表示されない。すなち、サーチ結果の画面に対して、後述するアサイン処理への移行を指示した状態で、図２１のような画面に切り替わる。この表示例では、スタッフは、氏名の先頭文字がＡ、Ｂ、Ｃ…順で配列されており、スクロールによって所望するスタッフの氏名をスタッフリスト表示欄６３３に表示することが可能である。なお、サーチ結果の表示画面に連動してスタッフリスト表示欄６３３が表示される態様としてもよい。
【００７５】
データ保管処理部５３２７は、図２０、図２１の内容をクラウドサーバ部４のモニタデータメモリ４４３に保管するものである。このように、一時的な保管を可能にすることで、所望時に読み出して処理を続行することが可能となり、操作性が向上する。
【００７６】
図７は、クラウドサーバ部のアサインモジュールメモリに格納されているアサインモジュールをクライアント端末５１のモジュール実行部５３で実行する際の機能ブロック図である。アサインモジュールは、検索された投稿記事を投稿したユーザ端末とクライアント部５のスタッフのクライアント端末５１とを紐付ける（アサインする）処理を実行するものである。
【００７７】
クライアント部５内のクライアント端末５１は事業主体内の人員に割り当てられている。そのうち、所定部門、例えばカスタマーサービス部門のスタッフはユーザに対するフォローアップ要員として配属されている。あるいは、事業主体の規模、分野によっては、事業主体の複数の部署、乃至はほぼ全員をスタッフとする体制としてもよい。かかるスタッフは、上述した、消極性の高い記事の投稿者のユーザ端末２にネットワーク上で紐付けされる。より詳細には、クライアント部５を備える事業主体は、例えばマーケッティング部門のスタッフによって、モニタが行われ、ユーザからの投稿記事のうち注目記事である消極性区分に該当する記事の投稿者に対して、カスタマーサービス部門等のスタッフを手動乃至は自動で割り当てて（紐付けて）、投稿内容に対してフォローすることで、誤解を解いたり、誤った認識を切り替えてもらったりすることが望まれる。ソーシャルネットワーク社会においては、勘違いなどに起因する、１つの心証を損なう（主には消極性の高い）投稿記事によって、意に反して売り上げがダウンしたり、取り返しのつかない信用失墜を招いたりする虞がある。従って、かかる誤解に基づくような記事を、図２１の画面から可及的速やかに発見して、迅速にフォローアップすることがマーケティング戦略として重要となる。
【００７８】
すなわち、アサインモード画面読出処理部５３３１は、サーチ結果画面に引き続いてアサインモジュールを指定した場合、あるいは一旦クラウドサーバ部４のモニタデータメモリ４４３に保管したサーチ結果を、アサインモジュールでクラウドサーバ部４から読み出すことで図２１に示す画面のように表示する。
【００７９】
アサイン処理部５３３２は、スタッフの一人を注目する記事に紐付ける処理を行う。入力部５１１によって、スタッフリスト表示欄６３３のいずれかのスタッフと、注目記事の表示欄とを関連付けることで紐付けが実行される。ここに、「紐付け処理」とは、クライアント部５内のマーケッティング部門のスタッフ（紐付け担当者）が、図２１を閲覧しながら、スタッフリスト表示欄６３３から１人のスタッフを選択し、そのスタッフが操作するクライアント端末５１と、記事を投稿したユーザのユーザ端末２（メールアドレアス）との組合せを設定することの処理である。また、「紐付け完了」とは、そのスタッフのクライアント端末５１に、投稿記事及びそのユーザ端末２のメールアドレアスがリンクされて、ケースマネジメント処理の対象として設定されることである。紐付け処理のための操作は、例えば入力部５１１がマウスの場合、画面上でマウスポインタがスタッフ欄の枠に重なった状態でマウスのボタンを押し、そのままの状態でマウスポインタを移動、すなわちドラッグさせ、表示ウィンドウ６３１内の指定予定の記事の表示欄上でマウスのボタンを離す、すなわちドロップすることで行われる。
【００８０】
アサイン処理部５３３２は、紐付けを行うための操作、例えば上記のドラッグアンドドロップ操作が終了すると、当該処理に応等して、当該スタッフのクライアント端末５１に紐付けを行うことの依頼メールの作成画面に切り替わり、必要な依頼メールの作成及びその通知、すなわち送信処理を実行する。
【００８１】
図２２は、アサインの依頼メールの作成画面の一例を示している。図２２において、画面６には、紐付け依頼文を入力するための文書入力欄６４１が示されている。紐付け依頼文としては、例えば「Would you like to assign [employeename] to this post？」である。なお、アサイン対象のユーザ端末２のアドレスデータ等は「this post」として、添付して送信されるようにしてある。また、必要に応じてコメントが追記可能なコメント入力欄６４２が設けられている。画面６の下部には、操作表示域６４３が設けられており、その中には通知指示を示すＯＫボタンと、通知を中止するキャンセルボタンとが表示されている。
【００８２】
データ保管処理部５３３３は、アサインの紐付け内容を、アサインデータメモリ４４５に保管する。
【００８３】
図８は、クラウドサーバ部のケースマネジメントモジュールメモリに格納されているケースマネジメントモジュールをクライアント端末５１のモジュール実行部５３で実行する際の機能ブロック図である。図８において、モジュール実行部５３は、ダウンロードされたケースマネジメントモジュールを制御部５１ａのＣＰＵで実行することによって、ケースマネジメントモード画面読出処理部５３４１と、ユーザ対応処理部５３４２と、フォローアップ監視処理部５３４３と、データ保管処理部５３４４として機能する。
【００８４】
ケースマネジメントモード画面読出処理部５３４１は、クラウドサーバ部４にログインして、ケースマネジメントモジュールを指定した場合に、ケースマネジメントモジュールでクラウドサーバ部４から読み出すことで、後述する図２３に示すような、アサインされた各案件のスタッフ名を含む一覧画面をスクロール可能に表示させるものである。
【００８５】
ユーザ対応処理部５３４２は、図２３に示すアサインされたスタッフの一覧画面に対して、自己の案件が選択された場合に、リンクされている、アサイン済みのユーザとのメールの一覧が履歴として表示され、必要に応じて返信メールを作成したり送信したりし、あるいはユーザ対応としての他の処理が実行可能とされる。
【００８６】
フォローアップ監視処理部５３４３は、図２３に示すアサインされたスタッフの一覧画面に対して、自己以外の他人の案件が選択された場合に、それらのフォローアップ状況を監視的に閲覧するなどして、進捗の把握を支援するものである。この閲覧によって、スタッフの変更なお、フォローアップの催促を指示することも可能となる。
【００８７】
図２３は、ケースマネジメントモード画面の一例を示す図である。図２３の表示例では、画面６の左右方向中央部に、アサイン済みリストウィンドウ６５０が表示されている。アサイン済みリストウィンドウ６５０には、ＩＤ番号表示欄６５１〜アサイン済みスタッフ表示欄６５６が設けられている。メール履歴情報６５８，６５９は、アサイン済みリストウィンドウ６５０の１行目に対応するフォローアップのためのメールの履歴情報で、この事案では、メールが２件あったことが判る。フォローアップのためのメールは、対応する事案にリンクが張られて、読み出し指示を受けつけてメール履歴情報６５８，６５９のように表示される。なお、メールの履歴情報６５８，６５９は、１行目に限定されず、アサイン済みリストウィンドウ６５０に表示されている中から、ケースマネジメントをする者が選択した事案の履歴情報でもよい。ここに、ケースマネジメントをする者とは、予め専任された者でもよく、あるいはマーケッティング部門、カスタムサービス部門の専任者、責任者乃至はいずれのスタッフであってもよい。
【００８８】
ＩＤ番号表示欄６５１は事案の識別番号を表示している。ソース表示欄６５２は、投稿記事の出典を、固有のマーク、ロゴで表示している。ユーザ名表示欄６５３は投稿者の氏名を表示している。表題表示欄６５４は、投稿記事の表題を表示している。日付表示欄６５５は投稿日時を表示している。アサイン済みスタッフ表示欄６５６は、当該ユーザに紐付けされたスタッフ名を表示している。また、表示内容を上下方向に公知の方法でスクロールすることで全てのアサイン状況を確認することができる。スタッフリストウィンドウ６５９は、スタッフ全員のリストである。スタッフリストウィンドウ６５９を併記することで、各事案の履歴情報から、問題となるケースに対して、スタッフの交代等も可能となる。
【００８９】
データ保管処理部５３４４は、図２３の内容をクラウドサーバ部４のアサインデータメモリ４４５に保管するものである。
【００９０】
図９は、クラウドサーバ部のインテリジェントメールモジュールメモリ４３６に格納されているインテリジェントメールモジュールをインテリジェントメール処理部４１３で実行する際の機能ブロック図である。インテリジェントメールモジュールは、モニタモジュールの処理によって検索された、注目の投稿記事を投稿したユーザ端末２に対してクライアント部５内のスタッフのクライアント端末５１を紐付け（アサイン）する際の、アサイン処理部５３３２による依頼メールの送信に対する応答メールを受信したか否かを確認し、応答がない場合に再通知する処理を行うものである。より詳細には、紐付け予定スタッフのパーソナルコンピュータ（ＰＣ）に、アサイン処理部５３３２によって、紐付け依頼のための最初の依頼メールが送信される。この最初の依頼メールの送信先であるパーソナルコンピュータ（ＰＣ）を扱うスタッフが速やかに、例えば当該スタッフのパーソナルコンピュータ（ＰＣ）をクラウドサーバ部４にログインし、乃至はログイン中で、この依頼メールを開いて、依頼を受け付ける等の応答処理を行った場合には、データ保管処理部５３３３によってクラウドサーバ部４のアサインデータメモリ４４５に送られ、インテリジェントメール対象外の処理が行われて本処理は終了する。一方、最初の依頼メールに対して応答がない場合には、本インテリジェントメールモジュールが起動することになる。
【００９１】
インテリジェントメール処理部４１３は、インテリジェントメールモジュールメモリ４３６のプログラムが実行されることで、通知管理部４１３１、再通知処理部４１３２、最終通知処理部４１３３、及びタイマ４１３４として機能する。
【００９２】
通知管理部４１３１は、最初の依頼メールに対してリアルタイムで応答メールがあった場合はインテリジェントメール処理に移行せず、それ以外の場合に、監視対象として本インテリジェントメールモジュールを起動する処理を行う。また、通知管理部４１３１は、送信先であるスタッフのパーソナルコンピュータ（ＰＣ）から、紐付けの依頼メールへの受諾の有無に関わらず、応答メールが返信されてきたことを受けると、応答ありとして処理する。なお、応答メールの返信操作は、応答予定者のクライアント端末５１がクラウドサーバ部４にログインした状態で行われ、その返信先は、最初の依頼メールを送信したマーケテフィング部門のスタッフのクライアント端末５１であればよい。インテリジェントメール処理部４１３は、かかる応答メールの返信を監視する。なお、紐付け依頼メール、依頼予定者に関する情報は、例えば、アサインデータメモリ４４５に紐付け依頼情報として格納し、紐付けの結果が確定した時点で、確定（又は取消）の処理を行えばよい。
【００９３】
インテリジェントメール通知スケジュールメモリ４４６は、後述するように、紐付けの依頼メールを繰り返し行う（送信する）際の、依頼メールの送信スケジュールが格納されたものである。依頼メールの送信スケジュールは、送信間隔が漸次延長される。例えば、最初の依頼メールの送信から２回目の依頼メールの送信までが１時間、２回目の依頼メールの送信から３回目の依頼メールの送信までが３時間、３回目の依頼メールの送信から４回目の依頼メールの送信までが半日、４回目の依頼メールの送信から５回目の依頼メールの送信までが２日、５回目の依頼メールの送信から６回目の依頼メールの送信までが１週間である。そして、対象のスタッフに組織の所属長乃至は責任者が存在する場合、さらに１週間後に当該所属長乃至は責任者のパーソナルコンピュータ（ＰＣ）に最終通知メールが送信される。このように、メールの送信間隔を漸次延長することで、緊急性に応えながらも、全体としてメール数を少なくすることができる。例えば２回目と同じ間隔である１時間の周期で同様の依頼メールを送信すると、１週間不在の場合を想定すると、本実施形態では６回で済むが、１時間毎の場合、１６８（＝２４×７）回となり、トラフィック過多の他、それらの間に重要なメールが埋もれている場合に誤って削除してしまうといった危険を抑止し難い。
【００９４】
なお、通知管理部４１３１は、初回とそれ以降の依頼メールにおいて、メール文章を変更する態様としてもよい。例えば、送信回数に応じて、文字の形態、例えば大きさや色等をより刺激性、視認性を高めるように変更してもよい。特に、最終の所属長乃至は責任者への依頼メールでは、送信履歴情報を付加してもよい。
【００９５】
なお、依頼メールの送信スケジュールは、１種類に限定するものではなく、スタッフ側の状況、ユーザ側の状況及び記事の内容如何によって複数種類が選択可能に準備されていることが好ましい。例えばスタッフの場合、現在の紐付き案件数が考慮され、件数が多ければ、依頼メールのスケジュールは相対的に延長方向とされる。ユーザの場合、ユーザが有名人、投稿件数が多い人、影響度の高い人であれば、スケジュールは相対的に短縮方向とされる。記事内容の場合、緊急性を要するものや、重大な場合、例えば記事内に時期に関する用語や「rapid」、「serious」のような緊急性、重大性を示唆するような用語があった場合、依頼メールのスケジュールは相対的に短縮方向とされる。相対的な短縮方向とは、例えば、前記の例の間隔に対して、それぞれ１倍未満の、例えば１／２程度とか、最終通知メールをもっと早い回数で行う等である。逆に相対的な延長方向とは、それぞれ１倍を超える、例えば２倍程度とか、最終通知メールをもっと遅い回数で行う等である。また、途中から、例えば２回目以降の依頼メールに対して延長割合、短縮割合が異なる態様としてもよい。いずれのスケジュールを採用するかは、最初の依頼メールを発した、紐付け管理者が設定してもよいし、通知管理部４１３１が、前述のスタッフ、ユーザ、記事内容の各状況を判断して、複数の中から自動で設定する態様でもよい。
【００９６】
再通知処理部４１３２は、初回の依頼メールに対して応答メールの返信がない場合に、２回目移行の依頼メールの送信処理を実行するものである。最終通知処理部４１３３は、複数回の依頼メールに対して応答メールの返信がなく、最終回となった場合の最終依頼メールの送信処理を実行するものである。
【００９７】
タイマ４１３４は、２回目及びそれ以降の送信日時を検出するためのものである。すなわち再通知処理部４１３２は、タイマ４１３４の計時情報と、初回の依頼メールの時刻及びインテリジェントメール通知スケジュールの内容とから、２回目以降の依頼メールの送信時刻に達したか否かを判断し、該当すれば送信処理を実行する。最終通知処理部４１３３は、タイマ４１３４の計時情報と、初回（あるいは最終の１回前）の依頼メールの時刻及びインテリジェントメール通知スケジュールの内容とから、最終依頼メールの送信時刻か否かを判断し、該当すれば送信処理を実行する。例えば、最初の依頼メールの送信が、本日のＡＭ９時３０分であったとするとき、時間が１時間経過して、ＡＭ１０時３０分に達すると、再通知処理部４１３２は、２回目の送信時刻に一致したと判断して、２回目の依頼メールの送信処理を実行する。
【００９８】
図１０〜図１５は、クラウドサーバ部４から読み出されて、クライアント端末５１の制御部（ＣＰＵ）によって実行される各モジュールの手順の一実施形態を説明するフローチャートである。
【００９９】
図１０は、投稿処理の手順の一実施形態を説明するフローチャートである。図１０において、まず、クライアント端末５１からクラウドサーバ部４にログイン要求があり、所定の認証処理を経てログインが認められると、初期画面（図１８）が表示され、この表示画面で投稿モジュール実行のボタンが押下されると、図１９に示す投稿モード画面がクライアント端末５１の表示面に表示される（ステップＳ１）。
【０１００】
次いで、投稿モード画面で、ＳＮＳ選択指示か否か、投稿原稿の作成か否か、又は投稿指示か否かが判断される（ステップＳ３）。一般的には、まず、ＳＮＳ選択指示、投稿原稿の作成が行われる。そして、ＳＮＳ選択指示であれば、選択されたＳＮＳが投稿の宛先として設定（ソーシャルログイン）される（ステップＳ５）。一方、投稿記事の作成が実行されるのであれば、投稿記事作成処理が実行される（ステップＳ７）。また、ＳＮＳが選択され（あるいはデファクトのままでもよい）、投稿記事が作成されたのであれば、投稿指示の有無が判断される。投稿指示であれば、投稿処理が実行される（ステップＳ９）。投稿記事としては、クライアントの事業主体による新たな宣伝や広告が想定される。次いで、投稿記事及び投稿先（ＳＮＳ）がクラウドサーバ部４の当該クライアント部でデータ領域に格納される（ステップＳ１１）。
【０１０１】
図１１は、モニタ処理の手順の一実施形態を説明するフローチャートである。図１１において、まず、クライアント端末５１からクラウドサーバ部４にログイン要求があり、所定の認証処理を経てログインが認められると、初期画面（図１８）が表示され、この表示画面でモニタモジュール実行のボタンが押下されると、図２０に示す、検索条件を入力するためのモニタモード画面がクライアント端末５１の表示面に表示される（ステップＳ２１）。
【０１０２】
次いで、このモニタモード画面で、ＳＮＳ選択指示か否か、キーワード入力操作か否かが判断される（ステップＳ２３）。ＳＮＳ選択指示であれば、指示されたＳＮＳがモニタの対象として選択設定される（ステップＳ２５）。また、キーワード入力操作であれば、キーワード入力欄６２１にキーワードが入力される（ステップＳ２７）。
【０１０３】
続いて、サーチ指示の有無が判断され（ステップＳ２９）、ＯＫボタン６２６が押下されると、サーチ処理が実行される（ステップＳ３１）。サーチ指示がなければ、例えばある時間経過後に、あるいはキャンセル操作（図略）を経て本フローを抜ける。サーチ処理は、選択されたＳＮＳの範囲内で、キーワードを含む投稿記事を検索し、抽出するものである。そして、抽出された投稿記事のそれぞれに対して、前述した解析処理が施される（ステップＳ３３）。次いで、抽出された投稿記事に対して、さらなる絞り込みが行われたか否かが判断され（ステップＳ３５）、絞り込みが行われたのであれば、絞り込み処理が実行され（ステップＳ３７）、そうでなければ、スキップしてステップＳ３９に進む。なお、絞り込みは、ステップＳ３１の前（例えばステップＳ２７のキーワード設定のとき）に行うことができる態様としてもよい。ステップＳ３９では、抽出された投稿記事が画面６に時系列で所定の向きに、ここでは図２１に示すように縦方向に表示される。
【０１０４】
続いて、積極性表示欄６３２３、消極性表示欄６３２４に対する変更指示の有無が判断される（ステップＳ４１）。積極性表示欄６３２３、消極性表示欄６３２４の少なくとも一方に対して変更の指示があると、例えば表示状態が反転して、「該当有り」から「該当無し」、または「中立」に、あるいはその逆に交互変更される（ステップＳ４３）。ここでは、「星形」マークのオン、オフ、また「!」マークのオン、オフが変更指示可能になる。例えば、オン（有彩色）状態の「星形」マークをオフ（無彩色）にし、オフ状態の「!」マークをオンにすると、当該投稿記事は、感情解析結果が「積極性」から「消極性」に変更される。変更指示がなければ、ステップＳ４３はスキップされる。
【０１０５】
なお、上記変更処理の場合、当該モニタモードを一旦終了してデータがクラウドサーバ部４の解析用データメモリ４４４に反映される際に、上述したように、情報処理部４１１によって当該投稿記事が事例として追加され、かつ用語スコアデータベース内の用語のスコアの再計算が実行される。これによって、事例が追加される毎に、クラウドサーバ部４で用語スコアデータベースが更新されて解析精度の向上が図れる。
【０１０６】
続いて、アサインモジュールの選択が指示されたか否かが判断され（ステップＳ４５）、指示されなければ本フローを抜け、指示されたのであれば、アサインモジュール処理に移行する（ステップＳ４７）。
【０１０７】
図１２は、アサイン処理の手順の一例を示すフローチャートである。まず、スタッフに紐付けを行うための画面が表示され、次いで、紐付け設定操作があるか否かが判断される（ステップＳ５１）。紐付け設定操作があれば、紐付け処理、すなわち、まず依頼メールの送信が実行され（ステップＳ５３）、さらにその旨がクラウドサーバ部４のアサインデータメモリ４４５に保管される（ステップＳ５５）。ステップＳ５１において、アサインモジュール処理中に依頼メールに対する応答メールが受信されてくると、紐付け設定処理（受諾の有り無し）を行い、その旨、すなわちインテリジェントメール対象外とする情報が、クラウドサーバ部４のアサインデータメモリ４４５に保管される（ステップＳ５５）。紐付け処理中に応答メールが受信されない場合、インテリジェントメール処理の対象とされる。なお、受諾無しの場合には、他のスタッフが適宜設定されるようにすればよい。
【０１０８】
図１３は、ケースマネジメント処理の手順の一実施形態を説明するフローチャートである。ケースマネジメント処理は、ユーザに対するスタッフのフォローアップを確認するためなどの処理で、ログイン後にケースマネジメント処理が選択されると、図２３に示す画面が表示される（ステップＳ６１）。次いで、アサイン済みリストウィンドウ６５０内から所望する案件が選択されたか否かが判断される（ステップＳ６３）。ここでは、図２３に示す紐付けされたスタッフの一覧画面に対して、自己の案件が選択された場合には、リンクされている、紐付け済みのユーザとのメールの一覧が履歴として表示され、必要に応じて返信メールを作成したり送信したりし、あるいはユーザ対応としての他の処理が実行される（ステップＳ６５）。一方、自己以外の他人の案件が選択された場合には、それらのフォローアップ状況を監視的に閲覧し、スタッフの変更やフォローアップの催促の指示等を行って、進捗の把握を支援するようにしている（ステップＳ６７）。
【０１０９】
次いで、終了（ステップＳ６９）が指示されると（あるいはケースマネジメント処理から他の処理への移行を含む）、本フローを終了し、そうでなければ、ステップＳ６３に戻る。
【０１１０】
図１４は、投稿処理において送信先を指定して実行される、ユーザ対応メール処理Ｉの手順の一例を示すフローチャートである。この処理は、ステップＳ６５の一態様を示すものである。クライアントデータメモリ４４２の履歴内容を用いてのユーザ対応メール処理Ｉが実行される。
【０１１１】
まず、クラウドサーバ部４からケースマネジメントモジュールを選択し、紐付けされたユーザのうち、フォローアップ対象のユーザが指定される（ステップＳ７１）。次いで、フォローアップ対象のユーザへのメール画面が表示される（ステップＳ７３）。この画面に対して、スタッフによるユーザ対応（フォローアップ）のための文字入力操作等に従った文章入力処理が実行され、さらに送信指示を受け付けて送信処理が実行される（ステップＳ７５）。そして、入力されたユーザ対応文章及びその送信の履歴が、当該スタッフに対応してアサインデータメモリ４４５に更新的に保管される（ステップＳ７７）。
【０１１２】
図１５は、投稿処理で実行される、ユーザ対応メール処理IIの手順の一例を示すフローチャートである。フォローアップ処理IIは、スタッフがアサインされたユーザに、最初のユーザ応答メールを送信した後に行われる処理である。より詳細には、スタッフのクライアント端末５１がクラウドサーバ部４にログインされ、当該スタッフの受信メール履歴（図２３参照）を開くことで、本フローが開始される。そして、アサインされたユーザからの受信メールがあり、これを開くことでユーザからのメールが画面に表示される（ステップＳ８１）。次いで、フォロー処理、すなわち再応答か否かが判断され（ステップＳ８３）、フォロー処理でなければ、本フローを抜ける。一方、フォロー処理であれば送信モードに切替えられ、フォロー文の入力操作に応じて文章が入力され、送信指示によって当該ユーザに返信される（ステップＳ８５）。そして、入力されたユーザ文章及びその返信は履歴として、当該スタッフに対応してアサインデータメモリ４４５に更新的に保管される（ステップＳ８７）。
【０１１３】
図１６は、インテリジェントメール処理部４１３によって実行される、紐付けの依頼メールに対する応答メールを受信した際の処理の一例を示すフローチャートである。
【０１１４】
まず、紐付けの最初の依頼メールが紐付け予定のスタッフに送信された後、このスタッフ（未応答スタッフ）から応答メールがあったか否かが判断される（ステップＳ９１）。未応答スタッフからの応答メールでなければ、本フローを抜ける。一方、未応答スタッフからの応答メールであれば、アサイン処理が実行される（ステップＳ９３）。アサイン処理とは、依頼メールを受諾する場合、断る場合の双方を含む。いずれの場合でも、アサイン依頼メールに対して結果が得られるからである。次いで、インテリジェントメール対象外処理が実行されて（ステップＳ９５）、すなわちアサインデータメモリ４４５から削除されることで、当該案件についてのインテリジェントメール処理の対象から外される。
【０１１５】
図１７は、インテリジェントメール処理部４１３によって実行される、インテリジェントメール処理の手順の一例を示すフローチャートである。なお、この処理はアサインの依頼メールに対して応答メールを返信していないスタッフの全員を対象に行われるが、以下の説明では、便宜上、ある１人のスタッフを対象者として説明する。
【０１１６】
まず、タイマ４１３４によって基準時間、例えば１秒（あるいは１分等でもよい）単位等で計時処理が実行されて（ステップＳ１０１）、現在時刻が、対象となるスタッフに設定されている繰り返し再通知のタイミングに一致したか否かの判断が行われる（ステップＳ１０３）。すなわち、当該スタッフに対して設定された次の繰り返し再通知タイミングか否かが、インテリジェントメール通知スケジュールメモリ４４６の当該スタッフのスケジュールとタイマ４１３４の時刻情報とが比較されて判断される。繰り返し再通知のタイミングでなければ、本フローを抜けて、次のタイミングでの判断に進む。
【０１１７】
一方、繰り返し再通知のタイミングであれば、最終通知のタイミングか否かがスケジュールから判断される（ステップＳ１０５）。最終通知でなければ、依頼メールの再通知の指示を受けて再通知処理が実行され（ステップＳ１０７）、さらに、今回の再通知処理が履歴としてインテリジェントメール通知スケジュールメモリ４４６に保管されて（ステップＳ１０９）、本フローを抜ける。一方、最終通知であれば、管理者ありか否か、すなわち管理者が設定されているか否かが判断され（ステップＳ１１１）、設定されていれば、当該管理者のクライアント端末５１に最終通知が行われる（ステップＳ１１３）。そして、最終通知処理の後、履歴がインテリジェントメール通知スケジュールメモリ４４６に保管される（ステップＳ１０９）。一方、管理者が設定されていない場合には、最終通知は行われない。なお、管理者が設定されていない場合には、直前の再通知メール（最後の再通知メール）において、最終であることを視認容易に、例えば色や文字の大きさ等の表示形態を変えて送信し、注意喚起するようにしてもよい。
【０１１８】
なお、本発明は、以下の態様が採用可能である。
【０１１９】
（１）紐付けすべきスタッフの選定は、以下のようにしてしてもよい。例えば、各スタッフに対応付けられた属性情報に、混み具合等の状況（フォローアップ件数）、経験乃至は得意分野等、苦情者の属性（年令、性別他）との差、またインフル性（影響度合い）等の適合性を閲覧可能に含み、これらの適合性を参照してユーザとの紐付けを選定し、乃至は自動選定するようにしてもよい。また、ユーザの属性（年令、性別他）、苦情内容（重大さ、緊急対処性）等を考慮して、分野、経験件数等の適合性も考慮してスタッフを選定するようにしてもよい。
【０１２０】
（２）本実施形態では、カスタマー要員である複数のスタッフの内のいずれかのスタッフのクライアント端末を、検索した記事の投稿者であるユーザのユーザ端末と紐付けるものとしたが、本発明はこれに限定されない。例えば、カスタマー要員である複数のスタッフの内のいずれかのスタッフのクライアント端末に、スタッフ各人にとって参考となるような有意義な記事を紐付けるものとしてもよい。これによれば、当該有意義な記事を他のスタッフも含めて報知したい場合に、紐付けられたスタッフから他のスタッフに配信などされることで、有意義な記事の周知徹底が図れる等の効果がある。
【０１２１】
（３）本実施形態では、カスタマー要員である複数のスタッフの内のいずれかのスタッフのクライアント端末に、記事投稿者であるユーザのユーザ端末と紐付けるための依頼メールを送信するものとしたが、本発明は、かかる態様に限定されず、以下の態様も含む。すなわち、本サービス支援サーバ装置（システム）では、ログインして所定のサービスを利用するものにおいて、情報通信が可能な２者の一方が、ログアウトしているときに、他方から受信があったことを効率的に通知するものである。
【０１２２】
（４）また、本発明は、チャットで相手側が不在（ログインなし）の場合に、かかる繰り返し通知のメール送信処理を実行するようにしてもよい。
【０１２３】
（５）例えば午前、午後、あるいは日にちや曜日等の時間要素を（タイマ４１３４で監視して）加味して、いずれの繰り返し通知スケジュールを採用するかが自動的に選定されるようにしてもよい。また、送信相手（本実施形態ではスタッフ等）の年令、性別、キャリア、仕事の混み具合、その他の属性情報が予め判っている乃至は知得可能な態様では、これらの属性情報を活用して、いずれの繰り返し通知スケジュールを採用するかが自動的に選定されるようにしてもよい。
【符号の説明】
【０１２４】
１  インターネット（ネットワーク）
２  ユーザ端末
３  ＳＮＳサーバ部
４  クラウドサーバ部
４３  モジュールメモリ部（メモリ部）
４１４  通信制御部（通信部）
４３３  モニタモジュールメモリ
４３４  アサインモジュールメモリ
５  クライアント部
５１  クライアント端末（情報処理装置）
５３３２  アサイン処理部
５１２  表示部
６  画面
【図１】
2014194683.tif 000003
【図２】
2014194683.tif 000004
【図３】
2014194683.tif 000005
【図４】
2014194683.tif 000006
【図５】
2014194683.tif 000007
【図６】
2014194683.tif 000008
【図７】
2014194683.tif 000009
【図８】
2014194683.tif 000010
【図９】
2014194683.tif 000011
【図１０】
2014194683.tif 000012
【図１１】
2014194683.tif 000013
【図１２】
2014194683.tif 000014
【図１３】
2014194683.tif 000015
【図１４】
2014194683.tif 000016
【図１５】
2014194683.tif 000017
【図１６】
2014194683.tif 000018
【図１７】
2014194683.tif 000019
【図１８】
2014194683.tif 000020
【図１９】
2014194683.tif 000021
【図２２】
2014194683.tif 000022
【図２０】
2014194683.tif 000023
【図２１】
2014194683.tif 000024
【図２３】
2014194683.tif 000025