JP2011530257A - 一意の機器識別子に基づくインスタンスｉｄ生成のための方法および装置 - Google Patents

Abstract

機器とネットワークの間の信号方式のための方法および装置。方法は、ネットワークにより使用されるインスタンス身分証明書（ＩＤ）と一致するインスタンスＩＤを機器により生成するステップを含む。本発明の装置は、ネットワークにより使用されるインスタンスＩＤと一致するＩＤを生成する手段を含む。

Description

関連出願の相互参照
本出願は、開示が参照により本明細書に組み入れられる、現在係属中の米国特許仮出願第６１／０８６，９０８号明細書の利益を主張する。

本明細書において使用されるように、以下の略号が以下の意味を有するものとする。
ＣＳ：回線交換
ＣＳＣＦ：呼セッション制御機能
ＥＳＮ：電子シリアル番号
ＧＲＵＵ：大域的ルータブルユーザエージェント（ＵＡ）ＵＲＩ
Ｉ−ＣＳＣＦ：問合せＣＳＣＦ
ＩＣＳ：ＩＭＳ集中サービス
ＩＤ：識別子
ＩＭＥＩ：国際移動体装置識別番号
ＩＭＳ：ＩＰマルチメディアサブシステム
ＩＰ：インターネットプロトコル
ＭＥＩＤ：移動体装置識別子
ＭＳＣ：移動体交換局
ＮＡＩ：ネットワークアクセス識別子
ＮＳＳ：名前空間特有文字列
Ｐ−ＣＳＣＦ：プロキシＣＳＣＦ
ＰＳ：パケット交換
Ｓ−ＣＳＣＦ：サービングＣＳＣＦ
ＳＣＣ ＡＳ：サービス集中および継続アプリケーションサーバ
ＳＩＰ：セッション開始プロトコル
ＳＮＲ：シリアル番号
ＴＡＣ：タイプ・アロケーション・コード
ＵＡ：ユーザエージェント
ＵＥ：ユーザ装置
ＵＲＩ：統一資源識別子
ＵＵＩＤ：汎用一意識別子

ＩＭＳなどのＳＩＰを基にしたシステムでは、限定されているわけではないが、携帯電話、端末、ＵＥ、固定回線端末、またはソフトウェアを基にしたクライアント（本明細書においてときどき「機器」と呼ばれる）などの特定の機器に要求を向けることが望ましい。たとえば、呼を転送するとき、携帯電話などの特定の機器に向けることが好ましいことがある。

このことを達成するために、大域的ルータブルユーザエージェント（ＵＡ）ＵＲＩ（ＧＲＵＵ）がレジストラ（ＩＭＳシステムではＳ−ＣＳＣＦである）により機器に割り当てられる。ＧＲＵＵを適切に割り当てるために、レジストラは登録中に機器により提供されるインスタンスＩＤを使用する。

インスタンスＩＤは実際のＧＲＵＵを生成するためにレジストラにより使用される。最も一般的な手法が、ＧＲＵＵの「ｇｒ」パラメータとしてインスタンスＩＤを使用することである。

現在のＩＭＳ仕様は、ＧＲＵＵを使ってターゲットにされている機器が、登録を行っていると仮定する。しかし、ＩＭＳ集中サービス（ＩＣＳ）の導入に伴って、機器がＣＳアクセスを使用しているとき、ネットワークが機器に代わってＩＭＳに登録することができる。ＩＣＳの場合、ＭＳＣサーバが、ＣＳ加入者に代わって登録するネットワークエンティティである。

ＩＣＳ機器はまた、ＰＳアクセスを使用しているときＩＭＳに直接登録することができることがあるので、ネットワークにより使用されるインスタンスＩＤが、登録を行っているときに機器により使用されるインスタンスＩＤと同一であることが望ましい。このことが、同じＧＲＵＵが機器に割り当てられることを保証する。

現在のＩＭＳ仕様は、機器またはネットワークがインスタンスＩＤをどのように生成しなければならないかに関するどんな具体的な手引きも提供していない。提供されている唯一の手引きが、インスタンスＩＤはＩＥＴＦアウトバウンドドラフトに記載されている形式と調和しなければならないことである。したがって、現在のＩＭＳ仕様では、ネットワークにより使用されるインスタンスＩＤが機器により使用されるインスタンスＩＤと一致することが保証されない。

さらに、現在のＩＭＳ仕様では、レジストラがインスタンスＩＤからＧＲＵＵをどのようにして生成しなければならないかに関するどんな手引きも提供されない。このことは、異なるＳ−ＣＳＣＦベンダが異なる方法でＧＲＵＵを生成することを選択した場合に、どのＳ−ＣＳＣＦが登録中に割り当てられるかによって、結果的に異なるＧＲＵＵが生成されることがある。

ＩＭＥＩなどの端末からの既に存在する装置識別番号をインスタンスＩＤとして直接使用することが提案された。しかし、Ｓ−ＣＳＣＦがＧＲＵＵとして元のままのインスタンスＩＤを使用する場合、これによりセッション確立中にＤｅｖＩＤが別のユーザに曝されることになる。これはプライバシ侵害と考えることができ、装置の複製を作るために使用される可能性がある。したがって、ＩＭＥＩなどの既存の機器識別番号をインスタンスＩＤとして直接使用することには不利な点がある。

以下は本発明の一部の態様の基本的理解を提供するために、本発明の概要を提示する。この概要は本発明の網羅的概観ではない。この概要は本発明の主要な、または重要な要素を識別するためのものでも、本発明の範囲を正確に叙述するためのものでもない。この概説の唯一の目的は、後で説明されるより詳細な説明の導入として、簡略化された形式で一部の概念を提示することである。

本発明は、インスタンスＩＤが機器により生成されるにせよ、ネットワークにより生成されるにせよ一貫しているが、それと同時にプライバシおよびセキュリティを提供するインスタンスＩＤを生成する手順を説明する。

一貫性を保証するために、インスタンスＩＤの生成は、機器に属するが、ネットワークにも公知である一意の識別子の使用に基づく（本明細書において「ＤｅｖＩＤ」と呼ばれる）。

プライバシを保証するために、インスタンスＩＤまたはＧＲＵＵの生成は、ＤｅｖＩＤを保護するためのハッシュ、およびＤｅｖＩＤをインスタンスＩＤまたはＧＲＵＵに符号化するときにネットワークによっても機器によっても使用される共有名前空間を使用することに基づく。

インスタンスＩＤは、暗号化されていない平文として渡されるＤｅｖＩＤに関する情報を含まないことが最適である。しかし、インスタンスＩＤは、本明細書において記載されるようにＵＥがインスタンスＩＤを保護することを義務づけることができないことがあるので、レジストラが何らかのレベルの保護を提供するための手順を記述する必要もある。したがって、本発明は、ＤｅｖＩＤが最初、登録中に保護されずに送信されるときでさえ、あるレベルのプライバシを提供するために使用されることができる別の手法を説明する。

