JP6984025B2 - 自動パッケージ追跡および優先順位付け再注文のためのシステムおよび方法 - Google Patents

Description

[0001] 本開示は、概して、自動パッケージ追跡および処理のためのコンピュータ化されたシステムおよび方法に関する。特に、本開示の実施形態は、複数のサブシステムからのデータの収集に基づいて、物流管理システムを介してパッケージを追跡する、発明的かつ非従来的なシステムに関する。

[0002] コンピュータ技術の進歩および普及に伴い、電子商取引としても知られるオンラインショッピングが、商取引の主要な手段の１つとなっている。消費者および企業がオンラインベンダから商品を購入する頻度がこれまで以上に高く、取引件数・売上高は前年同期比で大きく伸びると見込まれている。電子商取引の範囲および量が増加し続けるにつれて、オンラインで利用可能な異なるアイテムの数および所与の期間に行われる購入の平均数の両方も指数関数的に増加している。例えば、１つの人気のあるオンライン小売業者によって販売された異なるアイテムの数は６億を超える製品に達したと言われ、同じ小売業者によって１日当たりに出荷されるパッケージの数は１６００万であると言われる。

[0003] 各オンライン購入は、本質的に、購入された商品のその意図された受取人への配達を必要とする。各オンライン購入または注文は、典型的には１つまたは複数の商品を含み、１つまたは複数の商品は、それぞれがそれ自体の約束された納期を有する１つまたは複数のパッケージにパッケージングされ得る。典型的な注文は、１つまたは複数の商品の注文を顧客から受けるステップ、１つまたは複数の商品を在庫から回収するステップ、１つまたは複数の商品を１つまたは複数のパッケージにパッケージングするステップ、および１つまたは複数のパッケージを約束された納期前に意図された受取人に引き渡すステップなどを介して処理することができる。約束された納期は、小売業者または出荷宅配業者が設定することができ、または顧客が特定の日を要求することができ、その場合、約束された納期として指定することができる。注文処理の理想的なシステムは、各パッケージを意図された受取人に、約束された配達日までに失敗なく配達する。

[0004] 現在存在する注文処理システムは、上述のステップを実施する際に、様々な程度の自動化および複雑さを含む。しかしながら、注文がサブシステムの複雑なネットワークを通過する必要があり、一部の注文が部分的な返品などの複雑な要因を有するという事実によって、異なる商品および注文の数が増加することにつれて、現在のシステムは注文がなされた瞬間から注文が履行された瞬間まで（すなわち、注文中のすべてのパッケージが、意図された受取人に配達されるか、または在庫に返品されるまで）、個々のパッケージを追跡することができないか、またはほとんど効率が悪いという点で、問題がある。この問題は、パッケージの数を増やし、迅速な処理に焦点を当てることによって、システムがパッケージを省略したり、ラベルを誤ったり、誤って分類したりするなどの人為的なエラーをより起こしやすくなるという事実によって悪化する。例えば、異なる約束された配達日を有する複数の荷物を含む注文は、システムの途中で１つ以上の紛失または損傷した荷物で終わることがあり、システムは、フラストレーションのある顧客がフォローアップするまで気付かないことがある。

[0005] 別の例では、注文のパッケージのうちの１つは、システム内のある時点で遅延することがあり、顧客はパッケージの再配達を要求することがあり、この場合、システムは既存のパッケージがなぜ遅延しているか、または遅延を解消するために必要となる時間をシステムが知らせることができないため、新しいパッケージを再注文する必要がある。この場合、既存の遅延パッケージと新しいパッケージの両方が顧客に配達され、システムに不必要な費用の負担をかける可能性がある。既存の遅延パッケージが倉庫まで正しく経路指定される場合であっても、現在のシステムは、顧客によって返却されたパッケージからそれを区別することができず、遅延パッケージが顧客に到達しておらず、したがって開封されていないので、最小限の検査のみで保管され、補充されることが可能であった場合、遅延パッケージは、他の顧客返却パッケージと共に完全な検査プロセスを経ることを必要とする場合がある。これらのシナリオは、現在のシステムの欠点を例示するのに役立ち、多くの他の問題も当業者には明らかであろう。

[0006] したがって、注文処理システムを介して注文およびパッケージを追跡し、まだ配達されていない残りの注文の数を減らすために必要なアクションを積極的に識別し、実行する一方で、動作費用への影響を最小限に抑えるための改善された方法およびシステムが必要とされている。

[0007] 本開示の一態様は、自動パッケージ追跡のための方法を対象とする。本方法は、コンピュータシステムにネットワークインタフェースを介して接続された少なくとも１つのプロセッサと、プロセッサにネットワークインタフェースを介して接続されたデータベースとによって実行される。この方法は、ネットワークインタフェースを介して、注文と、第１のパッケージに関連付けられた第１のパッケージ識別子と、第１のパッケージ識別子を含む複数のパッケージ識別子に関連付けられたイベントデータと、を含む集約された情報を、ネットワークインタフェースを介して受信するステップであって、前記注文が、第１のグループのアイテムを含み、第１のパッケージが、第１のグループのアイテムに関連付けられ、１つまたは複数の既存のルートを介して第１の予め定められた期間内に第１の受取人に配達される、ステップと、第１のパッケージ識別子に基づいてイベントデータを解析するステップと、解析されたイベントデータに基づいて第１のパッケージが存在するかどうかを判定するステップであって、第１のパッケージが存在しないと判定される場合には、第１のパッケージ識別子に第１の条件を満たすものとしてフラグを立て、第１のパッケージが存在すると判定される場合には、リソースの不足のために第１のパッケージが配達されなかったかどうかを判定し、第１のパッケージがリソースの不足のために配達されなかったと判定される場合には、第１の予め定められた期間が第１の閾値を超えて経過した場合に、第１のパッケージ識別子に第２の条件を満たすものとしてフラグを立てる、ステップと、前記判定に基づいて、第１のパッケージを配達するために、または第１のパッケージを再注文するために、コンピュータシステムに信号を送信するステップと、を含む。

