(57)【要約】  分散サービス層トランザクション（ＤＳＬＴ）を、通信ネットワークのサービス層でＤＳＬＴサービスによってサポートして、ＤＳＬＴ処理を管理するアプリケーションの負担を軽減することができる。
2020514912.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサおよびメモリを備える装置であって、
前記装置は、
前記装置の前記プロセッサによって実行されると、
前記装置に通信ネットワークの第１サービス層エンティティを実行させ、
前記第１サービス層エンティティに、
前記通信ネットワーク上で実行されるアプリケーションから、分散トランザクションのリクエストであって、前記通信ネットワークの複数の他のサービス層エンティティによってホストされているターゲットリソースのセットで原子的に実行されるコマンドを規定するリクエストを受信し、
前記複数の他のサービス層エンティティのそれぞれに、該他のサービス層エンティティによってホストされているターゲットリソースのいずれかをロックするようにリクエストを送信し、
前記複数の他のサービス層エンティティのそれぞれから、該サービス層エンティティが該サービス層エンティティによってホストされている前記ターゲットリソースをロックできたかどうかを示す応答を受信し、
前記複数の他のサービス層エンティティが前記ターゲットリソースのセットをロックできたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記ターゲットリソースのセットで前記コマンドの原子的実行を実施するようにリクエストを送信し、
前記複数の他のサービス層エンティティから、前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答を受信し、
前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記分散トランザクションをコミットするようにリクエストを送信し、
前記アプリケーションに前記分散トランザクションが正常に実施されたことを示す応答を送信する、
各手順を実行させる、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備える装置。
【請求項２】
前記コンピュータ実行可能命令はさらに、前記アプリケーションから前記分散トランザクションの前記リクエストを受信すると、前記第１サービス層エンティティの前記メモリ内に、前記分散トランザクションを表し、かつ前記分散トランザクションの状態に関する情報を含むリソースを前記第１サービス層エンティティに生成させ、
前記リソースは、前記アプリケーションが前記通信ネットワークを介してアクセス可能なものである、請求項１に記載の装置。
【請求項３】
前記リソースは、前記トランザクションを一意に識別するトランザクション識別子属性と、前記分散トランザクションの前記状態に関する前記情報が保存されているトランザクション状態属性とを含む、請求項２に記載の装置。
【請求項４】
前記リソースは、前記第１サービス層エンティティが前記分散トランザクションの前記リクエストの処理をいつ開始するかを制御する実行時間属性を含む、請求項２に記載の装置。
【請求項５】
前記装置は、前記通信ネットワークのサーバまたはゲートウェイのうち１つを含む、請求項１に記載の装置。
【請求項６】
前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、前記リクエストの処理に関するルールを定義するポリシーに従って前記分散トランザクションの前記リクエストを処理させる、請求項１に記載の装置。
【請求項７】
前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、前記分散トランザクションの前記リクエストの前記処理をスケジュールさせる、請求項１に記載の装置。
【請求項８】
前記分散トランザクションの前記リクエストは、リクエストのシーケンスの一部である、請求項１に記載の装置。
【請求項９】
前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、前記コマンドの前記実行に対する制約を示す基準を前記複数の他のサービス層エンティティへ送信させる、請求項１に記載の装置。
【請求項１０】
前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、リクエストされた前記分散トランザクションの優先順位の割り当てをさせる、請求項１に記載の装置。
【請求項１１】
通信ネットワークの第１サービス層エンティティが、前記通信ネットワークで実行されるアプリケーションから、分散トランザクションのリクエストであって、前記通信ネットワークの複数の他のサービス層エンティティによってホストされているターゲットリソースのセットで原子的に実行されるコマンドを規定するリクエストを受信することと、
前記複数の他のサービス層エンティティのそれぞれに、該他のサービス層エンティティによってホストされているターゲットリソースのいずれかをロックするようにリクエストを前記第１サービス層エンティティが送信することと、
前記複数のサービス層エンティティのそれぞれから、該サービス層エンティティが該サービス層エンティティによってホストされている前記ターゲットリソースをロックできたかどうかを示す応答を前記第１サービス層エンティティが受信することと、
前記複数の他のサービス層エンティティが前記ターゲットのセットをロックできたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記ターゲットリソースのセットで前記コマンドの原子的実行を実施するようにリクエストを前記第１サービス層エンティティが送信することと、
前記複数の他のサービス層エンティティから、前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答を前記第１サービス層エンティティが受信することと、
前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記分散トランザクションをコミットするようにリクエストを前記第１サービス層エンティティが送信することと、
前記アプリケーションに前記分散トランザクションが正常に実施されたことを示す応答を送信することと
を含む方法。
【請求項１２】
前記アプリケーションから前記分散トランザクションの前記リクエストを受信すると、前記分散トランザクションを表し、かつ前記分散トランザクションの状態に関する情報を含むリソースを前記第１サービス層エンティティが生成することをさらに含み、前記リソースは、前記アプリケーションが前記通信ネットワークを介してアクセス可能なものである、請求項１１に記載の方法。
【請求項１３】
前記リソースは、前記トランザクションを一意に識別するトランザクション識別子属性と、前記分散トランザクションの前記状態に関する前記情報が保存されているトランザクション状態属性とを含む、請求項１２に記載の方法。
【請求項１４】
前記リソースは、前記第１サービス層エンティティが前記分散トランザクションの前記リクエストの処理をいつ開始するかを制御する実行時間属性を含む、請求項１２に記載の方法。
【請求項１５】
前記第１サービス層エンティティは、前記通信ネットワークのサーバまたはゲートウェイのうち１つに実装される、請求項１１に記載の方法。
【請求項１６】
前記リクエストの処理に関するルールを定義するポリシーに従って、前記分散トランザクションの前記リクエストを処理することをさらに含む、請求項１１に記載の方法。
【請求項１７】
前記分散トランザクションの前記リクエストの前記処理のスケジューリングをさらに含む、請求項１１に記載の方法。
【請求項１８】
前記分散トランザクションの前記リクエストは、リクエストのシーケンスの一部である、請求項１１に記載の方法。
【請求項１９】
前記複数の他のサービス層エンティティに、前記コマンドの前記実行に対する制約を示す基準を送信することをさらに含む、請求項１１に記載の方法。
【請求項２０】
リクエストされた前記分散トランザクションに優先順位を割り当てることをさらに含む、請求項１１に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
（関連出願の相互参照）
本出願は、２０１７年３月１７日に出願された「ＩｏＴ（Internet  of  Things）サービス層における分散トランザクション管理を可能にする方法」と題する米国仮出願第６２／４７２，８５１号の利益を主張するものであり、その内容はその全体が参照により本明細書に組み込まれる。
【０００２】
（背景）
トランザクションは、ユニットとして実行される必要のある、操作のセット、または操作のシーケンスである場合がある。操作のセットは、（例えば、機能上の理由またはビジネス上の理由により）密接に関係する場合があり、またユニットとして各操作の全てが正常に実行されるか、または該各操作のいずれも実行されないかのどちらか一方である必要がある。トランザクションは、原子性、一貫性、独立性、および耐久性（Atomicity,  Consistency,  Isolation  and  Durability：ＡＣＩＤ）の４つの特性を有する場合がある。原子性とは、トランザクションにリクエストまたはステップがいくつ含まれても、それらが単一のリクエストであるかのように実行される必要があることを意味する。それらは全てが正常に実行されるか、または全く実行されない必要がある。部分的な実行は許容されない。一貫性とは、トランザクションの実行前と実行後とで、トランザクションのターゲットの状態が一貫していなければならないことを意味する。一貫性は、原子性と密接に関係している。独立性とは、各トランザクションが互いに独立している必要があり、互いに干渉できないことを意味する。耐久性とは、一旦トランザクションがコミットされると、システムはトランザクションの結果が安全で耐久性のあるものであることを保証する必要があることを意味する。結果は、突然の誤動作に耐え得るものであり、回復後の結果に回復できるものである。近年、マシンツーマシン（Machine-To-Machine：Ｍ２Ｍ）ネットワークまたはＩｏＴ（Internet  of  Things）ネットワークのコンテキストにおけるトランザクション処理に取り組む努力がなされている。
【発明の概要】
【課題を解決するための手段】
【０００３】
通信ネットワークのサービス層での分散トランザクション処理のサポートを提供するための方法、装置、およびシステムを本明細書にて開示する。方法、装置およびシステムは、ＤＳＬＴの処理をそれら自体で管理しなければならないというアプリケーションの複雑さおよび負担を軽減するために、分散サービス層トランザクション（Distributed  Service  Layer  Transaction：ＤＳＬＴ）処理性能をサポートするＤＳＬＴサービスで具現化することができる。ＤＳＬＴ処理性能は、アプリケーションに代わってＤＳＬＴの原子的処理を管理するＤＳＬＴサービス性能と、アプリケーションに代わってＤＳＬＴシーケンスの原子的処理を管理するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを構成する個々のリクエストのスケジューリングを調整するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの実行基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの再伝送ポリシーをアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの完了基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの優先順位をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを開始するためのシンプルなＲＥＳＴｆｕｌアプリケーションプログラミングインターフェース（Application  Programming  Interface：ＡＰＩ）をアプリケーションに提供するＤＳＬＴサービス性能とを含んでよい。
【０００４】
一態様では、ＤＳＬＴサービスを実装する通信ネットワークの第１サービス層エンティティは、通信ネットワーク上で実行されるアプリケーションから分散トランザクションのリクエストを受信してよい。リクエストは、該通信ネットワークの複数の他のサービス層エンティティによってホストされているターゲットリソースのセットで原子的に実行されるコマンドを規定してよい。リクエストに応答して、第１サービス層エンティティは、複数の他のサービス層エンティティのそれぞれに、該他のサービス層エンティティによってホストされているターゲットリソースのいずれかをロックするようにリクエストを送信してよい。次いで、第１サービス層エンティティは、複数の他のサービス層エンティティのそれぞれから、該サービス層エンティティがそのサービス層エンティティによってホストされているターゲットリソースをロックできたかどうかを示す応答を受信してよい。第１サービス層エンティティが、ターゲットリソースの全てがロックされたことを示す応答を受信する場合、第１サービス層エンティティは、ターゲットリソースのセットでコマンドの原子的実行を実施するように、複数の他のサービス層エンティティにリクエストを送信してよい。第１サービス層エンティティが、コマンドがターゲットリソースのセットで正常に実行されたことを示す応答を受信する場合、第１サービス層エンティティは、分散トランザクションをコミットするように、複数の他のサービス層エンティティにリクエストを送信してよい。次に、第１サービス層エンティティは、アプリケーションに分散トランザクションが正常に実施されたことを示す応答を送信してよい。
【０００５】
別の態様では、第１サービス層エンティティは、アプリケーションから分散トランザクションのリクエストを受信すると、第１サービス層エンティティのメモリ内に、分散トランザクションを表し、かつ分散トランザクションの状態に関する情報を含むリソースを生成してもよい。当該リソースは、アプリケーションがトランザクションのステータスを監視できるように、アプリケーションが通信ネットワークを介してアクセス可能なものであってよい。当該リソースは、トランザクションを一意に識別するトランザクション識別子属性と、分散トランザクションの状態に関する情報が保存されているトランザクション状態属性を含んでよい。当該リソースは、第１サービス層エンティティが分散トランザクションのリクエストの処理をいつ開始するかを制御する実行時間属性をさらに含んでもよい。
【０００６】
本概要は、一部の概念を簡単に紹介するものであり、詳しくは以下の詳細な説明で説明する。本概要は、請求の範囲に記載される主題の主要な特徴または実質的な特徴を特定することも、請求の範囲に記載される主題の範囲を限定するために使用されることも意図していない。さらに、請求の範囲に記載される主題は、本開示のいずれかの部分に記載される、不利点の一部またはすべてを解決する限定事項にも限定されない。
【図面の簡単な説明】
【０００７】
添付図面と併せて例として挙げられる以下の説明からより詳細な理解を得ることが可能である。
【０００８】
【図１】図１は、サービス層をサポートする例示的プロトコルスタックを示す図である。
【図２】図２は、様々な種類のネットワークノードに展開されるＭ２Ｍ／ＩｏＴサービス層（Service  Layer：ＳＬ）を示す図である。
【図３】図３は、ｏｎｅＭ２Ｍアーキテクチャを示す図である。
【図４】図４は、ｏｎｅＭ２Ｍ共通サービス機能を示す図である。
【図５】図５は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる構成を示す図である。
【図６】図６は、ｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを示す図である。
【図７】図７は、ｏｎｅＭ２Ｍトランザクション処理（成功例）を示す図である。
【図８】図８は、ｏｎｅＭ２Ｍトランザクション処理（失敗例）を示す図である。
【図９】図９は、ＳＬトランザクション管理の有用性を説明するスマートファクトリーユースケースを示す図である。
【図１０】図１０は、分散サービス層トランザクション（ＤＳＬＴ）の最小限のＳＬソリューションを示す図である。
【図１１】図１１は、ＤＳＬＴの完全なＳＬソリューションを示す図である。
【図１２】図１２は、ＤＳＬＴ展開オプションを示す図である。
【図１３】図１３は、分散サービス層トランザクション管理機能（Distributed  Service  Layer  Transaction  Management  Function：ＤＳＬＴ−ＭＦ）を示す図である。
【図１４】図１４は、分散サービス層トランザクションクライアント機能（Distributed  Service  Layer  Transaction  Client  Function：ＤＳＬＴ−ＣＦ）を示す図である。
【図１５】図１５は、個々のＤＳＬＴに対する分散サービス層トランザクショントリガ機能（Distributed  Service  Layer  Transaction  Trigger  Function：ＤＳＬＴ−ＴＦ）の処理を示す図である。
【図１６】図１６は、個々のＤＳＬＴに対するＤＳＬＴ−ＭＦの処理を示す図である。
【図１７】図１７は、個々のＤＳＬＴ−ＣＦに対するＤＳＬＴ−ＣＦの処理を示す図である。
【図１８】図１８は、ＤＳＬＴシーケンスに対するＤＳＬＴ−ＴＦの処理を示す図である。
【図１９】図１９は、ＤＳＬＴシーケンスに対するＤＳＬＴ−ＭＦの処理を示す図である。
【図２０】図２０は、ＤＳＬＴシーケンスに対するＤＳＬＴ−ＣＦの処理を示す図である。
【図２１】図２１は、個々のＤＳＬＴプロシージャを示す図である。
【図２２】図２２は、ＤＳＬＴシーケンスプロシージャを示す図である。
【図２３】図２３は、ｏｎｅＭ２Ｍにおけるトランザクション管理共通サービス機能（Common  Service  Functions：ＣＳＦ）のアーキテクチャの実施形態を示す図である。
【図２４】図２４は、ｏｎｅＭ２ＭリソースのＤＳＬＴ指向属性を示す図である。
【図２５】図２５は、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスリソースを示す図である。
【図２６】図２６は、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースのＤＳＬＴ拡張を示す図である。
【図２７−１】図２７−１は、ｏｎｅＭ２Ｍ  ＤＳＬＴグループファンアウト（ｆａｎｏｕｔ）プロシージャを示す図である。
【図２７−２】図２７−２は、ｏｎｅＭ２Ｍ  ＤＳＬＴグループファンアウト（ｆａｎｏｕｔ）プロシージャを示す図である。
【図２８−１】図２８−１は、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスプロシージャを示す図である。
【図２８−２】図２８−２は、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスプロシージャを示す図である。
【図２９】図２９は、サービス層トランザクションユーザーインターフェースを示す図である。
【図３０Ａ】図３０Ａは、通信ネットワークを含むＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システムを示す図である。
【図３０Ｂ】図３０Ｂは、Ｍ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスならびに通信ネットワークにサービスを提供するフィールドドメインにおけるＭ２Ｍサービス層を示す図である。
【図３０Ｃ】図３０Ｃは、本明細書で記載される論理的エンティティのいずれかを実装するために使用することができる例示的装置を示す図である。
【図３０Ｄ】図３０Ｄは、本明細書で記載される論理的エンティティのいずれかを実装するために使用することができるコンピュータシステムまたはサーバのブロック図である。
【発明を実施するための形態】
【０００９】
以下は、以下の説明に出現する可能性のある頭字語のリストである。特に指示がない限り、本明細書で使用される頭字語は、以下に記載された対応する用語を指す。
ＡＤＮ：Application  Dedicated  Node（アプリケーション専用ノード）
ＡＥ：Application  Entity（アプリケーションエンティティ）
ＡＰＩ：Application  Programming  Interfaces（アプリケーションプログラミングインターフェース）
ＡＳＮ：Application  Service  Node（アプリケーションサービスノード）
ＣＳＥ：Common  Service  Entity（共通サービスエンティティ）
ＣＳＦ：Common  Service  Function（共通サービス機能）
ＤＳＬＴ：Distributed  Service  Layer  Transaction（分散サービス層トランザクション）
ＤＳＬＴ−ＣＦ：Distributed  Service  Layer  Transaction  Client  Function（分散サービス層トランザクションクライアント機能）
ＤＳＬＴ−ＭＦ：Distributed  Service  Layer  Transaction  Management  Function（分散サービス層トランザクション管理機能）
ＤＳＬＴ−ＴＦ：Distributed  Service  Layer  Transaction  Trigger  Function（分散サービス層トランザクショントリガ機能）
ＤＳＬＴ−ＲＥＱ：Distributed  Service  Layer  Transaction  Request（分散サービス層トランザクションリクエスト）
ＤＳＬＴ−ＴＲＩＧＧＥＲ：Distributed  Service  Layer  Transaction  Trigger  Request（分散サービス層トランザクショントリガリクエスト）
ＩＮ：Infrastructure  Network（インフラストラクチャネットワーク）
ＩｏＴ：Internet  of  Things（モノのインターネット）
ＩＰ：Internet  Protocol（インターネットプロトコル）
Ｍ２Ｍ：Machine  to  Machine（マシンツーマシン）
ＭＮ：Middle  Node（ミドルノード）
ＮｏＤＮ：Non-oneM2M  Node（非ｏｎｅＭ２Ｍノード）
ＰｏＡ：Point  of  Access（アクセスポイント）
ＲＯＡ：Resource  Oriented  Architecture（リソース指向アーキテクチャ）
ＳＬ：Service  Layer（サービス層）
ＵＲＩ：Uniform  Resource  Identifier（ユニフォームリソース識別子）
【００１０】
また、以下の用語は、以下の説明で使用される場合があり、特に指示がない限り以下の意味を含んでよい。
【００１１】
Ｍ２Ｍ／ＩｏＴサービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）と下位ネットワークインターフェースとのセットを介してＭ２Ｍ／ＩｏＴアプリケーションおよびデバイス向けに付加価値サービスをサポートするソフトウェアミドルウェア層であってよい。
【００１２】
Ｍ２Ｍ／ＩｏＴアプリケーションは、特定のＭ２Ｍ／ＩｏＴユースケース（例えば、ｅヘルス、スマートエネルギー、ホームオートメーション）を対象とするアプリケーションであってよい。
【００１３】
サービス層エンティティは、Ｍ２Ｍ／ＩｏＴアプリケーション、またはＭ２Ｍ／ＩｏＴサービス層のインスタンスであってよい。
【００１４】
サービス層リソースは、Ｍ２Ｍ／ＩｏＴサービス層によってホストされる一意にアドレス付け可能なオブジェクトであってよい。
【００１５】
サービス層リクエストは、サービス層リソースを対象とするサービス層エンティティによって送出される操作であってよい。
【００１６】
サービス層トランザクションは、全てが正常に実行されるか、またはいずれも実行されない、ユニットとして原子的に実施される必要があるサービス層リクエストのセットまたはシーケンスであってよい。
【００１７】
分散サービス層トランザクションは、異なるネットワークノードでホストされる複数のサービス層エンティティによってホストされるリソースのセットを対象とするサービス層トランザクションであってよい。
【００１８】
分散サービス層トランザクション管理機能は、分散サービス層トランザクションクライアント機能と相互作用でき、かつこれらの機能への分散サービス層トランザクションの原子的な処理を管理できるサービス層機能であってよい。
【００１９】
分散サービス層トランザクションクライアント機能は、分散サービス層トランザクション管理機能と相互作用でき、かつ個々の分散サービス層トランザクションを受信して処理できるサービス層機能であってよい。
【００２０】
分散サービス層トランザクショントリガ機能は、分散サービス層トランザクション管理機能と相互作用でき、かつ分散サービス層トランザクションを開始できるサービス層機能であってよい。
【００２１】
分散サービス層トランザクショントリガリクエストは、分散サービス層トランザクショントリガ機能によって分散サービス層トランザクション管理機能に送信され、分散サービス層トランザクションを開始させるリクエストであってよい。
【００２２】
分散サービス層トランザクションリクエストは、分散サービス層トランザクション管理機能によって分散サービス層トランザクションクライアント機能に配布され、分散サービス層トランザクションを実行させるリクエストであってよい。
【００２３】
Ｍ２Ｍ（Machine-To-Machine）ネットワークまたはＩｏＴ（Internet  of  Things）ネットワークでは、サービス層（ＳＬ）は、特に、Ｍ２Ｍ／ＩｏＴデバイスおよびＭ２Ｍ／ＩｏＴアプリケーション向けに付加価値サービスを提供することを目的とする技術である。近年、いくつかの業界規格団体（例えば、ｏｎｅＭ２Ｍ[oneM2M  TS-0001  oneM2M  Functional  Architecture-V-3.0.0.]、ＥＴＳＩ[ETSI  TS  102  690  Machine-to-Machine  communications  (M2M)  Functional  architecture  V2.0.13.]、ＯＣＦ[OCF  -  OIC  Specifications,  V1.1]、およびＬＷＭ２Ｍ[OMA  LWM2M  Specification,V1.0]）が、インターネット／ウェブ、セルラー、企業内、および家庭内のネットワーク展開へのＭ２Ｍ／ＩｏＴデバイスおよびアプリケーションの統合に関連する課題に対処するためにＭ２Ｍ／ＩｏＴ  ＳＬを開発している。
【００２４】
Ｍ２Ｍ／ＩｏＴサービス層は、アプリケーションおよびデバイスがＭ２Ｍ／ＩｏＴ指向性能群にアクセスできるようにする。いくつかの例としては、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続管理が挙げられる。これらの性能は、Ｍ２Ｍ／ＩｏＴ  ＳＬによってサポートされるメッセージフォーマット、リソース構成およびリソース表現を利用するアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアプリケーションが利用できるものである。
【００２５】
プロトコルスタックの観点から、ＳＬは典型的には、アプリケーションプロトコル層の上位に位置し、サポートしているアプリケーションに付加価値サービスを提供する。それゆえＳＬは、「ミドルウェア」サービスとして分類されることが多い。図１は、アプリケーションプロトコル１０４とアプリケーション１０６との間の例示的なサービス層１０２を示す図である。
【００２６】
展開の観点から、Ｍ２Ｍ／ＩｏＴ  ＳＬ１０２は、図２に示すように、サーバ、ゲートウェイ、およびデバイスを含む様々な種類のネットワークノードで展開され得る。サービス層機能を実装またはサービス層のインスタンスを組み込む通信ネットワークのノード、サーバ、ゲートウェイ、デバイス、装置、または他の論理的エンティティはいずれも、本明細書においてはサービス層エンティティと称する場合がある。
【００２７】
ｏｎｅＭ２Ｍ規格[oneM2M  TS-0001]では、のｅ−ヘルス、フリート管理、およびスマートホームなどの様々な「バーティカル」なＭ２Ｍシステムおよびアプリケーションによって利用することができる「ホリゾンタル」なサービスを提供することを目的とするＭ２Ｍ／ＩｏＴ  ＳＬを定義している。ｏｎｅＭ２Ｍ  ＳＬのアーキテクチャは、図３に示すように、サービス層を採り入れて、４つの参照点をサポートする共通サービスエンティティ（Common  Service  Entity：ＣＳＥ）３０２を画定する。Ｍｃａ参照点は、アプリケーションエンティティ（Application  Entity：ＡＥ）３０４とインターフェースする。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥ３０６とインターフェースし、Ｍｃｃ’参照点は、異なるサービスプロバイダドメインの別のＣＳＥとインターフェースする。Ｍｃｎ参照点は、下位ネットワークサービスエンティティ（Network  Service  Entity：ＮＳＥ）とインターフェースする。ＮＳＥ３０８は、デバイス管理、位置情報サービス、およびデバイストリガ等の下位ネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、「データ管理およびリポジトリ」などの「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含み、これらの機能を合わせてサービス層の機能が構成される。図４はｏｎｅＭ２ＭによってサポートされるＣＳＦを示す図である。通信ネットワークのノード、サーバ、ゲートウェイ、デバイス、装置、またはその他の論理的エンティティでホストされるＣＳＥの各インスタンスは、本明細書においてはネットワークのサービス層エンティティと称する場合がある。
【００２８】
ｏｎｅＭ２Ｍアーキテクチャは、分散型アーキテクチャであり、Ｍ２Ｍ／ＩｏＴサービスを以下の種類のノードにわたって分散して展開することをサポートする。
・アプリケーションサービスノード（ＡＳＮ）
ＡＳＮは、１つのＣＳＥを含み、かつ少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。例えば、ＡＳＮは、Ｍ２Ｍデバイス内に存在し得る。
・アプリケーション専用ノード（ＡＤＮ）
ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。例えば、アプリケーション専用ノードは、制約されたＭ２Ｍデバイス内に存在し得る。
・ミドルノード（ＭＮ）
ＭＮは、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。例えば、ＭＮは、Ｍ２Ｍゲートウェイに存在し得る。
・インフラストラクチャノード（ＩＮ）
ＩＮは、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。ＩＮ内のＣＳＥは、他のノードタイプには適用されないＣＳＥ機能を含む場合がある。例えば、ＩＮは、Ｍ２Ｍサービスインフラストラクチャ内に存在し得る。
・非ｏｎｅＭ２Ｍノード（ＮｏＤＮ）
非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを（ＡＥおよびＣＳＥのいずれも）含まないノードである。このようなノードは、管理を含む相互動作目的のためにｏｎｅＭ２Ｍシステムに接続されたデバイスを意味する。
【００２９】
ｏｎｅＭ２Ｍシステム内でサポートされる種々のエンティティを相互接続する可能な構成を図５に示す。
【００３０】
近年、ｏｎｅＭ２ＭはＳＬトランザクション向けのサポートを規定する取り組みを開始している。この取り組みは、oneM2M  TR-0020,  Study  of  service  transactions  and  re-usable  service  layer  context,  V0.6.0に記載されている。現在までのところ、これまでに１つのソリューションが定義されている。以下はこのソリューションの概要である。
【００３１】
＜ｔｒａｎｓａｃｔｉｏｎ＞リソースは他のいずれかのリソースの子であり得る。これは、親リソースがトランザクションのターゲットであることを意味する。＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの状態に基づいて、ｏｎｅＭ２Ｍプリミティブはターゲットリソースで実行される。＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの構成を図６に示し、その属性を表１で説明する。
【表１】
2020514912.tif 000003
【００３２】
図７および図８は、ｏｎｅＭ２Ｍシステムにおいて、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを使用して、どのようにトランザクションが処理されるかのフローを示す図である。図７は、ｏｎｅＭ２Ｍトランザクション処理の成功例を示す図である。図８は、ｏｎｅＭ２Ｍトランザクション処理の失敗例を示す図である。この処理は、１つのＡＥおよび複数のＣＳＥによって行われる。ＡＥは、複数のＣＳＥにわたるトランザクションの調整を開始および管理する。各ステップの詳細な説明を以下に示す。
【００３３】
図７および図８のステップ１では、ＡＥ７０２は、複数のＣＳＥに＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを生成する。＜ｔｒａｎｓａｃｔｉｏｎ＞は、各ターゲットリソースの子リソースとして生成される。＜ｔｒａｎｓａｃｔｉｏｎ＞リソースは、トランザクションの実行時間、および実行されるプリミティブを含む。トランザクションのコミットが調整されることを保証するために、それぞれのＣＳＥの実行時間は同じである。プリミティブは、発信元の識別情報、操作、および実行されるプリミティブの内容をさらに含む。
【００３４】
図７および図８のステップ２では、＜ｔｒａｎｓａｃｔｉｏｎ＞生成リクエストを受信した各ＣＳＥ７０４、７０６および７０８において、ＣＳＥ７０４、７０６および７０８は、＜ｔｒａｎｓａｃｔｉｏｎ＞を正常に実行できるかどうかをチェックする。このチェックは、アクセス権チェックを含んでよく、プリミティブのフォーマットが適正であるかをチェックし、かつ所定の時間で実行が実施可能であるかをチェックする。
【００３５】
図７のステップ３（成功）では、チェックが成功した場合、ＣＳＥ７０４、７０６および７０８は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースが生成されて、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの親リソースが予約状態になっていることをＡＥ７０２に応答する。予約状態では、リソースは、特定の実行時間でのプリミティブの正常実行に障害をもたらす可能性のある他のいずれのリクエストも拒否する。
【００３６】
図７のステップ４（成功）では、各ＣＳＥ７０４、７０６および７０８は、特定の実行時間に対応するプリミティブを実行する。
【００３７】
図８のステップ３（失敗）では、ＣＳＥでのいずれか（この例では、ＣＳＥ７０８）でチェックが失敗した場合は、ＣＳＥ７０８は、失敗応答でＡＥに応答する。失敗応答を受信した場合、ＡＥ７０２は、全てのＣＳＥにわたってトランザクションが原子的に実施できないと判断する。そのため、ＡＥ７０２は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを正常に生成した各ＣＳＥ（この例では、ＣＳＥ７０４および７０６）に削除リクエストを送信し、スケジュールされた実行時間前に＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを削除する。これによりトランザクションがキャンセルされる。
【００３８】
図８のステップ４（失敗）では、＜ｔｒａｎｓａｃｔｉｏｎ＞を正常に生成したＣＳＥ（この例では、ＣＳＥ７０４および７０６）は、トランザクションを削除する。
【００３９】
以下のユースケースは、Ｍ２Ｍ／ＩｏＴネットワークにおけるトランザクション処理性能の必要性を理解する上で有用である。複数のロボット９０４、９０６および９０８を備える図９の製造組立ライン９０２などのスマートファクトリーユースケースを考察する。これらのロボット９０４、９０６および９０８は、組立ラインによって製造される製品を適切に組み立てるために互いに緊密な同期を維持する必要がある。ロボットの設定のうち１つを修正する場合、通常、ロボットが互いに同調した操作を続けるよう、同じ組立ラインで動作している他のロボットに対しても対応する修正を要する。工場内の全ての組立ラインは、工場のコントロール室に位置する対応する遠隔管理ステーションから、技術者によって監視および制御されている。それぞれの組立ラインのロボットは、これらのステーションから、技術者によって遠隔的に監視および制御することができる。ロボットのメンテナンスを実施するために組立ラインを停止すると著しく費用がかかるので、工場では、停止時間を最小限に抑え、さらに組立ライン稼働中にメンテナンスを実施する方法も模索している。このため、技術者は、ロボットの設定変更を厳密に調整して行う性能を望んでいる。また、技術者は、組立ラインのロボットの動作が特定の正常範囲を逸脱したという検出に基づいてこれらの更新をトリガする性能も望んでいる。これが発生した場合、ロボット９０４、９０６および９０８の設定の構成に対する更新をトリガし、状況が悪化する前に修復することを技術者は望んでいる。そのためには、トリガイベントに基づいてロボットの設定を変更する分散トランザクションを送信する性能が必要である。また、ロボットが同調する動作を維持したまま、組立ラインが停止することなく機能を続行するよう、このトランザクションで複数のロボット９０４、９０６および９０８の設定を原子的に更新させる必要がある。そうすることで、技術者は、全てのロボットが設定を正常に変更できる場合にのみ、ロボット９０４、９０６および９０８の設定が変更されることが保証される。１つまたは複数のロボットが、それらの設定を正常に変更できない場合は、いずれのロボットの設定も変更されない。これにより、組立ラインにおいてロボットが同調して動作しなくなった状態になることを回避できる。技術者は、ロボットに対するこれらの原子的なトランザクションの管理を調整するために複雑なアプリケーションを開発するのではなく、こうしたＩｏＴサービスプラットフォームのトランザクション管理性能の複雑性が軽減されることを望んでいる。
【００４０】
現在までのところ、分散リソースのセットを対象とする原子的なトランザクションを実施することの複雑性および負担は、これらのトランザクションを開始するアプリケーション、および、これらのアプリケーションを構築して導入する開発者の肩に直接的にかかっている。膨大な数の分散デバイスを含む最近のＩｏＴネットワーク展開の大きさと複雑性の増大によって、これらのアプリケーションおよび開発者に与えるこの負担はさらに大きくなっている。このため、最近では、ｏｎｅＭ２ＭなどのＩｏＴ／Ｍ２Ｍサービス層技術により、分散トランザクションの管理によってアプリケーションを支援する必要性が認識されている。
【００４１】
これまでに、分散サービス層トランザクション（ＤＳＬＴ）の管理のために、極めて基本的かつ最小限のＳＬ中心ソリューションのみが規定されている。例えば、ｏｎｅＭ２Ｍ[oneM2M  TR-0020]にて規定されている現行のソリューションは、ＤＳＬＴを管理するために、依然としてアプリケーションに大きく依存している。アプリケーションの役割は、依然として、ＤＳＬＴを構成する個々のリクエストのそれぞれを開始し、個々のターゲットリソースにこれらのリクエストを送信することである。アプリケーションの役割は、依然として、これらの個々のリクエストのそれぞれの進行状況を監視し、それらのいずれかが失敗になるかどうか、およびＤＳＬＴ全体を中止する必要があるかどうかを判断することである。ＤＳＬＴを中止する必要がある場合、アプリケーションは、キャンセルリクエストを送信する必要があるターゲットを追跡しなければならない。アプリケーションの役割は、さらに、ＤＳＬＴの実行時間を追跡し、ＤＳＬＴを構成する個々のリクエストが、実行時間が経過する前に全てキャンセルされるように、このタイマーが満了する前にこれらのキャンセルリクエストの送信が行われることを確実にすることである。したがって、図１０に示すように、ＤＳＬＴを管理するアプリケーションには、大幅なオーバーヘッドおよび負担が依然として存在する。
【００４２】
図１０のステップ１では、アプリケーション１００２は、複数のデバイス１００４、１００６および１００８にトランザクションリクエストを送信する。
【００４３】
図１０のステップ２では、デバイス１００４、１００６および１００８は、トランザクションを正常に実行できるかどうかチェックする。
【００４４】
図１０のステップ３では、デバイス１００４、１００６および１００８は、アプリケーション１００２に応答して、トランザクションを実行できるがどうかを示す。この例では、デバイス１００８はトランザクションを実行することができない。
【００４５】
図１０のステップ４では、デバイスの１つ（デバイス１００８）がトランザクションの実行ができないので、その他のデバイス（デバイス１００４および１００６）でのトランザクションが中止される。
【００４６】
本明細書では、ＤＳＬＴの処理をそれら自体で管理しなければならないというアプリケーションの複雑さおよび負担を軽減するために、ＤＳＬＴ処理性能をサポートする分散サービス層トランザクション（ＤＳＬＴ）サービスを説明する。ＤＳＬＴ処理性能は、アプリケーションに代わってＤＳＬＴの原子的処理を管理するＤＳＬＴサービス性能と、アプリケーションに代わってＤＳＬＴシーケンスの原子的処理を管理するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを構成する個々のリクエストのスケジューリングを調整するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの実行基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの再伝送ポリシーをアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの完了基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの優先順位をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを開始するためのシンプルなＲＥＳＴｆｕｌ  ＡＰＩをアプリケーションに提供するＤＳＬＴサービス性能とを含んでよい。
【００４７】
アプリケーションに代わってＤＳＬＴの原子的処理を管理するＤＳＬＴサービス性能に関しては、サービスは、それ自体が分散可能であり、別々のネットワークノードでホストされる複数のサービス層エンティティにわたって展開可能であるＤＳＬＴ管理機能およびＤＳＬＴクライアント機能で構成されてよい。ＤＳＬＴを開始し、かつＤＳＬＴの処理完了時のサービスからの応答を受信するために、アプリケーションは単一のリクエストをサービスに送信するだけでよい。サービスは、アプリケーションが個々のＤＳＬＴターゲットのいずれかと通信すること、またはそのライフサイクルを通してＤＳＬＴを管理することを必要としなくてもよい。サービスは、処理ステータスを提供するために使用されるＤＳＬＴの処理中にＤＳＬＴの状態を保持し、障害が発生する場合にはＤＳＬＴのロールバックを可能にすることができる。サービスは、障害が発生した場合に、ＤＳＬＴの原子性要件を満たすことができるよう個々のリクエストのロールバックおよび中止を実施できるように、ＤＳＬＴに関連付けられた個々のリクエストの分散したセットの正常な配布および実行を管理してよい。
【００４８】
アプリケーションに代わってＤＳＬＴシーケンスの原子的処理を管理するＤＳＬＴサービス性能に関しては、ＤＳＬＴシーケンスは、アプリケーションに代わって、サービスによって原子的に順序付けられ、実施することができるＤＳＬＴのセットで構成されてよい。サービスは、障害が発生した場合に、シーケンスの原子性要件を満たすことができるようシーケンスのロールバックおよび中止を実施することができるように、ＤＳＬＴシーケンスの正常な実行を管理してよい。
【００４９】
設定可能なＤＳＬＴポリシーエンジンをサポートするＤＳＬＴサービス性能に関しては、ポリシーエンジンは、プログラム可能なＤＳＬＴポリシーのセットによって設定されてよい。ポリシーエンジンは、スケジューリングポリシー、再試行ポリシー、優先順位付けポリシー、実行基準ポリシー、完了基準ポリシー、およびシーケンスポリシーなどのＤＳＬＴポリシーをサポートしてもよい。ＤＳＬＴポリシーは、サービスがＤＳＬＴをどう処理するかを制御するルールを定義してもよい。
【００５０】
アプリケーションの要件を満たし、ＤＳＬＴターゲット（例えば、間欠的なネットワークコネクティビティのみを有するＩｏＴデバイス）の要件も満たすタイムウィンドウで実施されるよう、ＤＳＬＴまたはＤＳＬＴのシーケンスを構成する個々のリクエストのスケジューリングを調整するＤＳＬＴサービス性能に関しては、サービスは、ＤＳＬＴがそのターゲットデバイスの全てに対して正常に実施され、ＤＳＬＴの原子的な実行要件を満たすことができるようにＤＳＬＴのターゲットであるＩｏＴデバイスに到達可能なスケジュールを調整して、必要とされるデバイスの全てがオンラインおよび利用可能であることを保証するように支援してよい。サービスは、同じリソースを対象とする複数のＤＳＬＴまたはＤＳＬＴシーケンスが同時に実行しないことを保証してもよいが、それは、それらのターゲットリソースのロックを各々が取得し、それらの対応するトランザクションが独立的かつ互いに干渉しないように実施されることを保証しなければならないためである。
【００５１】
ＤＳＬＴまたはＤＳＬＴシーケンスの実行基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、実行基準は、ＤＳＬＴの実行を行うに適している時を判断してトリガするために、サービスによって使用されてよい。実行基準は、１つまたは複数の規定されたＳＬ属性またはメタデータの閾値／値、１つまたは複数のデバイスの状態または１つまたは複数のリソース状態などの過去および現在の状況の解析に基づくＳＬ定義済みイベント、アプリケーションまたはサードパーティのサービスまたは下位ネットワークからＳＬが受信または検出する外部トリガ要件、もしくは別のＳＬトランザクションの正常な完了を含んでもよい。
【００５２】
ＤＳＬＴまたはＤＳＬＴシーケンスの再伝送ポリシーをアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、再伝送ポリシーは、ＤＳＬＴの実行の失敗により、サービスのＤＳＬＴ再試行を行うに適している時を判断するために、サービスによって使用されてよい。
【００５３】
ＤＳＬＴまたはＤＳＬＴシーケンスの完了基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、完了基準は、ＤＳＬＴを構成する個々のリクエスト結果をもとに、ＤＳＬＴの実行が成功した時または成功しなかった時を判断するために、サービスによって使用されてよい。例えば、正常な完了は、一定のタイムウィンドウ内での完了を要件とし得る。または、一部のＤＳＬＴは、リクエストのサブセットが正常に完了することのみを要件とし得るが、その他のＤＳＬＴは、リクエストの全てが正常であることを要件とし得る。
【００５４】
ＤＳＬＴまたはＤＳＬＴシーケンスの優先順位をアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、優先順位は、ＤＳＬＴを相互に順位付けし、必要な場合（例えば、ＤＳＬＴが同じターゲットを共有し、それらの実行をシリアル化する必要がある場合）は、この順位付けに基づいてそれらの実行を順序付けするために、サービスによって使用されてよい。
【００５５】
ＤＳＬＴまたはＤＳＬＴシーケンスを開始するためのシンプルなＲＥＳＴｆｕｌ  ＡＰＩをアプリケーションに提供するＤＳＬＴサービス性能に関しては、ＡＰＩはＤＳＬＴごとにＳＬトランザクション識別子を定義することができる。ＡＰＩはＤＳＬＴシーケンスにＳＬシーケンス識別子を定義してもよい。また、ＡＰＩは、アプリケーションからの非ブロッキングリクエスト性能をサポートして、ＤＳＬＴまたはＤＳＬＴシーケンスを開始し、ＤＳＬＴまたはＤＳＬＴシーケンスのステータスを参照し、もしくはＤＳＬＴまたはＤＳＬＴシーケンスを中止することができる。
【００５６】
図１１は、開示されるＤＳＬＴサービスによって達成され得る複雑性の低減をアプリケーションの観点から示す図である。
【００５７】
図１１のステップ１では、アプリケーション１００２は、サーバ１１０２にトランザクションのリクエストを送信する。サーバ１１０２は、ＤＳＬＴサービスを具備しているサービス層を備えるＩｏＴサーバ１１０２であってもよい。サーバ１１０２は、トランザクションの管理を担う。（図１０で行われているように）アプリケーション１００２からサーバ１１０２にトランザクションの管理を移行することによって、アプリケーション１００２での操作を簡略化することができる。
【００５８】
図１１のステップ２では、サーバ１１０２は、複数のデバイス１００４、１００６および１００８にＤＳＬＴリクエストを配布する。
【００５９】
図１１のステップ３では、デバイス１００４、１００６および１００８は、トランザクションを正常に実行できるかどうかチェックする。
【００６０】
図１１のステップ４では、デバイス１００４、１００６および１００８は、サーバに応答して、トランザクションを実行できるかどうかを示す。この例では、デバイスの１つ（デバイス１００８）は、トランザクションを実行することができない。
【００６１】
図１１のステップ５では、デバイスの１つ（デバイス１００８）がトランザクションを実行することができないので、その他のデバイス（デバイス１００４および１００６）でのトランザクションが中止される。
【００６２】
図１１のステップ６では、サーバ１１０２はアプリケーション１００２に応答を送信する。
【００６３】
図１１を図１０と比較すると、ＤＳＬＴを管理するＩｏＴアプリケーション１００２のオーバーヘッドおよび複雑性が大幅に低減されている。記載されるＤＳＬＴサービスを用いることで、ＩｏＴアプリケーション１００２は単一のリクエストと応答でＤＳＬＴを実施できるが、既存のソリューションでは、各トランザクションの状態を管理するためにより多くのメッセージおよび内部ロジックが必要である。
【００６４】
開示されるＤＳＬＴサービスの詳細については以下に記載する。
【００６５】
（ＤＳＬＴアーキテクチャ）
一実施形態では、ＤＳＬＴサービスは、分散サービス層トランザクショントリガ機能（ＤＳＬＴ−ＴＦ）１２０２、分散サービス層トランザクション管理機能（ＤＳＬＴ−ＭＦ）１２０４および１２０６、ならびに分散サービス層トランザクションクライアント機能（ＤＳＬＴ−ＣＦ）１２０８、１２１０、１２１２および１２１４を含んでよい。
【００６６】
ＤＳＬＴ−ＴＦ１２０２を使用して、ＤＳＬＴ−ＭＦ１２０４へのＤＳＬＴトリガリクエスト（ＤＳＬＴ−ＴＲＩＧＧＥＲ）１２１６を開始してよく、これにより、ＤＳＬＴ−ＭＦ１２０４はＤＳＬＴ−ＲＥＱ１２１８を配布および管理してよい。ＤＳＬＴ−ＴＦ１２０２は、軽量かつ薄型の機能であり、ＩｏＴサーバ、ＩｏＴゲートウェイ、ＩｏＴデバイス、およびＩｏＴアプリケーションなどの様々な種類のネットワークノードでホストされてよい。
【００６７】
ＤＳＬＴ−ＭＦ１２０４（および１２０６）は、サービスとして実装されてよい。サービスは独立したサービスであるか、あるいはＩｏＴサービス層のサブサービスとして実装されるかのいずれかであってよい。ＤＳＬＴ−ＭＦサービス１２０４は、ＩｏＴサーバ、ＩｏＴゲートウェイ、ＩｏＴデバイスなどの様々な種類のネットワークノードでホストされてよい。ＤＳＬＴ−ＭＦサービス１２０４は、分散しているＤＳＬＴ−ＣＦのセットへのＤＳＬＴの配布および処理をトリガするリクエストを受信してよい。ＤＳＬＴ−ＭＦ１２０４によって受信される各ＤＳＬＴ−ＴＲＩＧＧＥＲは、１つまたは複数のターゲットを対象とする１つまたは複数のＳＬ操作で構成されてよい。ＤＳＬＴ−ＭＦ１２０４は、その関連するＳＬリクエストの全てを原子的に処理することによってＤＳＬＴ−ＴＲＩＧＧＥＲ１２１６を処理する。必要であれば、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＴＲＩＧＧＥＲ１２１６によって規定されたＳＬリクエストが分散しているＳＬエンティティのセットに正確に配布され、ターゲットＳＬエンティティの全てによって正常に実行されるか、または失敗した場合には、それらのいずれによっても実行されないことを保証する。明確にするため、ＤＳＬＴ−ＭＦ１２０４からＤＳＬＴ−ＣＦ１２０８および１２１０へと配布されるＤＳＬＴリクエストは、ＤＳＬＴ−ＲＥＱ１２１８と呼ぶ。
【００６８】
ＤＳＬＴ−ＣＦ１２１０は、ターゲットとして機能し、ＤＳＬＴ−ＭＦ１２０４から受信する配布されたＤＳＬＴ−ＲＥＱ１２１８を処理する。ＤＳＬＴ−ＣＦ１２０８は、ＩｏＴサーバ、ＩｏＴゲートウェイ、ＩｏＴデバイスおよびＩｏＴアプリケーションなどの様々な種類のネットワークノードでホストされてよい。
【００６９】
例えば、図１２に示すように、ＤＳＬＴ−ＴＦ１２０２をサポートするＩｏＴアプリケーション１２３０は、ＩｏＴサーバ１２３２でホストされているＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＴＲＩＧＧＥＲ１２１６を送信して、ＤＳＬＴ−ＭＦ１２０４に原子的なＤＳＬＴ−ＲＥＱ１２１８および１２１９のセットを配布させ、分散しているＩｏＴデバイス１２３４および１２３６のセット上のアクチュエータ（例えば、電子スイッチ）を更新してもよい。ＤＳＬＴ−ＭＦ１２０４は、各デバイスでホストされているＤＳＬＴ−ＣＦ１２０８および１２１０にＤＳＬＴ−ＲＥＱ１２１８および１２１９を配布してよく、また、それら全てがＤＳＬＴ−ＲＥＱ１２１８および１２１９を正常に実施してそれらのアクチュエータを更新するか、またはそれらのいずれも更新を実施しないことを保証してもよい。そうすることで、全てのデバイスの設定の整合性を維持する。
【００７０】
図１２に示すような、例えば、ＩｏＴゲートウェイならびにＩｏＴデバイス１２３８および１２４０が関与するようなマルチホップシナリオの場合には、ＩｏＴゲートウェイ１２４２のＤＳＬＴ−ＭＦ１２０６を使用して、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４から配布されたＤＳＬＴ−ＴＲＩＧＧＥＲ１２２２を受信してよい。そのＤＳＬＴ−ＴＲＩＧＧＥＲがＩｏＴデバイス１２３８および１２４０によってホストされているリソースを対象とすることを検出した場合、ＩｏＴゲートウェイのＤＳＬＴ−ＭＦ１２０６を使用して、ＩｏＴデバイスのＤＳＬＴ−ＣＦ１２１２および１２１４の両方にＤＳＬＴ−ＲＥＱ１２２４および１２２６を配布してもよい。これは、ＤＳＬＴサービスの分散特性、および複数のＤＳＬＴ−ＭＦをどのように使用してシステム全体にわたってＤＳＬＴを原子的に処理するかを示している。
【００７１】
ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４へのＤＳＬＴリクエストを開始し、ＤＳＬＴ−ＭＦ１２０４から返信されるＤＳＬＴ応答を受信する性能をサポートしてよいが、他のいずれのＤＳＬＴ処理性能もサポートする必要はない。
【００７２】
ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴを処理するためのいくつかの性能をサポートしてもよい。ＤＳＬＴ−ＭＦの性能のセットを図１３に示す。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＭＦ  ＡＰＩ１３０２、ＤＳＬＴ−ＭＦ処理１３０４、ＤＳＬＴ−ＭＦシーケンス処理１３０６、ＤＳＬＴ−ＭＦポリシーエンジン１３０８およびＤＳＬＴ−ＭＦスケジューラ１３１０を含んでよい。
【００７３】
同様に、ＤＳＬＴ−ＣＦ１２１０は、図１４に示すように、ＤＳＬＴを処理する対応する一連の性能をサポートしてもよい。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＣＦ  ＡＰＩ１４０２、ＤＳＬＴ−ＣＦ処理１４０４およびＤＳＬＴ−ＣＦシーケンス処理１４０６を含んでよい。
【００７４】
以下のサブセクションでは、ＤＳＬＴ−ＭＦ１２０４およびＤＳＬＴ−ＣＦ１２１０のそれぞれの性能のより詳しい定義を提供する。
【００７５】
（ＤＳＬＴ  ＡＰＩ）
ＤＳＬＴ−ＭＦ１２０４へのＤＳＬ関連リクエストを開始するためにＤＳＬＴ−ＴＦによって使用され得るＡＰＩ１３０２を、ＤＳＬＴ−ＭＦ１２０４はサポートしてよい。サポートされるリクエストのタイプとしては、新規のＤＳＬＴを開始するタイプ（すなわちＤＳＬＴ−ＴＲＩＧＧＥＲ）、既存のＤＳＬＴのステータスを参照するタイプ（すなわちＤＳＬＴ−ＱＵＥＲＹ）、および未処理のＤＳＬＴを中止するタイプ（ＤＳＬＴ−ＡＢＯＲＴ）を含んでよい。ＡＰＩ１３０２はまた、どのようにＤＳＬＴ−ＭＦがＤＳＬＴを処理し、スケジュールするかを制御するためのルールを定義するポリシーを設定するために使用されてもよい。このＡＰＩ１３０２は、ＤＳＬＴ−ＭＦ１２０４によってホストされているＤＳＬＴ関連メッセージパラメータおよび／またはリソースで構成されるＲＥＳＴｆｕｌインターフェースとしてサポートされてよい。
【００７６】
ＤＳＬＴ−ＣＦ１２１０も同様に、ＡＰＩ１４０２をサポートしてよい。このＡＰＩ１４０２は、ＤＳＬＴ−ＣＦ１２１０にＤＳＬＴ関連リクエストを送信するために、ＤＳＬＴ−ＭＦ１２０４によって使用されてよい。サポートされるリクエストのタイプとしては、新規のＤＳＬＴをＤＳＬＴ−ＣＦ１２１０に転送するタイプ（すなわちＤＳＬＴ−ＲＥＱ）、既存のＤＳＬＴのステータスを参照するタイプ（ＤＳＬＴ−ＱＵＥＲＹ）、およびＤＳＬＴ−ＣＦ１２１０が処理している未処理のＤＳＬＴを中止するタイプ（ＤＳＬＴ−ＡＢＯＲＴ）を含んでよい。このＡＰＩ１４０２は、ＤＳＬＴ−ＣＦ１２１０によってホストされているＤＳＬＴ関連メッセージパラメータおよび／またはリソースで構成されるＲＥＳＴｆｕｌインターフェースとしてサポートされてよい。
【００７７】
（ＤＳＬＴ  ＡＰＩリソース）
一実施例では、以下のリソースタイプがＤＳＬＴ−ＭＦ１２０４によってサポートされてよい。
【表２】
2020514912.tif 000004
【００７８】
（ＤＳＬＴ  ＡＰＩメッセージパラメータ）
ＤＳＬＴメッセージパラメータは、ＤＳＬＴ−ＴＲＩＧＧＥＲ、ＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲ、ＤＳＬＴ−ＲＥＱ、ＤＳＬＴ−ＱＵＥＲＹおよびＤＳＬＴ−ＡＢＯＲＴなどの様々なタイプのＤＳＬＴメッセージに適用できるものであってよい。これらの種々のＤＳＬＴメッセージタイプは、ＣＲＵＤ操作およびいくつかのＤＳＬＴメッセージパラメータを使用して、各ＤＳＬＴメッセージタイプが実装され得るＲＥＳＴｆｕｌ  ＡＰＩにマップされてよい。
【表３】
2020514912.tif 000005
【００７９】
単一のＤＳＬＴリクエストに加えて、ＤＳＬＴシーケンスを形成するために２つまたはそれ以上のＤＳＬＴが組み合わされてもよい。ＤＳＬＴシーケンスは、ＤＳＬＴの順序付けリストを規定する。複数のＤＳＬＴは、単一のＳＬリクエスト内で一緒にまとめて処理されるか、あるいはＤＳＬＴシーケンスは、同じ値を有するＤＳＬＴシーケンス識別子を使用して互いに関連付けられてもよい。ＤＳＬＴ−ＭＦ１２０４ならびにＤＳＬＴ−ＣＦ１２１０および１２０８は協働して、ＤＳＬＴシーケンスを原子的に処理および実行してよい。処理は、個々のＤＳＬＴの原子的な実行および全シーケンスの原子的な処理を含む。したがって、個々のＤＳＬＴのいずれかが正常に完了しない場合は、ＤＳＬＴシーケンスによって対象とされるいずれのリソースも、ＤＳＬＴシーケンスの実行開始前と同じ元の状態に戻されるように、ＤＳＬＴ−ＭＦ１２０４ならびにＤＳＬＴ−ＣＦ１２１０および１２０８は、シーケンス内の全てのＤＳＬＴのロールバックをサポートしてよい。
【００８０】
以下は、ＤＳＬＴシーケンスに関連するメッセージパラメータのセットである。
【表４】
2020514912.tif 000006
【００８１】
（ＤＳＬＴ  ＡＰＩ識別子）
個々のＤＳＬＴのＳＬ識別子を表７に示す。ＤＳＬＴシーケンスの識別子を表６に示す。これらのＤＳＬＴ識別子の構成は、表５に示すような複数のコンポーネントで構成されてよい。識別子は、サービスプロバイダコンポーネント（ＳＰ−ＩＤ）、ＤＳＬＴ−ＭＦコンポーネント（ＤＳＬＴ−ＭＦ−ＩＤ）、ＤＳＬＴシーケンスコンポーネント（ＤＳＬＴ−ＳＥＱ−ＩＤ）、ＤＳＬＴコンポーネント（ＤＳＬＴ−ＩＤ）およびＳＬリクエストＩＤコンポーネント（ＳＬ−ＲＥＱ−ＩＤ）で構成されてよい。
【００８２】
ＤＳＬＴがシステム内のどこで使用されるかによって、異なるフォーマットと一意性要件が存在してもよい。例えば、ＤＳＬＴが、ＤＳＬＴ−ＭＦ１２０４がホストされているのと同じＩｏＴサービスプロバイダドメイン内でホストされているＤＳＬＴ−ＣＦを対象とするためだけに使用される場合、ＤＳＬＴ識別子の一意性要件はＳＰ−ＩＤコンポーネントを必要としなくてもよい。一方で、ＤＳＬＴが、ＤＳＬＴ−ＭＦ１２０４とは異なるＩｏＴサービスプロバイダドメイン内でホストされているＤＳＬＴ−ＣＦを対象としている場合、ＤＳＬＴは、ＳＬインスタンス全体にわたっておよびサービスプロバイダドメイン全体にわたって一意であり、かつＳＰ−ＩＤを含む識別子を必要としてもよい。
【表５】
2020514912.tif 000007
【表６】
2020514912.tif 000008
【表７】
2020514912.tif 000009
【００８３】
（ＤＳＬＴ処理性能）
個々のＤＳＬＴの処理方法およびＤＳＬＴシーケンスの処理方法について以下で説明する。これらの方法のそれぞれは、ＤＳＬＴ−ＴＦ１２０２、ＤＳＬＴ−ＭＦ１２０４およびＤＳＬＴ−ＣＦ１２１０によって実施される動作を有する。それぞれの動作は、以下の説明で明確にされる。
【００８４】
（個々のＤＳＬＴ処理）
個々のＤＳＬＴは、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＴＲＩＧＧＥＲリクエスト１２１６を送信することで、ＤＳＬＴ−ＴＦ１２０２によって開始される１つのＤＳＬＴで構成されてよい。次に、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエスト１２１６を処理する。この処理では、ＤＳＬＴ−ＭＦ１２０４が、ＤＳＬＴのターゲットである分散しているＳＬエンティティのセットに、複数のＤＳＬＴ−ＲＥＱ１２１８および１２１９を配布する。ＤＳＬＴ−ＲＥＱを受信する各ＳＬエンティティは、ＤＳＬＴ−ＲＥＱを処理することができるＤＳＬＴ−ＣＦ１２０８および１２１０をホストしている。ＤＳＬＴ−ＭＦ１２０４は、配布したＤＳＬＴ−ＲＥＱ１２１９および１２１８のセットを管理し、それらが原子的に処理されることを保証する。完了すると、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエスト１２１６を発信したＤＳＬＴ−ＴＦ１２０２に応答を返す。この応答は、ＤＳＬＴの結果を含む。
【００８５】
個々のＤＳＬＴを処理する方法全体は、ＤＳＬＴを開始するＤＳＬＴ−ＴＦ１２０２、ＤＳＬＴの処理を管理するＤＳＬＴ−ＭＦ１２０４、およびＤＳＬＴを規定した操作をターゲットリソースで実施するＤＳＬＴ−ＣＦ１２０８および１２１０、で構成される３つの好適な方法に細分することが可能である。これらの各方法の説明を、以下のフロー図に記載する。
【００８６】
図１５は、個々のＤＳＬＴに対するＤＳＬＴ−ＴＦの処理を示す図である。
【００８７】
図１５のステップ１では、ＤＳＬＴ−ＴＦ１２０２をホストしているＳＬエンティティ（例えば、アプリケーション）１２３０においてＤＳＬＴのトリガ要件（例えば、アプリケーション固有イベント）が発生する。
【００８８】
図１５のステップ２では、ＤＳＬＴ−ＴＦ１２０２はＤＳＬＴ−ＴＲＩＧＧＥＲリクエストを生成し、ＤＳＬＴ−ＭＦ１２０４をホストしているＳＬエンティティに、該リクエストを送信する。これにより、ＤＳＬＴ−ＭＦ１２０４は、ＳＬエンティティの代わりにＤＳＬＴ処理を実施できる。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４がＤＳＬＴ処理の完了を示す応答を返してくるのを待つ。
【００８９】
図１５のステップ３ａでは、ＤＳＬＴ−ＭＦ１２０４はＤＳＬＴ−ＴＦ１２０２に、ＤＳＬＴ処理が完了したことを応答し、この処理のステータスを含める。
【００９０】
図１５のステップ３ｂでは、ＤＳＬＴ−ＴＦ１２０２はＤＳＬＴ−ＭＦ１２０４からの応答を待ってタイムアウトする。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＴＲＩＧＧＥＲを再送信することによってＤＳＬＴを再試行する。
【００９１】
図１５のステップ３ｃでは、ＤＳＬＴ−ＴＦ１２０２はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ−ＴＦ１２０２が再試行を望まないと決定した後のタイムアウトに起因するものであってもよい。または、この決定は、アプリケーション固有の理由などの他の要因に基づくものであってもよい。
【００９２】
図１５のステップ４では、ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４によって返されたＤＳＬＴの結果をチェックする。
【００９３】
図１５のステップ５ａでは、ＤＳＬＴは、ＤＳＬＴ−ＭＦ１２０４によって正常に処理された。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴが完了したとみなしてよい。
【００９４】
図１５のステップ５ｂでは、ＤＳＬＴは正常に処理されなかった。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴの処理を再試行させるために、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＴＲＩＧＧＥＲリクエストを再発行することによるＤＳＬＴの再試行を決定する。
【００９５】
図１５のステップ５ｃでは、ＤＳＬＴは正常に処理されなかった。ＤＳＬＴ−ＴＦ１２０２は、再試行ではなく、ＤＳＬＴリクエストの中止を決定する。
【００９６】
図１５のステップ６では、ＤＳＬＴが正常に処理されて、ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴトリガリクエストを起動したエンティティ（例えば、アプリケーション）にその結果を返す。
【００９７】
図１５のステップ７では、ＤＳＬＴ−ＴＦはＤＳＬＴの中止を決定した。ＤＳＬＴ−ＴＦ１２０２が、ＤＳＬＴ−ＭＦ１２０４から応答を受信したか否かによって、ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴの中止を決定したことを通知するために、ＤＳＬＴ−ＭＦ１２０４に中止リクエストを送信することを決定してよい。
【００９８】
図１６は、個々のＤＳＬＴに対するＤＳＬＴ−ＭＦ１２０４の処理を示す図である。
【００９９】
図１６のステップ１では、ＤＳＬＴ−ＴＦ１２０２をホストしているＳＬエンティティは、ＤＳＬＴ−ＭＦ１２０４をホストしているＳＬエンティティに、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエストを送信して、ＤＳＬＴを開始する。
【０１００】
図１６のステップ２では、ＤＳＬＴ−ＭＦ１２０４は、リクエストを処理し、ＤＳＬＴ−ＴＲＩＧＧＥＲによって対象とされているＤＳＬＴ−ＣＦ１２０８および１２１０のそれぞれに、ＤＳＬＴ−ＲＥＱを配布する。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースのロックを正常に取得したことを示す応答を待つ。
【０１０１】
図１６のステップ３ａでは、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースのロックを正常に取得できたことを検出する。
【０１０２】
図１６のステップ３ｂでは、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ−ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ−ＣＦに、ＤＳＬＴ−ＲＥＱを再送信することによってＤＳＬＴを再試行する。
【０１０３】
図１６のステップ３ｃでは、ＤＳＬＴ−ＭＦ１２０４はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ−ＭＦ１２０４が（例えば、再試行の最大数に到達して）再試行を望まないと決定した後のタイムアウトに起因するものであってよい。１つまたは複数のＤＳＬＴ−ＣＦがターゲットリソースのロックを正常に取得できなかったことを、ＤＳＬＴ−ＭＦ１２０４が検知する場合、ＤＳＬＴ−ＭＦ１２０４は、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、ＤＳＬＴの（定義された完了基準に応じて）中止を選択してもよい。ＤＳＬＴ−ＭＦ１２０４は、各ＤＳＬＴ−ＣＦに実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ−ＣＦに中止コマンドを明確に送信してよい。中止の決定は、１つまたは複数のＤＳＬＴ−ＣＦが到達可能でないなどの他の要因にも基づいてよい。
【０１０４】
図１６のステップ４では、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦに実行コマンドを送信することによってＤＳＬＴによって規定された操作を実行するようにＤＳＬＴ−ＣＦ１２０８および１２１０に命令する。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦのそれぞれから、ターゲットリソースで操作を正常に実行したことを示す応答を待つ。
【０１０５】
図１６のステップ５ａでは、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦの全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作を正常に実行できたことを検出する。
【０１０６】
図１６のステップ５ｂでは、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ−ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ−ＣＦへの実行コマンドの送信を再試行する。
【０１０７】
図１６のステップ５ｃでは、ＤＳＬＴ−ＭＦ１２０４はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ−ＭＦ１２０４が（例えば、再実行の最大数に到達して）再試行を望まないと決定した後のタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ−ＣＦが到達可能でないなどの他の要因に基づくものであってよい。ＤＳＬＴ−ＭＦ１２０４が、１つまたは複数のＤＳＬＴ−ＣＦがターゲットリソースで操作を正常に実行できなかったことを検出した場合、ＤＳＬＴ−ＭＦ１２０４は、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、ＤＳＬＴの（定義された完了基準に応じて）中止を選択してもよい。ＤＳＬＴ−ＭＦ１２０４は、各ＤＳＬＴ−ＣＦ１２０８および１２１０に実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ−ＣＦ１２０８および１２１０に中止コマンドを明確に送信してよい。
【０１０８】
図１６のステップ６では、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴによって規定された操作をコミットするようにＤＳＬＴ−ＣＦ１２０８および１２１０に命令する。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースで操作を正常にコミットしたことを示す応答を待つ。
【０１０９】
図１６のステップ７ａでは、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作の結果を正常にコミットできたことを検出する。
【０１１０】
図１６のステップ７ｂでは、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ−ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０へのコミットコマンドの送信を再試行する。
【０１１１】
図１６のステップ７ｃでは、ＤＳＬＴ−ＭＦ１２０４はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ−ＭＦ１２０４が（例えば、再実行の最大数に到達して）再実行を望まないと決定した後のタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０が到達可能ではないなどの他の要因に基づくものであってよい。
【０１１２】
図１６のステップ８では、ＤＳＬＴが正常に処理されて、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴをトリガしたＤＳＬＴ−ＴＦ１２０２に、その結果を返す。
【０１１３】
図１６のステップ９では、ＤＳＬＴ−ＭＦはＤＳＬＴの中止を決定した。ＤＳＬＴ−ＭＦ１２０４が、ＤＳＬＴ−ＣＦ１２０８および１２１０から応答を受信したか否かによって、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０に明確な中止リクエストを送信することを決定し、ＤＳＬＴの中止を決定したことを１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０に通知してもよい。これにより、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０は、ＤＳＬＴの処理を停止するプロセス、ターゲットリソースの状態を元の状態にロールバックするプロセス、またはターゲットリソースをアンロックするプロセスなど、任意の必要なプロセスを実施してもよい。
【０１１４】
図１７は、個々のＤＳＬＴ−ＣＦに対するＤＳＬＴ−ＣＦの処理を示す。
【０１１５】
図１７のステップ１では、ＤＳＬＴ−ＣＦ１２１０をホストしているＳＬエンティティは、ＤＳＬＴ−ＭＦ１２０４からＤＳＬＴ−ＲＥＱを受信する。
【０１１６】
図１７のステップ２では、ＤＳＬＴ−ＣＦ１２１０がリクエストリソースのロックを試みる初期化処理ステップである。
【０１１７】
図１７のステップ３ａでは、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＲＥＱによって対象とされるリソースのロックを（必要に応じて）正常に取得することができる。ロックリソースの状態がコミットされてアンロックされるまでロックリソースの取得もブロックされなければならない場合があるので、このブロッキングは、他のＤＳＬＴ−ＲＥＱからの全ての操作に適用され得る。
【０１１８】
図１７のステップ３ｂでは、ＤＳＬＴ−ＣＦ１２１０は、タイムアウト期間が経過する前にターゲットリソースのロックを取得することができず、その後、ＤＳＬＴ−ＣＦ１２１０はタイムアウトを選択し、ＤＳＬＴ−ＲＥＱを中止する。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４から再試行されたＤＳＬＴ−ＲＥＱを受信してもよく、この場合、ＤＳＬＴ−ＣＦ１２１０は、ステップ１からフローを繰り返してよい。
【０１１９】
図１７のステップ３ｃでは、ＤＳＬＴ−ＣＦ１２１０は、明確な中止コマンドをＤＳＬＴ−ＭＦ１２０４から受信し、その後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱを中止する。ＤＳＬＴ−ＣＦ１２１０がいずれかのターゲットリソースのロックを取得できていた場合、ＤＳＬＴ−ＣＦ１２１０は、これらのロックを解放し、ＤＳＬＴの処理を停止する。ＤＳＬＴ−ＣＦは、ＤＳＬＴ−ＭＦ１２０４から再試行されたＤＳＬＴ−ＲＥＱを受信してもよく、この場合、ＤＳＬＴ−ＣＦは、ステップ１からフローを繰り返してよい。
【０１２０】
図１７のステップ４では、ターゲットリソースのロックが、（必要に応じて）各ＤＳＬＴ−ＣＦによって取得される。各ＤＳＬＴ−ＣＦは、ロックが取得されたか、またはロックが必要でないことをＤＳＬＴ−ＭＦ１２０４に通知する。ＤＳＬＴ−ＣＦ１２１０は、ターゲットリソースでＤＳＬＴ規定操作を実行するコマンドをＤＳＬＴ−ＭＦ１２０４から受信するまでこの状態で待つ。
【０１２１】
図１７のステップ５ａでは、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４から実行コマンド受信して、ターゲットリソースでＤＳＬＴ規定操作の実行を正常に完了することができた。
【０１２２】
図１７のステップ５ｂでは、ＤＳＬＴ−ＣＦ１２１０は、タイムアウト期間が経過する前にＤＳＬＴ−ＭＦ１２０４から実行コマンドを受信せず、その後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱをタイムアウトし、リソースをアンロックする。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＭＦ１２０４からＤＳＬＴ−ＲＥＱコマンドを受信してよい。
【０１２３】
図１７のステップ５ｃでは、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱの実行を中止する。これは、ＤＳＬＴ−ＭＦ１２０４から実行コマンドを受信し、ターゲットリソースでＤＳＬＴ規定操作を正常に実行できないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。
【０１２４】
図１７のステップ６では、ＤＳＬＴ−ＣＦ１２１０は実行を正常に完了した。ＤＳＬＴは、ＤＳＬＴ−ＭＦ１２０４にその実行ステータスを通知し、ＤＳＬＴ−ＭＦ１２０４からのコミットコマンドを待つ。
【０１２５】
図１７のステップ７ａでは、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４からコミットコマンドを受信して、ターゲットリソースの状態を正常にコミットできたため、結果が耐久的に維持される。
【０１２６】
図１７のステップ７ｂでは、ＤＳＬＴ−ＣＦ１２１０は、タイムアウト期間が経過する前にＤＳＬＴ−ＭＦ１２０４からコミットコマンドを受信せず、その後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱをタイムアウトする。ＤＳＬＴ−ＣＦ１２１０は、他のＤＳＬＴ−ＣＦと整合した状態を維持するために中止するのではなく、更新されたリソースの状態を引き続きコミットする。ＤＳＬＴ−ＣＦ１２１０は、リソースのアンロックも行う。
【０１２７】
図１７のステップ７ｃでは、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱのコミットを中止する。これは、ＤＳＬＴ−ＭＦ１２０４からコミットコマンドを受信し、結果を正常にコミットできないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。
【０１２８】
図１７のステップ８では、コミット後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴによって対象とされたリソースのロックを解放してよい。この場合、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にコミットの通知を送信してもよい。
【０１２９】
図１７のステップ９では、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴの中止およびロールバックを行い、ＤＳＬＴ−ＭＦ１２０４に、対応するステータスを返す。中止後、ＤＳＬＴ−ＣＦはリソースのロックを解放する必要がある。この場合、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４に中止の通知を送信してもよい。
【０１３０】
（ＤＳＬＴシーケンス処理）
ＤＳＬＴシーケンスは、原子的な順序付けられたセットとして処理される必要がある複数の分散サービス層トランザクションで構成される。ＤＳＬＴシーケンスは、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを送信するＤＳＬＴ−ＴＦ１２０２によってトリガされる。次に、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴシーケンスを処理する。この処理では、ＤＳＬＴ−ＭＦ１２０４が、ＤＳＬＴシーケンスのターゲットである分散しているＳＬエンティティのセットにＤＳＬＴ−ＲＥＱを配布する。ＤＳＬＴ−ＲＥＱを受信する各ＳＬエンティティは、ＤＳＬＴ−ＲＥＱを処理することができるＤＳＬＴ−ＣＦ１２０８および１２１０をホストしている。ＤＳＬＴ−ＭＦ１２０４は、シーケンス内のＤＳＬＴ−ＲＥＱの全てが原子的に順序付けられて処理されることを保証する。完了すると、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを発信したＤＳＬＴ−ＴＦ１２０２に応答を返す。この応答は、ＤＳＬＴシーケンスの結果を含む。
【０１３１】
ＤＳＬＴシーケンスを処理する方法全体は、ＤＳＬＴシーケンスを開始するＤＳＬＴ−ＴＦ１２０２、ＤＳＬＴシーケンスの処理を管理するＤＳＬＴ−ＭＦ１２０４、およびシーケンス内の個々のＤＳＬＴによって規定された操作をターゲットリソースで実施するＤＳＬＴ−ＣＦ１２０８および１２１０、で構成される３つの好適な方法に細分することが可能である。これらの各方法の説明を、以下のフロー図に記載する。
【０１３２】
図１８は、ＤＳＬＴシーケンスに対するＤＳＬＴ−ＴＦ１２０２の処理を示す図である。
【０１３３】
図１８のステップ１では、ＤＳＬＴ−ＴＦ１２０２をホストしているＳＬエンティティ（例えば、アプリケーション）においてＤＳＬＴシーケンストリガ要件（例えば、アプリケーション固有イベント）が発生する。
【０１３４】
図１８のステップ２では、ＤＳＬＴ−ＴＦ１２０２はＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを生成し、ＤＳＬＴ−ＭＦ１２０４をホストしているＳＬエンティティに、該リクエストを送信する。これにより、ＤＳＬＴ−ＭＦ１２０４は、ＳＬエンティティの代わりにＤＳＬＴシーケンス処理を実施できる。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４がＤＳＬＴシーケンス処理の完了を示す応答を返してくるのを待つ。
【０１３５】
図１８のステップ３ａでは、ＤＳＬＴ−ＭＦ１２０４はＤＳＬＴ−ＴＦ１２０２に、ＤＳＬＴシーケンス処理が完了したことを応答し、この処理のステータスを含める。
【０１３６】
図１８のステップ３ｂでは、ＤＳＬＴ−ＴＦ１２０２はＤＳＬＴ−ＭＦ１２０４からの応答を待ってタイムアウトする。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを再送信することによってＤＳＬＴシーケンスを再試行する。
【０１３７】
図１８のステップ３ｃでは、ＤＳＬＴ−ＴＦ１２０２はＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストの中止を決定する。この決定は、ＤＳＬＴ−ＴＦ１２０２が再試行を望まないと決定した後のタイムアウトに起因するものであってもよい。または、この決定は、アプリケーション固有の理由などの他の要因に基づくものであってもよい。
【０１３８】
図１８のステップ４では、ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４によって返されたＤＳＬＴシーケンスの結果をチェックする。
【０１３９】
図１８のステップ５ａでは、ＤＳＬＴシーケンスは、ＤＳＬＴ−ＭＦ１２０４によって正常に処理された。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴシーケンスが完了したとみなしてよい。
【０１４０】
図１８のステップ５ｂでは、ＤＳＬＴシーケンスは正常に処理されなかった。ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴの処理を再試行させるために、ＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを再発行することによるＤＳＬＴシーケンスの再試行を決定する。
【０１４１】
図１８のステップ５ｃでは、ＤＳＬＴシーケンスは正常に処理されなかった。ＤＳＬＴ−ＴＦ１２０２は、再試行ではなく、ＤＳＬＴシーケンスリクエストの中止を決定する。
【０１４２】
図１８のステップ６では、ＤＳＬＴシーケンスが正常に処理されて、ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴシーケンストリガリクエストを起動したエンティティ（例えば、アプリケーション）にその結果を返す。
【０１４３】
図１８のステップ７では、ＤＳＬＴ−ＴＦ１２０２はＤＳＬＴシーケンスの中止を決定した。ＤＳＬＴ−ＴＦ１２０２が、ＤＳＬＴ−ＭＦ１２０４から応答を受信したか否かによって、ＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴシーケンスの中止を決定したことを通知するために、ＤＳＬＴ−ＭＦ１２０４に中止リクエストを送信することを決定してよい。
【０１４４】
図１９は、ＤＳＬＴシーケンスに対するＤＳＬＴ−ＭＦ１２０４の処理を示す図である。
【０１４５】
図１９のステップ１では、ＤＳＬＴ−ＴＦ１２０２をホストしているＳＬエンティティは、ＤＳＬＴ−ＭＦ１２０４をホストしているＳＬエンティティに、ＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを送信して、ＤＳＬＴシーケンスを開始する。
【０１４６】
図１９のステップ２では、ＤＳＬＴ−ＭＦ１２０４は、リクエストを処理し、ＤＳＬＴ−ＴＲＩＧＧＥＲによって対象とされているＤＳＬＴ−ＣＦ１２０８および１２１０のそれぞれに、シーケンス内の最初のＤＳＬＴに対応するＤＳＬＴ−ＲＥＱを配布する。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースのロックを正常に取得したことを示す応答を待つ。
【０１４７】
図１９のステップ３ａでは、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースのロックを正常に取得できたことを検出する。
【０１４８】
図１９のステップ３ｂでは、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ−ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ−ＣＦに、シーケンス内の最初のＤＳＬＴに対応するＤＳＬＴ−ＲＥＱを再送信することによってＤＳＬＴを再試行する。
【０１４９】
図１９のステップ３ｃでは、ＤＳＬＴ−ＭＦ１２０４は、シーケンス完了基準に応じて、シーケンス内の最初のＤＳＬＴリクエスト、および場合によっては全てのＤＳＬＴシーケンスの中止を決定する。この決定は、ＤＳＬＴ−ＭＦ１２０４が（例えば、再実行の最大数に到達して）再試行を望まないと決定した後のタイムアウトに起因するものであってよい。１つまたは複数のＤＳＬＴ−ＣＦがターゲットリソースのロックを正常に取得できなかったことをＤＳＬＴ−ＭＦ１２０４が検知した場合、ＤＳＬＴ−ＭＦ１２０４は、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、（定義された完了基準に応じて）ＤＳＬＴの中止を選択してもよい。ＤＳＬＴ−ＭＦ１２０４は、各ＤＳＬＴ−ＣＦ１２０８および１２１０に実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ−ＣＦ１２０８および１２１０に中止コマンドを明確に送信してもよい。中止の決定は、１つまたは複数のＤＳＬＴ−ＣＦが到達可能でないなどの他の要因にも基づいてよい。
【０１５０】
図１９のステップ４では、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０に実行コマンドを送信することによって、シーケンス内の最初のＤＳＬＴによって規定された操作を実行するようにＤＳＬＴ−ＣＦ１２０８および１２１０に命令する。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースで操作を正常に実行したことを示す応答を待つ。
【０１５１】
図１９のステップ５ａでは、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作を正常に実行できたことを検出する。
【０１５２】
図１９のステップ５ｂでは、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ−ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ−ＣＦへの実行コマンドの送信を再試行する。
【０１５３】
図１９のステップ５ｃでは、ＤＳＬＴ−ＭＦ１２０４は、シーケンス完了基準に応じて、シーケンス内の最初のＤＳＬＴリクエスト、および場合によっては全てのＤＳＬＴシーケンスの中止を決定する。この決定は、ＤＳＬＴ−ＭＦ１２０４が（例えば、再実行の最大数に到達して）再実行を望まないと決定した後のタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０が到達可能ではないなどの他の要因に基づくものであってもよい。１つまたは複数のＤＳＬＴ−ＣＦがターゲットリソースで操作を正常に実行できなかったことをＤＳＬＴ−ＭＦ１２０４が検出する場合、ＤＳＬＴ−ＭＦ１２０４は、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、（定義された完了基準に応じて）ＤＳＬＴの中止を選択してもよい。ＤＳＬＴ−ＭＦ１２０４は、各ＤＳＬＴ−ＣＦ１２０８および１２１０に実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ−ＣＦ１２０８および１２１０に中止コマンドを明確に送信してもよい。
【０１５４】
図１９のステップ６では、ステップ２で記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１５５】
図１９のステップ７ａでは、ステップ３ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１５６】
図１９のステップ７ｂでは、ステップ３ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１５７】
図１９のステップ７ｃでは、ステップ３ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１５８】
図１９のステップ８では、ステップ４で記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１５９】
図１９のステップ９ａでは、ステップ５ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１６０】
図１９のステップ９ｂでは、ステップ５ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１６１】
図１９のステップ９ｃでは、ステップ５ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１６２】
図１９のステップ１０では、ステップ２で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１６３】
図１９のステップ１１ａでは、ステップ３ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１６４】
図１９のステップ１１ｂでは、ステップ３ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１６５】
図１９のステップ１１ｃでは、ステップ３ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１６６】
図１９のステップ１２では、ステップ４で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１６７】
図１９のステップ１３ａでは、ステップ５ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１６８】
図１９のステップ１３ｂでは、ステップ５ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１６９】
図１９のステップ１３ｃでは、ステップ５ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１７０】
図１９のステップ１４では、ＤＳＬＴ−ＭＦ１２０４が、ＤＳＬＴ−ＣＦ１２０８および１２１０の全て（または定義されたシーケンス完了基準に応じたサブセット）が、ＤＳＬＴの全シーケンスによって規定されているように、全ターゲットリソースで操作を全て正常に実行できたことを検知する場合、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０のそれぞれに、結果の状態を耐久的に維持するように、シーケンス内の該当する全てのＤＳＬＴのコミットを命令する。
【０１７１】
図１９のステップ１５ａでは、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作の結果を正常にコミットできたことを検出する。
【０１７２】
図１９のステップ１５ｂでは、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦからの応答を待ってタイムアウトする。ＤＳＬＴ−ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ−ＣＦへのコミットコマンドの送信を再試行する。
【０１７３】
図１９のステップ１５ｃでは、ＤＳＬＴ−ＭＦ１２０４は、シーケンス完了基準に基づいてＤＳＬＴシーケンスの中止を決定する。この決定は、ＤＳＬＴ−ＭＦ１２０４が（例えば、再試行の最大数に到達して）再試行を望まないと決定するタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ−ＣＦが到達可能でないなどの他の要因に基づくものであってもよい。ＤＳＬＴ−ＭＦ１２０４が、１つまたは複数のＤＳＬＴ−ＣＦがターゲットリソースで操作を正常にコミットできなかったことを検出した場合、ＤＳＬＴ−ＭＦ１２０４は、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にわたってＤＳＬＴシーケンスを原子的に実施することができないので、（定義された完了基準に応じて）ＤＳＬＴシーケンスの中止を選択してもよい。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴシーケンスをトリガしたＤＳＬＴ−ＴＦ１２０２にエラーを返すことによってＤＳＬＴシーケンスを中止してよい。
【０１７４】
図１９のステップ１６では、ＤＳＬＴシーケンスが正常に処理されて、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴシーケンスをトリガしたＤＳＬＴ−ＴＦ１２０２に、その結果を返す。
【０１７５】
図１９のステップ１７では、ＤＳＬＴ−ＭＦはＤＳＬＴシーケンスの中止を決定した。ＤＳＬＴ−ＭＦ１２０４が、ＤＳＬＴ−ＣＦ１２０８および１２１０から応答を受信したか否かによって、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０に明確な中止リクエストを送信することを決定し、シーケンス内の１つまたは複数のＤＳＬＴの中止を決定したことを１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０に通知してもよい。これにより、１つまたは複数のＤＳＬＴ−ＣＦ１２０８および１２１０は、ＤＳＬＴシーケンスの処理を停止するプロセス、ターゲットリソースの状態を元の状態にロールバックするプロセス、またはターゲットリソースをアンロックするプロセスなど、任意の必要なプロセスを実施してもよい。
【０１７６】
図２０は、ＤＳＬＴシーケンスに対するＤＳＬＴ−ＣＦの処理を示す図である。
【０１７７】
図２０のステップ１では、ＤＳＬＴ−ＣＦ１２１０をホストしているＳＬエンティティは、ＤＳＬＴ−ＭＦ１２０４からシーケンス内の最初のＤＳＬＴに対応するＤＳＬＴ−ＲＥＱを受信する。あるいは、各ＤＳＬＴ−ＣＦ１２０８および１２１０は、単一のリクエストで一緒にまとめて処理されるシーケンス内の全てのＤＳＬＴを受信してもよい。
【０１７８】
図２０のステップ２では、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱを処理し、トランザクションが他のいずれのＤＳＬＴ−ＲＥＱからも独立し、かつ干渉されずに実施されることを保障するために、ＤＳＬＴ−ＲＥＱによって対象とされるリソースのロックを（必要に応じて）試みる。ＤＳＬＴ−ＣＦ１２１０は、（必要に応じて）ロックが取得されるまでこの状態で待つ。ＤＳＬＴ−ＣＦ１２１０は、このロックをＤＳＬＴシーケンスに関連付けて、同じシーケンス内の各ＤＳＬＴ（その他のいずれのＤＳＬＴでもない）がリソースで動作することを可能にしてよい。このロックは、操作の種類によって左右されるものであってよい。例えば、操作が更新または削除である場合のみ、ターゲットリソースをロックする。しかし、一部のユースケースでは、取得を実施するＤＳＬＴ−ＲＥＱが実行される前に、別のＤＳＬＴ−ＲＥＱがリソースを変更または削除しないことを確実にするために、取得のためのロックも保証されてもよい。一旦、リソースが１つのＤＳＬＴ−ＲＥＱによってロックされると、このロックを使用して、他のＤＳＬＴ−ＲＥＱが該リソースにアクセスすることをブロックしてよい。ロックリソースの状態がコミットされてアンロックされるまでロックリソースの取得もブロックされる必要があり得るため、このブロッキングは、他のＤＳＬＴ−ＲＥＱからの全ての操作に適用できるものであってよい。
【０１７９】
図２０のステップ３ａでは、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＲＥＱによって対象とされるリソースのロックを（必要に応じて）正常に取得することができる。ロックリソースの状態がコミットされてアンロックされるまでロックリソースの取得もブロックされる必要があり得るため、このブロッキングは、他のＤＳＬＴ−ＲＥＱからの全ての操作に適用できるものであってよい。
【０１８０】
図２０のステップ３ｂでは、ＤＳＬＴ−ＣＦ１２１０は、タイムアウト期間が経過する前にターゲットリソースのロックを取得することができず、その後、ＤＳＬＴ−ＣＦ１２１０はタイムアウトしてＤＳＬＴ−ＲＥＱを中止することを選択する。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ−ＣＦは、ＤＳＬＴ−ＭＦ１２０４から再試行されたＤＳＬＴ−ＲＥＱを受信してもよく、この場合、ＤＳＬＴ−ＣＦは、ステップ１からフローを繰り返してよい。
【０１８１】
図２０のステップ３ｃでは、ＤＳＬＴ−ＣＦ１２１０は、明確な中止コマンドをＤＳＬＴ−ＭＦ１２０４から受信し、その後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱを中止する。ＤＳＬＴ−ＣＦ１２１０がいずれかのターゲットリソースロックを取得することができていた場合、ＤＳＬＴ−ＣＦ１２１０は、これらのロックを解放し、ＤＳＬＴの処理を停止する。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４から再試行されたＤＳＬＴ−ＲＥＱを受信してもよく、この場合、ＤＳＬＴ−ＣＦ１２１０は、ステップ１からフローを繰り返してよい。
【０１８２】
図２０のステップ４では、ターゲットリソースのロックが、各ＤＳＬＴ−ＣＦ１２０８および１２１０によって（必要に応じて）取得される。各ＤＳＬＴ−ＣＦは、ＤＳＬＴ−ＭＦ１２０４に、ロックが取得されたか、またはロックが必要でないことを通知する。ＤＳＬＴ−ＣＦは、ＤＳＬＴ−ＭＦ１２０４からターゲットリソースでＤＳＬＴ規定操作を実行するコマンドを受信するまでこの状態で待つ。
【０１８３】
図２０のステップ５ａでは、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４から実行コマンドを受信して、ターゲットリソースでＤＳＬＴ規定操作の実行を正常に完了することができた。
【０１８４】
図２０のステップ５ｂでは、ＤＳＬＴ−ＣＦ１２１０は、タイムアウト期間が経過する前にＤＳＬＴ−ＭＦ１２０４から実行コマンドを受信せず、その後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱをタイムアウトし、リソースをアンロックする。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＭＦ１２０４からＤＳＬＴ−ＲＥＱコマンドを受信してよい。
【０１８５】
図２０のステップ５ｃでは、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴ−ＲＥＱの実行を中止する。これは、ＤＳＬＴ−ＭＦ１２０４から実行コマンドを受信し、ターゲットリソースでＤＳＬＴ規定操作を正常に実行できないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。
【０１８６】
図２０のステップ６では、ＤＳＬＴ−ＣＦ１２１０は実行を正常に完了した。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にその実行ステータスを通知し、シーケンス内の次のＤＳＬＴ、またはＤＳＬＴ−ＭＦ１２０４からのコミットコマンドを待つ。次のＤＳＬＴがシーケンス中に受信される場合、ステップ２で記載したのと同じ動作が、該次のＤＳＬＴの処理に適用されてよい。
【０１８７】
図２０のステップ７ａでは、ステップ３ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１８８】
図２０のステップ７ｂでは、ステップ３ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１８９】
図２０のステップ７ｃでは、ステップ３ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１９０】
図２０のステップ８では、ステップ４で記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１９１】
図２０のステップ９ａでは、ステップ５ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１９２】
図２０のステップ９ｂでは、ステップ５ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１９３】
図２０のステップ９ｃでは、ステップ５ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。
【０１９４】
図２０のステップ１０では、ステップ６で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１９５】
図２０のステップ１１ａでは、ステップ３ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１９６】
図２０のステップ１１ｂでは、ステップ３ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１９７】
図２０のステップ１１ｃでは、ステップ３ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１９８】
図２０のステップ１２では、ステップ４で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０１９９】
図２０のステップ１３ａでは、ステップ５ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０２００】
図２０のステップ１３ｂでは、ステップ５ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０２０１】
図２０のステップ１３ｃでは、ステップ５ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。
【０２０２】
図２０のステップ１４では、ＤＳＬＴ−ＣＦ１２１０は、シーケンス内のＮ番目のＤＳＬＴの実行を正常に完了する。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にその実行ステータスを通知し、シーケンス内の次のＤＳＬＴ、またはＤＳＬＴ−ＭＦ１２０４からのコミットコマンドを待つ。
【０２０３】
図２０のステップ１５ａでは、ＤＳＬＴ−ＣＦ１２１０は、シーケンス内のＤＳＬＴを正常にコミットすることができた。
【０２０４】
図２０のステップ１５ｂでは、ＤＳＬＴ−ＣＦ１２１０は、タイムアウト期間が経過する前に、シーケンス内で次に続くＤＳＬＴ、またはＤＳＬＴ−ＭＦ１２０４からのコミットコマンドを受信せず、その後、ＤＳＬＴ−ＣＦ１２１０はＤＳＬＴシーケンスをタイムアウトする。これが起こった場合／起こったとき、ＤＳＬＴ−ＣＦは、シーケンス内の更新されたリソースの状態をコミットせずに中止する。これにより、ターゲットリソースの状態は、シーケンス内のいずれのＤＳＬＴ操作も実施される前の初期状態にロールバックされる。同様に、ターゲットリソースでＤＳＬＴ規定操作を実施した後に、ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＭＦ１２０４から明確な中止コマンドを受信する場合、ＤＳＬＴ−ＣＦ１２１０は、更新されたリソースの状態をコミットせずにＤＳＬＴシーケンスを中止することによってＤＳＬＴシーケンスを中止してよい。これにより、ターゲットリソースの状態は、シーケンス内のいずれのＤＳＬＴ操作も実施される前の初期状態にロールバックされる。ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４にこの中止を通知してよい。
【０２０５】
図２０のステップ１５ｃでは、ＤＳＬＴ−ＣＦ１２１０は、シーケンスの一部として処理され、まだコミットされていない全てのＤＳＬＴのコミットを中止する。これは、ＤＳＬＴ−ＭＦ１２０４からコミットコマンドを受信し、結果を正常にコミットできないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。
【０２０６】
図２０のステップ１６では、コミット後、ＤＳＬＴ−ＣＦ１２１０は、シーケンス内のいずれかのＤＳＬＴによって対象とされたリソースのロックを解放してよい。この場合、ＤＳＬＴ−ＣＦは、ＤＳＬＴ−ＭＦ１２０４にコミットの通知を送信してもよい。
【０２０７】
図２０のステップ１７では、タイムアウトまたは中止が発生した場合、ＤＳＬＴ−ＣＦは、シーケンスの一部として処理された全てのＤＳＬＴを中止してロールバックし、ＤＳＬＴ−ＭＦ１２０４に対応するステータスを返してよい。中止後、ＤＳＬＴ−ＣＦ１２１０は、同様にリソースのロックを解放する必要がある。この場合、ＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＭＦ１２０４に中止の通知を送信してもよい。
【０２０８】
（ＤＳＬＴ−ＭＦポリシーエンジン性能）
ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴポリシーエンジン性能１３０８をサポートしてよい。そのＡＰＩによって、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ処理ポリシーを、生成、取得、更新または削除するためのポリシー構成リクエストをサポートしてよい。これらのポリシーを使用して、ＤＳＬＴ−ＭＦ１２０４内部に、ＤＳＬＴの処理の方法、ならびにターゲットＤＳＬＴ−ＣＦ１２０８および１２１０との相互作用を制御するＤＳＬＴ処理ルールを構成してよい。
【０２０９】
ＤＳＬＴ処理ポリシーには、以下の種類のものを使用してよい。
・ＤＳＬＴスケジューリングポリシー
ＤＳＬＴ−ＭＦ１２０４が、ＤＳＬＴまたはＤＳＬＴシーケンスの処理をどのようにスケジュールするか制御するルールを設定するために使用されるポリシー。
・ＤＳＬＴ再試行ポリシー
ＤＳＬＴ−ＭＦ１２０４が、処理が失敗したＤＳＬＴまたはＤＳＬＴシーケンスをいつ再試行するか制御するルールを設定するために使用されるポリシー。ルールには、ＤＳＬＴが再試行することができる回数の最大限度または最小限度を含んでよい。
・ＤＳＬＴ優先順位付けポリシー
ＤＳＬＴ−ＭＦ１２０４が、どのようにＤＳＬＴまたはＤＳＬＴシーケンスの処理を互いに対して優先順位付けおよび順位付けするか制御するルールを設定するために使用されるポリシー。
・ＤＳＬＴ実行基準ポリシー
ＤＳＬＴ−ＭＦ１２０４が、どのようにＤＳＬＴまたはＤＳＬＴシーケンスに対して実行基準を割り当てて処理するか制御するルールを設定するために使用されるポリシー。
・ＤＳＬＴ完了基準ポリシー
ＤＳＬＴ−ＭＦ１２０４が、どのようにＤＳＬＴまたはＤＳＬＴシーケンスに対して完了基準を割り当てて処理するか制御するルールを設定するために使用されるポリシー。
【０２１０】
上記の種類のポリシーのそれぞれの適用性／範囲が設定されてよい。例えば、ポリシーの範囲は以下のものに限定されてよい。
特定の送信元（例えば、特定のＤＳＬＴ−ＴＦ１２０２または複数のＤＳＬＴ−ＴＦ１２０２のグループ）から発信されるＤＳＬＴ
特定のターゲット（例えば、特定のＤＳＬＴ−ＣＦまたはＤＳＬＴ−ＣＦのグループ）を対象とするＤＳＬＴ
特定のタイプのＤＳＬＴ（例えば、生成と同等の操作でのＤＳＬＴ）
【０２１１】
以下の種類のポリシーエンジン機能が使用されてよい。ＤＳＬＴ−ＭＦ１２０４は、受信する受信ＤＳＬＴリクエストに、対応するポリシールール（例えば、スケジューリング、再試行、優先順位付け、および完了基準ルール）を適用してもよい。これらのルールは、これらのパラメータに対して、明確にその対応する値を定義していない（例えば、これらの値を明確に定めるＤＳＬＴメッセージパラメータを含まない）ＤＳＬＴリクエストに適用することができるデフォルトとして使用されてよい。ＤＳＬＴリクエストがこれらのパラメータのうちの１つまたは複数に対する明確な値を含まない場合、これらのポリシーは限度として使用されてよい。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴリクエストにおいて明確に定義されたパラメータに対してこれらのポリシー限度を比較してもよく、必要に応じて、限度に従うように明確な値を変更することによってこれらの限度に実効性をもたせる。
【０２１２】
（リソース予約のためのＤＳＬＴ−ＭＦスケジューリング性能）
ＤＳＬＴ−ＭＦ１２０４は、集約化型ＤＳＬＴスケジューリング機能１３１０として機能してもよい。ＤＳＬＴ−ＭＦ１２０４は、分散しているＳＬエンティティのセットへのアクセス、およびＤＳＬＴを実行するために必要とされる該分散している各ＳＬエンティティによってホストされているリソースへのアクセスの、スケジューリング性能をサポートしてよい。あらかじめこのスケジューリングを先回りして行うことによって、所定のＤＳＬＴを実行するのに必要なリソースが必要に応じて利用可能になり、これらのリソースに対する競合が最小限に抑えられることを保証する支援をしてもよい。これにより、最初の試みでＤＳＬＴ処理が成功する可能性が高くなる場合があり、性能が向上（例えば、再試行の試みの発生を低減）する場合がある。集約化型ＤＳＬＴ−ＭＦスケジューリング性能は、ターゲットリソースおよびＤＳＬＴのそれぞれで規定された対応する操作を検査してもよい。全ＤＳＬＴにわたる情報のこの集約セットに基づいて、ＤＳＬＴ−ＭＦ１２０４は、得られた情報からＤＳＬＴスケジューリングを決定し、未処理の全ＤＳＬＴの上位集合にわたって対象とされるリソースへのアクセスを最適化する。
【０２１３】
以下のＤＳＬＴスケジューリング機能１３１０が使用されてよい。
（１）ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴがそのターゲットデバイスの全てに対して正常に実施され、ＤＳＬＴの原子的な実行要件を満たすことができるようにＤＳＬＴのターゲットであるＩｏＴデバイスの到達可能スケジュールを調整して、全ての必要とされるデバイスがオンラインおよび利用可能であることを保証するように支援してよい。デバイスのうち１つが利用できない場合、原子性欠如によってＤＳＬＴが失敗することになるので、これは重大である。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴリクエストがターゲットデバイスに対して発行される前に、ターゲットデバイス同士が互いに連携するように、ターゲットデバイスのそれぞれを調整して、それらのコネクティビティスケジュールを構成してよい。この連携は、本質的に反復性であるタイプのＤＳＬＴに、ワンタイム／アドホックベースで行われるか、繰り返し／継続ベースで行われてよい。
（２）ＤＳＬＴ−ＭＦ１２０４は、同じリソースを対象とする複数のＤＳＬＴまたはＤＳＬＴシーケンスが同時に実行しないことを保証してもよいが、それは、それらのターゲットリソースのロックを各々が取得し、独立的に、かつ互いに干渉しないようにそれらの対応するトランザクションを実施することを保証する必要があるためである。同じリソースを対象とする複数のＤＳＬＴの同時実行を試みると、最適でないＤＳＬＴ実行（例えば、遅延、タイムアウト、再試行など）またはＤＳＬＴの失敗をももたらす場合がある。ＤＳＬＴ−ＭＦ１２０４は、各ＤＳＬＴおよびその構成ターゲットを検査してよい。次いで、ターゲットが重複しているそれらＤＳＬＴは同時に実行されず、ターゲットが重複していないＤＳＬＴは重複してもよいことを保証するために、各ＤＳＬＴの実行を互いに対して適切にスケジュールして、順序付けしてよい。ＤＳＬＴ−ＭＦ１２０４は、各ＤＳＬＴ内で構成される優先順位を考慮にいれて、これをそのスケジューリングアルゴリズムに含んで、低優先順位ＤＳＬＴの前に高優先順位ＤＳＬＴを実行できるようにしてよい。
【０２１４】
（ＤＳＬＴプロシージャ）
以下のプロシージャでは、正常なＤＳＬＴ処理シナリオについて記載する。
【０２１５】
（個々のＤＳＬＴ処理）
図２１は、個々のＤＳＬＴプロシージャを示す図である。
【０２１６】
図２１のステップ１は、任意のステップである。図２１のステップ１では、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２がＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４にＤＳＬＴポリシーリソースを生成するようにリクエストを送信する。各ポリシーリソースは、ＤＳＬＴ−ＭＦ１２０４がＤＳＬＴリクエストをどのように処理するかを制御するための１つまたは複数のルールを含んでよい。これらのルールは、ＤＳＬＴスケジューリング、ＤＳＬＴの再試行、ＤＳＬＴの優先順位付け、ＤＳＬＴ向けの実行基準および完了基準に関連してよい。あるいは、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴポリシーによって事前にプロビジョンされてもよい。
【０２１７】
図２１のステップ２は、任意のステップである。図２１のステップ２では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、リクエストを受信して処理し、ＤＳＬＴポリシーリソースを生成する。ＤＳＬＴ−ＭＦ１２０４はポリシーリソースを生成し、さらに、ポリシーで規定されたルールによってそのＤＳＬＴポリシーエンジン１３０８の設定も行う。
【０２１８】
図２１のステップ３は、任意のステップである。図２１のステップ３では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２に応答を返して、ポリシーリソースで定義されたルールが受諾されたか否か通知する。受諾されなかった場合、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＭＦ１２０４によって受諾されたルールの修正バージョンを提供してよい。
【０２１９】
図２１のステップ４では、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２がＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＴＲＩＧＧＥＲリクエストを送信する。リクエストは、ターゲットノード（例えば、ＩｏＴデバイス１およびＩｏＴデバイス２）のセット、これらのノードで実施する操作、この操作をいつ実施するかのスケジュール、実行基準のセット、優先順位、トランザクションの処理の試みが失敗した場合の再試行の回数、完了基準のセット、ＤＳＬＴ−ＭＦ１２０４がトランザクションを非ブロッキング式に処理するのに使用してもよいＤＳＬＴ識別子およびコンタクト情報などのいくつかのパラメータを含んでよい。
【０２２０】
図２１のステップ５では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエストを受信して処理を開始する。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴリクエストリソースを生成して、ＤＳＬＴの処理の間、状態を追跡する。ＤＳＬＴ−ＭＦ１２０４は、ステップ４で示したＤＳＬＴ−ＴＲＩＧＧＥＲリクエストパラメータに含まれた情報を用いてリソースの属性を構成する。
【０２２１】
図２１のステップ６では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、リクエストを受信して処理を開始したことを示す応答をＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２に返すことによって、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエストを非ブロッキング式に処理する。あるいは、ＤＳＬＴ−ＭＦ１２０４は、このリクエストをブロッキング式に処理してもよい。
【０２２２】
図２１のステップ７では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエストを解析し、対象とされるリソースのリストを見つける。ＤＳＬＴ−ＭＦ１２０４は、ターゲットリソースが、ＩｏＴサーバでローカルにホストされておらず、ＩｏＴデバイス１および２によってホストされていることを検出する。その後、ＤＳＬＴ−ＭＦ１２０４は、これらのターゲットデバイスに配布する対応するＤＳＬＴ−ＲＥＱを準備する。リクエストの配布の前に、ＤＳＬＴ−ＣＦ１２１０はまず、スケジュール情報がＤＳＬＴ−ＴＲＩＧＧＥＲリクエストで、またはいずれかのＤＳＬＴスケジュール関連ポリシー内で明確に構成されたかどうかをチェックする。ＤＳＬＴ−ＭＦ１２０４はまた、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエストまたはいずれかのＤＳＬＴスケジュールポリシーにおいて、いずれかの優先順位が明確に設定されたかどうかをチェックする。明確に設定されていた場合、ＤＳＬＴ−ＭＦ１２０４は、既に受信して、かつ処理の必要があるその他のＤＳＬＴ−ＴＲＩＧＧＥＲリクエストがあるかどうかをチェックする。ある場合、ＤＳＬＴ−ＭＦ１２０４は、優先順位およびスケジュール情報を使用して、ＤＳＬＴ−ＴＲＩＧＧＥＲリクエストの実行を互いに対して順位付けおよび順序付けする。一旦、スケジュールおよび優先順位によって順序付けが行われると、ＤＳＬＴ−ＭＦ１２０４は、それに応じてターゲットにＤＳＬＴ−ＲＥＱを配布する。ＤＳＬＴ−ＭＦ１２０４の優先順位付けポリシーに応じて、処理が進行されているＤＳＬＴ−ＴＲＩＧＧＥＲよりも優先順位が高い新しいＤＳＬＴ−ＴＲＩＧＧＥＲが受信される場合、ＤＳＬＴ−ＭＦ１２０４は、処理が進行されているＤＳＬＴ−ＴＲＩＧＧＥＲを完了するか、または新たに届いた優先順位の高いＤＳＬＴ−ＴＲＩＧＧＥＲを処理するために割り込みしてもよい。割り込みする場合は、ＤＳＬＴ−ＭＦ１２０４は、後で処理を再開するのに有利なように、トランザクションを中止してロールバックするか、またはＤＳＬＴ−ＭＦ１２０４は、優先順位の高いトランザクションを処理している間処理を一時停止し、その後、処理を再開してよい。中止するか割り込みするかの判断は、優先順位の高いトランザクションが、処理が進行されている優先順位の低いものと同じリソースを対象としているかどうかなど、いくつかの要因に基づくものであってよい。この場合、ＤＳＬＴ−ＭＦ１２０４は優先順位の低いトランザクションの中止を決定してよいが、その一方で、２つのトランザクションが異なるリソースを対象としているケースでは、ＤＳＬＴ−ＭＦ１２０４は、優先順位の低いトランザクションへの割り込みを選択するか、またはサポートされている場合は、両方のトランザクションを並行して実行してよい。
【０２２３】
図２１のステップ８では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ−ＣＦ１２０８および１２１０は、それぞれのＤＳＬＴ−ＲＥＱを受信する。どちらともリクエストを処理し、ローカルＤＳＬＴリソースを生成して、ＤＳＬＴ−ＲＥＱを処理している間、トランザクションの状態を追跡する。ＤＳＬＴ−ＣＦ１２０８および１２１０は、ＤＳＬＴ−ＲＥＱパラメータ内に含まれている情報を用いてそれらのリソースの属性を構成する。ＤＳＬＴ−ＣＦ１２０８および１２１０は、まず、ターゲットリソースの利用可能性をチェックすることからトランザクションの処理を開始する。リソースがＩｏＴデバイスに対してローカルの場合、ＤＳＬＴ−ＣＦ１２１０は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合は、ＤＳＬＴ−ＣＦ１２１０は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施してもよいようにリソースをロックしてよい。ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＲＥＱを受信して、リクエストがローカルデバイスでホストされていないリソースを対象としていることを見つけた場合、ＤＳＬＴ−ＣＦ（場合によっては、デバイスでホストされているローカルＤＳＬＴ−ＭＦ１２０４と提携している）は、その他のデバイスのＤＳＬＴ−ＣＦ１２１０がそれを処理してもよいように、システム内の別のデバイスに向けてＤＳＬＴ−ＲＥＱリクエストを再度対象としてよい。
【０２２４】
図２１のステップ９では、各ＩｏＴデバイスのＤＳＬＴ−ＣＦ１２１０は、ＤＳＬＴ−ＲＥＱが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、他のトランザクションから干渉を受けることなく現在のトランザクションが進行できるようにリソースがロックされたことを示すステータスをＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４に返す。
【０２２５】
図２１のステップ１０では、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１および２の両方）が、ターゲットリソースを正常にロックしたと応答したことを、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４が検出する。その結果、ＤＳＬＴ−ＭＦ１２０４は、トランザクションの実行をするように、ターゲットＤＳＬＴ−ＣＦに続いて命令してよいと判断する。ＤＳＬＴ−ＭＦ１２０４が全てのターゲットから正常なロックの応答を受信しなかった場合、いずれかの完了基準がトランザクションのために構成されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＭＦ１２０４が手順を進めることが基準によって許容されているかどうかをチェックしてよい（例えば、基準は、全てのターゲットではなく、ターゲットのサブセットのみでトランザクションが完了することが必要とされると規定している場合がある）。あるいは、トランザクションのうちの１つまたは複数がターゲットリソースのロックに失敗した場合、ＤＳＬＴ−ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるよう設定されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ−ＭＦ１２０４は失敗したトランザクションを再試行してもよい。この場合、ＤＳＬＴ−ＭＦ１２０４は、失敗したＤＳＬＴ−ＣＦに再試行を送信してよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ−ＭＦ１２０４が判断する場合は、ＤＳＬＴ−ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ−ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ−ＣＦ１２０８および１２１０）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ−ＣＦは、トランザクションによって対象とされたリソースに対して行われたいずれの変更もトランザクションの開始前と同じ状態に戻されるようにロールバックすることによってトランザクションを中止する。ＤＳＬＴ−ＣＦは、ターゲットリソースのロックの解放もしてよい。
【０２２６】
あるいは、ＤＳＬＴ−ＣＦ１２１０は、ステップ８でリソースのロックができなかった場合、リソースが利用不可能である理由（リソースが存在しない、アクセス権が不適正である、リソースが既にロックされているなど）に関する表示を提供してよい。リソースがロックされている場合、ＤＳＬＴ−ＣＦ１２１０は、（ロックリソースに関連付けられたタイムアウトに基づいて）リソースがいつアンロックされる可能性があるかの時間の表示を提供してもよい。この場合、ＤＳＬＴ−ＭＦ１２０４は、（ＤＳＬＴ−ＣＦ１２１０によって提供された情報に基づいて）しばらくしてからトランザクションの再試行を試みてよい。
【０２２７】
図２１のステップ１１では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、各ターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にリクエストを送信して、トランザクションを実行するようコマンドする。このコマンドは、ＤＳＬＴ−ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイスでホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ−ＣＦ１２０８および１２１０にトランザクションを実行するように命令する。
【０２２８】
図２１のステップ１２では、トランザクションの実行のコマンドを受信すると、各デバイスのＤＳＬＴ−ＣＦ１２１０は、ターゲットリソースでトランザクションに規定された操作を実施する。ターゲットリソースでの操作の結果として、ＩｏＴデバイスの複数のリソースの状態が変化することもある。ＤＳＬＴ−ＲＥＱが中止され、ロールバックされる必要がある場合に、必要があれば、ＤＳＬＴ−ＣＦ１２１０は（操作の実行前の）操作前の状態のコピーを保持する。
【０２２９】
図２１のステップ１３では、一旦、実行が完了すると、各ＤＳＬＴ−ＣＦ１２１０は、実行結果、およびそれが成功したのか否かについて、ＤＳＬＴ−ＭＦ１２０４に応答を返す。
【０２３０】
図２１のステップ１４では、全てのターゲットＤＳＬＴ−ＣＦ（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がターゲットリソースでトランザクションを正常に実行したと応答したことを、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４が検出する。その結果、ＤＳＬＴ−ＭＦ１２０４は、結果（例えば、更新されたリソース表現）を耐久的なものにし、かつリソースおよびその更新済み状態に他のトランザクションがアクセスできるようにリソースのロックを解放することによって結果をコミットするように、ターゲットＤＳＬＴ−ＣＦ１２０８および１２１０に続いて命令してよいと判断する。ＤＳＬＴ−ＭＦ１２０４は、全てのターゲットから正常な実行の応答を受信しなかった場合は、いずれかの完了基準がトランザクションに設定されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＭＦ１２０４が手順を進めることが基準によって許容されているかどうかをチェックしてよい（例えば、基準は、トランザクションが全てのターゲットではなく、ターゲットのサブセットで完了することのみを要すると規定している場合がある）。あるいは、実行されたトランザクションのうちの１つまたは複数が失敗した場合、ＤＳＬＴ−ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるように設定されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ−ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ−ＭＦ１２０４が判断した場合、ＤＳＬＴ−ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ−ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ−ＣＦ）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ−ＣＦ１２１０は、トランザクションによって対象とされたリソースに対して行われたいずれの変更もトランザクションの開始前と同じ状態に戻されるようにロールバックすることによってトランザクションを中止する。ＤＳＬＴ−ＣＦ１２１０は、ターゲットリソースのロックの解放もしてよい。
【０２３１】
図２１のステップ１５では、ＩｏＴサーバ１２３０のＤＳＬＴ−ＭＦ１２０４は、各ターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にリクエストを送信して、トランザクションをコミットするようコマンドする。このコマンドは、ＤＳＬＴ−ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイスでホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ−ＣＦ１２０８および１２１０にトランザクションをコミットするように命令する。
【０２３２】
図２１のステップ１６では、トランザクションをコミットするコマンドを受信すると、各デバイスのＤＳＬＴ−ＣＦ１２０８および１２１０は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。ＤＳＬＴ−ＣＦ１２０８および１２１０は、コミットされるリソースの状態のいずれかの更新に基づいて、ターゲットリソースにサブスクライブした可能性のあるシステム内のいずれの他のエンティティにも更新状態に関する通知を送信してもよい。次いで、ＤＳＬＴ−ＣＦ１２０８および１２１０は、ターゲットリソースのいずれのロックも解放し、保存した操作前状態のいずれも削除してよい。
【０２３３】
図２１のステップ１７では、一旦、コミットが完了すると、各ＤＳＬＴ−ＣＦ１２０８および１２１０は、コミット結果、およびそれが成功したか否かと共に、ＤＳＬＴ−ＭＦ１２０４に応答を返す。
【０２３４】
図２１のステップ１８では、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がターゲットリソースでトランザクションを正常にコミットしたと応答したことを、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４が検出する。コミットのうちの１つまたは複数が失敗した場合、ＤＳＬＴ−ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるように設定されているか否かチェックしてもよい。再試行が許可されている場合、ＤＳＬＴ−ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ−ＭＦ１２０４が判断する場合は、ＤＳＬＴ−ＭＦ１２０４はトランザクションのエラー状況を報告してよい。
【０２３５】
図２１のステップ１９では、ＤＳＬＴ−ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２から受信したＤＳＬＴに対応する、そのローカルにホストされているＤＳＬＴリソースを更新する。この更新には、ＩｏＴデバイスに配布して、トランザクションが成功したかどうか、および、成功しなかった場合はその失敗の原因または理由を示すＤＳＬＴのそれぞれのステータスが含まれる。
【０２３６】
図２１のステップ２０では、一旦、ＤＳＬＴ処理が完了すると、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２に、ＤＳＬＴの結果を含めて通知してよい。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴの全体的なステータスおよび個々のターゲットで実施された各配布されたトランザクションの個々のステータスを含めてよい。これは、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。
【０２３７】
図２１のステップ２１では、完了したＤＳＬＴの通知を受信した後、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４に、通知受信の確認を応答してよい。
【０２３８】
図２１のステップ２２では、いずれかの時点で、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２がＤＳＬＴ処理のステータスのチェックを所望する場合、ステータスをチェックするようにＤＳＬＴ−ＭＦ１２０４に問い合わせしてもよい。問い合わせリクエストを受信すると、ＤＳＬＴ−ＭＦ１２０４は、対応するＤＳＬＴリソース内で保持しているＤＳＬＴの状態をチェックしてよい。
【０２３９】
図２１のステップ２３では、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴステータス問い合わせを開始したＤＳＬＴ−ＴＦ１２０２にＤＳＬＴ処理の状態を返す。
【０２４０】
（ＤＳＬＴシーケンスプロシージャ）
図２２は、ＤＳＬＴシーケンスプロシージャを示す図である。
【０２４１】
図２２のステップ１は、任意のステップである。図２２のステップ１では、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２が、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４にＤＳＬＴシーケンスポリシーリソースを生成するようリクエストを送信する。各ポリシーリソースは、ＤＳＬＴ−ＭＦがＤＳＬＴシーケンスリクエストをどのように処理するか制御する１つまたは複数のルールを含んでよい。これらのルールは、ＤＳＬＴシーケンススケジューリング、ＤＳＬＴシーケンスの再試行、ＤＳＬＴシーケンスの優先順位付け、ならびに、ＤＳＬＴシーケンス向けの実行基準および完了基準に関連してよい。あるいは、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴシーケンスポリシーを用いて事前にプロビジョンされてもよい。
【０２４２】
図２２のステップ２は、任意のステップである。図２２のステップ２では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、リクエストを受信し処理し、ＤＳＬＴシーケンスポリシーリソースを生成する。ＤＳＬＴ−ＭＦ１２０４はポリシーリソースを生成し、さらに、ポリシーで規定されたルールによってそのＤＳＬＴポリシーエンジン１３０８の設定も行う。
【０２４３】
図２２のステップ３は、任意のステップである。図２２のステップ３では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２に応答を返して、ポリシーリソースで定義されたルールが受諾されたか否か通知する。受諾されなかった場合、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＭＦ１２０４によって受諾されたルールの修正バージョンを提供してよい。
【０２４４】
図２２のステップ４では、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２がＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４にＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを送信する。リクエストは、ターゲットノード（例えば、ＩｏＴデバイス１およびＩｏＴデバイス２）のセット、これらのノードで実施するＤＳＬＴのリスト、シーケンスをいつ実施するかのスケジュール、シーケンス実行基準のセット、優先順位、トランザクションのシーケンスの処理の試みが失敗した場合の再試行の回数、シーケンス完了基準のセット、ＤＳＬＴ−ＭＦ１２０４がシーケンスを非ブロッキング式に処理するのに使用し得るＤＳＬＴシーケンス識別子およびコンタクト情報などのいくつかのパラメータを含んでよい。
【０２４５】
図２２のステップ５では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストを受信して処理を開始する。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴシーケンスリソースを生成して、ＤＳＬＴシーケンスの処理の間、トランザクションシーケンスの状態を追跡する。ＤＳＬＴ−ＭＦ１２０４は、ステップ４で示したＤＳＬＴシーケンスリクエストパラメータに含まれた情報を用いてリソースの属性を構成する。
【０２４６】
図２２のステップ６では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、リクエストを受信して処理を開始したことを示す応答をＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２に返すことによって、リクエストを非ブロッキング式に処理する。あるいは、ＤＳＬＴ−ＭＦ１２０４は、このリクエストをブロッキング式に処理してもよい。
【０２４７】
図２２のステップ７では、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、リクエストを解析し、シーケンスによって対象とされるリソースのリストを見つける。ＤＳＬＴ−ＭＦ１２０４は、ターゲットリソースが、ＩｏＴサーバでローカルにホストされておらず、ＩｏＴデバイス１および２によってホストされていることを検出する。その後、ＤＳＬＴ−ＭＦ１２０４は、これらのターゲットデバイスに配布するシーケンス内の最初の／次の対応するＤＳＬＴを準備する。ＤＳＬＴの配布の前に、ＤＳＬＴ−ＭＦ１２０４はまず、スケジュール情報が元々のＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストで、またはいずれかのスケジュール関連ポリシー内で明確に設定されたかどうかをチェックする。ＤＳＬＴ−ＭＦ１２０４はまた、優先順位が元々のＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストで、またはいずれかのポリシーで明確に設定されたかどうかをチェックする。明確に設定されている場合、ＤＳＬＴ−ＭＦ１２０４は、既に受信して処理の必要があるその他のＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストがあるかどうかをチェックする。ある場合、ＤＳＬＴ−ＭＦ１２０４は、優先順位情報を使用して、ＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストの実行を互いに対して順位付けおよび順序付けする。一旦、スケジュールおよび優先順位によって順序付けが行われると、ＤＳＬＴ−ＭＦ１２０４は、それに応じてターゲットにＤＳＬＴ−ＲＥＱリクエストを配布する。
【０２４８】
一旦、スケジュールおよび優先順位によって順序付けが行われると、ＤＳＬＴ−ＭＦ１２０４は、それに応じてターゲットにＤＳＬＴ−ＲＥＱを配布する。ＤＳＬＴ−ＭＦ１２０４の優先順位付けポリシーに応じて、処理が進行されているＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲよりも優先順位の高い新たなＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲが受信される場合は、ＤＳＬＴ−ＭＦ１２０４は、処理が進行されているＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲを完了するか、または新たに届いた優先順位の高いＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲを処理するために割り込みしてもよい。シーケンスを割り込みする場合は、ＤＳＬＴ−ＭＦ１２０４は、後で処理を再開するのに有利なように、シーケンスを中止してロールバックするか、またはＤＳＬＴ−ＭＦ１２０４は、優先順位の高いシーケンスを処理している間シーケンスの処理およびその関連するＤＳＬＴを一時停止し、その後処理を再開してよい。中止するか割り込みするかの判断は、優先順位の高いシーケンスが、処理が進行されている優先順位の低いシーケンスと同じリソースを対象としているかどうかなど、いくつかの要因に基づくものであってよい。この場合、ＤＳＬＴ−ＭＦ１２０４は優先順位の低いシーケンスの中止を決定してよいが、その一方で、２つのシーケンスが異なるリソースを対象としているケースでは、ＤＳＬＴ−ＭＦ１２０４は、優先順位の低いシーケンスへの割り込みを選択するか、またはサポートされている場合は、両方のシーケンスを並行して実行してもよい。
【０２４９】
図２２のステップ８では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ−ＣＦ１２０８および１２１０は、それぞれのＤＳＬＴ−ＲＥＱを受信する。どちらともリクエストを処理し、ローカルＤＳＬＴリソースを生成して、ＤＳＬＴを処理している間、トランザクションの状態を追跡する。ＤＳＬＴ−ＣＦ１２０８および１２１０は、ＤＳＬＴ−ＲＥＱパラメータ内に含まれている情報を用いてそれらのリソースの属性を構成する。ＤＳＬＴ−ＣＦ１２０８および１２１０は、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。リソースがＩｏＴデバイスに対してローカルの場合、ＤＳＬＴ−ＣＦ１２１０は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合は、ＤＳＬＴ−ＣＦ１２１０は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施してもよいようにリソースをロックしてよい。ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＲＥＱを受信して、リクエストがローカルデバイスでホストされていないリソースを対象としていることを見つける場合、ＤＳＬＴ−ＣＦ１２１０は、（場合によっては、デバイスでローカルにホストされているＤＳＬＴ−ＭＦ１２０４の支援によって）その他のデバイスのＤＳＬＴ−ＣＦがそれを処理できるように、システム内の別のデバイスに向けてＤＳＬＴ−ＲＥＱを再対象としてよい。
【０２５０】
図２２のステップ９では、各ＩｏＴデバイスのＤＳＬＴ−ＣＦ１２１０は、リクエストが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、リソースがロックされて、他のトランザクションから干渉を受けることなく現在のトランザクションが処理できることを示すステータスをＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４に返す。
【０２５１】
図２２のステップ１０では、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）が、ターゲットリソースを正常にロックしたと応答したことを、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４が検出する。その結果、ＤＳＬＴ−ＭＦ１２０４は、トランザクションの実行をするように、ターゲットＤＳＬＴ−ＣＦ１２１０に続いて命令してよいと判断する。ＤＳＬＴ−ＭＦ１２０４が全てのターゲットから正常なロックの応答を受信しなかった場合、いずれかの完了基準がトランザクションのために設定されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＭＦ１２０４が手順を進めることを基準によって許容されているかどうかをチェックしてよい（例えば、基準は、トランザクションが全てのターゲットではなく、ターゲットのサブセットで完了することのみを要すると規定している場合がある）。あるいは、トランザクションのうちの１つまたは複数がターゲットリソースのロックに失敗した場合、ＤＳＬＴ−ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再実行されるように構成されているのか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ−ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ−ＭＦ１２０４が判断する場合は、ＤＳＬＴ−ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ−ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ−ＣＦ１２０８および１２１０）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ−ＣＦ１２１０は、トランザクションによって対象とされたリソースに対して行われたいずれの変更もトランザクションの開始前と同じ状態に戻されるようにロールバックすることによってトランザクションを中止する。ＤＳＬＴ−ＣＦ１２１０は、ターゲットリソースのロックの解放もしてよい。
【０２５２】
あるいは、ＤＳＬＴ−ＣＦ１２１０は、ステップ８でリソースのロックができなかった場合、リソースが利用不可能である理由（リソースが存在しない、アクセス権が不適正である、リソースが既にロックされているなど）に関する表示を提供してよい。リソースがロックされている場合、ＤＳＬＴ−ＣＦ１２１０は、（ロックリソースに関連付けられたタイムアウトに基づいて）リソースがいつアンロックされる可能性があるかの時間の表示を提供してもよい。この場合、ＤＳＬＴ−ＭＦ１２０４は、（ＤＳＬＴ−ＣＦ１２１０によって提供された情報に基づいて）しばらくしてからトランザクションの再試行行を試みてよい。
【０２５３】
図２２のステップ１１では、ＩｏＴサーバ１２３０のＤＳＬＴ−ＭＦ１２０４は、各ターゲットＤＳＬＴ−ＣＦ１２０８および１２１０にリクエストを送信して、トランザクションを実行するようにコマンドする。このコマンドは、ＤＳＬＴ−ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイス１２３４および１２３６でホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ−ＣＦ１２０８および１２１０にトランザクションを実行するように命令する。
【０２５４】
図２２のステップ１２では、トランザクションの実行のコマンドを受信すると、各デバイスのＤＳＬＴ−ＣＦ１２０８および１２１０は、ターゲットリソースでトランザクションに規定された操作を実施する。ターゲットリソースでの操作の結果として、ＩｏＴデバイスの複数のリソースの状態が変化することもある。ＤＳＬＴ−ＲＥＱが中止され、ロールバックされる必要がある場合に、必要があれば、ＤＳＬＴ−ＣＦ１２０８および１２１０は（操作の実行前の）操作前の状態のコピーを保持する。
【０２５５】
図２２のステップ１３では、一旦、実行が完了すると、各ＤＳＬＴ−ＣＦ１２０８および１２１０は、実行結果、およびそれが成功したのか否かについて、ＤＳＬＴ−ＭＦ１２０４に応答を返す。
【０２５６】
図２２のステップ１４では、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がターゲットリソースでトランザクションを正常に実行したと応答したことを、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４が検出する。次いで、ＤＳＬＴ−ＭＦ１２０４は、シーケンス内に残存するＤＳＬＴがあるかどうかをチェックする。残存するＤＳＬＴがある場合、ＤＳＬＴ−ＭＦ１２０４は、次のＤＳＬＴを準備して、ステップ７〜１４を繰り返す。シーケンス内に残存するＤＳＬＴがない場合、ＤＳＬＴ−ＭＦ１２０４は、シーケンスの一部として処理された全てのＤＳＬＴの結果をコミットするように、ターゲットＤＳＬＴ−ＣＦ１２０８に続いて命令してよいと判断する。結果を耐久的にすること、かつリソースのロックを解放することによって、リソースおよびその更新状態に他のトランザクションがアクセスできるようにする。ＤＳＬＴ−ＭＦ１２０４は、全てのターゲットから正常な実行の応答を受信しなかった場合、いずれかの完了基準がトランザクションに設定されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴ−ＭＦ１２０４が手順を進めることが基準によって許容されているかどうかをチェックしてよい（例えば、基準は、全てのターゲットではなく、ターゲットのサブセットのみでトランザクションが完了することが必要とされると規定している場合がある）。あるいは、実行されたトランザクションのうちの１つまたは複数が失敗した場合、ＤＳＬＴ−ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるように設定されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ−ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ−ＭＦ１２０４が判断する場合、ＤＳＬＴ−ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ−ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ−ＣＦ１２０８および１２１０）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ−ＣＦ１２０８および１２１０はシーケンス内の各トランザクションを中止することによってシーケンスを中止する。これにより、シーケンス内のトランザクションによって対象とされていたリソースに対して行われたいずれの変更もシーケンスの開始前と同じ状態に戻されるようにロールバックされる。ＤＳＬＴ−ＣＦ１２０８および１２１０は、ターゲットリソースのロックの解放もしてよい。
【０２５７】
図２２のステップ１５では、ＩｏＴサーバ１２３０のＤＳＬＴ−ＭＦ１２０４は、各ＤＳＬＴが実行された各ターゲットＤＳＬＴ−ＣＦ１２０８および１２１０に一連のコミットリクエストを送信する。このコマンドは、ＤＳＬＴ−ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイス１２３４および１２３６でホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ−ＣＦ１２０８および１２１０にトランザクションをコミットするように命令する。
【０２５８】
図２２のステップ１６では、所定のＤＳＬＴをコミットする各コマンドを受信すると、各デバイスのＤＳＬＴ−ＣＦ１２０８および１２１０は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。ＤＳＬＴ−ＣＦ１２０８および１２１０は、コミットされるリソースの状態のいずれの更新にも基づいて、ターゲットリソースにサブスクライブした可能性のあるシステム内のいずれの他のエンティティにも更新状態に関する通知を送信してもよい。次いで、ＤＳＬＴ−ＣＦ１２０８および１２１０は、ターゲットリソースのいずれのロックも解放し、保存した操作前状態のいずれも削除してよい。
【０２５９】
図２２のステップ１７では、一旦、各コミットが完了すると、各ＤＳＬＴ−ＣＦ１２０８および１２１０は、コミット結果、およびそれが成功したか否かと共に、ＤＳＬＴ−ＭＦ１２０４に応答を返す。
【０２６０】
図２２のステップ１８では、全てのターゲットＤＳＬＴ−ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がそれぞれのターゲットリソースでシーケンス内の全てのトランザクションを正常にコミットしたと応答したことを、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４が検出する。コミットのうちの１つまたは複数が失敗した場合、ＤＳＬＴ−ＭＦ１２０４は、それぞれのトランザクションシーケンスがその設定パラメータまたはポリシー設定を介して再実行されるように構成されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ−ＭＦ１２０４は失敗したトランザクションシーケンスを再試行してもよい。完了基準を満たすことができず、トランザクションシーケンスの再試行ができないとＤＳＬＴ−ＭＦ１２０４が判断する場合は、ＤＳＬＴ−ＭＦ１２０４はトランザクションシーケンスのエラー状況を報告することを選択してもよい。
【０２６１】
図２２のステップ１９では、ＤＳＬＴ−ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２から受信したＤＳＬＴ−ＳＥＱ−ＴＲＩＧＧＥＲリクエストに対応する、そのローカルにホストされているＤＳＬＴシーケンスリソースを更新する。この更新には、ＩｏＴデバイスに配布されるシーケンス内のＤＳＬＴのそれぞれのステータスが含まれる。このステータスは、トランザクションシーケンスが成功したかどうかを示し、成功しなかった場合はその失敗の理由を示す。ＤＳＬＴ−ＭＦ１２０４は、シーケンス内の失敗したいずれのＤＳＬＴの個々のステータスおよび失敗の情報も含めてもよい。
【０２６２】
図２２のステップ２０では、一旦、ＤＳＬＴシーケンス処理が完了すると、ＩｏＴサーバのＤＳＬＴ−ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２にＤＳＬＴシーケンスの結果を含めて通知してよい。ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴシーケンスの全体的なステータスおよび個々のターゲットで実施されたシーケンス内の各配布されたトランザクションの個々のステータスを含めてよい。これは、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。
【０２６３】
図２２のステップ２１では、完了したＤＳＬＴシーケンスの通知の受信後、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２は、ＤＳＬＴ−ＭＦ１２０４に、通知受信の確認を応答してよい。
【０２６４】
図２２のステップ２２では、いずれかの時点で、ＩｏＴアプリケーションのＤＳＬＴ−ＴＦ１２０２がＤＳＬＴシーケンス処理のステータスのチェックを所望する場合、ステータスをチェックするようにＤＳＬＴ−ＭＦ１２０４に問い合わせしてよい。問い合わせリクエストを受信すると、ＤＳＬＴ−ＭＦ１２０４は、対応するＤＳＬＴシーケンスリソース内で保持しているＤＳＬＴシーケンスの状態をチェックしてよい。
【０２６５】
図２２のステップ２３では、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴステータス問い合わせを開始したＤＳＬＴ−ＴＦ１２０２にＤＳＬＴシーケンス処理の状態を返す。
【０２６６】
（ｏｎｅＭ２Ｍ分散サービス層トランザクション実施形態）
ｏｎｅＭ２Ｍアーキテクチャ[oneM2M  TS-0001]を対象とするＤＳＬＴメカニズムおよびプロシージャのいくつかの実施形態について以下に説明する。ＤＳＬＴサポートをｏｎｅＭ２Ｍアーキテクチャに加えることで、全てのリクエストが正常に実施されるか、またはいずれのリクエストも実施されないかどちらかとなるような原子的に実施される複数のリソースをターゲットとするリクエストのセットを可能にする。
【０２６７】
ＤＳＬＴ−ＭＦ１２０４および／またはＤＳＬＴ−ＣＦ１２１０は、ｏｎｅＭ２Ｍアーキテクチャの内部で、図２３に示すように、共通サービスエンティティ（ＣＳＥ）（すなわち、サービス層エンティティ）の新しいトランザクション管理共通サービス機能（ＣＳＦ）として実現可能である。
【０２６８】
このトランザクション管理ＣＳＦ２３０４は、ｏｎｅＭ２ＭシステムにおいてＤＳＬＴサポートを可能にするために使用されてよい。あるいは、ＤＳＬＴ−ＭＦ１２０４は、１つまたは複数の既存のｏｎｅＭ２Ｍ  ＣＳＦ（図１〜６に示さず）の性能として実現されてもよい。
【０２６９】
ＤＳＬＴ−ＴＦ１２０２および／またはＤＳＬＴ−ＣＦ１２１０の機能は、ｏｎｅＭ２Ｍアプリケーションエンティティ（ＡＥ）２３０６によってサポートされてもよい。例えば、ＡＥ２３０６はそのＤＳＬＴ−ＴＦ１２０２を介してＤＳＬＴリクエストを開始して、ＣＳＥ２３０２によってホストされているＤＳＬＴ−ＭＦ２３０４にこのリクエストを送信してもよい。あるいは、ＡＥ２３０６は、ＣＳＥによってホストされているＤＳＬＴ−ＭＦ１２０４からそのＤＳＬＴ−ＣＦ１２１０を介してＤＳＬＴリクエストを受信してもよい。
【０２７０】
ＣＳＥ２３０２およびＡＥ２３０６がＤＳＬＴ機能をサポートすることを可能にするために、以下のサブセクションでは、いくつかのＤＳＬＴｏｎｅＭ２Ｍ実施形態を定義する。
【０２７１】
（ｏｎｅＭ２ＭリクエストパラメータへのＤＳＬＴ拡張）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴをサポートするために、ＤＳＬＴおよびＤＳＬＴシーケンスメッセージパラメータのそれぞれに対して新しいｏｎｅＭ２Ｍリクエストパラメータが表３および表４で定義されている。これらのパラメータをｏｎｅＭ２Ｍリクエスト内でサポートすることで、複数のｏｎｅＭ２Ｍリクエストを互いに関連付けてｏｎｅＭ２Ｍリクエストのセットとして一緒に原子的に処理することを可能にする。
【０２７２】
トランザクションベースの処理をサポートするために、既存のｏｎｅＭ２Ｍ応答タイプパラメータを拡張して、非ブロッキングトランザクションリクエスト同期（ｎｏｎＢｌｏｃｋｉｎｇＴｒａｎｓａｃｔｉｏｎＲｅｑｕｅｓｔＳｙｎｃｈ）および非ブロッキングトランザクションリクエスト非同期（ｎｏｎＢｌｏｃｋｉｎｇＴｒａｎｓａｃｔｉｏｎＲｅｑｕｅｓｔＡｓｙｎｃｈ）の２つの追加の非ブロッキング応答タイプを追加サポートしてもよい。これらの２つの応答タイプは、非ブロッキングであり原子的なトランザクションとしてホスティングＣＳＥによってリクエストが処理されることを規定するために、発信元によって使用されてよい。これらの新しい値の１つに設定された応答タイプを備えるリクエストを受信するときに、ホスティングＣＳＥは、後のセクションに記載されているような、ｏｎｅＭ２Ｍ＜ｒｅｑｕｅｓｔ＞リソースへの追加の新しいトランザクション指向属性をサポートしてよい。これらの新しいトランザクション指向応答タイプおよび＜ｒｅｑｕｅｓｔ＞属性により、後のセクションに詳述されているプロシージャにてさらに記載されているような原子的なトランザクション指向方式で、ホスティングＣＳＥがプリミティブを処理することを可能にする。あるいは、ホスティングＣＳＥは、他の方法で、例えば、いくつかの追加のＤＳＬＴ属性または＜ｓｅｑｕｅｎｃｅ＞リソースと共に、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースをサポートすることによっても、同様にＤＳＬＴをサポートしてもよい。
【０２７３】
（ｏｎｅＭ２Ｍ  ＤＳＬＴリソース）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴをサポートするために、いくつかのＤＳＬＴ関連属性が使用されてよい。これらの属性は、図２４に示すように、＜ｒｅｑｕｅｓｔ＞リソースまたは＜ｔｒａｎｓａｃｔｉｏｎ＞リソースなどの既存のｏｎｅＭ２Ｍリソースに加えられてよい。あるいは、新しいリソースタイプは、これらの属性をサポートするように定義されてもよい。新しいリソースタイプが定義されているケースでは、完全なソリューションを提供するために、＜ｒｅｑｕｅｓｔ＞リソースおよび／または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースで既に定義されている属性のいくつかに類似する追加属性を組み込むことを必要としてもよい。これらの既存のｏｎｅＭ２Ｍ属性は、簡潔にするために組み込まれていなかった。１つの例は、ｏｎｅＭ２Ｍリクエストプリミティブに含まれるプリミティブ属性である。この属性は、＜ｒｅｑｕｅｓｔ＞リソースおよび＜ｔｒａｎｓａｃｔｉｏｎ＞リソースにて既存のものである（図示せず）。
【０２７４】
これらの新しい属性により、発信元（例えば、ＡＥまたはＣＳＥ）がターゲットＣＳＥに対してＤＳＬＴリクエストを発行し、ＣＳＥにそのリクエストを非ブロッキング式かつ原子的に処理させることを可能にする。
【表８−１】
2020514912.tif 000010
【表８−２】
2020514912.tif 000011
【０２７５】
（ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスリソース）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴシーケンスをサポートするために、いくつかのＤＳＬＴシーケンス属性を有する＜ｓｅｑｕｅｎｃｅ＞リソースを図２５に示す。
【０２７６】
この新しいリソースおよび属性により、発信元（例えば、ＡＥまたはＣＳＥ）がＤＳＬＴシーケンスリクエストを発行し、ホスティングＣＳＥに非ブロッキング式にかつ原子的にＤＳＬＴのシーケンスを処理させることを可能にする。この処理は、シーケンス内の個別のＤＳＬＴが原子的に実行されること、およびＤＳＬＴのシーケンス全体も原子的に（すなわち、全てのＤＳＬＴが正常に実行されるか、またはいずれのＤＳＬＴも実行されないかどちらかとなるように）実行されることを保証するために、発信元に代わって、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥによる個別のＤＳＬＴのシーケンスの処理を含んでよい。これにより、発信元からのＤＳＬＴシーケンスの処理のオーバーヘッドおよび負担を軽減することができる。この機能は、発信元が繰り返しリクエストを作成して、ＤＳＬＴシーケンスを送信する場合に、特に有用となる可能性がある。発信元は、これらの繰り返しＤＳＬＴシーケンスをそれ自体で処理しなければならないのではなく、この動作をその代わりに実施する＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥに肩代わりさせることができる。
【０２７７】
シーケンス内のＤＳＬＴが＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥによってホストされているローカルリソースを対象とする場合、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、これらのＤＳＬＴをそれ自体で原子的に処理してよい。この処理の間に、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、これらのローカルリソースをロックして、処理が進行されているシーケンス内のＤＳＬＴによって規定された操作以外は、該ローカルリソースでいずれの操作も実施されないことを保証してよい。一旦、進行中のシーケンスの処理が正常に完了してコミットされると、このロックは解放されてよい。
【０２７８】
シーケンス内のＤＳＬＴが、遠隔のＣＳＥでホストされているリソースを対象とする場合、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、ＤＳＬＴ属性を有する遠隔ＣＳＥに＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを生成することによって、遠隔ＣＳＥにＤＳＬＴリクエストを送信してよい。＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、次いで、遠隔ＣＳＥのこれらの＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの状態を管理して、ＤＳＬＴが原子的に処理されることを保証してよい。＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、ターゲットリソースのロックを取得できるという遠隔ＣＳＥからの通知を待ってよい。一旦、通知が受信されると、次に、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、遠隔ＣＳＥに、対応する＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースのコマンド属性を更新することによってＤＳＬＴを実行するように命令してよい。次に、遠隔ＣＳＥは、トランザクションが正常に実行されたという遠隔ＣＳＥからの通知を待ってよい。一旦、通知が受信されると、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、遠隔ＣＳＥに、対応する＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースのコマンド属性がさらにまた更新されるまでに、結果が耐久的なものとなるようにトランザクションの結果をコミットするように命令してよい。次に、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、結果が正常にコミットされたという遠隔ＣＳＥからの通知を待ってよい。一旦、コミットが成功したという通知が受信されると、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、シーケンスリクエストの処理を完了して、その発信元に応答を返してよい。この応答は、ブロッキング式にまたは非ブロッキング式に返されてよい。この処理中のいずれかのステップにおいて、遠隔ＣＳＥがシーケンス内のいずれかのＤＳＬＴを正常にロック、実行またはコミットできなかった場合、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥはシーケンスを中止して、対応する＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースのコマンド属性がさらにまた更新されるまでに、これらのホスティングＣＳＥによって、ターゲットリソースがロールバックされることを保証してよい。このロールバックに続いて、リソースは、ＤＳＬＴシーケンス処理が開始される前と同じ状態に戻されてよい。
【表９】
2020514912.tif 000012
【０２７９】
（ｏｎｅＭ２Ｍ  ＤＳＬＴポリシーリソース）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴポリシー構成をサポートするために、いくつかのＤＳＬＴポリシー属性を表１０に定義する。これらの属性は、ｏｎｅＭ２Ｍ  ＣＭＤＨ機能について定義されたような既存のｏｎｅＭ２Ｍ＜ｍｇｍｔＯｂｊ＞特化などの既存のｏｎｅＭ２Ｍリソースに追加されてよい。あるいは、ＤＳＬＴ機能に固有の新しいｏｎｅＭ２Ｍ＜ｍｇｍｔＯｂｊ＞特化などのこれらの属性をサポートするように、新しいリソースタイプが定義されてもよい。例えば、新しい特化が、ＤＳＬＴスケジューリングポリシー、ＤＳＬＴ再試行ポリシー、ＤＳＬＴ優先順位付けポリシー、ＤＳＬＴ完了基準ポリシーおよびＤＳＬＴシーケンスポリシーに定義されてもよい。
【０２８０】
これらの新しい属性により、発信元（例えば、ＡＥまたはＣＳＥ）は、ＤＳＬＴリクエストをＣＳＥがどう処理するかを制御するＤＳＬＴ関連ポリシーをＣＳＥ内に構成することができる。
【表１０】
2020514912.tif 000013
【０２８１】
（ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースへのＤＳＬＴ拡張）
１つまたは複数のＣＳＥでホストされている複数のターゲットリソースへの原子的な配布およびＤＳＬＴの処理をサポートするために、図２６に示すように、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースへの新しい＜ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＰｏｉｎｔ＞仮想リソースおよび新しいｔｒａｎｓａｃｔｉｏｎＳｔａｔｅ属性が使用されてよい。この新しいリソースおよび属性は、ＤＳＬＴリクエストの発信元によって任意に使用されてよい。このリソースが使用された場合、グループホスティングＣＳＥが発信元に代わってＤＳＬＴリクエストの処理を取り扱ってよい。この処理には、グループによって規定されたメンバーリソースのそれぞれへのＤＳＬＴのファンアウトを含んでよい。メンバーリソースが遠隔ＣＳＥでホストされている場合、グループホスティングＣＳＥは、メンバーリソースを対象とする＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを生成することによって遠隔ＣＳＥへＤＳＬＴをファンアウトしてよい。処理には、グループホスティングＣＳＥが、対応する各メンバーリソースの各ＤＳＬＴの状態を管理することを含んでもよい。これは、発信元の代わりに行われて、ＤＳＬＴが互いに対して原子的に（すなわち、全てが正常に実行されるか、またはいずれも実行されないかのどちらか一方で）実行されることを保証してもよい。これにより、発信元からのＤＳＬＴの処理のオーバーヘッドおよび負担を軽減することができる。この機能は、発信元が、繰り返しリクエストを作成して、多数のターゲットにＤＳＬＴを送信する場合に、特に有用となる可能性がある。発信元は、多数のターゲットリソース向けにこれらの繰り返しＤＳＬＴをそれ自体で処理しなければならないのではなく、この動作をその代わりに実施するグループホスティングＣＳＥに肩代わりさせることができる。あるいは、ＤＳＬＴの発信元がＤＳＬＴをそれ自体で管理する場合は、発信元はこの新しいリソースを使用せずにその管理を行ってもよい。
【０２８２】
この仮想リソースは表現を持たないが、＜ｇｒｏｕｐ＞リソースの子リソースである。ｏｎｅＭ２Ｍリクエストプリミティブが、＜ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＰｏｉｎｔ＞リソースに送信される場合は常に、グループホスティングＣＳＥは、親＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒＩＤ属性によって規定されたメンバーのそれぞれに、対応するＤＳＬＴ  ＣＲＥＡＴＥリクエストをファンアウトすることによってリクエストを処理してよい。発信元またはグループホスティングＣＳＥで構成されるローカルポリシーによって規定されている場合、メンバーにファンアウトする各ＤＳＬＴ  ＣＲＥＡＴＥリクエスト向けに、グループホスティングＣＳＥは、発信元から受信した元のリクエストプリミティブを有する属性、「Ｉｎｉｔｉａｌ」の値を有する状態属性、結果の満了時間パラメータよりも小さな値を有するｅｘｅｃｕｔｉｏｎＴｉｍｅ属性を構成してよい。その後、グループホスティングＣＳＥは、ファンアウトされたＤＳＬＴリクエストの取り扱いを、互いに対して原子的に（すなわち、ファンアウトされたトランザクションの全てが正常に完了するか、またはその全てが中止されるかのどちらか一方で）全て処理されるように調整してよい。メンバーホスティングＣＳＥにファンアウトされたＤＳＬＴ  ＣＲＥＡＴＥリクエストに対して、これらのＣＳＥは、規定された実行時間においてメンバーリソースで規定されたプリミティブを実施できるかどうかをチェックしてよい。チェックが成功する場合、メンバーホスティングＣＳＥは、ＤＳＬＴを正常に生成したと、グループホスティングＣＳＥに応答を返してよい。チェックが成功しない場合、メンバーホスティングＣＳＥは、その失敗結果と共に応答を返してもよい。トランザクションの処理に対して、グループホスティングＣＳＥによってタイマーが継続されてよい。タイマーの満了前に各メンバーホスティングＣＳＥからＤＳＬＴの正常生成の応答が受信される場合、トランザクションを次に進めて実行することができる。グループホスティングＣＳＥは、任意選択でコマンドを各メンバーホスティングＣＳＥに送信して、トランザクションを実行し、コミットすることを命令してよい。トランザクションが進行できない場合、グループホスティングＣＳＥは、ＤＳＬＴを正常に生成したと示したいずれのメンバーホスティングＣＳＥにも、ＤＳＬＴ  ＤＥＬＥＴＥリクエストを送信することによってトランザクションを中止してもよい。トランザクションが実行できる場合、メンバーで実行した各リクエストプリミティブからの個々の応答は、グループホスティングＣＳＥに返されてよい。次に、グループホスティングＣＳＥは、応答を集約して、発信元に結果を返してよい。応答の集約のためにグループホスティングＣＳＥによってタイマーが継続されてもよい。全ての応答が受信されるか、タイマーが満了すると、応答は集約される。時間満了後に受信される応答は、破棄されてよい。この処理中のいずれかのステップにおいて、グループホスティングＣＳＥが、グループメンバーのそれぞれから、ＤＳＬＴをロック、実行またはコミットできるという成功の確認を受け取らない場合は、グループホスティングＣＳＥは、ＤＳＬＴを中止して、���ーゲットメンバーリソースがそれぞれのメンバーホスティングＣＳＥによってロールバックされることを保証してよい。このロールバックに続いて、リソースは、ＤＳＬＴ処理が開始される前と同じ状態に戻されてよい。グループホスティングＣＳＥは、トランザクションの処理状態（例えば、開始（ｉｎｉｔｉａｌ）、ロックされた（ｌｏｃｋｅｄ）、実行された（ｅｘｅｃｕｔｅｄ）、コミットされた（ｃｏｍｍｉｔｔｅｄ）、または中止された（ａｂｏｒｔｅｄ））を用いて更新されたｔｒａｎｓａｃｔｉｏｎＳｔａｔｅ属性を保持してもよい。
【０２８３】
別の実施形態では、新しい属性（例えば、ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＥｎａｂｌｅ）が、代わりに＜ｇｒｏｕｐ＞リソースに追加されてもよい。この属性を使用して、＜ｇｒｏｕｐ＞の既存の＜ｆａｎＯｕｔＰｏｉｎｔ＞仮想リソースを対象とするリクエストが、ＤＳＬＴまたは非ＤＳＬＴリクエストとして次に進むべきかどうかを限定してよい。この選択肢については、図２６に示していない。
【０２８４】
さらに別の実施形態では、グループホスティングＣＳＥは、代わりに、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースの既存の＜ｆａｎｏｕｔＰｏｉｎｔ＞を対象とするリクエストが、ＤＳＬＴとして処理されるべきか否か検出するために、リクエスト内の１つまたは複数のＤＳＬＴ関連パラメータの存在に依存してよい。
【０２８５】
（ｏｎｅＭ２Ｍロック属性）
全てのｏｎｅＭ２Ｍリソースに、追加のｏｎｅＭ２Ｍ「ｌｏｃｋ」共通属性が使用されてよい。この新しい属性は、リソースがロック状態かどうかを追跡し、かつ通知するために、ホスティングＣＳＥによって使用されてよい。例えば、ＤＳＬＴが処理されるときに、そのターゲットリソースはロックされてよい。ロックされると、ロック属性は、リソースがロックされたことを反映するために更新されてよい。この属性は、ｔｒｕｅまたはｆａｌｓｅなどの値で構成されてよい。あるいは、この属性は、様々なタイプのロック（例えば、更新のためのみにロックされるなど）に反映する値をサポートしてもよい。
【０２８６】
（ｏｎｅＭ２Ｍ  ＤＳＬＴ識別子）
ＤＳＬＴ機能をサポートするために、ｏｎｅＭ２Ｍ  ＤＳＬＴ識別子が使用されてよい。個々のＤＳＬＴリクエストの処理には、それぞれが固有の異なるｏｎｅＭ２Ｍリクエスト識別子を有する複数のｏｎｅＭ２Ｍリクエストを必要とする場合があるので、ＤＳＬＴ識別子は、これらの別々のｏｎｅＭ２Ｍリクエストを単一のＤＳＬＴに関連付けるメカニズムを提供する。この関連付けのレベルにより、ＤＳＬＴを構成する個々のｏｎｅＭ２Ｍリクエストの、分散され、かつ原子的処理を可能にする。表１１は、ｏｎｅＭ２Ｍ  ＤＳＬＴ識別子フォーマットの説明である。表１２は、ｏｎｅＭ２Ｍ  ＤＳＬＴベースのリクエスト識別子の構成の説明である。
【表１１】
2020514912.tif 000014
【表１２】
2020514912.tif 000015
【０２８７】
ＤＳＬＴシーケンス機能をサポートするために、ＤＳＬＴシーケンス用のｏｎｅＭ２Ｍ識別子について記載する。ＤＳＬＴシーケンスの処理には複数のＤＳＬＴの処理を必要とする場合があり、各ＤＳＬＴの処理にはそれぞれが固有の異なるｏｎｅＭ２Ｍリクエスト識別子を有する複数のｏｎｅＭ２Ｍリクエストの処理を必要とする場合があるので、ＤＳＬＴシーケンス識別子は、これらの複数のＤＳＬＴおよびｏｎｅＭ２Ｍリクエストを単一のＤＳＬＴシーケンスに関連付けるメカニズムを提供する。この関連付けのレベルにより、ＤＳＬＴシーケンスを構成する個々のＤＳＬＴおよびｏｎｅＭ２Ｍリクエストの、分散され、かつ原子的処理を可能にする。表１３は、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンス識別子フォーマットの説明である。表１４は、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスベースのＤＳＬＴ識別子の構成の説明である。表１５は、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスベースのリクエスト識別子の構成の説明である。
【表１３】
2020514912.tif 000016
【表１４】
2020514912.tif 000017
【表１５】
2020514912.tif 000018
【０２８８】
（ｏｎｅＭ２Ｍ  ＤＳＬＴグループファンアウトプロシージャ）
図２７−１および２７−２は、ｏｎｅＭ２Ｍ  ＤＳＬＴグループファンアウトプロシージャを示す図である。
【０２８９】
図２７−１および２７−２のステップ１では、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースが生成される。グループのメンバーは、ＡＳＮ−ＣＳＥ１およびＡＳＮ−ＣＳＥ２でホストされるコンテナリソースとなるように構成される。このグループはＤＳＬＴ−ＴＦ１２０２をホストしているＡＥまたはシステム内の別のＡＥによって生成されてよい。
【０２９０】
図２７−１および２７−２のステップ２では、ＤＳＬＴ−ＴＦ１２０２機能をホストしているＡＥは、ＡＳＮ−ＣＳＥ１およびＡＳＮ−ＣＳＥ２によってホストされているコンテナリソースに属するｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を原子的に生成するためにｏｎｅＭ２Ｍ  ＤＳＬＴリクエストを構築する。このＤＳＬＴリクエストは、図２７−１および２７−２に示すように、ｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。あるいは、このＤＳＬＴリクエストは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのプリミティブ属性内にカプセル化するｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞ＣＲＥＡＴＥリクエストプリミティブとして構成されてもよい。図２７−１および２７−２には示されていないが、リクエストは、同様に、いつ操作を実施するかのスケジュール、実行基準のセット、優先順位、トランザクションの処理の試みが失敗した場合の再試行の回数、および完了基準のセットなどの追加のパラメータを含んでよい。
【０２９１】
図２７−１および２７−２のステップ３では、ＤＳＬＴ−ＴＦ１２０２機能をホストしているＡＥは、ＤＳＬＴ−ＭＦ１２０４性能をサポートしているＩＮ−ＣＳＥ２７０２にＤＳＬＴリクエストを送信する。リクエストは、ＩＮ−ＣＳＥ２７０２がメンバーにリクエストを原子的に配布することによってリクエストを処理できるようにステップ１で生成されたグループリソースの＜ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＰｏｉｎｔ＞子リソースに送信される。このリクエストは、新しいタイプのｏｎｅＭ２Ｍ非ブロッキングリクエストである非ブロッキングトランザクションリクエストを使用して送信されてよい。このリクエストでは、非ブロッキングリクエストの処理が完了したときに通知する際にＩＮ−ＣＳＥ２７０２が使用することになる通知コールバックＵＲＩをＡＥが規定してよい。あるいは、ＡＥは代わりにブロッキングリクエストを使用することもできる。
【０２９２】
図２７−１および２７−２のステップ４では、ＩＮ−ＣＳＥ２７０２はＤＳＬＴリクエストを受信する。リクエストが非ブロッキングトランザクションとして送信される場合、ＩＮ−ＣＳＥ２７０２は、トランザクション指向属性をサポートし、かつ状態属性を「Ｉｎｉｔｉａｌ」と構成するｏｎｅＭ２Ｍ＜ｒｅｑｕｅｓｔ＞リソースを生成する。この＜ｒｅｑｕｅｓｔ＞リソースは、ＤＳＬＴを処理している間に、ＤＳＬＴリクエストリソースを追跡するために、ＩＮ−ＣＳＥ２７０２によって使用されてよい。
【０２９３】
図２７−１および２７−２のステップ５では、ＩＮ−ＣＳＥ２７０２は、リクエストを受信して処理を開始したことを示す応答をＡＥに返す。あるいは、リクエストはブロッキング式に処理されてもよい。
【０２９４】
図２７−１および２７−２のステップ６では、ＩＮ−ＣＳＥ２７０２は、次にグループトランザクションファンアウト性能を使用してＤＳＬＴを処理する。
【０２９５】
図２７−１および２７−２のステップ７では、ＩＮ−ＣＳＥ２７０２は、グループメンバーリソースがＩＮ−ＣＳＥ２７０２でローカルにホストされていないことを検出する。その後、ＩＮ−ＣＳＥ２７０２は対応するＤＳＬＴリクエスト（すなわち、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブ）を準備し、これらのターゲットデバイスに配布（すなわち、ファンアウト）する。このＤＳＬＴは、図２７−１および２７−２に示すように、非ブロッキングｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。あるいは、このＤＳＬＴリクエストは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのプリミティブ属性内にカプセル化するｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞ＣＲＥＡＴＥリクエストプリミティブとして構成されてもよい。
【０２９６】
図２７−１および２７−２のステップ８では、ＡＳＮ−ＣＳＥ２７０４および１２０６のＤＳＬＴ−ＣＦ１２０８および１２１０は、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を生成するＤＳＬＴをそれぞれ受信して、＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソースを生成することによってリクエストを処理し、ＤＳＬＴを処理している間、トランザクション状態を追跡する。ＡＳＮ−ＣＳＥ２７０４および２７０６は、ＤＳＬＴに含まれるトランザクション情報を用いてこのリソースの状態を構成する。ＡＳＮ−ＣＳＥ２７０４および２７０６は、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。ＡＳＮ−ＣＳＥ２７０４および２７０６は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合、ＡＳＮ−ＣＳＥ２７０４および２７０６は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施できるようにリソースをロックする。
【０２９７】
図２７−１および２７−２のステップ９では、ＡＳＮ−ＣＳＥ２７０４および２７０６は、ＤＳＬＴが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、他のトランザクションから干渉を受けることなく現在のトランザクションが進行できるようにリソースがロックされたことを示すステータスをＩＮ−ＣＳＥ２７０２に返す。
【０２９８】
図２７−１および２７−２のステップ１０では、ＩＮ−ＣＳＥ２７０２は、全てのメンバーがターゲットリソースを正常にロックしたと応答したことを検出する。その結果、ＩＮ−ＣＳＥ２７０２は、トランザクションを実行するように、ターゲットメンバーに続いて命令してよいと判断する。
【０２９９】
図２７−１および２７−２のステップ１１では、ＩＮ−ＣＳＥ２７０２は、トランザクションに関連付けられたその対応する＜ｒｅｑｕｅｓｔ＞リソース内のコマンド属性を更新するように各ＡＳＮ−ＣＳＥ２７０４および２７０６にリクエストを送信する。コマンド属性は、値「Ｅｘｅｃｕｔｅ」に更新される。あるいは、このコマンド属性は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの属性であってもよい。
【０３００】
図２７−１および２７−２のステップ１２では、トランザクションの実行のコマンドを受信すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、ターゲットリソースでトランザクションに規定された操作を実施する。
【０３０１】
図２７−１および２７−２のステップ１３では、一旦、実行が完了すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、実行結果、およびそれが成功したか否かと共に、ＩＮ−ＣＳＥ２７０２に応答を返す。
【０３０２】
図２７−１および２７−２のステップ１４では、ＩＮ−ＣＳＥ２７０２は、全てのグループメンバーがターゲットリソースでトランザクションを正常に実行したと応答したことを検出する。その結果、ＩＮ−ＣＳＥ２７０２は、結果（例えば、更新されたリソース表現）を耐久的なものにし、かつリソースおよびその更新済み状態に他のトランザクションがアクセスできるようにリソースのロックを解放することによって結果をコミットするように、メンバーに続いて命令してよいと判断する。
【０３０３】
図２７−１および２７−２のステップ１５では、ＩＮ−ＣＳＥ２７０２は、各グループメンバーにリクエストを送信して、トランザクションをコミットするようにコマンドする。このコマンドは、ＩＮ−ＣＳＥ２７０２によって発行されてよく、各ＡＳＮ−ＣＳＥ２７０４および２７０６でホストされている＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソース内のコマンド属性を更新し、トランザクションをコミットするように命令する。
【０３０４】
図２７−１および２７−２のステップ１６では、トランザクションをコミットするコマンドを受信すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。次に、ＡＳＮ−ＣＳＥ２７０４および２７０６はターゲットリソースのいずれのロックも解放する。
【０３０５】
図２７−１および２７−２のステップ１７では、一旦、コミットが完了すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、コミット結果、およびそれが成功したか否かと共に、ＩＮ−ＣＳＥ２７０２に応答を返す。
【０３０６】
図２７−１および２７−２のステップ１８では、ＩＮ−ＣＳＥ２７０２は、全てのグループメンバー（すなわち、ＡＳＮ−ＣＳＥ２７０４および２７０６の両方）がターゲットリソースでトランザクションを正常にコミットしたと応答したことを検出する。
【０３０７】
図２７−１および２７−２のステップ１９では、ＩＮ−ＣＳＥ２７０２は、ＡＥから受信したＤＳＬＴに対応する、そのローカルにホストされている＜ｒｅｑｕｅｓｔ＞リソースを更新する。この更新には、グループメンバーに配布して、トランザクションが成功したかどうか、および成功しなかった場合はその失敗の原因または理由を示すＤＳＬＴのそれぞれのステータスが含まれる。
【０３０８】
図２７−１および２７−２のステップ２０では、一旦、ＤＳＬＴ処理が完了すると、ＩＮ−ＣＳＥ２７０２は、ＡＥにＤＳＬＴの結果を含めて通知してよい。ＩＮ−ＣＳＥ２７０２は、ＤＳＬＴの全体的なステータスおよび個々のターゲットで実施された各配布されたトランザクションの個々のステータスを含めてよい。これには、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。
【０３０９】
図２７−１および２７−２のステップ２１では、完了したＤＳＬＴの通知の受信後、ＡＥは、ＩＮ−ＣＳＥ２７０２に、通知受信の確認を応答してよい。
【０３１０】
図２７−１および２７−２のステップ２２では、いずれかの時点で、ＡＥがＤＳＬＴ処理のステータスのチェックを所望する場合、ＩＮ−ＣＳＥ２７０２がホストしている＜ｒｅｑｕｅｓｔ＞リソースに、ステータスをチェックするように問い合わせしてよい。問い合わせリクエストを受信すると、ＩＮ−ＣＳＥ２７０２は、このリソース内で保持されているＤＳＬＴの状態をチェックしてよい。
【０３１１】
図２７−１および２７−２のステップ２３では、ＩＮ−ＣＳＥ２７０２は、ＡＥにＤＳＬＴ処理の状態を返す。
【０３１２】
（ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスプロシージャ）
図２８−１および２８−２は、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスプロシージャを示す図である。
【０３１３】
図２８−１および２８−２のステップ１は、任意のステップである。図２８−１および２８−２のステップ１では、１つまたは複数のｏｎｅＭ２Ｍ  ＤＳＬＴまたはＤＳＬＴシーケンスポリシーリソースが生成される。これらリソースは、ＤＳＬＴ−ＴＦ１２０２をホストしているＡＥまたはシステム内の別のＡＥによって生成されてよい。各ポリシーリソースは、ＩＮ−ＣＳＥ２７０２によってホストされているＤＳＬＴ−ＭＦ１２０４がＤＳＬＴシーケンスリクエストをどのように処理するかを制御するための１つまたは複数のルールを含んでよい。これらのルールは、ＤＳＬＴシーケンススケジューリング、ＤＳＬＴシーケンスの再試行、ＤＳＬＴシーケンスの優先順位付け、ならびに、ＤＳＬＴシーケンス向けの実行基準および完了基準に関連してよい。あるいは、ＩＮ−ＣＳＥ２７０２は、ＤＳＬＴシーケンスポリシーを用いて事前にプロビジョンされてもよい。
【０３１４】
図２８−１および２８−２のステップ２では、ＤＳＬＴ−ＴＦ１２０２機能をホストしているＡＥは、ＡＳＮ−ＣＳＥ２７０４および２７０６によってホストされているコンテナリソースに属する一連のｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を原子的に生成するために、ｏｎｅＭ２Ｍ  ＤＳＬＴシーケンスリクエストを構築する。このＤＳＬＴシーケンスリクエストは、ｏｎｅＭ２Ｍ＜ｓｅｑｕｅｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。＜ｓｅｑｕｅｎｃｅ＞リソースは、一連の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのトランザクション属性内にカプセル化する。各＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブは、ＡＳＮ−ＣＳＥ２７０４および２７０６によってホストされるコンテナリソースとなるように構成されるそのメンバー属性を有するＩＮ−ＣＳＥ２７０２でホストされているグループリソースを対象としてよい。したがって、各＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブは、シーケンス内の別々のトランザクションである。図２７−１および２７−２には示されていないが、個々の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブは、代わりに、ＩＮ−ＣＳＥ２７０２で別々の＜ｔｒａｎｓａｃｔｉｏｎ＞リソースとして生成されてもよい。＜ｓｅｑｕｅｎｃｅ＞リソースのトランザクション属性は、これらの個々の＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを参照する識別子のリストによって構成されてよい。＜ｓｅｑｕｅｎｃｅ＞ＣＲＥＡＴＥプリミティブは、同様に、いつシーケンスを実施するかのスケジュール、実行基準のセット、優先順位、シーケンスの処理が失敗した場合に試みる再試行の回数、および完了基準のセットなどの追加のパラメータを含んでよい。
【０３１５】
図２８−１および２８−２のステップ３では、ＤＳＬＴ−ＴＦ１２０２機能をホストしているＡＥは、ＤＳＬＴ−ＭＦ１２０４性能をサポートしているＩＮ−ＣＳＥ２７０２にＤＳＬＴシーケンスリクエストを送信する。このリクエストは、ブロッキングまたは非ブロッキングリクエストを使用してＩＮ−ＣＳＥ２７０２に送信されてよい。非ブロッキングリクエストが使用される場合、ＡＥは、非ブロッキングリクエストの処理が完了したときに通知する際にＩＮ−ＣＳＥ２７０２が使用することになる通知コールバックＵＲＩを規定してよい。あるいは、ＡＥは、ブロッキングリクエストまたは代わりに既存のｏｎｅＭ２Ｍ非ブロッキングリクエストのうち１つを使用できる。
【０３１６】
図２８−１および２８−２のステップ４では、ＩＮ−ＣＳＥ２７０２はＤＳＬＴシーケンスリクエストを受信する。
【０３１７】
図２８−１および２８−２のステップ５では、ＩＮ−ＣＳＥ２７０２は、リクエストを受信して処理を開始したことを示す応答をＡＥに返す。あるいは、リクエストはブロッキング式に処理されてもよい。図には示されていないが、＜ｓｅｑｕｅｎｃｅ＞リソースに変更（例えば、シーケンスの状態の更新）が生じるときにＩＮ−ＣＳＥ２７０２から通知を受信するために、ＡＥは＜ｓｅｑｕｅｎｃｅ＞リソースにサブスクリプションを生成してもよい。
【０３１８】
図２８−１および２８−２のステップ６では、次に、ＩＮ−ＣＳＥ２７０２は、ＤＳＬＴシーケンスの処理を開始する。
【０３１９】
図２８−１および２８−２のステップ７では、ＩＮ−ＣＳＥ２７０２は、リクエストを解析し、シーケンス内の最初のＤＳＬＴを入手する。ＩＮ−ＣＳＥ２７０２は、このＤＳＬＴがＡＳＮ−ＣＳＥ２７０４および２７０６でホストされているコンテナであるメンバーリソースで構成されるグループリソースを対象としていることを検出する。その後、ＩＮ−ＣＳＥ２７０２は対応するＤＳＬＴリクエスト（すなわち、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブ）を準備し、これらのターゲットデバイスに配布（すなわち、ファンアウト）する。このＤＳＬＴは、図２７−１および２７−２に示すように、非ブロッキングｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。あるいは、ＤＳＬＴリクエストは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのプリミティブ属性内にカプセル化するｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞ＣＲＥＡＴＥリクエストプリミティブとして構成されてもよい。
【０３２０】
図２８−１および２８−２のステップ８では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ−ＣＦ１２０８および１２１０は、それぞれのＤＳＬＴ−ＲＥＱを受信する。どちらともリクエストを処理し、ローカルＤＳＬＴリソースを生成して、ＤＳＬＴを処理している間、トランザクションの状態を追跡する。ＤＳＬＴ−ＣＦは、ＤＳＬＴ−ＲＥＱパラメータ内に含まれている情報を用いてそれらのリソースの属性を構成する。ＤＳＬＴ−ＣＦは、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。リソースがＩｏＴデバイスに対してローカルの場合、ＤＳＬＴ−ＣＦ１２１０は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合は、ＤＳＬＴ−ＣＦは、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施してもよいようにリソースをロックしてよい。ＤＳＬＴ−ＣＦ１２１０がＤＳＬＴ−ＲＥＱを受信して、リクエストがローカルデバイスでホストされていないリソースを対象としていることを見つける場合、ＤＳＬＴ−ＣＦは、（場合によっては、デバイスでローカルにホストされているＤＳＬＴ−ＭＦ１２０４の支援を用いて）その他のデバイスのＤＳＬＴ−ＣＦ１２０８がそれを処理してもよいように、システム内の別のデバイスに向けてＤＳＬＴ−ＲＥＱを再対象としてよい。
【０３２１】
ＡＳＮ−ＣＳＥ２７０４および２７０６のＤＳＬＴ−ＣＦは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を生成するＤＳＬＴをそれぞれ受信し、＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソースを生成することによってリクエストを処理して、ＤＳＬＴを処理している間、トランザクション状態を追跡する。ＡＳＮ−ＣＳＥ２７０４および２７０６は、ＤＳＬＴに含まれるトランザクション情報を用いてこのリソースの状態を構成する。ＡＳＮ−ＣＳＥ２７０４および２７０６は、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。ＡＳＮ−ＣＳＥ２７０４および２７０６は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合、ＡＳＮ−ＣＳＥ２７０４および２７０６は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施できるようにリソースをロックする。
【０３２２】
図２８−１および２８−２のステップ９では、ＡＳＮ−ＣＳＥ２７０４および２７０６は、ＤＳＬＴが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、他のトランザクションから干渉を受けることなく現在のトランザクションが進行できるようにリソースがロックされたことを示すステータスをＩＮ−ＣＳＥ２７０２に返す。
【０３２３】
図２８−１および２８−２のステップ１０では、ＩＮ−ＣＳＥ２７０２は、全てのメンバーがターゲットリソースを正常にロックしたと応答したことを検出する。その結果、ＩＮ−ＣＳＥ２７０２は、トランザクションを実行するように、ターゲットメンバーに続いて命令してよいと判断する。
【０３２４】
図２８−１および２８−２のステップ１１では、ＩＮ−ＣＳＥ２７０２は、トランザクションに関連付けられたその対応する＜ｒｅｑｕｅｓｔ＞リソース内のコマンド属性を更新するように各ＡＳＮ−ＣＳＥにリクエストを送信する。コマンド属性は、値「Ｅｘｅｃｕｔｅ」に更新される。あるいは、このコマンド属性は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの属性であってもよい。
【０３２５】
図２８−１および２８−２のステップ１２では、トランザクションの実行のコマンドを受信すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、ターゲットリソースでトランザクションに規定された操作を実施する。
【０３２６】
図２８−１および２８−２のステップ１３では、一旦、実行が完了すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、実行結果、およびそれが成功したか否かと共に、ＩＮ−ＣＳＥ２７０２に応答を返す。
【０３２７】
図２８−１および２８−２のステップ１４では、ＩＮ−ＣＳＥ２７０２は、全てのターゲットメンバー（すなわち、ＡＳＮ−ＣＳＥ２７０４および２７０６）がターゲットリソースでトランザクションを正常に実行したと応答したことを検出する。次いで、ＩＮ−ＣＳＥ２７０２は、シーケンス内に残存するＤＳＬＴがあるかどうかをチェックする。残存するＤＳＬＴがある場合、ＩＮ−ＣＳＥ２７０２は、次のＤＳＬＴを準備して、ステップ７〜１４を繰り返す。シーケンス内に残存するＤＳＬＴがない場合、ＩＮ−ＣＳＥ２７０２は、結果を耐久的なものにし、かつリソースおよび更新済み状態に他のトランザクションがアクセスできるようにリソースのロックを解放することによって、シーケンスの一部として処理された全てのＤＳＬＴの結果をコミットするように、メンバーに続いて命令してよいと判断する。
【０３２８】
図２８−１および２８−２のステップ１５では、ＩＮ−ＣＳＥ２７０２は、各ＤＳＬＴが実行されたＡＳＮ−ＣＳＥ２７０４および２７０６に一連のコミットリクエストを送信する。各コマンドは、ＩＮ−ＣＳＥ２７０２によって発行されてよく、各ＡＳＮ−ＣＳＥ２７０４および２７０６でホストされている＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソース内のコマンド属性を更新し、対応するトランザクションをコミットするように命令する。
【０３２９】
図２８−１および２８−２のステップ１６では、所定のＤＳＬＴをコミットする各コマンドを受信すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。コミットされるリソースの状態のいずれの更新にも基づいて、ターゲットリソースにサブスクライブした可能性のあるシステム内のいずれの他のエンティティにも更新状態に関する通知を送信してもよい。次いで、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、ターゲットリソースのいずれのロックも解放し、保存した操作前状態のいずれも削除してよい。
【０３３０】
図２８−１および２８−２のステップ１７では、一旦、各コミットが完了すると、各ＡＳＮ−ＣＳＥ２７０４および２７０６は、コミット結果、およびそれが成功したか否かと共に、ＩＮ−ＣＳＥ２７０２に応答を返す。
【０３３１】
図２８−１および２８−２のステップ１８では、ＩＮ−ＣＳＥ２７０２は、それぞれのターゲットＡＳＮ−ＣＳＥ２７０４および２７０６が、それぞれのターゲットリソースでシーケンス内の全てのトランザクションを正常にコミットしたと応答したことを検出する。
【０３３２】
図２８−１および２８−２のステップ１９では、ＩＮ−ＣＳＥ２７０２は、自身のローカルにホストされているＤＳＬＴシーケンスリソースを更新する。この更新には、配布されたシーケンス内のＤＳＬＴのそれぞれのステータスが含まれる。このステータスは、トランザクションシーケンスが成功したかどうかを示し、成功しなかった場合はその失敗の理由を示す。ＩＮ−ＣＳＥ２７０２は、シーケンス内の失敗したいずれのＤＳＬＴの個々のステータスおよび失敗の情報も含めてもよい。
【０３３３】
図２８−１および２８−２のステップ２０では、一旦、ＤＳＬＴシーケンス処理が完了すると、ＩＮ−ＣＳＥ２７０２は、ＡＥにＤＳＬＴシーケンスの結果を含めて通知してよい。ＩＮ−ＣＳＥ２７０２は、ＤＳＬＴシーケンスの全体的なステータスおよび個々のターゲットで実施されたシーケンス内の各配布されたトランザクションの個々のステータスを含めてよい。これは、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。
【０３３４】
図２８−１および２８−２のステップ２１では、完了したＤＳＬＴシーケンスの通知の受信後、ＡＥは、ＩＮ−ＣＳＥ２７０２に、通知受信の確認を応答してよい。
【０３３５】
図２８−１および２８−２のステップ２２では、いずれかの時点で、ＡＥがＤＳＬＴシーケンス処理のステータスのチェックを所望する場合、ＩＮ−ＣＳＥ２７０２にステータスをチェックするように問い合わせしてよい。問い合わせリクエストを受信すると、ＩＮ−ＣＳＥ２７０２は、対応するＤＳＬＴシーケンスリソース内で保持しているＤＳＬＴシーケンスリソースの状態をチェックしてよい。
【０３３６】
図２８−１および２８−２のステップ２３では、ＤＳＬＴ−ＭＦ１２０４は、ＤＳＬＴステータス問い合わせを開始したＤＳＬＴ−ＴＦ１２０２にＤＳＬＴシーケンス処理の状態を返す。
【０３３７】
（分散サービス層トランザクションユーザーインターフェース）
グラフィカルユーザーインターフェース（Graphical  User  Interface：ＧＵＩ）などのインターフェースを使用して、ユーザーが分散トランザクション管理に関連した機能を制御および／または構成することを支援してよい。図２９に示すようなインターフェース２９０２、２９０４、２９０６および２９０８などのユーザーインターフェースを実装して、リクエストが原子的に実施されるような複数のＩｏＴデバイスへのＤＳＬＴベースのリクエストをユーザーが開始できるようにしてもよい。例えば、組立ライン展開などの調整された方式で動作するデバイスのセット上の、制御設定の原子的な更新を実施することなどが挙げられる。受信するＤＳＬＴをどう処理するかを制御するために、デバイス、ゲートウェイ、サーバおよびアプリケーション内のＤＳＬＴ関連ポリシーを構成するためにもユーザーインターフェースを実装してよい。インターフェース２９０２、２９０４、２９０６および２９０８は、図３０Ｃ〜Ｄに示し、以下で述べるようなディスプレイを使用して作られてよいことを理解されたい。
【０３３８】
（Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システムの例）
本明細書に記載されている種々の技術は、ハードウェア、ファームウェア、ソフトウェアまたは適切な場合にこれらの組み合わせと連携して実装されてもよい。かかるハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードで配置される装置に含まれてもよい。本明細書記載の方法を行うために、装置は単独でまたは互いに連携して動作してもよい。本明細書において、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」は同じ意味で用いられる場合がある。
【０３３９】
サービス層は、ネットワークサービスアーキテクチャ内の機能層であってよい。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰまたはＭＱＴＴなどのアプリケーションプロトコル層の上位に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層は、例えば、コントロール層およびトランスポート層／アクセス層などの下位リソース層のコアネットワークにインターフェースも提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシー管理、アクセス制御、およびサービスクラスタ化を含む（サービス）性能または機能の複数のカテゴリーをサポートする。近年、いくつかの業界規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業ネットワーク、およびホームネットワークなどの展開へのＭ２Ｍタイプのデバイスおよびアプリケーションの統合に関連する課題に対処するためにＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、ＣＳＥまたはＳＣＬと呼ばれることもあるサービス層によってサポートされる上述の性能または機能の集合またはセットへのアクセスをアプリケーションおよび／または種々のデバイスに提供することができる。いくつかの例としては、種々のアプリケーションによって一般に使用されることがある、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理が挙げられるが、これらに限定されない。これらの性能または機能は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションが利用できるものである。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装可能であり、それらがそのような性能もしくは機能を使用するために、種々のアプリケーションおよび／またはデバイス（すなわち、そのような機能エンティティ間の機能インターフェース）で具現化される（サービス）性能もしくは機能を提供する機能エンティティである。
【０３４０】
図３０Ａは、１つまたは複数の開示する実施形態がその中で実装される可能性のある、Ｍ２Ｍ（machine-to-machiine）、ＩｏＴ（Internet  of  Things）、またはＷｏＴ（Web  of  Things）通信システム１０の例の図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノード、ならびにＩｏＴ／ＷｏＴサービス層などであってよい。通信システム１０は、開示される実施形態の機能を実装するために使用されてよく、機能、ならびにＤＳＬＴ−ＴＦ１２０２、ＤＳＬＴ−ＭＦ１２０４および１２０６、ＤＳＬＴ−ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ−ＭＦ  ＡＰＩ１３０２、ＤＳＬＴ−ＭＦ処理１３０４、ＤＳＬＴ−ＭＦシーケンス処理１３０６、ＤＳＬＴ−ＭＦポリシーエンジン１３０８、ＤＳＬＴ−ＭＦスケジューラ１３１０、ＤＳＬＴ−ＣＦ  ＡＰＩ１４０２、ＤＳＬＴ−ＣＦ処理１４０４、ＤＳＬＴ−ＣＦシーケンス処理１４０６、ＤＳＬＴ−ＭＦ  ＣＳＦ２３０４、サービス層１０２、アプリケーションプロトコル１０４、アプリケーション１０６、ＣＳＥ３０２、３０６および２３０２、ＡＥ３０４、７０４、７０６、７０８および２３０６、ＮＳＥ３０８、ＩｏＴアプリケーション１００２および１２３０、ＩｏＴデバイス１００４、１００６、１００８、１２３４、１２３６、１２３８および１２４０、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ−ＣＳＥ２７０２、ＡＳＮ−ＣＳＥ２７０４および２７０６、および、インターフェース２９０２、２９０４、２９０６および２９０８などのインターフェースを作る論理的エンティティなどの論理的エンティティを含んでもよい。
【０３４１】
図３０Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣなど）または無線ネットワーク（例えば、ＷＬＡＮ、セルラーなど）、もしくは異種ネットワークのネットワークであってよい。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のユーザーに提供する複数のアクセスネットワークで構成されてよい。例えば、通信ネットワーク１２は、符号分割多重アクセス（Code  Division  Multiple  Access：ＣＤＭＡ）、時分割多重アクセス（Time  Division  Multiple  Access：ＴＤＭＡ）、周波数分割多重アクセス（Frequency  Division  Multiple  Access：ＦＤＭＡ）、直交ＦＤＭＡ（Orthogonal  FDMA：ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（Single-Carrier  FDMA：ＳＣ−ＦＤＭＡ）などの１つまたは複数のチャネルアクセス方法を採用してもよい。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを含んでよい。
【０３４２】
図３０Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含んでもよい。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常は、Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインの両方は、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイスなど）を含んでよい。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４および端末デバイス１８を含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれてもよいことが理解されよう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して、通信回路を使用して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、通信ネットワーク１２などのオペレータネットワーク、または直接無線リンクのいずれかを通して、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が通信できるようにする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または別のＭ２Ｍデバイス１８に送信してもよい。Ｍ２Ｍ端末デバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信してもよい。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信されてもよい。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信してもよい。
【０３４３】
例示的Ｍ２Ｍ端末デバイス１８としては、タブレット、スマートフォン、メディカルデバイス、気温・天候モニター、コネクテッドカー、スマートメーター、ゲームコンソール、携帯情報端末、健康・フィットネスモニター、照明、サーモスタット、機器、ガレージドアおよびアクチュエータ式のデバイス、セキュリティデバイスおよびスマートコンセントなどが挙げられるが、これらに限定されない。
【０３４４】
図３０Ｂを参照すると、図示されているフィールドドメイン内のＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、例えば、以下で説明され、図３０Ｃおよび３０Ｄに図示されるデバイスなどを含む、１つまたは複数のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／ストレージファームなど）などによって、実装されてよい。Ｍ２Ｍサービス層２２は、所望により、任意数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信してよい。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを含むことがある、ネットワークの１つまたは複数のノードによって実装されてよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイ１４およびＭ２Ｍアプリケーション２０に適用するサービス性能を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで、など様々な方法で実装されてよい。
【０３４５】
図示されているＭ２Ｍサービス層２２に類似したＭ２Ｍサービス層２２’がインフラストラクチャドメイン内に存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下位通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２’は、フィールドドメイン内のＭ２Ｍゲートウェイ１４およびＭ２Ｍ端末デバイス１８にもサービスを提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２ＭゲートウェイおよびＭ２Ｍデバイスと通信してよい。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用してもよい。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／ストレージファームなど）を含むネットワークの１つまたは複数のノードによるものである。
【０３４６】
さらに図３０Ｂを参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルなシステムが活用することができるサービス配信性能のコアセットを提供する。これらのサービス性能は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見などの機能を果たすことを可能にする。本質的に、これらのサービス性能は、これらの機能を実装する負担をアプリケーションから取り除くので、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’は、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと連携して、ネットワーク１２を通して通信することも可能にする。
【０３４７】
本発明の方法は、サービス層２２および２２’の一部として実装されてもよい。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）と下位ネットワークインターフェースとのセットを介して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ  Ｍ２ＭおよびｏｎｅＭ２Ｍの両方では、本出願の接続方法を含む可能性のあるサービス層を使用する。ＥＴＳＩ  Ｍ２Ｍのサービス層は、サービス性能層（Service  Capability  Layer：ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（この場合、デバイスＳＣＬ（Device  SCL：ＤＳＣＬ）と称される）、ゲートウェイ（この場合、ゲートウェイＳＣＬ（Gateway  SCL：ＧＳＣＬ）と称される）、および／またはネットワークノード（この場合、ネットワークＳＣＬ（Network  SCL：ＮＳＣＬ）と称される）内に実装される可能性がある。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス性能）のセットをサポートする。１つまたは複数の特定のタイプのＣＳＦのセットのインスタンス化は、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）でホストされる可能性のある共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法などのサービスにアクセスするために、サービス指向アーキテクチャ（Service  Oriented  Architecture：ＳＯＡ）および／またはリソース指向アーキテクチャ（Resource-Oriented  Architecture：ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装することができる。
【０３４８】
一部の実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示したシステムおよび方法と共に使用されてよい。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含んでよく、かつ他の開示したシステムおよび方法と共に使用されてもよい。
【０３４９】
一実施形態では、ＤＳＬＴ−ＴＦ１２０２、ＤＳＬＴ−ＭＦ１２０４および１２０６、ＤＳＬＴ−ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ−ＭＦ  ＡＰＩ１３０２、ＤＳＬＴ−ＭＦ処理１３０４、ＤＳＬＴ−ＭＦシーケンス処理１３０６、ＤＳＬＴ−ＭＦポリシーエンジン１３０８、ＤＳＬＴ−ＭＦスケジューラ１３１０、ＤＳＬＴ−ＣＦ  ＡＰＩ１４０２、ＤＳＬＴ−ＣＦ処理１４０４、ＤＳＬＴ−ＣＦシーケンス処理１４０６、ＤＳＬＴ−ＭＦ  ＣＳＦ２３０４、サービス層１０２、ＣＳＥ３０２、３０６および２３０２、ＮＳＥ３０８、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ−ＣＳＥ２７０２、ＡＳＮ−ＣＳＥ２７０４および２７０６などの論理的エンティティは、図３０Ｂに示すように、Ｍ２Ｍサーバ、Ｍ２ＭゲートウェイまたはＭ２ＭデバイスなどのＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされてよい。例えば、これらの論理的エンティティは、Ｍ２Ｍサービス層インスタンス内の個々のサービス性能を含むか、または既存のサービス性能内のサブ機能を同様に含んでよい。
【０３５０】
Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視などの種々の業界でのアプリケーションを含むことができる。上記のように、システムのデバイス、ゲートウェイ、サーバおよび他のノードにわたって起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合などの機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。
【０３５１】
概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）と下位ネットワークインターフェースとのセットを介して付加価値サービス能力をサポートするソフトウェアミドルウェア層を画定する。ＥＴＳＩ  Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を規定している。ＥＴＳＩ  Ｍ２Ｍのサービス層は、サービス性能層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ  Ｍ２Ｍアーキテクチャの種々の異なるノードで実装される可能性がある。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（この場合、デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（この場合、ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（この場合、ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装される可能性がある。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス性能）のセットをサポートする。１つまたは複数の特定のタイプのＣＳＦのセットのインスタンス化は、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）でホストされる可能性のある共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（Third  Generation  Partnership  Project：３ＧＰＰ）は、マシンタイプコミュニケーション（Machine-Type  Communications：ＭＴＣ）向けのアーキテクチャも規定している。そのアーキテクチャでは、サービス層およびサービス層が提供するサービス性能は、サービス性能サーバ（Service  Capability  Server：ＳＣＳ）の一部として実装される。ＥＳＴＩ  Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬまたはＮＳＣＬで、３ＧＰＰ  ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで、またはネットワークの他のいくつかのノードで具現化される、サービス層のインスタンスは、サーバ、コンピュータおよび他のコンピューティングデバイスまたはノードを含むネットワーク内の１つまたは複数のスタンドアロンノードか、または１つまたは複数の既存のノードの一部としてのどちらかで実行する論理的エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令など）として実装することができる。一例として、サービス層のインスタンスまたはそのコンポーネントは、以下で説明され、図３０Ｃおよび３０Ｄに図示される基本的なアーキテクチャを有するネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）で動作するソフトウェアの形態で実装することができる。
【０３５２】
さらに、本明細書で記載し、図に示した論理的エンティティは、本出願のサービスにアクセスするためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装することができる。
【０３５３】
図３０Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ２２などのネットワーク装置３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。装置３０のアーキテクチャを使用して、本明細書に記載され、かつ図に示された上述の論理的エンティティのいずれかを実装してよい。装置３０は、図３０Ａ〜Ｂに示すようなＭ２Ｍネットワークの一部、または非Ｍ２Ｍネットワークの一部であってもよい。図３０Ｃに示すように、装置３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、電源４８と、全地球測位システム（Global  Positioning  System：ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。装置３０は、送受信機３４および伝送／受信要素３６などの通信回路も含んでもよい。装置３０は、実施形態と一致したままで、上述の要素の任意の副次的組み合わせを含んでよいことを理解されたい。この装置は、本明細書に記載した機能を実装するノードであってもよい。
【０３５４】
プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital  Signal  Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application  Specific  Integrated  Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field  Programmable  Gate  Array：ＦＰＧＡ）回路、任意のその他のタイプの集積回路（Integrated  Circuit：ＩＣ）、状態マシンなどであり得る。概して、プロセッサ３２は、装置のメモリ（例えば、メモリ４４および／またはメモリ４６）に記憶されたコンピュータ実行可能命令を実行して、装置の種々の必要とされる機能を実施してもよい。例えば、プロセッサ３２は、信号コーディング、データ処理、電力制御、入力／出力処理、および／または装置３０が無線または有線環境で動作することを可能にする任意の他の機能を実施してもよい。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（Radio  Access-Layer：ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを実施してもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層などで、認証、セキュリティキー共有および／または暗号化操作などのセキュリティ操作も実施してよい。
【０３５５】
図３０Ｃに示すように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）と連結している。プロセッサ３２は、コンピュータ実行可能命令の実行により、通信回路を制御して、装置３０に接続されているネットワークを介して他のネットワーク装置と通信させてもよい。特に、プロセッサ３２は通信回路を制御して、本明細書および特許請求の範囲で記載される伝送および受信ステップを実施してもよい。図３０Ｃは、プロセッサ３２と送受信機３４とを別個のコンポーネントとして描写するが、プロセッサ３２と送受信機３４とは、電子パッケージまたはチップ内に一体化されてもよいことを理解されよう。
【０３５６】
伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む他の装置に信号を伝送するまたはそこから信号を受信するように構成されてよい。例えば、一実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラーなどの種々のネットワークおよびエアインターフェースをサポートしてよい。一実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であってもよい。更に別の一実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成されてよい。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成されてもよいことを理解されよう。
【０３５７】
加えて、伝送／受信要素３６は、単一の要素として図３０Ｃで描写されているが、装置３０は、任意の数の伝送／受信要素３６を含んでもよい。より具体的には、装置３０は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態では、装置３０は、無線信号を伝送および受信するために、２つまたはそれ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含んでもよい。
【０３５８】
送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、かつ伝送／受信要素３６によって受信される信号を復調するように構成されてよい。上記のように、装置３０は、マルチモード性能を有し得る。したがって、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して装置３０が通信することを可能にするために、送受信機３４は複数の送受信機を含み得る。
【０３５９】
プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６などの任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。例えば、プロセッサ３２は、前述したように、そのメモリ内にセッションコンテキストを記憶してもよい。非取り外し可能メモリ４４は、ランダムアクセスメモリ（Random-Access  Memory：ＲＡＭ）、読み取り専用メモリ（Read-Only  Memory：ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。取り外し可能メモリ４６は、加入者識別モジュール（Subscriber  Identity  Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure  Digital：ＳＤ）メモリカードなどを含んでもよい。別の実施形態では、プロセッサ３２は、サーバまたは家庭用コンピュータなどの装置３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。プロセッサ３２は、システムのステータスを反映するためにディスプレイ上の可視的表示を制御するか、あるいは、ユーザーからの入力を取得するか、もしくは性能または設定に関する情報をユーザーに表示するように構成されてもよい。ディスプレイに表示することができるグラフィカルユーザーインターフェースは、ユーザーが本明細書に記載される機能をインタラクティブに実行できるようにするＡＰＩの上に層化されてもよい。
【０３６０】
プロセッサ３２は、電源４８から電力を得てよく、装置３０内のその他のコンポーネントへの電力を分配および／または制御するように構成されてよい。電源４８は、装置３０に給電するための任意の好適なデバイスであってよい。例えば、電源４８としては、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などが挙げられる。
【０３６１】
プロセッサ３２はまた、装置３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に連結されてよい。装置３０は、実施形態と一致したままで任意の好適な位置決定方法を介して位置情報を取得してもよいことを理解されるであろう。
【０３６２】
プロセッサ３２はさらに、追加の特徴、機能、および／または有線もしくは無線コネクティビティを提供する、１つまたは複数のソフトウェアならびに／もしくはハードウェアモジュールを含み得るその他の周辺機器５２に連結されてよい。例えば、周辺機器５２としては、加速度計、バイオメトリック（例えば、指紋）センサなどの種々のセンサ、ｅ−コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal  Serial  Bus：ＵＳＢ）ポートまたはその他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（Frequency  Modulated：ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどが挙げられる。
【０３６３】
装置３０は、センサ、大衆消費電子製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ健康デバイス、ロボット、産業機器、ドローン、車、トラック、電車または飛行機などの乗物などの他の装置もしくはデバイス内で具現化されてもよい。装置３０は、周辺機器５２のうちの１つを備えることがある相互接続インターフェース等の１つまたは複数の相互接続インターフェースを介して、上記の装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。あるいは、装置３０は、センサ、大衆消費電子製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ健康デバイス、ロボット、産業機器、ドローン、車、トラック、電車または飛行機などの乗物などの装置もしくはデバイスを含んでよい。
【０３６４】
図３０Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイスあるいはその他のノードまたは装置などのＭ２Ｍネットワークの１つまたは複数の論理的エンティティまたはノードを実装するために使用することができる例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備えてもよく、ソフトウェアの形態（ソフトウェアが記憶されるまたはアクセスされる場所や手段は問わない）であってもよいコンピュータ可読命令によって主に制御されてよい。コンピューティングシステム９０は、ＤＳＬＴ−ＴＦ１２０２、ＤＳＬＴ−ＭＦ１２０４および１２０６、ＤＳＬＴ−ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ−ＭＦ  ＡＰＩ１３０２、ＤＳＬＴ−ＭＦ処理１３０４、ＤＳＬＴ−ＭＦシーケンス処理１３０６、ＤＳＬＴ−ＭＦポリシーエンジン１３０８、ＤＳＬＴ−ＭＦスケジューラ１３１０、ＤＳＬＴ−ＣＦ  ＡＰＩ１４０２、ＤＳＬＴ−ＣＦ処理１４０４、ＤＳＬＴ−ＣＦシーケンス処理１４０６、ＤＳＬＴ−ＭＦ  ＣＳＦ２３０４、サービス層１０２、アプリケーションプロトコル１０４、アプリケーション１０６、ＣＳＥ３０２、３０６および２３０２、ＡＥ３０４、７０４、７０６、７０８および２３０６、ＮＳＥ３０８、ＩｏＴアプリケーション１００２および１２３０、ＩｏＴデバイス１００４、１００６、１００８、１２３４、１２３６、１２３８および１２４０、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ−ＣＳＥ２７０２、ＡＳＮ−ＣＳＥ２７０４および２７０６、ならびに、インターフェース２９０２、２９０４、２９０６および２９０８などのインターフェースを作る論理的エンティティなどの論理的エンティティを実行または含んでよい。コンピューティングシステム９０は、例えば、Ｍ２Ｍデバイス、ユーザー端末、ゲートウェイ、ＵＥ／ＧＷ、または、モバイルコアネットワークのノード、サービス層ネットワークアプリケーションプロバイダのノード、端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４を含む任意の他のノードであってよい。かかるコンピュータ可読命令は、コンピューティングシステム９０を稼働させるように、中央演算処理装置（Central  Processing  Unit：ＣＰＵ）９１などのプロセッサ内で実行されてよい。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央演算処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央演算処理装置９１は、複数のプロセッサを備えることがある。コプロセッサ８１は、追加の機能を実施またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる、任意選択のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書を受信またはセッション証明書に基づく認証など、Ｅ２Ｅ  Ｍ２Ｍサービス層セッションのために、開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理してよい。
【０３６５】
動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ転送する、かつ他のリソースから転送する。当該システムバスは、コンピューティングシステム９０内のコンポーネント同士を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを操作するための制御ラインを含む。当該システムバス８０の一例として、ＰＣＩ（周辺コンポーネント相互接続）バスがある。
【０３６６】
システムバス８０に連結されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。当該メモリは、情報の記憶および取得を可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１またはその他のハードウェアデバイスによって読み取られてよく、または変更されてもよい。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供してよい。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザープロセスからシステムプロセスを隔離するメモリ保護機能を提供してよい。したがって、第１のモードで起動するプログラムは、それ自体のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
【０３６７】
加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含んでもよい。
【０３６８】
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。当該視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを用いて実装されてよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる電子コンポーネントを含む。
【０３６９】
さらに、コンピューティングシステム９０は、図３０Ａおよび図３０Ｂのネットワーク１２などの外部通信ネットワークに、コンピューティングシステム９０を接続するために使用され得るネットワークアダプタ９７などの通信回路を備えて、コンピューティングシステム９０がネットワークの他のノードと通信できるようにしてもよい。
【０３７０】
ユーザー端末（User  Equipment：ＵＥ）は、エンドユーザーが通信するために使用するいかなるデバイスであってよい。ユーザー端末（ＵＥ）は、ハンドヘルド電話機、モバイルブロードバンドアダプタを搭載したラップトップコンピュータまたは任意の他のデバイスであってもよい。例えば、ＵＥは、図３０Ａ〜ＢのＭ２Ｍ端末デバイス１８または図３０Ｃのデバイス３０として実装されてよい。
【０３７１】
本明細書に記載されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化されてよく、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含むＭ２Ｍネットワークのノードまたは装置などのマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することを理解されたい。具体的には、ＤＳＬＴ−ＴＦ１２０２、ＤＳＬＴ−ＭＦ１２０４および１２０６、ＤＳＬＴ−ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ−ＭＦ  ＡＰＩ１３０２、ＤＳＬＴ−ＭＦ処理１３０４、ＤＳＬＴ−ＭＦシーケンス処理１３０６、ＤＳＬＴ−ＭＦポリシーエンジン１３０８、ＤＳＬＴ−ＭＦスケジューラ１３１０、ＤＳＬＴ−ＣＦ  ＡＰＩ１４０２、ＤＳＬＴ−ＣＦ処理１４０４、ＤＳＬＴ−ＣＦシーケンス処理１４０６、ＤＳＬＴ−ＭＦ  ＣＳＦ２３０４、サービス層１０２、アプリケーションプロトコル１０４、アプリケーション１０６、ＣＳＥ３０２、３０６および２３０２、ＡＥ３０４、７０４、７０６、７０８および２３０６、ＮＳＥ３０８、ＩｏＴアプリケーション１００２および１２３０、ＩｏＴデバイス１００４、１００６、１００８、１２３４、１２３６、１２３８および１２４０、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ−ＣＳＥ２７０２、ＡＳＮ−ＣＳＥ２７０４および２７０６、ならびに、インターフェース２９０２、２９０４、２９０６および２９０８などのインターフェースを作るデバイスまたはエンティティの操作を含む、上述のステップ、操作または機能のいずれかが、コンピュータ可読記憶媒体に記憶されるコンピュータ実行可能命令の形態で実装されてよい。コンピュータ可読記憶媒体は、情報を記憶するための任意の非一時的（すなわち、有形または物理的）方法もしくは技術に実装される揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は信号を含まない。コンピュータ可読記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（Digital  Versatile  Disks：ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用されてよく、かつコンピュータによってアクセス可能である任意の他の有形もしくは物理的媒体が挙げられるが、それらに限定されない。
【０３７２】
さらに、図１１、１２、１５〜２２、２７および２８に示したステップを実施するエンティティは、図３０Ｃおよび図３０Ｄに示したような無線および／またはネットワーク通信またはコンピュータシステム向けに構成される装置のメモリ内に記憶され、そのプロセッサで実行されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよい論理的エンティティであってよいことが理解される。すなわち、図１１、１２、１５〜２２、２７および２８に示した方法は、図３０Ｃおよび図３０Ｄに示した装置またはコンピュータシステムなどの装置のメモリに記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてよいが、この際、該コンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１１、１２、１５〜２２、２７および２８に示したステップを実施するものである。図１１、１２、１５〜２２、２７および２８に示した１つまたは複数のエンティティおよび関連する機能は、１つまたは複数の仮想化ネットワーク機能の形態で実装されてもよいことも理解される。ネットワーク機能は、必ずしも直接通信する必要はなく、むしろ、転送またはルーティング機能を介して通信してもよい。また、図１１、１２、１５〜２２、２７および２８に示した任意の伝送および受信ステップは、装置の通信回路または装置のプロセッサの制御下にあるエンティティ、およびそれが実行するコンピュータ実行可能命令（すなわち、ソフトウェア）によって実施されてよいことも理解される。
【０３７３】
「リクエストの送信」、「応答の送信」、「リクエストの受信」、「応答の受信」などの表現は、通信ネットワークを介して、通信ネットワークのエンティティへ／エンティティからのメッセージを（例えば、パケットの形態でまたは他の定義されたビットのシーケンスで）送信または受信することを含む場合がある。ここで、メッセージの内容またはデータは、リクエストまたは応答されている内容を受信先に通知するものであることもさらに理解される。したがって、例えば、「リクエストの送信」という表現は、「メッセージリクエストの送信」、「リクエストを含むメッセージの送信」などの表現と、同等のものである場合がある。
【０３７４】
図に示す本開示の主題の好ましい実施形態を説明する際に、明確にするために、特定の用語を使用する。ただし、特許請求の範囲に記載する主題は、そこで選択した特定の用語に限定されることを意図するものではなく、各特定の要素は、同様の目的を達成するために同様の方式で動作する全ての技術的等価物を含むことを理解されたい。
【０３７５】
本明細書の実施例は、最良の態様を含む本発明を開示し、任意のデバイスまたはシステムの作製かつ使用および任意の組み込まれた方法の実行を含む本発明の実施を可能にするために使用される。本発明の特許性のある範囲は、特許請求の範囲によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、特許請求の範囲の文言通りの構造要素を有する場合に、または特許請求の範囲の文言と大きく異ならない同等の構造要素を含む場合に、特許請求の範囲の範囲内であることを意図している。
【図１】
2020514912.tif 000019
【図２】
2020514912.tif 000020
【図３】
2020514912.tif 000021
【図４】
2020514912.tif 000022
【図５】
2020514912.tif 000023
【図６】
2020514912.tif 000024
【図７】
2020514912.tif 000025
【図８】
2020514912.tif 000026
【図９】
2020514912.tif 000027
【図１０】
2020514912.tif 000028
【図１１】
2020514912.tif 000029
【図１２】
2020514912.tif 000030
【図１３】
2020514912.tif 000031
【図１４】
2020514912.tif 000032
【図１５】
2020514912.tif 000033
【図１６】
2020514912.tif 000034
【図１７】
2020514912.tif 000035
【図１８】
2020514912.tif 000036
【図１９】
2020514912.tif 000037
【図２０】
2020514912.tif 000038
【図２１】
2020514912.tif 000039
【図２２】
2020514912.tif 000040
【図２３】
2020514912.tif 000041
【図２４】
2020514912.tif 000042
【図２５】
2020514912.tif 000043
【図２６】
2020514912.tif 000044
【図２７−１】
2020514912.tif 000045
【図２７−２】
2020514912.tif 000046
【図２８−１】
2020514912.tif 000047
【図２８−２】
2020514912.tif 000048
【図２９】
2020514912.tif 000049
【図３０Ａ】
2020514912.tif 000050
【図３０Ｂ】
2020514912.tif 000051
【図３０Ｃ】
2020514912.tif 000052
【図３０Ｄ】
2020514912.tif 000053
【国際調査報告】
2020514912.tif 000054
2020514912.tif 000055
2020514912.tif 000056