JP2023174381A - 荷物配送の委託支援方法および委託支援システム - Google Patents

Abstract

【課題】手荷物の配送作業の円滑な実行に配慮しつつ、配送依頼者と配送請負者とのマッチングの成立を支援すること。【解決手段】荷物の配送委託を支援する委託支援システム（１）のコンピュータ（２０）が実行する委託支援方法は、配送依頼者からの荷物の配送依頼を端末装置（３）から受信する受信ステップ（Ｓ１００）と、受信した配送依頼に対する配送請負者のマッチングを行うマッチングステップ（Ｓ１０６）と、上記配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する配送先情報取得ステップ（Ｓ１０２）と、受入可否情報を取得できない場合に、配送先が備える装置（６）及び又は配送依頼者の端末装置に所定の報知を出力させる報知ステップ（Ｓ１１４）と、を含む。【選択図】図５

Description

本発明は、荷物の配送を依頼する配送依頼者と荷物の配送を請け負う配送請負者とのマッチングを行う、荷物配送の委託支援方法および委託支援システムに関する。

近年、交通参加者の中でも高齢者や子供といった脆弱な立場にある人々にも配慮した持続可能な輸送システムへのアクセスを提供する取り組みが活発化している。この実現に向けて、特に荷物運搬希望者向けの移動手段に関する開発を通して交通の安全性や利便性をより一層改善する研究開発に注力している。
特許文献１には、クラウドソースにより調達されるクラウドソース配送員と、クラウドソース以外の方法で調達される非クラウドソース配送員と、を含む配送員による、複数の配送対象についての配送計画を作成する配送計画プログラムが開示されている。

特開２０２０－６１０２９号公報

ところで、荷物運搬希望者向けの移動手段が用いられるシーンとして、例えば、旅行者が、観光地に到着して観光を開始する場合において、身軽な状態で観光ができるように、観光地への移動に際し手荷物等の一部を手放して宿泊先等へ配送したい場合がある。このような場合、インターネットを通じて仕事を発注することのできる、いわゆるギグワーカに手荷物等の配送を迅速に依頼できれば便宜である。

そのような、手荷物の配送を依頼する配送依頼者と、手荷物配送を請け負う配送請負者とのマッチングを行うサービスにおいては、配送先が手荷物を受け入れられない状態のときにマッチングや手荷物の回収を進めてしまうと、配送請負者は配送作業をスムーズに進めることができず、配送請負者にとって負担となり得る。

本発明の目的は、手荷物の配送作業の円滑な実行に配慮しつつ、配送依頼者と配送請負者とのマッチングの成立を支援し得る、委託支援方法又は委託支援システムを実現することである。
本願は、上記課題の解決により、荷物運搬希望者向けの移動手段の利用促進を図り、延いては持続可能な輸送システムの発展に寄与するものである。

本発明の一の態様は、荷物の配送委託を支援する委託支援システムのコンピュータが実行する委託支援方法であって、配送依頼者からの荷物の配送依頼を端末装置から受信する受信ステップと、前記受信した配送依頼に対する配送請負者のマッチングを行うマッチングステップと、前記受信した前記配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する配送先情報取得ステップと、前記受入可否情報を取得できない場合に、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる報知ステップと、を含む、委託支援方法である。
本発明の他の態様によると、前記マッチングステップでは、配送請負者の候補の中から一の配送請負者を決定し、前記報知ステップでは、前記マッチングステップにおいて前記一の配送請負者が決定されたとき、又は前記決定のあとに、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる。
本発明の他の態様によると、前記配送請負者における、前記配送依頼についての配送工程の進捗状況を示す進捗情報を取得する進捗情報取得ステップを含み、前記報知ステップでは、前記進捗情報に基づいて、前記報知の内容を決定する。
本発明の他の態様によると、前記報知ステップでは、前記進捗情報に基づき、前記配送工程が進むにつれて前記報知がより強調されるように、前記報知の態様を変更する。
本発明の他の態様によると、前記配送先情報取得ステップでは、前記配送先が所定の種別であるときに、前記受入可否情報を取得する。
本発明の他の態様によると、前記配送先情報取得ステップでは、前記配送先の種別が宿泊施設であるときは、前記受入可否情報を取得しない。
本発明の他の態様によると、前記報知ステップでは、前記配送先の種別にも基づいて、前記報知を行うか否かを決定する。
本発明の他の態様によると、前記報知ステップでは、前記配送先の種別が宿泊施設である場合には前記報知を行わず、前記配送先の種別がレストラン又はコンビニエンスストアである場合に、前記報知を行う。
本発明の他の態様は、荷物の配送委託を支援する委託支援システムであって、配送依頼者からの荷物の配送依頼を端末装置から受信する受信部と、前記受信した配送依頼に対する配送請負者のマッチングを行うマッチング部と、前記受信した前記配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する配送先情報取得部と、前記受入可否情報を取得できない場合に、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる報知部と、を備える、委託支援システムである。

本発明によれば、手荷物の配送作業の円滑な実行に配慮しつつ、配送依頼者と配送請負者とのマッチングの成立を支援し得る、委託支援方法又は委託支援システムを実現することができる。

本発明の一実施形態に係る委託支援システムの構成を示す図である。 支援サーバの構成の一例を示す図である。 配送依頼者の端末装置における請負候補者リストの表示画面の一例を示す図である。 配送依頼者の端末装置に出力する報知の一例を示す図である。 委託支援システムが実行する委託支援方法における処理の手順を示すフロー図である。

以下、図面を参照して本発明の実施形態について説明する。
［１．委託支援システムの構成］
図１は、本発明に係る、委託支援方法を実行する委託支援システムの構成を示す図である。この委託支援システム１は、委託支援方法を実行して、荷物の配送を依頼する配送依頼者Ｒと、荷物の配送を請け負う複数の配送請負者Ｃと、のマッチングを行う。

