JP5916596B2

JP5916596B2 - タスク配分サーバ、タスク配分方法、およびタスク配分プログラム

Info

Publication number: JP5916596B2
Application number: JP2012275467A
Authority: JP
Inventors: 辰也石原
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-12-18
Filing date: 2012-12-18
Publication date: 2016-05-11
Anticipated expiration: 2032-12-18
Also published as: CN103870913A; CN103870913B; JP2014120031A

Description

本発明は、複数種類のサービスからのタスクを配分するための技術に関し、より詳細には、特定種類のサービスからのタスクの作業の遅れをなくして全体的な作業の効率化を図るための技術に関する。

近年、インターネットを通じて不特定多数の群集に業務を委託するクラウドソーシングが注目されている。Ａｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．が運営するＡｍａｚｏｎＭｅｃｈａｎｉｃａｌＴｕｒｋや、ＩｎｎｏＣｅｎｔｉｖｅ，Ｉｎｃ．が運営するＩｎｎｏＣｅｎｔｉｖｅは世界的に有名なクラウドソーシングである。これまでのクラウドソーシングの仕組みでは、ユーザは特定のサービスを提供するサーバに能動的にアクセスして作業を行っていた（図１（ａ）を参照）。しかしユーザが能動的にアクセスするだけでは、集められる労働力は限られている。

そこで、様々なクラウドソーシングからのタスクを１つのサービスに集約し、同一のインタフェースで様々な種類のタスクをユーザに提示し続ける方法が考えられる（図１（ｂ）参照）。しかし、それぞれ異なる興味・スキルのセットを持つユーザにランダムにタスクを提示しても、多くの作業量は期待できない。

ユーザ本人についての過去の履歴又は類似する他についての履歴を利用して最終的に推薦すべき対象を決定する従来技術として特許文献１〜４が存在する。

特許文献１は、ユーザのロールに基づいてユーザのタスクを推定し、推定したユーザのタスクを支援するためのサービスを検索し、ユーザのタスクに応じたサービスを推薦するサービス推薦システムを開示する。特許文献１はまた、より確度の高いタスク推定を行う場合は、現在の時間、及び、現在のユーザの位置情報と、タスクに対応付けられた時間情報及び場所情報（「時間と場所の利用ログ」又は「標準的な時間、場所」）との比較を行うことにより、ユーザ行動を推定する技術を開示する。

特許文献２は、ユーザが使う複数の機器から嗜好を抽出し、よりユーザの興味に近いコンテンツを推薦できるようにする情報検索システムを開示する。特許文献２はまた、ＨＤＤに記憶されたユーザの視聴履歴、操作履歴を検索し、ユーザの嗜好を分析して、得られた嗜好情報に基づいて、興味データを生成する技術を開示する。

特許文献３は、設備に対する作業に関する複数の技術情報、複数の設備各々の状況を表す複数の設備情報、及び端末における技術情報の閲覧の実績を表す閲覧実績情報にアクセスし、閲覧実績情報に対応する第１の設備情報と目的の設備に対応する第２の設備情報とを取得し、第１の設備情報を含む比較情報と第２の設備情報を含む対象情報との関連度を計算し、その関連度に基づいて、閲覧実績情報に対応する技術情報の中から出力対象として優先する情報を抽出する情報提供装置を開示する。特許文献３はまた、相関計算処理において、協調フィルタリング手法を用いて正規化後の比較データ（第１のユーザ経歴データ）各々と、正規化後の対象データ（第２のユーザ経歴データ２３２）との関連度（相関の高さ）を計算することを開示する。

特許文献４は、パーソナル・コンピュータには、ユーザの一覧保存するユーザ一覧テーブルと、画像に関連するタスクの一覧を保存するタスク一覧テーブルと、タスクと操作とを関連付けた操作履歴を保存する操作履歴テーブルとを具備するデータベース部を備え、タスク情報管理サーバには、タスク情報を保存した情報管理データベース部を備え、ユーザがファイルに対する操作を行う際には、そのファイルに関連するタスクに基づきユーザの操作する可能性が高い操作を予測し、提示する技術を開示する。

また、複数の計算機システムを用いてジョブを実行する場合に、利用者が依頼したジョブが完了する時間をあらかじめ予測すると同時に、計算機システムの利用に際して、ジョブの完了期限を考慮したジョブ配分を実現する従来技術として特許文献５が存在する。特許文献５は、複数の計算機システムを備えた分散処理システムにおいて、計算機システムの各々の稼働情報を共有し、計算機システムの一つに投入するジョブの実行優先度の最適化および実行期限を指定し、投入したジョブの実行完了時期を予測し、予測結果に応じて変更した実行優先順位で再度ジョブの実行完了時期を予測し、予測結果に応じて稼働情報を共有する他の計算機システムへジョブ実行を依頼する技術を開示する。

また、クラウドソーシングにおけるワーカーの到着とタスクの実行をポアソン過程でモデル化した上でコストの最適化を行う従来技術として非特許文献１及び２が存在する。

非特許文献１は、ワーカーの作業を予測した上で時間内に作業を終わらせるために報酬を決定する技術を開示する。

非特許文献２は、クラウドソーシングにおけるワーカーの到着とタスクの実行をポアソン過程でモデル化することで、リアルタイム性を要求するクラウドソーシングのタスクを小さいコストで実現する技術を開示する。

また、非特許文献３は、ウィキペディアにおける編集作業のタスク配分技術を開示する。より具体的には、非特許文献３は、ユーザが編集した記事のタイトル、リンク構造から次に編集すべき記事を推薦する技術を開示する。

なお、以下の非特許文献４及び５は、それぞれＭａｔｒｉｘＦａｃｔｏｒｉｚａｔｉｏｎによる協調フィルタリング、ＴｅｎｓｏｒＦａｃｔｏｒｉｚａｔｉｏｎによるコンテキストを考慮した協調フィルタリングを示す背景技術として列挙するものである。

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

S. Faridani, B.Hartmann, P. Ipeirotis, "What's the Right Price? Pricing Tasks forFinishing on Time", Proceedings of the Third Human Computation Workshop,2011 Michael Bernstein, David R. Karger, Robert C. Miller, and Joel R. Brandt,"Analytic Methods for Optimizing Realtime Crowdsourcing", Proceedings of CollectiveIntelligence 2012 DanCosley, Dan Frankowski, Loren Terveen, John Riedl, "SuggestBot: UsingIntelligent Task Routing to Help People Find Work in Wikipedia", IUI '07 Proceedings of the12th international conference on Intelligent user interfaces, 2007, Pages 32-41 Gabor Takacs, IstvanPilaszy, Bottyan Nemeth, "Major components of the Gravity RecommendationSystem", ACM SIGKDD Explorations Newsletter - Special issue on visualanalytics Volume 9 Issue 2, December 2007 , Pages 80-83 AlexandrosKaratzoglou, Xavier Amatriain, Linas Baltrunas, "MultiverseRecommendation: N-dimensional Tensor Factorization for Context-awareCollaborative Filtering", RecSys '10Proceedings of the fourth ACM conference on Recommender systems, Pages79-86

しかしながら、特許文献１〜４及び非特許文献３の技術は、特定の人又は物について過去の履歴に基づき推薦すべき対象を決定する技術であり、これら文献では全体的な作業の効率化を図るという考えはない。従って、上記技術をクラウドソーシングにおけるタスク配分に採用したとしても、特定種類のタスクに人気が集中し、一部のタスクについては作業が遅れるという事態を防ぐことはできない。

