JP7346745B2

JP7346745B2 - サービスａｐｉ発行のための方法及びネットワークエンティティ

Info

Publication number: JP7346745B2
Application number: JP2022540574A
Authority: JP
Inventors: ブンリョウシュ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2020-02-14
Filing date: 2020-11-20
Publication date: 2023-09-19
Anticipated expiration: 2040-11-20
Also published as: EP4104417A1; CN115023931B; EP4239982A2; CN115023931A; CN117221385A; EP4104417B1; JP2024009797A; MX2022007792A; US20230046570A1; EP4239982A3; WO2021160307A1; JP2023516243A

Description

本開示は、通信技術、より具体的には、サービス・アプリケーション・プログラミング・インタフェース（ＡＰＩ）発行（Ｐｕｂｌｉｓｈｉｎｇ）のための方法及びネットワークエンティティに関する。

ノースバウンドＡＰＩを開発する第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））での関心の高まりに伴い、共通ＡＰＩフレームワーク（ＣＡＰＩＦ）は、複数のワーキンググループ間でのノースバウンドＡＰＩの一貫した開発を可能、つまり、基盤となる３ＧＰＰ（登録商標）ネットワーク機能をサードパーティのアプリケーションに公開又は抽象化するためにノースバウンドＡＰＩを定義する。ＣＡＰＩＦは、ＡＰＩの登録、認証、検出、ロギング及び課金に関して、ノースバウンドＡＰＩに共通のフレームワークを提供する。

３ＧＰＰ（登録商標）リリース１６において、ＣＡＰＩＦは、異なるＣＡＰＩＦプロバイダドメイン間又は同じＣＡＰＩＦプロバイダドメイン内の相互接続によって拡張される。図１は、ＣＡＰＩＦプロバイダのＡＰＩ呼び出し元がサードパーティＣＡＰＩＦプロバイダからのサービスＡＰＩを利用できる様にする、ＣＡＰＩＦ相互接続のアーキテクチャモデルを示している。図２は、同じＣＡＰＩＦプロバイダドメイン内のＣＡＰＩＦ相互接続のアーキテクチャモデルを示し、これにより、ＣＡＰＩＦコア機能（ＣＣＦ）１のＡＰＩ呼び出し元は、ＣＣＦ２からのサービスＡＰＩを利用でき、両方のＣＣＦがＣＡＰＩＦプロバイダＡの信頼ドメイン内でホストされる。図１において、２つのＣＣＦは、ＣＡＰＩＦ－６ｅインタフェース（参照ポイント）を介して相互に接続されているが、図２において、２つのＣＣＦは、ＣＡＰＩＦ－６インタフェース（参照ポイント）を介して相互に接続されている。ＣＡＰＩＦ－６／６ｅインタフェースは、サービスＡＰＩ情報の発行と検出をサポートする。サービスＡＰＩ発行の場合、ＡＰＩ発行機能（ＡＰＦ）（ＡＰＩ呼び出し元によるサービスＡＰＩの発見を可能にするため、ＡＰＩプロバイダがサービスＡＰＩ情報をＣＣＦに発行することを可能にする）又はＣＣＦは、ＡＰＩ発行要求又は相互接続ＡＰＩ発行要求において共有可能な情報を示すことができ、その様な情報は、サービスＡＰＩを共有できるかどうかと、共有できる場合にはどのＣＡＰＩＦプロバイダドメインと共有できるかを示す。これら及びその他の機能エンティティと、インタフェース（参照ポイント）と、ＡＰＩ発行要求及び応答と、相互接続ＡＰＩ発行要求及び応答と、の詳細については、３ＧＰＰ（登録商標）技術仕様（ＴＳ）２３．２２２、Ｖ１６．６．０を参照でき、本明細書ではその全体を参照する。

本開示の目的は、サービスＡＰＩ発行のための方法及びネットワークエンティティを提供することである。

本開示の第１の態様によると、サービスＡＰＩ発行のための第１ネットワークエンティティにおける方法が提供される。方法は、第２ネットワークエンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信することであって、第１ＡＰＩ発行要求は、サービスＡＰＩを発行したネットワークエンティティの識別子のリストを含む、ことを含み、方法は、さらに、第１ネットワークエンティティの識別子がリストに含まれている場合、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成することなく、かつ、いずれのネットワークエンティティにもサービスＡＰＩを発行することなく、サービスＡＰＩの発行の失敗を示すＡＰＩ発行応答を第２ネットワークエンティティに送信することと、第１ネットワークエンティティの識別子がリストに含まれていない場合、サービスＡＰＩを発行するための第２ＡＰＩ発行要求を第３ネットワークエンティティに送信することであって、第２ＡＰＩ発行要求は、第１ネットワークエンティティの識別子を第１リストに追加することにより得られた、ネットワークエンティティの識別子の第２リストを含む、ことと、を含む。

