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

Abstract

ブロックチェーンに基づく部屋在庫管理システムは、資産管理システム（ＰＭＳ）モジュールと中間サーバシステムとを含む。ＰＭＳモジュールは、ホテルに直接的に制御され得る。中間サーバシステムは、部屋予約イベントの確認および処理をするために、イーサリアムベースのスマートコントラクトを用いて、少なくとも１つのオンライントラベルエージェンシー（ＯＴＡ）および／または少なくとも１つのブッキングエンジンと通信する。部屋予約イベントが成立した取引として確認された場合、中間サーバシステムも成立した取引をＰＭＳモジュールと複数のノードサーバから形成されたブロックチェーンとに更新する。ブロックチェーンは、異なる時刻の成立した取引を区別するために時系列の順番で配置された複数のブロックを含む。こうすれば、それぞれの成立した取引について、後で成立した取引が誤って先行することを回避することができ、部屋在庫管理システムはオーバーブッキングの問題を改善することができる。

Description

関連出願の相互参照

この出願は、２０１７年１１月２０日に出願され「Ｐｒｏｐｅｒｔｙ ｍａｎａｇｅｍｅｎｔ ｂａｓｅｄ ｏｎ Ｅｔｈｅｒｅｕｍ」と題された米国仮出願第６２／５８８，９０９号に基づく優先権を主張する。この出願の内容は、その全体が参照により本明細書に援用される。

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

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

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

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

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

本開示は、ブロックチェーンに基づく部屋在庫管理システムを開示する。ブロックチェーンに基づく部屋在庫管理システムは資産管理システムと中間サーバシステムとを含む。資産管理システムはホスト送受信機とホスト不発揮性コンピュータ可読メモリとホストコンピュータプロセッサとを含む。ホスト送受信機は成立した取引を受信する。ホスト不発揮性コンピュータ可読メモリは、資産管理システムによって管理されたすべての部屋の予約状況（ａｖａｉｌａｂｉｌｉｔｙ）を記録する部屋在庫記録の複写を記憶する。ホストコンピュータプロセッサは、成立した取引を組み入れることによって、部屋在庫記録の複写を更新する。中間サーバシステムは取引プロキシサーバと複数のノードサーバとを含む。取引プロキシサーバは中間送受信機と中間不発揮性コンピュータ可読メモリと中間コンピュータプロセッサとを含む。中間送受信機は、部屋予約イベントを受信し、成立した取引を資産管理システムへ転送し、成立した取引に応じて生成される新しいブロックを転送する。中間不発揮性コンピュータ可読メモリは、イーサリアム（登録商標）に基づいて生成される複数のスマートコントラクトを記憶し、複数のスマートコントラクトの少なくとも１つを用いて実行される部屋在庫記録を記憶し、複数のブロックを含むブロックチェーンを記憶する。ブロックチェーンにおいて最も新しく追加されたブロックは、資産管理システムにおける最新の成立した取引のすべてを担持する。中間コンピュータプロセッサは、部屋予約イベントが部屋在庫記録においてオーバーブッキングを起こすか否かを確認する。また、中間コンピュータプロセッサは、部屋予約イベントがローカルの部屋在庫記録においてオーバーブッキングを起こさないと確認したとき、部屋予約イベントが成立することを決定して部屋予約イベントの情報を用いて成立した取引を生成する。中間コンピュータプロセッサはハッシングモジュールとタイムスタンプモジュールとブロック生成モジュールとを含む。ハッシングモジュールは、成立した取引に応じて、新しいブロックに対してハッシュ値を生成する。タイムスタンプモジュールは、成立した取引に応じて、新しいブロックに対して一意的なタイムスタンプを生成する。ブロック生成モジュールは、成立した取引に応じて、少なくとも一意的なハッシュ値、一意的なタイムスタンプ、および最も新しく追加されたブロックの内容を用いて新しいブロックに対して一意的なブロックヘッダを生成する。また、ブロック生成モジュールは、一意的なブロックヘッダ、成立した取引の情報、複数のスマートコントラクトの少なくとも１つ、および最も新しく追加されたブロックの内容を含む新しいブロックを生成する。さらに、ブロック生成モジュールは、新しいブロックをブロックチェーンに追加する。複数のノードサーバのそれぞれは、ノード送受信機とノード不発揮性コンピュータ可読メモリとノードコンピュータプロセッサとを含む。ノード送受信機は中間送受信機から新しいブロックを受信する。ノード不発揮性コンピュータ可読メモリはブロックチェーンの複写を記憶する。ノードコンピュータプロセッサは、新しいブロックをブロックチェーンの複写に追加することによって、ブロックチェーンの複写を更新する。

