JP2010520556A - 予測モデルを更新するためのシステム及び方法 - Google Patents

Abstract

予測モデルを更新するための方法が開示されている。予測モデルは、パラメータを含んでおり、履歴依存データと履歴因果データを表す収集されたデータを受け取る。収集されたデータは、互いに測定単位が異なっている。収集されたデータに基づいて、予測モデルが適用され、予測モデルのパラメータに関して行われる計算から、総誤差値が求められる。予測モデルを更新するため、追加のパラメータが加えられるか、又は既定のパラメータが修正されるか、又は予測モデルからパラメータが削除され、修正総誤差値が求められる。その後、修正総誤差値は、原総誤差値と比較される。パラメータは、更に、共通の測定単位になるように正規化値に換算されるので、予測モデルを適用して総誤差値を求めることが容易になる。
【選択図】図３Ａ

Description

本出願は、２００７年３月５日出願の米国仮特許出願第６０／９０５，２１５号に対する優先権を主張し、同仮特許出願の内容を参考文献として援用する。

本発明は、概括的には、多次元データの分析に関し、より具体的には、企業データに対する統一された測定単位を使用して予想データの作成と分析を支援する、統合された企業データの動的多次元分析に関する。本発明は、更に、企業データの異なる測定単位を貨幣値に換算することに関する。

多くの会社にとって、会社が提供する製品又はサービスの財務的な将来性を予測することは望ましい。例えば、或る会社は、製品又はサービスの将来的な売上、成長率、及び利益の凡その変化を知りたいかもしれない。また、多くの会社は、予測されたデータ（例えば、売上高、成長率、及び／又は収益）に対する因果事象の動向（例えば、市場、広告、及び／又は価格設定の動向）の効果、及びこれらの動向が、提供製品又はサービスの将来性にどのように影響を及ぼすかを知りたがる。結果として、多くの会社は、予測データを予想するのに多くの因果データを網羅した予測モデルを使用している。

既存の予測モデルの入力値を修正する場合、各因果事象は、個別に修正しなければならない（例えば、テレビ視聴率の点数、ラジオ広告のスポット数、視聴者数などの引き上げ）。その上、それぞれの事象は、異なる測定単位を有している。従って、予測モデルをシミュレーションし直すには、各因果事象値の調整に多くの時間を費やさねばならい。更に、修正する際は、因果値同士の相互関係を理解していることが極めて重大である。従って、予測モデルの入力を修正する際には誤差が生じ易い。

従って、必要とされているのは、ユーザーが、予測モデルに入力される因果値の測定と修正をもっと大雑把に行えるようにした予測モデルである。

米国仮出願第６０／９０５，２１５号

予測モデルを更新するための方法を開示する。最初に、基準Ｍで作成された原予測モデルが受け取られる。予測モデルは、測定単位が互いに異なる入力を含んでいる。次いで、複数の原値が、収集されたデータに基づいて複数の入力のために受け取られ、原総計貨幣値が求められる。その後、予測モデルの入力が修正され、修正総計貨幣値が計算されることになるが、ここで修正総計貨幣値は、原総計貨幣値とＸパーセント異なっている。更に、入力される各値は、異なる測定単位から共通の測定単位へ換算され、入力用の正規化値が導き出される。

本発明は、添付図面の各図に一例として示されており、但しこれらに限定されるものではなく、また、図中、同様の符号は類似要素を表している。

実履歴依存データ対因果データの関係の１つの実施形態を示すブロック図である。 履歴因果データに基づいて計算された予想履歴依存データの関係の１つの実施形態を示すブロック図である。 履歴依存データと因果データから予想依存データを生成するためのプロセスの１つの実施形態のフロー図である。 履歴因果データから予想因果データを導き出す１つの実施形態を示すブロック図である。 予想因果データから予想依存データを導き出す１つの実施形態を示すブロック図である。 予想依存データと増分履歴依存データを比較する１つの実施形態を示すブロック図である。 予想依存データを生成する１つの実施形態を示すブロック図である。 多数の依存データと因果データの１つの実施形態を示すブロック図である。 予想依存データから分析報告を生成するためのプロセスの１つの実施形態のフロー図である。 予想依存データを生成するデータ処理システムの１つの実施形態のブロック図である。 予測モデルを更新する１つの実施形態のブロック図である。 図９の９０３の一例的方法のブロック図である。 本発明を実行するのに適した動作環境の１つの実施形態の図である。 図９の動作環境で使用するのに適した、汎用コンピュータシステムの様なデータ処理システムの１つの実施形態の図である。

本発明の実施形態の以下の詳細な説明では、添付図面を参照しているが、図中、同様の符号は類似要素を表しており、図には、本発明を実施することができる特定の実施形態を例示的に示している。これらの実施形態は、当業者が本発明を実施できるよう十分詳細に説明されているが、他の実施形態を利用してもよく、本発明の範囲から逸脱することなく、論理的、機械的、電気的、機能的、及び他の変更を加えることができるものと理解頂きたい。以下の詳細な説明は、従って、制限を課すという意味で捉えられるべきではなく、本発明の範囲は、特許請求の範囲によってのみ定義される。

予測モデル
図１Ａは、実履歴依存データ１０２と履歴因果データ１０４の関係の１つの実施形態１００を示すブロック図である。図１Ａでは、実履歴依存データ１０２のキューブは、多次元キューブに形成された時系列データを示している。１つの実施形態では、実売上高キューブ１０２の次元は、時間と製品と場所であるが、代わりの実施形態では、次元は、もっと多くても、少なくても、及び／又は異なっていてもよい。実履歴依存データ１０２は、特定の時点１０８で終了している。実履歴依存データ１０２の左手のキューブ部分は、利用できる、極めて初期の依存データを表している。

実履歴依存データ１０２のデータ予測モデルを推定するのに、アナリストは、履歴因果データ１０４を収集する。履歴因果データ１０４は、実履歴依存データ１０２に影響を及ぼす可能性のあるビジネスドライバを含んでいる。ビジネスドライバは、実履歴依存データ１０２に影響を与え得ると見込まれる活動である。ビジネスドライバの例として、限定するわけではないが、店内活動（例えば、価格、ディスプレイなど）、広告（例えば、目標視聴率、延べ視聴率、印刷チラシなど）、気象（例えば、気温、気温変化、降雨量など）、流通、競合活動（自社類似製品、並びに競合製品）などが挙げられる。通常は、因果データは、履歴依存データを予想する予測モデルにおいて利用される。更に、予測モデルは、各ビジネスドライバが依存データに影響を及ぼす場合にどれほど影響力が大きいかを、アナリストがより深く理解できるように助ける。例えば、依存データの或るセットは価格に敏感で、依存データの他のセットは季節又は気象変化に敏感である。

図１Ａの実施形態は、実履歴依存データ１０２と履歴因果データ１０４の１つの実施形態の例示である。しかしながら、実履歴依存データ１０２と履歴因果データ１０４は、いつも指定時点１０８で終わるわけではない。別の実施形態では、実履歴依存データ１０２と履歴因果データ１０４は、過去のどの様な期間に亘るものであってもよく、例えば、日単位、週単位、月単位、年単位など、様々な長さであってよい。更に、実履歴依存データ情報１０２と履歴因果データ１０４は、時間の長さが異なっていてもよいし、又は期間に重なりが見られてもよい。

図１Ｂは、因果データから導き出される予想履歴依存データ１１０の１つの実施形態１５０を示すブロック図である。予測モデル１１２は、履歴因果データ１０４から予想履歴依存データ１１０を生成するのに使用される。因果依存情報から予測モデルを作成するプロセスは、多くが当技術で知られている。更に、アナリストは、予想履歴依存データ１１０を実履歴依存データ１０４と比較することによって、予測モデル１１２の信頼性を判定することができる。アナリストは、予測モデル１１２を、結果分析のための基礎として使用し、実履歴依存データ１０２又は予想履歴依存データ１１０に影響を及ぼすビジネスドライバを確定することができる。通常、アナリストは、実履歴依存データ１１２に基づいて、過去／未来の動向及び／又は関係について推断又は推測する。しかしながら、図１Ａ−Ｂは、集計された履歴データに基づいた結果を示しているだけで、未来の結果は予想できていない。また、アナリストは、因果データに起因する依存データへの寄与度を分解する（例えば、広告、価格変動、気象変動などにより生じる売上高比率を求める）ことはできない。

図２は、履歴依存データと因果データから予想依存データを生成するプロセス２００の１つの実施形態のフロー図である。プロセスは、処理論理部によって行われ、同論理部は、ハードウェア（例えば、回路、専用論理部、プログラム可能論理部、マイクロコードなど）、ソフトウェア（例えば、汎用コンピュータシステム又は専用機械上で実行されるものなど）、又は両者の組み合わせを備えていてもよい。１つの実施形態では、プロセス２００は、図８のデータ処理システム８００によって行われる。

図２に戻ると、プロセス２００は、処理論理部によってブロック２０２で履歴依存データと因果データ（例えば、図１Ａ及び図１Ｂに示している履歴実依存データ１０２と履歴因果データ１０４）を収集することから開始される。１つの実施形態では、履歴依存データは、通常は、等価製品の売上数量の形態をしている。異なる梱包寸法で売られている特定の製品の売上を正規化するのに、等量が用いられる。例えば、ソーダ売上では、１等量は８オンス缶２４本分である。よって、１２オンスのソーダ１２缶入りの箱が２箱では１．５等量となる。ブロック２０４で、処理論理部は、予想因果データを使った予測モデルを受け取る。予測モデルは、履歴依存データと因果データを使用して推定される数学モデルである。因果情報から予測モデルを作成するのに、多くのプロセスが当技術で知られている。１つの実施形態では、予測モデルは、数式（１）、

（１）
で示され、ここに、

は、製品の需要の基準レベルを表す切片、

は、

に対する期待される依存データ応答を定量化するための係数、

は、共変量である。共変量は、下に説明している様にビジネスドライバに関係している。例えば、１つの実施形態では、或る品目の売上の単純な予測モデルは、ディスプレイ広告、特集広告（例えば、印刷広告）、価格、気象、及びテレビ広告に基づいている。この実施形態での予測モデルは、