一実施形態において、第２ＡＰＩ発行要求は、第３ネットワークエンティティの識別子が第１リストに含まれていないと判定したことに応答して送信され得る。

一実施形態において、方法は、さらに、第１ネットワークエンティティの識別子が第１のリストに含まれない場合、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成することと、第２ネットワークエンティティに、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むＡＰＩ発行応答を送信することと、を含む。

一実施形態において、第１ネットワークエンティティ、第２ネットワークエンティティ、第３ネットワークエンティティ及びサービスＡＰＩを発行したネットワークエンティティのそれぞれは、ＣＣＦエンティティであり得る。

一実施形態において、第１ネットワークエンティティ、第２ネットワークエンティティ、第３ネットワークエンティティ及びサービスＡＰＩを発行したネットワークエンティティは、総て、単一ＣＡＰＩＦプロバイダドメイン内にあり得る。

本開示の第３態様によると、サービスＡＰＩ発行のための第１ネットワークエンティティにおける方法が提供される。方法は、機能エンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信することと、ＡＰＩを発行するための第２ＡＰＩ発行要求を第２ネットワークエンティティに送信することと、を含み、第２ＡＰＩ発行要求は、第１ネットワークエンティティの識別子を含む。

一実施形態において、第１ネットワークエンティティ及び第２ネットワークエンティティのそれぞれは、ＣＣＦエンティティであり、機能エンティティは、ＡＰＦエンティティであり得る。

一実施形態において、第１ネットワークエンティティ及び第２ネットワークエンティティは、両方とも、単一ＣＡＰＩＦプロバイダドメイン内にあり得る。

本開示の第４態様によると、第１ネットワークエンティティが提供される。第１ネットワークエンティティは、通信インタフェース、プロセッサ及びメモリを備えている。メモリは、プロセッサにより実行可能な命令を格納し、それにより、第１ネットワークエンティティは、第１態様、第２態様及び／又は第３態様による方法を実行する様に動作する。

本開示の第５態様によると、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、コンピュータプログラム命令を格納する。コンピュータプログラム命令は、第１ネットワークエンティティのプロセッサにより実行されると、第１ネットワークエンティティに、第１態様、第２態様及び／又は第３態様による方法を実行させる。

本開示の第６態様によると、通信システムが提供される。通信システムは、ＡＰＦエンティティと、複数のＣＣＦエンティティと、を含む。ＡＰＦエンティティは、サービスＡＰＩを発行するためのＡＰＩ発行要求を複数のＣＣＦエンティティの内の１つに送信する様に構成される。複数のＣＣＦエンティティのそれぞれは、第１態様、第２態様及び／又は第３態様による方法を実行する様に構成される。

本開示の実施形態により、サービスＡＰＩを発行するためのＡＰＩ発行要求を受信すると、ネットワークエンティティは、その識別子が、サービスＡＰＩを発行したネットワークエンティティの識別子のリストに含まれているかを判定できる（ＡＰＩ発行要求に含まれているか。）。その識別子がリストに含まれている場合、ネットワークエンティティは、サービスＡＰＩのために新たなリソースを作成することなく、かつ、いずれのネットワークエンティティにもサービスＡＰＩを発行することなく、サービスＡＰＩの発行の失敗を示す結果で応答する。一方、その識別子がリストに含まれていない場合にのみ、ＣＣＦエンティティは、サービスＡＰＩの新たなリソースを作成、及び／又は、サービスＡＰＩを別のネットワークエンティティに発行するための更なるＡＰＩ発行要求を送信する。更なるＡＰＩ発行要求は、ネットワークエンティティの識別子がリストに追加された、サービスＡＰＩを発行したネットワークエンティティの識別子の更新されたリストを含み得る。この様にして、ネットワークエンティティは、同じサービスＡＰＩのための冗長リソースの作成を回避し、サービングＡＰＩを発行するためのループを防ぐことができる。

上述した、及び、他の目的、特徴及び利点は、図を参照する以下の実施形態の記述から明らかになる。