したがって、本発明はプライバシに対する懸念に対処する２つの手法を主張する。すなわち、（１）実際のＤｅｖＩＤに関するどんな情報も明かさないインスタンスＩＤを生成するための仕組みを規定すること。これにより、インスタンスＩＤをＧＲＵＵの「ｇｒ」パラメータとして直接使用することができるようにし、また、（２）．インスタンスＩＤが暗号でなくＤｅｖＩＤ平文を含む場合、レジストラがＧＲＵＵの「ｇｒ」パラメータを生成するためにインスタンスＩＤを扱う仕組みを規定することである。これにより、ＵＥからの非登録シグナリングでＤｅｖＩＤのためのプライバシが提供される。

次節では、本発明が図で示される例示的実施形態を参照して説明される。

ＵＵＩＤ文字列表現を図示するテーブルである。 ＩＭＥＩに対する名前空間定義、またはＵＵＩＤ生成に基づく別の機器ＩＤを図示するテーブルである。 ＩＭＥＩの構造を示す図である。 ＩＭＥＩＳＶの構造を示す図である。 ＭＥＩＤの構造を示す図である。 インスタンスＩＤにおいて保護されたＤｅｖＩＤを使った機器登録を図示するメッセージ流れ図である。 インスタンスＩＤ（ｓｉｐ．ｉｎｓｔａｎｃｅ）を使った例示的ＲＥＧＩＳＴＥＲである。 インスタンスＩＤにおいて保護されたＤｅｖＩＤを使った、ＣＳ ＵＥに代わるネットワーク登録を図示するメッセージ流れ図である。 インスタンスＩＤ（ｓｉｐ．ｉｎｓｔａｎｃｅ）を使った例示的ＲＥＧＩＳＴＥＲである。 インスタンスＩＤにおいて保護されていないＤｅｖＩＤを使った機器登録を図示するメッセージ流れ図である。 インスタンスＩＤ（ｓｉｐ．ｉｎｓｔａｎｃｅ）を使った例示的ＲＥＧＩＳＴＥＲである。 ＧＲＵＵを使った例示的２００（ＯＫ）である。 インスタンスＩＤにおいて保護されていないＤｅｖＩＤを使った、ＣＳ ＵＥに代わるネットワーク登録を伴うメッセージ流れ図である。 インスタンスＩＤ（ｓｉｐ．ｉｎｓｔａｎｃｅ）を使った例示的ＲＥＧＩＳＴＥＲである。 ＧＲＵＵを使った例示的２００（ＯＫ）である。

本発明は、既存の装置識別番号のプライバシを保証しながらＩＤの一意性を保証するインスタンスＩＤの生成を容易にする。本発明はまた、ネットワーク（ＭＳＣサーバ）および機器が、ＧＲＵＵの生成で使用されるのと同一のインスタンスＩＤを生成することを保証する仕組みを提供する。本発明はＲＦＣ４１２２に規定されるＵＵＩＤ形式を使用する。

さらに、本発明は、ＩＤが、登録中にネットワークに送信されるインスタンスＩＤにおいて保護されていないときでさえ、ＤｅｖＩＤに対するプライバシをネットワークが提供する仕組みを提供する。本発明のこの態様は、ＵＥまたはＭＳＣサーバがＤｅｖＩＤを保護するときに採用されるのと同じ技法を使用するが、レジストラ（Ｓ−ＣＳＣＦ）により実施される。

本明細書において記載されるように、機器はＧＲＵＵ、およびインスタンスＩＤの生成をサポートする３ＧＰＰモバイルであると仮定されるが、本発明は、ネットワークおよび機器が機器特有識別子の知識を共有する任意の機器に適用できる。３ＧＰＰ機器の場合、ＤｅｖＩＤはＩＭＥＩから得られる。３ＧＰＰ２機器の場合、ＤｅｖＩＤはＭＥＩＤまたはＥＳＮから得られる。

ソフトウェアを基にしたクライアント、および移動体標準に完全には適合しないクライアントについては、ＩＭＥＩ（または同等物）が利用できないことがある。したがって、本発明の別の態様では、ＤｅｖＩＤは端末のプライベートユーザ識別番号に基づき生成される。そのようなシナリオでは、機器が、レジストラに向けたいくつかのプライベートユーザ識別番号（ＰＳアクセスを介するなどのＵＥからの識別番号、およびユーザに代わって登録するＭＳＣサーバからの識別番号）により表されることがある。一貫した動作を保証するためには、ＵＥも登録を行うネットワークも、ネットワークにより使用されるプライベートＩＤに基づきＤｅｖＩＤを選択する必要がある。ＤｅｖＩＤとしてネットワークからのプライベートＩＤを使用する別の利点は、ＤｅｖＩＤが、使用されるＣＳアクセスのタイプにとらわれなくなるということである。

両方の手法に共通の情報
本発明では、ＲＦＣ４１２２に記載されるように、ＵＵＩＤの名前を基にしたバージョンが使用される。バージョン３またはバージョン５のいずれかを使用することができ、唯一の差は、使用されるハッシングのタイプである（それぞれ、ＭＤ５およびＳＨＡ−１）。図１のテーブル１００で示されるように、インスタンスＩＤは、ＲＦＣ４１２２に記載されているように、ＵＵＩＤの文字列表現を使用してＵＵＩＤ ＵＲＮとして構築される。

最終的なインスタンスＩＤを生成するためには、名前空間ＩＤが必要とされる。図２のテーブル２００が本明細書において一例として使用される名前空間の定義を提供する。さらに、図３が様々な標準で使用される一意機器識別子３００を図示する。本明細書において示されるように、ＩＭＥＩは以下の要素からなる（各要素は１０進数字だけからなる）。
１．タイプ・アロケーション・コード（ＴＡＣ）３０１。ＴＡＣの長さは８桁である。
２．シリアル番号（ＳＮＲ）３０２は、ＴＡＣの範囲内で各装置を一意に識別する個々のシリアル番号である。ＳＮＲの長さは６桁である。
３．スペアディジット（チェックディジット）３０３。この数字はＬｕｈｎチェックサムディジットとして使用され、ＩＭＥＩと一緒に送信されない。

ＩＭＥＩ（１４桁）はチェックディジットにより補数をとられる。チェックディジットは送信される桁の一部ではない。

例示的ＤｅｖＩＤ導出
３ＧＰＰ ＩＭＥＩ：
ＴＡＣ：３５１９６５００
ＳＮＲ：７１８９１７
チェックディジット：７
ＤｅｖＩＤ＝ＴＡＣ＋ＳＮＲ＝３５１９６５００７１８９１７