一方、非特許文献１及び２の技術は、クラウドソーシングにおいて全体的な作業の効率化を図るという観点からタスクを配分する技術を開示する。しかしながら非特許文献１の技術は時間内に作業を終わらせるために報酬を与える技術であるため場合によってはコストがかかる。また、非特許文献２の技術は、その実行可能なタスクに基づきワーカーを複数のグループに分け、タスクとワーカーの到着レートを考慮してスループットが最もよくなるようグループに対してタスクの配分を決定するものである。しかしながら非特許文献２の技術では、タスク配分時において実際のタスク実行状況が考慮されることはないため、やはり一部のタスクについて作業が遅れるという事態は起こり得る。

また、特許文献５の技術は、利用者が所属する部門の計算機システムでは利用者が要望する日程を満足させることができない場合に他部門が運用する計算機システムの利用可能性を調べて利用者が要望する期限までにジョブを完了させる技術を開示する。しかしながら、特許文献５の技術においてジョブを完了させるのは計算機システムであるため、これをジョブの実行が人間によってなされるクラウドソーシングのサービスに単純に適用することはできない。

なお、上述したように非特許文献４及び５は、本発明の実施形態の１つにおいて利用する協調フィルタリング技術を説明する文献としてリストしたにすぎない。

本発明は、上記従来技術における問題点に鑑みてなされたものであり、本発明は、複数種類のサービスからのタスクを配分するクラウドソーシングのサービスにおいて、特定種類のサービスからのタスクの作業の遅れをなくして全体的な作業の効率化を図ることのできるタスク配分方法、タスク配分サーバ、およびタスク配分プログラムを提供することを目的とする。

本発明は、上記従来技術の課題を解決するために以下の特徴を有するタスク配分方法を提供する。本発明のコンピュータの処理により複数種類のサービスからのタスクをユーザに配分するためのタスク配分方法は、（ａ）前記コンピュータが、前記複数種類のサービスの各々について、前記ユーザの前記サービスからのタスクの実行履歴から前記ユーザの興味度の推定値と該推定値の不確かさを算出するステップと、（ｂ）前記コンピュータが、前記複数種類のサービスの各々について、前記興味度の推定値と該推定値の不確かさに基づいて前記サービスからのタスクの優先度を算出するステップであって、前記タスクの優先度は同一の前記サービスからのタスクを配分されている他のユーザにより前記同一のサービスからのタスクが実行されていない確率を考慮して算出される、前記ステップと、（ｃ）前記コンピュータが、算出された前記優先度の一番大きいサービスからのタスクを前記ユーザに提示すべきタスクとして決定するステップとを含む。

好ましくは、ステップ（ｂ）において、前記推定値の不確かさは、前記他のユーザにより前記同一のサービスからのタスクが実行されていない前記確率で重み付けされる。

また好ましくは、ステップ（ｂ）において、前記優先度は、重み付けされた前記推定値の不確かさと前記興味度の推定値の和として算出される。

また好ましくは、ステップ（ａ）において、サービスごとの前記ユーザの興味度の推定値は、前記ユーザが前記サービスからのタスクを実行する確率の推定値の平均として算出され、及び、前記推定値の不確かさは、前記推定値の標準偏差として算出される。

また好ましくは、ステップ（ｂ）において、前記他のユーザにより前記同一のサービスからのタスクが実行されていない前記確率は、前記他のユーザの前記同一のサービスからのタスクに対する興味度と、前記他のユーザの前記同一のサービスからのタスクに対するスキルとの積を値１から差し引き、これを全ての前記他のユーザについて掛け合わせることにより算出される。より好ましくは、ステップ（ｂ）において、前記他のユーザにより前記同一のサービスからのタスクが実行されていない前記確率は、前記他のユーザが前記同一のサービスからのタスクを実行する確率と、前記優先度の算出の際に前記他のユーザが前記同一のサービスからのタスクを完了している確率との積を値１から差し引き、これを全ての前記他のユーザについて掛け合わせることにより算出される。

また好ましくは、ステップ（ａ）において、前記ユーザの実行履歴のないサービスについては、協調フィルタリングを利用して前記ユーザの興味度の推定値が算出される。

また好ましくは、ステップ（ａ）は、前記ユーザに対するタスクの提示に応答して繰り返し実行され、上記方法は、前記コンピュータが、算出された前記ユーザの興味度の推定値と該推定値の不確かさとを次の優先度算出の際に利用可能なように保存するステップを更に含む。

より好ましくは、ステップ（ｂ）は、前記ユーザによる前記コンピュータへのログインに応答して実行され、上記方法は、前記コンピュータが、前記ユーザがログアウトするまで、定期的にステップ（ｂ）及びステップ（ｃ）を繰り返すステップを更に含む。更に好ましくは、前記コンピュータは、Ｗｅｂサーバであり、ステップ（ｃ）について、タスクの提示は、前記ユーザのコンピュータに導入されたＷｅｂブラウザ、またはクライアントアプリケーションにカード形式で表示される。

また好ましくは、前記コンピュータは、Ｗｅｂサーバに接続し、ステップ（ｂ）は、前記ユーザによる前記Ｗｅｂサーバへのログインに応答して実行され、及び、ステップ（ｃ）について、タスクの提示は、前記Ｗｅｂサーバを介して前記ユーザのコンピュータに導入されたＷｅｂブラウザ、またはクライアントアプリケーションにカード形式で表示される。更に好ましくは、上記方法は、前記コンピュータが、前記ユーザが前記Ｗｅｂサーバをログアウトするまで、定期的にステップ（ｂ）及びステップ（ｃ）を繰り返すステップを更に含む。

また好ましくは、上記方法は、ステップ（ｃ）について、前記コンピュータが、前記優先度が所定の閾値を超えることを条件として、決定された前記タスクを前記ユーザにアラート通知するステップを更に含む。

以上、複数種類のサービスからのタスクを配分するためのタスク配分方法として本発明を説明した。しかし本発明は、そのようなタスク配分方法の各ステップをコンピュータに実行させるタスク配分プログラム、及びタスク配分プログラムをサーバ用コンピュータにインストールして実現されるタスク配分サーバとして把握することもできる。

本発明によれば、複数種類のサービスからのタスクを配分するタスク配分サービスが提供される。該タスク配分サービスでは、サービスごとそのタスクの優先度がユーザのサービスに対する興味度の推定値と該推定値の不確かさに基づいて求められ、優先度の高いタスクがユーザに提示すべきタスクとして決定される。優先度の算出にあたっては同一のサービスからのタスクを配布されている他のユーザにより該タスクが実行されていない確率が考慮される。このため、特定種類のサービスからのタスクの作業が遅れる可能性があるときは、その特定種類のサービスに潜在的な興味をもつユーザに対して積極的にタスクを配布することが可能となる。結果、本発明によれば、特定種類のサービスからのタスクの作業の遅れをなくして全体的な作業の効率化を図ることが可能となる。本発明のその他の効果については、各実施の形態の記載から理解される。

