特表2024-541021 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ アマデウス　エス．アー．エス．の特許一覧

特表2024-541021商品購入のキーベースの取扱い

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7A
7B
8
9
10
11

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-11-06

(54)【発明の名称】商品購入のキーベースの取扱い

(51)【国際特許分類】

G06F 16/242 20190101AFI20241029BHJP

G06F 16/25 20190101ALI20241029BHJP

G06Q 30/06 20230101ALI20241029BHJP

【ＦＩ】

G06F16/242

G06F16/25

G06Q30/06

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024525125

(86)(22)【出願日】2022-10-21

(85)【翻訳文提出日】2024-05-27

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

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

(87)【国際公開日】2023-05-04

(31)【優先権主張番号】17/510,876

(32)【優先日】2021-10-26

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

２．ＭａｒｉａＤＢ

３．ＣＯＵＣＨＢＡＳＥ

４．ＲＥＤＩＳ

５．ＲＩＡＫ

(71)【出願人】

【識別番号】509228994

【氏名又は名称】アマデウスエス．アー．エス．

【氏名又は名称原語表記】ＡＭＡＤＥＵＳＳ．Ａ．Ｓ．

【住所又は居所原語表記】４８５ＲｏｕｔｅｄｕＰｉｎＭｏｎｔａｒｄ，ＳｏｐｈｉａＡｎｔｉｐｏｌｉｓ，Ｆ－０６４１０Ｂｉｏｔ，Ｆｒａｎｃｅ

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部達彦

(72)【発明者】

【氏名】ヨアン・プラン

(72)【発明者】

【氏名】シャルル・ミシェル・ピエール・ギヨム・クルチエン

(72)【発明者】

【氏名】グレゴリー・ヴァリジアニ

(72)【発明者】

【氏名】ルイージ・ディ・ノーイア

(72)【発明者】

【氏名】フィリップ・サルセイ

【テーマコード（参考）】

5B175

5L030

【Ｆターム（参考）】

5B175CA11

5B175EA03

5B175FB03

5L030BB21

(57)【要約】

商品の購入を取り扱うデータベースシステム、方法、およびコンピュータプログラム製品が提案され、データベースシステムは、複数の商品についてのリレーショナルデータを記憶するリレーショナルデータベースと、複数の第1のファイルおよび複数の第2のファイルを記憶するキーバリューデータベースと、リレーショナルデータベースをキーバリューデータベースと接続するインターフェースモジュールと、キーバリューデータベースと通信する購買エンジンとを備える。インターフェースモジュールは、リレーショナルデータベースに記憶されたリレーショナルデータを第1のファイルおよび第2のファイルへと変換する。購買エンジンは、利用可能性要求に応答して利用可能な商品を取り出すために、キーバリューデータベースに照会する。

【特許請求の範囲】

【請求項1】

商品の購入を取り扱うためのデータベースシステムであって、
複数の商品についてのリレーショナルデータを記憶するリレーショナルデータベースと、
複数の第1のファイルおよび複数の第2のファイルを記憶するキーバリューデータベースであって、前記第1および第2のファイルが前記リレーショナルデータを表し、前記第1のファイルが、前記商品に関連するそれぞれの第1のキーを使用することによってアクセス可能であり、それぞれの少なくとも1つの第2のキーを含み、前記第2のファイルが、前記それぞれの少なくとも1つの第2のキーを使用することによってアクセス可能である、キーバリューデータベースと、
前記リレーショナルデータベースを前記キーバリューデータベースと接続するインターフェースモジュールと、
前記キーバリューデータベースと通信する購買エンジンと
を備え、
前記インターフェースモジュールが、
商品毎に、前記リレーショナルデータベースに記憶された前記リレーショナルデータの少なくとも一部を、前記第1のファイルのうちの1つおよび前記第2のファイルのうちの少なくとも1つへと変換することと、
前記1つの第1のファイルおよび前記少なくとも1つの第2のファイルを前記キーバリューデータベースに記憶することと
を行うように構成され、
前記購買エンジンが、
クライアントデバイスから商品についての利用可能性要求を受け取ることと、
前記商品に関連する第1のキーを使用することによって前記キーバリューデータベースに照会して、前記商品に関連する第1のファイルを取り出すことと、
前記第1のファイルを処理して、少なくとも1つの第2のキーおよび前記少なくとも1つの第2のキーに関連するメタデータを抽出することと、
第2のキー毎に、前記メタデータを前記利用可能性要求と比較して、前記メタデータが前記利用可能性要求を満足する第2のキーを決定することと、
前記利用可能性要求を満足する前記第2のキーのリストを使用することによって前記キーバリューデータベースに照会して、対応する第2のファイルを受け取ることと、
前記第2のファイルからデータを抽出することと、
前記第2のファイルから抽出された前記データを前記クライアントデバイスに送信することと
を行うように構成される、データベースシステム。

【請求項2】

前記インターフェースモジュールが、前記リレーショナルデータベースのツリー構造をフラット化する一方で、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルへと変換するようにさらに構成される、請求項1に記載のデータベースシステム。

【請求項3】

前記インターフェースモジュールが、前記リレーショナルデータにシリアライゼーションプロトコルを適用し、シリアライゼーションしたデータを前記第1のファイルおよび前記第2のファイルに記憶する一方で、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するようにさらに構成される、請求項1に記載のデータベースシステム。

【請求項4】

前記インターフェースモジュールが、前記シリアライゼーションしたデータに圧縮プロトコルを適用する一方で、前記リレーショナルデータを前記第1のファイルおよび前記第2のファイルに変換するようにさらに構成される、請求項3に記載のデータベースシステム。

【請求項5】

前記購買エンジンおよび/または前記インターフェースモジュールが、前記リレーショナルデータのマッピングを対応する前記第1のファイルおよび前記少なくとも1つの第2のファイルに記憶するように構成される、請求項1に記載のデータベースシステム。

【請求項6】

前記インターフェースモジュールが、予め規定された時間間隔で周期的に、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するように構成される、請求項1に記載のデータベースシステム。

【請求項7】

前記インターフェースモジュールが、前記リレーショナルデータの変化に応答して、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するように構成される、請求項1に記載のデータベースシステム。

【請求項8】

前記第1のファイルおよび/または前記第2のファイルが少なくとも1つの第3のキーを含み、前記キーバリューデータベースが第3のファイルをさらに記憶し、前記インターフェースモジュールが、前記リレーショナルデータの一部を少なくとも1つの第3のファイルに変換するようにさらに構成され、前記第3のファイルが前記少なくとも1つの第3のキーを使用することによってアクセス可能である、請求項1に記載のデータベースシステム。

【請求項9】

前記商品の購入が旅行関係商品の予約である、請求項1に記載のデータベースシステム。

【請求項10】

