JP5981344B2 - 寄与分析を用いた、データへのアクセスの価格設定 - Google Patents

Description

本発明は、寄与分析を用いた、データへのアクセスの価格設定に関する。

データ消費システムは、ネットワーク環境内のプロバイダのデータをホストして、当該システムのユーザが当該データにアクセスできるようにする。当該システムは、データが格納される記憶域を備える。記憶域は、データを格納できる記憶システム（例えば、データベース）である。ユーザは例えば、ネットワークを介してクエリを記憶域に送信することができる。記憶域はクエリを解析して、ユーザのクエリに対する応答を生成するためにどのデータを分析すべきかを判定することができる。分析されるデータは寄与データと呼ばれることがある。寄与データをユーザのクエリに従って分析すると、記憶域が、寄与データのサブセットを含む結果を生成する。記憶域は次いで、例えばネットワークを介して当該結果をユーザに提供する。

記憶域に格納されたデータへのアクセスに対してユーザに課金することができる。しかし、かかる課金に関する従来の価格設定モデルには制限があった。従来の価格設定モデルの１つにはサブスクリプション価格設定モデル（ｓｕｂｓｃｒｉｐｔｉｏｎ ｐｒｉｃｉｎｇ ｍｏｄｅｌ）がある。サブスクリプション価格設定モデルによれば、ユーザにはサブスクリプション料が課金され、これによりユーザがデータに指定の期間（例えば、一か月、一年、等）だけアクセスする権限が与えられる。しばしば、追加の定期サブスクリプション料を支払うことによって、次の期間についてサブスクリプションを更新することができる。しかし、サブスクリプション価格設定モデルでは、一般に、大量のデータにアクセスするユーザと少量のデータにアクセスするユーザが区別されない。例えば、サブスクリプション価格設定モデルでは、データへの無制限のアクセスがユーザに与えられることがよくある。

別の従来の価格設定モデルは、要求単位の価格設定モデル（ｐｅｒ−ｒｅｑｕｅｓｔ ｐｒｉｃｉｎｇ ｍｏｄｅｌ）である。要求単位の価格設定モデルによると、ユーザには、ユーザが記憶域に送信したクエリごとに指定の料金が課金される。しかし、要求単位の価格設定モデルでは、一般に、ユーザが送信できる様々な種類のクエリが区別されず、または、クエリに応答してアクセスされるデータの種類が区別されない。

本明細書ではとりわけ、寄与分析を用いた、データへのアクセスに価格設定するための様々なアプローチを説明する。例えば、ユーザは、データを格納する記憶域にクエリを発行することができる。データを任意の適切な形式で表現することができる。例えば、データを、プロパティを有するオブジェクトとして表現してもよい。この例によれば、オブジェクトが、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ドキュメントの要素、関係データベースの行、列記憶域（ｃｏｌｕｍｎ ｓｔｏｒｅ）の列、等であってもよい。記憶域がデータのサブセットを分析して、クエリに応答してユーザに提供すべき結果を決定することができる。分析されるデータのサブセットを寄与データと称する。

データ・アクセス価格計算器が寄与分析を行って、結果にアクセスするユーザに課金すべき価格を決定する。寄与分析では、寄与データに含まれるデータの行および／または列の数、結果に含まれるデータの行および／または列の数、記憶域が寄与データを分析している間に使用した関数、またはこれらの任意の組合せを考慮する。例えば、データ・アクセス価格計算器がかかる情報を、記憶域から受け取られるインジケータから導出してもよい。別の例では、データ・アクセス価格計算器が、結果に含まれるデータの行および／または列の数を当該結果自体から導出してもよい。

データを複数のテーブルに格納する記憶域に対してクエリを実行する方法の例を説明する。各テーブルはそれぞれ、データの行と列を含む。結果が、クエリに基づいて受け取られる。結果にはデータのサブセットが含まれる。サブセット内のデータの行数を決定する。当該結果にアクセスするためのクエリを発行したユーザに課金すべき価格を、決定したサブセット内のデータの行数に基づいて決定する。

クエリに関する非インラインのクエリ・プランが記憶域から要求される、別の方法の例を説明する。クエリ・プランとは、記憶域によって実施され、記憶域に対するクエリの実行に応答して結果を生成する１組の動作である。非インラインのクエリ・プランとは、全ての関数がインライン化されるわけではないクエリ・プランである。関数とは、クエリ内で参照されるサブ・クエリである。その定義が記憶域によってクエリに取り込まれる（即ち、インライン化される）場合、関数はインライン化されるといい、クエリが記憶域に対して実行されるときにそれが記憶域により呼び出される場合、関数は非インライン化されるという。このように、インライン化された関数は、当該関数の定義をクエリ・プランに取り込むことによってクエリ・プランに含まれ、非インライン化された関数はその関数に対する関数呼出しを列挙することによってクエリ・プランに含まれる。非インライン化されたクエリ・プランが要求されると、クエリ・プランが当該クエリに関して実行すべき関数を含むと判定される。関数の関数価格が決定される。クエリに対応する結果にアクセスするためのクエリを発行したユーザに課金すべき価格は、関数価格に基づいて決まる。

クエリ実行モジュール、結果行決定モジュール、およびアクセス価格決定モジュールを備えるシステムの例を説明する。クエリ実行モジュールは、データを複数のテーブルに記憶する記憶域に対してクエリを実行するように構成される。各テーブルはそれぞれ、データの行と列を含む。結果行決定モジュールは、クエリの実行に応答して受け取られる結果内のデータの行数を決定するように構成される。当該結果は、データのサブセットを含む。アクセス価格決定モジュールは、当該結果にアクセスするためのクエリを発行したユーザに課金すべき価格を、決定した当該結果内のデータの行数に基づいて決定するように構成される。

クエリ・プラン要求モジュール、関数決定モジュール、関数価格決定モジュール、およびアクセス価格決定モジュールを含む、別のシステムの例を説明する。クエリ・プラン要求モジュールは、クエリに関する非インラインのクエリ・プランを記憶域から要求するように構成される。関数決定モジュールは、クエリに関して実行すべき関数をクエリ・プランが含むと判定するように構成される。関数価格決定モジュールは、関数の関数価格を決定するように構成される。アクセス価格決定モジュールは、クエリに対応する結果にアクセスするためのクエリを発行したユーザに課金すべき価格を関数価格に基づいて決定するように構成される。

本発明の概要は、選択した概念を簡潔な形で導入するために与えたものである。当該概念は後の発明を実施するための形態でさらに説明する。本発明の概要は、クレーム主題の主要な特徴または本質的な特徴を特定しようとするものではなく、クレーム主題の範囲を限定するために使用しようとするものでもない。さらに、本発明は発明を実施するための形態および／または本明細書の他の節で説明する特定の実施形態には限定されないことに留意されたい。かかる実施形態は、本明細書で例示の目的でのみ提示するものである。さらなる実施形態は、本明細書に含まれる教示事項を基にすれば当業者には明らかであろう。

添付図面は、本明細書に取り込まれて本明細書の一部を形成し、本発明の諸実施形態を例示し、その説明とともに、必要な原理を説明し当業者が開示された技術を利用できるようにする役割をさらに果たす。

