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

Abstract

【課題】煩雑な操作を必要とすることなく、投稿コンテンツの適切な投稿先を決定する仕組みを提供することを目的とする。【解決手段】投稿対象の投稿コンテンツからキーワードを抽出するキーワード抽出手段と、投稿コンテンツの投稿ユーザが利用する複数のサービスそれぞれに登録されている複数の登録コンテンツの中から、キーワードを含む登録コンテンツを検索する検索手段と、サービス毎の検索結果に基づいて、複数のサービスの中から、投稿コンテンツの投稿先となるサービスを決定する投稿先決定手段とを有することによって課題を解決する。【選択図】図４

Description

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

従来、ＰＣ等の情報処理装置は、ネットワーク上のＷｅｂサーバに接続し、Ｗｅｂサーバにより提供されるコンテンツ又は機能を、自身が備えるＷｅｂブラウザ又は専用のアプリケーションを介して利用することができる。
最近では、スキャナやプリンタ等を備えたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）の中にも、上述したようなＷｅｂブラウザ又は専用のアプリケーションを備えているものがある。このようなＭＦＰは、Ｗｅｂサーバにより提供されるコンテンツを操作画面に表示し、ユーザからの各種指示を受け付ける。

ところで、情報処理装置を取り巻くネットワーク環境は、近年大きく変化している。例えば、多数のＷｅｂサービス提供者による様々なサービスがインターネットを介して提供されている。コミュニケーション手段を提供するソーシャル・ネットワーキング・サービス（ＳＮＳ）もその一つである。
ＳＮＳとは、社会的ネットワークをインターネット上で構築するサービスの事である。ＳＮＳの主目的は、人と人のコミュニケーション手段を提供することである。ユーザは、ＳＮＳを利用して、文書ファイル等の情報を他のユーザとの間で共有することができる。

従来から多くのユーザに利用されているコミュニケーションツールとして、電子メールが知られている。電子メールとＳＮＳとを比べると、電子メールにはいくつかの問題点が存在する。まず、電子メールは、手紙を電子的に置き換えたものであり、１対１の対話が基本である。このため、電子メールは、多くの人に同時にその内容を伝えることや（１対多）、多くの人が同時にコミュニケーションすること（多対多）が不得意である。
さらに電子メールにおいては、１対多の場合、送信先をユーザが自ら指定する必要があり、手間がかかる。一方、ＳＮＳでは、ユーザは、相手を意識することなく情報を発信することができる。

また、電子メールは、リアルタイム性に欠ける。ユーザは、送信した電子メールに対する返信がいつ届くかわからず、不便である。一方、ＳＮＳにおいては、ユーザは、相手がリアルタイムに情報を閲覧することができる状況かどうか容易に把握することができる。
さらに、電子メールは、他のアプリケーションとの融合も難しい。一方、ＳＮＳは、タスク管理、スケジュール管理、文書編集等のツールと簡単にコラボレーションすることが可能である。

ＳＮＳは以上のような利点を有しており、ＳＮＳをコミュニケーションツールとして利用する個人又は企業は、近年かなり増加している。ＳＮＳの普及により、インターネット上では様々なＳＮＳが続々と登場している。例えば、一般的なユーザの間のコミュニケーションを促進するＳＮＳとしては、Ｔｗｉｔｔｅｒ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）等が挙げられる。また、社員同士等限られたコミュニティにおけるコミュニケーションを促進するＳＮＳとしては、Ｃｈａｔｔｅｒ（登録商標）、Ｙａｍｍｅｒ（登録商標）等が挙げられる。
ユーザは、複数のＳＮＳサイトのアカウントを所有し、利用する場面に合わせて希望のＳＮＳサービスを選択することが可能となっている。１人のユーザが複数のＳＮＳサービスを利用する例としては、ある一般ユーザがＴｗｉｔｔｅｒ及びＦａｃｅｂｏｏｋ両方のアカウントを所有し、趣味毎に使い分けるような場合がある。

ＭＦＰが、ＳＮＳサービスと連携処理を行う例としては、複数のＳＮＳサービスを利用するユーザが、ＭＦＰを使用してイベントの開催案内をスキャンし、スキャン内容を投稿する例が挙げられる。この場合、複数のＳＮＳサービスを利用するユーザは、いずれのサービスにスキャン内容を投稿するか選択したい場合もある。
また、ある企業の社員が社内でのコミュニケーションにはＣｈａｔｔｅｒを利用し、連携先とのやり取りにはＹａｍｍｅｒを利用する場合もある。このような社員がＭＦＰを利用してファクスを送信する際に、送信ファクス文書の内容に応じて、適切な通知先のＳＮＳサービスを選択することを希望する場合もある。

これらの要望に対応すべく、情報処理装置においては、様々なＷｅｂサービスと連携してユーザのニーズに応じることのできるソリューションを提供することが重要となっている。
例えば、特許文献１には、様々なＷｅｂサービスが提供するネットワーク・インターフェースを専用の外部装置において共通の形式に変換する通信方法が開示されている。この方法を利用することにより、ユーザは複数のＷｅｂサービス間の違いを意識することなく、複数のＷｅｂサービスを利用することが可能となる。また、特許文献２には、文書ファイルの内容に従い、転送先を自動的に判断する方法が開示されている。

特開２０１２−６３９７２号公報 特開平７−２７３９２２号公報

しかしながら、特許文献１の方法では、ユーザは利用するＷｅｂサービスを選択する必要があり、手間がかかるという問題がある。また、例えば受信したファクス文書の内容に応じて自動的に異なるＷｅｂサービスに転送する等自動的に投稿先を選択する技術の提供が望まれている。
これに対し、特許文献２には、転送先を自動的に判断する方法が開示されている。しかしながら、特許文献２の方法では、受信者の氏名等の情報を予め登録し、登録した情報を適宜更新する必要があり、手間がかかるという問題がある。

本発明はこのような問題点に鑑みなされたもので、煩雑な操作を必要とすることなく、投稿コンテンツの適切な投稿先を決定する仕組みを提供することを目的とする。

