JP6175735B1 - ＳＮＳを利用したＷｅｂサイトの中継サーバ、システム、方法及びプログラム - Google Patents

Abstract

【課題】ＳＮＳを利用して、利用者が欲しい情報をより手軽に取得し、取得した情報を引き続き活用することができ、かつセキュリティも確保するシステムを提供する。【解決手段】中継サーバは、第１のＳＮＳサーバと第２のＳＮＳサーバとにネットワークで接続され、利用者からのＷｅｂサイトへの処理を管理する。中継サーバは、第１のＳＮＳサーバから利用者のメッセージを受信し、利用者が登録した登録サイトに対する処理要求であるか否かを判別するメッセージ判別手段と、登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、判別されたメッセージから登録サイトに対する処理要求を生成するサイト処理要求生成手段と、処理要求を受信したサイトからの応答情報に応じて、第１のＳＮＳサーバ又は第２のＳＮＳサーバに応答情報を返信するＳＮＳ返信手段と、を備える。【選択図】図２

Description

本発明は、ＳＮＳを利用して、Ｗｅｂサイトを利用するためのシステムに関する。

今日、様々なＳＮＳ（Social Networking Service)が登場し、世界中に広く普及している。ＳＮＳは、今や人間同士のコミュニケーションツールとしてだけでなく、人間とコンピュータ又は情報システムとの新たなコミュニケーション手段としても利用できる可能性を高めている。例えば、出願人においても、ユーザが普通の言葉でミニブログなどのＳＮＳに入力することで、銀行のネットバンキングの取引を行うことができる自然言語バンキングシステムを提案している（特許文献１参照）。

ところで、インターネットの世界で膨大なＷｅｂサイトが産まれた結果、利用者は、日常的に欲しい情報を取得するためであっても、様々なＷｅｂサイトに個々にアクセスを繰り返す必要が生じ、億劫を感じるようになっている。例えば、クレジットカードの利用金額や銀行残高を調べるためには、それぞれの金融機関のＷｅｂサイトでいちいちログインする必要がある。また、飲食店の検索を行うためには、分野によって複数のＷｅｂサイトを利用しなくてはならない。また、汎用の検索エンジンを使用した場合には、自分が求めている情報だけでなく不要な情報も数多く表示され、自分がよく使用しているＷｅｂサイトの情報を優先的に取得できないといったことが生じている。

上記のような問題を解決するため、非特許文献１のような複数の銀行口座の残高及びクレジットカードや電子マネーの利用金額をスマートフォンで１つにまとめて管理するアプリケーションも存在するが、銀行口座やクレジットカードなどの金融分野に留まり、セキュリティ上、あらかじめ登録した金融機関への残高照会や利用明細照会などから一方通行で情報を取得するにとどまっている。

特開２０１２−１８５６７２号公報

マネーツリー株式会社、"Ｍｏｎｅｙｔｒｅｅ"、［ｏｎｌｉｎｅ］、［平成２８年３月１１日検索］、インターネット、<URL:https://moneytree.jp/>

個人がＷｅｂサイトを利用する際には、情報の取得だけでなく、取得した情報に基づいて、引き続きなんらかの処理を行いたい場合が多い。例えば、銀行のネットバンキングを利用する際には、口座残高を確認してから、振込を実行したり、場合によっては、キャッシングを申し込んだりする場合もある。クレジットカードのＷｅｂサービスを利用する際には、カードの利用明細（Ｗｅｂ明細）を確認するだけでなく、貯まったポイントを活用したり、今月の支払をリボ払いに変更したりする場合もある。飲食店の検索を利用する際には、気に入った店が見つかれば、その店を直ぐに予約したい場合もある。

しかし、普段、コミュニケーションツールとして使っているＳＮＳ上から、上記のようなＷｅｂサイトをまとめて検索したり、利用したりする方法はあまり知られていない。一方で、ＳＮＳは、手軽なコミュニケーションツールではあるが、個人のプライバシーやセキュリティに関する不安も存在する。

したがって、本発明では、ＳＮＳの普及と、上記のような個人向け情報に関する状況に着目し、ネット上で個人が欲しい情報をより手軽に取得し、取得した情報を引き続き活用することができ、かつセキュリティも確保したシステムを提供することを目的とする。

上記課題を解決するため、本発明は、以下のような解決手段を提供する。
（１）本発明の第１の態様は、第１のＳＮＳサーバと第２のＳＮＳサーバとにネットワークで接続され、利用者からの登録サイトへの処理を中継する中継サーバであって、前記第１のＳＮＳサーバから前記利用者のメッセージを受信し、前記メッセージが前記登録サイトに対する処理要求であるか否かを判別するメッセージ判別手段と、前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイトに対する処理要求を生成するサイト処理要求生成手段と、前記処理要求を受信したサイトからの応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するＳＮＳ返信手段と、を備えることを特徴とする。

（２）また、上記（１）の構成において、前記メッセージが、前記利用者の普通に用いられる言葉からなる自然言語の文章である場合、前記メッセージの自然言語を解析する自然言語解析手段を更に備えるようにしてもよい。

（３）また、上記（１）又は（２）の構成において、前記登録サイトへの利用履歴情報に基づいて、利用頻度に応じて前記登録サイトの優先順位を判定し、前記優先順位に従って、前記応答情報の表示順を指示する優先サイト判定手段を更に備えるようにしてもよい。

（４）また、上記（１）〜（３）のいずれか１つの構成において、前記第１のＳＮＳサーバが送信した処理要求に対する応答情報の返信先のＳＮＳの識別子を、前記利用者に登録させる登録手段を更に備えるようにしてもよい。

（５）また、上記（４）の構成において、前記登録手段は、利用者固有のキーワードを前記キーワードテーブルに登録させ、前記サイト処理要求生成手段は、前記利用者固有のキーワードを前記キーワードテーブルに基づいて、前記登録サイトが処理可能なキーワードに変換するようにしてもよい。

