JP7368531B2 - ブロックチェーンに基づく部屋在庫管理システム - Google Patents

Description

本発明は、部屋在庫管理システムに関し、より具体的には、ブロックチェーンに基づく部屋在庫管理システムに関する。

部屋の予約はホテルまたは旅行代理店（トラベルエージェンシー）にとって重要なサービスである。従来（Ｃｏｎｖｅｎｔｉｏｎａｌ）の部屋予約サービスにおいて、ブッキングエンジン（Ｂｏｏｋｉｎｇ ｅｎｇｉｎｅ）またはオンライントラベルエージェンシー（ＯＴＡ）はホテルを代理して、予定した時刻でホテルの空き部屋を予約するための遠隔ユーザインタフェースを顧客に提供する。

ＯＴＡとは、顧客への、ホテル部屋予約などの旅行商品の販売に特化した旅行ウェブサイトを指す。ＯＴＡは、部屋の予約を再販売するための、部屋提供者（例えば、ホテル）とのオンライン代理契約を有する。そのような条件の下で、ＯＴＡは、少なくとも１つの空き部屋を予約する顧客から代金を貰い、ホテルに卸し価格を支払う。

ホテルの部屋予約のためのブッキングエンジンとは、顧客が空き部屋を予約できるようにするウェブサイトを指す。ブッキングエンジンは、部屋予約にあたってより容易に決定できるよう、カスタマイズされた価格および／または支払いルールを顧客に紹介してもよい。

しかしながら、短期間のうちに複数の顧客がホテルの同一の空き部屋を予約するために遠隔ユーザインタフェースにログインする場合、オーバーブッキングが発生しやすい。オーバーブッキングは顧客およびホテルの両方に著しい損失をもたらす。例えば、オーバーブッキングは、追加の部屋、サービス、および／または補償の手配でホテルを煩わせる。また、オーバーブッキングは、限られた時間内で顧客にその旅行計画の変更を強いてしまい、顧客の旅行体験を損なう。このような不便は、旅行の混雑期により頻発し、深刻化する。それでも、ホテルは、現行のＯＴＡおよび／またはブッキングエンジンによるオーバーブッキングを処理する技術で制限を受ける。そのため、技術的な解決策を介して効率的にオーバーブッキングを和らげる必要がある。

本文献は、ブロックチェーンに基づく部屋在庫管理システムを管理する方法を開示する。当該方法は、ホテル部屋在庫システムにおける複数のノードの各ノード内に、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持するステップであり、ブロックチェーンは、時間順に単独にリンクされる複数のブロックを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、所与のホテル部屋品目に関する成立した取引を記憶する、ステップと；ホテル部屋在庫システムに通信上結合されたコンピュータネットワークから部屋予約イベントを受信すると、複数のノードの中のマスタノードにより、部屋予約イベントを表す新しい取引をブロックチェーンに記憶されるスマートコントラクトにサブミットすることによって、部屋予約イベントが成立可能かどうかを判断するステップであり、スマートコントラクトは、所与のホテル部屋品目の現在の数量残高に基づいて、サブミットされた取引が、所与のホテル部屋品目に関するブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含む、ステップと；スマートコントラクトに基づいて、部屋予約イベントを表す新しい取引が成立可能であると判断すると、マスタノードにより、ブロックチェーンに付加される新しいブロックを作成するステップであり、新しいブロックは、新しい取引を成立として表すデータを記憶し、上記新しいブロックの作成は、ホテル部屋在庫システムにおける複数のノードの各ノード内のブロックチェーンに新しいブロックを追加させる、ステップと；スマートコントラクトにより、所定の変動ルールに基づいて、部屋予約イベントが所定の変動ルールを満たす現在の数量残高をもたらしたとき、所与のホテル部屋品目の市場価格を自動的に調整するステップと、を含む。

本文献は、ブロックチェーンに基づくホテル部屋在庫システムをさらに開示する。当該システムは、複数のノードであり、複数のノードの各ノードは、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持するように構成され、ブロックチェーンは、時間順に単独にリンクされる複数のブロックを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、所与のホテル部屋品目に関する成立した取引を記憶する、複数のノードと；ブロックチェーンに記憶されるスマートコントラクトであり、スマートコントラクトは、所与のホテル部屋品目の現在の数量残高に基づいて、サブミットされた取引が、所与のホテル部屋品目に関するブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含む、スマートコントラクトと；マスタノードであり、ホテル部屋在庫システムに通信上結合されたコンピュータネットワークから部屋予約イベントを受信し、部屋予約イベントを表す新しい取引をスマートコントラクトにサブミットすることによって、部屋予約イベントが成立可能かどうかを判断し、スマートコントラクトに基づいて、部屋予約イベントを表す新しい取引が成立可能であると判断すると、ブロックチェーンに付加される新しいブロックを作成し、新しいブロックは、新しい取引を成立として表すデータを記憶する、ように構成され、上記新しいブロックの作成は、ホテル部屋在庫システムにおける複数のノードの各ノード内のブロックチェーンに新しいブロックを追加させる、マスタノードと；を含み、スマートコントラクトは、所定の変動ルールに基づいて、部屋予約イベントが、現在の数量残高または予約時間の期間を含む所定の変動ルールを満たす現在の数量残高をもたらしたとき、所与のホテル部屋品目の市場価格を自動的に調整する。

本文献は、複数の命令を含む非一時的コンピュータ読取可能媒体をさらに開示し、複数の命令は、コンピュータ化されたホテル部屋在庫システムの１つ以上のプロセッサにより実行されると、システムに：ホテル部屋在庫システムにおける複数のノードの各ノード内に、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持し、ブロックチェーンは、時間順に単独にリンクされる複数のブロックを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、所与のホテル部屋品目に関する成立した取引を記憶し；ホテル部屋在庫システムに通信上結合されたコンピュータネットワークから部屋予約イベントを受信すると、複数のノードの中のマスタノードにより、部屋予約イベントを表す新しい取引をブロックチェーンに記憶されるスマートコントラクトにサブミットすることによって、部屋予約イベントが成立可能かどうかを判断し、スマートコントラクトは、所与のホテル部屋品目の現在の数量残高に基づいて、サブミットされた取引が、所与のホテル部屋品目に関するブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含み、スマートコントラクトは、所与のホテル部屋品目のホテル位置、所与のホテル部屋品目の部屋タイプ、および／または所与のホテル部屋品目に関する部屋予約イベントの時間範囲にさらに基づいて衝突を判断するように構成され；スマートコントラクトに基づいて、部屋予約イベントを表す新しい取引が成立可能であると判断すると、マスタノードにより、ブロックチェーンに付加される新しいブロックを作成し、新しいブロックは、新しい取引を成立として表すデータを記憶し、上記新しいブロックの作成は、ホテル部屋在庫システムにおける複数のノードの各ノード内のブロックチェーンに新しいブロックを追加させる；ことをさせ、スマートコントラクトは、所定の変動ルールに基づいて、部屋予約イベントが、現在の数量残高または予約時間の期間を含む所定の変動ルールを満たす現在の数量残高をもたらしたとき、所与のホテル部屋品目の市場価格を自動的に調整する。

前述した概要、および本発明についての以下の詳細な説明は、添付図面と併せて読むことより、よく理解されるであろう。本発明を説明するために、現に好ましい実施例が図面に示されている。しかしながら、本発明は示された精確な配置および手段に限定されないことが理解されるべきである。

従来の部屋在庫管理システムが、部屋を予約する顧客のためにどのようにＯＴＡモジュールおよび／またはブッキングエンジンと協働するかを示す図 本発明の１つの実施例に基づく、ブロックチェーンに基づく部屋在庫管理システムを示す図 図２に示された部屋在庫管理システムのホストメモリ、中間メモリ、およびノードメモリの部屋在庫記録の間のデータ交換に関する略図 図２に示された部屋在庫管理システムの中間プロセッサがどのように新しいブロックを生成するかを示す図 本発明の１つの実施例に基づいて、マスタサーバの責務をノードサーバに移転する、ブロックチェーンに基づく部屋在庫管理システムを示す図 図５に示された部屋在庫管理システムのホストメモリ、一時的なマスタノードメモリ、および他のノードメモリの部屋在庫記録の間のデータ交換に関する略図 図５に示された部屋在庫管理システムの一時的なマスタプロセッサがどのように新しいブロックを生成するかを示す図 本発明のブロックチェーンに基づく部屋在庫管理システムを管理する方法のフローチャートを示す図 本発明の動的価格設定のフローチャートを示す図

添付図面に示された発明の実施例に対する参照は細かく行われる。可能な限り、同様な参照番号は全図面にわたって同様または類似の部分に振られている。

＜従来（Ｃｏｎｖｅｎｔｉｏｎａｌ）の部屋在庫管理システムの構造＞

図１は、従来の部屋在庫管理システム１００が、部屋在庫管理システム１００とＯＴＡモジュールおよび／またはブッキングエンジンとの間に接続され、かつホテルの制御下にある中間チャネル管理機１５０を介して、顧客のためにどのようにＯＴＡモジュールおよび／またはブッキングエンジンと協働して部屋を予約するかを示す。例示的に、部屋在庫管理システム１００は、Ｍ個のＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭ、および／またはＮ個のブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮと協働する。ここでＭおよびＮは正の整数である。少なくとも１つの前述したＯＴＡモジュールおよび／またはブッキングエンジンは少なくとも１つのグローバルディストリビューションシステム（ＧＤＳ）および／または少なくとも１つのメタサーチエンジンに替えてもよいことが注意されるべきである。ただ、ＧＤＳおよびメタサーチエンジンなどを利用するときのホテルのコストは、ＯＴＡモジュールおよび／またはブッキングエンジンからサービスをレンタルするときのホテルのコストより相当に高い。このようなコストは、少なくとも、カスタマイズされたアプリケーションプログラミングインタフェース（ＡＰＩ）の構築および維持、ならびに大量の顧客要求によって求められるサービス費用を含み得る。そのため、通常のホテルは、ＧＤＳおよびメタサーチエンジンのサービスを求めるより、ＯＴＡモジュールおよび／またはブッキングエンジンのサービスを求める。以下の説明もＯＴＡモジュールおよび／またはブッキングエンジンの利用に集中されるが、ＧＤＳおよびメタサーチエンジンのサービスを利用する状況にも提供できる。

部屋在庫管理システム１００はホテルの制御下の所有地内に設けられている。ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよび／またはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮは、ホテルから離れたところに設けられており、ホテルの制御下にはない。チャネル管理機１５０は、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよびブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮの各々との通信チャネルをそれぞれ維持し、それらの要求を、部屋在庫管理システム１００、すなわちホテル、に対して解釈し中継する。しかしながら、共通の環境下では、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよび／またはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮの各々は、異なるＡＰＩおよび通信プロトコルを利用して異なる種類の変数およびパラメータを伝える。よって、これは、チャネル管理機１５０の通信チャネル用のカスタマイズＡＰＩを設計する際に、ホストまたはチャネル管理機１５０のコストを常に増加させる。カスタマイズＡＰＩは、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよび／またはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのＡＰＩおよび通信プロトコルに適合させるためのＡＰＩである。

部屋在庫管理システム１００は従来の資産管理システム（ＰＭＳ：ｐｒｏｐｅｒｔｙ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）モジュール１２０とメモリ１３０とを含む。

