JP7406512B2 - サービス加入者のプライバシのためのデータ匿名化 - Google Patents

Description

Ｍ２Ｍ／ＩｏＴサービス層（ＳＬ）は、Ｍ２Ｍ／ＩｏＴ機器と、ＩｏＴアプリケーションと、ＩｏＴデータとに対して付加価値サービスを提供することを目的とした技術である。近年、複数の業界標準団体（例えば、ｏｎｅＭ２Ｍ、ＥＴＳＩ、ＯＣＦ、ＬＷＭ２Ｍなど）がＭ２Ｍ／ＩｏＴ ＳＬを開発しており、これによりＭ２Ｍ／ＩｏＴ機器と、アプリケーションと、データとを、インターネット／ウェブ、セルラネットワーク、企業ネットワーク、およびホームネットワークを用いたデプロイメントに統合することに伴う課題の解決を図っている。

本開示の方法とシステムとによりユーザのプライバシを保護する機能を備えたＩｏＴ／Ｍ２Ｍサービス層が提供される。この機能によってＩｏＴ／Ｍ２Ｍサービス層はユーザデータを匿名化することができ、特にユーザデータがサードパーティコンシューマに共有される場合に有効である。プライバシポリシサービスによりＩｏＴサービス層システムが、法的義務や、加入者のプライバシ選好度や、データコンシューマの認証レベルなどの入力情報に基づく匿名化（例えばプライバシの匿名化）ポリシを作成することが可能になる。データ匿名化ポリシはプライバシポリシサービスから出力されてデータ匿名化サービスに送られ、データ匿名化サービスにおいて原データが１つ以上のデータ匿名化ポリシに基づいて匿名化される。データ匿名化サービス機能からの出力情報は、私事化版（例えば、匿名化版）のデータであって、データコンシューマがユーザの１つ以上の識別特徴を発見することを防ぐデータになる。

（図面の簡単な説明）
本出願のより明確な理解を容易にするために添付図面を参照する。各図において、同様の構成要素には同様の参照数字を付している。これらの図面は本出願を限定するものではなく、あくまでも例として示したものである。

図１は、各種のノードにデプロイされたＭ２Ｍ／ＩｏＴサービス層の一例を示すブロック図である。 図２は、ｏｎｅＭ２Ｍアーキテクチャの一例を示すブロック図である。 図３は、ｏｎｅＭ２Ｍにおける共通サービス機能（Common Service Function）の一例を示すブロック図である。 図４は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされた構成の一例を示すブロック図である。 図５は、Ｍ２Ｍサービスの加入者がＭ２Ｍサービスプロバイダに申し込む方法の一例を示すフローチャートである。 図６は、Ｍ２Ｍサービスの加入者がＡＳＰサービスに申し込む方法の一例を示すフローチャートである。 図７は、５Ｇシステムサービスベースのアーキテクチャの一例を示すブロック図である。 図８は、非ローミング５Ｇシステムアーキテクチャの一例を示すブロック図である。 図９は、ＳＭ、ＳＭＳ、およびその他のサービスにおけるＮＡＳトランスポート方法の一例を示すフローチャートである。 図１０は、ネットワークスライシングの方法の一例を示すフローチャートである。 図１１は、Ｍ２Ｍサービス層プラットフォームの一例を示すブロック図である。 図１２は、サービス層におけるユーザプロファイルの作成方法の一例を示すフローチャートである。 図１３は、ユーザプロファイルを機器、アプリケーション、またはサービス層のエンティティとリンクする方法の一例を示すフローチャートである。 図１４は、機器、アプリケーション、またはサービス層の登録の間にユーザプロファイルをリンクする方法の一例を示すフローチャートである。 図１５は、データ匿名化手順の方法例を示すフローチャートである。 図１６は、プライバシサービスを用いてデータ匿名化を行う方法の一例を示すフローチャートである。 図１７は、分散ＤＡＳ設定を用いてデータ匿名化プロセスを行う方法の一例を示すフローチャートである。 図１８は、リンクされたユーザを含むｏｎｅＭ２Ｍリソースツリーにおける機器、アプリケーション、またはサービス層の等価表示の一例を示すブロック図である。 図１９は、ＡＥを介したｏｎｅＭ２Ｍサービス層におけるユーザプロファイルの作成方法の一例を示すフローチャートである。 図２０は、ｏｎｅＭ２Ｍの態様に基づく、ユーザプロファイルを機器、アプリケーション、またはサービス層のエンティティとリンクするユーザリクエストに関連する方法の一例を示すフローチャートである。 図２１は、ｏｎｅＭ２Ｍの態様に基づく、ノード、ＡＥ、またはＣＳＥからの登録リクエストに基づいてユーザプロファイルをノード、ＡＥ、またはＣＳＥとリンクすることに関連する方法の一例を示すフローチャートである。 図２２は、ｏｎｅＭ２Ｍシステムにおけるデータリクエストおよび匿名化されたデータ配信を行う方法の一例を示すフローチャートである。 図２３は、サービス層におけるＰＰＳとＤＡＳとのサービスの一例を示すブロック図である。 図２４は、３ＧＰＰ（Third Generation Partnership Project）システムにおいてサードパーティＡＦがデータをリクエストする方法の一例を示す図である。 図２５Ａは、１つ以上の本開示の実施形態が実施される、マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）の通信システムの一例を示す系統図である。 図２５Ｂは、図２５Ａに示したＭ２Ｍ／ＩｏＴ通信システム内で使用される、アーキテクチャの一例を示す系統図である。 図２５Ｃは、図２５Ａに示した通信システム内で使用される、Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイ機器の一例を示す系統図である。 図２５Ｄは、図２５Ａの通信システムの態様が実施される、コンピュータシステムの一例を示すブロック図である。

Ｍ２Ｍ／ＩｏＴ ＳＬは、アプリケーションや機器に、多数のＭ２Ｍ／ＩｏＴ指向機能へのアクセスを提供する。数種の例として、セキュリティ、課金、データ管理、機器管理、ディスカバリ、プロビジョニング、および接続性管理がある。これらの機能は、Ｍ２Ｍ／ＩｏＴ ＳＬにサポートされたメッセージフォーマット、リソース構造、およびリソース表現を用いるＡＰＩを介して、アプリケーションに利用可能にされる。

プロトコルスタックの面からは、ＳＬは通常アプリケーションプロトコル層の上に位置して該ＳＬがサポートするアプリケーションに付加価値サービスを提供する。このため、ＳＬはしばしば「ミドルウェア」サービスに分類される。表１にアプリケーションプロトコルとアプリケーションとの間に位置したサービス層の一例を示す。

デプロイメントの面では、Ｍ２Ｍ／ＩｏＴ ＳＬは、図１に示すとおり、サーバ、ゲートウェイ、および機器などの様々な種類のネットワークノードにデプロイされる。

Ｍ２Ｍ／ＩｏＴ ＳＬはｏｎｅＭ２Ｍ標準により定義されている（ｏｎｅＭ２Ｍ－ＴＳ－０００１、ｏｎｅＭ２Ｍ機能アーキテクチャ－Ｖ－２．１０．１参照）。このＳＬの目的は、Ｅヘルス、フリート管理、およびスマートホームなどの、様々な「垂直」Ｍ２Ｍシステムならびにアプリケーションに利用可能な「水平」サービスを提供することである。図２に示したｏｎｅＭ２Ｍ ＳＬのアーキテクチャは、４つの基準点をサポートする共通サービスエンティティ（Common Service Entity：ＣＳＥ）を規定している。Ｍｃａ基準点はアプリケーションエンティティ（ＡＥ）とインタフェースで接続している。Ｍｃｃ基準点は同一サービスプロバイダドメイン内の別のＣＳＥとインタフェースで接続し、Ｍｃｃ′基準点は異なるサービスプロバイダドメイン内の別のＣＳＥとインタフェースで接続する。Ｍｃｎ基準点は下位のネットワークサービスエンティティ（ＮＳＥ）とインタフェースで接続する。ＮＳＥは、機器管理、位置情報サービス、および機器トリガリングなどの下位ネットワークサービスをＣＳＥに提供する。ＣＳＥは、「ディスカバリ」や「データ管理リポジトリ」などの「共通サービス機能（Common Service Functions：ＣＳＦ）」と呼ばれる複数の論理機能を含んでいる。図３にｏｎｅＭ２ＭにサポートされたＣＳＦを示す。

ｏｎｅＭ２Ｍアーキテクチャは、以下に例示した各ノード種にＭ２Ｍ／ＩｏＴサービスを分散してデプロイすることをサポートする分散アーキテクチャである。

アプリケーションサービスノード（Application Service Node：ＡＳＮ）
ＡＳＮは、１つのＣＳＥと少なくとも１つのアプリケーションエンティティ（ＡＥ）とを含むノードである。物理マッピングの一例においてＡＳＮはＭ２Ｍ機器内に位置する。

アプリケーション専用ノード（Application Dedicated Node：ＡＤＮ）
ＡＤＮは、少なくとも１つのＡＥを含んでＣＳＥを含まないノードである。物理マッピングの一例においてアプリケーション専用ノードは制限付きＭ２Ｍ機器内に位置する。

ミドルノード（Middle Node：ＭＮ）
ＭＮは１つのＣＳＥを含むと共に、１つ以上のＡＥを含むもしくは含まないノードである。物理マッピングの一例においてＭＮはＭ２Ｍゲートウェイに位置する。

インフラストラクチャノード（Infrastructure Node：ＩＮ）
ＩＮは１つのＣＳＥを含むと共に、１つ以上のＡＥを含むもしくは含まないノードである。ＩＮのＣＳＥは、他種のノードには適用できないＣＳＥ機能を含む。物理マッピングの一例においてＩＮはＭ２Ｍサービスインフラストラクチャに位置する。

非ｏｎｅＭ２Ｍノード（Non-oneM2M Node：ＮｏＤＮ）
非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを含まない（ＡＥとＣＳＥとのいずれも含まない）ノードである。これらのノードは、管理などのインターワーキングのためにｏｎｅＭ２Ｍシステムにアタッチされた機器を表している。

ｏｎｅＭ２Ｍシステム内でサポートされた様々なエンティティのあり得る相互接続形態を図４に示す。

現在のｏｎｅＭ２Ｍ／ＩｏＴシステムは、プライバシ保護管理（ＰＰＭ）と呼ばれるプライバシの管理機能を備えている。「プライベートであるもの」が表現するものは、個人の見解と、社会規範と、行政機関から課せられたポリシとによって異なってくる。ＰＰＭ機能はユーザの選好度に基づいてアクセス制御ポリシを作成し、これにより認証された者だけがユーザの個人特定情報（ＰＩＩ）にアクセスすることができるようになる。しかし、これらのポリシは、ユーザデータが匿名化（例えば、サニタイズ、別名化、省略など）される粒度へのアクセス制御は提供するものではない。Ｍ２Ｍ／ＩｏＴサービス層にこのようなレベルまでユーザのプライバシを保護することが可能な機能をもたせる方法とシステムとが本明細書で開示される。以下に述べるプライバシ保護アーキテクチャの説明は、Ｓｅｃｕｒｉｔｙ Ｓｏｌｕｔｉｏｎｓ－Ｖ－３．０．６のｏｎｅＭ２Ｍ－ＴＳ－０００３の１１節からの引用である。

Ｍ２Ｍのアプリケーションサービスプロバイダ（ＡＳＰ）はＭ２Ｍサービスプロバイダと加入契約を交わした者と定義される。Ｍ２Ｍ／ＩｏＴサービスプロバイダを介してＡＳＰにより提供されるサービスに加入するエンティティはＭ２Ｍサービス加入者と呼ばれる。

サードパーティデータコンシューマはＭ２ＭサービスプロバイダからのＭ２Ｍサービス加入者のデータの入手を望んでいる。このとき、サードパーティデータコンシューマはＡＳＰとして振る舞う。ｏｎｅＭ２ＭセキュリティＣＳＦ内のプライバシポリシマネージャ（ＰＰＭ）機能がＭ２Ｍサービス加入者のプライバシ選好度に基づく個人データ管理フレームワークになり、これによりＭ２Ｍサービス加入者に合意されたポリシからアクセス制御情報が作成される。ＰＰＭは、非認証者と非認証集団とからＭ２Ｍサービス加入者の個人データを保護する。ＰＰＭは、Ｍ２Ｍサービスプロバイダ自身またはＭ２Ｍサービスプロバイダに代わる他のエンティティによって管理される。

Ｍ２ＭサービスプロバイダがＭ２Ｍサービス加入者の個人データをサードパーティのＭ２Ｍのアプリケーションサービスプロバイダ（ＡＳＰ）に提供する場合、Ｍ２ＭサービスプロバイダはＭ２Ｍサービス加入者の承諾を得る必要がある。データが属するエンティティはデータ主体と呼ばれる。つまり、Ｍ２Ｍサービス加入者がデータを供給するデータ主体になる。Ｍ２Ｍサービス加入者がサードパーティへの提供を示すプライバシポリシを承認した場合は、Ｍ２Ｍサービスプロバイダはデータ主体の個人データを該サードパーティに提供することができる。しかし、プライバシポリシがサードパーティへの提供を示していない場合は、サービスプロバイダはプライバシポリシを更新してそのポリシに対するＭ２Ｍサービス加入者の承諾を得る必要がある。

ＰＰＭはプライバシ選好度とプライバシポリシとを管理する。

プライバシ選好度とは、Ｍ２Ｍサービス加入者が自身の個人データをサードパーティに提供することについての選好度のことである。Ｍ２Ｍサービス加入者はＭ２Ｍサービス加入者のプライバシ選好度を作成してＰＰＭに登録する。プライバシ属性のリストの例がｏｎｅＭ２Ｍ－ＴＳ－０００３の付録Ｊに記載されている。

プライバシポリシには、Ｍ２ＭサービスプロバイダがＭ２Ｍサービス加入者にサービスを提供するために必要な個人データが示されている。Ｍ２Ｍサービスプロバイダはプライバシポリシを作成してＰＰＭに登録する。

ＰＰＭは以下の機能の１つ以上を実行するように構成される。

（１）Ｍ２Ｍサービス加入者のプライバシ選好度をＡＳＰのプライバシポリシに合わせるための高度な同意手順。プライバシポリシは、Ｍ２ＭサービスプロバイダがＭ２Ｍサービス加入者にサービスを提供するために必要な個人データを記述している。Ｍ２Ｍサービス加入者が、Ｍ２Ｍサービスプロバイダが提供するサービスに加入する場合、Ｍ２Ｍサービスプロバイダは該サービスのプライバシポリシに対するＭ２Ｍサービス加入者の同意を得る必要がある。ＰＰＭは、プライバシ選好度とプライバシポリシとを比較することによってＭ２Ｍサービス加入者に使いやすい同意手順を提供する。

（２）分散認証におけるポリシ判定ポイント（ＰＤＰ）ならびにポリシ検索ポイント（ＰＲＰ）と、「アクセス制御ポリシ（AccessControlPolicy）」リソースの管理と、ダイナミック認証システムサーバ（ＤＡＳＳ）との機能を以下に説明する。

（ａ）ＰＤＰ
発信者がポリシ実施ポイント（ＰＥＰ）となるホスティングＣＳＥから個人データをリクエストすると、ホスティングＣＳＥはＰＤＰとなるＰＰＭからアクセス制御決定データをリクエストする。ＰＰＭは、Ｍ２Ｍサービス加入者の同意を得たポリシから作成されたアクセス制御情報から「認証決定（authorizationDecision）」リソースを作成し、その「認証決定」リソースの表示をもってホスティングＣＳＥに応答する。ＰＤＰと「認証決定」との詳細はそれぞれＴＳ－０００３の７．５．２節とＴＳ－０００１の９．６．４２節とに記載されている。

（ｂ）ＰＲＰ
発信者がＰＤＰとなるホスティングＣＳＥから個人データをリクエストすると、ホスティングＣＳＥはＰＲＰとなるＰＰＭからアクセス制御ポリシをリクエストする。ＰＰＭは、Ｍ２Ｍサービス加入者の同意を得たポリシに基づいて「認証ポリシ（authorizationPolicy）」リソースを作成し、その「認証ポリシ」リソースの表示をもってホスティングＣＳＥに応答する。ＰＲＰと「認証ポリシ」との詳細はそれぞれＴＳ－０００３の７．５．３節とＴＳ－０００１の９．６．４３節とに記載されている。

（ｃ）ＣＳＥがホストとなる「アクセス制御ポリシ（accessControlPolicy）リソース」の管理
発信者がホスティングＣＳＥから個人データをリクエストし、このＣＳＥがローカル保存された「アクセス制御ポリシ」リソースを用いて７．１節（ＴＳ－０００３）に記載された手順によりアクセス制御決定を導くと、ＰＰＭは、ＩＮ－ＡＥであって、要求された「アクセス制御ポリシ」リソースを生成して各ＣＳＥにデプロイし、かつ適切なアクセス制御ポリシＩＤの属性をＭ２Ｍサービス加入者が作成したリソースに割り当てるＩＮ－ＡＥとして機能する。

（ｄ）ダイナミック認証システム

（ｉ）直接ダイナミック認証
発信者がホスティングＣＳＥに個人データをリクエストすると、ホスティングＣＳＥは「ダイナミックＡＣＰ情報（dynamicACPInfo）」リソースまたは「トークン（token）」リソースをＰＰＭにリクエストする。ＰＰＭは、Ｍ２Ｍサービス加入者の同意を得たポリシに基づいて「ダイナミックＡＣＰ情報」リソースまたは「トークン」リソースを作成し、「ダイナミックＡＣＰ情報」リソースまたは「トークン」リソースの表示をもってホスティングＣＳＥに応答する。直接ダイナミック認証の詳細はＴＳ－０００３の７．３．２．２節に記載されている。「ダイナミックＡＣＰ情報」リソースと「トークン」リソースとの詳細はそれぞれＴＳ－０００１の９．６．４０節と９．６．３９節とに記載されている。

（ｉｉ）間接ダイナミック認証
ある発信者がホスティングＣＳＥに個人データをリクエストする前に、その発信者は「トークン」リソースまたはトークンＩＤをＰＰＭにリクエストする。ＰＰＭは、Ｍ２Ｍサービス加入者の同意を得たポリシに基づいて「トークン」リソースを作成し、「トークン」リソースの表示またはトークンＩＤをもって発信者に応答する。次いで、発信者は「トークン」リソースまたはトークンＩＤを用いてホスティングＣＳＥに個人データをリクエストする。間接ダイナミック認証の詳細はＴＳ－０００３の７．３．２．３節に記載されている。

（３）個人データの使われ方のトレーサビリティ
ＰＰＭは、どの発信者がどの種類の収集データにアクセスしたかを記録したアクセスログを保存している。この機能はｏｎｅＭ２Ｍにおける今後の研究課題であるが、同機能はｏｎｅＭ２Ｍで定義されたコンポーネントを用いて実装することができる。