（６）また、本発明の第２の態様は、利用者が登録した登録サイト並びに第１のＳＮＳサーバ及び第２のＳＮＳサーバがネットワークで接続されたシステムであって、前記第１のＳＮＳサーバは、前記利用者のメッセージを受信し、前記登録サイトに対する処理要求であるか否かを判別するメッセージ判別手段と、前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイトに対する処理要求を生成するサイト処理要求生成手段と、を備え、前記登録サイトは、前記処理要求に対する応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するＳＮＳ返信手段を備え、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバは、前記返信された応答情報を前記利用者の端末に送信する応答送信手段を備える、ことを特徴とする。

（７）また、本発明の第３の態様は、利用者が登録した登録サイト並びに第１のＳＮＳサーバ及び第２のＳＮＳサーバがネットワークで接続されたシステムであって、前記第１のＳＮＳサーバは、前記利用者のメッセージを受信し、前記メッセージが前記登録サイトに対する処理要求であるか否かを判別し、処理要求と判別した場合、前記メッセージを前記登録サイトに送信するメッセージ判別手段と、
を備え、前記登録サイトは、前記第１のＳＮＳサーバから前記判別されたメッセージを受信するメッセージ受信手段と、前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記メッセージから当該登録サイトの処理要求を生成するサイト処理要求生成手段と、前記処理要求に対する応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するＳＮＳ返信手段を備え、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバは、前記返信された応答情報を前記利用者の端末に送信する応答送信手段を備える、ことを特徴とするシステム。

（８）また、本発明の第４の態様は、ＳＮＳから入力した登録サイトへの処理要求を制御するための方法であって、第１のＳＮＳサーバが、利用者のメッセージを受信するステップと、前記メッセージが、前記登録サイトに対する処理要求であるか否かを判別するステップと、を実行し、前記第１のＳＮＳサーバ又は第２のＳＮＳサーバに接続され、前記利用者からの前記登録サイトへの処理を中継する中継サーバ又は前記登録サイトが、前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイト又は未登録サイトに対する処理要求を生成するステップと、前記処理要求を受信したサイトからの応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するステップと、を実行することを特徴とする。

（９）また、本発明の第５の態様は、ＳＮＳから入力した登録サイトへの処理要求を制御するためのプログラムであって、第１のＳＮＳサーバから利用者のメッセージを受信するステップと、前記メッセージが、前記登録サイトに対する処理要求であるか否かを判別するステップと、前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイトに対する処理要求を生成するステップと、前記処理要求を受信したサイトからの応答情報に応じて、前記第１のＳＮＳサーバ又は第２のＳＮＳサーバに前記応答情報を返信するステップと、をコンピュータに実行させることを特徴とする。

本発明によれば、個人が普段使っているＳＮＳを利用して、欲しい情報をより手軽に取得し、取得した情報を引き続き活用することができ、かつセキュリティも確保したシステムを提供することができる。

本発明の実施形態に係るシステムが提供するサービスの基本イメージを示す図である。 本発明の第１の実施形態に係るシステムの機能構成を示す図である。 本発明の第１の実施形態に係るキーワードテーブル及び利用者情報ＤＢに格納されるデータ構成の具体例を示す図である。 本発明の第１の実施形態に係るシステム間の連携フローを示す図である。 実際の利用シーンにおける利用者端末の画面例（その１）を示す図である。 実際の利用シーンにおける利用者端末の画面例（その２）を示す図である。 実際の利用シーンにおける利用者端末の画面例（その３）を示す図である。 実際の利用シーンにおける利用者端末の画面例（その４）を示す図である。 本発明の第２の実施形態に係るシステムの機能構成を示す図である。 本発明の第２の実施形態に係るシステム間の連携フローを示す図である。 本発明の第３の実施形態に係るシステムの機能構成を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号又は符号を付している。

（基本イメージ）
図１は、本発明の実施形態に係るシステム（以下、本システムと呼ぶ）が提供するサービスの基本イメージを示す図である。本システムにおいては、銀行のネットバンキングのサイト、クレジットカードのＷｅｂサービスのサイト、ネットモールのサイトなど、専用のＷｅｂサイト（以下、単にサイトと呼ぶ）でログインしなければ取得できない情報のやりとりをＳＮＳと連携させる。また、飲食店の検索サイトなど、ログインが必要ないサイトもＳＮＳと連携させる。すなわち、本システムは、ＳＮＳを検索窓口として、利用者が関連するキーワードを「呟く」（普段使っている言葉で入力する）ことで、欲しい情報をＳＮＳが備えるダイレクトメッセージなどの手段で受け取れるようにするサービスを提供する。

連携させるＳＮＳは、１つでなくともよく複数であってもよい。ここでいうＳＮＳとは、Ｔｗｉｔｔｅｒ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）、ＬＩＮＥ（登録商標）、ｍｉｘｉ（登録商標）、Ｉｎｓｔａｇｒａｍ（登録商標）などの他、１対１での文字情報のやりとりが可能な手段であればよく、通常のＥメールやＳＭＳ（Short Message Service)のような手段を含んでもよい。利用者は、ＳＮＳを窓口とすることで、複数のウェブサイトに別々にアクセスする必要がなくなり、いちいちそれぞれのウェブサイトにログインする必要もなくなる。

図１で示すように、本システムの利用者は、ログインしているＳＮＳ上で、欲しい情報を「呟く」と、利用者が普段使っているサイト（登録サイト）の中から、その情報を取得可能な、又は処理可能なサイトを、その呟きを解析して抽出し、そのサイトに対して、ＳＮＳ経由で希望する処理の要求が送信される。その際、利用者は、普段の呟きと区別するために、ハッシュタグ（言葉やスペースのないフレーズの前にハッシュ記号（番号記号）、#を付ける形のラベル）も同時に呟いておいてもよい。例えば、本サービスを識別するためのハッシュタグを「#want」とし、「#want 今月のクレジットカードの利用料金」、「#want 銀行口座の残高」、「#want 今夜、行ける飲食店、イタリアン、３０００円くらい」などのような呟き（メッセージ）をＳＮＳに入力する。このメッセージを受信したＳＮＳは、メッセージの言葉を解析し、その目的に対処可能なサイトを特定し、そのサイトが処理可能な情報を含む処理要求に変換し、サイトに送信する。サイト側は、この処理要求に対しての処理結果をＳＮＳ経由で利用者に返信する。ここで、利用者がサイトにアクセスするための情報（サイトのＵＲＬ、ログインＩＤ、パスワードなど）は、あらかじめ本システムに登録しておくものとし、ＳＮＳ上でメッセージを入力するだけで目的のサイトに自動的にログインする。したがって、各サイトには別途ログインする必要はない。