ホテルの部屋予約のための従来のＰＭＳモジュールとは、ホテルの部屋予約を促進するカスタマイズされたシステムを指す。従来のＰＭＳモジュールは、ホテルのフロント機能（ｆｒｏｎｔ ｏｆｆｉｃｅ ｆｕｎｃｔｉｏｎ）、販売機能、計画機能、報告機能等の運行を調整するなどの目標のカバーに用いられる総合的なソフトウェアアプリケーションである。従来のＰＭＳモジュールは、顧客の予約、顧客の詳細、オンライン予約、料金の通知、販売時点（ｐｏｉｎｔ ｏｆ ｓａｌｅ）、電話、売掛金、販売とマーケティング、イベント、食品および飲料の原価計算、資材管理、人事管理および給与計算、保守管理、品質管理、および他のアメニティなどのホテル運営を自動化する。ホテルのＰＭＳモジュールは、中央予約システムおよび収益（ｒｅｖｅｎｕｅ）または利益（ｙｉｅｌｄ）管理システム、オンラインブッキングエンジン、バックオフィス（ｂａｃｋ ｏｆｆｉｃｅ）、販売時点、ドアロック、ルームサービス最適化、エネルギー管理、支払いカード認証およびチャネル管理システムなどのサードパーティソリューションに、統合され得るまたはインタフェースを介して連結され得る。クラウドコンピューティング技術によって、ホテルのＰＭＳモジュールがその機能性を、オンラインチェックイン、ルームサービス、室内における制御、顧客とスタッフと間のコミュニケーション、仮想コンシェルジュ（ｖｉｒｔｕａｌ ｃｏｎｃｉｅｒｇｅ）などの顧客の面と向かう特徴まで拡張する。拡張機能は主に、顧客がその自身が持っている携帯電話によって利用され、または、ホテルのロビーおよび／または部屋において提供される。従来のＰＭＳモジュールは、１日当たりの平均料金や稼働率などの、従来のＰＭＳモジュールでは、ホテル業務の基本的な主要業績評価指標（ｂａｓｉｃ ｋｅｙ ｐｅｒｆｏｒｍａｎｃｅ ｉｎｄｉｃａｔｏｒｓ）について、正確で即時の情報を提供する必要がある。従来のＰＭＳモジュールは、食品および飲料の管理について、貯蔵室の在庫を制御し、どのようなもの、どの価格で、どの頻度で購入すべきかを決定することにも役に立つ。このように、従来のＰＭＳモジュール１２０は、ＰＭＳモジュール１２０を介してホテルとローカル的に、または、前述したＯＴＡモジュールおよび／またはブッキングエンジンを介して遠隔的に、顧客にその部屋予約を完成させることができる。

メモリ１３０は、部屋在庫管理システム１００によって管理された、すなわち、ホテルによって管理されたすべての部屋の予約状況を記録する部屋在庫記録１４０を保持する。管理された部屋の予約状況に基づいて、管理された部屋は、空き部屋、予約済みの部屋、および使用中の部屋に、部屋在庫管理システム１００によって分類され得る。顧客が空き部屋を予約すると、当該空き部屋は予約済みの部屋になる。顧客がホテルの予約済みの部屋にチェックインすると、予約済みの部屋は使用中の部屋になる。顧客がホテルからチェックアウトすると、使用中の部屋は空き部屋になる。

同様に、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭのそれぞれは対応する部屋在庫を有する。ブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのそれぞれも対応する部屋在庫記録を有する。

しかしながら、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよびブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮは、それぞれの部屋在庫記録の内容を部屋在庫記録１４０の内容と動的に同期する動機がない。それは、このような動的な同期は従来のＰＭＳモジュール１２０の応答を待つためにその負担が著しく増加し得るからである。また、チャネル管理機１５０は要求の翻訳および中継のみを担当するので、チャネル管理機１５０はこのような負担を従来のＰＭＳモジュールに低減させることができない。さらにひどい場合、多くのＯＴＡモジュールおよびブッキングエンジンが部屋在庫記録１４０の内容を問い合わせし続けると、従来のＰＭＳモジュール１２０はこのような問い合わせを対処できず、そのシステムクラッシュに導く。このようなシステムクラッシュを回避するために、従来のＰＭＳモジュール１２０は、より長い待ち時間間隔を与えることによって、ＯＴＡモジュールおよびブッキングエンジンのそれぞれに対して限られた問い合わせのみを許可することができる。待ち時間間隔は、ホテルがサービスを求めるＯＴＡモジュールおよび／またはブッキングエンジンの数に依存して、少なくとも数分間から数時間である。例えば、ＯＴＡまたはブッキングエンジンは、ホテルがサービスを求めるＯＴＡモジュールおよび／またはブッキングエンジンが５個以上の場合、半時間から二時間ごとに部屋在庫記録１４０を問い合わせるように限られ得る。ホテルがより多くのＯＴＡおよび／もしくはブッキングエンジンと協働するとき、または旅行の混雑期のとき、このような待ち時間はより長く設定され得る。その結果、ＯＴＡモジュールおよび／またはブッキングエンジンは顧客の部屋予約要求を処理するまで正確な部屋在庫記録を有しないことがあるので、部屋在庫記録１４０とＯＴＡモジュールおよび／またはブッキングエンジンの部屋在庫記録との内容には不一致が必然的に発生する。極端な状況下であっても、双方に望ましくない負担を低減するために、および、入ってくる部屋予約要求の処理に集中するために、ＯＴＡおよび／またはブッキングエンジンは、部屋在庫確認のコストを節約すべく、時々またはさらに頻繁に従来のＰＭＳモジュール１２０に問い合わせることを省こうとすることがある。さらにひどい場合、ホテルの空き部屋が実際に無くなり、かつ、ＯＴＡモジュールおよび／またはブッキングエンジンが意識するために即時に従来のＰＭＳモジュール１２０に問い合わせができていないとき、オーバーブッキングの発生は必然となる。

＜オーバーブッキングはどのように従来の部屋在庫管理システムで発生するか＞

従来の技術の観点でオーバーブッキングはどのように発生するかについては、図１の参照を介してさらに詳細に紹介される。

仮に、部屋在庫管理システム１００によって管理された空き部屋Ｒ１を予約するために、第１の顧客がＯＴＡモジュールＯＴＡ１を介してＰＭＳシステム１２０にアクセスする。まず、ＯＴＡモジュールＯＴＡ１は、ホテルが空き部屋を有するかを確認するために、自分の部屋在庫記録を確認し、当該自分の部屋在庫記録は部屋在庫記録１４０と一致していないことがある。ホテルが空き部屋を有する場合、ＯＴＡモジュールＯＴＡ１は第１の顧客の部屋予約要求を従来のＰＭＳモジュール１２０に転送する。次に、従来のＰＭＳモジュール１２０は部屋在庫記録１４０を確認し、第１の顧客に対して空き部屋を確かに有するかを確認する。確かに有する場合、従来のＰＭＳモジュール１２０は、第１の顧客の部屋予約要求を成立した取引に翻訳し、部屋在庫記録１４０を更新し当該成立した取引を記録する。このような更新は、部屋Ｒ１の予約状況を「予約済み」に変更することと、ホテルの空き部屋数を減少させることとを含む。

しかしながら、第１の顧客の部屋予約の少し後、同一の部屋Ｒ１を予約するために、第２の顧客がブッキングエンジンＢＥ１を介してＰＭＳシステム１２０にアクセスすると、ブッキングエンジンＢＥ１は、第１の顧客の成立した取引について即時に知らせられてなく、部屋Ｒ１がまだ空いていると誤った確認を取ることがある。次に、ブッキングエンジンＢＥ１は第２の顧客の部屋予約要求を従来のＰＭＳモジュール１２０に転送する。明らかに、従来のＰＭＳモジュール１２０は、部屋在庫記録１４０を参照すれば、第２の顧客の部屋予約が成立しないとすぐ決定するが、第２の顧客の成立しない部屋予約を知らせるためにブッキングエンジンＢＥ１の次の問い合わせを待たなければならない。運が悪い場合、ブッキングエンジンＢＥ１の次の問い合わせより前に第２の顧客がチェックインしようとすると、第２の顧客およびホテルはオーバーブッキングの問題に直面する。

第２の顧客は運が良かった場合、ホテルは適切な補償を第２の顧客に提供して代替的で空き部屋を用意することができる。しかしながら、ホテルは第１の顧客の成立した取引を確定した後その空き部屋が尽きた場合、第２の顧客はまたオーバーブッキングの問題に直面し、直ちに他のホテルにおいて他の空き部屋を探すと強いられる。大きな不確定性によって、第２の顧客の旅行体験が高い確率で損なわれ、ホテルおよびブッキングエンジンＢＥ１の両方の信用にも傷付く。さらにひどいとき、上述したように、ホテルが多くのＯＴＡおよび／もしくはブッキングエンジンと協働する場合、または、旅行の混雑期の場合、オーバーブッキングの問題の深刻さは増え続ける。

技術的な観点では、従来の部屋在庫管理システム１００は以下の欠点を有する。

（１）ＯＴＡおよびブッキングエンジンは、それぞれの部屋在庫記録の正確性を確認するために従来のＰＭＳモジュール１２０と動的に問い合わせることができない。

（２）ＯＴＡモジュールおよびブッキングエンジンが従来のＰＭＳモジュール１２０に問い合わせるそれぞれの頻度を増加させる場合、従来のＰＭＳモジュール１２０はその計算および／または通信帯域幅の負荷を対処できなくなる。よって、計算上または通信上のエラーが発生しやすくなる。

（３）従来の部屋在庫管理システム１００とＯＴＡモジュールおよび／またはブッキングエンジンとの間におけるデータの不一致は、ホテルのオーバーブッキングをもたらす。このようなオーバーブッキングは、ホテルが多くのＯＴＡモジュールおよび／またはブッキングエンジンと協働するとき、または旅行の混雑期のときにひどくなる。

（４）ホテルは、カスタマイズされたＡＰＩおよび通信プロトコルを開発し、ＯＴＡモジュールおよび／またはブッキングエンジンから要求される変数およびパラメータを受信し、部屋予約要求、部屋キャンセル要求、または部屋チェックアウト要求を処理するために、さらに多くのコストをかけなければならない。

＜本発明に係る部屋在庫管理システム＞

従来の部屋在庫管理システム１００において発生するオーバーブッキング問題を効率的に緩和するために、本発明は、１つの実施例に基づく、ブロックチェーンに基づく部屋在庫管理システム、すなわち、図２に示されたブロックチェーンに基づく部屋在庫管理システム２００を開示する。部屋在庫管理システム２００は中間サーバシステムを導入し、当該中間サーバシステムは、従来のＰＭＳモジュールとＯＴＡモジュールおよび／またはブッキングエンジンとの間のデータの不一致を緩和することができ、従来のＰＭＳモジュールの負担を低減することができる。また、部屋在庫管理システム２００は、ＯＴＡモジュールおよびブッキングエンジン、さらに前述したＧＤＳおよびメタサーチエンジンによる通信および維持のコストを節約するような、費用効果が高い解決策をホテルに提供する。

ブロックチェーンは複数の物理ノードを含み、論理上、それぞれの物理ノードは同様な内容、例えば、同様な複数のブロックを維持している。それぞれのノードは複数のブロックを含む。特定のイベントの発生に応じて、例えば、成立した取引の発生に応じて、当該特定のイベントを記録するために新しいブロックが生成される。多くのブロックの生成につれて、成立した取引の履歴はブロックチェーンにおいて確立されて追跡され得る。よって、ブロックチェーンを採用する１つ目の利点は追跡可能性である。その上、特定の物理ノードにおいて特定ブロックの改ざん行為が成功したとしても、すべての物理ノードが論理上に同様な内容、すなわち、同様なブロックを含むため、当該行為は、影響を受けていない他の物理ノードを参照することによって検出され修復され得る。すなわち、ブロックチェーンを採用する２つ目の利点はその改ざん行為を防御する能力である。

ブロックチェーン技術を適用するとき、ブロックチェーンに基づく部屋在庫管理システム２００は、成立した取引のそれぞれ、すなわち、部屋予約イベントのそれぞれの正確性を有効的に確保することができる。よって、ブロックチェーンに基づく部屋在庫管理システム２００は、従来の部屋在庫管理システムによって起こされるオーバーブッキング問題を有効的に緩和することができる。

また、ブロックチェーンに基づく部屋在庫管理システム２００は、イーサリアムに基づくスマートコントラクト（ｓｍａｒｔ ｃｏｎｔｒａｃｔ）を利用して、ＯＴＡモジュールおよび／またはブッキングエンジンと通信するための、共通のＡＰＩおよび／または共通の通信プロトコルを生成する。いくつかの実施例において、共通のＡＰＩは、同様にイーサリアムに基づくこれらのＯＴＡモジュールおよび／またはブッキングエンジン向けであり、共通の通信プロトコルは、イーサリアムに基づかないこれらのＯＴＡモジュールおよび／またはブッキングエンジン向けである。このように、システムの維持と通信のためのＡＰＩおよび／または通信プロトコルのコストを著しく減少させることができ、当該システムの維持と通信は、ＯＴＡモジュールおよび／もしくはブッキングエンジンとの部屋予約イベントの送受信、または、ＯＴＡモジュールおよび／もしくはブッキングエンジンとの部屋在庫記録の更新を含む。それは、イーサリアムに基づくスマートコントラクトが言語設計上のオープンで簡単という特性により、当該特性は、比較的に少ないまたは比較的に理解しやすい変数およびパラメータの中継を含む。このようなコスト低減は、同様な理由で、ブロックチェーンに基づく部屋在庫管理システム２００がＧＤＳおよびメタサーチエンジンと協働するときも働く。

