特許 6014615 建築システムを実現するためのシステムおよび方法

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

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

(11)【特許番号】6014615

(24)【登録日】2016年9月30日

(45)【発行日】2016年10月25日

(54)【発明の名称】建築システムを実現するためのシステムおよび方法

(51)【国際特許分類】

   G06F 17/50 20060101AFI20161011BHJP

   G06Q 50/08 20120101ALI20161011BHJP

【ＦＩ】

   G06F17/50 680B

   G06F17/50 634C

   G06F17/50 612A

   G06Q50/08

【請求項の数】15

【全頁数】28

(21)【出願番号】特願2013-558241(P2013-558241)

(86)(22)【出願日】2012年3月19日

(65)【公表番号】特表2014-515133(P2014-515133A)

(43)【公表日】2014年6月26日

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

(87)【国際公開番号】WO2012126010

(87)【国際公開日】20120920

【審査請求日】2015年3月10日

(31)【優先権主張番号】61/453,867

(32)【優先日】2011年3月17日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】513231199

【氏名又は名称】アディタッズ，インク．

(74)【代理人】

【識別番号】100082072

【弁理士】

【氏名又は名称】清原 義博

(72)【発明者】

【氏名】ヴェルクリュイス，ウォード，エー．

(72)【発明者】

【氏名】アートレシュ，ディパック，ジェイ．

(72)【発明者】

【氏名】ルーベル，ジグムント

【審査官】 早川 学

(56)【参考文献】

【文献】 特開平０６−０９６１４６（ＪＰ，Ａ）

【文献】 高瀬大樹、外１名，患者需要予測システムの開発と適用 −医療施設計画における患者マーケティングに関する研究−，日本建築学会技術報告集，一般社団法人日本建築学会，２００３年 ６月２０日，第17号，pp.375-378

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

Ｇ０６Ｆ １７／５０

Ｇ０６Ｑ ５０／０８

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

【請求項1】

ヘルスケアサービスが患者に提供される建築内のシステムを実現するためのコンピュータによって実行される方法であって、
前記方法は、ヘルスケアサービスがコンピュータによって患者に提供される建築内のシステムのための顧客ニーズに関連する入力を受信する工程を含み、該入力は遠隔クライアントデバイスを介して受信され、形式記述言語によって表現され、
前記方法は、コンピュータが、前記顧客ニーズから複数の異なるビジネスモデルを生成する工程を含み、前記ビジネスモデルは、前記顧客ニーズを満足するために前記建築システム内に提供されるヘルスケアサービスの型および量を定義し、
前記方法は、コンピュータが、少なくとも１つのビジネスモデルから複数の異なる空間的配置を生成する工程を含み、前記空間的配置は、前記建築システムのフォーム及びシェル、前記建築システムのブロック及びスタック、及び前記建築システム内の部屋の配置を定義し、
前記方法は、コンピュータが、少なくとも１つの空間的配置から複数の異なるシステム統合設計を生成する工程を含み、前記システム統合設計は、前記建築システムのインフラの三次元を定義し、
前記方法は、コンピュータが、前記顧客ニーズ、前記ビジネスモデル、前記空間的配置及び前記システム統合設計の間の依存性を追跡する工程を含み、
前記ビジネスモデルは、建築システムによって提供されるサービスライン、建築システムへの患者の負荷、及び部屋とスタッフのニーズを識別し、前記サービスラインは、緊急のケア、健康のケア、イメージング、及び実験室の少なくとも１つを含み、
複数の異なるビジネスモデルを生成する工程及び複数の異なる空間的配置を生成する工程が、少なくとも１つのコンピュータによって実行されるシミュレーション演算及びコンピュータによって実行される最適化演算を含み、前記少なくとも１つのコンピュータによって実行されるシミュレーション演算及びコンピュータによって実行される最適化演算は、少なくともデッキの構成要素の次元を含む予め定義されたセットの物理的な建築構成要素を使用して実行され、
前記顧客ニーズ、前記ビジネスモデル、前記空間的配置及び前記システム統合設計の間の依存性の追跡が、最も高いレベルの前記顧客ニーズから、前記ビジネスモデルへ、前記空間的配置へ、前記システム統合へと、階層順において、中央のデータベースに、前記顧客ニーズ、各々の前記複数の異なるビジネスモデル、各々の前記複数の異なる空間的配置、及び各々の異なるシステム統合のためのインスタンススペシフィックデータを格納する工程を含み、
その結果、前記顧客ニーズからの中央のデータベース及び階層順において、各々のシステム統合は、対応する空間的配置、及び対応するビジネスモデルを介して、前記顧客ニーズを追跡し、
前記方法は、階層順における、前記顧客ニーズ、前記ビジネスモデル、及び前記空間的配置の変更を伝播する工程をさらに含み、
各インスタンスが独立してアクセスして変更することができるように、前記ビジネスモデル及び前記空間的配置の各インスタンスは、前記中央のデータベースに一意に格納される
ことを特徴とするコンピュータによって実行される方法。

【請求項2】

前記中央のデータベースがクラウドサービスに格納される請求項１に記載のコンピュータによって実行される方法。

【請求項3】

処理システムを含む、クラウドサービスの複数の異なるプロセッサにシミュレーション演算と最適化演算のコンピュータタスクを分配する工程をさらに含む請求項１に記載のコンピュータによって実行される方法。

【請求項4】

前記コンピュータタスクが、ＭａｐＲｅｄｕｃｅフレームワークにしたがって前記処理システムによって実行される請求項３に記載のコンピュータによって実行される方法。

【請求項5】

コンピュータによる顧客ニーズに関連する前記入力が顧客の価値の形式記述を含む請求項１に記載のコンピュータによって実行される方法。

【請求項6】

前記ビジネスモデルがコンピュータによってビジネスモデルのライブラリから生成される請求項５に記載のコンピュータによって実行される方法。

【請求項7】

処理システムを含むクラウドサービスを介して並行してアクセスされる複数の異なるプロセッサを用いて異なるビジネスモデル上で挙動シミュレーションを計算する工程をさらに含む請求項６に記載のコンピュータによって実行される方法。

【請求項8】

コンピュータによって実行されるシミュレーション演算の実行は、ビジネスモデルが如何にして実行するかを決定するために、スペースパターンによって、人のワークフロー・パターンとプロセスのワークフロー・パターンを比較することによって、前記ビジネスモデルの様相において、コンピュータによって実行されるシミュレーション演算を実行する工程を含む、請求項１に記載のコンピュータによって実行される方法。

【請求項9】

ヘルスケアサービスが患者に提供される建築システムを実現するためのコンピュータによって実行される方法であって、
前記方法は、建築システムのための顧客ニーズに関連する入力を受信する工程を含み、該入力は遠隔クライアントデバイスを介して受信され、形式記述言語によって表現され、前記入力は前記建築システムが構築される場所の表示を含み、前記方法は、前記顧客ニーズから複数の異なるビジネスモデルを生成する工程を含み、前記ビジネスモデルは、前記建築システムを介して提供されるヘルスケアサービスの型および量を機能的な言語で定義し、
前記方法は、コンピュータが、前記ビジネスモデルの様相をシミュレーションする工程と、コンピュータが、前記ビジネスモデルの様相を最適化する工程を含み、
前記方法は、コンピュータが、少なくとも１つのビジネスモデルから複数の異なる空間的配置を生成する工程を含み、前記建築システムの前記空間的配置は、前記建築システムのフォーム及びシェル、前記建築システムのブロック及びスタック、及び前記建築システム内の部屋の配置を定義し、
前記方法は、コンピュータが、前記建築システムの空間的の様相をシミュレーションする工程をさらに含み、
前記シミュレーションの演算と最適化の演算のコンピュータタスクが処理システムの複数の異なるプロセッサに与えられる
ことを特徴とするコンピュータによって実行される方法。

【請求項10】

コンピュータが、前記顧客ニーズ、前記ビジネスモデル、及び前記空間的配置の依存性を追跡する工程をさらに含む請求項９に記載のコンピュータによって実行される方法。

【請求項11】

前記コンピュータタスクが、ＭａｐＲｅｄｕｃｅフレームワークにしたがって前記処理システムによって実行される請求項９に記載のコンピュータによって実行される方法。

【請求項12】

複数の異なるプロセッサを有する処理システムと、
前記処理システムと通信するストレージ・ネットワークとを備えたシステムであって、前記ストレージ・ネットワークはコンピュータ読み取り可能な命令とデータを格納し、前記処理システムによって処理されるとき、建築実現プラットフォームを実行し、
前記建築実現プラットフォームが、建築システムに対する顧客ニーズに関連する入力を受信するように構成され、当該入力が遠隔クライアントデバイスを介して受信され、かつ形式記述言語で表現され、
前記建築実現プラットフォームが、前記顧客ニーズ入力から少なくとも１つのビジネスモデルを生成するように構成され、前記ビジネスモデルは、前記建築システム内に提供されるサービスの型と量を機能的な言語で定義し、
前記建築実現プラットフォームが、前記ビジネスモデルの様相をシミュレーションし、前記ビジネスモデルの様相を最適化し、前記少なくとも１つのビジネスモデルから少なくとも１つの空間的配置を生成するように構成され、前記建築システムの空間的配置が、前記建築システムのフォーム及びシェル、前記建築システムのブロック及びスタック、前記建築システムの部屋の配置を定義し、
前記建築実現プラットフォームが、前記建築システムの空間的配置の様相をシミュレーションし、前記顧客ニーズ、前記ビジネスモデル、及び前記空間的配置の間の依存性を追跡するように構成され、前記シミュレーションの演算及び前記最適化の演算のコンピュータのタスクが処理システムの複数の異なるプロセッサに与えられる
ことを特徴とするシステム。

【請求項13】

前記処理システムとストレージ・ネットワークがクラウドサービスの構成要素である請求項１２に記載のシステム。

【請求項14】

前記建築実現プラットフォームが、ＭａｐＲｅｄｕｃｅフレームワークを用いて処理システムの複数の異なるプロセッサにシミュレーションと最適化のコンピュータ演算を分配する請求項１３に記載のシステム。