図４で示されるＩＭＥＩＳＶ４００は以下の要素からなる（各要素は１０進数字だけからなる）。
１．タイプ・アロケーション・コード（ＴＡＣ）４０１。ＴＡＣの長さは８桁である。
２．シリアル番号（ＳＮＲ）４０２は、各ＴＡＣの範囲内で各装置を一意に識別する個々のシリアル番号である。ＳＮＲの長さは６桁である。
３．ソフトウェアバージョン番号（ＳＶＮ）４０３が、移動体装置のソフトウェアバージョン番号を識別する。ＳＶＮの長さは２桁である。

例示的ＤｅｖＩＤ導出
３ＧＰＰ ＥＭＥＩＳＶ：
ＴＡＣ：３５１９６５００
ＳＮＲ：７１８９１７
ＳＶＮ：０４
ＤｅｖＩＤ＝ＴＡＣ＋ＳＮＲ＝３５１９６５００７１８９１７

図５のＭＥＩＤ５００では、これらのフィールドのすべてが以下の有効範囲を有する１６進値として規定される。
ＮＮ５０１ 有効範囲Ａ〜０
ＦＦ５０２ 大域的に管理される
ＴＴＴＴＴＴ５０３ 有効範囲００００００〜ＦＦＦＦＦＦ
ＺＺＺＺＺＺ５０４ 有効範囲００００００〜ＦＦＦＦＦＦ
ＣＤ５０５ 有効範囲０〜Ｆ

チェックディジット（ＣＤ）５０５はＭＥＩＤの一部ではなく、ＭＥＩＤが送信されるときに送信されない。

例示的ＤｅｖＩＤ導出
３ＧＰＰ２ ＭＥＩＤ：
ＴＡＣ：Ａ１００００００
ＳＮＲ：３Ｆ０Ｄ５０
ＣＤ：
ＤｅｖＩＤ＝ＴＡＣ＋ＳＮＲ＝Ａ１００００００３Ｆ０Ｄ５０

以下は一意機器ＩＤのない機器に対する識別子の別の選択肢である。

プライベートＩＤソリューション（アクセスにとらわれない）
場合によっては、クライアントに利用できるＩＭＥＩなどの機器特有ＩＤがないことがある。たとえば、これは、ソフトウェアクライアントを使用するときにあてはまる。この場合、プライベート識別番号を代わりに使用することができる。プライベート識別番号はＲＦＣ４２８２に規定されるようにネットワークアクセス識別子（ＮＡＩ）の形をとる。

ＩＭＳに対する例示的ＩＭＳのプライベート識別番号がｕｓｅｒ１＿ｐｒｉｖａｔｅ＠ｈｏｍｅ１．ｎｅｔである。

例示的ＤｅｖＩＤ導出
プライベートＩＤ：
プライベートＩＤ：ｕｓｅｒ１＿ｐｒｉｖａｔｅ＠ｈｏｍｅ１．ｎｅｔ
ＤｅｖＩＤ＝プライベートＩＤ＝ｕｓｅｒ１＿ｐｒｉｖａｔｅ＠ｈｏｍｅ１．ｎｅｔ

ＵＥまたはネットワーク（ＭＳＣサーバ）内でＤｅｖＩＤ保護を提供するときのインスタンスＩＤ生成
前に説明したように、本発明の好ましい実施形態は、登録中でさえもＵＥまたはＭＳＣサーバでＤｅｖＩＤを保護するものである。したがって、ＤｅｖＩＤは以下のステップを使用して符号化されるものとする。

機器特有ＩＤを使用して、この例では３ＧＰＰで規定されるＩＭＥＩを使用して、ＵＥまたはネットワーク（ＭＳＣサーバ）でインスタンスＩＤを生成するためのステップ。
１．ネットワークおよび機器が同じハッシュアルゴリズム（ＭＤ５またはＳＨＡ−１）を選択する。この例はＭＤ５を使用して本発明を例示する。
２．（図３で示されるような）ＩＭＥＩからＴＡＣおよびＳＮＲを抽出することによりＤｅｖＩＤを生成する。スペアディジットは使用される総計１４桁に対して省かれる。スペアディジットを省くことにより、本発明のこの方法はまた、ＳＶＮが省かれるＩＭＥＩＳＶにも適用できる。ＩＭＥＩ以外の識別子を使用する非３ＧＰＰ機器については、ＤｅｖＩＤのための唯一の基準が、ＤｅｖＩＤが機器に一意であり、かつネットワークにより知られていることである。
３．（図２のテーブル２００で示されるような）名前空間ＩＤおよびＤｅｖＩＤをネットワークのバイト順に配置する。
４．名前空間ＩＤとＤｅｖＩＤを連結する。
５．事前に選択されたハッシュアルゴリズムを使用して、連結された文字列のハッシュを計算する。
６．上記で計算されたハッシュを使用して、ＲＦＣ４１２２の第４．３節に明記されるようにＵＵＩＤフィールドを設定し、ＲＦＣの第３節に示されるように文字列表現を生成する。
７．上記の文字列の前に「ｕｒｎ：ｕｕｉｄ」を付加することによりｕｒｎ形に文字列表現を配置する。例：ｕｒｎ：ｕｕｉｄ：３６４７ｆ４９３−４９４８−ａｂｅ２−６５９９−７ｃ２９５ａｂ２９８０４
８．このＵＵＩＤ ＵＲＮは、この機器に代わって登録するときにこの機器のためにネットワークにより使用されるインスタンスＩＤである。

ＵＥまたはネットワーク（ＭＳＣサーバ）でＤｅｖＩＤ保護を提供する例示的呼の流れ
図６および図８は本発明の方法のステップを図示する基本的な呼の流れ６００、８００を描く。これらの例示的呼の流れはＩＭＳを基にするネットワークアーキテクチャを示すが、本発明はまた同様に非ＩＭＳアーキテクチャにも適用される。

図６では、移動体機器がＰＳアクセスを使用してＩＭＳで（レジストラに向かって）機器自体を直接登録する呼の流れ６００が図示されている。図８では、ネットワークがＣＳアクセスを使用している機器に代わって登録する呼の流れ８００が図示されている。

明確にするために、以下の例中のＳＩＰヘッダの一部を含む、本発明に無関係な一部の詳細を省いた。

