特許 7539315 価格適正化システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-15

(45)【発行日】2024-08-23

(54)【発明の名称】価格適正化システム

(51)【国際特許分類】

   G06Q 10/04 20230101AFI20240816BHJP

【ＦＩ】

G06Q10/04

【請求項の数】 10

(21)【出願番号】P 2020545622

(86)(22)【出願日】2020-03-16

(65)【公表番号】

(43)【公表日】2022-05-27

(86)【国際出願番号】 US2020022937

(87)【国際公開番号】W WO2020209985

(87)【国際公開日】2020-10-15

【審査請求日】2023-03-15

(31)【優先権主張番号】16/380,185

(32)【優先日】2019-04-10

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ウー，ス－ミン

(72)【発明者】

【氏名】バフティンスキー，アンドリュー

(72)【発明者】

【氏名】ボロウジェニ，セタレー・ボルジアン

(72)【発明者】

【氏名】レディ，サントシュ・バイ

(72)【発明者】

【氏名】パンチャンガム，キラン・ブイ

(72)【発明者】

【氏名】ビジャヤン，サジート

(72)【発明者】

【氏名】ジャン，モンジェンユイ

【審査官】池田 聡史

(56)【参考文献】

【文献】米国特許出願公開第２０１７／０２００１８０（ＵＳ，Ａ１）

【文献】特開２０１９－０３２８２７（ＪＰ，Ａ）

【文献】齋藤雄太ほか１名，“不確実な製品需要量と顧客返品率を考慮したE-コマース環境下での最適運用のためのリスク分析とサプライチェーン調整”，公益社団法人 日本経営工学会２０１５年秋季大会予稿集，2015年11月28日，pp.54～55

【文献】新見勇気ほか２名，“返品取扱を考慮したＥコマース環境下での販売ネットワークシステムの構築とその最適販売方策”，社団法人日本経営工学会平成１９年度秋季研究大会予稿集，2007年10月20日，pp.106～107

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

アイテムの価格表を決定する方法であって、前記アイテムの前記価格表を決定することは、各アイテムについて、
前記アイテムの価格のセットと、前記アイテムの在庫量と、前記アイテムのセグメント当たり需要モデルと、前記セグメント当たり需要モデルの関数であって、少なくとも前記アイテムの返品の確率、前記アイテムの返品のコストおよび前記アイテムの返品までの平均時間に基づいて収益を最大化する目的関数とを受信することと、
少なくとも前記目的関数に対する各顧客セグメントの寄与予想に基づいて、複数の顧客セグメント間で前記在庫量を割り振ることと、
各顧客セグメントについて、少なくとも前記顧客セグメントに割り振られた在庫の量に基づいて、前記目的関数を最大化する前記価格表のプロモーション部分を決定することとによってなされ、前記プロモーション部分は、前記アイテムの通常シーズン中のそれぞれの期間にわたる前記価格のセットから選択された一連の価格を前記アイテムに割り当て、前記アイテムの前記価格表を決定することはさらに、各アイテムについて、
前記通常シーズンの終了時に、前記複数の顧客セグメントに割り振られた残余在庫の量を集計することと、
少なくとも前記集計された在庫に基づいて、前記目的関数を最大化する前記アイテムの前記価格表の値下げ部分を決定することとによってなされ、前記値下げ部分は、前記アイテムのクリアランスシーズン中のそれぞれの期間にわたる前記価格のセットから選択された一連の価格を割り当て、前記アイテムの前記価格表を決定することはさらに、各アイテムについて、
前記プロモーション部分と前記値下げ部分とを組み合わせて、前記アイテムの前記価格表を作成することによってなされる、方法。

【請求項2】

【数1】

【請求項3】

【数2】

【請求項4】

顧客セグメント間で前記在庫量を割り振ることは、各顧客セグメントについて、
前記在庫量の全体を前記顧客セグメントに割り振ることと、
前記在庫量の前記全体と、前記価格のセットと、近似セグメント当たり需要モデルと、制約の第１のセットと、近似目的関数とをオプティマイザに送信することと、
前記オプティマイザから、前記顧客セグメントについての前記近似目的関数のセグメント当たりの値を受信することと、
前記顧客セグメントについての全てのセグメント当たりの値の合計に対する前記セグメント当たりの値の比率を計算することと、
各顧客セグメントについて前記比率に従って前記顧客セグメント間で前記在庫量を割り振ることとを備え、
各顧客セグメントについて前記プロモーション部分を決定することは、
前記価格のセットと、前記顧客セグメントに割り振られた前記在庫量と、前記近似セグメント当たり需要モデルと、制約の第２のセットと、前記近似目的関数とを前記オプティマイザに提供することと、
前記オプティマイザから、前記目的関数を最適化する各顧客セグメントについてのプロモーション部分を受信することとを備え、
前記値下げ部分を決定することは、
前記価格のセットと、前記集計された在庫と、前記アイテムの近似集計需要モデルと、制約の第３のセットと、前記近似目的関数とを前記オプティマイザに提供することと、
前記オプティマイザから、前記目的関数を最適化する値下げ部分を受信することとを備える、請求項１から３のいずれか１項に記載の方法。

【請求項5】

前記価格のセットの線形近似に対応する線を計算することをさらに備え、前記線は、前記線を最高価格と最低価格との間のセグメントに均等に分割する位置変数の関数であり、前記位置変数の各整数値は、前記価格のセットの中のある価格に関連付けられ、
前記アイテムの前記価格のセットとして、前記線の式を前記オプティマイザに提供することと、
前記オプティマイザから、選択された価格に対応する前記位置変数の整数値を受信することと、
前記位置変数に対応する前記価格のセットの中のある価格を識別することと、
前記識別された価格を前記アイテムの前記価格表に含めることとをさらに備える、請求項４に記載の方法。

【請求項6】

各顧客セグメントについて前記プロモーション部分を決定することは、
各期間について、前記アイテムが前記価格のセットの中のそれぞれの価格に価格設定された場合の前記アイテムの顧客セグメント需要のセットを計算することと、
前記顧客セグメント需要のセットの区分線形近似に対応する複数の線を計算することと、
各価格について、前記価格における最高需要に対応する線を選択することと、
前記期間中の前記価格の前記近似セグメント当たり需要モデルとして、前記選択された線の式を前記オプティマイザに提供することとをさらに備える、請求項４に記載の方法。

【請求項7】

各顧客セグメントについて前記プロモーション部分を決定することは、
各顧客セグメントについて、前記アイテムが前記価格のセットの中のそれぞれの価格に価格設定された場合の前記アイテムの顧客セグメント需要のセットを計算することと、
各価格についてのそれぞれの顧客セグメント需要を集計することによって、それぞれの集計需要のセットを計算することと、
前記集計需要のセットの区分線形近似に対応する複数の線を計算することと、
各価格について、前記価格における最高需要に対応する線を選択することと、
前記期間中の前記価格における前記アイテムの前記近似集計需要モデルとして、前記選択された線の式を前記オプティマイザに提供することとをさらに備える、請求項４に記載の方法。

【請求項8】

アイテムの価格表を決定する方法であって、前記アイテムの前記価格表を決定することは、各アイテムについて、
前記アイテムの価格のセットと、前記アイテムの在庫量と、前記アイテムのセグメント当たり需要モデルと、前記セグメント当たり需要モデルの関数であって、少なくとも前記アイテムの返品の確率および前記返品のコストに基づいて収益を最大化する目的関数とを受信することと、
少なくとも前記目的関数に対する各顧客セグメントの寄与予想に基づいて、複数の顧客セグメント間で前記在庫量を割り振ることと、
各顧客セグメントについて、少なくとも前記顧客セグメントに割り振られた在庫の量に基づいて、前記目的関数を最大化する前記価格表のプロモーション部分を決定することとによってなされ、前記プロモーション部分は、前記アイテムの通常シーズン中のそれぞれの期間にわたる前記価格のセットから選択された一連の価格を前記アイテムに割り当て、前記アイテムの前記価格表を決定することはさらに、各アイテムについて、
前記通常シーズンの終了時に、前記複数の顧客セグメントに割り振られた残余在庫の量を集計することと、
少なくとも前記集計された在庫に基づいて、前記目的関数を最大化する前記アイテムの前記価格表の値下げ部分を決定することとによってなされ、前記値下げ部分は、前記アイテムのクリアランスシーズン中のそれぞれの期間にわたる前記価格のセットから選択された一連の価格を割り当て、前記アイテムの前記価格表を決定することはさらに、各アイテムについて、
前記プロモーション部分と前記値下げ部分とを組み合わせて、前記アイテムの前記価格表を作成することによってなされ、

【数3】

【請求項9】

アイテムの価格表を決定する価格適正化システムであって、
１つ以上のプロセッサと、
前記１つ以上のプロセッサに請求項１～８のいずれか１項に記載の方法を実施させるための命令を有するプログラムを記憶した記憶媒体と、を備える、価格適正化システム。

【請求項10】

請求項１～８のいずれか１項に記載の方法を１つ以上のプロセッサに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

分野
一実施形態は、一般に製品価格設定を決定するためのコンピュータシステムに向けられ、特に製品価格設定プロモーションおよび値下げスケジュールを決定するコンピュータシステムに向けられる。

【背景技術】

【0002】

背景情報
製品の小売業者または任意の販売人は、販売サイクル中のある時点において、おそらくプロモーションを通じて製品の価格をいつ値下げするか、およびどれぐらい値下げするかについて決断を下す必要があるだろう。価格値下げは、商品アイテムライフサイクル価格設定の重要な部分であり得る。一般的な小売業者は、アイテムのうちの２０％～５０％を値下げし（すなわち、永久的に割り引きし）、収益のうちの約３０～４０％を値下げ価格で生じさせる。