（２）
である。処理論理部は、数式（１）又は何か他の予測モデルから、予想依存データを計算する。
先に述べた様に、それぞれの共変量（

）は、依存データに潜在的に影響を及ぼすビジネスドライバに関係している。１つの実施形態では、共変量はビジネスドライバである。代わりのやり方では、処理論理部は、ビジネスドライバを数学的に共変量に換算する。これは、通常は、ビジネスドライバの変化が依存データに線形に影響を及ぼさない場合に用いられる。例えば、売上高に及ぼす製品価格の影響は、約１．９９ドル／等量付近で大きくなるかもしれないが、価格が３．９９ドル／等量であれば、大きくならないかもしれない。この場合、処理論理部は、価格それ自体の代わりに経変量であるln（Price:価格）を使用する。上記数式（２）に表されている単純な予測モデルの例を取り上げると、処理論理部は、ここで、予測モデル、

（３）
を使用することになる。処理論理部は、ビジネスドライバの共変量への変換では、単純な数学的変換の様な多様な数学的変換を支援している。他の共変量は、時間遅延効果を有している。例えば、一期間の広告経費が、幾つかの連続する期間に亘って依存データに影響を及ぼし続けることがある。この種の効果をモデル化する場合、共変量は、初期入力値後の時間に伴って減少する減衰関数である。更に、２つ以上のビジネスドライバが、共変量に影響を及ぼすこともある。例えば、競合依存データは、製品の依存データを増減させることで依存データに影響を及ぼすことがある。

処理論理部は、当技術で知られている他の予測モデルを等しく使用することができる。例えば、１つの実施形態では、処理論理部は、米国で使用されている五大店内食料品販売促進条件に関係付けられる５つのモデルを合わせたモデル（数式（４））、

（４）
を使用しており、ここに、

は、製品が特集広告及びディスプレイ有りで売り出されたことによる売上高、

は、製品がディスプレイ有り特集広告無しで売り出されたことによる売上高、

は、製品が特集広告有りディスプレイ無しで売り出されたことによる売上高、

は、製品が一時的に値下げ（ＴＰＲ）されて売り出されたことによる売上高、

は、ディスプレイも特集広告もＴＰＲも無しで売り出されたことによる売上高である。それぞれの売上高の数式は、

（５）
の通り、固有の切片、係数、及び共変量を有しており、ここに、

，

，

，

及び

は、他の共変量の係数であり、通常は、数式（５）の５つの条件別売上高の数式で同じである（例えば、気象、価格など）。

ブロック２０６で、処理論理部は、予想因果データを使用するか又は履歴因果データを使用するかを決める。処理論理部は、履歴因果データを使用する場合、ブロック２１４で、予想履歴依存データを生成する。他方、予想因果データを使用する場合、処理論理部は、ブロック２０８で、予想因果データを作成する。予想因果データは、予想未来依存データに影響を及ぼす情報を表している。予想因果データは、通常は、店内活動、広告、気象、競合活動の様な、履歴因果データ１０４の場合と同種の情報である。１つの実施形態では、処理論理部は、履歴因果情報から予想因果データを生成する。この実施形態では、過去の同期間で店内活動、広告などに使用された同じ値が、未来の或る期間に対して用いられている。例えば、処理論理部は、或る製品の履歴因果データで２００５年３月のものと同じデータを、２００６年３月用の予想因果データとして使用している。別の実施形態では、処理論理部は、同じ履歴因果情報を予想因果情報に使用しているが、処理論理部は、履歴因果データの幾つか又は全てに変更を加えている。例えば、処理論理部は、２００４年３月と同じ履歴因果データに、全体的に３パーセント（３％）上乗せしたものを、２００６年３月の予想因果データに使用している。もう１つの例として、処理論理部は、同じ履歴因果データを使用するが、全ての市場ビジネスドライバを５パーセント（５％）削っている。更に別の例では、処理論理部は、同じ履歴因果データを使用するが、異常に暑い夏の場合を予想している。別の実施形態では、処理論理部は、市場調査員の入力から予想因果データを生成している。もう１つの実施形態では、処理論理部は、別の製品の履歴因果データから、予想因果データを生成している。もう１つの実施形態では、処理論理部は、上で説明したやり方の組合せから予想因果データを生成している。

図３Ａは、図２のブロック２０４に説明されている、履歴因果データ１０４から予想因果データ３０２を導き出すプロセス２００の１つの実施形態を示すブロック図である。図３Ａで、履歴実依存データ１０２と履歴因果データ１０４は、図１Ａ及び図１Ｂと同様に収集されている。図１Ａ及び図１Ｂと同様に、実依存データキューブ１０２の３つの次元は、時間と製品と場所である。実履歴依存データ１０２と履歴因果データ１０４は、指定時点１０８で終了しており、実履歴依存データ１０２と履歴因果データ１０４の左手は、利用可能な最も初期の依存データを表している。

時間軸３０４は、時点１０８の右手方向に進むと未来になる。予想因果データ３０２は、指定時点１０８で始まり、右手方向の未来に進んでいる。上で述べた様に、予想因果データ３０２は、履歴因果データ１０４からコピーされるか、履歴因果データ１０４から導き出されるか、何か他の製品因果データから導き出されるか、ユーザー入力から生成されるか、又はそれらの組合せから生成される。この実施形態は、予想因果データ３０４を例示することを意図しており、予想因果データ３０４がいつも現時点１０８で始まることを示唆するものではない。予想因果データ３０４の他の実施形態は、未来のどの様な期間に亘っているものであってもよく、例えば、日単位、週単位、月単位、年単位など、様々な長さであってよい。更に、実因果データ情報１０４と予想因果データ３０２は、時間の長さが異なっていてもよい。

図２に戻るが、ブロック２１０で、処理論理部は、アナリストが予想因果データを修正したか否かを判定する。修正されていた場合、ブロック２１２で、処理論理部は、予想因果データに対する市場調査員による変更を処理する。予想因果データに対する考えられる修正の例としては、限定するわけではないが、テレビ広告が以前の期間と比較して多い／少ないこと、気象がより暑く／より寒くなると見込まれること、価格の上昇／下落などが含まれる。何れの場合も、処理論理部は、ブロック２１４に進む。

ブロック２１４で、処理論理部は、予測モデルと、履歴又は予想の何れかの因果データとから予想依存データを生成する。１つの実施形態では、処理論理部は、履歴因果データを使って、予想履歴依存データを生成する。代わりのやり方では、処理論理部は、予想因果データを使って、予想未来依存データを生成する。

１つの実施形態では、処理論理部は、履歴依存データと同じ細分性を有する予想依存データを生成する。依存データ予想の一例として、説明を目的とし、処理論理部が、数式（２）の単純な予測モデルを使用した場合を想定してみよう。更に、ビジネスドライバと係数は、表１に掲載された以下の数値を取るものと仮定する。
表１．ビジネスドライバと係数の実例

処理論理部は、数式（２）の予測モデルを使って、依存データを８６．７と予想する。仮に価格を１．９９ドルまで下げた場合、予想依存データは、８７．５に上がる。これは単純な例であるが、予測モデルは、通常は、もっと複雑であり、多数のビジネスドライバと複合的な製品依存性が関与する。例えば、図６に示す下の例の様に、処理論理部は、百週間にも及ぶ長期に亘り、何百という市場の何千という製品をモデル化することもある。

図３Ｂは、図２のブロック２１２に説明されている、予測モデル３０８を使用して、予想因果データ３０２から予想依存データ３０６を導き出すプロセス２００の１つの実施形態を示すブロック図である。図３Ｂでは、履歴実依存データ１０２と履歴因果データ１０２は、図１Ａ及び図１Ｂと同様に収集されている。実依存データキューブ１０２、履歴因果データ１０４、予想因果データ３０２、及び予想依存データ３０６の３つの次元は、時間と製品と場所である。実履歴依存データ１０２と履歴因果データ１０４は、指定時点１０８で終了しており、実履歴依存データ１０２と履歴因果データ１０４の左手は、利用可能な、最も初期の依存データを表している。図３Ａの様に、予想因果データの左手は、時点１０８又は予想因果データ３０２の始点である。更に、処理論理部は、予想因果データ３０２と予測モデル３０８を使って、予想依存データ３０６を生成する。予想依存データ３０６は、予想因果データ３０２と同様に、左手の時点１０８に始まり、時間軸３０４によって未来へ進んでいく。この実施形態は、予想依存データ３０６を例示することを意図しており、予想依存データ３０６が、いつも時点１０８で始まることを示唆しているわけではない。予想依存データ３０６の他の実施形態は、未来のどの様な期間に亘っているものであってもよく、例えば、日単位、週単位、月単位、年単位など、様々な長さであってよい。更に、予想依存データ３０６と予想因果データ３０２は、時間の長さが異なっていてもよいし、又は期間に重なりが見られてもよい。

図２に戻ると、ブロック２１６で、処理論理部は、予想依存データから分析報告を導き出す。処理論理部は、予想履歴依存データ及び／又は予想未来依存データから分析報告を生成することができる。予想依存データの各セットの細分性は同じなので、処理論理部は、同種の分析報告を生成することができる。処理論理部は、通常、依存データ分解報告、「背景要因」報告、及びシナリオのシミュレーション又は最適化を生成する。これらの報告は、依存データ（例えば、収益、費用など）、依存データへの因果データの寄与度（例えば、価格、広告、気象変動などにより生じる売上高変動率）、及び／又はそれらの組合せ（広告、価格などに起因する増分収益変動）から導き出された情報を提供する。更に、処理論理部は、予想依存データから、製造者及び配給者の視点から見た、収益、費用、及びの営業利益を含む損益計算書の様な財務情報を生成する。分析報告の生成は、下の図７で更に詳しく説明する。