【請求項15】

複数の異なるプロセッサを有する処理システムと、
前記処理システムと通信するストレージ・ネットワークとを備えたシステムであって、前記ストレージ・ネットワークはコンピュータ読み取り可能な命令とデータを格納し、前記処理システムによって処理されるとき、請求項１に記載のヘルスケアサービスが患者に提供される建築システムを実現するための方法を実行するシステム。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
この出願は、建築を計画し、設計し、構築し、及び展開するための方法およびシステム」と題される、２０１１年３月１７日に出願された米国仮特許出願第６１／４５３，８６７号の利益を受ける権利を有しており、参照により本明細書に組み込まれている。
［発明の分野］
本発明は、一般的に建築に関し、より詳しくは、建築システムを実現するためのコンピュータベースの技術に関する。

【背景技術】

【0002】

建築は私たちの日常生活の不可欠な部分ですある。これらの建築の設計と構築、計画のプロセスは、数千年にわたって進化してきた。

【0003】

今日では、特に複雑なサービス（ヘルスケア施設など）を提供する場所である近代的な設備のために、そのような建築を物理的に実現するために辿るステップは、非常に複雑であり、いくつかの異なる分野にまたがっている熟練労働者の高度な技量を必要とする。

【0004】

この複雑さは、効率的で収益性の高い方法で、意図されたサービスを提供するために使用することができる実行可能な施設を構築するために費やされた時間、金および他のリソースの面で大きな課題を提起する。いくつかの産業やサービスが自分の仕事の流れを変更することにより、同じような複雑な課題を満たしているとそれが良く急成長と安価なコンピュータ資源を活用するために適応させる。これは、それらの産業における生産性の向上をもたらした。

【0005】

しかし、技術やコンピュータ能力の出現は、設計と構築を構築するための十分に確立されたプロセスに限られた採用を発見した。その結果、必死に複雑で需要を満たすために、今日必要とされる全体的な生産性で少しゲインがあった。例えば、それは他のすべての非農業産業は１９６４年から２００４年に彼らの生産性を倍増している一方で、建築業界の同僚は実際に遅れていることが見出されている。

【0006】

構築の生産性が他の領域に追いついていない多くの理由が存在するが、建築の設計と構築業界で使用される従来の方法は、一般的な、特にコンピュータ技術に適していな可能性がある。ほとんどすべての他の産業では、コンピュータ技術のスマートな適応による生産で培ってきたが、理由は俄かにわからないが、構築業界では、任意の同様の利益が見られない。

【0007】

建築は、すべてのさまざまな形や大きさになるが、建築の複雑さは、その用途に応じて異なる。例えば、多くの異なる視点から、病院などのヘルスケアの建築は空の倉庫の建築よりはるかに複雑である。建築の複雑さは、人が、病院の設計などの建築設計を数学的に記述し、モデル化し、シミュレーションをし、最適化し、および検証しようとするとき、明らかになる。特に、数学的記述、モデル化、シミュレーション、最適化、および検証は、おのおの、３次元（３Ｄ）空間と時間の演算の複雑な組み合わせである。３次元空間の特性は、例えば、建築のシェル・アンド・コア（ｓｈｅｌｌ ａｎｄ ｃｏｒｅ）、部屋の大きさ及びレイアウト、並びに建築のインフラのルーティング（ｒｏｕｔｉｎｇ）を含む。時間的な演算の特徴は、例えば、建築、建築への負荷（例えば、患者のボリューム）、および動的な環境条件（例えば、内部／外部温度、光、エネルギーコストなど）に設けられたサービスがある。

【発明の概要】

【0008】

本発明の一実施形態によれば、複雑な建築システムの全体的なアプローチは、建築の最初から建築の運営までの複雑な建築システムを管理するために、生産性の高い高性能な（ＨＰ２）コンピュータリソースを使用することを含む。例えば、ＨＰ２コンピュータリソースは、建築を構築するために使用することができる完全な仮想建築設計に顧客のニーズの設定を変換するために使用される。さらに、仮想建築の設計時に生成された情報は、後で、手数料を作製し、仮想建ての建築のバージョンを動作させるために使用される情報の基礎として使用することができる。ＨＰ２コンピュータリソースが使用されるため、モデリング、最適化、シミュレーションおよび検証は、これまで、複雑な建築システムに適用されていない規模で単一のプラットフォームから行うことができる。また、複雑な構築システムへの全体的なアプローチは、建築システムに関連する情報のすべてを管理するための集中型データベースを使用することを含む。集中型データベースの概念は、それぞれ異なる学問分野（例えば、建築家、構造エンジニア、電気エンジニアなど）が、分野特有の情報（ｄｉｓｉｐｌｉｎｅ−ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）の独自のデータベースを維持する従来のアプローチとは対照的である。

【0009】

本発明の実施形態の他の態様および利点は、本発明の原理の例により示され、添付の図面と併せて以下の詳細な説明から明らかになるであろう。

【図面の簡単な説明】

【0010】

【図1】図１は、開始から建築演算に建築プロジェクトを取る建築実現プラットフォームを実行するために高性能高生産性コンピュータリソースを利用する全体的な建築管理システムを示す図である。

【図2】図２は、建築実現プラットフォームを実行することが可能な、生産性の高い高性能なコンピュータアーキテクチャの実施形態を示す。

【図3】図３は、建築実現プラットフォームを使用して実行されて並列階層設計技術の実施形態を示す。

【図4】図４は、建築実現プラットフォームの実現エンジンを作動させるための選択可能なタブを含む建築実現プラットフォームのユーザー・インターフェースの実施形態を示す。

【図5】図５は、建築実現プラットフォームのビジネスモデルドメインのユーザー・インターフェースの実施形態を示す。

【図6】図６は、建築実現プラットフォームのビジネスモデルドメインからユーザー・インターフェースの別の実施形態を示す。

【図7】図７は、建築実現プラットフォームの空間配置ドメイン内のフォームとシェルタブからユーザー・インターフェースの実施形態を示す。

【図8】図８は、建築実現プラットフォームの空間配置ドメインブロックとスタックタブのユーザー・インターフェースの一実施形態を示す。

【図9】図９は、建築実現プラットフォームの空間配置ドメインの部屋の配置タブからユーザー・インターフェースを示している。

【図10】図１０は、建築実現プラットフォームの空間配置ドメインの部屋の配置タブからユーザー・インターフェースを示している。

【図11】図１１は、建築実現プラットフォームによって使用される統一されたデータモデルの一例を示す図である。

【図12】図１２は、顧客のニーズのセットから、システム統合設計を生成するためのコンピュータベースの技術のプロセスフロー図である。

【図13】図１３は、システムの要素及び建築実現プラットフォームを使用してビジネスモデルから空間配置を生成するための対応するプロセスフローを示す。

【図14】図１４は、建築実現プラットフォームの一実施形態のアーキテクチャの実施形態を示す。

【図15】図１５は、実現エンジンのいずれかによって提供されるサービスの実行を示す図である。

【図16】図１６は、複雑な建築システムを実現するための方法のプロセスフロー図である。

【図17】図１７は、医療サービスを患者に提供される建築内のシステムを実現するための方法のプロセスフロー図である。

【図18】図１８は、プロセッサ、メモリ、および通信インターフェースを備えたコンピュータを示す図である。

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

【0011】

詳細な説明を通して、同じ参照番号は同じ要素を特定するために使用することができる。さらに、いくつかのケースでは、参照符号は明瞭さを維持し、図面の混乱を避けるために、各図では繰り返さない。

【0012】

なお、容易に実施形態の構成要素としては、一般に本明細書に記載及び添付の図面に示さ配置することができ、多種多様な異なる構成で設計することが理解されるであろう。

【0013】

従って、図面に示される様々な実施形態の以下のより詳細な説明は、本開示の範囲を限定することを意図するものではなく、様々な実施形態の単なる代表可能である。実施形態の様々な態様は、図面に示されているが具体的に示さない限り、図面は必ずしも一定の縮尺で描かれていない。

【0014】

説明した実施形態は例示であって制限的ではない、あらゆる点で考慮されるべきである。

【0015】

したがって、本発明の範囲は、この詳細な説明によってではなく、添付の特許請求の範囲によって示されている。

【0016】

特許請求の範囲と均等の意味および範囲内でのすべての変更は、その範囲内に包含されるべきである。

【0017】

本明細書全体を通して、特徴、利点、または同様の用語の減給は、本発明によって実現され得る特徴および利点のすべてが、単一の実施形態に記載されるべきであることを意味するものではない。

【0018】

むしろ、特徴および利点に言及した言語は、実施形態に関連して説明された特定の特徴、利点、又は特性が少なくとも１つの実施形態に含まれることを意味すると理解される。

【0019】

従って、本明細書全体を通しての特徴および利点、および同様の用語の議論もよいが、必ずしも、同じ実施形態を指すものではない。

【0020】

更に、説明された特徴、利点、および本発明の特徴は、１つ以上の実施形態において任意の適切な方法で組み合わせることができる。

【0021】

当業者は、本発明は特定の実施形態の特定の特徴または利点の１つ以上がなくても実施できることは、本明細書の説明に照らして、認識するであろう。

【0022】

他の例では、追加の特徴および利点は、本発明のすべての実施形態に存在しなくてもよい特定の実施形態で認識することができる。

【0023】

本明細書全体を通して「一実施形態」、「実施形態」、または同様の用語への言及は、示された実施形態に関連して記載された特定の特徴、構造、又は特性が、少なくとも１つの実施形態に含まれることを意味する。

【0024】

したがって、本明細書全体を通じて「一実施形態において」、「特定の実施形態において」及び類似のフレーズは、しかしながら、必ずしも全てが同じ実施形態に言及したものではない。

【0025】

コンピュータは、建築を数学的に記述し、モデル化し、シミュレーションし、および最適化するために使用される。

【0026】

