特許 7540418 買物代行斡旋システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-19

(45)【発行日】2024-08-27

(54)【発明の名称】買物代行斡旋システム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20240820BHJP

【ＦＩ】

G06Q50/10

【請求項の数】 5

(21)【出願番号】P 2021168032

(22)【出願日】2021-10-13

(65)【公開番号】P2023058192

(43)【公開日】2023-04-25

【審査請求日】2023-07-11

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】100104765

【弁理士】

【氏名又は名称】江上 達夫

(74)【代理人】

【識別番号】100131015

【弁理士】

【氏名又は名称】三輪 浩誉

(72)【発明者】

【氏名】佐々木 清人

(72)【発明者】

【氏名】河原田 誠

(72)【発明者】

【氏名】中村 慧

(72)【発明者】

【氏名】奥村 健一

(72)【発明者】

【氏名】角谷 直哉

【審査官】▲高▼瀬 健太郎

(56)【参考文献】

【文献】特開２０１９－１３９７７６（ＪＰ，Ａ）

【文献】特開２０２１－０２８７４２（ＪＰ，Ａ）

【文献】特開２０１３－０５８１１８（ＪＰ，Ａ）

【文献】特開２０１９－０３２６０３（ＪＰ，Ａ）

【文献】特開２００２－１１７２２１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ －９９／００

(57)【特許請求の範囲】

【請求項1】

複数のユーザのそれぞれに対応する端末装置を含み、買物代行を委託する委託者及び該買物代行を受託する受託者間における該買物代行を斡旋する買物代行斡旋システムであって、
前記委託者及び前記受託者の少なくとも一方になり得る前記複数のユーザのそれぞれに関する情報であるユーザ情報を管理するユーザ情報管理部と、
前記複数のユーザのうち前記委託者としてのユーザに係る前記端末装置からのリクエストを、前記複数のユーザのうち前記委託者を除くユーザに係る前記端末装置に、配信するリクエスト配信部と、
配信された前記リクエストに応じて前記端末装置から送信された、前記買物代行の受託を希望することを示すアクセプトを受信するアクセプト受信部と、
前記アクセプトを送信した前記端末装置に係る前記ユーザから、正式な受託者を決定する決定部と、
前記正式な受託者による前記買物代行の完了を確認する確認部とを備え、
前記ユーザ情報管理部は、前記確認部により前記買物代行の完了が確認されると、前記ユーザ情報に含まれる前記委託者に係る委託回数を更新するとともに前記ユーザ情報に含まれる前記正式な受託者に係る受託回数を更新し、前記委託回数及び前記受託回数に基づいた自己の利用傾向が前記複数のユーザのそれぞれに認識されるように、前記各ユーザに対応する前記端末装置にそのユーザの利用傾向を、表示可能に構成されている、買物代行斡旋システム。

【請求項2】

前記受託回数と前記委託回数との関係が第１条件を満たすユーザに対して、特定の店舗で提供される特典を付与する特典提供部を更に備える、ことを特徴とする、請求項１に記載の買物代行斡旋システム。

【請求項3】

前記委託回数と前記受託回数との関係が第２条件を満たすユーザに対して、システム利用料を要求する料金要求部を更に備える、ことを特徴とする請求項１に記載の買物代行斡旋システム。

【請求項4】

前記リクエストに、纏め買い割引が提供される前記買物代行の対象となる商品の割引情報及び該纏め買い割引を提供する店舗の店舗情報が含まれる、ことを特徴とする請求項１に記載の買物代行斡旋システム。

【請求項5】

前記端末装置は、前記買物代行の対象となる商品の種類別又は該商品が購入可能な店舗の種類別に分類されたフォーマットで、前記リクエストを表示可能に構成されている、ことを特徴とする請求項１に記載の買物代行斡旋システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、買物代行を委託する委託者に対し、買物代行を受託する受託者を斡旋する或いは買物代行を支援する買物代行斡旋システムの技術分野に関する。

【背景技術】

【0002】

この種のシステムとして例えば、利用者と援助者とをマッチングさせることで、利用者の買物の依頼を援助者が代行することができる買物代行サービスシステムが提案されている（特許文献１参照）。このシステムによれば、業者を介さず、金銭のやり取りを発生させることなく、買物代行が可能とされている。なお、仲介業者を介して或いは金銭のやり取りを発生させて買物代行業者を斡旋するシステムも提案されているが（特許文献２及び３参照）、ユーザにおける相互援助或いは経済的負担軽減にならない。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１９－１３９７７６号公報

【文献】特開２００２－１８３４９６号公報

【文献】特開２０１９－０４９７９４号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、上記特許文献１によれば、現実社会の中では、子育てをしている親らや買物を自らしたいが自由に行動できない人らが多くいるため、システム上では、買物を希望する或いは買物代行の利用を希望する利用者の登録者数に対して、ボランティアで買物代行を行う援助者の登録者数が少なくなってしまう。これにより、マッチング処理が満足に機能しなくなるという技術的問題点がある。即ち、例えばシステム上で利用者と援助者との相互依存の関係を構築することなどにより、データ上でマッチングすべき利用者数と援助者数との均衡を図ることについては、技術が追いついていない。

【0005】

本発明は、例えば上述した技術的問題に鑑みなされたものであり、利用と援助との公平性を図り得る買物代行斡旋システムを提供することを課題とする。

【課題を解決するための手段】

【0006】