委託支援システム１は、支援サーバ２と、配送依頼者Ｒの端末装置３と、複数の配送請負者Ｃの端末装置４と、を含む。
配送依頼者Ｒは、本実施形態では、例えば、観光地の駅に到着して観光を開始しようとする旅行者である。

配送請負者Ｃは、それぞれ、例えば、その配送請負者Ｃが所有する移動体５を用いて、請け負った荷物の配送を行う。移動体５は、例えば、自動車等の四輪車、自転車やバイクなどの二輪車であり得る。なお、荷物配送に用いられる移動体は、車両以外の移動体、例えば、ドローン等の飛翔体や、海上を移動するボートであってもよい。

端末装置３および４は、それぞれ、プロセッサ及びメモリ等で構成されるコンピュータを含み、従来技術に従い、アプリケーション・プログラムを実行することにより、支援サーバ２と協働して、後述する動作を行う。本実施形態では、端末装置３および４は、例えば、スマートホン等の携帯端末である。

支援サーバ２、端末装置３、および端末装置４は、通信ネットワーク１０を介して相互に通信可能に接続されている。
支援サーバ２は、また、荷物の配送先となり得る種々の施設８の施設サーバ６と、通信ネットワーク１０を介して通信可能に接続されている。施設サーバ６は、コンピュータを備え、対応する施設８の荷物預かりスペースの空き状況を管理し、荷物の受け入れ可否についての情報である受入可否情報を提供する。

施設８は、例えば、配送依頼者Ｒである旅行者が観光の後に宿泊しようとするホテル等の宿泊施設であって、施設サーバ６は、その宿泊施設が運営するサーバであり得る。また、あるいは、施設８は、配送依頼者Ｒである旅行者が宿泊施設に到着するまでに立ち寄る店舗、例えば、レストランやコンビニエンスストア等の施設であり、施設サーバ６は、それらの施設がそれぞれ運営するサーバであり得る。

なお、配送依頼者Ｒは、旅行者に限らず、特定の場所へ移動しようとする任意の人物であるものとすることができ、施設サーバ６は、そのような人物が移動しようとする場所又はその移動経路の途中にある立ち寄り場所の、任意の施設８のサーバであり得る。

委託支援システム１は、概ね次のように動作して、配送依頼者Ｒから配送請負者Ｃへの荷物の配送委託の成立を支援する。まず、配送依頼者Ｒは、自身の端末装置３を用いて、荷物の受け渡し場所及び配送先の情報を含む配送依頼を、支援サーバ２へ送信する。荷物の受け渡し場所は、例えば、端末装置３の現在位置でもよいし、配送依頼者Ｒが端末装置３に入力する特定の場所でもよい。

配送依頼者Ｒの端末装置３から配送依頼を受信した支援サーバ２は、その配送依頼が示す荷物の配送先である施設８の施設サーバ６から、当該施設８における荷物引き受けの可否状態についての受入可否情報を取得する。そして、支援サーバ２は、受入可否情報の内容に基づき、上記配送依頼に対する配送請負者Ｃのマッチングを行うか否かを判断する。例えば、支援サーバ２は、受入可否情報が、配送先である施設８における荷物引き受けが可能であることを示す場合に、上記マッチングを行うと判断する（すなわち、マッチングを行うことを決定する）。これにより、配送依頼にマッチングされる配送請負者Ｃは、自身で荷物を保管することなく、配送作業をスムーズに遂行することができる。

この場合において、支援サーバ２は、受入可否情報のほか、配送先である施設８の種別にも基づいて、上記マッチングを行うか否かを判断してもよい。例えば、支援サーバ２は、配送先である施設８の種別が宿泊施設である場合には、受入可否情報に関わらず、マッチングを実行すると判断する。また、例えば、支援サーバ２は、配送先である施設８の種別が、コンビニエンスストア又はレストランである場合には、受入可否情報が、荷物の受け入れが可能であることを示す場合に、マッチングを実行すると判断する。

これにより、例えば、荷物の引き受け可否の状態が時間と共に変化し得るレストラン又はコンビニエンスストアについては、荷物受け入れが可であるときにマッチングが行われるので、配送作業の円滑な実行を実現し得る。また、例えば、荷物受け入れが可能である可能性が常に高い宿泊施設については、受入可否情報に関わらずマッチングステップの実行を判断することができるので、処理負荷を軽減することができる。

支援サーバ２は、マッチングを実行すると判断したときは、上記受信した配送依頼と、それぞれの配送請負者Ｃの現在の状況を示す請負ステータス情報と、に基づき、上記配送依頼に一の配送請負者Ｃをマッチングするマッチング処理を実行する。

ここで、それぞれの配送請負者Ｃの請負ステータス情報は、支援サーバ２が配送請負者Ｃの端末装置４から定期的に取得するものとすることができる。請負ステータス情報には、その配送請負者Ｃが現在請け負っている配送依頼についての配送工程の進捗状況を示す進捗情報が含まれる。この進捗情報には、その配送請負者Ｃの現在位置の情報および現在における予定移動経路の情報が含まれ得る。

支援サーバ２は、まず、上記配送依頼と請負ステータス情報とに基づき、上記配送依頼にマッチングする配送請負者Ｃの候補である請負者候補を決定する。例えば、支援サーバ２は、請負ステータス情報に含まれる現在位置が、配送依頼に含まれる荷物の受け渡し場所から所定距離の範囲内である配送請負者Ｃを、請負候補者として決定するものとすることができる。請負候補者のリストには、その請負候補者を識別する請負者ＩＤ、プロフィール、自己ＰＲ、及び又はユーザ評価等の情報が含まれ得る。