[0008] 本開示の別の態様は、自動パッケージ追跡のためのコンピュータ実装システムを対象とする。システムは、命令を記憶するメモリと、少なくとも１つのプロセッサと、プロセッサにネットワークインタフェースを介して接続されたデータベースと、プロセッサに接続されたネットワークインタフェースを介してコンピュータシステムとを含む。プロセッサは、注文と、第１のパッケージに関連付けられた第１のパッケージ識別子と、前記第１のパッケージ識別子を含む複数のパッケージ識別子に関連付けられたイベントデータと、を含む集約された情報を、ネットワークインタフェースを介して受信するステップであって、前記注文が、第１のグループのアイテムを含み、第１のパッケージが、第１のグループのアイテムに関連付けられ、１つまたは複数の既存のルートを介して第１の予め定められた期間内に第１の受取人に配達される、ステップと、第１のパッケージのステータスを判定するために第１のパッケージ識別子に基づいてイベントデータを解析するステップと、解析されたイベントデータに基づいて第１のパッケージが存在するかどうかを判定するステップであって、第１のパッケージが存在しないと判定される場合には、第１のパッケージ識別子に第１の条件を満たすものとしてフラグを立て、第１のパッケージが存在すると判定される場合には、リソースの不足のために第１のパッケージが配達されなかったかどうかを判定し、第１のパッケージがリソースの不足のために配達されなかったと判定される場合には、第１の予め定められた期間が第１の閾値を超えて経過した場合に、第１のパッケージ識別子に第２の条件を満たすものとしてフラグを立てる、ステップと、前記判定に基づいて、第１のパッケージを配達するために、または第１のパッケージを再注文するために、コンピュータシステムに信号を送信するステップと、を行うための命令を実行するように構成されている。

[0009] 本開示のさらに別の態様は、複数のパッケージの自動パッケージ追跡のためのコンピュータ実装システムを対象とする。このシステムは、第１のコンピュータシステムと、モバイルデバイスと、データベースと、第２のコンピュータシステムとを含む。モバイルデバイスは、命令を記憶するメモリと、複数のパッケージに対応するパッケージ識別子をスキャンすることによってイベントデータを生成し、生成されたイベントデータが、位置、時間、デバイス識別子、またはユーザ識別子のうちの少なくとも１つを含み、生成されたイベントデータをデータベースにネットワークを介して送信する、ための命令を実行するように構成された少なくとも１つのプロセッサと、を含む。第１のコンピュータシステムは、命令を記憶するメモリと、複数の注文と、複数のパッケージ識別子と、生成されたイベントデータと、を含む集約された情報を、ネットワークを介して前記データベースから受信するステップであって、各注文が、少なくとも１つのグループのアイテムを含み、各パッケージが、１つのグループのアイテムに関連付けられ、１つまたは複数の既存のルートを介してそれぞれの予め定められた期間内にそれぞれの受取人に配達される、ステップと、複数のパッケージ識別子に基づいてイベントデータを解析するステップと、解析されたイベントデータに基づいて各パッケージが存在するかどうかを判定するステップであって、特定のパッケージが存在しないと判定される場合には、当該特定のパッケージに第１の条件を満たすものとしてフラグを立て、特定のパッケージが存在すると判定される場合には、リソースの不足のために前記特定のパッケージが配達されなかったかどうかを判定し、リソースの不足のために前記特定のパッケージが配達されなかったと判定される場合には、対応する予め定められた期間が閾値を超えて経過した場合に、対応するパッケージ識別子に第２の条件を満たすものとしてフラグを立てる、ステップと、前記判定に基づいて、各パッケージの配達を引き起こすために、またはフラグが立てられたパッケージを再注文するために、ネットワークを介して第２のコンピュータシステムに信号を送信するステップと、を行うための命令を実行するように構成された少なくとも１つのプロセッサと、を含む。

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

[0011] 図１Ａは、開示された実施形態と整合する、出荷、輸送、および物流オペレーションを可能にする通信のためのコンピュータ化されたシステムを備えるネットワークの例示的な実施形態を示す概略ブロック図である。 [0012] 図１Ｂは、開示された実施形態と整合する、インタラクティブなユーザインタフェース要素とともに検索要求を満たす１つまたは複数の検索結果を含む例示的な検索結果ページ（ＳＲＰ）を示す。 [0013] 図１Ｃは、開示された実施形態と整合する、対話型ユーザインタフェース要素とともに製品および製品に関する情報を含む例示的な単一ディスプレイページ（ＳＤＰ）を示す。 [0014] 図１Ｄは、開示された実施形態と整合する、対話型ユーザインタフェース要素とともに仮想ショッピングカート内のアイテムを含む例示的なカートページを示す。 [0015] 図１Ｅは開示された実施形態に整合する、対話型ユーザインタフェース要素とともに、購入および出荷に関する情報とともに仮想ショッピングカートからのアイテムを含む例示的な注文ページを示す。 [0016] 図２は、開示された実施形態と整合する、開示されたコンピュータ化されたシステムを利用するように構成された例示的なフルフィルメントセンタの概略図である。 [0017] 図３は、開示された実施形態と整合する、適切なパッケージ追跡プロセスを決定するためにフォローされる例示的なコンピュータ化された開始プロセスのフローチャートである。 [0018] 図４は、開示された実施形態と整合する、パッケージがキャンプゾーンに到着したと判定されたときにフォローされる例示的なコンピュータ化されたパッケージ追跡プロセスのフローチャートである。 [0019] 図５は、開示された実施形態と整合する、パッケージが配達のために出発したと判定されたときにフォローされる例示的なコンピュータ化されたパッケージ追跡プロセスのフローチャートである。 [0020] 図６は、開示された実施形態と整合する、パッケージが配達に失敗したと判定された場合にフォローされる例示的なコンピュータ化されたパッケージ追跡プロセスのフローチャートである。 [0021] 図７は、開示された実施形態と整合する、パッケージが正常に配達されたと判定された場合にフォローされる例示的なコンピュータ化されたパッケージ追跡プロセスのフローチャートである。

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

