JP7463416B2 - 在庫補充通知を提供するためのシステムおよび方法 - Google Patents

Description

[001] 本開示は、概して、電子的な在庫補充通知を提供するためのコンピュータ化された
システムおよび方法に関する。具体的には、本開示の実施形態は、通知スケジュールに基
づいて在庫補充通知を送信し、重複通知の送信を回避するためにバッチフレームワークを
使用することに関連する、発明的かつ非従来型のシステムに関する。

[002] ウェブサイト上にリストされた在庫切れのアイテムが補充され、購入可能になった
ときにユーザに電子的に通知するための様々なタイプのコンピュータ実装システムおよび
方法が存在する。例えば、多くの小売販売ウェブサイトおよびアプリケーションは、在庫
切れのアイテムが利用可能になったときに、ユーザが電子メール、テキストメッセージ、
および／またはプッシュ通知によって通知されるようにサブスクライブすることができる
通知サービスを提供する。これらの通知は有用であるが、ユーザがアクティブである期間
中に通知を送信し、重複通知を送信することを回避する、在庫補充通知を提供するための
効率的な方法がまだ存在していない。

[003] 今日、多くの小売業者は、モバイルアプリケーション、ウェブブラウザ、およびモ
バイルウェブブラウザを含むがこれらに限定されない、ユーザがアイテムを購入するため
の様々なプラットフォームを提供する。ユーザは、例えば、特定の小売業者に関連付けら
れたモバイルアプリケーション上のアイテムをブラウズし、在庫切れのアイテムが利用可
能になったときに電子メールによって通知されるようにサブスクライブすることができる
。また、ユーザは、特定の小売業者に関連付けられたウェブブラウザ上のアイテムをブラ
ウズし、在庫切れのアイテムが利用可能になったときに電子メールによって通知されるよ
うに再びサブスクライブすることができる。次いで、在庫切れのアイテムが利用可能にな
ると、ユーザは、モバイルアプリケーションおよびウェブブラウザ上で電子メール通知に
サブスクライブしたので、重複した在庫補充通知を受信する。

[004] さらに、ユーザに在庫補充通知を提供するための多くのコンピュータ実装システム
および方法が存在するが、従来のシステムおよび方法は、典型的には、在庫切れのアイテ
ムが購入可能であることが決定されるとすぐに在庫補充通知を送信する。したがって、在
庫切れのアイテムが朝の３時に利用可能になった場合、従来のシステムおよび方法は、ユ
ーザが最も睡眠している可能性が高い朝の３時にユーザに在庫補充通知を送信する。した
がって、ユーザは在庫補充通知を見逃し、アイテムを放棄する可能性が高くなり、これに
より、小売業者がアイテムに対して行うことができる収益の額が減少する可能性がある。

[005] したがって、在庫補充通知を提供するための改善されたシステムおよび方法が必要
とされている。特に、各ユーザに対してカスタマイズされた通知スケジュールに基づいて
在庫補充通知を提供するための改善されたシステムおよび方法が必要とされている。さら
に、たとえユーザが特定の製品の在庫補充通知に複数回サブスクライブしたとしても、重
複通知をユーザに送信することを回避する、在庫補充通知を提供するための改善されたシ
ステムおよび方法が必要とされている。

[006] 本開示の一態様は、在庫補充通知を提供するためのコンピュータ実装システムを対
象とする。システムは、命令を記憶するメモリと、命令を実行するように構成された少な
くとも１つのプロセッサとを備え得る。少なくとも１つのプロセッサは、ユーザに関連付
けられたユーザインタフェースから、製品に関連付けられた在庫補充通知のための第１の
要求を受信し、製品に第１のステータスを割り当てるようにデータベースを修正し、製品
が購入可能であることを示すメッセージを受信し、製品に第２のステータスを割り当てる
ようにデータベースを修正するための命令を実行するように構成され得る。また、少なく
とも１つのプロセッサは、第２のステータスが割り当てられた製品を識別するためにデー
タベースを定期的に分析し、在庫補充通知をユーザに送信するための通知スケジュールを
決定するように、バッチフレームワークを構成し得る。少なくとも１つのプロセッサは、
決定された通知スケジュールに基づいて在庫補充通知をユーザに送信するように構成され
得る。

[007] いくつかの実施形態において、ユーザインタフェースは、モバイルアプリケーショ
ンプログラミングインタフェース、ウェブブラウザ、モバイルウェブブラウザ、またはカ
ートウェブブラウザのうちの少なくとも１つを含み得る。いくつかの実施形態では、第１
のステータスは、在庫切れの製品の在庫補充通知のための保留中の要求を示すことができ
、第２のステータスは、製品が在庫ありであり、在庫補充通知がユーザに送信される準備
ができていることを示し得る。他の実施形態では、製品が購入可能であることを示すメッ
セージは、製品ＩＤ、アイテムＩＤ、ベンダアイテムＩＤ、またはベンダアイテムパッケ
ージＩＤのうちの少なくとも１つを含み得る。いくつかの実施形態では、在庫補充通知は
、モバイルアプリケーションのためのプッシュ通知または電子メール通知のうちの少なく
とも１つを含み得る。

