(57)【要約】  本開示の実施形態は、命令を記憶するメモリと、命令を実行するように構成された少なくとも１つのプロセッサとを備える、在庫補充通知を提供するためのシステムおよび方法を提供する。プロセッサは、ユーザに関連付けられたユーザインタフェースから、製品に関連付けられた在庫補充通知のための第１の要求を受信し、製品に第１のステータスを割り当てるようにデータベースを修正するように構成されてもよい。プロセッサはさらに、製品が購入可能であることを示すメッセージを受信し、第２のステータスを製品に割り当てるようにデータベースを修正するように構成してもよい。プロセッサは、第２のステータスが割り当てられた製品を識別するためにデータベースを定期的に分析し、ユーザに在庫補充通知を送信するための通知スケジュールを決定するようにバッチフレームワークを構成してもよい。プロセッサは、決定された通知スケジュールに基づいて、在庫補充通知をユーザに送信するように構成されてもよい。
2021518001.tif 000002
【特許請求の範囲】
【請求項１】
在庫補充通知を提供するためのコンピュータ実装システムであって、
命令を記憶するメモリと、
ユーザに関連付けられたユーザインタフェースから、製品に関連付けられた在庫補充通知のための第１の要求を受信するステップと、
前記製品に第１のステータスを割り当てるようにデータベースを修正するステップと、
前記製品が購入可能であることを示すメッセージを受信するステップと、
前記製品に第２のステータスを割り当てるように前記データベースを修正するステップと、
前記第２のステータスが割り当てられた製品を識別するために前記データベースを定期的に分析するようにバッチフレームワークを構成するステップと、
前記ユーザに前記在庫補充通知を送信するための通知スケジュールを決定するように前記バッチフレームワークを構成するステップと、
決定された通知スケジュールに基づいて前記在庫補充通知を前記ユーザに送信するステップと、
を行うための前記命令を実行するように構成された少なくとも１つのプロセッサと、
を備えたシステム。
【請求項２】
前記ユーザインタフェースは、モバイルアプリケーションプログラミングインタフェース、ウェブブラウザ、モバイルウェブブラウザ、またはカートウェブブラウザのうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項３】
前記第１のステータスは、在庫切れの製品の在庫補充通知のための保留中の要求を示し、
前記第２のステータスは、前記製品が在庫ありであり、前記在庫補充通知がユーザに送信される準備ができていることを示す、
請求項１に記載のシステム。
【請求項４】
前記製品が購入可能であることを示す前記メッセージは、アイテムＩＤまたはベンダアイテムＩＤのうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項５】
前記在庫補充通知は、モバイルアプリケーションのためのプッシュ通知または電子メール通知のうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項６】
前記少なくとも１つのプロセッサは、さらに
前記製品に第３のステータスを割り当てるように前記データベースを修正するステップであって、前記第３のステータスが、前記ユーザに前記在庫補充通知を送信できなかったことを示す、ステップと、
決定された通知スケジュールに基づいて前記在庫補充通知をユーザに再送信するためのフェイルオーバーロジックを適用するように前記バッチフレームワークを構成するステップと、
を行うための前記命令を実行するように構成されている、請求項１に記載のシステム。
【請求項７】
前記少なくとも１つのプロセッサは、さらに
在庫補充後の前記製品の数量を決定するステップと、
前記数量が予め定められた閾値を超えた場合に、前記在庫補充通知を前記ユーザに送信するステップと、
を行うための前記命令を実行するように構成されている、請求項１に記載のシステム。
【請求項８】
前記少なくとも１つのプロセッサは、さらに、前記ユーザが前記ユーザインタフェースと対話する時間に基づいて前記通知スケジュールを決定するように前記バッチフレームワークを構成するステップを行うための前記命令を実行するように構成されている、請求項１に記載のシステム。
【請求項９】
前記通知スケジュールは、アラートタイプを含み、
前記少なくとも１つのプロセッサは、さらに、前記在庫補充通知を送信するためのスケジュールされた時間に基づいて、前記アラートタイプを調整するステップを行うための前記命令を実行するように構成されている、
請求項１に記載のシステム。
【請求項１０】
前記少なくとも１つのプロセッサは、さらに
前記ユーザに関連付けられた第２のユーザインタフェースから、第２の製品に関連付けられた在庫補充通知のための第２の要求を受信するステップと、
前記第２の製品に前記第１のステータスを割り当てるように前記データベースを変更するステップと、
前記第２の製品が購入可能であることを示す第２のメッセージを受信するステップと、
前記第２の製品に前記第２のステータスを割り当てるように前記データベースを変更するステップと、
前記第１の要求が前記第２の要求に関連するかどうかを判定するように前記バッチフレームワークを構成するステップであって、前記第１の要求が前記第２の要求に関連する場合に、前記製品および前記第２の製品が同一である、ステップと、
前記第１の要求が前記第２の要求に関連する場合に、前記第１の要求および前記第２の要求に応答して、決定された通知スケジュールに基づいて１つの在庫補充通知を前記ユーザに送信するステップと、
を行うための前記命令を実行するように構成されている、請求項１に記載のシステム。
【請求項１１】
在庫補充通知を提供するためのコンピュータ実装方法であって、
ユーザに関連付けられたユーザインタフェースから、製品に関連付けられた在庫補充通知のための第１の要求を受信するステップと、
前記製品に第１のステータスを割り当てるようにデータベースを修正するステップと、
前記製品が購入可能であることを示すメッセージを受信するステップと、
前記製品に第２のステータスを割り当てるように前記データベースを修正するステップと、
前記第２のステータスが割り当てられた製品を識別するために前記データベースを定期的に分析するようにバッチフレームワークを構成するステップと、
前記ユーザに前記在庫補充通知を送信するための通知スケジュールを決定するように前記バッチフレームワークを構成するステップと、
決定された通知スケジュールに基づいて前記在庫補充通知を前記ユーザに送信するステップと、
を含む方法。
【請求項１２】
前記ユーザインタフェースは、モバイルアプリケーションプログラミングインタフェース、ウェブブラウザ、モバイルウェブブラウザ、またはカートウェブブラウザのうちの少なくとも１つを含む、請求項１１に記載の方法。
【請求項１３】
前記在庫補充通知は、モバイルアプリケーションのためのプッシュ通知または電子メール通知のうちの少なくとも１つを含む、請求項１１に記載の方法。
【請求項１４】
前記第１のステータスは、在庫切れの製品の在庫補充通知のための保留中の要求を示し、
前記第２のステータスは、前記製品が在庫ありであり、在庫補充通知がユーザに送信される準備ができていることを示す、
請求項１１に記載の方法。
【請求項１５】
前記製品に第３のステータスを割り当てるように前記データベースを修正するステップであって、前記第３のステータスは、前記ユーザに前記在庫補充通知を送信できなかったことを示す、ステップと、
決定された通知スケジュールに基づいて前記在庫補充通知をユーザに再送信するためのフェイルオーバーロジックを適用するように前記バッチフレームワークを構成するステップと、
をさらに含む、請求項１１に記載の方法。
【請求項１６】
在庫補充後の前記製品の数量を決定するステップと、
前記数量が予め定められた閾値を超えた場合に、前記在庫補充通知を前記ユーザに送信するステップと、
をさらに含む、請求項１１に記載の方法。
【請求項１７】
前記ユーザが前記ユーザインタフェースと対話する時間に基づいて前記通知スケジュールを決定するように前記バッチフレームワークを構成するステップをさらに含む、請求項１１に記載の方法。
【請求項１８】
前記通知スケジュールは、アラートタイプを含み、前記方法は、前記在庫補充通知を送信するためのスケジュールされた時間に基づいて、前記アラートタイプを調整するステップをさらに含む、請求項１１に記載の方法。
【請求項１９】
前記ユーザに関連付けられた第２のユーザインタフェースから、第２の製品に関連付けられた在庫補充通知のための第２の要求を受信するステップと、
前記第２の製品に前記第１のステータスを割り当てるように前記データベースを変更するステップと、
前記第２の製品が購入可能であることを示す第２のメッセージを受信するステップと、
前記第２の製品に前記第２のステータスを割り当てるように前記データベースを変更するステップと、
前記第１の要求が前記第２の要求に関連するかどうかを判定するように前記バッチフレームワークを構成するステップであって、前記第１の要求が前記第２の要求に関連する場合に、前記製品および前記第２の製品が同一である、ステップと、
前記第１の要求が前記第２の要求に関連する場合に、前記第１の要求および前記第２の要求に応答して、決定された通知スケジュールに基づいて１つの在庫補充通知を前記ユーザに送信するステップと、
をさらに含む、請求項１１に記載の方法。
【請求項２０】
在庫補充通知を提供するためのコンピュータ実装システムであって、
命令を記憶するメモリと、
ユーザに関連付けられた第１のユーザインタフェースから、第１の製品に関連付けられた在庫補充通知のための第１の要求を受信するステップと、
前記ユーザに関連付けられた第２のユーザインタフェースから、第２の製品に関連付けられた在庫補充通知のための第２の要求を受信するステップと、
前記第１の製品および前記第２の製品に第１のステータスを割り当てるようにデータベースを変更するステップであって、前記第１のステータスは、在庫切れの製品の在庫補充通知のための保留中の要求を示す、ステップと、
前記第１の製品が購入可能であることを示す第１のメッセージと、前記第２の製品が購入可能であることを示す第２のメッセージとを受信するステップと、
前記第１の製品および前記第２の製品に第２のステータスを割り当てるように前記データベースを変更するステップであって、前記第２のステータスは、製品が在庫ありであり、前記在庫補充通知がユーザに送信される準備ができていることを示す、ステップと、
前記第２のステータスが割り当てられた製品を識別するために前記データベースを定期的に分析するようにバッチフレームワークを構成するステップと、
前記ユーザに前記在庫補充通知を送信するための通知スケジュールを決定するように前記バッチフレームワークを構成するステップと、
前記第１の要求が前記第２の要求に関連するかどうかを判定するように前記バッチフレームワークを構成するステップであって、前記第１の要求が前記第２の要求に関連する場合に、前記第１の製品および前記第２の製品が同一である、ステップと、
在庫補充後の前記第１の製品および前記第２の製品の数量を決定するステップと、
前記第１の要求が前記第２の要求に関連し、かつ、前記第１の製品および前記第２の製品の前記数量が予め定められた閾値を超えた場合に、決定された通知スケジュールに基づいて前記第１の製品および前記第２の製品のための１つの在庫補充通知を前記ユーザに送信するステップと、
前記第１の要求が前記第２の要求に関連しておらず、かつ、前記第１の製品および前記第２の製品の前記数量が予め定められた閾値を超えた場合に、決定された通知スケジュールに基づいて前記第１の製品のための第１の在庫補充通知と前記第２の製品のための第２の在庫補充通知とを送信するステップと、
を行うための前記命令を実行するように構成された少なくとも１つのプロセッサと、
を備えたシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
[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] さらに、例示的な実施形態が本明細書で説明されてきたが、本開示に基づいて当業者によって理解されるように、同等の要素、修正、省略、組み合わせ（例えば、様々な実施形態にわたる態様の）、適応、および／または変更を有する任意のおよびすべての実施形態の範囲。クレームの限定はクレームに使用されている文言に広く基づいて解釈されるものとし、本明細書に記載されている例に限定されるものではなく、又は出願手続中に解釈されるものとする。実施例は、非排他的であると解釈されるべきである。さらに、開示された方法のステップは、ステップを並べ替えること、および／またはステップを挿入または削除することを含む、任意の方法で修正されてもよい。したがって、本明細書および実施例は単に例示的なものとみなされ、真の範囲および精神は以下の特許請求の範囲およびそれらの均等物の全範囲によって示されることが意図される。
【図１Ａ】
2021518001.tif 000003
【図１Ｂ】
2021518001.tif 000004
【図１Ｃ】
2021518001.tif 000005
【図１Ｄ】
2021518001.tif 000006
【図１Ｅ】
2021518001.tif 000007
【図２】
2021518001.tif 000008
【図３】
2021518001.tif 000009
【図４】
2021518001.tif 000010
【図５】
2021518001.tif 000011
【図６】
2021518001.tif 000012
【図７】
2021518001.tif 000013
【国際調査報告】
2021518001.tif 000014
2021518001.tif 000015