しかし、従来のコンピュータベースの技術は、単一の問題、例えば、構造性能、温度モデリング、またはワークフローの最適化に焦点を当てている、非常に特定の演算を実行するために、限られたコンピュータ能力を搭載したＰＣベースのコンピュータプラットフォームを利用している。

【0027】

ＰＣベースのコンピュータリソースの固有の制限のために、従来の設計、モデリング、シミュレーション、および最適化の動作は、妥当な時間で、２〜３の設計オプションだけを評価することができる、比較的大雑把な数学モデルに依存することを余儀なくされている。

【0028】

建築システムに複雑さを加えるいくつかの特徴はつぎのとおりである。

【0029】

すなわち、システムコンポーネントは、必ずしも数学的に類似した構造を持たず、時間や空間に異なるスケールを含んでもよく、部品点数が時には膨大な、大きくてもよい。

【0030】

構成要素は、様々な接続することができる最も頻繁に様々な方法、非線形および／またはネットワークを介して、ローカルおよびシステム全体の現象は複雑な方法で相互に依存し得る。

【0031】

システム全体の挙動は個々の構成要素の挙動から予測することが困難であり得る。

【0032】

システム全体の挙動は、任意の段階で小さな摂動に対して大きな感度が表示され得る質的に異なる経路に沿って進化させ得る。

【0033】

そのような建築システムの複雑さの故に、従来の技法を越えて大きな進歩を提供するように、包括的にＰＣベースのコンピュータプラットフォーム上で、そのような建築のシステムを設計し、モデル化し、シミュレーションし、或いは最適化することはたとえ不可能でなくても、困難である。

【0034】

本発明の実施形態では、複雑なビルシステムへの総合的なアプローチに基づき、建築の演算に至るまで開始の構築から複雑な建築システムを管理するために生産性の高い、高性能（ＨＰ２）コンピュータリソースを使用することを含む。例えば、ＨＰ２コンピュータリソースは、建築を構築するために使用することができる完全な仮想建築設計に顧客のニーズのセットを変換するために使用される。さらに、仮想建築の設計時に生成された情報は、後で、手数料を作製し、仮想建ての建築のバージョンを動作させるために使用される情報の基礎として使用することができる。ＨＰ２コンピュータリソースが使用されるため、モデル化、最適化、シミュレーションおよび検証は、これまで、複雑な建築システムに適用されていない規模で、単一のプラットフォームから行うことができるものである。また、複雑な構築システムへの全体的なアプローチは、建築システムに関連する情報のすべてを管理するための集中型データベースを使用することを含む。集中型データベースの概念はそれぞれ異なる学問領域（例えば、建築家、構造エンジニア、電気エンジニアなど）固有の情報、独自のデータベースを維持する、従来のアプローチとは対照的である。

【0035】

図１は、開始から建築演算（例えば、顧客のニーズ）まで、建築プロジェクトを取りビル実現プラットフォーム（ＢＲＰ）（１０２）を実行するためにＨＰ２コンピュータリソースを利用する総合的なビル管理システム（１００）を示す。ＢＲＰは、建築の演算を通じて顧客ニーズの初期仕様から維持され得る建築の情報の中心的なハブである。実施形態では、ＢＲＰが実現エンジン（１０４）や建築データベース（１０６）を含む。実施形態では、実現エンジンは、建築システムに関連付けられた設計、モデル化、シミュレーション、最適化、及び検証演算を駆動するためのロジックを含み、建築のデータベースは、設計化され、モデル化され、シミュレートされ、最適化され、および実現エンジンによって検証される建築システム（仮想および／または実数）に関連付けられて格納されたデータを含む。

【0036】

ハイレベルな観点から、ＢＲＰ（１０２）は、より抽象的なものから、より抽象的でないものまでのプロセスフローで実行する一連の階層ドメインをサポートしている。図１に示される階層ドメインは、より抽象的なものから、より抽象的でないものまで、顧客ニーズ（１１０）、ビジネスモデル（１１２）、空間配置（１１４）、システム統合（１１６）、製造（１１８）、アセンブリ（１２０）、コミッショニング（ｃｏｍｍｉｓｓｉｏｎｉｎｇ）（１２２）及び演算（１２４）である。複雑な建築システムのライフサイクルでは、ドメインの各々は、以前のドメインに関連付けられているデータに依存する。このように、図１はまた、プロセスが次のドメインに移動することができる前に、前のドメインのものと特定の細部で異なるドメイン間の時間的関係を特定しなければならない点を示している。また、ドメイン間の依存関係は以前のドメインの要件に対応するように追跡される。

【0037】

一実施形態において、顧客ニーズ（１１０）のドメインは、所有者の観点からの所望の建築システムに関するものである。つまり、建築システム（例えば、ヘルスケア、ホスピタリティーなど）の使用とは何であるか、建築システムはどこに位置しているか、及び設計の品質を評価する指標（ｍｅｔｒｉｃ）とその重要性は何であるかである。ビジネスモデルのドメイン（１１２）は、顧客のニーズを満たすために提供されるサービスの種類とボリュームに関する。ビジネスモデルは、建築システムの動作のモデル化と、および建築システムの機能と空間のプログラムをサポートすることができる。空間配置ドメイン（１１４）は、それぞれ位置づけられた部屋と共に、所望の建築学上の部分を実施する１組の建築構造としての建築システムに関するものである。システム統合ドメイン（１１６）は、詳細な設計ドキュメントが導出され得る定義された３Ｄ空間や建築のインフラを含む完全な詳しい施設に関するものである。製作ドメイン（１１８）は、如何にして、どれくらい多くの基本的な要素（すなわち、建築ブロック）（例えば、建築の構成要素のリスト）が、建築システムを構築するために製作する必要があるかということにも関する。アセンブリドメイン（１２０）は、建築システムを構築するために、如何にして、どんな順序で基本的な要素を組み立てられるのかに関連している。コミッショニングドメイン（１２２）は、物理的な建築システム及びその動作方法に関する。コミッショニングドメインは、システム統合ドメインに保持されている情報に類似しているが、建築システムの製造および組立時に発生した可能性がある偏差を説明する情報も含み得る。演算ドメイン（１２４）は、演算中の建築システムに関するものである。演算ドメインにおいて、建築システムの仮想モデルは、例えば室温、スタッフ及び患者のスケジューリングなどのプロセスを最適化し、評価し、予定外のイベントに適合させるために、即座に使用することができる。

【0038】

実施形態では、予め定義されたセットの物理的な建築構成要素を使用して、建築の開始から、各複合ビルシステムが設計され、モデル化され、シミュレートされ、最適化され、そして検証される。予め定義されたセットの物理的な建築構成要素は、例えば、構造的な構成要素、デッキの構成要素、および壁の構成要素を含むことができる。予め定義された物理的な建築の構成要素は、より迅速かつ正確な結果を生成するためにＢＲＰの様々なドメインで利用することができる既知の特性（例えば、寸法、構造の材料、構造的性能、熱的性能）のセットを有する。具体的には、予め定義された物理的な建築部材の使用は、設計、モデリング、シミュレーション、最適化、複雑な建築システムの検証を可能にする数学的モデルの開発および再利用を可能にする。物理的な建築部材の予め定義されたセットは、ビジネスモデルドメイン、空間配置ドメイン、およびシステム統合ドメイン内では、例えば、初期の建築の設計プロセスにおいて考慮することができる。

【0039】

ＢＲＰ（１０２）を参照して説明した処理を実行すると、ＰＣベースの一般的なコンピュータシステムによって提供することができるものを充分に超えるコンピュータリソースを必要とする。実施形態において、ＢＲＰは、複雑な建築システムのライフサイクル全体に亘ってＨＰ２コンピュータリソースを利用する。図２は、ＢＲＰを実行することができるＨＰ２のコンピュータアーキテクチャ（１４０）の一実施形態を示す。特に、ＨＰ２コンピュータアーキテクチャは、大容量のネットワークストレージシステム（１４２）、大規模な処理システム（１４４）、およびユーザー・インターフェース装置（１４６）、例えば、クライアントマシン、を含む。また、ロードバランサ（１４８）およびフローサーバ（１５０）は、大規模な処理システムから供給され得る。

【0040】

ユーザー・インターフェース装置（１４６）は、クライアントマシン、典型的にはデスクトップコンピュータ、ラップトップコンピュータ、またはタブレットコンピュータであってもよく、セッションが設計フローを制御し、特定の建築のシステム設計の性能結果を表示するために開くことができる。ユーザー・インターフェース装置は、ユーザーが設計の意図を提供し、設計および解析手順を呼び出すことができる。設計および解析が利用可能になったと、結果がユーザー・インターフェースデバイスに入って来る。実施形態では、ユーザー・インターフェース装置は、アクセスネットワーク（１５２）を介してＢＲＰ（１０２）のブラウザベースのユーザー・インターフェースにアクセスするために使用される。

【0041】

大容量ネットワークストレージシステム（１４２）は、実現エンジンを実行するために使用されるソフトウェアコードを記憶するため、及びＢＲＰを使用して管理される複数の異なる複雑な構築システムに関連するデータを格納するためのメモリを含む。図２の実施例において、大容量のネットワークストレージシステムは、データのテラビットのオーダーの記憶容量を提供するストレージサーバ１５４のネットワーク化された組合せを含む。

【0042】

それぞれ異なる学問領域、例えば、建築家、構造エンジニア、電気エンジニア、ＨＶＡＣエンジニアなどが、独自の内部コンピュータネットワークと建築のデータベースを持っている従来の技術とは対照的に、図２に示されるコンピュータアーキテクチャは、複雑な建築システムに関する複数の異なる分野にまたがるデータの中央リポジトリが含まれる。たとえば、特定の建築のデータは、顧客のニーズ、ビジネスモデル、空間配置、システム統合、製造、組立、試運転、演算に関連するデータを含んでもよい。これは、従来、建築のライフサイクルに関与している分野の多くが交差する情報を含んでもよい。図２の実施形態において、大容量のストレージシステム（１４２）は、建築データベース（１０６）の情報を格納する１または２以上のストレージサーバと、実現エンジン（１０４）を実行する１または２以上のサーバとを含む。