図１の（ａ）は、従来のクラウドソーシング・システムの構成の一例を示す図である。図１の（ｂ）は、提案するクラウドソーシング・システムの構成の一例を示す図である。図２の（ａ）は、本発明の実施形態によるタスク配分サーバを含むシステム全体の構成の一例を示す図である。図２の（ｂ）は、本発明の実施形態によるタスク配分サーバを含むシステム全体の構成の他の例を示す図である。本発明の実施形態によるタスク配分サーバ２００を実現するのに好適な情報処理装置のハードウェア構成の一例を示す。本発明の実施形態によるタスク配分サーバ２００の機能ブロック図である。実行履歴情報の表の一例を示す図である。Ｗｅｂブラウザにカードを示す例を示す図である。各ユーザiにタスクを配分するためのタスク配分処理の全体の流れを示すフローチャートである。図７に示すフローチャートのステップ７０２の優先度算出処理の流れを示すフローチャートである。タスク配分サーバがバックグラウンドで定期的に行う処理の流れを示すフローチャートである。図１０（ａ）〜（ｃ）は、シミュレーションによる第１の実験結果を示す図である。図１１（ａ）〜（ｃ）は、シミュレーションによる第２の実験結果を示す図である。図１２（ａ）、（ｂ）は、シミュレーションによる第３の実験結果を示す図である。

以下、本発明を実施するための形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。

本発明の実施形態に係るタスク配分サーバは、ユーザが空いた時間にタスクを実行できるように、ユーザからのリクエストの有無に関わらずタスクをユーザに提示し続ける。これを実現するために、本発明の実施形態に係るタスク配分サーバは、図２（ａ）に示すように、ポータルサイトやソーシャル・ネットワーキング・サービスなどクライアント・コンピュータのユーザが常時ログインしているようなサービスを提供するＷｅｂサーバ２０２ａの一機能として実装してよい。また、メールクライアント等のように、ユーザが頻繁に利用するクライアントアプリケーションの一部として実装してよい。Ｗｅｂサーバ２０２ａであるタスク配分サーバは、ユーザがログインしている間、ユーザに対して選択したタスクをＷｅｂブラウザの画面の一部、またはクライアントアプリケーションの一部に表示し続ける。

また本発明の実施形態に係るタスク配分サーバは、登録されている様々な種類のサービスの中から、全体的な作業の効率化を考慮しつつユーザに適したサービスのタスクを選択して提示する。このためＷｅｂサーバ２０２ａであるタスク配分サーバは、図２（ａ）に示すように、インターネット２０４を介して接続される、複数のサーバ２１２ａ、２１２ｂ、２１２ｃが提供する様々なクラウドソーシングからのタスクを１つのサービスとして集約してよく、或いは、タスクの登録を特定種類のサービスに限定することなく個人／法人から直に受け付けてもよい。

前者の場合、タスク配分サーバは、クラウドソーシングのサービスを提供する個々のサーバ２１２ａ、２１２ｂ、２１２ｃから登録されているサービスのタスク情報を定期的に受信する。後者の場合、タスク配分サーバは、従来のクラウドソーシングにおけるサーバのように、サービスの登録を希望する個人／法人に対し所定の登録フォームを提示して登録すべきサービスのタスク情報を入力させる。いずれの場合もタスク配分サーバは、取得したタスク情報を保持してタスク配分サービスを提供する。以下では、前者の構成を採用するものとしてタスク配分サーバを説明する。

図２（ａ）において、Ｗｅｂサーバ２０２ａには、インターネット２０４を介して、複数のクライアント・コンピュータ２０６ａ、２０６ｂ・・・２０６ｚが接続されている。図２（ａ）のシステムにおいては、クライアント・コンピュータのユーザは、Ｗｅｂブラウザを通じて、インターネット２０４の回線を介して、Ｗｅｂサーバ２０２ａにログインする。具体的には、所定のＵＲＬをＷｅｂブラウザに打ち込んで、所定のページを表示する。ここでは、Ｗｅｂサーバ２０２ａが実現するタスク配分サービス以外のサービスとして、ソーシャル・ネットワーク・システム（ＳＮＳ）を想定する。

ログインに当たっては、クライアント・コンピュータのユーザは、与えられたユーザＩＤと、それに関連付けられたパスワードを用いる。クライアント・コンピュータのユーザは、一旦ログインすると、ＳＮＳ内で、ブログを書いたり、アクセスを許可されている他人のブログを閲覧してコメントを書いたり、ニュースを見たり、気の合った仲間同士でグループを作成したり、チャットしたり、趣味のコミュニティを検索したり、提示されているタスクを実行したり、などの活動を行う。

Ｗｅｂサーバ２０２ａにはまた、パケット通信網１０８を介して、スマート・フォン２１０ａ、・・・２１０ｋなどのモバイル端末が接続される。ユーザは、与えられたユーザＩＤと、それに関連付けられたパスワードがあれば、スマート・フォンに導入されているＷｅｂブラウザを通じて、同様にＷｅｂサーバ２０２ａのＳＮＳにアクセスできる。

なお、本発明の実施形態に係るタスク配分サーバの実装方法は、図２（ａ）を参照して説明した方法に限定されない、例えば図２（ｂ）に示すシステムのように、Ｗｅｂサーバ２０２ｂとは別個のサーバとしてタスク配分サーバを実装してもよい。この場合タスク配分サーバは、Ｗｅｂサーバ２０２ｂからユーザのログイン、ログアウト情報を受信しつつ、ユーザごと選択したタスク情報を、Ｗｅｂサーバ２０２ｂを介してクライアント・コンピュータ２０６ａ、２０６ｂ・・・２０６ｚや、スマート・フォン２１０ａ、・・・２１０ｋなどのモバイル端末のユーザに提示する。なお、図２（ｂ）に示すシステムでは、タスク配分サーバ２０３は、インターネット２１４を介して接続される複数のサーバ２１２ａ、２１２ｂ、２１２ｃが提供する様々なクラウドソーシングからのタスクを１つのサービスとして集約している。以下では、本発明の実施形態に係るタスク配分サーバをＷｅｂサーバの一機能として実装する場合について説明する。

図３は、本発明を実施するためのＷｅｂサーバ２０２ａとしてのコンピュータ３００の例示的なハードウェア構成を示す。コンピュータ３００は、ＣＰＵ３０２とメイン・メモリ３０４とを備えており、これらはバス３０６に接続されている。バス３０６にはまた通信コントローラ３２４を介して通信インタフェース３２６が接続されている。通信インタフェース３２６は、コンピュータ３００を通信回線３２８（クライアント・コンピュータと通信するためのインターネット、及び、スマート・フォンと通信するためのパケット通信網を含む）に物理的に接続する役割を担い、コンピュータ３００のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インタフェース層を提供する。なお、通信回線は、有線ＬＡＮ環境に基づくもの、又は、無線ＬＡＮ環境、例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどのＷｉ−Ｆｉ規格に基づくものであってもよい。

バス３０６にはまた、ディスプレイ・コントローラ３０８を介して、ディスプレイ３１０、例えば液晶ディスプレイ（ＬＣＤ）や、キーボード・マウスコントローラ３１８又はＵＳＢバス（図示せず）を介して、キーボード３２０及びマウス３２２が接続されうる。これらによって、Ｗｅｂサーバ及びタスク配分サーバとしてのコンピュータ３００全体の管理やメンテナンス作業を行うようにしてもよい。

バス３０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ３１２を介して、ディスク３１４、例えばシリコン・ディスク又はハードディスクが接続されうる。バス３０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ３１２を介して、任意的に、ドライブ３１６、例えばＣＤ、ＤＶＤ又はＢＤドライブが接続されうる。