[008] いくつかの実施形態では、少なくとも１つのプロセッサは、製品に第３のステータ
スを割り当てるようにデータベースを修正するための命令を実行するように構成され得る
。第３のステータスは、在庫補充通知をユーザに送信できなかったことを示し得る。少な
くとも１つのプロセッサはさらに、決定された通知スケジュールに基づいて、ユーザに在
庫補充通知を再送信するフェイルオーバーロジックを適用するようにバッチフレームワー
クを構成し得る。いくつかの実施形態では、少なくとも１つのプロセッサは、在庫補充後
の製品の数量を決定し、製品の数量が予め定められた閾値を超えた場合に、在庫補充通知
をユーザに送信するように構成され得る。

[009] いくつかの実施形態では、少なくとも１つのプロセッサは、ユーザがユーザインタ
フェースと対話する時間に基づいて通知スケジュールを決定するように、バッチフレーム
ワークを構成し得る。他の実施形態では、通知スケジュールは、アラートタイプを含み得
て、少なくとも１つのプロセッサは、在庫補充通知を送信するためのスケジュールされた
時間に基づいてアラートタイプを調整するように構成され得る。

[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] 図４の１つ以上のプロセッサ４１２と同様に、１つ以上のプロセッサ５１２は、
第１のユーザインタフェース５０３および第２のユーザインタフェース５０４からの在庫
補充通知の要求を受信するように構成することができる。在庫補充通知の要求を受信した
後、１つまたは複数のプロセッサ５１２は、要求に関連付けられた製品が在庫切れである
と判定し、データベース５０８を修正して、各製品にステータスを割り当てることができ
る。ステータスは、製品が在庫切れであることを示すことができる。また、１つ以上のプ
ロセッサ５１２は、各製品に対するユーザ要求在庫補充通知に関連付けられたユーザＩＤ
のリストなど、在庫補充通知を要求するユーザに関連付けられた情報をデータベース５０
８に格納してもよい。

[00100] いくつかの実施形態において、１つ以上のプロセッサ５１２は、例えば、サーバ
３０３から１つ以上の在庫補充メッセージ５０９を受信するように構成されてもよい。図
４の在庫補充メッセージ４０９と同様に、１つまたは複数の在庫補充メッセージ５０９は
特定の製品が在庫ありに戻っており、ユーザによる購入のために利用可能であることを示
すことができる。１つまたは複数の補充メッセージ５０９は、在庫が戻っている各製品に
関連付けられた製品識別子を識別することができ、また、利用可能な各製品の数量を識別
することもできる。追加的に、または代替的に、１つ以上の在庫補充メッセージ５０９は
、在庫ありに戻される各製品に関連する製品ＩＤ、アイテムＩＤ、ベンダアイテムＩＤ、
またはベンダアイテムパッケージＩＤの少なくとも１つを含むことができる。製品ＩＤは
、製品のカテゴリに関連付けられた製品識別子を含むことができる。アイテムＩＤは、製
品の１つまたは複数の属性、例えば、色、サイズ、製造業者、材料、またはブランドを示
す、製品に関連付けられた製品識別子を含むことができる。ベンダアイテムＩＤは、製品
のベンダも識別する製品に関連付けられた製品識別子を含むことができる。ベンダアイテ
ムパッケージＩＤは、購入可能なベンダによって販売された製品の集合に関連付けられた
製品識別子を含むことができる。ベンダアイテムパッケージＩＤは、製品のコレクション
のベンダを識別することもできる。次に、１つ以上のプロセッサ５１２は、データベース
５０８内の製品識別子を検索し、データベース５０８を修正して、製品識別子に関連する
製品に第２のステータスを割り当てるように構成することができる。第２のステータスは
、製品が在庫ありに戻っており、購入可能であることを示すことができる。１つ以上のプ
ロセッサ５１２はまた、データベース５０８を修正して、在庫補充後の購入に利用可能な
各製品の数量を変更するように構成されてもよい。

[00101] 図４の補充通知システム４０２と同様に、補充通知システム５０２は、バッチフ
レームワーク５１０を含むことができる。１つまたは複数のプロセッサ５１２は、バッチ
フレームワーク５１０を構成して、データベース５０８を分析し、製品が在庫ありに戻っ
ていることを示すステータスが割り当てられた製品を識別することができる。いくつかの
実施形態では、１つまたは複数のプロセッサ５１２は、利用可能な各製品の量を決定する
ためにデータベース５０８を分析するようにバッチフレームワーク５１０を構成すること
もできる。バッチフレームワーク５１０は、データベース４０８を定期的に、または所定
のスケジュールで分析するように構成してもよい。例えば、バッチフレームワーク５１０
は、データベース５０８を２時間ごと、５時間ごと、１０時間ごと、２４時間ごと、また
は週に２回分析するように構成され得る。他の実施形態では、バッチフレームワーク５１
０は、１つ以上のプロセッサ５１２によって受信されるすべての在庫補充メッセージ５０
９の後に、データベース５０８を分析するように構成してもよい。