本発明に係る買物代行斡旋システム一の態様は上記課題を解決するために、複数のユーザのそれぞれに対応する端末装置を含み、買物代行を委託する委託者及び該買物代行を受託する受託者間における該買物代行を斡旋する買物代行斡旋システムであって、前記委託者及び前記受託者の少なくとも一方になり得る前記複数のユーザのそれぞれに関する情報であるユーザ情報を管理するユーザ情報管理部と、前記複数のユーザのうち前記委託者としてのユーザに係る前記端末装置からのリクエストを、前記複数のユーザのうち前記委託者を除くユーザに係る前記端末装置に、配信するリクエスト配信部と、配信された前記リクエストに応じて前記端末装置から送信された、前記買物代行の受託を希望することを示すアクセプトを受信するアクセプト受信部と、前記アクセプトを送信した前記端末装置に係る前記ユーザから、正式な受託者を決定する決定部と、前記正式な受託者による前記買物代行の完了を確認する確認部とを備え、前記ユーザ情報管理部は、前記確認部により前記買物代行の完了が確認されると、前記ユーザ情報に含まれる前記委託者に係る委託回数を更新するとともに前記ユーザ情報に含まれる前記正式な受託者に係る受託回数を更新し、前記委託回数及び前記受託回数に基づいた各前記ユーザの利用傾向を、前記端末装置に表示可能に構成されている。

【発明の効果】

【0007】

本発明に係る買物代行斡旋システムの一態様によれば、複数のユーザに対して、過去の買物代行の委託回数及び受託回数を直接的に（即ち、回数そのものを）又は間接的に（即ち、回数そのものではなくその多少や程度或いはレベルを示す指標を）可視化することで、無償で買物代行が提供される環境であっても、個々のユーザにおける委回数託及び受託回数の均衡、或いは代行利用及び援助間の公平性が図られるように誘導できる。特に、利用料金の授受がない環境において有効である。更に、援助が多い者に対して特典を付与したり、委託が多い者に対してシステム利用料を要求可能なように構成することにより、代行利用及び援助間の不均衡を経済的な価値で埋めることもできる。

【0008】

本発明によるこのような作用効果は、以下に説明する発明の実施形態により、より明らかにされる。

【図面の簡単な説明】

【0009】

【図1】第１実施形態に係る買物代行斡旋システムの全体構成の一例を示すブロック図である。

【図2】第１実施形態に係る買物代行斡旋システムにおける管理サーバのハードウェア構成の一例を示す図である。

【図3】第１実施形態に係る買物代行斡旋システムで利用される各種情報のデータ構成の一例を示す図である。

【図4】第１実施形態に係る買物代行斡旋システムにおける端末装置のハードウェア構成の一例を示す図である。

【図5】第１実施形態に係る買物代行斡旋システムで行われる買物代行斡旋に係る処理ルーチンの一例を示すフローチャートである。

【図6】第１実施形態に係る買物代行斡旋システムで行われる代行委託処理の一例を示すシーケンス図である。

【図7】代行委託処理において端末装置に表示されるリクエスト画面の一例を示す図である。

【図8】第２実施形態に係る図２と同趣旨の図である。

【図9】第２実施形態に係る図５と同趣旨のフローチャートである。

【図10】第３実施形態に係る図２と同趣旨の図である。

【図11】第３実施形態に係る図５と同趣旨のフローチャートである。

【発明を実施するための形態】

【0010】

＜第１実施形態＞
図１から図７を参照して、第１実施形態に係る買物代行斡旋システムについて説明する。まず、図１を参照して、第１実施形態に係る買物代行斡旋システムの全体構成の一例について説明する。

【0011】

１．買物代行斡旋システムの全体構成
図１に示すように、本形態に係る買物代行斡旋システム１は、管理サーバ１０と、管理サーバ１０がアクセス可能なデータベース１３と、複数の端末装置２０とを備えて構成されてよい。管理サーバ１０と各端末装置２０とは、相互にデータ通信可能であり、買物代行斡旋システム１は、例えばインターネット１００上に構築されてよい。端末装置２０は、複数のユーザのそれぞれに対応し、各ユーザの入力操作を受け付けるスマートホン、パーソナルコンピュータ、タブレット端末等を含む概念である。他方、管理サーバ１０は、例えば、買物代行を斡旋する斡旋業者の管理下で、当該斡旋業者の営業所内やクラウド上に置かれてよい。図１では４つの端末装置２０、即ち、端末装置２０ａ、端末装置２０ｂ、端末装置２０ｃ、及び端末装置２０ｄが示されているが、買物代行斡旋システム１における端末装置２０の数はこれに限らない。データベース１３は、インターネット１００を介して管理サーバ１０にアクセス可能に構成されてよい。以下、端末装置２０ａ～２０ｄを特に区別しないとき端末装置２０という。また、端末装置２０ａに対応するユーザをユーザ２０ａ、端末装置２０ｂに対応するユーザをユーザ２０ｂ、端末装置２０ｃに対応するユーザをユーザ２０ｃ、及び端末装置２０ｄに対応するユーザをユーザ２０ｄという。

【0012】

なお、図１に示す管理サーバ１０及びデータベース１３は概念的構成であり、物理的に１つの装置として実現されてもよいし、物理的に複数の装置によって実現されてもよい。例えば、管理サーバ１０内にデータベース１３が備えられていてよい。また、複数の端末装置２０のいずれかが、管理サーバ１０のハードウェア構成及び処理の一部或いは全部を担うことにより、管理サーバ１０が実現されてもよい。或いは、管理サーバ１０のハードウェア構成及び処理の全てを複数の端末装置２０に分散させて管理サーバ１０が実現されてもよい。

【0013】

２．管理サーバのハードウェア構成
管理サーバ１０のハードウェア構成の一例について図２を用いて説明する。管理サーバ１０は上述したように概念的存在であるため、図２に示すハードウェア構成及びその動作は、例えば、複数のサーバ装置によって実現されてよい。或いは、当該ハードウェア構成及びその動作の一部或いは全部は、複数の端末装置２０の少なくとも一部に分散させて実現されてもよい。

【0014】

管理サーバ１０は、例えば、サーバ制御部１１及びサーバ送受信部１２を備えていてよい。サーバ制御部１１とサーバ送受信部１２とは、相互にデータ通信可能であり、例えば、データバス１４を介して接続されていてよい。更に、管理サーバ１０は、例えば、システム運用管理者の各種操作を受け付け、各種データをシステム運用管理者に対して出力する不図示のデータ入出力部を備えていてよい。

【0015】