また、本開示は、他のバージョンの、ブロックチェーンに基づく部屋在庫管理システムを開示する。当該ブロックチェーンに基づく部屋在庫管理システムは資産管理システムと中間サーバシステムとを含む。資産管理システムはホスト送受信機とホスト不発揮性コンピュータ可読メモリとホストコンピュータプロセッサとを含む。ホスト送受信機は成立した取引を受信する。ホスト不発揮性コンピュータ可読メモリは、資産管理システムによって管理されたすべての部屋の予約状況（ａｖａｉｌａｂｉｌｉｔｙ）を記録する部屋在庫記録の複写を記憶する。ホストコンピュータプロセッサは、成立した取引を組み入れることによって、部屋在庫記録の複写を更新する。中間サーバシステムは複数のノードサーバを含む。複数のノードサーバのそれぞれは、ノード送受信機とノード不発揮性コンピュータ可読メモリとノードコンピュータプロセッサとを含む。ノード送受信機は、部屋予約イベントを受信し、成立した取引を資産管理システムへ転送し、成立した取引に応じて生成される新しいブロックを転送する。ノード不発揮性コンピュータ可読メモリは、イーサリアムに基づいて生成される複数のスマートコントラクトを記憶する。また、ノード不発揮性コンピュータ可読メモリは、複数のブロックを含むブロックチェーン、またはブロックチェーンの複写を記憶する。ブロックチェーンにおいて最も新しく追加されたブロックは、資産管理システムにおける最新の成立した取引のすべてを担持する。部屋在庫記録は、複数のスマートコントラクトの少なくとも１つを用いて実行される。ノードコンピュータプロセッサは、記憶されたブロックチェーンまたは記憶されたブロックチェーンの複写に新しいブロックを追加することによって、記憶されたブロックチェーンまたは記憶されたブロックチェーンの複写を更新する。ノードコンピュータプロセッサはハッシングモジュールと、タイムスタンプモジュールと、ブロック生成モジュールとを含む。複数のノードサーバは、コンセンサスアルゴリズム（ｃｏｎｓｅｎｓｕｓ ａｌｇｏｒｉｔｈｍ）を用いて、複数のノードサーバのうちからマスタノードサーバを一時的に選択する。マスタノードサーバのノードコンピュータプロセッサは、部屋予約イベントが部屋在庫記録においてオーバーブッキングを起こすか否かを確認する。また、マスタノードサーバのノードコンピュータプロセッサは、部屋予約イベントが部屋在庫記録においてオーバーブッキングを起こさないと確認したとき、部屋予約イベントが成立することを決定して部屋予約イベントの情報を用いて成立した取引を生成する。ハッシングモジュールは、成立した取引に応じて、新しいブロックに対してハッシュ値を生成する。マスタノードサーバのタイムスタンプモジュールは、成立した取引に応じて、新しいブロックに対して一意的なタイムスタンプを生成する。マスタノードサーバのブロック生成モジュールは、成立した取引に応じて、少なくとも一意的なハッシュ値、一意的なタイムスタンプ、および最も新しく追加されたブロックの内容を用いて新しいブロックに対して一意的なブロックヘッダを生成する。また、マスタノードサーバのブロック生成モジュールは、一意的なブロックヘッダ、成立した取引の情報、複数のスマートコントラクトの少なくとも１つ、および最も新しく追加されたブロックの内容を含む新しいブロックを生成する。さらに、マスタノードサーバのブロック生成モジュールは、マスタノードサーバのノード不発揮性コンピュータ可読メモリに記憶されたブロックチェーンに新しいブロックを追加する。マスタノードサーバ以外の複数のノードサーバのノードコンピュータプロセッサのブロック生成モジュールは、成立した取引に応じて、それぞれのノード不発揮性コンピュータ可読メモリに記憶されたブロックチェーンの複写に新しいブロックを追加する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (22)