【0043】

一実施形態において、データベースサーバ（１５４）は、つぎのとおり組織化された設計情報を格納する。すなわち、構築データベース、分析データベース、プロセス知識のライブラリ、および設計ルールのライブラリである。構築データベースは、システムが構築された方法とは独立している様々なシステム記述を含んでいてもよい。分析データベースが構築データベースに格納されているシステムの様々な分析、シミュレーションによって得られた性能と品質の結果を含んでいてもよい。プロセス知識のライブラリ情報は、プロセス、人のパターン、部門パターン、構築パターン、および機械、電気、および配管（ＭＥＰ）のルーティングパターンに関連する情報を含み得る。設計ルールのライブラリは、出口、火災、及びアクセスの要件など、建築の法律や、業界のベストプラクティス（建築のルールの局所的な変動に適合するように格納された設計ルールの異なるセットがあり得ることに注意されたい）を含み得る。特定のデータベースの構成の一例を説明したが、データを編成する他の方法が可能である。

【0044】

大規模な処理システム（１４４）は、ＢＲＰを実行する必要があるコンピュータの処理を実行する。例えば、大規模な処理システムは、設計、モデル化、シミュレーション、最適化、およびＢＲＰの検証を実行するために、大量の数学的コンピュータを実行する。実施形態では、大規模な処理システムは、それぞれが個々のサーバに接続される多くの高速のプロセッサ（例えば、数千のオーダー以上）を有する、複数のサーバ（１５８）（すなわち、サーバファームまたはコンピュータファーム）を含み、個々のサーバはギガビットイーサネットなどの高速ネットワークリンクによって互いに接続される。このような大規模な処理システムは、１秒当たりペテラ−（１０１２）乃至ペタ−（１０１５）オーダーの浮動小数点演算で実行することができ、それぞれテラフロップス及びペタフロップスと呼ばれている。大規模処理システムの例は、３，３２８の処理コアを有するＣＲＡＹ＿ＸＴ３と、１４，７５２の処理コアを有するＣＲＡＹ＿ＸＴ５とを含む。一実施形態において、大規模な処理システムは、 「ＭａｐＲｅｄｕｃｅ」フレームワークに係る分散コンピュータを実施するために、グリッドコンピュータアーキテクチャおよび／またはマルチコアプロセッサを利用する。大規模処理システムの例が記載されているが、他の大規模な情報処理システムも可能である。

【0045】

仮想、ユーザー・インターフェース装置（１４６）毎に１つ、および設計であり得るフローサーバ（１５０）は、ＢＲＰデザインフローを実行する命令を行う大規模な処理システム（１４４）（例えば、サーバファーム）から借りたコンピュータエンジンであり得る。実施形態において、フローサーバは、それぞれユニークなデザインの設計状態を保持している。すなわち、フローサーバは、特定の設計のための設計サイクルの相（ｐｈａｓｅ）を知っている。一般的には、フローサーバは、単に十分な設計の意図、結果、およびジョブ投入の効率的な転送を可能にするために、メモリ内のデザインのままにする。コンピュータ集約的なタスクのために、フローサーバは、ロードバランサ（１４８）に処理ジョブ（すなわち、計コンピュータタスク）を送りし、ロードバランサは、プロジェクト、ユーザー、およびタスクの優先度に基づいてコンピュータタスクを出す。

【0046】

大規模な処理システム（１４４）のコンピュータサーバ（１５８）が、例えば、並列処理のためのマップ減少（ｍａｐ ｒｅｄｕｃｅｄ）または 「ＭａｐＲｅｄｕｃｅ」技術を用いて、コンピュータ集約なタスクを実行するために、フローサーバ（１５０）によって使用される。実施形態では、コンピュータサーバはロードバランサ（１４８）によってフローサーバ間でプールされる。コンピュータサーバは、大容量ネットワークストレージシステム（１４２）のデータベースサーバ（１５４）から直接大量の設計情報を引き出し、ストレージシステムに戻って生の結果を保存することができる。

【0047】

実施形態では、コンピュータリソースのいくつかまたはすべて（ユーザー・インターフェース装置を除く）が、「クラウドサービス」として提供される。例えば、図２のＨＰ２コンピュータリソースは、ネットワーククラウド（１６０）内のクラウドサービスとして提供される。すなわち、コンピュータリソースはＢＲＰの所有者またはユーザーによって所有されていないが、その代わりに、必要に応じて、ＢＲＰの所有者またはユーザーによって利用され、支払われる。例えば、Ａｍａｚｏｎ＿Ｗｅｂサービス（ＡＷＳ）によって提供されるようなクラウドサービスがＢＲＰ（１０２）を実行するために利用することができる。

【0048】

図２に示されたＨＰ２コンピュータアーキテクチャ（１４０）は、多くの点で、従来の作業界のプラクティスと異なる。すべてのコンピュータタスクを計算し、データベース・サーバの両方を含有よく制御された高性能なクラウドサービスで行われている一方で、特に、制御及びプレゼンテーションの機能が、僅かなクライアント・のユーザー・インターフェース装置（１４６）において分離される。コンピュータ・マシンは、タスクまたは学問分野（建築家、構築エンジニア、メカニカルエンジニア、演算アナリスト）の種類ごとに割り当てられていないが、フローサーバとして機能し、エンジンを計算するためにプールされる。この集中化アプローチは、デザインセッションが開始され、フローサーバは、そのデザインセッションのすべてのタスクを調整するようにフロー・サーバがコンピュータプールから引き出されているという点で、効率を最適化する。また、データベースサーバは学問分野ごとに編成されていない、つまり、それぞれの学問分野、例えば、建築家、構築エンジニア、メカニカルエンジニア、演算アナリストに対して、おのおの１つのデータベースサーバが、それぞれ構成されている。図２のアーキテクチャにおいて、高帯域幅／大容量データトランザクションは、データベースサーバ（１５４）とコンピュータサー（１５８）の間で発生する。

【0049】

ＢＲＰ（１０２）とＨＰ２コンピュータアーキテクチャ（１４０）は図１及び図２を参照して説明したように、構築開始から完全に定義されたシステムの統合まで階層的な並列設計技術を実行するために組み合わせて利用されるが、従来の建築設計の分野では想定されていない。図３は、階層的な並列設計技術の一実施形態を例証しており、当該階層的な並列設計技術は、顧客のニーズ、例えば建築開始から始まり、完全に定義されたシステム統合の多数を通る。ＨＰ２コンピュータリソースを使用して、ビジネスのモデル化から空間的な配置まで、各ドメイン内のさまざまなオプションをシステム統合に実現することができ、並列的に吟味され得る。プロセスの各ステップで、インスタンススペシフィック（ｉｎｓｔａｎｃｅ−ｓｐｅｃｉｆｉｃ）データは、後続の設計分析および／または変形例における使用のために保存し、維持することができる。さらに、並列階層的なアプローチは、顧客のニーズの同じ集合に係るすべての異なる多くの設計スキームの開発と追跡を可能にする。図３の実施形態において、顧客ニーズデータベース（１７０）は、異なるビジネスモデルの集合、ビジネスモデルデータベース（１７２）を生成するために使用される必要がある。それぞれ異なるビジネスモデルのデータベースは、空間的配置データベース（１７４）として記憶される空間的配置の集合を生成するために使用される。それぞれ異なる空間的配置のデータベースは、システム統合設計データベース（１７６）として格納されるシステム統合デザインのセットを生成するために使用される。

【0050】

図３に例証された並列階層的なプロセスを、図３〜１０を参照してより詳細に説明する。図４は、顧客ニーズのドメイン（１１０）、ビジネスモデルのドメイン（１１２）、空間的配置のドメイン（１１４）、システム統合のドメイン（１１６）、及びＢＲＰの製造ドメイン（１１８）における動作を起動するための選択可能なタブ又はアイコンを含むＢＲＰ（１０２）のユーザー・インターフェースの一実施形態を示す。顧客ニーズドメインの中で、顧客のニーズが指定される。実施形態では、顧客ニーズは、顧客ニーズの形式記述としてクライアントデバイスのウェブベースのユーザー・インターフェースに表示される。たとえば、顧客のニーズの形式記述は、コンピュータサイエンスにおいて公知であるように、顧客ニーズが作用され得るように特定の概念を正しく、正確に、かつ明確に表す情報の正式の記述である。

【0051】

一実施形態において、顧客ニーズは、医療施設などの特定の使用のために建築を構築するために探している法人（ｅｎｔｉｔｙ）によってクライアントデバイスを介してＢＲＰ（１０２）に入力される。例えば、法人または「顧客」が、予想需要を満たすために特定のＺＩＰコード内の住民に十分な急性期医療サービスを提供したいことを指定することができる。別の実施形態では、顧客ニーズは、プロジェクトの場所、サービス目標、事業目標、および／または顧客のニーズの優先順位を反映しているかもしれない。たとえば、顧客ニーズは、建築中に提供されるサービスの種類、設備投資の制限、投資収益率（ＲＯＩ）の要件および／または種々の設計案を評価する指標において提供されるサービスの量を指定し得る。

【0052】

実施形態において、ヘルスケア建築システムに関連する顧客ニーズは、建築システムのための所望の場所、建築システムのためのケアのモデル、および顧客の価値を含む。価値について、ユーザー・インターフェースは、技術革新、持続可能性、ライフサイクルコスト、ヘルスケアの改善、効率性、柔軟性などの概念をユーザーが如何に評価するかについて、スライディングスケールで、評価することができる。一実施形態では、顧客ニーズドメインは、所望の建築システムの場所のマップ、所望の場所のための人口調査データ（ｃｅｎｓｕｓ ｄａｔａ）、および疾病管理センター（ＣＤＣ）情報などの公衆衛生情報などの出力をユーザーに提供することができる。実施形態では、マップは、ポインタ又は「ピン」を含み、ポインタ又は「ピン」は、関連施設、例えば、所望の場所の近傍に位置する他のヘルスケア施設、医師、研究室などの施設を識別する。