続いて、支援サーバ２は、決定した請負者候補のリストを端末装置３へ送信し、端末装置３は、受信した請負候補者のリストを表示する。その後、配送依頼者Ｒが、端末装置３において、表示された請負候補者のリストから一の配送請負者Ｃを選択すると、選択された配送請負者Ｃの情報が端末装置３から支援サーバ２へ送信される。そして、支援サーバ２からその配送請負者Ｃの端末装置４へ、その配送依頼者Ｒの配送依頼が送信される。

配送請負者Ｃは、その配送依頼を請け負う場合には、端末装置４を介して受任通知を支援サーバ２へ送信し、支援サーバ２は、受任した配送請負者Ｃの情報を、配送依頼者Ｒの端末装置３へ送信する。これにより、配送依頼者Ｒの配送依頼と、一の配送請負者Ｃとのマッチングが成立し、マッチング処理が終了する。配送請負者Ｃは、配送依頼に示された荷物受け渡し場所において荷物を受け取り、その荷物を配送依頼に示された配送先へ配送する。

支援サーバ２は、また、上述した受入可否情報が取得できないときは、配送先である施設８の施設サーバ６及び又は配送依頼者Ｒの端末装置３に所定の報知（例えば、受入可否情報が取得できない旨の報知や受入可否情報を入力するよう促す報知）を出力させる。これにより、施設８の人員は、荷物の受け入れ希望があることを認識して、例えば、荷物受け入れスペースの暫定的な拡張等の処置を行うことができる。あるいは、上記報知により、配送依頼者Ｒは、配送先として指定する施設８の変更を検討することができる。その結果、配送請負者Ｃによる円滑な配送作業が実現され得る。

この場合において、上記報知は、マッチングの実行により配送依頼に対して一の配送請負者Ｃが決定されたとき又はそのあとに、行われるものとすることができる。これにより、受入可否情報が取得できない場合でも、その配送依頼の配送工程は先に進められるので、配送依頼者Ｒにとっては、配送実行までの待ち時間が発生してしまうこと避けることができ、配送請負者Ｃにとっては、配送先での荷物受け入れが可能か否かがわからず不安となってしまうのを解消することができる。

また、支援サーバ２は、配送先である施設８の種別にも基づいて、上記報知を行うか否かを決定してもよい。例えば、支援サーバ２は、配送先である施設８の種別がレストラン又はコンビニエンスストアである場合には上記報知を行うものとする一方、その施設８の種別が宿泊施設である場合には上記報知を行わないものとすることができる。これにより、荷物引き受けの可否状態が変化しやすく荷物引き受けスペースを事前に確保しやすいレストラン又はコンビニエンスストアには上記報知が行われるので、例えば、これらの施設における上記スペースの確保を促進して、配送作業の円滑化を図ることができる。また、一方、荷物引き受けの可否状態が変化しにくい宿泊施設には、上記報知は行われないので、宿泊施設が不要な報知に煩わされてしまうのを避けることができる。

また、支援サーバ２は、配送依頼にマッチングされた配送請負者Ｃにおける、当該配送依頼についての配送工程の進捗情報を取得して、当該取得した進捗情報に基づき、上記報知の内容を決定してもよい。上記進捗情報は、例えば、その配送請負者Ｃについての、上述した請負ステータス情報から取得され得る。

これにより、例えば、上記報知を受け取った配送先である施設８及び又は配送依頼者Ｒは、報知の内容の変化から、荷物受け入れが必要となるタイミングを認識して、荷物受け入れスペースの確保のタイミングや、配送先変更等のタイミングを計ることができる。

この場合において、支援サーバ２は、上記取得した進捗情報に基づき、配送工程が進むにつれて上記報知がより強調されるように、その報知の態様を変更するものとすることができる。これにより、例えば、上記報知を受け取った配送先である施設８及び又は配送依頼者Ｒは、配送先において荷物受け入れが必要となるまでの時間を、より明確に認識することができ、例えば配送依頼者Ｒが配送先である施設８に直接電話を掛けて受入れ可とするよう連絡を取るといったことを促すことができる。

［２．支援サーバの構成］
図２は、支援サーバ２の構成の一例を示す図である。支援サーバ２は、プロセッサ２０と、メモリ２１と、通信装置２２と、を有する。通信装置２２は、支援サーバ２が通信ネットワーク１０を介して端末装置３等の他の装置と通信するための送受信機である。メモリ２１は、例えば、揮発性及び又は不揮発性の半導体メモリ、及び又はハードディスク装置等により構成される。メモリ２１には、委託支援システム１に参加する配送請負者Ｃのそれぞれの登録情報が保存された請負者ＤＢ２９が記憶されている。登録情報は、配送請負者Ｃを識別する請負者ＩＤ、その配送請負者Ｃの氏名、プロフィール、自己ＰＲ、ユーザ評価等の情報、および端末装置４にアクセスするためのアクセス情報が含まれ得る。請負者ＤＢ２９には、また、後述する受信部２３により、配送請負者Ｃのそれぞれの現在の状況を示す請負ステータス情報も保存される。

プロセッサ２０は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等のプロセッサを備えるコンピュータである。プロセッサ２０は、プログラムが書き込まれたＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、データの一時記憶のためのＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等を有する構成であってもよい。そして、プロセッサ２０は、機能要素又は機能ユニットとして、受信部２３と、配送先情報取得部２４と、判断部２５と、マッチング部２６と、進捗情報取得部２７と、報知部２８と、を備える。

プロセッサ２０が備えるこれらの機能要素は、例えば、コンピュータであるプロセッサ２０がメモリ２１に記憶された支援プログラム３０を実行することにより実現される。なお、支援プログラム３０は、コンピュータ読み取り可能な任意の記憶媒体に記憶させておくことができる。これに代えて、プロセッサ２０が備える上記機能要素の全部又は一部を、それぞれ一つ以上の電子回路部品を含むハードウェアにより構成することもできる。