対象となる登録サイトとしては、銀行のネットバンキングのサイト、クレジットカード会社のＷｅｂサービスのサイト、多数のネット店舗を統括するネットモールのサイト、その他各種検索サイト（飲食店検索サイト、価格比較サイト、旅行検索サイト、チケット予約サイトなど）が主なものである。例えば、ネットバンキングのサイトでは、情報の取得として、口座残高の照会や入出金明細の照会だけでなく、取得した情報の結果を確認して、振込やキャッシングの申し込みができる。

それぞれのサイトは、業種（分野）ごとに複数であってもよい。例えば、図の例のように、「#want 今月のクレジットカードの利用料金」と呟いた場合は、利用者が登録しているクレジットカードが複数あれば、それぞれのクレジットカードのサイトに「今月の利用明細」の情報の処理要求がなされ、その返信情報から各カードの利用料金の合計が計算されて、利用者の端末にＳＮＳ経由で返信される。特定のクレジットカードのサイトのみに処理を要求するときは、「〇〇カード」のようなカードを特定できる言葉をメッセージに含めておけばよい。

このとき、処理要求のメッセージを入力したＳＮＳ（第１のＳＮＳと呼ぶ）とは別のＳＮＳ（第２のＳＮＳと呼ぶ）経由で返信をもらうこともできる（図の破線の矢印で示す）。例えば、第１のＳＮＳで、「お父さんに１万円振り込んで！」というような要求を出した場合、振込元の銀行からの振込情報（振込金額、振込先口座報など）は、第１のＳＮＳではなく、第２のＳＮＳに返信され、利用者が第２のＳＮＳ上でこの振込を確認（承認）するようにもできる。２つのＳＮＳを使うことで、２重に本人確認がなされることになり、セキュリティが高まる。ＳＮＳを２つ利用していない利用者の場合は、通常のＥメールを返信先としてもよい。その場合は、Ｅメールのメーラが第２のＳＮＳとみなされる。

このようにすることで、本システムの利用者は、個々のサイトに個別にアクセスすることなく、いつも使っているＳＮＳ上で呟くことで、友人と会話する感覚で、欲しい情報を取得したり、必要な処理をサイトに要求したりすることができる。また、必要な場合は、特に、振込や商品購入など実際にお金を動かす要求に対しては、第１のＳＮＳでの本人認証に加え、第２のＳＮＳでの本人認証を加えることでセキュリティを高めることができる。

（第１の実施形態）
図２は、本発明の第１の実施形態に係るシステムの機能構成を示す図である。この図は、上記のサービスの基本イメージを実現するためのシステムの１つの形態を示したものである。以下の図において、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表すものとする。

第１の実施形態における本システムは、利用者端末１０と、第１のＳＮＳサーバ２０と、第２のＳＮＳサーバ３０と、中継サーバ４０と、利用者が普段使っているサイト（まとめてサイト５０と呼ぶ）とが、ネットワークで接続されて通信可能に構成される。ネットワークは、一般のインターネットであってよいが、一部にＶＰＮ（Virtual Private Network)のような専用ネットワークを含んでもよい。利用者端末１０は、ＳＮＳ及びサイトにログイン可能であれば、通常のパソコン、スマートフォン、タブレット端末などであってよい。

第１のＳＮＳサーバ２０は、一般的なＳＮＳサービスを行うためのサーバであり、メッセージ送信手段２１と、応答受信手段２５と、応答送信手段２６とを備える。ただし、ここでは本システムに直接関係のない機能を処理するための手段は省略している。

メッセージ送信手段２１は、利用者端末１０から入力された登録サイトへの処理要求を含むメッセージを受け付け、メッセージに含まれたハッシュタグなどで登録サイトへの処理要求か否かを判断し、登録サイトへの処理要求であれば、そのメッセージをそのまま中継サーバ４０に送信する。中継サーバ４０は、ＳＮＳと各サイトを中継する役目を持ったサーバである。中継サーバ４０に送信されたメッセージは、後述する処理を経て、目的のサイトに送信される。

応答受信手段２５は、送信した処理要求に対して、該当するサイトからの応答情報を中継サーバ４０経由で受信する。応答送信手段２６は、当該応答情報をメッセージを入力した利用者端末１０に返信する。

第２のＳＮＳサーバ３０も基本的には、第１のＳＮＳサーバ２０と同様の構成であり、メッセージ送信手段３１と、応答受信手段３５と、応答送信手段３６とを備えている。ただし、第２のＳＮＳサーバ３０を、サイトからの応答を受信して利用者端末１０に送信するだけの応答専用とすれば、メッセージ送信手段３１はなくともよい。

中継サーバ４０は、第１の実施形態における本システムの中核であり、メッセージ判別手段４１と、自然言語解析手段４２と、サイト処理要求生成手段４３と、キーワードテーブル４４と、利用者情報ＤＢ４５と、優先サイト判定手段４６と、サイト応答情報受信手段４７と、ＳＮＳ返信手段４８と、登録手段４９とを備える。中継サーバ４０は、単にＳＮＳと登録サイトを中継するだけでなく、利用者にとってサイトのコンシェルジュのような役目を果たす。以下、中継サーバ４０に備えられた手段を順に説明する。

メッセージ判別手段４１は、第１のＳＮＳから利用者のメッセージを受信し、利用者が登録した登録サイトに対する処理要求であるか否かを判別する。メッセージが登録サイトに対する処理要求でないと判別した場合は何もしないが、処理要求であると判別した場合は、自然言語解析手段４２に処理を移し、メッセージを解析させる。このメッセージは、ＳＮＳ上で呟くような普通の言葉、すなわち、自然言語の文章であってもよいし、単語を並べた文字列であってもよい。また、メッセージには、サイトに対する処理要求であることを区別するため、前述したような所定のハッシュタグを含めるようにしてもよい。また、ハッシュタグの代わりに、利用者固有の絵記号を用いてもよい。ここで、絵記号とは、ＬＩＮＥ（登録商標）のスタンプのように、ＩＤとなるコード（識別子）が割り当てられた絵（画像）を意味する。

