JP2013254504A - ローカル・ショッピング、及び、在庫管理 - Google Patents

Abstract

【課題】複数の製品、小売店、及び、場所を網羅する精確な地域製品情報を顧客に提供するシステムが、必要とされている。
【解決手段】コンピュータ上でデータを受信するステップであって、前記データは、第１の製品識別情報と、第１の前記販売業者の場所識別情報と、前記製品を販売した第１の時間(t1)に対応するタイムスタンプとを含む、ステップと、前記販売業者の場所での前記製品に関する販売事象速度(r_e) を決定するステップと、第２の時間(t2)において、前記製品の問い合わせを受信するステップであって、前記第２の時間は、前記第１の時間よりも後である、ステップと、前記第２の時間と前記第1の時間の差分(t2-t1)に対応する持続時間(t3)中に販売事象を観測しない確率を決定するステップと、前記販売業者の場所での前記製品の製品在庫表示を提供するステップと、を含むコンピュータ実行方法。
【選択図】図９

Description

本発明は、一般に、製品販売、及び、製品を販売する企業に関するデータを収集し、収集したデータに基いて、在庫見積もりを提供する技術に関する。

インターネットの様なコンピュータ・ネットワークでは、膨大な量の情報の伝送と受信が可能である。例えば、近年、一部の商業小売店では、インターネットを介して消費者が利用できる製品在庫情報、及び、製品販売に関する他のデータを顧客がインターネット上で入手可能にするように試みるようになった。だが、この情報の殆どは、情報の取得に時間がかかり、しかも、コストもかかるレガシー・システムに記憶されている。この結果、各小売店から提供されるオンライン情報の多くは、精確ではない。同様に、多くの第三者企業は、複数の小売店における地域の製品情報をまとめ（例えば、製品情報等を公開するウェブサイト、または、他のシステムからの情報の切り抜き処理等によって）、この情報をインターネットを介して提供することを試みている。これらの試みもまた、上手くいっていない。恐らく、これは、広範囲の製品、小売店、及び、場所に関する精確なデータにアクセスすることが難しいからであろう。更に、在庫データを取得した場合、データは、第三者企業に届くまでに古くなっていることが多く、これにより、在庫データは、精確でなくなることもある。

従って、当技術分野では、複数の製品、小売店、及び、場所を網羅する精確な地域製品情報を顧客に提供するシステムが、必要とされている。

製品在庫の見積もり法は、製品の販売事象（製品提供行為）の速度、及び、その製品に関する過去の製品在庫の見積りから経過した時間量を決定することを含む。次に、この製品に関する新たな製品在庫見積りを、この製品の販売事象速度に基いて決定する。製品に関する販売事象の速度は、販売業者からの製品に関するデータ・フィード、または、他の販売データに基いて決定できる。

一態様によれば、製品在庫インジケータを提供するための、コンピュータ実行方法は、販売時点管理（ＰＯＳ）データを受信することを含む。ＰＯＳデータは、販売した製品、この製品を販売した店舗、及び、製品を販売した時間に対応するタイムスタンプを特定する。製品、及び、店舗に対応するデータ・オブジェクトが引き出される。このデータ・オブジェクトは、製品の販売事象間の平均時間を示す（販売事象）速度フィールド（(<t>)）と、製品在庫インジケータを「限定」モードへと切り替える必要のある時間を示す限定時間フィールドと、製品在庫インジケータを「在庫切れ」モードへと切り替える必要のある時間を示す在庫切れ時間フィールドと、並びに、製品の最後の販売時間に対応するタイムスタンプ・フィールド（T_{last_sale}）とを含む。新たな限定時間が、少なくとも第１のタイムスタンプ、（販売事象）速度フィールド、タイムスタンプ・フィールド、及び、第１の確率閾値（p1）に基いて決定される。新たな在庫切れ時間が、少なくとも第１のタイムスタンプ、（販売事象）速度フィールド、タイムスタンプ・フィールド、及び、第２の確率閾値（p２）に基いて決定される。限定時間フィールドを、新たな限定時間で更新する。在庫切れ時間フィールドを、新たな在庫切れ時間で更新する。データオブジェクトを記憶する。このデータオブジェクトの中に記憶されたデータに少なくとも基いて、製品在庫インジケータを提供する。

１部の例示的実施形態に従って、ＰＯＳデータを収集するシステムを示す。 １部の例示的実施形態に従って、ＰＯＳデータを収集するシステムを示す。 １部の例示的実施形態に基づくＰＯＳデータ収集器のブロック図を示す。 １部の例示的実施形態に従って、ＰＯＳデータを収集する方法を示すブロック・フロー図である。 １部の例示的実施形態に従って、データを抽出するシステムを示す。 １部の例示的実施形態に従って、データを抽出するシステムを示す。 １部の例示的実施形態に従って、データを抽出するシステムを示す。 １部の例示的実施形態に従って、データを抽出する方法を示すブロック・フロー図である。 １部の例示的実施形態に従って、製品在庫を見積もるシステムを示す。 １部の例示的実施形態に従って、製品在庫を見積もる方法を示すブロック・フロー図を示す。 １部の例示的実施形態に従って、製品在庫を見積もる方法を示すブロック・フロー図を示す。 １部の例示的実施形態に従って、製品在庫を見積もる方法を示すブロック・フロー図を示す。 １部の例示的実施形態に基づくデータ・オブジェクトのブロック図を示す。

本明細書において述べる方法、及び、システムでは、製品在庫の精確な見積もり、並びに、世界中の地域の販売（ＰＯＳ）データや、製品販売、及び、製品を販売する企業に関する他の情報の収集が可能である。

一部の例示的実施形態によれば、ＰＯＳデータ収集システムは、ハードウェア装置、及び／または、ソフトウェアとして実装されるＰＯＳデータ収集器を含むことができる。このアダプター（ＰＯＳデータ収集器）は、小売店舗の販売場所、例えば、バーコード・スキャナーとＰＯＳ端末（例えば、レジ装置）上で実行するＰＯＳアプリケーションとの間で設置することが可能である。製品を販売場所でスキャンする際、アダプターは、バーコードがバーコード・スキャナーからＰＯＳアプリケーションへと送られる時に、バーコードを読み取ることができる。バーコードを読み取った後、アダプターは、バーコードを、著しく遅延させることなくＰＯＳアプリケーションへ送信できるので、アダプターによる通常の業務処理の中断は起こらない。更に、アダプターは、ネットワーク接続を介して、バーコードを遠隔サーバに送ることもできる。このようにして、遠隔サーバは、膨大な数の製品、小売店、及び、場所を網羅するＰＯＳデータを収集できる。

これと同じ実施形態、若しくは、付加的な実施形態では、データ収集システムは、ソフトウェアとして実装される情報抽出手段を含むことができる。この情報抽出手段は、商業小売店舗のローカル・コンピュータ・システムに実装可能であり、これを用いて、製品販売、及び／または、商業小売店舗自体に関する情報を抽出することができる。例えば、多くの商業小売店には、製品在庫情報、販売データ、店舗一覧（例えば、１つ以上の場所を持つ企業の場合）、製品一覧（例えば、販売している全商品）、価格‐数量データ（例えば、店舗ごと、製品価格ごと）、店舗地図、チラシ、クーポン等を記憶するローカル・コンピュータ・システムが備えられている。これらのデータ、及び、製品販売や製品を販売する企業に関する他のデータは、商業小売店舗のローカル・コンピュータシステムに記憶され得る。

このデータは、市販データベースの形式（例えば、ＭｙＳＱＬ、Ｏｒａｃｌｅ、ＭＳ ＳＱＬ Ｓｅｒｖｅｒ等）、または、他の公知の方法（例えば、製品在庫／販売ソフトウェア、フラット・ファイル、スプレッドシート等）に従って記憶可能である。一部の例示的実施形態によれば、情報抽出手段を用いて、この様なデータベース（または、他の公知の形式）に記憶された情報へ、容易、且つ、直感的にインターフェースを有することができ、それにより、データを抽出し、これをネットワーク接続を介して遠隔サーバへ送信することができる。例えば、情報抽出手段は、既存データベースの属性を遠隔コンピュータが予期するものへと、容易、且つ、直感的に対応付けたり、一度、定期的、及び／または、実時間での抽出データの遠隔サーバへの送信を容易、且つ、直感的にスケジュールするためのユーザ・インターフェースを提供することが可能である。この方法によって、遠隔コンピュータは、膨大な数の製品、小売店、及び、場所を網羅する情報を収集できる。

これと同じ実施形態、若しくは、付加的な実施形態では、製品在庫見積もりシステムは、商業小売店舗のコンピュータ・システムの一部、若しくは、第三者のコンピュータ・システムの一部として実装可能である。製品在庫見積もりシステムは、商業小売店が、販売用に提供する所与の全ての製品の在庫を見積もるのに使用できる。この様な製品見積もりは、例えば、ＰＯＳデータ、定期的な在庫供給量、バーコード・スキャンデータ、全地球測位システム（ＧＰＳ）データ、領収書解析データ（利用者、または、企業から受け取った領収書の画像の光学文字認識データ）、第三者アグリゲータからのデータといった他の「商取引以外の」データ、及び、適切な他のデータを含む任意の数の入力データに基づくことが可能である。例示的実施形態によれば、製品在庫見積もりは、所与の製品の販売事象の速度の決定に基くことが可能である。他の例示的実施形態では、製品在庫見積もりは、所与の製品の販売の速度の測定に基づくこともある。これらの例示的実施形態の双方は、上記の入力データを使用可能であり、このデータは、実時間で（例えば、ネットワーク／通信／システムの遅延を考慮に入れて最大限迅速に）、若しくは、周期単位で（例えば、８時間ごと、一日一度、或いは、他の適切な時間周期でスケジュールした、小売店からのバッチ更新）で利用できる。例示的実施形態によれば、製品在庫見積もりシステムは、在庫見積もりを、例えば、見込み顧客が、製品のインターネット検索を実行する際に、この見込み顧客に対して提供可能である。

本発明の１つ以上の態様は、本明細書で論じ、説明する機能を具現化するコンピュータ・プログラムを含むことができる。しかしながら、本発明をコンピュータ・プログラムとして実現するのに、多くの様々な方法があり得ること、そして、本発明を任意の１組のコンピュータ・プログラム命令に制限するものと解釈すべきでないことは明らかなはずである。更に、熟練したプログラマーであれば、添付のフローチャート、及び、本出願の文章における関連説明に基いて、本開示の発明を実現するため、この様なプログラムを書くことができるであろう。それ故、本発明をどの様に作成し、これを使用するかについて適切に理解する上で、特定の組のプログラム・コード命令の開示は、必要であるとは認識されない。以下、本発明の独創的な機能について、プログラム・フローを説明する図と併せて読まれる以下の説明でより詳細に述べる。

ここで、図面を参照する。これらの図面では、その全体を通じて、類似の番号は、類似の構成要素を示しており、本発明の例示的実施形態が、詳細に述べられる。

図１は、１部の例示的実施形態に従って、ＰＯＳデータを収集するためのシステム１００を示す。図１で示すように、システム１００は、ＰＯＳデータ収集器１０５、ＰＯＳスキャナー１１０、ＰＯＳ端末１１５、並びに、遠隔システム１５０を含むことができる。ＰＯＳデータ収集器１０５は、接続１２０を介して、ＰＯＳスキャナー１１０へと接続し、接続１２５を介して、ＰＯＳ端末１１５へと接続することが可能である。ＰＯＳデータ収集器１０５は、限定されないが、ユニバーサル・シリアル・バス（ＵＳＢ）、ＲＳ−２３２、及び／または、これらの任意の組み合わせを含む任意の標準、または、専用ストレージ、及び／または、通信プロトコルを用いて、ＰＯＳスキャナー１１０、及び、ＰＯＳ端末１１５と通信できる。また、図１の実施形態は、有線接続１２０、１２５を示しているが、これら接続の何れか、若しくは、双方を、他の一部の例示的実施形態に従って、無線通信リンク（例えば、Ｗｉ−Ｆｉ、 ＭｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等）に置き換えることも可能である。更に、図１、及び、図２では、ＰＯＳデータ収集器１０５を、独立したハードウェア装置として示しているが、ＰＯＳデータ収集器１０５の１つ以上の構成要素を、代替の例示的実施形態に従って、ＰＯＳスキャナー１１０、及び、ＰＯＳ端末１１５の一方、または、双方に統合する場合もある。

図１で示すように、ＰＯＳスキャナー１１０は、一部の例示的実施形態によれば、従来の略固定型のバーコードスキャナーで良い。図２は、代替実施形態に基づくシステム２００を示し、このシステムでは、ＰＯＳスキャナーは、ＰＯＳ無線バーコードスキャナー２１２、及び、ＰＯＳ無線基地局２１０を含む。この代替実施形態では、ＰＯＳデータ収集器１０５は、ＰＯＳデータ収集器１０５が図１のＰＯＳスキャナー１１０と通信するのと同じ方法で、ＰＯＳ無線基地局２１０と通信可能である。図１、及び、図２は、異なる例示的実施形態を説明しているが、ＰＯＳデータ収集器１０５は、図１、及び、図２で示したものとは異なるハードウェアを備えたＰＯＳシステムにおいても同様に使用可能であることも理解されたい。

例示的実施形態によれば、ＰＯＳスキャナー１１０は、バーコード・スキャナーで良く、限定されないが、ＵＰＣ、ＥＡＮ、ＪＡＮ等を含む任意の数のバーコード形式を読み取るよう構成できる。他の例示的実施形態によれば、ＰＯＳスキャナー１１０は、ＲＦＩＤ読み取り装置、若しくは、ＰＯＳシステム内の製品識別情報の読み取りに対応する他の任意の装置でも良い。

図１で更に示すように、ＰＯＳデータ収集器１０５は、ネットワーク１４０を介して、遠隔システム１５０へと通信可能に接続できる。ネットワーク１４０は、ストレージエリア網（ＳＡＮ）、パーソナルエリア網（ＰＡＮ）、ローカル・エリア網（ＬＡＮ）、メトロポリタン・エリア網（ＭＡＮ）、広域網（ＷＡＮ）、無線ローカル・エリア網（ＷＬＡＮ）、仮想プライベート網（ＶＰＮ）、イントラネット、インターネット、または、信号、データ、及び／または、メッセージ（総称して、データと呼ぶ）の通信を支援する他の任意の適切なアーキテクチャー、或いは、システムとして実現されるか、または、その一部を構成できる。ＰＯＳデータ収集器１０５は、接続１３５を介して、ネットワーク１４０と接続できる。例示的実施形態によれば、接続１３５は、専用のセルラー・モデム接続でも良い。代替実施形態では、接続１３５は、有線イーサネット（登録商標）接続、有線／無線インターネット接続（例えば、ＭｉＦｉ）を備えたホットスポットへのＷｉ−Ｆｉ、または、Ｂｌｕｅｔｏｏｔｈ（登録商標）接続、或いは、ネットワーク１４０での信号の通信に適した任意の他の有線、或いは、無線接続が可能である。

