▶ オラクル・インターナショナル・コーポレイションの特許一覧
特表2024-509940サービス通信プロキシ（ＳＣＰ）における代行承認のための方法、システム、およびコンピュータ可読媒体
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-05
(54)【発明の名称】サービス通信プロキシ（ＳＣＰ）における代行承認のための方法、システム、およびコンピュータ可読媒体
(51)【国際特許分類】
H04W 12/084 20210101AFI20240227BHJP
H04W 88/18 20090101ALI20240227BHJP
H04W 92/24 20090101ALI20240227BHJP
【ＦＩ】
H04W12/084
H04W88/18
H04W92/24
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023555356
(86)(22)【出願日】2022-01-27
(85)【翻訳文提出日】2023-11-01
(86)【国際出願番号】 US2022014087
(87)【国際公開番号】W WO2022191932
(87)【国際公開日】2022-09-15
(31)【優先権主張番号】17/198,815
(32)【優先日】2021-03-11
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】シング，ビレンドラ
(72)【発明者】
【氏名】ラジプット，ジャイ
(72)【発明者】
【氏名】スリバスタバ，アンキット
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA33
5K067HH22
5K067HH23
5K067HH36
(57)【要約】
サービス通信プロキシ（ＳＣＰ）における代行承認のための方法は、アクセストークンベースの承認をサポートしないコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）要求を傍受することを含む。本方法はさらに、アクセストークン承認クライアントとして動作して、コンシューマＮＦに代わって第１のアクセストークンを取得することを含む。本方法はさらに、第１のアクセストークンを使用して、コンシューマＮＦが、アクセストークンベースの承認を必要とする第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることを含む。ＳＣＰは、アクセストークンベースの承認をサポートしないＮＲＦに代わってアクセストークン承認サーバとして機能することもできる。
【特許請求の範囲】
【請求項1】
サービス通信プロキシ（ＳＣＰ）における代行承認のための方法であって、少なくとも１つのプロセッサおよびメモリを含む第１のＳＣＰにおいて、
アクセストークンベースの承認をサポートしない第１のコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）要求を傍受することと、
アクセストークン承認クライアントプロキシとして動作して、前記第１のコンシューマＮＦに代わって第１のアクセストークンを取得することと、
前記第１のアクセストークンを使用して、前記第１のコンシューマＮＦが、アクセストークンベースの承認を必要とする第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることとを含む、方法。
【請求項2】
アクセストークン承認クライアントプロキシとして動作することは、前記第１のアクセストークンを取得するためにＮＦリポジトリ機能（ＮＲＦ）と信号通信を行うことを含む、請求項１に記載の方法。
【請求項3】
前記第１のアクセストークンを取得するために前記ＮＲＦと信号通信を行うことは、前記第１のコンシューマＮＦに代わってアクセストークン要求を生成することと、
前記アクセストークン要求を前記ＮＲＦに送信することと、
前記ＮＲＦから、前記第１のアクセストークンを含むアクセストークン応答を受信することとを含む、請求項２に記載の方法。
【請求項4】
前記アクセストークン要求を生成することは、前記ＳＢＩ要求のユーザエージェントヘッダから、前記アクセストークン要求に含まれるべき少なくともいくつかの属性の値を抽出することを含む、請求項３に記載の方法。
【請求項5】
前記属性のうちの少なくともいくつかの値を抽出することは、前記ＳＢＩ要求の前記ユーザエージェントヘッダから前記第１のコンシューマＮＦのＮＦインスタンスＩＤを抽出することを含む、請求項４に記載の方法。
【請求項6】
ＳＢＩ要求を受信することは、前記第１のコンシューマＮＦからＳＢＩサービス要求を受信することを含み、前記第１のアクセストークンを使用して、前記第１のコンシューマＮＦが前記第１のプロデューサＮＦによって提供される前記サービスにアクセスすることを可能にすることは、前記ＳＢＩサービス要求に前記第１のアクセストークンを挿入することと、
前記第１のアクセストークンを含む前記ＳＢＩサービス要求を前記第１のプロデューサＮＦに転送することと、
前記第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、
前記ＳＢＩサービス応答を前記第１のコンシューマＮＦに転送することとを含む、先行する請求項のいずれか１項に記載の方法。
【請求項7】
ＳＢＩ要求を受信することは、前記第１のコンシューマＮＦからＳＢＩサービスアクセス要求を受信することを含み、前記第１のアクセストークンを使用して、前記第１のコンシューマＮＦが前記第１のプロデューサＮＦによって提供される前記サービスにアクセスすることを可能にすることは、前記ＳＢＩサービスアクセス要求に応答して実行される代行発見およびＮＦ選択に基づいてＳＢＩサービス要求を生成することと、
前記ＳＢＩサービス要求に前記第１のアクセストークンを挿入することと、
前記第１のアクセストークンを含む前記ＳＢＩサービス要求を前記第１のプロデューサＮＦに転送することと、
前記第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、
前記ＳＢＩサービス応答を前記第１のコンシューマＮＦに転送することとを含む、先行する請求項のいずれか１項に記載の方法。
【請求項8】
第２のコンシューマＮＦまたは第２のＳＣＰから、アクセストークン要求を受信することと、前記第２のコンシューマＮＦまたは前記第２のＳＣＰからの前記アクセストークン要求に応答して、アクセストークン承認をサポートしないＮＦリポジトリ機能（ＮＲＦ）に代わってアクセストークン承認サーバプロキシとして動作することと、
前記第２のコンシューマＮＦが第２のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするよう、前記第２のコンシューマＮＦまたは前記第２のＳＣＰおよび前記第２のプロデューサＮＦと信号通信を行うこととを含む、先行する請求項のいずれか１項に記載の方法。
【請求項9】
アクセストークン承認サーバプロキシとして動作することは、前記アクセストークン要求に応答して、第２のアクセストークンを生成することと、
前記第２のコンシューマＮＦまたは前記第２のＳＣＰに、前記第２のアクセストークンを含むアクセストークン応答を送信することとを含む、請求項８に記載の方法。
【請求項10】
前記第２のコンシューマＮＦが前記第２のプロデューサＮＦによって提供される前記サービスにアクセスすることを可能にするよう、前記第２のプロデューサＮＦと信号通信を行うことは、前記第２のコンシューマＮＦまたは前記第２のＳＣＰから、前記第２のアクセストークンを含む第２のＳＢＩサービス要求を受信することと、
前記第２のＳＢＩサービス要求から前記第２のアクセストークンを除去することと、
前記第２のＳＢＩサービス要求を前記第２のプロデューサＮＦに転送することと、
前記第２のプロデューサＮＦからＳＢＩサービス応答を受信することと、
前記ＳＢＩサービス応答を前記第２のコンシューマＮＦまたは前記第２のＳＣＰに転送することとを含む、請求項８に記載の方法。
【請求項11】
サービス通信プロキシ（ＳＣＰ）における代行承認のためのシステムであって、少なくとも１つのプロセッサおよびメモリを含む第１のＳＣＰと、
前記少なくとも１つのプロセッサによって実現されるアクセストークン承認クライアントプロキシとを備え、前記アクセストークン承認クライアントプロキシは、アクセストークンベースの承認をサポートしない第１のコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）要求を傍受し、アクセストークン承認クライアントとして動作して、前記第１のコンシューマＮＦに代わって第１のアクセストークンを取得し、前記第１のアクセストークンを使用して、前記第１のコンシューマＮＦがアクセストークンベースの承認を必要とする第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にする、システム。
【請求項12】
前記アクセストークン承認クライアントプロキシは、前記第１のアクセストークンを取得するためにＮＦリポジトリ機能（ＮＲＦ）と信号通信を行うよう構成される、請求項１１に記載のシステム。
【請求項13】
前記アクセストークン承認クライアントプロキシは、前記第１のアクセストークンを取得するために、前記ＮＲＦと信号通信を行うことを、前記第１のコンシューマＮＦに代わってアクセストークン要求を生成することと、
前記アクセストークン要求を前記ＮＲＦに送信することと、
前記ＮＲＦから、前記第１のアクセストークンを含むアクセストークン応答を受信することとによって行うよう構成される、請求項１２に記載のシステム。
【請求項14】
前記アクセストークン承認クライアントプロキシは、前記ＳＢＩ要求のユーザエージェントヘッダから、前記アクセストークン要求に含まれるべき少なくともいくつかの属性の値を抽出することによって、前記アクセストークン要求を生成するよう構成される、請求項１３に記載のシステム。
【請求項15】
前記アクセストークン承認クライアントプロキシによって抽出される前記値は、前記ＳＢＩ要求の前記ユーザエージェントヘッダからの前記第１のコンシューマＮＦのＮＦインスタンスＩＤを含む、請求項１４に記載のシステム。
【請求項16】
前記ＳＢＩ要求は、ＳＢＩサービス要求を含み、前記アクセストークン承認クライアントプロキシは、前記第１のアクセストークンを使用して、前記第１のコンシューマＮＦが前記サービスにアクセスすることを可能にすることを、前記第１のアクセストークンを前記ＳＢＩサービス要求に挿入することと、
前記第１のアクセストークンを含む前記ＳＢＩサービス要求を前記第１のプロデューサＮＦに転送することと、
前記第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、
前記ＳＢＩサービス応答を前記第１のコンシューマＮＦに転送することとによって行うよう構成される、請求項１１～１５のいずれか１項に記載のシステム。
【請求項17】
前記ＳＢＩ要求は、前記第１のコンシューマＮＦからのＳＢＩサービスアクセス要求を含み、前記アクセストークン承認クライアントプロキシは、前記第１のアクセストークンを使用して、前記第１のコンシューマＮＦが前記第１のプロデューサＮＦによって提供される前記サービスにアクセスすることを可能にすることを、前記ＳＢＩサービスアクセス要求に応答して実行される代行発見およびＮＦ選択に基づいてＳＢＩサービス要求を生成することと、
前記ＳＢＩサービス要求に前記第１のアクセストークンを挿入することと、
前記第１のアクセストークンを含む前記ＳＢＩサービス要求を前記第１のプロデューサＮＦに転送することと、
前記第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、
前記ＳＢＩサービス応答を前記第１のコンシューマＮＦに転送することとによって行うよう構成される、請求項１１～１６のいずれか１項に記載のシステム。
【請求項18】
第２のコンシューマＮＦまたは第２のＳＣＰからアクセストークン要求を受信し、前記第２のコンシューマＮＦからの前記アクセストークン要求に応答して、アクセストークン承認をサポートしないＮＦリポジトリ機能（ＮＲＦ）に代わってアクセストークン承認サーバとして動作し、前記第２のコンシューマＮＦが第２のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするよう、前記第２のコンシューマＮＦまたは前記第２のＳＣＰおよび前記第２のプロデューサＮＦと信号通信を行うためのアクセストークン承認サーバプロキシを備える、請求項１１～１７のいずれか１項に記載のシステム。
【請求項19】
前記アクセストークン承認サーバとして動作する際に、前記アクセストークン承認サーバプロキシは、前記アクセストークン要求に応答して、第２のアクセストークンを生成し、
前記第２のコンシューマＮＦまたは前記第２のＳＣＰに、前記第２のアクセストークンを含むアクセストークン応答を送信するよう構成され、
前記アクセストークン承認サーバプロキシは、前記第２のコンシューマＮＦが前記第２のプロデューサＮＦによって提供される前記サービスにアクセスすることを可能にするよう、前記第２のコンシューマＮＦまたは前記第２のＳＣＰおよび前記第２のプロデューサＮＦとの信号通信を、
前記第２のコンシューマＮＦまたは前記第２のＳＣＰから、前記第２のアクセストークンを含む第２のＳＢＩサービス要求を受信することと、
前記第２のＳＢＩサービス要求から前記第２のアクセストークンを除去することと、
前記ＳＢＩサービス要求を前記第２のプロデューサＮＦに転送することと、
前記第２のプロデューサＮＦからＳＢＩサービス応答を受信することと、
前記ＳＢＩサービス応答を前記第２のコンシューマＮＦに転送することとによって行うよう構成される、請求項１８に記載のシステム。
【請求項20】
コンピュータのプロセッサによって実行されるとステップを実行するように前記コンピュータを制御する実行可能命令を記憶した非一時的なコンピュータ可読媒体であって、前記ステップは、アクセストークンベースの承認をサポートしないコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）要求を傍受することと、
アクセストークン承認クライアントとして動作して、前記コンシューマＮＦに代わって第１のアクセストークンを取得することと、
前記第１のアクセストークンを使用して、前記コンシューマＮＦが、アクセストークンベースの承認を必要とするプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることとを含む、非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
優先権主張
本出願は、２０２１年３月１１日に提出された米国特許出願１７／１９８，８１５の優先権利益を主張し、その開示は、参照によりその全体が本明細書に組み込まれる。
本出願は、２０２１年３月１１日に提出された米国特許出願１７／１９８，８１５の優先権利益を主張し、その開示は、参照によりその全体が本明細書に組み込まれる。
【0002】
技術分野
本明細書で説明する主題は、ネットワークセキュリティおよび公衆陸上移動体通信網（ＰＬＭＮ）間互換性に関する。より具体的には、本明細書で説明される主題は、ＳＣＰにおける代行承認のための方法、システム、およびコンピュータ可読媒体に関する。
本明細書で説明する主題は、ネットワークセキュリティおよび公衆陸上移動体通信網（ＰＬＭＮ）間互換性に関する。より具体的には、本明細書で説明される主題は、ＳＣＰにおける代行承認のための方法、システム、およびコンピュータ可読媒体に関する。
【背景技術】
【0003】
背景
５Ｇ電気通信ネットワークでは、サービスを提供するネットワーク機能は、プロデューサネットワーク機能（ＮＦ）またはＮＦサービスプロデューサと呼ばれる。サービスを消費するネットワーク機能は、コンシューマＮＦまたはＮＦサービスコンシューマと呼ばれる。ネットワーク機能は、ネットワーク機能がサービスを消費しているか、産生しているか、または消費および産生しているかに応じて、プロデューサＮＦ、コンシューマＮＦ、またはその両方であり得る。「プロデューサＮＦ」および「ＮＦサービスプロデューサ」という用語は、ここでは互換的に使用される。同様に、「コンシューマＮＦ」および「ＮＦサービスコンシューマ」という用語は、ここでは互換的に使用される。
５Ｇ電気通信ネットワークでは、サービスを提供するネットワーク機能は、プロデューサネットワーク機能（ＮＦ）またはＮＦサービスプロデューサと呼ばれる。サービスを消費するネットワーク機能は、コンシューマＮＦまたはＮＦサービスコンシューマと呼ばれる。ネットワーク機能は、ネットワーク機能がサービスを消費しているか、産生しているか、または消費および産生しているかに応じて、プロデューサＮＦ、コンシューマＮＦ、またはその両方であり得る。「プロデューサＮＦ」および「ＮＦサービスプロデューサ」という用語は、ここでは互換的に使用される。同様に、「コンシューマＮＦ」および「ＮＦサービスコンシューマ」という用語は、ここでは互換的に使用される。
【0004】
所与のプロデューサＮＦは、多くのサービスエンドポイントを有することができ、サービスエンドポイントは、プロデューサＮＦによってホストされる１つ以上のＮＦインスタンスのための接点である。サービスエンドポイントは、インターネットプロトコル（ＩＰ）アドレスおよびポート番号の組み合わせ、またはプロデューサＮＦをホストするネットワークノード上のＩＰアドレスおよびポート番号に解決する完全修飾ドメイン名によって識別される。ＮＦインスタンスは、サービスを提供するプロデューサＮＦのインスタンスである。所与のプロデューサＮＦは、複数のＮＦインスタンスを含み得る。複数のＮＦインスタンスが同じサービスエンドポイントを共有できることにも留意されたい。
【0005】
プロデューサＮＦは、ネットワーク機能リポジトリ機能（ＮＲＦ）に登録する。ＮＲＦは、各ＮＦインスタンスによってサポートされるサービスを識別する、利用可能なＮＦインスタンスのサービスプロファイルを維持する。「サービスプロファイル」および「ＮＦプロファイル」という用語は、ここでは互換的に使用される。コンシューマＮＦは、ＮＲＦに登録したプロデューサＮＦインスタンスに関する情報を受信するように加入することができる。
【0006】
コンシューマＮＦに加えて、ＮＦサービスインスタンスに関する情報を受信するよう加入することができる別のタイプのネットワークノードは、サービス通信プロキシ（ＳＣＰ）である。ＳＣＰは、ＮＲＦに加入し、プロデューサＮＦサービスインスタンスに関する到達可能性およびサービスプロファイル情報を取得する。コンシューマＮＦは、サービス通信プロキシに接続し、サービス通信プロキシは、要求されるサービスを提供するプロデューサＮＦサービスインスタンス間でトラフィックを分散させるか、またはそのトラフィックを宛先プロデューサＮＦインスタンスに直接ルーティングする。
【0007】
ＳＣＰに加えて、プロデューサＮＦとコンシューマＮＦとの間でトラフィックをルーティングする中間プロキシノードの別の例は、セキュリティエッジ保護プロキシ（ＳＥＰＰ）である。ＳＥＰＰは、異なる５Ｇ公衆陸上移動体通信網（ＰＬＭＮ）間で交換される制御プレーントラフィックを保護するために使用されるネットワークノードである。したがって、ＳＥＰＰは、ＰＬＭＮ間で送信されるすべてのアプリケーションプログラミングインターフェース（ＡＰＩ）メッセージに対してメッセージフィルタリング、監視、およびトポロジー隠蔽を実行する。
【0008】
５Ｇ通信ネットワークにおける１つの問題は、１つのＰＬＭＮまたはネットワーク機能がＯＡｕｔｈ２．０承認をサポートし、別のＰＬＭＮまたはネットワーク機能がＯＡｕｔｈ２．０承認をサポートしないときに生じる。インターネットエンジニアリングタスクフォース（ＩＥＴＦ）コメント要求（ＲＦＣ）６７４９（Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749）に規定されるOAuth２.０承認フレームワークによれば、リソースサーバから利用可能な保護されたリソースにアクセスしようとする承認クライアントは、まず承認サーバからアクセストークンを取得する。クライアントは、アクセストークンを取得した後、リソースサーバにサービス要求を送信する。リソースサーバは、アクセストークンを検証し、保護されたリソースへのアクセスを提供する。
【0009】
５Ｇ通信ネットワークの文脈では、ＮＦサービスコンシューマはＯＡｕｔｈ２．０リソースクライアントとして機能し、ＮＦサービスプロデューサはＯＡｕｔｈ２．０リソースサーバとして機能し、ＮＲＦは承認サーバとして機能する。したがって、ＮＦサービスプロデューサによって提供されるサービスにアクセスしようとするＮＦサービスコンシューマは、ＮＦサービスプロデューサによって提供されるリソースにアクセスするためにアクセストークンを取得するために、ＮＲＦと信号通信を行う。ＮＦサービスコンシューマがＮＲＦからアクセストークンを取得した後、ＮＦサービスコンシューマは、サービス要求をＮＦサービスプロデューサに送信し、ここで、サービス要求は、アクセストークンを含んでいる。ＮＦサービスプロデューサは、アクセストークンを検証し、ＮＦサービスコンシューマによって要求されたサービスへのアクセスを提供する。
【0010】
ＯＡｕｔｈ２．０承認フレームワークは、５Ｇ通信ネットワークにおいて承認を提供するように機能するが、サービス要求が、ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦから、ＯＡｕｔｈ２．０アクセストークンを必要とするプロデューサＮＦに送信される場合、そのサービス要求は拒否されることになる。同様に、ＯＡｕｔｈ２．０承認をサポートするコンシューマＮＦが、ＯＡｕｔｈ２．０承認をサポートしないＮＲＦにアクセストークン要求を送信する場合、要求側コンシューマＮＦは、アクセストークンを取得することはできない。
【0011】
これらのタイプの非互換性の問題は、サービスコンシューマのＰＬＭＮがＯＡｕｔｈ２．０承認をサポートし、サービスプロデューサのＰＬＭＮがＯＡｕｔｈ２．０承認をサポートしないとき、またはその逆のときに発生し得る。これらのタイプの非互換性の問題はまた、あるベンダからのＮＦがＯＡｕｔｈ２．０承認をサポートし、別のベンダからのＮＦがＯＡｕｔｈ２．０承認をサポートしないときにも生じ得る。
【0012】
これらおよび他の困難に照らして、ＯＡｕｔｈ２．０承認非互換性が存在する場合に、ネットワーク機能間の改善された相互運用性のための方法の必要性が存在する。
【発明の概要】
【課題を解決するための手段】
【0013】
概要
サービス通信プロキシ（ＳＣＰ）における代行承認のための方法は、アクセストークンベースの承認をサポートしない第１のコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）サービス要求を傍受することを含む。本方法はさらに、アクセストークン承認クライアントプロキシとして動作して、第１のコンシューマＮＦに代わって第１のアクセストークンを取得することを含む。本方法はさらに、第１のアクセストークンを使用して、第１のコンシューマＮＦが、アクセストークンベースの承認を必要とする第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることを含む。
サービス通信プロキシ（ＳＣＰ）における代行承認のための方法は、アクセストークンベースの承認をサポートしない第１のコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）サービス要求を傍受することを含む。本方法はさらに、アクセストークン承認クライアントプロキシとして動作して、第１のコンシューマＮＦに代わって第１のアクセストークンを取得することを含む。本方法はさらに、第１のアクセストークンを使用して、第１のコンシューマＮＦが、アクセストークンベースの承認を必要とする第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることを含む。
【0014】
本明細書で説明する主題の別の局面によれば、アクセストークン承認クライアントプロキシとして動作することは、第１のアクセストークンを取得するためにＮＦリポジトリ機能（ＮＲＦ）と信号通信を行うことを含む。
【0015】
本明細書で説明する主題の別の局面によれば、第１のアクセストークンを取得するためにＮＲＦと信号通信を行うことは、第１のコンシューマＮＦに代わってアクセストークン要求を生成することと、アクセストークン要求をＮＲＦに送信することと、ＮＲＦから、第１のアクセストークンを含むアクセストークン応答を受信することとを含む。
【0016】
本明細書で説明する主題の別の局面によれば、アクセストークン要求を生成することは、ＳＢＩ要求のユーザエージェントヘッダから、アクセストークン要求に含まれるべき少なくともいくつかの属性の値を抽出することを含む。
【0017】
本明細書で説明する主題の別の局面によれば、属性のうちの少なくともいくつかの値を抽出することは、ＳＢＩ要求のユーザエージェントヘッダから第１のコンシューマＮＦのＮＦインスタンスＩＤを抽出することを含む。
【0018】
本明細書で説明する主題の別の局面によれば、ＳＢＩ要求を受信することは、第１のコンシューマＮＦからＳＢＩサービス要求を受信することを含み、第１のアクセストークンを使用して、第１のコンシューマＮＦが第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることは、ＳＢＩサービス要求に第１のアクセストークンを挿入することと、第１のアクセストークンを含むＳＢＩサービス要求を第１のプロデューサＮＦに転送することと、第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、ＳＢＩサービス応答を第１のコンシューマＮＦに転送することとを含む。
【0019】
本明細書で説明する主題の別の局面によれば、ＳＢＩ要求を受信することは、第１のコンシューマＮＦからＳＢＩサービスアクセス要求を受信することを含み、第１のアクセストークンを使用して、第１のコンシューマＮＦが第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることは、ＳＢＩサービスアクセス要求に応答して実行される代行発見およびＮＦ選択に基づいてＳＢＩサービス要求を生成することと、ＳＢＩサービス要求に第１のアクセストークンを挿入することと、第１のアクセストークンを含むＳＢＩサービス要求を第１のプロデューサＮＦに転送することと、第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、ＳＢＩサービス応答を第１のコンシューマＮＦに転送することとを含む。
【0020】
本明細書で説明する主題の別の局面によれば、ＳＣＰにおける代行承認のための方法は、第２のコンシューマＮＦまたは第２のＳＣＰから、アクセストークン要求を受信することと、第２のコンシューマＮＦまたは第２のＳＣＰからのアクセストークン要求に応答して、アクセストークン承認をサポートしないＮＦリポジトリ機能（ＮＲＦ）に代わってアクセストークン承認サーバプロキシとして動作することと、第２のコンシューマＮＦが第２のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするよう、第２のコンシューマＮＦまたは第２のＳＣＰおよび第２のプロデューサＮＦと信号通信を行うこととを含む。
【0021】
本明細書で説明する主題の別の局面によれば、アクセストークン承認サーバプロキシとして動作することは、アクセストークン要求に応答して、第２のアクセストークンを生成することと、第２のコンシューマＮＦまたは第２のＳＣＰに、第２のアクセストークンを含むアクセストークン応答を送信することとを含む。
【0022】
本明細書で説明される主題の別の局面によれば、第２のコンシューマＮＦが第２のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするよう、第２のプロデューサＮＦまたは第２のＳＣＰと信号通信を行うことは、第２のコンシューマＮＦから、第２のアクセストークンを含む第２のＳＢＩサービス要求を受信することと、第２のＳＢＩサービス要求から第２のアクセストークンを除去することと、第２のＳＢＩサービス要求を第２のプロデューサＮＦに転送することと、第２のプロデューサＮＦからＳＢＩサービス応答を受信することと、ＳＢＩサービス応答を第２のコンシューマＮＦまたは第２のＳＣＰに転送することとを含む。
【0023】
本明細書で説明する主題の別の局面によれば、第２のアクセストークンを生成することは、構文的に正しいクレームを伴うダミーアクセストークンを含むＯＡｕｔｈ２．０アクセストークンを生成することを含む。
【0024】
本明細書で説明する主題の別の局面によれば、サービス通信プロキシ（ＳＣＰ）における代行承認のためのシステムが提供される。本システムは、少なくとも１つのプロセッサおよびメモリを含む第１のＳＣＰを含む。本システムはさらに、少なくとも１つのプロセッサによって実現され、アクセストークンベースの承認をサポートしない第１のコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）要求を傍受し、アクセストークン承認クライアントとして動作して、第１のコンシューマＮＦに代わって第１のアクセストークンを取得し、第１のアクセストークンを使用して、第１のコンシューマＮＦがアクセストークンベースの承認を必要とする第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするための、アクセストークン承認クライアントプロキシを備える。
【0025】
本明細書で説明する主題の別の局面によれば、アクセストークン承認クライアントプロキシは、第１のアクセストークンを取得するためにＮＦリポジトリ機能（ＮＲＦ）と信号通信を行うよう構成される。
【0026】
本明細書で説明する主題の別の局面によれば、アクセストークン承認クライアントプロキシは、第１のアクセストークンを取得するために、ＮＲＦと信号通信を行うことを、第１のコンシューマＮＦに代わってアクセストークン要求を生成することと、アクセストークン要求をＮＲＦに送信することと、ＮＲＦから、第１のアクセストークンを含むアクセストークン応答を受信することとによって行うよう構成される。
【0027】
本明細書で説明する主題の別の局面によれば、アクセストークン承認クライアントプロキシは、ＳＢＩ要求のユーザエージェントヘッダからアクセストークン要求に含まれるべき少なくともいくつかの属性の値を抽出することによってアクセストークン要求を生成するよう構成される。
【0028】
本明細書で説明する主題の別の局面によれば、アクセストークン承認クライアントプロキシによって抽出される値は、ＳＢＩ要求のユーザエージェントヘッダからの第１のコンシューマＮＦのＮＦインスタンスＩＤを含む。
【0029】
本明細書で説明する主題の別の局面によれば、ＳＢＩ要求は、第１のコンシューマＮＦからのＳＢＩサービス要求を含み、アクセストークン承認クライアントプロキシは、第１のアクセストークンを使用して、第１のコンシューマＮＦがサービスにアクセスすることを可能にすることを、ＳＢＩサービス要求に第１のアクセストークンを挿入することと、第１のアクセストークンを含むＳＢＩサービス要求を第１のプロデューサＮＦに転送することと、第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、ＳＢＩサービス応答を第１のコンシューマＮＦに転送することとによって行うよう構成される。
【0030】
本明細書で説明される主題の別の局面によれば、ＳＢＩ要求は、第１のコンシューマＮＦからのＳＢＩサービスアクセス要求を含み、アクセストークン承認クライアントプロキシは、第１のアクセストークンを使用して、第１のコンシューマＮＦが第１のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることを、ＳＢＩサービスアクセス要求に応答して実行される代行発見およびＮＦ選択に基づいてＳＢＩサービス要求を生成することと、ＳＢＩサービス要求に第１のアクセストークンを挿入することと、第１のアクセストークンを含むＳＢＩサービス要求を第１のプロデューサＮＦに転送することと、第１のプロデューサＮＦからＳＢＩサービス応答を受信することと、ＳＢＩサービス応答を第１のコンシューマＮＦに転送することとによって行うよう構成される。
【0031】
本明細書で説明する主題の別の局面によれば、ＳＣＰにおける代行承認のためのシステムは、第２のコンシューマＮＦまたは第２のＳＣＰからアクセストークン要求を受信し、第２のコンシューマＮＦからのアクセストークン要求に応答して、アクセストークン承認をサポートしないＮＦリポジトリ機能（ＮＲＦ）に代わってアクセストークン承認サーバとして動作し、第２のコンシューマＮＦが第２のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするよう、第２のコンシューマＮＦまたは第２のＳＣＰおよび第２のプロデューサＮＦと信号通信を行うためのアクセストークン承認サーバプロキシを備える。
【0032】
本明細書に記載される主題の別の局面によれば、アクセストークン承認サーバプロキシは、アクセストークン承認サーバとして動作する際に、アクセストークン要求に応答して、第２のアクセストークンを生成し、第２のコンシューマＮＦまたは第２のＳＣＰに、第２のアクセストークンを含むアクセストークン応答を送信するよう構成される。
【0033】
本明細書で説明する主題の別の局面によれば、アクセストークン承認サーバプロキシは、第２のコンシューマＮＦが第２のプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするよう、第２のコンシューマＮＦまたは第２のＳＣＰおよび第２のプロデューサＮＦとの信号通信を、第２のコンシューマＮＦまたは第２のＳＣＰから、第２のアクセストークンを含む第２のＳＢＩサービス要求を受信することと、第２のＳＢＩサービス要求から第２のアクセストークンを除去することと、ＳＢＩサービス要求を第２のプロデューサＮＦに転送することと、第２のプロデューサＮＦからＳＢＩサービス応答を受信することと、ＳＢＩサービス応答を第２のコンシューマＮＦまたは第２のＳＣＰに転送することとによって行うよう構成される。
【0034】
本明細書で説明する主題の別の局面によれば、コンピュータのプロセッサによって実行されるとステップを実行するようにコンピュータを制御する実行可能命令を記憶した非一時的なコンピュータ可読媒体が提供される。ステップは、アクセストークンベースの承認をサポートしないコンシューマネットワーク機能（ＮＦ）から、サービスベースのインターフェース（ＳＢＩ）要求を傍受することを含む。ステップは、さらに、アクセストークン承認クライアントプロキシとして動作して、第１のコンシューマＮＦに代わって第１のアクセストークンを取得することを含む。ステップは、さらに、第１のアクセストークンを使用して、コンシューマＮＦが、アクセストークンベースの承認を必要とするプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることを含む。
【0035】
本明細書で説明される主題は、ソフトウェアをハードウェアおよび／またはファームウェアと組み合わせて実現され得る。たとえば、本明細書で説明する主題は、プロセッサによって実行されるソフトウェアで実現され得る。例示的な一実現例では、本明細書で説明する主題は、コンピュータのプロセッサによって実行されるとステップを実行するようコンピュータを制御するコンピュータ実行可能命令を記憶した非一時的コンピュータ可読媒体を使用して実現され得る。本明細書に記載の主題を実施するのに適した例示的なコンピュータ可読媒体は、ディスクメモリデバイス、チップメモリデバイス、プログラマブル論理デバイス、および特定用途向け集積回路などの非一時的コンピュータ可読媒体を含む。加えて、本明細書で説明される主題を実現するコンピュータ可読媒体は、単一のデバイスもしくはコンピューティングプラットフォーム上に位置してもよく、または複数のデバイスもしくはコンピューティングプラットフォームにわたって分散されてもよい。
【図面の簡単な説明】
【0036】
【図1】例示的な５Ｇシステムネットワークアーキテクチャを示すネットワーク図である。
【図2A】ＯＡｕｔｈ２．０承認フレームワークを使用して５Ｇ通信ネットワーク内でサービスにアクセスする際に交換される例示的なメッセージを示すメッセージフロー図であり、メッセージフローは、代行発見を伴わない間接的なＰＬＭＮ間通信のためのものである（モデルＣ）。
【図2B】ＯＡｕｔｈ２．０承認フレームワークを使用して５Ｇ通信ネットワーク内でサービスにアクセスする際に交換される例示的なメッセージを示すメッセージフロー図であり、メッセージフローは、代行発見を伴う間接的なＰＬＭＮ間通信のためのものである（モデルＤ）。
【図3A】コンシューマＮＦがＯＡｕｔｈ２．０承認をサポートせず、プロデューサＮＦが、プロデューサＮＦによって提供されるサービスへのアクセスを許可するための条件としてＯＡｕｔｈ２．０承認を必要とするときに交換される例示的なメッセージを示すメッセージフロー図であり、メッセージフローは、代行発見を伴わない間接的なＰＬＭＮ間通信のためのものである（モデルＣ）。
【図3B】コンシューマＮＦがＯＡｕｔｈ２．０承認をサポートし、ＮＲＦがＯＡｕｔｈ２．０承認をサポートしないときに交換される例示的なメッセージを示すメッセージフロー図であり、メッセージフローは、代行発見を伴わない間接的なＰＬＭＮ間通信のためのものである（モデルＣ）。
【図3C】コンシューマＮＦがＯＡｕｔｈ２．０承認をサポートし、ＮＲＦがＯＡｕｔｈ２．０承認をサポートしないときに交換される例示的なメッセージを示すメッセージフロー図であり、メッセージフローは、代行発見を伴う間接的なＰＬＭＮ間通信のためのものである（モデルＤ）。
【図4】ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦに代わってＳＣＰがＯＡｕｔｈ２．０承認クライアントプロキシとして動作するときの代行ＯＡｕｔｈ２．０承認を示すメッセージフロー図であり、メッセージフローは、代行発見（モデルＤ）を伴う間接的なＰＬＭＮ間通信のためのものである。
【図5A】ＯＡｕｔｈ２．０承認をサポートしないＮＲＦに代わってＳＣＰがＯＡｕｔｈ２．０承認サーバプロキシとして動作するときに交換される例示的なメッセージを示すメッセージフロー図であり、メッセージフローは、代行発見を伴わない間接的なＰＬＭＮ間通信のためのものである（モデルＣ）。
【図5B】ＯＡｕｔｈ２．０承認をサポートしないＮＲＦに代わってＳＣＰがＯＡｕｔｈ２．０承認サーバプロキシとして動作するときに交換される例示的なメッセージを示すメッセージフロー図であり、メッセージフローは、代行発見を伴う間接的なＰＬＭＮ間通信のためのものである（モデルＤ）。
【図6】ＯＡｕｔｈ２．０承認をサポートしないＮＦサービスコンシューマおよびＮＲＦに代わって代行ＯＡｕｔｈ２．０承認を実行することができるＳＣＰを示すブロック図である。
【図7A】ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦに代わって代行ＯＡｕｔｈ２．０承認を実行する例示的なプロセスを示すフローチャートである。
【図7C】ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦがＯＡｕｔｈ２．０承認を必要とするプロデューサＮＦによって提供されるサービスにアクセスすることを可能にするためにアクセストークンを使用する図７Ａからのステップをより詳細に示すフローチャートである。
【図8A】ＯＡｕｔｈ２．０承認をサポートしないＮＲＦに代わってＯＡｕｔｈ２．０承認サーバプロキシとして動作し、コンシューマＮＦがＯＡｕｔｈ２．０承認をサポートし、プロデューサＮＦがＯＡｕｔｈ２．０承認をサポートしないときにサービスへのアクセスを容易にするための例示的なプロセスを示すフローチャートである。
【発明を実施するための形態】
【0037】
詳細な説明
図１は、例示的な５Ｇシステムネットワークアーキテクチャを示すブロック図である。図１のアーキテクチャは、同じホーム公衆陸上移動体通信網（ＨＰＬＭＮ：home public land mobile network）に位置し得るＮＲＦ１００およびＳＣＰ１０１を含む。上記で説明されるように、ＮＲＦ１００は、利用可能なプロデューサＮＦサービスインスタンスおよびそれらのサポートされるサービスのプロファイルを維持し、コンシューマＮＦまたはＳＣＰが、新たな／更新されたプロデューサＮＦサービスインスタンスに加入し、その登録を通知されることを可能にし得る。ＳＣＰ１０１はまた、プロデューサＮＦインスタンスのサービス発見および選択をサポートし得る。ＳＣＰ１０１は、コンシューマＮＦとプロデューサＮＦとの間の接続の負荷分散を実行し得る。
図１は、例示的な５Ｇシステムネットワークアーキテクチャを示すブロック図である。図１のアーキテクチャは、同じホーム公衆陸上移動体通信網（ＨＰＬＭＮ：home public land mobile network）に位置し得るＮＲＦ１００およびＳＣＰ１０１を含む。上記で説明されるように、ＮＲＦ１００は、利用可能なプロデューサＮＦサービスインスタンスおよびそれらのサポートされるサービスのプロファイルを維持し、コンシューマＮＦまたはＳＣＰが、新たな／更新されたプロデューサＮＦサービスインスタンスに加入し、その登録を通知されることを可能にし得る。ＳＣＰ１０１はまた、プロデューサＮＦインスタンスのサービス発見および選択をサポートし得る。ＳＣＰ１０１は、コンシューマＮＦとプロデューサＮＦとの間の接続の負荷分散を実行し得る。
【0038】
ＮＲＦ１００は、プロデューサＮＦインスタンスのＮＦまたはサービスプロファイルのためのリポジトリである。プロデューサＮＦインスタンスと通信するために、コンシューマＮＦまたはＳＣＰは、プロデューサＮＦインスタンスのＮＦまたはサービスプロファイルをＮＲＦ１００から取得しなければならない。ＮＦまたはサービスプロファイルは、３ＧＰＰ（登録商標） ＴＳ ２９．５１０で定義されるJavaScriptオブジェクト表記（ＪＳＯＮ）データ構造である。ＮＦまたはサービスプロファイル定義は、完全修飾ドメイン名（ＦＱＤＮ）、インターネットプロトコル（ＩＰ）バージョン４（ＩＰｖ４）アドレス、またはＩＰバージョン６（ＩＰｖ６）アドレスのうちの少なくとも１つを含む。
【0039】
図１では、ネットワーク機能のいずれも、それらがサービスを要求、提供、または要求および提供しているかどうかに応じて、コンシューマＮＦ、プロデューサＮＦ、または両方となり得る。図示の例では、ＮＦは、ネットワークにおいてポリシー関連動作を実行するＰＣＦ１０２と、ユーザデータを管理するＵＤＭ機能１０４と、アプリケーションサービスを提供するアプリケーション機能（ＡＦ）１０６とを含む。
【0040】
図１に示すＮＦは、アクセスおよびモビリティ管理機能（ＡＭＦ）１１０とＰＣＦ１０２との間のセッションを管理するセッション管理機能（ＳＭＦ）１０８をさらに含む。ＡＭＦ１１０は、４Ｇネットワークにおいてモビリティ管理エンティティ（ＭＭＥ）によって実行されるモビリティ管理動作と同様の動作を実行する。認証サーバ機能（ＡＵＳＦ）１１２は、ネットワークへのアクセスを求めるユーザ機器（ＵＥ）１１４などのユーザ機器（ＵＥ）のために認証サービスを実行する。
【0041】
ネットワークスライス選択機能（ＮＳＳＦ）１１６は、ネットワークスライスに関連付けられる特定のネットワーク機能および特性にアクセスしようとするデバイスのためにネットワークスライスサービスを提供する。ネットワーク公開機能（ＮＥＦ）１１８は、モノのインターネット（ＩｏＴ）デバイスおよびネットワークに接続される他のＵＥに関する情報を取得しようとするアプリケーション機能のためにアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供する。ＮＥＦ１１８は、４Ｇネットワークにおけるサービス機能公開機能（ＳＣＥＦ）と同様の機能を実行する。
【0042】
無線アクセスネットワーク（ＲＡＮ）１２０は、無線リンクを介してユーザ機器（ＵＥ）１１４をネットワークに接続する。無線アクセスネットワーク１２０は、g-Node B（ｇＮＢ）（図１には示さず）または他の無線アクセスポイントを用いてアクセスされてもよい。ユーザプレーン機能（ＵＰＦ）１２２は、ユーザプレーンサービスのために様々なプロキシ機能をサポート可能である。そのようなプロキシ機能の一例は、マルチパス伝送制御プロトコル（ＭＰＴＣＰ）プロキシ機能である。ＵＰＦ１２２はまた、ネットワーク性能測定値を取得するためにＵＥ１１４によって使用されてもよい性能測定機能をサポートしてもよい。図１には、ＵＥがインターネットサービスなどのデータネットワークサービスにアクセスするデータネットワーク（ＤＮ）１２４も示されている。
【0043】
ＳＥＰＰ１２６は、別のＰＬＭＮからの着信トラフィックをフィルタリングし、ホームＰＬＭＮを出るトラフィックのためにトポロジー隠蔽を実行する。ＳＥＰＰ１２６は、外部ＰＬＭＮのセキュリティを管理する、外部ＰＬＭＮ内のＳＥＰＰと通信してもよい。したがって、異なるＰＬＭＮ内のＮＦ間のトラフィックは、一方はホームＰＬＭＮ用であり、他方は外部ＰＬＭＮ用である、２つのＳＥＰＰ機能を横断し得る。
【0044】
前述のように、５Ｇネットワークにおいて生じ得る１つの問題は、ＯＡｕｔｈ２．０承認のための汎用サポートの欠如であり、これは、ネットワーク間のサービス非互換性をもたらし得る。図２Ａは、ＰＬＭＮ間のＯＡｕｔｈ２．０承認と、ＰＬＭＮ境界を越えてサービスにアクセスするためのアクセストークンの使用とを示すメッセージフロー図である。図２Ａのメッセージフローは、３ＧＰＰ ＴＳ ２３．５０１の補遺ＥにおいてモデルＣとして定義される、代行発見を伴わない間接的なＰＬＭＮ間通信のためのものである。モデルＣの仕様によれば、コンシューマＮＦは、ＮＲＦに問い合わせることによって発見を実行する。コンシューマＮＦは、発見結果に基づいて、プロデューサＮＦまたはＮＦセットを選択する。次いで、コンシューマＮＦは、選択されたプロデューサＮＦまたはプロデューサＮＦセットのアドレスを含むＳＢＩサービス要求をＳＣＰに送信する。サービス要求がＮＦセットを指定する場合、ＳＣＰは、ＮＲＦと対話して、ロケーション、容量などの選択パラメータを取得し、これらのパラメータを使用してプロデューサＮＦインスタンスを選択することができる。ＳＣＰは、選択されたプロデューサＮＦインスタンスにＳＢＩサービス要求をルーティングする。
【0045】
図２Ａのメッセージフローを参照すると、ライン１において、コンシューマＮＦ２００は、ＮＦ発見を実行し、ＳＣＰ１０１Ａおよび１０１ＢならびにＳＥＰＰ１２６Ａおよび１２６Ｂを介してＮＲＦ１００Ｂと信号通信を行うことによって、プロデューサＮＦインスタンスまたはＮＦセットを選択する。ライン２で、プロデューサＮＦまたはＮＦセットを選択した後、コンシューマＮＦ２００は、Ｎｎｒｆアクセストークン要求メッセージをビジターネットワーク（アクセストークン要求をトリガしたＵＥが現在ローミングしているビジターＰＬＭＮにローカルなネットワーク）内に位置するＮＲＦ１００Ａに送信する。ＮＲＦ１００Ａは、ＳＣＰ１０１Ａおよび１０１ＢならびにＳＥＰＰ１２６Ａおよび１２６Ｂを介して、アクセストークン要求メッセージをリモートＮＲＦ１００Ｂに転送する。この転送は、図２Ａのライン２～６によって示される。
【0046】
ホームＮＲＦ１００Ｂは、クライアントがアクセストークンの受信を承認されているか否かを判断し、アクセストークン応答メッセージを送信することによってアクセストークンを返信する。ライン７～１１で、アクセストークン応答メッセージは、ＳＣＰ１０１Ａおよび１０１Ｂ、ＳＥＰＰ１２６Ａおよび１２６Ｂ、ならびにＮＲＦ１００Ａを介してコンシューマＮＦ２００に通信される。
【0047】
コンシューマＮＦ２００は、ライン１２～１４によって示されるように、アクセストークンを含むＳＢＩサービス要求メッセージを生成し、ＳＣＰ１０１Ａおよび１０１ＢならびにＳＥＰＰ１２６Ａおよび１２６Ｂを介して、ＳＢＩサービス要求メッセージをプロデューサＮＦ２０２に送信する。ＳＢＩサービス要求メッセージは、アクセストークンを含む。ＳＢＩ要求は、任意選択で、図２Ａの「ＣＣＡ＊」によって示されるように、クライアント身分証明表明（ＣＣＡ）属性を含んでもよい。
【0048】
プロデューサＮＦ２０２は、アクセストークンを検証し、サービスへのアクセスをコンシューマＮＦ２００に許可する。ライン１５～１７において、プロデューサＮＦ２０２は、ＳＢＩサービス応答メッセージをコンシューマＮＦ２００に返す。同様のフローが、コンシューマＮＦがホームネットワーク内に存在し、プロデューサＮＦがビジターまたは非ホームネットワーク内に存在するときに、生じる。したがって、図２Ａは、２つの異なるネットワークが、ＳＣＰを介してＯＡｕｔｈ２．０承認および間接的なＰＬＭＮ間通信をサポートし、その結果、アクセストークンメッセージングおよびサービス要求メッセージングが成功する場合を示す。しかしながら、一方または他方のネットワークがＯＡｕｔｈ２．０承認をサポートしない場合、サービス要求メッセージングおよび／またはアクセストークンメッセージングは成功しないことになる。
【0049】
図２Ｂは、代行発見を伴う間接的なＰＬＭＮ間通信およびＯＡｕｔｈ２．０承認を示すメッセージフロー図である。代行発見を伴う間接的な通信は、３ＧＰＰ ＴＳ ２３．５０１の補遺ＥにおけるモデルＤとして定義される。モデルＤによれば、コンシューマＮＦは、ＮＦ選択または発見を実行しない。代わりに、コンシューマＮＦは、必要な発見パラメータおよび選択パラメータを、ＳＣＰに送信される発見要求に追加する。次いで、ＳＣＰは、ＮＲＦと発見を実行し、発見結果を取得し、選択されたＮＦにＳＢＩサービス要求を送信する。図２Ｂのメッセージフローを参照すると、ライン１において、コンシューマＮＦ２００は、ＳＢＩサービスアクセス要求メッセージを発見パラメータおよびプロデューサＮＦ選択パラメータとともにＳＣＰ１０１Ａに送信する。ライン２で、ＳＣＰ１０１Ａは、ＮＲＦ１０１Ｂと発見を実行する。発見の結果は、サービス要求メッセージを処理するためのプロデューサＮＦ２０２の選択である。しかしながら、サービス要求メッセージをプロデューサＮＦ２０２に送信する前に、ＳＣＰ１０１Ａは、プロデューサＮＦ２０２のネットワーク内のＮＲＦ１００Ｂからアクセストークンを取得しなければならない。したがって、ライン３において、ＳＣＰ１０１Ａは、アクセストークン要求メッセージをローカルＮＲＦ１００Ａに送信する。ローカルＮＲＦ１００Ａは、メッセージフロー図のライン４～６によって示されるように、ＳＣＰ１０１Ａおよび１０１ＢならびにＳＥＰＰ１２６Ａおよび１２６Ｂを介して、アクセストークン要求メッセージをリモートＮＲＦ１００Ｂに転送する。
【0050】
ＮＲＦ１００Ｂは、クライアントが承認されているかどうかを判断し、ＳＣＰ１０１Ｂおよび１０１ＡならびにＳＥＰＰ１２６Ｂおよび１２６Ａを介してアクセストークンを返す。アクセストークンの返送は、図２Ｂのメッセージフローのライン７～１０を介して示されている。
【0051】
ライン１１および１２で、ＳＣＰ１０１Ａは、ＳＥＰＰ１２６Ａおよび１２６ＢならびにＳＣＰ１０１Ｂを介して、ライン２によって表される代行発見手順中に選択されたプロデューサＮＦ２０２に、ＳＢＩサービス要求メッセージを送信する。プロデューサＮＦ２０２は、アクセストークンを検証し、ライン１３～１５において、ＳＢＩサービス応答を、自身のＳＣＰ１０１Ｂおよび１０１ＡならびにＳＥＰＰ１２６Ｂおよび１２６Ａを介して、コンシューマＮＦ２００に送信する。コンシューマＮＦ２００に通信されるＳＢＩサービス応答は、任意選択で、図２Ｂにおいて「アクセストークン＊＊」によって示されるように、アクセストークンを含んでもよい。
【0052】
同様のフローが、コンシューマＮＦがホームネットワーク内にあり、プロデューサＮＦがビジターネットワーク内にあるときに、生じる。したがって、図２Ｂは、コンシューマＮＦにサービスするＳＣＰおよびプロデューサＮＦのネットワーク内のＮＲＦがＯＡｕｔｈ２．０承認をサポートし、代行発見を伴う間接的なＰＬＭＮ間通信が実行されるケースを示す。
【0053】
図３Ａは、ＮＦサービスコンシューマがＯＡｕｔｈ２．０承認をサポートせず、ＮＦサービスプロデューサがＯＡｕｔｈ２．０承認を必要とする、代行発見を伴わないＰＬＭＮ間間接通信の場合を示す。図３Ａを参照すると、この例におけるビジターネットワークはＯＡｕｔｈ２．０承認をサポートしないので、図２Ａのライン１～１１からアクセストークンを取得するためのＰＬＭＮ間信号通信は発生しない。図３Ａのメッセージフローは、ライン１で始まり、コンシューマＮＦ２００は、アクセストークンなしのＳＢＩサービス要求メッセージを、異なるＰＬＭＮ内に位置し、アクセストークン承認を必要とするプロデューサＮＦ２０２に送信する。サービス要求はアクセストークンを含まないので、ライン２のサービス要求はホームＳＥＰＰ１２６Ｂによって拒否される。３ＧＰＰ ＴＳ ３３．５０１のセクション１３．４．１．２．２は、プロバイダＳＥＰＰが、アクセストークン内のサブジェクトクレームのサービングＰＬＭＮがＮ３２メッセージ内のＮ３２－ｆコンテキストＩＤに対応するリモートＰＬＭＮに一致することをチェックすることを提唱するので、ＳＥＰＰ１２６Ｂは、サービス要求を拒否する。ライン２のサービス要求メッセージはアクセストークンを含まないので、ＳＥＰＰ１２６Ｂが検証するサブジェクトクレームはなく、したがってメッセージは拒否される。
【0054】
図３Ａは、コンシューマＮＦがＯＡｕｔｈ２．０承認をサポートせず、プロデューサＮＦがＯＡｕｔｈ２．０承認をサポートする、代行発見を伴わない間接的なＰＬＭＮ間通信の場合を示し、図３Ｂは、コンシューマＮＦがＯＡｕｔｈ２．０承認をサポートし、プロデューサＮＦのネットワーク内のＮＲＦがサポートしない、代行発見を伴わない間接的なＰＬＭＮ間通信の場合を示す。図３Ｂのメッセージフローを参照すると、ライン１において、ホームネットワークに位置するコンシューマＮＦ３００は、ビジターネットワークに位置するＮＲＦ１００Ａと信号通信を行って、サービス発見を実行する。この例では、サービス発見の結果は、要求されたサービスを提供するためにビジターネットワーク内に位置するプロデューサＮＦ３０２の選択である、と仮定する。
【0055】
サービス発見後、ライン２において、コンシューマＮＦ３００は、ホームネットワーク内に位置するＳＣＰ１０１Ｂにアクセストークン要求メッセージを送信する。ライン３で、ＳＣＰ１０１Ｂは、アクセストークン要求をＮＲＦ１００Ｂに送信する。ライン４で、ＮＲＦ１００Ｂは、アクセストークン要求をＳＣＰ１０１Ｂに転送し、ライン５で、アクセストークン要求をリモートＳＣＰ１０１Ａにルーティングする。ライン６で、ＳＣＰ１０１Ａは、アクセストークン要求をビジターネットワーク内に位置するＮＲＦ１００Ａにルーティングする。この例では、ビジターＮＲＦ１００Ａは、ＯＡｕｔｈ２．０承認をサポートしない。したがって、ビジターＮＲＦ１００Ａは、アクセストークン要求に応答することはできず、アクセストークンメッセージングの失敗をもたらす。その結果、コンシューマＮＦ３００は、ビジターネットワークによって提供されるサービスにアクセスすることができない場合がある。
【0056】
図３Ｃは、コンシューマＮＦはＯＡｕｔｈ２．０承認をサポートし、プロデューサＮＦはサポートしない、代行発見を伴う間接的なＰＬＭＮ間通信の場合を示す。図３Ｃのメッセージフローを参照すると、ライン１において、ホームネットワーク内に位置するコンシューマＮＦ３００は、サービスアクセス要求を発見パラメータとともにＳＣＰ１０１Ｂに送信する。ライン２で、ＳＣＰ１０１Ｂは、ビジターネットワーク内に位置するＮＲＦ１００Ａと信号通信を行って、サービス発見を実行する。この例では、サービス発見の結果は、要求されたサービスを提供するためにビジターネットワーク内に位置するプロデューサＮＦ３０２の選択である、と仮定する。
【0057】
サービス発見後、ライン３において、ＳＣＰ１０１Ｂは、アクセストークン要求をＮＲＦ１００Ｂに送信する。ライン４で、ＮＲＦ１００Ｂは、アクセストークン要求をＳＣＰ１０１Ｂに転送し、ライン５で、アクセストークン要求をリモートＳＣＰ１０１Ａにルーティングする。ライン６で、ＳＣＰ１０１Ａは、アクセストークン要求をビジターネットワーク内に位置するＮＲＦ１００Ａにルーティングする。この例では、ビジターＮＲＦ１００Ａは、ＯＡｕｔｈ２．０承認をサポートしない。したがって、ビジターＮＲＦ１００Ａは、アクセストークン要求に応答することはできず、アクセストークンメッセージングの失敗をもたらす。その結果、コンシューマＮＦ３００は、ビジターネットワークによって提供されるサービスにアクセスすることができない場合がある。
【0058】
これらの困難を回避するために、本明細書で説明するＳＣＰは、アクセストークンベースの承認をサポートしないコンシューマＮＦに代わってアクセストークン承認クライアントプロキシとして機能し、アクセストークンベースの承認をサポートしないＮＲＦに代わってアクセストークン承認サーバとして機能する。アクセストークンベースの承認をサポートしないコンシューマＮＦについては、ＳＣＰは、アクセストークンをフェッチし、アクセストークンをＳＢＩ要求に追加した後に、プロデューサＮＦにＳＢＩ要求を転送する。ＳＣＰは、処理を高速化するためにトークンをキャッシュすることを選択することができる。ＳＣＰは、ＳＢＩサービスまたはＳＢＩサービスアクセス要求においてコンシューマＮＦによって提供されるユーザエージェントヘッダからのフィールドを利用して、コンシューマＮＦに代わってアクセストークン要求を作成するために使用されるＮＦタイプおよびＮＦインスタンスＩＤを取得してもよい。ＳＣＰがＯＡｕｔｈ２．０承認サーバとして機能する場合、ＳＣＰは、代行発見が実行されるか否かに応じて、アクセストークンを、要求を行っているコンシューマＮＦまたはＳＣＰに発行する。
【0059】
図４は、ＳＣＰがＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦに代わってＯＡｕｔｈ２．０承認クライアントプロキシとして動作する、代行発見を伴う間接的なＰＬＭＮ間通信の場合を示す。図４を参照すると、メッセージフロー図のライン１において、コンシューマＮＦ２００は、ＳＢＩサービスアクセス要求をアクセストークンなしでＳＣＰ１０１Ａに送信する。ライン２で、ＳＣＰ１０１Ａは、ＮＲＦ１００Ｂとの信号通信によってコンシューマＮＦ２００に代わって代行発見を実行し、代行発見の結果は、プロデューサＮＦ２０２の選択である。
【0060】
ライン１のサービスアクセス要求に応答してＳＢＩサービス要求を生成するのではなく、ＳＣＰ１０１Ａは、サービスアクセス要求はアクセストークンを含まないことを検出し、サービスアクセス要求を傍受して記憶し、コンシューマＮＦ２００に代わってアクセストークンをフェッチする。アクセストークンをフェッチするプロセスは、メッセージフロー図のライン３において始まり、ＳＣＰ１０１Ａは、アクセストークン要求を定式化し、ＳＣＰ１０１Ｂに送信し、ＳＣＰ１０１Ｂは、ライン４において、プロデューサＮＦ２０２のＰＬＭＮ内に位置するＮＲＦ１００Ｂにアクセストークン要求をルーティングする。アクセストークン要求メッセージの定式化については、以下でさらに詳細に説明する。ＮＲＦ１００Ｂは、コンシューマＮＦ２００を検証し、アクセストークンを含むアクセストークン応答を生成し、ライン５および６において、ＳＥＰＰ１２６Ｂおよび１２６ＡならびにＳＣＰ１０１Ｂを介して、アクセストークン応答をコンシューマＮＦ２００のネットワークに送信する。
【0061】
ＳＣＰ１０１Ａは、アクセストークン応答を受信し、応答からアクセストークンを抽出し、ライン１で受信したＳＢＩサービスアクセス要求に基づいてＳＢＩサービス要求を生成し、生成したＳＢＩサービス要求にアクセストークンを挿入する。ライン７および８で、ＳＣＰ１０１Ａは、ＳＢＩサービス要求をアクセストークンとともにプロデューサＮＦ２０２に転送する。プロデューサＮＦ２０２は、アクセストークンを使用してサービス要求を検証し、ライン９～１１において、ＳＢＩサービス応答メッセージを生成し、コンシューマＮＦ２００に送信する。したがって、図４は、ＳＣＰ１０１ＡがＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦに代わってＯＡｕｔｈ２．０承認クライアントプロキシとして機能する場合を示す。
【0062】
別の例では、ＳＣＰ１０１Ａは、アクセストークン承認サーバとして機能し得る。１つのそのような例は、ホームネットワーク内に位置し、ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦ３００が、ビジターネットワーク内に位置するプロデューサＮＦ３０２によって提供されるサービスにアクセスしようとする、代行発見を伴わない間接的なＰＬＭＮ間通信を図示する、図５Ａに図示される。図５Ａを参照すると、ライン１において、コンシューマＮＦは、ＮＲＦ１００Ａと信号通信を行うことによってサービス発見を実行し、サービス発見の結果は、サービスを提供するためのプロデューサＮＦ３０２の選択である。
【0063】
ライン２で、コンシューマＮＦ３００は、アクセストークン要求メッセージを生成し、アクセストークン要求をＳＣＰ１０１Ｂに転送する。ライン３で、ＳＣＰ１０１Ｂは、アクセストークン要求をＮＲＦ１００Ｂに転送する。ＮＲＦ１００Ｂは、ライン４および５において、アクセストークン要求メッセージをＮＲＦ１００Ａに転送する。しかしながら、ＮＲＦ１００Ａは、ＯＡｕｔｈ２．０承認をサポートしない。したがって、アクセストークン要求をＮＲＦ１００Ａに転送する代わりに、ＳＣＰ１０１Ａは、アクセストークン要求メッセージを傍受し、ＮＲＦ１００Ａに代わってアクセストークン応答メッセージを生成する。アクセストークン応答メッセージは、ＳＣＰ１０１Ａにローカルな情報を使用してＳＣＰ１０１Ａによって生成されたアクセストークンを含む。アクセストークンは、必要とされるアクセストークンクレームのすべてを含むという点で、構文的に正しくてもよい。ライン６～９において、ＳＣＰ１０１Ａは、アクセストークン応答をコンシューマＮＦ３００に転送する。
【0064】
ライン１０で、コンシューマＮＦ３００は、ＳＢＩサービス要求を生成し、ＳＣＰ１０１Ｂおよび１０１ＡならびにＳＥＰＰ１２６Ｂおよび１２６Ａを介してプロデューサＮＦ３０２に送信し、サービス要求は、アクセストークンを含む。ライン１１で、ＳＣＰ１０１Ａは、ＳＢＩサービス要求を傍受し、プロデューサＮＦ３０２がＯＡｕｔｈ２．０承認をサポートしないため、サービス要求からアクセストークンを除去する。ライン１２で、ＳＣＰ１０１Ａは、サービス要求を（アクセストークンなしで）プロデューサＮＦ３０２に転送する。ライン１３～１５で、プロデューサＮＦ３０２は、ＳＢＩサービス応答メッセージを生成し、コンシューマＮＦ３００に送信する。したがって、図５Ａは、ＳＣＰ１０１Ａが、ＯＡｕｔｈ２．０承認をサポートしないＮＲＦに代わってＯＡｕｔｈ２．０承認サーバプロキシとして機能する場合を示す。
【0065】
図５Ａは、ＳＣＰが、代行発見を伴わないＰＬＭＮ間との間接的な通信のためにＯＡｕｔｈ２．０承認サーバとして動作するケースを示し、図５Ｂは、ＳＣＰが、代行発見を伴う間接的なＰＬＭＮ間通信のためにＯＡｕｔｈ２．０承認サーバとして動作するケースを示す。図５Ｂを参照すると、メッセージフロー図のライン１において、ホームネットワーク内に位置するコンシューマＮＦ３００は、サービスアクセス要求メッセージを発見パラメータとともにＳＣＰ１０１Ｂに送信する。ライン２で、ＳＣＰ１０１Ｂは、ビジターネットワーク内に位置するＮＲＦ１００Ａと信号通信を行うことによって、代行ＮＦ発見および選択を実行する。代行発見およびＮＦ選択の結果は、要求されたサービスを提供するための、ビジターネットワーク内に位置するプロデューサＮＦ３０２の選択である。
【0066】
代行発見およびＮＦ選択を実行した後、ライン３において、ＳＣＰ１０１Ｂは、アクセストークン要求メッセージを生成し、アクセストークン要求メッセージをＮＲＦ１００Ｂに転送する。ＮＲＦ１００Ｂは、ライン４および５において、アクセストークン要求メッセージをＮＲＦ１００Ａに転送する。しかしながら、ＮＲＦ１００Ａは、ＯＡｕｔｈ２．０承認をサポートしない。アクセストークン要求をＮＲＦ１００Ａに転送する代わりに、ＳＣＰ１０１Ａは、アクセストークン要求を傍受し、ＮＲＦ１００Ａに代わってアクセストークン応答を生成する。アクセストークン応答は、ＳＣＰ１０１Ａにローカルな情報を使用してＳＣＰ１０１Ａによって生成されたアクセストークンを含む。アクセストークンは、必要とされるアクセストークンクレームのすべてを含むという点で、構文的に正しくてもよい。ライン６～８において、ＳＣＰ１０１Ａは、アクセストークン応答をＳＣＰ１０１Ｂに転送する。
【0067】
ライン９で、ＳＣＰ１０１Ｂは、ＳＢＩサービス要求を生成し、ＳＥＰＰ１２６Ｂおよび１２６ＡならびにＳＣＰ１０１Ａを介して、プロデューサＮＦ３０２に送信し、サービス要求は、アクセストークンを含む。ＳＣＰ１０１Ａは、プロデューサＮＦ３０２がＯＡｕｔｈ２．０承認をサポートしないため、ＳＢＩサービス要求を傍受し、サービス要求からアクセストークンを除去する。ライン１０で、ＳＣＰ１０１Ａは、サービス要求を（アクセストークンなしで）プロデューサＮＦ３０２に転送する。ライン１１～１３において、プロデューサＮＦ３０２は、ＳＢＩサービス応答メッセージを生成し、コンシューマＮＦ３００に送信する。したがって、図５Ｂは、ＳＣＰ１０１Ａが代行発見およびＮＦ選択を実行し、ＯＡｕｔｈ２．０承認をサポートしないＮＲＦに代わってＯＡｕｔｈ２．０承認サーバプロキシとして機能する場合を示す。
【0068】
図６は、本明細書で説明するＯＡｕｔｈ２．０承認プロキシ化をサポートするＳＣＰの例示的なアーキテクチャを示すブロック図である。図６を参照すると、ＳＣＰ１０１Ａは、少なくとも１つのプロセッサ６００およびメモリ６０２を含む。ＳＣＰ１０１Ａは、ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦに代わってＯＡｕｔｈ２．０アクセストークンを取得し、ＯＡｕｔｈ２．０アクセストークンを含むＳＢＩサービス要求メッセージを生成して、コンシューマＮＦがＯＡｕｔｈ２．０承認をサポートするプロデューサＮＦによって提供されるサービスにアクセスすることを可能にする、代行発見例のために図４に関して上記で説明した動作を実行するためのアクセストークン承認クライアントプロキシ６０４をさらに含む。非代行発見の場合、アクセストークン承認クライアントプロキシ６０４は、ＯＡｕｔｈ２．０アクセストークンを取得し、ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦからのＳＢＩサービス要求メッセージ中に挿入してもよい。
【0069】
ＳＣＰ１０１Ａは、図５Ａおよび図５Ｂに関して上述したように、ＯＡｕｔｈ２．０承認をサポートしないＮＲＦに代わってＯＡｕｔｈ２．０承認サーバの機能を実行するアクセストークン承認サーバプロキシ６０６をさらに含む。アクセストークン承認サーバプロキシ６０６はまた、アクセストークンベースの承認をサポートしないプロデューサＮＦに宛てられたサービス要求メッセージからアクセストークンを除去し得る。アクセストークン承認クライアントプロキシ６０４およびアクセストークン承認サーバプロキシ６０６は、プロセッサ６００に上述のアクセストークン承認クライアントおよびサーバプロキシ化動作を行わせる、メモリ６０２に記憶されたコンピュータ実行可能命令を使用して実現することができる。
【0070】
図７Ａは、ＳＣＰにおいて代行承認を実行するための例示的な全体的なプロセスを示すフローチャートであり、ＳＣＰはアクセストークン承認クライアントプロキシとして機能する。図７Ａを参照すると、ステップ７００において、本プロセスは、アクセストークンベースの承認をサポートしないコンシューマＮＦから、アクセストークンベースの承認を必要とするプロデューサＮＦによって提供されるサービスにアクセスするためのＳＢＩ要求を傍受することを含む。例えば、代行発見を伴わない間接的なＰＬＭＮ間通信の場合、ＳＣＰ１０１Ａは、プロデューサＮＦ２０２によって提供されるサービスにアクセスするためのＳＢＩサービス要求をコンシューマＮＦから受信し得る。代行発見伴う間接的なＰＬＭＮ間通信の場合、ＳＣＰ１０１Ａは、コンシューマＮＦからサービスアクセス要求を受信し得る。
【0071】
ステップ７０２において、本プロセスは、コンシューマＮＦに代わってアクセストークンを取得するためにアクセストークン承認クライアントプロキシとして動作することを含む。例えば、ＳＣＰ１０１Ａは、ＯＡｕｔｈ２．０承認をサポートしないコンシューマＮＦに代わってアクセストークンを取得するためにＯＡｕｔｈ２．０承認クライアントプロキシとして機能し得る。図７Ｂは、図７Ａのステップ７０２のさらなる詳細を示す。図７Ｂを参照すると、ステップ７０２Ａにおいて、本プロセスは、コンシューマＮＦに代わってアクセストークン要求メッセージを生成することを含む。下記の表１は、アクセストークン要求メッセージに含まれなければならない属性を示す。
【0072】
【表1】
【0073】
アクセストークン要求に含まれなければならない属性の最小セットは、許可タイプ、ＮＦインスタンスＩＤ、ＮＦタイプ、ターゲットＮＦタイプ、範囲、要求元ＰＬＭＮ、およびターゲットＰＬＭＮである。許可タイプ属性は、ＳＢＩサービス要求またはサービスアクセス要求メッセージからポピュレートされるコンシューマＮＦ身分証明から取得され得る。ＮＦインスタンスＩＤは、ＳＢＩサービス要求メッセージまたはサービスアクセス要求メッセージのユーザエージェントヘッダからポピュレートされ得る。３ＧＰＰ ＴＳ ２９．５００のセクション５．２．２によれば、ユーザエージェントヘッダは、ＳＢＩサービス要求メッセージ内の必須ヘッダである。以下の表２は、ユーザエージェントパラメータの構造を示す。
【0074】
【表2】
【0075】
表２に示されるように、ユーザエージェントパラメータは、ＮＦインスタンスＩＤ等の、ＮＦインスタンスを識別する情報を含み得る。ＳＣＰ１０１Ａは、ＳＢＩ要求メッセージ（すなわち、代行発見のためのサービスアクセス要求または非代行発見のためのサービス要求メッセージ）のユーザエージェントヘッダからＮＦインスタンスＩＤを抽出し、その情報を使用してアクセストークン要求メッセージのＮＦインスタンスＩＤ属性をポピュレートし得る。同様に、ＮＦタイプもまた、ＳＢＩ要求メッセージのユーザエージェントヘッダから取得され得る。
【0076】
表１に戻ると、アクセストークン要求の要求元ＰＬＭＮは、ＳＣＰ１０１Ａの、設定された要求元ＰＬＭＮパラメータに基づいて、ポピュレートされ得る。ターゲットＰＬＭＮ属性は、ＳＢＩ要求メッセージの要求元統一資源識別子（Ｒ－ＵＲＩ）から抽出されたＡＰＩ名からポピュレートされ得る。アクセストークン要求の範囲属性は、ＳＢＩ要求メッセージのＲ－ＵＲＩから抽出されたサービス名からポピュレートされ得る。
【0077】
図７Ｂに戻ると、アクセストークン要求が定式化されると、ステップ７０２Ｂにおいて、ＳＣＰ１０１Ａは、アクセストークン要求をＮＲＦに送信する。例えば、ＳＣＰ１０１Ａは、プロデューサＮＦが位置するＰＬＭＮに位置するＮＲＦ１００Ｂにアクセストークン要求メッセージを送信してもよい。
【0078】
ステップ７０２Ｃにおいて、本プロセスは、アクセストークンを含むアクセストークン応答をＮＲＦから受信することを含む。例えば、ＳＣＰ１０１Ａは、アクセストークンを含むアクセストークン応答をＮＲＦ１００Ｂから受信してもよい。
【0079】
図７Ａに戻ると、ステップ７０４において、本プロセスは、アクセストークンを使用して、コンシューマＮＦがプロデューサＮＦによって提供されるサービスにアクセスすることを可能にすることを含む。図７Ｃは、図７Ａのステップ７０４のさらなる詳細を示す。図７Ｃを参照すると、本プロセスは、代行発見が実行されたかまたは非代行発見が実行されたかに応じて、わずかに異なる。代行発見が実行された場合、制御はステップ７０４Ａ１に進み、本プロセスは、以前に受信されたサービスアクセス要求に応答してＳＢＩサービス要求メッセージを生成することと、ステップ７０２においてコンシューマＮＦに代わって取得されたアクセストークンをＳＢＩサービス要求メッセージに挿入することとを含む。例えば、ＳＣＰ１０１Ａは、代行発見手順において識別されたプロデューサＮＦに向けられるＳＢＩサービス要求を生成し、それがＮＲＦ１００Ｂから取得したアクセストークンをＳＢＩサービス要求メッセージに挿入することができる。ステップ７０４Ｂ１において、本プロセスは、アクセストークンを含むＳＢＩサービス要求をプロデューサＮＦに転送することを含む。例えば、ＳＣＰ１０１Ａは、アクセストークンを含むＳＢＩサービス要求を、代行発見手順において識別されたプロデューサＮＦに転送することができる。次いで、プロデューサＮＦは、アクセストークンを使用してサービス要求を承認し、サービス要求に応答する。ＳＣＰ１０１Ａは、サービスアクセス要求を送信したコンシューマＮＦ２００に応答を転送する。
【0080】
代行発見が実施されない場合、制御はステップ７０４Ａ２に進み、ＳＣＰ１０１Ａは、アクセストークンを、以前に受信されたＳＢＩサービス要求に挿入する。非代行発見の場合のメッセージフローは、ライン１において受信されるメッセージがＳＢＩサービスアクセス要求ではなくＳＢＩサービス要求であり、発見が既に実行されていることを除いて、図４に示されるものと同様である。図４のライン２における代行発見メッセージングは必要とされない。非代行発見ケースの残りのステップは、図４に示すものと同じである。したがって、ステップ７０４Ｂ２において、ＳＣＰ１０１Ａは、アクセストークンを含むＳＢＩサービス要求をプロデューサＮＦに転送する。ＳＣＰ１０１Ａは、プロデューサＮＦから応答を受信すると、その応答をコンシューマＮＦに転送する。したがって、図７Ａ～図７Ｃは、ＳＣＰがアクセストークン承認クライアントプロキシとして機能し、アクセストークン承認クライアントプロキシは、本明細書で説明する例では、ＯＡｕｔｈ２．０承認クライアントプロキシである、ＳＣＰによる代行承認を示す。
【0081】
図８Ａは、アクセストークンベースの承認をサポートしないＮＲＦに代わってアクセストークン承認サーバプロキシとして機能するＳＣＰによって実行される例示的な代行承認プロセスを示す。図８Ａを参照すると、本プロセスは、ステップ８００において、非代行発見の場合にはコンシューマＮＦから、または代行発見の場合にはコンシューマＮＦに代わってリモートＳＣＰから、アクセストークン要求を受信することを含む。例えば、ＳＣＰ１０１Ａは、非代行発見の場合（図５Ａ参照）にはコンシューマＮＦ３００から、または代行発見の場合（図５Ｂ参照）にはＳＣＰ１０１Ｂから、アクセストークン要求を受信してもよい。
【0082】
ステップ８０２において、本プロセスは、アクセストークン要求に応答して、アクセストークンベースの承認をサポートしないＮＲＦに代わってアクセストークン承認サーバプロキシとして動作することを含む。ステップ８０２は、図８Ｂにさらに詳細に示される。図８Ｂを参照すると、ステップ８０２Ａにおいて、本プロセスは、アクセストークン要求に応答してアクセストークンを生成することを含む。たとえば、ＳＣＰ１０１Ａは、ＩＥＴＦ ＲＦＣ６７４９において指定される必要とされるクレームを含むアクセストークンを生成し得る。アクセストークンは、ＩＥＴＦ ＲＦＣ６７４９において指定されたフォーマットおよびコンテンツに従って構文的に正しいものであってもよい。しかしながら、以下で説明されるように、ＳＣＰ１０１Ａは、アクセストークンベースの承認をサポートしないプロデューサＮＦにサービス要求メッセージを転送する前にサービス要求メッセージからアクセストークンを除去することになるので、アクセストークンは実際のアクセストークンである必要はなく、構文的に正しいフィールドを有するダミーアクセストークンであり得る。
【0083】
ステップ８０２Ｂにおいて、本プロセスは、アクセストークン応答をコンシューマＮＦまたはＳＣＰに送信することを含む。例えば、ＳＣＰ１０１Ａは、それがステップ８０２Ａで生成したアクセストークン応答を、非代行発見の場合には要求側コンシューマＮＦに送信し、代行発見の場合にはリモートＳＣＰに送信することができる。
【0084】
図８Ａに戻ると、ステップ８０４において、本プロセスは、コンシューマＮＦがサービスにアクセスすることを可能にするよう、プロデューサＮＦおよびコンシューマＮＦまたはＳＣＰと信号通信を行うことを含む。ステップ８０４は、図８Ｃにより詳細に示される。図８Ｃを参照すると、プロデューサＮＦおよびコンシューマＮＦまたはＳＣＰとの信号通信のプロセスは、ステップ８０４Ａにおいて、コンシューマＮＦまたはＳＣＰから、アクセストークンを含むＳＢＩサービス要求を受信することを含む。例えば、ＳＣＰ１０１Ａは、（非代行発見の場合には）ＳＣＰ１０１Ａが生成したＮＦアクセストークンを含むＳＢＩサービス要求をＮＦサービスコンシューマ３００から、または代行発見の場合にはＳＣＰ１０１Ｂから、受信することができる。
【0085】
ステップ８０４Ｂにおいて、本プロセスは、ＳＢＩサービス要求からアクセストークンを除去することを含む。ステップ８０４Ｃにおいて、本プロセスは、ＳＢＩサービス要求をプロデューサＮＦに転送することを含む。例えば、ＳＣＰ１０１Ａは、それがＳＢＩサービス要求から生成したアクセストークンを除去し、ＳＢＩサービス要求をプロデューサＮＦに転送することができる。したがって、図８Ａ～図８Ｃは、アクセストークンベースの承認をサポートしないＮＲＦに代わってアクセストークン承認サーバプロキシおよび信号通信仲介者として機能する際にＳＣＰによって実行され得る例示的なステップを示す。
【0086】
本明細書で説明される主題の例示的な利点は、あるＰＬＭＮがアクセストークンベースの承認をサポートし、別のＰＬＭＮがサポートしない、ＰＬＭＮ間の改善された相互運用性を含む。本ソリューションをＳＣＰにおいて提供することは、ＳＣＰが複数のコンシューマＮＦに代わってメッセージングを扱うので、有益である。また、それは、単一のＳＣＰが、コンシューマＮＦおよびプロデューサＮＦのために、またはそれらに代わって、本明細書で説明される機能を果たすことができるため、スケーラブルなソリューションでもある。
【0087】
以下の参考文献の各々の開示は、参照によりその全体が本明細書に組み込まれる。
参照
1. Hardt, D. "The OAuth 2.0 Authorization Framework," IETF RFC 6749 (October 2012).
2. 3GPP TS 33.501 V17.0.0 (2020-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 17).
3. 3GPP TS 29.500 V17.1.0 (2020-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of the Service Based Architecture; Stage 3 (Release 17).
4. 3GPP TS 29.510 V17.0.0 (2020-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17).
5. 3GPP TS 23.501 V16.7.0 (2020-12); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16).
本明細書に記載される主題の様々な詳細は、本明細書に記載される主題の範囲から逸脱することなく変更され得ることが理解されるであろう。さらに、本明細書に記載される主題は、以下に記載される特許請求の範囲によって規定されるため、前述の説明は、例示のみを目的とし、限定を目的としない。
参照
1. Hardt, D. "The OAuth 2.0 Authorization Framework," IETF RFC 6749 (October 2012).
2. 3GPP TS 33.501 V17.0.0 (2020-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 17).
3. 3GPP TS 29.500 V17.1.0 (2020-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of the Service Based Architecture; Stage 3 (Release 17).
4. 3GPP TS 29.510 V17.0.0 (2020-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17).
5. 3GPP TS 23.501 V16.7.0 (2020-12); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16).
本明細書に記載される主題の様々な詳細は、本明細書に記載される主題の範囲から逸脱することなく変更され得ることが理解されるであろう。さらに、本明細書に記載される主題は、以下に記載される特許請求の範囲によって規定されるため、前述の説明は、例示のみを目的とし、限定を目的としない。
【図1】
【図2A】
【図2B】
【図3A】
【図3B】
【図3C】
【図4】
【図5A】
【図5B】
【図6】
【図7A】
【図7B】
【図7C】
【図8A】
【図8B】
【図8C】
【国際調査報告】