ブロック２１８で、処理論理部は、予測モデルの正当性を確認すべきか否かを判定する。１つの実施形態では、アナリストは、当該モデルの正当性を確認すべきことを処理論理に信号連絡するが、代わりの実施形態は、モデルの正当性を確認すべきか否かを異なる手段によって判定する（即ち、処理論理部は、モデルの正当性を確認すべきか否かを自動的に判定する、処理論理部は、モデルの正当性を確認すべきか否かをアナリストからの入力で判定する、など）。正当性を確認すべきであれば、ブロック２２０で、処理論理部は、予想履歴依存データ情報を実履歴依存データ情報と比較することによって、予測モデルの正当性を確認する。処理論理部は、２つのやり方、即ち：（ｉ）下の図４で示している様に、追加の実依存データを蓄積し、追加の履歴依存データを予想依存データと比較する、又は（ii）下の図５で示している様に、予測モデルを使って履歴依存データ情報を予想し、予想履歴依存データ情報を既存の実履歴依存データと比較する、というやり方で、実履歴依存データ情報と比較することができる。比較に使用される依存データが生成又は収集されると、処理論理部は、限定するわけではないが、分散分析、検証サンプル、モデル統計学などの様な、依存データを比較するための多くの既知の方式の１つを使って、依存データ情報の２つのセットを比較する。依存データのセットの間の類似性が高ければ、予測モデルが、依存データを正当に表現していることになる。しかしながら、依存データセット同士の相違がかなり際立っていれば、予測モデルは、変更又は更新されるべきである。

図４は、図２のブロック２１６に説明されている、予想依存データ情報３０６を蓄積された履歴依存データ情報４０８と比較するプロセス２００の１つの実施形態を示すブロック図である。図４は、図３Ｂと同様に、実履歴依存データ１０２と履歴因果データ１０４を、時点４０２で終了する時間発展キューブとして示している。更に、図４は、時点４０２で始まる予想依存データ３０６と予想因果データ３０２を示している。処理論理部は、予測モデル３０８を使用して、予想因果データ３０２から予想依存データ３０６を生成する。更に、図４は、時間が、因果データが最初に予想された時点４０２から、更新される現時点４０４まで進んでいるので、追加の増分実依存データ４０８と増分因果データ４１０が蓄積されたことを示している。更新される現時点の左手は履歴時間軸４１２であり、右手は未来時間軸４０４である。時間は進んでいるので、追加の依存データと因果データを収集することができ、それらは、増分実依存データ４０８及び増分因果データ４１０として表されている。増分実依存データ４０８は、予想依存データ３０６の同じ部分と比較され、予測モデル３０８が信頼できるか否かが判定される。

図５は、図２のブロック２１６に説明されている、予想依存データ３０６と予想履歴依存データ情報５０２を比較するプロセス２００の１つの実施形態を示すブロック図である。図５は、図３Ｂと同様に、実履歴依存データ１０２と履歴因果データ１０４を、現時点１０８で終わる時間発展キューブとして示している。更に、図５は、現時点１０８で始まる予想依存データ３０６と予想因果データ３０２を示している。また、図５は、処理論理部が予測モデル３０８を使って履歴因果データ１０４から予想履歴依存データ５０２を生成する工程を示している。予想履歴依存データ５０２が履歴因果データ１０４と同じ細分性を有することから、予想履歴依存データ５０２は、予想履歴依存データ１１０とは異なっている。処理論理部は、上のブロック２１６で詳しく説明した様に、予想履歴依存データ５０２を使用して、予測モデル３０８の正当性を確認する。

プロセス２００は、未来依存データを予想し、予想依存データに優勢的に影響を及ぼすビジネスドライバを見抜く力を得るための有力なやり方を提供している。処理論理部は、実履歴依存データ１０２と履歴因果データ１０４の最高の細分性を使用し、この細分性を予想因果データ３０２、予想依存データ３０６、及び予想履歴依存データ５０２へと伝播させてゆくので、処理論理部は、下層データによりサポートされているどの細分性レベルの分析報告でも計算することができる。よって、処理論理部は、従来のＯＬＡＰとは異なり、アナリストが、例えば、市場変数を用いて、非常に低い細分性レベルでの依存データへの影響を計算できるようにする。更に、処理論理部は、予想未来依存データに基づいて分析報告を行えるようにする。これは、依存データの未来予想が、細分性依存データのセットに関して行われ、ＯＬＡＰの様に集計された履歴データからの予想に基づいてはいないので、好都合である。更に、プロセス２００は、アナリストが、依存データ（例えば、売上高変動）及び依存データから算出されたデータ（例えば、収益変動）への寄与度を計算できるようにしている。更に、アナリストは、予想履歴及び／又は未来依存データに基づき、推断及び／又は推測することもできる。

図６は、多数の製品及び市場について予想因果及び依存データ情報を生成する１つの実施形態６００を示すブロック図である。図３から図５は、１製品１市場の場合の様々な実データ及び予想データのキューブを示している。通常、市場計画では、何週間も（多くの場合、１００週間又はそれ以上）の期間に亘って多数の市場（何百もの市場）の多数の製品（多くの場合何千もの製品）が対象になるはずである。図６は、多数の製品キューブのセット（６０８−６１８）を示している。各製品キューブセット内には、表２に掲載されている８個の別々のキューブが含まれている。
表２．図６のキューブの種類

全８種のキューブ種類を図６に示しているが、図６では、製品６０８−６１８全てについてそれぞれのキューブ種類が確認できるわけではない。１つの実施形態では、製品キューブは、ｚ方向に異なる製品６２４、ｙ方向に異なる市場６２２、ｘ方向に時間変化として編成されているが、代わりの実施形態は、製品キューブを異なる様式で編成してもよい（例えば、異なる市場変数を使用し、製品及び／又は市場の異なる階層用に多数のキューブを有するなど）。

図７は、予想依存データ情報から分析報告を生成するプロセス７００の１つの実施形態のフロー図である。プロセスは、処理論理部によって行われ、同論理部は、ハードウェア（例えば、回路、専用論理部、プログラム可能論理部、マイクロコードなど）、ソフトウェア（例えば、汎用コンピュータシステム又は専用機械上で実行されるものなど）、又は両者の組み合わせを備えていてもよい。１つの実施形態では、プロセス７００は、図８のデータ処理システム８００によって行われる。

図７に戻ると、ブロック７０２で、プロセス７００は、処理論理部が市場調査員の入力に基づいてシナリオを準備することから開始される。シナリオとは、或る特定のビジネス論題に対する仮定と予想される結論のセットである。例えば、１つの実施形態では、ビジネス論題は、「北東部で製品価格が３パーセント（％）上昇すれば、収益はどのように変化するか」というものである。処理論理部は、仮定のセット（３パーセントの価格上昇、場所は北東部の市場に限定）を受け取り、結果として生じる収益の変化を計算する。よって、シナリオのおかげで、アナリストは、依存データから算出されたデータに対する因果データの寄与度を求めることができるようになる。シナリオは、市場計画を分析する上で中心的な分析単位であり、異なる市場条件下で予期される結果を比較するのに用いられる。通常のプロセスでは、数十又は数百というシナリオが作成されることになろう。

ブロック７０４で、処理論理部は、予想依存データ情報を受け取る。処理論理部は、この情報と他の製品情報、例えば、材料原価、製造費用、流通費用など、を併せて使用して分析報告を生成する。ブロック７０６で、処理論理部は背景要因報告を計算する。背景要因報告では、或る特定のビジネスドライバに起因する依存データ量が識別される。処理論理部は、シナリオ又は或る期間を、背景要因報告の基準線として使用する。処理論理部は、マーケティングビジネスドライバを操作して、マーケティングビジネスドライバ毎の、依存データ寄与度を求める。依存データに対して線形の効果を持つビジネスドライバについては、処理論理部は、当該特定のビジネスドライバを操作して、依存データの変化を求める。非線形の効果を有していて他のビジネスドライバに依存しているビジネスドライバについては、処理論理部は、当該特定のビジネスドライバを当該依存ビジネスドライバと共に操作して、ビジネスドライバそれぞれに帰せられる依存データ寄与度を求める。

ブロック７０８で、処理論理部は、売上高分解報告を生成する。売上高分解報告は、背景要因報告と同様に、マーケティングビジネスドライバに起因する依存データの量を識別する。売上高分解報告は、背景要因報告の特別な事例である。処理論理部は、全マーケティングビジネスドライバの寄与度がゼロの既知点から開始し、マーケティングビジネスドライバを変化させて、マーケティングビジネスドライバそれぞれによる売上高寄与度を求める。よって、処理論理部は、市場活動を示していない基準線を計算する。再び図２のブロック２１２による予測モデルに関して、処理論理部は、市場活動による寄与度がゼロである（例えば、テレビ広告や印刷広告無しの）予測モデルから売上高を計算する。背景要因報告と同様に、処理論理部は、線形及び非線形の効果を勘案する。背景要因報告と売上高分解報告の両方のおかげで、アナリストは、依存データに対する因果データの寄与度を求めることができるようになる。

ブロック７１０で、処理論理部は、予想財務情報を、通常は、シナリオによる予想売上高情報を利用した損益計算書の形式で生成する。１つの実施形態では、処理論理部は、総収益、売上原価、純収益、売上総利益、払込金、営業利益、を含む損益計算書を生成する。処理論理部は、固定費（即ち、経費）、変動費（例えば、原材料、梱包など）、及びビジネスドライバ費（例えば、広告費など）による経費を計算する。処理論理部は、予想売上高情報から財務情報を作成するので、処理論理部は、利用可能な細分性の最も細かいレベルに基づいた財務情報を生成する。これにより、結果の分析に融通が効き、結果を掘り下げて、例えば、市場又は財務的寄与度をより身近に調べることができるようになる。

図８は、本発明の１つの実施形態による予想依存データを生成するデータ処理システム８００のブロック図である。データ処理システムは、限定するわけではないが、汎用コンピュータ、マルチプロセッサコンピュータ、ネットワークにより連結されている数台のコンピュータなどであってもよい。図８では、システム８００は、データ収集モジュール８０２で、実履歴依存データと履歴因果データを収集する。データ収集モジュール８０２は、局所コンピュータ、１つ又は複数の遠隔コンピュータ、又は局所コンピュータと遠隔コンピュータの組合せから、情報を収集する。図２に戻るが、この実施形態では、データ収集モジュール８０２は、ブロック２０２に含まれている機能を実行している。図８に戻って、データ収集モジュール８０２は、履歴因果情報を予想因果モジュール８０４へ転送する。