ディスク３１４には、オペレーティング・システム、クライアント・コンピュータ２０６ａ、２０６ｂ・・・２０６ｚのログイン管理のための、ユーザＩＤとパスワードの対応テーブルが保存されている。ディスク３１４にはさらに、コンピュータ３００をＷｅｂサーバａとして機能させるためのＡｐａｃｈｅなどのソフトウェアが、コンピュータ３００の立ち上げ時にメイン・メモリ３０４にロード可能なように保存されている。これによってユーザのコンピュータがＴＣＰ／ＩＰのプロトコルで、コンピュータ３００にアクセスすることが可能となる。ディスク３１４にはまた、パケット通信網を介してスマート・フォンと通信するための通信モジュールも格納されている。

ディスク３１４にはまた、このＳＮＳの各ユーザのメッセージ、ブログ、掲示板などの情報と、ＳＮＳの情報が、好適には、ＨＴＭＬファイルなどのテキスト形式、あるいはグラフィック・イメージ、動画ファイル、音楽ファイルなどのマルチメディア形式で、保存されている。ブログ、及び掲示板には、当該ユーザが書き込むことができ、他のユーザは、許された権限に応じて、ブログ、掲示板を読んだり、コメントを付けたりすることができる。

ディスク３１４には更に、図４の機能ブロック図に関連して後述するタスク情報、履歴情報、タスク登録・管理モジュール、履歴情報管理モジュール、ログイン検出モジュール、優先度算出モジュール、興味度算出モジュール、不実行確率算出モジュール、タスク決定モジュールがメイン・メモリ３０４にロード可能なように保存されている。これらモジュールは、ＣＰＵ３０２に働きかけて、コンピュータ３００を、タスク登録・管理部４０４、タスク情報格納部４０６、履歴情報管理部４０８、履歴情報格納部４１０、ログイン検出部４０９、優先度算出部４１２、興味度算出部４１４、不実行確率算出部４１６、タスク決定部４１８としてそれぞれ機能させる。コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。

なお、様々なクラウドソーシングからのタスクを１つのサービスとして集約する代わりに、タスクの登録を特定種類のサービスに限定することなく個人／法人から直に受け付ける場合、ディスク３１４には更にまた、クラウドソーシングのサービスとして従来知られている機能、即ち、タスク依頼者によるタスクの登録を受け付ける登録受け付け処理、タスク依頼者とタスク実行者との間の契約締結処理、実行結果のレビュー及び承認処理、報酬の支払い処理などの処理をコンピュータ３００に実行させるためのモジュールも格納される。

Ｗｅｂサーバ用のコンピュータ３００として、インターナョナル・ビジネス・マシーンズ・コーポレーションから購入可能な、ＩＢＭ（インターナョナル・ビジネス・マシーンズ・コーポレーションの商標）ＳｙｓｔｅｍＸ、Ｓｙｓｔｅｍｉ、Ｓｙｓｔｅｍｐなどの機種のサーバを使うことができる。その際、使用可能なオペレーティング・システムは、ＡＩＸ(インターナョナル・ビジネス・マシーンズ・コーポレーション社の商標)、ＵＮＩＸ(ＴｈｅＯｐｅｎＧｒｏｕｐの商標)、Ｌｉｎｕｘ(ＬｉｎｕｓＴｏｒｖａｌｄｓの商標)、Ｗｉｎｄｏｗｓ(商標)２００３Ｓｅｒｖｅｒなどがある。特にこの実施例では、オペレーティング・システムとしてＬｉｎｕｘ(ＬｉｎｕｓＴｏｒｖａｌｄｓの商標)を採用し、その上にＪａｖａ(Ｒ)ＥＥを導入し、サーバサイドＪａｖａ(Ｒ)が導入され、本発明の処理プログラムである上記複数のモジュールは好適には、その上で動くＪａｖａ(Ｒ)のプログラム、あるいはＳｅｒｖｌｅｔの形式で実装される。

以上から、本発明の実施態様において使用されるコンピュータ３００は、ワークステーションやメインフレームなどの情報処理装置、又は、これらの組み合わせによって実現されることが容易に理解されるであろう。なお、上記説明した構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。特に、本発明の実施形態に係るタスク配分サーバをＷｅｂサーバとは別個のサーバとして実装する場合、上述したＳＮＳを提供するＷｅｂサーバとして機能するための構成要素は不要となることに留意されたい。

次に、図４の機能ブロック図を参照して、本発明を実施するための処理要素について説明する。上述したとおり、本発明の実施形態に係るタスク配分サーバ４００はＷｅｂサーバ２０２ａの一機能として実装されるものとする。また、タスク配分サーバ４００は、複数のサーバが提供する様々なクラウドソーシングのサービスからのタスクを１つのサービスとして集約するものとする。

通信部４０２は、クラウドソーシングの複数種類のサービスを提供する複数のサーバと、いずれかのサービスからのタスクを実行する複数のタスク実行者のそれぞれとの間でデータの送受信を行う。

タスク登録・管理部４０４は、通信部４０２において定期的に受信される、クラウドソーシングのサービスを提供する個々のサーバに登録されているサービスからのタスクに関するタスク情報を、後述するタスク情報格納部４０６に格納する。タスク登録・管理部４０４はまた、タスク情報格納部４０６にそのタスク情報が格納されるサービスごと、該サービスからのタスクを提示されたタスク実行者の実行者リストを作成し、これを対応するサービスからのタスク情報に関連付けて保存し、管理する。具体的には、タスク登録・管理部４０４は、通信部４０２からあるサービスからのタスクがタスク実行者へ送信され提示されると、そのタスク実行者をタスクの送信時刻と共に該当するサービスの実行者リストに追加する。このときタスク登録・管理部４０４は、後述する履歴情報管理部４０８へ、タスク実行者のタスク実行に関する履歴情報として、タスク実行者の識別情報、タスクの識別情報、タスクの属するサービスの識別情報、及びタスク情報の送信時刻を渡す。また、タスク登録・管理部４０４は、通信部４０２においてタスク実行者からタスクの実行結果が受信されると、そのタスク実行者を該当するサービスの実行者リストから削除する。このときタスク登録・管理部４０４は、後述する履歴情報管理部４０８へ、タスク実行者のタスク実行に関する履歴情報として、タスク実行者の識別情報、タスクの識別情報、タスクの属するサービスの識別情報、及びタスクの実行結果の受信時刻を渡す。

タスク情報格納部４０６は、クラウドソーシングを提供する複数のサーバにそれぞれ登録されているタスク情報を格納する。タスク情報は、そのタスクが属するサービス単位でまとめられ、サービスの識別情報、該サービスに属する全てのタスクの識別情報、タスク実行者に提示するタスクの概要、実行条件（例えば、期限、報酬、必要な資格、募集人数など）、タスク依頼者情報を含む。また上述したように、タスク情報格納部４０６は、同一のサービスに属するタスクを提示されたタスク実行者のタスク実行者リストを、対応するタスク情報に関連付けて格納する。

履歴情報管理部４０８は、Ｗｅｂサーバ２０２にユーザとして登録されているユーザごと、そのタスク実行の履歴を作成し、これを後述する履歴情報格納部４１０に格納して管理する。具体的には、履歴情報管理部４０８は、タスク登録・管理部４０４からタスク実行者のタスク実行に関する履歴情報を受け取るとこれを該当するタスク実行者の履歴情報に追加する。

