特許 7295094 モノのインターネット構成可能イベント・アクション・シーケンシング・フレームワーク

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

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

(11)【特許番号】

(24)【登録日】2023-06-12

(45)【発行日】2023-06-20

(54)【発明の名称】モノのインターネット構成可能イベント・アクション・シーケンシング・フレームワーク

(51)【国際特許分類】

   G06F 9/54 20060101AFI20230613BHJP

   G06F 8/35 20180101ALI20230613BHJP

   G06Q 10/06 20230101ALI20230613BHJP

   G06Q 50/04 20120101ALI20230613BHJP

   G16Y 10/25 20200101ALI20230613BHJP

   G16Y 40/10 20200101ALI20230613BHJP

【ＦＩ】

G06F9/54 C

G06F8/35

G06Q10/06

G06Q50/04

G16Y10/25

G16Y40/10

【請求項の数】 15

(21)【出願番号】P 2020512683

(86)(22)【出願日】2018-09-06

(65)【公表番号】

(43)【公表日】2020-12-17

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

(87)【国際公開番号】W WO2019051028

(87)【国際公開日】2019-03-14

【審査請求日】2021-08-30

(31)【優先権主張番号】62/554,753

(32)【優先日】2017-09-06

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】515222713

【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】リ，クァン

(72)【発明者】

【氏名】シード，デイル，エヌ．

(72)【発明者】

【氏名】チェン，チュオ

(72)【発明者】

【氏名】フリン，ウィリアム，ロバート

(72)【発明者】

【氏名】ムラディン，カタリナ，ミハエラ

(72)【発明者】

【氏名】ディジローラモ，ロッコ

(72)【発明者】

【氏名】ローブ，ショシャナ

(72)【発明者】

【氏名】リ，ホンクン

【審査官】田中 幸雄

(56)【参考文献】

【文献】特開２０１７－１４２７９８（ＪＰ，Ａ）

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

Ｇ０６Ｑ １０／０６

Ｇ０６Ｑ ５０／０４

Ｇ１６Ｙ １０／２５

Ｇ０６Ｆ ９／５４

Ｇ１６Ｙ ４０／１０

Ｇ０６Ｆ ８／３５

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

【請求項1】

モノのインターネット（IoT）システムにおける構成可能イベント・アクション・シーケンシング・プロセス（EASP）のための装置であって、
プロセッサと、
プロセッサに結合されたメモリと、
を含み、
前記メモリは、前記プロセッサによって実行されると、前記プロセッサに動作を実行させる実行可能命令を含み、前記動作は、
アプリケーションのための第１のEASPリソースを作成するためのリクエストを取得することを含み、前記第１のEASPリソースは、前記アプリケーションにおける一連のイベントの状態に関連付けられたRestful（Representational State Transfer-ful）インタフェースによって制御可能なミドルウェアリソースであり、前記一連のイベントのそれぞれは、実行されるアクションをトリガする検出された条件であり、前記動作はさらに、
前記リクエストに応答して、前記第１のEASPリソースを作成することであって、
前記第１のEASPリソースは、前記リクエストによって特定された一連のイベントの状態の現在のステータスと、遷移パラメータと、アクションパラメータとを含むリソースであり、前記遷移パラメータは、検出された条件に基づいて遷移すべき第２のEASPリソースの識別子を含み、前記アクションパラメータは、前記検出された条件に基づいて実行すべき１つ又は複数のアクションを特定する、
ことと、
前記リクエストへの応答として、前記作成された第１のEASPリソースの識別子を含むレスポンスを送信することと、
を含む、
装置。

【請求項2】

前記動作は、
前記アプリケーションのための第２のEASPリソースを追加するリクエストを受信することと、
前記第２のEASPリソースを追加するリクエストに基づき、前記第１のEASPリソースを分析することと、
前記第１のEASPリソースの分析に基づき、EASPがアクティブに実行されている間にEASPの動作に影響を及ぼすことなく、前記第２のEASPリソースをEASPに統合可能なときを決定することと、
をさらに含む、請求項１に記載の装置。

【請求項3】

前記動作は、
アプリケーションのための複数のイベント状態リソースのうち、第２のEASPリソースを更新するリクエストを受信することと、
前記第２のEASPリソースを更新するリクエストに基づき、前記第１のEASPリソースを分析することと、
前記第１のEASPリソースの分析に基づき、EASPがアクティブに実行されている間にEASPの動作に影響を及ぼすことなく、前記第２のEASPリソースをEASPに更新可能なときを決定することと、
をさらに含む、請求項１に記載の装置。

【請求項4】

前記第１のEASPリソースは、イベントの現在の状態を終了できるように、イベントの現在の状態を終了させるイベントの指示を含む、請求項１に記載の装置。

【請求項5】

前記遷移パラメータは、前記検出された条件に基づいて実行されるアクションを含む、請求項１に記載の装置。

【請求項6】

前記動作は、
遷移リソースを作成するリクエストを取得することをさらに含み、
前記遷移リソースは、第２のEASPリソースに関連付けられる、
請求項１に記載の装置。

【請求項7】

前記第１のEASPリソースは、遷移先の次のイベント状態の識別子を含む、請求項１に記載の装置。

【請求項8】

モノのインターネットシステムにおける構成可能イベント・アクション・シーケンシング・プロセス（EASP）のためにコンピュータが実行する方法であって、
アプリケーションのための第１のEASPリソースを作成するためのリクエストを取得することを含み、前記第１のEASPリソースは、前記アプリケーションにおける一連のイベントの状態に関連付けられたRestful（Representational State Transfer-ful）インタフェースによって制御可能なミドルウェアリソースであり、前記一連のイベントのそれぞれは、実行されるアクションをトリガする検出された条件であり、前記方法はさらに、
前記リクエストに応答して、前記第１のEASPリソースを作成することであって、
前記第１のEASPリソースは、前記リクエストによって特定された一連のイベントの状態の現在のステータスと、遷移パラメータと、アクションパラメータとを含むリソースであり、前記遷移パラメータは、検出された条件に基づいて遷移すべき第２のEASPリソースの識別子を含み、前記アクションパラメータは、前記検出された条件に基づいて実行すべき１つ又は複数のアクションを特定する、
ことと、
前記リクエストへの応答として、前記作成された第１のEASPリソースの識別子を含むレスポンスを送信することと、
を含む、
方法。

【請求項9】

前記アプリケーションのための第２のEASPリソースを追加するリクエストを受信することと、
前記第２のEASPリソースを追加するリクエストに基づき、前記第１のEASPリソースを分析することと、
前記第１のEASPリソースの分析に基づき、EASPがアクティブに実行されている間にEASPの動作に影響を及ぼすことなく、前記第２のEASPリソースをEASPに統合可能なときを決定することと、
をさらに含む、請求項８に記載の方法。

【請求項10】

アプリケーションのための複数のイベント状態リソースのうち、第２のEASPリソースを更新するリクエストを受信することと、
前記第２のEASPリソースを更新するリクエストに基づき、前記第１のEASPリソースを分析することと、
前記第１のEASPリソースの分析に基づき、EASPがアクティブに実行されている間にEASPの動作に影響を及ぼすことなく、前記第２のEASPリソースをEASPに更新可能なときを決定することと、
をさらに含む、請求項８に記載の方法。

【請求項11】

前記第１のEASPリソースは、イベントの現在の状態を終了できるように、イベントの現在の状態を終了させるイベントの指示を含む、請求項８に記載の方法。

【請求項12】

前記遷移パラメータは、前記検出された状態に基づいて実行されるアクションを含む、請求項８に記載の方法。

【請求項13】

遷移リソースを作成するリクエストを取得することをさらに含み、
前記遷移リソースは、第２のEASPリソースに関連付けられる、
請求項８に記載の方法。

【請求項14】

前記第１のEASPリソースは、遷移先の次のイベント状態の識別子を含む、請求項８に記載の方法。

【請求項15】

コンピュータプログラムが記憶されたコンピュータ可読記憶媒体であって、
当該コンピュータプログラムは、データ処理ユニットにロード可能であり、当該コンピュータプログラムがデータ処理ユニットによって実行されるときに、当該データ処理ユニットに請求項８から１４のいずれか１項に記載の方法を実行させるように適合される、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本願は、２０１７年９月６日に出願された米国仮特許出願第６２／５５４７５３号「物のインターネット構成可能イベント・アクション・シーケンシング・フレームワーク」の利益を主張し、その内容は参照によりここに組み込まれる。

【背景技術】

【0002】

モノのインターネット（IoT）は新しい技術であり、日々利用される物を含むデバイスを、インターネットまたは何等かのネットワーク技術を介して相互接続し、データの送受信を行うことができるものである。デバイス自体の大小は問われず、センサデータを提供したり、または、アクションを実行するためのアクチュエータコマンドを受信したりし、異なる機能および性能を有してもよい。家庭におけるIoTデバイスの一例は、存在検知センサ、照明、コーヒーメーカ、天井に取り付けられたファン、冷蔵庫、オーディオシステム、スマートテレビ等である。複雑なIoTデバイスは、産業用ロボットや機械、インターネットゲートウェイ、スマートフォン等から、自動運転自動車（またはそのコンポーネント）まで含みうる。

【0003】

IoTアプリケーションは、IoTデバイスが生成する大量の情報を処理するよう構築できる。生データが提供するパターンまたはトレンドを抽出するための分析やデータマイニングを実行できる。伝統的なウェブアプリケーションは、特定のアプリケーション用に利用できるデータセットが限られているため、主として範囲の面で実行できる分析の種類が限定されていた。ここで「限定されていた」とは、必ずしもサイズ面ではなく概ね多様性という面で限定されていたことを意味している。他方、IoT技術は、IoTデバイスによって提供される生データの多様かつ大量のデータセットに対してデータマイニングを実行する能力を提供する。

【0004】

IoTシステム内の多様かつ時には共通点のない「モノ」を結びつけることができるアプリケーションは多数あり得る。たとえば、IoTホームオートメーションシステムは、家屋の所有者のカレンダースケジュールを使用して、相互に関連付けられていない種々のIoTデバイスとインタラクトして種々のIoTデバイスを制御することが可能である。種々のIoTデバイスとは、コーヒーメーカ、スピーカ、照明、HVACシステム、ガレージドア開閉機、自動車などである。ユーザが朝目を覚ますと、シャワーを浴びている間、その日のニュースを浴室のスピーカから流すことができる。ユーザが浴室から出るのを存在検知センサが検知し、カップ１杯のコーヒーを入れ始める。同じように、他の存在検知センサはガレージ内の自動車を遠隔でスタートさせ、ユーザが仕事に行く準備が完了するや否やガレージのドアを開けさせることができる。ガレージドアが閉まった後、HVACシステムはエネルギ使用量を節約するように調整されうる。

【0005】

上記各動作はその前に起こった動作に依存していることが分かる。IoTイベントは、特定の事象の発生の検知、と定義される。たとえば存在検知センサによるユーザの退室の検知、または、ガレージドアを閉めたことの検知などである。他方、IoTアクションは、当該イベントの発生に応じて実行される動作である。たとえば、スピーカからのニュースのストリーミング、自動車の自動遠隔始動、ガレージドアの開放等である。結果的に、IoTイベントとIoTアクションとは互いに関連づけられ、IoTシステムにより提供される現実の生活の中での快適さを実現することを可能にしている。ホームオートメーションのユースケースでは、ユーザのスケジュールが、異なる事象の発生に基づく複数のアクションの順番（シーケンス）を決定する。ユーザがいつも通り通勤することに基づき、あるアクション・セットがトリガされ、ユーザが家で仕事するときや休暇のときは他のアクション・セットが発生するだろう。アクションのシーケンスは、ユーザが寝坊したときには遅らせられさえするだろう。つまりこれらのアクションは、予めプログラムされたスケジュールとは異なり、リアルタイムで発生するイベントの検知によってトリガされる。

【0006】

IoT技術を可能にしている主たる要素の一つが、サービス層（SL）アーキテクチャの特定である。M2MやOCF等の標準化団体（SDO：Standard Developing Organization）は、それによってIoTを実現できるアーキテクチャコンポーネントを定義している。これらのコンポーネントは、物理的エンティティ、仮想エンティティ、リソースモデル、リソースプレゼンテーション、サービス、ケイパビリティ、プロトコルメッセージング等からなる。こうした標準を実装したIoTデバイスは互いに通信可能であり、IoT技術が約束する、種類と量の両面で豊富なデータセットを提供することができる。

【0007】

SLアーキテクチャ内では様々な機能が提供され、それによって収集されたデータを使用したり処理したりすることができる。このような機能の一つがイベントマネージメントである。oneM2Mでは、この機能をアクション・トリガリングと呼ぶ。Open Connectivity Foundationは、シーン、ルール、およびスクリプトを用いた機能等のイベントマネージメントを限定しているが、機能は主としてオペレーションの自動化にフォーカスしており、多様なアクションによるイベント処理にはフォーカスしていない。イベントマネージメントはシステム内のイベントを検知して、当該イベント発生に応じて何等かの結果となるアクションを実行する処理である。IoTシステムでは、この機能は強力なケイパビリティである。なぜなら、様々なソースおよび種類のデータを統合して、上に説明したホームオートメーションのユースケースに見られるように、よりスマートなアプリケーションを可能にするからである。

【発明の概要】

【0008】

IoTアーキテクチャは依然発展中であり、アプリケーションが利用できる大量のデータをどのように使用するのがベストか決めようと試みられている。ここに開示するのは、IoT構成可能イベント・アクション・シーケンシング・メカニズムであり、種々のIoTイベントを相互に関連付けて、IoTシステムにおいて利用可能なデータの複雑な使用を効率的に可能にするようなエンドプロセスを達成するものである。

【0009】

この概要は、以下の詳細な説明においてさらに詳しく説明されるえりすぐりのコンセプトを単純化した形式で紹介する。この概要は、請求される主題事項の重要な特徴または本質的な特徴を示すことは意図しておらず、また、請求される主題事項の範囲を限定するために使用されることも意図していない。さらに、請求される主題事項は、本開示のいずれかの部分において記述されるいずれかの不利益または全部の不利益を解決することのみに限られない。

【図面の簡単な説明】

【0010】

添付図面と関連して例示される、以下の説明からより詳細な理解が得られるであろう。添付図面は以下の通りである。

【0011】

【図1】図１は、例示的赤ワイン製造プロセスを示す図である。

【図2】図２は、例示的IoT構成可能イベント・アクション・シーケンシング・アーキテクチャ・フレームワークを示す図である。

【図3】図３は、EASPリソースヒエラルキーを示す図である。

【図4】図４は、リクエスト処理のためのリソースマネージャの例示的手順を示す図である。

【図5】図５は、IoTシステムに対する実行ユニットアクセス認証の例示的手順を示す図である。