サーバ送受信部１２は、例えば、管理サーバ１０の外部構成（例えば、各端末装置２０）とインターネット１００を介して各種データの送受信を行う。サーバ制御部１１は、管理サーバ１０によって実行される各処理を制御するように構成されている。サーバ制御部１１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｅｃｓｓｉｎｇ Ｕｎｉｔ）と、その動作に必要な記憶域であるＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）及びＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）とで構成されるコンピュータユニットとして構成されてよい。

【0016】

サーバ制御部１１は、例えば、ＲＯＭに記憶されたコンピュータプログラムを読み込み、実行してよい。また、サーバ制御部１１は、例えば、コンピュータで読み取り可能な不揮発性記録媒体が記憶しているコンピュータプログラムを、不図示の記録媒体読み取り装置を用いて読み込んでもよい。サーバ制御部１１は、インターネット１００を介して、管理サーバ１０の外部に配置される不図示の装置からコンピュータプログラムを読み込んでもよい。サーバ制御部１１は、読み込んだコンピュータプログラムを実行する。その結果、サーバ制御部１１内には、管理サーバ１０が行うべき動作を実行するための論理的な機能ブロックが実現される。つまり、サーバ制御部１１は、管理サーバ１０が行うべき動作を実行するための論理的な機能ブロックを実現するためのコントローラとして機能可能である。図２には、サーバ制御部１１内に実現される論理的な機能ブロックの一例が示されている。図２に示すように、サーバ制御部１１内には、例えば、ユーザ情報管理部１１１と、リクエスト配信部１１２と、アクセプト受信部１１３と、決定部１１４と、確認部１１５とが実現されてよい。各部１１１～１１５の動作については後述する。

【0017】

３．データベースが保持するデータ
データベース１３は、管理サーバ１０によって行われる各種処理に必要な各種データを保持する。データベース１３には、図３に示すように、例えば、ユーザ情報１３１、リクエスト情報１３２等が記憶されてよい。ユーザ情報１３１には、買物代行斡旋システム１を利用する各ユーザに関する情報が登録されている。ユーザ情報１３１は、例えば、図３に示すように、各ユーザを識別するユーザＩＤに、委託回数１３１ａ、受託回数１３１ｂ、利用指標１３１ｃ、及び個人情報１３１ｄが対応付けられて構成されてよい。委託回数１３１ａは、ユーザが買物代行を過去に委託した回数に関する情報を示す。受託回数１３１ｂは、ユーザが買物代行を過去に受託した回数に関する情報を示す。委託回数１３１ａ及び受託回数１３１ｂのそれぞれは、累計数の他、例えば日、月又は年等の任意の集計単位で時系列に集計可能なように、委託ごと又は受託ごとの時間情報も保持していることが望ましい。利用指標１３１ｃは、ユーザに関して買物代行斡旋システム１の利用傾向（即ち、受託が多い傾向か委託が多い傾向か）を示す指標である。利用指標１３１ｃは、委託回数１３１ａと受託回数１３１ｂとの関係に基づいて設定されてよい。利用指標１３１ｃとして、例えば、委託回数と受託回数との合計（以下「利用回数」という。）に対する委託回数の割合を委託程度、及び利用回数に対する受託回数の割合を受託程度が含まれてよい。また、受託程度及び委託程度のそれぞれは、例えば、程度を段階的に分類したレベル値で示されてもよい。委託回数１３１ａ、受託回数１３１ｂ、及び利用指標１３１ｃは、買物代行斡旋システム１の利用の傾向をユーザに可視化して示す際に使用されてよい。以下、委託回数１３１ａ、受託回数１３１ｂ、及び利用指標１３１ｃを利用傾向情報という。個人情報１３１ｄには、例えば、ユーザの氏名、住所、及び端末装置２０を介して連絡可能な連絡先情報（例えば、メールアドレス等）、等が含まれてよい。

【0018】

リクエスト情報１３２は、委託された買物代行に関する情報を保持する。買物代行の委託を希望するユーザ（即ち、委託者）が管理サーバ１０に向けて送信するリクエストに基づいた情報である。リクエスト情報１３２には、例えば、図３に示すように、各リクエストを識別するリクエストＩＤに、委託者としてのユーザのユーザＩＤ、依頼内容１３２ａ及びステータス１３２ｂ等が対応付けられていてよい。依頼内容１３２ａには、例えば、購入依頼商品（即ち、買物代行の対象となる商品）、購入希望個数、受取希望期限、購入希望場所（例えば、店舗情報）等が含まれてよい。ステータス１３２ｂは、対応するリクエストの現在のステータスを示す。ステータスには、例えば、買物代行の受託希望者を受付中である状態を示す「受付中」、正式な受託者が決定された状態を示す「決定済」、及び買物代行が完了した状態を示す「代行完了」等が含まれる。

【0019】

４．サーバ制御部の動作
図２に戻り、サーバ制御部１１が実現する各部１１１～１１５の動作について説明する。なお、各部１１１～１１５における送受信は、サーバ送受信部１２を介した送受信である。ユーザ情報管理部１１１は、ユーザ情報１３１の登録及び更新を管理する。例えば、ユーザ情報管理部１１１は、新規ユーザの登録を受け付け、当該新規ユーザに関するユーザ情報１３１を記憶してよい。これにより、新規ユーザは、買物代行斡旋システム１のユーザとして登録されたことになる。また、ユーザ情報管理部１１１は、買物代行が完了される度に、例えば、委託回数１３１ａ、受託回数１３１ｂ、及び利用指標１３１ｃを更新し、各ユーザが自己の利用傾向を認識可能なように適宜のタイミングで端末装置２０に表示させてよい。

【0020】

リクエスト配信部１１２は、買物代行のリクエストを配信する。リクエスト配信部１１２は、例えば、買物代行の委託者に対応する端末装置２０からのリクエストを受信すると、当該リクエストを当該委託者以外のユーザに対応する端末装置２０に配信してよい。アクセプト受信部１１３は、例えば、リクエストを受信した端末装置２０から、当該リクエストの受託を希望することを示すアクセプトを受信してよい。

【0021】