スマートコントラクトはイーサリアムの下で開発された技術であり、本発明に適用されるブロックチェーン技術に対して重要な補助技術である。イーサリアムは、オープンソースであり、ブロックチェーンに基づく分散計算システムおよびオペレーティングシステムであり、スマートコントラクトの機能性を特徴とする。イーサリアムは、分散式でチューリング完全（Ｔｕｒｉｎｇ－ｃｏｍｐｌｅｔｅ）の仮想マシン、すなわち、イーサリアム仮想マシン（ＥＶＭ：Ｅｔｈｅｒｅｕｍ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）を提供し、当該ＥＶＭはノードの国際ネットワークを利用するスクリプトを実行することができる。

イーサリアムのスマートコントラクトは、開発者が各自の機能をプログラミングするために利用する異なるコンピュータ言語に基づく。スマートコントラクトは、高級プログラミングに抽象化されており、ＥＶＭのバイトコードにコンパイルされ、実行されるようにイーサリアムブロックチェーンに配置される。スマートコントラクトによって、証明可能な公平性（ｐｒｏｖａｂｌｙ ｆａｉｒ）を自身に含むカジノなどの機能性を提供することが可能となる。イーサリアムブロックチェーンアプリケーションはしばしば分散式アプリケーションと称され、それは、当アプリケーションは分散式ＥＶＭおよびそのスマートコントラクトに基づくからである。イーサリアムブロックチェーンアプリケーションの例としては、デジタル署名アルゴリズム、証券化トークン、デジタル権利管理、クラウドファンディング、予測市場、送金、オンラインギャンブル、ソーシャルメディアプラットフォーム、金融取引所、および識別システムが挙げられる。イーサリアムのチューリング完全の特性によって、スマートコントラクトは、機能の設計上および実行上の高い柔軟性を提供する。また、イーサリアムに基づくスマートコントラクトはオープンソースであって実装しやすいため、ブロックチェーンに基づく部屋在庫管理システム２００は、イーサリアムに基づくスマートコントラクトによって、ＯＴＡモジュールおよび／またはブッキングエンジンとの通信において上述した利点を有する。

ブロックチェーンに基づく部屋在庫管理システム２００は、新規のＰＭＳモジュール２１０と中間サーバシステム２５０とを含む。ＰＭＳモジュール２１０は、ＰＭＳモジュール２１０を直接的に制御できるホテルなどのホテル内に配置され得る。中間サーバ２５０はＰＭＳモジュール２１０から遠隔的に配置され得る。一実施例において、中間サーバシステム２５０はＰＭＳモジュール２１０のために部屋予約イベントを前処理しまたは処理し、よって、中間サーバシステム２５０はＰＭＳモジュール２１０の負担を著しく緩和する。一実施例において、部屋予約イベントは、少なくとも、ホテルからの内部部屋予約要求およい内部部屋キャンセル／チェックアウト要求、ならびに、ＯＴＡモジュールおよび／またはブッキングエンジンからの外部部屋予約要求および外部部屋キャンセル要求を含む。外部部屋予約／キャンセル要求は外部のＯＴＡモジュールおよび／またはブッキングエンジンに送信され、イーサリアムに基づくスマートコントラクトを用いて開発されたＡＰＩまたは通信プロトコルによってホテルの少なくとも１つの部屋を予約またはキャンセルしてもよい。内部部屋予約／チェックアウト要求は、ホテルにおいて顧客が直接的に部屋を予約するとき、または、ホテルにチェックインした顧客がチェックアウトするときに発生する。また、イーサリアムに基づくスマートコントラクトを用いて開発されたＡＰＩまたは通信プロトコルが設定しやすいため、中間サーバシステム２５０はイーサリアムに基づくスマートコントラクトを利用して部屋予約イベントを通信し、ＯＴＡモジュールおよび／またはブッキングエンジンとの費用効果が高い通信が達成する。

一実施例において、ＰＭＳモジュール２１０は、同様な遠隔手続き呼び出し（ＲＴＣ：ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ、リモートプロシージャコールとも呼ばれている）プロシージャなどの同様なアプリケーションプログラミングインタフェースを共有することによって中間サーバシステム２５０と協働するように特別に設計され、よって、ＰＭＳモジュール２１０と中間サーバシステム２５０との間の通信は処理時間が短くなって効率がよくなることができる。部屋在庫管理システム２００が短時間内で大量の部屋予約イベントを処理する必要があるとき、例えば、旅行の混雑期のときに、このような高い効率はより明らかになる。

ＰＭＳモジュール２１０は、ホスト送受信機２１２とホストプロセッサ２１４とホストメモリ２１６とを含む。本発明の実施例において、ホストプロセッサ２１４はコンピュータプロセッサであり、ホストメモリ２１６は不発揮性コンピュータ可読メモリである。ホスト送受信機２１２は中間サーバシステム２５０との通信を処理できるが、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよびブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮと直接的に通信しない。ホストメモリ２１６は、ホストの部屋管理のためにＰＭＳモジュール２１０に対して（図３に示された）部屋在庫記録２１８を維持する。部屋在庫記録２１８は、少なくとも、ホテルの各部屋の予約状況、および、ホテルの空き部屋数を含む。ホストプロセッサ２１４は、部屋予約イベントの発生に応じて、部屋在庫記録２１８を参照および／または更新する。例えば、ホストプロセッサ２１４は部屋予約要求に応じて、空き部屋数を減少させ、および／または、予約部屋を、空きがない状況としてもよい。また、ホストプロセッサ２１４は、部屋キャンセル要求または部屋チェックアウト要求に応じて、空き部屋数を増加させ、および／または、予約済みの部屋を空いている状況にしてもよい。

中間サーバシステム２５０はブロックチェーン技術を適用する。また、中間サーバシステム２５０は取引プロキシサーバ２６０と複数のノードサーバ、例えば、図２に示されたＸ個のノードサーバＮＳ１、ＮＳ２…ＮＳＸとを含む。Ｘは正の整数である。また、ノードサーバＮＳ１、ＮＳ２…ＮＳＸは、ブロックチェーンを形成し、それぞれにデータ一致性およびデータ追跡可能性のために実質的に同様なデータを維持する。

取引プロキシサーバ２６０は、中間サーバシステム２５０の頭脳として動作し、中間送受信機２６２と中間プロセッサ２６４と中間メモリ２６６とを含む。いくつかの実施例において、取引プロキシサーバ２６０は信頼ノードとして動作し、中間サーバシステム２５０内にブロックチェーンにおけるブロックを生成するように承認される。同様に、実施例において、中間プロセッサ２６４はコンピュータプロセッサであり、中間メモリ２６６は不発揮性コンピュータ可読メモリである。ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭ、およびブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮまたはＰＭＳモジュール２１０のいずれか１つが部屋予約要求を発行するとき、中間送受信機２６２は部屋予約要求を受信して部屋予約要求を中間プロセッサ２６４に転送する。いくつかの実施例において、中間送受信機２６２はアプリケーションプログラミングインタフェース（ＡＰＩ）サーバとして実行され、ＡＰＩサーバは、中間メモリ２６６に記憶されたイーサリアムのスマートコントラクトに基づいて、部屋予約要求を、ＰＭＳモジュール２１０および中間サーバシステム２５０が理解しやすい形式に翻訳し、すなわち、チャネル管理機１５０の機能の代替となる。中間メモリ２６６は、少なくとも１つのイーサリアムに基づくスマートコントラクトを用いて実行される（図３に示された）部屋在庫記録２６８を維持し、よって、中間プロセッサ２６４は、複数のイーサリアムに基づくスマートコントラクトと互換可能な指令に基づいて、部屋在庫記録２６８を操作する（例えば、アクセスする、更新する、または監査する（ａｕｄｉｔ））。中間サーバシステム２５０（特に取引プロキシサーバ２６０）とＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよび／またはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮとの間の通信は、中間メモリ２６６に記憶されたスマートコントラクトによって支援される。中間プロセッサ２６４は、複数のスマートコントラクトの少なくとも１つを利用し、部屋在庫記録２６８の内容にアクセスするおよび／または更新する。また、いくつかの実施例において、ＡＰＩサーバの翻訳プロシージャを部屋在庫管理プロシージャから分離させて取引プロキシサーバ２６０のシステムオーバーロードを回避するために、中間送受信機２６２は中間プロセッサ２６４および／または中間メモリ２６６から離れて配置され得る。

いくつかの実施例において、中間プロセッサ２６４は、ＰＭＳモジュール２１０、または、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭもしくはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのいずれか１つから部屋予約イベントが成立した取引であるかを判断し、当該部屋予約イベントは部屋予約要求、部屋チェックアウト要求または部屋キャンセル要求であってもよい。ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭまたはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのいずれか１つからの部屋予約イベントは、顧客からの外部部屋予約要求または（予約がすでに成立と確認された場合において）外部部屋キャンセル要求であってもよい。ＰＭＳモジュール２１０からの部屋予約イベントは、内部部屋予約要求、内部部屋キャンセル要求、または内部部屋チェックアウト要求であってもよい。部屋予約要求を受信するとき、中間プロセッサ２６４は、部屋在庫記録２６８を確認し、例えば、予約部屋の予約状況に基づいて、または、部屋予約要求が許可されるとホテルにおいてオーバーブッキングが発生するか否かに基づいて、部屋予約要求が許可すべきであるか否かを確認する。中間プロセッサ２６４が部屋予約要求を許可すると、中間プロセッサ２６４は対応的に成立した取引を生成する。同様に、内部チェックアウト要求、内部部屋キャンセル要求または外部部屋キャンセル要求を受信すると、中間プロセッサ２６４は、部屋在庫記録２６８を確認し、キャンセルされたまたはチェックアウトされた部屋を解除し、対応的に成立した取引を生成する。

ブロックチェーン技術の下で実行される複雑な機能を支援するために、中間サーバシステム２５０は、中間メモリ２６６に記憶された少なくとも１つの、イーサリアムに基づくスマートコントラクトを適用する。前述したように、スマートコントラクトの設定上および実行機能上の柔軟性によって、中間サーバシステム２５０は、伝統的な部屋予約需要と最も新しいブロックチェーン技術とを組み合わせて様々な種類の機能を実行することができる。

いくつかの実施例において、中間プロセッサ２６４は、部屋予約イベントが成立した取引であるか否かを判断した後、部屋在庫記録２６８を更新するために成立した取引を部屋在庫記録２６８に組み入れる。また、中間プロセッサ２６４は、ノードサーバＮＳ１、ＮＳ２…ＮＳＸのそれぞれに対して更新した部屋在庫記録２６８の内容を同期してもよく、すなわち、ノードサーバＮＳ１、ＮＳ２…ＮＳＸによって形成されたブロックチェーンを更新してもよい。よって、ノードサーバＮＳ１、ＮＳ２…ＮＳＸは、部屋在庫記録２６８のためのバックアップ記憶装置として動作し得る。

いくつかの実施例において、よく知られたブロックチェーン技術が示すように、前述したノードサーバＮＳ１、ＮＳ２…ＮＳＸのブロック更新は同一のブロックチェーンにおいて異なるノードサーバ間のブロック競合（ｂｌｏｃｋ ｃｏｍｐｅｔｉｔｉｏｎ）を含み得て、よって、いくつかのブロックはノードサーバＮＳ１、ＮＳ２…ＮＳＸの一部において追加されてから廃棄される。ただ、簡潔に説明するために、仮にノードサーバＮＳ１、ＮＳ２…ＮＳＸのブロック更新はこのようなブロック競合をカバーする。よって、仮に、ノードサーバＮＳ１、ＮＳ２…ＮＳＸのそれぞれは、実質的に同様なブロックを有し、当該ブロックは最終的には実質的に同様な取引履歴を含む。