そこで、本発明は、情報処理装置であって、投稿対象の投稿コンテンツからキーワードを抽出するキーワード抽出手段と、前記投稿コンテンツの投稿ユーザが利用する複数のサービスそれぞれに登録されている複数の登録コンテンツの中から、前記キーワードを含む登録コンテンツを検索する検索手段と、前記サービス毎の検索結果に基づいて、前記複数のサービスの中から、前記投稿コンテンツの投稿先となるサービスを決定する投稿先決定手段と有することを特徴とする。

本発明によれば、煩雑な操作を必要とすることなく、投稿コンテンツの適切な投稿先を決定する仕組みを提供することができる。

情報処理システムを示す図である。 ＭＦＰを示す図である。 Ｗｅｂサーバ装置を示す図である。 ＭＦＰを示す図である。 ログイン画面の一例を示す図である。 メイン画面の一例を示す図である。 投稿画面の一例を示す図である。 投稿処理を示すフローチャートである。 検索処理を示すフローチャートである。 検索結果管理テーブルの一例を示す図である。 投稿先判断処理を示すフローチャートである。 第２の実施形態にかかるＭＦＰを示す図である。

以下、本発明の実施形態について図面に基づいて説明する。

（第１実施形態：スキャン）
図１は、第１実施形態にかかる情報処理システムの全体構成を示す図である。情報処理システムは、情報処理装置としてのＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）１００と、Ｗｅｂサーバ装置１０１ａ，１０１ｂとを備えている。ＭＦＰ１００と、Ｗｅｂサーバ装置１０１ａ，１０１ｂとは、それぞれ互いに通信可能にＬＡＮ１１０に接続されている。ＭＦＰ１００は、さらに公衆回線１２０に接続し、ファクスの送受信を行う。
Ｗｅｂサーバ装置１０１ａ，１０１ｂは、ＳＮＳを提供するＳＮＳサーバの一例である。図１においては、ＭＦＰ１００が連携するＷｅｂサーバ装置として、２つのＷｅｂサーバ装置１０１ａ，１０１ｂを示す。しかし、ＭＦＰ１００が連携するＷｅｂサーバ装置の数は、実施の形態に限定されるものではない。以下、「Ｗｅｂサーバ装置１０１ａ，１０１ｂ」を、適宜単に「Ｗｅｂサーバ装置１０１」と称することとする。

第１実施形態にかかる情報処理システムは、ＭＦＰ１００のスキャン処理により文書データを得る。そして、情報処理システムは、文書データの内容と複数のＷｅｂサービスそれぞれに登録されている情報とに応じて、複数のＷｅｂサービスのうち適切なＷｅｂサービスを決定する。ここで、Ｗｅｂサービスは、Ｗｅｂサーバ装置１０１により提供されるサービスであり、本実施の形態においては、ＳＮＳサービスである。情報処理システムは、決定したＷｅｂサービスを提供するＷｅｂサーバ装置１０１に対し、文書データを転送し、又はスキャン操作の旨を通知する。
なお、以下、ＳＮＳサービス提供サーバとしてのＷｅｂサーバ装置１０１へのコンテンツの転送及び情報の通知を「投稿」と称することとする。また、投稿対象となるコンテンツを投稿コンテンツと称する。投稿コンテンツとしては、文書データの他、画像データ、ユーザにより入力されたコメント等がある。
本実施形態においては、スキャン処理を例に、情報処理システムが投稿コンテンツの投稿先を決定する処理について説明する。情報処理システムは、ＭＦＰ１００におけるファクス送信、プリント等の対象となるコンテンツを投稿コンテンツとして、同様の処理を行うこともできる。

＜ＭＦＰの構成＞
図２は、ＭＦＰ１００の構成を示す図である。ＣＰＵ２０１を含む制御部２００は、ＭＦＰ１００全体の動作を制御する。ＣＰＵ２０１は、ＲＯＭ２０２に記憶された制御プログラムを読み出して読取制御や送信制御等の各種制御を行う。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。
ＨＤＤ２０４は、画像データや各種プログラム、各種情報テーブル等を記憶する。操作部Ｉ／Ｆ２０５は、操作部２０９と制御部２００とを接続する。操作部２０９は、タッチパネル機能を有する液晶表示部やキーボード等を有している。モデム２１３は、公衆回線１２０及びシステムバス２１２に接続し、公衆回線１２０により接続された外部のファクス端末（不図示）とファクス送受信の通信を行う。
後述するＭＦＰ１００の機能や処理は、ＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４に格納されている制御プログラムを読み出し、この制御プログラムを実行することにより実現されるものである。

プリンタＩ／Ｆ２０６は、プリンタ２１０と制御部２００とを接続する。プリンタ２１０で印刷すべき画像データは、制御部２００からプリンタＩ／Ｆ２０６を介してプリンタ２１０に転送され、プリンタ２１０において記録媒体上に印刷される。スキャナＩ／Ｆ２０７は、スキャナ２１１と制御部２００とを接続する。スキャナ２１１は、原稿上の画像を読み取って画像データを生成する。スキャナ２１１は、生成した画像データをスキャナＩ／Ｆ２０７を介して制御部２００に送信する。
ネットワークＩ／Ｆ２０８は、制御部２００（ＭＦＰ１００）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ２０８は、ＬＡＮ１１０上の外部装置（例えば、Ｗｅｂサーバ装置１０１）に画像データや情報を送信する処理と、ＬＡＮ１１０上の外部装置から各種情報を受信する処理を行う。

＜Ｗｅｂサーバ装置の構成＞
図３は、Ｗｅｂサーバ装置１０１の構成を示す図である。ＣＰＵ３０１を含む制御部３００は、Ｗｅｂサーバ装置１０１全体の動作を制御する。ＣＰＵ３０１は、ＲＯＭ３０２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３０３は、ＣＰＵ３０１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３０４は、画像データや各種プログラム、後述する各種情報等を記憶する。
後述するＷｅｂサーバ装置１０１の機能や処理は、ＣＰＵ３０１がＲＯＭ３０２又はＨＤＤ３０４に格納されている制御プログラムを読み出し、この制御ログラムを実行することにより実現されるものである。
ネットワークＩ／Ｆ３０５は、制御部３００（Ｗｅｂサーバ装置１０１）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ３０５は、ＬＡＮ１１０上の他の装置との間で各種情報を送受信する。