決定部１１４は、買物代行の正式な受託者を決定する。決定部１１４は、例えば、アクセプトを送信した端末装置２０に対応するユーザから、所定の条件を満たすユーザを、正式な受託者として決定してよい。決定部１１４は、正式な受託者を決定した後、例えば、アクセプトを送信した各端末装置２０に、決定通知を送信してよい。確認部１１５は、買物代行の完了を確認する。確認部１１５は、例えば、正式な受託者によって買物代行が完了したことを示す完了通知を受信すると、当該完了が確認されたと判断してよい。

【0022】

５．端末装置のハードウェア構成
端末装置２０の基本的なハードウェア構成の一例について図４を用いて説明する。端末装置２０は、例えば、端末送受信部２１、データ入力部２２、データ出力部２３、及び端末制御部２４を備えていてよい。端末送受信部２１と、データ入力部２２と、データ出力部２３と、端末制御部２４とは、例えばデータバス２５を介してデータ通信可能に接続されてよい。端末送受信部２１は、例えば、管理サーバ１０等の端末装置２０の外部構成と各種データの送受信をインターネット１００を介して行うように構成されてよい。データ入力部２２は、例えば、端末装置２０の操作者としてのユーザからの各種データのデータ入力を受け付けるように構成されてよい。データ入力には、例えば、キーボードやマウス等の各種入力機器を介した入力、タッチパネルやボタン等への接触入力や非接触入力、及び音声入力等が含まれる。データ出力部２３は、例えば、端末装置２０の操作者に対して、各種データを出力するように構成されてよい。データ出力には、画面出力、及び音声出力等が含まれる。

【0023】

端末制御部２４は、他の各部２１、２２、２３の動作を制御することにより、端末装置２０における各処理を制御するように構成されている。端末制御部２４は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｅｃｓｓｉｎｇ Ｕｎｉｔ）と、その動作に必要な記憶域であるＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）及びＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）とで構成されるコンピュータユニットとして構成されてよい。端末制御部２４は、例えば、管理サーバ１０のユーザインターフェースとして機能してよい。端末制御部２４は、例えば、管理サーバ１０からの指示に従って、ユーザにデータを入力させ、入力されたデータを管理サーバ１０に送信してよい。また、端末制御部２４は、例えば、管理サーバ１０からの指示に従って、管理サーバ１０からのデータを取得し、取得したデータをユーザに対して出力してよい。なお、端末制御部２４は、サーバ制御部１１の上述した各部１１１～１１５の少なくとも一部を実現するように構成されてもよい。端末制御部２４は、端末送受信部２１を介して、例えば、リクエスト及び決定通知等を受信し、アクセプト及び完了通知等を送信する。

【0024】

６．買物代行斡旋システムで行われる処理
買物代行斡旋システム１において行われる処理について、サーバ制御部１１が行う処理を中心にして、図５～図７を用いて説明する。

【0025】

図５は、買物代行斡旋システム１で行われる買物代行斡旋に関する処理ルーチンの一例を示すフローチャートである。まず、サーバ制御部１１は、ユーザ登録処理を行う（ステップＳ１０１）。ユーザ登録処理では、買物代行斡旋システム１を利用するユーザの登録が行われる。ユーザ登録処理は、例えば、ユーザ情報管理部１１１によって行われてよい。例えば、買物代行斡旋システム１への登録を希望するユーザが、登録リクエストを管理サーバ１０に送信すると、ユーザ情報管理部１１１は、受信した登録リクエストに応じて、ユーザ登録処理を行ってよい。ユーザ情報管理部１１１は、ユーザ登録処理として、例えば、当該登録を希望するユーザにユーザＩＤを付与し、端末装置２０を介して氏名や住所等の個人情報１３１ｄを取得し、取得した個人情報１３１ｄをユーザＩＤに対応付けてユーザ情報１３１に設定してよい。

【0026】

続いて、サーバ制御部１１は、代行受託者処理を行ってよい（ステップＳ１０２）。代行受託者処理では、買物代行の委託受付から正式な受託者の決定まで行われる。代行受託者処理につて、図６及び図７を参照して説明する。以下の説明において、管理サーバ１０によって行われる処理は、サーバ制御部１１の制御によって行われる処理である。

【0027】

買物代行を委託するリクエストの受信待ち状態（ステップＳ２００）の管理サーバ１０は、端末装置２０（本形態では、端末装置２０ａ）からリクエストが管理サーバ１０へ送信されると、当該リクエストを受信する（ステップＳ２００：Ｙｅｓ、ステップＳ２０１）。リクエストには、例えば、買物代行の委託者としてのユーザ（本形態では端末装置２０ａのユーザ２０ａ）のユーザＩＤ、及び買物代行の依頼内容１３２ａ（即ち、購入依頼商品、購入希望個数、受取希望期限、購入希望場所等）を示す情報等が含まれてよい。

【0028】

リクエストを受信した管理サーバ１０は、例えば、受信したリクエストに、リクエストＩＤを付与し、当該リクエストに関するリクエスト情報１３２を生成してよい。管理サーバ１０は、リクエスト情報１３２を生成すると、例えば、この段階のステータス１３２ｂを「受付中」としてよい。続いて、管理サーバ１０は、端末装置２０ａから受信したリクエストを、端末装置２０ａを除いた買物代行斡旋システム１内の全端末装置２０に配信してよい（ステップＳ２０２）。本実施形態の場合、管理サーバ１０は、依頼内容１３２ａを含むリクエストを端末装置２０ｂ～２０ｄへ配信する。配信されるリクエストには、例えば、リクエストに対応するユーザＩＤ及びリクエストＩＤが含まれてよい。

【0029】

リクエストを管理サーバ１０から受信した端末装置２０では、例えば、ユーザの操作に応じて、図７に示すようなリクエスト画面７０が表示されてよい。表示されたリクエスト画面７０により、ユーザに、買物代行の内容を確認させ、買物代行を受託するか否かを検討させることができる。リクエスト画面７０には、例えば、リクエスト詳細７０ａとして、委託者氏名、委託者住所、及び依頼内容１３２ａが表示されてよい。なお、この段階では、委託者氏名及び委託者住所は、個人情報保護法の観点から、氏名や住所が特定されないように表示されることが望ましい。また、管理サーバ１０は、例えば、各端末装置２０へリクエストを配信する際に、対応するユーザの利用傾向情報も送信してリクエスト画面７０に利用傾向７０ｂとして表示させてよい。これにより、ユーザに、そのユーザの利用傾向が可視化され、当該利用傾向をユーザに視覚的に認識させることができる。

