IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社Nice Ezeの特許一覧

<>
  • 特開-荷物の配送方法、およびサーバ 図1A
  • 特開-荷物の配送方法、およびサーバ 図1B
  • 特開-荷物の配送方法、およびサーバ 図2
  • 特開-荷物の配送方法、およびサーバ 図3A
  • 特開-荷物の配送方法、およびサーバ 図3B
  • 特開-荷物の配送方法、およびサーバ 図3C
  • 特開-荷物の配送方法、およびサーバ 図4
  • 特開-荷物の配送方法、およびサーバ 図5A
  • 特開-荷物の配送方法、およびサーバ 図5B
  • 特開-荷物の配送方法、およびサーバ 図6
  • 特開-荷物の配送方法、およびサーバ 図7
  • 特開-荷物の配送方法、およびサーバ 図8
  • 特開-荷物の配送方法、およびサーバ 図9
  • 特開-荷物の配送方法、およびサーバ 図10
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024036923
(43)【公開日】2024-03-18
(54)【発明の名称】荷物の配送方法、およびサーバ
(51)【国際特許分類】
   G06Q 10/08 20240101AFI20240311BHJP
   B65G 61/00 20060101ALI20240311BHJP
【FI】
G06Q10/08
B65G61/00 542
B65G61/00 550
【審査請求】有
【請求項の数】12
【出願形態】OL
(21)【出願番号】P 2022141481
(22)【出願日】2022-09-06
(11)【特許番号】
(45)【特許公報発行日】2023-04-27
(71)【出願人】
【識別番号】521222349
【氏名又は名称】株式会社Nice Eze
(74)【代理人】
【識別番号】110000408
【氏名又は名称】弁理士法人高橋・林アンドパートナーズ
(72)【発明者】
【氏名】松浦 学
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049CC51
(57)【要約】
【課題】宅配ボックスを効率良く利用することで荷物の配送負担を軽減可能な方法、およびこの方法を実現するためのサーバを提供すること。
【解決手段】配送方法は、第1の宅配ボックスに配送される荷物の総数をアロケーションサーバにおいて予測すること、予測された総数が第1の宅配ボックスの容量を超える期間が存在する場合、当該期間における荷物の配送先として第1の宅配ボックスを指定した複数のユーザから一人を第1のユーザとしてアロケーションサーバによって選択すること、第1のユーザの通信端末に対し、荷物の配送日時の変更、または荷物の配送先として第2の宅配ボックスへの変更を依頼するための変更依頼信号をアロケーションサーバから送信すること、および、上記通信端末から送信される、変更を受諾するまたは拒否する応答信号をアロケーションサーバで受信することを含む。
【選択図】図3A
【特許請求の範囲】
【請求項1】
第1の宅配ボックスに配送される荷物の総数をアロケーションサーバにおいて予測すること、
予測された前記総数が前記第1の宅配ボックスの容量を超える期間が存在する場合、前記期間における前記荷物の配送先として前記第1の宅配ボックスを指定した複数のユーザから一人を第1のユーザとして前記アロケーションサーバによって選択すること、
前記第1のユーザの通信端末に対し、前記荷物の配送日時の変更、または前記荷物の前記配送先として第2の宅配ボックスへの変更を依頼するための変更依頼信号を前記アロケーションサーバから送信すること、および、
前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を前記アロケーションサーバで受信することを含む、荷物の配送方法。
【請求項2】
前記総数の前記予測は、過去に前記第1の宅配ボックスに配送された荷物のカテゴリ、大きさ、および配送日時、ならびに前記荷物を構成する商品の発注時に前記商品に係る特典が前記複数のユーザによって利用されたか否か、の少なくとも一つを特徴量として用いる教師あり学習モデルによって行われる、請求項1に記載の配送方法。
【請求項3】
前記第1の宅配ボックスを管理するボックス管理サーバから送信される、前記第1の宅配ボックスに設けられる複数のロッカーの使用状況を含むロッカー情報信号を、前記アロケーションサーバで受信することをさらに含む、請求項1に記載の配送方法。
【請求項4】
前記複数のユーザから前記第1のユーザと異なる第2のユーザをアロケーションサーバによって選択すること、
前記第2のユーザの通信端末に対し、前記変更依頼信号を前記アロケーションサーバから送信すること、および
前記第2のユーザの前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を、前記アロケーションサーバで受信することをさらに含む、請求項1に記載の配送方法。
【請求項5】
前記第1のユーザの前記選択は、前記アロケーションサーバに格納されたユーザパラメータに基づいて行われ、
前記ユーザパラメータは、
前記第1のユーザが過去に発注した荷物の前記第1の宅配ボックス内における滞在時間、
前記第1のユーザが過去に前記依頼を受諾した頻度、
前記第1のユーザの属性、
前記第1のユーザの住居種別、および
前記第1のユーザの居住階の少なくとも一つを含む、請求項1に記載の配送方法。
【請求項6】
前記依頼を受諾した前記第1のユーザの前記通信端末に対し、前記第1のユーザにインセンティブを付与したことを通知するためのインセンティブ通知信号を前記アロケーションサーバから送信することをさらに含む、請求項1に記載の配送方法。
【請求項7】
第1の宅配ボックスに配送される荷物の総数を予測し、
予測された前記総数が前記第1の宅配ボックスの容量を超える期間が存在する場合、前記期間における荷物の配送先として前記第1の宅配ボックスを指定した複数のユーザから一人を第1のユーザとして選択し、
前記第1のユーザの通信端末に対し、前記荷物の配送日時の変更、または前記荷物の前記配送先として第2の宅配ボックスへの変更を依頼するための変更依頼信号を送信し、
前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を受信するように構成される、サーバ。
【請求項8】
前記総数の前記予測は、過去に前記第1の宅配ボックスに配送された荷物のカテゴリ、大きさ、および配送日時、ならびに前記荷物を構成する商品の発注時に前記商品に係る特典が前記複数のユーザによって利用されたか否か、の少なくとも一つを特徴量として用いる教師あり学習モデルによって行われる、請求項7に記載のサーバ。
【請求項9】
前記第1の宅配ボックスを管理するボックス管理サーバから送信される、前記第1の宅配ボックスに設けられる複数のロッカーの使用状況を含むロッカー情報信号を受信するようにさらに構成される、請求項7に記載のサーバ。
【請求項10】
前記複数のユーザから前記第1のユーザと異なる第2のユーザを選択し、
前記第2のユーザの通信端末に対して前記変更依頼信号を送信し、
前記第2のユーザの前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を受信するようにさらに構成される、請求項7に記載のサーバ。
【請求項11】
前記第1のユーザの前記選択は、前記サーバに格納されたユーザパラメータに基づいて行われ、
前記ユーザパラメータは、
前記第1のユーザが過去に発注した荷物の前記第1の宅配ボックス内における滞在時間、
前記第1のユーザが過去に前記依頼を受諾した頻度、
前記第1のユーザの属性、
前記第1のユーザの住居種別、および
前記第1のユーザの居住階の少なくとも一つを含む、請求項7に記載のサーバ。
【請求項12】
前記依頼を受諾した前記第1のユーザの前記通信端末に対し、前記第1のユーザにインセンティブを付与したことを通知するためのインセンティブ通知信号を送信するようにさらに構成される、請求項7に記載のサーバ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態の一つは、荷物を配送するための配送方法、およびこの配送方法を実現するためのサーバに関する。
【背景技術】
【0002】
荷物をユーザへ配送する際、ユーザが不在の場合がある。この場合、荷物を宅配ボックスに搬入し、荷物の搬入をユーザに通知することで、ユーザは任意の時間に荷物を宅配ボックスから取り出すことができる。これにより、再配送するための負担とコストが軽減されるとともに、ユーザも配送のために待機する必要がなくなるため、時間的な制約から解放される。また、荷物の盗難や、個人情報の流出も防止することができる(例えば、特許文献1参照。)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2020-077391号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明の実施形態の一つは、荷物をユーザへ配送するための新規な方法、およびこの方法を実現するためのサーバを提供することを課題の一つとする。あるいは、本発明の実施形態の一つは、宅配ボックスを効率良く利用することで荷物の配送負担を軽減可能な方法、およびこの方法を実現するためのサーバを提供することを課題の一つとする。
【課題を解決するための手段】
【0005】
本発明の実施形態の一つは、荷物の配送方法である。この配送方法は、第1の宅配ボックスに配送される荷物の総数をアロケーションサーバにおいて予測すること、予測された総数が第1の宅配ボックスの容量を超える期間が存在する場合、当該期間における荷物の配送先として第1の宅配ボックスを指定した複数のユーザから一人を第1のユーザとしてアロケーションサーバによって選択すること、第1のユーザの通信端末に対し、荷物の配送日時の変更、または荷物の配送先として第2の宅配ボックスへの変更を依頼するための変更依頼信号をアロケーションサーバから送信すること、および、上記通信端末から送信される、変更を受諾するまたは拒否する応答信号をアロケーションサーバで受信することを含む。
【0006】
本発明の実施形態の一つは、サーバである。このサーバは、第1の宅配ボックスに配送される荷物の総数を予測し、予測された総数が第1の宅配ボックスの容量を超える期間が存在する場合、当該期間における荷物の配送先として第1の宅配ボックスを指定した複数のユーザから一人を第1のユーザとして選択し、第1のユーザの通信端末に対し、荷物の配送日時の変更、または荷物の配送先として第2の宅配ボックスへの変更を依頼するための変更依頼信号を送信し、上記通信端末から送信される、変更を受諾するまたは拒否する応答信号を受信するように構成される。
【図面の簡単な説明】
【0007】
図1A】本発明の実施形態に係る配送方法を説明する概念図。
図1B】本発明の実施形態に係る配送方法を実現するシステムの概念図。
図2】本発明の実施形態に係るアロケーションサーバの機能ブロック図。
図3A】本発明の実施形態に係る配送方法の一例を示すスキーム。
図3B】本発明の実施形態に係る配送方法の一例を示すスキーム。
図3C】本発明の実施形態に係る配送方法の一例を示すスキーム。
図4】本発明の実施形態に係る配送方法で用いられる特徴量の一例を示す表。
図5A】本発明の実施形態に係る配送方法を説明する模式図。
図5B】本発明の実施形態に係る配送方法を説明する模式図。
図6】本発明の実施形態に係る配送方法を説明するためのフローチャート。
図7】本発明の実施形態に係る配送方法で用いられるユーザパラメータの一例を示す表。
図8】本発明の実施形態に係る配送方法における信号の授受を示す模式図。
図9】本発明の実施形態に係る配送方法における信号の授受を示す模式図。
図10】本発明の実施形態に係る配送方法における信号の授受を示す模式図。
【発明を実施するための形態】
【0008】
以下、本発明の各実施形態について、図面などを参照しつつ説明する。ただし、本発明は、その要旨を逸脱しない範囲において様々な態様で実施することができ、以下に例示する実施形態の記載内容に限定して解釈されるものではない。
【0009】
図面は、説明をより明確にするため、実際の態様に比べ、各部の幅、厚さ、形状などについて模式的に表される場合があるが、あくまで一例であって、本発明の解釈を限定するものではない。本明細書と各図において、既出の図に関して説明したものと同様の機能を備えた要素には、同一の符号を付して、重複する説明を省略することがある。同一、あるいは類似する複数の構造を総じて表す際にはこの符号が用いられ、これらを個々に表す際には符号の後にハイフンと自然数が加えられる。
【0010】
以下、本発明の実施形態の一つに係る荷物の配送方法(以下、単に本配送方法とも記す。)、本配送方法を実現するためのアロケーションサーバ、および本配送を実現可能なシステムについて説明する。
【0011】
1.配送方法の概要
本配送方法の概念図を図1Aに模式的に示す。この配送方法では、所謂留め置きと言う方法で顧客(以下、ユーザ)100が発注した商品を含む荷物が配送される。すなわち、ユーザ100に対して戸別に荷物を配送するのではなく、宅配ボックス190が備えるロッカーに荷物を収容することで配送が行われる。
【0012】
ユーザ100は、インターネットに例示されるワイドエリアネットワークや電話回線、ファックス回線などの種々の通信ネットワーク104を介して、あるいは対面での商取引を通じて商品の売り手である店舗180に商品を発注する。店舗180は、スーパーマーケットやデパートなどの総合小売店、酒屋、クリーニング店、レストランや喫茶店、ファーストフードなどの飲食店、書店、文房具店、化粧品や薬品などを扱うドラッグストアなどの実店舗でもよい。また、店舗180は、自身で構築した電子商取引用のプラットフォーム、またはプラットフォームを有償または無償で提供する事業者(以下、プラットフォーム提供事業者)160から提供される電子商取引用のプラットフォーム上で電子商取引を行う店舗でもよい。したがって、店舗180は必ずしも実店舗である必要は無い。荷物に含まれる商品に制約はなく、あらゆる業種に属する商品が含まれる。また、商品はレンタル品(レンタルシューズ、レンタル衣装、レンタルバッグなど)でもよく、試供品(試供化粧品や試供食品など)でもよい。
【0013】
荷物を配送する主体(以下、配送人)は、商品の発注を受けた店舗180、または、店舗180、プラットフォーム提供事業者160、若しくは後述するアロケーション事業者110から配送依頼を受ける配送事業者170である。あるいは、アロケーション事業者110が配送人として配送業務を担ってもよい。
【0014】
上述したように、配送される荷物は全て宅配ボックス190に留め置かれる。したがって、配送人は、荷物を各住戸へ運搬する必要は無く、ユーザ100が在宅か不在かを確認する必要もない。このため、本配送方法では、配送人に対する負担が極めて小さく、かつ、配送に必要な時間やコストを大幅に削減し、配送業務における人的資源を有効活用することが可能である。
【0015】
本配送方法ではさらに、荷物が配送される前に、ユーザ100が指定する宅配ボックス190の複数のロッカーのうち一つまたは複数が割り当てられる。より具体的には、アロケーション事業者110は、ユーザ100が指定した宅配ボックス190が備える複数のロッカーのうち当該に荷物に適した一つまたは複数のロッカーを選択する。さらに、荷物の配送人は、荷物を配送する前に、通信ネットワーク104を介し、アロケーション事業者110が選択したロッカーの割り当てを受け、その後、荷物を配送する。このため、荷物を配送する前に予め荷物を収容するためのロッカーを確実に確保することができ、全てのロッカーが使用されているために強いられる再配送という負担から解放される。なお、アロケーション事業者110は、ロッカーの選択に当たり、通信ネットワーク104を介し、宅配ボックス190から直接、または宅配ボックス190を管理する事業者(以下、ボックス管理事業者150)から各宅配ボックス190のロッカーの使用状況に関する情報(以下、ロッカー情報と言う。)を定期的にまたは随時提供を受ける。このため、配送人の要求に適宜応答して荷物の収容に適切なロッカーを迅速に割り当てることができる。
【0016】
また、以下に詳述する様に、本配送方法では、アロケーション事業者110によって各宅配ボックス190の需要予測が実行され、需要予測に基づいて荷物の配送調整が行われる。具体的には、アロケーション事業者110は、各宅配ボックス190に配送される荷物総数を学習モデルを用いて予測する。予測された荷物総数が宅配ボックス190の容量(すなわち、各宅配ボックス190のロッカーの総数)を超える期間(以下、繁忙期間)が存在すると判断すると、繁忙期間における荷物の配送先として当該宅配ボックス190を指定した複数のユーザ100から一人または複数を選択する。選択は、後述するユーザパラメータに従って行われる。その後、選択したユーザ100に対し、荷物の配送日時の変更、または荷物の配送先を他の宅配ボックスへ変更する依頼(以下、ユーザ100に対するこれらの依頼をプロモーションとも言う。)を行う。これにより、一部のユーザ100に対し、繁忙期間を避けて宅配ボックス190を利用することを促すことができる。あるいは、容量に余裕のある他の宅配ボックス190の利用を促すことができる。その結果、荷物総数が宅配ボックス190の容量を超える事態を回避することができるので、一定期間に荷物の配送が集中することなく、配送人は確実にロッカーを確保することができる。また、配送業務の平準化ができるため、意図しない配送遅延も防止することができる。
【0017】
なお、アロケーション事業者110は、ユーザ100がプロモーションを受諾した場合には、ユーザ100に対して何らかの特典(インセンティブ)を提供してもよい。これにより、ユーザ100は、アロケーション事業者110からのプロモーションをより積極的に受諾するように動機づけられ、その結果、より円滑な配送調整と配送業務が可能となる。
【0018】
2.配送システムの構成
本配送方法を実現するための配送システム200の構成の一例を図1Bに示す。配送システム200は、アロケーション事業者110によって管理されるアロケーションサーバ112、一つまたは複数の宅配ボックス190、宅配ボックス190を管理するためにボックス管理事業者150が利用するボックス管理サーバ152、および配送事業者170が荷物の配送を管理するための配送管理サーバ172を含む。配送システム200はさらに、店舗180がユーザ100からの発注の際に利用する店舗サーバ182、プラットフォーム提供事業者160がプラットフォーム構築のために用いるプラットフォームサーバ162を含んでもよい。また、配送システム200は、ユーザ100が管理する通信端末であるユーザ端末102を含んでもよい。これらの構成は、通信ネットワーク104に接続されており、互いに通信可能な状況に置かれる。
【0019】
なお、アロケーション事業者110が配送人として荷物の配送を担う場合には、アロケーションサーバ112と配送管理サーバ172はアロケーション事業者110によって管理されてもよく、あるいはこれら二つのサーバが統合された一つのサーバがアロケーション事業者110によって管理されてもよい。以下、これらの構成について説明するが、配送管理サーバ172やプラットフォームサーバ162、店舗サーバ182は既存のサーバまたはコンピュータなどの通信端末で構築することができるため、説明は割愛する。
【0020】
(1)宅配ボックスとボックス管理サーバ
各宅配ボックス190は複数のロッカーを備えており、集合住宅の共用スペースのほか、駅、コンビニエンスストア、総合小売店、アミューズメント施設、駐車場、高速道路のサービスエリアなど、任意の場所に設置することができる。複数の宅配ボックス190は、全て一つの事業者によって管理されていてもよく、あるいは互いに独立した複数の事業者によって管理される複数の宅配ボックスによって構成されてもよい。また、複数の宅配ボックス190の仕様は互いに同一でもよく、あるいは少なくとも一つの仕様が他のそれと異なってもよい。各宅配ボックス190に設けられる複数のロッカーの大きさは互いに同一でもよく、少なくとも一つが他と異なってもよい。各宅配ボックス190には、それぞれを識別するための識別子(ボックスID)が付与され、各宅配ボックス190の複数のロッカーのそれぞれに対しても各ロッカーを識別するための識別子(ロッカーID)が付与される。
【0021】
図示しないが、宅配ボックス190の各ロッカーには、ロッカー内の荷物の存否や配置状態を把握するためのセンサまたはカメラを備えてもよい。宅配ボックス190はさらに、各ロッカーの開閉を感知するセンサを備えることができる。このため、例えばロッカーが開かれた際にカメラを用いて内部の配置状態を映像(静止画または動画)として取得し、ロッカーが開閉された際に、ロッカーの開閉時刻とともに映像のデータをボックス管理サーバ152へ送信するように宅配ボックス190を構成してもよい。これにより、ロッカーに荷物が収容された時刻と取り出された時刻を宅配ボックス190またはボックス管理サーバ152上で把握することができる。
【0022】
センサによって把握されるロッカー内の荷物の存否は、定期的に、ボックス管理サーバ152からの要求に応じて、または宅配ボックス190に設けられるセンサの動作に応答して、ロッカー情報としてボックス管理サーバ152に送信される。このため、ボックス管理サーバ152は、宅配ボックス190のロッカー情報を常時把握することができる。ロッカー情報は、定期的に、またはアロケーションサーバ112の要求に応じてボックス管理サーバ152からアロケーションサーバ112に送信される。したがって、アロケーションサーバ112もロッカー情報を常時または適時に把握することができる。
【0023】
(2)アロケーションサーバ
本発明の実施形態の一つに係るアロケーションサーバ112の機能ブロック図を図2に示す。アロケーションサーバ112は通信機能と計算機能を有するデバイスであり、その構成に制約はない。例えば、アロケーションサーバ112は、アロケーションサーバ112全体を制御する制御部114に加え、記憶部122、通信部124、入力部126、出力部128などを備えることができる。
【0024】
入力部126は、アロケーションサーバ112を操作するためのインターフェースの一つであり、例えばキーボード、マウス、タッチペン、タッチセンサなどである。出力部128は情報を出力するためのインターフェースであり、液晶表示装置や電界発光表示装置などの表示装置が例示される。入力部126の一部はタッチセンサとして出力部128に組み込まれてもよい。記憶部122は、例えば、ランダムアクセスメモリ(RAM)やリードオンリーメモリ(ROM)などの主記憶装置や、ハードディスクドライブ(HDD)やフラッシュメモリなどの外部記憶装置を含む。記憶部122は制御部114の演算結果やプログラムなどの各種情報を記憶するとともに、ユーザ100に係る情報であるユーザパラメータや宅配ボックス190の需要予測のために利用される各種情報が格納される。記憶部122には、需要予測のための演算に必要なインプットデータ、教師データ、学習モデル、学習モデルによる需要予測結果などがさらに格納される。
【0025】
通信部124は、通信ネットワーク104を介してボックス管理サーバ152、プラットフォームサーバ162、配送管理サーバ172、店舗サーバ182などとの通信を行うためのユニットである。通信部124は、例えば宅配ボックス190またはボックス管理サーバ152と通信を行い、ロッカー情報を取得する。さらに通信部124は、店舗サーバ182またはプラットフォームサーバ162と通信を行い、各店舗180またはプラットフォーム提供事業者160が商品に係る特典を提供しているか否か、ユーザ100が当該特典を利用したか否か、特典の内容などを含むサービス情報などの種々の情報を取得するように構成されてもよい。
【0026】
制御部114は、中央演算ユニット(CPU)などの演算装置を有し、記憶部122から必要なプログラムを読み出して実行してアロケーションサーバ112の全体を制御するとともに、学習モデルに従って演算処理を行う。制御部114は、その主な機能を果たすユニットとして、需要予測部116、調整部118、およびユーザ管理部120に分割することができる。なお、制御部114は必ずしもアロケーションサーバ112の機能に従って複数のユニットから構成されなくてもよく、一つの制御部114で各種機能を果たすように構成してもよい。
【0027】
(3)ユーザ端末
ユーザ端末102は、ユーザ100によって利用または管理され、通信機能と計算機能を有する通信端末である。ユーザ端末102としては、公知の通信端末を利用することができる。ユーザ端末102は、例えばノート型、または据え置き型のコンピュータでもよく、あるいはスマートフォンやタブレットコンピュータ、ヘッドマウント型の携帯型通信端末でもよい。
【0028】
3.配送方法
以下、本配送方法を詳細に説明する。
【0029】
(1)商品の発注と配送依頼
図3Aのスキームに示すように、まず、ユーザ100は、店舗180に商品を発注し、ユーザが予めまたは発注時に指定する宅配ボックス190(以下、ユーザ100が指定する宅配ボックスを指定宅配ボックスと記す。)への配送を依頼する。この時、ユーザ100は店舗180に口頭やファックスで商品発注と配送を依頼してもよく、ユーザ端末102を利用して商品発注と配送を依頼してもよい。後者の場合、ユーザ100は、ユーザ端末102を用いて店舗180またはプラットフォーム提供事業者160が構築するプラットフォームにアクセスし、当該プラットフォーム上で店舗180に商品の発注と配送を依頼する。また、ユーザ100は、商品の配送希望日時を直接またはプラットフォーム上で店舗180に通知してもよい。店舗180によって商品の注文が確認されて注文が受諾されると、商品の発注が確定する。なお、ユーザ100は、予めまたは商品の発注時に指定宅配ボックス以外の宅配ボックス190を代替宅配ボックスとして指定してもよい。あるいは、指定宅配ボックス以外の物理的空間を配送先として指定してもよい。物理的空間としては、ショッピングモール(例えばショッピングモール内のサービスカウンター)、スーパーマーケットまたはデパートなどの総合小売店、書店、コンビニエンスストア、新聞配達所だけでなく、パチンコ店やゲームセンターなどのアミューズメント施設でもよい。
【0030】
その後、店舗180は、店舗サーバ182を用い、直接またはプラットフォーム提供事業者160を介して商品を含む荷物の配送を配送事業者170に依頼する。すなわち、店舗サーバ182から配送依頼信号が配送管理サーバ172に送信される。配送依頼信号には、荷物に関する情報(荷物情報)が含まれる。荷物情報としては、商品の名称、カテゴリ、数量、大きさ、管理方法(例えば、冷蔵保存または冷凍保存の要否など)、ユーザ100が希望する配送日時(配送希望日時)などが挙げられる。荷物情報には、指定宅配ボックスや代替宅配ボックスのボックスIDが含まれてもよい。また、荷物情報にはユーザ100に関する情報(住所、氏名、電話番号など)を含ませてもよいが、指定宅配ボックスや代替宅配ボックスのボックスIDが含まれている場合には、配送先が確定されているため、ユーザ100に関する情報を荷物情報に含ませなくてもよい。ユーザ100に関する情報を荷物情報に含ませないことで、当該情報の漏洩を予防することができる。
【0031】
(2)ロッカーの割り当てと配送
配送を依頼された配送事業者170は、アロケーション事業者110に対し、ロッカーの割り当てを要求する。具体的には、配送管理サーバ172を用いてアロケーションサーバ112にアクセスし、アロケーションサーバ112に対してロッカー割当要求信号を送信する。ロッカー割当要求信号には、荷物情報が含まれ、さらに配送事業者170が決定する配送予定日時が含まれてもよい。荷物情報にボックスIDが含まれていない場合には、ユーザ100が指定する宅配ボックス190のボックスIDをユーザ100の住所から配送管理サーバ172上で割り出し、ボックスIDをロッカー割当要求信号に含ませればよい。
【0032】
アロケーションサーバ112は、定期的またはロッカー割当要求を受け取る度に指定宅配ボックスまたはボックス管理サーバ152にアクセスし、指定宅配ボックスのロッカー情報を取得する。アロケーション事業者110は、取得したロッカー情報と荷物情報に基づき、利用可能なロッカーの中から当該荷物の収容に最適なロッカーを選択する。ロッカーの選択では、荷物の大きさに適合したロッカーを選択することが好ましい。例えば、荷物の体積がロッカーの容積の75%以上100%以下、80%以上100%以下、90%以上100%以下、または95%以上100%以下となるようにロッカーを選択する。また、一人のユーザ100に対して複数の荷物が配送される場合には、複数の荷物が同梱可能なロッカーを選択してもよい。あるいは、荷物の管理方法に従ってロッカーを選択してもよい。例えば、冷蔵保存が要求される荷物の場合には、冷蔵機能が設けられたロッカーを選択してもよい。
【0033】
ロッカーが選択されると、アロケーション事業者110は、アロケーションサーバ112を用いて配送事業者170の配送管理サーバ172に対し、選択されたロッカーのロッカーIDを含むロッカー割当信号を送信する。これにより、配送事業者170は、荷物の配送前に指定宅配ボックスのロッカーを確保することができるため、配送時にロッカーが不足する状況が発生せず、荷物を確実にロッカーに収容することができる。このため、荷物の再配送という負担が強いられることがない。
【0034】
荷物が配送された後には、ユーザ100のユーザ端末102に対し、荷物の配送が完了したことを通知するための信号を配送管理サーバ172および/またはアロケーションサーバ112から送信してもよい。また、荷物の配送完了後一定期間(例えば24時間、2日、3日など)が経過してもユーザ100が荷物を取り出さない場合には、荷物を取り出すための催促通知を配送管理サーバ172および/またはアロケーションサーバ112からユーザ端末102に送信してもよい。
【0035】
(3)需要予測
上述したように、配送事業者170からのロッカー割当要求に従ってアロケーション事業者110は指定宅配ボックスから利用可能なロッカーを選択するが、その際、必ずしも利用可能なロッカーが存在しているとは限らない。利用可能なロッカーが存在しない場合にはロッカーの割り当てができないため、配送日時を確定することができず、ユーザ100に対して、配送日時を通知することもできない。そこで、このような事態を避けるため、本配送方法では、アロケーション事業者110によって各宅配ボックス190の需要予測が行われ、配送される荷物の総数が宅配ボックス190の容量を超えないように配送調整が行われる。需要予測は定期的に行ってもよく、ロッカー割当要求を受け取る度に行ってもよい。
【0036】
需要予測は、アロケーションサーバ112の制御部114または制御部114に設けられる需要予測部116により行われ、一定期間ごと(例えば、日にちごと、週ごと、二週ごと、月ごと)に配送される荷物の総数が予測される。例えば、需要予測は、教師あり学習モデルを用いてを行うことができる。教師あり学習モデルによる需要予測では、各宅配ボックス190に備えられる複数のロッカーの過去の利用実績が教師データとして利用される。過去の利用実績とは、例えば各宅配ボックス190について、過去の一定期間(例えば1年、半年、3か月など)に遡り、一定時間(例えば、1日、半日)ごとに現実に収容された荷物の総数である。教師データは宅配ボックス190ごとに収集され、記憶部122に格納される。
【0037】
教師あり学習モデルの構築では、種々のパラメータをインプットデータ(特徴量データ)として利用することができる。特徴量データを纏めたテーブルの一例を図4に示す。特徴量データは、ロッカーを特定するボックスIDとロッカーIDに紐付けされる。特徴量データとしては、荷物に含まれる商品が発注された店舗を特定する店舗識別子(店舗ID)、商品を特定する識別子(商品ID)とカテゴリ、荷物の大きさや個数、荷物がロッカーに滞在した時間、荷物を配送した配送事業者を特定する識別子(配送事業者ID)、商品を発注した日時や曜日などが挙げられる。その他、商品を発注した際に店舗180またはプラットフォーム提供事業者160が提供する特典がユーザ100によって利用されたか否かなども特徴量データとして利用してもよい。図4には示されていないが、暦(祝日か否か、祝日の曜日、連休の有無や連休中の休日の数など)、大規模行事(オリンピック、ワールドカップなど)の有無、天候なども特徴量データとして用いてもよい。特徴量データも宅配ボックス190ごとに収集され、記憶部122に格納される。
【0038】
教師あり学習モデルで用いるアルゴリズムは任意に選択することができ、例えば、機械学習アルゴリズムを使用することができる。機械学習アルゴリズムとしては、線形回帰モデル、ランダムフォレスト、決定木、勾配ブースティング、深層学習(ディープラーニング)などが挙げられ、特に深層学習が好ましい。深層学習を用いる場合には、ニューラルネットワーク、ディープニューラルネットワーク、畳み込みニューラルネットワークなどのアルゴリズムを適宜用いればよい。機械学習アルゴリズムを用いて各宅配ボックス190の需要予測を行うことで、一定期間に宅配ボックス190に収容される荷物の総数を予測することができる。予測された荷物の総数と過去の利用実績である教師データの差分が目的関数であり、この目的関数を最小化することで学習モデルを学習、更新させることができる。
【0039】
(4)需要予測に基づくユーザに対するプロモーション
需要予測により、荷物の総数が宅配ボックス190の容量を超えない場合には、上述した手順に従って荷物の配送を行えばよい。しかしながら、図5Aに示すように、需要予測に基づく荷物総数が宅配ボックス190の容量を超える繁忙期間が到来すると予想される場合、需要予測の精度にも依存するものの、荷物の配送調整を実施しないと荷物総数が現実に宅配ボックス190の容量を超えるおそれがある(図5Aの鎖線参照。)。このような事態が発生すると、ロッカーの割り当てができなくなり、配送日時を迅速にユーザ100に通知することができなくなり、配送業務の停滞とユーザ満足度の低下を招く。
【0040】
したがって、本配送方法では、繁忙期間の到来が予想される場合、当該宅配ボックス190を利用するユーザ100の一部または全てに対し、アロケーション事業者110によって配送調整のためのプロモーションが行われる(図3A参照。)。具体的には、図6のフローチャートに示すように、商品発注が確定すると、上述した需要予測に基づき、配送日時(すなわち、配送希望日時または配送予定日時)が繁忙期間にあるか否かをアロケーションサーバ112上で判断する。配送日時が繁忙期間に無い場合には、上述した手順に従ってロッカーが各荷物に割り当てられ、これに従って配送事業者170が指定宅配ボックスへ荷物を配送すればよい。
【0041】
一方、配送日時が繁忙期間に当たる場合、アロケーション事業者110は、当該宅配ボックス190を利用する一人または複数のユーザ100を選択し、プロモーションを行う。すなわち、配送日時および/または配送先の変更を依頼する。ユーザ100の選択は、アロケーションサーバ112の制御部114または制御部114に設けられる調整部118によって行われる。選択されるユーザ100は、当該商品を発注したユーザ100でもよく、商品の発注が既に確定したものの配送日時が確定していないユーザ100でもよく、配送日時が既に確定したユーザ100でもよい。
【0042】
ユーザ100の選択は、配送日時が当該繁忙期間に当たるユーザ100からランダム(任意)に選択してもよいが、ユーザ100によるプロモーション受諾を円滑に得るため、ユーザパラメータを利用して行うことが好ましい。ユーザパラメータは、各ユーザ100の識別子(ユーザID)に関連付けられる種々のパラメータとしてアロケーションサーバ112の記憶部122に格納される。ユーザパラメータに含まれるパラメータの一例を図7中の表に纏める。図7に示すように、ユーザパラメータとしては、ユーザの区分または属性(例えば、単身者であるか、一般世帯であるか)、過去の商品発注日時や荷物の配送日時および曜日、配送を希望した時間帯、荷物をロッカーから取り出した日時や曜日、ロッカー内に荷物を滞在させた時間、戸別配送を過去に希望したものの荷物配送時に不在であったか否か(不在実績)、不在実績の頻度、住居の種別(戸建て住宅か集合住宅かなど)、集合住宅の場合には居住階などが挙げられるが、これらに限られない。さらに、ユーザの挙動、具体的には、過去にアロケーション事業者110からのプロモーションを受けた回数や、プロモーションを受諾した頻度(変更受諾回数/変更依頼回数)などもユーザパラメータとして利用することができる。
【0043】
ユーザ100の選択は、例えば、一つのユーザパラメータ(例えば、プロモーションを受諾した頻度、居住階など)に注目し、その順に従ってユーザ100を選択してもよい。例えばプロモーションを受諾した頻度は、ユーザが協力的であるか否かの指標となる。また、ユーザが低層階に居住している場合には、配送日時や配送先の変更が大きな負担とならないため、プロモーションを受諾する確率が高いと言える。
【0044】
あるいは、より効率の良い選択のため、教師あり学習モデルを利用し、プロモーションを受諾する可能性がより高いユーザ100を選択してもよい。すなわち、上述した複数のユーザパラメータを特徴量として用い、機械学習アルゴリズムなどのアルゴリズムを用いてプロモーションを受諾する頻度を予測する。教師データであるユーザ100が過去にプロモーションを受諾した頻度と予測結果との差分である目的関数を最小化することで、学習モデルが構築、更新される。
【0045】
プロモーションを行うユーザ100(以下、第1のユーザと記す。)が選択されると、アロケーション事業者110は、第1のユーザに対してプロモーションを行う(図6)。すなわち、プロモーションするための変更依頼信号をアロケーションサーバ112から第1のユーザのユーザ端末102に送信する。配送日時の変更を依頼する場合には、例えば、配送希望日時および/または配送予定日が需要予測で算出される荷物総数のピーク時よりも前であれば、配送の前倒しを依頼する。逆に、配送希望日時および/または配送予定日時が荷物総数のピーク時よりも後であれば、配送の先送りを依頼する。第1のユーザが配送希望日時を指定していない場合も同様であり、配送の前倒しまたは先送りを配送予定日時と荷物総数のピーク時との関係に応じて第1のユーザにプロモーションを行えばよい。あるいは、配送希望日時や配送予定日時が荷物総数のピーク時の前であるか後ろであるかに関わりなく、一律に前倒しまたは先送りを依頼してもよい。あるいは、需要予測に基づき、荷物に適したロッカーが利用可能になると予想される日時を変更後の配送日時として設定してもよい。
【0046】
あるいは、指定宅配ボックスの繁忙期間において荷物総数が容量を超えない他の宅配ボックス190が存在する場合には、第1のユーザに対して代替宅配ボックスを荷物の配送先として変更することを依頼してもよい。あるいは、第1のユーザが代替宅配ボックスを指定していない場合には、第1のユーザが指定した指定宅配ボックスからの距離が小さい順に代替宅配ボックスを選択してもよく、あるいは、第1のユーザの住所に近い駅や施設に設置された宅配ボックス190から優先的に代替宅配ボックスをアロケーションサーバ112上で選択してもよい。
【0047】
(5)ユーザによる応答
プロモーションを受けた第1のユーザは、プロモーションを受諾または拒否することができる。具体的には、第1のユーザは、変更依頼信号を受信した後、ユーザ端末102を用い、アロケーションサーバ112に対してプロモーションを受諾するまたは拒否することを通知するための応答信号を送信すればよい。
【0048】
第1のユーザがプロモーションを受諾し、プロモーションを受諾することを通知する応答信号をアロケーションサーバ112が受信すると、変更後の配送日時および/または変更された宅配ボックス190のボックスID、およびアロケーションサーバ112によって割り当てられたロッカーのロッカーIDを含むロッカー割当信号がアロケーションサーバ112によって生成され、配送事業者170の配送管理サーバ172に送信される。これにより、荷物配送のための宅配ボックス190とそのロッカーが確保される。その後、配送事業者170は変更後の配送日時に、または変更後の宅配ボックス190に荷物を配送する。
【0049】
第1のユーザがプロモーションを受諾した場合には、アロケーション事業者110は、プロモーションを受諾した第1のユーザに対してインセンティブを提供してもよい(図6)。インセンティブの提供は、荷物の配送後に行ってもよく、配送前に行ってもよい。インセンティブの提供は、アロケーションサーバ112の制御部114または制御部114に設けられるユーザ管理部120によって行うことができる。インセンティブの内容は任意であり、アロケーション事業者110を利用する手数料の割引、配送料の割引、アロケーション事業者110を利用する際に付加されるポイントの割増などが挙げられる。あるいは、より使用しやすいロッカー(例えば、より操作しやすい位置にあるロッカー)を優先的に割り当てるというサービスをインセンティブとして提供してもよい。インセンティブが付与されると、その報告を第1のユーザに通知するためのインセンティブ通知信号をアロケーションサーバ112から第1のユーザのユーザ端末102へ送信してもよい。
【0050】
一方、第1のユーザがプロモーションを拒否した場合には、配送日時が当該繁忙期間に当たる他のユーザ100(以下、第2のユーザと記す。)を選択し、プロモーションを行ってもよい(図6)。第2のユーザの選択やプロモーション方法は、第1のユーザのそれと同様である。また、第2のユーザの荷物の配送や第2のユーザに対するインセンティブの提供も第1のユーザのそれと同様であるため、説明は割愛する。
【0051】
また、第2のユーザもプロモーションを拒否した場合には、引き続き、第3、第4のユーザを選択してプロモーションを行ってもよい。なお、選択したユーザのいずれもがプロモーションを拒否した場合には、配送日時が確定していないユーザ100の荷物の配送日時を、宅配ボックス190のロッカーが利用可能になった時以降に設定すればよい。
【0052】
このように、各宅配ボックス190の需要を予測し、配送される荷物総数が宅配ボックス190の容量を超えないように配送調整することで、図5Bの鎖線で示されるように、配送される荷物数が平準化され、配送事業者170の業務負担の平準化が可能となる。また、荷物を収容するロッカーを配送前に確実に確保することができるため、再配送に必要なコストや人的資源の大幅な節約を達成することができる。
【0053】
また、プロモーションを行うユーザの選択においてユーザパラメータを使用することで、より円滑にプロモーションの受諾を得ることができる。例えば、荷物の収容後速やかに荷物を取り出す傾向にあるユーザ100(すなわち、荷物の滞在時間の短いユーザ100)や、過去にプロモーションを受諾した頻度の高いユーザ100などを優先的に選択してプロモーションを行う。これにより、プロモーションが拒否される頻度が低減し、配送調整を迅速に行うことができるので、より効率良く宅配ボックスを利用することができる。
【0054】
なお、配送調整が困難または不可能な場合、例えば、繁忙期が長期に亘るために配送日時の大幅な変更が必要な場合や、適切な宅配ボックス190またはロッカーが長期間に亘って確保できない場合などには、上述した物理的空間を配送先として割り当ててもよい。
【0055】
4.配送方法の変形例
上述した例では、荷物の配送は配送事業者170に依頼する。しかしながら、本配送方法では、図3Bに示すように、配送依頼を直接アロケーション事業者110に対して行ってもよい。この場合、店舗サーバ182上で構築されるプラットフォームまたはプラットフォームサーバ162上で構築されるプラットフォームを介し、配送依頼を行うための配送依頼信号が店舗サーバ182からアロケーションサーバ112に送信される。また、ロッカーが確保されると、割り当てられたロッカーのロッカーIDとともに荷物の配送依頼がアロケーションサーバ112から配送管理サーバ172へ送信される。
【0056】
あるいは、配送主体が店舗180である場合でも本配送方法を適用することができる。具体的には、図3Cに示すように、店舗180がアロケーション事業者110に対してロッカーの割り当てを依頼する。すなわち、店舗サーバ182から直接またはプラットフォームサーバ162のプラットフォームを介し、アロケーションサーバ112にロッカー割当要求信号が送信される。ロッカー割当要求信号を受信すると、アロケーションサーバ112は、宅配ボックス190またはボックス管理サーバ152から取得したロッカー情報に基づいてロッカーを選択し、選択されたロッカーのロッカーIDを店舗サーバ182に送信する。配送を担う店舗180は、ロッカーIDに従い、割り当てられたロッカーに荷物を収容すればよい。
【0057】
5.信号の授受
本配送方法に従って荷物を配送する際に各構成間で行われる信号の授受を図8から図10のフローチャートを用いて説明する。以下の説明では、ユーザ100が店舗サーバ182上で商品を発注する例を中心に説明を行うが、商品の発注は店舗180との対面商取引で行ってもよく、プラットフォームサーバ162上で行ってもよい。プラットフォームサーバ162上で商品を発注する場合には、店舗サーバ182をプラットフォームサーバ162に置き換えればよい。
【0058】
(1)配送事業者が配送を担う場合
配送事業者170が配送を担う場合、すなわち、配送事業者170とアロケーション事業者110が独立した事業者である場合のフローチャートを図8に示す。まず、ユーザ100が商品を発注する。具体的には、ユーザ端末102から店舗サーバ182に対し、商品を発注するための信号を送信する(S100)。この後、店舗サーバ182はユーザ端末102に対し、発注の確認のための信号を送信してもよい(S102)。
【0059】
この後、店舗サーバ182から荷物の配送依頼信号が配送管理サーバ172に送信される(S104)。図示しないが、配送依頼信号の受信確認のための信号を配送管理サーバ172から店舗サーバ182に送信してもよい。
【0060】
この後、配送管理サーバ172からロッカー割当要求信号がアロケーションサーバ112に送信される(S106)。図示しないが、ロッカー割当要求信号の受信確認のための信号をアロケーションサーバ112から配送管理サーバ172に送信してもよい。
【0061】
上述したように、各宅配ボックス190は、定期的に、ボックス管理サーバ152からの要求に応じて、または宅配ボックス190に設けられるセンサの動作に応答してロッカー情報をボックス管理サーバ152に送信する(S108)。アロケーションサーバ112は、ボックス管理サーバ152に対してロッカー情報を送信するためのロッカー情報要求信号を送信する(S110)。ロッカー情報要求信号には、指定宅配ボックスや代替宅配ボックスのボックスIDが含まれる。ボックス管理サーバ152は、ロッカー情報要求信号に応答し、指定宅配ボックスや代替宅配ボックスのロッカー情報をアロケーションサーバ112に送信する(S112)。なお、上述したように、ロッカー情報は、定期的にボックス管理サーバ152からアロケーションサーバ112に送信してもよい。この場合には、アロケーションサーバ112はロッカー情報要求信号をボックス管理サーバ152に送信しなくてもよい。
【0062】
図示しないが、アロケーションサーバ112による需要予測から、荷物の配送希望日時または配送予定日時が繁忙期間に該当しない場合には、取得したロッカー情報に基づいてロッカー割当信号を配送管理サーバ172に送信する。配送事業者170は、ロッカー割当信号に含まれるロッカーIDに対応するロッカーに荷物を配送すればよい。
【0063】
一方、荷物の配送希望日時または配送予定日時が繁忙期間に該当する場合、アロケーションサーバ112上でプロモーションを行うユーザ100を選択する。図8に示す例では、当該商品を発注したユーザ100が選択される。この場合、アロケーションサーバ112からユーザ端末102に対し、配送日時または配送先の変更を依頼するための変更依頼信号を送信する(S114)。プロモーションを受けたユーザ100は、プロモーションを受諾するまたは拒否することを通知するための信号(応答信号)をユーザ端末102からアロケーションサーバ112へ送信する(S116)。ユーザ100がプロモーションを受諾すると、変更後の配送日時および/または変更後の配送先である代替宅配ボックスのボックスIDとロッカーIDを含むロッカー割当信号がアロケーションサーバ112から配送管理サーバ172に送信される(S118)。これにより、当該配送日時において荷物を配送するためのロッカーが確実に確保され、配送事業者170は、このロッカー割当信号に含まれる情報に従って荷物を配送することができる。配送管理サーバ172は、変更後の配送日時および/または配送先を通知するための信号をユーザ端末102に送信してもよい(S120)。この信号は、アロケーションサーバ112からユーザ端末102に送信してもよい。
【0064】
配送が完了した後、配送管理サーバ172からユーザ端末102に対し、荷物の配送が完了したことを通知するための配送通知信号が送信される(S122)。あるいは、配送通知信号を配送管理サーバ172からアロケーションサーバ112へ送信し、その後アロケーションサーバ112からユーザ端末102に送信してもよい。これにより、アロケーションサーバ112上で実際の配送日時が把握される。なお、荷物が配送されると、宅配ボックス190に設置されたセンサが検知する信号に基づいてロッカー情報が宅配ボックス190からボックス管理サーバ152に送信され(S124)、さらにアロケーションサーバ112に送信される(S126)。したがって、ロッカー情報を利用してもアロケーションサーバ112上で荷物が実際に配送された日時やユーザ100によって荷物が取り出された日時を把握することができる。アロケーションサーバ112は、これらの情報をユーザパラメータとして記憶部122に格納し、プロモーションを行うユーザの選択に利用することができる。
【0065】
図示しないが、荷物の滞在時間が所定時間を経過すると、アロケーションサーバ112からユーザ端末102へ催促通知を送信してもよい。また、インセンティブ通知信号をアロケーションサーバ112からユーザ端末102へ送信してもよい。インセンティブ通知信号を送信するタイミングは任意であり、プロモーションを受諾したユーザ100のユーザ端末102から応答信号を受信した後に適宜送信すればよい。
【0066】
上述したように、プロモーションを行うユーザは、必ずしも当該商品を発注したユーザ100に限られない。例えば、ある商品を発注した第1のユーザとは異なり、商品の発注が既に確定したものの配送予定日時が確定していない、あるいは配送予定日時が既に確定した第2のユーザに対してプロモーションを行ってもよい。また、あるユーザ(例えば第1のユーザ)にプロモーションを行ったもののプロモーションが拒否された場合には、当該ユーザとは異なる第2のユーザにプロモーションを行うことがある。これらの場合には、第1のユーザの第1のユーザ端末102-1に変更依頼信号を送信すること無く、あるいは、第1のユーザの第1のユーザ端末102-1からプロモーションを拒否する応答信号を受信した後(S116)、アロケーションサーバ112から第2のユーザの第2のユーザ端末102-2に対して変更依頼信号が送信される(S130)(図9参照。)。その応答信号が第2のユーザ端末102-2からアロケーションサーバ112に送信される(S132)。
【0067】
なお、荷物の配送先として宅配ボックス190以外の物理的空間が割り当てられる場合には、その物理的空間を管理する主体が有する通信端末から配送通知信号がユーザ端末102へ送信される。
【0068】
(2)アロケーション事業者が配送を担う場合
上述したように、本配送方法では、アロケーション事業者110が荷物の配送を担うことができる。換言すると、配送事業者170がアロケーション事業を担ってもよい。この場合には、図10に示すように、配送依頼信号は店舗サーバ182からアロケーションサーバ112へ送信され(S140)、その受信確認が店舗サーバ182へ送信される(S142)。また、配送通知信号もアロケーションサーバ112からユーザ端末102へ送信される(S144)。これら以外の信号の授受は配送事業者170とアロケーション事業者110が独立した事業者である場合と同様であるため、説明は割愛する。
【0069】
以上述べたように、本配送方法では、配送事業者170から依頼を受けたアロケーション事業者110が指定宅配ボックスからロッカーを割り当てるだけでなく、宅配ボックス190の需要予測に基づき、当該指定宅配ボックスを利用するユーザ100から一人または複数を選択し、選択されたユーザ100に対し、配送日時または配送先の変更のためのプロモーションを行う。また、ユーザの選択では、ユーザの過去の挙動を含むユーザパラメータ(荷物の滞在時間、不在実績の頻度など)が利用されるため、ユーザに対してプロモーションを受諾する動機を提供することができる。その結果、宅配ボックス190の容量が不足する事態が想定される場合に適切な配送調整を行うことができ、宅配ボックス190のロッカーが全て利用されているために再配送を余儀なくされるという事態を回避することができる。このことは、配送人の負担と配送コストを大幅な低減に寄与する。
【0070】
本発明の実施形態として上述した各実施形態は、相互に矛盾しない限りにおいて、適宜組み合わせて実施することができる。また、各実施形態の表示装置を基にして、当事業者が適宜構成要素の追加、削除もしくは設計変更を行ったもの、又は、工程の追加、省略もしくは条件変更を行ったものも、本発明の要旨を備えている限り、本発明の範囲に含まれる。
【0071】
上述した各実施形態の態様によりもたらされる作用効果とは異なる他の作用効果であっても、本明細書の記載から明らかなもの、又は、当事業者において容易に予測し得るものについては、当然に本発明によりもたらされるものと解される。
【符号の説明】
【0072】
100:ユーザ、102:ユーザ端末、102-1:第1のユーザ端末、102-2:第2のユーザ端末、104:通信ネットワーク、110:アロケーション事業者、112:アロケーションサーバ、114:制御部、116:需要予測部、118:調整部、120:ユーザ管理部、122:記憶部、124:通信部、126:入力部、128:出力部、150:ボックス管理事業者、152:ボックス管理サーバ、160:プラットフォーム提供事業者、162:プラットフォームサーバ、170:配送事業者、172:配送管理サーバ、180:店舗、182:店舗サーバ、190:宅配ボックス、200:配送システム
図1A
図1B
図2
図3A
図3B
図3C
図4
図5A
図5B
図6
図7
図8
図9
図10
【手続補正書】
【提出日】2023-01-13
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
第1の宅配ボックスに配送される荷物の総数を、前記第1の宅配ボックスに備えられる複数のロッカーの過去の利用実績を教師データとして利用する教師あり学習モデルを用いてアロケーションサーバにおいて予測すること、
予測された前記総数が前記第1の宅配ボックスの容量を超える期間が存在する場合、前記期間における前記荷物の配送先として前記第1の宅配ボックスを指定した複数のユーザから一人を第1のユーザとして前記アロケーションサーバによって選択すること、
前記第1のユーザの通信端末に対し、前記荷物の配送日時の変更、または前記荷物の前記配送先として第2の宅配ボックスへの変更を依頼するための変更依頼信号を前記アロケーションサーバから送信すること、および、
前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を前記アロケーションサーバで受信することを含む、荷物の配送方法。
【請求項2】
前記総数の前記予測は、過去に前記第1の宅配ボックスに配送された荷物のカテゴリ、大きさ、および前記荷物を構成する商品を発注した日時と曜日、ならびに前記商品の発注時に前記商品に係る特典が前記複数のユーザによって利用されたか否か、の少なくとも一つを特徴量として用いる教師あり学習モデルによって行われる、請求項1に記載の配送方法。
【請求項3】
前記第1の宅配ボックスを管理するボックス管理サーバから送信される、前記第1の宅配ボックスに設けられる複数のロッカーの使用状況を含むロッカー情報信号を、前記アロケーションサーバで受信することをさらに含む、請求項1に記載の配送方法。
【請求項4】
前記複数のユーザから前記第1のユーザと異なる第2のユーザをアロケーションサーバによって選択すること、
前記第2のユーザの通信端末に対し、前記変更依頼信号を前記アロケーションサーバから送信すること、および
前記第2のユーザの前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を、前記アロケーションサーバで受信することをさらに含む、請求項1に記載の配送方法。
【請求項5】
前記第1のユーザの前記選択は、前記アロケーションサーバに格納されたユーザパラメータに基づいて行われ、
前記ユーザパラメータは、
前記第1のユーザが過去に発注した荷物の前記第1の宅配ボックス内における滞在時間、
前記第1のユーザが過去に前記依頼を受諾した頻度、
前記第1のユーザの属性、
前記第1のユーザの住居種別、および
前記第1のユーザの居住階の少なくとも一つを含む、請求項1に記載の配送方法。
【請求項6】
前記依頼を受諾した前記第1のユーザの前記通信端末に対し、前記第1のユーザにインセンティブを付与したことを通知するためのインセンティブ通知信号を前記アロケーションサーバから送信することをさらに含む、請求項1に記載の配送方法。
【請求項7】
第1の宅配ボックスに配送される荷物の総数を、前記第1の宅配ボックスに備えられる複数のロッカーの過去の利用実績を教師データとして利用する教師あり学習モデルを用いて予測し、
予測された前記総数が前記第1の宅配ボックスの容量を超える期間が存在する場合、前記期間における荷物の配送先として前記第1の宅配ボックスを指定した複数のユーザから一人を第1のユーザとして選択し、
前記第1のユーザの通信端末に対し、前記荷物の配送日時の変更、または前記荷物の前記配送先として第2の宅配ボックスへの変更を依頼するための変更依頼信号を送信し、
前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を受信するように構成される、サーバ。
【請求項8】
前記総数の前記予測は、過去に前記第1の宅配ボックスに配送された荷物のカテゴリ、大きさ、および前記荷物を構成する商品を発注した日時と曜日、ならびに前記商品の発注時に前記商品に係る特典が前記複数のユーザによって利用されたか否か、の少なくとも一つを特徴量として用いる教師あり学習モデルによって行われる、請求項7に記載のサーバ。
【請求項9】
前記第1の宅配ボックスを管理するボックス管理サーバから送信される、前記第1の宅配ボックスに設けられる複数のロッカーの使用状況を含むロッカー情報信号を受信するようにさらに構成される、請求項7に記載のサーバ。
【請求項10】
前記複数のユーザから前記第1のユーザと異なる第2のユーザを選択し、
前記第2のユーザの通信端末に対して前記変更依頼信号を送信し、
前記第2のユーザの前記通信端末から送信される、前記変更を受諾するまたは拒否する応答信号を受信するようにさらに構成される、請求項7に記載のサーバ。
【請求項11】
前記第1のユーザの前記選択は、前記サーバに格納されたユーザパラメータに基づいて行われ、
前記ユーザパラメータは、
前記第1のユーザが過去に発注した荷物の前記第1の宅配ボックス内における滞在時間、
前記第1のユーザが過去に前記依頼を受諾した頻度、
前記第1のユーザの属性、
前記第1のユーザの住居種別、および
前記第1のユーザの居住階の少なくとも一つを含む、請求項7に記載のサーバ。
【請求項12】
前記依頼を受諾した前記第1のユーザの前記通信端末に対し、前記第1のユーザにインセンティブを付与したことを通知するためのインセンティブ通知信号を送信するようにさらに構成される、請求項7に記載のサーバ。