JP2016162332A - タスク管理方法およびサーバ - Google Patents

Abstract

【課題】コンテン提供サイト３から利用者端末１へのコンテンツ配信を利用者によるタスク処理を条件に許可する。【解決手段】タスク管理サーバ２において、履歴DB２０２には、利用者から要求されたコンテンツ、当該要求に対して要請したタスクおよび当該タスク処理の結果を含む履歴情報が蓄積される。分析機能部２０４は、前記履歴情報を分析し、利用者に関連したコンテンツに基づいてタスクを選択するルールを策定する。タスク選択部２０５は、利用者端末１から、配信を要求するコンテンツに固有のコンテンツIDを含むタスク要求を受信すると、当該コンテンツIDをルールに適用してタスクを選択し、その処理を利用者端末１へ要請する。サービス提供決定部２０７は、前記処理結果の取得に応答してサービス提供サイト３へコンテンツ配信を許可する。サービス提供サイト３は、許可されたコンテンツをネットワーク経由で利用者端末１へ配信する。【選択図】図１

Description

本発明は、ネットワークを介したサービスの提供を要求する利用者へタスクの処理を要請し、処理結果の返信を条件にサービスの提供を許可するタスク管理方法およびサーバに係り、特に、利用者により多くのタスクを効率的に処理させることができるタスク管理方法およびサーバに関する。

アンケート調査への回答、映像への単語のタグ付け、あるいは簡単な要約作業のように、高度な知識や技術は必要としないものの処理量が膨大なタスクを迅速かつ低コストで処理したいという要望がある。

一方、動画サイトの普及に伴い、コンテンツの配信に先だってコマーシャル映像を配信し、その視聴を条件にコンテンツの視聴制限を解除するビジネスモデルが普及している。

特許文献１には、Webサイトを活用して、タスク調査を行うシステムが開示されている。特許文献１では、Webサイトの閲覧前にタスク画面をコンテンツに重畳して表示することで閲覧制限を実現している。

特開2012-022604号公報

利用者へ要請するタスクの難易度が高くなると、これを処理できる利用者と処理できない利用者とが現れ、処理できない利用者はコンテンツ視聴を含む各種のサービスを享受することができず、またタスク処理の要請側もタスク処理結果を得られないので、タスクを効率的に処理することができない。

ここで「各種のサービス」とは、映画や写真などのコンテンツ配信や、ゲームやコミュニケーションなどへの参加権、会員ページなどの許可が必要なデータベースへのアクセス権限、などのネットワークを介したサービス全般を指す。

従来技術では、利用者の個性を考慮せず、ランダムに様々なタスクを割り当てていたので、能力の低い利用者へ難易度の高いタスクが割り当てられてしまい、タスクの処理結果を得られない場合があるという技術課題があった。

本発明の目的は、上記の技術課題を解決し、サービスの提供を要求する利用者に対して、その能力に適したタスクが割り当てられるようにすることで、大量のタスクを効率よく処理できるタスク管理方法およびサーバを提供することにある。

上記の目的を達成するために、本発明は、サービスの提供を要求する利用者へ、サービス提供の条件となるタスク処理を要請し、処理結果が返信されるとサービス提供を許可するタスク管理サーバにおいて、以下の構成を具備した点に特徴がある。

(1) 利用者から要求されたサービス、当該要求に対して要請したタスクおよび当該タスク処理の結果を履歴情報として蓄積する履歴DBと、履歴情報を分析して、利用者に関連したサービスからタスクを選択するルールを策定する手段と、利用者端末から、要求するサービスに固有のサービスIDを含むタスク要求を受信する手段と、前記サービスIDを前記ルールに適用してタスクを選択し、その処理を利用者端末へ要請する手段とを具備した。

(2) 利用者端末から取得した処理結果を履歴DBに登録する手段を更に具備した。

本発明によれば、各利用者が要求したサービスの属性と当該利用者のタスク処理に関する実績との関係を分析することで、利用者と関連性のあるサービスとタスクの処理能力との潜在的な関連性を識別できる。したがって、各利用者が要求したサービスや利用履歴のあるサービスに基づいて、当該利用者への依頼が好適なタスクを簡単に選択できるようになり、その結果、タスク処理の報酬としてサービスの提供を許可するモデルにおいて、大量のタスク処理を効率良く行えるようになる。

本発明の一実施形態の構成を示した機能ブロック図である。 ３人の利用者U1，U2，U3に関する履歴情報の一例を示した図である。 本発明の一実施形態の動作を示したシーケンスフローである。 本発明の一実施形態におけるタスク管理サーバの動作を示したフローチャートである。