受信部２３は、請負者ＤＢ２９に記憶されている配送請負者Ｃのそれぞれの登録情報に基づき、それぞれの配送請負者Ｃの端末装置４に定期的に（例えば、所定の時間間隔で）アクセスし、配送請負者Ｃの現在の状況を示す請負ステータス情報を取得して請負者ＤＢ２９に記憶する。請負ステータス情報は、例えば、従来技術に従い、端末装置４において実行されるアプリにより、受信部２３からの要求に応じて端末装置４から送信される。上述したように、請負ステータス情報は、その配送請負者Ｃが現在請け負っている配送依頼についての配送工程の進捗状況を示す進捗情報が含まれる。また、この進捗情報には、その配送請負者Ｃの現在位置の情報および現在における予定移動経路の情報が含まれ得る。

受信部２３は、また、配送依頼者Ｒからの荷物の配送依頼を端末装置３から受信する。配送依頼は、例えば、従来技術に従い、端末装置３において実行されるアプリにより、配送依頼者Ｒの操作に応じて送信される。配送依頼には、配送依頼者Ｒの識別名、現在位置、端末装置３と通信するためのアクセス情報、荷物の写真、荷物の受け渡し場所および配送先の情報が含まれ得る。配送依頼者Ｒの識別名は、配送請負者Ｃが荷物受け渡しの際にその配送依頼者Ｒを確認できる氏名（本名または偽名）あるいはニックネームであり得る。

配送依頼者Ｒの現在位置は、端末装置３の現在位置または、配送依頼者Ｒが端末装置３に入力する特定の場所でもよい。アクセス情報は、電子メールのメールアドレス、電話番号等であり得る。荷物の写真は、例えば、端末装置３が備えるカメラにより配送依頼者Ｒが撮影するものとすることができる。また荷物の写真に代えて、配送依頼者Ｒが端末装置３に入力する荷物のサイズ（例えば、縦、横、及び奥行の寸法）の情報を用いても良い。

配送先情報取得部２４は、受信部２３が受信した配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する。配送先情報取得部２４は、上記配送先が所定の種別であるときに、受入可否情報を取得する。例えば、配送先情報取得部２４は、配送先の種別が宿泊施設であるときは、受入可否情報を取得しない。配送先情報取得部２４は、上記配送依頼が指定する配送先である施設８の施設サーバ６にアクセスして、当該施設サーバ６からその施設８の受入可否情報を取得するものとすることができる。なお、施設サーバ６が受入可否情報を提供していないときは、配送先情報取得部２４は、受入可否情報を取得することができない。この場合には、配送先情報取得部２４は、例えば、受入可否情報が取得できなかったことを記憶する。

判断部２５は、受信部２３が受信した配送依頼に対し、マッチング部２６におけるマッチング処理を実行するか否か、すなわち、配送請負者Ｃのマッチングを実行するか否かを判断する。具体的には、判断部２５は、配送先である施設８の受入可否情報に基づいて、マッチング部２６におけるマッチング処理を実行するか否かを判断する。

例えば、判断部２５は、配送先情報取得部２４が取得した受入可否情報が、配送先の施設８における荷物引き受けが可能であることを示す場合に、上記マッチング処理を実行すると判断する。また、例えば、判断部２５は、配送先情報取得部２４が、上記配送先の種別に基づき受入可否情報を取得しないと判断したとき、若しくは、配送先の受入可否情報を取得できなかったとき、または、取得した受入可否情報が、配送先の施設８における荷物引き受けが不可であることを示す場合には、上記マッチング処理を実行しないと判断する。

この場合において、判断部２５は、配送先の施設８の種別にも基づいて、マッチング処理を実行するか否かを判断してもよい。例えば、判断部２５は、配送先である施設８の種別が宿泊施設である場合には、受入可否情報に関わらず、マッチング処理を実行すると判断する。また、例えば、判断部２５は、配送先である施設８の種別が、コンビニエンスストア又はレストランである場合には、受入可否情報が、荷物の受け入れが可能であることを示す場合に、マッチング処理を実行すると判断する。施設８の種別は、例えば、判断部２５が、その施設８の名称等から判断するものとすることができる。

マッチング部２６は、判断部２５における判断結果に応じて、判断部２５がマッチング処理を実行すると判断したときは、受信部２３が受信した配送依頼についてのマッチング処理を実行する。マッチング処理では、上記受信した配送依頼に対し、配送請負者Ｃの候補の中から一の配送請負者Ｃを決定する。具体的には、マッチング部２６は、受信した配送依頼と、請負者ＤＢ２９に保存されている請負ステータス情報とに基づき、上記配送依頼にマッチングする配送請負者Ｃの候補である請負者候補を決定する。

例えば、マッチング部２６は、上述したように、請負ステータス情報に含まれる現在位置が上記配送依頼に含まれる荷物の受け渡し場所から所定距離の範囲内である配送請負者Ｃを請負候補者として決定し、請負候補者のリストを生成する。請負候補者のリストには、請負者ＤＢ２９に保存されているその請負候補者の請負者ＩＤ、氏名、プロフィール、自己ＰＲ、ユーザ評価等のほか、現在の位置および移動経路の情報が含まれ得る。

マッチング部２６は、決定した請負者候補のリストを端末装置３へ送信し、端末装置３は、受信した請負候補者のリストを表示する。

図３は、端末装置３における請負候補者リストの表示画面の一例である。図示の例では、端末装置３が備える表示装置４０に、マップ４１と、請負候補者リスト４２と、が表示されている。ここで、表示装置４０は、例えば、タッチパネルである。マップ４１には、配送依頼者Ｒの現在位置を示す依頼者マーク４６が、黒い星印で示されている。また、マップ４１には、請負候補者である配送請負者Ｃのそれぞれの、現在位置及び移動先を示す請負者マーク４７および移動先マーク４８と、移動予定経路（図示点線）と、が示されている。また、図示の例では、請負者マーク４７に、対応する配送請負者Ｃの請負者ＩＤが付されている。