[0023] 本開示の実施形態は、自動パッケージ追跡および処理のために構成されたシステムおよび方法を対象とする。

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

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

[0026] 外部フロントエンドシステム１０３は、いくつかの実施形態では、外部ユーザがシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、システム１００がシステムのプレゼンテーションを可能にして、ユーザがアイテムの注文を行うことを可能にする実施形態では、外部フロントエンドシステム１０３は、検索要求を受信し、アイテムページを提示し、支払い情報を要請するウェブサーバとして実装されてもよい。例えば、外部フロントエンドシステム１０３は、Ａｐａｃｈｅ ＨＴＴＰサーバ、Ｍｉｃｒｏｓｏｆｔインターネット・インフォメーション・サービス、ＮＧＩＮＸなどのソフトウェアを実行するコンピュータまたはコンピュータとして実現することができる。他の実施形態では、外部フロントエンドシステム１０３は、外部デバイス（例えば、モバイルデバイス１０２Ａまたはコンピュータ１０２Ｂ）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得された情報に基づいて受信された要求への応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。

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

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

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

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

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

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

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

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

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

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

[0037] 内部フロントエンドシステム１０５は、いくつかの実施形態では、内部ユーザ（例えば、システム１００を所有し、操作し、またはリースする組織の従業員）がシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装され得る。例えば、ネットワーク１０１がシステムのプレゼンテーションを可能にして、ユーザがアイテムの注文を行うことを可能にする実施形態では、内部フロントエンドシステム１０５は、内部ユーザが注文に関する診断および統計情報を見ること、アイテム情報を修正すること、または注文に関する統計をレビューすることを可能にするウェブサーバとして実装されてもよい。例えば、内部フロントエンドシステム１０５は、Ａｐａｃｈｅ ＨＴＴＰサーバ、Ｍｉｃｒｏｓｏｆｔインターネット・インフォメーション・サービス、ＮＧＩＮＸなどのソフトウェアを実行するコンピュータまたはコンピュータとして実現することができる。他の実施形態では、内部フロントエンドシステム１０５は、システム１００に示されているシステムまたは装置（および図示されていない他の装置）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得された情報に基づいて受信された要求に応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行してもよい。

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

[0039] 輸送システム１０７は、いくつかの実施形態では、システム１００内のシステムまたはデバイスとモバイルデバイス１０７Ａ〜１０７Ｃとの間の通信を可能にするコンピュータシステムとして実装され得る。輸送システム１０７は、いくつかの実施形態では、１つまたは複数のモバイルデバイス１０７Ａ〜１０７Ｃ（例えば、携帯電話、スマートフォン、ＰＤＡなど）から情報を受信することができる。例えば、いくつかの実施形態では、モバイルデバイス１０７Ａ〜１０７Ｃは、配達員によって操作されるデバイスを備えてもよい。配達作業員は、正社員、一時社員、またはシフト社員であってもよく、モバイルデバイス１０７Ａ〜１０７Ｃを利用して、ユーザによって注文された製品を含むパッケージの配達を行うことができる。例えば、荷物を配達するために、配達作業者は、どの荷物を配達すべきか、およびどこに配達すべきかを示す通知をモバイルデバイス上で受信することができる。配達作業者は、配達場所に到着すると、パッケージを（例えば、トラックの後ろに、またはパッケージのクレートに）配置し、モバイルデバイスを使用してパッケージ上の識別子（例えば、バーコード、画像、テキストストリング、ＲＦＩＤタグなど）に関連するデータをスキャンまたは他の方法で取り込み、パッケージを（例えば、前面ドアに置いたままにし、セキュリティガードを付けたままにし、受取人に渡すなどによって）配達することができる。いくつかの実施形態では、配達作業者は、パッケージの写真（複数可）をキャプチャすることができ、および／またはモバイルデバイスを使用して署名を取得することができる。モバイルデバイスは、例えば、時間、日付、ＧＰＳ位置、写真、配達作業者に関連付けられた識別子、モバイルデバイスに関連付けられた識別子などを含む、配達に関する情報を含む情報を輸送システム１０７に送信することができる。輸送システム１０７は、システム１００内の他のシステムによるアクセスのために、この情報をデータベース（図示せず）に記憶することができる。輸送システム１０７は、いくつかの実施形態では、この情報を使用して、特定の荷物の位置を示す追跡データを準備し、他のシステムに送信することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0067] キャンプゾーン２１５内の作業者および／または機械は、例えば、既存のルートおよび／またはサブルートに対する目的地の比較、各ルートおよび／またはサブルートに対する作業負荷の計算、時刻、出荷方法、パッケージ２２０を出荷するためのコスト、パッケージ２２０内の品目に関連付けられたＰＤＤなどに基づいて、パッケージ２２０がどのルートおよび／またはサブルートに関連付けられるべきかを決定することができる。いくつかの実施形態では、作業者または機械が（例えば、デバイス１１９Ａ〜１１９Ｃのうちの１つを使用して）パッケージをスキャンして、その最終的な宛先を決定することができる。パッケージ２２０が特定のルートおよび／またはサブルートに割り当てられると、作業者および／または機械は、出荷されるパッケージ２２０を移動させることができる。例示的な図２において、キャンプゾーン２１５は、トラック２２２、自動車２２６、および配達作業員２２４Ａおよび２２４Ｂを含む。いくつかの実施形態では、トラック２２２が配達作業員２２４Ａによって駆動されてもよく、配達作業員２２４ＡはＦＣ２００のパッケージを配達する常勤の従業員であり、トラック２２２はＦＣ２００を所有、リース、または運営する同じ会社によって所有、リース、または運営される。いくつかの実施形態では、自動車２２６が配達作業者２２４Ｂによって駆動されてもよく、配達作業者２２４Ｂは必要に応じて（例えば、季節的に）配達している「フレックス」または時折の作業者である。自動車２２６は、配達員２２４Ｂによって所有され、リースされ、または操作されてもよい。

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