このように、中間プロセッサ２６４はノードサーバＮＳ１、ＮＳ２…ＮＳＸのいずれか１つから部屋在庫記録２６８の正確な複写を常に見つけることができるため、部屋在庫記録２６８の内容は損害をより回避することができる。

ノードサーバＮＳ１、ＮＳ２…ＮＳＸのそれぞれは、ノード送受信機とノードプロセッサとノードメモリとを含む。ノードプロセッサはコンピュータプロセッサである。また、ノードメモリは不発揮性コンピュータ可読メモリである。ノード送受信機は、部屋予約要求に対応する成立した取引が発生するときに、中間プロセッサ２６４から指令を受信し中間プロセッサ２６４からにデータを送信する。ノードメモリは、以後の更新および／または監査のために、部屋在庫記録２６８の内容の複写を記憶してもよい。ノードプロセッサは、中間プロセッサ２６４から受信した指令を処理し、中間プロセッサ２６４に応答するにはどのようなデータを判断する。図２に示された例示のように、例えば、ノードサーバＮＳ１はノード送受信機ＮＴ１とノードプロセッサＮＰ１とノードメモリＮＭ１とを有し、ノードサーバＮＳ２はノード送受信機ＮＴ２とノードプロセッサＮＰ２とノードメモリＮＭ２とを有し、ノードサーバＮＳＸはノード送受信機ＮＴＸとノードプロセッサＮＰＸとノードメモリＮＭＸとを有する。

図３は、ホストメモリ２１６、中間メモリ２６６、およびノードメモリＮＭ１、ＮＭ２…ＮＭＸの部屋在庫記録、すなわち、部屋在庫記録２１８、部屋在庫記録２６８、および部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸの間のデータ交換に関する略図を示す。ノードメモリＮＭ１、ＮＭ２…ＮＭＸのそれぞれは同様な複数のスマートコントラクトを部屋在庫管理２６８の複数のスマートコントラクトとして記憶する。また、部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸは、ノードメモリＮＭ１、ＮＭ２…ＮＭＸのそれぞれに記憶された当該複数のスマートコントラクトを用いて実行される。中間プロセッサ２６４および中間メモリ２６６と同様に、ノードプロセッサＮＰ１、ＮＰ２…ＮＰＸのそれぞれは、部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸを実行する当該複数のスマートコントラクトを用いて、部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸの内容を各自にアクセスし更新する。

いくつかの実施例において、中間プロセッサ２６４はまず、成立した取引の発生に応じて、部屋在庫記録２６８を更新する。また、中間プロセッサ２６４はホスト送受信機２１２を介して部屋在庫記録２６８の更新した内容をＰＭＳモジュール２１０に転送し、よって、ホストプロセッサ２１４は部屋在庫記録２１８を更新し、部屋在庫記録２６８の更新した内容と同期する。また、中間プロセッサ２６４は、部屋在庫記録２６８の更新した内容に応じて、新しいブロックを生成し、当該新しいブロックはＰＭＳモジュール２１２の少なくとも最新の成立した取引のすべてを担持する。いくつかの実施例において、中間プロセッサ２６４は、完全の指令、例えば、変数を計算し更新すること、を実行するために、中間メモリ２６６に記憶された少なくとも１つのスマートコントラクトを要求し、新しいブロックを生成する。例えば、Ｙ個の異なる成立した取引が時間順（ｃｈｒｏｎｏｌｏｇｉｃａｌ ｏｒｄｅｒ）で発生するとき、中間プロセッサ２６４は、時刻ｔ１にブロックＢＬ１を、時刻ｔ２にブロックＢＬ２を、時刻ｔＹに最も新しく生成されるブロックＢＬＹを生成する。Ｙは正の整数である。時刻ｔ１が時刻ｔ２より早く、時刻ｔ２が時刻ｔ（Ｙ－１）より早く、時刻ｔ（Ｙ－１）が時刻ｔＹより早い。時刻ｔＹは、最新に生成される成立した取引が発生する時刻ｔＹを指す。ブロックＢＬ１は時刻ｔ１まで最新の成立した取引のすべてを含む。ブロックＢＬ２は、ブロックＢＬ１より、もう１つの、時刻ｔ２に発生した成立した取引を含み、すなわち、時刻ｔ２まで最新の成立した取引のすべてを含む。同様に、ブロックＢＬＹは時刻ｔＹまで最新の成立した取引のすべてを含む。

ノードサーバＮＳ１、ＮＳ２…ＮＳＸのそれぞれは、ブロックチェーン技術の下で、対応する部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸを部屋在庫記録２６８の内容と同期的に更新し続けるべきである。よって、それぞれのノード送受信機ＮＴ１、ＮＴ２…ＮＴＸを介して最も新しく生成されたブロックＢＬＹを受信した後、ノードプロセッサＮＰ１、ＮＰ２…ＮＰＸは、当該最も新しく生成されたブロックＢＬＹを対応する部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸにそれぞれに組み入れる。いくつかの実施例において、ノードプロセッサＮＰ１、ＮＰ２…ＰＮＸは、少なくとも１つのスマートコントラクトの協力を要求し、最も新しい取引に関わる指令を同期的に実行し、対応する部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸの更新を完成する。更新は、いくつかのローカル変数またはいくつかのグローバル変数の更新を含んでもよい。いくつかのローカル変数は部屋の予約状況または対応する部屋価格を含んでもよい。いくつかのグローバル変数は条件付き割引または動的に調整された部屋価格を含んでもよい。

図４は、中間プロセッサ２６４がどのように新しいブロックを生成するかを詳細に示す。中間プロセッサ２６４はハッシングモジュール４０２とタイムスタンプモジュール４０４とブロック生成モジュール４０６とを含む。前述したように、中間プロセッサ２６４は成立した取引に応じて新しいブロックを生成する。中間プロセッサ２６４が成立した取引を確認するとき、ハッシングモジュール４０２は新しいブロックに対してハッシュ値を生成し、タイムスタンプ４０４は新しいブロックに対して一意的なタイムスタンプを生成する。例えば、Ｙ個のブロックＢＬ１、ＢＬ２…ＢＬＹに対して、ハッシングモジュール４０２は実質的に一意的なハッシュ値ＨＳ１、ＨＳ２…ＨＳＹをそれぞれに生成し、タイムスタンプモジュール４０４は実質的に一意的なタイムスタンプＴＳ１、ＴＳ２…ＴＳＹをそれぞれに生成する。

ハッシュ値の生成方法はブロックチェーン技術の当業者にとっては周知であるため、ここでは詳細に説明しない。ただ、生成されたハッシュ値のそれぞれはそのランダム性（ｒａｎｄｏｍｎｅｓｓ）を有し、よって、生成されたハッシュ値のそれぞれは実質的に一意的であり得る。いくつかの実施例において、生成されたタイムスタンプは、中間プロセッサ２６４が成立した取引を確認する時刻、または部屋予約要求が開始される時刻として参照され得て、当該部屋予約要求は、例えば、ＰＭＳモジュール２１０、または、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭ、もしくはＮ個のブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのいずれか１つによって開始される。このように、ブロックＢＬ１、ＢＬ２…ＢＬＹのそれぞれは、それの実質的に一意的なハッシュ値と実質的に一意的なタイムスタンプとを有するはずである。また、最も新しく生成されたブロックＢＬＹは、最新に生成された複数のブロックのうちに、最も新しいタイムスタンプを有する。

成立した取引に応じて、ブロック生成モジュール４０６は、ブロックヘッダを生成するために、ハッシングモジュール４０２からの実質的に一意的なハッシュ値とタイムスタンプモジュール４０４からの実質的に一意的なタイムスタンプとを組み入れる。例えば、最も新しい成立した取引に基づいて生成すべきブロックＢＬＹに対して、ブロック生成モジュール４０６はハッシュ値ＨＳＹとタイムスタンプＴＳＹとを取り入れてブロックヘッダＢＨＹを生成する。このように、ブロック生成モジュール４０６はブロックヘッダＢＨ１、ＢＨ２…またはＢＨＹをそれぞれに生成する。

また、成立した取引に応じて、ブロック生成モジュール４０６は、対応するブロックヘッダと、成立した取引の内容と、少なくとも１つスマートコントラクトと、直前に生成したブロックの内容とを取り入れた新しいブロックを生成する。例えば、最も新しい成立した取引に応じて、ブロック生成モジュール４０６はブロックＢＬＹを生成し、ブロックＢＬＹは、ブロックヘッダＢＨＹと、中間メモリ２６６からロードした少なくとも１つの１つスマートコントラクトと、直前のブロックＢＬ（Ｙ－１）の内容（簡潔に説明するために図示せず）とを含む。このように、最も新しく成立したブロックＢＬＹは以前生成したブロックＢＬ１、ＢＬ２…ＢＬ（Ｙ－１）のすべての内容を含む。また、以前生成したブロックＢＬ１、ＢＬ２…ＢＬ（Ｙ－１）のすべてによって指される最新の成立した取引のすべては、最も新しく生成したブロックＢＬＹを参照するだけで簡単に監査し得る。

最後に、ブロック生成モジュール４０６は、ノードサーバＮＳ１、ＮＳ２…ＮＳＸによって形成されたブロックチェーンに新しいブロックを追加し、ブロックチェーンを更新する。例えば、ブロック生成モジュール４０６は、ブロックチェーンを更新するために、すでにブロックＢＬ１、ＢＬ２…ＢＬ（Ｙ－１）を含んでいるブロックチェーンに最も新しく生成したブロックＢＬＹを追加する。

いくつかの実施例において、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよび／またはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのそれぞれは、直接的に、または取引プロキシサーバ２６０を介して、ノードサーバＮＳ１、ＮＳ２…ＮＳＸによって形成されたブロックチェーンにアクセスすることが許可される。このように、最も新しい取引を実質的に常に維持するブロックチェーンを利用することによって、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭおよび／またはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのそれぞれは常に、最も新しく生成したブロックをタイムリーに参照することによって、空き部屋の正確な数量および／または特定の部屋の予約状況を主導的に確認することができる。その結果、オーバーブッキングは実質的に改善され得る。

また、ＰＭＳモジュール２１０の多くのタスクが中間サーバシステム２５０によって緩和されるため、ＰＭＳモジュールのオーバーロードという従来の欠点も有効的に実質的に回避され得る。

いくつかの実施例において、ノードサーバＮＳ１、ＮＳ２…ＮＳＸによって形成されたブロックチェーンは、それぞれのブロックヘッダを介して、さらに具体的には、それぞれのハッシュ値を介して、形成されて監査される。いくつかの実施例において、ノードサーバＮＳ１、ＮＳ２…ＮＳＸの間のブロックチェーンはマークル木（Ｍｅｒｋｌｅ Ｔｒｅｅ）の技術を適用し、よって、ブロックチェーンの各ブロックは実質的に一意的なマークルルート（Ｍｅｒｋｌｅ Ｒｏｏｔ）を有する。特定のブロック、例えば、ブロックＢＬ１がノードサーバＮＳ１、ＮＳ２…ＮＳＸのうちの１つにおいて改ざんされた場合、ブロックチェーンにアクセス可能な任意の個体は、ブロックチェーンを簡単に監査し、特定のノードサーバにおいて改ざんされたブロックＢＬ１を容易に見つけることができる。監査プロシージャは以下のことを含む。（１）ノードサーバＮＳ１、ＮＳ２…ＮＳＸのそれぞれにおけるブロックＢＬ１のマークルルートを計算する。（２）ノードサーバＮＳ１、ＮＳ２…ＮＳＸのすべてにおけるブロックＢＬ１のマークルルートを比較し、少なくとも１つのノードサーバにおいて改ざんされたブロックＢＬ１にある不一致を見つける。より具体的には、改ざんされたブロックＢＬ１は必ず、他のノードサーバにおいて改ざんされていないブロックＢＬ１のマークルルートと異なるマークルルートを有するため、当該異なるマークルルートは前述した比較によって簡単に見つけられる。また、改ざんされたブロックＢＬ１は、改ざんされていない他のブロックＢＬ１を参照することによって修復できる。その結果、ブロックチェーンにおけるブロックはそれぞれの正確さが保証され、よって、それぞれのノードサーバにおける部屋在庫記録は安全性が確保されている。いくつかの実施例において、ある個体は、ブロックチェーンを監査する、またはさらに修復するために、ブロックチェーンにアクセスすることが承認され、当該個体は例えば、ＰＭＳモジュール２１０、取引プロキシサーバ２６０、または、いずれかのノードサーバＮＳ１、ＮＳ２…ＮＳＸのプロセッサである。前述した監査および修復の実施例は、例示のブロックＢＬ１以外の他のブロックにも適用される。