図３は、一部の例示的実施形態に基づくＰＯＳデータ収集器１０５のブロック図である。ＰＯＳデータ収集器１０５の構成要素は、限定されないが、プロセッサー３６０、ストレージ資源３６２、ネットワーク・モジュール３６４、入出力（Ｉ／Ｏ）モジュール３６６、クロック・モジュール３６８、ＧＰＳモジュール３７０、及び、障害インジケータ１３０（障害インジケータ１３０は、図１、図２でも図示）を含んでも良い。図示の様に、プロセッサー３６０は、ＰＯＳデータ収集器１０５の他の構成要素のそれぞれと通信可能に接続できる。

プロセッサー３６０は、プログラム命令の解釈、及び／または、実行、及び／または、ソフトウェア・モジュール３８０に関連するデータの処理を実行するよう動作する任意のシステム、デバイス、若しくは、装置を含んでも良く、限定されないが、マイクロプロセッサー、マイクロコントローラ、デジタル信号プロセッサー（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、または、プログラム命令の解釈、及び／または、実行、及び／または、データ処理用に構成された他の任意のデジタル、または、アナログ回路を含むことが可能である。ある実施形態では、プロセッサー３６０は、ローカルに記憶された（例えば、ストレージ資源３６２内）プログラム命令の解釈、及び／または、実行、及び／または、ローカルに記憶されたデータを処理できる。同じ実施形態、若しくは、代替実施形態では、プロセッサー３６０は、遠隔に記憶された（例えば、図１、及び、図２のネットワーク１４０のネットワーク・ストレージ資源（図示せず））プログラム命令の解釈、及び／または、実行、及び／または、遠隔に記憶されたデータを処理できる。

ローカル・ストレージ資源３６２は、コンピュータ可読媒体（例えば、ハードディスク・ドライブ、フロッピー（登録商標）・ディスク・ドライブ、ＣＤ‐ＲＯＭ、及び／または、他の種類の回転ストレージ・メディア、フラッシュ・メモリー、ＥＥＰＲＯＭ、及び／または、他の種類の固形ストレージ・メディア）を含むことが可能で、通常、データを記憶するよう動作できる。

ネットワーク・モジュール３６４は、情報ＰＯＳデータ収集器１０５とネットワーク１４０（図１と図２）との間のインターフェースとして機能するよう動作する任意の適切なシステム、装置、または、デバイスが可能である。ネットワーク・モジュール３６４によって、情報ＰＯＳデータ収集器１０５は、限定されないが、ネットワーク１４０、及び、接続１３５に関する説明において前述で列挙した全ての伝送プロトコル、及び／または、規格を含む任意の適切な伝送プロトコル、及び／または、規格を用いてネットワーク１４０を介して通信できる。

Ｉ／Ｏモジュール３６６は、通常、情報ＰＯＳデータ収集器１０５へと／情報ＰＯＳデータ収集器１０５から／情報ＰＯＳデータ収集器１０５内でデータを受信、及び／または、送信するよう動作する任意のシステム、デバイス、または、装置であり得る。Ｉ／Ｏモジュール３６６は、例えば、限定されないが、ＵＳＢインターフェース、及び／または、ＲＳ−２３２インターフェースを含む任意の数の通信インターフェースを含めることができる。

クロック・モジュール３６８は、通常、内部クロックを維持するよう動作する任意のシステム、デバイス、または、装置で良い。ある例示的実施形態によれば、クロック・モジュール３６８は、ＵＴＣ（協定世界時）と同期できる。更に、クロック・モジュール３６８は、ＰＯＳデータ収集器１０５への電力が絶たれた時（例えば、独立バッテリー式電源を介して）、精確な内部クロックを維持するよう構成可能である。

ＧＰＳモジュール３７０は、全地球測位衛星信号、または、他の類似法（例えば、ネットワーク・モジュール３６４によって受信された位置情報を介して）に基いて、ＰＯＳデータ収集器１０５の位置を判定し、これを提供するよう通常動作する任意のシステム、デバイス、または、装置であり得る。

障害インジケータ１３０としては、通常、ＰＯＳデータ収集器１０５付近の利用者が視覚的、若しくは、聴覚的に検知可能な表示を提供するよう動作する任意のシステム、デバイス、または、装置が可能である。例えば、障害インジケータ１３０は、一部の例示的実施形態によれば、可視ＬＥＤライトであり得る。同じ実施形態、または、代替実施形態において、障害インジケータは、可聴ノイズをできる可聴式スピーカの場合もある。

図４は、一部の例示的実施形態に従って、ＰＯＳデータを収集する方法４００を示すブロックフロー図である。この方法について、図１‐３で説明した構成要素を参照して説明する。

ブロック４０５では、ＰＯＳデータ収集器１０５のソフトウェア・モジュール３８０は、、購入される製品に関連する製品識別情報（ＩＤ）を取得するように待機することができる。例えば、ＰＯＳスキャナー１１０を用いて、購入する製品のバーコードをスキャンする。スキャン後、ＰＯＳスキャナー１１０は、ＰＯＳ端末１１５上で実行するＰＯＳアプリケーションによる処理のため、製品識別情報を送信する。ＰＯＳデータ収集器１０５は、ＰＯＳスキャナー１１０、及び、ＰＯＳ端末１１５間で通信可能に接続されているので、ＰＯＳデータ収集器１０５は、購入された製品に関連する製品識別情報が、ＰＯＳ端末１１５へ送信される際、この製品識別情報を取得できる。

ブロック４１０では、ソフトウェア・モジュール３８０が、更新されていないバージョンの製品識別情報をＰＯＳ端末１１５へ送信することができる。一部の例示的実施形態によれば、この送信は、著しい遅延をもたらさずに実行可能であるので、ＰＯＳシステム１００へのＰＯＳデータ収集器１０５の追加によって、通常の業務フローが阻害されることはない。即ち、ＰＯＳ端末１１５上で実行するＰＯＳアプリケーションは、購入取引を進めることが可能となり、ＰＯＳデータ収集器１０５のＰＯＳシステム１００への追加に起因する著しい遅延は発生しない。

ブロック４１５では、ソフトウェア・モジュール３８０は、ネットワーク・モジュール３６４とネットワーク１４０を介して、遠隔システム１５０との接続を確立できる。例示的実施形態によれば、ソフトウェア・モジュール３８０は、ＤＮＳ、または、他のプロトコルを介して、ホスト名、及び／または、アドレスを解決してから、接続を確立するため、遠隔システム１５０と通信することによって、この接続を確立することが可能である。接続が成功裏に確立されれば（ブロック４２０）、ソフトウェア・モジュール３８０は、ブロック４２５へと進み、製品識別情報を遠隔ホスト端末１５０へと送信できる。一部の例示実施形態によれば、この送信は、ＨＴＴＰＳ プロトコル、若しくは、データをネットワーク１４０を介して遠隔システムへと送信するのに適した任意の他のプロトコルを介して可能である。ＨＴＴＰＳ プロトコルを使用する例示的実施形態に従うと、ソフトウェア・モジュール３８０は、ＳＳＬ証明書の有効性を検証し、有効性が立証されなければ、データを送信しなくても良い。

例示的実施形態によれば、ブロック４２５でのデータ送信は、製品識別情報のみを含むだけであり得る。別の実施形態では、ソフトウェア・モジュール３８０は、追加データを遠隔サーバ１５０へ送信できる。両方の事例において、例示的実施形態で使用されるＨＴＴＰＳ プロトコルによれば、送信データを、ＨＴＴＰＳを介して、ＰＯＳＴ要求の本体として送ることが可能である。このため、製品識別情報のみを送信した場合、ＰＯＳＴ要求の本体は、以下のフィールドを含み得る。
scan:<product_identifier>

代替実施形態において、ソフトウェア・モジュール３８０は、限定されないが、以下の１つ以上を含むデータを提供することができる：販売業者識別情報、店舗識別情報（例えば、店舗が１つ以上ある販売業者の場合）、製品のスキャン回数、現タイムスタンプ、装置識別情報（例えば、製造者が発行したシリアル番号）、セキュリティ・キー（例えばセキュア通信のための）、ソフトウェア・バージョン番号、価格、装置のＧＰＳ座標を含む追加データを提供できる。本代替実施形態によれば、ＰＯＳＴ要求の本体は、以下のフィールドの１つ以上を含むことが可能である。
serial:<device_identifier>
key:<security key>
version:<software version>
currenttime:<current_time>
sequence:<scanned_product_count>
store:<store_identifier>
gps:<gps_coordinates>
scan:<product_identifier>

更に別の例示的実施形態では、ソフトウェア・モジュール３８０は、製品識別情報が、ＰＯＳスキャナーで走査された時間を示すタイムスタンプを提供できる。この実施形態によれば、上記のＰＯＳＴ要求の本体は、以下の様に変更できる。
scan:<product_identifier>:<timestamp>

ブロック４４５では、ソフトウェア・モジュール３８０は、送信に成功したかどうかを判定できる。例えば、ＨＴＴＰＳを介した送信によれば、送信に成功した時、ソフトウェア・モジュール３８０は、空の本体を含むＨＴＴＰ ２００／ＯＫ 応答を受信可能である。一方、送信に失敗した場合、ソフトウェア・モジュール３８０は、４ｘｘ、若しくは、５ｘｘのＨＴＴＰエラーの何れかを受信できる。

データ送信に失敗した場合（ブロック４４５において）、ソフトウェア・モジュール３８０は、ブロック４５０に進んで、所定再試行回数を超えているかどうかを判定できる。所定再試行回数を超えていなければ、ソフトウェア・モジュール３８０は、再試行回数を１進めてから、ブロック４２５に進むことができ、そこで、製品識別情報（及び、上記の他の任意のデータ）を遠隔システム１５０に再度送信することを試みることができる。例示的実施形態によれば、ソフトウェア・モジュール３８０は、ブロック４２５へすぐに進むことができる。他の実施形態では、ソフトウェア・モジュール３８０は、所定時間量（例えば、１、５、 １０分等）待機してから、送信をやり直すことでできる。更に他の例示的実施形態では、ソフトウェア・モジュール３８０は、再試行前に１分間（「タイムアウト間隔」）待機し、次の試行送信にも失敗した場合には、タイムアウト間隔を２倍にする。この実施形態では、ソフトウェア・モジュール３８０は、タイムアウト間隔が３２分となるまで、続けて失敗した送信試行ごとに、タイムアウト間隔を２倍にし続けることが可能であり、タイムアウト間隔が３２分となった時点で、ソフトウェア・モジュール３８０は、３２分ごとにデータ送信を試行し続けることもできる。

ブロック４５０において、送信試行回数が所定の再試行回数を超える場合、ソフトウェア・モジュールは、ブロック４４０へと進んで、障害インジケータ１３０を起動できる。このようにして、ＰＯＳデータ収集器に障害が発生したという旨を、小売店の従業員に通知することが可能である。

同様に、接続確立に失敗した場合（ブロック４２０での判定）、ソフトウェア・モジュール３８０は、ブロック４３５へと進んで、所定再試行回数を超えたかどうかを判定できる。所定再試行回数を超えていなければ、ソフトウェア・モジュール３８０は、再試行回数を１進めてから、ブロック４１５へ進み、そこで、遠隔システム１５０との接続確立を再度試行する。ここでは、前述のものと類似するタイムアウト間隔アルゴリズムを使用できる。ブロック４３５において、接続試行回数が所定再試行回数を超える場合、ソフトウェア・モジュールは、ブロック４４０に進んで、障害インジケータ１３０を起動できる。このようにして、ＰＯＳデータ収集器に障害が発生したという旨を、小売店の従業員に通知できる。

障害インジケータが起動すると、ソフトウェア・モジュール３８０は、ブロック４０５へ戻り、そこで、購入している追加の製品に関連する次の製品識別情報を取得するため待機できる。従って、ソフトウェア・モジュール３８０は、障害状況であっても、動作し続けることができる。この方法により、ＰＯＳデータ収集器１０５は、スキャンした製品識別情報をＰＯＳ端末へ送信し続けることが可能であるので（ブロック４１０）、障害状態が業務運営に影響することはない。例示的実施形態（図示せず）によれば、この様な場合において、ソフトウェア・モジュール３８０は、遠隔システムとの接続確立、または、遠隔システム１５０へのデータ送信のための次回の試行に成功すれば、障害インジケータを解除することができる。

従って、図４の例示的実施形態によれば、ＰＯＳデータ収集器１０５は、各製品がスキャンされる時と略実時間で、しかも、著しい遅延をもたらさずに（即ち、図４の方法手順を実行に必要なだけの遅延より大きな遅延がなく）各製品識別情報を送信できる。

例示的実施形態に基づき、且つ、実時間でＰＯＳデータを送信する代替実施形態として、ＰＯＳデータ収集器１０５は、ＰＯＳデータを蓄積し、蓄積データを定期的に遠隔システム１５０へ送信できる。例えば、蓄積された製品識別データが、遠隔システム１５０へと送られるまで、ソフトウェア・モジュール３８０は、蓄積された製品識別データをストレージ資源３６２に記憶可能である。一実施形態では、例えば、ソフトウェア・モジュール３８０は、所定時間（例えば、５、１５、３０分等）の間製品識別情報を蓄積してから、このデータを遠隔サーバ１５０へ送ることができる。他の実施形態では、ソフトウェア・モジュール３８０は、製品識別情報を蓄積し、所定数の識別情報（例えば、５、１００、１０００個等）が蓄積された後で、この識別情報を遠隔サーバ１５０へと送信できる。

更に別の実施形態では、ソフトウェア・モジュール３８０は、ＰＯＳデータを蓄積し、時間周期、及び、所定の製品識別情報の計数の双方を用いて、データの遠隔システム１５０への送信時を決定することが可能である。この例示的実施形態によれば、ソフトウェア・モジュール３８０は、所定時間の間、または、所定数の製品識別情報が蓄積されるまで、いずれか先に起こるまで、製品識別情報をバッファに保存することが可能である。更に別の実施形態では、ソフトウェア・モジュール３８０は、所定量のデータ（例えば、１ｋＢ、１ＭＢ等）が蓄積されるまで、ＰＯＳデータを蓄積できる。従って、適切な頻度で更新データを送信しながら、トラフィックを最小にするよう、データ送信を最適化することが可能である。