ＰＰＭは、Ｍ２Ｍサービス加入者の選好度とＭ２Ｍアプリケーションサービスプロバイダのサービスプライバシポリシとを管理するように構成される。基本的に、Ｍ２Ｍアプリケーションサービスプロバイダはインフラストラクチャドメインに１つのＰＰＭを備え、そのＰＰＭにおけるＭ２Ｍサービス加入者の同意のステータスを管理する。ＰＰＭの使用には、以下の関係を有する４つの手順がある。

Ｍ２Ｍサービス加入者が、Ｍ２Ｍサービスプロバイダが提供するサービスに加入する。

Ｍ２Ｍサービス加入者が、ＡＳＰが提供するサービスに加入する。

ＡＥ（ＩＮ－ＡＥまたはフィールドドメインＡＥ）がホスティングＣＳＥに保存された個人データをリクエストする。

Ｍ２Ｍサービス加入者が自身の個人データのアクセスログをチェックし、収集された個人データをホスティングＣＳＥから削除するようにリクエストする。

上記手順を用いるいくつかの関連エンティティを以下に示す。

（１）Ｍ２Ｍサービス加入者
Ｍ２Ｍサービス加入者は、Ｍ２Ｍサービスプロバイダに扱われる情報へのアクセスを制御する機能を提供する、ＡＳＰのサービスに加入することによってＭ２Ｍサービスを利用することができる。個人データは、個人特定情報（ＰＩＩ）を作成するためにそのままでまたは個人を特定する他の情報と併せて使用される。

（２）ＡＤＮ－ＡＥ、ＡＳＮ－ＡＥ
ＡＤＮ－ＡＥまたはＡＳＮ－ＡＥは、センサデータなどの様々な種類のデータを作成する。さらにＡＤＮ－ＡＥまたはＡＳＮ－ＡＥは、リソースのホスティングＣＳＥにデータをリクエストする。

（３）ホスティングＣＳＥ
ホスティングＣＳＥがＰＰＭをＰＤＰとして用いる場合は、ホスティングＣＳＥはポリシ実施ポイント（ＰＥＰ）として機能する。ホスティングＣＳＥがＰＰＭをＰＲＰとして用いる場合は、ホスティングＣＳＥはＰＤＰとして機能する。ホスティングＣＳＥがＰＰＭをＤＡＳとして用いる場合は、ホスティングＣＳＥは、リクエストされたリソースにリンクされた「ダイナミック認証コンサルテーション（dynamicAuthorizationConsultation）リソースを設定する。

（４）アプリケーションサービスプロバイダ
アプリケーションサービスプロバイダは、Ｍ２Ｍサービスプロバイダに加入しているＭ２Ｍサービス加入者にサービスを提供する。

（５）Ｍ２Ｍサービスプロバイダ
Ｍ２Ｍポータルが、Ｍ２Ｍサービス加入者インタフェースであって、このインタフェースを通じてＭ２Ｍプラットフォームが提供するサービスが管理されるインタフェースを提供する。

（６）ＰＰＭ
ＰＰＭは、（ｏｎｅＭ２Ｍによって定義されていない）自動化手順であって、Ｍ２Ｍサービス加入者の同意を得たポリシと選好度とに基づいてアクセス制御ポリシを作成してそのポリシをＣＳＥにデプロイする、自動化手順の機能を備えている。ＰＰＭがＰＤＰまたはＰＲＰとして機能する場合は、ＰＰＭはＣＳＥ機能を要求する。ＰＰＭがダイナミック認証サービスサーバとして機能する場合は、ＰＰＭはＡＥ機能を要求する。ＰＰＭはＰＰＭポータルを介してＭ２Ｍサービス加入者インタフェースを提供する。Ｍ２Ｍサービス加入者はＰＰＭポータルにアクセスしてＭ２Ｍサービス加入者のプライバシ選好度を設定する。ＰＰＭポータルはｏｎｅＭ２Ｍの範囲外にある。

ここでＰＰＭアーキテクチャにおける管理フローの一例を説明する。Ｍ２Ｍサービス加入者がＭ２Ｍサービスプロバイダに加入すると、Ｍ２Ｍサービス加入者はＰＰＭを用いてプライバシ選好度を設定する。プライバシの選好度／ポリシが、どのデータがＡＳＰによって使用されることになっていて、かつ同意により他のサービス加入者と共有されることを許可されているか、を説明する。プロセスの一例を図５に示す。

ステップ１で、Ｍ２Ｍサービス加入者はＭ２ＭサービスプロバイダのＭ２Ｍポータルにアクセスする。このプロセスは通常ＨＴＴＰやＨＴＴＰＳなどのＷｅｂアクセスプロトコルを用いて行われる。

ステップ２で、Ｍ２Ｍサービス加入者はプライバシ選好度を設定してＰＰＭポータルに登録する。Ｍ２Ｍサービス加入者がＰＰＭポータルにアクセスする。またはＭ２ＭポータルがＭ２ＭサービスプロバイダをＰＰＭポータルにリダイレクトする。このプロセスはＷｅｂアクセスプロトコルを用いて行われる。

ステップ３で、Ｍ２ＭサービスプロバイダがＭ２Ｍサービス加入者からデータを集めて保存する。

Ｍ２Ｍサービス加入者はＭ２Ｍサービスプロバイダを通じてＡＳＰが提供する様々な種類のサービスに加入することができる。サービスのリストがＭ２Ｍポータルに登録されていて、Ｍ２Ｍサービス加入者は加入するサービスを選択することができる。Ｍ２Ｍサービス加入者がサービスに加入する場合、そのＭ２Ｍサービス加入者はＡＳＰのプライバシポリシを承認する必要がある。Ｍ２Ｍサービス加入者がこのポリシを容易に理解するために、ＰＰＭは、ＡＳＰが提供するプライバシポリシとＭ２Ｍサービス加入者のプライバシ選好度とに基づいて、カスタマイズされたプライバシポリシを作成してもよい。このため、Ｍ２Ｍサービス加入者は個人データをコントロールすることが可能になり、合意にはプライバシポリシを理解したことが含意されている。図６にこのプロセスの概略例を示す。

ステップ１で、Ｍ２Ｍサービス加入者はＭ２Ｍポータルにアクセスして加入するＡＳＰのサービスを選択する。Ｍ２Ｍポータルが、Ｍ２Ｍサービス加入者の同意を得るためにＰＰＭポータルにリダイレクトする。この処理は通常ＨＴＴＰやＨＴＴＰＳなどのＷｅｂアクセスプロトコルを用いて行われる。

ステップ２で、Ｍ２Ｍサービス加入者はＡＳＰのサービスに加入するためにプライバシポリシを承認する必要がある。ＰＰＭは、Ｍ２Ｍサービス加入者のプライバシ選好度とサービスのプライバシポリシとに基づいて各Ｍ２Ｍサービス加入者に対するカスタマイズされたプライバシポリシを作成する。Ｍ２Ｍサービス加入者が、プライバシ選好度とプライバシポリシとの差異を確認して、どの種類の個人データがＡＳＰに収集されているかを把握することは容易である。Ｍ２Ｍサービス加入者はプライバシポリシを承認した後、ＡＳＰのサービスに加入することができる。

ステップ３で、ＰＰＭは、Ｍ２Ｍサービス加入者が承認したプライバシポリシを用いてアクセス制御ポリシを作成または更新する。

４種の移植のオプションがＴＳ－０００３－Ｖ３．６．０に示されている。それらオプションを下記に示す。

（１）ＰＰＭがＰＤＰとして機能する。

（２）ＰＰＭがＰＲＰとして機能する。

（３）ＰＰＭが下記の（ａ）、（ｂ）いずれかを用いてダイナミック認証システムサーバ（ＤＡＳＳ）として機能する。

（ａ）直接ダイナミック認証

（ｂ）間接ダイナミック認証

ＰＰＭは、ユーザが自身のプライバシ選好度を表示できるように構成されたデータ管理フレームワークである。ユーザの個人特定情報（ＰＩＩ）は、ユーザのプライバシ選好度を考慮して設定されたアクセス制御ポリシによって敵対者や非認証者から保護される。ＰＰＭは、Ｍ２Ｍサービスプロバイダまたは他の信頼できるステークホルダによって管理される。サービスプロバイダや信頼できるステークホルダは、当該ユーザのＰＩＩをサードパーティと共有するために、そのＰＩＩを共有することについてユーザの了解を得る必要がある。プライバシポリシにはサードパーティに関する規定が含まれている。

サービスプロバイダが提供するサービスに加入するエンドユーザがデータ主体になる。データ主体はプライバシ選好度のテンプレートを有している。データ主体がサービスに加入しようとする場合、データ主体はプライバシ選好度テンプレートをＰＰＭポータルからダウンロードし、そのテンプレートを自らのテンプレートと比較して整合しているかどうかを確認する。エンドユーザが自身のプライバシ選好度を表す属性を選択および選択解除した後、そのプライバシ選好度が同一のポータルを用いてＰＰＭに登録される。

ｏｎｅＭ２Ｍでは、ＰＰＭは２つの機能を果たす。第１に、ＰＰＭはポリシ判定ポイント（ＰＤＰ）として機能する。この場合、アプリケーションがＩＮ－ＣＳＥに個人データをリクエストすると、ＰＰＭはユーザのプライバシ選好度に基づくアクセス判定で応答する。第２に、ＰＰＭはポリシ検索ポイント（ＰＲＰ）として機能する。ＰＤＰがＰＰＭにアクセス制御ポリシをリクエスト可能な状態で、アプリケーションがＩＮ－ＣＳＥに個人データをリクエストすると、ＰＰＭはユーザのプライバシ選好度に基づくアクセス制御ポリシで応答する。

ｏｎｅＭ２Ｍサービス層において、Ｒｅｇｉｓｔｒａｔｉｏｎ（ＲＥＧ）ＣＳＦは、レジストラＣＳＥを用いて登録するようにＡＥまたは他のＣＳＥからのリクエストを処理して、登録されたエンティティがレジストラＣＳＥにより提出されたサービスを使えるようにする。

Ｒｅｇｉｓｔｒａｔｉｏｎは、登録するエンティティがＡＥである場合はそのエンティティが「ＡＥ」リソースを作成するプロセスになり、ＣＳＥを登録する場合は「リモートＣＳＥ」を作成するプロセスになる。登録の更新がある場合は、これらのリソースも更新される。

Ｒｅｇｉｓｔｒａｔｉｏｎとは、ＡＥまたはＣＳＥ情報を別のＣＳＥに送ってそのＣＳＥがＭ２Ｍサービスを使えるようにするプロセスである。ＡＳＮ、ＭＮ、またはＩＮのＡＥは、対応するＣＳＥへの局所的な登録を行って、そのＣＳＥが提出したＭ２Ｍサービスを使えるようにする。ＡＤＮのＡＥは、ＭＮまたはＩＮにおけるＣＳＥへの登録を行って、そのＣＳＥが提出したＭ２Ｍサービスを使えるようにする。ＩＮ－ＡＥは、ＩＮでの対応するＣＳＥへの登録を行って、そのＣＳＥが提出したＭ２Ｍサービスを使えるようにする。ＡＥは、自身のレジストラＣＳＥが対象ＣＳＥである場合、そのレジストラＣＳＥを他のＣＳＥに登録させることなく該レジストラＣＳＥとインタラクションすることができる。ＡＳＮのＣＳＥは、ＭＮ内のＣＳＥへの登録を行って、そのＭＮのＣＳＥが提出したＭ２Ｍサービスを使えるようにする。ＭＮ－ＣＳＥにＡＳＮ－ＣＳＥが登録されると、ＡＳＮとＭＮとにおけるＣＳＥ同士の間に情報交換可能な関係が確立する。

ＭＮのＣＳＥは、他のＭＮのＣＳＥへの登録を行って、そのＭＮのＣＳＥが提出したＭ２Ｍサービスを使えるようにする。ＭＮ－ＣＳＥが他のＭＮ－ＣＳＥに登録されると、これらＭＮのＣＳＥ同士の間に情報交換可能な関係が確立する。ＡＳＮまたはＭＮのＣＳＥは、ＩＮのＣＳＥへの登録を行って、そのＩＮのＣＳＥが提出したＭ２Ｍサービスを使えるようにする。ＡＳＮ／ＭＮがＩＮ－ＣＳＥに登録されると、これらＡＳＮ／ＭＮとＩＮとのＣＳＥ間に情報交換可能な関係が確立する。

ｏｎｅＭ２ＭプラットフォームはＩｏＴ機器がスマート機器であることを想定している。したがって、登録プロセスの一部として、ＩｏＴ機器の仮想表示をｏｎｅＭ２Ｍサービスプロバイダプラットフォーム（oneM2M Service Provider platform）に形成することができる。

ｏｎｅＭ２ＭはこれらＩｏＴ機器のユーザや所有権を認識していない。しかし、実生活のシナリオでは、個人ユーザや組織体はこれら機器に対し責任をもって管理する必要がある。また、シナリオによっては、機器が個人ユーザの所有物あるいは組織体の資産になっているが、他のユーザまたは組織体に貸し出されていることもある。それらのシナリオでは、ユーザまたは加入者のプロファイルがサービス層に認識されるようにされる。本開示のユーザプロファイルはユーザのアカウント情報を含んでいる。例えば、このアカウント情報は、ユーザ名と、ユーザＩＤと、所在地と、所有機器とを含んでいる。

５Ｇモバイルコアネットワークアーキテクチャ（5G Mobile Core Network Architecture）が「３ＧＰＰ ＴＳ ２３．５０１、５Ｇシステムのシステムアーキテクチャ、ステージ２、ｖ１．２．０、１５版」に規定されている。図７に、制御プレーン内のサービスベースのインタフェースを備えた非ローミング参照アーキテクチャを示す。図８に、非ローミングの場合の５Ｇシステムアーキテクチャを、様々なネットワーク機能がどのように相互作用しているかを示す参照点表示を用いて示す。

モビリティ管理機能とセッション管理機能とが分かれていることは注目に値する。１つのＮ１ ＮＡＳ コネクションを用いて、登録管理（Registration Management）とコネクション管理（Connection Management）との両方（ＲＭ／ＣＭ）およびＵＥ向けのＳＭ関連メッセージおよび手順が行われる。１つのＮ１の終端点はＡＭＦに位置している。ＡＭＦはＳＭ関連のＮＡＳ情報をＳＭＦに転送する。ＡＭＦは、ＵＥと取り交わしたＮＡＳ信号の登録管理とコネクション管理との部分を扱う。ＳＭＦは、ＵＥと取り交わしたＮＡＳ信号のセッション管理部分を扱う。

３ＧＰＰ ＴＳ ２３．５０１に記載されているとおり、５ＧＣは、サードパーティアプリケーションサーバおよび他のＮＦから分析情報を収集する、ＮＷＤＡネットワーク機能を備えている。また、ＮＷＤＡは分析情報を他のＮＦおよびサードパーティアプリケーションサーバに提供する。サードパーティアプリケーションサーバとＮＦとは分析情報を用いてネットワーク構成、データ経路、通信ポリシなどを最適化することができる。

１つのＮ１ ＮＡＳコネクションが、ＵＥが接続される各アクセスに用いられる。１つのＮ１終端点がＡＭＦに位置する。上記１つのＮ１ ＮＡＳコネクションは、登録管理とコネクション管理との両方（ＲＭ／ＣＭ）ならびにＵＥ向けのＳＭに関するメッセージおよび手順に使用される。Ｎ１におけるＮＡＳプロトコルは、ＮＡＳ－ＭＭコンポーネントとＮＡＳ－ＳＭコンポーネントとからなる。 図９に、Ｎ１インタフェースを介したＵＥと５Ｇコアネットワーク間（例えば、ＵＥとＡＭＦ間）における一般的なプロトコルスタックを示す。

ネットワークスライシングはモバイルネットワークオペレータにより使用される手順であって、モバイルオペレータのネットワークの固定部と、バックホールとコアネットワークとの両方とにわたるエアインタフェースの背後の複数の「仮想」ネットワークをサポートする手順である（ＮＧＭＮ（Next Generation Mobile Networks）協定「ネットワークスライシングの概念の解説」参照）。この手順には、種々のＲＡＮをサポート、または１つのＲＡＮで作動する種々のサービスタイプをサポートするためにネットワークを複数の仮想ネットワークに「スライスすること」が含まれている。ネットワークスライシングによりオペレータは、多様な要件（例えば、機能、性能、および分離の面での要件）が求められる様々な市場シナリオに対して最適なソリューションを与えるようにカスタマイズされた複数のネットワークを形成することができる。

図１０にネットワークスライシングのアーキテクチャの一例を示す。ネットワークスライスインスタンスは一連のネットワーク機能とそれらネットワーク機能を実行するリソースで構成される。種々の色を用いて種々のネットワークスライスインスタンスまたはサブネットワークスライスインスタンスが示されている。サブネットワークスライスインスタンスは一連のネットワーク機能とそれらネットワーク機能を実行するリソースで構成されるが、それ自体は完全な論理ネットワークになっていない。サブネットワークスライスインスタンスは複数のネットワークスライスインスタンスに共有され得る。

３ＧＰＰ ５Ｇネットワークはネットワークスライシング技術を組み込んでいる。この技術は５Ｇネットワークによく適合する。この理由は、５Ｇユースケース（例えば、大規模なＩｏＴ、限界的な通信、および高度化モバイルブロードバンドなど）ではきわめて多様でかつ時に極端な条件が要求されるためである。現在のｐｒｅ－５Ｇアーキテクチャでは、比較的モノリシックなネットワークとトランスポートフレームワークとを用いて、スマートフォン、ＯＴＴ（Over The Top）コンテンツ、フィーチャフォン、データカード、および組み込みＭ２Ｍ機器からのモバイルトラヒックなどの多様なサービスに適応するようになっている。現在のアーキテクチャは、広範囲のビジネスニーズのそれぞれが特有の性能、拡張性、および可用性の要件のセットを有している場合に、そのビジネスニーズを効率よくサポートする上で十分な順応性と拡張性とを有していないと思われる。さらに、新しいネットワークサービスの導入をより効率的に行う必要がある。それにもかかわらず、複数のユースケースが同じオペレータネットワークで同時に進行していて、そのために高度な５Ｇネットワークの順応性と拡張性が必要になっていると思われる。

ネットワークスライシングによりオペレータは、多様な要件（例えば、機能、性能、および分離の面での要件）が求められる様々な市場シナリオに対して最適なソリューションを与えるようにカスタマイズされた複数のネットワークを形成することができる。しかし、今後の５Ｇネットワークでネットワークスライシングをサポートするにはいくつかの課題がある。上記課題の例として以下のものがある。ただし、これに限定するものではない。

ネットワークスライスインスタンス間の分離をどのように行うか、またどのレベルおよび種類の分離が必要か。

どのようにして、またどのタイプの、リソースおよびネットワーク機能の共有をネットワークスライスインスタンス間で用いることができるか。

どのようにしてＵＥは１オペレータの１つ以上の特定ネットワークスライスインスタンスから同時にサービスを得ることができるか。

ネットワークスライシングに関して３ＧＰＰの範囲に含まれるものは何か（例えば、ネットワークスライスの形成／構成、変更、削除など）。

