JP2021510868A - モジュラーキャンプ分類及び動的積み込みレイアウト生成のためのシステムおよび方法 - Google Patents

Abstract

荷物の分類および積み込みを最適化するためのコンピュータ実装システムおよび方法が開示される。例示的なシステムは命令を記憶するメモリを含み、命令を実行するように構成された少なくとも１つのプロセッサを含んでもよい。システムは、複数の荷物に関連付けられた複数の荷物識別子を含むデータを受信することを含む動作を実行してもよい。動作は、複数の荷物の配送位置に関連付けられた複数のブロックエリアを決定することを含んでもよい。動作は、ルートの第１のセットを決定すること、ルートの各セットに対する入力の最適な組み合わせを決定すること、および最適な組み合わせに関連する最短ルートを決定することによって、配送ルートを決定することをさらに含んでもよい。動作は、荷物の各々を配送車に積み込む順序を決定することを含んでもよい。動作は、デバイスに積載順序の視覚的表現を表示させるための命令を生成することをさらに含んでもよい。

Description

本発明は一般に、荷物を分類および積み込むためのコンピュータ化されたシステムおよび方法に関する。具体的には、本発明の実施形態が１つまたは複数のカスタマ注文に関するデータに基づいて、複数の荷物の積載順序を決定し、積載順序の視覚的表現を生成し、積載順序に関するデータを、視覚的表現をディスプレイするように構成された１つまたは複数のデバイスに送信するための、発明的かつ非従来型のシステムに関する。

荷物配送のための多数のコンピュータ化されたシステムが存在する。これらのシステムは例えば、どの配送作業員が荷物を配送するかを決定し、荷物配送のためのルートを生成し、配送ルートおよび荷物を配送作業員に通信するバックエンドシステムなどを含む。

これらのバックエンドシステムはトラック内のどこに荷物を配置するかについてのさらなる案内なしに、トラック内に特定の荷物を配置するように作業員に単に指示するという点で問題がある。これは、作業員が全ての荷物に適合するためにトラックをパックし、再パックする必要があるため、遅延をもたらす。これはまた、荷物の喪失につながる可能性がある。
システムはまた、携帯電話または携帯情報端末（ＰＤＡ）などの配送作業員デバイスを含むことができる。配送作業員が荷物を配送しているとき、これらのデバイスは配送作業員に、荷物をどこに配送するかを通知し、配送作業員が配送トラックの後ろにある荷物を見つけることができるようにするための情報（バーコードなど）を提供する。しかしながら、これらのデバイスは住所のような情報を提供し、配送作業員がそれぞれの配送位置で配送する正しい荷物を見つけるために、数百ではないにしても、数十の荷物を掘ることを要求するという点で、基本的なものである。これは、配送車を事前に梱包する方法を知るために配送作業員に頼ることを必要とし、非効率性を引き起こす。

したがって、荷物を分類し、梱包し、配送するための改良された電子的方法およびシステムが必要とされている。

本発明による実施形態は、荷物の分類および積み込みを最適化するためのコンピュータ化された方法およびシステムを提供する。実施形態は、最適化された分類または積み込み決定の視覚的表現を提供するための方法およびシステムを含むことができる。

いくつかの実施形態では、コンピュータ実装システムが配送車の最適な仕分けおよび積載順序を決定するように構成されてもよい。システムは、メモリ記憶命令を含むことができる。システムは本開示と矛盾しない１つ以上の動作を実行するために、記憶された命令を実行するように構成された少なくとも１つのプロセッサをさらに含んでもよい。プロセッサは、複数の荷物に関連する複数の荷物識別子を含むデータを受信してもよい。プロセッサは、複数の荷物の配送位置に関連付けられた複数のブロックエリアを決定することができる。複数のブロックエリアは、受信されたデータに基づいて決定されてもよい。プロセッサは、配送ルートを決定するように構成してもよい。配送ルートは、複数の荷物を配送するための順序を含んでもよい。プロセッサはルートの第１のセットを決定し、ルートの第１のセットを変換して、ルートの第１のセットの各々に対する入力の最適な組合せを決定することによって、配送ルートを決定することができる。プロセッサはさらに、変換されたルートに関連するブロックエリアを交換することによって、最短ルートを決定してもよい。プロセッサは、積載順序を決定するようにさらに構成されてもよい。積載順序は、複数の荷物の各々の荷物を配送車に積み込む順序を含んでもよい。順序は、決定された配送ルートに基づくものであってもよい。プロセッサは、デバイスが積載順序の視覚的表現を表示するための命令を生成するようにさらに構成されてもよい。

いくつかの実施形態では、コンピュータ実装方法が複数の荷物の分類および積み込みを最適化するように構成されてもよい。該方法は、複数の荷物に関連付けられた複数の荷物識別子を含むデータを受信することを含んでもよい。該方法は、複数の荷物の配送位置に関連付けられた複数のブロックエリアを決定するステップをさらに含んでもよい。ブロックエリアは、受信されたデータに基づいて決定されてもよい。該方法は、複数の荷物を配送するための順序を含む配送ルートを決定することをさらに含んでもよい。配送ルートはルートの第１のセットを決定し、ルートの第１のセットを変換して、ルートの第１のセットの各々に対する入力の最適な組合せを決定することによって決定されてもよい。変換されたルートは、各々の変換されたルートに関連付けられたブロックエリアの順序を交換することによって、複数の荷物を配送するための最短ルートを決定するために使用されてもよい。該方法は、配送ルートに基づいて、複数の荷物の各々を配送車に積載する積載順序を決定するステップをさらに含んでもよい。本方法は、決定された積載順序の視覚的表現を表示するためのデバイスのための命令を生成することをさらに含んでもよい。

いくつかの実施形態では、システムは荷物の分類および装填を最適化するように構成されてもよい。システムは、メモリとプロセッサとで構成されるコンピュータ実施システムと、プロセッサに動作を実行させる命令を記憶するメモリとを含んでもよい。動作は、複数の荷物に関連付けられた複数の荷物識別子を含むデータを受信することを含んでもよい。動作はまた、複数の荷物の配送位置に関連付けられた複数のブロックエリアを決定することを含んでもよい。複数のブロックエリアは、受信されたデータに基づいて決定されてもよい。動作は、複数の荷物を配送するための領域系列を含む配送ルートを決定することをさらに含んでもよい。配送ルートはルートの第１のセットを決定し、ルートの第１のセットを変換して、ルートの第１のセットの各々に対する入力の最適な組み合わせを決定し、変換されたルートの各々に関連付けられたブロックエリアの順序を交換することによって、最短ルートを決定することによって決定されてもよい。この動作はさらに、複数の荷物のそれぞれの荷物を配送車に積み込む積載順序を決定することを含み得る。積載順序は、決定された配送ルートに基づいて決定されてもよい。動作は、積載順序の視覚的表現を表示するための命令を生成することをさらに含んでもよい。動作は、命令を送信することも含んでもよい。デバイスは送信された命令を受信し、決定された積載順序に従って複数の荷物を分類することを含む動作を実行するように構成された分類デバイスを含んでもよい。システムはまた、送信された命令を受信することと、積載順序の視覚的表現を表示することとを含む動作を実行するように構成された積み込みデバイスを含んでもよい。

開示された実施形態と一致して、非一時的なコンピュータ可読記憶媒体は、本明細書で説明された方法、プロセス、または動作のいずれかを実行するために少なくとも１つのプロセッサによって実行されるプログラム命令を記憶することができる。

前述の一般的な裁量および以下の詳細な説明は、例示的なものにすぎず、特許請求の範囲を限定するものではない。

図１Ａは、開示された実施形態と一致する、出荷、輸送、および物流オペレーションを可能にする通信のためのコンピュータ化されたシステムを備えるネットワークの例示的な実施形態を示す概略ブロック図である。 図１Ｂは、開示された実施形態と矛盾しない、インタラクティブなユーザインタフェース要素と共に、検索要求を満たす１つ以上の検索結果を含むサンプル検索結果ページ（ＳＲＰ）を示す。 図１Ｃは、開示された実施形態と一致する、対話型ユーザインターフェース要素と共に製品および製品に関する情報を含む例示的な単一ディスプレイページ（ＳＤＰ）を示す。 図１Ｄは、開示された実施形態と一致する、対話型ユーザインターフェース要素と共に仮想ショッピングカート内のアイテムを含むサンプルカートページを示す。 図１Ｅは開示された実施形態に一致する、仮想ショッピングカートからのアイテムを、購入および出荷に関する情報とともに、対話型ユーザインターフェース要素とともに含むサンプル注文ページを示す。 図２は、開示された実施形態と一致する、開示されたコンピュータ化されたシステムを利用するように構成された例示的なフルフィルメントセンタの概略図である。 図３は、開示された実施形態と一致する、荷物の分類および積み込みを最適化するための例示的な手法を示す流れ図である。 図４は、開示された実施形態と一致する、地理的エリア上にマッピングされた複数の決定されたブロックエリアを有する例示的な地理的エリアを示す。 図５Ａは、開示された実施形態に一致する、複数の荷物を受容するように構成された例示的なモジュール式コンテナの概略図である。 図５Ｂは、開示された実施形態に一致する、複数の荷物を受容するように構成された例示的なモジュール式コンテナの概略図である。 図６Ａは、開示された実施形態に一致する配送ルートを生成するためのインプットデータを示す流れ図である。 図６Ｂは、開示された実施形態と一致するルート生成器によって決定されたアウトプットデータを示す流れ図である。 図７Ａは、開示された実施形態と一致する、積荷領域内に複数の位置を有する例示的な後部積載配送車を示す。 図７Ｂは、開示された実施形態と一致する、積み荷領域内に複数の位置を有する例示的な側方積載配送車を示す。 図８Ａは開示された実施形態と一致する、決定された積載順序の視覚的表現の例示的な表示を示し、表示は、プリントアウトからなる。 図８Ｂは決定された積載順序の視覚的表現の例示的なディスプレイを示し、ディスプレイは、開示された実施形態に一致する、デバイスのスクリーン上のディスプレイからなる。

以下の詳細な説明は、添付の図面を参照する。可能な限り、図面および以下の説明では、同一または類似の部分を参照するために、同一の参照番号が使用される。いくつかの例示的な実施形態が本明細書で説明されるが、修正、適応、および他の実装が可能である。例えば、置換、追加、または修正が図面に示された構成要素およびステップに行われてもよく、本明細書に記載された例示的な方法は、開示された方法にステップを置換、並べ替え、除去、または追加することによって修正されてもよい。したがって、以下の詳細な説明は、開示された実施形態および実施例に限定されない。むしろ、本発明の適切な範囲は、添付の特許請求の範囲によって定義される。

本発明の実施形態は、配送される荷物の分類および積み込みを最適化するように構成されたシステムおよび方法を対象とする。分類および積み込みは、荷物が配送される、決定されたブロックエリアに基づいてもよい。分類および積み込みの順序は、システムから表示デバイスに送信される視覚的表現で表すことができる。

図１Ａを参照すると、出荷、輸送、および物流動作を可能にする通信のためのコンピュータ化されたシステムを含むシステムの例示的な実施形態を示す概略ブロック図１００が示されている。図１Ａに示すように、システム１００は様々なシステムを含むことができ、その各々は、１つまたは複数のネットワークを介して互いに接続することができる。システムはまた、例えばケーブルを使用して、直接接続を介して互いに接続されてもよい。図示のシステムは、出荷権限技術（ＳＡＴ）システム１０１、外部フロントエンドシステム１０３、内部フロントエンドシステム１０５、輸送システム１０７、モバイルデバイス１０７Ａ、１０７Ｂ、１０７Ｃ、売り手ポータル１０９、出荷および注文追跡（ＳＯＴ）システム１１１、フルフィルメント(履行)最適化（ＦＯ）システム１１３、フルフィルメントメッセージングゲートウェイ（ＦＭＧ）１１５、サプライチェーン管理（ＳＣＭ）システム１１７、労働力管理システム１１９、モバイルデバイス１１９Ａ、１１９Ｂ、１１９Ｃ（フルフィルメントセンタ（ＦＣ）２００の内部にあるものとして図示）、第三者フルフィルメントシステム１２１Ａ、１２１Ｂ、１２１Ｃ、フルフィルメントセンタ認証システム（ＦＣ認証）１２３、労働管理システム（ＬＭＳ）１２５を含む。

ＳＡＴシステム１０１は、いくつかの実施形態では注文ステータスおよび配送ステータスを監視するコンピュータシステムとして実装されてもよい。例えば、ＳＡＴデバイス１０１は注文がその約束配送日（ＰＤＤ）を過ぎているかどうかを決定し、新しい注文を開始すること、配送されていない注文の品目を再出荷すること、配送されていない注文をキャンセルすること、注文するカスタマとのコンタクトを開始することなどを含む、適切な行動をとることができる。ＳＡＴデバイス１０１は、出力（特定の期間中に出荷された荷物の数のよう）及び入力（出荷に使用するために受け取った空のボール紙箱の数のよう）を含む他のデータを監視することもできる。また、ＳＡＴシステム１０１はシステム１００内の異なるデバイス間のゲートウェイとして機能し、外部フロントエンドシステム１０３およびＦＯシステム１１３などのデバイス間の通信（例えば、ストアアンドフォワードまたは他の技術を使用する）を可能にしてもよい。

いくつかの実施形態では、外部フロントエンドシステム１０３が外部ユーザがシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、システム１００がシステムの提示によってユーザがアイテムの注文を行うことができるようにする実施形態では、外部フロントエンドシステム１０３が検索リクエストを受信し、アイテムページを提示し、決済情報を要請するウェブサーバとして実装されてもよい。例えば、外部フロントエンドシステム１０３は、アパッチＨＴＴＰサーバー、マイクロソフトインターネットインフォメーションサービス、ＮＧＩＮＸ等のソフトウエアを実行するコンピュータ又はコンピュータとして実施することができる。他の実施形態では、外部フロントエンドシステム１０３が外部デバイス（例えば、モバイルデバイス１０２Ａまたはコンピュータ１０２Ｂ）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得した情報に基づいて受信した要求に対する応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。

いくつかの実施形態では、外部フロントエンドシステム１０３がウェブキャッシングシステム、データベース、検索システム、または支払いシステムのうちの１つまたは複数を含むことができる。一態様では外部フロントエンドシステム１０３がこれらのシステムのうちの１つまたは複数を備えることができ、別の態様では外部フロントエンドシステム１０３がこれらのシステムのうちの１つまたは複数に接続されたインターフェース（例えば、サーバ間、データベース間、または他の網接続）を備えることができる。

