JP2022509900A - 単一の顧客に対する分割配送を自動マージするためのシステムおよび方法 - Google Patents

Abstract

開示された実施形態は、一般に、配送ウェーブスケジューリングのための、コンピュータ化されたシステムを対象としている。方法は、複数の製品と、関連付けられた識別子とを含む注文情報を、リモートシステムから受信することと、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品の各製品に対して、フルフィルメントセンタを判定し、複数の配送ウェーブから配送ウェーブを判定することと、製品に関連付けて、判定された配送ウェーブをデータベースに格納することと、少なくとも１つの配送ウェーブが、後の配送ウェーブよりも早い期間に関連付けられていると判定することとを含み、判定することに応じて、もともと、前の配送ウェーブに関連付けられていた製品を後の配送ウェーブに関連付けるために、データベースを修正することと、製品、および第２の配送ウェーブに関連付けられた情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイスに転送することとを少なくとも含んでもよい。

Description

本開示は、一般に、荷物配送の自動再スケジュールのための、コンピュータ化されたシステムおよび方法に関する。特に、本開示の実施形態は、複数のサブシステムからのデータの集まりに基づいて、物流管理システムを通じて電子注文情報を分析して、分割配送を単一の配送に統合することができる場合を判定して、このような判定の際に、配送を自動的に再スケジュールする、発明的な非従来型のシステムに関する。

コンピュータ技術の進歩および普及に伴い、ｅコマースとしても知られるオンラインショッピングは、商取引の主要な手段の１つになった。消費者および企業はかつてないほど頻繁にオンラインベンダから商品を購入しており、取引数および売上高は前年比で驚異的なペースで増加すると予測されている。ｅコマースの範囲および取引量が増加し続けるにつれて、オンラインで購入可能な異なる製品の数と、特定の期間に行われた平均購入数との両方が急激に増加している。例えば、ある人気のオンライン小売業者が販売する異なる製品の数は６億製品を超え、同じ小売業者が１日に出荷する荷物の数は１６０万個を超えていると言われている。

各オンライン購入では、本質的に、購入された商品を意図する受取人に配送する必要がある。各オンライン購入またはオンライン注文は、一般的に、１つ以上の商品を含み、１つ以上の商品は、各々が独自の約束配送日を持つ１つ以上の荷物に梱包される場合がある。一般的な注文は、１つ以上の商品を求める注文を顧客から受信することと、在庫から１つ以上の商品を取り出すことと、１つ以上の商品を１つ以上の荷物に梱包することと、約束配送日の前に、１つ以上の荷物を意図する受取人に配送することとのようなステップを通じて処理してもよい。約束配送日は、小売業者自身もしくは出荷業者が設定してもよいし、または顧客が特定の日付を要求して、その後約束配送日として割り当ててもよい。注文処理の理想的なシステムは、約束配送日までに各荷物を意図する受取人に間違いなく配送する。

注文処理システムは、場合によっては、「ウェーブ（wave）プロセス」を使用して動作してもよく、このプロセスでは、製品が、特定の期間の１つ以上のウェーブの間に指定されたエリアに配送されるようにスケジュールされる。例えば、ウェーブ配送は、特定のエリア（例えば、サブルートを含むルート）の周りの荷物の第１のウェーブを１日１回含み、次に、その日の、より遅い時間における同じエリアへの荷物の第２のウェーブを含んでもよい。このプロセスは、製品が、異なるエリアの１つ以上のシフトで配送される（例えば、２つのシフトが、指定されたエリアの半分を２つ分カバーする）「シフトプロセス」の代替手段として使用され得る。「ウェーブプロセス」は、「シフトプロセス」と比べて、特定の利点をもたらすことができる。例えば、「ウェーブプロセス」は、優れたエリアカバー率を提供して、他の方法では配送が利用できない特定のエリアへの配送を可能にすることができる。しかしながら、「ウェーブプロセス」は１日に複数回同じエリアをカバーすることができるので、このプロセスを利用すると、１日に１回の配送しか必要ない場合に、１日に複数回同じ場所に製品を配送して、費用が大幅に増加する場合がある。

現在の既存のコンピュータ化された注文処理システムは、前述のステップを実装する際に様々な程度の自動化および複雑さを含んでいる。しかしながら、異なる商品および注文の数が増えるにつれ、注文はサブシステムの複雑なネットワークを経由する必要があること、および一部の注文には部分的な返品などの複雑な要素があることによって悪化していて、現在のシステムは、費用を削減するために、同じ受取人への複数の配送を１つに統合する（すなわち、注文内のすべての荷物が、複数のウェーブではなく単一のウェーブで意図する受取人に配送される）ことができる場合を判定することが不可能、または大幅に非効率的である点で問題がある。

したがって、１回の配送しか必要ない場合に、複数回同じ場所に製品を配送することに起因する費用を削減するために、複数の配送ウェーブにわたる複数の荷物の配送を、単一のウェーブに自動統合するための改善された方法およびシステムが必要である。

本開示の一態様は、配送ウェーブスケジューリングのための、コンピュータ化されたシステムを対象としている。システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサにステップを実行させる命令を含む少なくとも１つの非一時的記憶媒体とを備え、ステップが、複数の製品と関連付けられた識別子とを含む注文情報を、リモートシステムから受信することと、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品の第１の製品に対して、フルフィルメントセンタを決定（判定）し、複数の配送ウェーブから第１の配送ウェーブを決定（判定）することと、第１の製品に関連付けて、第１の配送ウェーブをデータベースに格納することと、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品のうちの第２の製品に対して、フルフィルメントセンタを決定（判定）し、複数の配送ウェーブから第２の配送ウェーブを決定（判定）することであって、第２の配送ウェーブが第１の配送ウェーブとは異なる、ことと、第２の製品に関連付けて、第２の配送ウェーブをデータベースに格納することと、第１の配送ウェーブが、第２の配送ウェーブよりも早い期間に関連付けられていると判定することとを含み、判定することに応じて、第１の製品を第２の配送ウェーブに関連付けるために、データベースを修正することと、第１の製品、および第２の配送ウェーブに関連付けられた情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイスに転送することとを含んでもよい。

