特開 2024-37128 荷物の配送方法、およびサーバ

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024037128

(43)【公開日】2024-03-18

(54)【発明の名称】荷物の配送方法、およびサーバ

(51)【国際特許分類】

   G06Q 10/08 20240101AFI20240311BHJP

   B65G 61/00 20060101ALI20240311BHJP

【ＦＩ】

G06Q10/08

B65G61/00 550

B65G61/00 540

【審査請求】未請求

【請求項の数】1

【出願形態】ＯＬ

(21)【出願番号】P 2023063313

(22)【出願日】2023-04-10

(62)【分割の表示】P 2022141481の分割

【原出願日】2022-09-06

(71)【出願人】

【識別番号】521222349

【氏名又は名称】株式会社Ｎｉｃｅ Ｅｚｅ

(74)【代理人】

【識別番号】110000408

【氏名又は名称】弁理士法人高橋・林アンドパートナーズ

(72)【発明者】

【氏名】松浦 学

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA16

(57)【要約】

【課題】宅配ボックスを効率良く利用することで荷物の配送負担を軽減可能な方法、およびこの方法を実現するためのサーバを提供すること。
【解決手段】配送方法は、第１の宅配ボックスに配送される荷物の総数をアロケーションサーバにおいて予測すること、予測された総数が第１の宅配ボックスの容量を超える期間が存在する場合、当該期間における荷物の配送先として第１の宅配ボックスを指定した複数のユーザから一人を第１のユーザとしてアロケーションサーバによって選択すること、第１のユーザの通信端末に対し、荷物の配送日時の変更、または荷物の配送先として第２の宅配ボックスへの変更を依頼するための変更依頼信号をアロケーションサーバから送信すること、および、上記通信端末から送信される、変更を受諾するまたは拒否する応答信号をアロケーションサーバで受信することを含む。
【選択図】図３Ａ

【特許請求の範囲】

【請求項1】

第１の宅配ボックスに配送される荷物の総数をアロケーションサーバにおいて予測すること、
予測された前記総数が前記第１の宅配ボックスの容量を超える期間が存在する場合、前記期間における前記荷物の配送先として前記第１の宅配ボックスを指定した複数のユーザから一人を第１のユーザとして前記アロケーションサーバによって選択すること、
前記第１のユーザの通信端末に対し、前記荷物の配送日時の変更、または前記荷物の前記配送先として第２の宅配ボックスへの変更を依頼するための変更依頼信号を前記アロケーションサーバから送信すること、および、
前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を前記アロケーションサーバで受信することを含む、荷物の配送方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態の一つは、荷物を配送するための配送方法、およびこの配送方法を実現するためのサーバに関する。

【背景技術】

【0002】

荷物をユーザへ配送する際、ユーザが不在の場合がある。この場合、荷物を宅配ボックスに搬入し、荷物の搬入をユーザに通知することで、ユーザは任意の時間に荷物を宅配ボックスから取り出すことができる。これにより、再配送するための負担とコストが軽減されるとともに、ユーザも配送のために待機する必要がなくなるため、時間的な制約から解放される。また、荷物の盗難や、個人情報の流出も防止することができる（例えば、特許文献１参照。）。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

本発明の実施形態の一つは、荷物をユーザへ配送するための新規な方法、およびこの方法を実現するためのサーバを提供することを課題の一つとする。あるいは、本発明の実施形態の一つは、宅配ボックスを効率良く利用することで荷物の配送負担を軽減可能な方法、およびこの方法を実現するためのサーバを提供することを課題の一つとする。

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

【0005】

本発明の実施形態の一つは、荷物の配送方法である。この配送方法は、第１の宅配ボックスに配送される荷物の総数をアロケーションサーバにおいて予測すること、予測された総数が第１の宅配ボックスの容量を超える期間が存在する場合、当該期間における荷物の配送先として第１の宅配ボックスを指定した複数のユーザから一人を第１のユーザとしてアロケーションサーバによって選択すること、第１のユーザの通信端末に対し、荷物の配送日時の変更、または荷物の配送先として第２の宅配ボックスへの変更を依頼するための変更依頼信号をアロケーションサーバから送信すること、および、上記通信端末から送信される、変更を受諾するまたは拒否する応答信号をアロケーションサーバで受信することを含む。

【0006】

本発明の実施形態の一つは、サーバである。このサーバは、第１の宅配ボックスに配送される荷物の総数を予測し、予測された総数が第１の宅配ボックスの容量を超える期間が存在する場合、当該期間における荷物の配送先として第１の宅配ボックスを指定した複数のユーザから一人を第１のユーザとして選択し、第１のユーザの通信端末に対し、荷物の配送日時の変更、または荷物の配送先として第２の宅配ボックスへの変更を依頼するための変更依頼信号を送信し、上記通信端末から送信される、変更を受諾するまたは拒否する応答信号を受信するように構成される。

【図面の簡単な説明】

【0007】

【図1A】本発明の実施形態に係る配送方法を説明する概念図。

【図1B】本発明の実施形態に係る配送方法を実現するシステムの概念図。

