【文献】
“ウーバー流”で移動を変革,日経コンピュータ,日本,日経BP社,2016年 6月23日,no.915,p.024-027
【文献】
「ハコベル」”物流版Uber”で格安ラストワンマイル,LOGI−BIZ,株式会社ライノス・パブリケーションズ Rhinos Publications,Inc.,2016年 6月 1日,第16巻,第3号,p.22-23
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0017】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。
【0018】
本発明の一実施の形態である物流支援システムは、例えば、ネット通販等において、発送者(販売者)が発送した荷物を、受取者(購入者)の元に配送するというような場合に、配送対象区間の途中の一部区間なら配送が可能であるというような複数のキャリアを組み合わせて、配送対象区間全体の配送が可能となるようにマッチングする。そして、これらのキャリアが例えば配達ロッカーを介してリレー形式で順次荷物を受け渡して配送することで、配送対象区間全体での荷物の配送を実現させる情報処理システムである。
【0019】
<システム構成>
図1は、本発明の一実施の形態である物流支援システムの構成例について概要を示した図である。物流支援システム1は、例えば、物流支援サーバ10に対して、インターネット等のネットワーク60を介して、発送者2、受取者3、および配送協力者4がそれぞれ保有する、発送者端末20、受取者端末30、および配送協力者端末40の各情報処理端末が接続される構成を有する。また、各地に設置された配達ロッカー50も接続される。なお、発送者端末20や受取者端末30、配送協力者端末40は、例えば、スマートフォンやタブレット端末、PC(Personal Computer)等の汎用の情報処理端末により構成され、図示しないWebブラウザもしくは専用のアプリケーションによって物流支援サーバ10にアクセスし、ユーザに対して画面表示を行うことができる。
【0020】
ここで、発送者2は配送対象の荷物を発送するユーザであり、受取者3はこれを受け取るユーザである。また、配送協力者4は、配送対象区間の少なくとも一部について配送が可能であるとして配送協力の申し出を行ったユーザである。また、配達ロッカー50は、例えば、駅やガソリンスタンド、レストラン、コンビニエンスストア等の各拠点(拠点オーナー5が所有する施設等である場合がある)に設置された鍵付きのロッカーであり、収容スペース毎に図示しないセンサ等を有して、荷物の収容状況や鍵の施錠状況等(すなわち、ロッカーの使用状況)の情報を把握し、ネットワーク60を介して送信することができる機能を有するものである。物流支援サーバ10は、各配達ロッカー50から直接これらの情報を取得してもよいし、各配達ロッカー50の情報を集約して一元的に管理する管理システム等を介して間接的に取得してもよい。
【0021】
物流支援サーバ10は、発送者2から受取者3に対して行われる荷物の配送について、各配送協力者4の配送協力の申し出との間でマッチングを行うとともに、マッチング結果に基づいて行われるリレー形式での配送の状況を管理することで物流支援サービスを提供するサーバシステムである。例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等により構成され、図示しないCPU(Central Processing Unit)により、HDD(Hard Disk Drive)等の記録装置からメモリ上に展開したOS(Operating System)やDBMS(DataBase Management System)、Webサーバプログラム等のミドルウェアや、その上で稼働するソフトウェアを実行することで、物流支援サービスの提供に係る後述するような各種機能を実現する。
【0022】
物流支援サーバ10は、例えば、ソフトウェアとして実装されたユーザインタフェース部101、配達ロッカー管理部102、配送協力受付部103、配送依頼受付部104、評価処理部105、配送状況管理部106、マッチング処理部107、および決済処理部108等の各部を有する。また、データベース等により実装された配達ロッカーDB111、配送協力DB112、配送依頼DB113、ユーザDB114、および配送状況DB115等の各記憶部を有する。
【0023】
ユーザインタフェース部101は、発送者端末20や受取者端末30、配送協力者端末40等が備える図示しないディスプレイに、ユーザからの要求や操作に応じて表示させる画面もしくはデータを出力するとともに、これらの画面を介してユーザの操作による指示や入力内容を受け付ける機能を有する。これらの端末に表示される画面の例については後述する。
【0024】
配達ロッカー管理部102は、各拠点に設置された配達ロッカー50について、個々の収容スペースの使用状況に係る情報をネットワーク60を介して取得・収集し、配達ロッカーDB111に記録する機能を有する。また、例えば、発送者2や配送協力者4等が配達ロッカー50に荷物を収容した際に、配達ロッカー50が備える図示しないディスプレイや小型プリンター、もしくは発送者端末20や受取者端末30等に出力するレシートに表示する情報を送信する機能を有していてもよい。また、配達ロッカーDB111の内容に基づいて、拠点毎の配達ロッカー50の使用状況(空き状況)を集計して、図示しない管理者端末等のディスプレイに表示させるようにしてもよい。
【0025】
配送協力受付部103は、配送協力者4となるユーザからの配送協力者端末40を介した配送協力の申し出(もしくはその内容の変更や削除等の操作)をユーザインタフェース部101を介して受け付けて、実際に配送を行う(マッチングの対象となる)配送協力者4の候補の情報として配送協力DB112に記録する機能を有する。また、配送依頼受付部104は、発送者2からの発送者端末20を介した(もしくは受取者3からの受取者端末30を介した)荷物の配送の依頼をユーザインタフェース部101を介して受け付けて、配送依頼DB113に記録する機能を有する。
【0026】
評価処理部105は、実際に配送を行った(配送対象区間の少なくとも一部を担当した)配送協力者4に対する受取者3による受取者端末30を介したレビュー・評価の入力をユーザインタフェース部101を介して受け付けて、ユーザDB114に対象のユーザ(配送協力者4)と関連付けて記録する機能を有する。レビュー・評価を行うのは受取者3に限られず、これに代えて、もしくはこれに加えて発送者2が行うようにしてもよい。さらに、各配送協力者4が、自身が荷物を受け取った際にその時点での荷物の状態(外観)を評価するようにしてもよい。また、物流支援システム1(もしくはその運営者や管理者等)が各区間の配送スピードや配送予定との整合性等を自動もしくは手動で評価するようにしてもよい。
【0027】
配送状況管理部106は、発送者2と受取者3との間で成立した荷物の配送案件毎に、対象の荷物の配送状況に係る情報を取得・把握して配送状況DB115に記録する機能を有する。荷物の配送状況に係る情報としては、例えば、所定の配達ロッカー50への収容もしくは取り出し等がある。当該情報は、例えば配達ロッカー管理部102(もしくは配達ロッカーDB111)から取得するようにしてもよい。配送状況管理部106は、さらに例えば、受取者3からの受取者端末30を介した配送状況の確認要求をユーザインタフェース部101を介して受け付けて、配送状況DB115から対応する情報を取得して受取者端末30に表示させる機能を有する。後述するように、配送途中で受取者3が荷物を受け取ることを可能とし、途中で受け取る場合にはその旨の入力を受け付けて配送を終了させるようにしてもよい。
【0028】
マッチング処理部107は、配送依頼DB113に新たに記録された配送依頼と、予め配送協力DB112に登録されている各配送協力者4の配送協力の申し出とをマッチングし、配送依頼における発送者2から受取者3までの配送対象区間で実際に荷物を配送する配送協力者4を決定する機能を有する。発送者2および決定された各配送協力者4には、その旨を電子メールその他の通知手段により通知する。
【0029】
マッチングの手法は特に限定されないが、例えば、発送者2と受取者3の拠点の情報に基づいて得られる配送対象区間の情報から、中継点となり得る拠点の配達ロッカー50を配達ロッカーDB111から抽出し、これらの配達ロッカー50間で荷物を配送することが可能な配送協力の申し出を配送協力DB112から抽出する。そして、配送依頼における荷物の発送予定日時と、受取者3の受取希望日時、および各配送協力の申し出における配送可能時間帯の情報に基づいて、配送協力の申し出を組み合わせて、リレー形式で荷物を配送できる組み合わせを決定する。
【0030】
また、組み合わせのパターンを複数抽出し、ランク付けして提示して発送者2に選択させるようにしてもよい。例えば、各組み合わせのパターンにおける中継数をs1、トータルでの所要時間をs2、必要な配送協力者4の人数をs3、各配送協力者4についてユーザDB114に記録された評価の高さをs4とした場合、
Y=a/s1+b/s2+c/s3+d・s4 (a、b、c、dは係数)
を算出し、スコアYの値が大きい順にランク付けすることができる。スコアYの値が最も大きい組み合わせのパターンを自動的に選択してもよい。上記のs1〜s4の指標はこれに限定されず、一部の指標を考慮対象から除外してもよいし、例えば、トータルでの配送料金等の他の指標を考慮対象に加えてもよい。
【0031】
上記の例では、配送対象区間全体をリレー形式で配送する1人以上の配送協力者4を予め全て決定してから配送を開始するものとしているが、他の手法とすることも可能である。例えば、荷物が現在既に存在する、もしくは所定時間後に到着予定の拠点の近辺に所在しているユーザに対して、当該拠点から荷物を取り出し、これを他のいずれかの拠点(少なくとも現在の拠点より受取者3の拠点に近くなる拠点)に配送することができる配送協力者4を募集する。そして、応答した配送協力者4に対して次の拠点までの荷物の配送を依頼するとともに、次の拠点に対して同様の処理を繰り返すことで最終的に受取者3の拠点まで配送するヒッチハイク形式の手法とすることもできる。
【0032】
また、配送対象区間全体を一般人である配送協力者4による配送に頼るのに代えて、その一部を宅配便業者や運送会社による大量輸送手段を用いるようにしてもよい。例えば、ターミナル拠点間の基幹配送にはこのような大量輸送手段を用いるものとし、そこから先の各受取者3の拠点までの配送には、配送協力者4によるシェアリングエコノミー型の配送を用いるようにしてもよい。これにより、配送効率・スピードとコストとのバランスを適切に調整することが可能である。また、配送協力者4が自ら移動して配送する場合に限らず、例えば、自身が所有するドローン等の輸送手段を用いて配送するようにしてもよい。
【0033】
決済処理部108は、発送者2と各配送協力者4との間での配送料金の決済に係る処理を行う機能を有する。例えば、図示しない外部の金融機関システム(銀行やクレジットカード会社等)に接続して、決済に係る取引指示を行う。金銭での決済に代えて、金銭的価値を有するものを配送協力者4に付与するものとしてもよい。例えば、配送先の配達ロッカー50が設置されている店舗等が発行するポイントやクーポン等(現金より価値を割増するものとする)を付与することで当該店舗への集客を図るようにしてもよい。
【0034】
決済の手法は特に限定されないが、例えば、受取者3の元に荷物が配送された後、受取者3による配送協力者4に対するレビュー・評価の入力がされたことを条件として(すなわち、配送が全て完了した時点で)、発送者2から各配送協力者4に自動的に入金処理がされるようにすることができる。もしくは、マッチング処理部107でのマッチングが成立した際に、発送者2がクレジットカードにより配送料を支払うとともに、各配送協力者4に対しては、自身が担当する区間を配送して配達ロッカー50に荷物を預け入れた時点で、配送料が自動的に入金されるようにしてもよい。また、例えば、物流支援システム1の運営側で、発送者2から予め受領した金銭をプールしておいてその情報を物流支援システム1で管理し、発送者2もしくは受取者3のいずれかがレビュー・評価を入力したことを条件として配送協力者4に対して入金処理を行うようにしてもよい。
【0035】
<配送の流れ>
図2は、本実施の形態における荷物の配送の流れの例について概要を示した図である。ここでは、発送者2が受取者3宛に発送した荷物が複数の配送協力者4によって配送される場合の流れの例を模式的に示している。まず、各配送協力者4は、予め、自身のスケジュールに合わせて、配送協力者端末40を介して配送協力の申し出を物流支援サーバ10に登録しておく(S01)。
図3は、本実施の形態における配送協力者端末40に表示される配送協力の申し出時の画面例について概要を示した図である。
図3の左側の図に示すように、配送協力の申し出に際して、配送協力者4は、例えば、自身の移動区間(すなわち、配送を担当できる区間)と移動予定日時、および配送可能な荷物のサイズと個数等の情報を指定する。
【0036】
なお、
図3の例では、配送協力者4は移動区間として「日吉」、「渋谷」の各拠点カウンタ(配達ロッカー50)を指定しているが、カウンタでの受け渡しに限られず、例えば、発送者2の家やその付近、最寄りの駅までの経路上等の所定の場所まで荷物を受け取りに行くよう申し出を行ってもよい。また、受取者3の家やその付近、最寄りの駅までの経路上等の所定の場所まで荷物を受け渡しに行くよう申し出を行ってもよい。また、このような荷物の受け取りもしくは受け渡しの内容を配送協力者4に対してレコメンドするようにしてもよい。
【0037】
図2に戻り、次に、発送者2が、発送者端末20を介して物流支援サーバ10に対して配送依頼を登録する(S02)。
図4は、本実施の形態における発送者端末20に表示される配送依頼の登録時の画面例について概要を示した図である。
図4の左側の図に示すように、配送依頼を行うに際して、発送者2は、例えば、配送元および配送先を特定するための名称と住所の情報、および配送する荷物のサイズと個数、品目等の情報を指定する。品目の情報を自己申告させることで、危険物等の配送が行われるリスクを低減させることが可能である。受取者3(配送先)が最寄りの配達ロッカー50までではなく自宅等までの配送を希望している場合にはその旨を指定できるようにしてもよい。
【0038】
図2に戻り、その後、物流支援サーバ10において配送依頼と配送協力の申し出との間でマッチングを行う(S03)。例えば、配送元から配送先までの配送対象区間に対して荷物の配送が可能となるような配送協力の申し出の組み合わせのパターンに対して、上述したような所定の計算式により求められるスコアに基づいてランク付けを行い、ランクが最も高いものをマッチング結果として選定する。マッチングが成立した場合は、発送者2、受取者3、および対象となった各配送協力者4に対して、物流支援サーバ10がその旨を通知する(S04)。
【0039】
例えば、
図4の右側の図に示すように、マッチング成立の通知を受けた発送者端末20に対しては、発送する荷物を預け入れるカウンタ(配達ロッカー50)と預け入れる日時の範囲、配送対象区間全体での配送に要する日数、荷物のサイズと個数、および配送料金の情報がレシートとして表示される。これに対して、発送者2がこの内容での配送を実際に委託するか拒否するかを一定時間の間に限り選択できるようにしてもよい。
【0040】
また、
図3の右側の図に示すように、マッチング成立の通知を受けた配送協力者端末40に対しては、荷物を受け取るカウンタ(配達ロッカー50)と受取日時の範囲、荷物を預け入れるカウンタ(配達ロッカー50)と配送日時の範囲、配送する荷物のサイズと個数、および配送料金の概算の情報がレシートとして表示される。これに対して、配送協力者4がこの内容での配送協力を受託するか拒否するかを一定時間の間に限り選択できるようにしてもよい。
【0041】
なお、配送料金については、例えば、配送協力者4が配送可能荷物の範囲内で複数の配送案件に係る荷物をまとめて同時に配送する場合(複数の配送案件をまとめて一括でマッチングが成立した場合)は、単位荷物あたりの配送料金が割安となるように単価を減額してもよい。
【0042】
発送者2もしくは配送協力者4の少なくとも一方が一定時間の間に委託もしくは受託を拒否した場合は、例えば、対象のマッチング結果を一旦キャンセルし、配送協力の申し出の組み合わせのパターンにおいて次にランクが高い組み合わせを選択するようにしてもよい。もしくは、再度マッチングし直すようにしてもよい。
【0043】
図2に戻り、発送者2が委託し、各配送協力者4がそれぞれ受託した場合、その内容に従って配送が開始される。まず、発送者2は、発送する荷物を最初の拠点の配達ロッカー50(
図2の例では鉄道の駅)に配送する(S05)。具体的には、例えば、発送者2は、発送する荷物を最初の預入カウンタの配達ロッカー50まで運ぶ。そして、
図4の右側の図のレシート画面に表示されたバーコード(QRコード(登録商標)等の二次元バーコードであってもよい)を、対象の配達ロッカー50が備える図示しないカメラやリーダ部分にかざして認識させる。
【0044】
配達ロッカー50は、物流支援サーバ10にアクセスし、読み取ったバーコードに対応する配送内容に係る情報を取得する。そして、例えば、これを図示しない小型プリンター等によりシール状の媒体に印字する。発送者2は、このシールを荷物に貼付した上で、指定された収容スペースに収容する。配達ロッカー50では、図示しないセンサ等により荷物が収容されて施錠されたことを検知して、その旨を物流支援サーバ10に送信する。物流支援サーバ10では、配達ロッカー50の状況や配送状況に係る情報を更新する。
【0045】
なお、上述したように、発送者2が配達ロッカー50まで荷物を運ぶのに代えて、発送者2の家や付近等まで最初の配送協力者4が荷物を受け取りに来るようにしてもよい。この場合、発送者2は、上述したような配達ロッカー50において印字されるシールを取得することができないが、例えば、発送者端末20や、その他のPC等の情報処理端末、および自宅のプリンターを用いて、物流支援システム1にアクセスして上記と同様のシールを印刷し、これを荷物に貼付することができる。
【0046】
そして、自宅に荷物を受け取りにきた最初の配送協力者4に対して、例えば、配送協力者端末40に表示されたバーコードを発送者端末20で読み込む、もしくは発送者端末20に表示されたバーコードを配送協力者端末40で読み込んだ後に、荷物を渡すようにしてもよい。このように、発送者端末20もしくは配送協力者端末40でバーコードを読み込むことで、誤った配送を防止するだけでなく、物流支援システム1においても、発送者2から配送協力者4に対象の荷物が実際に受け渡されたことを検出することができ、これをトリガとして配送状況DB115の更新等の処理を行うことができる。
【0047】
その後、配送協力者4は、自身の担当区間における受取カウンタの配達ロッカー50から荷物を取り出し、これを自身の移動と併せて配送するとともに、担当区間における預入カウンタの配達ロッカー50(
図2の例ではガソリンスタンド)にこれを収容する(S06)。具体的には、例えば、配送協力者4は、受取カウンタの配達ロッカー50において、
図3の右側の図のレシート画面に表示されたバーコードを対象の配達ロッカー50にかざして認識させ、対象の荷物が収容された収容スペースを開錠して荷物を取り出す。そして、預入カウンタの配達ロッカー50まで配送してこれを収容スペースに収容する。このステップS06の処理を繰り返すことで、受取者3が荷物を受け取るカウンタの配達ロッカー50(
図2の例ではハンバーガーショップ)まで荷物が配送される。
【0048】
図5は、本実施の形態における受取者端末30に表示される配送内容の確認時の画面例について概要を示した図である。
図5の左側の図に示すように、受取者3は、配送される荷物の受取カウンタ(配達ロッカー50)と受取可能日時の範囲、荷物のサイズと個数を確認することができる。また、荷物が現在どの配達ロッカー50まで配達されたか等の配送状況に係る情報を随時確認することができる。
図5の例では、現在、中継点である「渋谷」の配達ロッカー50において荷物が保管中であることを示している。
【0049】
配達ロッカー50に荷物が保管中である場合に、例えば、受取者3が近くまで寄ることになった場合等、受取者3が当該配達ロッカー50から自身で荷物を引き取って、配送を終了させるようにしてもよい。例えば、
図5の左側の図において「引取」ボタンを押下することで、受取者3が対象の配達ロッカー50から荷物を取り出し可能とするとともに、以降の配送をキャンセルする。このとき、配送をキャンセルされた配送協力者4には所定のキャンセル料を支払うようにしてもよい。すなわち、全体での配送料金自体は減額しないものとする。
【0050】
なお、受取者3は、荷物を配送中の配送協力者4の現在位置についてより詳細な情報を閲覧できるようにしてもよい。例えば、受取者端末30に表示された地図上で現在位置をプロットしてもよい。このとき、セキュリティ上の観点から、例えば、現在位置についてはピンポイントでの高精度の表示ではなく一定範囲でのぼかした表示とするのが望ましい。人が多い場所では個人の特定が困難であることから精度をより高く表示し、人が少ない場所では精度をより低く表示するようにしてもよい。配送協力者4の同意があれば受取者3が正確な位置情報を把握可能としてもよい。これにより、配達ロッカー50を介してではなく、荷物を直接受け渡すことが可能となる。この場合、配達ロッカー50を介さないことから、荷物の受け渡しの証跡を残すため、受取者端末30に表示されたバーコードを配送協力者端末40が読み取る(もしくはその逆)ことによって配送完了としてもよい。
【0051】
図2に戻り、受取者3が荷物を受け取るカウンタ、すなわち配達対象区間の最後のカウンタの配達ロッカー50(
図2の例ではハンバーガーショップ)まで荷物が配送されると、受取者端末30に対して、受取カウンタまで荷物が到着したことを通知する(S07)。併せて発送者端末20に対しても通知するのが望ましい。
【0052】
通知を受けた受取者3は、対象の受取カウンタの配達ロッカー50まで移動し、
図5の左側の図のレシート画面に表示されたバーコードを対象の配達ロッカー50にかざして認識させ、対象の荷物が収容された収容スペースを開錠して荷物を取り出す(S08)。なお、上述したように、受取者3が配達ロッカー50まで移動して荷物を取り出すのに代えて、最後の配送協力者4が受取者3の家もしくは付近等まで荷物を配送して受け渡すようにしてもよい。
【0053】
その後、受取者3や発送者2等が、配送協力者4に対してレビュー・評価を行う(S09)。例えば、
図5の右側の図に示すようなレビュー画面において、受取者3は、荷物を受け取った結果に基づいて、各区間における配送協力者4の配送スピードや、荷物の状態等に係る評価を入力もしくは指定する。例えば、配送予定日時よりも早く荷物を受け取った場合は高い評価を設定する。また、配送予定日時を順守しなかった配送協力者4については低い評価を設定する。このとき、当該配送協力者4にはペナルティの支払を課すようにしてもよい。なお、これらの評価を自動的に設定したり、デフォルト値を設定したり等、処理を簡略化してもよい。
【0054】
上述したように、配送協力者4に対するレビュー・評価は、受取者3や発送者2が行ってもよいし、他の配送協力者4が自身が荷物を受け取る時点での状態をレビュー・評価するようにしてもよい。また、物流支援システム1(もしくはその運営者や管理者等)が評価するようにしてもよい。
【0055】
受取者3や発送者2等によるレビュー・評価の入力が完了した後に、発送者2と配送協力者4との間で決済が行われる。すなわち、発送者2は全体の配送料を支払い、その中から各配送協力者4の報酬分がそれぞれの配送協力者4に対して入金される(S10)。配送協力者4だけに限らず、配達ロッカー50の設置場所を提供している拠点オーナー5(
図2の例ではハンバーガーショップのオーナー)に対してスペース借用費用を入金するようにしてもよい。なお、上述したように、配送協力者4に対しては現金での支払に代えて割増したポイント(例えば拠点オーナー5がコンビニエンスストアの場合は当該コンビニエンスストアで使用可能なポイント)を発行するようにしてもよい。
【0056】
図6は、本実施の形態における配達ロッカー50の使用状況の管理画面の例について概要を示した図である。ここでは、地図上(
図6の例では東京都心)に各拠点(
図6の例では東京、新宿、渋谷)のカウンタにおける配達ロッカー50の収容スペース毎の使用状況をパイグラフによって示している。すなわち、
図6の例では、東京カウンタの配達ロッカー50の使用率が高く(空きが少なく)、渋谷カウンタの使用率が低い(空きが多い)状況であることを示している。
【0057】
また、
図6の例において各拠点間に表示された矢印は、拠点間で配送される荷物量(配送件数)の多さを矢印の太さおよび色により示している。
図6の例では、東京カウンタと渋谷カウンタの間の荷物量が過剰であることを示している。この場合、例えば、システム管理者等は、配達ロッカー50の使用率や拠点間の配送件数を平準化するため、東京カウンタから渋谷カウンタへの荷物の配送の全部もしくは一部をトラック等の大量輸送手段を用いて一括で輸送するよう指示することができるものとする。
【0058】
また、配達ロッカー50の使用率や拠点間の配送件数によって判断するのに代えて、例えば、各配送協力者4個人が配送した場合の配送料と、一括輸送した場合の配送料とを常時比較して、一括輸送した場合の配送料の方が安くなった場合に、配送協力者4による配送をキャンセルして一括輸送に切り替えるようにしてもよい。なお、一括輸送に切り替えたことでキャンセルされた配送協力者4には低額のキャンセル料(例えば10円等)を支払うようにしてもよい。もしくは再度マッチングを行うようにしてもよい。
【0059】
<データ構成>
図7は、本実施の形態における配達ロッカーDB111のデータ構成の例について概要を示した図である。配達ロッカーDB111は、各拠点に設置された配達ロッカー50について、属性情報等のマスタ情報および使用状況に係る情報等を保持するテーブルであり、例えば、配達ロッカーID、カウンタ名、住所、位置情報、および空き状況等の各項目を有する。
【0060】
配達ロッカーIDの項目は、例えば、各配達ロッカー50を収容スペース単位で一意に識別することができるID等の情報を保持する。カウンタ名の項目は、例えば、対象の配達ロッカー50の表示名称の情報を保持する。住所の項目は、例えば、対象の配達ロッカー50の住所の情報を保持する。位置情報の項目は、例えば、対象の配達ロッカー50の所在位置を示す緯度経度や座標等の情報を保持する。空き状況の項目は、例えば、対象の配達ロッカー50(収容スペース)の空き状況(もしくは荷物の収容状況)を示すコード値等の情報を保持する。
【0061】
図8は、本実施の形態における配送協力DB112のデータ構成の例について概要を示した図である。配送協力DB112は、配送協力者4となるユーザからの配送協力の申し出の情報を保持するテーブルであり、例えば、配送協力者ID、移動区間、移動日時、および配送可能荷物等の各項目を有する。
【0062】
配送協力者IDの項目は、例えば、対象の配送協力の申し出を行ったユーザを一意に識別することができるID等の情報を保持する。この情報は、例えば、後述するユーザDB114に登録されている。移動区間の項目は、例えば、対象の申し出において配送協力者4から申請された移動区間の情報を保持する。また、移動日時の項目は、例えば、対象の申し出において配送協力者4から申請された移動日時の情報を保持する。一定の時間帯によって指定されていてもよい。また、配送可能荷物の項目は、例えば、対象の申し出において配送協力者4から申請された配送可能な荷物の内容を特定する情報を保持する。例えば、荷物の種類やサイズ、重量、個数等の情報が含まれ得る。
【0063】
図9は、本実施の形態における配送依頼DB113のデータ構成の例について概要を示した図である。配送依頼DB113は、発送者2から受け付けた配送依頼の情報を保持するテーブルであり、例えば、配送依頼ID、発送者ID、受取者ID、配送元名、配送元住所、配送先名、配送先住所、配送希望日時、および配送荷物等の各項目を有する。
【0064】
配送依頼IDの項目は、対象の配送依頼を一意に識別するIDやシーケンス番号等の情報を保持する。発送者IDおよび受取者IDの項目は、それぞれ、対象の配送依頼を行った発送者2および配送先となる受取者3のユーザを一意に識別することができるID等の情報を保持する。この情報は、例えば、後述するユーザDB114に登録されている。
【0065】
配送元名および配送元住所の項目は、それぞれ、対象の配送依頼における配送元の氏名等の表示名および住所の情報を保持する。また、配送先名および配送先住所の項目は、それぞれ、対象の配送依頼における配送先の氏名等の表示名および住所の情報を保持する。なお、これらの項目の氏名や住所等の内容は、例えば、発送者2および受取者3について後述するユーザDB114に登録されている氏名や住所の内容と異なる内容が用いられる場合にのみ指定するようにしてもよい。
【0066】
配送希望日時の項目は、対象の配送依頼において発送者2から申請された配送希望日時の情報を保持する。一定の時間帯によって指定されていてもよい。配送荷物の項目は、対象の配送依頼において発送者2から申請された荷物の内容を特定する情報を保持する。例えば、荷物の種類やサイズ、重量、個数等の情報が含まれ得る。
【0067】
図10は、本実施の形態におけるユーザDB114のデータ構成の例について概要を示した図である。ユーザDB114は、本実施の形態の物流支援システム1(物流支援サーバ10)にアクセスすることができるユーザ(すなわち、発送者2、受取者3、配送協力者4、およびシステム管理者等)の情報を保持するテーブルであり、例えば、ユーザID、氏名、住所、決済口座情報、および配送評価等の各項目を有する。
【0068】
ユーザIDの項目は、例えば、対象のユーザを一意に識別することができるID等の情報を保持する。氏名および住所の項目は、それぞれ、対象のユーザの氏名等の表示名および住所の情報を保持する。決済口座情報の項目は、例えば、配送料の支払のためのクレジットカード番号等の情報や、配送料の入金のための銀行口座等の情報を保持する。配送評価の項目は、例えば、対象のユーザが配送協力者4として行った配送について発送者2や受取者3から受けた評価やレビューの情報を保持する。各発送者2や受取者3から受けた評価やレビューの履歴の情報として保持していてもよいし、全ての評価やレビューの平均や数、ランク等の総合評価の情報として保持していてもよい。
【0069】
図11は、本実施の形態における配送状況DB115のデータ構成の例について概要を示した図である。配送状況DB115は、発送者2と受取者3との間で成立した荷物の配送案件毎に、対象の荷物の配送状況に係る情報を保持するテーブルであり、例えば、配送ID、配送依頼ID、配送元拠点、配送先拠点、区間N、配送協力者N、配送手段N、出発予定日時N、到着予定日時N、出発実績日時N、および到着実績日時N等の各項目を有する。
【0070】
配送IDの項目は、対象の配送案件を一意に識別することができるIDやシーケンス番号等の情報を保持する。配送依頼IDの項目は、対象の配送案件の基礎となった配送依頼を特定する情報を保持する。この情報は、上述した配送依頼DB113に登録されている。配送元拠点および配送先拠点の項目は、それぞれ、対象の配送案件においてマッチングの結果設定された配送元および配送先の拠点カウンタ(配達ロッカー50)を特定する情報を保持する。これらの情報は、上述した配達ロッカーDB111に登録されている。
【0071】
区間Nの項目は、対象の配送案件においてマッチングの結果設定された配送元拠点から配送先拠点までの間の各区間のうちN番目の区間を特定する情報を保持する。例えば、区間の始点および終点の拠点カウンタの組み合わせにより特定する。配送協力者Nの項目は、例えば、対象の配送案件におけるN番目の区間の配送協力者Nを特定する情報を保持する。この情報は、上述したユーザDB114に登録されている。また、配送手段Nの項目は、例えば、対象の配送案件におけるN番目の区間で用いられる配送手段(電車、自家用車、徒歩等)を特定するコード値等の情報を保持する。
【0072】
出発予定日時Nおよび到着予定日時Nの項目は、例えばそれぞれ、対象の配送案件におけるN番目の区間の始点の出発予定日時および終点の到着予定日時の情報を保持する。一定の時間帯によって指定されていてもよい。また、出発実績日時Nおよび到着実績日時Nの項目は、例えばそれぞれ、対象の配送案件におけるN番目の区間の始点の実際の出発日時および終点の実際の到着日時の実績情報を保持する。上記の区間N以降の各項目(すなわちN番目の区間を対象とした各項目)は、区間毎に繰り返し保持するものとする。
【0073】
なお、上述の
図7〜
図11で示した各テーブルのデータ構成(項目)はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
【0074】
以上に説明したように、本発明の一実施の形態である物流支援システム1によれば、例えば、ネット通販等において、発送者2(販売者)が発送した荷物を、受取者3(購入者)の元に配送するというような場合に、配送対象区間の途中の一部区間のみなら配送が可能であるというような複数の配送協力者4(キャリア)を組み合わせて、配送対象区間全体の配送が可能となるようにマッチングする。そして、これらの配送協力者4が例えば配達ロッカー50を介してリレー形式で順次荷物を受け渡して配送することで、配送対象区間全体での荷物の配送を柔軟に低コストで行うシェアリングエコノミー型の物流サービスを実現することができる。
【0075】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【0076】
例えば、配送される荷物のセキュリティを確保するため、荷物を梱包した段ボール箱等をテープ等で封止した部分に、万引き防止等に用いられるICタグ付きシール等を貼付しておくようにしてもよい。このICタグを配送経路上の各配達ロッカー50や、各配送協力者4の配送協力者端末40等により読み取ることで、配送協力者4を含む第三者に開封されていないかを確認することができる。荷物に貼付されたICタグのID情報を配送状況DB115等に記録して管理することで、荷物をトラッキングできるようにしてもよい。
【0077】
また、各配送案件について配送状況DB115等に記録された配送実績・配送履歴の情報から、発送者2、受取者3、配送協力者4の動線情報を得ることができるため、この情報をユーザの属性情報と併せてマーケティング情報として活用するようにしてもよい。特に、配送協力者4に対する配送料として、例えば、配達ロッカー50が所在するコンビニエンスストア等の店舗で使用可能なポイントを付与した場合に、当該ポイントの使用履歴の情報と併せて分析することで、ユーザの層毎のより詳細な購買動向を把握することができ、クーポンの自動発行等、その日の状況に応じたリアルタイムマーケティングを行うことができる。
【0078】
また、非特許文献1のような航空便による海外(もしくは国内の他地域)への渡航者を配送協力者4とすることも可能である。例えば、出発地の空港のチェックインカウンターの付近に配送カウンタを備え、ここで複数の配送協力者4(もしくは発送者2)が運んできた荷物をまとめて一つのスーツケース等に収容する。この配送カウンタで渡航者である配送協力者4が当該スーツケース等を受け取り、自身が利用する航空会社のチェックインカウンターで手荷物として預ける。そして、目的地でスーツケース等を受け取り、税関を通過して、目的地空港での配送カウンタに受け渡す。目的地空港の配送カウンタでは、スーツケース等に収容された荷物を取り出し、それぞれの荷物を配送する配送協力者4(もしくは受取者3)に受け渡す。以降は上述した本実施の形態における配送と同様の手法により受取者3まで荷物が配送される。
【0079】
なお、複数の荷物を配送するスーツケース等には施錠を行う。GPS(Global Positioning System)センサにより取得した位置情報を発信する装置を内蔵するようにしてもよい。また、海外等に渡航する予定のユーザに対して、渡航内容の情報を自動的に取得して、配送協力の申し出を行うようレコメンドするようにしてもよい。渡航内容の情報は、例えば、配送協力者4のスマートフォン等(配送協力者端末40)に保持された航空券の情報や渡航予定のスケジュール情報等をアプリケーションにより自動的に参照して把握することができる。
【0080】
また、上記の実施の形態では、荷物の受け渡しに際して配達ロッカー50を使用する例を中心に説明したが、これに限られない。配達ロッカー50に代えて、もしくはこれに加えて、例えば、拠点オーナー5や、拠点の従業員等のスタッフを配置したカウンタを介して人手で受け渡しするものであってもよい。このカウンタには、配達ロッカー50と同様の機能(例えば、シールやラベルの印字機能、バーコード読み取り機能等)を備えたハードウェアが設置されているのが望ましい。このハードウェアは、例えば、通信機能を備えたPC等の情報処理端末とプリンター、およびバーコードリーダ等によって構成することができるが、これに限られない。バーコード読み取り機能を備えるスマートフォンやタブレット端末等の携帯端末とプリンターによって構成するものであってもよい。
【0081】
また、上記の実施の形態では、配送協力者4から配送協力の申し出を受け付ける構成としたが、これに限られない。例えば、所定期間の過去の各配送協力者4の実績と、新たに受け付けた配送依頼とをマッチングし、成立結果として抽出された配送協力者4に対して、配送協力の申し出なしに配送協力に係るレシートを配送協力者端末40に対してプッシュ型で通知する構成としてもよい。
【0082】
上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、SSD(Solid State Drive)等の記録装置、またはICカード、SDカード、DVD等の記録媒体に置くことができる。
【0083】
また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。