[0069] 情報の電子的な要求と集約は１日に１回（例えば、１日の終わりに）、一定の間隔で１日に複数回、または必要に応じて、あるいは異なるシステムが追加情報（例えば、配送状況の更新）を生成するときにリアルタイムで行われてもよい。また、異なるシステムは、それぞれ異なる時間、間隔、または頻度で、ＳＡＴシステム１０１と情報を電子的に送受信することもできる。ＳＡＴシステム１０１と各異なるシステムとの間の情報の通信および転送について以下に説明する。

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

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

[0072] イベントデータは例えば、スキャン／読取時間、日付、パッケージ識別子、配達状況、および意図された受取人を含むことができる。配達の試みが不成功であった場合、イベントデータは、キャンプゾーン２１５での容量超過の判定、配達中のリソース不足の判定、誤って分類されたパッケージの判定、受取人の利用不能、または損傷したパッケージなど、試みが失敗した理由も含むことができる。未配達についての他の理由は当業者に明らかであり、そして本発明の範囲内である。モバイルデバイス（例えば、図１のデバイス１０７Ａ〜１０７Ｃ）を使用する配達作業者２２４Ａまたは２２４Ｂは、ユーザインタフェース上に表示されたドロップダウンリストから１つまたは複数の理由を選択することによって、未配達の理由をイベントデータに追加することができる。次に、ＳＡＴシステム１０１は、以下に説明するように、１つ以上の対応する理由コードをイベントデータおよび／または対応するパッケージ情報に追加することができる。さらに、配達作業者２２４Ａまたは２２４Ｂが配達作業中に顧客から返品されたパッケージを拾った場合、イベントデータは、返品されたパッケージに関する情報も含むことができる。

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

[0074] ＷＭＳ１１９及び３ＰＬシステム１２１Ａ〜１２１Ｃからのパッケージ情報の要求及び収集のために、ＳＡＴシステム１０１は、ＦＯシステム１１３に電子要求を送信することができ、それによってＦＭＧ１１５に電子要求を転送することができる。次いで、ＦＭＧ１１５は、上述のように、電子要求を各システムに適した別のフォーマットまたはプロトコルに変換した後に、ＷＭＳ１１９および３ＰＬシステム１２１Ａ〜１２１Ｃのそれぞれに電子要求を送信することができる。

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

[0076] ＷＭＳ１１９または３ＰＬシステム１２１Ａ〜１２１Ｃの各パッケージに関連するイベントデータを集計するか、または各パッケージのイベントデータが生成されると、イベントデータは、ＦＭＧ１１５に送信され、必要に応じて標準フォーマットに変換される。次に、ＦＭＧ１１５は、変換されたイベントデータをＦＯシステム１１３に転送し、その後、イベントデータをＳＡＴシステム１０１に転送する。

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

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

[0079] 代替的に、または追加的に、最後のイベントデータが例えば、パッケージが失われたことを示す場合、ＳＡＴシステム１０１は、以前のイベントデータ、またはユーザ識別子（例えば、ユーザ識別子および従ってユーザの割り当てられた作業領域に基づいて判定する）のような他の付随データに基づいて、最後の既知の位置を判定し、それに応じて状態を更新することができる。例えば、以前のイベントデータはパッケージが配達のために出発したことを示すことができ、この場合、ＳＡＴシステム１０１は、ステータスを配達のために出発したもの（５０１）として設定する。矛盾する指示をもつパッケージ識別子について複数の事象データが存在するいくつかの実施形態では、ＳＡＴシステム１０１は、矛盾するイベントデータの最新の１つに基づいてステータスを判定し、他を無視することを選択してもよい。いくつかの実施形態では、ＳＡＴシステム１０１は、パッケージの現在のステータスが不正確であると判定し、ステータスを変更することもできる。

[0080] 図３に戻ると、ＳＡＴシステム１０１は、ステップ３０３において、最後のイベントが、パッケージがキャンプゾーン２１５に到着したことを示すかどうかを判定することができる。肯定の場合、ＳＡＴシステム１０１は、ステップ３０５で、パッケージに関連付けられたパッケージ情報を更新し、そのステータスが、パッケージがキャンプゾーン２１５に到着したことを示すようにすることができる。次に、プロセスは、図４のパッケージ追跡プロセス４００に進むことができる。

[0081] ステップ３０３からの判定が否定的である場合、ＳＡＴシステム１０１は、ステップ３０７において、最後のイベントが、パッケージが配達のために出発したことを示すかどうかを判定することができる。この判定の結果が肯定的である場合、ＳＡＴシステム１０１はステップ３０９において、パッケージに関連するパッケージ情報を更新し、そのステータスが、パッケージがトラック２２２またはかご２２６に積み込まれ、配達のために出発したことを示すようにすることができる。次に、プロセスは、図５のパッケージ追跡プロセス５００に進むことができる。

[0082] ステップ３０７での判定が否定的である場合、ＳＡＴシステム１０１は、ステップ３１１で、最後のイベントが、配信試行が行われたが失敗したことを示すかどうかを判定することができる。この判定の結果が肯定的である場合、ＳＡＴシステム１０１は、ステップ３１３において、配達の試みが不成功であったことをそのステータスが示すように、パッケージに関連付けられたパッケージ情報を更新することができる。次に、プロセスは、図６のパッケージ追跡プロセス６００に進むことができる。

[0083] ステップ３１１での判定が否定的である場合、ＳＡＴシステム１０１は、ステップ３１５で、パッケージが正常に配達されたと判定し、そのステータスが、配達が正常に行われたことを示すように、パッケージに関連付けられたパッケージ情報を更新することができる。次いで、プロセスは、図７のパッケージ追跡プロセス７００を継続してもよい。

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