前記インターフェースモジュールが周期合併モジュールを備え、前記周期合併モジュールが、
旅行関係商品の料金の時間依存関係に基づいて、前記旅行関係商品の少なくとも1つの価格の有効期間を決定することと、
前記有効期間内で、前記少なくとも1つの価格の周期性および構造を識別することと、
前記構造のための識別子を作成することと、
前記構造とは別個にそれぞれの識別子とともに前記有効期間を記憶することと
を行うように構成される、請求項9に記載のデータベースシステム。

【請求項11】

データベースシステムにおける商品の購入を取り扱う方法であって、前記データベースシステムが、
複数の商品についてのリレーショナルデータを記憶するリレーショナルデータベースと、
複数の第1のファイルおよび複数の第2のファイルを記憶するキーバリューデータベースであって、前記第1および第2のファイルが前記リレーショナルデータを表し、前記第1のファイルが、前記商品に関連するそれぞれの第1のキーを使用することによってアクセス可能であり、それぞれの少なくとも1つの第2のキーを含み、前記第2のファイルが、前記それぞれの少なくとも1つの第2のキーを使用することによってアクセス可能である、キーバリューデータベースと、
前記リレーショナルデータベースを前記キーバリューデータベースと接続するインターフェースモジュールと、
前記キーバリューデータベースと通信する購買エンジンと
を備え、
前記方法が、
商品毎に、前記リレーショナルデータベースに記憶された前記リレーショナルデータの少なくとも一部を、前記第1のファイルのうちの1つおよび前記第2のファイルのうちの少なくとも1つへと変換するステップと、
前記1つの第1のファイルおよび前記少なくとも1つの第2のファイルを前記キーバリューデータベースに記憶するステップと、
クライアントデバイスから商品についての利用可能性要求を受け取るステップと、
前記商品に関連する第1のキーを使用することによって前記キーバリューデータベースに照会して、前記商品に関連する第1のファイルを取り出すステップと、
前記第1のファイルを処理して、少なくとも1つの第2のキーおよび前記少なくとも1つの第2のキーに関連するメタデータを抽出するステップと、
第2のキー毎に、前記メタデータを前記利用可能性要求と比較して、前記メタデータが前記利用可能性要求を満足する第2のキーを決定するステップと、
前記利用可能性要求を満足する前記第2のキーのリストを使用することによって前記キーバリューデータベースに照会して、対応する第2のファイルを受け取るステップと、
前記第2のファイルからデータを抽出するステップと、
前記第2のファイルから抽出された前記データを前記クライアントデバイスに送信するステップと
を含む、方法。

【請求項12】

前記リレーショナルデータベースのツリー構造をフラット化する一方で、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルへと変換するステップをさらに含む、請求項11に記載の方法。

【請求項13】

前記リレーショナルデータにシリアライゼーションプロトコルを適用し、シリアライゼーションしたデータを前記第1のファイルおよび前記第2のファイルに記憶する一方で、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するステップをさらに含む、請求項11に記載の方法。

【請求項14】

前記シリアライゼーションしたデータに圧縮プロトコルを適用する一方で、前記リレーショナルデータを前記第1のファイルおよび前記第2のファイルに変換するステップをさらに含む、請求項13に記載の方法。

【請求項15】

前記リレーショナルデータのマッピングを対応する前記第1のファイルおよび前記少なくとも1つの第2のファイルに記憶するステップをさらに含む、請求項11に記載の方法。

【請求項16】

予め規定された時間間隔で周期的に、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するステップをさらに含む、請求項11に記載の方法。

【請求項17】

前記リレーショナルデータの変化に応答して、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するステップをさらに含む、請求項11に記載の方法。

【請求項18】

前記第1のファイルおよび/または前記第2のファイルが少なくとも1つの第3のキーを含み、前記キーバリューデータベースが第3のファイルをさらに記憶し、前記方法が前記リレーショナルデータの一部を少なくとも1つの第3のファイルに変換するステップをさらに含み、前記第3のファイルが前記少なくとも1つの第3のキーを使用することによってアクセス可能である、請求項11に記載の方法。

【請求項19】

前記商品の購入が旅行関係商品の予約である、請求項11に記載の方法。

【請求項20】

旅行関係商品の料金の時間依存関係に基づいて、前記旅行関係商品の少なくとも1つの価格の有効期間を決定するステップと、
前記有効期間内で、前記少なくとも1つの価格の周期性および構造を識別するステップと、
前記構造のための識別子を作成するステップと、
前記構造とは別個にそれぞれの識別子とともに前記有効期間を記憶するステップと
をさらに含む、請求項19に記載の方法。

【請求項21】

プログラムコードを記憶する非一時的機械可読媒体であって、コンピュータシステム上で実行されると、前記プログラムコードが、
複数の商品のうちの商品毎に、リレーショナルデータベースに記憶されたリレーショナルデータの少なくとも一部を、複数の第1のファイルのうちの1つおよび複数の第2のファイルのうちの少なくとも1つへと変換するステップであって、前記リレーショナルデータが前記複数の商品に関連する、ステップと、
前記1つの第1のファイルおよび前記少なくとも1つの第2のファイルをキーバリューデータベースに記憶するステップと、
クライアントデバイスから商品についての利用可能性要求を受け取るステップと、
前記商品に関連する第1のキーを使用することによって前記キーバリューデータベースに照会して、前記商品に関連する第1のファイルを取り出すステップと、
前記第1のファイルを処理して、少なくとも1つの第2のキーおよび前記少なくとも1つの第2のキーに関連するメタデータを抽出するステップと、
第2のキー毎に、前記メタデータを前記利用可能性要求と比較して、前記メタデータが前記利用可能性要求を満足する第2のキーを決定するステップと、
前記利用可能性要求を満足する前記第2のキーのリストを使用することによって前記キーバリューデータベースに照会して、対応する第2のファイルを受け取るステップと、
前記第2のファイルからデータを抽出するステップと、
前記第2のファイルから抽出された前記データを前記クライアントデバイスに送信するステップと
を含む方法を実行するように構成される、非一時的機械可読媒体。

【請求項22】

前記方法が、前記リレーショナルデータベースのツリー構造をフラット化する一方で、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルへと変換するステップをさらに含む、請求項21に記載の非一時的機械可読媒体。

【請求項23】

前記方法が、前記リレーショナルデータにシリアライゼーションプロトコルを適用し、シリアライゼーションしたデータを前記第1のファイルおよび前記第2のファイルに記憶する一方で、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するステップをさらに含む、請求項21に記載の非一時的機械可読媒体。

【請求項24】

前記方法が、前記シリアライゼーションしたデータに圧縮プロトコルを適用する一方で、前記リレーショナルデータを前記第1のファイルおよび前記第2のファイルに変換するステップをさらに含む、請求項23に記載の非一時的機械可読媒体。