履歴情報格納部４１０は、Ｗｅｂサーバ２０２にユーザとして登録されているユーザごと、該ユーザが実行したタスクの実行履歴に関する履歴情報を格納する。ユーザごとのタスク実行に関する履歴情報は、タスクが属するサービスの識別情報、タスクの識別情報、タスクの実行開始時刻（一例として、タスク情報の送信時刻）、及びタスクの完了時刻（一例として、タスクの実行結果の受信時刻）を含む。一例として履歴情報は、図５に示す表のように表形式で維持されてよい。図５に示す表は、ユーザＩＤフィールド、サービスＩＤフィールド、タスクＩＤフィールド、開始時刻フィールド、及び完了時刻フィールドを含む。なお、タスクを提示された段階では完了時刻フィールドに値は設定されず、ユーザからタスクの実行結果が送信されることによって、完了時刻フィールドに値が設定されることに留意されたい。

ログイン検出部４０９は、Ｗｅｂサーバ２０２へのユーザのログインを検出する。タスク配分サーバ４００がＷｅｂサーバの一機能として実装されているか否かに関わらず、該検出は、Ｗｅｂサーバ２０２からタスク配分サーバ４００へのユーザ情報を含むログイン成功の通知によってなされる。

優先度算出部４１２は、ログイン検出部４０９によりそのログインが検出されたユーザに対し、タスク情報格納部４０６に格納される複数種類のサービスの各々について、該サービスからのタスクの優先度を算出する。なお、優先度算出部４１２は、後述する興味度算出部４１４と不実行確率算出部４１６によりそれぞれ算出される値を用いて優先度を算出する。このため優先度算出部４１２は、それらの値が利用可能な状態である場合はその値を読み出し、利用可能でない場合は値の算出を依頼する。優先度算出処理の詳細は後述する。

興味度算出部４１４は、タスク情報格納部４０６に格納される複数種類のサービスの各々について、ユーザのタスク実行に関する履歴情報に基づき、上記サービスからのタスクに対するユーザの興味度の推定値と該推定値の不確かさとを算出する。好ましくは、興味度算出部４１４は、サービスごとのユーザの興味度の推定値を、ユーザが該サービスからのタスクを実行する確率の推定値の平均として算出し、また、サービスごとの推定値の不確かさを、推定値の標準偏差として算出する。これについて以下詳細に説明する。

上述したように、ユーザiのサービスjへの興味は、各サービスのタスクをユーザが実行する確率で表されるものと仮定し、以下の二項分布の確率Pの平均P_P（i,ｊ）で表されるとする。
― ユーザiが、サービスｊのタスクをｎ回提示されて、ｋ回実行する確率P
このとき確率Pをベイズ推定したときのPの平均値P_P（i,ｊ）とPの分散Pσ（i,ｊ）は、Pの事前分布を一様分布と仮定すると、それぞれ以下の式（１）及び式（２）のように求められる。

ここで、式に現れるｎとｋのそれぞれの値は、ユーザの履歴情報から求める。即ち、上述したように、実行履歴情報格納部４１０に格納されるユーザごとのタスク実行に関する履歴情報は、タスクが属するサービスの識別情報と、タスクの識別情報と、タスクの実行開始時刻と、タスクの完了時刻とを含む。そこで、サービスの識別情報が同一であるエントリの数がｎの値となり、そのうちタスクの完了時刻が設定されているエントリ数がｋの値となる。

なお、P_P（i,ｊ）に欠損値があった場合、即ち、ユーザのタスク実行に関する履歴情報のないサービスがあった場合、協調フィルタリングを利用してユーザの興味度の推定値を算出してよい。以下では、ＭａｔｒｉｘＦａｃｔｏｒｉｚａｔｉｏｎにより他のユーザの興味度の値から推測値を計算する方法について説明する。

まず次のように定義する。即ち、以下に示す式（３）は、ユーザiが各タスクを実行した確率を示す。なお、タスク配分サーバ４００に登録されているサービスｊはｍ種類あるとする。式（４）は、全てのユーザのタスクの実行確率を示す。なお、Ｗｅｂサーバ２０２ａに登録されているユーザ数はn（nは２以上の整数）とする。式（５）は各ユーザiの各タスクの実行確率のＭａｔｒｉｘＦａｃｔｏｒｉｚａｔｉｏｎによる推測を示す。

なお式（５）の左辺のマトリックスPpが最終的に求めるべきものであり、その成分がP_P（i,ｊ）となる。

次に以下のステップにより、マトリックスPpを求める。
ステップ１：マトリックスU,Tをランダムな値により作成する。
ステップ２：マトリックスU,Tを以下の式（６）〜（８）に従い、収束するまで更新処理を繰り返す。ここでKは、ＭａｔｒｉｘＦａｃｔｏｒｉｚａｔｉｏｎの潜在因子数であり、予め指定される。一例としてKは、タスク配分サーバ４００に登録されているタスクの種類に基づきヒューリスティックに決定される。例えば、文字校正と画像の説明文を付加する２種類のタスクが登録されているとすると、文字入力のスキルと日本語のスキルが必要と考えられるため、潜在因子数として２が指定される。また、α、βも定数として予め指定する。これらには数値計算が安定する数字が経験値として指定される。後述する実験ではα＝0.0001、β＝0.01とした。

ステップ３：ステップ２で得られたマトリックスU,Tを用いて、上式（５）に従ってマトリックスPpを算出する。更なる詳細は、非特許文献４を参照されたい。

このように、P_P（i,ｊ）に欠損値がある場合は、協調フィルタリングを利用してユーザの興味度の推定値を算出できる。一方、Pσ（i,ｊ）に欠損値がある場合は、上式（２）の分散の式においてn=0, k=0を代入した値を用いてよい。以上のように、ユーザの興味度の推定値と該推定値の不確かさは、ユーザのタスク実行の履歴情報に基づいて求められるため、好ましくは、興味度算出部４１４はその算出処理を、ユーザに対するタスクの提示に応答して、もしくはその提示により履歴情報が更新されることに応答して実行する。そして興味度算出部４１４は、算出した値を後に優先度算出部４１２が利用可能なように保存しておく。

不実行確率算出部４１６は、優先度算出部４１２による処理の依頼に応答して、複数種類のサービスの各々について、該サービスからのタスクを配分されている他のユーザにより該タスクが実行されていない確率である不実行確率を算出する。ここでサービスjからのタスクを配分されている他のユーザとは、優先度算出部４１２が現在対象とするユーザiを除く、サービスjからのタスクを配分されている全てのユーザを意味する。以下では、優先度算出部４１２がユーザiについて時刻Ｔに優先度算出処理を開始した際に、サービスjのタスクが実行されていない不実行確率をPw（ｊ,T）と表記する。また、サービスjからのタスクを配分されている全てのユーザの集合をU(j)と表記する。なお、集合U(j)は、サービスjのタスク情報に関連付けてタスク情報格納部４０６に格納されている実行者リストより求められる。

一般に、興味がありかつスキルが高いユーザに既にタスクを配分しているサービスは、すぐに実行される確率が高い。これは、あるサービスからのタスクが実行される確率は、該タスクに対するユーザの興味度とユーザのスキルの高さの積によって表すことができることを意味する。上述したように、本実施例では、ユーザkのサービスjへの興味は、各サービスのタスクをユーザが実行する確率で表した。ここでは更に、ユーザｋのサービスjに対するスキルを、ユーザkがタスクjを実行するのに要する時間で表す。そしてこの時間をポワソン仮定で表されるものと仮定し、ユーザkがタスクjを時間Δtの間に終わらせる確率をP_S(k,j,Δt)と表記する。

時刻ｔまでに、ある事象がr回起こるポアソン過程は以下の式（９）のように表される。