[00102] いくつかの実施形態では、バッチフレームワーク５１０は、データベース５０８
を定期的に分析して、在庫補充通知の重複要求をチェックすることができる。例えば、ユ
ーザ５０１は、第１のユーザインタフェース５０３を介して、製品の在庫補充通知のため
の第１の要求を送信することができる。ユーザ５０１はまた、第２のユーザインタフェー
ス５０４を介して、製品の在庫補充通知のための第２の要求を送信することができる。バ
ッチフレームワーク５１０は、例えば、各要求に関連するユーザＩＤを識別することによ
って、第１の要求と第２の要求の両方がユーザ５０１からのものであることを決定しても
よい。次に、バッチフレームワーク５１０は、第１の要求が第２の要求に関連するかどう
かを判定することができる。例えば、バッチフレームワーク５１０は、在庫補充通知のた
めの第１の要求に関連付けられた製品が在庫補充通知のための第２の要求に関連付けられ
た製品と同じであるかどうかを判定することができる。第１および第２の要求に関連付け
られた２つの製品が同じである場合、バッチフレームワーク５１０は、第１の要求および
第２の要求が関連していると判定することができる。バッチフレームワーク５１０が、在
庫補充通知に対する２つの要求が関連していることを決定すると、バッチフレームワーク
５１０は、１つ以上のプロセッサ５１２が製品の１つの在庫補充通知のみをユーザ５０１
に送信し、それによって重複メッセージがユーザに送信されることを防止するような通知
スケジュールを生成することができる。

[00103] 他の実施形態では、バッチフレームワーク５１０は、第１のユーザインタフェー
ス５０３がユーザ５０１に関連付けられ、第２のユーザインタフェース５０４が異なるユ
ーザに関連付けられることを決定してもよい。１つまたは複数のプロセッサ５０２は、第
１のユーザインタフェース５０３を介して第１の製品の在庫補充通知のための第１の要求
を受信し、第２のユーザインタフェース５０４を介して第２の製品の在庫補充通知のため
の第２の要求を受信することができる。第１の製品と第２の製品が同一であっても、バッ
チフレームワーク５１０が第１のユーザインタフェース５０３が第２のユーザインタフェ
ース５０４に関連しないと判断した場合、バッチフレームワーク５１０は、第１のユーザ
インタフェース５０３に関連するユーザ５０１に第１の在庫補充通知を送信し、第２のユ
ーザインタフェース５０４に関連する異なるユーザに第２の在庫補充通知を送信してもよ
い。

[00104] 有利には、バッチフレームワーク５１０は、製品が在庫ありに戻るとすぐに、ま
たユーザがアクティブであるときに、ユーザが在庫補充通知を受信するように、ユーザに
在庫補充通知を送信するための通知スケジュールを決定するように構成されてもよい。一
例として、１つ以上のプロセッサ５１２は、第１のユーザインタフェース５０３または第
２のユーザインタフェース５０４の少なくとも１つで、ユーザの活動傾向を決定してもよ
い。決定されたユーザの活動傾向に基づいて、１つ以上のプロセッサ５１２は、時間枠を
決定してもよく、その時間枠の間、ユーザは、第１のユーザインタフェース５０３または
第２のユーザインタフェース５０４の少なくとも１つでアクティブである可能性が最も高
い。１つ以上のプロセッサ５１２は、ユーザの活動傾向情報および時間枠情報をデータベ
ース５０８に記憶することができる。データベース５０８に記憶されたユーザの情報に基
づいて、バッチフレームワーク５１０は、ユーザに在庫補充通知を送信するための通知ス
ケジュールを決定することができる。したがって、バッチフレームワーク５１０は、１つ
以上のプロセッサ５１２が時間枠内に、ユーザに在庫補充通知を送信することを可能にし
てもよく、その時間枠の間に、ユーザは在庫補充通知をチェックする可能性が最も高い。
したがって、バッチフレームワーク５１０は、第１のユーザインタフェース５０３または
第２のユーザインタフェース５０４の少なくとも１つとの各ユーザの対話に基づいて、各
ユーザに対してカスタマイズされる通知スケジュールを決定することができる。

[00105] いくつかの実施形態では、バッチフレームワーク５１０はまた、１つ以上のプロ
セッサ５１２が時間枠の外でユーザに在庫補充通知を送信しないように通知スケジュール
を決定してもよく、その時間枠の間、ユーザは在庫補充通知をチェックする可能性が最も
高い。いくつかの実施形態において、バッチフレームワーク５１０は、１つ以上のプロセ
ッサ５１２が特定の時間、例えば午前０時の後に、ユーザに在庫補充通知を送信しないよ
うに、通知スケジュールを生成することができる。他の実施形態では、通知スケジュール
を決定することは在庫補充通知のためのアラートタイプを決定することを含むことができ
る。バッチフレームワーク５１０は、１つまたは複数のプロセッサ５１２が通知スケジュ
ールに基づいて在庫補充通知のアラートタイプを調整するように構成され得るように、通
知スケジュールを決定することができる。例えば、バッチフレームワーク５１０は、１つ
以上のプロセッサ５１２が午前０時などの特定の時間の後にユーザに送信される任意の在
庫補充通知をミュートするように構成されてもよいように、通知スケジュールを生成して
もよい。