＜ＭＦＰ１００のソフトウェア構成＞
図４は、ＭＦＰ１００の機能構成を示す図である。ＭＦＰ１００は、アプリケーション４００を搭載している。より具体的には、アプリケーション４００は、ＭＦＰ１００のＯＳ上で動作する。
ただし、アプリケーション４００は、直接ＭＦＰ１００のＯＳ上で動作するのではなく、ＭＦＰ１００内の仮想マシン上で動作するアプリケーションであってもよい。アプリケーション４００は、例えば、Ｊａｖａ（登録商標）の仮想マシン上で動作するアプリケーションであってもよい。

ＵＩ制御部４０１は、操作部２０９に操作画面を表示するための制御処理を行うソフトウェアモジュールである。ＵＩ制御部４０１は、例えば操作部２０９から受け取ったユーザの操作に応じて画面を遷移させる。ＵＩ制御部４０１はまた、他のモジュールに操作を依頼する。画像受信部４０２は、ＨＤＤ２０４に格納されている画像データや、スキャナＩ／Ｆ２０８から受け取った画像データ等を取得するソフトウェアモジュールである。
判断通信モジュール４１０は、Ｗｅｂサーバ装置１０１と通信を行うソフトウェアモジュールである。判断通信モジュール４１０はまた、画像受信部４０２から画像データを受け取り、受け取った画像データの内容に従って投稿先のＷｅｂサービスを決定する。

文字認識部４１１は、画像受信部４０２が受信した、投稿コンテンツとしての画像データからテキスト情報を抽出するソフトウェアモジュールである。文字認識部４１１による文字認識処理については、図８を参照しつつ後述する。キーワード抽出部４１２は、文字認識部４１１により抽出されたテキスト情報からキーワードを抽出するソフトウェアモジュールである。なお、キーワードは、投稿コンテンツとしての画像データの投稿先を決定するために利用される。キーワード抽出部４１２によるキーワード抽出処理については、図８を参照しつつ後述する。
検索部４１３は、キーワード抽出部４１２で抽出したキーワードを含む登録コンテンツを検索するソフトウェアモジュールである。ここで、登録コンテンツとは、Ｗｅｂサーバ装置１０１に投稿され、登録されているコンテンツである。検索部４１３による検索処理については、図９を参照しつつ後述する。
投稿先判断部４１４は、検索部４１３により得られた検索結果に基づいて、投稿先の決定等、投稿先判断にかかる処理を行うソフトウェアモジュールである。投稿先判断部４１４による投稿先判断処理については、図１１を参照しつつ後述する。

通信部４１５は、Ｗｅｂサーバ装置１０１と通信を行うソフトウェアモジュールである。通信部４１５は、他のソフトウェアモジュールからＷｅｂサーバ装置１０１との通信依頼を受け取る。通信部４１５は、通信依頼を受け取ると、Ｗｅｂサーバ装置１０１に通信用のリクエストメッセージを生成し、生成したリクエストメッセージを送信する。そして、通信部４１５は、Ｗｅｂサーバ装置１０１からリクエストメッセージに対するレスポンスメッセージを受信し、受信したメッセージを解析して依頼元のソフトウェアモジュールに通知する。
なお、通信部４１５は、通信用のリクエストメッセージを生成する際に必要となる認可情報は、ユーザ情報管理部４１７から取得する。通信部４１５が生成する通信用のリクエストメッセージは、Ｗｅｂサービスによりフォーマットが異なることがある。この場合には、通信部４１５は、適宜フォーマットの変換を行う。

検索結果管理部４１６は、検索部４１３で取得した検索結果を格納及び管理するソフトウェアモジュールである。検索結果は、ユーザ毎、ＳＮＳサービス毎に格納されている。検索結果管理部４１６の管理対象の情報については、図１０を参照しつつ後述する。
ユーザ情報管理部４１７は、ユーザがアプリケーションにログインする際の情報、ユーザが利用するＷｅｂサーバ装置１０１の情報、及びＷｅｂサーバ装置１０１と通信するための認可情報を格納及び管理するソフトウェアモジュールである。本実施形態にかかる情報処理システムにおいて利用される認可情報は、認可プロトコルＯＡｕｔｈに従った文字列形式のアクセストークンとする。

＜アプリケーションの画面構成＞
図５は、アプリケーション４００のログイン画面の例を示す図である。ログイン画面は、ＭＦＰ１００のＣＰＵ２０１が制御プログラムを実行することにより、操作部２０９に表示される。後述するメイン画面及び投稿画面も、同様に、ＭＦＰ１００のＣＰＵ２０１が制御プログラムを実行することにより、操作部２０９に表示される。ログイン画面５００は、アプリケーション４００が起動された時に、ＵＩ制御部４０１により操作部２０９の液晶画面に表示される。
５０１は、アプリケーション終了ボタンである。ユーザがアプリケーション終了ボタン５０１を押下すると、アプリケーション４００は終了する。５０２は、ユーザ名入力エリアであって、ユーザがユーザ名を入力するエリアである。５０３は、パスワード入力エリアであって、ユーザがパスワードを入力するエリアである。入力されたパスワードは自動的に内容が判別できない文字（例えば「＊」マーク）に変換される。

５０４は、ログインボタンである。ユーザがログインボタン５０４を押下すると、ＵＩ制御部４０１はその押下イベントを受け付ける。ＵＩ制御部４０１は、ユーザ名入力エリア５０２及びパスワード入力エリア５０３内の内容に基づいて、ユーザ情報管理部４１７にユーザの確認を依頼する。ユーザ情報管理部４１７により、ユーザがアプリケーション４００を利用できると判断された場合、操作部２０９の表示は、ログイン画面５００からメイン画面（サービス選択画面）６００に遷移する。
５０５は、メッセージ表示エリアであって、ユーザに対する指示メッセージ、入力されたユーザ名及びパスワードの確認結果を示すメッセージを表示するエリアである。ログインボタン５０４が押下され、入力されたユーザ名及びパスワードが有効ではない場合、表示エリア５０５には、有効でない旨を表すメッセージが表示される。