すると、ユーザｋのサービスjに対するスキル、即ち、ユーザkがタスクjを時間Δtの間に終わらせる確率P_S(k,j, Δt)は、r=1のポアソン仮定に該当するので、以下の式（１０）のように表される。

なお、λ_kjは、履歴情報格納部４１０に格納されるユーザkの履歴情報から単位時間当たりのタスク実行回数を計算することにより求める。即ち、λ_kjは、これまでユーザkがサービスjのタスクを実行するのにかかった総作業時間で、ユーザkが実行したサービスjのタスク数を割ることにより求められる。ここで、上記総作業時間は、タスクの完了時刻からタスクの実行開始時刻を差し引いた値を、サービスの識別情報が同一である全てのエントリについて足し合わせることにより算出される。なお、当該計算は、各ユーザが、いずれかのサービスのタスクを１つ実行する毎に行う。λ_kjに欠損値があった場合、即ち、ユーザkの履歴情報がないサービスがあった場合、ここでも協調フィルタリングを利用してλ_kjの推定値を算出してよい。なお協調フィルタリングを利用したλ_kjの推定値は、P_P（i,ｊ）に関して説明したのと同様の方法により算出可能であるため、ここでは繰り返しを避けるため説明を省略する。

そして不実行確率算出部４１６は、時刻Ｔにおいてサービスjからのタスクを配分されている他のユーザk（k∈U(j)）により該タスクが実行されていない確率である不実行確率Pw（ｊ,T）を、ユーザkのサービスjに対する興味度とスキルとの積を値１から差し引き、これを集合U(j)の全ユーザについて掛け合わせることにより算出する。言い換えると、不実行確率算出部４１６は、不実行確率Pw（ｊ,T）を、ユーザkがあるサービスjからのタスクを実行する確率と、優先度の算出の際（即ち、時刻Ｔ）にあるユーザkがあるサービスjからのタスクを完了している確率との積を値１から差し引き、これを集合U(j)の全ユーザについて掛け合わせることにより算出する。これを式に表すと以下式（１１）のようになる。

上式（１１）において、T(k)は、ユーザkがサービスjからのタスクを送信された時刻を示す。また、P_P（k,ｊ）は、式（１）により、P_s(k,j,T-T(k))は、式（１０）によりそれぞれ求められる。

上述したように興味度算出部４１４と不実行確率算出部４１６とによりそれぞれ値が算出されると、優先度算出部４１２は、ログイン検出部４０９によりそのログインが検出されたユーザiに対し、タスク情報格納部４０６に格納される複数種類のサービスの各々について、該サービスjからのタスクの優先度m(i,j)を、興味度算出部４１４により算出された興味度の推定値P_P（i,ｊ）と該推定値の不確かさPσ（i,ｊ）に基づき算出する。その際優先度算出部４１２は、同一のサービスjからのタスクを配分されている他のユーザにより同一のサービスからのタスクが実行されていない確率である不実行確率Pw（ｊ,T）を考慮する。

即ち、優先度算出部４１２は、推定値の不確かさPσ（i,ｊ）を、上記他のユーザにより同一のサービスjからのタスクが実行されていない不実行確率Pw（ｊ,T）で重み付けする。そして優先度算出部４１２は、サービスからのタスクの優先度m(i,j)を、重み付けした推定値の不確かさと興味度の推定値の和として算出する。これを式で表すと以下の式（１２）ようになる。

タスク決定部４１８は、優先度算出部４１２により算出された全サービスについてそのタスクの優先度m(i,j)を比較し、優先度の一番大きいサービスからのタスクをユーザiに提示すべきタスクとして決定する。そしてタスク決定部４１８は、決定したタスクを、通信部４０２を介してユーザiに送信し、提示する。ここで、タスクの提示は一例としてユーザiのコンピュータに導入されたＷｅｂブラウザの画面にカード形式で表示してよい。図６は、そのようなＷｅｂブラウザ６０２の画面に、またはクライアントアプリケーションの画面にカード形式で表示されたタスク情報６０４を示す。

優先度算出部４１２とタスク決定部４１８による上記処理は、ユーザiによるＷｅｂサーバ２０２ａへのログインに応答して実行され、ユーザiがログアウトするまで、定期的に繰り返し実行される。

次に、図７〜図９を参照して、本発明に係るタスク配分処理の流れを説明する。図７は、各ユーザiにタスクを配分するためのタスク配分処理の全体の流れを示すフローチャートである。図８は、図７に示すフローチャートのステップ７０２の優先度算出処理の流れを示すフローチャートである。図９は、タスク配分サーバがバックグラウンドで定期的に行う処理の流れを示すフローチャートである。

図７に示す各ユーザiにタスクを配分するためのタスク配分処理は、ステップ７００でユーザiのログインを検出することにより開始され、タスク配分サーバ４００は、続いてユーザiについて、タスク情報格納部４０６に格納されている各サービスのタスクの優先度を算出する。優先度算出処理の詳細は図８を参照して後述する。

続いて、タスク配分サーバ４００は、算出した優先度のうち最大の優先度のサービスjからのタスクをユーザiに対して提示すべきタスクとして決定し、これをユーザiに提示する（ステップ７０４）。この際タスク配分サーバ４００は、実行履歴情報格納部４１０に格納されるユーザiの実行履歴を更新し、ユーザiの実行履歴にサービスjのタスクを提示した事実を追加する。続いてタスク配分サーバ４００は、一定期間が経過するのを待ち、ユーザiからサービスjのタスクの実行結果を受信したか否かを判定する（ステップ７０６）。受信していない場合（ステップ７０６：ＮＯ）、タスク配分サーバ４００は、ユーザiの興味度の推定値と該推定値の不確かさを更新する。（ステップ７０８）

一方、ユーザiからサービスjのタスクの実行結果を受信した場合（ステップ７０６：ＹＥＳ）、タスク配分サーバ４００は、ユーザiの興味度の推定値と該推定値の不確かさに加えて、ユーザiのスキルを更新する（ステップ７１０）。なお、タスク配分サーバ４００は、ユーザiからサービスjのタスクの実行結果を受信すると、実行履歴情報格納部４１０に格納されるユーザiの実行履歴を更新し、ユーザiの実行履歴にサービスjのタスクを完了した事実を追加するものとする。

続いてタスク配分サーバ４００は、ユーザiがログイン状態を継続しているか否かを判定する（ステップ７１２）。ユーザiのログイン状態が継続している場合（ステップ７１２：ＹＥＳ）、処理はステップ７０２へ戻り、タスク配分サーバ４００は、優先度算出処理を繰り返す。ユーザiのログイン状態が継続していない場合（ステップ７１２：ＮＯ）、処理は終了する。

図８に示す優先度算出処理は、ステップ８００から開始し、タスク配分サーバ４００は、タスク情報格納部４０６に格納されている各サービスからのタスクについて、ユーザiの興味度の推定値と該推定値の不確かさが既に算出されている場合にはこれを読み出す。続いてタスク配分サーバ４００は、読み出しに成功したか否かを判定し（ステップ８０２）、読み出しに成功しなかった場合（ステップ８０２：ＮＯ）、改めて各サービスからのタスクについて、ユーザiの興味度の推定値と該推定値の不確かさを算出する（ステップ８０４）。