一実施形態に従うデータ消費システムの例のブロック図である。 諸実施形態に従う、寄与分析を用いてデータへのアクセスに価格設定するための方法の流れ図である。 諸実施形態に従う、図１に示すデータ・アクセス価格計算器の実装形態の例のブロック図である。 諸実施形態に従う、寄与分析を用いてデータへのアクセスに価格設定するための方法の流れ図である。 諸実施形態に従う、図１に示すデータ・アクセス価格計算器の実装形態の例のブロック図である。 諸実施形態に従う、寄与分析を用いてデータへのアクセスに価格設定するための方法の流れ図である。 諸実施形態に従う、図１に示すデータ・アクセス価格計算器の実装形態の例のブロック図である。 諸実施形態に従う、寄与分析を用いてデータへのアクセスに価格設定するための方法の流れ図である。 諸実施形態に従う、図１に示すデータ・アクセス価格計算器の実装形態の例のブロック図である。 諸実施形態を実装できるコンピュータの例を示す図である。

開示した技術の機能および利点は、以下で説明する詳細な説明を添付図面と関連して検討すればより明らかになろう。添付図面では、図面全体にわたって同じ参照文字は対応する要素を示す。添付図面では、同じ参照番号は一般に、同一の、機能的に類似の、かつ／または構造的に類似の要素を示す。要素が最初に出現する図面を、対応する参照番号の左端の数字（複数可）により示す。

Ｉ．導入
以下の詳細な説明では、本発明の例示的な諸実施形態を示す添付図面を参照する。しかし、本発明の範囲はこれらの諸実施形態に限定されず、添付の特許請求の範囲により定義される。したがって、添付図面に示すものを越える諸実施形態、例えば、図示した諸実施形態の修正版は、添付図面に示すものを越えるものであっても、本発明により包含することができる。

本明細書における「一実施形態」、「実施形態」、「実施形態の例」、等への参照は、説明した実施形態が特定の機能、構造、または特徴を含みうることを示すが、全ての実施形態が必ずしも当該特定の機能、構造、または特徴を含まなくともよい。さらに、かかる語句は必ずしも同一の実施形態に言及しない。さらに、特定の機能、構造、または特徴を一実施形態と関連して説明するとき、明示するとしないとに関わらずかかる特定の機能、構造、または特徴を他の実施形態と関連して実装することは当業者の知識の範囲内にあると考えている。

ＩＩ．寄与分析を用いた、データへのアクセスの価格設定
諸実施形態の例では、寄与分析を用いた、データへのアクセスに価格設定することができる。例えば、ユーザが、データを格納した記憶域に対してクエリを発行することができる。データを任意の適切な形式で表現してもよい。例えば、データを、プロパティを有するオブジェクトとして表現してもよい。この例によれば、オブジェクトが、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ドキュメントの要素、関係データベースの行、列記憶域の列、等であってもよい。記憶域がデータのサブセットを分析して、クエリに応答してユーザに提供すべき結果を決定することができる。分析されるデータのサブセットを寄与データと称する。データ・アクセス価格計算器が寄与分析を行って、結果にアクセスするユーザに課金すべき価格を決定する。寄与分析では、寄与データに含まれるデータの行および／または列の数、結果に含まれるデータの行および／または列の数、記憶域が寄与データを分析している間に使用した関数、またはこれらの任意の組合せを考慮する。例えば、データ・アクセス価格計算器がかかる情報を、記憶域から受け取られるインジケータから導出してもよい。別の例では、データ・アクセス価格計算器が、結果に含まれるデータの行および／または列の数を当該結果自体から導出してもよい。

本明細書で説明した寄与分析を用いた、データへのアクセスに価格設定するための技術はストアド・プロシージャに適用可能であるが、諸実施形態の例の範囲はこの点に限定されない。ストアド・プロシージャ（ｐｒｏｃ、ｓｐｒｏｃ、ＳｔｏＰｒｏ、ＳＰ、等としても知られる）は、毎回クエリを記憶域に送信する必要がなく、かつ、毎回クエリを再コンパイルする必要がなく、複数回実行できる事前コンパイル型のクエリである。例えば、（他種のクエリと対照的に）ストアド・プロシージャを用いると、データ消費システムにおけるネットワーク・トラフィックおよび／またはプロセッサ負荷を軽減することができる。ストアド・プロシージャはクエリ・タイプの一例である。本明細書で説明した技法を任意の適切なクエリ・タイプに適用可能であることは理解されよう。

本明細書で説明した技法には、データへのアクセスの価格設定に関して、従来の技法と比べて様々な利益がある。例えば、本明細書で説明した技法を用いるとより細かいレベルで（例えば、行単位、列単位、またはセル単位で）データを販売することができる。セルは、データの１行および１列に対応する。結果における列数および／もしくは行数ならびに／またはそれらの中のデータ・タイプを価格設定において考慮してもよい。比較的大量のデータにアクセスしたユーザに、比較的少量のデータにアクセスしたユーザよりも高く課金してもよい。例えば、大量の寄与データが分析されるクエリを送信したユーザに、少量の寄与データが分析されるクエリを送信したユーザよりも高く課金してもよい。クエリ・タイプ、当該クエリに応答して分析されるデータ・タイプ、等に基づいて価格設定を行ってもよい。指定の関数に対して価格を設定してもよい。当該指定の関数は、寄与データの分析中に実施可能な動作を定義する。指定の関数の価格が、当該関数に関して分析される寄与データの量と独立であってもよい。

図１は、一実施形態に従うデータ消費システム１００の例のブロック図である。一般的には、データ消費システム１００は、プロバイダのデータをホストして当該システムのユーザが当該データにアクセスできるようにするように動作する。諸実施形態の例によれば、データ消費システム１００は、データにアクセスするユーザに課金すべき価格を、寄与分析を用いて決定するように動作する。寄与分析を用いた、データへのアクセスに価格設定するための技法についてのさらなる詳細は後述する。

図１に示すように、データ消費システム１００は複数のユーザ・システム１０２Ａ〜１０２Ｍ、ネットワーク１０４、データ・アクセス価格計算器１０６、および記憶域１０８を備える。ユーザ・システム１０２Ａ〜１０２Ｍとデータ・アクセス価格計算器１０６の間の通信が、良く知られたネットワーク通信プロトコルを用いてネットワーク１０４上で実行される。ネットワーク１０４は広域ネットワーク（例えば、インターネット）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、別の種類のネットワーク、またはそれらの組合せであってもよい。データ・アクセス価格計算器１０６と記憶域１０８の間の通信は、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）、ＪＰＱＬ（Ｊａｖａ Ｐｅｒｓｉｓｔｅｎｃｅ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）、等のような良く知られた問合せ言語を用いて実行される。

ユーザ・システム１０２Ａ〜１０２Ｍは、記憶域１０８に格納したデータを要求する（または記憶域１０８にアクセス可能な）データ・アクセス価格計算器１０６へクエリを提供できる処理システムである。処理システムの一例として、１組の命令に従ってデータを操作できる少なくとも１つのプロセッサを備えるシステムがある。例えば、処理システムが、コンピュータ、携帯情報端末、等であってもよい。例えば、ユーザが、当該ユーザが所有するかまたはアクセス可能なユーザ・システム１０２に展開したクライアント（例えば、ウェブ・ブラウザ、ウェブ・クローラ、または他種のクライアント）を用いて、データに対するクエリを開始してもよい。