どのネットワーク機能が特定のネットワークスライスインスタンスに含まれるか、またどのネットワーク機能がネットワークスライスから独立しているか。

ＵＥ向けの特定のネットワークスライスの選択手順。

ネットワークスライシングローミング（Network Slicing Roaming）シナリオのサポート方法。

どのようにして、オペレータがネットワークスライシングの概念を用いて、類似のネットワーク特性を要する複数のサードパーティ（例えば、企業、サービスプロバイダ、コンテンツプロバイダなど）を効率よくサポートできるようにするか。

前述のプライバシポリシ管理（ＰＰＭ）アーキテクチャは、方法であって、その方法により認証された者だけが加入者／ユーザの個人特定情報（ＰＩＩ）にアクセスを許可される方法を提供するものである。上記認証ポリシはユーザ選好度とＡＳＰのプライバシポリシとに基づいてビルドされる。ユーザデータを選択的に匿名化することが可能な方法とシステムとが本明細書で開示される。本提案の技術は、データのサニタイズ、省略、および置き換えなどのデータ匿名化方法を含むものである。

全てのデータには価値がある。あるデータが匿名化される場合、データの一部が隠されるかまたはデータコンシューマが個人情報を見たり確認したりできないように処理される。データを匿名化すると、情報の一部が失われるのでその分だけデータの価値が下がる。しかし、法的要件を満たすため、および／または人々が満足してデータを共有するために、データの匿名化が時に必要になる。例えば、自治体がデータを集めてそのデータをデータコンシューマ（例えば、広告者など）に利用できるようにする場合、プライバシの問題が生じてくる。データマーケットプレイスまたはデータプラットフォームのデプロイに対するプライバシ関連の法的かつ政治的障壁に対処するために、データプラットフォームはプライバシをサービスとして提供できる必要がある。最低でも、プライバシサービスは、ユーザのポリシとサービスプロバイダのポリシとに基づく一定程度のプライバシを提供できることが必要である。ユーザのポリシは、データに関連するユーザの個人的選好度に基づくものであり、サービスプロバイダのポリシはそのサービスプロバイダの内部業務方針と法的要件とに基づくものである。

ここで第１ユースケースを機械学習とデータ処理とを参照して説明する。今後、機械学習を用いてユーザ、機器、およびアプリケーションの挙動と関心事とが予測されるであろう。例えば、サービス層システムがユーザ、機器、およびアプリケーションに関する情報を集める。集められた情報を処理した後、それを用いて今後の挙動および関心事の予測に使用可能なアルゴリズムを作成する。アルゴリズムを作成するステップは後処理作業であり、リアルタイムでは行われない。

アルゴリズムが作成されると、リアルタイムでデータを集め、集めたデータに作成したアルゴリズムを適用して、ネットワークリソースをどのように割り当てるか、またどの情報をユーザ、機器、およびアプリケーションに送るか、などを決定する。アプリケーションデータを保存するサービス層は、機械学習アルゴリズムを適用するアプリケーションまたはサービス層にそのデータを提供する前のデータの匿名化に関するものでもある。

ここで第２ユースケースについて自治体によるデータ収集を参照して説明する。プライバシの問題は、自治体がデータを集めて、開放市場を介してそのデータをデータコンシューマに利用できるようにする場合に生じる。ある人物のゴミ収集記録（名前、住所、収集毎の容器の数と種類、各容器の重さなど）を全て含むファイルを考える。この情報は種々の理由で有用である。ゴミ収集会社は資産計画および管理や、マーケティング目的（新規顧客の獲得や顧客の引き留めを試みる場合）でこの情報を用いることができる。ただし、自治体がこのデータを公表したときに、政治的および／または法的な問題が生じる恐れがある。プライバシに対する懸念が実際に生じると（人々が感じると）、投票者／住民は自治体内部の意思決定者に圧力をかけてデータを集めないようにまたはコンシューマがデータを利用できないようにさせる可能性がある。

ここで第３ユースケースについて電力消費データを参照して説明する。家庭の電力消費の内訳（居住者氏名、居住者年齢、家庭の住所、電力を消費する全ての器具／機器のリスト、各器具／機器に消費される電力量、各器具／機器が使われる回数など）を全て含むファイルを考える。この情報は種々の理由で有用である。電力供給者はこの情報を対象となる消費者へのマーケティングキャンペーンに用いることができる。器具／機器メーカはこの情報を用いて、最新のもっとも電力効率のよいモデルに交換することでいかに多額の費用を節約できるかを消費者に語ることができる。電力配給会社はインフラストラクチャ計画のためにこの情報を用いることができる。このファイルには有用な情報が含まれているが、一方で共有できない情報も含まれている。例えば、このファイルには、家庭内に医療機器があって、その機器が何時使用されているか、またどれだけの電力がその機器に消費されているかを示す情報が含まれていることがある。この種の医療情報を共有することは違法であるため、このファイルは使えなくなる。

現在のサービス層アーキテクチャは、サービスプロバイダが、個々のデータの利用を認められる者を設定することを可能にしている。しかし、ＰＰＭアーキテクチャでは、ユーザデータ内の情報に対するきめ細かい制御を得られない。特に、上記サービス層アーキテクチャでは、サービスプロバイダは、コンシューマがデータの一部分、変更版のデータ、またはサニタイズ版のデータにアクセスできるように、システムを構成することはできない。したがって、単にデータセットの一部が私的なものであるということだけで、データコンシューマは全てのデータも有することができない。さらに、ある所定のデータに伴うアクセス許可がデータ主体に依存することもあるが、現在のサービス層アーキテクチャではデータ主体を特定する方法が得られない。

例えば、ＲＥＳＴｆｕｌリソースとそれにアタッチされた属性がある人物の電気使用量に関する情報を含んでいることがある。サービスプロバイダは、あるコンシューマがリソース内の全ての情報を読み出し、他のコンシューマは一部の情報しか読み出しできない（例えば、データコンシューマがある人物の電力消費とおよその位置を読み出しできるが、その人物の身元と特有の位置とを読み出すことはできない）というようにシステムを構成することはできない。サービス層は、位置情報を特定位置（例えば、住所）からおよその位置（例えば、町区）に変更するときを把握しているように構成される必要がある。Ｍ２Ｍ／ＩｏＴサービスプロバイダも、電気器具の名称を、データコンシューマから隠すことが必要になる。例えば、ある人物の医療機器が１５０ｋＷｈを消費することをコンシューマに示す代わりに、その医療機器についての記載を不可視にし、消費電力の総量もそれに応じて除かれるようにデータをサニタイズする必要がある。

データセットの一部分、変更されたデータセット、および／またはサニタイズされたデータセットへのアクセスを制限する時期を決定するポリシで、どのようにサービス層を構成することができるか、についての方法とシステムとが開示される。上記ポリシで構成されることにより、サービス層は、ユーザ／加入者に、選択肢として、共有されないデータの部分を選択すること、ユーザデータを全て共有すること、およびユーザデータをサードパーティのデータコンシューマとの共有から完全に保護すること、を与えることができる。この選択は、Ｍ２Ｍ／ＩｏＴサービスプロバイダまたはアプリケーションサービスプロバイダが提供するサービスの質または他のインセンティブの影響を受ける（またはそれに基づいて行われる）。

ＩｏＴ／Ｍ２Ｍサービス層アーキテクチャは、自身が提供する種々のサービスからデータを集める。このデータは種々の面で有用であるため、ＩｏＴ／Ｍ２Ｍサービスプロバイダはデータを用いると共に関係者と共有する。ただし、データを共有する場合はユーザのプライバシを保護する必要がある。

ＩｏＴ／Ｍ２Ｍサービス層にユーザのプライバシを保護する能力をもたせる機能が開示される。この機能により、特にユーザデータがサードパーティコンシューマと共有される場合に、ＩｏＴ／Ｍ２Ｍサービス層が加入者／ユーザのデータを匿名化することが可能になる。本提案のソリューションは２つの主なサービスからなる。すなわち、プライバシポリシサービスとデータ匿名化サービスとである。

プライバシポリシサービスは、ＩｏＴサーバシステムが、法的義務、加入者のプライバシ選好度、およびデータコンシューマの認証レベルなどの入力情報に基づいて匿名化（プライバシ）ポリシを作成することを助長するものである。データ匿名化（プライバシ）ポリシはプライバシポリシサービスから出力される。

データ匿名化ポリシと匿名化する必要がある原データとがデータ匿名化サービス（ＤＡＳ）への入力情報になる。次いで原データがデータ匿名化ポリシに基づいて匿名化される。このため、データ匿名化サービス機能からの出力情報が私事化（匿名化）版のデータになる。

ユーザ／加入者に関する情報を取得するユーザプロファイルが開示されて、サービス層に保存されてどれだけ多く、またはどれだけ少なくデータをデータコンシューマに公表するべきかについてのポリシの作成に用いられるデータにユーザプロファイルが関連付けられるようにされる。また、ユーザプロファイルを作成、変更、およびサービス層に保存された他の情報とリンクする方法が開示される。

上述のＩｏＴ／Ｍ２Ｍサービス層のプライバシサービス機能は、既存のプライバシおよびセキュリティ機能における追加特徴として、またはデータプライバシの進化した形態のいずれかとして実現される。

ここで他のシステム（例えば、サービス層システム）内またはそれに並行してデプロイ可能なプライバシサービスを説明する。このプライバシサービスは、データセットの各部へのアクセスを何時ならびにどのように制限するかを決定するポリシで構成される。例として、変更されたデータセットおよび／またはサニタイズされたデータセットへのアクセスを与えるかどうか、が挙げられる。

あるデータを公表、非公表、または匿名化のいずれにするべきかを決定する場合の重要な留意事項は、どのユーザがそのデータを作成したか、またはどのユーザがそのデータを所有しているかに基づいていることである。例えば、あるユーザは自身の全データをサードパーティに公表することに抵抗がなく、別のユーザは自身のデータがサードパーティに公表される前に匿名化されることを望むことがあり得る。なお、プライバシ選好度の選択に際してユーザの取り得る選択肢として、個人データを選択的に共有すること、データ全体を共有すること、およびユーザデータを共有することを完全に拒否することがある。この選択の決定は、Ｍ２Ｍ／ＩｏＴサービスプロバイダおよび／またはＡＳＰが提供するサービスの質または他のインセンティブに基づいてまたは影響されて行われる。プライバシサービスがデータを処理する際にどのポリシが適用されるべきかを決定するために、サービス層および／またはプライバシサービスはデータに関連するユーザを特定できる必要がある。

ユーザプロファイルを、サービス層システムに保存されたいずれのアプリケーション、サービス層、または機器の登録情報からも独立して作成することが提案される。サービス層システムに、ユーザのプロファイルをアプリケーション、サービス層、および／または機器にリンクさせる方法が本明細書で開示される。例えば、リンクキーの考え方を導入する。リンクキーは、機器またはユーザに関連したキーである。機器がサービス層に登録する際に、その機器はユーザに関連したリンクキーを提示してユーザとのリンクを許可されていることを証明する。サービス層は、提示されたリンクキーがユーザのプロファイルに保存されたリンクキーに整合していることを確認する。同様に、ユーザがサービス層に登録する際には、ユーザは機器に関連したリンクキーを提示して機器とのリンクを許可されていることを証明する。サービス層は、提示されたリンクキーが機器のプロファイルに保存されたリンクキーに整合していることを確認する。

図１１に、プライバシをサービスとして提供する、高度化されたＩｏＴ／Ｍ２Ｍサービス層システムの一例を示す。このＩｏＴ／Ｍ２Ｍサービス層システムが、ユーザプロファイルの作成に使用される、加入者管理ポータル（Subscriber Management Portal：ＳＭＰ）を公表する。例えば、各ユーザ（例えば、ユーザ１・・・ユーザＮ）はこのポータルを介してサービス層に接続して自身のプロファイルを作成する。また、サービス層プラットフォームによって、アプリケーションサービスプロバイダ（ＡＳＰ）が、スマートメータなどの機器によってサービス層に保存されたデータにアクセスすることが可能になる。サービス層システムによってどのようにデータがＡＳＰに提供されたか、かつ提供されたかどうかは、プライバシポリシとプライバシサービスがそのプライバシポリシをどのように適用するかに基づいて定まる。

ユーザプロファイルを作成する方法とシステムとが開示される。

Ｍ２Ｍシステムにおけるあらゆるデータと、データにアクセス可能なユーザとは一連のポリシにより規制される。ある所定のデータに適用されるポリシは、そのデータがどの加入者に適用されるか、誰がそのデータの利用をリクエストしたか、およびサービス層システムのポリシによって決定される。現在のサービス層の規格（例えば、ｏｎｅＭ２Ｍ）では加入者を特定する方法は示されていない。Ｍ２Ｍ／ＩｏＴサービス層が提供するサービスに申し込んだユーザが加入者になる。したがって、ユーザを加入者と呼ぶこともある。

本節では個々のデータに関連する加入者（すなわちユーザ）を特定する方法について説明したが、同様の技法を用いて個々のデータを利用しようとしているサードパーティコンシューマを特定可能なことは言うまでもない。ユーザの情報はユーザプロファイルとしてＩｏＴ／Ｍ２Ｍサービス層プラットフォームに取得される。ユーザプロファイルには表２に示したような情報が含まれている。

表３はユーザプライバシの保護規則の詳細を示している。ＩｏＴ機器、アプリケーション、およびサービス層のエンティティもまたそれら自身に関する情報をサービス層に保存する。この情報は通常、機器、アプリケーション、またはサービス層がサービス層に登録するときにサービス層に提示される。その後、このデータは通常動作の間に処理される。表４に、ＩｏＴ機器、アプリケーション、またはサービス層のプロファイルに含まれる情報で、どのプライバシポリシをサービス層のリクエストに適用するかを決定するために使用される情報を示す。

例えば、表２に示したようなユーザプロファイルは、ユーザが自分自身をＩｏＴサービス層の加入者管理ポータルを介してＩｏＴサービス層プラットフォームに登録するときに作成される。この作成プロセスを図１２に示す。図１２の手順は、アプリケーションサービスプロバイダ（ＡＳＰ）（例えば、電力会社、広告会社など）が、ある判断基準（例えば、位置、名前など）に適合するユーザが生まれたときに通知を受けるようにする加入の仕方を示している。ＩｏＴ／Ｍ２Ｍサービス層システムは適合するユーザが生まれるとＡＳＰに通知を送る。次いでＡＳＰが、ユーザに関連するデータの読み出しリクエストなどの通知に基づいて動作を行う。図１２の手順の詳細例を以下に説明する。

ステップ１で、アプリケーションサービスプロバイダ（ＡＳＰ）がＩｏＴ／Ｍ２Ｍサービス層のサービス（例えば、通知サービス）に加入する。加入リクエストには、以下の事象のいずれかが生じた場合に通知を受けたい旨が示されている。

特定のユーザがプロファイルを作成する。

特定のユーザのプロファイルが変更される。

特定の機器、アプリケーション、またはサービス層に関連するユーザが変わる。

ユーザプロファイルが作成または変更されて、そのプロファイルが、特定の機器、アプリケーション、またはサービス層タイプに関連付けられる。

特定のグループに関連するユーザプロファイルが作成または変更される。

ある判断基準に適合するユーザプロファイルが作成または変更される。この判断基準として、ユーザがある所定の位置に関連していることがある。また、この判断基準として、表２に示したいずれかのパラメータなどの、ユーザプロファイル中の何らかのパラメータがある所定の値または値範囲に割り当てられることがある。ならびに／または、

ユーザプロファイルがある特定のリンクキーを備えて作成される。

ステップ２で、サービス層は確認応答をＡＳＰに返送し、ＡＳＰは加入の成立を確認する。このメッセージには加入の成否が示されている。加入が成立しなかった場合、このメッセージにその要因値が示される。

ステップ３で、ユーザは加入者管理ポータル（ＳＭＰ）を介してＩｏＴサービス層に自身のユーザプロファイルを作成する。加入者管理ポータルはＲＥＳＴｆｕｌプロトコルを用いてアクセスされる。ユーザプロファイルの作成の間に設定されてメッセージに含められる項目を表２に示す。また、サービス層はこのメッセージのコンテンツを用いて自身のもつ新規ユーザ用のデータベース内にエントリを作成する。さらに、リクエストが、新規ユーザのプロファイルを、既にＩｏＴサーバに登録された機器、アプリケーション、またはサービス層に関連付ける必要があることを示している場合は、ＩｏＴサーバは機器、アプリケーション、またはサービス層のプロファイルを更新してそれら（機器他）がユーザにリンクしていることを示すようにする。このユーザプロファイルを機器、アプリケーション、またはサービス層にリンクするプロセスについては後述する。リクエストがリンクキーを含んでいた場合は、ＩｏＴサーバは、機器、アプリケーション、またはサービス層のプロファイルが同じリンクキーを示していることを確認する。

ステップ４で、ユーザプロファイルの作成が完了すると、サービス層は加入者管理ポータルに確認応答を返し、加入者管理ポータルはユーザプロファイルが作成されたことを確認もしくは作成できなかった理由の通知を確認する。

ステップ５で、ステップ３で設定された加入、またはステップ３で更新された機器、アプリケーション、またはサービス層のプロファイルに基づいて、サービス層がＡＳＰに通知を送る。

ステップ６で、ＩｏＴサーバから通知を受け取ると、ＡＳＰは確認応答をＩｏＴサーバに返すことによって受信を確認する。

機器、アプリケーション、および／またはサービス層をユーザプロファイルにリンクさせる方法とシステムとが開示される。

ユーザプロファイルとのリンクの結果として、

ユーザプロファイルの記録またはリソースが更新されて、ユーザが機器、アプリケーション、および／またはサービス層と関連していることが記録される。

リンクされた機器、アプリケーション、および／またはサービス層に関連した記録またはリソースが更新されて、それら記録またはリソースがユーザに関連していることが記録される。ならびに／または、

形成されるリンクの関係者へのトリガまたは通知が行われる。

ユーザプロファイルが機器、アプリケーション、またはサービス層にリンクされる。リンクされた機器、アプリケーション、またはサービス層が既にサービス層に登録されている例では、ユーザプロファイルの作成時にリンクが行われる。

ユーザプロファイルが作成されると、ユーザは、ユーザプロファイルの作成時（例えば、図１３のステップ２）にユーザがリンクされることになっているアプリケーション、機器、および／またはサービス層の識別情報を提出する。

これに加えてまたはこれに代えて、ユーザプロファイルの作成後、ＳＭＰにおける別のリクエストを、ユーザプロファイルをアプリケーション、機器、および／またはサービス層にリンクするリクエストとして用いることもある。

リンクされた機器、アプリケーション、またはサービス層が未だサービス層に登録されていない場合は、ユーザプロファイルの作成時にリンクが行われる。

機器、アプリケーション、またはサービス層は、その登録時にどのユーザにリンクされるのがよいかを示す（一例を図１４のステップ１～３に示す）。ならびに／または、