【請求項25】

前記方法が、前記リレーショナルデータのマッピングを対応する前記第1のファイルおよび前記少なくとも1つの第2のファイルに記憶するステップをさらに含む、請求項21に記載の非一時的機械可読媒体。

【請求項26】

前記方法が、予め規定された時間間隔で周期的に、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するステップをさらに含む、請求項21に記載の非一時的機械可読媒体。

【請求項27】

前記方法が、前記リレーショナルデータの変化に応答して、前記リレーショナルデータを前記第1のファイルおよび前記少なくとも1つの第2のファイルに変換するステップをさらに含む、請求項21に記載の非一時的機械可読媒体。

【請求項28】

【請求項29】

前記商品の購入が旅行関係商品の予約である、請求項21に記載の非一時的機械可読媒体。

【請求項30】

前記方法が、
旅行関係商品の料金の時間依存関係に基づいて、前記旅行関係商品の少なくとも1つの価格の有効期間を決定するステップと、
前記有効期間内で、前記少なくとも1つの価格の周期性および構造を識別するステップと、
前記構造のための識別子を作成するステップと、
前記構造とは別個にそれぞれの識別子とともに前記有効期間を記憶するステップと
をさらに含む、請求項29に記載の非一時的機械可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般的に、大きいデータベースシステムを使用する商品購入のための、コンピュータ化したシステムおよび方法に関する。詳細には、商品購入する間の、変換された商品情報のキーベースのデータ取出しに関する。

【背景技術】

【0002】

世界中で商品を購入できるにつれて、コンピュータ化した商品購入の実装およびサポートは、ますます複雑化しリソース要求が多くなる。商品情報のほとんどは、要求を満たす商品についての情報を受け取って、商品の購入を可能にするように照会される、リレーショナルデータベースシステムに記憶される。

【0003】

たとえば、ホテルの資産管理者は、1つまたは複数のリレーショナルデータベースに接続されたインターフェースを介して、彼らの資産管理システムにホテルの料金を入力する。次いで、旅行者が購買要求を行うと、購買エンジンが1つまたは複数のリレーショナルデータベースにアクセスして、利用可能な料金が得られる。しかし、リレーショナルデータモデルは、通常拡大縮小できない。リレーショナルデータベースは、したがって、秒当たり限られた数の取引を取り扱うことだけができる。そのようなアーキテクチャは、したがって、秒当たりにサポートされる取引の数が通常20程度であるため、6000のホテルおよび多数の同時の購買要求があるホテルチェーンにとって好適でなく、一方で、秒当たり5000の取引が実際には取り扱われるべきである。

【0004】

多くの他の商品カテゴリーの商品購買のコンピュータ化された実装形態は、やはり同様の制約に直面する。というのは、商品管理システムは、原子性、同時並行性、および分離性のために伝統的にリレーショナルデータベースに依拠するためである。

【発明の概要】

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

【0005】

主題の実施形態のいくつかの態様の基本的な理解をもたらすために、以下では、主題の簡単な概要が提示される。この概要は、主題の広範な概観ではない。実施形態のキー/重要要素を識別すること、または、主題の範囲を定めることは意図していない。

【0006】

その唯一の目的は、後で提示されるより詳細な記載に対する前置きとして、簡単な形で主題のいくつかの概念を提示することである。

【0007】

第1の態様によれば、商品の購入を取り扱うデータベースシステムが提供される。データベースシステムは、複数の商品についてのリレーショナルデータを記憶するリレーショナルデータベースと、複数の第1のファイルおよび複数の第2のファイルを記憶するキーバリューデータベースとを備え、第1および第2のファイルがリレーショナルデータを表し、第1のファイルが、商品に関連するそれぞれの第1のキーを使用することによってアクセス可能であり、それぞれの少なくとも1つの第2のキーを含み、第2のファイルが、それぞれの少なくとも1つの第2のキーを使用することによってアクセス可能である。データベースシステムは、リレーショナルデータベースをキーバリューデータベースと接続するインターフェースモジュールと、キーバリューデータベースと通信する購買エンジンとをさらに備える。

【0008】

インターフェースモジュールは、商品毎に、リレーショナルデータベースに記憶されたリレーショナルデータの少なくとも一部を、第1のファイルのうちの1つおよび第2のファイルのうちの少なくとも1つへと変換することと、1つの第1のファイルおよび少なくとも1つの第2のファイルをキーバリューデータベースに記憶することとを行うように構成される。加えて、購買エンジンは、クライアントデバイスから商品についての利用可能性要求を受け取ることと、商品に関連する第1のキーを使用することによってキーバリューデータベースに照会して、商品に関連する第1のファイルを取り出すことと、前記第1のファイルを処理して、少なくとも1つの第2のキーおよび前記少なくとも1つの第2のキーに関連するメタデータを抽出することと、第2のキー毎に、メタデータを利用可能性要求と比較して、メタデータが利用可能性要求を満足する第2のキーを決定することと、利用可能性要求を満足する前記第2のキーのリストを使用することによってキーバリューデータベースに照会して、対応する第2のファイルを受け取ることと、前記第2のファイルからデータを抽出することと、前記第2のファイルから抽出されたデータをクライアントデバイスに送信することとを行うように構成される。

【0009】

第2の態様によれば、データベースシステムにおける商品の購入を取り扱う方法が提供される。方法は、商品毎に、リレーショナルデータベースに記憶されたリレーショナルデータの少なくとも一部を、第1のファイルのうちの1つおよび第2のファイルのうちの少なくとも1つへと変換するステップと、1つの第1のファイルおよび少なくとも1つの第2のファイルをキーバリューデータベースに記憶するステップとを含む。方法は、クライアントデバイスから商品についての利用可能性要求を受け取るステップと、商品に関連する第1のキーを使用することによってキーバリューデータベースに照会して、商品に関連する第1のファイルを取り出すステップと、前記第1のファイルを処理して、少なくとも1つの第2のキーおよび前記少なくとも1つの第2のキーに関連するメタデータを抽出するステップと、第2のキー毎に、メタデータを利用可能性要求と比較して、メタデータが利用可能性要求を満足する第2のキーを決定するステップと、利用可能性要求を満足する前記第2のキーのリストを使用することによってキーバリューデータベースに照会して、対応する第2のファイルを受け取るステップと、前記第2のファイルからデータを抽出するステップと、前記第2のファイルから抽出されたデータをクライアントデバイスに送信するステップとをさらに含む。

【0010】