異なるＣＡＰＩＦプロバイダドメイン間のＣＡＰＩＦ相互接続のアーキテクチャモデルを示す概略図。１つのＣＡＰＩＦプロバイダドメイン内のＣＡＰＩＦ相互接続のアーキテクチャモデルを示す概略図。サービスＡＰＩ発行のループの例を示す概略図。本開示の実施形態による、サービスＡＰＩ発行方法を示すフローチャート。本開示の別の実施形態による、サービスＡＰＩ発行方法を示すフローチャート。本開示の実施形態による、サービスＡＰＩ発行の例示的なプロセスを示すシーケンス図。本開示の一実施形態による、ネットワークエンティティのブロック図。本開示の別の実施形態による、ネットワークエンティティのブロック図。

本明細書における"一実施形態"、"実施形態"、"例示的な実施形態"等への言及は、説明された実施形態が、特定の特徴、構造又は特性を含み得ることを示すが、総ての実施形態が必ずしも特定の特徴、構造又は特性を含むとは限らない。さらに、その様なフレーズは必ずしも同じ実施形態を参照しているわけではない。さらに、特定の特徴、構造又は特性が実施形態に関して説明されている場合、他の実施形態に関連してその様な特性、構造又は特性を実装することは、明示的に記述されているか否かに拘わらず、当業者の知識の範囲内では提示されている。

本明細書では、"第１"及び"第２"等の用語を使用して様々な要素を説明することができるが、これらの要素はこれらの用語によって限定されるべきではないことを理解されたい。これらの用語は、ある要素と別の要素を区別するためにのみ使用される。例えば、例示的な実施形態の範囲から逸脱することなく、第１要素を第２要素と呼ぶことができ、同様に、第２要素を第１要素と呼ぶことができる。本明細書で使用される"及び／又は"という用語は、関連する列挙された用語の１つ又は複数のありとあらゆる組み合わせを含む。

本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、例示的な実施形態を限定することを意図していない。単数形式は、文脈が明らかに他の場合を示している場合を除き、複数形式を含むことが意図される。ここで使用する、用語"含む"、"有する"、"備える"等は、述べられた特徴、要素及び／又は構成部品の存在を特定するが、１つ以上の他の特徴、要素、構成部品及び／又はそれらの組み合わせの存在を除外するものではない。

以下の説明及び特許請求の範囲において、別の定義がなされていない限り、使用される総ての技術的及び科学的用語は、本開示の技術分野に属する当業者により通常理解されるのと同じ意味を有する。

図３に示す様に、ＣＡＰＩＦ－６／６ｅインタフェースを介したサービスＡＰＩ発行の場合、ＡＰＩは最初にＣＣＦ１からＣＣＦ２に発行され、次にＣＣＦ２からＣＣＦ３に発行され、次にＣＣＦ３からＣＣＦ１に発行される可能性がある。この場合、ＣＣＦ１は、ＡＰＩが最初に、例えば、ＡＰＦから発行されたときに作成したサービスＡＰＩリソースに加えて、ＡＰＩのための新たなサービスＡＰＩリソースを作成する。この様に、ＣＣＦ１は、同じＡＰＩによって占有される冗長なリソースを有する。さらに深刻なことに、ＣＣＦ１はＡＰＩをＣＣＦ２に再度発行し、ＣＣＦ２はＡＰＩをＣＣＦ３に発行する等、サービスＡＰＩ発行のループが生じる可能性がある。

図４は、本開示の実施形態による、サービスＡＰＩ発行のための方法４００を示すフローチャートである。方法４００は、第１ネットワークエンティティ、例えば、ＣＣＦエンティティにより実行され得る。

ブロック４１０で、サービスＡＰＩを発行するための第１ＡＰＩ発行要求が、第２ネットワークエンティティ（例えば、ＣＣＦエンティティ）から受信される。第１ＡＰＩ発行要求は、サービスＡＰＩを発行したネットワークエンティティ（例えば、ＣＣＦエンティティ）の識別子の第１リストを含む。この文脈において、リストは"発行されたＡＰＩパス"又は略して"ＡＰＩパス"としても参照され得る。

ここで、第１ＡＰＩ発行要求は、ＴＳ２３．２２２のセクション８．２５．２で仕様化されている相互接続ＡＰＩ発行要求であり得る。ＴＳ２３．２２２の表８．２５．２．１－１は、相互接続ＡＰＩ発行要求の情報要素（ＩＥ）を定義し、以下の表１として記載する。