[00106] ある実施形態では、１つ以上のプロセッサ５１２は、バッチフレームワーク５１
０によって決定された通知スケジュールに基づいて、ユーザに在庫補充通知を送信するよ
うに構成されてもよい。１つ以上のプロセッサ５１２は、メッセージングプラットフォー
ム５１１を使用して、ユーザに在庫補充通知を送信するように構成することができる。メ
ッセージングプラットフォーム５１１は、ユーザにメッセージを交換することが可能な任
意のインターネットインフラストラクチャを含むことができる。例えば、メッセージング
プラットフォーム５１１は、電子メール、ショートメッセージサービス、ソーシャルネッ
トワークサービス、ソフトウェアアプリケーション、ＡＰＩ、インスタントメッセージン
グサービス、またはこれらの任意の組み合わせを含むことができる。いくつかの実施形態
において、ユーザは例えば、それらのプロファイルにログインすることによって、好みの
メッセージングプラットフォーム５１１を選択することができる。例えば、ユーザは、電
子メールを介して、またはモバイルアプリケーションを介してプッシュ通知を介して、在
庫補充通知を受信することを選択することができる。

[00107] 図４を参照して議論したように、在庫補充通知がユーザへ送信できなかった場合
、１つ以上のプロセッサ５１２は、データベース５０８を修正して、特定の製品にステー
タスを割り当てることができ、これは、在庫補充通知がユーザへ送信できなかったことを
示してもよい。バッチフレームワーク５１０は、データベース５０８を定期的に分析して
、割り当てられた在庫補充通知が送信できなかったことを示すステータスがある製品を識
別することができる。バッチフレームワーク５１０が在庫補充通知を送信できなかったこ
とを示すステータスが割り当てられた特定の製品を識別するとき、バッチフレームワーク
５１０は、決定された通知スケジュールに基づいて、在庫補充通知を再送信するフェイル
オーバーロジックを適用してもよい。

[00108] 図６は、在庫補充通知を提供するための例示的な方法６００を示すフローチャー
トである。この例示的な方法は、例として提供される。図６に示される方法６００は、様
々なシステムの１つまたは複数の組合せによって実行されるか、さもなければ実行される
ことができる。以下に説明する方法６００は、例として図３に示すように、在庫補充通知
システム３０１によって実行することができ、在庫補充通知システム３０１の様々な要素
は、図６の方法を説明する際に参照される。図６に示される各ブロックは、例示的な方法
６００における１つまたは複数のプロセス、方法、またはサブルーチンを表す。図６を参
照すると、例示的な方法６００は、ブロック６０１で開始することができる。

[00109] ブロック６０１で、１つまたは複数のプロセッサ３０５は、製品に関連する在庫
補充通知の要求を受信することができる。いくつかの実施形態において、ユーザは、モバ
イルＡＰＩ４０３、ウェブブラウザ４０４、モバイルウェブブラウザ４０５、またはカー
トウェブブラウザ４０６の少なくとも１つを介して、在庫補充通知の要求を送ることがで
きる。次いで、１つまたは複数のプロセッサ３０５は、カートＡＰＩ４０７ａ～ｃのうち
の少なくとも１つを介して、またはカートウェブブラウザ４０６を介して直接、補充通知
の要求を受信することができる。

[00110] １つまたは複数のプロセッサ３０５が事故補充通知の要求を受信すると、方法６
００は、ブロック６０２に進むことができる。ブロック６０２において、１つ以上のプロ
セッサ３０５は、データベース４０８のようなデータベースを修正して、製品に第１のス
テータスを割り当てることができる。図４を参照して上述したように、データベース４０
８は、購入のために提供されるすべての製品の在庫、ならびに製品の製品識別子（例えば
、在庫管理ユニット（ＳＫＵ））、利用可能な製品の数量、製品の利用可能性を示すステ
ータス、および／または製品に関連する補充通知の要求の数を含む、各製品に関連する情
報を格納することができる。したがって、ブロック６０２で、１つまたは複数のプロセッ
サ３０５は、例えば、製品が在庫切れであることを示すことができる第１のステータスを
製品に割り当てるために、データベース４０８を修正することができる。

