JP7230070B2 - 配送ウェーブシステムを使用した自動荷物再注文のためのシステムおよび方法 - Google Patents

Description

関連特許出願の相互参照
本出願は、参照によりその全体が本明細書に組み込まれる、２０１９年３月１８日に出願された米国特許出願第１６／３５６，１００号の一部継続出願である。

本開示は、一般に、自動荷物再出荷スケジューリングのためのコンピュータ化されたシステムおよび方法に関する。特に、本開示の実施形態は、複数のサブシステムからのデータの収集に基づく物流管理システムを通じた荷物の追跡を利用して、再出荷が必要なときを決定し、そのような決定を受けて荷物の再出荷を自動的にスケジュールする、発明的で非従来型のシステムに関する。

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

各オンライン購入は、本質的に、購入された商品を目的の受取人に配送する必要がある。各オンライン購入または注文は、通常、１つまたは複数の商品から構成され、１つまたは複数の商品は、各々が独自の配送予定日を有する１つまたは複数の荷物にパッケージングすることができる。一般的な注文は、顧客から１つまたは複数の商品の注文を受けること、在庫から１つまたは複数の商品を取り出すこと、１つまたは複数の商品を１つまたは複数の荷物にパッケージングすること、および、配送予定日の前に、１つまたは複数の荷物を目的の受取人に配送することなどのステップを介して処理され得る。配送予定日は、小売業者自身または配送業者が設定することができるか、または、顧客が特定の日付を要求して、それをその後、配送予定日として割り当てることができる。注文処理の理想的なシステムは、配送予定日までに各荷物を目的の受取人に失敗することなく配送する。

現在存在する注文処理システムには、上記のステップの実施における様々な程度の自動化および複雑さを含む。しかし、種々の商品および注文の数が増えるにつれ、これは注文が複雑なサブシステムネットワークを通過する必要があり、一部の注文には部分的な返品などの複雑な要因があるという事実によって悪化することであるが、現在のシステムには、注文が出された瞬間から注文が実行される（すなわち、注文内のすべての荷物が目的の受取人に配送されるか、または在庫に戻される）瞬間まで、個々の荷物を追跡するのは不可能であるかまたは相当に非効率的であるという点で問題がある。この問題は、荷物の数が増え、迅速な処理に重点が置かれると、システムが荷物の入れ忘れ、ラベルの誤り、またはソートの誤りなどの人的エラーを起こしやすくなるという事実によって悪化する。例えば、配送予定日が異なる複数の荷物から構成される注文では、システムの途中で１つまたは複数の荷物が喪失または破損することになる可能性があり、これは、失望した顧客が追求するまでシステムが気付かない場合がある。

別の例では、注文の荷物の１つがシステムのある点において遅延する場合があり、顧客が荷物の再配送を要求する場合がある。その場合、システムは既存の荷物が遅延している理由、または、遅延を解消するために必要な時間を伝えることができないため、新しい荷物を再注文する必要がある。この場合、既存の遅延した荷物と新しい荷物の両方が顧客に配送され、システムに不必要な費用がかかる可能性がある。既存の遅延荷物が倉庫に正しくルーティングし戻されている場合であっても、現在のシステムは、顧客から返送された荷物と区別できない場合があり、遅延した荷物は、顧客に届かず、したがって開封されなかったために最小限の検査のみで保管して補充され得たときに、他の顧客が返品した荷物と共に全検査プロセスを経る必要がある。これらのシナリオは、現在のシステムの欠点を例示する役割を果たし、他の多くの問題も当業者には明らかであり得る。

したがって、事業費への影響を常に最小限に抑えながら、注文処理システムを通じて注文および荷物を追跡し、まだ配送されていない残存する注文の数を減らすために必要な措置を積極的に特定して実行するための改善された方法およびシステムが必要とされている。

本開示の一態様は、自動再出荷スケジューリングのための方法に関する。方法は、注文と、第１の荷物に関連付けられている第１の荷物識別子であり、第１の荷物は１つまたは複数のアイテムを含む、第１の荷物識別子と、第１の荷物識別子を含む複数の荷物識別子に関連付けられているイベントデータとを含む集約情報を受信することであって、注文は、アイテムの第１のグループを含み、第１の荷物は第１の受取人およびスケジュールされた配送時間に関連付けられていることと、第１の荷物識別子に基づいてイベントデータを解析することと、解析されたイベントデータに基づいて、第１の荷物が配送されなかったかを判定することと、第１の荷物が配送されなかったという判定に基づいて、現在の時刻を決定することと、複数の締め切り時刻を決定することであって、複数の締め切り時刻の各締め切り時刻は、配送ウェーブに関連付けられることと、複数の締め切り時刻と現在の時刻との間の比較に基づいて、配送ウェーブに関連付けられている新しいスケジュールされた配送時間を決定することと、第１の荷物に含まれる１つまたは複数のアイテムを含む第２の荷物に対する新しい注文を作成することと、新しいスケジュールされた配送時間に関連付けられている配送ウェーブに基づいて、モバイルデバイスに新しい注文を配送するための命令を送信することとを含む。

自動再出荷スケジューリングのためのコンピュータ実装システムであって、少なくとも１つのプロセッサと、少なくとも１つのプロセッサによって実行されると、ステップを実施する命令を含むメモリとを備え、ステップは、注文、第１の荷物に関連付けられている第１の荷物識別子であり、第１の荷物は１つまたは複数のアイテムを含む、第１の荷物識別子、および第１の荷物識別子を含む複数の荷物識別子に関連付けられているイベントデータを含む集約情報を受信することであって、注文は、アイテムの第１のグループを含み、第１の荷物は第１の受取人およびスケジュールされた配送時間に関連付けられていることと、第１の荷物識別子に基づいてイベントデータを解析することと、解析されたイベントデータに基づいて、第１の荷物が配送されなかったかを判定することと、第１の荷物が配送されなかったという判定に基づいて、第１の荷物に対応する注文の一部をキャンセルすることと、現在の時刻を決定することと、複数の締め切り時刻を決定することであって、複数の締め切り時刻の各締め切り時刻は、配送ウェーブに関連付けられることと、複数の締め切り時刻と現在の時刻との間の比較に基づいて、配送ウェーブに関連付けられている新しいスケジュールされた配送時間を決定することと、第１の荷物に含まれる１つまたは複数のアイテムを含む第２の荷物に対する新しい注文を作成することと、新しいスケジュールされた配送時間に関連付けられている配送ウェーブに基づいて、モバイルに新しい注文を配送するための命令を送信することとを含む、コンピュータ実装システム。

自動再出荷スケジューリングのためのコンピュータ実装システムであって、少なくとも１つのプロセッサと、少なくとも１つのプロセッサによって実行されると、ステップを実施する命令を含むメモリとを備え、ステップは、注文と、第１の荷物に関連付けられている第１の荷物識別子であり、第１の荷物は１つまたは複数のアイテムを含む、第１の荷物識別子と、第１の荷物識別子を含む複数の荷物識別子に関連付けられているイベントデータを含む集約情報を受信することであって、注文は、アイテムの第１のグループを含み、第１の荷物はアイテムの第１のグループに関連付けられており、１つまたは複数の既存のルートを通じて第１の所定の期間内に第１の受取人に配送されることになることと、第１の荷物識別子に基づいてイベントデータを解析することと、解析されたイベントデータに基づいて第１の荷物が存在するか否かを判定することと、第１の荷物が存在しないと判定された場合、第１の荷物識別子に第１の条件を満たすものとしてフラグを立てることと、第１の荷物が存在すると判定された場合、リソース不足のために第１の荷物が配送されなかったかを判定することと、リソース不足のために第１の荷物が配送されなかったと判定された場合、第１の所定の期間が第１の閾値を超えて経過した場合に、第１の荷物識別子に第２の条件を満たすものとしてフラグを立てることと、判定に基づいて、現在の時刻を決定することと、複数の締め切り時刻を決定することと、複数の締め切り時刻と現在の時刻との間の比較に基づいて、配送ウェーブに関連付けられている新しいスケジュールされた配送時間を決定することと、第１の荷物に含まれる１つまたは複数のアイテムを含む第２の荷物に対する新しい注文を作成することと、新しいスケジュールされた配送時間に関連付けられている配送ウェーブに基づいて、モバイルデバイスに新しい注文を配送するための命令を送信することとを含む、コンピュータ実装システム。

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