第3の態様によれば、プログラムコードがその上に記憶される機械可読媒体の形、または、プログラムコードの表現を含む伝播信号の形のいずれかであるコンピュータプログラム製品が提供される。プログラムコードは、コンピュータシステム上で実行されると方法を実行するように配置構成され、ここで方法は、商品毎に、リレーショナルデータベースに記憶されたリレーショナルデータの少なくとも一部を、第1のファイルのうちの1つおよび第2のファイルのうちの少なくとも1つへと変換するステップと、1つの第1のファイルおよび少なくとも1つの第2のファイルをキーバリューデータベースに記憶するステップとを含む。方法は、クライアントデバイスから商品についての利用可能性要求を受け取るステップと、商品に関連する第1のキーを使用することによってキーバリューデータベースに照会して、商品に関連する第1のファイルを取り出すステップと、前記第1のファイルを処理して、少なくとも1つの第2のキーおよび前記少なくとも1つの第2のキーに関連するメタデータを抽出するステップと、第2のキー毎に、メタデータを利用可能性要求と比較して、メタデータが利用可能性要求を満足する第2のキーを決定するステップと、利用可能性要求を満足する前記第2のキーのリストを使用することによってキーバリューデータベースに照会して、対応する第2のファイルを受け取るステップと、前記第2のファイルからデータを抽出するステップと、前記第2のファイルから抽出されたデータをクライアントデバイスに送信するステップとをさらに含む。

【0011】

これらおよび他の目的、実施形態、および利点は、添付図面を参照をして実施形態の以下の詳細な記載から、当業者には容易に明らかとなり、本発明は、任意の特定の実施形態に限定されない。

【0012】

本主題の上述のさらなる目的、特徴、および利点は、添付図面を参照して例示的な実施形態の以下の記載から明らかとなり、ここで、同様の数値は同様の要素を表すために使用される。

【0013】

しかし、参照番号と一緒に添付図面は、単に本主題の典型的な実施形態を説明しており、したがって、主題は、他の等しく効果的な実施形態を認めることができるために、その範囲の限定と考えるべきでないことに留意されたい。

【0014】

したがって、実施形態は、以下の図を参照して記載される。

【図面の簡単な説明】

【0015】

【図1】本発明による商品の購入を取り扱うデータベースシステムを示す図である。

【図2】商品の購入を取り扱うデータベースシステムを示す拡大図である。

【図3】第1および第2のファイルを有するキーバリューデータベースを描く図である。

【図4】リレーショナルデータを第1および第2のファイルに変換するフローチャートである。

【図5】商品購入のための、データ取出しおよび抽出のフローチャートである。

【図6】リレーショナルデータを第1および第2のファイルに変換するためにデータをフラット化する例を示す図である。

【図7A】リレーショナルデータを第1および第2のファイルに変換するためにデータをシリアライゼーションする例を示す図である。

【図7B】リレーショナルデータを第1および第2のファイルに変換するためにデータをシリアライゼーションする例を示す図である。

【図8】第1、第2、および第3のファイルでのデータ取出しの例を示す図である。

【図9】旅行関係商品の購入のための、周期合併モジュールを有する実施形態を描く図である。

【図10】リレーショナルデータを第1および第2のファイルに変換するために有効期間を抽出するフローチャートである。

【図11】本明細書に記載される方法を実装する例示的なコンピューティングマシンの図式表現である。

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

【0016】

図1は、本発明による商品の購入を取り扱うデータベースシステム100を示す。データベースシステム100は、リレーショナルデータベース101およびキーバリューデータベース102、インターフェースモジュール103、ならびに購買エンジン104を備える。

【0017】

リレーショナルデータベース101は、複数の商品についてのリレーショナルデータを記憶する。商品は、同じタイプの、旅行関係商品、食品関係商品、娯楽関係商品などのすべてであってよい。リレーショナルデータベース101は、異なるタイプの商品を記憶することもできる。1つのタイプの商品は、同じサブタイプのものであってもよく、たとえば、リレーショナルデータベース101は、旅行関係商品および特にホテル予約商品を記憶することができる。リレーショナルデータは、多かれ少なかれ購入する商品に応じて、商品の情報、すなわち、詳細な説明、価格、利用可能性、輸送費用、追加予約可能なサービス、製造業者、サービスのエアライン/プロバイダをやはり含む。リレーショナルデータベース101は、Oracle(登録商標)、MySQL(商標)、Microsoft(登録商標)SQL Server、IBM(登録商標)Db2(登録商標)、SQLite、MariaDB、Apache Hive(商標)、または任意の他のリレーショナルデータベースであってよい。

【0018】

キーバリューデータベース102は、複数の第1のファイルおよび複数の第2のファイルを記憶し、第1および第2のファイルは、リレーショナルデータベース101に記憶されるリレーショナルデータを表す。リレーショナルデータベース101に記憶される商品のリレーショナルデータは、キーバリューデータベース102に記憶される、対応する第1および第2のファイルに変換される。キーバリューデータベース102は、Couchbase、LevelDB、Redis、Riak、または任意の他のキーバリューデータベースであってよい。リレーショナルデータベース101ならびにキーバリューデータベースは、局所的に記憶されるデータベースであってよく、または、複数の別個に記憶されるデータベースをやはり備えることができる分散データベースシステムであってよい。

【0019】

インターフェースモジュール103は、リレーショナルデータベース101とキーバリューデータベース102を接続し、リレーショナルデータベース101からのデータをキーバリューデータベース102中のファイルとして記憶されるように変換する変換モジュールである。たとえば、リレーショナルデータベース101は、ホテル予約に関連するデータを保持する。インターフェースモジュール103は、たとえば、毎時、毎日、または任意の他の好適な時間間隔といった、予め規定された時間間隔で周期的に、リレーショナルデータを第1のファイルおよび少なくとも1つの第2のファイルに変換するように構成することができる。

【0020】

購買エンジン104は、キーバリューデータベース102と通信することによる購買プロセスを実行するように構成されるモジュールである。購買エンジン104およびインターフェースモジュールは、同じサーバ、別個のサーバ、クラウド、または任意の他の好適なシステムもしくは場所に記憶することができる。リレーショナルデータベース101、キーバリューデータベース102、インターフェースモジュール103、および購買エンジン104は、ネットワークを介して接続することができる。ネットワークは、ワイドエリアネットワーク、グローバルネットワーク、インターネット、または同様のネットワークであってよく、公共ネットワークまたはプライベートネットワークであってよく、当技術分野で知られているような複数の相互接続ネットワークを含むことができる。

【0021】

図2は、商品の購入を取り扱うデータベースシステム100の拡大図を示しており、ここでは、複数のクライアントデバイス205および複数のプロバイダデバイス206がやはりデータベースシステム100に接続される。

【0022】