機器登録
本発明を実現している機器の基本登録の流れが図６で示される。図６で示されるように、
１．インスタンスＩＤを構築する６０１：ＵＥ Ａが本発明で説明されるように自分のＩＭＥＩから得られるインスタンスＩＤを生成する
２．ＲＥＧＩＳＴＥＲ要求（ＵＥ ＡからＰ−ＣＳＣＦに）６０２。この要求の一例が図７のテーブル７００で示される。
３．ＲＥＧＩＳＴＥＲ要求（Ｐ−ＣＳＣＦからＩ−ＣＳＣＦに）６０３。Ｐ−ＣＳＣＦがＩ−ＣＳＣＦに要求を転送する。
４．Ｃｘユーザ登録状態問合せ手順６０４。Ｉ−ＣＳＣＦが、プライベートユーザ識別番号、パブリックユーザ識別番号、および訪問したドメイン名をＨＳＳに送信することにより加入者登録状態に関係のある情報を要求する。ＨＳＳはＳ−ＣＳＣＦに必要とされる能力を返し、Ｉ−ＣＳＣＦはこの情報を使用して適切なＳ−ＣＳＣＦを選択する。
５．ＲＥＧＩＳＴＥＲ要求（Ｉ−ＣＳＣＦからＳ−ＣＳＣＦに）６０５。Ｉ−ＣＳＣＦが、選択されたＳ−ＣＳＣＦにＲＥＧＩＳＴＥＲ要求を転送する。
６．４０１（認証失敗）（Ｓ−ＣＳＣＦからＩ−ＣＳＣＦ）６０６。Ｓ−ＣＳＣＦが登録要求をチャレンジする。
７．４０１（認証失敗）（Ｉ−ＣＳＣＦからＰ−ＣＳＣＦに）６０７。Ｉ−ＣＳＣＦがＰ−ＣＳＣＦに応答を転送する。
８．４０１（認証失敗）（Ｐ−ＣＳＣＦからＵＥ Ａに）６０８。Ｐ−ＣＳＣＦがＵＥ Ａに応答を転送する。
９．ＲＥＧＩＳＴＥＲ要求（ＵＥ ＡからＰ−ＣＳＣＦに）６０９。ＵＥ Ａが、（ステップ６０２で示されるように）今回は認証信任状を伴うＲＥＧＩＳＴＥＲ要求を再送する。
１０．ＲＥＧＩＳＴＥＲ要求（Ｐ−ＣＳＣＦからＩ−ＣＳＣＦに）６１０。Ｐ−ＣＳＣＦがＩ−ＣＳＣＦに要求を転送する。
１１．Ｃｘ：ユーザ登録状態問合せ手順６１１。Ｉ−ＣＳＣＦが、プライベートユーザ識別番号、パブリックユーザ識別番号、および訪問したドメイン名をＨＳＳに送信することにより加入者登録状態に関係する情報を要求する。ＨＳＳはＳ−ＣＳＣＦに必要とされる能力を返し、Ｉ−ＣＳＣＦはこの情報を使用して適切なＳ−ＣＳＣＦを選択する。
１２．ＲＥＧＩＳＴＥＲ要求（Ｉ−ＣＳＣＦからＳ−ＣＳＣＦに）６１２。Ｉ−ＣＳＣＦが、選択されたＳ−ＣＳＣＦにＲＥＧＩＳＴＥＲ要求を転送する。
１３．Ｃｘ：Ｓ−ＣＳＣＦ登録通知６１３。Ｓ−ＣＳＣＦがＨＳＳに、ユーザが登録されたことを通知する。Ｓ−ＣＳＣＦにより要求されると、ＨＳＳはまた、Ｓ−ＣＳＣＦに送信される応答中にユーザプロファイルを含む。
１４．ＧＲＵＵを構築する６１４。Ｓ−ＣＳＣＦ（レジストラの役割を果たす）が、ステップ６０１で生成されたインスタンスＩＤに基づきＧＲＵＵを構築する。ＧＲＵＵはｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕに規定されるように構築されるものとする。
１５．２００（ＯＫ）（Ｓ−ＣＳＣＦからＩ−ＣＳＣＦに）６１５：Ｓ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＩ−ＣＳＣＦに送信する。２００（ＯＫ）応答は、前のステップで生成されたＧＲＵＵを含む。
１６．２００（ＯＫ）（Ｉ−ＣＳＣＦからＰ−ＣＳＣＦに）６１６：Ｉ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＰ−ＣＳＣＦに転送する。
１７．２００（ＯＫ）（Ｐ−ＣＳＣＦからＵＥ Ａに）６１７：Ｐ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＵＥ Ａに転送する。

ネットワーク登録
図８は、本発明により提供される機能を追加することにより３ＧＰＰ ＴＳ ２４．２９２の呼の流れを改善する強化された呼の流れ８００を図示する。信号方式の詳細は以下のとおりである。
１．ＣＳ ａｔｔａｃｈ（ＵＥ ＡからＭＳＣに）８０１。
２．認証および位置更新（ＭＳＣ／ＶＬＲからＨＬＲ／ＨＳＳに）８０２。
３．ＣＳ ａｔｔａｃｈ ａｃｃｅｐｔ（ＭＳＣからＵＥ Ａに）８０３。
４．ＩＭＳ登録評価８０４。ＭＳＣサーバがＩＭＳを使って登録を行う必要があるかどうかを評価する。このことは、ＨＳＳ／ＨＬＲから受信された加入者データに基づくことができる。
５．ＩＭＳアドレス発見８０５。ＭＳＣサーバがホーム・ネットワーク・ドメイン名を得る。ホーム・ネットワーク・ドメイン名はホームネットワーク内のＩ−ＣＳＣＦの位置を突き止めるためのＤＮＳ問合せを行うために使用される。
６．インスタンスＩＤを構築する８０６。ＭＳＣサーバが、本発明で説明されるＵＥ ＡのＩＭＥＩから得られるインスタンスＩＤを生成する
７．ＲＥＧＩＳＴＥＲ要求（ＭＳＣサーバからＩ−ＣＳＣＦに）８０７。この要求の目的は、プライベートユーザ識別番号、およびホームネットワーク内でＳ−ＣＳＣＦを使ってユーザに代わってこの加入者に対して得られた一時的パブリックユーザ識別番号を登録することである。この要求はホームネットワーク内のＩ−ＣＳＣＦにルーティングされる。
８．Ｃｘ：ユーザ登録状態問合せ手順８０８。Ｉ−ＣＳＣＦが、プライベートユーザ識別番号、パブリックユーザ識別番号、および訪問したドメイン名をＨＳＳに送信することにより加入者登録状態に関係する情報を要求する。ＨＳＳはＳ−ＣＳＣＦに必要とされる能力を返し、Ｉ−ＣＳＣＦがこの情報を使用して適切なＳ−ＣＳＣＦを選択する。
９．ＲＥＧＩＳＴＥＲ要求（Ｉ−ＣＳＣＦからＳ−ＣＳＣＦに）８０９。Ｉ−ＣＳＣＦが、選択されたＳ−ＣＳＣＦにＲＥＧＩＳＴＥＲ要求を転送する。
１０．Ｃｘ：Ｓ−ＣＳＣＦ登録通知８１０。Ｓ−ＣＳＣＦがＨＳＳに、ユーザが登録されたことを通知する。Ｓ−ＣＳＣＦにより要求されると、ＨＳＳはまた、Ｓ−ＣＳＣＦに送信される応答中にユーザプロファイルを含む。
１１．ＧＲＵＵを構築する８１１。Ｓ−ＣＳＣＦ（レジストラの役割を果たす）が、上記のステップ８０６で生成されたインスタンスＩＤに基づきＧＲＵＵを構築する。ＧＲＵＵはｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｇｒｕｕに規定されるように構築されるものとする。インスタンスＩＤは、機器が生成したのと同じなので、生成されるＧＲＵＵはまた、直接登録している機器に返されるものと同じである。
１２．２００（ＯＫ）（Ｓ−ＣＳＣＦからＩ−ＣＳＣＦに）８１２。Ｓ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＩ−ＣＳＣＦに送信する。２００（ＯＫ）応答は前のステップで生成されたＧＲＵＵを含む。
１３．２００（ＯＫ）（Ｉ−ＣＳＣＦからＭＳＣサーバに）８１３。Ｉ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＭＳＣサーバに転送する。レジストラ（Ｓ−ＣＳＣＦ）によるＧＲＵＵ生成は、登録中に保護されていないことに留意されたい。