[0085] 図４〜図７を参照すると、例示的なパッケージ追跡プロセス４００、５００、６００、および７００が、開示された実施形態と整合して、以下で説明される。ＳＡＴシステム１０１は、所定の間隔（例えば、２４時間）で、データベース内のすべてのパッケージを繰り返し、図３を参照して上述した決定に基づいて、パッケージ追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数を実行することができる。ＳＡＴシステム１０１は、データベース内の各パッケージを順番に反復処理し、各パッケージに割り当てられた対応するステータスに基づいて適切なプロセスを選択しステップ実行し、それらのステータスに従ってパッケージをソートし、各プロセスをバッチで実行するか、またはその他の方法で実行することができる。

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

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

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

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

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

[0091] 図４は、パッケージがキャンプゾーン２１５に到着したと判定されたときにＳＡＴシステム１０１がフォローすることができるコンピュータ化パッケージ追跡プロセス４００を示す。パッケージは配達のために積み込まれた後に、ハブゾーン２１３またはトラック２２２または自動車２２６から到着していてもよい。

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

[0093] ステップ４０３からの否定的な判定は、ステップ４０５で表されるように、パッケージが失われた（すなわち、不明）ことを示すことができ、ＳＡＴシステム１０１は、ステップ４０７で、再注文の条件を満たすものとしてパッケージ識別子にフラグを立てるために、対応するパッケージ情報を更新することができる。例えば、フラグ付けは、対応するパッケージ情報を記憶するデータベース内のパラメータ（例えば、優先順位ステータス）を修正することを含んでもよい。

[0094] 一方、ステップ４０３からの肯定的な判定は、物理パッケージが存在することを示すことができる。この場合、パッケージは内部遅延（例えば、キャンプゾーン２１５での容量を超えた）のためにキャンプゾーン２１５を出たことがないか、またはパッケージは直前の出荷サイクルの間に配達のために出たことがあるが、１つ以上の理由（例えば、配達トラックは作業時間内に配達を完了できなかった）のために配達されずにキャンプゾーン２１５に戻った。この状況では、ＳＡＴシステム１０１は、ブロック４０９で、ＳＯＴシステム１１１からの配達状況情報に基づいて、パッケージが配達されなかった理由を判定することができる。

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

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

[0097] ブロック４０９に戻って参照すると、ステップ４１９で表されるように、代わりに未配達が顧客の障害によるものであった場合、ＳＡＴシステム１０１は、ＰＤＤから第２の所定の長さ（例えば、４日）を超えて経過したかどうかを判定し（ステップ４２１）、上述のステップ４０７と同様に、ステップ４２３で、再注文の条件を満たすものとして対応するパッケージ識別子にフラグを立てることができる。そうでない場合、ステップ４２５に示すように、ＳＡＴシステム１０１は、対応するパッケージ情報を変更しないままにしてもよい。他の実施形態では、第２所定の期間が半日、５日等、４日未満またはそれ以上とすることができる。さらに他の実施形態では、時間の長さは顧客によって引き起こされる特定の遅延に基づいて変化し得る。

[0098] ブロック４０９に戻って参照すると、４２７で表されるように、代わりに、未配達が紛失または損傷したパッケージによるものであった場合、ＳＡＴシステム１０１は、パッケージがステップ４０３で存在する（すなわち、物理的に存在し、損傷していない）と以前に判定されたが、未配達の理由はパッケージが紛失または損傷していることを示すため、パッケージ情報にエラーがあると判定することができる。この場合、ＳＡＴシステム１０１はステップ４２９で表されるように、パッケージ情報内の配達されていない理由を「容量超過」にオーバーライドすることができ、したがって、配達されていない未知の理由はたとえば顧客の障害とは対照的に、内部遅延に起因する。

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

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

[0101] ステップ５０３で、ＳＡＴシステム１００は、ステップ４０３に関して上述したように、パッケージがシステム内に依然として存在するかどうかを検証することができる。ステップ５０３からの否定的な判定はステップ５０５で表され、ステップ４０５に関して上述したように、パッケージが失われたことを示すことができる。次に、ＳＡＴシステム１０１は、ステップ５０７において、上述のステップ４０７と同様の方法で、対応するパッケージ識別子に、再注文の条件を満たすものとしてフラグを立てることができる。

[0102] 一方、ステップ５０３でパッケージが存在することが検証された場合、ＳＡＴシステム１０１は、ブロック５０９で、ＳＯＴシステム１１１からの配達状況情報に基づいて、パッケージが配達されなかった理由を判定することができる。未配達が配達時間のようなリソースの不足によるものであると判定された場合、ＳＡＴシステム１０１は、ＰＤＤから第１の所定の長さより長い時間が経過したかどうかを判定し（ステップ５１３）、もしそうであれば、対応するパッケージ情報に再注文の条件を満たすものとしてフラグを立てるか（ステップ５１５）、またはステップ４１３〜４１７に関して上述したように、対応するパッケージ情報を変更しないままにしておく（ステップ５１７）ことができる。

[0103] 代わりに、ステップ５１９で表されるように、未配達が顧客の障害によるものであったと判定された場合、ＳＡＴシステム１０１は、ＰＤＤから第２の所定の長さより長い時間が経過したかどうかを判定し（ステップ５２１）、その場合には、対応するパッケージ情報に再注文の条件を満たすものとしてフラグを立てるか（ステップ５２３）、またはステップ５２１〜５２５に関して上述したようにパッケージ情報を変更しないままにしておく（ステップ５２５）ことができる。

[0104] それでもなお、ブロック５０９で、５２７で表されるように、未配達が代わりに紛失または損傷したパッケージによるものであったと判定された場合、ＳＡＴシステム１０１はステップ４２７に関して上述したように、エラーがあると判定することができる。この場合、ＳＡＴシステム１０１は、配達されていない理由を「ミスソート」にオーバーライドすることができ（ステップ５２９）、以前の判定が、パッケージが配達のために出発したことを示す（ステップ５０１）が何らかの理由でまだキャンプゾーン２１５にあることを示す（ステップ５０３）ので、パッケージがミスソートされた（例えば、間違った配達トラック２２２または自動車２２６にロードされた）ことを示し、パッケージは、それが予定された場所になかったことを示唆する。ＳＡＴシステム１０１は、次の出荷サイクル中にこれらのパッケージを配達しようと試みることができる。