【0003】

適正化された価格値下げの判断は、在庫制約、ならびに、期間、価格および在庫の影響への需要依存性を考慮に入れることによって、収益を最大化する。適正化された値下げは、正規価格での販売期間中だけでなく値崩れ販売中でも、在庫を所望のレベルに持っていくことができ、製品ライフサイクル全体にわたって売上総利益額を最大化する。しかし、一般に、価格適正化システムは、短期的収益または短期的利益を最大化するように価格を決定しようとする。これらのシステムは、概して、後に製品が顧客によって返品されるか否かなどの販売後の要因を考慮に入れない。

【発明の概要】

【課題を解決するための手段】

【0004】

概要
実施形態では、アイテムの価格表を決定し、上記アイテムの上記価格表を決定することは、各アイテムについて、上記アイテムの価格のセットと、上記アイテムの在庫量と、上記アイテムのセグメント当たり需要モデルと、上記セグメント当たり需要モデルの関数であって、少なくとも上記アイテムの返品の確率および上記返品のコストに基づいて収益を最大化する目的関数とを受信することによってなされる。実施形態では、少なくとも上記目的関数に対する各顧客セグメントの寄与予想に基づいて、複数の顧客セグメント間で上記在庫量を割り振る。実施形態では、各顧客セグメントについて、少なくとも上記顧客セグメントに割り振られた在庫の量に基づいて、上記目的関数を最大化する上記価格表のプロモーション部分を決定し、上記プロモーション部分は、上記アイテムの通常シーズン中のそれぞれの期間にわたる上記価格のセットから選択された一連の価格を上記アイテムに割り当てる。実施形態では、上記通常シーズンの終了時に、上記複数の顧客セグメントに割り振られた残余在庫の量を集計する。実施形態では、少なくとも上記集計された在庫に基づいて、上記目的関数を最大化する上記アイテムの上記価格表の値下げ部分を決定し、上記値下げ部分は、上記アイテムのクリアランスシーズン中のそれぞれの期間にわたる上記価格のセットから選択された一連の価格を割り当て、上記プロモーション部分と上記値下げ部分とを組み合わせて、上記アイテムの価格表を作成する。

【図面の簡単な説明】

【0005】

【図1】一実施形態に係る、アイテムのセットの価格表を生成するコンピュータ化されたシステムを示す図である。

【図2A】一実施形態に係る、アイテムのセットの価格表を生成するコンピュータ化されたシステムを示す図である。

【図2B】一実施形態に係る、アイテムの価格のセットを近似するために使用される価格線制約を価格ロジックがどのように生成するかを示す図である。

【図2C】一実施形態に係る、オプティマイザに提供されるセグメント当たり需要モデルの線形近似である需要ピース制約を需要ロジックがどのように決定するかを示す図である。

【図3A】実施形態に係るロジスティック関数をグラフで示す図である。

【図3B】実施形態に係るロジスティック関数をその近似値とともにグラフで示す図である。

【図4】一実施形態に係る、各アイテムの返品の確率を考慮に入れた、アイテム群の各アイテムのプロモーションおよび値下げ価格表を決定する際の図１の価格表ロジックの機能のフロー図である。

【図5】本発明の実施形態に係るコンピュータサーバ／システムのブロック図である。

【発明を実施するための形態】

【0006】

詳細な説明
一実施形態は、後に顧客が製品を返品する確率を考慮に入れることによって価格設定を決定する価格適正化システムである。したがって、適正化された価格設定は、他の要因に加えて、返品の確率も最小限に抑え、長期的利益を増加させる。実施形態では、価格上昇に起因するであろう返品の確率の上昇のために価格の上昇による収益の増加を犠牲にすることによって、この確率を考慮に入れる。返品の確率の上昇は、本来の売上げに関連付けられた収益を失うことを意味するだけでなく、返品を処理するコストを負担することも意味する。

【0007】

上記のように、小売業者のための公知の価格適正化システムは、一般に、価格を調整して、小売業者の収益または利益を最大化する価格で顧客に購入させるプロモーションを行うことに重点を置く。単に特定の製品／アイテムを販売することに重点が置かれ、顧客がアイテムを返品するか否かについては考えない。たとえば、顧客に請求する価格を高くすることにより、顧客が商品を返品する可能性を高めることを犠牲にして、短期的な収益が向上するであろう。小売業者は、返品を処理するコストを負担することになり、公知の価格適正化システムは、この起こり得るコストを考慮に入れておらず、目先の収益または利益を増加させるように価格を設定するのみである。

【0008】

オンライン小売業者の中には、顧客が商品を返品しないことに同意した場合に割り引きを提供することによって返品のコストを削減しようとしてきた業者もある。しかし、大半の小売業者は、特に店舗内購入の場合、価格設定を通じて返品に影響を及ぼすことを試みてこなかった。

【0009】

一般に、小売業者は、そもそも返品を減らそうとするのではなく、返品の処理を効率化しようとしてきた。たとえば、小売業者は、返品された商品を、返品が受け取られた店舗よりもよく売れそうな別の店舗に転送しようとしたり、返品された商品を迅速に処分するために、単に返品された商品の価格を非常に低くしたりしてきたかもしれない。このように、小売業者は、顧客が商品を返品するか否かを制御することは不可能であることを単純に認めて、その代わりにできる限り効率的に返品を処理することに重点を置いていた。同様に、公知の価格適正化システムは、返品された商品を在庫に追加して、次いで増加した在庫を最良の価格で販売することに重点を置いてきた。これは、返品による在庫の増加を全く考慮に入れないよりは確実によいが、そもそも返品を減らすことほど有益ではない。

【0010】

最大化を使用して単に顧客に購入させるように価格を適正化する公知のシステムとは対照的に、本発明の実施形態では、顧客が商品を返品する確率を減少させるために、この最大化を顧客への割り引きの提供と組み合わせる。割り引きは、支払われる価格を含むいくつかの要因を顧客が商品を返品する確率に関係付ける顧客行動のモデルに基づく。実施形態では、この割り引きの提供と起こり得る収益または利益の減少とのバランスをとって、収益または利益の減少を価値あるものにするのに十分に確率を減少させる価格を選択する。確率を十分に減少させると、返品の処理に関連付けられた小売業者のコストも減少し、これは、収益または利益の減少を埋め合わせることができる。

【0011】

実施形態では、割り引きは、レジで（または、オンライン精算時に）その場で、またはキャッシュバックとして、またはクレジットカードポイントと同様の、顧客が後に使用できる「ポイント」として、顧客に提供されることができる。

【0012】

実施形態では、商品に対して支払われる価格を含むいくつかの要因を返品の確率に関係付ける顧客行動のモデルを使用する。たとえば、他の要因としては、商品のタイプおよび商品が購入された時期および顧客（または、他の顧客）がこのタイプの商品に対して行った返品の数が挙げられる。実施形態では、小売業者の販売および返品の取引履歴を介して反復処理を実行して、返品確率に対するこれらの要因の各々の影響を判断する。次いで、価格適正化は、このモデルを利用することによって適正化中に返品の確率を予測し、それに従って価格を調整する。

【0013】

また、実施形態に係るモデルは、小売業者が顧客セグメントを有する場合には顧客の顧客セグメントも考慮に入れることができる。これは、モデルの精度を向上させることができる。なぜなら、さまざまな顧客セグメントはさまざまな返品行動を有し得るからである。

【0014】

実施形態では、割り引きは、以下の２つの方法のうちの１つの方法で顧客に提供されることができる。２つの方法とは、（１）たとえばポイントカードを介して、または購入がオンラインであって顧客がログインしたという理由で、顧客を識別できる場合には、割り引きは、顧客が属する顧客セグメントに合わせられ、（２）たとえば顧客がレジにいて小売業者のポイントプログラムの一部ではないという理由で顧客を識別できない場合には、顧客をセグメントのうちのいずれかからランダムに選択されたものとして扱うことによって割り引きを決定することができる。

【0015】

上記に開示されているように、特にアパレルなどの短いライフサイクルの商品を有する小売業者は、プロモーションおよび値下げを使用して、販売システムの終了時までに商品を一掃するように在庫を動かして利益を最大化する。プロモーションおよび値下げをいつにするか、および、プロモーションおよび値下げ中にどの価格を商品に割り当てるべきかを判断することは、小売業者にとって難しい問題である。また、小売業者は、多くの場合、プロモーション価格を同時に割り当てることができるアイテムの最大数などのビジネスルールを有しており、これは、各アイテムの価格表を制約する。さらに、さまざまな顧客セグメント（たとえば、独身者、若い人、親、退職者など）は、プロモーションおよび値下げに対してさまざまに反応し、これは、価格スケジューリングプロセスに取り込まれるべき事実である。多くの小売業者がシーズンごとに何百もの異なるアイテムを有することを考えると、小売業者によって販売されるアイテムの価格表を設定するためのコンピュータ化されたアプローチでさえ実現不可能であり得ることが分かる。

【0016】

実施形態では、各アイテムの返品の確率を考慮に入れる効率的な態様で多数のアイテムのコンピュータ化されたプロモーションおよび値下げスケジューリングを提供する。さまざまな顧客セグメントのために異なるプロモーションスケジュールが作成されて、さまざまなタイプの顧客の購買習慣についての知識を活用して、利益を最大化する。スケジュールのプロモーション部分（すなわち、通常シーズン）およびスケジュールの値下げ部分（すなわち、クリアランスシーズン）は、両方とも、実施形態によって同時に計算され、これにより、小売業者は、さまざまなプロモーションおよび値下げアプローチを検討することができる。