以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明の一実施形態の構成を示した機能ブロック図であり、ここでは、利用者が要求するサービスとして、コンテンツ配信を例にして説明する。

利用者端末１は、利用者の入力操作を受け付ける入力操作子１０１および配信されたコンテンツを表示するディスプレイ１０２を備えた汎用のコンピュータであり、コンテンツの再生、および依頼されたタスクを処理するユーザインタフェースとしてWebブラウザを実装している。

タスク管理サーバ２は、コンテンツ配信を要求した利用者へ、タスク依頼者から依頼されたタスク処理を要請し、タスクの処理結果を返信した利用者に対して、その報酬としてコンテンツ配信を許可する。本発明のタスク管理サーバ２は、汎用のコンピュータやサーバに各機能を実現するアプリケーション（プログラム）を実装することで構成できる。あるいはアプリケーションの一部がハードウェア化またはROM化された専用機や単能機としても構成できる。

サービス提供サイト３は、多数のコンテンツを蓄積したコンテンツサーバ３０１を含み、利用者端末１から要求されたコンテンツを、タスク管理サーバ２からのタスク完了通知に応答してネットワーク経由で配信する。サービス提供サイト３は、例えば配信可能なコンテンツのジャンルごとに複数用意されており、利用者端末１は所望のコンテンツを蓄積しているサービス提供サイト３を選んでコンテンツ配信を要求する。

前記タスク管理サーバ２において、タスクDB２０１には、複数のタスク依頼者４から処理を依頼された多数のタスクが蓄積されている。依頼されるタスクには、利用者に静止画像を提示して、写っているオブジェクトや色に関する単語のタグ付を行わせる画像タグ付タスク、利用者に外国語テキストの一部を提示して、その翻訳文を入力させる翻訳タスク、利用者に長文の一部を提示して、その要約を入力させる要約タスク、利用者に映像の一部分を提示して、写っている者や人物名あるいは会話の要約にタグ付を行わせる映像タグ付タスク、質問に対して解答させるアンケートタスクなどがある。

履歴DB２０２は、コンテンツ配信の要求履歴がある利用者ごとに、要求されたコンテンツの名称、タイトル、型番などの識別子やコンテンツの内容、ジャンル、価格などの属性（以下、全て属性で代表する）、当該要求に対して処理を要請したタスクの種別、および当該タスクの処理実績を対応付けて管理する。

図２は、３人の利用者U1，U2，U3に関して履歴DB２０２に登録された履歴情報の一例を示した図である。

各レコードには、各タスクに固有の識別子（タスクID）と、各コンテンツの属性に固有の識別子（コンテンツID）と、各タスクの具体的な内容と、処理を要請したタスクの処理結果とが登録されている。なお、処理結果の（未回答）とは、タスクの処理を要請してから所定時間が経過しても利用者から処理結果が返信されなかったケースである。

分析機能部２０４は、前記履歴DB２０２が管理する対応関係に基づいて、コンテンツID、利用者IDおよびタスクIDと、当該タスク処理の実績との対応関係を分析し、各利用者へ要請するタスクの優先ルールを策定してルールDB２０３へ蓄積する。

例えば、前記図２に示した履歴情報を対象とした分析であれば、タスク処理率に注目すると、利用者U1は、要請された７つのタスクのうち５つのタスクを処理済みなので、そのタスク処理率は5/7=71.4％となる。同様に、利用者U2のタスク処理率は4/5=80％となり、利用者U3のタスク処理率は3/5=60％となる。

また、コンテンツ別にタスク処理率を比較すると、コンテンツAAAのタスク処理率は4/5=80％となり、コンテンツJJJのタスク処理率は1/3=33.3％となる。

さらに、タスク別にタスク処理率を比較すると、タスクaの処理率には偏りがなく、かつ8/9=88.9％となって高い値を示している。タスクbの処理率には偏りがあり、例えば、利用者U2の処理率は2/2=100％であるのに対して、利用者U1，U3の処理率はいずれも0％となっている。

このような分析を多数の履歴情報を対象にして行い、例えば「コンテンツAAAを視聴する利用者のタスク処理率は相対的に高い」、「コンテンツBBBを視聴する利用者のタスク処理率は相対的に低い」という分析結果が得られたならば、以下のようなルールを策定できる。