図１Ｂ、図１Ｃ、図１Ｄ、および図１Ｅによって示されるステップの例示的な組は、外部フロントエンドシステム１０３のいくつかの動作を説明するのに役立つ。外部フロントエンドシステム１０３は提示および／またはディスプレイのために、システム１００内のシステムまたはデバイスから情報を受信することができる。例えば、外部フロントエンドシステム１０３は、検索結果を含む１つ以上のウェブページをホスティングまたは提供することができる： ページ(ＳＲＰ)(例えば、図１Ｂ）、単一詳細ページ(ＳＤＰ)(例えば、図１Ｃ）、カードページ（例えば、図１Ｄ）、または注文ページ（例えば、図１Ｅ）。ユーザデバイス（例えば、モバイルデバイス１０２Ａまたはコンピュータ１０２Ｂを使用する）は外部フロントエンドシステム１０３にナビゲートし、サーチボックスに入力することによってサーチをリクエストすることができる。外部フロントエンドシステム１０３は、システム１００内の１つまたは複数のシステムからリクエストすることができる。例えば、外部フロントエンドシステム１０３は、検索要求を満たす情報をＦＯシステム１１３に要求してもよい。また、外部フロントエンドシステム１０３は検索結果に含まれる商品ごとに、約束配送日または「ＰＤＤ」を（ＦＯシステム１１３から）リクエストし、受信することもできる。

ＰＤＤはいくつかの実施形態では製品を含む荷物がいつユーザの所望の場所に到着するか、または、例えば、午後１１時５９分までに特定の期間内に注文された場合、製品がユーザの所望の場所に配送されることを約束される日付の推定値を表すことができる（ＰＤＤはＦＯシステム１１３に関して以下でさらに説明される）外部フロントエンドシステム１０３がその情報に基づいてＳＲＰ(例えば、図１Ｂ）を準備することができる。ＳＲＰは、検索要求を満たす情報を含むことができる。例えば、これは、検索要求を満たす製品の写真を含むことができる。ＳＲＰはまた、各製品についてのそれぞれの価格、または各製品についての強化された配送オプション、ＰＤＤ、重み、規模、オファー、割引などに関する情報を含んでもよい。外部フロントエンドシステム１０３は（例えば、網を介して）要求側ユーザデバイスにＳＲＰを送信することができる。

次いで、ユーザデバイスは例えば、ユーザインターフェースをクリックまたはタップすることによって、または別の入力デバイスを使用して、ＳＲＰ上で表される製品を選択することによって、ＳＲＰから製品を選択することができる。ユーザデバイスは選択された商品に関するリクエストを作成し、それを外部フロントエンドシステム１０３に送ることができる。これに応じて、外部フロントエンドシステム１０３は、選択された商品に関する情報をリクエストすることができる。例えば、情報は、それぞれのＳＲＰ上の製品について提示される情報を超える追加の情報を含むことができる。これは、例えば、貯蔵寿命、原産国、体重、大きさ、荷物中の品目の個数、取扱説明書、または生成物に関する他の事項を含むことができる。また、情報は（例えば、この製品および少なくとも１つの他の製品を購入した顧客のビッグデータおよび／または機械学習分析に基づく）類似の製品に対する推奨、頻繁に質問される質問に対する回答、顧客からのレビュー、製造業者情報、写真などを含むことができる。

外部フロントエンドシステム１０３は受信したプロダクトインフォメーションに基づいて、ＳＤＰ(単一ディテールページ）（例えば、図１Ｃ）を準備することができる。ＳＤＰは、「今すぐ買う」ボタン、「カードに追加する」ボタン、数量フィールド、アイテムの写真などの他の対話型要素も含むことができる。ＳＤＰは、製品を提供する売り手のリストをさらに含むことができる。リストは各売り手が提供する価格に基づいて注文されてもよく、その結果、最低価格で製品を販売することを提案する売り手は最上位にリストされてもよい。リストは最高ランクの売り手が最上位にリストされるように、売り手ランキングに基づいて注文されてもよい。売り手ランキングは例えば、ＰＤＤを保持する売り手の過去のトラックレコードを含む複数の要因に基づいて定式化されてもよい。外部フロントエンドシステム１０３は（例えば、網を介して）要求側ユーザデバイスにＳＤＰを配送することができる。

要求ユーザデバイスは、製品情報をリストするＳＤＰを受信してもよい。その後、ＳＤＰを受信すると、ユーザデバイスはＳＤＰと対話することができる。例えば、要求ユーザデバイスのユーザは、ＳＤＰ上の「カートに入れる」ボタンをクリックするか、または他の方法で対話することができる。これは、ユーザに関連付けられたショッピングカートに製品を追加する。ユーザデバイスは、このリクエストを送信して、商品をショッピングカートに追加することができる（１０３）。

外部フロントエンドシステム１０３はカートページ（例えば、図１Ｄ）を生成することができる。カートページはいくつかの実施形態ではユーザが仮想「ショッピングカート」に追加した製品をリストし、ユーザデバイスは、ＳＲＰ、ＳＤＰ、または他のページ上のアイコンをクリックするか、または他の方法で対話することによって、カートページを要求してもよい。いくつかの実施形態では、カートページがユーザがショッピングカートに追加したすべての製品、ならびに各製品の数量、各製品毎の価格、関連する数量に基づく各製品の価格、ＰＤＤに関する情報、配送方法、出荷費用、ショッピングカート内の製品を修正するためのユーザインターフェース要素（例えば、数量の削除または修正）、他の製品を注文するかまたは製品の定期的な配送を設定するためのオプション、利息支払いを設定するためのオプション、購入を進めるためのユーザインターフェース要素などのカート内の製品に関する情報を列挙することができる。ユーザデバイスのユーザはショッピングカート内の製品の購入を開始するために、ユーザインターフェース要素（例えば、「今すぐ買う」と読むボタン）をクリックするか、さもなければユーザインターフェース要素と対話することができる。そうすると、ユーザデバイスは、購買を開始するためにこのリクエストを外部フロントエンドシステム１０３に送信することができる。

外部フロントエンドシステム１０３は購買を開始するためのリクエストを受信することに応じて、オーダーページ（例えば、図１Ｅ）を生成することができる。注文ページはいくつかの実施形態ではショッピングカートからアイテムを再リストし、支払いおよび出荷情報の入力を要求する。例えば、注文ページはショッピングカート内のアイテムの購入者に関する情報（例えば、名前、住所、電子メールアドレス、電話番号）、受取人に関する情報（例えば、名前、住所、電話番号、配送情報）、出荷情報（例えば、配送および／または集荷の速度／方法）、支払情報（例えば、クレジットカード、銀行振込、小切手、記憶クレジット）、現金受領を要求するためのユーザインターフェース要素（例えば、税務目的のための）などを要求する区画を含むことができる。外部フロントエンドシステム１０３は、注文ページをユーザデバイスに送信することができる。

ユーザデバイスはオーダページに情報を入力し、その情報を外部フロントエンドシステム１０３に送信するユーザインターフェース要素をクリックするか、または他の方法で対話することができる。そこから、外部フロントエンドシステム１０３は買い物かご内の製品を用いて新しい注文の作成および加工を可能にするために、システム１００内の様々なシステムに情報を送信することができる。

いくつかの実施形態では、外部フロントエンドシステム１０３が売り手が注文に関する情報を送受信することを可能にするようにさらに構成されてもよい。

内部フロントエンドシステム１０５はいくつかの実施形態では内部ユーザ（例えば、システム１００を所有し、運営し、またはリースする団体の従業員）がシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、システム１００がシステムの提示によってユーザが品目の注文を行うことができるようにする実施形態では、内部フロントエンドシステム１０５が内部ユーザが注文に関する診断および統計情報を表示したり、品目情報を変更したり、注文に関する統計をレビューしたりすることができるウェブサーバとして実装されてもよい。例えば、内蔵フロントエンドシステム１０５は、アパッチＨＴＴＰサーバ、マイクロソフトインターネットインフォメーションサービス、ＮＧＩＮＸ等のソフトウエアを実行するコンピュータ又はコンピュータとして実現することができる。他の実施形態では、内蔵フロントエンドシステム１０５がシステム１００に示されたシステムまたはデバイス（ならびに図示されていない他のデバイス）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得された情報に基づいて受信された要求への応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。

いくつかの実施形態では、内蔵フロントエンドシステム１０５がウェブキャッシングシステム、データベース、検索システム、支払いシステム、分析システム、注文監視システムなどのうちの１つまたは複数を含むことができる。一態様では内部フロントエンドシステム１０５がこれらのシステムのうちの１つまたは複数を備えることができ、別の態様では内部フロントエンドシステム１０５がこれらのシステムのうちの１つまたは複数に接続されたインターフェース（たとえば、サーバ間、データベース間、または他の網接続）を備えることができる。

輸送システム１０７は、いくつかの実施形態ではシステム１００内のシステムまたはデバイスとモバイルデバイス１０７Ａ〜１０７Ｃとの間の通信を可能にするコンピュータシステムとして実装されてもよい。いくつかの実施形態では、トランスポーテーションシステム１０７が１つまたは複数のモバイルデバイス１０７Ａ〜１０７Ｃ（例えば、携帯電話、スマートフォン、ＰＤＡなど）から受信することができる。例えば、いくつかの実施形態では、モバイルデバイス１０７Ａ〜１０７Ｃが配送作業員によって操作されるデバイスを含むことができる。配送作業員は、正社員、臨時社員、または交替社員であってもよく、モバイルデバイス１０７Ａ〜１０７Ｃを利用して、ユーザによって注文された製品を含む荷物の配送を行うことができる。例えば、荷物を配送するために、配送作業員は、どの荷物を配送すべきか、およびそれをどこに配送すべきかを示す通知をモバイルデバイス上で受信することができる。配送位置に到着すると、配送作業員は荷物を（例えば、トラックの後ろに、または荷物の箱に）配置し、モバイルデバイスを使用して荷物上の識別情報（例えば、バーコード、イメージ、文字列、ＲＦＩＤタグなど）に関連するデータを走査または捕捉し、荷物を（例えば、前扉に置いたままにするか、警備員を置いたままにするか、受信者に渡すなどによって）配送することができる。いくつかの実施形態では、配送作業員が荷物の写真をキャプチャすることができ、および／またはモバイルデバイスを使用してシグネチャを取得することができる。モバイルデバイスは例えば、時刻、日付、ＧＰＳ位置、写真、配送作業員に関連付けられた識別子、モバイルデバイスに関連付けられた識別子などを含む配送に関する情報を含む情報を輸送機関１０７に送信することができる。輸送システム１０７はシステム１００内の他のシステムによるアクセスのために、この情報をデータベース（図示せず）に記憶することができる。輸送システム１０７はいくつかの実施形態ではこの情報を使用して、特定の荷物の位置を示す追跡データを準備し、他のシステムに送信することができる。

いくつかの実施形態ではあるユーザが１つの種類のモバイルデバイスを使用することができる（例えば、永久作業員はバーコードスキャナ、スタイラス、および他のデバイスなどのカスタムハードウェアと共に専用のＰＤＡを使用することができる）が他のユーザは他の種類のモバイルデバイスを使用することができる（例えば、一時的または移動作業員は既製の携帯電話および／またはスマートフォンを利用することができる）。

いくつかの実施形態では、輸送システム１０７がユーザを各デバイスに関連付けることができる。例えば、輸送システム１０７はユーザ（例えば、ユーザ識別子、従業員識別子、または電話番号）とモバイルデバイス（例えば、国際移動デバイス識別子（ＩＭＥＩ）、国際移動加入識別子（ＩＭＳＩ）、電話番号、汎用一意識別子（ＵＵＩＤ）、またはグローバル一意識別子（ＧＵＩＤ）によって表される）との間のアソシエーションを記憶することができる。交通機関１０７はこの関連付けを、配送上で受信されたデータと共に使用して、とりわけ、作業員の位置、作業員の有効性、または作業員のスピードを決定するために、データベースに格納されたデータを分析することができる。

売り手ポータル１０９は、いくつかの実施形態では売り手または他の外部エンティティがシステム１００内の１つまたは複数のシステムと電子的に通信することを可能にするコンピュータシステムとして実装され得る。例えば、売り手は、コンピュータシステム（図示せず）を利用して、売り手が売り手ポータル１０９を使用してシステム１００を通して売りたい製品について、製品情報、注文情報、連絡先情報などをアップ積み込みまたは提供することができる。

出荷および注文追跡システム１１１はいくつかの実施形態では（例えば、デバイス１０２Ａ〜１０２Ｂを使用するユーザによって）顧客によって注文された製品を含む荷物の位置に関する情報を受信し、格納し、転送するコンピュータシステムとして実装され得る。いくつかの実施形態では、出荷および注文追跡デバイス１１１が顧客が注文した製品を含む荷物を配送する出荷会社によって運営されるウェブサーバ（図示せず）からの情報をリクエストまたは記憶することができる。

いくつかの実施形態では、出荷および注文追跡システム１１１がシステム１００に示されたシステムからの情報をリクエストし、記憶することができる。例えば、出荷および注文追跡システム１１１は、輸送システム１０７にリクエストすることができる。上述のように、交通機関１０７はユーザ（例えば、配送作業員）または乗り物（例えば、配送車）のうちの１つまたは複数に関連付けられた１つまたは複数のモバイルデバイス１０７Ａ〜１０７Ｃ（例えば、携帯電話、スマートフォン、ＰＤＡなど）から受信することができる。いくつかの実施形態では、出荷および注文追跡デバイス１１１がフルフィルメントセンタ（例えば、フルフィルメントセンタ２００）内の個々の製品の位置を決定するために、労働力管理システム（ＷＭＳ）１１９にリクエストすることもできる。出荷および注文追跡システム１１１は輸送システム１０７またはＷＭＳ １１９のうちの１つまたは複数からデータを要求し、それを処理し、要求に応じてそれをデバイス（例えば、ユーザデバイス１０２Ａおよび１０２Ｂ）に提示することができる。

フルフィルメント(履行)最適化（ＦＯ）システム１１３はいくつかの実施形態では他のシステム（例えば、外部フロントエンドシステム１０３および／または出荷および注文追跡システム１１１）からの顧客注文に関する情報を記憶するコンピュータシステムとして実装されてもよい。ＦＯシステム１１３はまた、特定のアイテムがどこに保持または格納されるかを記述する情報を格納してもよい。たとえば、特定の項目は１つのフルフィルメントセンタにのみ格納され、他の特定の項目は複数のフルフィルメントセンタに格納される場合がある。さらに他の実施形態では、特定のフルフィルメントセンターが特定のセットのアイテム（例えば、生鮮食品または冷凍製品）のみを格納するように設計されてもよい。ＦＯシステム１１３はこの情報ならびに関連する情報（例えば、数量、サイズ、受領日、有効期限など）を格納する。

また、ＦＯシステム１１３は、商品毎に対応するＰＤＤ(約束配送日）を計算してもよい。ＰＤＤは、いくつかの実施形態では１つまたは複数の要因に基づくことができる。例えば、ＦＯシステム１１３は製品に対する過去の需要（例えば、その製品がある期間中に何回注文されたか）、製品に対する予想需要（例えば、来るべき期間中にその製品を注文するために何人の顧客が予想されるか）、ある期間中にいくつの製品が注文されたかを示すネットワーク全体の過去の需要、来るべき期間中にいくつの製品が注文されることが予想されるかを示すネットワーク全体の予想需要、各フルフィルメントセンタ２００に記憶された製品の１つ以上のカウント、その製品に対する各製品、予想または現行の注文などに基づいて、製品に対するＰＤＤを計算することができる。

いくつかの実施形態では、ＦＯシステム１１３が定期的に（例えば、１時間ごとに）商品ごとにＰＤＤを決定し、それを検索または他のシステム（例えば、外部フロントエンドシステム１０３、ＳＡＴシステム１０１、出荷および注文追跡システム１１１）に送信するためにデータベースに格納することができる。他の実施形態では、ＦＯシステム１１３が１つまたは複数のシステム（例えば、外部フロントエンドシステム１０３、ＳＡＴシステム１０１、出荷および注文追跡システム１１１）から電子要求を受信し、オンデマンドでＰＤＤを計算することができる。

フルフィルメントメッセージングゲートウェイ１１５はいくつかの実施形態ではＦＯシステム１１３などのシステム１００内の１つ以上のシステムから１つのフォーマットまたはプロトコルで要求または応答を受信し、それを別のフォーマットまたはプロトコルに変換し、変換されたフォーマットまたはプロトコルで、ＷＭＳ １１９または第三者フルフィルメントシステム１２１Ａ、１２１Ｂ、または１２１Ｃなどの他のシステムに転送する、コンピュータシステムとして実装されてもよい。

サプライチェーン管理（ＳＣＭ）システム１１７は、いくつかの実施形態では予測機能を実行するコンピュータシステムとして実装することができる。例えば、ＳＣＭシステム１１７は例えば、製品に対する過去の需要、製品に対する予想される需要、ネットワーク全体の過去の需要、ネットワーク全体の予想される需要、各フルフィルメントセンタ２００に記憶された製品の数、各製品に対する予想または現在の注文などに基づいて、特定の製品に対する需要の水準を予測することができる。この予測された水準およびすべてのフルフィルメントセンタにわたるそれぞれの製品の量に応じて、ＳＣＭシステム１１７は特定の製品に対する予測された需要を満たすのに充分な量を購入し、在庫するための１つまたは複数の購入注文を生成することができる。

労働力管理システム（ＷＭＳ）１１９は、いくつかの実施形態ではワークフローをモニタするコンピュータシステムとして実装されてもよい。例えば、ＷＭＳ １１９は個別のイベントを示すイベントデータを個々のデバイス（例えば、デバイス１０７Ａ〜１０７Ｃまたは１１９Ａ〜１１９Ｃ）から受信することができる。例えば、ＷＭＳ １１９は、荷物を走査するためにこれらのデバイスの１つの使用を示すイベントデータを受信してもよい。フルフィルメントセンタ２００および図２に関して以下で論じるように、実行処理中に、荷物識別器（例えば、バーコードまたはＲＦＩＤタグデータ）は特定の段階で機械によってスキャンまたは読み取ることができる（例えば、自動またはハンドヘルドバーコードスキャナ、ＲＦＩＤリーダ、高速カメラ、タブレット１１９Ａ、モバイルデバイス／ＰＤＡ １１９Ｂ、コンピュータ１１９Ｃなどのデバイス）。ＷＭＳ １１９は荷物識別子、時刻、日付、場所、ユーザ識別子、または他の情報と共に、対応するデータベース（図示せず）に、荷物識別子の走査または読み取りを示すそれぞれの事象を格納することができ、この情報を他のシステム（例えば、出荷および注文追跡システム１１１）に提供することができる。

ＷＭＳ １１９はいくつかの実施形態では１つまたは複数のデバイス（たとえば、デバイス１０７Ａ〜１０７Ｃまたは１１９Ａ〜１１９Ｃ）をシステム１００に関連する１つまたは複数のユーザに関連付ける情報を記憶することができる。例えば、いくつかの状況では、ユーザ（パートまたはフルタイムの従業員など）がユーザがモバイルデバイスを所有する（例えば、モバイルデバイスがスマートフォンである）という点で、モバイルデバイスに関連付けられてもよい。他の状況では、ユーザがユーザが一時的にモバイルデバイスを保管している（例えば、ユーザは日の始めにモバイルデバイスをチェックアウトし、日中にそれを使用し、日の終わりにそれを返す）という点で、モバイルデバイスに関連付けられてもよい。

ＷＭＳ １１９は、いくつかの実施形態ではシステム１００に関連する各ユーザの作業ログを維持することができる。例えば、ＷＭＳ １１９は任意の割り当てられたプロセス（例えば、トラックのアン積み込み、ピックゾーンからのアイテムのピッキング、リビン(ｒｅｂｉｎ)ウォールワーク、パッキングアイテム）、ユーザ識別子、位置（例えば、フルフィルメントセンタ２００内のフロアまたはゾーン）、従業員によってシステム内を移動されたユニットの数（例えば、ピッキングされたアイテムの数、パッキングされたアイテムの数）、デバイスに関連する識別子（例えば、デバイス１１９Ａ〜１１９Ｃ）などを含む、各従業員に関連する情報を記憶することができる。いくつかの実施形態では、ＷＭＳ １１９がデバイス１１９Ａ〜１１９Ｃ上で動作するタイムキーピングシステムなどのタイムキーピングシステムからチェックインおよびチェックアウト情報を受信することができる。

いくつかの実施形態では、第三者フルフィルメント（３ＰＬ）システム１２１Ａ〜１２１Ｃがロジスティクスおよび製品のサードパーティプロバイダに関連するコンピュータシステムを表す。例えば、（図２に関して以下に説明するように）いくつかの製品がフルフィルメントセンタ２００に格納されている間、他の製品は、オフサイトで格納されてもよく、オンデマンドで生産されてもよく、またはフルフィルメントセンタ２００に格納するために利用できなくてもよい。３ＰＬシステム１２１Ａ〜１２１ＣはＦＯシステム１１３から（例えば、ＦＭＧ １１５を介して）注文を受信するように構成されてもよく、製品および／またはサービス（例えば、配送または設置）を顧客に直接的に提供してもよい。いくつかの実施形態では３ＰＬシステム１２１Ａ〜１２１Ｃのうちの１つまたは複数がシステム１００の一部とすることができ、他の実施形態では３ＰＬシステム１２１Ａ〜１２１Ｃのうちの１つまたは複数がシステム１００の外部（例えば、サードパーティプロバイダによって所有または運営される）とすることができる。

フルフィルメントセンタ自動システム（ＦＣ認証）１２３は、いくつかの実施形態では様々な機能を有するコンピュータシステムとして実装され得る。例えば、いくつかの実施形態では、ＦＣ認証１２３がシステム１００内の１つまたは複数の他のシステムのためのシングルサインオン（ＳＳＯ）サービスとして動作することができる。例えば、ＦＣ認証１２３はユーザが内部フロントエンドシステム１０５を介してログインすることを可能にし、ユーザが出荷および注文追跡システム１１１においてリソースにアクセスするための同様の特権を有していることを決定し、ユーザが２回目のログイン処理を必要とせずにそれらの特権にアクセスすることを可能にしてもよい。他の実施形態では、ＦＣ認証１２３がユーザ（例えば、従業員）が自分自身を特定の作業に関連付けることを可能にすることができる。例えば、従業員の中には、電子デバイス（デバイス１１９Ａ〜１１９Ｃなど）を持たない者もいれば、その代わりに、１日の過程中に、フルフィルメントセンタ２００内で、タスクからタスクへ、およびゾーンからゾーンへ移動することができる。ＦＣ認証１２３は、それらの従業員が彼らがどの仕事をしているか、および彼らが様々な時刻にどの区域にいるかを示すことを可能にするように構成されてもよい。

労働管理システム（ＬＭＳ）１２５は、いくつかの実施形態では従業員（フルタイムおよびパートタイムの従業員を含む）のための出勤および残業を記憶するコンピュータシステムとして実装されてもよい。例えば、ＬＭＳ １２５は、ＦＣ認証１２３、ＷＭＡ １１９、デバイス１１９Ａ〜１１９Ｃ、輸送デバイス１０７、および／またはデバイス１０７Ａ〜１０７Ｃから受信することができる。

図１Ａに示される特定の構成は単なる例である。例えば、図１ＡはＦＯシステム１１３に接続されたＦＣ認証システム１２３を示すが、全ての実施形態がこの特定の構成を必要とするわけではない。実際、いくつかの実施形態では、システム１００内のシステムがインターネット、イントラネット、ＷＡＮ(ワイドエリアネットワーク）、ＭＡＮ(メトロポリタンエリアネットワーク）、ＩＥＥＥ ８０２．１１ａ／ｂ／ｇ／ｎ規格に準拠する無線ネットワーク、専用線などを含む１つまたは複数の公衆またはプライベートネットワークを介して互いに接続され得る。いくつかの実施形態では、システム１００内のシステムの１つ以上がデータセンター、サーバファームなどに実装された１つ以上の仮想サーバとして実装されてもよい。

図２は、フルフィルメントセンタ２００を示す。フルフィルメントセンタ２００は、注文時に顧客に出荷するためのアイテムを格納する物理的な場所の実例である。フルフィルメントセンタ（ＦＣ）２００は多数のゾーンに分割することができ、その各々を図２に示す。いくつかの実施形態ではこれらの「ゾーン」がいくつかの実施形態ではアイテムを受け取り、アイテムを格納し、アイテムを取り出し、アイテムを出荷するプロセスの異なる段階間の仮想分割と考えることができ、したがって、「ゾーン」は図２に示されているが、ゾーンの他の分割も可能であり、図２のゾーンはいくつかの実施形態では省略、複製、または修正することができる。

インバウンドゾーン２０３は、図１Ａのシステム１００を使用して製品を販売したい売り手からアイテムが受け取られるＦＣ ２００の領域を表す。例えば、売り手は、トラック２０１を使用してアイテム２０２Ａ及び２０２Ｂを配送することができる。アイテム２０２Ａはそれ自体の出荷パレットを占有するのに十分な大きさの単一のアイテムを表すことができ、アイテム２０２Ｂは、スペースを節約するために同じパレット上に一緒に積み重ねられたアイテムのセットを表すことができる。

作業員はインバウンドゾーン２０３内のアイテムを受け取り、オプションとして、コンピュータシステム（図示せず）を使用して、アイテムの破損および正当性を検査することができる。例えば、作業員は、コンピュータシステムを使用して、品目２０２Ａおよび２０２Ｂの数量を品目の注文数量と比較することができる。数量が合致しない場合、その作業員は、項目２０２Ａまたは２０２Ｂのうちの１つまたは複数を拒否することができる。もし量が一致すれば、作業員はそれらのアイテムを（例えば、人形、手すり、フォークリフト、または手動で使用して）緩衝区域２０５に移動させることができる。バッファゾーン２０５は例えば、予測される需要を満たすのに十分な量のアイテムがピッキングゾーン内にあるため、ピッキングゾーン内で現在必要とされていないアイテムのための一時記憶領域であってもよい。いくつかの実施形態では、フォークリフト２０６が物品をバッファゾーン２０５の周り、およびインバウンドゾーン２０３とドロップゾーン２０７との間で移動させるように動作する。ピッキングゾーンに品目２０２Ａまたは２０２Ｂが必要な場合（例えば、予想される需要のため）、フォークリフトは、品目２０２Ａまたは２０２Ｂを落下ゾーン２０７に移動させることができる。

ドロップゾーン２０７は、アイテムがピッキングゾーン２０９に移動される前にアイテムを格納するＦＣ ２００の領域であってもよい。ピッキングタスクに割り当てられた作業員（「ピッカ」）はピッキングゾーン内のアイテム２０２Ａおよび２０２Ｂに接近し、ピッキングゾーンのバーコードをスキャンし、モバイルデバイス（例えば、デバイス１１９Ｂ）を使用してアイテム２０２Ａおよび２０２Ｂに関連するバーコードをスキャンすることができる。次いで、ピッカーはアイテムをピッキング・ゾーン２０９に（例えば、カートの上に置くか、またはそれを運ぶことによって）取り込むことができる。

ピッキングゾーン２０９は、アイテム２０８が記憶ユニット２１０に記憶されるＦＣ ２００の領域であってもよい。いくつかの実施形態では、貯蔵ユニット２１０が物理的な棚、本棚、箱、運搬箱、冷蔵庫、冷凍庫、冷蔵庫などのうちの１つまたは複数を含むことができる。いくつかの実施形態では、ピッキングゾーン２０９が複数のフロアに編成されてもよい。いくつかの実施形態では、作業員または機械が例えば、フォークリフト、エレベータ、コンベアベルト、カート、ハンドトラック、ドリー、自動ロボットもしくはデバイス、または手動を含む多数の方法で、物品をピッキングゾーン２０９に移動させてもよい。例えば、ピッカーはアイテム２０２Ａおよび２０２Ｂをドロップゾーン２０７内のハンドトラックまたはカート上に置き、アイテム２０２Ａおよび２０２Ｂをピッキングゾーン２０９まで歩くことができる。

ピッカーは、保管ユニット２１０上の特定のスペースのような、ピッキングゾーン２０９内の特定のスポットにアイテムを配置する（または「収納する」）命令を受け取ることができる。例えば、ピッカはモバイルデバイス（例えば、デバイス１１９Ｂ）を使用してアイテム２０２Ａを走査することができる。デバイスは例えば、通路、棚、および位置を示すシステムを使用して、ピッカーがアイテム２０２Ａを収納すべき場所を示すことができる。次に、デバイスはその位置にアイテム２０２Ａを格納する前に、その位置でバーコードをスキャンするようにピッカーに促すことができる。デバイスは図１ＡのＷＭＳ １１９のようなコンピュータシステムに（例えば、無線ネットワークを介して）データを送信し、デバイス１１９Ｂを使用するユーザによってアイテム２０２Ａがその場所に格納されたことを示すことができる。

ユーザが注文を出すと、ピッカは記憶ユニット２１０から１つまたは複数のアイテム２０８を取り出すために、デバイス１１９Ｂ上で命令を受け取ることができる。ピッカーはアイテム２０８を取り出し、アイテム２０８上のバーコードをスキャンし、それを搬送機構２１４上に置くことができる。搬送機構２１４はスライドとして表されているが、いくつかの実施形態では搬送機構がコンベヤベルト、エレベータ、カート、フォークリフト、ハンドトラック、台車、カートなどのうちの１つまたは複数として実施することができる。次に、品目２０８は、パッキングゾーン２１１に到着することができる。

パッキングゾーン２１１は、アイテムがピッキングゾーン２０９から受け取られ、最終的に顧客に出荷するためにボックスまたはバッグにパッキングされるＦＣ ２００の領域であってもよい。パッキングゾーン２１１では受取アイテム（「リビン(ｒｅｂｉｎ)作業員」）に割り当てられた作業員がピッキングゾーン２０９からアイテム２０８を受け取り、それがどの注文に対応するかを決定する。例えば、リビン(ｒｅｂｉｎ)作業員はアイテム２０８上のバーコードを走査するために、コンピュータ１１９Ｃなどのデバイスを使用することができる。コンピュータ１１９Ｃはどの注文アイテム２０８が関連付けられているかを視覚的に示すことができる。これは例えば、注文に対応する壁面２１６上の空間または「セル」を含むことができる。注文が完了すると（例えば、セルが注文のためのすべてのアイテムを含むため）、リビン(ｒｅｂｉｎ)作業員は注文が完了したことをパッキング作業員（または「パッカー」）に示すことができる。梱包業者はセルから品目を取り出し、それらを出荷のために箱または袋に入れることができる。その後、パッカーは例えば、フォークリフト、カート、ドリー、ハンドトラック、コンベヤーベルトを介して、又は他の方法で、箱又はバッグをハブゾーン２１３に送ることができる。

ハブゾーン２１３は、パッキングゾーン２１１から全てのボックスまたはバッグ（「荷物」）を受け取るＦＣ ２００の領域であってもよい。ハブゾーン２１３内の作業員および／またはマシンは荷物２１８を検索し、それぞれの荷物が行こうとする配送領域の一部を決定し、荷物を適切なキャンプゾーン２１５にルーティングすることができる。例えば、配送領域が２つのより小さいサブ領域を有する場合、荷物は２つのキャンプゾーン２１５のうちの１つに進む。いくつかの実施形態では、作業員またはマシンが（例えば、デバイス１１９Ａ〜１１９Ｃのうちの１つを使用して）荷物を走査して、その最終的な宛先を決定することができる。荷物をキャンプ・ゾーン２１５にルーティングすることは、例えば、荷物が向けられている地理的エリアの一部を（例えば、郵便番号に基づいて）決定することと、地理的エリアの一部に関連付けられたキャンプ・ゾーン２１５を決定することとを含むことができる。

キャンプゾーン２１５はいくつかの実施形態では１つまたは複数の建物、１つまたは複数の物理的な空間、または１つまたは複数のエリアを備えることができ、荷物は、ルートおよび／またはサブルートに分類するためにハブゾーン２１３から受け取られる。いくつかの実施形態ではキャンプゾーン２１５がＦＣ ２００から物理的に分離されているが、他の実施形態ではキャンプゾーン２０１５がＦＣ ２００の一部を形成することができる。

キャンプゾーン２１５内の作業員および／またはマシンは例えば、目的地と現存するルートおよび／またはサブルートとの照合、ルートおよび／またはサブルートごとの作業負荷の算出、時刻、出荷方法、荷物２２０を出荷する費用、荷物２２０内のアイテムに関連付けられたＰＤＤなどに基づいて、荷物２２０がどのルートおよび／またはサブルートに関連付けられるべきかを決定することができる。いくつかの実施形態では、作業員またはマシンが（例えば、デバイス１１９Ａ〜１１９Ｃのうちの１つを使用して）荷物を走査して、その最終的な宛先を決定することができる。荷物２２０が特定のルートおよび／またはサブルートに割り当てられると、作業員および／またはマシンは、出荷される荷物２２０を移動させることができる。例示的な図２において、キャンプゾーン２１５は、トラック２２２、かご２２６、および配送作業員２２４Ａおよび２２４Ｂを含む。いくつかの実施形態では、トラック２２２が配送作業員２２４Ａによって駆動されてもよく、配送作業員２２４ＡはＦＣ ２００の荷物を配送する常勤の従業員であり、トラック２２２はＦＣ ２００を所有し、リースし、または運営する同じ企業によって所有され、リースされ、または運営される。いくつかの実施形態では、自動車２２６が配送作業員２２４Ｂによって駆動されてもよく、ここで、配送作業員２２４Ｂは必要に応じて（例えば、季節的に）配送する「屈曲」または時折の作業員である。自動車２２６は、配送作業員２２４Ｂによって所有され、リースされ、または操作され得る。

本発明によれば、いくつかの実施形態では、輸送デバイス１０７が配送車への荷物の仕分けおよび積み込みを最適化するように構成されてもよい。このデバイスは例えば、荷物が配送される複数のブロックエリアを決定し、各ブロックエリアにサービスする順序を決定し、各ブロックエリアがサービスされているときに荷物が容易に配置されるように配送車に積載する順序を決定し、積載順序に従ってローダまたは自律ロボットが配送車に荷物を積載することができるように、デバイス上に積載順序の視覚的表現を生成することによって、荷物の分類および積載を最適化することができる。例として、図３は、荷物の分類および積み込みを最適化するための例示的な方法３００を提供する。方法またはその一部は、システムによって実行されてもよい。システムは１つ以上のプロセッサと、１つ以上のプロセッサによって実行されたときに、荷物の分類および積み込みを最適化するための動作をシステムに実行させる命令を記憶するメモリーとを含んでもよい。システムは、システム１００に含まれる任意のもの、システム１００に含まれるシステムの組み合わせ、システム１００に含まれないシステム、またはそれらの組み合わせであってもよい。他の実施形態では、図１Ａに示されるシステムまたはデバイスのうちの１つまたは複数が方法３００の１つまたは複数のステップを実行することができる。

本発明によれば、配送される荷物に関する情報を受信するように構成することができる。例えば、方法３００は、配送される複数の荷物に関するデータを受信する工程３０１を含むことができる。荷物識別情報、カスタマーオーダー、配送住所、希望配送日、商品の内容、荷物の寸法等に関する情報を含んでいてもよい。データは例えば、ＦＯシステム１１３によって生成されたデータ、例えば、顧客によって発注された注文の遂行に関連するデータを含むことができる。データは追加的に又は代替的に、例えば、顧客注文の注文及び配送状態を監視することに関連するデータのような、例えば、ＳＡＴデバイス１０１によって生成されたデータを含むことができる。例えば、トランスポートシステム１０７は配送のために準備された１つ以上の荷物に関するデータを受信することができ、データは、荷物の各々のための配送住所を含むことができる。

データは、本明細書で開示される任意のシステムまたはデバイスから受信され得る。例えば、データは、デバイス１１９Ａまたはデバイス１１９Ｂのようなモバイルデバイスから受信されてもよい。これに加えて、またはこれに代えて、データは荷物配送に関するデータを記憶または生成するシステム、例えば、ＳＡＴシステム１０１、ＦＯシステム１１３、出荷および注文追跡システム１１１、ＷＭＳ １１９などから受信されてもよい。

この情報は、荷物を加工する任意の段階で受信することができる。例えば、荷物が落下ゾーン２０７からピッキングゾーン２０９に移送されるとき、ピッカーがモバイルデバイス１１９Ｂでバーコードをスキャンするのに応じて、データを受信することができる。別の例では、データが例えば、梱包ゾーン２１１において、または出荷のために品目がハブゾーン２１３またはキャンプゾーン２１５に輸送されるときに、出荷のために品目が梱包されるときに受信されてもよい。

本開示と一致して、システムは、複数のブロックエリアを決定するように構成され得る。例えば、方法３００は、荷物が配送される複数のブロックエリアを決定する工程３０３を含むことができる。ブロックエリアは、複数の荷物のうちの少なくとも１つが配送される地理的領域であってもよい。それぞれのブロックエリアは複数の荷物のうちの少なくとも１つが連続的に配送され得る、壊れない、または連続的な地理的領域であってもよい。地理的領域は、配送車の使用を最小限に抑えて、その領域内に１つ以上の荷物を配送することを容易にする品質を有する場合、壊れないか、または継続的であり得る。例えば、地理的エリアは配送の人物が配送の車両を１つの場所に駐車し、配送の車両を移動させる必要なしに地理的エリア内に多数の荷物を配送することができる場合には、ブロックエリアであってもよい。別の例として、地理的エリアは配送の人物がエリア内の第１の位置に配送車を駐車し、エリアの第１の部分内に１つまたは複数の荷物を配送し、次いで、例えば、高速道路または他の主要な輸送機関上を移動する必要なく、エリア内の第２の位置に配送車を移動し、エリアの第２の部分内に１つまたは複数の荷物を配送することができる場合、ブロックエリアとすることができる。ブロックエリアは、特定の量または大きさの荷物が配送される地理的領域内の領域であってもよい。例えば、複数の荷物をほぼ等しい大きさのグループにグループ化し、地理的情報を用いて、荷物のグループの各々に対応するブロックエリアを決定することができる。ブロックエリアの例、及びそれらの位置、寸法等を決定するためのプロセスは、図４に関して以下に説明される。

本発明によれば、荷物の分類及び積み込みを最適化するためのデバイスは、荷物を荷物のグループに分類するように構成することができる。荷物は、複数のブロックエリアに対応するグループに分類されてもよい。例えば、該方法３００は、ステップ３０３で決定されたブロックエリアに対応するグループに荷物を分類するステップ３０５を含むことができる。分類は、複数の荷物内の各荷物を、決定されたブロックエリアのうちの１つと相関させ、各荷物を、同じブロックエリアに対応する他の荷物と位置決めすることを含み得る。トランスポートシステム１０７はブロックエリアの位置またはブロックエリアに含まれるアドレスのようなブロックエリアに関するデータを使用し、そのデータを各荷物からのデータと比較して、各荷物がどのブロックエリアに配送されるかを決定することができる。

輸送デバイス１０７は荷物を自動的に複数のグループに分類することができ、または作業員またはマシンに命令を提供することができ、命令は荷物の適切な分類を含む。例えば、コンベアベルトを使用して、例えば、コンベアベルト上の仕切りを使用して、コンベアベルト上の種々の点で荷物を分離することによって、荷物を複数のグループに仕分けしてもよい。例えば、ブロックエリア４０１に関連した荷物はコンベアベルト上の第１の点におけるセパレータによってコンベアベルトから除去されてもよく、ブロックエリア４０９に関連した荷物はコンベアベルト上の第２の点におけるセパレータによってコンベアベルトから除去されてもよい。別の例ではデバイスがモバイルデバイス１０７Ａまたはデバイス１１９Ａ上のＧＵＩ上に命令を提供することなどによって、荷物が複数のグループにどのように分類されるべきかを決定し、作業員に命令を提供することができ、作業員は命令に従って荷物を手動で分類することができる。

荷物は、ハブゾーン２１３、キャンプゾーン２１５、またはそれらの組合せでグループに分類することができる。例えば、作業員またはマシンがハブゾーン２１３内の荷物２１８を検索すると、荷物がスキャンされ、ブロックエリアに関連付けられる。次に、荷物は、ブロックエリアとの関連付けに基づいてグループ化されてもよい。別の実施形態では、荷物２２０がキャンプゾーン２１５で処理されるときに、ブロックエリアに対応する群に分類されてもよい。加えて、または代替として、荷物はハブゾーン２１３において、各グループが複数のブロックエリアに対応するグループに分類され、さらに、各サブグループがブロックエリアに対応するサブグループに分類されてもよいことが企図される。この実施例では、図４に示す地理的領域４００に配送される荷物がハブゾーン２１３内で一緒にグループ化され、キャンプゾーン２１５に移送される。キャンプゾーン２１５に入ると、荷物はさらに７つのサブグループに分割され、それぞれのサブグループは７つのブロックエリア４０１、４０３、４０５、４０７、４０９、４１１、または４１３のうちの１つに対応する。

本発明によれば、荷物を分類するステップは、荷物のそれぞれの群を１つまたは複数のモジュール式コンテナに分類するステップを含むことができる。モジュール式コンテナは、１つ以上の荷物を一時的に保管することができる任意の容器であってもよい。モジュール式コンテナは、再使用可能であってもよく、配送車に容易に装填可能であるように構成されてもよい。例えば、モジュール式コンテナは車輪を有し、それをＦＣ ２００の周りで容易に輸送することを可能にするか、又はフォークリフト２０６のような機械によって移動可能なように構成することができる。モジュール式コンテナは荷物を貯蔵するための１つまたは複数の区画を有することができ、例えば選択的に取り外し可能な壁面または仕切りを含めることによって、区画を追加または取り外すことができるように構成することができる。ブロックエリアに関する荷物は、荷物の仕分けと配送との間で、１つ以上のモジュール式コンテナに格納されてもよい。また、２つ以上のブロックエリアに関連する荷物は、単一のモジュール式コンテナ上に格納されてもよいことも企図される。モジュール式コンテナの例は、図５Ａ及び図５Ｂに関して以下に説明される。

分類された荷物に関連するデータは、システム１００内の他のシステムに送信されてもよく、または外部システムに送信されてもよい。例えば、輸送システム１０７は上述のように荷物を分類し、情報をＦＯシステム１１３、出荷および注文追跡システム１１１、またはデータを処理することができる他のシステムに提供することができる。データは、どの荷物が各グループに分類されるか、いくつの荷物が各グループに分類されるか、各グループに分類される荷物の寸法、各グループの荷物に関連する荷物識別子、各グループの位置、各グループに関連するモジュール式コンテナなどに関する情報を含むことができる。

本発明によれば、荷物の分類および積み込みを最適化するためのデバイスは、配送ルートを決定するように構成されてもよい。配送ルートは、決定されたブロックエリアに関する情報に基づいて決定されてもよい。例えば、方法３００は、ステップ３０３で決定されたブロックエリアに基づいて配送ルートを決定するステップ３０７を含むことができる。これに加えて、またはこれに代えて、輸送デバイス１０７は、分類された荷物に関するデータに基づいて、履歴配送データまたは運転データに基づいて、あるいはこれらの組合せに基づいて、配送ルートを決定することができる。

配送ルートは、複数の荷物を配送するための順序を含み得る。例えば、配送ルートは、複数のブロックエリアの各々にサービスを提供する順序を含むことができる。例えば、配送ルートは最初に荷物をブロックエリア４１３に配送し、次にブロックエリア４１１に配送し、次にブロックエリア４０７に配送するなどのルートとすることができる。配送ルートはさらに、または代替として、地理的領域を通る物理的なルートを含むことができ、例えば、配送ルートを通って配送車をナビゲートするための方向と、ルートに沿って荷物をどのようにおよび／またはどこに配送するかについての命令とを含むことができる。配送ルートの決定に関する例は、図６Ａおよび図６Ｂに関して以下に説明される。

本発明によれば、荷物の分類および積載を最適化するためのデバイスは、配送車を積載する順序を決定するように構成されてもよい。積載順序は、荷物の複数のグループの各々を積み込む順序を含むことができる。例えば、該方法３００は、ステップ３０５で決定された荷物のグループを配送車に積載するための積載順序を決定するためのステップ３０９を含むことができる。積載順序は、それぞれの荷物または荷物群が配送車内に配置される位置を含むことができる。積載順序は、配送の乗物に合わせることができる。同じルートに対する積載順序は例えば、第１の構成で構成された貨物領域を有する配送車が配送に使用される場合、または第２の構成を有する貨物領域を有する配送車が配送に使用される場合、異なってもよい。例えば、貨物エリアが複数の物理的区画を有する場合、積載順序は、第１の区画を積載する順序と、第２の区画を積載する順序とを含むことができる。同様に、積載順序は、配送乗物の扉または出入り口の位置によって決定されてもよい。配送車の構成およびそれぞれに関連付けられ得る積載順序の例を、図７Ａおよび図７Ｂに関して以下に論じる。

上述のように、地理的エリアに配送される複数の荷物は、地理的エリア内のブロックエリアに関連付けられたモジュール式コンテナに分類されてもよい。荷物をモジュール式コンテナに分類することは、積載順序を決定するための処理を単純化することができる。例えば、積載順序は、複数のモジュール式コンテナの各々を配送車に積載する順序を含むことができる。

本発明によれば、荷物の分類及び積み込みを最適化するためのデバイスは、デバイスに積載順序の視覚的表現をディスプレイさせるための命令を生成することができる。例えば、方法３００は、ステップ３０９で決定された積載順序を表示させるための命令を生成するためのステップ３１１を含むことができる。命令は、いくつかのタイプのディスプレイのための指示を含むことができる。例えば、命令は、コンピュータシステムに積載順序の視覚的表現を印刷させるための指示、モバイルデバイスに視覚的表現をＧＵＩに表示させるための指示、コンピュータシステムに視覚的表現を複数のデバイスに送信させるための指示、それらの組合せなどを含むことができる。視覚的表現及びそれを表示するための命令の例は、図８Ａ及び図８Ｂに関して以下に説明される。

図４は、地理的領域４００上にマップされた複数のブロックエリア４０１、４０３、４０５、４０７、４０９、４１１、４１３を示す。地理的区域４００は高速道路システム４１９、道路システム４１７、および鉄道システム４１５によって画定される複数の都市ブロックを含み、複数の建物（番号なし）および池４２１を含む。それぞれのブロックエリアは、複数の荷物のうちの１つまたは複数のための配送位置に関連付けられる。

本開示から理解され得るように、ブロックエリアは、任意の寸法であり得る。例えば、多数の荷物がマンションビルディングまたは事務所ビルディングなどの単一のビルディングに配送される場合、ブロックエリアは、そのビルディングのみを含むことができる。ブロックエリア４０５は、１つの建物を含むブロックエリアの一例である。別の例では、ブロックエリアが複数の都市ブロックのサイズとすることができ、複数の建物、住宅、またはそれらの組合せを含むことができる。ブロックエリア４０３は地理的エリア４００の２つのブロックをカバーし、複数の建物を含むブロックエリアの一例である。また、ブロックエリアは建物の一部のみを含んでもよいことも考えられる。例えば、複数のテナントを有する事務所ビルは、それぞれのテナントに配送される荷物の量に応じて、複数のブロックエリアに分割されてもよい。本開示から理解され得るように、ブロックエリアは、任意の形状または構成であり得る。ブロックエリア４０７は略矩形であるブロックエリアの一例であり、ブロックエリア４１１は、形状が不規則であるブロックエリアの一例である。

ブロックエリアの境界は、既存の物理的境界、人工的境界、またはそれらの組み合わせによって定義されてもよい。物理的境界は例えば、水域、高速道路または道路システム、鉄道、建物、樹木線などを含むことができる。人工境界は、エリアコード、郵便番号、サービスエリア、近隣、他のブロックエリアなどに関連する境界を含むことができる。ブロックエリア４０９は、片側の池４２１、両側のハイウェイシステム４１９、および他の側の道路システム４１７を含む物理的境界によって画定されるブロックエリアの一例である。ブロックエリア４１１は２つの側面の地理的領域４００の外側境界と、別の側面の隣接するブロックエリア４０５とによって規定される、高速道路システム４１９によって規定されるブロックエリアの一例であり、両者は人工的境界である。

また、配送する複数の荷物に関する情報からブロックエリアを決定してもよい。上述したように、例えば、方法３００の段階３０１において、システムによって受信されるデータは、荷物に対する配送アドレスを含むことができる。輸送システム１０７のようなシステムは配送アドレスを使用して、アドレスに対応する地理的エリアを決定し、さらに、アドレスに関連するブロックエリアを決定することができる。ブロックエリアは、既存の地理的エリアまたは他の人工的境界から決定されてもよい。例えば、システムは複数の荷物の配送住所に関するデータを受信し、住所を１つ以上の郵便番号に関連付けることができる。次に、荷物の第１のグループが郵便番号の第１のサブエリアに配送されるであり、荷物の第２のグループが郵便番号の第２のサブエリアに配送されるであることなどを決定することができる。次に、郵便番号によって定義される領域は複数のブロックエリアに分割され、各ブロックエリアは郵便番号内の識別されたサブ領域のうちの１つまたは複数に対応する。

ブロックエリアは、履歴配送データによって定義されてもよい。例えば、以前の配送に基づいて、交通機関１０７は例えば、地理的エリアのサブエリアが一貫して大量の荷物を受信することを決定することができる。この領域は例えば、既知のブロックエリアとしてシステム１００と通信するメモリデバイスまたはデータベースに保存することができる。将来の分析では、サービスされる地理的エリアが既知のブロックエリアを含む場合、輸送システム１０７は既知のブロックエリアに対応する地理的エリアの部分を第１のブロックエリアとして自動的に分類し、それによって、地理的エリアの複数のブロックエリアへの分割を単純化することができる。例えば、ブロックエリア４１３が一貫して大量の荷物を受け取るビジネスパークに関連付けられている場合、次に地理的領域４００について複数のブロックエリアを決定するときに、ブロックエリア４１３を独立したブロックエリアとして自動的に分類することによって解析を開始することができる。履歴データはまた、エリアの自然境界またはエリアへのサービスの容易さに関するデータを含むことができる。例えば、ブロックエリア４１１のように、ブロックエリア４１１を二つの区域に分けたハイウェイシステム４１９が自然境界として機能し、ブロックエリア４１１が二つのブロックエリアに分けられるべきであるように思えるかもしれない。しかしながら、履歴データーは、配送運転者がブロックエリア４１１内でハイウェイシステム４１９の両側に容易にサービスすることができることを示すことができる。これは、ドライバーフィードバック、その領域内の配送のモニターされた有効性、またはデバイスに提供されるかまたはデバイスによって決定される他の測定基準に基づいて決定される。

ブロックエリアは、システムによって自動的に決定されてもよい。例えば、輸送システム１０７は上述したデータを受信し、例えば、ニューラルネットワーク又は他のコンピュータ学習方法を使用して、上述したように複数のブロックエリアを決定することができる。ブロックエリアを自動的に決定する利点は、コンピューティング・システムが後続の動作で自動的に分析されるか、または他のシステムに送信される可能性がある追加のデータを生成する可能性があることである。他の例では、ブロックエリアが１つ以上の作業員からの入力に基づいて決定されてもよい。例えば、作業員は、２つの隣り合うブロックエリアを作ることを正当化する、以前の経験からの実際的な知見を有することができる。別の実施形態ではコンピュータシステムが複数のブロックエリアを決定し、ブロックエリアを１つまたは複数の作業員にディスプレイすることができ、次いで、１つまたは複数の作業員はシステムと対話することによって、決定されたブロックエリアの境界を調整または確認する機会を有することができる。

決定されたブロックエリアに関するデータは、他のシステムに送信されてもよく、メモリデバイスまたはデータベースに記憶されてもよく、あるいはシステム１００によって他の方法で処理されてもよい。データは、ブロックエリアの位置、サイズ、または寸法などのブロックエリアに関する情報を含むことができる。また、荷物量、荷物の大きさ、荷物毎の荷物識別子など、各ブロックエリアに配送する荷物に関する情報を含んでいてもよい。

図５Ａはモジュラー容器５０１の例示的な実施形態の正面図を提供し、図５Ｂは、同じ例示的なモジュラー容器５０１の側面図を提供する。モジュール式コンテナ５０１は、裏側５０３、右側５０５、および左側５０７を含む。モジュール式コンテナ５０１は前面を欠いているが、撤去可能な前面を備えるように構成されてもよい。撤去可能な前面はヒンジドア、スリダブルウォール、又はモジュール式コンテナ５０１への荷物の搭載及び搭載を可能に選択的に可動する他の部分を含むことができる。背面５０３、右側面５０５、および左側面５０７のそれぞれは複数の垂直バー５１０から構成されるものとして示されているが、この構造は例示的なものにすぎず、各側面５０３、５０５、５０７は任意の構成でよいことを理解されたい。

モジュール式コンテナ５０１は、複数の荷物を受け入れるための底部棚としても機能する底部５０９を含む。例えば、荷物５１４は、底部５０９の上面に載っている。底部５０９は、モジュール式コンテナ５０１を移動可能にするための手段のための取り付け点として働くことができる。例えば、ホイール５１３は、当技術分野で知られている任意の手段によって底部５０９に取り付けることができる。また、ホイール５１３は、側部５０３、５０５、５０７のいずれかに取り付けられてもよく、または底部５０９と側部５０３、５０５、５０７との組み合わせに取り付けられてもよいことも企図される。モジュール容器５０１はまた、底部シェルフとモジュラー容器５０１の上縁部との間に位置する取り外し可能なシェルフである仕切板５１１を含む。分割器５１１は、一群の荷物を支持する棚として作用する。例えば、荷物５１２は仕切り５１１の上面に載っている。分割器５１１は、当技術分野で知られている任意の手段によってモジュール式コンテナ５０１に取り付けることができる。例えば、分割器５１１は、右側面５０５および左側面５０７の垂直バー５１０を通して機械的締結具５１３によって取り付けられてもよい。分割器５１１は、モジュール式コンテナ５０１が底部５０９と、側部５０３、５０５、および５０７のそれぞれとによって画定される１つの区画を有するように、取り外されてもよい。

モジュール式コンテナ５０１は、使用されていないときに省スペース構成で格納され得るように構成され得ることが企図される。複数のモジュール式コンテナは、配送車に装填されてもよく、荷物が配送目的地に配送された後に配送車内に残ってもよい。省スペース構成に変換するようにモジュール式コンテナを構成することは、モジュール式コンテナ内に以前に装填された荷物を除去した後に、作業員が空のモジュール式コンテナを配送車内に格納することを可能にし、それによって配送車内の空間を解放することができる。例えば、モジュール式コンテナ５０１は実質的に平坦な構成に折り畳むことができるように、折り畳み可能な設計を有することができる。別の例として、モジュラー容器５０１は例えば、機械的締結具を取り外すことによって分解され、組み立てられたモジュラー容器よりも少ない体積しか必要としない構成で格納されてもよい。

それぞれのブロックエリアに対応する荷物は、モジュール式コンテナ５０１上に分類されてもよい。単一のブロックエリアからの荷物は、１つのモジュール式コンテナ５０１に積載することができる。例えば、ブロックエリア４１１に配送される複数の荷物があってもよく、第１のモジュール式コンテナ５０１には、ブロックエリア４１１に向けられた荷物の全てが装填されてもよい。荷物の量は、デバイダ５１１が取り外された状態でモジュール式コンテナ５０１全体を満たすのに充分な量とすることができる。別の実施形態では、ブロックエリア４０９に向けられた荷物のグループと、ブロックエリア４０７に向けられた荷物のグループとが存在してもよい。ブロックエリア４０９用の荷物はモジュール式コンテナ５０１の第１の区画内に配置されてもよく、第１の区画は底部５０９と仕切り５１１との間の領域によって画定され、ブロックエリア４０７用の荷物は同じモジュール式コンテナ５０１の第２の区画内に配置されてもよく、第２の区画は仕切り５１１の上方の領域によって画定される。

モジュール式コンテナは、仕分けおよび装填荷物のためのいくつかの利点を提供する。一例として、第１の位置、例えばハブゾーン２１３のモジュール式コンテナにブロックエリア別に分類された荷物は、キャンプゾーン２１５の配送車に搭載されたときに再分類される必要はない。また、モジュール式コンテナは、無駄な空間を最小限に抑えて、配送車に適合するように知的な大きさにすることができる。例えば、モジュール容器５０１は、配送車の荷物領域の高さに対応する高さであってもよい。さらに、モジュール容器５０１は、配送車の寸法の割合である幅員を有していてもよい。例えば、モジュール式コンテナの幅は配送車の貨物領域の幅の３分の１とすることができ、これにより、配送車は、配送車の貨物領域の無駄な空間を最小限に抑えた３つのモジュール式コンテナを積載することができる。分別・モジュールコンテナへの積み込みにより発生する効率は、配送タイムの向上や燃費の向上など、配送上のメリットにつながる可能性がある。

荷物は、本発明と一致する任意の手段によって分類されてもよく、モジュール式コンテナに分類される必要はないことを理解されたい。例えば、搬送デバイス１０７は荷物が上述したのと実質的に同じ方法でどのように分類されるべきかを決定することができ、荷物を複数のグループに分類するための命令を生成することができる。命令は例えば、各荷物のための荷物識別子、各荷物のグループのためのグループＩＤ、および各荷物を対応するグループに入れるための命令を含み得る。分類は例えば、分類デバイス、ロボットシステムなどによって実行されてもよい。いくつかの実施形態は、手動分類も含むことができる。

デバイスは、複数の要因に基づいて１つ以上の配送ルートを決定することができる。効率の好みは、配送ルートを決定するために使用されてもよい。効率の好みは、ユーザによって提供されるか、またはデバイスによって決定され、荷物を配送する効率に関連する任意の規則または指針であってもよい。例えば、第１の効率優先は右旋回が赤色光で行われることができ、さもなければ実行がより容易であるため、右旋回が左旋回よりも好ましいことを提供することができる。効率優先の別の例は例えば、ＦＣ ２００を出る任意の配送車が少なくとも８０％の荷物で満杯である必要がある場合に、配送車が一定のパーセンテージで満杯である場合にのみ、配送のために出発することができるというものであってもよい。効率優先の別の例は、２つのルートが互いにオーバーラップしないことである。また、例えば、他のエリアよりも先に最も荷物度の高いブロックエリアに荷物を配送することを優先してもよい。ここで提供される効率優先は単なる例示であり、任意の効率優先がルート決定に含まれてもよいことが理解される。

リソースデータは、配送ルートを決定するために使用されてもよい。リソースデータは、配送上で使用され得るリソースに関連する任意のデータである。資源データの例には、利用可能な配送車の数および種類（例えば、２台のトラックおよび１台の乗客車）、利用可能な配送作業員の数（例えば、１つのフルタイム作業員および２つのパートタイム作業員）、配送に利用可能な支援機械またはシステムの数（例えば、１台の犬車または自律ロボット）などに関するデータが含まれる。リソースデータは、デバイス１１９Ａ上などの入力を介してシステムに提供されてもよく、またはＷＭＳ １１９などのシステムによって決定されてもよい。

荷物データはまた、配送ルートを決定するために使用されてもよい。荷物データは、荷物識別子、荷物の量、荷物の寸法、荷物が配送される領域、荷物がどのように分類されるか等を含むことができる。荷物情報は、インプットまたは別のシステムからシステムによって受信されてもよい。例えば、荷物データは、方法３００のステップ３０１で受信されたデータ、方法３００のステップ３０３で生成されたデータ、方法３００のステップ３０５で生成されたデータ、またはそれらの組合せを含むことができる。

配送ルートを決定するために使用される要因は上述のように、配送ルートが、荷物をブロックエリアに対応するグループに分類する前後に決定されるかどうかに依存し得る。例えば、システムは地理的エリア４００に関するデータを受信し、地理的エリア４００の有効性の好み及び地形に基づいて、ブロックエリアの各々に荷物を配送するためのルートを決定することができる。結果として得られるルートは例えば、各ブロックエリアにアクセスするための最も効率的なルートであってもよい。例えば、効率的な優先によれば、最も効率的なルートはブロックエリア４０９から始まり、ブロックエリア４１３から始まり、ブロックエリア４１１から始まり、ブロックエリア４０７から始まり、ブロックエリア４０５から始まり、ブロックエリア４０１から始まり、最後にブロックエリア４０３である。逆に、荷物がすでにグループに分類されている場合はブロックエリアの一部に他の領域よりもはるかに多い、または少ない荷物が含まれているか、または一部のブロックエリアの荷物が同じモジュール式コンテナで分類されていることが荷物されている可能性がある。例えば、ブロックエリア４０７が地理的エリア４００のブロックエリアの中で最も荷物量が多く、ブロックエリア４１１と４０５の荷物が同じモジュール式コンテナに分類されている場合、システムはまずブロックエリア４０７のために荷物の全部を配送し、次に、ブロックエリア４１１と４０５が同じモジュール式コンテナに含まれているために連続して配送されるという条件を有する他のブロックエリアに荷物を配送する順序を決定することが最も効率的であると判断するかもしれない。

図６Ａは、ルート生成器へのインプットを示す例示的なフローチャートの説明図である。図６Ａから分かるように、入力はいくつかの異なるタイプのデータを含むことができ、各タイプのデータは、複数の情報を含むことができる。例えば、配送データ６０１は、各ブロックエリアのアイデンティティ、各ブロックエリアに配送される荷物の量または体積、および荷物が分類されるモジュール式コンテナのアイデンティティに関するデータを含み得る。例えば、図６Ａによって表されるインプットは方法３００のステップ３０７の一部として実行されてもよく、配送データ６０１は方法３００のステップ３０３で生成されたブロックエリアに関するデータと、方法３００のステップ３０５の間に発生した可能性があるモジュールコンテナへの荷物の分類に関するデータとを含んでもよい。配送データ６０１は単なる例示であり、図６Ａに示されていないデータを含んでもよく、または図６Ａに示されているデータの一部を除外してもよい。

インプットは、荷物の配送を達成するために利用可能なリソースに関連するリソースデータ６０３を含むことができる。図６Ａの例では、資源データ６０３が配送車の可用性、それぞれの配送車の能力（例えば、配送車内に受け取ることができる多数のモジュール式コンテナで測定される）、および荷物を配送することができる作業員の可用性および状態に関するデータを含む。資源データ６０３は利用可能な配送車の台数、各配送車の好み又は制限（例えば、２輪駆動車両は、山又は他の震えやすい地形のエリアにサービスできない場合がある）、各配送車の燃費などの他の情報を含むことができる。

入力は、事前に設定された、または決定された規格に関連する効率優先６０５を含むことができる。効率優先６０５は、配送に影響を及ぼす事業体が達成したいと望む任意の効率基準、または制度または作業員が重視する任意の基準であってもよい。例えば、第１の効率基準は各ブロックエリアに荷物を配送するために可能な最少の配送車を使用することができ、第２の効率基準は配送上で左折しないようにしたいという要望であり、第３の効率基準は、配送のために出発する前に８０％を超える全ての配送車を有するようにすることであり得る。

入力は、地理的データ６０７も含むことができる。地理的データ６０７は図４の地図に対応する地図として示されているが、データは視覚的表現（地図など）、エリアの記述（ＧＰＳ座標または地形情報など）、またはそれらの組合せを含む、任意の形態をとることができる。地理的データ６０７は、地理的エリア内の各ブロックエリア４０１、４０３、４０５、４０７、４０９、４１１、４１３の位置、位置、寸法などを含むことができる。列挙されたデータに加えて、履歴配送データなどの追加データをインプットとして含めることができる。配送データ６０１、資源データ６０３、効率優先６０５、地理的データ６０７、および他のインプットデータは、プロセッシングのためにルート生成器６１１に提供される。

ルート生成器６１１は複数の荷物を配送するためのシーケンスを含む配送ルート６１２を決定するために、インプットデータをプロセッシングするための１つ以上のアルゴリズムを含み得る。ルート生成器６１１は、ハードウエア、ソフトウエア、ファームウエア、またはそれらの組合せとして実施することができる。ルート生成器６１１は配送を完了し、リソースをグループ化し、それらを、例えば、配送される荷物にマッチングさせるために、どのリソースが必要であるかを決定するように構成されたマッチングアルゴリズムを含むことができる。例えば、マッチングアルゴリズムは、配送データ６０１をリソースデータ６０３と比較して、リソースデータ６０３において識別された配送車の両方が配送データ６０１において識別された９つのモジュール式コンテナを移送するために必要とされることを決定し得る。この判定は配送車（第１の配送車用の６つのモジュール式コンテナ及び第２の配送車用の４つのモジュール式コンテナ）のいずれの容量も、配送データ６０１で特定された９つのモジュール式コンテナを収容するのに十分ではないが、２つの配送車の総容量が９つのモジュール式コンテナを収容するのに十分であるという判定に基づくことができる。マッチングアルゴリズムはまた、例えば、どの作業員が配送車の各々とマッチングされるべきか、ＦＣ ２００のどの領域（例えば、キャンプゾーン２１５、出荷ゾーン２１７など）が各配送車とマッチングされるべきか、および他のロジスティックインフォメーションを決定し得る。マッチングアルゴリズムはまた、配送データ６０１内の特定の要件を認識し、特定の要件を有するそれらの荷物を、リソースデータ６０３内で識別された適切なリソースとマッチングさせるように構成されてもよい。例えば、荷物の第１の群が冷凍を必要とする場合、マッチングアルゴリズムは、これらの荷物を、冷凍能力を有する配送車とマッチングさせる。

ルート生成器６１１は、第１の配送車と第２の配送車との間の荷重をバランスさせるためのバランスアルゴリズムを含んでもよい。負荷は、任意の基準に基づいてバランスをとることができる。例えば、デバイスは各配送車がＦＣ ２００を出るときにほぼ同じ比率で完全になるように、各配送車が配送ルート上を実質的に同じ距離を走行するように、または任意の他のバランス基準で、荷重をバランスさせることができる。図６Ａに描かれた実例では、バランシングアルゴリズムが（６つのモジュール式コンテナの能力を有する）より大きな配送車がより小さな配送車よりも多くのモジュール式コンテナを有するべきであると決定し、それぞれの配送車にどのモジュール式コンテナを割り当てるべきかを決定することができる。バランシングアルゴリズムは例えば、どのモジュール式コンテナが互いに近接して配送の目的地を有するかを決定することによって、またはすべてのモジュール式コンテナを配送するのに必要な総距離を決定することによって、および２つの配送する車両間の総距離を実質的に等しく、またはそれぞれの配送車の大きさ、燃費、または他の基準に比例して分割することによって、解析において地理的データ６０７および効率優先６０５を考慮し得る。

マッチングアルゴリズム及びバランシングアルゴリズムは、複数の潜在的ルートを決定することができると考えられる。例えば、マッチングアルゴリズムは、配送およびバランシングアルゴリズムを完成させるために使用され得る配送車、作業員、およびＦＣ ２００領域の複数の可能な組み合わせを決定してもよく、効率優先６０５および他の基準を満足する複数の可能なルートを決定してもよい。ルート生成器６１１は、複数の考えられるルートをユーザに報告またはディスプレイすることができることが企図される。これに加えて、またはこれに代えて、ルート生成器６１１は、１つまたは複数の好ましいルートを決定することができる。ルート生成器６１１は図６Ａに示されていない追加のインプット、例えば、履歴配送データ、気象状態に関するデータ、または配送ルートに影響を及ぼし得る他の要因を考慮し得ることが企図される。ルート生成器６１１は追加のアルゴリズムを含むことができ、アルゴリズムは、任意の順序で、または実質的に同時にインプットデータを処理することができることが企図される。

たとえば、ルート生成器６１１は、１つまたは複数の考えられるルートを決定するための機能を実装することができる。いくつかの実施形態では、ルート生成器６１１が基本ルート生成器６１１Ａ、ルート最適化器６１１Ｂ、およびシーケンス最適化器６１１Ｃを含んでもよい。基本ルート生成器６１１Ａは、複数の荷物を配送するためのルートの第１のセットを決定してもよい。基本ルート生成器へのインプットは上述したように、資源データと配送データとの混合を含むことができる。例えば、入力は利用可能な多数の配送車、各配送車の容量、各車両に対する好み、各ブロックエリアに対して意図される荷物の容積、ブロックエリア間の距離等を含んでもよい。基本ルート生成器６１１Ａは、荷物を配送するための考えられるすべてのルートを識別するための発見的アルゴリズムを含んでもよい。ヒューリスティックアルゴリズムはそれぞれのインプットが決定において一度だけ使用され、荷物を配送するために必要とされる最小限のルートを決定することができるように、制限されることができる。ルートはランダムに決定されてもよいし、複数の所定の設定に従って決定されてもよい。例えば、入力が図６Ａのものに対応する場合、基本ルート生成器６１１Ａはそれぞれの配送車に対応する２つの配送ルートを決定することができ、各ブロックエリアおよび各配送ドライバを２つのルートのうちの１つにランダムに割り当てることができる。

ルート・オプティマイザ６１１Ｂは基本ルート生成器によって決定されたルートを受け取り、一連の変換を実行してもよい。変換は、各ルートに対する入力の最適な組み合わせを決定するように構成されてもよい。例えば、上記の例を続けると、ルートオプティマイザ６１１Ｂは第１の配送ルートから第２の配送ルートに、およびその逆に、ブロックエリアのうちの１つまたは複数を交換することができる。ブロックエリア、作業員、および他の要因を再配置することによって、ルート最適化器は、第１のルートについての複数の可能な組み合わせ、および第２のルートについての複数の可能な組み合わせを生成することができる。ルートオプティマイザ６１１Ｂは可能な第１のルートのそれぞれを可能な第２のルートのそれぞれと比較し、比較に基づいて第１のルートおよび第２のルートを選択することができる。例えば、ルートオプティマイザ６１１Ｂは、１つまたは複数の要因において第２のルートとの差が最小化された第１のルートを選択することができる。比較は例えば、１／０プログラミングモデルを使用して実行されてもよい。例えば、ファクタは荷物のボリュームであってもよく、ルートオプティマイザはルートごとの荷物のボリューム間の差異が最小である第１および第２のルートに基づいて、第１および第２のルートを選択してもよい。言い換えれば、選択された第１のルートは選択された第２のルートとほぼ同じ荷物量を有し、第１のルートまたは第２のルートの他の選択は、第１のルートと第２のルートとの間の体積の間の差異をより小さくしない。ルートオプティマイザ６１１Ｂのアウトプットはルートごとの組合せの一覧、例えば、使用されるべき配送車の指標、サービスされるべき区域、配送される荷物などを含むことができる。

シーケンスオプティマイザ６１１Ｃは、ルートオプティマイザからの出力を使用して、各ルートのシーケンスを決定することができる。シーケンスは、ブロックエリアのそれぞれにサービスする順序を含むことができる。シーケンスオプティマイザ６１１Ｃは例えば、各ブロックエリアをノードとして表し、各ノードとそれに隣接するノードとの間の距離を決定し、各ノードに移動するための最短距離を決定することができる。各ノード（すなわち、ブロックエリア）に移動するための最短距離の決定は、巡回セールスマン問題（ＴＳＰ）を解決するのと実質的に同じ方法で達成することができる。例えば、シーケンスオプティマイザ６１１Ｃは各ノードを２つの最も近い隣接ノードに接続することによってベースライン距離を決定し、このモデルによって必要とされる合計距離を計算することができる。その後、シーケンス・オプティマイザーは１つ以上のノードをスワップできる。スワップの結果、移動した総距離が短くなる場合、シーケンスオプティマイザはその結果を保存することができ、スワップの結果、移動した総距離が長くなる場合、シーケンスオプティマイザは異なるスワップを実行し、このプロセスを繰り返すことができる。スワップはランダム化されてもよく、あるいは、シーケンスオプティマイザ６１１Ｃがどのノードをスワップすべきかを推定するために、ヒューリスティックモデルまたはニューラルネットワークモデルを使用してもよい。スワッピングプロセスの数回の反復の後、各ブロックエリアへの移動のための可能な最短ルートが決定される。

シーケンスオプティマイザ６１１Ｃは最短ルートが必ずしも最適シーケンスではないように、追加の制約を含むことができると考えられる。例えば、制約はルートがそれ自体をクロスオーバしないようにすることであり、シーケンスオプティマイザは、ルートをそれ自体クロスさせるスワップを実行することを回避するためにその情報を使用する。シーケンスオプティマイザのアウトプットは、各配送ルート、各ルートに関連付けられたブロックエリア、作業員、配送車など、および各ブロックエリアにサービスするシーケンスの一覧であってもよい。

この例では基本ルート生成器６１１Ａ、ルートオプティマイザ６１１Ｂ、および順序オプティマイザ６１１Ｃの各々はマッチングアルゴリズムまたは上述のバランシングアルゴリズムのいずれかに含まれてもよく、それに対して相補的であってもよく、またはバランシングおよび／またはマッチングアルゴリズムの代わりに使用されてもよい。例えば、基本ルート生成器６１１Ａはマッチングアルゴリズムに含まれてもよく、ルートオプティマイザ６１１Ｂおよびシーケンスオプティマイザ６１１Ｃはバランスアルゴリズムに含まれてもよい。別の実施形態では、ルート生成器６１１がマッチングアルゴリズムおよび順序オプティマイザ６１１Ｃのみを含んでもよい。ルート・オプティマイザ６１１Ｂおよびシーケンス・オプティマイザ６１１Ｃと組み合わせて基本ルート生成器６１１Ａを使用することは、さもなければ、ランダムまたはブルートフォース方式で生成され得る生成ルートにおいて、効率的利点を提供する。

図６Ｂは、ルート生成器６１１から出力され得るデータタイプの図示を提供する。図６Ｂに示されるルート生成器６１１の出力は、図６Ａに示される入力データに対応する。本事例では、ルート生成器６１１がルート１ ６１３Ａとルート２ ６１３Ｂの２つのルートを決定した。各ルートについて、ルート生成器６１１は、どの配送車を使用するか、どの作業員が荷物を配送するか、どのモジュール式コンテナが各配送車に含まれるか、各ルート上で配送される荷物の個数、各ルートによってサービスされるブロックエリア、ブロックエリアがサービスされる順序などを識別するデータを生成した。例えば、ルート１ ６１３Ａは、使用される配送車と、そのルート上で荷物を配送する作業に割り当てられた作業員とを識別するルートディテール６１５Ａを含む。ルート詳細６１５Ａは、リソースデータ６０３に対応することに留意されたい。ルートディテール６１５Ａは、どのキャンプゾーン２１５が配送車を積み込むために使用されるべきかのような、他のロジスティックインフォメーションを識別するデーターを含むことができると考えられる。ルート１ ６１３Ａのために生成されたデータは、ルート上で配送される荷物の番号、荷物を保持するモジュール式コンテナの識別、および荷物が対応するブロックエリアを識別する荷物詳細６１７Ａを含むことができる。荷物詳細６１７Ａは、各荷物に対応する配送住所、各荷物の寸法、各荷物の重みなど、荷物に関する他の情報を含むことができることが企図される。ルート生成器６１１に提供される配送データ６０１の全体は、荷物詳細６１７Ａのルート１ ６１３Ａと荷物詳細６１７Ｂのルート２ ６１３Ｂとの間で考慮されることに留意されたい。ルート毎に生成される情報には荷物の配送順序、またはブロックエリアのサービス順序が含まれていてもよい。例えば、ルート１ ６１３Ａは、ルート１ ６１３Ａによってサービスされる各ブロックエリアがサービスされる順序と、各ブロックエリアに対応する１つまたは複数のモジュール式コンテナとを指示する配送順序６１９Ａを含む。上述のように、ブロックエリアがサービスされる順序は、効率優先６０５および地理的データ６０７を含むいくつかの要因によって決定され得る。配送順序６１９Ａは、それぞれのブロックエリアへの、およびそれぞれのブロックエリア間のナビゲーション方向などの追加のデータを含むことができることが企図される。

ルート生成器６１１は効率プリファレンス６０５に対する例外を認識するように、またはそわなければ特殊化されたルートを生成するように構成され得ることが企図される。例えば、配送が、配送データ６０１に反映され得る、所定の時間フレーム内に配送される荷物を含む場合、ルート生成器６１１はそれらの荷物プライオリティを与え、それによって、それらが時間フレーム内に配送されることを確実にするために、配送ルートにおけるそれらの位置を変更することができる。

ルート生成器６１１によって生成されたデータは、さらに処理され、記憶され、またはシステム１００内の任意のシステムまたは外部システムに送信されてもよい。例えば、ルート詳細６１５Ａは作業員またはロボットシステムが配送のためにルート詳細６１５Ａ内で識別された配送車を準備し、配送に関連する１つまたは複数のタスクをＦＣ ２００内の作業員またはシステムに割り当てることができるように、ＷＭＳ １１９に送信することができる。同様に、荷物詳細６１７Ａおよび６１７Ｂはハブゾーン２１３の作業員またはシステムが荷物詳細６１７Ａで識別されたモジュール式コンテナを第１のキャンプゾーン２１５に移送し、荷物詳細６１７Ｂで識別されたモジュール式コンテナを第２のキャンプゾーン２１５に移送することができるように、デバイス１０７Ａなどのデバイスに送信することができる。同様に、配送注文６１９Ａおよび配送注文６１９ＢはＦＯシステム１１３に送信され、ＰＤＤを決定するために、または出荷および注文追跡システム１１１に使用され、荷物の出荷の追跡を支援するために使用されてもよい。

図７Ａは、例示的な配送車７００の上面図である。配送車は、乗客領域７０１及び貨物領域７０３、２つのドア７０５Ａ、７０５Ｂを有する貨物領域７０３から構成される。積荷区域７０３内には、複数の位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆがあり、そこに一群の荷物またはモジュール式コンテナを積み込むことができる。位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆは、貨物領域７０３内の物理的に分離された領域を表さないことが考えられる。図７Ａから分かるように、領域Ａ及びＢは、配送車７００の前面に最も近く、ドア７０５Ａ、７０５Ｂから最も遠い貨物領域７０３内の領域である。この例では、好ましい積載順序が領域ＡおよびＢが領域ＣおよびＤの前に充填され、領域ＥおよびＦの前に充填される順序であってもよく、ドア７０５Ａ、７０５Ｂから等距離にある領域が隣接する領域よりも優先されてもよい場合もある。例えば、ドア７０５Ａはドア７０５Ｂとは独立に開いてもよく、ドア７０５Ｂはドア７０５Ａが既に開いている場合にのみ開いてもよい場合がある。この場合、位置Ｆは位置Ｅよりも優先され、位置Ｆは位置Ｅよりも先に積み込みされ、この場合、位置Ｅは最初に配送される荷物に関連付けられ、荷物は最後に位置Ｅに積み込みされる。配送ルート上の最初の停留所では、作業員が位置Ｅの荷物を配送し、配送の残部のために位置Ｅを空のままにすることができる。その後、配送作業員は例えば、位置Ｅの空いている空間を通って取り除くことによって、位置Ｆに装填された荷物を配送することができ、それによって扉７０５Ｂを開く必要性を回避する。１つの位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆを別の位置よりも優先する追加の理由があり得、上記の例は限定的ではない。図７Ｂは、配送車、配送車７０２の別の実例を提供する。配送車７０２は、ドア７１５Ａ及び７１５Ｂが荷物領域７１３の側面に位置することを除いて、配送車７００と実質的に同じである。上記と同様に、好ましい積載順序は最初にドアから最も離れた領域を積載し、最後にドアに最も近い領域を積載するものであってもよい。

図７Ａおよび図７Ｂに示す例では、配送車７００および７０２の構成は例示にすぎないことを理解されたい。特に、ドア７０５Ａ、７０５Ｂ、７１５Ａ、７１５Ｂはそれぞれの貨物領域７０３、７１３上のどこにでも配置することができ、ヒンジ上の開口部として示されているが、ドアは摺動、転動、後退などの当技術分野で知られている任意の手段によって開くことができる。また、複数の位置に複数のドアが存在してもよく、例えば、配送車は、荷物領域の側部および後部の両方に位置するドアを有する可能性がある。貨物エリア７０３、７１３は任意の数のエリアに再分割されてもよく、これらのエリアは同じまたは変化するサイズおよび位置であってもよい。配送車７００、７０２は、台車２２２、自動車２２４、または配送を達成するために使用することができる任意の他の車両とすることができる。

積載順序は、積載位置を含んでもよい。位置は、装填ガイドラインによって予め決定されてもよく、またはアドホックに基づいて決定されてもよい。例えば、積載ガイドラインは、全ての配送車が左側から右側へ、及び前側から後側へ積載されることを指示することができる。この例題では、荷物のグループを最初に積み込む方向が配送車内の左端と最前端の位置に荷物のグループを積み込む方向である。別の例として、積載順序は荷物のグループを最初に装填し、それを第１の位置に積載する方向を含むことができる。位置は、配送車の寸法、荷物群の寸法、荷物群が属するブロックエリアなどの複数の要因に基づいて決定されてもよい。位置は例えば、図７Ｂに示されるような位置Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌのうちの１つ、またはそのサブセットであってもよい。例えば、デバイスは荷物の第１のグループが位置Ｈに積み込みされるべきであると決定し、荷物の第２のグループが同様に位置Ｈに積み込みされるべきであると決定することができる。第１のグループの位置は位置Ｈの右半分、位置Ｈの下半分、または位置Ｈの任意の他の分割であってもよく、図７Ｂから理解され得るように、位置Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌは、様々な形状およびサイズであってもよい。荷物群を積載する位置を決定することは、それぞれの荷物の位置に関する情報が荷物が配送されているときに配送作業員またはロボットシステムに提供され得、それによって、配送車内の荷物の位置を突き止めるために必要とされる手間をさらに低減するので、好都合である。本発明から理解されるように、位置は、配送車に対応することができる。

積載順序は、以前に決定された配送ルート、ブロックエリア、またはそれらの組合せに対応することができる。例えば、方法３００のステップ３０９で決定された積載順序は、ステップ３０７で決定された配送ルートに対応することができる。例えば、ルート生成器６１１によって生成された配送順序６１９Ｂに関連するデータは、順序を決定するために使用されてもよい。積載順序は、最初のブロックエリアに配送される荷物が最後に配送車に積載されるように決定されてもよい。配送車内の位置は、決定されたブロックエリアに対応することができる。例えば、図６Ｂに示すように、ルート２ ６１３Ｂは最初にブロックエリア４１１に荷物を配送し、次にブロックエリア４０７に配送荷物し、次に最後にブロックエリア４０５に荷物を配送する。この例の荷物の積載順序はルート４０５の荷物を最初に配送車に積み込み、次にブロックエリア４０７の荷物を積み込み、最後にブロックエリア４１１の荷物を積み込む方向であってもよい。例えば、配送車７０２が配送ルートを実行するために使用される場合、区画４０５に関連する荷物は、ドアから最も遠く、配送車７０２の前部に最も近い位置である位置Ｈに積み込みされてもよい。次いで、ブロックエリア４０７に関連付けられた荷物を、位置Ｇ、すなわち、前に積み込みされた位置（すなわち、位置Ｈ）よりもドアに近い１つの位置である位置、などに積み込むことができる。この順序で荷物を積み込むことの長所は配送車が配送のために外に出たときに、最初に納品される荷物が配送車の扉またはアクセスポイントに最も近い位置に配置されることである。さらに、配送車が配送ルートを下って進み、荷物が配送車から除去されるにつれて、それぞれの後続の配送領域に配送される荷物は、扉または出入り口に最も近くなる。このように、荷物は、それぞれの配送領域において配送車内に荷物を配置する必要性を低減することによって、より効率的に配送され得る。

積載順序は、複数のモジュール式コンテナを配送車に積み込む順序を含み得る。例えば、位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆの各々は各位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆが１つのモジュール式コンテナを受け入れることができるように、モジュール式コンテナ５０１のサイズに対応するサイズであってもよいと考えられる。加えて、または代替として、位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆの各々は様々なサイズであってもよく、各々はモジュラー容器、複数のモジュラー容器、または同様のもの一部分を受容するようにサイズ決定されてもよい。本実施形態の目的のために、位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆの各々は単一のモジュール式コンテナを受容するような大きさであるが、当業者は他の大きさおよび構成が可能であることを認識する。

例えば、ルート１ ６１３Ａの配送順序６１９Ａはルート上の３つの停留所（すなわち、区域４１１、４０７、４０５での停留所）と、ルート上で配送される５つのモジュール式コンテナ（すなわち、モジュール式コンテナ２、３、４、７、８）とを含む。上述のように、好ましい順序は、最初に配送される荷物が最後に積み込みされ、最後に配送される荷物が最初に積み込みされる順序であってもよい。この例ではモジュール式コンテナ２、３はルート１ ６１３Ａによってサービスされる最後のブロックエリアであるブロックエリア４０５に対応するので、積載順序は最初にモジュール式コンテナ２、３を積載することを含むことができる。配送車７００がルート１ ６１３Ａに使用されている場合、モジュール式コンテナ２、３は、ドア７０５Ａ、７０５Ｂから最も離れた位置である位置Ａ、Ｂに積み込まれてもよい。モジュール式コンテナ２、３は同じブロックエリア４０５に関連付けられているので、モジュール式コンテナ２、３の両方が同時に配送されるので、モジュール式コンテナ２が位置Ａまたは位置Ｂに装填されるかどうかは問題にならない。モジュール式コンテナ４は、ルート１ ６１３Ａ上でサービスされるべき最後から２番目のブロックエリアであるブロックエリア４０７に対応するので、次に積み込みされてもよい。位置ＣおよびＤは、ドアから最も遠い空き位置である。上述のように、位置Ｃまたは位置Ｄのいずれかを他方より優先する理由があり得る。例えば、モジュール容器４を位置Ｄに積載することができ、最後に、ルート１ ６１３Ａ上でサービスされる第１のブロックエリアに対応するモジュール容器７、８を配送車７００に積載することができる。この実施形態ではモジュール式コンテナ７、８は位置Ｃおよび位置Ｆに装填されてもよく、本発明によって理解されるように、モジュール式コンテナの使用は複数の荷物または複数のグループの荷物のそれぞれについてではなく、比較的少数のモジュール式コンテナについて積載順序および位置の決定を必要とするという長所を提供する。

積載順序は、積み込み最適化アルゴリズムによって決定されてもよい。積み込み最適化アルゴリズムは、上述のように積載順序を決定してもよい。積み込み最適化アルゴリズムはさらに、貨物エリア内の位置の数、各位置の大きさ、各位置の向き、各位置への荷物またはブロックエリアの写像、それらの組合せなどを含む、配送車内の貨物エリアをどのように分割するかを決定することができる。例えば、積み込み最適化アルゴリズムは、配送車７００の積み込み領域７０３が６つの等しい大きさで整形された位置Ａ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦに最適に分割されることを決定することができる。

上記の例は一群の荷物または複数のモジュール式コンテナのそれぞれを積載する順序を決定することによって積載順序を決定することを論じているが、積載順序を決定することは複数の荷物のそれぞれの荷物を配送車に積載する順序を決定することを含むことができることを理解されたい。例えば、積載順序を決定することは、第１のブロックエリアに対応するそれぞれの荷物がそのブロックエリアに関連付けられた配送車内の位置に装填されるべき順序を決定することを含んでもよい。この決定は、上述したのと実質的に同じ方法で実行することができる。

積載順序またはそれに関連するデータは、ネットワークまたは外部システム内の他のシステムに送信され、格納され、同じまたは異なるシステムによってさらに処理され、デバイス上に表示され、またはそれらの組合せであってもよい。例えば、配送注文はモバイルデバイス１０７Ａまたはモバイルデバイス１１９Ａなどのデバイス上に表示され、作業員は積載注文に従って配送車を積載することができる。他の例として、積み込みオーダデータは更なるプロセスのために、ＷＭＳ １１９、ＦＯシステム１１３、ＳＡＴシステム１０１、出荷および注文追跡システム１１１等に送信されてもよい。別の例として、積載順序に関するデータは、積載順序に従って配送車を積載するように構成されたロボットシステムに送信されてもよい。

本開示と一致して、積載順序データは、積載順序の視覚的表現を表示するためのデバイスのための命令を生成するためにさらに処理され得る。積載順序の視覚的表現は、作業員またはロボットシステムが積載順序に従って配送車を積載することを可能にし得る任意の視覚的表現を含み得る。例えば、視覚的表現は、積載順序のテキスト記述、積載順序に従って配送車を積載するためのテキスト方向、配送車がどのように装填されるべきかを識別するグラフまたはテーブル、視覚化された装填マップ、それらの組合せなどを含むことができる。視覚化された積載マップは、配送車のダイアグラムまたはマップと、配送車内の複数の位置とを含むことができる。例えば、視覚化された積載マップは配送車の上面図を含むことができ、積載順序に関連して決定されたそれぞれの位置の位置を含むことができる。例えば、視覚化された積載マップは、図７Ａの配送車７００の図と実質的に同様に見える。視覚化された積載マップは、配送車の図における荷物、荷物群、複数の荷物識別子、モジュール式コンテナ、またはそれらの組合せを示す図をさらに含むことができる。また、視覚化された積み込みマップは、３次元であってもよいことが企図される。すなわち、図７Ａに描かれた上面図に限定されるのではなく、可視化された積載マップは複数の異なった向きから、積載領域７０３、積載領域７０３を有する位置、及びその中に積載される荷物を表示することができる。視覚化された装填マップは、配送車に装填される複数の荷物、荷物のグループ、またはモジュール式コンテナのそれぞれの位置を含むことができる。

図８Ａは積載順序の視覚的表現を含む例示的プリントアウトの図であり、視覚的表現は、複数のモジュール式コンテナが配送車に積載される位置を示すテーブル８０１と、配送車を積載するための文字方向８０３との両方を含む。明確にするために、テーブル８０１に含まれるデータおよびテキスト方向８０３は、図７Ａおよび図７Ｂに示される位置Ａ〜Ｌ、図６Ａの配送データ６０１に含まれるようなモジュール式コンテナ１〜９、および図６Ｂに示されるような配送順序６１９Ａ、６１９Ｂなどの先行例に対応する。上述し、表８０１に示すように、配送順序６１９Ａについて、モジュール式コンテナ２は位置Ａに装填され、モジュール式コンテナ３は位置Ｂに装填され、モジュール式コンテナ７は位置Ｃに装填され、モジュール式コンテナ４は位置Ｄに装填され、位置Ｅには何も装填されず、モジュール式コンテナ８は位置Ｆに装填される。表８０１はこのことを報告し、テキスト方向８０３は、決定された積載順序に従ってモジュール式コンテナを配送車に積載するための一連のステップを記述する。図８Ａはテーブルとテキスト記述８０３の両方を示しているが、テーブル８０１またはテキスト記述８０３のいずれかだけで、積載順序をロボットシステムまたは作業員に伝達することができる。図８Ａはプリントアウト８００上の視覚的表現を示すが、視覚的表現はデバイス上、仮想空間内、または任意の他のモダリティ上に表示され得ることが理解される。

図８Ｂは、積載順序の視覚的表現の例示的な表示を提供する。視覚的表現は、デバイス８１０上に表示される。デバイス８１０は例えば、コンピュータ、ＰＤＡ、モバイルデバイス、またはディスプレイを備えた他のデバイスとすることができる。例えば、デバイス８１０は、デバイス１０７Ａ、１０７Ｂ、１０７Ｃ、または別のデバイスのいずれかであってもよい。デバイス８１０は、システム１００および他のデバイス内のシステムとの間でデータを送受信するように構成され得ることが企図される。例えば、デバイス８１０は輸送システム１０７によって生成された命令を受信し、それに応答して視覚的表現を表示することができる。別の例では、デバイス８１０が例えば、デバイス８１０上に表示される視覚表現に関する情報、デバイス８１０上の入力などを含むデータをＷＭＳ １１９に送信することができる。デバイス８１０のディスプレイはタッチスクリーン８１２として表されるが、ディスプレイは当技術分野で知られている任意のディスプレイとすることができる。タッチスクリーン８１２は、３つの主要表示領域、グラフィック表示領域８１１、タスクバー８１３、およびタスク表示領域８１９を有するものとして描かれている。タッチスクリーン８１２の構成は、例示的なものにすぎず、積載順序の１つまたは複数の視覚的表現を表示するように構成された任意の１つまたは複数の領域を有することができることを理解されたい。例えば、タッチスクリーン８１２は、対話型３次元視覚化積み込みマップを表示するように構成された単一の表示領域を有することができる。

タスクバー８１３は、ディスプレイ領域８１１および８１９の各々に表示されるものを制御するための主要な手段であってもよい。タスクバー８１３は、複数のタスク間をナビゲートするための手段を含むことができる。例えば、タスクバー８１３は、ユーザが上下のナビゲーション矢印８１７に触れると、保留中のタスクのリストをナビゲートするように構成されたナビゲーション矢印８１７を含むことができる。タスク間をナビゲートするための手段は、ドロップダウンメニュー、スクロールバー、音声起動ナビゲータなどの、当技術分野で知られている任意の他の手段を含むことができる。タスクバー８１３は、選択されたタスクのアイデンティティを表示するように構成され得るタスク選択領域８１５を含み得る。タスクバー８１３は、デバイス８１０のディスプレイ上のどこに配置されてもよく、または完全に省略されてもよいことが理解される。例えば、タスクバー８１３は、完全に省略されてもよく、デバイス８１０は上述のように、分類および積載順序を最適化するためにシステムによって生成された命令を受信することに応答して、タスクを自動的に表示するように構成されてもよい。グラフィック表示領域８１１およびタスク表示領域８１９は、積載順序の任意の視覚的表現を表示するように構成され得る。例えば、グラフィック表示領域８１１は、配送車の概略図、配送車を搭載するためのテキスト指示、または本明細書で開示される任意の他の視覚的表現を表示することができる。タスク表示領域８１９は、実質的に同様の情報を含むことができる。いくつかの実施形態では、タスク表示領域８１９がタスクの対話型表示を含むことができ、作業員またはロボットシステムが決定された積載順序に従って配送車を積載することを確実にするように構成することができる。

図８（ｂ）に示す例では、タスク選択領域８１５に、選択されたタスク「配送車１の積載」が表示されている。図８Ｂに関連して上述したように、選択されたタスクは、本明細書の他の例で生成され、図６Ｂに示される情報に対応する。グラフィック表示領域８１１は、図７Ａの配送車７００に対応する、配送車１の概略図を表示することができる。回路図は、配送車の荷物領域内の複数の位置を含む。タスク表示領域８１９内の表示は、タスク選択領域８１５内に表示されるタスク選択と同様に対応する。タスク領域８１９内のディスプレイは、決定された積載順序に従って配送車を積載するための複数のステップを含む。これらのステップは、図８Ａおよびテキスト方向８０３に関連して上述したものに対応する。ステップは、タスクの性能を監視する複数のインジケータ８２１、８２３、８２５を伴う。ブランクインジケータ８２３は、デフォルトインジケータであってもよく、タスクのステップがまだ完了していないことをシグナリングしてもよい。各ステップのインジケータは、タスクの開始前にブランクインジケータ８２３であってもよいことが企図される。空白インジケータ８２３は、図８Ｂに示される空のボックスのような中立位置を示す記号、または中立表現を有する絵文字などであってもよい。完全なインジケータ８２１は、タスクのステップが完了したことを知らせるインジケータであってもよい。完了インジケータ８２１はブランクインジケータ８２３の修正バージョンであってもよいし、タスクの完了を示すブランクインジケータ８２３のシンボルとは異なるシンボルであってもよい。例えば、完全インジケータ８２１は、図８Ｂに示されるチェックマークされたボックス、または関連付けられたまたは達成された表現を有する絵文字などであり得る。作業員は例えば、インジケータを押す又は選択することによって、作業の段階が完了すると、空白のインジケータ８２３を完全なインジケータ８２３に変更することができると考えられる。インジケータは、ステップの完了時に自動的に変化するように構成されてもよいことも企図される。例えば、複数のセンサまたはカメラシステムはタスクを監視し、タスクが完了したときにデバイス８１０に信号を送信するように構成されてもよく、次いで、デバイス８１０は、ブランクインジケータ８２３を完了インジケータ８２１に変更するように構成されてもよい。エラーインジケータ８２５は、タスクのステップが間違って完了したこと、または間違った順序で完了したことを知らせるインジケータであってもよい。エラー・インジケータ８２５はブランクインジケータ８２３の修正バージョンであってもよいし、タスクの誤った完了を示すブランクインジケータ８２３のシンボルとは異なるシンボルであってもよい。例えば、エラーインジケータ８２５は、図８Ｂに示される「Ｘ」印のボックス、または悲しい表現を有する絵文字などであり得る。エラーインジケータ８２５は、作業員が決定された積載順序と順序が異なる順序でインジケータに触れるか、またはインジケータを選択した場合に表示され得ることが企図される。例えば、作業員がモジュール式コンテナ７を位置Ｃに積載する前に、モジュール式コンテナ８を位置Ｆに積載する場合、作業表示領域８１９は、誤差インジケータ８２５を表示するように構成されてもよい。また、センサまたはカメラシステムは配送車の積載を監視し、配送車が誤って積載された場合に、エラーインジケータ８２５を表示するための命令を自動的に生成してもよいと考えられる。エラー・メッセージは、エラー・インジケータ８２５に関連して表示することができると考えられる。例えば、エラーインジケータ８２５が表示されるとき、エラーメッセージ８２７は、実質的に同時に表示されてもよい。エラーメッセージ８２７は、エラーのテキスト記述など、エラーインジケータ８２５の理由の視覚的表現を含むことができる。エラーメッセージ８２７が表示されている間、タスク表示領域８１９はエラーが解決されない限り、またはエラーが解決されるまで、さらなるアクションを禁止するように構成され得ることが企図される。図８Ｂに示される例は例示的なものにすぎず、デバイスは本発明と一致する任意の手段によって、積載順序の視覚的表現をディスプレイするように構成され得ることが理解される。

本発明によれば、荷物の分類及び積み込みを最適化するためのデバイスは、決定された配送ルートに関する情報を表示するための命令を生成するように構成されてもよい。命令はデバイスに送信されてもよく、配送ルートの視覚的表現は、図８Ｂに関連して説明されたのと実質的に同じ方法で表示されてもよい。例えば、タスク選択領域８１５に表示され得るタスクの１つは「ルート１上の配送荷物」であってもよく、グラフィック表示領域８１１およびタスク表示領域８１９内の表示は決定された配送ルートに関する情報を表示してもよい。例えば、図形表示エリア８１１は図４の地理的エリア４００に対応することができる配送ルートの地図を表示することができ、作業表示エリア８１９は、図６Ｂの配送順序６１９Ａに対応するステップを含む、配送を達成するためのテキスト方向を表示することができる。

本発明によれば、荷物の分類および積み込みを最適化するためのデバイスは、決定された積載順序の視覚的表現のディスプレイからのインプットに応じて、本明細書に開示された方法およびプロセスを実行するように構成されてもよい。例えば、上述したように、視覚化された積み込みマップがデバイスに表示され、作業員がシステムによって決定された順序とは別の順序で荷物を配送すると決定した場合、作業員はルートに変更を加えることができ、システムは、変更に関するインプットを受け取ることができる。次に、デバイスは例えば、変更された配送ルートと一致する新しい積載順序を決定し、変更と一致する新しい視覚化された積み込みマップをディスプレイするための命令を生成するために、方法３００のステップを繰り返すことができる。同様の調整は、方法３００の任意のステップで行うことができる。例えば、作業員はステップ３０３で決定されたブロックエリアを、例えば、ブロックエリアの大きさ、寸法などを変更することによって、または第１のブロックエリアを第２のブロックエリアと組み合わせることによって変更することができ、次いで、システムは変更と一致する積載順序を決定するために、方法３００の残りのステップを実行することができ、以下同様である。

本発明によれば、積載順序の視覚的表現は、複数の荷物の配送中に使用することができる。例えば、視覚化された積み込みマップを表示するための命令は配送作業員が視覚化された積み込みマップを見ることができるように、デバイスに配送されてもよい。作業員は、デバイスのディスプレイ上の視覚化された装填マップを見て、配送される荷物または荷物群の位置を見て、配送車内の荷物を手動で分類または走査する必要なく、荷物を容易に見つけることができる。例えば、配送作業員は例えば、輸送デバイス１０７によって決定されたルートを配送荷物するように促されてもよい。配送を実行している間、作業員は、例えば作業表示領域８１９に本配送のステップの表示を含むデバイス８１０のようなデバイスを有することができる。作業員が第１のブロックエリアのような第１の配送領域に近づくと、デバイスは例えば、グラフィックディスプレイ８１１上の視覚化された積み込みマップにおいて、その配送領域に配送される荷物の位置を表示することができる。作業員は、このインフォメーションを使用して、領域に配送される荷物を迅速かつ容易に突き止めることができる。作業員は例えば、荷物が配置されたとき、および／またはそれらが配送されたときに、それらに添付されたバーコードをスキャンすることによって、荷物が配置または配送されたことを示すインプットをデバイス８１０に提供してもよい。次いで、デバイス８１０は次の配送をディスプレイするようにアップデートすることができ、以下同様である。これは、従来技術に勝る明確な利点を提供する。

本開示はその特定の実施形態を参照して示され、説明されてきたが、本開示は修正なしに、他の環境において実施され得ることが理解されるのであろう。前述の説明は、例示の目的で提示されている。これは、網羅的ではなく、開示された正確な形態または実施形態に限定されない。当業者には、開示された実施形態の明細書および実施を考慮することによって、修正および適合が明らかになるのであろう。加えて、開示された実施形態の態様はメモリに格納されるものとして説明されているが、当業者はこれらの態様が例えばハードディスクまたはCD ROM、あるいは他の形態のＲＡＭまたはＲＯＭ、ＵＳＢ媒体、ＤＶＤ、ブルーレイ、または他の光学ドライブ媒体などの二次記憶デバイスなどの他のタイプのコンピュータ可読媒体に格納され得ることを理解するのであろう。

記載された説明および開示された方法に基づくコンピュータプログラムは、熟練した開発者の技術の範囲内である。様々なプログラムまたはプログラムモジュールを、当業者に知られている技法のいずれかを使用して作成することができ、または既存のソフトウェアに関連して設計することができる。例えば、プログラム・セクションまたはプログラムモジュールは、.Net Framework、.Net Compact Framework (およびVisual Basic、Ｃ などの関連言語）、Java、C++、Objective-C、HTML、HTML/AJAXの組み合わせ、XML、またはJavaアプレットを含むＨＴＭＬの中で、または手段によって設計され得る。

さらに、例示的な実施形態が本明細書で説明されてきたが、本開示に基づいて当業者によって理解されるように、同等の要素、修正、省略、組み合わせ（例えば、様々な実施形態にわたる態様の）、適応、および／または変更を有する任意のおよびすべての実施形態の範囲。クレームの限定はクレームに使用されている文言に広く基づいて解釈されるものとし、本明細書に記載されている例に限定されるものではなく、又は出願手続中に解釈されるものとする。実施例は、非排他的であると解釈されるべきである。さらに、開示された方法のステップは、ステップを並べ替えること、および／またはステップを挿入または削除することを含む、任意の方法で修正されてもよい。したがって、本明細書および実施例は単に例示的なものとみなされ、真の範囲および精神は以下の特許請求の範囲およびそれらの均等物の全範囲によって示されることが意図される。

Claims (20)

1. 荷物の分類および積み込みを最適化するためのコンピュータ実装システムであって、
   命令を記憶するメモリと、
   前記命令を実行して動作を実行するように構成された少なくとも１つのプロセッサと、
   を備え、
   当該動作は、複数の荷物に関連付けられた複数の荷物識別子を含むデータを受信すること、
   前記データに基づいて、複数の荷物の配送位置に関連する複数のブロックエリアを決定すること、
   ルートの第１のセットを決定し、当該ルートの第１のセットの各々に対する入力の最適な組合せを決定するために当該ルートの第１のセットを変換し、各変換されたルートに関連するブロックエリアの順序を交換することによって最短ルートを決定することによって、複数の荷物を配送するための順序を含む配送ルートを決定すること、
   配送ルートに基づいて複数の荷物の各々を配送車に積載する積載順序を決定すること、
   当該決定された積載順序の視覚的表現をディスプレイするデバイスのための命令を生成すること
   を含むコンピュータ実装システム。
2. 前記動作はさらに、
   前記複数の荷物の各荷物を、荷物の複数のグループのうちの１つに分類することを含み、各グループは前記複数のブロックエリアのうちの１つに対応し、
   前記積載順序を決定することは、前記グループの各々を前記配送車に積載する順序、または前記グループの各々を積載する前記配送車内の位置のうちの少なくとも１つを決定することを含む
   請求項１に記載のシステム。
3. 前記動作はさらに、
   前記複数の荷物の各荷物を、モジュール式コンテナ内の１つ以上の区画に分類することを含み、各区画は前記複数のブロックエリアのうちの１つに対応し、
   積載順序を決定することは、複数のモジュール式コンテナを前記配送車に積載する順序を決定することと、各モジュール式コンテナを積載する前記配送車内の位置を決定することを含む
   請求項１に記載のシステム。
4. 前記複数のブロックエリアを決定することは、
   複数の荷物が配送される地理的エリアを決定すること、及び
   少なくとも１つの荷物が配送される地理的エリア内の１つ以上の破壊不能エリアを決定することを含み、それぞれの破壊不能エリアが１つのブロックエリアを表す
   請求項１に記載のシステム。
5. 前記複数のブロックエリアを決定することは、
   配送される複数の荷物に関連する１つ以上の郵便番号を決定すること、及び
   荷物のグループが配送される郵便番号によって表される地理的エリア内の１つ以上のエリアを決定することを含み、それぞれのエリアは１つのブロックエリアを表す
   請求項１に記載のシステム。
6. 配送ルートを決定することは、履歴データ、効率優先、資源データ、地理的データ、または配送データのうちの１つまたは複数に基づいて、複数の荷物をそれぞれのブロックエリアに配送するための順序を決定することを含む
   請求項１に記載のシステム。
7. 前記動作はさらに、
   生成された命令を前記デバイスに送信することを含み、
   当該デバイスは前記命令を受け取ると、前記積載順序の視覚的表現を表示し、前記視覚的表現は、前記配送車の視覚化された積載マップと、前記複数の荷物のそれぞれの荷物に対する位置とを含む、
   請求項１に記載のシステム。
8. 積載順序を決定することは、複数の荷物のそれぞれの荷物に対する配送車内の位置を決定することを含む
   請求項１に記載のシステム。
9. 荷物の分類および積み込みを最適化するためのコンピュータ実装方法であって、
   複数の荷物に関連付けられた複数の荷物識別子を含むデータを受信すること、
   前記データに基づいて、複数の荷物の配送位置に関連する複数のブロックエリアを決定すること、
   ルートの第１のセットを決定し、当該ルートの第１のセットの各々に対する入力の最適な組合せを決定するために当該ルートの第１のセットを変換し、各変換されたルートに関連するブロックエリアの順序を交換することによって最短ルートを決定することによって、複数の荷物を配送するための順序を含む配送ルートを決定すること、
   配送ルートに基づいて複数の荷物の各々を配送車に積載する積載順序を決定すること、及び
   当該決定された積載順序の視覚的表現をディスプレイするデバイスのための命令を生成すること、
   を含むコンピュータ実装方法。
10. 前記複数の荷物の各荷物を複数の荷物グループのうちの１つに分類することを含み、各グループは前記複数のブロックエリアのうちの１つに対応し、
    前記積載順序を決定することは、前記グループの各々を前記配送車に積載する順序を決定すること、及び前記グループの各々を積載する前記配送車内の位置を決定することを含む
    請求項９に記載の方法。
11. 前記複数の荷物の各荷物を、モジュール式コンテナ内の１つ以上の区画に分類することを含み、各区画は前記複数のブロックエリアのうちの１つに対応し、
    積載順序を決定することは、複数のモジュール式コンテナを前記配送車に積載する順序を決定すること、及び各モジュール式コンテナを積載する前記配送車内の位置を決定することを含む
    請求項９に記載の方法。
12. 複数のブロックエリアを決定することは、
    複数の荷物が配送される地理的エリアを決定すること、及び
    少なくとも１つの荷物が配送される地理的エリア内の１つまたは複数の破壊不能エリアを決定することを含み、それぞれの破壊不能エリアが１つのブロックエリアを表す
    請求項９に記載の方法。
13. 配送ルートを決定することは、履歴データ、効率優先、資源データ、地理的データ、および配送データのうちの１つまたは複数に基づいて、複数の荷物をそれぞれのブロックエリアに配送するための順序を決定することを含む
    請求項９に記載の方法。
14. 前記生成された命令をデバイスに送信することをさらに含み、当該デバイスは、命令を受信すると、積載順序の視覚的表現を表示する
    請求項９に記載の方法。
15. 前記積載順序の視覚的表現が前記配送車の可視化された積載マップを含み、当該可視化された積載マップが、前記複数の荷物の各々の荷物に対する位置を含む
    請求項９に記載の方法。
16. 積載順序を決定することは、前記複数の荷物のそれぞれの荷物に対する前記配送車内の位置を決定することを含む
    請求項９に記載の方法。
17. 荷物の分類および積み込みを最適化するためのシステムであって、
    メモリとプロセッサとで構成されるコンピュータ実施システムであって、プロセッサに動作を実行させる命令を記憶するメモリであって、当該動作は、
    複数の荷物に関連付けられた複数の荷物識別子を含むデータを受信すること、
    前記データに基づいて、複数の荷物の配送位置に関連する複数のブロックエリアを決定すること、
    ルートの第１のセットを決定し、ルートの第１のセットを変換して、ルートの第１のセットの各々に対する入力の最適な組合せを決定し、各変換されたルートに関連するブロックエリアの順序を交換することで最短ルートを決定することによって、複数の荷物を配送するためのエリア順序を含む配送ルートを決定すること、
    前記配送ルートに基づいて複数の荷物の各々を配送車に積載する積載順序を決定することと、
    前記積載順序の視覚的表現を表示するための命令を生成することと、
    前記命令を送信することと、
    を含みコンピュータ実施システムと、
    前記送信された命令を受信すること、及び前記決定された積載順序に従って複数の荷物を分類すること、を含む動作を実行するように構成された分類デバイスと、
    前記送信された命令を受信すること、及び前記積載順序の視覚的表現を表示すること、を含む動作を実行するように構成された積載デバイスと、
    を備えるシステム。
18. 積載順序を決定することは、複数のモジュール式コンテナを配送車に積載する順序を決定することと、各モジュール式コンテナを積載する配送車内の位置を決定することとを含み、複数の荷物を分類することは複数のモジュール式コンテナ内の１つまたは複数の区画内の複数の荷物の各荷物を分類することを含み、各区画は複数のブロックエリアのうちの１つに対応する
    請求項１７に記載のシステム。
19. 前記視覚的表現は、視覚化された積載マップを含み、当該視覚化された積載マップは、前記複数の荷物のそれぞれの荷物について、前記配送車の前記貨物エリアまたは前記貨物エリア内の位置のうちの少なくとも１つを描写する
    請求項１７に記載のシステム。
20. 前記積載デバイスは、前記視覚的表現をプリントすることによって、前記視覚的表現を１つ以上のモバイルデバイスに送信することによって、前記視覚的表現をスクリーン上に表示することによって、またはそれらの組合せによって、前記視覚的表現を表示するように構成される、請求項１７に記載のデバイス。

Images