【0017】

図１は、一実施形態に係る、アイテムのセットの価格表を生成するコンピュータ化されたシステム１００を示す。価格表は、たとえば本明細書に記載されているデータ値および／または情報の記録を含むメモリに格納されたデータ構造である。システム１００は、以下に開示されているさまざまな動作を実行するようにプロセッサを制御する価格表ロジック１１０を含む。一実施形態では、価格表ロジック１１０は、非一時的なコンピュータ記憶媒体に格納された、モジュールで具体化されるコンピュータ命令として実現され、命令は、少なくともコンピューティングデバイスのプロセッサによって実行されると本明細書に記載されている機能を実行するように構成された実行可能なアルゴリズムとして構成される。

【0018】

価格表ロジック１１０は、ネットワークを介した電子通信またはインターネット接続によって、小売業者のコンピューティングデバイスと対話する。「小売業者」または「要求元デバイス」という表現は、販売されるアイテムの価格設定を行い、小売業者によって販売されるアイテムの価格表をシステム１００から要求している、小売業者の制御下のコンピューティングデバイスを含むよう意図されている。価格表ロジック１１０は、アイテムの価格データ、アイテムの在庫データ、アイテムのセグメント当たり需要モデル、および選択された目的関数を通信する小売業者のリモートコンピューティングデバイスから電子通信を受信するように構成される。

【0019】

価格データは、各アイテムについて考慮されるべき価格のセットを規定する。価格のセットは、アイテムの通常価格、プロモーション価格および値下げ価格を含む。一実施形態では、プロモーション価格および値下げ価格は、アイテムの通常価格を含まない２つのセットに分離されて、プロモーションおよび値下げシーズンにおける計算を単純化する。価格のセットは、アイテムの「価格ラダー」と称されることもある。一実施形態では、各アイテムのコストデータも、利益の計算に使用するために価格表ロジック１１０によって入力される。

【0020】

在庫データは、「在庫量」を含み、この在庫量は、本明細書の目的のために、通常シーズンの開始時に手元にあるアイテムの初期在庫量と、任意に、通常シーズン中にストックを補充するためのアイテムのスケジュールされた出荷とを含む。アイテムのセットについての価格および在庫データを入力または受信するために、価格表ロジック１１０は、このようなデータ（たとえば、価格ラダーならびに在庫および補充量を符号化する電子記録）を格納するデータベースに照会してもよい。

【0021】

セグメント当たり需要モデルは、小売業者によって提供されてもよく、または価格表ロジック１１０にとってアクセス可能であってもよい。一実施形態では、セグメント当たり需要モデルは、「スキャン－プロ」モデルである。一実施形態では、セグメント当たり需要モデルは、プロセッサによって実行されると、アイテムの価格および弾力性、プロモーション疲労、季節性などの他の要因に基づいてアイテムの需要を計算する格納された命令のセットである。セグメント当たり需要モデルは、さまざまな顧客セグメントのためのさまざまな需要パラメータ値を含む。セグメント当たり需要モデルの一例については以下で詳細に説明するが、実施形態ではさまざまな顧客セグメント間を区別しない需要モデルを含む任意の需要モデルを使用できるということが理解されるべきである。一実施形態では、小売業者は、自身の販売履歴および経験に基づいて需要パラメータの値を提供する。他の実施形態では、価格表ロジック１１０は、セグメント当たり需要モデルを格納および維持するか、またはセグメント当たり需要モデルおよびパラメータ値を異なるソースから取得する。

【0022】

目的関数は、小売業者が最大化しようとする売上高に関連する量を規定する。目的関数の例としては、利益および収益が挙げられる。実施形態では、顧客がアイテムを返品する確率に価格変化がどのように影響を及ぼし得るかおよび利益に対する対応する影響も考慮に入れる新規の目的関数を提供する。

【0023】

価格ロジック１１０は、プロモーション部分と値下げ部分とを含む価格表を生成するように構成される。価格表は、アイテムの通常シーズンおよびクリアランスシーズン中のそれぞれの期間（たとえば、数週間または数日）にわたる価格のセットから選択された一連の価格をアイテムに割り当てる。アイテムの価格表は、各顧客セグメントについて生成される。「独身者」顧客セグメントおよび「母親」顧客セグメントの価格表の例が図１に示されている。価格表の「通常／プロモーション」部分中は２つの顧客セグメントで価格表が異なっているが、価格表の「クリアランス／値下げ」部分中は２つの顧客セグメントで価格表が同一であることが分かる。価格表ロジック１１０は、アイテムの価格設定に使用するために、ネットワーク接続によって価格表を小売業者に送信するように構成される。

【0024】

顧客セグメントが考慮に入れられる場合、プロモーションおよび値下げスケジュール問題は比例的に大きくなる。セグメント当たりのプロモーションおよび値下げスケジューリングを行うための問題のうちの１つは、さまざまな顧客セグメントが同一の在庫を共有することである。別の問題は、一般に値下げ方針が全ての顧客セグメントにわたって同一であるのに対して、セグメント当たりのプロモーション価格設定がターゲットマーケティングによって実現可能であることである。価格表ロジック１１０は、割り振りロジック１２０と、プロモーションロジック１３０と、値下げロジック１４０とを含み、これらのロジックは、協働して、多面的プロセスを使用してこれらの問題に対処して、価格表のプロモーション部分および値下げ部分を生成する。

【0025】

割り振りロジック１２０は、少なくとも目的関数に対する各顧客セグメントの寄与予想に基づいて、複数の顧客セグメント間で在庫量（たとえば、初期在庫および任意に補充量）を割り振るように構成される。各顧客セグメントについてプロモーション価格決定を行う前に各顧客セグメントに在庫を割り振ることによって、顧客セグメント間のリンクは断ち切られ、価格表のプロモーション部分および値下げ部分を生成するプロセスが大幅に簡略化される。

【0026】

たとえば、財布は、３つの異なる顧客セグメント、すなわち独身女性、母親および退職者、に販売されてもよい。セグメント当たり需要モデルは、各セグメントについてのさまざまな需要パラメータ値を含むことによって、これらの異なるタイプの顧客の特定の行動を指定する。割り振りロジック１２０は、目的関数に対する各顧客セグメントの寄与度を予想するように構成される。一実施形態では、セグメント当たり需要モデルに基づいて、割り振りロジック１２０は、（１）全ての在庫量が独身女性セグメントに割り振られると、１２００．００ドルの収益（すなわち、目的関数）が生成され、（２）全ての在庫量が母親に割り振られると、１０００．００ドルの収益が生成され、（３）全ての在庫量が退職者に割り振られると、３００．００ドルの収益が生成されると判断してもよい。割り振りロジック１２０は、この寄与予想に基づいて在庫量を異なる顧客セグメントに割り振る（たとえば、在庫量のうちの１２００／（１２００＋１０００＋３００）または４８％が独身女性顧客セグメントに割り振られる、など）。他の実施形態では、目的関数に対する各顧客セグメントの寄与度を予想する他の方法が使用される。

【0027】

プロモーションロジック１３０は、価格表のプロモーション部分を決定するように構成される。各顧客セグメントについて、顧客セグメントに割り振られた在庫の量に基づいて、プロモーションロジック１３０は、目的関数を最大化する価格表のプロモーション部分を決定するように構成される。プロモーション部分は、アイテムの通常シーズン中のそれぞれの期間にわたる価格のセットから選択された一連の価格をアイテムに割り当てる。

【0028】

値下げロジック１４０は、通常シーズンの終了時に、各顧客セグメントにおける残余在庫の量を集計するように構成される。値下げロジック１４０は、少なくとも集計された在庫に基づいて、目的関数を最大化するアイテムの価格表の値下げ部分を決定するように構成される。値下げ部分は、アイテムのクリアランスシーズン中のそれぞれの期間にわたる価格のセットから選択された一連の価格をアイテムに割り当てる。価格ロジック１１０は、各顧客セグメントのプロモーション部分と値下げ部分とを組み合わせて、顧客セグメントの価格表を作成する。

【0029】

一実施形態では、システム１００は、企業組織のためのアプリケーションまたは分散アプリケーションの集合体を含むコンピューティング／データ処理システムである。アプリケーションおよびコンピューティングシステム１００は、クラウドベースのネットワーキングシステム、「ソフトウェア・アズ・ア・サービス」（「ＳａａＳ」）アーキテクチャまたは他のタイプのネットワーク接続されたコンピューティングソリューションとともに動作するように構成されてもよく、またはクラウドベースのネットワーキングシステム、「ＳａａＳ」アーキテクチャまたは他のタイプのネットワーク接続されたコンピューティングソリューションとして実現されてもよい。一実施形態では、価格表ロジック１１０は、少なくとも本明細書に開示されている機能を提供し、コンピュータネットワークを介してコンピューティングシステム１００（サーバとして機能）と通信するコンピューティングデバイス／端末を介して多くのユーザによってアクセスされる集中型サーバ側アプリケーションである。

【0030】

図２Ａは、一実施形態に係る、アイテムのセットの価格表を生成するコンピュータ化されたシステム２００を示す。システム２００は、価格表ロジック２１０を含み、価格表ロジック２１０は、図１の割り振りロジック１２０、プロモーションロジック１３０および値下げロジック１４０について説明したものと同様に機能する割り振りロジック２２０、プロモーションロジック２３０および値下げロジック２４０を含む。価格ロジック２１０は、オプティマイザ（たとえば、「Ｇｕｒｏｂｉ」適正化ソルバなどの混合整数線形プログラミング（「ＭＩＬＰ」）ソルバ）と対話して価格表を生成するように構成される。ビジネスルールに従って価格表のさまざまな側面を制約するいくつかの制約および以下で説明するように価格表ロジック２１０によって生成される他の制約は、価格表ロジック２１０によって格納される。多くの例示的な制約を表す数学的表記は付表Ａに含まれている。これらの制約は、付表の中の制約に割り当てられた制約番号によって参照される。