開示された実施形態と一致する、出荷、輸送、および物流オペレーションを可能にする通信のためのコンピュータ化されたシステムを備えるネットワークの例示的な実施形態を示す概略ブロック図である。 開示された実施形態と一致する、対話型ユーザインターフェース要素と共に、検索要求を満たす１つまたは複数の検索結果を含む例示的な検索結果ページ（ＳＲＰ）を示す図である。 開示された実施形態と一致する、対話型ユーザインターフェース要素と共に製品および製品に関する情報を含む例示的な単一ディスプレイページ（ＳＤＰ）を示す図である。 開示された実施形態と一致する、対話型ユーザインターフェース要素と共に仮想ショッピングカート内のアイテムを含む例示的なカートページを示す図である。 開示された実施形態と一致する、対話型ユーザインターフェース要素と共に、購入および出荷に関する情報と共に仮想ショッピングカートからのアイテムを含む例示的な注文ページを示す図である。 開示された実施形態と一致する、開示されたコンピュータ化されたシステムを利用するように構成されている例示的なフルフィルメントセンタの概略図である。 開示された実施形態と一致する、適切な荷物追跡プロセスを決定するために遵守される例示的なコンピュータ化された開始プロセスのフローチャートである。 開示された実施形態と一致する、荷物がキャンプゾーンに到着したと決定されたときに遵守される例示的なコンピュータ化された荷物追跡プロセスのフローチャートである。 開示された実施形態と一致する、荷物が発送されたと決定されたときに遵守される例示的なコンピュータ化された荷物追跡プロセスのフローチャートである。 開示された実施形態と一致する、荷物を配送することができなかったと決定されたときに遵守される例示的なコンピュータ化された荷物追跡プロセスのフローチャートである。 開示された実施形態と一致する、荷物の配送に成功したと決定されたときに遵守される例示的なコンピュータ化された荷物追跡プロセスのフローチャートである。 開示された実施形態と一致する、ＳＡＴシステム１０１が、荷物が再注文の条件を満たしたと決定したときに遵守することができる例示的な再注文プロセス８００を示す図である。

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

本開示の実施形態は、自動小包追跡および処理のために構成されたシステムおよび方法に関する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１Ａに戻って参照すると、個々の荷物を識別および追跡するための荷物追跡プロセスの例示的な実施形態が説明される。いくつかの実施形態では、ＳＡＴシステム１０１は、荷物追跡プロセスを開始し、外部フロントエンドシステム１０３、出荷および注文追跡（ＳＯＴ）システム１１１、ＦＯシステム１１３、ＦＭＧ １１５、ＷＭＳ １１９、および３ＰＬシステム１２１Ａ～１２１Ｃなどの他のシステムから、現在保留中の注文および返品に関連付けられている個々の荷物に対応する荷物情報を電子的に要求および集約することができる。荷物は、一意の荷物識別子を使用して電子システム（例えば、ＳＡＴシステム１０１、ＦＯシステム１１３など）のネットワークによって追跡されるように、注文または返品に関連付けられている１つまたは複数のアイテムを保持する物理的なコンテナ（例えば、箱、小包、封筒、または１つもしくは複数のアイテムを保持するように構成された任意のパッケージング）を指すことができる。

電子要求および情報の集約は、１日１回（例えば、１日の終わりに）、定期的な間隔を置いてもしくは必要に応じて１日に複数回、または種々のシステムが追加情報（例えば、配送ステータス更新）を生成するときにリアルタイムで発生し得る。種々のシステムはまた、各々異なる時間、間隔、または頻度で、ＳＡＴシステム１０１を用いて情報を電子的に送受信することができる。ＳＡＴシステム１０１と各異なるシステムとの間の情報の通信および転送は以下に説明する。

いくつかの実施形態では、ＳＡＴシステム１０１は、外部フロントエンドシステム１０３、内部フロントエンドシステム１０５、または顧客返品システム（図示せず）から注文情報を電子的に要求および集約することができる。ＳＡＴシステム１０１から情報に対する電子要求を受信すると、外部フロントエンドシステム１０３、内部フロントエンドシステム１０５、または顧客返品システム（図示せず）は、すべての注文、返品をコンパイルし、ならびに／または、例えば、注文内のアイテム、各アイテムの数量、およびＰＤＤを含むことができるデータを交換することができる。次に、収集された注文情報は、さらなる処理のためにＳＡＴシステム１０１に電子的に送信される。ＳＡＴシステム１０１は、注文情報が連続的に更新されるように、外部フロントエンドシステム１０３、内部フロントエンドシステム１０５、または顧客返品システム（図示せず）と連続的に通信することができる。代替的に、システムは、事前定義された間隔を置いてまたは事前定義された時間に通信し、ＳＡＴシステム１０１に記憶された注文情報を、外部フロントエンドシステム１０３、内部フロントエンドシステム１０５、または顧客返品システム（図示せず）において収集された新しい注文情報によって随時更新することができる。

いくつかの実施形態では、ＳＡＴシステム１０１はまた、ＳＯＴシステム１１１からの配送ステータス情報を電子的に要求および集約することもできる。ＳＡＴシステム１０１は、ＳＯＴシステム１１１と連続的に通信することができ、その結果、各配送試行が配送作業員２２４Ａもしくは２２４Ｂによって行われるとき、または各配送実行の終了時に、配送ステータス情報が連続的に更新される。代替的に、システムは、事前定義された間隔を置いてまたは事前定義された時間に通信し、ＳＡＴシステム１０１に記憶された配送ステータス情報を、ＳＯＴシステム１１１において収集された新しい注文情報によって随時更新することができる。配送ステータス情報は、配送作業員２２４Ａまたは２２４Ｂが、上記のようにモバイルデバイスを使用した対応する配送の試みの後に、各荷物の荷物識別子をスキャンしまたは読み取るときに生成されるイベントデータを含むことができる。

イベントデータは、例えば、スキャン／読み取り時刻、日付、荷物識別子、配送ステータス、および目的の受取人を含むことができる。配送試行が失敗した場合、イベントデータはまた、キャンプゾーン２１５における容量超過の判定、配送中のリソースの不足の判定、荷物のソートが誤っていたことの判定、受取人の不在、または荷物の破損など、試行が失敗した理由も含むことができる。不達の他の理由は、当業者には明らかであり、本発明の範囲内である。モバイルデバイス（例えば、図１のデバイス１０７Ａ～１０７Ｃ）を使用する配送作業員２２４Ａまたは２２４Ｂは、ユーザインターフェースに表示されるドロップダウンリストから１つまたは複数の理由を選択することによって、イベントデータに不達の理由を追加することができる。次に、ＳＡＴシステム１０１は、以下に説明するように、１つまたは複数の対応する理由コードをイベントデータおよび／または対応する荷物情報に追加することができる。さらに、配送作業員２２４Ａまたは２２４Ｂが配送実行中に顧客から返送された荷物をピックアップした場合、イベントデータはまた、返送された荷物の情報を含むことができる。