図１では、ユーザ・システム１０２Ａ〜１０２Ｍをデスクトップ・コンピュータとして示しているが、ユーザ・システム１０２Ａ〜１０２Ｍが任意のクライアント可能なシステムまたは装置であってもよいことは当業者には理解されよう。当該システムまたは装置には、ラップトップ・コンピュータ、携帯情報端末、携帯電話、等が含まれるがこれらに限らない。

データ・アクセス価格計算器１０６は、記憶域１０８に格納された（または記憶域１０８にアクセス可能な）データにアクセスするためのクエリを発行したユーザに課金すべき価格を決定できる処理システムである。ユーザのクエリを受け取ると、データ・アクセス価格計算器１０６は、記憶域１０８に対するクエリを実行する。データ・アクセス価格計算器１０６は、当該クエリに基づく結果を記憶域１０８から受け取る。データ・アクセス価格計算器１０６が、寄与分析インジケータを記憶域１０８から受け取ってもよい。寄与分析インジケータは、データ・アクセス価格計算器１０６による寄与分析の実施を容易にするための情報を含む。例えば、寄与分析インジケータが、ユーザのクエリに関する寄与データに含まれるデータの行数および／または列数、結果に含まれるデータの行数および／または列数、寄与データの分析中に使用された関数、等を指定してもよい。データ・アクセス価格計算器１０６は、結果および／または寄与分析インジケータを分析して、当該結果にアクセスしたユーザに課金すべき価格を決定する。データ・アクセス価格計算器１０６は当該結果を、クエリが開始されたユーザ・システム１０２に転送する。

記憶域１０８は、データを複数のテーブルに格納する記憶装置または記憶システムである。各テーブルには、それぞれ、データの行および列が含まれる。記憶域１０８が処理機能を備えてもよいが、諸実施形態の例の範囲はこの点に限定されることはない。例えば、記憶域１０８が、記憶域１０８に格納されている（または記憶域１０８にアクセス可能な）どのデータが、データ・アクセス価格計算器１０６により実行されるクエリに基づいて分析されるべきかを決定してもよい。この例によれば、記憶域１０８が、当該データを分析してクエリに基づいて結果を決定してもよい。分析されるデータを寄与データと称する。記憶域１０８が寄与分析インジケータを生成してもよいが、諸実施形態の例の範囲はこの点に限定されることはない。寄与分析インジケータは、寄与データに含まれるデータの行および／または列の数、結果に含まれるデータの行および／または列の数、記憶域が寄与データを分析している間に使用した関数、またはこれらの任意の組合せを指定する。記憶域１０８が結果を提供し、（適用可能ならば）寄与分析インジケータをデータ・アクセス価格計算器１０６に提供して、寄与分析に関してさらに処理を行う。

図２は、一実施形態に従う寄与分析を用いてデータへのアクセスに価格設定するための方法の流れ図２００を示す。流れ図２００を、例えば図１に示すデータ消費システム１００のデータ・アクセス価格計算器１０６により実施してもよい。例示の目的のため、一実施形態に従って、流れ図２００を図３に示すデータ・アクセス価格計算器３００に関して説明する。データ・アクセス価格計算器３００はデータ・アクセス価格計算器１０６の一例である。図３に示すように、データ・アクセス価格計算器３００はクエリ実行モジュール３０２、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、結果列決定モジュール３１０、関係決定モジュール３１２、基本価格決定モジュール３１４、プレミアム価格決定モジュール３１６、およびアクセス価格決定モジュール３１８を備える。別の構造的および動作にかかる諸実施形態は、流れ図２００に関する議論を基にすれば当業者には明らかであろう。流れ図２００を以下で説明する。

図２に示すように、流れ図２００の方法はステップ２０２で開始する。ステップ２０２で、データを複数のテーブルに格納する記憶域に対してクエリ実行する。各テーブルは、それぞれ、データの行および列を含む。記憶域に格納されたデータが様々なトピックに関するものであってもよい。例えば、第１のテーブルが、指定の地域で売りに出されている家に関するデータを含んでもよく、第２のテーブルが指定のジャンルの映画に関するデータを含んでもよく、第３のテーブルがレシピに関するデータを含んでもよい、等である。例示の目的のため、流れ図２００の各ステップを、ロサンゼルスにある全ての食料品店の一覧を要求するクエリの例に関して論ずる。この例を以下の議論では「食料品店の例」と称する。食料品店の例で実行されるクエリはクエリの一例にすぎず、任意の適切なクエリを記憶域に対して実行してもよいことは理解されよう。実施形態の例では、クエリ実行モジュール３０２がクエリを実行する。

ステップ２０４で、クエリに基づいて結果を受け取る。当該結果はデータのサブセットを含む。食料品店の例によれば、当該結果が、要求されたロサンゼルスにある全ての食料品店の一覧を含んでもよい。当該結果における食料品店の一覧は記憶域に格納されるデータのサブセットであることは理解されよう。例えば、記憶域が他のデータ、例えば、売りに出されている家に関するデータ、映画に関するデータ、レシピに関するデータ、等を格納してもよい。実装形態の例では、結果受領モジュール３０４が当該結果を受け取る。

ステップ２０６で、サブセット内のデータの行数を決定する。食料品店の例によれば、各行は、結果に含まれる食料品店の一覧内の各食料品店を表してもよい。実装形態の例では、結果行決定モジュール３０６がサブセット内のデータの行数を決定する。

ステップ２０８で、結果にアクセスするためのクエリを発行したユーザに課金すべき価格がサブセット内のデータの列数に基づくべきかどうかを判定する。食料品店の例によれば、各列が食料品店の各特性を表してもよい。例えば、当該特性として、営業時間、電話番号、住所、顧客評価、等を含めてもよい。ユーザに課金すべき価格が、結果が含む特性の数に依存してもよい。実装形態の例では、価格コンポーネント決定モジュール３０８が、結果にアクセスするユーザに課金すべき価格がサブセット内のデータの列数に基づくべきかどうかを判定する。価格が当該サブセット内のデータの列数に基づくべき場合は、フローはステップ２１２に続く。そうでなければ、フローはステップ２１０に続く。

ステップ２１０で、結果にアクセスするためのクエリを発行したユーザに課金すべき価格を決定したサブセット内のデータの行数に基づいて決定する。食料品店の例によれば、価格は結果の食料品店の一覧に含まれる食料品店の数に基づく。実装形態の例では、アクセス価格決定モジュール３１８が、価格を、決定したサブセット内のデータの行数に基づいて決定する。ステップ２１０が完了すると、流れ図２００は終了する。

ステップ２１２で、サブセット内のデータの列数を決定する。食料品店の例によれば、結果に含まれる食料品店の特性の数を決定する。実装形態の例では、結果列決定モジュール３１０が、サブセット内のデータの列数を決定する。