図６は、アプリケーション４００のメイン画面を示す図である。図６に示すメイン画面６００は、ユーザによりログイン画面５００のログインボタン５０４が押下され、且つユーザ名入力エリア５０２及びパスワード入力エリア５０３に有効な値が入力された際に表示される。
６０１は、アプリケーション終了ボタンであって、ログイン画面５００のアプリケーション終了ボタン５０１と同様の機能を有する。６１０は、ユーザ情報表示エリアであって、ログインしたユーザの情報（ユーザ名、Ｅメールアドレス等）を表示するエリアである。６１１，６１２は、それぞれユーザ名及びＥメールアドレスを表示するエリアである。表示エリア６１１，６１２に表示されるユーザ情報は、ＵＩ制御部４０１がメイン画面６００を生成する際、ログイン画面５００で入力されたユーザ名に基づいて、ユーザ情報管理部４１７から取得した情報である。

６２０は、ログインしたユーザが利用するＷｅｂサービスのリスト（ＳＮＳサイトリスト）を表示するエリアである。６２１，６２２，６２３は、ログインしたユーザが利用するＷｅｂサービス（ＳＮＳサイト）の名称（ＳＮＳサイト名）及びＳＮＳサイトの利用状況を表示するエリアである。ＳＮＳサイトの利用状況は、ユーザ情報管理部４１７に格納されているＳＮＳサイトの認可情報の有効性を示すものである。
ＵＩ制御部４０１は、アプリケーションのメイン画面６００を生成する際、ユーザ情報管理部４１７からユーザが利用するＳＮＳサイトの情報及び認可情報を取得する。そして、ＵＩ制御部４０１は、通信部４１５に認可情報の有効性の確認依頼を行う。通信部４１５は、確認依頼を受け取り、認可情報を確認するリクエストメッセージを生成する。そして、通信部４１５は、リクエストメッセージをＷｅｂサーバ装置１０１に送信する。

通信部４１５は、Ｗｅｂサーバ装置１０１からレスポンスメッセージを受信し、受信したメッセージ内容に従い認可情報の有効性を判断し、判断結果をＵＩ制御部４０１に通知する。ＵＩ制御部４０１は、判断結果に従い、認可情報が有効の場合、「利用可能」のラベルを表示し、無効の場合には、「認証する」のボタンを表示する。なお、ＵＩ制御部４０１は、判断結果を表示するとともに、ユーザ情報管理部４１７に登録する。
ユーザが「認証する」ボタンを押下すると、ＵＩ制御部４０１は、対応する押下イベントを受け付け、通信部４１５に認可情報を取得する処理を依頼する。認可情報を取得する処理は、ＯＡｕｔｈの認可情報取得処理に従うものとする。

６３０は、操作リストエリアであって、アプリケーション４００が利用可能なＭＦＰ１００の機能を表示するエリアである。６３１は、スキャンボタンである。ユーザがスキャンボタン６３１を押下すると、ＵＩ制御部４０１は、対応する押下イベントを受け付ける。そして、ＵＩ制御部４０１は、操作部２０９の表示をＭＦＰ１００のスキャン画面（不図示）に遷移させる。ユーザは、ＭＦＰ１００のスキャン画面を参照し、ＭＦＰ１００にスキャンを指示することができる。ＭＦＰ１００は、スキャン処理において、原稿上の画像を読み取り画像データを生成する。スキャン処理が終了すると、ＵＩ制御部４０１は、終了イベントを受け付け、投稿画面（図７）を表示する。
６３２は、ファクス送信ボタンである。６３３は、プリントボタンである。ユーザがファクス送信ボタン６３２及びプリントボタン６３３を押下すると、スキャンボタン６３１を押下した場合の処理と同じように、操作部２０９の表示は、ＭＦＰ１００のファクス送信画面（不図示）又はプリント画面（不図示）に遷移する。そして、ファクス送信及びプリント処理が終了すると、投稿画面が表示される。

図７は、アプリケーション４００の投稿画面を示す図である。図７に示す投稿画面７００は、スキャン、ファクス送信又はプリント処理が終了した際に表示される。７０１は、アプリケーション終了ボタンであって、ログイン画面５００のアプリケーション終了ボタン５０１と同様の機能を有する。
７１０は、投稿エリアであって、ＳＮＳサイトに投稿する際のコメント及びファイルの添付を入力するエリアである。投稿エリアに入力されるコメント及びファイルは、投稿コンテンツの一例である。７１１は、コメント入力エリアであって、ＳＮＳサイトに投稿する際のコメントを入力するエリアである。７１２は、添付ファイル選択チェックボックスである。ユーザは、添付ファイル選択チェックボックス７１２において、スキャン、ファクス送信又はプリント処理の対象となる画像データを添付ファイルとしてＳＮＳサイトに投稿するか否かを選択することができる。

７２０は、投稿先判断結果表示エリアであって、投稿先の判断結果を表示するエリアである。ユーザによるコメント入力エリア７１１へのコメント入力が完了すると、ＵＩ制御部４０１は、入力終了イベントを受け取る。そして、ＵＩ制御部４０１は、入力終了イベントに基づいて、投稿先判断部４１４に投稿先判断処理（図８参照）を依頼する。投稿先判断処理において、投稿先として決定されたＳＮＳサイトのチェックボックス７２１には、チェックが表示される。
なお、投稿先判断結果により、複数の投稿先のチェックボックスがチェックされる場合と、複数の投稿先いずれのチェックボックスもチェックされない場合とがある。ユーザは、チェックボックスを確認し、投稿先の変更を希望する場合には、チェックボックス７２１，７２２，７２３のチェックを変更することにより、投稿先の変更をＭＦＰ１００に指示することができる。

７３０は、投稿ボタンである。ユーザが投稿ボタン７３０を押下すると、ＵＩ制御部４０１がその押下イベントを受け取り、通信部４１５に投稿処理を依頼する。通信部４１５は、投稿依頼を受け取る。通信部４１５は、投稿依頼に従い、７１２のチェックボックスがチェックされている場合、コメント入力エリア７１１に入力されているコメント及び添付ファイルを投稿先判断結果表示エリア７２０にチェックされている投稿先に投稿する。通信部４１５が投稿処理を行う場合や、通信部４１５による投稿処理が終了した場合には、ＵＩ制御部４０１は、その旨をメッセージボックスとして投稿画面７００上に表示する（不図示）。
また、投稿処理が終了した際に表示されたメッセージボックス上の確認ボタンがユーザにより押下されると、ＵＩ制御部４０１は、対応する押下イベントを受け取る。そして、ＵＩ制御部４０１は、押下イベントに従い、操作部２０９の表示をアプリケーション４００のメイン画面６００に遷移させる。
７３１は、投稿しないボタンである。ユーザが投稿しないボタン７３１を押下すると、ＵＩ制御部４０１は、対応する押下イベントを受け取る。そして、ＵＩ制御部４０１は、押下イベントに従い、操作部２０９の表示をアプリケーション４００のメイン画面６００に遷移させる。