いくつかの実施形態では、ＳＡＴシステム１０１はまた、ＷＭＳ１１９および３ＰＬシステム１２１Ａ～１２１Ｃから荷物情報を電子的に要求および集約することもできる。ＳＡＴシステム１０１、ＷＭＳ１１９、および３ＰＬシステム１２１Ａ～１２１Ｃは、各荷物が、上記のようにモバイルデバイスを使用してユーザによってスキャンまたは読み取られるときに荷物情報が連続的に更新されるように、互いに連続的に通信することができる。代替的に、システムは、事前定義された間隔を置いてまたは事前定義された時間に通信し、ＳＡＴシステム１０１に記憶された荷物情報を、他のシステムにおいて収集された新しい荷物情報によって随時更新することができる。荷物情報は、キャンプへの到着または配送トラックへの積み込みなどの特定のイベントを示すための、ユーザが各荷物の荷物識別子をスキャンまたは読み取るときのイベントデータを含むことができる。イベントデータは、荷物識別子、時間、日付、場所、ユーザ識別子、または他の情報をさらに含むことができる。

ＷＭＳ１１９および３ＰＬシステム１２１Ａ～１２１Ｃから荷物情報を要求および収集するために、ＳＡＴシステム１０１は電子要求をＦＯシステム１１３に送信することができ、ＦＯシステム１１３はその後、電子要求をＦＭＧ１１５に転送することができる。次に、ＦＭＧ１１５は、電子要求を上記のように各システムに適切な別のフォーマットまたはプロトコルに変換した後、ＷＭＳ１１９および３ＰＬシステム１２１Ａ～１２１Ｃの各々に電子要求を送信することができる。

ＳＡＴシステム１０１からの電子要求に関係なく、ＷＭＳおよび３ＰＬシステム１２１Ａ－１２１Ｃは、荷物がキャンプゾーン２１５に到着するか、またはトラック２２２もしくは車２２６に積み込まれるときに個々のデバイス（例えば、デバイス１０７Ａ～１０７Ｃまたは１１９Ａ～１１９Ｃ）から収集されるイベントデータに基づいて、各荷物に対応する荷物情報を連続的に収集および更新することができる。上記のように、荷物に対応する荷物情報は、荷物識別子に基づいて編成することができ、新しいイベントデータは、荷物識別子に基づいて適切な荷物情報に関連付けることができる。いくつかの実施形態では、荷物識別子は、最初はキャンプゾーン２１５に到着するとき、および、２回目は配送のためにトラック２２２または車２２６に積み込まれるときの少なくとも２回、スキャンまたは読み取ることができる。配送作業員２２４Ａまたは２２４Ｂが、荷物のパッケージング（例えば、箱、封筒、またはテープ）および／またはその中身が破損していることに気付いた場合にも、荷物をスキャンまたは読み取ることができる。

ＷＭＳ１１９または３ＰＬシステム１２１Ａ～１２１Ｃの各々のすべての荷物に関連するイベントデータが集約されるか、各荷物のイベントデータが生成されると、イベントデータはＦＭＧ１１５に送信され、ＦＭＧ１１５はこれを必要に応じて標準化フォーマットに変換する。次に、ＦＭＧ１１５は、変換されたイベントデータをＦＯシステム１１３に転送し、次にＦＯシステム１１３は、イベントデータをＳＡＴシステム１０１に転送する。

ＷＭＳ１１９または３ＰＬシステム１２１Ａ～１２１Ｃからの情報が集約されると、ＳＡＴシステム１０１は、集約された情報をリアルタイムで処理して、例えば、任意の所与の瞬間においてシステム１００を通じて処理されている荷物のデータベースを維持することができる。代替的に、このプロセスは、１日１回、定期的な間隔を置いてもしくは必要に応じて１日複数回、または他のシステムから追加の情報が集約されるときにリアルタイムで実施されてもよい。処理は、情報を解析して標準化されたフォーマットまたはプロトコルにすることと、１つまたは複数の荷物識別子（および、したがって対応する荷物）を各注文にマッピングすることと、個々の荷物識別子に基づいてすべてのイベントデータを統合しソートすることと、少なくとも対応する荷物識別子に対応するイベントのシーケンスに基づいて、個々の荷物の履歴を決定することと、それぞれの最後のイベントに基づいて、個々の荷物の現在のステータスを決定することとを含むことができる。荷物がとることができるステータスは、例えば、キャンプゾーンに到着したこと４０１、発送されたこと５０１、配送試行の失敗６０１、および配送の成功７０１を含むことができる。

図３は、開示された実施形態と一致する、荷物のステータスおよび遵守すべき適切な荷物追跡プロセスを決定するためにＳＡＴシステム１０１が遵守する例示的なコンピュータ化された開始プロセス３００のフローチャートである。いくつかの実施形態では、ＳＡＴシステム１０１は、荷物に関連付けられている最後のイベントデータおよび／または荷物に関連付けられているイベントのシーケンスに基づいてステータス決定を行うことができる。ステップ３０１から開始して、ＳＡＴシステム１０１は、いくつかの実施形態では、例えば、ＷＭＳ１１９から、対応する荷物識別子に関連付けられている最後のイベントデータを要求することによって、荷物のステータスを決定することができる。

代替的にまたは付加的に、最後のイベントデータが、例えば、荷物が喪失したとマークされたことを示す場合、ＳＡＴシステム１０１は、前のイベントデータまたはユーザ識別子などの他の付随するデータに基づいて最後の分かっている位置を決定し（例えば、ユーザ識別子、および、したがってユーザの割り当てられている作業領域に基づいて決定する）、それに応じてステータスを更新することができる。例えば、前のイベントデータは、荷物が発送されたことを示すことができ、その場合、ＳＡＴシステム１０１は、ステータスを発送された５０１と設定する。矛盾した指示を有する荷物識別子の複数のイベントデータが存在するいくつかの実施形態では、ＳＡＴシステム１０１は、矛盾するイベントデータの最新のものに基づいてステータスを決定し、他を無視することを選択することができる。いくつかの実施形態では、ＳＡＴシステム１０１はまた、荷物の現在のステータスが不正確であると判定し、ステータスを変更することもできる。

図３に戻って参照すると、ＳＡＴシステム１０１は、ステップ３０３において、最後のイベントが、荷物がキャンプゾーン２１５に到着したことを示しているか否かを決定することができる。肯定的である場合、ＳＡＴシステム１０１は、ステップ３０５において、そのステータスが、荷物がキャンプゾーン２１５に到着したことを示すように、荷物に関連付けられている荷物情報を更新することができる。次に、プロセスは、図４の荷物追跡プロセス４００に続くことができる。

ステップ３０３からの判定が否定的である場合、ＳＡＴシステム１０１は、ステップ３０７において、最後のイベントが、荷物が発送されたことを示しているか否かを判定することができる。この判定の結果が肯定的である場合、ＳＡＴシステム１０１は、ステップ３０９において、そのステータスが、荷物がトラック２２２または車２２６に積み込まれ、発送されたことを示すように、荷物に関連付けられている荷物情報を更新することができる。次に、プロセスは、図５の荷物追跡プロセス５００に続くことができる。

ステップ３０７における判定が否定的である場合、ＳＡＴシステム１０１は、ステップ３１１において、最後のイベントが、配送試行が行われたが失敗したことを示しているか否かを判定することができる。この判定の結果が肯定的である場合、ＳＡＴシステム１０１は、ステップ３１３において、そのステータスが、配送試行が失敗したことを示すように、荷物に関連付けられている荷物情報を更新することができる。次に、プロセスは、図６の荷物追跡プロセス６００に続くことができる。

ステップ３１１における判定が否定的である場合、ＳＡＴシステム１０１は、荷物の配送に成功したと判定し、ステップ３１５において、そのステータスが、配送が成功したことを示すように、荷物に関連付けられている荷物情報を更新することができる。次に、プロセスは、図７の荷物追跡プロセス７００に続くことができる。

４つの異なるステータスは、例としての役割を果たすようにのみ意図されており、ステータスの代替セットもまた、開示された実施形態の範囲内であり、開始プロセス３００は、ステータスの代替セットに対応するために他の判定を追加または削除するように変更されてもよい。