従って、ソフトウェア・モジュール３８０は、例示的実施形態に従って、蓄積された製品識別情報のみを送信できる。この様な場合、ＨＴＴＰＳ要求の本体は、以下の様な形式が可能である。
scan:<product_identifier>:<timestamp>
scan:<product_identifier>:<timestamp>
. . .

ソフトウェア・モジュール３８０が、製品識別情報の他にもデータを提供する実施形態において、ＰＯＳＴ要求の本体は、以下のフィールドの１つ以上を含むことができる。
serial:<device_identifier>
key:<security key>
version:<software version>
currenttime:<current_time>
sequence:<scanned_product_count>
store:<store_identifier>
gps:<gps_coordinates>
scan:<product_identifier>:<timestamp>
scan:<product_identifier>:<timestamp>
. . .

上記の例示的実施形態では、ネットワーク・モジュール３６４とネットワーク１４０を介した遠隔システム１５０への接続は、開放されたままとするか、または、送信の度に閉じることが可能である。

ＰＯＳデータ収集器１０５は、例示的実施形態に従って、作動インジケータを遠隔システム１５０へと送信できる。例えば、製品がスキャン走査されるかどうかに関係無く、ソフトウェア・モジュール３８０は、定期的（例えば、４、６、８時間等ごと）に、作動インジケータを遠隔システム１５０へ送信可能である。ソフトウェア・モジュール３８０は、図４で述べたものと類似するステップを用いて、作動インジケータを送信できる。例えば、ソフトウェア・モジュール３８０は、遠隔システム１５０との接続確立、及び、作動インジケータの送信を試行する際、同じ再試行／失敗アルゴリズムを実行できる。

送信でＨＴＴＰＳプロトコルを用いる例示的実施形態によれば、作動インジケータのＨＴＴＰＳ送信は、製品識別情報（複数）を送信するのに使用されるＵＲＬとは別のＵＲＬへと送ることもある。更に、動的ＰＯＳＴインジケータの本体は、以下のうちの１つ以上のフィールドを含むことが可能である。
serial:<device_identifier>
key:<security key>
version:<software version>
currenttime:<current_time>
sequence:<scanned_product_count>

従って、遠隔システム１５０は、作動インジケータ送信を用い、障害があるかどうかについて、ＰＯＳデータ収集器１０５を監視する。即ち、遠隔システム１５０は、所定時間周期のスケジュールに従って、作動インジケータを受信しない場合、ＰＯＳデータ収集器１０５が動作していないと判断できる。従って、ＰＯＳデータ収集システムの提供者は、該システムが正しい動作を停止した場合、ＰＯＳデータ収集器１０５の障害を解決するよう手配できる。

図５は、一部の例示的実施形態に従って、データを抽出するシステム５００を示す。図５で示すように、システム５００は、ローカル・コンピュータ５０２、遠隔ストレージ資源５０８、遠隔コンピュータ５１０、及び、遠隔データベース５１６を含むことができる。ローカル・コンピュータ５０２は、商業小売店本部に設置された小売店の中央サーバであるか、または、地域のサーバ、或いは、店舗専用のサーバであり得る。データベース５０４は、ローカル・コンピュータ５０２上に存在するか、または、遠隔データベース・サーバ（図示せず）上に存在可能であり、小売製品、及び／または、製品を販売する企業に関するデータを含むことができる。例えば、ローカル・コンピュータ５０２は、商業小売店舗によって保有され得、データベース５０４は、小売店の製品在庫、小売店の店舗（例えば、１つ以上の場所を持つ企業の場合）、販売取引、製品一覧、価格量データ（例えば、店舗ごと、製品価格ごと）、チラシ、クーポン等を含められる。例示的実施形態によれば、データベース５０４は、市販のデータベース・プログラム（例えば、ＭｙＳＱＬ、Ｏｒａｃｌｅ、 ＭＳ ＳＱＬ Ｓｅｒｖｅｒ等）で良い。代替実施形態では、データベース５０４は、市販の製品在庫／販売ソフトウェア、フラット・データファイル、スプレッドシート等の一部であっても良い。同様に、遠隔データベース５１６は、任意の種類が可能であり、ローカル・コンピュータ５０２から遠隔に配置可能である。

例示的実施形態によれば、情報抽出手段５０６は、ローカル・コンピュータ５1２上に配備可能である。情報抽出手段は、一般に、データベース５０４からデータを抽出し、抽出したデータを処理し、更に、データを遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０へと送信するよう動作するソフトウェアであり得る。図示の通り、情報抽出手段５０６は、設定ファイル５１４を含む。設定ファイル５１４は、バイナリー、平文、データベース、または、他の適切な形式を含む任意の形式が可能である。設定ファイル５１４は、データベース５０４、遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０に関連する接続やマッピング設定を含められ得る。情報抽出手段５０６、及び、設定ファイル５１４については、図６‐８を参照して以下で詳細に述べる。

遠隔ストレージ５０８は、ローカル・コンピュータ５０２、及び、遠隔コンピュータ５１０の双方からアクセス可能な任意のストレージ装置で良い。例示的実施形態によれば、遠隔ストレージ５０８は、ディスクベースののストレージ装置、例えば、磁気ストレージ、磁気光学ストレージ、または、他の種類のディスクベースのストレージを含められる。図５で示すように、遠隔ストレージは、例えば、独立したネットワーク接続ストレージ・ソリューションとして、または、クラウド・ストレージ・ソリューション等として、ローカル・コンピュータ５０２、及び、遠隔コンピュータ５１０から分離できる。また、遠隔ストレージ５０８は、例えば、遠隔コンピュータ５１０に存在するストレージ資源（若しくは、ストレージ資源アレー）として、遠隔コンピュータ５１０の一体部分を形成可能である。

遠隔コンピュータ５１０は、業務、科学調査、管制、娯楽、または、他の目的用の任意の形式の情報、知能、または、データを計算、分類、加工、送信、受信、検索取得、創出、交換、記憶、表示、明示、検知、記録、再生、処理、または、利用するよう動作可能な任意の手段、或いは、手段の集合であり得る。例えば、遠隔コンピュータ５１０は、メインフレーム・コンピュータ、ネットワーク・サーバ、パーソナル・コンピュータ、ＰＤＡ，家庭用電子機器、ネットワーク・ストレージ装置、または、他の任意の適切な装置が可能であり、サイズ、形状、性能、機能、及び、価格の点で異なり得る。遠隔コンピュータ５１０は、メモリー、中央処理装置（ＣＰＵ）またはハードウェア、或いは、ソフトウェア制御ロジックの様な１つ以上の処理資源を含むことができる。、遠隔コンピュータ５１０の追加の構成要素には、１つ以上のストレージ装置、外部装置と通信するための１つ以上の通信ポート、及び、キーボード、マウス、及び、ビデオ・ディスプレイの様な種々の入出力（Ｉ／Ｏ）装置が含まれ得る。更に、遠隔コンピュータ５１０は、種々のハードウェア構成要素間で情報を送信するよう動作する１つ以上のバスを含むこともできる。

更に、図５で示すように、ローカル・コンピュータ５０２は、ネットワーク５１２を介して、遠隔ストレージ（提供されていれば）、及び、遠隔コンピュータ５１０と通信可能に接続できる。ネットワーク５１２は、ストレージエリア網（ＳＡＮ）、パーソナルエリア網（ＰＡＮ）、ローカル・エリア網（ＬＡＮ）、メトロポリタン・エリア網（ＭＡＮ）、広域網（ＷＡＮ）、無線ローカル・エリア網（ＷＬＡＮ）、仮想プライベート網（ＶＰＮ）、イントラネット、インターネット、または、信号、データ、及び／または、メッセージ（総称して、データと呼ぶ）の通信を支援する他の任意の適切なアーキテクチャー、或いは、システムとして実現されるか、または、その一部とすることができる。例示的実施形態によれば、ローカル・コンピュータ５０２は、専用セルラー・モデム接続を介して、ネットワーク５１２へと接続できる。代替実施形態では、ローカル・コンピュータ５０２は、有線イーサネット（登録商標）接続、有線／無線インターネット接続（例えば、ＭｉＦｉ）を備えたホットスポットへのＷｉ−Ｆｉ、または、Ｂｌｕｅｔｏｏｔｈ（登録商標）接続、或いは、ネットワーク５１２を介した信号送信に適した他の任意の有線、或いは、無線接続を介して、ネットワーク５１２に接続できる。

図６は、一部の例示的実施形態に従って、データを抽出するシステム６００を示す。図６で示すように、システム６００は、設定ダイヤログ６０１を含むことができる。設定ダイヤログ６０１は、情報抽出手段５０６により、ローカル・コンピュータ５０２の利用者へ表示可能であり、通常、利用者からの入力を受容するよう動作可能である。例えば、設定ダイヤログ６０１は、データベース種類メニュー６０２を含められ得る。一部の例示的実施形態によれば、データベース種類メニュー６０２は、情報抽出手段５０６と互換性のある事前に構成されたデータベース種類の選択肢を含むドロップ‐ダウン形式のメニューが可能である。例えば、データベース種類メニュー６０２には、市販のデータベース・プログラム（例えば、ＭｙＳＱＬ、Ｏｒａｃｌｅ、ＭＳ ＳＱＬ Ｓｅｒｖｅｒ等）、市販の製品在庫／販売ソフトウェア（例えば、ＰＯＳｌｏｇ等）、フラットデータ・ファイル、スプレッドシート等のエントリーを含められ得る。これに従って、ローカル・コンピュータ５０２の利用者は、データベース種類メニュー６０２の中にあるデータベース５０４に対応する適切なエントリーを選択できる。

一部の例示的実施形態によれば、設定ダイヤログ６０１には、データベースホスト入力部６０４（任意でポート番号を含む）、データベース名称入力部６０６、ＤＢ利用者名入力部６０８、及び、ＤＢパスワード入力部６１０も、更に含められる。従って、ローカル・コンピュータ５０２の利用者は、データベース５０４固有の接続パラメータを指定可能であり、それにおり情報抽出手段５０６は、データベース内のデータへのアクセスを取得できる。図６では、入力部６０２〜６１０を明示的に示しているが、設定ダイヤログ６０１は、この特定の実施形態に限定されるべきものではない。例えば、データベース５０４アクセスに関連する別の入力部を、設けることも可能である。また、ローカル・コンピュータ５０２、及び、データベース５０４の特定の構成によっては、図示の入力部の一部は、データベース５０４にアクセスする上で必要ではないこともある。

今述べたデータベース構成パラメータに加えて、設定ダイヤログ６０１には、遠隔コンピュータ、及び／または、遠隔ストレージの構成パラメータも入力することもできる。例えば、一部の実施形態では、設定ダイヤログ６０１は、リモートユーザ入力部６１２、リモート・パスワード入力部６１４、スケジュール頻度メニュー６１６、スケジュール時間入力部６１８、及び、スケジュール日付メニュー６１９を含むこともある。一部の例示的実施形態では、スケジュール頻度メニュー６１６は、情報抽出手段５０６と互換性のある事前構成された頻度種類の選択肢を含むドロップ‐ダウン形式のメニューが可能である

図示の実施形態によれば、スケジュール頻度メニュー６１６は、情報抽出手段５０６がデータベース５０４からデータを抽出して、たとえば毎週土曜の午後７時（スケジュール時間入力部６１８、及び、スケジュール日付メニュー６１９によって指定）といった週単位で、抽出データを遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０へと送信する必要があることを示す「週単位」頻度種別を含む。他の実施形態では、スケジュール頻度メニュー６１６は、他の定期抽出頻度、例えば、「月単位」、「日単位」、または、「時間単位」等に関するエントリーを含むこともできる。

更に、別の実施形態では、スケジュール頻度メニュー６１６は、「即時」抽出、または、「手動」抽出用のエントリーも含む場合もある。これらの実施形態によれば、情報抽出手段５０６は、利用者が保存ボタン６２２をクリックすると即時、データベース５０４からデータを抽出し、抽出したデータを遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０へと送信できる。

更に、別の例示的実施形態によれば、スケジュール頻度メニュー６１６は、「実時間」抽出用のエントリーを含み得る。この実施形態によれば、情報抽出手段５０６は、実時間でデータベース５０４からデータを抽出し、抽出したデータを遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０へと送信することができる。例えば、実時間抽出は、データベース５０４内のデータベース・テーブルの更新に呼応して、実行できる。この機能は、例えば、製品価格、店舗閉鎖、販売促進、地域行事、製品販売（例えば、最新の販売情報を反映する品目データ）の更新、または、製品販売、及び／または、製品を販売する店舗に関する他の更新を反映する場合に便利である。他の例示的実施形態では、実時間抽出は、データベース５０４外の他の既定のイベント（例えば、ローカル・コンピュータの遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０への接続確立、情報抽出手段のデータベース５０４への接続確立等）に応答して実行できる。これらのイベント、及び、実時間抽出を始動する他のイベントは、設定ファイル５１４の中で提供可能である。

従って、パラメータ６１２〜６１９を提供することにより、ローカル・コンピュータ５０２の利用者は、遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０固有の接続パラメータを指定可能となり、情報抽出手段５０６が、これらに接続して、データを送信できる。図６において、入力部６１２〜６１９を明示的に示したが、設定ダイヤログ６０１は、この特定の実施形態のみに限定されるべきものではない。例えば、遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０へのアクセスに関する追加の入力部を提供することができる。また、ローカル・コンピュータ５０２、遠隔ストレージ５０８、及び、遠隔コンピュータ５１０の特定の構成如何によっては、図示の入力部の一部は、遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０にアクセスする上で必要ではないこともある。

例示的実施形態によれば、設定ダイヤログ６０１は、接続試験ボタン６２０、保存ボタン６２２、及び、クリアーボタン６２４を含むことが可能であり、これらは、各ボタンのレベルで表される機能を提供できる。例えば、接続試験ボタン６２０は、利用者が供給した入力パラメータを用いて、データべース５０４、遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０への有効な接続を検証できる。保存ボタン６２２は、利用者が供給した入力パラメータを設定ファイル５１４に保存できる。クリアーボタン６２４は、利用者が供給した入力パラメータを全てクリアーして、入力フィールドを空白、及び／または、未選択の状態とすることができる。