1. ブロックチェーンに基づく部屋在庫管理システムであって、
   資産管理システムであって、
   成立した取引を受信するように構成されたホスト送受信機と、
   前記資産管理システムによって管理されたすべての部屋の予約状況を記録する部屋在庫記録の複写を記憶するように構成されたホスト不発揮性コンピュータ可読メモリと、
   前記成立した取引を組み入れることによって、前記部屋在庫記録の前記複写を更新するように構成されたホストコンピュータプロセッサと、
   を含む、前記資産管理システムと、
   中間サーバシステムであって、
   取引プロキシサーバであって、
   部屋予約イベントを受信し、前記成立した取引を前記資産管理システムへ転送し、前記成立した取引に応じて生成される新しいブロックを転送するように構成された中間送受信機と、
   イーサリアム（登録商標）に基づいて生成される複数のスマートコントラクトを記憶し、前記複数のスマートコントラクトの少なくとも１つを用いて実行される前記部屋在庫記録を記憶し、複数のブロックを含むブロックチェーンを記憶するように構成された中間不発揮性コンピュータ可読メモリであって、前記ブロックチェーンにおいて最も新しく追加されたブロックは、前記資産管理システムにおける最新の成立した取引のすべてを担持する、前記中間不発揮性コンピュータ可読メモリと、
   前記部屋予約イベントが前記部屋在庫記録においてオーバーブッキングを起こすか否かを確認し、前記部屋予約イベントがローカルの前記部屋在庫記録においてオーバーブッキングを起こさないと確認したとき、前記部屋予約イベントが成立することを決定して前記部屋予約イベントの情報を用いて前記成立した取引を生成するように構成された中間コンピュータプロセッサであって、
   前記成立した取引に応じて、前記新しいブロックに対してハッシュ値を生成するように構成されたハッシングモジュールと、
   前記成立した取引に応じて、前記新しいブロックに対して一意的なタイムスタンプを生成するように構成されたタイムスタンプモジュールと、
   前記成立した取引に応じて、少なくとも前記一意的なハッシュ値、前記一意的なタイムスタンプ、および前記最も新しく追加されたブロックの内容を用いて前記新しいブロックに対して一意的なブロックヘッダを生成し、前記一意的なブロックヘッダ、前記成立した取引の情報、前記複数のスマートコントラクトの少なくとも１つ、および前記最も新しく追加されたブロックの前記内容を含む前記新しいブロックを生成し、前記新しいブロックを前記ブロックチェーンに追加するように構成されたブロック生成モジュールと、
   を含む、前記中間コンピュータプロセッサと、
   を含む、前記取引プロキシサーバと、
   複数のノードサーバであって、前記複数のノードサーバのそれぞれは、
   前記中間送受信機から前記新しいブロックを受信するように構成されたノード送受信機と、
   前記ブロックチェーンの複写を記憶するように構成されたノード不発揮性コンピュータ可読メモリと、
   前記新しいブロックを前記ブロックチェーンの前記複写に追加することによって、前記ブロックチェーンの前記複写を更新するように構成されたノードコンピュータプロセッサと、
   を含む、前記複数のノードサーバと、
   を含む、前記中間サーバシステムと、
   を含む、ブロックチェーンに基づく部屋在庫管理システム。
2. 前記タイムスタンプモジュールは、前記部屋予約イベントの発行時間に基づいて前記一意的なタイムスタンプを生成するようにさらに構成されている、請求項１に記載のブロックチェーンに基づく部屋在庫管理システム。
3. 前記タイムスタンプモジュールは、前記中間送受信機が前記部屋予約イベントを受信する受信時間に基づいて前記一意的なタイムスタンプを生成するようにさらに構成されている、請求項１に記載のブロックチェーンに基づく部屋在庫管理システム。
4. 前記中間コンピュータプロセッサは、前記成立した取引に応じて、前記部屋予約イベントが、割り当て予定の部屋を予約するように指示する部屋予約要求を含むとき、暫定空き部屋数を減少させる、および／または、前記部屋在庫記録に記録された前記割り当て予定の部屋を空いていない状況とするようにさらに構成されており、
   前記中間コンピュータプロセッサは、前記成立した取引に応じて、前記部屋予約イベントが、部屋の予約をキャンセルするように指示する部屋予約キャンセル要求、または、前記部屋をチェックアウトするように指示する部屋チェックアウト要求を含むとき、前記暫定空き部屋数を増加させ、ならびに／または、前記部屋在庫記録および前記少なくとも１つの部屋在庫管理のスマートコントラクトに記録された予約解除予定の前記部屋を空いている状況とするようにさらに構成されている、請求項１に記載のブロックチェーンに基づく部屋在庫管理システム。