機器、アプリケーション、またはサービス層の登録時に、該機器、アプリケーション、またはサービス層が登録されたことを示す通知がＳＭＰを介してユーザに送られる。サービス層は、以前にＳＭＰを介してユーザから受け取った加入リクエストに基づいてこの通知を送るようにプログラムされる。この加入リクエストは、特定の機器、特定のアプリケーション、特定の機器タイプ、特定のアプリケーションタイプ、またはサービス層タイプが登録する場合、またはある判断基準に適合する機器、アプリケーション、またはサービス層が登録する場合に、ユーザが通知されることを望んでいることを示している。このプロセスの例を図１４に示す。

図１３に、方法であって、その方法により加入者管理ポータル（ＳＭＰ）からのユーザリクエストに基づいて、登録された機器、アプリケーション、またはサービス層にユーザプロファイルがリンクされる方法の一例を示す。

ステップ１で、ユーザプロファイルを有するユーザがＳＭＰを介して、そのユーザプロファイルと既存の登録された機器、アプリケーション、またはサービス層のエンティティとのリンクのリクエストを送る。このリクエストメッセージは、上記機器、アプリケーション、またはサービス層のエンティティの識別情報と、ユーザプロファイルの識別情報と、関連のリンクキーとを含んでいる。

ステップ２で、ＩｏＴ／Ｍ２Ｍサービス層がこのリクエストを受け取って処理する。このリクエストの処理には、ステップ１で提示されたリンクキーが、ユーザがリンクを望んでいる機器、アプリケーション、またはサービス層のプロファイルのリンクキーに整合していることを確認することが含まれる。この結果、リンクされた機器、アプリケーション、またはサービス層の記録またはリソース表示およびユーザの記録またはリソース表示が追加または更新されて、前記リンクすなわち関連付けが示される。したがって、このときに表４の情報が表２の情報と併せてリンクされる。

ステップ３で、処理の完了とリクエストの結果についての通知がＳＭＰを介してユーザに送られる。この通知は、ユーザのリクエストが実施されたかどうかを示しており、実施された場合は、リンクされた機器、アプリケーション、またはサービス層のエンティティについての情報も通知の一部として送られる。

図１４は、機器、アプリケーション、またはサービス層がＩｏＴサーバに登録するときにユーザプロファイルが機器、アプリケーション、またはサービス層にリンクされる方法の一例を示すフローチャートである。

ステップ１で、機器、アプリケーション、またはサービス層が、該機器、アプリケーション、またはサービス層がリンクを所望する対象ユーザを含む登録リクエストをＩｏＴサーバに送る。このリクエストにはリンクキーが含まれている。

ステップ２で、リクエストを受け取ると、ＩｏＴサービス層プラットフォームが、リクエスト元の機器、アプリケーション、またはサービス層をＩｏＴサーバに登録すると共に、リクエストに示されたユーザのユーザプロファイルが、登録されたリクエスト元の機器、アプリケーション、またはサービス層とリンクされる。さらにＩｏＴサーバが、ステップ１で提示されたリンクキーが、リクエスト元がリンクを所望した対象ユーザの記録内のリンクキーに整合していることを確認する。この結果、リンクされた機器、アプリケーション、またはサービス層の記録やリソース表示、およびユーザの記録および／またはリソース表示が追加または更新されて、前記リンクすなわち関連付けが示される。

ステップ３で、登録の成否および示されたユーザとのリンクプロセスの成否に関する確認応答が機器、アプリケーション、またはサービス層に返される。

ステップ４で、ＩｏＴサーバが、機器、アプリケーション、またはサービス層によって行われたリンクのリクエストに関する通知をＳＭＰに送る。この通知はユーザに転送される。

ステップ５で、受け取った通知の種類に基づいて、ユーザはＩｏＴサーバを承認する。これに加えてまたはこれに代えて、ユーザが自身のプロファイルをリクエスト元の機器、アプリケーション、またはサービス層にリンクするリクエストを送ってもよい。

ステップ６で、ユーザの同意を得ると、Ｍ２Ｍ／ＩｏＴサービス層プラットフォームは、ユーザプロファイルをリクエスト元の機器、アプリケーション、またはサービス層にリンクするプロセスを仕上げる。この結果、ユーザの記録またはリソース表示が追加または更新されて、前記リンクすなわち関連付けが示される。例えば、表４の情報が表２の情報と併せてリンクされる。

ステップ７で、ＩｏＴサーバは、リクエストされたユーザと機器、アプリケーション、またはサービス層との間のリンクが完了したことについての確認応答を、リクエスト元の機器、アプリケーション、またはサービス層に返す。

ステップ８で、ＩｏＴサービス層は、リクエストされたユーザのユーザプロファイルとリクエスト元の機器、アプリケーション、またはサービス層とのリンクが完了したことについての通知を、ＳＭＰを介してユーザに送る。

機器、アプリケーション、またはサービス層は複数のユーザプロファイルとリンク可能なことは明らかである。

プライバシポリシサービス（ＰＰＳ）であって、これを用いて、データがデータコンシューマに提供される前にそのデータを匿名化する方法の決定に用いるポリシが検索される、プライバシポリシサービスが開示される。例えば、ＡＳＰがＩｏＴサーバに保存されたリソースの読み出しをリクエストした場合、ＩｏＴサーバはＰＰＳからポリシを検索する。このポリシは、リクエスト元の識別情報、リクエストされたデータに関連するユーザ、および／またはローカルポリシに基づくポリシである。

ＰＰＳの入力情報と出力情報とをそれぞれ表５と表６とに示す。なお、リクエストされているデータまたはデータの種類に関連するユーザに基づいてポリシを検索することも可能である。

受信した入力情報に基づいて、ＰＰＳは、ポリシであって、そのポリシを用いてデータがデータコンシューマ（ＡＳＰ）に提供される前にそのデータをどのように変更するかを決定する、ポリシをビルドする。このポリシは以下の要因に基づくポリシである。

ユーザ／加入者の選好度
ユーザの選好度は、ユーザが個人情報と考えるユーザデータの部分を隠すべきかどうかを決定させるものである。さらに、ユーザが、データを保有して欲しくないターゲットコンシューマのタイプを示すこともある。データがサードパーティに使われた場合でも、ユーザは共有を欲しない個人情報を管理することができる。この選好度（表５に記載）は、ポリシ作成リクエストと共にＰＰＳに提供される。

地方自治体により課せられる法規
既存の地方自治体の政策による規制によって、ユーザが特定の情報を共有することを強制されるまたは許可されることがある。例えば、現地法が、ＩｏＴサービスプロバイダが、ユーザの同意なしに（すなわちターゲットコンシューマ（例えば、医療介護部門）のみに依拠して）ユーザデータを共有または取り引きすることを許可していないことがある。人物の年齢、身長、およびこれまでの医学的状態を共有する必要がある場合もある。これらの選好度はローカルポリシからＰＰＳにより取得される。ならびに／または、

データコンシューマの選好度
この選好度はプライバシポリシとは対照的な管理ポリシとみなされる。データコンシューマは、ユーザのプロファイルまたは機器、アプリケーション、またはＳＬのエンティティのプロファイルの精確さのレベルおよび原データの精確さのレベルが選択することができる。この選好度の評価基準は、支払われた金額に基づいてどのデータをデータコンシューマに渡すかを決定する上で重要なものになる。これらの選好度は予備プロビジョニングを経てＰＰＳにより取得される、またはローカルポリシとして実装される。

上記諸要因には何らかの優先度が伴っている。例えば、地方自治体により課せられる規制はユーザ／加入者の選好度に優先し、ユーザ／加入者の選好度はデータコンシューマの選好度に優先する。この優先度はローカル設定に基づくものである。

このポリシは、データにエイリアス化、サニタイズ、またはマスキングなどを施す必要があるかどうかを示すものである。これについては後に詳しく述べる。さらに、このポリシは、諸データが所定の条件を満たした場合に、それらデータを単純に匿名化すればよいか、またはそれぞれ別な仕方で匿名化する必要があるかを示している。例えば、機器がある所定位置に存在している間にデータが作成された場合は、そのデータはエイリアス化するだけでよい。

データ匿名化サービスであって、ポリシと一連のデータ（すなわち、ポリシとデータへのポインタ）を入力情報として受信して、匿名化されたデータセットおよび／または匿名化されたデータセットへのポインタを作成するデータ匿名化サービスが開示される。データ匿名化サービスの入力情報と出力情報との例を表７と表８とにそれぞれ示す。

ユーザデータは１つ以上の匿名化技術を組み合わせて匿名化される。ユーザデータの匿名化に用いる技術の例として１つ以上の以下の技術がある。

（１）データのサニタイズ
ユーザの個人データの一部を隠蔽（マスキング）することでプライバシを保つ。例えば、家庭の電気料金請求書には、ユーザの名称、住所番号を伴う所在地、その住居の居住人数、機器の数、機器のタイプ、機器の名称／銘柄などが載っている。個人情報が明白な部分はサニタイズまたはマスキングを施すことができる。

（２）データの変更

（ａ）省略
名前などのデータの一部がイニシャルで表される。例えば、Ｒｏｂｉｎ ＳｈａｒｍａはＲＳと省略される。

（ｂ）置き換え
データに名前を付けることでデータの価値が高められる。ただし、名前は乱数、文字、または他の一般名に置き換えられる。例えば、Ｒｏｂｉｎ ＳｈａｒｍａをＤＨＭＣＱＳＸＬＫＺＳに置き換えられる。他の置き換え形式としてエイリアスや省略形が用いられる。例えば、Ｒｏｂｉｎ ＳｈａｒｍａはＲＳと省略される、あるいはＪａｍｅｓ Ｓ． Ｃａｍｒｏｎとエイリアス化される。

（ｃ）シャフリング
置き換えに類似しているがデータ間に記録が付されている。これは大きいデータセットの場合のみ有効である。例えば、ある郵便番号について集められた電力消費データは、混ぜ合わされた場合でもその郵便番号での電力消費の巨視的様相を表すことができるので利用価値がある。

（ｄ）暗号化
暗号化はデータの機密性の保護に寄与する。適正なキーを有する当事者だけがデータを見ることができる。この暗号化は、有線でデータを転送する場合、またはデータの一部を秘密キーを有する特定の人々に利用可能にするシナリオで重要になる。例えば、あるファイル内の２箇所のデータを２つの異なるキーで暗号化して、キーを組織内の特定の人々に（地位に応じて）与える場合は、別々のファイル受信者は１つのファイル内の別々のデータセットを見ることになる。

ここでデータ匿名化手順が開示される。図１５に、ポリシ作成およびデータ匿名化プロセスの図的記述の一例を示す。データ匿名化ポリシは３つの主要なコンポーネントに基づいている。すなわち、行政機関が定めたデータポリシ／法規と、加入者／ユーザの匿名化の選好度と、データコンシューマの要求事項とである。プライバシポリシサービス（ＰＰＳ）がこれらの要件に基づいて適用可能なプライバシポリシを作成する。次いで、ポリシが、匿名化を要する原データと特定のデータリクエストに付随する匿名化パラメータと共に、データ匿名化サービス（ＤＡＳ）に使用される。データ匿名化サービスは、匿名化（私事化）形式のデータを出力として算出する。データ匿名化サービスはｋ－匿名化などの技術を用いてデータを匿名化する。Ｋなどの匿名化パラメータはＰＰＳにより作成され、ポリシ内に置かれて、ポリシの一部としてＤＡＳに提供される。他の例として、ＤＡＳが、準同型暗号化や差分プライバシなどの演算を行うものもある。これらの匿名化／暗号化技術を構成するパラメータはＰＰＳにより作成され、ポリシ内に置かれて、ポリシの一部としてＤＡＳに提供される。

データ匿名化手順の２つのバリアントについて説明する。

第１バリアントは、ＰＰＳとＤＡＳとが集中化（例えば、ＩｏＴサーバに集中化）されるデプロイメントによく適合する。原データのホストは、ＩｏＴサーバでもゲートウェイなどの分散ＩｏＴノードでもよい。このバリアントにおいて、ＰＰＳは、匿名化ポリシだけでなく、原データと共にＤＡＳに供給される、リクエスト毎の匿名化パラメータも提供する。

第２バリアントは、ＰＰＳは集中化されるが一方でＤＡＳのサービスは分散して設けられるデプロイメントで、特にＤＡＳのサービスが原データのホストと同一箇所に置かれる場合によく適合する。このバリアントにおいて、ＰＰＳはポリシのみを提供し、匿名化パラメータはポリシと原データリクエストに基づいてＤＡＳにより作成される。

図１６に、第１バリアントによるデータ匿名化手順の方法例のフローチャートを示す。

ステップ１で、ＡＳＰはユーザデータのリクエストをＩｏＴサービス層プラットフォームに送る。このリクエストは、ＡＳＰの認証情報と属性とを含んでいる。例えば、ＡＳＰのＡＥアプリケーションは、ユーザのカテゴリ（すなわち、財政状態、日付範囲 ２０１６年５月１日～２０１７年４月３０日、所在地 郵便番号１９１２６など）などの属性を含むリクエストを送る。このリクエストはさらに、ユーザのファーストネームとラストネームとからなるユーザＩＤなどのユーザ認証情報を含む。

あるいは、ＡＳＰは、ＩｏＴサーバの記憶装置からデータを削除することを認められている者である。例えば、リクエストが、ある特定のユーザ、ユーザグループ、またはカテゴリなどに関連する全データを削除する必要があることを示す場合がある。このリクエストはさらに、ある日付範囲内または場所内で作成された全てのデータを削除する必要があることを示している。

ステップ２で、ＩｏＴサーバはＡＳＰからのリクエストを解釈して、ＡＳＰにリクエストされたデータに適用可能な適切なプライバシポリシについての問い合わせをプライバシサービスに送る。

ステップ３で、ＡＳＰの認証情報と属性とに基づいて、プライバシポリシサービス（ＰＰＳ）は、ユーザデータの選好度とユーザの所在地のプライバシ法とについて適切なデータベースを検索する。検索された情報に基づいて、リクエストされたユーザデータに適用可能な特定のプライバシポリシが策定される。例えば、ユーザの選好度として、省略 ＞ ユーザＩＤ ＡＮＤ サニタイズ ＞ 街路名 ＡＮＤ サニタイズ ＞ ＳＳＮ ＡＮＤ 暗号化 ＞ 誕生日、がある。「＞」は命令を示す。ある例では、ＡＳＰは同一のリクエストを複数回送信する。過去に策定したポリシはＭ２Ｍ／ＩｏＴサービス層に保存され、後に再利用される。

ステップ４で、ＰＰＳは匿名化ポリシを策定してＩｏＴサーバに送り返す。

ステップ５で、ＩｏＴサーバはユーザの原データと適用可能なポリシとをデータ匿名化サービス（ＤＡＳ）に送る。例えば、完成したポリシは以下のとおりである。

ポリシ１ 施行 ＞ ユーザ選好度 ＡＮＤ 施行 ＞ データの共有に対するユーザの同意。

ポリシ２ 省略 ＞ ユーザＩＤ ＡＮＤ サニタイズ ＞ 街路名 ＡＮＤ サニタイズ ＞ ＳＳＮ ＡＮＤ 暗号化 ＞ 誕生日。

あるいは、上記ポリシが、何らかの操作をデータに施す必要があるかどうか（例えば、削除、変更、消去など）をＤＡＳに示す。

ステップ６で、原データと適用可能なポリシとがデータ匿名化サービスに入力情報として受信される。このポリシに基づいてデータが匿名化される。この結果、全ての要件に適合した匿名化版のデータが作成される。例えば、匿名化版では、「ユーザＩＤ」「Ｓａｍ Ａｄａｍｓ」は「ユーザＩＤ」「ＳＡ」（省略）になり、「住所」「フィラデルフィア」は「ＰＡ」に、「ＳＳＮ」は「」に、「誕生日」は「Ｎｖ／ｇＱｓＶｑｘＲａ４６０ｉｂ１ＲＹｇＲｆｗ＝＝ＩｗＥｍＳ」になる。

ステップ７で、匿名化版のデータがＩｏＴサーバに返送される。

あるいは、ステップ５で提示されたポリシがデータを削除する必要があることを示している場合は、このメッセージは削除ができたかどうかを示す通知となる。

ステップ８で、リクエストされたデータの匿名化版がリクエストしたＡＳＰに返送される。この応答には、データが匿名化されたことの通知が含まれている。さらに、この応答により、どの匿名化技術がデータに適用されたかが示される。ＡＳＰは、データセット全体へのアクセスをリクエストすることでこの応答に返信する。

あるいは、ステップ１で提示されたポリシがデータを削除する必要があることを示している場合は、このメッセージは削除ができたかどうかを示す通知となる。

ＩｏＴサーバは、誰がデータをリクエストしたか、どのデータがリクエストされたか、どのデータが提供されたか、どのようにしてデータを匿名化したか、どのデータを削除したか、などについての記録（例えば、課金データ記録）を作成する。

なお、匿名化ポリシは、価格／費用要因であって、ＩｏＴサービス層プラットフォームに変動する価格／匿名性に応じて様々なデータをもたせることになる、価格／費用要因にも依存するものである。ただし、既存の行政機関のポリシ／法規に則った最低レベルの匿名性は必ず実施される必要がある。

また、演算と管理とを簡略にするために様々なレベルの匿名化が実施される。上記匿名化のレベルは、価格と匿名性の選好度に基づいてモデル化可能である。

図１７に、第２バリアントによる、集中化ＰＰＳと分散ＤＡＳとのサービスを用いてデータ匿名化を行う方法の一例のフローチャートを示す。図１７は、ＤＡＳのサービスを事前設定するプライバシポリシについての情報をサービス層が有するプロセスであって、ユーザデータがＡＳＰにリクエストされると、サービス層はそのプライバシポリシを用いて匿名化されたデータで応答するプロセスの例を示す。以下に各ステップを説明する。

ステップ１で、サービス層（原データのホスト）がデータアクセスを開始する。このステップは、そのサービス層（ＳＬ）自体の他のＳＬ（例えば、機器またはゲートウェイ用のＳＬ）への登録などの所定の手順の一部として、他のＳＬが該ＳＬ（例えば、ゲートウェイまたはサーバ用のＳＬ）に登録するときや、個々のリソースが最初に作成されるときなどに行われる。このとき、当該原データについてのアクセス制御ポリシが設定される。さらにこのときに、該原データがＳＬ内の１つ以上のユーザプロファイルに関連付けられる。

ステップ２で、ＳＬが、ホストデータに適用されるプライバシポリシについてＰＰＳと交信する。このステップは、他のトリガに基づいて付加的または代替的に行われるステップである。他のトリガとして、ＳＬが定期的にポリシを更新するために、関連データについての新たなポリシを受け取った後、その新ポリシが利用可能になったことを通知されるときなどがある。さらにＳＬは、リソースの目的についてのキーワードや、リソース作成者などの、リクエスト中の関連のメタデータを提供する。