予想因果モジュール８０４は、同じ相対期間からの履歴因果データを使用し、対応する履歴因果データに変更を加え（例えば、マーケティングビジネスドライバに３パーセント加算する）、別の製品からの履歴因果データを使用し、及び／又はアナリストが情報を入力できるようにするだけで履歴因果データを処理して予想因果データを作成する。再度図１を参照すると、予想因果モジュール８０４は、ブロック２０６−２１２の機能を実行している。

図８に戻ると、予測モデルモジュール８０６は、データ収集モジュール８０２からの履歴因果データを使用して、予測モデルを生成する。上で述べた様に、予測モデルは、切片、係数、及び共変量に基づく数学モデルであり、共変量は、ビジネスドライバに関係している。再度図２を参照すると、予測モデルモジュールは、ブロック２０４の機能を実行している。

図８に戻ると、予想依存データモジュール８０８は、予測モデルモジュール８０６によって生成された予測モデル、予測因果モデル８０４からのデータ、及び／又はデータ収集モジュール８０２からのデータを使用して、予想依存データを計算する。更に、予想依存データモデル８０８は、モデル正当性確認モジュール８１０が予測モデルの正当性を確認するのに使用することのできる履歴依存データを予想することができる。再度図２を参照すると、予測モデルモジュールは、ブロック２１４の機能を実行している。

図８に戻ると、モデル正当性確認モジュール８１０は、予想履歴依存データを実履歴依存データと比較するか、又は、追加の実履歴依存データを蓄積し、それを予想依存データと比較するか、の何れかのやり方によって、予測モデルの正当性を確認する。予測モデル正当性確認８１０は、実履歴依存データ情報と予想履歴依存データの比較を行うのに、限定するわけではないが、分散分析、検証サンプル、モデル統計学などの様な、最新技術で知られている多くのプロセスを使用する。再度図２を参照すると、予測モデル正当性確認モジュール８１０は、ブロック２１８−２２０の機能を実行している。モデル正当性確認モジュールは、更に、図１０のブロック１００５の機能を実行しているが、これについては後段で説明する。

図８に戻ると、分析モジュール８１２は、背景要因報告、売上高分解、シナリオ、及び損益計算書の様な財務分析を生成することによって、予想依存データ情報から分析報告を生成する。再度図２と図７を参照すると、分析モジュール８０８は、ブロック２１６及びブロック７０２−７１０の機能を実行している。

予測モデルを更新する
図９は、予測モデルを更新するための方法のブロック図である。１つの実施形態では、予測モデル更新時の試験と正当性確認は、図８に説明されているシステムにより提供される。９０１で、日付Ｍに作成された原予測モデルが、予測モデルを更新することになっているシステム又は装置に受け取られる。先に論じた様に、１つの実施形態では、予測モデルは、係数、共変量（例えば、ビジネスドライバ）、及び切片（例えば、製品需要の基準レベル）の様な入力を含む数学モデルである。１つの例では、予測モデルは、メモリ又は記憶場所（例えば、光学記憶ディスク、磁気記憶ディスク、フラッシュメモリ）から取り出される。代わりの実施形態では、予測モデルは、システムのユーザーインターフェースを通して、ユーザーによって入力される。

９０２で、システムは、日付Ｍから次の日付Ｎまでに収集されたデータを受け取る。１つの実施形態では、収集されたデータは、予測モデルの原入力値として供されたものであり、測定単位が互いに異なるものである。収集されるデータの種類には、限定するわけではないが、日付Ｍから見て未来の因果データと依存データが含まれる。収集される因果及び依存データの種類は、先に図１Ａに関連して説明している。日付Ｍに作成された予測モデルは、９０２で収集された依存データの少なくともサブセットを分析又は予測するものである。予測モデルは、更に、時間以外の次元の一部であるデータの更新を分析又は予測する。その様な次元の例としては、限定するわけではないが、製品（例えば、データは、Coca-Cola（登録商標）の新しい飲料に関したものが受け取られたとすると、基準Ｍまでに収集／作成されたデータは、原製品に関するデータであり、基準Ｎまでに収集／作成されたデータは、Ｍのデータと新製品に関するデータを含んでいる）と、場所（例えば、データは、Coca-Cola（登録商標）が参入した新しい販売市場に関するものが受け取られたとすると、基準Ｍまでに収集／作成されたデータは、原市場に関するデータであり、基準Ｎまでに収集／作成されたデータは、Ｍのデータと新市場に関するデータを含んでいる）が挙げられる。純粋に、説明のみを目的として、図９に示されている方法を、時間の次元に関して収集されたデータに関連付けて説明する。

再度図９を参照すると、９０３で原予測モデルが更新される。予測モデルを更新する場合、９０２により収集されたデータを使用して、何らかの修正又は更新が行われた予測モデルが試験されるが、これを図１０の、方法ブロック９０３の１つの実施形態の中で説明する。

図１０は、図９による方法ブロック９０３の１つの実施形態のブロック図である。１００１で、予測モデル更新に使用するために収集されるデータの期間が指定される。例えば、図９の９０２で収集されたデータから、直近４カ月分の収集データだけが、予測モデルの更新に使用されるかもしれない。ビデオゲームの中のCoca-Cola（登録商標）の広告の具体例では、Coca-Cola（登録商標）が日付Ｎの丁度４カ月前にビデオゲームに広告を載せ始めた場合、最近４か月の収集データが、モデルの更新に使用される。代わりに、予測モデルの更新には、収集された全データを使用してもよい。期間は、ユーザーによって指定されるか、又はシステムによって決められる。更に、予測モデルの更新及び試験では、上記指定期間は必ずしも排他的ではない（例えば、更新された予測モデルを試験するか、又は更新されたモデルの信頼性の結果を確かめるのに、他のデータを使用してもよい）。

再度図１０を参照すると、予測モデルに加えることのできる、予測モデルから差し引くことのできる、又は予測モデル内で変更することのできる、少なくとも１つのパラメータが１００２で指定される。それらパラメータには、限定するわけではないが、係数、共変量、基準線／交点、及び予測モデル内に存在する他のあらゆる変数が含まれる。１つの実施形態では、（単数又は複数の）パラメータは、予測モデル又は予測モデルに加えられることになる項の係数に限定される。パラメータを加えること、予測モデルから削除すること、又は差し引くことによって、更新後の出力が、予測モデルに適用されたパラメータの修正に基づいて求められる。従って、上の数式（２）が、図９の９０１で受け取られた予測モデルである場合、パラメータは係数

である。

例を進めて、数式（２）は、日付Ｍに関して作成された予測モデルであり、Coca-Cola（登録商標）は、ビデオゲームの広告の効果を分析したいと思っているとすると、数式（２）に項

が加えられることになる。項

は、売上高に対するビデオゲームの中の広告の効果を記述している係数及び共変量である。代替的又は追加的に、

は、ビデオゲームの中の広告が従来のメディア広告の一部であると想定される場合に変更されるべき係数である。項を予測モデルに加えたりパラメータを予測モデル内で変更したりできるのとまったく同じ様に、予測モデルから項を削除することもできる。例えば、ディスプレイ広告による売上高の変化に関する効果が最小になり始めていることが明らかになった場合、当該項は、予測モデルから削除するよう指定される。

再度図１０を参照すると、識別されたパラメータそれぞれについて、１００２で、値の範囲も指定される。例えば、Coca-Cola（登録商標）が、或る特定のパラメータ係数は５０％を越えて変化するはずはないと確信している場合、変更可能であるものと識別されている係数は、最大値が現在係数値に原係数値の５０％を足すか引くかした値と等しくなる指定範囲を有する。その範囲は、ユーザーによって指定されるか、又はシステムによって決められる。代わりのやり方では、（単数又は複数の）パラメータが等しくなる値の範囲は、空いたままである。

１００３で、モデルの式と、１００２で識別されなかったパラメータの値は、原予測モデルを更新する場合のテンプレート予測モデルとして使用される。例えば、数式（２）が原予測モデルであるとして、

が、１００２で変更されるべきパラメータとして識別された場合、原モデルの更新で予測モデルを修正する時には、数式（２）で指定されている項と値は、

を除き変更無しである。

１００４では、１００２で原予測モデル内で変更するか又は原予測モデルに加えるものとして識別されたパラメータにつき、開始値が求められる。１つの実施形態では、パラメータの開始値は、原予測モデルのパラメータの既定値である。この様にして、各パラメータの初期値が決まる。予測モデルに加えるものとして識別されたパラメータでは、当該パラメータはデフォルト値に設定され、（単数又は複数の）関連項が予測モデルに加えられる（例えば、上の例では数式（２）に項

が加えられ、係数

は、ゼロの様なデフォルト値に設定される）。パラメータ値は、ユーザーが指定することもできるし、又はパラメータにとっての最適値としてシステムが最善に推定したものでもよい。

予測モデルの全てのパラメータが初期値に設定されたら、１００５で、予測モデルの総誤差が求められる。予測モデルの誤差を求める際、誤差は、予測モデルの予想出力値と観察された実際の値との差により定量化される。例えば、Coca-Cola（登録商標）の予測モデルの更新で数式（２）の誤差を求める時、日付Ｍから日付Ｎまでの或る時点における予想売上高（Volume）値Ｇを算出するために、９０２による収集データが数式（２）に挿入される。１つの実施形態では、収集されたデータは、関連付けられた費用を有しているものであって予測モデルへの入力として供されたものと解釈することができる。収集されたデータは、同時点での実際に観察された売上高（Volume）値Ｈも含んでいる。そこで、誤差は、値ＧとＨの差（即ち、予想結果と実際の結果の差）を定量化した値であると定められる。

誤差は、期間が異なると違ってくるので、総誤差を求める場合は、多数の期間に対する多数の誤差が計算されることになる。結果として、予測モデルの総誤差を定量化する目的関数が作られ、而して、予測モデル更新の際に最小化される。誤差モデルの単純な例は、数式（６）