図７は、一部の例示的実施形態に従って、データを抽出するシステム７００を示す。図７で示すように、システム７００は、テーブル・マッピング・ダイヤログ７０２を含んでも良い。テーブル・マッピング・ダイヤログ７０２は、情報抽出手段５０６によって、ローカル・コンピュータ５０２の利用者へと表示でき、通常、データベース５０４のテーブル属性（例えば、テーブル・フィールド）の情報抽出手段５０６内の所定属性へのマッピングを支援する利用者からの入力を受容するよう動作可能である。一部の例示的実施形態では、テーブル・マッピング・ダイヤログ７０２は、ある種の情報、または、テーブルに固有でも良い。例えば、図７は、店舗情報専用のテーブル・マッピング・ダイヤログ７０２を示している。この実施形態によれば、利用者は、店舗情報（例えば、１つ、または、複数の店舗のある小売業者の場合）に関連するテーブル属性のマッピングを提供できる。他の例示的実施形態では、テーブル・マッピング・ダイヤログ７０２は、製品情報（特定の小売店が販売する全ての製品に関連するデータ）に固有であっても良い。更に別の例示的実施形態では、テーブル・マッピング・ダイヤログ７０２は、価格‐数量情報（例えば、店舗ごと、製品在庫ごと、及び、価格情報）に固有であっても良い。製品販売、及び、製品を販売する企業に関する他のデータを収集できるよう、テーブル・マッピング・ダイヤログ７０２に関する更に別の実施形態を提供可能である。

一部の例示的実施形態によれば、テーブル・マッピング・ダイヤログ７０２は、ドロップ‐ダウン・メニュー形式のテーブル・メニュー７０４を含むことができる。テーブル・メニュー７０４上で利用可能なエントリーは、設定ファイル５１４に記憶される接続パラメータを用いてデータベース５０４内で利用可能なテーブルに基いて提供可能である。利用者が、テーブル・メニュー７０４を用いてテーブルを選択すると、選択したテーブルの属性が、テーブル属性フィールド７０６内に表示され得る。図示の例では、選択したテーブル「Stores（店舗）」は、３つの属性、すなわち「name（店舗名）」、「address（住所）」、「id（識別情報）」を含む。テーブル・マッピング・ダイヤログ７０２は、店舗属性フィールド７０８も含むことができる。店舗属性フィールド７０８は、情報抽出手段５０６の既定属性を含められる。図示の実施形態では、テーブル・マッピング・ダイヤログ７０２は、上記のように、店舗情報に固有であることから、このフィールドは、「店舗属性」としてレベル付けされている。他の実施形態では、テーブル・マッピング・ダイヤログ７０２のこのフィールドは、別のレベルを有することができる（例えば、「製品属性」、「価格‐数量属性」等）。

従って、ローカル・コンピュータ５０２の利用者は、テーブル属性（テーブル属性フィールド７０６内で表示）、及び、情報抽出手段５０６の所定属性（例えば、店舗属性フィールド７０８内で表示）間のマッピングを提供することができる。例えば、利用者は、テーブル属性フィールド７０６から「name（店舗名）」を選択し、店舗属性フィールド７０８から「Name（店舗名）」を選択して、マッピング保存ボタン７１２を押下できる。同様に、利用者は、「address（住所）」を「Address Line（住所欄１）」へと、そして、「id（識別情報）」を「Store code（店舗コード）」へとマッピングすることができる。この例のマッピング結果は、図７のテーブル・マッピング・ダイヤログ７２０において示される。具体的には、マッピングは、マッピング済の値フィールド７２６の中で示される方法で、利用者に表示可能である。例示的実施形態に基づき、また（テーブル）マッピング・ダイヤログ７２０で示される様に、テーブル属性が一度マッピングされると、これは、テーブル属性フィールド７０６から削除できる。同様に、店舗属性がマッピングされると、これは、店舗属性フィールド７０６から削除できる。

例示的実施形態によれば、テーブル・マッピング・ダイヤログ７０２は、作成ボタン７１４、保存ボタン７１６、及び、クリアーボタン７１８を含むことが可能であり、これらは、各ボタンのレベルで表される機能を提供できる。例えば、作成ボタン７１４は、利用者が供給した入力パラメータを用いて、情報抽出手段５０６が、遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０へ送信するデータを表すファイルを作成する。このボタンは、例えば、利用者が供給したマッピングの正確さを確実にする上で、有用である。保存ボタン７１６は、利用者が供給した入力パラメータを設定ファイル５１４、または、個別のマッピング・ファイル（図示せず）に保存できる。クリアーボタン624は、利用者が供給した入力パラメータを全てクリアーして、入力フィールドを空白、及び／または、初期状態へと戻すことができる。

前述の例示的実施形態の特徴に基いて、ローカル・コンピュータ５０２の利用者は、既存のレガシー・データベース・システムのテーブル属性の、情報抽出手段５０６が望ましいものとする規定属性へのマッピングを容易に実行できる。

図８は、一部の例示的実施形態に従って、データを抽出する方法８００を示すブロックフロー図である。この方法８００は、図５〜７で説明した構成要素を参照して説明する。更に、図８は、一部の例示的実施形態に基いて、データを抽出する手段についても例示説明する。

ブロック８０２では、情報抽出手段５０６は始動条件にたいして待機することができる。例えば、その様な始動条件は、利用者から供給された設定ダイヤログ６０１のパラメータ６１６〜６１９に従って、提供可能である。上述の様に、始動条件は、定期的設定、即時設定、または、実時間設定に基づくことが可能である。設定した始動イベントが発生したら、情報抽出手段５０６は、ブロック８０４へと進むことができる。

ブロック８０４では、情報抽出手段５０６は、設定ファイル５１４を読み取り、利用者が供給した設定ダイヤログ６０１のパラメータ６０２〜６１０に従って、データベース接続パラメータを取得できる。更に、情報抽出手段５０６は、テーブル・マッピング・ダイヤログ７０２の中で提供された利用者が供給したマッピングに従って、テーブル・マッピング・パラメータを取得できる。ブロック８０６では、情報抽出手段５０６は、取得したデータベース接続パラメータを用いて、データベース５０４への接続を試みることができる。この接続試行に成功すれば、情報抽出手段５０６は、ブロック８０８へ進むことができる。

ブロック８０８では、情報抽出手段５０６は、データベース５０４内に存在する１つ以上のデータベース・テーブルからデータを抽出できる。例えば、情報抽出手段５０６は、ブロック８０４で得られた属性マッピングを用いて、指定されたテーブル・フィールドからデータを抽出することが可能である。更に、情報抽出手段５０６は、遠隔データベース５１６内に存在する１つ以上のデータベース・テーブルからもデータを抽出できる。このようにして、情報抽出手段５０６は、同じ場所、または、異なる場所にある複数のデータベースからデータを受けることが可能である。例えば、小売業者は、それぞれが販売データを保持する複数の店舗を運営する場合がある。情報抽出手段５０６は、各データベース５０４、５１６からデータを受けとり、点在する小売業者の販売データの全て（または、任意の所与の部分）に関するデータ源を提供できる。

ブロック８１０では、情報抽出手段５０６は、抽出データを処理することができる。例えば、情報抽出手段５０６は、抽出データの形式が、予期される形式（例えば、住所データの均一性、構文等）と一致するかどうかについて検証可能である。一部の実施形態では、情報抽出手段５０６は、抽出データの形式が予期される形式と一致しない場合は、抽出データを再フォーマットすることが可能であり、更に、抽出データの形式が期待される形式と一致する場合には、抽出データを再フォーマットしなくても良い。

同じ実施形態、または、付加的な実施形態では、ブロック８１０において、情報抽出手段は、抽出データに基いて、データを自動生成可能である。例えば、一部の実施形態において、情報抽出手段５０６は、所与の店舗位置に関する緯度、及び、経度情報を必要とする場合がある。この情報は、データベース５０４で入手できないことがある。従って、店舗位置の住所情報をデータベース５０４で取得でき、且つ、マッピング・ダイヤログ７０２を用いて、適切にマッピングされている場合、店舗位置の住所情報に基いて、緯度と経度の情報を生成するよう情報抽出手段５０６を設定可能である。前述の様に、ブロック８１０では、例示的実施形態に基いて、抽出データを処理する手段も説明できる。

ブロック８１２では、情報抽出手段５０６は、例えば、ブロック８０４で取得された遠隔ストレージ、及び／または、遠隔コンピュータ接続に関するパラメータを用いて、遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０に接続することを試行できる。この接続試行に成功したら、情報抽出手段５０６は、ブロック８１４に進み、そこで、情報抽出手段５０６は、データ（即ち、ブロック８１０において実行した追加／変更処理を施した抽出データ）を遠隔ストレージ５０８、及び／または、遠隔コンピュータ５１０へと送信できる。データを送った後、情報抽出手段５０６は、ブロック８０２に戻って、次の始動条件に対して待機することができる。

図９は、例示的実施形態に従って、製品在庫を見積もるためのシステム９００を示す。図９で示すように、システム９００は、コンピュータ９１０を含むことができる。コンピュータ９１０は、業務、科学調査、管制、娯楽、または、他の目的用の任意の形式の情報、知能、または、データを計算、分類、加工、送信、受信、検索、創出、交換、記憶、表示、明示、検知、記録、再生、処理、または、利用するよう動作可能な任意の手段、或いは、手段の集合で良い。例えば、コンピュータ９１０は、メインフレーム・コンピュータ、ネットワーク・サーバ、パーソナル・コンピュータ、ＰＤＡ、家庭用電子機器、ネットワーク・ストレージ装置、または、他の任意の適切な装置が可能であり、サイズ、形状、性能、機能、及び、価格の点で異なり得る。

コンピュータ９１０は、１つ以上の処理資源（例えば、プロセッサー９０１）を含むことができる。例えば、プロセッサー９０１は、プログラム命令の解釈、及び／または、実行、及び／または、ソフトウェア・モジュール９５０に関連するデータの処理を実行するよう動作する任意のシステム、デバイス、若しくは、装置を含んでも良く、限定されないが、マイクロプロセッサー、マイクロコントローラ、デジタル信号プロセッサー（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、または、プログラム命令の解釈、及び／または、実行、及び／または、データ処理用に構成された他の任意のデジタル、または、アナログ回路を含むことが可能である。いくつかの実施形態では、プロセッサー９０１は、ローカルに記憶されたプログラム命令の解釈、及び／または、実行、及び／または、ローカルに記憶されたデータを処理できる。同じ実施形態、若しくは、別の実施形態では、プロセッサー９０１は、遠隔に記憶されたプログラム命令の解釈、及び／または、実行、及び／または、遠隔に記憶されたデータを処理できる。

コンピュータ９１０の追加の構成要素は、１つ以上のストレージ資源を含むことができる。例えば、コンピュータ９１０は、ローカル・ストレージ資源（例えば、図３のローカル・ストレージ資源３６２について説明されたもの）、または、遠隔ストレージ資源（例えば、図５の遠隔ストレージ５０８について説明されたもの）等のストレージ資源９７０を含むことができる。更に、コンピュータ９１０は、外部装置（例えば、ネットワークＩ／Ｆ ９０２、 Ｉ／Ｏ （入出力装置）９０３等）と通信するための１つ以上の通信ポート、及び、キーボード、マウス、及び、ビデオ・ディスプレイの様な種々の入出力（Ｉ／Ｏ）装置も含められる。コンピュータ９１０は、種々のハードウェア構成要素間の情報を伝送するよう動作する１つ以上のバスも含み得る。

一部の例示的実施形態によれば、コンピュータ９１０は、例えば、商業小売業者の本部、支部、または、指定小売店舗に設置された商業小売業者のコンピュータ・システムの一部として実現可能である。他の例示的実施形態では、コンピュータ９１０は、例えば、、第三者企業の事業地に遠隔的に設置、若しくは（第三者によって保有／運用される）商業小売業者の本部、支部、または、小売店舗等に設置された第三者コンピュータ・システムの一部として実現可能である。コンピュータ９１０は、入力データ９２０を受け取るよう設定することができる。一部の例示的実施形態によれば、入力データ９２０には、例えば、ＰＯＳデータ、在庫データフィード、バーコード・スキャンデータ、全地球測位システム（ＧＰＳ）データ、レシートデータ（利用者、または、企業からの）、第三者アグリゲータからのデータの様な他の「商取引以外の」データ、及び、他のデータが含まれる。入力データ９２０は、実時間で（例えば、ネットワーク／通信／システムの遅延を考慮して最大限迅速に）、または、定期的（例えば、小売業者がスケジュールした分ごと、時間ごと、８時間ごと、１日１度、または、適切な他の時間周期からのバッチ更新処理）で取得可能である。

コンピュータ９１０は、製品在庫見積もり結果出力９３０を提供するように設定可能である。一部の例示的実施形態によれば、（製品在庫見積もり結果）出力９３０は、製品在庫見積もりを見込み買い手（例えば、消費者）に提供するのに使用できる。例えば、コンピュータ９１0は、インターネット検索エンジン／ウェブ・サーバとして構成可能である。この実施形態では、消費者は、特定の製品についてインターネット検索を実行できる。消費者の検索要求に応答して、コンピュータ９１０は、製品在庫見積もり結果出力９３０を含む検索結果を提供することができる。検索結果は、製品を扱う複数の近隣の商業小売業者、及び、近隣の商業小売業者それぞれでの販売用に製品の在庫があるかどうかを示す等のため、各小売店に関する製品在庫見積もり結果出力９３０を含められる。また、コンピュータ９１０は、（製品在庫見積もり結果）出力９３０を、例えば、インターネット検索エンジン／ウェブサーバへと通信可能に接続できるよう、独立した製品在庫見積もりシステムとして構成可能である。特定の製品に関するインターネット検索に応答して、この代替実施形態は、ウェブサーバとコンピュータ９１０が、別個のハードウェア要素であるということを除き、前述の様に機能できる。従って、ウェブサーバは、コンピュータ９１０に問い合わせて、製品在庫見積もり結果出力９３０（店舗単位ごとに）取得可能であり、この情報は、検索結果と共に提供できる。

他の例示的実施形態において、（製品在庫見積もり結果）出力９３０は、製品在庫見積もりを商業小売業者へと提供するために、使用可能である。この実施形態では、コンピュータ９１０は、商業小売業者の店舗に配置された端末（例えば、ＰＯＳ端末、倉庫の端末、または、他の端末）であるか、或いは、この様な端末に（ローカル、または、遠隔の何れかで）接続する独立したシステムであり得る。この実施形態によれば、特定の製品の在庫見積りは、例えば、店舗の従業員が端末を使用することによって得ることができる。この実施形態の端末は、前述のインターネット検索エンジン／ウェブサーバと同様に動作し、所定製品の在庫についてコンピュータ９１０に問い合わせると、見積もられた製品の在庫が、（製品在庫見積もり結果）出力９３０へと提供されることとなる（これによって、例えば、端末のモニター上に表示できる）。