マップ４１の図示下方に表示された請負候補者リスト４２には、左側の列に請負候補者の請負者ＩＤが表示されている。また、中央列には、その請負候補者の詳細情報を表示するための詳細ボタン４３が表示され、右側列には、その請負候補者を委託先として選択するための選択ボタン４４が表示されている。配送依頼者Ｒがいずれかの詳細ボタン４３にタッチすると、対応する配送請負者Ｃの詳細情報が、請負候補者リスト４２の図示下方の詳細表示エリア４５に表示される。この詳細情報には、例えば、その請負候補者の氏名、プロフィール、自己ＰＲ等が含まれ得る。

配送依頼者Ｒは、いずれかの選択ボタン４４にタッチすることにより、対応する請負候補者を委託先として選択することができる。端末装置３は、請負候補者の選択結果（例えば、選択された請負候補者の請負者ＩＤ）を、支援サーバ２へ送信する。

図２を参照し、マッチング部２６は、配送依頼者Ｒによる上記選択結果を端末装置３から受信して、上記選択された配送請負者Ｃの端末装置４へ、その配送依頼者Ｒの配送依頼を送信する。配送請負者Ｃは、その配送依頼を請け負う場合には、端末装置４を介して受任通知を支援サーバ２へ送信する。マッチング部２６は、受任した配送請負者Ｃの情報を、配送依頼者Ｒの端末装置３へ送信する。

進捗情報取得部２７は、配送依頼にマッチングされた配送請負者Ｃにおける、その配送依頼についての配送工程の進捗情報を取得する。進捗情報取得部２７は、例えば、受信部２３がその配送請負者Ｃの端末装置４から受信して請負者ＤＢ２９に保存した、その配送請負者Ｃについての現在の状況を示す請負ステータス情報から、上記進捗情報を取得するものとすることができる。進捗情報は、例えば、「荷物受取場所へ移動中」、「荷物保管中」、または「配送先へ移動中」等の、配送工程の進捗ステータスを示すものであり得る。ステータス「配送先への移動中」には、配送先の施設８に到着するまでの残り時間又は予想到着時刻が含まれるものとしてもよい。

報知部２８は、受入可否情報を取得できない場合に、配送先の施設８が備える装置である施設サーバ６、及び又は配送依頼者Ｒの端末装置３に、所定の報知を出力させる。具体的には、報知部２８は、上記報知の出力を指示する報知指示を、施設サーバ６及び又は端末装置３へ送信する。報知指示を受信した施設サーバ６及び又は端末装置３は、それぞれ、その施設８の人員及び又は配送依頼者Ｒに対し、上記所定の報知を出力する。

例えば、報知部２８は、マッチング部２６が実行するマッチング処理において配送依頼に対し一の配送請負者Ｃが決定されたとき又はその決定のあとに、その配送依頼に係る施設８の施設サーバ６及び又は配送依頼者Ｒの端末装置３に、上記報知を出力させる。

報知部２８は、配送依頼が示す配送先の施設８の種別にも基づいて、上記報知の出力を行うか否か、すなわち、上記報知指示を送信するか否かを決定してもよい。報知部２８は、例えば、配送先の施設８の種別が宿泊施設である場合には上記報知を行わず、配送先の施設８の種別がレストラン又はコンビニエンスストアである場合に上記報知を行うものとすることができる。配送先の施設８の種別は、報知部２８が、その施設８の名称等に基づいて判断するものとすることができる。

また、報知部２８は、進捗情報取得部２７が取得した上記進捗情報に基づいて、上記報知の内容を決定するものとすることができる。例えば、報知部２８は、進捗情報が示すステータスに応じて、上記報知が含むメッセージを、「荷物受取場所へ移動中」、「荷物保管中」、または「配送先へ移動中」等とすることができる。あるいは、報知部２８は、例えば、上記報知に地図を含ませるものとし、進捗情報が示す進捗状況に応じて、地図上に表示する配送請負者Ｃの現在位置を更新するものとすることができる。

また、報知部２８は、上記進捗情報に基づき、配送依頼についての配送請負者Ｃにおける配送工程が進むにつれて、上記報知がより強調されるように、上記報知の態様を変更してもよい。例えば、報知部２８は、上記報知の態様として、上記報知の送信先の数、報知の音量、及び又は報知の頻度を変化（例えば、増加）させることにより、上記報知を強調するものとすることができる。

図４は、報知部２８が送信する報知指示に基づいて配送依頼者Ｒの端末装置３の表示装置４０に表示される報知画面の一例を示す図である。この報知画面が示す報知には、マップ５０と、ステータスメッセージ５１が含まれている。マップ５０には、配送請負者Ｃの現在位置を示す請負者マーク５２と、配送先の位置を示す配送先マーク５３と、配送請負者Ｃの移動予定経路（図示点線）と、が示されている。

図４の報知画面により示される報知では、配送請負者Ｃの配送工程の進捗情報に応じて、マップ５０上の請負者マーク５２の位置が更新されると共に、ステータスメッセージ５１の内容が更新される。例えば、ステータスメッセージ５１は、上記進捗状況に応じて、配送先に到着するまでの残り時間である「（残りＸＸ分）」の「ＸＸ」の値が変更される。あるいは、ステータスメッセージ５１は、進捗状況に応じて、「配送先へ移動中」の部分が、「荷物保管中」（例えば、配送先で荷物を預けられなかった場合）等に変更される。あるいは、上記に代えて又は追加して、報知部２８が送信する報知指示に基づいて配送依頼者Ｒの端末装置３の表示装置４０に、受入可否情報が取得できない旨のメッセージを表示させてもよい。