【0030】

利用傾向７０ｂの表示態様は、ユーザに自己の利用傾向を認識させ得る、或いは当該利用傾向の認識を誘導させ得る態様であればよい。当該表示態様としては、例えば、委託回数１３１ａ及び受託回数１３１ｂ、及び／又は利用指標１３１ｃが保持する数値がそのまま、或いは所定の統計手法に基づいた統計値で表示されてよい。或いは、利用傾向７０ｂの表示態様は、グラフ、表、ゲージ等でもよい。例えば、利用傾向７０ｂは、受託程度及び委託程度を色分けしてその濃淡で利用傾向が認識されるように示されてもよい。また、利用傾向７０ｂには、所定期間（例えば、直近６か月）或いは、ユーザの指定期間における利用傾向が示されてよい。例えば、利用傾向７０ｂは、委託回数１３１ａ及び受託回数１３１ｂ、及び／又は利用指標１３１ｃが保持する数値に基づいて、直近６か月間の月別集計グラフのようにグラフ化されて示されてもよい。利用傾向７０ｂがリクエスト画面７０に表示されることにより、ユーザは、依頼内容だけでなく自己の利用傾向も確認した上で、表示されているリクエストを受託するかしないかを決定することができる。

【0031】

リクエスト画面７０には、更に、図７に示すように纏め買い割引情報７０ｃも示されてもよい。纏め買い割引情報７０ｃには、買物代行の対象となる商品の纏め買い割引に関する情報として、例えば、割引情報（例えば、対象商品、購入必要個数、及び割引率等）、纏め買い割引を提供する店舗の店舗情報（例えば、店舗名及び場所等）、及び委託者の購入希望個数が示されてよい。図７に示す例では、纏め買い情報７０ｃに、店舗Ａで５個買うと３割引になる対象商品Ｂについて、委託者の購入希望個数が３個であることが示されている。この場合、対象商品Ｂが店舗Ａであと２個一緒に購入されれば、纏め買い割引が適用され、３割引になることを意味している。従って、対象商品Ｂの購入を希望し、かつ店舗Ａでの買物が可能なユーザに対して、表示されているリクエストを受託するモチベーションを上げることができる。

【0032】

なお、纏め買い情報７０ｃは、例えば、委託者の入力操作により委託者から送信されるリクエストの依頼内容１３２ａに含ませることにより、リクエスト画面７０上に表示されてよい。或いは、管理サーバ１０が不図示の店舗システムと連携して、リクエストが示す購入依頼商品に関する纏め買い情報を当該店舗システムから取得して、纏め買い情報を配信するリクエストの依頼内容１３２ａに含ませることにより、纏め買い情報７０ｃがリクエスト画面７０に表示されてよい。

【0033】

表示されたリクエストの受託を希望するユーザは、例えば、「受託を希望する」のチェックボックス７０ｄにチェックを入れる。これにより、当該受託を希望することを示すアクセプトが管理サーバ１０に送信される。このように、アクセプトは、買物代行の受託を希望するユーザ（即ち、受託希望者）の操作に応じて端末装置２０から送信されてよい。アクセプトには、例えば、受託を希望するリクエストのリクエストＩＤ及び受託希望者のユーザＩＤが含まれてよい。

【0034】

管理サーバ１０は、リクエストを配信した後、例えば、所定の受付制限内で、端末装置２０からのアクセプトを受信可能にする（ステップＳ２０３）。受付制限は、例えば、時間的期限でもよいし、アクセプトの受信数の上限でもよい。本形態では、リクエストを受信した端末装置２０ｂ～２０ｄのうち、端末装置２０ｃ及び端末装置２０ｄからアクセプトが送信され、これらが管理サーバ１０で受信されている。この場合、端末装置２０ｃのユーザ２０ｃ及び端末装置のユーザ２０ｄが買物代行の受託希望者として、アクセプトを送信したことを示す。

【0035】

続いて、管理サーバ１０は、受託希望者の中から、所定の条件を満たすユーザを正式な受託者として決定する（ステップＳ２０４）。例えば、受け付けたアクセプトが１つだけの場合、即ち、受託希望者が一人だけの場合、管理サーバ１０は、その受託希望者を正式な受託者として決定してよい。アクセプトを２つ以上受け付けた場合、即ち、受託希望者が２人以上いる場合、管理サーバ１０は、例えば、正式な受託者を先着順に決定してよい。或いは、管理サーバ１０は、委託者に住所が最も近い受託希望者を正式な受託者に決定してよい。或いは、管理サーバ１０は、各受託希望者の利用指標１３１ｃを参照して、受託程度（又は、受託レベル）が最も低いユーザを正式な受託者として決定してよい。

【0036】

管理サーバ１０は、正式な受託者を決定後、受託希望者の各端末装置２０、即ちアクセプトを送信した各端末装置２０に決定通知を送信してよい。本形態では、管理サーバ１０は、決定通知を、アクセプトを送信した端末装置２０ｃ及び端末装置２０ｄに送信する。例えば、端末装置２０ｃのユーザ２０ｃが正式な受託者として決定された場合、端末装置２０ｃへ送信される決定通知は、ユーザ２０ｃが正式な受託者として決定されたことを示してよい。また、正規な受託者として決定されたユーザに送信される決定通知には、委託者の氏名及び住所が特定され得る情報が含まれていてよい。一方、正式な受託者として決定されなかったユーザ２０ｄの端末装置２０ｄへ送信される決定通知は、ユーザ２０ｄが正式な受託者として決定されなかったことを示してよい。更に、管理サーバ１０は、正式な受託者を決定後、対応するリクエストのステータス１３２ｂを「決定済」に更新してよい。

