知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-05
(45)【発行日】2023-10-16
(54)【発明の名称】サービス機能の要件および選好に基づくサービス登録
(51)【国際特許分類】
H04L 47/724 20220101AFI20231006BHJP
【ＦＩ】
H04L47/724
【請求項の数】
7
(21)【出願番号】P 2020518506
(86)(22)【出願日】2018-09-28
(65)【公表番号】
(43)【公表日】2020-12-10
(86)【国際出願番号】 US2018053411
(87)【国際公開番号】W WO2019067892
(87)【国際公開日】2019-04-04
【審査請求日】2021-09-21
(31)【優先権主張番号】62/565,750
(32)【優先日】2017-09-29
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】515222713
【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】チェン，チュオ
(72)【発明者】
【氏名】シード，デイル，エヌ．
(72)【発明者】
【氏名】リ，クァン
(72)【発明者】
【氏名】ムラディン，カタリナ，ミハエラ
(72)【発明者】
【氏名】フリン ４世，ウィリアム，ロバート
(72)【発明者】
【氏名】ディ ジローラモ，ロッコ
(72)【発明者】
【氏名】ローブ，ショシャーナ
【審査官】羽岡 さやか
(56)【参考文献】
【文献】国際公開第２０１７／０４０７４９（ＷＯ，Ａ１）
【文献】特表２０１３－５２２９６５（ＪＰ，Ａ）
【文献】国際公開第２０１６／１６４８９９（ＷＯ，Ａ１）
【文献】特表２０１６－５０３６０９（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１７／０２０１４１１（ＵＳ，Ａ１）
【文献】特表２０１６－５３７８３５（ＪＰ，Ａ）
【文献】欧州特許出願公開第０２７９７３６８（ＥＰ，Ａ１）
【文献】米国特許出願公開第２０１１／００４４２９１（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ４７／００
(57)【特許請求の範囲】
【請求項1】
プロセッサ、メモリ、および通信回路を含み、前記通信回路を介してネットワークに接続される装置であって、前記装置の前記メモリに格納され、前記装置の前記プロセッサによって実行されたとき、前記装置に、ａ．サービス層被登録エンティティから前記サービス層被登録エンティティに関連するサービス層機能選好を受信することと、
ｂ．前記サービス層機能選好とレジストラが使用可能な容量に少なくとも部分的に基づいて、前記サービス層被登録エンティティを登録するかどうかを判定することと、１つまたは複数の他の登録済みエンティティに対するサポートへの潜在的な影響に少なくとも部分的に基づいて、前記サービス層被登録エンティティを登録するかどうかを判定することと、
ｃ．前記サービス層被登録エンティティを登録することと、
ｄ．前記サービス層機能選好に基づいて、サービス機能を予約することを含む操作を実行させるコンピュータ実行可能命令をさらに含む装置。
【請求項2】
前記サービス層機能選好は、コンピュータメモリの量、中央演算装置パワーの帯域幅、または実行すべき操作の頻度を含む、請求項１に記載の装置。
【請求項3】
前記サービス層被登録エンティティは新しい被登録側である、請求項２に記載の装置。
【請求項4】
前記命令は、前記装置に、ａ．前記サービス層機能選好とレジストラが使用可能な容量に少なくとも部分的に基づいて、前記サービス層被登録エンティティを登録しないことを決定することと、
ｂ．新しいレジストラゲートウェイに登録を転送する要求をサーバに送信することと、
ｃ．前記新しいレジストラゲートウェイを特定する応答を前記サーバから受信することを含む操作をさらに実行させる、請求項２に記載の装置。
【請求項5】
ａ．前記サービス層機能選好はサービス機能要件を含み、ｂ．前記命令は、前記装置にさらに、前記サービス機能要件に少なくとも部分的に基づいて、前記サービス層被登録エンティティを登録することを拒否することを決定させる、請求項１に記載の装置。
【請求項6】
プロセッサ、メモリ、および通信回路を含み、前記通信回路を介してネットワークに接続される装置であって、前記装置の前記メモリに格納され、前記装置の前記プロセッサによって実行されたとき、前記装置に、ａ．第１サービス層レジストラから、サービス層被登録エンティティと、第２サービス層レジストラの識別に対する要求とに関連するサービス層機能選好を含むメッセージを受信することと、前記サービス層機能選好を含む要求を前記第２サービス層レジストラに送信することと、
ｂ．前記第２サービス層レジストラの識別を、前記第１サービス層レジストラに送信することと、前記要求に対する肯定的応答を前記第２サービス層レジストラから受信することを含む操作を実行させるコンピュータ実行可能命令をさらに含む装置。
【請求項7】
前記サービス層機能選好はサービス機能要件を含む、請求項６に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、「サービス機能の要件および選好に基づくサービス登録」（Ｃｈｅｎ他）（"Service registration based on service capabilities requirements and preferences" (Chen, et al.)）と題する２０１７年９月２９日出願の米国仮出願第６２／５６５，７５０号の利益を主張する。その内容全体は本明細書に参照により援用される。
本出願は、「サービス機能の要件および選好に基づくサービス登録」（Ｃｈｅｎ他）（"Service registration based on service capabilities requirements and preferences" (Chen, et al.)）と題する２０１７年９月２９日出願の米国仮出願第６２／５６５，７５０号の利益を主張する。その内容全体は本明細書に参照により援用される。
【背景技術】
【0002】
マシンツーマシン（Machine-to-Machine：Ｍ２Ｍ）、モノのインターネット（Internet of Things：ＩｏＴ）、およびモノのウェブ（Web of Things：ＷｏＴ）のネットワーク展開においては、Ｍ２Ｍ／ＩｏＴ／ＷｏＴアプリケーションおよびサーバをホストするＭ２Ｍ／ＩｏＴ／ＷｏＴサーバ、ゲートウェイ、およびデバイスなどの、ノード間のユニキャストおよびマルチキャスト通信を採用することができる。そのようなネットワーク展開の例としては、制約されたネットワーク、無線センサネットワーク、無線メッシュネットワーク、モバイルアドホックネットワーク、および無線センサおよびアクチュエータネットワークを挙げることができる。
【0003】
サービス層への登録は、サービス機能の要件および選好を追跡することによって改善され得る。例えば、ゲートウェイなどのサービス層レジストラは、サービス層被登録エンティティのサービス機能選好を取得できる。被登録側は、例えば、ユーザ装置デバイス、またはユーザ装置デバイスに常駐するアプリケーションであり得る。その後、レジストラは、サービス機能選好とレジストラが使用可能な容量に少なくとも部分的に基づいて、サービス層被登録エンティティを登録するかどうかを決定することができる。
【0004】
例えば、エンティティを登録する前に、レジストラは、被登録側がレジストラにサポートしてほしいトランザクションおよびその他の操作の頻度と複雑さに対して、レジストラが利用できるコンピュータメモリ量と中央処理の帯域幅を調べたい場合がある。このことから、レジストラは、他の登録済みエンティティに対するレジストラのサポートへの潜在的な影響を見積り、それによって、サービス層被登録エンティティを登録するかどうかを決定することができる。
【0005】
レジスタが要求されたサービス機能を提供できると確信する場合、レジストラは、要求中のエンティティを登録し、サービス機能の選好または要件に基づいて、被登録側にサービスするのに十分な操作上のリソースをオプションとして予約する。
【0006】
要求されたレベルの操作をサポートする能力が不足していると感じる場合、レジストラは、新しいレジストラに登録を転送することを依頼する要求をサーバに送信することができる。その後、最初のレジストラは、要求元の被登録側が使用するためのレジストラゲートウェイを特定する応答をサーバから受信することができる。
【0007】
レジストラは、サービス機能の選好または要件を含む登録要求を任意のエンティティから受信することができる。例えば、要求はユーザ装置またはサーバから来る可能性がある。同様に、レジストラは、更新されたサービス機能の選好または要件を含む登録要求を任意のエンティティから受信することができる。更新された要求は、新しい要求の処理と類似の方法で処理することができる。
【0008】
レジストラと同様に、被登録側およびサーバは、登録要求において、また、代替レジストラを求める通信において、サービス機能の選好および要件を処理するように特別に適応され得る。
【0009】
本発明の概要は、以下の「発明を実施するための形態」でさらに説明される概念の選択を、単純化された形で紹介するために提供されるものである。本発明の概要は、特許請求された主題の主要な特徴または本質的な特徴を特定することを意図するものではなく、特許請求された主題の範囲を制限するために使用されることを意図するものでもない。さらに、特許請求された主題は、本開示のいかなる部分に記載された任意またはすべての短所を解決する制限にも限定されるものではない。
【図面の簡単な説明】
【0010】
添付の図面と共に例として示される以下の説明から、より詳細な理解を得ることができる。
【図5】図５は、別のサービス層（Service Layer：ＳＬ）エンティティがデバイスによって必要なサポートのレベルを満たすことができる場合に、ＳＬに登録することに失敗したデバイスの例を示すブロック図である。
【図9】図９は、サービス機能要件プロファイル（Service Capabilities Requirement Profile：ＳＣＲＰ）が被登録側によって更新される場合のサービス層登録管理のための例示的な手順のコールフローを示す。
【発明を実施するための形態】
【0011】
Ｍ２Ｍ／ＩｏＴサービス層（ＳＬ）では、例えば、ｏｎｅＭ２Ｍの中間ノードＣＳＥ（Middle Node CSE：ＭＮ－ＣＳＥ）などのＳＬゲートウェイは、通常、ローカルに、またはネットワークのエッジに配置されて、低遅延サービスを提供する。デバイスはＳＬゲートウェイに登録して、サービスの提供および利用の少なくとも一方を実行する。しかし、これらのＳＬゲートウェイは、通常、サービス能力が限られている。ＳＬゲートウェイ上でホストされているサービスを登録して使用しているデバイスを適切に管理しなければ、ＳＬゲートウェイが過負荷となり、サービスの選好または要件を満たすようにすべてのデバイスに必要なサービスを提供することができなくなる可能性がある。本開示においては、ＳＬゲートウェイが登録済みデバイスに必要なレベルの利用可能なサービスを提供し続けるだけでなく、サービス容量があるときには新しいデバイスにサービスを提供できるように、ＳＬ登録を管理する方法を提案する。
【0012】
既存の被登録側に対するサポートのレベルがシステムに登録する新しい被登録側によって影響を受けない、強化されたＳＬ登録手順を提案する。提案された手順では、レジストラエンティティ（例えば、ＳＬゲートウェイ）は、新しい被登録エンティティ（例えば、アプリケーション）のサービス機能要件を取得して、被登録エンティティのサービスの選好または要件を満足させ、かつ既存の被登録エンティティに対するサポートのレベルが影響を受けないことを保証するだけの十分なサービス能力が残っている場合に限り、登録を受け入れる。
【0013】
強化されたＳＬ登録手順は、新しい登録アプリケーションのサービス機能の要件または選好を満たすために提案される。提案された手順では、ＳＬエンティティは、新しい被登録エンティティのサービス機能の要件および選好を取得して、被登録エンティティのサービス機能要件を満たすだけでなくサービス選好も満たすレジストラエンティティを選択する。
【0014】
被登録エンティティに関連するサービスの選好または要件が登録後に更新される場合、強化されたＳＬ登録管理手順が提案される。
【0015】
【表1】
【0016】
「Ｍ２Ｍ／ＩｏＴ ＳＬ」という用語は、一般に、アプリケーションプログラミングインターフェース（ＡＰＩ）のセットおよび基礎となるネットワークインターフェースを介してＭ２Ｍ／ＩｏＴアプリケーションおよびデバイスための付加価値サービスをサポートするソフトウェアミドルウェア層を指す。
【0017】
「Ｍ２Ｍ／ＩｏＴアプリケーション」という用語は、一般に、特定のＭ２Ｍ／ＩｏＴユースケース（例えば、ｅＨｅａｌｔｈ、スマートエネルギー、またはホームオートメーション）をターゲットとするアプリケーションを指す。
【0018】
「レジストラ」という用語は、一般に、別のＳＬエンティティが登録したＳＬエンティティを指す。
【0019】
「被登録側」という用語は、一般に、別のＳＬエンティティに登録したＳＬエンティティを指す。例えば、アプリケーション（例えば、ｏｎｅＭ２ＭコンテキストにおけるＡＥ）は、Ｍ２Ｍサーバ（例えば、ｏｎｅＭ２ＭコンテキストにおけるＣＳＥ）に登録する。アプリケーションは被登録エンティティであり、サーバはレジストラエンティティである。
【0020】
「ＳＬエンティティ」という用語は、一般に、Ｍ２Ｍ／ＩｏＴエリアネットワーク内のＭ２Ｍ／ＩｏＴサーバ、Ｍ２Ｍ／ＩｏＴゲートウェイ、またはＭ２Ｍ／ＩｏＴデバイス、あるいは、Ｍ２Ｍ／ＩｏＴアプリケーション層またはＭ２Ｍ／ＩｏＴサービス層のソフトウェアコンポーネントを指す。
【0021】
「ＳＬリソース」という用語は、一般に、Ｍ２Ｍ／ＩｏＴ ＳＬにおける一意的にアドレス可能な仮想エンティティを指す。
【0022】
「手順」という用語は、一般に、特定の目的を達成するために操作を実行する方法を指す。「手順」という用語は、Ｍ２ＭおよびＩｏＴアプリケーションのコンテキストにおける「方法」という用語の特殊な意味との混同を避けるために、「方法」の代わりに使用される。手順に関して説明されるステップは、多くの場合オプションであり、様々な手段および様々な順序で実行され得る。したがって、本明細書では、「手順」という用語は、ステップの固定的なセットおよび順序として解釈すべきではなく、様々な手段で適応可能な、結果を達成するための一般的な方法論を指す。
【0023】
本明細書では、「サービス機能要件」および「サービス機能選好」という用語は、一般に、エンティティのニーズに対応するために用いるべき機能量に対するエンティティの要件や選好を指す。サービス機能の要件と選好は、タスクに用いるべきメモリまたは中央処理装置（Central Processing Unit：ＣＰＵ）パワー、あるいは実行すべき操作またはトランザクションの数または頻度によって表すことができる。サービス機能には、サービスレベル、すなわち、通信帯域幅または品質のレベルを含むことができ、さらに、または代替的に、タスク、トラフィック、トランザクションの処理、または他の機能の実行の必要性を満たすための、プロバイダエンティティまたはエンティティのシステムによる可用性を含むことができる。「選好」および「要件」という用語は、この２つの処理が非常に類似しているため、本明細書においては、しばしば互換的に使用される。エンティティの「選好」には、エンティティが選好するサービスの両側面が含まれ得る。例を挙げると、例えば、少なくとも２００トランザクションの２４時間以内の処理などの最低要件に加えて、２４時間以内の１０００トランザクションの処理と２ＭＢのサーバ保存スペースなどがある。
【0024】
Ｍ２Ｍ／ＩｏＴサービス層（ＳＬ）は、Ｍ２Ｍ／ＩｏＴデバイスおよびアプリケーションに付加価値サービスを提供することを特に目標とする技術である。最近、Ｍ２Ｍ／ＩｏＴデバイスおよびアプリケーションを、インターネット／ウェブ、セルラー、企業、およびホームネットワークなどの展開に統合するということに伴う課題に対処するために、ｏｎｅＭ２Ｍ、欧州電気通信標準化機構（European Telecommunications Standards Institute：ＥＴＳＩ）、オープンコネクティビティファウンデーション（Open Connectivity Foundation：ＯＣＦ）などのいくつかの業界標準団体が、Ｍ２Ｍ／ＩｏＴ ＳＬを開発してきている。例えば、oneM2M TS-0001: "oneM2M Functional Architecture" v3.3.0や、ETSI TS 102 690: "Machine-to-Machine communications (M2M/IoT) Functional architecture" V2.0.13や、オープンコネクティビティファウンデーションによるOIC Core Specification, v1.1.1などを参照されたい。
【0025】
Ｍ２Ｍ／ＩｏＴ ＳＬは、Ｍ２Ｍ／ＩｏＴ指向機能のコレクションに対するアクセスを、アプリケーションおよびデバイスに提供することができる。いくつかの例として、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理が挙げられる。これらの機能は、Ｍ２Ｍ／ＩｏＴ ＳＬによってサポートされたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションが利用できる。
【0026】
プロトコルスタックの観点から、ＳＬは、通常、アプリケーションプロトコル層の上位に位置し、ＳＬがサポートするアプリケーションに付加価値サービスを提供する。したがって、ＳＬはしばしば「ミドルウェア」サービスとして分類される。サービス層をサポートするプロトコルスタックは、例えば、以下の６つの層を含んでいる。（１）アプリケーション層、（２）サービス層（ＳＬ）、（３）アプリケーションプロトコル（例えば、ハイパーテキスト転送プロトコル（Hypertext Transfer Protocol：ＨＴＴＰ）、制約アプリケーションプロトコル（Constrained Application Protocol：ＣｏＡＰ）、およびメッセージキューテレメトリトランスポート（Message Queuing Telemetry Transport：ＭＱＴＴ））、（４）伝送プロトコル（例えば、伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ）およびユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ））、（５）ネットワークプロトコル（例えば、インターネットプロトコルバージョン４（Internet Protocol Version 4：ＩＰｖ４）／インターネットプロトコルバージョン６（Internet Protocol Version 6：ＩＰｖ６））、および（６）アクセスネットワークプロトコル（例えば、イーサネット（登録商標）（Ethernet）、セルラー、Ｗｉ－Ｆｉ）。
【0027】
ｏｎｅＭ２Ｍ ＴＳ－０００１標準は、Ｍ２Ｍ／ＩｏＴ ＳＬを定義している。ＳＬの目的は、ｅＨｅａｌｔｈ、フリート管理、スマートホームなどの異なる「垂直」Ｍ２Ｍ／ＩｏＴシステムやアプリケーションが利用可能な「水平」サービスを提供することである。図１に示すように、ｏｎｅＭ２Ｍ ＳＬのアーキテクチャは、４つの参照点をサポートする共通サービスエンティティ（ＣＳＥ）を定義する。Ｍｃａ参照点はアプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、基礎となるネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、ロケーションサービス、およびデバイストリガリングなどの、基礎となるネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、「データ管理およびリポジトリ」などの、共通サービス機能（ＣＳＦ）と呼ばれる複数の論理機能を含む。図２は、ｏｎｅＭ２ＭによってサポートされるＣＳＦを示す。
【0028】
ｏｎｅＭ２Ｍアーキテクチャは、分散型アーキテクチャであり、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、中間ノード（ＭＮ）、インフラストラクチャノード（Infrastructure Node：ＩＮ）、および非ｏｎｅＭ２Ｍノード（ＮｏＤＮ）などのいくつかのタイプのノードにわたって分散した方法で、Ｍ２Ｍ／ＩｏＴサービスの展開をサポートする。ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。物理マッピングの一例は、Ｍ２Ｍ／ＩｏＴデバイス内に常駐するＡＳＮである。ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。物理マッピングの一例は、制約のあるＭ２Ｍ／ＩｏＴデバイス内に常駐するアプリケーション専用ノードである。ＭＮは、ＣＳＥを含むノードである。ＭＮは、さらに１つまたは複数のＡＥを含み得る。物理マッピングの一例は、Ｍ２Ｍ／ＩｏＴゲートウェイ内に常駐するＭＮである。ＩＮは、ＣＳＥを含むノードである。ＩＮは、さらに１つまたは複数のＡＥを含み得る。ＩＮのＣＳＥは、他のノードタイプには適用できないＣＳＥ機能を含んでもよい。物理マッピングの一例は、Ｍ２Ｍ／ＩｏＴサービスインフラストラクチャに常駐するＩＮである。非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを含まない（例えば、ＡＥもＣＳＥも含まない）ノードである。このようなノードは、例えば、管理などのインターワーキングのためにｏｎｅＭ２Ｍシステムに接続されたデバイスであり得る。
【0029】
図３は、ｏｎｅＭ２Ｍシステム内でサポートされる様々なエンティティ間の相互接続のいくつかの例示的な構成を示す。
【0030】
図４および図５は、スマートシティのサービスプロバイダによって展開されたＭ２Ｍ／ＩｏＴネットワークのユースケースを示す。この種のネットワークでは、例えば、ｏｎｅＭ２ＭにおけるＭＮ－ＣＳＥなどのＳＬゲートウェイは、通常、ローカルに、またはネットワークのエッジに配置されて、低遅延サービスを提供する。通常、配置されるＳＬゲートウェイは、サービス能力が限られている。デバイスはＳＬゲートウェイに登録して、ＳＬゲートウェイ上で利用可能な１つまたは複数のサービスの提供および利用の少なくとも一方を実行する。最初に配置された後、ＳＬゲートウェイにおけるサービス負荷は動的に変化し得る。特に、ＳＬゲートウェイに登録し、ゲートウェイによって提供されるサービスを利用するデバイスの数は、時間の経過と伴に動的に変化する可能性がある。例えば、日中に登録してサービスを利用するデバイスはより多く、夜間に登録してサービスを利用するデバイスはより少ない。別の例では、社会的イベント中には、より多くのデバイスが登録してサービスを利用する。
【0031】
図４および５に示すシナリオにおいて、少なくとも２つの問題が一般的に見られる。第１の問題は、配置されるゲートウェイは、通常、サービス能力が限られていることである。例えばＺｉｇｂｅｅプロトコルなどの下位層のプロトコルは、ローカルネットワーク内の１５００万個の「論理」デバイスをサポートできる。しかし、サービス能力が限られているＳＬゲートウェイは、１５００万個のデバイスにサービスを提供することが困難である可能性がある。現在のサービス層技術は、デバイス（または、そのオーナー）がサービス要件のレベルをサービスプロバイダのプラットフォームに対して指定できるようにする機能をサポートしていない。そのため、サービスプロバイダのプラットフォームは、ある期間内にデバイスがプラットフォームに送出できる要求の数をあらかじめ把握していない。その結果、サービスプロバイダのプラットフォームは、デバイスが必要とするサービスを満足させるために、プラットフォームまたはプラットフォームの特定のノード（ゲートウェイやサーバなど）の容量を予約するための事前措置を講じることができない。さらに、これにより、図４に示すように、サービスプロバイダのプラットフォームまたはプラットフォーム上の特定のノードが過負荷になり、デバイスが必要なレベルのサポートを受けられないという結果にもなる。
【0032】
第２の問題は、図５の例に示すように、システム上に複数のＳＬゲートウェイがある場合、新しいデバイスは、通常、同じローカルネットワークにあるゲートウェイ１などのＳＬエンティティに登録しようとすることである。しかし、ゲートウェイ１は、サービス容量が限られているため、デバイスが必要とするサポートのレベルを満たさない場合がある。例えば、デバイスは、要求を送信した後の特定の期間内に、ゲートウェイ１が提供するサービス容量を超える可能性がある応答を受信することを必要とするかもしれない。このため、例えば、デバイスが必要とするサポートのレベルを満たすことができるゲートウェイ２のような別のＳＬエンティティが存在するにも関わらず、デバイスはＳＬへの登録に失敗する。
【0033】
これらおよび他の問題に対処するために、ＳＬゲートウェイが、登録済みデバイスに必要なレベルのサポートを提供するだけでなく、新しいデバイスへの適切なレベルのサポートが存在するかどうかに基づいて、それらの新しいデバイスを登録できるかどうかを判定するように、ＳＬ登録を強化することができる。レジストラエンティティは、新しい被登録エンティティのサービス機能の要件または選好を取得して、レジストラエンティティが、既存の被登録エンティティのサービスの選好または要件を満たし続けながら、新しい被登録エンティティのサービスの選好または要件を満たす、利用可能なサービス容量を有している場合に限り、登録を受け入れることができる。
【0034】
複数のＳＬゲートウェイが存在するシナリオでは、強化された分散登録手順を使用することができ、例えば、それによって、被登録エンティティは、そのサービスの選好または要件を満たすだけでなく、そのサービス選好も満足するＳＬゲートウェイの１つに登録することができる。登録後は、被登録エンティティに関連付けられたサービス機能の選好または要件は、被登録エンティティまたは別のエンティティによって更新され得る。
【0035】
強化されたＳＬ登録手順は、サービス機能要件プロファイル（ＳＣＲＰ）から新しい被登録エンティティのサービス機能要件を取得するレジストラエンティティを含むことができ、その結果、レジストラエンティティは、既存の被登録エンティティのサービス機能要件を依然として満たしながら、被登録エンティティのサービス機能要件を満たす適切なサービス容量がある場合に限り、登録を受け入れる。ＳＣＲＰには、被登録側またはそのオーナーが必要とする個々のサービスに基づいてまとめられたサービスの選好または要件のリストが含まれている。例えば、サービス識別子（Identifier：ＩＤ）、名前を、必要なサービスごとに含めることができる。
【0036】
一般的なサービスの選好または要件には、例えば、サービス要求レート要件、サービスデータ保存スペース要件、サービス応答遅延要件、サービス可用性、および手頃な価格が含まれ得る。
【0037】
サービス要求レート要件を使用して、例えば、ＳＬ被登録エンティティが１秒当たり生成し得るか、または受信したい要求の最小数および最大数の少なくとも一方を指定することができる。さらに、要求のタイプが異なれば、サービスレート要件も異なり得る。例えば、ＳＬ被登録エンティティは、１分ごとにリソースを作成するよう要求するかもしれない。別の例では、ＳＬ被登録エンティティは、１秒ごとにリソースをリトリーブ（検索して取得）するよう要求するかもしれない。別の例では、ＳＬ被登録エンティティは、１秒ごとに他のＳＬエンティティから要求を受信するよう要求するかもしれない。
【0038】
サービスデータ保存スペース要件を使用して、例えば、ＳＬレジストラによって保存されるべき、ＳＬ被登録エンティティが必要とする最小および最大バイト数の少なくとも一方を指定することができる。
【0039】
サービス応答遅延要件を使用して、例えば、サービスの利用を要求する際に、ＳＬ被登録エンティティが許容できる最大遅延を指定することができる。例えば、この遅延は秒単位で表すことができる。さらに、要求のタイプが異なれば、サービス応答遅延要件も異なり得る。例えば、リソースのリトリーブに対する応答遅延要件を、リソースの作成に対する遅延よりも小さくすることができる。
【0040】
サービス可用性要件を使用して、例えば、ＳＬ被登録エンティティが容認可能な最大サービスダウン期間を指定することができる。例として、ＳＬ被登録エンティティがＳＬレジストラエンティティに対して行う要求の９９．５％に対してサービスが利用可能である必要がある。
【0041】
手頃な価格要件を使用して、例えば、被登録エンティティがサービスに対して支払う用意がある予算を指定することができる。例えば、ＳＬレジストラエンティティが提供するサービスにアクセスするためのコストは、このコストを超えることはできない。
【0042】
サービス固有の要件には、例えば、アクセスウィンドウ、サービス加入要件、通知要件、およびデバイストリガリング要件のような項目が含まれ得る。
【0043】
アクセスウィンドウ値を使用して、ＳＬ被登録エンティティがＳＬリソースにアクセスする時間ウィンドウ、例えば、早朝（午前６時～午前９時）、午前（午前９時～午後１２時）、午後（午後１２時～午後４時）、夕方（午後４時～午後７時）、プライムタイム（午後７時～午後１１時）、時間外（午後１１時～午前６時）などを指定することができる。
【0044】
サービス加入要件を使用して、例えば、ＳＬ被登録エンティティで特定のイベントを監視するために加入することができるエンティティの最小数および最大数の少なくとも一方を指定することができる。
【0045】
通知要件を使用して、例えば、ＳＬ被登録エンティティが１秒ごとに受信し得る通知の最小数および最大数の少なくとも一方を指定することができる。
【0046】
デバイストリガリング要件を使用して、例えば、ＳＬ被登録エンティティが１秒ごとに受信し得るトリガリングメッセージの最小数および最大数の少なくとも一方を指定することができる。
【0047】
一例では、センサデバイスは、毎分１０バイトの検知データを生成して、ゲートウェイが検知データを少なくとも１か月間保存することを要求する可能性がある。このため、このカテゴリのデバイス（例えば、カテゴリ１センサ）のサービスの選好または要件を満たすために、ゲートウェイは少なくとも５００ＫＢの利用可能なデータ保存スペースを有する必要がある。別の例では、低画質ビデオカメラが毎秒１００ＫＢのストリーミングデータを生成して、ビデオデータを最長７日間保存するようにゲートウェイに要求する可能性がある。このため、このカテゴリのデバイス（例えば、カテゴリ２カメラ）のサービス要件を満たすために、ゲートウェイは少なくとも５８ＧＢの保存スペースを有する必要がある。別の例では、高画質ビデオカメラが毎秒１ＭＢのストリーミングデータを生成して、ビデオデータを最長３日間保存するようにゲートウェイに要求する可能性がある。このため、このカテゴリのデバイス（例えば、カテゴリ３カメラ）のサービス要件を満たすために、ゲートウェイは少なくとも２５４ＧＢの保存スペースを有する必要がある。ＳＣＲＰは、異なるタイプおよびカテゴリのデバイスに対してあらかじめ定義されるか、またはデバイスがサービスプロバイダに登録または加入するときに定義されることができるが、本開示の範囲外である。
【0048】
ゲートウェイなどのレジストラエンティティは、既存のサービス被登録側によって消費されるシステムリソースの量および残存する利用可能なシステムリソースの記録を維持することができる。例えば、レジストラエンティティは、既存のサービス被登録側のために予約されているデータ保存スペースの量と、新しい被登録側のために予約されている可能性のあるデータ保存スペースの量を推定することができる。同様に、レジストラエンティティは、１分ごとに処理可能なサービス要求の最大レートと、１分ごとに受信する現在のサービス要求の量を推定することができる。
【0049】
レジストラエンティティは、様々なフィールドを使用して、既存のサービス被登録側によって消費されるシステムリソースに関する情報を保存することができる。例えば、システム容量フィールドを使用して、ＳＬに割り当てられたシステムリソースを示すことができる。これは、被登録エンティティにサービスを提供するために使用できる最大のシステムリソースである。例えば、メモリ、保存スペース、およびＣＰＵである。残存システム容量フィールドを使用して、新しい被登録エンティティに割り当てることができるシステムリソースを示すことができる。例えば、メモリ、保存スペース、およびＣＰＵである。システム容量利用フィールドを使用して、既存のＳＬ被登録エンティティにサービスを提供するために利用されるシステムリソースを示すことができる。例えば、メモリ、保存スペース、およびＣＰＵである。サービス要求レートフィールドを使用して、レジストラエンティティの現在のサービス要求レートを示すことができる。一例では、レジストラエンティティが１秒ごとに受信する要求数である。
【0050】
同様に、サービス要求レート限界フィールドを使用して、レジストラエンティティが処理できる最大サービス要求レートを示すことができる。例えば、レジストラエンティティが１秒ごとに受信できる要求の最大数である。通知発信レートフィールドを使用して、レジストラエンティティの現在の発信サービス通知レートを示すことができる。通知発信レート限界フィールドを使用して、レジストラエンティティが処理できる最大発信サービス通知レートを示すことができる。
【0051】
サービス処理時間フィールドを使用して、レジストラエンティティのサービス要求の受信と、受信に対する応答の送信の間の平均時間を示すことができる。一例では、レジストラエンティティは、平均サービス処理時間を秒単位で示すことができる。サービス処理時間限界フィールドを使用して、レジストラエンティティのサービス要求の受信と、受信に対する応答の送信の間の最小時間を示すことができる。一例では、レジストラエンティティは、最小サービス処理時間を秒単位で示すことができる。
【0052】
さらに、ＳＬ被登録側最大数フィールドを使用して、レジストラがサポートできるＳＬ被登録側の最大数を示すことができる。値は、被登録側のタイプとカテゴリに依存する。例えば、レジストラは１０個のカテゴリ１カメラデバイスにサービスを提供できるが、５個のカテゴリ２カメラデバイスにしかサービスを提供できない。ＳＬ被登録数フィールドを使用して、レジストラが現在有しているＳＬ被登録側の数を示すことができる。例えば、レジストラは、現在、５個のカテゴリ１カメラデバイスと１個のカテゴリ２カメラデバイスにサービスを提供している。
【0053】
もちろん、レジストラエンティティが維持するサービス容量情報は、これらの例示的なフィールドに限定されない。
【0054】
図６は、例えば、例示的な図４に示されるデバイスによって使用され得る例示的手順のコールフロー図である。上述のように、図４は、Ｍ２Ｍ／ＩｏＴシステムの性能を低下させるサービス過負荷の例を示すブロック図である。図４には、ＳＬレジストラエンティティ（ゲートウェイとサーバ）およびＳＬ被登録エンティティ（デバイス）が含まれている。図４において、ゲートウェイ１はＭ２Ｍ／ＩｏＴサーバ１を有する。図６において、新しいデバイス１がゲートウェイ１に登録される。
【0055】
図６のステップ１で、被登録エンティティであるデバイス１は、登録要求メッセージをレジストラエンティティであるゲートウェイ１に送信する。登録要求メッセージは、ＳＣＲＰ識別子、およびＳＣＲＰに記載されているサービスの選好または要件のいずれかのうち、少なくとも一方を含むことができる。一例では、デバイス１は、それがカテゴリ１カメラであることを示すこと、およびゲートウェイが少なくとも５８ＧＢのデータ保存スペースを有することを求めることのうち、少なくとも一方を実行することができる。別の例では、デバイス１は、それが毎秒１００ＫＢのストリーミングデータを生成し、そのデータを少なくとも７日間保存する必要があることを示すことができる。
【0056】
登録要求メッセージには、様々なサービスの選好または要件が含まれ得る。例えば、被登録エンティティが「カテゴリ１カメラ」であることを示すために、例えば、サービス機能要件プロファイル識別子を使用してサービス機能要件プロファイル識別子を示すことができる。同様に、別のサービス機能要件を使用して、ＳＣＲＰに記載されているサービスの選考または要件のいずれかを示すことができる。
【0057】
ステップ２では、ゲートウェイ１は登録要求メッセージを受信した後、登録要求を評価する。サービスの選好または要件が要求に含まれていない場合、またはゲートウェイ１がＳＣＲＰの具体的要求を把握していない場合、ステップ３に示すように、ゲートウェイ１は、デバイス１に関連付けられた要件のサービス機能要件プロファイルをＭ２Ｍ／ＩｏＴサーバ１からリトリーブする要求を示すことができる。ゲートウェイ１がサービスの選好または要件を把握している場合、ゲートウェイ１は、例えば、既存のサービス被登録側によって消費されたシステムリソースのレコードにおける様々なフィールドと合計システム容量との対比をチェックすることにより、自身の残存サービス容量をチェックし、新しいデバイスに対してサービスを提供し、かつ既存の登録済みデバイスのサービス機能要件を満たし続けることが可能かどうかを判定することができる。可能である場合には、ゲートウェイ１は、デバイス１の登録を作成し、デバイスのＳＣＲＰからの情報を使用して、デバイスのサービス要件を満たすためのシステム容量を予約する。一例では、デバイス１が毎分１０バイトの検知データを生成するカテゴリ１センサであり、ゲートウェイに最大１か月分の検知データを保存することを求めている場合、このカテゴリのデバイスにサービスを提供するために、ゲートウェイは少なくとも５００ＫＢの空き保存スペースがあるかどうかをチェックすることができる。登録の作成後は、デバイス１にサービスを提供するために保存スペースが予約されるため、ゲートウェイ１の空き保存スペースは５００ＫＢだけ減少する。別の例では、ゲートウェイ１が１秒ごとに処理できる要求の最大数は１０００であり、現在のゲートウェイ１の要求レートは１分当たり６００要求である。デバイス１が、登録要求に指定されたように毎分５００要求を生成する場合、ゲートウェイ１はデバイス１からの登録要求を拒否する。
【0058】
ステップ３では、サービスの選好または要件が要求に含まれていない場合、またはゲートウェイ１がＳＣＲＰの具体的要求を把握していない場合、ゲートウェイ１は、登録要求に示されたＳＣＲＰをリトリーブする要求をＭ２Ｍ／ＩｏＴサーバ１に送信する。
【0059】
ステップ４では、Ｍ２Ｍ／ＩｏＴサーバ１は、デバイス１に関連付けられたＳＣＲＰを含む応答をゲートウェイ１に送信する準備をする。ＳＣＲＰは、デバイス１に関連付けられたサービスプロファイルから取得することができる。
【0060】
ステップ５では、Ｍ２Ｍ／ＩｏＴサーバ１は、デバイス１に関連付けられたＳＣＲＰを含む応答メッセージをゲートウェイ１に送信する。
【0061】
ステップ６では、ゲートウェイ１は応答メッセージを受信した後、メッセージを処理し、登録応答メッセージをデバイス１に送信する準備をする。ＳＣＲＰが応答に含まれている場合、ゲートウェイ１は自身の残存サービス容量をチェックして、ステップ２で述べたように、新しいデバイスに対してサービスを提供し、かつ既存の登録済みデバイスのサービス機能要件を満たし続けることが可能かどうかを判定することができる。
【0062】
ステップ７では、ゲートウェイ１は、登録応答メッセージをデバイス１に送信する。
【0063】
ＳＬ登録手順は、新しい被登録エンティティのサービス要件および選好を満たすようにさらに強化され得る。例えば、このような手順では、ＳＬエンティティは、ＳＣＲＰまたはサービス機能選好プロファイル（ＳＣＰＰ）から新しい被登録エンティティのサービス機能の要件と選好を取得し、被登録エンティティのサービスの選好または要件を満たすだけでなく、サービス選好も満たすレジストラエンティティを選択することができる。ＳＣＲＰと同様に、ＳＣＰＰには、個々の被登録側またはそのオーナーに基づいてまとめられたサービス選好のリストが含まれている。例えば、各サービス選好ごとに、サービスＩＤ、名前、またはタイプ、ならびに効用関数およびサービス選好基準が含まれ得る。効用関数は、例えば、選好を評価するための変数としてのサービス選好基準を伴う加重関数であってもよい。サービス選好基準は、例えば、サービス要求レート選好、サービスデータ保存スペース選好、サービス応答遅延選好、サービス可用性選好、サービス価格選好、またはアクセスウィンドウ選好であり得る。
【0064】
サービス選好は、単一の基準であってもよい。例えば、被登録エンティティは、最も強力なＣＰＵを持つレジストラエンティティを選好する。別の例では、被登録エンティティは、より低価格を請求するレジストラエンティティを選好する。サービス選好は、複数基準の組み合わせであってもよい。例えば、効用関数には複数の基準が含まれ、各基準はそれに付随する加重パラメータを有する。
【0065】
強化されたＳＬ登録手順の例が図５に示され、そこには、ＳＬエンティティ（ゲートウェイとサーバ）およびＳＬ被登録エンティティ（デバイス）が含まれる。図５において、ゲートウェイ１と２がＭ２Ｍ／ＩｏＴサーバ１に登録済みであり、新しいデバイス１が、図７および図８に示すような提案された手順を使用して、ゲートウェイ１に登録する。
【0066】
図５のステップ０では、ゲートウェイ１およびゲートウェイ２は、それらのサービス容量情報をＭ２Ｍ／ＩｏＴサーバ１と交換する。一例では、ゲートウェイ１およびゲートウェイ２は、それらのサービス容量情報をＭ２Ｍ／ＩｏＴサーバ１に定期的に報告する。別の例では、Ｍ２Ｍ／ＩｏＴサーバ１は、ゲートウェイ１およびゲートウェイ２からのサービス容量情報を定期的またはオンデマンドで問い合わせることができる。
【0067】
ステップ１では、デバイス１などの被登録エンティティは、ゲートウェイ１などのレジストラエンティティに登録要求メッセージを送信する。登録要求メッセージには、ＳＣＲＰと、サービスの選好または要件のいずれかとのうち、少なくとも一方を含むことができる。
【0068】
登録要求メッセージは、ＳＣＰＰおよびサービス選好情報の少なくとも一方も含むことができる。例えば、サービス機能選好プロファイル識別子を使用して、例えば、被登録エンティティが「カテゴリ２カメラ」であるというサービス能力選好プロファイル識別子を示すことができる。サービス選好を使用して、ＳＣＰＰに記載されているサービス機能選好のいずれかを示すことができる。
【0069】
ステップ２では、ゲートウェイ１は、登録要求メッセージを受信した後、メッセージを処理し、登録要求の中にサービス機能要件およびサービス機能選好情報を含むこの登録をＭ２Ｍ／ＩｏＴサーバ１に報告する要求を送信する準備をする。例えば、サービスの選好または要件が要求に含まれていない場合、またはゲートウェイ１がＳＣＲＰの具体的要求を把握していない場合、ゲートウェイ１は、デバイス１に関連付けられたＳＣＲＰをＭ２Ｍ／ＩｏＴサーバ１からリトリーブする要求を開始する。サービスの選好または要件が要求に含まれている場合、ゲートウェイ１は自身の残存サービス容量をチェックして、既存の登録済みデバイスのサービスの選好または要件を満たすことに失敗することなく新しいデバイスにサービスを提供できるかどうかを判定することができる。サービス選好が要求に含まれている場合、ゲートウェイ１はこの情報をＭ２Ｍ／ＩｏＴサーバにも転送する。
【0070】
ステップ３では、ゲートウェイ１は、この登録を報告する要求をＭ２Ｍ／ＩｏＴサーバ１に送信する。
【0071】
様々なフィールドが、登録報告要求メッセージに含まれ得る。例えば、被登録側情報フィールドを使用して、ＳＬ被登録エンティティに関する情報、例えば、「デバイス１」のＩＰアドレスを示すことができる。登録意思フィールドを使用して、レジストラエンティティが被登録エンティティにサービスを提供する意思があるかどうかを示すことができる。例えば、レジストラエンティティがその既存の被登録エンティティのサービス機能要件を満たすことに失敗することなく新しい被登録エンティティにサービスを提供できる場合は、「受け入れる」、そうでない場合は「拒否する」という決定になり得る。サービス機能要件プロファイル識別子フィールドを使用して、被登録側に関連付けられたＳＣＲＰ識別子を示すことができる。サービス機能要件フィールドを使用して、登録要求の中のサービス機能要件を示すことができる。サービス機能選好プロファイル識別子フィールドを使用して、被登録側に関連付けられたＳＣＰＰ識別子を示すことができる。サービス機能選好フィールドを使用して、登録要求の中のサービス機能選好を示すことができる。
【0072】
ステップ４では、Ｍ２Ｍ／ＩｏＴサーバ１は、要求を処理し、ＳＬ識別子をデバイス１に割り当て、被登録エンティティＩＤ、レジストラエンティティＩＤ、およびＳＣＲＰフィールドを含む応答をゲートウェイ１に送信する準備をする。要求、またはデバイス１に関連付けられたサービス登録プロファイルのいずれかからサービス機能要件とサービス選好を取得した後、Ｍ２Ｍ／ＩｏＴサーバ１は、ステップ０で取得したサービス容量情報に基づいて、サービス機能要件とサービス選好を満たすＳＬゲートウェイを選択する。一例では、まず、Ｍ２Ｍ／ＩｏＴサーバ１は、デバイス１に関連付けられたサービス機能要件を満たすすべてのＳＬゲートウェイを選択することができ、次に、Ｍ２Ｍ／ＩｏＴサーバ１は、デバイス１に関連付けられたサービス選好に基づいて、それらのＳＬゲートウェイのうち１つのゲートウェイをＳＬレジストラとして選択する。例えば、ＳＬレジスタエンティティの選好が残存システム容量である場合、Ｍ２Ｍ／ＩｏＴサーバ１は、最大の残存システム容量を持つゲートウェイを選択する。ゲートウェイ１がＳＬレジストラとして選択されているシナリオでは、Ｍ２Ｍ／ＩｏＴサーバは、ステップ５に示すように、応答メッセージにおいてゲートウェイ１のＳＬ識別を示す。別のゲートウェイ、例えば、ゲートウェイ２がレジストラとして選択されているシナリオでは、Ｍ２Ｍ／ＩｏＴサーバ１は、被登録エンティティの登録を作成するために、デリゲート（委譲）登録要求メッセージをゲートウェイ２に送信する。デリゲート登録要求メッセージには、被登録エンティティＩＤ、被登録側情報、およびＳＣＲＰフィールドなどの情報が含まれている。例えば、Ｍ２Ｍ／ＩｏＴサーバ１には、デバイス１に関連付けられたＳＣＲＰが含まれている。
【0073】
図７の方法が実行された後、Ｍ２Ｍ／ＩｏＴサーバに保存されたＳＣＲＰおよびＳＣＰＰを用いて、登録管理を達成することができる。例えば、Ｍ２Ｍ／ＩｏＴサーバ１は以下のレコードを含み得る。被登録エンティティＩＤはデバイス１を指定し、レジストラエンティティＩＤはゲートウェイ１を指定し、ＳＣＲＰはカテゴリ１センサであり、そしてＳＣＰＰもカテゴリ１センサである。
【0074】
登録報告応答メッセージにおいて、被登録エンティティＩＤフィールドを使用して、例えば、デバイス１のような、被登録エンティティのＳＬ ＩＤを示すことができる。レジストラエンティティＩＤフィールドを使用して、被登録エンティティの登録先であるレジストラエンティティのＳＬ ＩＤを示すことができる。サービス機能要件プロファイルフィールドを使用して、被登録エンティティに関連付けられたサービス機能要件プロファイルを示すことができる。
【0075】
デリゲート登録要求メッセージにおいて、被登録エンティティＩＤフィールドを使用して、例えば、デバイス１のような被登録エンティティのＳＬ ＩＤを示すことができる。被登録側情報フィールドを使用して、デバイス１のＩＰアドレスのような被登録側情報を示すことができる。サービス機能要件プロファイルフィールドを使用して、被登録エンティティに関連付けられたサービス機能要件プロファイルを示すことができる。
【0076】
【0077】
図７のメッセージ５において、Ｍ２Ｍ／ＩｏＴサーバ１は、例えば、被登録エンティティＩＤ、レジストラエンティティＩＤ、およびＳＣＲＰフィールドを含む応答メッセージをゲートウェイ１に送信する。また、サーバ１は、デバイス１がゲートウェイ１に登録するという情報、およびデバイス１に関連付けられたＳＣＲＰとＳＣＰＰを保存する。
【0078】
ステップ６では、ゲートウェイ１は、応答メッセージを受信した後、デバイス１の登録を作成し、デバイス１に関連付けられたサービス機能要件を保存する。
【0079】
メッセージ７において、ゲートウェイ１は、Ｍ２Ｍ／ＩｏＴサーバ１によって割り当てられたＳＬ識別を含む応答をデバイス１に送信する。
【0080】
図７のコールフローは、第２のケースを示す図８に続く。図８のメッセージ８において、Ｍ２Ｍ／ＩｏＴサーバは、例えば、被登録エンティティＩＤ、被登録側情報、およびＳＣＲＰフィールドなどのフィールドを含むデリゲート登録要求メッセージをゲートウェイ２に送信する。
【0081】
ステップ９では、ゲートウェイ２は、デバイス１の登録を作成し、デバイス１に関連付けられたサービス機能要件を保存する。
【0082】
ステップ１０では、ゲートウェイ２は登録の結果を示す応答を送信する。ゲートウェイ２、が登録の作成に失敗した場合、サーバ１はステップ４のようにして別のゲートウェイを選択し、デリゲートされた登録を、選択したゲートウェイに送信する。
【0083】
ステップ１１では、サーバ１は、Ｍ２Ｍ／ＩｏＴサーバ１によって割り当てられたＳＬ識別、およびゲートウェイ２のＳＬ識別とアドレス（例えば、ＩＰアドレス）のうち少なくとも一方を含む応答をゲートウェイ１に送信する。
【0084】
ステップ１２では、ゲートウェイ１は、Ｍ２Ｍ／ＩｏＴサーバ１によって割り当てられたＳＬ識別、およびゲートウェイ２のＳＬ識別とアドレス（例えば、ＩＰアドレス）のうち少なくとも一方を含む応答をデバイス１に送信する。デバイス１は応答を受信すると、その後ゲートウェイ２と直接通信することができる。
【0085】
あるいは、サーバ１は、ステップ９をスキップして、Ｍ２Ｍ／ＩｏＴサーバ１によって割り当てられたＳＬ識別、およびゲートウェイ２のＳＬ識別とアドレス（例えば、ＩＰアドレス）のうち少なくとも一方を含む応答をゲートウェイ１に送信してもよい。その後、ゲートウェイ１は、被登録エンティティＩＤ、被登録側情報、およびＳＣＲＰフィールドを含むデリゲート登録要求メッセージをゲートウェイ２に送信することによって、デバイス１に代わってゲートウェイ２への登録を作成できる。さらにあるいは、ゲートウェイ１は、Ｍ２Ｍ／ＩｏＴサーバ１によって割り当てられたＳＬ識別、およびゲートウェイ２のＳＬ識別とアドレス（例えば、ＩＰアドレス）のうち少なくとも一方を含む応答をデバイス１に送信し、その後、デバイス１は新しい登録作成プロセスを開始して、ゲートウェイ２に自身で登録を作成してもよい。
【0086】
強化されたＳＬ登録管理手順は、ＳＣＲＰが被登録エンティティまたは別のエンティティによって更新された後に使用されてもよい。図９に示す手順は、被登録エンティティがＳＣＲＰの更新を要求するシナリオを記述している。図１０に示す手順は、被登録エンティティに関連付けられたＳＣＲＰがサーバにおいて別のエンティティによって更新されるシナリオを記述している。例えば、被登録エンティティに関連付けられたＳＬプロファイルをＳＬ登録更新手順によって更新することができる。提案された手順を説明するために、図６のＳＬエンティティ（ゲートウェイとサーバ）とアプリケーションエンティティ（デバイス）を例として使用する。図６において、ゲートウェイ１と２がＭ２Ｍ／ＩｏＴサーバ１に登録済みであり、ゲートウェイ１は、図７と図８に示す提案された手順を使用するデバイス１のレジストラエンティティである。
【0087】
【0088】
ステップ１では、被登録エンティティ、例えばデバイス１は、ＳＣＲＰを更新する要求を送信するか、または、レジストラエンティティ、例えばゲートウェイ１に、新しいサービスの選好または要件を提案する。要求メッセージには、新しいＳＣＲＰと、サービスの選好または要件のいずれかとのうち、少なくとも一方を含むことができる。
【0089】
ステップ２では、ＳＣＲＰ更新要求メッセージを受信した後、ゲートウェイ１はデバイス１に関連付けられたＳＣＲＰを更新する。ゲートウェイ１は自身の残存サービス容量をチェックして、既存の被登録エンティティのサービスの選好または要件を満たすことに失敗することなくデバイス１の更新されたサービス要求を満たすことが可能かどうかを判定することができる。可能である場合には、ゲートウェイ１はデバイス１のために予約されているサービス容量を更新し、サーバ１に保存されているＳＣＲＰを更新する要求を送信する。そうでない場合には、ゲートウェイ１は、新しい要件を満たせないことを報告するためにサーバ１に要求を送信し、ＳＣＲＰを更新して新しいサービスの選好または要件を満足できる新しいゲートウェイを選択することをサーバ１に要求する。
【0090】
ステップ３では、ゲートウェイ１は、更新されたＳＣＲＰを報告する要求をＭ２Ｍ／ＩｏＴサーバ１に送信する。
【0091】
ステップ４では、Ｍ２Ｍ／ＩｏＴサーバ１はデバイスに関連付けられたＳＣＲＰを更新する。ゲートウェイ１が新しいゲートウェイの選択を要求した場合、Ｍ２Ｍ／ＩｏＴサーバ１は、図７のステップ４に関連して説明したものと同じ方法を用いて、新しいサービス機能要件を満たす新しいレジストラエンティティを選択する。
【0092】
ステップ５では、Ｍ２Ｍ／ＩｏＴサーバ１は、例えばゲートウェイ２などの新しいレジストラの情報を含む応答メッセージをゲートウェイ１に送信する。オプションとして、ゲートウェイ２が新しいレジストラとして選択されていることを通知するために、サーバ１は、要求メッセージをゲートウェイ２に送信することができる。
【0093】
ステップ６では、応答メッセージを受信した後、ゲートウェイ１はゲートウェイ２に要求を送信することによって、デバイス１に関連する登録を転送する。登録を転送する方法の詳細な手順は本開示の範囲外である。
【0094】
ステップ７では、ゲートウェイ２はデバイス１の登録を作成し、デバイス１に関連付けられたサービス機能要件を保存する。
【0095】
ステップ８では、ゲートウェイ２は登録の結果を示す応答を送信する。
【0096】
ステップ９では、登録のゲートウェイ２への転送が成功した場合、ゲートウェイ１は登録を削除し、デバイス１に関連付けられた予約されたリソースを解放することができる。ゲートウェイ２が登録の作成に失敗した場合、ゲートウェイ１は、ステップ３のように、サーバ１に別のゲートウェイを選択するよう要求する。
【0097】
ステップ１０では、ゲートウェイ１はデバイス１に応答を送信する。応答には、新しいレジストラエンティティ、例えば、ゲートウェイ２がサーバによって選択された場合、そのＳＬ識別およびアドレス（例えば、ＩＰアドレス）の少なくとも一方も含まれる。こうなった場合、デバイス１はその後ゲートウェイ２と直接通信することができる。
【0098】
図１０は、ＳＣＲＰがサーバにおいて更新される場合のサービス層登録管理のための例示的な手順を示す。図１０の例では、被登録エンティティに関連付けられたＳＣＲＰがサーバにおいて別のエンティティによって更新される。例えば、被登録エンティティに関連付けられたＳＬプロファイルをＳＬ登録更新手順によって更新することができる。
【0099】
ステップ１では、ＳＣＲＰが更新された後、Ｍ２Ｍ／ＩｏＴサーバ１は、ＳＣＲＰに関連付けられた、例えばデバイス１のような、ＳＬエンティティをすべて検索して、デバイス１のレジストラエンティティ、例えば、ゲートウェイ１を見つける。その後、サーバ１はゲートウェイ１のサービス容量情報をチェックして、ゲートウェイ１が、ゲートウェイ１の既存の被登録エンティティのサービス機能要件を満たすことに失敗することなくデバイス１の更新されたサービス要求を満たすことが可能かどうかを判定する。可能である場合には、サーバ１は、ゲートウェイ１において保存されたＳＣＲＰを更新する要求をゲートウェイ１に送信する。そうでない場合には、図７と図８に示すように、サーバ１は、ステップ４と同様に、サービス容量情報に基づいてサービス機能要件とサービス選好を満たすレジストラエンティティ、例えば、ゲートウェイ２を選択する。その後、サーバ１は、ゲートウェイ１が新しいサービスの選好または要件を満たすことができないことを示すために、ゲートウェイ１に要求を送信する。サーバ１はゲートウェイ１にＳＣＲＰの更新を要求し、新しいサービスの選好または要件を満たし得る登録をゲートウェイ２に転送する。
【0100】
ステップ２では、ゲートウェイ１は、デバイス１に関連付けられたＳＣＲＰを更新する。ゲートウェイ１がデバイス１に関連付けられた登録をゲートウェイ２に転送するように指示された場合、ステップ３からステップ７が実行される。
【0101】
ステップ３では、応答メッセージを受信した後、ゲートウェイ１は、デバイス１に関連付けられた登録を転送する要求をゲートウェイ２に送信する。登録を転送する方法の詳細な手順は本開示の範囲外である。
【0102】
ステップ４では、ゲートウェイ２はデバイス１の登録を作成し、デバイス１に関連付けられたサービス機能要件を保存する。
【0103】
ステップ５では、ゲートウェイ２は、登録の結果を示す応答を送信する。
【0104】
ステップ６では、登録のゲートウェイ２への転送が成功した場合、ゲートウェイ１は登録を削除し、デバイス１に関連付けられた予約されたリソースを解放することができる。ゲートウェイ２が登録の作成に失敗した場合、ゲートウェイ１は、ステップ１０の応答メッセージにおいて、サーバ１に別のゲートウェイを選択するよう要求する。その後、ゲートウェイ１はデバイス１に通知を送信する。通知には、新しいレジストラエンティティ、例えば、ゲートウェイ２のＳＬ識別とアドレス（例えば、ＩＰアドレス）のうち少なくとも一方が含まれる。
【0105】
ステップ７では、デバイス１は、登録の転送を確認する応答を送信する、そして、その後ゲートウェイ２と直接通信することができる。
【0106】
ステップ８では、ゲートウェイ１は、ＳＣＲＰの更新および登録の転送についての要求を確認する応答を送信する。
【0107】
ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる機能を定義する。ｏｎｅＭ２Ｍサービス層は、機能サービス機能（Capability Service Function：ＣＳＦ）のセットで構成される機能サービスエンティティ（Capability Services Entity：ＣＳＥ）としてインスタンス化される。例えば、本明細書で提案する様々な方法は、図１１に示すような、強化された登録ＣＳＦの一部と、アプリケーションおよびサービス層管理ＣＳＦの一部とのうち、少なくとも一方として実装することができる。ＣＳＥは、ＭｃｃおよびＭｃｃ’参照点を介して通信することにより、登録を管理することができる。アプリケーションエンティティ（ＡＥ）は、Ｍｃａ参照点を介して通信することにより、登録を管理することができる。
【0108】
本明細書では、ＳＬ被登録エンティティの監視および管理をサポートするために、新しいサービス容量、リソース、および属性を提案する。例えば、ｏｎｅＭ２Ｍリソース指向アーキテクチャにおいて、そのような構造を使用することができる。
【0109】
新しい共通属性、例えば、serviceRequirementおよびservicePreferenceを、<AE>、<CSEBase>、<remoteCSE>、および<m2mServiceSubscriptionProfile>で使用するために提案する。
【0110】
serviceRequirement属性には、被登録側またはそのオーナーが必要とする個々のサービスに基づいてまとめられたサービスの選好または要件のリストを含めることができる。例えば、必要なサービスごとに、以下の一般および特定サービス要件の情報を含めることができる。
【0111】
一般サービス要件には、例えば、サービス要求レート要件、サービスデータ保存スペース要件、サービス応答遅延要件、サービス可用性、または手頃な価格要件が含まれ得る。
【0112】
サービス要求レート要件は、例えば、ＳＬ被登録エンティティが１秒当たり生成し得るか、または受信したい要求の最小数および最大数の少なくとも一方を指定することができる。さらに、要求のタイプが異なれば、サービスレート要件も異なり得る。例えば、ＳＬ被登録エンティティは、１分ごとにリソースを作成するよう要求するかもしれない。別の例では、ＳＬ被登録エンティティは、１秒ごとにリソースをリトリーブするよう要求するかもしれない。別の例では、ＳＬ被登録エンティティは、１秒ごとに他のＳＬエンティティから要求を受信するよう要求するかもしれない。
【0113】
サービスデータ保存スペース要件は、例えば、ＳＬレジストラによって保存されるべき、ＳＬ被登録エンティティが必要とする最小および最大バイト数の少なくとも一方を指定することができる。このフィールドはオプションであってもよい。
【0114】
サービス応答遅延要件は、例えば、サービスの利用を要求する際に、ＳＬ被登録エンティティが許容できる最大遅延を指定することができる。例えば、この遅延は秒単位で表すことができる。さらに、要求のタイプが異なれば、サービス応答遅延要件も異なり得る。例えば、リソースのリトリーブに対する応答遅延要件を、リソースの作成に対する遅延よりも小さくすることができる。
【0115】
サービス可用性要件は、例えば、ＳＬ被登録エンティティが容認可能な最大サービスダウン期間を指定することができる。例として、ＳＬ被登録エンティティがＳＬレジストラエンティティに対して行う要求の９９．５％に対してサービスが利用可能である必要がある。
【0116】
手頃な価格要件。一例では、この値は、被登録エンティティがサービスに対して支払う用意がある予算を指定する。例えば、ＳＬレジストラエンティティが提供するサービスにアクセスするためのコストは、このコストを超えることはできない。
【0117】
特定サービス要件には、例えば、アクセスウィンドウ、サービス加入要件、通知要件、またはデバイストリガリング要件が含まれ得る。
【0118】
アクセスウィンドウ要件は、例えば、ＳＬ被登録エンティティがＳＬリソースにアクセスする時間ウィンドウ（例えば、早朝（午前６時～午前９時）、午前（午前９時～午後１２時）、午後（午後１２時～午後４時）、夕方（午後４時～午後７時）、プライムタイム（午後７時～午後１１時）、時間外（午後１１時～午前６時））を指定することができる。
【0119】
サービス加入要件は、例えば、ＳＬ被登録エンティティで特定のイベントを監視するために加入することができるエンティティの最小数および最大数の少なくとも一方を指定することができる。
【0120】
通知要件は、例えば、ＳＬ被登録エンティティが１秒ごとに受信し得る通知の最小数および最大数の少なくとも一方を指定することができる。
【0121】
デバイストリガリング要件は、例えば、ＳＬ被登録エンティティが１秒ごとに受信し得るトリガリングメッセージの最小数および最大数の少なくとも一方を指定することができる。
【0122】
servicePreference属性には、被登録側またはそのオーナーが必要とする個々のサービスに基づいてまとめられたサービス機能選好のリストを含めることができる。例えば、必要なサービスごとに、servicePreference属性には、サービス要求レート選好、サービスデータ保存スペース選好、サービス応答遅延選好、サービス可用性選好、サービス価格選好、およびアクセスウィンドウ選好などのサービス選好基準と共に、サービスＩＤ、名前、またはタイプが含まれ得る。
【0123】
新しいリソース、例えば、<serviceCapacity>は、<CSEBase>および<remoteCSE>が、ＣＳＥに関連付けられたサービス容量情報を保存するために使用することができる。<serviceCapacity>リソースはいくつかの属性を持つことができる。systemCapacity属性を使用して、ＳＬに割り当てられたシステムリソースを示すことができる。これは、メモリ、保存スペース、およびＣＰＵなどの、ＣＳＥにサービスを提供するために使用できる最大のシステムリソースである。residualCapacity属性を使用して、メモリ、ストレージ、およびＣＰＵなどの既存の登録済みデバイスによって占められていない新しいデバイスに割り当てることができるシステムリソースを示すことができる。
【0124】
systemUtilization属性を使用して、メモリ、保存スペース、およびＣＰＵなどの既存の登録済みデバイスにサービスを提供するために利用されるシステムリソースを示すことができる。
【0125】
serviceRequestRate属性を使用して、ＣＳＥの現在のサービス要求レート、例えば、それが１秒ごとに受信する要求数を示すことができる。
【0126】
さらに、serviceRequestRateLimit属性を使用して、ＣＳＥが１秒ごとに受信できる最大要求数などの、ＣＳＥが処理できる最大サービス要求レートを示すことができる。outgoingRateoflSfotifications属性を使用して、ＣＳＥの現在の発信サービス通知レートを示すことができる。outgoingRateofNotificationsLimit属性を使用して、ＣＳＥが処理できる最大発信サービス通知レートを示すことができる。serviceProcessingTime属性を使用して、ＣＳＥがサービス要求を受信してから要求に対する応答を送信するまでの平均時間を示すことができる。一例では、ＣＳＥは、平均サービス処理時間を秒単位で示すことができる。
【0127】
さらに、serviceProcessingTimeLimit属性を使用して、ＣＳＥがサービス要求を受信してからその要求に対する応答を送信するまでの最小時間を示すことができる。一例では、ＣＳＥは、最小サービス処理時間を秒単位で示すことができる。maximumNumberofSLRegistree属性を使用して、ＣＳＥがサポートできるデバイスの最大数を示すことができる。値は、被登録側のタイプとカテゴリに依存する。例えば、ＣＳＥは１０個のカテゴリ２カメラデバイスにサービスを提供できるが、５個のカテゴリ３カメラデバイスにしかサービスを提供できない。Number of SLRegistree属性を使用して、ＣＳＥに登録されているデバイスの数を示すことができる。例えば、ＣＳＥは、現在、５個のカテゴリ２カメラデバイスと１個のカテゴリ３カメラデバイスにサービスを提供している。
【0128】
【0129】
図１２を参照すると、ステップ１では、被登録ＡＥは登録要求メッセージをＭＮ－ＣＳＥ１に送信する。登録要求メッセージには、９に記載されているように、Contentパラメータの属性としてサービスの要件と選好を含むことができる。登録要求メッセージには、サービス選好を含むことができる。
【0130】
ステップ２では、登録要求メッセージを受信した後、ＭＮ－ＣＳＥ１はメッセージを処理し、この登録を報告する要求をＩＮ－ＣＳＥに送信する準備をする。例えば、サービス要件が要求に含まれていない場合、ＭＮ－ＣＳＥ１は、デバイスに関連付けられているサービス要件プロファイルを<m2mServiceSubscriptionProfile>からリトリーブする要求をＩＮ－ＣＳＥに送信する。サービス要件が要求に含まれている場合、ＭＮ－ＣＳＥ１はその残存サービス容量をチェックして、既存の被登録エンティティのサービス要件を満たすことに失敗することなく被登録ＡＥにサービスを提供できるかどうかを判定することができる。サービス選好が要求に含まれている場合、ＭＮ－ＣＳＥ１は、デバイスに関連付けられたサービス選好属性を含む要求をＩＮ－ＣＳＥに送信することができる。
【0131】
ステップ３では、ＭＮ－ＣＳＥ１は、ステップ２で準備されたこの登録を報告する要求をＭ２Ｍ／ＩｏＴサーバ１に送信する。
【0132】
ステップ４では、ＩＮ－ＣＳＥは要求を処理し、Ｓ－ＡＥ－ＩＤを被登録ＡＥに割り当て、レジストラＣＳＥのＣＳＥ－ＩＤをContentパラメータの属性として含む応答をＭＮ－ＣＳＥ１に送信する準備をする。サービス要件とサービス選好を、要求、または被登録ＡＥに関連付けられた<serviceSubscribedNode>から取得した後、ＩＮ－ＣＳＥは、ＭＮ－ＣＳＥに関連付けられた<serviceCapacity>に基づいて、サービス要件とサービス選好を満たすＭＮ－ＣＳＥを選択する。ＩＮ－ＣＳＥがレジストラＣＳＥを選択するための詳細なアルゴリズムは本開示の範囲外である。一例では、ＩＮ－ＣＳＥは、まず、被登録ＡＥに関連付けられたサービスの選好または要件を満たすすべてのＭＮ－ＣＳＥを選択することができ、次に、ＩＮ－ＣＳＥは、被登録ＡＥに関連付けられたサービスの選好に基づいて、１つのＣＳＥをレジストラＣＳＥとして選択する。例えば、被登録ＡＥの選好がデータ処理能力である場合、ＩＮ－ＣＳＥは、最大データ処理能力を有するゲートウェイを選択する。ＭＮ－ＣＳＥ１がレジストラＣＳＥとして選択されるシナリオでは、ＩＮ－ＣＳＥは、ステップ５のように、応答メッセージにおいて、ＭＮ－ＣＳＥ１のＣＳＥ－ＩＤを示す。別のＣＳＥ、例えば、ＭＮ－ＣＳＥ２がレジストラＣＳＥとして選択されるシナリオでは、ＩＮ－ＣＳＥは、ステップ８のように、被登録ＡＥの登録を作成するためのデリゲート登録要求メッセージをＭＮ－ＣＳＥ２に送信する。デリゲート登録要求メッセージには、被登録エンティティＩＤ、被登録側情報、およびＳＣＲＰフィールドなどの情報が、Contentパラメータの属性として含まれる。例えば、ＩＮ－ＣＳＥには、被登録ＡＥに関連付けられたサービス登録プロファイルから取得されたＡＥ－ＩＤ、ポイントオブアクセス（ＰｏＡ）、およびサービス要件プロファイルが含まれる。
【0133】
ＩＮ－ＣＳＥとしてＭＮ－ＣＳＥ１が選択された場合、ステップ５からステップ７が実行される。
【0134】
ステップ５では、ＩＮ－ＣＳＥは、被登録エンティティＩＤ、レジストラエンティティＩＤ、およびＳＣＲＰフィールドを含む応答メッセージをＭＮ－ＣＳＥ１に送信する。
【0135】
ステップ６では、ＭＮ－ＣＳＥ１は応答メッセージを受信した後、ＡＥ１の登録を作成し、ＡＥ１に関連付けられたサービス要件を保存する。具体的には、ＭＮ－ＣＳＥ１は、応答メッセージ中のContentパラメータで提供されるＡＥ－ＩＤとサービス要件を使用して、<AE>リソースを作成する。
【0136】
ステップ７では、ＭＮ－ＣＳＥ１は、ＩＮ－ＣＳＥによって割り当てられたＳ－ＡＥ－ＩＤを含む応答をＡＥ１に送信する。
【0137】
ＩＮ－ＣＳＥとしてＭＮ－ＣＳＥ２が選択された場合、ステップ８からステップ１２が実行される。
【0138】
図１２の手順は、図１３に続く。図１３を参照すると、ステップ８では、ＩＮ－ＣＳＥは、被登録エンティティＩＤ、被登録側情報、およびＳＣＲＰフィールドを含むデリゲート登録要求メッセージを（通知（NOTIFY）要求を通じて）ＭＮ－ＣＳＥ２に送信する。具体的には、要求には、ＡＥに関連付けられたＡＥ－ＩＤ、ＰｏＡ、およびサービス要件が、Contentパラメータの属性として含まれる。
【0139】
ステップ９では、ＭＮ－ＣＳＥ２はＡＥ１の登録を作成し、ＡＥ１に関連付けられたサービス要件を保存する。具体的には、ＭＮ－ＣＳＥ２は、デリゲート登録要求メッセージで提供されているＡＥ－ＩＤ、ＰｏＡおよびサービス要件を使用して、<AE>リソースを作成する。
【0140】
ステップ１０では、ＭＮ－ＣＳＥ２は登録作成の結果を示す応答を送信する。ＭＮ－ＣＳＥ２が登録の作成に失敗した場合、ＩＮ－ＣＳＥは、ステップ４で説明したように、別のゲートウェイを選択し、デリゲートされた登録を選択されたＣＳＥに送信する。
【0141】
ステップ１１では、ＩＮ－ＣＳＥは、ＩＮ－ＣＳＥによって割り当てられたＳ－ＡＥ－ＩＤと、ＣＳＥ－ＩＤおよびレジストラエンティティ、例えば、ＭＮ－ＣＳＥ２のアドレス（例えば、ＩＰアドレス）の少なくとも一方とをContentパラメータの属性として含む応答を、ＭＮ－ＣＳＥ１に送信する。
【0142】
ステップ１２では、ＭＮ－ＣＳＥ１は、ＩＮ－ＣＳＥによって割り当てられたＳ－ＡＥ－ＩＤと、ＣＳＥ－ＩＤおよびレジストラエンティティ、例えば、ＭＮ－ＣＳＥ２のアドレス（例えば、ＩＰアドレス）の少なくとも一方とをContentパラメータの属性として含む応答を、ＡＥ１に送信する。ＡＥ１は応答を受信すると、その後ＭＮ－ＣＳＥ２と直接通信することができる。
【0143】
図１４は、ＡＥまたはＣＳＥのサービス要件プロファイルを構成したり表示したりするために、ｏｎｅＭ２Ｍ ＩＮ－ＣＳＥなどのＭ２Ｍ／ＩｏＴサーバ上で使用するための、例示的なユーザインターフェースを示す。図１５は、サービスプロバイダに登録されたＣＳＥのサービス容量情報を表示するためのユーザインターフェースの例を示す。
【0144】
図１６は、１つまたは複数の開示される実施形態が実施され得るマシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）の例示的な通信システム１０の図である。一般に、Ｍ２Ｍ技術はＩｏＴ／ＷｏＴのためのビルディングブロックを提供し、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、およびＭ２ＭサービスプラットフォームはいずれもＩｏＴ／ＷｏＴおよびＩｏＴ／ＷｏＴサービス層の構成要素またはノードであり得る。図１、図３～図１０、図１２、図１３、および図１６～図１９のいずれかに示されたクライアント、プロキシ、またはサーバデバイスのいずれも、図１、図３～図１０、図１２、図１３、および図１６～図１７に示されたもののような通信システムのノードを備えることができる。
【0145】
サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、通常、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、制約アプリケーションプロトコル（ＣｏＡＰ）、またはメッセージキューテレメトリトランスポート（ＭＱＴＴ）などのアプリケーションプロトコル層の上位に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層は、制御層やトランスポート／アクセス層などのより下位のリソース層におけるコアネットワークへのインターフェースも提供する。サービス層は、サービス定義、サービスの実行時有効化、ポリシー管理、アクセス制御、およびサービスクラスタリングなどを含む複数のカテゴリの（サービス）能力または機能をサポートする。最近、Ｍ２Ｍタイプのデバイスおよびアプリケーションを、インターネット／ウェブ、セルラー、企業、およびホームネットワークなどの展開に統合するということに伴う課題に対処するために、ｏｎｅＭ２Ｍなどのいくつかの業界標準化団体はＭ２Ｍサービス層を開発してきている。Ｍ２Ｍサービス層は、アプリケーションおよび様々なデバイスの少なくとも一方に、ＣＳＥまたはサービス機能層（Service Capability Layer：ＳＣＬ）と呼ばれることもあるサービス層によってサポートされる上記の能力または機能の集合またはセットへのアクセスを提供することができる。いくつかの例として、様々なアプリケーションが共通に使用する可能性のあるセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理が挙げられるが、これらに限定されない。これらの能力または機能は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、このような様々なアプリケーションが利用できる。ＣＳＥまたはＳＣＬは、ハードウェアおよびソフトウェアの少なくとも一方によって実装することが可能であり、様々なアプリケーションおよびデバイスの少なくとも一方に公開された（サービス）能力または機能（すなわち、そのような機能エンティティ間の機能インターフェース）を提供して、アプリケーションやデバイスがそのような能力または機能を利用できるようにする機能エンティティである。
【0146】
図１６に示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（Ethernet）、ファイバ、サービス総合デジタル網（Integrated Services Digital Network：ＩＳＤＮ）、電力線搬送通信（Power Line Communication：ＰＬＣ）など）、または無線ネットワーク（例えば、無線ローカルエリアネットワーク（Wireless Local Area Network：ＷＬＡＮ）、セルラーなど）、または異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数ユーザに提供する複数のアクセスネットワークから構成され得る。例えば、通信ネットワーク１２は、符号分割多元接続（Code Division Multiple Access：ＣＤＭＡ）、時分割多元接続（Time Division Multiple Access：ＴＤＭＡ）、周波数分割多元接続（Frequency Division Multiple Access：ＦＤＭＡ）、直交周波数分割多元接続（Orthogonal Frequency Division Multiple Access：ＯＦＤＭＡ）、シングルキャリア周波数分割多元接続（Single Carrier Frequency Division Multiple Access：ＳＣ－ＦＤＭＡ）などの１つ以上のチャネルアクセス方法を採用することができる。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを含むことができる。
【0147】
図１６に示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインとインフラストラクチャドメインは両方とも、ネットワークの様々な異なるノード（例えば、サーバ、ゲートウェイ、デバイスなど）を含むことができる。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４およびデバイス１８を含むことができる。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８が、必要に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることは理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８の各々は、通信回路を使用して通信ネットワーク１２または直接無線リンクを介して信号を送受信するように構成される。Ｍ２Ｍゲートウェイ１４は、（例えば、セルラーおよび非セルラーの）無線Ｍ２Ｍデバイスおよび固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が通信ネットワーク１２などの事業者ネットワークまたは直接無線リンクを介して通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、Ｍ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８にデータを送信することができる。Ｍ２Ｍデバイス１８は、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信することもできる。さらに、以下に説明するように、データおよび信号は、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、Ｍ２Ｍアプリケーション２０から受信され得る。Ｍ２Ｍデバイス１８とゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、無線パーソナルエリアネットワーク（Wireless Personal Area Network：ＷＰＡＮ）（例えば、Ｚｉｇｂｅｅ、低電力ワイヤレスパーソナルエリアネットワーク上のＩＰｖ６（IPv6 over Low-power Power Wireless Personal Area Networks：６ＬｏＷＰＡＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、ワイヤラインなどを含む様々なネットワークを介して、通信することができる。例示的なＭ２Ｍデバイスには、タブレット、スマートフォン、医療機器、温度および気象モニタ、コネクテッドカー、スマートメーター、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、ライト、サーモスタット、電気製品、ガレージドア、その他のアクチュエータベースのデバイス、セキュリティデバイス、およびスマートコンセントが含まれるが、これらに限定されない。
【0148】
図１７を参照すると、フィールドドメイン内に図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍデバイス１８ならびに通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、必要に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２と通信することができることは理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを備えることができるネットワークの１つまたは複数のノードによって実装することができる。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用されるサービス機能を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、セルラーコアネットワーク、クラウドなどにおけるウェブサーバとして、様々な方法で実装されてもよい。
【0149】
図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメインにはＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および基礎となる通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２’はフィールドドメイン内のＭ２Ｍゲートウェイ１４およびＭ２Ｍデバイス１８にもサービスを提供する。Ｍ２Ｍサービス層２２’は任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信することができることは理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用することができる。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／ストレージファームなど）などを備えることができるネットワークの１つまたは複数のノードによって実装され得る。
【0150】
図１７も参照すると、Ｍ２Ｍサービス層２２および２２’は、様々なアプリケーションおよび垂直アプリケーションが活用できるサービス配信機能のコアセットを提供する。これらのサービス機能は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイスの発見などの機能を実行することを可能にする。基本的に、これらのサービス機能は、アプリケーションをこれらの機能を実装する負担から解放することによって、アプリケーション開発を簡素化し、商品化までのコストと時間を削減する。サービス層２２および２２’は、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスに関連して、ネットワーク１２などの様々なネットワークを通じて通信することも可能にする。
【0151】
Ｍ２Ｍアプリケーション２０および２０’は、例えば、運輸、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよびサーベイランスなどであるがこれらに限らない様々な産業におけるアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、サーバおよびその他のノードにわたって実行されるＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合などの機能をサポートし、これらの機能をサービスとしてＭ２Ｍアプリケーション２０および２０’に提供する。
【0152】
一般に、図１７に示すサービス層２２および２２’などのサービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および基礎となるネットワーキングインターフェースのセットを介して付加価値サービス機能をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭとｏｎｅＭ２Ｍの両アーキテクチャがサービス層を定義する。ＥＴＳＩ Ｍ２Ｍ’のサービス層は、サービス機能層（ＳＣＬ）と呼ばれる。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの様々な異なるノードに実装できる。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（この場合、インスタンスはデバイスＳＣＬ（Device SCL：ＤＳＣＬ）と呼ばれる）、ゲートウェイ（この場合、インスタンスはゲートウェイＳＣＬ（Gateway SCL：ＧＳＣＬ）と呼ばれる）、およびネットワークノード（この場合、インスタンスはネットワークＳＣＬ（Network SCL：ＮＳＣＬ）と呼ばれる）のうち少なくとも１つの範囲内に実装できる。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）のセット（すなわち、サービス機能）をサポートする。１つまたは複数の特定のタイプのＣＳＦのセットをインスタンス化したものは、様々なタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション固有ノード）でホストされる共通サービスエンティティ（ＣＳＥ）と呼ばれる。第三世代パートナーシッププロジェクト（３ＧＰＰ）は、マシンタイプ通信（Machine-Type Communications：ＭＴＣ）のアーキテクチャも定義している。そのアーキテクチャにおいては、サービス層とそれが提供するサービス機能は、サービス機能サーバ（Service Capability Server：ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬの中、３ＧＰＰ ＭＴＣアーキテクチャのサービス機能サーバ（ＳＣＳ）の中、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥの中、およびネットワークの他のノードの中のうちのどれにおいて具体化されているかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、およびその他のコンピューティングデバイスまたはノードを含む、ネットワーク内の１つまたは複数のスタンドアロンノードで実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令など）として、または１つ以上の既存のノードの一部として実装できる。一例として、サービス層またはその構成要素のインスタンスは、以下に述べる図１８または図１９に示す一般的なアーキテクチャを持つネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）で実行されるソフトウェアの形で実装できる。
【0153】
さらに、本明細書で説明する方法および機能は、サービスにアクセスするためにサービス指向アーキテクチャ（Service-Oriented Architecture：ＳＯＡ）およびリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）の少なくとも一方を使用するＭ２Ｍネットワークの一部として実装することができる。
【0154】
図１８は、例えば、図１、図３～図１０、図１２、図１３、および図１６～図１９に示すクライアント、サーバ、またはプロキシのうちの１つなどの、ネットワークのノードの例示的なハードウェア／ソフトウェアアーキテクチャのブロック図である。このノードは、図１、図３～図１０、図１２、図１３、および図１６～図１７に示すようなＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、またはその他のノードとして動作することができる。図１８に示すように、ノード３０は、プロセッサ３２、取り外し不可能メモリ４４、取り外し可能メモリ４６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ、タッチパッド、インジケータ４２、電源４８、全地球測位システム（Global Positioning System：ＧＰＳ）チップセット５０、およびその他の周辺機器５２を含み得る。ノード３０は、トランシーバ３４および送信／受信要素３６などの通信回路も含み得る。ノード３０は、実施形態との整合性を保ちながら、前述の要素の任意のサブコンビネーションを含み得ることは理解されるであろう。このノードは、例えば、図６～図１０および図１２～図１３の参照によるかまたは特許請求の範囲で説明される方法に関して、サービス機能の要件および選好を通信および管理するための処理を実装するノードであり得る。
【0155】
プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、その他のタイプの集積回路（Integrated Circuit：ＩＣ）、状態マシンなどであり得る。一般に、プロセッサ３２は、ノードの様々な必要機能を実行するために、ノード装置のメモリ（例えば、メモリ４４やメモリ４６の）に格納されたコンピュータ実行可能命令を実行することができる。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、およびノード３０が無線または有線環境で動作することを可能にする他の任意の機能のうち少なくとも１つを実行することができる。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）、無線アクセス層（Radio Access layer：ＲＡＮ）プログラム、および他の通信プログラムのうち少なくとも１つを実行することができる。プロセッサ３２は、例えばアクセス層およびアプリケーション層の少なくとも一方における、認証や、セキュリティ鍵合意や、暗号操作などのセキュリティ操作を実行することもできる。
【0156】
図１８に示すように、プロセッサ３２は、その通信回路（例えば、トランシーバ３４および送信／受信要素３６）に結合される。プロセッサ３２は、ノード３０を、それが接続されているネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通じて、通信回路を制御することができる。特に、プロセッサ３２は、例えば、図６～図１０および図１２～図１３に関連して、または特許請求の範囲において、本明細書に記載されたサービス機能の要件および選好を通信および管理する方法を実行するために通信回路を制御することができる。図１８は、プロセッサ３２とトランシーバ３４を別個の構成要素として示しているが、プロセッサ３２とトランシーバ３４は、共に電子パッケージまたはチップに統合されてもよいことは理解されるであろう。
【0157】
送信／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む他のノードに信号を送信、またはそこから受信するように構成され得る。例えば、一実施形態では、送信／受信要素３６は、無線周波数（Radio Frequency：ＲＦ）信号を送信や受信するように構成されたアンテナであり得る。送信／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラーなどの様々なネットワークおよびエアインターフェースをサポートすることができる。一実施形態では、送信／受信要素３６は、例えば、赤外線（Infrared：ＩＲ）、紫外線（Ultraviolet：ＵＶ）、または可視光信号を送信や受信するように構成されたエミッタ／検出器であり得る。さらに別の実施形態では、送信／受信要素３６は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送信／受信要素３６が、無線または有線信号の任意の組み合わせを送信や受信するように構成され得ることは理解されるであろう。
【0158】
さらに、図１８は、送信／受信要素３６を単一の要素として示しているが、ノード３０は、任意の数の送信／受信要素３６を含むことができる。より具体的には、ノード３０は、多入力多出力（Multiple Input Multiple Output：ＭＩＭＯ）技術を採用することができる。このように、一実施形態では、ノード３０は、無線信号を送信および受信するための２つ以上の送信／受信要素３６（例えば、複数のアンテナ）を含み得る。
【0159】
トランシーバ３４は、送信／受信要素３６によって送信すべき信号を変調し、送信／受信要素３６によって受信された信号を復調するように構成され得る。上述のように、ノード３０は、マルチモード機能を有する。したがって、トランシーバ３４は、ノード３０が、例えば、ユニバーサル地上無線アクセス（Universal Terrestrial Radio Access：ＵＴＲＡ）やＩＥＥＥ８０２．１１のなどの複数の無線アクセス技術（Radio Access Technology：ＲＡＴ）によって通信することを可能にするための、複数のトランシーバを含み得る。
【0160】
プロセッサ３２は、取り外し不可能メモリ４４や取り外し可能メモリ４６などの任意のタイプの適切なメモリからの情報にアクセスし、そこにデータを保存することができる。例えば、上記のように、プロセッサ３２は、そのメモリにセッションコンテキストを格納することができる。取り外し不可能メモリ４４には、ランダムアクセスメモリ（Random-Access Memory：ＲＡＭ）、読み出し専用メモリ（Read-Only Memory：ＲＯＭ）、ハードディスク、または任意の他のタイプの記憶装置が含まれ得る。取り外し可能メモリ４６には、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどが含まれ得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータなどのノード３０上に物理的に位置していないメモリからの情報にアクセスし、そこにデータを保存することができる。プロセッサ３２は、Ｍ２Ｍサービス層セッションの移行または共有のステータスを反映するか、またはユーザからの入力を取得するか、あるいはノードのセッション移行または共有の機能または設定についての情報をユーザに対して表示するために、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するように構成され得る。別の例では、ディスプレイは、セッション状態に関する情報を表示し得る。
【0161】
プロセッサ３２は、電源４８から電力を受けることができ、ノード３０内の他の構成要素に電力を分配したり制御したりするように構成され得る。電源４８は、ノード３０に電力を供給するための任意の適切なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）など）、太陽電池、燃料電池などを含み得る。
【0162】
プロセッサ３２は、また、ノード３０の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されたＧＰＳチップセット５０に接続されてもよい。ノード３０は、実施形態との整合性を保ちながら、任意の適切な位置決定方法によって位置情報を取得できるということは理解されるであろう。
【0163】
プロセッサ３２は、さらに、追加的特徴や機能性や有線または無線接続性を提供する１つまたは複数のソフトウェアやハードウェアのモジュール含むことができるその他の周辺機器５２に接続され得る。例えば、周辺機器５２は、加速度計や生体計測（例えば、指紋）センサなどの各種センサ、電子コンパス（ｅ－Ｃｏｍｐａｓｓ）、衛星トランシーバ、センサ、（写真またはビデオ用）デジタルカメラ、ユニバーサルシリアルバス（Universal Serial Bus：ＵＳＢ）ポートまたはその他の相互接続インターフェース、振動デバイス、テレビジョントランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（Frequency Modulated：ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。
【0164】
ノード３０は、センサ、家庭用電化製品、スマートウォッチやスマートクロージングのようなウェアラブルデバイス、医療機器やｅＨｅａｌｔｈデバイス、ロボット、産業機器、ドローン、乗用車、トラック、列車、航空機などの輸送手段などの、他の装置またはデバイス内に具現化されてもよい。ノード３０は、そのような装置またはデバイスの他の構成要素、モジュール、またはシステムに、周辺機器５２の１つを含み得る相互接続インターフェースなどの１つまたは複数の相互接続インターフェースを介して接続されてもよい。
【0165】
図１９は、図１、図３～図１０、図１２、図１３、および図１６～図１９に示すクライアント、サーバ、またはプロキシなどのネットワークの１つまたは複数のノードを実装するためにも使用できる例示的なコンピューティングシステム９０のブロック図である。このノードは、図１、図３～図１０、図１２、図１３、および図１６～図１７に示すようなＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、またはその他のノードとして動作することができる。
【0166】
コンピューティングシステム９０は、コンピュータまたはサーバを備えることができ、主としてコンピュータ読み取り可能な命令によって制御され得る。その命令はソフトウェアの形であってもよく、任意の場所に、あるいは任意の手段によって格納もしくはアクセスされてもよい。そのようなコンピュータ読み取り可能な命令は、中央処理装置（Central Processing Unit：ＣＰＵ）９１などのプロセッサ内で実行されて、コンピューティングシステム９０を機能させることができる。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれるシングルチップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は複数のプロセッサを備え得る。コプロセッサ８１は、追加的機能を実行するかまたはＣＰＵ９１をアシストする、メインＣＰＵ９１とは別のオプションのプロセッサである。ＣＰＵ９１とコプロセッサ８１の少なくとも一方は、例えば、セッション認証情報の受信またはセッション認証情報に基づく認証のような、エンドツーエンド（End-to-End：Ｅ２Ｅ）Ｍ２Ｍサービス層セッションのための開示されたシステムと方法に関連するデータを、受信、生成、および処理することができる。
【0167】
動作中、ＣＰＵ９１は命令をフェッチし、解読し、実行し、そして、コンピュータの主たるデータ転送経路であるシステムバス８０を介して、他のリソースと情報をやりとりする。そのようなシステムバスは、コンピューティングシステム９０の構成要素を接続し、データ交換の媒介手段を規定する。システムバス８０は、通常、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するためとシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の一例が、周辺構成要素相互接続（Peripheral Component Interconnect：ＰＣＩ）バスである。
【0168】
システムバス８０に接続されたメモリには、ランダムアクセスメモリ（ＲＡＭ）８２と読み出し専用メモリ（ＲＯＭ）９３が含まれる。そのようなメモリは、情報を格納し、読み出すことを可能にする回路を含む。ＲＯＭ９３は、一般に、容易に修正できない保存データを格納する。ＲＡＭ８２内に格納されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られるか、変更され得る。ＲＡＭ８２やＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供することができる。メモリコントローラ９２は、さらに、システム内のプロセスを隔離してシステムプロセスをユーザプロセスから隔離するメモリ保護機能を提供することができる。そのため、第１モードで実行中のプログラムは、それ自身のプロセス仮想アドレス空間によってマッピングされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。
【0169】
さらに、コンピューティングシステム９０は、ＣＰＵ９１から、プリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器への命令伝達を司る周辺機器コントローラ８３を含むことができる。
【0170】
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含むことができる。ディスプレイ８６は、ブラウン管（Cathode-Ray Tube：ＣＲＴ）ベースのビデオディスプレイ、液晶ディスプレイ（Liquid Crystal Display：ＬＣＤ）ベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを用いて実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要な電子部品を含む。
【0171】
さらに、コンピューティングシステム９０は、図１～図４のネットワーク１２などの外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７などの通信回路を含むことができ、それによって、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にすることができる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】