JP2010534372A - 検索関連タスクに対する事実上の即時支払に関するシステム - Google Patents

Abstract

本文で論じられる例は、検索者が検索を実施し、完了した検索又はその他の検索関連タスクに基づいて現金又は非現金報酬の形で収入を得ることができる検索システム及び、銀行のような検索者が事実上即時に勤労所得の支払を受け取ることができる関連支払システムを提供する。検索者が検索を完了した時、検索システムにある検索者の口座に収入が記入される。検索者からのリクエストがあり次第、支払金額が指定されたグラフィカルユーザーインターフェースを使用して、支払金額に対応した勤労所得が、検索システムから支払システムに送信された口座クレジットリクエストによって実質上即時に支払いシステムの検索システム口座から支払システムの検索者の口座へと送金される。検索システムにある検索者の口座は支払い金額のためにデビットされる。支払システムで、デビットカードで購入やＡＴＭでデビットカードで現金を引落すといったように、購入するために検索者が勤労所得を使用することができる。
【選択図】なし

Description

関連出願の相互参照
この出願は、“Ａ Ｓｙｓｔｅｍ Ｆｏｒ Ｓｕｂｓｔａｎｔｉａｌｌｙ Ｉｍｍｅｄｉａｔｅ Ｐａｙｍｅｎｔ Ｆｏｒ Ｓｅａｒｃｈ Ｒｅｔｌａｔｅｄ Ｔａｓｋｓ”という題名で発明者Ｓｃｏｔｔ Ａ．Ｊｏｎｅｓにより２００７年７月２４日に米国特許商標庁に出願された米国特許出願第１１／７８２，２７５号、及び“Ａ Ｓｙｓｔｅｍ Ｆｏｒ Ｉｍｍｅｄｉａｔｅ Ｐａｙｍｅｎｔ Ｆｏｒ Ｐｉｅｃｅｗｏｒｋ”という題名で発明者ｓｃｏｔｔ Ａ．Ｊｏｎｅｓにより２００６年７月２４日に米国特許商標庁に出願された米国仮特許出願第６０／８２０，１７９号に関するもので、その優先権の利益を主張し、上記総ての出願の文献を援用する。

本文に描かれた例は、作業員が検索又はその他のネットワークベースタスクを実施し、そのタスクに対して即時に支払を受け取ることを可能にするシステムに導かれたものである。

情報処理業界の作業員は、しばしばコンピュータベースタスク又はマイクロタスクを行う。かかるタスクはユーザクエリ、写真認識（Ａｍａｚｏｎ（登録商標）Ｍｅｃｈａｎｉｃａｌ Ｔｕｒｋによる）又は区分、スピーチからテキストへの転写、テキストからスピーチへの変換、クレジットカード所有者のアカウント状態に関する質問に回答といったようなアカウントに関する情報への質問の回答、又は銀行のバックオフィスでの国際貿易取引の実行に基づく情報の検索の実施に関わるものである場合がある。このようなタイプのタスクは、電子請負タスクと呼ばれることがあり、作業員は請負作業ベースで支払を受け取る、すなわち完了したタスクに基づいて支払を受けてよい。かかる作業が、小切手又は小切手口座に電子送金にて２週間毎といったように周期ベースで支払われることもしばしば一般的である。

かかる作業員の中には、各タスクの完了後又は作業員が支払を受けたいと要求した時に即時に支払を受け取りたいと望むものもいる。例えば、多くの電子請負タスクを行った若者がデートに出かける時に映画に行きたいと思ったが、映画代金を支払うだけの手持ちの金がなく、小切手口座の残高も少なすぎることが判明することがある。若者は請負作業に対する支払を即時に受け取り、自分が貯めた収入に即時アクセスできれば映画に行けると考えるだろう。

その夜に映画に行きたいと考えており、自分が映画に行く十分な金がないことが判明し、よってその日に金を稼ぐために請け負い作業を行っているといったようなかかる作業員は自分が望むことができるだけの十分な金を得るという望みをもっており、自分が欲しい金額を稼ぐまで働く場合がある。例えば、あるタスクにおいて、マイルストーンが完了した時又は収入の割合に応じた取引手数料を減らすため特定の閾に貯めた資金が到達した時及び／又はより効率的に資金を管理するため（例、遅延金の支払を避けるため支払期限日に支払をするが資金に最大の利益が生じるようにする、又は現金を最大活用するためタスクが完了した直後に１つ以上の口座に資金を振り込む）といったように、場合によっては特定の条件が満たされる場合作業員は現金での支払受け取りを望むこともあるだろう。

かかる請負タスクを行わないその他のタイプの作業員も、自分が完了した作業に対して即時支払を受け取ることを望むこともあるだろう。

必要なものは活動に対してかかる即時支払を実行するシステムである。

作業員がタスクが完了及び／又はその他の条件が見合った時に、自分が行ったタスクに対して即時支払を受け取ることを可能にするシステムを提供することが、本文で論じられる例の観点である。

作業員又は検索者を彼らが検索結果を完了した時点で貸し方に記入するシステムを提供することが、本文で論じられる例のもう１つの観点である。

デビットカードのような電子カードを使用して作業員が支払所得ではなく勤労所得を利用することを可能にするシステムを提供することが、本文で論じられる例のもう１つの観点である。

本文で論じられる例は、検索者が検索を実施し、完了した検索に基づいて収入を得ることができる検索システム及び、検索者が事実上即時に勤労所得の支払を受け取ることができる支払システムを提供する。検索者（又は作業員）が検索（又はタスク）を完了した時、検索システムにある検索者の口座に収入が記入される。検索者からのリクエストがあればすぐに、電子カードを使って購入ができるといったように、検索者が購入のために金を使用することができる検索者の支払システム口座へ勤労所得が振込まれる。リクエストは明確に事前に確立された一連の条件に従って行われる場合がある。

以下に明らかになるその他の態様及び利点と共に、前記の態様及び利点は、以下に詳細に記載され、特許請求の範囲に記載される構成及び動作の詳細にあり、この一部を形成する添付図面に参照が行われる。添付図面において、同様の参照符号は同様の部分を示す。

図１は、本文で論じられる例に従ったシステムを説明している。 図２は、転送プロセスを説明している。 図３は、転送プロセスのリクエストを説明している。 図４は、データベースを説明している。 図５は、グラフィカルユーザインタフェースを表示している。 図５Ａは、グラフィカルユーザインタフェースを表示している。 図５Ｂは、グラフィカルユーザインタフェースを表示している。 図６は、グラフィカルユーザインタフェースを表示している。 図７は、グラフィカルユーザインタフェースを表示している。 図８は、プロセスを説明している。 図９は、グラフィカルユーザインタフェースを表示している。