クライアントデバイス205は、購買エンジンに接続して、商品を検索および/または購入することができる。たとえば、クライアントデバイス205は、コンピュータ、サーバ、移動局、ラップトップ、スマートフォン、アプリケーション、さらなるデータベースシステムのうちの少なくとも1つを含む。クライアントデバイス205は、要求を購買エンジンに送信し、商品を購入することができる。そのような要求は、一般的に、利用可能な商品が要求されるときの利用可能性要求と呼ぶことができる。しかし、購買エンジン104の具体的な実装に依存して、現在利用不可能な商品は、やはり、情報目的でクライアントデバイス205に戻されてよい。たとえば、クライアントデバイス205は、一部の部屋タイプが要求された具体的なときに利用可能でない場合でさえ、利用可能な要求に応答して、すべての既存のホテルの部屋タイプの情報を取り出すこともできる。

【0023】

プロバイダデバイス206は、リレーショナルデータベース101にさらに接続して、クライアントデバイスに提供するべき商品に関するデータを記憶することができる。プロバイダデバイス206は各々が、クライアントデバイス205が購入することができる1つまたは複数の商品のプロバイダに関連づけることができる。たとえば、プロバイダは、キャリア、レジャー/イベントプロバイダ、または旅行プロバイダ、たとえば、航空会社、ホテルもしくはホテルチェーン、タクシー会社、レンタカー代理店、列車会社、イベント代理店、チケット用プラットフォーム、または、複数の異なるサービスを取り扱い提供するメタ代理店であってよい。追加または代替として、プロバイダは、携帯電話事業者、ネットワーク事業者、倉庫、買物チェーンなどであってもよい。

【0024】

クライアントデバイス205およびプロバイダデバイス206は、ネットワークを介してデータベースシステム100に接続することができ、ネットワークは、ワイドエリアネットワーク、グローバルネットワーク、インターネット、または同様のネットワークであってよく、公共ネットワークまたはプライベートネットワークであってよく、当技術分野で知られているような複数の相互接続ネットワークを含むことができる。プロバイダデバイス206は、それによって、リレーショナルデータベース101に直接接続すること、または、インターフェースもしくは他の追加モジュール(図示せず)を介して接続することができる。

【0025】

プロバイダは、たとえば、所与のリレーショナルデータベース方式による、ツリー構造で、リレーショナルデータベース101中のクライアントに提供するべき商品のデータを記憶することができる。たとえば、商品がアパートまたはホテルの部屋である場合、すべての特性を含む、すなわち、すべてのホテルが提供する部屋についてのエントリーを含むリレーショナルデータベース101中の表が存在してよい。表は、都市名コード、国コード、名前、チェーンなどといった、ホテルの異なる特徴のためのカラムを有することができる。別の表が、たとえば設備および眺望タイプなどといった情報を有する部屋のタイプについての情報を保持することができ、別の表が、料金プランについての情報を保持することができ、別の表が、姿を見せないときまたはキャンセルするときのルールについての情報を保持することができる、などである。したがって、最終的な商品、一例では、ホテルの部屋のこうした最終的な商品を、ツリー構造で規定する複数の表が存在する。ホテルの部屋の例で、リレーショナルデータベース101は、少なくとも、Table 1(表1)に示されるデータベースの表を記憶することができる。

【0026】

【表1】

【0027】

料金プランは、それが価格すなわちホテルの部屋の料金を識別するときに、最終的な商品を計算するための主要な要素である。ホテルの部屋の料金およびホテルの部屋の特徴のリストは、顧客に販売される提供事項を構成する。したがって、RatePlanという表は、所与の特性についてのすべての料金プランのリストを含む。PriceGridという表は、価格のためのパラメータおよび額のルールに対する参照を含む。AmountRuleという表は、価格を計算するためのルールを規定しており、この表は、とりわけ額(固定した額または百分率のような相対的額)およびこの額が適用可能な日付周期を含む。複数の額のルールによって、異なる周期および異なる商品をカバーさせる。価格グリッドは、異なる価格を作成するために組み合わせることができる。たとえば、第1の価格グリッドPG1が固定した額、たとえば500USDを含み、別の価格グリッドPG2が相対的額、たとえば-10%を含むと考える。価格グリッドPG1がPG2にリンクされる場合、結果として得られる価格は、450USDである。

【0028】

ポリシー表は、販売条件を含む。ハウスポリシーは、具体的なホテルおよび所与の時間の周期について規定される販売条件である。他のポリシー表は、所与の料金プランについての販売条件を指定する。税金は、TaxRuleおよびTaxという2つの表を使用して規定される。これらの2つの表は、他の税金を参照して、複雑な税金スキーマを作成することができる。料金プランは、制約がない、または1つまたは複数の制約を有する場合がある。NoArrivalRuleという表は、チェックイン日が具体的な日の前である場合に、この料金の使用を禁止する制約を規定し、NoStayRuleという表は、チェックインが具体的な周期内であるときに、この料金を禁止する制約を規定する。HurdlePoint表という表は、計算された価格が特定の額より低い場合に利用可能でないとき、料金プランを設定しなければならない場合に、さらに指定される。

【0029】

図3は、複数の第1のファイル310および複数の第2のファイル320を有するキーバリューデータベース102を描く。第1のファイル310はそれぞれの第1のキー311を使用することによってアクセス可能であり、第1のキー311は、第1のファイル310からデータを得るためのそれぞれ固有の識別子を規定する。第2のファイル320はそれぞれの第2のキー321、322を使用することによってアクセス可能であり、第2のキー321、322は、それぞれの第2のファイル320に固有のそれぞれの識別子を規定する。したがって、各第1のファイル310または第2のファイル320は、それぞれ第1のファイル310または第2のファイル320にアクセスするのに必要な、特定の固有キー311、321、322に関連づけられる。第1のキー311は、リレーショナルデータベース101に記憶され、キーバリューデータベース102中にその固有キーを有する特定の商品、たとえば各商品に関連づけられ、このことによって、商品に関連づけられる第1のファイル310にアクセスすることが可能になる。

【0030】

第1のファイル310のうちの任意の1つは、その値部分に、少なくとも1つの第2のキー321、322を含む。第1のファイル310に含まれる少なくとも1つの第2のキー321、322は、第2のファイル320にアクセスするために使用することができる。図3の例では、第1のファイル310に記憶される第2のキー321は、(点線323によって示される)第2のキー321と同一であり、第1のファイル310に記憶される第2のキー322は、(点線324によって示される)第2のキー322と同一である。したがって、第1のファイル310に記憶される第2のキー321、322に基づいて、第1のファイル310に記憶される商品に関連するデータの効率的な取出しを達成することができる。

【0031】