[00111] ブロック６０３で、１つまたは複数のプロセッサ３０５は、図４の在庫補充メッ
セージ４０９などの在庫補充メッセージを受信することができる。在庫補充メッセージは
、在庫切れの製品が在庫ありであり、ユーザによる購入のために利用可能であることを示
すことができる。補充メッセージは、製品に関連付けられた製品識別子を識別することが
でき、在庫補充後に利用可能な製品の数量を識別することもできる。追加または代替とし
て、補充メッセージは、製品ＩＤ、アイテムＩＤ、ベンダアイテムＩＤ、または製品に関
連付けられたベンダアイテムパッケージＩＤのうちの少なくとも１つを備えることができ
る。製品ＩＤは、製品のカテゴリに関連付けられた製品識別子を含むことができる。アイ
テムＩＤは、製品の１つまたは複数の属性、例えば、色、サイズ、製造業者、材料、また
はブランドを示す、製品に関連付けられた製品識別子を含むことができる。ベンダアイテ
ムＩＤは、製品のベンダも識別する製品に関連付けられた製品識別子を含むことができる
。ベンダアイテムパッケージＩＤは、購入可能なベンダによって販売された製品の集合に
関連付けられた製品識別子を含むことができる。ベンダアイテムパッケージＩＤは、製品
のコレクションのベンダを識別することもできる。

[00112] ブロック６０３で補充メッセージを受信した後、方法６００は、ブロック６０４
に進むことができる。ブロック６０４において、１つ以上のプロセッサ３０５は、データ
ベース４０８内の製品識別子を検索し、データベース４０８を修正して、製品識別子に関
連する製品に第２のステータスを割り当てるように構成することができる。第２のステー
タスは、製品が在庫ありに戻っており、購入可能であることを示すことができる。１つ以
上のプロセッサ３０５はまた、データベース４０８を修正して、在庫補充後の購入に利用
可能な製品の数量を変更するように構成されてもよい。

[00113] 方法６００は、ブロック６０５に進んでもよいが、この場合、１つ以上のプロセ
ッサ３０５は、バッチフレームワーク４１０のようなバッチフレームワークによって決定
された通知スケジュールに基づいて、在庫補充通知をユーザに送信することができる。い
くつかの実施形態では、特定の製品についてユーザに送信される在庫補充通知は、受信者
名（例えば、ユーザの名前）、製品名（例えば、在庫が戻っている特定の製品の名前）、
特定の製品の画像、または特定の製品に関連付けられたリンクのうちの少なくとも１つを
含むことができる。特定の製品に関連付けられたリンクは、単一詳細ページ（ＳＤＰ）リ
ンクである場合があり、これを介して、ユーザは、特定の製品に関連付けられた詳細情報
を示すＳＤＰにアクセスすることができる。図４を参照して上述したように、１つ以上の
プロセッサ３０５は、バッチフレームワークを構成して、データベース５０８を分析し、
第２のステータスが割り当てられた製品を識別することができ、これは、製品が元のステ
ータスに戻っていることを示す。いくつかの実施形態では、１つまたは複数のプロセッサ
３０５は、利用可能な各製品の量を決定するためにデータベース５０８を分析するように
バッチフレームワークを構成することもできる。バッチフレームワークは、第２のステー
タスが割り当てられた製品と、在庫補充通知の保留中の要求がある製品とを識別すること
ができる。在庫補充通知のための保留中の要求を有する製品について、バッチフレームワ
ークは、在庫補充通知をユーザに送信するための通知スケジュールを決定することができ
る。

[00114] 例えば、バッチフレームワークは、在庫補充通知をユーザに送信するための通知
スケジュールを決定するように構成することができ、その結果、ユーザは、製品が在庫あ
りに戻るとすぐに、またユーザがアクティブになるときに、在庫補充通知を受信する。一
例として、１つ以上のプロセッサ３０５は、モバイルＡＰＩ４０３、ウェブブラウザ４０
４、モバイルウェブブラウザ４０５、またはカートウェブブラウザ４０６の少なくとも１
つについて、ユーザの活動傾向を決定することができる。決定されたユーザの活動傾向に
基づいて、１つ以上のプロセッサ３０５は、時間枠を決定することができ、その時間枠の
間、ユーザは、モバイルＡＰＩ４０３、ウェブブラウザ４０４、モバイルウェブブラウザ
４０５、またはカートウェブブラウザ４０６の少なくとも１つでアクティブである可能性
が最も高い。１つ以上のプロセッサ３０５は、ユーザの活動傾向情報および時間枠情報を
データベース４０８に記憶することができる。データベース４０８に記憶されたユーザの
情報に基づいて、バッチフレームワークは、ユーザに在庫補充通知を送信するための通知
スケジュールを決定することができる。したがって、バッチフレームワークは、１つ以上
のプロセッサ３０５が時間枠内にユーザに在庫補充通知を送信することを可能にしてもよ
く、その時間枠の間に、ユーザは在庫補充通知をチェックする可能性が最も高い。したが
って、バッチフレームワークは、モバイルＡＰＩ４０３、ウェブブラウザ４０４、モバイ
ルウェブブラウザ４０５、またはカートウェブブラウザ４０６の少なくとも１つに関する
各ユーザの活動傾向に基づいて、各ユーザに対してカスタマイズされる通知スケジュール
を決定することができる。