ステップ３で、プライバシポリシサービス（ＰＰＳ）は、リクエストパラメータと、ユーザ選好度と、デフォルトとに基づいて適用可能なポリシを作成する。行政機関のポリシとデータコンシューマの選好度とがデフォルトとして実装される。これに加えてまたはこれに代えて、このポリシは選択肢（例えば、データコンシューマのタイプによる差異など）を示している。ＰＰＳはリクエスト中に提示されたユーザ選好度を使用するか、または他のリクエストパラメータに基づいてユーザ選好度を発見する。例えば、ユーザＸ向けの医療アプリケーションにより作成された１つの情報に関連するポリシのリクエストが集中化ＰＰＳをトリガして、それによりそのＰＰＳがＸに関連するユーザ選好度と医療データとを（たとえそれらがＳＬによって提供されない場合でも）既に有しているかどうかがチェックされるようになっている。上記ポリシは、プログラムされる匿名化のタイプ、アルゴリズムのタイプならびに強さなどを含んでいる。さらにこのポリシにより、匿名化データと脱匿名化パラメータとを保存する場所と方法とが指定される。

ステップ４で、ＰＰＳは匿名化ポリシを策定してＳＬに送る。なお、同じポリシが、例えば、データコンシューマのタイプ、位置、時間などによって、リクエスト毎に異なる処理をもたらすこともある。ＰＰＳが使用されるアルゴリズムなどの匿名化パラメータ（例えば、モンドリアン（Mondrian）、ｋ－匿名性、ｋ値など）を提供することもある。これに加えてまたはこれに代えて、ＤＤＳがこの情報をＰＰＳによって提供されたポリシから引き出すこともある。

ステップ５で、ＳＬは（状況に応じて）所定のポリシについてのＤＡＳのサービスの事前設定を行う。この事前設定には、使用されるアルゴリズムの初期化や、ボールトサービスまたは匿名化データのストレージを提供するエンティティへの登録などが含まれる。
応答がＳＬに返される。

ステップ６で、ＡＳＰ（発信者）が、ＳＬでの（保護されるプライバシである）ホストデータへのアクセスをリクエストする。

ステップ７で、ＳＬは、リクエストされた原データと適用可能なポリシとをデータアノニマイザ機能に送る。ＰＰＳが匿名化パラメータを提供していてかつＤＡＳが事前設定されていない場合は、上記情報もこのときに提供される。

ステップ８で、原データと適用可能なポリシとがデータ匿名化機能に入力情報として受信される。適用可能なポリシに基づいて、（ＰＰＳによって提供されない場合は）匿名化パラメータが作成される。例えば、ポリシに含まれるデータコンシューマのタイプ毎に異なるハッシュの強さが算出される。なお、事前設定のオプションが使用される場合、匿名化パラメータの中にはＤＡＳで演算されるものもある（例えば、ステップ５ｂで）。データリクエスト（原データ自体を含む）と、匿名化ポリシと、匿名化パラメータとに基づいて、原データが匿名化される。この結果、全ての要件に適合した匿名化版のデータが作成される。ポリシによって脱匿名化データがリクエストされる場合は、そのデータも同様にポリシにしたがってＤＡＳにより作成されて保存される。

ステップ９で、応答がＳＬに送られる。この応答が匿名化データを含むこともある（例えば、ポリシによって指定された場合）。含まない場合は、この応答は匿名化データの位置のみを含む。なお、ポリシが、脱匿名化情報を提供すべきかどうかおよびその情報をどのように保存するかを指定することもある。ＳＬが脱匿名化情報を局所的に保存している場合、ＳＬは、原データにのみ利用可能な情報の範囲の原データを用いた匿名データ（例えば、エイリアス）に基づいてクエリを行うことができる。あるいは、脱匿名化情報がＤＤＳから受信されて外部のセキュアボールトに保存される。応答を受け取ると、ＳＬは、原データの削除、原データを匿名化データに置き換えなどの、他の操作を行う。

ステップ１０で、匿名化版のリクエストデータ（またはその位置）がリクエスト元のＡＳＰに返送される。この応答は、データが匿名化されたことの通知と、用いた匿名化技術に関する情報とを含んでいる。ＡＳＰは、データセット全体へのアクセスをリクエストすることでこの応答に返信する。

ｏｎｅＭ２Ｍの一実施形態における本記載のデータ匿名化サービスの実装例を以下に述べる。

図１１との関連で述べた手順はｏｎｅＭ２Ｍシステムに適用可能である。例えば、ＩｏＴサーバはＩＮ－ＣＳＥであり、ＳＭＰは、ユーザにユーザプロファイルの作成と変更とのリクエストを行わせる専用ＡＥである。ＩｏＴサーバへのＳＭＰのインタフェースはＭｃａインタフェースである。さらに、ＡＳＰはＭｃａ基準点でＩＮ－ＣＳＥとＡＥとにインタフェースで接続する。

ユーザプロファイルが作成されると、「ユーザプロファイル（<userProfile>）」リソースが作成される。「ユーザプロファイル」リソースは、「ユーザプライバシプロファイル（<userPrivacyProfile>）」子リソースを有している。「ユーザプロファイル」の名称は加入者ＩＤに対して設定され、「ユーザプロファイル」リソースに関連する属性は表２に示したものと同じ項目のものである。

「ユーザプロファイル」リソースを作成することでＩＮ－ＣＳＥ内の他のリソースも変更される。例えば、作成したユーザプロファイルリクエストが、ユーザが特定の機器、アプリケーション、またはサービス層にリンクされていることを示す場合は、対応する「ノード（<node>）」、「ＡＥ（<AE>）」、および「リモートＣＳＥ（<remoteCSE>）」リソースがそのリンクを示すように更新される。新しいリンクユーザ（linkedUser）属性が「ノード）」、「ＡＥ」、および「リモートＣＳＥ」リソースに関連付けられて、上記機器、アプリケーション、またはサービス層に関連する全てのユーザと等しく設定される。

「ユーザプライバシプロファイル」リソースの属性を下表に示す。

ここでユーザプロファイルを機器、アプリケーション、またはサービス層とリンクするプロセスの一例を説明する。ユーザプロファイルを機器、アプリケーション、またはサービス層とリンクする方法として２つの方法を前述した。すなわち、ＳＭＰリクエストに基づくプロファイルリンクと、機器、アプリケーション、またはサービス層の登録におけるプロファイルリンクである。これらのいずれの方法も、表４に示したパラメータを属性として「ノード」、「ＡＥ」、または「リモートＣＳＥ」リソースに付加することによって、または表４に示したパラメータに対応する属性を用いて対応する「機器プライバシプロファイル（<devicePrivacyProfile>）」を作成することによってｏｎｅＭ２Ｍシステムに適用可能である。同時に、「ユーザプロファイル」リソースに対するリンクノード（linkedNode）、リンクＡＥ（linkedAE）、またはリンクＣＳＥ（linkedCSE）属性が更新または追加される。

同時に、「ユーザプロファイル」リソースを「ｍ２ｍサービス加入プロファイル（<m2mServiceSubscriptionProfile>）」リソースと、「サービス加入ノード（<serviceSubscribedNode>）」リソースと、「サービス加入アプリケーション規則（<serviceSubscribedAppRule>）」リソースとにリンクする。この関係により、ユーザプロファイルを介してユーザを、ユーザがアクセスを承認される「ノード」リソースと「ＡＥ」リソースとを規定する「ＣＳＥベース（<CSEBase>）」リソースを用いて、ユーザが加入するサービスの加入申し込みに関連付けることができる。ユーザプロファイルを機器、アプリケーション、またはサービス層にリンクする方法を以下に述べる。

（１）ＳＭＰリクエストに基づくプロファイルのリンク
本記載のとおり、ＳＭＰは専用ＡＥである。したがって、ＡＥは、「ユーザプライバシプロファイル」が「ノード」、「ＡＥ」、または「リモートＣＳＥ」リソースとリンクしていることをリクエストまたは通知する。このリクエストは、ＡＥが「ユーザプライバシプロファイル」のリンクノード、リンクＡＥ、またはリンクＣＳＥ属性を更新することによって行われる。また、「ノード」、「ＡＥ」、または「リモートＣＳＥ」リソースのリンクユーザの属性を更新することによっても行われる。これに加えてまたはこれに代えて、リンクノード、リンクＡＥ、またはリンクＣＳＥの属性とリンクユーザの属性とをそれらの関連リソースのサブリソースとして実装してもよい。

（２）機器、アプリケーション、またはサービス層の登録におけるプロファイルのリンク
ｏｎｅＭ２Ｍ ＣＳＥは、プロセスであって、そのプロセスにより、サービス層がＩｏＴサーバに登録するときにユーザプロファイルが機器、アプリケーション、またはサービス層とリンクするプロセスをサポートすることができる。ＡＥまたはＣＳＥがＣＳＥに登録する場合、ＡＥまたはＣＳＥは、その「ＡＥ」または「リモートＣＳＥ」リソースを作成するときにリンクユーザ属性を提示することによって、どのユーザにリンクすればよいかを示すことができる。ユーザがＡＥ、ＣＳＥ、またはノードにリンクすると通知が送られる。ＣＳＥまたはＡＥは、ある特定の値を割り当てられたシステム内の任意のリンクユーザ属性に同意するか、「ユーザプロファイル」リソースのリンクノード、リンクＡＥ、またはリンクＣＳＥ属性の更新に同意するか、または「ＡＥ」、「リモートＣＳＥ」、または「ノード」リソースのリンクユーザ属性の更新に同意する。

図１８に、メインの「ＣＳＥベース」リソースの下での、「ノード」、「ＡＥ」、または「リモートＣＳＥ」子リソースを対応するリソースおよび属性と共に示す。これら子リソースは、それぞれにアタッチされたリンクユーザの属性を示すことでリンクしたユーザプロファイルを示すようになっている。

プライバシポリシサービス（ＰＰＳ）は、前述の入力情報に基づいてデータプライバシポリシのビルドを促進するサービスである。ｏｎｅＭ２Ｍサービス層において、このサービスは独立したｏｎｅＭ２Ｍ ＣＳＦまたは補助機能となるポリシ検索ポイント（ＰＲＰ）のいずれかとして具現される。ＰＲＰはＴＳ－０００３の１１章に規定されている。ＰＲＰ（またはＰＰＳを含むｏｎｅＭ２Ｍ ＣＳＦ）の出力情報がプライバシポリシであり、リソースツリーにおける「プライバシポリシ（<privacyPolicy>）」リソースになる。ＰＲＰ（またはＰＰＳを含むｏｎｅＭ２Ｍ ＣＳＦ）の入力情報を表５に示す。表６に示したこのｏｎｅＭ２Ｍ ＣＳＦまたはＰＲＰの出力情報は「プライバシポリシ」リソースとして取得される。得られたデータプライバシ（または匿名化）ポリシは次いでデータ匿名化サービスに送られる。

前述のデータ匿名化サービス（ＤＡＳ）は、原ユーザデータの取得とＰＰＳ（ＰＲＰ）から得られたデータ匿名化ポリシの施行とに関するものであった。ｏｎｅＭ２Ｍにおいては、ＤＡＳは、補助機能となるポリシ実施ポイント（ＰＥＰ）として機能する、独立したｏｎｅＭ２Ｍ ＣＳＦになる。さらにＤＡＳは、ポリシを施行可能かどうかについての結論を下す際のポリシ判定ポイント（ＰＤＰ）（ＰＤＰとＰＥＰとはＴＳ－０００３の１１章に規定されている）として機能する。ＰＰＳ（ＰＲＰ）からの出力「プライバシポリシ」がＤＡＳ（ＰＥＰ）の入力情報になる。

ＤＡＳの入力情報を表７に示す。ユーザデータについてのＰＲＰから出力されたポリシの施行がＤＡＳで決定される。次いで、例えば、受信したユーザデータにポリシを適用することによってポリシを施行する。したがって、ＤＡＳ（ＰＥＰ）からの出力情報が匿名化版のユーザデータになる。ユーザデータはｏｎｅＭ２Ｍの「フレックスコンテナ（<flexContainer>）」リソースにより具現される。

図１９に、ｏｎｅＭ２Ｍサービス層のＳＭＰを介したユーザによるユーザプロファイルの作成に関わるステップを示す。

ステップ１で、ＡＳＰのＡＥはｏｎｅＭ２Ｍサービスプロバイダからの種々のサービスに加入する。例えば、この加入には、通知サービスや、機器ディスカバリサービスや、プライバシポリシ管理が含まれる。

ステップ２で、確認応答により、ＡＥが加入した可能性のある全ての加入申し込みが確認される。

ステップ３で、ユーザは、ｏｎｅＭ２Ｍサービス層内の専用ＡＥである、加入者管理ポータル（ＳＭＰ）と呼ばれるインテフェースを介してｏｎｅＭ２ＭシステムのＣＳＥにアクセスする。ユーザプロファイルを作成するために、ユーザはリクエスト内に認証情報を含めて送信する。ユーザの認証情報には、ユーザのファーストネームと、ＳＳＮまたは運転免許証番号などの特有の識別情報と、その他の情報が含まれている。これらの情報は、作成されるユーザプロファイルリソース毎に子リソースおよび属性として具現される。

ステップ４で、ｏｎｅＭ２Ｍサービス層は、リクエスト元のユーザの情報を含む「ユーザプロファイル」リソースを作成する。このリソースは、作成者ＣＳＥの「ＣＳＥベース」リソースの子リソースとして作成される。ユーザに関連する追加情報も、「ユーザプロファイル」リソースの子リソースまたは「ユーザプロファイル」リソースの属性のいずれかとして具現される。例えば、「ユーザプロファイル１（<userProfile1>）」がメインのユーザプロファイルリソースで、リンクＡＥとＧＰＳ座標（GPSCoordinates）とが「ユーザプロファイル１」の属性になる。

別の例では、「ｍ２ｍサービス加入プロファイル」リソースを用いて「ユーザプロファイル」の子リソースが作成される。このように、「ユーザプロファイル」子リソースを有するユーザはサービス層の「ＣＳＥベース」リソースを用いて加入申し込みを行う。関連する「サービス加入ノード」リソースと「サービス加入アプリケーション規則」リソースとによって、ユーザがアクセスを認証される「ノード」リソースと「ＡＥ」リソースとが規定される。

ステップ５で、ｏｎｅＭ２Ｍサービス層のＣＳＥが、「ユーザプロファイル」リソースの作成を通知する確認応答をＡＥ（ＳＭＰ）を介してユーザに返送する。

ステップ６で、ｏｎｅＭ２Ｍサービス層のＣＳＥはさらに「ユーザプロファイル」リソースの作成についての通知をＡＥ（ＡＳＰ）に送る。

ステップ７で、ＡＥ（ＡＳＰ）は、「ユーザプロファイル」の作成の通知の受領を示す確認応答をｏｎｅＭ２Ｍサービス層に返送する。

ユーザプロファイルが作成されると、次のステップでそのユーザプロファイルを「ノード」、「ＡＥ」、または「リモートＣＳＥ」にリンクさせる。ユーザプロファイルを機器、アプリケーション、またはサービス層にリンクさせるには２つの方法がある。図２０に、ユーザのリクエストに基づいて、ユーザプロファイルを、それぞれ機器、アプリケーション、またはサービス層を表す、「ノード」、「ＡＥ」、または「リモートＣＳＥ」リソースにリンクさせることに関連する手順を示す。

ステップ１で、ＡＥ（ＳＭＰ）経由のユーザが、「ユーザプロファイル」リソースで表される自身のユーザプロファイルと「ノード」、「ＡＥ」、または「リモートＣＳＥ」リソースとのリンクをｏｎｅＭ２Ｍサービス層のＣＳＥにリクエストする。このリクエストは機器、アプリケーション、またはサービス層の認証情報とユーザの認証情報とを含んでいる。

ステップ２で、ｏｎｅＭ２Ｍ／ＩｏＴサービス層がこのリクエストを受け取って処理する。これにより、サービス層のＣＳＥが、それぞれがリンクされた機器、アプリケーション、またはサービス層のエンティティを表す、リンクノード、リンクＡＥ、またはリンクＣＳＥ属性を用いて、「ユーザプロファイル」リソースを更新する。ＣＳＥはさらに、リンクした「ノード」リソース、「ＡＥ」リソース、および「リモートＣＳＥ」リソースのそれぞれをリンクユーザ属性によって更新して、機器、アプリケーション、またはサービス層のエンティティにそれぞれリンクされたユーザを示す。

別の例では、複数のユーザプロファイルが「ノード」、「ＡＥ」、または「リモートＣＳＥ」リソースにリンクされる。この実装はケースバイケースで変化する。

ステップ３で、ｏｎｅＭ２Ｍ／ＩｏＴサービス層は、機器、アプリケーション、またはサービス層へのユーザの結合プロセスが完了したことを示す通知を、ＡＥを介してユーザに返送する。

第２方法は、この方法によりユーザプロファイルが機器、アプリケーション、またはサービス層にリンクする方法であり、機器、アプリケーション、またはサービス層からの登録リクエストであって、それぞれとリンクされる必要のあるユーザを含む登録リクエストに基づく方法である。図２１は、ｏｎｅＭ２Ｍシステムにおけるノード、ＡＥ、またはＣＳＥがどのようにしてこのリクエストを作成するかを示す図である。

ステップ１で、ノード、ＡＥ、またはＣＳＥが、それぞれがリンクを所望するユーザの表示を含む登録リクエストをＩｏＴサーバに送る。このリクエストはリンクキーを含む。

ステップ２で、ｏｎｅＭ２Ｍサービス層が、リクエスト元のノード、ＡＥ、またはＣＳＥを登録する。さらに、リクエストに示されたユーザのユーザプロファイルが、リクエスト元でかつ登録済みのノード、ＡＥ、またはＣＳＥにリンクされる。ｏｎｅＭ２Ｍサービス層はさらに、ステップ１で提示されたリンクキーが、リクエスト元がリンクを望むユーザの記録内のリンクキーに整合していることを確認する。この結果、リンクされたノード、ＡＥ、またはＣＳＥの記録またはリソースの表示とユーザの記録またはリソースの表示とが追加または更新されて、前記リンクすなわち関連付けが示される。図１８において、リンクされたユーザのユーザプロファイルは、「ノード」、「ＡＥ」、および「ＣＳＥ」リソースにおけるリンクユーザ属性として表されている。

ステップ３で、示されたユーザに対する登録とリンクとのプロセスの成否についての確認応答が、リクエスト元のノード、ＡＥ、またはＣＳＥに返送される。

ステップ４で、ｏｎｅＭ２Ｍサービス層は、ノード、ＡＥ、またはＣＳＥによって行われたリンクのリクエストについての通知を（ＳＭＰを具現した）ＡＥを介して送る。この通知はユーザに転送される。

ステップ５で、ユーザは当該ｏｎｅＭ２Ｍサービス層を承認する、またはユーザプロファイルをリクエスト元のノード、ＡＥ、またはＣＳＥとリンクするリクエストを送る。

ステップ６で、ユーザの同意を得ると、ｏｎｅＭ２Ｍシステムは、ユーザプロファイルとリクエスト元のノード、ＡＥ、またはＣＳＥとのリンクを仕上げる。これによってユーザの記録またはリソースの表示が追加または更新されて、前記リンクすなわち関連付けが示される。