いくつかの実施例において、それぞれの成立した取引は、対応するブロックヘッダを介して、さらに具体的には対応するタイムスタンプを介して、ノードサーバＮＳ１、ＮＳ２…ＮＳＸのいずれか１つにおけるブロックＢＬ１、ＢＬ２…ＢＬＹのいずれか１つを参照することによって、前述した監査プロシージャの一部として、正確に追跡され得る。また、追跡プロシージャは、前述したようにブロックチェーンをアクセスすることが承認された個体によって、中間メモリ２６６またはそれぞれのノードメモリＮＭ１、ＮＭ２…ＮＭＸに記憶された少なくとも１つの監査スマートコントラクトを用いて、実行され得る。このような個体は、取引プロキシサーバ２６０の中間プロセッサ２６４、または、いずれかのノードサーバＮＳ１、ＮＳ２…ＮＳＸのノードプロセッサを含んでもよい。好ましくは、このような監査プロシージャは、即時かつ混乱が生じない更新のために、中間プロセッサ２６４によって行われる。追跡プロシージャは以下のことを含む。（１）ブロックＢＬ１、ＢＬ２…ＢＬＹのブロックヘッダＢＨ１、ＢＨ２…ＢＨＹを検索する。（２）それぞれのブロックＢＬ１、ＢＬ２…ＢＬＹの生成の発端となったそれぞれの成立した取引を識別するために、それぞれのブロックＢＬ１、ＢＬ２…ＢＬＹのタイムスタンプＴＳ１、ＴＳ２…ＴＳＹを追跡する。タイムスタンプによって、それぞれの成立した取引の発生は時間順で正確に確認され得る。このように、先に成立してＯＴＡモジュールまたはブッキングエンジンに即時に通知されない可能性がある取引ではなく、後で成立した取引を誤ってアクセスすることによって起こされるオーバーブッキングを、よりよく確認して回避することができる。

いくつかの実施例において、部屋在庫記録２６８に記憶された複数のスマートコントラクトは少なくとも１つの動的価格スマートコントラクトを含み、当該動的価格スマートコントラクトによれば、部屋在庫記録２６８に記録された暫定空き部屋数に基づいて、少なくとも１つの暫定かつ変更可能な部屋価格を決定することができる。中間プロセッサ２６４は、暫定部屋価格を動的に調整し、中間送受信機２６２を介して、調整した部屋価格をＰＭＳモジュール２１０、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭ、および／またはブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮに転送する。同様に、ホスト送受信機２１２が調整された部屋価格を受信すると、ホストプロセッサ２１４は調整された部屋価格を用いて部屋在庫記録２１８を動的に更新する。

従来の部屋在庫管理システム１００と比べると、部屋在庫管理システム２００は以下の利点を有する。（１）すべての成立した取引が時間順で記録されることを確保することによって、オーバーブッキング問題を改善する。（２）中間サーバシステム２５０によって、成立した取引の確認および／または部屋在庫記録の更新のための、ＰＭＳモジュールの負担、時間および帯域幅を緩和する。（３）部屋在庫記録の正確さおよび追跡可能性を高める。

前述した実施例において、部屋在庫管理システム２００は中央モジュール、すなわち、取引プロキシサーバ２６０を適用し、中間サーバシステム２６０のノードサーバＮＳ１、ＮＳ２…ＮＳＸにわたる主要なタスクを管理する。しかしながら、本発明のもう１つの実施例において、ノードサーバＮＳ１、ＮＳ２…ＮＳＸの間のこのような管理責務を移転することによってタスクを管理することについてバランスをよりよく取る。特には、ノードサーバＮＳ１、ＮＳ２…ＮＳＸのいずれか１つは、時間期間内にすべてのノードサーバＮＳ１、ＮＳ２…ＮＳＸを管理するようにマスタノードサーバとして一時的に指定され得て、ノードサーバＮＳ１、ＮＳ２…ＮＳＸのうちのもう１つは他の時間期間内に新しいマスタノードサーバとして指定され得る。いくつかの実施例において、ノードサーバＮＳ１、ＮＳ２…ＮＳＸの間のマスタノードサーバの責務転換は、時々に（ｆｒｏｍ ｔｉｍｅ ｔｏ ｔｉｍｅ）、周期的に、またはランダム的に実行され得る。また、マスタノードサーバの指定は、ノードサーバＮＳ１、ＮＳ２…ＮＳＸの間で、選挙、順次交替、または所定ルールによって実行され得る。所定ルールは、より小さいまたは最も小さい負担を有するノードサーバを新しいマスタノードサーバにすることを含んでもよく、このような負担は、瞬時システム負荷、瞬時ストレージサイズ、および／または瞬時送信帯域幅を含んでもよい。よって、任意のノードサーバＮＳ１、ＮＳ２…ＮＳＸは、受けきれない負担を受けること、さらに故障することを回避することができる。

図５は本発明のもう１つの実施例に基づく部屋在庫管理システム５００を示す。部屋在庫管理システム５００はＰＭＳモジュール２１０と中間サーバシステム２５０とを含む。ＰＭＳモジュール２１０の特性および配置は図２で説明したＰＭＳモジュールと同様である。よって、ＰＭＳモジュール２１０に関する説明はここで繰り返さない。中間サーバシステム５２０は図２で説明したノードサーバと同様な複数のノードサーバＮＳ１、ＮＳ２…ＮＳＸを含む。しかしながら、部屋在庫管理システム２００と部屋在庫管理システム５００との主な違いは、取引プロキシサーバ２６０の代わりに、１つのノードサーバＮＳ１、ＮＳ２…ＮＳＸはコンセンサスアルゴリズムによってマスタノードサーバとして一時的に選択できることにある。マスタノードサーバおよびその要素は、少なくとも取引プロキシサーバ２６０およびその要素の構造および能力を受け継ぐ。よって、簡潔に説明するために、マスタノードサーバについて取引プロキシサーバ２６０と同様な重複の説明を省略する。

ノードサーバＮＳ１、ＮＳ２…ＮＳＸのうちからマスタノードサーバを選択するコンセンサスアルゴリズムは、順次順序によって選択すること、ランダムな順序によって選択すること、および／または、すべてのノードサーバに関与する問い合わせコンセンサスを介して選択することを含む。選択されたマスタノードサーバが所定の時間期間内に管理タスクを担当し、当該所定の時間期間が終わると選択が再び行って他のマスタノードサーバを決定し、よって、以前に選択されたマスタノードサーバは再度に選択されるまでその責任が解放される。以下の説明は、取引プロキシサーバ２６０と同様な機能を行うマスタノードサーバとしてノードサーバＮＳＴが一時的に選択されるという条件に基づく。

図６は、ホストメモリ２１６と他のノードメモリＮＭ１、ＮＭ２…ＮＭＸ（一時的なマスタノードメモリＮＭＴを含む。）との部屋在庫記録の間の関係、すなわち、部屋在庫記録２１８と部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸ（一時的なマスタ部屋在庫記録ＲＩＴを含む。）との間の関係に関する略図を示す。同様に、部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸは、メモリＮＭ１、ＮＭ２…ＮＭＸに記憶された複数のスマートコントラクトを用いて実行される。また、ノードプロセッサＮＰ１、ＮＰ２…ＮＰＴ…ＮＰＸは複数のスマートコントラクトを用いて対応する部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸをアクセスするまたは更新する。いくつかの実施例において、マスタノードプロセッサＮＳＴはまず、成立した取引の発生に応じて、一時的なマスタ部屋在庫記録ＲＩＴを更新する。また、マスタノードプロセッサＮＳＴは、マスタノード送受信機ＮＴＴおよびホスト送受信機２１２を介して、一時的なマスタ部屋在庫記録ＲＩＴの更新した内容をＰＭＳモジュール２１０に転送する。それよって、ホストプロセッサ２１４は、部屋在庫記録２１８を更新し、一時的なマスタ部屋在庫記録ＲＩＴの更新した内容と実質的に同期する。また、マスタノードプロセッサＮＰＴは、一時的なマスタ部屋在庫記録ＲＩＴの更新された内容に応じて、ＰＭＳモジュール２１２において少なくとも最新の成立した取引のすべてを担持する新しいブロックを生成する。注意すべきなのは、それぞれのノードサーバＮＳ１、ＮＳ２…ＮＳＸのメモリＮＭ１、ＮＭ２…ＮＭＴに記憶されたスマートコントラクトは、中間メモリ２６６に記憶されたスマートコントラクトと同様であることである。よって、いくつかの実施例において、マスタノードプロセッサＮＰＴは、完全な指令、例えば、変数を計算し更新することを実行するために、マスタノードメモリＮＭＴに記憶された少なくとも１つのスマートコントラクトをロードして新しいブロックを生成してもよい。例えば、時間順にＹ個異なる成立した取引が発生するとき、前回のマスタノードプロセッサおよび／または一時的なマスタノードプロセッサ２６４は、時刻ｔ１にブロックＢＬ１を生成し、時刻ｔ２にブロックＢＬ２を生成し、時刻ｔＹに最も新しく生成されるブロックＢＬＹを生成してもよい。Ｙは正の整数である。時刻ｔ１が時刻ｔ２より早く、時刻ｔ２が時刻ｔ（Ｙ－１）より早く、時刻ｔ（Ｙ－１）が時刻ｔＹより早い。時刻ｔＹは、最新に生成される成立した取引が発生する時刻ｔＹを指す。ブロックＢＬ１は時刻ｔ１まで最新の成立した取引のすべてを含む。ブロックＢＬ２は、ブロックＢＬ１より、もう１つの、時刻ｔ２に発生した成立した取引を含み、すなわち、時刻ｔ２まで最新の成立した取引のすべてを含む。同様に、ブロックＢＬＹは時刻ｔＹまで最新の成立した取引のすべてを含む。

前述したように、ノードサーバＮＳ１、ＮＳ２…ＮＳＸのそれぞれは、ブロックチェーン技術の下で、対応する部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸをこのときのマスタ部屋在庫記録ＲＩＴの内容と同期的に更新し続けるように求められる。よって、それぞれのノード送受信機ＮＴ１、ＮＴ２…ＮＴＸ（最も新しく生成されたブロックＢＬＹを送信するこのときのマスタ送受信機を除く。）を介して最も新しく生成されたブロックＢＬＹを受信した後、ノードプロセッサＮＰ１、ＮＰ２…ＮＰＸ（このときのマスタ部屋在庫記録ＲＩＴを除く。）は、当該最も新しく生成されたブロックＢＬＹを対応する部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸにそれぞれに組み入れる。いくつかの実施例において、ノードプロセッサＮＰ１、ＮＰ２…ＰＮＸは、少なくとも１つのスマートコントラクトの協力を要求し、最も新しい取引に関わる指令を同期的に実行し、対応する部屋在庫記録ＲＩ１、ＲＩ２…ＲＩＸの更新を完成する。更新は、例えば、部屋の予約状況または対応する部屋価格を含む特定のローカル変数の更新、または、条件付き割引または動的に調整された部屋価格を含む特定のグローバル変数の更新を含んでもよい。

図７は、一時的なマスタプロセッサＮＰＴがどのように新しいブロックを生成するかを詳細に示す。一時的なマスタプロセッサＮＰＴはハッシングモジュールＮＰＴ＿ＨとタイムスタンプモジュールＮＰＴ＿ＴＳとブロック生成モジュールＮＰＴ＿Ｂとを含む。前述したように、一時的なマスタプロセッサＮＰＴは成立した取引に応じて新しいブロックを生成する。一時的なマスタプロセッサＮＰＴが成立した取引を確認するとき、ハッシングモジュールＮＰＴ＿Ｈは新しいブロックに対して実質的に一意的なハッシュ値を生成し、タイムスタンプモジュールＮＰＴ＿ＴＳは新しいブロックに対して実質的に一意的なタイムスタンプを生成する。例えば、Ｙ個のブロックＢＬ１、ＢＬ２…ＢＬＹに対して、ハッシングモジュールＮＰＴ＿ＨはＹ個の実質的に一意的なハッシュ値ＨＳ１、ＨＳ２…ＨＳＹをそれぞれに生成し、タイムスタンプモジュールＮＰＴ＿ＴＳは実質的に一意的なタイムスタンプＴＳ１、ＴＳ２…ＴＳＹをそれぞれに生成する。