ＤｅｖＩＤは、登録中でさえも保護されることが最適であるが、登録中にインスタンスＩＤとして暗号化されていない平文で送信される場合がある。ユーザに対して何らかのレベルのプライバシ保護を提供するために、ＤｅｖＩＤを明かさない方法でインスタンスＩＤに基づきＧＲＵＵを構築するためのネットワーク内の手順を規定することが必要である。

本発明の別の実施形態が、ＤｅｖＩＤを保護したインスタンスＩＤの生成のための上記で説明されたのと同じ技法を使用する。しかし、このシナリオでは、レジストラ（Ｓ−ＣＳＣＦ）はこれらの技法をインスタンスＩＤではなくＧＲＵＵの「ｇｒ」パラメータの生成に適用する。

インスタンスＩＤにおいて暗号化されていない平文で移送されるときのＤｅｖＩＤの形式
ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｏｕｔｂｏｕｎｄに記載されているように、どのインスタンスＩＤもＵＲＮ体系を使用しなければならない。保護されたＤｅｖＩＤをインスタンスＩＤとして送信するときにＲＦＣ４１２２に基づくＵＲＮを使用する本発明の一実施形態が本明細書において説明された。しかし、ＤｅｖＩＤ形式を暗号化されていない平文として送信するとき、参照すべき最終的に承認されたＲＦＣが現在ない。したがって、ＤｅｖＩＤに対するＵＲＮがどのように見えるかの例を示すことしかできない。そのようなＵＲＮの最終形式は本明細書に提示される例と同一でないことがあるが、記載される原理が、同じ情報を運ぶ別の形式に依然として適用されるべきである。

ＩＭＥＩを基にするＤｅｖＩＤの１つの提案された形式がｄｒａｆｔ−ｍｏｎｔｅｍｕｒｒｏ−ｇｓｍａ−ｉｍｅｉ−ｕｒｎに記載されている。そのドラフトに基づく例示的インスタンスＩＤが以下のとおりである。
３ＧＰＰ ＩＭＥＩ：
ＴＡＣ：３５１９６５００
ＳＮＲ：７１８９１７
チェックディジット：７
＋ｓｉｐ．ｉｎｓｔａｎｃｅ＝“＜ｕｒｎ：ｇｓｍａ：ｉｍｅｉ：３５１９６５００−７１８９１７−０＞”

末端のゼロ（０）は常にゼロ（０）として送信されるスペアディジットを表すことに留意されたい。

レジストラはインスタンスＩＤ（＋ｓｉｐ．ｉｎｓｔａｎｃｅ）中の受信されたＵＲＮ形式を使用して、どの取扱いを適用すべきかを決定する。この例では、ｕｒｎ：ｇｓｍａ：ｉｍｅｉの受信が本発明の手順を適用するトリガとなる。

ＤｅｖＩＤが登録中に保護されていないときのレジストラ（Ｓ−ＣＳＣＦ）によるＧＲＵＵ生成のためのステップ
インスタンスＩＤ中の保護されていないＤｅｖＩＤに基づきレジストラ（Ｓ−ＣＳＣＦ）によりＧＲＵＵを生成するステップは以下のとおりである。
１．前提条件：ＲＥＧＩＳＴＥＲメッセージがレジストラ（Ｓ−ＣＳＣＦ）に到着し、インスタンスＩＤが、インスタンスＩＤ中で使用されるＵＲＮ体系に基づき（この例では「ｕｒｎ：ｇｓｍａ：ｉｍｅｉ」）、暗号化されていない平文で送信されたＤｅｖＩＤを含むことをレジストラ（Ｓ−ＣＳＣＦ）が識別した。
２．レジストラ（Ｓ−ＣＳＣＦ）がハッシュアルゴリズム（ＭＤ５またはＳＨＡ−１）を選択する。この例はＭＤ５を使用する。
３．ＩＭＥＩからＴＡＣおよびＳＮＲを抽出する（ＵＲＮ中のＩＭＥＩ構造は前に図示された）。ＴＡＣおよびＳＮＲは使用され、スペアディジットは、使用される総計１４桁のために省かれる。スペアディジットを省くことにより、この技法はまた、ＳＶＮが省かれるＩＭＥＩＳＶにも適用できる。
４．図２のテーブル２００で示されるような名前空間ＩＤ、ＴＡＣおよびＳＮＲをネットワークバイト順に配置する。
５．名前空間ＩＤ、ＴＡＣ、およびＳＮＲを連結する。
６．あらかじめ選択されたハッシュアルゴリズムを使用して、連結された文字列のハッシュを計算する。
７．上記で計算されたハッシュを使用して、ＲＦＣ４１２２の第４．３節に記載されているようなＵＵＩＤフィールドを設定し、ＲＦＣの第３節に示されるような文字列表現を生成する。
８．上記の文字列の前に「ｕｒｎ：ｕｕｉｄ」を付加することによりｕｒｎ形で文字列表現を配置する。および
９．このＵＵＩＤ ＵＲＮが、受信されたインスタンスＩＤに基づき割り当てられるＧＲＵＵの「ｇｒ」パラメータである。

ＩＭＥＩ以外の識別が使用される非３ＧＰＰ機器の場合、唯一の基準が、インスタンスＩＤの内容が機器に対して一意であり、時間と共に変化しないということである。

