JP2020509792A

JP2020509792A - 仮想環境のための動的設計データを管理するためのシステムおよび方法

Info

Publication number: JP2020509792A
Application number: JP2019537359A
Authority: JP
Inventors: スペンサー，ネイサン; ウィンクラー，ドワイト; ギレスピー，ガース
Original assignee: MZ IP Holdings LLC
Current assignee: MZ IP Holdings LLC
Priority date: 2017-01-11
Filing date: 2018-01-10
Publication date: 2020-04-02
Also published as: CN110392880A; WO2018132416A1; AU2018208489A1; EP3568752A1; US20180196666A1

Abstract

本開示の実現例は、仮想環境設計データのデプロイメントを容易にすることによって、環境をインスタンス化するアプリケーションのコードベースまたはコア処理機能全体を再デプロイする必要なく環境のユーザのために新たなエクスペリエンスを作成するためのコンピュータによって実行される方法、システムおよび物品に向けられる。一実施形態では、設計ツールは、仮想環境（オンラインマルチプレイヤゲームのための設定など）のための環境設計パラメータを受信し、仮想環境は、設計パラメータによって定義される要素と、一次関数コードベースとを含み、設計ツールはさらに、仮想環境のバージョンを作成し、各バージョンは、一次関数コードベースから独立した設計パラメータのサブセットを備える。バージョンは、仮想環境の１人以上のユーザに割り当てられ、一次関数コードベースの配信を必要とすることなく、ユーザに配信される。

Description

関連出願の相互参照
本願は、２０１８年１月１０日に出願された米国特許出願番号第１５／８６６，６８２号および２０１７年１月１１日に出願された米国仮特許出願番号第６２／４４４，９７９号に対する優先権を主張し、米国特許出願番号第１５／８６６，６８２号および米国仮特許出願番号第６２／４４４，９７９号は、全内容が引用によって本明細書に援用される。

背景
本開示は、仮想環境の設計および管理に関し、特に、設計データおよびパラメータを動的に設計して仮想環境にデプロイするためのシステムおよび方法に関する。

一般に、現実世界の環境をシミュレートするため、または、数十万人さらには数百万人ものプレイヤが互いに対話し、仮想環境とも対話するオンラインゲームに対して背景状況を提供するために、仮想世界が使用されてもよい。仮想環境は、屋外シーンおよび風景から建物および都市景観、家具、ツールまたは他の物体にいたるまでの無数のさまざまな「要素」または「もの」から成っていてもよい。これらの要素の各々は、独自のパラメータおよび特性を有していてもよく、これらのパラメータおよび特性は、総合して、仮想環境全体がどのようなものであるかおよび参加者が環境内の要素とどのように対話するかを定義する。

環境および要素に変化を生じさせるためには、これらのパラメータを更新して本番環境にデプロイしなければならない。これは、多数のユーザが環境と対話している場合には困難である可能性があり、更新はリアルタイムで行われなければならない。仮想環境内のユーザエクスペリエンスを妨害しないまたは損なわない態様でこのような更新をデプロイすることが望ましい。

概要
本明細書に記載されているシステムおよび方法の実現例を使用して、たとえばマルチプレイヤオンラインゲーム（たとえば、大規模マルチプレイヤオンラインゲームなど）を含む仮想環境において操作パラメータおよび設計データを管理することができる。設計データは、たとえば、オンラインゲームまたはオンラインゲームのための仮想環境と対話するための入力をユーザ（代替的に、本明細書では「プレイヤ」と称される）がクライアントデバイスに提供すると作成されるユーザイベントを含み得る。

仮想環境またはオンラインゲームでは、環境の各要素（「特徴」）は、参加者および他の特徴が当該特徴をどのように見て対話するかを定義するさまざまな値で構成され得る。これらの値の定義および調整は、ユーザエクスペリエンスおよび環境の全体範囲を形作る。たとえば、環境は、建物、自然の要素（たとえば、湖、山など）、乗り物および他の物体などの特徴を含んでもよい。各特徴は、そのサイズ、形状、機能および他のパラメータを定義する属性を含んでもよく、これらは「設計データ」と総称される。ユーザエクスペリエンスを妨害することなく頻繁に一貫して新たな特徴が導入される場合に、仮想環境およびオンラインゲームに対するユーザの関与およびロイヤルティは増加する。

したがって、これらの問題に対処しかつベースコードデプロイメントから切り離されたワークフロープロセスおよびアーキテクチャを利用する、これらの環境において設計データ（したがって、新たな特徴）を定義して実現するためのプロセスは、多大な価値をもたらすことができる。本明細書に記載されている技術および支援システムにより、仮想環境を実現するベースコードを再デプロイする必要なしに、特徴の迅速なデータ駆動型の開発が可能になる。これにより、設計チームは、常にオンデマンドベースで新たな特徴およびコンテンツのリリースを駆動することができるため、ユーザ関与が最大化され、設計データをアップロード、バージョン化、管理およびリリースするための設計データツールによって管理することができる既存の設計データの複数のライブバージョンが容易になる。

一局面において、本明細書に記載されている主題は、コンピュータによって実行される方法に関する。上記方法は、仮想環境（オンラインマルチプレイヤゲームのための設定など）のための複数の設計パラメータ（たとえば、新たな設計データおよび／または既存の設計データに対する変更を含んでもよい）を受信するステップを含み、上記仮想環境は、上記設計パラメータによって定義される要素と、一次関数コードベース（primary functional codebase）とを含み、上記方法はさらに、上記仮想環境のバージョンを作成するステップを含み、各バージョンは、上記一次関数コードベースから独立した上記設計パラメータのサブセットを備える。上記バージョンは、上記仮想環境の１人以上のユーザに割り当てられ、上記一次関数コードベースの配信を必要とすることなく、上記ユーザに配信される。

いくつかの実施形態では、上記バージョンの配信は、上記バージョンに関連付けられた上記ユーザからの要求に応答して、上記ユーザがクライアントデバイス上で上記仮想環境をインスタンス化したことに応答して、または場合によっては、いかなるユーザアクティビティもしくは動作からも独立して、起動されてもよい。いくつかの実現例では、上記ユーザの割り当てられたバージョンに従って各ユーザが上記仮想環境と対話するように、後続のバージョンが上記仮想環境の後続のユーザに割り当てられてもよい。いくつかの実施形態では、１つ以上のバージョンからさまざまなバリアントが作成されてもよい。バリアントは、たとえば特定の地理的領域に帰してもよく、そのため、上記地理的領域内の上記仮想環境のユーザは、上記地理的領域に関連付けられた上記バリアントを割り当てられる。場合によっては、バリアントは、一人のユーザに特有であってもよい。いくつかの実施形態では、１つ以上のリリースルール（たとえば、タイムスタンプ）が満たされたときにのみリリースが行われるように、バージョンは上記ルールに準拠するものとして指定されてもよい。場合によっては、新たなバージョンのために設計パラメータのサブセットを指定するだけでよいように、新たに作成されたバージョンは、既存のバージョンから設計パラメータを継承してもよい。特定の例では、上記バージョンを上記ユーザに配信するステップの前に、上記バージョンが前にリリースされたバージョンの設計パラメータと矛盾するか否かについて判断がなされ、このような矛盾が解決されたとして指定されるかまたは上記矛盾する設計パラメータが破棄されるまでは上記バージョンのリリースを認めない。

別の局面において、本明細書に記載されている主題は、システムに関する。上記システムは、動作を実行するようにプログラムされた１つ以上のコンピュータプロセッサを含み、上記動作は、仮想環境（オンラインマルチプレイヤゲームのための設定など）のための複数の設計パラメータ（たとえば、新たな設計データおよび／または既存の設計データに対する変更を含んでもよい）を受信するステップを備え、上記仮想環境は、上記設計パラメータによって定義される要素と、一次関数コードベースとを含み、上記動作はさらに、上記仮想環境のバージョンを作成するステップを備え、各バージョンは、上記一次関数コードベースから独立した上記設計パラメータのサブセットを備える。上記バージョンは、上記仮想環境の１人以上のユーザに割り当てられ、上記一次関数コードベースの配信を必要とすることなく、上記ユーザに配信される。