【0053】

顧客ニーズに関連する情報は、ついで、ＢＲＰ（１０２）の顧客ニーズデータベース（１７０）に格納され得る。例えば、プロジェクトは名前が与えられ、場所、ケアのモデル、価値評価、マップ情報、人工調査情報、及びＣＤＣ情報を含むプロジェクト情報は、プロジェクト名の下ですべてのＢＲＰのデータベースに格納される。異なるプロジェクトは異なるプロジェクト名で確立することができ、顧客ニーズドメインにおけるユーザー特定基準は、変更することができる。

【0054】

特定された顧客ニーズによって、プロセスは、ビジネスモデルドメイン（１１２）まで移動することができ、顧客ニーズは入力として使用され、多数の異なるビジネスモデルは出力として提供される。図３の実施形態において、より多くの異なるビジネスモデルが顧客ニーズの同じ集合から生成され得ることが理解されるべきであるが、３つの異なるビジネスモデルが出力（ＢＭ１、ＢＭ２およびＢＭ３）として提供される。実施形態では、ビジネスモデルは、指定された顧客ニーズを満たすために必要とされる建築の「プログラム」を定義する。例えば、ビジネスモデルは、サービスのタイプが建築に提供され、どのような量でサービスが提供されるかを指定する。ビジネスモデルは、建築の初期のシェルを指定することもできる。したがって、ビジネスモデルは、空間の元と時間の次元の両方を含むことができる。

【0055】

図３に例証されるように、複数の異なるビジネスモデルは、顧客ニーズの同じ集合から並列的に発生させることができる。実施形態では、ビジネスモデルの生成は、並列に異なる設計を多数生成し、評価することができる、ンピュータ集約的な設計のプロセス、シミュレーション、最適化、および検証を含む。例えば、顧客ニーズの単一のセットから数十分のビジネスモデル（例えば、１時間未満）に関連する異なる数百乃至数千のオーダーでの繰り返しで、設計、シミュレート、最適化、および検証することが可能である。

【0056】

一実施形態では、ビジネスモデルドメイン（１１２）で実行するコンピュータ集中型の演算は、特定の建築によって提供されるべきサービスの種類とボリュームを決定するために、挙動シミュレーションを伴う。挙動シミュレーションは、ビジネスモデルの策定と実施の基礎となるプロセスの研究に適している。例えば、挙動シミュレーションは制御またはコンテキストを測定する、歴史的事実を扱って、問題全体でのプロセスの違いを把握し、成果にプロセスをリンクする、複数のレベルでの測定変数を含むことができる。ビジネスモデルドメインで実行される挙動シミュレーションは、論理的に建築の結果として得られる設計、構築、および演算にリンクされる。

【0057】

ビジネスモデルドメイン（１１２）を通じて、顧客ニーズを満たすために生成される、顧客ニーズとビジネスモデルとの間の直接的な関係が存在するように、ＢＲＰ（１０２）は顧客ニーズへの依存関係を追跡する。顧客ニーズの変化は、ビジネスモデルドメインに伝播することができ、顧客のニーズを満たすために、必要とされるようにビジネスモデルへの変更がなされ得る。また、既に生成されたビジネスモデルは顧客のニーズの変化に照らして評価することができる。各インスタンスが独立してアクセスして変更することができるように、それぞれ異なるビジネスモデルの各インスタンスは、一意のデータベースに格納される。ビジネスモデルの各インスタンスの一意の格納は、個々のビジネスモデルにアクセスすることができ、評価され、および／または顧客のニーズの同じセットに対応する他のビジネスモデルに影響を与えずに変更され得る。

【0058】

一実施の形態では、ビジネスモデルは、サービスライン（例えば、緊急のケア、健康のケア、イメージング、実験室）および／または建築システムによって提供される部署、建築システムへの患者の負荷、及び部屋とスタッフのニーズ（例えば、部屋数とスタッフの種類の数と種類）を識別する。ビジネスモデルの出力は、ＢＲＰ（１０２）のユーザー・インターフェースを介してユーザーに提供することができる。

【0059】

図５は、ＢＲＰ（１０２）のビジネスモデルドメイン（１１２）からのユーザー・インターフェースの実施形態を示す。ユーザー・インターフェースは、医師の数（ＭＤＳ）、医療助手（ＭＡＳ）の数、看護師の数（ＲＮＳ）、トリアージ（ｔｒｉａｇｅ）領域の数、心的外傷（ｔｒａｕｍａ）の部屋の数、急性期ケアの数、試験室の数、観察用ベッドの数、撮影室の数、手術室の数、病床数の数などのビジネスモデルについての情報を表示する。ビジネスモデルドメイン内で、建築システムの挙動が、ＢＲＰに組み込まれている建築モデルおよび種々のワークフローロジックの基準に基づいてシミュレートすることができる。ＢＲＰのユーザー・インターフェースは、シミュレーションで使用するために、変更するビジネスモデルの特定のパラメータを可能にする。例えば、ユーザー・インターフェースは、ユーザーが、急性期医療試験室の数、試験室の数は、観測室の数、心的外傷の部屋の数、医師の数、および登録された看護師の数などのビジネスモデルのいずれかに関連するパラメータを調整することができる。

【0060】

図６は、ビジネスモデルドメイン内で生成されたシミュレーション結果を示すビジネスモデルドメイン（１１２）からのユーザー・インターフェースの実施形態を示す。例えば、結果は、入力パラメータの特定のセットを与えられた患者の滞在の長さに関連する。実施形態では、事象駆動のシミュレーションが実行され、別のシミュレーションが特定ＨＰ２コンピュータリソースを使用するように設定されている。例えば、各コンピュータオペレーションはＭａｐＲｅｄｕｃｅの技術を用いて、大規模な処理システムにおける処理ハードウェアの特定のセットにマッピングされる。

【0061】

図３に戻って参照すると、指定された様々なビジネスモデルと、並列階層的なプロセスは、出力として提供されるビジネスモデルを入力し、複数の異なる空間アレンジとして使用される空間的配置のドメインに移動することができる。図３の実施形態において、少なくとも３つの異なる空間的配置が、各ビジネスモデルに対して生成される。図示されているように、空間的配置ＳＡ１１、ＳＡ１２、ＳＡ１３およびＢＭ１は、空間的配置ＳＡ２１、ＳＡ２２から生成され、ＳＡ２３はＢＭ２から生成され、かつ空間的配置ＳＡ３１、ＳＡ３２およびＳＡ３３はＢＭ３から生成される。三つの異なる空間的配置は、各ビジネスモジュールから生成されるが、さらに多くの異なる空間的配置が、ビジネスモデルの同じ集合から生成され得ることは理解されるべきである。実施形態では、空間的配置は、建築や部屋の配置の基本構造を含む３次元空間として建築システムを定義する。例えば、空間的配置は、建築のおおよその面積、建築内の床数、数、種類、場所、面積、および建築内の部屋の機能を定義する。

【0062】

実施形態では、空間的配置は、大規模な並列処理システムのコンピュータ資源を使用して生成される。例えば、大規模な処理システムのコンピュータリソースを設計するために使用される、モデリング、シミュレーション、最適化、及び異なる空間配置を確認する。

【0063】

一実施形態において、空間的配置ドメイン（１１４）における処理は、隣接の基準と挙動シミュレーション性能に基づく部門および／または部屋のコンピュータ支援の配置を含む。コンピュータ支援の配置とＨＰ２コンピュータリソースを使用して、多くの異なる空間的配置が、モデル化され、シミュレートされ、最適化され、かつ比較的短時間で確認することができる。例えば、建築システムのエネルギー効率のシミュレーションは、各々が一時間を完了するために必要な千もの別個のコンピュータタスク又はジョブを含むことができる。ＨＰ２コンピュータリソースを使用して、千もの別個のコンピュータタスクが、大まかに千倍のタスクを完了するために必要な時間を短縮しつつ、別個のプロセッサ（例えば、別々の物理ハードウェアデバイス）によって並列に処理することができる。

【0064】

空間的配置ドメイン（１１４）内で、ＢＲＰ（１０２）は、空間的配置、建築モデル、及び最終的に顧客ニーズの間に直接的な関係が存在するように、対応するビジネスモデルへの依存性を追跡する。顧客ニーズドメイン又はビジネスモデルドメインにおける変更は空間的配置領域に伝播することができ、変更は必要に応じて空間的な配置にすることができる。さらに、それぞれの異なる空間的配置の各インスタンスは、各インスタンスが独立してアクセスし、演算することができるように、データベースに一意的に格納することができる。ビジネスモデルと空間的な配置が階層順に維持されているので、特定の階層的なチェーンに影響を与える唯一の変更は、空間的配置に伝播する必要がある。たとえば、変更がＢＭ１の面にだけ行われると、変更は空間配置ＳＡ１１、ＳＡ１２、ＳＡ１３に伝搬することができる一方で、ＢＭ２とＢＭ３にリンクされている空間的配置（例えば、それぞれＳＡ２１、ＳＡ２２、ＳＡ２３、及びＳＡ３１、ＳＡ３２、ＳＡ３３）は影響を受けない。

【0065】

一実施形態において、空間的な配置は、「フォーム」と「シェル」、「ブロック」と「スタック」及び「部屋の配置」に関連する建築システムの面を指定する。一実施の形態において、空間的配置ドメイン（１１４）内のフォームとシェルは、形状（例えば、建築パターンや建築パーティション）とビルシステムの大きさなどのパラメータを指定する。フォームとシェルは、顧客ニーズにおいて特定された場所で建築の向きや場所を指定することもできる。特定されたフォームとシェルから、種々のモデル、シミュレーション及び／又は最適化が、ＨＰ２コンピュータリソースを使用して行われ得る。たとえば、ＨＰ２コンピュータリソースを使用して、エネルギー効率のシミュレーションと最適化演算は、これまでは不可能であった規模で行うことができる。図７は、空間的配置ドメインにおけるフォーム及びシェルタブからのユーザー・インターフェースの一実施形態を示しており、当該空間的ドメインはフォーム及びシェルで実行されるエネルギー効率のシミュレーションの調整可能なパラメータを示している。シミュレーションのための調整可能なパラメータは、年の時間（例えば、月）、建築の向き、異なる方向、例えば、東、西、北、南における光沢−不透明比率を含む。