典型的なガイドベース検索において、ユーザコンピュータシステム１１２（又はＰＤＡタイプデバイス、又はクエリの送信が可能なその他のデバイス）を使用して情報１１０（図１）を探している人物が、検索システム１１４にクエリを送信するものであり、“Ａ Ｓｃａｌａｂｌｅ Ｓｅａｒｃｈ Ｓｙｓｔｅｍ Ｕｓｉｎｇ Ｈｕｍａｎ Ｓｅａｒｃｈｅｒｓ”という題で発明者Ｓｃｏｔｔ Ａ．Ｊｏｎｅｓにより２００６年１月２３日に米国特許商標庁に出願された米国出願第１１／３３６，９２８に記載のように、インターネットのようなコミュニケーションネットワーク１１６に関して、参照文として本文にその発明が編入してある。 検索システム１１４はクエリ又は検索タスクをガイド又は検索者１１８に割り当て、クエリを検索者コンピュータシステム１２０に転送する。検索者１１８は、Ｙａｈｏｏ！（登録商標）といったような検索エンジンを活用した検索及び／又は、検索者１１８がまとめた及び／又はＷｅｂＭＤ（登録商標）（医療情報用）やＥＳＰＮ（登録商標）（スポーツ情報用）といったようなサービスからの情報といったようなその他のリソースの検索を実施することで、クエリに適切な情報を得るため検索者コンピュータシステム１２０を使用する。検索が実施される間、情報探索者１１０は広告や広告サーバ１２２からクエリに適切であるその他の情報を提供されてもよい。検索が完了した時、検索者は検索結果をユーザ（又はＩｎｆｏｓｅｅｋｅｒ（登録商標））コンピュータ１１２（図１）に送信してよい。検索システム１１４は、情報探索者によって提示され、使用され及び／又は購入された検索、広告、その他の情報に対して支払を受けることができる。

検索が完了した時、検索システム１１４は、ある支払方法／計算式を使用して検索／タスクの完了に対するクレジット（又は支払）を、検索データベース１２４（図１）における検索者検索システム口座（図４を参照）のクレジットすることができる。例えば、検索者口座に、完了検索１件につき１時間５ドルのレートでクレジットされてよい。或いは、検索者が検索１件につき１０セント又はその他の給与計算方法で支払を受けるかもしれない。検索者が作成した資料が情報探索者によってアクセスされた時に、検索者はロイヤルティタイプの支払を受け取ってもよい。また検索者は検索者のトレーニング及び／又は検索者の検討及び／又は格付け、及び／又は検索者が作成した作業に対して支払を受け取ってもよい。また、募集を行った検索システムに登録した企業も、スポンサーした作業員によって行われた作業に対してクレジットを獲得してもよい。一般的に、2週間おきといったように定期的に、オンラインやオフラインで働く作業員の給与支払でよく知られている技術にあるように、検索システム１１４はデフォルトでバッチプロセスの給与小切手を検索者１１８に発行してよい。検索活動又は検索者のトレーニング、検索結果の検証、検索者のリクルートといったようなその他の活動に関連した検索、又はその他の活動に対して、作業員及び／又は企業は収入を得てよい。作業期間終了後、作業員及び／又は企業は作業に対して支払を得ることができる。

給与小切手を待つよりも、検索者１１８は実質的に即時に検索システム１１４にある検索者の口座から支払を要求することができる。実質的に即時の支払とはどのようなことを意味するかというと、給与小切手や電子送金振込よりも速く、一般的に注文して１５分以内、しばしば１５秒以内に、望むらくは１秒以内又は“オンデマンド”で受け取ることができる支払（又は資金及び／又は商品及び／又はサービスが利用可能）を指す。即時支払リクエストを行うには、検索者１１８はかかる支払のリクエストを検索システム１１４にコンピュータシステム１２０から送信できる。即時支払リクエストに対応して、検索システム１１４は即時支払リクエスト（及びシステム１１４及び１２６による任意のサービス料金）の金額を検索データベース１２４にある検索者の口座を引落し、カリフォルニア、サンホセにあるＰａｙＰａｌ（登録商標）といったような支払システム１２６に、又はインディアナ州のインディアナポリスにあるＦｉｒｓｔ Ｉｎｔｅｒｎｅｔ Ｂａｎｋといったような銀行経由で送金リクエストを送信する。送金リクエストにより、支払システム１２６が支払システムデータベース１２８にある検索システム口座１２８ａから、支払システムデータベース１２８（図１）にある検索者口座１２８ｂへ支払額を送金するようにさせる。この送金が完了する場合、検索者１１８は下記に説明の通り多数の異なるシステムにアクセスする方法で、その金額にアクセスしてよい。即時支払リクエストは、グラフィカルユーザインタフェース（ＧＵＩ）にあるキーを押すといったような公然としたアクション、又は携帯電話経由での口頭によるリクエストによって生じることが可能で、或いは、支払口座の借り越し条件、検索者が無意識であって作業員によって作業が完了している、又は事前に確立された任意の条件の達成といったような暗示的なアクションによって生じる可能性がある。同様に、支払は条件によって１つ以上の支払システム口座に対して実行可能である。

支払リクエスト時に、検索システム１１４にある検索者／企業の口座は上記に記載の通り１件の支払を含むか、多数の検索又は活動からの累積された支払を含んでいる場合がある。検索者によって行われる支払リクエストは、本文で後に論じられる通り、検索者の口座にある金の全額又は小額を含む場合がある。支払リクエストに先駆けて、検索者は必ず支払システム１２６に口座を確立しておかなければならず（リクエスト時に口座を作成するため又は、既存の口座を指定するためダイアログが検索者との間に確立されていたとしても）、そして本文で後で論じられる通り、デビットカードやクレジットカードといったような支払システム用の電子送金カードも得ておかなければならない。また、検索者又は企業は、検索システム１１４にある環境設定情報又は検索者のプロファイルに、支払システム１２６にある検索者口座１２８ｂに関する適切な情報を含む又は保存しておく必要もある。

検索者は、条件が見合う又はイベントが起こった場合に自動的に支払のリクエストされるように、検索システム１１４にある環境基本設定も設定できる。すなわち、検索者は支払に対して明白なリクエストを行う必要はなく、自動で行うことができる。これは、完了した作業の値、カレンダーの時間、完了した作業量（例えば検索数）等、及び／又は前記の任意の組み合わせに関連した閾に達することによって、タスク毎、１時間毎、１日毎によって完了させることができる。検索者又はシステム管理者によって定義された条件であればどんな条件でも、即時支払を実行することが可能である。即時支払は、検索者によって指定された通り、どの検索者の支払システム口座が指定されてもよい。また、下記にさらに詳細に説明している通り、イベントにより、支払が指定の検索者支払口座へ支払が生じる場合もある。