図４に示す報知画面には、上記に加えて、報知の一部として、配送依頼を識別するための配送依頼ＩＤ５４と、配送先において荷物受け入れが可能か否かが不明であることを示す情報メッセージ５５と、が含まれている。情報メッセージ５５には、例えば、「（＊＊レストラン）」等の配送先の施設名が表示される。配送依頼ＩＤは、例えば、受信部２３が配送依頼を受信したときに、受信部２３により当該配送依頼に割り当てられるものとすることができる。

図４に示す報知画面は、また、報知部２８からの報知指示に従い、配送工程が進むにつれて、例えば、当該画面のバックグランドカラーが寒色計から暖色系に変化したり、輝度が一定状態から点滅状態へ変化したり、更には、当該点滅の頻度が増加して、上記報知が強調される。

配送先の装置である施設サーバ６における報知の表示も、図４と同様の報知画面とすることができる。あるいは、施設サーバ６における報知では、配送依頼毎の、配送依頼ＩＤ５４とステータスメッセージ５１とが、リスト形式で表示されるものとすることができる。また、施設サーバ６における報知では、受入可否情報の入力を促すメッセージを表示しってもよい。また、進捗状況に応じた報知の強調は、例えば、配送依頼毎に、対応するリストの行のフォアグランドカラーやバックグラウンドカラーの色や輝度を変化させることで行われるものとすることができる。

［３．委託支援システムの動作手順］
次に、委託支援システム１における動作の手順について説明する。
図５は、委託支援システム１が実行する委託支援方法における処理の手順を示すフロー図である。本処理は、繰り返し実行される。なお、本処理と並行して、支援サーバ２の受信部２３は、所定の時間間隔で、配送請負者Ｃのそれぞれの端末装置４から、その配送請負者Ｃの請負ステータス情報を取得して請負者ＤＢ２９に保存するものとする。

図５において、まず、支援サーバ２の受信部２３は、配送依頼者Ｒからの配送依頼を受信したかを判断する（Ｓ１００）。そして、配送依頼を受信しないときは（Ｓ１００、ＮＯ）、受信部２３は、ステップＳ１００に戻って処理を繰り返し、配送依頼が受信されるのを待機する。

一方、配送依頼を受信したときは（Ｓ１００、ＹＥＳ）、配送先情報取得部２４は、上記受信した配送依頼が示す配送先の種別に基づいて、受入可否情報を取得するか否かを判断する（Ｓ１０２）。例えば、配送先情報取得部２４は、配送先が所定の種別であるときに、受入可否情報を取得すべきと判断する。また、例えば、配送先情報取得部２４は、配送先の種別が宿泊施設であるときは、受入可否情報を取得する必要はないと判断する。

そして、配送先情報取得部２４は、受入可否情報を取得すべきと判断するときは（Ｓ１０２、ＹＥＳ）、受入可否情報を取得する（Ｓ１０４）。受入可否情報は、例えば、配送先の施設８の施設サーバ６から取得され得る。ここで、施設サーバ６が受入可否情報を提供していないときは、ステップＳ１０４において、配送先情報取得部２４は、受入可否情報を取得することができない。この場合には、配送先情報取得部２４は、受入可否情報が取得できなかったことを記憶する。

一方、配送先情報取得部２４は、受入可否情報を取得する必要はないと判断するときは（Ｓ１０２、ＮＯ）、ステップＳ１０６に処理を移す。

次に、判断部２５は、上記受信した配送依頼に対し配送請負者Ｃをマッチングするマッチング処理を行うか否か（すなわち、マッチング部２６にマッチング処理を実行させるか否か）を判断する（Ｓ１０６）。上述したように、判断部２５は、ステップＳ１０４において配送先情報取得部２４が取得した受入可否情報が、配送先における荷物引き受けが可であることを示す場合に、マッチング処理を実行すると判断する。また、判断部２５は、配送先情報取得部２４が、ステップＳ１０２における判断に基づいて受入可否情報を取得しないとき、若しくは、ステップＳ１０４において受入可否情報を取得できなかったとき、または、ステップＳ１０４において取得した受入可否情報が、配送先における荷物引き受けが不可であることを示す場合に、マッチング処理を実行しないと判断する。

上記に加え、本実施形態では、判断部２５は、ステップＳ１０６において、配送先の種別にも基づいて、マッチング処理を実行するか否かを判断する。上述したように、判断部２５は、例えば、配送先の種別が宿泊施設である場合には、受入可否情報に関わらずマッチング処理を実行すると判断し、配送先の種別がコンビニエンスストア又はレストランである場合には、受入可否情報が荷物受け入れ可能であることを示す場合に、マッチング処理を実行すると判断する。

そして、判断部２５は、マッチング処理を行わないと判断したときは（Ｓ１０６、ＮＯ）、本処理を終了する。一方、判断部２５が、マッチング処理を行うと判断したときは（Ｓ１０６、ＹＥＳ）、マッチング部２６は、上記配送依頼に対して一の配送請負者Ｃを決定するマッチング処理を行う（Ｓ１０８）。

続いて、報知部２８は、配送先情報取得部２４がステップＳ１０４において配送先についての受入可否情報を取得できたか否かを判断する（Ｓ１１０）。そして、受入可否情報を取得できたときは（Ｓ１１０、ＹＥＳ）、報知部２８は、本処理を終了する。

一方、ステップＳ１０４において受入可否情報を取得できなかったときは（Ｓ１１０、ＮＯ）、報知部２８は、配送先が備える装置（例えば、施設サーバ６）及び又は配送依頼者Ｒの端末装置３に所定の報知を出力させるか否かを判断する（Ｓ１１２）。上述したように、報知部２８は、配送先の種別にも基づいて、上記報知を行うか否かを決定するものとすることができる。