ステップ２１４で、プレミアム価格がサブセット内のデータの少なくとも１つの列に関連付けられているかどうかを判定する。食料品店の例によれば、例示のため、結果に含まれる食料品店の顧客評価に対してプレミアム価格を課金できると仮定する。実装形態の例では、関係決定モジュール３１２が、プレミアム価格がサブセット内のデータの少なくとも１つの列に関連付けられているかを判定する。プレミアム価格がサブセット内のデータの少なくとも１つの列に関連付けられている場合は、フローはステップ２１８に続く。そうでなければフローはステップ２１６に続く。

ステップ２１６で、結果にアクセスしたユーザに課金すべき価格を、決定したサブセット内のデータの行数と決定したサブセット内のデータの列数に基づいて決定する。食料品店の例によれば、価格は、結果に含まれる食料品店の数と食料品店の特性の数に基づく。実装形態の例では、アクセス価格決定モジュール３１８が、価格を、決定したサブセット内のデータの行数と決定したサブセット内のデータの列数に基づいて決定する。ステップ２１６が完了すると、流れ図２００は終了する。

ステップ２１８で、サブセット内のデータの列数に対する基本価格を決定する。例えば、基本価格が、サブセット内のデータの列数と独立な固定価格であってもよい。あるいは、基本価格がサブセット内のデータの列数に比例してもよい。食料品店の例によれば、基本価格は、結果に含まれる食料品店の特性の数に対して決まる。実装形態の例では、基本価格決定モジュール３１４が基本価格を決定する。

ステップ２２０で、プレミアム価格を決定する。実装形態の例では、プレミアム価格決定モジュール３１６がプレミアム価格を決定する。

ステップ２２２で、結果にアクセスするユーザに課金すべき価格を、決定したサブセット内のデータの行数に基づいて、決定したサブセット内のデータの列数に基づいて、基本価格、サブセット内のデータの少なくとも１つの列に関連付けられたプレミアム価格に基づいて、決定する。食料品店の例によると、価格は、結果に含まれる食料品店の数、結果に含まれる食料品店の特性の数、基本価格、およびプレミアム価格に基づく。実装形態の例では、アクセス価格決定モジュール３１８が、ユーザに課金すべき価格を、決定したサブセット内のデータの行数、決定したサブセット内のデータの列数、基本価格、およびプレミアム価格に基づいて決定する。ステップ２２２が完了すると、流れ図２００は終了する。

一実施形態の例によれば、記憶域の幾つかのテーブルに含まれる行に、当該記憶域の他のテーブルに含まれる行よりも高い価格を関連付けてもよい。例えば、第１のテーブル内の行を第１の価格に関連付け、第２のテーブル内の行を第２の価格に関連付けてもよい、等である。ユーザに課金すべき価格を決定するときに、行の間のかかる価格差を考慮してもよい。

幾つかの諸実施形態の例では、流れ図２００のステップ２０２、２０４、２０６、２０８、２１０、２１２，２１４、２１６、２１８、２２０、および／または２２２のうち１つまたは複数を実施しなくともよい。さらに、ステップ２０２、２０４、２０６、２０８、２１０、２１２、２１４、２１６、２１８、２２０、および／または２２２に対する追加または代替のステップを実施してもよい。

データ・アクセス価格計算器３００がクエリ実行モジュール３０２、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、結果列決定モジュール３１０、関係決定モジュール３１２、基本価格決定モジュール３１４、プレミアム価格決定モジュール３１６、および／または価格決定モジュール３１８のうち１つまたは複数を備えなくともよい。さらに、データ・アクセス価格計算器３００が、クエリ実行モジュール３０２、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、結果列決定モジュール３１０、関係決定モジュール３１２、基本価格決定モジュール３１４、プレミアム価格決定モジュール３１６、および／またはアクセス価格決定モジュール３１８に対する追加または代替のモジュールを備えてもよい。

一実施形態の例によれば、流れ図２００のステップ２０８、２１０、２１２、２１４、２１６、２１８、２２０、および／または２２２を、図４の流れ図４００に示すステップで置き換えてもよい。一実施形態に従って、流れ図４００を図５に示すデータ・アクセス価格計算器５００に関して説明する。データ・アクセス価格計算器５００はデータ・アクセス価格計算器１０６の一例である。図５に示すように、データ・アクセス価格計算器５００は第１の列価格決定モジュール５０２、第２の列価格決定モジュール５０４、およびアクセス価格決定モジュール３１８を備える。別の構造的および動作にかかる諸実施形態は、流れ図４００に関する議論を基にすれば当業者には明らかであろう。流れ図４００を以下で説明する。

図４に示すように、流れ図４００の方法はステップ４０２で開始する。ステップ４０２で、サブセット内のデータの第１の列の第１の価格を決定する。実装形態の例では、第１の列価格決定モジュール５０２が当該第１の列の当該第１の価格を決定する。

ステップ４０４で、サブセット内のデータの第２の列の第２の価格を決定する。第２の価格は第１の価格よりも高い。図２を参照して食料品店の例で上述したように、食料品店の顧客評価の価格を、当該食料品店の電話番号よりも高く設定してもよい。したがって、データの第１の列の第１の価格は食料品店の電話番号の価格に対応し、データの第２の列の第２の価格は食料品店の顧客評価の価格に対応してもよい。実装形態の例では、第２の列価格決定モジュール５０４が第２の列の第２の価格を決定する。

ステップ４０６で、結果にアクセスするユーザに課金すべき価格を、決定したサブセット内のデータの行数、第１の価格、および第２の価格に基づいて決定する。食料品店の例によれば、価格は、結果の食料品店の一覧に含まれる食料品店の数、食料品店の電話番号の価格、および食料品店の顧客評価の価格に基づく。実装形態の例では、アクセス価格決定モジュール３０８が、ユーザに課金すべき価格を、決定したサブセット内のデータの行数、第１の価格、および第２の価格に基づいて決定する。

図２および図４の流れ図２００および４００に示した方法では、クエリに基づく結果に含まれるデータの量を考慮している。これらの方法によれば、大量のデータを含む結果へアクセスするユーザに、少量のデータを含む結果にアクセスするユーザよりも多く課金してもよい。しかし、クエリを実行するのに大量の寄与データを分析する必要があったかもしれないが、関連する結果に比較的ごくわずかな（例えば１行の）データが含まれるクエリもある。かかる事例では、結果にアクセスするユーザに課金すべき価格を決定するために寄与データの量を考慮する価格設定モデルを利用することが望ましいかもしれない。

図６は、一実施形態に従ってクエリに関して分析される寄与データの量を考慮した、データへのアクセスに価格設定するための方法の流れ図６００を示す。例示の目的のため、一実施形態に従って、流れ図６００を図７のデータ・アクセス価格計算器７００に関して説明する。データ・アクセス価格計算器７００はデータ・アクセス価格計算器１０６の一例である。図７に示すように、データ・アクセス価格計算器７００はクエリ実行モジュール３０２、インジケータ受領モジュール７０２、寄与行決定モジュール７０４、寄与列決定モジュール７０６、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、およびアクセス価格決定モジュール３１８を備える。別の構造的および動作にかかる諸実施形態は、流れ図６００に関する議論を基にすれば当業者には明らかであろう。流れ図６００を以下で説明する。