＜投稿処理＞
図８は、ＭＦＰ１００による投稿処理を示すフローチャートである。ステップＳ８０１では、文字認識部４１１は、画像受信部４０２を介して受信した、投稿コンテンツとしての画像データからテキスト情報を抽出する。文字認識部４１１は、テキスト情報を抽出する処理において、ＯＣＲ（文字認識）処理を利用する。なお、本実施形態においては、ＯＣＲの認識精度が機械で作成した一般的なフォントの文字を問題なく認識できる程度であるものとする。
ステップＳ８０２では、キーワード抽出部４１２は、ステップＳ８０１で抽出したテキスト情報及びコメント入力エリア７１１（図７）に入力されたテキスト情報から投稿先を判断するためのキーワードを抽出する（キーワード抽出処理）。なお、コメント入力エリア７１１に入力されたテキスト情報は、投稿コメントの一例である。すなわち、ＣＰＵ２０１は、キーワード処理においては、投稿コメントを含む投稿コンテンツからキーワードを抽出する。

キーワード抽出部４１２は、キーワードの抽出処理において、名詞辞書、文法辞書等の辞書を利用してテキスト情報から名詞の意味の単語を抽出する一般的な手法を用いることができる。キーワード抽出部４１２は、さらに抽出した各キーワードに対し、所定のルールに従い、優先度を意味する重み情報を付与する。
重み情報を付与する処理において、キーワード抽出部４１２は、例えばコメント入力エリア７１１に入力されたテキスト情報から抽出したキーワードに対し、他のキーワードに比べて高い第１重み値を付与する。コメント入力エリア７１１に入力された内容は、ユーザが積極的に他人に伝えたい内容である可能性が高いためである。

また、コメント入力エリア７１１に入力されたテキスト情報中から「＃」タグ（ハッシュタグ）が付いているキーワードが抽出されたとする。この場合には、キーワード抽出部４１２は、第２重み値を付与する。ここで、第２重み値は、第１重み値よりも大きい値である。例えば、図７に示すコメント入力エリア７１１に入力されている「ＡＡ」（書籍名）には、ハッシュタグが付与されている。
キーワード抽出部４１２はまた、ステップＳ８０１で抽出した投稿コンテンツとしての画像データのテキスト情報から抽出したキーワードに対しては、キーワードが出現する場所に応じて異なる重みを付与する。例えば、タイトル、宛名及び署名部分から抽出したキーワードに対し、他の部分から抽出したキーワードに比べてやや大きい第３重み値を付与する。ただし、第３重み値は、第１重み値に比べて小さい値とする。

キーワード抽出部４１２はさらに、タイトル、宛名、署名以外の本文部分から抽出したキーワードの出現頻度により重みを付与する。キーワード抽出部４１２は、以下に示す降順に出現頻度に対して、その降順に従ってより小さくなるような重み値を付与する。降順は、例えば、コメント入力エリア７１１に入力されたハッシュタグ付きキーワード、その他入力されたキーワード、画像データのタイトル・宛名・署名中のキーワード及び本文中のキーワードの順とする。
キーワード抽出部４１２は、重み付与が完了すると、重みが付与されたキーワードの中の重みの高い上位５位のキーワードをＳＮＳサイトに検索する候補の検索キーワードとして選択する。そして、キーワード抽出部４１２は、検索キーワードを次のステップＳ８０３に渡す。

ステップＳ８０３では、検索部４１３は、ステップＳ８０２において抽出した検索キーワードにより、投稿コンテンツの投稿を指示する投稿ユーザが利用する各ＳＮＳサイトに対する検索処理を行う。検索処理の詳細については、図９を参照しつつ後述する。ステップＳ８０４では、投稿先判断部４１４は、ステップＳ８０３において得られた検索結果から投稿先を判断する投稿先判断処理を行う。投稿先判断処理の詳細は図１１の説明で後述する。

図９は、検索処理を示すフローチャートである。ステップＳ９０１では、検索部４１３は、ステップＳ８０２で抽出した各キーワードの検索履歴情報の確認を検索結果管理部４１６に依頼する。検索結果管理部４１６は、依頼を受け付けると、検索履歴情報を検索部４１３に提供する。検索部４１３は、受け取った検索履歴情報から処理対象とする検索キーワードの最終更新日時を特定する。なお、検索結果管理部４１６は、ユーザ毎、ＳＮＳサイト毎及び検索対象分類毎にキーワードの出現・更新日時及び最後検索日時を管理している。
ステップＳ９０２では、検索部４１３は、ステップＳ９０１で取得した各キーワードの最後検索日時に基づいて、ＳＮＳサイトでキーワードを検索する際の検索範囲を特定する。より具体的には、最後検索日時が、Ｓ９０２を実施している時点（検索タイミング）から過去１ヶ月以内の日時であるとする。この場合、検索部４１３は、最後検索日時から検索タイミングまでの間を更新日時とする登録コンテンツの範囲を検索範囲として特定する。

また、最後検索日時が検索タイミングから過去１ヶ月よりも過去の日時であるとする。この場合、検索部４１３は、検索タイミングから過去１ヶ月の間を更新日時とする登録コンテンツの範囲を検索範囲として特定する。また、検索キーワードが検索結果管理部４１６に存在しない場合にも、検索部４１３は、検索タイミングから過去１ヶ月の間を更新日時とする登録コンテンツの範囲を検索範囲として特定する。
このように、ステップＳ９０２において、検索部４１３は、登録コンテンツの更新日時、最後検索日時及び検索タイミングに基づいて検索範囲を決定する。すなわち、ステップＳ９０２は、検索範囲決定処理の一例である。
なお、本実施形態にかかる検索部４１３には、１ヶ月の検索範囲の最大値が予め設定されているものとする。ただし、検索範囲の最大値は、任意の値である。検索範囲を縮小した場合には、検索処理のパフォーマンスが向上する。