別の局面において、本明細書に記載されている主題は、システムに関する。上記システムは、動作を実行するようにプログラムされた１つ以上のコンピュータプロセッサを含み、上記動作は、データ設計ツール、バージョン化サービスおよび複数のコンテンツ配信ノードのインスタンス化を備える。上記データ設計ツールは、仮想環境（オンラインマルチプレイヤゲームなど）のための設計パラメータを含むユーザ入力を受信し、上記仮想環境は、上記設計パラメータによって定義される要素と、一次関数コードベースとを備える。上記バージョン化サービスは、上記仮想環境のバージョンの作成を容易にし、各バージョンは、上記一次関数コードベースから独立した上記設計パラメータのサブセットを備え、上記バージョン化サービスはさらに、上記仮想環境のユーザへの上記バージョンの割り当てを容易にする。上記コンテンツ配信ノードは、上記一次関数コードベースの配信を必要とすることなく、上記バージョンを上記仮想環境の上記ユーザに配信する。

いくつかの実施形態では、上記コンテンツ配信ノードによる上記バージョンの配信は、上記バージョンに関連付けられた上記ユーザからの要求に応答して、上記ユーザがクライアントデバイス上で上記仮想環境をインスタンス化したことに応答して、または場合によっては、いかなるユーザアクティビティもしくは動作からも独立して、起動されてもよい。いくつかの実現例では、上記バージョン化サービスは、上記ユーザの割り当てられたバージョンに従って各ユーザが上記仮想環境と対話するように、後続のバージョンを上記仮想環境の後続のユーザに割り当ててもよい。いくつかの実施形態では、上記バージョン化サービスは、上記バージョンからさまざまなバリアントを作成してもよい。バリアントは、たとえば特定の地理的領域に帰してもよく、そのため、上記地理的領域内の上記仮想環境のユーザは、上記地理的領域に関連付けられた上記バリアントを割り当てられる。場合によっては、バリアントは、一人のユーザに特有であってもよい。いくつかの実施形態では、１つ以上のリリースルール（たとえば、タイムスタンプ）が満たされたときにのみリリースが行われるように、バージョンは上記ルールに準拠するものとして指定されてもよい。場合によっては、新たなバージョンのために設計パラメータのサブセットを指定するだけでよいように、新たに作成されたバージョンは、既存のバージョンから設計パラメータを継承してもよい。特定の例では、上記バージョンを上記ユーザに配信する前に、上記バージョンが前にリリースされたバージョンの設計パラメータと矛盾するか否かについて判断がなされ、このような矛盾が解決されたとして指定されるかまたは上記矛盾する設計パラメータが破棄されるまでは上記バージョンのリリースを認めない。

別の局面において、本明細書に記載されている主題は、物品に関する。上記物品は、命令を格納した非一時的なコンピュータ読取可能媒体を備え、上記命令は、コンピュータプロセッサによって実行されると、上記コンピュータプロセッサに仮想環境のための複数の設計パラメータを受信させ、上記仮想環境は、上記設計パラメータによって定義される要素と、一次関数コードベースとを含む。また、上記命令の実行は、上記仮想環境のバージョンを作成し、各バージョンは、上記一次関数コードベースから独立した上記設計パラメータのサブセットを備え、上記命令の実行はさらに、上記バージョンを上記仮想環境のユーザに割り当て、上記一次関数コードベースの配信を必要とすることなく、上記バージョンを上記仮想環境の上記ユーザに配信する。

本発明の所与の局面に関して記載される実施形態の要素は、本発明の別の局面のさまざまな実施形態でも使用できる。たとえば、１つの独立請求項に従属する従属請求項の特徴は、他の独立請求項のうちのいずれかの装置、システムおよび／または方法でも使用できると考えられる。

本発明およびその付随する多くの利点は、以下の詳細な説明を添付図面と合わせて参照することによってよりよく理解されるので、そのより完全な理解は容易に得られるであろう。図中、同様の参照符号は、一般に、異なる図面全体にわたって同一の部分を指す。さらに、図面は、必ずしも一定の縮尺になっておらず、その代わりに、通常は本発明の原理を説明することに重点が置かれている。

本開示に係る仮想環境のための設計データを管理するためのシステムの一例の概略図である。本開示に係る仮想環境において設計データを定義して実現するさまざまな構成物を示す。本開示に係る仮想環境内で新たな特徴を実現するためのプロセスを示すフローチャートである。本開示に係る仮想環境内でバージョンおよび特徴を実現するための設計データを収集および管理するために使用され得る例示的なスプレッドシートセットである。本開示に係る仮想環境内でバージョンおよび特徴を実現するためのデータツールコンソールを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境のバージョンに特徴を割り当てるためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境のバージョンにホットフィックスを割り当てるためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境内でルールを作成および管理するためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境内でルールを作成および管理するためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境の局面を定義するために使用されるウィジェットを定義するためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境のバリアントを管理するためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境のバリアントに関連付けられたパラメータを編集するためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境に特徴をデプロイするためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境のバージョンのデプロイメントを管理するためのアプリケーションページを示す例示的なスクリーンキャプチャである。本開示に係る仮想環境に設計データをデプロイするためのプロセスを示すワークフローである。本開示に係る仮想環境に設計データをデプロイするためのアーキテクチャを示すワークフローである。本開示に係る仮想環境の新たなバージョンを作成および検証するためのプロセスを示すフローチャートである。本開示に係る仮想環境の新たなバリアントを作成および検証するためのプロセスを示すフローチャートである。本開示に係る仮想環境の新たなバージョンをデプロイするためのプロセスを示すフローチャートである。

詳細な説明
図１は、パラメータおよび仮想環境に関連する設計データおよび当該環境を構成する要素の作成、管理および配信を管理するためのシステム１００の一例を示す。本明細書で使用される仮想環境は、ユーザが建物、乗り物、バーチャルビーイング、武器、玩具などの仮想のアイテムおよび要素を見たり、対話したり、売買したり、使用したりする任意のオンライン環境であり得る。場合によっては、要素はルールに従って使用されて、ゲーム環境を作成し、当該ゲーム環境では、ユーザは互いに競争してアイテム、富、力などを蓄えていくことができる。本明細書に記載されている本発明の局面では、要素の表示および／または使用を定義するパラメータおよびデータは、仮想環境をインスタンス化する関数コードベースとは別に、作成、格納およびデプロイされてもよい。たとえば、環境の構造を作成するレベル、ロケールなどにかかわらず、全てのユーザに共通する関数コードセットが存在してもよいが、設計データは、要素を作成し、または要素の「詳細を補い」、ユーザベースにわたってカスタマイズ可能である。

一般におよび図１を参照して、システム１００は、設計データツール１０２および対応するデータツールデータベース１０４と、関連付けられた静的データサービス１０８およびバージョンデータベース１１０を有するバージョン化サービス１０６と、ＣＤＮ（コンテンツ配信ノード）１１２とを含む。いくつかの実施形態では、ＲＴＥ（リアルタイムイベント）通知サービス１１４は、システム１００のコンポーネント間でのリアルタイムまたは準リアルタイムメッセージング機能を提供する。ＲＴＥ通知サービス１１４のアーキテクチャの一例は、所有者が共通する米国特許出願番号第１５／４４２，０３６号に記載されている出版／購読サービス（「PubSub」）を備え、米国特許出願番号第１５／４４２，０３６号は、全開示内容が引用によって本明細書に援用される。仮想環境のバージョンのユーザは、１つ以上のクライアント１１６から環境にアクセスして環境と対話する。設計データツール１０２は、アプリケーションインターフェイスを提供し、このアプリケーションインターフェイスを介して、環境管理者および設計者は、仮想環境に関連する設計データをアップロード、整備およびデプロイすることができる。バージョン化サービス１０６は、アプリケーションプログラミングインターフェイスを提供し、このアプリケーションプログラミングインターフェイスを介して、データツールは、静的データをロードしてそこにとどまらせ、静的データサービス１０８は、適切なデータをＣＤＮ１１２に配信し、そこでデータはパッケージングされて、その後のクライアント１１６への配信のために格納される。