5. 前記ホストコンピュータプロセッサは、前記成立した取引に応じて、前記部屋予約イベントが前記部屋予約要求を含むとき、ローカルの空き部屋数を減少させる、および／または、前記部屋在庫記録の前記複写に記録された割り当て予定の前記部屋を空いていない状況とするようにさらに構成されており、
   前記ホストコンピュータプロセッサは、前記成立した取引に応じて、前記部屋予約イベントが前記部屋予約キャンセル要求または前記部屋チェックアウト要求を含むとき、前記ローカルの空き部屋数を増加させる、および／または、前記部屋在庫記録の前記複写に記録された予約解除予定の前記部屋を空いている状況とするようにさらに構成されている、請求項４に記載のブロックチェーンに基づく部屋在庫管理システム。
6. 前記複数のスマートコントラクトは少なくとも１つの動的価格スマートコントラクトを含み、
   前記中間コンピュータプロセッサは、前記部屋在庫記録に記録された暫定空き部屋数に基づいて、前記部屋在庫記録に記録された暫定部屋価格を動的に調整し、前記中間送受信機を介して、前記資産管理システム、オンライントラベルエージェンシー（ＯＴＡ）モジュール、ブッキングエンジン、グローバルディストリビューションシステム（ＧＤＳ）、または、メタサーチエンジンへ前記暫定部屋価格を動的に転送するようにさらに構成されている、請求項１に記載のブロックチェーンに基づく部屋在庫管理システム。
7. 前記ホストコンピュータプロセッサは、前記ホスト送受信機が前記暫定部屋価格を受信するとき、前記暫定部屋価格を用いて、前記ホスト不発揮性コンピュータ可読メモリに記録されたローカル部屋価格を動的に更新するようにさらに構成されている、請求項６に記載のブロックチェーンに基づく部屋在庫管理システム。
8. 前記複数のスマートコントラクトは少なくとも１つの監査スマートコントラクトを含み、
   前記中間コンピュータプロセッサ、またはいずれか１つの前記ノードプロセッサは、前記少なくとも１つの監査スマートコントラクトを用いて、前記ブロックチェーンの少なくとも１つのブロックに記録された前記少なくとも１つの成立した取引を、当該少なくとも１つのブロックのブロックヘッダを時系列で追跡することによって監査するようにさらに構成されている、請求項１に記載のブロックチェーンに基づく部屋在庫管理システム。