【0066】

一実施形態では、空間的配置ドメイン（１１４）内のブロックとスタックは、部門ブロックと循環要素が建築システムの指定されたフォームとシェル内に配置する方法を指定する。例えば、ブロックとスタックは、如何に部門ブロックを互いに水平方向に構成するか、及び如何に部門ブロックを互いに垂直方向に（例えば、高層建築の異なるフロア間に）構成するか、或いは「積む」かについて定義する。特定されたブロックとスタックから、様々なモデル、シミュレーション、および／または最適化が、ＨＰ２コンピュータ資源を用いて行うことができる。例えば、演算は、相互に作用する部門の距離探査、部門距離による挙動シミュレーション、および個々の部門のブロックの生成を含み得る。図８は空間的配置ドメインのブロックとスタックタブからのユーザー・インターフェースの一実施形態を示し、当該空間的配置は特定のブロック及びスタックが与えられた特定の部門間の移動距離及び時間を決定するために、シミュレーションの出力を示す。

【0067】

一実施形態では、空間的配置ドメイン（１１４）内の部屋の配置は、特定のブロックとスタック構成を有する建築のシステム内で特定の部屋の位置を指定する。指定された部屋の配置から、様々なモデル、シミュレーションおよび／または最適化がＨＰ２コンピュータリソースを使用して行うことができる。例えば、演算は、相互に作用する室の距離の探査、部屋の距離による挙動、および退出設計ルールチェックを含み得る。図９及び図１０は、空間的配置ドメインの部屋の配置タブからのユーザーインターフェースを示している。特に、図９は、異なる部屋の配置設計を示しており、当該設計は与えられた基準の集合に基づいて生成される。

【0068】

図３に戻って参照すると、生成され、保存されたさまざまな空間的配置によって、プロセスはシステム統合ドメインに移動することができ、空間配置は入力として使用され、複数の異なるシステムの統合設計は出力として提供される。実施形態では、システム統合設計は、建築の３Ｄ空間と建築のインフラを定義する。例えば、建築のためのシステム統合の設計は、建築システムのインフラ構成要素の三次元での配置（すなわち、３Ｄ空間）を定義する。システム統合設計で指定された建築のインフラは、例えば、機械的、電気的、及び配管（ＭＥＰ）システム、情報技術（ＩＴ）、安全及びセキュリティ構成要素、および照明の配置と仕様を含み得る。システム統合設計では、建築インフラ構成要素の位置が完全に定義され、建築システムの３次元空間内に一体化される。実施形態では、異なるシステム統合設計システム統合設計を設計し、モデル化し、シミュレーションし、最適化し、及び検証するために、大規模な処理システムのコンピュータ資源を使用して、並行して生成される。

【0069】

図３の実施形態では、少なくとも３つの異なるシステムの統合は、各空間的配置のために生成される。図示されるように、システム統合設計（ＳＩＬ１１）、（ＳＩＬ１２）、（ＳＩＬ１３）は、空間的配置（ＳＡ１１）のために生成され、システム統合設計（ＳＩ１２１）、（ＳＩ１２２）、及び（ＳＩ１２３）は空間的配置（ＳＡ１２）のために生成され、システム統合ション設計（ＳＩ１３１）、（ＳＩ１３２）、及び（ＳＩ１３３）は空間的配置（ＳＡ１３）のために生成されるなど、トータルで２７の異なるシステム統合設計のために生成される。三つの異なるシステム統合の設計は、各空間的配置のために生成されるが、さらに多くの異なるシステムの統合の設計が同じ集合の空間的配置から生成され得ることは理解されるべきである。図３に示されるように、多数の設計オプションが、同じ集合の顧客ニーズから生成することができる。さらに、すべての異なる設計オプションを設計し、モデル化し、シミュレーションし、最適化し、および検証することのコンピュータタスクは、非常に高速になるように成長し得る。したがって、集中型のＢＲＰ（１０２）によるＨＰ２コンピュータリソースの使用が並列階層設計技術を可能にするための鍵となる。

【0070】

一実施形態において、顧客ニーズの集合からシステム統合設計に辿るプロセスは、ＢＲＰ （１０２）によって維持される統一されたデータモデルによってサポートされる。図１１は、コンピュータ建築システムの設計、モデル化、シミュレーション、最適化、および検証においてＢＲＰによって使用される統一されたデータモデル（１９０）の一例を例証する図である。図１１に示されるように、統合されたデータモデルは、挙動階層（１９２）、空間的階層（１９４）、及び物理階層（１９６）を含む。

【0071】

一実施形態において、挙動階層（１９２）は、特定の設備を用いて、専用の部屋での個人による単一の活動から、部門におけるプロセス、建築ワイドの演算モデルへのサービスライン又はビジネスユニットにおけるプロセスまでの、演算およびビジネスプロセスを定義する。挙動の記述は、抽象化の様々な程度を持つことができる。例えば、部門が特定の機器を必要とし、コストをかけ、収益を生成し、又はスタッフの活性、患者の処理、時間をかけ、コストをかけ、患者を処理するアクティビティに向かって、収益を生成する単一のアクティビティとして記述することができる。人間の挙動記述に加えて、また、エネルギー、光、水、例えば、ヒト以外の要素のための挙動の説明があり得る。図１１において、挙動階層は、活動性から、プロセス、サービス、建築の演算までに亘って、挙動階層の各レベルが、その前より抽象的である。

【0072】

実施形態では、空間的な階層（１９４）は、建築物の容積が如何に構成されるかを説明している。例えば、建築物は階を有しており、各階は、部門ブロックと廊下を有しており、部門ブロックは部屋、廊下や循環スペースを有しており、部屋は家具／什器／備品（ＦＦＥ）要素を含む。空間的な説明は、抽象化の種々の程度の抽象化を有することができる。例えば、建築物は漠然とした建設可能な容積、場所によって決定される容積、物理的制約、法的制約、および所有者の好みから、建築物の構成を記載している建築の部分、例えば、アトリウム対屋根の概念に向けて、主要な水平および垂直循環領域の記述に向けて、建築の様々なセクションに部門のグローバルな配分に向けて、建築内のすべての部屋と廊下の正確な場所に向けて記載され得る。図１１において、空間的な階層は、部屋のレイアウトから、空間階層の範囲、部門のレイアウト、ブロックとスタックのレイアウト、建築物のレイアウト、まで、空間的な階層の各レベルは、その前よりも抽象的である。

【0073】

物理階層（１９６）は、物理的な建築があらかじめ定義された建築部材のリストから如何にして構成されるかを説明する。図１１において、物律的な階層は、材料から、構成要素、システム、建築物までに亘って、物理的な階層の各レベルは、その前よりも、より抽象的である。例えば、建築物の構成要素は、内壁、外壁、床パネル、ルーフパネル、浴室のポッド、集約機器の壁床モジュール、装置部品やポッド、ユーティリティフレーム、コンクリート構造物の鉄筋ケージとしてあらかじめ定義された物理的なコンポーネントのセットを含んでもよい、金属やコンクリートの床アセンブリ、構造用鋼、およびユーティリティシステム。実施形態では、このような寸法、性能特性、美的の評価、環境問題、コスト、製品寿命等の建築部材の特定の態様は、予めに知られており、ＢＲＰ（１０２）の異なるドメインに、必要に応じて使用される。上述したように、予め定義された建築構成要素は、既知の特性によって、複雑な建築のシステムを設計し、モデル化し、シミュレーションし、最適化し、および検証するために、数理モデルの開発と再利用を可能にする。

【0074】

データ階層のおのおのに対して、そして各階層レベルで、抽象的な説明と、１つ以上の構造的な説明の両方が存在する。すなわち、統一されたデータモデル内で、オブジェクト（ｏｂｊｅｃｔ）は、下位レベルのオブジェクトの接続されたインスタンスの集合から構成されるとして記載されている。たとえば、定期的な検査のために入ってくる患者のプロセスは、別の人が関与し、別の場所で発生する個々の活動の連結グラフとして記述することができる。統一されたデータモデルは、設計、シミュレーション、最適化、および／または検証演算でＢＲＰによって使用されてもよい。

【0075】

並列階層設計技術が図１乃至１１を参照して説明される。前述したように、並列階層設計技術は、多くの異なったビジネスモデル、空間配置、およびシステム統合設計を、並行して、設計の依存関係を維持して階層的に処理するために、集中型のＢＲＰ（１０２）とＨＰ２コンピュータアーキテクチャ１（４０）を使用する。顧客ニーズのセットから、システム統合設計を生成するための技術の実施形態を、図１２を参照してより詳細に説明する。特に図１２は、顧客ニーズの集合から、システム統合設計を生成するためのコンピュータベースの技術のプロセスフロー図である。当該技術は、これまで想定されておらず、かつ特定の専門家が所有するデータベースを含む従来のＰＣベースのコンピュータシステ及び従来の建築システムを用いて達成できなかった設計プロセスを実行するためのＨＰ２コンピュータリソースによって実行される、コンピュータ集約シミュレーション、最適化、および検証演算に依存する高度に相互作用するコンピュータベースのプロセスループ（２００）を利用する。

【0076】

ブロック（２０２）において、顧客ニーズが指定される。たとえば、顧客ニーズは、特定の機能の説明に従って入力顧客にユーザーを照会する必要があるユーザーインターフェースを介して指定される。顧客ニーズドメインで処理される情報の例は上述した。

【0077】