（６）
に示され、ここに、

は、各

を別々に独立して加重するための係数、

は、日付Ｍから日付Ｎの範囲内の指定期間における予測モデルの誤差であり、ここにｉ＝１からｎまでのそれぞれの期間は、その他全ての期間と異なっている。数式（６）が総誤差を求める場合の実際の数式である場合、１００５で、数式（６）を解いて総誤差が求められる。数式（６）は、予測モデルの総誤差を計算するための、原パラメータと修正されたパラメータの総和であると解釈することができる。予測モデルの更新と同様、総誤差の目的関数も、時間以外の何れの次元に関連付けて計算してもよい。

決定ブロック１００６で、システムは、予測モデルの総誤差が許容可能か否かを判定する。誤差が指定された閾値を下回っている場合、総誤差は許容可能である。閾値は、ユーザーによって定義されるか、デフォルト値に設定されるかの何れかである。例えば、Coca-Cola（登録商標）の予測モデルを更新するシステムでユーザーが誤差の閾値レベルを０．８に設定した場合、信頼レベルが０．７８の修正予測モデルは、１００６で許容可能とされる誤差レベルを有していることになる。先の例では、閾値は、原予測モデルの総誤差に対する関係（例えば、原予測モデルの総誤差値の半分）と定義することもできる。

１００６で総誤差が許容可能であった場合、次に、システムは、１００７で、予測モデルのパラメータ値を変更する必要があるという結論に導かれることになる外部要因があるか否かを判定する。外部要因は、ユーザーが指定するか、又は、収集されたデータ又はモデルの過去の実績に照らしてシステムが決める。外部要因の例には、Coca-Cola（登録商標）の例と同様、限定するわけではないが、新しい広告キャンペーンの開始、主要スーパーマーケットチェーンの閉鎖、熱波の襲来、及び新しい競合相手の参入が挙げられる。１００７で、外部要因が存在しなければ、既定（原）モデルは更新されず、１００８では既定の予測モデルが継続して用いられる。

１００６で、予測モデルの総誤差が許容可能でなかった場合、又は１００７で、予測モデルのパラメータ値を変更する必要があると確信させる外部要因が存在する場合、１００９では、１００２で識別されたパラメータが変更され、及び／又は識別されたパラメータを備えた項が予測モデルに加えられか又は予測モデルから差し引かれる。１００９で予測モデルのパラメータ値に行われる変更は、加えられる、削除可能、及び／又は変更可能であると識別されたパラメータを変えながら総誤差の目的関数を最小化しようと試みることによって決められる。１００９のパラメータの新しい値の確定には、どの様な最適化又は統計モデル推定技法を使用してもよい。

予測モデルが修正されたら、１００１で指定されたデータを使って予測モデルの総誤差が求められる。誤差は、１００５で求めたやり方同様に、１０１０で求められる。しかしながら、１つ違うのは、誤差を求めるのに使用されるデータが異なっていることである（例えば、１００５での誤差の求め方は、全又は原データ{日付Ｍまでに収集されたデータ}を使用するのに対し、１０１０での誤差の求め方は、１００１で指定されたデータを使用している）。

１０１０で誤差が判定されたら、システムは、１０１２で、当該誤差が許容可能であるか及び減少しているか否かを判定する。誤差が許容可能であるか否かの判定は、１００６の方法と同じである。誤差が減少したことを判定するのに、システムは、修正された予測モデルの誤差が、原予測モデルの誤差よりも少ないか否か、又は、もう１つのやり方として、以前に修正された予測モデルの誤差よりも少ないか否かを判定する。１つの実施形態では、修正された予測モデルの誤差と原予測モデルの誤差の差は、百分率による差として表される。１００６では、総誤差の値が閾値より下であるか許容可能である総誤差と等しい場合に、追加的又は代替的に、システム又は装置は、パラメータ値変更の各繰り返しの間の予測モデルの総誤差の変化が、指定の変化レベルよりも下にあると判定してもよい。予測モデルの総誤差を下げようとして、予測モデルを複数回修正する（即ち、項を加えるか削除する、及び／又は、パラメータ値を何度も変更する）と、総誤差の変化は、通常、予測モデルの修正を繰り返す回数が増えるにつれて小さくなる。簡略化した例では、予測モデルが７回修正されると、７回の繰り返しの間に、総誤差は、０．２０から、０．１０、０．０８、０．０７１、０．０７０１、０．０６９９、０．０６８９６へと変化するかもしれない。総誤差は、時間経過につれて小さくなるように計算されるが、誤差の変化は繰り返しを経ている間に相当に小さくなる（例えば、０．６９９から０．６８９６になると、差は０．０００４）ので、繰り返しによって予測モデルに見られる改善は最小になる。従って、或る期間に亘って総誤差の変化が指定レベルを下回っている（例えば、総誤差の変化が無視できるほどであった）場合、修正された予測モデルの総誤差は、１０１２で、システム又は装置によって許容可能であると見なされる。上の方法は、１０１２でシステムが、誤差が減少したことを判定する場合にも使用することができる。

１０１２で、誤差が減少しており、許容可能である場合、システムは、１０１３で、新しいパラメータ値が正しい／正確か否かを判定する。多くの可能なパラメータ値は、予測モデルに実施した場合、誤りを生む。例えば、数式（２）のテレビ広告に対応する項の係数が負の値であれば、テレビ広告への出費の増加が売上高に負の効果を与えることを意味することになってしまう。テレビ広告が増えれば、売上高が増えるのは明らかである。よって、前記特定の係数については、負の係数値は、間違っている／不正確である。別の例として、価格については逆が真である。正の係数値は、価格が上昇するだけで売上高が増大することを意味しているが、通常、それは真でない。システムは、１０１３で、パラメータ値が正確であると判定されれば、修正された予測モデル（例えば、１００９による最新パラメータ値）を更新予測モデルとして使用する。

１０１２で、誤差が許容可能でなく、減少していない場合、又は１０１３で、パラメータ値が正しい／正確で無い場合は、システムは、決定ブロック１０１５において、１００２で識別されたパラメータの値に何か更なる変更を行えるか否かを判定する。例えば、１００２で１つのパラメータが識別され、当該パラメータに対して指定された範囲がシステムにパラメータを６０個の異なる値に変えることを許容している場合、システムがパラメータの値を６０回変えてしまえば、システムは、以前に分析された或る値を繰り返すこと無しに当該パラメータをもう一回変更できる機会は無くなってしまう。従って、前記例では、それ以上の値変更は存在しない。値変更をそれ以上行えないもう１つの場合を例示すると、以前の値を代入したモデルから現在の値を代入したモデルまでの誤差の変化が、小さ過ぎて測定できない場合がある。１００２で識別されたパラメータでそれ以上の値変更が使えない場合、システムは、予測モデルを更新しようとするのを中止し、従って、１００８で、既定（原）予測モデルを使い続ける。１０１５で、パラメータ値への更なる変更が使える場合、パラメータ値は、１００９で再度、変更される。

システムは、当該パラメータ値に対して更なる変更が使えるか否かを判定することの他に、モデルを更新するのに割り当てられた指定時間量が満了したか否かも判定する。時間に敏感な演算の間に予測モデルを更新する場合、会社には予測モデルを更新する時間が短時間しか無いこともある。従って、ユーザーには、システム又は装置が、予測モデルを更新しようと試みることが許される特定の時間量を設定するという選択肢がある。別の例では、モデルの更新に、予測モデルのパラメータ値の変更と総誤差を求める工程を何度も繰り返すことが含まれている。繰り返し数があまりに大きければ、予測モデルの更新に費やされる時間量は桁外れになる。従って、予測モデルの更新に時間量を割り当てておけば、モデルの更新に費やされる時間量を、操作し易いレベルに維持することができるようになる。予測モデルの更新に割り当てられた時間量が満了したら、そこで、モデルのそれ以上の修正（例えば、パラメータの値に対するそれ以上の変更）は中止され、１００８では既定予測モデルが使用される。

ブロック１００９からブロック１０１５までは、決定ブロック１０１３で肯定の応答が返されるか又は１０１５で否定の応答が返されるまで繰り返される。１つの実施形態では、ブロック１００９からブロック１０１５は、遺伝的アルゴリズムの様なメタヒューリスティクアルゴリズムを通して実施される。他の実施方法には、限定するわけではないが、他の学習アルゴリズム又は何らかの最適化技法が含まれる。１つの実施形態として、試行錯誤の実施がある。

図９と図１０に示される方法は、予測モデルを更新するための１つの方法を例示している。図９及び図１０に関連して説明したステップは全部が必要なわけではない。更に、方法は、或る特定の行為順序で説明してきたが、行為は、説明している特定の順序で実行する必要は無い。更に、予測モデルの更新では、他の行為、例えば、２つ以上の更新予測モデルが存在してもよいように、多数の修正された予測モデルを保存し、それら予測モデルを総誤差の大きさにより順位付けする工程が含まれていてもよい。システムは、予測モデルの総誤差の大きさにより予測モデルを順位付けすることにより、最適予測モデルを確定する。更に、システムは、以前に修正された何れかの予測モデルを更新予測モデルとして設定することができるようになっていてもよい。従って、システム又は装置は、後で最良の修正予測モデルを決めるために、ブロック１００９からブロック１０１５までを繰り返す毎に１つずつ、修正された予測モデルの全部を記憶してもよい。

更新予測モデルが作成されたら、図７の方法を使用して、更新モデルから分析データを抽出することができるようになる。多数の予測モデルが存在する１つの実施形態では、ユーザーは、どの予測モデルを分析に使用するかを指定する。ユーザーには、全ての予測モデルを使ってデータを分析するか又は利用可能な予測モデルのサブセットを使って分析するかを確定するという選択肢も与えられている。また、ユーザーには、特定のシナリオでは、どの予測モデルバージョンが信頼性が一番高いかを求めるという選択肢もある。１つの例では、システムは、ユーザーに、原予測モデルが更新された予測モデルに比べて総誤差の観点から見て良いか悪いかの情報を与えるだけである。また、システムは、予測モデル更新中に起こる可能性のあるパラメータ値の傾向を追跡してもよい。従って、図７に示している方法によって提供される分析に加え、多数の予測モデルの値の分析が提供されるようにしてもよい。