本開示の別の態様は、配送ウェーブスケジューリングのための、コンピュータによって実装される方法を対象としている。方法は、複数の製品と関連付けられた識別子とを含む注文情報を、リモートシステムから受信することと、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品の第１の製品に対して、フルフィルメントセンタを決定（判定）し、複数の配送ウェーブから第１の配送ウェーブを決定（判定）することと、第１の製品に関連付けて、第１の配送ウェーブをデータベースに格納することと、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品のうちの第２の製品に対して、フルフィルメントセンタを決定（判定）し、複数の配送ウェーブから第２の配送ウェーブを決定（判定）することであって、第２の配送ウェーブが第１の配送ウェーブとは異なる、ことと、
第２の製品に関連付けて、第２の配送ウェーブをデータベースに格納することと、第１の配送ウェーブが、第２の配送ウェーブよりも早い期間に関連付けられていると判定することとを含み、判定することに応じて、第１の製品を第２の配送ウェーブに関連付けるために、データベースを修正することと、第１の製品、および第２の配送ウェーブに関連付けられた情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイスに転送することとを含んでもよい。

本開示のさらに別の態様は、配送ウェーブスケジューリングのための、コンピュータ化されたシステムを対象としている。システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサにステップを実行させる命令を含む少なくとも１つの非一時的記憶媒体とを備えステップが、複数の製品と関連付けられた識別子とを含む注文情報を、リモートシステムから受信することと、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品の第１の製品に対して、フルフィルメントセンタを決定（判定）し、複数の配送ウェーブから第１の配送ウェーブを決定（判定）することであって、第１のウェーブが条件と関連付けられていることと、第１の製品に関連付けて、第１の配送ウェーブをデータベースに格納することと、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品のうちの第２の製品に対して、フルフィルメントセンタを決定（判定）し、複数の配送ウェーブから第２の配送ウェーブを決定（判定）することであって、第２の配送ウェーブが、第１の配送ウェーブに関連付けられた期間とは異なる期間に関連付けられることと、第２の製品に関連付けて、第２の配送ウェーブをデータベースに格納することと、第１のウェーブに関連付けられた期間と、第２のウェーブに関連付けられた期間とが同じウェーブ期間の間に発生すると判定することと、第１の配送ウェーブが、第２の配送ウェーブよりも早い期間に関連付けられていると、および第２の配送ウェーブが、条件を満たしていない第２の製品に基づいて決定（判定）されたと判定することであって、この判定することに応じて、第２の製品を第１の配送ウェーブに関連付けるために、データベースを修正すること、および第１の配送ウェーブに関連付けられた、第２の製品および情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイスに転送することとを含んでもよい。

他のシステム、方法、およびコンピュータ可読媒体も、本明細書で説明する。

開示された実施形態に一致する、出荷、輸送、および物流オペレーションを可能にする通信のための、コンピュータ化されたシステムを備えるネットワークの例示的な実施形態を示す概略ブロック図である。 開示された実施形態に一致する、対話型ユーザインタフェース要素と共に検索要求を満たす１つ以上の検索結果を含む例示的な検索結果ページ（ＳＲＰ）を示す図である。 開示された実施形態に一致する、対話型ユーザインタフェース要素と共に製品および製品に関する情報を含む例示的な単一ディスプレイページ（ＳＤＰ）を示す図である。 開示された実施形態に一致する、対話型ユーザインタフェース要素と共に仮想ショッピングカート内の商品を含む例示的なカートページを示す図である。 開示された実施形態に一致する、対話型ユーザインタフェース要素と共に、購入および出荷に関する情報と共に仮想ショッピングカートからの商品を含む例示的な注文ページを示す図である。 開示された実施形態に一致する、開示されたコンピュータ化されたシステムを利用するように構成された例示的なフルフィルメントセンタの概略図である。 開示された実施形態に一致する、フルフィルメント最適化（ＦＯ）システムによってアクセス可能なデータベースの例示的な実施形態を示すブロック図である。 開示された実施形態に一致する、分割配送を統合するために実行されてもよい例示的なマージプロセスを示すフローチャートである。 開示された実施形態に一致する、分割配送をマージするために実行されてもよい詳細かつ例示的なマージプロセスを示すフローチャートである。 開示された実施形態に一致する、同じウェーブで配送されるべきであると判定された際に、複数の製品の配送を再スケジュールするために実行されてもよい例示的なプロセスの図である。 開示された実施形態に一致する、荷物の配送が別のウェーブに再スケジュールされるべきであると判定された際に、荷物ラベルを印刷および交換するために実行されてもよい例示的なプロセスを示すフローチャートである。 開示された実施形態に一致する、製品の配送が異なるウェーブに再スケジュールされた後のウェーブの間に製品の配送を防止するために実行されてもよい例示的なプロセスを示すフローチャートである。 開示された実施形態に一致する、配送を再スケジュールするために、データベースに格納された製品情報をどのように修正することができるかを示す図である。

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

本開示の実施形態は、分割配送を単一の顧客に自動マージするために構成されたシステムおよび方法を対象としている。具体的には、開示された実施形態は、１回の配送しか必要ない場合に、複数回同じ場所に製品を配送することに起因する費用を削減するために、複数の配送ウェーブにわたる複数の荷物の配送を、単一のウェーブに統合することを対象とする。

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

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

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

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

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