ルール１：コンテンツAAAを要求している利用者には複数のタスクを要請する。
ルール２：コンテンツAAAの視聴履歴（コンテンツ配信サービスの利用履歴）がある利用者には複数のタスクを要請する。
ルール３：コンテンツBBBを要求している利用者には一つのタスクを要請する。
ルール４：コンテンツBBBの視聴履歴がある利用者には一つのタスクを要請する。

また、例えばタスクａに関して、「コンテンツCCCを視聴する利用者のタスク処理率は相対的に高い」、「コンテンツDDDを視聴する利用者のタスク処理率は相対的に低い」という分析結果が得られたならば、以下のようなルールを策定できる。

ルール５：コンテンツCCCを要求している利用者にはタスクａを優先的に要請する。
ルール６：コンテンツCCCの視聴履歴がある利用者にはタスクａを優先的に要請する。
ルール７：コンテンツDDDを要求している利用者にはタスクａを要請しない。
ルール８：コンテンツDDDの視聴履歴がある利用者にはタスクａを要請しない。

さらに、例えばタスクｂに関して、「コンテンツAAAおよびCCCを視聴する利用者のタスク処理率は相対的に高い」、「コンテンツAAAおよびDDDを視聴する利用者のタスク処理率は相対的に低い」という分析結果が得られたならば、以下のようなルールを策定できる。

ルール９：コンテンツAAAおよびCCCの一方の視聴履歴があって他方を要求している利用者にはタスクｂを優先的に要請する。
ルール１０：コンテンツAAAおよびDDDの一方の視聴履歴があって他方を要求している利用者にはタスクｂを要請しない。

なお、利用者が要求したコンテンツに関連した履歴や利用者自身に関する履歴が履歴DB２０２に存在しない場合のために、要求されているコンテンツとは無関係に、以下のようなルールを一般的なルールとして策定し、補助的に用いても良い。

ルール１１：タスク処理率のより高い利用者により多くのタスクを要請する。
ルール１２：利用者に関わらず処理率の高いタスクは誰にでも割り当てられる。
ルール１３：新規タスクはタスク処理率のより高い利用者に優先的に割り当てる。

また、履歴DB２０２に基づいて、「コンテンツを午後に要求する利用者のタスク処理率は相対的に高い」という分析結果が得られたならば、以下のようなルールを策定しても良い。
ルール１４：午後はタスク処理率の高いタスクを割り当てる。

さらに、利用者がコンテンツを要求した際の所在地を、利用者端末に実装されたGPS測位機能や複数の無線基地局からの距離に基づく測位機能により認識でき、例えば、駅に所在する利用者のタスク処理率は低い」という分析結果が履歴DB２０２から得られたならば、以下のようなルールを策定しても良い。
ルール１５：所在地が駅の利用者には処理率の低いタスクを優先的に割り当てる。

タスク選択部２０５は、利用者が要求したコンテンツの属性、当該要求した利用者の識別子、時刻情報あるいは位置情報等を各ルールに適用することで少なくとも一つのタスクを選択し、その処理を利用者端末１へ要請する。適用するルールは一つに限定されるものではなく、複数のルールを組み合わせて適用しても良い。

利用者端末１では、タスク管理サーバ２から要請されたタスクを利用者が処理し、その処理結果が、タスク管理サーバ２へネットワーク経由で返信されてタスク依頼者４へ提供される。

履歴登録部２０６は、タスクの処理結果を利用者端末１から受信して履歴DB２０２に蓄積する。本実施形態では、利用者へ要請したタスクの処理結果が所定の時間内に返信されると、そのタスクID、コンテンツIDおよび利用者IDが、タスクの処理結果と対応付けられて蓄積される。なお、タスク処理を要請してから所定の時間内に処理結果が得られない場合は、未回答である旨が登録される。

サービス提供決定部２０７は、処理を要請した利用者端末１からタスクの処理結果が返信されると、利用者端末１に対してロック解除を通知する一方、サービス提供サイト３に対してタスク完了を通知する。これにより、不正なコンテンツ要求を排除するためのロック機能が解除されるので、利用者端末１によるコンテンツ要求が可能になり、サービス提供サイト３は、要求されていたコンテンツをコンテンツサーバ３０１から読み出して利用者端末１へ配信することが可能になる。

図３は、本発明の一実施形態の動作を示したシーケンスフローであり、図４は、当該シーケンスにおけるタスク管理サーバ２の動作を示したフローチャートである。

時刻t1では、利用者端末１からサービス提供サイト３へ、コンテンツ要求のメッセージが送信される。この要求メッセージには、配信を要求するコンテンツの属性に固有のコンテンツIDが記述されている。