本発明の別の実施形態は、ＵＲＮ形式が認識されない場合に、またはＩＭＥＩ同等物を有しないことがある非３ＧＰＰ機器の場合に、レジストラにより実現することができる。これらの場合には、レジストラは以下のステップを使用することができる。
１．レジストラ（Ｓ−ＣＳＣＦ）がハッシュアルゴリズム（ＭＤ５またはＳＨＡ−１）を選択する。この例はＭＤ５を使用して例示される。
２．インスタンスＩＤ（＋ｓｉｐ．ｉｎｓｔａｎｃｅ）からＵＲＮ（ＲＦＣ２１４１に規定される）から名前空間特有（ＮＳＳ）文字列を抽出する。
３．ネットワークバイト順にＮＳＳを配置する。
４．ＮＳＳのハッシュを計算する。
５．このハッシュされた値が、受信されたインスタンスＩＤに基づいて割り当てられるＧＲＵＵの「ｇｒ」パラメータである。

レジストラでＤｅｖＩＤ保護を提供する例示的呼の流れ
ここで、図１０および図１３を参照すると、本発明を実現する基本的呼の流れが図示されている。これらの例示的呼の流れは、ＩＭＳを基にするネットワークアーキテクチャを図示するが、本発明は同様に非ＩＭＳアーキテクチャにも適用できる。

図１０の呼の流れは、ＰＳアクセスを使用して（レジストラに向かって）直接ＩＭＳに自分を登録する移動体機器を図示する。図１３の呼の流れは、ＣＳアクセスを使用している機器に代わってネットワークが登録するときの呼の流れを図示する。

図１０および図１３に図示される本発明に関係しない一部の詳細が、明確にするために省かれた。これは例中のＳＩＰヘッダの一部を含む。

機器登録
図１０は本発明を実装している機器について基本的登録の流れ１０００を提供する。信号方式の流れの詳細は以下のとおりである。
１．インスタンスＩＤを構築する１００１：ＵＥ Ａが、平文でＩＭＥＩを移送するＵＲＮ形式を使用してインスタンスＩＤを生成する。
２．ＲＥＧＩＳＴＥＲ要求（ＵＥ ＡからＰ−ＣＳＣＦに）１００２：図１１のテーブル１１００を参照のこと。
３．ＲＥＧＩＳＴＥＲ要求（Ｐ−ＣＳＣＦからＩ−ＣＳＣＦに）１００３：Ｐ−ＣＳＣＦがＩ−ＣＳＣＦに要求を転送する。
４．Ｃｘ：ユーザ登録状態問合せ手順１００４：Ｉ−ＣＳＣＦが、プライベートユーザ識別番号、パブリックユーザ識別番号、および訪問したドメイン名をＨＳＳに送信することにより加入者登録状態に関係する情報を要求する。ＨＳＳはＳ−ＣＳＣＦに必要とされる能力を返し、Ｉ−ＣＳＣＦがこの情報を使用して適切なＳ−ＣＳＣＦを選択する。
５．ＲＥＧＩＳＴＥＲ要求（Ｉ−ＣＳＣＦからＳ−ＣＳＣＦに）１００５：Ｉ−ＣＳＣＦが、選択されたＳ−ＣＳＣＦにＲＥＧＩＳＴＥＲ要求を転送する。
６．４０１（認証失敗）（Ｓ−ＣＳＣＦからＩ−ＣＳＣＦに）１００６：Ｓ−ＣＳＣＦが登録要求をチャレンジする。
７．４０１（認証失敗）（Ｉ−ＣＳＣＦからＰ−ＣＳＣＦに）１００７：Ｉ−ＣＳＣＦがＰ−ＣＳＣＦに応答を転送する。
８．４０１（認証失敗）（Ｐ−ＣＳＣＦからＵＥ Ａに）１００８：Ｐ−ＣＳＣＦがＵＥ Ａに応答を転送する。
９．ＲＥＧＩＳＴＥＲ要求（ＵＥ ＡからＰ−ＣＳＣＦに）１００９：ＵＥ Ａが（ステップ１００２で示されるように）今回は認証信任状を伴うＲＥＧＩＳＴＥＲ要求を再送する。
１０．ＲＥＧＩＳＴＥＲ要求（Ｐ−ＣＳＣＦからＩ−ＣＳＣＦに）１０１０：Ｐ−ＣＳＣＦがＩ−ＣＳＣＦに要求を転送する。
１１．Ｃｘ：ユーザ登録状態問合せ手順１０１１：Ｉ−ＣＳＣＦが、プライベートユーザ識別番号、パブリックユーザ識別番号、および訪問したドメイン名をＨＳＳに送信することにより加入者登録状況に関係する情報を要求する。ＨＳＳはＳ−ＣＳＣＦに必要とされる能力を返し、Ｉ−ＣＳＣＦはこの情報を使用して適切なＳ−ＣＳＣＦを選択する。
１２．ＲＥＧＩＳＴＥＲ要求（Ｉ−ＣＳＣＦからＳ−ＣＳＣＦに）１０１２：Ｉ−ＣＳＣＦが、選択されたＳ−ＣＳＣＦにＲＥＧＩＳＴＥＲ要求を転送する。
１３．Ｃｘ：Ｓ−ＣＳＣＦ登録通知１０１３：Ｓ−ＣＳＣＦがＨＳＳに、ユーザが登録されたことをＨＳＳに通知する。Ｓ−ＣＳＣＦにより要求されると、ＨＳＳはまた、Ｓ−ＣＳＣＦに送信される応答中にユーザプロファイルを含む。
１４．ＧＲＵＵを構築する１０１４：Ｓ−ＣＳＣＦ（レジストラの役割を果たす）が、ステップ１００１で送信されたインスタンスＩＤに基づきＧＲＵＵを構築する。ＧＲＵＵは本明細書において前に説明されるように構築されるものとする（登録中にＤｅｖＩＤが保護されていないときの、レジストラ（Ｓ−ＣＳＣＦ）によるＧＲＵＵ生成のためのステップ、および図１２のテーブル１２０１を参照のこと）
１５．２００（ＯＫ）（Ｓ−ＣＳＣＦからＩ−ＣＳＣＦに）１０１５：Ｓ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＩ−ＣＳＣＦに送信する。２００（ＯＫ）応答は、前のステップで生成されたＧＲＵＵを含む。
１６．２００（ＯＫ）（Ｉ−ＣＳＣＦからＰ−ＣＳＣＦに）１０１６：Ｉ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＰ−ＣＳＣＦに転送する。
１７．２００（ＯＫ）（Ｐ−ＣＳＣＦからＵＥ Ａに）１０１７：Ｐ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＵＥ Ａに転送する。