9. 前記資産管理システムおよび前記中間サーバシステムは、相互通信のために、同じ遠隔手続き呼び出しプロシージャを共有する、請求項１に記載のブロックチェーンに基づく部屋在庫管理システム。
10. 前記中間コンピュータプロセッサは、前記複数のスマートコントラクトの少なくとも１つを用いて、ブッキングエンジン、ＯＴＡモジュール、グローバルディストリビューションシステム、またはメタサーチエンジンのいずれか１つが、前記共通のＡＰＩおよび／または前記共通の通信プロトコルを用いて、前記部屋予約イベントを開始すること、および／または、前記複数のノードサーバのいずれか１つの前記部屋在庫記録を確認することができるよう、共通のアプリケーションプログラミングインタフェース（ＡＰＩ）、および／または共通の通信プロトコルを生成するようにさらに構成されている、請求項１に記載のブロックチェーンに基づく部屋在庫管理システム。
11. ブロックチェーンに基づく部屋在庫管理システムであって、
    資産管理システムであって、
    成立した取引を受信するように構成されたホスト送受信機と、
    前記資産管理システムによって管理されたすべての部屋の予約状況を記録する部屋在庫記録の複写を記憶するように構成されたホスト不発揮性コンピュータ可読メモリと、
    前記成立した取引を組み入れることによって、前記部屋在庫記録の前記複写を更新するように構成されたホストコンピュータプロセッサと、
    を含む、前記資産管理システムと、
    中間サーバシステムであって、
    複数のノードサーバであって、前記ノードサーバのそれぞれは、
    部屋予約イベントを受信し、前記成立した取引を前記資産管理システムへ転送し、前記成立した取引に応じて生成される新しいブロックを転送するように構成されたノード送受信機と、
    イーサリアムに基づいて生成される複数のスマートコントラクトを記憶し、複数のブロックを含むブロックチェーン、または前記ブロックチェーンの複写を記憶するように構成されたノード不発揮性コンピュータ可読メモリであって、前記ブロックチェーンにおいて最も新しく追加されたブロックは、前記資産管理システムにおける最新の成立した取引のすべてを担持し、前記部屋在庫記録は、前記複数のスマートコントラクトの少なくとも１つを用いて実行される、前記ノード不発揮性コンピュータ可読メモリと、
    前記記憶されたブロックチェーンまたは前記記憶されたブロックチェーンの前記複写に新しいブロックを追加することによって、前記記憶されたブロックチェーンまたは前記記憶されたブロックチェーンの前記複写を更新するように構成されており、ハッシングモジュールと、タイムスタンプモジュールと、ブロック生成モジュールとを含むノードコンピュータプロセッサと、
    を含み、
    前記複数のノードサーバは、コンセンサスアルゴリズムを用いて、前記複数のノードサーバのうちからマスタノードサーバを一時的に選択するようにさらに構成されており、
    前記マスタノードサーバの前記ノードコンピュータプロセッサは、
    前記部屋予約イベントが前記部屋在庫記録においてオーバーブッキングを起こすか否かを確認し、前記部屋予約イベントが前記部屋在庫記録においてオーバーブッキングを起こさないと確認したとき、前記部屋予約イベントが成立することを決定して前記部屋予約イベントの情報を用いて前記成立した取引を生成するようにさらに構成されており、
    前記マスタノードサーバの前記ハッシングモジュールは、前記成立した取引に応じて、前記新しいブロックに対してハッシュ値を生成するように構成されており、
    前記マスタノードサーバの前記タイムスタンプモジュールは、前記成立した取引に応じて、前記新しいブロックに対して一意的なタイムスタンプを生成するように構成されており、
    前記マスタノードサーバの前記ブロック生成モジュールは、前記成立した取引に応じて、少なくとも前記一意的なハッシュ値、前記一意的なタイムスタンプ、および前記最も新しく追加されたブロックの内容を用いて前記新しいブロックに対して一意的なブロックヘッダを生成し、前記一意的なブロックヘッダ、前記成立した取引の情報、前記複数のスマートコントラクトの少なくとも１つ、および前記最も新しく追加されたブロックの前記内容を含む前記新しいブロックを生成し、前記マスタノードサーバのノード不発揮性コンピュータ可読メモリに記憶された前記ブロックチェーンに前記新しいブロックを追加するように構成されており、
    前記マスタノードサーバ以外の前記複数のノードサーバの前記ノードコンピュータプロセッサの前記ブロック生成モジュールは、前記成立した取引に応じて、それぞれのノード不発揮性コンピュータ可読メモリに記憶された前記ブロックチェーンの前記複写に前記新しいブロックを追加するように構成されている、
    前記複数のノードサーバと、
    を含む、前記中間サーバシステムと、
    を含む、ブロックチェーンに基づく部屋在庫管理システム。
12. 前記タイムスタンプモジュールは、前記部屋予約イベントの発行時間に基づいて前記一意的なタイムスタンプを生成するようにさらに構成されている、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
13. 前記タイムスタンプモジュールは、前記マスタノードサーバの前記ノード送受信機が前記部屋予約イベントを受信する受信時間に基づいて前記一意的なタイムスタンプを生成するようにさらに構成されている、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
14. 前記複数のスマートコントラクトは、前記部屋在庫記録を記録する少なくとも１つの部屋在庫管理スマートコントラクトを含み、
    前記マスタノードサーバの前記ノードコンピュータプロセッサは、前記成立した取引に応じて、前記部屋予約イベントが、部屋を予約するように指示する部屋予約要求を含むとき、暫定空き部屋数を減少させる、または、前記部屋在庫記録に記録された割り当て予定の前記部屋を空いていない状況とするようにさらに構成されており、
    前記マスタノードサーバの前記ノードコンピュータプロセッサは、前記成立した取引または内部解除チェックアウト要求に応じて、前記部屋予約イベントが、部屋の予約をキャンセルするように指示する部屋予約キャンセル要求、または、前記部屋をチェックアウトするように指示する部屋チェックアウト要求を含むとき、前記暫定空き部屋数を増加させる、ならびに／または、前記部屋在庫記録に記録された予約解除予定の前記部屋を空いている状況とするようにさらに構成されている、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