図４～７を参照して、開示された実施形態と一致する、例示的な荷物追跡プロセス４００、５００、６００、および７００を以下に説明する。ＳＡＴシステム１０１は、所定の間隔（例えば、２４時間）を置いて、データベース内のすべての荷物を反復し、図３に照らして上述した判定に基づいて、荷物追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数を実施することができる。ＳＡＴシステム１０１は、データベース内の各荷物を通じて順次反復し、各荷物に割り当てられた対応するステータスに基づいて適切なプロセスを選択およびステップスルーし、ステータスに従って荷物をソートし、各プロセスをバッチにおいてまたは他の様態で実施することができる。

荷物追跡プロセス４００、５００、６００、および７００は、荷物がまだ配送されておらず、したがってＦＣ２００のどこかに対応する荷物を有するはずであることを示す各荷物の情報を、実際に対応する荷物に（例えば、「キャンプゾーンに到着した」というステータスを有する荷物情報に対応する荷物が実際にキャンプゾーン２１５に位置していることを検証することによって）マッピングすることができることを検証する役割を果たす。荷物追跡プロセス４００、５００、６００、および７００はまた、誤ったステータスが割り当てられた荷物情報を識別および修正し、必要に応じて荷物をソートし直すこともできる。４つの異なるプロセスは、例としての役割を果たすことのみを意図しており、上記で利用されたステータスのセットに一致するプロセスの代替のセットもまた、開示された実施形態の範囲内である。

いくつかの実施形態では、ＳＯＴシステム１１１、ＦＯシステム１１３、およびＷＭＳ１１９などの他のシステムは、ＳＡＴシステム１０１が荷物のデータベースを反復している間に荷物の処理を停止し、ＳＡＴシステム１０１が終了すると再開することができる。代替的に、他の実施形態では、ＳＯＴシステム１１１、ＦＯシステム１１３、およびＷＭＳ１１９などの他のシステムは、それぞれ、それらの通常の速度において荷物を処理し続けるか、またはそれらを減速して処理することができる。ＳＡＴシステム１０１がパッケージング追跡プロセスを実施している間に他のシステムによって生成されている追加のイベントデータは、一時的なロケーションに電子的に記憶することができ、ＳＡＴシステム１０１が荷物のデータベースを反復し終えた後、データベース内の荷物のリストと照合することができる。

出荷サイクルは、ＳＡＴシステム１０１がデータベース内のすべての荷物情報について荷物追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数の実施を完了した瞬間から、システム１００がすべての荷物の配送を試行し、ＳＡＴシステム１０１が、各荷物情報に対して荷物追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数を再び実施し始めようとしている所定の間隔（例えば、２４時間）の後の瞬間までの期間を指すことができる。出荷サイクルの開始は、就業日の終了または深夜と一致してもよく、その時点において、すべての荷物が積み込まれており、少なくとも１回は配送が試行されている。言い換えれば、各出荷サイクルは、ＳＡＴシステム１０１が荷物追跡プロセス４００、５００、６００、および７００を実施する期間によって分離されている。

すべての出荷サイクル中に、システム１００内のすべての荷物を、トラック２２２または車２２６を介して積み込まれ、発送されるように試行することができる（例えば、システム１００内のすべての荷物が少なくとも１日１回積み込まれ、送出される）ことに留意することが重要である。出荷サイクル中に荷物を少なくとも１回積み込むことができなかった場合、ＷＭＳ１１９は、キャンプゾーン２１５において容量超過のために荷物が配送されなかった（例えば、配送用の荷物がＦＣ２００において処理できる数を超えた）というイベントデータをＳＡＴシステム１０１の対応する荷物情報に追加することができる。１つまたは複数の荷物追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数が実施されている間、各荷物は異なる場所（例えば、キャンプゾーン２１５、トラック２２２または車２２６）にあり得ることにも留意されたい。

出荷サイクルの終わりに（すなわち、荷物追跡プロセス４００、５００、６００、および７００のいずれかが始まる前に）、ＳＡＴシステム１０１は、その荷物識別子がモバイルデバイス（例えば、１０７Ａ～１０７Ｃまたは１１９Ａ～１１９Ｃ）によってスキャンまたは読み取られた、現在システム１００にある荷物のリストを生成することができる。各荷物がスキャンまたは読み取られているときに、後で荷物追跡プロセス４００、５００、６００、または７００中に再注文の条件を満たすものとしてフラグを立てるために、破損した荷物を荷物のリストから省くことができる。

図４は、荷物がキャンプゾーン２１５に到着したと決定されたときにＳＡＴシステム１０１が遵守することができるコンピュータ化された荷物追跡プロセス４００を示す。荷物は、配送のために積み込まれた後、ハブゾーン２１３またはトラック２２２もしくは車２２６から到着したものであり得る。

ステップ４０３において、ＳＡＴシステム１０１は、対応する荷物識別子が前の出荷サイクルの終わりにスキャンされまたは読み取られたか否かを判定することによって、特定の荷物がシステム１００に存在するか否かを検証することができる。

ステップ４０３からの否定的な判定は、ステップ４０５において表されるように、荷物が失われた（すなわち、計上されていない）ことを示すことができ、ＳＡＴシステム１０１は、対応する荷物情報を更新して、ステップ４０７における再注文の条件を満たすとして荷物識別子にフラグを立てることができる。フラグ立ては、例えば、対応する荷物情報を記憶するデータベース内のパラメータ（例えば、優先度ステータスおよび／または荷物がより迅速に配送されるべきであることを示す）を変更することを含むことができる。（いくつかの実施形態では、再注文の条件を満たすものとして荷物識別子にフラグを立てると、方法は、以下でさらに詳細に説明される、図８のプロセス８００に進むことができる。）

他方、ステップ４０３からの肯定的な判定は、物理的な荷物が存在することを示すことができる。この場合、荷物は、内部遅延（例えば、キャンプゾーン２１５の容量を超えた）のためにキャンプゾーン２１５を離れたことがないか、または、荷物が直前の出荷サイクル中に発送されていたが、１つまたは複数の理由で（例えば、配送トラックが営業時間内に配送を完了できなかった）配送されずにキャンプゾーン２１５に戻った可能性がある。この状況では、ＳＡＴシステム１０１は、ブロック４０９において、ＳＯＴシステム１１１からの配送ステータス情報に基づいて、荷物が配送されなかった理由を決定することができる。

ステップ４１１において表されるように、不達が容量を超えたことによるものであると決定された場合、ＳＡＴシステム１０１は、ステップ４１３において、それがＰＤＤから第１の所定の期間（例えば、２日）を超えているか否かを判定することができる。ステップ４１１における超過される容量は、例えば、作業可能な配送作業員２２４Ａまたは２２４Ｂの数、配送のために利用可能なトラック２２２または車２２６の数、およびトラック２２２または車２２６上のスペースの量を含むことができる。他の実施形態では、荷物が再注文の条件を満たすとフラグが立てられる前に経過しなければならない時間長は、半日、３日などのような、２日未満または２日超であり得る。さらに他の実施形態では、時間長は、不足している特定のリソースに基づいて変化し得る。

ステップ４１３からの判定が肯定的である場合、ＳＡＴシステム１０１は、対応する荷物情報を更新して、上述したステップ４０７と同様に、ステップ４１５における再注文の条件を満たすとして荷物識別子にフラグを立てることができる。そうでない場合、ステップ４１７に示されるように、ＳＡＴシステム１０１は、対応する荷物情報を変更せずに残すことができ、その結果、荷物は、次の出荷サイクル中に再び配送を試行し、データベース内の次の荷物を処理することができる。