ネットワーク登録
図１３は、３ＧＰＰ ＴＳ ２４．２９２に記載され、呼の流れに対して改善された呼の流れ１３００を図示する。信号方式の流れの詳細は以下のとおりである。
１．ＣＳ ａｔｔａｃｈ（ＵＥ ＡからＭＳＣに）１３０１。
２．認証および位置更新（ＭＳＣ／ＶＬＲからＨＬＲ／ＨＳＳに）１３０２。
３．ＣＳ ａｔｔａｃｈ ａｃｃｅｐｔ（ＭＳＣからＵＥ Ａに）１３０３。
４．ＩＭＳ登録評価１３０４：ＭＳＣサーバが、ＩＭＳを使って登録を行う必要があるかどうか評価する。このことは、ＨＳＳ／ＨＬＲから受信される加入者データに基づくことができる。
５．ＩＭＳアドレス発見１３０５：ＭＳＣサーバがホーム・ネットワーク・ドメイン名を得る。ホーム・ネットワーク・ドメイン名は、ホームネットワーク内でＩ−ＣＳＣＦの位置を突き止めるためのＤＮＳ問合せを行うために使用される。
６．インスタンスＩＤを構築する１３０６：ＭＳＣサーバが、平文でＩＭＥＩを移送するＵＲＮ形式を使用してインスタンスＩＤを生成する。
７．ＲＥＧＩＳＴＥＲ要求（ＭＳＣサーバからＩ−ＣＳＣＦに）１３０７：この要求が、プライベートユーザ識別番号、およびホームネットワーク内のＳ−ＣＳＣＦを使ってユーザに代わってこの加入者のために得られた一時的パブリックユーザ識別番号を登録する。この要求は、ホームネットワーク内のＩ−ＣＳＣＦにルーティングされる。図１４のテーブル１４００を参照のこと。
８．Ｃｘ：ユーザ登録状態問合せ手順１３０８：Ｉ−ＣＳＣＦが、プライベートユーザ識別番号、パブリックユーザ識別番号、および訪問したドメイン名をＨＳＳに送信することにより加入者登録状態に関係する情報を要求する。ＨＳＳはＳ−ＣＳＣＦに必要とされる能力を返し、Ｉ−ＣＳＣＦがこの情報を使用して適切なＳ−ＣＳＣＦを選択する。
９．ＲＥＧＩＳＴＥＲ要求（Ｉ−ＣＳＣＦからＳ−ＣＳＣＦに）１３０９：Ｉ−ＣＳＣＦが、選択されたＳ−ＣＳＣＦにＲＥＧＩＳＴＥＲ要求を転送する。
１０．Ｃｘ：Ｓ−ＣＳＣＦ登録通知１３１０：Ｓ−ＣＳＣＦがＨＳＳに、ユーザが登録されたことを通知する。Ｓ−ＣＳＣＦにより要求されると、ＨＳＳはまた、Ｓ−ＣＳＣＦに送信される応答中にユーザプロファイルを含む。
１１．ＧＲＵＵを構築する１３１１：レジストラの役割を果たすＳ−ＣＳＣＦが、ステップ１３０６で送信されたインスタンスＩＤに基づきＧＲＵＵを構築する。ＧＲＵＵは本明細書において説明されるように構築されるものとする。登録中にＤｅｖＩＤが保護されていないときの、レジストラ（Ｓ−ＣＳＣＦ）によるＧＲＵＵ生成のためのステップを参照のこと。図１５のテーブル１５００を参照のこと。
１２．２００（ＯＫ）（Ｓ−ＣＳＣＦからＩ−ＣＳＣＦに）１３１２：Ｓ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＩ−ＣＳＣＦに送信する。２００（ＯＫ）応答は前のステップで生成されたＧＲＵＵを含む。
１３．２００（ＯＫ）（Ｉ−ＣＳＣＦからＭＳＣサーバに）１３１３：Ｉ−ＣＳＣＦが、登録が成功したことを示す２００（ＯＫ）応答をＭＳＣサーバに転送する。

本明細書において上記で理解されるように、本発明は機器とネットワークの間の信号方式のための方法および装置を含む。方法はネットワークにより使用されるインスタンスＩＤと一致するインスタンス身分証明書（ＩＤ）を機器により生成するステップを含む。本発明の装置はネットワークにより使用されるインスタンスＩＤと一致するＩＤを生成する手段を含む。手段は、以下により完全に記載されるように、コンピュータのハードウェアおよびソフトウェア内に実装することができる。方法であれ装置であれ、インスタンスＩＤは、機器に属するがネットワークにも公知の一意の識別子（ＤｅｖＩＤ）に基づく。インスタンスＩＤの生成は、ＤｅｖＩＤを保護するためのハッシュ、およびＤｅｖＩＤをインスタンスＩＤに符号化するときにネットワークと機器の両方により使用される共有名前空間に基づくことができる。一部の例では、インスタンスＩＤが、符号化されていない平文として渡されるＤｅｖＩＤに関する情報を含まない。さらに、本発明では、（ｉ）ネットワーク内のレジストラをインスタンスＩＤを保護するように構成することができ、（ｉｉ）インスタンスＩＤの生成は、ＤｅｖＩＤをＵＲＮとしてインスタンスＩＤの中に直接使用することに基づくことができ、（ｉｉｉ）インスタンスＩＤが、暗号化されていない平文として渡されるＤｅｖＩＤに関する情報を含むことができ、この場合、一実施形態では、ＧＲＵＵの「ｇｒ」のパラメータの生成がＤｅｖＩＤを保護するためのハッシュに基づき、別の実施形態では、ハッシュされたパラメータの生成が、ＤｅｖＩＤと名前空間の連結、およびハッシュアルゴリズムを適用することに基づくことができる。本発明では、インスタンスＩＤはＩＭＥＩ、ＭＥＩＤに、ＮＡＩの形でプライベートユーザＩＤに、またはレジストラにより認識されないＵＲＮ形式に基づくことができる。インスタンスＩＤがＵＲＮ形式に基づく場合、ＧＲＵＵの「ｇｒ」パラメータの生成は未知のＵＲＮ形式を保護するためのハッシュに基づく。

本発明は提案されたソリューションに対して有利な点をいくつか提供する。最も注目に値することには、本発明は、ネットワークにより生成されるどんなインスタンスＩＤも機器により生成されるインスタンスＩＤと同一となることを保証する。これにより、今度は、機器が（直接またはネットワークにより）どのように登録されるかとは無関係に、同じＧＲＵＵが規定されることになる。さらに、本発明は、具体的にはＩＭＳシステムの場合、インスタンスＩＤの生成の概略を述べるための具体的なステップを提供する。このことが現在公開されている既存の３ＧＰＰ仕様のギャップを埋める。本発明はＩＣＳなどのＩＭＳを基にするサービスに対して一貫した動作を保証する。本発明はハッシュを使用して、インスタンスＩＤを得るため、（ＩＭＥＩ、ＭＥＩＤなどの）機器特有識別子が保護される。本発明は機器特有識別子の完全性を保護し、それによって、セキュリティを強化する。