自然言語解析手段４２は、メッセージが自然言語の文章の場合、形態素解析によってその文章を構文解析し、形態素（意味を持つ最小の単位）に分解する。メッセージが既に単語に分かれている場合は、登録サイトへの処理要求としては意味を持たない単語を除去する。なお、メッセージ中に感嘆詞、顔文字等が含まれる場合、その感嘆詞、顔文字等も登録サイトへの処理要求のキーワードとして採用してもよいし、処理要求としては意味を持たない語として扱ってもよい。

サイト処理要求生成手段４３は、自然言語解析手段４２で解析された形態素列又は単語の列を、キーワードテーブル４４及び利用者情報ＤＢ４５を参照して、処理要求を送信するサイトを決定し、そのサイトが処理可能な処理要求を生成する。例えば、「お父さんに１万円送って」という自然言語の文章のメッセージは、「お父さん」、「に」、「１万」、「円」、「送って」に分解され、「お父さん」、「に」は、利用者があらかじめ振込先として登録した「父親」の「口座番号」に変換され、「１万」と「円」は、「振込金額」と「１００００円」に、「送って」は、「振込命令」に変換され、利用者の口座のある銀行のネットバンキングサーバに送信される。

キーワードテーブル４４は、上記の形態素列又は単語の列を、登録サイトが処理可能なキーワード（処理命令とその処理のために必要な情報）に変換するためのテーブルである。言い換えると、各サイトが要求を処理できるように、上記のようなキーワードの変換ルールをサイト分野別又は個々のサイト別に定義したテーブルである。キーワードテーブル４４には、利用者が独自のキーワードを定義することができる。例えば、「お父さん」というキーワードに、父親の銀行口座の口座番号を対応付けたり、「家賃」というキーワードに、家賃の支払先の銀行口座の口座番号を対応付けたりすることができる。キーワードテーブル４４の具体例は、図３（ａ）で更に説明する。

利用者情報ＤＢ４５は、利用者ＩＤ、氏名、住所、連絡先などの登録個人情報、登録ＳＮＳ情報、及び登録サイト情報を格納したデータベースである。利用者情報ＤＢ４５のデータ構成について詳しくは図３（ｂ）で説明する。

優先サイト判定手段４６は、サイトの利用頻度を調べるため、利用者情報ＤＢ４５の登録サイトへの利用履歴情報を参照し、利用頻度の高い順に登録サイトの優先順位を判定し、その優先順位に従って、応答情報の表示順を指示する。すなわち、利用頻度の高いサイトほど、その応答情報が利用者端末１０の画面の上位に表示されるように、サイト応答情報受信手段４７に対して、サイト応答情報の優先順位付けを指示する。

サイト応答情報受信手段４７は、サイトからの応答情報を受信する。また、優先サイト判定手段４６の判定結果により、受信した応答情報の表示の優先順位付けをする。

ＳＮＳ返信手段４８は、サイトからの応答情報に応じて、及び/又は、利用者情報ＤＢ４５の登録情報に基づいて、返信先のＳＮＳを第１のＳＮＳサーバ２０にするか第２のＳＮＳサーバ３０にするかを決定し、その決定されたＳＮＳサーバにサイトからの応答情報を送信する。

登録手段４９は、利用者の登録個人情報、登録ＳＮＳ情報、及び登録サイト情報を利用者情報ＤＢ４５に登録する機能を有する。また、登録手段４９は、キーワードテーブル４４に、利用者独自のキーワードを登録する手段としても機能する。

図３（ａ）は、キーワードテーブル４４の具体例を示す図である。キーワードテーブル４４は、利用者ごとに登録され、ＳＮＳ上の呟きに使われるような普通の言葉を、登録サイトが処理可能なキーワードに変換するためのテーブルである。メッセージの中では同じキーワードであっても、登録サイトの分野又は個々の登録サイトによって異なる意味に変換されることがある。例えば、メッセージのキーワードが、「送って」、「送れ」などは、ネットバンキングでは「振込」に変換されるが、ネットモールでは「配達」に変換される。同様に、「お父さん」、「パパ」などは、ネットバンキングでは振込先の口座情報に変換されるが、ネットモールでは商品の配達先の住所に変換される。

図３（ｂ）は、利用者情報ＤＢ４５に格納されるデータ構成の具体例を示す図である。利用者情報ＤＢ４５には、図示するように、利用者ＩＤ、ログインＩＤ／パスワード、利用者の氏名・住所・連絡先（メールアドレスを含む）、利用者が普段使うクレジットカード、キャッシュカード、電子マネーカードなどの番号、登録ＳＮＳ情報、登録サイト情報が格納される。

登録ＳＮＳ情報には、ＳＮＳ名、ＳＮＳのＩＤ、返信先ＳＮＳのＩＤ（返信相手のＳＮＳ）、メッセージ識別記号が登録される。図の例では、ＳＮＳ１が受けたメッセージ（処理要求）の応答はＳＮＳ２に返信されるようにし、ＳＮＳ２が受けたメッセージはＳＮＳ１に返信されるようにし、ＳＮＳ３が受けたメッセージは、ＳＮＳ３自身に返信されるように登録されている。このようにすることで、複数のＳＮＳをサイトによって自由に組合せることができる。メッセージ識別記号とは、サイトへの処理要求を含んだメッセージと一般のメッセージとを区別するための記号である。メッセージ判別手段４１は、メッセージ識別記号を含んだメッセージをサイトへの処理要求とみなす。メッセージ識別記号は、ハッシュタグ、スタンプや顔文字のような絵記号、その他の任意の記号であってよい。