上記の表８．２５．２．１－１のサービスＡＰＩ情報は、ＴＳ２９．２２２、Ｖ１６．１．０の表８．２．４．２．２－１で詳細に定義されており、以下の表２に示す様に、ＡＰＩパスを含める様に変更され得る。

属性"ｐｕｂＡｐｉＰａｔｈ"は、ＡＰＩを発行したＣＣＦエンティティの識別子を含む。たとえば、データタイプ"ＰｕｂｌｉｓｈｅｄＡｐｉＰａｔｈ"は、以下の表３で定義され得る。

表１の他のＩＥ及び表２の他の属性の詳細については、それぞれＴＳ２３．２２２の表８．２５．２．１－１及びＴＳ２９．２２２の表８．２．４．２．２－１を参照でき、ここでは省略する。

第１ネットワークエンティティの識別子が第１リストに含まれている場合、ブロック４２０において、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを生成することなく、かつ、いずれのネットワークエンティティにもサービスＡＰＩをさらに発行することなく、サービスＡＰＩ発行の失敗を示すＡＰＩ発行応答が、第２ネットワークエンティティに送信される。つまり、第１ネットワークエンティティの識別子がＡＰＩパスに含まれている場合、第１ＡＰＩ発行要求で発行されたサービスＡＰＩは、第１エンティティが発行したサービスＡＰＩであることを意味する。この場合、第１ネットワークエンティティは、同じサービスＡＰＩのための新たなリソースを作成したり、サービスＡＰＩをいずれかネットワークエンティティにもさらに発行したりしないため、リソースの浪費とＡＰＩ発行のループを回避できる。ここで、ＡＰＩ発行応答は、ＴＳ２３．２２２のセクション８．２５．２．２で仕様化されている相互接続ＡＰＩ発行応答であり得る。

一方、第１ネットワークエンティティの識別子が第１リストに含まれていない場合、ブロック４３０で、サービスＡＰＩを発行するための第２ＡＰＩ発行要求が第３ネットワークエンティティ（例えば、ＣＣＦエンティティ）に送信される。第２ＡＰＩ発行要求は、第１ネットワークエンティティの識別子を第１リストに追加することによって得られたネットワークエンティティの識別子の第２リストを含む。

一例において、ブロック４３０で、第２ＡＰＩ発行要求は、第３ネットワークエンティティの識別子が第１リストに含まれていないと判定したことに応答して送信され得る。言い換えると、第１ネットワークエンティティが第３ネットワークエンティティの識別子を知っていて、第３ネットワークエンティティの識別子が第１リストに含まれていると判定した場合、サービスＡＰＩが第３エンティティによって発行されたサービスＡＰＩであることを意味し、第１ネットワークエンティティは、同じサービスＡＰＩを第３ネットワークエンティティにさらに発行するために第２ＡＰＩ発行要求を送信せず、これにより、リソースの浪費とＡＰＩ発行のループを回避する。

さらに、第１ネットワークエンティティの識別子が第１のリストに含まれていない場合、第１ネットワークエンティティは、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成することができ、第２ネットワークエンティティに、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むＡＰＩ発行応答を送信することができる。ここで、ＡＰＩ発行応答は、ＴＳ２３．２２２のセクション８．２５．２．２で仕様化されている相互接続ＡＰＩ発行応答であり得る。

一例において、第１ネットワークエンティティ、第２ネットワークエンティティ、第３ネットワークエンティティ及びサービスＡＰＩを発行したネットワークエンティティは、総て、単一ＣＡＰＩＦプロバイダドメイン内にあり得る。別の例において、これらのネットワークエンティティは、異なるＣＡＰＩＦプロバイダドメインに属し得る。

実装において、方法４００は、ブロック４１０及び４２０のみを含み得る。別の実装において、方法４００は、ブロック４１０及び４３０のみを含み得る。更に別の実装において、方法４００は、ブロック４１０、４２０及び４３０を含み得る。

図５は、本開示の実施形態による、サービスＡＰＩ発行のための方法５００を示すフローチャートである。方法５００は、第１ネットワークエンティティ、例えば、ＣＣＦエンティティにより実行され得る。

ブロック５１０で、サービスＡＰＩを発行するための第１ＡＰＩ発行要求が、機能エンティティ（例えば、ＡＰＦエンティティ）から受信される。第１ＡＰＩ発行要求は、ＴＳ２３．２２２のセクション８．３．２．１で仕様化されているサービスＡＰＩ発行要求であり得る。