支払システム１２６によって検索者１１８へ発行されたデビット／クレジットカードを使用して、支払システムデータベースにある検索者の口座がデビットされたファイナンシャルネットワーク１３２を通じて、検索者は自動現金支払機（ＡＴＭ）１３０から現金を得ることができる。カード及び／又はその他の支払デバイスも、カードリーダー１３４（図１）によってカードを読み取り又はスキャンする洋服店や映画館といったような一般的な購入取引に使用することができ、また支払システムデータベース１２８にある検索者の口座へアクセスするデビット又はクレジットカードとしても仕えることができる。また、支払システム１２６にある検索者の口座と関連したデータを使用して購入が可能であるＡｍａｚｏｎ（登録商標）といったようなウェブサービス１３８へアクセスするため、検索者１１８はコンピュータシステム１２０又はコンピュータシステム１３６も、ワイヤレス又はそうでなくても、使用できる。コンピュータシステム１２０、１３６は検索者が希望する金額（例、ギフト額、タスクからの収益のシェア、作業に関連した手数料やロイヤルティ）を支払システム１２６又は電子支払／送金経由で検索者口座と関連付けられた任意の支払システムにあるその他の口座へ送金するために使用されてもよい。電話、ワイヤレスデバイス又はその他の手段といったようなその他の種類の電子デバイスが支払の実施に使用できる国々において、検索者は自動販売機からソフトドリンクを購入するといったような商品やサービスの支払を行うため、(パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話又はその他のデバイスといったような）検索者デバイス１４０を使用できる。支払システム１２６へのこれらの各アクセスにおいて、従来のファイナンシャルネットワークオペレーションは、例えば、ＡＴＭ１３０がデビットカードの口座が現金引き出しに十分な資金があることを確認するといったような場所で起こり、支払システム１２６にある口座にリクエストされた現金支払及び支払に対するその他の取引手数料によってデビットさせ、ＡＴＭ１３０からカード所有者に資金を支出する。すなわち、従来のテクノロジーはデビット／クレジットカード取引のリクエスト又は支払システム１２６にある口座からの資金の支払のその他のリクエストを処理できる。

即時支払のリクエストをするためにコンピュータシステム１２０を使用するよりも、検索者１１８は、パブリックスイッチ電話ネットワーク１４２を経由して、携帯電話の場合は電話サーバ１４４を経由して、ワイヤレスデバイスの場合はワイヤレスサーバ１４６を経由して、又は直接ネットワーク１１６を経由して、デバイス１４０（電話、ＰＤＡ等）から検索システム１１４へ即時支払リクエストを送信することができる。これにより、即時支払システムユーザ又は現在の例では検索者１１８が“一瞬の通知”で検索システム１１４の検索者口座にある資金にアクセスを得ることができる。ワイヤレスケーブルラップトップ、タブレットコンピュータ、電話（例、ボイスｘＭＬメニューを使用して）といったようなその他のデバイスも支払リクエストをするために使用できる。かかるリクエストは１つ以上のサービスプロバイダ、コミュニケーションプロバイダ及び／又は銀行から取引料金がかかる場合がある。

図１の点線で示す通り、検索システム１１４は、コミュニケーションネットワーク１１６経由でセキュアリンクよりも直接支払システム１２６とコミュニケーションを図ってもよく、及び／又は支払システム１２６は検索データベース１２４へ直接アクセスしてもよい。

図２に示してある通り、支払のリクエストを処理する検索システム１１４（図１）のプロセス２０５は、コンピュータシステム１２０（図１）や検索者デバイス１４０といったようなリクエストソースから支払リクエストが受け取られるまで２１０を待ってもよい。リクエストは検索者、検索者の口座等を認識し、パスワード等を含み、実質上即時に支払うことができる金額を認識可能である。リクエストが受け取られない場合、プロセス２０５は支払リクエストが受け取られるように２１０を継続して待つ。リクエストが有効であり、検索データベース１２４（図１）の検索者の口座に対してリクエストした金額が確認される（オペレーション２１２（図２））。リクエストした金額が検索データベース１２４にある検索者の口座の金額よりも多い場合、検索システム１１４によって、コンピュータシステム１２０又は検索者デバイス１４０（例えば）にいる検索者１１８へ資金が不十分であるというメッセージが送信される（オペレーション２１４（図２））。プロセス２０５は、支払リクエストを受け取るまでその後継続して２１０を待つ。十分な資金が利用可能である場合、検索システム１１４は検索データベース１２４（図１）にある検索者の口座からリクエストされた金額をデビットする（オペレーション２１６（図２））。その後検索システム１１４は、アプリケーションプログラミングインタフェース（ＡＰＩ）を経由して送金リクエストを支払システム１２６又は支払データベース１２８にあるシステム口座１２８ａ（図１）から、支払システムデータベース１２８にある検索者口座１２８ｂへ実質上即時支払リクエストの金額を送金するためのその他のコミュニケーションメカニズムへ発行する（オペレーション２１８（図２））。送金リクエストは、金額、支払システムデータベース１２８にあるシステム口座１２８ａ及び支払システムデータベース１２８にある検索者口座１２８ｂを認識する。オプションで、システム１１４と１２６は、リクエストを処理するために一律料金（例、５０セント）及び／又はパーセンテージ(例３％)で、取引料金を請求してよく、どんな取引料金も、リクエストされた送金額から検索システム１１４（及び／又は支払システム）の取引料金口座１２８ｃ（図１）へクレジットされ、支払システム１２６内の実際の送金は取引料金からリクエスト金額を引いた額となる。それから検索システム１１４は、支払システム１２６（図１）からの送金確認書の受け取りを待つ（オペレーション２２０（図２））。確認書が定義された時間内に受け取られない場合、検索システムは取引をキャンセルし、再入力又は支払システムで不完全な取引を解決してもよい。

検索システム１１４（図１）がリクエストを確認している間、送金のリクエストをする及び／又は送金の確認書を待ち、検索システム１１４は検索者デバイス１２０、１４０といったような検索者デバイスに、広告サーバ１２２（図１）から得たミュージックストア用などの広告を適切な方法で検索者に提示できるように送信できる。即時支払リクエストが実施される前及び／又は後に、検索システム１１４は即時支払リクエストを行う検索者に対して商品及び／又はサービスの割引オファーを送信してもよい。

支払システム１２６からの確認書を受け取る場合、検索システム１１４は、コンピュータシステム１２０（図１）又は検索者デバイス１４０であるリクエストのソースにおける検索者１１８（図１）へ確認書を送信（オペレーション２２２（図２））してよく、リクエストを待つために戻る（オペレーション２１０（図２））。確認書によって、送金された金額を確定し、また希望があれば、送金に使用された検索者口座情報及び／又は関連情報を確認する。支払システム１２６（図１）は、支払システムで一般的に使用される方法で検索者に取引を確定してもよい。

送金オペレーションが取引料金を必要とする場合、検索システム１１４は、検索者がリクエストしシステムがそのリクエストを受け取った時に検索者に取引料金の金額を知らせ、実質上即時に支払われる実際の金額がリクエストされた金額から取引料金を引いた額であることをシステムに表示し、検索者の口座に利用可能な金額の確認をする（オペレーション２１２（図２）前に修正された支払金額に対して検索者から承認をリクエストしてよい。

検索者口座１２８ｂがクレジットされる時に、システム口座１２８ａ（図１）から送金リクエスト額（適用されれば取引手数料を足した額）デビットするよりも、その後、支払システム１２６が送金リクエストの結果かかったいかなる料金を足した検索者口座１２８ｂに追加したクレジット額を検索システム１１４に請求してもよい。

前記に説明の通り、タスクが完了した時、又はその他の定義された条件が満たされた時に実質上即時支払をするため、検索者は検索システム１１４の環境設定を行うことができる。かかる状況において、検索システム１１４（図１）は状況が満たされるのを待ち（オペレーション２５２（図２））、検索データベース１２４（図１）にある検索者の口座が更新される（例、検索関連タスクが完了し、クレジットが検索者の検索システム口座に追加される）のを待つ。かかるタスクが完了され、目標が満たされる等といったように即時支払リクエスト条件が満たされる場合、検索システム１１４は検索者の口座に関連した検索データベース１２４（図１）における金額とその他の情報を読み取る（オペレーション２５４（図２））。その後、リクエストの金額が検索データベース１２４にある検索者の口座からデビットされ（オペレーション２１６）、以前に説明した通り送金が実施できる。即時支払リクエスト条件が満たされない場合、検索システムは条件が満たされるまで継続して待つ（オペレーション２５２）。

処理の簡易性を考え、本文で説明の通り、銀行は即時支払システムで使用するためデビットカード番号に特別な番号を割り当てることができる。検索者又はガイドが銀行に口座を維持する場合、システム（マスター）口座から検索者の口座への送金は一般的に銀行信用と呼ばれる。有効な取引を受け取る場合、送金リクエストは一般的に1秒もかからない。送金リクエストは一般的に自動クリアリングハウス（ＡＣＨ）タイプリクエスト又は従来のＡＣＨファイル交換仕様書に従ってＡＣＨファイルフォーマット化される可能性がある。送金リクエストには従来のＡＣＨシステムを使わなくてもよいが、送金リクエストは一般的に銀行インターネットバンキング接続経由で銀行に送信され、これにはホームバンキングチャネルや自動現金支払機（ＡＴＭ）チャネルを含むことができる。輸送メカニズムは、プライベートネットワーク（ＶＰＮ）経由であってよい。このタイプの口座の不正使用を防ぐため、キャッシュ管理ツールとして、最低引落し取引金額を２５ドルといったように指定してよい。即時支払のリクエストを処理する費用は、２ドルといったようにアウトオブネットワークＡＴＭ料金に匹敵して設定されてよい。

即時支払リクエストプロセス２９０(図３参照)は、検索者コンピュータシステム１２０（図１）、検索者デバイス１４０、検索システム１１４、又は検索システム１１４に即時支払リクエストを送信可能なその他の適切なデバイスといったようなソースデバイス上で実行してよい。プロセス２９０（図３）は、検索システム１１４（図１）における検索者口座の金額を含む情報用にリクエスト２９２で開始する。リクエストには、システムが検索者１１８のアカウントを識別することを可能にする検索システム１１４にある検索者識別子、検索者の検索データベース１２４へのアクセス権を確認するパスワード、検索データベース１２４にある検索者口座にある金額をリクエストするコマンド、セキュリティ関連データ、検索者ソースデバイス（例、コンピュータシステム１２０又は検索者デバイス１４０）を識別する（“クッキー”のような）識別子が含まれてよい。一般的に、口座ＩＤ 、パスワード及び／又はその他の適用される有効性情報は、リクエストで自動的に提供されてよいが、検索者１１８はこの情報を入力する必要がある場合がある。リクエストにより、検索システム１１４が検索者アカウントにおける勤労金額及び／又は検索データベース１２４におけるその他のデータを得ることができ、それを検索者デバイス１２０、１４０といったような検索者デバイスに送信できる。情報に対して何のリクエストも受け取られない場合、プロセス２９０は継続してリクエスト２９２を待つ。

プロセス２９０（図３）は、それからグラフィカルユーザインタフェース（ＧＵＩ）又は検索者１１８によって検証するため、検索者デバイス１２０、１４０のような検索者デバイスにその他の適切な方法を使用して、リクエストに対応して検索システム１１４（図１）から受け取った金額を継続して提示し続ける（オペレーション２９４）。

その後プロセス２９０（図３）は、例えば検索者作動即時支払（ＰａｙＭｅＮｏｗ（登録商標））ボタン又はディスプレイＧＵＩのコントロール、キープレス又はボイスインタフェースが表示された時の発話、又は検索者１１８（図１）によるその他のアクションによって、即時支払リクエストが作動されたかどうかを決定する（オペレーション２９６）。即時支払リクエストが作動していない場合、プロセス２９０（図３）は待つ。指定時間内にユーザがそれ以上のアクションを取らない場合、プロセス２９０はタイムアウトし、検索者口座の情報に対してリクエスト２９２を待つため戻る。即時支払が作動されると、プロセス２９０は、検索者が支払われる金額及び／又はその他の情報を指定することができるように検索者にオプションの提示を続行する（オペレーション２９８）。

検索者１１８（図１）は、その後検索システムから受け取った金額とは異なる金額を指定（オペレーション３００（図３））してもよく、及び／又は即時支払リクエストに何らかの修正を加えてもよい。プロセス２９０は即時支払のリクエストが、例えばＧＵＩ上の“ＯＫ”ボタンを“クリックする”といったようなコントロールを作動、ソースデバイスキーボード上の“エンター”タイプキーを押す、口頭で受け入れる等によって作動されているかどうかの決定を続行する（オペレーション３０２）。

即時支払リクエストが作動していない場合、プロセス２９０は待つ。指定時間内に即時支払リクエストが作動されない場合、プロセス２９０はタイムアウトし、検索者口座情報２９２のリクエストを待つため戻る。

即時支払リクエストが作動される場合、プロセス２９０はその後検索システム１１４（図１）に即時支払リクエストを送信（オペレーション３０４）し、支払システム１２６（図１）からの送金の確認書３０６（図３）を待つ。確認書が受け取られると、プロセス２９０（図３）は検索者へ確認書の表示を提示してよい。プロセス２９０はその後他のリクエストを待つために戻る（オペレーション２９２）。

即時支払システムからの確認書が受け取られない場合、プロセス２９０は待つ。指定時間内に確認書が支払システム１２６（図１）から受け取られない場合、プロセス２９０（図３）はタイムアウトし、タイムアウト状態３０８を解決する。検索システムは送金リクエストを再転送し、取引をキャンセルし、ガイドに知らせるか、タイムアウト状態を解決するための何らかの適切なアクションをとってよい。プロセス２９０はその後他のリクエスト２９２を待つために戻る。

検索データベース１２４（図１）は、検索者１１８によって実施された検索／タスクに関連した検索結果等の保存に加え、検索者のランキング、タスクの支払に関連した情報、及び図４で描かれた通り本文で説明した実質上即時支払といったような検索者の情報も保存してよい。検索データベース１２４（図１）は検索者のための検索者記録３４０（図４を参照）を構成してよい。１つの検索者記録が図４に描かれている一方で、別の検索者記録が任意の検索者のために検索システム１１４によって維持されてよいことを把握している。

図４に説明の通り、検索者記録３４０はガイドＩＤ欄３４２、支払システム口座ＩＤ欄３４４、支払システムルーティン番号欄３４６、送金状態欄３４８、合計収入欄３５０、口座残高欄３５２及び支払金額欄３５４を持つ記録を含んでよい。

ガイドＩＤ欄３４２は、その他のガイドのガイド記録からガイドのガイド記録を差別化するために使用されるガイドのためのユニークな識別子を含む。

支払システム口座ＩＤ欄３４４は支払システム１２６（図１）にある検索者の口座情報（クレジット／デビットカード）を含む。支払システム口座情報はガイド記録に関連した支払システム口座への支払の送金に使用されてよい。

支払システムルーティン番号欄３４６（図４）は支払システム１２６（図１）内の検索者口座用のルーティン番号を含む。ルーティン番号は、ガイド記録に関連した支払システム口座への支払の送金に使用されてよい。

送金状態欄３４８（図４）は、ガイド記録に関連したガイド用に以前に説明した条件に見合った後の即時支払の条件についての情報を含む。

合計収入欄３５０は、一定期間ガイド記録に関連した検索者／ガイド／作業員が稼いだ合計金額を含む。

口座残高欄３５２は、ガイド記録に関連した検索口座に利用可能な現在の金額を含んでよい。

支払金額欄３５４は、検索者記録の送金状態欄３４８に関連した即時支払のリクエストの額を含んでよい。

また、検索データベース１２４（図１）には、検索者の税率、源泉課税額、社会保障番号等といったような法に従って必要とされるその他のファイナンシャル情報を記録してもよい。この金額によって、例えばデビットカードで検索者へ送金するために実際にアクセス可能な金額に影響がある場合がある。

支払システムデータベース１２８は、支払がリクエストされた時に検索者口座１２８ｂといったような支払資金が検索者の口座へ送金することができるマスター検索システム口座１２８ａを含んでいる。本文で説明したシステムが支払システム１２６における検索者口座を必要とするため、検索者は即時支払のリクエスト又は即時支払を行うため上記に記載の環境設定変数の設定を許可される前に、かかる口座を確立する必要があるかもしれない。少なくとも１つの例において、この情報はＧＵＩ５５０（図９）といったような、例えばグラフィカルユーザインタフェース（ＧＵＩ）を使用して収集されてよい。

図５は、検索タスクを実施するため、検索者が少なくとも１つの例において即時支払（ＰａｙＭｅＮｏｗ（登録商標））をリクエストできるコンピュータシステム１２０（図１）に表示されたＧＵＩ３９２を描写している。このインタフェース３９２（図５）は、ユーザ１１０（図１）のクエリが表示されたクエリ欄３９４を含む。検索者１１８（図１）により検索結果を整理し、検索結果を選択しユーザコンピュータ１１２に転送できるフレーム３９６（図５）も提供されてよい。完了した作業量のインジケータ３９８（図５）も提供されてよい。このインタフェースも、検索者が１つ以上の検索タスクを完了して稼いだ現在の金額を表示する欄４００を含んでよい。即時支払のリクエストを開始するボタン又はコントロール４０２も含まれることができる。

ＧＵＩ３９２（図５）も広告ウインドウ４０４と目標選択ボックス４０６を含んでもよい。目標選択ボックス４０６は以前に言及された“Ｍｅｔｈｏｄ Ａｎｄ Ｓｙｓｔｅｍ Ｔｒａｃｋｉｎｇ Ｗｏｒｋ Ｄｏｎｅ Ｂｙ Ｈｕｍａｎ Ｗｏｒｋｅｒｓ”という題の関連アプリケーションの図４のようなＧＵＩへ導くことができ、又は同じアプリケーションの図４Ａ及び４Ｂに従った目的を得るために必要な残りの労力を表示することができる。ガイドは非現金又は現金目標の中から選ぶことを選択してよい。それから、ガイドのいかなる又は全ての収入が、ガイドによって指定された目標達成に向けてカウント可能な“ポイント”として解釈されてもよい。目標が達成されると、ガイドは直ちにアイテムを購入することを選んでもよく、それから支払金額はガイドの収入口座からデビットされ、支払システム１２８（図１）にある目標商品及び／又はサービスを提供する店舗の口座に適切にクレジットされる。例えば、目標は商品又はサービス（例、映画のチケット、ヘアカット等）であってもよく、どのケースにおいても、チケットは即時に購入可能で、“Ｗｉｌｌ ｃａｌｌ”でピックアップできる。これは店舗などからの割引を得る利点ともなり、ガイドのモラルを改善することになるかもしれない。

図５Ａは現在の収入と目標ＧＵＩ４０８がどのようにアレンジされえるかを少なくとも１つの例において説明したものである。ＧＵＩ４０８は、目標４１４と一緒に作動した時に即時支払のリクエストが送られるボタン４１２に関連した累積“収入”４１０を表示している。目標４１４は編集可能又は、新しい目標と関連ボタン４１６経由で取替え可能である。また、ＧＵＩ４０８も今までに完了した仕事量とインジケータ４１８とその他の情報を表示している。

図において、目標は現在現金金額である。しかし、目標が映画のチケットのような商品である場合、ディスプレイは映画のチケットとチケットを得るために必要な合計収入の達成パーセンテージを表示してもよい。根本的なベースはお金であるが、チケット購入に関連した割引がある可能性もあるが、それは簡単には目に見えず、チケットを得ることを簡単にすることが可能である。例えば、作業員が目標として映画のチケットを選んだ場合、割引なしのチケットの値段は９ドルかもしれない。作業員がガイドとして一検索時間毎に５ドル稼ぐ場合、作業員はチケット得るために１．８時間働く必要がある。ただし、検索システム（ガイド用にチケットを相当数購入するバイヤーとして）は、同じチケットを７ドルで得ることができるかもしれない。よって、検索システムは例えば７．５ドルに匹敵するサービスでガイドにチケットを提供するかもしれない。この例において、収入は作業員が映画のチケットを得るためにガイドの作業量は１．５時間のみである必要があることになる。作業員はＰａｙＭｅＮｏｗ（登録商標）ボタン４１２を作動し、この例のチケットが映画館で割り当てられ（作業員のために購入）、“Ｗｉｌｌ ｃａｌｌ”窓口でピックアップ可能とすることができる。

目標欄４１４は異なる目標を選定できるようにドロップダウンメニューであってもよい。システムは目標が達成されると自動的に選択した目標を“支払”ってよい。上記の例を使うと、作業員は映画チケットの目標に達した場合、システムは自動的に電子的に“購入”され、作業員は映画館に姿を現し、チケットをピックアップできる。この方法において、例えば“未収収益が２００ドル”又は“映画のチケット２枚、ポップコーンとラージサイズのドリンクを２杯”といったような事前に定めた目標が達成された時に支払われるということが支払の“誘因”となる。

図５Ｂは検索者／作業員が自動即時支払リクエストのパラメータの入力に使ってよいＧＵＩ４２０を描写している。ＧＵＩ４２０は支払条件欄４２２、支払口座欄４２４、支払金額／タイプ欄４２６、“追加”ボタン４２８、“削除”ボタン４３０、“受入”ボタン４３２、“キャンセル”ボタン４３４、及びナビゲーションコントロール４３６を含んでよい。

支払条件欄４２２により、ガイドが“日／時間が・・・に等しい”、“口座残高が・・・以上”、“目標達成”、“タスクが完了したときにいつでも”、“２週間毎の金曜日”、“毎月１５日”、“毎月第２木曜日”などといったように支払リクエストが出される条件を指定することが可能とする。これにより、検索者が即時支払リクエストが出される条件を指定可能となる。条件は論理的な組み合わせであるかもしれない。例えば、“任意のタスクが完了”及び“口座残高が１００ドル以上”、或いは、“目標が達成”又は“毎月最終日”又は“ＰａｙＭｅＮｏｗ（登録商標）が選択されている”というようになる。条件欄はドロップダウンメニュー又はその他の適切なインタフェースとして実行されてよい。

支払口座欄４２４により、ガイドは条件が正である場合に送金がなされる支払システム口座を指定することが可能となる。例えば、ガイドが支払システム（貯金、小切手、ローン等）の複数の口座を所有している又は、複数の支払システムで支払口座を確立してもよい。即時支払リクエスト用にガイドが利用可能な口座をこの欄に入力してよい。入力欄はドロップダウンメニューとして実行されてよく、口座は口座番号又は口座説明など様々な方法を使用して表示可能である。

支払金額／タイプ欄４２６により、ガイドはオプションとして即時支払リクエストの金額及び／又はタイプを指定することが可能である。このメカニズムを使って、ガイドは定義された条件が見合えば、合計口座残高以上の金額を選ぶことができる。例えば、タスクの完了によりガイドの検索システム口座に４００ドルのクレジットをもたらした場合、ガイドは貯金口座に２００ドル、小切手口座に１５０ドル送金するように選ぶことができる。同様に、ガイドは商品及び／又はサービス目標が達成された時に即時に給料を得るように選んでもよい。

“追加”ボタン４２８により、ガイドは新しい支払リクエストを自動支払リクエストリストに追加可能となる。“削除”ボタン４３０により、ガイドは、例えばリストからリクエストを選択し、削除ボタン４３０を作動して、既存の支払リクエストを削除可能となる。“受入”ボタン４３２により、ガイドは自動リクエストの現在のリストを受入、検索データベース１２４（図１）のどんな修正も保存可能となる。“キャンセル”ボタン４３４（図５Ｂ）により、ガイドは検索データベース１２４（図１）へのどんな修正も保存せずにＧＵＩ４２０を退出可能となる。ナビゲーションコントロール４３６（図５Ｂ）により、ガイドは自動支払リクエストのリストをナビゲート可能となる。

検索システム１１４（図１）は、自動リクエストが行われたかどうか検索者に知らせてもよい。インスタントメッセージ、ＳＭＳ、電子メールやその他のコミュニケーション手段といったような様々な通知手段、が使われてよい。支払システムは従来の手段によって取引を確認してよい。

図６は、例えばボタン４０２（図５）が少なくとも１つの例において作動している場合、コンピュータシステム１２０に表示可能なＧＵＩ４４２を描写している。ＧＵＩ４４２（図６）は、検索者の口座にある金額を表示する欄４４４を含み、この欄は検索者が口座にある合計金額以下の金額を指定するため、欄を選択し、コンピュータの番号キーを使って変更できる。もちろん、検索者は欄４４４にある金額を変更する必要はない。即時支払のリクエストを稼動するボタン又はコントロール４４６も含まれることができる。オプションとして、インタフェース４４２も、各タスクが完了したときに即時に支払う環境基本設定の設定をするため、検索者が一般的に支払金額の編集に関して質問されない場合にボタン４４８を含むことができる。

ＧＵＩ又は携帯電話のその他の機能、ＰＤＡや検索者デバイス１４０（図１）のようなその他の検索デバイスはその機能の使用が限定されるかもしれないので、コンピュータシステム１２０の機能と比べて簡素なものが望ましい。少なくとも１つの例において、図７に説明の通り、検索者デバイス１４０（図１）のような検索者デバイスのＧＵＩ４５０は検索者の口座の金額が表示される欄４８２（図７）を含むことができる。検索者１１８（図１）はデバイスキー４８４を使って欄４８２（図７）の金額を変更でき、送金／送信ボタン４８６を使って即時支払リクエストを転送できる。まず稼いだ金額（又は利用可能な金額）が検索データベース１２４（図１）に表示され、次に検索者が送金したい金額を入力できる。

検索者デバイスが表示及び／又はインタフェースの機能を限定する場合、適切なインタフェースが提供されてよい。例えば、検索者デバイスがボイス入力とオーディオ出力機能のみを所有する場合、ボイスｘＭＬ又は人物は即時支払リクエストを処理してよい。

図８は、人物又は企業が検索者又はガイド或いはプロバイダとしてサインアップし、作業を実施し、又は給与を受け取り、実質上即時支払を得る一連のオペレーション５１２を描写している。人物／企業は、まず５１４登録を完了する。登録情報の有効性の確認がオペレーション５１６で行われる。有効性が確認できない場合、システム１１４（図１）は報告５１８（図８）を発行し、登録オペレーション５１４（図８）に戻る。情報の有効性が確認されると、Ｗ９、所得税者ＩＤ等といったような登録データがデータベース更新５２０によって保存される。ガイド／登録者はそれからトレーニングを受ける（オペレーション５２２）。トレーニングが終了しない場合、プロセス５１２は継続してトレーニングが終了するまで待つ（オペレーション５２２）。トレーニングが終了すると、ガイドがサービスを入力し、ガイドの口座（図４参照）が収入でクレジットされる（オペレーション５２４）検索タスク又は検索関連タスクの実施を開始する。それからガイドは５２６支払をリクエストできる。ガイドは５２６支払をリクエストしない場合、プロセス５１２は継続してリクエストを待つ。システムは口座残高が十分にあるかどうかを確認するため５２８をチェックする。十分でない場合、残高が不十分であるというメッセージが送信される（オペレーション５３６）。それからプロセス５１２は、ガイドに収入をクレジットする（オペレーション５２４）ため戻る。口座残高が十分な場合、検索システム１１４（図１）は支払データを得、支払システム１２８へ支払金額の取引の送金を送信するため支払システムＡＰＩ（アプリケーションプログラミングインタフェース）への通話を実行する。支払システム１２８において、検索者（又はガイド）口座１２８ｂは、ガイドへの支払に関して（取引／手数料を引いて）クレジット可能である（オペレーション５３０（図８））。それから手数料が配信される（オペレーション５３２）。検索システム１１４（図１）は検索データベース１２４（図１）を更新する（オペレーション５３４（図８））。プロセス５１２はその後収入が発生するまでガイドを待つために戻る（オペレーション５２４）。

銀行のような他のタイプの支払システムが使用される場合、検索者はデビット／クレジットカードに関連した個々の銀行口座を所有してよい。検索システム１１４は、広告のような収入ソースで資金が提供される会社のマスター口座を銀行に所有する。マスター口座は、ＰａｙＭｅＮｏｗ（登録商標）ボタンが使用された及び／又は検索者が自分の口座に自動及び／又は継続支払されるように指定する場合、一般的な支払スケジュール（例、２週間おき）において個々の検索者の口座にリアルタイムで送金を行うために使用することが可能である。上記のどれにおいても、検索システム１１４から、銀行から又はコミュニケーションプロバイダからの手数料が含まれてよい。

上記の説明は、検索者が継続して又はリクエストをした時に支払を受け取るように選択可能であることを示している。全ての検索者が支払システムに口座を所有している場合、デフォルトの支払方法は常に即時支払に設定することが可能であり、検索者／作業員がリクエストした時又は月次給与としてといったように頻度をさげて支払を受け取るように選択することが可能である。支払は、固定の閾や手数料を差し引いた検索者の口座残高が一定のパーセンテージに達した時等というような、図５Ｂに関連して説明の通り、その他の要素に基づくことも可能である。

図９は、ガイド又は登録企業によって支払口座情報を入力する際の模範的なＧＵＩ５５０を描写している。ＧＵＩ５５０は登録プロセス５１４（図８を参照）の一部として及び／又はガイドによってリクエストされたとしてガイドへ提示されてもよい。ＧＵＩ５５０には、名前、住所、電話番号ボックス５５２、ルーティン番号ボックス５５４、口座番号ボックス５５６、説明ボックス５５８、“受入”ボタン５６０及び／又は“キャンセル”ボタン５６２を含んでよい。

名前、住所、電話番号ボックス５５２（図９）は検索者の支払システムの口座に関する口座データを入力するために使用されてよい。少なくとも１つの例において、このデータは検索データベース１２４からの情報を使用して記入されてもよい。

ルーティンボックス５５４（図９）は検索者の支払システムの口座に関するルーティン番号を入力するために使用されてよい。口座番号ボックス５５６（図９）は検索者の支払システムの口座に関する口座番号を入力するために使用されてよい。説明ボックス５５８（図９）は口座の説明題記を入力するために使用されてよい。

受入ボタン５６０は検索データベース１２４（図１）にある修正されたデータを保存するために使用されてもよい。キャンセルボタン５６２は、検索データベース１２４（図１）への修正を保存せずにＧＵＩ５５０を退出するために使用してよい。

即時支払に使用される支払システム口座は、上記に記述の要件に見合うように支払システムを確立されなければならない。システムが１つの支払システムを使用して説明されているけれども、複数の支払システムを使用してよいことも描写されている。

また、検索者が支払システム１２６のデビット／クレジットカード口座を使っていつでもシステムによって検索者が検索データベース１２４にある稼いだ収入へアクセスできるようにすることは可能である。かかるシステムにおいて、支払システム１２６はＡＴＭからの資金の引落しの権限のリクエストといったような取引を受け取るかもしれない。十分な資金が検索者支払システム口座１２８ｂに利用可能でない場合、過振りからの保護の形式である、取引をカバーするのに十分な資金送金を求めて、支払システムは検索システム１１４（すなわち、即時支払リクエストの作成）を質問することが可能である。システム１１４及び１２６を組み合わせても十分な資金が利用できない場合、支払システム１２６は、ＡＴＭを通じて検索者に資金が不十分であることを伝えるメッセージを発行できる。

本文で説明されたシステムは、検索者が任意のデバイスからシステムにログインを可能とし、ＧＵＩ又は支払リクエストを出すことを可能にするその他のインタフェースを得ることもでき、よって検索者が必然的にどのロケーションからも支払リクエストができるようになる。

銀行のバックオフィスの国際貿易取引活動のようなその他のタイプの電子タスク又は活動は、かかる電子タスクに対する即時支払を可能にするため本文で説明されたシステムによって即時支払に関して上記に説明した検索のような活動としても処理可能である。

検索者が望んだ時に又はタスクが終了した時に即時“マイクロペイメント”支払のリクエストができるとシステムを説明してきたけれども、システムは常に１つ以上のタスクが完了された後に即時に支払うように設定することができる。よって、必然的に常に即時に支払う又は検索者が稼いだ資金にアクセス可能となる。

システムは、ニューヨークのロチェスターのＰａｙｃｈｅｘ（登録商標）によって提供されるサービスのようなサービスによって完了したときに自動計算ベースで税金、手当、手数料等を支払うように環境設定されてもよい。

また、システムは検索システム１１４から独立しているように支払システム１２６を説明しているが、さらにこの２つのシステムを１つのシステムに組み込むことが可能である。

本文での説明がデータベースに記録があり、データベースが記録を所有していることを示しているけれども、データベースは適切なアクセス認識情報を使って適切な情報にアクセスを可能とするいかなる形式の任意のデータを保存してよい。

また、ガイド、検索者、企業又は作業員は、例えばガイドが支払や資金の送金をしたいと思うクレジットカード口座や貯金口座といったような他の口座に即時支払を実施するようにリクエストをすることもできる。

検索システムの検索者口座は検索者によってリクルートされたその他の人物が実施した検索に対するクレジット、検索者が検索作業を実施するようにその他の検索者をサインアップするシステムのスポンサーに対してといったような様々な理由に対して収入を受け取ってよい

本文で説明した通り実質上即時支払を受けた作業は、作業又は活動の完了又は最終ポイント及び作業に対する支払金額が電子システムに入力できる限り、電子ベースの作業である必要はない。作業が一連のイベントからなる場合、各イベントの終了時といったように、作業の最終完了時よりも段階毎に支払われることができる。

デビットカードで資金を引落すよりも、ユーザは銀行内のその他の口座又はその他の金融或いは非金融機関へ電子的に送金された資金を所有することが可能である。

検索システム自体が金融機関の一部であることも可能で、よってシステムの検索者口座は銀行口座である。

各例は検索システムに関して説明されたものであるが、独立した請負人（ガイド又は作業員）がオンデマンド支払システムが望ましい作業を実施するその他の環境において実践されることが可能である。

システムは、例えば天災の被害者であると認定された受贈者が登録者である非営利目的ネットワークの一部であることが可能である。かかるシステムは高度に系統立てられ説明可能であるが、急速に配置可能で柔軟性のあるシステムにおいて既存のインフラを通して即時救済を提供することができる。システムオペレータは、マーケティング専門知識とネットワークのドナーとサービスプロバイダの両方として手配可能なドナーのネットワークを所有する既存の慈善組織（ユニセフ、アメリカ赤十字、救世軍、ユナイテッドウェイ等）であってもよい。

同様に、主要小売業者（例、Ｔｈｅ Ｈｏｍｅ Ｄｅｐｏｔ（登録商標））のような営利目的企業が、タスクタイプベースで補助的サービス（例、購入商品のインストール）を提供する独立サービスプロバイダを手配するため、かかるシステムを提供するかもしれない。請負業者は、自分たちのキャッシュフローを改善するため即時に支払を受け取るように選ぶかもしれない。及び／又は上記に記載の通り、購入パワーを改善及び／又はサプライヤベースに影響を与えることができるように商店報酬を選ぶかもしれない。

また、会員又はガイド／検索者／作業員／企業がスポンサーをした人物が作業員のグループが目標を達成し、実質上即時に支払を受け取ることができるように通知されるようなかかる方法でシステムを組織することも可能である。少なくとも１人のメンバーが自分のタスクに対する給与及び自分のスポンサーをした人物からの手数料を稼ぐことができるので、登録者グループの収益能力は同じグループの個人としての能力よりも優れていてもよい。

システムが共通の利益を共有する作業員を雇用する場合があるため、提携商店ネットワークの力は（例えば）電子カードを使用して割引を得るために使用してもよい。

上記で説明の通り、作業員はカードを使用して電子的に支払を受けてもよいが、検索システムプロバイダによって提供されたネットワーク外の商品、例えば映画のチケットを購入するためのネットワークを使用してもよいし、又はシステム会員が提供した商品及び／又はサービスを事前購入してもよい。即時支払システムはデビットカードのようなポータブル手段無しで実施される。

システムは１つの口座に収入を集約することも可能である。例えば、１人のガイドでは一定の期間に条件に見合うだけの収入を得ることはできないかもしれないが、検索者のグループが１人の検索者の口座に収入の一部又は全部を“寄付”することに決めることができる。収入は非営利組織からの特別なニーズに対して適用／送金／寄付できる。

作業員の活動の実施と実質上即時に支払を受けることについてシステムの説明をしてきた。以前に説明した“Ｍｅｔｈｏｄ，Ｓｙｓｔｅｍ Ａｎｄ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍ Ｆｏｒ Ｍｕｌｔｉｌｅｖｅｌ Ｍａｒｋｅｔｉｎｇ”という題の関連アプリケーションで説明した通り、災害救済のような集合的活動に対する収入を作業員が分割できるようにすることも可能である。組織／企業は収入を累積でき（例、多くの検索者からの小額の寄付）また、一連の条件が見合えば組織が指定した様々な口座へ実質上直ちに支払うことも可能である検索システム１１４の口座を所有しているかもしれない。

特許出願を請求する事例の多数の特徴及び利点は、詳細な仕様書から明らかになり、そのため、特許請求の範囲より、この真の要旨及び範囲内にあるこのような実施例の特徴及び利点の全てをカバーすることを意図する。さらに、多数の修正及び変更が容易に当業者に生じるため、開示された実施例に図示及び記載された正確な構成及び動作に本発明を限定することを望まない。従って、全ての適切な修正及びそれに匹敵する変更は、本発明の範囲内にあることを要求し得る。

Claims (29)

1. タスクベースの支払方法であって、
   検索関連活動スペシャリストにより、検索関連活動を実行するステップと；
   前記活動の完了時に前記スペシャリストへの実質的に即時の電子支払を実施するステップと；
   を具えることを特徴とする方法。
2. 検索ベースの支払方法であって、
   前記検索をリクエストするユーザのために、検索者による検索システム活動を実行するステップと；
   前記検索の完了時に前記検索者への実質的に即時の電子支払を実施するステップと；
   を具えることを特徴とする方法。
3. 電子検索関連タスクが実行されたことを決定するステップと；
   前記電子作業タスクに対する即時支払を実質的に実施するステップと；
   を具えることを特徴とする方法。
4. 検索関連活動の支払方法であって、
   作業員により検索関連活動を実行するステップと；
   前記活動と関連するリクエスト時に、前記作業員への実質的に即時の電子支払を実施するステップと；
   を具えることを特徴とする方法。
5. 請求項４に記載の方法において、前記活動は、検索結果がユーザに送信される場合は、ユーザのための検索者による情報検索ステップ、及び、検索者をトレーニングするステップのうちの１つを具えることを特徴とする方法。
6. 請求項４に記載の方法において、前記支払が、現金報酬及び非現金報酬のうちの１つを具えることを特徴とする方法。
7. 請求項６に記載の方法において、前記非現金報酬が、商品、サービス、商品券、提携商店のポイント、及び提携商店のクレジットのうちの１つを具えることを特徴とする方法。
8. 請求項４に記載の方法において、前記実施ステップが、検索システム口座から検索者口座へ支払金額を振り込むステップを具えることを特徴とする方法。
9. 請求項８に記載の方法において、前記振込ステップが、支払金額振込リクエストを支払システムへ送信するステップを具えることを特徴とする方法。
10. 請求項９に記載の方法において、前記支払システムが、銀行を具えることを特徴とする方法。
11. 請求項５に記載の方法において、前記実施ステップは、前記検索者が電子カードを用いて支払金額を引き出すのを可能にするステップを具えることを特徴とする方法。
12. 請求項５に記載の方法において、前記実施ステップが、検索者口座がリクエストされた支払金額に対し十分な資金を含むか否かを決定するステップを具えることを特徴とする方法。
13. 請求項５に記載の方法において、前記実施ステップが、
    検索者の検索システム口座内の金額を示すグラフィカルユーザインタフェース（ＧＵＩ）を用いて、前記検索者に提示するステップと；
    前記検索者が前記ＧＵＩを用いて支払金額を指定するのを可能にするステップと；
    を具えることを特徴とする方法。
14. 請求項１３に記載の方法において、前記検索者が、支払のトリガを指定できることを特徴とする方法。
15. 請求項５に記載の方法において、前記実施ステップは、前記検索者が支払を電子的にリクエストするのを可能にするするステップを具えることを特徴とする方法。
16. 請求項５に記載の方法において、前記実行ステップが、検索者の検索システム口座に前記検索についての収入をクレジットするステップを具えることを特徴とする方法。
17. 請求項５に記載の方法において、目標が合致した場合に支払がトリガされることを特徴とする方法。
18. 検索ベースの支払方法であって、
    前記検索をリクエストするユーザのために、検索者による情報検索を実行し、前記ユーザに対して検索結果を送信するステップと；
    検索者によるリクエスト時の前記検索結果の前記送信ステップ後に、検索システム口座から金融機関の検索者口座に支払金額を振り込むステップを具える前記検索者への実質的な即時電子支払を実施するステップと；
    を具えることを特徴とする方法。
19. 検索ベースの支払方法であって、
    前記検索をリクエストするユーザのために、検索者による情報検索を実行し、前記ユーザに対して検索結果を送信するステップと；
    検索者によるリクエスト時の前記検索結果の前記送信ステップ後に、前記検索者がデビットカードで購入するのを可能にするステップによって、前記検索者への実質的な即時電子支払を実施するステップと；
    を具えることを特徴とする方法。
20. 検索システムの検索者口座において、検索に対する勤労所得を検索者にクレジットするステップと；
    支払リクエスト用のインタフェースを前記検索者に提供するステップと；
    前記インタフェースを用いて前記検索者が支払金額を指定するのを可能にするステップと；
    広告を前記検索者に提示するステップと；
    前記検索者が前記検索者口座からの支払をリクエストしたことを決定するステップと；
    検索者口座が支払用の十分な資金を有しているか否かを識別するステップと；
    前記支払用の検索者口座から検索料金をデビットするステップと；
    クレジット口座のリクエストを支払システムに送信して、前記支払用の検索者支払口座をクレジットするステップと；
    前記支払用の支払システム内の前記支払口座をクレジットし、前記支払用の検索システム口座をデビットするステップと；
    前記検索者への振込を確定するステップと；
    前記検索者が前記支払口座内の資金に実質的に即時にアクセスするのを可能にするステップと；
    を具えることを特徴とする方法。
21. 請求項２０に記載の方法において、前記決定ステップ、確認ステップ、デビットするステップ、送信ステップ、及びクレジットステップが、１分未満で成立することを特徴とする方法。
22. ユーザがユーザのリクエストに基づき検索を実行し、前記検索についての収入を得るのを可能にする検索システムと；
    前記検索者がリクエストし、勤労所得を実質的に即時に支払われるのを可能にする支払システムと；
    を具えることを特徴とするシステム。
23. ユーザが支払金額を設定するための欄と；
    ユーザが支払金額の実質的な即時支払のためのリクエストを開始するのを可能にする制御と；
    を具えることを特徴とするグラフィカルユーザインタフェース。
24. 勤労所得を示す欄と；
    ユーザが前記勤労所得の実質的な即時支払のためのリクエストを開始するのを可能にする制御と；
    を具えることを特徴とするグラフィカルユーザインタフェース。
25. 請求項２４に記載のインタフェースが、更に、
    ガイドにより検索された検索クエリを示すための欄と；
    前記クエリ用の検索結果を示すための検索結果欄と；
    を具えることを特徴とするインタフェース。
26. データベースを具えるコンピュータを制御するためのコンピュータ読取可能ストレージであって、前記データベースが、
    作業員識別子欄と；
    作業員支払システム口座を識別するための支払システム口座識別子欄と；
    前記作業員が作業するシステムにおいて前記作業員が得た勤労所得残高を保持するための口座残高欄と；
    を具えることを特徴とするコンピュータ読取可能ストレージ。
27. タスクベースの支払方法であって、
    作業員により、電子ベースの支払に適したタスクを実行するステップと；
    前記タスクの完了時に前記作業員への実質的に即時の電子支払を実施するステップと；
    を具えることを特徴とする方法。
28. 口座を指定する欄と；
    即時支払タイプを指定する欄と；
    を具えることを特徴とするユーザグラフィカルインタフェース。
29. 請求項２８に記載のインタフェースにおいて、即時支払タイプが、タスク完了時、リクエスト時および定期的に成立することを特徴とするインタフェース。

Images