実際には、予測モデルは、特定の市場だけについて更新する必要があるのかもしれない。例えば、Coca-Cola（登録商標）の欧州の中だけで公開されているビデオゲームでの広告は、世界の他の場所の市場の依存データには影響を及ぼさないはずである。従って、システムは、ユーザーが、予測モデルを更新する際に、全世界的予測モデルから、例えば、バージニア州リースバーグの予測モデルまで、異なるレベルの忠実度を定義できるようにしている。上記例では、Coca-Cola（登録商標）は、欧州市場又は当該市場のサブセット（例えば、フランス又はドイツ）の予測モデルを更新することになる。

ここに述べているプロセスは、機械実行可能な命令で構築された１つ又は複数のプログラムを構成していてもよい。図９と図１０のフロー図に関連付けてプロセスを説明することで、当業者には、適切に構成された機械（ＲＡＭ（例えば、ＤＲＡＭ）、ＲＯＭ、不揮発性記憶媒体（例えば、ハードドライブ又はＣＤ−ＲＯＭ）などの様な、機械読み取り可能媒体からの命令を実行する機械のプロセッサ）上の論理ブロックによって表現される演算（行為）を実行するための命令などを含め、その様なプログラムを開発することが可能になる。機械実行可能命令は、コンピュータプログラミング言語で書いてもよいし、ファームウェア論理又はハードウェア回路で具現化してもよい。その様な命令は、認知されている標準に整合したプログラミング言語で書き込まれている場合は、各種ハードウェアプラットフォーム上及び各種オペレーティングシステムのインターフェースで実行させることができる。また、本発明を何れかの特定のプログラミング言語に関連付けて説明することはしない。ここに説明している本発明の教示の実施には、各種プログラミング言語が使用できるものと理解頂きたい。また、当技術では、ソフトウェアを、或る行為を行うか又は或る結果を生じさせる一形態又は別の形態（例えば、プログラム、手続き、プロセス、アプリケーション、モジュール、論理...）で述べるのが一般的である。その様な表現は、機械によってソフトウェアが実行されることで、機械のプロセッサに或る行為を行わせるか又は結果を生じさせることを手短に表しているに過ぎない。また、フロー図に示されているプロセスには、本発明の範囲から逸脱すること無く、それより多くの又はそれより少ないプロセスを組み込むことができ、ここに図示し説明しているブロックの配置は特定の順序を示唆するものではないものと理解頂きたい。

図１１は、インターネットの様なネットワーク１１０２を通して、一体に連結されている幾つかのコンピュータシステム１１００を示している。ここで用いている「インターネット」という用語は、ネットワークの中でも、ＴＣＰ／ＩＰプロトコルの様な或る特定のプロトコル、並びにワールドワイドウェブ（ウェブ）を構築しているハイパーテキストマークアップ言語（ＨＴＭＬ）文書のためのハイパーテキストトランスファープロトコル（ＨＴＴＰ）の様な考えられる他のプロトコルを使用したネットワークを指している。インターネットの物理的接続と、インターネットのプロトコル及び通信手続きは、当業者にはよく知られている。インターネット１１０２へのアクセスは、通常は、ＩＳＰ１１０４や１１０６などの様なインターネットサービスプロバイダ（ＩＳＰ）によって提供される。クライアントコンピュータシステム１１１２、１１１６、１１２４、及び１１２６の様なクライアントシステム上のユーザーは、ＩＳＰ１１０４及び１１０６の様なインターネットサービスプロバイダを通して、インターネットへアクセスする。インターネットへのアクセスにより、クライアントコンピュータシステムのユーザーは、情報を交換し、ｅメールを送受信し、ＨＴＭＬフォーマットで準備された文書の様な文書を閲覧することができるようになる。これらの文書は、多くの場合、インターネット「上」にあると見なされているウェブサーバ１１０８の様なウェブサーバによって提供される。多くの場合、これらのウェブサーバは、ＩＳＰ１１０４の様なＩＳＰによって提供されているが、コンピュータシステムは、当技術ではよく知られている様に、同システムがＩＳＰでなくても、セットアップしてインターネットに接続することができる。

ウェブサーバ１１０８は、通常は、サーバコンピュータシステムとして作動し、ワールドワイドウェブのプロトコルで動作するように構成されている、少なくとも１つのコンピュータシステムであり、インターネットに連結されている。随意的に、ウェブサーバ１１０８は、クライアントシステムにインターネットへのアクセスを提供するＩＳＰの一部であってもよい。ウェブサーバ１１０８は、サーバコンピュータシステム１１１０に連結されているものとして示されており、サーバコンピュータシステム１１１０自体はウェブコンテンツ１１１２に連結されており、ウェブコンテンツ１１１２は、メディアデータベースの一形態と考えることができる。図１１には２つのコンピュータシステム１１０８と１１１０が示されているが、ウェブサーバシステム１１０８とサーバコンピュータシステム１１１０は、下で詳しく説明するが、ウェブサーバ機能とサーバコンピュータシステム１１１０によって提供されるサーバ機能とを提供する異なるソフトウェア構成要素を有する１つのコンピュータシステムであってもよい。

クライアントコンピュータシステム１１１２、１１１６、１１２４、及び１１２６は、それぞれ、適切なウェブブラウジングソフトウェアを使って、ウェブサーバ１１０８によって提供されたＨＴＭＬページを閲覧することができる。ＩＳＰ１１０４は、クライアントコンピュータシステム１１１２の一部とみなすことができるモデムインターフェース１１１４を通して、クライアントコンピュータシステム１１１２へのインターネット接続を提供する。クライアントコンピュータシステムは、パーソナルコンピュータシステム、ネットワークコンピュータ、ウェブテレビシステム、ハンドヘルド型装置、又は他のその様なコンピュータシステムであってもよい。同様に、ＩＳＰ１１０６は、クライアントシステム１１１６、１１２４、及び１１２６にインターネット接続を提供するが、図１１に示している様に、接続は、これら３つのコンピュータシステムで同じではない。クライアントコンピュータシステム１１１６は、モデムインターフェース１１１８を通して連結されており、一方、クライアントコンピュータシステム１１２４及び１１２６はＬＡＮの一部である。図１１は、インターフェース１１１４及び１１１８を総称的に「モデム」として示しているが、これらインターフェースのそれぞれは、アナログモデム、ＩＳＤＮモデム、ケーブルモデム、衛星伝送インターフェース、又は、コンピュータシステムを他のコンピュータシステムに連結するための他のインターフェースであってもよいと理解頂きたい。クライアントコンピュータシステム１１２４と１１１６は、ネットワークインターフェース１１３０及び１１３２を通してＬＡＮ１１２２に連結されており、それらネットワークインターフェースは、イーサネットネットワーク又は他のネットワークインターフェースであってもよい。ＬＡＮ１１２２は、更に、ローカルエリアネットワークのためのファイアウォール及び他のインターネット関連サービスを提供することができるゲートウェイコンピュータシステム１１２０に連結されている。このゲートウェイコンピュータシステム１１２０は、ＩＳＰ１１０６に連結されて、クライアントコンピュータシステム１１２４及び１１２６へのインターネット接続を提供している。ゲートウェイコンピュータシステム１１２０は、従来のサーバコンピュータシステムであってもよい。同様に、ウェブサーバシステム１１０８も、従来のサーバコンピュータシステムであってもよい。

代わりに、周知の通り、サーバコンピュータシステム１１２８は、ネットワークインターフェース１１３４を通してＬＡＮ１１２２に直結し、ゲートウェイシステム１１２０を通してインターネットに接続する必要無しに、ファイル１１３６や他のサービスをクライアント１１２４、１１２６へ提供することもできる。更に、ＬＡＮ１１２２、インターネット１１０２、又は組合せを通信媒体として使用して、クライアントシステム１１１２、１１１６、１１２４、１１２６のあらゆる組合せを、互いにピア・ツー・ピアネットワーク式に接続してもよい。一般に、ピア・ツー・ピアネットワークは、単一又は複数の中央サーバを使用すること無く、記憶と検索ができるように、データを複数の機械のネットワークに跨って分散させる。よって、それぞれのピアネットワークノードには、上で説明したクライアントとサーバの両方の機能を組み込んでもよい。

貨幣ベースのプランニング
予測モデルは、先に説明した様に、店内活動（例えば、価格、ティスプレイなど）、広告（例えば、目標視聴率、延べ視聴率、印刷チラシなど）、気象（例えば、気温、気温変化、降雨量など）、流通、競合活動（自社類似製品、並びに競合製品）などを含む、多数のビジネスドライバを含んでいる。ビジネスドライバの内の幾つかは（例えば、店内活動及び広告に費やされる金額）は調整可能であるが、調整可能なビジネスドライバは、測定単位が同様ではない。異なるビジネスドライバの依存度（例えば、延べ視聴率対印刷配布物／チラシ）を比較し判定するために、システムは、予測モデルのビジネスドライバの測定単位を一様な測定単位に換算する。

１つの実施形態では、一様な測定単位は、通貨単位（例えば、米ドル、ユーロ、英国ポンド、日本円など）である。従って、予測モデルに入力する人は、測定単位と、特定のビジネスドライバに割り当てられている金額の単位との間の換算（例えば、印刷広告配布物を１０万部引き上げるのに必要な金額）を知る必要は無く、予測モデルへの入力の細かいレベルでの生成を避けることができる。システムは、貨幣入力を、予測モデルのビジネスドライバそれぞれの測定単位に換算する（例えば、テレビ広告に割り当てられた金額をテレビ視聴率に、又は、店内広告に割り当てられた金額を店内広告数に換算する）。