ブロック５２０で、ＡＰＩを発行するための第２ＡＰＩ発行要求は、例えば、ＡＰＩパスを含まない第１ＡＰＩ発行要求に応答して、第２ネットワークエンティティ（例えば、ＣＣＦエンティティ）に送信される。第２ＡＰＩ発行要求は、例えば、ＡＰＩパスに第１ネットワークエンティティの識別子を含む。第２ＡＰＩ発行要求は、表１による相互接続ＡＰＩ発行要求であり、表２による"ｐｕｂＡｐｉＰａｔｈ"を含み得る。

ここで、第１ＡＰＩ発行要求はＡＰＩパスを含まないため、第１ネットワークエンティティは、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成でき、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むＡＰＩ発行応答を機能エンティティに送信できる。ここで、ＡＰＩ発行応答は、ＴＳ２３．２２２のセクション８．３．２．２で仕様化されているサービスＡＰＩ発行応答であり得る。

一例において、第１ネットワークエンティティ及び第２ネットワークエンティティは、両方とも、単一ＣＡＰＩＦプロバイダドメイン内にあり得る。別の例において、これらのネットワークエンティティは、異なるＣＡＰＩＦプロバイダドメインに属し得る。

図６は、本開示の実施形態による、サービスＡＰＩ発行のための例示的なプロセスを示すシーケンス図である。このプロセスは、少なくともＡＰＦエンティティと複数のＣＣＦエンティティ（例えば、ＣＣＦ１、ＣＣＦ２及びＣＣＦ３）を含む通信システムで実行され得る。

６．１で、ＡＰＦエンティティは、サービスＡＰＩを発行するためのサービスＡＰＩ発行要求をＣＣＦ１に送信する。ＡＰＦエンティティからのサービスＡＰＩ発行要求は、ＡＰＩパスを含まないため、ＣＣＦ１はサービスＡＰＩのための新たなリソースを作成し、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むサービスＡＰＩ発行応答を、６．２で、ＡＰＦエンティティに送信する。６．３で、（サービスＡＰＩ発行要求の共有可能情報に応じて）サービスＡＰＩをＣＣＦ２と共有する場合、ＣＣＦ１は、ＣＣＦ１の識別子を含むＡＰＩパスを含む、サービスＡＰＩを発行するための相互接続ＡＰＩ発行要求をＣＣＦ２に送信する。相互接続ＡＰＩ発行要求を受信すると、ＣＣＦ２はＡＰＩパスを検査し、ＣＣＦ２の識別子がＡＰＩパスに含まれていないことを判定する。それに応じて、ＣＣＦ２はサービスＡＰＩのための新たなリソースを作成し、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含む相互接続ＡＰＩ発行応答を、６．４で、ＣＣＦ１に送信する。（ＣＣＦ１からの相互接続ＡＰＩ発行要求の共有可能情報に応じて）サービスＡＰＩをＣＣＦ３と共有する場合、ＣＣＦ２は、まず、ＣＣＦ３の識別子を認識している場合、ＣＣＦ３の識別子がＡＰＩパスに含まれているかを判定し得る。ＣＣＦ３の識別子を知っており、かつ、ＡＰＩパスに含まれていない場合、或いは、ＣＣＦ３の識別子をＣＣＦ２が知らない場合、６．５で、ＣＣＦ２は、サービスＡＰＩをＣＣＦ３に発行するための相互接続ＡＰＩ発行要求を送信し、これは、ＣＣＦ１及びＣＣＦ２の識別子を含むＡＰＩパスを含む。相互接続ＡＰＩ発行要求を受信すると、ＣＣＦ３は、ＡＰＩパスを検査し、ＣＣＦ３の識別子がＡＰＩパスに含まれていないことを判定する。それに応じて、ＣＣＦ３はサービスＡＰＩのための新たなリソースを作成し、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含む相互接続ＡＰＩ発行応答を、６．６で、ＣＣＦ２に送信する。

