IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ テレフオンアクチーボラゲット エル エム エリクソン(パブル)の特許一覧

特開2024-9797サービスAPI発行のための方法及びネットワークエンティティ
<>
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図1
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図2
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図3
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図4
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図5
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図6
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図7
  • 特開-サービスAPI発行のための方法及びネットワークエンティティ 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024009797
(43)【公開日】2024-01-23
(54)【発明の名称】サービスAPI発行のための方法及びネットワークエンティティ
(51)【国際特許分類】
   H04L 41/122 20220101AFI20240116BHJP
   H04W 92/02 20090101ALI20240116BHJP
   H04W 48/08 20090101ALI20240116BHJP
【FI】
H04L41/122
H04W92/02
H04W48/08
【審査請求】有
【請求項の数】7
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2023144636
(22)【出願日】2023-09-06
(62)【分割の表示】P 2022540574の分割
【原出願日】2020-11-20
(31)【優先権主張番号】PCT/CN2020/075379
(32)【優先日】2020-02-14
(33)【優先権主張国・地域又は機関】CN
(71)【出願人】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン(パブル)
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】シュ, ブンリョウ
(57)【要約】      (修正有)
【課題】本開示は、サービス・アプリケーション・プログラミング・インタフェース(API)発行のための第1ネットワークエンティティにおける方法(400)を提供する。
【解決手段】方法(400)は、第2ネットワークエンティティから、サービスAPIを発行するための、サービスAPIを発行したネットワークエンティティの識別子のリストを含むAPI発行要求を受信(410)することと、第1ネットワークエンティティの識別子がリストに含まれている場合、第1ネットワークエンティティでサービスAPIのための新たなリソースを生成することなく、かつ、いずれのネットワークエンティティにもサービスAPIを発行することなく、サービスAPIの発行の失敗を示すAPI発行応答を第2ネットワークエンティティに送信(420)することと、を含む。
【選択図】図4
【特許請求の範囲】
【請求項1】
サービス・アプリケーション・プログラミング・インタフェース(API)発行のための第1ネットワークエンティティにおける方法(400)であって、
第2ネットワークエンティティから、サービスAPIを発行するための第1API発行要求を受信(410)することを含み、前記第1API発行要求は、前記サービスAPIを発行したネットワークエンティティの識別子のリストを含み、
前記方法(400)は、さらに、
前記第1ネットワークエンティティの識別子が前記リストに含まれている場合、前記第1ネットワークエンティティで前記サービスAPIのための新たなリソースを作成することなく、かつ、いずれのネットワークエンティティにも前記サービスAPIを発行することなく、前記サービスAPIの発行の失敗を示すAPI発行応答を前記第2ネットワークエンティティに送信(420)すること、或いは、
前記第1ネットワークエンティティの識別子が前記第1リストに含まれていない場合、前記サービスAPIを発行するための第2API発行要求を第3ネットワークエンティティに送信(430)することであって、前記第2API発行要求は、前記第1ネットワークエンティティの前記識別子を前記第1リストに追加することにより得られた、ネットワークエンティティの識別子の第2リストを含む、こと、
を含む方法。
【請求項2】
請求項1に記載の方法(400)であって、
前記送信(430)することは、前記第3ネットワークエンティティの識別子が前記第1リストに含まれていないと判定したことの応答である、方法。
【請求項3】
請求項1又は2に記載の方法(400)であって、さらに、
前記第1ネットワークエンティティの前記識別子が前記第1リストに含まれていない場合、
前記第1ネットワークエンティティで前記サービスAPIのための新たなリソースを作成することと、
前記第2ネットワークエンティティに、前記サービスAPIの発行の成功を示し、かつ、作成された前記新たなリソースの識別子を含むAPI発行応答を送信することと、
を含む方法。
【請求項4】
請求項1から3のいずれか1項に記載の方法(400)であって、
前記第1ネットワークエンティティ、前記第2ネットワークエンティティ、前記第3ネットワークエンティティ及び前記サービスAPIを発行した前記ネットワークエンティティのそれぞれは、共通APIフレームワーク(CAPIF)コア機能(CCF)エンティティである、方法。
【請求項5】
請求項4に記載の方法(400)であって、
前記第1ネットワークエンティティ、前記第2ネットワークエンティティ、前記第3ネットワークエンティティ及び前記サービスAPIを発行した前記ネットワークエンティティは、総て、単一CAPIFプロバイダドメイン内にある、方法。
【請求項6】
サービス・アプリケーション・プログラミング・インタフェース(API)発行のための第1ネットワークエンティティにおける方法(500)であって、
機能エンティティから、サービスAPIを発行するための第1API発行要求を受信(510)することと、
前記APIを発行するための第2API発行要求を第2ネットワークエンティティに送信(520)することと、
を含み、
前記第2API発行要求は、前記第1ネットワークエンティティの識別子を含む、方法。
【請求項7】
請求項6に記載の方法(500)であって、
前記第1ネットワークエンティティ及び前記第2ネットワークエンティティのそれぞれは、共通APIフレームワーク(CAPIF)コア機能(CCF)エンティティであり、
前記機能エンティティは、API発行機能(APF)エンティティである、方法。
【請求項8】
請求項7に記載の方法(500)であって、
前記第1ネットワークエンティティ及び前記第2ネットワークエンティティは、両方とも、単一CAPIFプロバイダドメイン内にある、方法。
【請求項9】
通信インタフェース(810)と、プロセッサ(820)と、メモリ(830)と、を含む第1ネットワークエンティティ(800)であって、
前記メモリ(830)は、前記プロセッサ(820)によって実行可能な命令を含み、それにより、前記第1ネットワークエンティティ(800)は、請求項1から8のいずれか1項に記載の方法を実行する様に動作する、第1ネットワークエンティティ。
【請求項10】
コンピュータプログラム命令を格納しているコンピュータ可読記憶媒体であって、
前記コンピュータプログラム命令は、第1ネットワークエンティティのプロセッサによって実行されると、前記第1ネットワークエンティティに、請求項1から8のいずれか1項に記載の方法を実行させる、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、通信技術、より具体的には、サービス・アプリケーション・プログラミング・インタフェース(API)発行(Publishing)のための方法及びネットワークエンティティに関する。
【背景技術】
【0002】
ノースバウンドAPIを開発する第3世代パートナーシッププロジェクト(3GPP(登録商標))での関心の高まりに伴い、共通APIフレームワーク(CAPIF)は、複数のワーキンググループ間でのノースバウンドAPIの一貫した開発を可能、つまり、基盤となる3GPP(登録商標)ネットワーク機能をサードパーティのアプリケーションに公開又は抽象化するためにノースバウンドAPIを定義する。CAPIFは、APIの登録、認証、検出、ロギング及び課金に関して、ノースバウンドAPIに共通のフレームワークを提供する。
【0003】
3GPP(登録商標)リリース16において、CAPIFは、異なるCAPIFプロバイダドメイン間又は同じCAPIFプロバイダドメイン内の相互接続によって拡張される。図1は、CAPIFプロバイダのAPI呼び出し元がサードパーティCAPIFプロバイダからのサービスAPIを利用できる様にする、CAPIF相互接続のアーキテクチャモデルを示している。図2は、同じCAPIFプロバイダドメイン内のCAPIF相互接続のアーキテクチャモデルを示し、これにより、CAPIFコア機能(CCF)1のAPI呼び出し元は、CCF2からのサービスAPIを利用でき、両方のCCFがCAPIFプロバイダAの信頼ドメイン内でホストされる。図1において、2つのCCFは、CAPIF-6eインタフェース(参照ポイント)を介して相互に接続されているが、図2において、2つのCCFは、CAPIF-6インタフェース(参照ポイント)を介して相互に接続されている。CAPIF-6/6eインタフェースは、サービスAPI情報の発行と検出をサポートする。サービスAPI発行の場合、API発行機能(APF)(API呼び出し元によるサービスAPIの発見を可能にするため、APIプロバイダがサービスAPI情報をCCFに発行することを可能にする)又はCCFは、API発行要求又は相互接続API発行要求において共有可能な情報を示すことができ、その様な情報は、サービスAPIを共有できるかどうかと、共有できる場合にはどのCAPIFプロバイダドメインと共有できるかを示す。これら及びその他の機能エンティティと、インタフェース(参照ポイント)と、API発行要求及び応答と、相互接続API発行要求及び応答と、の詳細については、3GPP(登録商標)技術仕様(TS)23.222、V16.6.0を参照でき、本明細書ではその全体を参照する。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本開示の目的は、サービスAPI発行のための方法及びネットワークエンティティを提供することである。
【課題を解決するための手段】
【0005】
本開示の第1の態様によると、サービスAPI発行のための第1ネットワークエンティティにおける方法が提供される。方法は、第2ネットワークエンティティから、サービスAPIを発行するための第1API発行要求を受信することであって、第1API発行要求は、サービスAPIを発行したネットワークエンティティの識別子のリストを含む、ことを含み、方法は、さらに、第1ネットワークエンティティの識別子がリストに含まれている場合、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成することなく、かつ、いずれのネットワークエンティティにもサービスAPIを発行することなく、サービスAPIの発行の失敗を示すAPI発行応答を第2ネットワークエンティティに送信することと、第1ネットワークエンティティの識別子がリストに含まれていない場合、サービスAPIを発行するための第2API発行要求を第3ネットワークエンティティに送信することであって、第2API発行要求は、第1ネットワークエンティティの識別子を第1リストに追加することにより得られた、ネットワークエンティティの識別子の第2リストを含む、ことと、を含む。
【0006】
一実施形態において、第2API発行要求は、第3ネットワークエンティティの識別子が第1リストに含まれていないと判定したことに応答して送信され得る。
【0007】
一実施形態において、方法は、さらに、第1ネットワークエンティティの識別子が第1のリストに含まれない場合、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成することと、第2ネットワークエンティティに、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むAPI発行応答を送信することと、を含む。
【0008】
一実施形態において、第1ネットワークエンティティ、第2ネットワークエンティティ、第3ネットワークエンティティ及びサービスAPIを発行したネットワークエンティティのそれぞれは、CCFエンティティであり得る。
【0009】
一実施形態において、第1ネットワークエンティティ、第2ネットワークエンティティ、第3ネットワークエンティティ及びサービスAPIを発行したネットワークエンティティは、総て、単一CAPIFプロバイダドメイン内にあり得る。
【0010】
本開示の第3態様によると、サービスAPI発行のための第1ネットワークエンティティにおける方法が提供される。方法は、機能エンティティから、サービスAPIを発行するための第1API発行要求を受信することと、APIを発行するための第2API発行要求を第2ネットワークエンティティに送信することと、を含み、第2API発行要求は、第1ネットワークエンティティの識別子を含む。
【0011】
一実施形態において、第1ネットワークエンティティ及び第2ネットワークエンティティのそれぞれは、CCFエンティティであり、機能エンティティは、APFエンティティであり得る。
【0012】
一実施形態において、第1ネットワークエンティティ及び第2ネットワークエンティティは、両方とも、単一CAPIFプロバイダドメイン内にあり得る。
【0013】
本開示の第4態様によると、第1ネットワークエンティティが提供される。第1ネットワークエンティティは、通信インタフェース、プロセッサ及びメモリを備えている。メモリは、プロセッサにより実行可能な命令を格納し、それにより、第1ネットワークエンティティは、第1態様、第2態様及び/又は第3態様による方法を実行する様に動作する。
【0014】
本開示の第5態様によると、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、コンピュータプログラム命令を格納する。コンピュータプログラム命令は、第1ネットワークエンティティのプロセッサにより実行されると、第1ネットワークエンティティに、第1態様、第2態様及び/又は第3態様による方法を実行させる。
【0015】
本開示の第6態様によると、通信システムが提供される。通信システムは、APFエンティティと、複数のCCFエンティティと、を含む。APFエンティティは、サービスAPIを発行するためのAPI発行要求を複数のCCFエンティティの内の1つに送信する様に構成される。複数のCCFエンティティのそれぞれは、第1態様、第2態様及び/又は第3態様による方法を実行する様に構成される。
【0016】
本開示の実施形態により、サービスAPIを発行するためのAPI発行要求を受信すると、ネットワークエンティティは、その識別子が、サービスAPIを発行したネットワークエンティティの識別子のリストに含まれているかを判定できる(API発行要求に含まれているか。)。その識別子がリストに含まれている場合、ネットワークエンティティは、サービスAPIのために新たなリソースを作成することなく、かつ、いずれのネットワークエンティティにもサービスAPIを発行することなく、サービスAPIの発行の失敗を示す結果で応答する。一方、その識別子がリストに含まれていない場合にのみ、CCFエンティティは、サービスAPIの新たなリソースを作成、及び/又は、サービスAPIを別のネットワークエンティティに発行するための更なるAPI発行要求を送信する。更なるAPI発行要求は、ネットワークエンティティの識別子がリストに追加された、サービスAPIを発行したネットワークエンティティの識別子の更新されたリストを含み得る。この様にして、ネットワークエンティティは、同じサービスAPIのための冗長リソースの作成を回避し、サービングAPIを発行するためのループを防ぐことができる。
【0017】
上述した、及び、他の目的、特徴及び利点は、図を参照する以下の実施形態の記述から明らかになる。
【図面の簡単な説明】
【0018】
図1】異なるCAPIFプロバイダドメイン間のCAPIF相互接続のアーキテクチャモデルを示す概略図。
図2】1つのCAPIFプロバイダドメイン内のCAPIF相互接続のアーキテクチャモデルを示す概略図。
図3】サービスAPI発行のループの例を示す概略図。
図4】本開示の実施形態による、サービスAPI発行方法を示すフローチャート。
図5】本開示の別の実施形態による、サービスAPI発行方法を示すフローチャート。
図6】本開示の実施形態による、サービスAPI発行の例示的なプロセスを示すシーケンス図。
図7】本開示の一実施形態による、ネットワークエンティティのブロック図。
図8】本開示の別の実施形態による、ネットワークエンティティのブロック図。
【発明を実施するための形態】
【0019】
本明細書における"一実施形態"、"実施形態"、"例示的な実施形態"等への言及は、説明された実施形態が、特定の特徴、構造又は特性を含み得ることを示すが、総ての実施形態が必ずしも特定の特徴、構造又は特性を含むとは限らない。さらに、その様なフレーズは必ずしも同じ実施形態を参照しているわけではない。さらに、特定の特徴、構造又は特性が実施形態に関して説明されている場合、他の実施形態に関連してその様な特性、構造又は特性を実装することは、明示的に記述されているか否かに拘わらず、当業者の知識の範囲内では提示されている。
【0020】
本明細書では、"第1"及び"第2"等の用語を使用して様々な要素を説明することができるが、これらの要素はこれらの用語によって限定されるべきではないことを理解されたい。これらの用語は、ある要素と別の要素を区別するためにのみ使用される。例えば、例示的な実施形態の範囲から逸脱することなく、第1要素を第2要素と呼ぶことができ、同様に、第2要素を第1要素と呼ぶことができる。本明細書で使用される"及び/又は"という用語は、関連する列挙された用語の1つ又は複数のありとあらゆる組み合わせを含む。
【0021】
本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、例示的な実施形態を限定することを意図していない。単数形式は、文脈が明らかに他の場合を示している場合を除き、複数形式を含むことが意図される。ここで使用する、用語"含む"、"有する"、"備える"等は、述べられた特徴、要素及び/又は構成部品の存在を特定するが、1つ以上の他の特徴、要素、構成部品及び/又はそれらの組み合わせの存在を除外するものではない。
【0022】
以下の説明及び特許請求の範囲において、別の定義がなされていない限り、使用される総ての技術的及び科学的用語は、本開示の技術分野に属する当業者により通常理解されるのと同じ意味を有する。
【0023】
図3に示す様に、CAPIF-6/6eインタフェースを介したサービスAPI発行の場合、APIは最初にCCF1からCCF2に発行され、次にCCF2からCCF3に発行され、次にCCF3からCCF1に発行される可能性がある。この場合、CCF1は、APIが最初に、例えば、APFから発行されたときに作成したサービスAPIリソースに加えて、APIのための新たなサービスAPIリソースを作成する。この様に、CCF1は、同じAPIによって占有される冗長なリソースを有する。さらに深刻なことに、CCF1はAPIをCCF2に再度発行し、CCF2はAPIをCCF3に発行する等、サービスAPI発行のループが生じる可能性がある。
【0024】
図4は、本開示の実施形態による、サービスAPI発行のための方法400を示すフローチャートである。方法400は、第1ネットワークエンティティ、例えば、CCFエンティティにより実行され得る。
【0025】
ブロック410で、サービスAPIを発行するための第1API発行要求が、第2ネットワークエンティティ(例えば、CCFエンティティ)から受信される。第1API発行要求は、サービスAPIを発行したネットワークエンティティ(例えば、CCFエンティティ)の識別子の第1リストを含む。この文脈において、リストは"発行されたAPIパス"又は略して"APIパス"としても参照され得る。
【0026】
ここで、第1API発行要求は、TS23.222のセクション8.25.2で仕様化されている相互接続API発行要求であり得る。TS23.222の表8.25.2.1-1は、相互接続API発行要求の情報要素(IE)を定義し、以下の表1として記載する。
【0027】
【表1】
【0028】
上記の表8.25.2.1-1のサービスAPI情報は、TS29.222、V16.1.0の表8.2.4.2.2-1で詳細に定義されており、以下の表2に示す様に、APIパスを含める様に変更され得る。
【0029】
【表2】
【0030】
属性"pubApiPath"は、APIを発行したCCFエンティティの識別子を含む。たとえば、データタイプ"PublishedApiPath"は、以下の表3で定義され得る。
【0031】
【表3】
【0032】
表1の他のIE及び表2の他の属性の詳細については、それぞれTS23.222の表8.25.2.1-1及びTS29.222の表8.2.4.2.2-1を参照でき、ここでは省略する。
【0033】
第1ネットワークエンティティの識別子が第1リストに含まれている場合、ブロック420において、第1ネットワークエンティティでサービスAPIのための新たなリソースを生成することなく、かつ、いずれのネットワークエンティティにもサービスAPIをさらに発行することなく、サービスAPI発行の失敗を示すAPI発行応答が、第2ネットワークエンティティに送信される。つまり、第1ネットワークエンティティの識別子がAPIパスに含まれている場合、第1API発行要求で発行されたサービスAPIは、第1エンティティが発行したサービスAPIであることを意味する。この場合、第1ネットワークエンティティは、同じサービスAPIのための新たなリソースを作成したり、サービスAPIをいずれかネットワークエンティティにもさらに発行したりしないため、リソースの浪費とAPI発行のループを回避できる。ここで、API発行応答は、TS23.222のセクション8.25.2.2で仕様化されている相互接続API発行応答であり得る。
【0034】
一方、第1ネットワークエンティティの識別子が第1リストに含まれていない場合、ブロック430で、サービスAPIを発行するための第2API発行要求が第3ネットワークエンティティ(例えば、CCFエンティティ)に送信される。第2API発行要求は、第1ネットワークエンティティの識別子を第1リストに追加することによって得られたネットワークエンティティの識別子の第2リストを含む。
【0035】
一例において、ブロック430で、第2API発行要求は、第3ネットワークエンティティの識別子が第1リストに含まれていないと判定したことに応答して送信され得る。言い換えると、第1ネットワークエンティティが第3ネットワークエンティティの識別子を知っていて、第3ネットワークエンティティの識別子が第1リストに含まれていると判定した場合、サービスAPIが第3エンティティによって発行されたサービスAPIであることを意味し、第1ネットワークエンティティは、同じサービスAPIを第3ネットワークエンティティにさらに発行するために第2API発行要求を送信せず、これにより、リソースの浪費とAPI発行のループを回避する。
【0036】
さらに、第1ネットワークエンティティの識別子が第1のリストに含まれていない場合、第1ネットワークエンティティは、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成することができ、第2ネットワークエンティティに、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むAPI発行応答を送信することができる。ここで、API発行応答は、TS23.222のセクション8.25.2.2で仕様化されている相互接続API発行応答であり得る。
【0037】
一例において、第1ネットワークエンティティ、第2ネットワークエンティティ、第3ネットワークエンティティ及びサービスAPIを発行したネットワークエンティティは、総て、単一CAPIFプロバイダドメイン内にあり得る。別の例において、これらのネットワークエンティティは、異なるCAPIFプロバイダドメインに属し得る。
【0038】
実装において、方法400は、ブロック410及び420のみを含み得る。別の実装において、方法400は、ブロック410及び430のみを含み得る。更に別の実装において、方法400は、ブロック410、420及び430を含み得る。
【0039】
図5は、本開示の実施形態による、サービスAPI発行のための方法500を示すフローチャートである。方法500は、第1ネットワークエンティティ、例えば、CCFエンティティにより実行され得る。
【0040】
ブロック510で、サービスAPIを発行するための第1API発行要求が、機能エンティティ(例えば、APFエンティティ)から受信される。第1API発行要求は、TS23.222のセクション8.3.2.1で仕様化されているサービスAPI発行要求であり得る。
【0041】
ブロック520で、APIを発行するための第2API発行要求は、例えば、APIパスを含まない第1API発行要求に応答して、第2ネットワークエンティティ(例えば、CCFエンティティ)に送信される。第2API発行要求は、例えば、APIパスに第1ネットワークエンティティの識別子を含む。第2API発行要求は、表1による相互接続API発行要求であり、表2による"pubApiPath"を含み得る。
【0042】
ここで、第1API発行要求はAPIパスを含まないため、第1ネットワークエンティティは、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成でき、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むAPI発行応答を機能エンティティに送信できる。ここで、API発行応答は、TS23.222のセクション8.3.2.2で仕様化されているサービスAPI発行応答であり得る。
【0043】
一例において、第1ネットワークエンティティ及び第2ネットワークエンティティは、両方とも、単一CAPIFプロバイダドメイン内にあり得る。別の例において、これらのネットワークエンティティは、異なるCAPIFプロバイダドメインに属し得る。
【0044】
図6は、本開示の実施形態による、サービスAPI発行のための例示的なプロセスを示すシーケンス図である。このプロセスは、少なくともAPFエンティティと複数のCCFエンティティ(例えば、CCF1、CCF2及びCCF3)を含む通信システムで実行され得る。
【0045】
6.1で、APFエンティティは、サービスAPIを発行するためのサービスAPI発行要求をCCF1に送信する。APFエンティティからのサービスAPI発行要求は、APIパスを含まないため、CCF1はサービスAPIのための新たなリソースを作成し、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むサービスAPI発行応答を、6.2で、APFエンティティに送信する。6.3で、(サービスAPI発行要求の共有可能情報に応じて)サービスAPIをCCF2と共有する場合、CCF1は、CCF1の識別子を含むAPIパスを含む、サービスAPIを発行するための相互接続API発行要求をCCF2に送信する。相互接続API発行要求を受信すると、CCF2はAPIパスを検査し、CCF2の識別子がAPIパスに含まれていないことを判定する。それに応じて、CCF2はサービスAPIのための新たなリソースを作成し、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含む相互接続API発行応答を、6.4で、CCF1に送信する。(CCF1からの相互接続API発行要求の共有可能情報に応じて)サービスAPIをCCF3と共有する場合、CCF2は、まず、CCF3の識別子を認識している場合、CCF3の識別子がAPIパスに含まれているかを判定し得る。CCF3の識別子を知っており、かつ、APIパスに含まれていない場合、或いは、CCF3の識別子をCCF2が知らない場合、6.5で、CCF2は、サービスAPIをCCF3に発行するための相互接続API発行要求を送信し、これは、CCF1及びCCF2の識別子を含むAPIパスを含む。相互接続API発行要求を受信すると、CCF3は、APIパスを検査し、CCF3の識別子がAPIパスに含まれていないことを判定する。それに応じて、CCF3はサービスAPIのための新たなリソースを作成し、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含む相互接続API発行応答を、6.6で、CCF2に送信する。
【0046】
(CCF2からの相互接続API発行要求の共有可能情報に応じて)サービスAPIをCCF1と共有する場合、CCF3は、まず、CCF1の識別子を知っている場合、CCF1の識別子がAPIパスに含まれているかを判定し得る。CCF1の識別子を知っており、かつ、APIパスに含まれている場合、CCF3は、サービスAPIをCCF1にそれ以上発行せず、よって、ループは生じない。しかしながら、CCF1の識別子をCCF3が知らない場合、6.7で、CCF3は、サービスAPIをCCF1に発行するための相互接続API発行要求を送信し、これは、CCF1、CCF2及びCCF3の識別子を含むAPIパスを含む。相互接続API発行要求を受信すると、CCF1は、APIパスを検査し、CCF1の識別子がAPIパスに含まれていることを判定する。したがって、CCF1は、CCF1でサービスAPIのための新たなリソースを作成することなく、かつ、任意のネットワークエンティティにサービスAPIをさらに発行することなく、6.8で、サービスAPIの発行の失敗を示す相互接続API発行応答を送信する。この場合、サービスAPI発行のループはない。
【0047】
上述した方法400又は500に対応して、第1ネットワークエンティティが提供される。図7は、本開示の実施形態による第1ネットワークエンティティ700のブロック図である。
【0048】
第1ネットワークエンティティ700は、図4に示す様に、方法400を実行する様に動作できる。方法400に関連して上述した様に、実装において、第1ネットワークエンティティ700は、方法400のブロック410及び420のみを実行する様に動作し得る。別の実装において、第1ネットワークエンティティ700は、方法400のブロック410及び430のみを実行する様に動作し得る。さらに別の実装において、第1ネットワークエンティティ700は、方法400のブロック410、420及び430を実行する様に動作し得る。
【0049】
図7に示す様に、第1ネットワークエンティティ700は、第2ネットワークエンティティから、サービスAPIを発行するための第1API発行要求を受信する様に構成された受信ユニット710を含み、第1API発行要求は、サービスAPIを発行したネットワークエンティティの識別子の第1リストを含む。
【0050】
第1ネットワークエンティティ700は、第1ネットワークエンティティの識別子が第1リストに含まれている場合、サービスAPIの発行の失敗を示すAPI発行応答を第2ネットワークエンティティに送信する様に構成された送信ユニット720をさらに含む。この場合、第1ネットワークエンティティ700は、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成したり、サービスAPIをいずれかのネットワークエンティティにさらに発行したりしない。
【0051】
代わりに、又は、追加して、第1ネットワークエンティティの識別子が第1リストに含まれていない場合、送信ユニット720は、サービスAPIを発行するための第2API発行要求を第3ネットワークエンティティに送信する様に構成されることができ、第2API発行要求は、第1ネットワークエンティティの識別子を第1リストに追加することにより得られた、ネットワークエンティティの識別子の第2リストを含む。この場合、第2API発行要求は、第3ネットワークエンティティの識別子が第1リストに含まれていないと判定したことに応答して送信され得る。第1ネットワークエンティティ700は、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成する様に構成された作成ユニットをさらに含むことができ、送信ユニット720は、第2ネットワークエンティティに、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むAPI発行応答を送信する様にさらに構成され得る。
【0052】
一実施形態において、第1ネットワークエンティティ、第2ネットワークエンティティ、第3ネットワークエンティティ及びサービスAPIを発行したネットワークエンティティのそれぞれは、CCFエンティティであり得る。
【0053】
一実施形態において、第1ネットワークエンティティ、第2ネットワークエンティティ、第3ネットワークエンティティ及びサービスAPIを発行したネットワークエンティティは、総て、単一CAPIFプロバイダドメイン内にあり得る。
【0054】
代わりに、ネットワークエンティティ700は、図5に示す様に、方法500を実行する様に動作できる。図7に示す様に、ネットワークエンティティ700は、機能エンティティから、サービスAPIを発行するための第1API発行要求を受信する様に構成された受信ユニット710を含む。ネットワークエンティティ700は、APIを発行するための第2API発行要求を第2ネットワークエンティティに送信する様に構成された送信ユニット720をさらに含み、第2API発行要求は、第1ネットワークエンティティの識別子を含む。
【0055】
一実施形態において、第1ネットワークエンティティ及び第2ネットワークエンティティのそれぞれは、CCFエンティティであり、機能エンティティは、APFエンティティであり得る。
【0056】
一実施形態において、第1ネットワークエンティティ及び第2ネットワークエンティティは、両方とも、単一CAPIFプロバイダドメイン内にあり得る。
【0057】
ユニット710及び720は、純粋はハードウェアとして、例えば、プロセッサ若しくはマイクロプロセッサと、適切なソフトウェアと、ソフトウェアを格納するメモリと、プログラム可能な論理デバイス(PLD)と、他の電子部品の1つ以上によるソフトウェアとハードウェアの組み合わせとして、或いは、例えば、図4又は5に示す上述した動作を実行する様に構成された処理回路として、実現され得る。
【0058】
図8は、本開示の別の実施形態による第1ネットワークエンティティ800のブロック図である。
【0059】
第1ネットワークエンティティ800は、通信インタフェース810と、プロセッサ820と、メモリ830と、を備えている。メモリ830は、プロセッサ820によって実行可能な命令を含み、それにより、第1ネットワークエンティティ800は、例えば、図4に関連して前述した手順のアクションを実行する様に動作する。方法400に関連して上述した様に、実装において、第1ネットワークエンティティ800は、方法400のブロック410及び420のみを実行する様に動作し得る。別の実装において、第1ネットワークエンティティ800は、方法400のブロック410及び430のみを実行する様に動作し得る。さらに別の実装において、第1ネットワークエンティティ800は、方法400のブロック410、420及び430を実行する様に動作し得る。
【0060】
特に、メモリ830は、プロセッサ820によって実行可能な命令を含み、それにより、第1ネットワークエンティティ800は、第2ネットワークエンティティから、サービスAPIを発行するための第1API発行要求を受信する様に動作し、第1API発行要求は、サービスAPIを発行したネットワークエンティティの識別子の第1リストを含む。
【0061】
メモリ830は、プロセッサ820によって実行可能な命令をさらに含み、それにより、第1ネットワークエンティティ800は、第1ネットワークエンティティの識別子が第1リストに含まれている場合、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成したり、サービスAPIをいずれかのネットワークエンティティにさらに発行したりすることなく、サービスAPIの発行の失敗を示すAPI発行応答を第2ネットワークエンティティに送信する様に動作する。
【0062】
代わりに、又は、追加して、メモリ830は、プロセッサ820によって実行可能な命令をさらに含み、それにより、第1ネットワークエンティティの識別子が第1リストに含まれていない場合、第1ネットワークエンティティ800は、サービスAPIを発行するための第2API発行要求を第3ネットワークエンティティに送信する様に動作し、第2API発行要求は、第1ネットワークエンティティの識別子を第1リストに追加することにより得られた、ネットワークエンティティの識別子の第2リストを含む。一実施形態において、第2API発行要求は、第3ネットワークエンティティの識別子が第1リストに含まれていないと判定したことに応答して送信され得る。一実施形態において、メモリ830は、プロセッサ820によって実行可能な命令をさらに含み、それにより、第1ネットワークエンティティの識別子が第1のリストに含まれていない場合、第1ネットワークエンティティ800は、第1ネットワークエンティティでサービスAPIのための新たなリソースを作成し、第2ネットワークエンティティに、サービスAPIの発行の成功を示し、かつ、作成された新たなリソースの識別子を含むAPI発行応答を送信する様に動作する。
【0063】
一実施形態において、第1ネットワークエンティティ、第2ネットワークエンティティ、第3ネットワークエンティティ及びサービスAPIを発行したネットワークエンティティのそれぞれは、CCFエンティティであり得る。
【0064】
一実施形態において、第1ネットワークエンティティ、第2ネットワークエンティティ、第3ネットワークエンティティ及びサービスAPIを発行したネットワークエンティティは、総て、単一CAPIFプロバイダドメイン内にあり得る。
【0065】
代わりに、メモリ830は、プロセッサ820によって実行可能な命令を含み、それにより、第1ネットワークエンティティ800は、例えば、図5に関連して上述した手順のアクションを実行する様に動作する。特に、メモリ830は、プロセッサ820によって実行可能な命令を含み、それにより、第1ネットワークエンティティ800は、機能エンティティから、サービスAPIを発行するための第1API発行要求を受信し、APIを発行するための第2API発行要求を第2ネットワークエンティティに送信する様に動作し、第2API発行要求は、第1ネットワークエンティティの識別子を含む。
【0066】
一実施形態において、第1ネットワークエンティティ及び第2ネットワークエンティティのそれぞれは、CCFエンティティであり、機能エンティティは、APFエンティティであり得る。
【0067】
一実施形態において、第1ネットワークエンティティ及び第2ネットワークエンティティは、両方とも、単一CAPIFプロバイダドメイン内にあり得る。
【0068】
本開示は、例えば、非一時的なコンピュータ可読記憶媒体、EEPROM(電気的に消去可能なプログラム可能リードオンリーメモリ)、フラッシュメモリ、又は、ハードドライブといった、不揮発性又は揮発性メモリの形式である、少なくとも1つのコンピュータプログラム製品も提供する。コンピュータプログラム製品は、コンピュータプログラムを有する。コンピュータプログラムは、プロセッサ820によって実行されると、ネットワークエンティティ800は、例えば、図4又は図5に関連して上述した手順のアクションを実行させる、コード/コンピュータ可読命令を含む。
【0069】
コンピュータプログラム製品は、コンピュータプログラムモジュールで構成されたコンピュータプログラムコードとして構成され得る。コンピュータプログラムモジュールは、図4又は図5に示すフローの動作を基本的に実行する。
【0070】
プロセッサは、単一CPU(中央処理ユニット)であり得るが、2つ以上の処理ユニットを含み得る。例えば、プロセッサは、汎用目的マイクロプロセッサ、命令セットプロセッサ、及び/又は、関連チップセット、及び/又は、特定用途向け集積回路(ASIC)の様な特別なマイクロプロセッサを含み得る。プロセッサは、キャッシュ目的のためのボードメモリを含み得る。コンピュータプログラムは、プロセッサに接続されたコンピュータプログラム製品により担持され得る。コンピュータプログラム製品は、コンピュータプログラムを格納する非一時的なコンピュータ可読記憶媒体を含み得る。例えば、コンピュータプログラム製品は、フラッシュメモリ、ランダムアクセスメモリ(RAM)、リードオンリーメモリ(ROM)又はEEPROMを含み、上述したコンピュータプログラムモジュールは、他の実施形態において、メモリ形式の様々なコンピュータプログラム製品に分散され得る。
【0071】
本開示について、実施形態を参照して説明した。種々の修正、置換及び追加が、本開示の範囲から逸脱することなく、当業者により行われ得ることを理解すべきである。よって、本開示の範囲は、上述した特定の実施形態に限定されず、添付の特許請求の範囲により定義されるのみである。
図1
図2
図3
図4
図5
図6
図7
図8
【手続補正書】
【提出日】2023-11-02
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
サービス・アプリケーション・プログラミング・インタフェース(API)発行のための第1ネットワークエンティティにおける方法(400)であって、
第2ネットワークエンティティから、サービスAPIを発行するための第1API発行要求を受信(410)することを含み、前記第1API発行要求は、前記サービスAPIを発行したネットワークエンティティの識別子の第1リストを含み、
前記方法(400)は、さらに、
前記第1ネットワークエンティティの識別子が前記第1リストに含まれている場合、前記サービスAPIの発行の失敗を示すAPI発行応答を前記第2ネットワークエンティティに送信(420)すること、或いは、
前記第1ネットワークエンティティの識別子が前記第1リストに含まれていない場合、ネットワークエンティティの識別子の第2リストを取得するために、前記第1ネットワークエンティティの前記識別子を前記第1リストに追加すること、
を含む方法。
【請求項2】
請求項1に記載の方法(400)であって、さらに、
第3ネットワークエンティティに、ネットワークエンティティの前記識別子の前記第2リストを含む要求を送信(430)することを含む、方法。
【請求項3】
請求項1又は2に記載の方法(400)であって、さらに、
前記第1ネットワークエンティティの前記識別子が前記第1リストに含まれていない場合、
前記第1ネットワークエンティティで前記サービスAPIのための新たなリソースを作成することと、
前記第2ネットワークエンティティに、前記サービスAPIの発行の成功を示し、かつ、作成された前記新たなリソースの識別子を含むAPI発行応答を送信することと、
を含む方法。
【請求項4】
請求項1から3のいずれか1項に記載の方法(400)であって、
前記第1ネットワークエンティティ、前記第2ネットワークエンティティ及び前記サービスAPIを発行した前記ネットワークエンティティのそれぞれは、共通APIフレームワーク(CAPIF)コア機能(CCF)エンティティである、方法。
【請求項5】
請求項4に記載の方法(400)であって、
前記第1ネットワークエンティティ、前記第2ネットワークエンティティ及び前記サービスAPIを発行した前記ネットワークエンティティは、総て、単一CAPIFプロバイダドメイン内にある、方法。
【請求項6】
通信インタフェース(810)と、プロセッサ(820)と、メモリ(830)と、を含む第1ネットワークエンティティ(800)であって、
前記メモリ(830)は、前記プロセッサ(820)によって実行可能な命令を含み、それにより、前記第1ネットワークエンティティ(800)は、請求項1からのいずれか1項に記載の方法を実行する様に動作する、第1ネットワークエンティティ。
【請求項7】
コンピュータプログラム命令を格納しているコンピュータ可読記憶媒体であって、
前記コンピュータプログラム命令は、第1ネットワークエンティティのプロセッサによって実行されると、前記第1ネットワークエンティティに、請求項1からのいずれか1項に記載の方法を実行させる、コンピュータ可読記憶媒体。
【外国語明細書】