【図6】図６は、実行ユニットによる状態処理の例示的フローを示す図である。

【図7A】図７Ａは、ワイン製造プロセスのオペレーション更新に使用できるステップの概要を示す図である。

【図7B】図７Ｂは、エンジン利用更新の例示的ユースケースを示す図である。

【図8】図８は、更新エンジンの処理の例示的フローを示す図である。

【図9】図９は、ワイン製造ユースケースのための例示的oneM2M<easp>リソースを示す図である。

【図10】図１０は、ワイン製造ユースケースのための例示的oneM2M<eventState>リソースを示す図である。

【図11】図１１は、ワイン製造ユースケースのための例示的oneM2M<transition>リソースを示す図である。

【図12】図１２は、例示的なOCFアーキテクチャにおけるロールの例を示す図である。

【図13】図１３は、例示的な工場ユースケースを示す図である。

【図14】図１４は、EASPリソースの例示的インタラクティブ制御を示す図である。

【図15】図１５は、開示する方法およびシステムに基づき生成され得るグラフィカル・ユーザ・インタフェースに表示され得る例示的テーブルを示す図である。

【図16】図１６は、oneM2Mの実施態様における図１のワイン製造プロセスの例示的ディスプレイを示す図である。

【図17A】図１７Ａは、開示する主題が実装され得る、例示的M2Mまたはモノのインターネット（IoT）通信システムを示す図である。

【図17B】図１７Ｂは、図１７Ａに示すM2M／IoT通信システムにおいて使用され得る例示的アーキテクチャの図である。

【図17C】図１７Ｃは、図１７Ａに示す通信システムにおいて使用され得る例示的M2M／IoT端末またはゲートウェイデバイスの図である。

【図17D】図１７Ｄは、図１７Ａの通信システムの側面が具体化され得る、例示的コンピューティングシステムの図である。

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

【0012】

IoTシステムは、IoTデバイスが生成し得る、サイズおよび多様性の両面で豊富なデータセットを使用し、マイニングし、分析する多くのケイパビリティを提供する。IoTシステムのイベントマネージメント・ケイパビリティは、何等かの基準に照らして種々のデータソースをまとめて関連付け、結果となるアクションを実行して、システム内で利用可能なデータのよりスマートな用途を生み出すことを可能にする。このケイパビリティは強力ではあるものの、イベントとその結果としてのアクションとについて一元的な見方しか提供できない。つまり、イベントはユーザの嗜好と比較され、マッチすれば、システムはなんらかの所望のアクションを実行する。いくつかのIoTユースケースは、動的に発生しうる所定のイベントの発生に基づき異なるアクションを実行することを要求するかもしれない。従来のサービス層（SL）イベントマネージメント・ケイパビリティはこのような機能をサポートしないかもしれず、サポートするとしても、複雑すぎてその機能を効率的に実現できるほどユーザフレンドリーではない可能性がある。

【0013】

従来のアプリケーションプログラミングは、IoTシステム向けにうまく拡張（スケーリング）できないかもしれない。ここに開示するのは、サービス層に鑑みて、より効率的にこれらのユースケースを実現するシステム（たとえばフレームワーク）である。サービス層は、サービス層において利用可能なリソースやサービスを用いて複雑なアプリケーションを構築することができるRESTfulプロセスを提供する。開示するEASPは、サービス層がオペレーションを効率的に管理し、および／または、これらの複雑なアプリケーションを更新することを可能にする。ここで定義するリソース（たとえば、EASPリソース、イベント状態リソース、遷移リソース）は、重要なサポートをEASPシステムに提供する。

【0014】

赤ワイン製造ユースケースは、IoTシステムにおけるより高度なイベントマネージメント・ケイパビリティの必要性を示すことができる。図１は、ブドウを収穫したのちの赤ワイン製造における高レベルのプロセスステップを示す。このステップは大まかに以下のように説明できる。ブドウを軸から外して破砕し（ステップ２０１）、醸し（ステップ２０２）、発酵させ（ステップ２０３）、液を循環させ（ポンプオーバ、ステップ２０４）、圧搾と澱引きを行い（ステップ２０５）、マロラクティック発酵させ（ステップ２０６）、樽熟成させ（ステップ２０７）、清澄化して瓶詰する（ステップ２０８）。

【0015】

ステップ２０１において、収穫されたブドウは除梗機またはベルトコンベヤに乗せられ、ブドウが軸から分離される。さらにブドウを破砕して果汁と皮とが混ぜ合わされて発酵するようにする。果汁とブドウの固形部分とを「ムスト」と呼ぶ。ステップ２０２では、ムストを発酵タンクに移して、香り、色、タンニンを定着させる。ムストの総酸度、糖度、pHをチェックし、いずれかの数値が外れの場合は修正して確実により良いワインとなるようにする。ステップ２０３では、タンクに酵母を加えて発酵プロセスを開始させる。酵母はムスト中の糖分を二酸化炭素とアルコールに変化させてワインをつくる。ムストが発酵するときに熱が生じるため、良好な高品質のワインを確実に得るために、温度が所定範囲内になるよう制御せねばならない。発酵温度は華氏６０度から華氏７０～８５度または華氏８０～９０度の範囲内の任意の温度までになるよう、発酵期間中定期的に制御される。発酵期間は長くて２週間程度である。さらに、発酵完了のタイミングを判断するため定期的に糖度を監視する。発酵中、ブドウの固形物（皮と種）が上方に浮き上がるが、これを「キャップ（果帽）」と呼ぶ。ステップ２０４では、「ポンプオーバ」と呼ばれる処理が１日数回にわたり実行され、キャップの上にタンクの底のムストをかけるように循環させ、確実に均一な混合物となるようにする。キャップを下方のムストの方に押し込むために道具を使用する場合は、この処理を「キャップ・パンチング」とも呼ぶ。この処理中、温度は所望の範囲に調整する。

【0016】

引き続き図１を参照し、いったん発酵が完了すると、ステップ２０５で果汁（この時点ではワイン）を流し出して保持タンクに入れ、ポマースと呼ばれる残ったムストを圧搾機に移す。圧搾機でポマースを絞って残ったワインを抽出し保持タンク内のワインに加える。より高品質のワインを製造する時は、流し出したワインのみを使う。圧搾後、保持タンク内のワインを落ち着くまで放置し、「澱」と呼ばれる沈殿物の層を底に形成させる。次にワインの「澱引き」を行うが、澱引きでは「澱」その他ワインを濁らせる物がタンクに残るようにしてワインを他のタンクに移動させる。ステップ２０６では、ワインの任意の第２発酵ステップを行ってもよく、このステップでリンゴ酸が乳酸に変化する。マロラクティック（ML）バクテリアを加えることで化合物を生成させワインのボディをしっかりさせる。ワインは１週間に２回かきまぜられ、温度は華氏７０度から華氏７５度の間に保たれる。この処理は２～６週間続く。ML発酵が完了すると、ステップ２０７で、再度ワインの澱引きを行い、樽等の保存容器にワインを移す。ワインを移す間に、総酸度とpHを調整してワインを改善してもよい。熟成プロセスでは、華氏５５度～華氏６０度の間の一定の温度範囲を維持する必要があり、４～６週間ごとにワインを味見して必要に応じて調整を行い確実にワインの熟成がうまく進むようにする。さらに、ワインを樽に保存する場合は、湿度を６５～７５％の間に維持する。このステップは、ワインが次のステップに進む状態になるまで数カ月から１年にわたり続く。ステップ２０８で、ワインの清澄化ステップが実行されてもよい。このステップでは、ワインに清澄剤を加えてワイン中の不所望の物質を除去し、その後、清澄剤をワインから濾過して取り除く。さらに、ワインを瓶詰する前に何等かの最終的な調整（総酸度、pH、残留糖等）を行ってもよい。いったん瓶詰した後は、年と共にワインの味はよくなるため、２カ月から数年の任意の期間にわたりさらに熟成させてもよい。

【0017】

ワイン製造プロセスから分かるように、ワイン製造に関係するステップや変数は多数ある。このような複雑なプロセスのシステム中の種々の「モノ」を監視し制御するためにIoTシステムを使用できる。温度、pH、糖度、総酸度の測定にはセンサを使用でき、「ポンプオーバ」や、圧搾および澱引きステップに使用されるポンプの制御のためコマンドを送信できる。一つのステップから次のステップへの移行は、センサの測定結果とプロセス中の前のステップの結果に依存するので、ワイン製造プロセスの大部分を自動化するIoTシステムを容易に設計できるだろう。

【0018】

ワイン製造ユースケースを見ると、IoTシステムに対して様々な要件が課され、それはイベントマネージメント・ケイパビリティの高度な実現を必要とするであろう。要件の一つは、特定のイベントの異なるトリガ条件に応じて多数のアクションを使用することだろう。たとえば、糖度またはワイン製造ユースケース中の他の測定値に基づき、次のステップに進む決定をすることである。他の要件は、センサの測定結果に基づき調整を行うことである。第３の要件は、入力の変化に応じてアプリケーションの動作を更新し、更新を通常のオペレーション動作に統合する能力であろう。たとえば、ワイン製造プロセス中に総酸度、pH、および糖度を調整する能力である。

【0019】

従来のIoTイベントマネージメント・ケイパビリティは主として、単一のイベント発生にフォーカスしている。つまり、成功したイベント検知にフォーカスし、失敗したイベント発生や代替的なイベント発生に対するアクションはサポートしていない。単一イベントにフォーカスしているため、種々のイベント間でのインタラクションのためには、多数の別個のイベントを定義しそのインタラクションを構成する必要があり、複雑かつ手間のかかるものとなっている。イベントの追加または更新は、既存イベントのリップリング効果を生じかねず、オペレーションを一時的に停止することが必要かもしれない。リアルタイムでのIoTオペレーションにおいては、このような限界は既存のイベントマネージメント・ケイパビリティの有用性と利点とを減じる。

【0020】

IoTシステムが約束するものは広範かつ多様である。数億のIoTデバイスから多用途かつ多種のデータが提供されると期待されている。IoTの未来は、膨大なデータセットを産み、それによって、多数の異なるソースからの多様なデータを利用した、新しいよりスマートなアプリケーションが生み出される。結果として、IoTアプリケーションはより複雑になり、よりスマートな用途を可能にするさらなるケイパビリティが要求される。

【0021】

IoTアーキテクチャは依然発展中であり、アプリケーションが利用できる大量のデータをどのように使用するのがベストか決めようと試みられている。ここに開示するのは、IoT構成可能イベント・アクション・シーケンシング・メカニズムであり、種々のIoTイベントを相互に関連付けて、IoTシステムにおいて利用可能なデータの複雑な使用を効率的に可能にするようなエンドプロセスを達成するものである。IoT構成可能イベント・アクション・シーケンシングは、以下を含みうる：
－複雑／分散IoTシステムのイベントが互いに関連づけられ、大量かつ多様なデータセットと、進化していくシステム条件と、の双方の利点が生かされるアーキテクチャの定義づけ。
－監視およびマネージメントを目的として、ユーザへイベントの相互関連付けを動的に定義し見せるために、リソースと属性が利用されるRESTfulインタフェースの定義づけ。これらのリソースは、イベントとその結果であるアクションとをリンクさせるように構造化されたIoTプロセスへとまとめられる。
－システム中で進化していく条件に対処するための、IoTプロセスがアクティブに動作している間にIoTプロセスを動的に更新するための手順の定義づけ。
－さらに複雑なオペレーションを可能にするための、異なるIoTプロセス間のインタラクションを特定する能力の提供。これらのインタラクションは、一つのIoTプロセスが他のIoTプロセスの開始、停止、中断、再開、リセットをトリガする場合もあり、複数のIoTプロセスが互いに並行して実行される場合もあるだろう。
－システム中のIoTデバイス間のインタラクションを通じてIoTプロセスを実行するための手順の定義づけ。
－開示する構成可能イベント・アクション・シーケンシング・システムが既存のIoTアーキテクチャに適用できる例の提供。

【0022】

図２は、開示するIoT構成可能イベント・アクション・シーケンシングのための例示的システム２１０を示す。システムのコンポーネントは、リソースマネージャ２１４、更新エンジン２１３、および、実行ユニット２１６を含むことができる。IoTシステムとイベント・アクション・シーケンシング・システム２１０との間のインタラクションを可能とする、インタフェースコンポーネント、入力インタフェース２１１および出力インタフェース２１２が設けられている。入力インタフェース２１１は、IoTエンティティがIoTプロセスのイベントおよびアクションに関する情報を指定し、構成し、更新し、アクセスするためのRESTfulインタフェースを提供することができる。出力インタフェース２１２コンポーネントは、IoTプロセス中に実行されるアクションに応答して、システム内のIoTデバイスを監視および制御するためのメカニズムを提供する。これらのインタフェースコンポーネントは、IoT構成可能イベント・アクション・シーケンシング・システムとIoTシステムとの間の接着剤（glue）としての役割を果たすことができ、完全のため含めている。入力インタフェースおよび出力インタフェースコンポーネントは通常、プラットフォームおよびプロトコル中心であり、イベント・アクション・シーケンシング・システム２１０が動作するために必要な補助機能である。

【0023】

システム２１０内では、リソースマネージャ２１４が入力インタフェースコンポーネントを介して外部IoTエンティティから入力を受け取る。リソースマネージャ２１４は、IoTプロセスに関連するリソースの作成、記憶、および保守を管理する。さらに、リソースマネージャ２１４は、IoTプロセスが起動され動作中になると、ステータス情報を提供するために、実行ユニット２１６とインタフェースする。実行ユニット２１６はIoTプロセスのアクションを実行し、IoTデバイスにコマンドを送信し、トリガ条件のステータスを監視し、イベント遷移を管理する役割を担う。実行ユニット２１６は、IoTプロセスの動作の詳細を得るために、リソースマネージャ２１４および更新エンジン２１３の双方とインタフェースする。最後に、更新エンジン２１３は、IoTプロセスがまだ動作中である間に、IoTプロセスのイベント条件およびアクションを更新し、更新が現在の動作に干渉しないことを保証するために、動的リクエストを処理する役割を担う。その結果、更新エンジン２１３は、リソースマネージャ２１４から入力を得て、実行ユニット２１６とインタフェースする。

【0024】