【0037】

ステップＳ２０１～ステップＳ２０２における処理は、サーバ制御部１１のリクエスト配信部１１２によって行われる。ステップＳ２０３における処理は、サーバ制御部１１のアクセプト受信部１１３によって行われる。また、ステップＳ２０４における処理は、サーバ制御部１１の決定部１１４によって行われる。

【0038】

図５に戻り、サーバ制御部１１は、代行受託者処理（ステップＳ１０２）後、例えば、買物代行の完了を示す完了通知の受信待ち状態となってよい（ステップＳ１０３）。完了通知は、例えば、買物代行に係る購入依頼商品を受け取った委託者（本形態では、ユーザ２０ａ）による操作に応じて端末装置２０（本形態では、端末装置２０ａ）から管理サーバ１０へ送信されてよい。或いは、完了通知は、例えば、買物代行に係る購入依頼商品を委託者（本形態では、ユーザ２０ａ）に渡した際に、正式な受託者（本形態では、ユーザ２０ｃ）による操作に応じて端末装置２０（本形態では、端末装置２０ｃ）から管理サーバ１０へ送信されてよい。

【0039】

サーバ制御部１１は、完了通知を受信後（ステップＳ１０３：Ｙｅｓ）、例えば、指標処理を行ってよい（ステップＳ１０４）。指標処理では、ユーザ情報１３１の更新が行われる。例えば、サーバ制御部１１のユーザ情報管理部１１１は、委託者（本形態ではユーザ２０ａ）の委託回数１３１ａを更新する（例えば、委託回数累計をカウントアップし、買物代行の完了日を時間情報に追加する）とともに、当該更新に伴ってユーザ２０ａの利用指標１３１ｃを更新する。また、ユーザ情報管理部１１１は、正式な受託者（本形態ではユーザ２０ｃ）の受託回数１３１ｂを更新する（例えば、受託回数累計をカウントアップし、買物代行の完了日を時間情報に追加する）とともに、当該更新に伴ってユーザ２０ｃの利用指標１３１ｃを更新してよい。また、サーバ制御部１１は、完了通知を受信後、例えば、対応するリクエストのステータス１３２ｂを「代行完了」に設定してよい。

【0040】

以上により買物代行斡旋に係る処理ルーチンが終了する。なお、複数のユーザに関するユーザ情報１３１が存在する状態においては、サーバ制御部１１は、ステップＳ１０２以降における処理を、ステップＳ１０１のユーザ情報登録処理とは独立した処理ルーチンで行ってよい。

【0041】

利用傾向７０ｂは、リクエスト画面７０上だけでなく、適宜のタイミングで端末装置２０に表示されてよい。例えば、ユーザの端末装置２０に対する表示要求操作に応じて、その時点でのそのユーザの利用傾向７０ｂが表示されてよい。これにより、ユーザは自己の利用傾向７０ｂを任意のタイミングで確認することができる。また、委託者としてのユーザが買物代行を委託する画面において、そのユーザの利用傾向７０ｂが表示されるように構成されてよい。これにより、ユーザに、自己の利用傾向７０ｂを認識させた上で、委託を決定させることができる。このように、各ユーザに自己の利用傾向７０ｂを適宜のタイミングで認識させることにより、ユーザの利用傾向が委託又は受託の一方に偏らないようにユーザを誘導することができる。また、買物代行斡旋システム１において、ユーザ情報１３１は利用指標１１ｃを含まず、利用指標１３１ｃが示す情報は委託回数１３１ａ及び受託回数１３１ｂに基づいて適宜算出されて導かれるように構成されてよい。

【0042】

ユーザ情報１３１の個人情報１３１ｄには、例えば、ユーザの年齢又は年代も含まれてよい。この場合、ユーザ情報管理部１１１は、例えば、年代別にグループ化し、グループ別に、代行受託者処理（図５：ステップＳ１０２）～指標処理（図５：ステップＳ１０４）を行ってよい。同じ年代のユーザ間では、購入したい商品や使用している商品が相互に似通っているため、ユーザが気軽に買物代行の委託や受託をできる環境を提供することができる。

【0043】

リクエスト情報１３２のステータス１３２ｂが「受付中」のリクエストが２つ以上存在する場合、リクエスト配信部１１２は、例えば、「受付中」のリクエストの一覧を、いずれか１つのリクエストを選択可能に端末装置２０に表示させ、選択されたリクエストに関してリクエスト画面７０（図７）を表示させてもよい。また、端末装置２０において当該一覧が表示される際に、例えば、端末制御部２４は、各リクエストが示す購入依頼商品に基づいて、商品の種類別又は商品が購入可能な店舗の種類別に分類されたフォーマットで、リクエストの一覧を表示可能なように、表示制御を行ってよい。この場合、例えば、端末制御部２４は、管理サーバ１０又は各端末装置２０が保持する、商品とその商品が購入可能な店舗が対応付けられた店舗リストに基づいて、各リクエストが示す購入依頼商品を購入可能な店舗を特定してよい。また、例えば、端末制御部２４は、依頼内容１３２ａに購入希望場所として示されている店舗を「購入可能な店舗」として特定してよい。

【0044】

以上詳細に説明したように、第１実施形態によれば、各ユーザに対して、過去の買物代行の利用傾向を可視化して示すことで、個々のユーザにおける委託回数及び受託回数の均衡、或いは代行利用及び援助間の公平性が図られるように誘導できる。

【0045】

＜第２実施形態＞
図８及び図９を参照して、第２実施形態について説明する。ここに図８及び図９はそれぞれ、第１実施形態に係る図２及び図５と同趣旨の図面であり、図８及び図９において、図２及び図５に示した第１実施形態と同様の構成要素に対しては同様の参照符号を付し、それらの説明は適宜省略する。第２実施形態では、委託回数と受託回数との関係が第１条件を満たすユーザ（以下、第２実施形態において「対象ユーザ」という。）に対して特典が付与されるように構成されている。付与される特典としては、例えば、特定店舗での割引特典、特定店舗でのプレゼント特典等がある。