[0105] ステップ５２７での判定が否定的であり、未配達の理由が何か他のものであったことを示す場合、ＳＡＴシステム１０１はステップ４３１に関して上述したように、対応するパッケージ情報を変更しないままに保つことができる（ステップ５３１）。

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

[0107] ステップ６０３で、ＳＡＴシステム１０１は、ステップ５０３に関して上述したように、パッケージがシステム内に依然として存在するかどうかを検証することができる。ステップ６０３からの否定判定はステップ６０５に示すように、パッケージが紛失したことを示すことができる。次に、ＳＡＴシステム１０１は、ステップ６０７において、上述のステップ４０７と同様の方法で、対応するパッケージ識別子に、再注文の条件を満たすものとしてフラグを立てることができる。

[0108] ステップ６０３でパッケージが存在することが検証された場合、ＳＡＴシステム１０１は、ブロック６０９で、ＳＯＴシステム１１１からの配達状況情報に基づいて、パッケージが配達されなかった理由を判定することができる。ステップ６１９で表されるように、未配達が顧客の障害によるものであると判定された場合、ＳＡＴシステム１０１は、ＰＤＤから第２の所定の長さを超える時間が経過したかどうかを判定し（ステップ６２１）、その場合には、対応するパッケージ情報に再注文の条件を満たすものとしてフラグを立てるか（ステップ６２３）、またはステップ６２１〜６２５に関して上述したようにパッケージ情報を変更しないままにする（ステップ６２５）ことができる。

[0109] 代替的に、ブロック６０９において、６２７で表されるように、未配達が代わりに紛失または損傷したパッケージによるものであったと判定された場合、ＳＡＴシステム１０１はエラーがあると判定し、ステップ５２７〜５２９に関して上述したように、未配達の理由を「ミスソート」にオーバーライドすることができる（ステップ６２９）。ステップ６２７での判定が否定的であり、未配達の理由が何か他のものであったことを示す場合、ＳＡＴシステムはステップ４３１に関して上述したように、対応するパッケージ情報を変更しないままに保つことができる（ステップ６３１）。

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

[0111] 図７は、ＳＡＴシステム１０１が例えば直前の出荷サイクル中にパッケージが成功裏に納入されたと判定した場合にフォローするパッケージ追跡プロセス７００を示している。

[0112] ステップ７０３で、ＳＡＴシステム１０１は、ステップ５０３に関して上述したように、パッケージがシステム内に依然として存在するかどうかを検証することができる。否定的な判定はパッケージがシステム１００内に存在しないことを正しく示し、配達されたパッケージがシステム１００内に存在しない可能性があることが真であるため、ステップ７０５において、対応するパッケージ情報は変更されないままである。しかしながら、肯定的な判定は、ＳＯＴシステム１１１からの情報、従って、配達されたパッケージもはやシステム１００内に存在することができないので、パッケージの現在のステータスが不適切である可能性があることを示す。この場合、ＳＡＴシステム１０１は、ステップ７１１で、パッケージに関連付けられた情報をオーバーライドして、リソースの不足のためにパッケージが配達されなかったことを示すことができる。次に、ＳＡＴシステム１０１は、ステップ７１３において、ＰＤＤから第１の所定の長さより長い時間が経過したかどうかを判定し、ステップ５１３〜５１７に関して上述したように、判定に基づいてステップ７１５または７１７において適切なアクションをとることができる。他の実施形態では、ＳＡＴシステム１０１がステップ７１１で、対応するパッケージ情報をオーバーライドして、異なるステータスおよび／または配信失敗の理由を割り当てることができる。

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

[0114] いくつかの実施形態では、ＳＡＴシステム１０１は、上述のように、ステップ４０７、４１５、４２３、５０７、５１５、５２３、６０７、６２３、および７１５のうちの少なくとも１つまたは複数に基づいて再注文されるパッケージを決定すると、そのようなパッケージはパッケージを再注文し、それらをシステム１００を通して迅速化させるための別の例示的なプロセスを通して処理される。さらに、いくつかの実施形態では、ＳＡＴシステム１０１は、内部ユーザ（例えば、システム１００を所有し、運営し、またはリースする組織の従業員）からの要求を受信すると、対応するパッケージ情報を更新することによって、再注文のためのパッケージを示すこともできる。いくつかの実施形態では、再注文プロセスは、その対応するパッケージ情報（すなわち、フラグ付きパッケージ）内で再注文するために示されたパッケージによって保持されたアイテムを識別することと、対応するパッケージ識別子に関連付けられた注文を識別することと、識別された注文の一部をキャンセルすることと、識別されたアイテムを用いて新しい注文を作成および処理することと、新しい注文に関連付けられたパッケージ情報を高優先順位として更新することと、新しい配信ルートおよび／またはサブルートを介して対応するパッケージを配信することと、を備えることができる。

[0115] あいまいさを生じさせずに説明を容易にするために、再注文プロセスを、例を用いて説明する。この例では、注文が、第１のパッケージ識別子と対応する第１のパッケージ情報とを有する第１のパッケージに一緒にパッケージ化される第１のグループのアイテムと、第２のパッケージ識別子と対応する第２のパッケージ情報とを有する第２のパッケージに一緒にパッケージ化される第２のグループのアイテムと、を含む。この例では、ＳＡＴシステム１０１は、第１のパッケージがその意図された受取人に正常に配達されたが、第２のパッケージが損傷を受けたと判定することができる。この場合、ステップ４１５に関して上述したように、ＳＡＴシステム１０１は、第２のパッケージ情報を更新して、上述したパッケージ追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数から決定されるように、再注文される必要があり得るデータベース内の他のパッケージ（もしあれば）と共に、再注文のための条件を満たすものとして第２のパッケージ識別子にフラグを立てることができる。

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

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