そして、報知部２８は、報知を行わないと判断したときは（Ｓ１１２、ＮＯ）、本処理を終了する。一方、報知部２８が、報知を行うと判断したときは（Ｓ１１２、ＹＥＳ）、進捗情報取得部２７は、配送請負者Ｃにおける、上記配送依頼についての配送工程の進捗状況を示す進捗情報を取得する（Ｓ１１４）。報知部２８は、上記取得された進捗情報に応じた報知を、配送先が備える施設サーバ６及び又は配送依頼者Ｒの端末装置３に出力させる（Ｓ１１６）。

次に、報知部２８は、上記進捗情報に基づき、配送依頼についての荷物の配送が完了したか否かを判断する（Ｓ１１８）。そして、配送が完了したときは（Ｓ１１８、ＹＥＳ）、報知部２８は、本処理を終了する。一方、配送が完了してないときは（Ｓ１１８、ＮＯ）、報知部２８は、ステップＳ１１４に処理を戻す。

ここで、図５に示すステップＳ１００、Ｓ１０６、およびＳ１０８は、それぞれ、本開示における受信ステップ、判断ステップ、およびマッチングステップに相当する。また、図５に示すステップＳ１０２およびＳ１０４は、本開示における配送先情報取得ステップに相当する。また、図５に示すステップＳ１１４およびＳ１１６は、それぞれ、本開示における進捗情報取得ステップおよび報知ステップに相当する。

［４．他の実施形態］
支援サーバ２のマッチング部２６は、本実施形態では、配送依頼に対し、配送依頼者Ｒが配送請負者Ｃの候補者のうちから選択した一の配送請負者Ｃをマッチングするものとしたが、配送依頼者Ｒの選択を求めることなく、自動的に一の配送請負者Ｃをマッチングしてもよい。例えば、マッチング部２６は、配送請負者Ｃの候補者のうち、配送依頼の受信時において配送依頼者Ｒに最も近い配送請負者Ｃを、その配送依頼に自動的にマッチングするものとすることができる。

支援サーバ２の配送先情報取得部２４は、配送先である施設８の施設サーバ６から受入可否情報を取得できない場合には、所定の時間間隔で施設サーバ６にアクセスして、受入可否情報の取得を試行してもよい。これらの試行により配送先情報取得部２４が受入可否情報を取得できたときは、報知部２８は、配送先に備える装置である施設サーバ６及び又は配送依頼者Ｒの端末装置３への報知を終了するものとすることができる。

支援サーバ２のプロセッサ２０が備えるものとして上述した機能要素は、必ずしもそのすべてが支援サーバ２のような一つの装置において実現され又は保存されている必要はなく、通信ネットワーク１０により互いに通信可能に接続された複数のサーバ装置において分散して実現されていてもよい。

すなわち、委託支援システム１は、上述した支援サーバ２の構成要素を統合的に又は分散して備える一つ又は複数の装置の、一つ又は複数のコンピュータにより実現されるものとすることができる。

［５．上記実施形態によりサポートされる構成］
上述した実施形態は、以下の構成をサポートする。

（構成１）荷物の配送委託を支援する委託支援システムのコンピュータが実行する委託支援方法であって、配送依頼者からの荷物の配送依頼を端末装置から受信する受信ステップと、前記受信した配送依頼に対する配送請負者のマッチングを行うマッチングステップと、前記受信した前記配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する配送先情報取得ステップと、前記受入可否情報を取得できない場合に、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる報知ステップと、を含む、委託支援方法。
構成１の委託支援方法によれば、配送先における荷物引き受けの可否が不明な場合には、配送先および配送依頼者に報知が行われるので、配送先および配送依頼者は、円滑な荷物配送に向けて、荷物受け入れのスペース確保や、配送先の変更等の対処を行うことができる。すなわち、構成１の委託支援方法によれば、配送作業の円滑な実行に配慮しつつ、配送依頼者と配送請負者とのマッチングの成立を支援することができる。

（構成２）前記マッチングステップでは、配送請負者の候補の中から一の配送請負者を決定し、前記報知ステップでは、前記マッチングステップにおいて前記一の配送請負者が決定されたとき、又は前記決定のあとに、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる、構成１に記載の委託支援方法。
構成２の委託支援方法によれば、配送先及び又は配送依頼者は、マッチング不成立の場合には報知を受信しないので、不要な報知により煩わされることがなく、委託支援システム１の利便性が向上する。

（構成３）前記配送請負者における、前記配送依頼についての配送工程の進捗状況を示す進捗情報を取得する進捗情報取得ステップを含み、前記報知ステップでは、前記進捗情報に基づいて、前記報知の内容を決定する、構成２に記載の委託支援方法。
構成３の委託支援方法によれば、報知を受け取った配送先及び又は配送依頼者は、例えば、荷物受け入れが必要となるタイミングを認識でき、荷物受け入れスペースの確保のタイミングや、配送先変更等のタイミングを計ることができる。

（構成４）前記報知ステップでは、前記進捗情報に基づき、前記配送工程が進むにつれて前記報知がより強調されるように、前記報知の態様を変更する、構成３に記載の委託支援方法。
構成４の委託支援方法によれば、報知を受け取る配送先及び又は配送依頼者は、配送先において荷物受け入れが必要となるまでの時間を、より明確に認識することができる。

（構成５）前記配送先情報取得ステップでは、前記配送先が所定の種別であるときに、前記受入可否情報を取得する、構成１ないし４のいずれかに記載の委託支援方法。
構成５の委託支援方法によれば、配送先の種別に依存して、配送先における荷物の受け入れ可否状況を確認する必要のない配送先については、受入可否情報を取得しないので、処理負荷を軽減することができる。