前述した実施例と同様に、ハッシュ値の生成方法はブロックチェーン技術の当業者にとっては周知であるため、ここでは詳細に説明しない。また、いくつかの実施例において、生成されたタイムスタンプは、一時的なマスタノードプロセッサＮＰＴが成立した取引を確認する時刻、または部屋予約要求が開始される時刻として参照され得て、当該部屋予約要求は、例えば、ＰＭＳモジュール２１０、または、ＯＴＡモジュールＯＴＡ１、ＯＴＡ２…ＯＴＡＭ、もしくはＮ個のブッキングエンジンＢＥ１、ＢＥ２…ＢＥＮのいずれか１つによって開始される。このように、ブロックＢＬ１、ＢＬ２…ＢＬＹのそれぞれは、それの実質的に一意的なハッシュ値と実質的に一意的なタイムスタンプとを有するはずである。また、最も新しく生成されたブロックＢＬＹは、最新に生成された複数のブロックのうちに、最も新しいタイムスタンプを有する。

成立した取引に応じて、ブロック生成モジュールＮＰＴ＿Ｂは、ブロックヘッダを生成するために、ハッシングモジュールＮＰＴ＿Ｈからの実質的に一意的なハッシュ値とタイムスタンプモジュールＮＰＴ＿ＴＳからの実質的に一意的なタイムスタンプとを組み入れる。例えば、最も新しい成立した取引に基づいて生成すべきブロックＢＬＹに対して、ブロック生成モジュールＮＰＴ＿Ｂはハッシュ値ＨＳＹとタイムスタンプＴＳＹとを取り入れてブロックヘッダＢＨＹを生成する。このように、ブロック生成モジュールＮＰＴ＿ＢはブロックヘッダＢＨ１、ＢＨ２…またはＢＨＹをそれぞれに生成する。

また、成立した取引に応じて、ブロック生成モジュールＮＰＴ＿Ｂは、対応するブロックヘッダと、成立した取引の内容と、少なくとも１つスマートコントラクトと、直前に生成したブロックの内容とを取り入れた新しいブロックを生成する。例えば、最も新しい成立した取引に応じて、ブロック生成モジュールＮＰＴ＿ＢはブロックＢＬＹを生成し、ブロックＢＬＹは、ブロックヘッダＢＨＹと、一時的なマスタノードメモリＮＴＴからロードした少なくとも１つの１つスマートコントラクトと、直前のブロックＢＬ（Ｙ－１）の内容（簡潔に説明するために図示せず）とを含む。このように、最も新しく成立したブロックＢＬＹは以前生成したブロックＢＬ１、ＢＬ２…ＢＬ（Ｙ－１）のすべての内容を含む。また、以前生成したブロックＢＬ１、ＢＬ２…ＢＬ（Ｙ－１）のすべてによって指される最新の成立した取引のすべては、最も新しく生成したブロックＢＬＹを参照するだけで簡単に監査し得る。

最後に、ブロック生成モジュールＮＰＴ＿Ｂは、ノードサーバＮＳ１、ＮＳ２…ＮＳＸによって形成されたブロックチェーンに新しいブロックを追加し、ブロックチェーンを更新する。例えば、ブロック生成モジュールＮＰＴ＿Ｂは、ブロックチェーンを更新するために、すでにブロックＢＬ１、ＢＬ２…ＢＬ（Ｙ－１）を含んでいるブロックチェーンに最も新しく生成したブロックＢＬＹを追加する。

部屋在庫管理システム２００と同様に、部屋在庫管理システム５００は、部屋在庫管理システム２００に関して言及した説明のように、実質的に同様な代替実施例、特性、および利点を有する。また、ノードサーバＮＳ１、ＮＳ２…ＮＳＸの間のマスタノードサーバとされる責務の転換は、時々に（ｆｒｏｍ ｔｉｍｅ ｔｏ ｔｉｍｅ）、周期的に、またはランダム的に実行され得る。また、マスタノードサーバの指定は、ノードサーバＮＳ１、ＮＳ２…ＮＳＸの間で、選挙、順次交替、または、マスタノードの責務についてバランスを取る所定ルールによって実行され得る。よって、ノードサーバＮＳ１、ＮＳ２…ＮＳＸはそれぞれの負担についてバランスをよりよく取って望ましくない故障を回避することができる。

好ましい一実施例において、図８のフローチャートに示すように、本発明のブロックチェーンに基づく部屋在庫管理システム２００を管理する方法は、以下のステップを含む。ステップＳ１は、ホテル部屋在庫管理システム２００における複数のノードサーバの各ノードサーバ内に、所与のホテル部屋品目（ｉｔｅｍ）に関するすべての成立した取引（ｓｕｃｃｅｓｓｆｕｌ ｔｒａｎｓａｃｔｉｏｎｓ）を記憶するブロックチェーンを維持し、ホテル部屋在庫管理システム２００は複数のノードサーバを有し、各ノードサーバはブロックチェーンの複写を維持する。ブロックチェーンは、時間順に単独にリンクされる複数のブロックＹを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックＹを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、所与のホテル部屋品目に関する成立した取引を記憶する。

ステップＳ２において、ホテル部屋在庫管理システム２００に通信上結合されたコンピュータネットワークを介して部屋予約イベントを受信すると、複数のノードサーバの中のマスタノードサーバにより、部屋予約イベントを表す新しい取引をブロックチェーンに記憶されるベース（ｂａｓｅ）スマートコントラクトにサブミットすることによって、部屋予約イベントが成立可能かどうかを判断する。部屋予約イベントは、コンピュータネットワークを介して、ホテル、予約エンジン、オンライントラベルエージェンシー（ＯＴＡ）、グローバルディストリビューションシステム、および／またはメタサーチエンジンから受信される。コンピュータネットワークを介したホテル部屋在庫管理システム２００との通信は、少なくとも部分的に、リモートプロシージャコール（ＲＰＣ）プロトコルに従う。取引プロキシサーバ２６０は、部屋在庫記録２６８を維持し、また、部屋在庫記録２６８が現在、ステップＳ２の前の部屋予約イベントを満たしているかどうかをチェックする（部屋在庫記録２６８および現在の部屋在庫は、前の部屋予約イベントに基づいて記録され、ブロックチェーンで処理された実際の部屋在庫と正確に等しくない可能性がある）。部屋在庫記録２６８が部屋予約イベントを満たすとき、ステップＳ２．１において、ベーススマートコントラクトは、部屋予約イベントの新しい取引を受信し、プログラムされた基準を実行し、プログラムされた基準は、ブロックチェーンからの所与のホテル部屋品目の実際の数量残高に基づいて、サブミットされた新しい取引が、所与のホテル部屋品目に関するブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突（ｃｏｎｆｌｉｃｔ）を表すかどうかを判断するように構成される。好ましい一実施例において、プログラムされた基準に基づいて、ベーススマートコントラクトは、ブロックチェーンの最新ブロックに記憶された現在の数量残高、所与のホテル部屋品目のホテル位置、所与のホテル部屋品目の部屋タイプ、および／または所与のホテル部屋品目に関する部屋予約イベントの時間範囲を決定して、サブミットされた新しい取引が何らかの衝突を引き起こすか否かを判断する。

取引プロキシサーバ２６０は、オラクル（ｏｒａｃｌｅ）とみなすことができる。それは、ブロックチェーンに基づく部屋在庫管理システム２００がプライベートブロックチェーン上に確立されるとき、必ずしもオラクルではない。それにもかかわらず、ブロックチェーンに基づく部屋在庫管理システム２００がイーサリアムなどのパブリックブロックチェーン上に確立される場合、取引プロキシサーバ２６０は、非中央集権化のためのコンセンサスアルゴリズムに基づくオラクルである必要がある場合がある。

ステップＳ３において、ベーススマートコントラクトに基づいて、部屋予約イベントを表す新しい取引が成立可能であると判断すると、マスタノードサーバにより、ブロックチェーンに付加される（ａｔｔａｃｈｅｄ）新しいブロックを作成する。新しいブロックは、部屋予約イベントを表す新しい取引がベーススマートコントラクトによって成立すると判断できるときのみ作成される。新しいブロックは、新しい取引を成立として表すデータを記憶し、上記新しいブロックの作成は、ホテル部屋在庫管理システム２００における複数のノードサーバの各ノードサーバ内のブロックチェーンに新しいブロックを追加させる。サブミットされた取引が衝突を示す場合、この取引は失敗とみなされ、直ちに破棄される。ブロックチェーンのブロックＹは、部屋ブッキング要求、部屋キャンセル要求、または部屋チェックアウト要求のうちの１つを有する成立した取引を含みんでもよく、成立した取引がいつ発行され／受領され（ｒｅｃｅｉｐｔｅｄ）たかを登録するためのタイムスタンプを用いて時間順にリンクされる。成立した取引のすべてがブロックチェーンに記録され、変更できない。

ステップＳ４において、ベーススマートコントラクトは、所与のホテル部屋品目の現在の数量残高に関する、コンピュータネットワークまたは取引プロキシサーバ２６０を介して受信されたクエリ（ｑｕｅｒｙ）に応答して、所与のホテル部屋品目の実際の数量残高を表すブロックチェーンの最新ブロック（または、マークル木などのアルゴリズムに従った対応するブロック）内のデータを、クエリの送信者に通信するように構成される。取引プロキシサーバ２６０は、ＰＭＳモジュール２１０との間で現在の数量残高をプッシュし、または同期させて、ＰＭＳモジュール２１０の部屋在庫記録２１８と同じである部屋在庫記録２６８の記録をつけ、それにより、ＯＴＡモジュールＭおよびブッキングエンジンＮは、部屋在庫の現在の数量残高にアクセスすることができる。

新しい取引に加えて、新しいブロックに記憶されたデータは、所与のホテル部屋品目に関するすべての前の成立した取引をさらに示す。新しいブロックに記憶されたデータは、一意的なブロックヘッダ、新しい取引を表す日付、および新しいブロックの直前のブロックの内容を表す暗号データを含む。一意的なブロックヘッダは、新しいブロックの一意的なハッシュ値、新しい取引が発行または受領されたときの時間を表す一意的なタイムスタンプを含む。所与のホテル部屋品目は、選択日付または選択期間における選択ホテル内の選択部屋タイプである。部屋予約イベントは、部屋予約／ブッキング要求、部屋チェックアウト要求、または部屋キャンセル要求とすることができる。

好ましい一実施例において、各ホテルは、その独自のブロックチェーンを有し、異なるホテルは、異なるブロックチェーンをそれぞれ有する。別の好ましい実施例において、すべての異なるホテルが、同じブロックチェーンを共有することができる。異なるホテル部屋品目からの別の成立した取引が、新しい取引と実質的に同時に生じていてもよく、異なるホテル部屋品目のすべての成立した取引が、ホテル部屋品目に関する新しい取引と実質的に同時にホテル部屋在庫管理システム２００内で生じていてもよい。