一部の例示的実施形態によれば、コンピュータ９１０は、ソフトウェア・モジュール９５０を含むことができる。ソフトウェア・モジュール９５０は、特定の製品の在庫を、その製品の販売事象の速度に基いて、見積もる（即ち、（製品在庫見積もり結果）出力９３０を生成する）ことができる。例えば、製品販売事象の速度（r_e）は、以下の方程式で表現できる。
r_e = N_e/T
ここで式中、N_eは、期間Ｔ中の販売事象の回数である。一部の例示的実施形態によれば、r_eは、販売事象間の平均時間（<t>）から推定することができる。例えば、r_eを以下の式で表現できる。
r_e ≒ r_e<t> = 1/<t>
i回の販売事象の観測後、<t> を再帰的に以下の様に見積もることができる。
<t>_i = (1-k)*<t>_i-1 + k*t_i、
ここで式中、t_i は販売事象iと販売事象i-1間の時間であり、kは何らかの定数(0 < k < 1)である。
従って、販売事象速度(r_e)は、指数関数型の移動平均により表記でき、直近の事象ほど、過去の事象よりも多くの重みを含むこととなる（即ち、過去の事象の重みは、指数関数的に減衰し得る）。

一部の例示的実施形態によれば、製品在庫を見積もる際、ソフトウェア・モジュール９５０は、通常の業務時間を考慮に入れるよう、時間値を調整することが可能である。例えば、ある店舗が、午後５時に閉店して、翌朝９時に開店し、そして、所与の製品の直近２度の販売が、午後４時５８分、及び、翌朝午前９時２分に発生した場合、ソフトウェア（モジュール）９５０は、これらの販売事象間の時間が、４分であると決定できる。

表１では、一部の例示的実施形態に従って、販売事象の速度（r_e）を見積もるための一例のデータを示す。

表１の例示販売データによれば、販売事象の絶対速度は、8／25＝0．32事象／分である（２５分間中に８回の事象、第一事象は数えない）。この速度は、近似値である。何故ならば、最後の販売事象と一致するよう、時間周期の終了を恣意的に選択するからである。この例示販売データを用いて、<t>₈ を以下の式の様に再帰的に推定できる。

ここでも、ｋは、０から１までの定数値が可能である。例えば、ｋを０．１とする場合、上記方程式は、以下の様に解くことができる。

従って、kを0.1とすると、例示データについて見積もられた販売事象速度r_eは、0.42 事象／分である。注意すべき点として、kが小さいほど、過去の事象に対してより多くの重みを与え、kが大きいほど、より直近の事象に対して重みをより多くあたえることができる。kの選択値の効果を、表２で例示説明しており、ここでは、種々のkの値を想定した場合の、表1の例示データについて見積もられる販売事象速度(r_e)を提供する。

一部の例示的実施形態によれば、直近１０〜３０回の販売について見積もられた販売事象の速度を平均して、妥当な仮定が得られる。従って、ｋは、0.03 ≦ k ≦ 0.1の範囲の中に収まり得る。

一部の例示的実施形態によれば、販売事象の見積もり速度を用いて、製品在庫を見積もることができる。例えば、コンピュータ９１０のソフトウェア・モジュール９５０は、品目データを含むPOSデータ（例えば、入力データ９２０の全て、若しくは、その一部）を受けとることができる。１つの単一品目は、所与の製品品目の1つ以上が、所与の店舗において所与の時間に販売される販売事象を表すことができる。例示的実施形態によれば、ソフトウェア・モジュール９５０は、販売事象が、ポアッソン分布に従う（均一な場合もあれば、そうでない場合もある）ということを仮定することができる。これにより、所与の販売事象の見積もり速度r_eが与えられれば、ソフトウェア・モジュール９５０は、ある時間ｔ中に販売事象を観測しない確率をexp(-r_e*t)として近似できる。

例えば、販売事象速度r_e を 0.04事象/分 (2.4 事象/時)と仮定とする場合、販売事象間の平均時間は、1/2.4 ≒ 0.42時間 ≒ 25分となる。この例では、最終販売が、午後１２時に発生した場合、１時間の間に（即ち、午後１時までに）販売事象を観測しない確率は、exp(-2.4 * 1) = 0.091として近似できる。同様に、5時間の間に（即ち、午後5時までに）販売事象を観測しない確率は、exp(-2.4 * 5) = 6.14e^-6として近似できる。

例示的実施形態によれば、ソフトウェア・モジュール９５０は、確率p₁ 、 p₂( p₁ > p₂)を、以下の特性を用いて定義できる。
・時間t₀中に無販売事象がexp(-r * t₀) > p_１の様に発生する場合、見積もり製品在庫は、「在庫あり」としてリスト表示される。
・持続時間 t₁ 中に無販売事象がp₁ > exp(-r * t₁) > p₂の様に発生する場合、見積もり製品在庫は、「不明」としてリスト表示される。
・持続時間t₂ 中に無販売事象がexp(-r * t₂) < p₂の様に発生する場合、見積もり製品在庫は、「在庫切れ」としてリスト表示される。

例示的実施形態によれば、確率p₁ およびp₂ は、全ての製品にわたって一貫し得る。例えば、全ての製品の確率はp₁=0.1 、及び、 p₂=0.01であり得る。代替実施形態によれば、確率p₁ および p₂ は、製品ごとに一貫し得る。例えば、製品Ａの確率はp₁=0.1と p₂=0.01であり、製品Ｂの確率はp₁=0.2 と p₂=0.03等であり得る。一部の実施形態では、確率p₁ および p₂ は、比較的一定であり得る。他の実施形態では、確率p₁ および p₂ は、例えば、製品見積もりシステム９００の性能のフィードバック／解析に基く調整を受けることにより、時間と共に変動する場合もある。

更に、別の実施形態では、「不明」条件が満たされ得ないように、確率p₁ および p₂ は等しくあり得る（即ち、「在庫あり」、及び、「在庫切れ」インジケータのみを提供できる）。

図９のコンピュータ９１０は、データ・オブジェクト９４０を含んでも良い。一部の例示的実施形態によれば、データ・オブジェクト９４０は、ストレージ資源９７０内に存在可能であり、製品在庫見積もり結果出力９３０を求める際に使用できる。データ・オブジェクト９４０は、以下のデータフィールドを有し得る:製品ＩＤ９４１、店舗ＩＤ９４２、最終販売タイムスタンプ９４３(T_{last_sale})、販売事象速度９４４(r_e)、確率９４５ (p₁)、確率 ９４６ (p₂)、不明切り替え時間９４７ (T_unknown)、及び、在庫切れ切り替え時間９４８(T_out-of-stock)を含むことができる。例示的実施形態によれば、コンピュータ９１０は、製品と店舗の組み合わせごとに、個々のデータ・オブジェクト９４０を含んでも良い。即ち、コンピュータ９１０は、所与の店舗で販売される各製品について、データ・オブジェクト９４０を１つ持つことが可能である。従って、製品ＩＤ９４１は、特定の製品と対応し得、更に、店舗ＩＤ９４２は、特定の製品が販売される特定の店舗と対応することができる。最終タイムスタンプ９３３は、特定店舗での特定製品の最終販売時間とに対応することができる。一部の例示的実施形態によれば、コンピュータ９１０のソフトウェア・モジュール９５０は、製品ＩＤ９４１、店舗ＩＤ９４２、及び、最終販売タイムスタンプ９３３のそれぞれを、品目データを含むPOSデータ（例えば、入力データ９２０の全て、若しくは、その一部）として受け取ることができる。

ある実施形態において、ソフトウェア・モジュール９５０は、POSデータの受領時に、販売事象速度９４４(r_e) を決定し得る。例えば、品目データを含むPOSデータを受領後、ソフトウェア・モジュール９５０は、受領した品目データ中の製品ＩＤと店舗ＩＤを用いて、データ・オブジェクト９４０を検索取得できる（例えば、データベース、フラット・ファイル、若しくは、他のデータ源から）。取得されたデータ・オブジェクト９４０には、販売事象速度９４４に関するNULL以外の値がすでに含まれていることがある（例えば、これが、受領した品目データの製品ＩＤと店舗ＩＤに対応する製品の最初の販売でない場合）。それでも、新規販売事象速度９４４は、ソフトウェア・モジュール９５０が新しい品目データを受領する度に、指数関数型の移動平均として決定可能である。上述の様に、ソフトウェア・モジュール９５０は、以下の式により、新しい販売事象速度９４４を決定することができる。

従って、ソフトウェア・モジュール９５０が新しい品目データを受領する度に、ソフトウェア・モジュール９５０は、データ・オブジェクト９４０の販売事象速度９４４を新規に決定した販売事象速度で更新する。

一部の例示的実施形態では、ソフトウェア・モジュール９５０は、品目データを含むＰＯＳデータの受領時に、最終販売タイムスタンプ９４３ (T_{last_sale})、不明切り替え時間９４７(T_unknown)、及び、在庫切れ切り替え時間９４7 (T_out-of-stock) を決定することができる。例えば、最終販売タイムスタンプ９４３は、受領した品目データの一部であり得る（例えば、図４に関して前述のＰＯＳデータ）。この様な事例では、ソフトウェア・モジュール９５０は、品目データ中のタイムスタンプをデータ・オブジェクト９４０の最終販売タイムスタンプ９４３フィールドへコピーすることできる。別の実施形態では、ソフトウェア・モジュール９５０は、ＰＯＳデータの実際の受領時間をデータ・オブジェクト９４０の最終販売タイムスタンプ９４３フィールドに記憶することができる。新しい販売事象速度９４４を決定した後、ソフトウェア・モジュール９５０は、以下の式に従って、不明切り替え時間９４７(T_unknown)、及び、在庫切れ切り替え時間９４7 (T_out-of-stock)を決定することができる。

例えば、品目データを含むＰＯＳデータの受領後、データ・オブジェクト９４０は、以下の値を含むことができる。
product_id:45
store_id:178
sales_event_rate: 0.04 (事象/分)
last_sale:12:00pm
p₁:0.1
p₂:0.01
この例示データによれば、以下の通りとなる。

この例では、ソフトウェア・モジュール９５０は、算出されたT_unknown の値（12:25pm)とT_out-of-stock の値（12:50pm)をデータ・オブジェクト９４０の不明切り替え時間９４７と在庫切れ切り替え時間９４7フィールドへと記憶できる。従って、製品ＩＤが４５、及び、店舗ＩＤが１７８に関する新たなＰＯＳデータを受領しない場合、コンピュータ９１０のソフトウェア・モジュール９５０は、製品在庫を、午後１２時から午後１２時間２５分までは「在庫あり」とし、午後１２時間２５分から午後１２時間５０分までは「不明」とし、更に、午後１２時間５０分以降は、「在庫切れ」として見積もることが可能である。ソフトウェア・モジュール９５０は、製品在庫見積もり結果出力９３０として、この様な見積もりを提供できる。

図１０は、一部の例示的実施形態に従って、製品在庫を見積もる方法１０００を示すブロック・フロー図を示す。方法１０００は、図１と図９で説明した構成要素を参照して説明する。

ブロック１０１０では、コンピュータ９１０のソフトウェア・モジュール９５０は、ＰＯＳデータを受領するように待機することができる。一部の例示的実施形態によれば、ＰＯＳシステム１００は、ＰＯＳデータ収集器１０５を介してＰＯＳデータを収集し、品目データとして、入力データ９２０の全て、または、その一部のＰＯＳデータをコンピュータ９１０へ送る。ＰＯＳデータの受領後、ソフトウェア・モジュール９５０は、ブロック１０２０へ進み、ＰＯＳデータとして受領した製品ＩＤと店舗ＩＤに対応するデータ・オブジェクト（例えば、データ・オブジェクト９４０）を検索取得することを試行する。この様なデータ・オブジェクトが存在しなければ、ソフトウェア・モジュール９５０は、ブロック１０３０へと進み、ＰＯＳデータとして受領した製品ＩＤと店舗ＩＤに対応する新規データ・オブジェクトを作成できる。

ブロック１０３０において新規データを作成した後、ソフトウェア・モジュール９５０は、ブロック１０４０へ進んで、新規データ・オブジェクトのp₁ およびp₂ 確率フィールドを更新できる。ある実施形態では、p₁ およびp₂ の値は既定である場合もあり、これにより、新規のデータ・オブジェクトの全ては、製品に関係無く同じp₁およびp₂ で初期化される。別の実施形態では、p₁および p₂ の値は、既定であるが、製品、または、製品の範疇ごとに固有とされることもある。この後者の実施形態では、例えば、ソフトウェア・モジュール９５０が、受領した製品ＩＤにより検索を実行できるよう、コンピュータ９１０には、確率テーブル９８０が含まれても良い。更に別の実施形態では、確率p₁ および p₂ は、システム規模単位で固定される場合もあり、この場合、データオブジェクト９４０の一部としてこの様なフィールドを備える必要は無い。また、これらの確率を、前述で述べた方法で導出可能とする実施形態もある。

ソフトウェア・モジュール９５０が、既存データ・オブジェクトを検索取得するか（即ち、ブロック１０２０)、または、新規データ・オブジェクトを作成したら（即ち、ブロック１０３０、１０４０）、ブロック１０５０へと進むことができる。ブロック１０５０では、ソフトウェア・モジュール９５０は、T_{last_sale} 値を更新できる。前述の様に、ソフトウェア・モジュール９５０は、受領したＰＯＳデータ内のタイムスタンプからT_{last_sale} を直接コピーするか、または、T_{last_sale}を現在時間で更新できる。ブロック１０６０では、ソフトウェア・モジュール９５０は、上述の通りに r_e フィールド（販売事象速度）を更新できる。ブロック1070では、ソフトウェア・モジュール９５０は、上述の通りにT_unknown 、及び、T_out-of-stock フィールドを更新できる。

図１１は、例示的実施形態に従って、製品在庫を見積もるための方法１１００を示すブロック・フロー図を示す。方法１１００を、図１と図９で説明した構成要素を参照して説明する。

ブロック１１１０では、コンピュータ９１０のソフトウェア・モジュール９５０は、製品在庫見積もりの要求を受領するために待機することができる。一部の実施形態では、コンピュータ９１０は、インターネット検索エンジン／ウェブ・サーバとして構成可能である。この実施形態では、消費者は、所定製品に関してインターネット検索を実行できる。この検索によって、コンピュータ９１０は、１つ以上の店舗が、所定の販売用製品を提供することを判定できる。従って、消費者による検索によって、製品在庫見積もりの要求が始動し、ソフトウェア・モジュール９５０は、１つ以上の小売店舗で製品を購入できるかどうかを示すことができる。他の実施形態によれば、コンピュータ９１０を、独立した製品在庫見積もりシステムとして構成可能である。この実施形態によれば、製品在庫見積もりの要求は、１つ以上の入力データ９２０を介して到達できる。