図６に示すように、流れ図６００の方法はステップ２０２で開始する。ステップ２０２で、データを複数のテーブルに格納する記憶域に対してクエリ実行する。各テーブルは、それぞれ、データの行および列を含む。例示の目的のため、流れ図６００の各ステップを、最も評価の高いロサンゼルスの中華レストランを要求するクエリの例に関して論ずる。本例を、以下の議論では「レストランの例」と称する。レストランの例で実行されるクエリはクエリの一例にすぎず、任意の適切なクエリを当該記憶域に対して実行できることは理解されよう。一実施形態の例では、クエリ実行モジュール３０２がクエリを実行する。

ステップ６０２で、クエリの実行に関して分析されるデータの第１のサブセットに含まれるデータの行数を指定する、インジケータを受け取る。レストランの例では、データの第１のサブセットがロサンゼルスの全ての中華レストランの一覧を含んでもよい。例えば、データの第１のサブセットに含まれるデータの各行が各々の中華レストランを表してもよい。ロサンゼルスの全ての中華レストランの一覧を、本例では寄与データと称する。実装形態の例では、インジケータ受領モジュール７０２がインジケータを受け取る。

一実施形態の例では、寄与行決定モジュール７０４が、第１のサブセットに含まれるデータの行数をインジケ一タに基づいて決定する。別の実施形態の例によれば、インジケータがさらに、データの第１のサブセットに含まれるデータの列数を指定する。本実施形態によれば、寄与列決定モジュール７０６が、第１のサブセットに含まれるデータの列数をインジケータに基づいて決定してもよい。

別の実施形態の例では、インジケータが、記憶域から受け取ったクエリ・プランを含む。クエリ・プランとは、記憶域によって実施され、記憶域に対するクエリの実行に応答して結果を生成する１組の動作である。例えば、クエリ・プランにより、第１のテーブル内の第１の行数、第２のテーブル内の第２の行数、等がクエリの実行に関して記憶域により分析されると指定してもよい。本実施形態によれば、第１のサブセットに含まれるデータの行数は第１の行数、第２の行数、等の和である。

ステップ６０４で、クエリに基づいて結果を受け取る。当該結果はデータの第２のサブセットを含む。第１のサブセットは、第２のサブセットよりも多くの、記憶域に格納されたデータを含む。例えば、データの第２のサブセットが、データの第１のサブセットのサブセットであってもよい。レストランの例によれば、当該結果に、最も評価の高いロサンゼルスの中華レストランが含まれる。最も評価の高いロサンゼルスの中華レストランが寄与データ（即ち、本例ではロサンゼルスの全ての中華レストランの一覧）のサブセットであることが分かる。実装形態の例では、結果受領モジュール３０４が結果を受け取る。

ステップ６０６で、第２のサブセット内のデータの行数を決定する。レストランの例によれば、結果が、最も評価の高いロサンゼルスの中華レストランを表す１つのデータ行を含むと判定する。実装形態の例では、結果行決定モジュール３０６が第２のサブセット内のデータの行数を決定する。

ステップ６０８で、結果にアクセスするためのクエリを発行したユーザに課金すべき価格が、第１のサブセットに含まれるデータの列数に基づくべきかどうかを判定する。レストランの例によれば、寄与データ内の各列が、中華レストランの各特性を表してもよい。例えば、当該特性として、営業時間、電話番号、住所、顧客評価、等を含めてもよい。ユーザに課金すべき価格が、結果が含む特性の数に依存してもよい。実装形態の例では、価格コンポーネント決定モジュール３０８が、結果にアクセスしたユーザに課金すべき価格を第１のサブセット内のデータの列数に基づくべきかどうかを判定する。価格が第１のサブセット内のデータの列数に基づくべき場合は、フローはステップ６１２に続く。そうでなければ、フローはステップ６１０に続く。

ステップ６１０で、結果にアクセスするためのクエリを発行したユーザに課金すべき価格を、決定した第２のサブセット内のデータの行数と、第１のサブセットに含まれるデータの行数とに基づいて決定する。レストランの例によれば、価格は結果（即ち、本例における結果）に含まれる中華レストランの数と、寄与データに含まれる中華レストランの数とに基づく。実装形態の例では、アクセス価格決定モジュール３１８が価格を、決定した第２のサブセット内のデータの行数と第１のサブセットに含まれるデータの行数とに基づいて決定する。ステップ６１０が完了すると、流れ図６００は終了する。

ステップ６１２で、結果にアクセスするためのクエリを発行したユーザに課金すべき価格を、決定した第２のサブセット内のデータの行数、第１のサブセットに含まれるデータの行数、および第１のサブセットに含まれるデータの列数に基づいて決定する。レストランの例によれば、価格は結果（即ち、本例における結果）に含まれる中華レストランの数と、寄与データに含まれる中華レストランの数と、寄与データに含まれる中華レストランの特性の数とに基づく。実装形態の例では、アクセス価格決定モジュール３１８が価格を、決定した第２のサブセット内のデータの行数、第１のサブセットに含まれるデータの行数、および第１のサブセットに含まれるデータの列数に基づいて決定する。ステップ６１２が完了すると、流れ図６００は終了する。

幾つかの諸実施形態の例では、流れ図６００のステップ６０２、６０４、６０６、６０８、６１０、および／または６１２のうち１つまたは複数を実施しなくともよい。さらに、ステップ６０２、６０４、６０６、６０８、６１０、および／または６１２に対する追加または代替のステップを実施してもよい。

データ・アクセス価格計算器７００がクエリ実行モジュール３０２、インジケータ受領モジュール７０２、寄与行決定モジュール７０４、寄与列決定モジュール７０６、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、および／またはアクセス価格決定モジュール３１８のうち１つまたは複数を備えなくともよいことは理解されよう。さらに、データ・アクセス価格計算器７００がクエリ実行モジュール３０２、インジケータ受領モジュール７０２、寄与行決定モジュール７０４、寄与列決定モジュール７０６、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、および／またはアクセス価格決定モジュール３１８に対して追加または代替のモジュールを備えてもよい。

図６の流れ図６００に示した方法では、寄与データに含まれるデータの量を考慮している。当該寄与データは、結果を決定するためにクエリに関して記憶域により分析されるものである。本方法によれば、大量の寄与データが分析される結果へアクセスするユーザに、少量の寄与データが分析される結果にアクセスするユーザよりも多く課金してもよい。しかし、クエリに関して分析される寄与データの量と必ずしも関係しない当該クエリ内で参照される幾つかの関数に対して指定の価格を設定する価格設定モデルを使用することが望ましいかもしれない。例えば、関数ベースの価格設定により、寄与データが大量であるときに、寄与データの量を考慮に入れた割引を価格設定に関して提供してもよい。

図８は、一実施形態に従ってクエリに関して実行される関数の関数価格を考慮した、データへのアクセスに価格設定するための方法の流れ図８００を示す。例示の目的のため、一実施形態に従って、流れ図８００を図９のデータ・アクセス価格計算器９００に関して説明する。データ・アクセス価格計算器９００はデータ・アクセス価格計算器１０６の一例である。図９に示すように、データ・アクセス価格計算器９００はクエリ・プラン要求モジュール９０２、関数決定モジュール９０４、関数価格決定モジュール９０６、アクセス価格決定モジュール３１８、インジケータ決定モジュール９０８、および価格表示モジュール９１０を備える。別の構造的および動作にかかる諸実施形態は、流れ図８００に関する議論を基にすれば当業者には明らかであろう。流れ図８００を以下で説明する。