ステップ８０２において読み出しに成功した場合、又はステップ８０４から処理はステップ８０６へ進み、タスク配分サーバ４００は、各サービスjについて、該サービスjを既に配布されている他のユーザkが該サービスjからのタスクを実行していない確率である不実行確率を算出する。続いてタスク配分サーバ４００は、各サービスjについて、その不実行確率を考慮して、ユーザiの興味度の推定値と該推定値の不確かさに基づきサービスjからのタスクの優先度を算出する（ステップ８０８）。そして処理は終了する。

図９に示すタスク配分サーバ４００のバックグランド処理は、タスク配分サービスが開始するのと同時に開始し、タスク配分サーバ４００は一定時間待機する（ステップ９００）。続いてタスク配分サーバ４００は、各ユーザiの各サービスjに対する興味及びスキルについて一定以上の更新があったか否かを判定する（ステップ９０２）。

一定以上の更新がなかった場合（ステップ９０２：ＮＯ）、処理はステップ９００へ戻り、タスク配分サーバ４００は再び一定時間待機する。一方、一定以上の更新があった場合（ステップ９０２：ＹＥＳ）、タスク配分サーバ４００は、各ユーザiの各サービスjに対する興味及びスキルの欠損値をＭａｔｒｉｘＦａｃｔｏｒｉｚａｔｉｏｎにより予測する（ステップ９０４）。そして処理は終了する。

次に図１０〜１２を参照して、本発明が提案するタスク配分方法を利用したシミュレーションによる実験結果を基に、本発明の有効性を証明する。なお、シミュレーションの設定は次の通りである。
・シミュレータ内の単位時間は、実世界の秒に相当するものとする。
・ユーザは一定の確率でタスク配分サービスへのログイン・ログアウトを繰り返す。
・各ユーザは、平均的には３０分から３時間の間のランダムな時間でログイン・ログアウトを繰り返す。
・各サービスは一定の難易度を持っているとする。
・ユーザの間のスキルの違いを表すために、各ユーザが、各サービスのタスクを1回実行するのにかかる平均の時間は、正規分布で表した。
但し、上記の正規分布の標準偏差は (１０分―１０秒)/４とした。
また、上記の正規分布の平均はサービス間で異なり、５つのランダムな潜在因子の値のいずれかを平均とする正規分布からランダムに作られた値とする。この値はサービス間の難易度を表し、１０秒から１０分の間とする。
・ユーザの各サービスに関する興味の値に応じて、興味が無いタスクは高い確率で、タスクを実行せずにスキップする。
なお、スキップするのにかかる時間は、ユーザ毎にランダムに異なり、平均的には５秒から５分の間の時間のランダムな値とした。
・各ユーザの各サービスに対する興味の真の値は未知として、初期値は０．５とした。
・各ユーザの各サービスに対するスキルの真の値は未知として、初期値は最大値、最小値の間の値を正規分布からランダムに生成した。この正規分布の平均は、１０個のランダムな潜在因子の値のいずれかを平均とする正規分布からランダムに作られる。

実験はシミュレーションにおけるユーザ数、サービス数を様々な値に変更し、比較した。各サービスのタスク数は１０００とした。図１０は、異なるユーザ数におけるシミュレーションによる実験結果を示す。図１１は、異なるサービス数におけるシミュレーションによる実験結果を示す。図１２は、サービス数／ユーザ数を固定してタスク完了時間を比較した実験結果を示す。いずれにおいても以下の４種の手法について比較を行った。またいずれの図のグラフも横軸は、シミュレータ内における時間（秒）を表し、縦軸は各サービスのタスク完了率の平均を示す。
Ａ．ランダムにタスクを配分（“ランダム”）。なお、グラフにおいて計算値をひし形でを表示。
Ｂ．各ユーザの各サービスに対する実行履歴から上式（１）で興味を推定、各ユーザに興味が最大となるタスクを配分（“興味のみＣＦない”）。なお、グラフにおいて計算値を四角で表示。
Ｃ．Ｂ．と同様に各ユーザに興味が最大となるタスクを配分するが、定期的にMatrix Factorization による協調フィルタリングを用いて他のユーザの興味から、各ユーザのまだ実行していないサービスについての興味を推定する（“興味のみＣＦあり”）。なお、グラフにおいて計算値を三角で表示。
Ｄ．本発明によるタスク配分（“提案手法”）。なお、グラフにおいて計算値をバツ印で表示。

図１０（ａ）〜（ｃ）は、異なるユーザ数におけるシミュレーションによる実験結果を示す。なお、サービス数は２０に固定した。図１０（ａ）〜（ｃ）から、ユーザ数が十分に増えると、Ａ．のランダムなタスク配分による手法と、Ｂ．の興味のみを利用した手法の差分が少なくなっていくのが分かる。例えば、７０％のタスク終了時の時間で比較すると差分が小さくなっている（図中の矢印１０００、１００２，１００４参照）。１００％のタスク終了時の時間を比較すると更に差分が小さくなっている（図１０（ａ）中の矢印１００６が、図１０（ｂ）、（ｃ）ではほぼ無くなっている）。これは、ランダムなタスク配分でも、ユーザ数が十分に増えると興味があるユーザを見つける可能性が高くなるためと考えられる。本発明によるタスク配分は、スキルや他のユーザの実行状況をも考慮するため、ユーザ数が十分に多くても大きな効果がある。

図１１（ａ）〜（ｃ）は、異なるサービス数におけるシミュレーションによる実験結果を示す。なお、ユーザ数は４００に固定した。図１１（ａ）のグラフに示すように、サービス数が小さくユーザ数が大きい状況では、ランダムなタスク配分が興味のみ考慮した手法より完了時間が早い（図中の楕円１１００を参照）。また、サービス数が小さくユーザ数が大きい状況では、タスク完了時間についての本発明のタスク配分による効果は小さいが、大部分のタスクが終わるまでにかかる時間については、本発明のタスク配分による効果は大きい（図中矢印１１０４の長さは短いが、矢印１１０２の長さは長い）。

図１２（ａ）は、サービス数を１０に固定して全てのサービスのタスクが完了した時刻のみを比較した実験結果を示す。図１２（ｂ）は、ユーザ数を４００人に固定して全てのサービスのタスクが完了した時刻のみを比較した実験結果を示す。ユーザ数が大きく、サービス数が大きい状況が、本発明による効果が最も大きい。シミュレーションを行った範囲では、最大で１６％タスクの完了時間が短くなる（図１２（ｂ）中の楕円１２００を参照）。様々なクラウドソーシングのタスクを、モバイル端末、ポータル、メールクライアント等を利用して、多数のワーカーに配分する際には上記状況が満たされるため、本発明のタスク配分方法を採用することが望ましいといえる。なお、ＣＦとは協調フィルタリングを意味する。

以上、実施形態を用いて本発明の説明をしたが、本発明の技術範囲は上記実施形態に記載の範囲には限定されない。上記の実施形態に、種々の変更又は改良を加えることが可能であることが当業者に明らかである。例えば、サービスごとのユーザの興味度の推定値P_P（i,ｊ）に欠損値があった場合、上記説明ではＭａｔｒｉｘＦａｃｔｏｒｉｚａｔｉｏｎにより他のユーザの興味度の値から推測値を計算する方法を示した。しかし上式（５）においてPp は行列表現としたが、テンソルとして、ユーザの興味だけでなく、コンテキスト(連続して複数のタスクを実行しているか、作業している時間帯等)や、ユーザのプロファイルを利用することが可能である。（例えば非特許文献５を参照)。従って、そのような変更又は改良を加えた形態も当然に本発明の技術的範囲に含まれる。