より具体的には、さまざまなコンポーネント間のデータ通信フローは、以下のように説明することができる。ユーザが設計データツール１０２に入力した設計データは、定期的にデータツールデータベース１０４にアップロードされて保存され、ユーザが新たな設計データを作成する際にデータツールデータベース１０４から取り込まれたり、改訂されたりすることができる。ユーザが設計データツール１０２を用いて設計データセットを完成させると（または、設計データセットの妥当性をチェックしたい場合）、設計データは、検証のために静的データサービス１０８に送信される。静的データサービス１０８において検証がなされると、当該設計データセットについてバージョン化およびリリースプロセスを開始してもよいことを示す応答が設計データツール１０２に送り返され、設計データセットについての更新ルールがバージョン化サービス１０６に送信される。次いで、新たに作成された設計データおよびその関連付けられた更新／リリースルールは、バージョンデータベース１１０に保存される。（すぐにまたは１つ以上のリリースルールに従って）バージョンが承認されてデプロイメントの準備が整うと、新たに作成されたバージョンは、ＣＤＮ１１２にデプロイされ、クライアント１１６へのデプロイメントに利用できるようにされる。たとえばＲＴＥ通知サービス１１４を介して、新たに作成されたバージョンをクライアント１１６に適切に通知することができる。クライアント１１６は、その後サービスにログインすると、現在のコアアプリケーションマニフェストと、特定のクライアント１１６のための新たな設計データを含むＣＤＮ１１２からの適切なデータパッケージとを提供される。代替的に、クライアント１１６がＲＴＥ通知サービス１１４から通知を受信したときに既にサービスにログインしている場合には、現在のコアアプリケーションマニフェストおよびＣＤＮ１１２からの適切なデータパッケージは、（自動的に）ダウンロードされるか、さもなければ背景の中のクライアント１１６に提供されてもよい。

図２は、システム１００を使用して設計およびデプロイされ得るさまざまなデータ分類を示す。設計データは、一般に、特徴２０４、ホットフィックス２０６またはバリアント２０８という３つの分類のうちの１つにグループ分けされてもよい。他の設計データ分類も可能である。これら３つの分類のいずれに入力されるデータも、新たな静的データ、既存の静的データに対する変更、またはそれら両方を含んでもよい。

システム１００が特徴のセットまたは特徴セットを中心に展開するので、特徴２０４は、データプログレッションにおける測定の原単位である。特徴２０４は、たとえば照合スプレッドシート、リスト、構造化ドキュメントまたは他のフォーマットを使用して設計データツール１０２に入力される設計データから成っていてもよい。場合によっては、特徴２０４は、専門の設計チームメンバによって作成および管理され、設計データツール１０２にアップロードされてもよく、データは、そこにとどまって、最終的にはデプロイされて静的データに変換される。いかなる数のペンディング特徴も設計データツール１０２において保持され管理されてもよく、デプロイされた特徴の全履歴が保持される。ホットフィックス２０６は、特徴設計データ（または、前のホットフィックス）に対する変更として扱われる。ホットフィックス２０６を適用する必要がある場合、設計データツール１０２におけるホットフィックス機能を介して必要な変更が収集されて適用される。場合によっては、設計データツール１０２は、関連する局面（他のペンディング特徴にホットフィックスを伝搬させることなど）を管理しながら、他のバージョン配信と比較して合理化されたホットフィックスワークフローを可能にする。これにより、起こり得る欠陥、バグ、または他の望ましくないが前に配信された設計データに対する迅速な応答が可能になる。

バリアント２０８は、それぞれの設計データがいつ適用されるかを規定する予め定義されたルールに結合されたスタンディングデータ置換定義（standing data replacement definitions）として使用される。場合によっては、バリアント２０８は、設計データツール１０２からデプロイされるあらゆる特徴２０４およびホットフィックス２０６に対して評価される。たとえば、要素として建物を含む仮想環境では、特定の建物は、特定のクライアント地理的領域（たとえば、特定の言語での広告板）においてさまざまな設計データを使用してもよく、当該領域では別の建物は利用不可であってもよい。このような区別は、バリアント２０８を対象の領域に制限するルールに結合されたバリアント２０８を使用して適用することができる。たとえば、要素として建物を含む仮想環境では、特定のクライアント地理的領域（翻訳されたテキストが内蔵された広告板など）においてさまざまなアセットを用いて特定の建物「建物Ａ」を描写することが望ましいであろう。同様に、別の特定の建物「建物Ｂ」を制限して当該領域では利用不可にすることが望ましいであろう。このような区別は、バリアント２０８を対象の領域に制限するルールに結合されたバリアント２０８を使用して適用することができる。上記の例では、「建物Ａ」は、そのアセット参照をバリアント２０８データと置換させ、「建物Ｂ」は、バリアント２０８データでは利用不可であるとしてフラグが立てられるであろう。新たな特徴２０４またはホットフィックス２０６がアップロードされるたびに、指定の設計データを使用して当該データセットの暗黙の代替バリアント２０８を作成することができる。

設計データツール１０２にアップロードされる全ての設計データは、バージョン化されて、ＣＤＮ１１２にデプロイされるまではもっぱら設計データツール１０２に存在することができる。特徴２０４およびホットフィックス２０６は、設計データツール１０２においてそれらのバージョン番号によって明示的に管理されることができ、バリアント２０８は、データ置換定義として設計データツール１０２に存在することができる。特徴２０４またはホットフィックス２０６がデプロイされると、既存のバリアント２０８のセットを使用して、設計データのベースセットに対して代替データセットを動的に生成することができる。

また、バリアント２０８は、設計データツール１０２において固有の名前／番号を割り当てられてもよい。たとえば、アップロードされた各特徴２０４は、新たな連続する主バージョン番号、たとえば１０５００、１０５０１、１０５０２など、を割り当てられ得る。アップロードされた各ホットフィックス２０６は、適用可能な主バージョン番号（すなわち、特徴２０４）に属する新たな連続する副バージョン番号を割り当てられ得る。たとえば、特徴１０５０２は、１０５０２．１、１０５０２．２および１０５０２．３などの３つの適用可能なホットフィックスを有してもよい。設計データツール１０２において定義される各バリアント２０８について、暗黙のデータ変化が、各々のデプロイされていない特徴２０４およびホットフィックス２０６に対して存在し得る。これらのバリアント２０８を使用して、バージョンデプロイメント中にデータ置換セットを生成してもよい。これらの変化は、適用されたルールセットに基づいて各々の特定のクライアント１１６についてさまざまな組み合わせでグループ分けされ得るので、バージョン番号付け規則に明示的に含まれていなくてもよい。

場合によっては、バージョン制御は、ステージ分けされたプロセスとして管理される。図３を参照して、各特徴２０４およびホットフィックス２０６は状態を割り当てられ、各状態は、ある状態から別の状態に移行するための対応するワークフローパラメータおよびルールセットを有する。一実施形態では、状態は、ペンディング（たとえば、データツールにアップロードされて動作を待っている）、デプロイ済み（たとえば、ＣＤＮ１１２に送信済み）、デプロイ済み−制限あり（たとえば、デプロイ済みであるが、１つ以上のルールまたはリリース日によって制約される）、矛盾している（たとえば、特定の特徴の新たな設計データと矛盾する伝搬ホットフィックス）および破棄済み（たとえば、廃棄された特徴またはホットフィックス）を含んでもよい。他の状態も可能である。

いくつかの実施形態では、ワークフロールールは、特徴２０４および／またはホットフィックス２０６がどのようにある状態から別の状態に移行するかを規定する。具体的には、最初に、特徴２０４およびホットフィックス２０６は全て、作成時に「ペンディング」の状態を付与されることができる。特徴２０４およびホットフィックス２０６は、ＣＤＮ１１２にデプロイされてクライアント１１６へのリリースに利用できるようになると、デプロイ済みの状態を付与される。これは、最終的な状態／ステータスである。なぜなら、特徴２０４またはホットフィックス２０６は、デプロイされると確定されたと考えられるからである。特徴２０４およびホットフィックス２０６は、ＣＤＮ１１２にデプロイされたが、付随するルールまたはリリースタイムスタンプが満たされるまでは特徴２０４およびホットフィックス２０６がクライアント１１６に送信されないようにルールまたはタイムスタンプを用いてそのようになされると、「デプロイ済み−制限あり」と見なされてもよい。ルールおよび／またはタイムスタンプが満たされると、特徴２０４またはホットフィックス２０６は、「デプロイ済み−制限あり」から「デプロイ済み」に移行してもよく、その時点で、全てのルールおよびタイムスタンプが除去される。