図８に示すように、流れ図８００の方法はステップ８０２で開始する。ステップ８０２で、クエリに関する非インラインのクエリ・プランを記憶域から要求する。実装形態の例では、クエリ・プラン要求モジュール９０２が非インラインのクエリ・プランを要求する。クエリ・プランとは、記憶域によって実施され、記憶域に対するクエリの実行に応答して結果を生成する１組の動作である。非インラインのクエリ・プランとは、全ての関数がインライン化されるわけではないクエリ・プランである。関数とは、クエリ内で参照されるサブ・クエリである。その定義が記憶域によってクエリに取り込まれる（即ち、インライン化される）場合に関数はインライン化されるといい、クエリが記憶域に対して実行されるときに記憶域により呼び出される場合に関数は非インライン化されるという。このように、インライン化された関数は、当該関数の定義をクエリ・プランに取り込むことによってクエリ・プランに含まれ、非インライン化された関数はその関数に対する関数呼出しを列挙することによってクエリ・プランに含まれる。

例示の目的のため、クエリが、「５マイル以内の関心点を取得」から全ての中華レストランを要求すると仮定する。「５マイル以内の関心点を取得」というフレーズは関数を表し、記憶域が、当該関数がインライン化または非インライン化されているとして扱ってもよい。記憶域が当該関数をインライン化されているとして扱う場合は、記憶域が当該クエリを修正して、中華レストランである関心点を選択し、ユーザのＸ座標をレストランのＸ座標から減じて各々のＸ距離を提供し、ユーザのＹ座標をレストランのＹ座標から減じて各々のＹ距離を提供し、当該Ｘ距離を二乗して各々の二乗Ｘ距離を提供し、当該Ｙ距離を二乗して各々の二乗Ｙ距離を提供し、各二乗Ｘ距離を対応する二乗Ｙ距離に加算して、その和の平方根をとって各距離を提供し、５マイル未満の距離にある中華レストランを結果として提供してもよい。

他方、記憶域が、当該関数が非インライン化されているとして扱う場合は、記憶域が関数呼出しを行って、ユーザの位置から５マイルの範囲内の全ての関心点を含む中間結果を取得してもよい。当該中間結果はデータの行および列を含むので、当該中間結果をテーブルとして記述してもよい。当該記憶域が当該クエリの他の態様を当該中間結果に対して実行してもよい。本例によれば、記憶域が、中間結果に含まれる関心点のうちどれが中華レストランであるかを判定してもよい。

ステップ８０４で、クエリ・プランが、クエリに関して実行すべき関数を含むと決定する。例えば、クエリ・プランが当該関数に対する関数呼出しを含むと決定してもよい。実装形態の例では、関数決定モジュール９０４が、クエリ・プランがクエリに関して実行すべき関数を含むと決定する。

ステップ８０６で、関数の関数価格を決定する。実装形態の例では、関数価格決定モジュール９０６が関数の関数価格を決定する。

ステップ８０８で、クエリに対応する結果にアクセスするためのクエリを発行したユーザに課金すべき価格を、関数価格に基づいて決定する。実装形態の例では、アクセス価格決定モジュール３１８が、当該結果にアクセスしたユーザに課金すべき価格を関数価格に基づいて決定する。

ステップ８１０で、結果にアクセスしたユーザに課金すべき価格を指定する価格インジケータをユーザに提供すべきかどうかを判定する。実装形態の例では、インジケータ決定モジュール９０８が、当該価格インジケータをユーザに提供すべきかどうかを判定する。価格インジケータをユーザに提供すべき場合は、フローはステップ８１２に続く。そうでなければ、流れ図８００は終了する。

ステップ８１２で、結果にアクセスしたユーザに課金すべき価格を指定する価格インジケータをユーザに提供する。例えば、ユーザに対して、当該結果へのアクセスがユーザに与えられる前に当該価格を受け入れるオプションを与えてもよい。実装形態の例では、価格表示モジュール９１０が価格インジケータをユーザに提供する。ステップ８１２が完了すると、流れ図８００が終了する。

記憶域が、インライン化された関数または非インライン化された関数を用いてクエリを処理してもよいことに留意されたい。非インライン化されたクエリ・プランは、記憶域がインライン化された関数を利用してクエリを処理する能力には影響を及ぼさない。実際、インライン化された関数を利用したクエリの処理は、非インライン化された関数を利用したクエリの処理よりも効率が良い。なぜならば、当該記憶域が、クエリに関して実施すべき動作の順序を選択できるからである。例えば、クエリがユーザの位置から５マイルの範囲内にある全ての中華レストランを要求する場合、ユーザの位置から５マイルの範囲内にある全ての関心点を決定した後にこれらの関心点のうちどれが中華レストランであるかを判定すればより迅速に結果を生成できると記憶域が判定してもよい。あるいは、全ての中華レストランを決定した後にこれらの中華レストランのうちどれがユーザの位置から５マイルの範囲内にあるかを判定すればより迅速に結果を生成できると記憶域が判定してもよい。インライン化された関数により、記憶域がかかる判定を行うことができる。

幾つかの諸実施形態の例では、流れ図８００のステップ８０２、８０４、８０６、８０８、８１０、および／または８１２のうち１つまたは複数を実施しなくともよい。さらに、ステップ８０２、８０４、８０６、８０８、８１０、および／または８１２に対する追加または代替のステップを実施してもよい。

データ・アクセス価格計算器９００がクエリ・プラン要求モジュール９０２、関数決定モジュール９０４、関数価格決定モジュール９０６、アクセス価格決定モジュール３１８、インジケータ決定モジュール９０８、および／または価格表示モジュール９１０のうち１つまたは複数を備えなくともよいことは理解されよう。さらに、データ・アクセス価格計算器９００がクエリ・プラン要求モジュール９０２、関数決定モジュール９０４、関数価格決定モジュール９０６、アクセス価格決定モジュール３１８、インジケータ決定モジュール９０８、および／または価格表示モジュール９１０に対して追加または代替のモジュールを備えてもよい。

クエリ実行モジュール３０２、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、結果列決定モジュール３１０、関係決定モジュール３１２、基本価格決定モジュール３１４、プレミアム価格決定モジュール３１６、アクセス価格決定モジュール３１８、第１の列価格決定モジュール５０２、第２の列価格決定モジュール５０４、インジケータ受領モジュール７０２、寄与行決定モジュール７０４、寄与列決定モジュール７０６、クエリ・プラン要求モジュール９０２、関数決定モジュール９０４、関数価格決定モジュール９０６、インジケータ決定モジュール９０８、および価格表示モジュール９１０をハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装してもよい。

例えば、クエリ実行モジュール３０２、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、結果列決定モジュール３１０、関係決定モジュール３１２、基本価格決定モジュール３１４、プレミアム価格決定モジュール３１６、アクセス価格決定モジュール３１８、第１の列価格決定モジュール５０２、第２の列価格決定モジュール５０４、インジケータ受領モジュール７０２、寄与行決定モジュール７０４、寄与列決定モジュール７０６、クエリ・プラン要求モジュール９０２、関数決定モジュール９０４、関数価格決定モジュール９０６、インジケータ決定モジュール９０８、および／または価格表示モジュール９１０を、１つまたは複数のプロセッサで実行されるように構成したコンピュータ・プログラム・コードとして実装してもよい。