ステップ７で、ｏｎｅＭ２Ｍサービス層が、ユーザとノード、ＡＥ、またはＣＳＥとのリンクの完了についての確認応答を、リクエスト元のノード、ＡＥ、またはＣＳＥに返送する。

ステップ８で、ｏｎｅＭ２Ｍサービス層は、ユーザのユーザプロファイルとリクエスト元のノード、ＡＥ、またはＣＳＥとのリンクの完了についての通知をＡＥを介してユーザに送る。

前述のデータ匿名化に係るプロセスには、このプロセスに関係するエンティティがどのようにｏｎｅＭ２Ｍドメイン内のエンティティに関係するかについての記述が含まれている。図１５に、ＰＰＳとＤＡＳとを用いて私事化（匿名化）版のユーザデータを提供しつつ、サードパーティによるＩｏＴサーバへのデータリクエストを処理する間の、関連する方法のコールフローの例を示す。この手順はｏｎｅＭ２Ｍシステムに適用可能である。アプリケーションサービスプロバイダ（ＡＳＰ）が、サードパーティエンティティにユーザデータのリクエストを送らせるＡＥになる。このデータメッセージのリクエストは、Ｍｃａインタフェースを介して送られるＲＥＳＴｆｕｌ ＲＥＴＲＩＥＶＥ動作になる。ＩｏＴサーバは、システムサーバが存在する場所、または実装の種類に応じてＩＮ－ＣＳＥ、ＭＮ－ＣＳＥ、またはＡＳＮ－ＣＳＥのいずれかになる。本記載のとおり、プライバシポリシサービス（ＰＰＳ）がｏｎｅＭ２Ｍ ＣＳＦまたはＰＲＰとして機能する。データ匿名化サービス（ＤＡＳ）はｏｎｅＭ２Ｍシステム内のｏｎｅＭ２Ｍ ＣＳＦまたはＰＥＰ／ＰＤＰである。

図２２に、ｏｎｅＭ２Ｍ／ＩｏＴシステムにおけるデータ匿名化手順のコールフロー図を示す。この図は、「ユーザプロファイル」リソースが作成されて、「ノード」、「ＡＥ」、または「ＣＳＥ」リソースがその「ユーザプロファイル」リソースにリンクされたことを前提としている。

ステップ１で、ＡＳＰを具現したＡＥがＭｃａインタフェースを介してｏｎｅＭ２ＭシステムにＲＥＳＴｆｕｌ読み出しリクエストを送る。このリクエストがｏｎｅＭ２Ｍシステムに受信されると、ユーザデータのリクエストが識別される。このデータリクエストは、リクエスト元の選好度（データのカテゴリに基づいて定まる）、日付範囲、位置などを含む。

ステップ２で、ｏｎｅＭ２ＭシステムがＡＥからのリクエストを識別し、ＣＳＥが、ＡＥから受け取ったリクエストに適用可能なデータ匿名化ポリシを要求する。

ステップ３で、ＣＳＥからリクエストを受け取ると、ＰＲＰとして機能するＰＰＳが、行政機関の法的要件／ポリシと、ユーザの選好度と、データコンシューマの選好度とをそれぞれのデータベースから検索する。これらの必要情報は別々のまたは１つのデータベースに存在している。これらの必要情報に基づいて、ＰＰＳはデータ匿名化に適用可能なポリシを策定する。

ステップ４で、ＰＰＳは策定された匿名化ポリシをＣＳＥに転送する。

ステップ５で、ＣＳＥがユーザデータとポリシとをデータ匿名化サービス（ＤＡＳ）に供給する。

ステップ６で、ＤＡＳがｏｎｅＭ２ＭシステムにおけるＰＥＰ／ＰＤＰとして機能する。匿名化ポリシが原ユーザデータに適用される。これにより、匿名化／私事化版のユーザデータが作成される。

ステップ７で、ＤＡＳが匿名化版のデータをＣＳＥに転送する。

ステップ８で、ＣＳＥは匿名化版のユーザデータを、ＲＥＳＴｆｕｌ通信を介してリクエスト元のＡＥに送る。この応答には、データが匿名化されたことを示す通知が含まれている。さらに、この応答は、どの匿名化技術がデータに適用されたかということも示している。ＡＥは、データセット全体へのアクセスをリクエストすることによってこの応答に返信する。

ある例では、ＰＰＳとＤＡＳとは、例えばゲートウェイ（またはｏｎｅＭ２Ｍの例ではＭＮ－ＣＳＥ）などのネットワークエッジにデプロイされる。これが有用となるのは、自宅所有者が自宅内に多数のＩｏＴ機器／センサをデプロイしていて、それら機器が、同様に自宅にデプロイされたゲートウェイにデータを保存するというシナリオを想定した場合である。

ネットワークエッジデプロイメントのシナリオでは、ＧＷのオーナは、どのようにデータを匿名化するか、およびどのデータを関連のサードパーティに公表するか、に関するポリシでＧＷを設定する。

さらに、ＧＷは、家庭内に見られる、様々なユーザ、機器、およびデータセットに対して矛盾のないエイリアスをもたらすエイリアスポリシで設定される。矛盾のないエイリアシングは、データコンシューマが週に一度機器についてのデータを読み出すシナリオにおいて重要になる。コンシューマは、データを取得する度に、読み出した情報を一週間前に得た読み出し情報と関連付ける必要がある。この種のデプロイメントには、分散データ匿名化サービスとの関連で前述した手続き型のフローが使用される。

あるｏｎｅＭ２Ｍの実施形態例では、ユーザが、自宅のゲートウェイに登録された複数の機器（例えば、スマートウォッチ、健康監視機器置、スマートアプリケーションなど）を有している。これらの機器がＡＤＮ－ＡＥになり、ゲートウェイがＭＮ－ＣＳＥになる。ＡＤＮ－ＡＥはＭＮ－ＣＳＥに登録している。ＭＮ－ＣＳＥ（ゲートウェイ）はｏｎｅＭ２Ｍサービスプロバイダが所有するＩＮ－ＣＳＥに登録している。

ＩＮ－ＣＳＥは、ユーザプロファイルをそのリソースツリー内に作成可能な、ＩＮ－ＡＥに接続されている。ＩＮ－ＡＥは、新たなユーザプロファイルの作成に用いられる。新しいユーザプロファイルを作成することで必然的に「ユーザプロファイル」リソースが作成される。このユーザプロファイルは、「ユーザプライバシプロファイル」サブリソースを含んでいる。「ユーザプライバシプロファイル」サブリソースは、どのサードパーティ（ＩＮ－ＡＥ）がユーザに関連するデータへのアクセスを許可されているかのリストとなっている。さらに、この「ユーザプライバシプロファイル」サブリソースは、各サードパーティ（ＩＮ－ＡＥ）からのリクエストの処理の仕方も示している。例えば、このサブリソースが、あるＩＮ－ＡＥを全データの閲覧が可能な認可サードパーティと特定し、別のＩＮ－ＡＥを制限されたサードパーティと特定することもある。このポリシはさらに、データアクセスの制限方法（例えば、ＩＮ－ＡＥが所定のタイプのデータしか見ることができないか、または所定のタイプのデータを見ることを許容されないか、など）を示している。このポリシは、本明細書で述べた「ユーザプライバシプロファイル」のサブリソースまたは属性に規定されている。

ＡＮＤ－ＡＥの１つは、オーナの心拍数と運動活動とを追跡するスマートウォッチである。これらの値はゲートウェイに保存されてＩＮ－ＣＳＥに報知される。

サードパーティＩＮ－ＡＥの一方は、スマートウォッチのオーナが活動の概略を見ることができる健康監視アプリケーションである。このＩＮ－ＡＥは、ＡＳＰである場合、図１６に示したデータの読み出しをリクエストする。ＩＮ－ＣＳＥがＩｏＴサーバになり、プライバシポリシサービスとデータ匿名化サービスとがＣＳＦになる。ステップ２で、ＩＮ－ＣＳＥがプライバシポリシサービスを呼び出すと、「ユーザプライバシプロファイル」のポリシがプライバシポリシサービスに与えられ、これを用いて健康監視システムがオーナの全データを見ることを許可することが決定される。プライバシポリシサービスにより作成されてステップ４で提供されたポリシは、ＩＮ－ＡＥがユーザの全データにアクセス可能なことを示している。ステップ５で、このポリシが報知されたデータと併せてデータ匿名化サービスに提供される。ステップ７で、データ匿名化サービスは、ユーザの活動の全てを表すデータセットをＩＮ－ＣＳＥに提供する。次いでこのデータがＩＮ－ＡＥに提供される。

サードパーティＩＮ－ＡＥのもう１方は、オーナの保険料の割引が得られるようにオーナの運動活動を観察可能な健康保険アプリケーションである。しかし、オーナとしては、健康保険会社がオーナの活動の詳細（例えば、心拍数）を見ることを防ぐかもしくは制限したい意向である。このＩＮ－ＡＥは、ＡＳＰである場合、図１６に示したデータの読み出しをリクエストする。ＩＮ－ＣＳＥがＩｏＴサーバになり、プライバシポリシサービスとデータ匿名化サービスとがＣＳＦになる。ステップ２で、ＩＮ－ＣＳＥがプライバシポリシサービスを呼び出すと、「ユーザプライバシプロファイル」のポリシがプライバシポリシサービスに与えられ、これを用いて健康保険会社がオーナの運動時間だけを見ることを許可され、他の健康測定項目は閲覧を許可されないことが決定される。プライバシポリシサービスにより作成されてステップ４で提示されたポリシは、ＩＮ－ＡＥがオーナの運動時間だけを見ることを許可され、他の健康測定項目は見ることを許可されないことを示している。ステップ５で、このポリシが報知されたデータと併せてデータ匿名化サービスに提供される。ステップ７で、データ匿名化サービスは、オーナの運動時間だけを含むデータセットをＩＮ－ＣＳＥに提供する。次いでこのデータがＩＮ－ＡＥに提供される。

図２３に、図１１に示した例のｏｎｅＭ２Ｍ／ＩｏＴに特化した実装を示す。図２３は、ＰＰＳとＤＤＳとがインフラストラクチャノードのサービス層またはミドルノードのサービス層のいずれかに位置できることを示している。複数のＡＳＰがそれぞれ、Ｍｃａ機器（例えば、スマートメータ）を介してＩＮ－ＣＳＥまたはＭＮ－ＣＳＥに接続したＡＥとして具現される個々のアプリケーションを備え、ＡＥまたはＣＳＥとして機能し、かつＭｃａまたはＭｃｃを介してＩＮ－ＣＳＥまたはＭＳ－ＣＳＥに接続している。ユーザは、ＡＥとして示されたアプリケーションを用いて、Ｍｃａを介してかつ加入者管理ポータルと呼ばれる特別のアプリケーションを通じてＩＮ－ＣＳＥまたはＭＳ－ＣＳＥに接続する。ＰＰＳとＤＡＳとは、この実装ではｏｎｅＭ２Ｍ／ＩｏＴ共通サービス機能として存している。

３ＧＰＰ実施形態例において、３ＧＰＰ ５Ｇコアネットワークでは、ＮＷＤＡネットワーク機能が、ネットワークの性能、特定のネットワークスライス、特定のネットワーク機能、特定のユーザ、特定の機器、および／または特定の加入者に関するデータ（ユーザ、加入者、および機器の種類も併せて）を収集する。このデータは、ＡＦとの直接インタフェースを介してサードパーティアプリケーション機能に公表される。これに加えてまたはこれに代えて、ＡＦがＮＥＦ（Network Exposure Function）を介してリクエストを行うこともある。

前述のとおり、サードパーティＡＦに公表されるデータは匿名化される必要がある。プライバシポリシサービスとデータ匿名化サービスとは仮想化ネットワーク機能として３ＧＰＰ ５Ｇコアネットワークにデプロイされ、データがサードパーティアプリケーション機能に公表される前のデータのサニタイズを支援するために用いられる。

プライバシポリシサービスが新しいスタンドアロンＮＦとしてデプロイされる。またはＰＰＳ機能が、ＮＷＤＡ、ＰＣＦ、またはＮＥＦなどの既存のＮＦと統合される。ＰＰＳは、データの匿名化方法に関するポリシをＵＤＲ（User Data Repository）に保存する。適正にポリシを策定するために、ＰＰＳは、ネットワークと、ユーザと、加入者と、サードパーティアプリケーションとのそれぞれの選好度をＵＤＲから取得する。ＰＰＳがＵＤＲにアクセスするとき、そのアクセスは直接アクセスまたはＵＤＭを介したアクセスである。

データ匿名化サービス（ＤＡＳ）が新しいスタンドアロンＮＦとしてデプロイされる。またはＰＰＳ機能が、ＮＷＤＡ、ＰＣＦ、またはＮＥＦなどの既存のＮＦと統合される。適正にデータを匿名化するために、ＤＡＳはＰＰＳまたはＵＤＲからプライバシポリシを取得する。これに加えてまたはこれに代えて、プライバシポリシがデータ匿名化リクエストによりＤＡＳに提供されることもある。ＰＰＳがＵＤＲにアクセスするとき、そのアクセスは直接アクセスまたはＵＤＭを介したアクセスになる。なお、ＰＰＳ機能とＤＡＳ機能とは１つのＮＦに統合されてもよい。詳細例を図２４に示す。また、以下で説明する。

ステップ１で、サードパーティアプリケーション機能が、読み出しデータサービスを呼び出すことにより、一連のデータのリクエストをＮＷＤＡに送る。このリクエストは直接ＮＷＤＡにアドレスして行われるか、またはＮＥＦを介して行われる。このリクエストは少なくともＡＦがリクエストしているデータセットの種類を示している。このリクエスト動作はデータセット識別子を示すことによって行われる。このリクエストはさらに、ＡＦが個々のまたはグループとしてのユーザ、加入者、機器、またはネットワークに属するデータを欲していることを示している。またこのリクエストは、認証キーであって、ＡＦがリクエストデータを取得することを認められていることを確認するためにネットワークによってベリファイ／認証可能な認証キーを含んでいる。

ステップ２で、ＮＥＦはこのデータリクエストとＡＦ識別子とをＮＷＤＡに転送する。ＮＥＦは最初に、ＡＦがデータを利用することを認められているかどうかをチェックするためにＵＤＭ／ＵＤＲＭにクエリすることによってＡＦからのリクエストを認証する。ＵＤＭ／ＵＤＲクエリはさらに提出された認証キーが正しいかどうかをベリファイする。

ステップ３で、ＮＷＤＡは、どのデータセットがリクエストされたか、誰がデータ（ＡＦ識別子）をリクエストしているか、およびデータに関連するユーザ、加入者、および機器についての通知をＰＰＳに送る。ＰＰＳは、データに関連するユーザ、加入者、および機器に関するポリシまたは選好度を取得する。例えば、ＰＰＳは上記ポリシと選好度とをＵＤＭ／ＵＤＲから取得する。次いでＰＰＳは、リクエストされたデータをどのように匿名化するのがよいかを示すポリシを策定する。

ステップ４で、ＰＰＳは、ここに述べたポリシでＮＷＤＡに応答する。このポリシは、該データセットにアクセス可能でかつそのデータセットに上記ポリシを適用可能なＤＡＳの識別情報を含んでいる。なお、ＰＰＳはこのポリシをＵＤＲなどのストレージ機能に保存していることもあり、この場合ＰＰＳは単にポリシに対する識別子（すなわちポインタ）をＮＷＤＡに提供するのみである。

ステップ５で、ＮＷＤＡは、データが匿名化されることを要求するリクエストをＤＡＳに送る。このリクエストは、データおよびポリシまたはデータおよびポリシに対するポインタを含んでいる。

ステップ６で、ＤＡＳはポリシを本記載のデータセットに適用して、匿名化されたデータをＮＷＤＡに提供する。前のステップのリクエストがデータおよび／またはポリシへのポインタを含んでいた場合は、ＤＡＳは、データにポリシを適用する前に適当なストレージ機能からデータおよび／またはポリシを検索する必要がある。

ステップ７で、ＮＷＤＡは、リクエストされたデータセット（匿名化されている）でＡＦに応答する。この応答はＮＥＦを介してＡＦに送られる。

ステップ８で、ＮＥＦがＡＦに応答する。

さらにＡＦからＮＥＦへのリクエストは、ＡＦが、所定の機器、加入者、またはユーザがネットワークに向かうトラヒック内にメタデータを挿入して、それによりＡＭＦ、ＳＭＦ、およびＵＰＦなどのＮＦがメタデータを収集してＮＷＤＡに転送するようにしたい、と考えていることも示している。ＮＥＦはこのリクエストをＰＣＦに転送する。次いでＰＣＦは、ＵＥがメタデータをネットワークに送ることを示す、更新されたＵＳＲＰをＵＥに送る。ＵＥからの分析データがＮＷＤＡに保存されると、データをサードパーティアプリケーションサーバに転送する前に図２４の手順を用いてデータが匿名化される。

あるサービス層のエンティティは、アプリケーションサービスプロバイダから、サービス層のエンティティの特定のユーザに関連するデータにアクセスするリクエストを受け取り、そのデータアクセスリクエストに基づいて１つ以上のプライバシポリシが該特定のユーザに関連していることを確認し、その１つ以上のプライバシポリシを検索し、該１つ以上のプライバシポリシに基づいて、アプリケーションサービスプロバイダが上記特定のユーザの１つ以上の識別特徴を確認することを防ぐ匿名化データセットを作成し、かつその匿名化データセットをアプリケーションサービスプロバイダに送るように構成される。

匿名化データセットの作成は、データの少なくとも一部を削除することとデータの少なくとも一部を変更することとのいずれかまたは両方を含む。データの少なくとも一部の変更は、データの少なくとも一部の省略と、データの少なくとも一部の置き換えと、データの少なくとも一部のシャッフルと、データの少なくとも一部の暗号化との１つ以上を含む。１つ以上のプライバシポリシは、特定のユーザに関連する１つ以上のユーザポリシと、１つ以上のアプリケーションサービスプロバイダポリシと、１つ以上の法的ポリシとを含む。特定のユーザに関連するデータにアクセスするリクエストは、アプリケーションサービスプロバイダに関連する１つ以上の特徴を含む。匿名化データセットの送信には、データが匿名化されていることの通知と、データの匿名化に用いられた匿名化技術の通知とのいずれかまたは両方をアプリケーションサービスプロバイダに送信することを含む。サービス層のエンティティはさらに、少なくともアプリケーションサービスプロバイダに関連する１つ以上の特徴に基づいて、特定のユーザに関連する複数のプライバシポリシの内の１つ以上を選択するように構成される。