システム２１０内では、イベント・アクション・シーケンシング・プロセス（EASP）が、所望の動作を達成するために相互接続されたイベントおよびアクションをとらえるように定義される。EASPは、EASPが動作するシステムの状態の変化を検出するイベントを用いて構成することができる。いくつかの動作を実施するために、イベントに異なるアクションを割り当てることができ、EASP内の次のイベントのシーケンスを指定するためのメカニズムが提供される。ユーザがEASPの動作を動的に制御することを可能にするEASPを表すためのリソースが開示される（例えば、動作に影響を及ぼすことなくリクエストを介してEASPを制御する能力、および、動作に影響する場合は、EASPはリクエストにどのように応答するか対処する）。EASPは、意図するアプリケーション用の所望のシーケンスへと、IoTイベントおよびアクションを相互につなぎ合わせるIoTプロセスであることに留意されたい。EASPは、イベントとアクションとを互いにリンクさせてプロセスフロー（例えば、「アクション・シーケンシング」）を形成するための枠組みと考えることができる。EASPリソース自体は、EASP CSFが実行する「プログラム」であってもよい。実行されると、EASP CSFは、一つのイベント状態リソースから別のイベント状態リソースに遷移することができる。

【0025】

EASPのイベントおよびアクションは、イベント・アクション・シーケンシング・システム２１０内のリソースとして表すことができ、そこでは、リクエスタが、EASPが何であるか、およびどのイベントがアクションの動作をトリガするかを作成し、定義する。その結果、EASPリソースは、EASPを記述するために使用されるパラメータと共に開示され得る。EASPリソース内では、イベント状態リソースを使用して、EASP内の各イベントを記述することができ、さらにイベント状態リソース内では、実行されるアクションおよびEASP内の次のイベントを記述するために、一つまたは複数の遷移リソースが提供される。図３は、開示されるリソース間の関係の一例を示しており、この例では、EASPリソース（例えば、EASPリソース２１７）が親リソースであり、複数のイベント状態リソース（例えば、イベント状態リソース２１８）およびそれらに関連する遷移リソース（例えば、遷移リソース２１９）を伴う。各リソース内には、そのリソースに関する情報をキャプチャするため、関連する情報を提供するパラメータが存在し得る。

【0026】

EASPリソース２１７は、EASPによって要求されるすべてのイベントおよびアクションを含むことができる。イベントは、何らかのアクション（単数または複数）の実行をトリガまたは引き起こすことができるIoTシステム内の条件である。イベントのいくつかの例は、特定のセンサのしきい値または値の範囲、タイマの満了、リソースに対するRESTful動作（Create、Retrieve、Update、Delete）、デバイスまたはエンティティをオンまたはオフにする動作、他のEASPによって実行されるアクションなどである。一方、アクションは、イベントの検出時に実行されるものである。アクションは、リソース上のRESTful動作、タイマの開始、デバイス管理動作、ストアアンドフォワード動作、別のEASPのイネーブル、アクチュエータの制御、コマンドの実行などを含むことがある。

【0027】

イベント・アクション・シーケンシング・システム２１０によって提供される他の重要な特徴は、EASPの相互作用を指定する能力である。EASPの動作は、他のEASPからのいくつかのアクションの実行に依存し得る。さらに、二つのEASPのイベントは、互いに密接に関係する可能性があり、IoTシステムの異なる側面を制御するために使用されてもよい。これらは、より単純なEASPの相互作用を介して複雑なEASPを構築することを可能にするために、開示されるイベント・アクション・シーケンシング・システム２１０によって提供される強力な特徴である。

【0028】

EASPは、本明細書に開示されるIoTプロセスの実現である。要約すると、イベント・アクション・シーケンシング・システム２１０は、そこからEASPが動作する全体的な機能システムと考えることができる。これを図２に示す。EASPは、特定のアプリケーション（例えばワイン製造ユースケース）のためのイベントとアクションとの相互関係のインスタンスである。EASPリソースは、EASPを表すリソースである。EASPリソースは、図３に示すように、子リソースであるイベント状態（EventState）を有することができ、当該子リソースはさらに、子リソースである遷移（Transition）を有することができる。イベント状態リソースは、所望のアプリケーション（例えば、ワイン製造ユースケースの各ステップ）を達成するためにEASPが経由する状態を記述する。開示される「EventState」は概括的にリソースと呼ばれ、「イベント状態（event state）」はイベント状態リソース（EventState resource）に関連する状態の発生である。遷移リソース（Transition resource）は、一つのイベント状態から別のイベント状態への遷移をトリガするイベントを記述する。さらに、アクションは、イベント遷移中に実行されてもよい。

【0029】

EASPリソース－EASPリソース２１７は、EASP全体の詳細を捉えることができる。表１は、EASPリソースのいくつかの例示的なパラメータを示す。EASP識別子（EASP ID; EASP identifier）は、EASPリソース２１７をEASPの詳細に関連付けるために使用されてもよく、EASPの動作を実行するために実行ユニット２１６によって使用されてもよい。EASP識別子は前提条件（precondition）として、または何らかのイベントによるアクションとして、当該EASPの動作をトリガするために、他のEASPリソースによって使用され得る。記述（Description）パラメータは、人間が読み取り可能な形式でEASPの目的を指定することを可能にし、一方、現在ステータス（Current Status）パラメータは、EASP全体の実行ステータスを提供する。制御（Control）パラメータを使用して、EASPの動作を、EASPを有効にすることから、EASPを一時停止、再開、終了、および無効にすることまで制御することができる。また、EASPが、IoTシステム内のイベントに基づいて自律的に実行される自動制御があってもよい。前提条件（Preconditions）パラメータは、EASPが開始される前に発生し得る、予め必要なイベントを提供し、EASPを自律的に実行するために制御パラメータと共に使用され得る。終了条件（Exit Conditions）パラメータは、動作を継続すると有害または危険である緊急事態の場合に、EASPの緊急終了を可能にする。このパラメータは実行ユニット２１６からの非同期応答に対応して、EASPに関連するすべてのアクションを停止し、その動作を非アクティブ化する。「グローバル」な終了条件は、EASPの動作中はそのイベント状態に関わらず継続的に監視され適用されてもよい。

【0030】

制御パラメータによって指定されるようにEASPを制御することができる多くの方法がある。かかる方法は、イベント・アクション・シーケンシング・システム２１０の実装に依存するだろうが、以下に制御パラメータを指定する方法のいくつかの例を挙げる。EASPが自動制御に設定される場合、イベントおよびアクションに関連するパラメータは、イベント・アクション・シーケンシング・システム２１０がEASPの動作をどのように制御すべきかに関するガイダンスを提供するように指定されなければならない。このモードでは、前提条件パラメータが、EASPが開始するのに必要なイベント（例えば、条件）またはアクションを指定することができる。一旦開始されると、EASPのシーケンシングは、指定されるイベント状態リソース２１８および遷移リソース２１９に依存する。EASPはまた、「時間遅延イネーブル」または「ディスエーブル」を有するタイマに基づいて、「イネーブルオンデマンド」を使用して制御されてもよい。EASPがアクティブに実行中になると、「即時終了」、「パーセンテージ完了または終了イベント条件で終了」、「一時停止」、「再開」、または「リセット」を使用して、EASPをインタラクティブに制御することができる。EASPを一時停止、再開、またはリセットする能力は、変化していくシステム条件を考慮することができる、極めてIoT中心的な相互作用を提供する。

【表1】

【0031】

イベント状態リソース－イベント状態リソース２１８は、イベントの詳細と、他のイベントに遷移するまで維持する状態とをキャプチャする。トリガされると、イベントはアクションを実行し、他のイベント状態に遷移する前に別のイベントが発生するのを監視する状態で待機することができる。EventState IDは、実行ユニット２１６がイベント状態の遷移を処理し、ステータス情報を維持するために定義される。イベント状態は、設定された持続時間の間、または特定のイベントの発生に起因して、別のイベント状態に遷移することができる。イベント状態が計時される場合、持続時間（Time Duration）パラメータが、イベントがどのくらい長く動作するか（例えば、残された時間の長さ）と、次のイベント状態にいつ遷移するかとを指定する。他のイベントによってイベント状態が遷移する場合、遷移リソース２１９は当該イベントの詳細を指定する。イベント終了条件（Event Exit Condition）パラメータは、EASPリソース２１７の終了条件（Exit Conditions）パラメータと同様に、現在のイベント状態を終了させることができるイベントを指定するために使用される。表２は、イベント状態リソース２１８のいくつかの例示的なパラメータを示す。

【表2】

【0032】

遷移リソース－遷移リソース２１９は、現在のイベント状態から次のイベント状態への遷移をトリガするための条件をキャプチャする。次のEventState IDパラメータは、遷移先のEventState IDを指定し、実行する必要があるアクションがある場合、アクション実行（Execute Actions）パラメータで指定される。遷移イベント（Transition Events）パラメータは、イベント状態遷移の発生をトリガするイベントを指定する。イベントは、AND、OR、XOR、NOTなどの論理演算子によって個々のイベントをつなげた複数の式で指定することができる。現在のイベント状態からの遷移各々に対して一つの遷移リソース２１９が作成され得ることに留意されたい。結果として、一つの特定のイベント状態リソース２１７に対して複数の遷移リソース２１９が存在し、各々が異なるトリガイベントを有し潜在的にそれらに関連するアクションを有することができる。表３は、遷移リソース２１９のいくつかの例示的なパラメータを示す。

【表3】

【0033】

リソースマネージャ２１４は、リクエストが解析され検証された後に、入力インタフェース２１１からリクエストを受信する。次に、リソースマネージャ２１４は、リクエストされた方法に基づいてリクエストを処理する。リクエストされた方法が更新である場合、リソースマネージャ２１４は、EASPプロセスがアクティブに実行中かどうかをチェックする。EASPがその時点で動作中である場合、リソースマネージャ２１４は、更新の詳細とともに、リクエストを更新エンジン２１３に転送する。図４は、リクエストに応じてリソースマネージャ２１４が実行する手順を示す。

【0034】

図４～図６、図８、図１２、図１４など、ここで示されるステップを実行するエンティティは、論理エンティティであってもよいことを理解されたい。これらのステップは、図１７Ｃまたは図１７Ｄに示されるようなデバイス、サーバ、またはコンピュータシステムのメモリに記憶され、それらのプロセッサ上で実行されてもよい。一例では、M2Mデバイスのインタラクションは以下でさらに詳細に説明するが、図５のIoTデバイス２４２は図１７ＡのM2M端末装置１８上に常駐することができ、図２のシステム２１０は図１７ＡのM2Mゲートウェイ装置１４上に常駐することができる。ここで開示される例示的な方法（例えば、図１、図４～図８、図１２、図１４など）の間で、ステップをスキップしたり、ステップを組み合わせたり、ステップを追加したりすることも考えられる。

【0035】

図４の手順は、IoTリクエスタからのリクエストを評価するときにリソースマネージャ２１４によって実行されるステップを説明している。ステップ２２１で、リクエストされたリソースが存在するかどうかをチェックする。イエスの場合、またはリクエストの内容が上に開示したリソース（例えば、遷移リソース２１９、イベント状態リソース２１８、またはEASPリソース２１７）の一つを作成することである場合、ステップ２２２に進む。ノーの場合エラー応答を送信する。エラー応答は、ステップ２３４（応答送信）を含んでもよい。ステップ２２２では、必要であれば、許可またはアクセス制御ポリシーをチェックする。ここには複数のステップが含まれてもよく、外部エンティティとのインタラクションを含んでもよい。許可されている場合またはアクセス制御が許可されている場合、ステップ２２３に進む。許可されていない場合、ステップ２３４（応答送信）を含むことができるエラー応答を生成する。ステップ２２３において、リクエストされた動作－CRUD（Create（作成）、Retrieve（読出）、Update（更新）、Delete（削除））をチェックする。リクエストされた動作が読出である場合、ステップ２２４に進む。要求された動作が削除である場合、ステップ２２５に進む。要求された動作が作成または更新である場合、ステップ２２６に進む。ステップ２２４では、データベースにアクセスし、以下にリストされる適切な応答の一つを返す。応答タイプは、リクエストのオプションやクエリ文字列などの一部で指定することができる。適切な応答は、現在のリソース表現、EASP全体の現在のステータス、ならびに現在のイベント状態のステータス、またはEASPリソース構造全体を含むことができる。この情報は、ステップ２３４（応答送信）で返される。ステップ２２５では、EASPが動作可能であるかどうか現在のステータスをチェックし、次いでステップ２３４に進んで適切な応答を送る。EASPが実行中ではない場合、削除リクエストで特定された適切なリソースおよび対応する子リソースを削除する。EASPリソース２１７が提供される場合、EASP構造全体がデータベース２１５から除去される。EASPがまだ実行されている場合は、エラー応答を返す。

【0036】

引き続き図４を参照すると、ステップ２２６において、提供された情報が所望の動作の要件を満足するかチェックする。例えば、作成リクエストの場合、提供された情報は、対応するリソースタイプのスキーマファイルの要件を満たすかどうかチェックする。情報がスキーマ要件を満たす場合、ステップ２２７に進む。情報がスキーマ要件を満たさない場合、エラー応答を送信し、ステップ２３４に進み応答を送信する。ステップ２２７で、EASPが動作中であるかどうかをチェックする。EASPが動作中であれば、更新エンジン２１３へリクエストを転送しステップ２３３において応答を待つ。評価の一部として、リソースマネージャ２１４は識別されたIoTデバイス（もしあれば）がアクセスのために利用可能であり得ることを保証するために、実行ユニット２１６とインタラクトする必要があり得る。この検証手順はEASPをアクティブ化する前に、後の時間まで遅延させることができ、システムに依存する。EASPがアクティブでない場合、ステップ２２８に進む。ステップ２２８では、要求された方法をチェックする。「更新」である場合、ステップ２２９に進む。「作成」である場合、ステップ２３０に進む。ステップ２２９で、データベース２１５内の情報をリクエストによって提供されたデータで更新し、ステップ２３４に進み、応答を送信する。ステップ２３０で、リクエストされたリソースが存在し、それが作成動作である場合、エラー応答を送信し、ステップ２３４に進み応答を送信する。それ以外の場合は、ステップ２３１に進む。ステップ２３１では、リクエストされたリソースが作成され得るかどうかを評価する。リソースを作成することができる場合にはステップ２３２に進み、それ以外の場合はエラー応答を送信し、ステップ２３４（応答送信）に進む。ステップ２３２では、必要に応じてリソースの識別子を生成する。リソースマネージャ２１４は、装置内の一意性を保証するために識別子を生成することができる。あるいは、識別子が提供されてもよく、リソースマネージャ２１４は一意性をチェックし、次いで、ステップ２３４に進んで応答を送信してもよい。ステップ２３３で、応答が更新エンジン２１３から受信され、結果をステップ２３４（応答送信）に転送する。成功応答の場合、データベース２１５内の情報を更新する。ステップ２３４で、応答を生成し適切なコードとともにリクエスタに送信する。

【0037】