別の例では、クエリ実行モジュール３０２、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、結果列決定モジュール３１０、関係決定モジュール３１２、基本価格決定モジュール３１４、プレミアム価格決定モジュール３１６、アクセス価格決定モジュール３１８、第１の列価格決定モジュール５０２、第２の列価格決定モジュール５０４、インジケータ受領モジュール７０２、寄与行決定モジュール７０４、寄与列決定モジュール７０６、クエリ・プラン要求モジュール９０２、関数決定モジュール９０４、関数価格決定モジュール９０６、インジケータ決定モジュール９０８、および／または価格表示モジュール９１０を、ハードウェア論理または電子回路として実装してもよい。

図１０は、諸実施形態を実装できるコンピュータの例１０００を示す。図１に示す、ユーザ・システム１０２Ａ〜１０２Ｍ、データ・アクセス価格計算器１０６、または記憶域１０８のうち任意の１つまたは複数（または図３、５、７、および９に示すそれらの任意の１つまたは複数のサブコンポーネント）を、コンピュータ１０００の１つもしくは複数の機能および／または代替機能を含めて、コンピュータ１０００を用いて実装してもよい。コンピュータ１０００が、例えば従来型のパーソナル・コンピュータ、モバイル・コンピュータ、またはワークステーションの形の汎用目的のコンピューティング装置であってもよく、または、コンピュータ１０００が特殊目的のコンピューティング装置であってもよい。本明細書で提供したコンピュータ１０００の説明は例示の目的で提供したものであり、限定を意図したものではない。諸実施形態を別の種類のコンピュータ・システムで実装してもよく、これは当業者には明らかであろう。

図１０に示すように、コンピュータ１０００は処理装置１００２、システム・メモリ１００４、システム・メモリ１００４を含む様々なシステム・コンポーネントを処理装置１００２に接続するバス１００６を備える。バス１００６は任意の数種のバス構造のうち１つまたは複数を表わす。当該バス構造には、メモリ・バスまたはメモリ・コントローラ、周辺バス、高速グラフィック・ポート、様々なバス構造のうち任意のものを利用したプロセッサまたはローカル・バスが含まれる。システム・メモリ１００４には、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）１００８およびＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）１０１０が含まれる。ＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１０１２がＲＯＭ１００８に格納される。

コンピュータ１０００はまた、１つまたは複数の以下のドライブ、即ち、ハードディスクを読書きするためのハードディスク・ドライブ１０１４、取外し可能磁気ディスク１０１８を読書きするための磁気ディスク・ドライブ１０１６、および、ＣＤ ＲＯＭ、ＤＶＤ ＲＯＭ、または他の光媒体のような取外し可能光ディスク１０２２を読書きするための光ディスク・ドライブ１０２０を有する。ハードディスク・ドライブ１０１４、磁気ディスク・ドライブ１０１６、光ディスク・ドライブ１０２０は、それぞれ、ハードディスク・ドライブ・インタフェース１０２４、磁気ディスク・ドライブ・インタフェース１０２６、および光ドライブ・インタフェース１０２８によってバス１００６に接続される。ドライブおよびその関連するコンピュータ可読記憶媒体により、コンピュータ可読命令、データ構造、プログラム・モジュールおよびコンピュータの他のデータの不揮発性記憶を提供する。ハードディスク、取外し可能磁気ディスクおよび取外し可能光ディスクを説明したが、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、等のような他種のコンピュータ可読記憶媒体を使用してデータを記憶することができる。

幾つかのプログラム・モジュールをハードディスク、磁気ディスク、光ディスク、ＲＯＭ、またはＲＡＭに格納してもよい。これらのプログラムは、オペレーティング・システム１０３０、１つまたは複数のアプリケーション・プログラム１０３２、他のプログラム・モジュール１０３４、およびプログラム・データ１０３６を備える。アプリケーション・プログラム１０３２またはプログラム・モジュール１０３４が、例えば、本明細書で説明した、クエリ実行モジュール３０２、結果受領モジュール３０４、結果行決定モジュール３０６、価格コンポーネント決定モジュール３０８、結果列決定モジュール３１０、関係決定モジュール３１２、基本価格決定モジュール３１４、プレミアム価格決定モジュール３１６、アクセス価格決定モジュール３１８、第１の列価格決定モジュール５０２、第２の列価格決定モジュール５０４、インジケータ受領モジュール７０２、寄与行決定モジュール７０４、寄与列決定モジュール７０６、クエリ・プラン要求モジュール９０２、関数決定モジュール９０４、関数価格決定モジュール９０６、インジケータ決定モジュール９０８、価格表示モジュール９１０、流れ図２００（流れ図２００の任意のステップを含む）、流れ図４００（流れ図４００の任意のステップを含む）、流れ図６００（流れ図６００の任意のステップを含む）、および／または流れ図８００（流れ図８００の任意のステップを含む）、を実装するためのコンピュータ・プログラム論理を備えてもよい。

ユーザは、コマンドおよび情報を、キーボード１０３８およびポインティング・デバイス１０４０のような入力装置を介してコンピュータ１０００に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲーム・パッド、パラボラ・アンテナ、スキャナ、等を含めてもよい。これらおよび他の入力装置はしばしば、バス１００６に接続されたシリアル・ポート・インタフェース１０４２を介して処理装置１００２に接続されるが、パラレル・ポート、ゲーム・ポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）のような他のインタフェースにより接続してもよい。

ディスプレイ装置１０４４（例えば、モニタ）も、ビデオ・アダプタ１０４６のようなインタフェースを介してバス１００６に接続される。ディスプレイ装置１０４４に加えて、コンピュータ１０００がスピーカおよびプリンタのような他の周辺出力装置（図示せず）を備えてもよい。

コンピュータ１０００は、ネットワーク・インタフェースもしくはアダプタ１０５０、モデム１０５２、またはネットワーク上で通信を確立するための他の手段を介してネットワーク１０４８（例えば、インターネット）に接続される。モデム１０５２は、内部または外部にあることができ、シリアル・ポート・インタフェース１０４２を介してバス１００６に接続される。

本明細書で使用する際、「コンピュータ・プログラム媒体」および「コンピュータ可読媒体」という用語は、一般に、ハードディスク・ドライブ１０１４に関連付けられたハードディスク、取外し可能磁気ディスク１０１８、取外し可能光ディスク１０２２のような媒体、ならびにフラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、等のような他の媒体を指す。

上述したように、コンピュータ・プログラムおよびモジュール（アプリケーション・プログラム１０３２および他のプログラム・モジュール１０３４を含む）をハードディスク、磁気ディスク、光ディスク、ＲＯＭ、またはＲＡＭに格納してもよい。かかるコンピュータ・プログラムを、ネットワーク・インタフェース１０５０またはシリアル・ポート・インタフェース１０４２を介して受け取ってもよい。かかるコンピュータ・プログラムがアプリケーションによって実行またはロードされると、コンピュータ１０００は本明細書で論じた諸実施形態の諸機能を実装することができる。したがって、かかるコンピュータ・プログラムはコンピュータ１０００の制御装置を表す。

