(57)【特許請求の範囲】
【請求項１】
ＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスと、
ＭＴＣサーバと、
前記ＭＴＣデバイスと前記ＭＴＣデバイスとの間でトラヒックを中継するネットワークと、を備え、
前記ＭＴＣデバイスは、前記ＭＴＣサーバへ送信すべきメッセージに、前記メッセージがプライバシー機密情報を包有するか否かを示す第１のフィールドを含め、
前記ネットワークは、
前記第１のフィールドに基づき、前記メッセージが前記プライバシー機密情報を包有するか否かを検証し、
さらに、前記ＭＴＣサーバが前記プライバシー機密情報を前記ＭＴＣデバイスに要求する又は前記ＭＴＣデバイスから受信することを許可されているか否かを検証することにより、前記ＭＴＣサーバを承認し、
前記ＭＴＣサーバを承認した場合に、前記メッセージを前記ＭＴＣサーバへ転送し、
前記ＭＴＣサーバを承認しなかった場合には、前記メッセージを前記ＭＴＣサーバへ転送しない、
システム。
【請求項２】
請求項１において、
前記ネットワークは、
さらに、前記ＭＴＣデバイスが前記プライバシー機密情報を前記ＭＴＣサーバへ送信することを許可されているか否かを検証することにより、前記ＭＴＣデバイスを承認し、
前記ＭＴＣデバイスを承認した場合に、前記メッセージの転送を行い、
前記ＭＴＣデバイスを承認しなかった場合には、前記メッセージの転送を行わない、
ことを特徴としたシステム。
【請求項３】
請求項１又は２において、
前記ネットワークが前記メッセージを前記ＭＴＣデバイスから前記ＭＴＣサーバへ転送するに際して、前記プライバシー機密情報は、前記ＭＴＣデバイスと前記ＭＴＣサーバとの間のセキュア通信により保護される、
ことを特徴としたシステム。
【請求項４】
請求項１〜３のいずれか一項において、
前記プライバシー機密情報は、前記ＭＴＣデバイスの位置情報を含む、
ことを特徴としたシステム。
【請求項５】
請求項１〜４のいずれか一項において、
前記ＭＴＣデバイスは、前記メッセージに、前記ＭＴＣデバイスが緊急時に使用されるデバイスであることを示す第２のフィールドを含め、
前記ネットワークは、
前記第２のフィールドに基づき、前記ＭＴＣデバイスを前記緊急時に使用されるデバイスとして特定し、
前記承認の是非を、前記ＭＴＣデバイスが前記緊急時に使用されるデバイスであることを考慮して決定する、
ことを特徴としたシステム。
【請求項６】
ＭＴＣデバイスとＭＴＣサーバとの間でトラヒックを中継するネットワークを形成するノードであって、
前記ＭＴＣデバイスから、前記ＭＴＣサーバへ送信すべきメッセージであり、当該メッセージがプライバシー機密情報を包有するか否かを示す第１のフィールドを含むメッセージを受信する受信手段と、
前記第１のフィールドに基づき、前記メッセージが前記プライバシー機密情報を包有するか否かを検証する検証手段と、
前記ＭＴＣサーバが前記プライバシー機密情報を前記ＭＴＣデバイスに要求する又は前記ＭＴＣデバイスから受信することを許可されているか否かを検証することにより、前記ＭＴＣサーバを承認する承認手段と、を備え、
前記ＭＴＣサーバを承認した場合に、前記メッセージを前記ＭＴＣサーバへ転送し、
前記ＭＴＣサーバを承認しなかった場合には、前記メッセージを前記ＭＴＣサーバへ転送しない、
ノード。
【請求項７】
請求項６において、
前記承認手段は、前記ＭＴＣデバイスが前記プライバシー機密情報を前記ＭＴＣサーバへ送信することを許可されているか否かを検証することにより、前記ＭＴＣデバイスを承認し、
前記ＭＴＣデバイスを承認した場合に、前記メッセージの転送を行い、
前記ＭＴＣデバイスを承認しなかった場合には、前記メッセージの転送を行わない、
ことを特徴とするノード。
【請求項８】
請求項６又は７において、
前記メッセージを前記ＭＴＣデバイスから前記ＭＴＣサーバへ転送するに際して、前記プライバシー機密情報は、前記ＭＴＣデバイスと前記ＭＴＣサーバとの間のセキュア通信により保護される、
ことを特徴とするノード。
【請求項９】
請求項６〜８のいずれか一項において、
前記メッセージは、前記ＭＴＣデバイスが緊急時に使用されるデバイスであることを示す第２のフィールドをさらに含み、
前記承認手段は、
前記第２のフィールドに基づき、前記ＭＴＣデバイスを前記緊急時に使用されるデバイスとして特定し、
前記承認の是非を、前記ＭＴＣデバイスが前記緊急時に使用されるデバイスであることを考慮して決定する、
ことを特徴とするノード。
【請求項１０】
ＭＴＣデバイスとＭＴＣサーバとの間でトラヒックを中継するネットワークを形成するノードの動作を制御する方法であって、
前記ＭＴＣデバイスから、前記ＭＴＣサーバへ送信すべきメッセージであり、当該メッセージがプライバシー機密情報を包有するか否かを示す第１のフィールドを含むメッセージを受信し、
前記第１のフィールドに基づき、前記メッセージが前記プライバシー機密情報を包有するか否かを検証し、
前記ＭＴＣサーバが前記プライバシー機密情報を前記ＭＴＣデバイスに要求する又は前記ＭＴＣデバイスから受信することを許可されているか否かを検証することにより、前記ＭＴＣサーバを承認し、
前記ＭＴＣサーバを承認した場合に、前記メッセージを前記ＭＴＣサーバへ転送し、
前記ＭＴＣサーバを承認しなかった場合には、前記メッセージを前記ＭＴＣサーバへ転送しない、
ことを含む方法。
【請求項１１】
請求項１０において、
さらに、前記ＭＴＣデバイスが前記プライバシー機密情報を前記ＭＴＣサーバへ送信することを許可されているか否かを検証することにより、前記ＭＴＣデバイスを承認し、
前記ＭＴＣデバイスを承認した場合に、前記メッセージの転送を行い、
前記ＭＴＣデバイスを承認しなかった場合には、前記メッセージの転送を行わない、
ことを特徴とした方法。
【請求項１２】
請求項１０又は１１において、
前記メッセージは、前記ＭＴＣデバイスが緊急時に使用されるデバイスであることを示す第２のフィールドをさらに含み、
前記第２のフィールドに基づき、前記ＭＴＣデバイスを前記緊急時に使用されるデバイスとして特定し、
前記承認の是非を、前記ＭＴＣデバイスが前記緊急時に使用されるデバイスであることを考慮して決定する、
ことを特徴とした方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｍ２Ｍ(ｍａｃｈｉｎｅ−ｔｏ−ｍａｃｈｉｎｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ)におけるセキュリティ及びプライバシー問題に関する。
【背景技術】
【０００２】
プライバシー問題が、３ＧＰＰ(Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)において検討されている。非特許文献３は、“個人にリンクされ得るＭＴＣ(Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ)デバイスの位置情報の(不必要な)収集に因るプライバシー侵害”を開示している(節５．７．２を参照)。
【０００３】
非特許文献３に記載される要件は、“幾つかのタイプのＭＴＣデバイスに対する位置情報のトラッキングを防止可能にすべきこと”である(節５．７３参照)。
【０００４】
このため、Ｍ２Ｍシステムにおいては、位置情報をＭＴＣデバイスからネットワーク及びＭＴＣサーバへセキュアに提供するメカニズムが必要である。
【０００５】
なお、ＭＴＣのためのサービス要件及びシステム改良については、非特許文献１及び２にそれぞれ開示されている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】３ＧＰＰ ＴＲ ２２．３６８、“Ｓｅｒｖｉｃｅ ｒｅｑｕｉｒｅｍｅｎｔｓ ｆｏｒ Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ (ＭＴＣ)； (Ｒｅｌｅａｓｅ １１)”、Ｖ１１．３．０、２０１１年９月、節７．２．１１、頁１６〜１７
【非特許文献２】３ＧＰＰ ＴＲ ２３．８８８、“Ｓｙｓｔｅｍ Ｉｍｐｒｏｖｅｍｅｎｔｓ ｆｏｒ Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎs； (Ｒｅｌｅａｓｅ １１)”、Ｖ１．５．０、２０１１年１０月、節４、頁７〜１７
【非特許文献３】３ＧＰＰ ＴＲ ３３．８６８、“Ｓｅｃｕｒｉｔｙ ａｓｐｅｃｔｓ ｏｆ Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎs (Ｒｅｌｅａｓｅ １１)”、Ｖ０．６．０、２０１１年１１月、節５．７及び７．６、頁１７〜１８及び２９
【発明の概要】
【０００７】
位置情報は、重要であり且つプライバシーに関連するから、必要な時に、認証且つ承認されたＭＴＣサーバへセキュアに提供されるのみであるべきである。
【０００８】
課題は、次の通りに分類され得る。
[１]位置情報は、アタックを防止するために、非承認のＭＴＣサーバへ晒されるべきで無い。
[２]ＭＴＣデバイスは、ネットワーク及び／又はＭＴＣサーバの要求に応じて、位置情報を提供可能である。
[３]不必要な位置情報は、特により高いトラヒック負荷をもたらすから、送信されるべきで無い。
[４]位置情報は、緊急時には、利用可能且つセキュアなべきである。
【０００９】
非特許文献３は、上記課題のためのソリューションを何ら提供していない。これらを達成するために、インタフェースＴ５ａ／Ｔ５ｂ及びＭＴＣｓｐが強化されるべきである。
【００１０】
本発明においては、プライバシーデータを、非特許文献３に記載されるような位置情報に重点を置いて検討する。本発明は、他のプライバシーデータにも同様に適用可能である。
【００１１】
非特許文献３には、ＭＴＣデバイスが、通信を行わない場合にはネットワークからデタッチして、ネットワークによる位置情報の不必要な収集を防止し得る旨記載されている。しかしながら、ＭＴＣデバイスは、接続状態を維持する必要があり得て、位置情報目的のみではデタッチ出来ない。
【００１２】
また、非特許文献３では、“ＭＴＣデバイスは、緊急時に位置トラッキング情報を送信する能力を提供する必要があり得る”と提案されている。本発明においては、この提案に対するソリューションが提供される。
【発明の効果】
【００１３】
本発明によれば、下記の効果１〜４の少なくとも一つを達成することが可能である。
【００１４】
１．位置情報は、ネットワーク及び／又はＭＴＣサーバの要求に応じて必要な時に、承認されたＭＴＣサーバへＭＴＣデバイスからその特性(ｆｅａｔｕｒｅ)と共に提供されるのみである。
２．位置情報は、ネットワーク及びＭＴＣサーバへ送信される間に保護されて、アタックを防止する。
３．位置情報提供機能のスイッチはオフにすることが可能であり、以て不必要な位置情報は提供されないだろうし、ＭＴＣデバイスはネットワークへ接続し続けることが可能であり、トラヒック負荷が低減される。
４．位置情報を、非常時にセキュアに提供可能である。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態に係るシステムの構成例を示したブロック図である。
【図２】本発明の実施の形態に係るシステムの動作例を示したシーケンス図である。
【図３】本発明の実施の形態に係るＭＴＣデバイスの構成例を示したブロック図である。
【図４】本発明の実施の形態に係るノードの構成例を示したブロック図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態を、図１〜図４を参照して説明する。
【００１７】
図１に示すように、本実施の形態に係るシステムは、ＭＴＣデバイス１０として機能するＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)と、ネットワークと、ＭＴＣサーバ２０とを含む。ＭＴＣデバイス１０は、ＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を介してネットワークへ接続される。ネットワークは、ＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ) ３０、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)、ＭＴＣ−ＩＷＦ(Ｉｎｔｅｒｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ) ４０、Ｓ−ＧＷ(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ)、Ｐ−ＧＷ(ＰＤＮ(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ) Ｇａｔｅｗａｙ)等を含む。ＭＭＥ ３０は、ＭＴＣ ＩＷＦ ４０又はＳ−ＧＷ／Ｐ−ＧＷを介して、ＭＴＣサーバ２０へ接続される。
【００１８】
本願の発明者らは、このようなシステムにおいては、次の通りにプライバシー問題に関する脅威があることを見出した。
【００１９】
＜脅威＞
個人にリンクされ得るＭＴＣデバイスの位置情報の(不必要な)収集に因るプライバシー侵害。
【００２０】
その送信を許可されていないＭＴＣデバイスにより送信され、その受信を許可されていないＭＴＣサーバへ向けられるプライバシー機密情報。なお、ＭＴＣデバイスのコンテキストにおいては、識別情報及び位置情報がプライバシー機密情報として考慮され得る。
【００２１】
これらの脅威に対処するため、次のセキュリティ要件を適用する。
【００２２】
＜セキュリティ要件＞
−ネットワークは、メッセージがプライバシー機密情報を包有するか否かを検証可能なべきである。
−ネットワークは、プライバシー機密情報を送信するＭＴＣデバイス、及びプライバシー情報を要求且つ受信するＭＴＣサーバに対するアクセス制御を行うことが可能なべきである。
−ネットワークを介してＭＴＣサーバへ送信されるプライバシー機密情報は、保護されるべきである。
【００２３】
これらのセキュリティ要件を満たすソリューションを、説明する。
【００２４】
＜ソリューション＞
ＭＴＣデバイスは、ネットワークへ接続する必要がある場合、ネットワークと通信し続けることができるように、位置情報を提供する機能のスイッチをオフにすることが可能なべきである。
【００２５】
ネットワークが検証できるように、フィールドを特定のメッセージに追加して、メッセージがプライバシー機密情報を包有するか否かを示すべきである。
【００２６】
また、緊急時におけるプライバシー問題を達成するため、次のセキュリティ要件を適用しても良い。
【００２７】
＜緊急時におけるプライバシー問題に関するセキュリティ要件＞
−ＭＴＣデバイスは、緊急時に、位置情報及び他のプライバシー機密情報をセキュアに提供可能なべきである。
−ネットワークは、緊急時に、プライバシー機密情報を送信するＭＴＣデバイスのアクセス制御を行うことが可能なべきである。
【００２８】
これらのセキュリティ要件を満たすソリューションを、説明する。
【００２９】
＜緊急時のためのソリューション＞
フィールドを特定の緊急メッセージに追加して、緊急用のＭＴＣデバイスであるか否かを示すことが可能である。ネットワークは、ＭＴＣデバイスが緊急時に使用／アクティブ化可能であるか否かを検証する。
【００３０】
セキュリティ保護は、有効であればＮＡＳセキュリティによって提供可能であり、或いはオプション的なソリューションは、ＭＴＣデバイスに緊急用のＵＳＩＭを配備することである。
【００３１】
次に、上記ソリューションの詳細を、図２を参照して説明する。
【００３２】
下記の通りに幾つかの仮定を立てる。
ｉ．ネットワーク及びＭＴＣサーバ２０は、相互認証を有している。
ｉｉ．ＭＴＣデバイス１０及びネットワークは、相互認証を有している。
ｉｉｉ．ＭＴＣデバイス１０及びＭＴＣサーバ２０は、相互認証を有している。
【００３３】
ネットワークは、位置情報がＭＴＣサーバへ送信されることを認識すべきであり、且つ承認を行って、情報を特定のＭＴＣサーバへ送信可能であるか検証すべきである。
【００３４】
上述した課題[１](位置情報が、アタックを防止するために、非承認のＭＴＣサーバへ晒されるべきで無いこと)を達成するための動作は、次の通りである。
ａ)メッセージが位置情報を含むことを示す特別なフィールドを、下記ｂ)〜ｄ)において用いる。
ｂ)位置情報は、ＭＴＣデバイス１０とＭＴＣサーバ２０との間のセキュア通信により保護されるべきである。
ｃ)ネットワークは、下記(ｃ１)、（ｃ２）を検証することにより、ＭＴＣデバイス１０に対する承認を行う(ステップＳ１５)。
(ｃ１)ＭＴＣデバイス１０が、位置情報を提供する機能を有しているか否か
(ｃ２)ＭＴＣデバイス１０が、位置情報を特定のＭＴＣサーバ２０へ送信することを許可されているか否か
ｄ)ネットワークは、下記(ｄ１)を検証することにより、ＭＴＣサーバ２０に対する承認を行う(ステップＳ１５)。
(ｄ１)ＭＴＣサーバ２０が、位置情報を特定のＭＴＣデバイス１０へ要求することを許可されているか否か
【００３５】
上述した課題[２](ＭＴＣデバイスが、ネットワーク及び／又はＭＴＣサーバの要求に応じて、位置情報を提供可能であること)を達成するための動作は、次の通りである。
ａ)アタッチ手順において、ＭＴＣデバイス１０には、位置情報に関連する、許可されたＭＴＣサーバや機能スイッチのＯＮ／ＯＦＦ等のパラメータが与えられる(ステップＳ１及びＳ２)。また、ＭＴＣデバイス１０は、ネットワークへアタッチする度毎にその直後に、位置情報を送信すべきである(ステップＳ３〜Ｓ１４)。これは、ＴＡＵ(Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ)についても同様である。
ｂ)ＭＴＣデバイス１０は、下記(ｂ１)〜(ｂ４)のいずれかにより、位置情報の送信をトリガされることが可能である。
(ｂ１)位置レポート用のタイマ(このタイマは、周期的であるか或いは次回のみのための固定時間である) (ステップＳ５〜Ｓ７)
(ｂ２)承認されたＭＴＣサーバ２０からの要求を伴うトリガメッセージ(ステップＳ８〜Ｓ１０)
(ｂ３)緊急時(ステップＳ１３及びＳ１４)
(ｂ４)ネットワーク／ＭＴＣサーバ２０との合意に応じた位置変更。これは、ＴＡＵ手順においてなされ得る(ステップＳ１１及びＳ１２)。
【００３６】
上述した課題[３](不必要な位置情報が、特にネットワーク負荷を防止するために、送信されるべきで無いこと)を達成するための動作は、次の通りである。
ａ)ＭＴＣデバイス１０は、他の通信のためにネットワークへ接続されている必要がある一方で、トラック又はモニタされるべき位置情報を提供するための機能のスイッチをオフにすることが可能なべきである(ステップＳ１７)。
ｂ)スイッチオフのタイミングは、必要な時にＭＴＣサーバ２０により示され得るか、或いは事前設定された条件、例えば位置情報を提供する度毎のその後のイベントトリガによって決定され得る。
【００３７】
上述した課題[４](位置情報が、緊急時に利用可能且つセキュアなべきであること)を達成するための動作は、次の通りである。
ａ)緊急時(ステップＳ１８)、ＭＴＣデバイス１０は、ＭＭＥ ３０を介した通信を開始し、以て制御信号をＭＴＣサーバ２０へ送信する(ステップＳ２１)。
ｂ)ＭＭＥ ３０は、ＩＭＥＩ(Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ)中の特別なフィールドにより、ＭＴＣデバイス１０が緊急用デバイスであることを特定可能である(ステップＳ２２)。デバイスをＭＴＣデバイスとして特定するための他の方法として、例えばＭＴＣデバイス１０から送信されるパケット中の新たなフィールドが挙げられる。
ｃ)ＭＭＥ ３０は、上記ｂ)を、ＭＴＣ ＩＷＦ ４０又はＳ−ＧＷ／Ｐ−ＧＷを介してＭＴＣサーバ２０へ信号で伝える。
ｄ)ユニークな緊急用ＵＳＩＭｓ(Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅｓ)を配備する。これは、例えば自動車会社へ緊急用ＭＴＣ ＵＳＩＭｓとして販売したＵＳＩＭｓを登録すること、或いは単純に、緊急用ＭＴＣデバイスに関連する特別なＩＭＳＩ(Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ)を伴う特別なＵＳＩＭｓを有することによってなされ得る。
ｅ)プライバシーデータ(位置情報)伝送のセキュリティを、次の方法のいずれか一つにおいて送信可能である。
(ｅ１)緊急用ＵＳＩＭが、プライバシーデータ(位置情報)を保護するためのセキュリティコンテキストを提供し得る(ステップＳ１９)
(ｅ２)ＭＴＣ ＩＷＦ ４０とＭＴＣサーバ２０との間のセキュリティに続く、ＭＴＣデバイス１０とＭＭＥ ３０との間のＮＡＳ(Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ)セキュリティ
(ｅ３)ＭＴＣデバイス１０とＭＴＣサーバ２０との間におけるエンド・ツー・エンドセキュリティ
ｆ)緊急用デバイスであることを示すＭＴＣ識別子や、ＭＴＣデバイス１０→ＭＭＥ ３０→ＭＴＣ ＩＷＦ ４０→ＭＴＣ Ｓｅｒｖｅｒ ２０とのメッセージパスといった、メッセージの緊急コンテンツは新規部分であり得る。
【００３８】
次に、上述した実施の形態に係るＭＴＣデバイス１０及びＭＭＥ ３０の構成例を、図３及び図４を参照して順に説明する。
【００３９】
図３に示すように、ＭＴＣデバイス１０は、包含部１１と、送信部１２と、スイッチオフ部１３とを含む。包含部１１は、メッセージに、課題[１]に関する動作において述べたフィールドを含める。送信部１２は、メッセージを、ＭＭＥ ３０並びにＭＴＣ−ＩＷＦ ４０又はＳ−ＧＷ／Ｐ−ＧＷを介して、ＭＴＣサーバ２０へ送信する。課題[２]に関する動作において述べた通り、送信部１２は、タイマの満了、ＭＴＣサーバ２０から受信したトリガメッセージ、又はＭＴＣデバイスの位置変更をトリガとして、プライバシー機密情報を送出しても良い。課題[３]に関する動作において述べた通り、スイッチオフ部１３は、ＭＭＥ ３０並びにＭＴＣ−ＩＷＦ ４０又はＳ−ＧＷ／Ｐ−ＧＷとのコネクションを維持しつつ、プライバシー機密情報を提供する機能のスイッチをオフにする。緊急時において、包含部１１は、メッセージ又はメッセージ中のＩＭＥＩに、課題[４]に関する動作において述べたフィールドを含める。この時、送信部１２は、プライバシー機密情報を、上述した緊急用ＵＳＩＭ(図示せず)に記憶されるセキュリティコンテキストを用いて保護しても良い。なお、これらのユニット１１〜１３は、バス等を介して相互接続される。これらのユニット１１〜１３は、例えば、ＲＡＮを介してＭＭＥ ３０等と通信するトランシーバと、このトランシーバを制御して、図２に示した処理或いはこれと同等の処理を実行するコントローラと、で構成可能である。
【００４０】
また、図４に示すように、ネットワークを形成するノードの一つであるＭＭＥ ３０は、受信部３１と、検証部３２と、承認部３３と、保護部３４と、特定部３５とを含む。受信部３１は、ＭＴＣデバイス１０から、課題[１]に関する動作において述べたフィールドを含むメッセージを受信する。検証部３２は、このフィールドに基づき、メッセージがプライバシー機密情報を包有するか否かを検証する。承認部３３は、ＭＴＣデバイス１０がプライバシー機密情報をＭＴＣサーバ２０へ送信することを許可されているか否かを検証することにより、ＭＴＣデバイス１０を承認する。また、承認部３３は、ＭＴＣサーバ２０がプライバシー機密情報をＭＴＣデバイス１０に要求する又はＭＴＣデバイス１０から受信することを許可されているか否かを検証することにより、ＭＴＣサーバ２０を承認する。保護部３４は、メッセージをＭＴＣデバイス１０からＭＴＣサーバ２０へ転送するに際して、プライバシー機密情報をセキュアに保護する。緊急時において、受信部３１は、ＭＴＣデバイス１０から、課題[４]に関する動作において述べたフィールドを含むメッセージを受信する。特定部３５は、このフィールドに基づき、ＭＴＣデバイス１０を緊急用デバイスとして特定する。なお、これらのユニット３１〜３５は、バス等を介して相互接続される。これらのユニット３１〜３５は、例えば、ＲＡＮを介してＭＴＣデバイス１０と通信するトランシーバと、ＭＴＣ−ＩＷＦ ４０又はＰ−ＧＷを介してＭＴＣデバイス１０と通信するトランシーバと、これらのトランシーバを制御して、図２に示した処理或いはこれと同等の処理を実行するコントローラと、で構成可能である。
【００４１】
なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。
【００４２】
この出願は、２０１２年１月２７日に出願された日本出願特願２０１２−０１５５７６を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【００４３】
上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【００４４】
(付記１)
メッセージがプライバシーデータ(すなわち、位置情報)を含むことを示す特別なフィールド。
【００４５】
(付記２)
ＭＴＣデバイスが緊急時にアクティブ化可能であることを示す特別なフィールド。
【００４６】
(付記３)
特定のＭＴＣサーバへプライバシーデータを提供しようとするＭＴＣデバイスに対するアクセス制御。
【００４７】
(付記４)
特定のＭＴＣデバイスへプライバシーデータを要求しようとするＭＴＣサーバに対するアクセス制御。
【００４８】
(付記５)
ＭＴＣデバイスへネットワーク及び／又はＭＴＣサーバの要求に応じて位置情報若しくは他のプライバシー機密情報の提供を要求するためのトリガは、タイマ、トリガメッセージ、位置変更であり得る。
【００４９】
(付記６)
位置情報を含むプライバシーデータを、緊急時にセキュアに提供可能である。
【００５０】
(付記７)
ＭＴＣデバイスとＭＴＣサーバとの間にセキュア通信が提供され、そのオプションは、緊急用のユニークなＵＳＩＭ、ＭＴＣ ＩＷＦとＭＴＣサーバとの間のセキュリティに続くＮＡＳセキュリティ、ＭＴＣデバイスとＭＴＣサーバとの間におけるエンド・ツー・エンドセキュリティである。
【００５１】
(付記８)
ＭＴＣデバイスは、ネットワークへの接続し続けることが可能でありながら、例えば位置レポート、モニタリング、トラッキングといった位置情報を送信する機能のスイッチをオフにすることが可能である。
【００５２】
(付記９)
メッセージ中における緊急コンテンツは、緊急用ＭＴＣデバイスであることを示す。
【符号の説明】
【００５３】
１０  ＭＴＣデバイス
１１  包含部
１２  送信部
１３  スイッチオフ部
２０  ＭＴＣサーバ
３０  ＭＭＥ
３１  受信部
３２  検証部
３３  承認部
３４  保護部
３５  特定部
４０  ＭＴＣ−ＩＷＦ
【図１】
0005773074.tif 000002
【図２】
0005773074.tif 000003
【図３】
0005773074.tif 000004
【図４】
0005773074.tif 000005