前述のように、リソースマネージャ２１４は、リクエスタのニーズに基づいてリクエストを読み出すために異なる応答を返すことができる。デフォルト応答は、読出リクエスト内のターゲット識別子によって指定されたリソースのリソース表現とすることができる。しかしながら、リソースマネージャ２１４は、リクエスタの関心のある他の関連情報を含むように応答をフォーマットすることもできる。そのような応答の一つは、EASPプロセスの動作のステータスの集約であり、一つはEASP全体に対するものであり、もう一つは現在のイベント状態に対するものである。リソースマネージャ２１４が提供することができる別のタイプの応答は、応答内のEASPリソース構造の集約である。これにより、リクエスタは、一つのリクエストでEASPのすべてのイベントおよびアクションを読み出すことができる。この情報は、リクエスタがEASPおよびそのイベントおよびアクションを構築または監視するのを助けることができる。イベント・アクション・シーケンシング・システム２１０が同様に返すことができる他の応答タイプがあってもよく、イベント・アクション・シーケンシング・システム２１０の設計に依存する。

【0038】

実行ユニット－EASPプロセスが定義されると、その動作は（例えば、いくつかの前提条件によるタイマの満了などに基づいて）様々なイベントによってトリガされ得る。他のトリガも定義することができ、イベント・アクション・シーケンシング・システム２１０に依存する。EASPの実行は実行ユニット２１６によって処理され、実行ユニット２１６は、出力インタフェース２１２を介してIoTシステムとインタフェースすることで、実行ユニット２１６はEASPへの入力へのアクセスを確保し、また、アクションによって指定された場合は制御のためにアクチュエータ型デバイスへのアクセスを確保する。

【0039】

EASPの実際の動作の前に、実行ユニット２１６は、EASPが動作するために必要なすべての入力および出力へのアクセスを検証することができる。この検証は、EASPリソース定義およびそれらのイベント状態リソースが作成されるときに実行することができる。あるいは検証は、起動後であるが実際の動作の前に実行されてもよい。この場合、EASPリソース２１７のCurrent Statusパラメータは、「EASP検証」またはそれと同様の機能を持つ任意のタイプのインジケータとして指定することができる。

【0040】

実際の検証は、イベント・アクション・シーケンシング・システム２１０がIoTシステムとどのように統合されているかに応じて、ローカルまたはリモートで行うことができる。イベント・アクション・シーケンシング・システム２１０がIoTシステムの一部として統合されている場合、センサおよびアクチュエータデバイスへのアクセスが既に確立されている可能性があり、実行ユニット２１６は、そのデバイスにアクセスするために識別子または何らかのURIを参照する必要がある可能性がある。しかしながら、リモートの場合には、実行ユニット２１６はデバイスとのメッセージングインタラクションのセットアップのために、出力インタフェース２１２の支援を必要とし得る。これは、サブスクリプション／通知メカニズム、プロトコルメカニズム（例えば、CoAP Observe)の使用、ポーリングメソッドの使用、またはIoTシステムによって公開されるいくつかのAPIコールの形態であり得る。これらの場合、許可またはアクセス制御ポリシーは、IoTデバイスへのアクセスを獲得するイベント・アクション・シーケンシング・システム２１０においても役割を果たすことができる。これらの問題はイベント・アクション・シーケンシング・システム２１０の範囲外であり、イベント・アクション・シーケンシング・システム２１０の動作を可能にするために、かかるアクセスのための何らかのメカニズムがIoTシステムによって提供されるべきである。図５は、イベント状態リソースの「作成」リクエストを処理するための、リソースマネージャ２１４と実行ユニット２１６との統合の例示的な手順を示す。イベント・アクション・シーケンシング・システム２１０の他の構成要素は、図が煩雑にならないよう省略されていることに留意されたい。また、アプリケーションがリソースを作成することができ、一つのEASPに対して複数のリソースを作成することができることにも留意されたい。リソースはまず、どのように動作するかEASPに指示するために作成されてもよい。ここで開示されるリソースは、アプリケーションがどのようにEASPをプログラムすることができるかの例である。他の例は、二つのリソースなど、より少ないリソースを含むことができる。

【0041】

図５は、IoTシステム手順への例示的な実行ユニットアクセス検証を示す。ステップ２５１において、IoTリクエスタ２４１は、イベント状態リソース２１８を作成するためのリクエストを送信する。この手順は、EASPリソース２１７または遷移リソース２１９の作成にも適用することができる。EASPリソース２１７を作成するときは、指定されるパラメータは、EASP ID、EASPの説明、EASPがどのように制御されるか、およびEASPのための任意の前提条件または終了条件を含むことができる。表１に、同様に指定され得る他のパラメータを列挙している。イベント状態リソース２１８を作成するときは、”EventState ID”、”Time Duration”、および”Transition Events”などのパラメータを指定することができる。他のEventStateパラメータを表２に示す。遷移リソース２１９に関しては、表３に記載されているように、”Transition Events”、”Next EventState ID”、および”Execute Actions”パラメータなどを含むことができる。ステップ２５２において、リソースマネージャ２１４はリクエストを処理し、イベント・アクション・シーケンシング・システム２１０によって必要とされる任意の必要な検証を実行する。ステップ２５３で、検証が成功した場合、リソースマネージャ２１４は、実行ユニット２１６にEventState情報を転送して、IoTデバイス２４２へのアクセスが行われ得ることを検証し得る。

【0042】

引き続き図５を参照すると、ステップ２５４において、実行ユニット２１６は（出力インタフェース２１２と共に）IoTデバイス２４２にリクエストを送る。このリクエストは、IoTデバイス２４２が到達可能であることを検証するための単純な読出であってもよく、またはサブスクリプションまたはCoAP Observeの作成を伴ってもよい。リクエストのもう一つの目的は、イベント・アクション・シーケンシング・システム２１０がIoTデバイス２４２にアクセスできるように、すべての許可またはアクセス制御が構成されることを保証することである。アクセスが許可されない場合、情報はIoTリクエスタ２４１に返される。アクセスが許可された場合、ステップ２５５においてIoTデバイス２４２は、ＯＫまたは適切な応答を返す。ステップ２５６において、実行ユニット２１６は、IoTデバイス２４２へのアクセスが検証されたという応答を返す。ステップ２５７で、リソースマネージャ２１４はイベント状態リソースを作成し、情報をデータベースに保存する。ステップ２５８において、作成された応答が生成され、IoTリクエスタ２４１に送信される。手順が失敗した場合、適切なエラー応答が返される。

【0043】

検証が完了し、イベント・アクション・シーケンシング・システム２１０が、EASPによって要求されるすべてのアクションを実行することができるようになると、実行ユニット２１６は動作を開始しイベント状態の遷移を追跡する。動作の過程で、実行ユニット２１６およびリソースマネージャ２１４は、必要に応じてリクエスタへステータス情報を転送できるよう通信を維持することができる。実行ユニット２１６はまた、更新エンジン２１３とインタフェースして、新しい動的に追加されたイベント状態リソース２１８または既存のイベント状態リソース２１８に対する変更を、動作に影響を及ぼすことなくEASPに統合することができるかどうかを判定する。ここでは、プロセス（例えば、アプリケーション）がアクティブに実行されている間にプロセスを更新する能力が開示される。従来、これはアプリケーションの停止を必要とするが、EASPを停止する必要はない。イベント・アクション・シーケンシング・システム２１０は変更が行われることを可能にし、変更されるもの以外の既存の動作に影響を及ぼすことなく、これを行う。換言すれば、変更を行うために、どんな動作（例えば、ワインプロセス）であっても停止する必要がない。イベント・アクション・シーケンシング・システム２１０は動的な変更を処理できる。とはいっても、変更によって、動作の結果がもともとプログラムされたイベント状態とは異なるイベント状態になるように変更を行うこともできる。図１と図７Ｂとの差を参照されたい。図７Ｂの次のイベント状態（ステップ２４３およびステップ２４４）は、図１が当初実行されたときには存在しなかった。

【0044】

図６は、EASPが起動されて実行されるときに実行ユニット２１６によって実行される処理手順を示す。図には「次のイベント状態への遷移」ステップの間に提供されるステータス情報のみを示すが、実行ユニット２１６は状態処理フロー全体の間いつでもステータス情報を提供し得ることに留意されたい。ステータス情報は、現在のEASP処理がどこにあるか（例えば、何パーセント完了したか）、どのイベント状態が現在アクティブであるか等を示すためにEASPシステムによって提供される任意の情報を含むことができる。ステータス情報の例を図１５及び図１６に示す。

【0045】

図６は、実行ユニット状態処理フローの一例を示す図である。ステップ２６１ａ～２６１ｃではアクティブ化が行われる。これは、実行ユニット２１６がトリガされて処理を開始するときである。これは様々な方法でトリガすることができ、図６は可能性のある３つの態様を示している。まず、EASPリソース２１７で指定された前提条件に基づく場合（ステップ２６１ａ）、将来の時間に基づく場合（ステップ２６１ｂ）、またはリクエスタのオンデマンド制御に基づく場合（ステップ２６１ｃ－EASPをアクティブ化するリクエストを受信した場合）である。表１に記載される制御パラメータは、EASPがアクティブ化され得る追加の方法を提供する。例えば、イベント状態リソースのそれぞれを最初に作成するときに、EASPがアクティブ化されないケースが存在し得る。別のシナリオでは、EASPがアクティブではなくアクティブにされるべきであるときに、１日のある時間中にのみEASPを実行することをユーザが望み、他の時間中には利益はない。ステップ２６２において、イベント状態情報のロードがあってもよい。いったんEASPがアクティブ化されると、実行ユニット２１６は最初に最初のイベント状態（Initial EventState）の情報をロードする。その後処理フローを繰り返すと、Next EventState IDパラメータによって特定されるイベント状態リソース２１８が代わりにロードされる。さらに実行ユニット２１６は、イベント状態リソースの作成中にこのステップがすでに以前に実行されていない場合、IoTデバイスへのアクセスが行われ得ることを検証する必要があり得る。これは、IoTシステム内のデバイスにサブスクリプションを行うこと、CoAP Observeを使用すること、または、イベント・アクション・シーケンシング・システム２１０およびIoTシステムが遠隔に位置する場合、デバイスをポーリングしてイベント状態に入力を提供することによって達成することができる。より統合されたソリューションの場合、適切なAPIコールを呼び出すことを含むことができる。必要であれば、次のステップに進む前にある期間実行されるイベント状態についてタイマを開始することができる。

【0046】

引き続き図６を参照すると、ステップ２６３においてイベント検出が存在し得る。実行ユニット２１６は、イベント状態リソース２１８の動作に必要なIoTデバイス２４２と通信できるようになりすべてのイベント状態リソースパラメータがローカルに保存されると、潜在的な遷移イベントを検出するために入力の監視を開始する。この時点で、イネーブルされた場合には、終了条件およびタイマ満了入力も検出ロジックに適用される。終了イベントが検出された場合、実行ユニット２１６はイベント状態を終了することができ、EASPがそのように構成されていた場合には、EASPを終了することもできる。最後に、実行ユニット２１６は、EASPに対する変更が行われた場合には、更新エンジン２１３から入力を取得することもできる。これが発生すると、実行ユニット２１６は、ローカルに記憶されたパラメータを更新エンジン２１３によって提供されたパラメータに置き換える。ステップ２６４では、実行されたアクション（または複数のアクション）が存在し得る。遷移をトリガするイベントを検出すると、実行ユニット２１６は、現在のイベント状態について指定され得る任意のアクションをIoTデバイスに対して実行することができ、またはイベント状態またはEASPを終了し得る。すべてのアクションが完了すると、次のステップに進むことができる。更新エンジン入力が存在する場合、実行ユニット２１６は、記憶されたパラメータを、入力によって提供されたパラメータと置き換えなければならないことに留意されたい。これは、実行される必要がある任意の新しいアクション、ならびに遷移先の次のイベント状態リソース２１８のIDを含むことができる。この能力により、EASPプロセスの動作の動的更新をサポートできる。

【0047】

ステップ２６５では、次のイベント状態リソース２１８への遷移がありうる。Next EventState IDが遷移リソース２１９の一部として存在する場合、実行ユニット２１６は、ステップ２６２への遷移を実行して、Nest EventState IDによって指定される次のイベント状態リソース２１８に関する情報をロードすることができる。実行ユニット２１６は次のイベント状態リソース２１８の識別子、および遷移のための他の関連情報、例えば、現在の状態、どのトリガイベントが検出されたかなどをリソースマネージャ２１４にシグナリングすることができる。この信号は、EASP動作を動的に更新するときに存在し得る潜在的な競合条件（race condition）を検出するために使用され得る。競合条件は、同じトリガイベントについて二つのEventStatesの可能性があるときはいつでも発生する。これは、ここで説明したようにEASPの更新時に起こりうる。例としては、リソースマネージャ２１４は、イベント状態リソース２１８が更新エンジン２１３によって最近修正された場合に、Nest EventState IDが現在格納されている識別子と一致するかどうかをチェックすることができる場合である。

【0048】

更新エンジン－更新エンジン２１３は、リクエスタがEASPプロセスの動作中にEASPプロセスを更新するためのメカニズムを提供する。この更新は、遷移イベントの変更という形式から、EASPに新たなイベント状態を追加する形式までありうる。EASP動作に影響を及ぼす他の変更もサポートすることができる。更新エンジン２１３は、更新がEASPの動作を妨害しないことを保証するために、実行ユニット２１６と調整することができる。干渉が検出された場合、更新エンジン２１３は更新をイネーブルせず、リソースマネージャ２１４に必要なエラー応答が提供され、リソースマネージャ２１４は応答をリクエスタに中継する。

【0049】

図７Ｂは、図１のワイン製造プロセスへ更新を行う例を示す。ここでは、より高品質のワインを製造するため、澱引きステップ（ステップ２０５）が二つの別個のステップに分割されている。この更新は、既に実行中のEASPプロセスに対する変更を実施するために更新エンジン２１３がどのように利用されるかを示す。図７Ａは、ワイン製造プロセスの動作を更新するために使用することができるステップの概要を示す。ステップ３４１で、新しい「第１の澱引き移送」ステップを追加する（ステップ２４３）。ステップ３４２で、新しい「第２の澱引き移送」ステップを追加する（ステップ２４４）。ステップ３４３で、「圧搾および澱引き」ステップ（ステップ２０５）の遷移リソース２１９を更新して、新しく作成された「第１の澱引き移送」ステップ（ステップ２４３）への遷移にする（遷移２４５）。ステップ３４４で、「マロラクティック発酵」ステップ（ステップ２０６）の遷移リソース２１９を更新して、新たに作成された「第２の澱引き移送」ステップ（ステップ２４４）への遷移にする（遷移２４６）。

【0050】