外部フロントエンドシステム１０３がその情報に基づいてＳＲＰ(例えば、図１Ｂ）を準備することができる。ＳＲＰは、検索要求を満たす情報を含むことができる。例えば、これは、検索要求を満たす製品の写真を含むことができる。ＳＲＰはまた、各製品についてのそれぞれの価格、または各製品についての強化された配送オプション、ＰＤＤ、重み、規模、オファー、割引などに関する情報を含んでもよい。外部フロントエンドシステム１０３は（例えば、ネットワークを介して）要求側ユーザデバイスにＳＲＰを送信することができる。

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

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

依頼元ユーザデバイスは、商品情報を記載したＳＤＰを受け取る場合がある。ＳＤＰを受信すると、ユーザデバイスはＳＤＰと対話することができる。例えば、要求ユーザデバイスのユーザは、ＳＤＰ上の「カートに入れる」ボタンをクリックするか、あるいは他の方法で対話することができる。これは、ユーザに関連付けられたショッピングカートに製品を追加する。ユーザデバイスはこのリクエストを送信して、商品をショッピングカートに追加し、外部フロントエンドシステム１０３に送ることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さらに、開示された配送システムは、異なる配送プロセスまたは異なる配送パラダイムで動作してもよい。例えば、システムは、「ウェーブプロセス」、「シフトプロセス」、またはそれらの組み合わせを使用して動作してもよい。ウェーブプロセスは、異なる時間の配送のウェーブに配送を調整してもよい。例えば、ウェーブ配送は、特定のウェーブ期間（例えば、１日）の間に数回、指定されたエリア（例えば、サブルートを含むルート）周辺の荷物の第１のウェーブを含んでもよい。対照的に、シフトプロセスは、異なるエリアへの配送を調整して、最初に特定のエリアの一部（例えば、５０％）に配送して、後の配送で、特定のエリアの残りの部分に配送してもよい。開示されたシステムおよび方法は、配送プロセスに対する最適化パラメータに基づいて、ルートおよび作業員スケジュールを再構成するように構成可能であってもよい。

いくつかの実施形態では、「ウェーブプロセス」で動作する配送システムは、特定のウェーブ期間の間の複数のウェーブのうちの１つの間に、特定の配送エリア内の顧客への荷物の配送を提供してもよい。例えば、配送作業員は、配送エリアに対応するルートまたはサブルートに沿って、午前ウェーブの間、および午後ウェーブの間に再度、意図する受取人に荷物を配送してもよい。各ウェーブは、受付終了時刻とＰＤＤとの両方に対応してもよい。受付終了時刻は、通常、出荷するオンライン注文に対応し、特定のウェーブ、または注文のＰＤＤに関連付けられた時刻であって、顧客が、ウェーブ、もしくはウェーブに関連付けられたＰＤＤを利用できなくなる時刻であってもよい。言い換えれば、顧客が受付終了時刻より前に荷物を注文しなかった場合、その受付終了時刻に関連付けられたＰＤＤで商品を受け取ることができなくなり、次に利用可能なＰＤＤでのみ商品を受け取ることができる。

「ウェーブプロセス」を利用すると、「シフトプロセス」と比べて、一定の利点が配送システムにもたらされる可能性がある。例えば、各ウェーブは１日に複数回エリア全体をカバーすることができる一方、各シフトは１日に１回だけしか特定のエリアに割り当てられないので、「ウェーブプロセス」を利用すると、「シフトプロセス」から得られるよりもはるかに優れたエリアカバー率が得られる。一方、「ウェーブプロセス」では、１回の配送しか必要ない同じ場所に、単一の期間に複数回製品を配送して、費用が増加する場合がある。この複数回の配送は、例えば、別々のウェーブにもともと割り当てられている複数の製品を含む単一の注文に起因する場合がある。例えば、顧客が、月曜日の午後７時０分に、２つの製品を注文し、両方の荷物が水曜日に届くように２日間配送で注文する場合がある。ただし、第１の製品は、水曜日の午前ウェーブに関連付けられた午後８時０分の受付終了時刻を有する場合がある一方、第２の製品は、午前ウェーブに関連付けられた午後６時０分の受付終了時刻を有する場合がある。通常、この受付終了時刻の違いにより、第１の製品は水曜日の午前中に配送され、第２の製品は午後に配送される。開示された実施形態は、「ウェーブプロセス」においてこれらの分割配送を統合することを可能にすることによって、この非効率性に対処して、これらの分割配送に関連付けられた費用を大幅に削減することができる。

好ましい実施形態では、開示されたプロセスは、ＦＯシステム１１３によって実行されてもよい。ただし、開示されたプロセスは、ＦＯシステム１１３によって実行されると説明されるが、開示されたプロセスまたはその一部は、システム１００全体によって、またはプロセスの少なくとも一部を実行することができるシステム１００の任意の構成要素（例えば、１つ以上のプロセッサ、ＳＡＴシステム１０１など）によって実行されてもよい。いくつかの実施形態では、ＦＯシステム１１３は、少なくとも１つのプロセッサと、命令を格納する少なくとも１つの非一時的記憶媒体またはメモリとを備えてもよく、この命令が少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、本開示で説明される１以上のプロセスを実行させる。

図３は、ＦＯシステム１１３によってアクセス可能なデータベース３０１の例示的な実施形態を示すブロック図である。データベース３０１は、ＦＯシステム１１３が、データベース３０１に格納された情報にアクセス、アップロード、および／または修正することができるように、ＦＯシステム１１３と通信可能に接続してもよい（例えば、ネットワークを介して）。データベース３０１は、１つ以上の注文に含まれる１つ以上の製品３０３の記録など、注文３０２に関連する注文情報を格納してもよい。データベースは、商品が配送される配送元である、関連付けられたＦＣ３０４、および製品が出荷される期間である、関連付けられたウェーブ３０５などの、注文内の各製品３０３に対応する情報をさらに格納してもよい。

図４は、開示された実施形態に一致する、分割配送を統合するために実行されてもよい例示的なマージプロセス４００を示すフローチャートを提供する。ウェーブマージプロセス４００のステップ４０１において、ＦＯシステム１１３は、複数の製品を含む注文情報を受信してもよい。例えば、ＦＯシステム１１３は、顧客が１つ以上の製品を一度に注文したことを示す情報を受信してもよい。ただし、いくつかの実施形態では、複数の製品を含む注文情報を受信することは、顧客が複数の注文で別々の時間に製品を注文したことを示す情報を受信することを含んでもよい。したがって、分割配送を統合するための開示されたプロセスは、１つの注文または複数の別々の注文で注文された製品の配送に適用されてもよい。注文情報を受信した後、プロセス４００はステップ４０２に進んでもよく、このステップにおいて、ＦＯシステムは、各製品がどのＦＣから配送されるべきであり、どのウェーブでそれらの製品が配送されるべきかを判定してもよい。ＦＯシステム１１３は、これらの判定を、１つ以上のＦＣにおける各製品の在庫状況、および注文内の各製品に関連付けられた、受付終了時刻および対応するウェーブなどの様々な要因の１つ以上に基づいて、行ってもよい。ステップ４０３において、ＦＯシステム１１３は、製品が異なるウェーブに割り当てられているか否かを判定してもよい。

製品が複数のウェーブに割り当てられていない場合、ウェーブマージプロセス４００はステップ４０４で終了してもよい（すなわち、注文内のすべての製品が同じウェーブで配送されるようにスケジュールされているので、分割配送を統合するためのアクションは必要ない）。製品が複数のウェーブに割り当てられている場合、ＦＯシステム１１３は、複数のウェーブが同じ期間内にあるという別の判定を行ってもよい。この期間は、事前に決定されてもよく、ウェーブの組を含む期間（例えば、１日以上）に対応してもよく、または製品の１つ以上に対するＰＤＤに関連付けられた期間に対応してもよい。例えば、注文内の２つの製品を別々のウェーブで配送するが、これらのウェーブが異なる日または週に発生する場合、配送を１つのウェーブに統合すると、製品のうちの１つの、顧客への配送が大幅に遅れる可能性があるので、望ましくない場合がある（例えば、分割配送を統合すると、関連付けられたＰＤＤの後に１つ以上の製品が配送されてしまう）。複数のウェーブが同じ期間内にない場合、ウェーブマージプロセスはステップ４０６で終了してもよい（すなわち、統合することが配送を遅らせる可能性があるので、分割配送を統合するためのアクションは必要ない）。そうでなければ、ステップ４０７において、割り当てられたウェーブが同じ期間内にある場合、ＦＯシステム１１３は、製品の１つ以上に対して、配送ウェーブを再割り当てして、製品のすべてが同じウェーブの間に配送されるようにしてもよい。配送ウェーブを再割り当てすることは、製品が同じウェーブ内で配送されることを確実にするためにＦＯシステム１１３が実行できる１つ以上のアクション（データベース３０１を修正することなど）を含んでもよく、これらのアクションは、図６Ａ、図６Ｂ、および図６Ｃを参照してさらに詳細に説明する。

図５は、開示された実施形態に一致する、分割配送を統合するためにＦＯシステム１１３によって実行されてもよい詳細で例示的なマージプロセス５００を示すフローチャートを提供する。プロセス５００は、ステップ５０１において始まる。ステップ５０１において、ＦＯシステム１１３は、複数の製品と、関連付けられた識別子（例えば、バーコード、画像、テキスト文字列、ＲＦＩＤタグなど）とを含む注文情報を、リモートシステム（例えば、外部フロントエンドシステム１０３、出荷および注文追跡システム１１１など）から受信してもよい。いくつかの実施形態では、注文情報は、複数の製品を含む、顧客からの単一の注文に対応してもよい。しかしながら、いくつかの実施形態では、注文情報は、２つの顧客注文を含み、第１の顧客注文に第１の製品を有し、第２の顧客注文に第２の製品を有してもよい、言い換えれば、マージプロセス５００を通じて単一の配送に統合されるためには、複数の配送は厳密に同じ注文からのものである必要はない。例えば、顧客は、ある日に複数の製品を注文して、翌日に別の複数の製品を注文してもよい。この例では、注文情報を受信することは、異なる時間に両方の注文を受信することと、両方の注文を注文情報に集約することとを含んでもよい。

ステップ５０１が完了した後、マージプロセス５００は次に、ステップ５０２に進んでもよい。ステップ５０２において、ＦＯシステム１１３は、関連付けられた識別子、およびリモートシステムに基づいて、複数の製品のうちの第１の製品に対して、ＦＣを判定し、複数の配送ウェーブから第１の配送ウェーブを判定してもよい。いくつかの実施形態では、ＦＣは、リモートシステム情報に関連付けられた地域を判定することと、判定された地域に関連付けられたＦＣの組からＦＣを判定することとによって判定されてもよい。例えば、リモートシステム情報は、受取人の配送先住所などの配送情報を含んでもよく、ＦＯシステム１１３は、この住所が複数の地域のうちの、ある配送地域内にあると判定してもよい。地域が特定された後、ＦＯシステム１１３は、その地域における各ＦＣでその時点に保持されている製品の在庫記録を調べて、どのＦＣが、第１の製品に対応する識別子に対応する製品の１つ以上を保持しているか（すなわち、各ＦＣの製品の在庫状況）を判定してもよい。いくつかの実施形態では、関連付けられた識別子、およびリモートシステムは、製品の購入時間、購入時間に関連付けられた受付終了時刻、および／または受付終了時刻に関連付けられたウェーブを含んでもよい。この情報に基づいて、ＦＯシステム１１３は、製品が、地域内のどのＦＣから配送されるべきかを判定して、第１の製品が配送されるべき第１のウェーブをさらに判定してもよい。ステップ５０３において、ＦＯシステム１１３は、判定されたＦＣおよび判定された第１の配送ウェーブを、第１の製品に関連付けて、データベース（例えば、データベース３０１）に格納することによって、判定されたＦＣおよび判定された配送ウェーブに、製品を割り当ててもよい。

いくつかの実施形態では、製品に対してＦＣを判定することは、１つ以上のＦＣ同士の間のウェーブのスケジュールと、各ＦＣを通る製品の平均移動時間との比較に基づいてもよい。スケジュールは、各ＦＣに対するウェーブの記録であってもよく、例えば、どのウェーブが各製品のＰＤＤに関連付けられているかを示す情報を含んでもよい。各ＦＣを通る製品の平均移動時間は、所与の製品がＦＣからキャンプゾーンに移動するのにかかる平均時間であってもよく、システム１００内のデータベース（例えば、データベース３０１）に格納された履歴データに基づいてもよく、この履歴データは、１つ以上の類似する製品の、当該ＦＣを通る移動に関連付けられた過去の時刻を表してもよい。履歴データは、ＦＯシステム１１３によって、１つ以上のモバイルデバイス（例えば、モバイルデバイス１０７Ａ、１０７Ｂ、１０７Ｃ）から継続的または定期的に収集されてもよく、ＦＣ内の異なるゾーン（例えば、インバウンドゾーン２０３、ドロップゾーン２０７、ピッキングゾーン２０９、ハブゾーン２１３、キャンプゾーン２１５など）への製品の到着時間の時刻に関連付けられた時刻などの情報を含んでもよい。これらの時刻は、各製品の移動時間を計算するために使用してもよく、総計移動時間は、平均移動時間を計算するために使用してもよい。平均移動時間を各ＦＣに対するウェーブのスケジュールと比較して、関連付けられたウェーブに対する積み込みに関連付けられた時間までに、製品がＦＣのキャンプゾーンに到達するか否かを判定することができる。

いくつかの実施形態では、ＦＣを判定することは、複数の以前の電子要求および関連付けられたＦＣをデータベース（例えば、データベース３０１）に格納することと、以前の電子要求を訓練データセットと、検証データセットとに分割することであって、訓練データセットが、検証データセットより多くの要求を有することと、要求情報およびＦＣを関連付ける訓練データセットに基づいて、予測モデルを生成することとを含んでもよい。例えば、ＦＯシステム１１３は、以前に注文された製品に関連付けられた履歴データをデータベースに格納してもよく、このデータは、以前の電子要求に関連付けられた情報（例えば、電子要求内で注文された製品の識別子、関連付けられたＦＣ、ウェーブ、および／またはＰＤＤなど）を示してもよい。ＦＯシステム１１３は、このデータ（すなわち、訓練データセット）の大部分を使用して、予測モデルを生成してもよい。予測モデルは、線形回帰、ランダムフォレスト、またはロジスティック回帰など、１つ以上の一般的な統計モデルの形式の数式であって、電子要求情報と、関連付けられたＦＣとの間の関係を表す数式であってもよい。

ＦＯシステム１１３が予測モデルを生成した後、いくつかの実施形態では、ＦＯシステム１１３は検証データセットを使用して予測モデルを有効性確認してもよい。検証データセットは、予測モデルを生成することに使用しなかった履歴データの少なくとも一部であってもよい。予測モデルを有効性確認するために、ＦＯシステム１１３は、検証データセット内の各電子要求に対して、予測された関連付けられたＦＣの組を生成して、予測された関連付けられたＦＣを実際の関連付けられたＦＣと比較してもよい。予測モデルは、例えば、事前に決定された信頼閾値を満たしている場合、有効性確認されてもよい（例えば、モデルが、関連付けられたＦＣの少なくとも９５％を正しく予測した場合）。予測モデルが有効性確認された後、ＦＯシステム１１３は、モデルを将来の電子要求に適用して、関連付けられたＦＣを判定してもよい。

ステップ５０３が完了した後、マージプロセス５００は次に、ステップ５０４に進んでもよい。ステップ５０４において、ＦＯシステム１１３は、複数の製品のうちの第２の製品に対して、関連付けられた識別子、およびリモートシステムに基づいて、複数の配送ウェーブから、ＦＣと、第１の配送ウェーブとは異なる第２の配送ウェーブとを判定してもよい。ＦＣおよび第２の配送ウェーブは、第１の製品に対して、ＦＣおよび第１の配送ウェーブを判定することに関して上で述べたプロセスと同様のプロセスを使用して、判定してもよい。ステップ５０５において、ＦＯシステム１１３は、第２の製品に関連付けて、第２の配送ウェーブをデータベースに格納してもよい。

図５は、連続して実行されるステップを示しているが、これらのステップは、開示された実施形態に一致して、実行されてもよく、任意の順序または構成であってもよい。例えば、ステップ５０２および５０３は、ステップ５０４および５０５に続いて行われても、並行して行われてもてもよい。さらに、いくつかの実施形態では、ＦＯシステムは、第１の製品に関連付けられたＦＣと、第２の製品に関連付けられたＦＣとが互いに異なると判定してもよい。

ステップ５０５が完了した後、マージプロセス５００は次に、ステップ５０６に進んでもよい。ステップ５０６において、ＦＯシステム１１３は、第１の配送ウェーブが、第２の配送ウェーブよりも早い期間に関連付けられていると判定してもよい。いくつかの実施形態では、ＦＯシステム１１３は、第１の配送ウェーブと第２の配送ウェーブとが同じ期間内にあることをさらに判定してもよい。例えば、ＦＯシステム１１３は、同じ顧客によって注文された別々の製品が別々のウェーブで顧客に配送されていると判定した後、これらの別々のウェーブが同じ日に発生するとさらに判定してもよい。したがって、この例では、ＦＯシステム１１３は、分割配送に関連付けられた費用をなくすことができるように、製品が同じウェーブで配送されるべきであると判定してもよい。この判定に応じて、ＦＯシステム１１３は、これらの配送が同じウェーブの間に行われるように、配送を再スケジュールしてもよい。ＦＯシステム１１３は、各荷物が一番遅い共通ウェーブまで出荷されないことを確実にするために、例えば、１つ以上のアクションを実行することによって配送を再スケジュールしてもよい。ＦＯシステムが実行してもよいアクションは、図６Ａ、図６Ｂ、および図６Ｃを参照してさらに詳細に説明する。

いくつかの実施形態では、ステップ５０６において、ＦＯシステム１１３は、第１の配送ウェーブが、第２の配送ウェーブよりも早い期間に関連付けられていること、および第２の配送ウェーブが、第２の製品に基づいて、条件を満たしていないと判定されたことを判定してもよい。条件は、製品に関連付けられた識別子、および／または製品に関連付けられた注文情報に基づいてもよく、製品、または製品を注文した顧客が速達の対象とされるか否かを示してもよい。製品はＦＣですぐに配送可能であることにより、速達の対象とすることができる。ただし、顧客が満たす特定の条件により、製品が速達の対象となる場合もある。多くの注文処理システムは、製品に対する１回限りの速達料金の支払い、または、システムを通じて注文された製品に対する無料の速達を受けるための、注文処理システムへのサブスクリプション料金の支払いのいずれかを行う顧客に対して、速達サービスを提供してもよい。

例えば、複数の製品を含む注文は、１回限りの料金またはサブスクリプション料金を支払っていない顧客からのものである場合があるため、この注文内の製品は速達の条件を満たさない。ただし、注文内の各製品に対して、配送ウェーブおよびＦＣが判定された場合でも、配送は同じ日に別々のウェーブでスケジュールされる場合がある。場合によっては、後のウェーブの間に配送が予定されている１つ以上の製品は、前のウェーブで配送可能である場合があり、または顧客が１回限りの料金もしくはサブスクリプション料金を支払っていれば、前のウェーブの間に配送の対象とされる場合がある。したがって、速達の費用を相殺するために１回限りの料金またはサブスクリプション料金を用いてもよいが、それらの支払いがなければ、場合によっては、分割配送によって費用が増加する場合がある。このような場合、条件を満たしていない製品が一部あったとしても、前のウェーブですべての製品を配送する方が、費用効率が良い場合がある。この費用増加に対処するために、ＦＯシステム１１３は、いくつかの実施形態では、１つ以上の製品が前のウェーブの条件を満たさなかったことを理由に、後のウェーブで配送されるようにスケジュールされたか否かを判定するように構成されてもよい。この判定に応じて、ＦＯシステム１１３は次に、一番遅い共通のウェーブではなく、それより前のウェーブの間に配送が行われるように、配送を再スケジュールしてもよい。

図６Ａは、開示された実施形態に一致する、同じウェーブで配送されるべきであると判定した場合、複数の製品の配送を再スケジュールするために実行されてもよい例示的なプロセス６１０を提供する。ステップ６１１において、ＦＯシステム１１３は、第１の製品を第２の配送ウェーブに関連付けるために、データベース（例えば、データベース３０１）を修正してもよい。データベースを修正することは、第１の製品に関連付けて、以前に格納された第１の配送ウェーブを上書きすることと、格納された第１の配送ウェーブを第２の配送ウェーブで置き換えることとを含んでもよい。その結果、データベースに格納されている記憶情報は、第１の製品がこのとき、第２のウェーブの間に配送されるようにスケジュールされていることを反映する。ステップ６１２において、ＦＯシステム１１３はまた、第１の製品、および第２の配送ウェーブに関連付けられた情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイス（例えば、輸送システム１０７の、モバイルデバイス１０７Ａ、１０７Ｂ、および１０７Ｃ）に転送してもよい。グラフィカルユーザインタフェースを生成することは、どの荷物を配送するかと、どのウェーブで荷物が配送されるべきかとを示す通知をモバイルデバイスに表示することを含んでもよい。生成されたグラフィカルインタフェースは、ユーザデバイスにダウンロードされたプログラムまたはアプリケーションの一部として生成されてもよい。

図７は、配送を再スケジュールするために、データベースに格納された製品情報をどのように修正できるかを示す図を提供する。この図は、データベース７０１がプロセス６１０のステップ６１１の処理中のものであり、それによって修正されたデータベース７０２が得られることを示している。データベース７０１および修正されたデータベース７０２は、本開示で前述したものと同じデータベース（例えば、データベース３０１）であってもよい。もともと、データベース７０１は、注文７０３に対応する情報を含み、注文７０３内で、第１の製品７１１および第２の製品７２１は、それぞれ、午前ウェーブ７１２および午後ウェーブ７２２に関連付けられている。しかしながら、この例では、ＦＯシステム１１３は、両方の製品が午後ウェーブ７２２の間に配送されるべきであると判定しているため、プロセス６１０を実施する。プロセス６１０のステップ６１１を経た後、修正されたデータベース７０２に格納された注文７０３に対応する情報は、第１の製品７１１および第２の製品７２１が両方とも、午後ウェーブ７２２に関連付けられていることを示してもよい。

更新された配送スケジュールを反映するようにデータベースが修正された後、データベースに対して情報を要求すると、第２の配送ウェーブに関連付けられた情報を返答してもよい。この情報の要求および返答は、第１の製品が配送プロセスの間の任意の時点でモバイルデバイスによってスキャンされたときに発生する可能性がある。いくつかの実施形態では、モバイルデバイスは、修正されたデータベースから取り出した第２の配送ウェーブに関連付けられた情報を返答してもよい。

ただし、いくつかの実施形態では、モバイルデバイスは、データベースから情報を取り出すように構成されていない場合には、製品または荷物ラベルに関連付けられた情報のみを返答してもよい。さらに、配送作業員は、配送ウェーブを決定するためにラベルを参照するだけでよく、それによって配送作業員に、配送ウェーブが変更された可能性があることを通知することができる。したがって、１つ以上の製品の配送を異なるウェーブに再スケジュールすべきであるというＦＯシステム１１３による判定に応じて荷物ラベルを交換するシステムを実装することが望ましい場合がある。

図６Ｂは、開示された実施形態に一致する、荷物の配送が別のウェーブに再スケジュールされるべきであると判定した場合、荷物ラベルを印刷および交換するために実行されてもよい例示的なプロセス６２０を示すフローチャートを提供する。ステップ６２１において、ＦＯシステム１１３は、命令の第２の組を印刷デバイスに転送してもよい。命令の第２の組は、第２のウェーブに関連付けられた情報をリストするラベルを印刷デバイスに印刷させるように構成されたコンピュータ命令の組であってもよい。印刷デバイスは、モバイルデバイス（例えば、輸送システム１０７の、モバイルデバイス１０７Ａ、１０７Ｂ、および１０７Ｃ）またはシステム１００に関連付けられた任意の他のデバイスであってもよい。印刷デバイスはまた、プリンタ（例えば、レーザ、インクジェット、またはサーマル）であってもよい。第２のウェーブに関連付けられた情報をリストするラベルを印刷することは、モバイルデバイスによってスキャンされると、第２のウェーブに関連付けられた情報をモバイルデバイスに表示させる、更新されたバーコード、または他の識別子を含むラベルを印刷することを含んでもよい。図６Ｂは、ステップ６２１がステップ６１２の後に行われるものとして示しているが、プロセス６２０は、プロセス６１０とは独立および／または並行して行われてもよい。

図６Ｃは、開示された実施形態に一致する、製品の配送が、あるウェーブから異なるウェーブに再スケジュールされた後に、再スケジュール前のウェーブの間に製品が配送されることを防止するために実行されてもよい例示的なプロセス６３０を示すフローチャートを提供する。ステップ６３１において、ＦＯシステム１１３は、第１の製品の識別子を含むスキャンイベントを、モバイルデバイス（例えば、輸送システム１０７の、モバイルデバイス１０７Ａ、１０７Ｂ、および１０７Ｃ）から受信してもよい。スキャンイベントは、例えば、キャンプゾーン２１５における作業者または機械が、製品を配送する前に第１の製品をスキャンして、製品の最終的な目的地を決定する場合に発生してもよい。このスキャンイベントは、第１のウェーブに対応する期間の間に発生してもよい。ＦＯシステム１１３が第１の製品の配送を第２のウェーブに再スケジュールした場合、プロセス６３０はステップ６３２に進んでもよい。ステップ６３２において、ＦＯシステム１１３は、受信されたスキャンイベントに基づいて、第１の配送ウェーブに関連付けられている期間であって、第２のウェーブに関連付けられていない期間の間にスキャンイベントが発生したと判定してもよい。言い換えれば、ＦＯシステム１１３は、第１の荷物が間違ったウェーブの間に配送されようとしていることを認識するように構成されてもよい。

ステップ６３２が完了した後、プロセス６３０はステップ６３３に進んでもよい。ステップ６３３において、ＦＯシステム１１３は、第１の製品が、第１の配送ウェーブの間に配送されるべきではないという指示を、モバイルデバイスに送信してもよい。この指示は、例えば、モバイルデバイスのユーザインタフェース上に表示されてもよい通知を含んでもよく、この表示は、第１の製品が、代わりに第２のウェーブ、または第１の製品の配送が再割り当てされた、いずれかのウェーブで配送されるべきであることを使用に通知する。次に、作業者は、第２のウェーブまで製品を保留して、第２の商品と同時に製品を配送することができるようにする。

ステップ６３３が完了した後、プロセス６３０はステップ６３４に進んでもよい。ステップ６３４において、ＦＯシステム１１３は、スキャンイベントが、完了したイベントのデータベースに挿入されるのを防止することができる。通常、配送の過程で、スキャンイベントは、ＳＡＴシステム１０１が配送状況を管理および監視することができるように、スキャンイベントをシステム１００に関連付けられたデータベースに挿入してもよい。このデータベースは、各製品に関連付けられたＦＣおよび各製品に関連付けられたウェーブに関する情報を格納するために使用されるのと同じデータベース（例えば、データベース２０１および６０１）であってもよく、またはシステム１００に関連付けられた別個のデータベース（例えば、ＳＡＴシステム１０１によって、配送状況を監視するために使用される専用データベース）であってもよい。しかしながら、ＳＡＴシステム１０１は、製品が、後のウェーブの間での配送のために実際には保留されている場合に、スキャンイベントがデータベースに挿入されていることに基づいて、製品が配送のために持ち出されているという誤った判定をする可能性があり、この誤った判定は、配送を混乱させ、または不必要に複雑にする可能性がある。この誤った判定に対処するために、ＦＯシステム１１３は、スキャンイベントが発生した期間に関連付けられたウェーブで、製品が配送されるべきではないという指示を携帯電話に送信した場合、データベースへのスキャンイベントの挿入を防止してもよい。

いくつかの実施形態では、スキャンイベントを挿入することは、モバイルデバイスが、スキャンイベントが発生したことを示す情報を含むデータパケットをデータベースに送信することを含んでもよく、挿入を防止することは、データパケットを遮断することと、データパケットを削除することとを含んでもよい。いくつかの実施形態では、データベースはデータパケットを受信してもよく、挿入を防止することは、データベースからデータパケットを除去することを含んでもよい。挿入を防止することは、データベースを読み取り専用としてマークすることも含んでもよく、そうすることで、データパケットを受信した場合、データパケット内のスキャンイベントを含む情報をデータベースに挿入することができなくなる。いくつかの実施形態では、スキャンイベントを防止することは、モバイルデバイスがパケットをデータベースに送信することを防止する命令を、モバイルデバイスに送信することを含んでもよい。

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

記載された説明および開示された方法に基づくコンピュータプログラムは、熟練した開発者の技術の範囲内である。様々なプログラムまたはプログラムモジュールは、当業者に知られている任意の技法を使用して作成してもよく、または既存のソフトウェアに関連して設計してもよい。例えば、プログラムセクションまたはプログラムモジュールは、．Ｎｅｔ Ｆｒａｍｅｗｏｒｋ、．Ｎｅｔ Ｃｏｍｐａｃｔ Ｆｒａｍｅｗｏｒｋ（およびＶｉｓｕａｌ Ｂａｓｉｃ、Ｃ言語などの関連言語）、Ｊａｖａ、Ｃ＋＋、Ｏｂｊｅｃｔｉｖｅ－Ｃ、ＨＴＭＬ、ＨＴＭＬ／ＡＪＡＸの組み合わせ、ＸＭＬ、またはＪａｖａアプレットを含むＨＴＭＬで設計、またはこれらを用いて設計してもよい。

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

Claims (19)

1. 配送ウェーブスケジューリングのための、コンピュータ化されたシステムであって、
   少なくとも１つのプロセッサと、
   前記少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサにステップを実行させる命令を含む少なくとも１つの非一時的記憶媒体とを備え、前記ステップが、
   複数の製品と、関連付けられた識別子と、を含む注文情報を、リモートシステムから受信することと、
   前記関連付けられた識別子および前記リモートシステムに基づいて、前記複数の製品の第１の製品に対して、フルフィルメントセンタと、複数の配送ウェーブからの第１の配送ウェーブと、を決定することと、
   前記第１の製品に関連付けて、前記第１の配送ウェーブをデータベースに格納することと、
   前記関連付けられた識別子および前記リモートシステムに基づいて、前記複数の製品の第２の製品に対して、フルフィルメントセンタと、前記複数の配送ウェーブからの第２の配送ウェーブと、を決定することであって、前記第２の配送ウェーブが前記第１の配送ウェーブとは異なる、ことと、
   前記第２の製品に関連付けて、前記第２の配送ウェーブを前記データベースに格納することと、
   前記第１の配送ウェーブが前記第２の配送ウェーブよりも早い期間に関連付けられていると判定することと、を含み、前記判定することに応じて、
   前記第１の製品を前記第２の配送ウェーブに関連付けるために、前記データベースを修正することと、
   前記第１の製品、および前記第２の配送ウェーブに関連付けられた情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイスに転送することとを含む、コンピュータ化されたシステム。
2. 前記第１の製品に関連付けられた前記フルフィルメントセンタと、前記第２の製品に関連付けられた前記フルフィルメントセンタと、が異なる、請求項１に記載のシステム。
3. 前記注文情報が２つの顧客注文を含み、第１の顧客注文に前記第１の製品を有し、第２の顧客注文に前記第２の製品を有する、請求項２に記載のシステム。
4. 前記ステップが、
   コンピュータ命令の第２の組を印刷デバイスに転送することであって、コンピュータ命令の前記第２の組が、前記第２のウェーブに関連付けられた前記情報をリストするラベルを前記印刷デバイスに印刷させるように構成されている、ことをさらに含む、請求項１に記載のシステム。
5. 各ウェーブが、複数のウェーブを含む期間の間に発生して、前記ステップが、前記第１の配送ウェーブと前記第２の配送ウェーブとが同じ期間の間に発生することを判定することをさらに含む、請求項１に記載のシステム。
6. 前記ステップが、
   前記第１の製品の識別子を含むスキャンイベントを、モバイルデバイスから受信することと、
   前記第１の配送ウェーブに関連付けられ、前記第２の配送ウェーブに関連付けられていない期間の間に前記スキャンイベントが発生したと判定することと、
   前記第１の製品が、前記第１の配送ウェーブの間に配送されるべきではないという指示を、前記モバイルデバイスに送信することと、
   前記スキャンイベントが、完了したスキャンイベントのデータベースに挿入されるのを防止することとをさらに含む、請求項１に記載のシステム。
7. 前記フルフィルメントセンタを判定することが、
   前記リモートシステムの情報に関連付けられた地域を判定することと、
   前記判定された地域に関連付けられたフルフィルメントセンタの組からフルフィルメントセンタを判定することとを含む、請求項１に記載のシステム。
8. 前記フルフィルメントセンタを判定することが、
   複数の以前の電子要求および関連付けられたフルフィルメントセンタをデータベースに格納することと、
   前記以前の電子要求を訓練データセットと、検証データセットとに分割することであって、前記訓練データセットが、前記検証データセットより多くの要求を有する、ことと、
   要求情報およびフルフィルメントセンタを関連付ける訓練データセットに基づいて、予測モデルを生成することと、
   前記検証データセットを使用して前記予測モデルを検証することと、
   前記予測モデルを前記電子要求に適用することによって、前記フルフィルメントセンタを判定することとを含む、請求項１に記載のシステム。
9. 前記フルフィルメントセンタを判定することが、製品のウェーブ配送のスケジュールと、複数のフルフィルメントセンタにおける各フルフィルメントセンタを通る製品の平均移動時間と、を比較することを含む、請求項１に記載のシステム。
10. 配送ウェーブスケジューリングのための、コンピュータによって実装される方法であって、
    複数の製品と、関連付けられた識別子と、を含む注文情報を、リモートシステムから受信することと、
    前記関連付けられた識別子および前記リモートシステムに基づいて、前記複数の製品の第１の製品に対して、フルフィルメントセンタと、複数の配送ウェーブからの第１の配送ウェーブと、を決定することと、
    前記第１の製品に関連付けて、前記第１の配送ウェーブをデータベースに格納することと、
    前記関連付けられた識別子および前記リモートシステムに基づいて、前記複数の製品の第２の製品に対して、フルフィルメントセンタと、前記複数の配送ウェーブからの第２の配送ウェーブと、を決定することであって、前記第２の配送ウェーブが前記第１の配送ウェーブとは異なる、ことと、
    前記第２の製品に関連付けて、前記第２の配送ウェーブを前記データベースに格納することと、
    前記第１の配送ウェーブが前記第２の配送ウェーブよりも早い期間に関連付けられていると判定することと、を含み、前記判定することに応じて、
    前記第１の製品を前記第２の配送ウェーブに関連付けるために、前記データベースを修正することと、
    前記第１の製品、および前記第２の配送ウェーブに関連付けられた情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイスに転送することとを含む、コンピュータによって実装される方法。
11. 前記第１の製品に関連付けられた前記フルフィルメントセンタと、前記第２の製品に関連付けられたフルフィルメントセンタと、が異なる、請求項１０に記載の方法。
12. 前記注文情報が２つの顧客注文を含み、第１の顧客注文に前記第１の製品を有し、第２の顧客注文に前記第２の製品を有する、請求項１１に記載の方法。
13. 前記ステップが、
    コンピュータ命令の第２の組を印刷デバイスに転送することであって、コンピュータ命令の前記第２の組が、前記第２のウェーブに関連付けられた前記情報をリストするラベルを前記印刷デバイスに印刷させるように構成されている、ことをさらに含む、請求項１０に記載の方法。
14. 各ウェーブが、複数のウェーブを含む期間の間に発生して、前記ステップが、前記第１の配送ウェーブと前記第２の配送ウェーブとが同じ期間の間に発生することを判定することをさらに含む、請求項１０に記載の方法。
15. 前記ステップが、
    前記第１の製品の識別子を含むスキャンイベントを、モバイルデバイスから受信することと、
    前記第１の配送ウェーブに関連付けられて、前記第２の配送ウェーブに関連付けられていない期間の間に前記スキャンイベントが発生したと判定することと、
    前記第１の製品が、前記第１の配送ウェーブの間に配送されるべきではないという指示を、前記モバイルデバイスに送信することと、
    前記スキャンイベントが、完了したスキャンイベントのデータベースに挿入されるのを防止することとをさらに含む、請求項１に記載の方法。
16. 前記ステップが、
    前記リモートシステムの情報に関連付けられた地域を判定することと、
    前記判定された地域に関連付けられたフルフィルメントセンタの組からフルフィルメントセンタを判定することとを含む、請求項１０に記載の方法。
17. 前記フルフィルメントセンタを判定することが、
    複数の以前の電子要求および関連付けられたフルフィルメントセンタをデータベースに格納することと、
    前記以前の電子要求を訓練データセットと、検証データセットとに分割することであって、前記訓練データセットが、前記検証データセットより多くの要求を有する、ことと、
    要求情報およびフルフィルメントセンタを関連付ける訓練データセットに基づいて、予測モデルを生成することと、
    前記検証データセットを使用して前記予測モデルを検証することと、
    前記予測モデルを前記電子要求に適用することによって、前記フルフィルメントセンタを判定することとを含む、請求項１０に記載の方法。
18. 前記フルフィルメントセンタを判定することが、製品のウェーブ配送のスケジュールと、複数のフルフィルメントセンタにおける、各フルフィルメントセンタを通る製品の平均移動時間とを比較することを含む、請求項１に記載のシステム。
19. 配送ウェーブスケジューリングのための、コンピュータ化されたシステムであって、
    少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサにステップを実行させる命令を含む少なくとも１つの非一時的記憶媒体とを備え、前記ステップが、
    複数の製品と、関連付けられた識別子と、を含む注文情報を、リモートシステムから受信することと、
    前記関連付けられた識別子および前記リモートシステムに基づいて、前記複数の製品の第１の製品に対して、フルフィルメントセンタと、複数の配送ウェーブからの第１の配送ウェーブと、を決定することであって、前記第１のウェーブが条件と関連付けられていることと、
    前記第１の製品に関連付けて、前記第１の配送ウェーブをデータベースに格納することと、
    前記関連付けられた識別子および前記リモートシステムに基づいて、前記複数の製品のうちの第２の製品に対して、フルフィルメントセンタと、前記複数の配送ウェーブからの第２の配送ウェーブと、を決定することであって、前記第２の配送ウェーブが、前記第１の配送ウェーブに関連付けられた期間とは異なる期間に関連付けられる、ことと、
    前記第２の製品に関連付けて、前記第２の配送ウェーブを前記データベースに格納することと、
    前記第１のウェーブに関連付けられた前記期間と、前記第２のウェーブに関連付けられた前記期間と、が同じ期間の間に発生すると判定することであって、前記期間が複数のウェーブを含む、ことと、
    前記第１の配送ウェーブが前記第２の配送ウェーブよりも早い期間に関連付けられていること、および、前記第２の配送ウェーブが前記条件を満たしていない前記第２の製品に基づいて決定されたこと、を判定することと、を含み、前記判定することに応じて、
    前記第２の製品を前記第１の配送ウェーブに関連付けるために、前記データベースを修正することと、
    前記第２の製品、および、前記第１の配送ウェーブに関連付けられた情報を表示する、グラフィカルユーザインタフェースを生成するために、コンピュータ命令を少なくとも１つのモバイルデバイスに転送することとを含む、コンピュータ化されたシステム。
    

Images