登録サイト情報には、サイト名、サイトＩＤ、サイトのログインＩＤとそのＰＷＤ（パスワード）、追加ＰＷＤ（サイトによっては、処理内容に応じて追加のＰＷＤなどを要求される場合があるため）、及びそのサイトを利用した利用履歴情報が格納される。利用履歴情報には、サイトの利用を開始した日時、利用を終了した日時などが含まれ、サイトの利用頻度を求め、サイトの優先順位を判定するために用いられる。

（第１の実施形態の処理フロー）
図４は、本発明の第１の実施形態に係るシステム間の連携フローを示す図である。以下の処理フロー図（フローチャート）においては、実線はシステム内の処理の流れを表し、一点鎖線はなんらかの応答を待つ状態を表し、点線はシステム間のデータの流れを表している。また、ここでは、利用者端末１０は「端末」、中継サーバ４０は「サーバ」、第１のＳＮＳサーバ２０は「ＳＮＳ１」、第２のＳＮＳサーバ３０は「ＳＮＳ２」と略すことにする。また、以下では、ＳＮＳ１が端末からのメッセージを受信した場合を想定しているが、ＳＮＳ２がメッセージを端末から受信した場合は、ＳＮＳ１とＳＮＳ２の処理が逆になるだけである。なお、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

まず、端末側の処理を説明する。端末は、ステップＳ００で、サイトに対するメッセージをＳＮＳ１に送信する。次に、ステップＳ０１で、その返信があるまで待機する。返信があった場合は、ステップＳ０２で、サイトからの返信情報（応答情報）を表示する。そして、ステップＳ０３で、その返信情報がＳＮＳ１からの返信かＳＮＳ２からの返信かを判断する。ＳＮＳ１からの返信の場合は、追加の処理はないため、そのまま処理を終了する。その返信がＳＮＳ２からの返信の場合は、ステップＳ０４で、その処理に利用者の承認（確認）が必要かどうかを判断し、承認が必要な場合は、利用者が返信情報を確認後、問題なければ承認を送信する（ステップＳ０５）。承認が必要な処理とは、振込や支払など金銭の移動を伴うような処理、ポイントの利用、支払方法の変更、登録情報の変更などがあり、通常はサイトによって処理内容に基づいて決定されるが、利用者が設定してもよい。

次に、サーバ側の処理を説明する。まず、サーバ側では、ステップＳ１０で、端末からのメッセージをＳＮＳ１経由で受信すると、ステップＳ１１で、登録サイトに対する要求か否かを判断する。登録されていないサイト（非登録サイト）に対する要求の場合は、ステップＳ１８で、非登録サイト処理を行う。非登録サイトに対しては、通常はメッセージの処理要求をサイトに送信しないようにするが、ログインが必要なく、かつ音声による検索をサポートするようなサイトでは、自然言語の処理要求を受け付ける場合もあるので、その場合は、処理要求をそのサイトに転送するようにしてもよい。ただし、その場合は、本システムのサポート範囲外となることがある。

ステップＳ１１で登録サイトに対する処理要求であると判断された場合は、ステップＳ１２に移り、そのメッセージを自然言語解析手段４２が解析する。解析が完了すると、登録サイト情報からログインＩＤとパスワードを読み出してサイトにログインし、サイト処理要求生成手段４３が生成した処理要求をサイトに送信し、その返信を待つ。なお、メッセージの解析が不能の場合は、その旨が端末側に返信される。

登録サイトから返信があった場合は、ステップＳ１３に進み、登録ＳＮＳ情報を参照して、ＳＮＳ１が返信先に指定されている場合は、返信情報をＳＮＳ１経由で端末に送信する（ステップＳ１９）。ＳＮＳ２が返信先に指定されている場合は、返信情報をＳＮＳ２経由で端末に送信する（ステップＳ１４）。

ＳＮＳ２経由の返信の場合は、ステップＳ１５で、利用者の承認が必要か否かを判断する。承認が不要な場合は処理を終了するが、承認が必要な場合はステップＳ１６に移り、利用者の承認をＳＮＳ２経由で取得し、ステップＳ１７で、承認情報をサイトに送信する。

次に、サイト側の処理を説明する。まず、サイト側では、ステップＳ３０で、サーバで生成された処理要求を受信する。次にステップＳ３１で、利用者がサイトの登録ユーザであるか否かを判断し、登録ユーザでない場合は登録を促す処理に移行する（ステップＳ３９）。登録が不要なサイトの場合は、ステップＳ３１、ステップＳ３９は不要である。

登録ユーザである場合、又は登録が不要な場合は、ステップＳ３２に進み、処理要求の内容に応じて、又は利用者の設定に応じて、返信をＳＮＳ１自身で行うか、別のＳＮＳ（ＳＮＳ２）から行う必要があるか否かを判断する。ＳＮＳ２で返信する必要がない場合は、ステップＳ３３で、ＳＮＳ１自身がサーバへ返信情報を送信するが、ＳＮＳ２から返信する必要がある場合は、ステップＳ３４で、サーバへＳＮＳ２経由で返信情報を利用者に送信するように要求する。そして、ステップＳ３５で、利用者からの承認があったかどうかを判断し、承認が得られた場合に、ステップＳ３６で、その承認を要する処理を実行する。以上のステップにより、全ての処理が終了する。なお、上記の説明では、承認プロセスをＳＮＳ２上で行うようにしたが、他の認証手段を併用するなどして、ＳＮＳ１上だけで承認プロセスを行うようにしてもよい。

（利用シーン）
図５は、実際の利用シーンにおける利用者端末１０の画面例（その１）を示す図である。この図では、ＳＮＳ１上で、今月のクレジットカードの利用金額と、銀行の口座残高とを同時に検索するような場面を示している。図の画面５００の例では、検索結果として、２種類のクレジットカードの利用残高と２つの銀行口座の口座残高とが表示されているが、クレジットカード会社によっては、利用限度額に対する残りの利用可能額も表示される。検索結果の表示順序は、サイトの種類ごとに、各サイトの利用頻度に応じて決定されてもよい。また、画面５００で、それぞれのサイトからの返信メッセージ欄の「明細」ボタンを押すと、詳しい明細が表示されるようにしてもよい。なお、図示はしていないが、各クレジットカードの利用金額の合計と各銀行口座残高の合計を計算して表示するようにしてもよい。