また、ホットフィックス２０６は、ホットフィックス２０６における設計データアイテムのうちの１つ以上が、ホットフィックス２０６をデプロイする対象であるターゲット特徴２０４におけるデータ変更と矛盾する場合に、ホットフィックス２０６が特徴２０４に伝搬されると、「矛盾している」と見なされてもよい。「矛盾している」と見なされると、ホットフィックス２０６はデプロイされない。矛盾が解消できると、ホットフィックス２０６はペンディング状態に移行することができる一方、そうでなければ、ホットフィックス２０６は破棄済みと見なされる。破棄済みと見なされるホットフィックス２０６は、廃棄されており、将来的なリリースについては無視される。また、ホットフィックス２０６を破棄済み状態に移行させることにより、他の特徴２０４に伝搬された当該ホットフィックス２０６の全てのペンディングインスタンスおよび矛盾しているインスタンスは破棄される。「デプロイ済み」のように、「破棄済み」は、最終的な状態であると考えられ、ホットフィックス２０６は、破棄されるとデプロイされない。

特徴設計データは、さまざまなアプリケーション、プログラミングインターフェイスおよび形式を使用して、さまざまな好適なフォーマットで、収集されて、データ設計ツール１０２に入力されてもよい。限定ではなく説明の目的で、図４に示される一組の実施形態では、スプレッドシートフォーマットを使用することができる。場合によっては、環境要素の特定のクラスのための設計データは、複数のスプレッドシートに散在してもよく、データが適用されている特定のクラスは、スプレッドシートファイルの第１のセルにおいて確認される。たとえば、建物に適用可能な設計データは、「建物データ」クラスに属していてもよく、単一のスプレッドシート４００が使用して、当該クラスのための設計データを含む各スプレッドシートファイルを一覧表示してもよい。そして、各々が「建物データ」クラスに属しているとされる下位スプレッドシート４０４ａおよび４０４ｂは、環境における建物データ要素のための特定の設計データを含んでもよく、この特定の設計データは、それがインスタンス化される環境のレベル、固有のアセット識別子、ユーザが要素を購入できるか否か、コスト、および建物データ要素に関連付けられた他のパラメータを含む。

特徴スプレッドシートのフルセットがバッチとしてロードされると、クラスに適用可能な全ての設計データは、次いで、各スプレッドシートにおいて指定されたクラスに基づいて照合されることができる。場合によっては、新たな特徴をアップロードする際に、設計データのうちの一部または全てが前のバージョン（デフォルトで、直近の特徴２０４およびホットフィックス２０６）から継承されてもよく、新たにアップロードされた特徴設計データが増加する、または当該データに上書きされる。ホットフィックス２０６設計データは、特徴２０４設計データと同様に集められてもよい。ホットフィックス２０６設計データは、既存の要素記録または追加される新たな記録の特定のデータフィールドに対する変更を含んでもよい。既存の記録を修正する際には、キーフィールドおよび修正すべきフィールドのみを入力する必要がある一方、変更されないフィールドは、空白のままであってもよく、または所望の変更がフィールドをクリアするものである場合には、「ヌル」文字列が当該フィールドに入力されてもよい。また、バリアント２０８設計データは、ホットフィックス２０６設計データの構築態様と同様のスプレッドシートフォーマットを使用して集められてもよい。たとえば、特定の建物アセットが特定の領域によって異なる場合、関連するスプレッドシート４０４ｃを使用して建物データに対するバリアントデータ入力を作成してもよく、ここでは、たとえばレベル１mage academyは、ベースライン「mage_academy_1」要素の代わりに、「jp_mage_academy_1」（たとえば、日本向け）アセットを使用する。

設計データツール１０２は、たとえば特徴管理、ホットフィックス管理、バリアント管理、アプリケーションデプロイメント管理、リリース管理、フル環境管理、および他の同様の機能などの機能を提供する。設計データツール１０２の特徴管理機能は、たとえば、特徴リスト／スプレッドシートを検証してフォーマットパラメータとの整合性を保証すること、スプレッドシート間の相違点を示すレポートを生成してある設計データセットから次の設計データセットへの変更を確認すること、特徴設計データセットを設計データツールにアップロードすること、場合によっては、デプロイされていない設計データのツール内編集、および他の同様の機能を含み得る。設計データツール１０２のホットフィックス管理機能は、たとえば、ホットフィックス設計データリスト／スプレッドシートを検証すること、相違点レポートを生成してホットフィックス変更を確認すること、ホットフィックスデータを設計データツールにアップロードすること、アップロードされたホットフィックスをペンディング特徴リリースに伝搬させること、ホットフィックス間の矛盾を管理すること、デプロイされていないホットフィックスデータのツール内編集、および他の同様の機能を含み得る。設計データツール１０２のバリアント管理機能は、たとえば、バリアント設計データを検証すること、相違点レポートを生成してバリアント変更を確認すること、バリアント設計データを新たなバリアントまたは既存のバリアントに対する修正としてデータツールにアップロードすること、バリアントデータのツール内編集、各バリアントを規定するルールを管理すること、および他の同様の機能を含み得る。

また、設計データツール１０２を使用して設計データのデプロイメントを管理してもよく、設計データのデプロイメントは、たとえば、ＣＤＮ１１２への本番データパッケージのデプロイメント、およびテスト用の他の非本番環境にデータをデプロイすることを含む。また、設計データツール１０２を使用してたとえばリリース管理を支援してもよく、リリース管理は、デフォルトリリースおよびタイムスタンプ／ルールベースのリリース、１つ以上の環境へのアプリケーション全体のフルデプロイメント、データのみのデプロイメント、ならびに他の同様の機能を含む。

図５〜図１３は、設計データを収集および管理するために使用され得る設計データツール１０２からのさまざまなスクリーンキャプチャを示す。アプリケーションのさまざまな実現例では、特に図５を参照して、設計データツールコンソール５００は、設計データのさまざまなバージョン５０８の各々がデプロイされたかまたはデプロイメントを待っている環境５０４を識別する。

図６は、特徴データリスト／スプレッドシートのアップロードを容易にする設計データツール１０２アプリケーションからのスクリーンキャプチャ６００の一例である。アップロードごとに新たな連続する主バージョン番号６０４を生成することができる。各々の新たな特徴２０４は、ベースラインとして最新の（たとえば、最上位にバージョン化された特徴２０４の最上位にバージョン化されたホットフィックス２０６までの）特徴／ホットフィックスバージョン６０８からデータを継承してもよく、説明６１２でタグ付けすることができる。「バリデート」関数は、選択されたスプレッドシートの全体的なデータ妥当性についてのレポート６１６を生成する。レポート６１６は、たとえば、第１のセルにおいて指定される状態データクラスの妥当性、スプレッドシート列／構造が定義されたスキーマに対応することの確認、フィールド入力のデータタイプの確認、重複する入力の除去またはフラグ立て、データモデルに定義された任意のカスタムデータ検証、および他の同様のレポートデータを含んでもよい。「ディフ」関数は、他のバージョンに対する選択されたスプレッドシートのデータ比較を可能にし、それによって、どの記録が追加または変更されているかを概説する。（バリデート関数による）構造的妥当性および（ディフ関数による）所望の変更が確認されると、スプレッドシートは設計データツール１０２にアップロードされる。

設計データツール１０２は、環境内の既存の設計要素に関連付けられたホットフィックス２０６データのアップロードも容易にする。図７は、設計データツール１０２内のホットフィックス管理画面のスクリーンキャプチャ７００の一例である。新たなホットフィックス２０６が入力されると、各ホットフィックス２０６について当該特徴２０４のもとで新たな連続する副バージョン番号７０４を生成することができる。ホットフィックス２０６は、ホットフィックス２０６が適用される特徴２０４（前のホットフィックス２０６を含む）から継承することができ（７０８）、同一の検証／ディフ／アップロード機能が適用される。また、ホットフィックス２０６は、既存の特徴２０４に自動的に順方向に伝搬してもよい。たとえば、特徴バージョン９０，９１，９２および９３が設計データツール１０２内に存在するとする。したがって、特徴９１は、既に適用された１つのホットフィックスを９１．１として有することができる。さらに、特徴９２は、既に適用された２つのホットフィックス（９２．１および９２．２）を有することができる。新たなホットフィックスが特徴９１に適用可能である。新たなホットフィックスバージョン番号は、９１．２であると考えられ、これは、二度持ち越されてホットフィックス９２．３および９３．１を作成することができる。この場合、ホットフィックス９１．２は、ルートホットフィックスであり、９２．３および９３．１は、ルートホットフィックス９１．２に基づいたさらなる変更を有するホットフィックスである。特徴管理セクションで説明した継承パターンのもとでホットフィックス２０６がホットフィックスデータを考慮に入れた後で、特徴２０４はアップロードされる。伝搬ホットフィックス２０６が作成されると、各々の順方向特徴２０４に対して矛盾検出が適用される。伝搬ホットフィックス２０６が、ルートホットフィックス２０６によって適用されるデータ変更とは異なるデータ変更を生じさせる場合、それらの行は、矛盾が生じているとして表示され得て、伝搬ホットフィックス２０６は、「矛盾」状態に入る。