ブロック４０９に戻って参照すると、ステップ４１９に示されるように、代わりに顧客の過失が原因で不達が生じた場合、ＳＡＴシステム１０１は、ＰＤＤから第２の所定の時間長（例えば、４日）を超える時間が経過したか否かを判定し（ステップ４２１）、上記のステップ４０７と同様に、ステップ４２３において再注文の条件を満たすものとして対応する荷物識別子にフラグを立てることができる。そうでない場合、ステップ４２５に示されるように、ＳＡＴシステム１０１は、対応する荷物情報を変更せずに残すことができる。他の実施形態では、第２の所定の時間長は、半日、５日など、４日未満または４日超であってもよい。さらに他の実施形態では、時間長は、顧客によって引き起こされる特定の遅延に基づいて変化してもよい。

ブロック４０９に戻って参照すると、代わりに、４２７に表されるように、荷物の喪失または破損が原因で不達が生じた場合、ＳＡＴシステム１０１は、ステップ４０３において荷物が存在する（すなわち、物理的に存在し、破損していない）と以前に決定されているため、荷物情報にエラーがあると判定することができ、さらに、不達の理由は、荷物が喪失または破損していることを示している。この場合、ＳＡＴシステム１０１は、荷物情報内の不達の理由を、ステップ４２９において表される「容量超過」にオーバーライドすることができ、したがって、不達の未知の理由を、例えば、顧客の過失とは対照的に内部遅延に帰することができる。

ステップ４２７における判定が否定的であり、不達の理由が他の何かであったことを示す場合、ＳＡＴシステム１０１は、ステップ４３１において対応する荷物情報を変更せずに残すことができ、その結果、荷物は、次の出荷サイクル中に再び配送を試行し、データベース内の次の荷物を処理することができる。

図５は、例えば、荷物が直前の出荷サイクル中に発送されたが配送試行が行われなかった場合に、荷物が発送されたと判定されたときにＳＡＴシステム１０１が従うことができるコンピュータ化された荷物追跡プロセス５００を示す。

ステップ５０３において、ＳＡＴシステム１００は、ステップ４０３に関して上記で説明したように、荷物がまだシステム内に存在するか否かを検証することができる。ステップ５０３からの否定的な判定は、ステップ５０５において表され、ステップ４０５に関して上述されたように、荷物が失われたことを示すことができる。このとき、ＳＡＴシステム１０１は、上述したステップ４０７と同様に、ステップ５０７における再注文の条件を満たすとして対応する荷物識別子にフラグを立てることができる。

他方、ステップ５０３において荷物が存在すると検証された場合、ＳＡＴシステム１０１は、ブロック５０９において、ＳＯＴシステム１１１からの配送ステータス情報に基づいて、荷物が配送されなかった理由を判定することができる。不達が配送時間などのリソースの不足によるものであると判定された場合、ＳＡＴシステム１０１は、ステップ４１３～４１７に関して上記で説明したように、ＰＤＤから第１の所定の時間長を超える時間が経過したか否かを判定し（ステップ５１３）、経過している場合、対応する荷物情報に再注文の条件を満たすとしてフラグを立てることができ（ステップ５１５）、または、対応する荷物情報を変更せずに保持する（ステップ５１７）ことができる。

代替的に、ステップ５１９に表されるように、不達が代わりに顧客の過失によるものであると判定された場合、ＳＡＴシステム１０１は、ステップ５２１～５２５に関して上記で説明したように、ＰＤＤから第２の所定の時間長を超える時間が経過したか否かを判定し（ステップ５２１）、経過している場合、対応する荷物情報に再注文の条件を満たすとしてフラグを立てることができ（ステップ５２３）、または、荷物情報を変更せずに保持する（ステップ５２５）ことができる。

それでもなお、ブロック５０９において、不達が代わりに５２７に表されるように荷物の喪失または破損が原因であると判定された場合、ＳＡＴシステム１０１は、ステップ４２７に関して上述したようにエラーがあると判定することができる。この場合、ＳＡＴシステム１０１は、配送されなかった理由を「ソートの誤り」（ステップ５２９）にオーバーライドすることができ、これは、以前の判定が、荷物が発送されたが（ステップ５０１）、何らかの理由でまだキャンプゾーン２１５にあることを示し（ステップ５０３）、荷物が本来あるべき場所になかったことを示唆しているため、荷物が誤ってソートされた（例えば、間違った配送トラック２２２または車２２６に積み込まれた）ことを示す。ＳＡＴシステム１０１は、後続の出荷サイクル中にこれらの荷物の配送を試行することができる。

ステップ５２７における判定が否定的であり、不達の理由が他の何かであったことを示す場合、ＳＡＴシステム１０１は、ステップ４３１に関して上述したように、対応する荷物情報を変更せずに保持することができる（ステップ５３１）。

図６は、ＳＡＴシステム１０１が、例えば、直前の出荷サイクル中に荷物の配送に失敗したと判定した場合に（例えば、配送人員２２４Ａまたは２２４Ｂが受取人の住所に到着したが、受取人がいないため、配送を完了できなかった）、ＳＡＴシステム１０１が従うことができるコンピュータ化された荷物追跡プロセス６００を示す。

ステップ６０３において、ＳＡＴシステム１０１は、ステップ５０３に関して上記で説明したように、荷物がまだシステム内に存在するか否かを検証することができる。ステップ６０３からの否定的な判定は、ステップ６０５において表されるように、荷物が失われたことを示すことができる。このとき、ＳＡＴシステム１０１は、上述したステップ４０７と同様に、ステップ６０７における再注文の条件を満たすとして対応する荷物識別子にフラグを立てることができる。

ステップ６０３において荷物が存在すると検証された場合、ＳＡＴシステム１０１は、ブロック６０９において、ＳＯＴシステム１１１からの配送ステータス情報に基づいて、荷物が配送されなかった理由を判定することができる。ステップ６１９に表されるように、不達が代わりに顧客の過失によるものであると判定された場合、ＳＡＴシステム１０１は、ステップ６２１～６２５に関して上記で説明したように、ＰＤＤから第２の所定の時間長を超える時間が経過したか否かを判定し（ステップ６２１）、経過している場合、対応する荷物情報に再注文の条件を満たすとしてフラグを立てることができ（ステップ６２３）、または、荷物情報を変更せずに保持する（ステップ６２５）ことができる。

代替的に、ブロック６０９において、不達が代わりに６２７に表されるように荷物の喪失または破損が原因であると判定された場合、ＳＡＴシステム１０１は、ステップ５２７～５２９に関して上述したようにエラーがあると判定し、不達の理由を「ソートの誤り」にオーバーライドすることができる（ステップ６２９）。ステップ６２７における判定が否定的であり、不達の理由が他の何かであったことを示す場合、ＳＡＴシステムは、ステップ４３１に関して上記で前述したように、対応する荷物情報を変更せずに保持することができる（ステップ６３１）。

この場合、配送が実際に試みられたため、すなわち、例えば、配送人員 ２２４Ａまたは２２４Ｂに、受取人の住所に到着して配送を試行するのに十分なリソースがあったため、ＳＡＴシステム１０１は、他の荷物追跡プロセス４００および５００の場合のように、不達がリソースの不足によるものであるか否かを考慮しなくてもよい。

図７は、ＳＡＴシステム１０１が、例えば直前の出荷サイクル中に荷物の配送に成功したと判定したときに従う荷物追跡プロセス７００を示している。