あるサービス層のエンティティは、１つ以上のデータアクセスパラメータを初期化し、１つ以上のプライバシポリシをプライバシポリシサービスから検索し、該１つ以上のプライバシポリシをサービス層のエンティティに保存し、サービス層のエンティティに保存されたデータの少なくとも一部にアクセスするリクエストをアプリケーションサービスプロバイダから受け取り、保存されたプライバシポリシの１つ以上が上記データの一部に適用可能であることを確認し、その１つ以上のプライバシポリシに基づいて該データの一部を匿名化してアプリケーションサービスプロバイダが前記データの一部に関連する特定のユーザの１つ以上の識別特徴を確認することを防ぎ、かつその匿名化されたデータをアプリケーションサービスプロバイダに送るように構成される。

データの匿名化は、データの少なくとも一部を削除することとデータの少なくとも一部を変更することとのいずれかまたは両方を含む。データの少なくとも一部の変更は、データの少なくとも一部の省略と、データの少なくとも一部の置き換えと、データの少なくとも一部のシャッフルと、データの少なくとも一部の暗号化との１つ以上を含む。１つ以上のプライバシポリシは、特定のユーザに関連する１つ以上のユーザポリシと、１つ以上のアプリケーションサービスプロバイダポリシと、１つ以上の法的ポリシとを含む。１つ以上のデータアクセスパラメータはサービス層登録手順の一部として初期化される。データの一部にアクセスするリクエストは、アプリケーションサービスプロバイダに関連する１つ以上の特徴を含む。匿名化データセットの送信には、データが匿名化されていることの通知と、データの匿名化に用いられた匿名化技術の通知とのいずれかまたは両方をアプリケーションサービスプロバイダに送信することを含む。サービス層のエンティティはさらに、少なくともアプリケーションサービスプロバイダに関連する１つ以上の特徴に基づいて、サービス層のエンティティに保存されたプライバシポリシの所定の１つを選択するように構成される。

あるサービス層のエンティティは、機器と１つ以上のユーザプロファイルとのリンクの指示を含むリンクリクエストを機器から受け取り、その機器をそのサービス層のエンティティに登録し、上記リンクリクエストに基づく通知を加入者管理ポータルに送り、１つ以上のユーザプロファイルに関連するユーザがリンクリクエストを承認したことの通知を加入者管理ポータルから受け取り、かつ該サービス層のエンティティにおいて機器と１つ以上のユーザプロファイルとをリンクするように構成される。

リンクリクエストはキーを含む。サービス層のエンティティは、機器から受け取ったリンクキーがユーザプロファイルに関連するリンクキーに整合することを確認するように構成される。サービス層のエンティティは、機器と１つ以上のユーザプロファイルとがリンクされたことの通知を、機器と加入者管理ポータルとのいずれかまたは両方に送るように構成される。機器は、ユーザ機器と、アプリケーションと、サービス層のエンティティとのいずれかである。

サービス層、サービス層機器、サービス層アプリケーション、およびアプリケーションエンティティなどの、図５、６、９～１７、および１９～２４に示した諸ステップを実行するエンティティは全て、ソフトウェア（すなわち、コンピュータで実行可能な命令）の形で実装される論理エンティティであって、図２５Ｃに示したような無線および／またはネットワーク通信用に構成された装置または図２５Ｄに示したようなコンピュータシステムのメモリに保存されてそのプロセッサで実行される論理エンティティである。すなわち、図５、６、９～１７、および１９～２４に示した方法は、図２５Ｃまたは図２５Ｄに示した装置またはコンピュータシステムなどの装置のメモリに保存されたソフトウェア（すなわち、コンピュータで実行可能な命令）の形で実装され、そのコンピュータで実行可能な命令は、装置のプロセッサによって実行されると、図５、６、９～１７、および１９～２４に示した諸ステップを実行する。図５、６、９～１７、および１９～２４に示した送信と受信とのステップは、装置のプロセッサとそのプロセッサが実行するコンピュータで実行可能な命令（例えば、ソフトウェア）の制御の下で装置／エンティティの通信回路によって実行される。

図２５Ａは、１つ以上の本開示の実施形態が実施される、マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の一例を示す図である。一般に、Ｍ２Ｍ技術によりＩｏＴ／ＷｏＴの構成要素が与えられ、あらゆるＭ２Ｍ機器、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２ＭサービスプラットフォームはＩｏＴ／ＷｏＴならびにＩｏＴ／ＷｏＴサービス層などのコンポーネントまたは装置になる。図１～図２４の全てに示したエンティティはいずれも、例えば、図２５Ａ～図２５Ｄに示したような、通信システムのネットワーク装置を含む。

サービス層はネットワークサービスアーキテクチャ内の機能層である。サービス層は通常ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴなどのアプリケーションプロトコル層の上に位置して、付加価値サービスをクライアントアプリケーションに提供する。さらにサービス層は、例えば、制御層やトランスポート／アクセス層などの、下位のリソース層のコアネットワークにインタフェースを提供する。サービス層は、サービスの定義、サービスランタイムイネーブルメント、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む、複数のカテゴリの（サービス）機能をサポートする。近年、いくつかの業界標準団体（例えば、ｏｎｅＭ２Ｍなど）によりＭ２Ｍサービス層が開発されており、これによりＭ２Ｍタイプの機器とアプリケーションとを、インターネット／ウェブネットワーク、セルラネットワーク、企業ネットワーク、およびホームネットワークなどのデプロイメントに統合することに伴う課題の解決が図られている。Ｍ２Ｍサービス層は、アプリケーションおよび／または種々の機器に、該サービス層にサポートされた一連の上述の機能へのアクセスを提供するもので、ＣＳＥまたはＳＣＬ（サービス機能層：Service Capability Layer）とも呼ばれる。数種の例として、限定するものではないが、様々なアプリケーションで一般に用いられる、セキュリティ、課金、データ管理、機器管理、ディスカバリ、プロビジョニング、および接続性管理がある。これらの機能は、ＡＰＩを介して、Ｍ２Ｍサービス層に規定されたメッセージフォーマット、リソース構造、およびリソース表現を用いるアプリケーションに利用できるようにされる。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実施される機能エンティティであって、公表される（サービス）機能を種々のアプリケーションおよび／または機器（すなわち、上記機能エンティティ間の機能インタフェース）に提供してそれらアプリケーション等が前記機能を使えるようにする機能エンティティである。

図２５Ａに示したとおり、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は通信ネットワーク１２を備えている。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ（integrated service digital network）、ＰＬＣ（Power Line Communication）など）、または無線ネットワーク（例えば、ＷＬＡＮ、セルラなど）、または異機種ネットワークである。例えば、通信ネットワーク１２は、多重アクセスネットワークであって、音声、データ、映像、メッセージング、放送などのコンテンツを複数のユーザに提供する多重アクセスネットワークからなる。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）などの１つ以上のチャネルアクセス方式を用いる。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、または企業ネットワークなどの他のネットワークを含む。

図２５Ａに示したとおり、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０はインフラストラクチャドメインとフィールドドメインとを備えている。インフラストラクチャドメインとは終端間Ｍ２Ｍデプロイメントのネットワーク側を指し、フィールドドメインとは（通常はＭ２Ｍゲートウェイの背後にある）エリアネットワークを指す。フィールドドメインとインフラストラクチャドメインとは共にネットワークの様々なネットワーク装置（例えば、サーバ、ゲートウェイ、機器など）を含む。例えば、フィールドドメインはＭ２Ｍゲートウェイ１４と機器１８とを含む。任意の数のＭ２Ｍゲートウェイ機器１４とＭ２Ｍ機器１８とが前述のＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれることは明らかである。Ｍ２Ｍゲートウェイ機器１４とＭ２Ｍ機器１８とはそれぞれ、通信回路を用いて、通信ネットワーク１２または直接無線リンクを介して信号を送受信するように構成される。

Ｍ２Ｍゲートウェイ機器１４によって、無線Ｍ２Ｍ機器（例えば、セルラおよび非セルラなど）ならびに固定ネットワークＭ２Ｍ機器（例えば、ＰＬＣなど）が、通信ネットワーク１２または直接無線リンクなどのオペレータネットワークのいずれかを通じて通信することができる。例えば、Ｍ２Ｍ機器１８はデータを集め、そのデータを通信ネットワーク１２または直接無線リンクを介してＭ２Ｍアプリケーション２０または他のＭ２Ｍ機器１８に送る。さらにＭ２Ｍ機器１８はＭ２Ｍアプリケーション２０またはある所定のＭ２Ｍ機器１８からデータを受け取る。さらに、下記のとおり、データと信号とがＭ２Ｍサービス層２２を介してＭ２Ｍアプリケーション２０に対して送受信される。Ｍ２Ｍ機器１８とゲートウェイ１４とは、例えば、セルラ、ＷＬＡＮ（wireless local area network）、ＷＰＡＮ（wireless personal area network）（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）など）、直接無線リンク、および有線などの、様々なネットワークを介して通信を行う。Ｍ２Ｍ機器の例として、限定はしないが、タブレット、スマートフォン、医療機器、温度および天候モニタ、コネクティッド・カー、スマートメータ、ゲーム機、携帯情報端末、健康とフィットネスとのモニタ、照明、サーモスタット、電気器具、ガレージドアおよびその他のアクチュエータに基づく機器、防犯機器、およびスマートアウトレットがある。

図２５Ｂを参照する。フィールドドメインに示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０と、Ｍ２Ｍゲートウェイ１４と、Ｍ２Ｍ機器１８と、通信ネットワーク１２とにサービスを提供する。Ｍ２Ｍサービス層２２は所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ機器１８、および通信ネットワーク１２と通信可能なことは明らかである。Ｍ２Ｍサービス層２２は、ネットワークにおけるサーバ、コンピュータ、および機器などの、１つ以上のネットワーク装置によって実現される。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ機器１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に付与されるサービス機能を提供する。Ｍ２Ｍサービス層２２の機能は、セルラコアネットワークやクラウド内などにおいて、例えばウェブサーバなどの様々な方式で実装される。

インフラストラクチャドメインには、Ｍ２Ｍサービス層２２に類似したＭ２Ｍサービス層２２’が存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’と下位の通信ネットワーク１２とにサービスを提供する。さらにＭ２Ｍサービス層２２’はフィールドドメイン内のＭ２Ｍゲートウェイ１４とＭ２Ｍ機器１８とにサービスを提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍ機器と通信可能なことは明らかである。Ｍ２Ｍサービス層２２’は異なるサービスプロバイダによってサービス層と情報のやりとりを行う。Ｍ２Ｍサービス層２２’は、ネットワークにおけるサーバ、コンピュータ、機器、バーチャル・マシン（例えば、クラウドコンピューティング／ストレージファームなど）などの、１つ以上のネットワーク装置によって実現される。

さらに図２５Ｂを参照する。Ｍ２Ｍサービス層２２、２２’は、多様なアプリケーションとバーティカルとが影響を与える、サービス提供機能のコアセットを提供する。これらのサービス機能により、Ｍ２Ｍサービス層２０、２０’は、機器類と情報交換を行って、データ収集、データ分析、データ管理、保全、請求、サービス／機器のディスカバリなどの機能を実行することができる。実質的に、これらのサービス機能によって上記機能を実行する重荷からアプリケーションが解放されるので、アプリケーションの開発が簡単になり、市販化のコストと時間が低減される。さらにＭ２Ｍサービス層２２、２２’によって、Ｍ２Ｍアプリケーション２０、２０’は、サービス層２２、２２’が提供するサービスに接続したネットワーク１２などの、様々なネットワークを通じて通信を行うことができる。

Ｍ２Ｍアプリケーション２０、２０’は、限定はしないが、運輸、健康、コネクテッドホーム、エネルギ管理、資産管理、およびセキュリティならびにサーベイランスなどの様々な産業におけるアプリケーションを含む。前述のとおり、Ｍ２Ｍサービス層は機器、ゲートウェイ、サーバ、およびシステムにおけるその他のネットワーク装置にわたって動作し、例えば、データ収集、機器管理、セキュリティ、請求、位置の追跡／ジオフェンシング、機器／サービスのディスカバリ、およびレガシーシステムの統合などの機能をサポートし、かつこれらの機能をサービスとしてＭ２Ｍアプリケーション２０、２０’に提供する。

一般に、図２５Ｂに示したサービス層２２、２２’などのサービス層により、一連のアプリケーションプログラミングインタフェース（ＡＰＩ）と下位のネットワークインタフェースとを通じて付加価値機能をサポートする、ソフトウェア（ミドルウェア）層が規定される。ＥＴＳＩ Ｍ２ＭアーキテクチャとｏｎｅＭ２Ｍアーキテクチャとは共にサービス層を規定する。ＥＴＳＩ Ｍ２Ｍのサービス層はサービス機能層（ＳＣＬ）と呼ばれる。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの様々な異なるノードで具現される。例えば、サービス層のインスタンスは、Ｍ２Ｍ機器（機器ＳＣＬ（ＤＳＣＬ）と呼ばれる）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と呼ばれる）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と呼ばれる）内で実装される。ｏｎｅＭ２Ｍサービス層は一連の共通サービス機能（ＣＳＦ）（すなわち、サービス機能（service capabilities））をサポートする。一連の１つ以上の特定タイプのＣＳＦをインスタンス化したものは共通サービスエンティティ（ＣＳＥ）と呼ばれ、このエンティティは、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、特定用途向けノードなど）で動作する。第３世代パートナシッププロジェクト（３ＧＰＰ）もマシンタイプコミュニケーション（ＭＴＣ）のアーキテクチャを規定している。このアーキテクチャでは、サービス層とサービス層が提供するサービス機能とはサービス機能サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬ、３ＧＰＰ ＭＴＣアーキテクチャのサービス機能サーバ（ＳＣＳ）、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥ、またはその他のネットワークノードのいずれで実施された場合でも、サービス層のインスタンスは論理エンティティ（例えば、ソフトウェア、コンピュータで実行可能な命令など）であって、サーバ、コンピュータ、およびその他のコンピュータ機器またはノードなどの、ネットワークにおける１つ以上のスタンドアロンノードのいずれかで実行される論理エンティティとして、または１つ以上の既存のノードの一部として実装される。一例として、サービス層またはそのサービス層のコンポーネントのインスタンスは、以下に述べる図２５Ｃまたは図２５Ｄに示す一般的アーキテクチャを有するネットワーク装置（例えば、サーバ、コンピュータ、ゲートウェイ、機器など）上で走るソフトウェアの形で実装される。

さらに、本記載の方法と機能とは、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を用いてサービスにアクセスするＭ２Ｍネットワークの一部として実装される。

デプロイメントの面では、サービス層は、本記載の様々な形態で示したサーバ、ゲートウェイ、および機器を含む様々なタイプのネットワークノードにデプロイされる。サービス層の機能を実装した、もしくはサービス層のインスタンスを組み込んだ通信ネットワークの、このようなノード、サーバ、ゲートウェイ、機器、装置、または他の論理エンティティはいずれも本明細書ではサービス層のエンティティと呼ばれる。

図２５Ｃは、図２５Ａおよび図２５Ｂに示したネットワークなどのＭ２ＭネットワークにおけるＭ２Ｍサーバ、ゲートウェイ、機器、または他のネットワーク装置として動作する、図１～２４に示したエンティティのいずれかなどの、ネットワークの装置のハードウェア／ソフトウェアアーキテクチャの一例のブロック図である。図２５Ｃに示したとおり、ネットワーク装置３０は、プロセッサ３２、非着脱式メモリ４４、着脱式メモリ４６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ、タッチパッド、および／またはインディケータ４２、電源４８、全地球測位システム（ＧＰＳ）チップセット５０、および他の周辺機器５２を備えている。ネットワーク装置３０はさらに、トランシーバ３４と送受信素子３６などの通信回路を備えている。ネットワーク装置３０が、実施形態と矛盾することなく前述の部品の任意のサブコンビネーションを備え得ることは言うまでもない。このネットワーク装置は、図５、６、９～１７、および１９～２４との関連で説明した諸操作などの、本記載のデータ匿名化方法を実施する装置である。

プロセッサ３２として、汎用プロセッサ、特定用途向けプロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに付随した１つ以上マイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、その他各種の集積回路（ＩＣ）、状態機械などがある。一般に、プロセッサ３２は、ネットワーク装置の様々な要求機能を果たすために、ネットワーク装置のメモリ（例えば、メモリ４４および／またはメモリ４６）に保存されたコンピュータで実行可能な命令を実行する。例えば、プロセッサ３２は、信号コーディング、データ処理、電力制御、入出力処理、および／またはネットワーク装置３０が無線または有線環境で動作できるようにする他の各種機能を実行する。プロセッサ３２は、アプリケーション層のプログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）のプログラムおよび／または他の通信プログラムを実行する。さらにプロセッサ３２は、例えば、アクセス層および／またはアプリケーション層などにおいて、認証、セキュリティキーの承諾、および／または暗号動作などのセキュリティ動作を行う。

図２５Ｃに示したとおり、プロセッサ３２は通信回路（例えば、トランシーバ３４と送受信素子３６）に接続されている。プロセッサ３２がコンピュータで実行可能な命令の実行を通じて通信回路を制御することで、ネットワーク装置３０が該装置３０に接続されたネットワークを介して他のネットワーク装置と通信する。特に、プロセッサ３２は通信回路を制御して本明細書（例えば、図５、６、９～１７、および１９～２４に図示）ならびに請求の範囲に記載の送受信ステップを実行する。図２５Ｃではプロセッサ３２とトランシーバ３４とは別々の構成要素として示されているが、プロセッサ３２とトランシーバ３４とは１つの電子パッケージまたはチップに集積してもよい。

送受信素子３６は、Ｍ２Ｍサーバ、ゲートウェイ、機器などの、他のネットワーク装置に信号を送信する、または該ネットワーク装置から信号を受信するように構成される。例えば、一実施形態において、送受信素子３６は、ＲＦ（無線周波数）信号を送信および／または受信するように構成されたアンテナである。送受信素子３６は、ＷＬＡＮ、ＷＰＡＮ、セルラなどの様々なネットワークおよびエアインタフェースをサポートする。一実施形態において、送受信素子３６は、例えば、ＩＲ、ＵＶ、または可視光の信号を送信および／または受信するように構成されたエミッタ／ディテクタである。さらに別の実施形態において、送受信素子３６はＲＦ信号と光信号との両方を送受信するように構成される。送受信素子３６は、任意の組み合わせによる無線または有線信号を送信および／または受信するように構成可能なことは明らかである。

さらに、図２５Ｃでは送受信素子３６は１つの素子として図示されているが、ネットワーク装置３０は任意の数の送受信素子３６を含むことができる。より詳細には、ネットワーク装置３０はＭＩＭＯ技術を採用している。したがって、ある実施形態では、ネットワーク装置３０は２つ以上の送受信素子３６（例えば、複数のアンテナ）を備えて無線信号の送受信を行っている。

トランシーバ３４は、送受信素子３６が送信する信号を変調すると共に、送受信素子３６が受信した信号を復調する。前述したとおり、ネットワーク装置３０は多モードの機能を有している。したがって、トランシーバ３４は複数のトランシーバを含んでおり、それによりネットワーク装置３０が、例えば、ＵＴＲＡ（Universal Terrestrial Radio Access）およびＩＥＥＥ ８０２．１１などの、複数のＲＡＴ（Remote Administration Tool）を介して通信できるようになっている。