主流なＳＮＳサイトが提供する検索ＡＰＩ（アプリケーション・プログラミング・インターフェース）は、日時範囲を指定できるオプション機能を有している。したがって、検索部４１３は、このオプション機能を利用することにより日時範囲を指定した検索を依頼することができる。
例えば、ＦａｃｅｂｏｏｋのＧｒａｐｈ ＡＰＩを利用して検索を行う場合、検索部４１３は、ＨＴＴＰメッセージのクエリーの「ｓｉｎｃｅ」、「ｕｎｔｉｌ」パラメータに値を設定することにより検索範囲を指定できる。
投稿先のＳＮＳサイトが提供するＡＰＩにおいて、検索範囲を指定できない場合には、検索部４１３は、検索範囲を指定せず、検索を依頼する。そして、検索部４１３は、検索結果を受け取り、受け取った検索結果を解析することにより、検索範囲内の検索結果を取得する。

ステップＳ９０３では、検索部４１３は、ユーザ情報管理部４１７から検索対象のＳＮＳサイト（検索ＳＮＳサイト）を特定する。なお、ユーザ情報管理部４１７には、メイン画面６００（図６）を生成する処理において、ＵＩ制御部４０１により、利用状況の確認結果が格納されている。このため、検索部４１３は、ユーザ情報管理部４１７を参照することにより、投稿ユーザが利用可能なＳＮＳサイトだけを検索ＳＮＳとして特定することができる。
ステップＳ９０４では、検索部４１３は、通信部４１５に対し検索依頼を送る（検索処理）。検索依頼には、ステップＳ９０３において特定された検索ＳＮＳサイト、ステップＳ８０２において抽出された各キーワード及びＳ９０２で特定された検索範囲が含まれている。通信部４１５が検索の依頼を受け取り、依頼に基づいて検索用のＨＴＴＰメッセージを生成する。そして、通信部４１５は、Ｗｅｂサーバ装置１０１に、検索用のＨＴＴＰメッセージを送信する。

検索用のＨＴＴＰメッセージを受信したＷｅｂサーバ装置１０１は、自装置に投稿され、既に登録されている登録コンテンツを検索キーワード及び検索範囲に基づいて検索する。そして、Ｗｅｂサーバ装置１０１は、検索キーワードに一致する登録コンテンツを検出する。そして、Ｗｅｂサーバ装置１０１は、検索結果を示す返信メッセージをＭＦＰ１００に送信する。
ＭＦＰ１００の通信部４１５は、Ｗｅｂサーバ装置１０１から返信メッセージを受信する。通信部４１５は、返信メッセージの内容から検索結果を抽出し、検索部４１３に通知する。ただし、ＳＮＳサイトが提供するＡＰＩにおいて、１回の検索ですべての検索結果を得られない場合がある。この場合には、通信部４１５は、ＳＮＳサイトのＡＰＩに従い、検索用ＨＴＴＰメッセージを複数回生成し、各検索用ＨＴＴＰメッセージをＷｅｂサーバ装置１０１に送信することとする。この場合には、通信部４１５は、Ｗｅｂサーバ装置１０１から複数回に渡り返信メッセージを受信する。そして、通信部４１５は、複数の返信メッセージの内容に基づいて、１つの検索結果を生成し、これを検索部４１３に通知する。

ステップＳ９０５では、検索部４１３は、ステップＳ９０３において得られた検索結果を項目毎に分類する。分類する項目は、投稿ユーザのプロファイル、投稿ユーザの投稿・コメント（それらに対するコメントも含む）で使用されているハッシュタグ及び自分の投稿・コメント（それらに対するコメントも含む）の本文の３つの項目である。
ステップＳ９０６では、検索部４１３は、検索結果管理部４１６にステップＳ９０５で分類した検索結果を格納する処理を依頼する。検索結果管理部４１６は、格納の依頼を受け取り、検索結果管理テーブルのうち、対象ユーザの検索キーワードの各ＳＮＳサイトの結果分類項目の日時欄（図１０の１００６の列）に検索結果となるレコードの更新日時を追記する。なお、検索結果管理部４１６に、対象となるレコードの行が存在しない場合には、検索結果管理部４１６は、検索結果管理テーブルにレコードの行を新たに生成する。そして、検索結果管理部４１６は、新たに生成したレコードの日時欄（図１０の１００６の列）に対象とするＳＮＳサイトに対応付けて検索結果の更新日時を検索履歴として格納する（検索履歴管理処理）。検索結果管理部４１６はまた、検索結果管理テーブルの最終検索日時欄（図１０の１００４の列）に、検索部４１３による検索日時を格納する。

ステップＳ９０７では、検索部４１３は、ステップＳ９０３で特定した検索対象ＳＮＳサイトの中にまだ検索されていないＳＮＳサイトが存在するかどうかを確認する。まだ検索されてないＳＮＳサイトが存在する場合、検索部４１３は、まだ検索されてないＳＮＳサイトを検索対象として、ステップＳ９０４に戻る。ステップＳ９０３で特定したすべての検索対象ＳＮＳサイトが全部検索済みの場合、検索部４１３は、検索処理を完了する。

図１０は、検索結果管理部４１６が管理する検索結果管理テーブルの構成を示す図である。検索結果管理テーブル１０００には、ユーザ毎の検索結果の履歴が格納されている。１００１の列は、アプリケーション４００を利用するユーザのユーザ名を保持する列である。１００２の列は、検索キーワードを保持する列である。
１００３の列は、ＳＮＳサイト名を保持する列である。１００４の列は、検索キーワードがＳＮＳサイト内で検索された最後の検索日時を保持する列である。１００５の列は、検索結果の分類を保持する列である。１００６の列は、結果分類のレコードの更新日時を保持する列である。各更新日時は、「，（カンマ）」により区切られている。１００６の列にデータがないことは検索条件に該当するレコードが存在しないことを意味する。
１０１０、１０１１の行は、一つの検索結果を示す行である。例えば、１０１０の行は、ユーザＡが利用するＳＮＳサイトＡのプロファイルの中に「読書」というキーワードを含む登録コンテンツが存在し、この登録コンテンツは２０１２／９／１４に更新されていることを示している。