ブロック（２０２）において、建築および／または演算フロー並びに建築の法律を含む最良のプラクティスに関連する情報などの追加情報は、顧客ニーズの一部として入力することもできる。例えば、建築開始から設計に組み込まれるべきである、位置固有および／または顧客固有の最良のプラクティスおよび建築の法律があり得る。顧客ニーズ（最良のプラクティスや建築基準を含む）を上記のようにデータベースに格納される。

【0078】

ブロック（２０４）で、少なくとも一つのビジネスモデルが顧客ニーズに応じて生成される。一実施形態において、ビジネスモデルは、建築物が提供するサービスと、提供されるサービスの量を指定する。特定の郵便番号の住民に対して急性医療サービスを提供することを期待している顧客の場合には、ビジネスモデルは、予想される需要を満たすために提供されるべき急性医療サービスのタイプと量を定義することができる。ブロック（２０６）において、ビジネスモデルのうちの１つまたは複数の挙動がシミュレートされる。一実施形態において、指定されたサービスが如何にして提供されることができるかを決定するために、挙動シミュレーションはワークフローモデリングを使用する。例えば、シミュレーションは、提案されたビジネスモデルが如何にして実行するかを決定するために、スペースパターンによって、人のワークフロー・パターンとプロセスのワークフローパターンを比較することができる。挙動のシミュレーションの結果は、患者の待ち時間、機械の稼働率、必要なスタッフの数、スタッフの利用、空間使用率、エネルギー効率のようなパラメータのグラフやレーティングとして、例えば、パフォーマンス指標の形式で出力することができる。種々の異なるパラメータは、挙動シミュレーションに基づくビジネスモデルの望ましさを評価するために使用することができる。

【0079】

ブロック（２０８）で、挙動のシミュレーションの結果は、顧客ニーズが満たされているかどうかを評価することができる。これは、直接的な人の相互作用を含む手動プロセスであり、あらかじめプログラムされた基準に基づく自動処理（非人（ｎｏ ｈｕｍａｎ）の相互作用）、またはそれらの組み合わせを含む。ブロック（２１０）では、顧客ニーズおよび／またはビジネスモデルを変更することも可能である。顧客ニーズとビジネスモデルの変更は、例えば、挙動シミュレーションを含む、フローの下流に伝播され得る。

【0080】

ブロック（２１２）では、一度挙動シミュレーションが、特定のビジネスモデルが顧客ニーズを満たしていることを示すと、ビジネスモデルは、コンピュータベースの最適化プロセスを介して加えられ得る。例えば、コンピュータベースの最適化プロセスは、建築設計の特定の面を最適化するために、多数の設計案を介して実行することができます。実施形態では、最適化プロセスは、顧客ニーズにおいて指定されている重要な領域を最適化しようとする。例えば、顧客が労働者の利便性に高い価値を置く必要がある場合、労働者の歩行距離を最小限に抑える設計が好まれることがある。同様に、顧客がエネルギー効率に高い価値を置く必要がある場合、人工光とＨＶＡＣの必要性を最小限にする設計が好まれ得る。最適化の他の基準は、投資収益率（ＲＯＩ）、資本支出の営業費用、患者の待ち時間、またはそれらの任意の組み合わせを含んでもよい。

【0081】

病院などの複雑な建築システムでは、顧客ニーズは広い範囲の設計の優先度を規定する。当該優先度は多変数の多次元分析を通じて最適化することができる。多数の設計変数の多次元分析は、図２を参照して記載されたとおりのＨＰ２コンピュータリソースによってコンピュータ処理される。

【0082】

ビジネスモデルが、ブロック（２１４）で最適化されると、最適化されたビジネスモデルは、検証プロセスを経て配置される。検証プロセスは、特定のビジネスモデルが特定の設計ルール（例えば、デザインルールチェック）を満たしているか否かを確認し、および／またはビジネスモジュールが指定された顧客ニーズを満たしているか否かを確認するためにチェックする。新たなビジネスモデルを生成し（または、既存のビジネスモデルを変更し）、挙動的に新たなビジネスモデルをシミュレートし、新たなビジネスモデルを最適化し、及び新たなビジネスモデルを検証するプロセスは、設計が空間的配置ドメインに移動する前に、複数の反復を介して実行することができる。

【0083】

ブロック（２１６）において、各検証ビジネスモデルは、一つ以上の空間的配置を生成するための入力として使用することができる。上述したように、空間的配置は、建築システムのフォーム及びシェル、建築システムのブロックとスタック配置、及び屋の配置を指定することもできる。空間的な配置は、はＨＰ２コンピュータ資源を用いて説明したようにシミュレーションされ、および／また最適化され得る。ブロック（２１８）および（２２０）において、空間的な配置は、検証および変更の反復プロセスを介して処理することができる。例えば、検証演算は、設計ルールチェックを含み得、および修正は空間的配置の１つまたは複数のパラメータを調整すること含み得る。

【0084】

ブロック（２２２）において、検証された各空間的な配置は、１つ以上のシステム統合設計を生成するための入力として使用することができる。上述したように、システム統合設計は、建築システムの３Ｄ空間とインフラを指定することができる。必要に応じて、システム統合ドメインにおいて、システム統合設計は、ＨＰ２コンピュータリソースを使用してシミュレートし、最適化されてもよい。ブロック（２２４）及び（２２６）において、空間的統合設計は、検証および変更の反復プロセスを介して処理することができる。例えば、検証演算は設計ルールチェックを含み、および修正は、１以上のシステム統合設計の１つまたは複数のパラメータを調整すること含むことができる。システム統合設計の出力は、それぞれ、ブロック（２２８）、（２３０）、（２３２）、及び（２３４）によって表される製造、組立、試運転、そして、オペレーションドメインの演算を実行するために使用することができる。

【0085】

図１３は、システム構成要素と、ＢＲＰ（１０２）を使用してビジネスモデルから空間配置を生成するための対応するプロセスフローを示す。システム構成要素は、少なくとも１つのビジネスモデルデータベース（１７０）、少なくとも１つの空間配置データベース（１７４）、分析データベース（２４０）、建築設計知識ベース（２４２）、合成ツール（２４４）、分析ツール（２４６）（例えば、シミュレーション、および／または検証）、および最適化ツール（２４８）を含む。建築設計知識ベースにおいて、コード及びルール構成要素（２５０）は建築コードと、建築設計ルールを含み、パターン構成要素（２５２）は、設計パターンの予め確立された集合（例えば、アーキテクチャパターンや建築部分）、ヘルスケア（ＨＣ）プロセス構成要素（２５４）は、ヘルスケアプロセス・ワークフロールールを含み、ルーム・ライブラリ（２５６）は、特定の物理的および／または動作上の特徴を有する予め確立された部屋の集合を含む。演算において、ビジネスモデルからの情報は、１つまたは複数の空間的配置を生成する合成ツールによって処理される。合成ツールは、空間的配置を生成するために、建築設計の知識ベースと設計意図（２５８）（例えば、設計基準）からの情報を使用する。空間的配置は、次いで、所望のとおりに分析される（例えば、シミュレートされ、および／または検証される）ことができ、分析の結果は、分析データベースに格納される。最適化ツールは設計意図（例えば、建築物の向き（図７参照）又はウイング当たりの部屋の数若しくは看護師の比率（図９参照））のパラメータを変更するために使用することができ、ついで、最適化された空間配置を生成するために合成ツールを介して伝達される。

【0086】

ＢＲＰ（１０２）は病院などのヘルスケア建築の文脈で説明したが、上述したＢＲＰおよび関連する技術は、他の建築及び建築システムに適用可能である。例えば、ＢＲＰおよび関連する技術は、ホスピタリティーの建築（例えば、ホテル）、アパート／コンドミニアム建築、輸送施設（例えば、空港）にも適用可能である。さらに、建築システムは、互いに着脱でき、互いに部分的に取り付けられ、または互いに完全に結合することができる１または複数の建築を含み得る。例えば、建築システムは、建築又は物理的に同じ場所／位置に配置されており、顧客ニーズのセットを満たすように意図されている建築の集合であってもよい。

【0087】

図１４は、ネットワーク及びＢＲＰ（１０２）が実装されるクラウドサービスのクライアント側のユーザー・インターフェース装置（１４６）に対するＢＲＰの一実施形態のアーキテクチャの実施形態を示す。図１４に示されるように、ＢＲＰは、ＢＲＰアプリケーション（３００）、実現エンジン（３０２）、アプリケーションプログラミングインターフェース（ＡＰＩ）（３０４）、ミドルウェアコネクタ（３０６）、およびデータベース（３０８）を含む。一実施形態では、実現エンジンはＢＲＰの設計、モデル化、シミュレーション、最適化、検証サービスを提供し、及びＢＲＰアプリケーションは、ユーザー・インターフェースを介して、クライアントデバイスのユーザーが通信し、制御することができるロジックと、実現エンジンによって提供されるサービスとを提供する。ＡＰＩは実現エンジンからデータを取得し、データベースにデータを提供できるようにするためのロジックを提供する。ミドルウェアコネクタは実現エンジンとデータベースの間に抽象化レイヤを提供する。データベースは、設計、モデル化、シミュレーション、最適化、および建築システムの検証に関連するデータを格納する。図１４の実施形態において データベースのデータは他の方法で編成することができるが、データベースは、構築データベース（３１０）、分析データベース（３１２）、プロセス知識のライブラリ（３１４）、及びデザインルールのライブラリ（３１６）を含む。実施形態では、ＢＲＰアプリケーション、実現エンジン、ＡＰＩ、およびミドルウェアコネクタおよびデータベース内のデータを実行するために必要なコンピュータ可読命令は、クラウドサービスのサーバに格納されている。実行するために呼び出されると、命令および対応するデータは、上述のとおりに、クラウドサービスのプロセッサによって処理される。

【0088】

図１５は、実現エンジン（３０２）１つによって提供されるサービスの実行を示す図である。たとえば、サービスは、多数の物理的に別個のプロセッサまたは分離したプロセッサコアの間で、１組のコンピュータタスクを分配することを含むシミュレーションである。図１５に示すように、同じシミュレーション演算に関連するＮ個の異なるコンピュータタスクは、Ｎ個の異なるプロセッサ（３５０）の間で分配され、ここでＮは、例えば１００乃至１０００の範囲である。上述のとおり、プロセッサは、クラウドサービスを介して提供され、必要な場合のみに使用することができる。