発酵ステップの間、ワインは良好な品質を有し、二つの澱引きステップを設けることが有利であろうと決定された。このとき、ワインメーカは図７Ｂに示すように、EASPに対して第１及び第２の澱引き移送イベント状態を作成する。これらのイベント状態リソース２１８の作成は既存の動作に影響を与えないので、作成リクエストは成功する。リソースが作成された後、イベント・アクション・シーケンシング・システム２１０は、図１に示す（もともとの）「圧搾および澱引き」ステップのEASPを遷移させる。図７Ｂでは、これは「圧搾」ステップとラベリングされている。次いで、ワインメーカは、「マロラクティック発酵」ステップ２０６の代わりに「第１の澱引き移送」ステップ２４３に遷移するアクションを再構成することによって、ステップを更新するリクエストを送る。更新エンジン２１３はリクエストを評価し、ワインが完全に圧搾されるまで待機するのは図６のイベント検出段階（ステップ２６３）だけなので、新しい入力を入れて処理フローを変更しNext EventState IDを「第１の澱引き移送」ステップ２４３に変更することができる。ワインの圧搾が完了すると、新しい更新エンジン入力は、EASPに、ワインを別のタンクに移して澱引きする「第１の澱引き移送」イベント状態に遷移するアクションを実行するように指示することができる。

【0051】

ワイン製造プロセスが「第１の澱引き移送」イベント状態になると、ワインメーカは、「マロラクティック発酵」イベント状態のために遷移リソース２１９の遷移イベントパラメータを修正することができる。この変更は「樽熟成」ステップに代えて、「第２の澱引き移送」ステップ２４４へと遷移をリダイレクトすることを含む。Execute Actionsパラメータも、熟成のために樽にポンプで送るのではなく、ワインを別のタンクにポンプで送るように修正することもできる。このリクエストは、処理がまだ「第１の澱引き移送」ステップ２４３内にあるので、成功裏に処理することができる。

【0052】

更新エンジン２１３の全体的な手順を図８に示す。ステップ２７１において、IoTリクエスタ２４１は対応するEASP処理がアクティブに実行されている間に、遷移リソースを更新する。一例として、IoTリクエスタ２４１は、遷移リソース２１９のTransition EventsパラメータおよびNext EventState IDパラメータを変更したいと思う。あるいは、IoTリクエスタ２４１は、現在の遷移リソース２１９内の値とは異なるTransition EventsパラメータおよびNext EventState IDパラメータを有する新しい遷移リソース２１９を作成することができる。これらの場合のいずれも、更新エンジン２１３の起動をトリガすることができる。さらに、イベント状態リソースの作成または修正も、更新エンジン２１３の動作をトリガする。ステップ２７２において、リソースマネージャ２１４はステップ２７１のリクエストを処理し、イベント・アクション・シーケンシング・システム２１０によって要求される検証を実行する。ステップ２７３において、リソースマネージャ２１４はEASPプロセスがアクティブに実行されていることを認識し、更新リクエストを処理のために更新エンジン２１３に転送する。ステップ２７４において、リソースマネージャ２１４は、更新リクエストが処理中であり、更新エンジン２１３からの結果を保留中であることをIoTリクエスタに通知するためにACK応答を返す。応答は、追跡目的のためにリソースマネージャ２１４によって生成された更新IDを含むことができる。現在の状態のステータス、ならびにEASP全体のステータスなど、他の関連情報も含めることができる。

【0053】

引き続き図８を参照すると、ステップ２７５で、更新エンジン２１３は実行ユニット２１６と通信することによって、更新を安全に行うことができ動作に悪影響（例えば、致命的エラーまたは他のしきい値エラー）を及ぼさないかどうかを評価する。更新を安全に行うことができる場合はステップ２７６に進み、それ以外の場合にはステップ２７７に進む。遷移リソース（または属性）は、EASPが次のステップにどのように遷移するかを指示することができる。ステップ２７６において、EASPの動作に悪影響（例えば、致命的エラーまたは他のしきい値エラー）を及ぼすことなく更新を行うことができる場合、更新エンジン２１３は、実行ユニット２１６に入力を追加して、図６に示すようにEASP動作を更新する。ステップ２７７で、更新エンジン２１３は、リソースマネージャ２１４に適切な応答を返す。ステップ２７８において、更新エンジン２１３が成功した応答を返した場合、リソースマネージャ２１４は、更新リクエストにおいて提供された情報でデータベース２１５を更新する。ステップ２７９で、リソースマネージャ２１４はIoTリクエスタ２４１に適切な応答を返し、ステップ２７４からの更新IDおよび更新されたステータスを含むことができる。エラーに関しては、EASPの実装に依存しうる。図６では、ステップ２６３が、EASPに影響を及ぼすイベントを検出する役割を果たす。更新が行われ、EASPがタイマ満了のイベントを監視している場合、EASPは変更を行うことができる。しかし、他の入力が監視されている場合、EASPは、それらがいつトリガするかを知らない。したがって、EASPは「致命的なエラー」を生成することがある。タイマ満了に戻ると、更新が受信されたときにタイマ満了になろうとしている場合は、「しきい値エラー」を生成することができる。

【0054】

追加の例:構成可能イベント・アクション・シーケンシング・システム２１０（本明細書ではイベント・アクション・シーケンシング・システム２１０とも呼ばれる）は、oneM2MおよびOCFなどの既存のIoTアーキテクチャに統合することができる。以下ではイベント・アクション・シーケンシング・システム２１０をこれらのアーキテクチャにどのように統合することができるかについての例が提供され、oneM2Mの例は本明細書で開示されるワイン製造ユースケースに適用される。また、EASPのインタラクティブ制御がイベント・アクション・シーケンシング・システム２１０を使用してどのように実現され得るかを示すために、工業工場のユースケースも提示される。また、本明細書では、EASPの手順を要約するユーザに返される表を示すことができる例示的なグラフィカル・ユーザ・インタフェースが示されている（図15）。

【0055】

oneM2Mは、共通サービス機能（CSF）がデータ管理、デバイス管理などのサービスをアプリケーションに提供する、サービス層アーキテクチャを定義している。これらのCSFは、クラウド・サーバ、ゲートウェイ装置またはモバイル装置上でも動作できる、共通サービスエンティティ(CSE:Common Services Entity)に一緒に結合される。アプリケーションは、CSEによって提供されるサービスを使用するように登録することができる。次いで、構成可能イベント・アクション・シーケンシング・システム２１０は、提供されるサービスの一つとしてCSEに統合され得る。実際には、イベント・アクション・シーケンシング・システム２１０自体がCSFの一つであってもよい。

【0056】

いったんイベント・アクション・シーケンシング・システム２１０が統合されると、EASPリソース２１７、イベント状態リソース２１８、および遷移リソース２１９について開示されたリソースを、oneM2Mアーキテクチャに追加することができる。表４および表５は、開示された<easp>リソースに対する子リソースおよびリソース固有属性をそれぞれリストする。

【表4】

【表5】

【0057】

表６および表７は、新たに開示される<eventState>リソースの子リソースおよびリソース固有属性をそれぞれリストしている。ここで、transitionEvents属性は、状態遷移を指定する潜在的な方法として指定されることに留意されたい。別の方法は、表８および表９に示すように、イベント状態遷移に関する情報を<transition>リソースに入れることである。

【表6】

【表7】

【0058】

表８および表９は、新たに開示される<transition>リソースの子リソースおよびリソース固有属性をそれぞれリストする。<transition>リソースの存在は、<eventState>リソースのtransitionEvents属性、transitionActions属性、およびnextEventStateID属性の必要性をなくすことができ、その逆も可能であることに留意されたい。

【表8】

【表9】

【0059】

図９は、ワイン製造ユースケースのための開示される<easp>リソース２８０の一例を示す。この例では、ワイン製造プロセスは、<easp>リソースによって表されるEASPとして実現される。したがって、ワイン製造プロセスおよびEASPは、交換可能に使用することができる。<easp>リソースは「wineMaking」と命名され、その属性および子リソースは以下にリストされる。このリソースはまず、ワイン製造プロセスで必要とされるステップを捉えるために、ワインメーカによりCSE上に生成される。Preconditions、exitConditionsその他の属性２８１～２８７が図９に示されている。図９は、イベント状態が作成された後の<easp>リソース２８０の表現を示し、したがって、numberEvents属性２８５は「８」であり、initialEvent属性２８６は「eid1」であり、finalEvent属性２８７は「eid8」である。EASPはまだ開始されておらず、control属性２８４およびcurrentStatus属性２８３の両方が、それぞれ「ディスエーブル（disable）」および「未開始（Not Started）」の値でこれを反映する。ワインメーカは、control属性２８４を使用してEASPをインタラクティブに制御することができるので、preconditionsイベントおよびexitConditionsイベントはない。いくつかの実施形態では、属性（例えば、finalEvent属性）と呼ばれるものは、リソースであってもよく、その逆であってもよいことが企図される。

【0060】

<easp>リソース２８０が作成されると、ワインメーカは、<easp>リソース２８０の子リソースとして８つの<eventState>リソース２８８を作成する。各<eventState>リソース２８８は名前「step#」を有し、ここで、#はワイン製造プロセス内の工程の番号であり、また「eid#」のeventStateIDを有し、ここでも#は工程番号に関連付けられる。図１０は、発酵工程であるステップ２０３のための<eventState>リソース２９０の例を示す。currentStatusは２週間のtimeDuration（持続時間）の50%であり、これは、発酵過程がすでに1週間経過したことを意味する。ここに示される値は高度に例示的な表現であり、実際の値を反映しないことがある。例えば、timeDuration属性は、人間が読み取り可能なラベル「週」の代わりに秒単位の値を有することができる。ステップ２０３のイベント状態内には、それぞれの遷移イベントが発生したときにどのアクションが実行されるかを指示する三つの<transition>リソース（例えば、transition1リソース２９５、transition2リソース２９６、transition3リソース２９７）がある。

【0061】

exitConditions属性２９４は、遷移イベントが発生しない場合にそれらの遷移イベントのいずれかをオーバーライドするメカニズムを提供する。このメカニズムは、イベント状態がスタックされ、そのイベント状態に留まることが望ましくない動作をもたらす場合を防止するために使用することができる。例えば、ワインの発酵は、２週間、または、糖度がゼロに達したときのいずれか先に起こった方までに制限される。終了条件を指定すると、糖度が決してゼロに達しなくても、最終的に工程が終了することが保証される。exitConditions属性２９４の各エントリは二つの値を含み、第１の値は終了イベントを指定し、第２の値は、executeActionsおよびnextStateEventIDが指定される遷移リソースを指定する。これはメカニズムの一つの実現であるが、アクションおよびnextEventStateIDを明示的に指定するために他のメカニズムを実現することができる。属性は、複雑なデータタイプを使用することによって、複数の終了条件をサポートすることもできる。

【0062】

<eventState>ステップ２０３内では、三つの遷移イベントのうちの一つが、２週間の発酵期間中に起こり得る。Transition1イベントは、温度を測定するために４時間毎に実行され、値が指定された範囲外にある場合に調整が行われる。このイベントはステップ２０３が開始されたときに最初にセットされるタイマの満了によってトリガされ、行われるアクションはcheckTempおよびadjustTempである。イベントおよびアクションの両方はM2M、V-0.5.0［2］におけるアクション・トリガリングのTR-0021 Studyで提供されるメカニズムによって捉えられてもよく、あるいは「<resource_URI><operator><value>」のような、オペレータによって分離されたキーと値のペアとして指定される単純な表現であってもよい。複雑な表現は、単純な表現を組み合わせるために論理演算子を使用して作成することができる。nextEventStateID属性は、遷移先の次のイベント状態を指定する。transition1イベントの場合、EASPは、指定されたアクションを実行した後、現在のステップに留まる。

【0063】

Transition2イベントは、発酵期間中に６時間毎に起こる。このイベントは、パンチツールがより均一な発酵のために、均質な状態にムストを混合することを可能にする。Transition2イベントの場合、EASPはステップ２０４に進み、ここで、パンチツールは、発酵ステップに戻る前に５分間動作するように構成される（詳細については図１５を参照）。最後に、transition3イベントは、糖度がゼロに達した時、発酵期間の終了を検出する。これに応答して、圧搾ツールの回転動作が実行され、EASPはステップ２０５に進む。

【0064】

発酵期間中、ワインメーカは、ワインの出来具合を監視するためにワインを味見する。この期間中、ワインメーカは最後に、より高品質のワインを製造するために二つの別々の時間に澱引き手順を実行することを選択することができる。これは、図７Ｂに示すように、マロラクティック発酵ステップ２０６の前後にワインを澱引きすることを含む。図１の元来のワイン製造プロセスでは、ステップ２０５において圧搾と澱引き手順を一つに組み合わせていたので、この決定はEASPフローの更新を必要とする。ワインメーカはまず、二つの澱引き手順各々をキャプチャするため、新しいステップ２４３およびステップ２４４を追加する。次に、圧搾手順が実行されている間に、ワインメーカはステップ２０５の遷移リソース２９５を更新する。この更新は、圧搾がまだ完了していないので、更新エンジン２１３によって安全に統合することができる。図１５中のrack1およびrack2に関して示される更新は、既存の遷移イベントをオーバーライドし、ステップ２０５の澱引き手順をバイパスする。代わりに、新しい遷移は、第１の澱引き手順を実行するためにステップ２４３に進む。

【0065】

第１の澱引き移送（ステップ２４３）が行われているとき、ワインメーカはステップ２０６の遷移リソース２９７について、図１５に示すように、遷移リソース２９７を更新して第２の澱引き移送を開始する（ステップ２４４）。ステップ２４３に入ると、ワインを２４時間沈降させ、澱１（グロス澱と呼ばれる）を除去し、続いて発酵のために細菌が添加される。この時点で、EASPはステップ２０６に進み、そこで最長６週間マロラクティック発酵が進む。ステップ２０３と同様に、マロラクティック発酵には終了条件があり、発酵量がゼロであるか、または６週間の持続時間が満了したときである。これらの条件のいずれも、EASPを強制的にステップ２４４に進め、そこで第２の澱引き移送がイネーブルされる。

【0066】

第２の澱引き移送内で、三つの遷移リソースは、互いに追従するように互いにリンクされる。Transition1は、タンクレベルがゼロであることによって示されるように、澱引き手順が完了したときのイベントを捉える。EASPは式「transition1 = done」によって示されるように、transition2イベントに続く。Transition2で実行されるアクションは、ワインの様々なレベルをチェックし、必要に応じてそれらを調整することである。これらのアクションは別のEASPによって捉えられ、総酸度、pHなどのレベルをチェックし、調整することができる。最後に、レベルが適切に調整されると、細かい澱を除去するためのEASPが開始し、終了すると、EASPは樽熟成ステップに進む。

【0067】