ベーススマートコントラクトが部屋予約イベントを受信し、部屋予約イベントが部屋ブッキング要求であるとき、ベーススマートコントラクトのプログラムされた基準は、部屋ブッキング要求を実行した後、所与のホテル部屋品目の現在の数量残高が所定の最大閾値を上回るかどうかを検証する（部屋在庫が十分であることを保証するために）。ベーススマートコントラクトは実際の数量残高を計算し、マスタノードサーバは実際の数量残高、一意的なタイムスタンプ、一意的なハッシュ、および部屋ブッキング要求を新しいブロックにパックする。新しいブロックはマスタノードサーバのブロックチェーンにアペンドされ、他のノードサーバにブロードキャストされる。取引プロキシサーバ２６０は、新しいブロックがブロックチェーンに成功裏にアペンドされたとき、実際の数量残高に近い現在の数量残高に近づくように、その部屋在庫記録２６８をブロックチェーン内の新しいブロックから（ベーススマートコントラクトを介して）自動的に更新し、それにより、ユーザは、ホテルの部屋を予約／ブッキングすることができる。部屋在庫記録２６８（または、現在の数量残高）は、実際の数量残高と同じでない可能性があり、なぜならば、次の新しいブロックは、時々にブロードキャストされる可能性があり、取引プロキシサーバ２６０は、ベーススマートコントラクトを介してブロックチェーンに新たにアペンドされ、かつノードサーバの大部分によって確認されているブロックからの情報のみを取得できるためである。新しいブロックがブロックチェーンに追加された後、部屋在庫記録２６８の所与のホテル部屋品目の現在の数量残高は、新しい取引で指定される量だけ減らされる。マスタノードサーバによって生成された、異なるＯＴＡ（またはユーザ）からの同じまたは重複した部屋予約イベントを有する、いくつかの新しいブロックＢＬ１Ｙ、ＢＬ２Ｙ…ＢＬＸＹがある場合、ノードサーバの大部分によりブロードキャストされ、受け入れられたいくつかの新しいブロックＢＬ１Ｙ、ＢＬ２Ｙ…ＢＬＸＹのうちの１つが、最新の／最も新しいブロックになる。最新の／最も新しいブロックが確認されたときのみ、部屋ブッキング要求が完了し、他の新しいブロックは破棄される。同様に、部屋キャンセル要求および部屋チェックアウト要求は同じプロシージャで処理される。

部屋予約イベントが部屋キャンセル要求または部屋チェックアウト要求であるとき、プログラムされた基準は、部屋キャンセル要求または部屋チェックアウト要求を実行した後、所与のホテル部屋品目の現在の数量残高が所定の最小閾値を下回るかどうかを検証する。新しいブロックがブロックチェーンに追加された後、部屋在庫記録２６８の所与のホテル部屋品目の現在の数量残高は、新しい取引で指定される量だけ増やされる。好ましい一実施例において、所定の最小閾値はゼロである。すべての成立した取引が一意的なタイムスタンプと共にブロックチェーンに記録され、新しいブロックは新しいブロックの取引が成立するときのみブロックチェーンにアペンドされるため、ブロックチェーンに記録された現在の数量残高は信頼でき、信用できる。本発明のブロックチェーンに基づく部屋在庫管理システム２００で生じるオーバーブッキング問題はない。

好ましい一実施例において、ブロックチェーンに基づく部屋在庫管理システム２００を管理する方法は、監査プロシージャをさらに含み、監査プロシージャは、ブロックチェーン内の各ブロックのブロックヘッダを読み取って、各ブロックの直前のブロックの位置を特定することと、ブロックチェーン内の各ブロック内のタイムスタンプを確認して、各ブロックを開始した成立した取引を識別して、すべてのブロックＹ内のタイムスタンプが時間順に列挙されていることを検証することによってブロックチェーンの完全性を保証することに基づく。

所定ルールに基づいて、マスタノードサーバは、ホテル部屋在庫管理システム２００における複数のノードサーバの中の特定のグループのノードサーバから選択され、マスタノードサーバは、部屋在庫管理システム２００のすべてのノードサーバＮＳ１－ＮＳＸの中の唯一のノードサーバであり、すべてのレコードおよび内容をパックして、新しいブロックＢＬ１Ｙ、ＢＬ２Ｙ…ＢＬＸＹを作成することができる。所定ルールは、順次順序、ランダムな順序、選挙、複数のノードサーバにポーリングする（ｐｏｌｌｉｎｇ）ことを含むコンセンサス、システムの現在のワークロードの比較、利用可能なストレージのサイズ、および／または新しい候補ノードサーバに対する既存のマスタノードサーバの送信帯域幅、のルールのうちの１つ以上に基づいてマスタノードサーバを選択することを含む。

動的価格設定

図９に示すフローチャートのステップＳ５に示すように、部屋予約イベントを有するブロックがブロックチェーンにアペンドされるとき、現在の数量残高は、成立した取引に従ってベーススマートコントラクトにより計算され、所定の変動（ｆｌｕｃｔｕａｔｉｏｎ）ルールに達し、所定の変動ルールは、所定の変動閾値（閾値より低い値または高い値とすることができる）、部屋在庫のブッキングされた部屋量に対するブッキングされていない部屋量の比率、所定の日付に近い現在の日付、または特定の期間を含む。所定の変動閾値は、残り部屋量／比率とすることができ、所定の日付は、特定の休日とすることができる。ベーススマートコントラクトは、変動スマートコントラクトをトリガする（ｔｒｉｇｇｅｒｓ）。変動スマートコントラクトは、ベーススマートコントラクトの一部として統合し、あるいはブロックチェーンの異なるブロックに記憶された別のスマートコントラクトとしてモジュール化することができる。ベーススマートコントラクトに書き込まれた元の部屋価格は、価格割引パラメータまたは価格上昇パラメータを乗じられ、これらは、変動スマートコントラクトに予め書き込むことができる（例えば、部屋在庫記録２６８の現在の数量残高が、特定の期間内に部屋在庫／ストックの５分の１を有するとき、変動スマートコントラクトが、ベーススマートコントラクトによってトリガされ、次いで、これらの残りの部屋の価格は、売上を刺激するために５０％オフなどの割引パラメータを乗じられる）。部屋予約イベントを有する取引が、現在の数量残高の変化を引き起こして変動スマートコントラクトを（ベーススマートコントラクトを介して）トリガするとき、取引プロキシサーバ２６０は、ベーススマートコントラクトまたは変動スマートコントラクトから調整された価格を取得し、ブロックチェーンの新しいブロックに示すことができる。割引／上昇パラメータは、変動スマートコントラクトに書き込む、あるいはブロックチェーンの別のブロックに書き込むことができる。変動スマートコントラクトは、ブロックチェーンの対応する１つのブロックに書き込まれた新しい割引／上昇パラメータを検索／追跡することができる。

部屋キャンセル要求または部屋チェックアウト要求などの部屋予約イベントを有する特定の成立した取引を実行した後、ベーススマートコントラクトは、新しい取引を処理しながら、所定の変動閾値から離れた値に達するように増加した実際の数量残高を計算し、ベーススマートコントラクトは、変動スマートコントラクトのトリガを停止し、元の部屋価格を使用し、元の部屋価格は、ベーススマートコントラクトに最初に書き込むことができる。部屋予約イベントの新しい取引を表す新しいブロックがブロックチェーンにアペンドされるとき、取引プロキシサーバ２６０は、ベーススマートコントラクト（およびマスタノードサーバ）によって新しいブロックから更新された部屋価格を取得する。

ステップＳ６において、所定の変動閾値および／または割引／上昇パラメータは、ベーススマートコントラクトを介してブロックチェーンにアペンドされる新しいブロックとして新しい取引をサブミットすることによって更新することができる。新しい取引は、更新される新しい所定の変動閾値および／または新しい割引／上昇パラメータを表す。ベーススマートコントラクトは、新しい所定の変動閾値および／または新しい割引／上昇パラメータの内容が確認されると、新しい取引を受け入れる。マスタノードサーバは、新しい取引をブロックチェーンにアペンドされる新しいブロックとしてパックする。ベーススマートコントラクトが現在の数量残高を計算し、残りの部屋量を取得すると、ベーススマートコントラクトは、新しい所定の変動閾値をチェックして、現在の数量残高が新しい所定の変動閾値の範囲内に入るかを確認する。ステップＳ７において、プログラムされた基準が、所与のホテル部屋品目の現在の数量残高に関してサブミットされた新しい取引を判断するように構成されるとき、ベース／変動スマートコントラクトは、所定の変動閾値が新たに更新されるかどうかをチェックする。好ましい一実施例において、変動スマートコントラクトは、部屋価格が動的価格設定に基づいて新しく、正しいことを保証するために、変動スマートコントラクトがトリガされるときに、割引／上昇パラメータが新しいかどうかを（マークル木を介して対応するブロックを検索することにより）チェックする。ステップＳ８において、変動スマートコントラクトは（あるいは、ベーススマートコントラクトを介して）、市場価格が所与のホテル部屋品目に対して調整されるかどうかについての市場価格に関するクエリに応答することができる。変動スマートコントラクトは、市場が調整される場合、クエリの送信者に対して、ブロックチェーンの新しいブロック（または対応するブロック）から、調整された市場価格を表すデータを（マークル木アルゴリズムを用いて）検索することができる（ステップＳ８．１）。市場価格が調整されないとき、ベーススマートコントラクトは、クエリの送信者に対して、ベーススマートコントラクト自体から、所与のホテル部屋品目の元の価格を提示するデータを検索することができる（ステップＳ８．２）。本発明のスマートコントラクトの動的価格設定はブロックチェーンに記録され、公開で読むことが可能であり、顧客およびトラベルエージェントにとって公平である。ブロックチェーンの性質に基づいて、市場価格は、市場メカニズムに基づく価格を真に反映するように、自動的に調整され、誰かにより秘密裏に操作されることはない。

別の好ましい実施例において、本発明のブロックチェーンに基づく部屋在庫管理システム２００は、複数のノードサーバ、ベーススマートコントラクト、およびマスタノードサーバを含む。複数のノードサーバの各ノードサーバは、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持するように構成される。ブロックチェーンは、時間順に単独にリンクされる複数のブロックＹを含む。各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照する。各ブロックは、所与のホテル部屋品目に関する成立した取引を記憶する。ベーススマートコントラクトは、ブロックチェーンに記憶される。ベーススマートコントラクトは、所与のホテル部屋品目の現在の数量残高に基づいて、サブミットされた取引が、所与のホテル部屋品目に関するブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含む。マスタノードサーバは、部屋在庫管理システム２００に通信上結合されたコンピュータネットワークから部屋予約イベントを受信し；部屋予約イベントを表す新しい取引をベーススマートコントラクトにサブミットすることによって、部屋予約イベントが成立可能かどうかを判断し；ベーススマートコントラクトに基づいて、部屋予約イベントを表す新しい取引が成立可能であると判断すると、ブロックチェーンに付加される新しいブロックを作成する；ように構成される。新しいブロックは、新しい取引を成立として表すデータを記憶する。新しいブロックの作成は、部屋在庫管理システム２００における複数のノードサーバの各ノードサーバ内のブロックチェーンに新しいブロックを追加させる。ベーススマートコントラクトは、所与のホテル部屋品目の現在の数量残高、特定の予約日付、または特定の期間に基づいて所与のホテル部屋品目の市場価格を調整し、コンピュータネットワークを介して所与のホテル部屋品目のエージェントまたは管理者との間で所与のホテル部屋品目の調整された市場価格に関して通信するために、変動スマートコントラクトをトリガすることができる。

別の好ましい実施例において、本発明の非一時的コンピュータ読取可能媒体は、複数の命令を含み、複数の命令は、コンピュータ化されたホテル部屋在庫管理システム２００の１つ以上のプロセッサにより実行されると、システム２００に：ホテル部屋在庫管理システム２００における複数のノードサーバの各ノードサーバ内に、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持し、ブロックチェーンは、所与のホテル部屋品目に関する成立した取引を記憶し、ブロックチェーンは、時間順に単独にリンクされる複数のブロックＹを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、所与のホテル部屋品目に関する成立した取引を記憶し；ホテル部屋在庫管理システム２００に通信上結合されたコンピュータネットワークから部屋の予約イベントを受信すると、複数のノードサーバの中のマスタノードサーバにより、部屋予約イベントを表す新しい取引をブロックチェーンに記憶されるベーススマートコントラクトにサブミットすることによって、部屋の予約イベントが成立可能かどうかを判断し、ベーススマートコントラクトは、所与のホテル部屋品目の現在の数量残高に基づいて、サブミットされた取引が、所与のホテル部屋品目に関するブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含み；スマートコントラクトに基づいて、部屋予約イベントを表す新しい取引が成立可能であると判断すると、マスタノードサーバにより、ブロックチェーンに付加される新しいブロックを作成し、新しいブロックは、新しい取引を成立として表すデータを記憶し、上記新しいブロックの作成は、ホテル部屋在庫管理システム２００における複数のノードサーバの各ノードサーバ内のブロックチェーンに新しいブロックを追加させる；ことをさせる。ベーススマートコントラクトはまた、所与のホテル部屋品目の市場価格を調整するために変動スマートコントラクトをトリガすることもできる。