測定単位は共通の尺度単位（例えば、金額）であるので、ユーザーは、予測モデルを使って手動でシミュレートし直すために、ビジネスドライバ値を変えることもできる。ビジネスドライバ値は、ユーザーが修正した予測モデルの中の各パラメータであると解釈することもできる。１つの実施形態では、システムは、予測モデルの各ビジネスドライバに投資された金額又は投資された金額の変化比率を要求する。もう１つの実施形態では、システムは、総金額の内の現在の予測モデルの各ビジネスドライバに割り当てられた比率を記憶する。例えば、１億ドルの内の１千万ドルが、現在、テレビ広告に費やされている場合、テレビ広告は、総広告金額の１０パーセントになる。結果として、システムは、支出金額の総変化量を要求し、総広告金額の内で特定のビジネスドライバに充てる記憶されている比率値に基づいて、予測モデルの各ビジネスドライバ値を求める。例えば、経営幹部は、総金額を１億ドルから２億ドルへ増額して、予測モデルを使ってシステムをシミュレートし直すことを決定する。従って、テレビ広告が総金額の１０パーセントで、店内ディスプレイが総金額の１５パーセントであった場合、システムは、テレビ広告に充てる金額を、増加した総金額に比例させて増額し、即ち、１千万ドルから２千万ドルに増やし、店内ディスプレイに充てる金額を１千５百万ドルから３千万ドルに増やす。換算は自動化されているので、ビジネスドライバ値の全ては、ユーザーがビジネスドライバ値の全部を予測モデルに合わせて設定しなくても、変化する。システムは、次いで、予測モデルのビジネスドライバ毎の更新された貨幣値を、当該ビジネスドライバの対応する測定単位に換算する（例えば、テレビ視聴率１ポイントに１万ドル掛かっているとすると、テレビ広告は、１億ドル増額されているので、テレビ視聴率は１０００ポイント上がる）。

システムが、予測モデルを使用し、総計金額のビジネスドライバ毎の既存の比率を使ってシミュレートし直した後、何らかのビジネスドライバに費やされる金額がユーザーが入力した値と異なることもあり得るが、これは、下層の需要モデルが変数の間に相互作用を引き起こす場合があるからである。それらの値を較正し直して、ユーザーが予測モデルに入力した原値に戻すプロセスが必要になる。更新工程、例えば、限定するわけではないが最適化は、前の節の「予測モデルを更新する」で既に説明した通り、及び／又は下で説明している通りである。システムは、こうして、予測モデルの更新に更なる入力を使用するので、支出額がユーザーによって入力された額を上回ることはないはずである。

１つの実施形態では、システムは、ビジネスドライバそれぞれの比率に対し、ユーザーが入力した総額を超える／下回るドル額に比例して調整を加える（例えば、変化が０．１％であれば、印刷配布物に対して−０．１％、店内広告に対して＋０．１％）。次に、システムは、シミュレーションを通して、予測モデルにビジネスドライバ値が一様な比率で増加（又は減少）する傾向が見られるか否かを判定する。システムは、その後、ビジネスドライバ値の一様な増加（又は減少）率が実現されるまで、予測モデルを使って比率の修正とシミュレションのやり直しを継続的に繰り返す。比率の調整は、システムによって、遺伝的アルゴリズム、模擬焼きなまし法、ハードコード化反復法、ファジィ論理など、各種の更新（例えば、最適化）技法の何れの方法を通して行われてもよい。予測モデルが更新されると、システムは、新しいシミュレーションについて、ユーザーへの報告書を作成する。

予測モデル更新の１つの実施形態では、システムは、予測モデルのビジネスドライバそれぞれの増加率を一様に維持しようとする（例えば、一様な増加率

）。例えば、システムがテレビ視聴率を５０パーセント上げれば、システムは、店内ディスプレイと印刷配布物を５０パーセント上げようとする。だが、ビジネスドライバの中にはドライバ同士の間に相互依存が存在するものもある。従って、特定のビジネスドライバでは、出費の絶対増加又は減少率は非線形の効果を示すかもしれない。例えば、印刷配布物（即ち、雑誌の広告又は新聞チラシ）の増加は、店内ディスプレイの効果を高める。印刷広告が店内ディスプレイと組み合わせて行われた時、消費者は、概して、店内ディスプレイに対してより敏感に反応する（例えば、広告の製品を購入する）。必然的に、特定の製品に対する昨今の大量の広告によってそれぞれの店内ディスプレイの価格は上昇するかもしれないが、ディスプレイの度に売れる製品の量が増加しているので、もっと多くの金額を店内ディスプレイに費やすことが必要になってくる。特定の例では、１回の店内ディスプレイは、製品それぞれにつき、概して２００ドル掛かっている。店側が当該製品について昨今の印刷広告キャンペーンに注目するのであれば、店側は当該製品の店内ディスプレイ価格を各２２０ドルに上げてもよい。雑誌発行部数が５０パーセント増やされた場合は、店内ディスプレイを５０パーセント増加することにより、普段の店内ディスプレイより１０パーセント（ディスプレイ当たり２０ドル）費用が嵩むことになる。

ビジネスドライバの相互依存に加えて、ビジネスドライバの尺度（例えば、配布数）が、出費金額（例えば、配布物に費やされる金額）と線形な関係にならないこともある。例えば、広告掲載では、支出が増えることで、割引が与えられる可能性がある（例えば、１０万部では値引きは発生しないが、２０万部になれば、価格が５パーセント値引きされる）。別の例では、テレビ及びラジオ広告を展開中の会社の中には、テレビとラジオの両方で広告を購入した場合に値引きされる広告パッケージを利用する会社があるかもしれない。システムは、全ての「二次的な効果」（ビジネスドライバ間の相互依存性と、金額値とビジネスドライバ値の非線形関係）を理解し勘案する。

金額値対各ビジネスドライバ値の相互依存性及び／又は非線形の相関の結果として、システムが各ビジネスドライバに対し金額の比率を一様に増加すると、ビジネスドライバ値の増加率は、単位換算後は一様にならない。例えば、システムが、各ビジネスドライバに対し一様な比率で金額の増額を実行する場合、店内ディスプレイの増加率は、他の広告展開場所（例えば、テレビ及び印刷広告）の増加より少なくなるであろう。更に、システムが、各ビジネスドライバ入力の値を比率的に一様に上げる場合、システムは、ユーザーによって設定された量を超えて又は下回って運用されないようにするため、相互依存性と非線形的影響を勘案しなければならないだろう。

結果として、システムは、ビジネスドライバ値を一様な比率で増加（又は減少）させることができるようにするため、予測モデルの比率を更新する（及び、最適化してもよい）。１つの実施形態では、先に論じた様に、システムは、先ず、ユーザー又はプログラマーにより入力された新しい金額を、各ビジネスドライバの既存の比率に準じて割り当てる。次に、システムは、金額を、ビジネスドライバそれぞれ毎の測定単位に換算する。各ビジネスドライバの本来の測定単位に換算した後、システムは、どのビジネスドライバが一様でなく増加又は減少しているかを判定する。例えば、発行部数と店内広告費用が相互に関係している場合は、システムは、店内広告にフラグを付けることになる。システムには、ビジネスドライバ間の相互依存性（例えば、発行部数と店内広告）とあらゆる非線形関係（例えば、値引き）が分かっているので、システムは、どのビジネスドライバの比率を変更すべきか、及び、全てのビジネスドライバ値を一様な比率で増加（又は減少）させることができるようにするビジネスドライバの比率を確定する。

予測モデルを更新する時、システムは、ビジネスドライバのクラス内の関係を勘案することができる。ビジネスドライバのクラスは、種類、媒体、実行、又は何か他の形態において互いに関係があるドライバ同士のグループである。ビジネスドライバのクラスは、ユーザーに対して意味又は関係を有している。例えば、１つのクラスは、テレビ広告、印刷配布物、及びラジオ広告を含む「メディア」であってもよい。クラスの中の１つのドライバが変更されると、通常、そのクラスの全てのドライバが一斉に変更される結果になる。例えば、予測モデル更新中に、映し出されるテレビ広告が増加すれば、ラジオ広告と印刷配布物も増える。従って、システムには、クラス内のドライバの関係とクラス自体のことが分かっている。１つの実施形態では、システムには、更に、クラス同士の関係も分かっている。

図１２の以下の説明は、上で説明した本発明のプロセスを実行するのに適したコンピュータのハードウェアと他のオペレーティング要素の概観を提示することを意図しているが、適用可能な環境を限定する意図はない。当業者には即座に理解頂ける様に、本発明の実施形態は、セットトップボックス、ハンドヘルド型装置、マルチプロセッサシステム、マイクロプロセッサベースの又はプログラム可能な家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、他のコンピュータシステム構成でも実施することができる。本発明の実施形態は、ピア・ツー・ピアネットワークインフラストラクチャの様な通信ネットワークを通して結び付けられた遠隔の処理装置によってタスクが実行される分散型コンピューティング環境でも実施することができる。