第1のファイル310および少なくとも1つの第2のファイル320を有し、第1のファイル310が少なくとも1つの第2のファイル320にアクセスするための第2のキー321、322を備える手法は、データ取出し時間とデータ処理時間の間の技術的最適条件に基づく。たとえば、ホテルのすべての部屋についてのあらゆる要求される情報などといった、具体的な商品または商品シリーズに関係するすべてのデータが第1のファイル310に含まれる場合、データ取出し時間は、ただ1つの単一ファイル、すなわち第1のファイル310がアクセスされなければならないとき、短くなる。しかし、かなりのサイズをさらに有することになる第1のファイル310から関連データを抽出および処理する時間は、許容できる応答時間をはるかに超えることになる。したがって、要求に答えるとき、第1のファイル310および複数の第2のファイル320中のデータを分割し、第1のファイル310から関連する第2のキー321、322を選択し、それぞれの第2のファイル320から関連するデータを取り出すことだけによって、データ取出しおよびデータ処理時間の最適条件を達成することができる。

【0032】

ホテルの部屋の例では、第1のファイル310は、複数のホテルの部屋を備えるホテルについての基本情報を含むことができる。たとえば、第1のファイル310は、情報の2つの異なる部分からなる特性レベルデータを含むことができる。第1の部分は、料金プラン情報部分であってよく、第2の部分はパリティグループ情報部分であってよい。

【0033】

料金プラン情報部分は、特性で分散されるすべての料金プランのリスト、および、各料金プランについてのすべての可能な部屋タイプのリストを記憶することができる。料金プラン情報部分は、結果をフィルタ処理することおよび/またはアクセスを加速することを可能にするため、第2のファイル320から複製されたデータをやはり含むことができる。たとえば、第1のファイル310は、最終的な候補に適用不可能な料金プランを取り除くことを可能にするために、料金プランが適用可能なとき、たとえば、販売日および/または滞在日の最後または始めを規定する、リスト化した料金プラン専用のメタ情報を含むことができる。パリティグループ情報部分は、料金プランの依存関係を記憶することができる。たとえば、パリティグループ情報は、他のものに依存する料金のグループを記載する。たとえば、料金B、C、およびDが料金Aに依存し、そのため、料金Aが利用可能でない場合、料金B、C、およびDは、やはり利用可能でない。

【0034】

特性レベルデータと同様に、第2のファイル320は料金プランデータを含む。料金プランは、典型的には、取引を考慮したカレンダーの周期に基づいた、料金プランに適用可能な条件付けルールを有する。これらのルールは、次いで、第2のファイル320に記憶される。さらに、第2のファイル320は、提供事項を予約するのを可能にするため顧客が満足させなければならない最小要件もしくは条件、または、顧客がこれらのルールを満足させなかった場合の罰則&手数料を記載するポリシーを記憶することもできる。さらに、第2のファイル320は、たとえば、価格グリッドのコード、価格グリッドのタイプなどといった価格グリッドについてのデータを含む価格グリッドデータ、および商品の実際の価格を規定する額ルールデータを含むこともできる。

【0035】

第1のファイル310および第2のファイル320がキーバリューデータベース102に記憶される2レベルファイル構造への、ホテルの部屋情報のこうした具体的な分散および再編成によって、購買要求への応答時間が著しく短くなる。たとえば、購買/検索要求に必要なすべてのデータがリレーショナルデータベース101から取り出される場合、応答時間が約500ms以上であると期待される。同じ購買/検索要求のためであるが、上で記載されたようなキーバリューデータベース102中の2レベルファイル構造を使用すると、応答時間は、おそらく50ms未満となり、80msを超えることが全くない可能性がある。リレーショナルデータベース101により多くのデータが記憶されると、記載されるキーバリューデータベース102中の2レベルファイル構造を適用するときの応答時間の節約がより大きくなる。

【0036】

上の記載から当業者には明らかとなるように、リレーショナルデータベース101とキーバリューデータベース102に記憶されるデータは互いに対応する。したがって、図4に示されるように、リレーショナルデータとキーバリューデータの間でデータ変換が要求される。

【0037】

インターフェースモジュール103は、したがって、2段階変換プロセスを実施する。インターフェースモジュール103は、予め規定された時間間隔で周期的に、リレーショナルデータを第1のファイル310および第2のファイル320に変換することができる。あるいは、リレーショナルデータベース101中のデータの変化に応じてリレーショナルデータを変換することができる。

【0038】

ボックス401に示されるように、商品のリレーショナルデータの部分は、第1のファイル310などの第1のファイルへと変換および記憶される。第1のファイル310が特性データを記憶するホテルの部屋の例では、特性に関係するデータは、リレーショナルデータベース101から、特に少なくともRatePlanという表から抽出されるが、いくつかの実施形態では、他の表からも抽出される。ボックス402に示されるように、商品のリレーショナルデータの部分は、第2のファイル320などの第2のファイルへとさらに変換および記憶される。いくつかの実施形態では、第2のファイル320に記憶されるデータの少なくとも部分が第1のファイル310に複製される。ホテルの例では、第1のファイル310と第2のファイル320の両方が、AmountRuleという表から抽出された情報を含むことができる。

【0039】

第1のファイル310および第2のファイル320は、同じデータ形式で記憶することができる。代わりの実施形態では、第1のファイル310と第2のファイル320のデータ形式が異なってよい。第1のファイル310および/または第2のファイル320のデータ形式は、JSON (JavaScript Object Notation)、HTML (Hypertext Markup Language)、または任意の他の好適なデータ形式であってよい。

【0040】

リレーショナルデータベース101のデータからキーバリューデータベース102に記憶されるファイルへの変換は、したがって、フラット化プロセスを含むことができ、ここで、リレーショナルデータベース101に含まれるデータは、第1のファイル310および第2のファイル320に記憶される。フラット化プロセスは、さらなる計算を含むこともできる。ホテルの部屋の例では、第2のファイル320中に、価格グリッドについてのすべての情報、たとえば、一般的な価格グリッド情報およびカレンダーの周期毎の額ルールを記憶すること以外に、第2のファイル320は、依存関係のツリーを取り出して解決することにより、商品の最終的な額を含むこともできる。したがって、図4に描かれるような変換プロセスによって、階層化機能構造がもたらされ、その結果、各第2のファイルの核となる情報が上層に記憶される。このことによって、利用可能性要求を満足する第2のファイル320だけがアクセスされるため、商品購入のためのデータを取り出して抽出すると、データの効率的なフィルタ処理によってデータの効率的な取出しがもたらされることが可能になる。

【0041】

商品購入のためのデータを取り出して抽出することは、図5のフローチャートに示される活動を含む。購買エンジン104は、ボックス501で、クライアントデバイス205から商品の利用可能性要求を受け取る。利用可能性要求は、クライアントが購入を希望する商品の情報を含むことができる。たとえば、利用可能性要求は、クライアントがホテルの部屋を探す場合、到着日および出発日ならびに都市/場所を含むことができる。

【0042】