当業者は、アプリケーションに関連する検索方法が、前に詳細に説明した、アプリのコンテキストに対する検索方法と同様であることを理解する。よって、アプリに関連するすべての実施例、方法、システム、および要素はアプリケーションに適用される。

Claims (10)

1. ホテル部屋在庫システムにおける複数のノードの各ノード内に、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持するステップであり、
   前記ブロックチェーンは、時間順に単独にリンクされる複数のブロックを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、前記所与のホテル部屋品目に関する成立した取引を記憶する、ステップと、
   前記ホテル部屋在庫システムに通信上結合されたコンピュータネットワークから部屋予約イベントを受信すると、前記複数のノードの中のマスタノードにより、前記部屋予約イベントを表す新しい取引を前記ブロックチェーンに記憶されるスマートコントラクトにサブミットすることによって、前記部屋予約イベントが成立可能かどうかを判断するステップであり、
   前記スマートコントラクトは、前記所与のホテル部屋品目の現在の数量残高に基づいて、前記サブミットされた取引が、前記所与のホテル部屋品目に関する前記ブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含み、前記スマートコントラクトは、前記所与のホテル部屋品目のホテル位置、前記所与のホテル部屋品目の部屋タイプ、および／または前記所与のホテル部屋品目に関する前記部屋予約イベントの時間範囲にさらに基づいて前記衝突を判断するように構成される、ステップと、
   前記スマートコントラクトに基づいて、前記部屋予約イベントを表す前記新しい取引が成立可能であると判断すると、前記マスタノードにより、前記ブロックチェーンに付加される新しいブロックを作成するステップであり、前記新しいブロックは、前記新しい取引を成立として表すデータを記憶し、
   前記新しいブロックの作成は、前記ホテル部屋在庫システムにおける前記複数のノードの各ノード内の前記ブロックチェーンに前記新しいブロックを追加させ、前記新しいブロックは、前記部屋予約イベントを表す前記新しい取引が成立可能であるときのみ作成される、ステップと、
   所定の変動パラメータに基づいて、前記スマートコントラクトにより、前記部屋予約イベントが所定の変動閾値を満たす前記現在の数量残高をもたらしたとき、前記所与のホテル部屋品目の市場価格を自動的に調整するステップと、
   前記新しい取引を前記スマートコントラクトにサブミットすることによって、前記所定の変動閾値または前記所定の変動パラメータを更新するステップであり、更新された変動閾値または更新された変動パラメータを表す前記新しい取引は、前記スマートコントラクトにより確認され、前記ブロックチェーンにアペンドされる前記新しいブロックとしてパックされる、ステップと、
   を含む方法。
2. 前記所定の変動閾値は、前記スマートコントラクトにより計算される前記所与のホテル部屋品目の前記現在の数量残高、特定の日付に近い現在の日付、または特定の期間であり、
   前記所定の変動パラメータは、割引パラメータまたは上昇パラメータである、
   請求項１に記載の方法。
3. 前記プログラムされた基準が、前記所与のホテル部屋品目の前記現在の数量残高に基づいて前記サブミットされた新しい取引を判断するように構成されるとき、前記スマートコントラクトにより、前記新しい変動閾値または前記新しい変動パラメータが新たに更新されるかどうかをチェックするステップ、をさらに含み、
   前記所定の変動閾値は、前記スマートコントラクトにより計算される前記所与のホテル部屋品目の前記現在の数量残高、特定の日付に近い現在の日付、または特定の期間であり、
   前記所定の変動パラメータは、割引パラメータまたは上昇パラメータである、
   請求項１に記載の方法。
4. 前記スマートコントラクトは、前記市場価格が前記所与のホテル部屋品目に対して調整されるかどうかについての、前記市場価格に関する前記コンピュータネットワークを介して受信されたクエリに応答して、前記市場価格が調整される場合、前記クエリの送信者に対して、前記ブロックチェーンの前記新しいブロックから、前記調整された市場価格を表すデータを検索し、前記市場価格が調整されない場合、前記クエリの前記送信者に対して、前記スマートコントラクトから、前記所与のホテル部屋品目を提示する元の価格を取得するように構成され、
   前記スマートコントラクトは、前記所与のホテル部屋品目の前記現在の数量残高に関する前記コンピュータネットワークを介して受信された前記クエリに応答して、前記ブロックチェーンの前記新しいブロックからの前記現在の数量残高を表すデータを前記クエリの前記送信者に通信するように構成される、
   請求項１に記載の方法。
5. 前記所与のホテル部屋品目は、選択日付における選択ホテル内の選択部屋タイプであり、
   前記部屋予約イベントは、部屋ブッキング要求、部屋チェックアウト要求、または部屋キャンセル要求であり、
   前記プログラムされた基準は、前記所与のホテル部屋品目の前記現在の数量残高が、ブッキングイベントを実行した後に所定の最大閾値を上回るかどうかを検証することを含み、前記所与のホテル部屋品目の前記現在の数量残高は、前記新しいブロックが前記ブロックチェーンに追加された後、前記新しい取引で指定される量だけ減らされ、
   前記プログラムされた基準は、前記所与のホテル部屋品目の前記現在の数量残高が、キャンセルイベントまたはチェックアウトイベントを実行した後に所定の最小閾値を下回るかどうかを検証することを含み、前記所与のホテル部屋品目の前記現在の数量残高は、前記新しいブロックが前記ブロックチェーンに追加された後に増やされる、
   請求項１に記載の方法。
6. ホテル部屋在庫システムであって、
   複数のノードであり、複数のノードの各ノードは、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持するように構成され、
   前記ブロックチェーンは、時間順に単独にリンクされる複数のブロックを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、前記所与のホテル部屋品目に関する成立した取引を記憶する、複数のノードと、
   前記ブロックチェーンに記憶されるスマートコントラクトであり、前記スマートコントラクトは、前記所与のホテル部屋品目の現在の数量残高に基づいて、サブミットされた取引が、前記所与のホテル部屋品目に関する前記ブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含み、前記スマートコントラクトは、前記所与のホテル部屋品目のホテル位置、前記所与のホテル部屋品目の部屋タイプ、および／または前記所与のホテル部屋品目に関する部屋予約イベントの時間範囲にさらに基づいて前記衝突を判断するように構成される、スマートコントラクトと、
   マスタノードであり、
   当該ホテル部屋在庫システムに通信上結合されたコンピュータネットワークから部屋予約イベントを受信し、
   前記部屋予約イベントを表す新しい取引を前記スマートコントラクトにサブミットすることによって、前記部屋予約イベントが成立可能かどうかを判断し、
   前記スマートコントラクトに基づいて、前記部屋予約イベントを表す前記新しい取引が成立可能であると判断すると、前記ブロックチェーンに付加される新しいブロックを作成し、前記新しいブロックは、前記新しい取引を成立として表すデータを記憶する、ように構成され、
   前記新しいブロックの作成は、当該ホテル部屋在庫システムにおける前記複数のノードの各ノード内の前記ブロックチェーンに前記新しいブロックを追加させ、前記新しいブロックは、前記部屋予約イベントを表す前記新しい取引が成立可能であるときのみ作成される、マスタノードと、を含み、
   前記スマートコントラクトは、所定の変動パラメータに基づいて、前記部屋予約イベントが、前記現在の数量残高または予約時間の期間を含む所定の変動閾値を満たす前記現在の数量残高をもたらしたとき、前記所与のホテル部屋品目の市場価格を自動的に調整し、
   前記所定の変動閾値または前記所定の変動パラメータは、前記新しい取引を前記スマートコントラクトにサブミットすることによって更新され、更新された変動閾値または更新された変動パラメータを表す前記新しい取引は、前記スマートコントラクトにより確認され、前記ブロックチェーンにアペンドされる前記新しいブロックとしてパックされる、システム。
7. 前記所定の変動閾値は、前記スマートコントラクトにより計算される前記所与のホテル部屋品目の前記現在の数量残高、特定の日付に近い現在の日付、または特定の期間であり、
   前記所定の変動パラメータは、割引パラメータまたは上昇パラメータである、
   請求項６に記載のシステム。
8. 前記プログラムされた基準が、前記所与のホテル部屋品目の前記現在の数量残高に基づいて前記サブミットされた新しい取引を判断するように構成されるとき、前記新しい変動閾値または新しい変動パラメータが新たに更新されるかどうかを確認するために、前記新しい変動閾値または新しい変動パラメータは、前記スマートコントラクトによりチェックされ、
   前記所定の変動閾値は、前記スマートコントラクトにより計算される前記所与のホテル部屋品目の前記現在の数量残高、特定の日付に近い現在の日付、または特定の期間であり、
   前記所定の変動パラメータは、割引パラメータまたは上昇パラメータである、
   請求項６に記載のシステム。
9. 複数の命令を含む非一時的コンピュータ読取可能媒体であって、前記複数の命令は、コンピュータ化されたホテル部屋在庫システムの１つ以上のプロセッサにより実行されると、前記ホテル部屋在庫システムに、
   前記ホテル部屋在庫システムにおける複数のノードの各ノード内に、所与のホテル部屋品目に関するすべての成立した取引を記憶するブロックチェーンを維持し、
   前記ブロックチェーンは、時間順に単独にリンクされる複数のブロックを含み、各ブロックは、いずれのブロック内のデータもすべての後続ブロックを変更することなく変更できないように、その直前のブロックを暗号的に参照し、各ブロックは、前記所与のホテル部屋品目に関する成立した取引を記憶し、
   前記ホテル部屋在庫システムに通信上結合されたコンピュータネットワークから部屋予約イベントを受信すると、前記複数のノードの中のマスタノードにより、前記部屋予約イベントを表す新しい取引を前記ブロックチェーンに記憶されるスマートコントラクトにサブミットすることによって、前記部屋予約イベントが成立可能かどうかを判断し、
   前記スマートコントラクトは、前記所与のホテル部屋品目の現在の数量残高に基づいて、前記サブミットされた取引が、前記所与のホテル部屋品目に関する前記ブロックチェーンに現在記憶されているすべての既存の成立した取引に対する衝突を表すかどうかを判断するように構成された、プログラムされた基準を含み、前記スマートコントラクトは、前記所与のホテル部屋品目のホテル位置、前記所与のホテル部屋品目の部屋タイプ、および／または前記所与のホテル部屋品目に関する前記部屋予約イベントの時間範囲にさらに基づいて前記衝突を判断するように構成され、
   前記スマートコントラクトに基づいて、前記部屋予約イベントを表す前記新しい取引が成立可能であると判断すると、前記マスタノードにより、前記ブロックチェーンに付加される新しいブロックを作成し、前記新しいブロックは、前記新しい取引を成立として表すデータを記憶し、
   前記新しいブロックの作成は、前記ホテル部屋在庫システムにおける前記複数のノードの各ノード内の前記ブロックチェーンに前記新しいブロックを追加させ、前記新しいブロックは、前記部屋予約イベントを表す前記新しい取引が成立可能であるときのみ作成される、ことをさせ、
   前記スマートコントラクトは、所定の変動パラメータに基づいて、前記部屋予約イベントが、前記現在の数量残高または予約時間の期間を含む所定の変動閾値を満たす前記現在の数量残高をもたらしたとき、前記所与のホテル部屋品目の市場価格を自動的に調整し、
   前記所定の変動閾値または前記所定の変動パラメータは、前記新しい取引を前記スマートコントラクトにサブミットすることによって更新され、更新された変動閾値または更新された変動パラメータを表す前記新しい取引は、前記スマートコントラクトにより確認され、前記ブロックチェーンにアペンドされる前記新しいブロックとしてパックされる、非一時的コンピュータ読取可能媒体。
10. 前記プログラムされた基準が、前記所与のホテル部屋品目の前記現在の数量残高に基づいて前記サブミットされた新しい取引を判断するように構成されるとき、前記新しい変動閾値または新しい変動パラメータが新たに更新されるかどうかを確認するために、前記新しい変動閾値または新しい変動パラメータは、前記スマートコントラクトによりチェックされ、
    前記所定の変動閾値は、前記スマートコントラクトにより計算される前記所与のホテル部屋品目の前記現在の数量残高、特定の日付に近い現在の日付、または特定の期間であり、
    前記所定の変動パラメータは、割引パラメータまたは上昇パラメータである、
    請求項９に記載の非一時的コンピュータ読取可能媒体。