【0046】

サーバ制御部１１には、図８に示すように、特典提供部１１６が更に設けられている。特典提供部１１６は、例えば、対象ユーザに対して特典を付与し、当該特典に関する情報を対象ユーザの個人情報１３１ｄに追加してよい。第１条件は、受託することが委託より相対的に多いユーザに特典が付与されるように設定されてよい。例えば、第１条件として、所定期間内の受託回数が委託回数より多くその差が所定基準以上、或いは、受託程度（又は、受託レベル）が所定基準以上、等がある。

【0047】

特典提供部１１６が行う処理について説明する。特典提供部１１６は、例えば、図９に示すように、指標処理（ステップＳ１０４）でユーザ情報１３１が更新された後、正式な受託者であるユーザの委託回数と受託回数との関係が第１条件を満たすか否かを判定してよい（ステップＳ５０１）。特典提供部１１６は、当該判定のために委託回数１３１ａ及び受託回数１３１ｂ、並びに／又は利用指標１３１ｃを参照してよい。当該関係が第１条件を満たさない場合（ステップＳ５０１：Ｎｏ）、特典提供部１１６は、処理対象の買物代行に関する処理ルーチンを終了してよい。一方、当該関係が第１条件を満たす場合（ステップＳ５０１：Ｙｅｓ）、特典提供部１１６は、特典提供処理を行ない（ステップＳ５０２）、その後、処理対象の買物代行に関する処理ルーチンを終了してよい。

【0048】

上述したように、特典提供部１１６は、ステップＳ５０２において、対象ユーザに特典を付与する特典提供処理を行ってよい。特典提供部１１６は、特典提供処理として、例えば、特典を示す特典クーポンを対象ユーザに発行し、対象ユーザの個人情報１３１ｄに設定してよい。特典クーポンには、例えば、特典内容及び特典が提供される店舗（以下、「対象店舗」という）が示されてよい。例えば、特典提供部１１６は、対象ユーザに特典が付与されたことを通知してよい。

【0049】

対象ユーザは、例えば、付与された特典クーポンを印刷して又は画面表示して提示することにより、対象店舗での特典を受けることが可能となる。例えば、割引特典の場合は、対象ユーザに対象店舗での商品購入の割引が提供されてよい。或いは、プレゼント特典の場合は、対象ユーザに対象店舗で所定商品がプレゼントされてよい。以上のように、第２実施形態によれば、援助することが多いユーザに対して特典を付与することで、代行利用及び援助間の不均衡を経済的な価値で埋めることができる。

【0050】

＜第３実施形態＞
図１０及び図１１を参照して、第３実施形態について説明する。ここに図１０及び図１１はそれぞれ、第１実施形態に係る図２及び図５と同趣旨の図面であり、図１０及び図１１において、図２及び図５に示した第１実施形態と同様の構成要素に対しては同様の参照符号を付し、それらの説明は適宜省略する。第３実施形態では、委託回数と受託回数との関係が第２条件を満たすユーザ（以下、第３実施形態において「対象ユーザ」という。）に対して、買物代行斡旋システム１の利用料金（以下、「システム利用料」という。）が発生するように構成されている。

【0051】

サーバ制御部１１には、図１０に示すように、料金要求部１１７が更に設けられている。料金要求部１１７は、例えば、対象ユーザに対して、システム利用料を発生させ、システム利用料の発生を示す情報を対象ユーザの個人情報１３１ｄに追加してよい。第２条件は、委託することが受託より相対的に多いユーザにシステム利用料を発生させるように設定されてよい。第２条件として、例えば、所定期間内の委託回数が受託回数より多くその差が所定基準以上、或いは、委託程度（又は、委託レベル）が所定基準以上、等がある。

【0052】

料金要求部１１７が行う処理について説明する。料金要求部１１７は、例えば、図１１に示すように、指標処理（ステップＳ１０４）でユーザ情報１３１が更新された後、委託者であるユーザの委託回数と受託回数との関係が第２条件を満たすか否かを判定してよい（ステップＳ６０１）。料金要求部１１７は、当該判定のために、委託回数１３１ａ及び受託回数１３１ｂ、並びに／又は利用指標１３１ｃを参照してもよい。当該関係が第２条件を満たさない場合（ステップＳ６０１：Ｎｏ）、料金要求部１１７は、、処理対象の買物代行に関する処理ルーチンを終了してよい。一方、当該関係が第２条件を満たす場合（ステップＳ６０１：Ｙｅｓ）、料金要求部１１７は、料金要求処理を行ない（ステップＳ６０２）、その後、、処理対象の買物代行に関する処理ルーチンを終了してよい。

【0053】

上述したように、料金要求部１１７は、ステップＳ６０２において、対象ユーザにシステム利用料を発生させる料金要求処理を行ってよい。料金要求部１１７は、料金要求処理として、例えば、対象ユーザに、上記関係に応じた金額のシステム利用料を発生させてよい。例えば、システム利用料は、委託回数と受託回数との差に比例して設定されてよい。料金要求部１１７は、例えば、対象ユーザにシステム利用料の要求対象であることを通知してよい。料金要求部１１７は、例えば、発生したシステム利用料を対象ユーザの個人情報１３１ｄに追加して対応する処理ルーチンを終了し、対象ユーザが買物代行斡旋システム１に再びアクセスした際に、当該システム利用料を要求してよい。或いは、料金要求部１１７は、対応する処理ルーチンのステップＳ６０２の料金要求処理において、発生したシステム利用料を対象ユーザに要求してよい。

【0054】

料金要求部１１７は、例えば、要求したシステム利用料の支払いを不図示の金融機関システムを介して確認するまで、対象ユーザに対して買物代行斡旋システム１の利用を禁止し、当該支払いを確認後、対象ユーザに対して買物代行斡旋システム１の利用を許可するように構成されてよい。以上のように、第３実施形態によれば、援助することが少ないユーザに対してシステム利用料を要求することなどで、代行利用及び援助間の不均衡を経済的な価値で埋めることができる。

【0055】