諸実施形態の例はまた、コンピュータ使用可能媒体に格納したソフトウェア（例えば、コンピュータ可読命令）を含むコンピュータ・プログラム製品に関する。かかるソフトウェアが１つまたは複数のデータ処理装置で実行されると、データ処理装置（複数可）は本明細書で説明したように動作する。諸実施形態では、現在公知であるかまたは将来公知となる任意のコンピュータ使用可能媒体またはコンピュータ可読媒体を採用してもよい。コンピュータ可読媒体の例には、ＲＡＭ、ハード・ドライブ、フロッピー・ディスク、ＣＤ ＲＯＭ、ＤＶＤ ＲＯＭ、ジップ・ディスク、テープ、磁気記憶装置、光記憶装置、ＭＥＭＳベースの記憶装置、ナノテクノロジ・ベースの記憶装置、等のような記憶装置が含まれるがこれらに限らない。

ＩＩＩ．結論
以上で様々な実施形態を説明したが、これらは例として提示したにすぎず限定ではないことは理解されよう。本発明の精神および範囲を逸脱することなく様々な変更を形態および詳細の点で加えることができることは当業者には明らかであろう。したがって、本発明の外延と範囲は上述した諸実施形態の例の何れによっても限定されず、添付の特許請求の範囲とその均等物によってのみ制限されるべきである。

Claims (12)

1. ネットワーク環境におけるデータベースに対するクエリをプロセッサが実行する方法であって、前記クエリを実行する方法は、
   結果を決定するために分析されるデータを複数のテーブルに格納する記憶域に対して、クエリを実行するステップと、
   少なくとも前記クエリに基づいて、結果を受け取るステップと、
   前記結果に含まれるサブセット内のデータの行数を決定するステップと、
   前記結果にアクセスする前記クエリを発行したユーザに課金すべき価格が、前記結果を決定するために分析されるデータの列数に基づくべき場合に、前記ユーザに課金すべき価格を、前記サブセット内のデータの行数と、前記結果を決定するために分析されるデータの行数および列数に基づいて決定するステップ
   を含むことを特徴とする方法。
2. 前記結果にアクセスする前記クエリを発行したユーザに課金すべき価格が、前記結果を決定するために分析されるデータの列数に基づくべきでない場合に、前記ユーザに課金すべき価格を、前記サブセット内のデータの行数と、前記結果を決定するために分析されるデータの行数に基づいて決定するステップをさらに含む、請求項１に記載の方法。
3. 前記結果にアクセスする前記クエリを発行したユーザに課金すべき価格が、前記結果を決定するために分析されるデータの列数に基づくべき場合に、
   前記サブセット内のデータの列数に対して基本価格を決定するステップと、
   前記基本価格に加えて課金すべき、前記サブセット内のデータの少なくとも１つの列に関連付けられたプレミアム価格を決定するステップと、
   をさらに含み、
   前記結果にアクセスしたユーザに課金すべき価格を決定するステップは、
   前記結果にアクセスしたユーザに課金すべき価格を、さらに前記基本価格、および前記プレミアム価格に基づいて決定するステップ
   を含むことを特徴とする請求項１に記載の方法。
4. 前記サブセット内のデータの第１の列の第１の価格を決定するステップと、
   前記サブセット内のデータの第２の列の第２の価格を決定するステップと、
   をさらに含み、
   前記第２の価格は前記第１の価格よりも高く、
   前記結果にアクセスしたユーザに課金すべき価格を決定するステップが、
   前記結果にアクセスしたユーザに課金すべき価格を、さらに、前記第１の価格、および前記第２の価格に基づいて決定するステップ
   を含むことを特徴とする請求項１又は２に記載の方法。
5. 前記結果にアクセスしたユーザに課金すべき価格を指定する価格インジケータを前記ユーザに提供するステップをさらに含むことを特徴とする請求項１に記載の方法。
6. 前記記憶域に対して前記クエリを実行するステップが、
   前記記憶域に対してストアド・プロシージャを実行するステップを含み、
   前記結果を少なくとも前記クエリに基づいて受け取るステップが、
   前記結果を少なくとも前記ストアド・プロシージャに基づいて受け取るステップ
   を含むことを特徴とする請求項１に記載の方法。
7. データ・アクセス価格計算器であって
   １または複数のプロセッサと、
   複数のテーブルに結果を決定するために分析されるデータを含むデータを格納する記憶域に対してクエリを実行するよう構成される、前記１または複数のプロセッサのうち少なくとも１つを用いて実行されるクエリ実行モジュールと、
   前記クエリの実行に応答して受け取られる、結果におけるデータの行数を決定するよう構成される、前記１または複数のプロセッサのうち少なくとも１つを用いて実行される結果行決定モジュールと、
   前記結果内のデータの列数を決定するよう構成される、前記１または複数のプロセッサのうち少なくとも１つを用いて実行される結果列決定モジュールと、
   前記結果にアクセスする前記クエリを発行したユーザに課金すべき価格が、前記結果を決定するために分析されるデータの列数に基づくべき場合に、前記ユーザに課金すべき価格を、前記結果内のデータの行数と、前記結果を決定するために分析されるデータの行数および列数とに基づいて決定するアクセス価格決定モジュールと
   を備えることを特徴とするデータ・アクセス価格計算器。
8. 前記アクセス価格決定モジュールは、さらに、
   前記ユーザに課金すべき価格が、前記結果を決定するために分析されるデータの列数に基づくべきでない場合に、前記ユーザに課金すべき価格を、前記結果内のデータの行数と、前記結果を決定するために分析されるデータの行数とに基づいて決定する、請求項７に記載のデータ・アクセス価格計算器。
9. 前記結果内のデータの列数に対して基本価格を決定するよう構成される基本価格決定モジュールと、
   前記基本価格に加えて課金すべき、前記結果内のデータの少なくとも１つの列に関連付けられたプレミアム価格を決定するよう構成されるプレミアム価格決定モジュールと、
   をさらに備え、
   前記結果にアクセスしたユーザに課金すべき前記価格はさらに前記基本価格と前記プレミアム価格とを考慮している
   ことを特徴とする請求項７に記載のデータ・アクセス価格計算器。
10. 前記記憶域から前記クエリに関する非インラインのクエリ・プランを要求するよう構成されるクエリ・プラン要求モジュールと、
    前記クエリ・プランが前記クエリに関して実行すべき関数を含むと判定するよう構成される関数決定モジュールと、
    前記関数の関数価格を決定するよう構成される関数価格決定モジュールと、
    をさらに備え、
    前記結果にアクセスしたユーザに課金すべき価格はさらに少なくとも前記関数価格に基づいている
    ことを特徴とする請求項７に記載のデータ・アクセス価格計算器。
11. 前記結果にアクセスしたユーザに課金すべき価格を指定する価格インジケータを前記ユーザに提供するよう構成される価格表示モジュール
    をさらに備えることを特徴とする請求項７に記載のデータ・アクセス価格計算器。
12. 前記結果を決定するために分析されるデータは寄与データであり、
    前記結果を決定するために分析されるデータの量は、前記寄与データの行数または列数のうちの少なくとも１つに対応する
    ことを特徴とする請求項１に記載の方法。

Images