【0031】

開示されているように、アイテムの数が増加するにつれて、セグメント当たり需要モデルを使用して価格表を迅速に生成することの複雑さが非現実的なものになる。ＭＩＬＰベースのオプティマイザを使用したソリューションを実現可能にするために、価格表ロジック２１０は、価格ロジック２５０、需要モデルロジック２６０および目的関数ロジック２７０を含み、これらのロジックは、近似制約の形式でオプティマイザに提供される価格データ、セグメント当たり需要モデルおよび目的関数をそれぞれ簡略化する。

【0032】

価格ロジック２５０は、価格を整数変数として表現することを可能にする態様で価格のセットを近似する価格線制約を生成するように構成される。需要ロジック２６０は、顧客セグメントの需要関数を近似する２つ以上の線形需要ピースを生成し、これらのピースのうちの選択された１つのピースを各価格値の需要ピース制約として提供するように構成される。

【0033】

割り振りロジック２２０、プロモーションロジック２３０および値下げロジック２４０は、近似制約が詳細に開示された後に、以下により詳細に開示されている態様で、選択された他の制約とともに近似制約をオプティマイザに提供するように構成される。

【0034】

図２Ｂは、一実施形態に係る、アイテムの価格のセットを近似するために使用される価格線制約を価格ロジック２５０がどのように生成するかを示す図である。価格線制約を使用することにより、有限区間にわたる整数変数の最適化問題が、一般に、同一の区間を占める「スケーリングされた」数値の二値変数を含む問題よりも対処するのが簡単であるということが認められる。アイテムの価格のセットまたは「価格ラダー」における価格が規則正しく間隔をあけて配置されている場合、価格ラダーは、スケーリングされた整数変数によって表すことができる。この特徴を使用して、整数である位置変数「ｗ」によって示される線によって価格ラダーを近似する。この線における価格は、ｗのさまざまな値に対応する。一般に、価格ラダーは、離散的であり、必ずしも均等に間隔があいていない。しかし、この場合でも、価格線近似は、許容できる結果を生じさせる。最適化後、オプティマイザによって選択された位置変数ｗに対応する価格ラダーからの「真の」価格値は、価格表およびその他の計算に含まれることができる。

【0035】

所与の価格ラダーについて線を求めるために、通常の最小二乗（「ＯＬＳ」）回帰が価格に対して実行され、図２Ｂに示されるように、各価格には順番にｗの次の値が割り当てられる。付表Ａに制約「Ｃ１」として含まれている価格線制約は、以下のように数学的に表すことができる。

【0036】

【数1】

【0037】

図２Ｃは、一実施形態に係る、オプティマイザに提供されるセグメント当たり需要モデルの線形近似である需要ピース制約を需要ロジック２６０がどのように決定するかを示す図である。一実施形態では、需要ロジック２６０は、２つの線形ピースに対してセグメント当たり需要モデルを近似するように構成される。２つの線形ピースを含む１つの近似需要モデルの数式は、以下の通りである。

【0038】

【数2】

【0039】

通常シーズンにおける第１および第２の需要ピースの傾きおよびｙ切片を求めるために、各製品、顧客セグメントおよび通常シーズンにおける期間についての価格ラダーにおけるさまざまな価格を考慮に入れて求められる需要値に対してＯＬＳ回帰が実行される。結果として生じる需要ピースは、プロモーション価格を生成するために使用されるセグメント当たり需要ピースである。

【0040】

クリアランスシーズン中に、さまざまなセグメントの需要値が各期間において集計され、集計された需要のＯＬＳ回帰が各製品および期間について実行される。結果として生じる需要ピースは、値下げ価格を生成するために使用される集計需要ピースである。

【0041】

数学的に、任意の所与の価格ポイントについて、需要ロジック２６０は、より高い需要を生み出す需要ピース制約を選択する。これが、式２が「ｍａｘ」関数を含む理由である。制約Ｃ８は、需要ピース制約の一実施形態を数学的に表している。

【0042】

一実施形態では、需要ロジック２６０は、３つ以上のピースに対して需要モデルを近似するように構成される。需要ロジック２６０は、２つのピースが使用される場合のフィットにおけるエラー（誤差）を求め、このエラーが閾値を上回る場合に、最も高いエラーポイントで需要モデルを「分解」して３つの線形ピースを再計算するように構成される。このプロセスは、エラーが十分に小さくなるまで繰り返される。次いで、需要モデルロジック２６０は、上記のように、各価格ポイントにおいて最高需要を生み出すピースを選択する。

【0043】

再び図２Ａを参照して、アイテムの価格表を生成するために価格表ロジック２１０によって利用される多段階プロセスについてここで説明する。割り振りロジック２２０が目的関数（たとえば、収益）に対する各顧客セグメントの寄与予想に基づいて顧客セグメント間で在庫量を割り振ることを思い起こされたい。割り振りロジック２２０は、オプティマイザを使用して、以下のように各セグメントの寄与度を予想する。割り振りロジック２２０は、在庫量全体（初期在庫および全ての補充を含む）を各セグメントに割り振る。割り振りロジック２２０は、制約Ｃ７を制約Ｃ７′に変更し、また制約Ｃ８を制約Ｃ８′に変更する（付表Ａを参照）。

【0044】

割り振りロジック２２０は、以下のようにセグメント単位の変数を使用して「値下げ価格変化限界」制約Ｃ４を調整する。

【0045】

【数3】

【0046】

割り振りロジック２２０は、各セグメントに割り振られた全在庫量、変更された「在庫保存」制約Ｃ７′、変更された「値下げ価格変化限界」制約Ｃ４、価格線制約Ｃ１、変更された需要ピース制約Ｃ８′、ならびに制約Ｃ２およびＣ３をオプティマイザに送る。なお、一実施形態では、割り振りロジック２２０は、在庫量を割り振るために使用される問題定式化にセルスルー制約Ｃ５を含めない。セルスルー制約は、販売シーズン全体にわたって販売される特定の在庫量（たとえば、９０％）を指定する。この制約を除外することにより、オプティマイザが最適な目的関数を解くことができない可能性が減少する。

【0047】

【数4】

【0048】

【表1】

【0049】

オプティマイザが価格線上の価格０．７９に対応する２という位置変数値を返すと、プロモーションロジックは、位置変数２に関連付けられた０．８０という「真の」価格を選択する。通常シーズンにおける各期間についての選択された価格は、価格表のプロモーション部分を構成する。

【0050】

値下げロジック２４０は、価格表の値下げ部分を生成するように構成される。値下げロジック２４０は、全ての通常シーズン期間を除外する。なぜなら、アイテムがクリアランスシーズン向けに価格設定されているからである。

【0051】

【数5】

【0052】

制約
システム１００のユーザは、いくつかの異なるビジネス関連制約を選択的にイネーブルにして指定してもよい。これらの制約は、割り振りロジック２２０、プロモーションロジック２３０および値下げロジック２４０によってオプティマイザに提供される。ここで、ビジネス関連制約の例について説明する。当然のことながら、小売業者の価格設定方針に従ってオプティマイザのソリューションを制約するために、アイテムの考えられる価格に対する他の制約がいくらでもオプティマイザに提供されてもよい。

【0053】

「セルフノータッチ（self no-touch）」制約は、特定のアイテムの２つの連続するプロモーションがいくつかの期間（たとえば、連続するプロモーション間に最低２週間）によって区切られるべきであるという事実をモデル化する。小売業者は、特定の（または、全ての）アイテムについてこの制約をイネーブルにすることを選択して、各アイテムについて、連続するプロモーション間の最小期間数を指定してもよい。ＭＩＰソルバへの入力に適した「セルフノータッチ」制約の１つの考えられる数学的定式化が、付表Ａに制約Ｃ１０として数学的形式で示されている。

【0054】

「クロスノータッチ（cross no-touch）」制約は、任意の２つの異なるアイテムの２つの連続するプロモーションがいくつかの期間（たとえば、任意のブランドのヨーグルトの連続するプロモーション間に最低２週間）によって区切られるべきであるという事実をモデル化する。小売業者は、特定の（または、全ての）アイテムのセットについてこの制約をイネーブルにすることを選択して、各アイテムのセットについて、連続するプロモーション間の最小期間数を指定してもよい。ＭＩＰソルバへの入力に適した「クロスノータッチ」制約の１つの考えられる数学的定式化が、付表Ａに制約Ｃ１１として数学的形式で示されている。

【0055】

設定された制約は、「プロモーションしなければならないアイテムのセット」と「プロモーションできないアイテムのセット」とを含む。「プロモーションしなければならないセット」の中のアイテムは、一緒にプロモーションしなければならない。たとえば、あるシャンプーブランドの製品が３つある（たとえば、シャンプー、コンディショナーおよびヘアスプレー）場合、小売業者は、これら３つの製品を全て同時にプロモーションした方がよい。小売業者は、特定のアイテムのセットについて「プロモーションしなければならないセット」制約をイネーブルにすることを選択してもよい。「プロモーションできないセット」の中のアイテムは、一緒にプロモーションすることができない。たとえば、小売業者は、非常に人気があるシャンプー製品と売れ行きの悪いシャンプー製品とを同時にプロモーションしたくないであろう。小売業者は、特定のアイテムのセットについて「プロモーションできないセット」制約をイネーブルにすることを選択してもよい。ＭＩＰソルバへの入力に適した「プロモーションしなければならないセット」制約および「プロモーションできないセット」制約の１つの考えられる数学的定式化が、付表Ａにそれぞれ制約Ｃ１２およびＣ１３として数学的形式で示されている。