【0089】

実施形態では、ＢＲＰ（１０２）は、ユーザーのニーズや、建築の法律とそれに対応する業界のベストプラクティスを含む包括的なセットのルールに基づいて、仮想の建築の生成と最適化を可能にする。ユーザーは、非常に抽象的な記述（例えば、要求を満たすのに十分な救急ケアの能力によって、郵便番号のセットで定義されている地域にサービスを提供する）から、如何にして建築物を建設するか、及び建築システムが如何に実行するかについて曖昧さをなくす、建築の意図を含む完全に詳細な説明、建築工学上の詳細および構築の詳細まで、徐々に設計を変える設計フローを使用して仮想の建築を作成する。仮想建築がＢＲＰの範囲内で完了すると、詳細な演算および構築の文書は、様々な業界標準のフォーマットのＢＲＰによって生成することができる。一実施形態において、ＢＲＰによって維持される仮想建築システムは、建築とそのすべてのサブシステムに関する詳細情報が含まれ、演算コスト、構築コスト、熱的快適性のレベル、昼光利用、持続可能性などの多くの次元に沿った、その使用とそのパフォーマンスについて、業務の効率化、患者の経験を含む。ＢＲＰによって維持される仮想建築システムは、詳細かつ明確にそれが仮想建築システムの性能と一致する性能を有する実建築システムの構築のための詳細な構造のドキュメントを生成するために使用することができるように十分に正確である。

【0090】

実施形態では、ＢＲＰによって維持された仮想建築システムは、建築の寿命の間に変更の示唆を予測することができる。一実施形態において、仮想建築システムは、建築構造、プロセスライン及びサービスライン、機械、電気、配管（ＭＥＰ）サブシステム、情報技術（ＩＴ）サブシステム、熱／エネルギー挙動、地震挙動、光挙動、音挙動の説明を含む。実施形態では、ＢＲＰにおいて維持される仮想建築システムは、次の方法における現在のプラクティスと異なる。すなわち、物理的な建築の説明に加えて、仮想建築システムは、建築とプロセスの両方が設計され、一緒に測定される必要があるので、建築の目的と演算説明を含む。建築についての情報は、別々に分割される。従来から、情報はドメインごと（建築構造、機械系、電気系）ごとにグループ化されるが、ドメイン間の緩い結合はある。全体的なアーキテクチャが隔離されたシステムの連合化されたネットワークであり、それぞれが黄金の設計情報の一部を保持し、必要性ごとに標準プロトコルを使用して相互に最低限の情報を交換する、現在の建築インフォメーションモデリング（ＢＩＭ）プラクティスとは異なり、本明細書に記載されたアプローチは、異なるシステムがＢＲＰを介して排他的に通信するスター型の構成である。黄金の設計情報は、中央のデータベースに存在し、衛星システムは、中央の黄金の情報やレポートを変更する薬剤として使用される。

【0091】

図１６は、複雑な建築システムを実現するための方法のプロセスフロー図である。ブロック（４００）において、建築システムのための顧客ニーズに関連する入力が受け取られ、入力は、遠隔クライアントデバイスのユーザー・インターフェースを介して受信され、正式の記述言語で表現されている。ブロック（４０２）において、複数の異なるビジネスモデルは、顧客ニーズの入力から生成され、ビジネスモデルは、顧客ニーズを満たすために建築システム内で提供されるサービスの種類や容量を、機能的な言語で定義する。ブロック（４０４）において、複数の異なる空間的配置が前記ビジネスモデルの少なくとも１つから生成され、空間的配置は建築システムのフォーム及びシェル、建築システムのブロックとスタック、および建築システム内の部屋の場所を定義する。ブロック（４０６）において、複数の異なるシステム統合設計は空間的配置の少なくとも１つから生成され、システム統合設計は、建築システムのインフラの三次元空間を定義する。ブロック（４０８）において、依存関係は、顧客ニーズ、ビジネスモデル、空間的配置、およびシステム統合設計との間で追跡される。

【0092】

図１７は、ヘルスケアサービスが患者に提供される建築内のシステムを実現するための方法のプロセスフロー図である。ブロック（４２０）において、建築システムに対する顧客ニーズに関する入力が受信され、当該入力は遠隔クライアントデバイス上のユーザーインターフェースを介して受信され、形式記述言語で表現され、当該入力は建築システムが構築される場所の表示を含む。ブロック（４２２）において、少なくとも一つのビジネスモデルは、顧客ニーズ入力から生成され、ビジネスモデルは、建築システムを介して提供されるヘルスケアサービスの種類や容量を機能的な言語で定義する。ブロック（４２４）において、ビジネスモデルの様相がシミュレートションされる。ブロック（４２６）において、ビジネスモデルの様相が最適化される。ブロック（４２８）において、建築システムの少なくとも１つの空間的配置は少なくとも一つのビジネスモデルから生成され、ここで、建築システムの空間配置は、建築システムのフォーム及びシェル、建築システムのブロックとスタック、及び建築システムの部屋の配置を定義する。ブロック（４３０）において、建築システムの空間的配置の様相がシミュレーショントされる。ブロック（４３２）において、シミュレーションおよび最適化のコンピュータ集約動作は、大規模な処理システムの複数の異なるプロセッサ上で分配される。

【0093】

本明細書において方法の演算が示され、特定の順序で記載されているが、各方法の演算の順序は、特定の演算が逆の順序で行うことができるように変更され得るか、或いは特定の演算が少なくとも部分的に他の演算と同時に実行される。別の実施形態では、異なる演算の命令または部分演算（ｓｕｂ−ｏｐｅｒａｔｉｏｎ）が断続的におよび／または交互に実施され得る。

【0094】

方法のための演算の少なくとも一部は、コンピュータによる実行のための非一過性のコンピュータ使用可能記憶媒体に格納されたソフトウェア命令を用いて実行されてもよいことにも留意すべきである。一例として、コンピュータプログラム・プロダクトの実施形態は、コンピュータ上で実行するコンピュータ読み取り可能なプログラムを格納するコンピュータ使用可能記憶媒体を含む本明細書に記載されるよう、動作をコンピュータに実行させる。

【0095】

さらに、本発明の少なくとも一部の実施形態は、コンピュータ実行可能命令を提供するコンピュータ使用可能若しくは非一過性のコンピュータ可読媒体からアクセス可能なコンピュータプログラム・プロダクト、又はコンピュータ若しくは任意の命令実行システムによる使用又はコンピュータ若しくは任意の命令実行システムとの接続での使用のためのプログラムコードの形態をとることができる。この説明の目的のために、非一過性のコンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって、或いは命令実行システム、装置、またはデバイと接続して使用するためのプログラムを含むか、または格納することができる任意の装置であり得る。

【0096】

コンピュータ使用可能またはコンピュータ可読媒体は、電子、磁気、光学、電磁気、赤外線、又は半導体システム（または装置またはデバイス）であり得る。コンピュータ可読媒体の例は、半導体または固体メモリ、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、固定磁気ディスク、及び光ディスクを含む。光ディスクの現在の例は、読み出し専用メモリ（ＣＤ−ＲＯＭ）を備えたコンパクトディスク、読み出し／書き込み（ＣＤ−Ｒ／Ｗ）を備えたコンパクトディスク、及びデジタルビデオディスク（ＤＶＤ）を含む。

【0097】

実施形態において、上述の機能は、コンピュータ可読命令を実行する１台又は複数台のコンピュータによって実行される。図１８は、プロセッサ（５０２）、メモリ（５０４）、および通信インターフェース（５０６）含むコンピュータ（５００）を示す。プロセッサは、多機能型装置および／または特定用途のプロセッサを含むことができる。プロセッサの例は、ＩＢＭ社製のプロセッサのＰｏｗｅｒＰＣ（商標）のファミリー、プロセッサのＸｅｏｎ（商標）のファミリー及びＩｎｔｅｌＸ５６５０（登録商標）プロセッサのファミリーなどのインテル社製のプロセッサのｘ８６のファミリーを含む。コンピュータ内のメモリは、例えば、読み出し専用メモリ（ＲＯＭ）、フラッシュメモリ、ＲＡＭ、ハードディスクドライブなどの大容量永久記憶装置などの記憶媒体を含み得る。通信インターフェースは、例えばインターネットプロトコル（ＩＰ）を介して他のコンピュータとの通信を可能にする。コンピュータは、上述のように様々なタスクを実行するために、記憶媒体に記憶されたコンピュータ可読命令を実行する。

【0098】

上記の説明において、様々な実施形態の具体的な詳細を述べた。しかしながら、いくつかの実施形態は、これらの具体的な詳細のすべてより少ないもので実施することができる。他の例では、特定の方法、手順、構成要素、構造体及び／又は機能は、簡潔かつ明瞭にするために、本発明の様々な実施形態を可能にするために以下でより詳細に記載される。

【0099】

本発明の特定の実施形態を説明し、および例証したが、本発明は、特定の形態またはその説明し、および例証した部品の配置に限定されるものではない。本発明の範囲は、本明細書に添付の特許請求の範囲およびそれらの均等物によって定義されるべきである。

【0100】

上記の説明では、様々な実施形態の具体的な詳細が提供される。しかしながら、いくつかの実施形態では、これらの具体的な詳細のすべてより少ないもので実施することができる。他の例では、特定の方法、手順、構成要素、構造体、及び／又は機能は、簡潔かつ明瞭にするために、本発明の様々な実施形態を可能にするためにより詳細に記載されている。

【0101】

本発明の特定の実施形態を説明および図示したが、本発明は、特定の形態またはその説明および図示した部品の配置に限定されるものではない。本発明の範囲は、本明細書に添付の特許請求の範囲およびそれらの均等物によって定義されるべきである。

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図1】

【図2】

【図3】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】