[00115] いくつかの実施形態では、バッチフレームワークはまた、１つ以上のプロセッサ
３０５が時間枠の外でユーザに在庫補充通知を送信しないように通知スケジュールを決定
してもよく、その時間枠の間、ユーザは在庫補充通知をチェックする可能性が最も高い。
他の実施形態では、バッチフレームワークは、１つまたは複数のプロセッサ３０５が通知
スケジュールに基づいて補充通知のアラートタイプを調整するように構成され得るように
、通知スケジュールを決定することができる。例えば、バッチフレームワークは、１つ以
上のプロセッサ３０５が午前０時などの特定の時間の後にユーザに送信される任意の在庫
補充通知をミュートするように構成されてもよいように、通知スケジュールを生成しても
よい。

[00116] バッチフレームワークによって決定された通知スケジュールに基づいて、１つ以
上のプロセッサ３０５は、メッセージングプラットフォーム４１１などの１つ以上のメッ
セージングプラットフォームを介して、在庫補充通知をユーザに送信することができる。
メッセージングプラットフォーム４１１は、ユーザにメッセージを交換することが可能な
任意のインターネットインフラストラクチャを含むことができる。例えば、メッセージプ
ラットフォーム４１１は、電子メール、ショートメッセージサービス、ソフトウェアアプ
リケーション、ＡＰＩ、インスタントメッセージング、またはこれらの任意の組み合わせ
を含むことができる。いくつかの実施形態では、ユーザは、例えば、自分のプロファイル
にログインすることによって、自分の好ましいメッセージングプラットフォーム４１１を
選択することができる。例えば、ユーザは、電子メールを介して、またはモバイルＡＰＩ
４０３のようなモバイルアプリケーションを介してプッシュ通知を介して、在庫補充通知
を受信することを選択することができる。

[00117] 図７は、在庫補充通知を提供するための方法７００を示すフローチャートである
。この例示的な方法は、例として提供される。図７に示される方法７００は、様々なシス
テムの１つまたは複数の組合せによって実行されるか、さもなければ実行されることがで
きる。以下に説明する方法７００は、例として図３に示すように、在庫補充通知システム
３０１によって実行することができ、在庫補充通知システム３０１の１つまたは複数の要
素は、図７の方法を説明する際に参照される。図７に示される各ブロックは、例示的な方
法７００における１つまたは複数のプロセス、方法、またはサブルーチンを表す。図７を
参照すると、例示的な方法７００は、ブロック７０１で開始することができる。

[00118] ブロック７０１において、１つまたは複数のプロセッサ３０５は、第１の製品に
関連する在庫補充通知のための第１の要求を受信することができる。ブロック７０２にお
いて、１つまたは複数のプロセッサ３０５は、第２の製品に関連する在庫補充通知のため
の第２の要求を受信することができる。いくつかの実施形態では、第１の要求および第２
の要求が同じユーザからのものであってもよい。他の実施形態では、第１の要求は第１の
ユーザからのものであってもよく、第２の要求は第２のユーザからのものであってもよい
。ユーザは、モバイルＡＰＩ４０３、ウェブブラウザ４０４、モバイルウェブブラウザ４
０５、またはカートウェブブラウザ４０６の少なくとも１つを介して、在庫補充通知の要
求を送ることができる。次いで、１つまたは複数のプロセッサ３０５は、カートＡＰＩ４
０７ａ～ｃのうちの少なくとも１つを介して、またはカートウェブブラウザ４０６を介し
て直接、第１の要求および第２の補充通知要求を受信することができる。

[00119] 在庫補充通知のための第１および第２の要求を受信した後、方法７００は、ブロ
ック７０３に進むことができる。ブロック７０３において、１つ以上のプロセッサ３０５
は、データベース４０８のようなデータベースを修正して、第１の製品および第２の製品
に第１のステータスを割り当てることができる。第１のステータスは、第１の製品および
第２の製品が在庫切れであることを示すことができる。図４を参照して上述したように、
データベース４０８は、第１および第２の製品に関連する情報を格納することができ、こ
れには第１および第２の製品に関連する製品識別子（例えば、在庫管理ユニット（ＳＫＵ
））、第１および第２の製品の利用可能な数量、第１および第２の製品の利用可能性を示
すステータス、第１および第２の製品について保留中の在庫補充通知の要求の数、および
／または第１および第２の製品についての在庫補充通知が送信されたかどうかを示すステ
ータスが含まれるが、これらに限定されない。