[0118] いくつかの実施形態では、高優先度パッケージが各システム内の内部ユーザの専用グループ（例えば、輸送システム１０７内の内部ユーザのグループ、またはＷＭＳ１１９内の内部ユーザのグループ）によって処理され、配達されて、パッケージがどれだけ多くの他の非高優先度パッケージが存在し得るかにかかわらず、可能な限り迅速にパッケージ化され、配達されることを保証することができる。さらに、いくつかの実施形態では、ＳＯＴシステム１１１は、高優先度パッケージの配信を最適化するように構成された新しい配信ルートおよび／またはサブルートを作成することができる。

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

[0120] いくつかの実施形態では、パッケージ追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数に基づいて紛失したと判定されたパッケージは、上述のように再注文プロセスを介して処理されるが、内部ユーザの一部は、紛失したパッケージを見つけ出し、ＦＣ２００内に位置する返却ステージングゾーン（図示せず）にそれらを転送することに専念することができる。代替的に又は追加的に、内部ユーザは、それぞれの通常の任務を遂行している間に、１つ以上の以前に紛失したパッケージを発見することができ、その時点で、内部ユーザは、パッケージを返却ステージングゾーンに転送することもできる。

[0121] システム１００は、発見されたパッケージを元の意図された受取人に再配達しようとしないことが好ましく、その理由は上記の再注文プロセスによって作成された新しい高優先度のパッケージをキャンセルし、配達するのを防止する必要があり、それによってシステム１００の速度が低下する可能性があるからである。さらに、いくつかの実施形態では、パッケージ追跡プロセス４００、５００、６００、および７００のうちの１つまたは複数に基づいて損傷していると判定されたパッケージは、その中のアイテムを取り出すことができるように、返却ステージングゾーンに転送することもできる。その中のアイテムのサブセットは、依然として販売可能な状態にあり得る。

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

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

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

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

Claims (20)

1. 自動パッケージ追跡のためのコンピュータ実装方法であって、コンピュータシステムにネットワークインタフェースを介して接続された少なくとも１つのプロセッサと、前記プロセッサにネットワークインタフェースを介して接続されたデータベースとによって行われる方法であり、
   注文と、第１のパッケージに関連付けられた第１のパッケージ識別子と、前記第１のパッケージ識別子を含む複数のパッケージ識別子に関連付けられたイベントデータと、を含む集約された情報を、ネットワークインタフェースを介して受信するステップであって、前記注文が、第１のグループのアイテムを含み、前記第１のパッケージが、前記第１のグループのアイテムに関連付けられ、１つまたは複数の既存のルートを介して第１の予め定められた期間内に第１の受取人に配達される、ステップと、
   前記第１のパッケージ識別子に基づいて前記イベントデータを解析するステップと、
   解析されたイベントデータに基づいて前記第１のパッケージが存在するかどうかを判定するステップであって、
   前記第１のパッケージが存在しないと判定される場合には、前記第１のパッケージ識別子に第１の条件を満たすものとしてフラグを立て、
   前記第１のパッケージが存在すると判定される場合には、リソースの不足のために第１のパッケージが配達されなかったかどうかを判定し、
   前記第１のパッケージがリソースの不足のために配達されなかったと判定される場合には、前記第１の予め定められた期間が第１の閾値を超えて経過した場合に、第１のパッケージ識別子に第２の条件を満たすものとしてフラグを立てる、ステップと、
   前記した一連の判定に基づいて、前記第１のパッケージを配達するか、または前記第１のパッケージを再注文するように、前記コンピュータシステムに信号を送信するステップと、
   を含む方法。
2. 前記注文は、第２のパッケージに対応する第２のグループのアイテムをさらに含み、前記複数のパッケージ識別子は、前記第２のパッケージに関連付けられた第２のパッケージ識別子をさらに含み、
   前記第２のパッケージは、前記１つまたは複数の既存のルートを介して第２の予め定められた期間内に前記第１の受取人に配達されることになり、
   前記解析するステップと、前記判定するステップと、前記送信するステップとは、前記第２のパッケージおよび前記第２のパッケージ識別子について繰り返される、
   請求項１に記載のコンピュータ実装方法。
3. 前記イベントデータを解析するステップは、
   前記イベントデータをフィルタリングして、前記第１のパッケージ識別子に関連付けられたイベントデータを分離するステップと、
   分離されたイベントデータを解析して、イベント間の時間的関係を判定するステップと、
   イベントの時系列シーケンスを判定するステップと、
   前記イベントの時系列シーケンスに基づいて前記第１のパッケージのステータスを判定するステップと、
   を含む、請求項１に記載のコンピュータ実装方法。
4. 前記第１のパッケージは、前記第１の受取人に配達されることを試みられた、請求項１に記載のコンピュータ実装方法。
5. 前記第１のパッケージを再注文するステップは、
   前記第１のグループのアイテムに対応する前記注文の一部をキャンセルするステップと、
   前記第１のグループのアイテムで新しい注文を作成するステップと、
   前記第１のグループのアイテムを保持するための新しいパッケージに関連付けられた新しいパッケージ識別子の作成するステップと、
   前記新しいパッケージ識別子に高優先度のフラグを立てるステップと、
   前記新しいパッケージ識別子を前記コンピュータシステムに送信するステップと、
   補充されるように前記第１のパッケージを転送するステップと、
   を含む、請求項１に記載のコンピュータ実装方法。