15. 前記ホストコンピュータプロセッサは、前記成立した取引に応じて、前記部屋予約イベントが前記部屋予約要求を含むとき、ローカルの空き部屋数を減少させる、および／または、前記部屋在庫記録の前記複写に記録された割り当て予定の前記部屋を空いていない状況とするようにさらに構成されており、
    前記ホストコンピュータプロセッサは、前記成立した取引に応じて、前記部屋予約イベントが前記部屋予約キャンセル要求または前記部屋チェックアウト要求を含むとき、前記ローカルの空き部屋数を減少させる、および／または、前記部屋在庫記録の前記複写に記録された予約解除予定の前記部屋を空いている状況とするようにさらに構成されている、請求項１４に記載のブロックチェーンに基づく部屋在庫管理システム。
16. 前記複数のスマートコントラクトは、前記部屋在庫記録を記憶する少なくとも１つの動的価格スマートコントラクトを含み、
    前記マスタノードサーバの前記ノードコンピュータプロセッサは、前記部屋在庫記録に記録された暫定空き部屋数に基づいて、前記部屋在庫記録に記録された暫定部屋価格を動的に調整し、前記ノード送受信機を介して、前記資産管理システム、オンライントラベルエージェンシーモジュール、ブッキングエンジン、グローバルディストリビューションシステム、または、メタサーチエンジンへ前記暫定部屋価格を動的に転送するようにさらに構成されている、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
17. 前記ホストコンピュータプロセッサは、前記暫定部屋価格を用いて、前記ホスト不発揮性コンピュータ可読メモリに記録された前記部屋在庫記録の前記複写に記録されたローカル部屋価格を動的に更新するようにさらに構成されている、請求項１６に記載のブロックチェーンに基づく部屋在庫管理システム。
18. 前記複数のスマートコントラクトは少なくとも１つの監査スマートコントラクトを含み、
    前記複数のノードサーバの前記ノードコンピュータプロセッサは、前記少なくとも１つの監査スマートコントラクトを用いて、前記ブロックチェーンの少なくとも１つのブロックに記録された前記少なくとも１つの成立した取引を、前記ブロックチェーンの当該少なくとも１つのブロックのブロックヘッダを時系列で追跡することによって監査するようにさらに構成されている、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
19. 前記資産管理システムおよび前記中間サーバシステムは、相互通信のために、同じ遠隔手続き呼び出しプロシージャを共有する、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
20. 前記部屋予約イベントは、ブッキングエンジン、ＯＴＡモジュール、グローバルディストリビューションシステム、またはメタサーチエンジンから送信され、
    前記マスタコンピュータプロセッサは、前記複数のスマートコントラクトの少なくとも１つを用いて、共通のＡＰＩ、および／または共通の通信プロトコルを生成するようにさらに構成されており、よって、ブッキングエンジン、ＯＴＡモジュール、グローバルディストリビューションシステム、またはメタサーチエンジンのいずれか１つは、前記共通のＡＰＩおよび／または前記共通の通信プロトコルを用いて、前記部屋予約イベントを開始すること、および／または、前記複数のノードサーバのいずれか１つの前記部屋在庫記録を確認することができる、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
21. 前記複数のノードサーバは、コンセンサスアルゴリズムを用いて、選挙、順次交替、または所定ルールによって、前記複数のノードサーバのうちからマスタノードサーバを決定するように構成されている、請求項１１に記載のブロックチェーンに基づく部屋在庫管理システム。
22. 前記所定ルールに基づいて、前記複数のノードサーバは、より小さい負担または最も小さい負担を有するノードサーバを前記マスタノードサーバとして動的に指定するように構成されており、前記負担は、前記複数のノードサーバの瞬時システム負荷、瞬時ストレージサイズ、および／または瞬時送信帯域幅によって決定される、請求項２１に記載のブロックチェーンに基づく部屋在庫管理システム。

Images