【0056】

小売業者は、アイテム間制約を使用して、２つのアイテム間の価格順序を維持する価格制限を課すことができる。たとえば、小売業者は、ナショナルブランドアイテムの価格がプライベートブランドアイテムよりも常に高くあるべきであることを指定した方がよい。別の例は、２パックの２リットルコーラボトルと４パックの２リットルコーラボトルとの間の価格関係を維持するというものであろう。小売業者は、特定のアイテムのセットについてアイテム間制約をイネーブルにすることを選択してもよい。小売業者は、維持しなければならないセット内のアイテムの価格間の関係を指定する。ＭＩＰソルバへの入力に適した「クロスノータッチ」制約の１つの考えられる数学的定式化が、付表Ａに制約Ｃ１４として数学的形式で示されている。

【0057】

返品の確率
入力
開示されているように、上記に加えて、実施形態では、返品の確率を考慮に入れる。したがって、実施形態は、以下の追加の入力を含む。

【0058】

・コストＣ_ｇｉ：これは、店舗ｇで購入されたアイテムｉの返品を処理する小売業者のコストである。小売業者の顧客は、ある店舗で購入して別の店舗に返品することが可能であり、これが小売業者でよくあることである場合、ｇで買い物をした顧客から返品を受け取る可能性が最も高い店舗では、コストＣ_ｇｉは平均的な返品処理コストに設定されるべきである。たとえば、ｇの近くの店舗では、Ｃ_ｇｉはアイテムｉの平均的な返品処理コストに設定されてもよい。

【0059】

【数6】

【0060】

ロジスティック関数
表記を最小限に抑えるために、以下の式では、店舗が１つだけであるとする。複数の店舗に対応することは、全ての店舗に対して以下の全てのことを繰り返すことであるため、１つの店舗についてのみ仕組みを説明するだけで十分である。したがって、明細書の残りの部分では、添え字は店舗添え字を含まない。

【0061】

実施形態では、以下のロジスティック関数を使用する。

【0062】

【数7】

【0063】

式中、ｐは価格である。この関数は、０から１の範囲であり、価格ｐについての返品の確率を示す。ａ_ｉｔｓ＞０であるので、価格ｐが上昇するにつれてＳは１に向かい、ｐが下落するにつれてｐは０に向かう。０から１に向かうその特性のために、それは、確率を表すために一般に使用され、価格に基づいて返品の確率を示すことに適合される。式８のロジスティック関数は、以下により詳細に開示されている、線形化可能であるという利点も有する。

【0064】

価格設定に対する返品確率の影響
目的関数（付表Ａに開示）は、項Ｒ_ｉｔｓ（ｐ_ｉｔｓ）の合計であり、これは、セグメントｓからの価格ｐ_ｉｔｓについての週ｔにおけるアイテムｉからの収益を意味する。実施形態では、さまざまな制約を受ける各アイテム、各週、およびおそらく各セグメントについて価格ｐ_ｉｔｓを選択して、全ての項Ｒ_ｉｔｓ（ｐ_ｉｔｓ）の合計を最大化する。記載されているように、これは、１つだけの店舗の収益であるため、全ての店舗に対して繰り返されることができる。

【0065】

返品の確率を考慮に入れるために、実施形態では、米国特許出願番号第１４／９８９，９３２号（その開示は引用によって本明細書に援用される）に開示されている目的関数を以下のように変更する。

【0066】

【数8】

【0067】

ここで、第二項は、収益Ｒ_ｉｔｓ（ｐ_ｉｔｓ）の一部、すなわち価格ｐ_ｉｔｓにおける返品の確率に等しい部分を引き算する。なぜなら、その部分は顧客に返還されなければならないからである。末項は、返品されるユニットについて小売業者が負担するコストを反映する。Ｕ_ｉｔｓ（ｐ_ｉｔｓ）は、価格がｐ_ｉｔｓであるときに販売されるユニットの数であり、返品の確率を乗算することによって、返品されるユニットの数が求められる。Ｃ_ｉは、１個のアイテムｉを処理するコストであるため、末項は、Ｒ_ｉｔｓ（ｐ_ｉｔｓ）によって表される売上高に起因する返品処理の総コストを示す。

【0068】

上記の変化は全て、目的関数に返品の確率を組み込むことに関連する。しかし、返品は、販売可能な在庫の量も増加させるので、在庫を追跡する米国特許出願番号第１４／９８９，９３２号に開示されているメカニズムは、変更を必要とする。変更は、付表ＡにおけるＣ７およびＣ７′に反映される。これらの変更は、返品が発生する場合に顧客は元々購入した店舗と同一の店舗にアイテムを返品することを想定している。実施形態では、各店舗を独立して扱うので、購入した店舗と異なる店舗に返品する場合に対処することはできない。

【0069】

【数9】

【0070】

需要が在庫を上回る期間では、上記の目的関数の収益部分は、需要を乗算した価格よりも収益に対する寄与が少ないべきである。なぜなら、需要の一部が満たされないからである。しかし、目的関数は、これらの期間でさえも単純に全収益を組み込むため、存在しない在庫を販売することによって収益を最大化する価格設定ソリューションをオプティマイザが生成することが可能であろう。ペナルティλは、これが起こることを防ぐ。なぜなら、λが十分に大きければ、オプティマイザは、たとえ収益の増加につながるとしてもバックオーダーの使用を最小限に抑え、実現可能なソリューションを生成する必要がある場合にのみバックオーダーを使用するからである。たとえば、バックオーダーがゼロ以外である期間数は最小限であり、つまり、オプティマイザは、最適な価格設定ソリューションと同様に、できる限り多くの期間を使用して在庫を販売する。

【0071】

線形化
実施形態では、上記の米国特許出願番号第１４／９８９，９３２号に開示されている目的関数の全ての項Ｒ_ｉｔｓ（ｐ_ｉｔｓ）を変更するが、Ｓ_ｉｔｓ（ｐ_ｉｔｓ）の線形化を使用する。市販のＧｕｒｏｂｉソルバを使用してＳ_ｉｔｓ（ｐ_ｉｔｓ）を直接使用することができないので、実施形態では線形化が使用される。したがって、目的関数は、その形式に対して制限がある。具体的には、Ｓ_ｉｔｓ（ｐ）は、ｐの制限値について価格ｐの線形関数によって近似されるべきであり、この近似をＳ_ｉｔｓ（ｐ）の代わりに使用することができる。実施形態では、近似は以下の通りである。

【0072】

【数10】

【0073】

この近似および範囲の派生物ならびにそれが優れた近似である理由について以下で説明する。上記の範囲および近似は、ロジスティック関数の変化の大半、すなわち０から１に移行している部分を取り込む。この範囲外では、ロジスティック関数は、０または１のいずれかに非常に近くなる。

【0074】

【数11】

【0075】

したがって、実施形態では、ｙ＝ｍｘ＋０．５，ｍ＞０という形式の線形関数を用いて、－３から３の間で関数Ｓ（ｘ）を近似することができる。実施形態では、この線形関数を［－３，３］の範囲内でできる限りＳ（ｘ）に近付けるようにｍの値を求める。近さを測定するために、実施形態では、Ｌ_２ノルムと呼ばれる標準的なこのような基準を選択する。したがって、実施形態では、以下のように最小化するｍを求める。

【0076】

【数12】

【0077】

実際、ロジスティック関数およびｙ＝ｍｘ＋０．５の対称性を使用して、－３から３の代わりに０から３までの積分を最小化するだけでよい。

【0078】

ｍを解くために、積分は、以下のように二乗を展開することによって計算される。

【0079】

【数13】

【0080】

式中、Ｃは、ｘのみを含みｍを含まないいくつかの項を表す。このような項は、積分後は単に定数になるため、最良のｍを計算することに影響を及ぼさず、単に除外されることができる。これにより、積分は以下のようになる。

【0081】

【数14】

【0082】

ここで、以下のように数値的に積分する必要がある。

【0083】

【数15】

【0084】

ここで、実施形態では、Ｌ_２積分を最小化するｍを求める。上記の式は、ｍの二次方程式であるため、ｍに関して微分して、結果として生じる式が０になる場合を求めることによって、最小値が求められる。

【0085】

【数16】

【0086】

これは、ロジスティック関数の線形化についての上記のセクションに見られる０．１８である。

【0087】

次いで、実施形態では、どこで近似が０になり、どこで近似が１になるかを確認する。なぜなら、近似は、ｘが－３よりもわずかに大きい場合に０に達し、ｘが３よりもわずかに小さい場合に１に達することが可能であるからである。実際、近似は、ｘ≒－２．７７で０に達し、ｘ≒２．７７で１に達するので、近似の範囲は、［－２．７７，２．７７］であり、これは、実施形態で使用される範囲である。

【0088】

実施形態では、値が適切に小さいことを確認するために、０．１８がｍに代入された状態で元のＬ_２ノルムの値を数値的に積分する。

【0089】

【数17】

【0090】