図１１は、投稿先判断処理の動作を説明するフローチャートである。ステップＳ１１０１では、投稿先判断部４１４は、検索結果管理部４１６に対し、各検索キーワードのＳＮＳサイト毎の検索結果を取得する処理を依頼する。検索結果管理部４１６は、投稿先判断部４１４から依頼を受け取ると、投稿先判断部４１４に各キーワードのＳＮＳサイト毎の検索結果を通知する。
ステップＳ１１０２では、投稿先判断部４１４は、ステップＳ１１０１で取得した検索結果に基づくＳＮＳサイト毎のマッチング度を計算する。本実施形態におけるマッチング度とは、画像受信部４０２で受信した画像データとＳＮＳサイトとの間の内容の一致具合を示す値である。投稿先判断部４１４は、対象となるＳＮＳサイトとのマッチング度が高いほど、ユーザが画像データを対象となるＳＮＳサイトに投稿する可能性が高いと認識する。より具体的には、投稿先判断部４１４は、（式１）により、マッチング度を算出する。
マッチング度
＝Σ_{全キーワート゛}（プロファイルのヒット件数＊プロファイルの重み
＋ハッシュタグのヒット件数＊ハッシュタグの重み
＋本文のヒット件数＊本文の重み）＊キーワード重み ・・・（式１）

（式１）において、「全キーワード」は、ステップＳ８０２で抽出したすべての検索キーワードである。「キーワード重み」は、ステップＳ８０２で抽出した検索キーワードの重みである。「プロファイルのヒット件数」は、全キーワードの中の一の検索キーワードが対象ＳＮＳサイトのプロファイルにヒットする件数である。図１０に示す検索結果１０１０においては、日時１００６の列においてヒットする件数は１件である。プロファイルは、頻繁に変更されることが少ない。このため、投稿先判断部４１４は、検索範囲内の件数を抽出しなくともよい。
「ハッシュタグのヒット件数」及び「本文のヒット件数」は、それぞれ検索範囲内で、対象ＳＮＳサイトのハッシュタグ及び本文においてヒットした件数である。検索タイミングを基準とする過去１ヶ月の日時が検索範囲として特定され、図１０に示す検索結果１０１１において、例えば、２０１２／９／２４時点で検索する場合、最上段の２０１２／８／１０は検索対象外となる。したがって、「ハッシュタグのヒット件数」は、５件となる。

「プロファイルの重み」、「ハッシュタグの重み」及び「本文の重み」は、それぞれ「プロファイル」、「ハッシュタグ」及び「本文」それぞれの結果分類に対する重みである。重みの値は、「プロファイルの重み」が最も高く、続いて、「ハッシュタグの重み」、「本文の重み」の順番となる。各重みの値は、予めＲＯＭ２０２又はＨＤＤ２０４に記憶されているものとする。
本実施形態にかかるＭＦＰ１００においては、プロファイルの結果分類に対し、一番高い重みが設定されている。これは、ユーザが、自身の趣向に応じて各ＳＮＳサイトの利用範囲を指定することが多いことに対応したものである。例えば、ユーザが趣味毎にＳＮＳサイトを使い分けている場合、ＳＮＳサイトのプロファイルの自己紹介部分に当該ＳＮＳサイトに関連する趣味を記載することが多い。

ＳＮＳサイトのハッシュタグは、ユーザが投稿を分類するために、自身の趣向に応じて付けた情報である。このため、本実施形態のＭＦＰ１００においては、ハッシュタグの結果分類に対し、やや高い重みが設定されている。ＳＮＳサイトの投稿・コメント本文は、量が多く、その内容には規則性がない。したがって、本実施形態のＭＦＰ１００においては、本文の結果分類に対し、低い重みが設定されている。
以上のように、投稿先判断部４１４は、（式１）により、画像データの内容とＳＮＳサイトとのマッチング度を計算することができる。図１０の検索結果管理テーブル１０００においては、ユーザＡが読書に関するコミュニケーションはＳＮＳサイトＡを利用する傾向がわかる。これに対応し、（式１）により、ユーザＡの投稿コンテンツである画像データに対しては、ＳＮＳサイトＡとのマッチング度が他のＳＮＳサイトとのマッチング度に比べて高い値となる。

図１１の説明に戻り、ステップＳ１１０３では、投稿先判断部４１４は、ステップＳ１１０３で計算した各ＳＮＳサイトのマッチング度に基づき投稿先を判断する。マッチング度が一番高く且つマッチング度の値が閾値（Ｔ１）より大きい場合、投稿先判断部４１４は、計算対象のＳＮＳサイトを投稿先として決定する。ここで、マッチング度の値が閾値（Ｔ１）よりも大きいというのは、ＭＦＰ１００に予め設定された規定条件である。
また、マッチング度が二番目以下のマッチング度と一番高いマッチング度の間の差が閾値（Ｔ２）以内且つマッチング度の値が閾値（Ｔ１）より大きいとする。この場合、投稿先判断部４１４は、２番目以下のマッチング度に対応するＳＮＳサイトも投稿先として決定する。つまり、投稿先判断部４１４は、マッチング度の値が近い複数のＳＮＳサイトを同時に投稿先として決定することができる。ユーザがスキャン・ファクス送信・プリントした文書内容により複数のＳＮＳサイトへの投稿を希望するケースに対応するものである。

一方で、一番高いマッチング度の値が閾値（Ｔ３）以下の場合、投稿先判断部４１４は、該当する投稿先がないと判断する。なお、Ｓ１１０３は、投稿先決定処理の一例である。上記閾値（Ｔ１〜Ｔ３）は、ＭＦＰ１００に予め設定された値である。
以上で、ＭＦＰ１００による投稿先判断処理が完了し、すなわち投稿処理が完了する。そして、ＵＩ制御部４０１は、ステップＳ１１０３の判断結果を受け取り、投稿先判断結果表示エリア７２０（図７）において、投稿先として判断されたＳＮＳサイトに対応するチェックボックスをチェックする。すなわち、ＵＩ制御部４０１は、投稿先のサービスをユーザに確認させるための画面としての投稿画面を表示する（表示制御処理）。