ブロック１１１０において要求を受領後、ソフトウェア・モジュール９５０は、ブロック１１２０へと進んで、ブロック１１１０で受領された要求内で指定される製品ＩＤと店舗ＩＤに対応するデータ・オブジェクト（例えば、データ・オブジェクト９４０）を検索取得することを試行できる。その様なデータ・オブジェクトが存在しなければ、ソフトウェア・モジュール９５０は、ブロック１１３０へと進むことができる。一部の実施形態では、要求に対応するデータが存在しないので、ブロック１１３０において、ソフトウェア・モジュール９５０は、製品在庫見積もり結果出力９３０を「未定義」へと設定する。この場合、在庫基準検証の必要性を示すため、製品在庫見積もり結果出力９３０を、「在庫に関する確認要求」、または、「制限」に設定可能である。

ブロック１１２０において、ソフトウェア・モジュール９５０により、既存データ・オブジェクトを取得したら、ソフトウェア・モジュール９５０は、ブロック１１４０へと進むことができる。ブロック１１４０では、ソフトウェア・モジュール９５０は、現在時間と取得されたデータ・オブジェクトのT_unknown フィールドに記憶された時間とを比較し得る。現在時間が、T_unknownよりも前であれば、ソフトウェア・モジュール９５０は、ブロック１１５０へと進み、製品在庫見積もり結果出力９３０を「在庫あり」に設定する。現在時間が、T_unknownよりも後であれば、ソフトウェア・モジュール９５０は、ブロック１１６０へと進む。

ブロック１１６０では、ソフトウェア・モジュール９５０は、現在時間が、取得されたデータ・オブジェクトのT_out-of-stockフィールド中に記憶された時間より前であるかどうかを判定し得る。現在時間がT_out-of-stockフィールド中の時間より前であれば、ブロック１１７０へと進み、製品在庫見積もり結果出力９３０を「不明」に設定することが可能である。一方、現在時間がT_out-of-stockフィールド中の時間より後であれば、ソフトウェア・モジュール９５０は、ブロック１１８０へと進み、製品在庫見積もり結果出力９３０を「在庫切れ」に設定する。一部の例示的実施形態では、ソフトウェア・モジュール９５０は、「在庫あり」、及び、「在庫切れ」オプションのみでしか動作できないこともある。

一部の例示的実施形態によれば、ソフトウェア・モジュール９５０は、製品の販売速度（前述の販売事象の速度とは異なる）に基いて、所定製品の在庫を見積もることが可能である（即ち、（製品在庫見積もり結果）出力９３０を生成する）。この実施形態では、取引中の品目数を、販売事象のタイミングから独立して仮定可能である。従って、販売速度(r_s) は、以下の式によりr_e から見積もることができる。

ここで式中、<u> は、販売事象中の平均単位数である。ここで、<u>は、<t>の場合と同じ様に、以下の式の様に算出できる。

ここで式中、u_i は、販売事象i中に販売された単位数であり、ｋは、何らかの定数(0 < k < 1)である。従って、販売速度(r_s)は、指数関数型の移動平均で表記できるので、直近の事販売ほど、過去の販売よりも重みを多く有することが可能となる（即ち、過去の販売の重みは、指数関数的に減衰し得る）。

表1における例示的な販売データに従って、販売事象の絶対速度は、25/9 = 2.78 単位/販売である。この例示的な販売データを用いて、<u>₉ は、以下の様に再帰的に見積もられる。

ここでも、ｋは、０から１までの定数値が可能である。例えば、k を0.1とすると、上記方程式は、以下の様に解くことができる。

r_s = r_e * <u>であるため、例示的なデータ結果から、以下の見積もり販売速度が得られる。

従って、k を0.1とすると、例示データに関する見積もり販売速度r_s は、0.924 単位／分である。 注意すべき点として、ｋが小さいほど、過去の事象に対してより多くの重みをもたらすが、ｋが大きいほど、より直近の事象に対して重みをより多くもたらすことができる。従って、 r_eに関するｋの選択と同様、r_s に関するｋは、0.03 ≦ k ≦ 0.1の範囲で良い。

一部の例示的実施形態によれば、見積もられた販売速度(r_s)を用いて、製品の在庫を推定できる。例えば、コンピュータ９１０のソフトウェア・モジュール９５０は、所与の店舗から、製品ごと、店舗ごとに、在庫内の量(Q_feed) を示す在庫のスナップショットを受領できる。このスナップショットは、例えば、情報抽出手段５０６から提供される定期的な在庫データフィードとして、入力データ９２０上で提供可能である。

ある実施形態では、定期的な在庫データフィードは、情報抽出手段５０６によって提供可能であるので、コンピュータ９１０のソフトウェア・モジュール９５０は、在庫のスナップショットを取得してからしばらく経って、在庫データフィードを受領する。この遅延は、ある程度の確実性を持って知ることが可能であり、例えば、以下の式で表現できる。

ここで式中、T_feedは、店舗／販売業者により在庫データフィードが生成された時間であり得、T_upload は、データフィードがコンピュータ９１０のソフトウェア・モジュール９５０から利用可能となった時間であり得、δ は、δ> 0、 <δ> = 1となる確率変数であり得る。一部の実施形態では、ΔT は、例えば、定期的な在庫データフィードとして送信されるデータの一部として、店舗／販売業者によって報告可能である。代替的、または、付加的に、販売業者、または、小売販売に関する品目単位情報の他の適切な情報源も使用可能であり、その代表例として、この類の情報の第三者アグリゲータがある。一部の実施形態では、ソフトウェア・モジュール９５０は、実データからδ統計を算出できる（例えば、複数の定期的な在庫データ・フィード更新等に基づく）。別の実施形態では、ソフトウェア・モジュール９５０は、δが、全ての店舗／販売業者に共通の何らかの固定δを有する対数正規分布乱数であることを仮定する場合もある。

一部の例示的実施形態によれば、ソフトウェア・モジュール９５０は、δ≡1と仮定しており、こうすれば、以下の様に遅延計算を簡略できる。

一部の実施形態では、ソフトウェア・モジュール９５０は、連続した定期的在庫データ・フィード間の販売事象リストを記憶し、これらの記憶された販売事象からのデータ、及び、在庫データ・フィードQ_feedとともに用いて、在庫Q_uploadを計算することができ、この時点で（即ち、時間T_upload)、在庫データフィードは、コンピュータ９１０のソフトウェア・モジュール９５０へとアップロードされる。 例えば、Q_upload を以下の方程式に従って算出できる。

ここで式中、Uは、所与の販売中の品目数量である。一部の例示的実施形態によれば、ソフトウェア・モジュール９５０は、以下の擬似コードに対応する命令を用いて上記機能を実装できる。

CalculateQupload (product_id, q_feed, t_feed, sales_events) {

// product_id: q_upload が算出されるべき製品
// q_feed: スナップショットが取られた時点での在庫
// t_feed: スナップショットが取られた時間
// sales_events: 所与の店舗の全ての販売データの配列

q_upload = q_feed;
t_upload = current_time();
foreach (event in sales_events) {
if ((event.product_id == product_id) &&
(event.timestamp < t_upload) &&
(event.timestamp > t_feed)) {
q_upload = q_upload - event.quantity;
}
// ある特定の実施形態は、
// 必要とされる記憶量を減らすために、
// 例えば、t_feedより古いいかなるデータも消去することにより、
// sales_events配列からデータを削除する:
if ((event.product_id == product_id) &&
(event.timestamp < t_feed)) {
delete(event);
}
}
return q_upload;
}

一部の例示的実施形態によれば、ソフトウェア・モジュール９５０は、在庫データフィードがアップロードされる時点において、在庫Q_uploadを見積もることが可能である。例えば、ソフトウェア・モジュール９５０は、以下の方程式に従って在庫を推定できる。
Q_upload = Q_feed - (r_s * ΔT).
この推定は、現在庫Q_uploadは、在庫スナップショットを取得した時点の在庫から販売速度をΔTで乗じたものを減じた数量に近くあり得るという事実に基いている。即ち、ΔTは、スナップショットを取得した時間とデータをコンピュータ９１０のソフトウェア・モジュール９５０にアップロードした時間との時間差である(T_upload - T_feed)。

ソフトウェア・モジュール９５０は、確率を伴って周期ΔT内で販売される品目数Nを分配可能である。 例えば、確率論に従うと、以下の通りである。

ここで式中、x = r_sΔTであり、上記方程式は、以下の様に簡略化できる。

従って、ソフトウェア・モジュール９５０は、累積分布関数に従って、N単位、または、これより少ない任意の所与の製品を販売する確率を求めることができる。例えば、以下の通りである。

以下の例示データは、説明用に提供するものである。