図３Ｂは、実施形態に係るロジスティック関数をその近似値とともにグラフで示す。
近似を組み込んだ目的関数を解く
米国特許出願番号第１４／９８９，９３２号では、Ｒ_ｉｔｓ（ｐ_ｉｔｓ）およびＵ_ｉｔｓ（ｐ_ｉｔｓ）の式は両方とも、価格ｐ_ｉｔｓの点で線形であるため、Ｓ_ｉｔｓ（ｐ_ｉｔｓ）に対する上記の近似を使用した後は、項Ｓ_ｉｔｓ（ｐ_ｉｔｓ）Ｒ_ｉｔｓ（ｐ_ｉｔｓ）およびＳ_ｉｔｓ（ｐ_ｉｔｓ）Ｕ_ｉｔｓ（ｐ_ｉｔｓ）Ｃ_ｉは両方とも、ｐ_ｉｔｓの二次方程式である。これは、Ｇｕｒｏｂｉソルバのための許容された形式の目的関数である。しかし、これは、Ｇｕｒｏｂｉソルバのための許容された形式の目的関数であるが、目的関数からの無意味な値を回避するために、実施形態では、価格に対して追加の制限を課す。

【0091】

具体的には、実施形態がＳ_ｉｔｓ（ｐ_ｉｔｓ）に対して使用している近似は、上記の範囲内でのみ有効であるため、ｐ_ｉｔｓは、この範囲に制限されるべきである。この範囲を超えることは、Ｓ_ｉｔｓ（ｐ_ｉｔｓ）に対する近似が０未満または１よりも大きな数値を返すことを意味し、これは、確率としては無意味である。したがって、近似のための上記の範囲制約が含められる。しかし、実施形態では、単純に全てのｐ_ｉｔｓに対してこれらの制限を盲目的に課すことはせず、実際には、これらの制限を課すために下記の前処理ステップが使用される。

【0092】

小売業者における価格設定に関する一般的なビジネスルールを反映する、価格に対するいくつかの制約が上記に開示されている。これらの制約のうちの１つは、「価格ラダー」制約であり、これは、既にそれ自体の範囲制約を価格に対して課しており、実際には店舗ｓにおけるアイテムｉの価格の有限のセットを指定する。これらの価格のうちの一部のみが、ロジスティック近似によって課される範囲に入ってもよく、いくつかの価格が実際にそうなることができる。したがって、実施形態では、以下の前処理機能を組み込む。

【0093】

１．ｓにおけるアイテムｉの価格ラダーにおける価格のうちの８０％未満が、ロジスティック近似によって課される範囲に入る場合、実施形態では、この店舗におけるこのアイテムの返品確率を考慮に入れない。具体的には、店舗ｓにおけるアイテムｉの目的関数の一部は、上記に開示されているように変更されない。

【0094】

【数18】

【0095】

ロジスティック回帰を実行するための履歴データ
「取引」は、精算を介した１回の買い物で顧客が購入したアイテムを含む。回帰の履歴データは、以下の顧客が識別された取引を含む。

【0096】

・取引の日付
・顧客が購入したアイテムのバスケット
・取引が発生した店舗、および
・顧客の識別子
そのため、同一の顧客が再び取引を行うのがいつであるかが分かる（そうでなければ、データは、顧客がアイテムを返品したか否かを示すことができない）。識別子は、小売業者によって発行されるポイントカード番号であってもよいが、クレジットカード番号などの、顧客のその他の種類の固有の識別子であってもよい。小売業界の慣行は、暗号化されたクレジットカード番号を使用して取引を結び付けることを含むため、ポイントカードは、有用ではあるが、同一の顧客からの取引を結び付けるために必要なものではないであろう。

【0097】

履歴データは、単一の小売業者についての多数のこのような取引を含み、小売業者が格納しているデータを同じぐらい多くのデータを含む。実施形態では、このようなデータは、リレーショナルデータベースにおけるテーブルに格納され、各取引は、複数の行のセットとして格納され、取引で購入された各アイテムについて１つの行があてられる。テーブルは、データの上記４つのピースの各々について列を含むので、各行は、購入されたアイテムを識別する列と、上記のための４つの列とを有し、列は合計５つである。

【0098】

回帰の特徴
実施形態では、回帰は、上記のテーブル上で直接実行されるわけではなく、回帰への入力になる列がテーブルに追加される。履歴データに基づくこのような追加の列は、回帰に送られる「特徴」である。上記のテーブルにおける各行について、下記の特徴のために値が生成される。参照しやすいように、各特徴は、その列名とともに一覧表示されている。このように、これらの列は履歴データのテーブルに追加され、列は下記のように満たされる。そして、ロジスティック回帰に送られるデータセットは、以下の特徴を含む。

【0099】

１．ある行における店舗から導き出される特徴。各行について、以下の特徴を追加する。

【0100】

ａ．店舗の郵便番号の平均世帯収入（ＡＶＧ＿ＨＨ＿ＩＮＣ）
ｂ．店舗の郵便番号のジニ係数（ＧＩＮＩ）：これは、容易に入手できる経済指標であり、この郵便番号内の富のばらつきの量を示す。

【0101】

ｃ．店舗の郵便番号の人口（ＰＯＰ＿ＮＵＭ）
ｄ．店舗がブリック・アンド・モルタルであるかオンライン販売をしているか（Ｅ＿ＤＵＭＭＹ）：この特徴は、「店舗」がオンラインであるか（１）実店舗であるか（０）によって単純に１または０である。

【0102】

２．ある行における顧客から導き出される特徴
ａ．取引日までの顧客の履歴返品確率（ＲＥＴ＿ＰＲＯＢ＿ＷＩＴＨ＿ＰＲＩＯＲ）：Ｄは取引日であるとする。Ｄ以前に顧客が過去に返品したアイテムの数を、Ｄ以前に顧客が過去に購入したアイテムの総数で除算することによってこの特徴を計算する。言い換えれば、それは、取引日Ｄまでの顧客の履歴に基づく、顧客がアイテムを返品する傾向である。

【0103】

３．取引の日付から導き出される特徴
ａ．月インジケータ（ＦＩＳＣＡＬ＿ＭＯ）：これは、回帰におけるカテゴリー変数である（離散的な値をとる変数を意味する）。それは、取引の月を示す。

【0104】

ｂ．休日／主要プロモーションインジケータ（ＨＯＬＩＤＡＹ＿ＤＵＭＭＹ）：この特徴は、０または１のいずれかであり、取引の日付が主要な休日またはプロモーションに近いか否かを示す。休日およびプロモーションのセットは、小売業者当たりに設定可能であり、主要な休日または全店プロモーションに近いために小売業者の売上高が特に多い日を含むべきである。このような日は、小売業者ごとに異なるため、これは、履歴データを調べて小売業者の売上高が特に多い日を見つけ出すことによって、小売業者当たりに設定する必要がある。

【0105】

４．ある行におけるアイテムから導き出される特徴。上記に開示されているように、各行は、１つの購入されたアイテムを（取引の一部として）示し、これらの特徴は、そのアイテムから導き出される。

【0106】

ａ．実際の価格（ＳＡＬＥ＿ＰＲＩＣＥ＿ＦＲＡＣＴＩＯＮ）：これは、この行において顧客が受け取った実際の価格であり、正規価格の何分の１かの価格として表される。たとえば、０．８は、顧客が正規価格から２０％割り引きでアイテムを購入したことを意味するであろう。この特徴では、回帰は、各顧客セグメントについて別々の係数を作成して、顧客セグメントごとの係数のばらつきを取り込む。（これは、標準的な統計的言語における「セグメントに関係する実際の価格」である。）
ｂ．アイテムの正規価格（ＦＵＬＬ＿ＰＲＩＣＥ）：この行における店舗でのアイテムの割り引きなしの価格。

【0107】

ｃ．同一の取引において同一のクラスが購入したアイテムの数（ＳＡＭＥ＿ＧＲＯＵＰ＿ＣＯＵＮＴ）：小売業者で販売されるアイテムは、階層、すなわち「商品階層」に編成される。階層のクラスレベルは、「全てのメンズドレスパンツ」などの同様のアイテムの集合体を示し得て、顧客が同一のクラスから２つ以上のアイテムを購入した取引は、顧客が後にそれらのうちの一部を返品するつもりであることを意味し得る。階層のどのレベルがクラスレベルを示すかは、小売業者に依存する構成である。

【0108】

ｄ．アイテムが最初に発売されてからの日数（ＤＡＹＳ＿ＦＲＯＭ＿ＦＩＲＳＴ）：この行におけるアイテムでは、これは、アイテムの最初の販売日と取引日との間の日数である。

【0109】

ｅ．クラス内の色人気（ＣＯＬＯＲ＿ＰＯＰ）：これは、０から１の間の値であり、取引日までに販売されたアイテムの一部が、この行における店舗での同一のクラス内のこの行におけるアイテムと同一の色を有していたことを示す。

【0110】

ｆ．クラス内のサイズ人気（ＳＩＺＥ＿ＰＯＰ）：ＣＯＬＯＲ＿ＰＯＰと同様に、それは、この行における店舗でのこの行におけるアイテムのサイズの人気を示す。

【0111】

５．アイテムが返品されたことを示す特徴（ＩＴＥＭ＿ＲＥＴＵＲＮＥＤ）。この列は、０または１のいずれかであり、（利用可能な履歴データ内で）この行におけるアイテムが最終的に返品されたか否かを示す。この列は、この顧客についてこのアイテムの返品取引があるか否かを求めるために、利用可能な履歴データを順方向に調べることによって計算される。

【0112】

ロジスティック回帰のためのデータフィルタリング
任意の回帰の実行の標準的な部分は、回帰に送られるデータセットから無意味なデータを除去することである。したがって、上記のデータに対して回帰を実行する前に、実施形態では、以下のうちのいずれかが当てはまる行を除去する。