次に、ボックス502に描かれるように、商品に関連する第1のファイル310を取り出すため商品に関連する第1のキー311を使用することによって、キーバリューデータベース102が(たとえばインターフェースモジュール103によって)照会される。実施形態では、第1のキー311を、利用可能性クエリが含むこと、すなわち、クライアントが入力することができ、または、リレーショナルデータベース101または任意の他のリモートもしくはローカル記憶装置であってよいデータベースに、事前処理クエリを通して、購買エンジン104が取り出すことができる。事前処理クエリは、たとえば、利用可能性要求を満足するすべての第1のキー311を要求することができる。ホテルの部屋の例では、購買エンジン104は、たとえば、利用可能性要求に含まれる都市に位置するすべてのホテルといった、場所の観点で、利用可能性要求を満足する特性のすべての固有識別番号、すなわちこの例では第1のキー311を取り出すことができる。別の例では、利用可能性要求が専用の要求、すなわち、指定された特性の部屋の利用可能性についての要求である場合、第1のキー311は、特性名の固有識別番号へのマッピングによって取り出すことができる。

【0043】

第1のキー311を使用することによって、それぞれの第1のファイル310にアクセスすることができる。第1のファイル310は、次いで、少なくとも1つの第2のキー321、322ならびにメタデータを抽出するように処理される。これは、ボックス503に示される。メタデータとは、たとえば、どの第2のファイル320が利用可能性要求を満足するか、または言い換えると利用可能性要求に当てはまるかをインターフェースモジュール103が決定することが可能になるデータである。ホテルの部屋の例では、メタデータは、上で述べられたメタ情報に対応する。したがって、メタデータは、利用可能性要求に対して料金プランが適用可能か否かの情報を含む。したがって、メタデータは、第2のキー321、322毎に利用可能性要求と比較され、メタデータが利用可能性要求を満足する第2のキー321、322を決定する(ボックス504に描かれる)。

【0044】

それらの決定された第2のキー321、322について、キーバリューデータベース102が照会され、ボックス505に示される。これは、利用可能性要求を満足する前記第2のキー321、322のリストを使用することによって行うことができ、対応する少なくとも1つの第2のファイル320を受け取る結果となる。ボックス506では、前記少なくとも1つの第2のファイル320からデータが抽出されて、最終的な商品を構築する。ホテルの部屋の例では、各料金プランについて第2のファイル320に記憶されるそれぞれの条件および価格が取り出され、第1のファイル310の情報と組み合わされて、要求しているクライアントが予約するために利用可能な、少なくとも1つの最終的なホテルの部屋の商品を構築する。提供するべき最終的な商品に対応する抽出されたデータは、次いで、要求しているクライアントデバイスに送信され、これが最後のボックス507によって示される。

【0045】

本方法は、実時間データ取出しを容易にする。提案されるシステムは、短応答時間で高度な利用可能なサービスを可能にする。リレーショナルデータベースを採用する従来型システムは、利用可能な商品を取り出すためデータベースに膨大な数のジョイントクエリを要求する。提案されるシステムでは、データ取出しは、要求される特性に関係する1つの第1のファイル310および要求を満足する料金プランの数に依存するN個の第2のファイル320の取出しだけを要求する。したがって、応答時間を80ms以下に減らすことができる。

【0046】

図6は、リレーショナルデータを第1のファイル310および第2のファイル320に変換するためにデータをフラット化する例を示す。左側601では、リレーショナルデータベース101に記憶されるリレーショナルデータのツリー構造が描かれる。たとえば、ホテルの部屋の実施形態で説明すると、2つの料金プランを提供する1つの特性が存在する場合がある。1つの料金プランは、ある種の条件下でのみ適用可能な3つの依存関係のある料金プランを有する。他の料金プランは、予約が行われる場合に満足することができる2つのさらなるルールを有する。ツリー構造は、次いで、インターフェースモジュール103によって、右側602の複数の第1のファイル310および第2のファイル320に変換される。

【0047】

図7Aおよび図7Bは、リレーショナルデータを第1のファイル310および第2のファイル320に変換するためにデータをシリアライゼーションする例を示す。図7Aでは、リレーショナルデータベース101からのリレーショナルデータは、インターフェースモジュール103を介して、キーバリューデータベース102に記憶されるデータファイルに変換される。この実施形態では、インターフェースモジュール103は、リレーショナルデータにシリアライゼーションプロトコル733を適用し、シリアライゼーションしたデータを第1のファイル310および第2のファイル320に記憶する。シリアライゼーションプロトコルを使用して、リレーショナルデータベース101のデータ構造が、より効率的に記憶できる(必要なメモリがより少ない)データ構造に変形され、元のデータと意味的に同一なクローンを構成する。シリアライゼーションプロトコルは、たとえば、Google Protobufシリアライゼーションプロトコル、Hessian 2.0シリアライゼーションプロトコル、Redisシリアライゼーションプロトコル、または任意の他の好適なプロトコルであってよい。シリアライゼーションは、一般的に、プロトコルバッファまたはフラットバッファを使用することによって達成することができる。

【0048】

図7Bでは、インターフェースモジュール103は、シリアライゼーションしたデータに圧縮プロトコル734をさらに適用する。シリアライゼーションしたデータに圧縮プロトコルを適用することによって、第1のファイル310および第2のファイル320の効率的な記憶が可能になる。圧縮プロトコルは、たとえば、IP(インターネットプロトコル)Payload圧縮プロトコル、Snappy圧縮プロトコル、または任意の他の好適なプロトコルであってよい。

【0049】

図8は、3つのファイルの層がキーバリューデータベース102に記憶される実施形態を示す。したがって、第1のファイル310は、少なくとも1つの第2のファイル320の少なくとも1つの第2のキー321を含む。第2のファイル320は、次いで、少なくとも1つの第3のファイル830の少なくとも1つの第3のキー831を含む。もちろん、4つ以上のファイルの層も、必要な場合には可能である。

【0050】

図9は、旅行関係商品の購入のためのさらなる実施形態を描く。旅行関係商品の価格は、通常ではそれらが適用される時間間隔に依存する。したがって、インターフェースモジュール103は、周期合併モジュール935をさらに備える。リレーショナルデータベース101に記憶されるリレーショナルデータを変換するとき、インターフェースモジュール103が備える周期合併モジュール935は、価格構造のそのような時間間隔を識別し、価格構造および時間間隔を反映するキーバリューデータベース102の第1のファイル310および/または第2のファイル320中にエントリーを作成する。

【0051】

周期合併モジュール935のワークフローが、図10のフローチャートに描かれる。周期合併モジュール935は、旅行関係商品の料金の時間依存関係に基づいて、旅行関係商品の少なくとも1つの価格の有効期間、すなわち、価格が適用される時間期間を決定する。これは、ボックス1001に示される。たとえば、周期合併モジュール935が、リレーショナルデータベース101に記憶されるデータを分析する。すべての価格グリッドについて、価格が時間依存性であるかが分析される。その場合、有効期間が決定される。