Q_feed = 22 (即ち、在庫のスナップショット取得時の在庫量)
ΔT = 1 (即ち、アップロード１時間前にスナップショットを作成)
r_s = 10/時間 (即ち、現販売速度が毎時10品目）
Q_sold = 7 (即ち、スナップショットのアップロード後、７品目を販売）

この例示データを用いると、ソフトウェア・モジュール９５０は、
以下の様に、在庫Q_nowの現残余品目数を見積もることができる。
Q_now = Q_feed - Q_sold - (r_s * ΔT)
= 22 - 7 - (10 * 1)
= 5

従って、ソフトウェア・モジュール９５０は、Q_now = 5であると決定し、更に、製品が「在庫あり」であることを示す（（製品在庫見積もり結果）出力９３０を介して）ことが可能である。このQ_now の値は、近似値である。何故ならば、店舗が、時間ΔT内に10品目よりも多く、若しくは、これよりも少なく販売した場合があるからである。

一部の実施形態では、ソフトウェア・モジュール９５０は、付加的、若しくは、代替的に、確率を用いて製品の在庫を推定できる。上記例示データの場合、時間ΔT中に14個、若しくは、これより少ない数の商品が販売された可能性が高い場合、ソフトウェア・モジュール９５０は、製品が在庫にあると決定できる。（Q_feed-Q_sold=15であることから、最大14個の商品が時間ΔT中に販売され、（製品在庫見積もり結果）出力９３０上に「在庫あり」インジケーションが生成されたままである。これは、在庫の中に商品がもう一つ残っているであろうからである。）
前述の様に、ソフトウェア・モジュール９５０は、以下に基いて、１４個、または、これより少ない数の商品を販売する確率を決定できる。

従って、ソフトウェア・モジュール９５０は、商品が、「在庫あり」であるという確率が９１％、そして、「売り切れ」という確率が９％であると決定できる。

一部の例示的実施形態によれば、ソフトウェア・モジュール９５０は、製品在庫が、「在庫あり」、「不明」、または、「在庫切れ」であるかどうか見積もる上での確率閾値を定義できる。例えば、ソフトウェア・モジュール９５０は、在庫中に商品がある確率が０．５を超える場合は、製品在庫は、「在庫あり」であり、０．５を下回る場合には、「不明」であると見積もることができる。同様に、在庫中に商品のある確率が０．１を下回る場合、ソフトウェア・モジュール９５０は、製品在庫は、「在庫ぎれ」と見積もれる。実施形態によっては、これらの確率閾値は、すべての製品にわたって一貫である場合もある。例えば、全ての製品が、「不明」の見積もりについては０．５、そして、「在庫切れ」の見積もりについては、０．１を使用することができる。代替実施形態によれば、確率閾値が、製品ごとに一貫である場合もある。例えば、製品Ａでは、「不明」見積もりについては０．５、「在庫切れ」見積りについては０．１、そして、製品Ｂでは、「不明」見積もりについては０．３、「在庫切れ」見積りについては０．０５とすることができる。ある実施形態では、確率閾値は、比較的変動しないこともある。他の実施形態では、確率閾値は、例えば、製品見積もりシステム９００の性能のフィードバック／解析に基く調整を受けることにより、時間と共に変動する場合もある（例えば、ソフトウェア（モジュール）９５０は、許容可能な偽陽性率から確率閾値を導出できる）。

一部の例示的実施形態によれば、ソフトウェア・モジュール９５０は、製品在庫が、「在庫あり」、または、「在庫切れ」であるかどうかを見積もるための１つの確率閾値を定義できる。例えば、ソフトウェア・モジュール９５０は、在庫に商品がある確率が０．５を超える場合は、製品在庫が「在庫あり」であり、０．５を下回る場合は、「在庫切れ」であると見積もることが可能である。

図１２は、一部の例示的実施形態に従って、製品在庫を見積もるための方法１２００を示すブロックフロー図を示す。この方法１２００は、図１、９、および１３で説明した構成要素を参考として説明する。

ブロック１２１０では、コンピュータ９１０のソフトウェア・モジュール９５０は、製品在庫見積もりの要求を受領するために待機し得る。一部の実施形態では、コンピュータ９１０は、インターネット検索エンジン／ウェブサーバとして構成可能である。この実施形態では、消費者は、所定の製品についてインターネット検索を実行できる。この検索によって、コンピュータ９１０は、１つ以上の小売店舗が、特定の販売製品を提供することを判定できる。従って、消費者による検索により、製品在庫見積もりの要求が始動し、ソフトウェア・モジュール９５０は、製品が１つ以上の小売店舗で製品を購入できるかどうかを示すことができる。他の実施形態によれば、コンピュータ９１０は、独立した製品在庫見積もりシステムとして構成できる。この実施形態では、製品在庫見積もり要求は、１つ以上の入力データ９２０を介して到来可能である。

ブロック１２１０における要求の受領後、ソフトウェア・モジュール９５０は、ブロック１２２０へと進み、ブロック１２１０で受領された要求内で指定される製品ＩＤと店舗ＩＤに対応するデータ・オブジェクト（例えば、データ・オブジェクト１３００）を検索取得することを試行できる。その様なデータが存在しなければ、ソフトウェア・モジュール９５０は、ブロック１２３０へと進むことができる。一部の実施形態では、要求に対応するデータがないことから、ソフトウェア・モジュール９５０は、ブロック１２３０において、製品在庫見積もり結果出力９３０を「未定義」へと設定できる。この場合、在庫基準検証の必要性を示すため、製品在庫見積もり結果出力９３０を、「在庫に関する確認要求」、または、「制限」に設定可能である。

ソフトウェア・モジュール９５０が、ブロック１２２０において、既存のデータオブジェクトを取得したら、ソフトウェア・モジュール９５０は、ブロック１２３５へと進むことができる。ブロック１２３５では、ソフトウェア・モジュール９５０は、Q_now 及び／または、確率 Pr()の値を、上述の様に求めることができる。例示的実施形態では、この見積もりにおいて、確率Pr()のみを使用できる。別の実施形態では、Q_now を見積もりで使用して、Q_now で得られた結果を検証するため、Pr()を使用できる。ブロック１２４０では、ソフトウェア・モジュール９５０は、確率Pr() を「不明」見積もりのために設定された確率閾値とを比較できる。確率Pr() が、「不明」閾値よりも高い場合、ソフトウェア・モジュール９５０は、ブロック１２５０に進んで、製品在庫見積もり結果出力９３０を「在庫あり」に設定することができる。一方、確率Pr() が、「不明」閾値よりも低ければ、ソフトウェア・モジュール９５０は、ブロック１２６０に進むことができる。

ブロック１２６０では、ソフトウェア・モジュール９５０は、確率Pr() が「在庫切れ」閾値よりも高いかどうかを判定できる。確率Pr() が「在庫切れ」閾値よりも高ければ、ソフトウェア・モジュール９５０は、ブロック１２７０へと進んで、製品在庫見積もり結果出力９３０を「不明」に設定可能である。一方、確率Pr() が「在庫切れ」閾値よりも低ければ、ソフトウェア・モジュール９５０は、ブロック１２８０へと進んで、製品在庫見積もり結果出力９３０を「在庫切れ」に設定可能である。

図１３は、一部の例示的実施形態に基づくデータ・オブジェクト１３００のブロック図を示す。コンピュータ９１０は、データ・オブジェクト１３００を含むことができる。例えば、ソフトウェア・モジュール９５０は、データ・オブジェクト１３００をストレージ資源９７０に記憶することができる。一部の実施形態では、図９〜１２を参照して上に述べたように、ソフトウェア・モジュール９５０は、データ・オブジェクト１３００に記憶されたデータを用いて、製品在庫見積もりを提供できる。通常、コンピュータ９１０は、製品‐店舗の組ごとに、データ・オブジェクト１３００を１つ含むことができる。

販売事象速度に基いて、製品在庫を推定する間、データ・オブジェクト１３００は、以下のフィールドを含み得る：T_{last_sale} １３１０ (即ち、最終販売タイムスタンプ）、<t> １３２０ (即ち、販売事象間の移動平均時間）、及び、<u> １３３０ (即ち、販売事象ごとの 移動平均単位数)。ソフトウェア・モジュール９５０は、ＰＯＳデータ受領時に、図９を参照して述べたように、T_{last_sale} １３１０、<t> １３２０、及び、 <u>１３３０を決定できる。

販売速度に基いて製品在庫を推定する間、一部の実施形態のデータ・オブジェクト１３００は、更に、以下のフィールドを含み得る：ΔT １３４０ (即ち、T_feedとT_uploadとの間の時間）、及び、Q_sold １３５０ (時間T_uploadにおいて、在庫のスナップショットをアップロードした後で販売された商品数）。ΔT １３４０ は、店舗／販売業者によって、例えば、定期的な在庫データ・フィードとして送られるデータの一部として報告可能である。代替的、または、付加的に、レシート解析（利用者、または、企業から）によって、販売データ、及び、他の「商取引以外の」データ、例えば、第三者アグリゲータからのデータが提供されることもある。ソフトウェア・モジュール９５０は、時間T_upload の後で受領した全てのＰＯＳデータに応答して、Q_sold １３５０を決定／記憶できる。別の実施形態では、データ・オブジェクト１３００は、更に、データフィールドr_s-upload １３６０ (即ち、時間T_uploadでの r_s 値）を含むことができ、これは、Pr()の計算時に、r_s の代わりとして使用できる。一部の実施形態では、データ・オブジェクト１３００に記憶されたデータによって、ソフトウェア・モジュール９５０は、入力データ920上のＰＯＳデータを介して受領した品目データの全てを記憶する必要性なしに、製品在庫見積もりを（例えば、（製品在庫見積もり結果）出力９３０上に）提供することができる。

一部の例示的実施形態では、製品在庫は、品目販売データに基いて、決定することができる。例えば、商品が現在、「不明」、若しくは、「在庫切れ」として一覧にされていれば、特定製品の販売を含む新規販売データの受領に基き、製品在庫を、「在庫あり」に更新できる。店舗が、製品を販売中にあれば、この製品は、在庫に入れられる。この例示的な実施形態では、店舗の実際の在庫を知ることなく、製品在庫を見積もることができる。

これまでに示した実施形態において説明した例示的方法、及び、システムは、例示説明であり、代替実施形態では、本発明の範囲と精神から逸脱せずに、一部の構成要素／ステップを、異なる順序で、互いに並列して、完全に省略して、及び／または、種々の例示的方法の間で組みあわせて実行することが可能であり、更に、幾つかの追加の構成要素／ステップも実行できる。従って、この様な代替実施形態も、本明細書で述べた発明の中に含められる。

本発明は、上述の方法、及び、処理機能を実行するコンピュータ・ハードウェア、及び、ソフトウェアで使用することができる。当業者にとって明らかなように、本明細書で述べたシステム、方法、及び、手順は、プログラム可能なコンピュータ、コンピュータで実行可能なソフトウェア、または、デジタル回路として具現化できる。ソフトウェアは、コンピュータ可読媒体上に記憶できる。例えば、コンピュータ可読媒体は、フロッピー（登録商標）・ディスク、ＲＡＭ、ＲＯＭ、ハード・ディスク、リムーバブル・メディア、フラッシュ・メモリー、メモリー・ステック、光学媒体、磁気‐光学媒体、ＣＤ−ＲＯＭ等を含んでも良い。デジタル回路には、集積回路、ゲート・アレー、ビルディング・ブロック・ロジック、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等を含められる。本明細書で述べたシステムおよび方法は、機械可読媒体内に記憶された命令、及び、命令を実行するプロセッサーを含む少なくとも１つのコンピュータ・システム内で動作する１つ以上のソフトウェア・モジュールによって実現可能である。

これまでに本発明の特定の実施形態について詳細に説明してきたが、この説明は、例示説明を目的とするものにすぎない。前で説明されたものに加えて、開示されている例示的実施形態の態様の種々の変更、および対応する等価ブロックを、下記の特許請求内で定義された本発明の精神と範囲から逸脱せずに、当業者によって作成することが可能であり、特許請求の範囲は、この様な変更や等価構造を網羅するよう、最も幅広い解釈が認められるべきである。

１００ システム
１０５ ＰＯＳデータ収集器
１１０ ＰＯＳスキャナー
１１５ ＰＯＳ端末
１２０ 有線接続
１２５ 有線接続
１３０ 障害インジケータ
１３５ 接続
１４０ ネットワーク
１５０ 遠隔システム
３６０ プロセッサー
３６２ ストレージ資源
３６４ ネットワーク・モジュール
３６６ 入出力（Ｉ／Ｏ）モジュール
３６８ クロック・モジュール
３７０ ＧＰＳモジュール
３８０ ソフトウェア・モジュール
５００ システム
５０２ ローカル・コンピュータ
５０４ データベース
５０６ 情報抽出手段
５０８ 遠隔ストレージ資源
５１０ 遠隔コンピュータ
５１４ 設定ファイル
５１６ 遠隔データベース
６００ システム
６０１ 設定ダイヤログ
６０２ データベース種類メニュー
６０４ データベースホスト入力部
６０８ ＤＢ入力者名入力部
６１０ ＤＢパスワード入力部
６１２ リモートユーザ入力部
６１４ リモート・パスワード入力部
６１６ スケジュール頻度メニュー
６１８ スケジュール時間入力部
６１９ スケジュール日付メニュー
７００ システム
７０２ テーブル・マッピング・ダイヤログ
７０４ テーブル・メニュー
７０６ テーブル属性フィールド
７０８ 店舗属性フィールド
７１２ マッピング保存ボタン
７１４ 作成ボタン
７１６ 保存ボタン
７１８ クリアーボタン
７２０ テーブル・マッピング・ダイヤログ
９０１ プロセッサー
９１０ コンピュータ
９２０ 入力データ
９３０ 結果出力
９４０ データ・オブジェクト
９５０ ソフトウェア・モジュール
９７０ ストレージ資源

Claims (42)

1. 製品在庫インジケータを提供するためのコンピュータ実行方法であって、
   コンピュータ上でデータを受信するステップであって、前記データは、販売された製品を特定する第１の製品識別情報と、前記製品を販売した販売業者の場所を特定する第１の前記販売業者の場所識別情報と、並びに、前記製品を販売した第１の時間(t1)に対応するタイムスタンプとを含む、ステップと、
   前記コンピュータにより、受信した前記データに少なくとも一部基いて、前記販売業者の場所での前記製品に関する販売事象速度(r_e) を決定するステップと、
   前記コンピュータにより、第２の時間(t2)において、前記製品の問い合わせを受信するステップであって、前記第２の時間は、前記第１の時間よりも後である、ステップと、
   前記コンピュータにより、前記販売事象速度(r_e)に少なくとも基いて、前記第２の時間と前記第1の時間の差分(t2-t1)に対応する持続時間(t3)中に販売事象を観測しない確率を決定するステップと、
   前記問い合わせに応答して、前記販売業者の場所での前記製品の製品在庫表示を提供するステップと、
   を含む、方法。
2. 前記データは、前記製品を販売した前記販売業者の場所に関係付けられた装置以外の情報源からのデータを含み、前記販売業者の場所に関係付けられた前記装置以外の前記情報源は、第三者の場所、前記販売業者の本部又は前記販売業者の地域店舗に関連付けられた装置を含む、請求項１に記載の方法。
3. 前記在庫表示は、前記確率が、第１の確率閾値よりも高い時の「在庫あり」インジケータを含む、請求項１に記載の方法。
4. 前記在庫表示は、
   前記確率が、前記第１の確率閾値よりも低く、且つ、第２の確率閾値よりも高い時の「制限」インジケータであって、前記第２の確率閾値は、前記第１の確率閾値よりも低い場合を含むか、又は、
   前記確率が、前記第２の確率閾値よりも低い時の「在庫切れ」インジケータを含む、請求項３に記載の方法。
5. 前記r_eと前記タイムスタンプを、前記製品と前記前記販売業者の場所に対応するデータ・オブジェクトの中に記憶することを、更に含む、請求項１に記載の方法。
6. 前記持続時間(t3)中に販売事象を観測しない確率は、方程式exp(-r_e * t3)に従って決定される、請求項１に記載の方法。
7. 前記販売事象速度(r_e)は、指数関数型の移動平均に従って決定される、請求項１に記載の方法。
8. 前記販売事象速度(r_e)は、式1/<t>に従って決定され、<t> は、以下の式
   <t>_i = (1-k)*<t>_i-1 + k*t_iにより再帰的に決定され、
   式中、t_i は、販売事象i と 販売事象i-1間の期間であり、ｋは、範囲0< k<1内の定数である、請求項７に記載の方法。
9. k は、0.02 ≦ k ≦ 0.5の範囲にある、請求項８に記載の方法。
10. kは、0.03 ≦ k ≦ 0.1の範囲にある、請求項８に記載の方法。
11. 前記第１および第２の確率閾値は、前記前記販売業者の場所で販売される全ての製品について、一貫している、請求項１に記載の方法。
12. 前記第１および第２の確率閾値は、固定である、請求項１に記載の方法。
13. 前記第１および第２の確率閾値は、同じである、請求項１に記載の方法。
14. 製品在庫インジケータを提供するためのコンピュータ実行方法であって、
    コンピュータによって、データを受信するステップであって、前記データは、販売された製品、前記製品を販売した前記販売業者の場所、並びに、前記製品を販売した時間に対応する第１のタイムスタンプを特定する、ステップと、
    前記コンピュータによって、前記製品と前記販売業者の場所に対応するデータ・オブジェクトを検索取得するステップであって、前記データ・オブジェクトは、前記製品の販売事象間の平均時間を示す速度フィールド(<t>) と、前記在庫インジケータを「限定」へと切り替える必要のある時間を示す限定時間フィールドと、前記在庫インジケータを「在庫切れ」へと切り替える必要のある時間を示す在庫切れ時間フィールドと、前記製品の以前の販売時間に対応するタイムスタンプフィールド(T_{last_sale})とを含む、ステップと、
    前記コンピュータによって、前記第１のタイムスタンプ、前記速度フィールド、前記タイムスタンプフィールド、及び、第１の確率閾値(p₁)に少なくとも一部基いて、新規限定時間を決定するステップと、
    前記コンピュータによって、前記第１のタイムスタンプ、前記速度フィールド、前記タイムスタンプフィールド、及び、第２の確率閾値(p₂)に少なくとも基いて、新規在庫切れ時間を決定するステップと、
    前記コンピュータによって、前記限定時間フィールドを前記新規の限定時間で更新するステップと、
    前記コンピュータによって、前記在庫切れ時間フィールドを前記新規の在庫切れ時間で更新することと、前記コンピュータによって、前記データ・オブジェクトを記憶することと、更に、前記コンピュータによって、前記データ・オブジェクトに記憶されたデータに少なくとも基いて、前記製品在庫インジケータを提供するステップと、
    を含む、方法。
15. 前記販売業者の場所の前記製品の製品在庫要求を受信することを更に含み、前記製品在庫インジケータを提供するステップは、前記製品在庫要求を受信した時間を、前記限定時間フィールド、及び、前記在庫切れ時間フィールドの少なくとも一方と突き合わせて比較することを含む、請求項１４の記載の方法。
16. 前記販売業者の場所での前記製品の販売事象速度(r_e)を、r_e=1/<t>となるよう、決定することを更に含み、前記新規の限定時間は、以下の方程式
    (new_limited_time = T_{last_sale} - log(p₁)/r_e) に従って決定され、
    前記新規の在庫切れ時間は、以下の方程式
    (new_out-of-stock_time = T_{last_sale} - log(p₂)/r_e) に従って決定される、請求項１４に記載の方法。
17. 製品在庫インジケータを提供するためのコンピュータ実行方法であって、
    コンピュータによって、データを受信するステップであって、前記データは、販売された製品、前記製品を販売した販売業者の場所、並びに、前記製品を販売した時間に対応する第１のタイムスタンプを特定する、ステップと、
    前記コンピュータによって、前記製品と前記販売業者の場所に対応するデータ・オブジェクトを検索取得するステップであって、前記データ・オブジェクトは、前記製品の販売事象間の平均時間を示す速度フィールド、及び、前記製品の最終販売時間に対応するタイムスタンプ・フィールドを含む、ステップと、
    前記コンピュータによって、前記速度フィールド、前記タイムスタンプ・フィールド、及び、前記製品が販売された時間に対応する前記第１のタイムスタンプに少なくとも基づいて、販売事象間の新規の平均時間を決定する、ステップと、
    前記コンピュータによって、前記速度フィールドを前記新規の平均時間で更新するステップと、
    前記コンピュータによって、前記タイムスタンプ・フィールドを前記第１のタイムスタンプで更新するステップと、
    前記コンピュータによって、前記データ・オブジェクトを記憶するステップと、
    前記コンピュータによって、前記データ・オブジェクトに記憶されたデータに少なくとも基いて、前記製品在庫インジケータを提供するステップと、
    を含む、方法。
18. 製品在庫インジケータを提供するためのコンピュータ実行方法であって、
    コンピュータによって、データを受信するステップであって、前記データは、販売された製品、販売された前記製品の数量、前記製品を販売した販売業者の場所、並びに、前記製品を販売した時間に対応する第１のタイムスタンプを特定する、ステップと、
    前記コンピュータによって、販売された前記製品の前記数量と前記第１のタイムスタンプに少なくとも基いて、前記販売業者の場所の前記製品の販売速度(r_s)を決定するステップと、
    前記コンピュータによって、在庫スナップショットを受信するステップであって、前記在庫スナップショットは、第１の時間(T1)での前記前記販売業者の場所の前記製品の在庫量（Q)を反映し、前記在庫スナップショットの受信は、前記第１の時間より後での第２の時間(T2)において発生する、ステップと、
    前記コンピュータによって、Qより少ない数量の製品が、時間T1 から時間T2の間に販売される確率を決定するステップであって、前記確率は、前記販売速度(r_s)、前記第１の時間(T1)、及び、前記第２の時間(T2)に少なくとも基く、ステップと、
    前記コンピュータにより、前記確率に少なくとも基いて、製品在庫インジケータを提供するステップと、
    を含む、方法。
19. (ΔT=T2-T1)、 (N=Q-1)、 (x=r_sΔT)であって、Qより少ない数量の製品が時間T1 から時間T2の間に販売される前記確率は、以下の式
    

    

    に従って決定される、請求項１８に記載の方法。
20. 前記販売速度(r_s) は、指数関数型の移動平均に従って決定される、請求項１９に記載の方法。
21. 前記販売速度(r_s)は、式<u>/<t>によって決定され、<u>は、以下の式
    <u>_i = (1-j)*<u>_i-1 + j*u_iにより再帰的に決定され、
    <t> は、以下の式
    <t>_i = (1-k)*<t>_i-1 + k*t_iにより再帰的に決定され、
    式中、u_i は販売事象i中に販売された単位数、t_i は販売事象iから販売事象i-1までの期間、j は範囲0<j<1内の定数、及び、k は範囲0<k<1内の定数）である、請求項２０に記載の方法。
22. jは、範囲0.02 ≦ j ≦ 0.5内にある、請求項２１に記載の方法。
23. kは、範囲0.03 ≦ k ≦ 0.1内にある、請求項２１に記載の方法
24. j と kは、等しい、 請求項２１に記載の方法。
25. 製品在庫インジケータを提供するためのコンピュータ実行方法であって、
    コンピュータによって、データを受信するステップであって、前記データは、販売された製品、販売された前記製品の数量、前記製品を販売した販売業者の場所、並びに、前記製品を販売した時間に対応する第１のタイムスタンプを特定する、ステップと、
    前記コンピュータによって、販売された前記製品の前記数量と前記第１のタイムスタンプに少なくとも基いて、前記販売業者の場所の前記製品の販売速度(r_s)を決定するステップと、
    前記コンピュータによって、在庫スナップショットを受信するステップであって、前記在庫スナップショットは、第１の時間（Ｔ１）での前記販売業者の場所の前記製品の在庫量（Ｑ）を反映し、前記在庫スナップショットの受信は、前記第１の時間の後での第２の時間（Ｔ２）において発生する、ステップと、
    前記コンピュータによって、Ｑより少ない数量の製品が、時間Ｔ１から時間Ｔ２の間に販売される確率を決定するステップと、
    前記コンピュータによって、前記確率が第１の確率閾値よりも高い時、「在庫あり」インジケータを提供するステップと、
    前記コンピュータによって、前記確率が第２の確率閾値よりも低い時、「在庫切れ」インジケータを提供するステップと、
    を含む方法。
26. 前記第１および第２の確率閾値は、前記販売業者の場所により販売される全ての製品について、一貫している、請求項２５に記載の方法。
27. 前記第１および第２の確率閾値は、固定である、請求項２５に記載の方法。
28. 前記第１の確率閾値は、前記第２の確率閾値と同一ではない、請求項２５に記載の方法。
29. 前記第２の確率閾値は、前記第１の確率閾値よりも低く、前記方法が、前記確率が、前記第１の確率閾値よりも低く、且つ、第２の確率閾値よりも高い時、「不明」インジケータを提供するステップを、更に含む、請求項２８の記載の方法。
30. 製品在庫インジケータを提供するためのコンピュータ実行方法であって、
    コンピュータによって、データを受信するステップであって、前記データは、販売された製品、販売された前記製品の数量、前記製品を販売した販売業者の場所、並びに、前記製品を販売した第１の時間に対応する第１のタイムスタンプを特定する、ステップと、
    前記コンピュータによって、前記製品と前記販売業者の場所に対応するデータ・オブジェクトを検索取得するステップであって、前記データオブジェクトは、前記製品の販売事象中に販売された単位数の関数を示す第１の速度フィールドと、前記製品を販売した第１の時間と前記製品の以前の販売時間との間の時間の関数を示す第２の速度フィールドと、前記製品の以前の販売時間に対応するタイムスタンプ・フィールドと、数量フィールドと、前記第１の時間と前記第１の時間に続く第２の時間との間の差に対応するΔT フィールドとを含む、ステップと、
    前記コンピュータによって、前記第１の速度フィールド、及び、前記製品を販売した前記数量に少なくとも基いて、販売単位数の新規関数を決定するステップと、
    前記コンピュータによって、前記第２の速度フィールド、前記タイムスタンプ・フィールド、及び、前記第１のタイムスタンプに基いて、前記製品を販売した第１の時間と前記製品の以前の販売時間との間の時間の新規関数を決定するステップと、
    前記コンピュータによって、前記第１の速度フィールドを前記販売単位数の新規関数で更新するステップと、
    前記コンピュータによって、前記第２の速度フィールドを、前記製品を販売した第１の時間と前記製品の以前の販売の時間との間の時間の前記新規関数で更新するステップと、
    前記コンピュータによって、前記タイムスタンプ・フィールドを前記第１のタイムスタンプで更新するステップと、
    前記コンピュータによって、前記オブジェクトを記憶するステップと、
    前記コンピュータによって、前記データ・オブジェクトに記憶された前記データに少なくとも基いて、前記製品在庫インジケータを提供するステップと、
    を含む、方法。
31. 在庫スナップショットを受信することを、更に含み、前記在庫スナップショットは、第１の時間（T1)での前記販売業者の場所での前記製品の在庫量（Q)を反映し、前記在庫スナップショットの受信は、前記第１の時間より後の前記第２の時間(T2)において発生し、更に、前記数量フィールドを前記在庫量（Q)で更新することと、前記ΔTフィールドを前記（Ｔ２−Ｔ１）値で更新することとを含む、請求項３０に記載の方法。
32. 前記データ・オブジェクトは、 r_s-upload フィールドを更に含み、前記方法は、前記r_s-upload フィールドを前記第２の速度フィールドの値により前記第１の速度フィールドの値を除算した値で更新することを、更に含む、請求項３１に記載の方法。
33. 製品在庫インジケータを提供するためのコンピュータ実行方法であって、
    コンピュータによって、データを受信するステップであって、前記データは、販売された製品、販売された前記製品の数量、前記製品を販売した前記販売業者の場所、並びに、前記製品を販売した時間に対応する第１のタイムスタンプを特定する、ステップと、
    前記コンピュータによって、前記製品と前記販売業者の場所に対応するデータ・オブジェクトを検索取得するステップであって、前記データ・オブジェクトは、前記製品の販売事象中に販売された平均単位数を示す第１の速度フィールドと、前記製品の販売事象間の平均時間を示す第２の速度フィールドと、前記製品の以前の販売時間に対応するタイムスタンプ・フィールドと、数量フィールドと、第１の時間と前記第１の時間以前の第２の時間との間の差に対応するΔTフィールドとを含む、ステップと、
    前記コンピュータによって、前記データ・オブジェクトに記憶されたデータに少なくとも基いて、前記製品在庫インジケータを提供するステップと、
    を含む、方法。
34. 製品在庫見積もりシステムであって、
    ストレージ資源と、
    ネットワーク・モジュールと、
    前記ストレージ資源、及び、前記ネットワーク・モジュールと通信可能に接続するプロセッサーとを含み、
    前記プロセッサーは、前記ストレージ資源に記憶されたアプリケーション・コード命令を実行し、
    前記アプリケーション・コード命令は、前記製品在庫見積もりシステムに対して、
    前記ネットワーク・モジュールを介して、定期的な在庫スナップショットを受信するステップであって、前記在庫スナップショットは、第１の時間(T1)での前記販売業者の場所の製品の在庫量（Q)を反映し、前記在庫スナップショットの受信は、前記第１の時間より後での第２の時間(T2)において発生する、ステップと、
    前記製品と前記前記販売業者の場所に対応するデータ・オブジェクト内の前記在庫量（Q)、及び （ΔＴ＝Ｔ２−Ｔ１）値を前記ストレージ資源内に記憶するステップと、
    前記ネットワーク・モジュールを介して、実時間のデータを受信するステップであって、前記データは、前記製品、前記前記販売業者の場所、販売された前記製品の量、及び、前記製品を販売した時間に対応する第１のタイムスタンプを特定する、ステップと、
    前記ストレージ資源から、前記製品と前記販売業者の場所に対応する前記データ・オブジェクトを検索取得するステップであって、前記データ・オブジェクトは、前記製品の販売事象中に販売された単位数の関数を示す第１の速度フィールドと、前記製品の販売事象間の時間の関数を示す第２の速度フィールドと、販売時間に対応するタイムスタンプ・フィールドと、記憶された在庫量（Q)に対応する数量フィールドと、及び、記憶された前記値（ΔＴ＝Ｔ２−Ｔ１）に対応するΔＴ フィールドとを含む、ステップと、
    時間T1とT2との間にQ個よりも少ない製品が販売される確率を決定するステップと、
    前記確率に少なくとも基いて、製品在庫インジケータを提供するステップであって、前記製品在庫インジケータは、前記確率が第１の確率の閾値よりも高いときに「在庫あり」のインジケータであり、前記製品在庫インジケータは、前記確率が第２の確率の閾値よりも低いときに「在庫切れ」のインジケータである、ステップと、
    を含む、製品在庫見積もりシステム。
    