なお、特許請求の範囲、明細書、及び図面中において示した装置、システム、プログラム、及び方法における動作、手順、ステップ、及び段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り任意の順序で実現しうることに留意すべきである。また、前の処理の出力を後の処理で用いる場合でも、前の処理と後の処理の間に他の処理が入ることは可能である場合があること、又は間に他の処理が入るように記載されていても前の処理を後の処理の直前に行うよう変更することも可能である場合があることも留意されたい。特許請求の範囲、明細書、及び図面中の動作フローに関して、便宜上「まず、」、「次に、」、「続いて、」等を用いて説明したとしても、この順で実施することが必須であることを必ずしも意味するとは限らない。

Claims

コンピュータの処理により複数種類のサービスからのタスクをユーザに配分するための方法であって、
（ａ）前記コンピュータが、前記複数種類のサービスの各々について、前記ユーザの前記サービスからのタスクの実行履歴から前記ユーザの興味度の推定値と該推定値の不確かさを算出するステップと、
（ｂ）前記コンピュータが、前記複数種類のサービスの各々について、前記興味度の推定値と該推定値の不確かさに基づいて前記サービスからのタスクの優先度を算出するステップであって、前記タスクの優先度は同一の前記サービスからのタスクを配分されている他のユーザにより前記同一のサービスからのタスクが実行されていない確率を考慮して算出される、前記ステップと、
（ｃ）前記コンピュータが、算出された前記優先度の一番大きいサービスからのタスクを前記ユーザに提示すべきタスクとして決定するステップと、
を含むタスク配分方法。
ステップ（ｂ）において、前記推定値の不確かさは、前記他のユーザにより前記同一のサービスからのタスクが実行されていない前記確率で重み付けされる、請求項１に記載のタスク配分方法。
ステップ（ｂ）において、前記優先度は、重み付けされた前記推定値の不確かさと前記興味度の推定値の和として算出される、請求項２に記載のタスク配分方法。
ステップ（ａ）において、サービスごとの前記ユーザの興味度の推定値は、前記ユーザが前記サービスからのタスクを実行する確率の推定値の平均として算出され、及び、前記推定値の不確かさは、前記推定値の標準偏差として算出される、請求項３に記載のタスク配分方法。
ステップ（ｂ）において、前記他のユーザにより前記同一のサービスからのタスクが実行されていない前記確率は、前記他のユーザの前記同一のサービスからのタスクに対する興味度と、前記他のユーザの前記同一のサービスからのタスクに対するスキルの高さとの積を値１から差し引き、これを全ての前記他のユーザについて掛け合わせることにより算出される、請求項４に記載のタスク配分方法。
ステップ（ｂ）において、前記他のユーザにより前記同一のサービスからのタスクが実行されていない前記確率は、前記他のユーザが前記同一のサービスからのタスクを実行する確率と、前記優先度の算出の際に前記他のユーザが前記同一のサービスからのタスクを完了している確率との積を値１から差し引き、これを全ての前記他のユーザについて掛け合わせることにより算出される、請求項４に記載のタスク配分方法。
ステップ（ａ）において、前記ユーザの実行履歴のないサービスについては、協調フィルタリングを利用して前記ユーザの興味度の推定値が算出される、請求項４に記載のタスク配分方法。
ステップ（ａ）は、前記ユーザに対するタスクの提示に応答して繰り返し実行され、前記コンピュータが、算出された前記ユーザの興味度の推定値と該推定値の不確かさとを次の優先度算出の際に利用可能なように保存するステップを更に含む、請求項２に記載のタスク配分方法。
ステップ（ｂ）は、前記ユーザによる前記コンピュータへのログインに応答して実行され、前記ユーザがログアウトするまで、前記コンピュータが、定期的にステップ（ｂ）及びステップ（ｃ）を繰り返すステップを更に含む、請求項２に記載のタスク配分方法。
前記コンピュータは、Ｗｅｂサーバであり、ステップ（ｃ）について、タスクの提示は、前記ユーザのコンピュータに導入されたＷｅｂブラウザ、またはクライアントアプリケーションにカード形式で表示される、請求項９に記載のタスク配分方法。
前記コンピュータは、Ｗｅｂサーバに接続しており、ステップ（ｂ）は、前記ユーザによる前記Ｗｅｂサーバへのログインに応答して実行され、及び、ステップ（ｃ）について、タスクの提示は、前記Ｗｅｂサーバを介して前記ユーザのコンピュータに導入されたＷｅｂブラウザ、またはクライアントアプリケーションにカード形式で表示される、請求項２に記載のタスク配分方法。
前記ユーザが前記Ｗｅｂサーバをログアウトするまで、前記コンピュータが、定期的にステップ（ｂ）及びステップ（ｃ）を繰り返すステップを更に含む、請求項１１に記載のタスク配分方法。
ステップ（ｃ）について、前記コンピュータが、前記優先度が所定の閾値を超えることを条件として、決定された前記タスクを前記ユーザにアラート通知するステップを更に含む、請求項１０又は１１に記載のタスク配分方法。
請求項１乃至１３のいずれか一項に記載のタスク配分方法の各ステップを、前記コンピュータに実行させるタスク配分プログラム。
複数種類のサービスからのタスクを配分するタスク配分サーバであって、
ユーザのログインを検出する検出部と、
ユーザごと各サービスからのタスクの実行履歴を格納する履歴格納部と、
前記複数種類のサービスの各々について、そのログインを検出した前記ユーザの前記サービスからのタスクの実行履歴から前記ユーザの興味度の推定値と該推定値の不確かさを算出する興味度算出部と、
前記複数種類のサービスの各々について、該サービスからのタスクを配分されている他のユーザにより前記タスクが実行されていない確率である不実行確率を算出する不実行確率算出部と、
前記複数種類のサービスの各々について、該サービスからのタスクの不実行確率を考慮して、前記ユーザの前記興味度の推定値と該推定値の不確かさに基づいて前記サービスからのタスクの優先度を算出する優先度算出部と、
前記算出された前記優先度の一番大きいサービスからのタスクを前記ユーザに配分すべきタスクとして決定するタスク決定部と、
を含むタスク配分サーバ。
前記優先度算出部は、前記推定値の不確かさを前記不実行確率で重み付けして前記優先度を算出する、請求項１５に記載のタスク配分サーバ。
前記優先度算出部は、重み付けされた前記推定値の不確かさと前記興味度の推定値の和として前記優先度を算出する、請求項１６に記載のタスク配分サーバ。
前記興味度算出部は、サービスごとの前記ユーザの興味度の推定値を、前記ユーザが前記サービスからのタスクを実行する確率の推定値の平均として算出し、及び、前記推定値の不確かさを、前記推定値の標準偏差として算出する、請求項１５に記載のタスク配分サーバ。
前記不実行確率算出部は、前記不実行確率を、前記他のユーザの前記サービスからのタスクに対する興味度と、前記他のユーザの前記サービスからのタスクに対するスキルとの積を値１から差し引き、これを全ての前記他のユーザについて掛け合わせることにより算出する、請求項１５に記載のタスク配分サーバ。
前記不実行確率算出部は、前記不実行確率を、前記他のユーザが前記サービスからのタスクを実行する確率と、前記優先度の算出の際に前記他のユーザが前記サービスからのタスクを完了している確率との積を値１から差し引き、これを全ての前記他のユーザについて掛け合わせることにより算出する、請求項１５に記載のタスク配分サーバ。