（構成６）前記配送先情報取得ステップでは、前記配送先の種別が宿泊施設であるときは、前記受入可否情報を取得しない、構成１ないし５のいずれか一項に記載の委託支援方法。
構成６の委託支援方法によれば、荷物受け入れが可能である可能性が常に高い宿泊施設については、受入可否情報を取得しないので、処理負荷を軽減することができる。

（構成７）前記報知ステップでは、前記配送先の種別にも基づいて、前記報知を行うか否かを決定する、構成１ないし６のいずれかに記載の委託支援方法。
構成７の委託支援方法によれば、マッチングステップの実行可否を配送先の種別により判断することにより、その配送先における預かり荷物の流動性を考慮して報知の要否を判断するので、不要な報知の発生を防止して、配送依頼者および配送請負者にとっての利便性を向上することができる。

（構成８）前記報知ステップでは、前記配送先の種別が宿泊施設である場合には前記報知を行わず、前記配送先の種別がレストラン又はコンビニエンスストアである場合に、前記報知を行う、構成７に記載の委託支援方法。
構成８の委託支援方法によれば、荷物引き受けの可否状態が変化しやすく荷物引き受けスペースの予約確保を行いやすいレストラン又はコンビニエンスストアには報知が行われるので、例えば、これらの施設における荷受けスペースの確保を促進して、配送作業の円滑化を図ることができる。一方、荷物引き受けの可否状態が変化しにくい宿泊施設には報知は行われないので、例えば、荷受けスペースの拡張等が困難な宿泊施設が不要な報知に煩わされてしまうのを避けることができる。

（構成９）荷物の配送委託を支援する委託支援システムであって、配送依頼者からの荷物の配送依頼を端末装置から受信する受信部と、前記受信した配送依頼に対する配送請負者のマッチングを行うマッチング部と、前記受信した前記配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する配送先情報取得部と、前記受入可否情報を取得できない場合に、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる報知部と、を備える、委託支援システム。
構成９の委託支援システムによれば、配送先における荷物引き受けの可否が不明な場合には、配送先および配送依頼者に報知が行われるので、配送先および配送依頼者は、円滑な荷物配送に向けて、荷物受け入れのスペース確保や、配送先の変更等の対処を行うことができる。すなわち、構成１の委託支援方法によれば、配送作業の円滑な実行に配慮しつつ、配送依頼者と配送請負者とのマッチングの成立を支援することができる。

１…委託支援システム、２…支援サーバ、３、４…端末装置、５…移動体、６…施設サーバ、８…施設、１０…通信ネットワーク、２０…プロセッサ、２１…メモリ、２２…通信装置、２３…受信部、２４…配送先情報取得部、２５…判断部、２６…マッチング部、２７…進捗情報取得部、２８…報知部、２９…請負者ＤＢ、３０…支援プログラム、４０…表示装置、４１、５０…マップ、４２…請負候補者リスト、４３…詳細ボタン、４４…選択ボタン、４５…詳細表示エリア、４６…依頼者マーク、４７、５２…請負者マーク、４８…移動先マーク、５１…ステータスメッセージ、５３…配送先マーク、５４…配送依頼ＩＤ、５５…情報メッセージ、Ｃ…配送請負者、Ｒ…配送依頼者。

Claims (9)

1. 荷物の配送委託を支援する委託支援システムのコンピュータが実行する委託支援方法であって、
   配送依頼者からの荷物の配送依頼を端末装置から受信する受信ステップと、
   前記受信した配送依頼に対する配送請負者のマッチングを行うマッチングステップと、
   前記受信した前記配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する配送先情報取得ステップと、
   前記受入可否情報を取得できない場合に、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる報知ステップと、
   を含む、
   委託支援方法。
2. 前記マッチングステップでは、配送請負者の候補の中から一の配送請負者を決定し、
   前記報知ステップでは、前記マッチングステップにおいて前記一の配送請負者が決定されたとき、又は前記決定のあとに、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる、
   請求項１に記載の委託支援方法。
3. 前記配送請負者における、前記配送依頼についての配送工程の進捗状況を示す進捗情報を取得する進捗情報取得ステップを含み、
   前記報知ステップでは、前記進捗情報に基づいて、前記報知の内容を決定する、
   請求項２に記載の委託支援方法。
4. 前記報知ステップでは、前記進捗情報に基づき、前記配送工程が進むにつれて前記報知がより強調されるように、前記報知の態様を変更する、
   請求項３に記載の委託支援方法。
5. 前記配送先情報取得ステップでは、前記配送先が所定の種別であるときに、前記受入可否情報を取得する、
   請求項１ないし４のいずれか一項に記載の委託支援方法。
6. 前記配送先情報取得ステップでは、前記配送先の種別が宿泊施設であるときは、前記受入可否情報を取得しない、
   請求項１ないし４のいずれか一項に記載の委託支援方法。
7. 前記報知ステップでは、前記配送先の種別にも基づいて、前記報知を行うか否かを決定する、
   請求項１ないし４のいずれか一項に記載の委託支援方法。
8. 前記報知ステップでは、
   前記配送先の種別が宿泊施設である場合には前記報知を行わず、
   前記配送先の種別がレストラン又はコンビニエンスストアである場合に、前記報知を行う、
   請求項７に記載の委託支援方法。
9. 荷物の配送委託を支援する委託支援システムであって、
   配送依頼者からの荷物の配送依頼を端末装置から受信する受信部と、
   前記受信した配送依頼に対する配送請負者のマッチングを行うマッチング部と、
   前記受信した前記配送依頼が指定する配送先における荷物引き受けの可否についての情報である受入可否情報を取得する配送先情報取得部と、
   前記受入可否情報を取得できない場合に、前記配送先が備える装置及び又は前記配送依頼者の端末装置に所定の報知を出力させる報知部と、
   を備える、
   委託支援システム。
   

Images