35. ネットワーク・インターフェース、及び、ストレージ資源を備えたコンピュータ・システムと共に使用されるコンピュータ・プログラムであって、
    前記コンピュータ・プログラムは、コンピュータ可読記憶媒体、及び、その内部に組み込まれたコンピュータ・プログラム命令を含み、
    前記コンピュータ・プログラム命令は、
    前記ネットワーク・インターフェースを介して、実時間のデータを受信する命令であって、前記データが、販売された製品、販売された前記製品の数量、前記製品を販売した前記販売業者の場所、並びに、前記製品を販売した時間に対応する第１のタイムスタンプを特定する、命令と、
    販売された前記製品の前記数量、及び、前記第１のタイムスタンプに少なくとも基いて、前記販売業者の場所の前記製品の販売速度(r_s)を決定する命令と、
    前記ネットワーク・インターフェースを介して、在庫スナップショットを受信する命令であって、前記在庫スナップショットは、第１の時間(T1)での前記前記販売業者の場所の前記製品の在庫量（Q)を反映し、前記在庫スナップショットの受信は、前記第１の時間より後での第２の時間(T2)において発生する、ステップと、
    Qより少ない数量の製品が、時間T1 から時間T2の間に販売される確率を決定する命令であって、前記確率は、前記販売速度(r_s)、前記第１の時間（T1),及び、前記第２の時間（T2)に少なくとも基く前記命令と、
    前記確率に少なくとも基いて、製品在庫インジケータを提供する命令であって、前記製品在庫インジケータは、前記確率が第１の確率の閾値よりも高いときに「在庫あり」のインジケータであり、前記製品在庫インジケータは、前記確率が第２の確率の閾値よりも低いときに「在庫切れ」のインジケータである、命令と、
    を含む、コンピュータ・プログラム。
36. 製品在庫見積もりシステムであって、
    ストレージ資源と、
    ネットワーク・モジュールと、
    受信したデータに基いて、販売業者の場所の製品に関する販売速度(r_s)を決定する手段と、
    数量（Q）よりも少ない製品が、第１の時間（T1）から第２の時間（T2）の間に販売される確率を決定する手段であって、前記確率が、前記販売速度(r_s)、前記第１の時間（T1）、及び、前記第２の時間（T2）に基いており、前記数量（Q)、前記第１の時間（T1）、及び、前記第２の時間（T2）は、受信した定期的な在庫スナップショットに対応する手段と、
    少なくとも前記確率に基づき製品在庫インジケータを提供する手段であって、前記製品在庫インジケータは、前記確率が第１の確率の閾値よりも高いときの「在庫あり」のインジケータであり、前記製品在庫インジケータは、前記確率が第２の確率の閾値よりも低いときの「在庫切れ」のインジケータである、手段と、
    前記ストレージ資源、及び、前記ネットワーク・モジュールと通信可能に接続するプロセッサーであって、前記ストレージ資源に記憶され、且つ、前記製品在庫システムに対して、前記確率に少なくとも基き、製品在庫インジケータを提供することを実行させるアプリケーション・コード命令を実行する、プロセッサーと、
    を含む、製品在庫見積もりシステム。
37. 前記第１の及び第２の確率の閾値は同じである
    請求項３６に記載のシステム。
38. 前記販売速度（ｒ_ｓ）は指数関数型の移動平均に従って決定される
    請求項３６に記載のシステム。
39. 前記販売速度（ｒ_ｓ）は、式<u>/<t>によって決定され、<u>は、以下の式
    <u>_i = (1-j)*<u>_i-1 + j*u_iにより再帰的に決定され、
    <t> は、以下の式
    <t>_i = (1-k)*<t>_i-1 + k*t_iにより再帰的に決定され、
    式中、u_i は販売事象i中に販売された単位数、t_i は販売事象iから販売事象i-1までの期間、j は範囲0<j<1内の定数、及び、k は範囲0<k<1内の定数）である、
    請求項３８に記載のシステム。
40. jは、範囲0.02 ≦ j ≦ 0.5内にある、
    請求項３９に記載のシステム。
41. kは、範囲0.03 ≦ k ≦ 0.1内にある、
    請求項３９に記載のシステム。
42. j と kは、等しい、
    請求項３９に記載のシステム。

Images