▶ クリック セラピューティクス インコーポレイテッドの特許一覧
特表2024-539548ユーザ関連条件に基づくアプリケーションにおける有限状態機械の適応的構成
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-10-29
(54)【発明の名称】ユーザ関連条件に基づくアプリケーションにおける有限状態機械の適応的構成
(51)【国際特許分類】
G06F 8/30 20180101AFI20241022BHJP
G06F 8/41 20180101ALI20241022BHJP
【ＦＩ】
G06F8/30
G06F8/41
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024517484
(86)(22)【出願日】2022-10-13
(85)【翻訳文提出日】2024-05-08
(86)【国際出願番号】 US2022046611
(87)【国際公開番号】W WO2023064495
(87)【国際公開日】2023-04-20
(31)【優先権主張番号】63/255,603
(32)【優先日】2021-10-14
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＳＷＩＦＴ
２．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】521455268
【氏名又は名称】クリック セラピューティクス インコーポレイテッド
【氏名又は名称原語表記】ＣＬＩＣＫ ＴＨＥＲＡＰＥＵＴＩＣＳ， ＩＮＣ．
(74)【代理人】
【識別番号】100147485
【弁理士】
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】230118913
【弁護士】
【氏名又は名称】杉村 光嗣
(74)【代理人】
【識別番号】100180655
【弁理士】
【氏名又は名称】鈴木 俊樹
(72)【発明者】
【氏名】チュアンハン チウ
(72)【発明者】
【氏名】リテシュ マンチャンダ
(72)【発明者】
【氏名】ディメトリウス ジョンソン
(72)【発明者】
【氏名】タイラー サージェント
(72)【発明者】
【氏名】ヘザー モリス
【テーマコード（参考）】
5B081
5B376
【Ｆターム（参考）】
5B081CC16
5B376BC57
5B376FA13
(57)【要約】
本明細書では、アプリケーション用に有限状態機械（ＦＳＭｓ）を構成するシステム及び方法を提示する。サーバは、アプリケーションの構成ファイルを特定することができる。構成ファイルは、条件に対処するための対応するルーチン用のＦＳＭを定義することができる。各ＦＳＭは複数の状態を特定し、各状態は個別のルーチンの出力を特定する。出力は、アプリケーションのユーザインタフェースのグラフィカル要素を特定する。各ＦＳＭは、複数の遷移を特定してもよく、各遷移は、ユーザインタフェースを介して検出されるイベントを特定する。イベントは、個別のルーチンに対してアプリケーションを介して実行されるアクションに対応してもよい。サーバは、構成ファイルを使用して、ＦＳＭを定義する命令を生成してもよい。サーバは、構成ファイルから生成された命令をアプリケーションに含めるために提供することができる。
【選択図】図１６
【選択図】図１６
【特許請求の範囲】
【請求項1】
アプリケーション用の有限状態機械（ＦＳＭｓ）を構成する方法であって、ユーザの状態に対処するためのそれぞれに対応する複数のルーチンのための複数のＦＳＭを定義する人間が読み取り可能な命令を含む、アプリケーションのための構成ファイルを少なくとも１つのサーバによって特定するステップであり、前記複数のＦＳＭｓの各ＦＳＭは、
（i）それぞれが前記アプリケーションを介して提供する出力を指定する、少なくとも第１状態及び第２状態を含む複数の状態、及び
（ii）複数の遷移であり、それぞれが前記第１状態から前記第２状態へ遷移するために前記アプリケーションを介して検出され、前記ルーチンのために前記アプリケーションを介して実行されるべきユーザアクションに対応する個別のイベントを指定する、該複数の遷移、
を特定するものである、該構成ファイルを特定するステップと、
前記少なくとも１つのサーバにより、前記構成ファイルの前記人間が読み取り可能な命令を使用して、前記複数のＦＳＭｓを定義する中間命令を生成するステップと、並びに
前記少なくとも１つのサーバにより、前記構成ファイルから生成された前記中間命令を前記アプリケーションに提供し、前記アプリケーションにより選択的に呼び出される前記複数のＦＳＭｓを定義する機械読み取り可能な命令を生成するステップと、
を備える、方法。
【請求項2】
請求項１に記載の方法において、前記複数のＦＳＭｓの少なくとも１つのＦＳＭにおける前記複数の遷移の各遷移は、前記アプリケーションのユーザインタフェース要素を介して検出される前記イベントを指定し、前記イベントは、前記個別のルーチンに対して実行される前記ユーザアクションに対応する、方法。
【請求項3】
請求項１に記載の方法において、前記複数のＦＳＭｓの第１ＦＳＭにおける前記複数の遷移のうちの少なくとも１つの遷移は、前記構成ファイルの前記人間が読み取り可能な命令によって定義された前記複数のＦＳＭｓの第２ＦＳＭを呼び出す前記イベントを指定する、方法。
【請求項4】
請求項１に記載の方法において、前記複数のＦＳＭｓのうちの少なくとも１つのＦＳＭにおける前記複数の状態のうちの少なくとも１つの状態は、前記アプリケーションを介して前記出力を提示するための１つ又は複数のユーザインタフェース要素を特定する、方法。
【請求項5】
請求項１に記載の方法において、前記構成ファイルを特定するステップは、さらに、開発アプリケーションを使用して生成された前記人間が読み取り可能な命令を含むスクリプトをコンピューティングデバイスから受信するステップを含む、方法。
【請求項6】
請求項１に記載の方法において、前記中間命令を生成するステップは、さらに、トランスパイラを使用して、ロード時に前記アプリケーションによってコンパイルされる前記中間命令を前記人間が読み取り可能な命令に変換するステップを含む、方法。
【請求項7】
請求項１に記載の方法において、前記中間命令を提供するステップは、さらに、クライアントデバイスにインストールされた前記アプリケーションによってロードされる前記中間命令を前記クライアントデバイスに送信するステップを含む、方法。
【請求項8】
請求項１に記載の方法であって、さらに、前記少なくとも１つのサーバによって、前記アプリケーションの前記ユーザの前記状態に対処するルーチンの要求に応答して、前記アプリケーションに提供する中間命令を選択するステップを備える、方法。
【請求項9】
請求項１に記載の方法であって、さらに、前記少なくとも１つのサーバによって、前記第１状態から前記第２状態に遷移する前記イベントの検出時に、前記アプリケーションが前記複数のＦＳＭｓのうちの第１ＦＳＭを呼び出すことに応答して、前記アプリケーションのユーザインタフェース要素を介して提示するためのコンテンツアイテムを送信するステップを備える、請求項１に記載の方法。
【請求項10】
請求項１に記載の方法であって、さらに、前記少なくとも１つのサーバによって、クライアントデバイス上の前記アプリケーションから、前記アプリケーションのユーザインタフェース要素を介して検出された前記イベントに関連する前記ユーザアクションを特定する記録エントリを受信するステップを備える、請求項１に記載の方法。
【請求項11】
アプリケーション用の有限状態機械（ＦＳＭｓ）を構成するためのシステムであって、メモリと結合された１つ又は複数のプロセッサを有する少なくとも１つのサーバを備え、この少なくとも１つのサーバは、
それぞれに対応する複数のルーチンのための複数のＦＳＭｓを定義する人間が読み取り可能な命令を含む、アプリケーションのための構成ファイルを特定するステップであり、前記複数のＦＳＭｓの各ＦＳＭは、
（i）それぞれが前記アプリケーションを介して提供する出力を指定する、少なくとも第１状態及び第２状態を含む複数の状態、及び
（ii）複数の遷移であり、それぞれが前記第１状態から前記第２状態へ遷移するために前記アプリケーションを介して検出され、前記ルーチンに対して前記アプリケーションを介して実行されるべきユーザアクションに対応する個別のイベントを指定する、該複数の遷移、
を特定するものである、該構成ファイルを特定するステップと、
前記構成ファイルの前記人間が読み取り可能な命令を使用して、前記複数のＦＳＭｓを定義する中間命令を生成するステップと、並びに
前記構成ファイルから生成された前記中間命令を前記アプリケーションに提供し、前記アプリケーションによって選択的に呼び出される前記複数のＦＳＭｓを定義する機械読み取り可能な命令を生成するステップと、
を行うよう構成される、システム。
【請求項12】
請求項１１に記載のシステムにおいて、前記複数のＦＳＭｓの少なくとも１つのＦＳＭにおける前記複数の遷移の各遷移は、前記アプリケーションのユーザインタフェース要素を介して検出される前記イベントを指定し、前記イベントは、前記個別のルーチンに対して実行される前記ユーザアクションに対応する、システム。
【請求項13】
請求項１１に記載のシステムにおいて、前記複数のＦＳＭｓの第１ＦＳＭにおける前記複数の遷移のうちの少なくとも１つの遷移は、前記構成ファイルの前記人間が読み取り可能な命令によって定義される前記複数のＦＳＭｓのうちの第２ＦＳＭを呼び出すための前記イベントを指定する、システム。
【請求項14】
請求項１１に記載のシステムにおいて、前記複数のＦＳＭｓの少なくとも１つのＦＳＭにおける前記複数の状態のうちの少なくとも１つの状態は、前記アプリケーションを介して前記出力を提示するための１つ又は複数のユーザインタフェース要素を特定する、システム。
【請求項15】
請求項１１に記載のシステムにおいて、前記少なくとも１つのサーバは、さらに、開発アプリケーションを使用して生成された前記人間が読み取り可能な命令を含むスクリプトをコンピューティングデバイスから受信するステップを行うように構成されている、システム。
【請求項16】
請求項１１に記載のシステムにおいて、前記少なくとも１つのサーバは、さらに、トランスパイラを使用して、前記人間が読み取り可能な命令を、ロード時に前記アプリケーションによってコンパイルされる前記中間命令に変換するステップを行うように構成されている、システム。
【請求項17】
請求項１１に記載のシステムにおいて、前記少なくとも１つのサーバは、さらに、クライアントデバイスにインストールされた前記アプリケーションによってロードされる前記中間命令を前記クライアントデバイスに送信するステップを行うように構成される、システム。
【請求項18】
請求項１１に記載のシステムにおいて、前記少なくとも１つのサーバは、さらに、前記アプリケーションの前記ユーザの前記状態に対処するためのルーチンの要求に応答して、前記アプリケーションに提供する前記中間命令を選択するステップを行うように構成される、システム。
【請求項19】
請求項１１に記載のシステムにおいて、前記少なくとも１つのサーバは、さらに、前記第１状態から前記第２状態に遷移する前記イベントの検出時に、前記アプリケーションが前記複数のＦＳＭｓのうちの第１ＦＳＭを呼び出すことに応答して、前記アプリケーションのユーザインタフェース要素を介して提示するためのコンテンツアイテムを送信するステップを行うように構成される、システム。
【請求項20】
請求項１１に記載のシステムにおいて、前記少なくとも１つのサーバは、さらに、クライアントデバイス上の前記アプリケーションから、前記アプリケーションのユーザインタフェース要素を介して検出された前記イベントに関連する前記ユーザアクションを特定する記録エントリを受信するステップを行うように構成される、システム。
【請求項21】
アプリケーション上で有限状態機械（ＦＳＭｓ）を取扱い処理する方法であって、クライアントデバイス上での実行時に、前記アプリケーションによって、ユーザの状態に対処するための複数のルーチンに対応する複数のＦＳＭｓを定義する機械読み取り可能な命令をロードするステップと、
前記アプリケーションによって、前記機械読み取り可能な命令によって定義された前記複数のＦＳＭｓを特定するステップであり、前記複数のＦＳＭｓの各ＦＳＭは、
（i）それぞれが前記アプリケーションを介して提供する出力を指定する、複数の状態における個別の第１状態、及び
（ii）個別の現在の状態からの複数の遷移であり、それぞれがそれに対応するＦＳＭを前記第１状態から第２状態に遷移させる前記アプリケーションを介して検出され、個別のルーチンのために前記アプリケーションを介して実行されるべきユーザアクションに対応する個別のイベントを指定する、該複数の遷移、
を特定するものである、該複数のＦＳＭｓを特定するステップと、
前記アプリケーションによって、前記複数のＦＳＭｓのＦＳＭで特定される複数の遷移の少なくとも１つによって指定される前記個別のイベントに対応する前記アプリケーションを介して実行される前記ユーザアクションを検出するステップと、並びに
前記アプリケーションによって、前記ユーザアクションの前記検出に応答して、前記第２状態によって得られる出力を提供するよう、前記ＦＳＭを前記個別の第１状態から前記第２状態に更新するステップと、
を備える、方法。
【請求項22】
請求項２１に記載の方法であって、さらに、前記アプリケーションによって、サーバから受信した前記複数のＦＳＭｓを定義する中間命令をコンパイルすることで、前記機械読み取り可能な命令を生成するステップを備える、方法。
【請求項23】
請求項２１に記載の方法であって、さらに、前記アプリケーションによって、対処すべき前記ユーザの前記状態に基づいてロードするように、対応する前記複数のルーチンのための前記機械読み取り可能な命令を特定するステップを備える、方法。
【請求項24】
請求項２１に記載の方法であって、さらに、前記アプリケーションによって、前記ユーザの前記状態に対処するための前記機械読み取り可能な命令を含む構成更新を受信したことに応答して、第２機械読み取り可能な命令を前記機械読み取り可能な命令に置き換えるステップを備える、方法。
【請求項25】
請求項２１に記載の方法であって、さらに、前記アプリケーションによって、前記アプリケーションのユーザインタフェース要素を介して検出された前記イベントに関連する前記ユーザアクションを特定する記録エントリをサーバに送信するステップを備える、方法。
【請求項26】
請求項２１に記載の方法において、前記検出するステップは、さらに、イベントバスを使用して、前記個別の現在の状態の前記複数の遷移のうちの少なくとも１つによって指定される前記個別のイベントに対応する前記ユーザアクションに応答する前記ＦＳＭの呼び出しを監視するステップを含む、方法。
【請求項27】
請求項２１に記載の方法において、前記更新するステップは、さらに、前記ＦＳＭの前記第２状態によって指定される前記出力に従って、前記アプリケーションのユーザインタフェース要素を介して提示するためのコンテンツアイテムをサーバから検索するステップを含む、方法。
【請求項28】
請求項２１に記載の方法において、前記更新するステップは、さらに、前記ＦＳＭの前記第２状態によって指定される前記出力に従って、前記アプリケーション上に１つ又は複数のユーザインタフェース要素を提示するステップを含む、方法。
【請求項29】
請求項２１に記載の方法において、前記複数のＦＳＭｓの少なくとも１つのＦＳＭにおける前記複数の遷移の各遷移は、前記アプリケーションのユーザインタフェース要素を介して検出される前記イベントを指定し、前記イベントは、前記個別のルーチンに対して実行されるべき前記ユーザアクションに対応する、方法。
【請求項30】
請求項２１に記載の方法において、前記複数のＦＳＭｓの第１ＦＳＭにおける前記複数の遷移のうちの少なくとも１つの遷移が、構成ファイルの前記機械読み取り可能な命令によって定義された前記複数のＦＳＭｓのうちの第２ＦＳＭを呼び出す前記イベントを指定する、方法。
【請求項31】
アプリケーション上で有限状態機械（ＦＳＭｓ）を取扱い処理するためのシステムであって、メモリと結合された１つ又は複数のプロセッサを有するクライアントデバイス上で実行可能なアプリケーションを備え、このアプリケーションは、
実行時に、ユーザの状態に対処するための複数のルーチンに対応する複数のＦＳＭｓを定義する機械読み取り可能な命令をロードするステップと、
前記機械読み取り可能な命令によって定義される複数のＦＳＭｓを特定するステップであり、前記複数のＦＳＭｓの各ＦＳＭは、
（i）それぞれが前記アプリケーションを介して提供する出力を指定する、複数の状態における個別の第１状態、及び
（ii）個別の現在の状態からの複数の遷移であり、前それぞれがそれに対応するＦＳＭを前記第１状態から第２状態に遷移させるためにアプリケーションを介して検出され、個別のルーチンのために前記アプリケーションを介して実行されるべきユーザアクションに対応する個別のイベントを指定する、該複数の遷移、
を特定するものである、該複数のＦＳＭｓを特定するステップと、
前記複数のＦＳＭｓのＦＳＭにおいて特定された前記複数の遷移のうちの少なくとも１つによって指定される前記個別のイベントに対応する前記アプリケーションを介して実行される前記ユーザアクションを検出するステップと、並びに
前記ユーザアクションの検出に応答して、前記第２状態によって得られる前記出力を提供するよう、前記ＦＳＭを前記個別の第１状態から前記第２状態に更新するステップと、
を行うよう構成される、システム。
【請求項32】
請求項３１に記載のシステムにおいて、前記アプリケーションは、さらに、サーバから受信した前記複数のＦＳＭｓを定義する中間命令をコンパイルすることにより、前記機械読み取り可能な命令を生成するステップを行うように構成されている、システム。
【請求項33】
請求項３１に記載のシステムにおいて、前記アプリケーションは、さらに、対処する前記ユーザの前記状態に基づいてロードする対応する複数の前記ルーチンのための前記機械読み取り可能な命令を特定するステップを行うように構成される、システム。
【請求項34】
請求項３１に記載のシステムにおいて、前記アプリケーションは、さらに、前記ユーザの前記状態に対処するための前記機械読み取り可能な命令を含む構成更新を受信したことに応答して、第２機械読み取り可能な命令を前記機械読み取り可能な命令に置き換えるステップを行うように構成される、システム。
【請求項35】
請求項３１に記載のシステムにおいて、前記アプリケーションは、さらに、前記アプリケーションのユーザインタフェース要素を介して検出された前記イベントに関連する前記ユーザアクションを特定する記録エントリをサーバに送信するステップを行うように構成される、システム。
【請求項36】
請求項３１に記載のシステムにおいて、前記アプリケーションは、さらに、イベントバスを使用して、前記個別の現在の状態の前記複数の遷移のうちの少なくとも１つによって指定される前記個別のイベントに対応する前記ユーザアクションに応答する前記ＦＳＭの呼び出しを監視するステップを行うように構成される、システム。
【請求項37】
請求項３１に記載のシステムにおいて、前記アプリケーションは、さらに、前記ＦＳＭの前記第２状態によって指定された前記出力に従って、前記アプリケーションのユーザインタフェース要素を介して提示するためのコンテンツアイテムをサーバから検索するステップを行うように構成される、システム。
【請求項38】
請求項３１に記載のシステムにおいて、前記アプリケーションは、さらに、前記ＦＳＭの前記第２状態によって指定される前記出力に従って、前記アプリケーション上に１つ又は複数のユーザインタフェース要素を提示するステップを行うように構成される、システム。
【請求項39】
請求項３１に記載のシステムにおいて、前記複数のＦＳＭｓのうち少なくとも１つのＦＳＭにおける前記複数の遷移の各遷移は、前記アプリケーションのユーザインタフェース要素を介して検出される前記イベントを指定し、前記イベントは、前記個別のルーチンに対して実行される前記ユーザアクションに対応する、システム。
【請求項40】
請求項３１に記載のシステムにおいて、前記複数のＦＳＭｓの第１ＦＳＭにおける前記複数の遷移のうち少なくとも１つの遷移は、構成ファイルの前記機械読み取り可能な命令によって定義された前記複数のＦＳＭｓのうちの第２ＦＳＭを呼び出す前記イベントを指定する、システム。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願）
本出願は、２０２１年１０月１４日に出願された「ユーザ関連条件に基づくアプリケーションにおける有限状態機械の適応的構成（Adaptive Configuration of Finite State Machines in Applications Based on User Related Conditions）」と題する米国仮特許出願第６３，２５５／６０３号の優先権を主張するものであり、この出願は、参照によりその全体が本明細書に組み込まれる。
本出願は、２０２１年１０月１４日に出願された「ユーザ関連条件に基づくアプリケーションにおける有限状態機械の適応的構成（Adaptive Configuration of Finite State Machines in Applications Based on User Related Conditions）」と題する米国仮特許出願第６３，２５５／６０３号の優先権を主張するものであり、この出願は、参照によりその全体が本明細書に組み込まれる。
【背景技術】
【0002】
コンピューティングデバイス上で実行されるアプリケーションは、表示のための様々な要素を含むユーザインタフェースを提供し得る。アプリケーションは、ユーザインタフェースの要素とのユーザインタラクションに応答ユーザインタフェースョンを実行するように構成し得る。
【発明の概要】
【0003】
本開示の態様は、アプリケーション用の有限状態機械（ＦＳＭｓ）を構成するシステム及び方法に向けられている。少なくとも１つのサーバは、アプリケーション用の構成ファイルを特定することができる。構成ファイルは、ユーザの状態に対処するために、対応する複数のルーチン用の複数のＦＳＭｓを定義する人間が読み取り可能な命令を含み得る。複数のＦＳＭｓの各々は、（i）少なくとも第１状態及び第２状態を含む複数の状態であって、各々の状態がアプリケーションを介して提供する出力を特定し得ること、（ii）複数の遷移であって、各々が第１状態から第２状態に遷移するためにアプリケーションを介して検出されるイベントを特定し得ること、を特定し得る。イベントは、個別のルーチンのアプリケーションを介して実行されるユーザアクションに対応し得る。少なくとも１つのサーバは、構成ファイルの人間が読み取り可能な命令を使用して、複数のＦＳＭｓを定義する中間命令を生成してもよい。少なくとも1つのサーバは、アプリケーションによって選択的に呼び出される複数のＦＳＭｓを定義する機械読み取り可能な命令を生成するために、構成ファイルから生成された中間命令をアプリケーションに提供してもよい。
【0004】
いくつかの実施形態では、複数のＦＳＭｓのうちの少なくとも1つのＦＳＭにおける複数の遷移の各遷移は、アプリケーションのユーザインタフェース要素を介して検出されるイベントを指定し得る。イベントは、個別のルーチンのために実行されるべきユーザアクションに対応してもよい。いくつかの実施形態において、複数のＦＳＭｓの第１ＦＳＭにおける複数の遷移のうち少なくとも1つの遷移は、構成ファイルの人間が読み取り可能な命令によって定義された複数のＦＳＭｓの第２ＦＳＭを呼び出すためのイベントを指定してもよい。いくつかの実施形態において、複数のＦＳＭｓのうち少なくとも1つのＦＳＭにおける複数の状態のうち少なくとも1つの状態は、アプリケーションを介して出力を提示するための１つ又は複数のユーザインタフェース要素を特定し得る。
【0005】
いくつかの実施形態では、少なくとも1つのサーバは、開発アプリケーションを使用して生成された人間が読み取り可能な命令を含むスクリプトを、コンピューティングデバイスから受信してもよい。いくつかの実施形態において、少なくとも1つのサーバは、トランスパイラを使用して、人間が読み取り可能な命令をロード時にアプリケーションによってコンパイルされる中間命令に変換し得る。いくつかの実施形態では、少なくとも1つのサーバは、クライアントデバイスに、クライアントデバイスにインストールされたアプリケーションによってロードされる中間命令を送信し得る。
【0006】
いくつかの実施形態において、少なくとも1つのサーバは、アプリケーションのユーザの状態に対処するルーチンの要求に応答して、アプリケーションに提供する中間命令を選択してもよい。いくつかの実施形態において、少なくとも1つのサーバは、第１状態から第２状態に遷移するイベントの検出時に、アプリケーションが複数のＦＳＭｓの第１ＦＳＭを呼び出すことに応答して、アプリケーションのユーザインタフェース要素を介して提示するためのコンテンツアイテムを送信してもよい。いくつかの実施形態において、少なくとも1つのサーバは、クライアントデバイス上のアプリケーションから、アプリケーションのユーザインタフェース要素を介して検出されたイベントに関連付けられたユーザアクションを特定する記録エントリを受信してもよい。
【0007】
本開示の態様は、アプリケーション上で有限状態機械（ＦＳＭｓ）を処理するシステム及び方法に向けられている。アプリケーションは、クライアントデバイス上での実行時に、ユーザの状態に対処するための複数のルーチンに対応する複数のＦＳＭｓを定義する機械読み取り可能な命令をロードし得る。アプリケーションは、機械読み取り可能な命令によって定義された複数のＦＳＭｓを特定してもよい。複数のＦＳＭｓの各ＦＳＭは、（i）それぞれがアプリケーションを介して提供する出力を指定する複数の状態における個別の第１状態、及び（ii）個別の現在の状態からの複数の遷移であって、複数の遷移の各遷移が、対応するＦＳＭを第１状態から第２状態に遷移させるためにアプリケーションを介して検出される個別のイベントを指定すること、を特定してもよい。個別のイベントは、個別のルーチンについてアプリケーションを介して実行されるユーザアクションに対応してもよい。アプリケーションは、複数のＦＳＭｓのＦＳＭにおいて特定される複数の遷移のうちの少なくとも１つによって指定される個別のイベントに対応するアプリケーションを介して実行されるユーザアクションを検出してもよい。アプリケーションは、ユーザアクションの検出に応答して、ＦＳＭを個別の第１状態から第２状態に更新し、第２状態によって得られる出力を提供し得る。
【0008】
いくつかの実施形態において、アプリケーションは、サーバから受信した複数のＦＳＭｓを定義する中間命令をコンパイルすることによって、機械読み取り可能な命令を生成してもよい。いくつかの実施形態において、アプリケーションは、対応する複数のルーチンのための機械読み取り可能な命令を、対処すべきユーザの状態に基づいてロードするように特定してもよい。
【0009】
いくつかの実施形態では、アプリケーションは、ユーザの状態に対処するための機械読み取り可能な命令を含む構成更新を受信することに応答して、第２機械読み取り可能な命令を機械読み取り可能な命令に置き換えてもよい。いくつかの実施形態では、アプリケーションは、アプリケーションのユーザインタフェース要素を介して検出されたイベントに関連するユーザアクションを特定する記録エントリをサーバに送信してもよい。
【0010】
いくつかの実施形態において、アプリケーションは、イベントバスを使用して、個別の現在の状態における複数の遷移のうち少なくとも１つによって指定される個別のイベントに対応するユーザアクションに応答するＦＳＭの呼び出しを監視してもよい。いくつかの実施形態では、アプリケーションは、ＦＳＭの第２状態によって指定された出力に従って、アプリケーションのユーザインタフェース要素を介して提示するためのコンテンツアイテムをサーバから検索し得る。いくつかの実施形態では、アプリケーションは、ＦＳＭの第２状態によって指定された出力に従って、アプリケーション上における１つ又は複数のユーザインタフェース要素を提示し得る。
【0011】
いくつかの実施形態では、複数のＦＳＭｓのうち少なくとも１つのＦＳＭにおける複数の遷移の各遷移は、アプリケーションのユーザインタフェース要素を介して検出されるイベントを指定し得る。イベントは、個別のルーチンのために実行されるべきユーザアクションに対応してもよい。いくつかの実施形態では、複数のＦＳＭｓの第１ＦＳＭにおける複数の遷移のうち少なくとも１つの遷移は、構成ファイルの機械読み取り可能な命令によって定義された複数のＦＳＭｓの第２ＦＳＭを呼び出すイベントを指定し得る。
【0012】
本開示の態様は、アプリケーション用の有限状態機械（ＦＳＭｓ）を構成するシステム及び方法に向けられている。少なくとも１のサーバは、アプリケーション用の構成ファイルを特定し得る。構成ファイルは、状態に対処するための対応する複数のルーチン用の複数のＦＳＭｓを定義し得る。複数のＦＳＭｓの各々は、少なくとも第１状態と第２状態を含む複数の状態を特定し、各状態は、複数のルーチンの個別のルーチンの出力を指定する。出力は、アプリケーションのユーザインタフェースのための１つ又は複数のグラフィカル要素を特定し得る。複数のＦＳＭｓの各々は、複数の遷移を特定し得、遷移の各々は、第１状態から第２状態に移行するためにアプリケーションのユーザインタフェースを介して検出されるイベントを指定する。イベントは、個別のルーチンに対してアプリケーションを介して実行されるアクションに対応し得る。少なくとも１つのサーバは、構成ファイルを使用して、アプリケーションによって選択的に呼び出される複数のＦＳＭｓを定義する機械読み取り可能な命令を生成してもよい。少なくとも１つのサーバは、構成ファイルから生成された機械読み取り可能な命令をアプリケーションに含めるように提供してもよい。
【0013】
いくつかの実施形態において、少なくとも１つのサーバは、ログ記録データベースに格納するために、複数の遷移のうち少なくとも１つの遷移によって指定されたイベントに対応するアクションに一致するアプリケーションのユーザインタフェース上で検出されたインタラクションに関連する記録エントリを受信してもよい。いくつかの実施形態において、少なくとも１つのサーバは、コンテンツの要求に応答して、アプリケーションのユーザインタフェース用の１つ又は複数のグラフィカル要素の１つとして提示するためのコンテンツアイテムをクライアントデバイスに提供し得る。
【0014】
本開示の態様は、アプリケーション上で有限状態機械（ＦＳＭｓ）を処理するシステム及び方法に向けられている。クライアントデバイスは、アプリケーションのための機械読み取り可能な命令によって定義された複数のＦＳＭｓを特定することができる。複数のＦＳＭｓは、条件に対処するための対応する複数のルーチン用のものであってもよい。複数のＦＳＭｓの各々は、少なくとも第１状態及び第２状態を含む複数の状態を特定し、各状態は、複数のルーチンにおける個別のルーチンに対する出力を指定し得る。出力は、アプリケーションのユーザインタフェースのための１つ又は複数のグラフィカル要素を特定し得る。複数のＦＳＭの各々は、複数の遷移を特定してもよく、遷移の各々は、第１状態から第２状態に移行するためにアプリケーションのユーザインタフェースを介して検出されるべきイベントを指定する。イベントは、個別のルーチンに対してアプリケーションを介して実行されるアクションに対応し得る。クライアントデバイスは、アプリケーションのユーザインタフェース上で検出されたインタラクションが、複数のＦＳＭｓのＦＳＭの少なくとも１つの遷移によって指定されたイベントに対応するアクションに一致すると判定し得る。クライアントデバイスは、判定に応答して、ＦＳＭを呼び出して、ＦＳＭの現在の状態を次の状態に更新し、次の状態に対する出力で特定された１つ又は複数のグラフィカル要素を提示するようにユーザインタフェースを修正し得る。
【0015】
いくつかの実施形態では、クライアントデバイスは、アプリケーションのための複数のＦＳＭｓにおける各ＦＳＭの現在の状態を維持し得る。現在の状態は、複数の遷移のうち１つ又は複数に関連付けられてもよい。いくつかの実施形態において、クライアントデバイスは、ログ記録データベースに格納するために、少なくとも１つの遷移によって指定されたイベントに対応するアクションに一致するアプリケーションのユーザインタフェース上で検出されたインタラクションに関連付けられた記録エントリを送信してもよい。
【図面の簡単な説明】
【0016】
本開示の上記及びその他の目的、態様、特徴、及び利点は、添付図面と併せて以下の説明を参照することにより、より明らかになり、より良く理解されるであろう。
【図1】例示的な実施形態による、プラグインを管理するためのシステムのアーキテクチャのブロック図を示す。
【図2】例示的な実施形態に従って、プラグインを管理するためのシステムで使用される有限状態機械（ＦＳＭ）を定義するためのユーザインタフェースのスクリーンショットを示す。
【図3】例示的な実施形態に従った、プラグインを管理するためのシステムにおけるイベントバスのアーキテクチャのブロック図を示す。
【図4】例示的な実施形態に従って、プラグインを管理するためのシステム内の複数の有限状態機械とインタフェースするイベントバスのブロック図を示す。
【図5】例示的な実施形態に従った、プラグインを管理するためのシステムにおけるスキルを解除するためのプロセスのフロー図を示す。
【図6】例示的な実施形態による、プラグインを管理するためのシステムのイベントバスにおけるイベント及び状態のシーケンスのブロック図を示す。
【図7】例示的な実施形態による、プラグイン用のレイアウトを管理するためのシステムのブロック図を示す。
【図8】例示的な実施形態に従った、プラグイン用のレイアウトを管理するためのシステムにおけるプラットフォームのブロック図を示す。
【図9】例示的な実施形態に従った、プラグインのレイアウトを管理するシステムにおけるユーザインタフェースのレンダリングを定義するためのツリーのブロック図を示す。
【図10】例示的な実施形態に従って、プラグインのレイアウトを管理するためのシステムによって使用される例示的なユーザインタフェースのブロック図を示す。
【図11】例示的な実施形態に従った、プラグイン内のレイアウトを管理するためのシステムにおける構成を解析するためのプロセスのフロー図を示す。
【図12】例示的な実施形態に従って、プラグインのレイアウトを管理するためのシステムによって生成される構成ツリーのブロック図を示す。
【図13】例示的な実施形態に従って、プラグインのレイアウトを管理するためのシステムによって生成されるツリー及びナビゲーション画面の例のブロックを示す。
【図14】例示的な実施形態に従って、プラグイン用のレイアウトを管理するためのシステムで使用されるテーマ構成のブロック図である。
【図15】例示的な実施形態に従った、プラグイン用のレイアウトを管理するためのシステムにおいて、優先度に従ってテーマをマージするためのプロセスのフロー図を示す。
【図16】例示的な実施形態による、アプリケーションに有限状態機械（ＦＳＭｓ）を提供するためのシステムのブロック図を示す。
【図17A】例示的な実施形態に従った、アプリケーションに有限状態機械（ＦＳＭｓ）を提供するためのシステムにおける命令を生成するためのプロセスのブロック図を示す。
【図17B】例示的な実施形態による、アプリケーションに有限状態機械（ＦＳＭｓ）を提供するためのシステムにおいて有限状態機械（ＦＳＭｓ）を処理するためのプロセスのブロック図を示す。
【図17C】例示的な実施形態に従った、アプリケーションに有限状態機械を提供するためのシステムにおけるユーザインタフェースを修正するためのプロセスのブロック図を示す。
【図18A】例示的な実施形態に従った、アプリケーション上で有限状態機械（ＦＳＭｓ）を構成する方法のフロー図を示す。
【図18B】例示的な実施形態に従った、アプリケーション上で有限状態機械（ＦＳＭｓ）を処理する方法のフロー図を示す。
【図19】例示的な実施形態に従った、サーバシステム及びクライアントコンピュータシステムのブロック図を示す。
【発明を実施するための形態】
【0017】
以下の様々な実施形態の説明を読む目的のために、本明細書のセクション及びそれらの個別内容の以下の列挙が役に立つであろう。
【0018】
セクションＡは、有限状態機械（ＦＳＭｓ）を実行するようにアプリケーションを構成するためのビヘイビアエンジン（behavior engine）のためのフロントエンドプラットフォーム及びアーキテクチャを説明する。
【0019】
セクションＢは、有限状態機械（ＦＳＭｓ）に従ってアプリケーションのユーザインタフェースを定義するためのレイアウトエンジンのためのフロントエンドプラットフォーム及びアーキテクチャを説明する。
【0020】
セクションＣは、有限状態機械（ＦＳＭｓ）上で有限状態機械を構成し、処理するシステム及び方法の実施形態を説明する。
【0021】
セクションＤは、本明細書で説明する実施形態を実践するのに有用なネットワーク及びコンピューティング環境を説明する。
【0022】
（Ａ．ビヘイビアエンジンのプラットフォームとアーキテクチャ）
レイアウトエンジンは、画面とコンテンツを構築するように構成され得るが、画面の単純なシーケンス以上のものは処理できない場合があり得る。これは、リッチコンテンツプラットフォームをサポートするには十分でない場合があり得る。例えば、フローにおいて、ユーザ入力に基づいて別のロジック分岐がある場合、レイアウトエンジンはこれを処理するように設計されていないおそれがある。別のシナリオとしては、アプリケーションがフローの途中でプッシュ通知を受信した場合、フローを中断するかどうかの判断がうまく定義されていないおそれがある。
レイアウトエンジンは、画面とコンテンツを構築するように構成され得るが、画面の単純なシーケンス以上のものは処理できない場合があり得る。これは、リッチコンテンツプラットフォームをサポートするには十分でない場合があり得る。例えば、フローにおいて、ユーザ入力に基づいて別のロジック分岐がある場合、レイアウトエンジンはこれを処理するように設計されていないおそれがある。別のシナリオとしては、アプリケーションがフローの途中でプッシュ通知を受信した場合、フローを中断するかどうかの判断がうまく定義されていないおそれがある。
【0023】
このような課題に対処するために、アプリケーションを実行するためのロジックは、臨床操作がアプリケーションにハードワイヤードされずにカスタマイズできるように、ドメイン固有の言語で定義し得る。特に、臨床操作がコンテンツだけでなく、コンテンツが提示されるロジックを制御できる場合には、アプリケーションの機能を制御する能力を提供し得る。
【0024】
（１．コンテキスト）
レイアウトエンジンは、ユーザインタフェース（ＵＩ）の設計及び配置をサポートし得る。これにより、非開発者（例えば、臨床医）が様々な臨床操作のためのコンテンツを構築することができる。レイアウトエンジンは、画面上のコンポーネントのレイアウトをサポートするだけでなく、ナビゲーションスタック（例えば、タブ、スタック及びモーダル）もサポートし得る。レイアウトエンジンは、例えば、次へ及び戻るが任意の補強なしの唯一の選択肢である画面のシーケンスなど、直線的なコンテンツのサポートに限定することができる。しかし、アプリケーションの操作には、複雑な分岐の決定、フローの中断及びユーザインタラクションが含まれ得る。これらの複雑さは、画面の流れの変更、エラー状態、ユーザインタフェースの表示を変更するためのアプリケーションプログラミングインタフェース（ＡＰＩ）呼び出しを伴い得る。
レイアウトエンジンは、ユーザインタフェース（ＵＩ）の設計及び配置をサポートし得る。これにより、非開発者（例えば、臨床医）が様々な臨床操作のためのコンテンツを構築することができる。レイアウトエンジンは、画面上のコンポーネントのレイアウトをサポートするだけでなく、ナビゲーションスタック（例えば、タブ、スタック及びモーダル）もサポートし得る。レイアウトエンジンは、例えば、次へ及び戻るが任意の補強なしの唯一の選択肢である画面のシーケンスなど、直線的なコンテンツのサポートに限定することができる。しかし、アプリケーションの操作には、複雑な分岐の決定、フローの中断及びユーザインタラクションが含まれ得る。これらの複雑さは、画面の流れの変更、エラー状態、ユーザインタフェースの表示を変更するためのアプリケーションプログラミングインタフェース（ＡＰＩ）呼び出しを伴い得る。
【0025】
このような問題を解決するために、カスタマイズされたロジック、状態機械又はビヘイビアツリーを定義するビヘイビアエンジンをレイアウトエンジンと一緒に追加して、並行して動作させ得る。ビヘイビアエンジンは、レイアウトエンジンを補強して、静的な線形シーケンスをサポートするだけでなく、分岐及びエラー処理を伴う動的なフローなど、より高機能なものにすることができる。つまり、ビヘイビアエンジンは、インタラクション、ロジック及び状態管理などをサポートすることができる。レイアウトエンジンがプレゼンテーションに重点を置く場合、ビヘイビアエンジンはアプリケーションのインタラクション及び状態を構成することができる。
【0026】
ビヘイビアエンジンは臨床操作によって設定可能である。例えば、コンテンツとセラピーは、過去と現在のデータを使って合理的な決定を下すことがすべてである。ユーザのデータがあれば、そのユーザにとってどのような治療の道のりになるかを設定し及びカスタマイズすることができる。ビヘイビアエンジンは社内開発にも役立ち得る。状態管理及び推論の多くが不具合又はバグの原因であるため、ビヘイビアエンジンを介して道のりを定義することで、アプリケーションの品質が向上する可能性がある。
【0027】
（２．目的）
アプリケーションが臨床操作によって設定可能である場合、アプリケーションは、より多様でインタラクティブなコンテンツを提供する能力を有し得る。例えば、ビヘイビアエンジンが治療日を追跡するように構成され、且つユーザがレッスンを完了していない場合、アプリケーションは、ビヘイビアエンジンによって、励ましの追加画面を表示するように構成されてもよい。
アプリケーションが臨床操作によって設定可能である場合、アプリケーションは、より多様でインタラクティブなコンテンツを提供する能力を有し得る。例えば、ビヘイビアエンジンが治療日を追跡するように構成され、且つユーザがレッスンを完了していない場合、アプリケーションは、ビヘイビアエンジンによって、励ましの追加画面を表示するように構成されてもよい。
【0028】
機能は、アプリケーションのレイアウト及びロジックを指定するための構成ファイルで定義され得る。コンテンツアセットは、コンテンツ管理システム（ＣＭＳ）上に存在し得る。ＣＭＳに依存して、構成ファイルは、アプリケーションのコンテンツ（ルックアンドフィールを含む）、フロー及びビヘイビアを提供するために定義される。アプリケーションはまた、起動シーケンス、フロー、単純な決定論的操作のような様々な操作のための起動ロジックも持ち得る。
【0029】
アプリケーションは、ゲームメカニクスロジックを実行するように構成することもできる。ビヘイビアエンジン及び構成ファイルは、ゲームメカニクス及びそれに付随する人工知能（ＡＩ）を実行するために使用され得る。このスキーマでは、セラピーはよりインタラクティブになり得る。ゲームメカニクスにより、アプリケーションによって提供されるセラピーは、人間のセラピストとのセッションをシミュレートすることができる。このようなセッションにおいて、セラピストは患者の状態に対応するために、戦略及び内容を動的にカスタマイズすることができる。さらに、治療による患者へのフィードバックがセッションに組み込まれることもある。
【0030】
構成にレイアウトされたトレーニングセッションは、ユーザが参加し、アプリケーションが適応的にユーザと対話する対話型ゲームになり得る。患者の状態に対処する能力は、アプリケーションが治療戦略を解決又は学習する方法を学習することによって向上し得る。ビヘイビアエンジンは、患者をテストし、且つ治療における最善の次のステップは何かを評価し得る。
【0031】
人間の脳の再配線に関する研究データを利用し、特定の障害に対して脳のどの部分が正しく働いていないかを特定するために、データを活用するように構成ファイルを設計することができる。ビヘイビアエンジンは、特定の障害と脳のどの部分をターゲットにする必要があるかについて、科学的に証明されたエクササイズのツールボックスを備えることができる。ビヘイビアエンジンは、一人ごとに治療をカスタマイズし、脳の関連部分をターゲットにするために使用できる。
【0032】
（３．ビヘイビアエンジンの仕様）
ビヘイビアエンジンは、アプリケーションコードにハードワイヤードされるのではなく、構成ファイル及びコンテンツ管理システム（ＣＭＳ）を使用してカスタマイズ可能であってもよい。構成ファイルによって、開発者でなくてもロジックを定義し得る。ビヘイビアエンジンはまた、直列化可能であってもよい。治療の過程で、ユーザがアプリケーションを終了しても、アプリケーションは経過を追跡し続けることができる。ビヘイビアエンジンは、直列化（シリアライズ）できない時間的値をサポートしてもよい。例えば、フローは、フローの存続期間中のみ、状態が追跡され続けるように指定することができる。ユーザインタフェースのテキストフィールドの値は、次のステップで使用され得る。状態は、セッション間で保存又はシリアライズ（直列化）されないかもしれない。
ビヘイビアエンジンは、アプリケーションコードにハードワイヤードされるのではなく、構成ファイル及びコンテンツ管理システム（ＣＭＳ）を使用してカスタマイズ可能であってもよい。構成ファイルによって、開発者でなくてもロジックを定義し得る。ビヘイビアエンジンはまた、直列化可能であってもよい。治療の過程で、ユーザがアプリケーションを終了しても、アプリケーションは経過を追跡し続けることができる。ビヘイビアエンジンは、直列化（シリアライズ）できない時間的値をサポートしてもよい。例えば、フローは、フローの存続期間中のみ、状態が追跡され続けるように指定することができる。ユーザインタフェースのテキストフィールドの値は、次のステップで使用され得る。状態は、セッション間で保存又はシリアライズ（直列化）されないかもしれない。
【0033】
ビヘイビアエンジンは、ビルディングブロックで構成可能であり得る。アプリケーションには、アプリケーションのさまざまな機能をすべて処理するための巨大なエンジンが一つ欠けている場合がある。例えば、リアクト（React）又はリーダックス（Redux）アプリケーションでは、すべてのアプリケーションロジックが１つの場所（例えば、リーダックス）にある可能性があり、アプリケーションはエラーが発生しやすく、且つ管理が困難になり得る。ビヘイビアエンジンは、複雑さを軽減するために使できる。コンポーザブルエンジンは、問題をサブ問題に分割することができる。各レッスンは個別の構成を持つことができる。共有された状態がサポートされることがあり、これは異なるレッスンが使用できる状態を公開する１つのレッスンによって実現し得る。
【0034】
各コンポーザブルユニットに対して、ビヘイビアエンジンはフローの複数のインスタンスをサポートすることができる。例えば、２０日目のレッスン（例えば、深呼吸）は、２１日目のレッスン（例えば、深呼吸）が矛盾しない状態になり得る。データは共有されてもよいが、分離がサポートされてもよい。ビヘイビア状態は分析のために解析され得る。例えば、バックエンドは、ビヘイビアの状態、履歴及び現在の状態の両方をキャプチャすることができ、分析は、ユーザがどのような状態にあるか、どのような状態にあったか及びその状態の詳細等を判断することができる。ビヘイビアエンジンは競合の解決を処理できるため、二つのデバイスが同期していない場合、これらのデバイスは新しい状態をサポートするために同期し得る。
【0035】
構成は任意のアプリケーションから独立しており、再利用し得る。レッスンの共有、ログインフロー及びその他の情報は、コピー又はペーストすることなく、異なるアプリケーション間で容易に共有することができる。このようにして、フローが表示され、且つビヘイビアエンジンから独立していてもよい。例えば、ビヘイビアは、着実に進む単純なウィザードだけのものであってもよい。構成ファイルによって定義されたレッスンは、進行状況を追跡することができる。ビヘイビアは、任意のレイアウトエンジン画面を駆動し得る。したがって、異なるコンテンツを持つ１０個のフローが、同じビヘイビア定義に依存し得る。
【0036】
ビヘイビアエンジンは、レイアウトエンジンからの外部イベント（例えば、ユーザインタラクション）だけでなく、プッシュ通知、バックエンドＡＰＩコール及びタイマーなどの外部イベントも受け入れ、且つ処理することができる。あるバージョンから別のバージョンへの移行状態がサポートされ得る（例えば、バージョン１からバージョン３へ）。新しいビヘイビアフローは、別のバージョン（例えば、バージョン１）で開始されたとしても、動作し続け得る。ビヘイビアエンジンはトリガーに依存してもよいし、外部コードを使用してもよい。例えば、ビヘイビアエンジンはＡＰＩコールを行ってデータを検索したり、或いはローカル通知をトリガーしたりすることができる。
【0037】
（４．ビヘイビアエンジンのアーキテクチャ）
ここで図１を参照すると、プラグインを管理するシステムのアーキテクチャのブロック図が描かれている。このアーキテクチャは、プラグインベースであってもよく、また時間の経過とともに拡張可能であってもよい。ビヘイビアエンジンは、メッセージの受け渡しことによってアプリケーションの残りの部分と通信することができる。メッセージの受け渡しは、リアクティブストリーム又はイベントバスを介して処理され得る。ビヘイビアエンジンは、エンジンインスタンス（例えば、有限状態機械（ＦＳＭ）のインスタンス）がシリアライズ及びデシリアライズされるように、ローカルストレージに直接アクセスすることができる。
ここで図１を参照すると、プラグインを管理するシステムのアーキテクチャのブロック図が描かれている。このアーキテクチャは、プラグインベースであってもよく、また時間の経過とともに拡張可能であってもよい。ビヘイビアエンジンは、メッセージの受け渡しことによってアプリケーションの残りの部分と通信することができる。メッセージの受け渡しは、リアクティブストリーム又はイベントバスを介して処理され得る。ビヘイビアエンジンは、エンジンインスタンス（例えば、有限状態機械（ＦＳＭ）のインスタンス）がシリアライズ及びデシリアライズされるように、ローカルストレージに直接アクセスすることができる。
【0038】
イベントバスは、ビヘイビアエンジンが、ローカルストレージを除くシステムの他の部分と通信するための主要な方法であり得る。これは、各プラグインがシリアライズ及びデシリアライズのコードを担当する可能性があるためである。ローカルストレージは、アプリケーションがデータをローカルに保存する方法であり得る。レイアウトエンジンはプレゼンテーションレイヤーを担当し得る。ビヘイビアエンジンはすべてのユーザインタラクションを認識し、また状態の変化に応じてプレゼンテーションを変更し得る。
【0039】
サービスはアプリケーションのアクティビティを実行する。アプリケーションは、プッシュ通知の受信、リマインダのスケジューリング、エラーの処理及びバックエンドＡＰＩの呼び出しなど、プレゼンテーションレイヤーの外部にロジックを持ち得る。ビヘイビアエンジンは、それらのイベントをリッスンする、又はアクティビティを実行するためにサービスをトリガーする方法を持ち得る。この通知及びトリガーはイベントバス上で行われる。
【0040】
例えば、アプリケーションは、ログイン又はサインアップのフローを管理するＦＳＭを持ち得る。フロー内で、ＦＳＭは分岐、ＡＰＩコール、トークンのメンテナンス、エラー処理、制御フロー、バインディング状態などを指定し得る。この例では、ＦＳＭの構成ファイルは新しいビヘイビア「開始」を定義し、またそのタイプは「ＦＳＭ」である。これは、構成をＦＳＭプラグインに渡し、プラグインが後でインスタンス化されるビヘイビアを作成する責任があることを示すように、ビヘイビアエンジンに信号を送ることができる。構成ファイルは、状態機械の開始状態が「ブート」であることを指定することもできる。次に、構成ファイルは、最終状態に移行する前に満たすべき２つの並列状態を特定することができる。
【0041】
２つのステップでは、バックエンドを呼び出して、（１）トークン内のアクティブなサインが有効であることを確認し、（２）バックエンドを呼び出して、ユーザに表示するリコール又はメッセージがあるかどうかを確認する。この呼び出しは、特に強制アップグレード及び重要なメッセージに関するものであり得る。これは、ＦＳＭが呼び出すことができるサービス又は外部操作であり、あらゆる種類のサービスを定義することができる。操作は、特にＵＲＬ及びタイムアウトなどの追加情報を含む入力をユーザに促すようなＡＰＩコールであってもよい。さらに、ＦＳＭは、完了（onDone）又はエラー発生（onError）など、すべての状態をカバーすることができる。完全な定義により、すべての状態を確実にカバーすることを保証し得る。例えば、図２に描かれているように、ビジュアルエディタを使用して、ＦＳＭの状態及び遷移を構築し得る。
【0042】
ビヘイビアエンジンはプラグインアーキテクチャを持つことがある。ＦＳＭプラグインは、設定可能な多くのプラグインのうちの１つであってもよい。上記の例に戻ると、ＦＳＭは、すべての状態の構成及び視覚化とともに構築することができる。ＦＳＭは入力及びいくつかの出力を持つことができる。入力は、ＦＳＭに新しい状態への遷移を要求するトリガーであり得る。この要求には、ペイロード又はデータを含めることができる。出力は、ＦＳＭが状態を変化させるときにトリガーされ得る。ＦＳＭは、ユーザ又は別のプロセスによってトリガーされる外部イベントを監視してもよい。ＦＳＭは、入力の結果を決定し得る。ＦＳＭは、次のステップ（又は状態）をペイロードとともに出力してもよい。
【0043】
ＦＳＭ及びアプリケーションの別の部分との間の結びつけるものは、イベントバスであってもよい。いくつかの実施形態では、イベントバスはリアクティブストリームであり、アプリケーション内の他のコンポーネントがバス上でリッスンし、パブリッシュすることを許可する。リアクティブストリームは、デバウンス、コンバイン、マップ、スケジューラなどのオペレータをサポートしてもよい。結局、レイアウトエンジン及び分析の２つのリスナーがある。どちらもバス上で双方向にメッセージを送受信できる。例えば、ビヘイビアエンジンを使ってアプリケーションを起動することについては、ＦＳＭはスプラッシュ画面を非表示にし、またログイン／サインアップフロー又はサインイン状態を表示することができる。これは、ＦＳＭが新しい画面／フローに移動するようにレイアウトエンジンに信号を送ることができるように、「アプリを開始」状態に動作又は呼び出しを追加することによって実行し得る。新しい画面を表示する命令とともに、ＦＳＭはペイロードを提供することができる。このペイロードには、表示画面を含めること、並びにタブナビゲータ及び３番目のタブの自動選択などの詳細を含めることができます。アプリケーションの起動が完了すると、アプリケーションのＦＳＭは、その状態になると「アプリを開始」と表示し、メッセージを表示（showMessage）、ホームへ（gotoHome）、未認証（unauthenticated）などの三つの条件をチェックし得る。次に、アプリケーションは、「ｃｏｎｄ」（条件付き）ロジックを使用して、ＦＳＭ内の正しい次の状態を自動的に選択する。ＦＳＭは、ｌａｙｏｕｔ．ｓｈｏｗＭｏｄａｌ又はｌａｙｏｕｔ．ｓｈｏｗＦｌｏｗの動作を実行することができる。これにより、ペイロードがバスに公開され得る。
【0044】
ここで図３を参照すると、プラグインを管理するためのシステムにおけるイベントバスのアーキテクチャのブロック図が描かれている。描かれているように、レイアウトエンジンはイベントをリッスンすることができる。そこで、モーダルを表示（showModal）又はフローを表示（showFlow）のＦＳＭペイロードが受信されることがある。このペイロードは、レイアウトエンジンに、画面及びフローの表示に関して何をすべきかを通知し得る。場合によっては、ペイロードの追加メタデータを使用して、追加の詳細を外部ソースに送信することができる。例えば、ディープリンクをサポートする場合、ＦＳＭはフローの途中でユーザを特定することができる。戻るボタンが正しく機能するように、履歴が再構成され得る。ビヘイビアエンジン及びレイアウトエンジンは、画面のフロー及び分岐を制御するために、互いにインタフェース接続することができる。
【0045】
（ａ．状態）
ビヘイビアエンジンは、状態を使用して、アプリケーションにおけるユーザの道のりを支援するインタラクティブロジックを定義するために使用することができる。状態は、ＦＳＭの現在の状態に対応し、またとりわけ変数、メタデータ及び履歴などを含むこともあり得る。ビヘイビアエンジンはこれをサポートし、また変更をブロードキャストすることができるため、任意のコンポーネントに内部詳細とともにステートの変更を通知することができる。
ビヘイビアエンジンは、状態を使用して、アプリケーションにおけるユーザの道のりを支援するインタラクティブロジックを定義するために使用することができる。状態は、ＦＳＭの現在の状態に対応し、またとりわけ変数、メタデータ及び履歴などを含むこともあり得る。ビヘイビアエンジンはこれをサポートし、また変更をブロードキャストすることができるため、任意のコンポーネントに内部詳細とともにステートの変更を通知することができる。
【0046】
ＦＳＭは、内部変数、メタデータ及び履歴を処理し、内部作業へのウィンドウを提供することもできる。このコンポーザブルな隔離されたボックス（カプセル化）により、ＵＩ及び他のＦＳＭをある種の状態から遠ざけることができる。アプリケーションはコンソール又はロジックを理解したりしないが、イベントを処理するためにＦＳＭを使ってイベントを発することができる。いくつかの実施形態では、リーダックスは、ＦＳＭを設定又は定義するために使用され得る。リーダックスは、構成ファイルを介して構成できない場合がある。ＦＳＭが現在の状態に基づいてどのようにイベントを処理するかは、リーダックスを使用しても変更されない場合がある。リーダックスは、グローバルな状態を有し、それ自体のインスタンスを有さない場合がある。
【0047】
ＦＳＭは、遷移の周りの状態及びメタデータの両方を保存することができる。しかし、アプリケーションは、ＦＳＭｓを使用してビヘイビアエンジンの外部で状態を追跡し得る。データは、ＦＳＭ及びビヘイビアエンジンに保存することもでき、或いはＦＳＭの外部に保存又は共有することもできる。そのため、アプリケーションはフック（hooks）、リーダックス、ＭｏｂＸなどを使うことができる。ＵＩはＦＳＭの状態にバインドすることもできるし、バスを使うこともできる。
【0048】
ビヘイビアエンジンは、プラグイン（ＦＳＭ）のインスタンスのシリアライズ又はデシリアライズをサポートしてもよい。このサポートにより、同じビヘイビア（ＦＳＭ）の複数のインスタンスを持つことができる。例えば、フローが日々チェックされる場合、毎日がインスタンスとなり、且つその状態値がローカルストレージに格納される。状態は、すべての生の状態データ、ＦＳＭが現在どの状態にあるか及びメタデータなどに加えて、人間が読むことができる。バックエンドは、データを読み取り、処理することができる。
【0049】
インスタンスをサポートするビヘイビアエンジンを持つことの利点の１つに、コンポーザブルなビルディングブロックが含まれ得る。各インスタンスは分離されたアトミックなもので、プライベートな状態を持ち、現在の状態を追跡することができる。インスタンスは、会話、共有及び一時的なＦＳＭのスピンアップなどの機能を持つことができる。サブモジュールが互いにメッセージを送信することで、システムをより理解し易くし、またコンポーザブルにすることができる。これらのビルディングブロックは、バスを介して接続することができる。
【0050】
ここで図４を参照すると、プラグインを管理するためのシステム内の複数の有限状態機械とインタフェース接続するイベントバスのブロック図が描かれている。ＦＳＭが状態を変更すると、ＦＳＭはその変更をアプリケーションにブロードキャストすることができる。リアクティブストリームを使用して、ストリーム、フィルタ、リシェイプ及びデバウンスなど、さまざまな機能を利用することができる。これにより、ユーザインタフェースは、ＦＳＭの任意のインスタンスに対する変更を受け取ることができ、ＦＳＭは他のＦＳＭをリッスンすることができる。例えば、ＵＩは治療の進行状況を表示するが、各治療は独自のＦＳＭを持ち得る。そのため、治療ＦＳＭは「患者のスコアは８０で、３／６のステップしか完了していません」とブロードキャストし、進行状況ＦＳＭはこれを受け取ってホーム画面のアニメーションを更新することができる。
【0051】
リアクティブストリームの利点の一つは、ＦＳＭが状態変化をブロードキャストしている場合、ストリームのコンシューマコンポーネントがパスに沿ってトランスフォーマにドロップできることである。そのため、データを送信するＦＳＭは、メッセージを処理するように設計されていないＦＳＭと通信できない場合がある。ＦＳＭｓと比較すると、リーダックスはリアクティブストリーム及び状態機械に付随する追加的なパワー及び利点に欠け得る。一方、ＦＳＭはコードなし又は少ないコードで構成できるため、グラフをより明示的にすることができる。例えば、リーダックスでは、アクションがディスパッチされ、リデューサーがグローバル状態を更新し得る。リーダックスでは、現在の状態にアクションを異なる方法で処理することはできず、すべてのアクションが同じように取扱い処理され得る。素朴な例としては、ＦＳＭで指定されたアクション「戻るボタン（BACK BUTTON）」と、現在の状態がログイン状態であった場合と、フローの別のステップであった場合がある。ＦＳＭはログイン状態を特定し、且つフローの１ステップに戻ることができる。リーダックスではこれをサポートするために、よりグローバルな状態が作成され、爆発的状態及び複雑な混合状態の問題に対処することができる。これはバグ及び予測不可能なビヘイビアにつながり得る。そのため、ＦＳＭｓで定義されるような明示的なステートは、安全で信頼性が高くなり得る。
【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】
（ａ．レイアウトエンジン）
レイアウトエンジンは、コンポーネントの配置及びスタイルを取扱い処理し、コンテンツ（例えば、テキスト、画像及びその他のオブジェクトなど）を管理し、とりわけナビゲーション、フラッシュメッセージ、キーボード回避（keyboard avoidance）、モーダル及びオーバーレイ、ディープリンク、ヘッダー並びにタブなどを制御することができる。これはプレゼンテーションレイヤーに対応する。レイアウトエンジンは、コードで開発されてもよいが、レイアウトエンジンによって構成可能なコンポーネントを活用してもよい。
レイアウトエンジンは、コンポーネントの配置及びスタイルを取扱い処理し、コンテンツ（例えば、テキスト、画像及びその他のオブジェクトなど）を管理し、とりわけナビゲーション、フラッシュメッセージ、キーボード回避（keyboard avoidance）、モーダル及びオーバーレイ、ディープリンク、ヘッダー並びにタブなどを制御することができる。これはプレゼンテーションレイヤーに対応する。レイアウトエンジンは、コードで開発されてもよいが、レイアウトエンジンによって構成可能なコンポーネントを活用してもよい。
【0081】
コンポーネントは、カプセル化され、またＵＩの構築にアトミックに影響を与えることができる。レイアウトエンジンは、複数のコンポーネントをネストすること及びコードコンポーネントが単独で実行できるような、コンポーネントを構築するための状態を管理する作業を行わないことがある。レイアウトエンジンは、コンポーネントからコンポーネントを構築することを意図していない場合がある。コンポーネントは、開発者でない人のためのもので、開発者がコードで行う構成ではなく、ドラッグアンドドロップを許可し得る。レイアウトエンジンは、レイアウトエンジンとの相互作用に対して、臨床製品、デザイン及び操作を考慮するように設計され得る。フロー又は共通グループをＣＭＳで定義することができ、またリアクトのような低レベルのコンポーネントはコードを使って開発することができる。例えば、開発者はリポジトリを使用し、コンポーネントを共有することで、ＣＭＳユーザがコンテンツのグループ化を構築するために使用できる優れたビルディングブロックを構築することができる。
【0082】
ここで図９を参照すると、プラグインのレイアウトを管理するシステムにおいてユーザインタフェースのレンダリングを定義するためのツリーのブロック図が描かれている。レイアウトエンジンはＹＡＭＬで構成することができる。ＹＡＭＬは、リアクトコンポーネントツリーに似たツリー構造の１対１のマッピングを可能にし得る。ＹＡＭＬは、リアクトネイティブツリーが表現できる任意のツリーを表現することができる。ＹＡＭＬは、ＪＳＸ（ＸＭＬ）又はＪＳＯＮ（コード）よりも人間が読みやすくなり得る。ツリーのノードの階層はＹＡＭＬファイルのインデントに対応する。リアクトコンポーネントのＹＡＭＬは、各ノードのプロパティを持つこともできる。これにより、各ノードを追加のプロパティでカスタマイズできる。さらに、ＹＡＭＬファイルは比較的簡潔で、人間が読める場合がある。
【0083】
モバイルアプリケーションの性質と限られた画面スペースを考えると、ほとんどの画面はいくつかの異なる方法で特徴付けることができる。コンポーネントの上から下へのリスト、タイルのグリッド、最小限のコンテンツを持つ単一画面、タブなど。例えば、コンポーネントは互いの上に積み重ねられてもよく、場合によってはアイテムのスタックにグリッドを使用してもよい。ボタンはほとんどの場合、ヘッダーと一緒に下部にある。これはＹＡＭＬファイルを使って定義できる。別の例として、スプラッシュ画面の例では、スタックに４つのコンポーネントがあり得る。それぞれのコンポーネントはプロパティがある。レイアウトエンジンはデフォルトのスタイルを挿入し、フレックスボックス（例えば、リアクトレイアウト構文）に依存せずにアイテムを積み重ねることができる。レイアウトエンジンが最適なパディング、色及びフォントサイズなどを決定するのに役立つテーマがサポートされ得る。レイアウトエンジンはまた、自動スクロール、フラッシュメッセージ及びモーダルなどのキーボードを意識したレイアウトを任意の画面に持つことができるように、ルールを適用し得る。これは、レイアウトエンジンが各画面の構築方法について一貫したアプローチを定義するためである。レイアウトエンジンがすべてのロジックをラップして処理できるため、各コンポーネントがキーボードを意識したレイアウトにどのように接続されているかを知る必要はない。
【0084】
ユーザビリティとアクセシビリティの仕様は、レイアウトエンジンの内部動作を定義することができる。ネイティブのリアクトコードでは、各画面は新しいコンポーネントとして定義される。例えば、１００の画面を持つアプリケーションは、小さなコンポーネントのグループを使用して大きなコンポーネントを形成する場合でも１００個の異なるレイアウトを持つことができる。単一のコンポーネントの小さな変更が何百もの異なるレイアウトにどのような影響を与えるか追跡する複雑さは困難である。レイアウトエンジンによって提供される定義は、単一の画面を持つことに似ている。レイアウトエンジンはその配置を処理し、各コンポーネントがキーボードを意識したレイアウトなどの機能と動作することを確認する。レイアウトエンジンはまた、アプリケーションのルックアンドフィールをより一貫したものにし得る。
【0085】
ここで図１０を参照すると、プラグインのレイアウトを管理するためにシステムによって使用されるユーザインタフェースの例のブロック図が描かれている。レイアウトエンジン内のコンポーネントは、ほとんど又は全くスタイリングを持たず、レイアウトエンジンに配置を処理させることができる。これは、描かれているように、ウェブグリッド又は列ベースのテンプレートに類似し得る。グリッドは、列数、ガター及びパディングなどのプロパティを定義することができる。このアプローチは、ＵＩの一貫性とバランスが最適であることを保証する。モバイル画面ではグリッドシステムではなく、ヘッダー付きのスタックであり、時にはタブビューにラップされることもある。描かれている例では、テキスト、タイル、ヘッダー及びボタンなどのコンポーネントをコンテナに配置することができる。この場合、コンテナは、画面、スクロールビュー、及びサブコンテナとすることができる。レイアウトエンジンは、各コンテナのパディング、マージン及び位置など、コンテナ及びコンテナ周辺のスタイルを制御することができる。
【0086】
リアクトアプリケーションでは、パディング、マージン、コンテナの位置は、アプリケーションの各画面又はページの画面コンポーネントで定義することができる。ドメイン固有言語（ＤＳＬ）スクリプトを使用することで、定義されたレイアウトは、各ページ及び個々のコンポーネントに対して新しいコードの作成に依存しなくなる。このコンポーネントとモジュール駆動のアプローチでは、アプリケーションコードベースのほとんどがコンポーネント構成と画面構成に存在するため、ゼロからコーディングすることなく機能を何度も再利用することができる。これにより、アプリケーションを毎回ゼロから構築するのとは対照的に、治療法を改善し、進化させることに集中できるようになるため、これは大きな勝利であり得る。
【0087】
グリッドシステムと同様に、スタイリングは親コンテナに依存することがあるので、レイアウトエンジンはこの種の情報を子コンポーネントに渡すことをサポートする必要がある。すべてをＤＳＬで持つことで、ツリーのクエリも可能になる。レイアウトエンジンは、スペーシング、フロート、コンテナ、ギャップスペーシング、アライメント、ネスト及びスクロールなどの機能もサポートする。レイアウトエンジンは、可視性、一部のアニメーション、アクセシビリティの認識、方向、キーボード回避も扱うことができる。
【0088】
例えば、ＹＡＭＬ構成ファイルでは、最初にルートノードがタイプナビゲーションになる。これを読んだレイアウトエンジンは、フローの一部である画面のリストを特定するナビゲーションスタックを作成する。ルートノードには、スタック内のスクリーンのリストを定義する「ｓｃｒｅｅｎ：ｐｒｏｐｅｒｔｙ」もある。新しい画面は、レイアウトエンジンがヘッダーを非表示にすることを示す「ｉｄ：ｓｐｌａｓｈ－ｓｃｒｅｅｎ」フィールドで作成することができる。スクリーン上のコンテンツが大きすぎる場合はスクロールできるようにする必要がある。レイアウトエンジンは、入力タイプのすべての子ノードを見て、キーボードを意識したレイアウトに合わせて特別なレイアウトを構築するかどうかを決定できる。それから、画面は、上から下へとレンダリングするコンポーネントのリストを持つ「ｌａｙｏｕｔ：ｐｒｏｐｅｒｔｙ」を持ち得る。残りはテキストで、次はブロックであり得る。ブロックは、画面の下部に固定されたフローティングボックスを作成するようレイアウトエンジンに指示できる。
【0089】
ここで図１１を参照すると、プラグインでレイアウトを管理するためのシステムで構成を解析するプロセスのフロー図が描かれている。最初に、レイアウトエンジンはメトロバンドラープラグインを介してＹＡＭＬファイルを読み込むことができる。ＹＡＭＬがネイティブのレイアウトエンジンフォーマットではなく、ＪＳＯＮがネイティブのレイアウトエンジンフォーマットである場合、このプラグインはＹＡＭＬファイルを中間フォーマット（例えば、ＪＳＯＮ）に変換する。例えば、多くのＣＭＳはＪＳＯＮ又はＪＳＯＮに変換されるＹＡＭＬ（又は別のタイプのＤＳＬ）を出力する。第２に、ＪＳＯＮファイルはＪＳＯＮツリーの異なる部分を参照するために、参照又はインポート（＄ｒｅｆ、＄ｉｄ）のためにスキャンされる。ＪＳＯＮツリーの部分は、構成ファイルの任意の部分をコピーすることなく再利用することができる。これにより、ＪＳＯＮのブロックの再利用が容易になる。
【0090】
第３に、パーサ（parser）は、各ＪＳＯＮノードをリアクトレンダツリーに変換するツリーを走査する再帰関数であってもよい。パーサは、ＪＳＯＮのタイプフィールドを使用して、どのサブパーサ関数が変換を処理すべきかを決定することができる。例えば、「ｔｙｐｅ＝ｔｅｘｔ」は、そのノードとサブノードを処理するようにテキストパーサ関数に信号を送ることができる。第４に、各サブパーサはまた、検証ポリシーを定義することができ、さらなる処理のためにパーサに関数を渡す前にスキーマを検証することができる。この検証は、例えばＴｙｐｅＳｃｒｉｐｔのタイプデフファイルである。解析されたノードは、ドキュメントの自動生成及び型規則の適用に使用される。レイアウトは、数値範囲及び条件などの実行時の検証を処理することができる。ａｊｖを使用して検証を実行できます。ネイティブＪＳＯＮはバリデーターとして使用でき、またカスタム関数をサポートするために使用できる。
【0091】
第５に、各サブパーサは各ノードをリアクトコンポーネントに変換できる。各サブパーサはメインパーサによって解析される子ノードを再帰的に渡すか、或いは子構成を使用できる。ほとんどの場合、ＹＡＭＬツリーはリアクトレンダツリーをミラーリングする。最後に、設定ツリーをたどった後、パーサはリアクトツリーを取得することができる。システムはＤＳＬを動的にするために柔軟に設計され、ツリーの各ノードはサブパーサ又は関数によって処理される。これにより、メインパーサを書き換えることなく、ＤＳＬに新しいセマンティクスを追加できる。
【0092】
ここで図１２を参照すると、プラグインのレイアウトを管理するシステムによって生成される構成ツリーのブロック図が描かれている。ツリーをたどることに加えて、パーサは各ステップで追加の文脈を送信することができる。この情報により、親ノードは情報を下に渡したり、サブノードから情報を受け取ったりすることができる。これらは、各ノードのパスに対する名前空間の情報が含まれる。親ノードがＹＡＭＬキー又は値から、任意のキー又は値を上書きすること、或いはキー又は値をデフォルト値で補完することを許可するハードオーバーライド、ＹＡＭＬキー又は値が親の値をデフォルト値と同様に上書きするソフトオーバーライドである。ツリーをたどるとき、ハードオーバーライドとソフトオーバーライドを渡すことができる。ソフトデフォルトを渡すと、ＹＡＭＬの特定の値又はプロパティが省略できる。ハードオーバーライドを渡すと、親ノードがＹＡＭＬファイルの値を強制的に上書きできる。例えば、グリッドレイアウトのパディング／マージンでは、グリッドレイアウトコンポーネントが有用なデータにアクセスできるように、オーバーライドはツリーの上下にデータを渡すことができる。
【0093】
アプリケーションの任意の部分で、パーサを登録することができる。パーサはＤＳＬ構成値を検証するために使用される解析関数、スキーマ定義を指定できる。上の例では、レイアウトエンジンに登録されたテキストとブロックのサブパーサがある。例えば、テキストサブパーサは次のものを含む。まず、ｓｃｈｅｍｅ．ｙｍｌを含む。これはａｊｖ検証ルールを定義する。このファイルでは、必須フィールドは「ｖａｌｕｅｄ」であり、プロパティフィールドにはｓｔｙｌｅ、ｖａｌｕｅ、ｍａｒｋｄｏｗｎＳｔｙｌｅｓ、ｖａｒｉａｎｔが含まれる。フィールド「＄ｒｅｆ：ｃｏｍｍｏｎ／ｓｔｙｌｅ」を参照すると、グローバルタイプはコピー又はペーストなしでインポートとして定義できる。１番上のフィールドはテキストで、ＹＡＭＬファイルをトラバースするときに使われる。ｔｙｐｅ：ｔｅｘｔが見つかると、このサブパーサが使われる。２番目は後述するｔｈｅｍｅ．ｙｍｌである。３番目はＴｅｘｔ．ｊｓである。このファイルはレイアウトエンジンに依存しないリアクトコンポーネントを含み、分離された状態を持つ機能的なコンポーネントであり得る。４番目はＩｎｄｅｘ．ｊｓである。これはサブパーサをレイアウトエンジンに登録する。５番目はリアクトコンポーネントとＹＡＭＬ生成バージョンをテストするユニットテストを含む。
【0094】
（ｂ．ナビゲーション）
ここで、図１３を参照すると、プラグインのレイアウトを管理するためのシステムによって生成されるツリーとナビゲーション画面の例のブロックが描かれている。レイアウトエンジンは、画面をレイアウトするだけでなく、フローを定義することも担当し得る。ナビゲーションのサブパーサとタブナビゲーションのサブパーサは、描かれているようにツリーを定義できる。それぞれのサブパーサ内には、スタック又はタブナビゲータ内のそれぞれの画面用の画面がある場合がある。ＹＡＭＬはヘッダースタイルとディープリンクなどの構成も定義できる。ビヘイビアエンジンはとりわけディープリンクを介して状態をプッシュ、ナビゲート、復元するなどの様々な機能を実行できる。このようにして、ナビゲーション、ディープリンク、その他の機能の大半のロジックをリアクトネイティブからＤＳＬに移動できる。例えば、３つのタブではなく５つのタブを持つようにアプリケーションを再構成することは、ＹＡＭＬで比較的簡単に変更できる。画面の流れはネイティブコードを変更することなく修正できる。
ここで、図１３を参照すると、プラグインのレイアウトを管理するためのシステムによって生成されるツリーとナビゲーション画面の例のブロックが描かれている。レイアウトエンジンは、画面をレイアウトするだけでなく、フローを定義することも担当し得る。ナビゲーションのサブパーサとタブナビゲーションのサブパーサは、描かれているようにツリーを定義できる。それぞれのサブパーサ内には、スタック又はタブナビゲータ内のそれぞれの画面用の画面がある場合がある。ＹＡＭＬはヘッダースタイルとディープリンクなどの構成も定義できる。ビヘイビアエンジンはとりわけディープリンクを介して状態をプッシュ、ナビゲート、復元するなどの様々な機能を実行できる。このようにして、ナビゲーション、ディープリンク、その他の機能の大半のロジックをリアクトネイティブからＤＳＬに移動できる。例えば、３つのタブではなく５つのタブを持つようにアプリケーションを再構成することは、ＹＡＭＬで比較的簡単に変更できる。画面の流れはネイティブコードを変更することなく修正できる。
【0095】
（ｃ．柔軟性と分離性）
リアクトコンポーネントとサブパーサを分割することの追加の利点は、レイアウトエンジンのないプロジェクトにリアクトコンポーネントをエクスポートできることである。さらに、レイアウトエンジン用にビルドされていないコンポーネントは、ラッパーとサブパーサを使用してインポートすることができる。コンポーネントはコードベースの他の部分から引っ張ってくることもできる。最後に、レイアウトパーサは、レイアウトエンジンフローのステップとして、手作りの画面、コンポーネント又は関数に分割できる。レイアウトエンジンは、コンポーネントのようにリアクトコードで使用するリアクトツリーを返すことができる。レイアウトエンジンで実行するために開発された画面の一部を含めるために、他のアプリケーションはレイアウトエンジンを使用しない可能性がある。
リアクトコンポーネントとサブパーサを分割することの追加の利点は、レイアウトエンジンのないプロジェクトにリアクトコンポーネントをエクスポートできることである。さらに、レイアウトエンジン用にビルドされていないコンポーネントは、ラッパーとサブパーサを使用してインポートすることができる。コンポーネントはコードベースの他の部分から引っ張ってくることもできる。最後に、レイアウトパーサは、レイアウトエンジンフローのステップとして、手作りの画面、コンポーネント又は関数に分割できる。レイアウトエンジンは、コンポーネントのようにリアクトコードで使用するリアクトツリーを返すことができる。レイアウトエンジンで実行するために開発された画面の一部を含めるために、他のアプリケーションはレイアウトエンジンを使用しない可能性がある。
【0096】
（ｄ．レイアウトに関するその他の考慮事項）
レイアウトエンジンに付随するものとして、テーマの定義及び環境に対する各コンポーネントのカスタマイズがある。これは、オペレーティングシステム（ＯＳ）のテーマのサポート（例えば、明及び暗モード）、アクセシビリティのサポート、ローカライゼーション及び国際化のサポート、デザイン言語の定義、バリアントのサポート、共通のレイアウト又はグリッドシステム、カラーパレット、ローカライズされたアセット、レイアウトの列数及び複数のアプリケーション間での再利用性など、様々な要因が考慮され得る。
レイアウトエンジンに付随するものとして、テーマの定義及び環境に対する各コンポーネントのカスタマイズがある。これは、オペレーティングシステム（ＯＳ）のテーマのサポート（例えば、明及び暗モード）、アクセシビリティのサポート、ローカライゼーション及び国際化のサポート、デザイン言語の定義、バリアントのサポート、共通のレイアウト又はグリッドシステム、カラーパレット、ローカライズされたアセット、レイアウトの列数及び複数のアプリケーション間での再利用性など、様々な要因が考慮され得る。
【0097】
レイアウトエンジンのコンポーネントは、さまざまな環境に合わせてカスタマイズすることができる。これはスタイルだけでなく、レイアウト、アセット、ローカライゼーションルール及びその他のカスタマイズも可能である。コンポーネントは外観とビヘイビアを持つことができる。ＣＭＳでは、このビヘイビアはテーマの中で制御され得る。これらのコンポーネントを使用して生成された複数のアプリケーションがある。こうして、あるアプリケーションでは入力の検証がフィールドの下に表示され、別のアプリケーションでは検証がフラッシュメッセージになるように指定され得る。さらに、暗テーマでは、色に合わせて異なるアセットの使用が伴うこと、或いはローカライゼーションで異なるアセットが必要になり得る。あるアプリケーションではアニメーション又はアクセシビリティのズームボタンを使い、一方、別のアプリケーションではアニメーション及びフォントのズームサポートがない場合がある。暗モードでは、色及びパディングが異なり得る。
【0098】
共有コンポーネントは環境に存在する。その環境は、異なる状態のアプリケーション（又は複数のアプリケーション）であり得る。そして、任意の状態で、そのコンポーネントのためのさらなるカスタマイズができる。コンポーネントは柔軟性があり、オン又はオフにできる様々な機能をサポートできる。視覚的特徴に加えて、その環境のデフォルトのビヘイビアを定義してもよい。構成はＹＡＭＬからレイアウトエンジンに移動させることができるが、その場合、アプリケーションがボタンを使うたびに、アプリケーションは構成を何度も使い得る。ボタンの視覚的な特徴とデフォルトのオプションの設定方法を定義する一つのテーマファイルを使用できる。レイアウトエンジンとＹＡＭＬはこれを繰り返し定義しないが、テーマファイルはアプリケーションのためにこれを定義し得る。
【0099】
レイアウトエンジンは、分離を強制することができる。例えば、レイアウトエンジンは、画面にボタンを配置するよう指示することができる。アプリケーションからは、アプリケーションはボタンを要求し得る。現在のテーマは、スタイルのためにこれを容易にし、アクセシビリティのズームもサポートしているため、ボタンのビヘイビア及び視覚的特徴の一部を変更できる。主なポイントは、テーマが単なる色、パディング、フォントサイズなどではなく、ボタンコンポーネントに渡すことができる追加の構成である。テーマの柔軟性にはとりわけ検証がある。検証ＹＡＭＬはコードの隣に設置され、且つｔｈｅｍｅ．ｙａｍｌも検証ファイルの隣に配置され得る。すべてのコンポーネントのオプションは１つのフォーマットＹＡＭＬに対応する一つの場所に配置できる。
【0100】
（４．アセット）
アセットはテーマの一部かであり得る。ボタンに親指を立てるアイコンを追加する場合、アプリケーションはそのテーマに適したアイコンを特定することができる。各テーマがアセットを定義できるように、レジストリを作成できる。テーマに定義されていない場合、アプリケーションは基本テーマにフォールバックする。各アセットはテーマに属するため、アセットはテーマごとになる。アセットは様々なフォーマットで入力できる（例えば、ＳＶＧ、ＭＰ４、Ｌｏｔｔｉｅ）。
アセットはテーマの一部かであり得る。ボタンに親指を立てるアイコンを追加する場合、アプリケーションはそのテーマに適したアイコンを特定することができる。各テーマがアセットを定義できるように、レジストリを作成できる。テーマに定義されていない場合、アプリケーションは基本テーマにフォールバックする。各アセットはテーマに属するため、アセットはテーマごとになる。アセットは様々なフォーマットで入力できる（例えば、ＳＶＧ、ＭＰ４、Ｌｏｔｔｉｅ）。
【0101】
ここで図１４を参照すると、プラグイン用のレイアウトを管理するためのシステムで使用されるテーマ構成のブロック図が描かれている。描かれているように、２種類のテーマと、テーマが存在する２つの境界がある。最初の境界はコンポーネントであり、また次は特定のアプリケーションである。各境界内には、２種類のテーマがあり、一方は基本テーマに対応し、他方は名前付きテーマ（例えば、明又は暗モード）に対応する。
【0102】
基本テーマは、感覚的なデフォルトを定義できる。基本テーマはコンポーネント境界にあり、すべてのアプリケーションは個別のコンポーネントに対してこれらのデフォルトを得ることができる。アプリケーション境界では、基本テーマはその特定のアプリケーションに適用される。他のタイプは、コンポーネント境界ではなく、アプリケーション境界に適用される名前付きテーマ（例えば、暗と明）であってもよい。さらに、アプリケーションはある時点で一つのアクティブなテーマを持ってもよい。コンポーネント境界はより多くの分離を生み出し得る。異なるアプリケーションは、コンポーネントのテーマ変数が変更されるたびにアプリケーションのすべての基本テーマを更新するために、共有コンポーネントをインポートすることができる。
【0103】
テーマについては、そのテーマが基本テーマか名前付きテーマかを指定することができる。そのテーマには優先度を定義できる。すべてのテーマデータをマージすることで、テーマのセットを特定のアプリケーション用の単一のテーマ構成にまとめることができ、テーマデータの各ユーザがこれらの構成を実行する必要がなくなる。どのアプリケーションが実行中で、どのテーマがアクティブであるかを使用すること、自動マージは、アプリケーションに単一の決定を提供することに使用できる。例えば、デフォルトでは、アプリケーションには優先度の値１０を、コンポーネントには１００を提供できる。
【0104】
ここで図１５を参照すると、プラグイン用のレイアウトを管理するためのシステムにおいて、優先度に従ってテーマをマージするプロセスのフロー図が描かれている。第１に、テーマ提供者は、コンポーネントとアプリケーションの境界を含む両方の境界から、すべての基本テーマをマージすることができる。テーマ提供者は、マージ順序を決定するために０から１００の間の優先度を使用できる。マージが完了すると、優先度０が優先度１００に勝ったマージされた基本テーマを表す単一の結合オブジェクトが得られる。テーマ提供者は、すべての名前テーマを一つずつマージすることができる。明及び暗の２つのテーマがある場合、２つの結合されたマージオブジェクトが計算される。このステップでは、優先度の点でステップ１と同じロジックを使用できる。
【0105】
基本及び名前付きテーマの特定により、テーマ提供者はアクティブなテーマを選択し、選択したテーマを基本テーマの上にマージすることができる。このように、テーマ提供者は、基本テーマからのデフォルトを持つことができる。テーマ提供者は、結合された基本又は名前付きテーマをたどって＄ｒｅｆをサーチし、オブジェクトの正しい部分を指すように値を更新し、＄ｒｅｆを実際の値に置き換えることができる。テーマ提供者は、リアクトネイティブスタイルシートをコンパイルすることでテーマを最適化し、その結果をキャッシュする。
【0106】
ｒｅｆと共有値については、多くの場合、ｔｅｘｔＣｏｌｏｒのような変数が使われる。テーマでは、＄ｒｅｆは値としてこれを許可する。これは、設定の別の部分を参照し得る。この＄ｒｅｆは、異なる名前付きの又はコンポーネントのテーマで定義された値の使用を許可するために、すべてのマージにまたがって適用できる。これは、例えば、テキストコンポーネントがあり、これがボディのようなスタイルを定義するために使われる場合に便利である。入力フィールドがあり、且つ全く同じボディスタイルが使用される場合、フィールド＄ｒｅｆが使用できる。
【0107】
マージが最初に実行され、＄ｒｅｆの置き換えが最後のステップであるため、アプリケーションのテーマ又は基本テーマはボディスタイルをオーバーライドでき、テキストと入力フィールドの両方がその値を使用できる。最後に、構成がスタイルとして使われるため、構成ファイルは任意の種類の名前空間をインポートするためのＹＡＭＬ構造を持ち得る。例えば、ファイルでｂｕｔｔｏｎ．ｐｒｉｍａｒｙ．ｌａｙｏｕｔ．ｐａｄｄｉｎｇ＝１００を指定することができる。これにより、スタイルの名前空間をより表現豊かにし得る。バリアントに関しては、名前空間はバリアントを作成するために使われ得る。これはオーバーライド値であり得る。そして、コンポーネントはプロパティバリアントを持つことができ、すべてのテーマプロバイダは名前空間バリアント値をテーマにマージすることができる。これにより、ボタンが異なるバリアントを持つことができる。これは状態でもできる。
【0108】
（Ｃ．ユーザ関連条件のアプリケーションのための有限状態機械の構成及び処理のためのシステム及び方法）
ここで図１６を参照すると、アプリケーションに有限状態機械（ＦＳＭｓ）を提供するためのシステム１６００のブロック図が描かれている。概要において、システム１６００は、少なくとも１つのネットワーク１６２０を介して互いに通信可能に結合された、少なくとも１つのアプリケーション構成サービス１６０５、１つ又は複数のクライアント１６１０Ａ～Ｎ（以下、一般にクライアント１６１０と称する）及び少なくとも１つのデータベース１６１５を含み得る。アプリケーション構成サービス１６０５は、少なくとも１つのファイルハンドラ１６２５、少なくとも１つのプラグインジェネレータ１６３０、少なくとも１つのコンテンツマネージャ１６３５及び少なくとも１つの分析評価器１６４０を含み得る。データベース１６１５は、少なくとも１つの構成ファイル１６４５Ａ～Ｎ（以下、一般に構成ファイル１６４５と称する）を記憶し、維持し又は他の方法で含んでもよい。各クライアント１６１０は、少なくとも１つのアプリケーション１６５０を含み得る。アプリケーション１６５０は、特に、少なくとも１つのアプリケーションサービス１６６０、少なくとも１つのビヘイビアマネージャ１６６５、少なくとも１つのレイアウトハンドラ１６７０、少なくとも１つのイベントバス１６７５及び少なくとも１つのプラグイン１６８０Ａ～Ｎ（以下、一般にプラグイン１６８０と称する）を含み得る。アプリケーション１６５０はまた、１つ又は複数のユーザインタフェース要素１６９０Ａ～Ｎ（以下、一般にユーザインタフェース要素１６９０と称する）を含む少なくとも１つのユーザインタフェース１６８５を提供し得る。
ここで図１６を参照すると、アプリケーションに有限状態機械（ＦＳＭｓ）を提供するためのシステム１６００のブロック図が描かれている。概要において、システム１６００は、少なくとも１つのネットワーク１６２０を介して互いに通信可能に結合された、少なくとも１つのアプリケーション構成サービス１６０５、１つ又は複数のクライアント１６１０Ａ～Ｎ（以下、一般にクライアント１６１０と称する）及び少なくとも１つのデータベース１６１５を含み得る。アプリケーション構成サービス１６０５は、少なくとも１つのファイルハンドラ１６２５、少なくとも１つのプラグインジェネレータ１６３０、少なくとも１つのコンテンツマネージャ１６３５及び少なくとも１つの分析評価器１６４０を含み得る。データベース１６１５は、少なくとも１つの構成ファイル１６４５Ａ～Ｎ（以下、一般に構成ファイル１６４５と称する）を記憶し、維持し又は他の方法で含んでもよい。各クライアント１６１０は、少なくとも１つのアプリケーション１６５０を含み得る。アプリケーション１６５０は、特に、少なくとも１つのアプリケーションサービス１６６０、少なくとも１つのビヘイビアマネージャ１６６５、少なくとも１つのレイアウトハンドラ１６７０、少なくとも１つのイベントバス１６７５及び少なくとも１つのプラグイン１６８０Ａ～Ｎ（以下、一般にプラグイン１６８０と称する）を含み得る。アプリケーション１６５０はまた、１つ又は複数のユーザインタフェース要素１６９０Ａ～Ｎ（以下、一般にユーザインタフェース要素１６９０と称する）を含む少なくとも１つのユーザインタフェース１６８５を提供し得る。
【0109】
システム１６００の各コンポーネント（例えば、アプリケーション構成サービス１６０５とそのコンポーネント及び各クライアント１６１０とそのコンポーネント）は、セクションＤで本明細書に詳述したシステム１９００のようなハードウェア又はハードウェアの組み合わせを使用して実行、処理又は実装されてもよい。システム１６００のコンポーネントは、セクションＡ及びＢにおいて本明細書に詳述される機能性を実行、処理又は実装するためにも使用され得る。例えば、アプリケーション構成サービス１６０５及びアプリケーション１６５０は、上記のセクションに説明されているように、ビヘイビアエンジン及びレイアウトエンジンと連動して詳述された動作を実行し得る。
【0110】
ここで、図１７Ａを参照すると、アプリケーションに有限状態機械（ＦＳＭｓ）を提供するためのシステム１６００内の命令を生成するためのプロセス１７００のブロック図が描かれている。プロセス１７００は、プラグイン１６８０を生成してクライアント１６１０に提供するためのアプリケーション構成サービス１６０５の動作に対応し得る。プロセス１７００の下で、アプリケーション構成サービス１６０５上で実行されるファイルハンドラ１６２５は、データベース１６１５から少なくとも１つの構成ファイル１６４５（例えば、第１構成ファイル１６４５Ａ）を検索、フェッチ又は特定してもよい。いくつかの実施形態では、ファイルハンドラ１６２５は、構成ファイル１６４５を作成する開発者のコンピューティングデバイスなどの別のソースから、構成ファイル１６４５を検索、取得又は受信してもよい。構成ファイル１６４５は、アプリケーション１６５０に追加されるプラグイン１６８０の様々な機能性を構成、定義又は他の方法で指定するための命令（例えば、人間が読み取り可能な命令を含むスクリプト）を含むことができる。構成１６４５によって指定される機能性は、アプリケーションサービス１６６０のものなど、アプリケーション１６５０の組み込みロジック及び機能性とは別であってもよい。いくつかの実施形態では、構成ファイル１６４５に含まれる命令は、特に、Ｙｅｔ Ａｎｏｔｈｅｒ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＹＡＭＬ）、Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）及びＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）などの人間が読めるフォーマットであってもよい。この態様では、構成ファイル１６４５内の人間が読み取り可能な命令を記述する際に開発者によって引き受けられる労力は、他のフォーマットで命令を構成する場合よりも少なくなり得る。
【0111】
構成ファイル１６４５内の命令は、少なくとも１つの有限状態機械（ＦＳＭ）１７０５を指定、識別又は他の方法で定義してもよい。ＦＳＭ１７０５は、アプリケーション１６５０のユーザの状態に対処するための一連のルーチンのためのものであってもよい。例えば状態は、特に喫煙、肥満、心理的障害（例えば、統合失調症）、精神的認知及びうつ病など、ユーザ側のものを含み得る。ＦＳＭ１７０５によって設定されるルーチンは、これらの異なる状態の様々な治療又は管理を含み得る。ルーチンは、共通のものであってもよいし、異なるタイプの状態に対して異なるものであってもよい。例えば、喫煙又は肥満の治療には、水分補給などのルーチンに指定された共通の活動がある。喫煙、肥満及びうつ病の場合、ＦＳＭ１７０５によって設定されるルーチンは、フィットネス作業又は呼吸運動などを含むことができる。ルーチンのセットは、禁煙など、所定の状態の目標行動エンドポイントを達成するためのユーザの旅に沿ったステップを形成することができる。アクティビティは、ユーザのクライアント１６１０上で実行されるアプリケーション１６５０を介して記録され得る。
【0112】
いくつかの実施形態において、構成ファイル１６４５（そしてその延長として、ＦＳＭｓ１７０５）のためのルーチンは、データベース１６１５上に保持されたルーチンのライブラリから選択されてもよい。ルーチンは、構成ファイル１６４５又はプラグイン１６８０の開発者によって、或いは構成ファイル１６４５又はプラグイン１６８０によって対象とされる条件を使用してファイルハンドラ１６２５によって選択されてもよい。ライブラリは、フィットネス運動、歩行、呼吸、水分補給又はメッセージの読み取りなど、様々なルーチンを識別又は定義するための命令を含むことができる。異なるルーチンを選択する能力は、特定の条件を対象とすることを可能にし、また構成ファイル１６４５内の命令を多種多様なアプリケーション１６０５で使用することを可能にし得る。例えば、呼吸運動のためのルーチンを詳述する１つの構成ファイル１６４５は、禁煙を目的とするアプリケーション１６０５及び肥満を目的とする別のアプリケーション１６５０に使用され得る。
【0113】
ＦＳＭ１７０５は、一組の状態１７１０Ａ～Ｎ（以下、一般に状態１７１０と称する）及び一組の遷移１７１５Ａ～Ｎ（以下、一般に遷移１７１５と称する）を特定又は含むことができる。各状態１７１０は、呼び出されたときにＦＳＭ１７０５によって生成される出力を定義、特定又は他の方法で指定することができる。いくつかの実施形態では、少なくとも１つの状態１７１０は、ＦＳＭｓ１７０５のセット内の別のＦＳＭ１７０５の呼び出しを指定し得る。出力は、ＦＳＭ１７０５に関連するルーチンのセット内の特定のルーチンに対するものであってもよく、アプリケーション１６５０のユーザインタフェース１６８５を介して提示されるユーザインタフェース要素１６９０を特定してもよい。いくつかの実施形態において、出力は、ユーザインタフェース１６８５に提供されるコンテンツアイテムのための１つ又は複数の識別子（例えば、ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ））を特定してもよい。例えば、状態１７１０の出力は、ユーザが歩行運動を完了したときに、禁煙のヒントメッセージを表示するためのものであってもよい。
【0114】
各遷移１７１５は、ある状態１７１０から別の状態１７１０にＦＳＭ１７０５を更新するために、アプリケーション１６５０を介して検出されるイベントを定義、特定又は他の方法で指定することができる。いくつかの実施形態では、少なくとも１つの遷移１７１５は、ＦＳＭｓ１７０５のセット内の別のＦＳＭ１７０５を呼び出すために検出されるイベントを指定し得る。例えば、遷移１７１５は、他のＦＳＭ１７０５の初期状態又は他の定義された状態であってもよい。イベントは、関連するルーチンに対してアプリケーション１６５０を介して実行されるアクションに対応してもよい。例えば、遷移１７１５は、ある状態１７１０Ａから次の状態１７１０Ｂに移行するために、ユーザがアプリケーション１６５０のユーザインタフェース１６８５を介して呼吸運動の完了を記録することを指定することができる。各状態１７１０は、状態１７１０に関連付けられた１つ又は複数の遷移１７１５を有し得る。
【0115】
いくつかの実施形態において、ファイルハンドラ１６２５は、アプリケーション１６５０のユーザインタフェース１６８５のためのＦＳＭ１７０５に関連付けられたユーザインタフェース要素１６９０のプレゼンテーションのための構成ファイル１６４５（例えば、第２構成ファイル１６４５Ｂ）を検索、フェッチ又は特定してもよい。いくつかの実施形態において、ユーザインタフェース１６８５を介したユーザ要素のプレゼンテーションのための構成ファイル１６４５Ｂは、ＦＳＭ１７０５を定義する構成ファイル１６４５Ａと同じであってもよい。いくつかの実施形態では、ユーザインタフェース要素１６９０の提示のための構成ファイル１６４５Ｂは、ＦＳＭ１７０５を定義する構成ファイル１６４５Ａとは別個であってよい。構成ファイル１６４５は、ＦＳＭ１７０５の各状態１７１０における出力のためのユーザインタフェース要素１６９０を指定、定義又は他の方法で特定してもよい。構成ファイル１６４５によって指定された出力用のユーザインタフェース要素１６９０は、複数の状態１７１０及び複数のＦＳＭｓ１７０５にわたって共有されてもよい。ユーザインタフェース要素１６９０は、色、フォントサイズ及び配置などの視覚的プロパティの観点から定義されてもよい。ユーザインタフェース要素１６９０は、アプリケーション構成サービス１６０５（又は別のリモートサーバ）からアプリケーション１６５０によって検索されるべきアセット（例えば、画像、ビデオ又は他のオブジェクト）に対応してもよい。
【0116】
アプリケーション構成サービス１６０５上で実行されるプラグインジェネレータ１６３０は、１つ又は複数の構成ファイル１６４５（例えば、ＦＳＭ１７０５を定義する構成ファイル１６４５Ａの人間が読み取り可能な命令）を使用して、プラグイン１６８０を生成、出力又は他の方法で生成してもよい。プラグイン１６８０は、アプリケーション１６５０上で実行される様々な機能性を構成、定義又は他の方法で指定するための命令を含み得る。プラグイン１６８０の命令は、中間フォーマット（本明細書では、トランスパイル又は翻訳フォーマットと称されることもある）であってもよい。例えば、プラグイン１６８０の命令は、人間が読むことのできる命令から、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）、ＴｙｐｅＳｃｒｉｐｔ、Ｓｗｉｆｔ又はＰｙｔｈｏｎなどの中間フォーマットに変換されてもよい。プラグイン１６８０のための命令はまた、状態１７１０及び遷移１７１５のセットを含むＦＳＭ１７０５を定義してもよい。各プラグイン１６８０は、指定されたルーチンを実行することによって対処される１つ又は複数の条件に関連付けられ得る。
【0117】
さらに、プラグイン１６８０のための命令は、ＦＳＭ１７０５内の状態１７１０における出力のためのユーザインタフェース要素１６９０を定義することもできる。プラグイン１６８０はアプリケーション１６５０とは別個に生成されるため、アプリケーション１６５０がどのプラグイン１６８０を含むかは、対処すべきユーザの状態に基づいて容易に交換され得る。生成において、プラグインジェネレータ１６３０は、プラグイン１６８０の仕様を格納する別個のファイルを作成してもよい。プラグインジェネレータ１６３０は、１つ又は複数の構成ファイル１６４５を解析して、元のフォーマットの命令を読み取るか、或いは特定してもよい。いくつかの実施形態において、プラグインジェネレータ１６３０は、プラグイン１６８０を生成しながら、ＦＳＭ１７０５を定義する構成ファイル１６４５Ａ及び出力のためのユーザインタフェース要素１６９０を定義する構成ファイル１６４５Ｂを直列又は並列に解析してもよい。
【0118】
構成ファイル１６４５（例えば、構成ファイル１６４５Ａ）の特定時に、プラグインジェネレータ１６３０は、アプリケーション１６５０に含めるための実行可能フォーマットで同等の命令を生成又は決定してもよい。プラグインジェネレータ１６３０は、アプリケーション１６５０に追加される中間フォーマットの命令を生成するために（例えば、ＪａｖａＳｃｒｉｐｔ Ｎｏｔａｔｉｏｎ Ｏｂｊｅｃｔ（ＪＳＯＮ）フォーマット、ＴｙｐｅＳｃｒｉｐｔ、Ｓｗｉｆｔ又はＰｙｔｈｏｎフォーマットに）、構成ファイル１６４５を翻訳又はトランスパイルしてもよい（例えば、トランスパイラ又はコンバータを使用して）。いくつかの実施形態において、プラグインジェネレータ１６３０は、より低レベルの言語で命令を生成するために、構成ファイル１６４５をコンパイルしてもよい。コンパイルされるとき、プラグイン１６８０のための命令は、特に、バイトコード、アセンブリ、オブジェクトコード又はマシンコードなどの低レベルの言語であり得る。いくつかの実施形態では、低レベルの言語のコンパイルは、クライアント１６１０上のアプリケーション１６５０によって実行されてもよい。生成時に、プラグインジェネレータ１６３０は、プラグイン１６８０のためのファイルに同等の命令を書き込んでもよく、構成ファイル１６４５の終わりまで繰り返し得る。
【0119】
生成によって、プラグインジェネレータ１６３０は、アプリケーション１６５０に追加又は含めるプラグイン１６８０の命令を伝送、送信又は他の方法で提供することができる。いくつかの実施形態では、プラグインジェネレータ１６３０は、クライアント１６１０へのインストールの前に、プラグイン１６８０をアプリケーション１６５０に挿入又は注入してもよい。例えば、プラグインジェネレータ１６３０は、特に、アプリケーションサービス１６６０、ビヘイビアマネージャ１６６５、レイアウトハンドラ１６７０及びイベントバス１６７５などの他のコンポーネントをすでに含むアプリケーション１６５０にプラグイン１６８０を挿入してもよい。プラグインジェネレータ１６３０は、挿入されたプラグイン１６８０を含むアプリケーション１６５０を、クライアント１６１０にインストールされたアプリケーション１６５０によってロードされるように、デジタル配信プラットフォーム（例えば、アプリケーションマーケット又はストア）を介してクライアント１６１０に提供してもよい。クライアント１６１０は、インストールのために、アプリケーション構成サービス１６０５（又はデジタル配信プラットフォーム）からアプリケーション１６５０をダウンロード又は検索するよう要求することができる。一旦受信されると、クライアント１６１０は、プラグイン１６８０を含むアプリケーション１６５０を解凍及びインストールすることができる。
【0120】
いくつかの実施形態では、プラグインジェネレータ１６３０は、クライアント１６１０にインストールされたアプリケーション１６５０を追加又は含めるためのプラグイン１６８０の指示を提供することができる。例えば、クライアント１６１０は、アプリケーション構成サービス１６０５から（例えば、デジタル配信プラットフォームを介して）受信したアプリケーション１６５０を事前にインストールしていてもよい。いくつかの実施形態では、クライアント１６１０は、その後、アプリケーション１６５０にルーチンの要求を送信することができる。要求は、アプリケーション１６５０を介して、状態に対処するためにユーザによって実行されるべき１つ又は複数のルーチンを特定し得る。リクエストにおいて特定されたルーチンに基づいて、プラグインジェネレータ１６３０は、クライアント１６１０上のアプリケーション１６５０に提供するために、対応するルーチンのための１つ又は複数のプラグイン１６８０を特定又は選択し得る。いくつかの実施形態において、プラグインジェネレータ１６３０は、プラグイン１６８０の指示を提供するために、更新がアプリケーション１６５０に提供されることを特定又は決定してもよい。例えば、アプリケーション構成サービス１６０５のシステム管理者は、アプリケーション１６５０のインスタンスが更新されることを指示してもよい。更新の特定によって、プラグインジェネレータ１６３０は、アプリケーション１６５０の他のコンポーネントを提供することなく、プラグイン１６８０のための命令を提供することができる。
【0121】
受信すると、クライアント１６１０（又はアプリケーション１６５０内で実行されているアプリケーションサービス１６６０）は、プラグイン１６８０を含むようにアプリケーション１６５０を更新してもよい。クライアント１６１０は、アプリケーション１６５０にロードされるプラグイン１６８０を保存してもよい。実行時に、アプリケーション１６５０は、ルーチン１６８０によって指定されたルーチンを実行するためにプラグイン１６８０をロードしてもよい。いくつかの実施形態において、プラグイン１６８０のための受信された命令は、中間フォーマットであってもよい。アプリケーション１６５０は、クライアント１６１０上で実行するための低レベルフォーマットを生成するために、命令をさらにコンパイルしてもよい。例えば、クライアント１６１０又はアプリケーション１６５０は、低レベルの言語の命令を生成するために、構成ファイル１６４５をコンパイルしてもよい。コンパイルされるとき、プラグイン１６８０のための命令は、特に、バイトコード、アセンブリ、オブジェクトコード又はマシンコードのような低レベル言語であり得る。いくつかの実施形態では、更新において、クライアント１６１０（又はアプリケーション１６５０）は、古いプラグイン１６８０を、新しく受信されたプラグイン１６８０と同じ条件に対処するルーチンで代用又は置き換えることができる。受信時に、アプリケーション１６５０は、新たに受信されたプラグイン１６８０と同じ状態に対処するための以前に提供されたプラグイン１６８０を特定し得る。この特定により、アプリケーション１６５０は、以前に提供されたプラグイン１６８０を削除するか、そうでなければ除去してもよい。
【0122】
ここで、図１７Ｂを参照すると、アプリケーションに有限状態機械（ＦＳＭｓ）を提供するためのシステム１６００において有限状態機械（ＦＳＭｓ）を処理するためのプロセス１７３０のブロック図が描かれている。プロセス１７３０は、アプリケーション１６５０を実行する際のクライアント１６１０における操作に対応し得る。プロセス１７３０の下で、アプリケーション１６５０上で実行されるアプリケーションサービス１６６０は、特に、ビヘイビアマネージャ１６６５、レイアウトハンドラ１６７０、イベントバス１６７５及びユーザインタフェース１６８５などの実行の開始などの初期化オペレーションを実行してもよい。アプリケーションサービス１６６０は、プラグイン１６８０のセットの外側でアプリケーション１６５０のために定義された様々なロジック及びオペレーションを実行してもよい。
【0123】
クライアント１６１０上で実行されるアプリケーション１６５０のビヘイビアマネージャ１６６５は、アプリケーション１６５０に含まれるプラグイン１６８０内のＦＳＭｓ１７０５のセットをインスタンス化、初期化又は他の方法で確立することができる。いくつかの実施形態では、ビヘイビアマネージャ１６６５は、ユーザ１７４０の特定の状態に対処するためのルーチンのために、ＦＳＭｓ１７０５のセットから１つ又は複数の選択又は特定をすることができる。例えば、初期化中に、ビヘイビアマネージャ１６６５は、ＦＳＭｓ１７０５を通じて提供されるルーチンを介して対処されるべきユーザ１７４０の状態を示すユーザ入力を受信し得る。ユーザ入力を使用して、ビヘイビアマネージャ１６６５は、全体的なセットからロードするＦＳＭｓ１７０５を選択することができる。ＦＳＭｓ１７０５の少なくともサブセットにおいて、各ＦＳＭ１７０５は、特に、フィットネスワークアウト、呼吸運動、ストレス解消活動、水分補給及び禁煙リマインダなどのルーチンの特定のセットに対応してもよい。
【0124】
初期化において、ビヘイビアマネージャ１６６５は、ＦＳＭｓ１７０５とアプリケーション１６５０の様々なコンポーネントとの間の通信を容易にするために、ロードされたＦＳＭｓ１７０５をイベントバス１６７５に接続してもよい。イベントバス１６７５は、プラグイン１６８０と、アプリケーションサービス１６６０、ビヘイビアマネージャ１６６５及びレイアウトハンドラ１６７０などのアプリケーション１６５０の様々なコンポーネントとの間のインタフェースに対応し得る。この接続により、ビヘイビアマネージャ１６６５は、イベントバス１６７５を介して、アプリケーション１６５０とのユーザインタラクションに対応するイベントを各ＦＳＭ１７０５に分配又は伝達することができる。受信側のＦＳＭｓ１７０５は、順番に、イベントバス１６７５を介して伝達されたイベントを処理し、取り扱うことができる。
【0125】
さらに、個別のプラグイン１６８０内の各ＦＳＭ１７０５について、ビヘイビアマネージャ１６６５は、ＦＳＭ１７０５の現在の状態１７１０を追跡し得る。ビヘイビアマネージャ１６６５は、イベントバス１６７５を介して、各ＦＳＭ１７０５の現在の状態１７１０を追跡し得る。いくつかの実施形態では、ビヘイビアマネージャ１６６５は、イベントバス１６７５を介して、現在の状態１７１０について、各ＦＳＭ１７０５にｐｉｎｇ又は問い合わせ（例えば、サンプル周期で）を送信してもよい。いくつかの実施形態では、各ＦＳＭ１７０５は、（例えば、サンプル周期で）現在の状態１７０５を、イベントバス１６７５を介してビヘイビアマネージャ１６６５に提供してもよい。いくつかの実施形態では、ビヘイビアマネージャ１６６５は、追跡するために、各ＦＳＭ１７０５のための現在の状態１７１０の識別子を使用又は維持し得る。初期化時に、各ＦＳＭ１７０５の現在の状態１７１０は、ＦＳＭ１７０５の開始状態１７１０（例えば、描かれているような状態１７１０Ａ）に対応してもよい。
【0126】
連動して、ビヘイビアマネージャ１６６５は、イベントバス１６７５を介して、ユーザインタフェース１６８５内のユーザインタフェース要素１６９０の１つ又は複数の少なくとも１つのイベント１７３５を監視又はリッスンすることができる。イベント１７３５は、アプリケーション１６５０のユーザ１７４０によって実行される少なくとも１つのアクションに対応し得る。例えば、ユーザインタフェース１６８５は、呼吸運動を実施するようにユーザ１７４０にプロンプトを提示してもよく、ユーザ１７４０は、ユーザインタフェース１６８５上のユーザインタフェース要素１６９０の一つとのユーザインタラクションを介して運動の完了を示してもよい。いくつかの実施形態において、ビヘイビアマネージャ１６６５は、アプリケーション１６９０又はクライアント１６１０の別のプロセスからのイベント１７３５を監視又はリッスンしてもよい。この場合のイベント１７３５は、ユーザ１７４０からのインタラクションによってトリガーされなかった、アプリケーション１６９０又はクライアント１６１０のプロセスによるアクションの発生に対応し得る。例えば、ビヘイビアマネージャ１６６５は、クライアント１６１０上のシステムタイマから日付及び時刻を特定するデータを受信し、そのデータの受信をイベント１７３５として認識してもよい。
【0127】
イベント１７３５の検出に応答して、ビヘイビアマネージャ１６６５は、呼び出すための対応するプラグイン１６８０内の少なくとも１つのＦＳＭ１７０５を決定又は選択してもよい。いくつかの実施形態では、ビヘイビアマネージャ１６６５は、検出されたイベント１７３５を、イベントバス１６７５を介してプラグイン１６８０に伝達又は渡すことができる。上述したように、イベントバス１６７５は、プラグイン１６８０とアプリケーション１６５０の様々なコンポーネントとの間のインタフェースに対応し得る。イベントバス１６７５は、アプリケーション１６５０にロードされたプラグイン１６８０間の呼び出し及び信号を中継、伝達又は他の方法で提供するために使用されてもよい。渡すことによって、ビヘイビアマネージャ１６６５は、検出されたイベント１７３５を、現在の状態１７１０について遷移１７１５によって指定されたイベントと照合することができる。上述したように、ビヘイビアマネージャ１６６５は、個別のプラグイン１６８０内の各ＦＳＭ１７０５の現在の状態１７１０を追跡し得る。いくつかの実施形態では、ビヘイビアマネージャ１６６５は、イベントバス１６７５を介して、検出されたイベント１７３５のチェックの結果を検出又は受信してもよい。
【0128】
検出されたイベント１７３５が、現在の状態１７１０の任意の遷移１７１５においても仕様に対応しない場合、ビヘイビアマネージャ１６６５は、ＦＳＭ１７０５を現在の状態１７１０（例えば、描かれているような状態１７１０Ａ）に維持してもよい。いくつかの実施形態では、ビヘイビアマネージャ１６６５はまた、ＦＳＭ１７０５の呼び出すことを控えてもよい。現在の状態１７１０におけるＦＳＭ１７０５の維持は、ユーザ１７４０が、現在の状態１７１０に関連する任意の遷移１７１５についても、ＦＳＭ１７０５のために設定されたルーチンのセットのルーチンを完了していないことに対応し得る。ビヘイビアマネージャ１６６５は、検出されたイベント１７３５を、他のプラグイン１６８０内のＦＳＭｓ１７０５の仕様に対してチェックし続けることができる。
【0129】
逆に、検出されたイベント１７３５が、現在の状態１７１０の遷移１７１５のうちの一つの仕様に対応するとき、ビヘイビアマネージャ１６６５は、呼び出したＦＳＭ１７０５を選択してもよい。呼び出すことによって、ビヘイビアマネージャ１６６５は、遷移１７１５に従って、ＦＳＭ１７０５の現在の状態１７１０を次の状態１７１０’に更新してもよい（例えば、図示のように）。ＦＳＭ１７０５の現在の状態１７１０から次の状態１７１０’への更新は、ユーザ１７４０が、現在の状態１７１０に関連付けられた遷移１７１５の少なくとも１つについて特定されたように、ＦＳＭ１７０５のために設定されたルーチンのセットのルーチンを完了したことに対応し得る。さらに、プラグイン１６８０のＦＳＭ１７０５を呼び出すことから、ビヘイビアマネージャ１６６５は、ＦＳＭ１７０５の次の状態１７１０’によって特定される出力１７４５を検索又は特定してもよい。出力１７４５は、上述したように、アプリケーション１６５０のユーザインタフェース１６８５を介して提示されるユーザインタフェース要素１６９０を特定し得る。いくつかの実施形態において、出力１７４５は、ユーザインタフェース１６８５のユーザインタフェース要素１６９０に適用される修正を特定してもよい。ビヘイビアマネージャ１６６５は、イベントバス１６７５を介してビヘイビアマネージャ１６６５に出力１７４５を伝達又は渡すことができる。
【0130】
ここで、図１７Ｃを参照すると、アプリケーションに有限状態機械を提供するためのシステム１６００におけるユーザインタフェース１６８５を修正するためのプロセス１７６０のブロック図が描かれている。プロセス１７６０は、プラグイン１６８０内のＦＳＭｓ１７０５のうちの１つの起動時のアプリケーション構成サービス１６０５及びアプリケーション１６５０のオペレーションに対応し得る。プロセス１７６０の下で、クライアント１６１０上で実行されるアプリケーション１６５０のレイアウトハンドラ１６７０は、出力１７４５に従って、ユーザインタフェース１６８５のユーザインタフェース要素１６９０を更新、変更又は他の方法で修正し得る。ユーザインタフェース１６８５を設定することによって、レイアウトハンドラ１６７０は、プラグイン１６８０のＦＳＭ１７０５内の状態１７１０をユーザインタフェース１６８５のユーザインタフェース要素１６９０に関連付け又はバインドすることができる。いくつかの実施形態において、ビヘイビアマネージャ１６６５と連携するレイアウトハンドラ１６７０は、ＦＳＭ１７０５の状態１７１０とユーザインタフェース１６８５のユーザインタフェース要素１６９０との関連付け又はバインディングを維持し得る。例えば、レイアウトハンドラ１６７０は、直近に呼び出されたＦＳＭ１７０５の状態１７１０と、ユーザインタフェース１６８５を介してレンダリング又は提示されたユーザインタフェース要素１６９０との間の関係を追跡し得る。
【0131】
修正において、レイアウトハンドラ１６７０は、コンテンツに対する要求１７６５をアプリケーション構成サービス１６０５（又は別のリモートサービス）に送信するかどうかを決定し得る。出力１７４５は、アプリケーション構成サービス１６０５からアプリケーション１６５０の実行中に提供される少なくとも１つのコンテンツアイテム１７７０（例えば、画像、動画及び他のオブジェクト）に依存してもよい。出力１７４５がコンテンツアイテム１７７０の検索を指定しない場合、レイアウトハンドラ１６７０は、コンテンツに対する要求１７６５をアプリケーション構成サービス１６０５に送信することを控え得る。また、レイアウトハンドラ１６７０は、出力１７４５に従って、ユーザインタフェース１６８５のユーザインタフェース要素１６９０の修正を継続してもよい。一方、出力１７４５がコンテンツ１７６５の検索を指定する場合、レイアウトハンドラ１６７０は、コンテンツに対する要求１７６５をアプリケーション構成サービス１６０５に送信することを決定してもよい。レイアウトハンドラ１６７０は、アプリケーション構成サービス１６０５から検索されるべきコンテンツアイテム１７７０を参照する少なくとも１つの識別子を含むコンテンツに対する要求１７６５を生成してもよい。識別子は、ＦＳＭ１７０５の現在の状態１７１０からの出力１７４５によって指定され得る。
【0132】
アプリケーション構成サービス１６０５上で実行されるコンテンツマネージャ１６３５は、順に、クライアント１６１０からコンテンツに対する要求１７６５を検索、特定又は他の方法で受け取ることができる。いくつかの実施形態では、コンテンツマネージャ１６３５は、ネットワーク１６２０を介してアクセス可能なアプリケーション構成サービス１６０５とは別のリモートサービスに常駐してもよい。コンテンツマネージャ１６３５は、ユーザインタフェース１６８５上での提示のためにクライアント１６１０に提供されるべきコンテンツアイテム１７７０を特定するために、要求１７６５を解析してもよい。いくつかの実施形態では、コンテンツマネージャ１６３５は、要求１７６５内の識別子を使用して、データベース１６１５にアクセスし、識別子によって参照されるコンテンツアイテム１７７０を検索、フェッチ又は特定し得る。コンテンツアイテム１７７０は、視覚又は音声媒体の情報であってもよく、画像、動画、音声又はユーザインタフェース１６８５上に提示される他の任意のオブジェクトを含んでもよい。例えば、コンテンツアイテム１７７０は、呼び出されたＦＳＭ１７０５に関連するルーチンのためのフィットネスエクササイズと併せて再生される音声を含んでもよい。特定により、コンテンツマネージャ１６３５は、コンテンツアイテム１７７０をクライアント１６１０に送信、返却又は他の方法で提供し得る。
【0133】
レイアウトハンドラ１６７０は、次に、アプリケーション構成サービス１６０５（又はリモートサービス）からコンテンツアイテム１７７０を検索、特定又は受信することができる。受信すると、レイアウトハンドラ１６７０は、コンテンツアイテム１７７０をユーザインタフェース１６８５に挿入、追加又は他の方法で含めることができる。レイアウトハンドラ１６７０は、ＦＳＭ１７０５からの出力１７４５で指定されるように、提示のために、コンテンツアイテム１７７０を１つ又は複数のユーザインタフェース要素１６９０に含めることができる。同時に、レイアウトハンドラ１６７０は、出力１７４５に従って、ユーザインタフェース１６８５のユーザインタフェース要素１６９０を修正し得る。例えば、レイアウトハンドラ１６７０は、ユーザインタフェース要素１６９０をインスタンス化し、個々のユーザインタフェース要素１６９０自体の色及び他の視覚特性を設定し、個々のユーザインタフェース要素１６９０内のテキストのフォント及びサイズを設定し、またクライアント１６１０のディスプレイ内のユーザインタフェース要素１６９０の配置を割り当ててもよい。いくつかの実施形態では、レイアウトハンドラ１６７０は、イベントバス１６７５を介して、コンテンツアイテム１７７０のプレゼンテーションの指示を、呼び出されたＦＳＭ１７０５に提供することができる。
【0134】
いくつかの実施形態では、レイアウトハンドラ１６７０は、ＦＳＭ１７０５によって指定された出力１７４５を使用して、レンダリング命令を生成又は決定し得る。出力１７４５は、ユーザインタフェース１６８５に含まれるべき個別のユーザインタフェース要素１６９０に対応する命令のセット（例えば、オリジナル又は下位レベルのフォーマット）を特定してもよい。レンダリング命令は、ディスプレイリスト又はレンダリングツリーの形式であってもよい。特定されると、レイアウトハンドラ１６７０は、ユーザインタフェース要素１６９０のセットに対応する出力１７４５内の命令を解析することができる。各命令に対して、レイアウトハンドラ１６７０は、レンダリング命令に含めるために同等のエントリ（例えば、レンダリングツリーノード）を生成してもよい。生成と共に、レイアウトハンドラ１６７０は、レンダリング命令に従って、ユーザインタフェース１６８５のためのユーザインタフェース要素１６９０を提示し得る。
【0135】
連動して、ビヘイビアマネージャ１６６５は、少なくとも１つの記録エントリ１７７５をアプリケーション構成サービス１６０５（又は別のリモートサービス）に送信、伝送又は提供してもよい。１つ又は複数のイベント１７３５を検出すると、ビヘイビアマネージャ１６６５は、記録エントリ１７７５を書き込むか、或いは生成することができる。記録エントリ１７７５は、アプリケーション１６５０においてプラグイン１６８０上で実行されていることに関する様々な情報を特定又は含むことができる。いくつかの実施形態において、記録１７７５は、アプリケーション１６５０のユーザインタフェース要素１６９０を介して検出されたイベント１７３５に関連付けられたユーザアクションを特定してもよい。例えば、特に、記録エントリ１７７５は、プラグイン１６８０内の各ＦＳＭ１７０５の現在の状態１７１０、ＦＳＭｓ１７０５においてユーザ１７４０のために完了したルーチン又は残っているルーチン、検出されたイベント１７３５、各イベント１７３５のタイプ、各イベント１７３５が検出された時間に対応するタイムスタンプ、ユーザ１７４０の識別子、クライアント１６１０の識別子、アプリケーション１６５０のインスタンスの識別子などを特定してもよい。生成により、ビヘイビアマネージャ１６６５は、記録エントリ１７７５をアプリケーション構成サービス１６０５に送信することができる。
【0136】
アプリケーション構成サービス１６０５上で実行される分析評価器１６４０は、次に、クライアント１６１０から記録エントリ１７７５を検索、特定又は他の方法で受信することができる。受信すると、分析評価器１６４０は、データベース１６１５上に保持されるログ記録１７８０に記録エントリ１７７５を追加及び含むことができる。ログ記録１７８０は、様々なクライアント１６１０から受信された記録エントリ１７７５を追跡し、維持することができる。いくつかの実施形態では、ログ記録１７８０は、リレーショナル、オブジェクト指向又はオブジェクトリレーショナルＤＢＭＳなどのデータベース管理システム（ＤＢＭＳ）に従って維持されてもよい。ログ記録１７８０に維持される記録エントリ１７７５を使用して、新しいプラグイン１６８０が構成されてもよく、或いは構成ファイル１６４５が開発者によって修正されてもよい。
【0137】
ここで、図１８Ａを参照すると、アプリケーション上で有限状態機械（ＦＳＭ）を構成する方法１８００のフロー図が描かれている。方法１８００は、図１６から１７Ｂ又は１９に関連して本明細書で詳細に説明したような任意のコンポーネントを使用して実装することができる。図１６から１７Ｂ又は１９を参照されたい。方法１８００の下で、サービスは、有限状態機械の構成ファイルを特定することができる（１８０５）。サービスは、構成ファイルを使用して機械読み取り可能な命令を生成してもよい（１８１０）。サービスは、アプリケーションに追加する機械読み取り可能な命令を提供する（１８１５）。
【0138】
ここで図１８Ｂを参照すると、アプリケーション上で有限状態機械（ＦＳＭ）を処理する方法１８５０のフロー図が描かれている。方法１８５０は、図１６から１７Ｂ又は１９に関連して本明細書で詳細に説明したような任意のコンポーネントを使用して実装することができる。図１６から図１７Ｂ又は図１９に関連して本明細書で詳述したようなコンポーネントを使用して、方法１８５０を実装することができる。方法１８５０の下で、クライアントは、有限状態機械の命令を特定することができる（１８５５）。クライアントは、ユーザインタラクションを監視してもよい（１８６０）。クライアントは、検出されたインタラクションが有限状態機械の現在の状態の条件を満たすか否かを判定してもよい（１８６５）。対話が有限状態機械の現在の状態の条件を満たす場合、クライアントは有限状態機械を呼び出し得る（１８７０）。クライアントは、有限状態機械に従ってレイアウトを更新してもよい（１８７５）。
【0139】
（Ｄ．ネットワークとコンピューティング環境）
本明細書で説明する様々な動作は、コンピュータシステム上で実施することができる。図１９は、本開示の特定の実施形態を実装するために使用可能な、代表的なサーバシステム１９００、クライアントコンピュータシステム１９１４及びネットワーク１９２６の簡略化されたブロック図である。様々な実施形態において、サーバシステム１９００又は同様のシステムは、本明細書に記載されるサービス又はサーバ又はその一部を実装することができる。クライアントコンピュータシステム１９１４又は同様のシステムは、本明細書に記載のクライアントを実装することができる。本明細書で説明するシステム２３００、２８００及び３３００は、サーバシステム１９００に類似し得る。サーバシステム１９００は、多数のモジュール１９０２（例えば、ブレードサーバの実施形態におけるブレード）を組み込んだモジュール設計を有することができ、２つのモジュール１９０２が示されているが、任意の数を提供することができる。各モジュール１９０２は、処理ユニット１９０４及びローカルストレージ１９０６を含むことができる。
本明細書で説明する様々な動作は、コンピュータシステム上で実施することができる。図１９は、本開示の特定の実施形態を実装するために使用可能な、代表的なサーバシステム１９００、クライアントコンピュータシステム１９１４及びネットワーク１９２６の簡略化されたブロック図である。様々な実施形態において、サーバシステム１９００又は同様のシステムは、本明細書に記載されるサービス又はサーバ又はその一部を実装することができる。クライアントコンピュータシステム１９１４又は同様のシステムは、本明細書に記載のクライアントを実装することができる。本明細書で説明するシステム２３００、２８００及び３３００は、サーバシステム１９００に類似し得る。サーバシステム１９００は、多数のモジュール１９０２（例えば、ブレードサーバの実施形態におけるブレード）を組み込んだモジュール設計を有することができ、２つのモジュール１９０２が示されているが、任意の数を提供することができる。各モジュール１９０２は、処理ユニット１９０４及びローカルストレージ１９０６を含むことができる。
【0140】
処理ユニット１９０４は、１つ又は複数のコアを有することができる単一のプロセッサ又は複数のプロセッサを含むことができる。いくつかの実施形態において、処理ユニット１９０４は、汎用プライマリプロセッサ、及びグラフィックスプロセッサ、デジタル信号プロセッサなどの１つ又は複数の特殊用途コプロセッサを含むことができる。いくつかの実施形態では、いくつかの又はすべての処理ユニット１９０４は、特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのカスタマイズ回路を使用して実装され得る。いくつかの実施形態では、そのような集積回路は、回路自体に記憶された命令を実行する。他の実施形態では、処理ユニット１９０４は、ローカルストレージ１９０６に記憶された命令を実行することができる。任意の組み合わせの任意のタイプのプロセッサを処理ユニット１９０４に含めることができる。
【0141】
ローカルストレージ１９０６は、揮発性記憶媒体（例えば、ＤＲＡＭ、ＳＲＡＭ、ＳＤＲＡＭなど）及び／又は不揮発性記憶媒体（例えば、磁気ディスク又は光ディスク、フラッシュメモリなど）を含むことができる。ローカルストレージ１９０６に組み込まれる記憶媒体は、所望に応じて、固定、取り外し可能又はアップグレード可能とすることができる。ローカルストレージ１９０６は、システムメモリ、読み出し専用メモリ（ＲＯＭ）及び永久記憶装置などの様々なサブユニットに物理的又は論理的に分割することができる。システムメモリは、読み書き可能なメモリデバイス又はダイナミックランダムアクセスメモリなどの揮発性読み書き可能メモリとすることができる。システムメモリは、処理ユニット１９０４が実行時に必要とする命令及びデータの一部又は全部を記憶することができる。ＲＯＭは、処理ユニット１９０４が必要とする静的データ及び命令を記憶することができる。永久記憶装置は、モジュール１９０２がパワーダウンしているときでも命令及びデータを記憶することができる不揮発性読み書きメモリ装置とすることができる。本明細書で使用する「記憶媒体」という用語は、（上書き、電気的妨害、電力損失などを対象として）データを無期限に記憶することができる任意の媒体を含み、無線又は有線接続を介して伝播する搬送波及び一過性の電子信号を含まない。
【0142】
いくつかの実施形態では、ローカルストレージ１９０６は、オペレーティングシステム及び／又はシステム２３００、２８００及び３３００或いは本明細書に記載される任意の他のシステムの機能などの様々なサーバ機能を実装するプログラム、或いはシステム２３００、２８００及び３３００、或いは本明細書に記載される任意の他のシステムに関連する任意の他のサーバなど、処理ユニット１９０４によって実行される１つ又は複数のソフトウェアプログラムを格納することができる。
【0143】
「ソフトウェア」とは、一般に処理ユニット１９０４によって実行されると、サーバシステム１９００（又はその一部）に様々な動作を実行させる命令のシーケンスを指し、したがって、ソフトウェアプログラムの動作を実行（ｅｘｅｃｕｔｅ）及び実行（ｐｅｒｆｏｒｍ）する１つ又は複数の特定の機械の実施形態を定義する。命令は、読み取り専用メモリに常駐するファームウェア及び／又は処理ユニット１９０４による実行のために揮発性作業メモリに読み取ることができる不揮発性記憶媒体に記憶されたプログラムコードとして記憶することができる。ソフトウェアは、単一のプログラム又は所望のように相互作用する別個のプログラム又はプログラムモジュールの集合として実装することができる。ローカルストレージ１９０６（又は後述する非ローカルストレージ）から、処理ユニット１９０４は、上述した様々な動作を実行するために、実行するプログラム命令及び処理するデータを取り出すことができる。
【0144】
一部のサーバシステム１９００では、複数のモジュール１９０２を、バス又は他の相互接続１９０８を介して相互接続し、モジュール１９０２とサーバシステム１９００の他のコンポーネントとの間の通信をサポートするローカルエリアネットワークを形成することができる。相互接続１９０８は、サーバラック、ハブ、ルータなどを含む様々な技術を使用して実装することができる。
【0145】
広域ネットワーク（ＷＡＮ）インタフェース１９１０は、ローカルエリアネットワーク（相互接続１９０８）及びインターネットなどのネットワーク１９２６との間のデータ通信機能を提供することができる。有線技術（例えば、イーサネット、ＩＥＥＥ８０２．３規格）及び／又は無線技術（例えば、Ｗｉ－Ｆｉ、ＩＥＥＥ８０２．１１規格）を含む技術を使用することができる。
【0146】
いくつかの実施形態では、ローカルストレージ１９０６は、処理ユニット１９０４にワーキングメモリを提供し、相互接続１９０８上のトラフィックを低減しながら、処理されるプログラム及び／又はデータへの高速アクセスを提供することを意図している。より大量のデータのためのストレージは、相互接続１９０８に接続され得る１つ又は複数のマスストレージサブシステム１９１２によって、ローカルエリアネットワーク上で提供され得る。マスストレージサブシステム１９１２は、磁気、光学、半導体又は他のデータ記憶媒体に基づくことができる。ダイレクトアタッチドストレージ、ストレージエリアネットワーク、ネットワークアタッチドストレージなどを使用することができる。サービス又はサーバによって生成、消費又は維持されるものとして本明細書で説明されるデータの任意のデータストア又は他のコレクションは、マスストレージサブシステム１９１２に記憶され得る。いくつかの実施形態では、追加のデータストレージリソースは、ＷＡＮインタフェース１９１０を介してアクセスすることができる（待ち時間が増加する可能性がある）。
【0147】
サーバシステム１９００は、ＷＡＮインタフェース１９１０を介して受信した要求に応答して動作することができる。例えば、モジュール１９０２の一つが監視機能を実装し、受信した要求に応答して、他のモジュール１９０２に個別のタスクを割り当てることができる。作業割当技術を使用し得る。要求が処理されると、結果はＷＡＮインタフェース１９１０を介して要求者に返される。このような操作は、一般に自動化できる。さらに、いくつかの実施形態では、ＷＡＮインタフェース１９１０は、複数のサーバシステム１９００を互いに接続することができ、大量のアクティビティを管理できるスケーラブルなシステムを提供する。サーバシステム及びサーバファーム（協働するサーバシステムの集合）を管理するための他の技術を使用することができ、これには動的なリソース割り当て及び再割り当てが含まれる。
【0148】
サーバシステム１９００は、インターネットなどの広域ネットワークを介して、様々なユーザ所有又はユーザ操作デバイスと相互作用することができる。ユーザが操作するデバイスの一例が、図１９にクライアントコンピューティングシステム１９１４として示されている。クライアントコンピューティングシステム１９１４は、例えば、スマートフォン、他の携帯電話、タブレットコンピュータ、ウェアラブルコンピューティングデバイス（例えば、スマートウォッチ、眼鏡）、デスクトップコンピュータ、ラップトップコンピュータなどの消費者デバイスとして実装することができる。
【0149】
例えば、クライアントコンピューティングシステム１９１４は、ＷＡＮインタフェース１９１０を介して通信することができる。クライアントコンピューティングシステム１９１４は、処理ユニット１９１６、ストレージ１９１８、ネットワークインタフェース１９２０、ユーザ入力デバイス１９２２及びユーザ出力デバイス１９２４などのコンピュータコンポーネントを含むことができる。クライアントコンピューティングシステム１９１４は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、他のモバイルコンピューティングデバイス、ウェアラブルコンピューティングデバイスなど、様々なフォームファクタで実装されるコンピューティングデバイスであり得る。
【0150】
プロセッサ１９１６及びストレージ１９１８は、上述した処理ユニット１９０４及びローカルストレージ１９０６と同様とすることができる。適切なデバイスは、クライアントコンピューティングシステム１９１４に配置される要求に基づいて選択され得る。例えば、クライアントコンピューティングシステム１９１４は、限られた処理能力を有する「シン（thin）」クライアントとして、或いは高出力のコンピューティングデバイスとして実装され得る。クライアントコンピューティングシステム１９１４は、サーバシステム１９００との様々な相互作用を可能にするために、処理ユニット１９１６によって実行可能なプログラムコードを備えることができる。
【0151】
ネットワークインタフェース１９２０は、サーバシステム１９００のＷＡＮインタフェース１９１０も接続されている広域ネットワーク（例えば、インターネット）などのネットワーク１９２６への接続を提供することができる。様々な実施形態において、ネットワークインタフェース１９２０は、有線インタフェース（例えば、イーサネット）及び／又はＷｉ－Ｆｉ、ブルートゥース（登録商標）、又はセルラーデータネットワーク規格（例えば、３Ｇ、４Ｇ、ＬＴＥなど）などの様々なＲＦデータ通信規格を実装する無線インタフェースを含むことができる。
【0152】
ユーザ入力デバイス１９２２は、ユーザがクライアントコンピューティングシステム１９１４に信号を提供することができる任意のデバイス（又は複数のデバイス）を含むことができ、クライアントコンピューティングシステム１９１４は、特定のユーザ要求又は情報を示すものとして信号を解釈することができる。様々な実施形態において、ユーザ入力デバイス１９２２は、キーボード、タッチパッド、タッチスクリーン、マウス又は他のポインティングデバイス、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、マイクロフォンなどのいずれか又は全てを含むことができる。
【0153】
ユーザ出力デバイス１９２４は、クライアントコンピューティングシステム１９１４がユーザに情報を提供することができる任意のデバイスを含むことができる。例えば、ユーザ出力デバイス１９２４は、クライアントコンピューティングシステム１９１４によって生成された、或いは配信された画像を表示するディスプレイを含むことができる。ディスプレイは、様々な画像生成技術、例えば、液晶ディスプレイ（ＬＣＤ）、有機発光ダイオード（ＯＬＥＤ）を含む発光ダイオード（ＬＥＤ）、投影システム、陰極線管（ＣＲＴ）などを、サポートする電子機器（例えば、デジタルアナログ又はアナログデジタルコンバータ、信号プロセッサなど）とともに組み込むことができる。いくつかの実施形態は、入力及び出力デバイスの両方として機能するタッチスクリーンなどのデバイスを含むことができる。いくつかの実施形態では、ディスプレイに加えて、又は代わりに、他のユーザ出力デバイス１９２４を提供することができる。例えば、表示灯、スピーカ、触覚「表示」デバイス、プリンタなどが挙げられる。
【0154】
いくつかの実施形態は、コンピュータが読み取り可能な記憶媒体にコンピュータプログラム命令を格納するマイクロプロセッサ、ストレージ、メモリなどの電子部品を含む。本明細書で説明する特徴の多くは、コンピュータが読み取り可能な記憶媒体にエンコードされたプログラム命令のセットとして指定されるプロセスとして実装することができる。これらのプログラム命令が１つ又は複数の処理ユニットによって実行されると、プログラム命令で示される様々な処理を処理ユニットに実行させる。プログラム命令又はコンピュータコードの例としては、コンパイラによって生成されるようなマシンコード及びインタプリタを使用してコンピュータ、電子部品又はマイクロプロセッサによって実行される高レベルコードを含むファイルがある。適切なプログラミングによって、処理ユニット１９０４及び１９１６は、サーバ又はクライアントによって実行されるものとして本明細書で説明される機能性のいずれか又は他の機能性を含む、サーバシステム１９００及びクライアントコンピューティングシステム１９１４のための様々な機能性を提供することができる。
【0155】
サーバシステム１９００及びクライアントコンピューティングシステム１９１４は例示であり、変化及び修正が可能であることが理解されるであろう。本開示の実施形態に関連して使用されるコンピュータシステムは、ここで具体的に説明されていない他の能力を有することができる。さらに、サーバシステム１９００及びクライアントコンピューティングシステム１９１４は、特定のブロックを参照して説明されているが、これらのブロックは、説明の便宜のために定義されており、構成部品の特定の物理的配置を意味することを意図していないことを理解されたい。例えば、異なるブロックは、同じ施設内、同じサーバラック内又は同じマザーボード上に配置することができるが、配置する必要はない。さらに、ブロックは物理的に異なるコンポーネントに対応する必要はない。ブロックは、例えば、プロセッサをプログラミングするか、或いは適切な制御回路を提供することによって、様々な動作を実行するように構成することができ、様々なブロックは、初期構成がどのように取得されるかに応じて再構成可能である場合と、そうでない場合がある。本開示の実施形態は、回路及びソフトウェアの任意の組み合わせを使用して実装される電子デバイスを含む様々な装置で実現することができる。
【0156】
本開示を特定の実施形態に関して説明してきたが、当業者であれば、多数の変更が可能であることを認識するであろう。本開示の実施形態は、本明細書で説明する具体例に限定されないが、様々なコンピュータシステム及び通信技術を使用して実現することができる。本開示の実施形態は、専用コンポーネント及び／又はプログラマブルプロセッサ及び／又は他のプログラマブルデバイスの任意の組み合わせを用いて実現することができる。本明細書で説明する様々な処理は、同じプロセッサ又は異なるプロセッサ上で任意の組み合わせで実装することができる。コンポーネントが特定の動作を実行するように構成されていると説明されている場合、そのような構成は、例えば、動作を実行するように電子回路を設計することによって、動作を実行するようにプログラマブル電子回路（マイクロプロセッサなど）をプログラミングすることによって、或いはそれらの任意の組み合わせによって、実現することができる。さらに、上述した実施形態は、特定のハードウェア及びソフトウェアコンポーネントに言及し得るが、当業者であれば、ハードウェア及び／又はソフトウェアコンポーネントの異なる組み合わせも使用され得ること、且つハードウェアで実施されるとして説明した特定の動作がソフトウェアでも実施され得ること、或いはその逆もあり得ることを理解されるであろう。
【0157】
本開示の様々な特徴を組み込んだコンピュータプログラムは、エンコードされて様々なコンピュータが読み取り可能な記憶媒体に記憶されてもよい。好適な媒体には、磁気ディスク又はテープ、コンパクトディスク（ＣＤ）又はデジタル多用途ディスク（ＤＶＤ）などの光記憶媒体、フラッシュメモリ及び他の非一過性の媒体が含まれる。プログラムコードでエンコードされたコンピュータが読み取り可能な媒体は、互換性のある電子機器と一緒にパッケージされてもよいし、プログラムコードが電子機器とは別に（例えば、インターネットダウンロードを介して、或いは別個にパッケージされたコンピュータが読み取り可能な記憶媒体として）提供されてもよい。
【0158】
したがって、本開示は、特定の実施形態に関して説明されてきたが、本開示は、以下の特許請求の範囲の範囲内のすべての変更及び均等物を網羅することを意図されていることが理解されるであろう。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17A】
【図17B】
【図17C】
【図18】
【図19】
【国際調査報告】