図６は、実際の利用シーンにおける利用者端末１０の画面例（その２）を示す図である。この図では、ＳＮＳ１上で、自分の銀行口座から家族へお祝いなどで送金する場面を示している。図の画面５１０の例では、Ａ銀行が指定されているのでＡ銀行からの送金であることが判断できるが、銀行が指定されていない場合で、かつ複数の銀行が登録されている場合は、どの銀行からの送金かを確認するためのメッセージが表示される。また、符号５１１で示すように、振込の処理要求の場合では、利用者本人を識別するための絵記号（スタンプなど）をメッセージに付加するようにし、本人確認を強化してもよい。画面５２０には、ＳＮＳ２上で、銀行からの返信メッセージが表示され、利用者がこの画面から「承認」ボタンを押すことで振込が実行される。なお、ＡＴＭのように、本システムで振込可能な金額に限度額を設けるようにしてもよい。

図７は、実際の利用シーンにおける利用者端末１０の画面例（その３）を示す図である。この図では、ＳＮＳ１上で、あるネットモールで特定のキーワードを含む商品を検索して購入する場面を示している。図の画面５３０の例では、商品のキーワードとネットモール名だけを並べて指定している。この検索の結果、画面５４０には、ネットモールからの返信が届き、「焼き菓子」に分類される商品の一覧が表示されている。利用者は、この画面５４０から「購入」ボタンを押すことで商品の購入ができる。

符号５４１で示す画像は、購入時の本人確認のための認証用絵記号である。このように、サイトによって認証用絵記号を変化させてもよい。あるいは、商品の購入金額によって、認証用絵記号を変更するようにしてもよい。なお、この例では、ネットモール名を指定しているが、他のネットモールも同時に検索したい場合は、そのネットモール名も指定するか、ネットモール名を省略する。ネットモール名を省略した場合は、すべてのネットモールの登録サイトが検索対象となるが、その場合は、利用頻度の高いサイトの情報が上位に表示されるようにしてもよい。

図８は、実際の利用シーンにおける利用者端末１０の画面例（その４）を示す図である。この図では、ＳＮＳ１上で、特定のカードのポイントを調べて、ポイントが貯まっていれば、商品と交換するような場面を示している。図の画面５５０の例では、「カードのポイントを使いたい」と呟くだけで、ＳＮＳ２上の画面５６０に現在のポイントと、そのポイントを使って交換可能な商品が表示されている。カードを複数登録していれば、カードごとに検索結果が表示される。利用者は、この画面５６０から「交換」ボタンを押すだけで、ポイントを商品やサービスと交換できる。なお、画面５６０でも符号５６１で示す別の認証用絵記号が用いられている。すなわち、処理要求ごとに、本人しか知らない異なる認証用絵記号を用いることでセキュリティを更に高めることができる。

（第２の実施形態）
図９は、本発明の第２の実施形態に係るシステムの機能構成を示す図である。第１の実施形態では、図２で示したように、中継サーバ４０をＳＮＳ側とサイト側の間に設け、中継サーバ４０が両者を中継する（コンシェルジュする）形態の構成としたが、第２の実施形態では、中継サーバ４０を設けずに、ＳＮＳ側とサイト側で中継サーバ４０の機能を分担する形態の構成をとる。図９は、その１つの構成例である。この構成では、図示するように、第１のＳＮＳサーバ２０に、図２の中継サーバ４０が備えていたような、メッセージ判別手段２１Ａ、自然言語解析手段２２、サイト処理要求生成手段２３、キーワードテーブル２４を備える。また、図示はしていないが、第２のＳＮＳサーバ３０も同様の構成としてもよい。この機能構成につき、以下では第１の実施形態と異なる部分についてのみ説明する。

サイト側は、ユーザ登録が必要なサイト５０Ａとユーザ登録が必要でないサイト５０Ｂとで少し事情が異なる。ユーザ登録が必要なサイトとして代表的なものは、銀行のネットバンキングサーバ５０Ａ１、クレジットカード会社のクレジットカードＷｅｂサーバ５０Ｂ２、ネットモールＷｅｂサーバ５０Ａ３、チケット予約サイト（図示せず）などがある。ユーザ登録が必要なサイト５０Ａは、通常、サイト内部に当該サイトの利用者情報（顧客情報）のＤＢを備えるが、本実施形態をサポートするサイト５０Ａは、利用者情報ＤＢ５５に、利用者ごとの登録ＳＮＳ情報を格納する。登録ＳＮＳ情報は、図３で示したものと同様である。

第１の実施形態との相違点としては、サイト側に登録ＳＮＳ情報を備える点、ＳＮＳ側に登録サイト情報と登録手段２７を備える点、及び第１のＳＮＳサーバ２０からの処理要求に対する応答情報に応じて、応答情報の返信先として、第１のＳＮＳサーバ２０又は第２のＳＮＳサーバ３０を切り替えるＳＮＳ返信手段（図示せず）をサイト側に備える点で、異なっている。また、図示は省略しているが、図２の優先サイト判定手段４６はＳＮＳ側に備える。

ユーザ登録を必要としないサイト５０Ｂは、情報提供のみを目的とする、検索サイト５０Ｂ１、観光案内サイト５０Ｂ２、地図情報サイト５０Ｂ３などがある（ただし、最近ではこのようなサイトでも登録してもらった利用者には付加サービスを提供するようになってきている）。ユーザ登録を必要としないサイト５０Ｂは、サイト内部に利用者情報（顧客情報）のＤＢを持たないので、サイト側に登録ＳＮＳ情報を持たせることができないので、ＳＮＳ側から登録ＳＮＳ情報をもらうか、処理要求を発したＳＮＳに常に返信情報を送信することになる。したがって、後者の場合は、返信先として、第１のＳＮＳと第２のＳＮＳを切り替えることはサポートされない。図９の一点鎖線は、後者の場合のサイト５０Ｂの情報の流れを示している。