樽熟成工程は１年以上かかることがあり、したがって、ワインメーカは、「［control, transition2］」のexitConditions属性値を指定している。<transition>リソースは各々その<eventState>リソースに関連付けられており、例えば、eventState eid3からのtransition2（２９６とラベル付けされている）は、eventState eid7のtransition2リソースとは異なることを理解されたい。この終了条件は<easp>リソース２８０のcontrol属性に基づき、ワインを味見するワインメーカによって決定される。ワインメーカは、<easp>リソース２８０のcontrol属性を明示的に変更することによって、この工程を突然終了することができる。さもなければ、ワインメーカは、指定されたtimeDuration（持続時間）で熟成プロセスを終了させてもよい。次いで、EASPは、濾過と瓶詰めの最終工程に続く。濾過と瓶詰めの手順は三つの主なイベントからなる。すなわち、transition1リソースにおいて濾過フィルタをオンにすること、transition2リソースにおいて濾過フィルタをオフにすることおよび瓶詰め処理をオンにすること、および最後に、transition3リソースにおいて瓶詰め処理をオフにすることからなる。この参照はeid8に対するものであり、eid3に対するものではない。これは、transition2リソースおよびtransition3リソースに適用される。

【0068】

Open Connectivity Forum： Open Connectivity Forum (OCF)は、IoTデバイスが互いに通信するためのサービスレイヤ機能を定義する、oneM2Mと同様の別のIoTアーキテクチャである。OCF(例えば、OICコア仕様、v1.1.0［3］）では、CSE上でデバイスリソースを集中的にホストするoneM2Mとは異なり、リソース自体がOICサーバ上でローカルにホストされる。しかしながら、OCFは、ゲートウェイデバイスとして実現され得るOIC中継部を定義している。図１２は、OCFによって定義されるエンティティの役割の一例を示す。OICクライアントは、OIC中継部を介してOICサーバにリクエストを行う。OIC中継部は複数のデバイスリソースにアクセスすることができ、その結果、本明細書で開示されるEASP処理機能を利用することができる。したがって、構成可能イベント・アクション・シーケンシング・システム２１０は、本明細書で開示されるサービスを提供するために、ゲートウェイの一部として統合され得る。これは、様々なIoTデバイスおよびそれらのリソースへのアクセスを有し、それにより、IoTプロセスを定義してデバイスを監視し制御するために使用することができる。

【0069】

OCFは、シーン、ルール、およびスクリプトを使用してタスクを自動化するためのメカニズムを定義する。これらのリソースはイベント管理のような動作を提供するが、それらの機能は現在、特定のイベントが真であることを検出し、次いで、いくつかの自動化されたタスクを実行するためにスクリプトを実行することのみに限定される。これらのリソースを更新するには、本明細書で開示されるEASP処理機能を使用可能にするために、かなりのリワークが必要となる。その結果、新しいOICリソースはOCFの例としてここに導入される。

【0070】

新しいOCFリソースタイプは、表１０に示すように定義することができる。これらのリソースタイプは図３に示すものと同様の構造を定義するが、OCF仕様内に収まるように指定される。最上位レベルはoic.wk.easplistリソースタイプであり、これは子oic.wk.easpリソースをホストするための集合リソースである。子oic.wk.easpリソースは、上で開示されたEASPリソースと同じである。最後に、oic.wk.eventStateリソースはoic.wk.easpの子リソースであり、EASPプロセスのイベント状態リソースを表す。次に、Transitionsリソースは以下に概説するように、OCFリソースプロパティとして実現される。開示されたリソースタイプはプレフィックス「oic.wk」を使用することに注意されたい。代替的プレフィックス「oic.r」も、OICリソースタイプを指定するために使用できる。他に注目すべきことは、oic.if.easpインタフェースの導入であり、これはリクエスタに対してEASPプロセスの特殊化された表現を提供するものであり、後述する。新しいリソースタイプは他のOCF定義インタフェースもサポートできるが、簡潔にするためにリストしていない。

【表10】

【0071】

表１１は、oic.wk.easplistリソースについて開示されたプロパティを示す。プロパティの大部分は、OIC集合リソースをサポートするために提供される。nfプロパティは集合に関するステータス情報を提供し、この集合で見つかったoic.wk.easpリソース（IoTプロセス）の数を示す。この情報は当該集合を管理するために使用でき、またイベント・アクション・シーケンシング・システム２１０の負荷を決定するために使用することができる。

【表11】

【0072】

表１２は、oic.wk.easpリソースについて開示されたプロパティを示す。これらのプロパティは、上述のように<easp>リソース２８０のパラメータを表す。これらのプロパティは、上に指定したのと同じ機能を有する。

【表12】

【0073】

表１３は、oic.wk.eventStateリソースについて開示されたプロパティを示す。これらのプロパティは、上述のように<eventState>リソースのパラメータを表す。この場合、遷移パラメータは、oic.wk.eventStateの子リソースではなく、OICプロパティとして表されることに留意されたい。それでも、遷移リソースと同じ状態遷移を決定する機能を提供する。

【表13】

【0074】

ユニークなOCFの特徴の一つが、OCFインタフェースコンセプトであり、OCFリソースが見えること（ビューを提供すること）と定義される。OCFでは、リソースにアクセスするときにどのタイプのリクエストおよび応答が許可されるかをインタフェースが定義する。例えば、OCF oic.if.baselineインタフェースは、読出リクエストおよび更新リクエストの両方がリソースに対して行われることを可能にし、応答は、メタプロパティを含むリソースの完全な表現を含む。表１４は、OCFインタフェースのリストを示す。一方、oic.if.rインタフェースは、ソースのプロパティを読み出すものにリクエストを制限する。このインタフェースコンセプトを使用して、新しいOCFインタフェースoic.if.easpを作成して、リクエスト中に提供されるクエリストリングに応じて異なる応答を提供することができる。次いで、このインタフェースは、リソースマネージャ２１４の動作に記述される、開示される応答の一つ、すなわち、現在の表現、現在のEASPおよびイベント状態ステータス、ならびにEASP構造全体をデバイスが返すことを可能にする。イベント・アクション・シーケンシング・システム２１０によって必要とされるように、追加の応答データもこのインタフェースによって提供されてもよい。こうした特殊な応答を提供するため、新しいoic.if.easpインタフェースを定義して表１４に追加してもよい。

【表14】

【0075】

工業工場：工業工場では、組立ラインに特定の機能を実行するロボットが配置される。最終製品を製造するために、配列された複数のステーションがある。図１３はこのようなステーションが二つ相互接続されたものを示す。ステーション２２０（ステーション３１７およびステーション３１８）の出力は、ステーション２１０（ステーション３１１～ステーション３１５）への入力である。ステーション２２０中のステーションは１時間当たり５ユニットの速度で出力することができ、ステーション２１０中のステーションは、１時間当たり２ユニットの速度で入力を受け取ることができる。ステーションは、生産性を最大にするためにロボットがアイドル状態のままである時間を最小にするように調整される。

【0076】

工場は、ここに開示される構成可能イベント・アクション・シーケンシング・システム２１０を実施し、図示されるステーションそれぞれを制御するためにEASPが作成される。各EASPプロセスは複数のイベント状態を有し、イベント状態は各ステーションが所望の速度で出力することを保証するために、Time Durationパラメータを使用して制御される。イベント・アクション・シーケンシング・システム２１０の管理者は、IoT処理のそれぞれに完全にアクセスすることができ、必要に応じてそれらをインタラクティブに制御することができる。さらに、各ロボットは、管理者が各ステーションの出力を監視することができるように、その動作の診断を提供する。

【0077】

ステーション３１１は、信頼性をもって動作したが、最近故障の兆候を示している古いロボットを含むかもしれない。一回のシフトの間、ステーション３１１は、その構成要素の一つが適切に動作していないという診断情報を送る。これに応答して、管理者は、ステーション３１１のEASPリソースの制御パラメータを「即時終了」に変更してステーションをシャットダウンするリクエストを送信する。次に、管理者はステーション３１１がシャットダウンされていることに対処するため、より遅い速度で出力するように、ステーション３１７およびステーション３１８のIoT処理を再プログラムする。図１４は、ステーション３１７およびステーション３１８のIoTプロセス各々をインタラクティブに制御するために管理者が実行するコールフローを示す。

【0078】

図１４は、EASPプロセスの例示的なインタラクティブ制御を示す。ステップ３３１において、管理者３２１はステーション３１７のEASPリソース（例えば、EASPリソース２１７）をターゲットとする更新リクエストを送信して、EASPを一時停止する。この場合、制御パラメータは「一時停止」に設定される。ステップ３３２で、イベント・アクション・シーケンシング・システム２１０内で、リソースマネージャ２１４は構成可能イベント・アクション・シーケンシング・システム２１０の一部である実行ユニット２１６に信号を送り、現在のイベント状態の動作を中断する。実行ユニット２１６はイベント状態の実行を制御しているタイマを停止し、実行している可能性がある任意のアクションを停止することができる。ステップ３３３で、イベント・アクション・シーケンシング・システム２１０は、EASPが一時停止されたことを示す応答を返すことができる。管理者３２１は、ステーション３１８のEASPについてステップ３３１～ステップ３３３を繰り返すことができる。ステップ３３４において、管理者３２１は、ステーション３１７のEASPリソースのTimeDurationパラメータを、１時間当たり４ユニットの速度で出力するように調整する。管理者は必要に応じて、複数のイベント状態リソース（例えば、イベント状態リソース２１８）についてこのリクエストを実行する。

【0079】

引き続き図１４を参照すると、ステップ３３５において、リソースマネージャ２１４は、ステーション３１７のEASPリソースのイベント状態リソースに対して適切な変更を行う。現在のイベント状態について、リソースマネージャ２１４は、実行ユニット２１６に直接変更を信号で伝えることができる。あるいは、リソースマネージャ２１４は、既存のイベント状態を更新するために、更新エンジン２１３に変更を転送することができる。非アクティブなイベント状態リソースの場合、リソースマネージャ２１４は単に、対応するイベント状態リソースのデータベース２１５を更新することができる。ステップ３３６では、イベント・アクション・シーケンシング・システム２１０は、変化が行われたことを示す応答を返す。管理者は、ステーション３１８のEASPについてステップ３３４～ステップ３３６を繰り返すことができる。ステップ３３７で、すべてのTime Durationパラメータが変更されると、管理者は、ステーション３１７の動作を再開するために「再開」リクエストを送る。これは、制御パラメータが「再開」に設定されているリクエストを送信することを伴ってもよい。ステップ３３８において、リソースマネージャ２１４は、現在のイベント状態の動作を再開するために、実行ユニット２１６に信号を送る。この時点で、タイマは、生産を減速させるようステップ３３４～ステップ３３６で行われた変更を反映する。ステップ３３９で、イベント・アクション・シーケンシング・システム２１０は、EASPが再始動されたことを示す応答を返す。管理者は、ステーション３１８のEASPについてステップ３３７～ステップ３３９を繰り返すことができる。

【0080】

ユーザインタフェース： 図１５は、EASPプロセスの情報を表形式で示すために構成可能イベント・アクション・シーケンシング・フレームワーク２１０が提供することができる例示的なユーザインタフェースを示す。この表は、上述のワイン製造ユースケースにおけるイベント状態を示し、ウェブインタフェースを介して提示されてもよい。表内の情報は、返されるべき応答データを指定するためのクエリインタフェースを使用して、イベント・アクション・シーケンシング・システム２１０から読み出すことができる。この場合、EASPリソース構造ならびにEASPおよび現在のイベント状態のステータスを返すように指定することができる。表内では、現在のイベント状態はeid5（太字）である。表は、色分けされていてもよい。例えば、既存のイベント状態は黒色であってもよく、（EASPが実行されている間に）新たに追加されたイベント状態は淡青色であってもよい。currentStatus属性のテキストは、視覚的表現を迅速にワインメーカに提供できるよう色分けされてもよい。作成された既存の属性のEASPに対する現在の更新を、赤いテキストで表すことができる。

【0081】

<easp>リソースが作成されると、それは将来の使用のために保存され、他のワインタイプのために調整されてもよい。ワインメーカは、異なるブドウ品種に対応するため、必要に応じて異なる発酵時間を試したりイベント状態を追加または除去したりすることができる。発酵はバッチごとに変化し得るので、ワインメーカがEASPの動作を調整する能力は、可能な限り最良の味のワインを製造するために重要である。

【0082】

図１６は、本明細書で説明される方法およびシステムに基づいて生成され得る例示的なディスプレイ（例えば、グラフィカル・ユーザ・インタフェース）を示す。ディスプレイインタフェース９０１（例えば、タッチスクリーンディスプレイ）は、EASPプロセスのスナップショットビューを提供することができる。ディスプレイインタフェースのタイトル９０２は、EASPの名前および現在のイベント状態をそれぞれ示す。タイトルの下には、EASPプロセス全体の高レベルフロー９０３があり、現在のイベント状態が強調表示されている。ディスプレイインタフェースの下部には、EASPプロセス９０４と現在のイベント状態９０５の両方のステータス情報がある。EASPプロセス９０４の場合、詳細および制御ボタンにより、ユーザはEASPプロセスを閲覧し、場合によっては更新することができる。現在のイベント状態ステータス９０５については、次の遷移先すべてのリストが表示され、現在のイベント状態から可能な遷移がユーザに示される。

【0083】

図１７Ａはイベント・アクション・シーケンシング・システム２１０に関連する一つまたは複数の開示された概念（例えば、図２～図１５よび付随する説明）を実現することができる、例示的なマシン・ツー・マシン（M2M）、モノのインターネット（IoT）、またはモノのウェブ（WoT）通信システム１０の図である。一般に、M2M技術はIoT/WoTのためのビルディング・ブロックを提供し、任意のM2Mデバイス、M2Mゲートウェイ、またはM2Mサービスプラットフォームは、IoT/WoT、およびIoT/WoTサービス層などの構成要素とすることができる。

【0084】

図１７Ａに示すように、M2M/IoT/WoT通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ISDN、PLCなど）、または無線ネットワーク（例えば、WLAN、セルラなど）、または異種ネットワークのネットワークであってもよい。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のユーザに提供する複数のアクセスネットワークを備えることができる。例えば、通信ネットワーク１２は、符号分割多重接続（CDMA）、時分割多重接続（TDMA）、周波数分割多重接続（FDMA）、直交FDMA(OFDMA)、シングルキャリアFDMA(SC－FDMA）などの一つまたは複数のチャネルアクセス方法を使用することができる。さらに、通信ネットワーク１２は例えば、コアネットワーク、インターネット、センサネットワーク、産業制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを備えることができる。

【0085】

図１７Ａに示すように、M2M/IoT/WoT通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含んでもよい。インフラストラクチャドメインとは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは、通常は、M2Mゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ１４および端末装置１８を含む。任意の数のM2Mゲートウェイ装置１４およびM2M装置１８が、必要に応じて、M2M/IoT/WoT通信システム１０に含まれてよいことが理解されよう。M2Mゲートウェイ装置１４およびM2M装置１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して、信号を送受信するように構成される。M2Mゲートウェイ装置１４は、通信ネットワーク１２などのオペレータネットワーク、または直接無線リンクのいずれかを通して、無線M2M装置（例えば、セルラおよび非セルラ）ならびに固定ネットワークM2M装置（例えば、PLC）が通信できるようにする。たとえば、M2M装置１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、M2Mアプリケーション２０またはM2M装置１８にデータを送信してもよい。M2M装置１８はまた、M2Mアプリケーション２０またはM2M装置１８からデータを受信してもよい。さらに、データおよび信号は、以下で説明されるように、M2Mサービス層２２を介して、M2Mアプリケーション２０との間で送受信され得る。M2M装置１８およびゲートウェイ１４はたとえば、セルラ、WLAN、WPAN(例えば、Zigbee、6LoWPAN、Bluetooth（登録商標））、直接無線リンク、および有線を含む、様々なネットワークを介して通信してもよい。

【0086】

図１７Ｂを参照すると、図示されているフィールドドメイン内のM2Mサービス層２２は、M2Mアプリケーション２０、M2Mゲートウェイ装置１４、およびM2M端末装置１８、ならびに通信ネットワーク１２にサービスを提供する。M2Mサービス層２２は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイ装置１４、M2M端末装置１８、および通信ネットワーク１２と通信してよいことを理解されたい。M2Mサービス層２２は、一つまたは複数のサーバ、コンピュータなどによって実装されてよい。M2Mサービス層２２は、M2M端末装置１８、M2Mゲートウェイ１４及びM2Mアプリケーション２０に適用するサービス性能を提供する。M2Mサービス層２２の機能は、たとえば、ウェブサーバとして、セルラコアネットワークで、クラウドで、など様々な方法で実装されてよい。

【0087】

図示されているM2Mサービス層２２に類似したM2Mサービス層２２’が、インフラストラクチャドメイン内に存在する。M2Mサービス層２２’は、インフラストラクチャドメイン内のM2Mアプリケーション２０’および下位通信ネットワーク１２’にサービスを提供する。M2Mサービス層２２'はまた、フィールドドメイン内のM2Mゲートウェイ装置１４およびM2M端末装置１８にサービスを提供する。M2Mサービス層２２'は、任意の数のM2Mアプリケーション、M2Mゲートウェイ装置、およびM2M端末装置と通信してよいことが理解されよう。M2Mサービス層２２'は、異なるサービスプロバイダによるサービス層とインタラクトしてもよい。M2Mサービス層２２'は、一つまたは複数のサーバ、コンピュータ、仮想マシン（例えば、クラウド/コンピュータ/ストレージファームなど）などによって実現できる。

【0088】

さらに図１７Ｂを参照すると、M2Mサービス層２２および２２'は、多様なアプリケーションおよびバーティカルなシステムが活用することができるサービス配信性能のコアセットを提供する。これらのサービス性能はM2Mアプリケーション２０および２０'がデバイスとインタラクトし、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス/デバイス発見などの機能を果たすことを可能にする。本質的に、これらのサービス性能は、これらの機能を実装する負担をアプリケーションから取り除くので、アプリケーション開発を単純化し、市場に出す費用および時間を低減する。サービス層２２および２２'はまた、M2Mアプリケーション２０および２０'が、サービス層２２および２２'が提供するサービスと連携して、様々なネットワーク１２および１２'を介して通信することも可能にする。

【0089】

いくつかの例では、M2Mアプリケーション２０および２０'は、ここに開示されるように、イベント・アクション・シーケンシング・システム２１０を使用して通信する所望のアプリケーションを含んでもよい。M2Mアプリケーション２０および２０'は、限定するものではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギ管理、アセット追跡、ならびにセキュリティおよび監視などの種々の産業のアプリケーションを含むことができる。上述のように、システムのデバイス、ゲートウェイ、および他のサーバにわたって実行されるM2Mサービス層は、たとえば、データ収集、デバイス管理、セキュリティ、課金、位置追跡/ジオフェンシング、デバイス/サービス発見、およびレガシーシステム統合などの機能をサポートし、サービスとしてこれらの機能をM2Mアプリケーション２０および２０’に提供する。

【0090】

本出願のイベント・アクション・シーケンシング・システムは、サービス層の一部として実装できる。サービス層は、アプリケーションプログラミングインターフェース（API）と下位ネットワーキングインターフェースとのセットを介して付加価値サービス能力をサポートするミドルウェア層である。M2Mエンティティ（例えば、ハードウェア上に実装されるデバイス、ゲートウェイ、またはサービス/プラットフォームなどのM2M機能エンティティ）は、アプリケーションまたはサービスを提供することができる。ETSI M2MおよびoneM2Mの両方は、本願のイベント・アクション・シーケンシング・システムを含むことができるサービス層を使用する。oneM2Mサービス層は共通サービス機能（CSF）のセット（すなわち、サービス性能）をサポートする。一つまたは複数の特定のタイプのCSFのセットのインスタンス化は、共通サービスエンティティ（CSE）と呼ばれ、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）上でホストされ得る。さらに、本願のイベント・アクション・シーケンシング・システムは、本願のイベント・アクション・シーケンシング・システムなどのサービスにアクセスするために、サービス指向アーキテクチャ（SOA）またはリソース指向アーキテクチャ（ROA）を使用するM2Mネットワークの一部として実装され得る。

【0091】

ここに開示するように、サービス層は、ネットワークサービスアーキテクチャ内の機能層とすることができる。サービス層は通常、HTTP、CoAP、またはMQTTなどのアプリケーションプロトコル層の上に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層は例えば、コントロール層およびトランスポート/アクセス層のような、下位リソース層におけるコアネットワークへのインタフェースも提供する。サービス層は、サービス定義、サービスランタイムイネーブルメント、ポリシー管理、アクセス制御、およびサービスクラスタリングを含む（サービス）能力または機能の複数のカテゴリをサポートする。最近、いくつかの業界標準化団体、例えば、oneM2Mは、M2Mタイプのデバイスおよびアプリケーションを、インターネット/ウェブ、セルラ、企業、およびホームネットワークなどの配備に統合することに関連する課題に対処するために、M2Mサービス層を開発している。M2Mサービス層は、CSEまたはSCLと呼ぶことができる、サービス層によってサポートされる、上述の能力または機能の集合またはセットへのアクセスを、さまざまなアプリケーションまたはデバイスに提供できる。いくつかの例は、これに限定されるものではないが、様々なアプリケーションに共通して使用され得る、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理を含む。これらの能力または機能は、M2Mサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するAPIを介して、そのような様々なアプリケーションに利用可能にされる。CSEまたはSCLは、ハードウェアまたはソフトウェアによって実装することができる機能的エンティティであり、さまざまなアプリケーションまたはデバイス（すなわち、そのような機能エンティティ間の機能インタフェース）に対して公開される（サービス）能力または機能を、それらアプリケーションまたはデバイスが使用できるよう提供する。

【0092】

図１７Ｃは、例示的なM2M装置３０のシステム図である。例示的M2M装置３０は例えば、（IoTデバイス２４２を含んでもよい）M2M端末装置１８、または（図５の一つまたは複数の構成要素を含んでもよい）M2Mゲートウェイ装置１４などである。図１７Ｃに示すように、M2M装置３０は、プロセッサ３２、トランシーバ３４、送信/受信要素３６、スピーカ/マイクロフォン３８、キーパッド４０、ディスプレイ/タッチパッド４２、非リムーバブルメモリ４４、リムーバブルメモリ４６、電源４８、全地球測位システム（GPS）チップセット５０、および他の周辺機器５２を含んでもよい。M2M装置３０は、開示された主題との一貫性を保ちつつ、前述の要素の任意のサブコンビネーションを含んでもよいことは理解されたい。M2M装置３０（例えば、イベント・アクション・シーケンシング・システム２１０、IoTデバイス２４２、IoTリクエスタ２４１、その他）は、イベント・アクション・シーケンシング・システムのための開示されたシステムおよび方法を実行する例示的な実装であってもよい。

【0093】

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（DSP）、複数のマイクロプロセッサ、DSPコアに関連付けられた一つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）回路、任意のその他のタイプの集積回路（IC）、状態マシンなどであってよい。プロセッサ３２は、信号コーディング、データ処理、電力制御、入力/出力処理、またはM2M装置３０が無線環境で動作することを可能にする任意の他の機能を実行してもよい。プロセッサ３２は、送信／受信要素３６と結合され得るトランシーバ３４と結合されてもよい。図１７Ｃは、プロセッサ３２とトランシーバ３４とを別個の構成要素として示すが、プロセッサ３２とトランシーバ３４とは電子パッケージまたはチップ内に一体化されてもよいことが理解されよう。プロセッサ３２はアプリケーション層プログラム（例えば、ブラウザ）または無線アクセス層（RAN）プログラムまたは通信を実行することができる。プロセッサ３２は、例えば、アクセス層またはアプリケーション層などで、認証、セキュリティキー共有、または暗号化操作などのセキュリティ操作も実施してよい。

【0094】

送信／受信要素３６は、M2Mサービスプラットフォーム２２に信号を送信する、またはM2Mサービスプラットフォーム２２から信号を受信するように構成されてもよい。たとえば、送信／受信要素３６は、RF信号を送信または受信するように構成されたアンテナであってもよい。送信／受信要素３６は、WLAN、WPAN、セルラなどの様々なネットワークおよびエアインタフェースをサポートすることができる。一例では、送信／受信要素３６は、たとえば、IR、UV、または可視光信号を送信または受信するように構成されたエミッタ/検出器であってもよい。さらに別の例では、送信／受信要素３６は、RF信号および光信号の両方を送信および受信するように構成されてもよい。送信／受信要素３６は、無線信号または有線信号の任意の組み合わせを送信または受信するように構成され得ることは理解されよう。

【0095】

さらに、送信／受信要素３６は、図１７Ｃでは単一の要素として描かれているが、M2M装置３０は任意の数の送信／受信要素３６を含むことができる。より具体的には、M2M装置３０はMIMO技術を採用してもよい。したがって、一例では、M2M装置３０は、無線信号を送信および受信するための二つ以上の送信／受信要素３６（たとえば、複数のアンテナ）を含んでもよい。

【0096】

トランシーバ３４は送信／受信要素３６によって送信される信号を変調し、かつ、送信／受信要素３６によって受信される信号を復調するように構成されてもよい。上述したように、M2M装置３０は、マルチモード性能を有することができる。したがって、例えば、UTRAおよびIEEE 802.11などの複数のRATを介してM2Mデバイス３０が通信することを可能にするために、トランシーバ３４は複数のトランシーバを含んでもよい。

【0097】

プロセッサ３２は、非リムーバブルメモリ４４またはリムーバブルメモリ４６などの任意のタイプの適切なメモリから情報にアクセスし、その中にデータを格納することができる。非リムーバブルメモリ４４は、ランダムアクセスメモリ（RAM）、リードオンリメモリ（ROM）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。リムーバブルメモリ４６は、加入者識別モジュール（SIM）カード、メモリスティック、セキュアデジタル（SD）メモリカードなどを含んでもよい。他の例では、プロセッサ３２は、サーバまたはホームコンピュータなどのM2M装置３０上に物理的に位置しないメモリから情報にアクセスし、当該メモリにデータを格納してもよい。プロセッサ３２は、ここで説明される例のいくつかにおけるイベント・アクション・シーケンスに関連する方法およびシステムが成功したか失敗したか（例えば、リクエストなど）に応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するように、または、イベント・アクション・シーケンシング・システム２１０および関連する構成要素のステータスを別の態様で示すように構成されてもよい。ディスプレイまたはインジケータ４２上の制御照明パターン、画像、または色は、ここで図示または説明する図（例えば、図１～図１５など）の方法フローまたは構成要素のいずれかの状態を反映することができる。ここでは、イベント・アクション・シーケンシング・システムのメッセージおよび手順を開示する。メッセージおよび手順は、ユーザが入力ソース（例えば、スピーカ/マイクロフォン３８、キーパッド４０、またはディスプレイ/タッチパッド４２）を介してイベント・アクション・シーケンシング・システム情報（例えば、イベント状態リソース２１８）をリクエストするためのインタフェース/APIを提供するように拡張することができる。追加の例では、イベント・アクション・シーケンシング・システム情報のリクエスト、構成、またはクエリ等をディスプレイ４２上に表示してもよい。

【0098】

プロセッサ３２は、電源４８から電力を得てよく、M2M装置３０内のその他の構成要素への電力を分配または制御するように構成されてよい。電源４８は、M2M装置３０に給電するための任意の適切な装置であってよい。例えば、電源４８は、一つ以上の乾電池（たとえば、ニッケルカドミウム（NiCd）、ニッケル亜鉛（NiZ）、ニッケル水素（NiMH）、リチウムイオン（Li-ion）等）、太陽電池、燃料電池等を含んでもよい。

【0099】

プロセッサ３２はまた、M2M装置３０の現在位置に関する位置情報（たとえば、経度および緯度）を提供するように構成されたGPSチップセット５０に連結されてもよい。M2M装置３０は、ここに開示される情報との一貫性を保ちつつ、任意の適切な位置決定方法によって位置情報を取得できることが理解されよう。

【0100】

プロセッサ３２はさらに、追加の特徴、機能、または有線もしくは無線接続性を提供する、一つまたは複数のソフトウェアまたはハードウェアモジュールを含みうるその他の周辺機器５２に連結されてよい。例えば、周辺機器５２としては、加速度計、バイオメトリック（たとえば、指紋）センサなどの種々のセンサ、eコンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（USB）ポートまたはその他の相互接続インタフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth（登録商標）モジュール、周波数変調（FM）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでよい。

【0101】

送信／受信要素３６は、センサ、家庭用電化製品、スマートウォッチまたはスマートウェアなどのウェアラブル装置、医療またはeヘルス装置、ロボット、産業機器、ドローン、自動車、トラック、電車または飛行機などの乗り物などの他の装置またはデバイス内で具現化されてもよい。送信／受信要素３６は、周辺機器５２のうちの一つを備えることがある相互接続インタフェースなどの一つまたは複数の相互接続インタフェースを介して、上記装置またはデバイスの他の構成要素、モジュール、またはシステムに接続してもよい。

【0102】

図１７Ｄは例えば、図１７Ａおよび図１７ＢのM2Mサービスプラットフォーム２２を実装することができる例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０（例えば、M2M端末装置１８またはM2Mゲートウェイ装置１４）は、コンピュータまたはサーバを含んでもよく、主にコンピュータ可読命令で制御できる。かかる命令の記憶およびアクセスの手法は限定されない。かかるコンピュータ可読命令は、中央処理装置（CPU）９１内で実行されて、コンピューティングシステム９０を動作させることができる。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれるシングルチップCPUで実現される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備えることができる。コプロセッサ８１は、メインCPU９１とは別個のオプションのプロセッサであり、追加の機能を実行し、またはCPU９１を補助する。CPU９１またはコプロセッサ８１は、EASPリソース要求メッセージの受信など、イベント・アクション・シーケンシングに関連する、開示されたシステムおよび方法に関連するデータを受信し、生成し、処理することができる。

【0103】

動作時、CPU９１は、命令をフェッチし、デコードし、実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ転送する、かつ他のリソースから転送する。当該システムバスは、コンピューティングシステム９０内のコンポーネント同士を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するためおよびシステムバスを操作するための制御ラインとを含む。このようなシステムバス８０の一例として、PCI(周辺コンポーネント相互接続：Peripheral Component Interconnect)バスがある。

【0104】

システムバス８０に連結されるメモリデバイスは、ランダムアクセスメモリ（RAM）８２および読取り専用メモリ（ROM）９３を含む。このようなメモリは、情報の記憶および読出しを可能にする回路を含む。ROM９３は、概して、容易に変更することができない記憶されたデータを含む。RAM８２に記憶されたデータは、CPU９１またはその他のハードウェア装置によって読み取りまたは変更ができる。RAM８２またはROM９３へのアクセスは、メモリコントローラ９２によって制御されてよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換する、アドレス変換機能を提供してもよい。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供してもよい。したがって、第１のモードで起動するプログラムは、それ自体のプロセス仮想アドレス空間によってマッピングされたメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

【0105】

さらに、コンピューティングシステム９０は、CPU９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に命令を通信する役割を担う周辺機器コントローラ８３を含んでもよい。

【0106】

ディスプレイ８６は、ディスプレイコントローラ９６によって制御され、コンピューティングシステム９０によって生成された視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでよい。ディスプレイ８６は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルで実装されてもよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するのに必要な電子構成要素を含む。

【0107】

さらに、コンピューティングシステム９０は、図１７Ａおよび図１７Ｂのネットワーク１２などの外部通信ネットワークにコンピューティングシステム９０を接続するために使用されうるネットワークアダプタ９７を含んでもよい。

【0108】

本明細書に記載されるシステム、方法、およびプロセスのいずれかまたはすべては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（たとえばプログラムコード）の形態で具現化されてよく、その命令はたとえば、コンピュータ、サーバ、M2M端末装置、M2Mゲートウェイ装置などの機械によって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実行または実装することが理解される。具体的には、上述の工程、動作、または機能のいずれも、このようなコンピュータ実行可能命令の形で実装することができる。コンピュータ可読記憶媒体は、情報を記憶するための任意の方法または技術で実装された揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は信号それ自体は含まない。本明細書の説明から明らかなように、記憶媒体は、法定主題であると解釈されるべきである。コンピュータ可読記憶媒体には、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD－ROM、デジタル多用途ディスク（DVD）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理媒体が含まれる。コンピュータ可読記憶媒体はその上に記憶されたコンピュータプログラムを有することができ、コンピュータプログラムはデータ処理ユニットにロード可能であり、コンピュータプログラムがデータ処理ユニットによって実行されるときに、データ処理ユニットに方法ステップを実行させるように適合されることができる。

【0109】

図面に示す本開示の主題の好ましい方法、システム、または装置、すなわち、イベント・アクション・シーケンシングに関連する方法およびシステムの説明に際し、明確化のために特定の用語が使用される。しかしながら、特許請求される主題は、選択された特定の用語に限定されることを意図するものではなく、各特定の要素は、同様の目的を達成するために同様の方式で動作するすべての技術的等価物を含むことを理解されたい。

【0110】

本明細書で説明される様々な技法はハードウェア、ファームウェア、ソフトウェア、または適切な場合にはそれらの組合せに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの様々なノードに位置する装置に常駐することができる。装置は本明細書で説明される方法を実施するために、単独で、または互いに組み合わせて動作することができる。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード」などは、互換的に使用され得る。加えて、単語「または」の使用は本明細書で特に断らない限り、一般に包括的に使用される。

【0111】

本明細書は最良の形態を含めて本発明を開示するために、また、任意のデバイスまたはシステムを作製および使用すること、ならびに任意の組み込まれた方法を実行することを含めて、当業者が本発明を実施することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、特許請求の範囲によって定義され、当業者に想起される他の実施例（例えば、ステップをスキップすること、図５～図６などのステップを組み合わせること、またはここで開示される例示的な方法の間にステップを追加すること）を含むことができる。このような他の実施例は、構成要素が特許請求の範囲に記載のものと相違ない場合、または特許請求の範囲に記載のものとそれほど相違ない同等の構成要素を含む場合、特許請求の範囲内であるものとする。

【0112】

ここでは、EASPの機能が実現されるシステムが開示される。IoTデバイスは、（図３、図５、図９、図１０、図１１に示すように）EASPリソース、イベント状態リソース、および遷移リソースの使用に基づいてEASPを作成することができる。開示する方法およびシステムは、（図８、図１４に示すように）EASPが動作中にEASPの動作を更新することを可能にする。表１～表３などの情報は、EASPを作成するために使用できるアプリケーションプログラミングインタフェースと見なすことができる。

【0113】

構成可能イベント・アクション・シーケンシングのリソース作成のリクエストを処理することで、IoTシステムは複雑なアプリケーションのコンポーネントを定義する。作成されるリソースは、EASPリソース、イベント状態リソースおよび遷移リソースと、それらの関連パラメータである。

【0114】

構成可能イベント・アクション・シーケンシングIoTシステムの実行を可能にして、当該システムはEASPの動作を管理する。これには、並列実行可能な他のEASPへのリンク、システムが実行されているときにEASPの動作に影響を与えずにEASP内のリソースを更新すること、および、EASPの動作のステータスをリクエスタに提供することを含む。さらに、開示するシステムは、EASPリソースのパラメーター（前提条件および/または終了条件）を用いて、複数のEASPをリンクする能力を有する。この能力によって、より小さいコンポーネントをリンクすることで複雑なIoTアプリケーションを作成することが可能になる。

【0115】

EASPは、アプリケーションが複数のステップ（例えば、モジュール）を必要とする場合に、アプリケーションのための動作を実行するようにプログラムされる。図１に示すワイン製造アプリケーションは、ワインの製造処理を開始するべくブドウを軸から外すことで始まる多数のステップを含む。EASPは、これらを実行するようにプログラミングされる。EASPは例えば、一度に１ステップずつプロセスを順序付けし、関連するEASPリソース（例えば、表１、表２、または表３）を有する。別のステップへの遷移は、検出されたイベントによって引き起こされることもある。

【0116】

とりわけ、ここで説明した方法、システム、および装置は、モノのインターネットシステムにおける構成可能イベント・アクション・シーケンシングの手段を提供することができ、そこには、リクエスタからリクエストを取得してイベント・アクション・シーケンシング・プロセス・リソース（EASPリソース）を作成することが含まれてもよく、EASPリソースは以下の情報を含んでもよい：EASP ID、説明、EASPの現在のステータス、制御動作、前提条件、終了条件、EASP内のイベントの数、EASPが開始するときの最初のイベント状態、またはEASPの最後のイベントである。そして、リクエストに応じて、EASPリソースを作成する。EASP ID、説明、EASPの現在の状態、制御動作、前提条件、終了条件、EASP内のイベントの数、EASPが開始するときの初期イベント状態、またはEASPの最終イベントは、特定のパラメータに対応する。方法、装置、コンピュータ可読記憶媒体、または装置は、必要に応じてリクエスタに状態情報を転送できるよう、通信維持の手段を有する。方法、装置、コンピュータ可読記憶媒体、または装置は、前提条件または終了条件のパラメータを使用して、現在のEASPの動作を他の既存のEASPとリンクさせるための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、リクエスタから、イベント状態リソース（例えば、イベント状態に関連するリソース）を作成するためのリクエストを取得する手段を有する。イベント状態リソースは、以下の情報を含んでよい：すなわち、現在のイベント状態について使用される識別子、イベント状態の説明、イベント状態の現在のステータス、イベント状態の持続時間として設定される時間、イベント状態の早期終了または非同期終了を可能にするよう現在のイベントを終了させるイベント、イベント状態の遷移をトリガするイベントと、遷移先の次のイベント状態のID、他のイベント状態に遷移するよう遷移イベントパラメータがトリガされたときに実行されるアクションのリスト、または次のイベント状態の識別子である。そして、リクエストに応じてイベント状態リソースを作成する。現在のイベント状態について使用される識別子、イベント状態の説明、イベント状態の現在のステータス、イベント状態の持続時間として設定される時間、イベント状態の非同期終了を可能にするために現在のイベント状態を終了するイベント、イベント状態遷移をトリガするイベント、および遷移先の次のイベント状態のID、別のイベント状態に遷移するように遷移イベントパラメータがトリガされ得るときに実行されるアクションのリスト、または次のイベント状態の識別子は、特定のパラメータに対応する。方法、装置、コンピュータ可読記憶媒体、または装置は、必要に応じてリクエスタに状態情報を転送できるよう、通信維持の手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、EASPがアクティブな間にEASPの動作に影響を及ぼすことなく、新しく動的にEASPに追加されたイベント状態リソース、または、既存のイベント状態リソースに対する変更を統合することができるかどうかを判定する手段を有する。この段落および以下の段落に記載の組み合わせはすべて（工程の削除または追加を含め）、詳細な説明の他の部分と一貫した態様で意図される。

【0117】

方法、システム、コンピュータ可読記憶媒体、または装置は、遷移リソースを作成するため、リクエスタからリクエストを取得するための手段を有する。ここで、遷移リソースは以下の情報を含んでよい：イベント状態の遷移を引き起こすイベント、イベントの発生の結果として実行され得るアクション、または遷移先の次のイベント状態。そして、リクエストに応じて遷移リソースが作成される。イベント状態の遷移を引き起こすイベント、イベントの発生の結果として実行され得るアクション、または遷移先の次のイベント状態は、特定のパラメータに対応する。方法、システム、コンピュータ可読記憶媒体、または装置は、必要に応じてリクエスタに状態情報を転送できるよう、通信維持の手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、EASPがアクティブな間にEASPの動作に影響を及ぼすことなく、新しく動的にEASPに追加された遷移リソース、または、既存の遷移リソースに対する変更を統合することができるかどうかを判定するための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、イベント・アクション・シーケンシング・プロセスリソース（EASPリソース）作成のリクエストをリクエスタから取得するための手段を有する。ここで、EASPリソースは、イベントを適用可能なアクションにリンクすることにより、複雑なモノのインターネットアプリケーションを、より細かいアプリケーションのコンポーネントで定義する。EASPリソースは以下の情報を含んでよい：すなわち、EASP ID、説明、EASPの現在のステータス、制御動作、前提条件、終了条件、EASP内のイベントの数、EASPが開始するときの初期イベント状態、またはEASPの最終イベント。そして、リクエストに応じて、EASPリソースが作成される。この段落および以下の段落に記載の組み合わせはすべて（工程の削除または追加を含め）、詳細な説明の他の部分と一貫した態様で意図される。

【0118】

方法、システム、コンピュータ可読記憶媒体、または装置は、アプリケーションのための複数のイベント状態リソースのうち、第１のイベント状態リソースを作成するためのリクエストを取得するための手段を有する。ここで、イベントは、実行されるべき動作をトリガする、モノのインターネットシステムにおける条件である。リクエストに応じて、イベント状態リソースが作成される。ここで、イベント状態リソースは、イベントの状態の現在のステータスと、当該状態が持続する時間と、を含むリソースである。方法、システム、コンピュータ可読記憶媒体、または装置は、アプリケーションのための第２のイベント状態リソースを追加するためのリクエストを受信するための手段を有する。第２のイベント状態リソースを追加するためのリクエストに基づき、第１のイベント状態リソースが分析される。そして、第１のイベント状態リソースの分析に基づき、EASPがアクティブに実行されている間にEASPの動作に悪影響を及ぼすことなく第２のイベント状態リソースをEASPに統合することができるときを判定する。方法、システム、コンピュータ可読記憶媒体、または装置は、アプリケーションのための複数のイベント状態リソースのうち、第２のイベント状態リソースを更新するためのリクエストを受信する手段を有する。第２のイベント状態リソースを更新するためのリクエストに基づいて、第１のイベント状態リソースが分析される。そして、第１のイベント状態リソースの分析に基づき、EASPがアクティブに実行されている間にEASPの動作に悪影響を及ぼすことなくEASPへの第２のイベント状態リソースの更新が可能なときを判定する。第１のイベント状態リソースは、第１の遷移リソースを含んでもよい。この段落および以下の段落に記載の組み合わせはすべて（工程の削除または追加を含め）、詳細な説明の他の部分と一貫した態様で意図される。

【0119】

方法、システム、および装置、コンピュータ可読媒体は、とりわけ、ここで説明したように、アプリケーションのための複数のイベント状態リソースのうち、第１のイベント状態リソースを作成するためのリクエストを取得するための手段を含むことができるシステムにおいて、構成可能イベント・アクション・シーケンシングの手段を提供することができる。ここで、イベント状態リソースは、アプリケーションのイベントの状態に関連付けられるリソース（たとえば、ワイン製造プロセスにおける発酵ステップなど、アプリケーションの全プロセスの中に含まれるモジュールまたはステップ）であってよい。イベント（たとえば、タイマの検出、温度測定など）は、実行されるべきアクションをトリガする検出された条件であってよい。そして、リクエストに基づき、イベント状態リソースが作成される。第１のイベント状態リソースは、イベントの状態の現在のステータスと、遷移パラメータとを含むリソース（たとえば、表３の情報などを含む属性またはリソース）であってよい。方法、システム、コンピュータ可読記憶媒体、または装置は、アプリケーションのための第２のイベント状態リソースを追加または更新するためのリクエストを受信するための手段を有する。第２のイベント状態リソースを追加または更新するためのリクエストに基づき、第1のイベント状態リソースが分析される。第１のイベント状態リソースの分析に基づき、EASPがアクティブに実行されている間にEASPの動作に悪影響を及ぼすことなく、第２のイベント状態リソースを（対応するステップまたはモジュールを含むことができる）EASPに統合可能なときを判定する。イベント状態リソースは、イベントの現在の状態を終了できるよう、イベントの現在の状態を終了させるイベントの指示を含んでもよい。該システム等は、遷移リソースを生成するためのリクエストを取得するための手段を含んでもよい。該遷移リソースは、第２のイベント状態リソースに関連付けられてもよい。第１のイベント状態リソースは、遷移先の次のイベント状態の識別子を含んでもよい（例えば、図１５）。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17A】

【図17B】

【図17C】

【図17D】