[00120] ブロック７０４において、１つまたは複数のプロセッサ３０５は、図４の１つま
たは複数の在庫補充メッセージ４０９などの在庫補充メッセージを受信することができる
。在庫補充メッセージ（複数可）は、第１の製品および第２の製品が在庫ありに戻ってお
り、購入に利用可能であることを示すことができる。在庫補充メッセージは、第１および
第２の製品に関連付けられた製品識別子を識別することができ、在庫補充後に利用可能な
第１および第２の製品の量を識別することもできる。追加または代替として、在庫補充メ
ッセージは、第１および第２の製品のそれぞれに関連付けられた製品ＩＤ、アイテムＩＤ
、ベンダアイテムＩＤ、またはベンダアイテムパッケージＩＤのうちの少なくとも１つを
備えることができる。製品ＩＤは、製品のカテゴリに関連付けられた製品識別子を含むこ
とができる。アイテムＩＤは、製品の１つまたは複数の属性、例えば、色、サイズ、製造
業者、材料、またはブランドを示す、製品に関連付けられた製品識別子を含むことができ
る。ベンダアイテムＩＤは、製品のベンダも識別する製品に関連付けられた製品識別子を
含むことができる。ベンダアイテムパッケージＩＤは、購入可能なベンダによって販売さ
れた製品のコレクションに関連付けられた製品識別子を含むことができる。ベンダアイテ
ムパッケージＩＤは、製品のコレクションのベンダを識別することもできる。

[00121] ブロック７０４において在庫補充メッセージを受信した後、方法７００は、ブロ
ック７０５に進むことができる。ブロック７０５において、１つ以上のプロセッサ３０５
は、データベース４０８内の製品識別子を検索し、データベース４０８を修正して、製品
識別子に関連する第１および第２の製品に第２のステータスを割り当てるように構成され
てもよい。第２のステータスは、第１および第２の製品が在庫ありに戻されており、購入
可能であることを示すことができる。１つ以上のプロセッサ３０５はまた、データベース
４０８を修正して、在庫補充後の購入に利用可能な第１および第２の製品の数量を変更す
るように構成されてもよい。

[00122] 第２のステータスを第１および第２の製品に割り当てた後、方法７００はブロッ
ク７０６に進むことができる。ブロック７０６において、１つまたは複数のプロセッサ３
０５は、第１および第２の製品の量が所定のしきい値を超えるかどうかを判定することが
できる。例えば、ブロック７０４において第１および第２の製品の在庫補充メッセージを
受信した後、１つまたは複数のプロセッサ３０５は、利用可能な第１および第２の製品の
量を決定することができる。１つまたは複数のプロセッサ３０５は、在庫補充後の第１お
よび第２の製品の量を所定の閾値と比較し、比較に基づいて、在庫補充通知をユーザに送
信するかどうかを判定することができる。例えば、在庫補充後の第１および第２の製品の
それぞれの量が所定の閾値未満である場合、１つまたは複数のプロセッサ３０５は、各製
品の量が所定の閾値を超えるまで在庫補充通知を送信しなくてもよい。同様に、在庫補充
後の第１および第２の製品のそれぞれの量が所定の閾値を超える場合、１つまたは複数の
プロセッサ３０５は、在庫補充通知をユーザに送信することに進むことができる。所定の
閾値は、各製品の消費者需要に応じて、各製品ごとに変化することができる。例えば、各
製品の所定の閾値は、各製品が素早く在庫切れになるのを防止するために、各製品の消費
者需要に正比例することができる。

[00123] １つまたは複数のプロセッサ３０５が第１の製品および／または第２の製品の量
が所定の閾値未満であると判定した場合、方法７００は、ブロック７０７において終了す
ることができ、在庫補充通知は、ユーザに送信されない。代わりに、１つまたは複数のプ
ロセッサ３０５が、第１の製品および／または第２の製品の量が所定の閾値を超えると判
定した場合、方法７００は、ブロック７０８に進むことができる。ブロック７０８におい
て、１つまたは複数のプロセッサ３０５は、第１の製品に関連する在庫補充通知のための
第１の要求（ブロック７０１）が第２の製品に関連する在庫補充通知のための第２の要求
（ブロック７０２）に関連するかどうかを判定することができる。

[00124] 上の図５を参照して議論したように、例えば、バッチフレームワークは、データ
ベース４０８内の各要求に関連するユーザＩＤを識別することによって、第１の要求と第
２の要求の両方が同じユーザからのものであることを決定してもよい。第１の要求に関連
付けられたユーザＩＤが第２の要求に関連付けられたユーザＩＤと同じ場合、バッチフレ
ームワークは、第１の要求と第２の要求が同じユーザからのものであると判断する場合が
ある。次いで、バッチフレームワークは、例えば、各要求に関連付けられた製品を比較す
ることによって、第１の要求が第２の要求に関連付けられているかどうかを判定すること
ができる。例えば、バッチフレームワークは、在庫補充通知のための第１の要求に関連付
けられた第１の製品が在庫補充通知のための第２の要求に関連付けられた第２の製品と同
じであるかどうかを判定することができる。第１の要求および第２の要求にそれぞれ関連
付けられた第１の製品および第２の製品が同じである場合、バッチフレームワークは、第
１の要求および第２の要求が関連していると判定することができる。