（ＣＣＦ２からの相互接続ＡＰＩ発行要求の共有可能情報に応じて）サービスＡＰＩをＣＣＦ１と共有する場合、ＣＣＦ３は、まず、ＣＣＦ１の識別子を知っている場合、ＣＣＦ１の識別子がＡＰＩパスに含まれているかを判定し得る。ＣＣＦ１の識別子を知っており、かつ、ＡＰＩパスに含まれている場合、ＣＣＦ３は、サービスＡＰＩをＣＣＦ１にそれ以上発行せず、よって、ループは生じない。しかしながら、ＣＣＦ１の識別子をＣＣＦ３が知らない場合、６．７で、ＣＣＦ３は、サービスＡＰＩをＣＣＦ１に発行するための相互接続ＡＰＩ発行要求を送信し、これは、ＣＣＦ１、ＣＣＦ２及びＣＣＦ３の識別子を含むＡＰＩパスを含む。相互接続ＡＰＩ発行要求を受信すると、ＣＣＦ１は、ＡＰＩパスを検査し、ＣＣＦ１の識別子がＡＰＩパスに含まれていることを判定する。したがって、ＣＣＦ１は、ＣＣＦ１でサービスＡＰＩのための新たなリソースを作成することなく、かつ、任意のネットワークエンティティにサービスＡＰＩをさらに発行することなく、６．８で、サービスＡＰＩの発行の失敗を示す相互接続ＡＰＩ発行応答を送信する。この場合、サービスＡＰＩ発行のループはない。

上述した方法４００又は５００に対応して、第１ネットワークエンティティが提供される。図７は、本開示の実施形態による第１ネットワークエンティティ７００のブロック図である。

第１ネットワークエンティティ７００は、図４に示す様に、方法４００を実行する様に動作できる。方法４００に関連して上述した様に、実装において、第１ネットワークエンティティ７００は、方法４００のブロック４１０及び４２０のみを実行する様に動作し得る。別の実装において、第１ネットワークエンティティ７００は、方法４００のブロック４１０及び４３０のみを実行する様に動作し得る。さらに別の実装において、第１ネットワークエンティティ７００は、方法４００のブロック４１０、４２０及び４３０を実行する様に動作し得る。

図７に示す様に、第１ネットワークエンティティ７００は、第２ネットワークエンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信する様に構成された受信ユニット７１０を含み、第１ＡＰＩ発行要求は、サービスＡＰＩを発行したネットワークエンティティの識別子の第１リストを含む。

第１ネットワークエンティティ７００は、第１ネットワークエンティティの識別子が第１リストに含まれている場合、サービスＡＰＩの発行の失敗を示すＡＰＩ発行応答を第２ネットワークエンティティに送信する様に構成された送信ユニット７２０をさらに含む。この場合、第１ネットワークエンティティ７００は、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成したり、サービスＡＰＩをいずれかのネットワークエンティティにさらに発行したりしない。

代わりに、又は、追加して、第１ネットワークエンティティの識別子が第１リストに含まれていない場合、送信ユニット７２０は、サービスＡＰＩを発行するための第２ＡＰＩ発行要求を第３ネットワークエンティティに送信する様に構成されることができ、第２ＡＰＩ発行要求は、第１ネットワークエンティティの識別子を第１リストに追加することにより得られた、ネットワークエンティティの識別子の第２リストを含む。この場合、第２ＡＰＩ発行要求は、第３ネットワークエンティティの識別子が第１リストに含まれていないと判定したことに応答して送信され得る。第１ネットワークエンティティ７００は、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成する様に構成された作成ユニットをさらに含むことができ、送信ユニット７２０は、第２ネットワークエンティティに、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むＡＰＩ発行応答を送信する様にさらに構成され得る。

代わりに、ネットワークエンティティ７００は、図５に示す様に、方法５００を実行する様に動作できる。図７に示す様に、ネットワークエンティティ７００は、機能エンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信する様に構成された受信ユニット７１０を含む。ネットワークエンティティ７００は、ＡＰＩを発行するための第２ＡＰＩ発行要求を第２ネットワークエンティティに送信する様に構成された送信ユニット７２０をさらに含み、第２ＡＰＩ発行要求は、第１ネットワークエンティティの識別子を含む。

ユニット７１０及び７２０は、純粋はハードウェアとして、例えば、プロセッサ若しくはマイクロプロセッサと、適切なソフトウェアと、ソフトウェアを格納するメモリと、プログラム可能な論理デバイス（ＰＬＤ）と、他の電子部品の１つ以上によるソフトウェアとハードウェアの組み合わせとして、或いは、例えば、図４又は５に示す上述した動作を実行する様に構成された処理回路として、実現され得る。