以上のように、第１の実施形態にかかるＭＦＰ１００は、スキャンした文書の内容（投稿コンテンツの内容）に応じて、複数のＳＮＳサイトの中から、投稿コンテンツの適切な投稿先を判断することができる。さらに、ＭＦＰ１００においては、投稿先ＳＮＳサイトを判断するための情報を予め登録するための煩雑な操作を不要とすることができる。さらに、ＭＦＰ１００においては、ＳＮＳサイトへの検索範囲を限定することにより、検索効率を向上させることができ、さらに投稿先判断に有用な検索結果を得ることができる。

（第２の実施形態：ファクス受信）
図１２は、第２の実施形態にかかるＭＦＰ１００の機能構成を示す図である。アプリケーション１３００は、ＭＦＰ１００のＯＳ上で動作するアプリケーションである。アプリケーション１３００は、受信したファクス文書の内容に応じて、自動的にファクス文書を投稿コンテンツとして適切なＳＮＳサイト（Ｗｅｂサーバ装置１０１のサービス）に投稿する。
アプリケーション制御部１３０１は、ファクス受信する際の処理及び投稿先判断結果に対する処理を行う。アプリケーション制御部１３０１は、モデム２１３がファクスを受信した際に、受信にかかる受信イベントを受け取り、ファクス画像受信部１３０２にファクス画像取得の依頼を行う。
アプリケーション制御部１３０１は、投稿先判断部４１４から投稿先の判断結果を受け取ると、ファクス画像を投稿先に投稿する処理を通信部４１５に依頼する。投稿する際のコメント及びファクス画像を添付するか否かについては、ユーザ等によりＭＦＰ１００に予め設定されているものとする。投稿先判断部４１４が該当する投稿先がないと判断した場合、アプリケーション制御部１３０１は、メール送信部１３０３に適切な投稿先がない旨のメールの送信処理を依頼する。

ファクス画像受信部１３０２は、アプリケーション制御部１３０１からファクス画像取得の依頼を受け取り、モデム２１３からファクスの画像データを受信する。ファクス画像受信部１３０２は、さらにファクスの画像データの受信を完了すると、判断通信モジュール４１０に対し、投稿処理（図８）を依頼する。投稿処理において参照されるユーザ情報は、予め指定されているものとする。なお、本実施形態においては、ユーザは管理者であることとする。
メール送信部１３０３は、アプリケーション制御部１３０１からメール送信処理の依頼を受け取り、事前設定したユーザ（管理者）に事前設定した内容のメールを送信する。
以上の構成により、第２の実施形態にかかるＭＦＰ１００は、被動的に文書を受け取る場合においても、受け取った文書の投稿先を判断することができる。なお、第２の実施形態にかかる情報処理システムのこれ以外の構成及び処理は、第１の実施形態にかかる情報処理システムと同様である。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
以上、上述した各実施形態によれば、煩雑な操作を必要とすることなく、投稿コンテンツの適切な投稿先を決定する仕組みを提供することができる。
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Claims (10)

1. 投稿対象の投稿コンテンツからキーワードを抽出するキーワード抽出手段と、
   前記投稿コンテンツの投稿ユーザが利用する複数のサービスそれぞれに登録されている複数の登録コンテンツの中から、前記キーワードを含む登録コンテンツを検索する検索手段と、
   前記サービス毎の検索結果に基づいて、前記複数のサービスの中から、前記投稿コンテンツの投稿先となるサービスを決定する投稿先決定手段と
   を有することを特徴とする情報処理装置。
2. 前記登録コンテンツと、前記登録コンテンツの更新日時とを対応付けて記憶する検索履歴管理手段と、
   前記登録コンテンツの更新日時及び前記検索手段による検索タイミングに基づいて、前記複数の登録コンテンツのうち検索対象とする登録コンテンツの検索範囲を決定する検索範囲決定手段と
   をさらに有し、
   前記検索手段は、前記検索範囲内の前記登録コンテンツの中から前記キーワードを含む前記登録コンテンツを検索することを特徴とする請求項１に記載の情報処理装置。
3. 前記検索範囲決定手段は、前記検索タイミングより後の前記更新日時に対応付けられている前記登録コンテンツを前記検索範囲として決定することを特徴とする請求項２に記載の情報処理装置。
4. 前記検索履歴管理手段は、前記登録コンテンツに対応付けて、前記登録コンテンツに対する検索が実行された検索日時をさらに記憶し、
   前記検索範囲決定手段は、さらに前記検索日時に基づいて、前記検索範囲を決定することを特徴とする請求項２又は３に記載の情報処理装置。
5. 各ユーザが利用する前記複数のサービスを、ユーザ毎に記憶するユーザ情報管理手段をさらに有し、
   前記検索手段は、前記ユーザ情報管理手段において前記投稿ユーザに対応付けられている前記複数のサービスを検索対象として、検索することを特徴とする請求項１に記載の情報処理装置。
6. 前記投稿先決定手段は、前記検索手段により検出された前記登録コンテンツが規定条件を満たす場合に、前記投稿コンテンツの投稿先を決定することを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
7. 前記投稿コンテンツは、前記投稿ユーザにより入力された投稿コメントを含むことを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
8. 前記投稿先決定手段で決定された前記投稿コンテンツの投稿先となるサービスを、ユーザに確認させるための画面を表示させる表示制御手段を更に有することを特徴とする請求項１乃至７の何れか１項に記載の情報処理装置。
9. 情報処理装置が実行する情報処理方法であって、
   投稿対象の投稿コンテンツからキーワードを抽出するキーワード抽出ステップと、
   前記投稿コンテンツの投稿ユーザが利用する複数のサービスそれぞれに登録されている複数の登録コンテンツの中から、前記キーワードを含む登録コンテンツを検索する検索ステップと、
   前記サービス毎の検索結果に基づいて、前記複数のサービスの中から、前記投稿コンテンツの投稿先となるサービスを決定する投稿先決定ステップと
   を含むことを特徴とする情報処理方法。
10. コンピュータを、
    投稿対象の投稿コンテンツからキーワードを抽出するキーワード抽出手段と、
    前記投稿コンテンツの投稿ユーザが利用する複数のサービスそれぞれに登録されている複数の登録コンテンツの中から、前記キーワードを含む登録コンテンツを検索する検索手段と、
    前記サービス毎の検索結果に基づいて、前記複数のサービスの中から、前記投稿コンテンツの投稿先となるサービスを決定する投稿先決定手段と
    して機能させるためのプログラム。

Images