図１０は、本発明の第２の実施形態に係るシステム間の連携フローを示す図である。以下では第１実施形態の図４のフロー図と異なる部分についてのみ説明する。図１０では、図４のステップと同じステップには同じ符号を付け、図４と対応するステップであるが処理が異なるステップには「Ａ」の符号を付けて区別している。また、以下では、図４と同様に、ＳＮＳ１が端末からのメッセージを受信した場合を想定している。

端末側の処理は、図４の場合と全く同じである。ＳＮＳ１側の処理では、ステップＳ１０Ａで、端末から直接、メッセージを受信する。また、ステップＳ１３Ａでは、サイトからの返信は自分自身に対するものと決まっているので、他のＳＮＳ（ここではＳＮＳ２）宛ての返信は処理しない。

ＳＮＳ２側の処理では、ステップＳ２０で、サイトからの返信があったか否かを判断し、サイトからの返信があれば、ステップＳ２１で、返信情報（応答情報）を端末に送信する。そして、ステップＳ２２で、利用者の承認が必要であるか否かを判断し、必要であれば、ステップＳ２３で、承認を取得し、ステップＳ２４で、承認情報をサイトに返信する。なお、ステップＳ２２〜Ｓ２４の処理は、図４のステップＳ１５〜Ｓ１７に対応する。

サイト側の処理では、ステップＳ３２で、ＳＮＳ１からメッセージを受信したが、返信はＳＮＳ２から必要があるか否かが判断される。ＳＮＳ２に返信する必要がなければ、ステップＳ３３でＳＮＳ１に返信する。ＳＮＳ２に返信する必要があれば、ステップＳ３４で、ＳＮＳ２に返信情報を送信する。以降の処理は図４の場合と同じである。

（第３の実施形態）
図１１は、本発明の第３の実施形態に係るシステムの機能構成を示す図である。
本実施形態は、自然言語解析手段５２、サイト処理要求生成手段５３、キーワードテーブル手段５４をサイト側に設けた形態である。この形態では、第１のＳＮＳサーバ２０′′のメッセージ判別手段２１Ａは、利用者端末１０から受信したメッセージが特定の登録サイトであるサイト５０Ａ′への処理要求であると判別したときは、そのメッセージをそのままサイト５０Ａ′に送信し、サイト５０Ａ′は、メッセージ受信手段５１により受信したメッセージを解析し、生成した処理要求を実行する。そして、ＳＮＳ返信手段５７が、処理要求実行手段５６が実行した処理結果を、処理要求に対する応答情報に応じて、第１のＳＮＳサーバ２０′′又は第２のＳＮＳサーバ３０に返信する。このようにすることで、ＳＮＳ側の処理負担が最小となるので既存のＳＮＳでも本サービスへの参加が容易になる。

以上説明した第１の実施形態と第２の実施形態を比較すると、第１の実施形態では中継サーバ４０を新たに構築する必要があるが、その分、ＳＮＳ側とサイト側の変更が少なくて済むので、既存のＳＮＳやサイトの多くをサービスの対象とすることができる。一方、第２の実施形態では、ＳＮＳ側とサイト側の変更が多くなるので、サービスの対象が限定される可能性があるが、有力なＳＮＳが各サイトと提携して、本実施形態の機能をサポートすれば、他のＳＮＳとの差別化が可能となる。また、第３の実施形態では、サイト側の処理負担は増えるものの、本実施形態の機能をサポートすれば、同業他社のサイトとの差別化に繋がる。

なお、上記の第１及び第２の実施形態における本システムの機能構成は、あくまで一例であり、１つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて１つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ(Solid State Drive)、ハードディスクなどの記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブルなどの必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。

（実施形態の効果）
以上の本システムの実施形態の効果をまとめると以下のようになる。まず第１に、個々のサイトにいちいちログインすることなく、利用者が普段使っているサイトをまとめて検索したり、場合によってはその一部だけを検索したり、検索の結果として取得した情報の結果しだいでは、引き続き、そのサイト又は別のサイトに対して、更なる処理を要求することができる。また、第１のＳＮＳと第２のＳＮＳで２重で本人確認することで、残高照会や利用明細などの情報取得だけでなく、振込や支払など更にセキュリティが求められる処理にも対応できる。

サイトに対する処理要求は、普段使い慣れたＳＮＳ上で、友人と会話するような感覚で普通の言葉で行うことが可能なので、検索キーワードで悩む必要がなくなる。もちろん、利用者独自の検索キーワードも登録することができる。また、様々なサイトの利用履歴をまとめて管理するので、利用頻度の高いサイトの情報を優先的に獲得したり、検索結果の上位に表示したりすることができる。また、ＳＮＳごとに、サイトからの応答情報の返信先を登録できるので、サイトによってＳＮＳの組合せを変えることができる。また、本システムの主な制御を中継サーバ側で行うか、ＳＮＳ側で行うか、サイト側で行うかの実施形態の選択も可能である。

また、このような付加価値の高いサービスを提供することで、ＳＮＳ側は利用者を更に増やすことができ、また、利用者の欲しい情報を送信する際に、その利用者に合った広告を付与することで、広告収入を増大させることもできる。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されないことはいうまでもない。上記実施形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。またその様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明として、中継サーバとそのシステムについて説明したが、本発明は、ＳＮＳから入力した登録サイトへの処理要求を制御する方法の発明、又はそのためのコンピュータ・プログラムの発明としても捉えることもできる。