時刻t2では、サービス提供サイト３から利用者端末１へ、タスク表示用のHTMLおよび利用者にタスクを処理させるためのタスクプログラム（JavaScript（登録商標）、Flash等）が応答される。前記タスクプログラムは、サービス提供サイト３からコンテンツを取得してブラウザへ提供する機能を備えるが、この時点では当該機能がロックされている。

時刻t3では、前記タスク表示用HTMLおよびタスクプログラムにより、利用者端末１からタスク管理サーバ２へタスク要求のメッセージが送信される。この要求メッセージには、前記コンテンツIDおよび利用者IDが記述されている。

タスク管理サーバ２は、図４のステップS１において、当該タスク要求を検知すると、ステップS２では、当該メッセージに記述されているコンテンツIDおよび利用者IDを識別する。ステップS３では、前記タスク選択部２０５が、前記タスク要求メッセージに記述されていたコンテンツIDおよび利用者IDを、前記ルールDB２０３に蓄積されているルールに適用することで少なくとも一つのタスクを選択する。

ステップS４では、前記選択されたタスクの処理を利用者へ要請するメッセージが構築され、時刻t4において利用者端末１へ送信される。時刻t5において、利用者が利用者端末１を操作して前記要請されたタスクを適宜に処理すると、時刻t6において、その処理結果がタスク管理サーバ２へ返信される。

タスク管理サーバ２は、ステップS５において前記処理結果の返信を検知すると、ステップS６では、時刻t7において、前記処理結果がタスク依頼者４へ提供される。ステップS７では、前記サービス提供決定部２０７により、利用者端末１へロック解除が通知（時刻t8）される。これにより、タスクプログラムにおけるコンテンツ取得のロックが解除されるので、利用者端末１はサービス提供サイト３へコンテンツ配信を要求できるようになる。

ステップS８では、前記サービス提供決定部２０７により、サービス提供サイト３へタスクの完了が通知（時刻t9）される。ステップS９では、利用者が要求したコンテンツのID、当該利用者に要請したラスクのIDおよびその処理結果が、前記履歴登録部２０６により履歴DB２０２に蓄積される。

なお、ステップS５において処理結果の返信が検知されず、ステップS１２でタイムアウトすると直ちにステップS９へ進み、処理結果が「未回答」の履歴情報が履歴DB２０２に蓄積されることになる。

ステップS１０では、前記分析機能部２０４により履歴DB２０２が分析されてルールが策定される。ステップS１１では、前記策定されたルールがルールDB２０３へ更新登録される。

これらの処理と並行して、時刻t10では、利用者端末１からサービス提供サイト３へ改めてコンテンツ要求が送信される。時刻t11では、サービス提供サイト３において当該利用者によるコンテンツ配信の正当性が判定され、ここでは前記時刻t9でタスク完了通知を受信しているので、時刻t11において、コンテンツサーバ３０１から前記コンテンツが配信される。時刻t12では、利用者端末１において前記コンテンツの再生が開始される。

なお、上記の実施形態ではコンテンツの配信前にタスク処理を要請し、その処理結果が返信されたことを条件にコンテンツ配信を許可するものとして説明したが、本発明はこれのみに限定されるものではなく、コンテンツの配信要求に対してコンテンツの一部（例えば、連続ドラマの第１話のみ）を配信すると共にタスク処理を要請し、タスク処理結果の返信を条件に残りのコンテンツ（第２話以降）の配信を許可するようにしても良い。

さらに、上記の実施形態では、利用者がタスク処理の結果をタスク管理サーバ２へ返信すると、利用者端末１へのコンテンツ配信がタスク管理サーバ２により許可されるものとして説明した。しかしながら、本発明はこれのみに限定されるものではなく、利用者端末１のタスクプログラムが、タスク管理サーバ２へタスク処理結果が返信されたことに応答して当該利用者端末１によるコンテンツ配信の要求を許可し、これにより利用者端末１がコンテンツサーバ３０１へコンテンツ配信を要求できるようにしても良い。

本実施形態によれば、各利用者が要求したコンテンツの属性と当該利用者のタスク処理に関する実績との関係を分析することで、コンテンツとタスクの処理能力との潜在的な関連性を識別できる。したがって、各利用者が要求したコンテンツや視聴履歴のあるコンテンツに基づいて、当該利用者への要請が好適なタスクを簡単に選択できるようになり、その結果、タスク処理の報酬としてコンテンツ配信を許可するモデルにおいて、タスク処理を効率良く行えるようになる。