【図2】本発明の実施形態に係るアロケーションサーバの機能ブロック図。

【図3A】本発明の実施形態に係る配送方法の一例を示すスキーム。

【図3B】本発明の実施形態に係る配送方法の一例を示すスキーム。

【図3C】本発明の実施形態に係る配送方法の一例を示すスキーム。

【図4】本発明の実施形態に係る配送方法で用いられる特徴量の一例を示す表。

【図5A】本発明の実施形態に係る配送方法を説明する模式図。

【図5B】本発明の実施形態に係る配送方法を説明する模式図。

【図6】本発明の実施形態に係る配送方法を説明するためのフローチャート。

【図7】本発明の実施形態に係る配送方法で用いられるユーザパラメータの一例を示す表。

【図8】本発明の実施形態に係る配送方法における信号の授受を示す模式図。

【図9】本発明の実施形態に係る配送方法における信号の授受を示す模式図。

【図10】本発明の実施形態に係る配送方法における信号の授受を示す模式図。

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

【0008】

以下、本発明の各実施形態について、図面などを参照しつつ説明する。ただし、本発明は、その要旨を逸脱しない範囲において様々な態様で実施することができ、以下に例示する実施形態の記載内容に限定して解釈されるものではない。

【0009】

図面は、説明をより明確にするため、実際の態様に比べ、各部の幅、厚さ、形状などについて模式的に表される場合があるが、あくまで一例であって、本発明の解釈を限定するものではない。本明細書と各図において、既出の図に関して説明したものと同様の機能を備えた要素には、同一の符号を付して、重複する説明を省略することがある。同一、あるいは類似する複数の構造を総じて表す際にはこの符号が用いられ、これらを個々に表す際には符号の後にハイフンと自然数が加えられる。

【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】

なお、荷物の配送先として宅配ボックス１９０以外の物理的空間が割り当てられる場合には、その物理的空間を管理する主体が有する通信端末から配送通知信号がユーザ端末１０２へ送信される。

【0068】

（２）アロケーション事業者が配送を担う場合
上述したように、本配送方法では、アロケーション事業者１１０が荷物の配送を担うことができる。換言すると、配送事業者１７０がアロケーション事業を担ってもよい。この場合には、図１０に示すように、配送依頼信号は店舗サーバ１８２からアロケーションサーバ１１２へ送信され（Ｓ１４０）、その受信確認が店舗サーバ１８２へ送信される（Ｓ１４２）。また、配送通知信号もアロケーションサーバ１１２からユーザ端末１０２へ送信される（Ｓ１４４）。これら以外の信号の授受は配送事業者１７０とアロケーション事業者１１０が独立した事業者である場合と同様であるため、説明は割愛する。

【0069】

以上述べたように、本配送方法では、配送事業者１７０から依頼を受けたアロケーション事業者１１０が指定宅配ボックスからロッカーを割り当てるだけでなく、宅配ボックス１９０の需要予測に基づき、当該指定宅配ボックスを利用するユーザ１００から一人または複数を選択し、選択されたユーザ１００に対し、配送日時または配送先の変更のためのプロモーションを行う。また、ユーザの選択では、ユーザの過去の挙動を含むユーザパラメータ（荷物の滞在時間、不在実績の頻度など）が利用されるため、ユーザに対してプロモーションを受諾する動機を提供することができる。その結果、宅配ボックス１９０の容量が不足する事態が想定される場合に適切な配送調整を行うことができ、宅配ボックス１９０のロッカーが全て利用されているために再配送を余儀なくされるという事態を回避することができる。このことは、配送人の負担と配送コストを大幅な低減に寄与する。

【0070】

本発明の実施形態として上述した各実施形態は、相互に矛盾しない限りにおいて、適宜組み合わせて実施することができる。また、各実施形態の表示装置を基にして、当事業者が適宜構成要素の追加、削除もしくは設計変更を行ったもの、又は、工程の追加、省略もしくは条件変更を行ったものも、本発明の要旨を備えている限り、本発明の範囲に含まれる。

【0071】

上述した各実施形態の態様によりもたらされる作用効果とは異なる他の作用効果であっても、本明細書の記載から明らかなもの、又は、当事業者において容易に予測し得るものについては、当然に本発明によりもたらされるものと解される。

【符号の説明】

【0072】

１００：ユーザ、１０２：ユーザ端末、１０２－１：第１のユーザ端末、１０２－２：第２のユーザ端末、１０４：通信ネットワーク、１１０：アロケーション事業者、１１２：アロケーションサーバ、１１４：制御部、１１６：需要予測部、１１８：調整部、１２０：ユーザ管理部、１２２：記憶部、１２４：通信部、１２６：入力部、１２８：出力部、１５０：ボックス管理事業者、１５２：ボックス管理サーバ、１６０：プラットフォーム提供事業者、１６２：プラットフォームサーバ、１７０：配送事業者、１７２：配送管理サーバ、１８０：店舗、１８２：店舗サーバ、１９０：宅配ボックス、２００：配送システム

【図1A】

【図1B】

【図2】

【図3A】

【図3B】

【図3C】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9】

【図10】