付記
以上説明した実施形態に関して、更に以下の付記を開示する。

【0056】

［付記１］
本発明に係る付記１に記載の買物代行斡旋システムは、複数のユーザのそれぞれに対応する端末装置を含み、買物代行を委託する委託者及び該買物代行を受託する受託者間における該買物代行を斡旋する買物代行斡旋システムであって、前記委託者及び前記受託者の少なくとも一方になり得る前記複数のユーザのそれぞれに関する情報であるユーザ情報を管理するユーザ情報管理部と、前記複数のユーザのうち前記委託者としてのユーザに係る前記端末装置からのリクエストを、前記複数のユーザのうち前記委託者を除くユーザに係る前記端末装置に、配信するリクエスト配信部と、配信された前記リクエストに応じて前記端末装置から送信された、前記買物代行の受託を希望することを示すアクセプトを受信するアクセプト受信部と、前記アクセプトを送信した前記端末装置に係る前記ユーザから、正式な受託者を決定する決定部と、前記正式な受託者による前記買物代行の完了を確認する確認部とを備え、前記ユーザ情報管理部は、前記確認部により前記買物代行の完了が確認されると、前記ユーザ情報に含まれる前記委託者に係る委託回数を更新するとともに前記ユーザ情報に含まれる前記正式な受託者に係る受託回数を更新し、前記委託回数及び前記受託回数に基づいた各前記ユーザの利用傾向を、前記端末装置に表示可能に構成されている、買物代行斡旋システムである。

【0057】

付記１に記載の買物代行斡旋システムによれば、買物代行の委託者と受託者とがマッチングされて買物代行が実現されるとともに、各ユーザの委託回数及び受託回数が管理され、当該委託回数及び受託回数に基づいた「利用傾向」が各ユーザに対して表示可能にされる。「利用傾向」は、対応するユーザの委託回数及び受託回数に基づいて得られる買物代行斡旋システムの利用の傾向を示す情報である。この「利用傾向」が可視化されてユーザに示されることにより、各ユーザに、委託が多い傾向か、或いは受託が多い傾向かを認識させることができる。これにより、例えば無償で買物代行が提供される環境であっても、個々のユーザにおける委託回数及び受託回数の均衡、或いは代行利用及び援助間の公平性が図られるように誘導できる。特に、利用料金の授受がない環境で当該公平性を得るために有効である。なお、「利用傾向」は、委託回数及び受託回数のみによって導かれる情報でもよいし、委託回数及び受託回数に他の情報も加えて導かれる情報でもよい。

【0058】

［付記２］
本発明に係る付記２に記載の買物代行斡旋システムは、前記受託回数と前記委託回数との関係が第１条件を満たすユーザに対して、特定の店舗で提供される特典を付与する特典提供部を更に備える、ことを特徴とする、付記１に記載の買物代行斡旋システムである。

【0059】

付記２に記載された買物代行斡旋システムによれば、例えば、受託することが委託より相対的に多いユーザに、特典を付与することが可能になるので、買物代行の受託のモチベーションを上げることが可能となる。特典として、例えば、商品の割引特典、プレゼント特典等が考えられる。これにより、代行利用及び援助間の不均衡を経済的な価値で埋めることができる。

【0060】

［付記３］
本発明に係る付記３に記載の買物代行斡旋システムは、前記委託回数と前記受託回数との関係が第２条件を満たすユーザに対して、システム利用料を要求する料金要求部を更に備える、ことを特徴とする付記１に記載の買物代行斡旋システムである。

【0061】

付記３に記載された買物代行斡旋システムによれば、例えば、委託することが受託より相対的に多いユーザに、システム利用料を要求することが可能になる。これにより、代行利用及び援助間の不均衡を経済的な価値で埋めることができる。また、例えば、外出困難な事情があり買物代行の受託ができないユーザに、他のユーザに対して引け目を感じさせず、本システムに参加しやすい環境を提供することが可能となる。

【0062】

［付記４］
本発明に係る付記４に記載の買物代行斡旋システムは、前記リクエストに、纏め買い割引が提供される前記買物代行の対象となる商品の割引情報及び該纏め買い割引を提供する店舗の店舗情報が含まれる、ことを特徴とする付記１に記載の買物代行斡旋システムである。

【0063】

付記４に記載された買物代行斡旋システムによれば、纏め買い割引の対象となる商品については、リクエストに、当該割引に関する割引情報及び当該割引を提供する店舗の店舗情報が含まれるので、纏め買い割引に関する情報を端末装置に表示させることができる。従って、買物代行の受託を検討するユーザは、その纏め買い割引に関する情報を知ることができる。これにより、纏め買い割引の恩恵を、委託者と受託者とで享受可能な環境を提供することができる。なお、纏め買いに関する情報（割引情報及び店舗情報等）は、ユーザにより提供されてもよいし、店舗から提供されてもよい。

【0064】

［付記５］
本発明に係る付記５に記載の買物代行斡旋システムは、前記端末装置は、前記買物代行の対象となる商品の種類別又は該商品が購入可能な店舗の種類別に分類されたフォーマットで、前記リクエストを表示可能に構成されている、ことを特徴とする付記１に記載の買物代行斡旋システムである。

【0065】

付記５に記載された買物代行斡旋システムによれば、ユーザは、複数のリクエストを端末装置にて見る際に、買物代行の対象となる商品の種類別、又は当該商品を購入可能な店舗別にまとめたフォーマットで見ることができる。従って、買物代行の受託を検討中のユーザに、複数のリクエストから所望のリクエストを検索しやすい環境を提供することができる。

【0066】

本発明は、請求の範囲及び明細書全体から読み取るこのできる発明の要旨又は思想に反しない範囲で適宜変更可能であり、そのような変更を伴う買物代行斡旋システムもまた本発明の技術思想に含まれる。

【符号の説明】

【0067】

買物代行斡旋システム……１
管理サーバ…１０
端末装置…２０
ユーザ情報管理部…１１１
リクエスト配信部…１１２
アクセプト受信部…１１３
決定部…１１４
確認部…１１５

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】