１…利用者端末，２…タスク管理サーバ，３…サービス提供サイト，２０１…タスクDB，２０２…履歴DB，２０３…ルールDB，２０４…分析機能部，２０５…タスク選択部，２０６…履歴登録部，２０７…サービス提供決定部，３０１…コンテンツサーバ

Claims (13)

1. ネットワークを介したサービスの利用者へタスクの処理を要請するタスク管理サーバにおいて、
   利用者から要求されたサービス、当該要求に対して要請したタスクおよび当該タスク処理の結果を含む履歴情報を蓄積する履歴DBと、
   前記履歴情報を分析し[GH1]、利用者に関連したサービスに基づいてタスクを選択するルールを策定する分析手段と、
   利用者からのタスク要求に応答して、当該利用者に関連したサービスを前記ルールに適用してタスクを選択するタスク選択手段と、
   前記選択されたタスクの処理を利用者へ要請する手段とを具備したことを特徴とするタスク管理サーバ。
2. 前記利用者からのタスク処理結果の取得に応答してサービスの提供を許可するサービス提供決定手段を更に具備したことを特徴とする請求項１に記載のタスク管理サーバ。
3. 前記タスク要求が配信を要求するサービスの識別子を含み、
   前記タスク選択手段は、前記サービスの識別子を前記ルールに適用してタスクを選択することを特徴とする請求項１または２に記載のタスク管理サーバ。
4. 前記タスク選択手段は、前記利用者の利用履歴にあるサービスの識別子を前記ルールに適用してタスクを選択することを特徴とする請求項１または２に記載のタスク管理サーバ。
5. 前記取得した処理結果を履歴DBに登録する履歴登録手段を更に具備したことを特徴とする請求項１ないし４のいずれかに記載のタスク管理サーバ。
6. 前記分析手段は、タスク処理率が高い利用者の利用履歴にあるサービスを要求した利用者に対してより多くのタスクを割り当てるルールを策定することを特徴とする請求項１ないし５のいずれかに記載のタスク管理サーバ。
7. 前記分析手段は、タスク処理率が低い利用者の利用履歴にあるサービスを要求した利用者に対してより少ないタスクを割り当てるルールを策定することを特徴とする請求項１ないし６のいずれかに記載のタスク管理サーバ。
8. 前記分析手段は、所定のタスクに関して処理率が高い利用者の利用履歴にあるサービスを要求した利用者に対して当該所定のタスクを割り当てるルールを策定することを特徴とする請求項１ないし７のいずれかに記載のタスク管理サーバ。
9. 前記分析手段は、所定のタスクに関して処理率が低い利用者の使用履歴にあるサービスを要求した利用者に対して当該所定のタスクを割り当てないルールを策定することを特徴とする請求項１ないし８のいずれかに記載のタスク管理サーバ。
10. ネットワークを介したサービスの利用者へタスクの処理を要請するタスク管理方法において、
    タスク管理サーバが、利用者から要求されたサービス、当該要求に対して要請したタスクおよび当該タスク処理の結果を含む履歴情報を分析し、利用者に関連したサービスに基づいてタスクを選択するルールを策定する手順と、
    利用者が、タスク管理サーバへタスク要求を送信する手順と、
    タスク管理サーバが、前記タスク要求を送信した利用者に関連したサービスを前記ルールに適用してタスクを選択する手順と、
    タスク管理サーバが、前記選択されたタスクの処理を前記利用者へ要請する手順とを含むことを特徴とするタスク管理方法。
11. 前記利用者が、前記要請されたタスクの処理結果をタスク管理サーバへ返信する手順と、
    タスク管理サーバが、前記処理結果の返信に応答してサービスの提供を許可する手順と、
    サービス提供サーバが、前記許可に応答して、前記利用者へサービスを提供する手順とを含むことを特徴とする請求項１０に記載のタスク管理方法。
12. 前記利用者が、前記要請されたタスクの処理結果をタスク管理サーバへ返信する手順と、
    前記利用者が、前記返信に応答して前記サービス提供サーバへサービスの提供を要求する手順と、
    前記サービス提供サーバが、前記配信要求に応答して、前記利用者へサービスを提供する手順とを含むことを特徴とする請求項１０に記載のタスク管理方法。
13. 前記タスク管理サーバが、前記返信された処理結果に基づいて前記履歴情報を更新する手順を更に含むことを特徴とする請求項１０ないし１２のいずれかに記載のタスク管理方法。