6. 前記新しいパッケージ識別子にフラグを立てるステップは、前記新しいパッケージ識別子に関連付けられたパラメータを更新するステップを含む、請求項５に記載のコンピュータ実装方法。
7. 前記新しいパッケージ識別子は、前記コンピュータシステムに、前記パラメータに基づいて前記新しいパッケージをより迅速に処理させる、請求項６に記載のコンピュータ実装方法。
8. 前記新しいパッケージ識別子は、デバイスに、当該デバイスを使用して前記新しいパッケージをスキャンする際に、前記新しいパッケージに関する特定の命令を含む通知を表示させる、請求項７に記載のコンピュータ実装方法。
9. 前記新しいパッケージ識別子は、前記コンピュータシステムに、前記新しいパッケージを配達するために最適化された新しいルートを作成させる、請求項７に記載のコンピュータ実装方法。
10. 前記第１のパッケージを再注文するステップは、前記新しいパッケージを前記第１の受取人に配達するための新しい期間を計算するステップをさらに含む、請求項６に記載のコンピュータ実装方法。
11. 更新される注文に関連する前記集約された情報に基づいて、注文に関連する前記集約された情報を、ネットワークインタフェースを介して受信するステップ、
    をさらに含む、請求項１に記載のコンピュータ実装方法。
12. 注文に関連する前記集約された情報を受信するステップは、第１の予め定めれた間隔で繰り返される、請求項１に記載のコンピュータ実装方法。
13. 前記解析するステップと、前記判定するステップと、前記送信するステップとは、前記第１の予め定められた間隔よりも長い第２の予め定められた間隔で繰り返される、請求項１に記載のコンピュータ実装方法。
14. 前記リソースの不足は、時間の不足、労働者の不足、またはスペースの不足のうちの少なくとも１つを含む、請求項１に記載のコンピュータ実装方法。
15. 前記第１の閾値は、不足していた特定のリソースに基づいて可変である、請求項１４に記載のコンピュータ実装方法。
16. 前記第１のパッケージのステータスは、ユーザによって手動で入力されたリクエストによって判定される、請求項１に記載のコンピュータ実装方法。
17. 前記第１のパッケージが他の理由のために配達されなかったと判定される場合には、前記第１の予め定められた期間が第２の閾値を超えて経過した場合に、前記第１のパッケージに第３の条件を満たすものとしてフラグを立てる、請求項１に記載のコンピュータ実装方法。
18. 前記第１のパッケージのステータスは、倉庫に到着したこと、配達のために出発したこと、配達の試みが失敗したこと、または配達が成功したことを含む、請求項１に記載のコンピュータ実装方法。
19. 自動パッケージ追跡のためのコンピュータ実装システムであって、
    命令を記憶するメモリと、
    少なくとも１つのプロセッサと、
    前記プロセッサにネットワークインタフェースを介して接続されたデータベースと、
    前記プロセッサにネットワークインタフェースを介して接続されたコンピュータシステムと、
    を備え、
    前記プロセッサは、
    注文と、第１のパッケージに関連付けられた第１のパッケージ識別子と、前記第１のパッケージ識別子を含む複数のパッケージ識別子に関連付けられたイベントデータと、を含む集約された情報を、ネットワークインタフェースを介して受信するステップであって、前記注文が、第１のグループのアイテムを含み、前記第１のパッケージが、前記第１のグループのアイテムに関連付けられ、１つまたは複数の既存のルートを介して第１の予め定められた期間内に第１の受取人に配達される、ステップと、
    前記第１のパッケージ識別子に基づいて前記イベントデータを解析するステップと、
    解析されたイベントデータに基づいて前記第１のパッケージが存在するかどうかを判定するステップであって、
    前記第１のパッケージが存在しないと判定される場合には、前記第１のパッケージ識別子に第１の条件を満たすものとしてフラグを立て、
    前記第１のパッケージが存在すると判定される場合には、リソースの不足のために第１のパッケージが配達されなかったかどうかを判定し、
    前記第１のパッケージがリソースの不足のために配達されなかったと判定される場合には、前記第１の予め定められた期間が第１の閾値を超えて経過した場合に、第１のパッケージ識別子に第２の条件を満たすものとしてフラグを立てる、ステップと、
    前記した一連の判定に基づいて、前記第１のパッケージを配達するか、または前記第１のパッケージを再注文するように、前記コンピュータシステムに信号を送信するステップと、
    を行うための前記命令を実行するように構成されている、コンピュータ実装システム。
20. 複数のパッケージの自動パッケージ追跡のためのコンピュータ実装システムであって、第１のコンピュータシステムと、モバイルデバイスと、データベースと、第２のコンピュータシステムとを備え、
    前記モバイルデバイスは、
    命令を記憶するメモリと、
    複数のパッケージに対応するパッケージ識別子をスキャンすることによってイベントデータを生成し、生成されたイベントデータが、位置、時間、デバイス識別子、またはユーザ識別子のうちの少なくとも１つを含み、
    生成されたイベントデータを前記データベースにネットワークを介して送信する、
    ための前記命令を実行するように構成された少なくとも１つのプロセッサと、
    を含み、
    前記第１のコンピュータシステムは、
    命令を記憶するメモリと、
    複数の注文と、複数のパッケージ識別子と、生成されたイベントデータと、を含む集約された情報を、ネットワークを介して前記データベースから受信するステップであって、各注文が、少なくとも１つのグループのアイテムを含み、各パッケージが、１つのグループのアイテムに関連付けられ、１つまたは複数の既存のルートを介してそれぞれの予め定められた期間内にそれぞれの受取人に配達される、ステップと、
    前記複数のパッケージ識別子に基づいて前記イベントデータを解析するステップと、
    解析されたイベントデータに基づいて各パッケージが存在するかどうかを判定するステップであって、
    特定のパッケージが存在しないと判定される場合には、当該特定のパッケージに第１の条件を満たすものとしてフラグを立て、
    特定のパッケージが存在すると判定される場合には、リソースの不足のために前記特定のパッケージが配達されなかったかどうかを判定し、
    リソースの不足のために前記特定のパッケージが配達されなかったと判定される場合には、対応する予め定められた期間が閾値を超えて経過した場合に、対応するパッケージ識別子に第２の条件を満たすものとしてフラグを立てる、ステップと、
    前記した一連の判定に基づいて、各パッケージの配達を引き起こすか、またはフラグが立てられたパッケージを再注文するように、ネットワークを介して前記第２のコンピュータシステムに信号を送信するステップと、
    を行うための前記命令を実行するように構成された少なくとも１つのプロセッサと、
    を含む、システム。

Images