限定ではなく説明の目的で、ルートホットフィックス９１．５が「mage_academy」行の「build_time」を６００から９００に変更すると、ルートホットフィックス９１．５は、特徴９２に伝搬されて伝搬ホットフィックス９２．１を作成する。しかし、特徴９２では、「mage_academy」の「build_time」は、１２００に設定されている。「build_time」は、ルートホットフィックス９１．５では６００から９００に変化するが、伝搬ホットフィックス９２．１では１２００から９００に変化するので、当該行は、矛盾が生じているとしてフラグが立てられ、伝搬ホットフィックス９２．１は、「矛盾」状態に入る。矛盾が生じている行は、所望のデータ変更を選択する（順方向特徴変更を保持する、またはそれに伝搬変更を上書きする）ことによって設計データツール１０２において解消されてもよい。伝搬ホットフィックス２０６における全ての矛盾が解消されると、「ペンディング」状態に戻る。新たなバージョンが矛盾したバージョンから継承する場合、矛盾は順方向に持ち越される。ルートホットフィックス２０６が破棄されると、依然としてペンディング状態にある全てのその伝搬ホットフィックス２０６も破棄され得る。

図８ａおよび図８ｂは、個々のルールがリスト８０４として追加されたり、修正されたり、検討されたりし得るルール管理画面８００、および、ルールに名前が付けられて（８１２）、特定のバリアント２０８に割り当てられ得るルール編集画面８０８の一例を示す。ルールは、好適なスクリプト言語（たとえば、Luaなど）を使用して、論理式および予め定義された選択を使用して、ウィジェットとして構築されてもよい。

図９は、より複雑なルールにおいて使用できるようにユーザがウィジェットを設計して挿入することができるウィジェット画面９００を示す。たとえば、結果として生じるルール９１２スニペットとともに公知のデータ要素９０４（たとえば、クライアント領域）およびブール演算子９０８を使用して、仮想環境のユーザが日本にいるか否かを調べるウィジェットが作成されてもよい。場合によっては、ルールスクリプトコードも手動で入力されてもよい。

ここで図１０を参照して、設計データツール１０２は、代替の静的データ変更を自動的に生成するために設計データツール１０２が使用することができるスタンディングデータ置換定義としてのデータバリアント２０８の作成および管理を容易にするバリアント管理画面１０００も含んでもよい。これらの変更は、上記のように、予め定義されたバリアントルールに基づいてクライアント１１６にデプロイされてもよい。特徴２０４およびホットフィックス２０６とは異なって、バリアント２０８は、データバージョン番号によって管理する必要はない。それどころか、バリアント２０８は、デプロイメント時にトリガされるスタンディングフックとして動作することができ、ＣＤＮ１１２にデプロイされる各々の特徴／ホットフィックスデータパッケージに対するデータ変更を生成する。クライアント１１６は、バージョン化サービス１０６を介してそのデータバージョンを確認すると、ベース特徴／ホットフィックスデータとともに、適用可能な変更の適切なサブセットを検索するように誘導され、置換物がクライアント１１６にデプロイされる。バリアント２０８データの各セットについてのメタデータ１００４は、たとえば、数値ＩＤ、アドミニストレータによって供給されるバリアント名、および当該バリアント２０８に結合されるルールセットを含み得る。他のメタデータも可能である。各バリアント２０８の数値ＩＤは、変更に矛盾が生じている場合には、その優先順位も表すことができる。複数のバリアント２０８が特定のクライアント１１６に適用され、それらのバリアント２０８が同一のデータフィールドを変更するであろう場合には、最下位の数値ＩＤを有するバリアント２０８が優先され得る。バリアント管理画面１０００は、リストを上または下にバリアント２０８を再順序付けする（１００８）（したがって、それらを新たなＩＤに再割り当てする）ことを可能にし、矛盾解消に対する制御を容易にすることができる。「ディフ」関数は、特定のバリアントまたはルールセットを適用してもしなくてもバージョン比較を可能にし、これにより、ユーザは、適用されているデータ変更を確認することができる。「エクスポート」関数は、選択されたバリアントのデータセットを外部ファイルに保存する機能とともに、当該データの閲覧を可能にする。「修正」関数は、（たとえば、スプレッドシートアップロードを使用して）バリアントの名前およびルールセットならびにバリアントデータ自体の編集を可能にする。

図１１は、特定のルール１１０８および対応する設計データファイル／スプレッドシート１１１２を有する、新たなバリアントが編集および／または作成されてバリアントＩＤ１１０４を割り当てられ得る設計データツール１０２のバリアント編集画面１１００の一例を示す。同様の検証／ディフ／アップロード機能も提供される。

また、設計データツール１０２は、ＣＤＮ１１２およびライブ配信のための仮想環境サーバへの、または場合によっては、選択された非本番開発もしくはテスト環境への、特定のデータバージョンのデプロイメントを管理する。いくつものリリースルールがデプロイメントに結合されてもよく、バリアントルールがバリアント２０８に適用されるのと同様に定義され、決定される。場合によっては、リリースタイムスタンプがデプロイメントに関連付けられてもよく、ルールとともに、データがクライアント１１６にデプロイされる時間および条件を定義してもよい。図１２は、特徴２０４およびホットフィックス２０６をデプロイするために使用される設計データツール１０２の特徴／ホットフィックスデプロイ画面１２００の一例を示す。この場合、画面１２００は、たとえば、特徴バージョン番号１２０４、それがデプロイされる環境１２０８、状態１２１２、および同一の環境への最近のデプロイメントの履歴１２１６を含み得る。

以下のステップは、本番（ライブ）環境にリリースをデプロイするためのプロセスの一例を概説する。まず、選択された特徴２０４またはホットフィックス２０６のためのベースデータがパッケージングされ、局所的にステージされる。次いで、各バリアントデータセットがパッケージングされ、一次データパッケージ下のサブフォルダにデプロイされ、これは、構文解析のためにクライアントが必要とするであろう、当該バリアント２０８に適用可能な優先順位メタデータを含む。次いで、ステージされたデータ（「フルデータパッケージ」）が、ＣＤＮ１１２にアップロードされ、バージョン番号によって索引付けされる。場合によっては、全ての現在のバリアント２０８のスナップショットが、履歴バリアントテーブルに保持され、特徴／ホットフィックスバージョン番号を使用してバージョン化されてもよく、これにより、時間とともにバリアント２０８が修正されるときに履歴的に見て正確なバリアントマッピングを保持することができる。次いで、本番環境サーバデータベースが、新たなバージョン化されたデータで更新され、特徴／ホットフィックスは、設計データツール１０２における「デプロイ済み」状態に入るか、または、リリースルールまたはタイムスタンプがデプロイメントに結合されている場合には「デプロイ済み−制限あり」状態に入る。新たにリリースされた設計データを受信するようにバージョン化サービス１０６に連絡するために、ＲＴＥブロードキャストが（適用可能であればリリースタイムスタンプに従ってスケジューリングされ、またはそうでなければすぐに）全てのクライアント１１６に送信される。フルデータパッケージをクライアント１１６上の適切なフォルダ構造に直接ダウンロードすることができ、次いで、クライアント１１６は、データパッケージを直接構文解析してロードする。

非本番環境へのデプロイメントでは、わずかに異なるワークフローが使用される。特徴／ホットフィックスデータおよびバリアントがフルデータパッケージに集められて局所的にステージされ、ライブデプロイメントに関して言えば、さらなるサーバデータパッケージが集められてステージされ、フルデータパッケージおよびサーバパッケージが所望の環境に配信されて、直接適切なフォルダ構造にされる。次いで、ローカルサーバデータベースが、テストインストール時に実行されるように構成されたサーバ負荷ＡＰＩを介して、適切なバージョン化されたデータで更新される。