[00125] バッチフレームワークが在庫補充通知のための第１および第２の要求が関連して
いると判定した場合、方法７００は、ブロック７１０に進むことができる。ブロック７１
０において、１つ以上のプロセッサ３０５は、バッチフレームワークを構成して、１つ以
上のプロセッサ３０５が第１の製品と第２の製品の両方について１つの在庫補充通知のみ
をユーザに送信し、それによって重複メッセージがユーザに送信されるのを防ぐように通
知スケジュールを生成することができる。一方、バッチフレームワークは、補充通知のた
めの第１および第２の要求が関連していないと判定することができる。例えば、バッチフ
レームワークは、在庫補充通知のための第１の要求に関連付けられた第１の製品が在庫補
充通知のための第２の要求に関連付けられた第２の製品と同じではないと判定することが
できる。例えば、ユーザは、２つの異なる製品に対する在庫補充通知のための２つの異な
る要求を送信したかもしれない。バッチフレームワークが在庫補充通知のための第１およ
び第２の要求が関連していないと判定した場合、方法７００は、ブロック７０９に進むこ
とができる。ブロック７０９において、１つまたは複数のプロセッサ３０５は、第１の製
品に関する第１の在庫補充通知をユーザに送信し、第２の製品に関する別個の第２の在庫
補充通知をユーザに送信することができる。

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

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

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

Claims (10)

1. 在庫補充通知を提供するためのコンピュータ実装方法であって、
   第１の製品に関連付けられた在庫補充通知のための第１の要求を第１のユーザインタフェースから受信するステップと、
   前記第１の製品に第１のステータスを割り当てるようにデータベースを修正するステップと、
   第２の製品に関連付けられた在庫補充通知のための第２の要求を前記第１のユーザインタフェースとは別の第２のユーザインタフェースから受信するステップと、
   前記第２の製品に前記第１のステータスを割り当てるように前記データベースを変更するステップと、
   前記第１の製品および前記第２の製品が購入可能であることを示すメッセージを受信するステップと、
   前記第１の製品および前記第２の製品に第２のステータスを割り当てるように前記データベースを修正するステップと、
   前記第１の要求が前記第２の要求に関連するかどうかを判定するステップであって、前記第１の要求が前記第２の要求に関連する場合に、前記第１の要求および前記第２の要求が、ユーザに関連付けられた同一の識別子に関連付けられている、ステップと、
   通知スケジュールを決定するステップと、
   前記第１の要求が前記第２の要求に関連する場合に、前記第１の要求および前記第２の要求に応答して、決定された通知スケジュールに基づいて１つの在庫補充通知を前記ユーザに送信するステップと、
   を含む方法。
2. 前記第１のユーザインタフェースおよび前記第２のユーザインタフェースは、前記ユーザに関連付けられている、請求項１に記載の方法。
3. 前記第１のユーザインタフェースおよび前記第２のユーザインタフェースのうちの少なくとも一方は、モバイルアプリケーションプログラミングインタフェース、ウェブブラウザ、モバイルウェブブラウザ、またはカートウェブブラウザのうちの少なくとも１つを含む、請求項１に記載の方法。
4. 前記第１のステータスは、在庫切れの製品の在庫補充通知のための保留中の要求を示し、
   前記第２のステータスは、前記在庫切れの製品が在庫ありであり、前記在庫補充通知が前記ユーザに送信される準備ができていることを示す、
   請求項１に記載の方法。
5. 前記在庫補充通知は、モバイルアプリケーションのためのプッシュ通知または電子メール通知のうちの少なくとも１つを含む、請求項１に記載の方法。
6. 前記第１の製品および前記第２の製品のうちの少なくとも一方に第３のステータスを割り当てるように前記データベースを修正するステップであって、前記第３のステータスは、前記ユーザに前記在庫補充通知を送信できなかったことを示す、ステップと、
   決定された通知スケジュールに基づいて前記在庫補充通知をユーザに再送信するためのフェイルオーバーロジックを適用するようにバッチフレームワークを構成するステップと、
   をさらに含む、請求項１に記載の方法。
7. 在庫補充後の前記第１の製品および前記第２の製品のうちの少なくとも一方の数量を決定するステップと、
   前記数量が予め定められた閾値を超えた場合に、前記在庫補充通知を前記ユーザに送信するステップと、
   をさらに含む、請求項１に記載の方法。
8. 前記ユーザが前記第１のユーザインタフェースおよび前記第２のユーザインタフェースのうちの少なくとも一方と対話する時間に基づいて前記通知スケジュールを決定するようにバッチフレームワークを構成するステップをさらに含む、請求項２に記載の方法。
9. 前記通知スケジュールは、アラートタイプを含み、
   前記在庫補充通知を送信するためのスケジュールされた時間に基づいて、前記アラートタイプを調整するステップをさらに含む、請求項１に記載の方法。
10. 在庫補充通知を提供するためのコンピュータ実装システムであって、
    命令を記憶するメモリと、
    請求項１～９のいずれかに記載の方法の動作を行うための前記命令を実行するように構成された少なくとも１つのプロセッサと、
    を備えるシステム。