プロセッサ３２は、非着脱式メモリ４４および／または着脱式メモリ４６などの、各種の適当なメモリから情報にアクセスすると共に、そのメモリにデータを保存する。例えば、プロセッサ３２は、上述のメモリにセッションコンテキストを保存する。非着脱式メモリ４４として、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、およびその他の各種記憶装置がある。着脱式メモリ４６として、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどがある。他の実施形態において、プロセッサ３２は、サーバやホームコンピュータなどの、ネットワーク装置３０に物理的に位置していないメモリから情報にアクセスすると共に、そのメモリにデータを保存する。プロセッサ３２は、ディスプレイまたはインディケータ４２の点灯パターン、画像、または色彩を制御して装置の状態を反映または装置を設定するように構成されている。前記装置として、特に下位のネットワーク、アプリケーション、またはネットワーク装置と通信する他のサービスがある。ある実施形態では、ディスプレイ／インディケータ４２がグラフィカルユーザインタフェースになっている。

プロセッサ３２は電源４８から電力を受けて、その電力をネットワーク装置３０の他のコンポーネントに分配するか、制御するか、またはその両方を行うように構成される。電源４８は、ネットワーク装置３０に電力を供給する任意の適当な機器である。例えば、電源４８として、１つ以上のドライセル電池（例えば、ニッケル－カドミウム（ＮｉＣｄ）電池、ニッケル－亜鉛（ＮｉＺｎ）電池、ニッケル水素（ＮｉＭＨ）電池、リチウムイオン（Ｌｉ－ｉｏｎ）電池など）、太陽電池、燃料電池などがある。

さらにプロセッサ３２は、ネットワーク装置３０の現在位置に関する位置情報（例えば、経度と緯度）を与えるように構成された、ＧＰＳチップセット５０に接続されることもある。ネットワーク装置３０が、実施形態と矛盾することなく適当な位置決定法によって位置情報を取得し得ることは明らかである。

さらにプロセッサ３２は、１つ以上のソフトウェアおよび／またはハードウェアモジュールで構成されるその他の周辺機器５２に接続され、これにより付加的な特徴、機能、および／または有線もしくは無線による接続性がもたらされる。例えば、周辺機器５２として、加速度計や生体認証（例えば、指紋など）センサなどの各種センサ、電子コンパス、衛星トランシーバ、センサ、デジタルカメラ（写真用または映像用）、ユニバーサルシリアルバス（ＵＳＢ）ポートまたは他の相互接続インタフェース、振動機器、テレビ用トランシーバ、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線装置、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどがある。

ネットワーク装置３０は、他の装置または機器としても実施される。例えば、センサ、家庭用電化製品、スマートウォッチやスマートクロージングなどのウェアラブル機器、医療機器またはＥヘルス機器、ロボット、産業機器、ドローン、乗用車、トラック、電車、飛行機などの乗り物などである。ネットワーク装置３０は、周辺機器５２のいずれかで構成される相互接続インタフェースなどの１つ以上の相互接続インタフェースを介して、その他のコンポーネント、その他のモジュール、または上記装置または機器のシステムに接続する。

図２５Ｄは、コンピュータシステム９０であって、図２５Ａおよび図２５Ｂに示したネットワークなどのＭ２ＭネットワークにおけるＭ２Ｍサーバ、ゲートウェイ、機器、または他のネットワーク装置として動作する、図１～２４に示しかつ本明細書で説明したエンティティなどの、ネットワークにおける１つ以上のネットワーク装置の実現に使用されるコンピュータシステム９０の一例のブロック図である。

コンピュータシステム９０はコンピュータまたはサーバを有し、主にソフトウェアの形のコンピュータ読み取り可能な命令であって、何処で、またはどのような手段で、そのソフトウェアが保存またはアクセスされたとしても、その命令により制御される。このコンピュータ読み取り可能な命令は、中央処理装置（ＣＰＵ）９１などのプロセッサ内で実行されて、コンピュータシステム９０を動作させる。多くの公知のワークステーション、サーバ、および個人用コンピュータにおいて、中央処理装置９１は、マイクロプロセッサと呼ばれる単チップのＣＰＵにより実現される。別の装置では、中央処理装置９１は複数のプロセッサで構成される。コプロセッサ８１は、追加機能を実行するかまたはＣＰＵ９１を支援する、メインのＣＰＵ９１とは別のオプションのプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１が、本開示のシステムおよび方法に関するデータを受信、作成、および処理する。

動作として、ＣＰＵ９１は命令をフェッチ、デコード、および実行して、コンピュータのメインデータ転送経路であるシステムバス８０を介して、他のリソースと情報を送受信する。このシステムバスはコンピュータシステム９０のコンポーネント同士を接続して、データ交換用の媒体を画定する。通常システムバス８０は、データ送信用のデータラインと、アドレス送信用のアドレスラインと、割り込み送信およびシステムバス操作用の制御ラインとを備えている。このシステムバス８０の一例としてＰＣＩ（周辺構成要素相互接続）バスがある。

システムバス８０に接続したメモリはランダムアクセスメモリ（ＲＡＭ）８２と読み出し専用メモリ（ＲＯＭ）９３とを備えている。これらのメモリは、情報の保存および検索を可能にする回路を含む。ＲＯＭ９３は通常、簡単には変更できない保存データを含んでいる。ＲＡＭ８２に保存されたデータは、ＣＰＵ９１または他のハードウェア機器によって読み出しまたは変更される。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスはメモリコントローラ９２によって制御される。メモリコントローラ９２により、命令が実行されると仮想アドレスを物理アドレスに変換するアドレス変換機能が与えられる。さらにメモリコントローラ９２により、システム内でプロセス同士を分離してシステムプロセスをユーザプロセスから切り離す、メモリ保護機能が与えられる。このため、第１モードで作動するプログラムはそれ自身のプロセスの仮想アドレス空間によってマッピングされたメモリにのみアクセスし、プロセス間のメモリ共有が設定されない限り他のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。

また、コンピュータシステム９０は、プリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器へのＣＰＵ９１からの命令の通信に関わる周辺機器コントローラ８３を含む。

ディスプレイコントローラ９６によって制御されるディスプレイ８６を用いて、コンピュータシステム９０により生成された視覚的出力情報が表示される。この視覚的出力情報は、テキスト、グラフィックス、動画グラフィックス、および映像を含む。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルによって具現される。ディスプレイコントローラ９６は、ディスプレイ８６に送られるビデオ信号の生成に必要な電子コンポーネントである。ディスプレイ８６と、ＣＰＵ９１により実行されるコンピュータで実行可能な命令との組み合わせにより、図２５Ｄと関連の説明により図示および説明したグラフィカルユーザインタフェースが作成および操作される。

さらに、コンピュータシステム９０は、例えば、ネットワークアダプタ９７などの通信回路を含む。この通信回路を用いてコンピュータシステム９０が、図２５Ａ～図２５Ｄのネットワーク１２などの外部通信ネットワークに接続されて、コンピュータシステム９０と外部通信ネットワークの他の装置との通信が可能になる。この通信回路を単独またはＣＰＵ９１と組み合わせて用いて、本明細書（例えば、図５、６、９～１７、および１９～２４）ならびに請求の範囲に示した諸ステップの送受信が行われる。

本明細書記載のシステム、方法、およびプロセスはいずれも、コンピュータ可読の記憶媒体に保存されたコンピュータで実行可能な命令（すなわち、プログラムコード）の形で実施される。この命令は、例えば、Ｍ２Ｍのサーバ、ゲートウェイ、機器を含むＭ２Ｍネットワークの装置などの装置により実行されると、本明細書記載のシステム、方法、およびプロセスを実行および／または実施する。すなわち、前述のステップ、動作、または機能のいずれもコンピュータで実行可能な命令の形で実施される。コンピュータ可読の記憶媒体は、あらゆる非一時的（すなわち、有形の（物理的な））情報記憶方法または技術で実施される、揮発性と不揮発性との両方の媒体および着脱式と非着脱式との両方の媒体を含む。ただし、信号はこのコンピュータ可読記憶媒体には含まれない。コンピュータ可読の記憶媒体として、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）、または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスク、または他の磁気ストレージ機器、およびその他の所望の情報の保存に使用されてコンピュータによりアクセスされる有形の（すなわち物理的な）媒体がある。

表１２に、以上の説明におけるサービス層技術に関する頭字語のリストを示す。特段の指定がない限り、本明細書で用いる頭字語は下表に示した対応する語句を指す。

以下に詳細な説明で用いた用語の説明と定義例を示す。

データセットの一部分
住所は町区名だけを示すように変更される。住所番号は示されず、ダミー値と交換される。

省略化データセット
人名は頭字語、イニシャル、短縮形などに変更される。

サニタイズ化データセット
データセットからデータが除かれる、ならびに／または重要なデータが除かれるようにデータが変更される。

置き換えデータセット
人名を乱数、一般名、エイリアス、略語などと置き換える。なお、「置き換え」と「エイリアシング」とに関する語句は本文書では互換的に使用される。

シャッフルデータセット
置き換えに類似しているが、固定ドメイン（例えば、郵便番号）内のデータ間にデータが記録されていて、データ同士の間で無作為にデータが交換される。シャッフルデータセットは変更データの一種である。例えば、郵便番号１９１２８の住民（世帯）間の平均水消費量データをシャッフルしても、ユーザのプライバシを侵害することなく水消費量の中央値および平均値などの有意な統計データを得ることができる。

暗号化データセット
人物のデータをキーによって暗号化することができる。当該キーを有するアプリケーションサービスプロバイダだけがデータを暗号化することができる。

データ主体
あるデータが属するエンティティ。例えば、医療記録のデータ主体は患者になる。

ユーザ
自然人または人間。

ネットワーク機能（ＮＦ）
機能的挙動を規定しかつインタフェースを画定したネットワークにおける処理機能。ＮＦは、専用ハードウェアにおけるネットワーク要素、専用ハードウェア上で走るソフトウェアインスタンス、または適当なプラットフォーム上で（例えば、クラウドインフラストラクチャ上で）インスタンス化された仮想機能、のいずれかとして実施される。

データの匿名化技術とサニタイズ技術との例として、限定はしないが、シャフリング、フィルタリング、マスキング、およびエイリアシングがある。フィルタリングの例としてデータの除去がある。マスキングの例としてデータセットの一部分の除去がある（例えば、６７８９ ３ｒｄ Ａｖｅ．をマスキングするとＸＸＸＸ ３ｒｄ Ａｖｅ．になる）。エイリアシングの例として名前をエンティティに割り当てし直すことがある（例えば、ユーザ Ｂｏｂはユーザ－Ａに変更され、機器ｄｏｏｒ－ｌｏｃｋは機器－１に変更される）。

本明細書は、最良の形態を含む実施例を用いて本発明を開示すると共に、当業者による本発明の実施であって、全ての機器またはシステムを作製および利用すること、ならびに全ての包含された方法を実行することを含む発明の実施を可能にするものである。本発明の特許範囲は請求の範囲によって定義され、当業者が考え得る他の実施例も含み得るものである。それら他の実施例は、それらが本請求の範囲の文言から逸脱しない要素を有する場合、あるいは本請求の範囲の文言と実質的に相違のない等価な要素を含む場合は、本発明の範囲内にあるものとする。

Claims (20)

1. サービス層のエンティティによって実施される方法であって、
   前記サービス層のエンティティの特定のユーザに関連するデータにアクセスするリクエストをアプリケーションサービスプロバイダから受け取ることと、
   前記データにアクセスする前記リクエストに基づいて、１つ以上のデータ匿名化ポリシが前記特定のユーザに関連していることを確認することであって、前記１つ以上のデータ匿名化ポリシは、ユーザの選好度、地方自治体により課せられる法規、またはデータコンシューマの選好度のうちの少なくとも１つに基づいて、決定され、また、前記１つ以上のデータ匿名化ポリシは、データ匿名化においてデータがどのように変更されるかを示す、ことと、
   前記１つ以上のデータ匿名化ポリシを検索することと、
   前記１つ以上のデータ匿名化ポリシに基づいて、前記アプリケーションサービスプロバイダが前記特定のユーザの１つ以上の識別特徴を確認することを防ぐ匿名化されたデータセットを作成することと、
   前記匿名化されたデータセットを前記アプリケーションサービスプロバイダに送ることと、
   を含む、方法。
2. 前記匿名化されたデータセットの作成は、前記データの少なくとも一部を削除することと前記データの少なくとも一部を変更することとのいずれかまたは両方を含む、請求項１記載の方法。
3. 前記データの少なくとも一部の変更は、前記データの少なくとも一部の省略と、前記データの少なくとも一部の置き換えと、前記データの少なくとも一部のシャッフルと、前記データの少なくとも一部の暗号化との１つ以上を含む、請求項２記載の方法。
4. 前記１つ以上のデータ匿名化ポリシは、前記特定のユーザに関連する１つ以上のユーザポリシと、１つ以上のアプリケーションサービスプロバイダポリシと、１つ以上の法的ポリシとを含む、請求項１記載の方法。
5. 前記特定のユーザに関連する前記データにアクセスする前記リクエストは、前記アプリケーションサービスプロバイダに関連する１つ以上の特徴を含む、
   請求項１記載の方法。
6. 少なくとも前記アプリケーションサービスプロバイダに関連する前記１つ以上の特徴に基づいて、前記特定のユーザに関連する複数のデータ匿名化ポリシの内の１つ以上を選択することをさらに含む、請求項５記載の方法。
7. 前記匿名化されたデータセットの送信は、前記データが匿名化されたことの通知と前記データの匿名化に用いた匿名化技術の通知との少なくとも一方を前記アプリケーションサービスプロバイダに送ることを含む、請求項１記載の方法。
8. プロセッサとメモリとを備えた装置であって、前記メモリは、コンピュータで実行可能な命令であって、前記プロセッサによって実行されると通信ネットワークのサービス層のエンティティを実施させ、かつ前記サービス層のエンティティに動作を行わせる命令を保存し、前記動作は、
   前記サービス層のエンティティの特定のユーザに関連するデータにアクセスするリクエストをアプリケーションサービスプロバイダから受け取ることと、
   前記データにアクセスする前記リクエストに基づいて、１つ以上のデータ匿名化ポリシが前記特定のユーザに関連していることを確認することであって、前記１つ以上のデータ匿名化ポリシは、ユーザの選好度、地方自治体により課せられる法規、またはデータコンシューマの選好度のうちの少なくとも１つに基づいて、決定され、また、前記１つ以上のデータ匿名化ポリシは、データ匿名化においてデータがどのように変更されるかを示す、ことと、
   前記１つ以上のデータ匿名化ポリシを検索することと、
   前記１つ以上のデータ匿名化ポリシに基づいて、前記アプリケーションサービスプロバイダが前記特定のユーザの１つ以上の識別特徴を確認することを防ぐ匿名化されたデータセットを作成することと、
   前記匿名化されたデータセットを前記アプリケーションサービスプロバイダに送ることと、
   を含む、装置。
9. 前記匿名化されたデータセットの作成は、前記データの少なくとも一部を削除することと前記データの少なくとも一部を変更することとのいずれかまたは両方を含む、請求項８記載の装置。
10. 前記データの少なくとも一部の変更は、前記データの少なくとも一部の省略と、前記データの少なくとも一部の置き換えと、前記データの少なくとも一部のシャッフルと、前記データの少なくとも一部の暗号化との１つ以上を含む、請求項９記載の装置。
11. 前記１つ以上のデータ匿名化ポリシは、前記特定のユーザに関連する１つ以上のユーザポリシと、１つ以上のアプリケーションサービスプロバイダポリシと、１つ以上の法的ポリシとを含む、請求項８記載の装置。
12. 前記特定のユーザに関連する前記データにアクセスする前記リクエストは、前記アプリケーションサービスプロバイダに関連する１つ以上の特徴を含む、請求項８記載の装置。
13. 前記命令は、実行されると、前記サービス層のエンティティに、少なくとも前記アプリケーションサービスプロバイダに関連する前記１つ以上の特徴に基づいて、前記特定のユーザに関連する複数のデータ匿名化ポリシの内の１つ以上を選択することを含む動作をさらに行わせる、請求項１２記載の装置。
14. 前記匿名化されたデータセットの送信は、前記データが匿名化されたことの通知と前記データの匿名化に用いた匿名化技術の通知との少なくとも一方を前記アプリケーションサービスプロバイダに送ることを含む、請求項８記載の装置。
15. プロセッサにより実行されると、通信ネットワークのサービス層のエンティティを実施させて、前記サービス層のエンティティに動作を行わせる命令を保存するコンピュータ可読記憶媒体であって、前記動作は、
    前記サービス層のエンティティの特定のユーザに関連するデータにアクセスするリクエストをアプリケーションサービスプロバイダから受け取ることと、
    前記データにアクセスする前記リクエストに基づいて、１つ以上のデータ匿名化ポリシが前記特定のユーザに関連していることを確認することであって、前記１つ以上のデータ匿名化ポリシは、ユーザの選好度、地方自治体により課せられる法規、またはデータコンシューマの選好度のうちの少なくとも１つに基づいて、決定され、また、前記１つ以上のデータ匿名化ポリシは、データ匿名化においてデータがどのように変更されるかを示す、ことと、
    前記１つ以上のデータ匿名化ポリシを検索することと、
    前記１つ以上のデータ匿名化ポリシに基づいて、前記アプリケーションサービスプロバイダが前記特定のユーザの１つ以上の識別特徴を確認することを防ぐ匿名化されたデータセットを作成することと、
    前記匿名化されたデータセットを前記アプリケーションサービスプロバイダに送ることと、
    を含む、コンピュータ可読記憶媒体。
16. 前記匿名化されたデータセットの作成は、前記データの少なくとも一部を削除することと前記データの少なくとも一部を変更することとのいずれかまたは両方を含む、請求項１５記載のコンピュータ可読記憶媒体。
17. 前記データの少なくとも一部の変更は、前記データの少なくとも一部の省略と、前記データの少なくとも一部の置き換えと、前記データの少なくとも一部のシャッフルと、前記データの少なくとも一部の暗号化との１つ以上を含む、請求項１６記載のコンピュータ可読記憶媒体。
18. 前記１つ以上のデータ匿名化ポリシは、前記特定のユーザに関連する１つ以上のユーザポリシと、１つ以上のアプリケーションサービスプロバイダポリシと、１つ以上の法的ポリシとを含む、請求項１５記載のコンピュータ可読記憶媒体。
19. 前記特定のユーザに関連する前記データにアクセスする前記リクエストは、前記アプリケーションサービスプロバイダに関連する１つ以上の特徴を含む、請求項１５記載のコンピュータ可読記憶媒体。
20. 前記命令は、実行されると、前記サービス層のエンティティに、少なくとも前記アプリケーションサービスプロバイダに関連する前記１つ以上の特徴に基づいて、前記特定のユーザに関連する複数のデータ匿名化ポリシの内の１つ以上を選択することを含む動作をさらに行わせる、請求項１９記載のコンピュータ可読記憶媒体。

Images