図１３は、設計データツール１０２のリリース管理画面１３００を示す。この画面を使用して、特徴／ホットフィックスバージョンがクライアント１１６にリリースされ、事実上、「ライブ」であると考えられるデータバージョンを選択する。リリースを修正する際には、「デプロイ済み」状態の単一の特徴／ホットフィックスが一次リリースバージョンとして選択され、いくつもの「デプロイ済み−制限あり」デプロイメントバージョンも選択されてもよく、リリースおよびバージョンの階層１３０８の中に何があるかということの概要１３０４を提供する。これらは、優先順位ＩＤ１３１２（最後の「デプロイ済み」バージョン）を割り当てられ、バリアント２０８と同様に決定される。各バージョンについてのリリースルールおよびタイムスタンプは、順番に評価され、最下位のＩＤが優先される。データバージョンロールバックが必要であると考えられる場合には、前のバージョンが選択されてもよい。リリース管理画面１３００は、ユーザが本番および非本番環境のための接続情報およびメタデータを構成することを可能にする。

次いで、クライアント１１６は、ログイン時またはそのように促されるたびに、ＲＴＥブロードキャストを介して現在のデータバージョンを確認してもよい。これは、以下の態様で要求を処理するバージョン化サービス１０６に対する要求を介して行われる。まず、各リリースルールおよびタイムスタンプを評価して、要求を行っているクライアント１１６に適用可能なリリースバージョンを判断し、各バリアントルールを評価してその適用可能性を判断する。次いで、適切なデータパッケージ（ベースデータと、このクライアントに適用可能なそれらの特定のバリアントサブフォルダのみとを含む）を参照するマニフェストが生成され、クライアント１１６に送信される。各々のバージョン化サービス１０６応答は、適用可能なユーザメタデータとともにログ記録され、問題解決の目的でのクライアントのデータセット履歴へのバックトレースを可能にする。

図１４は、本発明の特定の実施形態に係る仮想環境のための設計データの設計およびデプロイメントのためのワークフローおよび役割／役目フローチャートの一例を示す。設計／ライブオペレーション（Ｏｐ）チーム１４００は、指定のスプレッドシートまたは他の好適な形式もしくはフォーマットでベースラインデータを集めて、ベースラインデータをベースラインデータアドミニストレータ（「ＢＤＡ」）１４０４に送信する。また、設計／ライブＯｐチーム１４００は、エクセルスプレッドシートまたは他の適切な形式でバリアントデータを集めて、バリアントデータをバリアントデータアドミニストレータ（「ＶＤＡ」）１４０８に送信する。ＢＤＡ１４０４は、設計データツール１０２を介してスプレッドシートをアップロードし、成功を確認またはエラーを分析して、必要に応じて設計データツール１０２からバージョン間差異を取得し、主バージョン間の変化を確認する。ＶＤＡ１４０８は、設計データツール１０２におけるバリアントルールセットを維持し、ルールセットを作成して適用可能なスプレッドシートをアップロードし、供給されたルールセットからバリアントバージョンを生成し、必要に応じて設計データツール１０２からバリアント間差異を取得し、バリアントによって適用される変化を確認し、正確さに関してデータバリアント矛盾を分析する。ライブデータアドミニストレータ（「ＬＤＡ」）１４１２は、データデプロイメントを連係し、ＢＤＡ１４０４およびＶＤＡ１４０８を用いてバージョンの準備完了を確認し、データパッケージをＣＤＮ１１２にデプロイする。

図１５は、本明細書に記載されている技術を実現するために使用され得るシステム１５００の一実施形態のより詳細な図である。図１を参照して説明したように、設計データツール１０２は、仮想環境をカスタマイズするために使用される設計データをユーザが入力、管理およびデプロイするためのウェブベースのアプリケーションとして実現されてもよい。集中型サーバ１５０４（または、場合によっては、サーバのアレイ）は、バージョン化サービス１０６をホストし、設計データツール１０２によって使用されるさまざまなデータを格納する。上記のように、設計／ライブオペレーションチーム１４００は、ベースラインデータ１５０８およびバリアントデータ１５１２とともに設計データツール１０２を使用して、バージョン化されたベースラインデータ１５１６および関連付けられたバリアントデータ１５２０のセットを作成し、このセットは、１つ以上のルール１５２４も含んでもよい。ベースラインデータ１５０８、バリアントデータ１５２０およびルール１５２４は、バージョン化サービス１０６によって結合されて、デプロイされたバージョン１５２８にされ、このデプロイされたバージョン１５２８の各々は、１つ以上のバリアント１５３２を有する。次いで、クライアント１１６は、（たとえば、１つ以上のクライアントパラメータまたは特徴に基づいて）ＣＤＮ１１２から特定のバージョンおよび適切なバリアントを検索することができ、バージョン化サービス１０６からバージョン確認情報を検索することもできる。

図１６は、後続のバージョンで使用され得るベースライン設計データセットを作成するための一般的なプロセスを示すフローチャートである。ステップ１６００において、設計チームのメンバは、指定のフォーマット（たとえば、スプレッドシートまたは他の好適なフォーマット）でベースライン設計データを集める。ベースライン設計データを含むスプレッドシートを検証のためにＢＤＡに送信し（ステップ１６０４）、ＢＤＡは、上記のバリデートおよびディフ関数を使用して、スプレッドシートが適切な形式であることを確認する（ステップ１６０８）。ベースライン設計データが適切にフォーマットされて確認されると（判断ステップ１６１２）、ベースライン設計データは、受け入れられて自動的にバージョン番号を割り当てられる（ステップ１６１６）。データは、検証ステップに合格しなければ、ベースライン設計データにおける問題を解決するために設計チームに戻される。

図１７は、バリアントデータを作成するためのプロセスを示すフローチャートである。ベースライン設計データ作成プロセスと同様に、ステップ１７００において、設計チームのメンバは、新たなバリアントのために指定のフォーマット（たとえば、スプレッドシートまたは他の好適なフォーマット）でバリアント設計データを集める。バリアント設計データを含むスプレッドシートを検証のためにＶＤＡに送信する（ステップ１７０４）。次いで、ＶＤＡは、新たなルールが新たなバリアントにおいて実行されているか否かを判断する（判断ステップ１７０８）。新たなルールが実行されている場合、当該新たなルールを作成する（ステップ１７１２）。いずれにしても、プロセスは、検証プロセスに進み、ＶＤＡは、上記のバリデートおよびディフ関数を使用して、スプレッドシートが適切な形式であることを確認する（ステップ１７１６）。バリアント設計データが適切にフォーマットされて確認されると（判断ステップ１７２０）、バリアント設計データがアップロードされ、新たなバリアントが作成される（ステップ１７２４）。データは、検証ステップに合格しなければ、バリアントがデプロイメントに向かっていくことができるように問題を解決するために設計チームに戻される。

図１８は、新たなバージョンを作成してデプロイするためのプロセスを示すフローチャートである。最初に、ＬＤＡは、ＢＤＡおよびＶＤＡと連係して（ステップ１８００）、バージョンをサポートするデータがデプロイできる状態にあることを確認する。次いで、ＬＤＡは、ベースラインバージョンと、当該バージョンを備えることになるバリアントのサブセットとを選択する（ステップ１８０４）。次いで、ＬＤＡは、選択されたバージョンおよび任意の関連付けられたバリアントをＣＤＡのためのデータパッケージにデプロイする（ステップ１８０８）。ベースラインバージョンは、デプロイ済みとして表示され（ステップ１８１２）、バリアントデータは、当該バージョンに適用されるものとして記録される（ステップ１８１６）。次いで、ＬＤＡは、新たにデプロイされた設計データパッケージを指し示すようにライブバージョンを更新し（ステップ１８２０）、クライアントに対するＲＴＥブロードキャストを開始し（ステップ１８２４）、次いで、クライアントによる設計データパッケージの検索を開始する（ステップ１８２８）。

ＢＤＡおよびＶＤＡチームが、コードベース全体の完全なリリースを必要とすることなく、新たなエクスペリエンスを作成し、前にリリースされたバージョンを修正または強化することができる設計データを作成してデプロイすることを可能にすることによって、新たなエクスペリエンスを、ほぼ連続的に、以前は許容されていなかった粒度のレベルで、ユーザに提供することができる。