図８は、本開示の別の実施形態による第１ネットワークエンティティ８００のブロック図である。

第１ネットワークエンティティ８００は、通信インタフェース８１０と、プロセッサ８２０と、メモリ８３０と、を備えている。メモリ８３０は、プロセッサ８２０によって実行可能な命令を含み、それにより、第１ネットワークエンティティ８００は、例えば、図４に関連して前述した手順のアクションを実行する様に動作する。方法４００に関連して上述した様に、実装において、第１ネットワークエンティティ８００は、方法４００のブロック４１０及び４２０のみを実行する様に動作し得る。別の実装において、第１ネットワークエンティティ８００は、方法４００のブロック４１０及び４３０のみを実行する様に動作し得る。さらに別の実装において、第１ネットワークエンティティ８００は、方法４００のブロック４１０、４２０及び４３０を実行する様に動作し得る。

特に、メモリ８３０は、プロセッサ８２０によって実行可能な命令を含み、それにより、第１ネットワークエンティティ８００は、第２ネットワークエンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信する様に動作し、第１ＡＰＩ発行要求は、サービスＡＰＩを発行したネットワークエンティティの識別子の第１リストを含む。

メモリ８３０は、プロセッサ８２０によって実行可能な命令をさらに含み、それにより、第１ネットワークエンティティ８００は、第１ネットワークエンティティの識別子が第１リストに含まれている場合、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成したり、サービスＡＰＩをいずれかのネットワークエンティティにさらに発行したりすることなく、サービスＡＰＩの発行の失敗を示すＡＰＩ発行応答を第２ネットワークエンティティに送信する様に動作する。

代わりに、又は、追加して、メモリ８３０は、プロセッサ８２０によって実行可能な命令をさらに含み、それにより、第１ネットワークエンティティの識別子が第１リストに含まれていない場合、第１ネットワークエンティティ８００は、サービスＡＰＩを発行するための第２ＡＰＩ発行要求を第３ネットワークエンティティに送信する様に動作し、第２ＡＰＩ発行要求は、第１ネットワークエンティティの識別子を第１リストに追加することにより得られた、ネットワークエンティティの識別子の第２リストを含む。一実施形態において、第２ＡＰＩ発行要求は、第３ネットワークエンティティの識別子が第１リストに含まれていないと判定したことに応答して送信され得る。一実施形態において、メモリ８３０は、プロセッサ８２０によって実行可能な命令をさらに含み、それにより、第１ネットワークエンティティの識別子が第１のリストに含まれていない場合、第１ネットワークエンティティ８００は、第１ネットワークエンティティでサービスＡＰＩのための新たなリソースを作成し、第２ネットワークエンティティに、サービスＡＰＩの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むＡＰＩ発行応答を送信する様に動作する。

代わりに、メモリ８３０は、プロセッサ８２０によって実行可能な命令を含み、それにより、第１ネットワークエンティティ８００は、例えば、図５に関連して上述した手順のアクションを実行する様に動作する。特に、メモリ８３０は、プロセッサ８２０によって実行可能な命令を含み、それにより、第１ネットワークエンティティ８００は、機能エンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信し、ＡＰＩを発行するための第２ＡＰＩ発行要求を第２ネットワークエンティティに送信する様に動作し、第２ＡＰＩ発行要求は、第１ネットワークエンティティの識別子を含む。

本開示は、例えば、非一時的なコンピュータ可読記憶媒体、ＥＥＰＲＯＭ（電気的に消去可能なプログラム可能リードオンリーメモリ）、フラッシュメモリ、又は、ハードドライブといった、不揮発性又は揮発性メモリの形式である、少なくとも１つのコンピュータプログラム製品も提供する。コンピュータプログラム製品は、コンピュータプログラムを有する。コンピュータプログラムは、プロセッサ８２０によって実行されると、ネットワークエンティティ８００は、例えば、図４又は図５に関連して上述した手順のアクションを実行させる、コード／コンピュータ可読命令を含む。

コンピュータプログラム製品は、コンピュータプログラムモジュールで構成されたコンピュータプログラムコードとして構成され得る。コンピュータプログラムモジュールは、図４又は図５に示すフローの動作を基本的に実行する。