図１２は、本発明の１つ又は複数の態様で使用することのできる従来のコンピュータシステムの１つの例を示している。コンピュータシステム１２００は、モデム又はネットワークインターフェース１２０２を通して、外部システムにインターフェースされている。モデム又はネットワークインターフェース１２０２は、コンピュータシステム１２００の一部と捉えることができると理解頂きたい。このインターフェース１２０２は、アナログモデム、ＩＳＤＮモデム、ケーブルモデム、トークンリングインターフェース、衛星伝送インターフェース、又は、コンピュータシステムを他のコンピュータシステムに連結するための他のインターフェースであってもよい。コンピュータシステム１２０２は、処理ユニット１２０４を含んでおり、同ユニットは、インテルのペンティアムマイクロプロセッサ又はモトローラのパワーＰＣマイクロプロセッサの様な従来のマイクロプロセッサであってもよい。メモリ１２０８は、バス１２０６でプロセッサ１２０４に連結されている。メモリ１２０８は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）であってよいし、スタティックＲＡＭ（ＳＲＡＭ）を含んでいてもよい。バス１２０６は、プロセッサ１２０４を、メモリ１２０８と、更には不揮発性記憶装置１２１４とに連結し、ディスプレイコントローラー１２１０に、そして入力／出力（Ｉ／Ｏ）コントローラー１２１６に連結している。ディスプレイコントローラー１２１０は、ディスプレイ装置１２１２上の表示を従来の方法で制御するが、このディスプレイ装置は、ブラウン管（ＣＲＴ）でも液晶ディスプレイ（ＬＣＤ）でもよい。入力／出力装置１２１８としては、キーボード、ディスクドライブ、プリンタ、スキャナ、及び、マウスや他のポインティング装置を含めた他の入力及び出力装置を挙げることができる。ディスプレイコントローラー１２１０とＩ／Ｏコントローラー１２１６は、従来の周知の技術によって実施することができる。デジタル画像入力装置１２２０は、デジタルカメラからの画像をコンピュータシステム１２００に入力できるようにするために、Ｉ／Ｏコントローラー１２１６に連結されているデジタルカメラであってもよい。不揮発性記憶装置１２１４は、多くの場合、磁気ハードティスク、光学ディスク、又は別の形態の大容量データ用記憶装置である。このデータの中には、しばしば、コンピュータシステム１２００内でソフトウェアが実行されている間に、ダイレクトメモリアクセスプロセスによってメモリ１２０８に書き込まれるものもある。当業者には即座に理解頂けるように、「コンピュータ読み取り可能媒体」及び「機械読み取り可能媒体」という用語には、プロセッサ１２０４か、又はセルラー電話又は携帯情報端末又はＭＰ３プレーヤーなどの様な他のデータ処理システムによってアクセス可能なあらゆる種類の記憶装置が含まれ、データ信号をエンコードする搬送波も対象に入る。

ネットワークコンピュータは、本発明の実施形態と共に使用することのできる別の種類のコンピュータシステムである。ネットワークコンピュータは、普通は、ハードディスク又は他の大容量記憶装置を含まず、実行可能なプログラムは、ネットワーク接続からメモリ１２０８にローディングされ、プロセッサ１２０４によって実行される。当技術で知られているウェブテレビシステムも、本発明の実施形態によるコンピュータシステムであると考えることができるが、図１２に示している機構の幾つか、例えば、或る特定の入力又は出力装置など、を欠いているかもしれない。典型的なコンピュータシステムは、普通は、少なくともプロセッサ、メモリ、及びメモリをプロセッサに連結しているバスを含んでいる。

コンピュータシステム１２００は、異なるアーキテクチャを有する多くの可能なコンピュータシステムの一例であると理解頂きたい。例えば、インテル・マイクロプロセッサをベースにしたパーソナルコンピュータは、多くの場合、多数のバスを有しており、その内の１つは、周辺機器用の入力／出力（Ｉ／Ｏ）バスであり、１つはプロセッサ１２０４とメモリ１２０８を直接接続するバス（メモリバスと呼ばれることもしばしば）である。バスは、バスプロトコルが異なることが原因で翻訳が必要となった場合に翻訳を行うブリッジ要素を通して一体に接続されている。

コンピュータシステム１２００は、オペレーティングシステムソフトウェアによって制御され、同ソフトウェアは、オペレーティングシステムソフトウェアの一部であるディスクオペレーティングシステムの様なファイル管理システムを含んでいるものと理解頂きたい。関連付けられたファイル管理システムソフトウェアを備えたオペレーティングシステムソフトウェアの一例として、ワシントン州レッドモンドのマイクロソフトから販売されているウィンドウズ・オペレーティング・システムとして知られているオペレーティングシステムと、それらに関連付けられているファイル管理システムとの一群がある。ファイル管理システムは、通常は、不揮発性記憶装置１２１４に記憶されていて、オペレーティングシステムが求める様々な行為をプロセッサ１２０４に実行させて、データが入力及び出力され、データがメモリに記憶されるようにしており、この中には、ファイルを不揮発性記憶装置１２１４に記憶させることが含まれる。

以上、本明細書の中で、本発明を、特定の代表的な実施形態に関連付けて説明した。特許請求の範囲に記載されている本発明のより広範な精神及び範囲から逸脱することなく、様々な修正を加えることができることは明白であろう。従って、本明細書と図面は、限定を課すという意味ではなく、説明を目的としているという意味に解釈されるべきである。

Claims (24)

1. 予測モデルを更新するための方法において、
   複数の入力を含んでいる原予測モデルを受け取る段階と、
   前記複数の入力に充てる複数の原入力値を受け取る段階であって、前記複数の原入力値は、測定単位が互いに異なっている、原入力値を受け取る段階と、
   前記原入力値のそれぞれに関連付けられる費用から導き出される前記複数の原入力値の総和に基づいて、原総計値を確定する段階と、
   前記原総計値に適用されるパラメータに基づいて、修正総計値を確定する段階と、
   前記複数の原入力値を、Ｘパーセントで正規化された複数の正規化値に換算して、前記複数の入力に充てる複数の修正値を算出する段階であって、前記複数の正規化値は、測定単位が同じである、正規化値を算出する段階と、から成る方法。
2. 前記修正総計値は、前記原総計値とはＸパーセント異なっており、前記複数の修正値の総和は、前記修正総計値に等しい、請求項１に記載の方法。
3. 前記複数の原入力値を受け取る段階は、前記複数の原入力値を確定するための期間を指定する段階を更に含んでいる、請求項１に記載の方法。
4. 前記修正総計値を確定する段階は、前記複数の入力に関係している少なくとも１つのパラメータについて或る範囲の値を指定する段階を更に含んでいる、請求項１に記載の方法。
5. 前記複数の原入力値を換算する段階は、前記複数の入力に充てる前記複数の正規化値の内の１つに関係しているパラメータを修正する段階を更に含んでいる、請求項１に記載の方法。
6. 前記パラメータの初期値を確定する段階を更に含んでいる、請求項５に記載の方法。
7. 前記パラメータを修正する段階は、前記修正総計値が、指定された閾値より下か否かを判定する段階に応えたものであり、前記指定された閾値は、前記原総計値との関係に基づいている、請求項５に記載の方法。
8. 前記パラメータを修正する段階は、外部要因が前記修正総計値に影響を与えたことを判定する段階に応えたものである、請求項５に記載の方法。
9. 前記複数の正規化値は、相関値の少なくとも１つのセットを含んでいる、請求項１に記載の方法。
10. 前記相関値の少なくとも１つのセットの内の少なくとも１つの正規化値を修正すると、その結果、前記相関値の少なくとも１つのセット内の残りの正規化値が自動的に更新される、請求項９に記載の方法。
11. 前記複数の修正値が一様なやり方で変更されたか否かを、各修正値との比較に基づいて判定する段階を更に含んでいる、請求項１に記載の方法。
12. 前記修正総計値を、前記原総計値と比較して順位付けし、最適予測モデルを確定する段階を更に含んでいる、請求項１に記載の方法。
13. 命令が内部に記憶されているコンピュータ読み取り可能媒体において、前記命令は、機械よって実行されると、前記機械に、
    複数の入力を含んでいる原予測モデルを受け取る段階と、
    前記複数の入力に充てる複数の原入力値を受け取る段階であって、前記複数の原入力値は、測定単位が互いに異なっている、原入力値を受け取る段階と、
    前記原入力値のそれぞれに関連付けられる費用から導き出される前記複数の原入力値の総計に基づいて、原総計値を確定する段階と、
    前記原総計値に適用されるパラメータに基づいて、修正総計値を確定する段階と、
    前記複数の原入力値を、Ｘパーセントで正規化された複数の正規化値に換算して、前記複数の入力に充てる複数の修正値を算出する段階であって、前記複数の正規化値は、測定単位が同じである、前記複数の原入力値を換算する段階と、を備えているオペレーションを実行させる、コンピュータ読み取り可能媒体。
14. 前記修正総計値は、前記原総計値とはＸパーセント異なっており、前記複数の修正値の総和は、前記修正総計値に等しい、請求項１３に記載のコンピュータ読み取り可能媒体。
15. 前記複数の原入力値を受け取る段階は、前記複数の原入力値を確定するための期間を指定する段階を更に含んでいる、請求項１３に記載のコンピュータ読み取り可能媒体。
16. 前記修正総計値を確定する段階は、前記複数の入力に関係している少なくとも１つのパラメータについて或る範囲の値を指定する段階を更に含んでいる、請求項１３に記載のコンピュータ読み取り可能媒体。
17. 前記複数の原入力値を換算する段階は、前記複数の入力に充てる前記複数の正規化値の内の１つに関係しているパラメータを修正する段階を更に含んでいる、請求項１３に記載のコンピュータ読み取り可能媒体。
18. 前記機械によって実行されると、前記機械に、
    前記パラメータの初期値を確定する段階を更に含んでいるオペレーションを実行させる、命令を更に保有している、請求項１７に記載のコンピュータ読み取り可能媒体。
19. 前記パラメータを修正する段階は、前記修正総計値が、指定された閾値より下か否かを判定する段階に応えたものであり、前記指定された閾値は、前記原総計値との関係に基づいている、請求項１７に記載のコンピュータ読み取り可能媒体。
20. 前記パラメータを修正する段階は、外部要因が前記修正総計値に影響を与えたことを判定する段階に応えたものである、請求項１７に記載のコンピュータ読み取り可能媒体。
21. 前記複数の正規化値は、相関値の少なくとも１つのセットを含んでいる、請求項１３に記載のコンピュータ読み取り可能媒体。
22. 前記相関値の少なくとも１つのセットの内の少なくとも１つの正規化値を修正すると、その結果、前記相関値の少なくとも１つのセット内の残りの正規化値が自動的に更新される、請求項２１に記載のコンピュータ読み取り可能媒体。
23. 前記機械によって実行されると、前記機械に、
    前記複数の修正値が一様なやり方で変更されたか否かを、各修正値との比較に基づいて判定する段階を更に含んでいるオペレーションを実行させる命令を更に保有している、請求項１３に記載のコンピュータ読み取り可能媒体。
24. 前記機械によって実行されると、前記機械に、
    前記修正総計値を、前記原総計値と比較して順位付けし、最適予測モデルを確定する段階を更に含んでいるオペレーションを実行させる命令を更に保有している、請求項１３に記載のコンピュータ読み取り可能媒体。

Images