本明細書に記載されている主題および動作の実現例は、デジタル電子回路で実現されてもよく、または本明細書に開示されている構造およびそれらの構造的等価物を含むコンピュータソフトウェア、ファームウェアもしくはハードウェアで実現されてもよく、またはそれらのうちの１つ以上の組み合わせで実現されてもよい。本明細書に記載されている主題の実現例は、データ処理装置による実行のために、またはデータ処理装置の動作を制御するためにコンピュータ記憶媒体上に符号化された１つ以上のコンピュータプログラム、すなわちコンピュータプログラム命令の１つ以上のモジュールとして実現されてもよい。代替的にまたは加えて、プログラム命令は、データ処理装置による実行のために好適な受信機装置に送信される情報を符号化するように生成される、人為的に生成された伝搬信号（たとえば、マシンによって生成された電気信号、光信号または電磁信号）上に符号化されてもよい。コンピュータ記憶媒体は、コンピュータ読取可能記憶装置、コンピュータ読取可能記憶基板、ランダムもしくはシリアルアクセスメモリアレイもしくはデバイス、またはそれらのうちの１つ以上の組み合わせであってもよく、またはそれらに含まれてもよい。さらに、コンピュータ記憶媒体は、伝搬信号ではないが、人為的に生成された伝搬信号に符号化されたコンピュータプログラム命令の送信元または宛先であってもよい。また、コンピュータ記憶媒体は、１つ以上の別々の物理的コンポーネントまたは媒体（たとえば、複数のＣＤ、ディスクまたは他の記憶装置）であってもよく、またはそれらに含まれてもよい。

本明細書に記載されている動作は、１つ以上のコンピュータ読取可能記憶装置に格納されるかまたは他のソースから受信されたデータに対してデータ処理装置によって実行される動作として実現されてもよい。

「データ処理装置」という用語は、データを処理するための全ての種類の装置、デバイスおよびマシンを包含し、一例として、プログラマブルプロセッサ、コンピュータ、システムオンチップ、または複数のこれら、または上記の組み合わせを含む。装置は、特殊用途論理回路（たとえば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路））を含んでもよい。また、装置は、ハードウェアに加えて、対象のコンピュータプログラムのための実行環境を作成するコード（たとえば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォームランタイム環境、バーチャルマシン、またはそれらのうちの１つ以上の組み合わせを構成するコード）を含んでもよい。装置および実行環境は、ウェブサービス、分散コンピューティングおよびグリッドコンピューティングインフラストラクチャなどのさまざまな異なるコンピューティングモデルインフラストラクチャを実現することができる。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプトまたはコードとしても知られている）は、コンパイラ型またはインタプリタ型言語、宣言型または手続き型言語を含む任意の形態のプログラミング言語で書き込まれてもよく、スタンドアロンプログラム、または、コンピューティング環境での使用に適したモジュール、コンポーネント、サブルーチン、オブジェクトもしくは他のユニットを含む任意の形態でデプロイされてもよい。コンピュータプログラムは、ファイルシステムにおけるファイルに対応してもよいが、対応していなくてもよい。プログラムは、他のプログラムもしくはデータ（たとえば、マークアップ言語ドキュメントに格納された１つ以上のスクリプト）を保持するファイルの一部に格納されてもよく、対象のプログラムに専用の単一のファイルに格納されてもよく、または複数の連係されたファイル（たとえば、１つ以上のモジュール、サブプログラムもしくはコードの部分を格納するファイル）に格納されてもよい。コンピュータプログラムは、１つのコンピュータ、または、一箇所に位置するかまたは複数の箇所に分散されて通信ネットワークによって相互接続される複数のコンピュータ上で実行されるようにデプロイされてもよい。

本明細書に記載されているプロセスおよび論理フローは、入力データで動作して出力を生成することによって動作を行うように１つ以上のコンピュータプログラムを実行する１つ以上のプログラマブルプロセッサによって実行されてもよい。また、プロセスおよび論理フローは、特殊用途論理回路（たとえば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路））によって実行されてもよく、装置も特殊用途論理回路（たとえば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路））として実現されてもよい。

コンピュータプログラムの実行に適したプロセッサは、一例として、汎用マイクロプロセッサおよび特殊用途マイクロプロセッサ、ならびにあらゆる種類のデジタルコンピュータの任意の１つ以上のプロセッサを含む。一般に、プロセッサは、リードオンリメモリまたはランダムアクセスメモリまたはそれら両方から命令およびデータを受信する。コンピュータの不可欠な要素は、命令に従って動作を実行するためのプロセッサと、命令およびデータを格納するための１つ以上のメモリデバイスとである。一般に、コンピュータは、データを格納するための１つ以上の大容量記憶装置（たとえば、磁気ディスク、光磁気ディスク、光ディスクもしくはソリッドステートドライブ）も含み、または１つ以上の大容量記憶装置からデータを受信したり、１つ以上の大容量記憶装置にデータを転送したり、１つ以上の大容量記憶装置に対してデータを受信および転送したりするように動作可能に結合される。しかし、コンピュータは、このような装置を有していなくてもよい。さらに、コンピュータは、別のデバイス（たとえば、ほんの数例を挙げると、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、携帯オーディオもしくはビデオプレーヤ、ゲーム機、グローバルポジショニングシステム（ＧＰＳ）受信機、または携帯型記憶装置（たとえば、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ））に組み込まれてもよい。コンピュータプログラム命令およびデータの格納に適したデバイスは、全ての形態の不揮発性メモリ、媒体およびメモリデバイスを含み、一例として、半導体メモリデバイス（たとえば、ＥＰＲＯＭ、ＥＥＰＲＯＭおよびフラッシュメモリデバイス）、磁気ディスク（たとえば、内部ハードディスクまたはリムーバブルディスク）、光磁気ディスク、ならびにＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクを含む。プロセッサおよびメモリは、特殊用途論理回路によって補完されてもよく、または特殊用途論理回路に組み入れられてもよい。

ユーザとの対話を提供するために、本明細書に記載されている主題の実現例は、ユーザに情報を表示するための表示装置（たとえば、ＣＲＴ（陰極線管）またはＬＣＤ（液晶ディスプレイ）モニタ）と、ユーザがコンピュータに入力を提供することができるキーボードおよびポインティングデバイス（たとえば、マウス、トラックボール、タッチパッドまたはスタイラス）とを有するコンピュータ上で実現されてもよい。ユーザとの対話を提供するために他の種類のデバイスが使用されてもよく、たとえば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック（たとえば、視覚フィードバック、聴覚フィードバックまたは触覚フィードバック）であってもよく、ユーザからの入力は、音響入力、音声入力または触覚入力を含む任意の形態で受信されてもよい。また、コンピュータは、ユーザが使用するデバイスにドキュメントを送信したり当該デバイスからドキュメントを受信したりすることによって、たとえばウェブブラウザから受信された要求に応答してユーザのクライアントデバイス上でウェブページをウェブブラウザに送信することによって、ユーザと対話してもよい。

本明細書に記載されている主題の実現例は、バックエンドコンポーネント（たとえば、データサーバ）を含むコンピューティングシステムで実現されてもよく、またはミドルウェアコンポーネント（たとえば、アプリケーションサーバ）を含むコンピューティングシステムで実現されてもよく、フロントエンドコンポーネント（たとえば、ユーザが本明細書に記載されている主題の実現例と対話することができるグラフィカルユーザインターフェイスまたはウェブブラウザを有するクライアントコンピュータ）を含むコンピューティングシステムで実現されてもよく、１つ以上のこのようなバックエンドコンポーネント、ミドルウェアコンポーネントまたはフロントエンドコンポーネントの任意の組み合わせを含むコンピューティングシステムで実現されてもよい。システムのコンポーネントは、デジタルデータ通信の任意の形態または媒体（たとえば、通信ネットワーク）によって相互接続されてもよい。通信ネットワークの例としては、ローカルエリアネットワーク（「ＬＡＮ」）およびワイドエリアネットワーク（「ＷＡＮ」）、インターネットワーク（たとえば、インターネット）、ならびにピア・トゥ・ピアネットワーク（たとえば、アドホックピア・トゥ・ピアネットワーク）が挙げられる。

コンピューティングシステムは、クライアントおよびサーバを含んでもよい。クライアントおよびサーバは、一般に互いに離れており、典型的には通信ネットワークを介して対話する。クライアントとサーバとの関係は、コンピュータプログラムがそれぞれのコンピュータ上で実行されて互いにクライアント・サーバ関係を有することによって生じる。いくつかの実現例では、サーバは、（たとえば、クライアントデバイスと対話するユーザに対してデータを表示して、ユーザからユーザ入力を受信する目的で）データ（たとえば、ＨＴＭＬページ）をクライアントデバイスに送信する。クライアントデバイスにおいて生成されたデータ（たとえば、ユーザ対話の結果）は、サーバにおけるクライアントデバイスから受信されてもよい。