ステップ７０３において、ＳＡＴシステム１０１は、ステップ５０３に関して上記で説明したように、荷物がまだシステム内に存在するか否かを検証することができる。否定的な判定は、荷物がシステム１００内に存在しないことを正しく示し、配送された荷物がシステム１００内に存在し得ないことは事実であるため、対応する荷物情報はステップ７０５において変更されないままである。一方、肯定的な判定は、配送された荷物がシステム１００にもはや存在し得ないため、ＳＯＴシステム１１１からの情報、したがって、荷物の現在のステータスが不適切である可能性があることを示す。この場合、ＳＡＴシステム１０１は、ステップ７１１において、荷物に関連付けられている情報をオーバーライドして、リソースの不足のために荷物が配送されなかったことを示すことができる。次に、ＳＡＴシステム１０１は、ステップ７１３において、ＰＤＤから第１の所定の時間長を超える時間が経過したか否かを判定し、ステップ５１３～５１７に関して上記したように、判定に基づいてステップ７１５または７１７において適切な措置をとることができる。他の実施形態では、ＳＡＴシステム１０１は、ステップ７１１において、対応する荷物情報をオーバーライドして、異なるステータスおよび／または配送の失敗の理由を割り当てることができる。

いくつかの実施形態では、ブロック４０９、５０９、６０９、７０９は、より多くの不達の理由を含むように拡張することができる。不達の理由４１１、４１９、４２７、５１１、５１９、５２７、６１９、および６２７も、より詳細な副理由を含むように分割することができる。例えば、理由５１１は、不足している種々のリソースに基づいて副理由に分割することができ、理由５１９は、顧客によって引き起こされた種々のタイプの遅延に基づいて副理由に分割することができる。さらに、ステップ４１３、４２１、５１３、５２１、６２１、および７１３における第１の所定の時間長および第２の所定の時間長は、ステータスおよび不達の理由の組み合わせに基づいて６つ以上の所定の時間長を含むように互いに異なることができる。所定の時間長のより多くのグループのうちの１つが等しい時間長を有する代替の実施形態もまた、本発明の範囲内である。

いくつかの実施形態では、ＳＡＴシステム１０１が、上記のように、ステップ４０７、４１５、４２３、５０７、５１５、５２３、６０７、６２３、および７１５のうちの少なくとも１つまたは複数に基づいて再注文される荷物を決定すると、そのような荷物は、荷物を再注文し、それらをシステム１００を通して急送させるための別の例示的なプロセスを通して処理される。

いくつかの実施形態では、システムを通じて荷物を急送させることは、決定された緊急コードまたは荷物がより迅速に配送される必要があることを示す荷物識別子に基づくことができる。緊急コードは、例えば、荷物にフラグを立てることによって、ＳＡＴシステム１０１が荷物に割り当てるコードであり得、１つまたは複数の不達の理由（例えば、理由４１１、４１９、４２７、５１１、５１９、５２７、６１９、および６２７）に基づくことができる。いくつかの実施形態では、ＳＡＴシステム１０１は、１つまたは複数の不達の理由に対応する１つまたは複数の緊急コードを有し得る。例えば、第１の緊急コードは、第２の緊急コードよりも高い優先度を示し得る（すなわち、第１の緊急コードを有する荷物は、第２の緊急コードを有する荷物よりも迅速に配送されるべきである）。

さらに、いくつかの実施形態では、ＳＡＴシステム１０１はまた、内部ユーザ（例えば、システム１００を所有、運用、またはリースする組織の従業員）からの要求の受信時に対応する荷物情報を更新することによって、再注文するための荷物を示すこともできる。さらに、いくつかの実施形態では、荷物に再注文のフラグが立てられると、ＳＡＴシステム１０１は、別の荷物（例えば、以前のウェーブ中に配送されなかったアイテムを含む）を配送することができる次の利用可能なウェーブを決定し、次の利用可能なウェーブにおいて荷物を配送するための命令を自動的に送信することができる。

いくつかの実施形態では、再注文プロセスは、対応する荷物情報において再注文するように示された荷物（すなわち、フラグが立てられた荷物）によって保持されるアイテムを識別することと、対応する荷物識別子に関連付けられている注文を識別することと、識別された注文の一部をキャンセルすることと、識別されたアイテムを使用して新しい注文を作成および処理することと、新しい注文に関連付けられている荷物情報を優先度の高いものとして更新することと、対応する荷物を新しい配送ルートおよび／またはサブルートを介して配送することとを含むことができる。

図８は、開示された実施形態と一致する、ＳＡＴシステム１０１が、荷物が再注文の条件を満たしたと決定したときに遵守することができる例示的な再注文プロセス８００を示す図である。

図８はステップ８０１によって開始する。荷物に再注文のフラグが立てられると（例えば、荷物が、ステップ４０７、４１５、４２３、５０７、５１５、５２３、６０７、６２３および７１５のうちの少なくとも１つに基づくステップのうちの１つまたは複数に基づいて再注文の条件を満たしている）、プロセスはステップ８０３に続くことができる。

ステップ８０３において、ＳＡＴシステム１０１は、ステップ８０３においてフラグが立てられた荷物に対応する注文の少なくとも一部をキャンセルすることができる。例えば、注文は、アイテムの第１のグループを含む第１の荷物を含む、複数の荷物を含むことができる。開示された追跡プロセス中のある時点において、アイテムの第１のグループを含む第１の荷物は、上記のように、１つまたは複数の理由に基づいて再注文のフラグが立てられる場合がある。しかしながら、複数の荷物内の残りの荷物は、再注文のフラグが立てられない場合があり、上記荷物をキャンセルしてそれらの配送を遅らせる必要はないことになる。この例では、ステップ８０３において、ＳＡＴシステムは、フラグが立てられた荷物（すなわち、アイテムの第１のグループを含む第１の荷物に対応する注文の部分のみをキャンセルする。注文の一部をキャンセルすることは、例えば、荷物の配送を停止する、荷物を省く、または荷物をＦＣ１００に戻すための命令を、システム１００内の１つまたは複数のデバイスに送信することを含むことができる。

ステップ８０５において、ＳＡＴシステム１０１は、現在の時刻と、複数の今後の配送ウェーブに関連付けられている複数の締め切り時刻の両方を決定することができる。これらの締め切り時刻は、荷物自体に関連付けることができ、および／または、荷物に含まれている１つもしくは複数の個別のアイテムに関連付けることができる。

ステップ８０７において、ＳＡＴシステム１０１は、各締め切り時刻と決定された現在の時刻との間の比較を行うことができる。

ステップ８０９において、ＳＡＴシステム１０１は、配送ウェーブの締め切り時刻がすでに経過したか否かを判定することができる。比較に基づいて、ＳＡＴシステム１０１は、ステップ８１３において配送に関連付けられている新しいスケジュールされた配送を決定することができる。この例では、この決定は、ステップ８０９であるか否かの判定に基づくことができる。現在の時刻が締め切り時刻より前でない場合（すなわち、締め切り時刻が経過していない場合）、ＳＡＴシステムは、ステップ８１１に表されるように、その締め切り時刻に関連付けられている配送ウェーブに再スケジュールせず、ステップ８０７に戻って、異なるウェーブに関連付けられている異なる締め切り時刻との別の比較を行う。

いくつかの実施形態では、ステップ８１３の詳細における新しい予定された配送を決定することは、付加的または代替的に、荷物に関連付けられている決定された緊急コード、または荷物がより迅速に出荷される必要があるとしてフラグが立てられているか否かに基づくことができる。例えば、第１の荷物が再注文のフラグが立てられ、第２の荷物が再注文のフラグが立てられ、より高い緊急コードを有するか、またはより早く出荷する必要があるとフラグが立てられている場合、ＳＡＴシステム１０１は第２の荷物の配送を優先することができる。いくつかの実施形態では、プロセス８００は、新しいルートが利用可能である場合に、新しい荷物を配送するために最適化された新しいルートを作成することをさらに含むことができる。

配送ウェーブに関連付けられている新しい配送時間が決定されると、ＳＡＴシステム１０１は、配送ウェーブに関連付けられている配送時間に基づいて荷物を配送するための命令を送信する。荷物に再注文のフラグが立てられたと判定したときにこのプロセスを自動的に実施することにより、ＳＡＴシステム１０１は、事業費への影響を常に最小限に抑えながら、まだ配送されていない残存する注文の数を大幅に減らすことができる。