本発明の装置および方法はハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現されることがある。本発明は少なくとも１つのコンピュータシステム内で集中化された方法で、または異なる要素がいくつかの相互接続されたコンピュータシステム全体にわたり散在する分散された方法で実現されることがある。本明細書において記載される方法を実行するために適合された任意の種類のシステムまたは別の装置が適している。ハードウェアとソフトウェアの典型的な組合せは、ロードされ実行されるときにコンピュータプログラムが本明細書において記載される方法を実行するように、コンピュータシステムを制御するコンピュータプログラムを有するコンピュータシステムでもよい。

本発明はまた、本明細書において記載される方法の実現を可能にするすべての特徴を含み、コンピュータシステム内にロードされたときにこれらの方法を実行することができるコンピュータプログラム製品内に組み込まれてもよい。本文脈におけるコンピュータプログラムは、直接、あるいは、以下の、すなわちａ）別の言語、コード、または表記法への変換、ｂ）異なる素材形式での再生のいずれかまたは両方の後に、特定の機能を実行するための情報処理能力を有するシステムをもたらすことを意図した１組の命令の任意の言語での任意の表現、コードまたは表記法を意味する。

ある種の実施形態を参照して本発明を説明したが、本発明の範囲を逸脱することなく様々な変更が行われることがあり、均等物が代用されることがあることが当業者により理解されよう。さらに、本発明の範囲を逸脱することなく本発明の教示に特定の状況または素材を適合させるように多くの修正が行われることがある。したがって、本発明は開示される特定の実施形態に限定されないが、本発明は添付の特許請求の範囲に入るすべての実施形態を含むものである。

Claims (28)

1. 機器とネットワークの間の信号方式のための方法であって、
   ネットワークにより使用されるインスタンス身分証明書（ＩＤ）と一致するインスタンスＩＤを機器により生成するステップ
   を含む方法。
2. 前記インスタンスＩＤが、前記機器に属するが前記ネットワークにも公知の一意の識別子（ＤｅｖＩＤ）に基づく請求項１に記載の方法。
3. 前記インスタンスＩＤの前記生成が、前記ＤｅｖＩＤを保護するためのハッシュ、および前記ＤｅｖＩＤをインスタンスＩＤに符号化するときに前記ネットワークと前記機器の両方により使用される共有名前空間に基づく請求項２に記載の方法。
4. 前記インスタンスＩＤが、暗号化されていない平文として渡される前記ＤｅｖＩＤに関する情報を含まない請求項３に記載の方法。
5. 前記ネットワーク内のレジストラが前記インスタンスＩＤを保護するように構成される請求項３に記載の方法。
6. 前記インスタンスＩＤの前記生成が、前記ＤｅｖＩＤをインスタンスＩＤの中のＵＲＮとして直接使用することに基づく請求項２に記載の方法。
7. 前記インスタンスＩＤが、暗号化されていない平文として渡される前記ＤｅｖＩＤに関する情報を含む請求項６に記載の方法。
8. ＧＲＵＵの「ｇｒ」パラメータの生成が前記ＤｅｖＩＤを保護するためのハッシュに基づく請求項７に記載の方法。
9. 前記ハッシュされたパラメータの前記生成が、前記ＤｅｖＩＤと名前空間の連結、およびハッシュアルゴリズムを適用することに基づく請求項８に記載の方法。
10. 前記インスタンスＩＤがＩＭＥＩに基づく請求項２に記載の方法。
11. 前記インスタンスＩＤがＭＥＩＤに基づく請求項２に記載の方法。
12. 前記インスタンスＩＤがＮＡＩの形のプライベートユーザ識別番号に基づく請求項２に記載の方法。
13. 前記インスタンスＩＤが、前記レジストラに認識されないＵＲＮ形式に基づく請求項２に記載の方法。
14. 前記ＧＲＵＵの前記「ｇｒ」パラメータの前記生成が、前記未知のＵＲＮ形式を保護するためのハッシュに基づく請求項１３に記載の方法。
15. 機器とネットワークの間の信号方式のための装置であって、
    ネットワークにより使用されるインスタンス身分証明書（ＩＤ）と一致するインスタンスＩＤを機器により生成するための手段
    を含む装置。
16. 前記インスタンスＩＤが、前記機器に属すが前記ネットワークにも公知である一意の識別子（ＤｅｖＩＤ）に基づく請求項１５に記載の装置。
17. 前記インスタンスＩＤの前記生成が、前記ＤｅｖＩＤを保護するためのハッシュ、および前記ＤｅｖＩＤをインスタンスＩＤに符号化するときに前記ネットワークと前記機器の両方により使用される共有名前空間に基づく請求項１６に記載の装置。
18. 前記インスタンスＩＤが、暗号化されていない平文として渡される前記ＤｅｖＩＤに関する情報を含まない請求項１７に記載の装置。
19. 前記ネットワーク内のレジストラが前記インスタンスＩＤを保護するように構成される請求項１７に記載の装置。
20. 前記インスタンスＩＤの前記生成が、前記ＤｅｖＩＤをインスタンスＩＤの中のＵＲＮとして直接使用することに基づく請求項１６に記載の装置。
21. 前記インスタンスＩＤが暗号化されていない平文として渡される前記ＤｅｖＩＤに関する情報を含む請求項２０に記載の装置。
22. ＧＲＵＵの「ｇｒ」パラメータの生成が、前記ＤｅｖＩＤを保護するためのハッシュに基づく請求項２１に記載の装置。
23. 前記ハッシュされたパラメータの前記生成が、前記ＤｅｖＩＤと名前空間の連結、およびハッシュアルゴリズムを適用することに基づく請求項２２に記載の装置。
24. 前記インスタンスＩＤがＩＭＥＩに基づく請求項１６に記載の装置。
25. 前記インスタンスＩＤがＭＥＩＤに基づく請求項１６に記載の装置。
26. 前記インスタンスＩＤがＮＡＩの形のプライベートユーザ識別番号に基づく請求項１６に記載の装置。
27. 前記インスタンスＩＤが、前記レジストラにより認識されないＵＲＮ形式に基づく請求項１６に記載の装置。
28. 前記ＧＲＵＵの前記「ｇｒ」パラメータの前記生成が、前記未知のＵＲＮ形式を保護するためのハッシュに基づく請求項２７に記載の装置。

Images