１０ 利用者端末
２０，２０´、２０´´ 第１のＳＮＳサーバ
２１ メッセージ送信手段（第１のＳＮＳ側）
２１Ａ メッセージ判別手段（第１のＳＮＳ側）
２２ 自然言語解析手段（第１のＳＮＳ側）
２３ サイト処理要求生成手段（第１のＳＮＳ側）
２４ キーワードテーブル（第１のＳＮＳ側）
２５ 応答受信手段（第１のＳＮＳ側）
２６ 応答送信手段（第１のＳＮＳ側）
２７ 登録手段（第１のＳＮＳ側）
２８ 利用者情報ＤＢ（第１のＳＮＳ側）
３０ 第２のＳＮＳサーバ
３１ メッセージ送信手段（第２のＳＮＳ側）
３５ 応答受信手段（第２のＳＮＳ側）
３６ 応答送信手段（第２のＳＮＳ側）
４０ 中継サーバ
４１ メッセージ判別手段（中継サーバ側）
４２ 自然言語解析手段（中継サーバ側）
４３ サイト処理要求生成手段（中継サーバ側）
４４ キーワードテーブル（中継サーバ側）
４５ 利用者情報ＤＢ（中継サーバ側）
４６ 優先サイト判定手段（中継サーバ側）
４７ サイト応答情報受信手段（中継サーバ側）
４８ ＳＮＳ返信手段（中継サーバ側）
４９ 登録手段（中継サーバ側）
５０ サイト
５０Ａ、５０Ａ´ サイト（ユーザ登録要）
５０Ａ１ ネットバンキングサーバ
５０Ａ２ クレジットカードＷｅｂサーバ
５０Ａ３ ネットモールＷｅｂサーバ
５０Ｂ サイト（ユーザ登録不要）
５０Ｂ１ 検索サイト
５０Ｂ２ 観光案内サイト
５０Ｂ３ 地図情報サイト
５１ メッセージ受信手段（サイト側）
５２ 自然言語解析手段（サイト側）
５３ サイト処理要求生成手段（サイト側）
５４ キーワードテーブル（サイト側）
５５ 利用者情報ＤＢ（サイト側）
５６ 処理要求実行手段（サイト側）
５７ ＳＮＳ返信手段（サイト側）
５００〜５６０ 実際の利用シーンにおける画面

Claims (9)

1. 第１のＳＮＳサーバと第２のＳＮＳサーバとにネットワークで接続され、利用者からの登録サイトへの処理を中継する中継サーバであって、
   前記第１のＳＮＳサーバから前記利用者のメッセージを受信し、前記メッセージが前記登録サイトに対する処理要求であるか否かを判別するメッセージ判別手段と、
   前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイトに対する処理要求を生成するサイト処理要求生成手段と、
   前記処理要求を受信したサイトからの応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するＳＮＳ返信手段と、
   を備えることを特徴とする中継サーバ。
2. 前記メッセージが、前記利用者の普通に用いられる言葉からなる自然言語の文章である場合、前記メッセージの自然言語を解析する自然言語解析手段を更に備えることを特徴とする請求項１に記載の中継サーバ
3. 前記登録サイトへの利用履歴情報に基づいて、利用頻度に応じて前記登録サイトの優先順位を判定し、前記優先順位に従って、前記応答情報の表示順を指示する優先サイト判定手段を更に備えることを特徴とする請求項１又は２に記載の中継サーバ。
4. 前記第１のＳＮＳサーバが送信した処理要求に対する応答情報の返信先のＳＮＳの識別子を、前記利用者に登録させる登録手段を更に備えることを特徴とする請求項１から３までのいずれか１項に記載の中継サーバ。
5. 前記登録手段は、利用者固有のキーワードを前記キーワードテーブルに登録させ、前記サイト処理要求生成手段は、前記利用者固有のキーワードを前記キーワードテーブルに基づいて、前記登録サイトが処理可能なキーワードに変換することを特徴とする請求項４に記載の中継サーバ。
6. 利用者が登録した登録サイト並びに第１のＳＮＳサーバ及び第２のＳＮＳサーバがネットワークで接続されたシステムであって、
   前記第１のＳＮＳサーバは、
   前記利用者のメッセージを受信し、前記登録サイトに対する処理要求であるか否かを判別するメッセージ判別手段と、
   前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイトに対する処理要求を生成するサイト処理要求生成手段と、を備え、
   前記登録サイトは、
   前記処理要求に対する応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するＳＮＳ返信手段を備え、
   前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバは、
   前記返信された応答情報を前記利用者の端末に送信する応答送信手段を備える、
   ことを特徴とするシステム。
7. 利用者が登録した登録サイト並びに第１のＳＮＳサーバ及び第２のＳＮＳサーバがネットワークで接続されたシステムであって、
   前記第１のＳＮＳサーバは、
   前記利用者のメッセージを受信し、前記メッセージが前記登録サイトに対する処理要求であるか否かを判別し、処理要求と判別した場合、前記メッセージを前記登録サイトに送信するメッセージ判別手段と、
   を備え、
   前記登録サイトは、
   前記第１のＳＮＳサーバから前記判別されたメッセージを受信するメッセージ受信手段と、
   前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記メッセージから当該登録サイトの処理要求を生成するサイト処理要求生成手段と、
   前記処理要求に対する応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するＳＮＳ返信手段を備え、
   前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバは、
   前記返信された応答情報を前記利用者の端末に送信する応答送信手段を備える、
   ことを特徴とするシステム。
8. ＳＮＳから入力した登録サイトへの処理要求を制御するための方法であって、
   第１のＳＮＳサーバが、
   利用者のメッセージを受信するステップと、
   前記メッセージが、前記登録サイトに対する処理要求であるか否かを判別するステップと、
   を実行し、
   前記第１のＳＮＳサーバ又は第２のＳＮＳサーバに接続され、前記利用者からの前記登録サイトへの処理を中継する中継サーバ又は前記登録サイトが、
   前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイト又は未登録サイトに対する処理要求を生成するステップと、
   前記処理要求を受信したサイトからの応答情報に応じて、前記第１のＳＮＳサーバ又は前記第２のＳＮＳサーバに前記応答情報を返信するステップと、
   を実行することを特徴とする方法。
   
9. ＳＮＳから入力した登録サイトへの処理要求を制御するためのプログラムであって、
   第１のＳＮＳサーバから利用者のメッセージを受信するステップと、
   前記メッセージが、前記登録サイトに対する処理要求であるか否かを判別するステップと、
   前記登録サイトが処理可能なキーワードを格納したキーワードテーブルに基づいて、前記判別されたメッセージから前記登録サイトに対する処理要求を生成するステップと、
   前記処理要求を受信したサイトからの応答情報に応じて、前記第１のＳＮＳサーバ又は第２のＳＮＳサーバに前記応答情報を返信するステップと、
   をコンピュータに実行させることを特徴とするプログラム。

Images