曖昧さを生じさせずに説明を容易にするために、再注文プロセスは、注文が第１の荷物識別子および対応する第１の荷物情報を有する第１の荷物にともにパッケージされたアイテムの第１のグループ、ならびに、第２の荷物識別子および対応する第２の荷物情報を有する第２の荷物にともにパッケージされたアイテムの第２のグループを含む例を使用して説明される。この例では、ＳＡＴシステム１０１は、第１の荷物を目的の受取人へと配送するのに成功したが、第２の荷物が破損したと判定し得る。この場合、ステップ４１５に関して上記で説明したように、ＳＡＴシステム１０１は、存在する場合、上記の荷物追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数から決定されるように再注文される必要があり得るデータベース内の他の荷物と共に、第２の荷物識別子に、再注文の条件を満たすものとしてフラグを立てるように、第２の荷物情報を更新することができる。

次に、再注文プロセスの一部として、ＳＡＴシステム１０１は、手動検査時の荷物の実際の内容、ならびに／または、上記の方法で収集された注文情報および荷物情報に基づく、第２の荷物（この例では、上記で定義されたアイテムの第２のグループ）内のアイテムの識別に進むことができる。アイテムおよび注文が識別されると、ＳＡＴシステム１０１は、再注文のために示されておらず、他の様態でも問題のない注文の他の部分に影響を与えることなく、アイテムに対応する注文の部分のキャンセルに進むことができる。次に、ＳＡＴシステム１０１は、アイテムの第２のグループを含む新しい注文を作成することを求める要求をＦＯシステム１１３に送信することができる。実効的には、アイテムの単一のグループを含み、したがって単一の荷物にパッケージされる部分注文が作成され、他の荷物と共に処理されるように、システム１００内に配置される。

いくつかの実施形態では、ＳＡＴシステム１０１はまた、対応する新しい荷物情報を「高優先度」として示すこともでき、これは、他のシステム要素（例えば、ＳＯＴシステム１１１およびＷＭＳ１１９）に通信され、内部ユーザ（例えば、システム１００を所有、運用、またはリースする組織の従業員）および／または配送作業員２２４Ａもしくは２２４Ｂへの通知として表示される。輸送システム１０７の１つもしくは複数のモバイルデバイス１０７Ａ～１０７Ｃおよび／またはＦＣ２００の１１９Ａ～１１９Ｃは、対応する荷物識別子をスキャンまたは読み取るときに「高優先度」通知を表示することができ、結果、内部ユーザは他の荷物の前にその荷物を処理することを優先することができる。

いくつかの実施形態では、優先度の高い荷物は、優先度の低い荷物が他にいくつあり得るかに関係なく、可能な限り迅速に荷物がパッケージされ、配送されることを確実にするために、各システム内の内部ユーザの専用グループ（例えば、輸送システム１０７の内部ユーザのグループまたはＷＭＳ１１９の内部ユーザのグループ）によって処理し、配送することができる。またさらに、いくつかの実施形態では、ＳＯＴシステム１１１は、優先度の高い荷物の配送を最適化するように構成された新しい配送ルートおよび／またはサブルートを作成することができる。

状況によっては、ＳＡＴシステム１０１は、元の注文時に作成された元のＰＤＤ以前に新しい荷物を配送することができないと判定する場合がある。これらの場合、ＳＡＴシステムは、上記の１つまたは複数の要因に基づいて、更新されたＰＤＤを求める要求をＦＯシステム１１３に送信することができる。更新されたＰＤＤは、内部注文追跡に使用することができ、または、注文ステータスを通知するために目的の受取人および／もしくは購入者に開示することができる。

いくつかの実施形態では、荷物追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数に基づいて失われたと判定された荷物が、上記のように再注文プロセスによって処理される一方、内部ユーザの一部が、失われた荷物を見つけ、ＦＣ２００内にある返品ステージングゾーン（図示せず）に転送することに専念してもよい。代替的または付加的に、内部ユーザがそれぞれの通常の職務を実施している間に、以前に失われた１つまたは複数の荷物が発見され得、その時点で、内部ユーザはまた、荷物を返品ステージングゾーンに転送し得る。

上記の再注文プロセスによって作成された新しい優先度の高い荷物はキャンセルされて配送されないようにする必要があり、システム１００の速度が低下する可能性があるため、システム１００は、発見された荷物を元の目的の受取人に再配送しようとしないことが好ましい。さらに、いくつかの実施形態では、荷物追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数に基づいて破損していると判定された荷物は、その中のアイテムを回収することができるように、返品ステージングゾーンに転送することもできる。その中のアイテムのサブセットは、まだ販売可能な状態にある場合がある。

いくつかの実施形態では、発見された喪失荷物、破損した荷物、および／または再注文の条件を満たすとしてフラグが立てられたために目的の受取人に到達する前にキャンセルされた他の荷物は、補充のために返品ステージングゾーンに転送される。そのような実施形態では、ＳＡＴシステム１０１は、顧客から受け取った返品荷物とは異なり、転送された荷物に対応する荷物情報を内部返品として更新することができる。そのような転送された荷物内のアイテムは、システム１００を介して処理されていたときに誰もそれらを開封していないため、他の顧客が開始した返品よりも密封された販売可能な状態にある可能性が比較的高い。したがって、その中にパッケージされたアイテムは、最小限の検査でピッキングゾーン２０９に転送および再ルーティングすることができ、それにより、比較的より徹底的な検査を実施するコストを節約し、処理時間を短縮し、重複注文のコストを節約する。

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

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

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

Claims (20)

1. 自動再出荷スケジューリングのためのコンピュータ実装システムであって、
   少なくとも１つのプロセッサと、
   前記少なくとも１つのプロセッサによって実行されると、ステップを実施する命令を含むメモリとを備え、前記ステップは、
   注文と、第１の荷物に関連付けられている第１の荷物識別子であり、前記第１の荷物は１つまたは複数のアイテムを含む、第１の荷物識別子と、前記第１の荷物識別子を含む複数の荷物識別子に関連付けられているイベントデータとを含む集約情報を受信することであって、前記注文は、アイテムの第１のグループを含み、前記第１の荷物は第１の受取人およびスケジュールされた配送時間に関連付けられていることと、
   前記第１の荷物識別子に基づいて前記イベントデータを解析することと、
   前記解析されたイベントデータに基づいて、前記第１の荷物が配送されなかったかを判定することと、
   第１の荷物が配送されなかったという判定に基づいて、
   前記第１の荷物識別子に第１の条件を満たすものとしてフラグを立てることと、
   前記第１の荷物に対応する前記注文の一部をキャンセルすることと、
   現在の時刻を決定することと、
   複数の締め切り時刻を決定することであって、前記複数の締め切り時刻の各締め切り時刻は、配送ウェーブに関連付けられることと、
   前記複数の締め切り時刻と前記現在の時刻との間の比較に基づいて、配送ウェーブに関連付けられている新しいスケジュールされた配送時間を決定することと、
   前記第１の荷物に含まれる前記１つまたは複数のアイテムを含む第２の荷物に対する新しい注文を作成することと、
   前記新しいスケジュールされた配送時間に関連付けられている前記配送ウェーブに基づいて、モバイルデバイスに前記新しい注文を配送するための命令を送信することと
   を含む、コンピュータ実装システム。