【0113】

１．ＳＡＬＥ＿ＰＲＩＣＥ＿ＦＲＡＣＴＩＯＮが０から１００の間ではないこと。このような条件は、アイテムの販売のために格納された価格設定データにおけるエラーを示す。

【0114】

２．顧客ＩＤが存在しないか、または「偽の顧客」を示すこと。小売業者の中には、顧客がポイントカードまたは他の識別情報を持っていなかった取引に関連付けられた「デフォルト」顧客ＩＤを有する業者もある。デフォルトＩＤを識別することは、それらに関連付けられたあまりに多すぎる（たとえば、何千もの）取引を有するそれらの顧客ＩＤを見つけ出すことである。このようなＩＤを有するいかなる取引もデータセットから除去されるべきである。

【0115】

３．行が購入を伴わない返品であること。すなわち、行は、商品の返品であるが、ＩＴＥＭ＿ＲＥＴＵＲＮＥＤ特徴の構築中に、対応する購入と対にされない。なお、これは、その行を含む取引全体ではなく、このような返品を示す行のみを除去する。なぜなら、取引における行の残りの部分は、完全に有効なデータであり得るからである。

【0116】

４．返品の際に顧客に返還される金額が、顧客が元々アイテムに支払った額よりも大きいこと。この場合、アイテムの売上高を示す行もその返品を示す行も除去する。やはり、この状況はある種のデータエラーの発生を意味し、関連付けられたデータは当てにならない。

【0117】

ロジスティック回帰の実行
ロジスティック回帰は、上記の行フィルタリングを実行した後に残る行に対して実行される。回帰の従属変数は、ＩＴＥＭ＿ＲＥＴＵＲＮＥＤ特徴であり、全ての他の特徴は、独立変数である。

【0118】

【数19】

【0119】

【表2】

【0120】

【表3】

【0121】

【表4】

【0122】

【数20】

【0123】

【表5】

【0124】

【表6】

【0125】

図４は、一実施形態に係る、各アイテムの返品の確率を考慮に入れた、アイテム群の各アイテムのプロモーションおよび値下げ価格表を決定する際の図１の価格表ロジックの機能のフロー図である。一実施形態では、図４のフロー図の機能は、メモリまたは他のコンピュータ読取可能なもしくは有形の媒体に格納されてプロセッサによって実行されるソフトウェアによって実現される。他の実施形態では、当該機能は、ハードウェアによって（たとえば、特定用途向け集積回路（「ＡＳＩＣ」）、プログラマブルゲートアレイ（「ＰＧＡ」）、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）などを使用することによって）実行されてもよく、またはハードウェアとソフトウェアとの任意の組み合わせによって実行されてもよい。

【0126】

４１０において、アイテムの価格のセットと、アイテムの在庫量と、アイテムのセグメント当たり需要モデルと、セグメント当たり需要モデルの関数である目的関数とを受信または入力する。このステップは、図１および図２Ａ～図２Ｃの価格表ロジック１１０または２１０によって実行されてもよい。一実施形態では、価格のセットに対応するデータは、価格表ロジック１１０によって照会され得るデータベーステーブルまたは他のデータベース構造における記録に格納される。一実施形態では、価格のセットおよび在庫量を表すデータは、レジスタまたはメモリアドレスに格納され、その内容は、価格表ロジック１１０のワーキングメモリに読み取られ、入力され、または転送されてもよい。一実施形態では、セグメント当たり需要モデルおよび選択された目的関数を符号化するデータ構造は、このデータ構造を識別するようにパーズされる小売業者から電子通信によって受信される。上記に詳細に開示されているように、目的関数は、各アイテムの返品の確率およびこのような返品のコストを考慮に入れながら収益を最大化する二次目的関数である。

【0127】

４２０において、少なくとも目的関数に対する各顧客セグメントの寄与予想に基づいて、複数の顧客セグメント間で在庫量を割り振る。４２０は、図１および図２Ａ～図２Ｃの割り振りロジック１２０または２２０によって実行されてもよい。プロセッサは、在庫量を割り振るように割り振りロジック１１０または２２０によって制御される。

【0128】

４３０において、各顧客セグメントについて、少なくとも顧客セグメントに割り振られた在庫量に基づいて、目的関数を最大化する価格表のプロモーション部分を決定する。プロモーション部分は、アイテムの通常シーズン中のそれぞれの期間にわたる価格のセットから選択された一連の価格をアイテムに割り当てる。４３０は、図１および図２Ａ～図２Ｃのプロモーションロジック２４０によって実行されてもよい。プロセッサは、価格表のプロモーション部分を作成するようにプロモーションロジック２４０によって制御される。

【0129】

４４０において、通常シーズンの終了時に、複数の顧客セグメントに割り振られた残余在庫の量を集計する。４４０は、図１および図２Ａ～図２Ｃの値下げロジック２５０によって実行されてもよい。プロセッサは、残余在庫量を集計するように値下げロジック２５０によって制御される。

【0130】

４５０において、少なくとも集計された在庫に基づいて、目的関数を最大化するアイテムの価格表の値下げ部分を決定する。値下げ部分は、アイテムのクリアランスシーズン中のそれぞれの期間にわたる価格のセットから選択された一連の価格を割り当てる。４５０は、図１および図２Ａ～図２Ｃの値下げロジック２５０によって実行されてもよい。プロセッサは、価格表の値下げ部分を作成するように値下げロジック２５０によって制御される。

【0131】

４６０において、プロモーション部分と値下げ部分とを組み合わせて、アイテムの価格表を作成する。４６０は、図１および図２Ａ～図２Ｃの価格表ロジック１１０または２１０によって実行されてもよい。プロセッサは、プロモーション部分と値下げ部分とを組み合わせるように価格表ロジック１１０または２１０によって制御される。

【0132】

一実施形態では、価格表を含む電子通信は、ネットワークまたはインターネット接続によって、小売業者のコンピューティングデバイスに送信される。一実施形態では、価格表は、小売業者のコンピューティングデバイスに、価格表に従って在庫／価格設定データベースのデータ記録におけるアイテムの価格を変更／調整させる。変更／調整された価格は、価格設定ソリューションを提供して、選択された制約を観察する態様で、選択された目的関数を向上させる。

【0133】

一実施形態では、図４の機能は、各顧客セグメントについて以下のことを実行することによって顧客セグメント間で在庫量を割り振ることを含み、上記以下のことは、上記在庫量の全体を上記顧客セグメントに割り振ることと、上記在庫量の上記全体と、上記価格のセットと、近似セグメント当たり需要モデルと、制約の第１のセットと、近似目的関数とをオプティマイザに送信することと、上記オプティマイザから、上記顧客セグメントについての上記近似目的関数のセグメント当たりの値を受信することと、上記顧客セグメントについての全てのセグメント当たりの値の合計に対する上記セグメント当たりの値の比率を計算することと、各顧客セグメントについて上記比率に従って上記顧客セグメント間で上記在庫量を割り振ることとを含む。

【0134】

一実施形態では、図４の機能は、以下のことを実行することによって各顧客セグメントについて上記プロモーション部分を決定することを含み、上記以下のことは、上記価格のセットと、上記顧客セグメントに割り振られた上記在庫量と、上記近似セグメント当たり需要モデルと、制約の第２のセットと、上記近似目的関数とを上記オプティマイザに提供することと、上記オプティマイザから、上記目的関数を最適化する各顧客セグメントについてのプロモーション部分を受信することとを含む。

【0135】

一実施形態では、図４の機能は、以下を実行することによって上記値下げ部分を決定することを含み、上記以下のことは、上記価格のセットと、上記集計された在庫と、上記アイテムの近似集計需要モデルと、制約の第３のセットと、上記近似目的関数とを上記オプティマイザに提供することと、上記オプティマイザから、上記目的関数を最適化する値下げ部分を受信することとを含む。

【0136】

一実施形態では、図４の機能は、上記価格のセットの線形近似に対応する線を計算することを含み、上記線は、上記線を最高価格と最低価格との間のセグメントに均等に分割する位置変数の関数であり、上記位置変数の各整数値は、上記価格のセットの中のある価格に関連付けられる。上記アイテムの上記価格のセットとして、上記線の式を上記オプティマイザに提供し、上記オプティマイザから、選択された価格に対応する上記位置変数の整数値を受信し、上記位置変数に対応する上記価格のセットの中のある価格を識別し、上記識別された価格を上記アイテムの上記価格表に含める。

【0137】

一実施形態では、図４の機能は、各期間について以下のことを実行することによって各顧客セグメントについて上記プロモーション部分を決定することを含み、上記以下のことは、上記アイテムが上記価格のセットの中のそれぞれの価格に価格設定された場合の上記アイテムの顧客セグメント需要のセットを計算することと、上記顧客セグメント需要のセットの区分線形近似に対応する複数の線を計算することと、各価格について、上記価格における最高需要に対応する線を選択することとを含む。上記期間中の上記価格の上記近似セグメント当たり需要モデルとして、上記選択された線の式を上記オプティマイザに提供する。

【0138】

一実施形態では、図４の機能は、各期間について以下のことを実行することによって上記アイテムの上記値下げ部分を決定することを含み、上記以下のことは、各顧客セグメントについて、上記アイテムが上記価格のセットの中のそれぞれの価格に価格設定された場合の上記アイテムの顧客セグメント需要のセットを計算することと、各価格についてのそれぞれの顧客セグメント需要を集計することによって、それぞれの集計需要のセットを計算することと、上記集計需要のセットの区分線形近似に対応する複数の線を計算することと、各価格について、上記価格における最高需要に対応する線を選択することとを含む。上記期間中の上記価格の上記近似集計需要モデルとして、上記選択された線の式を上記オプティマイザに提供する。