プロセッサは、単一ＣＰＵ（中央処理ユニット）であり得るが、２つ以上の処理ユニットを含み得る。例えば、プロセッサは、汎用目的マイクロプロセッサ、命令セットプロセッサ、及び／又は、関連チップセット、及び／又は、特定用途向け集積回路（ＡＳＩＣ）の様な特別なマイクロプロセッサを含み得る。プロセッサは、キャッシュ目的のためのボードメモリを含み得る。コンピュータプログラムは、プロセッサに接続されたコンピュータプログラム製品により担持され得る。コンピュータプログラム製品は、コンピュータプログラムを格納する非一時的なコンピュータ可読記憶媒体を含み得る。例えば、コンピュータプログラム製品は、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）又はＥＥＰＲＯＭを含み、上述したコンピュータプログラムモジュールは、他の実施形態において、メモリ形式の様々なコンピュータプログラム製品に分散され得る。

本開示について、実施形態を参照して説明した。種々の修正、置換及び追加が、本開示の範囲から逸脱することなく、当業者により行われ得ることを理解すべきである。よって、本開示の範囲は、上述した特定の実施形態に限定されず、添付の特許請求の範囲により定義されるのみである。

Claims

サービス・アプリケーション・プログラミング・インタフェース（ＡＰＩ）発行のための第１ネットワークエンティティにおける方法（４００）であって、
第２ネットワークエンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信（４１０）することであって、前記第１ＡＰＩ発行要求は、前記サービスＡＰＩを発行したネットワークエンティティの識別子の第１リストを含む、ことを含み、
前記方法（４００）は、さらに、
前記第１ネットワークエンティティの識別子が前記第１リストに含まれている場合、前記サービスＡＰＩの発行の失敗を示すＡＰＩ発行応答を前記第２ネットワークエンティティに送信（４２０）すること、
を含む方法。
サービス・アプリケーション・プログラミング・インタフェース（ＡＰＩ）発行のための第１ネットワークエンティティにおける方法（４００）であって、
第２ネットワークエンティティから、サービスＡＰＩを発行するための第１ＡＰＩ発行要求を受信（４１０）することであって、前記第１ＡＰＩ発行要求は、前記サービスＡＰＩを発行したネットワークエンティティの識別子の第１リストを含む、ことと、
前記第１ネットワークエンティティの識別子が前記第１リストに含まれていない場合、ネットワークエンティティの識別子の第２リストを得るために、前記第１ネットワークエンティティの前記識別子を前記第１リストに追加することと、
を含む方法。
請求項２に記載の方法（４００）であって、
第３ネットワークエンティティの識別子が前記第１リストに含まれていないとの判定に応答して、ネットワークエンティティの識別子の前記第２リストを含む要求を前記第３ネットワークエンティティに送信（４３０）することを含む、方法。
請求項１から３のいずれか１項に記載の方法（４００）であって、さらに、
前記第１ネットワークエンティティの前記識別子が前記第１リストに含まれていない場合、
前記第１ネットワークエンティティで前記サービスＡＰＩのための新たなリソースを作成することと、
前記第２ネットワークエンティティに、前記サービスＡＰＩの発行の成功を示し、かつ、作成された前記新たなリソースの識別子を含むＡＰＩ発行応答を送信することと、
を含む方法。
請求項１から４のいずれか１項に記載の方法（４００）であって、
前記第１ネットワークエンティティ、前記第２ネットワークエンティティ及び前記サービスＡＰＩを発行した前記ネットワークエンティティのそれぞれは、共通ＡＰＩフレームワーク（ＣＡＰＩＦ）コア機能（ＣＣＦ）エンティティである、方法。
請求項５に記載の方法（４００）であって、
前記第１ネットワークエンティティ、前記第２ネットワークエンティティ及び前記サービスＡＰＩを発行した前記ネットワークエンティティは、総て、単一ＣＡＰＩＦプロバイダドメイン内にある、方法。
通信インタフェース（８１０）と、プロセッサ（８２０）と、メモリ（８３０）と、を含む第１ネットワークエンティティ（８００）であって、
前記メモリ（８３０）は、前記プロセッサ（８２０）によって実行可能な命令を含み、それにより、前記第１ネットワークエンティティ（８００）は、請求項１から６のいずれか１項に記載の方法を実行する様に動作する、第１ネットワークエンティティ。
コンピュータプログラム命令を格納しているコンピュータ可読記憶媒体であって、
前記コンピュータプログラム命令は、第１ネットワークエンティティのプロセッサによって実行されると、前記第１ネットワークエンティティに、請求項１から６のいずれか１項に記載の方法を実行させる、コンピュータ可読記憶媒体。