本明細書は、多くの具体的な実現例の詳細を含んでいるが、これらは、いかなる発明またはクレームされ得るものの範囲も限定するものとして解釈されるべきではなく、むしろ特定の発明の特定の実現例に特有の特徴を説明するものとして解釈されるべきである。別々の実現例の文脈において本明細書に記載されている特定の特徴は、単一の実現例において組み合わせて実現されてもよい。逆に、単一の実現例の文脈において記載されているさまざまな特徴は、複数の実現例において別々に、または任意の好適なサブコンビネーションで実現されてもよい。さらに、特徴は、特定の組み合わせで動作するものとして上記され、最初はそのようにクレームされ得るが、クレームされている組み合わせからの１つ以上の特徴は、場合によっては当該組み合わせから削除されてもよく、クレームされている組み合わせは、サブコンビネーションまたはサブコンビネーションの変形例に向けられてもよい。

同様に、動作は特定の順序で図面に記載されているが、これは、このような動作が、望ましい結果を達成するために、示されている特定の順序またはシーケンシャルな順序で実行されなければならないものとして理解されるべきではなく、示されている全ての動作が実行されなければならないものとして理解されるべきでもない。特定の状況では、マルチタスクおよび並列処理が有利である場合もある。さらに、上記の実現例におけるさまざまなシステムコンポーネントの分離は、全ての実現例においてこのような分離が必要であるように理解されるべきではなく、記載されているプログラムコンポーネントおよびシステムは、一般に、単一のソフトウェア製品に統合されるか、または複数のソフトウェア製品にパッケージングされてもよいということが理解されるべきである。

このように、主題の特定の実現例について説明してきた。他の実現例も以下の特許請求の範囲の範囲内である。場合によっては、特許請求の範囲に記載されている動作は、異なる順序で実行されても依然として望ましい結果を達成することができる。また、添付の図面に記載されているプロセスは、望ましい結果を達成するために、示されている特定の順序またはシーケンシャルな順序を必ずしも必要としない。特定の実現例では、マルチタスクおよび並列処理が有利である場合もある。

Claims

方法であって、
仮想環境のための複数の設計パラメータを受信するステップを備え、前記仮想環境は、前記設計パラメータによって定義される要素と、一次関数コードベースとを備え、前記方法はさらに、
１つ以上のコンピュータプロセッサが、前記仮想環境の１つ以上のバージョンを作成するステップを備え、各バージョンは、前記一次関数コードベースから独立した前記設計パラメータのサブセットを備え、前記方法はさらに、
前記１つ以上のコンピュータプロセッサが、前記１つ以上のバージョンのうちの１つを前記仮想環境のユーザに割り当てるステップと、
前記一次関数コードベースの配信を必要とすることなく、前記１つ以上のバージョンのうちの前記１つを前記仮想環境の前記ユーザに配信するステップとを備える、方法。
前記１つ以上のバージョンの前記配信は、前記１つ以上のバージョンのうちの前記１つに関連付けられた前記ユーザからの要求に応答する、請求項１に記載の方法。
前記１つ以上のバージョンの前記配信は、前記ユーザがクライアントデバイス上で前記仮想環境をインスタンス化したことに応答する、請求項１に記載の方法。
前記仮想環境は、オンラインマルチプレイヤゲームのための設定を提供する、請求項１に記載の方法。
前記ユーザの割り当てられたバージョンに従って各ユーザが前記仮想環境と対話するように、前記１つ以上のバージョンのうちの後続のバージョンを前記仮想環境の後続のユーザに割り当てるステップをさらに備える、請求項１に記載の方法。
前記１つ以上のバージョンのうちの少なくとも１つは、前のバージョンから設計パラメータのサブセットを継承する、請求項１に記載の方法。
前記設計パラメータは、新たな設計データおよび既存の設計データに対する変更のうちの１つ以上を備える、請求項１に記載の方法。
各バージョンの１つ以上のバリアントを作成するステップをさらに備える、請求項１に記載の方法。
前記１つ以上のバージョンのうちの前記１つを前記仮想環境の前記ユーザに配信するステップの前に、１つ以上のリリースルールが満たされたときにのみリリースが行われるように前記１つ以上のバージョンのうちの前記１つを前記ルールに準拠するものとして指定するステップをさらに備える、請求項１に記載の方法。
前記１つ以上のバージョンのうちの前記１つを前記仮想環境の前記ユーザに配信するステップの前に、前記１つ以上のバージョンのうちの前記１つが前にリリースされたバージョンの設計パラメータと矛盾するか否かを判断し、このような矛盾が解決されたとして指定されるかまたは前記矛盾する設計パラメータが破棄されるまでは前記１つ以上のバージョンのうちの前記１つのリリースを認めないステップをさらに備える、請求項１に記載の方法。
システムであって、
動作を実行するようにプログラムされた１つ以上のコンピュータプロセッサを備え、前記動作は、
仮想環境のための複数の設計パラメータを受信するステップを備え、前記仮想環境は、前記設計パラメータによって定義される要素と、一次関数コードベースとを備え、前記動作はさらに、
１つ以上のコンピュータプロセッサが、前記仮想環境の１つ以上のバージョンを作成するステップを備え、各バージョンは、前記一次関数コードベースから独立した前記設計パラメータのサブセットを備え、前記動作はさらに、
前記１つ以上のコンピュータプロセッサが、前記１つ以上のバージョンのうちの１つを前記仮想環境のユーザに割り当てるステップと、
前記一次関数コードベースの配信を必要とすることなく、前記１つ以上のバージョンのうちの前記１つを前記仮想環境の前記ユーザに配信するステップとを備える、システム。
前記１つ以上のバージョンの前記配信は、前記１つ以上のバージョンのうちの前記１つに関連付けられた前記ユーザからの要求に応答する、請求項１１に記載のシステム。
前記１つ以上のバージョンの前記配信は、前記ユーザがクライアントデバイス上で前記仮想環境をインスタンス化したことに応答する、請求項１１に記載のシステム。
前記仮想環境は、オンラインマルチプレイヤゲームのための設定を提供する、請求項１１に記載のシステム。
前記ユーザの割り当てられたバージョンに従って各ユーザが前記仮想環境と対話するように、前記１つ以上のバージョンのうちの後続のバージョンを前記仮想環境の後続のユーザに割り当てるステップをさらに備える、請求項１１に記載のシステム。
前記１つ以上のバージョンのうちの少なくとも１つは、前のバージョンから設計パラメータのサブセットを継承する、請求項１１に記載のシステム。
前記設計パラメータは、新たな設計データおよび既存の設計データに対する変更のうちの１つ以上を備える、請求項１１に記載のシステム。
各バージョンの１つ以上のバリアントを作成するステップをさらに備える、請求項１１に記載のシステム。
前記１つ以上のバージョンのうちの前記１つを前記仮想環境の前記ユーザに配信するステップの前に、１つ以上のリリースルールが満たされたときにのみリリースが行われるように前記１つ以上のバージョンのうちの前記１つを前記ルールに準拠するものとして指定するステップをさらに備える、請求項１１に記載のシステム。
前記１つ以上のバージョンのうちの前記１つを前記仮想環境の前記ユーザに配信するステップの前に、前記１つ以上のバージョンのうちの前記１つが前にリリースされたバージョンの設計パラメータと矛盾するか否かを判断し、このような矛盾が解決されたとして指定されるかまたは前記矛盾する設計パラメータが破棄されるまでは前記１つ以上のバージョンのうちの前記１つのリリースを認めないステップをさらに備える、請求項１１に記載のシステム。
命令を格納した非一時的なコンピュータ読取可能媒体であって、前記命令は、１つ以上のコンピュータプロセッサによって実行されると、前記コンピュータプロセッサに、
仮想環境のための複数の設計パラメータを受信する動作を実行させ、前記仮想環境は、前記設計パラメータによって定義される要素と、一次関数コードベースとを備え、前記命令はさらに、前記コンピュータプロセッサによって実行されると、前記コンピュータプロセッサに、
前記仮想環境の１つ以上のバージョンを作成する動作を実行させ、各バージョンは、前記一次関数コードベースから独立した前記設計パラメータのサブセットを備え、前記命令はさらに、前記コンピュータプロセッサによって実行されると、前記コンピュータプロセッサに、
前記１つ以上のバージョンのうちの１つを前記仮想環境のユーザに割り当てる動作を実行させ、
前記一次関数コードベースの配信を必要とすることなく、前記１つ以上のバージョンのうちの前記１つを前記仮想環境の前記ユーザに配信する動作を実行させる、非一時的なコンピュータ読取可能媒体。