【0139】

一実施形態では、図４の機能は、各期間について以下のことを実行することによって上記近似目的関数を決定することを含み、上記以下のことは、少なくとも上記期間の上記近似需要モデルに基づいて、上記価格のセットの中の価格における上記アイテムの売上高を計算することを含む。

【0140】

図５は、本発明の実施形態に係るコンピュータサーバ／システム１０のブロック図である。単一のシステムとして示されているが、システム１０の機能は、分散システムとして実現されてもよい。さらに、本明細書に開示されている機能は、ネットワークを介して結合され得る別々のサーバまたはデバイス上で実現されてもよい。さらに、システム１０の１つ以上のコンポーネントは含まれていなくてもよい。たとえば、サーバの機能のために、システム１０は、プロセッサおよびメモリを含む必要があるが、キーボードまたはディスプレイなどの、図５に示されている他のコンポーネントのうちの１つ以上を含んでいなくてもよい。図５は、本明細書に開示されているコンポーネントのうちのいずれかを実現するために使用され得る。

【0141】

システム１０は、情報を通信するためのバス１２または他の通信機構と、バス１２に結合されて情報を処理するためのプロセッサ２２とを含む。プロセッサ２２は、いかなるタイプの汎用または特定目的プロセッサであってもよい。システム１０は、情報およびプロセッサ２２によって実行される命令を格納するためのメモリ１４をさらに含む。メモリ１４は、ランダムアクセスメモリ（「ＲＡＭ」）、リードオンリメモリ（「ＲＯＭ」）、スタティックストレージ（磁気もしくは光ディスクなど）、またはその他のタイプのコンピュータ読取可能媒体の任意の組み合わせで構成されてもよい。システム１０は、ネットワークへのアクセスを提供するためのネットワークインターフェイスカードなどの通信デバイス２０をさらに含む。したがって、ユーザは、直接、またはネットワークを介してリモートで、またはその他の方法で、システム１０と接続してもよい。

【0142】

コンピュータ読取可能媒体は、プロセッサ２２によってアクセス可能であって、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体、ならびに通信媒体を含む任意の入手可能な媒体であってもよい。通信媒体は、搬送波または他の搬送機構などの変調されたデータ信号の状態でコンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータを含んでもよく、任意の情報配信媒体を含む。

【0143】

プロセッサ２２は、さらに、バス１２を介して液晶ディスプレイ（「ＬＣＤ」）などのディスプレイ２４に結合される。ユーザがシステム１０と接続することを可能にするために、キーボード２６およびコンピュータマウスなどのカーソル制御装置２８がバス１２にさらに結合されている。

【0144】

一実施形態では、メモリ１４は、プロセッサ２２によって実行されると機能を提供するソフトウェアモジュールを格納する。これらのモジュールは、システム１０にオペレーティングシステム機能を提供するオペレーティングシステム１５を含む。これらのモジュールは、アイテムの適正な価格設定を決定する価格適正化モジュール１６をさらに含み、プロモーションおよび値下げ価格スケジューリングならびに本明細書に開示されている全ての他の機能を含む。システム１０は、より大きなシステムの一部であってもよい。したがって、システム１０は、小売管理システム（たとえば、オラクル社からの「オラクル小売需要予測システム」または「オラクル・リテール・アドバンスト・サイエンス・エンジン」（「ＯＲＡＳＥ」））またはエンタープライズ・リソース・プランニング（「ＥＲＰ」）システムなどの追加機能を含むための１つ以上の追加機能モジュール１８を含み得る。データベース１７は、バス１２に結合されて、モジュール１６および１８に対して中央保管を提供し、顧客データ、製品データ、取引データなどを格納する。一実施形態では、データベース１７は、構造化照会言語（「ＳＱＬ」）を使用して格納データを管理することができるリレーショナルデータベース管理システム（「ＲＤＢＭＳ」）である。一実施形態では、専門的な販売時点情報管理（「ＰＯＳ」）端末９９は、需要の予測に使用される取引データおよび履歴売上高データ（たとえば、各小売店舗における各アイテム／ＳＫＵの取引に関するデータ）を生成する。ＰＯＳ端末９９自体は、一実施形態に係る需要を予測するための追加処理機能を含み得て、単独でまたは図５の他のコンポーネントとともに専門的な需要予測システムとして動作することができる。

【0145】

一実施形態では、特に多数の小売店舗、多数のアイテムおよび大量の履歴データがある場合に、データベース１７は、インメモリデータベース（「ＩＭＤＢ」）として実現される。ＩＭＤＢは、コンピュータデータ保管のために主にメインメモリに頼るデータベース管理システムである。それは、ディスクストレージ機構を利用するデータベース管理システムとは対照的である。メインメモリデータベースは、ディスク適正化データベースよりも高速である。なぜなら、ディスクアクセスがメモリアクセスよりもゆっくりであり、内部適正化アルゴリズムがより単純であり、実行するＣＰＵ命令がより少ないからである。メモリ内のデータにアクセスすることにより、データを照会する際のシークタイムが不要になり、ディスクよりも高速かつ予想可能な性能が提供される。

【0146】

一実施形態では、データベース１７は、ＩＭＤＢとして実現される場合、分散データグリッドに基づいて実現される。分散データグリッドは、コンピュータサーバの集合体が１つ以上のクラスタの状態で協働して、分散またはクラスタ化環境内で情報および計算などの関連動作を管理するシステムである。分散データグリッドを使用して、サーバ全体で共有されるアプリケーションオブジェクトおよびデータを管理することができる。分散データグリッドは、短い応答時間、高いスループット、予想可能なスケーラビリティ、連続的な可用性および情報信頼性を提供する。特定の例では、分散データグリッド（たとえば、オラクル社からの「オラクルコヒーレンス」データグリッドなど）は、情報をメモリ内に格納してより高い性能を実現し、当該情報のコピーを複数のサーバ全体で同期させるのにリダンダンシを利用することにより、サーバが故障した場合でもシステムの回復力および連続可用性が保証される。

【0147】

一実施形態では、システム１０は、企業組織のためのアプリケーションまたは分散アプリケーションの集合体を含むコンピューティング／データ処理システムであり、ロジスティクス、製造および在庫管理機能も実現してもよい。アプリケーションおよびコンピューティングシステム１０は、クラウドベースのネットワーキングシステム、ソフトウェア・アズ・ア・サービス（「ＳａａＳ」）アーキテクチャまたは他のタイプのコンピューティングソリューションとともに動作するように構成されてもよく、またはクラウドベースのネットワーキングシステム、ＳａａＳアーキテクチャまたは他のタイプのコンピューティングソリューションとして実現されてもよい。

【0148】

本明細書に記載されているシステムおよび方法は、同一次元の混合整数線形プログラミング問題を生成するために近似の単一の層を含んでいる、ということが上記の説明から分かる。売上高モデルにさらなる非なめらかさを課すことになる在庫切れが、記載の技術によって考慮に入れられる。各々が異なる価格設定の好みを有する複数の異なる顧客セグメントをターゲットにした複数のプロモーション価格表が、記載の技術によって生成される。記載のフレームワークは、混合整数問題（「ＭＩＰ」）ソルバベースの並列化の利用を可能にする態様でさまざまな顧客セグメントについて価格表のプロモーション部分を計算する。記載の技術は、モデルが非線形であるか非凸状であるかにかかわらず、いずれの需要モデルにも適用可能である。さらに、多くの異なるビジネス制約をソリューションプロセスに含めることができる。

【0149】

簡略化のために、本明細書では、目的関数、近似目的関数、係数、変数、制約、需要モデル、近似需要モデルおよび値という用語が使用されている。これらの用語は、上記のコンピューティング要素によって解釈可能な態様で目的関数、近似目的関数、係数、変数、制約、需要モデル、近似需要モデルまたは値を符号化するデータまたはデータ構造を意味するものとして解釈される、ということが理解されるべきである。これらの用語の入力、出力、受信、送信または他の操作は、適宜、記憶媒体へのデータの格納、記憶媒体からのデータの読み取り、ネットワーク接続によるデータの送受信、プロセッサを用いたデータに対する作用として解釈されるべきである。さらに、小売業者という用語は、ｉ）プロモーションおよび値下げ部分を求めるまたはｉｉ）本明細書に記載されているシステムおよび方法によって生成された価格表に従ってアイテムの価格設定を行う小売業者の制御下の１つまたは複数のコンピューティングデバイスとして解釈されるべきである。

【0150】

開示されているように、実施形態では、収益および利益を最大化する価格を設定することによって価格適正化を実行するが、アイテムの返品の確率および在庫に対する起こり得る返品の影響も考慮に入れる。これらの要因を含めることによって、より正確な適正化された価格表を決定することができる。

【0151】

本明細書には、いくつかの実施形態が具体的に示され、および／または、記載されている。しかし、開示されている実施形態の変形例および変更例が、本発明の精神および所期の範囲から逸脱することなく、添付の特許請求の範囲の範囲内で、上記の教示によって包含されるということが理解されるであろう。

【0152】

【表7】

【0153】

【表8】

【0154】

【表9】

【0155】

【表10】

【0156】

【表11】

【0157】

【表12】

【0158】

【表13】

【0159】

【表14】

【0160】

【表15】

【0161】

【表16】

【0162】

【表17】

【0163】

【表18】

【図1】

【図2A】

【図2B】

【図2C】

【図3A】

【図3B】

【図4】

【図5】