【0052】

その後、周期合併モジュール935は、有効期間内で、もしも存在するなら、少なくとも1つの価格の周期性および構造を識別する(ボックス1002)。たとえば、価格が週末だけに適用される場合、周期性は、週単位となり、有効期間は2日間となる。さらに、価格の構造は、額であるが子どもまたは老人専用、遅い到着との組合せのみなどといった、価格に適用される条件であってもよい。

【0053】

ボックス1003では、周期合併モジュール935が、構造についての識別子、すなわち、特定の価格構造についての固有識別子を作成する。次いでこの識別子は、たとえば第1のファイル310の中に、それぞれの有効期間とともに記憶される。第2のファイル320は、次いで、特定の価格の構造を記憶することができる。これは、ボックス1004に描かれる。特定の構造とは別個に有効期間を記憶することによって、複数の有効期間を1つの構造用に規定することができる。

【0054】

別の実施形態では、命令を含むコンピュータプログラム製品が提供される。これらの命令は、プログラムがコンピュータに実行されると、本明細書に記載されるような方法をコンピュータに実行させる。本明細書に記載されるアプリケーション/モジュールのいずれかで具体化されるプログラムコードは、種々の異なる形式でプログラム製品として別個にまたは集合的に供給することが可能である。特に、プログラムコードは、プロセッサに本発明の実施形態の態様を実行させるために、その上にコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体を使用して供給することができる。

【0055】

本質的に非一時的なコンピュータ可読記憶媒体としては、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどといった情報の記憶のために、任意の方法または技術で実装される、揮発性および不揮発性、ならびに、取外し可能および取外し不可能な有形媒体が挙げられ得る。コンピュータ可読記憶媒体としては、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、消去可能プログラム可能読取り専用メモリ(EPROM)、電気的消去可能プログラム可能読取り専用メモリ(EEPROM)、フラッシュメモリもしくは他の固体メモリ技術、携帯型コンパクトディスク読取り専用メモリ(CD-ROM)、または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、所望の情報を記憶するために使用することができコンピュータが読み取ることができる任意の他の媒体がさらに挙げられ得る。

【0056】

コンピュータ可読記憶媒体は、一過性の信号自体(たとえば、電波もしくは他の伝播する電磁波、導波路などの伝達媒体を通って伝播する電磁波、または、ワイヤを通って伝達される電気信号)とみなすべきでない。コンピュータ可読プログラム命令は、コンピュータ可読記憶媒体から、コンピュータ、別のタイプのプログラム可能データ処理装置、もしくは別のデバイスに、または、ネットワークを介して外部コンピュータもしくは外部記憶デバイスにダウンロードすることができる。

【0057】

図11は、本明細書に記載される方法の少なくとも部分を実装する例示的なコンピューティングマシン1100の図式表現である。同様のコンピューティングマシンが、上で記載した、モジュール/インターフェース103、104、クライアントデバイス205および/またはプロバイダデバイス206、ならびにデータベース101、102のうちの1つまたは複数をやはり実現することができる。コンピューティングマシン1100は、コンピューティングマシン1100によって実行されると本明細書で議論した方法のいずれかをコンピューティングマシン1100に実施させる命令の組を含む。

【0058】

コンピューティングマシン1100は、バス1104を介して互いと通信する、少なくとも1つのプロセッサ1101、メインメモリ1106、およびネットワークインターフェースデバイス1103を含む。任意選択で、コンピューティングマシン1100は、スタティックメモリ1105およびディスク駆動ユニットをさらに含むことができる。ビデオディスプレイ、英数字入力デバイス、およびカーソル制御デバイスを、ユーザインターフェース1102の例として設けることができる。ネットワークインターフェースデバイス1103は、コンピューティングマシン1100を上で記載した他の構成要素のいずれかに接続する。

【0059】

コンピューティングマシン1100は、メインメモリ、ランダムアクセスメモリ(RAM)および/または任意のさらなる揮発性メモリなどといったメモリ1106を含む。メモリ1106は、データベースシステム100の機能性を円滑にするため、一時データおよびプログラムデータを記憶することができる。メモリ106は、データベース101、102から最近取り出したデータを記憶する1つまたは複数のキャッシュ1107を備えることもできる。キャッシュは、レベル1(L1)キャッシュ、レベル2(L2)キャッシュ、および/またはレベル3(L3)キャッシュであってよい。メモリ1106は、上で記載したような方法を実施するため、コンピュータプログラムデータ1108を記憶することもできる。

【0060】

本明細書に記載される方法のいずれか1つまたはすべてを具体化するコンピュータ実行可能命令の組(コンピュータプログラムコード1108)は、たとえばメモリ1106といった、機械可読記憶媒体の中または上に、完全に、または少なくとも部分的に常駐する。命令1108は、さらに、ネットワークインターフェースデバイス1103を通してインターネットを介して、またはユーザインターフェース1102を介して、伝播される信号として送信または受信することができる。コンピューティングマシンとの通信は、バス1104を介して実施される。コンピューティングマシン1100の基本動作は、やはりメモリ1106、少なくとも1つのプロセッサ1101、および/またはスタティックメモリ1105中に配置されるオペレーティングシステムによって制御される。

【0061】

本発明の具体的な実施形態および変形形態が本明細書に記載されてきた一方で、関連技術の当業者には、さらなる修正形態および代替形態が明らかになることを理解するべきである。特に、本発明の原理を説明するため、および、それらの原理を実施するためにいくつかの具体的な方法および配置構成を提供するため、例が提供される。

【0062】

したがって、記載される実施形態は、本発明の一般的な特徴および原理の教示のために、例として提供されると理解するべきであるが、添付される特許請求の範囲に規定されるような本発明の範囲を制限するものと理解するべきではない。

【符号の説明】

【0063】

100 データベースシステム
101 リレーショナルデータベース
102 キーバリューデータベース
103 インターフェースモジュール、モジュール/インターフェース
104 購買エンジン、モジュール/インターフェース
205 クライアントデバイス
206 プロバイダデバイス
310 第1のファイル
311 第1のキー、固有キー
320 第2のファイル
321 第2のキー、固有キー
322 第2のキー、固有キー
323 点線
324 点線
733 シリアライゼーションプロトコル
734 圧縮プロトコル
830 第3のファイル
831 第3のキー
935 周期合併モジュール
1100 コンピューティングマシン
1101 プロセッサ
1102 ユーザインターフェース
1103 ネットワークインターフェースデバイス
1104 バス
1105 スタティックメモリ
1106 メインメモリ
1107 キャッシュ
1108 コンピュータプログラムデータ、コンピュータプログラムコード、命令

【図1】