2. 前記締め切り時刻は、前記第１の荷物および前記配送ウェーブに関連付けられる、請求項１に記載のコンピュータ実装システム。
3. 前記配送ウェーブは、前記第１の荷物が配送されることが意図されている所定の期間を含む、請求項２に記載のコンピュータ実装システム。
4. 各々の日が複数の配送ウェーブに関連付けられており、各配送ウェーブが締め切り時刻および配送期間に関連付けられており、それぞれの締め切り時刻がそれぞれの配送期間の前に発生する、請求項３に記載のコンピュータ実装システム。
5. 前記イベントデータを解析することは、
   前記イベントデータをフィルタリングして、前記第１の荷物識別子に関連付けられている前記イベントデータを分離することと、
   前記分離されたイベントデータを解析して、時間的関係を決定することと、
   前記分離されたイベントデータおよび前記決定された時間的関係に基づいて時系列を決定することと、
   前記時系列に基づいて前記第１の荷物のステータスを決定することと
   を含む、請求項１に記載のコンピュータ実装システム。
6. 前記新しいスケジュールされた配送時間は、
   前記時系列に基づいて、前記第１の荷物が配送されなかった少なくとも１つの理由を決定することと、
   前記決定された理由に基づいて緊急コードを決定することと、
   前記決定された緊急コードに基づいて、前記第１の荷物を配送するための配送ウェーブを決定することと
   によって決定される、請求項５に記載のコンピュータ実装システム。
7. 前記少なくとも１つの理由は、
   前記第１の荷物が外部へ送出されなかったこと、
   前記第１の荷物が顧客の過失により配送されなかったこと、
   前記第１の荷物が容量超過のために配送されなかったこと、
   前記第１の荷物がリソース不足のために配送されなかったこと、
   前記第１の荷物が喪失のために配送されなかったこと、または
   前記第１の荷物が破損のために配送されなかったことから成る群から選択される、請求項６に記載のコンピュータ実装システム。
8. 前記荷物識別子に第１の条件を満たすものとしてフラグを立てることは、前記第１の荷物がより迅速に配送されるべきであることを示すように、前記荷物識別子に関連付けられているパラメータを更新することをさらに含む、請求項１に記載のコンピュータ実装システム。
9. 前記ステップは、
   前記第１の荷物識別子に関連付けられているパラメータが、前記第１の荷物をより迅速に配送する必要があることを示していると判定することと、
   前記判定に基づいて、前記命令を、前記第１の荷物が配送されなかったことを示すためにモバイルデバイスに送信されるように構成することと
   をさらに含む、請求項７に記載のコンピュータ実装システム。
10. 前記ステップは、
    前記第２の荷物を配送するために最適化された新しいルートを作成することをさらに含
    む、請求項９に記載のコンピュータ実装システム。
11. 自動再出荷スケジューリングのための方法であって、
    注文と、第１の荷物に関連付けられている第１の荷物識別子であり、前記第１の荷物は１つまたは複数のアイテムを含む、第１の荷物識別子と、前記第１の荷物識別子を含む複数の荷物識別子に関連付けられているイベントデータとを含む集約情報を受信することであって、前記注文は、アイテムの第１のグループを含み、前記第１の荷物は第１の受取人およびスケジュールされた配送時間に関連付けられていることと、
    前記第１の荷物識別子に基づいて前記イベントデータを解析することと、
    前記解析されたイベントデータに基づいて、前記第１の荷物が配送されなかったかを判定することと、
    第１の荷物が配送されなかったという判定に基づいて、
    前記第１の荷物識別子に第１の条件を満たすものとしてフラグを立てることと、
    現在の時刻を決定することと、
    複数の締め切り時刻を決定することであって、前記複数の締め切り時刻の各締め切り時刻は、配送ウェーブに関連付けられることと、
    前記複数の締め切り時刻と前記現在の時刻との間の比較に基づいて、配送ウェーブに関連付けられている新しいスケジュールされた配送時間を決定することと、
    前記新しいスケジュールされた配送時間に関連付けられている前記配送ウェーブに基づいて、前記第１の荷物に含まれる前記１つまたは複数のアイテムを含む第２の荷物に対する新しい注文を作成するための命令をモバイルデバイスに送信することと
    を含む、方法。
12. 前記締め切り時刻は、前記第１の荷物および前記配送ウェーブに関連付けられる、請求項１１に記載の方法。
13. 前記配送ウェーブは、前記第１の荷物が配送されることが意図されている所定の期間を含む、請求項１２に記載の方法。
14. 各々の日が複数の配送ウェーブに関連付けられており、各配送ウェーブが締め切り時刻および配送期間に関連付けられており、それぞれの締め切り時刻がそれぞれの配送期間の前に発生する、請求項１３に記載の方法。
15. 前記イベントデータを解析することは、
    前記イベントデータをフィルタリングして、前記第１の荷物識別子に関連付けられている前記イベントデータを分離することと、
    前記分離されたイベントデータを解析して、時間的関係を決定することと、
    前記分離されたイベントデータおよび前記決定された時間的関係に基づいて時系列を決定することと、
    前記時系列に基づいて前記第１の荷物のステータスを決定することと
    を含む、請求項１１に記載の方法。
16. 前記新しいスケジュールされた配送時間は、
    前記時系列に基づいて、前記第１の荷物が配送されなかった少なくとも１つの理由を決
    定することと、
    前記決定された理由に基づいて緊急コードを決定することと、
    前記決定された緊急コードに基づいて、前記第１の荷物を配送するための配送ウェーブ
    を決定することと
    によって決定される、請求項１５に記載の方法。
17. 前記荷物に第１の条件識別子を満たすものとしてフラグを立てることは、前記第１の荷物がより迅速に配送されるべきであることを示すように、前記荷物識別子に関連付けられているパラメータを更新することを含む、請求項１１に記載の方法。
18. 前記第１の荷物識別子に関連付けられているパラメータが、前記第１の荷物をより迅速
    に配送する必要があることを示していると判定することと、
    前記判定に基づいて、前記命令を、前記第１の荷物が配送されなかったことを示すため
    にモバイルデバイスに送信されるように構成することと
    をさらに含む、請求項１７に記載の方法。
19. 前記第２の荷物を配送するために最適化された新しいルートを作成することをさらに含
    む、請求項１８に記載の方法。
20. 自動再出荷スケジューリングのためのコンピュータ実装システムであって、
    少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサによって実行されると、ステップを実施する命令を含むメモリとを備え、前記ステップは、
    注文と、第１の荷物に関連付けられている第１の荷物識別子であり、前記第１の荷物は１つまたは複数のアイテムを含む、第１の荷物識別子と、前記第１の荷物識別子を含む複数の荷物識別子に関連付けられているイベントデータを含む集約情報を受信することであって、前記注文は、アイテムの第１のグループを含み、前記第１の荷物は前記アイテムの第１のグループに関連付けられており、１つまたは複数の既存のルートを通じて第１の所定の期間内に第１の受取人に配送されることになることと、
    前記第１の荷物識別子に基づいて前記イベントデータを解析することと、
    前記解析されたイベントデータに基づいて前記第１の荷物が存在するか否かを判定することと、
    前記第１の荷物が存在しないと判定された場合、前記第１の荷物識別子に第１の条件を満たすものとしてフラグを立てることと、
    前記第１の荷物が存在すると判定された場合、リソース不足のために前記第１の荷物が配送されなかったかを判定することと、
    リソース不足のために前記第１の荷物が配送されなかったと判定された場合、前記第１の所定の期間が第１の閾値を超えて経過した場合に、前記第１の荷物識別子に第２の条件を満たすものとしてフラグを立てることと、
    前記判定に基づいて、
    現在の時刻を決定することと、
    複数の締め切り時刻を決定することと、
    前記複数の締め切り時刻と前記現在の時刻との間の比較に基づいて、配送ウェーブに関連付けられている新しいスケジュールされた配送時間を決定することと、
    前記新しいスケジュールされた配送時間に関連付けられている前記配送ウェーブに基づいて、前記第１の荷物に含まれる前記１つまたは複数のアイテムを含む第２の荷物に対する新しい注文を作成するための命令をモバイルデバイス送信することと
    を含む、コンピュータ実装システム。

Images